Find out which mail transfer agent is running on your box by using the alternatives program

MTA (Mail Transfer Agent) – Find out what’s on your linux server

For the reasons behind why I needed to find out what my MTA was, you should check out this post detailing an error that occurred with qmail – “CNAME lookup failed temporarily. (#4.4.3) I’m not going to try again; this message has been in the queue too long.”

A quick snippet of information for those looking to find their active mail transfer agent is to issue, as a privileged user, this command at the terminal:

Which should yield something similar to the following output:

What did we just run?

Alternatives, in its most basic form will let you know information about all the different symbolic links that you specify. alternatives and its usage can be more accurately defined by its man page on:

alternatives creates, removes, maintains and displays information about the symbolic links comprising the alternatives system. The alternatives system is a reimplementation of the Debian alternatives system. It was rewritten primarily to remove the dependence on perl; it is intended to be a drop in replacement for Debian’s update-dependencies script. This man page is a slightly modified version of the man page from the Debian project.

It is possible for several programs fulfilling the same or similar functions to be installed on a single system at the same time. For example, many systems have several text editors installed at once. This gives choice to the users of a system, allowing each to use a different editor, if desired, but makes it difficult for a program to make a good choice of editor to invoke if the user has not specified a particular preference.

Email-Logo

CNAME lookup failed temporarily. (#4.4.3) – Possible Workaround

One of the servers in my workplace was giving strange bounces the other day, relating to CNAME DNS errors, specifically they consisted of the following reason:

I didn’t have much time to research the issue, unfortunately, but I did find out why this might be happening.

Turns out that qmail, the MTA that was running on my server (I wrote a post about finding out which MTA was running on a linux server here) has a problem where if an ANY DNS query returns a response longer than 512 bytes, qmail eats itself.

I particularly found the following post very interesting and enlightening by ispcolohost:

All of the senders experiencing the bounced messages mentioning cname lookup failure appear to be running the qmail mail server software. Qmail, if not using a third party patch that was written in the late 90′s, has an issue sending to domains whose name servers respond to DNS queries of type “ANY” with more than 512 bytes of data; that is a bug in qmail and the author has never fixed it because he wants you to use his DNS server software which also eliminates the issue in a different way. Google’s name servers do respond to queries of type “ANY” with more than 512 bytes of data, so when an unpatched qmail server tries to send an email to a domain whose lowest cost MX record ends in .google.com, qmail is going to do a DNS query of type ANY against one of google.com’s authoritative name servers, get back more than it can correctly handle and defer repeatedly until ultimately bouncing the message with that cname lookup failure…

To read more (it really is a great post) at:
https://productforums.google.com/d/msg/apps/mIGTQVZiFxo/ULesU7hOo6wJ

So, what’s the (possible) fix

There are a couple of ways you could get around this infrequent problem. I’d love to give you step by steps on this, but due to the differences in your OS, architecture and particular setup, I don’t think I could it justice. Therefore, why not think about the following courses of action:

  • Patch qmail – Read this page for more detailed info on patching http://www.memoryhole.net/qmail/#oversize-dn
  • Replace your MTA with another, such as Postfix or Exim – This will be different depending on your distro and configuration, maybe you could ask your host nicely to do it for you if you’re on a compatible environment
Dog knows all about localhost and TCP/IP pipes

127.0.0.1 vs localhost with PHP / MySQL – Which is faster?

So I learnt an interesting tid-bit of information today.

I’ve always wondered which is the faster notation for connecting to a local MySQL installation, 127.0.0.1 using TCP/IP or using localhost when specifying connections.

Well as it turns out, it differs depending on your environment!

Linux: localhost

For Linux operating systems, use localhost, which will invoke the use of something called a unix domain socket to make the connection, which is slightly faster than the TCP/IP stack.

Windows: 127.0.0.1

Conversely, in Windows environments, use the TCP/IP stack (which ironically is also a type of socket, named pipe apparently) by specifying 127.0.0.1 instead.

Specifying the IP in Windows environments could also avoid problems in certain releases, where IPv4 and IPv6 routing was confused.

Look after the pennies…

This shaves a couple of milliseconds off the time of execution. It may not sound like a lot, but if your apps open many connections, it could add up.

From the PHP site:

Whenever you specify “localhost” or “localhost:port” as server, the MySQL client library will override this and try to connect to a local socket (named pipe on Windows). If you want to use TCP/IP, use “127.0.0.1″ instead of “localhost”. If the MySQL client library tries to connect to the wrong local socket, you should set the correct path as in your PHP configuration and leave the server field blank.

Osclass: “Please check your permissions.” Plugin Fix – Open Source Classifieds

So I’m trying to install plugins on Osclass when suddenly, a wild error appears!

Problems when copying files. Please check your permissions.

Hmmm. Permissions. I was trying to download from the OSClass marketplace…

The fix

Change your plugins directory to be public writable. On my server it was:

Simply change to the correct working directory for your particular installation.

Find & Check Email Mailbox Passwords on Plesk 9/10/11

Just a quick command for you Plesk control panel users out there that might save you a bit of time.

A Password, My Kingdom For A Password

Say you look after a lot of websites, and all those websites have various email addresses created for them. Often finding passwords, when say, one of your colleagues changes a password without telling you, or doesn’t record it all when created, can be mega-frustrating!

Besides, you probably also have IMAP users relying on their mail access, so you can’t just go ahead and change their password without getting up off your arse and reconfiguring their email, whilst simultaneously disrupting their service while you’re at it.

Wouldn’t it just be so much easier to grab the password from Plesk itself? I mean, you’ve got full admin access right? Wrong. Plesk’s web interface won’t tell you. So issue the following command providing you have shell access to your Plesk based server.

Ta da!

Hope it helps!

Site Error: Unable to Load Site Preferences; Invalid Preference Data – ExpressionEngine Error

I recently got the following error trying to upgrade an Expression Engine installation:

Site Error: Unable to Load Site Preferences; Invalid Preference Data

What I found out was that because I was using the Multiple Site Manager (MSM) from Ellislab, somehow the exp_sites table within my database had become empty!

In my case, a re-install fixed this problem, however if you’ve tried this and still no joy, there’s another set of steps you can try according to this Ellislab forum post.

  1. In your EE 1.x database, navigate to the exp_sites table and find the column site_system_preferences. Copy the data from this column.
  2. Use the utility at Online PHP Unserializer to unserialize the data. Copy it into the field, do not check the box labeled base64 decode, and click “Unserialize!”
  3. Now on the resulting page, scroll down to the bottom, this time do check the box labeled base64 encode, and click “Re-serialize!”
  4. Copy the contents of the box titled “Re-serialized output”.
  5. Now open up your EE 2.x database, and navigate to the exp_sites table to find the site_system_preferences field. Paste and save here the data you copied from the box in the previous step. (If you’re running an MSM site with multiple rows in your exp_sites table, you’ll repeat steps 1-5 for each one.)
  6. Now log in to your CP and double-check all your settings and preferences, especially things like site URL and forum theme path, etc.

Paul

Secure Shell by Google is Fantastic

Ok, I’ll admit it. I worshipped at the altar of Putty.

There. I said it. I was unwilling to change, unwilling to give up the cozy confines of my highly-configurable desktop application. I had it looking amazing with slightly transparent backgrounds and hot pink text (because hot pink is cool), and multiple tabs with Putty Connection Manager. It looked like a scene from The Matrix, and equally as cheesy.

But then, Chrome came…

And along with that the world of chrome extensions. And a bit later Windows 7 came and Putty Connection Manager stopped working (I know, my work PC is out of date).

One such extension I found by chance was Secure Shell, written by Google, it provided access to shell terminals within my favourite browser, and it soon became my brand new favourite extension.

Yes, it has it’s problems. Namely I can’t customise it to look like Mimura’s computer from Battle Royale, but that’s beside the point. I can have all the websites hosted on a particular server in one tab, whilst moving SQL databases and migrating sites in another tab – and check the results without swapping application! And, I can be monitoring all our dedicated servers at work in four tabs funning htop, a tab per server. How freaking cool is that.

It’s won me over. But I’m easy. Easy like Sunday morning.

There are stopped jobs – What does that mean?

So I was rolling around on a server the other day in the terminal and when I went to exit I saw this:

I figured I’d write a little post about it as it confused me the first time I saw it, and here’s to helping out the next guy!

It simply means that the shell is reminding you that a process or processes that you’ve started in your session are suspended and terminating your session will force those jobs to be killed. Graphic I know.

To work out what jobs you have running, simply type:

jobs

In my case it was an instance of vi that I had left running:

I didn’t need that anymore, so I decided to kill it by typing logout once more. If however, the shell saved your bacon and you really needed that stopped job, then simply type:

To bring that job back into the foreground where %n is the number of the job you want to bring back to life.

Increasing PHP’s upload_max_filesize on a Plesk 9 server with a single domain or sub-domain

I spent a little time trying to work out how to change the values of the PHP environment on one of our dedicated servers that was configured with Plesk and a 100 multi-domain license.

The server was configured as with the following specs:

  • Plesk 9.5.4
  • CentOS 5.7 Final
  • PHP 5.2.17
  • Apache 2.2.3

One of my colleagues was butting up against a problem where he couldn’t upload a file into ExpressionEngine File Upload field because it was too large and exceeded PHP’s set limit of 2M (megabytes). We were going to upload files of up to about 50Mb on this server, so this obviously needed changing.

The first thought I had was ‘Oh great, I can just change the /etc/php.ini configuration file’… But then I realised, if I changed that, it would change for all of our domains on that box, and not just the one I wanted to edit. Specifically I wanted to change just one sub-domain’s properties while we were developing a new site.

So I looked around for a bit, and decided to check out how Plesk generated the files needed by Apache to display each virtual host. It led me to /var/www/vhosts/mydomain.com/conf/httpd.include, and for a brief moment I thought I’d struck gold. It was not to be. On the top of this file contained the following, and dare I say it startling, warning:

So obviously, this was not the right file for me to be editing. I read and re-read the warning and decided to do exactly what it said.

Step One – Edit (or create if it doesn’t exist) your vhosts file

I issued the following command. Depending on your distro you may not have nano installed on your system. In which case substitute the following for vim or emacs as you see fit. It will either edit an existing vhost.conf file or create a new empty one with the same name. I roll as root, you will need to issue a sudo, or su before you perform the following commands.

Step Two – Set your PHP configuration variables

I pasted the following into a new vhost.conf file (you may want to think about backing up and existing one if you have one already). Simply copy and paste the following directives, replace the parts in bold with your specific site and subdomain, and the size you wish to allow.

Step Three – Rebuild the Plesk server vhost configuration

The next step allows Plesk to edit it’s own httpd.include files with the location of our new vhost.conf file. This step is important as your directives won’t be initiated without it. Once again replace the bold parts with your domain. If you get any syntax error messages at this point, go back and check what you’ve input is correct.

Step Four – Restart Apache and apply the changes

The next step restarts Apache and applies your changes.

This step may differ with each distro, but you can easily find the command that will restart apache by using your favourite search engine.

That’s it! Your changes should be applied, and if you upload a file to your domain / subdomain. You can use a PHP file with phpinfo(); to view your local variables to ensure it’s picked it up correctly