On 09/21/2012 02:47 PM, Rob Crittenden wrote:
Simo Sorce wrote:
----- Original Message -----
Sigbjorn Lie wrote:
On 09/20/2012 10:17 PM, Rob Crittenden wrote:
bind isn't my strongest suite.
My guess is that this file is the ccache for bind. I'm guessing
that
25 is the UID of the named user. If this is the case, then it
should
be safe to stop named, rename the file, and restart. Perhaps the
contexts have changed so when this gets re-created it will get
fixed
automagically.
rob
You guessed well!! :)
Stop named:
# service named stop
Enable selinux:
# setenforce 1
Verify that error still exists:
# service named start
Starting named: [FAILED]
Rename file:
# cd /var/tmp
# mv DNS_25 DNS_25_old
Attempt to start named again:
# service named start
Starting named: [ OK ]
Voila!
A before and after shot:
# ls -lZ DNS_25*
-rw-------. named named unconfined_u:object_r:named_tmp_t:s0 DNS_25
-rw-------. named named system_u:object_r:tmp_t:s0 DNS_25_old
What's the odds that this was the entire issue and that named will
now
keep running safe and sound?
Hard to say. Because restorecon didn't fix the bad context I suspect
this isn't directly covered in policy. So if the file should get the
wrong context again you could be back in this position. It is
probably
worth filing a bug. I'm not entirely sure whether it should be
against
bind or selinux, but it'll get to the right folks either way
eventually.
That file is the reply-cache, and it's context is set at runtime by the
krb5 library. It did get out of sync because selinux was disabled, and
restorecon, can't fix the label because the file is in a tmp directory,
so it just takes the tmp_t context by default.
If selinux is not completely disable this shouldn't happen anymore,
however,
should it happen you can simply remove the file, it is not vital and
will
get recreated after you restart named.
Simo.
AFAIK he never disabled SELinux. He put it into permissive temporarily
to get going again while we diagnosed this but before and after the
krb5-server upgrade he was in enforcing mode.
I wonder if the krb5-server upgrade caused a filesystem relabel and
this is what hosed the /var/tmp entry.
rob
This is my test environment, and I disabled SElinux completely after the
upgrade to 2.2 as I got annoyed with how slow it was. The "yum upgrade"
occured while SElinux was in disabled mode. I then set selinux=enforcing
in /etc/sysconfig/selinux and rebooted after yum upgrade completed. I
then set SElinux to permissive during the troubleshooting we did a few
days ago.
My production environment still got SElinux set to enforcing, and the
krb5-server has not yet been upgraded until these issues has been clarified.
I'm sorry for the confusion.
Is the conclusion that I'm having this issue in the first place because
SElinux was disabled when I did "yum upgrade" ?
Regards,
Siggi
_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
