And now for something completely different : Dave Brubeck Quartet's Time Out album is currently on heavy play. I know I'm late to the party. In fact, I was born to late for this party. But I really really digging the combination of mellow, swing and exotica on this album.
And this is a big reason is why you pay a real sysadmin to do your system administration.
In short, people were installing WordPress badly (friends don't let friends use PHP). They were allowing password authenticated ssh login over the internet. They were doing
chmod 0777 ~apache/html_docs. They were doing other highly unsafe things.
If you can't see the problem with these things, then you need to talk to a professional sysadmin.
I FINALLY found it!
The problem: You are messing around with loopback files and volume groups. You've removed the loopback, but the VG stays in the kernel's internal list.
vgremove is of course NOT how you get rid of it.
The sane way of doing this is:
vgchange -a n VolGroup00 kpartx -d /dev/nbd0 qemu-nbd -d /dev/nbd0 vgscan
But maybe you killed qemu-nbd by mistake? Or maybe your partition is long gone. Then you need to use dmsetup to remove all traces:
# ls -l /dev/mapper/ total 0 lrwxrwxrwx. 1 root root 7 Mar 18 22:08 GEORGE2-root -> ../dm-0 lrwxrwxrwx. 1 root root 7 Mar 18 22:08 GEORGE2-swap -> ../dm-1 lrwxrwxrwx. 1 root root 7 Mar 19 15:44 Test02-LogVol00 -> ../dm-4 lrwxrwxrwx. 1 root root 7 Mar 19 15:44 Test02-LogVol01 -> ../dm-5 crw-rw----. 1 root root 10, 58 Mar 18 22:08 control # dmsetup info /dev/dm-4 Name: Test02-LogVol00 State: ACTIVE Read Ahead: 256 Tables present: LIVE Open count: 0 Event number: 0 Major, minor: 253, 4 Number of targets: 1 UUID: LVM-zo1BvaMXr6TS1knhxoyjhtItHEaIVH4wGJz2s2w8w24za3486Aa9ur0igGMxpLf7 # dmsetup remove /dev/dm-4 # dmsetup remove /dev/dm-5 # vgscan Reading all physical volumes. This may take a while... Found volume group "GEORGE2" using metadata type lvm2
And there was much rejoicing.
Nothing is beyond me. When it comes to computers, I am all conquering.
That actually might be an exaggeration. But I just pulled off a stunt that really impressed me.
I'm moving all my systems from CentOS 5 to CentOS 6. (Why so soon? Shut up) In the process, I need to move my VMs from VMware Server 1 (Seriously? Shut up) to KVM (libvirt specificly). For the most part, I'm actually starting up whole new VMs and reconfiging them. But I still might want to look at my old data, fetch old files, and what not. This means being able to read VMware's vmdk files. This is "easy":
modprobe nbd max_part=8 qemu-nbd -r --connect=/dev/nbd0 /vmware/files/sda.vmdk kpartx -a /dev/nbd0 vgscan vgchange -a y VolGroup00 mount -o ro /dev/mapper/VolGroup00-LogVol00 /mnt/files
There are 3 complications to this:
First, you can't have multiple VGs with the same name active at once. Work around is to only mount one at a time. You can renamed VGs with
vgrename but that's a job for another day.
Next off, I chose to have my vmdk split into multiple 2GB files. This makes copying them around so much more fun. But qemu only understands monolithic files, so you need vmware-vdiskmanager to convert them. Specificly
vmware-vdiskmanager -r /vmware/files/sda.vmdk -t 0 /vmware/files/single.vmdk
Lastly (and this is the main point of this post) CENTOS 6 DOESN'T SHIP WITH NBD! After WTFing about as hard as I could, I googled around for one. Someone must have needed nbd at some point, surely. The only solution I found was to recompile the kernel from scratch. Which is stupid. As a work around, I used the kernel-lt from elrepo. But the real solution would be a kmod. I thought doing a kmod would be hard, so I set aside a few hours. Turns out, it's really easy and I got it right on the first try.
tl;dr - rpm -ivh kmod-nbd-0.0-1.el6.x86_64.rpm
- Install the kmod-jfs SRPM;
- Copy jfs-kmod.spec to nbd-kmod.spec;
- Copy kmodtool-jfs-el6.sh to kmodtool-nbd-el6.sh
- Edit nbd-kmod.spec. You have to change kmod_name and the %changelog section. You might also want to change kversion to your current kernel (uname -r). If not, you need to add --define "kversion $(uname -r)" when running rpmbuild;
- Create nbd-0.0.tar.bz2;
- Build, install and test the new module.
rpmbuild -ba nbd-kmod.spec rpm -ivh ~/rpmbuild/RPMS/x86_64/kmod-nbd-0.0-1.el6.x86_64.rpm modprobe nbd ls -l /dev/nbd*
- FLAWLESS VICTORY!
The hard part (of course) is that I wasn't sure what to put in nbd-0.0.tar.bz2. The contents of jfs-0.0.tar.bz2 just look like the files from drivers/jfs in the kernel tree with Kconfig and Makefile added on. So I pull down the kernel SRPM, did a
rpmbuild -bp on that (just commend out all the BuildRequires that give you grief. You aren't doing a full build.) Then I poked around for nbd in ~/rpmbuild/BUILD/vanilla-2.6.32-431.5.1.el6/. Turns out there's only nbd.c and nbd.h. So that goes in the pot. I copied over the Makefile from jfs, modifying it slightly because jfs is spread over multiple source files. Kconfig looked like kernel configuration vars. I just copied BLK_DEV_NBD out of vanilla-2.6.32-431.5.1.el6/drivers/block/Kconfig.
This entire process took roughly 1 hours. It worked on the first try. Of course, all the magic is in kmodtool-nbd-el6.sh. But I was expecting a lot of pain. Instead it worked on the first try. I was so surprised I did
modprobe -r nbd ; ls -l /dev/nbd* just to make sure I wasn't getting a false positive.
WARNING The encryption of encfs is severly broken. Do not rely on it to keep anything secret.
So one can layer encfs on top of google-drive-ocamlfuse.
Here's how I set it up.
yum --enablerepo=epel install rlog-devel boost-devel wget http://encfs.googlecode.com/files/encfs-1.7.4.tgz tar zxvf encfs-1.7.4.tgz cd encfs-1.7.4 ./configure --prefix=/opt/encfs-1.7.4 \ --with-boost-serialization=boost_serialization-mt \ --with-boost-filesystem=boost_filesystem-mt make all && sudo make install sudo sh -c "echo /opt/encfs-1.7.4/lib >/etc/ld.so.conf.d/encfs-1.7.4.conf" sudo ldconfig for n in /opt/encfs-1.7.4/bin/encfs* ; do sudo ln -s $n /usr/local/bin done encfs ~/googledrive/Backup/Encoded ~/encfs
And now "all" I have to do is
rsync -av /remote/pictures/ ~/encfs/Pictures/ --progress. And wait. A lot, given I'm getting roughly 12.43kB/s though this setup.
Given that 1TB of backup from Google is now 10$ a month, I had to look into doing cloud backups again.
Google doesn't have a native Linux client. So one has to use google-drive-ocamlfuse. Installing this on CentOS 6 is surprisingly complex. And Google Drive's auth mechanism is based around a web interface.
But once I got it working, it Just Worked. Or rather, I could copy small files to ~/googledrive, see them via the web interface, delete them there and they are now missing.
Of course you wouldn't leave unencrypted backups on Google's servers. I futzed around with gpg a bit, but maybe layering encfs on top of google-drive-ocamlfuse would be a better idea.
My experimetation was cut short by supper, and by the fact that uploading a 400MB file was very slow :-) (sent 418536429 bytes received 31 bytes 219416.23 bytes/sec aka 1.6 Mbit/S)
For the record, here is how I installed google-drive-ocamlfuse
yum install m4 libcurl-devel fuse-devel sqlite-devel zlib-devel \ libzip-devel openssl-devel curl -kL https://raw.github.com/hcarty/ocamlbrew/master/ocamlbrew-install \ | env OCAMLBREW_FLAGS="-r" bash source /home/fil/ocamlbrew/ocaml-4.01.0/etc/ocamlbrew.bashrc opam init eval `opam config env --root=/home/fil/ocamlbrew/ocaml-4.01.0/.opam` opam install google-drive-ocamlfuse sudo usermod -a -G fuse fil google-drive-ocamlfuse google-drive-ocamlfuse ~/googledrive
The second to last command will open a browser to get an OAuth token. This means you need htmlview and a valid DISPLAY. The token is only good for 30 days. This is something that needs to be better automated.
I was working on a CentOS 6 install for work and figured "hey, I should upgrade Mustang to the latest version." Normally this means
yum upgrade shutdown -r now
Of course that didn't work; Mustang has an APU and uses a proprietary driver from AMD for X.org. I pretty much never use Mustang's console so I didn't notice this for 2 days, when my wife complained about not being able to watch Lost.
After much futzing, I find the error message:
symbol lookup error: /usr/lib64/xorg/modules/drivers/fglrx_drv.so: undefined symbol: GlxInitVisuals2D. This means AMD's driver is doing something stupid. I of course can't compile it nor fix it. I tried to download the latest driver, but that refused to install. Curse swear, google google and then I found it.
rpm -ivh http://elrepo.org/linux/elrepo/el6/x86_64/RPMS/elrepo-release-6-6.el6.elrepo.noarch.rpm rpm -e fglrx64_p_i_c-12.104-1 --nodeps yum -y install fglrx-x11-drv-32bit fglrx-x11-drv kmod-fglrx aticonfig --initial
First line installs ELRepo, which you might already have. Second line removes the previous drivers, which conflict with the new ones. The
--nodeps is because Adobe really wants OpenGL installed. Third line is the important one, it installs the new drivers and does all the magic to get them working. Yes, the X.org driver needs to install a kernel module. Last line just makes sure that Xorg.conf is set up properly. I'd been playing around in it to try to get it to work.
So Death to Proprietary Drivers! And long live the guys at ELRepo!