• Home
• Blog
• About
• Gallery
• Map
• Resume

Bare Metal Linux Restore

Several weeks ago we started seeing some pretty scary errors showing up on the main system disk for our Blackboard server. We had an extra server hanging around, so we decided to move all the data off the failing disk and onto our spare server. The only question was how to make the new server as close to a perfect copy of the old one as possible. Simply restoring all the filesystems failed for a variety of reasons, mostly related to GRUB and the kernel, so I had to find a way of excluding only the files and directories that were tied to the specific model of server.

To do this, I started by installing a minimal copy of RHEL 4, making sure to lay the filesystems out in exactly the same way as they were on the old server. I then went through several experiments, leaving just the bare minimum files and directories required for the hardware and booting, but formatting all other filesystems and restoring the data from our old server. In the end, the below process resulted in system that worked perfectly, and very closely mirrored the original server.
Read more

RHEL System Configuration Changes for Oracle 10G

Below is a list of RHEL system configuration changes that Oracle 10G requires before it is installed.

First, check the following kernel parameters using the commands below:

/sbin/sysctl -a | grep kernel.shmall
/sbin/sysctl -a | grep kernel.shmmax
/sbin/sysctl -a | grep kernel.shmmni
/sbin/sysctl -a | grep kernel.sem
/sbin/sysctl -a | grep fs.file-max
/sbin/sysctl -a | grep net.ipv4.ip_local_port_range
/sbin/sysctl -a | grep net.core.rmem_default
/sbin/sysctl -a | grep net.core.rmem_max
/sbin/sysctl -a | grep net.core.wmem_default
/sbin/sysctl -a | grep net.core.wmem_max

If any parameters are lower than the examples below, you will have to increase them by editing “/etc/sysctl.conf” file, adding the appropriate lines as expressed below. If the current value is higher, leave it as is.

kernel.shmall = 2097152
kernel.shmmax = 2147483648
kernel.shmmni = 4096
kernel.sem = 250 32000 100 128
fs.file-max = 65536
net.ipv4.ip_local_port_range = 1024 65000
net.core.rmem_default = 262144
net.core.rmem_max = 262144
net.core.wmem_default = 262144
net.core.wmem_max = 262144

Next, edit your “/etc/security/limits.conf” file, adding the following lines:

oracle          soft    nproc           2047
oracle          hard    nproc           16384
oracle          soft    nofile          1024
oracle          hard    nofile          65536

If your current “/etc/pam.d/login” file does not already contain the following line, add it:

session    required     pam_limits.so

Finally, add the following lines to your “/etc/profile” file:

#Tweaks for Oracle
if [ $USER = "oracle" ]; then
    if [ $SHELL = "/bin/ksh" ]; then
    ulimit -p 16384
    ulimit -n 65536
    else
    ulimit -u 16384 -n 65536
    fi
fi

These are just the basic steps I take. See the “Oracle Database Installation Guide” for more complete instructions.

How to Make Gnarly Big Linux Filesystems

At least in RHEL 4, the fdisk command does not support the creation of filesystems larger than 2TB. In order to get around it, you have to use the parted command. I found the basic info here, but this is the long and short of how to cut off a big ol’ slice of disk using parted:

Run parted

# /sbin/parted

It’s interactive, so the following commands are issued within the utility.

1) Make the disk label

(parted) mklabel gpt

2) Create the partition

(parted) mkpart primary 0 -1

3) Verify

(parted) print

Disk geometry for /dev/sda: 0.000-38146.972 megabytes
Disk label type: msdos
Minor    Start       End     Type      Filesystem  Flags
1          0.031    101.975  primary   ext3        boot
2        101.975  38146.530  primary               lvm

4) Exit the GNU Parted command shell

(parted) quit

5) Finally, make the filesystem:

# mkfs.ext3 -m0 -F /dev/sdb1

6)Finally, you don’t want to wait for that big filesystem to fsck from time to time, so make sure it does not get checked unless you run the command yourself:

