Wednesday, July 21, 2010

SELINUX SCREWS LOG FILES

How do we troubleshoot a problem in a Linux machine
We first try to see through the logs and see if we notice anything.

Now what if the logs are empty. What do we do ???
Ahh we are in a deep shit now. We check the /var and then the space on the /var and permissions and all things and we dont find anything. We check the syslog config file and we still dont see anything. Now What. Someone Help me please.

What I do is I check the dmesg and do a grep on the syslog. Ahh I found something. If at all it returns you with a similar output as shown below you can really catch the IT security guy and blame it on the SELINUX config
dmesg | grep syslog
audit(1151150355.645:2): avc: denied { read } for pid=2204 comm="syslogd" name="services" dev=dm-0 ino=14567535 scontext=system_u:system_r:syslogd_t tcontext=rootbject_r:tmp_t tclass=file
.

A quick workaround is to stop the syslog service and start the daemons from the terminal.
Ohh hoo it works.

service syslog stop
Stopping kernel logger [OK]
Stopping system logger [OK]
[root@test]# klogd -d
[root@test]# syslogd -d.


Now check the logs and it has to work.

Now what. Solution for this is


Turn off the Damn SELINUX or run

fixfiles relabel


Problem resolved. Give me a 5

Tuesday, May 29, 2007

SYSTEM INIT SCRIPT FORMAT

#!/bin/bash#
# chkconfig: 35 90 12
# description: Foo server
#

# Get function from functions library
. /etc/init.d/functions

# Start the service FOO
start() {
initlog -c "echo -n Starting FOO server: "
/path/to/FOO &
### Create the lock file ###
touch /var/lock/subsys/FOO
success $”FOO server startup”
echo
}

# Restart the service FOO
stop()
{
initlog -c “echo -n Stopping FOO server: ”
killproc FOO
### Now, delete the lock file ###
rm -f /var/lock/subsys/FOO
echo
}
### main logic ###
case “$1″ in
start)
start
;;
stop)
stop
;;
status)
status FOO
;;
restartreloadcondrestart)
stop
start
;;
*)
echo $”Usage: $0 {startstoprestartreloadstatus}”
exit 1
esac
exit 0

Thursday, May 24, 2007

DIfferent Raid Levels

The different raid levels available today

Raid 0 - Stripping data across the disks. This stripes the data across all the disks present in the
array. This improves the read and write performance. Eg. Reading a large file takes a
long time in comparison to reading the same file from a Raid 0 system.They is no data
redundancy in this case.

Raid 1 - Mirroring. In case of Raid 0 it was observed that there was no redundancy,i.e if one
disk fails then the data is lost. Raid 1 overcomes that problem by mirroring the data. So
if one disk fails the data is still accessible through the other disk.

Raid 2 - RAID level that does not use one or more of the "standard" techniques of mirroring,
striping and/or parity. It is implemented by splitting data at bit level and spreading it
across the data disks and redundant disk. It uses a special algorithm called as ECC
(error correction code) which is accompanied across each data block. These are tallied
when the data is read from the disk to maintain data integrity.

Raid 3 - data is striped across multiple disks at a byte level. The data is stripped with parity and
the parity is maintained in a separate disk. So if that disk goes off , it results in a data
loss.

Raid 4 - Similar to Raid 3 the only difference is that the data is striped across multiple disks at
block level.

Raid 5 - Block-level striping with distributed parity. The data and parity is stripped across all
disks thus increasing the data redundancy. Minimum three disks are required and if
any one disk goes off the data is still secure.

Raid 6 - Block-level striping with dual distributed parity. Its stripes blocks of data and parity
across all disks in the Raid except that it maintains two sets of parity information for
each parcel of data thus increasing the data redundancy. So if two disk go off the data
is still intact.

Raid 7 - Asynchronous, cached striping with dedicated parity. This level is not a open industry
standard. It is based on the concepts of Raid 3 and 4 and a great deal of cache is
included across multiple levels. Also there is a specialised real time processor to
manage the array asynchronously.

Friday, May 18, 2007

The complete sudo config

Thursday, May 17, 2007

Audit daemon- The culprit

It is observed that if your Linux machine stops responding to any application the cause may be the audit daemon running on your system. But it can be only concluded if your /var/log/messages displays the audit daemon as culprit. The /var/log/messages normally shows messages like
May 16 10:40:01 test-server audbin[848]: threshold 20.00 exceeded for filesystem /var/log/audit.d/. - free blocks down to 19.96%
May 16 10:40:01 test-server auditd[3706]: Notify command /usr/sbin/audbin -S /var/log/audit.d/save.%u -C -T 20% exited with status 1
May 16 10:40:01 test-server auditd[3706]: output errorMay 16 10:40:01 test-server auditd[3706]: output error
May 16 10:40:01 test-server auditd[3706]: output error; suspending execution

In this case the problem is the audit daemon setting in the file /etc/audit/audit.conf

Normally the file looks like this
mode = bin;
num-files = 4;
file-size = 20M;
file-name = "/var/log/audit.d/bin";
notify = "/usr/sbin/audbin -S /var/log/audit.d/save.%u -C -T 20%";# AUDBIN THRESHOLDS:# The above notify will cause auditd to enter 'suspend' mode when
# free space on the /var/ filesystem falls below 20%.
# To take remedial action, eg. moving the oldest save file to /backup, use:
# notify = "/usr/sbin/audbin -S /var/log/audit.d/save.%u -C -T 20% -N 'mv -f %f /backup'";
# or even
# notify = "/usr/sbin/audbin -S /var/log/audit.d/save.%u -C -T 20% -N 'rm -f %f'";
# This will free space by removing the oldest "save." files first from /var,# returning 0 to auditd and allowing it to continue.


Now as per the above file the audit daemon gets suspended once the /var filesystem available space goes below 20 %

So we need to enable the last option of deleting the audit log file once the /var filesystem available space goes below 20 %
This can be done by commenting the first notify line and uncommenting the last notify line. The explanation in the file says it all

Wednesday, May 9, 2007

Linux

The kernel differences
2.4 and 2.6

2.4 has .o objects for the os to come up. Which means that the user space programs are used for linking and bringing up the OS. But 2.6 uses .ko objects for the os to come up. which means that it uses kernel space programs for linking and bringing up the OS also which make the OS fast in booting.

The schedulers
2.4 uses a O1 scheduler whereas 2.6 uses a On scheduler algorithm