ALINK="#FF0000">

"Linux Gazette...making Linux just a little more fun!"


The Answer Guy


By James T. Dennis, jimd@starshine.org
Starshine Technical Services, http://www.starshine.org/


Contents:


 Faxing and Dialing Out on the Same Line

From: Carlos Costa Portela c.c.portela@ieee.org

Hello, Linux Gazette!
First of all, let me say you that the Gazette is EXCELLENT! Well, you probably know that, but I must say it!. I have the next problem:
I am using the fax program efax, by Ed Casas. Really good!. When my system starts, I put the fax in answer mode:

This is the entry in the inittab file: rf:3:respawn:/bin/sh /usr/bin/fax answer

 Another option here would be 'mgetty' -- which provides dial-in (terminal, PPP, etc) and fax support on the same line. Allegedly the 'vgetty' extension to 'mgetty' will even allow limited "voice" support on that same line (although the only modem that's currently supported seems to be certain Zyxel models -- none of the other modem manufacturers seem to be willing to release the API's for voice support!).

 But sometimes a day (once or twice) I need my modem to connect to my ISP and, at least, read and send my mail!

Then there is an overlapping between one program -or command- and the other.

 This is a very common situation. That's why Unix communications programs support various sorts of "device locking."

The only trick is to make sure that all the programs on your system agree on the name, location, and type of lock files.

On a Linux box this is reasonably easy -- compile them all to use the /var/lock/ directory. The lock files will be of the form: LCK..$device (where $device is the base name of the modem device -- like 'ttyS0' or 'modem'). That takes care of the location.

My advice is to ignore everything you've heard about using "cuaXX" as the call out device and "ttySxx" as the dial-in device. I make a symlink from /dev/modem to the appropriate /dev/ttyS* node and use /dev/modem as the device name for EVERYTHING (pppd, chat, uucp, C-Kermit, minicom, efax, mgetty/sendfax, diald, EVERYTHING). Obviously that advice applies to situations where you only have one or two modems. If you're handling whole banks of modems (you're an ISP) than your situation is different (you probably don't allow much dial-out via these lines and would probably have one or more lines dedicated to fax). However, that handles the 'name' issue.

Finally there is the question of lock file "type." There are three common strategies in Unix for dealing with lock files. The first a refer to a "touch" -- the mere existence of any file by the correct name is a flag for all other processes to leave the device/resource alone. If a process dies and leaves a stale lock file -- there is not automatic recovery -- an administrator must manually remove the lock file. This limitation makes this the least useful and least common of the lockfile types.

With the other sorts of lock files the controlling process (the one creating the lock) writes its PID into the file. Any other process seeing the lock file then parses a 'ps' listing to determine the status of the process that locked the resource. If it's dead or non-existent (possibly even if it's a zombie) then the new process removes the "stale" lock file (usually with a message to that effect) and creates a new one.

Here the only question is: what format should the PID be written in? I prefer "text" (i.e. the PID is a string of ASCII digits -- like the printf("%d", int) would generate). Some programs might default to "binary" -- where the PID is written to the file in the same way that a program stores it in memory.

The advantage of text format lock files is that you can more easily write a wrapper script in perl, sh, or whatever -- to provide lock file support to a program that doesn't use the same sort of lock files you want. Another advantage is that the admin of a system can read it -- and use 'ps' or 'top' to check the state of the locking process manually (useful if a client program is overly timid about removing the lock file from a "zombie" for example).

The only other problem associated with device lock files involves the permissions of the /var/lock directory. The simple solution is to make it world writable. However I consider that to be poor administrative practice -- particularly on a multi-user or server system. You can't make this directory "sticky" (as you should with your /tmp/) unless you make all of your modem using programs SUID. If you did that, no program would be able to remove a lock file that was created by a different user -- stale or otherwise.

So, I make this directory group writable by the 'uucp' group and make all my modem using programs SGID 'uucp'. If you need finer grain support (for other programs that use the /var/lock directory) then you'd want to create more specific directories below /var/lock, and compile all of your programs to use those. On my main Red Hat (3.03) system all of the other programs that I've see use directories below /var/lock/ so only my modem programs really need write access. Obviously any root owned, or suid root or even suid 'bin' programs can also write to the /var/lock directory -- all we're doing is keeping out the "riff-raff" (like my personal shell account).

 Obviously, this is not a solution:
Turn off the modem, and then turn on.
Kill the efax process.

Because the entry has a "respawn" keyword.

What is the best way to:
- inactivate the fax.
- connect to Internet.
- disconnect.
- activate the fax.

 The best way is to avoid the problem. Configure or compile efax to use a locking mechanism that's compatible with your dial-out programs (or switch to 'mgetty' or some other enhanced getty).

The 'mgetty' home page is at:

Mgetty+Sendfax Documentation Centre (Gert Doering) http://www.leo.org/~doering/mgetty/

... and some related resources are at:

ISP Resources - mgetty info (AutoPPP) http://www.buoy.com/isp/mgetty.html

Coastal Internet - ISP Info! http://www.buoy.com/isp/

 Well, one solution is:
go to the /etc/inittab comment the line restart the system Is there a better one?.

 If you really had an insurmountable problem of this sort -- a program that just wouldn't co-exist with something that you're respawning in your inittab (like some weird UPS power daemon or data aquisition service) -- I'd solve it using a new runlevel. The line where you're loading your fax daemon process specifies that it runs in level 3 (the default "multi-user with networking" mode). So you could just use the 'telinit 4' command to switch to the (currently undefined or "custom") runlevel. This should kill the fax process (and any getty's or xdm's that you have configured for runlevel 3) and start any processes that you define for runlevel 4.

Read the man page for inittab(5) (that is "the inittab page in section section 5 of the man tree") for details. I've always been mildly surprised that the SysV Init programmers didn't put in options for a full 9 runlevels (where 7, 8, and 9 would all be custom). However I've never seen a need for such elaborate handling -- so they likely didn't either.

Hope that clarifies the whole issue of lock files and resolving access concurrency issues. You can use similar programming techniques (even in shell scripts) to resolve similar problems with directory, file, or device locking.

-- Jim


Linux and the 286

From: tbickl@inreach.com tbickl@inreach.com

Hello,
I am taking a class at community college for introduction to Unix. I was told I could download Linux, put it on the 286 machine I have, and that it would function well enough to learn from.

 You were told wrong.

 Searching thru the downloadables, I have only seen versions that will run on 386 or above, and I do not have a 386 machine available to me right now.

 Your observations are to be trusted more than the sources of your rumors.

 Do you know if and where I could find a version of Linux that would suffice?

 There is a project to produce an 8086 (and thus 286 compatible) subset of the Linux kernel (ELK -- embeddable Linux kernel). However it is probably not far enough along to be of interest to you. More generally we can say that a kernel is not enough -- there would be considerable work to porting a large enough set of tools to the subset architecture.

Moving back a little bit from Linux specifically we can recommend a couple of Unix like OS' that did run on the 286. Of them, only Minix is still widely available. It is not free (in the sense of GPL or the BSD License) -- but is included with copies of Andrew Tanenbaum's seminal text book on _Operating_Systems_Design_and_Implementation_. You'll want the 2nd Edition.

The two other implementations of Unix that have run on 286 systems are Xenix (originally a Microsoft product then handed off to SCO -- Santa Cruz Operations; which I think Microsoft still owns a good chunk of) and long since discontinued, and Coherent (by the now defunct Mark Williams Company).

Neither of these offered any TCP/IP support. I think the latest versions of Minix do -- although I don't know how robust or extensive that support is.

