Raphaël Hertzog's questions

The LDAP uses the posixAccount schema and related attributes and I wonder if there's a standardized way to disable an account. Re-enabling the account should obviously re-enable the former password.

I know that passwd --lock adds an exclamation mark in front of the encrypted password in /etc/passwd. Does the same convention work with the userPasswd field of an LDAP entry?

Update: I know PAM/NSS underneath, my question was specifically targetted at the LDAP server. Once the account is locked I want the user to not be able to open an authenticated connection to the LDAP server itself (with his own credentials). That's because several services use a successful authenticated connection to LDAP as simple authentication mechanism without using PAM for this task (this is common with web interfaces).

The network configuration in my Xen setup is the following:

• the dom0 has 3 network cards (eth0, eth1, eth2), 3 brigdes (xenbrE, xenbrI, xenbrD) and each brigde integrates the corresponding network card. Only xenbrD has an IP address configured (192.168.78.2, a private LAN) so that it can discuss with all domU.
• there's a domU that is a firewall/router and it also contains 3 virtual cards (eth0, eth1, eth2). It does masquerading for traffic going out on eth0 (the external interface which is part of xenbrE).

My problem is that when I download a big file from the internet by HTTP in the dom0, the download rate is not stable. It goes up progressively and then stalls for a few seconds, and restart again going up progressively (and all this in loop until the download is complete). During the stalls, it looks all networking is blocked on the machine (noticed on interactive SSH sessions).

dom0                             │domU
     wget                        │
       ↕                         │
eth2↔xenbrD(192.168.78.2)↔vif2.2←┼→eth2(192.168.78.1/24)
                                 │   ↕ masquerading
eth0↔xenbrE↔vif2.0←——————————————┼→eth0(192.168.1.20/24)
 ↕
internet

If I do the same download but uses a (non-caching) HTTP proxy that runs in the firewall domU, the download rate is stable at its maximum value.

How can I avoid this problem?

I suspect it's a bug in the networking stack but I would like assistance to diagnose it more precisely (and maybe find a work-around).

This is a Debian Etch system with Xen 3.2 and the 2.6.26-xen-686 kernel of Debian Lenny (backports). The bridges are created with /etc/network/interfaces:

auto lo
iface lo inet loopback

auto xenbrE
iface xenbrE inet manual
        bridge_ports eth0
        bridge_maxwait 0

auto xenbrI
iface xenbrI inet manual
        bridge_ports eth1
        bridge_maxwait 0

auto xenbrD
iface xenbrD inet static
        address 192.168.78.2
        netmask 255.255.255.0
        gateway 192.168.78.1
        bridge_ports eth2
        bridge_maxwait 0

The xend configuration is not complicated:

# grep '^(' /etc/xen/xend-config.sxp
(network-script network-dummy)
(vif-script vif-bridge)
(dom0-min-mem 150)
(dom0-cpus 0)
(vncpasswd '')

The Xen network setup of the domU is done with:

# grep vif /etc/xen/xm.slis
vif = [ 'mac=00:16:3e:14:85:11, bridge=xenbrE', 'mac=00:16:3e:14:85:12, bridge=xenbrI', 'mac=00:16:3e:14:85:13, bridge=xenbrD' ]

And the only routing in dom0 redirects to the domU via xenbrD:

# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.78.0    0.0.0.0         255.255.255.0   U     0      0        0 xenbrD
0.0.0.0         192.168.78.1    0.0.0.0         UG    0      0        0 xenbrD

In the domU, the only iptables configuration done is iptables -t nat -A POSTROUTING -s 192.168.78.0/24 -o eth0 -j MASQUERADE.

The broadcast address is apparently misconfigured on some (old) Linux embedded device that I setup (but that I don't own anymore) because it doesn't match the expected value given the IP address and the netmask (for example, it has a broadcast of 192.168.70.255 instead of 192.168.71.255 for 192.168.70.243/255.255.254.0). It runs a kernel 2.4.31 with busybox 0.60.5. The network configuration is simply done with that shell snippet:

ifconfig eth0 $IPADDR netmask $NETMASK
if [ -n "$GATEWAY" ]; then
    route add default gw $GATEWAY
fi

Thus the broadcast address is not explicitely configured. The question is: what is responsible of this bad behaviour? Is it busybox's ifconfig that doesn't set the broadcast address correctly or is it the kernel that set it up badly?

Note: it's possible that none of them are responsible but something else gets in the way in the boot process (and reconfigures it badly) as the device runs user-specific software that I don't know. I will follow up with more info once I have them.