Recently in Debian Category
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.
I always get this error when I am working i a chroot trying to use screen. In the past I have fixed it using the following command.
mount -t devpts devpts /usr/CHROOT/dev/ptsWhen this fails another alternative is the following:
script /dev/null screenIts a bit of a hack but it gets the job done.
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!
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.
I got a new Dell Vostro 400 this week and have been trying to get Debian Etch stable on it. This has proved a bit of a pain.
The following facts might help.
- Dell are using a new Intel Ethernet Controller
- They are also using a modern SATA controller
- The stock Debian netinst cd does not have the correct drivers for these.
Thanks to Kenshi Muto I was able to get Debian installed but this is where it all went bad.
My next job was to get Gnome running on the machine. I have a Nvidia card installed so I went to the Nvidia Unix Driver Page and got the latest driver. I tried to install this but it is incompatible with the rivafb and nvidifb modules so if I stick with Kenshi's kernel I cannot have a desktop but if I install a new kernel I cannot have networking.
At this point you are probably hoping there is some smart fix for this problem. Unfortunately I didn't find one. I ended up installing a separate network card to get the system running. I would imagine in the near future that the Linux Kernel will have support for E1000E and when it does I will recompile the kernel.
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.
