File: lg_answer22.html

package info (click to toggle)
lg-issue22 4-1
links: PTS
area: main
in suites: hamm, slink
size: 1,108 kB
ctags: 181
sloc: makefile: 30; sh: 3
file content (2138 lines) | stat: -rw-r--r-- 92,268 bytes
<!--startcut =======================================================  -->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> 
<html>
<head>
<title>The Answer Guy Issue 22</title>
</head>

<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#0020F0"
ALINK="#FF0000">
<!--endcut =========================================================  -->
<H4>&quot;Linux Gazette...<I>making Linux just a little more fun!</I>&quot;
</H4>
<P> <hr> <P> 

<!-- ===============================================================  -->
<center>
<H1><A NAME="answer">
<img src="../gx/ans.gif" alt="" border=0 align=middle>
The Answer Guy
<img src="../gx/ans.gif" alt="" border=0 align=middle>
</A></H1> <BR>
<H4>By James T. Dennis,
<a href="mailto:jimd@starshine.org">jimd@starshine.org</a><BR> 
Starshine Technical Services, <A HREF="http://www.starshine.org/">
http://www.starshine.org/</A> </H4> 
</center>

<p><hr><p>
<H3>Contents:</H3>
<ul>
<li><a HREF="./lg_answer22.html#fax">Faxing and Dialing-Out on the Same Line</a>
<li><a HREF="./lg_answer22.html#286">Linux and the 286</a>
<li><a HREF="./lg_answer22.html#ext2fs">Accessing ext2fs from Windows 95</a>
<li><a HREF="./lg_answer22.html#chattr">chattr +i</a>
<li><a HREF="./lg_answer22.html#sendmail">Linux sendmail problem</a>
<li><a HREF="./lg_answer22.html#fetch">POP3 vs. /etc/passwd</a>
<li><a HREF="./lg_answer22.html#make">Problem with make</a>
<li><a HREF="./lg_answer22.html#swap">Swap partition and Modems</a>
<li><a HREF="./lg_answer22.html#rhmotif">Redhat 4.2/Motif</a>
<li><a HREF="./lg_answer22.html#email">E-mail adjustment needed</a>
<li><a HREF="./lg_answer22.html#realbios">REALBIOS?</a>
<li><a HREF="./lg_answer22.html#lib">X-Windows Libraries</a>
<li><a HREF="./lg_answer22.html#pc">PC Emulation</a>
<li><a HREF="./lg_answer22.html#vbasic">Visual Basic for Linux</a>
<li><a HREF="./lg_answer22.html#hardware">Linux 4.2 software and Hardware
compatablity problems</a>
<li><a HREF="./lg_answer22.html#mvusr">Moving /usr subdirectory to
another drive..</a>
<li><a HREF="./lg_answer22.html#cppx">C++ Integrated Programming
Enviroment for X...</a>
<li><a HREF="./lg_answer22.html#lynx">LYNX-DEV new to LYNX</a>
</ul>

<p><hr><p> 
<!--================================================================-->

<a name="fax"></a>
<h3><img align=bottom alt=" " src="../gx/ques.gif">
Faxing and Dialing Out on the Same Line
</h3>
<P> <B> 

From: Carlos Costa Portela
 <a href="mailto:c.c.portela@ieee.org">
 c.c.portela@ieee.org </a>
</b>
<p> 

<b>
Hello, Linux Gazette!
<br>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:
<br>I am using the fax program efax, by Ed Casas. Really good!. When my
system starts, I put the fax in answer mode:
</B><p><B> 
This is the entry in the inittab file:
rf:3:respawn:/bin/sh /usr/bin/fax answer
</B> <P> 
<img align=bottom alt=" " src="../gx/ans2.gif">

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!).
<p> 
<b> 
<img align=bottom alt=" " src="../gx/ques.gif">
But sometimes a day (once or twice) I need my modem to connect to my ISP
and, at least, read and send my mail!
</b><p> <B>
Then there is an overlapping between one program -or command- and the
other.
</B> <P> 
<img align=bottom alt=" " src="../gx/ans2.gif">

This is a very common situation.  That's why Unix communications
programs support various sorts of "device locking."
<p>
The only trick is to make sure that all the programs on your
system agree on the name, location, and type of lock files.

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

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.

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

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

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

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

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

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

