560 lines
24 KiB
HTML
560 lines
24 KiB
HTML
<!--startcut ======================================================= -->
|
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
|
|
<html><head>
|
|
<META NAME="generator" CONTENT="lgazmail v1.1preB">
|
|
<TITLE>The Answer Guy 32:
|
|
SysAdmin: User Administration: Disabling Accounts
|
|
</TITLE>
|
|
<!-- ORIGINAL SUBJECT:
|
|
disabling users
|
|
JTD SUBTITLE:
|
|
|
|
-->
|
|
</head>
|
|
|
|
<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#A000A0"
|
|
ALINK="#FF0000">
|
|
<H4>"Linux Gazette...<I>making Linux just a little more fun!</I>"
|
|
</H4>
|
|
<P> <hr> <P>
|
|
<!-- ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: -->
|
|
<H1 align="center"><A NAME="answer">
|
|
<img src="../gx/dennis/qbubble.gif" alt="" border="0" align="middle">
|
|
<a href="./index.html">The Answer Guy</a>
|
|
<img src="../gx/dennis/bbubble.gif" alt="" border="0" align="middle">
|
|
</A></H1>
|
|
<BR>
|
|
<H4 align="center">By James T. Dennis,
|
|
<a href="mailto:linux-questions-only@ssc.com">linux-questions-only@ssc.com</a>
|
|
<BR>Starshine Technical Services, <A HREF="http://www.starshine.org/">http://www.starshine.org/</A>
|
|
</H4>
|
|
<p><hr><p>
|
|
<!--endcut ========================================================= -->
|
|
<H3><img src="../gx/dennis/qbub.gif" alt="(?)"
|
|
width="50" height="28" align="left" border="0"
|
|
>SysAdmin: User Administration: Disabling Accounts</H3>
|
|
<p><strong>From Glenn Jonsson on 05 Aug 1998 </strong></p>
|
|
<!-- begin body -->
|
|
|
|
<strong><p>Answerguy,
|
|
</p></strong>
|
|
<strong><p>I'm doing a course on unix administration, unfortunatly i don't
|
|
recall being taught to disable a user, I was hoping you would be
|
|
able to tell me how to do this?
|
|
</p></strong>
|
|
<strong><p>Thanks
|
|
<br>Glenn
|
|
</p></strong>
|
|
|
|
<blockquote><img src="../gx/dennis/bbub.gif" height="28" width="50"
|
|
alt="(!)" border="0"
|
|
>I suppose you could disable a user by taking a sledgehammer
|
|
or other LART to his or her kneecaps (least gruesome among
|
|
many means that come to mind). However, I presume the intended
|
|
question at hand was:
|
|
</blockquote>
|
|
<blockquote>"How does a Unix/Linux sysadmin disable a user's
|
|
<EM>account</EM>?"
|
|
</blockquote>
|
|
<blockquote>Now, I should preface this answer with a bit of a flame
|
|
(more of a spark, really): This is not the "do-your-homework"
|
|
line. When you get an assigment as part of your coursework
|
|
you've either been presented with the information needed to
|
|
answer the question --- or you're expected to know where to
|
|
find that information (how to do the research).
|
|
</blockquote>
|
|
<blockquote>So, before I answer this question let me answer the meta-question:
|
|
</blockquote>
|
|
<blockquote>"How does a sysadmin find out how to perform routine
|
|
user and group management operations on his systems?"
|
|
</blockquote>
|
|
<blockquote>One way is to look for commands that relate the operation,
|
|
to find out what might be '<tt>apropos</tt>' --- so we issue the
|
|
'<tt>apropos</tt>' command (or '<tt>man -k</tt>' --- keyword search command).
|
|
</blockquote>
|
|
<blockquote>Since this relates to a user's account let's try:
|
|
</blockquote>
|
|
|
|
<blockquote><blockquote><code>man -k account
|
|
</code></blockquote></blockquote>
|
|
|
|
<blockquote>On my system that gives me two commands:
|
|
</blockquote>
|
|
<pre>userdel (8) - Delete a user account and related files
|
|
usermod (8) - Modify a user account
|
|
</pre>
|
|
|
|
<blockquote>These and many others will show up when we issue:
|
|
</blockquote>
|
|
|
|
<blockquote><blockquote><code>man -k users
|
|
</code></blockquote></blockquote>
|
|
|
|
<blockquote>... and '<tt>man -k login</tt>' will give us just about the right
|
|
number of other alternatives.
|
|
</blockquote>
|
|
<blockquote>However, '<tt>usermod</tt>' sounds promising. Looking at the man
|
|
page for usermod and searching on the word "disable" leads be to
|
|
the following paragraph:
|
|
</blockquote>
|
|
|
|
<pre>-f inactive_days
|
|
The number of days after a password expires until
|
|
the account is permanently disabled. A value of 0
|
|
disables the account as soon as the password has
|
|
expired, and a value of -1 disables the feature.
|
|
The default value is -1.
|
|
</pre>
|
|
<blockquote>... so that's one way to do it. If we near the end of the
|
|
man pages we'll often find a "SEE ALSO" section which will
|
|
point us to related man pages. So we look at <tt>passwd(1)</tt>
|
|
(the section/chapter 1 command '<tt>passwd</tt>') and search on disable
|
|
and find:
|
|
</blockquote>
|
|
|
|
<pre>Account maintenance
|
|
User accounts may be locked and unlocked with the -l and
|
|
-u flags. The -l option disables an account by changing
|
|
the password to a value which matches no possible
|
|
encrypted value. The -u option re-enables an account by
|
|
changing the password back to its previous value.
|
|
</pre>
|
|
|
|
<blockquote>... so that's method number two.
|
|
</blockquote>
|
|
<blockquote>This note about "changing the password to a value which
|
|
matches no...." sounds in intriquing. Technically it is
|
|
using the wrong terminology since passwords in the <tt>/etc/passwd</tt>
|
|
file are technically not "encrypted" --- they are "hashed"
|
|
using a cryptographically strong algorithm (DES by default, MD5
|
|
or others on some systems). The distinction is lost on most
|
|
writers and it is a bit longer to explain --- but the way that
|
|
DES hashing of a password under Unix works is that the password
|
|
and a "salt" (a random 12 bit value) are used as a "key" to
|
|
"encrypt" a string of ASCII NUL's using the DES (data encryption
|
|
standard --- a 20 year old U.S. mandated encryption system derived
|
|
from IBM's "Lucifer" research). The result value is expressed as
|
|
a subset of the printable characters with the "salt" prepended to it.
|
|
</blockquote>
|
|
<blockquote>(The "salt" exists simply to make "dictionary attacks" more
|
|
expensive --- computationally and in terms of storage. It
|
|
means that the "crack-er" has to have about 4000 different
|
|
hashes for every word in his or her 'crack' dictionary).
|
|
</blockquote>
|
|
<blockquote>One of the properties of DES that made it attractive for
|
|
commercial deployment is that that it is highly resistant
|
|
to "known plaintext attacks." That means that it was
|
|
computationally infeasible to recover the key even if one
|
|
had arbitrary samples of the plain text (our string of NUL
|
|
characters in this case) and the crypt text (the hashed form of
|
|
the password from the <tt>/etc/passwd</tt> file).
|
|
</blockquote>
|
|
<blockquote>There are two reasons why this, technically, is not being
|
|
used for "encryption." First, is a matter of semantics; if
|
|
I know the plain text (the string of NUL's) then I'm not
|
|
"encrypting" anything becuase I'm not "hiding information."
|
|
I am "using cryptographic protocols and algorithms" for
|
|
other purposes (such as authentication, digital signatures,
|
|
etc). The other reason is more technical and pedantic. Conceivably
|
|
there might be multiple keys (passwords) that encrypt a string
|
|
of NUL's into the same hash. This is a defining property of
|
|
hashes (checksums, CRC's, etc). You can verify that there is
|
|
a given "message" has a given likelihood of being valid
|
|
(you can measure its probability of integrity) --- but you can
|
|
not definitively say that a given specific message was <EM>the</EM>
|
|
same one that generated a given hash. (Given other constraints
|
|
on the use of DES for Unix passwords it's possible to try all
|
|
1 to 8 character combinations to detect collisions --- but that
|
|
is a different matter).
|
|
</blockquote>
|
|
<blockquote>In any event, given an alleged password the '<tt>login</tt>' program
|
|
(or the <tt>xdm</tt>, <tt>xlockmore</tt>, POP/IMAP daemon, or PAM module, etc)
|
|
will attempt to encrypt a string of NUL's with it (and the
|
|
"salt") and compare the resulting hash to the one stored in the
|
|
<tt>/etc/passwd</tt> or the <tt>/etc/shadow</tt> file. (Generally this is done
|
|
via the '<tt>crypt(3)</tt>' library call). There are minor differences
|
|
in the details (particularly on '<tt>shadow</tt>' vs. non-shadowed systems)
|
|
but that's the gist of it. If the hashes match than the user
|
|
is presumed to have entered the correct password.
|
|
</blockquote>
|
|
<blockquote>If we follow another cross-reference from the <tt>passwd(1)</tt>
|
|
man page we might find a list of characters that cannot be
|
|
generated by the <tt>crypt(3) function</tt>. Actually we'll find a
|
|
list of characters that <EM>can</EM> result from the operation and
|
|
a bit of thought about that (taking the complement) will
|
|
show us some characters that will never work.
|
|
</blockquote>
|
|
<blockquote>Now, the Linux man pages don't just come out and say this
|
|
but logically we can see that we could use the following
|
|
procedure to "manually" disable an account:
|
|
</blockquote>
|
|
|
|
<blockquote>
|
|
<ul><li>Edit the <tt>/etc/passwd</tt> ('<tt>vipw</tt>' command)
|
|
(or the <tt>/etc/shadow</tt>, as appropriate)
|
|
|
|
<li>Find the user.
|
|
|
|
<cwliblockquote>Insert an '*' into the the password field
|
|
(i.e.prepend the password has with an asterisk)
|
|
</ul></blockquote>
|
|
|
|
<blockquote>... and it makes sense that <EM>no</EM> password will <em>ever</em>
|
|
result in a matching hash. Thus the user will be locked out
|
|
of direct logins. To re-enable the account *with the same
|
|
password it used to have* just remove the asterisk. That's
|
|
why we don't overwrite the passwd --- then we'd have to
|
|
go through extra work to securely re-enable the password and
|
|
get the user's new password set. (Most organizations are
|
|
quite sloppy about this procedure --- sending initial passwords
|
|
over e-mail, setting them to well-known and easily guessed
|
|
values, etc. I recommend much better protocols).
|
|
</blockquote>
|
|
<blockquote>Now, I have a confession to make: I didn't figure this all
|
|
out on my own. I didn't read all of these man pages. I
|
|
learned about the "prepend with an asterisk" trick from other
|
|
sysadmins. It was so long ago, I really don't remember where
|
|
I saw it first. It might have been netnews. It might have been
|
|
over someone's shoulder. Who knows.
|
|
</blockquote>
|
|
<blockquote>The point here is that you should find some of those sysadmins
|
|
to "hang out" with. To be an effective sysadmin you need to
|
|
become part of a sysadmin community. You and your classmates
|
|
should probably form such a community and work together ---
|
|
there's too much in this field for anyone to "know it all"
|
|
(as a perusal of my back issues will sure prove with regards
|
|
to me). The most organized and widespread community of
|
|
sysadmins would be SAGE (the "System Adminsitrator's Guild"
|
|
--- the 'e' is silent). Look at
|
|
<A HREF="http://www.usenix.org/sage">http://www.usenix.org/sage</A>
|
|
for details.
|
|
</blockquote>
|
|
<blockquote>Of course none of this is to suggest that you should neglect
|
|
your textbooks. There are two standard textbooks on systems
|
|
administration today:
|
|
</blockquote>
|
|
|
|
<blockquote>
|
|
<dl><dt>Unix System Administration Handbook, 2nd Edition
|
|
<dd>by Evi Nemeth, Trent R. Hein, Scott Seebass and
|
|
Garth Snyder
|
|
<br>(Prentice Hall, 1995, ISBN 0-13-151051-7)
|
|
<br>Known as the "cranberry book."
|
|
|
|
<dt>Essential System Administration, 2nd Edition
|
|
<dd>by Aeleen Frisch
|
|
<br>(O'Reilly & Associates, 1995, ISBN 1-56592-127-5)
|
|
<br>... the "armadillo book"
|
|
</dl>
|
|
</blockquote>
|
|
<blockquote>... I'm working on one that I hope will go well beyond these
|
|
--- although it will appear as a "Linux" title.
|
|
</blockquote>
|
|
<blockquote>Of the two Frisch's work tends to give a more "step-by-step"
|
|
HOWTO approach to these things --- so I'd look in there
|
|
(indeed I tried to review it so I could remind myself of
|
|
what she says --- but my copy must be out on loan somewhere).
|
|
</blockquote>
|
|
<blockquote>Glancing in the cranberry book's index I find no entry
|
|
under "accounts" and "users" refers me to "logins" where
|
|
I find "disabling" on pp. 95 & 95:
|
|
</blockquote>
|
|
<blockquote>Occasionally, a user's login must be temporarily
|
|
disabled. Before networking invaded the UNIX world
|
|
we would just put a star in front of the encrypted
|
|
password, making it impossible for the user to log in.
|
|
However the user could still log in across the network.
|
|
These days we replace the user's shell with a program
|
|
that prints a message explaining why the login as been
|
|
disabled and provides instructions for rectifying the
|
|
situation.
|
|
</blockquote>
|
|
<blockquote>There is no further explanation of this at that point ---
|
|
and they don't cover a number of other issues related to
|
|
the situation.
|
|
</blockquote>
|
|
<blockquote>They are, of course, referring to the fact that this
|
|
user might have a <tt>.rhosts</tt> file that permits them access
|
|
to their account without a password. Their approach is
|
|
<EM>part</EM> of a solution --- but it is incomplete.
|
|
</blockquote>
|
|
<blockquote>In the <em>Linux System Administration Handbook</em>
|
|
by Mark F. Komarinski and Cary Collett they go into a bit more detail
|
|
(p. 24) but show a bit less experience:
|
|
</blockquote>
|
|
<blockquote><blockquote>If you want to disable a user account (that is,
|
|
prevent the user from logging in again), replace the
|
|
password in the <tt>/etc/passwd</tt> file with an * or some
|
|
other character. Since the * isn't a valid encrypted
|
|
password, there is no password that will allow you to
|
|
log into that account (2).
|
|
</blockquote></blockquote>
|
|
<blockquote>... no notion of re-enabling the account with its old
|
|
password here. We've replaced it.
|
|
</blockquote>
|
|
<blockquote>Komarinski and Collett also mention that the account can
|
|
receive mail --- but doesn't mention that there may be
|
|
other forms of access that are possible by this "disabled"
|
|
user. They miss the same things that Nemeth et al
|
|
gloss over --- and a bit more.
|
|
</blockquote>
|
|
<blockquote>A few of the problems with just knocking out the password
|
|
--- and changing the shell:
|
|
</blockquote>
|
|
<blockquote>You might have various other services, like <tt>ssh</tt>,
|
|
that don't require a password.
|
|
</blockquote>
|
|
<blockquote>Their <tt>.forward</tt> file might route their mail through
|
|
a script or customer filtering program (like <tt>procmail</tt>).
|
|
That script could do anything that they could do
|
|
under their UID --- including opening up some sort of
|
|
connection to some system to which they still have
|
|
access and allowing them to have interactive access
|
|
to a shell. (I don't know of a tool that does this
|
|
--- but I know it's possible and I could probably
|
|
cook one up in a few hours using '<tt>netcat</tt>' and/or
|
|
'<tt>expect</tt>' --- there's probably a set of "warez" that
|
|
does this for you.
|
|
</blockquote>
|
|
<blockquote>They might have started a daemon. This might wake
|
|
up periodically and change their password and shell
|
|
back to some setting (we didn't prevent their UID
|
|
from running the <tt>chsh</tt> and <tt>passwd</tt> commands, perhaps
|
|
via an '<tt>expect</tt>' or a <tt>Perl/comm.pl</tt> script).
|
|
</blockquote>
|
|
<blockquote>They might leave in '<tt>cron</tt>' or '<tt>at</tt>' jobs
|
|
to periodically renable their access or as a logic bomb.
|
|
</blockquote>
|
|
<blockquote>If their directory was on a writable NFS volume and they
|
|
can get at any of the hosts that are trusted by that
|
|
NFS server ---- they can put in new <tt>.forward</tt> and
|
|
other "magic" files to do these sorts of things.
|
|
</blockquote>
|
|
<blockquote>There might be other mechanisms that I don't even know
|
|
about. In fact there almost certainly are.
|
|
</blockquote>
|
|
<blockquote>Many of these won't apply to many hosts. However they should
|
|
all be considered.
|
|
</blockquote>
|
|
<blockquote>One potential method would be to remove their line from the
|
|
<tt>/etc/passwd file completely</tt>. Perhaps you'd save it in a
|
|
special file so you could restore it later. I don't
|
|
like that approach since it leaves their files as 'orphans'
|
|
(an <tt>ls -l</tt> command will show numeric ID's for the ownership
|
|
and they will be found by a '<tt>find -nouser</tt>' command).
|
|
</blockquote>
|
|
<blockquote>So, the minimum I recommend to disable an account is:
|
|
</blockquote>
|
|
|
|
<blockquote><ul>
|
|
<li><EM>star</EM> out the password.
|
|
<cwliblockquote>Change the shell to a <EM>binary</EM> such as
|
|
<tt>/usr/sbin/nologin</tt>
|
|
--- DO NOT USE A SHELL SCRIPT FOR THIS! I'd also
|
|
recommend not linking it against any standard libraries
|
|
--- it should use a few direct <tt>write()</tt>'s and
|
|
one <tt>exit()</tt> system calls and that's it!
|
|
(Various magic environment
|
|
variables are used by most any shell and by the
|
|
standard I/O libraries --- these can sometimes be
|
|
overflowed or subverted).
|
|
<li>Change the user's home directory to /home/.graveyard
|
|
<li>Remove any 'cron' or 'at' jobs for that user (or
|
|
review them thoroughly, if there's some reason to
|
|
retain them).
|
|
<li>Kill all processes owned by that user. (Manually
|
|
go through a ps listing or use a command like:
|
|
|
|
<blockquote><code>ps -u | while read user pid rest; do
|
|
<br>kill $pid; done
|
|
</code></blockquote>
|
|
</ul>
|
|
</blockquote>
|
|
<blockquote>Using PAM you can do other things, in addition to this.
|
|
For example you can use the <tt>listfile.so</tt> (module) to check
|
|
a magic file in <tt>/etc/</tt> (one that you create for yourself)
|
|
with the "sense=deny" parameters.
|
|
</blockquote>
|
|
<blockquote>Another thing I personally recommend (at least optionally)
|
|
is to scour your filesystems for files owned by this user
|
|
--- move them all into a "graveyard" <tt>.tar</tt> file.
|
|
</blockquote>
|
|
<blockquote>You can use a command like:
|
|
</blockquote>
|
|
|
|
<blockquote><blockquote><code
|
|
>{ cd / && find . -user $GOING \
|
|
<br>| tee /root/tmp/scourge.$$ \
|
|
<br>| tar cTzf - /home/.graveyard/$GOING.tar.gz } \
|
|
<br>&& cat /root/tmp/scourge.$$ | xargs rm -f \
|
|
<br>cat /root/tmp/scourge.$$ | xargs rmdir 2> /dev/null
|
|
</code></blockquote></blockquote>
|
|
|
|
<blockquote>... this is intentionally simplified (I usually do this by
|
|
hand since I have reason to go through a disabled users files
|
|
to re-assign them to other users. That's appropriate for
|
|
former or suspended employees while it wouldn't be in most
|
|
educational or ISP environments).
|
|
</blockquote>
|
|
<blockquote>The point of this process is to create a "graveyard" file
|
|
that contains <EM>every</EM> file that this user owned. I remove them
|
|
(dangerous if they used degenerate filenames --- this part
|
|
I'm glossing over since I usually manually look over the list to
|
|
catch them and I suggest running a 'skulker' to warn you about
|
|
'weird' filenames anyway).
|
|
</blockquote>
|
|
<blockquote>In most cases I don't recommend re-using user names (for
|
|
several months at least) or UID's (until you've "wrapped around"
|
|
on the UID's). This is a complex issue, but it really amounts
|
|
to avoiding the confusion when you restore from backups, or
|
|
encounter other files (perhaps members from .tar files)
|
|
etc. This is another case where the standard practice for
|
|
ISP's and educational institutions is necessary quite different
|
|
from business and government sites (typically the turn over
|
|
in ISP's and at colleges, etc, is far to quick to worry about
|
|
UID re-use after about one fiscal quarter).
|
|
</blockquote>
|
|
<blockquote>Note: there may be other things you'll have to do in sites
|
|
that use NIS/NIS+ (make sure you update the account entry in
|
|
the master yp maps), and in Kerberos realms (remove their
|
|
credentials on the KDC). I don't know all the details of
|
|
these.
|
|
</blockquote>
|
|
<blockquote>Hopefully I've made some important points here:
|
|
</blockquote>
|
|
<blockquote>Read the man pages. (I have never left it at
|
|
RTFM --- I prefer to tell you which M to F'ing
|
|
R).
|
|
</blockquote>
|
|
<blockquote>Look beyond the first answer. If you'd stopped
|
|
at the <tt>usermod -f 0</tt>, you'd be stumped at the
|
|
first box you came to that didn't have the shadow
|
|
suite installed, or that had a different
|
|
implementation. Likewise with the <tt>passwd -l</tt> (which
|
|
I think is not supported in the PAM suite that came
|
|
with <A HREF="http://www.redhat.com/">Red Hat</A> 5.1).
|
|
</blockquote>
|
|
<blockquote>Knowing about "star-ring out" the password is pretty
|
|
portable --- it works with DES, MD5, and "Big-DES",
|
|
at least. HOWEVER, you have to check on each new
|
|
version of UNIX that you encounter! Try it on a test
|
|
account and make sure you method works. Tomorrow
|
|
someone may implement a Unix passwd scheme that uses
|
|
SHA-1 (the NIST secure hashing algorithm) in some
|
|
way --- possibly with a bug --- that ignores the
|
|
"*'s." A minute's test on each new system is probably
|
|
worth a professional sysadmin's time.
|
|
</blockquote>
|
|
<blockquote>Look beyond the initial question. It sounds like
|
|
you were told to just stop the user from "logging in"
|
|
--- which might lead to an incomplete solution (prevent
|
|
<EM>password authenticated</EM> logins). If the requirement
|
|
is <EM>disable the account</EM> then perhaps you need to do
|
|
more than merely prevent password authentication.
|
|
</blockquote>
|
|
<blockquote>This last point is crucial. Just knowing how Unix and Linux
|
|
work is not enough. Knowing that many sites have the r*
|
|
(<tt>rsh</tt>, <tt>rlogin</tt>, et al) utilities enabled, and knowing that
|
|
a <tt>.forward</tt> file can be used to run arbitrary shell scripts
|
|
with arbitrary side effects; these go beyond just knowing
|
|
how Unix works. More importantly you have to think about
|
|
the implications of these things, and know people who've
|
|
experienced some of them.
|
|
</blockquote>
|
|
<blockquote>Reading the threads on <a href="news:comp.unix.admin"
|
|
>comp.unix.admin</a> for a few months will
|
|
help quite a bit with that. Netnews for all the bad rap
|
|
that it takes and all of the spam it endures, is still the
|
|
largest set of open, ongoing technical discussions in the
|
|
world. The regulars in comp.unix.admin are particularly helpful
|
|
<EM>UNLESS YOU EXPECT THEM TO DO YOUR HOMEWORK</EM>.
|
|
</blockquote>
|
|
<blockquote>Finally: it's more important that you know *how to find
|
|
answers* than how to perform a specific operation. It is even
|
|
more important that you learn how to ask the right questions.
|
|
</blockquote>
|
|
<blockquote>This goes beyond the nitpick (disabling the user vs. his or her
|
|
account) --- and asking "disable access to <EM>which services</EM>"
|
|
(which requires some understanding of all of the services and
|
|
forms of access that are available on the system at hand.
|
|
</blockquote>
|
|
<blockquote>Anyway, good luck on your studies.
|
|
</blockquote>
|
|
<!-- end body -->
|
|
|
|
<!--startcut ======================================================= -->
|
|
<P> <hr> <P>
|
|
<H5 align="center"><a href="http://www.linuxgazette.com/copying.html"
|
|
>Copyright ©</a> 1998, James T. Dennis <BR>
|
|
Published in <I>Linux Gazette</I> Issue 32 September 1998</H5>
|
|
<P> <hr> <P>
|
|
|
|
<!--::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::-->
|
|
<table width="98%"><tr valign="center" align="center">
|
|
<td rowspan="3"><A HREF="./lg_answer32.html"><IMG
|
|
SRC="../gx/dennis/answernew.gif"
|
|
ALT="[ Answer Guy Index ]"></A></td>
|
|
<td><A HREF="tag_phreak.html">phreak</A>
|
|
<td><A HREF="tag_abandon.html">abandon</A>
|
|
<td><A HREF="tag_javaterm.html">javaterm</A>
|
|
<td><A HREF="tag_BBS.html">BBS</A>
|
|
<td><A HREF="tag_flaws.html">flaws</A>
|
|
<td><A HREF="tag_doslinux.html">doslinux</A>
|
|
<td><A HREF="tag_resume.html">resume</A>
|
|
|
|
</tr><tr valign="center" align="center">
|
|
<td><A HREF="tag_softwindows.html">softwindows</A>
|
|
<td><A HREF="tag_convert.html">convert</A>
|
|
<td><A HREF="tag_apache.html">apache</A>
|
|
<td><A HREF="tag_emulate.html">emulate</A>
|
|
<td><A HREF="tag_database.html">database</A>
|
|
<td><A HREF="tag_distrib.html">distrib</A>
|
|
<td><A HREF="tag_proxy.html">proxy</A>
|
|
|
|
</tr><tr valign="center" align="center">
|
|
<td><A HREF="tag_disable.html">disable</A>
|
|
<td><A HREF="tag_DVI.html">DVI</A>
|
|
<td><A HREF="tag_superblock.html">superblock</A>
|
|
<td><A HREF="tag_serial.html">serial</A>
|
|
<td><A HREF="tag_permission.html">permission</A>
|
|
<td><A HREF="tag_detach.html">detach</A>
|
|
<td><A HREF="tag_cdr.html">cdr</A>
|
|
|
|
</tr><tr valign="center" align="center">
|
|
<td><A HREF="tag_rs422.html">rs422</A>
|
|
<td><A HREF="tag_modem.html">modem</A>
|
|
<td><A HREF="tag_notfound.html">notfound</A>
|
|
<td><A HREF="tag_tuning.html">tuning</A>
|
|
<td><A HREF="tag_libc5.html">libc5</A>
|
|
<td><A HREF="tag_startup.html">startup</A>
|
|
<td><A HREF="tag_clock.html">clock</A>
|
|
<td><A HREF="tag_ping.html">ping</A>
|
|
|
|
</tr><tr valign="center" align="center">
|
|
<td><A HREF="tag_accounts.html">accounts</A>
|
|
<td><A HREF="tag_lilo.html">lilo</A>
|
|
<td><A HREF="tag_NDS.html">NDS</A>
|
|
<td><A HREF="tag_95slow.html">95slow</A>
|
|
<td><A HREF="tag_nonlinux.html">nonlinux</A>
|
|
<td><A HREF="tag_progenv.html">progenv</A>
|
|
<td><A HREF="tag_cluster.html">cluster</A>
|
|
<td><A HREF="tag_ftpd.html">ftpd</A>
|
|
|
|
</tr></table>
|
|
<P> <hr> <P>
|
|
<!--::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::-->
|
|
<A HREF="./index.html"><IMG SRC="../gx/indexnew.gif"
|
|
ALT="[ Table Of Contents ]"></A>
|
|
<A HREF="../index.html"><IMG SRC="../gx/homenew.gif"
|
|
ALT="[ Front Page ]"></A>
|
|
<A HREF="lg_bytes32.html"><IMG SRC="../gx/back2.gif"
|
|
ALT="[ Previous Section ]"></A>
|
|
<A HREF="./stemen.html"><IMG SRC="../gx/fwd.gif"
|
|
ALT="[ Next Section ]"></A>
|
|
<!--::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::-->
|
|
</body>
|
|
</html>
|
|
<!--endcut ========================================================= -->
|
|
|
|
|