Faxing and Dialing Out on the Same Line

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).

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.

Linux and the 286

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.

chattr +i

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

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:

(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)

(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:

POP3 vs. /etc/passwd

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

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

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.

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

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:

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:

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

X-Windows Libraries

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.

PC Emulation

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.

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:

* (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).

Visual Basic for Linux

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.

Linux 4.2 software and Hardware compatablity problems

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:

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.

... 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..

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.

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.

(* 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:

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).

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...

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"