# tune2fs -c0 -i0 /dev/sdb1

That should just about do it. Remember that only RHEL 4 and higher can support filesystems larger than 2TB. If I remember correctly RHEL 3 can go up to 2TB, RHEL4 can handle 8TB, and RHEL 5 can make a whopping 16TB chunk of disk. Have fun!

RHEL useradd Syntax

Unlike other flavors of UNIX, RHEL does not have a command like adduser which walks you through the process step-by-step, so you have to remember the four flags useradd requires, and in what order it expects to receive them. Since I don’t manually add users unless I’m installing a new server, I don’t run the command enough to remember the syntax… It’s basically the same as it is on Solaris.

useradd -g group -c 'User Name' -d /path/to/home/directory -s /bin/bash username

VMware Fusion Evaluation

Since much of my job involves rolling out Linux solutions I’ve been experimenting with VMware Fusion Beta for the Macintosh in my development environment. Given that the product is still in beta, I have very few complaints about its actual stability. Most of the features work reliably as advertised, but there are some basic points of functionality that I feel the software is lacking. More on that later.

First, let’s take a look at exactly what VMware Fusion is. At its core, the package allows the user to create and run virtual machines on the Macintosh. For those who are new to virtualization, it is a way to run multiple virtual computers on one actual computer. The hardware resources are abstracted and shared to the virtual machines through the virtualization software — in this case VMware Fusion. A complete description on virtualization can be found here.

Previous to Fusion, only VMware player was available to Macintosh users, so it is nice to actually be able to create virtual machines locally. The snapshot feature is also very nice for development purposes since you can instantly roll back to a previous working state should you corrupt the software on the virtual machine.

Perhaps the problem that annoyed me most, however, was the fact that there is no clear way to delete virtual machines from within the software. I actually tried to get rid of one by deleting this folder:

/Volumes/Macintosh HD/Users/myaccount/Documents/Virtual Machines/Mymachine.vmwarevm

But I just ended up breaking the “Virtual Machine Library” application and having to uninstall and reinstall everything from scratch. The process detailing how to delete a virtual machine did not exist anywhere in the VMware Fusion FAQ or documentation as far as I could tell. Granted, it’s beta software, but I would think this should be a core feature of any virtualization product. At least they provide an “Uninstaller” script.

VMware Fusion is a basic piece of software that succeeds in fulfilling the most fundamental of virtualization requirements. If all you want to do is be able to run a virtual machine or two on your Mac, it will most likely work for you. If you are looking to deploy it as part of an enterprise solution, I would suggest letting the product mature a while and using something like Parallels instead.

Disable SSH Root Logins on RHEL

For one reason or another RHEL does not disallow incoming ssh connections as root. This is, of course a glaring security problem which should be addressed for all systems that allow ssh connections to be made from any but the most restricted networks.

The best practice, of course, would be to make the initial ssh connection as an unprivileged user and then use the “su” command to promote yourself to root. This way, even if an attacker managed to get into the system, it would be as an unprivileged user and they would not able to do much harm. Allowing incoming ssh connections at root leaves you much more exposed to attack. Granted your root password is still protecting you, but it becomes your only layer of defense.

Ok, so how do we disallow incoming ssh connections as root on our RHEL box?

First, edit “/etc/ssh/sshd_config”

Find the section of the file that looks like this:

# Authentication:
#LoginGraceTime 2m
#PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6

Change this line:
#PermitRootLogin yes

To this:
PermitRootLogin no

Restart sshd:
/sbin/service sshd restart

RHEL Winbind Authentication Against Active Directory

So you have a RHEL system and you want to authenticate it against your active directory. The good news is that Red Hat has made it easy for you to do this. The bad news is that they only get the most basic structure working for you. Here I will show you how to get WinBind authentication working using Authconfig, and how make it a little more seamless than this utility leaves it off.

