Wandering Thoughts archives

Accidental bittorrent on our networks

Several times now we've had cases of 'accidental BitTorrent' on our networks (and generally gotten email from the campus network people about it); people running BitTorrent clients on our networks without intending to. It turns out that this is an amusing (to me) consequence of the pervasiveness of laptops and laptop hibernation these days.

(You might reasonably ask why we 'allow' BitTorrent at all. There's at least two reasons; first, without deep packet inspection (and maybe even then) we can't tell what is and isn't BitTorrent traffic, and second, there are legitimate uses for BitTorrent, especially in a Computer Science research environment.)

What I believe generally happens is:

• at home, the user starts their BitTorrent client on their laptop
• the client tucks itself discreetly away somewhere in the system
• the user hibernates or otherwise suspends their laptop, instead of shutting it down outright.
• the user brings the laptop to here, and un-suspends it, resuming everything including the BitTorrent client (which doesn't care that it changed networks, since it's stateless overall).

It shouldn't surprise anyone that BitTorrent swarms love our network, as they love anything with a fast uplink. The resulting network utilization can be dramatic.

I don't consider this the user's fault; it is a classic case of a collection of design decisions (and human factors issues, like how people forget things in the corner) that make perfect sense in isolation but combine badly. Unfortunately all of the cures that I can think of are more complicated than the disease.

A thought about filesystem snapshots

Here is an aphorism:

Filesystem snapshots preserve mistakes, and so public snapshots preserve mistakes publicly.

This isn't an issue unique to snapshots; it's common to any backup system that offers public or 'self serve' restores. In theory a system that only let you see or restore files that you owned would avoid the problem, but the simple version would make certain files inaccessible (files you owned inside directories that other people owned, unless the system made an exception for that). Plus it only really works for backup systems; filesystem snapshots count on the general filesystem for a lot of things, including permissions.

Our use of (ZFS) snapshots is likely to be both entirely administrative and short term, so I think we are probably not going to worry too much about this particular thought.

(On a side note, I must strongly encourage vendors of systems with such 'self serve' restore programs to not try to duplicate Unix file permissions checking; that way lies dragons, and I have seen some of them. And certainly it should be possible to selectively turn off the ability to do self-serve restores, so that some filesystems or directory trees can only be restored by sysadmins.)

Why people persist in sending files by email

One of the things that annoys (some) sysadmins is users exchanging files over the email system, often for good technical reasons, and over the years a lot of people have devoted a lot of effort to trying to persuade users to switch to various other mechanisms.

It's not going to happen. (Well, you knew that already if you've been paying attention.)

People keep exchanging files over email because email remains the most visibly secure and convenient way of doing so, especially to naive users. The advantages of email for this, from a user perspective, include:

• email does it all in one step; competing systems generally require both uploading the file and emailing the target, and then the target has to read their email and do something else to retrieve the file.

  (If you think that the service users upload files to can send the email itself instead of making the users do it, remember the first rule of free email-based services.)

• people naturally feel that it is more secure to do the electronic equivalent of mailing an actual package instead of the electronic equivalent of mailing directions to where you can get a copy of the package (no matter how obscure and unguessable the directions are, and no matter that in theory any of the postal people in the background could make their own copy).

• email is in practice 'more secure' in that your file is less likely to spread around, because people resend huge email messages much less frequently than they pass around URLs or the like.

• once you send the file, you don't have to worry about if and when it will expire; the recipient has their copy and that's just done.
• once you receive the file, you don't have to worry that you need to grab a copy before some set time or the like; you can keep it as long as the local policies on email let you (often 'forever'). Similarly you can delete it whenever you want to and it's gone.

Even a global filesystem with reliable identification and ACLs wouldn't get around the convenience of the expiry (non) issue, although it could get around the others.

And frankly, speaking as a sysadmin I am just as happy to not have another service to run, maintain, and worry about, so even for me all the alternatives to users emailing files to each other are pretty much worse. (And I would have to run the service, at least if we're being responsible.)

Why package systems are important

Once upon a time it was popular to laugh at package systems like RPM and say that all you really needed was 'make install'. This attitude missed the point, because the importance of good package systems is that they let you easily remove things.

This matters because it encourages experimentation with packages. If removing a package is difficult and painful, it's a fairly big commitment to just install a package in the first place. If removing a package is easy and reliable, then installing packages is not at all a commitment; if it turns out to not be useful, you just remove it again. When it's easy enough, installing a package temporarily may become the easiest way to merely read about the package.

(Having lots of unnecessary packages is a form of clutter, and like all clutter makes your systems harder to manage. It may also expose you to more security issues, and it eats up more disk space, and so on.)

This implies that one of the things that a good package system should do is have as little done by install and removal scripts as possible. Scripts are an opportunity for people building packages to get things wrong, and it only takes a few mistakes to lose people's trust. Putting every routine operation in the package system itself means that only one set of people have to get it right, and they generally have a much deeper and broader exposure to the issues.

(Of course there are other things that competent package systems do to encourage experimentation, like automatic dependency resolution. But a good package system should have a way of removing a specific package and all packages that were only installed as dependencies; as far as someone experimenting with a package is concerned, they're all one thing.)