LDAP over SSL
Matthias Mielke
Ich plane an unserem Institut die Einführung von ssh.
Da wir sehr viele Benutzer haben, kann die Authentifizierung nur über LDAP
erfolgen.
Ich weiß allerdings nicht, wie man so einen LDAP-Server konfiguriert. Auf
jeden Fall muß dieser LDAP-Server Kontakt mit einem internen Server
aufnehmen.
Jemand soll sich also per ssh an einem LDAP-Server anmelden; dieser Prüft
dann die Berechtigung. Dann soll eine Verbindung zu einem Rechner hinter der
Firewall freigegeben und aufgebaut werden.
Kann mir jemand einen Tip geben, wie man auf diesem Gebiet an geeignete
Literatur kommt ???
Für einen Tip wäre ich sehr dankbar ;-)
Christian Kahlo
Matthias Mielke wrote:
> Ich plane an unserem Institut die Einführung von ssh.
> Da wir sehr viele Benutzer haben, kann die Authentifizierung nur über LDAP
> erfolgen.
Schau Dir mal RFC2865 an. Kann mitunter sinnvoller als LDAP sein,
ausser ihr wollt noch Mega-Byte weise Attributinformationen hinterlegen.
Ausserdem gibt es sehr viel Hardware und Softwareloesungen (Dial-In
Router, Firewalls, VPN-Gateways, etc.) die nur RADIUS, TACACS(+),
etc. pp. sprechen und LDAP nicht so richtig moegen.
Gruss,
Christian
Michael Ströder
>
> Ich plane an unserem Institut die Einführung von ssh.
> Da wir sehr viele Benutzer haben, kann die Authentifizierung nur über LDAP
> erfolgen.
Habt ihr bereits Datenhaltung in einem LDAP-Dienst?
Möchtest Du den LDAP-Server auch für andere Dinge benutzen?
> Ich weiß allerdings nicht, wie man so einen LDAP-Server konfiguriert. Auf
> jeden Fall muß dieser LDAP-Server Kontakt mit einem internen Server
> aufnehmen.
Umgekehrt wird ein Schuh draus. Der Rechner, auf dem sich der
Benutzer anmelden möchte, muß den LDAP-Server kontaktieren.
> Jemand soll sich also per ssh an einem LDAP-Server anmelden; dieser Prüft
> dann die Berechtigung. Dann soll eine Verbindung zu einem Rechner hinter der
> Firewall freigegeben und aufgebaut werden.
pam_ldap/nss_ldap
Du hast uns leider nicht verraten, welches OS Du einsetzt.
> Kann mir jemand einen Tip geben, wie man auf diesem Gebiet an geeignete
> Literatur kommt ???
http://www.openldap.org
http://www.padl.com/projects.html
PAM
RFC2307 (nur ein mögliches Schema)
Ciao, Michael.
Felix von Leitner
Christian, der Mann hat sich Sorgen um die Sicherheit gemacht, und da
dempfiehlst du ihm RADIUS?!
Felix
Christian Kahlo
Felix von Leitner wrote:
> Christian, der Mann hat sich Sorgen um die Sicherheit gemacht, und da
> dempfiehlst du ihm RADIUS?!
Er muss ja nicht gleich die duemmste am Markt verfuegbare
Implementation dazu kaufen.
Die Sachen die wir hier ausprobiert haben (nein, wir haben kein
RADIUS im Produktionsbetrieb ;-)) sahen ganz gut aus.
Man sollte sich natuerlich das Deploymentszenario sehr genau ueberlegen
bevor man pi*Daumen irgendwo einen RADIUS Server hinstellt und sich
spaeter schwer wundert warum das nicht funktioniert.
Also "public clients" bei denen jeder das shared secret lesen kann
oder pot. flooding-sensible Positionen sind natuerlich tabu.
Aber fuer bestimmte Szenarien passt es ganz gut und tut.
Gruss,
Christian
Bernd Eckenfels
> Ich plane an unserem Institut die Einf?hrung von ssh.
Das wird aber Zeit, Ihr setzt doch nicht telnet oder rsh ein? Ich wuerde an
deiner Stelle die Verwendung von ssh unabhaengig von einer neuen Directory
Struktur einfuehren, der Gewinn an Sicherheit ist hier schon im ersten Schritt
betraechtlich.
> Da wir sehr viele Benutzer haben, kann die Authentifizierung nur ?ber LDAP
> erfolgen.
Der Zusammenhang viele Benutzer und "nur LDAP" erschliesst sich mir nicht
ganz. Ich bin auch ein Befrworter von LDAP aber ob ausgerechnet eine "grosse"
(was immer ihr unter viel versteht) useranzahl ein alleinstellungsmerkmal von
LDAP ist wage ich doch zu bezweifeln.
> Ich wei? allerdings nicht, wie man so einen LDAP-Server konfiguriert. Auf
> jeden Fall mu? dieser LDAP-Server Kontakt mit einem internen Server
> aufnehmen.
> Jemand soll sich also per ssh an einem LDAP-Server anmelden; dieser Pr?ft
> dann die Berechtigung. Dann soll eine Verbindung zu einem Rechner hinter der
> Firewall freigegeben und aufgebaut werden.
D.h. du willst auf einer Firewall Logins freischalten und dazu eine
Authentifizierung gegen einen LDAP Server fahren. Speziell dazu ist LDAP
eigentlich nicht notwendig, da kannst du auch beliebige andere Verfahren
verwenden. Bei der Verteilung von Account Infos kann LDAP Punkten, aber das
besonders nur im Heterogenen Umfeld (z.b. Hosts, Unix und NT).
> Kann mir jemand einen Tip geben, wie man auf diesem Gebiet an geeignete
> Literatur kommt ???
www.openldap.org ist als Einstiegspunkt ganz gut, aber wirklich gute Lektuere
ist selten. Boxed Penguin ist ach ein Project das sich mit dem Thema
beschaeftigt. Einen Abriss der Technologien werde ich auf dem LT2001 in S
vorstellen.
So als Background info: Debian verwendet z.b. einen zentralen LDAP Server,
benutzt den aber nicht fuer Online Anfragen bei den Logins, sondern nur um
Batch gesteuert einen lokalen Cache zu fuellen. Grosser Vorteil hierbei ist
die Robustheit des Systems.
Wenn es nur um FW Authorisierungen geht, dann bietet sich RADIUS, TACAS oder
auch TIS auth Daemon an. Sogar SMB Auth ist hier gut geeignet. Und last but
not least Kerberos und AFS Tickets.
Gruss
Bernd
PS: fuehre ssh heute ein, warte mit LDAP auf morgen.
PPS:
LT=http://www.linuxtag.org/2001/showitem.php3?item=103=de&tid=lt-539447855
--
Bernd Eckenfels - www.freefire.de
Dietz Proepper
> Matthias Mielke <m.mi...@dkfz.de> wrote:
> Der Zusammenhang viele Benutzer und "nur LDAP" erschliesst sich mir nicht
> ganz. Ich bin auch ein Befrworter von LDAP aber ob ausgerechnet eine "grosse"
> (was immer ihr unter viel versteht) useranzahl ein alleinstellungsmerkmal von
> LDAP ist wage ich doch zu bezweifeln.
Der Zusammenhang "LDAP" als solcher ist eigentlich nicht allzu einleuchtend.
*Ich* finde LDAP relativ hässlich, und werde immer skeptisch wenn es heißt
"wir wollen alles vereinheitlichen". Außerdem ist mir nachwievor unklar,
welchen Vorteil LDAP gegenüber einer richtigen RDB bringen soll. Gut, ist
lightweight. Das sind die lokalen Caches vom Ergebnis her auch.
> D.h. du willst auf einer Firewall Logins freischalten und dazu eine
> Authentifizierung gegen einen LDAP Server fahren. Speziell dazu ist LDAP
> eigentlich nicht notwendig, da kannst du auch beliebige andere Verfahren
Wozu ist LDAP eigentlich wirklich nötig? Oder sinnvoll? Bitte nicht miß-
verstehen, ich will hier keiner Krieg anzetteln, ich habs nur noch nicht
verstanden und würde es gerne.
> So als Background info: Debian verwendet z.b. einen zentralen LDAP Server,
> benutzt den aber nicht fuer Online Anfragen bei den Logins, sondern nur um
> Batch gesteuert einen lokalen Cache zu fuellen.
Komisch. Die meisten LDAP-Systeme die ich kenne arbeiten so, man hat ein
RDBMS, das füttert LDAP und dann hat man etliche LDAP-Verwender die entweder
lokal cachen oder unverwendbar sind. Hat zudem den Vorteil daß man ohne
das hohe Management mit rüden technischen Details zu nerven noch auf
25 weitgeren Wegen an die Datenbank kommen kann...
> PS: fuehre ssh heute ein, warte mit LDAP auf morgen.
Das eindeutig.
Dietz
Michael Ströder
>
> *Ich* finde LDAP relativ hässlich, und werde immer skeptisch wenn es heißt
> "wir wollen alles vereinheitlichen".
Das Problem ist, daß Leute versuchen die eierlegende Wollmilchsau zu
verkaufen, ohne zuzugeben, daß das mit erheblichem Aufwand verbunden
ist.
> Außerdem ist mir nachwievor unklar,
> welchen Vorteil LDAP gegenüber einer richtigen RDB bringen soll.
- Standardschema
- Standardzugangsprotokoll
- sehr viele LDAP-Bibliotheken für nahezu jede Programmiersprache
- implementiert in gängigen E-Mail-Clients
> Gut, ist lightweight.
Nein, schon lange nicht mehr.
Ich persönlich habe im Rahmen einer PKI LDAP eingesetzt. Danach
weitere Anwendungen.
Ciao, Michael.
Michael Ströder
>
> So als Background info: Debian verwendet z.b. einen zentralen LDAP Server,
> benutzt den aber nicht fuer Online Anfragen bei den Logins, sondern nur um
> Batch gesteuert einen lokalen Cache zu fuellen. Grosser Vorteil hierbei ist
> die Robustheit des Systems.
Welche Infos werden denn bei Debian über LDAP verteilt? Unschön
fände ich es, wenn die Passwörter aus dem userPassword-Attribut im
LDAP in /etc/shadow repliziert werden...
Ciao, Michael.
Felix von Leitner
> einer richtigen RDB bringen soll.
"soll"? Na er soll die ganzen Nachteile nicht haben.
> Gut, ist lightweight.
Quark. Wo kommt dieser Irrglaube eigentlich her?
Nur weil ein paar Gurkenköppe das Protokoll "lightweight" nennen hält es
die Welt plötzlich für Lightweight? Hallo? man "Arbeitslager".
Kinders, laßt Onkel Fefe mal eine der ältesten Heuristiken der
IT-Branche aus der Mottenkiste kramen:
Wenn im Namen <gutes Attribut> ist, dann ist das Produkt das genaue
Gegenteil. Warum sonst müßten sie <gutes Attribut> dazu sagen? Wenn
<gutes Attribut> wahr wäre, würde es den Leuten doch auffallen!
Quick C ist nicht Quick, SMTP ist nicht Simple, LDAP ist nicht
Lightweight, SQL ist nicht Structured, Windows 2000 Professional ist
nicht Professional. Seht ihr? Ist doch ganz einfach.
Felix
Michael Ströder
>
> > Gut, ist lightweight.
>
> Quark. Wo kommt dieser Irrglaube eigentlich her?
Ist halt alles relativ. ;-)
Gegen X.500 war LDAPv2 halt wirklich light-weigth.
Ciao, Michael.
Dietz Proepper
>> Außerdem ist mir nachwievor unklar, welchen Vorteil LDAP gegenüber
>> einer richtigen RDB bringen soll.
>
> "soll"? Na er soll die ganzen Nachteile nicht haben.
Die da wären? Alles liegt in einer Datenbank, wenn sich was
geändert hat dann geht der make los und verteilt die diffs.
Einfach, überschaubar, schlecht skalierend.
Aber Du hast Recht, ldap soll auf jeden Fall besser skalieren,
ist aber in dem Sinn nimmer "einfach".
>> Gut, ist lightweight.
>
> Quark. Wo kommt dieser Irrglaube eigentlich her?
Wenn man einen ldap-Server mit einem Orakel vergleicht dann scheint
mir der ldap-Server doch eher leichtgewichtig.
> Nur weil ein paar Gurkenköppe das Protokoll "lightweight" nennen hält es
> die Welt plötzlich für Lightweight? Hallo? man "Arbeitslager".
Alles eine Frage des Bezugpunkts.
> Kinders, laßt Onkel Fefe mal eine der ältesten Heuristiken der
> IT-Branche aus der Mottenkiste kramen:
Onkel Dietz lauscht gespannt.
> Wenn im Namen <gutes Attribut> ist, dann ist das Produkt das genaue
> Gegenteil. Warum sonst müßten sie <gutes Attribut> dazu sagen? Wenn
> <gutes Attribut> wahr wäre, würde es den Leuten doch auffallen!
>
> Quick C ist nicht Quick,
man MS.
> SMTP ist nicht Simple,
s. Bezugspunkt.
> LDAP ist nicht Lightweight,
s.o.
> SQL ist nicht Structured,
Man kann Strukturen aufbauen. Ist nicht das Problem der Datenbanker
daß die Programmierer was anderes darunter verstehen...
> Windows 2000 Professional ist nicht Professional.
man MS.
Dietz
Stefan Heinecke
>Quick C ist nicht Quick, SMTP ist nicht Simple, LDAP ist nicht
>Lightweight, SQL ist nicht Structured, Windows 2000 Professional ist
>nicht Professional. Seht ihr? Ist doch ganz einfach.
Schöne Zusammenfassung, seit Wochen mal wieder was wahr ist und wo man
herrlich drüber lachen kann.
Ich habe bis dato erst ein Szenario gesehen in dem LDAP Sinn macht.
Aber vielleicht komm ich auch zu wenig rum im Moment.
Michael Ströder
>
> Ich habe bis dato erst ein Szenario gesehen in dem LDAP Sinn macht.
Ja? Und? Lass uns mehr erfahren.
Ciao, Michael.
Alexander Bochmann
>> Außerdem ist mir nachwievor unklar, welchen Vorteil LDAP gegenüber
>> einer richtigen RDB bringen soll.
>> Gut, ist lightweight.
> Quark. Wo kommt dieser Irrglaube eigentlich her?
> Nur weil ein paar Gurkenköppe das Protokoll "lightweight" nennen hält es
> die Welt plötzlich für Lightweight? Hallo? man "Arbeitslager".
[ ] Du hast ne Ahnung, wovon Du sprichst, und vor
welchem Hintergrund sich der Name entwickelt hat.
> Quick C ist nicht Quick, SMTP ist nicht Simple, LDAP ist nicht
> Lightweight, SQL ist nicht Structured, Windows 2000 Professional ist
Turbo C war aber turbo. Und SMTP ist bestimmt Simple im
Vergleich zu anderen Mailsystemen (was auch immer zum
damaligen Zeitpunkt der Vergleich gewesen sein mag), und
LDAP ist verdammt Leightweight im Vergleich zu gewissen
Dingen mit nem X. davor.
Onkel Felix erzaehlt leider Duennschiss, aber das ist
ja auch nix neues.
Alex.
Felix von Leitner
> > Quark. Wo kommt dieser Irrglaube eigentlich her?
> > Nur weil ein paar Gurkenköppe das Protokoll "lightweight" nennen hält es
> > die Welt plötzlich für Lightweight? Hallo? man "Arbeitslager".
> [ ] Du hast ne Ahnung, wovon Du sprichst, und vor
> welchem Hintergrund sich der Name entwickelt hat.
Niemanden interessiert, wie es zu einem Namen gekommen ist.
Er ist falsch. Das war das Argument.
Du faselst.
> > Quick C ist nicht Quick, SMTP ist nicht Simple, LDAP ist nicht
> > Lightweight, SQL ist nicht Structured, Windows 2000 Professional ist
> Turbo C war aber turbo.
Weil es ein Gegenbeispiel gibt, es es auch keine Regel, sondern eine
Heuristik. Wie ich schon schrieb.
Du faselst.
> Und SMTP ist bestimmt Simple im Vergleich zu anderen Mailsystemen (was
> auch immer zum damaligen Zeitpunkt der Vergleich gewesen sein mag),
Harhar. Und ich bin im Vergleich zum Saturn sicher auch
leichtgewichtig. Na und? Spielt keine Rolle. Fakt ist: SMTP ist nicht
Simple. Ob es noch schlimmere Sachen gibt, ist nicht relevant.
Du faselst.
> und LDAP ist verdammt Leightweight im Vergleich zu gewissen Dingen mit
> nem X. davor.
Du faselst.
Felix
Bernd Eckenfels
> Komisch. Die meisten LDAP-Systeme die ich kenne arbeiten so, man hat ein
> lokal cachen oder unverwendbar sind. Hat zudem den Vorteil da? man ohne
> das hohe Management mit r?den technischen Details zu nerven noch auf
> 25 weitgeren Wegen an die Datenbank kommen kann...
Naja, einer der Vorteile von ldaP ist das P. Es ist das Protokoll genormt
keine API oder Produkt. Deswegen macht es sinn mit LDAP auf eine Datenbank
zuzugreifen... das is einer der Punkte die ich auf meinem Vortrag rausarbeiten
will.
Gruss
Bernd
Bernd Eckenfels
> <gutes Attribut> wahr w?re, w?rde es den Leuten doch auffallen!
Speziell bei LDAP (mist ich bring hier meinen ganzen Vortrag) kommt das L
nicht daher weil LDAP sehr einfach ist absolut gesehen (ich meine Hell es
verwendet ASN.1) sondern relativ gesehen (relativ zu X.500 DAP).
Gruss
Bernd
Bernd Eckenfels
> Welche Infos werden denn bei Debian ?ber LDAP verteilt? Unsch?n
> f?nde ich es, wenn die Passw?rter aus dem userPassword-Attribut im
> LDAP in /etc/shadow repliziert werden...
Es werden die SSH Public Keys zusammen mit allen anderen Posix Account Infos
verteilt. Die Passwort Hashes glaube ich allerdings auch, bin mir da nicht
100% sicher.
Debian hat einen gepatchten sshd der in einem einzigen dbm file alle public
keys enthaelt. Dieses File wird durch einen Dump auf das authorizedKey
Attribut erzeugt.
Gruss
Bernd
Michael Ströder
>
> Naja, einer der Vorteile von ldaP ist das P. Es ist das Protokoll genormt
> keine API oder Produkt.
Nicht nur das Protokoll on-the-wire ist genormt, sondern vor allem
auch verschiedene Datenbankschemata (objectClass, attributeType,
syntax). Ein LDAP-fähiger E-Mail-Client kann erwarten im Attribut
"mail" AKA rfc822Mailbox (OID 0.9.2342.19200300.100.1.3) eine
RFC822-konforme E-Mail-Adresse zu finden, etc.
Es gibt übrigens auch genormte APIs, z.B. LDAP C API in RFC1823 oder
die LDAP-EXT APIs für C und Java (siehe auch
http://www.ietf.org/html.charters/ldapext-charter.html).
> Deswegen macht es sinn mit LDAP auf eine Datenbank
> zuzugreifen... das is einer der Punkte die ich auf meinem Vortrag rausarbeiten
> will.
Es macht durchaus in vielen Fällen Sinn, aber nicht ohne
Beschränkungen im Datenmodell.
Zur Diskussion RDBMS vs. LDAP:
http://www.openldap.org/faq/data/cache/378.html
http://www.networkmagazine.com/article/DCM20000502S0039
Ciao, Michael.
Felix von Leitner
> > Wenn im Namen <gutes Attribut> ist, dann ist das Produkt das genaue
> > Gegenteil. Warum sonst m??ten sie <gutes Attribut> dazu sagen? Wenn
> > <gutes Attribut> wahr w?re, w?rde es den Leuten doch auffallen!
> Speziell bei LDAP (mist ich bring hier meinen ganzen Vortrag) kommt das L
> nicht daher weil LDAP sehr einfach ist absolut gesehen (ich meine Hell es
> verwendet ASN.1) sondern relativ gesehen (relativ zu X.500 DAP).
LDAP ist auch relativ gesehen nicht lightweight.
Key-Value-Pair-Lookup über TCP mit Netstrings ist lightweight.
Felix
Michael Ströder
>
> LDAP ist auch relativ gesehen nicht lightweight.
> Key-Value-Pair-Lookup über TCP mit Netstrings ist lightweight.
Wie codiere ich Umlaute? Und wie authentifiziere ich mich? Und
wie...
Natürlich kann man den realen Problemen komplett aus dem Weg gehen,
um alles ganz "light-weight" zu machen.
Ciao, Michael.
Dietz Proepper
>> nicht daher weil LDAP sehr einfach ist absolut gesehen (ich meine Hell es
>> verwendet ASN.1) sondern relativ gesehen (relativ zu X.500 DAP).
>
> LDAP ist auch relativ gesehen nicht lightweight.
Wie gesagt, Standpunkt.
> Key-Value-Pair-Lookup über TCP mit Netstrings ist lightweight.
Das wäre gekatezu skelettartig. Netstrings langen aber nicht.
Dietz
Alexander Bochmann
> Thus spake Alexander Bochmann (a...@2001.news.gxis.de):
>> > Quark. Wo kommt dieser Irrglaube eigentlich her?
>> > Nur weil ein paar Gurkenköppe das Protokoll "lightweight" nennen hält es
>> > die Welt plötzlich für Lightweight? Hallo? man "Arbeitslager".
>> [ ] Du hast ne Ahnung, wovon Du sprichst, und vor
>> welchem Hintergrund sich der Name entwickelt hat.
> Niemanden interessiert, wie es zu einem Namen gekommen ist.
> Er ist falsch. Das war das Argument.
Ach, ich vergass, Du bist Berater.
Das sind die Leute, fuer die die Welt per Definition
einfach ist, weil sie schon lange wieder weg sind, wenn
die wirklichen Probleme auftauchen.
Das Konzept, dass eine Aussage ein Verhaeltis zu einem
existierenden Vergleichsmasstab angibt, ist fuer solche
Leute natuerlich zu komplex. Entschuldige, dass ich Dich
ueberfordert habe.
> Du faselst.
Geh heim.
Alex.
Felix von Leitner
> > Er ist falsch. Das war das Argument.
> Ach, ich vergass, Du bist Berater.
Auch, ja.
> Das sind die Leute, fuer die die Welt per Definition einfach ist, weil
> sie schon lange wieder weg sind, wenn die wirklichen Probleme
> auftauchen.
Das mag auf inkompetente Betrüger zutreffen. Möglicherweise schließt du
hier von dir auf andere. Ich kenne solche Leute nicht.
> Entschuldige, dass ich Dich ueberfordert habe.
Du könntest nicht mal ein Kleinkind intellektuell überfordern.
Felix
Daniel Roesen
> Felix von Leitner wrote:
>> LDAP ist auch relativ gesehen nicht lightweight.
>
> Wie gesagt, Standpunkt.
"Manche Leute haben einen Horizont mit dem Radius 0. Dies nennen sie
dann einen Standpunkt[1]." - [weiss nicht von wem das war]
Nein, ich meine nicht Dich damit, Dietz. :-)
>> Key-Value-Pair-Lookup über TCP mit Netstrings ist lightweight.
>
> Das wäre gekatezu skelettartig. Netstrings langen aber nicht.
Die Nachteile von Netstrings (another marvelous $DEITY invention) wurden
ja auch schon zu Genuege diskutiert.
Aber Du weisst doch... keine Funktionalitaet ist l33t. Alles andere ist
lame.
[1] ich nenn's "Sandkasten mit hohen Raendern"
--
Ich finde, scharfe Waffen und "Feuern nach eigenem Ermessen" sollte zum
Adminjob dazugehören. [Lars Marowsky-Bree in d.a.s.r]
Felix von Leitner
> "Manche Leute haben einen Horizont mit dem Radius 0. Dies nennen sie
> dann einen Standpunkt[1]." - [weiss nicht von wem das war]
> Nein, ich meine nicht Dich damit, Dietz. :-)
Haha, laß mich raten, haha, das war jetzt humoristisch, wie?
Aber wie ich dich kenne, willst du die ganze Zeit den Thread einstellen
und wirst mir gleich vorwerfen, daß ich mit Beschimpfungen angefangen
hätte, wie? Kein Problem, Daniel. Mach nur.
> >> Key-Value-Pair-Lookup über TCP mit Netstrings ist lightweight.
> > Das wäre gekatezu skelettartig. Netstrings langen aber nicht.
> Die Nachteile von Netstrings (another marvelous $DEITY invention) wurden
> ja auch schon zu Genuege diskutiert.
Nein, wurden sie nicht.
Lutz mag sie nicht, _das_ ist diskutiert worden. Warum? Das hat er
nicht so recht darlegen können. Es hat wohl damit zu tun, daß ihm das
Kodieren eines Parsers in Ada zu viel Arbeit war, und er mal wieder
(hach, das hatten wir schon lange nicht mehr...) auf C rumbashen wollte.
> Aber Du weisst doch... keine Funktionalitaet ist l33t. Alles andere ist
> lame.
Hoi, Daniel offenbart uns, aus welchen Kreisen er seine "Bildung"
bezieht! Toll, Daniel, das machst du aber *tätschel* ganz prima!
Und nächstes Jahr zeigen wir dir dann, was ein Umlaut ist...
Daniel Roesen
> Hoi, Daniel offenbart uns, aus welchen Kreisen er seine "Bildung"
> bezieht! Toll, Daniel, das machst du aber *tätschel* ganz prima!
<no comment>
> Und nächstes Jahr zeigen wir dir dann, was ein Umlaut ist...
Och, das ist die Macht von grob 15 Jahren Gewohntheit. Nein, ich werde
mich nicht bemuehen dies zu aendern.
F'up gesetzt.
Daniel Roesen
> Och, das ist die Macht von grob 15 Jahren Gewohntheit.
s/Gewohntheit/Gewohnheit/, bevor die Polizei anrueckt. :-)
Dietz Proepper
>> > Das wäre gekatezu skelettartig. Netstrings langen aber nicht.
>> Die Nachteile von Netstrings (another marvelous $DEITY invention) wurden
>> ja auch schon zu Genuege diskutiert.
>
> Nein, wurden sie nicht.
Durchaus wurden sie. Iirc lief es im wesentlichen auf folgendes hinaus:
- Dumme Programmierer können natürlich auch Netstrings verhunzen.
- Nicht-dumme Programmierer können auch ohne vorangestellte Längenangabe
funktionierende Parser bauen.
- Ein ganzer Rattenschwanz an Problemen wartet auch nachdem ein Netstring
gelesen wurde. Was nützt mir ein Netstring wenn ich dann dessen Anfang
bis zum Token "<blah>" ungeprüft in einen statischen Buffer kopiere?
> Lutz mag sie nicht, _das_ ist diskutiert worden.
Es war nicht zu verkennen, zumindest.
> Warum? Das hat er nicht so recht darlegen können.
Zumindest ich hab' in seine Rede obiges interpretiert.
> Es hat wohl damit zu tun, daß ihm das Kodieren eines Parsers in Ada zu
> viel Arbeit war,
Eh?
> und er mal wieder
> (hach, das hatten wir schon lange nicht mehr...) auf C rumbashen wollte.
C ist aber auch so herrlich bashbar.
Dietz.
Felix von Leitner
> Durchaus wurden sie. Iirc lief es im wesentlichen auf folgendes hinaus:
> - Dumme Programmierer können natürlich auch Netstrings verhunzen.
Nullargument.
> - Nicht-dumme Programmierer können auch ohne vorangestellte Längenangabe
> funktionierende Parser bauen.
Nullargument.
Netstrings erweitern die Klasse der Parser nicht. Das hat niemand
behauptet. Aber es ist natürlich eine uralte Methode der unfairen
Argumentation, der Gegenseite Aussage in die Schuhe zu schieben, die man
einfacher als ihre wirklichen Aussagen widerlegen kann.
> - Ein ganzer Rattenschwanz an Problemen wartet auch nachdem ein Netstring
> gelesen wurde. Was nützt mir ein Netstring wenn ich dann dessen Anfang
> bis zum Token "<blah>" ungeprüft in einen statischen Buffer kopiere?
Das gleiche Nullargument wie das erste.
> > Warum? Das hat er nicht so recht darlegen können.
> Zumindest ich hab' in seine Rede obiges interpretiert.
Richtig, aber das sind keine Argumente.
> > Es hat wohl damit zu tun, daß ihm das Kodieren eines Parsers in Ada zu
> > viel Arbeit war,
> Eh?
man google.
> C ist aber auch so herrlich bashbar.
Was für eine armselige Einstellung.
Konstruktives Arbeiten ist viel erfüllender als Bashing.
Leistet doch einfach was in eurer Lebenszeit, anstatt nur flüchtig
herumzubashen. Das ist in ein paar Wochen wieder vergessen.
Felix
Dietz Proepper
> Thus spake Dietz Proepper (dietz...@rotfl.franken.de):
>> Durchaus wurden sie. Iirc lief es im wesentlichen auf folgendes hinaus:
>> - Dumme Programmierer können natürlich auch Netstrings verhunzen.
>
> Nullargument.
>
>> - Nicht-dumme Programmierer können auch ohne vorangestellte Längenangabe
>> funktionierende Parser bauen.
>
> Nullargument.
> Netstrings erweitern die Klasse der Parser nicht. Das hat niemand
> behauptet.
Dann leg' Dich doch mal fest, was machen Netstrings? "Parser" war
natürlich der falsche Begriff, ich hatte 2 Schritte weiter gedacht.
> Aber es ist natürlich eine uralte Methode der unfairen Argumentation,
Beruhig' Dich Felix, ich bin lernbereit, ob -fähig wird sich zeigen.
> der Gegenseite Aussage in die Schuhe zu schieben, die man
> einfacher als ihre wirklichen Aussagen widerlegen kann.
Ich hatte von Dir als Rationale für Netstrings ein "kein Bufferoverflow"
im Ohr. Da dies natürlich Unsinn ist, habe ich Dich sicher falsch ver-
standen.
>> - Ein ganzer Rattenschwanz an Problemen wartet auch nachdem ein Netstring
>> gelesen wurde. Was nützt mir ein Netstring wenn ich dann dessen Anfang
>> bis zum Token "<blah>" ungeprüft in einen statischen Buffer kopiere?
>
> Das gleiche Nullargument wie das erste.
Nee, wenn dann ein anderes. "das erste" bezog sich auf das Problem,
den Stringinhalt in den Speicher zu bewegen. Obiges war eher im Hinblick
darauf gedacht daß Strings nicht das einzige sind was man u.U. trans-
portieren möchte und damit ASN.[choose] zumindest von der Idee her Sinn
macht.
>> > Warum? Das hat er nicht so recht darlegen können.
>> Zumindest ich hab' in seine Rede obiges interpretiert.
>
> Richtig, aber das sind keine Argumente.
Gut, dann sei bitte so freundlich und stelle noch mal klar und prägnant
und für solch ignorante Toren wie mich verstehbar dar was aus Deiner
Sicht der Grund sein könnte, Netstrings zu verwenden.
>> C ist aber auch so herrlich bashbar.
>
> Was für eine armselige Einstellung.
Felix, dieses "ich bin viel leeter als Du" beginnt zu langweilen.
Dietz
Felix von Leitner
> > behauptet.
> Dann leg' Dich doch mal fest, was machen Netstrings? "Parser" war
> natürlich der falsche Begriff, ich hatte 2 Schritte weiter gedacht.
Netstrings definieren eine Syntax, mit der man Daten so übertragen kann,
daß die Gegenseite vor der Übertragung der Daten weiß, wie viele Daten
kommen werden. So kann 1. realloc() vermieden werden, 2. Code gespart
werden, 3. Platzmangel vor dem Entgegennehmen der eigentlichen Nutzdaten
erkannt werden.
> >> - Ein ganzer Rattenschwanz an Problemen wartet auch nachdem ein Netstring
> >> gelesen wurde. Was nützt mir ein Netstring wenn ich dann dessen Anfang
> >> bis zum Token "<blah>" ungeprüft in einen statischen Buffer kopiere?
> > Das gleiche Nullargument wie das erste.
> Nee, wenn dann ein anderes. "das erste" bezog sich auf das Problem,
> den Stringinhalt in den Speicher zu bewegen. Obiges war eher im Hinblick
> darauf gedacht daß Strings nicht das einzige sind was man u.U. trans-
> portieren möchte und damit ASN.[choose] zumindest von der Idee her Sinn
> macht.
Ah. Richtig, das Marshalling-Problem lösen Netstrings nicht.
> >> C ist aber auch so herrlich bashbar.
> > Was für eine armselige Einstellung.
> Felix, dieses "ich bin viel leeter als Du" beginnt zu langweilen.
Langeweile impliziert Zeit, die du anders hättest verbringen können und
wollen. Schreibe doch einfach freie Software! Das ist sehr erfüllend.
Felix
Rainer Weikusat
> > natürlich der falsche Begriff, ich hatte 2 Schritte weiter gedacht.
>
> Netstrings definieren eine Syntax, mit der man Daten so übertragen kann,
> daß die Gegenseite vor der Übertragung der Daten weiß, wie viele Daten
> kommen werden. So kann 1. realloc() vermieden werden, 2. Code gespart
> werden, 3. Platzmangel vor dem Entgegennehmen der eigentlichen Nutzdaten
> erkannt werden.
Die Annahme, mein jeweiliges Gegenüber erzähle mir nicht absichtlich
die Unwahrheit (oder unabsichtlich durch Programmfehler) ist in einem
robusten Programm ausgesprochen fehl am Platz.
Insofern gewinne ich eine (ASCII-kodierte) Längenangabe und spare
nichts.
--
SIGSTOP
Dietz Proepper
> Thus spake Dietz Proepper (dietz...@rotfl.franken.de):
>> > Netstrings erweitern die Klasse der Parser nicht. Das hat niemand
>> > behauptet.
>> Dann leg' Dich doch mal fest, was machen Netstrings? "Parser" war
>> natürlich der falsche Begriff, ich hatte 2 Schritte weiter gedacht.
>
> Netstrings definieren eine Syntax, mit der man Daten so übertragen kann,
> daß die Gegenseite vor der Übertragung der Daten weiß, wie viele Daten
> kommen werden.
Nicht mehr?! Wegen so'ner Kleinigkeit etablierte Protokolle anfassen?
Aua.
> So kann 1. realloc() vermieden werden, 2. Code gespart
> werden, 3. Platzmangel vor dem Entgegennehmen der eigentlichen Nutzdaten
> erkannt werden.
Das leistet ein vernünftiges marshalling auch.
>> Nee, wenn dann ein anderes. "das erste" bezog sich auf das Problem,
>> den Stringinhalt in den Speicher zu bewegen. Obiges war eher im Hinblick
>> darauf gedacht daß Strings nicht das einzige sind was man u.U. trans-
>> portieren möchte und damit ASN.[choose] zumindest von der Idee her Sinn
>> macht.
>
> Ah. Richtig, das Marshalling-Problem lösen Netstrings nicht.
Marshalling. Danke.
Und da sitzt eben oft auch das Problem drin. Wenn man jetzt schon hergeht,
an irgendeiner Stelle Netstrings verwendet und damit existierendes neu
definiert könnte man gleich Nägel mit Köpfen machen.
>> >> C ist aber auch so herrlich bashbar.
>> > Was für eine armselige Einstellung.
>> Felix, dieses "ich bin viel leeter als Du" beginnt zu langweilen.
>
> Langeweile impliziert Zeit, die du anders hättest verbringen können und
> wollen.
Ich las News, stellte fest daß 80% Deines Postings interessant waren.
> Schreibe doch einfach freie Software!
Dazu würden die restlichen 20% nicht langen.
> Das ist sehr erfüllend.
Ja, man darf sich dann nebst normalen Kunden (was schon unschön genug
sein kann) auch noch die Klagen von all den Heulern anhören die
geschenkten Gäulen ins Maul schauen müssen.
Abgesehen davon - etwas so zu machen daß ich es in meinem Namen ver-
öffentlichen würde ist mir einfach zu aufwendig. Weißt schon, nicht 50k
Source ohne Punkt und Komma sondern 50k Source mit definierter Semantik
welche durch Regressionstests und Dokumentation unterstützt für den
Verwender eine wahre Freude bedeuten.
Dietz
Dietz Proepper
> Felix von Leitner <lei...@fefe.de> writes:
>> Netstrings definieren eine Syntax, mit der man Daten so übertragen kann,
>> daß die Gegenseite vor der Übertragung der Daten weiß, wie viele Daten
>> kommen werden. So kann 1. realloc() vermieden werden, 2. Code gespart
>> werden, 3. Platzmangel vor dem Entgegennehmen der eigentlichen Nutzdaten
>> erkannt werden.
>
> Die Annahme, mein jeweiliges Gegenüber erzähle mir nicht absichtlich
> die Unwahrheit (oder unabsichtlich durch Programmfehler) ist in einem
> robusten Programm ausgesprochen fehl am Platz.
Naja, Netstrings sind in sofern fail-safe daß eine korrekte Implementierung
relativ einfach ist und ein Sender mittels Erzählen der Unwahrheit nur sich
selber schadet.
> Insofern gewinne ich eine (ASCII-kodierte) Längenangabe und spare
> nichts.
Die Idee als solche, Protokolle die Maschinen miteinander sprechen in
einer einfach maschinell darstellbaren Weise zu verpacken ist erstmal
durchaus sinnvoll.
Sprich, würde man jetzt ein Protokoll neuschreiben dann wäre die Ver-
wendung etwas Netstring-ähnlichen durchaus zu überlegen. Wobei mir
Netstrings da zuwenig Funktion bieten würden.
Dietz
Rainer Weikusat
> Rainer Weikusat wrote:
> > Die Annahme, mein jeweiliges Gegenüber erzähle mir nicht absichtlich
> > die Unwahrheit (oder unabsichtlich durch Programmfehler) ist in einem
> > robusten Programm ausgesprochen fehl am Platz.
>
> Naja, Netstrings sind in sofern fail-safe daß eine korrekte Implementierung
> relativ einfach ist und ein Sender mittels Erzählen der Unwahrheit nur sich
> selber schadet.
Trotzdem hilft das nicht viel, weil ich mich nicht auf eine korrekte
Implementierung am anderen Ende verlassen kann und weil ich einen best
effort unternehmen sollte, trotz Fehlern 'etwas sinnvolles' damit
anzufangen ("Be liberal ..."). Um das Ende eines Datenblock
zuverlässig erkennen zu können, brauche ich einen out-of-band-Marker,
der dieses Ende markiert. Bei den meisten Internetprotokollen (FTP,
SMTP, POP3 usf) ist das \r\n. IIRC gibt es bei netstrings ein ',' am
Ende, was eine 'heuristische' Fehlerüberprüfung ermöglicht, aber das
ist in band, tut also nicht. Falls der Sender und der Empfänger nicht
mehr synchron sind, können sie sich damit auch nicht mehr
re-synchronisieren, weil sowohl ',' als auch '[0-9]+:' überall im
Datenstrom erlaubt sind.
Deswegen auch Lutz' Beispiel mit ASN.x base64-encoded und blanks. Die
wären ebenfalls out of band.
Nicht, das man das nicht auch kaputtkriegen könnte, aber soviel Gewinn
bringt das nicht.
> > Insofern gewinne ich eine (ASCII-kodierte) Längenangabe und spare
> > nichts.
>
> Die Idee als solche, Protokolle die Maschinen miteinander sprechen in
> einer einfach maschinell darstellbaren Weise zu verpacken ist erstmal
> durchaus sinnvoll.
Die Idee, sie in einer für Menschen verständlichen Art und Weise
miteinander sprechen zu lassen, auch. Aber das grenzt an
'Glaubensartikel' ;-).
--
SIGSTOP
Michael Ströder
>
> Felix von Leitner wrote:
> > Schreibe doch einfach freie Software!
> > Das ist sehr erfüllend.
>
> [..]
> Abgesehen davon - etwas so zu machen daß ich es in meinem Namen ver-
> öffentlichen würde ist mir einfach zu aufwendig. Weißt schon, nicht 50k
> Source ohne Punkt und Komma sondern 50k Source mit definierter Semantik
> welche durch Regressionstests und Dokumentation unterstützt für den
> Verwender eine wahre Freude bedeuten.
Wer nix macht, macht nix falsch. Und ist auch bequemer.
Ciao, Michael.
Daniel Roesen
> Wer nix macht, macht nix falsch. Und ist auch bequemer.
Hehe, DJB Standardtaktik. Alle Dinge die ueber die Komplexitaet von
"Hello World" hinausgehen (leicht uebertrieben gesagt) werden mit
teilweise haarstraeubenden "Argumentationen" als "boese" oder "unnoetig"
deklariert, damit $DEITY das nicht implementieren muss. Und nicht
implementiertes hat keine Fehler, damit hat er absolut Recht. :-)
Nur leider braucht die Welt ausserhalb seines Standpunktes (:-]) etwas
mehr als Hello World.
Bernd Eckenfels
> da? die Gegenseite vor der ?bertragung der Daten wei?, wie viele Daten
> kommen werden.
Das tut ASN.1 auch.
Gruss
Bernd
Bernd Eckenfels
> Nicht mehr?! Wegen so'ner Kleinigkeit etablierte Protokolle anfassen?
> Aua.
Gruss
Bernd
Felix von Leitner
> > da? die Gegenseite vor der ?bertragung der Daten wei?, wie viele Daten
> > kommen werden.
> Das tut ASN.1 auch.
Ja.
Du zeigst mir einen vollständigen ASN.1-Parser in 1k Code, dann
akzeptiere ich das als "Argument".
Diese Binsenweisheit bringe ich mal der Vollständigkeit halber, dir wird
sie natürlich bekannt sein (auch wenn du sie natürlich für dieses
"Argument" geflissentlich ignoriert hast):
Mehr Code == Mehr Komplexität == Weniger Sicherheit
Felix
Bernd Eckenfels
> akzeptiere ich das als "Argument".
Ich wollte nicht argumentieren, ich weollte nur die pro Netstrings Argumente
entkraeften.
Ich persoenlich finde Netstrings ein Kompromiss zwischen "ascii protokoll" und
"binaer protokoll" der nicht gegückt ist. Wenn ich ein Protokoll für den
Computer einfacher machen will, dann halte ich mich an den Grundsatz von DJB
"dont parse". Wieso er den bei Netstrings nicht eingehalten hat wweiss ich
nicht. Jedenfalls sieht meine Alternative zu Netstrings einfach aus :) Java
UTF8 Strings, die sind binaercodiert und haben einen vorangestellten binaer
(Networked Byte Order) laengenidentifier.
Die sind damit genauso receiver freundlich wie netstrings, die laengenangabe
muss nicht geparsed werden und die übertragenen zeichen können unicode sein.
Einziges Probem: UTF8 kennt ungueltige Zeichen, d.h man braucht hier einen
UTF8 "Parser". Aber ich glaube das kann man akzeptieren.
Gruss
BErnd
Dietz Proepper
Es ist besser, nichts zu tun als mit viel Aufwand nichts zustandezubringen.
Und wenn ich mir 80% dessen was unter Open Source segelt anschaue dann
weiß ich daß die Leute die Zeit besser mit was anderem verbracht hätten.
> Und ist auch bequemer.
Nee, Michael, das ist das was ich als "kann geistig nicht folgen"-Fehler
bezeichne. Ganz einfach für Dich: Operative Hektik ist ein gern verwendeter
Ausgleich für geistige Windstille.
Dietz
Dietz Proepper
Ach.
Juergen P. Meier
>> Nicht mehr?! Wegen so'ner Kleinigkeit etablierte Protokolle anfassen?
Subject: LDAP over SSL
und worueber redest du so?
SCNR
juergen
--
J...@lrz.fh-muenchen.de - "This World is about to be Destroyed!"
end
<URL:http://support.microsoft.com/support/kb/articles/q265/2/30.asp>
<URL:http://support.microsoft.com/support/kb/articles/Q260/8/22.ASP>
Lutz Donnerhacke
>Netstrings erweitern die Klasse der Parser nicht.
Doch, das tun sie. Zum Parsen von Netstrings kann man die klassischen
Parsergeneratoren wegwerfen, da Netstrings ein Typ 1-Sprache ist.
Lutz Donnerhacke
>Naja, Netstrings sind in sofern fail-safe daß eine korrekte Implementierung
>relativ einfach ist und ein Sender mittels Erzählen der Unwahrheit nur sich
>selber schadet.
Ich hatte bereits dargelegt, daß ein korrekter Parser nicht mit
Standardmitteln automatisch generiert werden kann (falsche Sprachklasse) und
ein nicht klug durchdachter handgeschriebener Parser anfällig für
Bufferoverflows ist.
>Sprich, würde man jetzt ein Protokoll neuschreiben dann wäre die Ver-
>wendung etwas Netstring-ähnlichen durchaus zu überlegen. Wobei mir
>Netstrings da zuwenig Funktion bieten würden.
Ack. Man würde ASN.1 nehmen.
Lutz Donnerhacke
>> > Netstrings definieren eine Syntax, mit der man Daten so ?bertragen kann,
>> > da? die Gegenseite vor der ?bertragung der Daten wei?, wie viele Daten
>> > kommen werden.
>> Das tut ASN.1 auch.
>
>Ja.
>Du zeigst mir einen vollständigen ASN.1-Parser in 1k Code, dann
>akzeptiere ich das als "Argument".
Das ist kein Problem, solange er nur die gleiche Funktionalität haben soll,
ist er kleiner zu bekommen.
Felix von Leitner
> >Netstrings erweitern die Klasse der Parser nicht.
> Doch, das tun sie. Zum Parsen von Netstrings kann man die klassischen
> Parsergeneratoren wegwerfen, da Netstrings ein Typ 1-Sprache ist.
Die Aussage war: du kannst mit Netstrings nicht mehr parsen als ohne.
Felix
Felix von Leitner
> >Du zeigst mir einen vollständigen ASN.1-Parser in 1k Code, dann
> >akzeptiere ich das als "Argument".
> Das ist kein Problem, solange er nur die gleiche Funktionalität haben soll,
> ist er kleiner zu bekommen.
Das "vollständig" hast du gesehen, ja?
Aus ASN.1 alle Sachen außer Strings rauszulassen ist möglich, und dann
hast du das Ziel von Netstrings auch erreicht. Aber es handelt sich
dann nicht mehr um ASN.1, sondern um eine Teilmenge von ASN.1.
Felix
Lutz Donnerhacke
>> >Ja.
>> >Du zeigst mir einen vollständigen ASN.1-Parser in 1k Code, dann
>> >akzeptiere ich das als "Argument".
>> Das ist kein Problem, solange er nur die gleiche Funktionalität haben soll,
>> ist er kleiner zu bekommen.
>
>Das "vollständig" hast du gesehen, ja?
Ja. Fordere von einem Genetiker die komplette Beschreibung aller
Erbgutinformationen, wenn Du DNA als unbrauchbar abstempeln willst.
Felix von Leitner
Wieso das denn?
Ich fordere von euch nicht alle mit ASN.1 kodierbaren Daten, sondern
einen kompletten Parser.
Felix
Lutz Donnerhacke
>einen kompletten Parser.
Für Schwanzvergleiche sollte man gleiche Funktion voraussetzen, sonst wird
es widerlich.
Daniel Roesen
> Für Schwanzvergleiche sollte man gleiche Funktion voraussetzen, sonst wird
> es widerlich.
Das kann er schon bei BIND/djbdns nicht, warum sollte er es dann bei
ASN.1/Netstrings koennen?
Robin S. Socha
>> Für Schwanzvergleiche sollte man gleiche Funktion voraussetzen, sonst
>> wird es widerlich.
> Das kann er schon bei BIND/djbdns nicht, warum sollte er es dann bei
> ASN.1/Netstrings koennen?
Lieber Daniel,
hiermit ernenne ich Dich zum Gruppenbeauftragten für die Kontrolle der
korrekten Durchführung von Schwanzvergleichen.
Diese Entscheidung ist angesichts der großen Zahl an Bewerbern nicht
leichtgefallen. Letzlich jedoch gab Deine über Monate hinweg bewiesene
Fähigkeit, unbeeinflußt von Wissen und Fakten über Dinge zu urteilen,
deren Vergleichsgrundlage Du nicht verstanden hast, verbunden mit der
Schlichtheit des sprachlichen und argumentativen Auftretens sowie der
höflichen Zurückhaltung im Umgang mit der Wahrheit den Ausschlag für
Dich.
Herzlichen Glückwunsch und viel Erfolg in Deinem neuem Job, Daniel!
Dein
Robin
--
Robin S. Socha - Your Worst Network Nightmare(tm).
`In Germany, they are not referred to as network administrators. They
prefer to be called "Sons Of The Third Reich".' (Kate: www.katewerk.com)
Immo 'FaUl' Wehrenberg
> * Daniel Roesen <d...@bofh.de> writes:
> hiermit ernenne ich Dich zum Gruppenbeauftragten für die Kontrolle der
> korrekten Durchführung von Schwanzvergleichen.
*g*
> Letzlich jedoch gab Deine über Monate hinweg bewiesene
> Fähigkeit, unbeeinflußt von Wissen und Fakten über Dinge zu urteilen,
> deren Vergleichsgrundlage Du nicht verstanden hast,
Hm, seine Kompetenzsimulation war nicht wirklich schlecht (im BIND vs DJBdns
Thread). Das einzige was wirklich nervt sind seine ständigen anti-fefe-flames
(da diese noch nicht einmal lustig sind, du solltest da wirklich noch dran
Arbeiten, Daniel!).
FaUl
end
This article does not support incompatible and broken newsreaders.
--
ED IS THE TRUE PATH TO NIRVANA! ED HAS BEEN THE CHOICE OF EDUCATED
AND IGNORANT ALIKE FOR CENTURIES! ED WILL NOT CORRUPT YOUR PRECIOUS
BODILY FLUIDS!! ED IS THE STANDARD TEXT EDITOR! ED MAKES THE SUN
SHINE AND THE BIRDS SING AND THE GRASS GREEN!! (Patrick J. LoPresti)
Robin S. Socha
> [Daniel "Schwanzbeauftragter" Roesens] Kompetenzsimulation war nicht
> wirklich schlecht (im BIND vs DJBdns Thread).
Sie war gut genug für Leute, die Fakten vernachlässigen um sich viriler
zu fühlen (cf. man (3) sendmail_admin).
> Das einzige was wirklich nervt sind seine ständigen anti-fefe-flames
Was nervt ist sein Herumtrollen mit halbverstandenem Viertelwissen und
seine Propaganda für die Vixie-Kommune und ihre Malware.
Andreas Ferber
>
>> Das einzige was wirklich nervt sind seine ständigen anti-fefe-flames
> Was nervt ist sein Herumtrollen mit halbverstandenem Viertelwissen und
> seine Propaganda für die Vixie-Kommune und ihre Malware.
Was nervt ist der ständige heilige Krieg, den einige DJB-Jünger meinen
führen zu müssen.
Andreas, sowohl bind und sendmail als auch djbdns und qmail einsetzend.
--
"Who is General Failure and why is he reading my hard disk ?"
Microsoft spel chekar vor sail, worgs grate !!
(By lei...@inf.fu-berlin.de, Felix von Leitner)
Felix von Leitner
> >> Das einzige was wirklich nervt sind seine ständigen anti-fefe-flames
> > Was nervt ist sein Herumtrollen mit halbverstandenem Viertelwissen und
> > seine Propaganda für die Vixie-Kommune und ihre Malware.
> Was nervt ist der ständige heilige Krieg, den einige DJB-Jünger meinen
> führen zu müssen.
Du halluzinierst.
djb-Jünger führen keinen heiligen Krieg (das ist ein Angriffskrieg),
sondern sie verteidigen djb-Software gegen unwahre und unfaire Anwürfe.
> Andreas, sowohl bind und sendmail als auch djbdns und qmail einsetzend.
Grandiose Idee! Du mußt ja ein wahrhaft großer Forscher sein, daß du
freiwillig alle möglichen Programme parallel laufen läßt. Nur so kannst
du sicher sein, daß bei dir auch wirklich alle Exploits funktionieren,
und du hast anständig viel Substanz für eine umfassende Post-Mortem
Analyse. Veröffentlichst du die Statistiken bitte frühzeitig, damit da
auch andere was von haben?
Wie hast du das mit deinem ISP geregelt, daß du keine Traffikkosten
zahlen mußt, wenn die Leute dich als Relay benutzen? Oh,
uni-bielefeld.de. Keine weiteren Fragen; zahlt der Steuerzahler. Kann
dir also wurscht sein.
So langsam verstehe ich, wieso unser Bundeskanzler IT-Fachkräfte lieber
aus Indien einfliegt als von unseren Unis nimmt. Es ist billiger, die
Leute da mit sendmail spielen zu lassen, als daß man sie in der
Wirtschaft echt Schaden anrichten läßt.
Felix
Rainer Weikusat
> sondern sie verteidigen djb-Software gegen unwahre und unfaire Anwürfe.
[...]
> Wie hast du das mit deinem ISP geregelt, daß du keine Traffikkosten
> zahlen mußt, wenn die Leute dich als Relay benutzen? Oh,
> uni-bielefeld.de.
Sowas nennt man dann wohl 'Amiguitätstoleranz'...
--
SIGSTOP
Juergen P. Meier
>> >> Das einzige was wirklich nervt sind seine ständigen anti-fefe-flames
>> > Was nervt ist sein Herumtrollen mit halbverstandenem Viertelwissen und
>> > seine Propaganda für die Vixie-Kommune und ihre Malware.
>> Was nervt ist der ständige heilige Krieg, den einige DJB-Jünger meinen
>> führen zu müssen.
>
>Du halluzinierst.
>
>djb-Jünger führen keinen heiligen Krieg (das ist ein Angriffskrieg),
>sondern sie verteidigen djb-Software gegen unwahre und unfaire Anwürfe.
Ach, und was sind dann deine (und Sascha's) attacken gegn BIND, sendmail
und cron?
Behaupte hier bitte nichts, was sich mit google in paar min. _deutlich_
durch zig postings wiederlegen laesst. Du machst dich nur unnoetig
laecherlich.
>> Andreas, sowohl bind und sendmail als auch djbdns und qmail einsetzend.
>
>Grandiose Idee! Du mußt ja ein wahrhaft großer Forscher sein, daß du
>freiwillig alle möglichen Programme parallel laufen läßt. Nur so kannst
>du sicher sein, daß bei dir auch wirklich alle Exploits funktionieren,
>und du hast anständig viel Substanz für eine umfassende Post-Mortem
>Analyse. Veröffentlichst du die Statistiken bitte frühzeitig, damit da
>auch andere was von haben?
man heterogene Umgebungen.
Aber wir alle wissen ja, das du nur einen einzigen rechner hast.
>Wie hast du das mit deinem ISP geregelt, daß du keine Traffikkosten
>zahlen mußt, wenn die Leute dich als Relay benutzen? Oh,
>uni-bielefeld.de. Keine weiteren Fragen; zahlt der Steuerzahler. Kann
>dir also wurscht sein.
Hmm, mit qmail ist es einfacher ein openrelay zu bauen.
>So langsam verstehe ich, wieso unser Bundeskanzler IT-Fachkräfte lieber
>aus Indien einfliegt als von unseren Unis nimmt. Es ist billiger, die
>Leute da mit sendmail spielen zu lassen, als daß man sie in der
>Wirtschaft echt Schaden anrichten läßt.
? PARSE ERROR
>Felix
Andreas Ferber
>
>> Andreas, sowohl bind und sendmail als auch djbdns und qmail einsetzend.
> Grandiose Idee! Du mußt ja ein wahrhaft großer Forscher sein, daß du
> freiwillig alle möglichen Programme parallel laufen läßt.
Wer hat gesagt, daß ich das ganz freiwillig tue? Das sendmail würde ich
auch lieber früher als später loswerden (Ersatz durch postfix ist in
Planung). Für den bind hier ist djbdns keine wirkliche Alternative.
> Nur so kannst
> du sicher sein, daß bei dir auch wirklich alle Exploits funktionieren,
> und du hast anständig viel Substanz für eine umfassende Post-Mortem
> Analyse. Veröffentlichst du die Statistiken bitte frühzeitig, damit da
> auch andere was von haben?
Hmm, die Statistik ist schnell gemacht: Aufgemachte Kisten: 0,
erfolgreiche DoS: 0.
> Wie hast du das mit deinem ISP geregelt, daß du keine Traffikkosten
> zahlen mußt, wenn die Leute dich als Relay benutzen? Oh,
> uni-bielefeld.de.
[ ] Du kannst einen NNTP-Posting-Host lesen.
Andreas
--
Andreas Ferber - dev/consulting GmbH - Bielefeld, FRG
---------------------------------------------------------
+49 521 1365800 - a...@devcon.net - www.devcon.net