Probleme beim Entdecken der Drucker

[Rüdiger Kupper]

Die Liste unserer Drucker wird vom paedml per Broadcast an alle Clients verteilt. Auf den Clients ist der "cups-browsed"-daemon für das Entdecken verantwortlich. Das hat in den letzten Tagen mal wieder nicht richtig funktioniert.
Beim Ansehen von /etc/cups/cups-browsed.conf fällt auf, dass die inzwischen deutlich mehr Optionen kennt als früher. Insbesondere die Auswahl der erlaubten Protokolle (CUPS und DNSSD und LDAP), aber auch die Option "BrowsePoll", die direkt beim Server anfragt, statt auf den Broadcast zu warten.
Hie sollten wir mal ein wenig experimentieren, welche Einstellung stabil funktioniert.

[Rüdiger Kupper]

Ich habe eben auf allen Rechnern den cups-browsed gestoppt, die printers.conf gelöscht, Service wieder gestartet. Danach sollten alle Rechner nach und nach die Drucker entdecken. Ca. 15 Minuten später ergibt sich dieses Bild (gezeigt ist für jeden Lehrernetzclient die Anzahl bekannter Drucker -- 16 sollten es sein):

[1] 10:26:14 [SUCCESS] rechner-lz-01
16
[2] 10:26:14 [SUCCESS] rechner-lz-jas
16
[3] 10:26:14 [SUCCESS] rechner-lz-06
16
[4] 10:26:14 [SUCCESS] rechner-sp3-5-36
0
[5] 10:26:14 [SUCCESS] rechner-lz-03
16
[6] 10:26:14 [SUCCESS] rechner-lz-05
16
[7] 10:26:14 [SUCCESS] rechner-lz-02
16
[8] 10:26:14 [SUCCESS] rechner-lz-04
16
[9] 10:26:14 [SUCCESS] rechner-sp2-5-23
0
[10] 10:26:14 [SUCCESS] rechner-5-50
0
[11] 10:26:14 [SUCCESS] rechner-lz-roml
16
[12] 10:26:14 [SUCCESS] rechner-lz-kup
16
[13] 10:26:14 [SUCCESS] rechner-1-sp0-5-10
0
[14] 10:26:14 [SUCCESS] rechner-2-sp0-5-10
0
[15] 10:26:14 [SUCCESS] rechner-sp4-5-47
0
[16] 10:26:14 [SUCCESS] rechner-3-12
0
[17] 10:26:14 [SUCCESS] rechner2-3-07
0
[18] 10:26:14 [SUCCESS] rechner-5-56
16
[19] 10:26:14 [SUCCESS] rechner3-3-07
0

Es fällt auf, dass die Rechner im Lehrerzimmer die Drucker gefunden haben, auch rechner-5-56, die anderen aber nicht. Passt das irgendwie zur Netzwerkstruktur?

[Rüdiger Kupper]

Von den Schülerrechnern haben übrigens bisher nur zwei(!) die Drucker gefunden, auf allen anderen ist die printers.conf noch leer...
Also kann man auf alle Fälle sagen, dass das Browsing nicht sehr gut funktioniert. Mal sehen, ob sie sich berappeln.

[Rüdiger Kupper]

Wäre es möglich, dass die Broadcast-Pakete in bestimmten Switchen stecken bleiben?

[bau]

Eigentlich eine komisch Konstellation, denn die Verbindung von Serverraum in dei U's ist besser, als die Verbindung ins Lehrerzimmer.

[Rüdiger Kupper]

Dann liegts vielleicht am anderen Subnetz?

[bau]

Die U's sind im gleichen Subnetz wie das LZ

[Rüdiger Kupper]

Aber das eine ist doch Lehrernetz und das andere Schülernetz...?

Am Donnerstag, 10. November 2016 16:47:00 CET schrieb Kepler-Trac 
<trac@kg-fds.de>:

[bau]

Äh nein, z.B. rechner-sp2-5-23 ist Lehrernetz!

[bau]

Problematisch könnte eine Route sein, die ich eingetragen habe, die ich aber schon immer nicht ganz verstehe (die obere):