<p>
<b>
<img align=bottom alt=" " src="../gx/ques.gif">
Obviously, this is not a solution:
<br>       Turn off the modem, and then turn on.
<br>       Kill the efax process.
</b><p> <b>
Because the entry has a "respawn" keyword.
</b><p> <B>

What is the best way to:
<br>   - inactivate the fax.
<br>   - connect to Internet.
<br>   - disconnect.
<br>   - activate the fax.
</B> <P> 
<img align=bottom alt=" " src="../gx/ans2.gif">
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).

<p> 
The 'mgetty' home page is at:

<p> 
	Mgetty+Sendfax Documentation Centre (Gert Doering)
		<a href="http://www.leo.org/~doering/mgetty/">
		http://www.leo.org/~doering/mgetty/</a>
<p> 
... and some related resources are at:

<p> 
	ISP Resources - mgetty info (AutoPPP)
		<a href="http://www.buoy.com/isp/mgetty.html">
		http://www.buoy.com/isp/mgetty.html</a>

<p> 
	Coastal Internet - ISP Info! 
		<a href="http://www.buoy.com/isp/">
		http://www.buoy.com/isp/</a>

<p> 
<B>
<img align=bottom alt=" " src="../gx/ques.gif">

Well, one solution is:
<br>       go to the /etc/inittab
comment the line
restart the system

Is there a better one?.
</B> <P> 
<img align=bottom alt=" " src="../gx/ans2.gif">

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. 

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

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

<p>--
Jim 


<p><hr><p> 
<!--================================================================-->

<a name="286"></a>
<h3><img align=bottom alt="" src="../gx/ques.gif">
Linux and the 286
</h3>
<P> 
<b>
From: tbickl@inreach.com
<a href="tbickl@inreach.com">tbickl@inreach.com</a>
</b><P><B>

Hello,<br>

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.


</B> <P> 
<img align=bottom alt=" " src="../gx/ans2.gif">

You were told wrong.
<P>

<img align=bottom alt=" " src="../gx/ques.gif">
 <B> 

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.


</B> <P>
<img align=bottom alt=" " src="../gx/ans2.gif">


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


<img align=bottom alt=" " src="../gx/ques.gif">
<B> 


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

</B> <P>
<img align=bottom alt=" " src="../gx/ans2.gif">


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

<p>
<img align=bottom alt=" " src="../gx/ques.gif">
 <B>

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


</B> <P>
<img align=bottom alt=" " src="../gx/ans2.gif">


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).
<p>
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.
<P><B>
<img align=bottom alt=" " src="../gx/ques.gif">

Thank you for any help you can offer . . .


</B> <P>
<img align=bottom alt=" " src="../gx/ans2.gif">


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

<p>--Jim
<p><hr><p> 
<!--================================================================-->

<a name="ext2fs"></a>
<h3><img align=bottom alt=" " src="../gx/ques.gif">
Accessing ex2fs from Windows 95
</h3>
<P> <B> 

From:  <a href="globus@pathcom.com">globus@pathcom.com</a>
</B><p><B>


Hi:<br>
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.

</B> <P> 
<img align=bottom alt=" " src="../gx/ans2.gif">

Try the Linux Software Map (currently courtesy of ExecPC).
I used just the keyword "DOS":
<p>
Have you looked at ext2tool:
<p>
Database: Linux Software Map
<p>
Title:                  Ext2 tools
<br>Version:                1.1
<br>       Entered-date:           09 Jan, 96
<p>       Description:
<br>               A collection of DOS programs that allow you to 
	read a Linux ext2 file system from DOS.
<p>                
Keywords:               DOS, ext2
<br>Author:                 ct@login.dknet.dk (Claus Tondering)
<br>       Maintained-by:          ct@login.dknet.dk (Claus Tondering)
<br>Primary-site:
<br>            login.dknet.dk pub/ct
<br>        287706 ext2tool_1_1.zip
    <br>    
<br>      Alternate-site:
<br>	sunsite.unc.edu pub/Linux/system/Filesystems/ext2
<br>            287706 ext2tool_1_1.zip
<br>        
<br>      Platforms:
<br>          PC with 386 or better
  <br>      
<br>     Copying-policy:                 GPL

<p>

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