It should be noted that while this works perfectly well, it is really not the best way to authenticate users against a UNIX host. Given the option, having your users in Open Ldap and PAM authenticating them against that would be a much better option. However, we don’t live in a perfect world, and sometimes we just have to make things work.

Let’s start by using authconfig to join your machine to the domain. This should all be done as the root user.

# authconfig

• Select “Use Winbind” and Use “Winbind Authentication”. Remember to leave “Cache Information”, “Use MD5 Passwords” and “Use Shadow Passwords” selected.
• Select “Next”
• Under “Security Model” select “ads”
• “Domains:” examplead (substatute with the name of your Active Directory)
• “Domain Controllers:” adserver.domain.com (Again, substitute with the name of your Active Directory server)
• “ADS Realm:” ADSERVER.DOMAIN.COM
• “Template Shell:” /bin/bash
• Select “Join Domain”
• Select “OK”

Now your machine should be be on the domain. Test it to make sure you can see your AD users:

# wbinfo -u

You should see your users in the list.

The only problem is that to do anything with them, you have to express their user name in that annoying way Windows likes you to. Something like this:

“EXAMPLEAD\\username”

Not very usefull. To get around this, simply edit “/etc/samba/smb.conf” and change this line:

winbind use default domain = no

to this:

winbind use default domain = yes

You should now be able to express AD usernames without the domain nonsense before it. Try it:

# finger username
Login: username                            Name: Username
Directory: /home/EXAMPLEAD/username        Shell: /bin/bash
Never logged in.
No mail.
No Plan.

Finally check your “/etc/nsswhich.conf” file to make sure RHEL knows to use WinBind. Authconfig should have set this up for you, and it should have lines that look like this:

passwd:     files winbind
shadow:     files winbind
group:      files winbind

That should do it you should be able to create home directories for all your AD users and let them authenticate away. Have fun.

IFCONFIG Does Not give You Link Status; ETHTOOL Does

For some reason that is a complete mystery to me, RHEL does not give you the link status when you run # ifconfig -a. This makes it incredibly hard to debug link integrity issues! Buried amongst all of Red Hat’s proprietary commands, however, is a utility called ethtool, which does give you the status of your link.

Since ethtool is used for querying settings of an ethernet device and changing them, it does a lot more than just give link status. Amongst other things, you can use it to turn on or off autonegotiation on your network card. Run # /sbin/ethtool -h for full usage.

Here’s how you use it to see if your server has link:

# /sbin/ethtool eth0

You should see something like this:

