Hallo allerseits!
Ich brauche mal Nachhilfe bzw. Tipps bei folgendem Problem: Erkennbar ist, dass an einem Linux-Server mit Samba 3.5.7 (SuSE 11.4) manchmal keine Anmeldung möglich ist, ein andermal das Profil nicht geladen wird und man damit kaum arbeiten kann. Problem 1 ist gefunden: Die Nutzerprofile hatte ich auf eine zweite Festplatte ausgelagert. Diese SATA-Festplatte ist aber gegenüber dem SAS-Raid schneckenlahm (etwa 80MB/s gegenüber 240MB/s) und bremst damit bei paralleler Anmeldung mehrerer Schüler natürlich aus.
Frage 1: Wie gefährlich ist es, ein Resize von ext4 vorzunehmen, wenn der Server läuft (aber niemand angemeldet ist), um Platz für eine weitere Partition zu schaffen?
Der zweite Teil des Problems liegt in dropped packets auf den Netzwerkkarten. Es kann sein, dass ich hier ein Verständnisproblem habe. Daher etwas ausführlicher zum Netzwerkaufbau: Es gibt 4 Netzwerk-Interfaces (Intel 1000er-Karten). Aus technischen Gründen ist ein Interface (eth3) auf 100MBit gedrosselt und landet am Switch auf einem getrennten VLAN (Wiederherstellung vom Laptops mit 100MBit-Karte per Multicast-Netzwerk). Die Interfaces eth0-eth2 sind gebündelt, das Netzwerkinterface ist also bond0. Was auffällt: Die Zahl der dropped packet von eth3 und bond0 stimmt (fast) überein (unterscheiden sich um genau 100), beide wachsen im exakt gleichen Maß. An den realen Interfaces eth0-eth2 gibt es keine "dropped"-Pakete, der angezeigte Durchsatz ist völlig in Ordnung. Zwischen eth3 und bond0 ist natürlich ein forward-Regel eingebaut. Auf der Firewall ist laut iptables -L keine Regel mit DROP. Die SuSE-Firewall ist aus, eine manuelle Regel sorgt dafür, dass zwei sezielle Rechner Samba-Zugriffe mit Reject beantwortet bekommen (ist notwendig).
Frage 2: Warum gibt überhaupt ca. 1% Netzwerkpakete bei "dropped"? Wo werden die möglicherweise gedropped? Gibt es einen Grund, warum eth3 und bond0 fast identische Zahlen dabei haben?
um nicht zu sehr zu raten die Zahlen von bond0: ---------------------- schnipp ------------------------------------ RX packets:73486162 errors:0 dropped:19165992 overruns:0 frame:0 TX packets:71049331 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 Sendewarteschlangenlänge:0 RX bytes:54676801251 (52143.8 Mb) TX bytes:68091939812 (64937.5 Mb) ---------------------- schnapp ------------------------------------
Bin für jede gute Idee dankbar
Reiner
Am 03.12.2011, 10:34 Uhr, schrieb Reiner Klaproth klaproth@online.de:
Hallo Reiner,
snip
Frage 1: Wie gefährlich ist es, ein Resize von ext4 vorzunehmen, wenn der Server läuft (aber niemand angemeldet ist), um Platz für eine weitere Partition zu schaffen?
d.h. Du willst dafür bestehende Partitionen verkleinern? Ist nur 'offline' vorgesehen - siehe z.B. http://wiki.ubuntuusers.de/Dateisystemgr%C3%B6%C3%9Fe_%C3%A4ndern
Nutzt Du LVM?
Grüße,
Bernhard
Hallo!
Am Samstag, 3. Dezember 2011, 12:07:44 schrieb Bernhard Bittner:
Frage 1: Wie gefährlich ist es, ein Resize von ext4 vorzunehmen, wenn der Server läuft (aber niemand angemeldet ist), um Platz für eine weitere Partition zu schaffen?
d.h. Du willst dafür bestehende Partitionen verkleinern? Ist nur 'offline' vorgesehen
Bereits erledigt. Dienste stoppen - umount /home - gparted nutzen und machen lassen. Die Partition wurde ohne Datenverlust verkleinert, die neue Partition für die Profile eingerichtet. /etc/fstab anpassen und neu booten.
Die Frage bezog sich vor allem darauf, dass ich alles per ssh machen muss, ohne die zwei Tage physisch an den Server zu kommen.
Gruss Reiner
Hallo Rainer,
Reiner Klaproth klaproth@online.de (Sa 03 Dez 2011 10:34:34 CET):
Frage 1: Wie gefährlich ist es, ein Resize von ext4 vorzunehmen, wenn der Server läuft (aber niemand angemeldet ist), um Platz für eine weitere Partition zu schaffen?
Ungefährlich. Denn es geht nicht. Du kannst ext{3,4} nur offline resizen, aber dann ist es ungefährlich, wenn man rechnen kann.
Der zweite Teil des Problems liegt in dropped packets auf den Netzwerkkarten. Es kann sein, dass ich hier ein Verständnisproblem habe. Daher etwas ausführlicher zum Netzwerkaufbau: Es gibt 4 Netzwerk-Interfaces (Intel 1000er-Karten). Aus technischen Gründen ist ein Interface (eth3) auf 100MBit gedrosselt und landet am Switch auf einem getrennten VLAN (Wiederherstellung vom Laptops mit 100MBit-Karte per Multicast-Netzwerk).
Die Interfaces eth0-eth2 sind gebündelt, das Netzwerkinterface ist also bond0. Was auffällt: Die Zahl der dropped packet von eth3 und bond0 stimmt (fast) überein (unterscheiden sich um genau 100), beide wachsen im exakt gleichen Maß. An den realen Interfaces eth0-eth2 gibt es keine "dropped"-Pakete, der angezeigte Durchsatz ist völlig in Ordnung.
Wie oft wird das eth3 gebraucht? Wenn ich den Zweck oben richtig verstehe, dann ja eher selten, oder?
Zwischen eth3 und bond0 ist natürlich ein forward-Regel eingebaut. Auf der Firewall ist laut iptables -L keine Regel mit DROP. Die SuSE-Firewall ist aus, eine manuelle Regel sorgt dafür, dass zwei sezielle Rechner Samba-Zugriffe mit Reject beantwortet bekommen (ist notwendig).
DROP in der Firewall hat mit dropped der Netzkarte m.E. nichts zu tun. Die dropped in der NIC könnten Empfängerüberläufe sein.
Frage 2: Warum gibt überhaupt ca. 1% Netzwerkpakete bei "dropped"? Wo werden die möglicherweise gedropped? Gibt es einen Grund, warum eth3 und bond0 fast identische Zahlen dabei haben?
Das ist merkwürdig. Gibt es Traffic, der mit beiden Karten etwas zu tun hat. VLANs machen auch manchmal komische Dinge. Ist das ein 802.1q VLAN?
Wie ist gebondet: Als Bündel und alle gemeinsam, oder wie? Ich denke, es gibt ja da verschiedene Bond-Modi.
Hallo!
Am Samstag, 3. Dezember 2011, 16:01:48 schrieb Heiko Schlittermann:
Frage 1: Wie gefährlich ist es, ein Resize von ext4 vorzunehmen, wenn der Server läuft (aber niemand angemeldet ist), um Platz für eine weitere Partition zu schaffen?
Ungefährlich. Denn es geht nicht. Du kannst ext{3,4} nur offline resizen, aber dann ist es ungefährlich, wenn man rechnen kann.
Richtig, habe ich nur falsch beschrieben. Man muss die Partition umounten, dann geht alles.
Die Interfaces eth0-eth2 sind gebündelt, das Netzwerkinterface ist also bond0. Was auffällt: Die Zahl der dropped packet von eth3 und bond0 stimmt (fast) überein (unterscheiden sich um genau 100), beide wachsen im exakt gleichen Maß. An den realen Interfaces eth0-eth2 gibt es keine "dropped"-Pakete, der angezeigte Durchsatz ist völlig in Ordnung.
Wie oft wird das eth3 gebraucht? Wenn ich den Zweck oben richtig verstehe, dann ja eher selten, oder?
Jaein. Neben den Laptops, die sonst per WLAN am Netz hängen gibt es noch LCD-Bildschirme mit integriertem Computer, die auch über dieses Interface gehen müssen. Witzigerweise haben die Gigabit-Netzwerkkarten, aber die PXE-Software für diese Karten kann nur 100MBit (hat mich damals Tage gekostet, das herauszufinden...)
Einen Reboot später weiß ich mehr: Jetzt zählt nicht mehr der Zähler an eth3 hoch, sondern der an eth2 (Weiß der Fuchs warum...) Jetzt verstehe ich aber die Zahlen: An eth2, das zu bond0 gebündelt ist, verschwinden RX-Pakete.
Die Frage, die ich jetzt klären muss: Warum verschwinden die Pakete und warum ausschließlich an eth2. Die andere Frage: Warum zeigte das ifconfig erst an eth3 statt eth2? Kernel SuSE-default zu OpenSuSE 11.4
Wie ist gebondet: Als Bündel und alle gemeinsam, oder wie? Ich denke, es gibt ja da verschiedene Bond-Modi.
Richtig. Ich hatte einige Anleitungen gelesen und vieles getestet. Am Ende hat es erst funktioniert, wenn man NICHTS vorher eingestellt hat und die Intel-Karten hat machen lassen. In dem Fall haben sich die Karten mit dem (HP ProCurve) Switch selbst geeinigt. Der schaltete seinerseits die Eingänge zum Bündel automatisch zusammen, wenn man keine Parameter angegeben hat. Mit Parameter gab es Probleme mal am Switch, mal mit den Karten....
Gruss Reiner
Am 03.12.2011, 18:00 Uhr, schrieb Reiner Klaproth klaproth@online.de:
Servus,
Am Samstag, 3. Dezember 2011, 16:01:48 schrieb Heiko Schlittermann:
Frage 1: Wie gefährlich ist es, ein Resize von ext4 vorzunehmen, wenn
der
Server läuft (aber niemand angemeldet ist), um Platz für eine weitere Partition zu schaffen?
Ungefährlich. Denn es geht nicht. Du kannst ext{3,4} nur offline resizen, aber dann ist es ungefährlich, wenn man rechnen kann.
Richtig, habe ich nur falsch beschrieben. Man muss die Partition umounten, dann geht alles.
ja, wenn man eine Partition zur Verfügung hat, die umounten im laufenden System mitmacht, geht es latürnich so wie Du es geschrieben hast.
Abgesehen von Kandidaten wie eben /home, ggf. noch /opt oder /srv hörts dann aber m.W. schon auf.
Nicht daß noch jemand durch 'es geht nicht' - 'dann geht alles' verwirrt wird ;-)
Seit ich mit nem ähnlichen Szenario zu tun hatte, bin ich begeisterter Nutzer von LVM (an dieser Stelle props an Dimitri Puzin, der mich da rangeführt hat :-).
Grüße,
Bernhard
Hallo!
Am Samstag, 3. Dezember 2011, 18:00:53 schrieb Reiner Klaproth:
Einen Reboot später weiß ich mehr: Jetzt zählt nicht mehr der Zähler an eth3 hoch, sondern der an eth2 (Weiß der Fuchs warum...)
Auch das ist erklärbar: Die Netzwerkkarten sind Intel-Serverkarten, die mit einem Baustein zwei Netzwerk-Interfaces anbieten. Somit sind also eth2 und eth3 physisch an einen Baustein gekoppelt (und haben dieselbe MAC-Adresse!). Daher hatte der Kernel das Problem, die Karten zuzuordnen. Darin steckt offenbar auch das Problem: Laut lspci haben diese Karten keinen Interrupt zugeteilt bekommen. Das ACPI-Management liefert als IRQ 66 und 76.
Fakt ist offenbar, dass Intel die Karten selbst auch als "Bündel" betreibt. Offenbar schaltet nicht nur eth3 auf 100MBit herunter, sondern parallel auch eth2. Das erklärt die verlorenen Pakete. Erster Würg-Around: Nur noch eth0 und eth1 sind auf bond0 gebündelt, denn diese funktionieren (auch eine Intel-Dual-Port-Serverkarte). Wahrscheinlich muss der Server eine weitere Netzwerkkarte erhalten für das 100MBit-Interface. Schön, dass so etwas nirgends ordentlich dokumentiert ist...
Gruss Reiner
Reiner Klaproth klaproth@online.de (So 04 Dez 2011 08:34:02 CET):
Hallo!
Am Samstag, 3. Dezember 2011, 18:00:53 schrieb Reiner Klaproth:
Einen Reboot später weiß ich mehr: Jetzt zählt nicht mehr der Zähler an eth3 hoch, sondern der an eth2 (Weiß der Fuchs warum...)
Auch das ist erklärbar: Die Netzwerkkarten sind Intel-Serverkarten, die mit einem Baustein zwei Netzwerk-Interfaces anbieten. Somit sind also eth2 und eth3 physisch an einen Baustein gekoppelt (und haben dieselbe MAC-Adresse!).
Gebündelt oder als Hub betrieben… wobei ich bei Serverkarten eher ersteres vermute, wiewohl ich das noch nie gesehen habe. Vielleicht kann man das in irgend einem BIOS beeinflussen. Denn intuitiv kommt mir das nicht vor. Wenn ich an einem Server zwei Ports sehe, dann würde ich auch davon ausgehen, daß ich zwei Ports (NICs habe).
Bist Du Dir sicher, daß die Dinger schon vor dem „enslaven“ in das Bond-Interface die selbe MAC haben?
Daher hatte der Kernel das Problem, die Karten zuzuordnen. Darin steckt offenbar auch das Problem: Laut lspci haben diese Karten keinen Interrupt zugeteilt bekommen. Das ACPI-Management liefert als IRQ 66 und 76.
Da sehe ich keinen Zusammenhang zur selben MAC.
Fakt ist offenbar, dass Intel die Karten selbst auch als "Bündel" betreibt. Offenbar schaltet nicht nur eth3 auf 100MBit herunter, sondern parallel auch eth2. Das erklärt die verlorenen Pakete.
Ach so, eth3 und eth2 sind ja nicht gemeinsam im Bond-Interface. Dann ist meine Frage von oben vielleicht auch Quatsch.
Das gleich der Chip beide Interfaces „runterzieht“, wenn man die Geschwindigkeit auf einem ändert, ist ja eine dolle Sache.
Erster Würg-Around: Nur noch eth0 und eth1 sind auf bond0 gebündelt, denn diese funktionieren (auch eine Intel-Dual-Port-Serverkarte). Wahrscheinlich muss der Server eine weitere Netzwerkkarte erhalten für das 100MBit-Interface. Schön, dass so etwas nirgends ordentlich dokumentiert ist...
Nun schon ☺
Hallo Heiko,
Am Sonntag, 4. Dezember 2011, 13:31:02 schrieb Heiko Schlittermann:
Bist Du Dir sicher, daß die Dinger schon vor dem „enslaven“ in das Bond-Interface die selbe MAC haben?
Inzwischen: JA (Früher hatte mir jemand erklärt: Das geht nicht, jedes Netzwerk-Interface hat eine eigene MAC) Das sieht so aus: lspci -v
02:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06) Subsystem: Intel Corporation PRO/1000 PT Dual Port Server Adapter Flags: bus master, fast devsel, latency 0, IRQ 66 Memory at ce240000 (32-bit, non-prefetchable) [size=128K] Memory at ce220000 (32-bit, non-prefetchable) [size=128K] I/O ports at 3000 [size=32] [virtual] Expansion ROM at c0100000 [disabled] [size=128K] Capabilities: [c8] Power Management version 2 Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+ Capabilities: [e0] Express Endpoint, MSI 00 Capabilities: [100] Advanced Error Reporting Capabilities: [140] Device Serial Number 00-15-17-ff-ff-dd-de-22 Kernel driver in use: e1000e
02:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06) Subsystem: Intel Corporation PRO/1000 PT Dual Port Server Adapter Flags: bus master, fast devsel, latency 0, IRQ 84 Memory at ce2a0000 (32-bit, non-prefetchable) [size=128K] Memory at ce280000 (32-bit, non-prefetchable) [size=128K] I/O ports at 3020 [size=32] [virtual] Expansion ROM at c0120000 [disabled] [size=128K] Capabilities: [c8] Power Management version 2 Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+ Capabilities: [e0] Express Endpoint, MSI 00 Capabilities: [100] Advanced Error Reporting Capabilities: [140] Device Serial Number 00-15-17-ff-ff-dd-de-22 Kernel driver in use: e1000e
08:00.0 Ethernet controller: Intel Corporation 82575EB Gigabit Network Connection (rev 02) Subsystem: Fujitsu Technology Solutions Device 1128 Flags: bus master, fast devsel, latency 0, IRQ 16 Memory at ce360000 (32-bit, non-prefetchable) [size=128K] Memory at ce340000 (32-bit, non-prefetchable) [size=128K] I/O ports at 4000 [size=32] Memory at ce300000 (32-bit, non-prefetchable) [size=16K] [virtual] Expansion ROM at c0200000 [disabled] [size=128K] Capabilities: [40] Power Management version 2 Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+ Capabilities: [60] MSI-X: Enable+ Count=10 Masked- Capabilities: [a0] Express Endpoint, MSI 00 Capabilities: [100] Advanced Error Reporting Capabilities: [140] Device Serial Number 00-19-99-ff-ff-82-f4-a2 Kernel driver in use: igb
08:00.1 Ethernet controller: Intel Corporation 82575EB Gigabit Network Connection (rev 02) Subsystem: Fujitsu Technology Solutions Device 1128 Flags: bus master, fast devsel, latency 0, IRQ 17 Memory at ce3c0000 (32-bit, non-prefetchable) [size=128K] Memory at ce3a0000 (32-bit, non-prefetchable) [size=128K] I/O ports at 4020 [size=32] Memory at ce304000 (32-bit, non-prefetchable) [size=16K] [virtual] Expansion ROM at c0220000 [disabled] [size=128K] Capabilities: [40] Power Management version 2 Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+ Capabilities: [60] MSI-X: Enable+ Count=10 Masked- Capabilities: [a0] Express Endpoint, MSI 00 Capabilities: [100] Advanced Error Reporting Capabilities: [140] Device Serial Number 00-19-99-ff-ff-82-f4-a2 Kernel driver in use: igb
Die Karte 02:00:X ist die Steckkarte mit eth0 und eth1, die Karte 08:00:X ist OnBoard mit eth2 und eth3. Jetzt ist eth2 nicht mit enslaved. Dennoch steht dieselbe "serial number" drin. Aktiviere ich die Karte eth2 mit einer beliebigen IP:
eth2 Link encap:Ethernet Hardware Adresse 00:19:99:82:F4:A2 inet Adresse:192.168.200.10 Bcast:192.168.200.255 Maske:255.255.255.0 inet6 Adresse: fe80::219:99ff:fe82:f4a2/64 Gültigkeitsbereich:Verbindung UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:11 errors:0 dropped:9 overruns:0 frame:0 TX packets:19 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 Sendewarteschlangenlänge:1000 RX bytes:913 (913.0 b) TX bytes:4435 (4.3 Kb) Speicher:ce360000-ce380000
eth3 Link encap:Ethernet Hardware Adresse 00:19:99:82:F4:A2 inet Adresse:192.168.1.1 Bcast:192.168.1.255 Maske:255.255.255.0 inet6 Adresse: fe80::219:99ff:fe82:f4a3/64 Gültigkeitsbereich:Verbindung UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:226 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 Sendewarteschlangenlänge:1000 RX bytes:0 (0.0 b) TX bytes:51319 (50.1 Kb) Speicher:ce3c0000-ce3e0000
Also nutzt der Kernel für BEIDE Karten die serial number aus dem PCI und die MAC ist in dem Fall gleich.
Keine Ahnung, womit das letztlich zusammen hängt.
Gruss Reiner
Hallo Reiner,
Bist Du sicher, dass Dir da so etwas wie UDEV nicht reinfunkt? Ich habe mich gerade auf mehreren Systemen mit Intel Multiportkarten umgesehen, dort haben alle Schnittstellen immer eigene MAC. Leider war bei meinen Referenzen eben nicht genau Dein Modell dabei, aber ich höre von sowas zum ersten Mal.
Mit freundlichen Grüßen / Kind regards Ronny Seffner
Hallo miteinander,
Kurz zusammengefasst die Erkenntnisse, die letztlich mein Problem gelöst haben. 1. Status jetzt: bond0 Link encap:Ethernet Hardware Adresse 00:15:17:DD:DE:22 inet Adresse:172.16.0.20 Bcast:172.16.255.255 Maske:255.255.0.0 inet6 Adresse: fe80::215:17ff:fedd:de22/64 Gültigkeitsbereich:Verbindung UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1 RX packets:193552957 errors:0 dropped:10 overruns:0 frame:0 TX packets:85113290 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 Sendewarteschlangenlänge:0 RX bytes:209304300835 (199608.1 Mb) TX bytes:6416975258 (6119.7 Mb)
Die 10 dropped packets stammen vermutlich aus der Initialisierungphase am Switch, denn die verteilen sich gleichmäßig auf eth0-eth3 (wobei eth1 keine Pakete gedropt hat, denn dieses Interface wird vom Treiber als erstes initialisiert, die Nummerierung ändert UDEV).
Das Problem bestand am Switch selbst, den die Netzwerkfirma eingerichtet hat. Der Switch muss natürlich die Bündelung der Netzwerkkarten seinerseits richtig unterstützen. Dazu dient LACP, um per 802.3ad zu bündeln.
Nun begab es sich, dass jene Firma zwar einen wilden Wuchs an Kabeln in den Switch führte, jedoch nirgends etwas dokumentierte. So war weder an den Kabeln, noch an Farben o.ä. ersichtlich, was wohin führte. Als ordnungsliebender Mensch davon gefrustet, entschied ich mich, die Kabel neu zu stecken, mit Aufklebern zu versehen und die Portbelegung des Switch sauber zu dokumentieren (OO-Tabelle). Laut der Beschreibung von HP ist LACP normalerweise bei "Server-Einschüben" (VL-Modul mit LWL-Anschlüssen) per AUTO aktiviert. Bündelung wird damit automatisch erkannt und vom Switch unterstützt. An anderen Anschlüssen kann es zudem aktiviert werden. Nun hatte jene Firma an einigen Ports dieses LACP aber deaktiviert. Eth2 und eth3 steckten also auf Ports, die somit nicht mehr automatisch gebündelt wurden. Da sie aber von UDEV und dem Bonding-Kerneltreiber gebündelt wurden, sendete der Switch die an anderen Port gesendeten Pakete wieder zurück - und wurden korrekt abgewiesen (also dropped).
Dummerweise kommt man an diese Einstellungen nicht per Web-Interface heran, nur per Telnet oder serieller Konsole. Dadurch ist der Fehler erst so spät aufgefallen.
Bist Du sicher, dass Dir da so etwas wie UDEV nicht reinfunkt? Ich habe mich gerade auf mehreren Systemen mit Intel Multiportkarten umgesehen, dort haben alle Schnittstellen immer eigene MAC.
Auch dass kann ich erklären: Wiederum mit dem Switch. Die Netzwerkkarten, die jetzt ohne Aktivierung in das Bonding mit einer IP versehen wurden, steckten auf Ports, die LACP nicht auf Auto, sondern auch AKTIV stehen hatten. Damit bündelte der Switch irgendwie diese Karten und entweder Kernel-Treiber oder UDEV (oder beide?) erkannten offenbar diese erzwungene Bündelung. Nachdem ich einen Port umgesteckt hatte, bekamen die beiden Interfaces korrekt verschiedene MAC-Adressen verpasst (die natürlich aufeinander folgten).
Fazit: Trau keiner Netzwerkfirma, die nicht einen Ordner mit Dokumentation übergeben hat. Hinterher sucht man sich dumm und dämlich...
Gruss Reiner
lug-dd@mailman.schlittermann.de
-
Bernhard Bittner -
Heiko Schlittermann -
Reiner Klaproth -
Ronny Seffner