-- Jim
<p><hr><p> 

<!--================================================================-->
<a name="chattr"></a>
<h3><img align=bottom alt=" " src="../gx/ques.gif">
chattr +i
</h3>
<P> <B> 
From: <A HREF="mailto:ckkrish@cyberspace.org">ckkrish@cyberspace.org</A>
</B> <P><B>  
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.

</B> <P> 
<img align=bottom alt=" " src="../gx/ans2.gif">
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.
 <P>

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

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

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

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

Anyway -- glad my tips were helpful.  

<P> 
-- Jim
<p><hr><p> 

<!--================================================================-->
<a name="sendmail"></a>
<h3><img align=bottom alt=" " src="../gx/ques.gif">
Linux sendmail problem 
</h3>
<P> <B> 
From:  Jason Moore <A HREF="mailto:jsmoore@brain.uccs.edu">jsmoore@brain.uccs.edu</A>
</B> <P><B> 

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.

</B> <P> 
<img align=bottom alt=" " src="../gx/ans2.gif">
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.
<P>

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

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

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

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

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:
 <P>
 <pre>
DNS HOWTO
  How to set up DNS.    
  _Updated 3 June 1997._
<a href="http://sunsite.unc.edu/LDP/HOWTO/DNS-HOWTO.html">http://sunsite.unc.edu/LDP/HOWTO/DNS-HOWTO.html</a>

</pre>
<p>
	(Like I said -- the real problem is your DNS).
<p> <pre>
Electronic Mail HOWTO
  Information on Linux-based mail servers and clients.
  _Updated 29 November 1995. _
<a href="http://sunsite.unc.edu/LDP/HOWTO/Mail-HOWTO.html">http://sunsite.unc.edu/LDP/HOWTO/Mail-HOWTO.html</a>                       
</pre><p>
	(This is a bit of an overview).
 <p><pre> 
Mail Queue mini-HOWTO
  How to queue remote mail and deliver local mail.
  _Updated 22 March 1997. _
<a href="http://sunsite.unc.edu/LDP/HOWTO/mini/Mail-Queue">http://sunsite.unc.edu/LDP/HOWTO/mini/Mail-Queue</a>
</pre><p>

	(This is more specific -- and might be how 
	 you want to do your mail).
 <p><pre>
  
Offline Mailing mini-HOWTO
  How to set up email addresses without a dedicated Internet
  connection.
  _Updated 10 June 1997. _
<a href="http://sunsite.unc.edu/LDP/HOWTO/mini/Offline-Mailing">http://sunsite.unc.edu/LDP/HOWTO/mini/Offline-Mailing</a>
</pre><p>


	(This is another way you might want to do your
	 mail).
 <p><pre>

ISP Hookup HOWTO
  Basic introduction to hooking up to an ISP. 
  _Updated 9 December 1996. _
<a href="http://sunsite.unc.edu/LDP/HOWTO/ISP-Hookup-HOWTO.html">http://sunsite.unc.edu/LDP/HOWTO/ISP-Hookup-HOWTO.html</a>
</pre><p>


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

  <p><pre>
 
PPP HOWTO
  Information on using PPP networking with Linux.
  _Updated 31 March 1997. _
<a href="http://sunsite.unc.edu/LDP/HOWTO/PPP-HOWTO.html">http://sunsite.unc.edu/LDP/HOWTO/PPP-HOWTO.html</a>                      
</pre><p>


	(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))
  <p><pre>
  
UUCP HOWTO
  Information on UUCP software for Linux.
  _Updated 29 November 1995. _
<a href="http://sunsite.unc.edu/LDP/HOWTO/UUCP-HOWTO.html">http://sunsite.unc.edu/LDP/HOWTO/UUCP-HOWTO.html</a>
</pre><p>


	(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)
<pre>
Sendmail+UUCP mini-HOWTO
  How to use sendmail and UUCP together.
  _Updated 15 March 1997. _
<a href="http://sunsite.unc.edu/LDP/HOWTO/mini/Sendmail+UUCP">http://sunsite.unc.edu/LDP/HOWTO/mini/Sendmail+UUCP</a>
</pre><p>

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

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:
<p>
<pre>
	smail:
		FTP Site:
		<a href="ftp://ftp.uu.net/networking/mail/smail">ftp://ftp.uu.net/networking/mail/smail</a>

		Newsgroup: 
		news:comp.mail.smail

	qmail:
		<a href="http://www.qmail.org">http://www.qmail.org</a>