Settings for eth0:
        Supported ports: [ TP ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Advertised auto-negotiation: Yes
        Speed: 1000Mb/s
        Duplex: Full
        Port: Twisted Pair
        PHYAD: 1
        Transceiver: internal
        Auto-negotiation: on
        Supports Wake-on: g
        Wake-on: d
        Link detected: yes

How to Disable Automatic FSCK on EXT3 Filesystems

The e2fsck will regularly force a check of a filesystem even if the filesystem is marked clean. By default, this happens on every twenty mounts or 180 days, whichever comes first.

The ext3 filesystem does this as well, which can be annoying if you have a very large filesystem and a short downtime window. Therefore, it’s a good idea to disable this feature on large volumes. Keep in mind that you should still run fsck occasionally, by disabling the automatic checks, you get to Decide when, not the system.

Use the command:

tune2fs -i 0 /dev/hdxx

This disables periodic, automatic checking.

Getting ntpd to work correctly on RHEL

When many new servers are delivered from the factory, the system clock is way off. Most UNIX systems run “ntpd” to keep the time in sync with internet time servers, which are, in turn synchronized against an atomic clock. This results in a system time that is very very close to the “actual” time of day. The downside, however, is that even a properly configured “ntpd” will not synchronize the system clock if it is too far out of sync with the time server. To remedy this, we first have to run “ntpdate” to get the system clock close to the correct time, and then enable “ntpd” to keep it there.

The first thing we have to do is “ntpd” to free up the port for “ntpdate”:

[root@server /]# /sbin/service ntpd stop
Shutting down ntpd:                                        [  OK  ]

This frees up the port for ntpdate. Next we run:

[root@server /]# /usr/sbin/ntpdate time.apple.com

Now the time should be set correctly. We then change the default time servers to something like the following in /etc/ntp.conf:

# --- OUR TIMESERVERS -----
time-a.timefreq.bldrdoc.gov
time-b.timefreq.bldrdoc.gov
time-c.timefreq.bldrdoc.gov


We can use any time server we want, but I like these and find them to be reliable.

Finally, start backup up your “ntpd” service, and your all set to go.

[root@server /]# /sbin/service ntpd start
Starting ntpd:                                        [  OK  ]

Remember to use “chkconfig” to make sure “ntpd” is enabled to come up when the system starts.

Installing OpenGroupWare 1.1.5 on RHEL 3

OpenGroupWare is an open source groupware package intended as an alternative to proprietary applications such as Exchange and PostPath. It is fairly robust in its feature set, and even integrates well with MS Outlook.

Its strongest points, in my opinion are that it does not depend in any way on Active Directory, and that it integrates well with open source standards like Open LDAP and University of Washington IMAP. Its downsides are that the documentation is sparse and scattered, that is is backed with PostgreSQL rather than MySQL, and that the package is bundled into a TON of RPM's.

I have not tried installing it from source, though I suspect that it would not be much more work than using the RPM's. Anyhow, if you want to install it for yourself, here are some quick scripts to help you, as well as some quick cookbook instructions. I installed it on RHEL 3 Workstation, though I suspect that it would work most Linux distributions.

The first thing we have to do is install the foundation for OpenGroupWare From the RHEL CD's or Website:

Install apache
Install PostgreSQL
Install PostgreSQL-devel
Install php
Install php_PostgreSQL

Next, run the following commands to get the database and webserver started:

# /sbin/chkconfig httpd on
# /sbin/chkconfig postgresql on
# /sbin/service postgresql start
# /sbin/service httpd start

Sendmail should already be installed and running, but if not, you will have to install it as well.

OK, so I said before that there are a TON of RPM's that you will have to install. These can be found at the OpenGroupWare website. Get them however you want, but if you have "wget" installed, you can use my script to fetch everything you need. You can omit the "devel" packages if you don't want to install the source code.

Ok, so now we have a directory filled up wit RPM's. Many of these have a lot of dependancies, so the order of install is important. The script below has them in the correct order, so you can either use it as a reference to install them yourself, or just save the script in the directory that has all your RPM's and run it. Your choice.

Some things to note about the install.

These all have to be done on one line or "rpm" will complain that it can's resolve dependancies:
rpm -Uvh ogo-webui-app-1.1.5-r1717.0.i386.rpm ogo-theme-default-1.1.5-r1717.0.i386.rpm ogo-webui-resource-en-1.1.5-r1717.0.i386.rpm ogo-webui-resource-de-1.1.5-r1717.0.i386.rpm

ogo-database-setup-1.1.5-0.i386.rpm sets up your PostgreSQL database and database user for you. The output should look something like this:

Preparing...                     ########################################### [100%]
1:ogo-database-setup             ########################################### [100%]
PostgreSQL seems to be already initialized
and I can see it running:
PIDS used: 3456 3458 3459
We're on PostgreSQL 7 (7.4)
checking /var/lib/pgsql/data/postgresql.conf
need to patch /var/lib/pgsql/data/postgresql.conf for 7.4
backup current one to /var/lib/pgsql/data/postgresql.conf.20061213-153319
checking /var/lib/pgsql/data/pg_hba.conf
need to patch /var/lib/pgsql/data/pg_hba.conf for 7.4
backup current one to /var/lib/pgsql/data/pg_hba.conf.20061213-153319
The changes we've made require that we restart PostgreSQL...
Stopping postgresql service:    [  OK  ]
Starting postgresql service:      [  OK  ]
OK! PostgreSQL runs again: (3909 3911 3912)
creating database user: OGo
creating the database itself: OGo
we've successfully created both the user OGo and the raw database OGo
we'll now fill the database with the scheme itself
checking the logfile created during scheme rollin...
/tmp/database_setup_psql.sh.20061213-153319.log
removing log - not needed anymore

OK... Now everything is installed, and if you run the following command:

# /sbin/chkconfig --list | grep ogo

You should see the following output:

ogo-zidestore   0:off   1:off   2:on    3:on    4:on    5:on    6:off
ogo-webui       0:off   1:off   2:on    3:on    4:on    5:on    6:off
ogo-xmlrpcd     0:off   1:off   2:on    3:on    4:on    5:on    6:off
ogo-nhsd        0:off   1:off   2:on    3:on    4:on    5:on    6:off

Now, let's fire up these services:


# /sbin/service ogo-zidestore start
# /sbin/service ogo-webui start
# /sbin/service ogo-xmlrpcd start
# /sbin/service ogo-nhsd start

Everything should be up and running now, so you can grab a web browser and go to the following RUL:

http://server.domain.com/OpenGroupware

You will be logged in as the root user, so make sure to change the password.

If you are using this system as a stand-alone server, you are pretty much all set. We needed to authenticate it against our central LDAP, and point it towards our IMAP server though, so I added the following lines to "/var/lib/opengroupware.org/.libFoundation/DefaultsNSGlobalDomain.plist":


LSAuthLDAPServer = "ldapserver.domain.com";
LSAuthLDAPServerRoot = "dc=mydomain,dc=com";
imap_host = "imapserver.domain.com";
UseSkyrixLoginForImap = YES;


Make sure to put these lines at the end of the file, but before the closing braces.

The file should look something like this:

###### SNIP #######
{
"skyrix_id" = "server.domain.com";
LSConnectionDictionary = {
  databaseName = OGo;
  hostName = "127.0.0.1";
  password = "";
  port = 5432;
  userName = OGo;
};
  LSNewsImagesPath = "/var/lib/opengroupware.org/news";
  LSNewsImagesUrl = "/ArticleImages";
  Languages = (
  English
);
  TimeZoneName = GMT;
  WOHttpAllowHost = (
  localhost,
  "127.0.0.1",
  "localhost.localdomain"
);
  LSAuthLDAPServer = "ldapserver.domain.com";
  LSAuthLDAPServerRoot = "dc=domain,dc=com";
  imap_host = "imapserver.domain.com";
  UseSkyrixLoginForImap = YES;
}
###### /SNIP #######

Since the system won't let you authenticate the "root" user against the local database if your are using LDAP, you have to create a root user on your central LDAP.

Create an LDIF file called root.ldif like so:

###### SNIP #######
dn: uid=root,ou=People,dc=mydomain,dc=com
objectClass: organizationalPerson
objectClass: top
objectClass: posixAccount
objectClass: shadowAccount
uid: root
uidNumber: 0
gidNumber: 0
sn: Root
cn: Root
homeDirectory: /root
loginShell: /bin/bash
gecos: Root
###### /SNIP #######

Finally, run the following command to add the root user:


ldapadd -x -D "cn=Manager,dc=mydomain,dc=com" -W -f root.ldif"


You should now be authenticating against your central LDAP server. Have fun!

Setting Up The Automounter Service on RHEL

Mounting filesystems in RHEL is pretty straightforward and easy. Occasionally, however, you will not want the filesystem to remain mounted all the time, but rather to automatically mount for a set period of time only when it is needed. Because of networking overhead, and the general unreliability of networks, NFS mounts are a good example of when this can be especially useful.

In order to manage the automatic mounting and unmounting of filesystems on RHEL, we use the Automounter service. Here is how.

First, The main configuration file is "/etc/auto.master". It should look something like this:

#
# $Id: auto.master,v 1.3 2003/09/29 08:22:35 raven Exp $
#
# Sample auto.master file
# This is an automounter map and it has the following format
# key [ -mount-options-separated-by-comma ] location
# For details of the format look at autofs(5).
#/misc  /etc/auto.misc --timeout=60
#/misc  /etc/auto.misc
#/net   /etc/auto.net

Let's assume that we want to set up an NFS mount on "/misc/backups". We would first create an entry in this file that looks something like this:

/misc   /etc/auto.misc --timeout=120

This tells the autofs service that we want to use it to manage mounts from within "/misc", that the configuration file is "/etc/auto.misc", and that it should disconnect after 2 minuets of inactivity.

Now, let's edit the "/etc/auto.misc" file. The file has three columns: the mount point from within the /misc directory, the options for mounting the filesystem, and the filesystem to be mounted. It also includes the remote server's name since we are using NFS. It should look something like this when you are done:

#
# $Id: auto.misc,v 1.2 2003/09/29 08:22:35 raven Exp $
#
# This is an automounter map and it has the following format
# key [ -mount-options-separated-by-comma ] location
# Details may be found in the autofs(5) manpage

cd              -fstype=iso9660,ro,nosuid,nodev :/dev/cdrom
backups         -rw,soft,intr remoteservername:/path/to/nfs/export

# the following entries are samples to pique your imagination
#linux          -ro,soft,intr           ftp.example.org:/pub/linux
#boot           -fstype=ext2            :/dev/hda1
#floppy         -fstype=auto            :/dev/fd0
#floppy         -fstype=ext2            :/dev/fd0
#e2floppy       -fstype=ext2            :/dev/fd0
#jaz            -fstype=ext2            :/dev/sdc1
#removable      -fstype=ext2            :/dev/hdd

Next, we create the directory for the mount point in /misc:

# mkdir /misc/backups

And finally we restart the autofs service:

# service autofs restart

That should pretty much do it. If you don't have autofs configured to start up, you can use chkconfig to enable it. "/misc/backups" will now be mounted whenever a user or process attempts to access data on it, and it will be automatically disconnected after 120 seconds of inactivity. Last, but not least, you can always confirm that it is running with the "service" command:

# service autofs status

As always, change the details to match your own requirements.

Working With Disk Labels in RHEL

When you install RHEL, the filesystems are labeled for you. Usually you won't have to mess with it anymore, but on occasion, you may want to change them to more accurately represent the data that is stored on that partition. If, for instance, you used to have all of your database files on a partition labeled "/database", but you have now moved them somewhere else, and you now wish to house your user account data there, it would make sense to change the label to something like "/users".

Labels are, of course, arbitrary, so there is no technical need to do this, and you could, instead simply change the mount point in the fstab file, mounting the partition by device name rather than label, but it is usually cleaner to change the label. Here is how you do it:

First, let's figure out what the partition is currently labeled as:

[root@calvin /]# /sbin/e2label /dev/hda4
/database
[root@calvin /]#

It's current label is "/database", and, since we have moved the database data somewhere else, we now want to store our user account data here, we need to change it to "/users".

[root@calvin /]# /sbin/e2label /dev/hda4 /users
[root@calvin /]#


That's all there is to it, now we check to make sure we have done what we think we have done.

[root@calvin /]# /sbin/e2label /dev/hda4
/users
[root@calvin /]#

Sure enough, it's now labeled "/users" and the data on the disk remains intact. Now all we have to do is change the appropriate entry in the "/etc/fstab" file to represent the change.

Change this:

LABEL=/database       /databases            ext3    defaults        1 2

To this:

LABEL=/users          /users                ext3    defaults        1 2

And you're all set to go. Make sure you have unmounted "/databases" before making the change.

Now, just run:
[root@calvin /]# mount /users
[root@calvin /]#

And you're all set to go. As always, change the values here to represent those in your environment.

Controlling Services With chkconfig

Many system 5 UNIX variants use scripts in the /etc/rcN.d/ directories to control which services should be started in the various runlevels. If, for instance, you wanted the secure shell daemon to run in runlevel 4, you would put a script named something like "S55sshd" in "/etc/rc4.d". This script would usually accept the "start" "stop" and "restart" arguments, as well as the commands to perform these functions. When the system came up, it would execute "/etc/rc4.d/S55sshd start" when it transitioned into runlevel 4. On the way down, it would execute "/etc/rc4.d/S55sshd stop" as the system passed from runlevel 4 to runlevel 3. If you had made some changes to the sshd configuration file, and wanted to restart the service, you could manually execute "/etc/rc3.d/sshd restart" to kill and then restart the daemon.

Since this model involved having multiple copies of the same script in many different directories, Linux and others have adopted the standard of putting all service control scripts in "/etc/init.d/", and using symbolic links to these scripts in the various "/etc/rcN.d/" directories. This allowed for the SGI IRIX innovation of the "chkconfig" command, which is command line tool that manages the symbolic links for you.

How to use "chkconfig" in Red Hat Enterprise Linux:

First, all your service control scripts need to be in the "/etc/init.d/" directory. They should reflect the name of the service they control. In our example, the file is named /etc/init.d/sshd".

Secondly, they have a tag at the head of the script that looks something like this so that "chkconfig" understands that it can controll it:

# Basic support for IRIX style chkconfig
###
# chkconfig: 2345 55 25
# description: Manages the services you are controlling with the chkconfig command
###

The first set of numbers "2345" is are the default runlevels for the service, and "55" and "25" represent the name of the "S" and "K" symbolic links, and the order in which the service will be started and stopped in the respective runlevel. You will need to change these last two numbers, making them unique.

Once these requirements are met, using the command is fairly simple. When we go into /etc/rc3.d, we see a file called "S55sshd".

[root@calvin rc2.d]# cd /etc/rc3.d
[root@calvin rc2.d]# ls -al S55sshd
lrwxrwxrwx 1 root root 14 Nov 15 15:10 S55sshd -> ../init.d/sshd

We see this file is a symbolic link to "../init.d/sshd". Let's run the "chkconfig" command to turn sshd off.

[root@calvin init.d]# /sbin/chkconfig sshd off
[root@calvin init.d]# /sbin/chkconfig --list sshd
sshd 0:off 1:off 2:off 3:off 4:off 5:off 6:off

chkconfig --list sshd confirms that sshd has been disabled in all runlevels, and the symbolic link has been removed from all "/etc/rcN.d/" directories.

Let's turn sshd back on:

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

chkconfig --list sshd confirms that sshd has now been enabled in runlevels 2, 3, 4 and 5, and we see s symbolic link to "/etc/init.d/sshd" named "S55sshd" in "/etc/rc2.d/", "/etc/rc3.d/", "/etc/rc4.d/" and "/etc/rc5.d/".

Let's imagine now that we only want sshd to be enabled in runlevel 5. We run the following command to accomplish this:

[root@calvin rc2.d]# /sbin/chkconfig sshd --level 234 off
cd /etc/[root@calvin rc2.d]# /sbin/chkconfig --list sshd
sshd 0:off 1:off 2:off 3:off 4:off 5:on 6:off

chkconfig --list sshd confirms that sshd has been disabled in all runlevels except 5, and the "S55sshd" has been removed from "/etc/rc2.d/", "/etc/rc3.d/" and "/etc/rc4.d/".

There is, of course, more to it, but this should get you well on your way to happily managing your system services with "chkconfig".

Popular Posts

• Bash For loop Example (740)
• Fish Supposedly Washed Up By Asian Tsunami (577)
• Little Japanese Trucks (342)
• Spencer Tunick Photographs More Than 18000 Nudes In Mexico City (282)
• Why Did my Arm Fall Asleep? (277)
• How to copy a Solaris boot drive to a disk with a different partition layout (245)
• RHEL Winbind Authentication Against Active Directory (205)
• Solaris Disk Partition Layout & Mirroring Scripts (193)
• F