endperform.org

I was inspired to write this based on an idea over at the Ubuntu Brainstorm. The idea was to add X11 and graphical configuration tools to the Ubuntu Server install. The main reason, the poster said, was to get more switchovers from Windows 2003, and allow for less mistakes when a server is set up. I don’t really agree with this sentiment. Personally, my feelings on Linux servers is based on real life experience. I feel that you should know something about configuring your server via the configuration files before deploying your server. Why? Consider the following scenario:

Bob is typically a Windows server administrator, but he’s heard about Ubuntu Server Edition with Gnome and managed to get his boss to agree to allowing him to install a box to host an instance of a popular web application. Bob is familiar with GUI configuration tools since he’s coming from a Windows background, so he figures he can install this machine pretty easily. Bob starts to configure the server using some of the nice GUI utilities provided. He then decides he wants to reboot the machine to make sure the changes he made continue to work. Much to Bob’s chagrin, his beloved GUI doesn’t come back up. Unfortunately while mucking with the configuration, Bob disabled GDM, and thus disabled his GUI. Bob now has a black screen with a login prompt. Bob may know enough to log in, thinking his GUI comes back up, but he finds that he’s at another prompt: [bob@server:/home/bob]$ Since Bob is unfamiliar with Linux, he now has to spend time trying to figure out what he needs to do to get his GUI up and running.

Now, what would happen if something failed on that server and the GUI couldn’t be restarted easily? Bob would have no clue as to where to start, and would have to find someone to help. I had a similar experience back up in PA where someone had messed with some settings via a GUI on a Linux server and inadvertently disabled X and changed permissions on key files. Ever since then, I’ve advocated X-less server installs. In my mind, if you deploy a server, you should know what to do in the case of a failure and not rely solely on GUI tools to hold your hand throughout an installation. Maybe I’m too old-school or just short-sighted, but I feel that if you’re going to run a Linux server, you best at least know where to find configuration files and how to navigate via the terminal.

Don’t get me wrong, GUI admin tools do make life easier, but one should really know the underlying configuration before rolling a server out into production.

I’ve decided that I’m going to move back to Ubuntu from Arch. Arch is a great distribution, but there are some packages that aren’t built yet, and even with AUR sometimes they don’t build correctly. I think I’ll be able to get a relatively clean system if I start out with the Ubuntu server install and build from there, but I’m not sure exactly which way I’m going to go yet.

Last post, I pointed out a thread going on in Ubuntu concerning the confusion of the file system, and how it should be changed. It’s a topic that has been discussed before, and there is one distribution that has gone ahead with it’s own layout. The main point of argument (later in the thread) seems to be that the file structure *needs* to change because it’s causing confusion among the users. I’m not for this change at all. Not because I’m an oldschooler, but because I feel it would cause a lot more problems.

The Filesystem Hierarchy Standard (link below) was set up a while back in order to keep things across distributions uniform. Breaking this standard would break a lot of things, such as the ability to download a source package and be able to compile it without changes to the make / install files. Upstream packages from the likes of KDE, Gnome and other vendors would need to be reconfigured, requiring more time from the Ubuntu developers and possibly introducing new bugs. Downloading and installing from source would now become an issue. The make and install files would need to be changed prior to installation, or developers would have to release a special Ubuntu source version, or a new “conversion” utility for Ubuntu would need to be written.

A new structure would mean a lot of re-learning for current users, and cause headaches for system admins. That headache may cost Ubuntu market share in the server realm, especially in multi-platform environments. I would much rather know that if I’m on Redhat or Ubuntu, generally system settings will be living under /etc, where if this change were to happen, settings might live in /etc on RedHat but under /system/settings in Ubuntu. I work on multiple Unix / Linux systems daily, and they are pretty uniform when it comes to directories. I’m sure a lot of system administrators would not want to re-learn file structure just for one distribution; They would go with what they know works.

In the forum thread (link below), one person mentioned that this should be a simple change. I feel that either this person is nuts, or just doesn’t understand the gravity of the change to be made. A few of the comments even suggest that the reason for the change is lack of courage. Is it really a lack of courage to keep a distribution somewhat compatible with the software used to build said distribution, than risk losing users and server installs for the sake of directories?

