For example, I am currently using something like:

/usr/sbin/cxs –report /var/log/cxs.scan –logfile /var/log/cxs.log –mail reports@myhost.co.uk –vir -I /etc/cxs/cxs.ignore –options mMOfSGChednWZDR –script /root/cxswatchscript.sh –xtra /etc/cxs/cxs.xtra -Z –sum -F 200000 -C /var/clamd -T 10 -B –allusers

the script defined above, /root/cxswatchscript.sh, receives 4 arguments from CXS

$1 = filename
$2 = option triggered
$3 = message reported
$4 = account name

As I wasn’t sure if I could get away with running a perl script directly, I use cxswatchscript.sh as a wrapper. cxswatchscript.sh contains:

Then cxswatchscript.pl contains:

The reason I don’t use the “Option Triggered” argument (the second one) is that ClamAV also picks up some javasript viruses, and while these things might technically be a virus, they don’t pose a threat to the server, and I wouldn’t want to suspend a user account based on finding one. The perl script allows us to be far more selective in the conditions that lead to a suspension.

• Got ConfigServer Exploit Scanner – CXS – installed on your cPanel/WHM server?
• Doing a full server scan every now and then, and getting swamped with the reports?
• Want a script that will trawl the reports, and email the cpanel users with their problems automatically?

Then you came to the right place!

Requirements

You need to have CXS installed, and you need to be generating a Scan Report Log file after your periodic scan. This is the file that is in this sort of format:

Jan 21 02:34:45 apollo cxs[526881]: ['/home/username/public_html/thingybob.info/adsense/volume1.zip'] – ClamAV detected virus = [HTML.Phishing.Bank-581]

It’s important to ensure this file is truncated before each CXS run, otherwise you will be sending out an ever increasing number of warning emails each week!

This Perl script also uses a couple of Perl modules that are normally available by default – Email::Valid and MIME::Lite

That’s it!

Just pop the script somewhere safe, and cron it to run a safe time after your cxs scan is schedules to run (to make sure it parses the completed log file). It will email (via Sendmail) a report to each cPanel user (via the cPanel account’s contact email address) with their affected files in an attached text file.

Version 2!

This version is now aware of resellers, and will email the reseller instead of the cpanel user directly.

Oh, yes, and obviously, you use this entirely at your own risk – absolutely at your own risk!!!

You may find instances where a local user tries to send mail to a host that operates greylisting. The messages never gets to the recipient. You see things like this in the exim_mainlog

Possible simple reasons for messages failing due to greylisting

Queue Interval time

Now, I’m assuming here that you have a sensible queue retry interval set in the exim command ( the -q switch ). You can check this by running

ps aux | grep exim

and checking the output…

/usr/sbin/exim -bd -q15m

The -q15m above means the queue is running every 15 minutes. In a WHM/cPanel environment you should set this in the Tweak Settings > Mail section.

If your retry interval is too long, you may miss the greylist window, and get greylisted again upon retrying, and thus eventually the message will fail.

Max load queue runner sleep factor

By default, exim will not run the queue if the system linux load average goes above 3.00 – on a modern server with a dozen cpu cores this is a patently silly value. The value should really be set to at least the number of cores on the machine. The actual exim config variable concerned is deliver_queue_load_max.

You can adjust/over-ride the value in the default exim.conf file by adding this to the first box at the top of the advanced exim config screen in WHM.

deliver_queue_load_max = 12

More tricky reasons for messages failing

Exim uses a number of hints databases. On a cPanel server, these are in /var/spool/exim

First thing to do is check what exim thinks the next retry will be for your failed message:

Now. In this instance I know the message was only sent on 16th Nov so there must be a bug somewhere for exim to think it was first sent on 03rd Nov.

My first try was to run

# exim_tidydb -t 7d /var/spool/exim retry

This removed a whole bunch of retry data from the database, but to no avail. Exim still had any message going to this domain as originally failing on the 3rd Nov.

