Recently in Linux Category
# 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
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.
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.
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.
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.
I got a series of kernel oops when using SATA on an MSI K8T Neo motherboard. I have written a short article on what I did to get it working. Luckily for me it turned out to be a solvable problem or at least it hasn't oopsed on me since.