</pre>
<P> 
-- Jim
<HR><P>
<!--================================================================-->

<a name="fetch"></a>
<h3><img align=bottom alt=" " src="../gx/ques.gif">
POP3 vs. /etc/passwd 
</h3>
<P> <B> 
From: Benjamin Peikes <A HREF="mailto:benp@npsa.com">benp@npsa.com</A>
</B> <P><B>  

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. 

</B> <P> 
<img align=bottom alt=" " src="../gx/ans2.gif">
Yes -- I understood that from the get go.

<P> <B>
<img align=bottom alt=" " src="../gx/ques.gif">

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.


</B> <P>
<img align=bottom alt=" " src="../gx/ans2.gif">

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

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

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

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

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


<P> 
-- Jim

<p><hr><p> 
<!--================================================================-->

<a name="make"></a>
<h3><img align=bottom alt=" " src="../gx/ques.gif">
Problem with make</h3>
<b>Date: Thu, 25 Sep 1997 21:17:56 -0700</b><p>
<b>From:  Alfredo Todini <a href="mailto:mc0736@mclink.it">mc0736@mclink.it</a><br>
Jim,
</B><p><B>
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.<p>
Could you please help me?
</B><P>
<img align=bottom alt=" " src="../gx/ans2.gif">
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).<p>

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?<p>

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)?<p>

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

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

<p>--Jim
<!--================================================================-->
<a name="swap"></a>
<P> <hr> <P>
<h3><img align="bottom" alt=" " src="../gx/ques.gif">
Swap partition and Modems</h3><p>
<b>Date: Thu, 25 Sep 1997 16:50:19 -0700</b><br>
<b>From: Robert Rambo <a href="mailto:robert.rambo@yale.edu">robert.rambo@yale.edu</a><br>
</b><p><B>
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.
</b><p>
<img align=bottom alt=" " src="../gx/ans2.gif">
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.
<p>--Jim
<!--================================================================-->
<a name="rhmotif"></a>
<P> <hr> <P>
<h3><img align=bottom alt=" " src="../gx/ques.gif">
Redhat 4.2/Motif</h3><p>
<b>Date: Thu, 25 Sep 1997 03:11:51 -0700<br>
From: "Victor J. McCoy" <a href="mailto:vmccoy@kmrmail.kmr.ll.mit.edu">
vmccoy@kmrmail.kmr.ll.mit.edu</a><br>
</B><p><B>
Ok, the details first:<br>
Redhat 4.2 (default installation)<br>
Redhat Motif 2.0.1<br>
Intel p133<br>
64 MB RAM<br>
ATI Graphics Pro Turbo (4MB)<br>
I think that's all the relevant info.<br>

I'm having trouble with pppd and Motif.  If I run my connection 
script, the Motif stops behaving properly.</B><p><B>

Before pppd...popup menus work fine, click anywhere in client window 
and focus shifts.</B><p><B>

After pppd...popups are non-existent, must click on window border to 
get focus.
</b><P>
<img align=bottom alt=" " src="../gx/ans2.gif">
      Are there *any* other symptoms?<br>
        This seems awfully specific -- and the PPP connection seems
        awfully peripheral to the windowing system.<p>

        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?)<p>

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

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

        What if you use a different Window manager (other than mwm)?
<p>
        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.
<p>
        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).
<p><img align=bottom alt=" " src="../gx/ques.gif">
<b>
 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).
</b><p><b>
Has this been trouble for anyone else?  I emailed redhat, but their 
"bugs@" email address states not to expect an answer.
</b><p>
<img align=bottom alt=" " src="../gx/ans2.gif">
 I might even get involved in a program to provide
        a better support infrastructure for Red Hat.
<p>

        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.
<p>--Jim
<!--================================================================-->
<a name="email"></a>
<P> <hr> <P> 
<h3><img align=bottom alt=" " src="../gx/ques.gif">E-mail adjustment needed</h3>
<P> <B>Date: Mon, 22 Sep 1997 12:52:50 -0700<BR>From: Terrey Cobb<a href="mailto:tcobb@onr.com">tcobb@onr.com</a></B><p>
<B>Greetings Answer Guy:<br>
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 &lt;sierra.onr.com&gt;."  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.
</b><p>
<align=bottom alt=" " src="../gx/ans2.gif">
        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).

