Is fairly straight forward.
You will need to be able to use the following commands with some confidence
ldd
strace
rsync
cp
Tips. When copying files make sure your umask is set to 022 and alias cp as follows:
alias cp=”cp -p”
If you are copying over any perl XS files ie *.so files make sure you also use ldd on these. As an example the PostgreSQL drivers require:
ldd usr/lib/perl5/auto/DBD/Pg/Pg.so
libpq.so.3 => /usr/lib/libpq.so.3 (0xb7fbf000)
libc.so.6 => /lib/tls/libc.so.6 (0xb7e89000)
libssl.so.0.9.7 => /usr/lib/i686/cmov/libssl.so.0.9.7 (0xb7e58000)
libcrypto.so.0.9.7 => /usr/lib/i686/cmov/libcrypto.so.0.9.7 (0xb7d59000)
libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0xb7cf1000)
libcrypt.so.1 => /lib/tls/libcrypt.so.1 (0xb7cc4000)
libresolv.so.2 => /lib/tls/libresolv.so.2 (0xb7cb2000)
libnsl.so.1 => /lib/tls/libnsl.so.1 (0xb7c9d000)
libpthread.so.0 => /lib/tls/libpthread.so.0 (0xb7c8e000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
libdl.so.2 => /lib/tls/libdl.so.2 (0xb7c8b000)
libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0xb7c68000)
libcom_err.so.2 => /lib/libcom_err.so.2 (0xb7c65000)
A quick way to find your shared object files is as follows.
find /chroot_directory_name/usr/ | grep perl | grep “.*\.so$”
You will already have copied most of the shared object files over while copying squid and apache but there are most likely a few extra ones you are going to need in particular if you are using the DBI.
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
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.
Kernel 2.6.5 and 2.6.9 fun
I upgraded from kernel 2.6.5 to kernel 2.6.9 because I was getting DMA errors when ripping CD’s to disc. I was also getting major errors with the SATA disk when copying the CD’s to my mp3 player so I have bit the bullet and decided to try and upgrade.
During boot I came across what I thought was some king of bug. When I rebooted the kernel fsck complained about a bad file system, no indication as to which device just the error message.
I logged back in and my SATA disk was gone. It had not been mounted during boot which was a bit of a bummer. I had a look at the dmesg output and lo and behold it is now a SCSI device and my three old mount points are now invalid. I am using the VIA controller ie
CONFIG_SCSI_SATA_VIA=y
in my config. I find these changes very disconcerting but then I am not a kernel hacker. I wonder if there is an easy way to see changes like this without having to read through tons of Change logs. Its even worse when you are jumping several versions.
Kernel upgrades, like life are is just full of little surprises.
Compiling a single module for the 2.6 Kernel
This is relatively straight forward. I just recently installed a new network card to play around with and to see if I can make head or tail of the driver details so I need to make sure I have the driver for the card.
I installed a NetGear F311, I had a couple of spares. The driver for this card is the natsemi driver. To see if you have the source try the following.
]$ locate natsemi
/usr/src/kernel-source-2.6.5/drivers/net/natsemi.c
/usr/src/kernel-source-2.6.5/include/config/natsemi.h
There is no need to be the root user for any of this until you need to actually install the driver, I will tell you when 😉
Copy both these files to a directory of your choice. Then, in the same directory create a Makefile with the following text:
1 obj-m := natsemi.o
2
3 KDIR := /lib/modules/$(shell uname -r)/build
4 PWD := $(shell pwd)
5
6 default:
7 $(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules
save it and then execute the folloing command:
]$ make
Some text should whizz past detailing what it is doing. In the directory which you ran make in there should now be several new files
natsemi.ko
natsemi.mod.c
natsemi.mod.o
natsemi.o
The one you are interested in is “natsemi.ko”. As the root user change to the directory containing the “natsemi.ko” file and run
]$ insmod natsemi.ko
If all goes well there should be no messages. To see if it loaded and to satisfy your curiosity try
]$ lsmod
natsemi 18976 0
tulip 36640 0
crc32 3840 2 natsemi,tulip
af_packet 12552 4
The above is what I have on mine
To see if the card works (Debian) edit your
/etc/network/interfaces
file and add the following. Note that I already have a card installed using eth0 so I have chosen eth1 for this card
11 iface eth1 inet static
12 address 192.168.1.10
13 netmask 255.255.255.0
Then issue the command
]$ ifup eth1
]$ ping 192.168.1.10
and you should now have the card working.
Writing Linux Device Drivers
I lost my internet connection at the weekend and was at a bit of a loss as to what I could do so I decided to take a pop at writing a simple module for the Linux kernel. I have a copy of
Beginning Linux Programming
ISBN: 1861002971
Authors: Richard Stevens and Neil Matthew
Ed: 2nd
so I turned to the back of it and started my foray into the Kernel. Now you need to remember that I am not a C programmer by trade and turning to the back of this book was a keen reminder of just how rusty my C is getting, not that it was ever rust free.
Luckily for me I have another book that is considered the C bible ie K&R and it deserves its reputation, it is a classic and I would recommend any programmer regardless of language choice to have a flick through it. When I was looking at some odd construct that those pointy hats had invented I had a flick through K&R and soon sorted it out.
Anyway back to the kernel. I was quick to discover that writing a module for the 2.6 kernel is not quite as straight forward as copying from the book and trying to understand what was going on. Things have been changing and I was getting all sorts of weird (or at least to me) and wonderful errors when trying to compile the kernel.
I eventually started to have a read at the recent modules in the source for 2.6.5 which I am running on this box. I also have the source for a 2.4 kernel on here so I opened 2 character drivers and compared notes between them. This is where I started to notice things that had changed. I made the changes I thought where necessary and I managed to get most of the “Hello World” module compiling but I was still getting errors.
I had a hunt around and I found a reference to some new build procedures for 2.6.5 so off I went in search of kbuild documentation and found some more stuff that had changed in the kernel. Namely the build procedure. This part was actually harder than the C that I had been struggling with.
After much swearing (I hate Makefiles and adding some more sugar is a pain in the ass) I managed to get the module compiling and I was on my way.
After a days work I now had a module that, on load would say
“Hello World”
and on removal
“Goodbye World”
time well spent or not? I haven’t decided yet. I wonder how often changes like this take place in the kernel and how much porting takes place because of it.
Where to go from here. I asked a few friends who know more about this stuff than I do and I got mixed advice about continuing. Some of them think the kernel is a mess because they are always changing the driver API among other things. I cannot comment because my knowledge of the Linux kernel is limited to spelling it and I sometimes get that wrong.
I did get some useful pointers though. The following is the best book I have found so far for someone like me who is just starting out in the kernel.
Linux Device Drivers, 2nd Edition
It is written for the 2.4 kernel but has a wealth of information that is still valid today. I have started porting the scull drivers from this to the 2.6 kernel I am running and it is proving very interesting. I printed off chapter 2 and 3 yesterday and have have almost finished them (40 mins from Luton to London on the train each way helps). So far it seems to be moving along at a fair old pace, I am just hoping I can keep up.
I could have done with the following at the weekend. This tells me what I needed to know about moving from 2.4 to 2.6. I can see myself using this a lot in the next few weeks.
Driver Porting
Multiple users and X-Windows
I wanted to open an application today as the Postgres user while logged in as my normal user account. I know that dropping access control to the xserver can be a bit of a security risk but I also don’t like flicking between users to achieve a task. I don’t mind opening an xterm but logging in and out of xwindows is not much fun.
Anyway to get an application working using the insecure method we can do the following. User A is the main user and you want user B to be able to open an app in users A’s session.
A@machine:~$ xhost +
A@machine:~$ su – B
password *********
B@machine:~$ export DISPLAY=:0.0
B@machine:~$ /path/to/application/
This was easy but I don’t like using
A@machine:~$ xhost +
and allowing everyone access. This is not smart so I decided to see if there is a more secure method that avoids this. Having a read of the xhost manual I found out that I could limit access on a per host or per user basis as follows
A@machine:~$ xhost +B@
which gives me a lovely error message as seen below. I have tried various different methods but I get the same error message.
B@ being added to access control list
X Error of failed request: BadValue (integer parameter out of range for operation)
Major opcode of failed request: 109 (X_ChangeHosts)
Value in failed request: 0xfe
Serial number of failed request: 7
Current serial number in output stream: 9
so it would appear to me that there is something amiss somewhere. I googled for quite a while to see if I could find a definitive answer. No joy, they all recommended using xhost + which is not what I want to do.
Simple things like this can be such a bloody chore under Linux. I know, I know stop bitching and start patching.
Anyway. I can remember doing something similar to what I want with ssh so I had a look at the man page and found the following snippet
-X Enables X11 forwarding. This can also be specified on a per-host
basis in a configuration file.
X11 forwarding should be enabled with caution. Users with the
ability to bypass file permissions on the remote host (for the
user’s X authorization database) can access the local X11 display
through the forwarded connection. An attacker may then be able
to perform activities such as keystroke monitoring.
This meant that I could do the following.
A@machine
A@machine:~$ ssh -X B@machine
password ********
B@machine:~$ /path/to/application
and I get the window displayed. Remember that you need to edit the
/etc/ssh/sshd_config
files and set X11forwarding to yes. This is more secure than using xhost + but still not ideal but good enough for what I want it for.
Linux Developer Gets Laid
I know this has probably done the rounds but this did make me giggle
Some developers are also excited that this may increase their chances of getting lucky, but most are being realistic. Walker Crandall said, “We thought we’d all be doing the hokey-pokey after Bill Fitzsimmons got some during the LinuxWorld Conference in 1999. We were fooling ourselves. Nobody got nothing.”
This is the third such occurrence for Linux developers since 1991.
Sans Serif or not to Sans Serif
I am pretty damned sure that fonts are one of the most used yet least appreciated aspects of computing I have come across.
It would be fine to interject here and say NO, surely its “blah de blah”. I say no…… People in general don’t give a damn about how machines work / talk / do their stuff, however they are concerned with how stuff looks.
For instance, look at the fashion industry. Clothes are expensive but the workmanship is generally crap but who cares, its a “scurgly! made by whatsisname”, and it looks good.
Its the same with computers, look at the Mac, previously thought the underdog, now its almost a fashion statement to own one.
Anyway, back to fonts. I am not really that bothered about what fonts are on my machine as long as I can read the text without squinting to much, but just the other day it was noted that I was using “Sans Serif” fonts and I was lacking in “Serif” fonts.
Well… I just shit my pants, what the hell was I missing. Apparently I wasn’t missing anything. Sans Serif add an extra bit to your fonts and I was missing the option of not missing them on everything I read.
To cut a long story short I needed to get some Microsoft fonts installed on my Debian box and this is the process.
First thing I needed was the Microsoft truetype fonts. ON debian these are called
msttcorefonts
and can be installed via “aptitude” or apt whichever you prefer. I fetched these and this installed a whole pile of stuff in
/usr/share/fonts/truetype/
Next thing I needed to do is create a “fonts.scale” file as ROOT
]$ cd /usr/share/fonts/truetype ; ttmkfdir;
sorted. The directory should now have the correct file. The next thing to do is restart either, the font server, or X11. I just logged in and out and that was it. New fancy fonts that are almost identical to the ones I had previously or at least in first inspection they are.
Remapping Keys in Linux
I never really had to do this before but I have been using enlightenment for a few months now and use the ALT-(q,w,e,a,s,d,z,x,c) to switch between 9 separate desktops. I find this quite quick but I tried xemacs the other day and I needed ALT-x but I kept switching between desktops. So I decided to use a different key.
Since the Windows key ie the one to the left of the left ALT button is never used I decided to use it to switch desktops instead (I know I will need to use the ALT key in other applications so I might as well do it now before its ingrained into me).
Anyway the procedure goes as follows.
1. Detect the keycode of the key you want changed.
Open a terminal and type
]$ xev
Lots of text should whizz past on the terminal and then stop. Touch the key you want the keycode of and more text should whizz past…. something like
KeyRelease event, serial 25, synthetic NO, window 0xe00001,
root 0x38, subw 0x0, time 24436498, (-298,301), root:(458,320),
state 0x0, keycode 115 (keysym 0x0, NoSymbol), same_screen YES,
XLookupString gives 0 bytes: “”
We can see that the keycode is 115.
2. Create a user modmap file to be loaded on starting X
]$ cd ~; touch .Xmodmap
and put the following text in it
keycode 115 = Hyper_L
add mod3 = Hyper_L
then edit your ~/.xsession file: Add
xmodmap .Xmodmap
before the “exec enlightenment” line and that should be you sorted. If for some reason you did not have a .xsession file then you will need to add the line to start whatever window manager you are using ie in my case my .xsession looks like
xmodmap .Xmodmap &
exec enlightenment
yours might well be
xmodmap .Xmodmap &
exec sawfish
You should now be able to use the MOD3 modifying key in e16keyedit as a modifier key after restarting xwindows.