Enabling and disabling services during start up in GNU/Linux

In any Linux distribution, some services are enabled to start at boot up by default. For example, on my machine, I have pcmcia, cron daemon, postfix mail transport agent ... just to name a few, which start during boot up. Usually, it is prudent to disable all services that are not needed as they are potential security risks, and also they unnecessarily waste hardware resources. For example, my machine does not have any pcmcia cards so I can safely disable it. Same is the case with postfix which is also not used.

So how do you disable these services so that they are not started at boot time?

The answer to that depends on the type of Linux distribution you are using. True, many Linux distributions including Ubuntu bundle with them a GUI front end to accomplish the task which makes it easier to enable and disable the system services. But there is no standard GUI utility common across all Linux distributions. And this makes it worth while to learn how to enable and disable the services via the command line.

But one thing is common for all Linux distributions which is that all the start-up scripts are stored in the '/etc/init.d/' directory. So if you want to say, enable apache webserver in different run levels, then you should have a script related to the apache webserver in the /etc/init.d/ directory. It is usually created at the time of installing the software. And in my machine (which runs Ubuntu), it is named apache2. Where as in Red Hat, it is named httpd. Usually, the script will have the same name as the process or daemon.

Here I will explain different ways of enabling and disabling the system services.

1) Red Hat Method

Red Hat and Red Hat based Linux distributions make use of the script called chkconfig to enable and disable the system services running in Linux.

For example, to enable the apache webserver to start in certain run levels, you use the chkconfig script to enable it in the desired run levels as follows:

# chkconfig httpd --add
# chkconfig  httpd  on --level 2,3,5

This will enable the apache webserver to automatically start in the run levels 2, 3 and 5. You can check this by running the command:

# chkconfig --list httpd

One can also disable the service by using the off flag as shown below:

# chkconfig httpd off
# chkconfig httpd --del

Red Hat also has a useful script called service which can be used to start or stop any service. Taking the previous example, to start apache webserver, you execute the command:

# service httpd start

and to stop the service...

# service httpd stop

The options being start, stop and restart which are self explanatory.

2) Debian Method

Debian Linux has its own script to enable and disable services across runlevels. It is called update-rc.d. Going by the above example, you can enable apache webserver as follows

# update-rc.d apache2 defaults

... this will enable the apache webserver to start in the default run levels of 2,3,4 and 5. Of course, you can do it explicitly by giving the run levels instead of the "defaults" keyword as follows:

# update-rc.d apache2 start 20 2 3 4 5 . stop 80 0 1 6 .

The above command modifies the sym-links in the respective /etc/rcX.d directories to start or stop the service in the destined runlevels. Here X stands for a value of 0 to 6 depending on the runlevel. One thing to note here is the dot (.) which is used to terminate the set which is important. Also 20 and 80 are the sequence codes which decides in what order of precedence the scripts in the /etc/init.d/ directory should be started or stopped.

And to disable the service in all the run levels, you execute the command:

# update-rc.d -f apache2 remove

Here -f option which stands for force is mandatory.

But if you want to enable the service only in runlevel 5, you do this instead:

# update-rc.d apache2  start 20 5 . stop 80 0 1 2 3 4 6 .

3) Gentoo Method

Gentoo also uses a script to enable or disable services during boot-up. The name of the script is rc-update . Gentoo has three default runlevels. Them being: boot, default and nonetwork. Suppose I want to add the apache webserver to start in the default runlevel, then I run the command:

# rc-update add apache2 default

... and to remove the webserver, it is as simple as :

# rc-update del apache2

To see all the running applications at your runlevel and their status, similar to what is achieved by chkconfig --list, you use the rc-status command.

# rc-status --all

4) The old fashioned way

I remember the first time I started using Linux, there were no such scripts to aid the user in enabling or disabling the services during start-up. You did it the old fashioned way which was creating or deleting symbolic links in the respective /etc/rcX.d/ directories. Here X in rcX.d is a number which stands for the runlevel. There can be two kinds of symbolic links in the /etc/rcX.d/ directories. One starts with the character 'S' followed by a number between 0 and 99 to denote the priority, followed by the name of the service you want to enable. The second kind of symlink has a name which starts with a 'K' followed by a number and then the name of the service you want to disable. So in any runlevel, at any given time, for each service, there should be only one symlink of the 'S' or 'K' variety but not both.

So taking the above example, suppose I want to enable apache webserver in the runlevel 5 but want to disable it in all other runlevels, I do the following:

First to enable the service for run level 5, I move into /etc/rc5.d/ directory and create a symlink to the apache service script residing in the /etc/init.d/ directory as follows:

# cd /etc/rc5.d/
# ln -s /etc/init.d/apache2 S20apache2

This creates a symbolic link in the /etc/rc5.d/ directory which the system interprets as - start (S) the apache service before all the services which have a priority number greater than 20.

If you do a long listing of the directory /etc/rc5.d in your system, you can find a lot of symlinks similar to the one below.

lrwxrwxrwx  1 root root 17 Mar 31 13:02 S20apache2 -> ../init.d/apache2

