Wednesday, May 08, 2013

time to blog again.

I have been a bit slack with my blogging and not posted much for a long time. This has been due to both working on lots of things, buying a house and a busy lifestyle.

I do however have a few things to blog about. So, in the coming days i will blog about auto_inst os testing, corporate patching, android tools, aucklug, raspberry pi, rdiff-backup, mulitseat Linux, the local riverside community centre, getting 10 laptops, which will run mageia, my cat gorse, gps tracking, house automation, Amazon AMIs and maybe some other stuff.

Saturday, May 28, 2011

a portable, offline, distributed wiki setup

I’ve found recently, that I keep having need of somewhere to write stuff down and that works off line, with updates from different computers.

As I’ve been using git for this for code, and it works fine, thought I would see if I could apply it to a wiki. Turns out, it’s easy. Dokuwiki is a wiki that is packaged with Mandriva and happens to store it’s data in plain text files. It also does not store history in these files, so they stay nice, clean and easy to read with a text editor. They are also conveniently in just one standard place. So, with a minimal amount of work, I turned /var/lib/dokuwiki/pages/ into a git repository, added the pages to the repo, and volla. Now, I can push my wiki up to any remote git repo I want, or pull it from another computer. In my case, I have a main remote repo for git, so push it up to that main repo when I am online, then pull it down to all the computers I use.

Keeping my wiki up to date is now quite simple and easy, with git pull/push and the odd git commit. Merges will happen if I end up editing a page on two different computers before they both get to sync with my master git, but that should be fine as the wiki format is clean and simple text.

Monday, November 22, 2010

Booting an lvm snapshot of /

When it becomes time to upgrade Mandriva, or in fact, any other distro, I always have the same problem. I don’t want to do an upgrade because I can’t easily go back if the upgrade fails. So I usually end up creating a fresh install with a different root volume in LVM, then installing the same packages and copying configuration across, as I see fit. Good, but could be better.

I’ve also found I do keep wanting to try stuff, which would be nice to be able to roll back to a known state if things turn bad. So, recently I investigated how to create LVM snapshots of the root filesystem (/).

The procedure below works for me.. but if you don’t understand it, don’t try this on an important system.

Here is my basic howto:
The example below assumes your root volume is /dev/vg/rootlv. It assumes your /boot partition is a normal partition, not part of /.

1. Create a snapshot of / (which I usually do while it’s running, which means it’s not 100% clean). I create this with the following command.
lvcreate -n rootsnap1 -L 5G -s /dev/vg/rootlv
2. Mount the snapshot in /mnt/rootsnap1
mkdir /mnt/rootsnap1; mount /dev/vg/rootsnap1 /mnt/rootsnap1
3. Adjust snapshot to be able to boot:
perl -pi -e "s#/dev/vg/rootlv#/dev/vg/rootsnap1#" /mnt/rootsnap1/etc/fstab
rm /mnt/rootsnap1/etc/mtab
umount /mnt/rootsnap1

4. Create yourself a copy of initrd that has the new root volume in it. I do this by just editing the current one.
mkdir /boot/tt
cd /boot/tt
cat ../initrd.img | gunzip | cpio -i
perl -pi -e "s#/dev/vg/rootlv#/dev/vg/rootsnap1#" init
find . | cpio -H newc -o | gzip -9 > ../initrd-rootsnap1.img
cd /boot
rm -rf /boot/tt

5. Add the new root snapshot1 to grub’s menu.1st file, by copying your existing entry and changing the copied entry:
initrd.img to initrd-rootsnap1.img
root=/dev/vg/rootlv to root=/dev/vg/rootsnap1
vi /boot/grub/menu.1st
6. Reboot and choose new entry from grub.

Notes:
1. If the snapshot gets full, you’ll loose access to it and the volume it is a snapshot of, until you fix it. You can however, make it bigger at any time before it is full. It will never use more than the size of the original volume.
2. Snapshots can be merged* (fairly new feature) back into the base for that snapshot. This means that changes on a snapshot can be tried and if successful, can be merged back into the base. See lvconvert.
(*note, you don’t want to have the snapshot, or the base mounted at the time. lvconvert will delay until next reboot if you do. Reboot twice for it to completely free up the snapshot space used.)
3. If you take multiple snapshots, it is best to not do large amounts of writes to the base for the snapshots, as every block changed on the base will first have to be copied to every snapshot which affects write performance.

Readers: Comments are welcome, however I do moderate them, so they don’t appear on my blog immediately.

Sunday, November 07, 2010

Public Mandriva 2010.1 AMI now available on Amazon EC2

