Just before Christmas, Amazon announced the release of Amazon Linux 2. In addition to the usual userland modernization (switching to systemd, providing a newer glibc ABI) and the Linux 4.9 kernel, you can now run it on premise; images are provided for VMware, Hyper-V and KVM. Sometime in 2018, Amazon will also start providing long-term support for Amazon Linux, similar to RedHat Enterprise Linux (RHEL), by promising to support ABI compatibility for at least five years.
I’ve always been somewhat puzzled by Amazon offering their own Linux distribution to customers. No other cloud provider does this, although Google runs their own Debian derivative on non-customer-accessible systems. (For more on that, the slides from a talk they gave in 2013 makes for fascinating reading, in part because live-upgrading a 10-year-old base OS to a newer one while changing from .rpm to .deb is… terrifying yet awesome.) I decided to take a pretty deep dive into Amazon Linux 2’s feature set to see if there’s a compelling reason I could see for customers to adopt it. Continue reading
My team at the CBC is hiring for two vacancies: System Administrator and Senior System Administrator.
Our group does day-to-day server and application management of the CBC.CA infrastructure, which runs almost entirely on Linux (so RHCT-level experience is needed for the former job, and RHCE for the latter). Equivalent experience, especially in the media industry, is welcome. Above all, since we’re a communications company, excellent communication skills and a pleasant demeanor are essential.
To apply, click on the links above. The postings close on Friday, November 26.
I upgraded to VMWare Workstation 6.5 recently and now
/usr/bin/vmware-config.pl is gone. I only discovered this recently when I updated my kernel for a security fix, and lo and behold, the old method of making vmnet, vmmon, etc. modules for the new kernel no longer applies!
It seems like others are having the same problem and I can’t find a sensible solution other than uninstalling and reinstalling VMWare. It seems the geniuses over at the Evil Machine Corporation have decided to replace
vmware-config.pl with some sort of GUI called
vmware-modconfig that doesn’t seem to work right.
Why can’t people just leave working tools alone — or at least preserve the familiar API for people that don’t want to wade through 300 pages of PDFs to figure out how to fix the breakage?
I attended the second annual Ontario Linux Fest on Saturday, held at the Days Inn and Conference Centre near the airport in Toronto. These days I find that my interest in specific technologies is waning and that I’m more interested in the public and social policy angles of technology and in particular, free software. Continue reading
In previous entries here I have described my unhappiness with the Highpoint series of RAID controllers. In particular I owned the 1740 4-port SATA RAID controller, but dis-satisfaction with the frequency of driver updates finally caused me to dump the 1740 for another controller. (Note that even though Fedora 9 is the current release, Highpoint has still not updated their drivers beyond Fedora 7, which is almost EOL.) Continue reading
Recently at work, we tried to implement Xen on Intel Xeon, running a 64-bit dom0/domU. I have to say that this failed horribly, so I’m writing this post to warn others off it. My colleague Gabriel worked hard to migrate everything back to a 32-bit environment, so kudos to him.
The specific symptoms we experienced while running 64-bit Xen is that the domU’s would crash and reboot randomly under (or after) high load. One of our domU’s is a development server, which also runs a CruiseControl, a continuous integration system. This means that every minute, CruiseControl wakes up, does a cvs update to see if there are any changes, and then recompiles the project(s) if needed. Periodically we started to see error messages like
Bad pte = 32971e067, process = cvs, vm_flags = 100077, vaddr = b7f34000
After a few of these, domU would reboot. It seems like others are having the same problem on 64-bit Xen. This user was running CentOS 5.1, which is basically what we’re running (we have the real deal Red Hat Enterprise LInux 5.1).
As I said, migrating the domU back to a 32-bit dom0 seemed to fix this, so let this be a fair warning to others thinking of running a 64-bit dom0.
I got bitten by this bug after upgrading to SpamAssassin 3.2.4 recently. It seems that the GnuPG key shipped with SA precludes the verification of signatures from updates downloaded using sa-update, due to some esoteric defect with the OpenPGP design. Anyway, the point is that attempting to download new signatures using sa-update results in the following error:
error: GPG validation failed!
The update downloaded successfully, but the GPG signature verification failed.
channel: GPG validation failed, channel failed
(How many times can one say the word “failed” before I get the message?)
Anyway, it looks like the SA folks have corrected the problem with their key but it’s only available in SVN trunk so you have to perform the following magic incantation:
$ sudo gpg --homedir /usr/local/etc/mail/spamassassin/sa-update-keys --delete-key 0x5244ec45
$ wget -O - http://cvs.apache.org/viewvc/spamassassin/trunk/rules/sa-update-pubkey.txt?revision=610699 | sudo gpg --homedir /usr/local/etc/mail/spamassassin/sa-update-keys --import -
That assumes you’re using FreeBSD — adjust your paths appropriately.
The bug is still open and will be fixed in the next version (boy, if I had a nickel for every time I’ve heard that from vendors…)
Recently I started taking a basic course in Computer-Aided Design (CAD) at George Brown College – mostly for interest’s sake, although it’s partly because my day job at CBC is exposing me more and more to the engineering side of things, and I imagine it’ll only be a matter of time before I’ll have to start looking at technical drawings. The instructor recommended on day one that we all purchase USB memory keys to save our work, because there are no personal home directories on the George Brown network. Thus begins the sorry tale of how I managed to get a virus on my CBC-issued Windows laptop – thanks Microsoft! Continue reading
One other interesting talk at Ontario Linux Fest was hearing Jon “maddog” Hall give a keynote. I remember Maddog giving a talk at Real World Linux back in 2004; in fact, I even wrote about it. Maddog’s been around the block many times, which is why I was surprised to hear him give a keynote on how the LTSP (Linux Terminal Server Project) and Linux-based thin clients are going to save the world. I’m overstating that a bit, but I feel I have to vehemently rebut. My thesis is: We’ve been on thin clients before, they were called VT100 green screens, and nobody really wants to go back – damn the peripheral factors.
A few weekends ago, I got up at the crack of dawn and headed out to the first (annual, I hope) Ontario Linux Fest. The admission price of $40 clearly signalled that this was a grassroots gathering of Linux hobbyists, but I’m sure many of those in attendance were also professional developers and/or system administrators. Although some of the talks were more show-and-tell that I would have hoped, I had to keep in mind the target audience, and I still learned a few things, particularly regarding the optimization of high traffic websites – thanks to Khalid Baheyeldin for his talk on this topic.