It has been a LONG time since I wrote anything here and I have updated very little elsewhere (I did update some of the documents at http://docs.xexyl.net and I changed the main menu here a little bit but that is about it). The reason for such is a lot of health problems and such is life. While there’s a lot of stuff I have thought to write about the truth of the matter is they are quite low on my priority list. Nevertheless, since the topic in question is something easy enough (read: it’s not a lot to cover) to write about and since I have seen many people complain about the very warning by the Postfix mail server yet not find a solution I decided to spend a few minutes to write how to solve it. The complaints that are heard are typically along the lines of two themes :

But I do not have my domain in both mydestination and virtual_mailbox_domains!

and

There’s no explanation on how to get rid of this warning (aside from the ‘work around’ option to disable warnings) in the documentation.

Well, each has its problems but I will sort this out for those who have the warning I refer to. For the first problem, you must understand that just because you do not specify mydestination does not mean it is not set. Further, there is the chance there’s more than one instance of Postfix running (though to be fair this is less likely the problem). The second problem is not entirely true although maybe it should be made very clear in the documentation. That’s not up to me though.

So how do you solve the problem then? First, we’ll assume that your domain names are two of the for-documentation purposes domains:

• example.com
• example.org

We’ll also assume that the mail server is specifically example.com and you want either both to be a virtual domain or you want example.org to be the virtual domain. Choose your poison when reading this as it really does not matter in the slightest with this configuration.

So given the above parameters this is what you need to do :

1. The server’s name should be what mydestination is set to, so in the configuration file (main.cf which is generally under /etc/postfix/main.cf) you need the line:
   • mydestination = example.com
2. Next, assuming you have you your virtual domains file (a plain text file, one entry domain name per line) named (also in /etc/postfix/) virtual_domains then you should (adjusting to whatever your file name is) have the following in your main.cf file :
   • virtual_mailbox_domains = virtual_domains

   Note that if your file is actually a database file then you would need to adjust the line above to let Postfix know this (e.g., prepending ‘hash:’ without the quotes to virtual_domains and if you have updated the file do not forget to update the database file with for example postmap). It should go without saying but example.com (the final destination) should NOT be in the virtual domains file.

3. The last step is essentially masquerading mydestination as a virtual domain (in the sense of the effect of the end result). Here Postfix is informed that local transport is to use the virtual transport service and that the local recipients are included in the virtual domains. That is possibly not the best way to word what is going on but the two lines should show all that is needed to understand it :
   • local_transport = virtual
   • local_recipient_maps = $alias_maps $virtual_mailbox_maps

   Assuming that Postfix virtual mailbox and virtual domains already worked then this, combined with reloading or restarting Postfix should be all you need to do. There is a way to ‘force’ Postfix to issue the warning (in the case that it’s not configured properly) but I do not have the motivation to write about it.

Hopefully this has been of help to some people and to those who I have left some questions remaining, I am sorry in advance. The real key is that your server name is the final destination and it is masqueraded as a virtual domain (but actually it is not in the truest sense of the word). This does however mean you might need to set up local users mail if they are to receive mail. I’m afraid you’re on your own there but if you only wanted virtual domains this should not be a real problem any way. Lastly, I am sorry if I have left anything out. As I said I have been quite unwell for some time and I may very well have neglected to mention something important. No idea when I’ll be writing next. Until then, so long and thanks for all the fish (yes, a little tribute to Douglas Adams as I missed his 61st birthday in March).

Although its still only beta, I was excited about a few significant changes in Fedora Core 17. I’ll explain.

Firstly, there is UsrMerge, which is explained in detail at http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge. I like the benefits of this, and it seems the best alternative to some other changes over time. Those changes:

Before UsrMerge, we had the following directories, among others :

/sbin/
/bin/
/usr/sbin/
/usr/bin

The original point of sbin versus bin has nothing to do with security and no, the ‘s’ does not stand for super or root user binaries only. It was static binaries. This was important in the days /usr and various other mount points were on separate file systems. Why? Static binary refers to the libraries it needs. Rather than load them dynamically, it was all built into the binary. This was vital when you had a problem on boot up and you needed certain utilities (if e.g., it needed something on /usr – what if that wasn’t mounted for some reason [whatever the case] ? You’d be in trouble). However, over time this changed. Nowadays, in systems prior to UsrMerge (e.g., CentOS), most of the files in /sbin are dynamically linked. In fact, in systemd setups (as opposed to the older init scripts), the /usr isn’t even supposed to be on a separate file system (when I first read that it annoyed me, but I’m ok with it now).

So basically, what UsrMerge does is the following :

Move all files in /sbin, /bin, /lib, /lib64 to to /usr which essentially means move the files, not the directories. After that, whatever was in /sbin is in /usr/sbin, and the same applies to /bin, /lib and /lib64. But what next? It symlinks (e.g., ln -s) the old locations to the new. So, essentially, when you do an ls -l / you will see something like:

lrwxrwxrwx 1 root root 7 Apr 20 13:13 bin -> usr/bin
lrwxrwxrwx 1 root root 7 Apr 20 13:13 lib -> usr/lib
lrwxrwxrwx 1 root root 9 Apr 20 13:13 lib64 -> usr/lib64
lrwxrwxrwx 1 root root 8 Apr 20 13:13 sbin -> usr/sbin

This only has benefits.

The other change I was looking forward to – the default gcc and gcc-c++ packages are now at version 4.7.0. Note I had only one minor problem when updating the operating system. A mis-sight on my part with my libstdc++47 package I built. The problem was file clashing. The solution is simply to remove that package. What I should have done is had /usr/include/c++/4.7.0 in a different directory name. As it is, I only need it on a CentOS 5 machine, which equates to never having libstdc++ 4.7.0, so I”m not concerned about fixing it (especially with such a simple fix – vital especially if you were to upgrade versus fresh install by DVD. The file clashes would stop the installer and then your system could be hosed. So do keep that in mind, folks). Normally I reinstall fresh, but I didn’t want that for a variety of reasons. In the end it was well worth it.

There’s a few addendums I’ll add though. Firstly, the instructions of what I followed are at https://fedoraproject.org/wiki/Upgrading_Fedora_using_yum#Fedora_16_-.3E_Fedora_17.

Note though that I had already downloaded the beta DVD as I intended to go that way initially (I downloaded it hours before the official beta was announced; little known fact that its usually obtainable by such time in at least some mirrors). And being on my rather lower downstream link, I did not want to download 1.6GB (which is what yum said I’d have to download). Now, how could I fix that? Well, because I had the DVD, I loop mounted it (see man page for mount, otherwise its : mount -o loop /path/to/image /mountpoint). Then, I initially was going to create a repo but (likely due to me being very impatient and not setting it up right) yum did not want to download via the loop. So, better idea came to mind:

What if I cp the files from the loop-mounted iso image to the location yum downloads the files it needs to? In this case it is /var/cache/yum/x86_64/17/fedora/packages/ (I actually didn’t do cp but rather an rsync as I had downloaded a few there already). As you can probably guess, it means any file that is the same version/release (and all that good stuff) will not have to be redownloaded. That means in my case instead of downloading 1.6GB I had to only download < 900GB. Quite a nice improvement. The only other note that comes to mind: on shutdown, after the update, the kernel could possibly panic (it did in my case after trying [and maybe did succeed - can't recall] - umount the file systems. Since I had no file system issues on power off and then power on (and boot), I assume it did succeed to umount things properly. This may seem like an isue but it's not really that shocking: all the libraries have been updated, kernel, the environment, everything. Next shutdown should go fine.

Aside from that, make sure you heed the warning about dracut and the kernel: it will assume by default you mean the currently RUNNING kernel. That means if you installed any kernel and have not booted into it, then you either must remove that kernel (by version and architecture!! That is essential.) or reboot into the new kernel before building your initramfs. I should point out another thing about initramfs: that's another reason why /sbin didn't care about libraries being statically linked or not - it has the modules/etc that you need to boot up with that kernel. Regardless though, UsrMerge works fine, and no bugs that I can see in Fedora Core 17. Of course, there is one issue for debugging with selinux enabled. However, you simply have to disable that flag (it's related to SELinux denies access to the ptrace system call). Simply doing 'setsebool deny_ptrace 0' will solve that (and if you use debuggers or programs such as strace, then you'll need that). Otherwise, see for more information.

Okay, so most network administrators and I suspect a fair amount of users know the main use of DNS zones and having authority. But to those who don’t know what it means, I’ll explain briefly:

It basically says this NS (name server) has control / is the master of the zone. That means, they can decide what the zone will resolve to, what sub domains in the zone will resolve to and so on.

Now, let’s also consider something very useful in BIND/Named (that’s the Berkeley Internet Name Domain / Name daemon). If you don’t know what a ‘daemon’ is: it’s a way for a computer to service a demon. Okay, maybe not. It’s actually a service – be it for web, dns, mail, list goes on. Apache (httpd) is a daemon and that’s what the d stands for in httpd too. It’s that simple.

Now, back to BIND. The feature I was referring to is known as ‘views’. It simply is this: you can match the source ip and say you use this definition of the zone’s file. This is very powerful indeed. It makes it possible to have internal hosts only visible on the inside. However, there’s indeed (as the title suggests) other – perhaps devious in ways – uses.

If you have authority of a zone, it means you can “play around” with clients. This has to be said though: its not normally a good idea, and its certainly not going to invite traffic if you try to exploit someone. However, when you check your daily logs and see a bunch of crap like this:

Feb  2 00:08:46 xexyl postfix/smtpd[16816]: warning: host-92-27-58-145.static.as13285.net[92.27.58.145]: SASL CRAM-MD5 authentication failed: PDI4NTc1ODM5NTkxMDkyNzkuMTMyODE3MDEyNEB4ZXh5bC5uZXQ+
Feb  2 00:09:20 xexyl postfix/smtpd[16816]: warning: host-92-27-58-145.static.as13285.net[92.27.58.145]: SASL CRAM-MD5 authentication failed: PDE5OTc2MDA2MjIyNjQ1MDQuMTMyODE3MDE0MkB4ZXh5bC5uZXQ+
Feb  2 00:10:09 xexyl postfix/smtpd[16816]: warning: host-92-27-58-145.static.as13285.net[92.27.58.145]: SASL CRAM-MD5 authentication failed: PDI2MTkwMzYzMDI1NjM2NDIuMTMyODE3MDE5MkB4ZXh5bC5uZXQ+
Feb  2 00:10:43 xexyl postfix/smtpd[16816]: warning: host-92-27-58-145.static.as13285.net[92.27.58.145]: SASL CRAM-MD5 authentication failed: PDc4NTkzMzEwMDUwMDU3NDYuMTMyODE3MDI0MUB4ZXh5bC5uZXQ+

… and you see that for several hours every minute… (Note: I had fail2ban active so it was blocking them and they would reconnect as soon as it expired as they were constantly trying to connect)

I would say its fair game. Incidentally, I had something similar recently (last year during the holidays). In that case I logged over 13,000 entries in the firewall (and that’s AFTER I added a ban from being annoyed enough. Though now I reinstalled fail2ban – so that’s less of a human intervention needed. But that’s another story anyway).

So, you see some stupid (likely Windows computer infected with the latest and greatest bug …) computer doing this, filling up log space, wasting resources and that includes network resources too. What can you do?

Well the first one (the other story) I was going to do similar and make it point to the broadcast of their network. It happened to be a Tech school (pathetic, yes, and even more so that they didn’t even acknowledge it like other schools, hosts and so on have – even after pointing it to them and calling them). That’s when it stopped.

However, today, I decided I only wanted to stop them. So, simply put. I set up a view for them. IF they are using your host name (and not IP) then here’s something for you to consider:

Match their IP in a view for them. Set up a zone file for your domain. Set all domains in that zone (as in, mail, www, ftp, whatever) MINUS the NS one (we want to make sure they see we’re authoritative) as localhost, that is to say: 127.0.0.1

Problem solved (Under the conditions I specified). If they’re connected to a service you can of course either restart the service (which will shutdown the connection) or you can drop their socket (via firewall or whatever else).

The one thought (or question) that some may have: why not just add an ip{,6}tables rule that drops their IP to the floor? Well, two reasons. Firstly, its less fun (not to mention they’re still going to be connecting that far.. and sending data). Second, if they’re going to be resolving and connecting, I’d rather them resolve to their own computer and therefore they only communicate with me via DNS and the rest is on their own end.

Although many more (than in the past) use nsupdate(1), I still edit named zones by hand (read: I’m too lazy to RTFM when vi(m) allows search/replace through the entire file, I don’t deal with huge zones, and the zones I do deal with are not often updated anyway). Now, as any one who has dealt with DNS will likely know, there’s a concept known as the serial number. Of course, many may know of other kinds of serial numbers but I have no interest in those kinds.

The basic principle is that it is a way to know if a zone has been updated (when the serial is incremented then the name servers know its been changed [once its loaded in the master nameserver]). The format is the following:

YYYYMMDDXY

The YYYYMMDD is obviously the year, month and day of the month. The XY (which might be better referred to as XX – you decide) is the part of the serial that says which update it is. In other words, the first change for the day can be 01, the second 02, all the way to 99 (though it should be noted that if you’re doing that many edits in a day or even close to that many – what you’re doing is doing something wrong!). In fact, I have this vague (and this may be a false memory) memory that it goes up to 20 maximum. But even still, 20 is too much if you ask me (and likely most if not all other DNS administrators).

So, what happens IF you go over the value or you cleverly play around with it and add more digits? Well, while it may or may not be fortunate that its an actual number (as in integral) and not a string – and therefore you have a more limited number range, you can fix it. You can also fix it if you (like I did the other day – at a time when I should probably not have been editing I might add!) accidentally change the number to either a number you meant to put else where or change the wrong digit entirely. I don’t recall what I changed the number to the other day except that I put it at least a few days in the future.

So then the next time I looked at it and wanted to make a change, I see that it’s actually a day ahead (I think the date was 27 instead of 17 and I checked again the 26). Well, thankfully I remembered playing around with this before.

The fix is very simple. The integer that the serial is stored in is of type unsigned int which means its minimum is 0 and its maximum is 4294967295. So, when an unsigned integer overflows, it will be reset to 0 and start over. In other words, if you make the serial 4294967296 it’ll go to zero. If you set it to 4294967297 it’ll be 1, and so on.

Understanding that is the key: simply set your serial in the zones to 4294967296 and do a :

rndc reload

If you have logging enabled you should see the serial is reported tohave gone backwards. That’s what you want: now you can set it to the proper serial and restart or reload named (rndc reload or service named restart).

It’s really that simple. The only time you might need to change that number is if your system’s maximum is higher. I think that unlikely in a standard Unix and Linux machine however. The point is in any case this: you overflow the serial so that it goes back to zero. Then you set it to the proper serial.