Retrospectives
By Jim Dennis
Introduction
I've been thinking about doing a new column for Linux Gazette for a few months now. Of looking back to our first issues, reading them with an Epimethean perspective. (Epimetheus, of Greek Mythology, was brother to Prometheus --- his counterpart; while Prometheus could see into the future, Epimetheus had perfect "hindsight").
So that's what this will be. It seems fitting somehow that we should start the new regular column at issue 100, reminiscent of the long running column in Scientific American for "50 and 100 Years Ago." Of course such number are completely arbitrary.
In future issues I might cover multiple back issues; or look for threads that wove their way through a history of discussion.
In most cases I will be looking for things that have changed; updates that need to be voiced. However, I expect that most of each issue is still relevant; that only minor retrospective commentary would be needed.
In this issue we'll be looking back at the very first issue of Linux Gazette.
Long Live Slackware
John Fisk was trying Slackware 2.0.0, had been using a 2400 baud dial up to get to the 'net via a VAX/VMS account. The first version of Slackware I used was version 1.0 --- I'd been using the now forgotten SLS (Soft Landing Systems) and Yggdrasil's "Plug & Play Linux" before then and had ignored Slackware's pre-releases.
Slackware is still maintained and is now up to version 9.1 --- and the project is still headed by Patrick Volkerding.
John's install was only 120Mb.
For comparison, modern Red Hat and Fedora installations require a minimum of 250Mb just for the root filesystem! However, a reasonably minimal Debian can reasonably fit in well under 120Mb; so we can't complain that Linux as a whole has become bloated.
Long Live our PPP Connections
He presents a simple PPP "keepalive" shell script. (Could use the persist directive with a modern pppd but some still might need something like the shell script)
while [ -e /var/run/ppp0.pid ]; do
ping -c 1 $REMOTE_ROUTER > /dev/null
sleep $DELAY
done
Another approach would be:
ping -i $DELAY $REMOTE_ROUTER 2>&1 > /dev/null &
PINGPID="$!" while [ -e /var/run/ppp0.pid ]; do
sleep $DELAY
done
kill $PINGPID
... which starts one ping process that sends a ping every $DELAY seconds; then polls slowly on the pid file and, when that's gone it kills the background task. This is no great technical improvement. There's minor improvement by not spawning so many ping processes --- we only load ping once and let it run like a daemon; then kill it when we're done with it. So this alternative approach is only valuable for edification --- and example of how to manage a backgrounded task under the shell.
Long Live Our Changes to /etc/motd and /etc/issue
- (And also: Know thy system as thou would know thine own spouse!)
The next item amounts to a 2-cent tip: that Slackware (among some other distributions) have rcS scripts (rc.sysinit on Red Hat, Fedora, and related distributions) that overwrite our /etc/motd and/or /etc/issue files. So you have to comment out that code if you want your changes to these files to persist.
My 5-penny tip over the top of that is that every Linux system administrator should read their /etc/inittab file from top to bottom and recursively follow through them by applying the following procedure:
- For every filename you encounter:
- Run the file command on it
- If it's binary:
- Read the man or info pages
- Use any package manager to find out which package "owns" this program (dpkg -S or rpm -qf)
- Peruse any other docs associated with that package
- If it's a script of any sort:
- Open it up in a text editor/viewer
- Recurse
Following this procedure, you will wend your way through your entire system start-up sequence. You will know almost EVERYTHING about how your system boots up. (This ignores the possibility that you might have an initrd --- and initial RAMdisk, with a /linuxrc script or binary embedded in it).
As part of my LPI classes I teach this procedure and recommend that all students do this for each new distribution that they ever try to manage.
Twiddle Dee Dum: Home at Last
In the next article we see our first 2-cent tip. ~ (the "tilde" or "twiddle" character) is expanded by the shell to the current user's home directory. I'd add that ~foo will look up the home directory for the user "foo" and expand into that path. This notion of "look up" can actually be quite involved on a Linux system --- though it usually just means a search through the /etc/passwd file. On other systems it would entail NIS, LDAP, Hesiod, or even MS Windows "Domain" or "Active Directory" operations. It all depends on the contents of the /etc/nsswitch.conf and the various /lib/libnss* libraries that might be installed.
Shell Tips, Tricks, Aliases and Custom Functions
The aliases he lists are all still valid. I might add another tip to point to Ian MacDonald's bash programmable completion project which is now shipped as examples with the GNU bash sources; and is thus installed on many Linux distributions by default. To use them, simply "source" the appropriate file, as described in Ian's article under "Getting Started." Ian's article has many other tips and tricks for bash and for the readline libraries against which it's linked. (On my Debian systems Ian's bash completions are in /etc/bash_completion).
In his next article John also talks about bash custom functions. A nitpick and CAVEAT is appropriate here. The version of bash that was in common use back then would accept all those shell functions as he typed them. However, newer versions of bash 2.x and later, require that we render them slightly differently:
# Now, some handy functions...
tarc () { tar -cvzf $1.tar.gz $1 ; }
tart () { tar -tvzf $1 | less ; }
tarx () { tar -xvzf $1 $2 $3 $4 $5 $6 ; }
popmail () { popclient -3 -v -u myname -p mypassword -o /root/mail/mail-in any.where.edu ; }
zless () { zcat $* | less ; }
z () { zcat $* | less ; }
... all we've done is insert semicolons before those closing braces. This is required in newer versions of bash because it was technically a parsing bug in older versions to treat the closing brace as a separator/token. We could also have simply inserted linebreaks before the closing braces. (To understand this consider the ambiguity caused by: 'echo }' --- historically the } did not need to be quoted like a ')' would be. if that doesn't enlighten you just accept it as a quirk and realize that these old examples from 1995 must be updated slightly to run on newer versions of bash).
Zounds!!! Zany Sounds
In the next article the old links to sunsite.unc.edu are ancient and obsolete. The sounds to which he was referring can still be found at:
... which is has all the old sunsite.unc.edu contents after two name changes (it was metalab.unc.edu for awhile, too).
Alas I couldn't find the "Three Stooges" sounds at the ibiblio site; but a quick Google search suggests that we can get some audible zaniness at:
/etc/fstab for Filesystem Aliases
His article on /etc/fstab entries, particularly for "noauto" devices like CD-ROMs and floppies is still relevant. Essentially nothing as changed about that. Some new distributions have programs like magicdev which run while you're logged into the GNOME or other GUI, polling the CD-ROM drive to automatically mount any disc you insert (and to detect the type and optionally dispatch music players for audio CDs or launch file browsers for file CDs, etc). Personally I detest these automount features and disable them as soon as I can find the relevant GUI control panel.
I'd still consider this to be a 2-cent tip of sorts.
Long Live Backups and Version Control!
For the next article (about making serialized backups of files before editing them) I'd simply suggest using RCS or CVS. RCS is installed with most Linux distributions. To use it, simply create an RCS directory under any directory in which you wish to maintain some files in version control. Then every time you're about to edit a config file therein, use the command: ci -l $FILENAME; the file will be "checked in" to the RCS directory. This will automatically track each set of changes. You can always use the rcsdiff command to view the differences between the current version and the most recent --- or between any arbitrary version by using the appropriate -r switches. CVS is basically similar, but allows you to maintain a centralized repository across the network --- optionally using securely authenticated and encrypted ssh tunnels. The advantage of tracking your files under CVS is that you can restore your settings and customizations even after you've completely wiped the local system (so long as you've maintained your CVS repository host and its backups).
Tutorials for CVS and RCS:
... there are several others on the web; Google for "RCS tutorial" or "CVS tutorial".
I'd also suggest that some of us look at the newly maturing Subversion at:
... which just attained the vaunted release version 1.0 this month.
In the next article: "Accessing Linux from DOS" I notice that the old link for the LDP still works (graciously redirecting us from the old sunsite.unc.edu/mdw/ URL to the current ibiblio LDP mirror). Historical note: MDW are Matt Welsh's initials! Of course the current canonical location for the LDP (Linux Documentation Project) is now:
As for the EXT2TOOL.ZIP link, it's dead. However, a quick perusal of Freshmeat suggests that anyone who needs to access ext2/ext3 filesystems from an MS-DOS prompt might want to use Werner Zimmermann's LTOOOLS package ( also at: http://www.it.fht-esslingen.de/~zimmerma/software/ltools.html Professor Zimmermann's home page). LTOOLS is the MS-DOS counterpart to the mtools package for Linux.
Apparently the LTOOLS package includes a "web interface" (one utility in the package and serve as a miniature web server for the MS Windows "localhost") and it include a Java GUI as well. LTOOLS allegedly still supports MS-DOS, but also have features for later Microsoft operating systems like '95/'98, NT, ME, XP, and Win 2000. It's also apparently portable to Solaris and other versions of UNIX (So you can access your ext2 filesystems from those as well).
mtools allows Linux users to access MS-DOS filesystems, mostly floppies, but also hard drive partitions, using commands like: mcopy a:foo.zip . or mtype b:foo.txt or just mdir (defaults to the A: drive, /dev/fd0 on most installations). mtools has been included with mainstream Linux distributions for most of the last decade, and has been available and widely used on other versions of UNIX for most of that time as well. However, when I'm teaching my LPI courses I still find that its new to more than half of the sysadmins I teach. The principle advantages of mtools are: you don't have to mount and unmount the floppies; you can mark it SGID group "floppy" and set the privileged=1 flag in /etc/mtools.conf to allow users to access MS-DOS filesystems on floppies from their own accounts (without sudo etc).
The last article in this premier issue was one on building a Linux kernel. The basic steps outline there have remained true for the last eight years. Today we use bzImage instead of the old zImage make target. Also, I usually use:
make menuconfig; make dep make clean bzImage modules modules_install install
... and now, with the recent release of the 2.6 kernels we'll be dispensing with the "make dep" step (which was used to make or modify sub-Makefiles among other things). Also the new 2.6 kernel builds are, by default, very quiet and clean. Try one to see what I mean!
Another minor change: newer kernels can no longer be booted raw from floppies. As of 2.6 Linux always requires some sort of boot loader (SYSLINUX, GRUB, LILO, LOADLIN.EXE, etc). The rdev command is basically useless on modern kernels (though one might still use its other features to patch in a default video mode, for example). This isn't a major issue as almost everyone has almost always used a bootloader through the history of Linux; the ability to pass kernel command line parameters is just too bloody indispensable! Of course Linux kernels on other architectures such as SPARC or PowerPC have their own formats and bootloaders.
Conclusion
Overall most of the content of this old issue, almost nine years ago, is still usable today. In less than 3 pages I've summarized it and pointed out the few things that have to be considered when using this information on modern systems, updated a few obsolete URLs, and just pointed to some newer stuff in general.
That doesn't surprise me. Linux follows the UNIX heritage. Things that people learned about UNIX 30 years ago are still relevant and useful today. Things we learned about Linux 10 years ago are now relevant on new Mac OS X systems. The legacy of UNIX has spanned over half of the history of electronic computing.
Jim is a Senior Contributing Editor for Linux Gazette, and the founder of The Answer Guy column (the precursor to The Answer Gang).
Jim has also worked in other computer roles, and also as an electrician and
a crane truck operator. Jim has also worked in many other roles. He's been a
graveyard dishwasher, a janitor, and a driver of school buses, taxis, pizza
delivery cars, and even did some cross-country, long-haul work.
He grew up in Chicago and has lived in the inner city, the suburbs,
and on farms in the midwest. In his early teens he lived in Oregon--
Portland, Clackamas, and the forests along
the coast (Brighton). In his early twenties, he moved to
the Los Angeles area "for a summer job" (working for his father, and learning
the contruction trades).
By then, Jim met his true love, Heather, at a
science-fiction convention. About a year later they started
spending time together, and they've now been living together for
over a decade. First they lived in Eugene, Oregon, for a year, but now they
live in the Silicon Valley.
Jim and Heather still go to SF cons together.
Jim has continued to be hooked on USENET and technical mailing
lists. In 1995 he registered the starshine.org domain as a birthday gift to
Heather (after her nickname and favorite Runequest persona). He's participated
in an ever changing array of lists and newsgroups.
In 1999 Jim started a book-authoring project (which he completed
after attracting a couple of co-authors). That book Linux System
Administration (published 2000, New Riders Associates) is not
a rehash of HOWTOs and man pages. It's intended to give a high-level
view of systems administration, covering topics like
Requirements Analysis, Recovery Planning, and Capacity Planning.
His book intended to build upon the works of Aeleen Frisch
(Essential Systems Administration, O-Reilly & Associates) and
Nemeth, et al (Unix System Administrator's Handbook, Prentice
Hall).
Jim is an active member of a number of Linux and UNIX users' groups
and has done Linux consulting and training for a number of companies
(Linuxcare) and customers (US Postal Service). He's also presented
technical sessions at conferences (Linux World Expo, San Jose and
New York).
A few years ago, he volunteered to help with misguided technical
question that were e-mailed to the editorial staff at the Linux
Gazette. He answered 13 questions the first month. A couple
months later, he realized that these questions and his responses had
become a regular column in the Gazette.
"Darn, that made me pay more attention to what I was saying! But I
did decide to affect a deliberately curmudgeonly attitude; I didn't
want to sound like the corporate tech support 'weenie' that I was
so experienced at playing. That's not what Linux was about!"
(
curmudgeon means a crusty, ill-tempered, and usually old man,
according to the
Merriam-Webster OnLine dictionary.
The word hails back to 1577, origin unknown, and originally meant miser.)
Eventually, Heather got involved and took over formatting the column,
and maintaining a script that translates "Jim's e-mail markup hints"
into HTML. Since then, Jim and Heather have (finally) invited other
generous souls to join them as The Answer Gang.
![[BIO]](../gx/2002/note.png)
Jim has been using Linux since kernel version 0.97 or so. His first
distribution was
SLS (Soft Landing Systems). Jim taught
himself Linux while working on the technical support queues at
Symantec's Peter Norton Group.
He started by lurking alt.os.minix and alt.os.linux on USENET
netnews (before the creation of the comp.os.linux.* newsgroups), reading them
just about all day while supporting Norton Utilities, and
for a few hours every night while waiting for the rush-hour traffic to subside.
