Weblogs for dkg
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:In particular, ubuntu's /etc/pam.d/gdm defaults to:
@include common-pammount
#%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-passwordWhen 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_startWith 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?
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.
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.
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.4But when i capture traffic with:
tcpdump -w /tmp/traffic.pcap -i eth0i 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.
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 #9booting 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 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?
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?
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 restartAlternately, 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!
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?
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.