I then decided to rip out the data for this domain directly using exim_fixdb. The man entry for exim_fixdb is a bit dry, and doesn’t really tell you how to identify the record keys, but it’s actually quite easy once you find out how!

First, search the database for your suspect domain:

The key to the hints database record is

R:remoteuser@remotedomain.co.uk:<localuser@localdomain.co.uk>

So, now just run exim_fixdb

the d command just deletes the most previously viewed record. That’s it! Now run exinext again:

# exinext kismarketing.co.uk
No retry data found for kismarketing.co.uk

That’s it – any messages sent to the remote domain should now retry properly again.

Enjoy.

• I don’t like being forced to upgrade to iCloud
• I don’t like being forced to upgrade to Lion to use iCloud
• As a user of Adobe CS5 and numerous peripherals for photo/print etc, I can’t see how upgrading to Lion is going to make anything easier for me (actually the reverse)
• I felt it was time to move my online self to a domain that I control, instead of me.com or mac.com

So, how to do it? I run a number of Macs, and an iPhone so whatever I choose has to work on both, and be relatively painless. This guide isn’t for total beginners, I wish I had the time to describe every step in detail with screenshots, but anyone with a sense of adventure should get through this guide without difficulty.

Step 1 – buy a domain

OK, so I got myself a domain, for the sake of argument mrsant.co.uk – that was the easy bit.

Step 2 – sign up to Google Apps Free

Again, this was pretty easy. I just went to

http://www.google.com/apps/intl/en/group/index.html

And went through their sign up process. You will need to verify your domain by adding a dns TXT record to the zone file, or by uploading a file to the website for your domain – but this is straightforward and much the same as verifying a website for use with Google’s Webmaster Tools or Analytics.

Once you have verified that you own the domain, then you need to active the services. Activating your email in Google Apps will require you to configure the MX records for your domain to point at Google’s mail cluster.

You will be asked at some point if you want to set up other users – just select No at this stage as we are only interested in setting up the first mailbox account.

Once you have got this bit done, you should be able to log into Google using your new email address (e.g. steve@mrsant.co.uk) and start using gmail in the way you already know and love.

Step 3 – Configure mail.app for Google Apps

OK, this is where I learnt a few things about how Google handles IMAP folders and how mail.app can be configured to work with it.

Enable IMAP access for your Google mailbox. This is done in your mailbox settings (click the gear/cog icon top right of your Google mail window) > Forwarding and POP/IMAP tab. Leave the options as default (Auto-Expunge on).

Now, in mail.app, just set up your account as follows:

And the SMTP settings that matter…

Mailbox behaviours that work for me

And finally, the advanced settings

Getting the folders to behave themselves

To prevent mail.app from creating extra folders in the gmail system you must tell mail.app which folders in the Google Apps mailbox to use as the default Sent Items, Trash, Junk, and Draft. You do this by expanding the new Gmail mailbox in mail.app’s left column, and selecting each folder in turn, then selecting from the mail.app menu, Mailbox > User This Mailbox For > [Draft, Sent, Trash, Junk]

Once you have done this correctly, you should just be left with the Starred and Important folders, as shown in the screenshot opposite.

About Gmail’s folder system

Gmail (Google Apps mail) uses a slightly funky system for storing messages in IMAP folders. It’s actually pretty neat, and allows very effective use of space. It creates folders virtually from the labels you attach to messages in the web interface. So, if you have a message with a 10Mb attachment, and assign it to two labels, then it will only take up 10Mb in your Gmail account. Try it and see! However, when you view it using mail.app or any other IMAP client, you will see the same message in two folders. Unfortunately, on your Mac, if storing the messages locally (which I always do) then the magic is lost and you will be keeping two separate copies.

This is esoteric, and doesn’t really matter in day to day usage, but sometimes, you might want to find a message on your Mac, and you might think it’s gone… forever. But – there is an idiosyncrasy in the way IMAP clients interact with the labelling system. If you drag a message from a Gmail folder in mail, to a local folder on your mac, you might think yo uhave removed it from your Google account. You haven’t. What you have done is remove Gmail label from the message in the Gmail system, and copied the message to your local Mac disk. The message will still exist in the  Gmail account in the “All Mail” folder.

