Augeas (from EPEL) doesn’t come with a default lens for the munin-node.conf files that control Munin Nodes. So I whipped one together.
(* Munin Node module for Augeas *)
module MuninNode =
autoload xfm
let record =
let value = store /[^ \t\n]+([ \t]+[^ \t\n]+)*/ in
[ key Rx.word . Sep.space . value . Util.eol ]
let lns = (record | Util.comment | Util.empty) *
let filter = incl "/etc/munin/munin-node.conf" . Util.stdexcl
let xfm = transform lns filter
My attempts to migrate a physical CentOS installation to a Virtual machine were fraught with perils. First, I had to figure out how to actually transfer the data. There are many tools out there that say they can assist in a P2V conversion, but the simplest method is usually the easiest. I ended up going with a good old dd.
- First, you’ll want to create the new VM that you’ll be migrating to; we’ll call this the DestinationVM. Just configure the hardware — don’t install an OS.
- Next, boot the VM from the CentOS installation disk and enter rescue mode. At the prompt, type
linux rescue
- Configure the network interfaces and when it asks to search for installations, allow it to initialize the disks in the VM. There isn’t an install present, but we need to setup the disks to perform the copy.
- When the VM has booted run
nc -l -p 6501 | dd of=/dev/sda
This will start the nc daemon and output the data to the /dev/sda disk. Make sure to change the destination disk if it is different than /dev/sda.
- On the physical machine run
dd if=/dev/sda | nc <ip-of-VM> 6501
Tip: Start the command in a screen session if you might be disconnected from the server during the transfer. It may take a while.
- You won’t see anything until the transfer completes. It took 6 hours for a 250GB drive to copy for me. YMMV
- Once the transfer is complete, reboot the VM and you should be good to go!
Sadly, when I rebooted the VM, I encountered the following error:
Reading all physical volumes. This may take awhile...
Volume group "VolGroup00" not found
Unable to access resume device (/dev/VolGroup00/LogVol01)
mount: could not find filesystem '/dev/root'
setuproot: moving /dev failed: No such file or directory
setuproot: error mounting /proc: No such file or directory
setuproot: error mounting /sys: No such file or directory
switchroot: mount failed: No such file or directory
Kernel panic - not syncing: Attempted to kill init!
This error likely means that the kernel copied from the old physical system doesn’t have drivers to support the disk hardware in the virtual machine. Because of this, the LVM configuration isn’t loading properly. The easiest way to resolve this is to reinstall the kernel using yum.
- Boot the VM into the CentOS install CD and at the prompt, type
linux rescue
- Enable and configure networking and allow the mounting of the local installation. Make sure to mount is as read/write — we’ll be making changes to it.
-
chroot /mnt/sysconfig
yum remove kernel
yum install kernel
exit
exit
Note, it’s OK to remove all versions of the kernel. Just make sure you install one before you reboot.
- The system will reboot, once it does, let it load into the OS. If everything went OK, your new system will be up and running!
I spent a while looking for information about how to resize an LVM within CentOS 5.6. After adding additional space to the Virtual disk through the vSphere1, CentOS doesn’t automatically utilize that space. To be able to make use of the extra space, you’ll have to do the following:
Note: These initial steps are required when expanding the size of the root partition. A non-system partition can be expanded without having to restart.
- Boot into a CentOS 5 installation disk. At the prompt, type:
linux rescue
- Type the following commands at the prompt. The following assume you have a standard CentOS LVM configuration.
-
# Create new partition from free space
fdisk /dev/sda
p # Print partition table
n # New partition
p # Primary partition
3 # ID = 3
t # Change partition type
3 # Change partition 3
8e # Type = Linux LVM
p # Print partition table
w # Write partition table
# Create a new LVM physical volume from the new partition
lvm pvcreate /dev/sda3
lvm pvdisplay
# Extend the volume group with the new physical volume
lvm vgextend /dev/VolGroup00 /dev/sda3
# Extend the logical volume to include 100% of the free space on the volume group.
lvm lvextend -l+100%FREE /dev/VolGroup00/LogVol00
# Mount the volume group
lvm vgscan
lvm vgchange -ay
# Resize the filesystem on the volume group to match the total size of the drive.
resize2fs /dev/VolGroup00/LogVol00
As always, have a backup of your data.
1 Learn about how to resize the virtual disk in VMWare KB Article 1004047.
I’m usually a postfix guy. That’s what I run on my servers and it’s the configuration I understand. So when someone asked me to take a look at an issue on a server running sendmail, I was a bit befuddled.
The problem was that any messages sent from the command line, were arriving with a from address of root@localhost.localdomain. This was a bit of a problem. To test and confirm I ran the following:
echo "Who will this message be addressed from? The world may never know." | mail -s "Testing sendmail" alex
And sure enough, I get an email address from root@localhost.localdomain. I end up Googling combinations of ‘root@localhost.localdomain’, ‘localhost.localdomain’ and ‘sendmail’. The options were pretty much useless. Too much noise about changing the sendmail configuration options.
In the end, I stumbled upon the real way to fix it…. Open /etc/hosts and change add the host’s name before the localhost.localdomain entry on the first line.
127.0.0.1 host.foobar.com host localhost.localdomain localhost
::1 localhost6.localdomain6 localhost6
Turns out, sendmail looks for the first hostname in the hosts file for the loopback address and uses that in the from field when a from address isn’t specified by the mail client.
I’m building a NAS and decided to use FreeNAS to deploy it (rather than buy a hardware solution). The installation instructions were easy enough though they didn’t include instructions on how to install FreeNAS onto a flash drive while running a Mac. I found a 512MB flash drive that was perfectly suitable for the install.
Note: The instructions below include terminal commands. The command is presented with an example of expected output.
- Download the latest release of FreeNAS from the downloads page. The version I downloaded was titled ‘FreeNAS-amd64-embedded-0.7.2.5543.img’. Make sure you get the .img file, not the .iso.
- Plug your flash drive into your computer and open a new terminal window.
- Using diskutil, find the device node for your flash drive:
mac:~ alex$ diskutil list
/dev/disk0
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *500.1 GB disk0
1: EFI 209.7 MB disk0s1
2: Apple_HFS Macintosh HD 499.8 GB disk0s2
/dev/disk1
#: TYPE NAME SIZE IDENTIFIER
0: CDROM *512.5 MB disk1
- The flash drive’s device node in the above output is /dev/disk1. Now, unmount the drive:
mac:~ alex$ diskutil unmountDisk /dev/disk1
Unmount of all volumes on disk1 was successful
- Next, we’ll extract the image’s contents onto the flash drive. Warning: This will delete all of the data off of the drive.
mac:~ alex$ sudo dd if=~/Downloads/FreeNAS-amd64-embedded-0.7.2.5543.img of=/dev/disk1
203632+0 records in
203632+0 records out
104259584 bytes transferred in 66.608632 secs (1565256 bytes/sec)
- Lastly, eject the drive.
$ diskutil eject /dev/disk1
Disk /dev/disk1 ejected
Now you can use the flash drive to boot off of and run your FreeNAS instance from. Good times!
So I was looking for web servers to run on my MBP. I came across MAMP which looks like a pretty good piece of software. While downloading I became curious if the MAMP team actually used MAMP servers.
Checking the HTTP headers revealed the following:
Server: Apache/2.2.4 (Linux/SUSE)
I’ll take that as a No.
For the record, I use the LAMP stack for my sites. I am messing around with offline development and needed an environment.