10.16.112.128 10.16.112.126 255.255.255.128 UG 0 0 0 eth0
10.16.112.128 * 255.255.255.128 U 0 0 0 eth2

Ich denke fast, dass Messages ins zweite VLAN, welches an eth2 hängt auch über das NIC direkt ins VLAN gehen sollten und nicht über die Router-Adresse (10.16.112.126) des Cisco0027 im ersten VLAN. Ich habe die überflüssige Route jetzt mal rausgenommen - mal beobachten.

Hintergrund:

VLAN1: eth0: 10.16.112.4
VLAN2: eth2: 10.16.112.252

VLAN3 und VLAN4 über cisco0027 im VLAN1: 10.16.112.126

cisco0027 hat in allen vier VLAN jeweils eine Router-Adresse:

• VLAN1: 10.16.112.126
• VLAN2: 10.16.112.254
• VLAN3: 10.16.113.126
• VLAN4: 10.16.113.254

Source-Routing:

32764:	from 10.16.112.128/25 lookup RTeth2   # wenn Paket aus VLAN2 
32765:	from 10.16.112.0/25 lookup RTeth0     # wenn Paket aus VLAN1

# ip route list table RTeth0
default via 10.16.112.126 dev eth0 
10.16.112.0/25 dev eth0  scope link  src 10.16.112.4 

# ip route list table RTeth2
default via 10.16.112.254 dev eth2 
10.16.112.128/25 dev eth2  scope link  src 10.16.112.252 

[bau]

So wie ich die Sache grade einschätze, haben die neueren Versionen von CUPS massiv Probleme beim browsen von älteren Servern - eine Quelle spricht vor allem von Ubuntu 16.04 in Zusammenarbeit mit 12.04.

[bau]

Problembehebung (WorkAround): Auf allen Lehrernetz-Clients in der /etc/cups/cups-browsed.conf:

• BrowseOrder Allow,Deny damit werden keine Server mehr abgefragt
• alle BrowseAllow-Direktiven auskommentiert
• alle PPD vom Server aus /etc/cups/ppd nach /usr/share/cups/model gelegt
• per lpadmin Kopierer und LaserLZ hinzugefügt:

     lpadmin -p Kopierer -v socket://10.16.112.202:9100 -m Kopierer.ppd -E
     lpadmin -p LaserLZ -v socket://10.16.112.201:9100 -m LaserLZ.ppd -E
  

Testweise ist das gerade auf dem rechner-lz-01 am Laufen, wenn es dort tut, würde ich es mal auf den anderen Rechnern auch so einrichten.

[bau]

Das lokale Einrichten der Drucker funktioniert prima!
Ich habe nun auf dem paedml ein Script /root/drucker/lprinters angelegt, welches die Drucker auf den LZ-Clients anlegt und das Browsing abschaltet. Die Drucker heißen gerade:

• 1_LaserLZ
• 2_Kopierer

damit die in der richtigen Reihenfolge aufgeführt werden. Andere Drucker habe ich mal nicht eingerichtet, die sind sicher überflüssig - oder?

Ich habe jetzt noch auf den Stützpunktrechnern und auf rechner-1-09-01 und rechner 1-10-01 das Monitor-Script laufen - mal sehen, was die den Tag über so melden.

[Rüdiger Kupper]

Hallo Jens,
hast Du gerade die übrigen Rechner im LZ bearbeitet? Die haben nun nämlich alles die selbe printers.conf!

[Rüdiger Kupper]

So weiß ich leider nicht, welches die alten und welches die neuen Einstellungen sind. Ich brauche noch mindestens einen Rechner, der unverändert ist!

[Rüdiger Kupper]

Okay, die Probleme mit dem CUPS-Browsing können wir offenbar nicht lösen, also richten wir die Drucker wie beschrieben lokal ein und stellen das Browsing komplett ab.
Wir sollten zu späterer Zeit probieren, ob es wieder funktioniert.

-> Ich schließe daher dieses Ticket und öffne ein neues für die lokalen Drucker.
Anschlussticket: #2446.