The “All Mail” folder in Gmail is (you guessed), another virtual folder, but this one is a bit special. It contains all messages including those that have no labels at all… i.e. those messages that do not appear in any folder in an IMAP client such as mail.app. So, if you can’t find a message in Mail.app, then there is always a slim chance it might be buried somewhere in your Gmail account.

Currently, there is no easy way to filter out all unlabelled mail in Gmail. This is something that people have requested for years, but Google have not yet provided.

The Problem

Your customer has a website at www.mycustomer.com – this is pointing at an ip address of 1.2.3.4 and everything is hunky dory. You have been engaged to build their new website (lucky you!) and you have either beavered away using WAMP or MAMP locally (if you are running your home compiled copy of apache then you shouldn’t need to read this article!), or maybe you have just developed the site on a temporary domain using another hosting account.

Whatever method you have used to develop your site, you now find yourself in a position where you need to move it to the final production hosting server, and you need to change the nameservers, or the DNS records for your customer’s domain to activate the new hosting.

But… you haven’t been able to fully test the installation because your site isn’t static, probably relies on mod_rewrite for those SEO friendly URLs and the mod_userdir solution offered by the hosting company, http://hostingco.com/~username/yoursite just won’t work with most modern sites. So, there’s no way to actually see the site running before you throw the switch, as it were.

How many times have you transferred the DNS to point at the new server, biting your nails in the hope that everything will “just work”… how’s that working out for you, eh?

The Solution – introducing your hosts file

The solution is to “cheat” your development PC into thinking that www.mycustomer.com (your customer’s new website) actually lives on the new hosting account, and not the old one. You do this by modifying the local hosts file (yes, local space hosts, not localhosts).

Whenever your computer tries to resolve the IP address of a website (lets assume we’re looking for www.mycustomer.com), it follows (roughly) this sort of a pattern…

1.) do I have an entry for www.mycustomer.com in my local hosts file?

2.) do I have an entry for www.mycustomer.com in my local DNS cache that hasn’t expired?

3.) ask my ISP’s DNS servers to get the IP address for me.

If the process succeeds at stage 1 or 2, then it stops looking any further. This saves time, and makes life easier for the global DNS system.

So, if your new hosting account has an IP address of 77.72.7.58 then all we need to do is tell your local PC that www.mycustomer.com lives there. And here’s how you do it!

Windows

C:\Windows\system32\drivers\etc\hosts

The bit in orange may change depending on where Windows is installed, but this is the default.

A default windows hosts file looks something like this:

You just need to add onto the end, something like:

Just open the file using notepad, and you’re away!

Mac or Linux

On a Mac and any flavour of Linux I’m aware of, the hosts file lives at

/etc/hosts

simple, eh? Again, the default hosts file doesn’t contain very much, usually just something like:

So again, all you have to do is add the following

Depending on your setup, you may not have permissions to edit this file. The best way to edit it is via the command line using something like:

If pico doesn’t work, try using nano. I’m not covering vi because, again, if you know vi, then you won’t need this article!

The result

Thats it! You should now be able to ping the address mycustomer.com or www.mycustomer.com and get the IP address of the new server. If ping is giving the right results, then so should your web browser – go and give it a go! If your web browser is not giving you the content from your new server, then clear it’s cache to make sure.

Now you can launch that new website with absolute confidence that it works properly! When you finally go live, just remove or comment out the entries from your hosts files by putting a hash # at the start of the lines. Remember NOT to remove or comment out the 127.0.0.1 localhost entries or you will break your computer’s networking facilities.

If you are running a hosting company, then you have either mitigated the issue somehow, or your helpdesk is probably still hung over from the after effects of exploited timthumb scripts.

So, cutting to the chase, here’s a script that I have used to run through whole cPanel based servers, looking for files called timthumb.php or thumb.php, which contain the text “timthumb” (almost every instance I have seen of the script contains this code in it somewhere).

