Category Archives: How To’s

cPanel Bug causing fixrndc to never complete on CentOS 6

If you are having problems on a recent cPanel installation on CentOS linux where /scripts/fixrndc starts and never completes this may fix your issue. I have noted that this is currently an issue on (at least) cPanel/WHM Release 11.32.3 but may also affect other versions.

After chatting with Michael from cPanel Support he has stated: “The basic issue is that on Centos 6 the /etc/init.d/named script needs to use the “portrelease” command before it can bind port 953. Such a line isn’t present in the default /etc/init.d/named script provided by the cPanel installer. Reinstalling bind installs a working /etc/init.d/named.”

This can manifest in the following ways (I have found so far):

  • EasyApache pauses on /scripts/fixrndc and never completes
  • Initial server GetStarted Wizard does not complete setting up bind and gets stuck
  • /scripts/upcp –force freezes and does not complete

These are the cases I have seen thus far. If you run /scripts/rndc manually you will likely get the following output:

warn [fixrndc] /usr/sbin/rndc status failed: WARNING: key file (/etc/rndc.key) exists, but using default configuration file (/etc/rndc.conf)rndc: connect failed: connection refused
warn [fixrndc] /usr/sbin/rndc status failed: WARNING: key file (/etc/rndc.key) exists, but using default configuration file (/etc/rndc.conf)rndc: connect failed: connection refused
Restarting named
warn [fixrndc] /usr/sbin/rndc status failed: WARNING: key file (/etc/rndc.key) exists, but using default configuration file (/etc/rndc.conf)rndc: connect failed: connection refused

The simple fix for this is to reinstall BIND using yum. All you need to do is execute:

yum reinstall bind

And the problem will be fixed. Michael has informed me that this will be fixed in a future update to cPanel. Kudos to him and the cPanel support team for getting me back up and running in RECORD fast time.

Stuart :D


Computer errors for beginners… tips and tricks for getting help

In the realm of computers it is definitely not uncommon to get the occasional, or sometimes annoyingly regular error. However, one thing that many people do not know is some simple steps that can be taken to make a support team’s life easier in diagnosing the issue.

First and foremost it is important for both you, and who will be supporting you to realise that it is possible that your level of knowledge surrounding the error will be lower than that of the support team. While this is not always the case, (I will happily admit I have had clients teach me a trick or two before) it is the general rule of thumb.

A good support person will gauge the level of knowledge of the person who is seeking assistance and balance their explanations to a level that can be understood. However if you find someone is talking to you on too low, or too high a technical level, never be afraid to let them know and try to get them to talk to you on your level of knowledge. By doing so you can work more effectively together and also learn things which may help you in future.

The Checklist:

The checklist is something that those of us in support use day to day. Even as a systems administrator, I collect this sort of information to pass on to vendors for support and so on. However whatever your level of knowledge of computers, or level of support you are liaising with, this list can be of great use.

So next time you have an error on your computer note down the following information, it will make support’s life easier, result in a much faster resolution for you and assist support in documenting the issue for future reference.

  1. Take a screenshot: this may sound simple but so often people don’t do it. If someone says “I got an error” and we can’t tell exactly what the error is, it makes it impossible to trace down what the problem may have been. Taking a screenshot saves the need for you to try to interpret or note down the exact error and greatly assists support teams.
  2. Note down the exact time and date of the error or issue (including any subsequent occurrences): knowing the exact time and date that the error occurred allows support teams to investigate other factors that may have been occurring at the time. They can also look at logs of related systems surrounding the time your issue occurred to gather additional information.
  3. Note down exactly what you were doing leading up to the error occurring: in some cases errors can be triggered by an exact sequence of events that occur leading up to it. Knowing what you were doing that lead to the error can help to reproduce the error.
  4. If you are using a web browser, note down the browser you are using and the browser version (usually under Help –> About), also try a different browser such as Google Chrome or Firefox, see if the same error appears, note down if it works in a different browser.
  5. If it is a website that is having problems, try a different web site as well, note down the original web site URL that was having problems, as well as any other sites you tried.
  6. Try to note down any related information to what you were doing: for example if it was an email that you sent that was never received, provide the exact subject line of the email. If it is a file on a shared drive, provide the exact name and file location to the file. The more information you can provide, the less likely that support will need to come back asking for the additional information, leading you to a faster resolution.
  7. Let support know if you are on a PC or a Mac and what version of the operating system you are using (such as Windows XP, Windows 7, Mac OSX Lion 10.7.4 etc), if you are unsure of the version at least letting them know if you are on a Mac or PC is a great start.

