Recently in Linux Category


I recently had an issue where my keyboard when using synergy was inserting a double arrow instead of the usual greater than or less than sign also known as guillemotleft and guillemotright.

To fix this annoying bug I added

keycode 53 = x X greater greater greater greater
keycode 52 = z Z less less less less
keycode 24 = q Q at at at at

to a .Xmodmap in my home directory. If you are wondering how to find the keycodes etc you can use xev. To start it without restarting X use

xmodmap .Xmodmap
Add to delicious Digg This Add to My Yahoo! Add to Google Add to StumbleUpon
| | Comments (0) | TrackBacks (0)

I have no idea when or why this started happening for me but I started getting Unrouteable address appearing for any external address.

I'm a huge fan of Debian but there are some things that really piss me off. One is the way they have completely screwed the exim4 configuration. Exim4, if you are not an administrator or mail guru is not the simplest thing in the world to configure, it's config file is fairly involved and you can do anything in it. Add DEBCONF variables to this and you have a complete nightmare configuration.I spent two days tracking this error down to the following:

DCconfig_internet=1

That was all I had to add to /etc/exim4/exim4.conf.template

Why this changed I have no idea. The setting I am using in /etc/exim4/update-exim4.conf.conf is

dc_eximconfig_configtype='internet'

I really cannot make head nor tail out of this at all. I sometimes wish I had started learning Postfix instead of Exim but part of me thinks that it's not Exim but rather the way it has been packaged up thats compicated.
Add to delicious Digg This Add to My Yahoo! Add to Google Add to StumbleUpon
| | Comments (1) | TrackBacks (0)

If you get the above erro then check the following file

$ grep vo_driver $HOME/.mplayer/gui.conf
vo_driver = "xmga"

It should read:

vo_driver = "x11"

Add to delicious Digg This Add to My Yahoo! Add to Google Add to StumbleUpon
| | Comments (0) | TrackBacks (0)

I started getting the following error when trying to ssh into a chroot on a debian machine.

stdin: is not a tty

I fixed it using the following entry in /etc/fstab

devpts /dev/pts devpts mode=0620,gid=5 0 0

I'm positive this is not the way I should have fixed it but it works!
Add to delicious Digg This Add to My Yahoo! Add to Google Add to StumbleUpon
| | Comments (0) | TrackBacks (0)

The alternaitives system in Debian is a pain in the arse! It's one of those things that when you need to use it you spend twenty minutes trying to figure out why various paths etc have changed and then you need to figure out the syntax to change to the path that was working before you installed Tomcat or some other related system that downloads a bunch of stuff and sets itself up as default for the rest of the system. It's a tad irritating.

I am not saying I know a better way to do it but it still pisses me off. Anyway to use a sane version of java I had to run the following command to get eclipse working again.

$:~# update-alternatives --install /usr/bin/java java /usr/local/sdk-5_05/jdk 1
$:~# update-alternatives --list java
/usr/lib/jvm/java-gcj/jre/bin/java
/usr/local/sdk-5_05/jdk
$:~# update-alternatives --remove java /usr/lib/jvm/java-gcj/jre/bin/java

I now have eclipse working again and tomcat installed. I was going to use jetty6 over tomcat but because Debian comes bundled with a binary tomcat distribution I have decided  to use it. This decision may cost me dearly later.




Add to delicious Digg This Add to My Yahoo! Add to Google Add to StumbleUpon
| | Comments (0)

If you ever run the set command and get any of the function definitions listed at the bottom of this entry then check your .bashrc file for the following entry.

# enable programmable completion features (you don't need to enable
# this, if it's already enabled in /etc/bash.bashrc and /etc/profile
# sources /etc/bash.bashrc).
if [ -f /etc/bash_completion ]; then
    . /etc/bash_completion
fi

If it is not commented out then it is likely that name completion has been activated elsewhere. Comment it out and start a new shell to see if it helps.



_alias                         _lvresize
_apt_cache                     _lvs
_apt_get                       _lvscan
_aptitude                      _make
_args                          _man
_aspell                        _mkisofs
_aspell_dictionary             _modules
_available_interfaces          _mount
_bzip2                         _mplayer
_cancel                        _mplayer_options_list
_cardctl                       _nslookup
_cd                            _ntpdate
_cdrecord                      _ooexp_
_chgrp                         _openssl
_chown                         _openssl_sections
_chsh                          _perl
_command                       _perldoc.........etc