Now if I start a service, I will want to stop the service while rebooting or while moving to single user mode and so on. So in those run levels I have to create the symlinks starting with character 'K'. So going back to the apache2 service example, if I want to automatically stop the service when the system goes into runlevel 0, 1 or 6, I will have to create the symlinks as follows in the /etc/rc0.d, /etc/rc1.d/, /etc/rc6.d/ directories.

# ln -s /etc/init.d/apache2 K80apache2

One interesting aspect here is the priority. Lower the number, the higher is the priority. So since the starting priority of apache2 is 20 - that is apache starts way ahead of other services during startup, we give it a stopping priority of 80. There is no hard and fast rule for this but usually, you follow the formula as follows:

If you have 'N' as the priority number for starting a service, you use the number (100-N) for the stopping priority number and vice versa.

(link to original post)

To chroot from one Linux to another

# /bin/bash
# chroot_to_gentoo.pl (from linux 1)
mount /dev/sda9 /mnt/gentoo ;
mount /dev/sda8 /mnt/gentoo/boot ;
mount -t proc none /mnt/gentoo/proc ;
mount -o bind /dev /mnt/gentoo/dev ;
/usr/sbin/chroot /mnt/gentoo /bin/bash

#source /etc/profile && env-update
#export PS1="(chroot) $PS1"
==================================
# /bin/bash
# chroot_to_gentoo2.pl (from linux 2)
#mount /dev/sda9 /mnt/gentoo ;
#mount /dev/sda8 /mnt/gentoo/boot ;
#mount -t proc none /mnt/gentoo/proc ;
# mount -o bind /dev /mnt/gentoo/dev ;
#/usr/sbin/chroot /mnt/gentoo /bin/bash

#This has to be in the gentoo side (gentoo partition).
source /etc/profile && env-update
#export PS1="(chroot) $PS1"
======================================
# /bin/bash
# chroot_to_gentoo3.pl (from linux 2)
#mount /dev/sda9 /mnt/gentoo ;
#mount /dev/sda8 /mnt/gentoo/boot ;
#mount -t proc none /mnt/gentoo/proc ;
# mount -o bind /dev /mnt/gentoo/dev ;
#/usr/sbin/chroot /mnt/gentoo /bin/bash

#source /etc/profile && env-update ;

#This has to be in the gentoo side (gentoo partition).
export PS1="(chroot) $PS1"
===============================
#/bin/bash
# exit_chroot.pl (from linux 1 after the command "exit" from linux 2)
#cd /home/acardh ;
umount /mnt/gentoo/boot /mnt/gentoo/dev /mnt/gentoo/proc /mnt/gentoo
=================================

Invalid atom in gentoo

# emaint --check world
Checking world for problems

'sys-apps/coldplugapp-admin/syslog-ng' is not a valid atom

Finished
====================
# emaint --fix world
Attempting to fix world
Finished
========================

Chroot: Gentoo installation steps

mount /dev/hda8 /mnt/gentoo
mount /dev/hda7 /mnt/gentoo/boot
mount -t proc none /mnt/gentoo/proc
mount -o bind /dev /mnt/gentoo/dev
/usr/sbin/chroot /mnt/gentoo /bin/bash

source /etc/profile && env-update
export PS1="(chroot) $PS1"


###################################

rc-update add net.eth0 default

passwd

useradd -m -G users acardh
# passwd acardh

nano -w /etc/rc.conf

emerge syslog-ng
# rc-update add syslog-ng default
logrotate

emerge vixie-cron
# rc-update add vixie-cron default

emerge dhcpcd

emerge grub
vi /boot/grub/grub.conf
grub
grub> root (hd0,6) (Specify where your /boot partition resides)
grub> setup (hd0,6) (Install GRUB in the MBR)
grub> quit (Exit the GRUB shell)

emerge firefox
emerge aspell



# exit
cdimage ~# cd
cdimage ~# umount /mnt/gentoo/boot /mnt/gentoo/dev /mnt/gentoo/proc /mnt/gentoo
cdimage ~# reboot





# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE: You have a /boot partition. This means that
# all kernel and initrd paths are relative to /boot/, eg.
# root (hd0,10)
# kernel /vmlinuz-version ro root=/dev/hda12
# initrd /initrd-version.img
#boot=/dev/hda
default=0
timeout=15
splashimage=(hd0,10)/grub/splash.xpm.gz
#hiddenmenu
title Fedora Core (2.6.18-1.2257.fc5)
root (hd0,10)
kernel /vmlinuz-2.6.18-1.2257.fc5 ro root=LABEL=/ rhgb quiet
initrd /initrd-2.6.18-1.2257.fc5.img

title=Gentoo Linux 2.6.18-r6 (genkernel)
root (hd0,6)
kernel /boot/kernel-genkernel-x86-2.6.18-gentoo-r6 root=/dev/ram0 init=/linuxrc ramdisk=8192 real_root=/dev/hda8 udev
initrd /boot/initramfs-genkernel-x86-2.6.18-gentoo-r6

#title Fedora Core (2.6.18-1.2239.fc5)
# root (hd0,10)
# kernel /vmlinuz-2.6.18-1.2239.fc5 ro root=LABEL=/ rhgb quiet
# initrd /initrd-2.6.18-1.2239.fc5.img
~

