Beyond Debian
When the "best" distro just isn't good enough
Medlemsmøte i NUUG Oslo
13 Nov 2007
About me
- Involved with the project since 1997
- Debian developer since 2002
- Concentrate on workflow, process integration, quality assurance
- Ph.D. student with Prof. Brian Fitzgerald at University of Limerick
- Researching development method innovations in the Debian project
- 28 years old, born German, living in Zurich, Switzerland
- Self-employed external contractor, IT controlling
- Network security trainer to the "professional" audience
Beyond Debian?
I conferred with
- 3 other developers
- 5 normal users, 2 industry users
- 1 Fedora developer
- 2 Gentoo preachers
The result?
Debian is omnipotent!
Thus, we're done!
Thanks for showing up!
My experience
- madduck.net
- 23 servers around the world, most of which I have never seen
- maximum of 500 users, no charge, any service they asked for
- 40 node cluster doubling as student robotics laboratory
- University mail server administration with ~1/4 mio. mails/day
Beyond Debian!
- System administration
- working with unpackaged software
- permissions management
- managing configuration with version control
- maintaining multiple systems
- backing up
- Packages
- alternative package sources
- when the Debian package does not meet your needs
- What Debian cannot do
Debian for sysadmins
- Flexible, universal tools
- Preserves your configuration
- Extensible configuration paradigms
The ideal in system administration is to do as little as possible
System administration
- working with unpackaged software
- permissions management
- managing configuration with version control
- maintaining multiple systems
- backing up
Unpackaged software
- E.g. Firewall-1, Oracle, VMWare, trunks, …
- ./configure --prefix=/usr/local && make all install
- "Pollutes" /usr/local (or /opt)
Stowing software
- Install software with --prefix=/usr/local/stow/something
- GNU stow maintains a symlink hierarchy from /usr/local/* to the stow
directory
- Uses installed footprint to uninstall
- Prevents overwriting files, but not really suitable for multiple software
- xstow aspires to improve upon stow but I could not get it to work
- Easy to use, even in scripts:
Example: stowing git
#!/bin/sh
cd ${0%/*}
git pull
(cd /usr/local/stow && stow -D git)
rm -rf /usr/local/stow/git
make clean install install-doc prefix=/usr/local/stow/git
(cd /usr/local/stow && stow git)
Integration with Debian
- dpkg-divert — safely replace (non-conf)files under Debian control
- update-alternatives — integrate an alternative (e.g. browser)
- dpkg-repack — repackage software with tiny changes (don't)
- checkinstall — record installations into packages (don't)
- alien — install/convert foreign packages
System administration
- working with unpackaged software
- managing configuration with version control
- maintaining multiple systems
- backing up
Permission management
dpkg "enforces" (overwrites) permissions at install time
Sometimes you want different permissions, e.g.:
# dpkg-statoverride --add --update root wheel 4754 /bin/su
# ls /bin/su -l
-rwsr-xr-- 1 root wheel 25284 2007-10-30 19:32 /bin/su
by registering a "stat-override", you tell dpkg to respect your wish
ACLs
- Advanced access control: give access to multiple users/groups
- Package acl
- VFS feature, thus supported by ext3, xfs, razorfs, jfs
Example: ACLs
# setfacl -R -d -m group:webmasters:rwx /var/log/apache
# setfacl -R -m group:webmasters:rwx /var/log/apache
# chmod -R ug=rwX,o= /var/log/apache
# ls -ld /var/log/apache
drwxrwx---+ 2 root root 4096 2007-10-28 21:28 /var/log/apache
# getfacl /var/log/apache
# file: var/log/apache
# owner: root
# group: root
[…]
group:webmasters:rwx #effective:r-x
mask::r-x
[…]
default:group:webmasters:rwx
System administration
- working with unpackaged software
- permissions management
- managing configuration with version control
- maintaining multiple systems
- backing up
Keeping /etc under version control
- no VCS I know tracks permissions
- FAI softupdate
- etckeeper
- Hooks and a local repository
FAI softupdate
- Extra indirection, makes testing difficult:
- keep a set of idempotent cfengine/perl/sh scripts under
version control
- run fai-soft-update and let the scripts update the system
- Records actual actions instead of changes
etckeeper
- Integrates metastore with git, thus allowing permissions to be
tracked (insecurely)
- Hooks in with APT and allows tracking of changes by packages
- Non-modular tracking (yet)
Hooks and a local repository
Keep a (git) repository in /srv/gits/etc/postfix
Make post-receive hook call make or ./update.sh
Write script to fix permissions and do other things, like postfix reload
If you are interested in this sort of thing:
http://lists.madduck.net/listinfo/vcs-home
System administration
- working with unpackaged software
- permissions management
- managing configuration with version control
- maintaining multiple systems
- backing up
Maintaining multiple systems
- FAI — automate and maintain installations
- apticron — report available updates (if you don't already use e.g.
nagios)
- cssh — run commands on multiple systems in parallel
Backing up
- Backups á la Debian: backupninja
- prepares backups for e.g. rdiff-backup
- modular, enable modules by putting configuration file in place
Packages
- alternative package sources
- when the Debian package does not meet your needs
Stable vs. outdated
- Debian is stable, rock-solid, and "outdated"
"Look, this is Debian. They don't release things until you have to fire
rockets at the thing to stop it from working." (Slashdot quote)
and
"Debian releases are out of date the minute they are published" (common
prejudice)
Alternative package sources
- Three can be used in most production environments:
- Security updates (official)
- Volatile archive (official)
- Backports (semi-official, needs pinning)
- Packages provide minimal updates
- Integrate well with current and next stable
Pinning
- APT selects upgrades based on pin priorities
- Installed: 100; update available: 500; target release: 990
- Never upgrade: <= 0; Downgrade if needed: >= 1000
- Three ways to pin:
- /etc/apt/apt.conf (APT::Default-Release "testing";)
- /etc/apt/preferences
- aptitude -t testing install …
Example: /etc/apt/preferences
#Package: *
#Pin: release a=etch-backports
#Pin-Priority: 1
Package: mdadm
Pin: version 2.6.2-1~bpo.1
Pin-Priority: 600
Package: molly-guard
Pin: release a=etch-backports
Pin-Priority: 600
Packages
- alternative package sources
- when the Debian package does not meet your needs
When the Debian package does not meet your needs…
- You think a different default setting makes sense?
- You require different compilation flags?
- You want to spawn a second daemon instance?
- You need a non-interactive mode for a tool?
- …
… rebuild it!
This is Debian:
- Download package source
- Make the required change(s)
- Log your change(s)
- Rebuild the package
- Write a wishlist bug with your change
pbuilder
- "Chroot management made easy"
- Helps find problems related to the build process
- Keeps the system clean
Tips for submitting wishlist bugs
- Read:
- Explain your use case; show how you came to conclude your solution was
necessary
- Never change the default: make your change optional and default-off
- Keep the patch to an absolute minimum
- Licence your patch, or put it into the public domain
When to become a Debian developer?
- No easy answer, anymore: alioth, version control, Debian maintainers
- When you know you could be more efficient with what you are already doing
if you were DD, mainly cross-package work
What Debian cannot do
- differing compilation flags
- … ???
Thank you
Thank you for your attention!