security level configuration tool

[charsjim]

I configured some additional ports in the security level configuration tool, and now the thing wont start. I get the following in a terminal:

[jim@localhost ~]$ system-config-securitylevel ?
Traceback (most recent call last):
File "/usr/share/system-config-securitylevel/system-config-securitylevel.py", line 18, in ?
app.stand_alone()
File "/usr/share/system-config-securitylevel/securitylevel.py", line 453, in stand_alone
self.readFile()
File "/usr/share/system-config-securitylevel/securitylevel.py", line 353, in readFile
protoname = socket.getservbyport(int(service), protocol)
socket.error: port/proto not found

Has anyone seen this issue or now how to fix it?

Jim

[bitrain]

[jim@localhost ~]$ system-config-securitylevel ?

What does it say without the question mark. Have you updated the tool, there was a bug, which is fixed. There is another bug, which doesn't let you start pyhton programs (like this one) from the commandline, so you have to use the menu.

[kg4cbk]

There is a known bug in system-config-securitylevel that causes it to fail if you added additional ports listed in the application. I believe there is a patch that has been issued for this problem. Do a yum update on that package and it should fix it for you.

[charsjim]

Thanks for your help, I managed to fix the issue by doing the yum update as suggested.

Jim

[SharedMedia]

Red Hat includes the checkconfig & service utilities to help you manage your start up scripts and save you a lot of typing. This is handy when you're adding your own services and also in managing the already existing services. chkconfig is available if you want to use it on other distributions that may not come with it - just go to freshmeat.net and look it up. /sbin/service is just a shell script that comes as part of Red Hat's initscripts package.

Without a tool like chkconfig, symbolic links to the scripts in /etc/rc.d/init.d are typically created by hand at the appropriate run levels. This can be messy & difficult to standardize. Also, it is necessary to view the contents of each run level directory to see which services are configured to run. Here's some ways to use chkconfig: What's enabled at run level 3?

[root@usr-3 init.d]# chkconfig --list | grep 3:on
atd 0:off 1:off 2:off 3:on 4:on 5:on 6:off
syslog 0:off 1:off 2:on 3:on 4:on 5:on 6:off
sendmail 0:off 1:off 2:on 3:on 4:on 5:on 6:off
autofs 0:off 1:off 2:off 3:on 4:on 5:on 6:off
network 0:off 1:off 2:on 3:on 4:on 5:on 6:off
random 0:off 1:off 2:on 3:on 4:on 5:on 6:off
apmd 0:off 1:off 2:on 3:on 4:on 5:on 6:off
iptables 0:off 1:off 2:on 3:on 4:on 5:on 6:off
sshd 0:off 1:off 2:on 3:on 4:on 5:on 6:off
portmap 0:off 1:off 2:off 3:on 4:on 5:on 6:off
nfs 0:off 1:off 2:off 3:on 4:on 5:on 6:off
nfslock 0:off 1:off 2:off 3:on 4:on 5:on 6:off
crond 0:off 1:off 2:on 3:on 4:on 5:on 6:off
anacron 0:off 1:off 2:on 3:on 4:on 5:on 6:off
xinetd 0:off 1:off 2:off 3:on 4:on 5:on 6:off

Enable a service for runlevel 3

[root@usr-3 init.d]# chkconfig wine on
[root@usr-3 init.d]# chkconfig --list wine
wine 0:off 1:off 2:on 3:on 4:off 5:off 6:off

Disable it

[root@usr-3 init.d]# chkconfig wine off
[root@usr-3 init.d]# chkconfig --list wine
wine 0:off 1:off 2:off 3:off 4:off 5:off 6:off

Checkconfig reads some lines at the beginning of an rc script to determine what run levels the script should be run at. We'll use the openssh rc script as our example.

[root@usr-3 init.d]# head -8 sshd
#!/bin/bash
#
# Init file for OpenSSH server daemon
#
# chkconfig: 2345 55 25
# description: OpenSSH server daemon
#

The chkconfig line & description line must go into every script that is to go under the control of chkconfig. The description line seems pretty self-explanatory. the chkconfig line:

# chkconfig: 2345 55 25
| | |
| | priority for kill scripts
| |
| priority for start scripts
|
run levels at which to start service

If you've created an rc script for a service, put your chkconfig line & description line in as listed above. Then you need to add your service to those under the management of chkconfig.

[root@usr-3 init.d]# chkconfig sshd --add

Now you can enable it.

[root@usr-3 init.d]# chkconfig sshd on

You can see by looking at listings of the directories that the appropriate links have been created in each of the run levels.

[root@usr-3 rc.d]# for i in 1 2 3 4 5 6
> do
> ls rc$i.d/*ssh*
> done
rc1.d/K25sshd
rc2.d/S55sshd
rc3.d/S55sshd
rc4.d/S55sshd
rc5.d/S55sshd
rc6.d/K25sshd

If you didn't know, the K links pass a stop parameter to the script and the S links send a start parameter. The numbers determine in what order they'll run relative to the other scripts at a given runlevel. The rc scripts are executed in the order you see when you list them in the directory, first the K's in numerical order, then the S's in numerical order. So at run levels 1 and 6 the script is run with a stop parameter, and in run levels 2,3,4,5 it receives a start parameter. We also see this by running a simple command:

[root@usr-3 rc2.d]# chkconfig sshd --list
sshd 0:off 1:off 2:on 3:on 4:on 5:on 6:off

Now that you can manage your scripts using chkconfig, here's a tip that will save you a little bit of typing. When running an rc script to restart a daemon or what have you, the path is pretty long:

[root@usr-3 rc2.d]# /etc/rc.d/init.d/sshd restart

or you could type this instead:

[root@usr-3 rc2.d]# service sshd restart

Hey, it's 9 keystrokes less! It has some other cool features - get the status on all your services:

[root@usr-3 rc2.d]# service --status-all
apmd (pid 682) is running...
arpwatch is stopped
atd (pid 1151) is running...
cannaserver (pid 985) is running...
crond (pid 1003) is running...
cserver (pid 966) is running...
jserver (pid 946) is running...
gpm is stopped
identd is stopped
ipchains: Incompatible with this kernel
No status available for this package
kserver (pid 1023) is running...
lpd is stopped

You get the idea. Have Fun!