We use multi-site installations pretty much exclusively. Moving sites around (from development to production, say) can be a pain, especially when there are a large number of modules in sites/all/modules, relatively few of which are used by a given subsite.
I recently turned my hand to using drush to pick out just the enabled modules for a given subsite to make for easy migration. This is my proof of concept script; there is lots of room for improvement.
Apt-dater is a relatively new utility that allows easy package management of multiple Debian servers from a central control server. I wrote up the necessary steps below, as the existing instructions (http://www.ibh.de/apt-dater/) are slightly unclear on a couple of things.
We run Debian stable (currently lenny) on many servers. Apt-dater is new enough that it is currently only available via the lenny-backports repository. (NB: in what follows I assume knowledge of basic package management and ssh configuration. Help with both of these is widely available on the 'Net.)
Setting up the CiviMail return channel is a notorious pain in the ass. The return channel is the mechanism by which email is passed back into the CiviMail system. It's necessary to allow replies and bounces to be handled by CiviCRM, making it fairly essential to the successful use of CiviMail.
The official way of setting things up is unfortunate in a couple of respects: it requires the installation of a customized version of the amavisd-new content-filtering daemon*, and it cannot handle multi-site installs. The "alternative" return channel implementation, although rumoured to not scale as well, requires no additional software, and can be easily adapted for servers hosting multiple domains that use CiviMail.
I recently found myself in possession of a huge (~1.5GB) MySQL dump that I needed to restore after a system reinstall. When a text file gets this large, it is very difficult to edit or even view, as text editors simply can't handle the size. Fortunately, I figured out a simple way of separating the single file into separate databases that could be viewed or imported individually. It works because a typical database dump first creates the database, then the tables, then inserts the data into those tables. It does this sequentially, for one database at a time.