Two packages mutually blocking each other in Gentoo

I try to update and recive error:
>=x11-proto/xproto-7.0.6 (is blocking x11-libs/libX11-1.0.1-r1)

i did uninstalled xproto but my computer had xproto-7.0.5 not xproto-7.0.6

# emerge --search xproto
* x11-proto/xproto
Latest version available: 7.0.7
Latest version installed: [ Not Installed ]
Size of files: 130 kB
Homepage: http://xorg.freedesktop.org/
Description: X.Org xproto protocol headers
License: xproto

===========
The solution
emerge -C xproto && emerge -C libX11 && emerge xproto libX11
==========

Safe make.conf in Gentoo

http://gentoo-wiki.com/Safe_Cflags
x86 - (32bytes)
Intel Core Solo/Duo

vendor_id : GenuineIntel
cpu family : 6
model : 14
model name : Genuine Intel(R) CPU TXXXX @ XXXGHz

CHOST="i686-pc-linux-gnu"
CFLAGS="-march=prescott -O2 -pipe -fomit-frame-pointer"
CXXFLAGS="${CFLAGS}"

Gentoo compilation failure metabug

http://bugs.gentoo.org/show_bug.cgi?id=20600


http://www.gentoo.org/doc/en/change-chost.xml

Gentoo configuration issues (2)

Updating configuration files in gentoo
=======
* Regenerating GNU info directory index...
* Processed 160 info files.
* IMPORTANT: 34 config files in /etc need updating.
* Type emerge --help config to learn how to update config files.
=======
In this case run the command: #etc-update


To add a service to the start up runlevel (so it will start every time the machine is reinitiated)
Adding to the run level:
# rc-update add gpm default
# rc-update add sshd default

To find a string:
Goto the applications folder, then:
grep -inr searchterm *
Ex: grep -inr localhost.localdomain *
This should show you all the files that contain that string.


3) Gentoo Method

Gentoo also uses a script to enable or disable services during boot-up. The name of the script is rc-update . Gentoo has three default runlevels. Them being: boot, default and nonetwork. Suppose I want to add the apache webserver to start in the default runlevel, then I run the command:

# rc-update add apache2 default

... and to remove the webserver, it is as simple as :

# rc-update del apache2

To see all the running applications at your runlevel and their status, similar to what is achieved by chkconfig --list, you use the rc-status command.

# rc-status --all

Gentoo configuration issues

To update the entire system
#emerge --update --deep --newuse --ask world

To manage blocked packages
http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?full=1#blocked
To un emerge the blocked packages:
#emerge --unmerge pckgname

Upgrade guide
http://www.gentoo.org/doc/en/new-upgrade-to-gentoo-1.4.xml

1. Before you begin

Be prepared

As with any major upgrade to the core of your Gentoo system, there is always the possibility that unforeseen problems will ensue. It is always prudent to back up all important data before beginning this process. If possible, try to allocate a large block of time for this upgrade, so that you will not feel rushed. All the software on your machine will need to be recompiled.

Other options

This is not the only way to upgrade your system. You can install a new 1.4 system onto a separate partition and reuse some of your system configuration instead. This method also has the advantage that you can always go back to your old system in the meantime as a fallback. You may also decide to simply not upgrade your system. If you decide you want to upgrade in place, read on.

General notes

Whenever the code listings suggest running the emerge command, it is always a good idea to make a test run of the command using the -p or --pretend option to make sure that the command will do what you expect it to do.

2. Upgrading in place

Get Portage as current as possible

Some of the syntax of current ebuilds is unreadable by older versions of Portage. If you don't have at least Portage 2.0.44, try upgrading Portage.

Code Listing 2.1: Updating Portage

# emerge --sync # emerge -u portage

Note: If your Portage version is very old, you may get an error message containing the phrase "unscriptable object". Read and follow the instructions in /usr/portage/sys-apps/portage/files/README.RESCUE. Your Portage install should then be current.

Preparing GCC for cohabitation

You will be installing a newer version of GCC during this upgrade. Versions of GCC older than 2.95.3-r8 are not designed to have multiple versions of GCC installed. You must therefore upgrade GCC to at least version 2.95.3-r8. This will also have the beneficial side-effect of installing the gcc-config package on your system, which can be used to switch back and forth between various installed versions of GCC.

Code Listing 2.2: Updating GCC

# emerge -u gcc

You can now check to see if gcc-config is working properly:

Code Listing 2.3: Verifying GCC profile

# gcc-config --get-current-profile

This should return i686-pc-linux-gnu-2.95.3 on most x86 systems. Older systems may return i586-pc-linux-gnu-2.95.3.

Installing GCC 3

Now you can install a newer version of GCC without damaging your current compiler. Look in /usr/portage/sys-devel/gcc for a version of the GCC ebuild that is at least 3.2.1-r6. Choose the highest version that is marked stable for your architecture. To see if an ebuild is considered stable for your architecture, look for the KEYWORDS line in the ebuild file. If it has your architecture listed without a ~ in front of it, it is considered stable. Assuming 3.2.2 is the most current stable version, we first need to remove the glibc dependency from gcc.

