Switching between the KDE and GNOME window managers on Centos and Fedora Linux hosts

I recently switched a Fedora host from the GNOME window manager to KDE. This exercise allowed me to familiarize myself with how X and the various window managers are organized on Fedora hosts, and I thought I would jot down how to switch between window managers for future reference.

When a Fedora host is booted into run-level 5, the following initab entry will cause the X server and Window manager to start:

# Run xdm in runlevel 5
x:5:respawn:/etc/X11/prefdm -nodaemon

The prefdm script uses the /etc/sysconfig/desktop file to control which window manager (KDE or GNOME) is started, as you can see in the following code snippet from the script:

preferred=
if [ -f /etc/sysconfig/desktop ]; then
        . /etc/sysconfig/desktop
        if [ "$DISPLAYMANAGER" = GNOME ]; then
                preferred=gdm
        elif [ "$DISPLAYMANAGER" = KDE ]; then
                preferred=kdm
        elif [ "$DISPLAYMANAGER" = XDM ]; then
                preferred=xdm
        fi
fi

So to set the default window manager to GNOME, you can set the DISPLAYMANAGER variable to GNOME:

$ echo “DISPLAYMANAGER=GNOME” >> /etc/sysconfig/desktop

To use KDE, you can set the DISPLAYMANAGER variable to KDE:

$ echo “DISPLAYMANAGER=KDE” >> /etc/sysconfig/desktop

I dig the fact that Fedora and CentOS Linux servers control application settings through configuration files in /etc/sysconfig. This makes it easy to adjust application settings, and ensures that a package update won’t whack your customizations! Nice!

Using the ssh config file to set specify remote usernames

I periodically need to access remote systems using different userids (I didn’t have control over the account creation process, and unfortunately LDAP isn’t in use :( ). While I could use the username@host syntax to specify a userid, I find it easier to list the userids in the .ssh/config configuration file. Here is a sample configuration I use on one of my systems:

Host *.dss.prefetch.net
  ServerAliveInterval 60
  User rmatt

Host *.ext.prefetch.net
  Compression yes
  ForwardX11 yes
  IdentityFile ~/.ssh/id_dsa_ext
  User matty

The User directive can be applied to each Host configuration stanza, which allows you to specify a unique userid for each host (or group of hosts) you connect to. There are a number of cool SSH options, which are documented in the ssh_config(5) manual page. Nice!

Restarting X and the GNOME window manager on Linux hosts

I useGNOME as my primary desktop at work, and periodically need to restart the Xserver / windowing environment to pick up new changes. If I have an X environment up and running, I will send a cntrl + alt + backspace to restart the X server. If for some reason I’m not able to send the key sequence above (this isn’t feasible if I’m logged in remotely), I will run the telinit command to switch to run level 3 (multi user mode w/o X), then execute it a second time to switch back to run level 5 (multi user mode w/ X):

$ telinit 3

$ telinit 5

The latest GNOME bits are pretty slick, though I’m starting to dig KDE again (I used to use KDE years ago). I plan to share my experience with the latest KDE bits in a future post.

Monitoring traffic across a Solaris 802.3ad link aggregation

I manage a number of Solaris hosts that push a fair amount of data each day. These servers utilize Solaris 802.3ad link aggregations, which contain anywhere from 4 to 8 physical NICs. Monitoring the bandwidth across the links in an aggregation is a snap with Solaris, since most of the dladm subcommands support the “-s” (show statistics) option:

$ dladm show-aggr -s -i 2 1

key:1		ipackets   rbytes       opackets   obytes       %ipkts  %opkts
 	Total	355021     531533375    60288      4944021     
	nxge0	166090     249992028    0          0              46.8     0.0  
	nxge1	120638     179830318    0          0              34.0     0.0  
	nxge4	16         1172         25728      2109696         0.0    42.7  
	nxge5	68277      101709857    34560      2834325        19.2    57.3  

key:1		ipackets   rbytes       opackets   obytes       %ipkts  %opkts
 	Total	344131     513180425    47543      3900596     
	nxge0	167398     250160702    12         1672           48.6     0.0  
	nxge1	95286      142041090    8          1330           27.7     0.0  
	nxge4	17         1320         21601      1771571         0.0    45.4  
	nxge5	81430      120977313    25922      2126023        23.7    54.5  

In the example above, dladm printed the number of bytes and packets received for each link in the aggregation that was created with key number 1. While not quite as awesome as nicstat, the statistics option is handy for getting a quick overview of the number of packets and bytes traversing each link.

Securing Linux file systems that don’t contain executables

Linux comes with a slew of mount options, several of which are useful for locking down what can and can’t happen inside a file system. Three options I find super useful are noexec, nosuid and nodev. The noexec option disables execution for files that reside within a file system, nosuid disables execution of setuid executables inside a file system, and the nodev option instructs the file system not to interpret character or block special files. These options make a lot of sense for file systems such as /tmp, /home and /var, since these file systems typically don’t need to contain executables or device files. To set these options for ext3 file systems, you can add the options to the fourth field in /etc/fstab. Here is an example for /tmp:

/dev/sda4 /tmp ext3 noatime,nodev,noexec,nosuid 1 2

While not the holy grail of security, this small change can enhance security by forcing executables to live in well known locations. In a follow up post, I’ll describe how selinux can assist with limiting what well known executables can do.

Making sense of cron in Centos and Fedora Linux

CentOS and Fedora Linux use a set of directories in /etc to control when jobs run. These directories take the following form:

/etc/cron.hourly – jobs that run once per hour
/etc/cron.daily – jobs that run once per day
/etc/cron.weekly – jobs that run one per week
/etc/cron.monthly – jobs that run once per month

To add a job to run hourly, daily, weekly or monthly, you can drop an executable shell script in the pertinent directory. I recently became curious which time of the day daily jobs execute, which day weekly jobs run, and when monthly jobs were scheduled. The answer to these questions comes in the way of /etc/crontab, which contains crontab formatted entries that call the run-parts script to invoke the scripts in the hourly, daily, weekly or monthly directory:

$ more /etc/crontab

SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
HOME=/

# run-parts
01 * * * * root run-parts /etc/cron.hourly
02 4 * * * root run-parts /etc/cron.daily
22 4 * * 0 root run-parts /etc/cron.weekly
42 4 1 * * root run-parts /etc/cron.monthly

If you are familiar with the crontab format, it’s easy enough to decode this information to figure out the days and times when cron jobs will run. Nice!