If you ever get this:
mdadm: error opening /dev/md0: No such file or directory
do:
ls -la /dev/md0
If the file does not exist create it as follows: (I am assuming your kernel already supports software raid)
mknod /dev/md0 b 9 0
Random Numbers And Shuffling Cards
This was an entertaining read.
Cheating at Cards
I found this as well:
For those wishing to test PRNG’s csrc.nist.gov
Xen Virtaul Machine
I have been using UML for quite a while now. Unlike most people my main reason for using it is security. You can run a UML instance inside a chrooted env as an unpriviledged user which is a bonus because it’s still a grey area if people can break out of a UML instance over the wire and remain connected (correct me if I am wrong). Breaking out into a chroot (/) as a user with no privs would definitely add another barrier to entry (I am not saying it can’t be broke, just that the guy cracking it is on a differnt level from the normal script kiddie at least until it becomes common knowledge how to do it).
Of course using UML has a price. Its slow. The main problem with UML Is IO. It’s really crap with high IO applications like databases. I tried it with PostgreSQL and it was awfull. Too much context switching.
I had heard of Xen on the grapevine and decided to have a look at it to see if it would be any faster and I was pleasently suprised to find that it is as easy to install as a new kernel. It was at this point that I really kicked myself, Xen as it stands today (version 2.0.7) does not support SMP. So I would be losing a processor using it. Unfortunately this is not acceptable on the machine I am on so I decided to postpone my foray into Xen and stick with UML for the time being on this box or at least until Xen domain 0 can support an SMP machine.
I am however tempted to invest in a single proc machine and run Xen on it. I am confident that Xen does what it says on the tin and that performance gains are substantial over UML but I would rather run a vanilla machine on a dual proc than lose one of them.
Moving from Lilo to Grub
Is a pain in the ass, or at least it was for me. I have been a die hard lilo fan for a fair while but I wanted to try Xen which meant I needed to use Grub. The biggest problem I had was not realizing that if your grub.conf file is missing then you need to boot manually from the grub command line. The command line is actually quite simple once you know the steps to boot your machine (If you get a VFS error you probably don’t have your file system built into your kernel, try again).
Not knowing how the hell
title blah root (hd0,0) kernel /vmlinuz-nnnnnn root=/dev/sda2
the bits in bold above related to each other I created 4 entries in
/boot/grub/grub.conf
and tried each in turn until I realized that
root (hd0,0) is the partition my /boot/*files* are on
and
root=/dev/sda2
is the actual root file system. Would it not have been simpler doing
title blah boot (hd0,0) kernel /vmlinuz-nnnnnn root=/dev/sda2
Software Raid
I created identical partition tables on my two SATA disks or rather I made the/dev/sdb identical to /dev/sda because my current root file system resides in /dev/sda2 and /boot/ is on /dev/sda1
/dev/sda1 == 200MB /boot/
/deb/sda2 == 2GB /
/deb/sda2
/dev/sdb1
/deb/sdb2
/deb/sdb3
I then ran the following command.
mdadm --create --verbose /dev/md0 --level=1 --raid-devices=2 /dev/sda3 dev/sdb3
To make sure everything is running properly:
cat /proc/mdstat Personalities : [linear] [raid0] [raid1] [raid5] [multipath] md0 : active raid1 sdb3[1] sda3[0] 196996992 blocks [2/2] [UU] [==>..................] resync = 10.3% (20347136/196996992) finish=46.4min speed=63318K/sec unused devices:
The next step is that when the resync is finished is to use lvm and set myself up some areas to work in.
isd200_get_inquiry_data
If you are compiling a Linux kernel and it fails complaining about
isd200_get_inquiry_data
ide_fix_friveid
Make sure that
CONFIG_USB_STORAGE_ISD200=n
when
CONFIG_USB_STORAGE=y
pxe Linux Install
I recently purchased a Dual Opteron HP Proliant and decided today to install Debian on it. The first problem is that there is no CD/DVD in it. I know I could have just ripped one out of another PC but I decided to do things a bit differently.
Basically I wanted to install Debian on the machine and the simplest way to do this if we are not allowed to use a CD is to use PXE and some ingenuity.
These are a rough set of steps I followed
apt-get install tftp-hpa and tftpd-hpa
You will also need a dhcp server and a resolver
apt-get install dnsmasq dhcpd
mkdir /tftpboot
grab The debian net insall bits
cp netboot.tar.gz /tftpboot/
cd /tftpboot/
tar -zxvf netboot.tar.gz
chown -R nobody:nogroup /tftpboot/*
edit /etc/xinetd.conf and add the following
service tftp
{
disable = no
socket_type = dgram
protocol = udp
wait = yes
user = root
server = /usr/sbin/in.tftpd
server_args = -s /tftpboot
}
/etc/init.d/xinetd restart
add the following to /etc/dhcp3/dhcpd.conf
host box2 {
hardware ethernet 00:00:1a:19:4e:7c;
filename “pxelinux.0”;
fixed-address 192.168.1.10;
}
subnet 192.168.1.0 netmask 255.255.255.0 {
range 192.168.1.20 192.168.1.30;
}
add the following to /etc/dnsmasq.conf
interface=eth1
dhcp-host=00:00:1A:19:4E:7C,box2
For those using an iptables firewall
iptables -A OUTPUT -p udp -o eth1 -j ACCEPT
iptables -A INPUT -p udp -i eth1 -j ACCEPT
iptables -A INPUT -p udp -i eth1 –dport 67:68 –sport 67:68 -j ACCEPT
iptables-A INPUT -p udp -i eth1 –dport 67:68 –sport 67:68 -j ACCEPT
iptables-A OUTPUT -p udp -o eth1 –dport 53 -j ACCEPT
iptables-A INPUT -p udp -i eth1 –sport 53 -j ACCEPT
Set the client machine to use network boot and restart it and hey presto a Debian installer. I chose linux26 at this point because I am using SATA disks with an Adaptec 1210SA controller.
ssh Notes
I had an odd problem using ssh that stumped me for a bit.
Using ssh -vvv user@host
Cutting out all the fluf we see that normally (when using a public key) we get something like the following
……………………
debug1: Next authentication method: publickey
debug1: Trying private key: /home/user/.ssh/identity
debug3: no such identity: /home/user/.ssh/identity
debug1: Trying private key: /home/user/.ssh/id_rsa
debug3: no such identity: /home/user/.ssh/id_rsa
debug1: Offering public key: /home/user/.ssh/id_dsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-dss blen 433
debug2: input_userauth_pk_ok:
debug3: sign_and_send_pubkey
debug1: read PEM private key done: type DSA
…………………..
I noticed that I had changed the perms on the users directory from
drwxr-xr-x 33 user user 2048 Aug 14 18:57 user
To
drwxrwxr-x 33 user user 2048 Aug 14 18:57 user
This meant that I lost access using public keys. The verbose output with this error is as follows.
………….
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/user/.ssh/identity
debug3: no such identity: /home/user/.ssh/identity
debug1: Trying private key: /home/user/.ssh/id_rsa
debug3: no such identity: /home/user/.ssh/id_rsa
debug1: Offering public key: /home/user/.ssh/id_dsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug2: we did not send a packet, disable method
debug3: authmethod_lookup keyboard-interactive
debug3: remaining preferred: password
debug3: authmethod_is_enabled keyboard-interactive
……………..
Removing group writable permissions from the users home directory solved the problem.
Subversion Notes
Notes to self about subversion.
To get the permssions right read the following.
RedBook
What follows is probably a butchers job.
#!/bin/sh
REPO=/usr/local/subversion
if [ -d $REPO ]; then
echo “Repository already exists”
exit 1;
fi
mkdir $REPO
chown svn:svn $REPO
chmod +s $REPO
chmod g+w $REPO
svnadmin create –fs-type fsfs $REPO
cd $REPO
chmod g+w db
chmod g+w db/transactions
chmod g+w db/write-lock
chmod g+w db/revs/
chmod g+w db/revs/*
chmod g+w db/revprops
chmod g+w db/revprops/*
Upgrading Woody to Sarge
Debian have just released sarge as the new stable distribution which means I need to start upgrading my machines. Before I upgraded the main machine though I decided to run through it on a UML machine first to see where the gotchas are.
Things to watch out for
1. The sshd config file gets an extra parameter added to it ie.
UsePAM yes
When I tested ssh after the upgrade I was unable to log into the machine and I found that I had to remove this option or set it to “no” to get ssh to work. This surprised me because I was not expecting Debian to modify config file without my knowledge.
2. The RECORD option is no longer valid
xinetd[5691]: Bad log_on_failure flag: RECORD [file=/etc/xinetd.conf] [line=13]
xinetd[5691]: A fatal error was encountered while parsing the default section. xinetd will exit.
xinetd[5691]: Exiting…
this prevents xinetd from starting up. This was also noticed while testing the machine after the upgrade.
What follows is roughly the files the upgrade offered to update to new versions. Since I had modified most of these I selected the default option which is “N” ie do not upgrade to the maintainers version. This may have been the reason the ssh upgrade wasn’t too smooth. However I would not recommend taking the maintainers version if you have customized the files.
Configuration file `/etc/pam.d/login’
Configuration file `/etc/securetty’
Configuration file `/etc/pam.d/passwd’
Configuration file `/etc/bash.bashrc’
Configuration file `/etc/init.d/sysklogd’
Configuration file `/etc/services’
Configuration file `/etc/init.d/bind9′
Configuration file `/etc/bind/named.conf’
Configuration file `/etc/bind/db.root’
Configuration file `/etc/init.d/xinetd’
Configuration file `/etc/xinetd.conf’
During the upgrade you may also be asked to add any users and groups that are
missing from the default debian lot. The following bits are just the output of some other configurations options and warnings of things that have changed between the woody and sarge.
Configuring ssh
Environment options on keys have been deprecated This version of OpenSSH
disables the environment option for public keys by default, in order to avoid
certain attacks (for example, LD_PRELOAD). If you are using this option in an
authorized_keys file, beware that the keys in question will no longer work
until the option is removed. To re-enable this option, set
“PermitUserEnvironment yes” in /etc/ssh/sshd_config after the upgrade is
complete, taking note of the warning in the sshd_config(5) manual page.
Configuring man-db
This version of man-db is incompatible with your existing database of manual
page descriptions, so that database needs to be x rebuilt. This may take some
time, depending on how many pages you have installed; it will happen in the
background, possibly slowing down the installation of other packages. If you do
not build the database now, it will be built the next time
/etc/cron.weekly/mandb runs, or you can do it yourself using ‘mandb -c’ as user
‘man’. In the meantime, the ‘whatis’ and ‘apropos’ commands will not be able to
display any output. Incompatible changes like this should happen rarely. Should
mandb build its database now?
So far I have upgraded two machines and had the same trouble with ssh and xinetd both times. If I encounter any mmore trouble I will add more here.