Groesbeek, view of the 'National Liberation Museum 1944-1945' in Groesbeek. © Ton Kersten tonkersten.com | Tue Aug 17, 2010 | © Ton Kersten - PA1TON
Most of this template stuff is borrowed ("stolen") from Miek Gieben
stopsoftwarepatents.eu petition banner

October 2008 Archives - Thoughts of a geek

October 2008 Archives

How I broke the triple-e and repaired it

Ton Kersten / 2008-10-19 12:41:56 CEST / Permanent link

Last weekend I decided it was time again to completely update my eeePC. So I ran the command tantrum everybody knows:

apt-get update
apt-get upgrade

and that gave me 287 new and updated packages.

After that I needed to reboot because I got a lot of new stuff.

Well, there the trouble began. No X, no network, no mouse, no USB etc. It was in a terrible state.

Digging around and repairing the odd stuff, I got X running, but still no mouse and no network. I thought that there had to be a general problem, because it looked impossible that everything was broken without some major hickup. Digging further and further I suddenly noticed that I did have a lot of files with the name ending in dpkg-new. That gave me the clou that these where new configs and new scripts that didn't update the original ones. why wasn't clear, first get the thing up and running again.

Now it was time for drastic actions. I found that all this weirdness was in the /etc directory so I created a small script to correct it. If it did work I would have a running eeePC again. If it didn't I would be in it very deep.

Here's the script:

cd /etc
for f in $(find . -type f -name \*.dpkg-new)
do
    a=$(echo $f | sed 's/\.dpkg-new$//')
    mv $a $a.NOT
    mv $a.dpkg-new $a
done

After running this everything worked again, like out of the box.

Now I only need to find out why the upgrade went sour. This blog will be updated as soon as I know.



Portforwarding without IPtables

Ton Kersten / 2008-10-14 19:50:53 CEST / Permanent link

Live's good and the problem is simple. Having a Linux server at home with two virtual machines running within VMware server, I would like to have a tunnel to the host OS and forward ports for smtp, imap, rdp and maybe some others.

I thought this could simply be solved with IPtables, but that turned out to be a big pain in the *ss. It didn't work as I wanted, I locked myself out several times and still it didn't do exactly as I wanted.

Telling a coworker of mine (Thanks Jacco) he stumbled on a simple tool, called rinetd. It can only do one thing, but does that very well. It can forward an incoming TCP port request to another machine on any port. The configuration is so simple, anybody can understand it, even I did.

My config looks like:

logfile /var/log/rinetd.log
logcommon
0.0.0.0   25 192.168.63.8   25
0.0.0.0   83 192.168.63.8   83
0.0.0.0  143 192.168.63.8  143
0.0.0.0 3389 192.168.63.2 3389

Start the daemon with this config file and everything works. Could not be easier.

To bad nobody maintains this, my version is dated 2003-04-13. Maybe I will, when time permits.

Take a look at the rinetd homepage and be amazed.



MDNS name resolving problem

Ton Kersten / 2008-10-14 19:37:53 CEST / Permanent link

Within a mixed Linux and Microsoft Windows network I ran into the following problem:

A host with the hostname linux1.firm.local could be pinged and found with nslookup and dig, but it was impossible to start a ssh session. The result kept being: Unknown host.

Playing Cherlock Holmes revealed that this had to do with Avahi and mdns, so with the .local part of the hostname.

In my /etc/nsswitch.conf the hosts: line read: (Using Ubuntu 8.04)

hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4

This results in searching the IP address of the host through mdns4_minimal. The .local domain now spoils it for me (use strings on mdns4_minimal and be amazed.

The problem can be solved very easy. Just replace the hosts: line in the /etc/nsswitch.conf with:

hosts: files dns mdns4

See also: Avahi