Subject: | |
From: | |
Reply To: | |
Date: | Tue, 15 Jul 2008 15:51:22 +0100 |
Content-Type: | TEXT/PLAIN |
Parts/Attachments: |
|
|
Bonjour all,
Several weeks ago a test SL4.5 server was built, with quite a lot of
post-install config (gLite). The test looked ok & seemed functional, so
(after a few more tweaks including syslog.conf - that's what bit us) a
batch of servers were built & deployed.
Then we noticed in horror that none were writing to /var/log/messages &
that lsof /dev/log showed a strange thing minilogd had control, not
syslogd. It looked like some fatal problem between selinux (which isn't
grok'd here) & syslogd.
The hurried solution was to set selinux to permissive & restart syslogd.
Then they log to /var/log/messages & to their central syslog server.
A bit of investigation now shows that this line
/bin/mv /root/conf/syslog.conf /etc/syslog.conf
is the culprit. Using /bin/cp instead & rebuilding a test server again,
syslogd is fine.
Many files will have changed on those deployed servers. It is warned not
to just enable selinux again:
"Changes you make to files while SELinux is disabled may give them an
unexpected security label, and new files do not have a label. You may need
to relabel part or all of the file system after enabling SELinux again."
Briefly perusing the SElinux manual doesn't enlighten, it's too complex.
Does anyone know, is there a quick-fix very safe solution, perserving all
current files, to re-set selinux to enforcing, for the servers that now
have to have selinux permissive for syslog to work?
Grateful for advice.
|
|
|