9635 lines
342 KiB
Plaintext
9635 lines
342 KiB
Plaintext
|
|
|||
|
Linux Gazette... making Linux just a little more fun!
|
|||
|
|
|||
|
Copyright © 1996-97 Specialized Systems Consultants, Inc.
|
|||
|
linux@ssc.com
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
WELCOME TO LINUX GAZETTE! (TM)
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Sponsored by:
|
|||
|
|
|||
|
INFOMAGIC
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Our sponsors make financial contributions toward the costs of
|
|||
|
publishing Linux Gazette. If you would like to become a sponsor of LG,
|
|||
|
e-mail us at sponsor@ssc.com.
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
TABLE OF CONTENTS ISSUE #15
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
* The Front Page
|
|||
|
* The MailBag
|
|||
|
+ Help Wanted -- Article Ideas
|
|||
|
+ General Mail
|
|||
|
* More 2 Cent Tips
|
|||
|
+ Automatic Term Resizing
|
|||
|
+ Background Images
|
|||
|
+ Changing Directories
|
|||
|
+ Colorized Prompts
|
|||
|
+ Getting less to View gzipped Files
|
|||
|
+ Lowercased Filenames
|
|||
|
+ More on Xterm Tittlebar Tip
|
|||
|
+ A Quick & Dirty getmail Script
|
|||
|
+ Syslog 2c Tip Revised
|
|||
|
+ vi/ed Tricks and the .exrc File
|
|||
|
* News Bytes
|
|||
|
+ News in General
|
|||
|
+ Software Announcements
|
|||
|
* The Answer Guy, by James T. Dennis
|
|||
|
+ fetchmail and POP3 Correction
|
|||
|
+ Automated File Transfer over Firewall
|
|||
|
+ chown Question
|
|||
|
+ Copy from Xterm to TkDesk
|
|||
|
+ File System Debugger
|
|||
|
+ IP Fragmentation Attack Description
|
|||
|
+ Mail Server Problem
|
|||
|
+ Mail and Sendmail
|
|||
|
+ Mounted vfat File Systems
|
|||
|
+ POP3 E-Mail
|
|||
|
+ Pseudo Terminal Device Questions
|
|||
|
+ root login Bug in Linux
|
|||
|
+ Sendmail-8.8.4 and Linux
|
|||
|
+ wu-ftpd Problems
|
|||
|
* Clueless at the Prompt: A New Column for New Users, by Mike List
|
|||
|
* Big Brother Network Monitoring System, by Paul M. Sittler
|
|||
|
* Date & Its Switches, by Larry Ayers
|
|||
|
* Debian Linux Installation & Getting Started, by Boris D. Beletsky
|
|||
|
* Graphics Muse, by Michael J. Hammel
|
|||
|
* Learning about Security, by Jay Sprenkle
|
|||
|
* Linux & Midi, by Dave Phillips
|
|||
|
* New Release Reviews, by Larry Ayers
|
|||
|
+ Amaya
|
|||
|
+ Slrn & Slrnpull: Sucking Down the News
|
|||
|
* Sigrot: BBS Taglines for the Net, by Paul Anderson
|
|||
|
* Thoughts on Multi-threading by Andrew L. Sandoval
|
|||
|
* Usenix/Uselinux Notes by Arnold Robbins
|
|||
|
* What You Can Do with tcpd, by Kelly Spoon
|
|||
|
* The Back Page
|
|||
|
+ About This Month's Authors
|
|||
|
+ Not Linux
|
|||
|
|
|||
|
|
|||
|
|
|||
|
The Answer Guy
|
|||
|
|
|||
|
|
|||
|
Weekend Mechanic will return next month.
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
TWDT 1 (text)
|
|||
|
TWDT 2 (HTML)
|
|||
|
are files containing the entire issue: one in text format, one in
|
|||
|
HTML. They are provided strictly as a way to save the contents as one
|
|||
|
file for later printing in the format of your choice; there is no
|
|||
|
guarantee of working links in the HTML version.
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Got any great ideas for improvements! Send your comments, criticisms,
|
|||
|
suggestions and ideas.
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
This page written and maintained by the Editor of Linux Gazette,
|
|||
|
gazette@ssc.com
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
"Linux Gazette...making Linux just a little more fun!"
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
The Mailbag!
|
|||
|
|
|||
|
Write the Gazette at gazette@ssc.com
|
|||
|
|
|||
|
CONTENTS:
|
|||
|
* Help Wanted -- Article Ideas
|
|||
|
* General Mail
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
HELP WANTED -- ARTICLE IDEAS
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Date: Wed, 05 Feb 1997 22:34:04 -0800
|
|||
|
Subject: Copy from xterm to TkDesk
|
|||
|
From: Steve Varadi, svaradi@sprynet.com
|
|||
|
|
|||
|
|
|||
|
I have a question maybe someone know simpler solution for this. I'm
|
|||
|
using TkDesk because very easy to use and most of the keystroke same
|
|||
|
as in Win95. If I want to copy something from xterm to an editble file
|
|||
|
I do following:
|
|||
|
* Select area in xterm
|
|||
|
* Open Emacs
|
|||
|
* Paste recent selection
|
|||
|
* Save file
|
|||
|
* Open this file with TkDesk Editor and working with it comfortable
|
|||
|
like in Win95 enviroment.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Is it any simpler procedure to copy something directly from xterm to
|
|||
|
TkDesk Editor???
|
|||
|
|
|||
|
Thanks:
|
|||
|
Steve
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Date: Sat, 08 Feb 1997 00:46:33 -0600
|
|||
|
Subject: suggestion
|
|||
|
From: Daniel Strong, daniels@voyageronline.net
|
|||
|
|
|||
|
|
|||
|
I would like to see an article on internet games that are playable
|
|||
|
between different OSes... Linux and Win95, Win3.11
|
|||
|
|
|||
|
Or just internet games in generall....:)
|
|||
|
|
|||
|
thanks..
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Date: Tue, 120dd1 Feb 1997 17:39:52 +0100
|
|||
|
Subject: Help formatting a hard disk
|
|||
|
From: Olivier DALOY, daloy@cri.ens-cachan.fr
|
|||
|
|
|||
|
|
|||
|
I am desperately trying to install Sparc Linux on a 1+ box. And I
|
|||
|
wonder how to format a Hard disk drive, from Sun OS, in Ext2FS type.
|
|||
|
If you could help me on that point, I would appreciate so much !
|
|||
|
|
|||
|
BTW too, congratulations for the job you do, I imagine that it's not
|
|||
|
so easy !!! :-)))
|
|||
|
|
|||
|
-- Olivier DALOY
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Date: Mon, 17 Feb 1997 13:41:05 +0000 (GMT)
|
|||
|
Subject: Animated Gifs From: Andrew Philip Crook,
|
|||
|
shu96apc@reading.ac.uk
|
|||
|
|
|||
|
|
|||
|
I have made some animated gifs for my web page and they should loop.
|
|||
|
However, on Netscape 2.02 + for most unix platforms they stop after
|
|||
|
one cycle.... why!
|
|||
|
|
|||
|
.... and how can i make them loop?
|
|||
|
|
|||
|
PS. Great Mag
|
|||
|
Andrew Crook.
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Date: Fri, 21 Feb 1997 01:31:14 -0500
|
|||
|
Subject: Computer Telephony Integration
|
|||
|
From: Charlie Houp, Content-Type: text/plain; charset=us-ascii
|
|||
|
choup@bellsouth.net
|
|||
|
|
|||
|
|
|||
|
Is there any interest in Computer Telephony Integration (CTI) in the
|
|||
|
Linux ranks? Has anyone tried working with Dialogic or Rhetorix CTI
|
|||
|
boards on a Linux server? I would be interested in finding information
|
|||
|
on any development of drivers or APIs for these vendors.
|
|||
|
|
|||
|
Thanks
|
|||
|
Charlie
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
GENERAL MAIL
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Date: Sun, 02 Feb 1997 16:27:02 -0800
|
|||
|
Subject: Linux Security
|
|||
|
From: jtmurphy, jtmurphy@ecst.csuchico.edu
|
|||
|
|
|||
|
|
|||
|
I notice there is a lack of discussion on Linux Security in LG.
|
|||
|
Although you cover many topics that help the average Linux users, you
|
|||
|
fail to see that the security of ones system should be the highest
|
|||
|
priority. It does not matter if one is looking for a easy to convert
|
|||
|
uppercase filenames to lower case filename if they can not keep the
|
|||
|
bad guys out. Please include more discussion on it.
|
|||
|
|
|||
|
PS. Check out my Web Page (Address Below).
|
|||
|
Jason T. Murphy The Linux Security Home Page ->
|
|||
|
http://www.ecst.csuchico.edu/~jtmurphy
|
|||
|
|
|||
|
(Actually, I do realize it. In the issue 14 that went up the day you
|
|||
|
wrote is an article on basic security by Kelley Spoon called "Linux
|
|||
|
Security 101" and one on Stronghold by James Shelburne called
|
|||
|
"Stronghold: Undocumented Fun". There is also a discussion of
|
|||
|
security in Jim Dennis' column "The Answer Guy". --Editor)
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Date: Sat, 01 Feb 1997 15:14:52 -0500
|
|||
|
Subject: Great Magazine
|
|||
|
From: "Stephen J. Pellicer", stephen@adata.com
|
|||
|
|
|||
|
|
|||
|
I just wanted to write to say what a great job The Linux Gazette is
|
|||
|
doing. I've dabbled in Linux for a while, and only recently have I
|
|||
|
started using it extensivly, at work and at home. Like Linux itself
|
|||
|
online information for the OS is a hit or miss affair. Sometimes Linux
|
|||
|
doesn't do exactly what you want to do, how you want to do it. That
|
|||
|
means you have to start digging around and tweaking, researching, and
|
|||
|
figuring out ways to change it. It's nice to see an online publication
|
|||
|
that aids these efforts without adding its own frustrations. Your
|
|||
|
publicaiton is sharp and a service to the Linux community.
|
|||
|
|
|||
|
Thanks,
|
|||
|
Stephens
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Date: Mon, 3 Feb 1997 21:53:41 -0500 (EST)
|
|||
|
Subject: TWDT-HTML-14 broken
|
|||
|
From: Ken Cantwell, cantwell@afterlife.ncsc.mil
|
|||
|
|
|||
|
|
|||
|
Issue 14's TWDT (HTML) is broken. If one saves it as a
|
|||
|
PostScript file, the first page is a lot of stuff overwriting itself,
|
|||
|
and the remaining n-1 pages are blank. And n is quite large.
|
|||
|
|
|||
|
Ken Cantwell
|
|||
|
|
|||
|
(Yes, you are right. It is broken. And I didn't have time to fix it
|
|||
|
until late in the month. Very sorry. --Editor)
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Date: Mon, 3 Feb 1997 18:36:47 CDT
|
|||
|
Subject: On XV
|
|||
|
From: "Jarrod Henry", jarrodh@ASMS3.dsc.k12.ar.us
|
|||
|
Organization: Arkansas School for Math & Science
|
|||
|
|
|||
|
Hiya...
|
|||
|
I was reading LG #14 , and something struck my eye in weekend
|
|||
|
Mechanic. Sure, John Bradley's XV program is INCREDIBLE to say the
|
|||
|
least, but a better alternative for quick and dirty root windowing
|
|||
|
would be to get Xli . Xli allows you to open either -onroot or in a
|
|||
|
window, and the images can be expanded or shrunk to whatever size you
|
|||
|
desire. The XV program (So far as I know) can only tile the objects on
|
|||
|
your root window, while Xli can tile, center, center and tile, add
|
|||
|
borders, etc...
|
|||
|
Xli can be found on sunsite, and thank you for producing such an
|
|||
|
INFORMATIVE and HELPFUL tool to this energetic Linux user :)
|
|||
|
|
|||
|
Jarrod Henry
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Date: Thu, 06 Feb 1997 08:50:05 -0500
|
|||
|
Subject: My Vim Article From: Jens Wessling, mailto:jwesslin@erim.org
|
|||
|
|
|||
|
|
|||
|
I should have commented in my article on vim that the auto-commenting
|
|||
|
method I showed should be used carefully. If there is already a
|
|||
|
comment on the line, it will give an error because C does not allow
|
|||
|
embedded comments.
|
|||
|
|
|||
|
--Jens Wessling
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Date: Thu, 6 Feb 1997 14:22:44 +0100 (GMT+0100)
|
|||
|
Subject: beating heart
|
|||
|
From: Jesper Pedersen, blackie@imada.ou.dk
|
|||
|
|
|||
|
|
|||
|
Your beating haert is very cute, but....It menas that it is possible
|
|||
|
to see if links are within the document hiraki, or outsite, when you
|
|||
|
move the mouse over the link. (which matters when one reads it
|
|||
|
offline). So please reconsider.
|
|||
|
|
|||
|
Kind Regards Jesper.
|
|||
|
|
|||
|
(Okay. Good enough reason for me. We turned it off the first week --
|
|||
|
never meant to leave it on forever anyway. It can be annoying after
|
|||
|
awhile. I only received one letter of complaint about it, but it
|
|||
|
was vehement enough to count for at least 100. I lost it somehow or
|
|||
|
I would have printed it too. --Editor)
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Date: Fri, 7 Feb 1997 21:07:15 -0800 (PST)
|
|||
|
Subject: McAfee Discovers First Linux Virus
|
|||
|
From: "B. James Phillippe, bryan@Terran.ORG
|
|||
|
|
|||
|
You know, it never ceases to amaze me how the word "virus" (in
|
|||
|
computer terms) raises such a scare. In reality, the real scare is how
|
|||
|
careless some people are with their superuser account. The following
|
|||
|
shell script:
|
|||
|
|
|||
|
#!/bin/rm -rf /
|
|||
|
|
|||
|
causes a hell of a lot more damage then any virus I can think of. Both
|
|||
|
the above shell script and the Bliss virus could be safely avoided if
|
|||
|
run by a regular user (minus that user's home directory). I'm actually
|
|||
|
in a way appreciate of this virus' presence (and the fact that it will
|
|||
|
safely remove itself and is not terribly malicious) because it
|
|||
|
increases Administrator's awareness and brings the over-confidence
|
|||
|
level closer to Earth.
|
|||
|
|
|||
|
My point: Virii are bad. So are typos. Think before you su. =]
|
|||
|
|
|||
|
# B. James Phillippe # Network/Sys Admin Terran.ORG #
|
|||
|
# bryan@terran.org# http://w3.terran.org/~bryan #
|
|||
|
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Date: Thu, 30 Jan 1997 00:02:21 -0500
|
|||
|
Subject: Linux Journal stuff
|
|||
|
From: Rick Hohensee, humbubba@cqi.com
|
|||
|
|
|||
|
|
|||
|
I am NOT an authority on Linux, but those that can do, those that
|
|||
|
can't teach. I have some stuff that may be one half step ahead of some
|
|||
|
readers. Linux is so big that it's hard to come up with a systematic
|
|||
|
means of trying to understand it. It's more a culture than a system.
|
|||
|
Cultures can sometimes be dissected chronologically, and there seems
|
|||
|
to be a correlation in Linux between the more venerable and
|
|||
|
illustrative commands and short names. Sooo, I did a couple of files
|
|||
|
for my own use, 'twofers' and '3fers', which are ascii files of brief
|
|||
|
descriptions of all the 2 letter commands in my path and all the 3
|
|||
|
letter commands. If you want 'em reply. ( I'm in windog at the moment
|
|||
|
and can't get at them.) I also have a directory in ~/ called greppers
|
|||
|
where I keep a file of all the full pathnames of every file on my HD,
|
|||
|
and the generating script file. I grep it frequently. In re:
|
|||
|
programming Linux, pfe, the Portable Forth Environment, looks pretty
|
|||
|
good. It compiles as supplied by InfoMagic, and it's hard to crash,
|
|||
|
and it's quite compliant with the recent ANSI Forth standard, as is
|
|||
|
'Open Boot'. More on Forth at my web page.
|
|||
|
|
|||
|
Rick Hohensee, http://cqi.com/~humbubba
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Date: Tue, 18 Feb 1997 12:32:15 +0000
|
|||
|
Subject: Put a date in the Table of Contents
|
|||
|
From: sewilco@fieldday.mn.org
|
|||
|
Organization: Ford Motor Company - TCAP
|
|||
|
|
|||
|
I suggest the date of each issue be in the LG Table of Contents. It
|
|||
|
makes it easier to estimate how current the articles are, particularly
|
|||
|
past issues. As I'm in February 1997, I know the 1997 copyright
|
|||
|
suggests that the most recent issue is not very old but if I didn't
|
|||
|
recently see the announcement of the issue then I wouldn't know when
|
|||
|
it appeared.
|
|||
|
|
|||
|
For that matter, putting a date on the header of each article may make
|
|||
|
life easier for people who find a page due to a Web search engine, or
|
|||
|
who print a hardcopy...
|
|||
|
|
|||
|
(Okay, see what I can do to make this more clear for both TOC and
|
|||
|
articles. It's true the copyright date is the way to tell now.
|
|||
|
--Editor)
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Date: Fri, 21 Feb 1997 12:50:00 +0100 (MEZ)
|
|||
|
Subject: Linux Gazette
|
|||
|
From: Alex
|
|||
|
|
|||
|
After receiving several complaints about some article I posted it now
|
|||
|
is time to send one myself. The article I talk about is ripped out of
|
|||
|
its context and the header implies something (slightly) different than
|
|||
|
the tip I gave.
|
|||
|
|
|||
|
The article: "How to truncate /var/adm/messages" in Issue #12. Not
|
|||
|
mentioned: The messages must be saved. Simply doing cat /dev/null >
|
|||
|
/var/adm/messages was not good enough. Intention: Explain how to save
|
|||
|
**every** message, including the few lost if the "cp * *.old; cat
|
|||
|
/dev/null> *" was used.
|
|||
|
|
|||
|
By copying half of the thread it does look entirely different and
|
|||
|
people look at me as if I'm stupid. The poster in Issue #13,
|
|||
|
gne@ffa.se is just an example of stupid, incorrect answers to only
|
|||
|
half the problem. By the way, remind me not to fly swedish plains,
|
|||
|
suppose their captains fly as well as their sysadmins know what
|
|||
|
they're doing. Ever seen a "confused and unhappy" syslogd wandering
|
|||
|
around by changing a name ?
|
|||
|
|
|||
|
Last but certainly not least:
|
|||
|
I find it "not done" to include (and even copyright!!!) my posting in
|
|||
|
this gazette without asking or even notifying me. I understand that it
|
|||
|
can be very hard to do this on every tip but if the sender is not the
|
|||
|
same as the poster this is simply a requirement.
|
|||
|
|
|||
|
Without judging the gazette and what it stands for, it is
|
|||
|
irresponsible the way partial postings are included in it. Incorrect
|
|||
|
information is now on the Internet and it is irreversible. People will
|
|||
|
be reading it for years and years. Thank you very much.
|
|||
|
|
|||
|
This mail does need an answer, this would only be fair.
|
|||
|
|
|||
|
Alex.
|
|||
|
|
|||
|
(Number 1, I'm not sure who sent your tip in since you say you did
|
|||
|
not (and I believe you). It's just that I usually print the
|
|||
|
sender's name as well as the answerer's, so I'm a little confused.
|
|||
|
Looking at it without your letter, I would have said you sent it.
|
|||
|
Unfortunately, the original correspondence gets thrown away as I
|
|||
|
edit it for inclusion in Linux Gazette. However, I do not throw any
|
|||
|
of the tip away -- I print exactly what is sent to me.
|
|||
|
Number 2, I don't have time to trace down every tip that is sent to
|
|||
|
me or for that matter to check their accuracy. That's why LG comes
|
|||
|
with a "no warranty" clause. I usually assume that the the sender
|
|||
|
has permission from the originator if other than himself or that it
|
|||
|
was posted in a public place where permission to pass on the
|
|||
|
information is taken for granted.
|
|||
|
Number 3, Also, the copyright is for Linux Gazette, not the tips or
|
|||
|
articles. Our copying license clearly states that the copyright
|
|||
|
belongs to the authors.
|
|||
|
I'm very sorry that this has caused you embarrassment. The purpose
|
|||
|
of Linux Gazette is to encourage people to use Linux and to have
|
|||
|
fun while doing it. Someone thought your tip was a good one or they
|
|||
|
would not have sent it in. I am very sorry that only part of it
|
|||
|
reached us. --Editor)
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Published in Linux Gazette Issue 15, March 1997
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
[ TABLE OF CONTENTS ] [ FRONT PAGE ] Next
|
|||
|
|
|||
|
This page written and maintained by the Editor of Linux Gazette,
|
|||
|
gazette@ssc.com
|
|||
|
Copyright © 1997 Specialized Systems Consultants, Inc.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
"Linux Gazette...making Linux just a little more fun! "
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
MORE 2<> TIPS!
|
|||
|
|
|||
|
|
|||
|
Send Linux Tips and Tricks to gazette@ssc.com
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
CONTENTS:
|
|||
|
* Automatic Term Resizing
|
|||
|
* Background Images
|
|||
|
* Changing Directories
|
|||
|
* Colorized Prompts
|
|||
|
* Getting less to View gzipped Files
|
|||
|
* Lowercased Filenames
|
|||
|
* More on Xterm Tittlebar Tip
|
|||
|
* A Quick & Dirty getmail Script
|
|||
|
* Syslog 2c Tip Revised
|
|||
|
* vi/ed Tricks and the .exrc File
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
AUTOMATIC TERM RESIZING
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Date: Mon, 17 Feb 1997 21:36:57 -0800 (PST)
|
|||
|
From: pb@europa.com
|
|||
|
|
|||
|
Heya,
|
|||
|
I spend a lot of time telnetting to my ISP from various sized terms
|
|||
|
under X and from the good ol' prompt. Typing "stty cols x rows y" got
|
|||
|
tedious, so I found a nice solution: Putting "eval `resize`" in my
|
|||
|
.cshrc. Now my remote terms automatically resize themselves to
|
|||
|
whatever convoluted geometry I've got locally.
|
|||
|
|
|||
|
Cheers,
|
|||
|
|
|||
|
Peat
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
BACKGROUND IMAGES
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Date: Tue, 18 Feb 1997 15:57:17 -0500
|
|||
|
From: Christopher Fortin, cfortin@bbn.com
|
|||
|
|
|||
|
Hi.
|
|||
|
I use fvwm2, and like to have four virtual screens, each with a
|
|||
|
different background. However, I found myself editing my .fvwm2rc file
|
|||
|
alot to change those backgrounds ( kept getting bored with the
|
|||
|
selection ). So I came up with a little tcl script to do the work for
|
|||
|
me. Now I just have a directory ( called .backgrounds ) filled with
|
|||
|
.xpm files that I like as backgrounds. On login, my .login file calls
|
|||
|
randBG.tcl, an executable tcl file thats in your path, ( if tclsh is
|
|||
|
not in /usr/bin, change the first line ).
|
|||
|
|
|||
|
#---CUT HERE------randBG.tcl---------------------------
|
|||
|
#! /usr/bin/tclsh
|
|||
|
|
|||
|
proc randomInit {seed} {
|
|||
|
global rand
|
|||
|
set rand(ia) 9301; #multiplier
|
|||
|
set rand(ic) 49297; #Constant
|
|||
|
set rand(im) 233280; #Divisor
|
|||
|
set rand(seed) $seed; #Last Result
|
|||
|
}
|
|||
|
|
|||
|
proc random {} {
|
|||
|
global rand
|
|||
|
set rand(seed) \
|
|||
|
[expr ($rand(seed)*$rand(ia) + \
|
|||
|
$rand(ic)) % $rand(im)]
|
|||
|
return [expr $rand(seed)/double($rand(im))]
|
|||
|
}
|
|||
|
|
|||
|
proc randomRange { range } {
|
|||
|
expr int([random]*$range)
|
|||
|
}
|
|||
|
|
|||
|
randomInit [pid]
|
|||
|
random
|
|||
|
randomRange 100
|
|||
|
|
|||
|
### CHANGE THIS #####################
|
|||
|
set BGDIR /your.home.dir/.backgrounds
|
|||
|
#
|
|||
|
|
|||
|
exec /bin/rm -f $BGDIR/desk1.xpm
|
|||
|
exec /bin/rm -f $BGDIR/desk2.xpm
|
|||
|
exec /bin/rm -f $BGDIR/desk3.xpm
|
|||
|
|
|||
|
set files [ exec ls $BGDIR ]
|
|||
|
set nfiles [llength $files]
|
|||
|
|
|||
|
set rnd1 [eval randomRange $nfiles]
|
|||
|
set rnd1file [lindex $files $rnd1]
|
|||
|
exec ln -s $BGDIR/$rnd1file $BGDIR/desk1.xpm
|
|||
|
|
|||
|
set rnd2 [eval randomRange $nfiles]
|
|||
|
set rnd2file [lindex $files $rnd2]
|
|||
|
exec ln -s $BGDIR/$rnd2file $BGDIR/desk2.xpm
|
|||
|
|
|||
|
set rnd3 [eval randomRange $nfiles]
|
|||
|
set rnd3file [lindex $files $rnd3]
|
|||
|
exec ln -s $BGDIR/$rnd3file $BGDIR/desk3.xpm
|
|||
|
#------------
|
|||
|
#-----CUT HERE-----------------------------------------
|
|||
|
|
|||
|
|
|||
|
|
|||
|
The rand part of this was from Welch's TCL book. Now you just need
|
|||
|
.fvwm2rc to use the ~/.backgrounds/desk?.xpm, like
|
|||
|
|
|||
|
#----------------------------------------------
|
|||
|
####
|
|||
|
# Set Up Backgrounds for different desktops.
|
|||
|
####
|
|||
|
Module FvwmBacker
|
|||
|
|
|||
|
*FvwmBackerDesk 0 xpmroot ./.backgrounds/desk0.xpm
|
|||
|
*FvwmBackerDesk 1 xpmroot ./.backgrounds/desk1.xpm
|
|||
|
*FvwmBackerDesk 2 xpmroot ./.backgrounds/desk2.xpm
|
|||
|
*FvwmBackerDesk 3 xpmroot ./.backgrounds/desk3.xpm
|
|||
|
#----------------------------------------------
|
|||
|
|
|||
|
and also
|
|||
|
|
|||
|
#----------------------------------------------
|
|||
|
AddToFunc "InitFunction" Desk "I" 0 0
|
|||
|
+ "I" Exec xpmroot ./.backgrounds/desk0.xpm &
|
|||
|
#----------------------------------------------
|
|||
|
|
|||
|
to set desk0 prior to changing between desks. Just a little
|
|||
|
hack I thought someone might like. Note that this only changes
|
|||
|
desks 1-3, since I tend to keep desk0 constant ( I found a
|
|||
|
*really* nice background ).
|
|||
|
|
|||
|
Chris
|
|||
|
-- Dr. Christopher S. Fortin
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
CHANGING DIRECTORIES, A SHORT ENHANCEMENT TO PREVIOUS ARTICLE'S IDEA
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Date: Thu, 20 Feb 1997 19:13:38 +0100
|
|||
|
From: jurriaan, thunder7@xs4all.nl
|
|||
|
|
|||
|
In an article in the October Linux Journal (or was it Gazette - I
|
|||
|
don't know) by Marc Ewing (marc@redhat.com) a shell script was
|
|||
|
presented to allow a user to go to any directory on the system,
|
|||
|
without getting to all directories in between.
|
|||
|
|
|||
|
Much as this script apealed to me, it didn't work as I expected:
|
|||
|
|
|||
|
(A part of) my directory tree look like:
|
|||
|
|
|||
|
/root
|
|||
|
/root/angband
|
|||
|
/root/angband/2796
|
|||
|
/root/angband/2796/src
|
|||
|
/root/angband/2796/lib
|
|||
|
/root/angband/2796/lib/edit
|
|||
|
/root/angband/2796/lib/data
|
|||
|
/root/angband/myang
|
|||
|
/root/angband/myang/src
|
|||
|
/root/angband/myang/lib
|
|||
|
/root/angband/myang/lib/edit
|
|||
|
/root/angband/myang/lib/data
|
|||
|
etc.
|
|||
|
|
|||
|
Now when I typed cds myang, it offered me a choice between all
|
|||
|
directories containing myang. Instead I'd much prefer if the program
|
|||
|
decided that the one directory ending in myang would be the most
|
|||
|
logical choice.
|
|||
|
|
|||
|
I adapted this script, and the result is included below. Many comments
|
|||
|
are added, which you may or may not like. They may not even be
|
|||
|
correct, as I am not one of the guru-est of linux-dom, as Marc Ewing
|
|||
|
was described :-).
|
|||
|
|
|||
|
If you like it, use (ie include) it and let me know please.
|
|||
|
|
|||
|
If you don't, adapt it and then include it and let me know please.
|
|||
|
|
|||
|
If you really don't like it, consider this message not written.
|
|||
|
|
|||
|
Greetings from Holland,
|
|||
|
Jurriaan (thunder7@xs4all.nl)
|
|||
|
|
|||
|
function cds() {
|
|||
|
# no arguments? then do nothing
|
|||
|
if [ $# -ne 1 ]; then
|
|||
|
echo "usage: cds pattern"
|
|||
|
return
|
|||
|
fi
|
|||
|
|
|||
|
# $1 seems to disappear later on, or change value, so we declare a real
|
|||
|
target
|
|||
|
target=$1
|
|||
|
|
|||
|
# find $target in file $HOME/.dirs
|
|||
|
set "foo" `fgrep $target $HOME/.dirs`
|
|||
|
|
|||
|
# $# is the function return status, 1 means not found
|
|||
|
if [ $# -eq 1 ]; then
|
|||
|
echo "No matches"
|
|||
|
|
|||
|
# 2 means just one found
|
|||
|
elif [ $# -eq 2 ]; then
|
|||
|
cd $2
|
|||
|
|
|||
|
# we found a couple of possible directories
|
|||
|
else
|
|||
|
|
|||
|
# $ is the sign for end-of-line , -E tells fgrep to use extended regular
|
|||
|
# expressions
|
|||
|
# the \ before $ tells the shell not to see $ as an empty variable, but to
|
|||
|
# pass it right on to fgrep
|
|||
|
# if you are ever in doubt, use set -x to see what goes on in your scripts.
|
|||
|
# then use set +x to get rid of all the extra output
|
|||
|
set "foo" `fgrep -E $target\$ $HOME/.dirs`
|
|||
|
|
|||
|
# we found a directory at the end of the tree, ie myang$ selects
|
|||
|
# /root/angband/myang, but not /root/angband/myang/src.
|
|||
|
if [ $# -eq 2 ]; then
|
|||
|
cd $2
|
|||
|
|
|||
|
# I'm not sure - in DOS you must reset your variables, in Linux too?
|
|||
|
target=
|
|||
|
return
|
|||
|
else
|
|||
|
|
|||
|
# this is a copy of the original function: search for a match, even if it
|
|||
|
# is in the middle of a directory
|
|||
|
# one extra trick: we first count how many matches we find, using fgrep -c
|
|||
|
count=`fgrep -c $target $HOME/.dirs`
|
|||
|
|
|||
|
# stty size gives on my terminal 51 116 (ie a 116x51 screen)
|
|||
|
# cut -b1-3 gives then 51
|
|||
|
lines=`stty size | cut -b1-3`
|
|||
|
|
|||
|
# if more than 2/3 of the terminal, it's too much
|
|||
|
lines=$[$lines*2/3]
|
|||
|
if [ $count -gt $lines ]; then
|
|||
|
echo "More than $lines matches - respecify plea
|
|||
|
se"
|
|||
|
count=
|
|||
|
lines=
|
|||
|
target=
|
|||
|
return
|
|||
|
fi
|
|||
|
|
|||
|
# else we really go for it, just like the old version
|
|||
|
set "foo" `fgrep $target $HOME/.dirs`
|
|||
|
shift
|
|||
|
for x in $@; do
|
|||
|
echo $x
|
|||
|
done | nl -n ln
|
|||
|
echo -n "Number: "
|
|||
|
read C
|
|||
|
if [ "$C" = "0" -o -z "$C" ]; then
|
|||
|
return
|
|||
|
fi
|
|||
|
eval D="\${$C}"
|
|||
|
if [ -n "$D" ]; then
|
|||
|
#echo $D
|
|||
|
cd $D
|
|||
|
fi
|
|||
|
fi
|
|||
|
fi;
|
|||
|
}
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
COLORIZED PROMPTS
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Date: Mon, 24 Feb 1997 12:03:57
|
|||
|
From: arnim@rupp.de
|
|||
|
|
|||
|
#!/bin/sh
|
|||
|
|
|||
|
# script for colorized prompts, by arnim@rupp.de
|
|||
|
|
|||
|
# start this script to see all possible colors then
|
|||
|
# include this ...
|
|||
|
# ------------------------- snip ------------------------
|
|||
|
|
|||
|
BLACK='^[[30m'
|
|||
|
RED='^[[31m'
|
|||
|
GREEN='^[[32m'
|
|||
|
YELLOW='^[[33m'
|
|||
|
BLUE='^[[34m'
|
|||
|
MAGNETA='^[[35m'
|
|||
|
CYAN='^[[36m'
|
|||
|
WHITE='^[[37m'
|
|||
|
|
|||
|
BRIGHT='^[[01m'
|
|||
|
NORMAL='^[[0m'
|
|||
|
|
|||
|
# blink ;-)
|
|||
|
BLINK='^[[05m'
|
|||
|
REVERSE='^[[07m'
|
|||
|
|
|||
|
# sample bash-prompt
|
|||
|
PS1=$BRIGHT$YELLOW'\u:'$NORMAL'/\t\w\$ '
|
|||
|
|
|||
|
# ------------------------- snip ------------------------
|
|||
|
# .. in Your /etc/profile, .profile, .bashrc, .whatever, ...
|
|||
|
# ( don't cut & paste with the mouse, this would spoil the escape-characters )
|
|||
|
|
|||
|
echo $BLACK 'BLACK'
|
|||
|
echo $RED 'RED'
|
|||
|
echo $GREEN 'GREEN'
|
|||
|
echo $YELLOW 'YELLOW'
|
|||
|
echo $BLUE 'BLUE'
|
|||
|
echo $MAGNETA 'MAGNETA'
|
|||
|
echo $CYAN 'CYAN'
|
|||
|
echo $WHITE 'WHITE'
|
|||
|
|
|||
|
echo $BRIGHT$BLACK 'BRIGHT BLACK'
|
|||
|
echo $BRIGHT$RED 'BRIGHT RED'
|
|||
|
echo $BRIGHT$GREEN 'BRIGHT GREEN'
|
|||
|
echo $BRIGHT$YELLOW 'BRIGHT YELLOW'
|
|||
|
echo $BRIGHT$BLUE 'BRIGHT BLUE'
|
|||
|
echo $BRIGHT$MAGNETA 'BRIGHT MAGNETA'
|
|||
|
echo $BRIGHT$CYAN 'BRIGHT CYAN'
|
|||
|
echo $BRIGHT$WHITE 'BRIGHT WHITE'
|
|||
|
|
|||
|
echo $NORMAL
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
GETTING LESS TO VIEW GZIPPED FILES
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Date: Fri, 7 Feb 1997 11:21:41 -0800 (PST)
|
|||
|
From: Michael Bain, michael.bain@boeing.com
|
|||
|
|
|||
|
Here's how to use less to view gzipped files. Also, there is a way you
|
|||
|
can use this less feature that doesn't require temporary files and
|
|||
|
only needs one script file.
|
|||
|
|
|||
|
Put lesspipe.sh in your executable path.
|
|||
|
|
|||
|
lesspipe.sh:
|
|||
|
|
|||
|
#! /bin/sh
|
|||
|
case "$1" in
|
|||
|
*.Z) uncompress -c $1 2>/dev/null
|
|||
|
;;
|
|||
|
*.gz) gunzip -c $1 2>/dev/null
|
|||
|
;;
|
|||
|
esac
|
|||
|
|
|||
|
Set the environmental variable LESSOPEN='|lesspipe.sh %s'. (Don't
|
|||
|
forget the pipe '|' symbol.) This works with less version 2.90.
|
|||
|
|
|||
|
Michael Bain
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
LOWERCASED FILENAMES
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Date: Thu, 20 Feb 1997 00:38:10 GMT
|
|||
|
From: bubje@freemail.nl
|
|||
|
|
|||
|
Hello there
|
|||
|
We've all read all those ways to convert uppercased filenames to
|
|||
|
lowercased ones. But why did we need it? One reason is because when we
|
|||
|
unzip a file, all filenames are uppercase. Well, try this (much much
|
|||
|
shorter :) )
|
|||
|
|
|||
|
unzip -L filename.zip
|
|||
|
|
|||
|
This extracts the files as usual, but converts the filenames to
|
|||
|
lowercase, so there's no need to run any of those other two cent tips
|
|||
|
anymore... (and it's less to type, and faster)
|
|||
|
|
|||
|
Greatz
|
|||
|
Jan Gyselinck, wodan@cryogen.com
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
MORE ON XTERM TITLEBAR TIP
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Date: Tue, 11 Feb 1997 12:33:18 -0500
|
|||
|
From: Raul D. Miller, rdr@tad.micro.umn.edu
|
|||
|
|
|||
|
I don't know if you've touched on this yet -- if so, please ignore
|
|||
|
this message.
|
|||
|
|
|||
|
With bash, you can reliably set the titlebar. Just set the
|
|||
|
PROMPT_COMMAND variable to be a command that sets your title bar.
|
|||
|
|
|||
|
Aside: I usually use the shortened host name, with a # suffix if I'm
|
|||
|
root. The most portable way of testing if I'm root is [ -w / ]
|
|||
|
|
|||
|
Raul
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
A QUICK AND DIRTY GETMAIL SCRIPT
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Date: Sat, 15 Feb 1997 12:45:59 +0200 (GMT+0200)
|
|||
|
From: Markku J. Salama, msalama@hit.fi
|
|||
|
|
|||
|
Hi there!
|
|||
|
|
|||
|
Here is a quick and dirty script for fetching your mail without a POP
|
|||
|
account. It does it's thing by using telnet and ftp.
|
|||
|
|
|||
|
--------------------------------BEGIN SCRIPT------------------------------
|
|||
|
|
|||
|
#!/bin/sh
|
|||
|
# Brought to you by msalama@superfly.salama.fi
|
|||
|
# Caveat emptor: You use this entirely at your own risk, I'm not
|
|||
|
# responsible for any damages or loss of mail it might cause.
|
|||
|
|
|||
|
# There are 3 things to remember:
|
|||
|
|
|||
|
# 1) Make sure this script is readable & executable _only_ by you, it
|
|||
|
# contains password information!
|
|||
|
|
|||
|
# 2) You must have a .netrc-file in your home directory containing a
|
|||
|
# hostname, your username and your passwd for ftp. Make sure this file
|
|||
|
# is readable _only_ by you, too, and check the ftp man page for
|
|||
|
# details.
|
|||
|
|
|||
|
# 3) You must, of course, edit this script to provide all the necessary
|
|||
|
# passwords, usernames etc. for telnet. Also, the remote system must
|
|||
|
# have dd installed to empty the mailbox.
|
|||
|
|
|||
|
(echo open your.host # The sleeps are necessary so that telnet
|
|||
|
sleep 5 # doesn't get confused
|
|||
|
|
|||
|
echo your.username
|
|||
|
sleep 5
|
|||
|
|
|||
|
echo your.password # For your eyes only...
|
|||
|
sleep 10 # 10 sec. break, let the motd etc. scroll by
|
|||
|
|
|||
|
echo cp /remote/mailbox/file ./newmail # copy the mailbox file into
|
|||
|
sleep 5 # your remote home directory
|
|||
|
|
|||
|
echo dd if=/remote/mailbox/file of=/remote/mailbox/file # Empty the
|
|||
|
sleep 5 # mailbox
|
|||
|
|
|||
|
echo quit) | telnet -8E > /dev/null
|
|||
|
|
|||
|
(echo binary # Now go get the mail using
|
|||
|
echo get newmail # ftp. Handy for those folks
|
|||
|
echo delete newmail # who don't have a POP account.
|
|||
|
echo bye) | ftp your.host > /dev/null
|
|||
|
|
|||
|
mv ./newmail /local/mailbox/file # Move the new mail in place...
|
|||
|
|
|||
|
chmod go-rwx /local/mailbox/file # Just in case it's readable
|
|||
|
# by someone else.
|
|||
|
# All done! Go read them.
|
|||
|
|
|||
|
--------------------------------END SCRIPT--------------------------------
|
|||
|
|
|||
|
There. Have a nice spring & be an excellent person.
|
|||
|
|
|||
|
Markku Salama
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
SYSLOG 2C TIP REVISED
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Date: Sun, 9 Feb 1997 23:26:46 -0800 (PST)
|
|||
|
From: Ian Main, imain@vcc.bc.ca
|
|||
|
|
|||
|
Hi, just going through issue #14 of the linux gazzette, and I noticed
|
|||
|
the tip on logging *.* to a file so you can read it in an rxvt in X. I
|
|||
|
do a similar thing here, but rather than logging to a file, I log to a
|
|||
|
pipe (ah ha! Why didn't I think of that? :-) ).
|
|||
|
|
|||
|
Works really well. No disk space used, and you can just use cat to
|
|||
|
view it, and it scrolls along nicely.
|
|||
|
|
|||
|
To make a named pipe (FIFO) in /var/log/message-pipe:
|
|||
|
|
|||
|
mknod /var/log/message-pipe p
|
|||
|
|
|||
|
and add this to your /etc/syslog.conf (note the pipe symbol there.) :
|
|||
|
|
|||
|
*.* |/var/log/message-pipe
|
|||
|
|
|||
|
and finally, just type:
|
|||
|
|
|||
|
cat /var/log/message-pipe
|
|||
|
|
|||
|
Or of course.. you can stick it in a shells script or as the command
|
|||
|
rxvt runs when it starts.. whatever you like.
|
|||
|
|
|||
|
Hope you find it useful,
|
|||
|
|
|||
|
Ian
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
VI/ED TRICKS AND THE .EXRC FILE
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Date: Tue, 11 Feb 1997 16:28:30 -0600 (CST)
|
|||
|
From: Sean Murray, murrsea@ripco.com
|
|||
|
|
|||
|
The vi editor is built on the foundations of the "ed" editor. Whatever
|
|||
|
applies to ed applies to vi. So if you where wondering if there was a
|
|||
|
way to customize your vi sessions wonder no longer.
|
|||
|
|
|||
|
In your home directory create a file called ".exrc", every time vi
|
|||
|
starts it will parse that file and customize it's actions. The below 5
|
|||
|
lines are the contents of my .exrc file.
|
|||
|
|
|||
|
set tabstop=8
|
|||
|
map ^N {!}sort^M
|
|||
|
map v {^M!}fmt^M
|
|||
|
map V 1G^M!Gfmt^M
|
|||
|
map ^W :!ispell %^M^M:e!^M
|
|||
|
|
|||
|
I didn't include any comments because I don't know if the .exrc file
|
|||
|
has a comment character, I'll comment theses lines later?
|
|||
|
|
|||
|
Ok the "set" command allows you to set various parameters in vi; in
|
|||
|
this case I've set the tab stop to 8 characters. So when ever I enter
|
|||
|
a tabstop in insertion mode the cursor will move over 8 spaces (8
|
|||
|
spaces is what most printers will print tabs at regardless of your vi
|
|||
|
settings). But you can set it to what ever you like.
|
|||
|
|
|||
|
Sometimes when programming I manually set my tabstop to 4 spaces for
|
|||
|
indentation. To do this type in the following ":set tabstop=4". The
|
|||
|
nice thing about this is that the character is still really a tab and
|
|||
|
not a bunch of spaces, hence you don't force other ppl to view text
|
|||
|
with your spacing.
|
|||
|
|
|||
|
"map" maps a key or key combination to a sequence of commands. Note:
|
|||
|
that only ed commands work here so see view a list of ed commands
|
|||
|
while editing your .exrc file. It's a BAD idea to map key or key
|
|||
|
combinations that already have other meanings. The available
|
|||
|
combinations are:
|
|||
|
|
|||
|
letters: "g K k q V v"
|
|||
|
Control keys: "^A ^K ^O ^T ^W ^X"
|
|||
|
(where "^A" means press the control key and the letter a)
|
|||
|
Symbols: "_ * \ ="
|
|||
|
|
|||
|
(These above four lines where shamelessly stolen from ORA's _Learning
|
|||
|
the Vi Editor_; it's a must get for any vi user)
|
|||
|
|
|||
|
So what does "map ^W :!ispell %^M^M:e!^M" do -- well the "map" is the
|
|||
|
keyword telling vi to map the next character to the following
|
|||
|
commands. (If you map a key combination like ^W then remember to enter
|
|||
|
this by typing the control key and "v" first and then the key
|
|||
|
combination of control key and the letter "w".) Here we are mapping ^W
|
|||
|
to a set of commands. The first command is telling vi to execute the
|
|||
|
external program ispell with the current file we are editing (the
|
|||
|
variable that holds the current files name is "%"). The ^M is actually
|
|||
|
the character that appears after you have typed ^V and then typed the
|
|||
|
return key hence ^M denotes the instance of a carriage return. The
|
|||
|
last command is the vi command to reload the current file; this is
|
|||
|
necessary as the ispell program will update the file and not the vi
|
|||
|
buffer.
|
|||
|
|
|||
|
assuming that you have the external programs "ispell", "fmt" and
|
|||
|
"sort" the theses mappings should work. "map ^N {!}sort^M" will sort a
|
|||
|
paragraph. "map v {^M!}fmt^M" will format a paragraph. "map V
|
|||
|
1G^M!Gfmt^M" will format the whole document.
|
|||
|
|
|||
|
A final note: if you have the environment variable EXINIT set it will
|
|||
|
take precedence over the .exrc file settings.
|
|||
|
|
|||
|
Sean Murray
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Published in Linux Gazette Issue 15, March 1997
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
[ TABLE OF CONTENTS ] [ FRONT PAGE ] Back Next
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
This page maintained by the Editor of Linux Gazette, gazette@ssc.com
|
|||
|
Copyright © 1997 Specialized Systems Consultants, Inc.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
"Linux Gazette...making Linux just a little more fun!"
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
News Bytes
|
|||
|
|
|||
|
CONTENTS:
|
|||
|
* News in General
|
|||
|
* Software Announcements
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
NEWS IN GENERAL
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
NEW COMPUTER OPERATING SYSTEM RIDES SPACE SHUTTLE
|
|||
|
|
|||
|
20 Feb 1997
|
|||
|
A radically different new computer operating system is controlling an
|
|||
|
experiment on a Space Shuttle mission in late March. The experiment
|
|||
|
tests "hydroponics", a way of growing plants without soil that could
|
|||
|
eventually provide oxygen and food to astronauts. The computer
|
|||
|
controlling the experiment runs "Debian GNU/Linux", an operating
|
|||
|
system built by a group of 200 volunteer computer programmers, who
|
|||
|
give the system and all of its source code away for free. Details are
|
|||
|
available on the group's web site: http:/www.debian.org/.
|
|||
|
|
|||
|
The space shuttle experiment will fly on mission STS-83 in late March
|
|||
|
and early April. Sebastian Kuzminsky is an engineer working on the
|
|||
|
computer that controls the experiment, which is operated by
|
|||
|
Biosciences Corporation. Kuzminsky said "The experiment studies the
|
|||
|
growth of plants in microgravity. It uses a miniature '486
|
|||
|
PC-compatible computer, the Ampro CoreModule 4DXi. Debian GNU/Linux is
|
|||
|
loaded on this system in place of DOS or Windows. The fragility and
|
|||
|
power drain of disk drives ruled them out for this experiment, and a
|
|||
|
solid-state disk replacement from the SanDisk company is used in their
|
|||
|
place. The entire system uses only 10 watts", said Kuzminsky, as much
|
|||
|
electricity as a night-light. "The computer controls an experiment in
|
|||
|
hydroponics, or the growth of plants without soil", said Kuzminsky.
|
|||
|
"It controls water and light for the growing plants, and sends
|
|||
|
telemetry and video of the plants to the ground".
|
|||
|
|
|||
|
For additonal information:
|
|||
|
Bruce Perens, bruce@debian.org
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
LINUX SPONSORED PENGUIN
|
|||
|
|
|||
|
|
|||
|
|
|||
|
SWANSEA, UK, January 29th, 1997 -- Linux users sponsor a penguin at
|
|||
|
Bristol Zoo. A bunch of UK Linux fans and Linux World magazine
|
|||
|
confirms they have sponsored Linus Torvalds a penguin for a christmas
|
|||
|
present.
|
|||
|
|
|||
|
"It has taken a bit of time for the paperwork to arrive but it has now
|
|||
|
been scanned and can be found on http://penguin.uk.linux.org and is
|
|||
|
now leaving for Finland." claimed Alan Cox, who leads the penguin
|
|||
|
sponsoring group.
|
|||
|
|
|||
|
"It's not a suprise given the rumours circulating at usenet" said a
|
|||
|
prominent Linux developer, "This has been on the cards for some time".
|
|||
|
|
|||
|
|
|||
|
A plaque with the web site name on will also soon appear near the
|
|||
|
Penguin area at Bristol Zoo which has been selected as the place to
|
|||
|
sponsor the penguin.
|
|||
|
|
|||
|
According to Alan Cox, Linus who as well as creating the Linux OS is
|
|||
|
also responsible for the choice of a penguin as logo, also gets ten
|
|||
|
free tickets to the Zoo as a result of the sponsorship. "It's not
|
|||
|
clear how he gets to Bristol Zoo easily" admitted a spokesman who
|
|||
|
didn't wish to be named.
|
|||
|
|
|||
|
Linux is a high performance Unixlike OS that is winning major awards
|
|||
|
and accolades. More information on Linux and the Linux Market are
|
|||
|
available from http://www.uk.linux.org/ and Linux International,
|
|||
|
http://www.li.org.
|
|||
|
|
|||
|
Bristol Zoo was founded in 1836 and is one of the oldest Zoos in
|
|||
|
europe. It has an international reputation for its pioneering work
|
|||
|
with endangered species.
|
|||
|
|
|||
|
A penguin is... oh come on you must know what a penguin is...
|
|||
|
|
|||
|
For additional information: Alan Cox, Alan.Cox@linux.org
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
RSA 56BIT CHALLENGE
|
|||
|
|
|||
|
Fri, 21 Feb 1997
|
|||
|
Some of you may now know about the attempt to break 56bit RC5 as part
|
|||
|
of the RSA challenge. 40 and 48 bits have been done. 56bit is a
|
|||
|
colossal challenge but has been started. Whichever group cracks the
|
|||
|
key gets $1000.
|
|||
|
|
|||
|
We are trying to get as many Linux folks as possible involved in the
|
|||
|
challenge and hopefully as one giant group using the id
|
|||
|
|
|||
|
linux@linuxnet.org
|
|||
|
|
|||
|
and the sheer number of Linux users to stick ourselves on the top of
|
|||
|
the stats page. [as of Feb 21, the linuxnet team is on the top of the
|
|||
|
charts with 21million keys per second on 247 hosts.] In the unlikely
|
|||
|
event we do crack the key the money will go to the Linux Development
|
|||
|
Grant Fund (Linux International).
|
|||
|
|
|||
|
To join, ftp the clients from ftp://ftp.genx.net/pub/crypto/rc5 and
|
|||
|
run them with
|
|||
|
./clientname linux@linuxnet.org
|
|||
|
or for some clients
|
|||
|
./clientname -i linux@linuxnet.org
|
|||
|
|
|||
|
|
|||
|
SMP folks should run one client per CPU.
|
|||
|
|
|||
|
Non US sites please be aware of the potential crypto export rules...
|
|||
|
|
|||
|
You might want to run it via "nice". It will then just soak idle CPU.
|
|||
|
|
|||
|
For more info see:
|
|||
|
http://zero.genx.net/ -- info and stats - we want to be top!
|
|||
|
http://www.rsa.com/ -- RSA - the RC5 creators and challenge setters
|
|||
|
http://www.cobaltgroup.com/~roland/rc5.html -- linuxnet registry
|
|||
|
|
|||
|
Alan Cox, Alan.Cox@linux.org
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
YGGDRASIL APPROVED BY THE WORLD WIDE WEB CONSORTIUM TO DEVELOP "ARENA" WEB
|
|||
|
BROWSER.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
San Jose, CA -- February 17, 1997 -- The World Wide Web Consortium
|
|||
|
[W3C] has approved Yggdrasil Computing to coordinate future
|
|||
|
development of Arena, a powerful graphical web browser originally
|
|||
|
developed as the Consortium's research testbed. Under the agreement,
|
|||
|
Yggdrasil will undertake new development and support the developer
|
|||
|
community on the internet. Yggdrasil will issue regular releases,
|
|||
|
provide a centralized file archive and web site, integrate contributed
|
|||
|
enhancements and fixes, create mailing lists for developers and users,
|
|||
|
and facilitate widespread use of Arena by others.
|
|||
|
|
|||
|
Yggdrasil's additions to Arena will be placed under the "GNU General
|
|||
|
Public License", which allows unlimited distribution both for profit
|
|||
|
and not for profit, provided that source code is made freely
|
|||
|
available, including source code to any modifications. No exclusive
|
|||
|
rights have been given to Yggdrasil. Anybody could legally do what
|
|||
|
Yggdrasil is doing, although the Consortium now considers Yggdrasil
|
|||
|
the formal maintainer of Arena.
|
|||
|
|
|||
|
For additional information:
|
|||
|
Complete press release and Developer Information
|
|||
|
Adam J. Richter, adam@yggdrasil.com
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
SPREADING NEWS ABOUT GREAT LISTS OF LINUX FRIENDLY APPLICATIONS
|
|||
|
|
|||
|
Sat, 01 Feb 1997
|
|||
|
From: Gary Swearingen, swear@aa.net
|
|||
|
|
|||
|
I've found a GREAT list of applications compatable with Linux which I
|
|||
|
think should be announced to the wide audience of the gazette.
|
|||
|
|
|||
|
a list of Linux software by Steven K. Baum
|
|||
|
|
|||
|
It's a very comprehensive, alphabetized list of (mostly free)
|
|||
|
software, which is described in a couple paragraphs, mentioning
|
|||
|
weather it is available in binary or source, and a link to where it is
|
|||
|
available. A lot of the entries would be of interest only to someone
|
|||
|
doing scientific programming, but much is of general interest.
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
ANOTHER LINUX GROUP
|
|||
|
|
|||
|
Date: Thu, 23 Jan 1997 21:25:46 -0600 (CST)
|
|||
|
From: Peter Lazecky, peter@linuxware.com
|
|||
|
|
|||
|
Hi, I have been a long time reader of LJ and it has been a great help
|
|||
|
to me, and I am sure that applies to many in the Linux Community! Now,
|
|||
|
my friends on the Net and I have also done something as a contribution
|
|||
|
to Linux which I thought would be interesting to you and helpful to
|
|||
|
your readers. This is to create an On-Line Linux Users Group for
|
|||
|
people interested in learning more about Linux, providing help to
|
|||
|
other Linuxers, and promoting Linux.
|
|||
|
|
|||
|
Peter Lazecky, http://www.linuxware.com/
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
LINUX IN THE NEWS
|
|||
|
|
|||
|
Linux in a Gray Flannel Suit, by Jim Mohr, Byte March 1997. A good
|
|||
|
article -- check it out.
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
SMARTLIST FOR LINUX WOMEN!
|
|||
|
|
|||
|
February 26--A list for women who work and play in Linux is housed at
|
|||
|
niestu.com through SmartList. The list is called linux-women. If you
|
|||
|
need more information send a note to lw-info@niestu.com outlining what
|
|||
|
you have tried so far. Since there does not seem to be much out there
|
|||
|
in the way of women and Linux, it may be fun to check this list out.
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
SOFTWARE ANNOUNCEMENTS
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
DOTFILE GENERATOR 2.0 NOW AVAILABLE
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Wed, 5 Feb 1997
|
|||
|
This note is to announce the public relase of The Dotfile Generator
|
|||
|
version 2.0. Lot's of changes has been made, since last version, which
|
|||
|
was release for more than a year ago.
|
|||
|
|
|||
|
The Dotfile Generator is a tool to help the end user configure basic
|
|||
|
things as well as exotic features of his or hers favorite programs
|
|||
|
without knowing the syntax of the configuration files, or reading
|
|||
|
hundreds of pages in a manual. At the moment, The Dotfile Generator
|
|||
|
knows how to configure Bash, Fvwm1, Fvwm2, Tcsh, Emacs, Elm and Rtin.
|
|||
|
|
|||
|
You can get a FREE copy directly from our ftp-site:
|
|||
|
ftp://ftp.imada.ou.dk/pub/dotfile/dotfile.tar.gz
|
|||
|
ftp://ftp.imada.ou.dk/pub/dotfile/dotfile.tar.Z
|
|||
|
|
|||
|
|
|||
|
For additional information:
|
|||
|
Complete press release
|
|||
|
Jesper Pedersen, blackie@imada.ou.dk
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
LASERJET MANAGER 2.5 ANNOUNCEMENT
|
|||
|
|
|||
|
|
|||
|
|
|||
|
February 26,1997--an upgrade has been announced for LASERJET MANAGER.
|
|||
|
The version is 2.5. The major bonuses of LjetMgr 2.5 are the ability
|
|||
|
to directly modify the screen settings on Hewlett Packard printers,
|
|||
|
and a graphical user interface which is fully localizable and comes
|
|||
|
with documentation and help pages in HTML pages. The program is faster
|
|||
|
and used less resources. A single license of Ljet Mgr costs US-$65 and
|
|||
|
there is a discount for educational institutions and students at 10%.
|
|||
|
This price includes installation support and one year of free
|
|||
|
upgrades. You must have a printer that supports PJL.
|
|||
|
|
|||
|
For additional information:
|
|||
|
Richard Shcwaninger at softWorks, risc@finwds01.tu-graz.ac.at
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
THE BITWIZARD DEVICE DRIVER SERVICE.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
February 26, 1997
|
|||
|
BitWizard is pleased to annouce that it is starting a Linux-device
|
|||
|
driver service. This means that you can concentrate on creating PC
|
|||
|
based systems, and we will make the required device drivers for the
|
|||
|
cards that you select. In general, the driver will be ready within a
|
|||
|
week or two after we get the hardware and the documentation.
|
|||
|
|
|||
|
For additional information:
|
|||
|
Roger Wolff, info@BitWizard.nl, http://www.BitWizard.nl/
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
ANNOUNCEMENT OF THOT STRUCTURED EDITOR
|
|||
|
|
|||
|
|
|||
|
|
|||
|
February 26, 1997
|
|||
|
Announced-- the source code of the Thot structured editor is now
|
|||
|
available by anonymous ftp. Several binaries may also be downloaded
|
|||
|
for various Unix platforms. You can get Thot version 2.0b at the
|
|||
|
following URL:
|
|||
|
|
|||
|
http://opera.inrialpes.fr/thot/
|
|||
|
|
|||
|
Thot Editor is a structured document editor, offering a graphical
|
|||
|
WYSIWYG interface under X-Windows. Thot offers the usual functionality
|
|||
|
of a word processor, but it also processes the document structure. It
|
|||
|
includes a large set of advanced tools, such as a spell checker and an
|
|||
|
index generator, and it allows to export documents to common formats
|
|||
|
like HTML and LaTeX.
|
|||
|
|
|||
|
For additional information: Opera project pages
|
|||
|
http://opera.inrialpes.fr
|
|||
|
Amaya pages http://www.w3.org/pub/WWW/Amaya/
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
ACTIVE TOOLS ANNOUNCES CLUSTOR 1.0
|
|||
|
|
|||
|
|
|||
|
|
|||
|
San Francisco, CA - February 10, 1997 - Active Tools, Inc. announced
|
|||
|
today the release of Clustor 1.0 (TM), a program for managing large
|
|||
|
computational tasks. Clustor greatly simplifies a common
|
|||
|
computationally intensive activity - running the same program code
|
|||
|
numerous times with different inputs. Clustor provides increased
|
|||
|
performance by distributing jobs over a network of computers and
|
|||
|
improved task management through a friendly user interface. Clustor
|
|||
|
provides an intuitive interface for task description and control. It
|
|||
|
supports all phases of running a computationally intensive task on a
|
|||
|
network or computers: task preparation, job generation, and job
|
|||
|
execution. Clustor 1.0 is currently available for computers from major
|
|||
|
workstation suppliers, including SGI Irix, Sun Solaris, DEC OSF, IBM
|
|||
|
AIX, HP HPUX and Intel Linux. Clustor 1.0 can be downloaded from:
|
|||
|
http://www.activetools.com/
|
|||
|
|
|||
|
For additional information: sales@activetools.com
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
LINKSCAN
|
|||
|
|
|||
|
February 26, 1997
|
|||
|
Electronic Software Publishing Corporation (Elsop) today announced
|
|||
|
LinkScan, the first and only commercially available linkchecker that
|
|||
|
operates on UNIX servers. Designed to work on both internet and
|
|||
|
intranet servers, LinkScan can test over 30,000 links per hour because
|
|||
|
it uses multi-threaded simultaneous processing.
|
|||
|
|
|||
|
Elsop's LinkScan reports and SiteMaps may be viewed using any of the
|
|||
|
standard Web browsers such as Netscape Navigator 1.2 and up, and
|
|||
|
Microsoft Internet Explorer on any platform including Windows 3.1,
|
|||
|
Windows 95, Macintosh, and, of course, UNIX. LinkScan can be used by
|
|||
|
virtually anyone because it is designed to run on industry standard
|
|||
|
UNIX, LINUX, and Microsoft Windows NT web servers.
|
|||
|
|
|||
|
Free evaluation copies of LinkScan may be downloaded (less than 80K
|
|||
|
bytes) from the company's website at:
|
|||
|
|
|||
|
http://www.elsop.com/
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
MATHWORKS RELEASE OF MATLAB 5
|
|||
|
|
|||
|
|
|||
|
|
|||
|
January 6 The MathWorks announced the release of MATLAB 5.
|
|||
|
|
|||
|
In addition to the MATLAB 5 release, major new versions of SIMULINK,
|
|||
|
the Signal Processing Toolbox, the Control System Toolbox, and MATLAB
|
|||
|
5 compatible versions of many other products will also be available.
|
|||
|
New features in these products include:
|
|||
|
* new development and programming tools
|
|||
|
* expanded data handling support
|
|||
|
* new algorithms
|
|||
|
* online documentation
|
|||
|
* and visual interfaces
|
|||
|
|
|||
|
that make MATLAB easier to use and learn, and better suited than ever
|
|||
|
for large analyses and application development.
|
|||
|
|
|||
|
For additional information:
|
|||
|
The MathWorks, info@mathworks.com
|
|||
|
http://www.mathworks.com/
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Published in Linux Gazette Issue 15, March 1997
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
[ TABLE OF CONTENTS ] [ FRONT PAGE ] Back Next
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
This page written and maintained by the Editor of Linux Gazette,
|
|||
|
gazette@ssc.com
|
|||
|
Copyright © 1997 Specialized Systems Consultants, Inc.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
"Linux Gazette...making Linux just a little more fun!"
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
THE ANSWER GUY
|
|||
|
|
|||
|
|
|||
|
By James T. Dennis, jimd@starshine.org
|
|||
|
Starshine Technical Services, http://www.starshine.org/
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
CONTENTS:
|
|||
|
* fetchmail and POP3 Correction
|
|||
|
* Automated File Transfer over Firewall
|
|||
|
* chown Question
|
|||
|
* Copy from Xterm to TkDesk
|
|||
|
* File System Debugger
|
|||
|
* IP Fragmentation Attack Description
|
|||
|
* Mail Server Problem
|
|||
|
* Mail and Sendmail
|
|||
|
* Mounted vfat File Systems
|
|||
|
* POP3 E-Mail
|
|||
|
* Pseudo Terminal Device Questions
|
|||
|
* root login Bug in Linux
|
|||
|
* Sendmail-8.8.4 and Linux
|
|||
|
* wu-ftpd Problems
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
FETCHMAIL AND POP3 CORRECTION
|
|||
|
|
|||
|
|
|||
|
|
|||
|
From: Eric S. Raymond, esr@snark.thyrsus.com
|
|||
|
|
|||
|
One of your answers in this month's letters column was slightly in
|
|||
|
error.
|
|||
|
|
|||
|
Fetchmail no longer has the old popclient option to dump retrieved
|
|||
|
mail to a file; I removed it. Fetchmail, unlike its ancestor
|
|||
|
popclient, is designed to be a pure MTA, a pipefitting that connects
|
|||
|
a POP or IMAP server to your normal, SMTP-based incoming-mail path.
|
|||
|
|
|||
|
Fetchmail's "multidrop" mode does what Moe Green wants. It allows
|
|||
|
fetchmail, in effect, to serve as a mail collector for a host or
|
|||
|
subdomain.
|
|||
|
|
|||
|
Fetchmail is available at Sunsite, under the system/mail/pop
|
|||
|
directory. Eric S. Raymond
|
|||
|
|
|||
|
Eric is the author (compiler) of _The_New_Hackers_Dictionary_ a
|
|||
|
maintainer of the Jargon file (on which the NHD is based) and is the
|
|||
|
current maintainer of the termcap file that's used by Linux (and
|
|||
|
probably other Unix' as well). He's also the author of 'fetchmail' --
|
|||
|
Jim
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
AUTOMATED FILE TRANSFER OVER FIREWALL
|
|||
|
|
|||
|
From: Koen Rousseau, koen@kava.be
|
|||
|
|
|||
|
Hi,
|
|||
|
Because of the security risk involved when using rcp, I disabled this
|
|||
|
service on our linux host. But the main advantage of rcp (over the
|
|||
|
more secure ftp) is that you can run it non-interactively (from cron
|
|||
|
for example). Is there a way to "simulate" this functionality with
|
|||
|
ftp?
|
|||
|
|
|||
|
Technically non-anonymous ftp isn't more secure than rcp. The security
|
|||
|
concerns are different. (Unless you're using the "guestgroups" feature
|
|||
|
of wu-ftpd). Under some circumstances it is less so.
|
|||
|
|
|||
|
FTP passes your account password across the untrusted wire in "clear
|
|||
|
text" form. Any sniffer on the same LAN segment can search for the
|
|||
|
distinctive packets that mark a new session and grab the next few
|
|||
|
packets -- which are almost certain to contain the password.
|
|||
|
|
|||
|
rcp doesn't send any sort of password. However the remote host has to
|
|||
|
trust the IP addresses and the information returned by reverse DNS
|
|||
|
lookups -- and possibly the responses of the local identd server. Thus
|
|||
|
it is vulnerable to IP spoofing, and DNS hijaacking attacks.
|
|||
|
|
|||
|
Ultimately any automated file transfer will involve storing a
|
|||
|
password, hash or key on each end of the link or it will involve
|
|||
|
"trusting" some meta information about the connection ( such as the IP
|
|||
|
address or reverse DNS lookups of the incoming connections).
|
|||
|
|
|||
|
If the initiating host is compromised it can always pass bad data to
|
|||
|
the remote host (the target of the file transfers). If the remote host
|
|||
|
(the target) is compromised it's data can be replaced. So we'll limit
|
|||
|
our discussion to how we can trust the wire.
|
|||
|
|
|||
|
I'd suggest that you look at ssh. Written by Tatu Ylongen, in Europe
|
|||
|
(Finland?) this is a secure replacement for rsh. It comes with scp (a
|
|||
|
replacement for rcp).
|
|||
|
|
|||
|
ssh uses public key cryptographic methods for authentication (RSA) and
|
|||
|
to exchange a random session key. This key is then used with a
|
|||
|
symmetrical algorithm (IDEA or your choice among others) for the
|
|||
|
end-to-end encryption through out the session.
|
|||
|
|
|||
|
It is free for non-commercial use. You can grab a copy from
|
|||
|
ftp.cs.hut.fi (if I remember correctly) or via http://www.cs.hut.fi.
|
|||
|
If you are in the U.S. you should obtain a copy of the rsaref library
|
|||
|
from mit.edu (I don't remember the exact hostname there) and compile
|
|||
|
against that (this is to satisfy the patents license from RSA). If you
|
|||
|
need a commercial license for it you should contact Data Fellows --
|
|||
|
look at those web pages for details -- or look at http://www.ssh.com.
|
|||
|
|
|||
|
This combination may seem like overkill -- but it is necessary over
|
|||
|
untrusted wires.
|
|||
|
|
|||
|
It is possible to run rdist (the remote file distribution program)
|
|||
|
over an ssh link. This will further automate the process -- allowing
|
|||
|
you to push and pull files from or to multiple servers, recurse
|
|||
|
through directories, automate the removal of files, and only transfer
|
|||
|
new or changed files. It is significantly more efficient than just rcp
|
|||
|
scripts.
|
|||
|
|
|||
|
There are other methods by which you can automate file transfers
|
|||
|
within your organization. One which may seem downright baroque is to
|
|||
|
use the venerable old UUCP.
|
|||
|
|
|||
|
UUCP can be used over tcp. You create accounts on each host for each
|
|||
|
host (or you can have them share accounts in various combinations --
|
|||
|
as you like). In addition to allowing cron driven and on demand file
|
|||
|
transfers using the 'uucp' command (which uses the UUCP protocols --
|
|||
|
if you catch the distinction) you can also configure specific remote
|
|||
|
scripts and allow remote job execution to specific accounts.
|
|||
|
|
|||
|
UUCP offers a great deal of flexibility in scheduling and job
|
|||
|
prioritization. It is extremely automation friendly and is reasonably
|
|||
|
secure (although the concerns about text passwords over your ethernet
|
|||
|
are still valid).
|
|||
|
|
|||
|
You could also use a modern kermit (ckermit from Columbia University)
|
|||
|
which can open sessions over telnet and perform file tranfers through
|
|||
|
that. kermit comes with a rich scripting language and is almost
|
|||
|
universally support.
|
|||
|
|
|||
|
It is also possible -- if you insist on sticking with ftp as the
|
|||
|
protocol -- to automate ftp. You can use the ncftp "macro" feature by
|
|||
|
putting entries in the .ncftprc file. This allows you to create a
|
|||
|
"startup" macro for each host your list in your rc file. It is
|
|||
|
possible to have multiple "host" entries which actually open
|
|||
|
connections to the same host to do different operations.
|
|||
|
|
|||
|
It is also possible to use 'expect' with your standard ftp client
|
|||
|
shell. Expect is a programming languages built around TCL which is
|
|||
|
specifically focused on automating interactive programs.
|
|||
|
|
|||
|
Obviously these last three options would involve storing the password
|
|||
|
in plain text on the host in the script files. However you can
|
|||
|
initiate the connection from either end and transfer files both ways.
|
|||
|
So it's possible to configure the more secure host to initiate all
|
|||
|
file transfer sessions (the ones involving any password) and it's
|
|||
|
possible to set up a variety of methods for the exposed host to
|
|||
|
request a session. (an attacker might spoof a connection request --
|
|||
|
but the more secure host will only connect to one of it's valid
|
|||
|
clients -- not some arbitrary host.
|
|||
|
|
|||
|
Example 1:
|
|||
|
Internet users can upload a file on our public linux host on the
|
|||
|
Internet. A cron job checks at 10 minute intervals if there are files
|
|||
|
in the incoming files directory (eg /home/ftp/incoming). If there are
|
|||
|
files, they would be automaticaly transfered to another host on our
|
|||
|
secure network (intranet) for further processing. With rcp this would
|
|||
|
be easy, but rcp is not a secure service, so can not be allowed on a
|
|||
|
public Internet host. It's "competitor", ftp, is more secure, but can
|
|||
|
it be done?
|
|||
|
|
|||
|
This is a "pull" operation.
|
|||
|
|
|||
|
In this context ftp, initiated from the exposed host and going to a
|
|||
|
non-anonymous account on your internal host, would be less secure than
|
|||
|
rcp. (presuming that you are preventing address spoofing at your
|
|||
|
exterior routers).
|
|||
|
|
|||
|
I'd use uucp over tcp (or even consider running a null modem if the
|
|||
|
hosts are physically close enough) and initiate session from the
|
|||
|
inside. TCP wrappers can be used to ensure that all requests to this
|
|||
|
protocol come from the appropriate addresses (again, assuming you've
|
|||
|
got your anti-spoofing in place at the routers).
|
|||
|
|
|||
|
TCP wrappers should also be used for your telnet, ftp, and r*
|
|||
|
sessions.
|
|||
|
|
|||
|
The best security would be via rdist over ssh.
|
|||
|
|
|||
|
Example 2:
|
|||
|
We extract data from our database on the intranet, and translate them
|
|||
|
into HTML-pages for publishing on our public WWW host on the
|
|||
|
Internet. Again, we wish to do this automaticaly from cron. Normally,
|
|||
|
one would use rcp, but for security reasons, we won't allow it. Can
|
|||
|
ftp be used here?
|
|||
|
|
|||
|
This would be a "push" operation.
|
|||
|
|
|||
|
Exactly the same methods will work as I've discussed above.
|
|||
|
|
|||
|
-- Jim
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
CHOWN QUESTION
|
|||
|
|
|||
|
|
|||
|
|
|||
|
From: Terry Paton, tpaton@vhf.nano.bc.ca
|
|||
|
|
|||
|
Hi Jim....
|
|||
|
My question concerns the chown command. The problem that I have is as
|
|||
|
follows:
|
|||
|
|
|||
|
In a directory that I have access to I have several files that I own
|
|||
|
and also have group ownership. I want to change the ownership and
|
|||
|
group to something else. I am also webmastr and in the weaver group.
|
|||
|
|
|||
|
example: filename is country.html rw- rw- r tpaton owner tpaton group
|
|||
|
|
|||
|
I want to change to owner webmastr group weaver. The command I used is
|
|||
|
chown webmastr.weaver country.html The response the system gives is
|
|||
|
Operation not permitted.
|
|||
|
|
|||
|
Any ideas how come??
|
|||
|
|
|||
|
Of course. Under Unix there are two approaches to 'chown' --
|
|||
|
"giveaway" and "privileged only." Linux installations almost always
|
|||
|
take the later approach (as do most systems which support quotas).
|
|||
|
|
|||
|
You want the 'chgrp' command.
|
|||
|
|
|||
|
You can use 'chgrp' to give group ownership of files away to any group
|
|||
|
of which you are a member.
|
|||
|
|
|||
|
Another approach is to use the SGID bit on the directory.
|
|||
|
|
|||
|
If you have a directory which you share among several users -- such as
|
|||
|
a staging area for your web server -- you can set that directory to a
|
|||
|
group ownership of a group (such as 'webauth') and use the 'chmod g+s'
|
|||
|
to set the SGID bit. On a directory this has a special meaning.
|
|||
|
|
|||
|
Any directory that is SGID will automatically set the group ownership
|
|||
|
of any files created in that directory to match that of the directory.
|
|||
|
This means that your webauthors can just create or copy files into the
|
|||
|
directory and not worry about using the chgrp (or chown) commands.
|
|||
|
|
|||
|
I suspect that this is what you really wanted. Note: You'll want your
|
|||
|
web authors to adjust their umask to allow g+rw to make the best use
|
|||
|
of these features.
|
|||
|
|
|||
|
Also note: if this doesn't seem to work you might want to check your
|
|||
|
/etc/fstab or the mount options on that filesystem. This behavior can
|
|||
|
be overridden with options to the mount command and may not be
|
|||
|
available on some filesystem types. It is the default on ext2
|
|||
|
filesystems.
|
|||
|
|
|||
|
There is also a special meaning to the "t" (sticky) bit when it is
|
|||
|
applied to directories. Originally (in the era of PDP-7's and PDP-11's
|
|||
|
-- on which Unix was originally written) the sticky bit was a hint to
|
|||
|
the kernel to keep the images of certain executable files cached in
|
|||
|
preference to "non-sticky" files. The sysadmin could then set this bit
|
|||
|
on things like "grep" which were used frequently -- giving the system
|
|||
|
a slight performance boost.
|
|||
|
|
|||
|
Given modern caching techniques, usage patterns, and storage systems
|
|||
|
the "sticky" bit has become useless on files.
|
|||
|
|
|||
|
However, most modern Unix systems still have a use for the 't' bit on
|
|||
|
directories. It modifies the meaning of the "write" bit so that users
|
|||
|
with the write option to a directory can only affect *THEIR OWN*
|
|||
|
files.
|
|||
|
|
|||
|
You should always set the 't' bit on /tmp/ and similar
|
|||
|
(world-writeable) directories.
|
|||
|
|
|||
|
Perhaps, one of these days will find a use for the 't' bit on files
|
|||
|
again. I don't know of a meaning for the SUID bit on directories (but
|
|||
|
there might be one in some forms of Unix -- even Linux). Notice that
|
|||
|
"sticky" is not the same as SUID or SGID. This is a fairly common
|
|||
|
misnomer.
|
|||
|
|
|||
|
-- Jim
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
COPY FROM XTERM TO TKDESK
|
|||
|
|
|||
|
|
|||
|
|
|||
|
From: Steve Varadi, svaradi@sprynet.com
|
|||
|
|
|||
|
I have a question maybe someone know simpler solution for this. I'm
|
|||
|
using TkDesk because very easy to use and most of the keystroke same
|
|||
|
as in Win95. If I want to copy something from xterm to an editble
|
|||
|
file I do following:
|
|||
|
1. Select area in xterm
|
|||
|
2. Open Emacs
|
|||
|
3. Paste recent selection
|
|||
|
4. Save file
|
|||
|
5. Open this file with TkDesk Editor and working with it comfortable
|
|||
|
like in Win95 enviroment.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Is it any simpler procedure to copy something directly from xterm to
|
|||
|
TkDesk Editor???
|
|||
|
|
|||
|
Thanks: Steve
|
|||
|
|
|||
|
The usual way to paste text in X is to use the "middle" mouse button.
|
|||
|
If you're using a two-button mouse you'd want your X server configured
|
|||
|
to "Emulate3Buttons" -- allowing you to "chord" the buttons (press and
|
|||
|
hold the left button then click with the other).
|
|||
|
|
|||
|
I realize that this is different than Windows and Mac -- where you
|
|||
|
expect a menu option to be explicitly available for "Edit, Paste" --
|
|||
|
but this follows the X principle of "providing mechanisms" rather than
|
|||
|
"dictating policy" (requiring that every application have an Edit menu
|
|||
|
with a Paste option would be a policy).
|
|||
|
|
|||
|
Personally I always preferred DESQview and DESQview/X's "Mark and
|
|||
|
Transfer" feature -- which was completely keyboard drive. It let me
|
|||
|
keep my hands on the keyboard and it allowed me to make interesting
|
|||
|
macros to automate the process. It was also nice because the
|
|||
|
application wasn't aware of the process -- if you could see text on
|
|||
|
your screen -- you could mark and transfer it.
|
|||
|
|
|||
|
However this sort of interface doesn't currently exist for Linux or
|
|||
|
XFree86 -- and I'm not enough of a programmer yet to bring it to you.
|
|||
|
So try "chording" directly into the text entry area of your TkDesk
|
|||
|
window after making your text selection. Remember -- you'll probably
|
|||
|
have to press on the left button first and hold it while clicking on
|
|||
|
the other button. If you try that in the other order it probably won't
|
|||
|
work (never does for me).
|
|||
|
|
|||
|
-- Jim
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
FILE SYSTEM DEBUGGER
|
|||
|
|
|||
|
From: Steven Mercurio, stevenm@voicenet.com
|
|||
|
|
|||
|
What I want to do is take apart the CURRENT filing system down to the
|
|||
|
layout of the superblock. On an AIX by IBM machine we used a program
|
|||
|
called FSDB. I just want to try and get my hands on it and the filing
|
|||
|
system layout.
|
|||
|
|
|||
|
FSDB would probably be "filesystem debugger." The closest equivalent
|
|||
|
in Linux would probably be the debugfs command.
|
|||
|
|
|||
|
If you start this with a command like:
|
|||
|
|
|||
|
debugfs /dev/hda1
|
|||
|
|
|||
|
... it will provide you with a shell-like interface (similar to the
|
|||
|
traditional ftp client) which provides you about forty commands for
|
|||
|
viewing and altering links and inodes in your filesystem. You can also
|
|||
|
select the filesytem you wish to use after you've started the program.
|
|||
|
|
|||
|
|
|||
|
From the man page: debugfs was written by Theodore Ts'o,
|
|||
|
tytso@mit.edu.
|
|||
|
|
|||
|
There is another program that might be of interest to you. It's called
|
|||
|
lde (Linux Disk Editor). This provides a nice ncurses (with optional
|
|||
|
color) interface to many of the same operations. You can find
|
|||
|
lde-2.3.tar.gz at any of the Sunsite mirrors.
|
|||
|
|
|||
|
There is yet another editor which is included with some versions of
|
|||
|
Red Hat (and probably other distributions) called ext2ed.
|
|||
|
|
|||
|
There are also FAQ's and HOWTO's on the ext2fs structure and internals
|
|||
|
available.
|
|||
|
|
|||
|
Hope that helps.
|
|||
|
|
|||
|
-- Jim
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
IP FRAGMENTATION ATTACK DESCRIPTION
|
|||
|
|
|||
|
|
|||
|
|
|||
|
From: Fabien Royer, fabien@magpage.com
|
|||
|
|
|||
|
Hi all !
|
|||
|
|
|||
|
|
|||
|
IP fragmentation is an old attack, used to send data to a port
|
|||
|
behind a packet filtering 'firewall'.
|
|||
|
|
|||
|
Now, wouldn't be possible to prevent an attack by packet fragmentation
|
|||
|
by simply adding a second router that would receive and recheck the
|
|||
|
packets reassembled by the first one ?
|
|||
|
|
|||
|
Regards, Fabien.
|
|||
|
|
|||
|
Most routers don't do reassembly and most packet filtering systems
|
|||
|
don't track connections. In these each packet is judged purely on its
|
|||
|
own merits.
|
|||
|
|
|||
|
There is a newer, more advanced class of packet filtering packages
|
|||
|
which do "stateful inspection."
|
|||
|
|
|||
|
These are currently mostly implemented in software on various sorts of
|
|||
|
Unix systems. From what I've heard these are largely experimental at
|
|||
|
this point.
|
|||
|
|
|||
|
For those that are curious there is a team working on a "stateful
|
|||
|
inspection module" for the Linux 2.x kernel. The "IP Masquerading"
|
|||
|
features that are built into this kernel (A.K.A. "Network Address
|
|||
|
Translation" or NAT) provide most of the support that's necessary to
|
|||
|
"stateful inspection."
|
|||
|
|
|||
|
Here's a couple of links (courtesy of the Computer: Security section
|
|||
|
of Yahoo, and Alta-Vista):
|
|||
|
|
|||
|
CYCON Labyrinth Firewall 1.4 Announcement
|
|||
|
http://www.cycon.com/press/announce.html CheckPoint FireWall-1
|
|||
|
Brochure http://www.checkpoint.com/brochure/page6.html Network Address
|
|||
|
Translation http://www.oms.co.za/overview/node2.html Firewall Overview
|
|||
|
http://www.morningstar.com/secure-access/fw101.htm Freestone Firewall
|
|||
|
for Linux http://www.crpht.lu/CNS/html/PubServ/\
|
|||
|
Security/Firewall/FW_Mail/07-16_freestone_SOS
|
|||
|
|
|||
|
(note: that last one is one long line).
|
|||
|
|
|||
|
(There is also a package called the Mazama Packet Filters for
|
|||
|
Unix/Linux -but I didn't see if it supports the "stateful" stuff).
|
|||
|
|
|||
|
I didn't find anything on stateful packet filtering under NT -- but
|
|||
|
Checkpoint's Firewall-1 (listed above) is available for NT -- and
|
|||
|
might support it.
|
|||
|
|
|||
|
-- Jim
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Mail Server Problem
|
|||
|
|
|||
|
From: Panoy Tan
|
|||
|
|
|||
|
Hi,
|
|||
|
First let me say that I enjoy Linux Journal very much and get a lot
|
|||
|
out of every issue, esp. 'Letters to the Editor'. If you have time to
|
|||
|
help me, I will be very glad and here is my trouble : My mail server
|
|||
|
run Linux Red Hat with kernel 2.0 and I use Netscape Mail (POP-user)
|
|||
|
to read my e-mails on the server. POP was designed to support
|
|||
|
"offline" mail processing, not "online" and "disconnected", therefor
|
|||
|
I have problem when I read my e-mails with different computers. That,
|
|||
|
I need, is my mails have to leave on the mail server, but whenever I
|
|||
|
delete one of my mails, which
|
|||
|
|
|||
|
This has become a recurring problem in the years since POP (post
|
|||
|
office protocol) was created.
|
|||
|
|
|||
|
You can configure most POP clients to keep your mail -- but then
|
|||
|
you'll be downloading a new copy of every message to each machine --
|
|||
|
each time you connect.
|
|||
|
|
|||
|
Apparently (searching through Netscape's site) there is a hack to the
|
|||
|
POP3 protocol which would allow some of what you're looking for. This
|
|||
|
appears to be called UIDL: Here's what I read:
|
|||
|
|
|||
|
"The POP3 server does not support UIDL", Issue: 960626-31 Product:
|
|||
|
Navigator, Navigator Gold, Personal Edition, Created: 06/12/96
|
|||
|
|
|||
|
Unfortunately they didn't have any pointers to a POP server with UIDL
|
|||
|
support. A search at Yahoo! sent me straight to Alta Vista -- so a
|
|||
|
number of USENet and mailing list postings that referred to a variety
|
|||
|
of patches. I'll leave that as an exercise to the reader.
|
|||
|
|
|||
|
I have read, it will be delete from the server. I have heard that IMAP
|
|||
|
supports 'online' mail processing and that is reason to my questions
|
|||
|
:
|
|||
|
|
|||
|
I've heard similar rumors. The question I was trying to answer by
|
|||
|
looking at Netscape's site is whether they support the client side of
|
|||
|
IMAP. Here's some more background info:
|
|||
|
|
|||
|
IMAP (Internet Mail Access Protocol) is intended to be a more advanced
|
|||
|
mail service. The proposed standards are covered in RFC1730 through
|
|||
|
RFC1733 (which are conveniently consecutive) and RFC2060. You can
|
|||
|
search for RFC's at the ds.internic.net web site or use ftp.isi.edu.
|
|||
|
|
|||
|
RFC's are the documents which become the standards of the Internet.
|
|||
|
They start as "requests for comments" and are revised and into STD's
|
|||
|
(standards documents) and FYI's ("for your information" documents). In
|
|||
|
the anarchy that is the 'net -- these are the results of the "rough
|
|||
|
consensus and running code" that gets all of our systems chatting with
|
|||
|
one another.
|
|||
|
|
|||
|
I did a quick Yahoo search using the keywords IMAP and Linux and came
|
|||
|
up with the following:
|
|||
|
|
|||
|
whatisIMAP? IMAP stands for Internet Message Access Protocol. It is
|
|||
|
a method of accessing electronic mail or bulletin board messages
|
|||
|
that are kept on a (possibly shared) mail server. In other words, it
|
|||
|
permits a "client" email program to access remote message stores as
|
|||
|
if they were local. For example, email stored on an IMAP server can
|
|||
|
be manipulated from a desktop computer at home, a workstation at the
|
|||
|
office, and a notebook computer while traveling, without the need to
|
|||
|
transfer messages or files back and forth between these computers.
|
|||
|
|
|||
|
IMAP's ability to access messages (both new and saved) from more
|
|||
|
than one computer has become extremely important as reliance on
|
|||
|
electronic messaging and use of multiple computers increase, but
|
|||
|
this functionality cannot be taken for granted: the widely used Post
|
|||
|
Office Protocol (POP) works best when one has only a single
|
|||
|
computer, since it was designed to support "offline" message access,
|
|||
|
wherein messages are downloaded and then deleted from the mail
|
|||
|
server. This mode of access is not compatible with access from
|
|||
|
multiple computers since it tends to sprinkle messages across all of
|
|||
|
the computers used for mail access. Thus, unless all of those
|
|||
|
machines share a common file system, the offline mode of access that
|
|||
|
POP was designed to support
|
|||
|
|
|||
|
|
|||
|
|
|||
|
There is *much* more info at this site -- I only clipped the first two
|
|||
|
paragraphs.
|
|||
|
|
|||
|
Some related work is the ACAP (Application Configuration Access
|
|||
|
Protocol) and the IMSP (Internet Message Support Protocol) which are
|
|||
|
other drafts that are currently on the table at the IETF
|
|||
|
(www.ietf.org).
|
|||
|
|
|||
|
To quote another site that came up in my search:
|
|||
|
|
|||
|
ACAP is a solution for the problem of client mobility on the
|
|||
|
internet. Almost all Internet applications currently store user
|
|||
|
preferences, options, server locations, and other personal data in
|
|||
|
local disk files. These leads to the unpleasant problems of users
|
|||
|
having to recreate configuration set-ups, subscription lists,
|
|||
|
addressbooks, bookmark files, folder storage locations, and so forth
|
|||
|
every time they change physical locations.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
If you're getting confused -- don't worry -- we all are. I've been
|
|||
|
bumping into references to IMAP, and ACAP for a few months now. They
|
|||
|
are pretty new and intended to address issues that only recently grew
|
|||
|
up to be problems for enough people to notice them.
|
|||
|
|
|||
|
The short form is: IMAP is an advanced protocol for accessing
|
|||
|
individual headers and messages from a remote mail box. ACAP (which I
|
|||
|
guess replaces or is built over IMSP) provides access to more advanced
|
|||
|
configuration options to affect how IMAP (and potentially other
|
|||
|
remotely accessed applications) behave for a given account.
|
|||
|
|
|||
|
1) Is there any IMAP to Linux, esp. Red Hat ?
|
|||
|
|
|||
|
There is an IMAP server included with Linux some Linux distributions
|
|||
|
(Red Hat 3.03 or later I suspect). I'm not sure about the feature set
|
|||
|
-- and the man page on my Red Hat 3 system here is pretty sparse.
|
|||
|
|
|||
|
However the server is not the real problem here. What you really need
|
|||
|
is a client program that can talk to your IMAP server.
|
|||
|
|
|||
|
2) Where can I get it ?
|
|||
|
|
|||
|
The CMU (Carnegie-Mellon University) Cyrus IMAP project looks
|
|||
|
promising -- so I downloaded a copy of that as I typed this and looked
|
|||
|
up some of these other references.
|
|||
|
|
|||
|
It's about 400K and can be found somewhere at:
|
|||
|
|
|||
|
ftp://ftp.andrew.cmu.edu/
|
|||
|
|
|||
|
3) What must I be carefully when I install it ?
|
|||
|
|
|||
|
You must have a client that supports the IMAP features that you're
|
|||
|
actually looking for. It's possible to have a client that treats an
|
|||
|
IMAP server just like a POP3 server (fetchmail for example). It may be
|
|||
|
that Netscape's UIDL support is all you need for your purposes.
|
|||
|
|
|||
|
I didn't find any reference to IMAP anywhere on Netscape's site --
|
|||
|
which suggests that they don't offer it yet. I'm blind copying a
|
|||
|
friend of mine that is a programmer for them -- and specifically one
|
|||
|
who worked (works?) on the code for the mail support in the Navigator.
|
|||
|
Maybe he'll tell me something about this (or maybe it's covered by his
|
|||
|
NDA).
|
|||
|
|
|||
|
I also looked at Eudora and Pegasus web pages and found no IMAP
|
|||
|
support for these either. It was a long shot since neither of these
|
|||
|
has a Linux port (so far as I know) -- and I doubt you want to run
|
|||
|
WABI to read all of your mail -- nor even DOSEmu to run the Pegasus
|
|||
|
for DOS.
|
|||
|
|
|||
|
pine seems to support IMAP. XF-Mail (a popular free X mail user agent)
|
|||
|
and Z-Mail (a popular commercial one) also seem to have some support.
|
|||
|
More info on IMAP clients is available at the IMAP Info Center (see
|
|||
|
below).
|
|||
|
|
|||
|
The most informative web sites I visited in my research for this
|
|||
|
question were:
|
|||
|
|
|||
|
Cyrus IMAP Server: Overview and Concepts
|
|||
|
http://andrew2.andrew.cmu.edu/cyrus/cyrus-overview.html The IMAP
|
|||
|
Information Center http://www.imap.org/ Draft IMSP Specification
|
|||
|
http://andrew2.andrew.cmu.edu/cyrus/rfc/imsp.html The ACAP Home Page
|
|||
|
http://andrew2.andrew.cmu.edu/cyrus/acap/ Client-server mail protocols
|
|||
|
FAQ http://www.cis.ohio-state.edu/hypertext/faq/ \
|
|||
|
usenet/mail/mailclient-faq/faq.html
|
|||
|
|
|||
|
The most active discussion about UIDL seems to have been on the
|
|||
|
mh-users mailing list. Archives can be found at:
|
|||
|
http://www.rosat.mpe-garching.mpg.de/mailing-lists/mh-users/
|
|||
|
|
|||
|
Thank you for your time to read my questions and hope to hear you
|
|||
|
soon.
|
|||
|
Regards, Nga
|
|||
|
|
|||
|
It's a hobby. I really only had about 2 hours to spare on this
|
|||
|
research (and I took about three) -- and I don't have an environment
|
|||
|
handy to do any real testing.
|
|||
|
|
|||
|
As I said -- I've been bumping into references about IMAP and ACAP and
|
|||
|
wanted to learn more myself. At the last IETF conference (in San Jose)
|
|||
|
I had lunch with one of the sysadmins at CMU -- who talked a bit about
|
|||
|
it.
|
|||
|
|
|||
|
Sorry this article is so rambling and disorganized. I basically tossed
|
|||
|
it together as I searched. To paraphrase Blaise Pascal:
|
|||
|
|
|||
|
This letter is so long because I lack the time to make it brief.
|
|||
|
|
|||
|
-- Jim
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
MAIL & SENDMAIL
|
|||
|
|
|||
|
|
|||
|
|
|||
|
From: Franaur P. Tan, noy@ayala.com.ph
|
|||
|
|
|||
|
Hi There,
|
|||
|
I just read your article on Linux Gazette, got a lot of good tips on
|
|||
|
securing my Linuz machine, thanks. Like always, I have one bit of
|
|||
|
question I was hoping you could answer, I'd like to send mail from my
|
|||
|
Linux machine w/o installing sendmail, and I need this e-mail to be
|
|||
|
sent by a script initiated by crond.
|
|||
|
|
|||
|
Right now (w/ sendmail installed) I can do it with a "mail -s subject
|
|||
|
noy@ayala.com.ph
|
|||
|
|
|||
|
Which article? I'm trying to submit at least one a month.
|
|||
|
|
|||
|
Well, you can use smail or qmail. These are replacements for
|
|||
|
sendmail.
|
|||
|
|
|||
|
I haven't installed either of these but I've fetched a copy of qmail
|
|||
|
and read a bit of the documentation. I might be implementing a system
|
|||
|
with that pretty soon.
|
|||
|
|
|||
|
However I'm not sure how much you gain this way. It's possible to
|
|||
|
configure 'sendmail' to send only so that it doesn't listen to
|
|||
|
incoming mail at all. This is most easily done by simply changing the
|
|||
|
line in your rc files that invokes sendmail (that would be
|
|||
|
/etc/rc.d/init.d/sendmail.init on a typical Red Hat or Caldera
|
|||
|
system). Just take the "-bd" off of that line like so:
|
|||
|
|
|||
|
/usr/lib/sendmail -bd -q1h
|
|||
|
|
|||
|
|
|||
|
... would become:
|
|||
|
|
|||
|
/usr/lib/sendmail -q1h
|
|||
|
|
|||
|
|
|||
|
... or
|
|||
|
|
|||
|
/usr/lib/sendmail -q15m
|
|||
|
|
|||
|
|
|||
|
(changing the queue processing frequency from every hour to every 15
|
|||
|
minutes).
|
|||
|
|
|||
|
You can also remove sendmail from memory entirely and use a cronjob
|
|||
|
to invoke it like:
|
|||
|
|
|||
|
00,30 * * * * root /usr/lib/sendmail -q
|
|||
|
|
|||
|
|
|||
|
(to process the queue on the hour and at half past every hour).
|
|||
|
|
|||
|
If you concerns are about remote attacks through your smtpd service
|
|||
|
than any of these methods will be sufficient.
|
|||
|
|
|||
|
You should also double check your /etc/inetd.conf for the smtp
|
|||
|
service line. This is normally commented out since most hosts default
|
|||
|
to loading a sendmail daemon. It should stay that way.
|
|||
|
|
|||
|
If you are using fetchmail (and getting your mail via POP or IMAP)
|
|||
|
you either after to load some sort of smtp listener (such as
|
|||
|
sendmail, smail, or qmail) or you have to over-ride fetchmail's
|
|||
|
defaults with some command line options.
|
|||
|
|
|||
|
'fetchmail' defaults to a mode whereby it connects to the remote POP
|
|||
|
or IMAP server, and to the localhost's smtpd and relays the mail from
|
|||
|
one through the other. This allows for any aliases, .forwards, and
|
|||
|
procmail processing to work properly on the local system and it
|
|||
|
allows fetchmail to benefit from sendmail's queue handling (to make
|
|||
|
sure you have sufficient disk space etc).
|
|||
|
|
|||
|
However you can configure sendmail to run out of in inetd.conf with
|
|||
|
TCP Wrappers (the tcpd entry that appears on almost all of the other
|
|||
|
services in that file) and limit the listener to only accept
|
|||
|
connections from the local host.
|
|||
|
|
|||
|
You'd then configure your /etc/hosts.deny file to look something
|
|||
|
like:
|
|||
|
|
|||
|
ALL:ALL
|
|||
|
|
|||
|
|
|||
|
... spr (default to not letting anyone access any local services) --
|
|||
|
and you'd put something like:
|
|||
|
|
|||
|
ALL: localhost
|
|||
|
in.telnetd: LOCAL
|
|||
|
in.ftpd: LOCAL
|
|||
|
|
|||
|
|
|||
|
... etc. in your /etc/hosts.allow
|
|||
|
|
|||
|
Finally you'd add something like:
|
|||
|
|
|||
|
smtp stream tcp nowait root /usr/sbin/tcpd /usr/sbin/sendmail -bs
|
|||
|
|
|||
|
|
|||
|
... to your /etc/inetd.conf.
|
|||
|
|
|||
|
(the -bs switch tells sendmail to "be" an "smtp" handler for one
|
|||
|
transaction. It handles one connection on stdin/stdout and exits).
|
|||
|
|
|||
|
All of this discussion assumes that you want to be able to use local
|
|||
|
mailers (like elm, and mailx) to send your mail and fetchmail to
|
|||
|
fetch it from a POP or IMAP server.
|
|||
|
|
|||
|
If your client is capable of it (like the mail reader in Netscape)
|
|||
|
you could configure it to use a remote smtpd gateway directly (it
|
|||
|
would make the connection to the remote host's smtp port and let it
|
|||
|
relay the mail from there). Then you'd have no sendmail, qmail, or
|
|||
|
smail anywhere on the system.
|
|||
|
|
|||
|
pine might be able to send directly via smtp (it does have an IMAP
|
|||
|
client so this would be a logical complement to that).
|
|||
|
|
|||
|
I hope all of this discussion gives you some ideas. As you can see
|
|||
|
there are lots of options.
|
|||
|
|
|||
|
-- Jim
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
MOUNTED VFAT FILESYSTEMS
|
|||
|
|
|||
|
|
|||
|
|
|||
|
From: Steve Baker, ssbaker@mwr.is
|
|||
|
|
|||
|
I have 2 vfat filesystems mounted. They belong to root; is there any
|
|||
|
way to give normal users read/write access to these filesystems?
|
|||
|
chown has no effect on vfat directories and files.
|
|||
|
|
|||
|
man 8 mount
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
I think this answer was a waste of bandwidth. Perhaps Andries didn't
|
|||
|
know this -- or perhaps he tried and the man page didn't make any
|
|||
|
sense.
|
|||
|
|
|||
|
In either event it doesn't do a thing for any of us (that didn't know
|
|||
|
the answer) and is an obvious and public slap in the face.
|
|||
|
|
|||
|
You could have at least added:
|
|||
|
|
|||
|
'look for gid= and umask= under options'
|
|||
|
|
|||
|
Me, I don't know these well enough so let me switch over to another
|
|||
|
VC, pull up the man page myself, and play with that a bit...
|
|||
|
|
|||
|
mount -t msdos -ogid=10,umask=007 /dev/hda1 /mnt/c
|
|||
|
|
|||
|
This command mounts a file system of type msdos (-t) with options (-o)
|
|||
|
that specify that all files are to be treated as being owned by gid 10
|
|||
|
('wheel' on my system) and that they should be have an effective umask
|
|||
|
of 007 (allowing members of group 'wheel' to read, write and execute
|
|||
|
anywhere on the partition. My C: drive is /dev/hda1 and I usually
|
|||
|
mount it under /mnt/c.
|
|||
|
|
|||
|
I tried specifying the gid by name -- no go. You have to look up the
|
|||
|
numeric in the /etc/group file. I tried different ownership and
|
|||
|
permissions on the underlying directory -- they are ignored.
|
|||
|
|
|||
|
This set of parameters does seem to work with vfat and umsdos
|
|||
|
mountings. Using the msdos or vfat at the time means that chmod and
|
|||
|
chown/chgrp commands dont' work on that fs. Using the -t umsdos allow
|
|||
|
me to change the ownership and permissions -- and the changes seem to
|
|||
|
be effective. However there are some oddities in what happens when you
|
|||
|
umount and remount the drive (the move of the write permission on
|
|||
|
files seems to stick but the ownership changes are lost and the
|
|||
|
owner/group r-x bits seem to "come back."
|
|||
|
|
|||
|
Obviously I haven't done much testing with this sort of thing. I
|
|||
|
usually don't write to my DOS partitions from in Linux. In fact I
|
|||
|
haven't see my DOS hard drive partition on this system in months (ever
|
|||
|
since I started compiling the msdos, vfat, and umsdos filesystems as
|
|||
|
modules -- so I don't automount them).
|
|||
|
|
|||
|
I hope that helps.
|
|||
|
|
|||
|
Personally I wish that the mount command would take some hints from
|
|||
|
the permissions of the directory that I'm mounting onto. I'm copying
|
|||
|
you two on this in the hopes that you'll share your thoughts on this
|
|||
|
idea.
|
|||
|
|
|||
|
What if the default for mount was to set the gid and umask of an
|
|||
|
msdos/vfat directory based on the ownership and permissions of the
|
|||
|
mount point. In other words I set up /mnt/c to look like:
|
|||
|
|
|||
|
drwxrwx--- 2 root wheel 1024 Aug 5 1996 c
|
|||
|
|
|||
|
(which I have) and mount would look up the gid for wheel and use that
|
|||
|
and the umask for the mount options.
|
|||
|
|
|||
|
This strikes me as being a reasonably intuitive behaviour.
|
|||
|
|
|||
|
If it can't be the default how about an option like:
|
|||
|
|
|||
|
-o usemountperms
|
|||
|
|
|||
|
... (that particular example seems a little ugly -- but fairly
|
|||
|
self-explanatory).
|
|||
|
|
|||
|
-- Jim
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
RE: ANSWER GUY - POP3 EMAIL
|
|||
|
|
|||
|
From: Brent Austin, baustin@iamerica.net
|
|||
|
|
|||
|
In reading your answer in LG#14 on "Dealing with e-mail on a pop3
|
|||
|
server", I have almost the same challenge. I have an ISP that is
|
|||
|
providing a 25 user POP3 Virtual Mail Server for 25 users. The
|
|||
|
problem is that each user must connect with the ISP individually and
|
|||
|
then to the mail server. I would like to find some method to allow
|
|||
|
Linux to connect with the Mail Server, individually poll each users
|
|||
|
account, and then transfer it into a POP3 server on the local network
|
|||
|
(possibly on the Linux box itself). Any suggestions??
|
|||
|
|
|||
|
If I understand you correctly you have a LAN at your place with about
|
|||
|
25 users/accounts on it. You're provider has set up 25 separate POP3
|
|||
|
mailboxes.
|
|||
|
|
|||
|
You'd like to set up your Linux (or other Unix) box to fetch the
|
|||
|
contents of all of these accounts (perhaps via a cron job) and to have
|
|||
|
it process your outgoing mail queue.
|
|||
|
|
|||
|
Then your users would fetch their mail from the Linux box (using their
|
|||
|
own Linux user agents or perhaps using Pegasus or Eudora under Windows
|
|||
|
or from Macs.
|
|||
|
|
|||
|
This is relatively straightforward (especially the POP3 part).
|
|||
|
|
|||
|
First get a copy of 'fetchmail' (I'm using 2.5 from
|
|||
|
ftp://sunsite.unc.edu). Build that.
|
|||
|
|
|||
|
Now, for each user, configure fetchmail using a .fetchmailrc file in
|
|||
|
their home directory
|
|||
|
|
|||
|
Each will have a line that looks like:
|
|||
|
|
|||
|
poll $HOST.YOURISP.COM proto pop3 user $HISACCT password $HISPASS
|
|||
|
|
|||
|
The parts of the form $ALLCAPS you replace with the name of the pop
|
|||
|
server, the account holder's name and the account holder's password.
|
|||
|
(I presume that you, as the admin for this Unix box, are already
|
|||
|
entrusted with the passwords for these e-mail accounts -- since the
|
|||
|
admin of any Unix box can read any of the mail flowing through it
|
|||
|
anyway).
|
|||
|
|
|||
|
Now set up a script run as root that does something like:
|
|||
|
|
|||
|
|
|||
|
##! do mail psuedo-code
|
|||
|
pppup (some script that brings up your PPP link)
|
|||
|
for users in $USERLIST do;
|
|||
|
[ -e ~$user/.fetchmailrc] && \
|
|||
|
su -c $user /usr/local/bin/fetchmail
|
|||
|
done;
|
|||
|
/usr/lib/sendmail -q
|
|||
|
pppdown
|
|||
|
|
|||
|
You can add a section of code that graps the list of users from your
|
|||
|
/etc/group file (if you're writing this in perl use the getgrent
|
|||
|
function (to get group entries) or you can use something like:
|
|||
|
|
|||
|
|
|||
|
awk -F":" '/'$GROUPNAME\
|
|||
|
'/ {split($4,users, ",");
|
|||
|
for (a in users) {print users[a]}; exit}' /etc/group
|
|||
|
|
|||
|
To get the list of users in a form suitable for use in your 'for'
|
|||
|
loop.
|
|||
|
|
|||
|
Naturally my psuedo-code is closer to bash' syntax.
|
|||
|
|
|||
|
This script (the psuedo-code one) will just bring the ppplink up, for
|
|||
|
each user in the list (perhaps from a group named "popusers") it will
|
|||
|
check for a .fetchmailrc file in their home directory and run
|
|||
|
fetchmail for those that have one. It will then call sendmail to
|
|||
|
process your outgoing queue and bring the ppplink down.
|
|||
|
|
|||
|
(Note: the su -c ... part of this is not secure and there are probably
|
|||
|
some exploits that could be perpetrated by anyone with write access to
|
|||
|
any of those .fetchmailrc's. However it's probably reasonably robust
|
|||
|
-- and you could set these files to be immutable (chattr +i) and you
|
|||
|
can write a more secure SUID perl script to actually execute
|
|||
|
fetchmail. My scripts, pppup and pppdown are SUID perl scripts.
|
|||
|
|
|||
|
I haven't written this as real code and tested it since I don't have a
|
|||
|
need of it myself. I recommend that disconnected networks avoid using
|
|||
|
POP/SMTP for their mail feed. UUCP has been solving the problems of
|
|||
|
dialup mail delivery for 25 years and doesn't involve some of the
|
|||
|
overhead and kludges necessary to do SMTP for intermittently connected
|
|||
|
systems.
|
|||
|
|
|||
|
I do recommend POP/SMTP within the organization and and it's
|
|||
|
absolutely necessary for the providers.
|
|||
|
|
|||
|
Anyway -- fetchmail will then have put each user's mail into his or
|
|||
|
here local spool file (and processed it through any procmail scripts
|
|||
|
that they might have set up).
|
|||
|
|
|||
|
Now each of your users can use any method they prefer (or that you
|
|||
|
dictate) to access their mail. DOS/Windows and Mac users can use
|
|||
|
Pegasus or Eudora, Linux or other Unix users can use fetchmail (or any
|
|||
|
of several other popclient, getpop, etc, other programs) to get the
|
|||
|
messages delivered to their workstation, or anyone in the organization
|
|||
|
can use telnet into the mailhost and user elm, pine, the old UCB mail,
|
|||
|
the RAND MH system or whatever.
|
|||
|
|
|||
|
All of these clients point their POP and mail clients to your
|
|||
|
mailhost. Your host then acts as their spool. This is likely to result
|
|||
|
in fewer calls to your ISP and more efficient mail handling all
|
|||
|
around.
|
|||
|
|
|||
|
You may want to ask your ISP -- or look around -- for UUCP providers.
|
|||
|
On of the big benefits to this is that you gain complete control of
|
|||
|
mail addressing within your domain. Typical UUCP rates go for about
|
|||
|
$50/mo for a low volume account and about $100/mo for anything over
|
|||
|
100Mb per month. However it's still possible to find bargains.
|
|||
|
|
|||
|
(Another nice thing about UUCP is that you can choose specific sites,
|
|||
|
with which you exchange a lot of mail, and configure your mail to be
|
|||
|
exchanged directly with them -- if they have the technical know-how at
|
|||
|
their end or are willing to let you do it for them. This can be done
|
|||
|
via direct dialup or over TCP connections).
|
|||
|
|
|||
|
uu.net is the Cadillac of UUCP providers (which is a bit pricey for me
|
|||
|
-- I use a small local provider who gives me a suite of UUCP, PPP,
|
|||
|
shell, virtual hosting, virtual ftp, and other services -- and is of
|
|||
|
little interest to you unless you're in the Bay Area).
|
|||
|
|
|||
|
You can also find information on Yahoo! using a search for "uucp
|
|||
|
providers" (duh!). I also seem to recall that win.net used to provide
|
|||
|
reasonable UUCP (and other) services.
|
|||
|
|
|||
|
Hope this helps. If you need more specific help in writing these
|
|||
|
scripts you may want to consider paying a consultant. It should be
|
|||
|
less than three hours work for anyone whose qualified to do it (and
|
|||
|
not including the configuration of all your local clients).
|
|||
|
|
|||
|
-- Jim
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
PSEUDO TERMINAL DEVICE QUESTIONS
|
|||
|
|
|||
|
From: Jeong Sung Won
|
|||
|
|
|||
|
Hello ?
|
|||
|
My name is Jeong Sung Won. May I ask you a question ? I'll make a
|
|||
|
program that uses PSEUDO TERMINAL DEVICE.
|
|||
|
|
|||
|
No need to shout -- I've heard of them. They're commonly called pty's
|
|||
|
-- used by 'telnetd', 'expect', 'typescript', and emacs' 'M-x shell'
|
|||
|
command -- among others.
|
|||
|
|
|||
|
But linux has 8 bit MINOR NUMBER, so that total number of pseudo
|
|||
|
terminal device DOESN'T OVERCOME 256.
|
|||
|
|
|||
|
That does seem to be true -- but it is a rather obscure detail about
|
|||
|
he kernel's internals.
|
|||
|
|
|||
|
Linus' work on the 64-bit Alpha port may change this.
|
|||
|
|
|||
|
Is there any possible way to OVERCOME THIS LIMITS ?
|
|||
|
|
|||
|
Only two that I can think of. Both would involve patching the kernel.
|
|||
|
|
|||
|
You might be able to instantiate multiple major devices -- which
|
|||
|
implement that same semantics as major device number 4 (the current
|
|||
|
driver for the virtual consoles and all of the pty's).
|
|||
|
|
|||
|
I'm frankly not enough of a kernel hacker to tell you how to do this
|
|||
|
or what sorts of problems it would raise.
|
|||
|
|
|||
|
The other would involve a major overhaul of the kernel code and all
|
|||
|
the code that depends on it.
|
|||
|
|
|||
|
For example,on HP9000, minor number is 24 bit, and actually I used
|
|||
|
concurrently 800 pseudo terminal device. And more than 1000 is also
|
|||
|
possible.
|
|||
|
|
|||
|
I wonder what it is on RS/6000, DEC OSF/1, and Sun/Solaris.
|
|||
|
|
|||
|
On Linux, is it impossible to make it, let me know the way I counld
|
|||
|
tell LINUS that upgrade minor number scheme from 8-bit to 16-bit or
|
|||
|
more-bit is needed.
|
|||
|
|
|||
|
Linus Torvald's e-mail address has been included with every copy of
|
|||
|
the sources ever distributed.
|
|||
|
|
|||
|
However it is much better to post a message to the
|
|||
|
comp.os.linux.development.system newsgroup than directly to him (or
|
|||
|
any of other developer).
|
|||
|
|
|||
|
As for "telling LINUS [to] upgrade" -- while it would probably be
|
|||
|
reasonably well recieved as a suggestion -- I'm not sure that
|
|||
|
"telling" him what to do is appropriate.
|
|||
|
|
|||
|
It's easy to forget that Linus has done all of his work on the Linux
|
|||
|
kernel for free. I'm not sure but I imagine that the work he puts in
|
|||
|
just dealing with all the people involved with Linux is more time
|
|||
|
consuming and difficult than the actual coding.
|
|||
|
|
|||
|
As many of the people who are active in the Linux community are aware
|
|||
|
Linus has been very busy recently. He's accepted a position with a
|
|||
|
small startup and will be moving to the San Francisco Bay Area
|
|||
|
(Silicon Valley, actually) -- and he and Tove have just had a baby
|
|||
|
girl.
|
|||
|
|
|||
|
I will personally understand if these events keep him from being as
|
|||
|
active with Linux as he as been for the last few years.
|
|||
|
|
|||
|
-- Jim
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
ROOT LOGIN BUG IN LINUX
|
|||
|
|
|||
|
|
|||
|
|
|||
|
From: Shevek, ma6ybm@bath.ac.uk
|
|||
|
|
|||
|
Has anybody else found a root login bug evident on my system.
|
|||
|
|
|||
|
The root password is an 8 character random series. For going live
|
|||
|
online I updated the root password to a 16 character random series. I
|
|||
|
can log in with the 16 character series, but also using the first
|
|||
|
eight and any random characters after that, or just the first eight.
|
|||
|
This creates an infinite number of root passwords and worries me more
|
|||
|
than a little.
|
|||
|
|
|||
|
About Unix Passwords and Security
|
|||
|
|
|||
|
This is a documented and well known limitation of conventional Unix
|
|||
|
login and authentication.
|
|||
|
|
|||
|
You can overcome this limit if you upgrade to the shadow password
|
|||
|
suite (replace all authenticating programs with the corresponding
|
|||
|
shadow equivalents) and enable the MD5 option (as opposed to the
|
|||
|
traditional DES hash).
|
|||
|
|
|||
|
Note -- there is probably an "infinite" number of valid passwords to
|
|||
|
either of these schemes. The password entry on your system is not
|
|||
|
encrypted. That is a common misconception. What is stored on your
|
|||
|
system is a "hash" (a complex sort of checksum).
|
|||
|
|
|||
|
Specifically the traditional Unix DES hash uses your password as the
|
|||
|
key to encrypt a string of nulls. DES is a one-way algorithm -- so
|
|||
|
there is no known *efficient* way to reclaim the key even if one has
|
|||
|
copies of the plaintext and the ciphertext.
|
|||
|
|
|||
|
'Crack' and it's brethren find passwords by trying dictionaries of
|
|||
|
words and common word variations (reverse, replace certain letters
|
|||
|
with visually similar numerics, various abbreviations,
|
|||
|
prepending/appending one or two digits, etc) -- and using the crypt()
|
|||
|
function (or an equivalent) on a string of nul's to find matches. This
|
|||
|
isn't particularly "efficient" -- but it is several orders of
|
|||
|
magnitude better than an exhaustive brute force attack.
|
|||
|
|
|||
|
The only two defenses against 'Crack' are:
|
|||
|
1. Don't let anyone have copies of the password hashes (which is why
|
|||
|
the shadow suite puts those in a separate file -- that is only
|
|||
|
readable by SUID or SGID programs, and not normal users)
|
|||
|
2. Don't allow users to use words, names, or simple variations of
|
|||
|
words as their passwords. This is don't by installing npasswd or
|
|||
|
passwd+ (replacements for the stock passwd program).
|
|||
|
|
|||
|
Use both of these strategies on all mult-user systems. That way, if
|
|||
|
someone exploits some newly discovered bug to get a copy of the shadow
|
|||
|
file, he is less likely to get any good passwords (since that will
|
|||
|
entail a password that is more clever than your npasswd rules and less
|
|||
|
clever than your attackers custom 'crack' dictionaries).
|
|||
|
|
|||
|
It is possible that two different passwords (keys) will result in the
|
|||
|
same hashed value (I don't know if there are any examples with DES 56
|
|||
|
bit within the domain of all ASCII sequence up to eight characters --
|
|||
|
but it is possible).
|
|||
|
|
|||
|
Using MD5 allows you to have passwords as long as you like. Again --
|
|||
|
it is possible (quite likely, in fact) that a number of different
|
|||
|
inputs will hash to the same value. Probably you would be looking at
|
|||
|
strings of incomprehensible ASCII that were several thousand bytes
|
|||
|
long before you found any collisions.
|
|||
|
|
|||
|
Considering that the best supercomputers and parallel computer
|
|||
|
clusters that are even suspected to exist take days or weeks to
|
|||
|
exhaustively brute force a single DES hash (with a max of only 8
|
|||
|
characters and only a 56-bit key) -- it is unlikely that anyone will
|
|||
|
manage to find one of the "other" valid keys for any well chosen
|
|||
|
password without expending far more energy and computing time than
|
|||
|
most of our systems are worth. (Even in these days of cheap PC's --
|
|||
|
computer time is a commodity with a pricetag).
|
|||
|
|
|||
|
There other ways to get long password support on your system. However
|
|||
|
the only reasonable one is to use the shadow suite compiled with the
|
|||
|
MD5 option. This is the way that FreeBSD (and it's derivatives) are
|
|||
|
installed by default -- so the code and systems have been reasonably
|
|||
|
well tested.
|
|||
|
|
|||
|
In fact -- if security and robustness are more important to you than
|
|||
|
other features you may want to consider FreeBSD or (or NetBSD, or
|
|||
|
OpenBSD) as an alternative. These are freely distributed Unix
|
|||
|
implementations which have been around as long as Linux. Obviously
|
|||
|
they have a much smaller user base. However each has a tightly knit
|
|||
|
group of developers and a devoted following which provides or an
|
|||
|
extremely robust and well-tested system.
|
|||
|
|
|||
|
As much as I like Linux -- I often recommend FreeBSD for dedicated web
|
|||
|
and ftp servers. Linux is better suited to the desktop and to use with
|
|||
|
exotic hardware -- or in situations where the machine needs to
|
|||
|
interact with Netware, NT and other types of systems. [Oh, Oh! Here
|
|||
|
come the fireballs!]
|
|||
|
|
|||
|
FreeBSD has a much more conservative set of features (no gpm support
|
|||
|
for one example -- IP packet filtering is a separate package in
|
|||
|
FreeBSD while it's built into the Linux kernel).
|
|||
|
|
|||
|
Another consideration is the local expertise. Linux and FreeBSD are
|
|||
|
both extremely similar in most respects (as they both are to most
|
|||
|
other Unix implementations). In some ways they are more similar to one
|
|||
|
another than either is to any non-PC Unix. However the little
|
|||
|
administrative difference might very well drive your sysadmin crazy.
|
|||
|
Particularly if he has a bunch of Linux machines and is used to them
|
|||
|
-- and you specify one or two FreeBSD systems for your "DMZ" (Internet
|
|||
|
exposed LAN segment).
|
|||
|
|
|||
|
Back to your original question:
|
|||
|
|
|||
|
You said that you are using a "random" string of characters for your
|
|||
|
password. In terms of cryptography and security you should be quite
|
|||
|
careful of that word: "random"
|
|||
|
|
|||
|
Several cryptographically strong systems have been compromised over
|
|||
|
the years by attacking the randomizer that were used to generate keys.
|
|||
|
A perfect example of this is the hack of SSL by a student in France
|
|||
|
(which was published last spring). He cracked a Netscape challenge and
|
|||
|
got a prize from them for the work (and Netscape implemented a better
|
|||
|
random seed generation algorithm).
|
|||
|
|
|||
|
In the context of creating "strong" passwords (ones that won't be
|
|||
|
tested by the best crack dictionaries out there) you don't need to go
|
|||
|
completely overboard. However -- if a specific attacker knows a little
|
|||
|
bit about how you generate your random keys -- he or she can generate
|
|||
|
a special dictionary tailored for that method.
|
|||
|
|
|||
|
Kernel linux 2.0.20 System P90, 8Mb, IDE, SCSI (not working fully),
|
|||
|
cd, sound, etc. root hda2, about 20 user entries in passwd.
|
|||
|
|
|||
|
Next bug: Two users with consecutive login entries. Both simply
|
|||
|
information logins, never to be logged in to, just for fingering to
|
|||
|
for status information. If you finger the second, OK. But if you
|
|||
|
finger the first, it fingers both. UID numbers 25 and 26. If I
|
|||
|
comment 26, but have a third login on UID 27 then it is OK. I have
|
|||
|
tried unassigning the groups and reassigning them. They both have
|
|||
|
real home directories, shell is dev/null, and are in a group called
|
|||
|
'private' on their own. There are no groups by the same name as the
|
|||
|
login.
|
|||
|
|
|||
|
This sounds very odd. I would want to look at the exact passwd entries
|
|||
|
(less the password hashes) and to know alot about the specific
|
|||
|
implementation of 'finger' that you were using (is it the GNU
|
|||
|
cfingerd?).
|
|||
|
|
|||
|
I would suggest that you look at the GNU cfingerd. I think it's
|
|||
|
possible to configure it to do respond to "virtual" finger requests
|
|||
|
(i.e. you can configure cfingerd to respond to specific finger
|
|||
|
requests by return specific files and program outputs without having
|
|||
|
any such accounts on your system). This is probably safer and easier
|
|||
|
than having a couple of non-user psuedo accounts and using the
|
|||
|
traditional finger daemon. (In additional the older fingerd is
|
|||
|
notoriously insecure and overflows of it was one of the exploits used
|
|||
|
by the "Morris Internet Worm" almost a decade ago).
|
|||
|
|
|||
|
Given the concerns I would seriously consider running a finger daemon
|
|||
|
in a chroot'd jail. Personally I disable this and most other services
|
|||
|
in the /etc/inetd.conf when ever I set up a new system.
|
|||
|
|
|||
|
When I perform RASA (risk assessment and security auditing)
|
|||
|
/etc/inetd.conf is the second file I look at (after looking for a
|
|||
|
/etc/README file -- which no one but me ever keeps; and inspecting the
|
|||
|
/etc/passwd file).
|
|||
|
|
|||
|
-- Jim
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
SENDMAIL-8.8.4 AND LINUX
|
|||
|
|
|||
|
|
|||
|
|
|||
|
From: Brent Austin, baustin@iAmerica.net
|
|||
|
|
|||
|
After setting up fetchmail and the PPP link to my ISP, everything has
|
|||
|
worked perfectly retrieving mail from the POP3 account.
|
|||
|
|
|||
|
Now, I've stumbled on another problem I require some help with.
|
|||
|
Compiling and Installing Sendmail-8.8.4 (or 8.8.5). I downloaded the
|
|||
|
8.8.4 source from sunsite and set it up in the /usr/src directory and
|
|||
|
using the O'Reilly "Sendmail" book as my guide, I modified the
|
|||
|
Makefile.Linux for no DNS support by setting ENVDEF = -DNAMED_BIND=0.
|
|||
|
And removing Berkeley DB support (removing -DNEWDB). After compiling
|
|||
|
and executing ./sendmail -d0.1 -bt
|
|||
|
|
|||
|
Version 8.8.4
|
|||
|
Compiled with: LOG MATCHGECOS MIME7TO8 MIME8TO7 NDBM NETINET NETUNIX
|
|||
|
QUEUE SCANF SMTP XDEBUG
|
|||
|
|
|||
|
|
|||
|
and the program hangs at this point. I am running Linux.2.0.29 on a
|
|||
|
486DX40 with 8 megs. My gcc is version 2.7.0.
|
|||
|
|
|||
|
Any hints you could provide are greatly appreciated!,
|
|||
|
|
|||
|
I fetched a copy of 8.8.5 and used the .../src/makesendmail script --
|
|||
|
and only encountered the problems with NEWDB Removing that seemed to
|
|||
|
work just fine.
|
|||
|
|
|||
|
I noticed you said -- .../src/obj -- did you mean something like:
|
|||
|
.../src/obj/obj.Linux.2.0.27.i386/
|
|||
|
|
|||
|
If you properly used the makesendmail script then the resulting .o and
|
|||
|
binaries should have landed in a directory such as that.
|
|||
|
|
|||
|
Other than that I don't know.
|
|||
|
|
|||
|
I don't disable the DNS stuff -- despite the fact that my sendmail
|
|||
|
almost all done via uucp.
|
|||
|
|
|||
|
As for using this with fetchmail -- I have my sendmail configured in
|
|||
|
/etc/inetd.conf like so:
|
|||
|
|
|||
|
# do not uncomment smtp unless you *really* know what you are doing.
|
|||
|
# smtp is handled by the sendmail daemon now, not smtpd. It does NOT
|
|||
|
# run from here, it is started at boot time from /etc/rc.d/rc#.d.
|
|||
|
## jtd: But I *really do* know what I'm doing.
|
|||
|
## jtd: I want fetchmail to handle mail transparently and I
|
|||
|
## jtd want tcpd to enforce the local only restriction
|
|||
|
smtp stream tcp nowait root /usr/sbin/tcpd /usr/local\
|
|||
|
/sbin/sendmail -bs
|
|||
|
|
|||
|
(note -- the line back is for this mail only -- remove it before
|
|||
|
attempting to use this line. Also note the -bs "be an smtp handler on
|
|||
|
stdin/stdout")
|
|||
|
|
|||
|
This arrangement allows me to fetchmail, lets fetchmail transparently
|
|||
|
talk to sendmail, and keeps the rest of the world from testing their
|
|||
|
latest remote sendmail exploit on me while my ppp link is up (I
|
|||
|
wouldn't recommend this for high volume mail server!).
|
|||
|
|
|||
|
Naturally I also have a cron job like this:
|
|||
|
|
|||
|
## Call sendmail -q every half hour
|
|||
|
00,30 * * * * root /usr/lib/sendmail -q
|
|||
|
|
|||
|
(which processes any mail that elm, pine, mh-e or any other mailers
|
|||
|
have left in the local queue -- awaiting their trip through uucp's
|
|||
|
rmail out to the rest of the world).
|
|||
|
|
|||
|
If you continue to have trouble compiling sendmail then you may want
|
|||
|
to just rely on the RPM updates. Compiling it can be tricky, so I
|
|||
|
avoid doing it unless I see a bugtraq or CERT advisory with the phrase
|
|||
|
"remotely exploitable" in it.
|
|||
|
|
|||
|
Re: O'Reilly's "bat" book. Do you have the 2nd Edition? If not -- get
|
|||
|
it (and ask them about their "upgrade" pricing/discount if that's
|
|||
|
still available)
|
|||
|
|
|||
|
-- Jim
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
WU-FTPD PROBLEMS
|
|||
|
|
|||
|
|
|||
|
|
|||
|
From: Ed Stone, estone@synernet.com
|
|||
|
|
|||
|
On BSDI, I've read ALL of the doc for wu-ftpd, and have ftp logins
|
|||
|
limited to the chroot dir, but still have these problems: 1) I cannot
|
|||
|
force ftp only. The guestgroup "guests" can telnet, and go
|
|||
|
everywhere. I've put /bin/true in /etc/shells; I've edited passwd and
|
|||
|
master.passwd for that; no effect
|
|||
|
|
|||
|
Usually I set their passwd to /bin/false or /usr/bin/passwd. I make
|
|||
|
sure that I use the path filter alias to prevent uploads of .rhosts
|
|||
|
and .forward files into their home directory under the chroot and I
|
|||
|
put entries like:
|
|||
|
|
|||
|
/home/.ftp/./home/fred
|
|||
|
|
|||
|
... for their home directory field in the (true-root)/etc/passwd file.
|
|||
|
|
|||
|
|
|||
|
Also make sure that you have the -a switch on the ftpd (or in.ftpd)
|
|||
|
line in your inetd.conf. The -a tells ftpd to use the /etc/ftpaccess
|
|||
|
file (or /usr/local/etc/ftpaccess -- depending on how you compiled
|
|||
|
it).
|
|||
|
|
|||
|
Personally I also configure each "ftponly" account into the sendmail
|
|||
|
aliases file -- to insure that mail gets properly bounced. I either
|
|||
|
set it to the user's "real" e-mail address (anywhere *off* of that
|
|||
|
machine) or I set it to point at nobody's procmail script (which
|
|||
|
autoresponds to it).
|
|||
|
|
|||
|
2) "guests" ftp to the proper directory, but get no listing. I have
|
|||
|
set up executable of ls in the ftp chroot dir in /bin there; no
|
|||
|
effect.
|
|||
|
|
|||
|
How do you know that they are in the proper directory? What happens if
|
|||
|
you use a chroot (8) command to go to that dir and try it? Is this
|
|||
|
'ls' statically linked? Do you have a /dev/zero set up under your
|
|||
|
(chroot)/?
|
|||
|
|
|||
|
Most common cause of this situation is a incomplete (chroot)
|
|||
|
environment -- usually missing libraries or missing device nodes.
|
|||
|
|
|||
|
-- Jim
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Copyright © 1997, James T. Dennis
|
|||
|
Published in Issue 15 of the Linux Gazette March 1997
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
[ TABLE OF CONTENTS ] [ FRONT PAGE ] Back Next
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
"Linux Gazette...making Linux just a little more fun!"
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
CLUELESS at the Prompt: A Column for New Users
|
|||
|
|
|||
|
By Mike List, troll@net-link.net
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
[IMAGE]
|
|||
|
|
|||
|
Welcome to installment 2 of Clueless at the Prompt: a new column for
|
|||
|
new linux users. On advice from several respondents, I'm going to
|
|||
|
start using a new format for specifying commands:
|
|||
|
|
|||
|
Typing them on a separate line
|
|||
|
separated from the text by a space
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Hopefully, this will minimize any confusion by even the very
|
|||
|
inexperienced user as to what should be typed at the prompt.
|
|||
|
|
|||
|
Last time we explored some of the differences and similarities between
|
|||
|
linux and DOS/Windows, and I'm going to continue this time with some
|
|||
|
stuff you already know, but perhaps aren't fully aware of.
|
|||
|
|
|||
|
One respondent seemed to take exception to my DOS-linux comparison,
|
|||
|
reminding me of the features that make linux and unices(unix like
|
|||
|
systems) more powerful than DOS.
|
|||
|
|
|||
|
Fair enough, this is a new users column and I would like to make sure
|
|||
|
that I'm not assuming that everyone who reads this column can read my
|
|||
|
mind. Besides, if I endure the slings and arrows of outrageous gurus I
|
|||
|
can hopefully expand my knowledge base, which I can then use for
|
|||
|
future columns.
|
|||
|
|
|||
|
Still, the paradigm of SUPERDOS holds some water.It is, after all a
|
|||
|
command line operating system which supports a windowing system, which
|
|||
|
has all the capabilities of MS Windows plus a few features that make
|
|||
|
Windowslook pale.
|
|||
|
|
|||
|
When you installed linux from whatever distribution,most of the
|
|||
|
packages installed came as pre-compiled binaries that were for the
|
|||
|
most part usable as is. However, if you found any applications that
|
|||
|
didn't come with the distribution they'll probably need to be unpacked
|
|||
|
and installed or compiled or both.
|
|||
|
|
|||
|
You could use a utility like installpkg, pkgtool, or dopkg but unless
|
|||
|
the package is from the distribution, the utility will likely install
|
|||
|
it to the / (base ) directory, which is probably less than optimal.
|
|||
|
|
|||
|
Instead, use the midnight commander, which is a Norton Commander
|
|||
|
clone, to view the contents of the package. To do this find the file,(
|
|||
|
I don't have a CD-ROM so I'm not sure of the procedure there )locate
|
|||
|
the file, probably with .tgz or .tar.gz extension, and highlight the
|
|||
|
file, then hit enter. you will see the contents of the archive. Read
|
|||
|
the files called for instance, INSTALL, README, Readme.whatever, or
|
|||
|
any file whose name suggests that it has necessary information, for a
|
|||
|
clue as to where best to unpack it. For instance, X apps probably
|
|||
|
should be unpacked in the /usr/X11R6 directory. To unpack the archive:
|
|||
|
|
|||
|
cd /thechosendirectory
|
|||
|
|
|||
|
|
|||
|
|
|||
|
then:
|
|||
|
|
|||
|
tar -zxvf /wherethearchiveis/file
|
|||
|
|
|||
|
|
|||
|
|
|||
|
you will see a list of files as they unpack. When this process is
|
|||
|
done, you will be returned to your shell prompt. If you get any error
|
|||
|
messages they should be pretty self explanatory, for instance a
|
|||
|
message saying file not found means you didn't name the file correctly
|
|||
|
in the tar command, unexpected EOF means the file was very likely
|
|||
|
corrupted or download was incomplete, try to get the file one more
|
|||
|
time.
|
|||
|
|
|||
|
At your shell prompt type:
|
|||
|
|
|||
|
ls
|
|||
|
|
|||
|
|
|||
|
|
|||
|
to see a list of files and directories that were untarred. then:
|
|||
|
|
|||
|
less /anyfilenamelike INSTALL,README,Readme.*(*= unx, elf, lnx, etc)
|
|||
|
|
|||
|
|
|||
|
|
|||
|
It wouldn't hurt to check any license, or Copying files for info on
|
|||
|
propers to the authors. It also might be a good idea to print out the
|
|||
|
files if they are long or contain a lot of special instructions so you
|
|||
|
can read and reread them to minimize the possibility that you will
|
|||
|
have to recompile or reinstall. If you aren't familiar with linux
|
|||
|
printing you can just:
|
|||
|
|
|||
|
cat /filename>/dev/lp0 (or lp1, or wherever your printer is located)
|
|||
|
|
|||
|
|
|||
|
|
|||
|
If you are in the directory that the file is in, you can skip the
|
|||
|
frontslash on the filename. If the files include a precompiled binary,
|
|||
|
you're done except to install if the documentation suggests a location
|
|||
|
other than where you unpacked and reboot or run ldconfig.
|
|||
|
|
|||
|
If you want to examine the contents of subdirectories of your current
|
|||
|
directory type:
|
|||
|
|
|||
|
cd subdirectory (leave off the / )
|
|||
|
|
|||
|
|
|||
|
|
|||
|
then,
|
|||
|
|
|||
|
ls
|
|||
|
|
|||
|
|
|||
|
|
|||
|
or,
|
|||
|
|
|||
|
ls subdirectory
|
|||
|
|
|||
|
|
|||
|
|
|||
|
If you cd to a subdirectory, you can return to the top level directory
|
|||
|
by typing:
|
|||
|
|
|||
|
cd -
|
|||
|
|
|||
|
|
|||
|
|
|||
|
If you have chosen a source file distribution of the software, then
|
|||
|
you will need to read the file INSTALL very carefully to find what
|
|||
|
needs to be done. Typically you might run
|
|||
|
|
|||
|
./configure
|
|||
|
|
|||
|
|
|||
|
|
|||
|
then edit the Makefile with a text editor as described in the INSTALL
|
|||
|
or README files, then run:
|
|||
|
|
|||
|
make
|
|||
|
|
|||
|
|
|||
|
|
|||
|
sometimes followed by an option like linux, unx, linux-elf as
|
|||
|
instructed in INSTALL.When it is done compiling, the time will vary
|
|||
|
according to the program, type:
|
|||
|
|
|||
|
make install
|
|||
|
|
|||
|
|
|||
|
|
|||
|
sometimes followed by an option as above.
|
|||
|
|
|||
|
The above is only a general guide to steps usually needed to install
|
|||
|
software in linux, more detailed instructions will come with the
|
|||
|
archive. READ THEM CAREFULLY!or print out the files.
|
|||
|
|
|||
|
Back to the DOS-Linux comparisons. In DOS there is a method of
|
|||
|
concatenating several files together under a batch file, which could
|
|||
|
be run to execute a string of commands. Linux also has this capability
|
|||
|
but it is called scripting, basically if you ever used MSEdit to
|
|||
|
create a batch file, you've done it before, except that you must
|
|||
|
change permissions to make it executable. Type:
|
|||
|
|
|||
|
chmod u+x filename
|
|||
|
|
|||
|
|
|||
|
|
|||
|
To make sure you have executable permission,type
|
|||
|
|
|||
|
ls in the directory the file is located, usually ~ , or /home/whoever you
|
|||
|
are
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Look for an asterisk * after the filename which shows that it's an
|
|||
|
executable Then you can run the string of commands by simply typing
|
|||
|
the file name of the script you created.
|
|||
|
|
|||
|
Of course there's a lot more to writing scripts than this, but I'm
|
|||
|
just a GNUbee and some things take a little time. Ihave written a
|
|||
|
couple of very simple scripts to control the dialup to my ISP but they
|
|||
|
are very simple and rely on recursion rather than more correct
|
|||
|
scripting so they must be killed after they have done their jobs. An
|
|||
|
example is "on-n-on", a script I wrote to continue dialing until I can
|
|||
|
beat the busy signal on the remote modem. It is very simply:
|
|||
|
|
|||
|
ppp-on
|
|||
|
sleep 30
|
|||
|
on-n-on
|
|||
|
|
|||
|
|
|||
|
|
|||
|
The script above is called up and dials every 30 seconds until a
|
|||
|
connection is reached, so when 30 seconds goes by without the modem
|
|||
|
dialling you will have a connection and can open a browser or E-mail.
|
|||
|
Before that you must quit by hitting Ctrl+C, however so that the
|
|||
|
script won't continue to use resources to do what it has already
|
|||
|
accomplished.
|
|||
|
|
|||
|
I am accepting suggestions as to how this could be done more
|
|||
|
correctly, but so far it works for me and I have given you an idea how
|
|||
|
simple scripts can be.
|
|||
|
|
|||
|
Thanks for all the input I got from readers and surprisingly from
|
|||
|
other authors, encouragement in the form of suggestions, none of them
|
|||
|
suggested that I go back to m******ft.
|
|||
|
|
|||
|
If I had some ideas about the kind of machines Linux is going on it
|
|||
|
would be helpful. I'm running a relatively old 486/66 with no CD-ROM
|
|||
|
so I installed from floppies, but most of the information here will be
|
|||
|
more about what can be done AFTER installation.
|
|||
|
|
|||
|
There is some discussion from from the Linux Users Support Team with
|
|||
|
regard to the most loved, most misunderstood linux institution,
|
|||
|
man-pages. Many people, myself included feel that they should be a
|
|||
|
little more user friendly, and some have suggested that they be
|
|||
|
replaced witha set of documents similar to howtos> Let me know what
|
|||
|
you think about man pages,how they could be improved, replaced
|
|||
|
supplemented, whatever,and I can have some info next time.
|
|||
|
|
|||
|
BTW, I made at least two errors in my DOS to Linux commands table, not
|
|||
|
very reassuring,but the DOS command for making a directory is:
|
|||
|
|
|||
|
md
|
|||
|
|
|||
|
not
|
|||
|
mkdir
|
|||
|
|
|||
|
|
|||
|
|
|||
|
and file copy should have been:
|
|||
|
|
|||
|
cp /filename /to
|
|||
|
|
|||
|
not
|
|||
|
cp /filename/filename /to
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Next Time- Let me know what you would like to see in here and I'll try to
|
|||
|
oblige just e-mailtroll@net-link.net me and ask, otherwise I'll just write
|
|||
|
about what gave me trouble and how I got past it.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
TTYL, Mike List
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Copyright © 1997, Mike List
|
|||
|
Published in Issue 15 of the Linux Gazette, March 1997
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
[ TABLE OF CONTENTS ] [ FRONT PAGE ] Back Next
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
"Linux Gazette...making Linux just a little more fun!"
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
[IMAGE]
|
|||
|
|
|||
|
BIG BROTHER NETWORK MONITORING SYSTEM
|
|||
|
|
|||
|
A WEB-BASED UNIX NETWORK MONITORING
|
|||
|
AND NOTIFICATION SYSTEM
|
|||
|
|
|||
|
By Paul M. Sittler, p-sittler@tamu.edu
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Big Brother is Watching. . .
|
|||
|
|
|||
|
I wasn't bored: I don't have time to be bored. Texas Agricultural
|
|||
|
Extension Service operates a fairly large enterprise-wide network that
|
|||
|
stretches across hell's half acre, otherwise known as Texas. We have
|
|||
|
around 3,000 users in 249 counties and 12 district offices who expect
|
|||
|
to get their e-mail and files across our Wide Area Network. Some users
|
|||
|
actually expect the network to work most of the time. We use ethernet
|
|||
|
networking with Novell servers at some 35 locations, 15 or so whose
|
|||
|
routers are connected via a mixture of 56Kb circuits, fractional T1,
|
|||
|
Frame-Relay, and radio links. We are not currently using barbed wire
|
|||
|
fences for our network, regardless of what you may have heard. . .
|
|||
|
|
|||
|
I am privileged to be part of the team that set up that network and
|
|||
|
tries to keep it going. We do not live in a perfect network world.
|
|||
|
Things happen. Scarcely a day goes by when we do not have one or more
|
|||
|
WAN link outages, usually of short duration. We sometimes have our
|
|||
|
hands full trying to keep all the pieces connected. Did I mention that
|
|||
|
the users expect the mail and other software to actually work?
|
|||
|
|
|||
|
Cruising the USENET newsgroups, I read a posting about "Big Brother, a
|
|||
|
solution to the problem of Unix Systems Monitoring" written by Sean
|
|||
|
MacGuire of Montreal, Canada. I was intrigued to notice that Big
|
|||
|
Brother was a collection of shell scripts and simple c programs
|
|||
|
designed to monitor a bunch of Unix machines on a network. So what if
|
|||
|
most of our mission critical servers were Novell-based? Who cares if
|
|||
|
some of our web servers run on Macintosh, OS/2, Win'95 or NT? We use
|
|||
|
both Linux and various flavours of Unix in a surprisingly large number
|
|||
|
of places.
|
|||
|
|
|||
|
We had cooked up a number of homemade monitoring systems. Pinging and
|
|||
|
tracerouting to all the servers can be very informative. We looked at
|
|||
|
a bunch of proprietary (and expensive) network monitoring systems. It
|
|||
|
is amazing how much money these things can cost. System adminstrators
|
|||
|
often reported difficult installations and software incompatibilities
|
|||
|
with the monitoring software. Thus, frustrated users often gave us our
|
|||
|
first hint that all was not well.
|
|||
|
|
|||
|
According to the blurb on Big Brother:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
"Big Brother is a loosely-coupled distributed set of tools for
|
|||
|
monitoring and displaying the current status of an entire Unix
|
|||
|
network and notifying the admin should need be. It came about as the
|
|||
|
result of automating the day to day tasks encountered while actively
|
|||
|
administering Unix systems."
|
|||
|
|
|||
|
|
|||
|
|
|||
|
The USENET news article provided a URL
|
|||
|
("http://www.iti.qc.ca/iti/users/sean/bb-dnld/") to the home site of
|
|||
|
Big Brother. I pointed my browser to it and was rewarded with a
|
|||
|
purple-sided screen background and a blue image of a sinister face
|
|||
|
peering out under the caption "big brother is watching." After my
|
|||
|
initial shock, I learned that Big Brother featured:
|
|||
|
|
|||
|
f e a t u r e s
|
|||
|
|
|||
|
* Web-based status display
|
|||
|
* Configurable warning and panic levels
|
|||
|
* Notification via Pager or email
|
|||
|
* Free and includes Source Code
|
|||
|
|
|||
|
|
|||
|
|
|||
|
I was fascinated. Especially by the last item, that said it was free
|
|||
|
with source code. (I often tell people that Linux isn't free, but
|
|||
|
priceless. . .) So what could a priceless package do for me? What on
|
|||
|
earth did Big Brother check?
|
|||
|
|
|||
|
m o n i t o r s
|
|||
|
|
|||
|
* connectivity via ping
|
|||
|
* http servers up and running
|
|||
|
* disk space usage
|
|||
|
* uptime and cpu usage
|
|||
|
* essential processes are still running
|
|||
|
* system-generated messages and warnings
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Overall, very sensible. Looking for some "gotchas," I found that I
|
|||
|
would need a Unix-based machine, and:
|
|||
|
|
|||
|
y o u ' l l
|
|||
|
n e e d
|
|||
|
|
|||
|
* A Functioning Web server & Browser - for the display
|
|||
|
* C compiler
|
|||
|
* Kermit and a modem line - for the pager
|
|||
|
|
|||
|
|
|||
|
|
|||
|
A web server was no problem, as we run many. A c compiler came with
|
|||
|
Linux, and we use kermit on many machines with modems. So far, so
|
|||
|
good.
|
|||
|
|
|||
|
The web site provided links to a few demonstration sites, and a link
|
|||
|
to download it as well. I connected to a demonstration site and was
|
|||
|
greeted with an amazing display:
|
|||
|
|
|||
|
LEGEND
|
|||
|
|
|||
|
|
|||
|
|
|||
|
green System OK
|
|||
|
yellow Attention
|
|||
|
red Trouble
|
|||
|
blue No report
|
|||
|
|
|||
|
UPDATED
|
|||
|
@ 22:52
|
|||
|
|
|||
|
BIG BROTHER
|
|||
|
|
|||
|
help
|
|||
|
info
|
|||
|
page
|
|||
|
view
|
|||
|
|
|||
|
conn
|
|||
|
|
|||
|
cpu
|
|||
|
|
|||
|
disk
|
|||
|
|
|||
|
http
|
|||
|
|
|||
|
msgs
|
|||
|
|
|||
|
procs
|
|||
|
|
|||
|
iti-s01 green green green green yellow green router-000 green - - - -
|
|||
|
- inet-gw-0 green - - - - -
|
|||
|
|
|||
|
Big Brother is watching! As I endured the scrutiny of the Orwellian
|
|||
|
face peering out at me, I examined the rest of the display. The
|
|||
|
display was coded like a traffic signal (green/yellow/red), and the
|
|||
|
update time was clearly displayed beneath it. To the right of "Big
|
|||
|
Brother" were four buttons, marked clearly "Help," "Info," "Page" and
|
|||
|
"View." Beneath the header area was a table with six column headings
|
|||
|
and three rows, each neatly labelled with a computer hostname. The
|
|||
|
boxes formed by the intersection of the rows and columns contained
|
|||
|
attractive green and yellow balls. The overall effect was like a
|
|||
|
decorated tree. The left side of the screen had a yellow tint,
|
|||
|
gradually becoming black at the center.
|
|||
|
|
|||
|
I selected the "Help" button and was rewarded with a brief explanation
|
|||
|
of what Big Brother was all about. Choosing the "Info" Button provided
|
|||
|
a much longer and more detailed explanation of the system, including a
|
|||
|
graphic that really was worth a thousand words. I tried the "Page"
|
|||
|
button to discover that this was a way to send a signal to a
|
|||
|
radio-linked pager. Not at all what I had expected! Finally, the
|
|||
|
"View" selection provided a briefer but perhaps more useful view of
|
|||
|
the information, isolating only the systems with problems.
|
|||
|
|
|||
|
In this case, only the "iti-s01" system was displayed. My browser
|
|||
|
cursor indicated a link as it passed over each colored dot, so I
|
|||
|
clicked on the blinking yellow dot and received a message that read:
|
|||
|
|
|||
|
"yellow Tue Feb 18 22:50:53 EST 1997 Feb 16 12:22:33 iti-s01 kernel:
|
|||
|
WARNING: / was not properly dismounted"
|
|||
|
|
|||
|
|
|||
|
|
|||
|
This puzzled me at first. How on earth could it know that? It seems
|
|||
|
that BB (Big Brother) checks the system /var/log/messages file
|
|||
|
periodically and alerts on any line that says either "WARNING" or
|
|||
|
"NOTICE." As I am certain that Sean MacGuire is very conscientious, I
|
|||
|
suspect that he adds that line to his message file so that something
|
|||
|
will appear to be wrong.
|
|||
|
|
|||
|
Suddenly, my screen spontaneously updated! The update time had changed
|
|||
|
by five minutes, and a blinking yellow dot appeared under the column
|
|||
|
labelled "procs." I clicked on the blinking yellow dot and was
|
|||
|
informed that the sendmail process was not running. This got me really
|
|||
|
interested! Apparently, Big Brother could monitor whether selected
|
|||
|
processes were running!
|
|||
|
|
|||
|
I was also a little puzzled about the screen being updated on its own.
|
|||
|
I used my browser to view the document source and discovered some html
|
|||
|
commands that were new to me:
|
|||
|
|
|||
|
<META HTTP-EQUIV="REFRESH" CONTENT="120">
|
|||
|
<META HTTP-EQUIV="EXPIRES" CONTENT="Tue Feb 18 23:22:07 CST 1997">
|
|||
|
|
|||
|
|
|||
|
|
|||
|
The first line instructs browsers to get an update every 120 seconds.
|
|||
|
The second line tells the browser that it should get a new copy after
|
|||
|
the expiration time and date. Very clever!
|
|||
|
|
|||
|
I returned to the graphics window and discovered that the yellow area
|
|||
|
on the left had changed to red! A new hostname row appeared with a
|
|||
|
blinking red dot under the column labelled "conn." I clicked on the
|
|||
|
blinking red dot and read a message that said:
|
|||
|
|
|||
|
"red Tue Feb 18 22:59:11 CST 1997 bb-network.sh: Can't connect to
|
|||
|
router-000... (paging)"
|
|||
|
|
|||
|
|
|||
|
|
|||
|
The connection to the machine called router-000 had been interrupted
|
|||
|
and the administrator had been paged. Amazingly, while in Texas, I had
|
|||
|
become aware of a network outage in Montreal, Canada. This really had
|
|||
|
possibilities. Perhaps I might someday be able to take a vacation!
|
|||
|
|
|||
|
Big Brother Installation
|
|||
|
|
|||
|
|
|||
|
|
|||
|
I was so impressed with Big Brother that I decided to try to use it.
|
|||
|
Sean has thoughtfully made its acquisition easy, but requests that you
|
|||
|
fill out an on-line registration form with your name and e-mail
|
|||
|
address. He would also like to know where you heard about Big Brother.
|
|||
|
I filled these out in early November 1996, and received an e-mail
|
|||
|
survey form in late December.
|
|||
|
|
|||
|
d o w n l o a d
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Click the link at left to download Big Brother and to get technical
|
|||
|
information about how the system works, and how to install and configure
|
|||
|
the package.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
When I clicked on the link to download Big Brother, I ended up with a
|
|||
|
file called "bb-src.tgz." I impetuously gunzipped this to get
|
|||
|
"bb-src.tar." I then thought better of the impending error of my ways
|
|||
|
and decided to download and print the installation instructions.
|
|||
|
|
|||
|
i n s t a l l
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Click the link at left to look at the install procedure for Big Brother.
|
|||
|
More information about how to set the system up lives here.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Just in case, I also grabbed and printed the debugging information so
|
|||
|
thoughtfully provided (as it turned out, I did not need it):
|
|||
|
|
|||
|
d e b u g
|
|||
|
|
|||
|
|
|||
|
|
|||
|
The link at left provides debugging information for different problems that
|
|||
|
may be experienced during the Big Brother installation process.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
I had no real problems following the installation instructions. I
|
|||
|
decided to make the $BBHOME directory "/usr/src/bb"; use whatever
|
|||
|
makes sense to you. The automatic configuration routines are said to
|
|||
|
work for AIX, FreeBSD, HPUX 10, Irix, Linux, NetBSD, OSF, RedHat
|
|||
|
Linux, SCO, SCO 3/5, Solaris, SunOS4.1, and UnixWare. I can vouch for
|
|||
|
Linux, RedHat Linux, Solaris, and SunOS 4.1.
|
|||
|
|
|||
|
The c programs compiled without incident, and the installation went
|
|||
|
smoothly. As always, your mileage may vary. In less than an hour, I
|
|||
|
was looking at Big Brother's display of coloured lights!
|
|||
|
|
|||
|
At this point, you may wish to re-examine the documentation and
|
|||
|
information files. Personalize your installation as desired. Above
|
|||
|
all, have fun!
|
|||
|
|
|||
|
Hacking
|
|||
|
|
|||
|
|
|||
|
|
|||
|
I admit it. I am a closet hacker. I saw many things about the stock BB
|
|||
|
distribution that I wanted to improve. Big Brother's modular and
|
|||
|
elegantly simple construction makes it a joy to modify as desired. The
|
|||
|
shell scripts are portable, simple, well documented, and easy to
|
|||
|
understand. The use of the modified hosts file to determine which
|
|||
|
hosts to monitor was gratifyingly familiar. The "bbclient" script made
|
|||
|
it extremely easy to move the required components to another similar
|
|||
|
Unix host. Sean has done a remarkable job in making this package easy
|
|||
|
to install!
|
|||
|
|
|||
|
I got obsessive-compulsive about hacking BB and modified it slightly,
|
|||
|
working from Sean MacGuire's v1.03 distribution as a base. I forwarded
|
|||
|
my changes to him for possible inclusion in a later distribution.
|
|||
|
|
|||
|
Features that I added to BB proper include (code added is bold):
|
|||
|
* Links to the info files in the brief view (bb2.html). That's when
|
|||
|
I need them the most.
|
|||
|
|
|||
|
* Links to html info files for each column heading and the column
|
|||
|
info files themselves. These are placed in the html directory
|
|||
|
along with bb.html and bb2.html and have boring names like
|
|||
|
conn.html, cpu.html, . . . smtp.html.
|
|||
|
|
|||
|
* Checks to see if ftp servers, pop3 post offices, and SMTP Mail
|
|||
|
Transfer Agents (MTA's) are accessible
|
|||
|
($BBHOME/bin/bb-network.sh). These all simply use bbnet to telnet
|
|||
|
to the respective ports. This followed Sean's style of adding
|
|||
|
comments to the bb-hosts file as follows:
|
|||
|
|
|||
|
128.194.44.99 behemoth.tamu.edu # BBPAGER smtp ftp pop3
|
|||
|
165.91.132.4 bryan-ctr.tamu.edu # pop3 smtp
|
|||
|
128.194.147.128 csdl.tamu.edu # http://csdl.tamu.edu/ ftp smtp
|
|||
|
|
|||
|
|
|||
|
* I added some environment variables to $BBHOME/etc/bbdef.sh for the
|
|||
|
added monitoring as follows:
|
|||
|
|
|||
|
#
|
|||
|
# WARNING AND PANIC LEVELS FOR DIFFERENT THINGS
|
|||
|
# SEASON TO TASTE
|
|||
|
#
|
|||
|
DFPAGE=Y # PAGE ON DISK FULL (Y/N)
|
|||
|
CPUPAGE=Y # PAGE FOR CPU Y/N
|
|||
|
TELNETPAGE=Y # PAGE ON TELNET FAILURE?
|
|||
|
HTTPPAGE=Y # PAGE ON HTTP FAILURE?
|
|||
|
FTPPAGE=Y # PAGE ON FTPD FAILURE?
|
|||
|
POP3PAGE=Y # PAGE ON POP3 PO FAILURE?
|
|||
|
SMTPPAGE=Y # PAGE ON SMTP MTA FAILURE?
|
|||
|
export DFPAGE CPUPAGE TELNETPAGE HTTPPAGE FTPPAGE POP3PAGE SMTPPAGE
|
|||
|
|
|||
|
|
|||
|
* I updated the bb-info.html and bb-help.html pages to reflect a
|
|||
|
version of 1.03a and a date of 10 February 1997. I also modified
|
|||
|
them to add brief mention of the new ftp, pop3, and smtp
|
|||
|
monitoring things. Specifically, I changed the bb-help.html file
|
|||
|
to add new pager codes for them as follows:
|
|||
|
|
|||
|
100 - Disk Error. Disk is over 95% full...
|
|||
|
200 - CPU Error. CPU load average is unacceptably high.
|
|||
|
300 - Process Error. An important process has died.
|
|||
|
400 - Message file contains a serious error.
|
|||
|
500 - Network error, can't connect to that IP address.
|
|||
|
600 - Web server HTTP error - server is down.
|
|||
|
610 - Ftp server error - server is down.
|
|||
|
620 - POP3 server error - PopMail Post Office is down.
|
|||
|
630 - SMTP MTA error - SMTP Mail Host is down.
|
|||
|
911 - User Page. Message is phone number to call back.
|
|||
|
|
|||
|
|
|||
|
* I added sections to the bb-info.html file to explain the added
|
|||
|
ftp, pop3, and smtp monitoring.
|
|||
|
|
|||
|
* I use a standard tagline file on each html page that identifies
|
|||
|
the author and location of the page. Thus, mkbb.sh and mkbb2.sh
|
|||
|
now look for an optional tagline file to incorporate into the html
|
|||
|
documents that they generate. The optional files are named
|
|||
|
mkbb.tag (for mkbb.sh) and mkbb2.tag (for mkbb2.sh). The shell
|
|||
|
scripts look for the optional tagline files in the $BBHOME/web
|
|||
|
directory (which is where the mkbb.sh and mkbb2.sh files reside).
|
|||
|
|
|||
|
* I went through ALL of the html-generating scripts and html files
|
|||
|
to ensure that they actually had <HEAD> sections and properly
|
|||
|
placed double quotes around the various arguments.
|
|||
|
|
|||
|
* For the most part, I edited the files so that everything would fit
|
|||
|
on an 80-column screen.
|
|||
|
|
|||
|
* I modified $BBHOME/etc/bbsys.sh to make it easier to ignore
|
|||
|
certain disk volumes as follows:
|
|||
|
|
|||
|
#
|
|||
|
# DISK INFORMATION
|
|||
|
#
|
|||
|
DFSORT="4" # % COLUMN - 1
|
|||
|
DFUSE="^/dev" # PATTERN FOR LINES TO INCLUDE
|
|||
|
DFEXCLUDE="-E dos|cdrom" # PATTERN FOR LINES TO EXCLUDE
|
|||
|
|
|||
|
|
|||
|
* I modified $BBHOME/etc/bbsys.linux so that the ping program is
|
|||
|
properly found as follows:
|
|||
|
|
|||
|
#
|
|||
|
# bbsys.linux
|
|||
|
#
|
|||
|
# BIG BROTHER
|
|||
|
# OPERATING SYSTEM DEPENDENT THINGS THAT ARE NEEDED
|
|||
|
#
|
|||
|
PING="/bin/ping" # LINUX CONNECTIVITY TEST
|
|||
|
PS="/bin/ps -ax" # LINUX
|
|||
|
DF="/bin/df -k"
|
|||
|
MSGFILE="/var/adm/messages"
|
|||
|
TOUCH="/bin/touch" # SPECIAL TO LINUX
|
|||
|
|
|||
|
|
|||
|
* I added the ability to dynamically traceroute and ping each system
|
|||
|
being monitored. I spoke with Sean about it, and, in keeping with
|
|||
|
the KISS (Keep It Simple, Stupid) principle, we thought these
|
|||
|
features were best added in the info files. The user portion is
|
|||
|
pretty obvious in the source to the info file. The cgi scripts are
|
|||
|
very simple shell scripts included below:
|
|||
|
|
|||
|
# traceroute.cgi ===========================================
|
|||
|
#!/bin/sh
|
|||
|
|
|||
|
TRACEROUTE=/usr/bin/traceroute
|
|||
|
|
|||
|
echo Content-type: text/html
|
|||
|
echo
|
|||
|
|
|||
|
if [ -x $TRACEROUTE ]; then
|
|||
|
if [ $# = 0 ]; then
|
|||
|
cat << EOM
|
|||
|
<TITLE>TraceRoute Gateway</TITLE>
|
|||
|
<H1>TraceRoute Gateway</H1>
|
|||
|
|
|||
|
<ISINDEX>
|
|||
|
|
|||
|
This is a gateway to "traceroute." Type the desired hostname
|
|||
|
(like hostname.domain.name, eg. net.tamu.edu) in your
|
|||
|
browser's search dialog, and enter a return.<P>
|
|||
|
|
|||
|
EOM
|
|||
|
else
|
|||
|
echo \<PRE\>
|
|||
|
$TRACEROUTE $*
|
|||
|
fi
|
|||
|
else
|
|||
|
echo Cannot find traceroute on this system.
|
|||
|
fi
|
|||
|
# traceroute.cgi ===========================================
|
|||
|
|
|||
|
|
|||
|
# ping.cgi ===========================================
|
|||
|
#!/bin/sh
|
|||
|
|
|||
|
PING=/bin/ping
|
|||
|
|
|||
|
echo Content-type: text/html
|
|||
|
echo
|
|||
|
|
|||
|
if [ -x $PING ]; then
|
|||
|
if [ $# = 0 ]; then
|
|||
|
cat << EOM
|
|||
|
<TITLE>TraceRoute Gateway</TITLE>
|
|||
|
<H1>TraceRoute Gateway</H1>
|
|||
|
|
|||
|
<ISINDEX>
|
|||
|
|
|||
|
This is a gateway to "ping." Type the desired hostname
|
|||
|
(like hostname.domain.name, eg. "net.tamu.edu") in your
|
|||
|
browser's search dialog, and enter a return.<P>
|
|||
|
|
|||
|
EOM
|
|||
|
else
|
|||
|
echo \<PRE\>
|
|||
|
$PING -c5 $*
|
|||
|
fi
|
|||
|
else
|
|||
|
echo Cannot find ping on this system.
|
|||
|
fi
|
|||
|
|
|||
|
# ping.cgi ===========================================
|
|||
|
|
|||
|
Future Enhancements of Big Brother
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Sean MacGuire is the primary author of Big Brother. In the finest
|
|||
|
InterNet tradition of decentralized shared software development, Sean
|
|||
|
solicits improvements, suggestions, and enhancements from all. He then
|
|||
|
skillfully incorporates them as appropriate into the Big Brother
|
|||
|
distribution. Thus, like Linux, Big Brother is in a dynamic state of
|
|||
|
positive evolution with contributions from a cast of thousands (at
|
|||
|
least dozens). This constrained anarchy can produce interesting
|
|||
|
results with an international flavour.
|
|||
|
|
|||
|
Jacob Lundqvist of Sweden is actively improving the paging interface.
|
|||
|
He has done a superb job of enhancing the paging portion, adding
|
|||
|
support for alphanumeric and SMS pagers. Darren Henderson (Maine, US)
|
|||
|
added AIX support. David Brandon (Texas, US) added proper IRIX
|
|||
|
support, and Jeff Matson (Minnesota, US) made some IRIX fixes. Richard
|
|||
|
Dansereau (Canada) ported Big Brother to SCO3 and provided support for
|
|||
|
other df's. Doug White (Oregon, US) made some paging script bug fixes.
|
|||
|
Ron Nelson (Minnesota, US) adapted BB to RedHat Linux. Jac Kersing
|
|||
|
(Netherlands) made some security enhancements to bbd.c. Alan Cox
|
|||
|
(Wales) suggested some shell script security modifications. Douwe
|
|||
|
Dijkstra (Netherlands) provided SCO 5 support. Erik Johannessen
|
|||
|
(Minnesota, US) survived SunOS 4.1.4 installation. Curtis Olson
|
|||
|
(Minnesota, US) survived IRIX, Linux, and SunOS installations. Gunnar
|
|||
|
Helliesen (Norway) ported Big Brother to Ultrix, OSF, and NetBSD. Josh
|
|||
|
Wilmes (Missouri, US) added Solaris changes for new ping stuff.
|
|||
|
|
|||
|
Many other unsung heros around the world are undoubtedly working to
|
|||
|
enhance BB at this very moment.
|
|||
|
|
|||
|
I am (ab)using Big Brother in ways not originally envisioned by its
|
|||
|
creator, Sean MacGuire. Texas Agricultural Extension's networks are
|
|||
|
wildly heterogeneous mixtures of different operating systems and
|
|||
|
protocols, rather than a homogeneous Unix-based network. I would like
|
|||
|
to see Big Brother learn about IPX/SPX protocols for Novell
|
|||
|
connectivity monitoring. I would also like to see Big Brother data
|
|||
|
collection modules for Macintosh, Novell, OS/2, Windows 3.1x,
|
|||
|
Windows'95, and Windows NT. Rewriting Big Brother into perl might
|
|||
|
better serve these disparate platforms. If I could only find the time!
|
|||
|
|
|||
|
Big Brother's Impact at Texas Agricultural Extension Service
|
|||
|
|
|||
|
|
|||
|
|
|||
|
We are now monitoring around 122 hosts. Only 20 are actually
|
|||
|
Unix-based hosts that run Big Brother's bb program internally. Some 28
|
|||
|
are Novell servers, 39 are routers, and the rest are a mixture of
|
|||
|
Macintosh, OS/2, Windows 3.1x, Windows'95, and Windows NT machines
|
|||
|
running one or more types of servers (34 ftp or 26 http). We also find
|
|||
|
it useful to monitor our 31 popmail post offices and 43 mail hosts and
|
|||
|
gateways. We are checking connectivity on three DNS servers as well,
|
|||
|
as they are mission critical.
|
|||
|
|
|||
|
Big Brother (or, as I now affectionately refer to it, "Big Bother") is
|
|||
|
now alerting us to outages five or more times daily. Typically, the
|
|||
|
system administrator receives a page. BB's display is checked and the
|
|||
|
info file is used to traceroute and ping the offending machine to
|
|||
|
validate the outage. Many connection outages involve routers, DSU/CSUs
|
|||
|
and multiplexors as well as the actual host. BB's display allows us to
|
|||
|
quickly see a pattern that aids in diagnosis. The ability to
|
|||
|
dynamically traceroute and ping the host from the html info page also
|
|||
|
helps to rapidly determine the actual point of failure. If the
|
|||
|
administrator paged cannot correct the problem, he relays it to the
|
|||
|
responsible person or agency.
|
|||
|
|
|||
|
Before we installed Big Brother, we were frequently notified of these
|
|||
|
failures by frustrated users telephoning us. Now, we are often aware
|
|||
|
of what has failed before they call us. The users are also becoming
|
|||
|
aware that they may monitor the network through the WWW interface. In
|
|||
|
many instances, we are able to actually correct the problem before it
|
|||
|
perturbs our users. It is difficult to accurately measure the time
|
|||
|
saved, but we estimate that Big Brother has had a net positive effect.
|
|||
|
|
|||
|
|
|||
|
We have a machine in a publicly visible area displaying the brief view
|
|||
|
of Big Brother. The green, yellow, red and blue screen splashes are
|
|||
|
clearly visible far down the hall. This helps our network team to be
|
|||
|
more aware of problems as they occur. The accessibility of the WWW
|
|||
|
page has made Big Brother useful even to people at the far ends of our
|
|||
|
network. So far, we are not inclined to shut Big Brother down. It has
|
|||
|
become a helpful member of our network team.
|
|||
|
|
|||
|
Maybe now I'll have time to be bored. . .
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
Texas Agricultural Extension WWW Server (http://taex.tamu.edu/)
|
|||
|
Extension Information Technology / Texas Agricultural Extension
|
|||
|
Service
|
|||
|
The Texas A&M University System / College Station, Texas 77843-2468
|
|||
|
This page was last modified Thu Feb 20 15:47:14 1997 by PMS.
|
|||
|
(URL=http://taex001.tamu.edu/bb/articles/bbartlg.html)
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Copyright © 1997, Paul M. Sittler
|
|||
|
Published in Issue 15 of the Linux Gazette, March 1997
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
[ TABLE OF CONTENTS ] [ FRONT PAGE ] Back Next
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
"Linux Gazette...making Linux just a little more fun!"
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
DATE AND ITS SWITCHES
|
|||
|
|
|||
|
by Larry Ayers
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
At first glance the humble GNU utility date seems to be a very minor
|
|||
|
program, perhaps useful in shell-scripts but hardly something to get
|
|||
|
excited about. Type "date" at the prompt, press enter, and "Tue Feb 11
|
|||
|
09:25:50 CST 1997" (or something similar) is displayed on your screen.
|
|||
|
As with so many unix-ish utilities, the bare command is really just a
|
|||
|
template, waiting to be laden with switches.
|
|||
|
|
|||
|
I keep a journal, and I've been using a header line for each entry
|
|||
|
with this format:
|
|||
|
|
|||
|
|
|||
|
Tue 11 Feb 1997 *** Journal Entry #44 *** 9:30 PM
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Weary of typing the header each day, some time ago I began attempts to
|
|||
|
automate it. Creating an abbreviation or macro for the center field is
|
|||
|
not hard with most editors, but I wanted the date and time as well.
|
|||
|
Reading the man page for date I discovered that it has numerous
|
|||
|
formatting switches. You can make the command print out the date
|
|||
|
and/or the time in just about any fashion you can think of. The first
|
|||
|
field of the above header can be created with these switches:
|
|||
|
|
|||
|
|
|||
|
date '+%a %-d %b %Y'
|
|||
|
|
|||
|
while the time-of-day field uses these:
|
|||
|
|
|||
|
date '+%-I:%M %p'
|
|||
|
|
|||
|
The single quotes are essential when combining several of the
|
|||
|
switches. I tried for some time to get the command to do what I wanted
|
|||
|
without success; while rereading the man- page I eventually noticed
|
|||
|
the quotes. Of course no-one is going to memorize date's numerous
|
|||
|
switches, which is probably one reason the shell script was invented.
|
|||
|
I wrote two short scripts; the first, called mydate, is just:
|
|||
|
|
|||
|
#!/bin/bash
|
|||
|
date '+%a %-d %b %Y'
|
|||
|
|
|||
|
|
|||
|
|
|||
|
The second, called mytime is the similar but with the above time
|
|||
|
switches for date.
|
|||
|
|
|||
|
Typing the daily header in Emacs was now somewhat easier: first the
|
|||
|
command Control-u Esc-!; when prompted in the mini-buffer I'd type
|
|||
|
mydate and the formatted date would begin the line. Next a keyboard
|
|||
|
macro for the center "Journal Entry" field, then a command like the
|
|||
|
first to have the time inserted at the end of the line.
|
|||
|
|
|||
|
After performing this little keyboard ritual for a few days, it
|
|||
|
occurred to me that perhaps an Emacs macro could have a shell command
|
|||
|
embedded within it. Reading a few Info files confirmed this
|
|||
|
supposition and suggested yet another refinement. I learned that it's
|
|||
|
possible to cause a macro to pause for input and then resume! This
|
|||
|
would be just ideal for the journal entry number.
|
|||
|
|
|||
|
The sequence which I came up with was: Control-( to start recording
|
|||
|
the macro, then Control-u Esc-! followed (when prompted) by mydate. At
|
|||
|
this point I typed in some spaces, then *** Journal Entry #, followed
|
|||
|
by Control-u Control-x q to start a recursive edit; this pauses the
|
|||
|
macro and allows the entry number to be entered. Next is Esc Control-c
|
|||
|
which exits the recursive edit and lets the macro proceed. The macro
|
|||
|
is completed with some more spaces, then control-u Esc-!, the mytime
|
|||
|
shell-script command, and ends with two Enter keystrokes and two
|
|||
|
spaces, to indent the first sentence. Control-) stops the
|
|||
|
macro-recording. Whew! That's a lot harder to describe than to type.
|
|||
|
|
|||
|
This routine would be ridiculously esoteric if you had to remember it.
|
|||
|
Luckily in Emacs you only have to do it one time. Once you've
|
|||
|
constructed such a macro and tried it out to see if it does what you
|
|||
|
want, two more steps will record it in your ~/.emacs file so that it
|
|||
|
can be executed with a simple keystroke.
|
|||
|
|
|||
|
The first step is to give the macro a name, which can be anything.
|
|||
|
Esc-x name-last-kbd-macro, followed by Return, then the name and
|
|||
|
another Return, sets the name. At this point load your ~/.emacs file,
|
|||
|
move the cursor to where you want the macro definition, then type
|
|||
|
Esc-x insert-kbd-macro, followed by Return. There you go! As long as
|
|||
|
you keep your ~/.emacs file you'll have the macro available. Now you
|
|||
|
can type Esc-x [macroname] and it'll execute. If you've put a
|
|||
|
recursive edit in it, just remember to type Esc Control-c after you've
|
|||
|
inserted the text you need and the macro will conclude.
|
|||
|
|
|||
|
This may seem like a convoluted procedure, and it is, the first time
|
|||
|
you do it: haltingly typing in a macro, starting over from scratch
|
|||
|
after one mis-typed character, all the while frequently referring to
|
|||
|
the docs. Then repeating the process when it doesn't do what you
|
|||
|
wanted!
|
|||
|
|
|||
|
The second time you will probably remember about half of the commands,
|
|||
|
enough that it's no longer a tortuous task. Creating and saving macros
|
|||
|
using these techniques isn't an everyday task; I've found that I have
|
|||
|
to refresh my memory on at least part of the procedure every time I do
|
|||
|
it, but for repetitive editing tasks the time spent is amply repaid.
|
|||
|
|
|||
|
If you make very many of these you risk bloating your ~/.emacs file,
|
|||
|
causing the editor to load even more slowly and wasting memory.
|
|||
|
Typically these macros have a specific use, so it makes sense to keep
|
|||
|
them in categorised LISP files, one for each type of file you edit.
|
|||
|
Put each file in the directory where it will be used, and load them on
|
|||
|
demand with the command Esc-x load-file [filename].
|
|||
|
|
|||
|
So there is a reason the Emacs partisans like to call it an
|
|||
|
"extensible" editor. These macros are just the tip of the iceberg;
|
|||
|
over the years many LISP extensions to Emacs have been contributed to
|
|||
|
the free software community by programmers world-wide. Luckily some of
|
|||
|
the best of them tend to be incorporated into successive releases of
|
|||
|
Emacs and XEmacs; many others are available from the Emacs-Lisp
|
|||
|
Archive. Another good source for Emacs information is the Gnu Emacs
|
|||
|
and XEmacs Information and Links Site.
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
Larry Ayers<layers@vax2.rainis.net>
|
|||
|
|
|||
|
Last modified: Thu Feb 27 18:39:47 CST 1997
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Copyright © 1997, Larry Ayers
|
|||
|
Published in Issue 15 of the Linux Gazette, March 1997
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
[ TABLE OF CONTENTS ] [ FRONT PAGE ] Back Next
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
"Linux Gazette...making Linux just a little more fun!"
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
SSC is expanding Matt Welsh's Linux Installation & Getting Started by
|
|||
|
adding chapters about each of the major distributions. Each chapter is
|
|||
|
being written by a different author in the Linux community. Here's a
|
|||
|
sneak preview -- the Debian chapter by Boris Beletsky, one of the
|
|||
|
Debian developers. --Editor
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Debian Linux Installation & Getting Started
|
|||
|
|
|||
|
By Boris D. Beletsky, borik@isracom.co.il
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Table of contents
|
|||
|
|
|||
|
1. Getting and installing Debian GNU/Linux.
|
|||
|
1.1 Getting floppy images.
|
|||
|
1.2 Preparing the floppies.
|
|||
|
1.3 Downloading the packages.
|
|||
|
1.4 Booting from floppies and installing Debian GNU/Linux.
|
|||
|
|
|||
|
2. Running Debian GNU/Linux.
|
|||
|
|
|||
|
2.1 Debian packaging system and package installation utilities.
|
|||
|
2.1.1 Package Classifications.
|
|||
|
2.1.2 Package Relationships.
|
|||
|
2.1.3 Dselect.
|
|||
|
2.1.4 Dpkg.
|
|||
|
|
|||
|
3. About Debian.
|
|||
|
3.1 Debian community.
|
|||
|
3.2 Mailing lists.
|
|||
|
3.3 Bug tracing system.
|
|||
|
|
|||
|
4. Almost the end.
|
|||
|
4.1 Acknowledgments.
|
|||
|
4.2 Last Note.
|
|||
|
4.3 Copyright.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
1. Getting and installing Debian GNU/Linux
|
|||
|
|
|||
|
|
|||
|
|
|||
|
META: I will not expand on system requirements here because this
|
|||
|
subject is surely covered in previous chapters of this book or in the
|
|||
|
"Linux Hardware Compatibility HOWTO" located at
|
|||
|
http://sunsite.unc.edu/mdw/HOWTO/Hardware-HOWTO.html.
|
|||
|
|
|||
|
1.1 Getting floppy images
|
|||
|
|
|||
|
If you have access to the Internet, the best way to get Debian is via
|
|||
|
anonymous FTP (File Transfer Protocol). The home ftp site of Debian is
|
|||
|
located at ftp.debian.org in /pub/debian directory. The structure of
|
|||
|
debian archive is built as following:
|
|||
|
|
|||
|
./stable/ (latest stable debian release)
|
|||
|
./stable/binary-i386 (debian packages for i386 architecture)
|
|||
|
./stable/disks-i386 (boot and root disks needed for Debian
|
|||
|
installation)
|
|||
|
./stable/disks-i386/current (The current boot floppy set)
|
|||
|
./stable/disks-i386/special-kernels (Special kernels and boot floppy
|
|||
|
disks, for hardware configurations that refuse working with our
|
|||
|
regular boot floppies)
|
|||
|
./stable/msdos-i386 (dos short file names for debian packages)
|
|||
|
|
|||
|
|
|||
|
|
|||
|
For base installation of Debian you will need about 12 megabytes of
|
|||
|
disk space, and some floppies. First you will need boot and root
|
|||
|
floppy images. Debian provides two sets of installation floppy images,
|
|||
|
for floppy 1440 and 1200 floppy drives. Check what floppy drive your
|
|||
|
system boots from, (it is the A: drive under Dos) and download the
|
|||
|
appropriate disk set. Files in ./stable/disks-i386/current:
|
|||
|
|
|||
|
Filename Label Description rsc1440.bin "Rescue Floppy" Floppy set
|
|||
|
for systems with 1.2MB floppy drive and at least 5MB RAM.
|
|||
|
drv1440.bin "Device Drivers"
|
|||
|
base14-1.bin "Base 1"
|
|||
|
base14-2.bin "Base 2"
|
|||
|
base14-3.bin "Base 3"
|
|||
|
base14-4.bin "Base 4"
|
|||
|
root.bin "Root Disk"
|
|||
|
rsc1440r.bin "Rescue Floppy" Optional Rescue Disk image for low
|
|||
|
memory systems (less then 5MB of RAM) rsc1200r.bin "Rescue Floppy"
|
|||
|
Floppy set for systems with 1.44MB floppy drive drv1200.bin "Device
|
|||
|
Drivers"
|
|||
|
base12-1.bin "Base 1"
|
|||
|
base12-2.bin "Base 2"
|
|||
|
base12-3.bin "Base 3"
|
|||
|
base12-4.bin "Base 4"
|
|||
|
root.bin "Root Disk"
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Choose the appropriate floppy set, corresponding to your hardware
|
|||
|
setup (Ram and floppy drive). What ever you choose, at the end you
|
|||
|
have to have 7 floppy images which contain, "Rescue Floppy", "Device
|
|||
|
Drivers, "Base 1", "Base 2" ..., "Root Disk". (Note, "Root Disk" image
|
|||
|
is the same for all drives and system types.)
|
|||
|
|
|||
|
1.2 Preparing the floppies
|
|||
|
|
|||
|
Next step is to prepare the floppies for the installation by copying
|
|||
|
the images into disks. Hence those files are disk images, they should
|
|||
|
be copied block-by-block. In Dos you can use the RAWRITE utility for
|
|||
|
that purpose located at
|
|||
|
ftp://ftp.debian.org/pub/debian/tools/rawrite2.exe. Here is a brief
|
|||
|
explanation on how to use it:
|
|||
|
|
|||
|
C:\> RAWRITE2
|
|||
|
|
|||
|
By executing the RAWRITE2 command as stated above, you will accomplish
|
|||
|
the following, the file "<file>" will be copied block-by-block into
|
|||
|
the drive "<drive>".
|
|||
|
|
|||
|
On any Unix like operation systems you can use dd(1):
|
|||
|
|
|||
|
# dd if=file of=/dev/fd0 bs=10k
|
|||
|
|
|||
|
META: In some Unix systems the first floppy device maybe named
|
|||
|
differently.
|
|||
|
|
|||
|
When you finish rawriting don't forget to mark the floppies else you
|
|||
|
will get confused later.
|
|||
|
|
|||
|
1.3 Downloading the packages
|
|||
|
|
|||
|
In order to install and use Debian you will need more then the base
|
|||
|
system. To decide what packages you want on your system download the
|
|||
|
file 'Packages' from ftp://ftp.debian.org/pub/debian/stable/Packages.
|
|||
|
This file is a list of Debian packages available for the moment in
|
|||
|
stable Debian distribution. This file comes in special format, evry
|
|||
|
package has it's own entry separated by a blank line, here is an
|
|||
|
explanation of each field in the package entry:
|
|||
|
|
|||
|
Package: The name of the package.
|
|||
|
Priority: The state of importance of the package.
|
|||
|
Required - Should be installed for system to work properly.
|
|||
|
Important - Not required though, important.
|
|||
|
Optional - Doesn't have to be installed but still useful.
|
|||
|
Extra - Package may conflict with. other packages with higher
|
|||
|
priorities.
|
|||
|
Section: This field declares a Debian section of the package. Base -
|
|||
|
base system.
|
|||
|
Devel - development tools.
|
|||
|
X11 - XWindows packages.
|
|||
|
Admin - administration utilities.
|
|||
|
Doc - documentation.
|
|||
|
Comm - various communication utilities.
|
|||
|
Editors - various editors.
|
|||
|
Electronics - electronics utilities.
|
|||
|
Games - games (you knew that didn't you?).
|
|||
|
Graphics - graphics utilities.
|
|||
|
Hamradio - utilities for internet radio.
|
|||
|
Mail - email clients and servers.
|
|||
|
Math - mathematics utilities (such as calculators, etc...).
|
|||
|
Net - various tools to connect to the network (usualy TCP/IP).
|
|||
|
News - servers and clients for internet news (NNTP).
|
|||
|
Shells - shells, such as tcsh, bash.
|
|||
|
Sound - any sound applications (such as, cd players).
|
|||
|
TeX - anything that can read, write, and convert TeX.
|
|||
|
Text - applications to manipulate texts. (such as nroff)
|
|||
|
Misc - everything else that doesn't fit in the above.
|
|||
|
Maintainer: The name of the person who maintains the package and his
|
|||
|
contact Email address.
|
|||
|
Version: The version of the package in the following format:
|
|||
|
<upstream-version>-<debian-version>.
|
|||
|
Depends: That field declares the dependency of the package with
|
|||
|
another one (or more), that means that this package can not be used
|
|||
|
or installed without the other packages listed in this field.
|
|||
|
Recommends: Another level of package dependencies. It is strongly
|
|||
|
recommended to install the packages listed in this field together
|
|||
|
with the package this entry entry describes.
|
|||
|
Suggests: Packages listed in this field maybe useful to the packages
|
|||
|
this entry entry describes.
|
|||
|
Filename: Filename of the package on ftp/cdrom.
|
|||
|
Msdos-Filename: Filename of the package in dos short format.
|
|||
|
Size: The size of the package after the installation.
|
|||
|
Md5sum: The md5sum check to be sure that this package came from us.
|
|||
|
Description: This field will tell you about the package (finally!),
|
|||
|
DO NOT download the package without reading it.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
META: More detailed explanation on Debian packaging scheme you can
|
|||
|
find in section 2.1 of this chapter.
|
|||
|
|
|||
|
The above should give you an idea on how to build your personal
|
|||
|
download list. When you have the list of packages you want to
|
|||
|
download, you will have to decide how and when you want to download
|
|||
|
them. If you are an experienced user you may want to download the
|
|||
|
netbase package, and slip/ppp if needed, for later downloading from
|
|||
|
linux. Otherwise you can download all the packages from your current
|
|||
|
OS and install them later from mounted partition.
|
|||
|
|
|||
|
1.4 Booting from floppies and installing Debian GNU/Linux
|
|||
|
|
|||
|
The Rescue Floppy
|
|||
|
|
|||
|
|
|||
|
Place the Rescue floppy in the a: floppy drive, and reset the
|
|||
|
system by pressing reset, turning the system off and then on,
|
|||
|
or by pressing Control-Alt-Del on the keyboard. The floppy disk
|
|||
|
should be accessed, and you should then see a screen that
|
|||
|
introduces the rescue floppy and ends with the boot: prompt.
|
|||
|
It's called the Rescue floppy because you can use it to boot
|
|||
|
your system and perform repairs if there is ever a problem that
|
|||
|
makes your hard disk unbootable. Thus, you should save this
|
|||
|
floppy after you've installed your system.
|
|||
|
|
|||
|
You can do two things at the boot: prompt. You can press the
|
|||
|
function keys F1 through F10 to view a few pages of helpful
|
|||
|
information, or you can boot the system. If you have any
|
|||
|
hardware devices that aren't made accessible from Linux
|
|||
|
correctly when Linux boots, you may find a parameter to add to
|
|||
|
the boot command line in the screens you see by pressing F3,
|
|||
|
F4, and F5. If you add any parameters to the boot command line,
|
|||
|
be sure to type the word linux and a space before the first
|
|||
|
parameter. If you simply press Enter, that's the same as typing
|
|||
|
linux without any special parameters.
|
|||
|
|
|||
|
If this is the first time you're booting the system, just press
|
|||
|
Enter and see if it works correctly. It probably will. If not,
|
|||
|
you can reboot later and look for any special parameters that
|
|||
|
inform the system about your hardware.
|
|||
|
|
|||
|
Once you press Enter, you should see the message Loading...,
|
|||
|
and then Uncompressing Linux..., and then a page or so of
|
|||
|
cryptic information about the hardware in your system. There
|
|||
|
may be a many messages in the form can't find something, or
|
|||
|
something not present, can't initialize something, or even this
|
|||
|
driver release depends on something. Most of these messages are
|
|||
|
harmless. You see them because the installation boot disk is
|
|||
|
built to run on computers with many different peripheral
|
|||
|
devices. Obviously, no one computer will have every possible
|
|||
|
peripheral device, so the operating system may emit a few
|
|||
|
complaints while it looks for peripherals you don't own. You
|
|||
|
may also see the system pause for a while. This happens when it
|
|||
|
is waiting for a device to respond, and that device is not
|
|||
|
present on your system. If you find the time it takes to boot
|
|||
|
the system unacceptably long, you can create a custom kernel
|
|||
|
once you've installed your system without all of the drivers
|
|||
|
for non-existent devices.
|
|||
|
|
|||
|
Low-Memory Systems
|
|||
|
|
|||
|
|
|||
|
If you system has 4MB RAM, you may now see a paragraph about
|
|||
|
low memory and a text menu with three choices. If your system
|
|||
|
has enough RAM you won't see this at all, and you'll go
|
|||
|
directly to the color-or-monochrome dialog box. If you get the
|
|||
|
low-memory menu, you should go through its selections in order.
|
|||
|
Partition your disk, activate the swap partition, and start the
|
|||
|
graphical installation system. The program that is used to
|
|||
|
partition your disk is called cfdisk, and you should use the
|
|||
|
manual page for cfdisk as an aid in its operation. Use cfdisk
|
|||
|
to create a Linux Swap partition (type 82). You need the swap
|
|||
|
partition to provide virtual memory during the installation
|
|||
|
process, since that process will use more memory than you have
|
|||
|
in your system. Select the size for the amount of virtual
|
|||
|
memory you intend to use once your system is installed. 16
|
|||
|
megabytes is probably the lowest amount that's practical, use
|
|||
|
32 megabytes if you can spare the space, and 64 if your disk is
|
|||
|
large enough that you won't miss that much.
|
|||
|
|
|||
|
The Color-or-Monochrome Dialog Box
|
|||
|
|
|||
|
|
|||
|
Once the system has finished booting, you should see the color
|
|||
|
or monochrome choice dialog box. If your monitor displays
|
|||
|
black-and-white, press Enter to continue with the installation.
|
|||
|
Otherwise, use the arrow key to move the cursor to the Color
|
|||
|
menu item and then press Enter. The display should change from
|
|||
|
black-and-white to color. Then press Enter again to continue
|
|||
|
with the installation.
|
|||
|
|
|||
|
The Main Menu
|
|||
|
|
|||
|
|
|||
|
You may see a dialog box that says The installation program is
|
|||
|
determining the current state of your system. On some systems,
|
|||
|
this will go by too quickly to read. You'll see this dialog box
|
|||
|
between steps in the main menu. The installation program will
|
|||
|
check the state of the system in between each step. This
|
|||
|
checking allows you to re-start the installation without losing
|
|||
|
the work you have already done if you happen to halt your
|
|||
|
system in the middle of the installation process. If you have
|
|||
|
to restart an installation, you will have to configure
|
|||
|
color-or-monochrome, configure your keyboard, re-activate your
|
|||
|
swap partition, and re-mount any disks that have been
|
|||
|
initialized. Anything else that you have done with the
|
|||
|
installation system will be saved.
|
|||
|
|
|||
|
During the entire installation process, you will be presented
|
|||
|
with the main menu. The choices at the top of the menu will
|
|||
|
change to indicate your progress in installing the system. Phil
|
|||
|
Hughes wrote in Linux Journal that you could teach a chicken to
|
|||
|
install Debian! He meant that the installation process was
|
|||
|
mostly just pecking at the return key. The first choice on the
|
|||
|
installation menu is the next action that you should perform
|
|||
|
according to what the system detects you have already done. It
|
|||
|
should say Next, and at this point the next item should be
|
|||
|
Configure the Keyboard.
|
|||
|
|
|||
|
Configuring the Keyboard
|
|||
|
|
|||
|
|
|||
|
Make sure the highlight is on the Next item, and Press Enter to
|
|||
|
go to the keyboard configuration menu. Select a keyboard that
|
|||
|
conforms to the layout used for your national language, or
|
|||
|
select something close if the keyboard layout you want isn't
|
|||
|
represented. Once the system is installed, you'll be able to
|
|||
|
select a keyboard layout from a wider range of choices. Move
|
|||
|
the highlight to the keyboard selection you desire and press
|
|||
|
enter. Use the arrow keys to move the highlight - they are in
|
|||
|
the same place in all national language keyboard layouts, so
|
|||
|
they are independent of the keyboard configuration.
|
|||
|
|
|||
|
The Shell
|
|||
|
|
|||
|
|
|||
|
If you are an experienced Unix or Linux user, press LeftAlt-F2
|
|||
|
to get to the second virtual console. That's the Alt key on the
|
|||
|
left-hand side of the space bar, and the F2 function key, at
|
|||
|
the same time. This is a separate window running a Bourne shell
|
|||
|
clone called ash. At this point you are booted from the RAM
|
|||
|
disk, and there is a limited set of Unix utilities available
|
|||
|
for your use. You can see what programs are available with the
|
|||
|
command ls /bin /sbin /usr/bin /usr/sbin. Use the menus to
|
|||
|
perform any task that they are able to do - the shell and
|
|||
|
commands are only there in case something goes wrong. In
|
|||
|
particular, you should always use the menus, not the shell, to
|
|||
|
activate your swap partition, because the menu software can't
|
|||
|
detect that you've done this from the shell. Press LeftAlt-F1
|
|||
|
to get back to menus. Linux provides up to 64 virtual consoles,
|
|||
|
although the Rescue floppy only uses a few of them.
|
|||
|
|
|||
|
Last Chance!
|
|||
|
|
|||
|
|
|||
|
Did we tell you to back up your disks? Here's your first chance
|
|||
|
to wipe out all of the data on your disks, and your last chance
|
|||
|
to save your old system. If you haven't backed up all of your
|
|||
|
disks, remove the floppy from the drive, reset the system, and
|
|||
|
run backups.
|
|||
|
|
|||
|
Partition Your Hard Disks
|
|||
|
|
|||
|
|
|||
|
If you have not already partitioned your disks for Linux native
|
|||
|
and Linux swap filesystems, the menu item Next will be
|
|||
|
Partition a Hard Disk. If you have already created at least one
|
|||
|
Linux Native and one Linux Swap disk partition, the Next menu
|
|||
|
selection will be Initialize and Activate the Swap Disk
|
|||
|
Partition, or you may even skip that step if your system had
|
|||
|
low memory and you were asked to activate the swap partition as
|
|||
|
soon as the system started. Whatever the Next menu selection
|
|||
|
is, you can use the down-arrow key to select Partition a Hard
|
|||
|
Disk.
|
|||
|
|
|||
|
The Partition a Hard Disk menu item presents you with a list of
|
|||
|
disk drives you can partition, and runs the cfdisk program,
|
|||
|
which allows you to create and edit disk partitions. The cfdisk
|
|||
|
manual page is included with this document, and you should read
|
|||
|
it now. You must create one "Linux" (type 83) disk partition,
|
|||
|
and one "Linux Swap" (type 82) partition.
|
|||
|
|
|||
|
Your swap partition will be used to provide virtual memory for
|
|||
|
the system and should be between 16 and 128 megabytes in size,
|
|||
|
depending on how much disk space you have and how many large
|
|||
|
programs you want to run. Linux will not use more than 128
|
|||
|
megabytes of swap, so there's no reason to make your swap
|
|||
|
partition larger than that. a swap partition is strongly
|
|||
|
recommended, but you can do without one if you insist, and if
|
|||
|
your system has more than 16 megabytes of RAM. If you wish to
|
|||
|
do this, please select the Do Without a Swap Partition item
|
|||
|
from the menu.
|
|||
|
|
|||
|
The "Linux" disk partition will hold all of your files, and you
|
|||
|
may make it any size between 40 megabytes and the maximum size
|
|||
|
of your disk minus the size of the swap partition. If you are
|
|||
|
already familiar with Unix or Linux, you may want to make
|
|||
|
additional partitions - for example, you can make partitions
|
|||
|
that will hold the /var, and /usr, filesystems.
|
|||
|
|
|||
|
Initialize and Activate the Swap Disk Partition
|
|||
|
|
|||
|
|
|||
|
This will be the Next menu item once you have created one disk
|
|||
|
partition. You have the choice of initializing and activating a
|
|||
|
new swap partition, activating a previously-initialized one,
|
|||
|
and doing without a swap partition. It's always permissible to
|
|||
|
re-initialize a swap partition, so select Initialize and
|
|||
|
Activate the Swap Disk Partition unless you are sure you know
|
|||
|
what you are doing. This menu choice will give you the option
|
|||
|
to scan the entire partition for un-readable disk blocks caused
|
|||
|
by defects on the surface of the hard disk platters. This is
|
|||
|
useful if you have MFM, RLL, or older SCSI disks, and never
|
|||
|
hurts. Properly-working IDE disks don't need this choice, as
|
|||
|
they have their own internal mechanism for mapping out bad disk
|
|||
|
blocks.
|
|||
|
|
|||
|
The swap partition provides virtual memory to supplement the
|
|||
|
RAM memory that you've installed in your system. It's even used
|
|||
|
for virtual memory while the system is being installed. That's
|
|||
|
why we initialize it first.
|
|||
|
|
|||
|
Initialize a Linux Disk Partition
|
|||
|
|
|||
|
|
|||
|
At this point, the Next menu item should be Initialize a Linux
|
|||
|
Disk Partition. If it isn't, it's because you haven't completed
|
|||
|
the disk partitioning process, or you haven't made one of the
|
|||
|
menu choices dealing with your swap partition.
|
|||
|
|
|||
|
You can initialize a Linux Disk partition, or alternately you
|
|||
|
can mount a previously-initialized one.
|
|||
|
|
|||
|
These floppies will not upgrade an old system without removing
|
|||
|
the files - Debian provides a different procedure than using
|
|||
|
the boot floppies for upgrading existing Debian systems. Thus,
|
|||
|
if you are using old disk partitions that are not empty, you
|
|||
|
should initialize them (which erases all files) here. You must
|
|||
|
initialize any partitions that you created in the disk
|
|||
|
partitioning step. About the only reason to mount a partition
|
|||
|
without initializing it at this point would be to mount a
|
|||
|
partition upon which you have already performed some part of
|
|||
|
the installation process using this same set of installation
|
|||
|
floppies.
|
|||
|
|
|||
|
Select the Next menu item to initialize and mount the / disk
|
|||
|
partition. The first partition that you mount or initialize
|
|||
|
will be the one mounted as / (pronounced root). You will be
|
|||
|
offered the choice to scan the disk partition for bad blocks,
|
|||
|
as you were when you initialized the swap partition. It never
|
|||
|
hurts to scan for bad blocks, but it could take 10 minutes or
|
|||
|
more to do so if you have a large disk.
|
|||
|
|
|||
|
Once you've mounted the / partition, the Next menu item will be
|
|||
|
Install the Base System unless you've already performed some of
|
|||
|
the installation steps. You can use the arrow keys to select
|
|||
|
the menu items to initialize and/or mount disk partitions if
|
|||
|
you have any more partitions to set up. If you have created
|
|||
|
separate partitions for /var, /usr, or other filesystems, you
|
|||
|
should initialize and/or mount them now.
|
|||
|
|
|||
|
Install the Base System
|
|||
|
|
|||
|
|
|||
|
This should be the Next menu step after you've mounted your /
|
|||
|
disk, unless you've already performed some of the installation
|
|||
|
steps on /. Select the Install the Base System menu item. There
|
|||
|
will be a pause while the system looks for a "local copy" of
|
|||
|
the base system. This search is for CD-ROM installations and
|
|||
|
will not succeed, and you'll be offered a menu of drives to use
|
|||
|
to read the base floppies. Select the appropriate drive. Feed
|
|||
|
in the Base 1, 2, and 3 (and 4 if you are using 1.2MB floppies)
|
|||
|
as requested by the program. If one of the base floppies is
|
|||
|
unreadable, you'll have to create a replacement floppy and feed
|
|||
|
all 3 (or 4) floppies into the system again. Once the floppies
|
|||
|
have all been read, the system will install the files it's read
|
|||
|
from them. This could take 10 minutes or more on slow systems,
|
|||
|
less on faster ones.
|
|||
|
|
|||
|
Install the Operating System Kernel
|
|||
|
|
|||
|
|
|||
|
At this point, the Next menu item should be Install the
|
|||
|
Operating System Kernel. Select it, and you will be prompted to
|
|||
|
select a floppy drive and insert the rescue floppy. This will
|
|||
|
copy the kernel on to the hard disk. In a later step this
|
|||
|
kernel will be used to create a custom boot floppy for your
|
|||
|
system, and to make the hard disk bootable without a floppy.
|
|||
|
|
|||
|
Install the Device Drivers
|
|||
|
|
|||
|
|
|||
|
Select the menu item to install the device drivers, and you'll
|
|||
|
be prompted to insert the device drivers floppy. The device
|
|||
|
drivers will be copied to your hard disk. Select the Configure
|
|||
|
Device Drivers menu item and look for devices that are on your
|
|||
|
system. Configure those device drivers, and they will be loaded
|
|||
|
whenever your system boots.
|
|||
|
|
|||
|
There is a menu selection for PCMCIA device drivers, but you
|
|||
|
need not use it . Once your system is installed, you can
|
|||
|
install the pcmcia-cs package. This detects PCMCIA cards
|
|||
|
automatically, and configures the ones it finds. It also copes
|
|||
|
with hot-plugging the cards while the system is booted - they
|
|||
|
will all be configured as they are plugged in, and
|
|||
|
de-configured when you unplug them.
|
|||
|
|
|||
|
Configure the Base System
|
|||
|
|
|||
|
|
|||
|
At this point you've read in all of the files that make up a
|
|||
|
minimal Debian system, but you must perform some configuration
|
|||
|
before the system will run. Select the Configure the Base
|
|||
|
System menu item.
|
|||
|
|
|||
|
You'll be asked to select your time zone. Look for your time
|
|||
|
zone or region of the world in the menu, and type it at the
|
|||
|
prompt. This may lead to another menu, in which you can select
|
|||
|
your actual time zone.
|
|||
|
|
|||
|
Next, you'll be asked if your system clock is to be set to GMT
|
|||
|
or local time. Select GMT if you will only be running Linux and
|
|||
|
Unix on your system, and select local time if you will be
|
|||
|
running another operating system such as DOS or Windows. Unix
|
|||
|
and Linux keep GMT time on the system clock and use software to
|
|||
|
convert it to the local time zone. This allows them to keep
|
|||
|
track of daylight savings time and leap years, and even allows
|
|||
|
users who are logged in from other time zones to individually
|
|||
|
set the time zone used on their terminal. If you run the system
|
|||
|
clock on GMT and your locality uses daylight savings time,
|
|||
|
you'll find that the system adjusts for daylight savings time
|
|||
|
properly on the days that it starts and ends.
|
|||
|
|
|||
|
Configure the Network
|
|||
|
|
|||
|
|
|||
|
You'll have to configure the network even if you don't have a
|
|||
|
network, but you'll only have to answer the first two questions
|
|||
|
- what is the name of your computer?, and is your system
|
|||
|
connected to a network?.
|
|||
|
|
|||
|
If you are connected to a network, here come some questions
|
|||
|
that you may not be able to figure out on your own - check with
|
|||
|
your system administrator if you don't know:
|
|||
|
|
|||
|
+ Your host name.
|
|||
|
+ Your domain name.
|
|||
|
+ Your computer's IP address.
|
|||
|
+ The netmask to use with your network.
|
|||
|
+ The IP address of your network.
|
|||
|
+ The broadcast address to use on your network.
|
|||
|
+ The IP address of the default gateway system you should route
|
|||
|
to, if your network has a gateway.
|
|||
|
+ The system on your network that you should use as a DNS
|
|||
|
(Domain Name Service) server.
|
|||
|
+ Whether you connect to the network using Ethernet.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Some technical details you might, or might not, find handy: the
|
|||
|
program will guess that the network IP address is the
|
|||
|
bitwise-AND of your system's IP address and your netmask. It
|
|||
|
will guess the broadcast address is the bitwise OR of your
|
|||
|
system's IP address with the bitwise negation of the netmask.
|
|||
|
It will guess that your gateway system is also your DNS server.
|
|||
|
If you can't find any of these answers, use the system's
|
|||
|
guesses - you can change them once the system has been
|
|||
|
installed, if necessary, by editing /etc/init.d/network .
|
|||
|
|
|||
|
Make the Hard Disk Bootable
|
|||
|
|
|||
|
|
|||
|
If you select to make the hard disk boot directly to Linux, you
|
|||
|
will be asked to install a master boot record. If you aren't
|
|||
|
using a boot manager (and this is probably the case if you
|
|||
|
don't know what a boot manager is), answer yes to this
|
|||
|
question. The next question will be whether you want to boot
|
|||
|
Linux automatically from the hard disk when you turn on your
|
|||
|
system. This sets Linux to be the bootable partition - the one
|
|||
|
that will be loaded from the hard disk. If you answer no to
|
|||
|
this question, you can set the bootable partition later using
|
|||
|
the DOS fdisk program, or with the Linux fdisk or activate
|
|||
|
programs.
|
|||
|
|
|||
|
If you are installing Linux on a drive other than the first
|
|||
|
hard disk in your system, be sure to make a boot floppy. The
|
|||
|
boot ROM of most systems is only capable of directly booting
|
|||
|
from the first hard drive, not the second one. You can,
|
|||
|
however, work around this problem once you've installed your
|
|||
|
system. To do so, read the instructions in the directory
|
|||
|
/usr/doc/lilo.
|
|||
|
|
|||
|
Make a Boot Floppy
|
|||
|
|
|||
|
|
|||
|
You should make a boot floppy even if you intend to boot the
|
|||
|
system from the hard disk. The reason for this is that it's
|
|||
|
possible for the hard disk bootstrap to be mis-installed, but a
|
|||
|
boot floppy will almost always work. Select Make a Boot Floppy
|
|||
|
from the menu and feed the system a blank floppy as directed.
|
|||
|
Make sure the floppy isn't write-protected, as the software
|
|||
|
will format and write it. Mark this the "Custom Boot" floppy
|
|||
|
and write-protect it once it has been written.
|
|||
|
|
|||
|
The Moment of Truth
|
|||
|
|
|||
|
|
|||
|
This is what electrical engineers call the smoke test - what
|
|||
|
happens when you turn on a new system for the first time.
|
|||
|
Remove the floppy disk from the floppy drive, and select the
|
|||
|
Reboot the System menu item. If the Linux system doesn't start
|
|||
|
up, insert the Custom Boot floppy you created and reset your
|
|||
|
system. Linux should boot. You should see the same messages as
|
|||
|
when you first booted the installation boot floppy, followed by
|
|||
|
some new messages.
|
|||
|
|
|||
|
Set the Root Password
|
|||
|
|
|||
|
|
|||
|
This is the password for the super-user, a login that bypasses
|
|||
|
all security protection on your system. It should only be used
|
|||
|
to perform system administration, and only for as short a time
|
|||
|
as possible. Do not use root as your personal login. You will
|
|||
|
be prompted to create a personal login as well, and that's the
|
|||
|
one you should use to send and receive e-mail and perform most
|
|||
|
of your work, not root. The reason to avoid using root's
|
|||
|
privileges is that you might be tricked into running a
|
|||
|
trojan-horse program - that is a program that takes advantage
|
|||
|
of your super-user power to compromise the security of your
|
|||
|
system behind your back. Any good book on Unix system
|
|||
|
administration will cover this topic in more detail - consider
|
|||
|
reading one if it's new to you. The good news is that Linux is
|
|||
|
probably more secure than other operating systems you might run
|
|||
|
on your PC. DOS and Windows, for example, give all programs
|
|||
|
super-user privilege. That's one reason that they have been so
|
|||
|
plagued by viruses.
|
|||
|
|
|||
|
All of the passwords you create should contain from 6 to 8
|
|||
|
characters, and should contain both upper and lower-case
|
|||
|
characters, as well as punctuation characters.
|
|||
|
|
|||
|
Once you've added both logins, you'll be dropped into the
|
|||
|
dselect program. The Dselect Tutorial is required reading
|
|||
|
before you run dselect. Dselect allows you to select packages
|
|||
|
to be installed on your system. If you have a CD-ROM or hard
|
|||
|
disk containing the additional Debian packages that you want to
|
|||
|
install on your system, or you are connected to the Internet,
|
|||
|
this will be useful to you right away. Otherwise, you may want
|
|||
|
to quit dselect and start it later, once you have transported
|
|||
|
the Debian package files to your system. You must be the
|
|||
|
super-user (root) when you run dselect. If you are about to
|
|||
|
install the X Window system and you do not use a US keyboard,
|
|||
|
you should read the X11 Release note for non-US-keyboard users.
|
|||
|
|
|||
|
|
|||
|
Log In
|
|||
|
|
|||
|
|
|||
|
After you've quit dselect, you'll be presented with the login
|
|||
|
prompt. Log in using the personal login and password you
|
|||
|
selected. Your system is now ready to use.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
2. Running Debian GNU/Linux.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
This section will deal Debian packaging system and debian specific
|
|||
|
utilities. Ab ovo.
|
|||
|
|
|||
|
2.1 Debian packaging system and package installation utilities
|
|||
|
|
|||
|
Debian distributions comes in archives called packages. Every package
|
|||
|
is a collection of files (software, usually) that can be installed
|
|||
|
using "dpkg" or "dselect". In addition the package contains some
|
|||
|
information about it self that is read by the installation utilities.
|
|||
|
|
|||
|
2.1.1 Package Classifications
|
|||
|
|
|||
|
The packages included with Debian GNU/Linux are classified according
|
|||
|
to how essential they are (priority), and according to their
|
|||
|
functionality (section).
|
|||
|
|
|||
|
The "priority" of a package indicates how essential or necessary it
|
|||
|
is. We have classified all packages into four different priority
|
|||
|
levels:
|
|||
|
|
|||
|
Required
|
|||
|
|
|||
|
|
|||
|
"Required" packages are packages that must be installed for the
|
|||
|
system to correctly operate. The required packages are the
|
|||
|
packages that were installed with the base system. Thus, they
|
|||
|
are already installed. Never, never, never remove a required
|
|||
|
package from the system unless you are absolutely sure what you
|
|||
|
are doing. This bears repeating. Never, never, never remove a
|
|||
|
required package from the system unless you are absolutely sure
|
|||
|
what you are doing. It is likely that doing so will render your
|
|||
|
system completely unusable.
|
|||
|
|
|||
|
Required packages are abbreviated in dselect as "Req".
|
|||
|
|
|||
|
Important
|
|||
|
|
|||
|
|
|||
|
"Important" packages are packages that are found on almost all
|
|||
|
Unix-like operating systems. Such packages include cron', man',
|
|||
|
and vi'.
|
|||
|
|
|||
|
Important packages are abbreviated in dselect as "Imp".
|
|||
|
|
|||
|
Standard
|
|||
|
|
|||
|
|
|||
|
"Standard" packages are packages that, more or less, comprise
|
|||
|
what we consider to be the "standard", character-based Debian
|
|||
|
GNU/Linux system. The Standard system includes a fairly
|
|||
|
complete software development environment and GNU Emacs.
|
|||
|
|
|||
|
Standard packages are abbreviated in dselect as "Std".
|
|||
|
|
|||
|
Optional
|
|||
|
|
|||
|
|
|||
|
"Optional" packages are packages that comprise a fairly
|
|||
|
complete system. The Optional system includes a fairly complete
|
|||
|
TeX environment and the X Window System.
|
|||
|
|
|||
|
Optional packages are abbreviated in dselect as "Opt".
|
|||
|
|
|||
|
Extra
|
|||
|
|
|||
|
|
|||
|
"Extra" packages are packages that are only useful to a small
|
|||
|
or select group of people, or that would be installed for a
|
|||
|
specific purpose rather than as a general part of an operating
|
|||
|
system. Such packages include electronics and ham radio
|
|||
|
packages.
|
|||
|
|
|||
|
Extra packages are abbreviated in dselect as "Xtr".
|
|||
|
|
|||
|
|
|||
|
|
|||
|
By default, dselect automatically selects the Standard system, if the
|
|||
|
user doesn't want to individually select the packages to be installed.
|
|||
|
|
|||
|
|
|||
|
The "section" of a package indicates the functionality or use of a
|
|||
|
package. Packages on the CD-ROM and in FTP archive are arranged
|
|||
|
according to section. The section names are fairly self-explanatory:
|
|||
|
for example, the category admin' contains packages for system
|
|||
|
administration, and the category devel' contains packages for software
|
|||
|
development and programming. Unlike priority levels, there are many
|
|||
|
sections, and more will probably be added in the future, so we do not
|
|||
|
individually describe any of them in the manual.
|
|||
|
|
|||
|
2.1.2 Package Relationships
|
|||
|
|
|||
|
Each package includes information about how it relates to the other
|
|||
|
packages included with the system. There are four package
|
|||
|
relationships in Debian GNU/Linux: conflicts, dependencies,
|
|||
|
recommendations, and suggestions.
|
|||
|
|
|||
|
A "conflict" occurs when two or more packages cannot be installed on
|
|||
|
the same system at the same time. A good example of conflicting
|
|||
|
packages are mail transfer agents (MTAs). A mail transfer agent is a
|
|||
|
program that delivers electronic mail to other users on the system or
|
|||
|
to other machines on the network. Debian GNU/Linux includes two
|
|||
|
alternative mail transfer agents: sendmail' and smail'.
|
|||
|
|
|||
|
Only one mail transfer agent can be installed on the system at a time,
|
|||
|
as they both do the same job and are not designed to coexist.
|
|||
|
Therefore, the sendmail' and smail' packages conflict. If you try to
|
|||
|
install sendmail' when smail' is already installed, the package
|
|||
|
maintenance system will refuse to install it. Likewise, if you try to
|
|||
|
install smail' when sendmail' is already installed, it will refuse to
|
|||
|
install it.
|
|||
|
|
|||
|
A "dependency" occurs when one package requires another package to
|
|||
|
function properly. Continuing our electronic mail example, users read
|
|||
|
mail with programs called mail user agents (MUAs). Popular mail user
|
|||
|
agents include elm', pine', and Emacs RMAIL. It is normal to install
|
|||
|
several MUAs at once, so these packages do not conflict. But a mail
|
|||
|
user agent does not deliver mail--it uses the mail transfer agent to
|
|||
|
do that. Therefore, all mail user agent packages depend on a mail
|
|||
|
transfer agent.
|
|||
|
|
|||
|
A package can also "recommend" or "suggest" other related packages.
|
|||
|
|
|||
|
2.1.3 Dselect
|
|||
|
|
|||
|
META: This section provides brief tutorial on Debian Dselect, for more
|
|||
|
detailed explanation please refer to Dselect Manual located at
|
|||
|
ftp://ftp.debian.org/debian/Debian-1.2/disks-i386/current/dselect.be
|
|||
|
ginner.6.html
|
|||
|
|
|||
|
Dselect is simple menu driven interface that will help you install
|
|||
|
packages. It is used to select packages you wish to install.
|
|||
|
|
|||
|
It will step you through the package installation process as follows:
|
|||
|
|
|||
|
* Choose the access method to use.
|
|||
|
* Update list of available packages, if possible.
|
|||
|
* Request which packages you want on your system.
|
|||
|
* Install and upgrade wanted packages.
|
|||
|
* Configure any packages that are unconfigured.
|
|||
|
* Remove unwanted software.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
The main dselect screen looks like that:
|
|||
|
|
|||
|
------------------------------------------------------------------
|
|||
|
|
|||
|
Debian Linux `dselect' package handling front end.
|
|||
|
0. [A]ccess Choose the access method to use.
|
|||
|
1. [U]pdate Update list of available packages, if possible.
|
|||
|
2. [S]elect Request which packages you want on your system.
|
|||
|
3. [I]nstall Install and upgrade wanted packages.
|
|||
|
4. [C]onfig Configure any packages that are unconfigured.
|
|||
|
5. [R]emove Remove unwanted software.
|
|||
|
6. [Q]uit Quit dselect.
|
|||
|
|
|||
|
------------------------------------------------------------------
|
|||
|
|
|||
|
|
|||
|
|
|||
|
META: There are two ways of selecting the option from the menu, one is
|
|||
|
choosing it with arrows, another one is pressing the key in []'s.
|
|||
|
|
|||
|
Access
|
|||
|
|
|||
|
|
|||
|
In this menu you can choose the method you will use for
|
|||
|
obtaining/installing the packages.
|
|||
|
|
|||
|
Abbrev. Description
|
|||
|
cdrom Install from a CD-ROM.
|
|||
|
nfs Install from an NFS server (not yet mounted).
|
|||
|
harddisk Install from a hard disk partition (not yet mounted).
|
|||
|
mounted Install from a filesystem which is already mounted.
|
|||
|
floppy Install from a pile of floppy disks.
|
|||
|
ftp Install using ftp.
|
|||
|
|
|||
|
|
|||
|
Update
|
|||
|
|
|||
|
|
|||
|
Dselect will read the packages list file (exactly the same file
|
|||
|
that was discussed in the 1.3 section) and will create a
|
|||
|
database of available packages locally on your system.
|
|||
|
|
|||
|
Select
|
|||
|
|
|||
|
This is where you select the packages, choose your love and hit
|
|||
|
<Enter>. If you have a slow machine be aware that the screen
|
|||
|
will clear and can remain blank for 15 seconds so don't start
|
|||
|
bashing keys at this point. The first thing that comes up on
|
|||
|
the screen is page 1 of the Help file. You can get to this help
|
|||
|
by hitting ? at any point in the Select screens and you can
|
|||
|
page through the help screens by hitting the . (full stop) key.
|
|||
|
|
|||
|
|
|||
|
To exit the Select screen after all selections are complete,
|
|||
|
hit <Enter>. This will return you to the main screen _if_ there
|
|||
|
are no problems with your selection. Else you will be asked to
|
|||
|
deal with those problems. When you are happy with any given
|
|||
|
screen hit <Enter> to get out.
|
|||
|
|
|||
|
Problems are quite normal and are to be expected. If you select
|
|||
|
package A and that package requires package B to run, then
|
|||
|
dselect will warn you of the problem and will most likely
|
|||
|
suggest a solution. If package A conflicts with package B (they
|
|||
|
are mutually exclusive) you will be asked to decide between
|
|||
|
them.
|
|||
|
|
|||
|
Install
|
|||
|
|
|||
|
|
|||
|
Dselect runs through the entire 800 packages and installs those
|
|||
|
selected. Expect to get asked to make decisions as you go. It
|
|||
|
is often useful to switch to a different shell to compare, say,
|
|||
|
an old config with a new one. If the old file is conf.modules
|
|||
|
the new one will be conf.modules.dpkg-new.
|
|||
|
|
|||
|
The screen scrolls past fairly quickly on a new machine. You
|
|||
|
can stop/start it with ^S/^Q and at the end of the run you will
|
|||
|
get a list of any uninstalled packages. If you want to keep a
|
|||
|
record of everything that happens use normal Unix features like
|
|||
|
tee or script.
|
|||
|
|
|||
|
Configure
|
|||
|
|
|||
|
|
|||
|
Most packages get configured in step 3, but anything left
|
|||
|
hanging can be configured here.
|
|||
|
|
|||
|
Remove
|
|||
|
|
|||
|
|
|||
|
Remove packages that no longer needed.
|
|||
|
|
|||
|
Quit
|
|||
|
|
|||
|
|
|||
|
Au revoir.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
2.1.4 Dpkg
|
|||
|
|
|||
|
META: This section provides a brief tutorial on Debian Dpkg program.
|
|||
|
|
|||
|
Dpkg is command line tool for installing and manipulating debian
|
|||
|
packages. It has several switches, which allow you to install,
|
|||
|
configure, update, remove and do other operations on debian packages
|
|||
|
(even build your own). Dpkg also allowd you to list the available
|
|||
|
packages, list files 'owned' by packages, find which package the file
|
|||
|
is owned by, et cetera.
|
|||
|
|
|||
|
Installing new packages / updating existing ones.
|
|||
|
|
|||
|
|
|||
|
It's as simple as any other dpkg operation. All you have to do
|
|||
|
is to type the following command:
|
|||
|
|
|||
|
|
|||
|
# dpkg -i <filename.deb>
|
|||
|
|
|||
|
where <filename> is the name of the file containing a debian package,
|
|||
|
such as, 'tcsh_6.06-11_i386.deb'. Dpkg is partly interactive;
|
|||
|
during the installation it may ask you additional questions,
|
|||
|
such as, wether to install the new version of a configuration
|
|||
|
file, or to keep the old one.
|
|||
|
|
|||
|
You may also unpack a package without configuring it: type:
|
|||
|
|
|||
|
|
|||
|
dpkg --unpack <filename>
|
|||
|
|
|||
|
If the package you are trying to install depends on a non-existing
|
|||
|
package or on a newer version of a package you have, or if any
|
|||
|
other problem occurs during the installation, dpkg will abort
|
|||
|
with a verbose error message.
|
|||
|
|
|||
|
Configure installed packages
|
|||
|
|
|||
|
|
|||
|
It happens that dpkg aborts during an installation and leaves
|
|||
|
the package installed, though unconfigured. It also happens
|
|||
|
that the users unpack packages without configuring it. Debian
|
|||
|
packaging system requires the package to be configured to avoid
|
|||
|
dependency problems. More than that, some packages require
|
|||
|
configuration to work properly.
|
|||
|
|
|||
|
To configure it, simply type:
|
|||
|
|
|||
|
|
|||
|
dpkg --configure <package>
|
|||
|
|
|||
|
where <package> is the name of the package, such as, 'tcsh' (which is
|
|||
|
not the same thing as a filename we mentioned above).
|
|||
|
|
|||
|
Removing installed packages
|
|||
|
|
|||
|
|
|||
|
In Debian package system, there are two ways to murder a
|
|||
|
package, called 'remove' and 'purge'. The 'remove' switch just
|
|||
|
removes the specified package; the 'purge' switch also purges
|
|||
|
the configuration files. The usage is:
|
|||
|
|
|||
|
|
|||
|
dpkg -r <package>
|
|||
|
dpkg --purge <package>
|
|||
|
|
|||
|
Of course, if there are any installed packages that depend on the one
|
|||
|
you wish to remove, the package will not be removed, and dpkg
|
|||
|
will abort with a verbose error message.
|
|||
|
|
|||
|
Reporting package status
|
|||
|
|
|||
|
|
|||
|
To report the status of the package (i.e., installed, not
|
|||
|
installed, unconfigured, etc.), type:
|
|||
|
|
|||
|
|
|||
|
dpkg -s <package>
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Listing available packages
|
|||
|
|
|||
|
|
|||
|
To list the installed packages that match some pattern, type:
|
|||
|
|
|||
|
|
|||
|
dpkg -l [<package-name-pattern>]
|
|||
|
|
|||
|
where <package-name-pattern> is an optional argument specifying a
|
|||
|
pattern for the package names to match, such as, "*sh". Yes,
|
|||
|
normal shell wildcards are allowed. If you don't specify the
|
|||
|
pattern, all the installed packages will be listed.
|
|||
|
|
|||
|
Listing files 'owned' by package
|
|||
|
|
|||
|
|
|||
|
To list all the files owned by a particular package, simply
|
|||
|
type:
|
|||
|
|
|||
|
|
|||
|
dpkg -L <package>
|
|||
|
|
|||
|
However, it will not list the files created by package-specific
|
|||
|
installation scripts.
|
|||
|
|
|||
|
Finding package 'owning' a file
|
|||
|
|
|||
|
|
|||
|
To find the package wich is 'owning' a particular file, type
|
|||
|
the following command:
|
|||
|
|
|||
|
|
|||
|
dpkg -S <filename-pattern>
|
|||
|
|
|||
|
where <filename-pattern> is the pattern for the file to search for.
|
|||
|
Again, normal shell wildcards are allowed.
|
|||
|
|
|||
|
Summary
|
|||
|
|
|||
|
|
|||
|
Dpkg is very simple to use and is preferred over dselect when
|
|||
|
all you have to do is to install, upgrade or remove a small
|
|||
|
number of packages. It also has some functionality which
|
|||
|
dselect (which is, in fact, an interface to dpkg) doesn't have,
|
|||
|
such as, finding package 'owning' a file. Here we haven't
|
|||
|
describe all the options dpkg have. For the full list, refer to
|
|||
|
dpkg(8) man page.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
3. About Debian
|
|||
|
|
|||
|
|
|||
|
|
|||
|
3.1 Debian community
|
|||
|
|
|||
|
Debian project was created by Ian Murdock in 1993, initially under the
|
|||
|
sponsorship of the Free Software Foundation's GNU project. Later,
|
|||
|
Debian has parted from FSF. Debian was created is the result of a
|
|||
|
volunteer effort to create a free, high-quality Unix-compatible
|
|||
|
operating system based on Linux kernel, complete with a suite of
|
|||
|
applications.
|
|||
|
|
|||
|
Debian community is a group of above 150 unpaid volunteers from over
|
|||
|
the world who collaborate via the Internet. The founders of the
|
|||
|
project have formed the organization "Software in the Public Interest"
|
|||
|
to sponsor Debian GNU/Linux development.
|
|||
|
|
|||
|
Software in the Public Interest
|
|||
|
|
|||
|
Software in the Public Interest (SPI) is a non-profit organization
|
|||
|
formed when FSF withdrew their sponsorship of Debian. The purpose of
|
|||
|
the organization is to develop and distribute free software. Its goals
|
|||
|
are very much like those of FSF, and it encourages programmers to use
|
|||
|
the GNU General Public License on their programs. However, SPI has a
|
|||
|
slightly different focus in that it is building and distributing a
|
|||
|
Linux system that diverges in many technical details from the GNU
|
|||
|
system planned by FSF. SPI still communicates with FSF, and it
|
|||
|
cooperates in sending them changes to GNU software and in asking its
|
|||
|
users to donate to FSF and the GNU project.
|
|||
|
|
|||
|
SPI can be reached at:
|
|||
|
|
|||
|
E-Mail: bruce@pixar.com Postal address:
|
|||
|
|
|||
|
Software in the Public Interest
|
|||
|
P.O. Box 70152
|
|||
|
Pt. Richmond, CA 94807-0152
|
|||
|
|
|||
|
|
|||
|
Phone: 510-215-3502 (Bruce Perens at work)
|
|||
|
|
|||
|
3.2 Mailing lists
|
|||
|
|
|||
|
There are several Debian-related mailing lists:
|
|||
|
|
|||
|
debian-announce@lists.debian.org
|
|||
|
Moderated. Major system announcements. Usually about one
|
|||
|
message per month.
|
|||
|
|
|||
|
debian-changes@lists.debian.org
|
|||
|
Announcements of new package releases for the stable
|
|||
|
distribution. Usually several messages per day.
|
|||
|
|
|||
|
debian-devel-changes@lists.debian.org
|
|||
|
Announcements of new package releases for the unstable
|
|||
|
distribution. Usually several messages per day.
|
|||
|
|
|||
|
debian-user@lists.debian.org
|
|||
|
A mailing lists where users of Debian ask for and get support.
|
|||
|
Usually about 50 packages per day.
|
|||
|
|
|||
|
debian-sparc@lists.debian.org,
|
|||
|
debian-alpha@lists.debian.org,
|
|||
|
debian-68k@lists.debian.org
|
|||
|
Lists for those who are involved in porting Debian software to
|
|||
|
SPARC / DEC Alpha / Motorolla 680x0 platforms.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
There are also several mailing lists for Debian developers.
|
|||
|
|
|||
|
You can subscribe to those mailing list by mail or via www, for more
|
|||
|
information please visit http://www.debian.org/
|
|||
|
|
|||
|
3.3 Bug tracing system.
|
|||
|
|
|||
|
Debian project has a bug tracing system which handles the bug reports
|
|||
|
provided by users. As soon as the bug report is received, the bug is
|
|||
|
given a number and all the information provided on this particular bug
|
|||
|
is stored in a file and mailed to the maintainer of the package. When
|
|||
|
the bug is fixed, it must be marked as done ("closed") by the
|
|||
|
maintainer; however, if it was closed by mistake, it may be reopened.
|
|||
|
|
|||
|
To receive more info on the bug tracing system, send e-mail to
|
|||
|
request@bugs.debian.org with "help" in the body.
|
|||
|
|
|||
|
4. Almost the end.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
4.1 Acknowledgments.
|
|||
|
|
|||
|
Many thanks to Bruce Perens, the author of Debian FAQ and Debian
|
|||
|
installation manual for kindly letting me use his materials. Bruce
|
|||
|
should be considered as co-author of this chapter.
|
|||
|
|
|||
|
Thanks a lot to Vadik Vygonets, my beloved cousin, that also helped me
|
|||
|
very much.
|
|||
|
|
|||
|
And thanks a lot to all members of Debian community for their hard
|
|||
|
work, let's hope that Debian will become even better.
|
|||
|
|
|||
|
4.2 Last Note
|
|||
|
|
|||
|
Hence Debian changes very fast, alot of facts may change faster then
|
|||
|
the book, but this document will be updated regularly, you can find it
|
|||
|
at http://www.cs.huji.ac.il/~borik/debian/ligs/
|
|||
|
|
|||
|
4.3 Copyright
|
|||
|
|
|||
|
Any redistributions or changes to this document may be made only with
|
|||
|
permission from the author.
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Copyright © 1997, Boris D. Beletsky
|
|||
|
Published in Issue 15 of the Linux Gazette, March 1, 1997
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
[ TABLE OF CONTENTS ] [ FRONT PAGE ] Back Next
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
"Linux Gazette...making Linux just a little more fun!"
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Welcom to the Graphics Muse Set your browser to the width of the line
|
|||
|
below for best viewing.
|
|||
|
© 1996 by mjh
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
--> Button Bar --> muse:
|
|||
|
1. v; to become absorbed in thought
|
|||
|
2. n; [ fr. Any of the nine sister goddesses of learning and the arts
|
|||
|
in Greek Mythology ]: a source of inspiration
|
|||
|
|
|||
|
W elcome to the Graphics Muse! Why a "muse"? Well, except for the
|
|||
|
sisters aspect, the above definitions are pretty much the way I'd
|
|||
|
describe my own interest in computer graphics: it keeps me deep in
|
|||
|
thought and it is a daily source of inspiration.
|
|||
|
|
|||
|
[Graphics Mews] [Musings] [Resources] indent T his column is dedicated
|
|||
|
to the use, creation, distribution, and dissussion of computer
|
|||
|
graphics tools for Linux systems.
|
|||
|
|
|||
|
After much delay I've finally started learning about the Blue
|
|||
|
Moon Rendering Tools (BMRT). It seemed only natural that I take what I
|
|||
|
learned and pass it on to my readers. So, starting this month, I'm
|
|||
|
going to do a three part series on BMRT and RenderMan® shaders.
|
|||
|
I've gotten help, of course. My thanks go out to Paul Sargent for
|
|||
|
providing example code and a place to bounce ideas off and to Larry
|
|||
|
Gritz, author of BMRT, for general support and technical assistance.
|
|||
|
The first in this 3 part series is an introduction to the tools and
|
|||
|
some relatively simple examples on how to use them.
|
|||
|
Although the BMRT articles are a big project in themselves, I
|
|||
|
don't want to devote 3 entire issues of the Muse to just BMRT. In this
|
|||
|
months column I'll also be covering a few other topics.
|
|||
|
* A review of Mark Kilgard's OpenGL Programming for the X Window
|
|||
|
System.
|
|||
|
* Information on scanner support for Linux.
|
|||
|
|
|||
|
Both of these are go into some detail. Along with the usual set of
|
|||
|
Mews offerings, this should be enough to hold you until next month.
|
|||
|
I was going to do a bit on John Beale's wonderful tool, HF-Lab,
|
|||
|
this month but decided to wait until next month. I happened to run
|
|||
|
across a few other POV-Ray tips recently and thought that the set of
|
|||
|
tips along with the HF-Lab review would fit well together. Look for
|
|||
|
them next month.
|
|||
|
An update on my crashed system woes: my little network at home
|
|||
|
uses a 386 16Mhz Dell computer as a server for doing backups. I had
|
|||
|
set it up but had not implemented the backups when my main system bit
|
|||
|
the bucket. After getting my main system running again I ended up with
|
|||
|
some extra drives that I wanted to put in my server. I first tried to
|
|||
|
make backups of my main system, across the network, using a version of
|
|||
|
taper that I had installed on my main system and just copied over to
|
|||
|
the server. That sort of worked, but for some reason taper wouldn't
|
|||
|
see some of my target directories. I figured it was incompatible with
|
|||
|
the installation I had on the 386, so I upgraded to Linux Pro (which
|
|||
|
is what I installed on my main system). Mistake. The server stopped
|
|||
|
working. The problem is a secondary IDE that I added to make use of
|
|||
|
the extra hard disks. I mucked with it for a week, got fed up and now
|
|||
|
have a new Cyrix 166, motherboard, and mini tower on order. The
|
|||
|
motherboard and 166 are going in the main box, and the old 486 and
|
|||
|
motherboard are going in the mini tower. I'm retiring the 386. It will
|
|||
|
take its rightful place next to my retired Wyse286 PC with its 20M
|
|||
|
hard drive.
|
|||
|
I never wanted to be a system administrator. I just want to use
|
|||
|
my systems. sigh At least with Linux I have more control over what I
|
|||
|
use.
|
|||
|
So, one month after disaster hit I still don't have reliable
|
|||
|
backups running. There is money to be made in making backups easy for
|
|||
|
Linux users. I guarantee it.
|
|||
|
|
|||
|
Graphics Mews
|
|||
|
|
|||
|
Disclaimer: Before I get too far into this I should note that
|
|||
|
any of the news items I post in this section are just that - news.
|
|||
|
Either I happened to run across them via some mailing list I was on,
|
|||
|
via some Usenet newsgroup, or via email from someone. I'm not
|
|||
|
necessarily endorsing these products (some of which may be
|
|||
|
commercial), I'm just letting you know I'd heard about them in the
|
|||
|
past month.
|
|||
|
|
|||
|
indent
|
|||
|
|
|||
|
GIFWizard
|
|||
|
|
|||
|
If you'd like to reduce the size of your GIF images but don't
|
|||
|
really know how to do it on your own, there is a free online service
|
|||
|
you can try. The GIF Wizard
|
|||
|
(http://www.raspberryhill.com/gifwizard.html) will work with images
|
|||
|
already on the Net (you provide a URL for the image) or on images on
|
|||
|
your hard drive. Note: Definitely don't ask me about this
|
|||
|
service - I haven't used it and only offer the info here because it
|
|||
|
looked like it might be of interest to some of my readers. indent
|
|||
|
indent
|
|||
|
|
|||
|
Tnpic - GIF/JPEG indexer
|
|||
|
|
|||
|
Tnpic, from Russell Marks (who doesn't have email access
|
|||
|
anymore), is a GIF/JPEG indexer that used to be bundled with zgv up
|
|||
|
until version 2.3. The index is output as a JPEG. Tnpic is available
|
|||
|
from sunsite.unc.edu /pub/Linux/apps/graphics/tnpic-2.4.tar.gz
|
|||
|
|
|||
|
indent
|
|||
|
|
|||
|
Ra-vec
|
|||
|
|
|||
|
Ra-vec is a new free application for Linux, SGi and Sun's from
|
|||
|
Rob Aspin that converts X Bitmaps, such as 2D plan drawings
|
|||
|
(architect's drawings), into a vector format which can be read by the
|
|||
|
3D modeling package AC3D (see the January 1997 issue). Using Ra-vec,
|
|||
|
complex 3D models and environments may be rapidly prototyped, reducing
|
|||
|
overall development time.
|
|||
|
|
|||
|
To download a free copy of the software got to:
|
|||
|
http://www.comp.lancs.ac.uk/computing/users/aspinr/ra-vec.html.
|
|||
|
indent
|
|||
|
|
|||
|
VARKON for Linux
|
|||
|
|
|||
|
VARKON is a high level development tool for CAD and Product
|
|||
|
Modelling appliactions from Microform AB, SWEDEN. The system includes
|
|||
|
a very powerful modelling language called MBS and an interactive
|
|||
|
environment for traditional modelling and developing MBS-applications.
|
|||
|
|
|||
|
|
|||
|
Keywords are:
|
|||
|
2D, 3D, Wireframe models, Surface models, Parametric, Structured
|
|||
|
Object Oriented Database, Easy to integrate with other systems,
|
|||
|
Commersially available on most platforms at a very low price. At the
|
|||
|
Web site - http://www.microform.se - you will find
|
|||
|
* A lot of technical information about VARKON
|
|||
|
* Links to download the latest version of Linux-VARKON (version
|
|||
|
1.14E)
|
|||
|
* Links to download the full documentation in text or MS-Word-format
|
|||
|
* Links to download demo-applications with source MBS-code,
|
|||
|
documentation, etc.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
You can also download a restricted but free demo-version of the system
|
|||
|
for Windows95. indent
|
|||
|
|
|||
|
QuickCam Resources
|
|||
|
|
|||
|
Interested in doing some work with the Connectix QuickCam? Thats
|
|||
|
the little round camera that has become very popular with Windows and
|
|||
|
Mac users. Russ Nelson (of the old Packet Drivers fame, for those of
|
|||
|
you who remember that software) maintains a very good resource page
|
|||
|
for the QuickCam at www.crynwr.com/qcpc. It contains links to drivers
|
|||
|
and applications for many operating systems, including Linux and other
|
|||
|
PC based Unices.
|
|||
|
Connectix also maintains a page for developers. They offer lots
|
|||
|
of information and require only that you register for their developers
|
|||
|
program, which costs nothing. You can find them at
|
|||
|
www.connectix.com/connect/developer.html
|
|||
|
If you're looking for a Linux driver for the Color QuickCam,
|
|||
|
check The SANE Project, a project to develop a generic interface to
|
|||
|
various types of media devices, such as scanners and the QuickCam.
|
|||
|
This package also contains a frontend to the Color QuickCam driver.
|
|||
|
|
|||
|
For those of you in the US wondering what these little gadgets cost,
|
|||
|
CompUSA sells the Color QuickCams for about $249. indent indent
|
|||
|
|
|||
|
Did You Know?
|
|||
|
|
|||
|
There are many places to find information about OpenGL on the
|
|||
|
Internet. The following is only a small list:
|
|||
|
* The OpenGL Utility Toolkit (GLUT)
|
|||
|
Programming Interface API Version 3
|
|||
|
http://reality.sgi.com/mjk_asd/spec3/spec3.html
|
|||
|
Mark J. Kilgard
|
|||
|
Silicon Graphics, Inc.
|
|||
|
* Frequently Asked GLUT Questions
|
|||
|
http://reality.sgi.com/mjk_asd/glut3/glut-faq.html
|
|||
|
* An Introduction to OpenGL
|
|||
|
http://www.dgp.toronto.edu/people/van/courses/csc418/opengl1.html
|
|||
|
* The OpenGL WWW Pages
|
|||
|
http://www.digital.com/pub/doc/opengl/
|
|||
|
* Course 22: OpenGL and Window System Integration
|
|||
|
OpenGL Portability Notes
|
|||
|
SIGGRAPH '96
|
|||
|
http://www.ssec.wisc.edu/~brianp/sig96/portable.htm
|
|||
|
* OpenGL WWW Center from Silicon Graphics
|
|||
|
http://www.sgi.com/Technology/openGL/
|
|||
|
|
|||
|
There are also a few sites with RenderMan information:
|
|||
|
* The RenderMan Repository -
|
|||
|
(http://pete.cs.caltech.edu/RMR/index.html)
|
|||
|
A storehouse for all things related to RenderMan.
|
|||
|
* RManNotes -
|
|||
|
(http://www.cgrg.ohio-state.edu/~smay/RManNotes/index.html)
|
|||
|
General information about writing shaders in the RenderMan Shading
|
|||
|
Language and using the two most commonly available RenderMan
|
|||
|
renderers
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Q and A
|
|||
|
|
|||
|
Q: Is displacment mapping the same thing as reaction-diffusion?
|
|||
|
|
|||
|
A: No. Reaction-diffusion simulates the mixing of chemicals, which is
|
|||
|
theorized to have something to do with certain organic texture
|
|||
|
patterns, like leopard skin.
|
|||
|
|
|||
|
Bump mapping is perturbing the normal of an object to simulate bumps,
|
|||
|
but without actually moving points on the surface.
|
|||
|
|
|||
|
Displacement mapping does what bump mapping merely simulates - it
|
|||
|
actually distorts the surface points of the object which is being
|
|||
|
mapped. This avoids artifacts you get from the bump mapping
|
|||
|
approximation (like actually making the silhouettes rough). You can
|
|||
|
think of it as a height field over an arbitrary surface.
|
|||
|
|
|||
|
Q: What is a stochastic raytracer and are there any freely available?
|
|||
|
|
|||
|
A: "Stochastic sampling" or "distribution ray tracing" (it's not
|
|||
|
called distributed these days) refers to placing samples at irregular
|
|||
|
intervals, rather than regularly spacing them. It doesn't have
|
|||
|
anything to do with the number of rays per pixel -- 1 sample per pixel
|
|||
|
can easily be jittered, and 100 samples per pixel can be regularly
|
|||
|
spaced. Also, it's not dependent on ray tracing -- PRMan uses
|
|||
|
stochastic sampling and it uses a scanline method.
|
|||
|
|
|||
|
Technically, stochastic sampling transfers high frequency signal
|
|||
|
energy above the Nyquist limit into noise, rather than having that
|
|||
|
energy alias as lower frequencies. It's just trading one artifact for
|
|||
|
another, but by coincidence the human visual system appears to find
|
|||
|
noise less objectionable than aliasing.
|
|||
|
|
|||
|
BMRT is a stochastic raytracers. POV-Ray is reported to be (but no
|
|||
|
official word if it is or not). Others include (not all are
|
|||
|
raytracers): PRMan, Mental Ray, and Alias.
|
|||
|
|
|||
|
Thanks to Larry Gritz for these definitions.
|
|||
|
|
|||
|
Q: What is tessellation?
|
|||
|
|
|||
|
A: Mark Kilgard writes the following in his OpenGL Programming for the
|
|||
|
X Window System:
|
|||
|
|
|||
|
In computer graphics, tessellation is the process of breaking a
|
|||
|
complex geometric surface into simple convex polygons.
|
|||
|
|
|||
|
The use of convex polygons allow for better performance in OpenGL.
|
|||
|
indent indent indent
|
|||
|
|
|||
|
Musings
|
|||
|
|
|||
|
indent OpenGL Programming for the X Windows System
|
|||
|
Mark Kilgard
|
|||
|
Addison-Wesley Developers Press
|
|||
|
|
|||
|
There are a growing number of Application Programming Interfaces
|
|||
|
(API's) available for Linux that enable software developers to create
|
|||
|
programs that render 3D graphics. Some of these are designed to allow
|
|||
|
programs to output data files that can be used by rendering engines to
|
|||
|
create a 3D image either to a display or to a file. The libribout.a
|
|||
|
static library in the BMRT package is an example of this kind of
|
|||
|
interface. It allows the software developer to write a program to
|
|||
|
output a RIB formatted file which can then be used by a RenderMan®
|
|||
|
compliant renderer. Other tools are designed for interactive 3D
|
|||
|
display. One such developer tool is OpenGL. OpenGL is, if not the
|
|||
|
grandfather, the God Father of all interactive 3D development tools.
|
|||
|
OpenGL is an API designed by Silicon Graphics and now managed by
|
|||
|
the OpenGL Architecture Review Board. It is defined by the OpenGL
|
|||
|
Programming Guide as follows:
|
|||
|
|
|||
|
The OpenGL graphics system is a software interface to graphics
|
|||
|
hardware. (The GL stands for Graphics Library.) It allows you to
|
|||
|
create interactive programs that produce color images of moving
|
|||
|
three-dimensional objects.
|
|||
|
|
|||
|
The interface is a window system independent interface to graphics
|
|||
|
hardware. In order to use OpenGL with a particular windowing system it
|
|||
|
must be used with a supplemental API. This supplemental API allows
|
|||
|
OpenGL to create its graphics contexts and windows in which OpenGL
|
|||
|
will do its rendering.
|
|||
|
Linux uses as its windowing system the X Windowing system, as do
|
|||
|
most, if not all, other Unices. To use OpenGL with X Windows the
|
|||
|
software developer must become familiar with GLX, the X Extension for
|
|||
|
OpenGL, along with one or more toolkits such as the X Toolkit (Xt) and
|
|||
|
a widget set like Motif (Xm). This is not a simple task. Just learning
|
|||
|
Xm can be a full time occupation (I know, its what I do now).
|
|||
|
Fortunately, Mark Kilgard has provided a very thorough text on
|
|||
|
integrating OpenGL with the X environment: OpenGL Programming for the
|
|||
|
X Windows System.
|
|||
|
This text contains 6 detailed chapters, 1 chapter devoted to an
|
|||
|
example application, and a number of very useful appendices. The first
|
|||
|
two chapters introduce the reader to OpenGL and the two libraries that
|
|||
|
generally accompany it: GLU, the GL Utility library that is used for
|
|||
|
certain operations that are hardware inspecific such as polygon
|
|||
|
tesselation, and GLX. The introduction is quite good except for
|
|||
|
explaining the use of GLU. All OpenGL functions are prefixed with "gl"
|
|||
|
except for the GLU functions which are prefixed with "glu". I can
|
|||
|
understand why they did this, but it is confusing to remember that
|
|||
|
OpenGL is actually two sets of functions with different prefixes (as
|
|||
|
if the X Windows system didn't provide enough of these already).
|
|||
|
|
|||
|
-Top of next column- indent indent indent
|
|||
|
More Musings...
|
|||
|
* Scanner Report - whats supported and where to get the software.
|
|||
|
* BMRT Part 1: Getting Started - Creating, Previewing, and Final
|
|||
|
Rendering of Simple Images (>45K text + numerous images)
|
|||
|
|
|||
|
indent indent indent
|
|||
|
Chapter 3 is a detailed explanation of how to use OpenGL with
|
|||
|
Motif. The basic premise is that you need to combine OpenGL (gl and
|
|||
|
glu routines) with the X Extension for OpenGL (GLX) and the widget set
|
|||
|
of choice (Xm along with Xt to manage the widget set). That seems like
|
|||
|
a lot of work. Not to mention that writing an OpenGL application this
|
|||
|
way, with the X calls embedded in the source, removes the portability
|
|||
|
that a developer originally had with just OpenGL. It would be nice if
|
|||
|
there were a way to remove the X calls and have a truly portable
|
|||
|
OpenGL application.
|
|||
|
There is. Mark introduces the GLUT library in Chapter 4 which
|
|||
|
hides most (not all) of the window system specific API calls from the
|
|||
|
developer. This toolkit, although not necessarily appropriate for
|
|||
|
full-featured OpenGL applications, provides an example of a toolkit
|
|||
|
which can handle window system API's for the developer and allow the
|
|||
|
developer to write a single source code base portable to any platform.
|
|||
|
The toolkit itself can be implemented in X, Windows NT or any other
|
|||
|
windowing system. The application developer only needs access to the
|
|||
|
toolkit.
|
|||
|
Chapter 4 is an introduction to the more basic features of GLUT.
|
|||
|
It covers such topics as window managment, callbacks, and font
|
|||
|
rendering. Chapter 5 goes into significantly more depth. Its 90+ pages
|
|||
|
cover topics ranging from lighting and texture mapping to using images
|
|||
|
and bitmaps to curves and surfaces. This chapter will be the one most
|
|||
|
readers will refer to repeatedly when they've gotten past their first
|
|||
|
sample OpenGL programs using GLUT. Chapter 6 covers advanced topics
|
|||
|
such as the X Input Extension, Overlays, and peformance issues.
|
|||
|
There are 3 appendices, the most interesting of which is the
|
|||
|
"Functional Description of the GLUT API". This is a reference section
|
|||
|
for the most part although it is not formatted with one page per
|
|||
|
function. This makes it a little hard to find what you're looking for
|
|||
|
since more than one function can be on a page. Other than that its a
|
|||
|
fairly complete description of the GLUT API. There is also a glossary
|
|||
|
that follows the appendices.
|
|||
|
Mark includes extensive sample code right from the start of the
|
|||
|
text. All the code is available for download from the Internet. The
|
|||
|
code is easy to follow and the accompanying text is well written.
|
|||
|
Although Mark does not spend time explaining how to program with the X
|
|||
|
Windows System (knowledge of which is a prerequisite for this text) he
|
|||
|
does thoroughly cover how to integrate OpenGL with the X environment.
|
|||
|
After explaining how this would work he then provides detailed
|
|||
|
information about how to remove the windowing system specific calls by
|
|||
|
using GLUT.
|
|||
|
I find OpenGL Programming for the X Windows System a very well
|
|||
|
written, thoroughly descriptive explanation on how software developers
|
|||
|
can integrate OpenGL with their X Windows applications.
|
|||
|
|
|||
|
Resources
|
|||
|
The following links are just starting points for finding more
|
|||
|
information about computer graphics and multimedia in general for
|
|||
|
Linux systems. If you have some application specific information for
|
|||
|
me, I'll add them to my other pages or you can contact the maintainer
|
|||
|
of some other web site. I'll consider adding other general references
|
|||
|
here, but application or site specific information needs to go into
|
|||
|
one of the following general references and not listed here.
|
|||
|
|
|||
|
|
|||
|
Linux Graphics mini-Howto
|
|||
|
Unix Graphics Utilities
|
|||
|
Linux Multimedia Page
|
|||
|
|
|||
|
Some of the Mailing Lists and Newsgroups I keep an eye on and where I
|
|||
|
get much of the information in this column:
|
|||
|
|
|||
|
The Gimp User and Gimp Developer Mailing Lists.
|
|||
|
The IRTC-L discussion list
|
|||
|
comp.graphics.rendering.raytracing
|
|||
|
comp.graphics.rendering.renderman
|
|||
|
comp.os.linux.announce
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Future Directions
|
|||
|
|
|||
|
Next month:
|
|||
|
* Height Fields with HF-Lab
|
|||
|
* POV-Ray Tips
|
|||
|
* BMRT Part 2: Shaders
|
|||
|
|
|||
|
|
|||
|
Let me know what you'd like to hear about!
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Copyright © 1997, Michael J. Hammel
|
|||
|
Published in Issue 15 of the Linux Gazette, March 1997
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
[ TABLE OF CONTENTS ] [ FRONT PAGE ] Back Next
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
More...
|
|||
|
|
|||
|
|
|||
|
Musings
|
|||
|
* Scanner Report
|
|||
|
|
|||
|
indent
|
|||
|
© 1996 Michael J. Hammel indent
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Scanner Report
|
|||
|
|
|||
|
|
|||
|
In December my brother called me to let me know he had a
|
|||
|
possible Christmas gift for me: a Compaq Keyboard Scanner. He works
|
|||
|
for Compaq and they had a special for employees. Knowing I might not
|
|||
|
have a Linux driver for this he called to ask. I didn't know, so I
|
|||
|
started to investigate. I checked the one place I knew I could ask
|
|||
|
questions like this and get reasonably accurate answers - the Gimp
|
|||
|
Developer and User mailing lists. I posted a message asking if anyone
|
|||
|
knew about scanners and this scanner in particular. Quite a few people
|
|||
|
answered. It turns out this particular scanner is actually an OEM'd
|
|||
|
version of the Visioneer keyboard scanner. The protocol this scanner
|
|||
|
uses in not publicly available and apparently its rather difficult to
|
|||
|
get on the developers list to get the information. So much for getting
|
|||
|
support for this little device. However, the amount of information I
|
|||
|
gathered about other scanner devices, about 14 pages of printed
|
|||
|
material, turned out to be a real windfall. I decided to summarize it
|
|||
|
here in the Muse.
|
|||
|
|
|||
|
First, lets list the set of scanners known to have support. This list
|
|||
|
is a compilation based on what the drivers say they support and what
|
|||
|
individuals have said they are specifically using.
|
|||
|
* HP scanners
|
|||
|
+ HP ScanJet IICX
|
|||
|
+ HP ScanJet IIC (predecessor to CX)
|
|||
|
+ HP 4C
|
|||
|
+ HP ScanJet 4P
|
|||
|
* A4 Tech scanners
|
|||
|
* Nikon color (SCSI)
|
|||
|
* Mustek
|
|||
|
+ M105 scanners
|
|||
|
+ Mustek Paragon 6000CX
|
|||
|
+ Others supported via a Generic SCSI interface
|
|||
|
* MicroTek (aka mTek) scanners
|
|||
|
+ ScanMaker E3
|
|||
|
+ ScanMaker E6
|
|||
|
* Logitec hand-held
|
|||
|
+ The old Logitech Scanman - A B&W-scanner fixed to 200dpi
|
|||
|
+ Logitech Scanman32 (aka Scanman+)
|
|||
|
+ The Logitech Scanman256 - A 100-400dpi Greyscale-Scanner with
|
|||
|
1,4-,6- and 8-bit resolution without dithering.
|
|||
|
* Epson scanners
|
|||
|
As of Nov '95, serial I/O had not been added but parallel and SCSI
|
|||
|
are said to be supported
|
|||
|
+ Epson GT-5000WINS
|
|||
|
* UMAX scanners
|
|||
|
+ UMAX Vista S6
|
|||
|
+ Vista S6 (NOT S6E at this time, hopefully that will change)
|
|||
|
+ Vista S8
|
|||
|
+ UC630
|
|||
|
+ UMAX scanners that might or might not work with it include
|
|||
|
o Vista S12
|
|||
|
o UG630
|
|||
|
o T630
|
|||
|
+ UMAX scanners that are known not to work with it at this time
|
|||
|
include
|
|||
|
o PowerLook
|
|||
|
o Vista S6E
|
|||
|
* Genius hand-held scanners (a few flavors)
|
|||
|
+ Genius GS-B105G
|
|||
|
+ Genius GS4500 and probably the GS4000 and GS4500A
|
|||
|
|
|||
|
The HP scanners appear to all require a generic SCSI interface,
|
|||
|
such as an Adaptec AHA 152x board and its associated driver, and the
|
|||
|
hpscanpbm user level driver. The SCSI board that comes with some (or
|
|||
|
possibly all, I'm not sure) of the HP scanners is not supported at
|
|||
|
this time.
|
|||
|
Knowing which scanners are supported is one thing. Now you need
|
|||
|
to find a driver that goes with them. The information I got was
|
|||
|
provided by the son of a coworker of my brother. Apparently he had
|
|||
|
some free time and had gone out and gathered this list on his own. Not
|
|||
|
all the information was complete and I filled in the rest by perusing
|
|||
|
the sunsite and tsx-11 archives. I also received information on some
|
|||
|
of the drivers from the developers.
|
|||
|
|
|||
|
Driver/Application Supported scanners hpscanpbm-0.3a.tar.gz User level
|
|||
|
driver for HP Scanjet II series a4scan.tgz Drivers for A4 Tech
|
|||
|
scanners coolscan-0.1.tgz User-level driver for the Nikon CoolScan
|
|||
|
SCSI mscan-0.1.tar.gz User level program for using Mustek scanners
|
|||
|
xscan-1.1.tgz User-level X program for scanning with Mustek scanners
|
|||
|
that saves files as X Bitmaps muscan-2.0.6.taz Driver for Mustek
|
|||
|
Paragon 6000CX mtekscan-0.1.tar.gz Driver for MicroTek ScanMaker
|
|||
|
scanners originally written for ScanMaker E6, but will also work with
|
|||
|
the E3. pbmscan-1.2.tar.gz Utility for Logitech scanners (including
|
|||
|
ScanMan 256) ppic0.5.tar.gz Early scanning package w/ EPSON support
|
|||
|
Table 1: scanner drivers for Linux available at
|
|||
|
ftp://sunsite.unc.edu/pub/Linux/apps/graphics/scanners.
|
|||
|
|
|||
|
Driver/Application Use gs105-0.0.1.tar.gz Genius GS-B105G 400 dpi
|
|||
|
greyscale handheld scanner gs4500-1.6.tar.gz Genius GS 4500 hand
|
|||
|
scanners and compatible models logiscan-0.0.4.tar.gz Logitech ScanMan+
|
|||
|
400 dpi handheld scanner driver scan-driver-0.1.8.tar.gz M105 handheld
|
|||
|
scanner driver or clone with GI1904 interface umax-0.4.tar.gz (v0.5
|
|||
|
may be out by now, which is reported to be very much improved over
|
|||
|
v0.4) UMAX scanners
|
|||
|
This one is written by Michael K. Johnson and he reports that there is
|
|||
|
sufficient documentation in the distribution for any one to add new
|
|||
|
UMAX support if they so desire. Table 2: scanner drivers for Linux
|
|||
|
available at
|
|||
|
ftp://tsx-11.mit.edu/pub/linux/ALPHA/scanner/:
|
|||
|
|
|||
|
I don't know what the difference between the pbmscan and logiscan
|
|||
|
packages is but suspect the pbmscan package is a front end to the
|
|||
|
logiscan package. The logiscan package has a front end called gifscan
|
|||
|
that uses SVGALIB (not an X interface) and saves the input into GIF
|
|||
|
files. The pbmscan package scans directly into PBM formatted files.
|
|||
|
|
|||
|
Commercial Scanner Products
|
|||
|
There is only one commercially available product for scanners -
|
|||
|
XVScan from Tummy.com, which contains a graphical front end and
|
|||
|
supports a number of scanners. XVScan runs for about $50US which
|
|||
|
includes the $30 registration for XV.
|
|||
|
Supported Devices (that I know of, there may be others)
|
|||
|
* IIp
|
|||
|
* IIc
|
|||
|
* IIcx
|
|||
|
* 3c (reported to work) Note: According to the HP ScanJet 4c web
|
|||
|
page the 3c and 4c 10-bit and 30-bit scanning modes are INTERNAL
|
|||
|
only. This combined with X and XVs inability to handle other than
|
|||
|
8-bit and 24-bit images means that you can't scan or display a
|
|||
|
10/30-bit image.
|
|||
|
* 4c (seems to be the same scanner as the 3c)
|
|||
|
* HP ScanJet Plus
|
|||
|
* HP ScanJet 4P (reported by a user, Tummy.com doesn't list it)
|
|||
|
Not Supported
|
|||
|
* Centronics-type interface ScanJets (mostly early models)
|
|||
|
* ScanJet 4s (4bpp greyscale single-page scanner)
|
|||
|
* ScanJet 4Si (high-volume network interface scanner)
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Application Interfaces
|
|||
|
SANE v0.42 - http://www.azstarnet.com/~axplinux/sane/ - is a
|
|||
|
project to create a Universal Scanner Interface. SANE, which stands
|
|||
|
for Scanner Access Now Easy, supports the following backends (device
|
|||
|
drivers):
|
|||
|
Supported Devices
|
|||
|
* Mustek flatbed scanners using a generic SCSI interface
|
|||
|
* PBM-Pseudo-Driver (demo implementation)
|
|||
|
* DL-Meta-Backend for multiple-scanner support
|
|||
|
* A Network based backend to support scanners across a network
|
|||
|
* Connectix Color QuickCam
|
|||
|
Work in Progress or Planned
|
|||
|
* UMAX scanners
|
|||
|
* Linux Handscanner ioctl interface bridge
|
|||
|
* HP scanner support (might be a port from xvscan)
|
|||
|
* MicroTek (aka mTek) scanners
|
|||
|
|
|||
|
There are a couple of front ends to this tool as well:
|
|||
|
* xcam - a front end to the Color QuickCam driver
|
|||
|
* a Gimp plug-in front end, which can also be compiled as a
|
|||
|
standalone GTK application (GTK is the X Toolkit used by the
|
|||
|
upcoming version of the Gimp)
|
|||
|
* a command line interface
|
|||
|
|
|||
|
|
|||
|
|
|||
|
This package makes use of the GNU Configure mechanism. Unfortunately
|
|||
|
it doesn't quite build right out of the box (there are some linking
|
|||
|
options which aren't supported by the Linux ld program). I couldn't
|
|||
|
test the programs or drivers out, unfortunately since I don't have a
|
|||
|
QuickCam or any scanners yet. Feel free to donate either, of course.
|
|||
|
|
|||
|
There are notes in the distribution about ongoing work for support for
|
|||
|
non-Unix platforms, but I have little interest in that so didn't
|
|||
|
really read through it.
|
|||
|
|
|||
|
What people are saying
|
|||
|
And of course, what would a scanner review be without some user
|
|||
|
testimonials. These are taken from the discussions on scanners in the
|
|||
|
Gimp User and Gimp Developer mailing lists. I didn't keep track of
|
|||
|
email addresses so all I have are the first names of the respondents.
|
|||
|
As with any unverifiable testimonials, take these with a grain of
|
|||
|
salt.
|
|||
|
|
|||
|
I've been using XVScan with my ScanJet 4P and Linux for about
|
|||
|
9 months, and I'm very happy with it. It worked perfectly out of the
|
|||
|
box, no tweaking or anything. XVScan costs $50, but that includes
|
|||
|
the $30 registration fee for XV and is produced by Tummy.com. Their
|
|||
|
web site is, of course, http://www.tummy.com/. - Scott
|
|||
|
|
|||
|
I'm using an Epson GT-5000WINS (JP model?) with a hand-made
|
|||
|
GIMP 0.54 plug-in driver. The driver is not for general use yet, but
|
|||
|
is available on-web. - Kaz Sasayama <A
|
|||
|
HREF="http://www.spice.or.jp/~hypercor/hyperplay/">http://www.spice.
|
|||
|
or.jp/~hypercor/hyperplay/
|
|||
|
|
|||
|
>
|
|||
|
|
|||
|
I'm using an HP Scanjet IIC (predecessor to the CX) with Linux
|
|||
|
and Gimp, and am very pleased with the results. I've a feeling
|
|||
|
(unsubstantiated), that not much changed between the two models
|
|||
|
other than the driver software that HP shipped with each. There's a
|
|||
|
good HP scanner driver for Linux called 'hpscanpbm' - available from
|
|||
|
the usual sources. It's command-line driven, but offers very good
|
|||
|
control over resolution, brightness, contrast etc. Output format is
|
|||
|
pbm only, unfortunately. So far, it's the only HP driver for Linux
|
|||
|
that I've seen. - Andre
|
|||
|
|
|||
|
I'm using a Mustek Paragon 600II-SP, and it works quite well
|
|||
|
(just don't expect to share the SCSI bus with anything else). It's
|
|||
|
sold here (in Austria) at around $300US - Andreas
|
|||
|
|
|||
|
I'm using a HP Scanjet IIcx, with the Adaptec AHA152x driver
|
|||
|
and the "generic" SCSI interface. No changes to the driver were
|
|||
|
necessary. Currently using the hpscanpbm program to do all scanning.
|
|||
|
- Rob Jenkins
|
|||
|
|
|||
|
I'm using an HP IICX with hpscanpbm. Installation was
|
|||
|
completely painless. I added it to my scsi bus, rebooted and once I
|
|||
|
figured out which generic scsi device it was and set the permissions
|
|||
|
appropriately it worked. Probably 10-15 minutes, including compiling
|
|||
|
hpscanpbm. - Stew
|
|||
|
|
|||
|
I have a Microtek ScanMaker E3, which is a 24-bit flatbed
|
|||
|
scanner with a 300x600dpi optical resolution, that can be had for
|
|||
|
right around $300. It comes with some pretty decent image editing
|
|||
|
software for the Mac and for Windows, and there's a
|
|||
|
(command-line-driven) driver available for Linux (mtekscan). With
|
|||
|
any luck, the SANE (Scanner Access Now Easy) project will have a
|
|||
|
driver available in the not-too-distant future (if I ever find time
|
|||
|
to write the driver, that is. :) The SANE driver will allow
|
|||
|
standalone scanning as well as a GIMP plug-in. The driver will
|
|||
|
probably work with other Microtek scanners as well (mtekscan was
|
|||
|
actually written for a ScanMaker E6 but works with my E3). - name
|
|||
|
unknown
|
|||
|
|
|||
|
As for Musteks, I was considering a 30-bit, 400x800dpi Mustek
|
|||
|
scanner (I don't remember the model), until I read a review which
|
|||
|
compared that scanner to a few other scanners (mostly 24-bit). The
|
|||
|
Mustek wasn't particularly impressive; I finally decided to go with
|
|||
|
the Microtek--even though inferior "on paper" it still received a
|
|||
|
much better review. In any case, you can't go wrong with a
|
|||
|
Microtek, I think. I've also read good things about the UMAX (which
|
|||
|
are also rather inexpensive), a Canon (a little more expensive), and
|
|||
|
of course HP scanners are generally top-notch, although they also
|
|||
|
command premium prices. If you have the bucks, go for an HP, but if
|
|||
|
you want to save a few dollars and still get an excellent quality
|
|||
|
product, there are other options. - name unknown
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Other OS's
|
|||
|
A few people responded to my request for information on the Gimp
|
|||
|
mailing lists with information for non-Linux systems. I normally don't
|
|||
|
write about these, but I'll go ahead this one time. Note that I don't
|
|||
|
want to write about other OS's - not because they aren't any good, but
|
|||
|
because Linux works for me and I don't have the time to wander around
|
|||
|
the OS world looking for yet another OS.
|
|||
|
* FreeBSD - apparenatly has a port called hpscan that needs a link
|
|||
|
to /dev/scanner from the device the scanner uses. hpscan saves
|
|||
|
images in JPEG format.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Thats it. Hopefully this information will help you get started
|
|||
|
looking for a scanner and the appropriate software to use with it. I
|
|||
|
have high expectations for the SANE project to be the primary
|
|||
|
interface for low-level and user-level drivers for all scanners in the
|
|||
|
future. Once a generic interface is defined it should be easier to
|
|||
|
develop applications that can make real use of the scanners.
|
|||
|
|
|||
|
indent © 1996 by Michael J. Hammel
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
More...
|
|||
|
|
|||
|
|
|||
|
Musings
|
|||
|
|
|||
|
BMRT
|
|||
|
Part I: Getting Started - Creating, Previewing, and Final Rendering
|
|||
|
of Simple Images
|
|||
|
Introduction
|
|||
|
User Tools - Renderers and Previewers
|
|||
|
Developer Tools - libraries, compiler, etc
|
|||
|
The Example Scenes
|
|||
|
The Input File - RIB format
|
|||
|
Basic Steps
|
|||
|
Shaders
|
|||
|
Closing
|
|||
|
|
|||
|
indent
|
|||
|
© 1996 Michael J. Hammel indent
|
|||
|
|
|||
|
|
|||
|
|
|||
|
1. Introduction
|
|||
|
|
|||
|
A couple of years ago, right after Toy Story had been released,
|
|||
|
I began to gather as much information on computer graphics as I could
|
|||
|
find. At first I had been looking for general information. Later, when
|
|||
|
I found out such tools existed for Windows and Mac systems, I began to
|
|||
|
look around for various 3D rendering and modelling tools that would
|
|||
|
run on Unix systems. The first tool I found was POV-Ray, a tool that
|
|||
|
has been ported to many platforms including a number of Unix OS's. I
|
|||
|
also found a number of other tools such as Polyray and Radiance. Since
|
|||
|
I was very new to 3D tools I started with POV-Ray. It had a large
|
|||
|
amount of online information (much of which has been scaled back on
|
|||
|
the Internet), a large user base that frequented the
|
|||
|
comp.graphics.rendering.raytracing newsgroup, and it had printed texts
|
|||
|
available. This last item was the most important element to me. I
|
|||
|
needed documentation I didn't have to print off myself and that was
|
|||
|
fairly well organized. I tended to carry it around to read at lunch on
|
|||
|
work days.
|
|||
|
|
|||
|
[IMAGE]
|
|||
|
Figure 1: A sample scene created using BMRT. The text was produced
|
|||
|
using the font3d tool, which can output RIB files.
|
|||
|
Not long after discovering POV-Ray I came across another tool
|
|||
|
called BMRT. BMRT is actually a set of tools that are compliant with
|
|||
|
the RenderMan Interface Specification. This specification is the same
|
|||
|
one used by PRMan, the tool used by Pixar to create Toy Story.
|
|||
|
Although I wanted to learn more about BMRT I really didn't have the
|
|||
|
background to understand how to use such tools. POV-Ray's
|
|||
|
documentation allowed me to learn some basics up front. After about a
|
|||
|
year of working on POV-Ray, along with continued research in other
|
|||
|
areas of computer graphics, I began to look once again at BMRT. I now
|
|||
|
better understand what it does. Its time to learn to use it. In
|
|||
|
this first of three articles on BMRT I'll be describing the package
|
|||
|
contents and introduce you to the basics of how to use the BMRT tools.
|
|||
|
You should keep in mind that much of the terminology might be new to
|
|||
|
you and so the early introductions and descriptions might not make too
|
|||
|
much sense. I apologize for this, but describing such a powerful
|
|||
|
package as BMRT and the RenderMan Specification in one introductory
|
|||
|
article is not easy. Fear not, however. I'll be explaining all of the
|
|||
|
package contents in some detail further along in this article. This
|
|||
|
won't be a complete, all encompassing tutorial. But it should be
|
|||
|
enough to get you started. After you get done here, go order the
|
|||
|
RenderMan Specification from Pixar. It is a very well written and
|
|||
|
easy to follow description of what BMRT implements. It also provides
|
|||
|
the reference guide necessary to understand the C and RIB bindings to
|
|||
|
the RenderMan interface.
|
|||
|
|
|||
|
WHAT IS BMRT?
|
|||
|
|
|||
|
BMRT stands for the Blue Moon Rendering Tools. It is a set of
|
|||
|
tools and libraries created by Larry Gritz, who now works at Pixar,
|
|||
|
that allow the previewing and rendering of 3D models and scenes. The
|
|||
|
rendering engines (programs) and static libraries (used to create
|
|||
|
applications that can output RIB files) are all compatible with the
|
|||
|
RenderMan Interface Standard developed by Pixar. RenderMan is not an
|
|||
|
actual piece of software, although many people use the terms RenderMan
|
|||
|
and PRMam (Pixar's software implementation of the RenderMan
|
|||
|
specification) interchangeably. It is a specification stating how a
|
|||
|
modeling system communicates with a rendering system. BMRT is an
|
|||
|
implementation of the rendering system with a static library provided
|
|||
|
for use with modeling systems, including stand-alone programs.
|
|||
|
BMRT's rendering tools support ray tracing, radiosity, area
|
|||
|
light sources, texture and environment mapping, programmable shading
|
|||
|
in the RenderMan Shading Language, motion blur, automatic ray cast
|
|||
|
shadows, CSG (Constructive Solid Geometry), depth of field, support of
|
|||
|
imager and volume shaders, and other advanced features. The toolkit
|
|||
|
also contains quick RIB previewers (using OpenGL and X11) to allow
|
|||
|
"pencil tests" of scenes and animations.
|
|||
|
|
|||
|
CURRENT RELEASE AND WHERE TO GET IT
|
|||
|
|
|||
|
At the time of this writing, February 22, 1997, the latest
|
|||
|
release of BMRT is 2.3.5. It is available from the BMRT Web site
|
|||
|
(http://www.seas.gwu.edu/student/gritz/bmrt.html). This site also
|
|||
|
contains example images and pointers to other RenderMan related sites
|
|||
|
on the Web. Larry only provides precompiled versions of the renderers
|
|||
|
and the RIB and shader libraries. He does, however, provide a set of
|
|||
|
shaders in source form along with their compiled versions. We'll
|
|||
|
discuss shaders a little later. Versions of BMRT are available for
|
|||
|
* SGI running IRIX 5.2 and up (mips1, mips2, and mips4 available)
|
|||
|
* Linux (i386/486/Pentium)
|
|||
|
* FreeBSD (i386/486/Pentium)
|
|||
|
* HP 9000 8xx/7xx running HP-UX
|
|||
|
* NEXTSTEP (HP, Motorola, Intel, and SPARC processors)
|
|||
|
* Sun SPARC (running Solaris)
|
|||
|
|
|||
|
Larry doesn't expect to port BMRT to non-Unix style operating systems
|
|||
|
due to the logistics problems (access to machines, and so forth)
|
|||
|
inherint with cross-platform development. There is no planned port for
|
|||
|
the MkLinux distribution at this time. I don't know if he plans on
|
|||
|
working on a Digital Alpha or any other non-Intel Linux ports.
|
|||
|
|
|||
|
WHAT THE PACKAGE CONTAINS
|
|||
|
|
|||
|
The distribution comes complete with what might be considered
|
|||
|
as a set of user tools, a set of development tools, and documentation
|
|||
|
for both. Its not quite correct to refer to these as user or
|
|||
|
development tools due to the nature of the tools, but for this article
|
|||
|
such classification will help organize things a little better.
|
|||
|
|
|||
|
User Tools - Renderers and Previewers
|
|||
|
|
|||
|
These are the executable programs in the package that allow
|
|||
|
users to render and preview images. There are 3 such programs:
|
|||
|
* rendribv - a wireframe previewer
|
|||
|
* rgl - a polygon previewer that uses OpenGL
|
|||
|
* rendrib - the RenderMan compliant renderer
|
|||
|
|
|||
|
Its easiest to remember these tools as the ones you'll need to render
|
|||
|
draft or final versions of your scenes. The first two are generally
|
|||
|
used to render draft versions, the last to render your final scene.
|
|||
|
However, you don't create the scene files with these tools. Scene
|
|||
|
files contain the description of the objects that make up the scene.
|
|||
|
These files use a format called RIB, the RenderMan Interface
|
|||
|
Bytestream format. Scene files can be created by hand (not a common
|
|||
|
practice), by writing a C program that uses the developer tools
|
|||
|
described in the next section, or by modellers that can output files
|
|||
|
in the RIB format.
|
|||
|
RIB files describe the shape and positions of objects. They
|
|||
|
provide the geometry of a scene. They do not describe colors of
|
|||
|
objects, the texture on the surface of objects, nor any aspect of
|
|||
|
lighting in the scene. This information is referenced by the RIB by
|
|||
|
using shaders. Shaders are external files that describe the appearance
|
|||
|
of the objects in a scene. There are developer tools for creating and
|
|||
|
examining shader files.
|
|||
|
|
|||
|
Developer Tools - libraries, compiler, etc
|
|||
|
|
|||
|
The developer tools in BMRT are actually a set of libraries and
|
|||
|
header files that are provided for users to create C programs that
|
|||
|
output RIB files or to parse shader source files. The user programs
|
|||
|
can be specifically designed for a given scene or set of frames or
|
|||
|
could be part of a more generalized modelling system, such as AC3D or
|
|||
|
SCED. Also included in the developer tools are programs for compiling
|
|||
|
shader source files into their .so format and for examining compiled
|
|||
|
shader files to find their types, parameters, and initial values.
|
|||
|
Shader source files look like ordinary C code. The source file
|
|||
|
is compiled into another format referred to as the .so file. The
|
|||
|
compiled .so versions are actually ASCII files. The .so extension
|
|||
|
might be a little confusing to users who are familiar with creating
|
|||
|
shared libraries, but these are not shared object files. They are
|
|||
|
plain text files.
|
|||
|
The libraries and header files provided are:
|
|||
|
* libribout.a, ri.h - used for producing RIB files
|
|||
|
* libsoargs.a, so.h - used to parse compiled shaders
|
|||
|
|
|||
|
The programs used for compiling and examing shader files are:
|
|||
|
* slc - shader compiler
|
|||
|
* sotell - command line program for parsing compiled shaders
|
|||
|
|
|||
|
Note that the distribution does not come with linkable libraries for
|
|||
|
the renderers.
|
|||
|
|
|||
|
Docs
|
|||
|
|
|||
|
There are only two pieces of documentation that come with the
|
|||
|
distribution, however both are quite well written and very good
|
|||
|
refernces.
|
|||
|
* bmrt.html
|
|||
|
* poets.ps
|
|||
|
|
|||
|
The first is a detailed description of all the tools and how to use
|
|||
|
them. This is a very valuable reference for new users learning how to
|
|||
|
get the most out of the programs by learning their command line
|
|||
|
arguments. The second is a quick introduction to the RenderMan API. It
|
|||
|
contains a brief description of the RIB format. For more detailed
|
|||
|
information on the RIB format you should contact Pixar to get the
|
|||
|
official RenderMan Interface 3.1 Specification. Although the
|
|||
|
specification document is not written as a tutorial, it does contain
|
|||
|
detailed, reference-style information on the RIB file format. For more
|
|||
|
information on contacting Pixar, see the comp.graphics.renderman FAQ
|
|||
|
at
|
|||
|
http://www.cis.ohio-state.edu/hypertext/faq/usenet/graphics/renderma
|
|||
|
n-faq/faq.html
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
2. User Tools - Renderers and Previewers
|
|||
|
|
|||
|
|
|||
|
|
|||
|
RENDRIBV - WIREFRAME PREVIEWER
|
|||
|
|
|||
|
The first of the renderers, rendribv, provides wireframe
|
|||
|
previews of the input scene files. The previews show geometric
|
|||
|
primitives without shading or removal of hidden lines. A wireframe
|
|||
|
display uses "wire cages" to represent objects instead of representing
|
|||
|
them as solid surfaced objects. The wireframe display requires the use
|
|||
|
of the X11 windowing system. Rendribv has a number of command line
|
|||
|
options, all of which are explained in the accompanying documentation.
|
|||
|
One important aspect to keep in mind is that rendribv was designed to
|
|||
|
display one or more frames of a RIB file. It offers a good way to
|
|||
|
preview an animation without the overhead that accompanies the shading
|
|||
|
of object surfaces. The limbo.rib example scene provides a sample
|
|||
|
animation. On my 486DX2/66 with 40M memory the wireframe animation is
|
|||
|
fairly smooth using rendribv. Its even faster on my P75 laptop with 8M
|
|||
|
of memory.
|
|||
|
|
|||
|
RGL - QUICK POLYGON PREVIEWER THAT USES OPENGL
|
|||
|
|
|||
|
Another previewer provided in the distribution is the rgl
|
|||
|
program. This renderer displays previews of scenes with simple Gouraud
|
|||
|
shading of object surfaces using OpenGL (OpenGL is a specification for
|
|||
|
a graphics interface from Silicon Graphics - see this months review of
|
|||
|
Mark Kilgards OpenGl Programming with the X Window System). Gouraud
|
|||
|
shading is a method for helping to eliminate large changes in color
|
|||
|
intensities that can cause banding. Hidden lines, those lines and
|
|||
|
surfaces that should not be visible to the viewer because they are
|
|||
|
blocked by other lines or surfaces, are also removed. Since rgl
|
|||
|
requires OpenGL, a port of an OpenGL library must be available on a
|
|||
|
particular platform in order for Larry to port rgl to that platform.
|
|||
|
Fortunately, the MesaGL library is available for Linux, as well as
|
|||
|
some commercial ports of the official OpenGL libraries, so there is a
|
|||
|
working version of rgl available for Linux. rgl is statically linked
|
|||
|
so you don't need any of the OpenGL or MesaGL libraries to use it.
|
|||
|
Other Unix distributions of BMRT may not have this program, however.
|
|||
|
|
|||
|
RENDRIB - HIQH QUALITY RENDERER W/RAYTRACING AND RADIOSITY
|
|||
|
|
|||
|
This is the gravy on the potatoes. The rendrib program is a
|
|||
|
fully featured, RenderMan compliant renderer that provides not only
|
|||
|
the full feature set of the RenderMan Specification but also provides
|
|||
|
such things as ray tracing, radiosity, solid modeling, depth of field,
|
|||
|
motion blur, area light sources, texture mapping, environment mapping,
|
|||
|
volume and imager shading, and support of the RenderMan Shading
|
|||
|
Language. The latest version also supports displacement mapping, a
|
|||
|
method of mapping an image to a surface that not only changes the
|
|||
|
appearance of the surface but also the actual shape of that surface.
|
|||
|
Rendrib is the tool to use when rendering your final scene as it
|
|||
|
will produce the best, most realistic results of all the renderers
|
|||
|
provided.
|
|||
|
|
|||
|
A WORD ABOUT COMPATIBILITY WITH COMMERCIAL LINUX DISTRIBUTIONS
|
|||
|
|
|||
|
Version 2.3.4 of the BMRT rendering tools were built against
|
|||
|
version 26 of the g++ library. Version 2.3.5 is linked against version
|
|||
|
27. This is no problem if you're running one of the newer commercial
|
|||
|
Linux distributions since I believe 27 has been out for awhile and
|
|||
|
should be in most recent Linux distrubtions. However, my laptop has an
|
|||
|
older Slackware 3.0 release which only has g++ v26. which means I
|
|||
|
can't run the v2.3.5 renderers on my laptop. This isn't a big deal for
|
|||
|
me, but it is something you should be aware of when deciding to
|
|||
|
explore BMRT. I don't know if Larry supplies older versions of BMRT so
|
|||
|
you may have to upgrade in order to use the latest distribution of
|
|||
|
BMRT.
|
|||
|
Note that the X and MesaGL/OpenGL libraries were statically
|
|||
|
linked to the renderers. However, the C/C++ libraries are still
|
|||
|
dynamically linked, which is why you need to be aware of which
|
|||
|
versions of these libraries are required.
|
|||
|
|
|||
|
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
3. Developer Tools - libraries, compiler, etc
|
|||
|
|
|||
|
|
|||
|
|
|||
|
SLC - SHADER LANGAUGE COMPILER
|
|||
|
|
|||
|
The shader language compiler is a program which takes shader
|
|||
|
language source files, those files ending in .sl, and compiles them
|
|||
|
into their compiled versions, those files ending in .so. The compiled
|
|||
|
shader files appear to be code to a state machine used in the rendrib
|
|||
|
renderer that determines how shading is applied to a given object (I
|
|||
|
don't know that for certain, but it seems a reasonable guess).
|
|||
|
RenderMan is a procedural interface. The shaders are procedures
|
|||
|
written in a C like language. The must be compiled to be used with a
|
|||
|
RenderMan compliant renderer like BMRT. The shader compiler turns the
|
|||
|
procedural shader into a format the renderer can handle.
|
|||
|
Shaders come in many forms: surface shaders which define how
|
|||
|
light leaving a point on an object will appear, volume shaders which
|
|||
|
define how light is affected as it passes through an object (such as
|
|||
|
the atmosphere), light shaders which describe the lighting of a scene,
|
|||
|
displacement shaders, transformation shaders, imager shaders, and so
|
|||
|
forth. rendrib supports all of these shader types.
|
|||
|
The BMRT package comes with a fairly large number of shaders,
|
|||
|
some of which are required by the RenderMan specification and some of
|
|||
|
which Larry has provided as bonus shaders in conjunction with example
|
|||
|
scenes.
|
|||
|
|
|||
|
RenderMan required shaders Extra shaders provided for use with example
|
|||
|
scenes constant, matte metal, shinymetal plastic, paintedplastic
|
|||
|
ambientlight, distantlight pointlight, spotlight depthcue, fog bumpy,
|
|||
|
null background, clamptoalpha, dented, funkyglass, glass,
|
|||
|
gmarbltile_polish, noisysmoke, parquet_plank, plank, screen,
|
|||
|
screen_aa, shiny, stucco, wallpaper_2stripe, wood2,
|
|||
|
arealight - shader for area light sources Both compiled versions and
|
|||
|
source code are provided for all of these shaders.
|
|||
|
|
|||
|
Note that the .so files provided are the precompiled versions of the
|
|||
|
.sl files and that the .so files are not compatible with PRMan,
|
|||
|
Pixar's RenderMan program. The .sl source files are compatible,
|
|||
|
however. The reason for this comes from the methods used internally to
|
|||
|
rendrib and PRMan to produce the 3D images. For more information see
|
|||
|
the section on Incompatibilities with PRMan in the bmrt.html document
|
|||
|
in the doc directory of the distribution.
|
|||
|
|
|||
|
SOTELL - LISTS THE ARGUMENTS TO A COMPILED SHADER
|
|||
|
|
|||
|
Another shader related tool is sotell. This program allows the user
|
|||
|
to parse a shader object file for its type, list of parameters, and
|
|||
|
default settings. What this is useful for will become more apparent in
|
|||
|
the next article which will cover the writing of shaders. We'll touch
|
|||
|
briefly on using predefined shaders a little later in this article.
|
|||
|
|
|||
|
LIBRIBOUT.A, RI.H - RENDERMAN LIBRARY FOR PRODUCING RIB FILES
|
|||
|
|
|||
|
These two files are used by developers who need to write applications
|
|||
|
to output their RIB files. Remember, RIB files are the input files
|
|||
|
(including references to shaders) passed to the rendrib program. There
|
|||
|
are two modellers on Linux that can output RIB files for you, SCED and
|
|||
|
AC3D, but you may find it convenient to write your own specialized
|
|||
|
application to output a series of specific frames. In this case (or if
|
|||
|
you are ambitious enough to write your own modeller) you can link your
|
|||
|
program to the libribout.a library. Your application would use then be
|
|||
|
using the C binding to the RenderMan API. This API is described in
|
|||
|
limited detail in the poets.ps document in the distribution. A much
|
|||
|
better description can be found in Steve Upstill's The RenderMan
|
|||
|
Companion, published by Addison-Wesley. Developer's who write
|
|||
|
applications that use the RenderMan API will also need to include the
|
|||
|
ri.h header file in their source code.
|
|||
|
|
|||
|
LIBSOARGS.A, SO.H - ARGUMENT PARSER FOR COMPILED SHADERS
|
|||
|
|
|||
|
According to Larry's documenation (which is all I have to go by -
|
|||
|
I've never seen the PRMan application myself), Pixar's PRMan
|
|||
|
distribution also comes with a linkable library for parsing compiled
|
|||
|
shaders, much like the sotell program does in the BMRT distribution.
|
|||
|
Since the compiled versions of the shaders differ in format Larry has
|
|||
|
provided a similar library for use by applications that need to parse
|
|||
|
his version of the compiled shader files. Applications which need this
|
|||
|
feature should include the so.h header file in their source code and
|
|||
|
link against the libsoargs.a library.
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
4. The Example Scenes
|
|||
|
|
|||
|
There are 8 example scenes in the distribution. These are described in
|
|||
|
the README file in the examples directory, but for completeness sake
|
|||
|
I'll list and describe them briefly here. The 8 RIB files are:
|
|||
|
* cornbox.rib - a simple radiosity test scene
|
|||
|
* disptest.rib - an example of the use of complex procedural
|
|||
|
textures
|
|||
|
* dresser.rib - raytracing combined with radiosity, showing light
|
|||
|
rays bouncing off of mirrors
|
|||
|
* limbo.rib - very cool animation of Luxo Learning to Limbo
|
|||
|
* shadtest.rib - shows shadows using lighting instead of shadow maps
|
|||
|
* smokebox.rib - example of atmospheric effects using volume shaders
|
|||
|
* teapots.rib - familiar teapot example using raytracing to show
|
|||
|
reflections and refractions.
|
|||
|
* tpdisp.rib - more complex procedural textures
|
|||
|
|
|||
|
Some of these are good examples for learning the syntax and structure
|
|||
|
of a RIB file, others are not. If you want to learn a little about the
|
|||
|
RIB ASCII binding you should start by taking a look at the following
|
|||
|
examples:
|
|||
|
* cornbox.rib - probably the most commented of the examples.
|
|||
|
* disptest.rib - short header comment and the file is well formatted
|
|||
|
making it fairly easy to follow. Also a fairly short example so
|
|||
|
its easy to look up and learn the commands if you use the
|
|||
|
RenderMan Specification as a reference.
|
|||
|
* shadtest.rib - good header comment, formatted; no other comments
|
|||
|
|
|||
|
The rest of the RIB examples are not well formatted (probably output
|
|||
|
from a modeller or a program linked with libribout.a). You really
|
|||
|
wouldn't want to examine the RIB file in these cases anyway, as their
|
|||
|
main purpose is to show features of the Shading Language. In these
|
|||
|
cases you should take a look at the shaders which they use. You'll
|
|||
|
have to look in the RIB to learn which shaders are important for a
|
|||
|
given example, however. For example, the tpdisp.rib file is an example
|
|||
|
of displacement shaders so you would look for the Displacement
|
|||
|
commands in the RIB file to find which displacement shader source
|
|||
|
files to examine.
|
|||
|
In order to explain how to use these tools in more detail I'll
|
|||
|
be using two examples in each of the rest of the sections of this
|
|||
|
article. In some cases I'll use examples I found in the RenderMan
|
|||
|
Companion. In other cases I'll use some of Larry's examples or some
|
|||
|
of my own extremely primitive examples. They aren't very good - but
|
|||
|
this article was is as much a learning experience for me as it is
|
|||
|
anyone else.
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
5. The Input File - RIB Format
|
|||
|
|
|||
|
|
|||
|
|
|||
|
WHAT IS IT?
|
|||
|
|
|||
|
RIB stands for the RenderMan Interface Bytestream. It comes in both
|
|||
|
ASCII and binary encodings. We'll only be discussing the ASCII version
|
|||
|
since I have very little information about the binary encodings and
|
|||
|
BMRT doesn't come with any binary examples. All the example RIB files
|
|||
|
are ASCII formatted.
|
|||
|
A RIB file is nothing more than an ASCII text file made up of a
|
|||
|
series of RIB commands. These commands match their RenderMan API C
|
|||
|
function counterparts almost exactly (there a few exceptions according
|
|||
|
to the official specification). When you write a C program that makes
|
|||
|
calls to the RenderMan API via the libribout.a library what you get as
|
|||
|
output is the ASCII encoding of RIB. This is why its generally easier
|
|||
|
to use the C binding for RenderMan than to write your own ASCII RIB
|
|||
|
file.
|
|||
|
|
|||
|
A LITTLE ABOUT THE FORMAT
|
|||
|
|
|||
|
The semantics of the two bindings (C and ASCII RIB) are very similar.
|
|||
|
Both take token/value pairs as arguments. The C binding requires that
|
|||
|
paremeter lists to functions be NULL terminated. The ASCII RIB format
|
|||
|
does not. The names of the C procedures are prefixed with Ri but the
|
|||
|
equivalent RIB commands are not.
|
|||
|
RIB files Support single or multiple frames of an image,
|
|||
|
allowing (as in the limbo.rib example) animations with a single scene
|
|||
|
description. This is a good case for using the procedural interface to
|
|||
|
RenderMan instead of hand coding the RIB file. Its much easier to
|
|||
|
compute the scene descriptions through a programmed loop than to hand
|
|||
|
compute each frame using the ASCII RIB commands.
|
|||
|
|
|||
|
HOW CAN YOU CREATE RIB FILES?
|
|||
|
|
|||
|
There are three ways to create a RIB file for use as input to one of
|
|||
|
BMRT's renderers:
|
|||
|
1. By hand
|
|||
|
2. Write a C program using the RenderMan API and link with
|
|||
|
libribout.a
|
|||
|
3. Using a modeller
|
|||
|
There are three modellers currently available for Linux that can
|
|||
|
output RIB formatted files:
|
|||
|
+ SCED - a constraint based modeller, with a quite useful CSG
|
|||
|
(constructive solid geometry) feature, that uses an Athena
|
|||
|
Widget interface
|
|||
|
+ AC3D - a polygon based modeller with an easy to use 3D
|
|||
|
(Motif-looking) interface
|
|||
|
+ AMAPI - an OpenGL based modeller
|
|||
|
|
|||
|
My impression is that few people create RIB files by hand except as
|
|||
|
examples in order to test shaders or something similar. The use of
|
|||
|
modellers on Linux is fairly new to the general public, so at this
|
|||
|
point I'm guessing many models are created by writing scene-specific
|
|||
|
programs linked with the libribout.a library. Note that developmental
|
|||
|
support for AC3D is ongoing, while AMAPI is reported to have dropped
|
|||
|
their Linux ports. SCED's status is unknown at this time. I've not
|
|||
|
seen any updates to it for about a year.
|
|||
|
Lets take a look at a couple of examples. The first is a simple
|
|||
|
RIB file from Larry's set of examples. The second is a simple
|
|||
|
animation in C source taken from the RenderMan Companion.
|
|||
|
|
|||
|
WORKING EXAMPLE 1A - A SAMPLE RIB FILE
|
|||
|
|
|||
|
The simplest example from the BMRT distribution to follow is probably
|
|||
|
shadtest.rib. It contains 3 textured objects (two spheres and a flat
|
|||
|
plane beneath them) along with a light source. The source is given in
|
|||
|
Listing 1.
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
##RenderMan RIB-Structure 1.0
|
|||
|
version 3.03
|
|||
|
Display "balls1.tif" "file" "rgba"
|
|||
|
Format 480 360 -1
|
|||
|
PixelSamples 1 1
|
|||
|
Projection "perspective" "fov" 45
|
|||
|
Translate 0 -2 8
|
|||
|
Rotate -110 1 0 0
|
|||
|
|
|||
|
WorldBegin
|
|||
|
|
|||
|
LightSource "ambientlight" 1 "intensity" 0.08
|
|||
|
|
|||
|
Declare "shadows" "string"
|
|||
|
Attribute "light" "shadows" "on"
|
|||
|
LightSource "distantlight" 1 "from" [0 1 4] "to" [0 0 0] "intensity" 0.8
|
|||
|
|
|||
|
AttributeBegin
|
|||
|
# Attribute "render" "casts_shadows" "none"
|
|||
|
Color [ 0.7 0.7 0.7 ]
|
|||
|
Surface "matte"
|
|||
|
Polygon "P" [ -5 -5 0 5 -5 0 5 5 0 -5 5 0 ]
|
|||
|
AttributeEnd
|
|||
|
|
|||
|
AttributeBegin
|
|||
|
Translate -2.25 0 2
|
|||
|
Color [1 .45 .06]
|
|||
|
Surface "screen" "Kd" 0.2 "Ks" 0.8 "roughness" 0.15 "specularcolor" [1 .5 .1]
|
|||
|
Sphere 1 -1 1 360
|
|||
|
AttributeEnd
|
|||
|
|
|||
|
AttributeBegin
|
|||
|
Translate 0 0 2
|
|||
|
Declare "casts_shadows" "string"
|
|||
|
Attribute "render" "casts_shadows" "shade"
|
|||
|
Color [1 .45 .06]
|
|||
|
Surface "screen_aa" "Kd" 0.2 "Ks" 0.8 "roughness" 0.15 "specularcolor" [1 .5
|
|||
|
.1]
|
|||
|
Sphere 1 -1 1 360
|
|||
|
AttributeEnd
|
|||
|
|
|||
|
AttributeBegin
|
|||
|
Translate 2.25 0 2
|
|||
|
Declare "casts_shadows" "string"
|
|||
|
Attribute "render" "casts_shadows" "shade"
|
|||
|
Surface "funkyglass" "roughness" 0.06
|
|||
|
Sphere 1 -1 1 360
|
|||
|
AttributeEnd
|
|||
|
|
|||
|
WorldEnd
|
|||
|
|
|||
|
Listing 1: shadtest.rib example from BMRT distribution
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
Items of interest in this file include:
|
|||
|
1. The values set before the WorldBegin command are used to set
|
|||
|
camera and display parameters. These global parameters are known
|
|||
|
as options. The display options can be specific to the renderer
|
|||
|
being used. Rendering options cannot be set inside the
|
|||
|
WorldBegin/WorldEnd commands.
|
|||
|
2. Values set inside the Attribute commands are referred to as
|
|||
|
current parameters and are object specific parameters such as
|
|||
|
lighting, opacity and surface colors and textures.
|
|||
|
3. Objects (including lights) created inside the WorldBegin/WorldEnd
|
|||
|
commands exist only inside those commands. They are not
|
|||
|
referencable outside of these commands.
|
|||
|
4. Notice how the RIB commands contain series of literal strings and
|
|||
|
numeric values. For example, the surface command is followed by
|
|||
|
the name of the surface (a string) followed by a series of
|
|||
|
token/value pairs. These tokens are variables known to the shader
|
|||
|
being called and the values are the ones we wish to set these
|
|||
|
variables to when the shader is invoked.
|
|||
|
5. The # sign is a comment, but the double # (ie ##) is a hint to the
|
|||
|
specific renderer. For all practical purposes, these are also
|
|||
|
comments, since no renderers use them for anything. I believe the
|
|||
|
format of the hint tag has changed for the 2.3.5 version of the
|
|||
|
BMRT renderers but I don't know what has replaced it.
|
|||
|
6. The commands to create the spheres are obvious. The command to
|
|||
|
create the plane is "polygon". The RenderMan API and BMRT provide
|
|||
|
support for a number of primitive shapes. BMRT also supports the
|
|||
|
ability to combine primitive shapes into more complex ones using
|
|||
|
what is known as Constructive Solid Geometry.
|
|||
|
7. The WorldEnd() command causes the scene to be output to the
|
|||
|
display.
|
|||
|
8. RIB commands may span multiple lines, although it doesn't show
|
|||
|
this in the example.
|
|||
|
|
|||
|
I removed the comment at the start of the file just to save a little
|
|||
|
space. You should read it and try rendering this example to get a feel
|
|||
|
for what it does. All I really wanted to do with this example is show
|
|||
|
you what an ASCII RIB file looks like. The format of the file gives a
|
|||
|
little clue as to the hierarchy of the commands: WorldBegin/End
|
|||
|
encompass the Attribute commands, which in turn encompass some objects
|
|||
|
and their textures and other descriptions. Understanding this
|
|||
|
hierarchy can help you see the scope of definitions such as objects or
|
|||
|
projections. This hierarchy can be more apparent when using the
|
|||
|
RenderMan API since the code is written in a structured language, C.
|
|||
|
|
|||
|
WORKING EXAMPLE 2A- A SIMPLE ANIMATION IN C
|
|||
|
|
|||
|
The RenderMan Companion by Steve Upstill contains a fair amount of
|
|||
|
sample code that uses the C binding to the RenderMan Interface. Lets
|
|||
|
take a look at the source for one of these examples:
|
|||
|
_________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
#include "
|
|||
|
#define NFRAMES 10 /* number of frames in the animation */
|
|||
|
#define NCUBES 5 /* # of minicubes on a side of the color cube */
|
|||
|
#define FRAMEROT 5.0 /* # of degress to rotate cube between frames */
|
|||
|
|
|||
|
main()
|
|||
|
{
|
|||
|
int frame;
|
|||
|
float scale;
|
|||
|
char filename[20];
|
|||
|
|
|||
|
RiBegin(RI_NULL); /* Start the renderer */
|
|||
|
|
|||
|
RiLightSource("distantlight", RI_NULL);
|
|||
|
|
|||
|
/* Viewing transformation */
|
|||
|
RiProjection("perspective", RI_NULL);
|
|||
|
RiTranslate(0.0, 0.0, 1.5);
|
|||
|
RiRotate(40.0, -1.0, 1.0, 0.0);
|
|||
|
|
|||
|
for (frame = 1; frame
|
|||
|
|
|||
|
|
|||
|
Listing 2: shadtest.rib example from BMRT distribution
|
|||
|
|
|||
|
|
|||
|
__________________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
As you can see the hierarchy of commands is a little more evident.
|
|||
|
Of course, being an animation this is a more complex example. A
|
|||
|
distant light source is defined outside all frames of the animation.
|
|||
|
The type of camera projection is defined along with the initial
|
|||
|
viewing transformation. This is followed by the main loop which
|
|||
|
produces the frames of the animation.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Inside the loop each frame is defined. The display is set to
|
|||
|
write to a file and the format of the output is set with RI_RGBA,
|
|||
|
meaning red, green, blue and alpha channels will be output (or
|
|||
|
in simpler terms 3 colors and 1 opacity level). How this is done
|
|||
|
is renderer specific.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
This particular example is simplified by the use of an external
|
|||
|
routine, ColorCube(), which actually defines the object geometry
|
|||
|
to be used. In this case a cube is being built by ColorCube()
|
|||
|
with its sides being colored. I left this routine as
|
|||
|
an exercise for the reader, mostly because I always wanted to
|
|||
|
say that to someone. For those who can't wait to figure out
|
|||
|
how to do it themselves, the code for ColorCube() is provided
|
|||
|
in the RenderMan Companion.
|
|||
|
|
|||
|
|
|||
|
__________________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
6. Basic Steps
|
|||
|
|
|||
|
So now we've seen what a RIB file looks like and how they can
|
|||
|
|
|||
|
be created. We know we need a RIB file as input to the renderers
|
|||
|
|
|||
|
provided in the BMRT distribution. We know that RIB files
|
|||
|
|
|||
|
provide the geometry of a scene or set of frames and that shaders
|
|||
|
|
|||
|
are referenced by the RIB files to provide texturing aspects to
|
|||
|
|
|||
|
objects in those scenes.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Ok, so now what do we do? Well, lets run through a full example
|
|||
|
of creating, shading, previewing, and final rendering of a single
|
|||
|
scene.
|
|||
|
|
|||
|
CREATE THE RIB FILE
|
|||
|
|
|||
|
HERE IS A
|
|||
|
|
|||
|
|
|||
|
simple example
|
|||
|
I created on my own. It is C source that
|
|||
|
links with the libribout.a library. When run it produces a RIB file
|
|||
|
of a scene with a blue ball over a gray plane, lit by a single
|
|||
|
distant light source. The source is commented so you can see
|
|||
|
exactly what I did to create this scene. The C source is in
|
|||
|
the same directory as the examples (or any directory directly under
|
|||
|
the main directory of the distribution).
|
|||
|
To compile this program you would use the following command:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
gcc -o example-2a -O example-2a.c -I../include ../lib/l
|
|||
|
ibribout.a
|
|||
|
|
|||
|
|
|||
|
|
|||
|
To run the command simply type
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
example-2a > example-2a.rib
|
|||
|
|
|||
|
|
|||
|
|
|||
|
At this point you have the ASCII RIB input file needed to feed to one
|
|||
|
of the rendering programs.
|
|||
|
|
|||
|
PREVIEW THE SCENE WITH RENDRIBV AND RGL
|
|||
|
|
|||
|
THE FIRST THING TO DO IS EXAMIME THE SCENE AS A WIREFRAME DISPLAY
|
|||
|
|
|||
|
TO MAKE SURE ALL OUR OBJECTS ARE THERE. WE WON'T REALLY BE ABLE TO
|
|||
|
|
|||
|
TELL IF THEY ARE ALIGNED PROPERLY (IN FRONT OF OR NEXT TO EACH
|
|||
|
|
|||
|
OTHER) BUT WE'LL BE ABLE TO SEE IF THEY HAVE THE CORRECT BASIC SHAPE AND
|
|||
|
|
|||
|
IF THEY ARE WITHIN THE FIELD OF VIEW.
|
|||
|
|
|||
|
TO PREVIEW THE SCENE USE THE FOLLOWING COMMAND:
|
|||
|
|
|||
|
|
|||
|
rendribv example-2a.rib
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
OK, everything looks as it should. We've got a
|
|||
|
sphere and a plane.
|
|||
|
Lets add some surfaces to the objects using rgl
|
|||
|
. The sphere
|
|||
|
should be a solid blue and the plane should be
|
|||
|
grayish.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
To preview the scene with rgl use the following
|
|||
|
command:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
rgl example-2a.rib
|
|||
|
|
|||
|
|
|||
|
|
|||
|
[IMAGE]
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Figure 2: wireframe output from rendribv
|
|||
|
|
|||
|
|
|||
|
|
|||
|
FULL RENDERING WITH RENDRIB
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
AGAIN, THIS IS ABOUT RIGHT. THE IMAGE YOU'RE LOOKING AT ISN'T GREAT
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
DUE TO THE WAY I CAPTURED THE IMAGE AND CONVERTED IT TO A GIF FILE.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
BUT THE IMAGE IS ABOUT WHAT I WAS EXPECTING. THE PLANE IS A BIT
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
DARK. BUT LETS SEE WHAT WE GET FROM THE HIGH QUALITY RENDERER.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
To preview the scene with rendrib use the follo
|
|||
|
wing command:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
rendrib example-2a.rib
|
|||
|
|
|||
|
|
|||
|
|
|||
|
[IMAGE]
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Figure 3: output from rgl
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Oh oh. The ball is well lit on top, but the pl
|
|||
|
ane is
|
|||
|
gone. Maybe it has someting to do with lightin
|
|||
|
g.
|
|||
|
|
|||
|
ADJUSTING THE LIGHTING
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
IN THE SAMPLE SOURCE I SET A DISTANT LIGHT THAT
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
SAT ON A LINE THAT STRETCHES FROM
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
<0.0, 10.5, -6.0>TO <0.0, 0.0, 0.0>
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
THIS IS ALLOWING LIGHT TO FALL ON ONLY THE TOP HALF
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
OF THE BALL, BUT DOESN'T EXPLAIN WHY THE PLANE ISN'T
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
VISIBLE. THATS A DIFFERENT PROBLEM.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
THE SAMPLE SCENE C SOURCE CONTAINS THE FOLLOWING LINES:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
RiLightSource(RI_DISTANTLIGHT, RI_INTEN
|
|||
|
SITY,
|
|||
|
|
|||
|
|
|||
|
&intensity, RI_FROM, (RtPointer)from,
|
|||
|
|
|||
|
|
|||
|
RI_TO, (RtPointer)to, RI_NULL);
|
|||
|
|
|||
|
|
|||
|
[IMAGE]
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Figure 4: output from rendrib
|
|||
|
|
|||
|
|
|||
|
|
|||
|
The variables from and to define the line on which
|
|||
|
the distant light exists. To make this light shine more on the front
|
|||
|
of the ball we can move the to point out to -600 on the Z axis.
|
|||
|
This lights up the ball much better, but the plane is still invisible.
|
|||
|
We can also increase the value of the intensity
|
|||
|
variable from 0.6 to 1.0.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
But whats wrong with the plane? Where did it go? The answer lies
|
|||
|
in the surface texture used.
|
|||
|
|
|||
|
TEST WITH STANDARD SHADERS
|
|||
|
|
|||
|
THE ORIGINAL VERSION OF THE SAMPLE SCENE USED A
|
|||
|
matte
|
|||
|
surface shader for the plane. When rendered with the single distant
|
|||
|
light the reflectivity of the surface made it basically invisible
|
|||
|
from the angle of view that we had set with our initial translation.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
A first guess was to try adding a spotlight abo
|
|||
|
ve
|
|||
|
the surface, which can be seen in the
|
|||
|
updated version of the
|
|||
|
sample source.
|
|||
|
This had no effect, so I tried another shader -
|
|||
|
the same matte
|
|||
|
shader used on the sphere. Viola! The surface
|
|||
|
shows up,
|
|||
|
including the newly added spotlight. Way cool.
|
|||
|
|
|||
|
[IMAGE]
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Figure 5: look boss - da plane! da plane!
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Lets look at two more examples:
|
|||
|
* Another plain sphere over a plane with a
|
|||
|
back wall
|
|||
|
* Same scene with textured surfaces
|
|||
|
|
|||
|
|
|||
|
|
|||
|
The RIB file for
|
|||
|
|
|||
|
|
|||
|
|
|||
|
example-4a
|
|||
|
is probably more simplistic than the example-2a
|
|||
|
but with better results. The difference is the use of
|
|||
|
well placed spotlights. Notice the way the spotlight i
|
|||
|
s
|
|||
|
defined:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
LightSource "spotlight" 1 "from" [1 3 -4]
|
|||
|
|
|||
|
|
|||
|
"to" [0 0 0] "intensity" 15
|
|||
|
|
|||
|
|
|||
|
|
|||
|
This is just like the distant light used in example-2a.
|
|||
|
This time two lights are used, and they are spotlights
|
|||
|
instead of a distant light. The effect of well placed
|
|||
|
spotlight shows in the realism of this image.
|
|||
|
|
|||
|
|
|||
|
[IMAGE]
|
|||
|
|
|||
|
|
|||
|
Figure 6: example 4a.jpg
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
The next image is a little hard to see. I didn't have
|
|||
|
time to adjust the brightness (well I tried using xv
|
|||
|
but it kinda mucked up the image and I didn't have time
|
|||
|
to rerender Paul's RIB file). What it shows is the sam
|
|||
|
e
|
|||
|
scene as Figure 6 except this time textures have been
|
|||
|
applied to the sphere, the wall and the floor. The
|
|||
|
texture on the sphere is a glass stucco. The floor has
|
|||
|
a wood texture and the wall has a wallpaper effect.
|
|||
|
The sphere is interesting in that it uses a glass surfa
|
|||
|
ce
|
|||
|
shader with a stucco displacement map. The displacemen
|
|||
|
t
|
|||
|
map alters the actual shape of the sphere causing
|
|||
|
the slightly bumpy effect that is (somewhat) visible in
|
|||
|
Figure 7.
|
|||
|
All of the textures are apparent from examination of th
|
|||
|
e
|
|||
|
RIB file.
|
|||
|
All of the shaders used in this example are available
|
|||
|
in the 2.3.5 release of BMRT. It is left as an exercis
|
|||
|
e
|
|||
|
for the reader to rerender and adjust for the darkness
|
|||
|
of the image. (Thats also something I always wanted to
|
|||
|
say.)
|
|||
|
|
|||
|
|
|||
|
|
|||
|
[IMAGE]
|
|||
|
|
|||
|
|
|||
|
Figure 7: example 4b.jpg
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
At this point there are only two things left to do:
|
|||
|
* Write scene specific shaders
|
|||
|
* Render final version
|
|||
|
Simple enough. Except the first one of these will take up an
|
|||
|
entirely
|
|||
|
seperate article. Next we'll introduce you to what shaders are
|
|||
|
without
|
|||
|
going into depth on how to write them.
|
|||
|
Stay tuned next month when we'll cover how to write shaders.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
__________________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
7. Shaders
|
|||
|
|
|||
|
WHAT EXACTLY IS A SHADER?
|
|||
|
|
|||
|
ACCORDING TO TO THE RENDERMAN COMPANION,
|
|||
|
|
|||
|
A shader is the part of the rendering program that calculates the
|
|||
|
appearance of visible surfaces in the scene. In RenderMan, a shader
|
|||
|
is a procedure written in the RenderMan Shading Language used to
|
|||
|
compute a value or set of values (e.g., the color of the surface)
|
|||
|
needed during rendering.
|
|||
|
|
|||
|
In my language: a shader puts the surface on an object.
|
|||
|
|
|||
|
HOW DOES IT FIT INTO A RIB?
|
|||
|
|
|||
|
THE SHADERS ARE EXTERNAL PROCEDURES REFERENCED AT RENDERING TIME
|
|||
|
|
|||
|
BY THE RENDERING ENGINE (IN BMRT THAT WOULD BE
|
|||
|
rendrib).
|
|||
|
The C binding to RenderMan calls a shader with the RiSurface
|
|||
|
call. The following lines in the sample source used in the previous
|
|||
|
section apply the matte surface shader to the sphere and plane:
|
|||
|
|
|||
|
|
|||
|
RiSurface("matte", RI_NULL);
|
|||
|
.
|
|||
|
|
|||
|
This causes the following line to be added to the
|
|||
|
ASCII RIB file output by the program when it is linked with libribout.a
|
|||
|
:
|
|||
|
|
|||
|
|
|||
|
Surface "matte"
|
|||
|
.
|
|||
|
|
|||
|
Obviously things can get much more complex than this. But at least
|
|||
|
you'll have some way of identifying the shaders in the example
|
|||
|
scene files.
|
|||
|
|
|||
|
|
|||
|
COMPILING A SHADER
|
|||
|
|
|||
|
YOU SHOULD KEEP IN MIND THAT THE SHADERS YOU WRITE IN THE
|
|||
|
|
|||
|
RENDERMAN SHADING LANGUAGE HAVE TO BE COMPILED BEFORE THEY CAN
|
|||
|
|
|||
|
BE USED. COMPILING SHADERS IS VERY STRAIGHTFORWARD. TO COMPILE
|
|||
|
|
|||
|
THE MATTE.SL SHADER INTO THE MATTE.SO FILE YOU WOULD USE A LINE
|
|||
|
|
|||
|
LIKE:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
slc matte.sl
|
|||
|
.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
__________________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
7. Closing
|
|||
|
|
|||
|
There aren't that many resource devoted to BMRT or RenderMan on the
|
|||
|
|
|||
|
net just yet. Most can be found by starting at
|
|||
|
|
|||
|
|
|||
|
The RenderMan Repository -
|
|||
|
(http://pete.cs.caltech.edu/RMR/index.html).
|
|||
|
There is also a good collection of RenderMan shader information at
|
|||
|
|
|||
|
RManNotes -
|
|||
|
(http://www.cgrg.ohio-state.edu/~smay/RManNotes/index.html).
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
So, thats about it. You've seen the basics. You've been introduced to
|
|||
|
the
|
|||
|
tools. Now you just have to do something with them. Larry's
|
|||
|
|
|||
|
BMRT Web
|
|||
|
pages contain links to intersting images created with BMRT. That shoul
|
|||
|
d
|
|||
|
provide some motivation. I'll be playing with it all next month trying
|
|||
|
to learn about the RenderMan Shading Language for the April Graphics Mu
|
|||
|
se
|
|||
|
column. If you come up with anything interesting feel free to drop me
|
|||
|
a
|
|||
|
note.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
indent
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Ordering information:
|
|||
|
|
|||
|
|
|||
|
Pixar Animation Studios
|
|||
|
|
|||
|
Attn: Katherine Emery
|
|||
|
|
|||
|
1001 W. Cutting Blvd.
|
|||
|
|
|||
|
Richmond, CA 94804
|
|||
|
|
|||
|
Specify you are ordering the "RenderMan Specification". It costs
|
|||
|
$20US. Note: I have no association with Pixar (but I can dream, can't
|
|||
|
I?).
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Upstill, Steve The RenderMan Companion
|
|||
|
A Programmer's Guide to Realistic Computer Graphics.
|
|||
|
Addison-Wesley 1992
|
|||
|
|
|||
|
|
|||
|
|
|||
|
The RenderMan® Interface Procedures and RIB Protocol are
|
|||
|
© Copyright 1988, 1989, Pixar. All rights reserved.
|
|||
|
RenderMan® is a registered trademark of Pixar.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Blue Moon Rendering Tools are
|
|||
|
© Copyright 1990-1995 by Larry I. Gritz. All rights reserved.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
indent
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
© 1996 by Michael J. Hammel
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
__________________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
"Linux Gazette...making Linux just a little more fun!"
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
__________________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Learning about Security
|
|||
|
|
|||
|
By Jay Sprenkle, jay@shadow.ashpool.com
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
__________________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
It all started when the system rebooted...
|
|||
|
|
|||
|
|
|||
|
|
|||
|
I had been having reliability problems with my system for over a
|
|||
|
month. It would run fine for up to a week or so then it would crash
|
|||
|
with wierd symptoms. I know it's unusual to trust in your software
|
|||
|
these days, but I had faith that Linux was not the culprit. Only
|
|||
|
operating systems produced by large companies have to be rebooted
|
|||
|
every day.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
I took the motherboard out of the system and drove down to the
|
|||
|
supplier. The guy behind the counter had the standard "electronic
|
|||
|
supplier salesperson disease". He thought I was A. an idiot, B. trying
|
|||
|
to rip him off or C. trying to ruin his day/profit margin. I explained
|
|||
|
the problem, told him how it gave different symptoms each time it
|
|||
|
died, and how I had swapped out parts. After about 20 minutes he had
|
|||
|
no more arguments and he gave me a new motherboard.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
I took it home and put it back into the case. I was back up in a few
|
|||
|
minutes and I put the system back into service. After almost three
|
|||
|
weeks of blissfull operation it rebooted itself and started back up
|
|||
|
without a problem. I didn't even know about it until I saw the system
|
|||
|
log file a day later. ARGGG! The **** thing is broken again...
|
|||
|
|
|||
|
|
|||
|
|
|||
|
I studied the logs and found that odd things had happened. The web
|
|||
|
server process log was filled with total nonsense. The system log had
|
|||
|
stopped working shortly after the reboot. I felt that a power failure
|
|||
|
had caused the odd log messages and possibly damaged the system
|
|||
|
logging program.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
As I began looking at the other logs I found that someone had
|
|||
|
transferred copies of some of my files to a system I had never heard
|
|||
|
of before. This was serious! I had been violated! I didn't have
|
|||
|
hardware problems, some sleazoid-weasel had broken into my system! I
|
|||
|
had previously been over the system carefully trying to eliminate all
|
|||
|
the security holes. I hadn't been careful enough!
|
|||
|
|
|||
|
|
|||
|
|
|||
|
I copied off every log file I could find and immediately changed all
|
|||
|
the passwords on the system. If they had gotten in and copied the
|
|||
|
password file they could eventually crack the encoding on their own
|
|||
|
system and they would have all the passwords.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
I sent off a message to the system administrator of the system that
|
|||
|
the files had been sent to. With a little time at a search engine site
|
|||
|
I found that this system was located in Chicago. I later found out
|
|||
|
from the site's system administrator that this guy had somehow broken
|
|||
|
through the security in one of their systems routers. Once into the
|
|||
|
router he installed a packet sniffer. This program reads the data
|
|||
|
packets that go across the net and records anything that looks like a
|
|||
|
password.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
I had been connecting to my system remotely to get mail from it. I
|
|||
|
have since found out that the POP3 protocol used to get mail sends
|
|||
|
your account password in clear text (unencrypted) when getting your
|
|||
|
mail. This sleazy booger's packet sniffer probably captured my
|
|||
|
password when I was getting my mail. The rlogin, rsh, rexec, rlp,
|
|||
|
telnet, adn FTP protocols also send passwords in clear text by the
|
|||
|
way!
|
|||
|
|
|||
|
|
|||
|
|
|||
|
I went through the '/etc/services' file one more time and found that I
|
|||
|
had not disabled the 'rlogin' service as I had first thought. This
|
|||
|
service runs on port 513 but is not called 'rlogin'. I went through
|
|||
|
and disabled every service that starts with an 'r'. These are the
|
|||
|
remote services programs that a cracker can use to get into your
|
|||
|
system. I disabled all file sharing and all protocols except tcp/ip. I
|
|||
|
disabled the telnet service altogether since there is a better
|
|||
|
replacement. I also made sure that NFS and RPC were disabled since
|
|||
|
there was supposed to be a security hole in these too.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Well, not a lot had been done to my system, other than the reboot
|
|||
|
after the break-in. One nagging thing was that the system logging no
|
|||
|
longer worked. After goofing around with it for a day or so I finally
|
|||
|
noticed what should have been obvious. The 'syslogd' program had been
|
|||
|
replaced with another program with the same name.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
I haven't verified it but I believe this program is another copy of
|
|||
|
the packet sniffer the cracker used in the router. When you do a 'ps'
|
|||
|
to see what's running you wouldn't think anything about it since this
|
|||
|
program should be running all the time. I replaced the 'syslogd'
|
|||
|
program with the correct one and it worked like a champ again.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
While poking around in my /tmp directory I found a copy of the 'bash'
|
|||
|
shell with the SUID bit set. WHOA! What's this? With this little baby
|
|||
|
you can become root by simply running it. When I happened to mention
|
|||
|
this to a fine gentleman [Jim Dennis, The Answer Guy --Editor]
|
|||
|
who was helping me try to get it working he
|
|||
|
immediately remembered the security hole associated with this. There's
|
|||
|
a bug with the 'sendmail' program that allows you to make an SUID copy
|
|||
|
of your shell in the /tmp directory. If you don't have version 8.8.3
|
|||
|
or later of the sendmail program you're vulnerable too! (go to
|
|||
|
http://www.sendmail.org for the latest stuff).
|
|||
|
|
|||
|
|
|||
|
|
|||
|
So, what have I learned from all this?
|
|||
|
1. Security is more important than I thought.
|
|||
|
2. Security is no fun to implement...
|
|||
|
3. Cracker's read the CERT releases so they can keep up on the
|
|||
|
latest, coolest, ways to break into your system. They think it's a
|
|||
|
fun challenge to 'beat you'
|
|||
|
4. Security is no fun to implement...
|
|||
|
5. Don't use FTP, telnet, rlogin, rsh, or POP3 remotely. If you need
|
|||
|
to do this get the newer versions that encrypt the session BEFORE
|
|||
|
they log in.
|
|||
|
6. Security is no fun to implement...
|
|||
|
7. If you have an older version of sendmail than 8.8.3 replace it. 8.
|
|||
|
8. Don't give access to programmers tools. It just makes the
|
|||
|
cracker's job easier.
|
|||
|
9. Security is no fun to implement...
|
|||
|
10. Turn off all remote services on your system
|
|||
|
11. Security is no fun to implement...
|
|||
|
12. Read the CERT bulletins to see if you have any obvious holes in
|
|||
|
your system. If you do, fix them
|
|||
|
and lastly...
|
|||
|
|
|||
|
|
|||
|
Security is no fun to implement!
|
|||
|
|
|||
|
|
|||
|
|
|||
|
best of luck to you!
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Jay
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
__________________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Copyright © 1997, Jay Sprenkle
|
|||
|
Published in Issue 15 of the Linux Gazette, March 1997
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
__________________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
[ TABLE OF CONTENTS ]
|
|||
|
[ FRONT PAGE ]
|
|||
|
Back
|
|||
|
Next
|
|||
|
|
|||
|
|
|||
|
|
|||
|
__________________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
__________________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
"Linux Gazette...making Linux just a little more fun!"
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
__________________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Linux and MIDI: In the beginning...
|
|||
|
|
|||
|
By Dave Phillips, diphilp@mail.bright.net
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
__________________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
"The Musical Instrument Digital Interface (MIDI) protocol has been variously
|
|||
|
described as an interconnection scheme between instruments and computers, a se
|
|||
|
t of
|
|||
|
guidelines for transferring data from one instrument to another, and a languag
|
|||
|
e for
|
|||
|
transmitting musical scores between computers and synthesizers. All these def
|
|||
|
initions
|
|||
|
capture an aspect of MIDI."
|
|||
|
<Roads, Curtis. 1995.
|
|||
|
|
|||
|
Computer Music Tutorial. Cambridge, Massachusetts: The MIT Press. p. 972>
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Greetings! This article will hopefully be the first in a series covering vari
|
|||
|
ous
|
|||
|
aspects of MIDI and sound with Linux. The series will be far from exhaustive, a
|
|||
|
nd
|
|||
|
I sincerely hope to hear from anyone currently using and/or developing MIDI and
|
|||
|
audio software for use under Linux.
|
|||
|
|
|||
|
|
|||
|
Perhaps most Linux users know about MIDI as a soundcard interface option, or
|
|||
|
as
|
|||
|
a standalone interface option during kernel configuration for sound. As usual,
|
|||
|
some
|
|||
|
preparatory considerations must be made in order to optimally set up your Linux
|
|||
|
MIDI music machine. Be sure to read the kernel configuration notes included in
|
|||
|
/usr/src/linux/Documentation: you will find basic information about setting up
|
|||
|
your
|
|||
|
soundcard and/or interface, and you will also find notes regarding changes and
|
|||
|
additions to the sound driver software.
|
|||
|
|
|||
|
|
|||
|
Common soundcards such as the SoundBlaster16 or the MediaVision
|
|||
|
PAS16 require
|
|||
|
a separate MIDI connector kit to provide the MIDI In/Out ports, while standalon
|
|||
|
e
|
|||
|
interface cards such as the Roland MPU-401 and
|
|||
|
Music Quest MQX32M have the ports
|
|||
|
built-in. Dedicated MIDI interface cards don't usually have synthesis chips (su
|
|||
|
ch
|
|||
|
as the Yamaha OPL3 FM synthesizer) on-board, but they often provide services no
|
|||
|
t usually
|
|||
|
found on the soundcards, such as MTC or SMPTE time code and multi-port systems
|
|||
|
(for
|
|||
|
expanding available channels past the original limit of 16).
|
|||
|
|
|||
|
|
|||
|
Having successfully installed your card and kernel (or module) support, you w
|
|||
|
ill
|
|||
|
still need a decent audio system and a MIDI input device. If you use a soundcar
|
|||
|
d for
|
|||
|
MIDI record/play via the internal chip, you will also need a software mixer; if
|
|||
|
you
|
|||
|
record your MIDI output to tape, and then record your tape to your hard-disk, y
|
|||
|
ou
|
|||
|
will also want a soundfile editor.
|
|||
|
|
|||
|
|
|||
|
When the essential hardware and software is properly configured, it's time to
|
|||
|
look
|
|||
|
at the available software for making music with MIDI and Linux. Please note tha
|
|||
|
t in this
|
|||
|
article I will only supply links and very brief descriptions, while further art
|
|||
|
icles
|
|||
|
will delve deeper into the software and its uses.
|
|||
|
|
|||
|
|
|||
|
Nathan Laredo's playmidi is a simple command-line utility for MIDI playback a
|
|||
|
nd
|
|||
|
recording which can also be compiled for ncurses and X interfaces.
|
|||
|
JAZZ is an excellent sequencer which has some unique MIDI-processing features a
|
|||
|
nd
|
|||
|
an
|
|||
|
interface which will feel quite familiar to users of Macintosh and Windows sequ
|
|||
|
encers.
|
|||
|
Vivace
|
|||
|
and Rosegarden are notation packages which provide score playback, but each wit
|
|||
|
h a
|
|||
|
difference: Rosegarden accesses your MIDI configuration, while Vivace "renders"
|
|||
|
the score. tiMiDity is a rendering program which compiles a MIDI file into
|
|||
|
a soundfile, using patch sets or WAV files as sound sources. Ruediger Borrmann'
|
|||
|
s
|
|||
|
MIDI2CS is also a
|
|||
|
rendering program, but it acts as a translator from a MIDI file to a
|
|||
|
Csound score file.
|
|||
|
Mike Durian's tclmidi and
|
|||
|
tkseq provide a powerful MIDI programming
|
|||
|
environment, and Tim Thompson has recently announced the availability of his
|
|||
|
KeyKit,
|
|||
|
a very interesting GUI for algorithmic MIDI composition.
|
|||
|
|
|||
|
|
|||
|
4-track recording to hard disk can be realized using Boris Nagels'
|
|||
|
Multitrack, but
|
|||
|
Linux has yet to see an integrated MIDI/audio sequencer such as Opcode's
|
|||
|
Studio Vision for the Mac
|
|||
|
or Voyetra's Digital Orchestrator Plus for Windows. Linux also lacks device sup
|
|||
|
port for the
|
|||
|
digital I/O cards such as the Zefiro or
|
|||
|
DAL's Digital-only.
|
|||
|
|
|||
|
|
|||
|
If you use the tiMiDity package or MIDI2CS you will want to edit your
|
|||
|
sample
|
|||
|
libraries.
|
|||
|
Available soundfile editors include the remarkable MiXViews, the Ceres
|
|||
|
Studio.
|
|||
|
|
|||
|
|
|||
|
The excellent Linux MIDI & Sound Pages are the best starting point in your se
|
|||
|
arch
|
|||
|
for software, and be sure to check the Incoming directory at
|
|||
|
sunsite. Newsgroups
|
|||
|
dedicated to MIDI include comp.music.midi and
|
|||
|
alt.binaries.sounds.midi; please write to me if you know what
|
|||
|
mail-lists are available, I'll list them in a later article.
|
|||
|
|
|||
|
|
|||
|
Feel free to write concerning corrections, addenda, or comments to this artic
|
|||
|
le.
|
|||
|
Linux has great potential as a sound-production platform, and we can all contri
|
|||
|
bute
|
|||
|
to its development. I look forward to hearing from you!
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
__________________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
Special thanks to Hannu Savolainen (for maintaining sound support for the Linux
|
|||
|
kernel) and to Arne Di Russo (for the Linux MIDI & Sound Pages).
|
|||
|
|
|||
|
__________________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dave Phillips
|
|||
|
|
|||
|
|
|||
|
|
|||
|
dlphilp@bright.net
|
|||
|
|
|||
|
|
|||
|
|
|||
|
DLP's Home Page
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
__________________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
__________________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Copyright © 1997, Dave Phillips
|
|||
|
Published in Issue 15 of the Linux Gazette, March 1997
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
__________________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
[ TABLE OF CONTENTS ]
|
|||
|
[ FRONT PAGE ]
|
|||
|
Back
|
|||
|
Next
|
|||
|
|
|||
|
|
|||
|
|
|||
|
__________________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
__________________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
"Linux Gazette...making Linux just a little more fun!"
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
__________________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
AMAYA
|
|||
|
|
|||
|
INTRODUCTION
|
|||
|
|
|||
|
by Larry Ayers
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
__________________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
For several years a group of programmers in France have been developing
|
|||
|
an elaborate text-processing system known as Thot. Thot has some
|
|||
|
resemblances to Tex, in that it is a structural document-editing system
|
|||
|
capable of very high-quality output. One major difference is that Thot is
|
|||
|
more WYSIWYG; the formatting tagging is hidden and doesn't have to be
|
|||
|
explicitly written by the user. The output formats are more varied as well.
|
|||
|
Thot can produce Postscript files, as Tex can, but it can also produce plain
|
|||
|
ASCII text and HTML.
|
|||
|
|
|||
|
This last formatting capability attracted the attention of the W3
|
|||
|
Consortium a couple of years ago. (W3 is an international research
|
|||
|
organization which attempts to set standards for Internet documents; their
|
|||
|
flexibility and patience have been sorely tried in recent years by the flood
|
|||
|
of HTML innovations introduced by Microsoft and Netscape, among others).
|
|||
|
Using the Thot system as a core, the W3 group in collaboration with the Thot
|
|||
|
developers have been developing a combined web-browser and HTML editor known
|
|||
|
as Amaya.
|
|||
|
|
|||
|
SOURCE AND INSTALLATION
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Amaya, as is the case with much Linux software, is a work-in-progress.
|
|||
|
Until recently the source code was restricted to members of the W3
|
|||
|
Consortium and only binary versions were available to the public. In early
|
|||
|
February the source was made freely available, both at the
|
|||
|
Amaya web-site and also at the
|
|||
|
Sunsite archive site, currently in the /pub/Linux/Incoming directory.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Amaya can be installed anywhere as long as the directory structure is
|
|||
|
preserved. It is a Motif application, so unless you have the Motif
|
|||
|
libraries and header files installed you will have to get the
|
|||
|
statically-linked binary distribution. Compiling the source necessitates
|
|||
|
obtaining and compiling the Thot toolkit as well, which is available from
|
|||
|
the same locations as Amaya. I compiled it from source and found the
|
|||
|
instructions to be somewhat unclear; after several false starts I found that
|
|||
|
the Thot source should be unarchived first, then the Amaya source should be
|
|||
|
unarchived so that the Amaya directory is a subdirectory of the top-level
|
|||
|
Thot directory. This is a very large source tree and needs about sixty
|
|||
|
megabytes of free disk-space over and above that required for the source
|
|||
|
itself. It compiled without errors but there was no evident means provided
|
|||
|
for cleaning up the object files, etc. I resorted to moving subdirectories
|
|||
|
which looked un-essential to another drive, then moving back the essential
|
|||
|
ones which it turned out Amaya needs. You might want to try the binary
|
|||
|
version first in order to determine if it suits you before going to the
|
|||
|
trouble of obtaining and compiling the source.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
One caution: the first time you start Amaya, point it at a local file;
|
|||
|
otherwise it will attempt to load a file from http://www.w3.org and if
|
|||
|
you're not on-line at the time, it will die with a segmentation fault. The
|
|||
|
default home-page can be set to one on your local disk in the
|
|||
|
initialization file if you'd like.
|
|||
|
|
|||
|
EDITING AND BROWSING WITH AMAYA
|
|||
|
|
|||
|
|
|||
|
|
|||
|
As an HTML editor Amaya is WYSIWYG all the way. There is no view of the
|
|||
|
file being edited which shows the actual HTML tags. The main window
|
|||
|
(take a look!) is a typical browser
|
|||
|
window complete with in-line graphics, with the major difference being that
|
|||
|
you can enter text. The various HTML tags are invisibly inserted by means
|
|||
|
of mouse-driven menus. I much prefer hot-keys and found that, though few
|
|||
|
are included by default, any number of them can be set up in the
|
|||
|
~/.thotrc file. The behaviour of the enter key is
|
|||
|
interesting. Pressing the key while just typing text will start a new
|
|||
|
paragraph, whereas if you are entering list-items, table-fields or other
|
|||
|
sequential tags another one is created.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
There are two alternative file views available: the first is the
|
|||
|
"Structure View" (here's a
|
|||
|
screenshot) which presents a tree-like diagram of the HTML file. I
|
|||
|
suppose this could be useful with large files, just to get an overview.
|
|||
|
Another window, the "Alternate View"
|
|||
|
(another screenshot), shows you what
|
|||
|
your file will look like when displayed by a text-mode browser such as Lynx.
|
|||
|
I thought this was a nice touch. It's all too easy to work up an HTML file,
|
|||
|
test it with Netscape or Mosaic, and never even consider that it may be
|
|||
|
illegible viewed with a text-mode browser.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
As a web-browser Amaya has some limitations. It is confused by many of
|
|||
|
the newer Netscape tags, though on relatively simple pages it does a good
|
|||
|
job. As an example, the Linux Gazette table-of-contents page is displayed
|
|||
|
in a garbled fashion. The spiral-notebook graphic on the left side of the
|
|||
|
page isn't rendered, and the table formatting isn't interpreted
|
|||
|
correctly. In contrast, the bulk of LG's content pages display well, but
|
|||
|
they are usually simpler in format.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Amaya wasn't really created to be a full-fledged browser, though it may
|
|||
|
approach that status in future releases. The W3 "position statement" on
|
|||
|
Amaya says that it is intended to be a test-bed platform for HTML
|
|||
|
development.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
I never have become comfortable using Amaya, or any WYSIWYG HTML editor
|
|||
|
for that matter, to create HTML files from scratch. What I have been using
|
|||
|
it for is to experiment with already-written files. Sometimes when the
|
|||
|
precise tagging I want eludes me, I've loaded the file into Amaya just to
|
|||
|
see how it approaches the problem. It might be wise to begin using Amaya on
|
|||
|
copies of files. I favor lower-case tagging but when Amaya saves a file it
|
|||
|
will replace all of the tagging with its own, and this is all uppercase.
|
|||
|
Some of its other choices may not be what you want as well, so working with
|
|||
|
a copy allows you to incorporate the changes you like into the original
|
|||
|
file, leaving the rest alone.
|
|||
|
|
|||
|
CONCLUSION
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Amaya is an interesting project, and even at this early stage it's stable
|
|||
|
enough to be usable. I wouldn't want to have to rely on it solely, but it
|
|||
|
has proved useful to me on several occasions. Now that the source has been
|
|||
|
made public perhaps other programmers will make contributions; it's likely
|
|||
|
that in future months new releases will be made, amd its capabilities will
|
|||
|
increase.
|
|||
|
|
|||
|
|
|||
|
__________________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
Larry Ayers<layers@vax2.rainis.net>
|
|||
|
|
|||
|
Last modified: Thu Feb 27 18:50:42 CST 1997
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
__________________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Copyright © 1997, Larry Ayers
|
|||
|
Published in Issue 15 of the Linux Gazette, March 1997
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
__________________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
[ TABLE OF CONTENTS ]
|
|||
|
[ FRONT PAGE ]
|
|||
|
Back
|
|||
|
Next
|
|||
|
|
|||
|
|
|||
|
|
|||
|
__________________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
__________________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
"Linux Gazette...making Linux just a little more fun!"
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
__________________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
SLRN AND SLRNPULL: SUCKING DOWN THE NEWS
|
|||
|
|
|||
|
|
|||
|
by Larry Ayers
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
__________________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
There are quite a few methods of reading Usenet postings. A conventional
|
|||
|
newsreader will log on to your remote server, download headers of the new
|
|||
|
messages in groups you want to follow, then allow you to tag the messages you
|
|||
|
want to read. These messages are then fetched for you. All of this happens
|
|||
|
while online, and the time can mount up.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Another approach is one used by Suck and Leafnode, among others. These
|
|||
|
programs are designed to be used non-interactively and usually are set up to
|
|||
|
deposit fetched postings into a local spool-directory. Suck requires that you
|
|||
|
have an active news-server, such as INN or CNEWS, on your machine. Leafnode
|
|||
|
doesn't need the news-server (it has its own), but both programs are designed
|
|||
|
for multiple users and might be overkill for single-user machines.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Slrn is a popular text-mode newsreader, written by John Davis at MIT. It origi
|
|||
|
nally belonged to the
|
|||
|
first category above, but recently Davis has been working on an extension for
|
|||
|
Slrn which will pull down messages from a server and store them locally. The
|
|||
|
messages can then be read offline with Slrn. The extension is called
|
|||
|
Slrnpull, and it comes with the most recent beta version of Slrn.
|
|||
|
|
|||
|
INSTALLATION AND USAGE
|
|||
|
|
|||
|
|
|||
|
|
|||
|
If you have the S-lang library on your system, you can compile Slrn and
|
|||
|
Slrnpull from the source, which is available (along with the S-lang library
|
|||
|
source) from this site.
|
|||
|
A binary, statically-linked version may be in the /pub/Linux/Incoming
|
|||
|
directory at sunsite.unc.edu by the time you read this. If you prefer a
|
|||
|
certain location for the news-spool directory (which can get large) the
|
|||
|
slrnfeat.h file in the /slrn/src directory can be edited.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Slrn uses a configure script which should enable it to be compiled on
|
|||
|
most Linux systems. Once you've put the executables in a directory on your
|
|||
|
path, create the spool directory (/var/spool/news/slrnpull or whatever
|
|||
|
you've defined it to be), then copy the supplied sample script
|
|||
|
slrnpull.conf to the new directory. This needs to be edited before
|
|||
|
you start Slrnpull for the first time. The format is not complicated; here are
|
|||
|
John Davis' comments from the sample file:
|
|||
|
|
|||
|
|
|||
|
# The syntax of the file is very simple.
|
|||
|
# Any line that is blank or begins with a '#' character will be ignored by
|
|||
|
# slrnpull. The remaining lines consist of 1-3 fields separated by
|
|||
|
# whitespace:
|
|||
|
#
|
|||
|
# NEWSGROUP_NAME MAX_ARTICLES_TO_RETRIEVE NUMBER_OF_DAYS_BEFORE_EXPIRE
|
|||
|
#
|
|||
|
# The first field must contain the name of a newsgroup.
|
|||
|
#
|
|||
|
# The second field denotes the number of articles to retrieve for the
|
|||
|
# newsgroup; if its value is 0, all available articles will
|
|||
|
# be retrieved.
|
|||
|
#
|
|||
|
# The third field indicates the number of days after an article is retrieved
|
|||
|
# before it will be eligible for deletion. If this value is 0, articles from
|
|||
|
# this group will not expire.
|
|||
|
#
|
|||
|
#
|
|||
|
# If a field is blank, or contains the single character '*', default values
|
|||
|
# will apply to the field. Defaults may be set by a line whose newsgroup
|
|||
|
# field is 'default'. Such a line will denote default values to be applied to
|
|||
|
# the lines following it or until another default is established.
|
|||
|
|
|||
|
# For example:
|
|||
|
default 20 14
|
|||
|
# indicates a default value of 20 articles to be retrieved from the server and
|
|||
|
# that such an article will expire after 14 days.
|
|||
|
comp.os.linux.misc 50 7
|
|||
|
comp.os.linux.x 20 7
|
|||
|
comp.os.linux.announce * *
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
This is easier to set up than some news programs I've used!
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Assuming you have the $NNTPSERVER variable set to your news-server's IP
|
|||
|
address in your ~/.bash_profile or ~/.cshenv file, Slrnpull
|
|||
|
should be ready to try out. The first time you start it up it will create a
|
|||
|
subdirectory for each news-group you have specified. Then it will log on to
|
|||
|
your server and download messages, displaying the connection speed and number
|
|||
|
of articles on your terminal screen.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
You probably subscribe to certain groups for which you want all of the new
|
|||
|
messages. For certain others you may want to be more selective in what you
|
|||
|
download. A kill-file can be created in the spool directory which specifies,
|
|||
|
on a per-group basis, which messages you would prefer be left on the
|
|||
|
server.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Starting up Slrn with the switch --spool will cause it to load the
|
|||
|
contents of your newly-filled spool-file. Reading messages this way is fast,
|
|||
|
and any which you delete will then be invisible in the newsreader, though they
|
|||
|
remain on the disk until they are expired. Any follow-up postings which you
|
|||
|
might write are stored in a subdirectory of the spool. The next time you run
|
|||
|
Slrnpull it will upload them to the server before retrieving new messages.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Slrnpull keeps a log of all transactions to the server; these messages are
|
|||
|
displayed on the screen as the program runs, but the idea of this program is
|
|||
|
that you don't need to be sitting there watching. The log is useful for
|
|||
|
checking to see if your postings have been accepted by the server.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Periodically Slrnpull should be run with the --expire switch, which
|
|||
|
will remove all messages you've marked for deletion while reading news with
|
|||
|
Slrn. This could be run every night as a cron job.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
It will take some fine-tuning of the slrnpull.conf file, but eventually
|
|||
|
you will have the program retrieving just the messages you want. It might seem
|
|||
|
like a waste to be downloading all of the junk messages along with the
|
|||
|
worthwhile ones, but it's a continuous process and doesn't take long. I've
|
|||
|
found that running Slrnpull while browsing the web or receiving an FTP file
|
|||
|
works well.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
The sample .slrnrc file included with the program has an if/then
|
|||
|
statement which causes Slrn to read the local active file when run in spool
|
|||
|
mode, while keeping Slrn in standard mode from retrieving the bulky remote
|
|||
|
active file each time a connection is made. This lets you read news
|
|||
|
directly from your server when desired.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
The sample file includes some new entries in order for Slrn to make use
|
|||
|
of the spooled messages. These are:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
set spool_inn_root "/var/spool/news/slrnpull"
|
|||
|
set spool_root "/var/spool/news/slrnpull/news"
|
|||
|
set spool_nov_root "/var/spool/news/slrnpull"
|
|||
|
set use_slrnpull 1
|
|||
|
hostname "your.host.name"
|
|||
|
username "your_user_name"
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
The remainder of the .slrnrc file is the same as in previous Slrn
|
|||
|
versions, so if you already have one customized to your liking the
|
|||
|
Slrnpull-specific sections can be lifted from the sample and pasted in.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
I initially had some trouble convincing slrnpull to talk to my news-server. I
|
|||
|
asked John Davis for help and he sent me a patch for one source file which
|
|||
|
caused slrnpull to generate a debugging log; from the logfile he determined
|
|||
|
that the problem was with the proprietary Dnews server software which my
|
|||
|
provider uses. The currently available version has this patch included.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
If you want to find out what software your news-server uses, just telnet into
|
|||
|
the news machine:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
telnet [IP address] :nntp
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
The server will identify itself when you log in.
|
|||
|
|
|||
|
CONCLUSION
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Slrnpull is probably most useful with low-volume newsgroups, such as
|
|||
|
comp.os.linux.announce. You would most likely want to see all of the
|
|||
|
messages anyway in such a group and Slrnpull will fetch them all. High-volume
|
|||
|
groups, such as comp.os.linux.advocacy, typically have a high
|
|||
|
chaff-to-wheat ratio, and in these a quick scan of the headers for the few of
|
|||
|
interest (while online) might be more efficient. Slrnpull is also effective
|
|||
|
for obtaining a quick idea of the the flavor and tone of a group: just tell
|
|||
|
it to suck down the most recent twenty messages in the group, and see
|
|||
|
what you think.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
If you have never used Slrn, I highly recommend this program, especially
|
|||
|
if you read news over a PPP or SLIP connection. It's fast and efficient,
|
|||
|
and its behaviour can be easily molded to your needs. Users of the Emacs
|
|||
|
news interface Gnus will find the transition painless, as most of the
|
|||
|
keystroke commands are identical. Gnus has many more features but it's
|
|||
|
slower to use over a network and is much more demanding of system resources.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
__________________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Larry Ayers<layers@vax2.rainis.net>
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Last modified: Thu Feb 27 18:39:52 CST 1997
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
__________________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Copyright © 1997, Larry Ayers
|
|||
|
Published in Issue 15 of the Linux Gazette, March 1997
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
__________________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
[ TABLE OF CONTENTS ]
|
|||
|
[ FRONT PAGE ]
|
|||
|
Back
|
|||
|
Next
|
|||
|
|
|||
|
|
|||
|
|
|||
|
__________________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
__________________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
"Linux Gazette...making Linux just a little more fun!"
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
__________________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
SIGROT: BBS TAGLINES FOR THE NET
|
|||
|
|
|||
|
|
|||
|
|
|||
|
By Paul Anderson, <paul@geeky1.ebtech.net>
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
__________________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Have you ever called BBSes and downloaded QWK packets? If you have,
|
|||
|
then you most likely will have either seen or used a tagline. For those
|
|||
|
of you who haven't, a tagline is one line of text for a witty saying. It's
|
|||
|
usually at the bottom of a persons signature. QWK packets, by the way,
|
|||
|
are like UUCP for DOS in that you downloaded this zipped file with all
|
|||
|
your mail in it, then you open it in a QWK mail reader, and upload your
|
|||
|
replies. The QWK mail reader often supports the ability to change taglines
|
|||
|
with each message.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
These short witticisms are nice to have at the end of a message, and
|
|||
|
sometimes they prove to be the best part! This brings me to the program
|
|||
|
featured in this article. Sigrot is currently in version 1.0 and is maintained
|
|||
|
by Christopher Morrone, <cmorrone@udel.edu>.
|
|||
|
It can be obtained from gilb5.gilb.udel.edu:/pub/linux/sigrot_v1.0.tar.gz
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Got the tar-file? Good. Untar it with:
|
|||
|
|
|||
|
tar -xzvf sigrot_v1.0.tar.gz
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Look in the current directory and you'll find a directory named sigrot_v1.0/
|
|||
|
Change into that directory, read the README and INSTALL.help files, then
|
|||
|
run make
|
|||
|
|
|||
|
geeky1,1:~/tar-stuff/sigrot_v1.0% make
|
|||
|
done
|
|||
|
geeky1,1:~/tar-stuff/sigrot_v1.0%
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
You'll have a program named sigrot in the current directory, sigrot.1
|
|||
|
is the manpage. Then you can test it:
|
|||
|
|
|||
|
geeky1,1:~/tar-stuff/sigrot_v1.0% sigrot -w testfile
|
|||
|
testfile copied over signature archive.
|
|||
|
Type "sigrot -r" to restore the previous archive.
|
|||
|
geeky1,1:~/tar-stuff/sigrot_v1.0% sigrot
|
|||
|
geeky1,1:~/tar-stuff/sigrot_v1.0%
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Well, what have we just done? We've put the signatures in testfile into
|
|||
|
sigrot's signature archive, and we've just nuked your ~/.signature file.
|
|||
|
Check it out and you'll see that it contains:
|
|||
|
|
|||
|
This is the first signature entry.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Okay, so if we check testfile we see that the first line contains the
|
|||
|
first signature. Let's run it again. Okay, what's in ~/.signature now?
|
|||
|
Check it out and you'll see:
|
|||
|
|
|||
|
This is
|
|||
|
the
|
|||
|
second signature
|
|||
|
entry.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
So what good is this to me, you say? Plenty. Create a new file called
|
|||
|
'mysigs' with couple of your favourite one-liners. Now we run our dear
|
|||
|
friend sigrot again:
|
|||
|
|
|||
|
geeky1,1:~/tar-stuff/sigrot_v1.0% sigrot -w mysigs
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Okay, run sigrot with no command-line options and check ~/.signature.
|
|||
|
Is one of the signatures from mysigs in ~/.signature? If so, put the following
|
|||
|
in your crontab:
|
|||
|
|
|||
|
00 * * * * sigrot
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
That'll run sigrot once every hour. Now, you're ready to send e-mail
|
|||
|
with your new cool .sig!
|
|||
|
|
|||
|
OF PREFIXES AND SPACE REDUCTION.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Sometimes, when you've got .sig like mine, the majority of my .sig never
|
|||
|
changes. If you get a significant number of one-liners in your signature
|
|||
|
archive, it can became quite large. What a waste of space. But, wait! There's
|
|||
|
a way to reduce the amount of space it takes! To show you what I mean,
|
|||
|
Here's my .signature:
|
|||
|
|
|||
|
---
|
|||
|
Paul Anderson
|
|||
|
Author of Star Spek(a tongue in cheek pun on Star trek)
|
|||
|
e-mail: starspek-request@lowdown.com with subscribe as the subject
|
|||
|
I hear it's hilarious. Maintainer of the Tips-HOWTO.
|
|||
|
http://www.netcom.com/~tonyh3/speck.html
|
|||
|
Manuals out, after all possible keystrokes have failed.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Only the last line ever changes. Why waste disk space when you can use
|
|||
|
a more efficient method? Here's what I've done, you see sigrot creates
|
|||
|
a directory called ~/.sigrot, and it lets you specify a prefix. A prefix
|
|||
|
is what's put before the .sigs from your .sig archive, it's used for stuff
|
|||
|
that doesn't change. So, I created a file named ~/.sigrot/prefix, and put
|
|||
|
the following in it:
|
|||
|
|
|||
|
---
|
|||
|
Paul Anderson
|
|||
|
Author of Star Spek(a tongue in cheek pun on Star trek)
|
|||
|
e-mail: starspek-request@lowdown.com with subscribe as the subject
|
|||
|
I hear it's hilarious. Maintainer of the Tips-HOWTO.
|
|||
|
http://www.netcom.com/~tonyh3/speck.html
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
See? Sigrot picks a .sig from your .sig-archive, then it appends it
|
|||
|
to the file ~/.sigrot/prefix.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
__________________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Now you know how to spiff up your e-mail with a wonderful program called
|
|||
|
sigrot. I have a file of 1,000 signatures for use with sigrot, send me
|
|||
|
some e-mail at paul@geeky1.ebtech.net
|
|||
|
if you want a copy, or some help on setting up sigrot.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
__________________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Copyright © 1997, Paul Anderson
|
|||
|
Published in Issue 15 of the Linux Gazette, March 1997
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
__________________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
[ TABLE OF CONTENTS ]
|
|||
|
[ FRONT PAGE ]
|
|||
|
Back
|
|||
|
Next
|
|||
|
|
|||
|
|
|||
|
|
|||
|
__________________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
__________________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
"Linux Gazette...making Linux just a little more fun!"
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
__________________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Thoughts on Multi-threading
|
|||
|
|
|||
|
By Andrew L. Sandoval, sandoval@perigee.net
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
__________________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
As I read the article "What Is Multi-Threading?" in
|
|||
|
the February issue of LJ my mind went back a couple of months ago to the
|
|||
|
time I decided it would be fun to write a multi-threaded FTP daemon
|
|||
|
to replace the wu-ftpd we were using on a very heavily hit FTP server.
|
|||
|
As the author explains in his article, threads make a lot of sense for
|
|||
|
server applications. Just the memory savings on 250 copies of the
|
|||
|
FTP daemon makes it all worth investigating. BUT, just as you were
|
|||
|
about to go out and make all of you favorite server applications multi-threaded
|
|||
|
,
|
|||
|
I thought a couple of notes from my project might come in handy.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
First, if you plan on allowing a high number of concurrent connections
|
|||
|
to your server, a single multi-threaded process will not do. Most
|
|||
|
OS's, Linux included limit the number of file descriptors a process is
|
|||
|
allowed to have open at any one time. You can usually use getrlimit()
|
|||
|
and setrlimit() to give your process the maximum number of file descriptors
|
|||
|
allowed, rather than the default (usually 64), but, even still most operating
|
|||
|
system (NOFILE) hard limits are set to 1024. In the case of an FTP
|
|||
|
server you must keep in mind that you will need at least three file descriptors
|
|||
|
for every client connection. (1 for commands, 1 for file transfers,
|
|||
|
and 1 to open the file or directory listing to transfer.) This
|
|||
|
quickly adds up. Supporting 500 concurrent connections would require
|
|||
|
an absolute minimum of 1500 descriptors, and that is not even counting
|
|||
|
the ones you need just to get up and running (like the socket used to listen
|
|||
|
for incoming connections.) The best way I have found to solve
|
|||
|
this problem is to fork() a predetermined number of child processes that
|
|||
|
all accept file descriptors that are passed from the parent and then create
|
|||
|
a thread to handle the incoming descriptor/connection. On Linux you
|
|||
|
would use the proc filesystem to pass the descriptor. On other OS's
|
|||
|
such as Solaris (that support Streams) you would use ioctl() with the I_SENDFD
|
|||
|
and I_RECVFD functions.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
This has another advantage as well. In addition to accepting
|
|||
|
file descriptors from the parent process which is listening for connections
|
|||
|
on port n, you can now receive connections from any process that chooses
|
|||
|
to pass clients on to your multi-threaded server through a named pipe.
|
|||
|
A good example might be a small appliction that is started by inetd and
|
|||
|
then decides (by say IP address) whether to pass your connection to
|
|||
|
the multi-threaded server or to the standard ftpd. (This was useful
|
|||
|
in my case, since our ftpd was for anonymous FTP only. The daemon
|
|||
|
did not support any functions unneccesary for typical anonymous FTP such
|
|||
|
as chmod or delete. On the otherhand, we wanted employees of the
|
|||
|
company to be able to do just that while still logging in as anonymous.
|
|||
|
So, if you came from an IP address that we knew was ours, the inetd
|
|||
|
application exec()'d ftpd after clearing the close-on-exec flag.
|
|||
|
If you came from the outside world you went directly to the multi-threaded
|
|||
|
FTP daemon which also limited your access beyond what the file system already
|
|||
|
provided.)
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Just when you finally think you have out smarted the file descriptor
|
|||
|
problem, here comes another one: fopen(). The standard i/o fuctions
|
|||
|
like fopen(), fprintf(), fgets(), etc., are extremely useful when working
|
|||
|
with a command driven application like FTP. Unfortunately the fileno
|
|||
|
element of the FILE struct is usually defined as an unsigned char.
|
|||
|
Simply put, once you have more than 255 open file descriptors in a single
|
|||
|
process you can no longer reliably use fopen(), fprintf(), etc. The
|
|||
|
solution here: don't use these functions. Instead use open(), read(),
|
|||
|
write(), etc. A possible second solution is to make sure you have
|
|||
|
enough child processes accepting file descriptors to keep each process
|
|||
|
from exceeding the 255 limit.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
If you choose to write such a multi-threaded server, you will also
|
|||
|
have to deal with the possibility of concurrent threads in multiple processes
|
|||
|
accessing a delicate resource. (i.e. even something as simple as
|
|||
|
a global count of the number of concurrent connections.) In this
|
|||
|
case you will still want to use a Mutex to protect data, but, the mutex
|
|||
|
will need to mmap()'d by all child processes, so that a lock in thread
|
|||
|
A in process 1 will also block thread C in process 2. In the case
|
|||
|
of a resource such as a "current user count" you will want that
|
|||
|
variable to be included in the mmap()'ing anyway.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Aside from all of this, threads really are fun. Threaded applications
|
|||
|
are a great deal more painful to debug, and given the OS and stdio limits
|
|||
|
I have mentioned there may even be more programming overhead, but,
|
|||
|
the trade off in system performance and resource utilization for major
|
|||
|
client/server applications is worth it. Besides, this is the stuff
|
|||
|
that makes programming fun!
|
|||
|
|
|||
|
|
|||
|
|
|||
|
I hope this is helpful.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Andrew L. Sandoval
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
__________________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Copyright © 1997, Andrew L. Sandoval
|
|||
|
Published in Issue 15 of the Linux Gazette, March 1997
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
__________________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
[ TABLE OF CONTENTS ]
|
|||
|
[ FRONT PAGE ]
|
|||
|
Back
|
|||
|
Next
|
|||
|
|
|||
|
|
|||
|
|
|||
|
__________________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
__________________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
"Linux Gazette...making Linux just a little more fun!"
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
__________________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
USENIX Notes
|
|||
|
|
|||
|
By Arnold D. Robbins, arnold@skeeve.atl.ga.us
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
__________________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Sun, 19 Jan 97
|
|||
|
|
|||
|
I am writing this on my Linux portable after USENIX. I hadn't been
|
|||
|
to USENIX in four years, and had been looking forward to it for a while.
|
|||
|
Some things were really great, and others were disappointing. Overall,
|
|||
|
I enjoyed it and it was worthwhile.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
I took two tutorials. The first was on Win32 programming, and it was most
|
|||
|
of the justification for getting my company to pay for the conference, since
|
|||
|
I'll be doing a lot of Windows NT programming starting soon after I return.
|
|||
|
The tutorial was good, but the notes were not in sync with the slides, which
|
|||
|
was very frustrating.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
The second tutorial, well, the less said about it the better; it was below
|
|||
|
the usual standard for USENIX tutorials, which are usually quite good.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Of course, the best part of the conference is the conference. There are
|
|||
|
several components: the refereed papers, the invited talks, the vendor
|
|||
|
show, and then the general "networking" (not the computer and wires kind,
|
|||
|
the other kind) that goes on.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
The refereed papers didn't seem that exciting. They all either dealt with
|
|||
|
enhancements to proprietary versions of Unix, or had WWW in their title.
|
|||
|
Of course, maybe when I get to read some of the papers, I'll revise my
|
|||
|
opinion.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
The invited talks were better, particularly from the guys at Bell Labs;
|
|||
|
Matt Blaze on why encryption isn't used more often, Rob Pike on Inferno
|
|||
|
(they gave out an Inferno CD to all registrants) and Bill Cheswick's
|
|||
|
"Stupid Net Tricks" talk.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
The vendor show was ok. O'Reilly, and especially the San Diego Technical
|
|||
|
Bookstore did a bang-up business. All the Linux CD-ROM vendors were there
|
|||
|
and did OK too. The biggest hit was SSC's t-shirt (see photos elsewhere),
|
|||
|
which sold like hot cakes. Fortunately, I got mine early.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
This was the first joint USELINUX conference. I must say, Linux is
|
|||
|
certainly invigorating the USENIX community. The Linux talks I went too
|
|||
|
were all well attended. Dave Miller and Miguel de Icaza (sp?) gave a
|
|||
|
neat talk on Linux/SPARC. It doesn't yet support the Minix filesystem,
|
|||
|
due to endian issues. Most people in the room didn't seem to mind...
|
|||
|
Otherwise, it's Linux, and it's cool. You can get a real distribution
|
|||
|
from Red Hat.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
It was particularly interesting that Linus's talk on the future of Linux
|
|||
|
overflowed the smaller conference room into the very large main speaking
|
|||
|
hall. The majority of the conference attendees were there. As always, I
|
|||
|
found Linus amusing, intelligent, and very insightful about the computer /
|
|||
|
desktop industry. Linus's goal: World Domination. But to achieve this,
|
|||
|
we need real end-user applications (spreadsheets, word processors, etc).
|
|||
|
Linus made the insightful observation that the Unix vendors have made a
|
|||
|
mistake concentrating on the market for the server in the back room; no-one
|
|||
|
sees it, and no-one cares if it's replaced with something else.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
And last, but not least, the "networking" part. Figuring that I probably
|
|||
|
wouldn't get to another USENIX for a long time, I took advantage of the
|
|||
|
opportunity to chat with Dennis Ritchie for a few minutes, and thank him
|
|||
|
for the courtesy with which he always replies to my email. I enjoyed it;
|
|||
|
he's a really neat person.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
I got to meet Jeffrey Friedl (author of O'Reilly's new book on regular
|
|||
|
expressions); he had found a number of strange cases in gawk's behavior
|
|||
|
(that have since been fixed). I also finally met Larry Wall, author
|
|||
|
of Perl. Larry is one of the few people who generally doesn't wear a
|
|||
|
name badge at USENIX; otherwise he wouldn't be able to move around much.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
I was there when Greg Wettstein (sp?) of the Roger Maris Cancer Center
|
|||
|
came over, introduced himself to Larry, and told him that many cancer
|
|||
|
patients were having an easier life thanks to Perl. It was a humbling
|
|||
|
experience, since I certainly haven't made that kind of an impact on
|
|||
|
anything, and Larry too seemed a bit awed. Larry's a neat guy; I hope
|
|||
|
to get to know him better in the future.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Conclusions: 1. It's worthwhile for Linux people to be involved in USENIX;
|
|||
|
we're all on the same Open Systems / Free Software team, even if we don't
|
|||
|
realize it. 2. Linux is invigorating USENIX, it's brought the fun back
|
|||
|
into the Unix world.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arnold Robbins -- The Basement Computer
|
|||
|
|
|||
|
Internet: arnold@gnu.ai.mit.edu
|
|||
|
|
|||
|
UUCP: dragon!skeeve!arnold
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
__________________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Copyright © 1997, Arnold D. Robbins
|
|||
|
Published in Issue 15 of the Linux Gazette, March 1997
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
__________________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
[ TABLE OF CONTENTS ]
|
|||
|
[ FRONT PAGE ]
|
|||
|
Back
|
|||
|
Next
|
|||
|
|
|||
|
|
|||
|
|
|||
|
__________________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
__________________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
"Linux Gazette...making Linux just a little more fun!"
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
WHAT YOU CAN DO WITH TCPD
|
|||
|
|
|||
|
By Kelly Spoon, mars@loeffel.txdirect.net
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
If you have read my article on security, then you know that tcpd
|
|||
|
can be used to keep people from getting on your machine, and, thusly,
|
|||
|
it makes a nice first line defense against Bad Guys. You also know that
|
|||
|
there is an extra option you can put in the /etc/hosts.allow and
|
|||
|
/etc/hosts.deny files that the man pages refer to as the
|
|||
|
"shell_command".
|
|||
|
|
|||
|
|
|||
|
|
|||
|
So....are you wondering what all you can do with the "shell_command" option?
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Me too. According to the hosts_access man(5) page, you can use it
|
|||
|
to finger the person who is trying to get to your services. However, the
|
|||
|
feature that I think is pretty neat is that this gives you the ability to
|
|||
|
set up personalized banners for whenever someone tries to connect to your
|
|||
|
machine.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Here's the catch, though. In order to enable this option, you're going to
|
|||
|
need to recompile and turn this sucker on yourself. The binaries that your
|
|||
|
favorite Linux distribution installed on your machine probably weren't set
|
|||
|
up to take advantage of this neat little feature. (At least, they weren't
|
|||
|
on mine)
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Getting and installing tcpd
|
|||
|
|
|||
|
|
|||
|
__________________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
The first thing you need to do is get a hold of is the source for tcpd.
|
|||
|
|
|||
|
Here is where it's been hidden.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Those of you with keen eyes will note that the name of the file we have
|
|||
|
downloaded is tcp_wrappers*.tar.gz and not tcpd*.tar.gz. Don't
|
|||
|
sweat it, this really is the package you want.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
tar -zxvf tcp_wrappers*.tar.gz will unpack everything for you into
|
|||
|
the tcp_wrappers_7.4 directory. It doesn't really matter where you do
|
|||
|
this, since after we have compiled and installed the binaries, we can get rid
|
|||
|
of this directory.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Go in there as root. Normally, all we have to do is type make,
|
|||
|
and Linux will automagically compile the program for us. However, we have
|
|||
|
to pass some extra options to the make with this program.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
* REAL_DAEMON_DIR=/usr/sbin/real-daemon-dir
|
|||
|
|
|||
|
tells tcpd where to look for the *real* daemons to use when you
|
|||
|
try to use the "easy" tcpd method. More on that after we get the
|
|||
|
sucker installed.
|
|||
|
|
|||
|
* STYLE=-DPROCESS_OPTIONS
|
|||
|
|
|||
|
This is the whole reason we're recompiling tcpd in the first
|
|||
|
place. This option enables tcpd to use the "shell_command"
|
|||
|
feature, which in turn lets use do the banners.
|
|||
|
|
|||
|
* linux
|
|||
|
|
|||
|
This just tells the compiler to use all the options that will
|
|||
|
produce a working binary for Linux.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Unfortunately, the Makefile for tcpd doesn't have an install option,
|
|||
|
so you have to put things in place yourself. Here's a quick list of where
|
|||
|
things should go after you've compiled:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Bin File Location on Your Machine
|
|||
|
-------- -----------------------
|
|||
|
safe_finger /usr/sbin/real-daemon-dir/safe_finger
|
|||
|
tcpd /usr/sbin/tcpd
|
|||
|
tcpdchk /usr/sbin/real-daemon-dir/tcpd-chk
|
|||
|
tcpdmatch /usr/sbin/real-daemon-dir/tcpdmatch
|
|||
|
try-from /usr/sbin/real-daemon-dir/try-from
|
|||
|
*.3 /usr/man/man3/*.3
|
|||
|
*.5 /usr/man/man5/*.5
|
|||
|
*.8 /usr/man/man8/*.8
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
As always, make sure you back up your *old* files before installing the new
|
|||
|
ones.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
__________________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
The Fun Part -- Banners and Other Stuff
|
|||
|
|
|||
|
|
|||
|
__________________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Now that we have our new tcpd in place, it's time to get the frame work
|
|||
|
in place for our banners. You can do this in any directory on your machine,
|
|||
|
but, in keeping with my own warped view of where things belong, I suggest
|
|||
|
creating a dir called /etc/banners and using that for our homebase.
|
|||
|
And since I get to be the author, that's the dir I'm going to refer to.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Once we've got /etc/banners created, we're going to need to do this from
|
|||
|
the tcp_wrappers_7.4 dir:
|
|||
|
|
|||
|
|
|||
|
cp Banners.Makefile /etc/banners/Makefile
|
|||
|
|
|||
|
|
|||
|
|
|||
|
And now that the hall is rented and the orchestra engaged, it is time to
|
|||
|
dance. (ObNiftyStarTrekQuoteThatI'veBeenDyingToUse)
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Creating your banners
|
|||
|
|
|||
|
|
|||
|
|
|||
|
In order to make a banner, all you have to do is go into /etc/banners,
|
|||
|
and create a file called prototype. Put anything you want in here.
|
|||
|
It's your banner. Since this would be a good place for an example, here's
|
|||
|
what I put for my banner whenever someone is denied access to my machine:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
^[[44m*****************************************************************
|
|||
|
This is a ^[[m^[[44;01mprivate^[[m^[[44m machine
|
|||
|
*******************************************************************^[[m
|
|||
|
|
|||
|
If you wish to access this machine, please send email to
|
|||
|
^[[01root@loeffel.txdirect.net^[[m
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
This prints out a nice looking little banner with the first 3 lines in blue,
|
|||
|
and the word "private" and root's email address set in bold. Looks pretty
|
|||
|
official.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Once you have created your prototype, then all you need to do is run
|
|||
|
a make in the /etc/banners directory. This will then produce
|
|||
|
4 files (or more, depending on whether you've hacked the Makefile).
|
|||
|
|
|||
|
|
|||
|
|
|||
|
They are in.telnetd, in.ftpd, in.rlogind, and nul.
|
|||
|
What you need to do next is create another dir, and move these files into
|
|||
|
it. Since the above example is for the connections that get refused, I
|
|||
|
put these in /etc/banners/general-reject. The last thing to do is
|
|||
|
to move the in.* and nul into the new directory. It's also
|
|||
|
a good idea to stick your prototype in there in case you want to change
|
|||
|
the banner later on.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Making tcpd use the banners
|
|||
|
|
|||
|
|
|||
|
|
|||
|
This is the last step. I promise.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
You need to edit your /etc/hosts.allow or /etc/hosts.deny files
|
|||
|
so that tcpd knows it should throw up a banner whenever someone tries
|
|||
|
to connect. Basically, my /etc/hosts.deny looks like this:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
# /etc/hosts.deny for linux.home.net
|
|||
|
|
|||
|
ALL: ALL except .home.net: banners /etc/banners/general-reject
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
And that's it. You can now put up customized banners that will be shown
|
|||
|
based upon the hostname of the person who tries to connect to your machine.
|
|||
|
Finally, you can take advantage of the "shell_command" option listed in
|
|||
|
man 5 hosts_access. To see what else you can do with this, check
|
|||
|
out man 5 hosts_options.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
And, if you're scratching your head wondering what's going on, keep reading.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
__________________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
Behind the Scenes
|
|||
|
|
|||
|
|
|||
|
__________________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
How tcpd Works
|
|||
|
|
|||
|
|
|||
|
|
|||
|
As you know, tcpd hangs around on your system and waits for something
|
|||
|
to wake it up. When that happens, it looks at /etc/hosts.deny and
|
|||
|
/etc/hosts.allow to see if the person who is trying to connect matches
|
|||
|
any of the patterns you have listed in these files. If it finds a match,
|
|||
|
then it either lets the connection go through, or it closes the socket.
|
|||
|
If it finds a match with a "shell_command" in it, then it will execute that
|
|||
|
command.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
The banners option tells tcpd that it needs to send back a
|
|||
|
text message to the client that's trying to connect. When it sees
|
|||
|
banners in the allow or deny file, it goes into the
|
|||
|
directory that you listed (/etc/banners/general-reject in my example),
|
|||
|
and tries to find a file with the same name as the service that the client
|
|||
|
requested. If it finds a file, the contents of the file get pumped back
|
|||
|
down to the client, and then tcpd either closes the connection or
|
|||
|
lets it go through. It it doesn't find a file, then tcpd doesn't
|
|||
|
send anything back.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
In plain English, if someone tries to telnet in (which would invoke
|
|||
|
in.telnetd) and you have a banners options listed for their entry
|
|||
|
in one of the hosts.* files, then tcpd looks for a file called
|
|||
|
/etc/banners/general-reject/in.telnetd. If it finds it, it displays
|
|||
|
the file, if not, ah well.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
This is important to remember when setting up a banner for your ftp service.
|
|||
|
The Banners.Makefile will create a banner file called in.ftpd.
|
|||
|
Since most Linux distributions use the Washington University FTP server,
|
|||
|
the service name is actually wu.ftpd. Therefore, if you intend for
|
|||
|
your banner to also be shown to people trying to ftp to your machine, you
|
|||
|
either need to change the /etc/banners/general-reject/in.ftpd to
|
|||
|
wu.ftpd, or you need to change the name of the service.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
The 2 Ways to Use tcpd
|
|||
|
|
|||
|
|
|||
|
|
|||
|
You generally have 2 choices on how tcpd protects your services:
|
|||
|
Let inetd handle it, or do a substitution. In my humble opinion,
|
|||
|
it's best to let inetd handle it.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
As you may know, inetd is the "super server". It basically monitors
|
|||
|
a bunch of ports, and whenever it detects someone trying to use one of them,
|
|||
|
it starts up the service you have listed in inetd.conf. This is handy
|
|||
|
because you don't run what you don't need, and thusly, unused daemons aren't
|
|||
|
sucking up all your system resources.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
inetd can be configured to launch tcpd before it starts up
|
|||
|
the service. In fact, if you take a look in /etc/inetd.conf, you'll
|
|||
|
see that it already does for many of your services. I'll pull one out
|
|||
|
so you don't have to flip over to a virutal console:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Service Socket Proto Flags User Server name Arguments
|
|||
|
------- ------ ----- ----- ---- ----------- ---------
|
|||
|
telnet stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.telnetd
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
The "Service" entry is just the name of the connection from the file
|
|||
|
/etc/services. This tells inetd what port to listen on.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
The other entries that we're concerned about is the "Server Name" and
|
|||
|
"Arguments". "Server Name", as you can see, points to our good friend
|
|||
|
tcpd. Whenever inetd gets a request for the "Service", it
|
|||
|
starts up tcpd with the path to the actual service passed as an
|
|||
|
"Argument". This lets tcpd know what program to run if it exits
|
|||
|
and the client has permission to use the service.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
See. It's pretty easy.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Your other option is to substitute tcpd for the service directly, and
|
|||
|
not even bother with inetd. To do this, you just move the daemon
|
|||
|
you want to protect to /usr/sbin/real-daemon-dir, and then either
|
|||
|
copy tcpd over to where the service used to be, or put in a symbolic
|
|||
|
link.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
For example, let's say I want to use tcpd on
|
|||
|
/usr/sbin/in.telnetd. I would simply give the following commands:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
mv /usr/sbin/in.telnetd /usr/sbin/real-daemon-dir/in.telnetd
|
|||
|
ln -s /usr/sbin/tcp /usr/sbin/in.telnetd
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
This method is even eaiser than inetd, but I prefer not to have 30
|
|||
|
million sym links laying around my system.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
One Last Thing to Keep in Mind
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Quoting directly from tcpd's man page:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
The tcpd program can be set up to monitor incoming
|
|||
|
requests for telnet, finger, ftp, exec, rsh, rlogin, tftp,
|
|||
|
talk, comsat and other services that have a one-to-one
|
|||
|
mapping onto executable files.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Check out that "...services that have a one-to-one mapping onto executable
|
|||
|
files" part.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
What that means is that tcpd is designed to be used by services that
|
|||
|
spawn 1 daemon for 1 client. In other words, tcpd won't work for
|
|||
|
stuff like ircd or Samba. Luckily, these programs usually give you
|
|||
|
the option to deny access to certain hosts, which accomplishes the same
|
|||
|
thing as what tcpd does.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
__________________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
And In Closing...
|
|||
|
|
|||
|
|
|||
|
__________________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
For the answer to any questions you have that I didn't address, please check
|
|||
|
the README file that comes with tcp_wrapper. It does an excellent
|
|||
|
job of explaining what's going on, and how to take advantage of some other
|
|||
|
features (although some of it is ambiguous about exact locations of where
|
|||
|
config files should live due to the fact that the author created
|
|||
|
tcp_wrappers to work on a lot of different machines). Also peruse the
|
|||
|
Makefile sometime and see if there's anything else you want to turn on
|
|||
|
once you've got a good idea of how this all works.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
And last but not least, the author of tcp_wrappers has given us a
|
|||
|
very useful tool free of charge. If you like it and use it, please
|
|||
|
take the time to send him a postcard (snail mail addy at the bottom of the
|
|||
|
README)....he's earned it.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
__________________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
Mail to:mars@loeffel.txdirect.net
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
__________________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Copyright © 1997, Kelly Spoon
|
|||
|
Published in Issue 15 of the Linux Gazette, March 1997
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
__________________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
[ TABLE OF CONTENTS ]
|
|||
|
[ FRONT PAGE ]
|
|||
|
Back
|
|||
|
Next
|
|||
|
|
|||
|
|
|||
|
|
|||
|
__________________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
__________________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
LINUX GAZETTE BACK PAGE
|
|||
|
|
|||
|
Copyright © 1997 Specialized Systems Consultants, Inc.
|
|||
|
For information regarding copying and distribution of this material see
|
|||
|
the Copying License.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
__________________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
CONTENTS:
|
|||
|
* About This Month's Authors
|
|||
|
* Not Linux
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
__________________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
ABOUT THIS MONTH'S AUTHORS
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
__________________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Paul Anderson
|
|||
|
Paul Anderson currently maintains the Tips-HOWTO, and writes episodes for
|
|||
|
a parody on Star Trek called Star Spek whilst going through highschool.
|
|||
|
Also fascinated with steam engines and a few months away from purchasing
|
|||
|
his first lathe, metalworking being one of numerous hobbies of his(get's
|
|||
|
expensive ya know!). Model rocketry, model airplanes, amateur science,
|
|||
|
inventing, antique engine collecting and electronics with a dash of old
|
|||
|
computer collecting are among his hobbies.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Larry Ayers
|
|||
|
Larry Ayers lives on a small farm
|
|||
|
in northern Missouri, where he is currently engaged in building a
|
|||
|
timber-frame house for his family. He operates a portable band-saw mill,
|
|||
|
does general woodworking, plays the fiddle and searches for rare
|
|||
|
prairie plants, as well as growing shiitake mushrooms. He is also
|
|||
|
struggling with configuring a Usenet news server for his local ISP.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Boris Beletsky
|
|||
|
Boris Beletsky is currently working as System Administrator at Institute
|
|||
|
Computer
|
|||
|
Science in Jerusalem, Israel. He is one of the Debian GNU/Linux developers.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
John M. Fisk
|
|||
|
John Fisk is most noteworthy as the former editor of the
|
|||
|
Linux Gazette.
|
|||
|
After three years as a General Surgery resident and
|
|||
|
Research Fellow at the Vanderbilt University Medical Center,
|
|||
|
John decided to "hang up the stethoscope", and pursue a
|
|||
|
career in Medical Information Management. He's currently a full
|
|||
|
time student at the Middle Tennessee State University and hopes
|
|||
|
to complete a graduate degree in Computer Science before
|
|||
|
entering a Medical Informatics Fellowship. In his dwindling
|
|||
|
free time he and his wife Faith enjoy hiking and camping in
|
|||
|
Tennessee's beautiful Great Smoky Mountains. He has been an avid Linux fan,
|
|||
|
since his first Slackware 2.0.0 installation a year and a half
|
|||
|
ago.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Michael J. Hammel
|
|||
|
Michael J. Hammel,
|
|||
|
is a transient software engineer with a background in
|
|||
|
everything from data communications to GUI development to Interactive Cable
|
|||
|
systems--all based in Unix. His interests outside of computers
|
|||
|
include 5K/10K races, skiing, Thai food and gardening. He suggests if you
|
|||
|
have any serious interest in finding out more about him, you visit his home
|
|||
|
pages at http://www.csn.net/~mjhammel. You'll find out more
|
|||
|
there than you really wanted to know.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Mike List
|
|||
|
Mike List is a father of four teenagers, musician, printer (not
|
|||
|
laserjet), and recently reformed technophobe, who has been into computers
|
|||
|
since April,1996, and Linux since July.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Dave Phillips
|
|||
|
Dave Phillips is a blues guitarist & singer, a computer musician
|
|||
|
working especially with Linux sound & MIDI applications, an avid
|
|||
|
t'ai-chi player, and a pretty decent amateur Latinist. He lives and
|
|||
|
performs in Findlay OH USA.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Arnold Robbins
|
|||
|
Arnold Robbins is a professional programmer and technical author. He has
|
|||
|
been working
|
|||
|
with Unix systems for longer than he cares to think about, and with AWK and
|
|||
|
gawk since
|
|||
|
2988. He is the author of
|
|||
|
Effective Awk Programming, published by SSC.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kelley Spoon
|
|||
|
Kelley Spoon currently studies computer science at the University of Texas,
|
|||
|
San Antonio. Some of his hobbies include trying to learn how to play the
|
|||
|
guitar, playing Euchre, laughing at John C. Dvorak, converting pizza into
|
|||
|
source code, terrorizing villages along the Mexican border, and frightening
|
|||
|
small children. He has been a Linux user since August 1995, and still
|
|||
|
pronounces the name as "luh-eye-nucks".
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Jay Sprenkle
|
|||
|
Jay Sprenkle lives in the Kansas City area and currently
|
|||
|
works for DRT Systems Consulting. He has been a programming professional
|
|||
|
for about 20 years, since graduating from the University of Missouri
|
|||
|
with a degree in Computer Science and a minor in Electrical
|
|||
|
Engineering. He's written code in assembler up through C++ and various
|
|||
|
fourth generation languages.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
__________________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
NOT LINUX
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
__________________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Thanks to all our authors, not just the ones above, but also those who wrote
|
|||
|
giving us their tips and tricks and making suggestions. Thanks also to our
|
|||
|
new mirror sites. And, of course, thanks to Michael Montoure for all his
|
|||
|
help with graphics and HTML checking.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
This month has been a very busy one for me. I've been discovering just
|
|||
|
how much more work there is to managing a print magazine, Linux Journal,
|
|||
|
as opposed to
|
|||
|
an electronic one. I'm afraid I've had much less time for LG than before.
|
|||
|
If you've written and didn't get a response, this is the reason. It also
|
|||
|
means that I'm too close to time to post LG and too little
|
|||
|
of it is together -- maybe half as I write this message.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
However, I have hired an Administrative Assistant, Amy Kukuk, to help
|
|||
|
with LJ correspondence and article tracking. She's also going to
|
|||
|
help me with LG by reading the news groups and writing the News
|
|||
|
Bytes column. So with her good help, I expect the pace to slow
|
|||
|
considerably.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
While Linux Gazette is free for all our readers, it is not free
|
|||
|
for its publisher, SSC -- they do pay me for the time I spend putting
|
|||
|
it together. In order to help pay for these costs, we've decided to
|
|||
|
make LG the PBS of online ezines by having sponsors from the
|
|||
|
Linux community. As I am
|
|||
|
sure most of you noticed, the Front Page now has a Sponsor section.
|
|||
|
We appreciate very much the financial contribution that InfoMagic, our
|
|||
|
first sponsor, has made to help us defray our costs.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Sorry to be late, I haven't been able to get to our web server since
|
|||
|
last Wednesday.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Have fun!
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
__________________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Marjorie L. Richardson
|
|||
|
|
|||
|
Editor, Linux Gazette gazette@ssc.com
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
__________________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
[ TABLE OF CONTENTS ]
|
|||
|
[ FRONT PAGE ]
|
|||
|
Back
|
|||
|
|
|||
|
|
|||
|
|
|||
|
__________________________________________________________________________
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Linux Gazette Issue 14, March 1997, http://www.ssc.com/lg/
|
|||
|
|
|||
|
This page written and maintained by the Editor of Linux Gazette,
|
|||
|
gazette@ssc.com
|