<P>        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).
<p>--Jim
<!--================================================================-->
<a name="realbios"></a>
<P> <hr> <P>
<H3><img align=bottom alt=" " src="../gx/ques.gif">REALBIOS?</H3>
<P> <B>From: Bill Dawson <a href="mailto:bdawson@abginc.com">bdawson@abginc.com</a><br>
Linux Wizard,<br>
      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:
      
</B><p><B>
      "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"
</B><p><B>
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?
</b><p>
<img align=bottom alt=" " src="../gx/ans2.gif">    
        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.
<p>
   Short Answer:<br>
   -------------<br> 
        Look for the loadlin.tar.gz package -- it
        should include that.  Here's the URL for the
        copy of that on sunsite:

<p>
<a href="http://sunsite.unc.edu/pub/Linux/distributions/slackware/slakware/a4/loadlin.tgz">http://sunsite.unc.edu/pub/Linux/distributions/slackware/slakware/a4/loadlin.tgz</a><p>
        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.
<p>
        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.
<p>
       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:

<p>
<pre>
                 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
</pre>
<p>
   A bit of Background:<br>
   --------------------<br>
<p>
        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").
<p>
        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).
<p>
        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.

<p>
    LILO and LOADLIN.EXE:
<br>
    ---------------------
<br><p>
        The two common ways to load a Linux kernel into memory 
        are: LILO and LOADLIN.EXE.   
<p>
        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).
<p>
        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).
<p>
        Worse than that -- there were no standard drivers -- each
        manufacturer had to write their own -- and none of them
        followed an particular conventions.
<p>
        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).
<p>
        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).
<p>
        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'.
<p>
        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).
<p>
        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.
<p>
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).
<p>
    Last Notes:
<br>
    -----------
<br>
<p>
        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).

<p>
    Conclusion:
<br>
    -----------
<br><p>
        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 


<p>--Jim
<P> <hr> <P>
<!--================================================================-->
<a name="lib"></a>
<h3><img align=bottom alt=" " src="../gx/ques.gif">X-Windows Libraries</h3><p><b>
Date: Sun, 21 Sep 1997 14:06:26 -0700<br>
From: <a href="mailto:PATAP!DPFALTZG@patapsco.com">PATAP!DPFALTZG@patapsco.com</a></B><p><B>
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.
</b><p>
<img align=bottom alt=" " src="../gx/ans2.gif">
        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.
<p>
        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").
<p><img align=bottom alt=" " src="../gx/ques.gif">
<B>
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.
</B><p><B>
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.
</B><p><B>
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!
</B><p><B>
Although you were not directly involved in the solution, I'd like to say,
"Thanks for being there!"
</B><p>
<img align=bottom alt=" " src="../gx/ans2.gif">
        I'm glad that worked.   I'll try remember that next time a similar probl
em comes up.
<p>
        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.
<p>--Jim
<P> <hr> <P>
<!--================================================================-->
<a name="pc"></a>

<h3><img align=bottom alt=" " src="../gx/ques.gif">
PC Emulation</h3><p><b>Date: Sat, 20 Sep 1997 13:07:56 -0700
<br>From: SAFA ISAA <a href="mailto:safaisaa@swipnet.se">safaisaa@swipnet.se</a></B><p><B>
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
</B>
<p>
<img align=bottom alt=" " src="../gx/ans2.gif">
        That would be the WRQ Reflections to emulate a 3270 or 5150/5250
        IBM terminal.
<p><b>
<img align=bottom alt=" " src="../gx/ques.gif">
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 ??
</b><p>
<img align=bottom alt=" " src="../gx/ans2.gif">
        You could install DOSLinux or MiniLinux and a copy of 
        tn3270 and it *might* be able to talk to your RS/6000 (AIX)
        applications.
<p>
        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.
<p>
        tn3270 just implements a bare minimum subset of the 3270
        protocols (just the weird EBCDIC character set so far as
        I know).
<p>
        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?
