So, starting last Friday, on two of the sites on our server, cfmailparam is kicking back the following:
can’t attach file https://www.xxx.xx/XXXXBDFECCD4B3DB6B3D7089879D31.pdf, this file doesn’t exist
The file definitely exists, I can click on the link and it’s there.
The strange thing is this is only affecting 2 of roughly 10 sites on the server. And it doesn’t seem to matter where I stick the attachment - any folder and it happens. I’ve tried downloading the attachment, and then linking to it locally, and the email sends just fine. Or downloading it, re-uploading to one of the other sites that is working and it still works just fine.
It happens on something as simple as this:
Testing
Where I set thisAttachment right before that. If I swap out the link with an attachment on a different site, no problem.
What am I missing here? Is there something ‘stuck’ somewhere in a spool specific to these two sites that is breaking this? I can’t for the life of me find where that might be in that case. I’m on Ubuntu 20.4. Upgraded lucee to newest version last night just in case but that didn’t help (is it normal that an upgrade deletes all datasources and mail links btw? That added some work ugh).
Primarily I can’t figure out why it would all of a sudden stop working on just a couple of sites as well. Seems to be plenty of memory left (disk usage under 30%, memory around 60%).
Any suggestions on where I can look?! I feel I’ve exhausted all options other than just re-setting up these sites from scratch again…
OS: Ubuntu 20.4
Lucee Version: 5.3.10.120
Servlet Container Apache Tomcat/9.0.35
Java 11.0.7 (AdoptOpenJDK) 64bit
I would check the permissions of the service user running lucee to the file path where you store the file.
1 Like
I have a cflucee user which is both owner and group, and has read/write access under both. The files across all the sites seem to have the same permissions upon manual checks I’ve done.
Or am I misunderstanding what you are saying?
su as that user, then manually try to grab that file.
A little unsure which command I should use to ‘grab’ a file, but su in as cflucee and then cp the file in question to somewhere else on the server works just fine.
Can permissions just all of a sudden change how they work? Nothing was done on the server last week, so just seems very strange.
updates to the os can change the behavior.
is it a DNS issue?
are you calling host.foo. in the email but its really “ip.add.ress” on your back-end?
Think about how this works logically.
lucee generates the correct file and the file works on most of your boxes
whats different? If all of the above just “works” but still fails on just a select few boxes, look at how the file is grabbed. Do they all really just CP, or is it network sfcp, or rsync, or is it a NFS share?
how is your code accessing the attachment? is it a chttp call? is it cfexecute to a custom binary? This is where if all of the above fail, post your code, your lucee version, your os version, your java version, if SELINUX and or fileACL is enabled.
No updates were done when this started failing though. I upgraded Lucee a few notches AFTER the problem started as a hope that was the reason, but other than a new set of headaches due to all the deleted datasources it didn’t do anything.
I have 3 sites on the same server with EXACTLY the same code/setup. 2 work, 1 doesn’t, all of a sudden, since last Friday with literally zero changes to code or anything. It’s possible Digital Ocean where they are hosted has done a change, but it seems unlikely that would affect 1 site and not the others. There are like 7 or 8 other sites of mine that share elements but aren’t exactly the same on the same server - one of these also has the same issue, the others seem fine.
I have created a test setup where the code is as simple as:
<cfmail>
<cfmailparam file="https://www.goxplore.dk/7E13BF8656C1C2E003D93FADF9DB6205.pdf" />
</cfmail>
And it still fails. Also if I run that same code on a local test server and try and access the same file on the server (guess it would fail no matter who ran the test). So clearly it’s not finding the pdf even though it’s there.
3 sites same server…
Vhost via apache?
I would check to see what your HOST file has, I would run a check on DIG for /hostname.whatever
I would check your base vhost for a htaccess file and check the contents
you should have an error log generated, which will tell you what to look for.
did you try importing the certificate for www.xxx.xxx into the keystore? In the Lucee admin, go to the SSL Certificates tab, and import it there, then restart Lucee and try that again. You often need the cert in your keystore in order to do thinks like cfhttp calls and the like.
1 Like
Can you cfhttp that same file and look if its generating an error and may be dump the error scope? Just like @David_Anderson I suspect there might be something else, like SSL handshake issues or networking problems.
1 Like
Ah, this was most helpful. There is definitely something there. Checked across a few different sites and the ones not working I’m getting this back:
errordetail: Unknown host: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
filecontent: Connection Failure
statuscode: Connection Failure. Status code unavailable.
I’ve never done what @David_Anderson mentions before, but will give it a shot now!
Ok, so it looks like an updated certificate (I use cloudflare for a few sites, these two included, but also some of the ones that were still fine) that I guess Lucee doesn’t update automatically (just guessing based on some past discussions on the topic). I couldn’t get the install via the server admin to work, but Cfhttp error over SSL (unable to find valid certification path to requested target) - #2 by ian_chapman had this neat little piece of code that handily fixed the problem:
<cfscript>
dump(SSLCertificateInstall("rodelokkavel.no"));
</cfscript>
So yeah, that is something a noob like me would never have been able to figure out without the pointing in the right direction by you guys. Thanks for the help!
2 Likes
Lucee bundles it’s own cacerts file causing this problem as it gets outdated.
So with 6.0 it will use the jvm’s bundled cacerts by default, which breaks SSLCertificateInstall which is just a workaround for this problem of having an outdated cacerts file, the old behaviour is still available via an env var, more details in ticket.
This is flagged in jira as a breaking-change
I have just updated the bundled cacerts for 5.3.10, 5.4 and 6.0
3 Likes
was there an error logged anywhere? i.e. maybe in the remoteclient.log?
@cfmitrah checked this as well, it didn’t log an error
I have created a ticket [LDEV-4499] - Lucee
1 Like
Does this mean we’ll have to go back to using keytool to update cacerts when needed?
I’d personally avoid that process completely, much better just updated your cacerts file from your JVM
In 6.0 that’s the default
Isn’t that done via the keytool.exe?
just copy the cacerts file over
2 Likes