Add to delicious Digg This Add to My Yahoo! Add to Google Add to StumbleUpon
| | Comments (0) | TrackBacks (0)

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.

Add to delicious Digg This Add to My Yahoo! Add to Google Add to StumbleUpon
| | Comments (0)

I have never seen the oom-killer before. I had heard stories from battle hardened veterans about their tussles with the beast but these stories where all just myths to me, until today, when the beastie raised its head in my logs.

Dec 20 18:08:50 debian kernel: oom-killer: gfp_mask=0x1d2
59071 Dec 20 18:08:51 debian kernel: DMA per-cpu:
59072 Dec 20 18:08:51 debian kernel: cpu 0 hot: low 2, high 6, batch 1
59073 Dec 20 18:08:51 debian kernel: cpu 0 cold: low 0, high 2, batch 1
59074 Dec 20 18:08:51 debian kernel: Normal per-cpu:
59075 Dec 20 18:08:51 debian kernel: cpu 0 hot: low 32, high 96, batch 16
59076 Dec 20 18:08:51 debian kernel: cpu 0 cold: low 0, high 32, batch 16
59077 Dec 20 18:08:51 debian kernel: HighMem per-cpu:
59078 Dec 20 18:08:51 debian kernel: cpu 0 hot: low 14, high 42, batch 7
59079 Dec 20 18:08:51 debian kernel: cpu 0 cold: low 0, high 14, batch 7
59080 Dec 20 18:08:51 debian kernel:
59081 Dec 20 18:08:51 debian kernel: Free pages: 1040kB (112kB HighMem)
59082 Dec 20 18:08:51 debian kernel: Active:253987 inactive:249 dirty:0 writeback:5 unstable:0 free:260 slab:2326 mapped:254 013 pagetables:680
59083 Dec 20 18:08:52 debian kernel: DMA free:16kB min:16kB low:32kB high:48kB active:12296kB inactive:0kB present:16384kB
59084 Dec 20 18:08:52 debian kernel: protections[]: 0 0 0
59085 Dec 20 18:08:52 debian kernel: Normal free:912kB min:936kB low:1872kB high:2808kB active:873984kB inactive:996kB prese nt:901120kB
59086 Dec 20 18:08:52 debian kernel: protections[]: 0 0 0
59087 Dec 20 18:08:52 debian kernel: HighMem free:112kB min:128kB low:256kB high:384kB active:129668kB inactive:0kB present: 131008kB
59088 Dec 20 18:08:52 debian kernel: protections[]: 0 0 0
59089 Dec 20 18:08:52 debian kernel: DMA: 0*4kB 0*8kB 1*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096k B = 16kB
59090 Dec 20 18:08:52 debian kernel: Normal: 0*4kB 0*8kB 1*16kB 2*32kB 1*64kB 0*128kB 1*256kB 1*512kB 0*1024kB 0*2048kB 0*40 96kB = 912kB
59091 Dec 20 18:08:52 debian kernel: HighMem: 0*4kB 0*8kB 1*16kB 1*32kB 1*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4 096kB = 112kB
59092 Dec 20 18:08:52 debian kernel: Swap cache: add 848298, delete 845230, find 151472/187493, race 0+3
59093 Dec 20 18:08:52 debian kernel: Out of Memory: Killed process 6332 (postmaster).

It would appear I was being a bit greedy with Postgres.

Add to delicious Digg This Add to My Yahoo! Add to Google Add to StumbleUpon
| | Comments (0)

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

Add to delicious Digg This Add to My Yahoo! Add to Google Add to StumbleUpon
| | Comments (0)

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.

Add to delicious Digg This Add to My Yahoo! Add to Google Add to StumbleUpon
| | Comments (0)

About this Archive

This page is a archive of recent entries in the Linux category.

Life is the previous category.

Management is the next category.

Find recent content on the main index or look in the archives to find all content.

Powered by Movable Type 4.01