It then moves/renames the file to something safe, and copies over the latest source from a location you can tweak in the script, and then sets the ownership and permissions correctly (assuming you are running suPHP).

The bash script:

Obviously, the usual disclaimers apply here – You are free to use this script, but NO responsibility can be accepted for anything that goes wrong if you choose to!

This is actually version 2, as it were – I have modified the script so that it now looks for the version number within the script and only updates versions that do not match those shown in the if statement.

However, if like most pilots, you fit your AWARE unit in a removable manner, Section 2 on page 4 of the TIL (specifically section 2.1) asks “Lanyard fitted – Ensure GPS is not a hazard if supported only by the lanyard.”

OK, I’m not knocking the AWARE or Airbox in any way. I love my Aware, and heartily recommend one to anyone who wants a simple GPS device to help keep themselves away from controlled airspace – but…

It’s ironic that the AWARE, developed by Airbox in association with NATS, and supported by the BMAA with it’s own fast track TIL minor mod submission, doesn’t actually have a Lanyard loop anywhere on it’s shiney orange and black casing.

To make an omelette

To make a lanyard hole I needed to know where to drill (oh my! there goes the warranty!) two holes. So, it was time to take the back off. Doing so would also reveal the location and type of LiPo battery powering the unit – thus making it easier to replace in future.

Note: I really shouldn’t have to say this, but taking your AWARE apart is at least going to invalidate the warranty, and if you’re ham fisted, quite likely to end in tears…

The case is a bit fiddly to open up – 4 tiny grub screws (circled in BLUE) hold the back of the case to the orange screen mouting frame, so whizz those out, and then there are four snap tabs on the inside of the case loacted as shown below (circled in RED):

You just have to sneek a small blade/tip into the gap between the black and orange plastic to locate these and apply a bit of pressure to click them free. Be carefull not to push too hard and break the tabs!

I first considered the corner where the speaker is mounted but discounted this as it would be too weak, relying on a little bit of the black casing, which is pretty thin.

The better solution would be a single hole near the stylus hole itself. If drilling into the case blind while it is still assembled, be VERY careful, as if you bodge your drill bit in too far you may rupture the LiPo battery with spectacular results… The drill bit should not go in any more than 2mm.

Once drilled, pass a nylon tie/zip/cable wrap into the stylus hole, and out of the new hole in the case and pull it tight. A standard/generic lanyard can then be fitted around the exposed portion of the cable tie and fixed to a point in the aircraft (or the mounting bracket – see below). Although this denies the stylus it’s storage hole, this is a very strong solution, which easily passed a 9G load test.

Another solution

Large piece of PCB circuit board glued to the back of the case with a hole in! – Hysol 9462 is probably one of the better epoxies to do this with.

Mounting bracket

We used the RAM-HOL-PD3 universal PDA mount in our Skyranger, which has plenty of opportunity for an extra hole for a lanyard fitting. It’s a great mount, with a spring loaded side claw, so popping the GPS in and out is easy.

Install Tweetdeck… Open Tweetdeck… then go back to Illustrator – and hey presto! No longer do i have to log out and back in again to get round this REALLY annoying bug.

Enjoy!

The screenshots were taken from my iPhone 4 runnng iOS 4.3.x. So, lets start.

Tap the Settings icon on your iPhone’s home screen. This will bring you to this screen (below).

Tap the Mail, Contacts, Calendars icon tp get the following screen.

OK, now tap the Add Account… icon to get the following screen

Tap Other

You guessed, tap the Add Mail Account icon (not too hard, is it?)

The New Account screen takes the basic details of your account:

• Name – This is the friendly name that will identify your outgoing emails (e.g. Steve Sant).
• Address – this should be your full email address for the POP3 or IMAP account.
• Password – This is the password that was configured for the mailbox (NOT your cPanel password).
• Description – this is just to help you identify the account in your settings later – call it anything you like.

Then tap Next at the top of the screen, which will bring you to the following screen.

