webgen

Webgen creates websites with linked menus, common stylesheets and template and page files which work as site wide models. It does this automatically using perl scripting.

create a new site:
cd into directory that will hold new site.
webgen create -t default -s andreas08 mysite
on a default installation you choose between three templates -t and several styles applied to those templates -s
when created cd into your new website top level folder (eg mysite) and run command ‘webgen’ to create the static html content. The html created resides in a subfolder called ‘output’. Run same command each time any changes are made. Content of the output folder is what needs ftp’ing to your webserver. Seeemples.

mdadm on existing setup

These notes relate to my ubuntu 9.10 setup. When I first setup up I had two sata drives (sda1 and sdb1) and an IDE drive (sdc1). sdb1 was one of an intended pair of 750gb drives that I wanted to set up as RAID1 using mdadm for /home, however the 2nd of that pair went back to samsung and was replaced under warranty at the time of setting up the 9.10 machine. The challenge here was could I add the 2nd 750gb drive, create the RAID and transfer what was on original /home as a regular ext3, without having to totally start over. Short answer – yes!

First let’s see what’s happening with the drives:

root@server:~# fdisk -l

The new drive is placed as /dev/sdb. The previous sdb1 (/home) gets renamed to /dev/dsc1 and the IDE goes to sdd1. As my fstab is using UUID’s this presents no problem. To prepare the new drive

root@server:~# fdisk /dev/sdb

This brings up the fdisk command prompt: use n for new partition; partition type is ‘fd’ for linux raid.

To manage what I want to do I need to setup an mdadm raid1 array without the 2nd drive in place:

root@server:~# mdadm --create --force --verbose /dev/md0 --level=1 --raid-devices=2 /dev/sdb1 missing

Result:

mdadm: size set to 732571904K

mdadm: array /dev/md0 started.

OK, lets check what’s happening with mdadm:

root@server:~# cat /proc/mdstat

Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]

md0 : active raid1 sdb1[0]

732571904 blocks [2/1] [U_]

unused devices: none

OK, format the new array drive with:

root@server:~# mkfs.ext3 /dev/md0

create info for the mdadm config file with:

root@server:~# mdadm --detail --scan --verbose > /etc/mdadm/mdadm.conf

Mount the new array (/dev/md0) as /whatever

root@server:~# mkdir /whatever

root@server:~# mount /dev/md0 /whatever

Copy contents of /home to /whatever.

-a is archive, preserves all attributes; -v verbose, let’s you know what’s happening:

root@server:~# cp -a -v /home/* /whatever

unmount the old /home:

root@server:~# umount /home

OK so now use fdisk again change the partition type of sdc1 to fd as above,

then add sdc1 to the array with

root@server:~# mdadm --add /dev/md0 /dev/sdc1

Next check that the new array can mount manually:

root@server:~# mount /dev/md0 as /whatever

OK!

Problem: after a reboot there doesn’t appear to be a /dev/md0 Where’s it gone?! Don’t worry it’s become /dev/md_d0 instead. This is the new naming convention which mdadm uses on newer linux kernels that can make md devices partitionable (see mdadm MAN on this).

Next issue is that /dev/md_d0 will need mounting as /home using fstab. Using the UUID that the mdadm –scan command uses appears not to be the right one. Using the command blkid (Block ID) gives another UUID for the RAID partition itself. Use that in fstab.

STUCK AT PRESENT

Can’t get the raid drive to mount using fstab:

First of all simply tried hashing out the old /home and using the new raid drive, the UUID for the raid device is the one that blkid is giving me. like this:

# orig /home was on /dev/sdb1 during installation

#UUID=e2c6ff62-a576-4182-b5e0-82c9fea9601c /home ext2 relatime $

# raid /home on /dev/md_d0 created during raid setup

UUID=9c1a494c-0e38-4f3b-b1f1-cdf66f4e7c0a /home ext3 relatime $

No go, so I also try this:

# orig /home was on /dev/sdb1 during installation

#UUID=e2c6ff62-a576-4182-b5e0-82c9fea9601c /home ext2 relatime $

# raid /home on /dev/md_d0 created during raid setup

/dev/md_d0 /home ext3 relatime 0 $

Still no go; boot halts saying that /home cannot be mounted.

OK that could because I can’t simply switch the /home directory without doing some other things perhaps. So let’s just try and get the raid to mount as /whatever:

# raid /home on /dev/md_d0 created during raid setup

UUID=9c1a494c-0e38-4f3b-b1f1-cdf66f4e7c0a /whatever ext3 relatime $


This results in /whatever being empty?

Huh?

this works:

markp@server:~$ sudo mount /dev/md_d0 /whatever

So does this:

markp@server:~$ sudo mount UUID="9c1a494c-0e38-4f3b-b1f1-cdf66f4e7c0a" /whatever

OK So John thinks there’s something squiffy with my fstab. knocking the options off of it and doing a mount -a indicates that might be right.

However rebooting fstab doesn’t mount /whatever, but after boot ‘mount -a’ does add it in. This makes me think the raid is not ready to be mounted at initial boot time perhaps?

Unstuck – ie got it working!

When I finally freed up the second 750gb drive from it’s /home duties I tried to add it to the /dev/md_d0 raid drive. No joy. Lot’s of attempts, including changing the format of the drives to ext4.

Got it fixed by simply running the create again, with force. Done away with all the faffy partition stuff by adding –auto=md This creates an (old fashioned?) regular /dev/md0

Complains that sdb1 and sdc1 are part of a raid and had a ext2 and ext3 partition (I’d definately tried to change them from that??). Anyway this time the new ext4 /dev/md0 is working OK.

root@server:~# mdadm --create --force --verbose --auto=md /dev/md0 --level=1 --raid-devices=2 /dev/sdb1 /dev/sdc1

Now to copy /home to it then mount it as new /home. Then see if the new install (10.04) will see the raid from install (using server version)