So i've been struggling with an Ubuntu 8.04 networked workstation. It uses libpam-mount to mount the user's homedir (actually, the mountpoint is one level up from the homedir) automatically at login over CIFS.

One of the problems i ran into with this arrangement happened because i was following the pam_mount configuration instructions too literally. In particular, README.Debian.gz says:

For every application used for logging in, there is a file of the form /etc/pam.d/xyz, add the following line at the end of the file:
@include common-pammount

In particular, ubuntu's /etc/pam.d/gdm defaults to:

#%PAM-1.0                                                                                                                                                               
auth    requisite       pam_nologin.so
auth    required        pam_env.so readenv=1
auth    required        pam_env.so readenv=1 envfile=/etc/default/locale
@include common-auth
auth    optional        pam_gnome_keyring.so
@include common-account
session required        pam_limits.so
@include common-session
session optional        pam_gnome_keyring.so auto_start
@include common-password

When i added the @include common-pammount directive to the bottom of this file when using pam_mount, new GNOME sessions failed badly: the gnome-panel didn't appear (which means that the user couldn't log out conveniently), and two error messages popped up at each login with nasty details like:

No database available to save your configuration: Unable to store a value at [...], as the configuration server has no writable databases.

The problem seems to be that libpam-gnome-keyring actually kicks off gconfd-2 during its PAM session invocation. If that comes before libpam-mount's PAM session invocation, then the home directory isn't mounted for the keyring, and gconfd-2 decides that it is unable to save any settings. Since gconfd then persists for the rest of the session, further GNOME session components try to talk to it and it refuses, even though the gconf db is now available (via the mounted homedir).

