Archive for the ‘Technical’ Category

« Older Entries
Newer Entries »

EPEL NSD RPM and the missing PID file directory

Sunday, June 26th, 2011

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“

Tags: , , , , , , , , , ,
Posted in Red Hat and CentOS | No Comments »

Remove CDP 2.0 cPanel integration

Sunday, June 19th, 2011

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.

Tags: , , , , , , , , , , , , , , ,
Posted in cPanel/WHM, R1Soft CDP | No Comments »

R1Soft CDP 3.0 and commercial SSL certificates

Sunday, June 12th, 2011

Chances are that you will want to protect the web interface for your R1Soft CDP 3.0 server with a commercial SSL certificate issued by a known, trusted certificate authority. After all, you are sending some pretty sensitive data between your browser the and the R1Soft CDP 3.0 web interface and you want to know not only that it is encrypted but that you are able to ensure the identity of the R1Soft CDP 3.0 server so that you aren’t susceptible to man-in-the-middle attacks.

This post assumes that you have generated a CSR and sent it to your chosen certificate authority to be signed. We use /root/example.key as the private key and /root/example.crt as the PEM certificate that you received back from the certificate authority. The certificate authority’s intermediate certificate is in /root/example_intermediate.crt. Obviously substitute these file names for whatever you have actually used.

In order to use the ImportKey utility to import your private key and certificate into the Java keystore file you will need to convert both the private key and certificate from the PEM format into DER using the openssl tool.

openssl pkcs8 -topk8 -nocrypt -in /root/example.key -inform PEM -out /root/example.key.der -outform DER
openssl x509 -in /root/example.crt -inform PEM -out /root/example.crt.der -outform DER

For some reason the java and keytool binaries provided by R1Soft aren’t executable by default, so lets fix this and download the ImportKey utility

cd /usr/sbin/r1soft/jre/bin
chmod +x java
chmod +x keytool
wget http://community.igniterealtime.org/servlet/JiveServlet/download/196707-4718/importkey.zip
unzip ImportKey.zip

Now lets use ImportKey to create a Java keystore with your private key and newly issued certificate.

./java ImportKey /root/example.key.der /root/example.crt.der

The ImportKey utility sets a password on both the keystore itself and the private key inside the keystore. For the R1Soft CDP 3.0 web server to be able to decrypt the keystore and private key it needs to know what the password is. Unfortunately there is no way to specify the password to use, the R1Soft CDP 3.0 embedded tomcat web server just assumes that both passwords are set to “password”, so we had better change the password from the default which is “importkey”.

./keytool -storepasswd -keystore /root/keystore.ImportKey
./keytool -keypasswd -alias importkey -keystore /root/keystore.ImportKey

Most SSL certificates aren’t signed directly from the root certificate authority these days, but instead are signed via an intermediate certificate. In order for the certificate to be useable, the entire certificate chain needs to be available in the keystore for the R1Soft CDP 3.0 web server, so we will import the intermediate certificate. Remember to use your newly set keystore password.

./keytool -import -alias intermed -file /root/example_intermediate.crt -keystore /root/keystore.ImportKey -trustcacerts

Now to start using your new keystore, just move the old one out of the way (better keep it around for now, just in case!) and replace it with your newly generated keystore then restart the service for the R1Soft CDP 3.0 server.

mv /usr/sbin/r1soft/conf/keystore /usr/sbin/r1soft/conf/keystore.old
mv /root/keystore.ImportKey /usr/sbin/r1soft/conf/keystore
/etc/init.d/cdp-server restart

Tags: , , , , , , , , , , , ,
Posted in R1Soft CDP | No Comments »

R1Soft CDP 3.0 with Atomic Secured Linux and PAX

Sunday, June 12th, 2011

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 :)

Tags: , , , , , , , , , ,
Posted in R1Soft CDP | No Comments »

Fortinet FortiOS firmware upgrade – Upload file is too big or invalid

Sunday, June 5th, 2011

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.

Tags: , , , , , ,
Posted in Fortinet | No Comments »

R1Soft CDP 3.0 – java.net.InetAddress.getLocalHost UnknownHostException

Sunday, May 29th, 2011

When you launch the CDP 3.0 web interface for the first time, you are prompted to activate your license, or at least you should be. If instead you get a Java error then take a look in /usr/sbin/r1soft/log/monitor.log and you will probably see something like this:

INFO | buserver | 2011/05/29 16:21:59 | May 29, 2011 4:21:59 PM org.zkoss.zk.ui.impl.UiEngineImpl handleError:1253
INFO | buserver | 2011/05/29 16:21:59 | SEVERE: >>java.lang.RuntimeException: java.net.UnknownHostException: cdp.example.com: cdp.example.com
INFO | buserver | 2011/05/29 16:21:59 | >>java.net.UnknownHostException: cdp.example.com: cdp.example.com
INFO | buserver | 2011/05/29 16:21:59 | >> at java.net.InetAddress.getLocalHost(Unknown Source)
INFO | buserver | 2011/05/29 16:21:59 | >> at com.r1soft.backup.server.facade.ServerFacade.getLocalHostIP(ServerFacade.java:537)
INFO | buserver | 2011/05/29 16:21:59 | >> at com.r1soft.backup.server.web.configuration.ActivationWizardWindow.afterCompose(ActivationWizardWindow.java:212)
INFO | buserver | 2011/05/29 16:21:59 | >> at org.zkoss.zk.ui.impl.UiEngineImpl.execCreateChild0(UiEngineImpl.java:736)
INFO | buserver | 2011/05/29 16:21:59 | >> at org.zkoss.zk.ui.impl.UiEngineImpl.execCreateChild(UiEngineImpl.java:685)
INFO | buserver | 2011/05/29 16:21:59 | >> at org.zkoss.zk.ui.impl.UiEngineImpl.execCreate0(UiEngineImpl.java:629)
INFO | buserver | 2011/05/29 16:21:59 | >> at org.zkoss.zk.ui.impl.UiEngineImpl.execCreateChild(UiEngineImpl.java:661)
INFO | buserver | 2011/05/29 16:21:59 | >>…

R1Soft CDP is trying to determine your server’s IP address from it’s hostname, so you need to make sure that your hostname exists in DNS or is at least present in the /etc/hosts file. As soon as Java is able to determine the server’s IP address from it’s hostname then this error message will be replaced with the license activation window that you were expecting to see.

Tags: , , , , , , , , , , , ,
Posted in R1Soft CDP | No Comments »

R1Soft CDP scheduler issues

Thursday, April 28th, 2011

After spending quite some time with R1Soft support investigating some bizarre issues where the CDP 2.0 scheduler was skipping over some tasks seemingly at random, we eventually discovered that the issue was caused by setting the e-mail reporting task to run every minute. Decreasing the frequency of this task allowed all scheduled CDP tasks to run as normal.

R1Soft are now investigating what causes these issues with the CDP 2.0 scheduler when tasks are set to run every minute. The option of running every minute is available through the CDP interface and R1Soft were unable to explain why setting the e-mail notifications to run every minute would intermittently break the scheduling of both the e-mail notifications and other scheduled tasks such as the all important backup processes!

Tags: , , , ,
Posted in R1Soft CDP | No Comments »

Missing kernel initial RAM disk with SolusVM and Xen

Thursday, April 28th, 2011

If for any reason your /boot/solus-vmlinuz symlink as well the /boot/solus-initrd.img initial RAM disk are missing or incorrect in Dom0 on one of your SolusVM Xen slaves, then you can force SolusVM to regenerate them using the latest Xen enabled copy of the kernel installed on the server using the following command in Dom0 on the slave:

php /usr/local/solusvm/includes/xenkernel.php

This not only re-creates the /boot/solus-vmlinuz symlink to the appropriate vmlinuz file, but also builds the necessary /boot/solus-initrd.img initial RAM disk to boot your DomU machines.

Of course, if you are using PyGrub then you don’t use these files in Dom0 :)

Tags: , , , , , , , , , ,
Posted in SolusVM | No Comments »

RouterOS slow learning BGP routes with Winbox open

Thursday, April 28th, 2011

After banging my head against a wall waiting for a RouterOS powered router to re-learn the 330,000 routes that currently make up the global routing table, I was surprised to find that seemingly Winbox slows the learning of BGP routes to a crawl. Closing Winbox allowed the router to process the entire global routing table in the normal minute or so, including passing through some complex filters.

It would seem that in RouterOS 4.x at least, the router is pushing details of all learned routes to any Winbox clients connected and slowing itself to a crawl in the process. I haven’t had a chance to verify if this affects all versions of RouterOS 4.x yet or test it on RouterOS 5.x

Tags: , , ,
Posted in Mikrotik RouterOS | No Comments »

Preventing backscatter on aliased domains in Zimbra

Tuesday, April 5th, 2011

By default, an aliased domain in Zimbra will accept all e-mail at SMTP time and then bounce a message later if it is unable to delivering it after carrying out the aliasing. This generates backscatter, which can be abused and even lead to your mail server appearing on some blacklists. Luckily, since Zimbra 5.0.12 there has been a way to fix this; just su to the zimbra user and run:

zmlocalconfig -e postfix_enable_smtpd_policyd=yes
zmprov mcf +zimbraMtaRestriction “check_policy_service unix:private/policy”
postfix stop
postfix start

Tags: , ,
Posted in Zimbra | No Comments »

« Older Entries
Newer Entries »