4GB of RAM on a Juniper J-Series router (J6350)

May 2nd, 2012

Officially the Juniper J-series routers such as the J6350 only supports a maximum 2GB of RAM. The J6350 comes with 1GB of RAM installed and if you want to add more then you have to buy your RAM from Juniper at inflated prices, however as the J-series are standard x86 machines with Netburst era Celeron and Pentium 4 processors you can simply install standard DDR400 RAM if you aren’t worried about being covered by JTAC support.

Not only does installing your own RAM save you a shedload of money compared to the Juniper equivalent part (JXX50-MEM-512M-S), but you can also exceed the “supported” 2GB maximum 4x512MB configuration, which provides additional memory to the control plane. The four memory slots present on a J6350 can take a 1GB DIMM each, however thanks to a 32bit architecture and mapping of the PCI bus into the same address space, you can only actually use 3.5GB of that 4GB.

The J-series routers are picky about what RAM they use however, so I like to stick to Crucial sticks; partly as that’s what Juniper use but mostly because I use Crucial elsewhere for their great customer service and a genuinely quality product. If you want to stick with a 2GB maximum then you can use Crucial part number CT2KIT6464Z40B, which provides 2x512MB sticks. Alternatively, Crucial part number CT2KIT12864Z40B provides 2x1GB sticks, allowing you to max the chassis out at 4GB across all four slots.

Once you’ve got all 4GB of memory installed in the chasis, boot the router up and from the JUNOS operational mode CLI issue the command “show chassis routing-engine” – you should see a total of 3584MB of memory split between 3008MB of control plane memory and 576MB of data plane memory. If you only opted for 2GB of memory then the 2048MB total will be split between 1472MB of control plane memory and 576MB of data plane memory.

Remember, you replace the RAM in your routers at your own risk and doing so will likely void your warranty as well as rending your system unspported by JTAC.

SolusVM Nginx PHP bug

February 20th, 2012

It looks like there is a bug in the SolusVM Nginx installer which means that the php_cgi service doesn’t start on a reboot.

It seems that the installer sets the unused “spwan-fcgi” process to start, but not the “php_cgi” service that is actually used to handle SolusVM.

Luckily, this is easy enough to fix by running two commands on any of the master and slave servers which have Nginx installed:

chkconfig –add php_cgi
chkconfig php_cgi on

Missing Parallels Plesk for Linux updates

February 11th, 2012

If you’re using Parallels Plesk 9.x with Postfix as the MTA, there appears to be a bug which can stop Plesk from displaying important updates that are available, including the micro-updates which provide important bug fixes and security updates.

If you are using the Updates section of the Plesk web interface, then no error message is displayed, so it just looks like there are no updates available. However, you can also check for updates using the Parallels autoinstaller utility from the command line:

/usr/local/psa/admin/sbin/autoinstaller –check-updates

After downloading all of the .inf3 files from Parallels, this will give you a badly translated error message:

Unable to process patch config: PSA_9.5.4/plesk-patches-9.5.4-cos5-x86_64.inf3: Failed to parse the patch file at (line 34 column 13)
Group named ‘qmail’ is not exists on this system.

Despite the qmail MTA not being installed because the Postifx MTA is being used, the Plesk autoinstaller utility (which is also used by the web interface) seems to be checking for a “qmail” group. The fix for this is incredibly simple – just create an empty ‘qmail” group:

/usr/sbin/groupadd qmail

Now if you refresh the Updates section in the Plesk web interface or re-run the Parallels autoinstaller from the command line then you should now see the available updates, which you can install in the normal manner.

Regenerate statistics in Parallels Plesk for Linux

February 6th, 2012

Every night Parallels Plesk for Linux servers run a cron job to process various log files and generate statistics. This includes generating the HTML for the AWStats or Webalizer log analysis packages used for the Plesk “web statistics” features as well as updating the disk usage and bandwidth usage for each domain.

Sometimes you need to re-run this task, such as if it failed or if you need to process a particular domain name again. One common reason for this is to correct the disk and/or bandwidth usage figures for a domain.

You can either regenerate the statistics for all domain names (the equivalent of the daily cron job) using:

/usr/local/psa/admin/sbin/statistics –calculate-all

Or you can re-generate the statistics for a single domain name (“example.com” in this case) using:

/usr/local/psa/admin/sbin/statistics –calculate-one –domain-name=example.com

There is a similar tool in Parallels Plesk for Windows under C:\Program Files (x86)\Parallels\Plesk\admin\bin\statistics.exe, however this requires different arguments.

Commercial SSL certificates with SolusVM

February 6th, 2012

When you install SolusVM it generates a self signed SSL certificate for use with the end user control panel and admin interface, however it would be wise to purchase a certificate from a commercial certificate authority to prevent man in the middle attacks (and get rid of annoying browser warning messages).

There are two different methods of installing SSL certificates in SoluSVM depending on if you are using the original Lighttpd web-server or the new Nginx option.