<p><b>
<img align=bottom alt=" " src="../gx/ques.gif">
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
</B><P> 
<img align=bottom alt=" " src="../gx/ans2.gif">
        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.
<p>
       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?
<p>
                Do you want to save money?
<p>
                While Win '95 and Reflections are commercial packages
                -- they aren't terribly expensive.  Your administrative
                and personnel training costs are presumably much higher.
<p>
                Is is for administrative flexibility?
<p>
                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.
<p>
                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."  
<p>
                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).
<p>
                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.
<p>
        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?
<p>
        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.
<p>
        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).
<p>
        Mini-Linux is pretty old (1.2.x kernel) and doesn't appear
        to be currently maintained.
<p>
        I'd look at Sunsite's distibutions directory -- 
<p>
<a href="http://sunsite.unc.edu/pub/Linux/distributions/">http://sunsite.unc.edu/pub/Linux/distributions/</a>
<p>
        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.
<p>
        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.
<p>
        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.
<p>
        A copy of ARJ.EXE doesn't seem to be included, so you'd
        have to grab that from someplace like:
<p>
Simtel: arj250a.exe -- Robert Jung's Archiver<p>
<a href="                ftp://ftp.cdrom.com/pub/simtelnet/msdos/arcers/arj250a.exe
">                ftp://ftp.cdrom.com/pub/simtelnet/msdos/arcers/arj250a.exe
</a>
<p>
       * (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).

<p>--Jim
<p>
<!--================================================================-->
<a name="vbasic"></a>
<P> <hr> <P>
<h3><img align=bottom alt=" " src="../gx/ques.gif">Visual Basic for Linux</h3>
<p>
<b>Date: Thu, 18 Sep 1997 15:34:08 -0700
<br>From:  Forzano <a href="mailto:Forzano@ansaldo.it">Forzano@ansaldo.it</a></b><p>
<B>I'm looking for a sw that can translate an application developed in
Visual Basic to Unix. Could you help me? 

</b><p>
<img align=bottom alt=" " src="../gx/ans2.gif">
 The product you were undoubtedly
     thinking ofis VBIX by Halcyon Software (<a href="http://www.vbix.com">http://www.vbix.com</a>).
        (408-378-9898).
<p> 
        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.
<p>
        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:
<p>
"<I>Halcyon Software Java Products
</I><p><I>
   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).
</I><p><I>
   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.</I>
<p>--Jim
<P> <hr> <P>

<!--================================================================-->
<a name="hardware"></a>
<h3><img align=bottom alt=" " src="../gx/ques.gif">
Linux 4.2 software and Hardware compatablity problems</h3>
Date: Wed, 17 Sep 1997 20:03:54 -0700<br>
From: John Arnold <a href="mailto:jarnold@hal-pc.org">jarnold@hal-pc.org</a><p>
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.
<p>
<B>They were purchased from different vendors.
</B><p>
<P><B>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:</B>
<p><pre><B>
   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
</B></pre>
<P><B>When I have the correct equipment I will find a professional to properly
configurer it.
</B><p>
<B>Thank you for your assistance.
</b><p>
<img align=bottom alt=" " src="../gx/ans2.gif">
        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).
<p>
        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
