Hands up who sees what the problem is with:Which obviously means "hey, you've done something stupid, and someone may be maliciously attempting to log in, when they shouldn't be able to, so for your sake I'm going to completely ignore the file".

The real question, of course, is why was the file in my configtool cache given the wrong permissions to start with?  I blame one of the various 2.6.26+xen-related crashes.

Returning things to normal (by nuking /var/lib/configtool/* and re-syncing) seems to have fixed the problem, allowing me to log in as root once again.

Memo to self for the future:On the other hand, I had 1.82TB in my crazy array for a while...

Growing xfs filesystems is easy - just remember to have the filesystem mounted:
xfs_grow /dev/vg0/data

I was all happy with my nice virtualbox networking setup:

VM1 (172.16.0.131)-+--|br0(172.16.0.129) eth0(172.16.3.130)|--gateway--<NAT>--world
VM2 (172.16.0.132)-+  +----------------host----------------+
VM3 (172.16.0.133)-+

It was all shiny, I could connect to my VMs from within my internal network, but they were on a separate subnet to my host, so I could be more restrictive.

Then, they changed it (ok, I did upgrade to the version in Debian experimental, but I thought it would fix my Windows 7 issue (it didn't - my problem was it not wanting to install drivers for the network card. Turns out you need to tell it to install virtualbox additions, then ignore the setup program (it fails), and instead open up hardware properties, then tell it to find the driver somewhere on the CD (in drivers, IIRC)). And broke my nice host interface networking on br0 - suddenly no traffic was being passed. Well, actually, suddenly it was complaining that:

Assertion failed: [!name.isNull()] at '/build/buildd/virtualbox-ose-2.1.0-dfsg/src/VBox/Main/NetworkAdapterImpl.cpp' (1068) in nsresult NetworkAdapter::loadSettings(const settings::Key&). Please contact the product vendor!.

 

Result Code:	NS_ERROR_FAILURE (0x80004005)
Component:	NetworkAdapter
Interface:	INetworkAdapter {a876d9b1-68d9-43b1-9c68-ddea0a473663}

This can be fixed by going to your virtual machines directory (in my case, /mnt/vmachines/VirtualBox), and then going into the Machines subdir, and finding the directory for the relevant VM. In there, you'll find an XML file. The offending lines in said file, at least in my case, were:

<HostInterface TAPSetup="sudo /home/michael/bin/vbox_bridge_setup up" TAPTerminate="sudo /home/michael/bin/vbox_bridge_setup down"/>

located within <Adapter></Adapter> elements. Deleting all the HostInterface elements fixed it (NB: if you have snapshots, you'll also have the HostInterface lines repeated later in the file - be sure to get them all, as it's something that bit me)

Now, back to the networking issue. The current solution I've found is to create a single tap device, and then set up every host to use it, using Host Interface networking.
Being lazy, I can't be bothered to bring up my tap interface every time I want to use my VMs - I want it started at boot, and ready to go. Editing /etc/network/interfaces does the right thing in this respect (note that my user has uid 1000):

# Interface vbox0
auto vbox0

iface vbox0 inet static
    address   172.16.2.193
    netmask   255.255.255.192
    post-down   tunctl -d vbox0
    pre-up   tunctl -t vbox0 -u 1000
    
iface vbox0 inet6 static
    address   2a01:348:15c:c001::1
    netmask   64

Yes, I know that pre-up would normally go before post-down, blame it on my configuration management software (which, incidentally, is fantastic. I'm using rb3, which has various flaws (some of the things I do in templates would make you cry), but makes managing, erm, 20 systems bearable).
I also took the opportunity to move to the 172.16.2.192/26 subnet (I'm trying to keep everything in 172.16.2 and 172.16.3 - and with configuration management, it's not actually too hard to implement).

Then, with the appropriate firewall magic, it all Just Works:

IF_REAL="eth1"
IF_VIRT="vbox0"
NET_VIRT="172.16.2.192/26"
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -m state --state NEW -i $IF_REAL -o $IF_VIRT -d $NET_VIRT -j ACCEPT
iptables -A FORWARD -m state --state NEW -i $IF_VIRT -o $IF_REAL -s $NET_VIRT -j ACCEPT
echo 1 > /proc/sys/net/ipv4/ip_forward

(obviously, to be used as part of a larger firewall)

This gives me:

VM 1 (172.16.2.195)--+--|vbox0 (172.16.2.193) eth0(172.16.3.129)|--gateway--<NAT>--world
VM 2 (172.16.2.196)--+  +--------------host---------------------+
VM 3 (172.16.2.197)--+

Hrm, I seem to be doing far too much stuff with virtualization at the moment - xen, virtualbox and vmware at work...

VMware do seem to be moving towards a whole "woo look at my management console" thing.
Turns out (despite my misgivings) that it's quite possible to do USB passthrough of mass storage devices to your guest OS - so, for example, running XP in a VM, you plug in your Stick O' USB, and have XP use it rather than your Debian Etch host machine.  This assumes you're running Server 2.x, and so have Webby Goodness.
Turns out that this is a really simple trick.
Step 1: Ensure that you're in the plugdev group (46).
Step 2: Modify the permissions with which /proc/bus/usb is mounted:Yep, that's right kids, on Etch /proc/bus/usb is no longer mounted by /etc/fstab.  So don't bother putting your entries there, it won't work.
Step 3: Reboot
Step 4: Profit (yeah, I know this should be step 3).

If it doesn't work - you do have a USB controller installed on your VM, don't you?

My normal approach is useless here.

My laptop contains an ATI Radeon chip.  Yes, I know that this is Bad for Linux-compatability - I was young and inexperienced when I got it.  Said laptop also runs Debian testing/unstable (/experimental), and used the xserver-xorg-video-radeon driver.

Now, kernel versions > 2.6.22 have been causing it to freeze completely when starting X - no network response, no nothing (with a lack of serial port, the trick is to boot into rescue mode, start ssh, ssh in, then continue to boot while tailing logs).  This is Less Than Ideal, especially given the number of security holes that have been discovered that apply to my 2.6.22 install.

So, last night, I decided to see what the fglrx driver was up to these days.  Last time I tried it, it had a nice tendency to hang the machine if I did, erm, pretty much anything, especially switching away from VT7.  Imagine my surprise when, having installed the appropriate packages (apt-cache search fglrx IYF) and prodded xorg.conf, it Just Worked™ - well, apart from the fact that mouse and keyboard input didn't seem to be happening...  Turns out that the xserver-xorg-input-kbd, xserver-xorg-input-mouse (and in my case xserver-xorg-input-synaptics) are kinda useful.  So, a quick switch to VT1, install, restart gdm, and switch back (look Ma, no hanging!), and I have working X.  Hooray!

If only the random router/firewall issues at work would sort themselves out as simply...

I may also be missing the most fabulous Jude in the world, and so have to keep busy somehow...

I guess it's just fussy to want not-too-hot and not-too-wet - at least it's not flooding.

Also, while the following works for cable modems:



You are strongly advised not to do so to your custom firewall (appropriate for Enterprise, apparently), unless you feel like digging out an old machine, a handy Debian install disk, network cards and your iptables knowledge and missing lunch...
On the other hand it might solve an issue where new VMware ESX machines (and, in fact, new physical machines) are added to the network and can't talk outside the local subnet.  Had we not cannibalized our Virtual Centre machine to get a network card for the firewall, I'd test it...

(also, I miss compressedchaos :()

Still, it's Saturday, and I have internet again \o/  (Oh, and hello Planet OxIRC, which I may actually be on now - that has probably about tripled the readership of this...).

If you don't know or care about IPv6, you probably want to

Warning: this post may contain rants about computers.

LDAP is, in principle, a very shiny thing. Single database of all your users, contacts, etc, meaning you don't have to hack stuff to keep passwd files, etc in sync.

However, there are a few pitfalls.

#1: make sure your database is indexed

I added some more 'index eq' entries to my slapd.conf, including 'index uid eq' and 'index cn eq'. This should help improve search speed (I think), but has a minor drawback - after restarting slapd, it seemed not to like me.

 m@z ~ % ldapsearch -x uid=michael uid
 m@z ~ % 

Yep, that's right, it returned absolutely nothing.
Turns out that you need to stop slapd and run slapdindex (tip: it'll probably screw up all the permissions so go chown openldap:openldap /var/lib/ldap/*). Restarting it then gives joy!

 m@z ~ % ldapsearch -x -LLL uid=michael uid
 dn: uid=michael,ou=users,dc=michaelh,dc=hopto,dc=org
 uid: michael

 m@z ~ %

#2: SSL/TLS issues

The Debian slapd package has switched from OpenSSL to GNUTLS (although in what can really only be described as epic failure, some of the stable packages are linked against one, while some are linked against the other - bug 457182). That's something of an aside, though - I don't know if it's causing the current issues or not (I know that it has been causing CompSoc some problems, but someone else will be taking that over soon).

Anyway, the current issue requires a little background. There are two machines - call them a and z. Now, a is running slapd, which listens on localhost:389 (ldap) and localnetworkip:636 (ldaps). Both machines are set to use LDAP for user lookups, etc. They have the same versions of libnss-ldapd, libpam-ldap, ldapscripts, libldap2, libldap-2.4-2. /etc/ldap/ldap.conf on z has:

URI ldaps://a/

and on a:

URI ldaps://a/ ldap://localhost/

Now, here's the fun bit. ldaps connections from z work:

 m@z ~ % ldapsearch -x -H ldaps://a/ uid=michael -LLL uid
 dn: uid=michael,ou=users,dc=michaelh,dc=hopto,dc=org
 uid: michael

 m@z ~ %

However, on a they don't:

 m@a(172.16.1.15) ~ % ldapsearch -x -H ldaps://a/ uid=michael -LLL uid
 ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
 m@a(172.16.1.15) ~ %

In the log (running slapd with -d 768), I see:

conn=20 fd=26 ACCEPT from IP=172.16.1.1:49298 (IP=172.16.1.1:636)
conn=20 fd=26 TLS established tls_ssf=16 ssf=16
conn=20 fd=26 closed (connection lost)

In fact, it appears that I was missing a key directive:

tls_cacert /etc/ssl/certs/MichaelSecurePlaces.pem

Having just added it to /etc/nss-ldapd.conf, I get a slightly worrying message:

 % sudo invoke-rc.d nslcd restart
Restarting nss-ldapd connection daemon: nslcdnslcd: /etc/nss-ldapd.conf:25: option tls_cacertfile is currently untested (please report any successes)

However, for now it seems to work...


Note: this is all running on a Debian lenny/sid system.
This is what happens when compressedchaos goes away for a week, and I start my holidays early.

If you're not Linux-based, I shall point out that my housemate is an extremely good cook. His Christmas dinners are quite amazing.

( If you are a Linux person, on the other hand, the following might be of use to you ).