"DEFROUTE" in RHEL, CentOS or Fedora - a usage case for eth0

Here is the situation: There is a user with a remote office that includes networking equipment like printers, backup server etc. He uses a company provided CentOS laptop as the gateway for his network via a cell card since there is no other cheaper option available to get him connected. He travels with the laptop often and I don't need access to the equipment at his office unless he's there. The user always connects either via WIFI or a cell card for VPN connection depending on what is available. The laptop is running openvpn and is connecting to our company's openvpn server. No problem... until I want to also connect the laptops ethernet cable and use NetworkManager and use a DHCP server for the eth0... That's when the VPN drops and the laptop now has an incorrect default route. What's odd is that order of interface startup does not matter... dhcp on eth0 wins no matter what... bummer.


What's happening? Well, normally with DHCP, the client is given a default route as part of the information exchange. That eth0 default route takes over. It's just that simple... unless you give the networking system guidance on what to do in the form of the "DEFROUTE" option. The option has been around for a long time. The current Red Hat Enterprise Linux 6 Deployment Guide has DEFROUTE option hidden in the 8.2.4. Dialup Interfaces section. Here is a chunk of the information from the guide:

DEFROUTE=answer

where answer is one of the following:

• yes — Set this interface as the default route.
• no — Do not set this interface as the default route.         

In the past, I did not use the DEFROUTE option. I found that I could just statically assign the eth0 and *not* let NetworkManager have access to it (NM_CONTROLLED=no). In fact with Centos (and the like), NM seems to get disabled as a generally rule.

Also, if this was a server or I wanted to statically assign the interface, it would not be an issue. Just one of those fringe usage cases.

LTSP 5.2.x rsh server on client install, setup and HOWTO

Don't start with the, "rsh is bad..." message. I know, I know! It's an internal test network and was just easy to do for remote client checking. Besides, the "ltsp-localapps" only works for the logged in user and does not allow for arbitrary root user interaction with the client. If there is a built-in way to do this, let me know. At some point, I may try sshd client setup.

I am using CentOS 6.x as the server OS and customize the client build to be CentOS 6.x also. LTSP 5.2 is the software from k12linux at fedorahostedI don't think that affects the directions below in any way, however. And if this looks like part of a script, you would be correct.

Change the LTS_HOME variable to your own LTSP client build location on the server as required:

export LTS_HOME="/opt/ltsp/i386"

Check to make sure rsh is allowed in securetty for the client:

grep -q "^rsh" $LTS_HOME/etc/securetty && echo rsh >> $LTS_HOME/etc/securetty

Get rsh-server installed into you chroot'd environment:

Option 1 (re)creates the client build to have rsh-server instaled and includes future builds:

edit the "/etc/ltsp/kickstart/Fedora/common/release/el6.ks" and add "rsh-server" *before* the "%end" line. Then (re)run the ltsp-build-client and ltsp-server-tweaks as if a new install:

ltsp-build-client 2>&1 |tee /tmp/ltsp-build-client.out-`date +%Y%m%d%H%M`


cd $LTS_HOME

setarch i386 chroot .


chkconfig rsh on

ltsp-server-tweaks

Option 2 install and setup the rsh-server for this client build only:

cd $LTS_HOME

setarch i386 chroot .

mount -t proc proc /proc

#set proxy if needed

yum install rsh-server

chkconfig rsh on

umount /proc

Get the clients /root to be based on the $LTS_HOME/root from the server and not a tmpfs by commenting the "/root" line of k12linux.rwtab:

sed -i 's/^empty[[:space:]]\/root/#empty\t\/root/'$LTS_HOME/etc/rwtab.d/k12linux.rwtab

OR for you perl peeps

perl -p -i -e "s/^empty\t\/root/\#empty\t\/root/g" $LTS_HOME/etc/rwtab.d/k12linux.rwtab

Note: To safeguard your custom options from accidental rpm update overwrites, please consider creating your own blah.ks file to be referenced in /etc/ltsp/ltsp-build-client.conf.

Properly create a .rhosts file for the clients root user. This script chunk assumes the primary (eth0) interface is the interface that communicates with the clients. If your primary server interface is not the interface for client connection, you will need to add/modify the client's .rhosts file accordingly:

echo "server-`hostname --ip` root" >> $LTS_HOME/root/.rhosts
echo "rsh" >> $LTS_HOME/etc/securetty
chmod 600  $LTS_HOME/root/.rhosts

Now boot the client and test an rsh command from the server to the client. If you have issues, you will want to add a "shell" option for the client in the correct lts.conf then reboot the client. For i386 arch, the file is "/var/lib/tftpboot/ltsp/i386/lts.conf". This will give you a chance to see the /var/log/messages file if you have not setup remote logging for the client.

To make a custom PXE boot logo change, create/modify a theme run the following command from within the chroot:
ltsp-rewrap-latest-kernel

To apply a new theme
Create a new plymouth theme. You can do this by making simple variations on the stock theme by taking a copy of the default theme using the procedure below. You can replace "newtheme" in the commands below with whatever name you want to give the new theme. This procedure assumes the chroot is in the /opt/ltsp/i386 directory.

Start by copying the folder with this command:

cp -a /opt/ltsp/i386/usr/share/plymouth/themes/solar /opt/ltsp/i386/usr/share/plymouth/themes/newtheme

Now modify "newtheme" as appropriate. First go into the new theme directory by typing:

cd /opt/ltsp/i386/usr/share/plymouth/themes/newtheme

Then rename the .plymouth file by running:

mv rings.plymouth newtheme.plymouth

Edit the .plymouth file and change:

Name=Rings

to:

Name=Newtheme

and change:

ImageDir=/usr/share/plymouth/themes/rings

to

ImageDir=/usr/share/plymouth/themes/newtheme

You may also want to change the background colors. BackgroundStartColor is the color at the top of the screen and BackgroundEndColor is the color at the bottom of the screen. Plymouth will make a gradient of these colors across the screen. For example to make the background change from white to black change the lines:

BackgroundStartColor=0x080808
BackgroundEndColor=0x080808

to:

BackgroundStartColor=0xffffff
BackgroundEndColor=0x000000

When finished making changes save the file.

Next replace the image file named header-image.png with the desired replacement. Do not change the name of this file!

The exact size does not seem to matter as the plymouth will center it in the screen above the animated "rings".

You can also get fancy and replace all the other progress images also.

Chroot to the client directory by running:

chroot /opt/ltsp/i386

Activate the new theme with this command:

plymouth-set-default-theme newtheme

Note: you may get an error from sed (ex: sed: warning: failed to set default file creation context to unconfined_u:object_r:usr_t:s0: No such file or directory). This does not seem to cause problems.

Build a new initramfs file with the new theme:

ltsp-rewrap-latest-kernel

Exit the chroot by typing:

exit

and update the tftp directory with the new initramfs by typing:

ltsp-update-kernels

If you use NBD you will also need to run:

ltsp-update-image

Now fire up a client and enjoy the new theme!