(<a href="http://www.varesearch.com">http://www.varesearch.com</a>).
 <br> 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.
<p>
        For about the same as you have spent on these parts separately
        you could probably get a system from VA Research or several
        others.  
<p>
        Here's a short list in no particular order:
<p>
                PromoX
 (<a href="http://www.promox.com">http://www.promox.com</a>)<p>
                Aspen Systems 
 (<a href="http://www.aspsys.com">http://www.aspsys.com</a>)<p>
                Linux Hardware Solutions 
 (<a href="http://www.linux-hw.com">http://www.linux-hw.com</a>)<p>
                SW Technology
 (<a href="http://www.swt.com">http://www.swt.com</a>)<p>
                Apache Digital 
 (<a href="http://www.apache.com">http://www.apache.com</a><p>
                Telenet Systems Solutions 
 (<a href="http://www.tesys.com">http://www.tesys.com</a>)<p>
        ... and that doesn't include the ones that specialize in
        Alphas or SPARC based systems.
<p>
        So, you have many choices for getting system with Linux 
        preconfigured.
<p>
       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).
<p>
        I cannot, in good conscience, recommend that you hire me
        to configure a system like this.  It's just too expensive
        that way.
<p>
        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).
<p>
        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.
<p>
        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.
<p>--Jim
<P> <hr> <P>

<!--================================================================-->
<a name="mvusr"></a>
<h3><img align=bottom alt=" " src="../gx/ques.gif">
Moving /usr subdirectory to another drive..
</h3>
Date: Wed, 17 Sep 1997 18:11:32 -0700<br>
From: Ben Bullock <a href="mailto:bullock@toolcity.net">bullock@toolcity.net</a>
<p>
<B>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.
</B><p><B>
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.
</B><p><B>
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.
</B><P>
<img align=bottom alt=" " src="../gx/ans2.gif">
        Re: my previous columns and articles.
<p>
                You're welcome.
<p>
        Re: how to move (migrate) trees full of files:
<p>
        I can understand you concerns.  Under DOS and Windows
        this sort of operation is hairy, tricky, painful, and
        often terribly destructive.
<p>
        The good news is that Unix is *much* better at this.
<p>
        Here's the overview:
<p>
                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.
<p>
       That's all there is to it.  Now we'll go back over those 
        steps in greater detail -- with same commands and some
        commentary.
 <p>
        Mount the new filesytem to a temporary location:
<p>
               I like to use /mnt/tmp for this.  So the command
                is:     

<p>
<code>
                        mount /dev/hdb1 /mnt/tmp
</code>
<p>
        Use a cpio or tar command to copy everything
<p>
                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:
<p>
<code>
                        cd /usr/ && find . -print0 | cpio -p0vumd /mnt/tmp
</code><p>
                        * note: must do this as root -- to preserve 
                          permissions and ownership!
<p>

                I realize this is an ugly looking command.  However,
                we'll explain it step by step:
<p>
                        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.

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

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

<p>
        * (optionally) Make all these files "immutable"
<p>
                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.  
<p>
                To do this use the command:
<p>
<code>
                        cd /mnt/tmp && chattr -R +i *
</code><p>
                ... or (to just do the files and not the directories):
<p><code>
                        find /mnt/tmp -type f -print0 | xargs -0 chattr +i
</code><p>
                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.  
<p>
                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).
<p>
                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.
<p>
                (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).
<p>
        Boot from an alternate partition or a rescue disk
<p>
                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.
<p>
                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.
<p>
                * Note to distributors and installation script 
                  maintainers:  PLEASE INCLUDE AN OPTION TO CREATE
                  AN ALTERNATIVE BOOT PARTITION IN YOUR PRODUCTS
<p>
        Rename the source directory
<p>
                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.
<p>
                So we issue a command like:
<p>
<pre>
                        cd $NORMALROOT          # (wherever you mounted 
                                                # your normal root filesystem)
                        mv usr usr.old
</pre>
<p>
        Make a new directory by that name (a mount point)
<p>
                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.
<p>
                So we use "ls -ld usr.old" to see the owner, 
                group, and permissions -- whice are typically
                like:
<p>
<pre>
drwxr-xr-x  20 root     root         1024 Aug  1 22:10 usr
</pre><p>
                ... and we use the commands:
<p><pre>
                        chown root.root usr
                        chmod 755 usr
</pre><p>
                ... to finish the new mount point.
<p>
                (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).
<p>
                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.
<p>
        Mount the new fs on the new mount point
<p>
               I like to do this just to test things.

<p>
        Update your /etc/fstab to make this permanent
<p>
                Now you can edit your /etc/fstab (which should
                actually be under whatever mount point your using
                during this "alternative root/rescue" session)
<p>
                You'll add a line like:
<p>
<pre>
/dev/sdb1     /usr               ext2   defaults,ro 1 2
</pre><p>
               ... to it.
<p>
                (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).
<p>
        * (optionally) Update your tripwire database
<p>
                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).
<p>
                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.
<p>
               For more info about tripwire see:
<p>
Tripwire (<a href="ftp://coast.cs.purdue.edu/pub/COAST/Tripwire">ftp://coast.cs.purdue.edu/pub/COAST/Tripwire</a>)
<p>
                To get it to compile cleanly under Linux look at
                the patch I wrote for it:
<p>
Tripwire Patch for Linux (<a href="http://www.starshine.org/linux/tripwire-linux.patch">http://www.starshine.org/linux/tripwire-linux.patch</a>)<p>
               (no .html extension on that -- its just a text file).
<p>
                (* 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).
<p>
        Test
<p>
                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.
<p>
        Remove the old tree at your leisure.
<p>
                When you're satisfied that everthing was copied 
                O.K. -- you can simply remove all the old copies
                using the command:
<p><code>
                        rm -fr /usr.old
</code><p>
                Now you finally have all that extra disk space back.
<p>
        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).
<p>
        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:
<p>
<pre>
# &lt;device&gt;    &lt;mountpoint&gt;   &lt;filesystemtype&gt; &lt;options&gt; &lt;dump&gt; &lt;fsckorder&gt;

/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      
</pre>
<p>
        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:
<p>
<pre>
        -r-sr-x---   1 root     wheel       26116 Jun  3  1996 /bin/mount
</pre><p>
        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).
<p>
        For more info about sudo see:
<p>
                Sudo Home Page
 (<a href="http://www.courtesan.com/courtesan/products/sudo/">http://www.courtesan.com/courtesan/products/sudo/</a>)<p>
                FTP sudo:
 (<a href="ftp://ftp.cs.colorado.edu/pub/sysadmin/sudo">ftp://ftp.cs.colorado.edu/pub/sysadmin/sudo</a><p>
        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.
<p>--Jim
<P> <hr> <P>                                               
<!--================================================================-->
<a name="cppx"></a>
<h3><img align=bottom alt=" " src="../gx/ques.gif">
C++ Integrated Programming Enviroment for X...</h3>
Date: Wed, 17 Sep 1997 17:56:30 -0700<br>From: <a href="mailto:trustno1@kansas.net">trustno1@kansas.net</a><p>
<P><B>
Dear Answer Guy,<br>
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?
</B><P>
<img align=bottom alt=" " src="../gx/ans2.gif">
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.
<p>
        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.
<p>
        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).
<p>--Jim
<P> <hr> <P>

<!--================================================================-->
<a name="lynx"></a>
<h3><img align=bottom alt=" " src="../gx/ques.gif">
LYNX-DEV new to LYNX</h3>
Date: Tue, 16 Sep 1997 22:06:45 -0700
<P><B>
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!
</B><P>
<img align=bottom alt=" " src="../gx/ans2.gif">
        The web is not the FULL INTERNET!

<p>
        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.
<p>
        There is no such thing as "browsing" the "full Internet."
        Indeed, the phrase "full Internet" is meaningless.
<p>
        As to your implicit question:

<p>
                Will you be able to browse all public web sites
                using Lynx?
<p>
        ... the answer is no.
<p>
        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).
<p>
        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).
<p>
        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."  
<p>
        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).
<p>
        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.
<p>
        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:
<p>
                <I>"Go get a 'real' browser, punk!"</I>
<p>
        ... (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!).
<p>
        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).