For the price of the book you could probably find a 386 motherboard and 16Mb of RAM to toss on it. I don't like to "push" people into hardware upgrades -- but the change from 286 to 386 is night and day.

 Like I said, it only has to function textually (textually?), no graphics or other fancies are necessary. Just regular Unix-command-line based stuff.

 The tough nut to crack isn't really the GUI -- Geoworks' Ensemble provided that (also there used to be a Windows for the 286 and Windows 3.x had a "standard mode" to support the AT). It isn't the timeslicing/multitasking (DESQview did that). It isn't providing Unix semantics in a shell and a set of Unix like tools (there's a whole directory full of GNUish tools on SimTel and there's the earlier versions of the MKS toolkit).

The hard part of running a "real" Unix on a 286 or earlier processor is the memory protection model. Prior to the 286 there was simply no memory protection mechanism at all. Any process could read or write to any address (I/O or memory) and therefore had complete control of the machine. These architectures are unsuitable for multi-user interactive systems. Unix is, at its heart, a multi-user system.

 Thank you for any help you can offer . . .

 The most bang for your buck is to buy a 386 or better motherboard. If you are in the SF bay area (Silicon Valley) I can give you one. This will allow you to run Linux, OpenBSD (or any of the other FreeBSD derivatives) and will just make more sense than spending any time or money on the 286.

If that just doesn't work for you -- get a copy of Tanenbaum's book (with the included CD). In fact, even if that does work for you, get a copy of his book. If you read that, you'll probably more about Unix than your instructors.

--Jim


 Accessing ex2fs from Windows 95

From: globus@pathcom.com

Hi:
Just wondering, is there any way (i.e. driver) in existence that would let me access ext2fs from Win95? I need read and write capabilites.

 Try the Linux Software Map (currently courtesy of ExecPC). I used just the keyword "DOS":

Have you looked at ext2tool:

Database: Linux Software Map

Title: Ext2 tools
Version: 1.1
Entered-date: 09 Jan, 96

Description:
A collection of DOS programs that allow you to read a Linux ext2 file system from DOS.

Keywords: DOS, ext2
Author: ct@login.dknet.dk (Claus Tondering)
Maintained-by: ct@login.dknet.dk (Claus Tondering)
Primary-site:
login.dknet.dk pub/ct
287706 ext2tool_1_1.zip

Alternate-site:
sunsite.unc.edu pub/Linux/system/Filesystems/ext2
287706 ext2tool_1_1.zip

Platforms:
PC with 386 or better

Copying-policy: GPL

There is also an installale filesystem for OS/2 -- but that probably won't help you much.

-- Jim


 chattr +i

From: ckkrish@cyberspace.org

