Monthly Archives: November 2013

*updated*

The studio laptop has thrown me two non-fatal BSODs in the last month.

The first thing I did after recovering from the first, was to check drivers. The system identified a USB driver issue, which I had a feeling I have known about for some time.

But I can’t resolve it, right now, because the box of drivers is upstairs, fully packed away, in one of the large cardboard boxes in the spare bedroom.

After the second BSOD (happened about three weeks after the first) I looked harder at the studio laptop’s hard disk.

Hmm.

Space was a little tight, with over 75% of the 149Gb hard disk full.

And I know that having a hard disk close to its maximum can lead to non-fatal BSOD error messages.

I don’t have MS-Office on the studio laptop, but I do have quite a bit of editing software (the very large Sony Vegas Pro, and the almost equally chunky Cubase, as well as a handful of smaller audio and video editing tools and file conversion utilities).

I can’t remove the editing tools/conversion utilities, obviously, because this is why the studio laptop exists.

But I have deleted a metric fuckton of completed video and audio edits, because they were already stored in audio and video project libraries on the NAS.

Then I looked at what else was left behind.

Music.

Slightly under 60Gb of music.

Slightly under 60Gb of music which is already backed up on the NAS.

So why is it on the hard disk of the studio laptop?

Because iTunes needs a local drive to work with.

And because of that simple rule, all of my music files have been stored in c:\documents and settings\[username]\my documents\my music\itunes\itunes music

Why is the music stored in that tediously long address?

Because the studio laptop precedes the arrival of the NAS by several years. And because although I have backed up my music library to the NAS every week, I have never migrated the iTunes functionality off the c:\

Because I have never got around to mapping a drive to the NAS.

Well all that is changing.

I have mapped z:\ to the NAS. I have given the mapping the appropriate permissions to read/write to the appropriate NAS directory.

And as I type this, iTunes is copying 7,081 songs from c:\etc to z:\my music\itunes

Erm.

Hopefully.

I say ‘hopefully’ because I won’t know if this has worked until I plug my iPod in, and it (hopefully) syncs with the library in the new location.

And I won’t be able to plug my iPod in to sync it, because moving 7,081 songs from c:\etc over to z:\etc is taking a really really really long time. Even though I’m directly connected to the router via Ethernet cable, and the router is directly connected to the NAS via Ethernet cable.

Oh well.

Fingers crossed that it all turns out alright, eh?

Anyway, when I’ve been able to validate that this musical migration has been successful, I will return to the hard disk of the studio laptop and delete the 60Gb of music.

And then I will start running serious diagnostics on the cause of the non-fatal BSOD.

See?

There is method to my madness.

Sortov.

___________________________________

Well, it worked.

And then I deleted the (now) duplicate music files on the c:\

And the studio laptop is down to 39.9Gb occupied and 109Gb free.

And it’s a lot quicker than it was.

And the iTunes migration plays nicely from the z:\ drive that I mapped to the NAS.

So yay!

Or, to put it another way:

Migrating a WordPress-based TLD website and an integrated sub-directory-based phpBB forum, when each entity is driven by their own MySQL databases (and keeping the content intact, obv)

I thought I was going to have a bucketful of problems with this experiment, but amazingly it turned out to be problem free (if a bit fiddly on the phpBB side of things).

• Backup the website MySQL database
• Backup the forum MySQL database
• In one operation, backup the website content (including the forum content)
• Transfer the backups to a local disk or drive
• Create the virtual host and DNS Server/zone file creation for the TLD website (as per here)
• Copy the website and forum content in to the virtual host folder (nb: this will create the forum subdirectory)
• Create the TLD MySQL database (copy the database name and username from the wp-config.php file in your WordPress root, and give the new database the same password as the old one) nb, you may need to edit the wp-config.php file to reflect the new address of the MySQL database, typically it will be ‘localhost’ for the new database, but the legacy address in the wp-config.php file might be different
• Create the Forum MySQL database (copy the database name and username from the config.php file in the phpBB root, and give the new database the same password as the old one) nb, see above re addressing the MySQL database correctly
• Import in to the new TLD the MySQL database from your backed-up TLD database
• Import in to the new Forum the MySQL database from your backed-up forum database
• Change the routing (may be a zone file edit) in your domain registrar’s control panel, to point the TLD at its new host
• Wait
• After a while, when the new host is active, your TLD website should be exactly as it was, though the forum won’t work yet, but don’t worry, we’re nearly there…
• Go in to your WordPress control panel and access the wp-united product that you have used to integrate the website with the forum
• Ignore any scary error messages that might be shouting at you
• Click on ‘change location’ under the phpBB location heading, and navigate to your forum root and click on the config.php file
• That should make the scary error messages go away. It should also (though this might take five minutes) sync the design and user details in your website and your forum (assuming you’ve set wp-united to do these things)

Your website content and design (and any bells and whistles you may have built in to it), and your forum content should be intact, and you should have successfully migrated your website and its integrated/interfaced forum to a new host with zero downtime, and no losses.

Congratulations.

For email transfers, see this post (but you should give it a few hours, before you do, to allow the host change to propagate, before you config your new email users on your new server).

This is completely mentile, but further to my last post (not *the* last post, that’s something else that I used to play on the cornet, trumpet, bugle when I were a lad and no, not on all of those at the same time), the amount of attempted MailServer hacks remains conspicuously low.

