RIP Steve Jobs, you have truly changed the face of both computing and society in general. Few people have had such a great and positive impact on the world as you did. You will be sorely missed.
Apple have a brief tribute to the great man over at http://www.apple.com/stevejobs/
If you are running a Windows Server 2008 installation with multiple IP addresses on one interface then you might be surprised to know that the default behaviour when selecting the IP address to use for outbound connections has changed compared to Windows Server 2003.
Previously, the “main” IP address on the adapter would have been used for initiating outbound connections and the “additional” IP addresses would be used for inbound connectivity only (unless specifically bound to by a client application, which is quite rare).
However, the new behaviour in Windows Server 2008 is that the IP address closest to the default gateway is used for outbound connections, which can catch you completely by surprise when your server’s IP address effectively changes after simply adding a new additional IP address to an interface – particularly if you are using firewalls to filter connections by IP address elsewhere in your network!
In order to provide some control which IP address is used for outbound connections, Microsoft introduced the “skipassource” flag to the netsh command. This allows you to exclude IP addresses from being used for outbound connections when managing IP addresses via netsh.
This command wasn’t initially available, so you may need to apply one of Microsoft’s hotfixes (KB975808 for Windows Server 2008 and KB2386184 for Windows Server 2008 R2). It is also possible to wipe out your carefully crafted skipassource settings using the GUI unless you apply KB2554859.
To add an IP address to the “Local Area Connection” interface with the skipassource flag set, fire up the command line and run the following (replacing <ip> <netmask> with the appropriate values for your network of course):
netsh int ipv4 add address “Local Area Connection” <ip> <netmask> skipassource=true
You can verify that this has worked as well as view the flags on all currently configured IP addresses using:
netsh int ipv4 show ipaddresses level=verbose
Zimbra has a fantastically useful built in system for exporting an entire mailbox, including the contents of the entire e-mail inbox, calendar, address book and briefcase ready to be imported on another Zimbra server either via the web interface or using zmmailbox from the command line. This makes migrating mailboxes between separate Zimbra installations incredibly easy.
You can export a chosen mailbox from the source Zimbra server with:
zmmailbox -z -m user@test.com getRestURL “//?fmt=tgz” > /tmp/user_test.com.tar.gz
And then import it into the destination server with:
zmmailbox -z -m user@test.com postRestURL “//?fmt=tgz&resolve=reset” /tmp/user_test.com.tar.gz
You need to make sure that the target account exists before attempting to import the archive on the destination server. Using the “reset” resolve method will ensure that everything is wiped from the target account before importing from the archive.
Simply replace “tgz” with “zip” in order to chose between the two archive formats when importing and exporting, making sure to use the right one on the import!
If you want to download a copy of an account from your browser, just visit the appropriate URL (e.g. http://mail.test.com/home/user/?fmt=tgz where “user” is the account’s username) or use the nice Import/Export GUI in the Zimbra preferences tab, which also gives you the option to upload and import an archive.
The Zimbra preference interface to the export function also allows you to easily specify advanced settings such as date ranges, search filters or limiting the export to a certain data type such as calendar items.
The one problem with Zimbra’s import/export system is that user settings such as signatures and mail filters which are stored in an account’s LDAP attributes aren’t included in the exported data. It’s easy enough to manually move signatures between servers, but anything more than a couple of mail filters can be tedious to manually re-create.
Luckily, you can get the information you need from the zimbraMailSieveScript attribute for a chosen account using the zmprov command line utility:
zmprov ga user@test.com zimbraMailSieveScript
This should give you something a copy of your mail filter rules in the sieve format, for example:
require ["fileinto", "reject", "tag", "flag"];
# No Reply
if anyof (header :contains ["to"] “noreply@test.com”) {
fileinto “Inbox/No Reply”;
stop;
}
You can then easily re-import this into LDAP on the destination server by placing single quotes around the result and using “zmprov ma”:
zmprov ma user@test.com zimbraMailSieveScript ‘require ["fileinto", "reject", "tag", "flag"];
# No Reply
if anyof (header :contains ["to"] “noreply@test.com”) {
fileinto “Inbox/No Reply”;
stop;
}’
You can of course apply the same technique to other account details if you wish, you just need to know the appropriate LDAP attribute, such as zimbraPrefMailSignatureHTML for your signature or zimbraPrefOutOfOfficeReply for your out of office auto reply.
If you are experiencing HTTP 500 Internal Server Error messages from the license management part of the Parallels Plesk control panel when running on Atomic Secured Linux, then you are probably running into some buggy anti-reverse engineering code that Parallels have built into the Plesk software.
It seems that Parallels are using ptrace to determine if someone has attached a debugger to Plesk in order to reverse engineer it. The problem is that AtomiCorp have implemented GRSecurity ptrace protection in the Atomic Secured Linux kernel in order to prevent malicious software such as TTY sniffers and Parallels Plesk is incorrectly interpreting it’s inability to ptrace as suspicious debugging behaviour.
Until Parallels fix this behaviour in Plesk (and there is no sign that they will, given that it has been a known issue for many months), then the only thing that you can to is disable the GRSecurity ptrace feature in the Atomic Secured Linux kernel. This can be done whilst the system is running using sysctl:
sysctl -w kernel.grsecurity.harden_ptrace=0
In order to make this change permanent so that it doesn’t disappear every time you reboot your server, you will need to edit /etc/sysctl.conf and add the following line:
kernel.grsecurity.harden_ptrace = 0
Now restart the Parallels Plesk service and enjoy your error free license management 
NSD is a fantastic authoritative nameserver from NLnet Labs which was developed in conjunction with the RIPE NCC to be a highly scalable, secure authoritative nameserver which has no recursive features by design. In fact, it is such as good nameserver that it is used on three of the root namesevers (k.root-servers.net, h.root-servers.net and l.root-servers.net).
Thanks to the EPEL project run by the Fedora guys, you can quickly and easily install an up to date copy of NSD on CentOS/RHEL systems. The only problem that I have found so far is that the RPM doesn’t seem to create directory for the PID file specified in the /etc/nsd/nsd.conf and so the daemon won’t start out of the box.
Obviously it is easy enough to create the /var/run/nsd directory with mkdir, but remember to chown/chgrp this directory to the nsd user and group, otherwise and “nsdc restart” will fail with errors in /var/log/messages along the lines of “failed to unlink pidfile /var/run/nsd/nsd.pid: Permission denied“
A handy feature of R1Soft CDP Server 2.0 (now known as Enterprise Edition) is that it can integrate with cPanel so that your users can restore their own files from your backups using a self service interface. If you want to remove this integration for any reason, then R1Soft provide a BASH shell script to do this for you:
/usr/lib/buagent/control-panels/cpanel/remove-cpanel-integration.sh
This script doesn’t always work for one reason or another, so the other way of doing this is to manually call the cPanel plugin uninstaller:
/usr/local/cpanel/bin/unregister_cpanelplugin /var/cpanel/registered_cpanelplugins/righteousbackup
This is particularly helpful if you forgot to uninstall the cPanel integration before upgrading to R1Soft CDP 3.0 or thought that the r1soft-uninstall-buagent utility would do it for you when removing the R1Soft CDP 2.0 agent (unfortunately it doesn’t, but it does helpfully remove the remove-cpanel-integration.sh script).
Unfortunately the cPanel integration in R1Soft CDP 3.0 is severely lacking compared to R1Soft CDP 2.0 and in my opinion is virtually useless in it’s current form.
As the control panel integration system is a pretty new feature in R1Soft CDP 3.0 (it was missing entirely from the initial release), hopefully it will be bolstered in subsequent R1Soft CDP 3.0 releases to restore it to the same level of functionality as was formerly available in R1Soft CDP 2.0.
If you want to run R1Soft CDP 3.0 on a system protected by Atomic Secured Linux and the ASL enhanced kernel with PaX/grsecurity then you need to disable memory protection for the CDP 3.0 binary. You do this by using paxctl to set the NOMPROTECT flag for the CDP 3.0 binary.
/sbin/paxctl -m /usr/sbin/r1soft/bin/2-6/cdp-2-6
Unfortunately the CDP 3.0 binary lacks the PT_PAX_FLAGS header, so you will receive an error message along the lines of:
file /usr/sbin/r1soft/bin/2-6/cdp-2-6 does not have a PT_PAX_FLAGS program header, try conversion
The solution to this is to first use paxctl to run a conversion on the CDP 3.0 binary which should change the PT_GNU_STACK header to PT_PAX_FLAGS
/sbin/paxctl -c /usr/sbin/r1soft/bin/2-6/cdp-2-6
If this has worked then you should see a message along the lines of
file /usr/sbin/r1soft/bin/2-6/cdp-2-6 had a PT_GNU_STACK program header, converted
Now you should be able to use paxctl to set the NOMPROTECT flag on the CDP 3.0 binary without any errors. Now restart the R1Soft CDP 3.0 agent service and have fun backing up all your previous data
If you receive an “Upload file is too big or invalid” error message when trying to upload a new FortiOS image to your Fortinet device via the web interface, then the first thing to try is giving the device a quick reboot in order to free up memory to hold the uploaded copy of the firmware image.
If this doesn’t fix the problem, then I’ve had much more success with running the update process from command line, although this does require you to have the new FortiOS image on a TFTP server so that the Fortinet device can download it. Once you have issued the command, the device will download the new image and reboot.
The exact command varies depending on the deice type, for example FortiGate devices have the option of FTP or TFTP downloads, whilst FortiMail devices can only download new FortiOS images via TFTP.
For a FortiGate device:
exec restore image tftp
For a FortiManager device running FortiOS 3.x:
exec restore image
For a FortiManager device running FortiOS 4.x:
exec restore image tftp
For a FortiAnalyser device running FortiOS 3.x:
exec restore image
For a FortiAnalyser device running FortiOS 4.x:
exec restore image tftp
For a FortiMail device running FortiOS 3.x:
exec restore image
For a FortiMail device running FortiOS 4.x:
exec restore image tftp
Depending on the device and FortiOS version, you may have other file transfer options such as FTP available to you. Devices registered with a FortiManager can also update their FortiOS image by downloading a new one from the FortiManager unit.
If you are still having problems getting the new FortiOS firmware image onto your Fortinet device, then you can also download a FortiOS image via TFTP from within the Fortinet bootloader/BIOS using the serial console.
Connect a serial console to your device and reboot it, then interrupt the boot sequence when prompted. In the menu, select the option to download a new FortiOS firmware image and provide the file name, server IP address and local IP address.
Right at the start of the bot process, you should see a message along the line of:
Press any key to display configuration menu…
Once you have pressed a key, then the following configuration menu should appear:
[G]: Get firmware image from TFTP server.
[F]: Format boot device.
[B]: Boot with backup firmware and set as default.
[I]: Configuration and information.
[Q]: Quit menu and continue to boot with default firmware.
[H]: Display this list of options.Enter G,F,B,I,Q,or H:
At the configuration menu, type “G” and press enter and you will be asked to enter the details needed to TFTP a new image to your Fortinet device:
Enter TFTP server address [192.168.1.168]:
Enter local address [192.168.1.188]:
Enter firmware image file name [image.out]:
You will need to be on the same subnet as the TFTP server in order to do this.