From mw@miwie.in-berlin.de  Mon Dec  3 12:52:15 2001
From: mw@miwie.in-berlin.de (Michael Wiedmann)
Date: Mon, 3 Dec 2001 13:52:15 +0100
Subject: [buug-l] Stammtisch, 07.12.01?
Message-ID: <20011203135215.A1839@miwie.in-berlin.de>

Wie wär's noch mal mit einem Stammtisch in diesem Jahr?

Vorschlag: Freitag, 07.12.01, ab 18:30
Ort:       wie immer, Mexikaner am Schlesischen Tor

Rückmeldung an die Liste erbeten.

Michael
... noch ganz entspannt vom Urlaub ...
-- 
mw@miwie.in-berlin.de                              http://www.miwie.org
mw@miwie.org


From mskranz@acm.org  Mon Dec  3 14:45:51 2001
From: mskranz@acm.org (Matthias Kranz)
Date: Mon, 03 Dec 2001 15:45:51 +0100 (CET)
Subject: [buug-l] Stammtisch, 07.12.01?
In-Reply-To: <20011203135215.A1839@miwie.in-berlin.de>
References: <20011203135215.A1839@miwie.in-berlin.de>
Message-ID: <1007390751.3c0b901fe8b01@webmail.in-berlin.de>

Quoting Michael Wiedmann <mw@miwie.in-berlin.de>:

> Wie wär's noch mal mit einem Stammtisch in diesem Jahr?
> 
> Vorschlag: Freitag, 07.12.01, ab 18:30
> Ort:       wie immer, Mexikaner am Schlesischen Tor

Auf jeden Fall.

Frank und ich haben am Wochenende schon darueber gesprochen. Aber bei uns geht
es ziemlich hektisch zu, weil wir extrem zu tun haben und daher noch kein
Announcement.

Ich wuerde vorschlagen, dass einfach alle auf die Liste schreiben, die kommen
moechten. Dann koennen wir wenigstens in etwa eine Prognose fuer die
Tischvorbestellung abgeben.

Cheers,
Matthias
-- 
Matthias Kranz
mskranz@acm.org

From Werner Heuser <wehe@mobilix.org>  Mon Dec  3 17:33:48 2001
From: Werner Heuser <wehe@mobilix.org> (Werner Heuser)
Date: Mon, 03 Dec 2001 18:33:48 +0100
Subject: [buug-l] Stammtisch, 07.12.01?
References: <20011203135215.A1839@miwie.in-berlin.de>
Message-ID: <3C0BB77C.6F15029A@snafu.de>

Ich wuerde kommen.

Werner
-- 
|=| Werner Heuser = Keplerstr. 11A = D-10589 Berlin = Germany
|=| <wehe_AT_mobilix.org>      T. 0049 - (0)30 - 349 53 86
|=| http://MobiliX.org         UniX on Mobile Systems: HOWTOs,Software
|=| http://Xtops.DE            Laptops+PDAs pre-installed with UniX
|*| This is no time for phony rhetoric -- Lou Reed

From fr@openoffice.de  Mon Dec  3 19:22:33 2001
From: fr@openoffice.de (Frank Ronneburg)
Date: Mon, 3 Dec 2001 20:22:33 +0100
Subject: [buug-l] Stammtisch, 07.12.01?
In-Reply-To: <1007390751.3c0b901fe8b01@webmail.in-berlin.de>
References: <20011203135215.A1839@miwie.in-berlin.de> <1007390751.3c0b901fe8b01@webmail.in-berlin.de>
Message-ID: <20011203202232.G14068@openoffice.de>

--SWTRyWv/ijrBap1m
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Quoting Matthias Kranz <mskranz@acm.org>:
>=20
> > Wie w=E4r's noch mal mit einem Stammtisch in diesem Jahr?
> >=20
> > Vorschlag: Freitag, 07.12.01, ab 18:30
> > Ort:       wie immer, Mexikaner am Schlesischen Tor
>=20
> Auf jeden Fall.

ich komme.

