» Arch Linux » Page 1
Arch Linux Insight from Brian Parsons rss

Arch Linux AMI for Amazon EC2

April 02, 2013 at 08:00 PM    


Update August 21, 2016

I am no longer maintaining Arch Linux images for Amazon EC2, and I no longer recommend using Arch Linux on servers. The attitude in some of the core pieces of the system has become far less disciplined and... what I will in a politically correct way say is more centered around agenda than users or system use.

Specifically the issue that broke this for me is the way versions of pacman since the file reorganization effort remove symlinks in the root path install path of a package. This bug has been brought up several times in pacman's history. The author and current Arch czar has stated that symlinks are improper and should be replaced with bind mounts. This approach breaks the best practice of being able to separate the OS from the data, and using bind mounts causes disk metrics, analysis and monitoring to misreport. In previous instances, this bug was fixed, however so far this time it is not being addressed.

I continue to be a proponent of Arch Linux for desktop use, but I have stopped using it on servers. I'm currently deploying using CentOS and most of the scripts I have open sourced for system management have been updated to work with CentOS.


Below is for Historical Purpose only.


These Arch Linux images for Amazon EC2 use my ec2-init script which requires python2 and boto, but other than that they are stock Arch Linux with just the base load and LTS kernel.

Usage Notes:

The ec2-init script will find the following variables in the user-metadata for the instance:

  • hostname - The hostname to set for the instance
  • mailto - the address to email with a message listing the instance information and ip address
  • mailfrom - the from address of the email message

The user-metadata should be pipe delimited like this:

hostname=myhost.example.com|mailto=myemail@example.com|mailfrom=ec2host@example.com

Additionally if the instance is granted IAM role permission to Route53, the script will create or update a DNS entry for the hostname if it finds a matching zone in Route53.

Pacman is functional but key signing has not been initialized. I recommend you install haveged and initialize the package signing:

# pacman-key --init

# pacman-key --populate

The pacman-key --init command will take a while or seem like it is hung while the system gathers enough entropy for the random number generator. To help it out, you can log into another session and do an ls -lR / as it uses system activity.

See Pacman-key on the Arch Linux Wiki for more information.

Arch Linux Boot Script for Amazon EC2

January 17, 2013 at 08:00 PM    


I have an updated Arch Linux image for Amazon EC2 that is systemd. I created a boot script that sets the hostname and root keys. It will even update DNS in Route53 and send you an email letting you know the instance IP.

Released under the MIT license on github.

I am working on cleaning up the base image that I use on Amazon EC2 and publishing the AMI as well.

Best Practices For Using Arch Linux on Servers

December 06, 2012 at 12:00 PM    


I've been running Arch Linux on my workstations and on servers for a long time. Every once in a while I see a debate in an Arch Linux forum about it's suitability for use on production servers. Being a rolling release distribution, it is different than other distributions that concentrate on enterprise and long-term support like RedHat Enterprise and CentOS. Without getting too much into the pros and cons - one of the key reasons that I use Arch on servers is earlier access to newer technologies like the 3.0 Linux kernel series (with built-in xen support). Overall, though, it is due to my familiarity with and love for it. The OS that I load on my servers is there to support my applications. I find Arch is simple and light yet thorough and stable in getting the job done. If you are running Arch on servers or are interested in doing so, here are some practices that I recommend.

This is not meant to be an exhaustive list and there are different approaches to systems administration. I welcome feedback and discussion of these concepts. I have seen projects centered around creating an off-shoot of Arch to use on servers. Ultimately I think they miss the point. The idea is not to make Arch act like CentOS. With some simple tweaks to your deployment and management process, Arch is a fine distro to use on servers.


Dealing with "Rolling Release"


Many of these things apply not just to Arch, but any rolling release distribution. Recently, Arch Linux has gone through some fundamental changes in the base layers of the operating system like the network configuration and system initialization. Updating needs to be a regular and intelligent process. You can automate much of it but you really should do the base updates manually.

1. Have a server in each datacenter or cloud that acts as a "base" server for testing updates. Always have a server that you can test updates on. I use Linode, Rackspace, and Amazon EC2 clouds and I have dev servers in each of those that are there to test updates on so that I can work out any issues before updating mission-critical instances. Once you update the base server, you can image it out appropriately for your environment.

