Of course, I just remembered that the server still thinks it's April 4,
and I still have some certs that are expiring as of 4-17-16. Before I
screw anything else up, what's the RIGHT way to renew those certs and
move the server back to real time?
On 04/29/2016 01:07 PM, Bret Wortman wrote:
Hot damn! It's up and running. Web UI works. CLI works.
The chgrp did the trick.
Thank you Rob, Petr and Christian!
Bret
On 04/29/2016 01:04 PM, Rob Crittenden wrote:
Bret Wortman wrote:
We run with selinux disabled.
# getenforce
Disabled
# restorecon -R -v /etc/httpd/alias
# ipactl start
Starting Directory Service
Starting krb5kdc Service
Starting kadmin Service
Starting named Service
Starting ipa_memcached Service
Starting httpd Service
Starting pki-tomcatd Service
Failed to start pki-tomcatd Service
Shutting down
Aborting ipactl
# ipactl status
Directory Service: STOPPED
Directory Service must be running in order to obtain status of other
services
ipa: INFO: The ipactl command was successful
#
The problem is permissions. Try:
# chgrp apache /etc/httpd/alias/*.db
The mode is ok, Apache only needs read access.
The segfault is fixed upstream and actual usable error messages
reported. The init system doesn't see it as a failure because this
happens after Apache forks its children.
I'd also consider re-enabling SELinux eventually.
rob
On 04/29/2016 12:25 PM, Christian Heimes wrote:
On 2016-04-29 18:17, Bret Wortman wrote:
I'll put the results inline here, since they're short.
[root@zsipa log]# ls -laZ /etc/httpd/
drwxr-xr-x. root root system_u:object_r:httpd_config_t:s0 .
drwxr-xr-x. root root system_u:object_r:etc_t:s0 ..
drwxr-xr-x. root root system_u:object_r:cert_t:s0 alias
drwxr-xr-x. root root system_u:object_r:httpd_config_t:s0 conf
drwxr-xr-x. root root system_u:object_r:httpd_config_t:s0 conf.d
drwxr-xr-x. root root system_u:object_r:httpd_config_t:s0
conf.modules.d
lrwxrwxrwx root root ? logs ->
../../var/log/httpd
lrwxrwxrwx root root ? modules ->
../../usr/lib64/httpd/modules
lrwxrwxrwx root root ? run ->
/run/httpd
[root@zsipa log]# ls -laZ /etc/httpd/alias
drwxr-xr-x. root root system_u:object_r:cert_t:s0 .
drwxr-xr-x. root root system_u:object_r:httpd_config_t:s0 ..
-r--r--r-- root root ? cacert.asc
-r--r--r-- root root ? cacert.asc.orig
-rw-r----- root root ? cert8.db
-rw-rw---- root apache ? cert8.db.20160426
-rw-rw---- root apache ? cert8.db.orig
-rw-------. root root system_u:object_r:cert_t:s0 install.log
-rw-r----- root root ? key3.db
-rw-rw---- root apache ? key3.db.20160426
-rw-rw---- root apache ? key3.db.orig
lrwxrwxrwx root root ? libnssckbi.so
-> ../../..//usr/lib64/libnssckbi.so
-rw-rw---- root apache ? pwdfile.txt
-rw-rw---- root apache ? pwdfile.txt.orig
-rw-rw---- root apache ? secmod.db
-rw-rw---- root apache ? secmod.db.orig
Some files don't have the correct SELinux context or are completely
missing a context. SELinux prevents Apache from accessing this files.
Did you replace some files or restore some from a backup? You
should see
a bunch of SELinux violations in your audit log.
In order to restore the correct context, please run restorecon:
# restorecon -R -v /etc/httpd/alias
This should set correct contexts and allow you to start Apache
HTTPD again.
Christian
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