Choose whether you want to connect using POP3 (messages downloaded locally to your iPhone) or IMAP (messages are kept on the server so you can also read them from your home PC/Mac). Just remember if you are using IMAP that you will start using up your user account space quota.

You will need to fill in the following:

Incoming Mail Server

• Host Name – This is almost always mail.domain.com – so if your email address is tommy@finger.co.uk, then your mail server is almost certainly mail.finger.co.uk
• User Name – For cPanel accounts, the account username is always the same as the mailbox address – if you are not using cPanel then you might have a different user name, but it will still be provided to you when you create your mailbox.
• Password – This should already be filled in for you, but if not, then enter your mailbox password again here.

Outgoing Mail Server

• Host Name – Again, this is almost always mail.domain.com, the same as your incoming server.
• User Name – Use the same details as you entered for your incoming mail server, above.
• Password – This should already be filled in for you, but if not, then enter your mailbox password again here.

Tap the Next button, at the top to verify your settings.

At this stage, you may get one or two responses from your iPhone:

1.) The SSL Certificate on the mail server you are trying to connect to, doesn’t protect the server name you specified

It is very likely that at this stage you will receive a Cannot Verify Server Identity warning. This is because the SSL certificate that is protecting your mail server is probably assigned to the main server name, and not your individual domain. If you contact your hosting provider, they should be able to tell you the right server names to use, to avoid this error.

You have two choices here. Continue, and ignore the message, or press Cancel and swith to using a NON SSL connection.

In all respects, it’s probably better to press Continue and ignore the problem. Although, strictly speaking, means that if you accidentally connected to another server (unlikely) or if you were the victim of DNS poisoning you wouldn’t know about it, it’s still a more secure choice than going with a NON SSL connection (which is still just as vulnerable to DNS poisoning).

2.) Your iPhone Cannot Connect Using SSL

This simply means that your mail server doesn’t offer the facility to connect using SSL. To be honest, if you get this, then there is something amis with your hosting provider’s server or, infinitely more likely, you have entered the wrong details somewhere. So tap No and go over everything again!

If everything worked out (and in most cases it should), then great! If you still can’t connect to your outgoing server, then read on…

Still got problems?

Advanced Incoming Mail Server Settings

If you need to alter advanced settings for your incoming server, then tap the Advanced button at the bottom of the account settings screen :

This will give you the following screen :

Here you can choose if you want SSL, the type of authentication, and when messages should be deleted from the server, if ever. You can also choose to use a non-standard TCP Port.

Advanced Outgoing Mail Server Settings

If you need to alter advanced settings for your incoming server, then tap the SMTP button at the bottom of the account settings screen :

This brings you to this screen :

You should see your chosen server at the top (as your Primary Server). All of the other servers should say Off (unless you are an expert, in which case you shouldn’t be reading this guide!). Tap on your Primary Server at the top, to bring you to the following screen :

Here you can configure the Host Name, User Name, Password, Use SSL, Authentication method, and TCP Port.

Many large ISPs block you from using SMTP servers outside of their network. You may run up against this problem if your iPhone connects to your home WiFi network and your home broadband is with one of the big providers in the UK or USA.

This is usually circumvented by connecting to your mail server using a different Port other than 25 (the default). For example, ziphost.co.uk use Port 525 as well as 25, so just change your Server Port to 525 and you you should get round the problem.

This information is not obvious on the PHP site, so I’m just putting it here as an aid to my brain cells. This is for PHP 5.2.x

E_RECOVERABLE_ERROR = 4096
E_USER_NOTICE = 1024
E_USER_WARNING = 512
E_USER_ERROR = 256
E_COMPILE_WARNING = 128
E_COMPILE_ERROR = 64
E_CORE_WARNING = 32
E_CORE_ERROR = 16
E_NOTICE = 8
E_PARSE = 4
E_WARNING = 2
E_ERROR = 1

E_ALL = 6143 = 1011111111111

Therefore E_ALL & ~E_NOTICE = 6143 – 8 = 6135

And to kill warnings as well:

E_ALL & ~E_NOTICE & ~E_WARNING = 6143 – 8- 2 = 6133