<p>
        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).
<p>
        So, there are a number of places on the "full Internet" that 
        you can't adequately or comfortably browse with Lynx.
<p>
        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.  
<p>
        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?).
<p>
        The final bit of good news is this:
<p>
                <I>"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."</I>
<p>
        When we say "hypertext" they seem to hear "hype OR text"
<p>
        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."
<p>
               <I> "* 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")."</I>
<p>
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"
<p>--
Jim 


<P> <hr> <P>           
<!--================================================================-->
<center><H5>Copyright &copy; 1997, James T. Dennis <BR> 
Published in Issue 22 of the Linux Gazette October 1997</H5></center>
<P> <hr> <P> 
<!--================================================================-->
<A HREF="./lg_toc22.html"><IMG SRC="../gx/indexnew.gif" ALT="[ TABLE OF 
CONTENTS ]"></A> <A HREF="../index.html"><IMG SRC="../gx/homenew.gif" 
ALT="[ FRONT PAGE ]"></A> 
<A HREF="lg_bytes22.html"><IMG SRC="../gx/back2.gif" ALT=" Back "></A>
<A HREF="./gm.html"><IMG SRC="../gx/fwd.gif" ALT=" Next "></A>
<!--startcut =======================================================  -->
</body> 
</html>
<!--endcut =========================================================  -->