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 --------------5A78A318C0CC02B6ED889A28 Content-Type: text/plain; charset=us-ascii --------------------------------------------------------------------- To unsubscribe, e-mail: tclug-list-unsubscribe at mn-linux.org For additional commands, e-mail: tclug-list-help at mn-linux.org --------------5A78A318C0CC02B6ED889A28--