Unsupported codec for output stream #0.0

At first I thought this was the result of my missing the libavcodec packages but upon closer inspection and a little forum reading I realized that the error I was seeing (#0.0 not #0.1).  #0.0 refers to VIDEO and not audio as I had previous thought and so installing the audio packages did nothing to resolve my issue.

So, how to solve this problem you ask? Well that’s as simple as adding a nice little switch and extra optino in there that looks a little bit like this:

-acodec copy

Solves the problem immediate.. From what I understand it just means that if the codec doesn’t exist to decode the video ffmpeg can use a copy of one instead.  Easy peasy lemonsqueezy

Oh and for anyone wanting to know how to extract audio from a video file it’s as simple as this:

ffmpeg -i inputfile.avi -acodec copy -ab 256 outputfile.avi

Today I finally decided to tackle it and it turned out to be easier than I thought.  All you need to do is go into Configure display settings where you can set your resolutions and such, I just changed the resolution and click on apply and it removed that additional desktop space and got me back down to the proper desktop size for one monitor.  Huzzah!

After fiddling with it for a bit I went into the WICD settings for that connection and specified static IP’s for the top 2 DNS entries.  Specifically 8.8.8.8 and 8.8.4.4 .  After reconnecting with those settings in place I was able to ping domains again(and consequentially write this post)

So as some of you may or may not know linux allocates memory a little differently than windows and it may be a little disconcerting at first to rely on ‘top’ for your memory usage breakdown as it starts to look like there is a big leak happening somewhere.  This isn’t the case and I’ll take a quick paragraph to explain how it works.

At the end of the day the way that RAM works is that if it isn’t being used it’s being wasted and linux being as amazing as it is has a strict policy about wasting as little as possible so it uses the ram extensively to cache nearly anything it can get it’s hands on.  What ends up happening is that after a program is run the output or information from that program are cached so that every subsequent time it’s run the information can just be pulled out of the cache which is stored in RAM instead, giving it about 1000x increase in read speed for future executions.   Pretty cool eh?  Yea, well unless you don’t know this, setup a new production server in linux, turn it on for the first time and sit there watching top report your free memory going down and down and down and down until it reaches a read out like this:

Mem:   8197228k total,  6219696k used,  1977532k free when just 2 hours ago the same server running on FreeBSD was reporting 90% of it’s ram being free.

The thing to note of course is how big the Cache is.. In my case here it’s about 4.8GB large, meaning there’s all sorts of data stored in there that apache is reloading over and over and over again that is lightning fast.  Already I’m loving this new Debian server

So how do I see my real memory usage?

#free -m

This nifty little command will show you the memory usage with and without caching taken into account resulting in something like this:

total used free shared buffers cached
Mem: 8005 6078 1926 0 487 4675
-/+ buffers/cache: 915 7089
Swap: 11442 4 11438

Telling me that I actually am only using 915MB of ram, not 6GB of it and I’ve got over 7GB of my available 8GB of memory to spare!  At this point you can breath a sigh of relief and give thanks that you are running an OS that is taking full advantage of all this juicy RAM that you have, which would otherwise just be sitting there taking up space

1. Install screen – apt-get install screen
2. run your commands from inside screen.  If you need to search through 1000′s of lines of output you’ll probably need to adjust the output buffer size by adding this line to your ~/.screenrc: defscrollback 5000
3. After you’ve run your command(s) and it/they’ve spit out line upon line of output you need to go into copy mode to start searching through.. You do this with C-a [ .  I just did that to be a dick as I’ve seen it everywhere and no one bothers to explain what the bloody hell C-a is.  It means Ctrl+a , shorthand for those people too lazy to type the trl in Ctrl I guess..  Anyways press Ctrl-a and then [ and then you’ll be in copy mode
4. Search backwards by pressing ? and then typing in your search term.  You can then press ‘n’ to go to the next instance
5. Search forwards by pressing / and again n will go to the next instance

Easy peasy and way more 1337 than using ctrl-f .

PS – another really handy command in screen is Ctrl-a ? which brings up all the commands.  Enjoy and happy searching

NOQUEUE: reject: RCPT from unknown Relay access denied; from

After tonnes and tonnes of trial and error I narrowed it down to /etc/dovecot/dovecot.conf , much thanks to this post : http://www.linuxmail.info/postfix-smtp-auth-dovecot-sasl/

In the end I needed

mechanisms = plain login

near the end of my .conf file so after the edit it looked like this:

auth default {
user = root

passdb sql {
args = /etc/dovecot/dovecot-sql.conf
}

userdb static {
args = uid=5000 gid=5000 home=/home/vmail/%d/%n allow_all_users=yes
}

socket listen {
master {
path = /var/run/dovecot/auth-master
mode = 0600
user = vmail
}

client {
path = /var/spool/postfix/private/auth
mode = 0660
user = postfix
group = postfix
}
}
mechanisms = plain login
}

Yay, hopefully this is the last of the problems with this mail server

1. Location       Result  min. rrt        avg. rrt        max. rrt        IP
2.  Singapore, Singapore:  Okay    189.9   206.1   245.7   65.39.222.41
3.  Amsterdam2, Netherlands:       Checkpoint temporarily not available    –       –       –       -
4.  Florida, U.S.A.:       Okay    76.4    77.0    78.0    65.39.222.41
5.  Amsterdam3, Netherlands:       Okay    0.0     0.0     0.0     ::1
6.  Hong Kong, China:      Okay    0.0     0.0     0.0     ::1
7.  Sydney, Australia:     Okay    183.2   183.6   184.7   65.39.222.41
8.  München, Germany:   Okay    187.3   187.7   188.0   65.39.222.41
9.  Cologne, Germany:      Okay    0.0     0.0     0.0     ::1
10.  New York, U.S.A.:      Okay    0.0     0.0     0.0     ::1
11.  Amsterdam1, Netherlands:       Okay    169.7   170.1   171.2   65.39.222.41
12.  Stockholm, Sweden:     Okay    0.0     0.1     0.1     ::1
13.  Santa Clara, U.S.A.:   Okay    25.4    26.1    26.6    65.39.222.41
14.  Vancouver, Canada:     Okay    0.0     0.0     0.0     ::1
15.  Madrid, Spain: Okay    181.6   184.8   189.4   65.39.222.41
16.  Padova, Italy: Okay    0.0     0.0     0.0     ::1
17.  Austin, U.S.A.:        Okay    0.0     0.0     0.0     ::1
18.  Amsterdam, Netherlands:        Okay    0.0     0.0     0.0     ::1
19.  Paris, France: Okay    0.0     0.0     0.0     ::1
20.  Melbourne, Australia:  Okay    0.0     0.0     0.0     ::1
21.  Shanghai, China:       Okay    162.4   163.4   163.8   65.39.222.41
22.  Copenhagen, Denmark:   Okay    0.0     0.0     0.0     ::1
23.  Lille, France: Checkpoint temporarily not available    –       –       –       -
24.  San Francisco, U.S.A.: Okay    0.0     0.0     0.0     ::1
25.  Zurich, Switzerland:   Okay    180.7   181.1   181.5   65.39.222.41
26.  Mumbai, India: Okay    287.9   288.6   289.4   65.39.222.41
27.  Chicago, U.S.A.:       Okay    0.0     0.0     0.1     ::1
28.  Nagano, Japan: Okay    131.0   131.2   132.0   65.39.222.41
29.  Haifa, Israel: Okay    247.1   247.8   248.3   65.39.222.41
30.  Auckland, New Zealand: Okay    185.1   185.7   187.1   65.39.222.41
31.  Antwerp, Belgium:      Okay    161.4   161.9   162.7   65.39.222.41
32.  Groningen, Netherlands:        Okay    184.5   185.1   185.8   65.39.222.41
33.  Moscow, Russia:        Okay    0.0     0.0     0.0     ::1
34.  Dublin, Ireland:       Okay    160.0   160.6   161.3   65.39.222.41
35.  Oslo, Norway:  Okay    0.0     0.0     0.0     ::1
36.  Kharkov, Ukraine:      Okay    204.0   204.0   204.0   65.39.222.41
37.  Vilnius, Lithuania:    Okay    206.8   209.4   211.0   65.39.222.41
38.  Bucharest, Romania:    Okay    194.4   195.2   197.2   65.39.222.41
39.  Bangkok, Thailand:     Okay    222.7   223.5   225.3   65.39.222.41
40.  Kuala Lumpur, Malaysia:        Okay    188.3   189.7   193.3   65.39.222.41
41.  Jakarta, Indonesia:    Okay    294.1   294.5   294.9   65.39.222.41
42.  Cape Town, South Africa:       Okay    298.8   299.3   299.6   65.39.222.41
43.  Glasgow, United Kingdom:       Okay    150.5   150.9   151.3   65.39.222.41
44.  Lisbon, Portugal:      Okay    188.3   195.4   200.1   65.39.222.41
45.  Chicago, U.S.A.:       Okay    0.0     0.0     0.1     ::1
46.  Dallas, U.S.A.:        Okay    65.2    65.6    66.1    65.39.222.41
47.  Buenos Aires, Argentina:       Okay    204.7   204.9   205.7   65.39.222.41
48.  Istanbul, Turkey:      Okay    205.9   206.5   206.9   65.39.222.41
49.  Gdansk, Poland:        Okay    0.0     0.0     0.0     ::1
50.  Beijing, China:        Okay    748.6   991.9   1,303.0 65.39.222.41
51.  Belgrade, Serbia:      Okay    159.6   177.6   196.7   65.39.222.41
52.  Toronto, Canada:       Okay    61.5    61.9    62.4    65.39.222.41
53.  Novosibirsk, Russia:   Okay    275.4   275.9   276.9   65.39.222.41
54.  Athens, Greece:        Okay    0.0     0.0     0.0     ::1
55.  Frankfurt, Germany:    Okay    0.0     0.0     0.0     ::1
56.  Sofia, Bulgaria:       Okay    200.3   200.8   201.2   65.39.222.41
57.  Budapest, Hungary:     Okay    177.3   177.9   178.9   65.39.222.41
    So naturally I floundered around for an hour or two before putting two and two together and than in all of my zone files for the domains on the server I have this: @      IN      AAAA    ::1
    This is something I no doubt saw in a tutorial and just implemented.. Well it;s the cause of all of the grieve..   Removing fixed it right away but I’m still curious as to what the heck this is.  It is as I guessed the IPV6 record for the domain and obviously what was in there was a mistake.  So I could spend the time and learn about hwo to properly implement IPV6 domains but after checking on where the adoption rate is( around .40% according to http://www.google.com/intl/en/ipv6/statistics/) I don’t feel the pressing need to dedicate more of my life to this, although I certain will in the future.

I got these for over 50% off and even then it was the single biggest waste of money I have ever spent in my entire life and the worst part is that I knew this the moment I put these pieces of garbage on my head.  Stay FAR FAR away from any of these products, Corsair needs to stick to the ram game because they are ruining their name by producing such underperformance, low grade pieces of garbage.

Overall Rating:

Sound Quality: 5/10

Bass Quality: 2/10

Construction: 3/10 (not counting the cord – 8/10)

Mic Quality: 7/10

Looks: 0/10

Value: Any price is too high

The reason I moved to the Ubuntu VPS was that my main server was being shut down, well in reality the entire Datacenter was being shut down, and I had 24 hours notice to move.  Nice eh?  Luckily enough that worked out to 72 hours which was enough time to setup a BIND DNS, also a first for me, and make sure we didn’t have any major downtime.  We were just without email for 3 days while postfix decided to kick my ass.  all of this so that the few hundred sites on that server had a place to live while the new dedicated box I ordered was being shipped to it’s new home in Seattle.  Pretty stoked about that because I’m going from an old Quad CPU Xeon server with 2GB of ram to a dual CPU, quad core(8 cores in total) newer Xeon with 8GB of ram and twice the hard drive(and even more importantly a hard drive with all it’s sectors in tact – goodbye fschk!).  Intel® Xeon® Processor E5420 (12M Cache, 2.50 GHz, 1333 MHz FSB) to be exact!  So I got word today that the new Debian server is setup just the way I wanted it(which took a few tries) and so I’m setting about to migrate off this VPS(which I’ve already killed twice in 1 week) onto a much more stable and dedicated colo box that I can play with as rough as I want

I figured that I would document the entire process as it’s bound to be a hell of a lot less eventful and painful now that we’re moving between Ubuntu and Debian, two distros that are about as similar as you can get – but different enough in their own right.

Why Debian:

Well this is a question worthy of an entire blog post but I’ll give you my opinion to be taken as that and only that.  First off Debian is more stable and that stability comes at the expense of not being on the cutting edge in terms of kernel releases.  People will argue that I could just stick to the Ubuntu LTS but I don’t know if I could trust myself with that holding back  If this wasn’t such a critical production server, responsible for 100′s of websites and dozens of businesses than I might not care as much but knowing that Debian functions on the philosophy of only releasing new updates when they are 110% good and ready and not a bloody minute before really re-assures me that a server of this size, diversity and importance is going to be as stable as possible.

Secondly, I recently switched off Ubuntu on my home machines onto Debian 6.  This is part of my solitary boycott of Ubuntu now ever since 11.10 and the release of Unity was shoved down our throats.  Ubuntu has taken the path of appealing to the lowest common demoninator with this move and that comes at the price of alienating the hard core linux users that put it on the map in the fist place.  So philosophically I refuse to use Ubuntu straight out but much to my surprise, when I switched onto Debian, I noticed gigantic performance increases in almost every area.   I read through a ton of reviews of all linux distros before making my choice and was full ready to go to Fedora, Arch or CentOS instead of going to Debian which is so similar to Ubuntu and at the end of it all of the reviews said the same thing.. Pound for pound Debian is the best linux distro in there, it’s leaner, it’s meaner and as I’ve learned it allows us hardcore users to customize our experience out the wazoo without facing the wrath of Canonical.   Like I was saying Ubuntu is much like the windows of the linux world.. As far as linux goes it’s designed to appeal to as many users as possible and this causes it’s fair share of bloat with the default install.. Debian comes stripped down and if you want extras(hell rsync isn’t even installed by default) you need to put them on.. The end result is a much more streamlined and efficient operating system, which is exactly what I want for my server.

The last reason is compatibility.  I would hands down still be with FreeBSD right now if it wasn’t for compatibility issues.. I prefer the more draconian approach BSD takes to things, it’s simpler, less flashy and just makes sense to me after 10 years of working with it.  I like going into my ports tree and doing a make install instead of apt-get install.  I like having everything in /usr/local/etc/apache22 instead of /etc/apache2.  Or I should say I’m used to it because using Ubuntu for the past week has made me udnerstand why they do it the way they do and the benefits to that(but still honestly does every single apache module need it’s own .conf file?  come on, just make a section in the httpd.conf for modules).  Anyways, there are some really really cool server applications that I just can’t run on BSD and trust you me I’ve tried.  The main one is Big Blue Button.  Probably the single coolest server application I’ve ever seen that will enable me to take my collaborative teams to a whole new level of connectivity.  Unfortunately it’s made for Ubuntu and fortunately enough for me Debian is close enough for it to work pretty flawlessly.  There is a BSD port but I cannot even begin to describe the nightmare of getting that to work properly.  Oh wait, I just remembered that I already did describe what it took to get it to work here: http://groups.google.com/group/bigbluebutton-users/browse_thread/thread/27f89c10aae707c2/0a5ad6064ec95aa1

So all in all my need for comparability, stability and performance coupled with my need to be a little less mainstream than Ubuntu landed me with a fresh new Debian install.

Installation:

So first things first, let’s get the damn OS installed.. Or more specifically lets get a damn tech at the DC to get the damn OS installed  It’s a total barebones installation but I did specify that everything except for  /tmp should be ext4.  For some reason the techs went with ext3 on the first run around which I spanked them for and got them to reinstall it all with ext4.  Now I was running XFS on my BSD box and from what I understand overall that’s a better FS however I am not using the filesystem for anything that would need XFS at all, as amazing as it is.  That and in the last 2 years I chewed through 4 hard drives, not saying it was all XFS but I wanted something new that I haven’t destroyed.  I run ext4 at home and have been for 1-2 years now and have had no issues.  I also researched the hell out of it and for the most part it comes out well on top of ext3 in performance so I went with that.  Now I said everything but /tmp before and for that I went with tmpfs as my filesystem..  Remember, for the past 6 years I’ve been running an ever expanding and demanding empire of websites on an old server with inadequate memory and so i’ve developed this obsession with squeezing every ounce of performance out of the server(my apache res memory size on my tuned box is 29MB versus the 95MB that it is on  one of the shared servers I have some websites).  Somewhere in this obsession I stumbled across an article about running  /tmp on a tmpfs instead of ext4 and the big performance gains you see from that(assuming you have enough ram) and so here I am, going to test it out.  In the end my partition table ended up like this(It’s a 500GB drive):

Filesystem Type 1K-blocks Used Available Use% Mounted on
/dev/sda4 ext4 392287828 341664 372019076 1% /
tmpfs tmpfs 4098612 0 4098612 0% /lib/init/rw
udev tmpfs 4093808 140 4093668 1% /dev
tmpfs tmpfs 4098612 0 4098612 0% /dev/shm
/dev/sda2 ext4 28836860 475212 26896816 2% /usr
/dev/sda3 ext4 48061320 318892 45301008 1% /var
tmpfs tmpfs 523356 0 523356 0% /tmp

It has a 12GB Swap, overkill yes I know but i’ve got room to spare.  Anyways, I won’t get into the explanation for why I went this way, it was through a lot of research and I’m sure if yuo want to verify that this is a good or bad setup you can head over to google and do some digging yourself.

Post-Install

So as I mentioned, a stock Debian install comes pretty barebones.  Not even rsync is installed.. So there’s some basic stuff we need to setup to enable us to even install any further packages and to transfer the other server over.   If your techs are a little bit on the lazy side, as it seems mine were, then you’ll notice that when you try your first apt-get install it will find the package and just sit at 0%.  Good times.. A quick trip into /etc/apt/sources.list shows that they left source as the CD-ROM disc, which now wasn’t in the drive.  So you’ll need to uncomment out the internet sources and as I noted in my previous post you are going to need to  put another repo in the sources to grab some pretty important packages.  In the end my sources.list looked like this:

# deb cdrom:[Debian GNU/Linux 6.0.3 _Squeeze_ - Official amd64 DVD Binary-1 20111008-14:36]/ squeeze contrib main

deb http://security.debian.org/ squeeze/updates main contrib
deb-src http://security.debian.org/ squeeze/updates main contrib
deb http://ftp.debian.org/debian/ squeeze-updates main contrib
deb-src http://ftp.debian.org/debian/ squeeze-updates main contrib
deb http://backports.debian.org/debian-backports squeeze-backports main
deb http://http.us.debian.org/debian/ squeeze contrib non-free main

From here I ran apt-get update && apt-get upgrade and ugpraded my kernel to the latest version.  A quick reboot with my fingers crossed and now uname -a shows this:

Linux ded 2.6.32-5-amd64 #1 SMP Thu Nov 3 03:41:26 UTC 2011 x86_64 GNU/Linux

Which again is a testament to how anal the Debian people are about their kernel release as the latest kernel out is .39 or higher I believe.  Now the server is ready to be used.

The first thing I install is rsync as I want to start moving everything over from the vps.  The first thing I’m moving over are all of the user accounts.  Because Debian and Ubuntu use the same hash algorithm it is possible to just copy passwd group and shadow over and it will work for the most part but problems will crop up down the road because of some small differences with group names across the two distros.  So your best bet is to go into your passwd, group and shadow files and find all of the missing user accounts and groups on your production server that haven’t yet been created on the new server.  It’s as simple as copying and pasting them onto the end of the file in question. *NOTE: You should avoid copying over any of the package specific usernames that get created upon package installation.  You’ll run into problems here and there and it’s best just to let the installer do it’s own thing*  Do all of this before hand will make it possible to just move the entire /home directory tree over and maintain all of the existing file ownerships.  Which is exactly what I’m going to get going in the background while I start installing all of the needed packages.

One of my BSD habits that I take with me is simple directory structure.. I absolutely can’t stand seeing /var/www/home/user1/site.com/public-html/ .  Who the hell needs all of that?  I’ve been running servers for 10 years and I have never in my life seen a need to distinguish public-html and private-html, what the hell is private-html anyways?  Are so many people in need of this that it really needs to be the default directory structure?  Hell no, anything in ./site.com/ is what’s going to show up on www.site.com so why not mirror that on the server if possible?  So everything on my servers just goes into /home/ which is symlinked to /usr/home to appease some programs.

So the first thing I’m doing is moving everything over from the old server’s home directory: #rsync -avpl -e “ssh” root@oldserver.com:/home/ /home/   and off she goes!  Transfering the 120 GB over should buy me enough time to setup some of the modules.

After that I’m going to go through the installed packages on the Ubuntu server and start installing them all manually according to what I actually need.  Remember that Ubuntu will install a bit of bloat that you don’t need by default, so make sure you know what everything instead of just installing it all over as you’ll no doubt be loosing some of the lean meanness of Debian that way.

Installing needed packages:

So we need to see what’s installed on the old server and install it on the new one.. There are going to be some obvious ones here like apache2, php5.3, mysql, etc etc but it’s good to make sure you’ve got a full list and don’t miss anything important.  For this we need to use the following command: dpkg –get-selections on on both servers and then compare the list, going through the ubuntu one carefully and making sure we are only moving over the necessary packages and not bringing all of it’s bloat with it.

How much bloat you ask?  Well out of a freak of coincidence the Ubuntu server has EXACTLY double the installed packages as the Debian server.  531 on the Ubuntu box and 265 on the Debian box.  Now given the Ubuntu server is a life and functioning web server and with that come a few installed packages but I can assure you that I have not installed 265 additional packages since I took ownership of that VPS.  So what I do is  I take the output from both servers, copy and paste them into two separate .txt files on my local machine here and run diff to see where the differences lie.  Time to get busy!

 *Word from the wise* :  A lesson I learned from an old sysadmin is that the first thing you should be installing when setting up a new server remotely, via ssh without KVM, is the screen package.  Take it from my experience, there will be a time when your 25 minuets into a big package installation and your connection to the server will die, or something horrible will happen forcing you to clean up and start over.  Save yourself the headache and do everything from within a screen that will ensure your procs will stay running even if you don’t.

Mysql Transfer :

So if you’re like me then you have a good number of databases, users and the like to move over.  Again because the two distros are so similar you can literally just use rsync to pull the contents of /var/lib/mysql off your old server onto the new one.. I just moved /var/lib/mysql to /var/lib/mysql_bak on the new server incase anything goes wrong and I need to reference the old files and then just pulled the mysql from the old server onto the new one.  The only issue here was that I was seeing this error on the initial startup:  ERROR 1045 (28000): Access denied for user ‘debian-sys-maint’@'localhost’ (using password: YES) followed by my inability to stop the server, etc, etc.    Because of how similar they are the /etc/mysql directory was one of the only ones I didn’t overwrite frmo the old server.  I figured if anything is going to have distro specific shit in there it’s going to be mysql, so best to leave the new installs files as they are.. Unfortunately that wasn’t the case and in order to get through this error I just needed to go into the /etc/mysql/debian.cnf file on the old server and copy the ‘password =’ value over.  Fixed everything from there on in.

Bind9:

As with most everything else you can pretty much copy the entire contents of /etc/bind and be fine with all of the configurations moving over.. The only area where you are going to need to do a little surgery is in regards to the IP addresses.  When moving to a new server in a new location chances are that you’re going to be assigned a whole new lot of IP addresses and you’ll need to migrate everything on over to the new ranges.  Now I suppose you could do some clever bash scripting for this with two arrays of IP addresses if you have a few dozen IP’s on the server but if you have 15 or less your probably better of just using some find and sed magic.

As with anytime you are making a ton of changes automatically let’s back up our /etc/bind/zones/ directory and then use the following command as many times as need be to replace all of the old IP’s with all of the new ones.  Keep in mind that you should be inside of /etc/bind/ before running this or it might take a while

find . -exec sed -i ‘s/old.IP.address.here/new.IP.address.here/g’ {} \;

From here it’s probably a good idea to run a cat * | more and just go through all of the files to make sure that everything is looking peachy and that you didn’t miss anything

Apache and Nginx:

Now depending on how you have your server setup you might have to do the same thing that yuo just did with bind except with apache as well.  Running find and replacing all of your old IP’s in apache conf files with new ones.  If you are like me however, apache is just acting as a proxy for nginx and in which case you need to do the same as with bind but with nginx.

Postfix / Dovecot:

I’m knocking on wood and crossing my fingers but this was incredibly painless to move over(now that it’s actually setup).  Just make sure that you carry all your certs over if you’ve setup SSL and that you’ve recreated  /var/spool/postfix/var/run/saslauthd so that everyone’s happy.  I spent a solid week setting this damn email server up the first time and I’m tickled pink to see it seamless transfer over and work right off the bat.  Again you should double check all of the conf files to make extra sure there’s nothing that needs altering and then telnet into 25, 587, 110 or 995 to test everything out

Testing:

So everything is pretty much moved over now but before you go ahead and edit your nameserver info at your registrar to point at the new server you better test the hell out of everything.  This is pretty easily accomplished by editing your /etc/hosts file(or localhost in windows) and putting in a list of domains you want to test and manually specifying what IP your computer should look for them on, essentially bypassing the nameservers.

something like 127.0.0.1 example.com would mean that instead of going to the actual IP for example.com it would look at the 127 IP instead.  This will allow you to test all of the domains you want to make sure are functioning properly.. It will allow you to check that mysql is doing what it needs to do, that php5 is happy and of course apache/nginx are working properly.  I was pleasantly surprised(shocked is a better word) that it all showed up immediately and perfectly as expected.

If you have a mail server setup you should also put your mail server address(ie: mail.example.com) in your hosts file to test that out with whatever email client you are using

I cannot express the true depth of my shock when everything came up working almost immediately.. Remember I initially moved 100+ domains and databases off of a BSD server that was having all the nameserver and email stuff managed externally onto an Ubuntu server where I was taking care of all of the nameserver and email stuff internally.  It was hell to say the least, mostly because I had to learn the nuances of the new OS and I had to re-setup everything by hand(or well with the help of some bash scripts I wrote) in terms of the domains, the email addresses, the dns entries, apache, nginx, etc etc.  This time it was as simple as copying everything over, double checking a few things and what took me 7-8 days of strife and stress now took me about 3-4 hours of work with everything basically working exactly as it should have and the troubles I did encounter were straight forward and easily solvable.  I could get used to this

So there you have it, I didn’t bother to document a lot of the setup of the individual components as there are all sorts of great guides out there written by people far more intelligent than I about that

Preconfiguring packages …
Can’t exec “/tmp/ssl-cert.config.16841″: Permission denied at /usr/share/perl/5.10/IPC/Open3.pm line 168.
open2: exec of /tmp/ssl-cert.config.16841 configure failed at /usr/share/perl5/Debconf/ConfModule.pm line 59
ssl-cert failed to preconfigure, with exit status 255
dpkg: unrecoverable fatal error, aborting:
syntax error: unknown group ‘Debian-exim’ in statoverride file
E: Sub-process /usr/bin/dpkg returned an error code (2)

So to get around that the boys over at Debian-Administration we’re kind enough to post the following solution:

Add the following to the file /etc/apt/apt.conf:

DPkg::Pre-Invoke{"mount -o remount,exec /tmp";};
DPkg::Post-Invoke {"mount -o remount /tmp";};

This contains two lines, one running before any packing installation and one afterwards. They merely execute the commands required to add and remove the execute permissions on the /tmp