[LUGA] Mit freundlicher Unterstützung von:
init.at

Mail Thread Index


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RANT]: Uralt Standards (was Re: [luga] ulimit, ...



Goesta Smekal wrote:
Bernd Petrovitsch wrote:
[snip]
Lt. http://www.openldap.org/ ist 2.3.27 stable - sollte also ein eher
geringeres Risiko sein, die Etch-Version zu backporten.

und da liegt auch der Weg zur Lösung !

[snip]
Ubuntu 6.06lts Server hat leider auch noch slapd 2.2.26. Aber ein LDAP Server mit Debian testing sollte ja kein Problem sein ...

  vielleicht kann CentOS noch warten :-)

CentOS kann mir gestohlen bleiben (zumindest in diesem Kontext) weil die auch noch einen 2.2er slapd haben, der mach 1024 FDs aufgibt.

Aber unter Debian Etch gibt es ja besagten 2.3er und da lässt sich auf meinem PC ein netter Test machen:

zuerst ein kleines Perlscript, das so viele TCP Verbindungen zum LDAP Server aufmacht wie möglich:

<code>
#!/usr/bin/perl -w
# LDAP-Bomb.pl
# v0.1 14.11.2006 GS

use IO::Socket;
my $nr=0;
my @socket;

while (1) {
  unless ( $socket[$nr] = IO::Socket::INET->new(
      PeerAddr => '192.168.56.130',
      PeerPort => 389,
      Proto => 'tcp',
      Type => SOCK_STREAM) )
  { print "It's over. Socket #$nr:\n$!\n"; exit; };
  ++$nr;
}
</code>

und damit wir den Server auch so richtig nerven wird das mehrfach gestartet:

<code>
#!/bin/bash
# LDAP-Bomb.sh
# v0.1 14.11.2006 GS

LIMIT=20
NUMBER=0

for ((NUMBER=1; NUMBER <= LIMIT; NUMBER++))
do
  echo "starte LDAP-Bomb #$NUMBER im Hintergrund ..."
  ./ldap-bomb.pl > bomb-log_$NUMBER &
done
</code>

Ohne weitere Vorkehrungen und als normaler User gestartet kommen wir wieder nur auf 102 Verbindungen, dann folgt der Eintrag:

Nov 14 22:30:59 localhost slapd[6692]: warning: cannot open /etc/hosts.allow: Too many open files

in /var/log/messages. ABER: wenn ich jetzt besagten Patch in /etc/init.d/slapd anbringe ("ulimit -n 10240" an einer prominenten Stelle) dann verkraftet der slapd locker 4000 Verbindungen (state ESTABLISHED wohlgemerkt, also TIME_WAIT und so wird nicht mitgezählt)
und dann habe ich hier eine Load von 3 und die CPU ist auf 100%.

Aber das ist ja nur ein kleiner Celeron und kein dual Xeon wie im Büro ;-)

Es liegt also offenbar an select statt poll und die OpenLDAP Leute haben das schon behoben. Jetzt müssen also nur noch die Distros nachziehen.

nochmal herzlichen Dank für eure Hilfe,

  Goesta

--
#!/usr/bin/perl
foreach $c (split(/ /,"47 6f 65 73 74 61 20 53 6d 65 6b 61 6c 0d 0a")) {
print pack("C", hex($c));}



powered by LINUX the choice of a gnu generation
linux user group austria;
Suche
Suche
Letzte Änderung:
webmaster@luga.at
September 2010