Packages (Was: Installing Red Hat)

[Andy Zbikowski <andyzb@ltiflex.com>]

From a quality standpoint, it IS a good thing that you can go out and
install just about every package in debian and not have package X break
package Y, and have everything start up out of the box. 

Debian is pretty strict security wise with their default configurations. I'm
not saying you should trust them entirely though. 

If you are being lazy, yes you can use the -y switch with apt and apt will
answer yes to all the prompts created by the package maintainer. This is a
rather dargerous switch to have, but it can be extremely useful when
combined with the -d switch. 

Example: I can set up a cron job to run
apt-get update (updates the list of available packages)
apt-get -d -y upgrade (downloads upgraded packages, but takes no other
action. -y suppress the X packages upgraded, need to download XXX bytes, do
you want to continue? message)

With that going you'll have your any security updates allready downloaded
when you pull into the office in the morning. Or you won't have to wait for
the download phase when doing an upgrade to the unstable system. This is a
rather useful cronjob if you're running debian unstable on a modem. Set it
to download the new packages while you're asleep or away from home.

> With such a system, I can see a whole new crop of cracker attacks as a
> result of such ever-user-friendly, "plug-and-play"ish packages.

I do belive Red Hat allready experienced this with their update system. One
of their deamons running as root had a default password for every RedHat box
or something. Good FUD material until it was pointed out ummm, MSSQL
defaults to no password on the sa account. 

If anything, the packages from the official debian archives are more secure
then those you compile yourself. Ever look into what it takes to become a
official debian maintainer? It's a lengthy process of meeting (in person)
keysigning, and what not. 

Personally, I'd rather grab my software pre-compiled from the official
debian archives than compile it myself. The end product, as stated before,
is basically the same. The debian source packages are just an added
convience. Yes, I could grab the source from freshmeat, and create my own
debian package OR just install it to /usr/local, but why should I when the
official package maintainer has made it that much easier for me? 

As for the configurations, well, if there was something really icky in a
default config in debian, the package would be updated and thrown into the
security archive or just replaced if it came from the unstable branch. Often
the software doesn't have a default config, but generates one based on your
responses. You are still encouraged to check it out and make sure everything
is ok. 

It almost sounds like you opinion is "I have to go through the code bit by
bit before it goes on my server." Well, if that's the way you like to do
things, fine by me, knock yourself out. Me, I'll take pre-packaged software
when I can get it and compile it when I need to. Maybe I should just shutup
about Linux and go install OpenBSD. :P~

> In contrast, I would encourage the download and compilation of the
> sources.  Aside from what's in the compiler itself, this is total
> control.  As slick as debs or rpms are, I can't help but feel as though
> they're sloppy and a "lazy" method for running (supposedly) trusted
> executables.

There is a certin joy to compiling your own biniaries, but if you don't do
it in a "correct" manner, you're asking for just as much trouble as your are
by answering yes to everything. On systems that do have package managment,
you also risk breaking that package managment. If you're compiling it
yourself, it's best not to install it to /usr but to /usr/local. (The idea
behind local is that this software is specific to your local setup, and
isn't found in the "stock" distribution/package/etc.) You could also use
/opt over /usr/local, but I never really got the point of /opt. Yes, it's
optional. By that definition, everything that isn't the base system should
be in /opt. 

I don't know if you had any issues with the stow suggestion, but I really
like stow. It give you another level of control that you don't get when you
just compile and make install. And it makes it extremely easy to remove
custom compiled software. I haven't encountered anything that broke with
stows methods, even vmware was ok when I forced it to install in
/usr/local/stow/vmware (/usr/local/stow/vmware/man,
/usr/local/stow/vmware/bin, /usr/local/stow/vmware/doc,
/usr/local/stow/vmware/lib, etc...) I had to change the path at every
prompt, but I won't spend more than 10 minutes tracking down every file it
installed should I ever want to remove it. 

If you want no package control what so ever, feel free to choose slackware.
It's package managment gets to job done, but compared to an RPM or deb based
system, pretty ruidmentry. I can see the appeal there if you're installing
say, one server and you want it to be secure and you don't want anything you
don't absoutely need. If you get into mutiple servers/workstations,
managment/version control/etc are necissities in the eyes of most. 

There is yet another advantage to package managment systems. The public
servers I have here are bare minimum. No compiler, no libiaries and the
like. With debian's make-kpgk tool I can easily compile new kernels for
these servers on my workstation and scp the resultion deb to the server for
installation. 

Hmmm, enough for now me thinks. =)

-- 
Andy Zbikowski, Sys Admin   | (PH)  763-428-9119 (EX:132)
LTI Flexible Products, Inc. | (FAX)  763-428-9126
21801 Industrial Blvd       | (PCS) 612-306-6055
Rogers, MN  55374           | (WEB) http://www.ltiflex.com
begin:vcard 
n:Zbikowski;Andrew
tel;pager:612-306-6055
tel;cell:612-306-6055
tel;fax:763-428-9126
tel;home:763-591-0977
tel;work:763-428-9119
x-mozilla-html:FALSE
url:http://www.ltiflex.com
org:LTI Flexible Products;Information Services
adr:;;21801 Industrial Blvd.;Rogers;MN;55374;USA
version:2.1
email;internet:andyzb@ltiflex.com
title:Computer Systems Administrator
x-mozilla-cpt:;-13248
fn:Andrew Zbikowski
end:vcard