There have been, in the last 48 hours, just three attempts to breach the MailServer – and those three attempts came from one (now banned-for-life) IP address.

So, something related to that domain name – or something related to the (now deleted address) on that domain name?

Here’s a peculiar thing – well, three peculiar things:

1. I wrote here about needing to learn additional mail admin knowledge in Postfix, specifically around learning how to delete an email account
2. I wrote here about one email account I was hosting, that received a metric fuckton of spam
3. I wrote here about a significant number of unsuccessful probes the mailserver was receiving

The first two items were about one email account attached to one hosted domain.

Well, after several days of internet fishing, I couldn’t find any help on how to delete an email account in Postfix.

So what I did was migrate the hosted domain (and therefore the associated email account) back to GoDaddy.

Then I deleted that email account there – because GoDaddy’s email control panel is simple, and easy to manage.

Within 48 hours, back on the NAS, all spam had dried up.

And, coincidentally (?) all probes to the MailServer had dried up too.

I would expect all spam to dry up, because the mx records for that domain now point to a server in Arizona, not my server here in Warwickshire. Deleting that email account is neither here nor there; that website is now under the administrative control of GoDaddy.

But all unwelcome probes/hack attempts drying up within the same timescale?

Well that’s just weird.

There are two environments that need attention, when hosting a domain on a Synology Diskstation:

1. Virtual Host (which organises the location of the files that your website is built out of), and
2. DNS Server (which controls the Zone File that points web browsers at your website)

First of all, to configure your Virtual Host for your new website (which we will call example.co.uk):

Web Services -> Web Applications -> Virtual Host:

• subfolder = example (without TLD suffix)
• hostname = example.co.uk (with full TLD suffix)
• OK

Now to configure your DNS Server and the Zone File:

Downloaded Packages -> DNS Server -> Zones:

• Create Master Zone
  • Domain Type: Forward Zone
  • Domain Name: example.co.uk
  • Master DNS Server: static IP address
  • Serial format: Integer
  • OK
• Edit Resource Record
  • Create:
  • MX Type
  • Name: mx
  • TTL: default
  • Priority: 10
  • Host/domain: example.co.uk
• Create:
  • MX Type
  • Name: (leave blank this time)
  • TTL: default
  • Priority: 20
  • Host/domain: example.co.uk
• Create:
  • CNAME
  • Name: (leave blank)
  • TTL: default
  • Canonical Name:
  • ns.example.co.uk
• Create:
  • A Type
  • Name: (leave blank)
  • TTL: default
  • IP address: static IP address
• Finish

And you’re done.

Email config is a separate thing. You need to follow these instructions for that.

so it seems that to run ghost i have to download, install and configure node.js?

oh

so much for the simple life

i’m getting the tar.gz for node.js, and downloading the ghost package

but it looks like there’s a lot of reading to be done before i get ghost up and running

this seems like a lot of effort just to look at a new product

but i’ll stick with it

slowly

as time allows

The NAS has been getting a significant amount of hack attempts, since I enabled the MailServer functionality.

About 10-15 times in a 24-hour period, people (or, to be more accurate, things, because these probes are probably automated) attempts to log on to the root of MailServer as the primary user.

I guess that the bots that trawl the internet looking for open ports probed for, and found, the open port 25 (MailServer port) against the static IP address that the NAS uses.

My first line of defence was to implement a ‘three strikes and you’re out’ security policy. This will ban, for life, the IP address of anyone who unsuccessfully attempts to log on to the NAS three times.

My second line of defence was to set each NAS account and each email account with a new, digitally-encoded password, that meets GCHQ encryption standards.

I did check out the first couple of dozen IP addresses, but the only thing I learned was that invariably they were based in China.

It amused me that the Chinese Government (hacking community? – what’s the difference between the two?) would be so keen to get their hands on my priceless collection of unsigned music.

Or the many thousands of amusing Garfield strips that I keep, for some reason.

Or the entire second series of Outnumbered that I’ve never quite got around to deleting.

Or my porn.

Ahem.

So I have implemented two lines of defence: three strikes and you’re out for life, and all passwords set to a very high standard.

Is there anything else I can add?

Bear in mind we are only talking about probes to the MailServer – an application on the NAS – not probes to the NAS itself.

The email account that is the object of all the email admin I’m looking at is getting hammered with spam.

It’s an old email account, the email address has been around the internet for a decade or so and it has been very public, so it’s not a big surprise that it’s getting spammed.

Over 99% of the spam comes from spoof email addresses (from hacked MailServers, I’m guessing) that begin ‘canada.medic@’.

I set a management rule in MailServer to discard any incoming traffic from all email addresses originating from ‘canada.medic’ attached to any domain name.

That did the trick.

The incoming traffic showed up on MailServer as incoming mail, but nothing was delivered to the incoming mailbox/email account.

Yay!

It looks like that, in order to delete/remove existing email accounts in the NAS I need to get down and dirty with some command line action.

I enabled Telnet and opened the appropriate port in the NAS firewall, and had a poke about /var/etc/packages/MailServer/ and everything looks like I’d expect it to.

But the more information I read, the more questions remain unanswered.

Do I need to remove the email account from MailServer?

Or do I need to remove the email account from the associated Dovecot package?

Or do I need to remove the email account from both?

Hmm.

I need to read even more, obv.