> Frank und ich haben am Wochenende schon darueber gesprochen. Aber bei uns=
 geht
> es ziemlich hektisch zu, weil wir extrem zu tun haben und daher noch kein

Ja, es ist echt die H=F6lle los....

fr

--=20
    Debian GNU/Linux|Hurd Infos und CDs: http://www.openoffice.de[/linux/]
    i386 / powerpc / alpha / m68k / sparc / arm  -  2.1 / 2.2 / 3.0 / ...
GPG Key:887EB817 2000-12-12 FD97 87F0 A948 E412 E2AF  F742 5F9D D632 887E B=
817
PS. Yes - it's free of any minix code, and it has a multi-threaded fs. - Li=
nus


--SWTRyWv/ijrBap1m
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Weitere Infos: siehe http://www.gnupg.org

iEYEARECAAYFAjwL0PgACgkQX53WMoh+uBcLzQCeM/7R2HPe7awlCljPwDRZzoun
QvIAnRTtvXHj91kWO5tPx1yzLsh5l9mg
=uDQT
-----END PGP SIGNATURE-----

--SWTRyWv/ijrBap1m--

From aleks@sailtraining.de  Thu Dec  6 08:09:10 2001
From: aleks@sailtraining.de (Alexander Stielau)
Date: Thu, 6 Dec 2001 09:09:10 +0100
Subject: [buug-l] Stammtisch, 07.12.01?
In-Reply-To: <20011203135215.A1839@miwie.in-berlin.de>
References: <20011203135215.A1839@miwie.in-berlin.de>
Message-ID: <20011206090910.A28120@linux-ag.de>

Am Mon, Dez 03, 2001 at 01:52:15 +0100 schrieb Michael Wiedmann:

> Vorschlag: Freitag, 07.12.01, ab 18:30
> Ort:       wie immer, Mexikaner am Schlesischen Tor
> 
> Rückmeldung an die Liste erbeten.

*seufz* Latürnich komme ich auch.

> ... noch ganz entspannt vom Urlaub ...

Naja, geht so.

Aleks
-- 
                 Der Schrauber schafft, der Hebel waechst, 
                 es steigt die Kraft, die Schraube aechzt.	
                 Zu spaet merkt erst die Grosshirnrinde - 
                 die Schraube trug ein Linksgewinde.

From aleks@sailtraining.de  Mon Dec 17 18:29:49 2001
From: aleks@sailtraining.de (Alexander Stielau)
Date: Mon, 17 Dec 2001 19:29:49 +0100
Subject: [buug-l] Umstellung auf ssh v2
Message-ID: <20011217192949.B9520@sailtraining.de>

Hallo Angelika, hallo Jungs!

Da SSH Protokollversion 1 immer wieder ein Quell der Freude und des
Exploitens ist, wird coredump.buug.de in kurzer Zeit nur noch via SSH
Protokollversion 2 erreichbar sein.

Da ein großer Teil von den Leuten, die auf coredump einen Account
haben, auf dieser Liste sind, zweckenfremde ich diese mal kurz dafür,
um Euch das mitzuteilen. 
   Noch keinen Account, aber einen haben wollen?
   -> Mail mit einem SSH2-Key und dem bevorzugten Loginnamen an Aleks.

Der Rechner preferiert jetzt schon Protokoll zwei, wer sich auf altem
Wege, also "ssh username@buug.de" einloggen will, kommt nicht rein,
die Fehlermeldung ist erst bei einem -v-Versuch klar.
Um zum Key hinterlegen noch SSH Protokoll 1 verwenden zu können, bitte
"ssh -1 username@buug.de" verwenden.

Um einen gültigen SSH Protokoll 2 Key zu erzeugen, ruft man auf einem
vertrauenswürdigen Rechner ein geeignet¹ aktuelles ssh-keygen mit der
Option -t dsa auf. /Bitte/ verwendet eine 'starke' Passphrase.
Dabei entstehen dann in ~/.ssh die Dateien id_dsa und id_dsa.pub. 

