NLU came to life just before October of 2005 and it’s been a fun ride. I’ve decided to depart from b5 both as New Linux User blogger and as Tech Channel Editor. I have some personal projects that I’d like to dedicate more time to and since nobody seems to be making more hours, I need to pare down what I do in the existing ones. b5 has been the single greatest blogging experience of my career so far. Working with Jeremy, Darren, Duncan, and Shai has been inspiring and the bloggers and other channel editors that form the body of b5 has been nothing short of amazing. I’ll miss the community and obviously bright future b5 has ahead of it, but sometimes you need to swim or sink on your own.

I’d be remiss if I didn’t thank all you for reading the blog. This blog has what I consider to be a tremendous amount of traffic and it’s very gratifying to see how many people come here for information, advice, and to correct me. This blog is its own little community and I know that whoever steps in to take over my role will strive to keep that community going.

Thank you all.

Jon

Post from: New Linux User

As regular readers can probably surmise, I’ve been doing an awful lot of host-moving these days. In the past week I’ve moved all 10 of my domains twice. I’ve moved domains before, but never on such a grand scale and never more than once in a week. It sucked, but I learned a few things such as using the /etc/hosts file.

When you move a site, the IP address of that site will change. To let the world know that your IP address has changed, you need to update your DSN records however it can take days for that information to propagate throughout the world. It’s very hard to thoroughly test a newly-moved website until DNS resolves and waiting for that to happen just to find out that your newly live site has errors in it isn’t a lot of fun. A much better way is to move the site, but leave your DNS settings alone so the rest of the world continues to see your old site, and make a change to your /etc/hosts file so only you can see the new site.

When you attempt to reach an Internet address – regardless of whether your browsing, ssh’ing, emailing, or whatever – your system consults its /etc/hosts file to see if it has an IP address entry for the domain you’re looking for. If it doesn’t (as is the case most of the time) it then queries the DNS system for an IP. To ensure that you will see the new site, edit your /etc/hosts file and, underneath the existing 127.0.0.1 lines, put in your new IP address and your domain on the same line. For example, when I moved Linux World Net, I added these lines to my /etc/hosts file:

69.65.105.227 linuxworldnet.com
69.65.105.227 www.linuxworldnet.com
69.65.105.227 fifo.linuxworldnet.com
69.65.105.227 security.linuxworldnet.com
69.65.105.227 gaming.linuxworldnet.com
69.65.105.227 linuxbiz.linuxworldnet.com
69.65.105.227 mythdispeller.linuxworldnet.com
69.65.105.227 gaming.linuxworldnet.com
69.65.105.227 learning.linuxworldnet.com
69.65.105.227 minimum.linuxworldnet.com
69.65.105.227 news.linuxworldnet.com
69.65.105.227 naked.linuxworldnet.com

Now, whenever I attempt to go to any of theses addresses, I get the new site. Nobody else in the world does, however, because I haven’t updated my DNS records yet. Once I’ve determined that the site is working properly, then I can change the DNS settings at Zone Edit (or your registrar) and the rest of the world can come on in.

Note: I suspect, but have not tested, that something like *.linuxworldnet.com might have worked as well.

Reader Eric left a tip that will speed up DNS propagation once you get to that step. Thanks, Eric:

About 24 hours before you move a domain, update your TTL settings for the domain that you’re going to move to 600 (seconds). The default in WHM is 14400.

This will tell DNS servers to check the server every 600 seconds (5 minutes) to update the DNS. So, once you switch you’ve moved the site and updated your nameservers, all traffic should be redirected to the new site in about 5 minutes.

Post from: New Linux User

An unmanaged plan gives you a box with a Linux distro on it (unless you get a Windows unmanaged VPS which are few and far between). A managed plan, in most cases, gives you a box with a Linux distro and a management panel like cPanel and all the ‘normal’ type stuff you’ll be expected to need like PHP and MySQL. It’s the cPanel Web Hosting Manager (WHM) that makes all the difference when you’re transferring servers. Moving from a WHM server to another WHM server is so ridiculously easy that it almost defies description.

Moving from the unmanaged required me to transfer each of my 10 domains manually. I had to tar up each domain, dump the databases and then recreate the domains, restore the tarballs, and restore the databases onto the new server. This took an entire day and there were still lots of permission errors at the end of that day. Moving from a WHM server to another WHM server literally requires a couple of clicks per domain. On the new WHM server, you can import an account from the old WHM server with ease.

The steps are so ridiculously easy that I won’t bother to list them here, but suffice it to say that I *highly* recommend getting a WHM enabled VPS from the get go. You’ll thank yourself later when you have to move hosts. And we all have to move hosts from time to time.

Post from: New Linux User

If you’re currently subscribed, you’ll remain free for a year.

Full details here.

Post from: New Linux User