Tell the truth, the whole truth and nothing but the truth

Most of all, don’t be afraid of telling support exactly what happened, we all start out somewhere and often support will come across an issue that simply needs user training, by us being able to pass knowledge on to you it is likely that you can do the same for someone else to make all our lives easier.

However if it is something that you have done wrong, often it will save support a lot of time and effort knowing exactly what has occurred, I am always of the mindset that if you do something wrong, then tell me so that I can fix it faster I will be a lot less unimpressed than if I have to find it out the hard way.

By noting down these details, whoever will be helping you out with your issue will be able to far more easily diagnose what occurred help you out. If you are having an issue with a problem you purchased on the internet, don’t be afraid to contact their support too. By providing the information above you have a great start to finding out exactly what problem may have occurred and should be able to work towards a resolution.

So whether you are a beginner in the tech world or a seasoned veteran like myself what are your thoughts. Have I missed anything out here?


Change tmp directory for CrashPlan on OSX

I have been an avid user of CrashPlan for quite some time, therefore I have dabbled in how to tweak it under the hood (especially in the case of Linux systems). Recently I had the need to move the tmp folder for Crashplan off my primary HDD and onto my secondary HDD. For the purpose of this article I will not go into why you might want to do this, that is up to you. However one issue I found was that there was no documentation anywhere describing how you would achieve this on Mac OSX Lion (and this should in theory work for any other recent version of OSX).

So, if you would like to have a custom temp directory for Crashplan on OSX perform the following steps:

  1. Back up your system… back up early back up often (I always like to throw this in).
  2. Do this ONLY if you know what you are doing, when you follow the next step if you don’t know what you are doing you can do permanent damage to your installation that may require a complete re-install to get around.
  3. Open a terminal and run ‘sudo bash’
  4. Backup /Library/LaunchDaemons/com.crashplan.engine.plist
  5. Edit /Library/LaunchDaemons/com.crashplan.engine.plist and add the following lines after the line which specifies DCP_USER_HOME.
  6. Stop the CrashPlan service
    launchctl unload /Library/LaunchDaemons/com.crashplan.engine.plist
  7. Start the CrashPlan service
    launchctl load /Library/LaunchDaemons/com.crashplan.engine.plist

Please note, if/when an update is pushed out by CrashPlan this may get overwritten so you may need to apply the fix at such a time.

Hope this helps someone else out at some point.


Holiday development – a geeks way to unwind

So as I was lucky enough to have a few days off over the break I felt it was time to haul my butt into gear and get some development work done. I have managed to get a good few productive days work in and have the following outputs to share with the world.

Firstly for you bloggers, if you have heard of and other such URL shortening services, you might be curious to check out YOURLS, which is essentially a self hosted URL shortener. I will leave it to your own decision as to why that might tickle your fancy but I have written a plugin for YOURLS which provides a social toolbar on shortened URLS.

You can check out the YOURLS Social Bar page on my Technical Wiki for all the details, if you have any feature requests please let me know so that I can start working towards the next major release.

The second item I have been working on is how to get the Atlassian Crowd Authentication connector for Apache compiled on a CentOS System running cPanel. To be honest unless you use the Atlassian suite of products AND run a cPanel server this second one probably won’t interest any of you that much but hey, it is definitely an achievement that I am proud of. You can check the how-to out on my wiki –>  Compile Atlassian’s Crowd authenticator on CentOS server with cPanel.

So that has been my few days relaxation and enjoyment :D. Geeks and Open Source software FOR THE WIN :D.


Posting a project to vWorker or

After having a good handful of projects that I have put up on vWorker (formerly I thought it was time to put together some information on lessons that I have learned, some gotchas that could be useful for others to know and things that you should look out for.

The document was written with my experiences from vWorker in mind however the same processes and ideas could be applied to any such project site including sites such as

I look forward to feedback, if you have any other experiences, hints or tips please let me know and I will incorporate them into the document.

Guide to putting projects onto vWorker/RentACoder/

Stuart :)