Den Public-key überträgt man mit scp auf coredump, und fügt ihn
der Datei .ssh/authorized_keys hinzu:

scp -1 ~/.ssh/id_dsa.pub username@buug.de:~/.ssh/key2
ssh -1 username@buug.de cat .ssh/key2 >> .ssh/authorized_keys

Auf coredump wird OpenSSH Version 3 verwendet, eine paralelle Nutzung
von knownhost2, authorized_keys2 und so weiter ist nicht mehr
notwendig.
ssh-agent kann mit SSH-v2-Keys genauso umgehen, wenn diese beim ssh-add
explizit genannt werden, also 'ssh-add .ssh/id_dsa'.

Rückfragen bitte an admins@buug.de

Aleks

¹ Also eine SSH-Version, die Protokoll 2 beherrscht. 

Resourcen:
http://www.securityfocus.com/archive/1/161150
http://www.openssh.com
-- 
		 Der Schrauber schafft, der Hebel waechst, 
                 es steigt die Kraft, die Schraube aechzt.      
                 Zu spaet merkt erst die Grosshirnrinde - 
                 die Schraube trug ein Linksgewinde.

From aleks@sailtraining.de  Mon Dec 17 18:42:45 2001
From: aleks@sailtraining.de (Alexander Stielau)
Date: Mon, 17 Dec 2001 19:42:45 +0100
Subject: [buug-l] PCMCIA, Skript =?iso-8859-1?Q?ausf=FChren?=
 =?iso-8859-1?Q?=2C_iptables_f=FCr_Anf=E4nger?=
Message-ID: <20011217194245.C9520@sailtraining.de>

Da ich gerade am Drücker sitze:

Ich möchte nach dem Mounten einer PCMCIA-Karte ein Skript
ausführen. Wo trage ich das ein? So ungefähr analog zu /etc/ppp/ip-up,
dachte ich mir.

In /etc/pcmcia/ finde ich nichts wirklich passendes, im PCMCIA-Howto
auch nicht.
Ich möchte je nach gesteckter Karte unterschiedliche Aktionen
ausführen, beim Einstecken einer wlan-Karte z.B. mein IPsec starten,
beim Einstecken einer Netzwerkkarte iptables, nach dem Einstecken
einer CF-Card diese mounten. Und noch 20 Sachen mehr...

Aleks

Wen es interessiert: Unter http://buug.de/~aleks/iptables gibt es ein
iptables-Regelwerk für den Hausgebrauch. Ich habe versucht, das, was
ich dort tue, einigermaßen sinnvoll zu kommentieren, weil es vorallem
iptables-Anfängern dienen soll.

Eine nächste Version ist bereits in Arbeit, bei der die Konfiguration
in einem Extrafile erledigt wird - dadurch wirds übersichtlicher.

Dazu wird es dann auch eine LAL geben. Nach Weihnachten.

A.
-- 
		 Der Schrauber schafft, der Hebel waechst, 
                 es steigt die Kraft, die Schraube aechzt.      
                 Zu spaet merkt erst die Grosshirnrinde - 
                 die Schraube trug ein Linksgewinde.

From aleks@sailtraining.de  Tue Dec 18 23:09:46 2001
From: aleks@sailtraining.de (Alexander Stielau)
Date: Wed, 19 Dec 2001 00:09:46 +0100
Subject: [buug-l] Umstellung auf ssh v2
In-Reply-To: <20011217192949.B9520@sailtraining.de>
Message-ID: <20011219000946.A7792@sailtraining.de>

Am Mon, Dez 17, 2001 at 07:29:49 +0100 schrieb Alexander Stielau:

> ssh -1 username@buug.de cat .ssh/key2 >> .ssh/authorized_keys

Das ist latürnich flasch, Der Befehl muß in Tüddel. Also

ssh -1 username@buug.de "cat .ssh/key2 >> .ssh/authorized_keys"

Karl-Heinz hat ein Diskussionspaper zum Thema verfaßt, ich poste es
mal in Auszügen hier. Ich hätte wirklich gerne eine Diskussion hier
auf der Liste zu diesem Thema. 


