RE: [vox] Zen and the Art of System Maintenance
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [vox] Zen and the Art of System Maintenance
Hey Bill, I completely missed your comment on this until this time
around... :-P Yeah, yeah, yeah. I am around, just busy working. :-)
Comment about these posts included below.
(This was a message that required a lot in the way of a response, and if
you thought my other posts were wordy...)
On Thu, 28 Mar 2002, Steven Peck wrote:
> You know, I've actually wondered that sometimes myself. I have a remote
> shell account on a friends Linux box that is very handy sometimes. Now
> I use X-Window over ssh to get to it. He hasn't updated Mozilla for a
> WHILE. It was convient for me to download and set up the newer version
> for myself in my home directory for my own use till he gets around to
> updating it.
> So, from a general system point, I suspose it would be better to
> 'upgrade' the package for 'all users' even if you are the only one. You
> never know when you are going to have company and want to setup an
> account for them to browse the web and get their email and such.
> Then again, this is only an observation. I don't admin Linux systems in
> a work envirnment.
I would install a new packaged version for all users too. There was a time
where I would not install any packaged version, but instead go out and get
it myself and then install it on my own.
Of course, I cant live that close to the edge with the NC Server and its
export ed filesystem for 80+ nodes to use as their NFS root. If I install
a new version of Netscpae that has a bug, I have 80 buggy machines
complaining at me. For this, I will test out new updates on other machines
before making it the new default.
Other applications are not as kind as Netscape with old prefs. Also, you
run the risk that the new package will not follow the same rules as the
old package. (Maybe it will look for config files in a diff location, or
ignore user's based config files due to a security hole.)
Ever since I migrated from the old ssh.com's sshd to openssh, I do not use
the packaged openssh or openssl servers. I dl and compiled my own openssl
and then openssh for each security update. This allows me to specify what
options I wish to use, and not worry about how the packaged one may or may
not work. This can be more work, but from the time I see the announcement
on BUGTRAQ about "security hole XYZ" is openssl or openssh, to the time my
server is running the newest patched version is frequently less than an
hour - if that.
(more comment after the response to the next post...)
> -----Original Message-----
> From: email@example.com [mailto:firstname.lastname@example.org] On
> Behalf Of nbs
> Sent: Friday, March 22, 2002 10:21 AM
> To: email@example.com
> Subject: Re: [vox] Zen and the Art of System Maintenance
> On Fri, Mar 22, 2002 at 07:47:27AM -0800, Richard S. Crawford wrote:
> > I'm beginning to see that maintaining a Linux box, even if it's just a
> > single-user environment, is as much an issue of philosophy as it is
> > technical. Where do I install new applications? Should I install
> > version of Mozilla as root or in my user account only? ...And so on.
> > Since the only background I have that even remotely resembles system
> > administration is in Windows, I don't have much experience maintaining
> > Linux box. What are some good resources for learning the more
> > philosophical, aesthetic, and ethical issues of maintaining a *nix
> Hopefully someone will actually answer your question?
> Where'd Mike Egan wander off to? :)
Hey, I am right here. Just been very busy and did not have time to answer
many questions that would take a lot of work to try to answer. (And this
question has that potential... probably why other have not posted many
answers either. ;-)
For the immediate question:
If you are deciding to go with a packaged version of netscape(*.deb, *.rpm
etc), let the package install it where it was coded to install. If you are
installing your own copy separate from the system, a common location is
/usr/local (in this case, netscape likes its own dir like
/usr/local/netscape .) Many other applications I install for users I
install is /usr/local/bin or /usr/local/sbin (mostly admin stuff there)
and libs /usr/local/lib with src in /usr/local/src and /usr/local/man for
man pages. The advantage in installing stuff in /usr/local is most (if not
all) Linux distros will NOT install stuff by default into /usr/local. This
helps prevent a system install from overwriting a custom install.
Implementing search dir order will also allow you to have two copies of a
thing installed and have your /usr/local stuff be first to be executed by
making sure your PATH has /usr/local/bin before the others. (Having two
different version of the same application/service is not considered a good
idea in most situations. There are cases where it is wise to have more
than one version of an application install.)
As for choosing to go with compiling your own or wait for a new package,
it depends on you as an admin and the item in question. If an item is
being updated frequently, you may wish to rely upon the built-in packaging
updates. If the updates are slow in coming, you may wish to build your
own and leave /usr/local/bin last in your search PATH so when the new one
comes out. (You should note packages often are not as frequently
created/released as the source code trees - especially with cvs based
I'll try to sum up the utilitarian history of the *nix admin as it will
give you some idea where people's mind were, and hopefully allow you to
get a grip on where they might be going:
Make tools as general purpose as possible (for integration with I/O), but
specific as possible to avoid bloating. In this way, you can acquire and
build very small tools that are each good at one thing. Simple early
examples: cat, cut, echo, more, less, most, bc, tr, sed, ls, and du (Just
naming a few. (Of course perl, and emacs violate this rule, but they are
considered "exceptions" heh.)
A dumbass example might be finding the total space claimed to be used by
all files from the present directory forward...
Taking from the above, you can build:
$ echo `ls -laR | cut -c32-43 | tr -d " " | tr '\012' "+"` \
| tr -s "+" | sed -e 's/^+\(.*\)+$/\1/;' | bc
(The "\" at the end of the first line can be removed if you join the
second line to the first without pressing RETURN.)
The output of the first becomes the input for the next for each "|" in the
pipeline. The above example is rather "dumb" because a small tool
specificly designed to do the above allready exists:
$ du -sb
and it does a much better than than my example above anyway (You'll note
my example produces an answer that is not quite accurate anyway. ;-)
This brings us to a second item in *NIX administration:
There is more than one way to do something, and each method may offer
different results. There is more than one way to skin a cat, or as I
"Q: Do you know how to quiet a cat? "
A: You pipe it more."
Some may imagine a snarling cat in an alley with an insane madman running
after it with a lead pipe to silence it forever. Others may just see:
# This is noisy and does not stop...
$ cat /dev/urandom
# So, I'll quiet it down:
$ cat /dev/urandom | more
OK, too much work for a stupid joke.
Use the Source... When possible, try to only use products where you have
access to the source code. A skilled *NIX admin can compile projects and
older ones could modify a Makefile to match their system's settings
(before autoconf/config) and older admins could write their own makefiles,
while even older ones would port a project for one system/arch over to
their OS and add entries in a new makefile for options to compile on one
system or the other. ( I remember when I found my first project with a
Makefile that included instructions on what options were for what systems
and allowed to only go through and comment in/out what was relative to me,
but do so in JUST ONE MAKEFILE! Woohoo! You can believe how floored I was
when I saw autoconf/configure work for the first time....
This does not mean you *should* compile all of your stuff by hand. It
means you should try to avoid installing things that you dont have access
to source code for you to fix problems that you may have.