Edit /usr/portage/sys-devel/gcc/gcc-3.2.2.ebuild and search for the line containing DEPEND. Remove the glibc dependency and save the ebuild.

Code Listing 2.4: Editing gcc-3.2.2.ebuild

# vim /usr/portage/sys-devel/gcc/gcc-3.2.2.ebuild

Now install the latest GCC version on your system:

Code Listing 2.5: Install the latest GCC

# USE="-java" emerge /usr/portage/sys-devel/gcc/gcc-3.2.2.ebuild

Changing profiles

Now you need to change two sets of profiles: your gcc-config profile and your Portage profile.

Code Listing 2.6: Change the Portage profile

# cd /etc # rm make.profile (Replace "x86" with your architecture) # ln -s ../usr/portage/profiles/default-x86-1.4 make.profile

Code Listing 2.7: Change the GCC profile

(Note the one for the version you just emerged, use it below) # gcc-config --list-profiles (Replace with the version you noted above) # gcc-config i686-pc-linux-gnu-3.2.2

Recompile toolchain

Now you need to recompile your core toolchain with your new compiler. If you are continuing in the same shell, you need to run source /etc/profile as gcc-config instructed you to. Then emerge glibc and binutils using your new compiler:

Code Listing 2.8: Rebuilding the toolchain

# emerge glibc binutils

Warning: It is quite likely that you will upgrade glibc from a 2.2 or older version to 2.3. Do not downgrade glibc afterwards. Any software you have compiled against glibc 2.3 will stop working, and this can make your system unusable.

Recompiling everything with your new compiler

Now you may recompile everything on your system with your new compiler:

Code Listing 2.9: Rebuilding the entire system

# emerge -e world

Note: If this command fails at any point due to errors, you can use emerge --resume to continue the process where you left off. This requires Portage 2.0.47 or later.

HOWTO Replace RedHat with Gentoo, Remotely over SSH

Author: Jordan Ritter (jpr5 at darkridge dot com) (Link)

Introduction

What is this?

This is a HOWTO that describes how to take a stock RedHat9 system and convert it to Gentoo, remotely over ssh and while it is running. These instructions have been tested with RedHat9, but very likely apply to everything from RedHat9 down to RedHat 7.2, and include everything from advice and gotchas around how to get another distribution installed over RedHat while it is running, to strategies for cleaning up the system of unused files once the transformation is complete.

Why do that?

While everyone has their own tastes in Linux distributions and installed software, there are frequently times when one doesn't have a real choice, and only the most popular distributions prevail. For example, remote ISPs that offer leasable colocated systems will provide only a short list of the most common Linux distros for pre-installation, and while it's almost a sure thing that RedHat is on that list, there is no guarantee that your favorite one is.

I had a remotely colocated server installed with RedHat9 that I had no physical access to. I love Gentoo, though, and so through much trial and tribulation (and about 80 vmware checkpoints) I figured out how to fulfull the Gentoo dream without needing to access the physical console.

Does it really work?

Yes, it really works! It probably seems a bit scary, but I have tried this process now a dozen times and the only problems I've ever had were the result of typo mistakes that can easily be avoided with more careful attention. No more RedHat9 on my systems -- all are 100% pure Gentoo now, baby!

Wait... I have questions about Gentoo..

This HOWTO assumes a basic knowledge of Gentoo. Some time is taken to explain the finer points and possible pitfalls and gotchas, but to successfully install Gentoo Linux really requires ready access to the Gentoo Installation Documentation, in addition to this document. Print it out in advance or have it handy before doing this.

OK, I'm ready. I can sue if this doesn't work, right?

Nope.

THESE INSTRUCTIONS ARE PROVIDED AS-IS AND WITHOUT WARRANTY. ALL USERS ACCEPT FULL RESPONSIBILITY AND LIABILITY IN THE EVENT OF SYSTEM FAILURE, DATA LOSS, OR ANY OTHER FAILURE OR LOSS RESULTING FROM THESE INSTRUCTIONS.

Phew, ok! Here we go!

The General Strategy

In summary, the transformation process is actually fairly simple. Since Gentoo, once unpacked, will run its own binaries from its own libraries, all we're really doing is unpacking Gentoo on top of RedHat without wiping out our remote access mechanism (sshd), then removing the old RedHat files.

The entire process can be distilled down into the following simple steps:

1. Preparation -- Make copies of important files and configuration items, Download Gentoo tarballs, Get sshd running without PAM, and Tag old files for later removal;
2. Installation -- Unpack Gentoo tarballs, Re-add important files and configuration items, Remove the old RedHat libc and related files, Synchronize Portage, and proceed with a normal Gentoo install;
3. Clean-up -- Remove old RedHat files, and Secure the system.

See? Easy!

Step 1: Preparation

There are several things that need to be prepared before actually starting the transformation process. Create a directory on a partition you have plenty of space on and don't intend to touch (like ``/tmp/gentoo''), and use that to store temporary files and such, as explained below.