2. Keep Snapshots so that you can "roll back". This is one of those things you should be doing no matter what you are using.

3. Update often. I run updates weekly on my workstations and weekly or bi-weekly on my servers. With a rolling release distribution, the more out of date you are, the more work you have to do with each update. If you don't have a proper environment for testing updates, make an image of your server and run updates against that in something like Virtualbox.

4. Watch the News/Forums/Mailing Lists for Update Issues. I update my workstations first and run that for a few days before updating my servers - unless it is a critical security issue. Package updates fixing security issues should always be done as soon as is practically possible.

5. Don't Run Updates via Daemon or Cron. I do not recommend running system updates via cron. You just never know when an update will require more than just the basics. If you are pushing your own applications via custom repositories, those can be automated if appropriate. (See Custom Repositories below)

6. Script tricky updates. A quick bash script can make updates against servers very simple and painless. I typically run my updates from one spot. Configuration management tools can help here too. (See Configuration Management below)

7. Remove pacman from SyncFirst and HoldPkg in /etc/pacman.conf. The default pacman.conf will stop and prompt to update pacman if there is a new version of it before updating the system. For workstations this is fine, but for servers or when you are running scripted updates, this will get in the way. If you are updating your workstations first and the server last, you will know if you need to update pacman first.

8. Create scripts to bring machines current from your vendor's image. Ideally you are running your own images made from your own base instances, but if you are using the vendor's images - such as the "Arch Linux" installs from Rackspace or Linode, you should have a script that takes that image and brings it current. This script needs to be tested and updated regularly as part of your update cycle.


Understanding the Philosophy


The key to running any operating system on your servers is understanding it and the philosophy behind it. Arch Linux is a lot like python. The driving philosophy is simplicity. Many times people over-think or assume that a given task is harder than it is.

9. Run Arch as your daily driver. Nothing will bring your knowledge up like interacting with the system on a daily basis. Linux is a great deskop OS, give Arch a try.

Also see The Arch Way entry in the Arch Linux wiki.


Custom Repositories


10. Keep private repositories in their own conf file. Instead of the main pacman.conf file, you can create your own configuration file and call pacman with --config filename. This allows you to update the packages from your repo independently of system updates.

11. SSL and ACL protect private repos. I put my custom repos behind a classic ACL username and password. Yes this is present in the .conf file URL in plaintext, but I can always change the ACL if I find it gets compromised. Using SSL will protect it in transit. Of course this isn't foolproof so if you are concerned about your proprietary packages leaking, watch the logs or load the sensitive packages in a different way.

12. Sign your packages. Arch's package management system now supports package signing and verification.

13. Keep workstation and server repos separated. I build custom packages that I use on workstations and servers. I like to keep them in different repos so that the server repo stays as clean as possible.


Configuration Management


14. Configuration Management is your friend. If you are managing multiple servers, configuration management tools like Puppet, Chef, or CFEngine are your friend. Employing one of these tools properly will keep your servers consistent and greatly ease management and deployment.

Again, these practices are not meant to be all-encompassing. There are probably many other things that could go into this, but I hope sharing my approach can help others. The Arch Linux Wiki, Forums, and IRC Channels are always helpful resources.

Disable Akonadi in KDE 4.7

August 22, 2011 at 10:02 AM    


In recent KDE updates, the PIM suite (kmail, kontact) is ...uh... not really working for me. I don't know if it is truly broken or just requires a different approach and understanding.

This has me temporarily using Thunderbird for mail until I can get back to using my beloved kmail. Unfortunately, Akonadi, the engine behind the PIM suite, still insists on going out and fetching mail and doing other things.

Martin Schlander has put up a great post on how to disable Akonadi and I haven't had any messages pop up after following the steps he lists.

Disable Akonadi in KDE SC 4.7

This is the personal web site of Brian Parsons. The views and opinions expressed in essays written on this web site are my own and are in no way related to or reflective of any company that I am associated with.

Creative Commons License Unless otherwise noted, this work is licensed under the Creative Commons Attribution 3.0 Unported License.

Other Work By Brian