After some work, I’ve created a Mandriva 2010.1 AMI instance on Amazon’s EC2 service. I’ll go into detail of how I created it, but for the impatient, you can now boot a Mandriva 2010.1 i386 Amazon virtual machine, setup with a base Mandriva install. The AMI ID is: ami-62e2150b and the name is “mandriva-2010.1-go”. You can find this image in the list of public AMI’s on Amazon if you search for mandriva. The smallest machine Amazon provide costs only around 2 cents per hour, if you just want to play with it.
Getting down to how I actually created this, is a little more interesting. Amazon now provide two things that make building your own machine on Amazon easier. The first is a think called EBS, which is basically the ability to create block devices and give them to the OS, they are persistent storage and reasonably fast. The second is that Amazon now have a thing called PVGRUB. This lets it boot any standard kernel that supports running as a Xen guest. (dom U).
To build the one I have made public, I started with an install of Mandriva inside a virtual machine I created, by using the normal installer and unselecting everything except the base and urpmi. I then booted an existing Amazon machine that was running a different version of Linux. I attached another EBS disk to the machine, made a file system and used rsync to copy all the files from my vm (which had been shutdown), onto the EBS storage at Amizon. After that, I adjusted /boot/grub/menu.1st and fstab, then switched my EBS storage devices around to boot from the Mandriva one I has just created. I then added an appropriate script to /etc/rc.d/rc.local to install the appropriate ssh key on boot when I make it public, and created a snapshot of the EBS decive. From this stapshot, I was able to create the AMI ( using ec2-register), which clones the snapshot every time someone creates a virtual machine based on the snapshot.
I can create the EBS ami with whatever size disk I want, as I setup the image to run a resize2fs on first boot to grow from the 2GB snapshot to whatever size people want. The public one I created has a 4GB disk to start with.

Tuesday, January 26, 2010

Mandriva 2010 issue of Linux Identity

For the latest 2010 release, I spent quite some time working on all the articles for the Mandriva 2010 issue of Linux Identity magazine . These articles are suitable for beginners, with the most complex article being one on a basic Mandriva Directory Server setup. They recently posted me a copy of the magazine, so enjoyed seeing my work, as I can’t buy the magazine here.

For those wondering, working on magazine content takes a lot longer than writing a blog, but is rewarding and worth while to me, as I want to support the community, which I feel involves all, including beginners that like to buy magazines with DVDs attached. :) I tried to cover things like installing Mandriva, setting up dual boot ( Transfug drake does need some improvement ), personalization of the desktop, multi users including parental controls and installing new applications.

I found writing the articles alerted me to many bugs as I started this during the beta’s of Mandriva 2010, so it was a process of write something, log a bug, push to get bug fixed before the final release.. so that the article did not have to have a.. oh, this works, but you have to make these changes to xyz.

Saturday, November 21, 2009

Happy first time Linux users, with Mandriva 2010

I recently setup a new computer for a friend, who’s win98 computer had broken some time ago. Purchased a really cheap new PC, dual core E5300 cpu, 2GB ram, on board everything, with sata disk and dvd writer, plus an 18.5 inch screen, came out to $630 NZD.

Now, I had the difficult call to make, as to Mandriva or Ubuntu, because Ubuntu is very popular in NZ so he might be able to get better community support for it, and their are local mirrors for updates. Anyway, decided that it was going to be Mandriva x86_64, 2010.0 with KDE 4.3, because I know it well and because is has some tools I planned on using.

He received the machine today and was rapped. Plugged his printer in and it just worked!.. and they even got imap with kmail configured without my help.

Now, I usually configure systems for myself, but this was for a real beginner, so I needed to keep things simple and make it easy for him, so I made a few changes to the configuration, however discovered some things that I think need improvement along the way.

First thing was, I installed Mandriva 2010.0 Free, then had to add in a bunch of commercial apps, because you can’t expect a beginner user to go without them or install them himself.. The most notable was Flash Player, I think this should be easier to get, for 2010.0 free. It’s in PLF, but only in the i586 repo, and beginners are not even going to know about PLF. So, my point here is, since it ships with Mandriva one, should be easy to get for Mandriva Free 2010.0 users.

Also installed Skype, Picasa and Google Earth and the necessary codecs to play DVDs, mp3, movies, etc. No packages available for the Google apps so had to install them by downloading the installers from Google.

Next, thought I’d fire up Transfugdrake and pull the configurations from his old hard drive, plugged in via USB. Not so easy, I ended up having to hack the source code in /usr/lib/libDrakX/transfugdrake.pm to even get it to look at the disk. It should be able to be pointed at a mount point, and told to run.. without having to rely on the auto detection, which did not work at all in my case.