Again, please have handy in some form the Gentoo Installation Documentation, as this HOWTO won't take the time to explain the various Gentoo-specific concepts in detail.

All instructions assume the user is logged in as ``root''.

1. Compile a kernel with relevant driver support compiled-in.

   Just to be on the safe side, you should compile a fully-static kernel. In other words, we want a kernel that will run the system that has no externel module dependencies. When we start removing libraries and old files and such, it is quite possible we might accidentially rm something that those exceedingly tedious RedHat kernels rely on. Just compile your own and make sure your system boots and runs from it before you even start this process. I suggest sticking with 2.4.x for now so as not to complicate things.

   NOTE: I suggest not enabling devfs support just yet. Gentoo can still boot without it, and it's better to have a kernel that can boot both systems RedHat + Gentoo than one that may only be able to boot under Gentoo (dunno how well RedHat supports devfs out-of-the-box).

   Also, just to be safe, copy the kernel (again, after you've tested it) to the safe directory where you're keeping copies of things.

2. Turn off PAM in OpenSSH's sshd_config file.

   Just like with the kernel, we have to be careful about the differences between the PAM setup in RedHat and the PAM setup in Gentoo. You don't need PAM in order for the thing to function, so regardless of whether you like it or not just disable it so as to ensure you'll be able to login again.

   Best way to do this is:

   1. Modify ``/etc/ssh/sshd_config'', set ``UsePAM'' to ``no'', save the file.
   2. Run ``netstat -tanp | grep LISTEN | grep sshd'', and note the sshd PID.
   3. Kill sshd with ``kill PID'', where you got the PID from the previous step. This will only kill the listening sshd, and will not affect any already-connected sessions.
   4. Without logging out, run ``/usr/sbin/sshd''.
   5. Separate from your current logged-in session, try to re-ssh back into the box.

   If you get back in, you're fine on this step.

   Most folks will have no problem with this. If you do experience problems, consult ``/var/log/messages'', and in the worst-case scenario run sshd in the foreground with debugging turned on. That should give you enough detail about what's going on to figure out how to get things running fine.

3. Download the latest snapshots/stage3 tarball.
   

   The only thing you need is the latest stage3 tarball. Make sure to decide ahead of time what platform architecture you are using (x86, pentium3, pentium4, etc), as that's an obvious benefit of Gentoo that you'll want to take advantage of. For the purposes of this HOWTO, we assume the safe ``x86'' architecture.

   You can find a full list of Gentoo mirrors at http://www.gentoo.org/main/en/mirrors.xml. As of this writing, the most recent stage3 tarball is:

      ftp://distro.ibiblio.org/pub/linux/distributions/gentoo/releases/x86/2004.2/stages/x86/stage3-x86-2004.2.tar.bz2
   

4. Make copies of important files and information.

   Copy the following files to your safe location:

   • /etc/resolv.conf
   • /etc/fstab,mtab
   • /etc/passwd,shadow,group
   • /etc/grub.conf,lilo.conf
   • /etc/sysconfig/network
   • /etc/sysconfig/network-scripts/ifcfg-eth*

   Additionally, take a quick snapshot of what modules are loaded, for later inspection, with ``/sbin/lsmod > /tmp/gentoo/modules.txt''.

5. Mark all current files with a special date.

   Assuming the author isn't on crack, how would one know what files to delete after the Gentoo installation overlays the RedHat one? Easy! Set the timestamp on all files to a special date before proceeding. I used my birthday!

   First of all, we need to be careful about touching all files, because the kernel will detect accesses to ``/dev'' and try to autoload modules for things that you may not have present or installed, which will make things take a lot longer. So first we temporarily disable modprobe by moving it out of the way, and then move it back when we're done. Also, some filenames and directories have spaces in them, so we need to be careful of that also.

           mv /sbin/modprobe /sbin/.modprobe
       find / | perl -wpe 's/ /\\ /g' | xargs touch -d "Feb 1 1978" -m -a
       mv /sbin/.modprobe /sbin/modprobe
   

Step 2: Installation

OK! So now it's time to take the dive. Yes, it's a little scary, but follow these instructions and you should be fine.

First, the most effective way to conduct this installation is with two (2) shells, both at or su'd to the root user. We'll call the first shell the "setup" shell and the second shell the "repair" shell. Let's assume that you used "/tmp/gentoo" as the safe directory to store copies of downloaded files and important files and configuration items.

1. From the "setup" shell: Unpack the stage3 tarball onto the root partition.

   cd / && tar jxvf /tmp/gentoo/stage3-*.tar.bz2
   

2. Synchronize Portage.

   emerge sync
   

3. While the portage synchronization is happening, continue on by completing the following operations from the "repair" shell:
   • Re-set the root password. This is because the stage3 tarball replaced your password and shadow file.

   • Re-add your own username/account.

     /usr/sbin/useradd $myuser
     

   • Re-chown your home directory. Your account's UID has changed between RedHat's and Gentoo's numbering schemes.

     chown -R $myuser:users /home/$myuser
     

   • Add your user account to the wheel group in ``/etc/group'', so you can ``su''.

   IMPORTANT: At this point, test that you can ssh back into the box. You may have to restart the listening sshd server, but that's unlikely.

   • Re-add any other necessary account info, referencing ``/tmp/gentoo/passwd,shadow,group'' files. If any UIDs or GIDs change between the old files vs. the new, make sure to run chown across the filesystem to adjust them.

     find / -uid $olduid |  perl -wpe 's/ /\\ /g'  | xargs chown $newusername
     

   • Copy back ``/etc/fstab''. Also suggest removing the "LABEL=" stuff, which I believe is a concept introduced by RedHat.
   • Fix ``/etc/grub.conf'' or ``/etc/lilo.conf'' depending on which you use.
   • Optional: Remove RedHat's bash aliases from ``/root/.bashrc''.
   • Edit ``/etc/make.conf''.
     • Add ``MAKEOPTS="-j2"''
     • Define your favorite settings. Please see the Gentoo Installation Guide for details.
   • Fix Network Configuration.
     • Edit ``/etc/conf.d/net''.
       • Set ``iface_eth0'', ``gateway''.
     • Run: ``rc-update add net.eth0 default''.
   • Edit ``/etc/rc.conf''.
     • Optional: Set KEYMAP (suggest ``emacs'' to turn capslock into control key).
     • Set ``CLOCK'' to "local".
     • Set ``EDITOR'' to "/usr/bin/vi" or "/usr/bin/emacs", depending on preference.
   • Set the system locale. For instance, if you live on the West Coast: ``ln -sf /usr/share/zoneinfo/US/Pacific /etc/localtime''.
   • (Temporarily) add ``/usr/bin/sshd'' to ``/etc/conf.d/local.start''.
   • Set the hostname: ``echo some_hostname > /etc/hostname''.
   • Switch from RedHat's system libraries to Gentoo's. Run: ``cd /lib && rm -rf i686 && /sbin/ldconfig''.

   By this point, you will be completely off of RedHat's system binaries and libraries and on Gentoo's. Now we must install some basic system components before we reboot and clean up.

4. (Re-)Add basic system components:
   • System Logger: ``emerge sysklogd''
   • Cron Daemon: ``emerge dcron''
   • Fix termcap, otherwise backspace in vi and emacs will be screwed up: ``emerge libtermcap-compat''

   Install any other utilities you would like to have before rebooting. At the very least, you should (re-)install the minimum of things you don't want deleted:

   • grub or lilo (to overwrite RedHat's so that it doesn't get deleted later)
   • openssh (remember to ``rc-update add sshd default'' and remove the ``/etc/conf.d/local.start'' entry afterwards)
   • emacs and/or vi (for a usable editor, I personally don't like nano)

And that's it! Now you're ready to reboot and come back up on Gentoo. At this point the best thing to do is go over your configuration and make sure you have the important things covered before you reboot:

1. That the bootloader is properly configured to point to your preferred, working kernel.
2. That your kernel supports the necessary drivers to properly boot the network interface.
3. That the Gentoo network configuration looks correct and doesn't have any typos.
4. That your fstab is correct and the right file systems will be mounted at boot time.
5. That you can login to the system remotely, and that you can su to root.
6. That the remote access mechanism, openssh, is configured properly to load at boot time. This can be via ``/etc/conf.d/local.start'' or the ``rc-update'' mechanism.

When you're ready, reboot your system: ``shutdown -r now''.

Step 3: Clean-up

The remaining tasks revolve around cleaning up the old RedHat files that Gentoo is not going to use (to get that disk space back), and a few OS security hardening items that can't hurt.

If you're like me, you install the minimum amount of software components necessary to run the system. If however you like installing lots of other things, then keep in mind that you need to consider the spirit of the following instructions rather than the literal directions, as you may have other components you'll want to isolate or protect.

1. Protect certain files and directories.

   Before we install any more software, we need to take advantage of the timestamp magic from the Preparation Step and nuke all the old files. But before we do that, there are some directories and files we want to make sure are protected no matter what. The following is a command line that touches the timestamps of various files, and it should be good enough if you haven't done anything beyond the scope of these instructions.

   for dir in /lib/modules /etc/ssh ; do \
   find $dir | perl -wpe 's/ /\\ /g' | xargs touch -m -a ; \
   done
   
   for file in /etc/resolv.conf ; do \
   touch -m -a $file; \
   done
   

2. Remove old RedHat files

   Recall that we ``touch''ed the entire file system back in the Preparation Step. This was to make it easy to find them after the installation -- the Gentoo steps would overwrite whatever files were in common with RedHat, thereby updating their timestamps, while the files that were untouched would retain the old timestamp. Now we'll run a ``find'' looking for directories and files older than a certain number of days, and then ``rm'' them.

   NOTE: the ``9125'' number below references the number of days since my birthday, which again was the date I chose in the Preparation Step. If you chose a different date, you need to adjust this number accordingly.

   find /bin /sbin /etc /lib /usr /var -type f -mtime +9125 | perl -wpe 's/ /\\ /g' | xargs rm -v
   find /bin /sbin /etc /lib /usr /var -type d -mtime +9125 | perl -wpe 's/ /\\ /g' | xargs rm -vrf
   

   Doing this will screw up the installation of groff (man) and emacs. I'm not sure how, but the solution is simple and easy enough so instead of drilling down to figure this out, I just provide you with the solution:

   emerge groff
   emerge emacs
   emerge vi
   

   See? Simple.

3. Optional: Remove old RedHat devices and special files.

   In the interest of being complete, we also want to consider wiping out any and all "special" files (devices, pipes, sockets, etc) from RedHat that Gentoo doesn't use. Again, remember that the timestamps will be recent if the Gentoo Installation overwrote any of the files, so you should be safe.

   NOTE: I did not do this step. I don't know if it works, but there won't be much disk space to recover from this step and it just wasn't important to me in light of the fact that the Gentoo system prefers to use DevFS and will take over the ``/dev'' directory.

   find /dev -type b -mtime +9125  | perl -wpe 's/ /\\ /g' | xargs rm -v
   find /dev -type c -mtime +9125  | perl -wpe 's/ /\\ /g' | xargs rm -v
   find /dev -type p -mtime +9125  | perl -wpe 's/ /\\ /g' | xargs rm -v
   find /dev -type s -mtime +9125  | perl -wpe 's/ /\\ /g' | xargs rm -v
   

4. Remove old RedHat directories

   If they are empty, you should nuke all the other RedHat directories.

   cd / && rm -rf opt misc tftpboot
   

   Once you're off of the RedHat kernel, you should ``rmdir /initrd'' as well.

   IMPORTANT: don't nuke the initrd directory, even if it's empty, if you're still on the RedHat kernel -- the RedHat kernel boot will fail and hang when it goes to mount the initrd image if the mount point is missing.

5. Secure the system.

   As a general practice, I don't like my users doing much on a system beyond what I have specifically provided for them. To that end, I favor limiting the permissions of standard system components, because you never know what's going to become a security risk.

   1. Limit permissions of SUID/SGID binaries.

      for file in /usr/bin/suidperl /usr/bin/sperl5.* /usr/bin/chage /usr/bin/gpasswd                 \
              /usr/bin/crontab /usr/bin/chfn /usr/bin/chsh /usr/bin/newgrp /usr/sbin/traceroute   \
              /usr/bin/traceroute6 /bin/ping /bin/ping6 /bin/mount /bin/umount /usr/bin/write; do \
      chmod o-rwx $file; chgrp wheel $file; chmod g-r $file ; \
      done
      

   2. Limit permissions of system components that users shouldn't need to run.

      for file in /usr/bin/*cc* /usr/bin/*86* /usr/bin/tracepath* /usr/bin/sudo /usr/sbin/*del \
              /usr/bin/i386-pc-linux-gnu-* /usr/bin/?++ /usr/i386-pc-linux-gnu/bin/*       \
              /usr/i386-pc-linux-gnu/gcc-bin/3.*/* /usr/sbin/*add /usr/sbin/*mod ; do      \
      chmod o-rwx $file; chmod g-rw $file; chgrp wheel $file; \
      done
      

If you want to recompile parts of the OS, now's the time! Install those missing components, emerge whatever you want. You're done!

Handling GCC in Gentoo

http://gentoo-wiki.com/HOWTO_Migrate_to_GCC_3.4

Gentoo Linux Kernel Upgrade Guide

http://www.gentoo.org/doc/en/kernel-upgrade.xml

Aguila server (updating gentoo)

aguila acardh # emerge --update --ask world

!!! Your current profile is deprecated and not supported anymore.
!!! Please upgrade to the following profile if possible:
default-linux/x86/2006.1/desktop

To upgrade do the following steps:
# There are several possible profiles that you can use to replace this one.

# default-linux/x86/2006.1
# default-linux/x86/2006.1/desktop
# default-linux/x86/2006.1/server
# default-linux/x86/no-nptl
# default-linux/x86/no-nptl/2.4

# By default, we use the desktop profile.

# emerge -n '>=sys-apps/portage-2.0.51'
# cd /etc
# rm make.profile
# ln -s ../usr/portage/profiles/default-linux/x86/2006.1/desktop make.profile

# This profile is deprecated and will be removed on or after November 1, 2006
====================
Automated

(View available profiles)
# eselect profile list

(Select the number of your desired profile from the list)
# eselect profile set 
========

Gentoo Upgrade

http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=1

http://www.gentoo.org/doc/en/gentoo-upgrading.xml

Updating your System

To keep your system in perfect shape (and not to mention install the latest security updates) you need to update your system regularly. Since Portage only checks the ebuilds in your Portage tree you first have to update your Portage tree. When your Portage tree is updated, you can update your system with emerge --update world. In the next example, we'll also use the --ask switch which will tell Portage to display the list of packages it wants to upgrade and ask you if you want to continue:

Code Listing 13: Updating your system

# emerge --update --ask world

Portage will then search for newer version of the applications you have installed. However, it will only verify the versions for the applications you have explicitly installed - not the dependencies. If you want to update every single package on your system, add the --deep argument:

Code Listing 14: Updating your entire system

# emerge --update --deep world

Since security updates also happen in packages you have not explicitly installed on your system (but that are pulled in as dependencies of other programs), it is recommended to run this command once in a while.

If you have altered any of your USE flags lately you might want to add --newuse as well. Portage will then verify if the change requires the installation of new packages or recompilation of existing ones:

Code Listing 15: Performing a full update

# emerge --update --deep --newuse world

Gentoo/BSD project

Gentoo in the server room?

Tuesday September 28, 2004 (08:00 AM GMT)

By: Jem Matzan

Link

When people think of Gentoo Linux, they usually associate it solely with Linux gurus who love to tinker with their operating system -- strictly on a desktop level, of course. But while it may be a challenging distraction for home users, Gentoo Linux is increasingly being used on Web servers -- a task traditionally relegated to BSD variants (FreeBSD, primarily) and commercial GNU/Linux distributions (Red Hat, primarily) as well as Windows. Is Gentoo truly ready for "real" work? Is it just some silly distraction for programmers, or can you really use this source-based operating system to your advantage in a production environment?

Before the hosting service company offered Gentoo-based servers for their various hosting services, FreeBSD was the operating system of choice for most of Tek Alchemy's customers. Nowadays most customers request Gentoo Linux on the machines they're paying to use. "Gentoo is a really nice distro," said Dave Thomas, a senior engineer with the company. "It's easy to work with and we can do a custom install with no XFree86 or other stuff that we don't need or want on the system." But you can get a similarly configured FreeBSD system up in less time and with reportedly greater reliability. What is it about Gentoo that people value in a Web server?

It may seem crude to ask that question, because by itself Gentoo Linux is one of the most advanced GNU/Linux distributions available. The Portage software management system delivers a great deal of power and convenience for administrators who need to keep software up-to-date for security reasons. A simple cron job can download and install updates for the base distribution plus whatever else you have installed. In many ways Gentoo is a lot like FreeBSD; the installation, configuration, and maintenance are very similar in practice. Also like FreeBSD, Gentoo doesn't have any fancy administration tools that would make it competitive with commercial distributions from Sun, Novell, Red Hat, and others. But there is a difference between a machine that hosts Apache, MySQL, and Sendmail on a rented server and a machine that runs local network services like NFS, NIS, and DHCP for the network that runs the business. Usually you'll find Red Hat or some other corporate-supported commercial distribution in the back room or on the sysadmin's desk, not a community-based distro. Gentoo makes a good rented server because of its speed and flexibility, but can it handle back room servers that enable the same hosting companies to make money off of their rented servers?

Gentoo as a production server

One company that eats its own dog food is Seven L Networks. It uses Gentoo Linux on almost all of its back room production servers as well as most of the hosting and dedicated servers that it rents out. It runs its mail services and its own company Web site, and stores all of its data backups on Gentoo-based computers. The only critical system that does not run Gentoo is the firewall, which is graced by the legendary OpenBSD.

"Todd Berman of the Mono project helped us out when we started up, and served as our sort of CTO," said Daniel Lang, a Seven L representative. "Todd pushed us to use Gentoo; he was really excited about its customizability and flexibility."

Lang also added that Seven L -- like Tek Alchemy -- has an excellent working relationship with the Gentoo project. "One of the things I like about Gentoo is the community. There's always lots of help available, and you're not afraid to ask questions, unlike some other distros."

Daniel went on to say that using Gentoo on the customer servers is a mixed experience; while it's easy to use and maintain, and the customers who prefer Gentoo are generally more knowledgable, it does take a long time to install. Seven L engineers will do a stage 2 Gentoo install -- meaning GCC, GlibC, and other necessary programs for bootstrapping are precompiled, but the base system is not -- and then use custom precompiled binaries for some of the programs that take a particularly long time to build from source. While Seven L currently uses the 2004.1 edition of Gentoo, it plans to switch to the new 2004.2 release soon. This is not much of an issue because starting from a stage 2 tarball and then updating the source code before compiling the system means that you're getting the latest edition of Gentoo Linux one way or the other.

The underestimated distro?

With operating systems -- especially GNU/Linux distributions -- the key to trouble-free operation is choosing the right tool for the right job. Gentoo can be made into several different tools; it can be a competent and speedy desktop system, it can be used to host chroot jails, or as a Web or email server. It can securely and safely store critical data backups, or host NFS directories.

What makes Gentoo Linux stand above other distros is not just its flexibility -- Slackware and Debian are just as flexible -- but its customizability. Whereas with Debian's stable distribution you're left using software that is months or years old (including the kernel), Gentoo uses the latest tested editions of the Linux kernel, the GNU project's userland utilities and compiler, and the more than 7,000 ported programs in Portage. Slackware, although just as moldable as Gentoo and Debian, does not have an automatically updatable package management system and compiles nothing from source by default.

Gentoo is not a hacker's toy; it is a professional's tool. Let's hear from some people who use Gentoo in production environments -- we already know it makes a good custom desktop. What else do you use Gentoo for?

Jem Matzan is the author of three books, a freelance journalist and the editor-in-chief of The Jem Report.

Gentoo Linux