Linux

When I setup a new Centos or Amazon Linux server, one of the first tasks I want to accomplish is installing postfix. There used to be a package named system-switch-mail that made this easy to do from the shell. If you've tried to yum install this package recently you might have been surprised to find that it has disappeared. Instead there is a tool that lets you do essentailly the same thing which is part of the chkconfig package.


For this to work you need to have the chkconfig package installed:



If you don't see it, then yum install chkconfig!

With chkconfig installed you have access to the alternatives system. Of course to be able to switch your mta you first have to install your sendmail alternative. In my case it's typically:




Now you can switch your system to use postfix as the default MTA!



Choose Postfix and hit enter and you're done. Don't forget to remove sendmail, as you no longer need it.

I like Amazon Linux. It is basically Centos with a bit of Fedora mixed in. Thus it comes with yum, and even better yet, with amazon supported repositories preconfigured. Because amazon provides it, they support it, and answer questions about it, and fix problems with it and keep it up to date and patched so that it runs well as a paravirtualized guest inside Amazon's Xen based infrastructure. They insure that it's fairly secure, has a fairly minimal set of installed packages, and comes with the ec2 api tools already installed, which can be a daunting task to setup for people new to aws and ec2.

However one thing they don't do by default is configure their AMI's to make the ephemeral storage you are entitled to available by default. When you boot up an instance, you find yourself with a 10 GB EBS volume, and that can become pretty filled once you've installed a few packages.

What is Ephemeral storage?
Ephemeral storage is the "instance storage" that's advertised for each instance type and can range from 150 GB on up to over a terabyte depending on the instance type you're running. This storage is called "Ephemeral" by Amazon because it comes from the local hard drives in the server your instance is running on, but does not persist or survive an instance stop. If you put anything important on it, you'll need to back that data up using traditional means, and won't have the ability to snapshot it like you can with EBS volumes. Although ephemeral drives can provide excellent IO performance and a substantial storage at no extra cost, they are subject to the types of failures that you'd expect with single server disks.

In spite of these concerns, they certainly are a great place for things like temporary files, or swap files, or logs that you're going to rotate or purge anyways.

So how can you use Amazon Linux and still get access to the ephemeral disks?

You need to utilize the Amazon API and use the "-b" parameter to map one or more block devices to your ephemeral storage. Although the web interface "Launch Instance" wizard includes a tab for storage options, the instance storage tab is not accessible. I typically use the command line api to start aws instances.

For example, this command will launch a large instance based on an Amazon Linux AMI, only, while at the same time adding back mappings to the ephemeral storage that is part of the Large instance profile.



The important parameters to note, are the two "-b" parameters, which specify that ec2 should establish block device mappings to our two ephemeral drives.

When your instance starts, you'll find that you now have a formated ext3 volume ready for use:

/dev/xvdb 414G 199M 393G 1% /media/ephemeral0

You might have noticed that we specified a mapping for 2 different block devices. You'll find that /dev/sdc is configured, but you'll have to format it and mount it yourself.

If this is the first time you've seen the command line api used, amazon linux is a great way to get started. Just start up a micro instance using the recommended Amazon Linux AMI, add your certs, and you're ready to go.

In summary, Amazon Linux is an excellent choice for your EBS backed instances -- just remember that unless you override the default, you'll be missing out on the Instance storage you're paying for!

I have been fighting a problem with mounting volumes from an NFS Server in AWS for a few days. With more pressing issues at hand, I had to try and google for solutions for an hour or so before bed, and nothing I was doing was having any effect. Curiously, an Ubuntu based machine that was mounting the drive using NFS3 was not having the same problem. Only the Amazon Linux servers that were using NFS4 were having the issue, and were showing all files and directories as being owned by nobody:nobody.



I had previously insured that the user UID and group GID for the user that would be writing files (in my case "apache" was the same (with the same UID and GID) on the NFS server and the servers mounting the nfs volume.

As it turned out the problem was with the configuration (or lack thereof) of the rpcidmapd service. NFS4 relies on this service to map users between machines. The "idmapd" requires that the domain of both the client and server should match for the UID/GID mapping to work, and in my case it wasn't. Probably many people with proper DNS configuration don't hit this problem, but we did not have a proper DNS setup, as these machines are part of a growing cluster. Compounding the problem I had set the configuration files to have meaningless host names rather than a domain.

You can tweak this setup by editing the: /etc/idmapd.conf file, and find the "Domain" variable:



Set these to be the same for the server and all the clients.

The last problem was that I had to restart the idmapd process, which has an /etc/init.d control script named /etc/rpcidmapd



Restart the process on both the nfs server and any nfs clients. If the source of your problem is the same as mine, your user & group mapping problems should be solved:



Finally!!!!

This error pops up for a couple of reasons. At the top of the script there will probably be a line that looks like this:



This is telling Linux that this script should be interpreted using the /bin/sh program. So your first step is to verify that program exists. I tend to use:



This will typically come back with a response like this:



This is telling us that the path to the sh program is in fact /bin/sh, matching the path specified at the top of the script. Ok, so what gives? Well, it's possible that this script was made on an operating system that has line ending characters different than linux. This could have been on on a Mac or PC, or the file could have been converted when it was packaged. In this case, you get the relatively misleading bad interpreter: No such file or directory message, which is really trying to look for sh, although you don't get any indication of the fact.

So, how to fix? Read on.

Continue reading "Linux shell scripting: bad interpreter: No such file or directory" »

Having recently left a company that had Exchange, the removal of Goodlink from my Samsung Blackjack left the phone in a fairly broken state. I fixed this by doing a full reset (Turn on phone while holding Up Arrow) and choosing 1. This put things back in basic working order.

My efforts to use the built in email client to access my Courier IMap Email had never been successful, so I decided to explore AT+T's XPress Mail system. This consists of client software you install on the phone, and a desktop application that connects through AT+T's servers to give you access to your email remotely, and also can be used to give you access to files on your PC.

Upon install of the client you choose your mail server (in my case IMAP) and input the basic settings required by most IMAP client softare (Account name & Password, email address, the IMAP server, SMTP server, security settings, etc). I did notice an unusual configuration box asking for "Root Folder Path" which I left blank. Here's where the fun began.

Continue reading "AT+T Wireless XPress Mail Courier IMAP setup problem - Trash Folder?" »

I gave a talk on the use of Xen for web developers at Lampsig. It took me a while to get my notes transcribed, but here at last they are. This prescription has been used by me to install Xen successfully on a Fedora core 4 box, Centos 4.3 and 4.4 boxes, and should probably work on RHEL, assuming you can figure out how to get the packages you need.

I cover use of file backed file systems, and how to mount and edit them, as well as expanding a file based filesystem.

I have run gentoo and Centos guests I got from jailtime.org and have found them to be very stable. I even was able to use this on a 64 bit server, although I did have to build my own guest. Many people who have had trouble getting Xen to work reliably when using the packaged (rpm) versions of Xen may find this prescription fixes their problems.

Xen 3.0 Centos How-to