Another user likened the current file system to a desk with everything on top and no organization whatsoever. That’s really untrue. If that were the case, I would see all of the files sitting in /. Personally, I think the whole issue boils down to a matter of personal opinion, which it really is. That’s what this is. My opinion and thoughts on the matter. Could the problems be resolved during implementation of this new file system? Perhaps, but at the cost of time. Development resources would be committed to working on implementing this new structure rather than fixing existing issues for the next version of Ubuntu. I would much rather see the time spent on something that truly needs fixing rather than something that is perceived to need fixing.

Links:

• Filesystem Hierarchy Standard
• Ubuntuforums thread

Unison is a nifty utility that allows you to keep directories and files in sync across separate machines. It is pretty configurable, and I’ll walk you through how to set it up using my setup as the example.

Install and Configuration
Installation is straight-forward in Ubuntu. A simple sudo apt-get install unison will do the trick. Once installed, you need to go about creating a configuration file, which is ~/.unison/default.prf. Below is a copy of my configuration file from the laptop:

# General prefs
logfile = /home/fubar/.logs/unison.log

root = /home/fubar
root = ssh://scooby//home/fubar

# Paths to keep in sync
path = projects
path = personal
path = mail
path = photos
path = .mutt
path = .getmail
path = archive
#path = media/music

# Individual files
path = .muttrc
path = .procmailrc
path = .vimrc

# Some regexps specifying names and paths to ignore
ignore = Name temp.*
ignore = Name *~
ignore = Name .*~
ignore = Name *.o
ignore = Name *.tmp
ignore = Name {,.}*{.lock}
ignore = Path projects/.metadata

Here’s a breakdown of the parameters:

logfile - Path and filename of the logfile.

root - Defines the root path to keep in sync. The first root entry is for the local machine. The second root entry points to the desktop’s home directory, connecting via SSH. For information on connection options can be found on the Unison website.

path - Define the path to keep in sync, relative to the root. These entries can be directories and files. I use both, as you can see.

ignore - Tells Unison what files to ignore. Useful if you don’t want to sync temporary files.

Running Unison
With configuration complete, it’s time to fire up Unison. From a terminal, type unison and press enter. Unison enters interactive mode and attempts to connect to the remote machine. It first checks the defined paths to determine if any files have been changed, added or deleted, after which it will present you with a prompt, asking what you’d like to do. In most cases, the default action will suffice, but sometimes Unison may not be sure, so you’ll need to specify which file to use. The prompts are straight-forward, and help is available.

Unison can also be run in a batch mode, but I won’t cover that here since I do all of this interactively.

Wrapping up
I use unison to keep my mail, pictures and projects in sync since I use both machines on a regular basis. It also ensures that I have a backup of my important files on another machine in case of failure. It’s a useful utility, and I recommend it.

Unison website: http://www.cis.upenn.edu/~bcpierce/unison/

For the longest time, I wasn’t a big fan of creating a /home partition on my Linux installs. I figured, why bother? But when I made the switchover to Ubuntu from Gentoo, I decided to go ahead and make a separate home partition on my desktop, and let me say I’m glad I did so. Yesterday I managed to screw up my Ubuntu install by forcing an upgrade. Herein lies why the developers warn against using a pre-release… things tend to break. Originally, I was going to try to save the install, but after thinking about everything I had installed over the course of the past few months, I figured a fresh install of Gutsy would be in order.

During the installation, I performed partitioning manually so I could insure my home partition (which is actually a separate 250GB drive) would not get wiped out. Once partitioning was completed, the installation moved on without a hitch, and I’m back up and running. The beauty of all of this is that I didn’t lose any data or custom configuration options. All I had to do was reinstall the software I used and I was back in business. I had all of my Firefox settings and bookmarks, my Fluxbox settings, my scripts and my data, all back and ready to go. Obviously, this is not a substitution to regular backups, but in the event that you would need to reinstall, a home partition will save you some work.

Additionally, I decided to start using KDE again. Why? I wanted a switch, and KDE has a special place in my geeky heart. I figured I’d go with it for a while and see what happens. It’s pretty snappy, and right now I’m not really missing Fluxbox. I’m also pretty tempted to try to install KDE 4 and play with it, but I might save that for a later time.