For Lighttpd, you need to place the Base64 encoded DER form of both the private key and the x509 certificate in /usr/local/solusvm/ssl/solusvm.pem and then restart the Lighttpd web-server.

You may need to edit /etc/lighttpd/lighttpd.conf and set “ssl.ca-file” to be the path to the Base64 encoded DER form of the x509 certificate intermediate certificate for your Certificate Authority.

For Nginx, you place the Base64 encoded DER form of both the private key in /usr/local/solusvm/ssl/nginxcert.key and the Base64 encoded DER form of x509 certificate in /usr/local/solusvm/ssl/nginxcert.pem then restart the Nginx web-server.

If you need to include an intermediate certificate for your Certificate Authority, then this also goes in the /usr/local/solusvm/ssl/nginxcert.pem file in Base64 encoded DER form.

Disabling highlighting of objects in Zimbra web UI

February 5th, 2012

Zimbra has a couple of Zimlets (plugins) that highlight parts of messages when viewed in the Zimbra Web Console such as dates, phone numbers and e-mails and turn them into special contextual links. Whilst this functionality is often quite useful, sometimes you just need to see the raw, unadulterated e-mail without your client interfering with the content – particularly if you are testing e-mail designs!

You can either disable Zimlets server wide through the admin console, or on a per-account basis using the preferences. In particular, look for the “Date”, “Email”, “Phone” and “URL Links” Zimlets as these are the four of the default Zimlets in Zimbra 7.x that are responsible for highlighting parts of messages and turning them into contextual links.

Convert SolusVM from Lighttpd to Nginx

February 4th, 2012

Historically the brilliant SolusVM VPS control panel have used the Lighttpd web server on their master and slave nodes, however it is now possible to use the popular Nginx as an alternative web-server.

I’m a big fan of the performance and flexibly of Nginx, not to mention that in my opinion the Nginx configuration files are just much easier to write and maintain than Lighttpd.

Thanks to a nice, easy to use installation script, the process of converting the SolusVM master server/node from Lighttpd to Nginx, just requires running the following commands:

wget http://files.soluslabs.com/solusvm/nginx/nginx-master-el5-x86_64
chmod 755 nginx-master-el5-x86_64
./nginx-master-el5-x86_64

And to convert each of your SolusVM slave servers/nodes from Lighttpd to Nginx, it’s just as simple:

wget http://files.soluslabs.com/solusvm/nginx/nginx-slave-el5-x86_64
chmod 755 nginx-slave-el5-x86_64
./nginx-slave-el5-x86_64

Both of these examples assume that you are running your SolusVM master and slave servers/nodes on a 64-bit CentOS 5.x system, however if you are using CentOS 6.x then just substitute “el6″ for “el5″ in each of these commands.

As part of the installation process, a new self signed SSL certificate will be generated for Nginx, leaving the original SSL certificate used by Lighttpd in it’s place in case you need to roll back for any reason. The roll back is simply a case of stopping and disabling the Nginx and Spawn-FCGI services before re-enabling and starting the Lighttpd service:

chkconfig nginx off
chkconfig spawn-fcgi off
chkconfig lighttpd on
service nginx stop
service lighttpd start

RIP Steve Jobs

October 5th, 2011

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/

Unable to send attachments in Horde

September 29th, 2011

I recently came across a bizzare issue in the version of Horde webmail shipped with Parallels Plesk 9.5.2 where it would allow you to attach files to an e-mail you are composing, but when you send the e-mail the attachment never arrives. Sending the same attachment via the Atmail webmail client or a traditional SMTP client wasn’t a problem and the mail server logs didn’t indicate that the attachment was getting stripped, so it was eveidently never getting attached to the e-mail in the first place.

For some reason Parallels Plesk doesn’t specify a seperate ErrorLog for the Horde webmail.domain.com vhost in /etc/httpd/conf.d/zzz_horde_vhost.conf so all of the logs from Horde end up in the main Apachce HTTPD error log at /var/log/httpd/error_log.

In the logs there should be PHP errors where Horde is unable to load one of it’s shared libraries that is used for processing attachments:

PHP Fatal error: Can’t load Horde/Serialize.php, open_basedir restriction. in /usr/share/psa-horde/lib/Horde/SessionObjects.php on line 134,

The easiest way to fix this is to change the relative path to the file (Horde/Serialize.php) to an asbolute path, so take a copy of /usr/share/psa-horde/lib/Horde/SessionObjects.php as a backup then open the file up and
look for two lines that say:

require_once ‘Horde/Serialize.php’;

And edit these two lines to have the full path:

require_once ‘/usr/share/psa-horde/lib/Horde/Serialize.php’;

Now all you have to do is save the file and test that Horde has started working as expected. Remember that future updates to Horde from Parallels will overwrite this file and you will have to re-apply your change.

Windows Server 2008 with multiple IP addresses on one NIC

September 5th, 2011

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&gt 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