As soon as ColdFusion 2018 update 2 was installed and the Apache connector was rebuilt, we are seeing this following error in mod_jk.log, repeatedly.
[Thu Feb 14 12:42:06 2019] [16186:139977799252096] [error] uri_worker_map_update::jk_uri_worker_map.c (1299): Unable to stat the /opt/coldfusion2018/config/wsconfig/1/uriworkermap.properties (errno=13)
The server is running RHEL 7, with SELinux and locked down. However the apache is running without any issues and the web application doesn't experience any issues. But the mod_jk.log is flooded with this entry.
It would be great, if someone could assist on this please. We didn't face this issue before.
Does that file exist? When you see "unable to stat" errors, sometimes that means the file no longer exists. I think you have to tell SELinux to no longer check that file. (Note: I am not an expert on SELinux.)
Dave Watts, Eidolon LLC
First - you should file a bug so Adobe is aware of the issue.
Next make sure that apache has permission to read that file
Finally make sure that selinux has the proper label on the file:
chcon -t httpd_config_t -u system_u /opt/coldfusion2018/config/wsconfig/1/uriworkermap.properties
Thank You Pete for your suggestions.
We resolved it and it was down to the file permissions. The right SELinux context was applied. as you had mentioned.
After the Apache Connector was re-built, the permissions of the files were 644. After this update 2 installation, the mod_jk.log file had its right SELinux type for the file and the permissions, without manually granting it.
Changing the permission of the file to 660, stopped the error entry in the log file. (Though CFLockdown guide recommendation was 540, which still didn't prevent the error from occurring). However the apache was starting up without any issues and CFadmin was accessible during the entire time.
Thanks for clarifying Annie, that is odd that it would need write permission to that file. It is just a configuration file but perhaps the new autotuning feature now writes to it so it opens for writing instead of opens it for reading??
I have raised this with dev and they are looking into this. I will keep you all posted.
It really is strange and I still don't understand why it would require a write permission on it. I was not aware of the autotuning feature, and will look into it.
I did bit of more experiment in a new Virtual machine and came up with the following observations.
In new VM instance built with an image containing CF2018, installed update 2, rebuilt Apache connector. Applied SELinux context and it all worked well with the following permissions.
The directory /opt/coldfusion2018/config/wsconfig/1 had full permissions (by default after running the wsconfig utility) with root:root as ownership.
All the files within the directory had 644 as permissions and root:root ownership.
I changed the ownership to cfuser:apache for the entire directory( /opt/coldfusion2018/config/wsconfig/1) and there were no issues.
I ran this command
Chmod -R 540 /opt/coldfusion2018/config/wsconfig/1 and applied chmod 560 on mod_jk.log, the issue started occurring.
[Thu Feb 14 21:25:01 2019] [1491:140393088891008] [error] uri_worker_map_update::jk_uri_worker_map.c (1299): Unable to stat the /opt/coldfusion2018/config/wsconfig/1/uriworkermap.properties (errno=13)
[root@test-apache-connector wsconfig]# chmod 660 1/
Changed the directory ( /opt/coldfusion2018/config/wsconfig/1) permission alone to 660, the issue stopped occurring.
Did you try the lockdown manually or with the Lockdown Installer?
Also, we are looking into why the uriworkermap.properties file would require write permissions.
Also, have you raised a bug for the error being thrown? It would be great if you could share the Bug number for everyone (if someone else also hits the same issue)
We have fixed the issue where correct context was not being set to mod_jk.log file.
We have a question regarding the Lockdown guides, could you please help answering our question. Our technical architect came up with this observation. We followed CF2016 lockdown guide, while setting this server up, last year as the CF2018 Lockdown guide was not released then. And there's this step where the apache user is added to webusers group in CF2016 lockdown guide. In that case, the folder /opt/coldfusion2018/config/wsconfig/1 should have had the following ownership cfuser:webusers instead of cfuser:apache?
Hi Annie, I don't think it would make much difference, because the apache user will be a member of both the apache group and the webusers group, and the cfuser can be controlled by the owner user bits. Feel free to email me directly to discuss further, it is my first name (4 letters) at foundeo.com
Thank you Pete!