,----
| From: Karl-Heinz Haag <khaag@linux-ag.com>
|
| Aus erneut gegebenem Anlaß ganz aktuell:
| SSH ist vulnerable -- Es gibt mehrere ROOT-Kits und Exploits
| 		      
| WAS TUN? 
| -Antwort: NUR noch die SSH Protokoll-Version 2 verwenden!
| 
| 1. Durch exploits betroffen ist SSH in der *Protkoll* Version *1* 
| 	Die neuere *Protokoll*-Version *2* ist bis jetzt nicht exploitable.
| 	
| 	Version 2 von SSH ist von Grund auf neu implementiert. 
| 	Version 1 und 2 sind *nicht* kompatibel zueinander; sowohl auf 
| 	Server- als auch auf der Client-Seite.
| 	
| 2. Linux-Systeme verwenden meistens OpenSSH
|    	OpenSSH beherrscht (dank Markus Friedl) seit 4.5.2000 _beide_ Protokolle.
| 	http://www.openssh.org/goals.html
| 
| 3. Default-Installationen von Linux-Systemen (+ssh-keygen auf User-Seite) 
|    aktivieren durch die Konfiguration das ALTE (unsichere) Protokoll mit OpenSSH!  
|    		Dies wohl zu dem Zweck, abwärtskompatibel zu sein. 
| 		OpenSSH macht es uns hier eindeutig zu leicht, beim unsicheren
| 		alten Protokoll zu bleiben.
|    
| 3. Wie bei jedem anderen Netzwerkprotokoll treten bei SSH-Verbindungen ein 
|    SERVER und ein CLIENT in Aktion. 
|    Es sind weiterhin die Server-keys und die keys des Users im Spiel. 
|    
| 		Der Server (sshd) wartet auf Verbindungsanfragen; der 
| 		Client (ssh) fragt einen Verbindungsaufbau an. 
|           keys: Server und Client identifizieren sich gegenseitig mit Ihren 
|        	        HostKeys und handeln einen gemeinsamen Sitzungsschlüssel aus.
| 	        Mit dem public key des Users werden die eigenen Nachrichten
|                 verschlüsselt, die ssh mittels des private keys entschlüsselt. 	
| 
| 
| NOTWENDIGE UMSTELLUNGSMASSNAHMEN; Migration Version1 --> Version2
| Hier sind sowohl die Server- als auch Clientseite zu berücksichtigen. 
| Die hinterlegten keys der Protokoll-Version 1 müssen überall erneuert werden
| 
| 5. SERVER --> sshd sicher machen -- Aufgabe von root
|    Konfigurationsdatei in /etc/ssh/sshd_config anpassen. 
|    	
| 	Die sicherheitsrelevanten Einträge in sshd_config:
| 	Protocol 2,1	# erzwingt zunächst Connect mit Protokoll 2; Fallback nach 1
| 			# Wenn alle User-keys auf 2 umgestellt sind, 
| 			# kann später (bald) die 1 entfernt werden
| 	HostKey /etc/ssh/ssh_host_key	    # der HostKey des Protokoll 1
| 	HostKey /etc/ssh/ssh_host_rsa_key   # RSA HostKey des Protokolls 2
| 	HostKey /etc/ssh/ssh_host_dsa_key   # DSA HostKey des Protokolls 2
| 	
| 	X11Forwarding no
| 	PasswordAuthentication no	    # zur Sicherheit!!, damit jeder
| 					    # auch wirklich keys zum Login verwendet
| 					    # Passwort-Login ist lokal exploitable!
|     Nach den Änderungen sshd neu starten. 
| 
| 6. CLIENT --> ssh neu einstellen -- Aufgabe jedes Users
| 	a) Neuen SSH2-kompatiblen key erzeugen
| 		
| 		ssh-keygen -t dsa
| 		
| 	    	Der massgebliche Abschnitt der manpage hierzu:	
| 		ssh-keygen generates, manages and converts authentication keys for
|      		ssh(1).  
| 		ssh-keygen defaults to generating a RSA1 key for use by SSH pro­
|      		tocol version 1. (sic!,KHH)  
| 		Specifying the -t option instead creates a key for use
|      		by SSH protocol version 2.
| 	
| 	   Auf jeden Fall sollte man dabei eine Passphrase übergeben; mit
|            dieser wird der private key verschlüsselt und ist dadurch zur Verwendung
|            von unautorisierten Personen einigermaßen sicher.
| 				
| 	b) Erzeugt wird das SSH-Protokoll2-kompatible Schlüsselpaar
| 		~/.ssh/id_dsa
| 			und
| 		~/.ssh/id_dsa.pub
| 	   Den public key kann man nun an die Datei ~/.ssh/authorized_keys im
|            gewünschten Zielsystem anhängen. 
| 	   Bei nicht ganz neuen OpenSSH-Versionen (vor 3.0.1p1) kann es sein,
| 	   daß man die Datei ~/.ssh/authorized_keys2 verwenden muß. 
| 
| 7. VERBINDUNGSAUFNAHME mittels SSH Version 2 
| 	Wirklich sichergehen, daß man sich mit dem Zielsystem via Version 2
| 	verbindet (was man sollte) kann man durch: 
| 
| 		ssh -2 username@zielsystem	(zusätzliches -v zeigt, was passiert)  
| 
| 	Eindeutig erkennbar ist die Verbindung mittels Protokollversion 2 bei
| 	Verwendung der Option -v (verbose) an dem String: 
| 		"ssh-userauth2 successful: method publickey"
| 	Zusatz: 
| 	Das Anlegen einer ~/.ssh/config -Datei mit default-Eintrag, ssh v2 zu
| 	benutzen, hat im Selbsttest _nicht_ funktioniert. 
| 
| 8. ERLEICHTERUNGEN: ssh-agent + ssh-add nutzen
| 	Damit man nicht bei jeder Verbindung zu einem ssh-server seine
| 	Passphrase aufs Neue angeben muß, kann man mit dem ssh-agent arbeiten. 
| 	Das geht aus einem Xterm heraus so:	
| 		
| 		ssh-add ~/.ssh/id_dsa
| 		  Enter passphrase for id_dsa: <passphrase eingeben> 
| 		  Identity added: id_dsa (id_dsa)
| 
| 	Von nun an ist es während der laufenden X-Session ohne Angabe der 
| 	passphrase möglich, sich mit 'ssh -2 username@host' auf andere Rechner 
| 	einzuloggen. 
| 	Bei Shell-Benutzung (ohne X) bedient man sich des ssh-agents so: 
| 		ssh-agent $SHELL
| 		ssh-add ~/.ssh/id_dsa
| 		 (weiter wie oben)
| 		 
| 9. WINDOWS-Spezifika
| 	Durch einen Kunden war heute zu erfahren, daß Client-Programme putty/winscp 
| 	keinen dsa-key erzeugen können. [für OpenSSH _die_ bevorzugte Schlüsselmethode] 
| 	Die sshd-Server sind jedoch in der Grundeinstellung so konfiguriert, 
| 	daß sie mit rsa-keys von clients umgehen können müßten. 
| 	Das schließe ich aus der Zeile: HostKey /etc/ssh/ssh_host_rsa_key 
| 	in den /etc/ssh/sshd_config auf aktuellen Linux-Installationen.
| 
| 
| **ADDONS und weitere Informationen**	(wenn Muße ist ...) 
| 
| Nur noch SSH2 benutzen?
| http://www.employees.org/~satch/ssh/faq/ssh-faq-1.html#ss1.12
| 1.12 . Shouldn't I be using only SSH2?
| There are structural weaknesses in SSH1 which leave it open to additional
| attacks 
|      SSH1 is subject to a man-in-the-middle attack 
|      SSH1 has more supported platforms 
|      SSH1 supports .rhosts authentication (it's against the draft for SSH2 
|      SSH1 has more diverse authentication support (AFS, Kerberos, etc.) 
|      Performance for SSH2 is not equal to SSH1 
| 
| Unterschiede zwischen SSH Protokoll 1 und 2 
| http://www.employees.org/~satch/ssh/faq/ssh-faq-1.html#ss1.8
| 1.8 What is the difference between SSH1 and SSH2?
| The difference between SSH1 and SSH2 is they are two entirely different
| protocols. SSH1 and SSH2 encrypt at different parts of the packets, and SSH1
| uses server and host keys to authenticate systems where SSH2 only uses host
| keys. SSH2 is a complete rewrite of the protocol, and it does not use the
| same networking implementation that SSH1 does. Also, SSH2 is more secure. 
| 
| Because of the different protocol implementation, they are not compatible. 
| 
| In a nutshell, SSH2 is a rewrite of the SSH1 protocol, with improvements to
| security, performance, and portability. 
| 
| 	Die obigen Zitate beziehen sich auf die kommerziellen Varianten von SSH1 und
| 	SSH2 - nicht auf OpenSSH. 
| 	OpenSSH ist eine eingenständige Weiter-/Neuentwicklung, die auf der von 
| 	ssh.com [© SSH Communications Security] freigegebenen Version 1.3(?) aufbaut. 
| 	Alle _protokoll_-bezogenen Aussagen betreffen jedoch auch die
| 	OpenSSH-Implementierung.
| 	Beim aktuellen OpenSSH ist es eine Frage der *Konfiguration*, welches Protokoll
| 	verwendet wird. Das Nähere dazu ist oben ausgeführt.
| 
| Ein schon älterer exploit von SSH protocol 1 ist hier beschrieben: 
| http://www.securityfocus.com/archive/1/161150 
| Es gibt weitere (neuere). 
| U.a. kann man mit dsniff (-->sshmitm) Verbindungaufnahmen Client-Server
| kapern und/oder mithören. Mit Protokoll 2 kann dsniff das jedoch nicht.  
| http://www.monkey.org/~dugsong/dsniff/faq.html#How do I sniff / hijack HTTPS / SSH connections 
| 
| Die Exploitbarkeit von eingeschalteter PasswordAuthenitcation kann gefunden
| werden über die Stichworte "uselogin exploit" auf www.google.com
`----

Wer das gelesen hat und sich mal in die zitierten Links einliest,
dem wird wahrscheinlich auch etwas die Muffe gehen. 

Mir z.B. war zwar klar, das es immer wieder ssh-Probleme gab, ich bin
aber nie ernsthaft der Ursache gefolgt, sondern habe einfach immer
eine aktuellere Version eingespielt, die aber - wie ich nun weiß - durch die zitierte
Abwärts-Kompatibilität zumindest prinzipiell auch gefährdet ist.

Aleks
(Das Reply-to der Liste zeigt immer auf den Autor, für eine
Listendiskussion an buug-l@buug.de antworten)
-- 
		 Der Schrauber schafft, der Hebel waechst, 
                 es steigt die Kraft, die Schraube aechzt.      
                 Zu spaet merkt erst die Grosshirnrinde - 
                 die Schraube trug ein Linksgewinde.

From aleks@sailtraining.de  Tue Dec 18 23:12:15 2001
From: aleks@sailtraining.de (Alexander Stielau)
Date: Wed, 19 Dec 2001 00:12:15 +0100
Subject: [buug-l] PCMCIA, =?iso-8859-1?Q?Skript?=
 =?iso-8859-1?Q?_ausf=FChren=2C_iptables_f=FCr_Anf=E4nger?=
In-Reply-To: <20011217194245.C9520@sailtraining.de>
Message-ID: <20011219001215.B7792@sailtraining.de>

Am Mon, Dez 17, 2001 at 07:42:45 +0100 schrieb Alexander Stielau:

> Wen es interessiert: Unter http://buug.de/~aleks/iptables gibt es ein
> iptables-Regelwerk für den Hausgebrauch. Ich habe versucht, das, was
> ich dort tue, einigermaßen sinnvoll zu kommentieren, weil es vorallem
> iptables-Anfängern dienen soll.
> 
> Eine nächste Version ist bereits in Arbeit, bei der die Konfiguration
> in einem Extrafile erledigt wird - dadurch wirds übersichtlicher.

So, ist erledigt. Bitte testen. 
Unter http://buug.de/~aleks/iptables/testing gibt es nun eine Version, die
eine extra Konfigurations-Datei verwendet. 

Aleks
-- 
		 Der Schrauber schafft, der Hebel waechst, 
                 es steigt die Kraft, die Schraube aechzt.      
                 Zu spaet merkt erst die Grosshirnrinde - 
                 die Schraube trug ein Linksgewinde.

From paulsen@mobile.in-berlin.de  Wed Dec 19 21:52:33 2001
From: paulsen@mobile.in-berlin.de (Holger Paulsen)
Date: 19 Dec 2001 22:52:33 +0100
Subject: [buug-l] Umstellung auf ssh v2
In-Reply-To: Alexander Stielau's message of "Wed, 19 Dec 2001 00:09:46 +0100"
References: <20011219000946.A7792@sailtraining.de>
Message-ID: <87vgf2g9ni.fsf@mobile.in-berlin.de>

Alexander Stielau <aleks@sailtraining.de> writes:

> Karl-Heinz hat ein Diskussionspaper zum Thema verfaßt, ich poste es
> mal in Auszügen hier. Ich hätte wirklich gerne eine Diskussion hier
> auf der Liste zu diesem Thema.

Karl-Heinzens Paper ist wirklich sehr interessant; und ich
würde mir wünschen, wenn so etwas in der Endfassung auch auf
buug.de zu finden wäre.

Um wirklich darüber diskutieren zu können, bräuchte man
keine Auszüge, sondern das Große Ganze. Ich vermute, daß Du,
Aleks, den ursprünglichen Text verantwortungsbewußt gekürzt
hast. Gut so.


  Holger



From mw@miwie.in-berlin.de  Fri Dec 21 18:01:15 2001
From: mw@miwie.in-berlin.de (Michael Wiedmann)
Date: Fri, 21 Dec 2001 19:01:15 +0100
Subject: [buug-l] FYI: DocBook Toolchain Overview
Message-ID: <20011221180115.GA2666@miwie.in-berlin.de>

Hallo,

als Nachtrag zur LAL "DocBook für Anfänger" passt ganz gut ein Bildchen,
das Nik Clayton vom FreeBSD Documentation Project erstellt hat und das
sehr übersichtlich das Zusammenwirken der diversen Tools aufzeigt. 

Auch wenn es an wenigen Stellen FreeBSD spezifisch ist und die diversen
Frontends (z.B. sgmltools-lite) die Komplexität ja gerade vor dem
Endanwender verbergen sollen, ist es IMO sehr informativ:

Siehe: http://people.freebsd.org/~nik/sgmlxml.gif (ca. 45 kB)

Gruß
Michael
PS: Entgegen meiner Behauptung bei der o.g. LAL, dass es zukünftig keine
    DocBook SGML Version mehr geben wird, wurde kürzlich verlautbart,
    dass "irgendwie" aus der autorativen XML Version immer auch eine
    SGML Version generiert werden kann.
-- 
mw@miwie.in-berlin.de                              http://www.miwie.org
mw@miwie.org


From paulsen@mobile.in-berlin.de  Mon Dec 31 17:30:43 2001
From: paulsen@mobile.in-berlin.de (Holger Paulsen)
Date: Mon, 31 Dec 2001 18:30:43 +0100
Subject: [buug-l] Guten Rutsch!
Message-ID: <20011231183043.C795@mobile.in-berlin.de>

Hallo Zielgruppe!


Ich liebe kleine, übersichtliche Mailinglisten. Euch allen:
Einen schönen Silvesterabend und ein genauso schönes,
erfolgreiches und interessantes Jahr 2002!


Alles Gute

  Holger


