I’m currently working on a bigger paper for university using LaTeX. As it’s necessary to compile source files multiple times (especially when using BibTeX or TOCs), build runs can take quite some time. As an example, my current build script:
This is OK on my workstation, but running a build on my notebook using a small 1.4 GHz single core processor can take up to a minute which is definitely too long. So I looked for solutions how to move the build process to a central server. As I was already using Git for source control on the project, I tried setting up a remote repository on the server which triggered a build using a post-receive script. This basically worked fine, but I wanted to go a step further. I had a look at CI servers and gave Hudson a try as it seems to have a lot of features while being quite easy to set up.
The result is the following: Hudson is polling the Git repository (can be remote or local, in my case it’s a self-hosted remote gitosis installation, but could be github too), starting a new build on changes and publishing the resulting PDF if successful. Hudson is accessible over https using an Apache2 server as frontend to a Tomcat installation.
I just did a change in the URL structure of a bigger site and had to check if all existing URLs are rewritten correctly to the new structure. First I extracted a list of all URLs from the CMS of the old version and wrote them to a text file, each line containing an URL. Then I changed the structure and used the following shellscript to check each URL with curl and output the result. Afterwards it’s easy to analyze the results and check for broken links.
#!/bin/sh
while read f
do
echo $f
echo ""
curl -IL --silent $f
echo "------------------"
echo ""
done < $1
Hatte noch ne Mango und 2 Hühnerfilets im Kühlschrank und hab mal experimentiert, wie man das so kombinieren könnte. Ergebnis war gut, auch wenn ichs mit dem Chili leicht übertrieben habe. Die Mengen hier sind grob geschätzt, kann also gut abweichen. Das Ganze braucht seine Zeit, da man zuerst das Chutney kochen und dann das Fleisch marinieren muss. Ich hab am Vortag das Chutney gekocht und am Tag danach den Rest.
Today was the first time I had to create a new DomU after upgrading my Xen setup to Debian Lenny. When I booted the VM and logged in via xm console I got some strange errors when installing packages:
Can not write log, openpty() failed (/dev/pts not mounted?)
Additionally, after setting up SSH, I got the following error when logging in with SSH:
Server refused to allocate pty
Solution: install udev, reboot the VM and you’re good to go.
Just tried to setup Thunderbird + Lightning on Ubuntu Karmic, but somehow I couldn’t add a new calendar as the field was greyed out. Solution: install libstdc++5 (here from the Debian Lenny repository), un- and reinstall lightning and you’re good to go.
As I stated before, I really like Christoph Haas’ ISPMail setup for Debian-based mailservers. I was quite fine without any server-side spam filtering solution until now, but somehow the spam amount in my inboxes increased more and more and I was looking for a decent and simple solution to filter out all that bullshit which is distracting me day after day.
I clearly wanted to go with Spamassassin (SA), as I made good experiences with it in the past and it’s more or less the standard spamfilter on linux based mailservers. The most common solutions to integrate SA into a Postfix based mailserver are the following:
Using amavisd-new
Using Postfixs content_filter
I don’t really like both of them. Amavis is quite heavy for the pure spam filtering purpose and the content filter checks both ingoing and outgoing mails by default which is obviously not in my interest. Amavis avoids checking outgoing mail just by checking if the sender domain is managed by the same system, but spammers can bypass this quite easily by faking the sender’s address to be the same as the recipient’s one (which is done quite often). There’s a discussion about this on the ISPMail page, so head there for more information. All this can be improved by using multiple Postfix instances and different ports (e.g. using 587/submission for authenticated clients and 25/smtp for normal SMTP traffic), but I want my mailserver to be as interoperable as possible without the need of any special setups on the client side.
So I was looking for another solution. I read some tutorials where people used procmail in user scripts to pass incoming mail to spamc before delivering it to the mailbox. I like this approach as the MTA isn’t involved into the spam filtering process, outgoing mail isn’t touched and you don’t need any complicated setups on the MTA side. All alias and transport definitions work fine and the final mail is checked right before being delivered to the user’s inbox.
First I thought about Sieve, which is already running through Dovecot’s Sieve implementation until I noticed that Sieve is not able to call any external programs (correct me if I’m wrong). Then I had a look at spamc and Postfix’ master.cf. spamc is capable to pipe its output to another program and in the ISPMail setup, Postfix passes the mail directly to Dovecot’s deliver, so why not just let Spamassassin check the mail right before it’s getting passed to Dovecot? I gave it a try and seems to work fine. I still need some automation in training SA databases (might follow in a later post), but the plain SA checking is working reliably and mails can easily be filtered with Sieve afterwards.
So much for the backstory, let’s get our hands dirty. Note: I’m running Debian Lenny.
Mich hätte gerade fast der Schlag getroffen. Ein Fileserver hier läuft trotz recht aktueller Hardware (Gigabyte GA-P35-DS3, C2D E4500) noch unter Windows 2000, weils das einfach noch tut. Da der Platz auf den momentan via Software gespiegelten 400GB IDE-Platten langsam recht knapp wird, wurden zwei 1TB SATA-Platten angeschafft, die ich gerade einbauen und über das onboard RAID des Mainboards laufen lassen wollte. Im Prinzip ja kein Problem. Neue Platten rein, den Controller (und zwar nur den Controller, an dem die neuen Platten hängen) auf RAID umgestellt, ins RAID-Setup und ab geht die Post. Denkste. Bis zum RAID-Setup hat alles problemlos gelappt. Als ich dann Windows bootete poppten auf einmal jede Menge Treiberinstallationsfenster für IDE-Kanäle und alles andere mögliche auf. Hab das mal durchlaufen lassen, aber nach einem Blick in die Datenträgerverwaltung war zwar das neue RAID-Array da, jedoch wurden die 2 alten Platten als unformatiert und mit nur 128GB Kapazität dargestellt. Habe dann auf Verdacht mal die Mainboard-CD rausgekramt und alle Chipsatztreiber nochmals drübergebügelt, nach einem Reboot jedoch das selbe Bild. Über big Google habe ich dann das hier gefunden, was eigentlich nur für Win2k kleiner SP3 gilt. Habs aber trotzdem versucht und als nach dem mittlerweile 3ten Reboot das auf der IDE-Platte liegende Hintergrundbild erschien war die Welt wieder in Ordnung. Jetz läuft gemütlich robocopy, der die alten Daten hoffentlich über Nacht auf die neuen Platten schiebt…ich hasse Computer(probleme) ;)
