I’ve been keeping an eye on MariaDB for a while. Since MySQL was acquired by Oracle, there have been concerns in the community about how Oracle will manage it going forward. MariaDB is a fork of MySQL, run by some of the people who originally created MySQL, that was created to address these concerns. It’s recently been picking up a fair amount of attention, in particular with some Linux distributions choosing to use it as a replacement for MySQL. (This reminds me of what happened with LibreOffice a couple years back.)
Anyway, I work with a MySQL system and I now have a need to get it running on a cluster of some sort, for scalability and redundancy. Since MariaDB Galera Cluster appears to be a little easier to set up and more flexible than MySQL Cluster, I figured that this would be a good time to put it to the test.
The purpose of this post is to document the process that I went through getting a MySQL database moved over to MariaDB and set up in a cluster. I hit a few snags along the way, so I figure that this could be useful to others.
Continue reading Moving a single-instance MySQL server to MariaDB Galera Cluster
Here’s a post I’ve been sitting on for a bit over two years. I was doing some clean-up/organization on my hard drive today and I ran across the text file with the notes that I made. :-P
We have some Dell servers running Ubuntu Server on a RAID array. It is necessary to be able to check on the status of the RAID array programmatically and fire off alerts if one of the disks fails.
This is actually pretty easy to accomplish.
First, install the mpt-status package (sudo aptitude install mpt-status).
Then, load the mptctl kernel module (sudo modprobe mptctl).
Find the SCSI ID for your disk array (sudo mpt-status -p). For me, it was “2.”
Get a RAID status report with mpt-status -i 2 (where “2” is the SCSI ID from the previous step). mpt-status should be run as the root user. You can add the -n flag to get some additional information in the output, including the percent completion of an in-progress rebuild operation.
The exit code for mpt-status will be 0 if everything looks good or something else if there is a problem.
Nowadays, most local area networks have a DHCP server running on them. This is, of course, how hosts on the network are assigned their IP address and other stuff they need to know (router address, DNS servers, etc.).
The DHCP server has a pool of addresses that it is allowed to hand out to clients, and it will often hand out these addresses sequentially. In some cases, the address chosen for a particular client may be based on some sort of hash function on the client’s MAC address (so that the client will always be assigned the same address, unless there is a hash collision).
Of course, sometimes it’s nice to assign a particular device on your network a specific IP address (a “static” or “fixed” IP address). This way, you will always know without any doubt what the IP address or your printer or file server or whatever is. Of course, you can just set the address manually on the device, taking care to place it outside of the DHCP pool.
Continue reading Have Ubuntu Server hand out “static” or “fixed” addresses via DHCP
Today, I installed the new Parallels Plesk 10.0.1 on Ubuntu Server 10.04. This is the first release of Plesk that supports any version of Ubuntu newer than 8.04. Anyway, after the install, I went to log in and filled out the initial setup information, and was then given this error:
Unable to restart Named: dnsmng failed: dnsmng failed: dnsmng: Service /etc/init.d/bind9 failed to restart
(What a great error message.)
Whoops. Turns out there’s a problem with the default Plesk configuration of the DNS server BIND (run it in a chrooted environment) and Ubuntu’s configuration (run it with AppArmor, explicitly configuring which files it is allowed to open). You have to give BIND permission to open the files in its chroot environment. The solution to this problem is to edit the file /etc/apparmor.d/usr.sbin.named and add these lines before the closing brace at the end of the file:
Then, reboot the machine and you should be good to go.
I’ve actually run into two separate causes of this problem during my time running Ubuntu Server machines. And while I am discussing Ubuntu Server in this post, I see no reason why this same problem couldn’t affect the desktop version of Ubuntu, or maybe other Ubuntu variants (Kubuntu, Xubuntu, etc.).
The problem: You’ve enabled automatic security update installation, and yet, security updates are not being automatically installed.
Continue reading Automatic Security Updates Not Happening in Ubuntu Server (10.04)
Alright, this is actually a pretty simple problem, but only once you know which configuration files to look at.
I recently replaced the machine that powers this very web site with a better one. This was my first migration since switching to Ubuntu Server last winter. I essentially took the hard drive out of the old machine and plopped it in the new one, booted it up, and hoped for the best. Since Linux is not as picky as Windows about being moved to a new set of hardware, I figured it would work out fine.
Sure enough, Ubuntu booted right up on the new machine without so much as a complaint. However, network connectivity was gone. The old machine was using a PCI Ethernet card, while the new machine had an on-board controller that I hoped to use. Anyway, I took the PCI card from the old machine and put it in the new machine, and then the network connectivity was back.
Why wouldn’t Ubuntu just start using the on-board controller, though?
Continue reading Moving an Ubuntu Server install to another machine – where’d my network connection go?