The Debian-Med CDD was started in January 2002 and has evolved a lot
since this time. Debian now becomes the distribution of choice for
people who are working in the field of medicine. On the one hand this
can be obtained from the increase of pure numbers of packages in the
field of medicine.

On the other hand - which is even more interesting for general Debian
development - a group was formed that has developed a certain way of
cooperation which might serve as an example for other teams. Debian
knows a lot of technical teams focussing onto technical issues
(pkg-perl, pkg-python, d-i, etc.). An important part of the project is
to involve people who call themselves "pure users" or "non-developers"
(whatever this might mean) as it is done at a certain amount by the
i18n and Debian Edu team.

So this talk is not about boring the audience by mentioning medical
Free Software - it exists at a certain amount out there as other
specific software does as well - but rather how to attract people to a
topic where FLOSS is not common but should. It will give examples for
our way to advertise Free Software in medicine which is heavily
dominated by proprietary software, which tools we developed inside the
CDD framework to be always up to date with our web pages that are
intended to attract users to Debian and last but not least the lessons
we have learned in the project that might be of high interest for
other CDDs (or potential CDDs). Examples are given for project
management, attracting people by working techniques and making sure
that medical software finds a good home in Debian.
Full event details

Maintaining one of the largest set of packages in Debian, the Debian Perl Group
needed a tool for sorting the work, showing progress made by other
members and easing the sponsoring of uploads, as many active members of the
group aren't DDs.