What I very quickly learned is that it’s very easy to lose file permissions and ownerships when you do what I did. When untarring the file onto the new server, it’s important to do it as the user who owns the account, and not the root user. Untarring the tarball as the root user will make the new files owned by root which can cause all sorts of problems with whatever CMS or blogware you’re running. It’s not that hard to recursively change ownership:

chmod -R newuser.newuser *

but it can produce some spectactularly ugly errors at the onset.

I’ve also found that in some cases, the newly untarred files would have all of their ‘w’rite permissions stipped from them. Again, not a big deal to restore it, but can also be the cause of some ugly errors.

I’m 100% sure that the way I did the server transfer could have been done better. There must be ways to preserve the file permissions when doing this. I’m not sure about the ownership, however, as it’s entirely possible to untar a bunch of files that are owned by a user on the old server that doesn’t exist on the new server.

Anyhow – not a lot of information in this post, but I wanted to share that if you’re doing something like this and getting all sorts of ugly errors, you may want to take a look at the new files’ permissions and ownership.

Post from: New Linux User

In any case, it’s been about 4 months since they’ve sent me anything and in the last month alone I’ve been sent three books. They all looks great and they all fit a different niche.

Here’s the run down of what I’ve been looking at this month (note, these are NOT affiliate links. Click away):

The Linux Starter Kit

Link

This is a ’software box’ with a full SUSE 10.1 DVD in it and a 150 page ‘quick start’ manual to get you up and running. It’s geared towards the new SUSE user, and perhaps the new Linux user, but not the new computer user. The instructions are good, but they’re probably too brief for a novice computer user. Great for those of us who are relatively comfortable with computers and want to dive right in.

The Linux Phrase Book

Link

Great for people who work with Linux. It’s not a narrative book at all, it’s a reference pocket book that has a quick index for pretty much every command you can think of. Great stuff.

The Official Ubuntu Book

This guy isn’t on the shelves yet. In fact, I just got it a few days ago and haven’t really had a good look at it yet. It’s direct from the Ubuntu clan, however, so it’s bound to be bang on the money. I’ll post more about it when I get further into it.

Post from: New Linux User

When I attempted to delete a *.bak file in my awstats directory I typed this:

rm * .bak

See the space? Yes. It took the entire directory.

Thankfully, I had almost the exact same setup on another server so I was able to grab my awstats conf files from there and tweak ‘em, but holy…that could have just as easily been any other directory on the machine. And yes, I was root.

Weenies Unite!

Post from: New Linux User

It’s over on The Linux Learning Station.

Post from: New Linux User

Sadly, many laptops’ touchpads show up as USB mice (as was the case with my old Inspiron 1000). Since the computer thinks it is a normal mouse, I don’t believe there is any way to pass parameters to it to shut off the tapping.

This procudure, however, has worked on both my current Dell inspiron 9400 and Kelly’s Acer Aspire 3000.

Open a terminal window and open the /etc/X11/xorg.conf file for editing. In Kubuntu:

Press Alt+F2 and type in Konsole
Type sudo cp /etc/X11/xorg.conf /etc/X11/xorg.conf.original
Type sudo nano /etc/X11/xorg.conf

In Ubuntu:

Press Alt+F2 and type in gnome-terminal
Type sudo cp /etc/X11/xorg.conf /etc/X11/xorg.conf.original
Type sudo gedit /etc/X11/xorg.conf

Scroll down to the Input Device section and add the following lines:

Option “TapButton0″ “0″
Option “TapButton1″ “0″
Option “TapButton2″ “0″

Different areas of the touchpad mimic mouse buttons. The tap mimicing the left-click is one such beastie. What we’re doing here is shutting them all off. I’m not entirely sure how many TapButtons there are to shut off, but these three ( 0 – 2) seem to turn everything off. If you have a really fancy touchpad, you may require more. I’m sure there’s a much better technical explanation for this, but that’s how I see it

Enjoy!

Post from: New Linux User

I was reading the booting section of my fancy-dancy LPI certification book and it speaks about kernel parameters. It mentions that you can feed the kernel parameters at boot time (which will be the subject of an upcoming entry) and also states that you can feed kernel modules parameters as well. It says that kernel module parameters can be specified in either the /etc/modules.conf or the /etc/conf.modules file.

I’m running Kubuntu 6.06LTS and I have neither of these files. I have an /etc/modprobe.d/ directory that contains a bunch of files that kind of look like what I want, but I’m not familiar enough with this topic to figure it out. I did some preliminary Googling and came up with this post that states running a sudo update-modules will create the modules.conf file, but it doesn’t work.

Now, it’s quite obvious that I don’t need this file as my system runs fine, but in order to understand how to pass module parameters, I need to understand how the system works in Ubuntu. Anyone want to take a shot at explaining it for me?

Post from: New Linux User