Hi Jim, I was going thru the "Tips" document distributed along with Slackware 3.2. Thanks for the "chattr +i". I used to take pride that I knew Unix related stuff reasonably well, until I read about "attribute" in your snippet. If only I had read it a few weeks before! I have been running Linux for about 2 years now. Only recently I went for an upgrade. To Slackware 3.2. While exploring the set of four CD's that came in the pack, I hit upon a language called INTERCAL - a sort of crazy stuff, the antethe- sis of a good programming language. As per the documents that ac- companied it, INTERCAL was made by pundits for fun. Well, I gave a "make install" and after that the usuall commands failed! The makefile had a line to "rm -f" everything from the target "bin" directory! I really felt a need for a "chattr +i" at that time, not really aware that it already exists. Thanks for the tip. It is a lifesaver.

 You're welcome. If you're ever administering a BSD machine (FreeBSD, OpenBSD, NetBSD or the commercial BSDI/OS) you can use the chflags +syschg command for the same purpose. That requires the UFS filesystem (while Linux' chattr is exclusively for ext2 filesystems. If they ever port ext2fs to other Unix system they'll probably port the lsattr and chattr commands along with them.

There's a few other tips you should consider following -- which will also help prevent disasters. First, configure your /usr/ as a separate filesystem and mount it read-only. You can always issue a 'mount' command with the 'remount' option when you really need to write to it (which should be pretty rarely). As part of that -- make sure to consistently user /usr/local for all new software that you install. It should also be a separate filesystem which you usually leave mounted read-only. Developement should be done in home directories, additions that are not part of a distribution should be in /usr/local/ and the / and /usr/ should be almost exclusively reserved for things that came with the initial installation. (you may end up and a /opt as well -- though mine is just a symlink to /usr/local).

Following these conventions helps when you need to do an upgrade -- since you can isolate, even unmount, the portions of your directory tree that the OS upgrade should NOT touch.

The other suggestion is to avoid doing things as root. You can set the permission on /usr/local to allow write access to member of a "staff" or "wheel" or "adm" group (I like to just create one called staff) -- and add your user account to that group. You can also use also use 'sudo' and carefully chosen suidperl scripts (which are also group executable and not accessible to other) to minimize the time you spend at the root prompt.

I've read about Intercal before. It's almost as infamous as TECO (the "tape editing command") which was the language in which EMACS was originally implemented. EMACS stands for "editor macros." There is a TECO emulator for GNU emacs now -- which was obviously done to satisfy some lisp programmer's sick fascination with recursion.

Anyway -- glad my tips were helpful.

-- Jim


 Linux sendmail problem

From: Jason Moore jsmoore@brain.uccs.edu

I have a problem with my linux setup. I have a Linksys Ether16 Ethernet Card(NE2000 compat), and It finds the card fine(with the correct irg, etc..) but when it boots, the machine freezes when it's loading send mail. currently I'm using Redhat 4.2, Kernal 2.0.30, and I don't know anything about sendmail.

 Sendmail isn't really hanging. It's blocking while waiting for a DNS query to time out. If you were to leave it alone long enough it would eventually timeout and your boot process will continue.

This is because your system can't talk to a name server whereby your copy of sendmail can look up the names associated with your network interfaces (using "reverse" DNS resolution). The quick solution is to remove the symlink from /etc/rc.d/rc3.d/S??sendmail (which points to /etc/rc.d/init.d/sendmail).

I like to manage these by creating a "disabled" directory under each of the /etc/rc.d/ directories -- then I can disable any of the startup scripts by simply moving their symlinks down one directory. The advantage of this is that is is self-documenting. Also, if I have to put an entry back in -- I don't have to wonder what numeric sequence it used to be in, since this "meta information" is encoded in the symlink's name (that's what the Sxx and Kyy part of the link names are doing).

Another thing you could do is just start sendmail asynchronously. To do this just find the line in /etc/rc.d/init.d/sendmail that actually loads /usr/lib/sendmail -- and put an "&" (ampersand) on the end of the line. If you do that right then sendmail will do it's waiting (and timing out) in the background -- and the rest of your startup scripts will continue.

Obviously this last item is not a solution -- it's just a workaround. sendmail will still fail to operate properly until it's configured properly (big surprise, right?).

I'm not going to write a treatise on sendmail configuration here. First I don't have enough information about your network connections and your requirements (it would be a monumental waste of our time if you're planning on reading your e-mail from a different system, for instance). Also there are a few HOWTO's and Mini-HOWTO's and a couple of pretty decent books on the topic. Here's the HOWTO's you want to peruse:

DNS HOWTO
  How to set up DNS.    
  _Updated 3 June 1997._
http://sunsite.unc.edu/LDP/HOWTO/DNS-HOWTO.html

(Like I said -- the real problem is your DNS).

Electronic Mail HOWTO
  Information on Linux-based mail servers and clients.
  _Updated 29 November 1995. _
http://sunsite.unc.edu/LDP/HOWTO/Mail-HOWTO.html                       

(This is a bit of an overview).

 
Mail Queue mini-HOWTO
  How to queue remote mail and deliver local mail.
  _Updated 22 March 1997. _
http://sunsite.unc.edu/LDP/HOWTO/mini/Mail-Queue

(This is more specific -- and might be how you want to do your mail).

  
Offline Mailing mini-HOWTO
  How to set up email addresses without a dedicated Internet
  connection.
  _Updated 10 June 1997. _
http://sunsite.unc.edu/LDP/HOWTO/mini/Offline-Mailing

(This is another way you might want to do your mail).


ISP Hookup HOWTO
  Basic introduction to hooking up to an ISP. 
  _Updated 9 December 1996. _
http://sunsite.unc.edu/LDP/HOWTO/ISP-Hookup-HOWTO.html

(Your e-mail almost certainly has to go through some sort of ISP to get anywhere beyond your system. Reading this will determine which of the mail configuration options are available to you).

 
PPP HOWTO
  Information on using PPP networking with Linux.
  _Updated 31 March 1997. _
http://sunsite.unc.edu/LDP/HOWTO/PPP-HOWTO.html                      

(Most people are connecting to their ISP's via PPP these days. There are other sorts of connections, like SLIP and various SLIP/PPP "emulators" (like TIA))

  
UUCP HOWTO
  Information on UUCP software for Linux.
  _Updated 29 November 1995. _
http://sunsite.unc.edu/LDP/HOWTO/UUCP-HOWTO.html

(This is another way to get mail and news. It is much older than PPP and SLIP and doesn't support protocols like HTTP. UUCP is a protocol that can work over dial up modem lines, or over TCP/IP -- including PPP and SLIP. I use UUCP for all my mail and news -- because it is designed for intermittent operation and spooling. However it can be a hassle to find an ISP that's ever heard of it. Another advantage to a UUCP feed is that you can control your own e-mail address space -- every user you create on your box can send and receive e-mail and read/post news. You don't have to have to ask your ISP to do anything at their end -- and they can't charge you based on the number of addresses at your end)

Sendmail+UUCP mini-HOWTO
  How to use sendmail and UUCP together.
  _Updated 15 March 1997. _
http://sunsite.unc.edu/LDP/HOWTO/mini/Sendmail+UUCP

(In the unlikely event that you decide to go out and find a UUCP feed (or several -- it can handle that) this is what you need to configure sendmail to talk to UUCP. This isn't difficult (once you have UUCP working) -- and sendmail and UUCP have been interoperating for over twenty years. It's just that you have to pay attention to the details).

Although our whole discussion has been about 'sendmail' -- it's worth noting that there are a couple of alternatives to it available. The two that are relatively recent and readily available for Linux are 'smail' and 'qmail.' I'm not going to go into much detail about them -- but you can find out more about these at:

	smail:
		FTP Site:
		ftp://ftp.uu.net/networking/mail/smail

		Newsgroup: 
		news:comp.mail.smail

	qmail:
		http://www.qmail.org

-- Jim


 POP3 vs. /etc/passwd

From: Benjamin Peikes benp@npsa.com

The problem with that is that now that person has ftp access. Too many programs rely on /etc/passwd. What I would like is to be able to set up users on a per service basis.

 Yes -- I understood that from the get go.

 I guess what I'm looking for is a way to manage which users can use which services. i.e. put this person into a no ftp, no samba, yes mail group. I guess what I really need is to write some scripts to manage users/services.

 This is precisely the intent of PAM/XSSO. Unfortunately PAM isn't quite done yet -- it's about 60% there and can be used for some of what you want now.

Under PAM you can configure any service to require membership in a specific group. You can also limit access to specific users based on the time of day or the source of the connection -- setup ulimit's and environment values, and provide/require S/Key (OPIE) one-time passwords in some cases while allowing plaintext in others.

Under the hood you can use shadowing, pwdb (indexed/hashed account/password files) to handle large numbers of accounts (without introducing linear delays for lookups), MD5 or "big DES" to allow long passwords (some might write an SHA-1 password hashing module now that MD5 has shown some weakness).

You could write a custom SQL query client if you wanted to allow database driven access to a particular service. The advantage to PAM is that you'd write this once -- and an admin could use it on any service with no coding required.

This gives us the flexibility that previously required very localized sysadmin hacking -- to reinvent the same wheel at every site and for every service!

-- Jim


 Problem with make

Date: Thu, 25 Sep 1997 21:17:56 -0700

From: Alfredo Todini mc0736@mclink.it
Jim,

I have a strange problem with make. I have Red Hat 4.0, and I recently installed GNU make 3.76.1. The compilation went well, and the program works, except for the fact that it doesn't accept the "short" version of the command line options. For example, "make --version" works, "make -v" doesn't; "make --file" works, "make -f" doesn't. All I get in these cases is the standard "invalid option" error message. It seems to be a problem related to my particular Linux distribution: I have also tried it on a Slackware 3.2 distribution, and it worked well. The old version of make that I have removed to install the new one worked well.

Could you please help me?

 This sounds very odd. What version of GCC did you use? Did you run the ./configure script under this directory? For GNU software this behavior should be controlled by the getopt libraries (defined in your /usr/include/getopt.h) -- which I think are linked with your normal libc (C libraries).

So, are there differences between the getopt.h files between these systems? What libc's are these linked against (use the 'ldd' command to see that)? Are there differences between the Makefiles generated by the ./configure on each of these systems?

If you make the program ('make') on one system, and copy it to the other system -- do you see the same problem? How about the converse? What if each is made "statically" (not using shared libraries)?

Obviously, there are many ways to try to isolate the problem.

I just make a copy of this same version -- grabbed it from prep.ai.mit.edu, ran ./configure and make -- and tested it (in part by taking the 'make' I just built and using it to remake itself). There was no problem.

--Jim


 Swap partition and Modems

Date: Thu, 25 Sep 1997 16:50:19 -0700
From: Robert Rambo robert.rambo@yale.edu

I was wondering if it is possible to resize the swap partition in Linux. I think mine is too small, I keep getting some virtual memory problem and a friend of mine suggested changing the swap partition.

 Resizing is more trouble than its worth. You can add addition swap partitions or swap files. Must read the 'mkswap' and 'swapon (8)' man pages for details.

--Jim


 Redhat 4.2/Motif

Date: Thu, 25 Sep 1997 03:11:51 -0700
From: "Victor J. McCoy" vmccoy@kmrmail.kmr.ll.mit.edu

Ok, the details first:
Redhat 4.2 (default installation)
Redhat Motif 2.0.1
Intel p133
64 MB RAM
ATI Graphics Pro Turbo (4MB)
I think that's all the relevant info.
I'm having trouble with pppd and Motif. If I run my connection script, the Motif stops behaving properly.

Before pppd...popup menus work fine, click anywhere in client window and focus shifts.

After pppd...popups are non-existent, must click on window border to get focus.

 Are there *any* other symptoms?
This seems awfully specific -- and the PPP connection seems awfully peripheral to the windowing system.

What if you initiate the PPP session from another virtual console -- or prior to loading X? What if you use the modem for some other form of dial-up activity? (i.e. is it a particular X client application, is it something to do with the serial hardware?)

Is this an internal modem? Is it "Plug and Pray?" What if you try an external modem?

What if you connect another system with PLIP or via ethernet?

What if you use a different Window manager (other than mwm)?

I can't offer much of a suggestion. Just try to isolate it further -- try different screen resolutions, copy your xinitrc and other conf files off to somewhere else and strip them down to nothing -- etc.

You'll definitely want to post in the newsgroups -- where you might find someone who's actually used Red Hat's Motif. (I haven't -- I hardly use X -- and fvwm or twm is fine for the little that I do in it).

 I noticed the behavior quite a while back with previous versions, but I was unable to duplicate the problem (I connect to work much more often than I used to so I noticed a pattern).

Has this been trouble for anyone else? I emailed redhat, but their "bugs@" email address states not to expect an answer.

 I might even get involved in a program to provide a better support infrastructure for Red Hat.

Unfortunately that's probably months away -- and this sort of "no response" situation is likely to be the norm for RH users for a bit.

--Jim


 E-mail adjustment needed

Date: Mon, 22 Sep 1997 12:52:50 -0700
From: Terrey Cobbtcobb@onr.com

Greetings Answer Guy:
I have a problem with e-mail which you may have already deduced from the "from:" line of this letter. In brief, I am running RedHat 4.0 on a home computer. I get onto the Internet by means of a local ISP using a dynamic ppp connection. I send and read my e-mail through EMACS. Whenever I send mail to anyone, the "from:" line states that I am "root <sierra.onr.com>." Even though I always use a "reply to" header giving my actual e-mail address, it would be nice if I could configure something so that the "from" header would reflect my true identity. Any help you could give me on this would be greatly appreciated.

What you want to use is called "masquerading" in the 'sendmail' terminology. This should not be confused with IP Masquerading (which everyone outside of the Linux world calls "NAT" -- network address translation).

The other think you'll want to use is to use M-x customize or M-x edit-options (in emacs) to customize/override the e-mail address that emacs' mail readers (RMAIL VM mh-e -- whichever) will put in its headers).

--Jim


 REALBIOS?

From: Bill Dawson bdawson@abginc.com
Linux Wizard,
I am a newbie to Linux, and it has been a rocky start. Through a series of trial and error I discovered I needed to use loadlin to get started. When I ran loadlin I got this message:

"Your current configuration needs interception of "setup.S," but the setup-code in your image is *very* old (or wrong) Please use BIOSINTV/ REALBIOS or try another image file"

I looked at the reference on your page to REALBIOS, but it did not tell me where to find this program. Could you tell me where to get it and how to use it, please?

 This happens when you have a memory manager, a disk manager, or any sort of TSR or device driver that "hooks" into your BIOS controlled interrupt vectors prior to running LOADLIN.

Short Answer:
-------------
Look for the loadlin.tar.gz package -- it should include that. Here's the URL for the copy of that on sunsite:

http://sunsite.unc.edu/pub/Linux/distributions/slackware/slakware/a4/loadlin.tgz

In this file there should be a copy of a program called REALBIOS.EXE which you would run as I've described before. It would create a special "system/hidden" file in the root of your C:\ drive -- which allows LOADLIN to find all the ROM handlers for each of your hardware interrupts.

One way you might avoid the problem is to invoke LOADLIN from your CONFIG.SYS. You can do that by invoking LOADLIN.EXE from a SHELL= directive in your CONFIG.SYS.

If you're using a version of MS-DOS later than 5.0 you can create a menu of boot options pretty easily -- see your MS-DOS/Windows '95 manuals for real details. Heres a trivial example:

                 rem CONFIG.SYS

                 menuitem WIN
                 menuitem LINUX
                 menudefault LINUX

                 [WINDOWS]
                 FILES=64
                 BUFFERS=32

                 [LINUX]
                 rem Load my 2.0.30 Linux kernel
                 SHELL=C:\LINUX\LOADLIN.EXE C:\LINUX\L2030.K root=/dev/hdc1

A bit of Background:
--------------------

PC Interrupt's are similar to Unix signals or Macintosh "traps." They are a table of pointers (in the first 4K of RAM) to "handlers" (routines that process verious sorts of events -- like characters coming in from the keyboard, handshaking signals from modems or printers, or data-ready events from disk drives). Normally, under MS-DOS, many of these events are handled by the BIOS. Others are handled by DOS device drivers. Still others aren't assigned to hardware events at all. In fact most of the interrupts are reserved for "service routines" (similar to Unix "system calls").

Linux doesn't use any of these routines. Your system's BIOS is a set of machine language routines written for the processor's "real mode." All x86 processor start in real mode. Every processor since the 286 has had a "protected" mode -- which is where all of the cool extended memory addressing and other features are implemented (actually the 286 only supported 24-bit addressing -- but it's not supported by any modern operating protected mode OS, the obscure 80186 was never used as the core processor).

So, your kernel has to shift from "real mode" to "protected mode." It also has to provide low level device drivers for any device you want to access -- where it uses I/O port and DMA channels to talk to the devices. The problem is that something from real mode must load the Linux kernel.

LILO and LOADLIN.EXE:
---------------------

The two common ways to load a Linux kernel into memory are: LILO and LOADLIN.EXE.

On any PC hard disk there is a "partition table" which is how multiple operating systems can share the same disk. This was necessary because the early design o fthe PC made it very difficult to swap drives. (Using the sorts of external SCSI drives that are common on other systems -- and any sort of OpenBoot or other PROM "monitor/debugger" -- makes it pretty easy to connect external drives with alternative OS' on them -- but that would have been far too expensive for the early PC XT's (the first PC's to offer hard drives).

Throughout most of the history of the PC architecture the BIOS for most machines could only see two hard drives -- any additional hard drives required additional drivers. Furthermore these two drives had to be on a single controller -- so you couldn't mix and match (without resorting to software drivers).

Worse than that -- there were no standard drivers -- each manufacturer had to write their own -- and none of them followed an particular conventions.

None of this matters to us, once we get the Linux kernel loaded, because Linux will recognize as many drives and devices as you attach to it (assuming you compile in the drivers or load their modules).

However, it does matter *until* we get our kernel loaded. With LILO this basically requires that we have our kernel somewhere where the BIOS can reliably find it from real mode. With LOADLIN we have a bit more flexibility -- since we can put the kernel anywhere where DOS can find it (after any of those funky drivers is loaded).

The partition table is a small block of data at the end of the master boot record (the MBR). It's about 40 bytes long and has enough for 4 entries. These are your "primary" partitions. One of them may be marked "active" that is will be the partition that is "booted" by default. One of the partitions may be an "extended" partition -- which is a pointer to another partition table on the same hard disk. The rest of the MBR (512 bytes total) which precedes the partition table is a section of real mode machine code called the 'boot loader'.

LILO can replace the MBR boot code (or it can be in the "logical boot record" -- which is like the "superblock" in Unix terminology -- it can also be placed in the boot sector of a floppy. If LILO is placed in "logical boot record" of a Linux partition -- then the DOS (or NT, or OS/2 or whatever) code must be set to load it (usually by setting that partition -- with LILO in it -- as the "active" partition).

With LOADLIN all of this is moot. You just boot DOS (or Win '95 in "command prompt" mode -- using {F8} during the boot sequence or whatever) -- or you can use the mult-boot configuration I described earlier.

One of the funny things about Linux is how many different ways you can load it. You can even shove a Linux kernel unto a floppy (using the dd command) and boot it that way (though you don't get any chance to pass it any parameters that way -- as you do with LOADLIN and LILO).

Last Notes:
-----------

Things are improving in the PC world. We no have some SCSI and EIDE controllers that can boot off of specially formatted CD-ROM disks (meaning we can use a full featured system for our rescue media, rather than and to scrimp and fight to get what we need onto one or two floppies). Most new systems come with at least EIDE -- giving us support for four devices rather than just two. (That's especially important when you want to share a system with a couple of OS and you want to have a CD-ROM drive). Any decent system comes with SCSI -- and most PCI SCSI controllers support 15 devices, rather than the traditional limit of seven. There are "removable bay" and drive adapters for IDE and SCSI -- so having an extra "cold spare" hard drive is pretty simple (and with SCSI we can have external drives again).

Conclusion:
-----------

There are still many cases where we need to use LOADLIN.EXE rather than LILO. I personally recommend that anyone that has DOS installed on their system make a LINUX directory somewhere and toss a copy of LOADLIN.EXE and their favorite kernel(s) in there. This makes an effective "alternative boot" sequence of your partition tables

--Jim


 X-Windows Libraries

Date: Sun, 21 Sep 1997 14:06:26 -0700
From: PATAP!DPFALTZG@patapsco.com

Although I did not get any response from you, I want to follow up with what I have found in the hopes that it may benefit someone along the way.

 Sorry. The volume of my mail and the nature of my expertise (that is the fact that I don't know much about X Windows -- meaning I have to research anything I'm thinking of saying), means that there are sometimes unfortunate delays in my responses.

By the beginning of next year I hope to entirely revamp the way we do "The Answer Guy" (it will hopefully become "The Answer Gang").

 This is about the problem of the X-Windows System not coming up but instead gives messages to the effect that it couldn't map the libraries.

In the process of our playing around, on occasion it would give a message about being out of memory. This puzzled us in that it was not consistent and appeared in a small percentage of the cases. However, on that clue, I found that the swap entry was missing from '/etc/fstab'. I manually turned on swapping and now the X-Windows System comes up and runs normally.

After adding the entry to '/etc/fstab', the whole system comes up and plays as it should. All I can say is that somewhere in the process of trying to get the system back on the air, the entry got removed!

Although you were not directly involved in the solution, I'd like to say, "Thanks for being there!"

 I'm glad that worked. I'll try remember that next time a similar probl em comes up.

To the extent that I have "been there" you're welcome. As with most of the contributors to Linux I must balance my participation against my paying work. Naturally my contributions are far less significant than those of our illustrious programmers -- bit I hope to help anyway.

--Jim


 PC Emulation

Date: Sat, 20 Sep 1997 13:07:56 -0700
From: SAFA ISAA safaisaa@swipnet.se

Hi Im working in comp. named Fordons Data our databas is a UNIX RS/6000.and we use aprogram calld Reflection to emulte pc so we can use the

 That would be the WRQ Reflections to emulate a 3270 or 5150/5250 IBM terminal.

 pc=B4s as aterminal.We use ethernet withe TCP/IP protcol=20 for com.betwen RS and PC .In pc we use win95.My q. is can we use doslinux or minilinux to com. withe rs instade of Reflection ??

 You could install DOSLinux or MiniLinux and a copy of tn3270 and it *might* be able to talk to your RS/6000 (AIX) applications.

The problem is that the 3270 and 5150 terminals are very complex -- more of a client/server hardware than a "terminal/host." Essentially the IBM mainframes and mini's download whole forms to the "terminal" and the "terminal" then handles all sorts of the processing on its own.

tn3270 just implements a bare minimum subset of the 3270 protocols (just the weird EBCDIC character set so far as I know).

Frankly I don't know how this relates to your RS/6000 AIX system. That should be able to accept standard telnet and terminal connections. The question be becomes: "Can your database application (frontends) handle this sort of connection?" Does it provide a curses or tty interface?

 If the answer is YES would U tell me where can I gat and how to test it..We R the bigest comp. in skandinavin for adm the hole car sys THX

 This looks pretty mangled. The answer is "I don't know." However, Linux has the virtual of being free -- so there's very low risk in setting up a copy and trying it.

The more fundamental question is: What are you trying to accomplish? If you currently use Win '95 and Reflections why do you want to switch?

Do you want to save money?

While Win '95 and Reflections are commercial packages -- they aren't terribly expensive. Your administrative and personnel training costs are presumably much higher.

Is is for administrative flexibility?

The number one complaint about MS Windows products by Unix sysadmins (based on my attendance at LISA, USENIX, and similar events) is that MS products are difficult to administer -- and largely impossible to administer remotely or in any automated way.

Unix admins are spoiled by rlogin, rcp, rdist, and the fact that almost *anything* under Unix can be scripted. Most jobs are amenable to shell or perl scripts run via rlogin or cron -- and some of the "tough" jobs require expect (or the perl comm.pl) to "overcome those fits of interactivity."

Mouse driven interfaces with "floating" windows and dialog boxes are not "automation friendly" and MS Windows is particularly unfriendly in this regard. (MacOS has an Applescript and a popular third-party utility called QuickKeys (sp) that reduce its deficiencies in this area).

So, if you're considering switching from Win '95 to Linux so that you can centrally administer your client desktops -- it's probably not quite a compelling reason.

I could go on and on. The point is that you have to make a good business case for making this switch. Is there some Linux application that you intend to deploy? Is this suggested by your security needs? What are the requirements of you database applications? Could you migrate those to use "thin clients" (HTML/CGI forms) through a web (intranet) gateway? Could you implement the client on Java?

As for DOSLinux and MiniLinux specifically: Those can be pretty hard to find. I've sent e-mail to Kent Robotti, the creator of the DOSLinux distribution, to ask where it's run off to.

There are some other small Linux distributions that are suitable for installation into a DOS directory and able to be run off of the UMSDOS filesystem mount on '/' (root).

Mini-Linux is pretty old (1.2.x kernel) and doesn't appear to be currently maintained.

I'd look at Sunsite's distibutions directory --

http://sunsite.unc.edu/pub/Linux/distributions/

Normally there would be a doslinux directory thereunder -- but Kent seems to change things pretty rapidly and it may be that this as been removed while he's doing another upgrade or release.

It may be that you best bet would be the "Monkey" distribution (there's a directory under the URL above for that). This seems to be a five diskette base set in a set of split ARJ (Jung Archive) files. This seems to have been put together by Milan Kerslager of Czechloslovakia (CZ). There are about nine add-on "packages" that are ready to roll with it.

This is pretty recent (last March) package -- and one of the packages for it is a 2.0.30 kernel from the end of April.

A copy of ARJ.EXE doesn't seem to be included, so you'd have to grab that from someplace like:

Simtel: arj250a.exe -- Robert Jung's Archiver

ftp://ftp.cdrom.com/pub/simtelnet/msdos/arcers/arj250a.exe

* (for those who don't know Simtel used to be at the White Sands Missile Range on an old TOPS system. It's primary mirror used to be at oak.oakland.edu -- and it's now hosted by Walnut Creek CD-ROM (ftp.cdrom.com). If you need any sort of DOS shareware or freeware (perhaps to run under dosemu or Caldera's OpenDOS) this is the definitive collection. If you need any significant number of packages (like you need to test/evaluate a dozen of them to decide which works for you) I'd suggest springing for the CD. Another invaluable site for any non-MS DOS users is at http://www.freedos.org -- which in proper free software tradition has links to other DOS sites like RxDOS. DOS is truly the OS that wouldn't die -- and the shareware writers have about a decade headstart on ubiquitous availability over Linux).

--Jim


 Visual Basic for Linux

Date: Thu, 18 Sep 1997 15:34:08 -0700
From: Forzano Forzano@ansaldo.it

I'm looking for a sw that can translate an application developed in Visual Basic to Unix. Could you help me?

 The product you were undoubtedly thinking ofis VBIX by Halcyon Software (http://www.vbix.com). (408-378-9898).

I haven't used this product personally (since I have no interest in Visual BASIC). However they do claim to support Microsoft Visual BASIC source code and they offer some other, related products.

I see a DBIX (which appears to be a database engine with ODBC -- open database connectivity drivers for Linux/Unix and MS Windows '95 and NT). Also interesting might be their "BASIC 4 Java." Here's a blurb from their web pages:

"Halcyon Software Java Products

InstantBasic Script -Written in 100% Pure Java, Halcyon InstantBasic Script (IBS) is more than just cross-platform BASIC; it is BASIC for the Internet. Moreover, IBS is available as both a compiler and an interpreter, thus allowing developers to execute scripts as either BASIC source code or Java binaries(class file). The engine is compatible with Microsoft's BASIC Script Edition and provides complete Java Beans and ActiveX* support. The engine is easily customizable for quick integration and comes with its own lightweight Interactive Development Environment (IDE).

InstantBasic 4 Java - InstantBasic 4 Java is a 4GL development environment written 100% in Java that allows programmers to quickly and easily migrate their existing VB applications to run under any Java environments using the VB-like IDE.

--Jim


 Linux 4.2 software and Hardware compatablity problems

Date: Wed, 17 Sep 1997 20:03:54 -0700
From: John Arnold jarnold@hal-pc.org

I purchased a new computer system and 4.2 RedHat Linux Power Tools for my son, Blake, who is a student at Trinity University in San Antonio, TX.

They were purchased from different vendors.

Neither, Blake, his profs,myself or my vendor knew what we were doing. The result is a big mess. I believe the basic configuration is incorrect. That notwithstanding, I need to know which parts are not supported by Linux and recommended replacements. The following is a brief description of the system:


   Supermicro P5MMS motherboard with 430TX chip set. Ultra DMA 33 Mb/s
   Transfer and 512K pipe line burst mode cache

   AMD K6 MMX Processor @166 MHz, 6th generation performance, Microsoft
   certified.

   32 MEG SDRAN-10ns-DIMM Memory
   Western Digital 4.0 Gig IDE hard drive.  Split 50/50 by vendor
   TEAC 1.44 floppy disk drive
   MATROX MYSTIQUE 4MEG SGRAM PCI Video card
   14" NI SVGA Color monitor by MediaTech,
   1024X768-28DPI (I beleive it has a Fixed Frequency)
   PIONEER 24X CD ROM Drive
   Keytronics keyboard
   Microsoft PS2 mouse
   US Robotics 28.8/33.6 Sportster modem
   Sound Blaster AWE 64 sound card with speakers
   Windows 95 & Plus, Service release 2

When I have the correct equipment I will find a professional to properly configurer it.

Thank you for your assistance.

 All of this equipment is fine. However I have to question your approach. There are several vendors that can ship you a fully configured system with Linux and Windows '95 pre-installed and configured (or just Linux, if you prefer).

In fact an upcoming issue of the Linux Journal has a hardware review of just such a system: the VAR Station II by VA Research (http://www.varesearch.com).
This system is very similar to the one you described (using the same video card, keyboard, and sound card and a very similar 24X CDROM). The big difference between the configuration you list and the one I reviewed is that the VAR Station came with a 4Gb SCSI hard drive, a Toshiba SCSI CD-ROM, and a SymBIOS SCSI adapter (in lieu of the IDE equipment you listed). Also the system I reviewed had a 3Com PCI ethernet card rather than any sort of modem (I already have some modem on my LAN). The other thing is that this motherboard is an Intel and uses a 266 Pentium II.

For about the same as you have spent on these parts separately you could probably get a system from VA Research or several others.

Here's a short list in no particular order:

PromoX (http://www.promox.com)

Aspen Systems (http://www.aspsys.com)

Linux Hardware Solutions (http://www.linux-hw.com)

SW Technology (http://www.swt.com)

Apache Digital (http://www.apache.com

Telenet Systems Solutions (http://www.tesys.com)

... and that doesn't include the ones that specialize in Alphas or SPARC based systems.

So, you have many choices for getting system with Linux preconfigured.

Now, if you're stuck with the system you've got, and you just want it all to work, you could pay a consultant to install and configure on the existing hardware. At typical rates of $50 to $150 per hour (mine are usually set at $91/hr) you'd rapidly spend more on this than on getting system from any of these vendors (who presumably have most of the installation and configuraiton process automated).

I cannot, in good conscience, recommend that you hire me to configure a system like this. It's just too expensive that way.

If you made it clear to your vendor that you intended to run Linux on the system, and they were unable to adequately install and configure it -- I personally think you are fully justified in returning everything and starting over. (If not then yo are still probably within your rights -- and you may still want to consider it).

Another approach you might try is to get just a hard disk with Linux pre-installed on it. This is the popular LOAD (Linux on a Disk) product from Cosmos Engineering (http://www.cosmoseng.com). This isn't quite a neat as getting the whole box pre-configured -- you still have to tell it what sort of video, sound, and other cards you want it to use (and you have to be able to support the extra drive -- which may be tricky if you have an IDE HD and an IDE CD-ROM drive already on your IDE controller. Many new IDE controller have two "channels" (enough to support four IDE devices) and some don't.

Another approach is to just let Blake fend for himself. He can wander around the campus a bit and look for fellow students who use and understand Linux. Who knows, he may meet some great people that way -- maybe even get a date in the process. Linux is very popular at colleges and universities -- and students are generally pretty enthusiastic about helping one another use any sort of toys -- computers especially.

--Jim


 Moving /usr subdirectory to another drive..

Date: Wed, 17 Sep 1997 18:11:32 -0700
From: Ben Bullock bullock@toolcity.net

My entire Linux filesystem currently resides on /dev/hda2 and uses up almost 90% of this partition. Because I am quickly running out of disk space on my original hard drive, I recently added a second hard drive and created a Linux partition on it which the system sees as /dev/hdb1. The /usr subdirectory of my filesystem has swollen to over 300MB, so I would like to copy all the directories and files under /usr over to /dev/hdb1 and then edit /etc/fstab so that this partition will then be mounted on /usr in the filesystem when I boot up.

I've given a lot of thought about how to do this, but I am very concerned about making this change because of the potential problems it might cause if not done properly. I would, therefore, appreciate your advice on how to proceed and what steps I should take to safeguard the integrity of my filesystem. BTW, I have a second, unused partition (/dev/hdb2) available on the new drive that could be used to store a "backup copy" of all the directories and files currently under /usr on /dev/hda2, and I also have an emergency boot/root floppy disk set that provides basic utilties.

Thanks very much for any help you can give me on this. Also, I want you to know that I enjoy your column in the Linux Gaxette and have found it to be very helpful.

 Re: my previous columns and articles.

You're welcome.

Re: how to move (migrate) trees full of files:

I can understand you concerns. Under DOS and Windows this sort of operation is hairy, tricky, painful, and often terribly destructive.

The good news is that Unix is *much* better at this.

Here's the overview:

Mount the new filesytem to a temporary location Use a cpio or tar command to copy everything * (optionally) Make all these files "immutable" Boot from an alternate partition or a rescue disk Rename the source directory Make a new directory by that name (a mount point) Mount the new fs on the new mount point Update your /etc/fstab to make this permanent * (optionally) Update your tripwire database Test Remove the old tree at your leisure.

That's all there is to it. Now we'll go back over those steps in greater detail -- with same commands and some commentary.

Mount the new filesytem to a temporary location:

I like to use /mnt/tmp for this. So the command is:

mount /dev/hdb1 /mnt/tmp

Use a cpio or tar command to copy everything

I used to use tar for this -- but I've found that cpio is better. So here's the tricky command that's really the core of your question:

cd /usr/ && find . -print0 | cpio -p0vumd /mnt/tmp

* note: must do this as root -- to preserve permissions and ownership!

I realize this is an ugly looking command. However, we'll explain it step by step:

cd /usr/ && -- this cd's to the user directory and (if that goes O.K.) executes the following. If you typed /usr/ wrong you won't end up with a mess.

find . -print0 -- this provides a list of filenames as "null terminated strings" -- this will work *even if some of the files have spaces, newlines, or other dubious characters in them*. The results are written into a pipe -- and the program reading them must be capable of using this list. Luckily the GNU cpio and xargs command have this feature, as we'll see.

| cpio -p0vmd /mnt/tmp -- here's the tricky part. This is the "passthrough" mode of cpio. cpio normally copies files "in" or "out" -- but it can do "both" using the "passthrough" mode. cpio expects a list of filenames for its standard input (which we are providing with the 'find' command). It then copies the corresponding file "in" from the path specified (as part of the input line) and "out" to the the path specified as one of cpio's arguments (/mnt/tmp in this case).

The rest of the switches on this cpio command are: 0 -- expect the input records (lines) to be null terminated, v -- be verbose, m -- preserve the modification time of the files (so your next incremental backup does think that everything under /usr/ has suddenly changed), and d -- make leading directories as needed.

The last argument to this cpio command is simply the target directory we supply to the -p switch.

* (optionally) Make all these files "immutable"

One obscure feature of Linux' ext2 filesystem that I like to suggest is the "immutable attribute." This prevents *any* change to a given file or directory until the file is made "mutable" again. It goes way beyond simply removing write permissions via the standard Unix chmod command.

To do this use the command:

cd /mnt/tmp && chattr -R +i *

... or (to just do the files and not the directories):

find /mnt/tmp -type f -print0 | xargs -0 chattr +i

Ultimately this protects the sysadmin from his or her own 'rootly' powers. Even 'root' gets an "operation not permitted" error on any attempt to modify any feature of an immutable file.

Under normal circumstances this only marginally improves the system's security (any attackers who get a 'root' shell can just 'chattr' the files back to "-i" (mutable), and then have their way with your files). However, with the addition of the "sysctl securelevel" features that are expected in the 2.2 kernel (and may already be in the current 2.0 and 2.1 kernels) -- this will actually be a real security feature. (Discussion of "securelevel" is for a different article).

The point is that you can save yourself from many sorts of mistakes by making files immutable. This is particularly handy when running 'make' as root -- when you may have missed some problem in the file that would otherwise wipe out some of your important files. I suspect it's also handy if you get a bogus RPM package -- for basically the same reason.

(Many sysadmin's I've talked to and exchanged mail and news postings with fervently rail about the dangers of running make as root or using any sort of package management system. I understand their concerns but also recognize that the number of new inexperienced SA's -- and the sheer amount of work that many SA's are expected to complete -- practically require us all to take shortcuts and place some trust in some of the packages we're installing. So this "immutable" feature is a reasonable compromise).

Boot from an alternate partition or a rescue disk

Now we've done the hard part. All we have to do now is use the new copy of /usr. The only problem is that many of the commands we want to use require access to the shared libraries in /usr/lib. If you ever accidentally remove or damage /usr/lib/libc.so you'll have first hand experience with the problem.

So, we boot from an alternative boot partition or from a rescue disk, mount our normal root partition and continue. I'll leave out the details on this -- since the details vary from one distribution and site to another.

* Note to distributors and installation script maintainers: PLEASE INCLUDE AN OPTION TO CREATE AN ALTERNATIVE BOOT PARTITION IN YOUR PRODUCTS

Rename the source directory

Now we've copied the whole /usr/ tree to /mnt/tmp. We could just modify the /etc/fstab, and reboot the system. Your rc scripts would blithely mount the new /dev/hdb1 right over the existing /usr -- in effect "hiding" the old usr files. However this wouldn't be very useful -- it does free up any disk space.

So we issue a command like:

                        cd $NORMALROOT          # (wherever you mounted 
                                                # your normal root filesystem)
                        mv usr usr.old

Make a new directory by that name (a mount point)

Now we need to make a new /usr directory. We just issue the "mkdir /usr" command. However -- we're not quite done. We also want to chown and chmod this new directory to match the old one.

So we use "ls -ld usr.old" to see the owner, group, and permissions -- whice are typically like:

drwxr-xr-x  20 root     root         1024 Aug  1 22:10 usr

... and we use the commands:

                        chown root.root usr
                        chmod 755 usr

... to finish the new mount point.

(Personally I like to make /usr/ owned by root.bin and mode 1775 -- sticky and group writable. However, I also mount the whole thing read-only so I'm not sure this is comparable to any of the FSSTND (the filesystem standard) or the conventions used by any distribution).

I get a bit of confused about how the mount command works -- because it seems that the mount command actually over-rides the underlying ownership and permissions of the mount point. However I have seen problems that only seemed to go away when I make the underlying mount point match my intended permissions -- so I do it without understanding it completely.

Mount the new fs on the new mount point

I like to do this just to test things.

Update your /etc/fstab to make this permanent

Now you can edit your /etc/fstab (which should actually be under whatever mount point your using during this "alternative root/rescue" session)

You'll add a line like:

/dev/sdb1     /usr               ext2   defaults,ro 1 2

... to it.

(Note, I like to mount /usr/ in "read-only" mode. this provide one extra layer of protection from the occasional root 'OOOOPS!' It also helps enforce my policy that all new packages are installed under /usr/local, or /usr/local/opt (to which my /opt is a symlink), or under a home directory (which, on some of my systems are under /usr/local/home). The idea of maintaining this policy is that I know what files and packages are not part of the base OS).

* (optionally) Update your tripwire database

Tripwire is a program that maintains a detailed database of your files, their permissions, ownership, dates, sizes, and several different checksums and hashes. The intent is to detect modifications to the system -- in particular these would be signs of corruption, or tampering (security breaches or the work of a virus or trojan horse).

I won't go into details here. If you have tripwire installed, you want to update the database and store it back on it's read-only media.

For more info about tripwire see:

Tripwire (ftp://coast.cs.purdue.edu/pub/COAST/Tripwire)

To get it to compile cleanly under Linux look at the patch I wrote for it:

Tripwire Patch for Linux (http://www.starshine.org/linux/tripwire-linux.patch)

(no .html extension on that -- its just a text file).

(* one of these days I'll get around to writing up a proper web page for Tripwire and for my patch -- I submitted it to Gene and Gene and they never integrated it into their sources).

Test

Now you simply reboot under your normal configuration and test to your hearts content. You haven't removed the old /usr.old yet -- so you can back out of all your changes if anything is broken.

Remove the old tree at your leisure.

When you're satisfied that everthing was copied O.K. -- you can simply remove all the old copies using the command:

rm -fr /usr.old

Now you finally have all that extra disk space back.

Obviously this process can be done for other parts of your filesystems as well. Luckily any other filesystem (that doesn't include the / (root) and /usr/lib/ trees) is less involved. You shouldn't have to reboot or even switch to single user mode for any other migrations (though it won't hurt to do so).

I like to put /tmp, /var, and /usr/local all on their own filesystems. On news servers I put /var/spool/news on it's own. Here's a typical fstab from one of my systems:

# <device>    <mountpoint>   <filesystemtype> <options> <dump> <fsckorder>

/dev/sdc1      /                  ext2   defaults       1 1
/dev/sda6      /tmp               ext2   defaults       1 2
/dev/sda10     /usr               ext2   defaults,ro    1 2
/dev/sda7      /var               ext2   defaults       1 3
/dev/sda8      /var/log           ext2   defaults       1 3
/dev/sda9      /var/spool         ext2   defaults       1 3
/dev/sdb5      /usr/local         ext2   defaults       1 3

/proc          /proc              proc   defaults
/dev/sda2      none               swap   sw

/dev/fd0       /mnt/a             umsdos  noauto,rw,user 0 0
/dev/fd1       /mnt/b             umsdos  noauto,rw,user 0 0
/dev/hda1      /mnt/c             umsdos  defaults 0 0
/dev/scd1      /mnt/cd            iso9660 noauto,ro,user,nodev,nosuid 0 0
/dev/scd0      /mnt/cdwr          iso9660 noauto,ro,user,nodev,nosuid 0 0
/dev/fd0       /mnt/floppy        minix  noauto,rw,user,noexec,nodev,nosuid 0 0
/dev/fd0       /mnt/e2floppy      ext2   noauto,rw,user,noexec,nodev,nosuid 0 0
/dev/sdd1      /mnt/mo            ext2   noauto,rw,user,nodev,nosuid 0 0
/dev/sdd1      /mnt/mo.offline    ext2   noauto,rw,user,nodev,nosuid 0 0
/dev/sdd1      /mnt/modos         umsdos  defaults,noauto 0 0

tau-ceti:/      /mnt/tau-ceti   nfs     ro      

Note all the noauto and user point points. These allow users to access these removable devices without switching to 'root.' To protect against potential problems with the 'mount' command (being SUID 'root') I have it configured with the following ownership and permissions:

        -r-sr-x---   1 root     wheel       26116 Jun  3  1996 /bin/mount

Thus, only members of the "wheel" group are allowed to use the mount command (and I only put a few people in that). So I balance the risk of one of the "wheel" members finding and exploiting a bug in 'mount' vs. the expense having to do all mount's myself and risk of my typing *bad things* at the root shell prompt. I could also accomplish the same sorts of things with 'sudo' (and I use that for many other cases).

For more info about sudo see:

Sudo Home Page (http://www.courtesan.com/courtesan/products/sudo/)

FTP sudo: (ftp://ftp.cs.colorado.edu/pub/sysadmin/sudo

I hope that I've done more than answer your question. I hope I've given you some ideas for how to make your system more robust and secure -- how to apply some of the principles of "best practice" to administering your Linux box.

--Jim


 C++ Integrated Programming Enviroment for X...

Date: Wed, 17 Sep 1997 17:56:30 -0700
From: trustno1@kansas.net

Dear Answer Guy,
I am a student in Information Systems at Kansas State University. As a relatively new user of Liunx, I was wondering if there exists a software package for X which could be comparable to something like Borland's C++ IDE? I've heard of something called Wipeout, but I'm not running Xview, is there anything else that I should check out?

 I've never heard of "Wipeout" -- but it sounds suspicously like a slurred pronunciation of "wpe" -- which would be the "Window Programming Environment" by Fred Kruse. This has a console mode (wpe) and an X mode (xwpe) which are just links to the same binary.

I don't know that it requires Xview. Certainly on the rare occasions when I've run it I didn't have to do anything special -- just type the appropriate command for the mode I wanted and it just appears. So, I didn't have to install any special libraries or run a particular window manager or anything silly like that.

t typing 'xwpe &' from any xterm and see if that's already installed for you. If so you can add it to your window manager's menu tree, or to whatever sort of desktop manager or program/applications manager you use (or just always launch if from an xterm -- which is what I do for 90% of the things I run under X).

--Jim


 LYNX-DEV new to LYNX

Date: Tue, 16 Sep 1997 22:06:45 -0700

Will I be able to browse the FULL INTERNET using LYNX? I am using LYNX at my job, and the computer does not have window!

 The web is not the FULL INTERNET!

Web browsers (such as Lynx, Mosaic, Netscape and MSIE) only access the web, ftp, and gopher. These are only a few of the services and protocols supported by the Internet.

There is no such thing as "browsing" the "full Internet." Indeed, the phrase "full Internet" is meaningless.

As to your implicit question:

Will you be able to browse all public web sites using Lynx?

... the answer is no.

Lynx is a browser that complies with as much of the HTTP and HTML specifications (the protocols and data representation (file formats) used by the "web") as possible -- within the constraints of it various platforms (text only -- no "inline" graphics, no sound, no support for "Java" or "JavaScript" (which aren't part of these specifications anyway).

Therein lies the rub. The client (Lynx) is able -- but many of the servers aren't willing. (In this case, by "servers" I'm referring to the people and the sites -- not the software).

Basically there are some sites that are "unfriendly." They make gratuitous use of tables, imagemaps, frames, Java applets, embedded JavaScript, cookies, ActiveX, active server pages (ASP) and ISAPI, and other extensions. They hope to win in some "one-up-manship" contest of "coolness."

Most of these extensions were introduced or promoted by one or another company (mostly Microsoft or Netscape) in their efforts to "capture" the "mindshare" -- which they hope will lead to increased *market*-share for their browsers and "web developement tools" (at the expense of standards, interoperability, and -- most especially -- their competitors).

The "web development tools" are the most insidious power piece in this little chess game. These tools (mostly Microsoft's "FrontPage") seem to include these non-standard extensions wherever possible -- with no warning, commentary, and mostly with no option to avoid them. Anyone who wants to produce "clean," friendly, standards conformant code is basically reduced to using a bare text editor -- and knowing the syntax inside and out.

In some particularly notorious cases there are "active" or "dynamic content" sites that will slam the door shut on your browser just based on a prejudice about it's name. By default your browser identifies itself to the server when fetching pages. Some sites are "just too cool" to have any textual content -- and shove a message down your throat:

"Go get a 'real' browser, punk!"

... (the sheer effrontery of telling your "customers" what sort of vehicle to drive around on the "stupor hypeway" -- it simply boggles the mind and gasts the flabber!).

I've even encountered a couple of cases where some "dynamic sites" would shove hundreds of kilobytes of "search engine spam" to my copy of Lynx. This was a crude effort to seed the databases maintained by Yahoo!, InfoSeek, HotBot, and others with excessively favorable content rating (based on the notion that most of these sites used "bots" (web robots, or "spiders") that identify themselves as "Lynx" (to avoid using the extra bandwidth on graphics that they couldn't use).

There are also an increasing number of sites that require SSL even for their non-secure information. SSL is a set of encryption protocols which are primarily used to provide for server-authenticated (or mutually authenticated) and "secure" (encrypted) access to web forms (mostly for order Pizzas without shouting your credit card number to every router in fifty states and a few countries).

So, there are a number of places on the "full Internet" that you can't adequately or comfortably browse with Lynx.

The good news is that Lynx does support features to address most of these problems. You can get an SSL proxy (which you'd run on the same machine as you run Lynx), the current versions of Lynx will list all the "frames" (which are a Netscape extension for displaying multiple separate HTML files concurrently), and can fetch some sorts of "map" files (the text files which describe the "hot" (clickable) regions of an IMAGEMAP -- which is a picture with "clickable" point therein) -- so you can browse them. Lynx can offer to accept cookies *(see note: cookies) for a given session -- and, eventually, may offer options to save them.

The bad news, again from the site maintainers and devlopers, is that they often don't provide meaningful names for their frames, or within their image map files. These are intended to be "seen" by a site's users -- and often aren't "seen" by the site's developers (remember the "integrated web developer software we mentioned earlier?).

The final bit of good news is this:

"Most sites that are particularly "Lynx-unfriendly" have not real content. When I succumb to curiosity and view them in a GUI browser -- they are all flash and no substance."

When we say "hypertext" they seem to hear "hype OR text"

So, Lynx acts as a bit of a twit filter. Visit a site first with a text browser (Lynx or emacs' W3 mode) and you'll know immediately whether their webmasters are hard of hearing or whether they "get it."

"* Cookies are another Netscape extension which are intended to allow web site developers a crude and unreliable way to "maintain state" (distinguish between users who might be at the same site -- like all of the AOL, CompuServe, and Netcom users going through their respective gateways). Marketing people drool over statistics based on "cookies" which can purport to tell how many *new* and *returning* users there are to a site, *who* read *which* documents other nonsense. However, for those statistics to be even close enough for a marketeer, the use of them must be almost universal (so we stop non-cookies browsers at the front home page) and we have to rely on them being so obscure in the browser software that no one tampers with them (they essentially must be "sneaky")."

PS: I've copied this to my editor at the Linux Gazette -- since I think it's a article for them to consider. Maybe they'll reprint it in "Websmith" (a feature of the Linux Journal, which is published by SSC, the maintainers for the Linux Gazette webazine). Interested parties can view all of the back issues of LG the URL in my sig. - -- a site that is emminently "Lynx Friendly"

-- Jim


Previous "Answer Guy" Columns

Answer Guy #1, January 1997
Answer Guy #2, February 1997
Answer Guy #3, March 1997
Answer Guy #4, April 1997
Answer Guy #5, May 1997
Answer Guy #6, June 1997
Answer Guy #7, July 1997
Answer Guy #8, August 1997
Answer Guy #9, September 1997


Copyright © 1997, James T. Dennis
Published in Issue 22 of the Linux Gazette October 1997


[ TABLE OF 
CONTENTS ] [ FRONT PAGE ]  Back  Next