Based on previous ad-hoc scripts, PET was written almost from scratch with the
idea of making it usable by other packaging groups, and it even is useful
for individuals tracking their own packages. It separates completely
presentation from data retrieval, and its modular structure allows to create
easily new sources of data and checks. (For more information, see
http://wiki.debian.org/Teams/DebianPerlGroup/DebianQA)

Today it helps a small group of people maintain over seven hundred packages (we
passed the 666 mark recently, so the joke is already old) without going insane.

Main functions:
* track new upstream versions
* show which packages prepared by non-DDs are ready for upload
* highlight several problems with packages and repo organisation
* follow uploaded packages' journey to the archive
* and lots of information packed in one place

This talk will introduce this tool, show how it's best used and a bit about its
internals so you can customize it (and contribute patches!).
Full event details

Dear Lazyweb, I'm a permanent resident of one country, but I'm representing the interests of another one as a part of my job. Anyhow, I'm constantly traveling, so I cannot consider myself as having a residence anywhere in particular. Still, the health insurance and taxation offices of the country where I'm registered as a resident are constantly annoying me with requests for additional clarifications about "working abroad" (trying to imply that I might have relocated to the country where my employer has their head office), which is a complete waste of my time, because the previous explanation is never good enough for them and they keep on twisting every word I say. I was thus wondering if someone ever found a way to not have any official place of residence anywhere and still be able to get visas for the countries they need to visit and also be able to rent apartments in the countries that they visit the most frequently without ending up with residence permits for each of them, so as to avoid the above mess with multiple jurisdictions? This question is not about evading taxation. It's about finding a solution to avoid wasting time constantly filing paperwork just because the bureaucracy cannot understand a situation where someone's lifestyle doesn't fit the traditional model of living and working in exactly one city.

I just had this crazy idea about solving snapshot.debian.net's space issue which just might work if done right.

We all know that snapshot.debian.net has ran out of space in early May this year and we all lost a valuable service. Since there are probably many users, developers and maintainers which find this service useful, it might make sense to think that the users themselves could solve the problem.

How? Think about implementing a really distributed storage/file system (not necesarly a real file system) that can rely on cluster nodes that can enter or exit at any time and the nodes are contributed by users, very much alike the GoogleFS file system (or maybe clients in a torrent swarm).


First problems that I can already see:

• there must be some indexing service that should run 24x7 to manage the information about the blocks which are desired.
• some data should always be kept on a trusted machine - the gpg signatures, the Packages files indexing information and meta data
  
• there might be a security risk involved since data would be stored on untrusted machines, but a sha1/md5 check in colaboration with the gpg signature should be enough (which isn't always doable - see large packages like openoffice.org or game data packages); if there are reasons why this might not be secure, maybe we need to rethink a little about the dpkg-sig package and see if we can get all the packages in the archive to be individually signed when entering the archive, or something of that sort
• the meta-data of the FS cluster might be really big, but my gut feeling tells me that it won't be as big as the current snapshot.d.n storage
• when a file is requested, the file needs to be cached on a central server so it can be assembled and its checksum be verified before being delivered to the client requesting it
• people might donate really little space compared to their usage
• some nodes of the network are special and this could lead to the failure of the entire infrastructure in case the special nodes fail; some of these nodes might turn out to need really big muscles
  
• some data might be unavailable at times depending on the clients connected to the network at different points in time
• in an attempt to create more copies of a block in more nodes in the network, a DoS might be triggered if many clients request the same info from a (set of) node(s) containing the rare info - still torrent's way of workig seems to cope quite well with that model
• none of this is implemented and probably I won't do it myself, although it could be a really nice project, even it is doomed to fail from day 1
  

Other ideas:

• maybe it would make more sense for the FS to actually be an ever-growing torrentt which people can connect to via some special client which would allow pushing to the clients in order to store information
• the number of copies of a file (or chunk of a file) in the distributed storage should be higher for more recent packages and lower for older ones (still one copy might be necessary to be stored on safe nodes - aka controled and trusted by debian so the information doesn't get lost - back to our current storage problem)
• probably the entire thing could be built somehow by piggy-backing the current apt-transport-debtorrent implementation or debtorrent, or apt's cache - the idea is that although not all files might be available, some people might still have relatiely recent packages files in their apt cache
• such a system, if done right, might prove to be usable as a live backup system between different nodes in the cluser, so it could be used in other situations by individuals, without the need of a central server - think trackerless trorrents
  

What do other people think?

Some time ago, when I packaged treeline, I wanted to make the package configure the environment so that .trl files would be automatically open with the program. That meant that the package had to configure the MIME types in the desktop to handle that, and assign the new MIME type the selected program. I tried a dozen of things at the time, based on a lot of howto’s that I found, without any success, so I decided to forget about it. This week I started packaging a new program: L ve, a 2D game development framework based in Lua and OpenGL. Many of the games developed for this platform are distributed as a zip file with the extension .love, so I decided I wanted to try again the MIME stuff. After many unsuccessful tries, I found a package that gave me some hints on how to do it: chemical-mime-data. After having a look at it, I was able to prepare a proof of concept that did what I wanted. It is supposed to work, at least, in GNOME, KDE and ROX. In case someone else is interested, here is the code:

• mime-example_0.1-1.dsc
• mime-example_0.1-1.diff.gz
• mime-example_0.1.orig.tar.gz

I am so happy that someone, Phil Lapsley to be exact, is writing a proper history of phone phreaking. Find out more here. Oh and here is something else you should check out: Project MF: "Project MF is a living, breathing simulation of analog SF/MF telephone signaling just as ...

Some people wonder how I develop and manage various features and their requests for awesome.

Yesterday, I was rummaging in my backpack, to make space for a few things I wanted to put in there and that I wanted to take along with me on the daytrip. As I was doing so, I found I'd forgotten to remove a knife from it before leaving for Argentina. Not just any knife, mind you: Yet with this monster in my backpack, I managed to pass security in Brussels International Airport with no issues. At all. Luckily I didn't have to go through security a second time on a different airport, or I might have been in serious trouble. By their own rules, however, they failed. Utterly.

• You don't want me to post pictures of you, yet you post a movie of me dancing. So there.
• You post a movie of me dancing in a format my PowerPC-based laptop can't read.

Please, pretty please, with sugar on top, convert it to Ogg Theora. Thanks, The Management.

Unfortunately, Matthew is correct, and it seems that Ryan Farmer is the idiot that signed a few of us up to about 200 mailing lists this morning. Not only do I trust Matthew's analysis (and was watching him go through the various steps on IRC as it happened), but then there were two other bits.

Ryan refused to approve two of my comments I made on his latest blog entry (more than happy to screenshot this). He claimed he too had been spammed, and had to abandon his email address of a few years. Even if you ignore the length of the text blanked out in the title bar not even remotely matching the length of his personal email address, there were only 131 messages in the inbox, of which 127 were unread, and no others but spam visible. He claimed they were archived; I offered to publicly apologise if he'd do a quick screencast showing him logging into that account and showing some messages from the archive to prove the point. Unfortunately he didn't bother approving these comments. (Incidentally, if you had to 'abandon' an email address due to an avalance of newsletters, et al, which took an hour or two to fully unsubscribe from, would you still bother blacking out the address everywhere?)

As per his standard 'insult everyone with random images from the internet and YouTube videos, then wildly claim conspiracies against him' policy, he went on to claim Matthew was conspiring against him, but given the choice between Matthew conspiring and severely irritating a few of his friends in the process, and some scorned 16-year old continuing his track record of acting like an irrational, immature idiot, I know which one I'd pick.

It takes some skill to be banned from all the Ubuntu IRC channels and the Ubuntu forums both, but I guess this morning showed that was completely justified. Apologies to everyone waiting on the announcement of sponsorship for XDS, as well as hotels, but unfortunately some people just can't conceive of having better things to do than acting like chavs. Hopefully IzanbardPrince/TheAlmightyCthulu/etc goes back to impersonating Kevin Carmony, flaming the bejesus out of companies using BIOSes which trip Linux bugs, and other, equally productive, uses of his time.

This is part 1 of a series on articles about the Firewire security issues mentioned below. For many years now, attacks via Firewire / i.LINK / IEEE 1394 have been a known security issue. Basically, if you gain physical access to a PC or laptop which has Firewire ports (or PCMCIA/Cardbus/ExpressCard, more on that later) you can

• read arbitrary RAM contents from the victim's system,
• overwrite arbitrary RAM contents with whatever you want,
• and perform many, many severe attacks based on the two issues above. Examples include grabbing a full RAM dump via Firewire (takes only a few minutes), grabbing ssh-agent keys, grabbing screen contents, modifying screen contents, bypassing login/password screens, and many, many more...

All of this is done by exploiting a "feature" of the Firewire spec (OHCI-1394) (PDF), namely that it allows read/write access to physical memory (via DMA) for external Firewire devices. Worse, as this is DMA, the CPU/OS will not even know what's going on. Even worse, this works regardless of whether you have locked your screen with a password-protected screensaver, or xlock, or vlock, or whatever. As long as the system is running, you're vulnerable. In this article, I intend to give a fairly complete overview of the available papers published on this issue, tools for testing the attacks, as well as mitigation techniques for various OSes. If I'm missing some important papers or tools, please post a comment! Papers, Attacks, and Tools Over the years a number of presentations and papers have been released with information about these Firewire issues. Maximilian Dornseif et. al. The first publication that I know of was done by Maximilian Dornseif, Michael Becher, and Christian Klein. They gave a number of talks on various security conferences on this topic:

• Pacsec 2004: 0wned by an iPod (PDF)
• 21C3: Hacking with Fire / Feuriges Hacken - Spa mit Firewire (PDF)
• Cansecwest 2005: Firewire: all your memory are belong to us (PDF)

They also released a number of tools, Firewire libraries for Mac OS X and Linux, as well as small demo scripts which use those libs:

• pyfw-20041111.tar.gz: Mac OS X Firewire bindings for Python, various demos
• http://c0re.23.nu/c0de/pyfw/: Other versions of the above code
• pyfw_linux.tar.gz: Linux Firewire bindings for Python (can be used with above demo code on Linux)
• ipod-linux-pyfw.tar.bz2: Instructions (+ disk image) on how to turn your iPod into a Firewire attack tool

Adam Boileau In 2006 Adam Boileau (a.k.a. Metlstorm) gave a talk called Hit by a Bus: Physical Access Attacks with Firewire (PDF) at Ruxcon 2006. In 2008 he then released a set of tools:

• pythonraw1394-1.0.tar.gz: Python bindings for libraw1394 (Linux). Tools: businfo, romtool, 1394memimage
• winlockpwn: Python script which can circumvent a locked Windows XP screen (an arbitrary password will log you in)
• bioskbsnarf: Grabs/shows the BIOS keyboard buffer via Firewire (which often contains your BIOS password)

Peter Panholzer As of early 2008 Peter Panholzer from sec-consult.com published a two-page whitepaper which says they were able to run a winlockpwn-like attack on Windows Vista via Firewire. There's not much information in the PDF unfortunately, and no tools were released, as far as I know.

• Whitepaper: Physical Security Attacks on Windows Vista (PDF)
• Bugtraq Thread about the whitepaper

David R. Piegdon The most recent toolset and papers I know of are from David R. Piegdon (a.k.a. IosTrace), who gave a number of talks in 2007/2008 about the issue, and also released a toolset called SEAT1394.

• 2007: OpenChaos: hacking in physically addressable memory (no extra slides)
• Easterhegg 2008: FireWire Hacking: paper (PDF), slides (PDF)
• More papers here...
• http://0null.net/software/SEAT1394/: tools and libraries for pyhsical memory access via Firewire/DMA: 1394csrtool, liblinear, libphysical, debug-sshkey, dump-memory, remote-ps, show-stack, snarf-sshkey, test-all-pagedirs, dmashell, ...

I'll go into much more detail on how the tools are used and what they can do in another follow-up article. Mitigation There are ways to eliminate or at least mitigate these attack vectors. The simplest and most secure way is to not have any Firewire ports installed (don't put Firewire PCI/PCIe cards in your PC, don't use Firewire PCMCIA/Cardbus/ExpressCard cards). Now, if you have a laptop with built-in Firewire ports, you have a problem, of course. In that case you could still physically destroy the port (by opening the laptop and cutting/desoldering stuff, or by putting glue/epoxy in the port in order to prevent any Firewire cables being attached). These are slightly drastic (but effective!) measures. Note: Even if you don't have any Firewire ports, you're not automatically safe and secure. If your laptop has a PCMCIA/Cardbus/ExpressCard slot, an attacker can simply insert a PCMCIA Firewire card (for instance) in that slot. Chances are, that your OS will automatically load the driver for that card and also the Firewire drivers you'll need if you want to use the card for attaching Firewire devices. Game over. Your "secure" laptop is now vulnerable... If you cannot (or don't want to) remove/destroy/disable your Firewire ports, the next best thing is to ensure that nobody except yourself ever gets physical access to your PC/laptop. This is hard to do for a PC, and almost impossible for a laptop, mind you. Finally, there are some software measures you can use to prevent at least physical DMA access for Firewire devices: Mitigation: Linux Pretty much every Linux system with the "old" Firewire drivers loaded (kernel module ohci1394 et. al.) is vulnerable to these issues. Newer kernels now also ship with a new Firewire stack called "juju" (kernel module firewire_ohci et. al.) which may or may not have the same issues (not fully tested by me so far, will report back later). Per default, all recent kernels, e.g. 2.6.26, are vulnerable, but see below. Under Linux, simply using a kernel which doesn't have any Firewire support (neither built-in, nor as a module) is the most secure option. If you must have Firewire support you can load the ohci1394 module with the phys_dma=0 parameter to at least disable physical DMA support:

  $ modprobe ohci1394 phys_dma=0

I have personally tested this on some boxes and I can confirm that it renders the currently published tools useless. As for the new "juju" Firewire stack, I'm not so sure. A few quick tests showed that the currently available tools don't work with the new stack, but you shouldn't feel too secure! AFAIK the new stack does support (or will support soon) physical DMA for Firewire, so it's probably just a matter of adapting the tools a bit (I'll do some testing/research on this later, as time permits). Mitigation: Mac OS On Mac OS you might also be able to completely remove Firewire support from the kernel (but I don't know if/how that can be done, not sure if you can easily recompile Mac OS kernels, and/or if you even have buildable source code and toolchains for that). However, you can at least remove the Firewire support in the default Mac OS installation by unloading AppleFWOHCI.kext:

  $ sudo kextunload /System/Library/Extensions/IOFireWireFamily.kext/Contents/PlugIns/AppleFWOHCI.kext

Thanks to a Daniel Reutter for letting me abuse his MacBook via Firewire and for finding the above kextunload command line. We have successfully tested that after unloading AppleFWOHCI.kext the current tools won't work anymore. The tests were done on a Mac OS X Tiger (I think) with all recent security updates applied. Please leave a comment if you can test other versions of Mac OS X... Mitigation: Windows As for Windows, well, I guess you're screwed. While Windows XP does implement sort of "protection" in that it only allows physical DMA access via Firewire to devices which "deserve it", e.g. iPods (or any other Firewire mass storage device, I guess) this can be easily defeated by having your attack PC/laptop pretend to be an iPod (see the romtool Python script by Adam Boileau). The only remaining option I know of (short of removing/destroying Firewire ports or preventing physical access alltogether) is to disable the Firewire ports/drivers in the device manager (untested by me so far). If you do that, remember to also disable all PCMCIA/Cardbus/ExpressCard controllers, of course (see above). So far I've tested Windows XP SP2/SP3 successfully with Adam Boileau's tools. I haven't yet been able to test Windows 95/98/Vista, if you can verify one of them, please leave a comment. Mitigation: OpenBSD/FreeBSD/NetBSD/OpenSolaris/... On OpenBSD you're likely not vulnerable as OpenBSD doesn't have any Firewire drivers at all, as far as I know ;-) As for FreeBSD, NetBSD, OpenSolaris, and other OSes I don't have any information. I might be able to test one or two of them in the nearer future, but please leave a comment if you have some information about whether they are vulnerable and/or how you can secure your system... Conclusion That's it for now. I hope you now have a good overview of these issues and how to protect. I can only urge you to take this problem seriously! Three or four minutes of leaving your laptop unattended are fully sufficient for an attacker to get a full forensic image of all your RAM contents for later analysis. This is at least as critical as the Cold Boot attacks, if not worse. I will follow-up with more articles about some more interesting details on these Firewire issues, how to use the above tools, and I'll report on some of the stuff I was able to find in RAM dumps gathered via Firewire...

After less than a week of vacation I've decided it was time to write a short blog entry, as I plan to write at least another one in some days, as we are waiting the arrival of Marc, our second son, for this week or the next one. In the last months I haven't done what I said in my last posts, I'm quite busy with the rest of my life and blogging or keeping my home computing infrastructure is not on the top list. Anyway I still have managed to do some things like giving a talk about virtualization on the VII Jornades de Programari Lliure, not going to Debconf8 (next year should be the one, the conference is in Spain and I have enough time to prepare it, including a possible trip with all the family) or do a partial server migration at home, leaving two machines to do the work of one. My plan for the migration has changed and if time permits I'll try to do it in the next couple of weeks; now I plan to move my current servers to an ASUS EeePC with 2GB of RAM and an external USB disk (it is a lot smaller and the hardware is still faster than my old server) and I'll use OpenVZ instead of Linux-Vserver for virtualization (OpenVZ enabled kernels are available for Lenny).

Hi folks! We’re almost done for the official Summer of Code program and I thought that I couldn’t let it end without another update, so here we are (you may thank Daniel Burrows for additional poking). The Gtk+ interface for Aptitude is making great progress. The product is not final yet but already implements many of the planned ideas, with others to come. Here are the screenies: So, let’s see the tasks presented in my previous update:

• A real user interface <- much progress here
• Being reliable <- check! we don’t crash all the time anymore
• Packages dependencies, pre-dependencies, etc. <- check!
• Hyperlinks between packages <- check!
• Advanced package search <- check!
• Tags support (tag clouds ?) <- well, no clouds yet, but we have tags
• Linking with interesting data sources like popcon <- not done yet
• A lot of interesting things <- well..

In some more details: we are now much closer to the final interface. Some things are not done yet, for example, notification bars la Iceweasel (or is it Firefox ?) are in the works for unobtrusive notifications about important things and a little guidance. We are much more reliable now. We eliminated lots of memory management problems that resulted from, mmh, imperfect coding discipline. We also lock the interface when important backend stuff reload to prevent the user from shooting himself in the foot when triggering an install when the APT cache is reloading for example.. The backend refactoring took a sizable part of this second term but it was worth it. The code is now much cleaner and uses no more (at least much fewer) ugly unscalable hacks. One very important feature of Aptitude is the ability to easily display all kinds of dependencies and navigate through them by hyperlinking. It’s now working in the Gtk+ interface as well. Feel free to click on whatever looks like a package or a package version. We now support the powerful Aptitude package searching syntax. Daniel Burrows is talking with Enrico Zini to bring the power of apt-xapian-index to Aptitude: autocompletion! lightning fast full-text searches! tag clouds! ponies! There is still a lot to be done. I’m not going away after the GSoC program. I’m here to stay, for Aptitude and Debian. Daniel Burrows has been very helpful and supportive. The Debian community is as awesome as I knew it before participating in the program. Daniel Burrows is planning to merge the Gtk+ interface into the main branch in September and packages may appear into Experimental. With the very interesting evolutions of the upcoming Adept-3, Lenny+1 will show very interesting changes in the area of packages managers. Now for you. I need you to test my interface. All necessary instructions are on the development trac : http://dev.graffit.net/aptitude/trac.

DebConf, the annual Debian Conference, is held this year in Mar del Plata, Argentina. One sometimes-overlooked part of this is the brilliant video streaming service, with each stream supported by an IRC feedback channel including announcement of talks and events as they approach, start and finish. While I was watching Martin F. Krafft’s talk yesterday (which introduced the topgit patch manager to me, which I’ll look at and may suggest to the Koha project), I was blown away by the production quality of the video. It’s even better than last year, which was already good. The shots of the slides with the presenter in a little window on them are a particularly clever idea and much better than the “auto-refreshing slides webpage” method I’ve seen from other conferences. It does look like a little encoder tweaking might be possible to get the slides (which don’t change much) pixel-perfect while compressing the presenter window, but I’d be happy if all conferences were covered this well. Read the debconf announcement for links to the streams and schedules. I was having a few problems watching this afternoon (packets getting lost between telecomplete and bytemark), but switching to a European video server helped it. Mplayer’s hardframedrop also seems to help in bad network conditions, but it takes multiple attempts to get a successful connection from mplayer, for reasons I don’t understand. The conference continues until next weekend, which includes Debian’s 15th anniversary.

Third day of DebConf8 now - and it has been a pretty nice time since I arrived. The local orga team is doing a marvelous job, making this whole conference a really nice experience for about every attendee. Thanks to that we had a lot of time doing actual Debian work, which meant that we got a nice number of changes in dak either done or planned for the future, including a redesign of our database schema. Which is urgently needed if we want to follow some of the points we discussed. Like throwing away apt-ftparchive and generating the Packages files ourselve. Or various other enhancements. So for dak, the changes are summarised into:

• Adapt an old patch for process-new, so that NEW packages only adding new binary components are sorted higher during the processing.
• Imported a patch from Joachim that adds an (effectively) anti-s390-buildd-maintainer option to our cruft-report full mode. Well, actually it lists a set of packages which are marked “not-for-us” on the buildd, but still have a (outdated) binary in unstable, effectively blocking updates of the packages going into testing. Ideally a buildd maintainer would report to the maintainer (through a bug or even just a mail) when he sets not-for-us (which is a short-term-solution, long-term P-a-s should be used), but that doesn’t seem to happen.
• Replaced a 128 line NIH syndrom perl script with one of those new-fangled sarge-and-later options in rsync :)
• Fixed bugs in code-pathes that are nearly never used - but which we managed to trigger twice while fixing a gpl violation (missing source) in our archive.
• Merged a patch that changes NEW handling of packages for stable/oldstable.
• Added signing of the buildd incoming.debian.org directory. Still need to announce this on d-d-a, but buildd maintainers should now be able to enable the gpg verification.
• Automate the i18n package description translation import so we finally get rid of the “one-time-manual-sync-back-in-2006” outdated translations. And have an automated but secure way to get updates.
• Started the layout of the new projectb.

But we did not only do work on dak, we also did some work for the conference. In the days down here we (re)wrote the Pentabarf entrance controller, enabling our frontdesk to check people in, keeping track of various details they need to know about them. We wrote entirely new controllers for Pentabarf, one of it being the part that manages this years Assassins game. Other orga team members (hello triple des :) ) wrote a video and a volunteer controller. I guess after DebConf we will have some fun time to merge our changes back to upstream.

---

Travel in .ar Oh well, as some people know, I stay in Argentina for about 10 days more after DebConf is over (my flight back goes on 27. August, in the evening). Up to now I haven’t decided - or even started planning - what I do here. I should probably look at that soon. Hrm. Anyone out there doing something similar the next days? :) Comments: 0

For some time people have been telling me about the benefits of SpamAssassin (SA). I have installed it once for a client (at their demand and against my recommendation) but was not satisfied with the result (managing the spam folder was too complex for their users). The typical configuration of SA has it run after mail has been accepted by the server. Messages that it regards as spam are put into a spam folder. This means that when someone phones you about some important message you didn’t receive then you have to check that folder. Someone who sends mail to a user who has such a SA configuration can not expect that the message will either be received or rejected (thus giving them a bounce message). Even worse it seems to be quite common for technical users to train the Bayesian part of SA on messages from the spam folder - without reviewing them! Submitting a folder of spam that has been carefully reviewed for Bayesian training can increase the accuracy of classification (including taking account for locality and language differences in spam). Submitting a folder which is not reviewed means that when a false-positive gets into that folder (which will eventually happen) it is used as training for spam recognition thus increasing the incidence of false-positives! Spam has been becoming more of a problem for me recently, on a typical day between 20 and 40 spam messages would get past the array of DNSBL services I use and be re-sent to pass the grey-listing. Also I have been receiving complaints from people who want to send email to me about some of the DNSBL and RHSBL services I use (the rfc-ignorant.org service gets a lot of complaints - there are a huge number of ignorant and lazy people running mail servers). So now I have installed spamassassin-milter to have SA run during the SMTP protocol. Then if SA checks indicate that the message is SPAM my mail server can just reject the message with a 55x which will cause the sending mail server to generate a local bounce (if it’s a legitimate message) or to just be discard it in the case of a spam server. Here is how to set it up on Debian/Lenny and CentOS 5: Install the package yum install spamass-milter or apt-get install spamass-milter spamassassin spamc (spamassassin seems to be installed by default on CentOS). On a Debian system the milter will be setup and running. On CentOS you have to run the following commands:
useradd -m -c "Spamassassin Milter" -s /bin/false spamass-milter
mkdir /var/run/spamass-milter
chown spamass-milter /var/run/spamass-milter
chmod 711 /var/run/spamass-milter
echo SOCKET="/var/run/spamass-milter/spamass.sock" >> /etc/sysconfig/spamass-milter On CentOS edit /etc/init.d/spamass-milter and change the daemon start line to ‘runuser - spamass-milter -s /bin/bash -c "/usr/sbin/spamass-milter -p $SOCKET -f $EXTRA_FLAGS"‘ Then add the following lines below it:
chown postfix:postfix /var/run/spamass-milter/spamass.sock
chmod 660 /var/run/spamass-milter/spamass.sock The spamass-milter program talks to the SpamAssassin daemon spamd. On both Debian and CentOS run the command “useradd -c Spamassassin -m -s /bin/false spamassassin” to create an account for SA. The Debian bug #486914 [1] has a request to have SA not run as root by default. On CentOS it seems that SA wants to use a directory under the spamass-milter home directory, the following commands alllow this. It would be good to have it not do that, or maybe it would be better to have the one Unix account used for SA and the milter.
chmod 711 ~spamass-milter
mkdir ~spamassassin/.spamassassin
chown spamassassin ~spamassassin/.spamassassin On Debian edit the file /etc/default/spamassassin and add “-u spamassassin -g spamassassin” to the OPTIONS line. On CentOS edit the file /etc/sysconfig/spamassassin and add “-u spamassassin -g spamassassin” to the SPAMDOPTIONS line. To enable the daemons, on CentOS you need to run “chkconfig spamass-milter on ; chkconfig spamassassin on“, on Debian edit the file /etc/default/spamassassin and set ENABLED=1. Now start the daemons, on CentOS use the command “service spamassassin start ; service spamass-milter start“, on Debian use the command “/etc/init.d/spamassassin start“. Now you have to edit the mail server configuration, for Postfix on CentOS the command “postconf -e smtpd_milters=unix:/var/run/spamass-milter/spamass.sock” will do it, for Postfix on Debian the command “postconf -e smtpd_milters=unix:/var/spool/postfix/spamass/spamass.sock” will do it. Now restart Postfix and it should be working. For correct operation you need to ensure that the score needed for a bounce is specified as the same number in both the spamass-milter and SA configuration. If you have a lower number for the spamass-milter configuration (as is the default in Debian) then bounces can be generated - you should never generate a bounce for a spam. The config file /etc/default/spamass-milter allows you to specify the score for rejecting mail, I am currently using a score of 5. Any changes to the score need matching changes to /etc/mail/spamassassin/local.cf (which has a default required_score of 5 in Debian). You can grep for “spamd..result..Y” in your mail log to see entries for messages that were rejected. One problem that I have with this configuration on Debian (not on CentOS) is that spamd is logging messages such as “spamd: handle_user unable to find user: ‘russell’“. I don’t want it to look for ~russell when processing mail for russell@coker.com.au because I have a virtual domain set up and the delivery mailbox has a different name. Ideally I could configure it to know the mapping between users and mailboxes (maybe by parsing the /etc/postfix/virtual.db file). But having it simply not attempt to access per-user configuration would be good too. Any suggestions would be appreciated. Now that I have SpamAssassin running it seems that I am getting about 5 spams a day, the difference is significant. The next thing I will do is make some of the DNSBL checks that are prone to false-positives become SpamAssassin scores instead. When I started writing this post I was not planning to compare the sys-admin experiences of CentOS and Debian. But it does seem that there is less work involved in the task of installing Debian packages.

• [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=486914

Share This

Somehow (thankfully) I've managed to avoid much to do with backups in my career as a sysadmin. It's always been someone else's responsibility, that's been fine by me. For some reason, I've been more paranoid lately, and with all of the crazy shit I've been doing to daedalus, I wanted to have a backup, just in case. Maybe it's old age. So a while ago, I went and had a stab at setting up Amanda, since pretty much whenever I've been near a bunch of sysadmins and someone asks for a recommendation on what to use, "Amanda" is the answer. I jumped through all of the hoops to have caesar be the backup server, and daedalus be a client. I set up a virtual tape library on caesar. I think I then lost interest for a while, until I was going to upgrade daedalus to Etch, and I wanted to have a successful backup first. I had the holding disk and the virtual tape library on the same filesystem, and it was nice and big, yet I kept running into this error about insufficient space. "dump larger than available tape space" was the complaint. I tried making the filesystem larger. I tried adding more virtual tapes. Nothing would placate it. After another round of Googling, I discovered that the problem was because Amanda would only only span a maximum of four tapes, and the filesystem I was trying to backup was way bigger than that. So I told it to use up to 10 tapes in a run (runtapes 10) and then lo and behold, I got a successful backup out of the sucker. So that was mostly all good, but occasionally a backup would fail, or fail once an succeed on a retry, because tar exited non-zero, with "file changed as we read it". I did some more Googling tonight, and discovered this Amanda/GNU tar compatibility matrix. It turns out that the version of tar and the version of Amanda shipped in Debian Etch aren't compatible with each other. Suck! Oh wait, they're maintained by the same person! Argh! So aside from the occasional backup failing due to a file being written to at the time of the backup, it's working fairly well. My DSL link isn't the fastest, so a full backup of daedalus can take over 48 hours to complete, but I'm not paying for inbound bandwidth at home, so it's not a big deal. I initially thought that to do a restore, I'd have to run amrecover on daedalus, and then I'd have to stream the contents of multiple tapes back to it at the appalling uplink speed of my DSL connection, but fortunately amrecover has a sethost command, so I can restore just the files I need on another machine local to caesar at LAN speeds, and just transfer the files I restore to daedalus. So that's all pretty neat. I quite like the FTP-client-like interface of amrecover. It's cool how you can use setdate and just go back in time. I had the opportunity to do a test restore recently when one of my users nuked his Maildir directory by accident. Unfortunately I was unable to recover the needed files in that case, and I'm not entirely sure what the problem was, so there's some more testing to be done before I'll be fully confident that I can rely on it. There's a lot of configuration options available as well, and I think I got the config I'm currently using from a template or something, so there's probably a fair bit of tweaking I can do. Oh, and I'm constantly reminded of this quote from a previous life, where technical details bubbled too far up non-technical management:

"Who is Amanda, and what is her role in the backups?"

I've released version 0.4.11.9 of the aptitude package manager (release notes). This release incorporates a few trivial bug-fixes that I hoped to get out before the lenny freeze, but real life intervened. More importantly, it includes the fix for bug #483459, a non-fatal but highly annoying bug that affected Polish users. I hope the release team allows this one into lenny after it's been tested in unstable, but we'll see. I'll put in a formal request for an exemption once the new release has steeped a enough.

Today I figured out why the awesome window manager's tags are so eh, awesome. I'm attending debconf via irc and web stream, and have that on tag 9. Which I mostly think of a a desktop, since I generally view one tag at a time, and flip between them like desktops. But often I want to browse the web, or do something else too, without losing the video and irc offscreen. So from tag 9, I can press mod+ctrl+3 to display tags 9+3 at the same time. And after I've done this, can mod+left/right to go up and down between tags, and tag 9 stays selected and visible. Awesome automatically lays everything out.

Only thing I don't like is that if I use mod+N to switch to a specific tag, it will drop tag 9.