Posts filed under 'Linux'
I’ve been running my own IMAP server for over 8 years now. Back when I evaluated possible options, I was fond of having all my mails remote accessible on my server and being able to do server-side filtering with sieve.
However, back then there existed no practical solution with the software I was using (Mozilla Mail, now Thunderbird), so sieve was just a word but I couldn’t use it (and I probably was lazy to do it by other means). I think I remember that Eudura had support for it.
Anyway, by sheer luck I came across the sieve extension for Thunerbird! I couldn’t believe, but it is true and it works.
Actually, the extension not a real up to par GUI filter interface what Thunderbird offers natively, it’s a more spiced up telnet to simply access the server side filters and work on them. But that shouldn’t degrade the extension, because it’s really all you need!
I instantly converted all my Thunderbird filters to sieve and, voila, no need to depend on a client to do the mail filtering.
This gave me quite a bite when I starting using my Nokia E61i with my imap server, because there’s no filtering capability available (and if it would, it probably would be too annoying for me to sync all the filters for it), but now that problem is solved too.
In case you’re wondering what IMAP solution I’m using: it’s cyrus imap using sasl. But don’t ask me about details. I set this thing up nearly a decade ago, carried this installation through all my hardware changes, first via chroots, now with vserver, but I almost entirely forgot how I sat it up, nevermind the master password :-)
I’m thinking about upgrading the architecture, switching to DBMAIL, etc, but there’s also this voice inside: never touch a running system. And, yes, cyrus is runnig well and haven’t failed me in years.
March 21st, 2008
Working with Linux is just art. It is unbelievable how creative one can be using it, something I bet you will never find with this kind of flexibility somewhere*windows*cough*else.
The prerequisites: you need to realize that 99% of the things you do by hand in Linux you can actually automate.
I’ve running an old SME Server (mail server with webgui) distribution on an even older hardware. A hard disc already died in the past, wiping out everything. The next outage is around the corner, I know it. We have contracted replacement for the server, but it may still take another month or two until it will be there. In the meantime, I cannot afford loosing the mail server.
First step: what do I want?
We purchased the Primergy RX200 S3 Killer and I want the mail serer to run in the Primergy. But not as a primary service: as a vserver.
This below roughly outlines the steps I had to go through, some with explanations why:
- Create the new vserver which will hold your new machine
- Get all the files from the remote machine on the local machine, using rsync
rsync -avz --numeric-ids --delete --exclude-from=1exclude-files.txt -e ssh root@mail:/ 10.16.0.3-mail/
Important factor: use --numeric-ids or you get translated ID numbers of file ownership and groups which won’t work
- Have a second copy of the rsyncd data on the new system
I need to make modifications, the system won’t work out of the box. Modification deals mostly with IP address changes, fstab etc, see below. Important: this one goes right into your vservers vdir. This will potentially destroy your dev/ and proc/ dirs and need to be restored.
- Change into vserver/etc/ and replace all occurrences of the old IP address:
perl -p -i -e 's;OLDIP;NEWIP;g' `find -type f|xargs grep -l OLDIP |grep -v cdb`
In my case I also needed to exclude those binary cdb files
- Comment out every line in /etc/fstab:
perl -p -i -e 's;^([^#].*);# $1;g' fstab
- SME Server uses runlevel 7 which is not support by util-vserver at the moment.
Workaround: vserver by default start into runlevel 3. Modify runlevel 3 in SME to be runlevel 7:
mv rc3.d rc3.disabled
ln -s rc.d/rc7.d rc3.d
- Disable some services I don’t need:
rm rc3.d/S25keytable
rm rc3.d/S37network
rm rc3.d/S91atalk
rm rc3.d/S91smb
- SME server also has one essential service, svscan, it starts from init and thus this service is defined in inittab:
sv:7:respawn:/usr/bin/env - PATH=/usr/local/bin:$PATH /usr/local/bin/svscan /service &
Because vserver doesn’t run init, the process doesn’t get executed. A quick (and probably very bad) solution is to have it started as first service in runlevel 3:
echo -e '#!/bin/bash\nPATH=/usr/local/bin:$PATH /usr/local/bin/svscan /service &' | sed 's;\\;;g' < rc3.d/S01svscan
chmod 755 rc3.d/S01svscan
Now, that’s it. I now was able to start the vserver and everything was up and running. Automated. Awesome.
July 13th, 2007
Since I’ve the bad habit of running multiple Linux installation on my hardware with chroot, I could be using vserver as well anyway.
First, why virtualizing anyway? Buy big fat hardware and consolidate services. Use less hardware and run more services on it. We’re getting a new development machine in our company shortly and we need a real working infrastructure:
- pure development machine
- experimental testing machine
- at least one but better more staging/QA machines
- provide stable services inside the company like:
- Wiki/Intranet
- Possible a Webmail-Server
Another important point is flexibility: I can move around vserver from one hardware to another if I have to. For me this is an unbeatable feature. Just think about what happens if the hardware shows its age and you need to acquire a new one: install everything from scratch again? Definitely not. But lets get started.
Today I gave it a first shot with Debian sarge and went quite smooth. When I started experimenting a day ago I didn’t realized that I was having backparts.org in my apt sources.list which is quite important: no backports, no ready-made vserver kernel images, no tools, etc. ;) Here’s the line I’m using in my host system:
deb http://www.backports.org/debian/ sarge-backports main contrib non-free
Continuing here I consulted various sources on how to get started, the most helpful which I reference here:
My experience is a result from all sources, reading through them and then finally started testing.
First I completely did not understand how the networking is meant to be set up, a few sites mentioned messing around with ipfilter but I tried to get away with this tool first because, from my simple perspective, I just wanted to run a vserver on a dedicated IP in my private network. Period.
I started with the following command:
vserver vserv00 build -m debootstrap --hostname vserver00.home --netdev eth1 --interface v00=192.168.1.10/24 --context 100 -- -d etch -m http://ftp.at.debian.org/debian
This command tells vserver to set up a new vserver, use the debootstrap mechanism, configure the vservers FQDN to be vserver00.home, use the hosts eth1 device, create a new interface v00 for this vserver and assign it Ip 192.168.1.10 in the 255.255.255.0 network (that’s the 24 CIDR directive). I’m not yet sure about the context number, it seems every vserver needs one and it must be unique. Not yet sure if the number affects some kind of priority.
This runs the debootstrap installation and thus downloads all necessary packages. Once done, you can start your vserver and enter it:
vserver vserv00 start
vserver vserv00 enter
I frequently get an error message like this when entering which I just ignore for now:
# vserver vserv00 entermesg: /dev/pts/2: Operation not permitted
Inside the vserver the sources.list is just the bare minimum. I quickly replaced it with the following:
deb http://ftp.at.debian.org/debian/ etch main non-free contribdeb-src http://ftp.at.debian.org/debian/ etch main non-free contribdeb http://security.debian.org/ etch/updates main contrib non-free
and ran through the complete dselect update/upgrade mechanism.
Enjoy :)
Update: the context is just a unique ID and doesn’t influence any kind of priority. Also, the error message
mesg: /dev/pts/2: Operation not permitted went away once I had a real system running inside.
Update 2: I’ve to admin: vserver is an awesome application/kernel extension. I successfully migrated my first long-runing chroot installation (been using over four years) to vserver and still runs. I had to make some adjustments, mainly the IP address changes of the new vserver and that syslog-ng cannot read /proc/kmsg (which isn’t a problem, actually) and make sure that the server gets started by default and that was it. Damn, this thing is so hot.
June 18th, 2007
Basically, follow the steps outlined at http://www.bpfh.net/simes/computing/chroot-break.html and you’re done.
The reason I wrote this is that I accidentally locked myself out of my hardware system installation. I had SSH access to one of the chroot systems running on the same machine but because I changed some SSHD settings on the hardware system I forgot to properly start SSHD again. The above document really gives an idiots guide to break out of the chroot and once the syntax error in line 62 is fixed (maybe it’s on purpose?) you end up with a shell outside the chroot. Luckily, in my case.
June 17th, 2007
A few days ago I switched to a new power supply. I switched on the server and let him ran for hours when I suddenly realized that the computer hung. It was always in combination with data transfers over the network. Since the primary reason of the server is file storage on my network via Samba I started out with investigation what could cause this by googling around.
I eventually found this thread (in German) which mentions the via rhine chipset and problems with the power management implementation in Linux. After trying out various combinations I finally found the one which did not lock up the computer until now:
acpi=off pci=noacpi noapic
After some time again I’ve upgraded to 2.6.16 because I needed to get the rt2005 drivers to run (for my not yet purchased wireless pci card, I always prefer to make sure I can compile drivers before I buy hardware) because they didn’t work with 2.6.8. On the new kernel I only appended the noapic kernel parameter and everything worked smooth.
What surprises me completely is that this problem started to occur after I changed the power supply. To me nothing which warrants anything related to the change I need.
January 29th, 2007
After upgrading from 3.0.22-1 to 3.0.23c-1 the user authorization for samba and SSH didn’t work anymore. Luckily I’m such a paranoid bastard that earlier this year I started versioning my complete debian installation with subversion. Guess what, this saved my live. I was able to exactly identify which files caused the problems:
- /lib/libnss_winbind.so.2
- /usr/sbin/smbd
- /usr/sbin/winbindd
- /lib/security/pam_winbind.so
- /lib/libnss_wins.so.2
Using on any of these files a version from the 3.0.23c-1 caused either samba to break and not accept valid users anymore or SSH pam/winbind authorization failed or other PAM enabled services e.g. apache.
I added additional information to the debian bug report 387076 which, from the description, matched my problem best.
For now I left the 3.0.23c-1 packages and only reverted the mentioned binaries, in hope that the next upgrade will fix this.
September 16th, 2006
I took the existing version of phpdoc.vim and modified it to me needs. The version worked very well but hat some annoyances and limitations. Thus I made 0.26a version with the following changes from the original functionality:
- support PHP5 public/protected/private on class variables and methods
- provide the current date in the @since tag
- check if a phpdoc already exists before insert a new one
The most current version can be downloaded from my site. Drop this file in your vim\vimfiles\plugin directory (on Windows, go figure for unix) and start Vim. I’ve only tested this with Vim 7.
I’m aware that Tobias Schlitt (site currently under construction it seems) has also been hacking around on a new / modified / alternate phpdoc.vim version with many many more new features. However I wanted a) to keep things simple and b) find my own way into vim scripting.
July 20th, 2006
One of the often encountered problems when developing application in the web environment is their complex setup. It’s not like a desktop application that you can check out, compile and run the source.
You need a proper server environment where your application can run, the components need to have the required version, etc. Setting up web server is not hard but tuning all required parameters takes time. And usually in a team of developers someone is responsible for the configuration management; and there’s a reason for that.
Because of the resources it takes to set up such an environment, the common sense when developing applications is usually that there’s one server for all developers and that there are one or two fixed checkouts of a project. That’s a bit against the philosophy on how versioning systems are designed to work. Each and every developer should have its own checkout. But with a complex environment it’s not always feasable to have this process. When it takes so much resources to have the central development server fine tuned you can bet it takes even more for local development on the developers computer.
My goal was that we have flexibility:
- have a place were we check out a complte project and multiple (!) developer can work on one checkout (traditional)
- have a place for each developer on the development server where he can check out as many custom web projects as he wants
- make it next to zero work to create new apache configurations for new projects (VirtualHosts, etc.)
I solved this with a small PHP class and some shell scripting, which basically can generate working apache VirtualHosts configuration on the fly. For this we need to know a few things first:
- the path where the apache configuration templates are stored
- the path to the common checked out projects
- the base directory for user specific checked out projects
- where to generate the PHP5 apache configuration
- where to generate the PHP4 apache configuration
To recognize a directory whether it is a project to be enabled for apache we’ve the following rules for the directory name:
.php4|.php5[.extern]
Within the directory name is the distinction whether it’s an PHP4 or PHP5 project. That’s necessary because we’re running two instances of apache for each version of PHP so we can run both versions as apache modules.
The other directive, .extern, tells us that we want to public this project from our development server live on the internet. Why? Well, customers are everthing but patient, so it happens quite often we hand out URLs of our current development state to our customers. This also means we have to generate separate VirtualHost configuration for those projects.
The same rule applies to the user specific project directory, except that we don’t support .extern there, see below we.
Every project generated from those rules may have the following URLs:
project.dev.company.tld
For e.g. project.php4, not accessibe for customers
project.live.company.tld
For e.g. project.php5.extern
And for user specific checkouts:
project.username.dev.company.tld
In the end it’s dead simple. It took me about 2 days to gather the requirements, talk with the other developers how we could approach this and implement the soluation. Thanks to apaches Include *.conf directive it’s really easy to dynamically generate VirtualHosts and tell apache to restart.
Since ever developer within our company should be able to create new VirtualHosts config on demand, I provided a basic web interface which generates the apache configuration and restarts apache. Restarting apache from within PHP was a bit problematc, because you need to
- have the proper permissions to restart apache from user www-data (I’m using Debian)
- take care that running a PHP script which stops apache also terminates this very PHP script
To solve the permission problem I used sudo and creates a sudoers file like this:
Cmnd_Alias WWWEXEC = /data/www/intern/magic-config/generate.sh
www-data ALL = (root) NOPASSWD: WWWEXEC
To properly execute this script I had to put it into background immidiately so it is decoupled from the PHP script:
exec(“sudo /data/www/intern/magic-config/generate.sh&”);
The generate.sh shell script restarts apache.
At the moment I do not plan to release the code for two reasons:
- I would need to get permission from my company, but if someone think he would really benefit from it, I may ask for it
- It may be to specific anyway to our environment
July 12th, 2006
On my new subversion setup with apache2 behind an apache1 SSL server I promptly ran into two issues which luckily were solved before, thanks to the community.
MKCOL, 405 Method Not Allowed, MERGE request failed
When I encountered this one, actually the second time, luckily my own post to the subversion mailing list helped me fixing this. When using svnnotify under some circumstances with weird characters sets it may hang. Although the commit will success on the server side, the client is given a commit error indication and the WC is left in an unusable state.
As I outlined in detail on the archive, the fix was quite easy:
- Make sure you pass the
--charset parameter with an appropriate character set, e.g. utf8 or iso-8859-1
- Forget your WC, make a new checkout and continue working from there.
All commands I ran (cleanup, update, commit) either gave no negative responses are unhelpful error messages.
The downside is that a server-side hang seems to destroy the client WC which should never happen.
Bad Gateway through reverse proxy from https to http
This one was quite a headache. It seems that the reverse proxy will not rewrite the path scheme of the Destination header. Thus you end up having the scheme https at the apache2 subversion server when you should have http.
A very good and actually easy solution was to install the ProxyDav.pm module from https://dev.sethd.org/svn/perl/lib/ . On debian this only required to install libapache2-mod-perl2 and placing the file into the /etc/apache2/ directory (because that’s one of the search paths which shows up immidiately in the error.log of the virtual host).
Thanks also to my co-worker for running in all sort of problems all the time so he came next to nothing to work at ;-)
June 29th, 2006
Sine some years I’m having the bad habbit of installing on my system exclusively in chroot installations. What does this mean? First, you install a bare-bone-only-what’s-really-necessary linux installation directly on the hardware itself and in the next second you forget that you did this and start bootstrapping another installation inside a chroot.
In short, what are the benefits? Moving your installation to another hardware is only a matter of copying all the files, it even doesn’t matter what linux distribution you’re having installed in your new machine (as long as the CPU matches you binaries).
The next level is to version your installation. Over the time, months, years, so many changes are done, you don’t know where and what you configured why anymore. At this point subversion (but it could be any suiteable versioning system, I guess) jumps into the scene.
Right after you bootstrapped your new installation you import everything into your repository. Care has to be taken for special directories, e.g. I don’t version /dev/ and /proc/ and a few others (see below). Once this is done, check out your imported version so you have the subversion control directories in place (I bet there’s a more elegant way to do this anyway) and you are set.
Of course there are gotchas and it is not easy to work with this setup (I didn’t pretend this). You have to make a plan what to version and what not. My plan is usually to version everything but:
/dev//home//proc//var/log//var/lock//var/cache//var/spool/
(probably some others in /var/ also)
Often-changing directories don’t make sense to version. And since usually I’ve a space on the system where all other data is stored (other repositories, web projects) I put them all under /data/ and also exclude this one from being versioned.
If you commit things in a subdirectory rather in the root directory from time to time you have to run svn update in the root directory which may restore deleted files, do this has to be done manually.
It is extra work and one has to take special care in handling all things, but in the end you don’t have to worry much about broken packages anymore.
Something I didn’t consider in depth are permissions on directories/files. I think I need to take another look at them in the future.
Ach, I forgot: try this with windows …
June 7th, 2006