Since the order of the lines in a /etc/pam.d/* are semantically relevant, i'm usually very reluctant to tamper with the defaults. However, i think the correct /etc/pam.d/gdm for this scenario (or any pam-mount scenario using GNOME where the homedir might not be present at all before the session) is actually:

#%PAM-1.0                                                                                                                                                               
auth    requisite       pam_nologin.so
auth    required        pam_env.so readenv=1
auth    required        pam_env.so readenv=1 envfile=/etc/default/locale
@include common-auth
@include common-account
session required        pam_limits.so
@include common-session
@include common-password
@include common-pammount
auth    optional        pam_gnome_keyring.so
session optional        pam_gnome_keyring.so auto_start

With this configuration in place, i can successfully log in with a test user, anyway (and move on to the next problem, which appears to be SQLite over CIFS, ugh).

These sorts of problems are tough to nail down:

• Is this overall problem due to a bug in the documentation for libpam-mount?
• In gdm for its default weirdly-ordered PAM config?
• In libpam-gnome-keyring for launching gconf-d-2 in the first place?
• In libgconf2-4 for gconfd-2 not being able to notice when the directories it wants become available?

Or maybe it's just a configuration detail that i should have known about and expected to deal with in the first place. Ah, well.

I finally got to try out goodbye-microsoft.com this past weekend. It uses similar principles as UNetbootin, which Utumno recently wrote about. I had a donated machine in a computer lab i volunteer at with a flakey CD-ROM which i couldn't get to netboot. Since it had Windows already on it, i booted to Windows, hooked into the network, downloaded a debian installer for Windows, ran it, and was on my way.

The project is clean, simply done, and provides a good interface in the leadup to rebooting into a debian installer. I highly recommend it for folks who need to switch a 'doze machine to the One True OS.

My one concern with this approach is if the debian install fails midway through, (and you haven't done any gymnastics to preserve a dual-boot scenario) you could be left with an unbootable machine. But the debian installer is pretty much rock solid these days, especially with common commodity hardware, so you'd probably have to trip over the power cord to get caught out like that.

There is a machine i have remote superuser access to which i know has some interesting info on one of the VTs (/dev/tty2 in particular in this case). I can try to scare up someone physically on-site to plug in a monitor, and painfully transcribe the text there by hand, but i'd prefer the simpler, politer (and less error-prone) option of getting the data digitally myself via ssh.

Any ideas how i could find the text that is already displayed on that VT? The machine is running a stripped-down debian etch, but i could add packages if i need to.

This entry has been truncated read the full entry.

I have the unfortunate circumstance of a xen machine with a single static, public IP address that needs to host multiple virtual servers internally. I don't want to bridge the main physical NIC to the virtual hosts, so i've created a bridge over a dummy NIC, and am trying to do iptables filtering with NAT to pass specific ports through to specific virtualized servers. I have one virtual server which should be granted full outbound 'net connectivity, masqueraded as though it is coming from the public IP address. But the source address in the packets from that virtual host aren't being rewritten.

The dom0, simian, runs a stock debian etch xen-linux-system. It has one public-facing ethernet interface, eth0. It has one dummy interface (dummy0, using the dummy.ko kernel module). simian:/etc/xen/xend-config.sxp contains:

(network-script 'network-bridge netdev=dummy0')

The Public IP address for simian is 1.2.3.4, but it has an IP address on dummy0 of 10.10.10.1/24. The domU in question has a virtual ethernet device bridged with dummy0 with IP address 10.10.10.2/24 (gateway 10.10.10.1). I want all outbound requests from the domU to pass (SNAT'ed) through the public IP address on eth0. To do this, i've enabled forwarding and set up SNAT on simian:

echo 1 > /proc/sys/net/ipv4/conf/dummy0/forwarding
echo 1 > /proc/sys/net/ipv4/conf/eth0/forwarding
iptables -t nat -A POSTROUTING -o eth0 -p tcp --src 10.10.10.2 -j SNAT --to 1.2.3.4

But when i capture traffic with:

tcpdump -w /tmp/traffic.pcap -i eth0

i see packets heading out on eth0 with a 10.10.10.2 source IP address. Needless to say, TCP sessions from these RFC-1918 reserved addresses never even get an ACK from a public internet server.

To verify, I just tried capturing packets seen by the next hop upstream (using the same kind of tcpdump, but on the next router down the line., and the captured packets indeed still have the 10.10.10.2 IP addresses in them, which means that outbound traffic from the domU will never be reciprocated.

So why isn't the SNAT rule triggering for these packets? What part of the netfilter documentation should i re-read with a closer eye to understand the situation? It seems buggy to me now, but i'm also aware that i've only skimmed the surface of what's possible.

I'm seeing more instances with hardware recently where the linux kernel gets an interrupt that it doesn't like or recognize, and it disables the IRQ entirely. Is there a way to get that IRQ re-enabled without restarting? My web searches haven't turned up anything fruitful.

To be clear, the error messages from the kernel look like this:

irq 9: nobody cared (try booting with the "irqpoll" option)
 [<c01402e3>] __report_bad_irq+0x2b/0x69
 [<c01404d0>] note_interrupt+0x1af/0x1e7
 [<c01d60b5>] acpi_irq+0xb/0x14
 [<c013fae7>] handle_IRQ_event+0x23/0x49
 [<c013fbc0>] __do_IRQ+0xb3/0xe8
 [<c01050e5>] do_IRQ+0x43/0x52
 [<c01036b6>] common_interrupt+0x1a/0x20
 [<c012182f>] __do_softirq+0x51/0xbb
 [<c01218cf>] do_softirq+0x36/0x3a
 [<c01050ea>] do_IRQ+0x48/0x52
 [<c01036b6>] common_interrupt+0x1a/0x20
 [<c0101a5a>] default_idle+0x0/0x59
 [<c0101a8b>] default_idle+0x31/0x59
 [<c0101b52>] cpu_idle+0x9f/0xb9
 [<c03176fd>] start_kernel+0x379/0x380
handlers:
[<c01d60aa>] (acpi_irq+0x0/0x14)
Disabling IRQ #9

booting with irqpoll has its own problems (on at least one machine i've tried that kernel parameter on, it resulted in unrecoverable lockups -- even ACPI signals didn't get through), so i'd rather not go there. But it would be nice to be able to get the IRQ back without a reboot, especially if it's shared across multiple devices.

Any suggestions?

I just noticed that one of the bodegas in my neighborhood sells "universal remotes" for a few USD. These are designed to work with arbitrary televisions, and can be switched/programmed to emit various IR signals. I've got an NSLU2 running sid, which feeds audio to my stereo using mpd. I'd like to use one of the cheap-o remotes to at least start/stop the audio and adjust the volume.

I suspect that the way to do that is with LIRC (as Utumno mentioned), but i'm not sure what kind of USB infrared devices will be compatible. The NSLU2 only has USB ports -- no RS-232 or anything else. Anyone with more experience in this area care to suggest a USB IR receiver that works well with a TV remote?

Does anyone have pointers for how to ask a modern debian system to prioritize certain interrupts (IRQs) ahead of others?

irqtune is the historical option, but it hasn't been updated for 10 years, and looks like a serious mess in debian at the moment (it's not in etch or lenny, orphaned, and has many serious bugs open).

Any thoughts or suggestions for what might be a better way to prioritize interrupts on a modern system?

The recently announced patch for openssl does a good thing: it looks for services known to use libssl and offers to restart them for you.

However, it doesn't seem to notice apache2, which relies heavily on libssl when mod_ssl is enabled. You can check to see what services still use the old libraries (as discussed earlier in my weblog here). If you see apache2 among that list, you should almost certainly do:

/etc/init.d/apache2 restart

Alternately, if you already know that you're using mod_ssl, you'll have an opportunity to add apache2 to the list of services to be restarted during the upgrade of libssl.

Many thanks to the debian security team for publishing this fix and making it so straightforward to restart most of the affected services. Your work is much appreciated!

Does anyone use the backup user for doing local system backups? or do you create a new user specifically for that?

I ask because backup is debian-specific uid 34, provided by the base-passwd package. But reading /usr/share/doc/base-passwd/users-and-groups.txt.gz, i find only this:

backup

    Presumably so backup/restore responsibilities can be locally delegated to
    someone without full root permissions?

    HELP: Is that right? Amanda reportedly uses this, details?

So fellow admins: do you use debian-allocated accounts (i.e., with uid < 100) (other than root) for any local (non-distro) purpose? If so, when do you do so? if not, why not?

It looks like debian etch just received its first point release, updating many useful packages with little nagging details that didn't make it into the first release.

Aside from the security fixes, one update i'm particularly happy to see is the fix of the libneon26 kerberos/GSSAPI authentication mechanism, which caused me a lot of pain.

What's your favorite update in the batch here? what update do you think is highest priority for the next point release?

As always, thanks to everyone who does this work.