The Debian Way - debian grimoire - groups

These things are related to maintaining a good Debian server, not a personal development machine, or desktop etc. Rather these are the criteria that should be used to keep a Debian server both sane and solid.

Use the current stable release, and keep it up-to-date.¶

Using a current stable release means installing the latest stable release from scratch, with minimal packages (don’t use tasksel to install a profile). Installing only those packages that you need, removing those that you don’t need. Only install packages from stable, and if necessary stable-backports. Never mix in testing/unstable packages with a stable server. Try to only install packages, that means don’t do a ./configure; make; make install, cpan, etc. these will spew things all over your filesystem, potentially overwriting the contents of your debian packages, which will lead to an unstable machine.

If you need to install something when there is no stable package, consider doing these things (in order):

0. understand the difference between the different debian suites, know what old-stable, stable, testing, unstable are and how packages transition from one to the other. Know the difference between lenny, squeeze, wheezy and sid. Know how backports are related to packages, know how security package updates work. These are fundamentals that you will need in order to understand the right way to do things on a debian system.

1. learn what the FHS is, and where things should go and how the FHS should work. You need to know this so you dont step on things in the dark.

2. see if there is a backport in debian-backports, and then use that.

3. if there is no backport, consider requesting one, or making one yourself and asking a debian friend to sponsor the upload

4. if sharing that package with backports doesn’t make sense, make a package yourself and put it in local apt repository and install it from there. learn how to make debian packages this is a skill that is extremely valuable!

5. if there is no package to update, see about making one, always consider sharing with the wider community by potentially maintaining it as a package in debian. remember, sharing is caring (you do NOT need to be a debian developer!). Its really easy to make debian packages out of perl and ruby libraries, its just a matter of running dh_make_perl, debpear, or gem2deb. Remember that the entire debian system that you are benefiting from running comes from people like you who have contributed their work to help others. Give back, so you can continue getting.

6. if making a package is too difficult, or its a one-off or you can’t care enough to share, then build the package in such a way that it wont mess up your system. This should be a last resort, but if you must, then use checkinstall to easily build a package that you can later remove all traces of from your system. When doing this, be sure that checkinstall isn’t going to write things to system directories, which may overwrite files/libraries/binaries from packages (ie. make it install to /srv, /opt or /usr/local)

7. if something like checkinstall is not possible, and a ./configure; make; make install is necessary, then make sure you take care to specify the base paths to configure so it will put things in /usr/local, or if necessary /opt.

Keeping it up-to-date means installing security updates as soon as possible, and installing stable point releases when they come out. Subscribe to the security-announce mailing list, and debian-announce to get the latest information. If you are using backports, subscribe to the backports-announce list to make sure you are aware of security issues in backports. Backports aren’t automatically upgraded, so you need to take special care here. If you’ve installed something outside of debian packaging systems, then you need to pay outside attention to that particular bit of software to make sure you are on top of its security.

Learn about the debian security tracker, how its used and updated, and potentially contribute, you dont have to be a debian developer.

File bugs, otherwise it will never be fixed. Send patches because that will get it fixed faster.


anarcat 2012-06-23	I usually install stuff in /usr/local, if installing from packages is too hard. I consider /srv belongs to a huge pile of storage where my data lives, not my software. /opt is confusing to me. I can see a use to tasksel and profiles, especially if you do not have Puppet-like configuration management. It is a good way to setup simple servers, and you can make your own profiles. This is the way I manage servers at home. Here’s my tasksel file: anarcat.ath.cx/software/mytasks.desc We install security updates automatically with apticron (for notifications) and cron-apt (for actually installing them), we wish that we would switch to unattented-upgrades. There are tons of other policies we have, I don’t know where to start.


taggart 2012-06-23	Here’s a document I wrote that describes how the FHS works lackof.org/taggart/hacking/FOSS-build anarcat’s suggestion of using apticron/cron-apt should be listed in the above document. maybe a “how to keep the system clean” section would be good too, we wrote some stuff for the riseup “squeeze upgrade checklist” that could be adapted. a short “how to report bugs” thing would be good. one key to maintaining a stable debian system is making sure the hardware is solid to start with, I have been meaning to write a “hardware burn-in and testing howto” Should I write these things? A lot of this info isn’t debian specific, I’ve been wondering lately if the debian grimoire should be made more generic…


Daniel Kahn Gillmor 2012-06-24	hardware burn-in and testing howto would be a really great thing to have. I’d be happy to contribute to it.


Micah 2012-06-26 2012-06-26	/opt is confusing to me. Thanks for the note about that, I got lazy at that point in the writing and didn’t clarify and just put down /srv, /opt and /usr/local. I agree that /usr/local is where that stuff should go, and /srv is for what you describe. I changed that. /opt is confusing is enough reason to avoid it in general. I think that /opt has historically been used by vendor installations, which typically means proprietary software installs. For example, those install blobs that you download, make executable and then run and it makes you agree to a license, and then does something mysterious in the background. When you look at the shell script, its got a base64 blob embedded in it that is extracted during the install. I agree with you about tasksel, I just think that accepting the tasks that are presented to you on debian install without knowing what they install results in packages on your system that you may not actually want installed. So I think if you are going to use tasksel, you should be very aware of what is being installed for you, perhaps by building up your own tasksel profiles like you did.


Micah 2012-06-26	taggart: I added your FHS link to the above. the ‘how to keep a system clean’ would be a good page to link to. i guess the relevant parts of the squeeze checklist could be turned into its own page and then link to it from here. i am sure there is a good document on how to report bugs somewhere. if someone has a suggestion, please add it! as for hardware burn-in (and I would also suggest responsible tear down!) – I think a page on that would be really helpful. I think there is a lot of generic things in the grimoire that aren’t debian-specific, so don’t let that stop you.


gdm 2012-07-10	some more info on how to package would be good! ;-) i really don’t know, and every time i’ve tried to figure it out i’ve just got more confused. particularly, i didn’t know any of the basics like how to write a makefile for really simple things (i.e. not c compilation), and i didn’t even know enough to figure out how to find proper help anywhere…. i heard there were some (a?) good tutorials (or maybe even videos) written since i last looked that go through package creation step-by-step, but i don’t know exactly where they are. any help appreciated!


dpdt1 2013-01-25	any recommendations (pro/against) on using the dotdeb.org repo ?


davedsp 2013-10-06	@dpdt1 nothing against dotdeb in particular (I didnt know it), but I would recommend against using third-party repositories unless absolutely necessary. It increases the attack surface, you have to trust the repo owner not to upload packages that have security vulnerabilities. Even if you trust them, are they able to keep their repo uncompromised (are the package lists signed? can they keep their private GPG signing key secure? do they review the packages they upload?). I used to get packages from debian-multimedia which is still sometimes useful, now I have disabled it completely and removed their signing key from /etc/apt/trusted.gpg.d/. If I need a package from there, I’ll simply get the .deb from the repo and install it manually. There are many good repos out there for themes, unoficially packaged stuff but I prefer doing it this way. You’d be better filing a Request For Packaging for the packages you need (see www.debian.org/devel/wnpp/) or build them yourself. @gdm I found some info on wiki.debian.org/IntroDebianPackaging and wiki.debian.org/PackagingTutorial. There are slides from debian developers about debian packaging but I can’t find them right now. About keeping the system up to date, what about recommending unattended-upgrades. I use it on my home server box and it has never failed me.