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
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:
if [ -f /etc/sysconfig/desktop ]; then
if [ "$DISPLAYMANAGER" = GNOME ]; then
elif [ "$DISPLAYMANAGER" = KDE ]; then
elif [ "$DISPLAYMANAGER" = XDM ]; then
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!
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:
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!
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.
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.
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.
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
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!