Transfugdrake did import some bookmarks, and the wall paper, plus some documents, although it missed all his documents that were on the desktop in windows. So, some thoughts around transfugdrake is…. it needs some improvements and a lot of testing! It also found his email address, but didn’t import it into anything useful in KDE4.3.

Next I tried to make life simpler for him, so did things like, reduced the number of desktops, added applications to the bottom panel, configured updates, added a link to the documentation, added him to the wheel group and configured sudo.

I wanted passwordless login, so I ran systemsettings as root, then configured KDM to auto-login and to not require passwords if he logged out. Pity this method of configuring auto-login is hidden for the average user.

Next I fired up Amarok, and discovered it wanted to use kwallet.. even when I had not entered any passwords for Amarok. The Last-fm plugin seems to want to open kwallet, even when it’s not storing a password… this brought me to the next thing, which was I wondered if it was possible to make kwallet not require a password for the default wallet. I could not find a way to do this, so ended up just turning off kwallet to keep in simple.

Next was making the configuration tools easy to get to. I set most things in the Mandriva authentication settings to not require a password, but could not find a way to allow access to drakconf without a password, so a quick edit of the .desktop file to run sudo drakconf fixed the problem nicely.

Maybe drakconf should try sudo, if the user can use sudo to run it, then use sudo instead of always requesting the root password.. This would make it easier for users, and is no less secure.

Next was backups, as I remembered drakbackup… however, found draksnapshot, which is even nicer. I created a ext4 partition on his old hard drive and used that for the backups with draksnapshot. It’s nice, but configuration is too simple, and, although it works, it runs on cron, so the user can’t trigger a backup, and it will only do daily backups at 4am by default.. So, was kindof limiting. I reconfigured cron to run the daily backups at a time he might be using the computer, then explained how it works. It would be good if the user could trigger a backup when the backup media is added. This kind of makes sense because draksnapshot initially prompted to use the media for backups in the first place.

I think using rsnapshot is smart, efficient and makes recovery easy, but think we need to work on improving the user interface of draksnapshot… Looking at the Ubuntu solution, of SimpleBackupSuite, it has many more options to control the backup.. Now, sbackup could be packaged for Mandriva, but it creates tar based backups, similar to drakbackup, which don’t seem as good to me as using rsnapshot.

anyway, a happy user, and looks like another couple of Mandriva converts.

allowing guests in via ssh

I recently setup a demo machine for a presentation on pxe boot, where I wanted people to be able to login and have a look around a demo pxe boot VM.

Lots of ways to do this, but the way I wanted to make this work was via ssh, without requesting a password.

To do this, I configured sshd with:

UsePAM yes
PermitEmptyPasswords yes

and configured /etc/pam/sshd, to allow members of the demo group access, by adding the following line:

auth sufficient pam_succeed_if.so user ingroup demo

then I just add users, and put them in the demo group if I want them to login without a password.. neat.

Monday, August 17, 2009

Improving pxe boot menus

Mandriva has a fairly good tool for building and managing pxe configuration. It’s called drakpxelinux. This is the tool that got me started with network booting and although it has some fairly rough edges, worked fairly well.

After exploring some more, I discovered that pxelinux, part of the syslinux package can do much more than people traditionally use it for.. This includes graphics, multiple boot options and menus, context and general help text and passwords and ability to change kernel options. A screenshot below is an example of what we now use at work for the default menu.
Mandriva Linux CS5 beta testing @ 2009-08-17 22:32:21
This really makes things a lot easier to use and looks quite professional.

We have menu items for:

Installers:

  • Red Hat
  • Red Hat with kickstart
  • Centos
  • Mandriva with nfs preconfigured

Running off the network:

  • Red Hat using it’s nfs snapshots, confugration created from the system-config-netboot tool
  • Knoppix
  • FreeDos
  • Memtest86 and PXEKnife, which includes some basic Linux flavors, firmware updating tools, password reset tools, disk wiping and other random stuff.
  • Clonezilla and udpcast

I am wondering about adding a “Graphics” option into drakpxelinux which would allow people using drakpxelinux to configure a graphical boot menu, probally using a couple of templates and allow them to incorporate their company logo.  I am also thinking it might be nice to provide a package that contains a bunch of common pxe tools and configurations. I am Interested in this, because I am also interested in making a better way to network boot Mandriva to run it diskless.   I might see if I can get some help with some of it, as have limited perl skills, although the code not looking too tricky from my breif inspection.

Anyone interested in my sample configurations, can get them here.

DHCP and tftpd configuration is mostly standard for pxe setups, let drakpxelinux configure it for you, although you will need to point to pxelinux.0 rather than linux.0 in the dhcpd.conf file.