Opened 10 years ago
Closed 10 years ago
#2310 closed Defekt (erledigt)
Drucker im LZ
| Reported by: | bau | Owned by: | bau |
|---|---|---|---|
| Priority: | unverzüglich erledigen | Milestone: | Schuljahr 2016/17 |
| Component: | Hardware: Netzwerktechnik | Severity: | beeinträchtigt den Unterricht vieler Lehrer |
| Keywords: | Cc: | netzwerk |
Description
Seit Umstellung des Netzes in Subnetze sieht man im LZ im CUPS nur noch den LaserLZ an 10.32.1.1 - offenbar browsen die Rechner nicht mehr den 10.16.112.4.
Der paedml streht auch im gleichen Subnetz zur Verfügung unetr der Adresse 10.16.112.252 - kann da bitte jemand schnell danach schauen - derzeit kann man ausschließklich auf den LaserLZ ausdrucken.
Drucken aus der VM heraus hingegen tut, da ich dort die fixen IP der Drucker eingetragen habe.
Change History (16)
comment:1 by , 10 years ago
| Cc: | added |
|---|---|
| Owner: | changed from to |
| Priority: | normal → hoch |
| Status: | new → accepted |
comment:2 by , 10 years ago
| Milestone: | Schuljahr 2015/16 → Schuljahr 2016/17 |
|---|
comment:3 by , 10 years ago
Vielleicht hängt das mal wieder mit dem avahi zusammen.
Auf meinem Laptop habe ich den kurzerhand ausgeschaltet (seitdem sind die Meldungen beim Anstöpseln an unser Netzwerk auch weg):
/etc/avahi/avahi-daemon.conf ... deny-interfaces=eth0 ...
comment:4 by , 10 years ago
Steht so auch im Christof-Image. Und da hat man die Drucker auch nicht gesehen, oder?
Ich tippe momentan doch eher noch auf Netzwerkprobleme:
- Name paedml wird falsch aufgelöst (eben Ticket dafür erstellt)
- man kann Rechner im Lehrernetz nicht per wake-on-LAN aufwecken (Problem mit Switch/Subnetting?)
Ich denke eher, dass der CUPS-Browsing-Pakete genausowenig durchkommen wie die Wake-on-LAN-Pakete...
Fällt Dir dazu etwas ein?
comment:5 by , 10 years ago
Ist das LZ ein eigenes Subnetz? Dann wäre es logisch, dass die LZ-Rechner nur den LZ-Drucker gefunden haben...
follow-ups: 7 9 comment:6 by , 10 years ago
Mist, jetzt weiß ich wieder, was ich dir gestern noch sagen wollte:
Der paedml hat nun drei virtuelle NIC - eines in grün, eines in VLAN6 (grau, wie bisher) und eines in VLAN62 (Lehrersubnetz des KGy) - der Wakeuponlan darf nun nicht mehr über eth1 raus sondern muss über eth2 ins VLAN62, denn die Magic-Packets werden nicht geroutet.
Die Rechner finden interessanterweise den LaserLZ am paedml mit der IP 10.32.1.1!
Wir sind hier aber im VLAN62 mit Adressen 10.16.112.129-254 !
paedml wird aufgelöst zu 10.16.112.4, wie bisher auch, da die Rechner in einem anderen Subnetz sind (paedml/10.16.112.4 in VLAN6, Rechner in VLAN62) werden die Pakete halt über das Default-Gateway (10.16.112.254) zum paedml gesendet. Eventuell hat der Client damit Probleme. Die Route ins grüne Netz geht über einen Linux-Rechner, die in die anderen VLAN über den Cisco-Switch, der auch routen kann. Vielleicht ist das der Unterschied.
comment:7 by , 10 years ago
paedml wird aufgelöst zu 10.16.112.4, wie bisher auch,
Zur Zeit nicht richtig, siehe #2314.
comment:8 by , 10 years ago
In der cups-browsed.conf steht:
BrowseAllow 10.32.1.1 BrowseAllow 10.16.112.4
Das stimmt dann ja nach wie vor, oder?
Vor etwa einer Stunde war die printers.conf meines Rechners noch komplett leer, jetzt sieht sie aber ganz normal aus (alle Drucker wurden entdeckt). Hast Du was geändert?
comment:9 by , 10 years ago
Replying to bau:
der Wakeuponlan darf nun nicht mehr über eth1 raus sondern muss über eth2 ins VLAN62
Es gibt kein eth2:
# ifconfig
eth0 Link encap:Ethernet Hardware Adresse 1a:ac:a7:39:9c:07
inet Adresse:10.16.112.4 Bcast:10.16.112.127 Maske:255.255.255.128
inet6-Adresse: fe80::18ac:a7ff:fe39:9c07/64 Gültigkeitsbereich:Verbindung
UP BROADCAST RUNNING MULTICAST MTU:1500 Metrik:1
RX-Pakete:1285126085 Fehler:0 Verloren:12130098 Überläufe:0 Fenster:0
TX-Pakete:701907508 Fehler:0 Verloren:0 Überläufe:0 Träger:0
Kollisionen:0 Sendewarteschlangenlänge:1000
RX-Bytes:898410606079 (898.4 GB) TX-Bytes:1423835298811 (1.4 TB)
eth1 Link encap:Ethernet Hardware Adresse ba:62:2d:0b:b1:3b
inet Adresse:10.32.1.1 Bcast:10.47.255.255 Maske:255.240.0.0
inet6-Adresse: fe80::b862:2dff:fe0b:b13b/64 Gültigkeitsbereich:Verbindung
UP BROADCAST RUNNING MULTICAST MTU:1500 Metrik:1
RX-Pakete:3900345833 Fehler:0 Verloren:10661689 Überläufe:0 Fenster:0
TX-Pakete:2353862917 Fehler:0 Verloren:0 Überläufe:0 Träger:0
Kollisionen:0 Sendewarteschlangenlänge:1000
RX-Bytes:2784595818340 (2.7 TB) TX-Bytes:6062690438458 (6.0 TB)
lo Link encap:Lokale Schleife
inet Adresse:127.0.0.1 Maske:255.0.0.0
inet6-Adresse: ::1/128 Gültigkeitsbereich:Maschine
UP LOOPBACK RUNNING MTU:16436 Metrik:1
RX-Pakete:276786871 Fehler:0 Verloren:0 Überläufe:0 Fenster:0
TX-Pakete:276786871 Fehler:0 Verloren:0 Überläufe:0 Träger:0
Kollisionen:0 Sendewarteschlangenlänge:0
RX-Bytes:195386954309 (195.3 GB) TX-Bytes:195386954309 (195.3 GB)
comment:10 by , 10 years ago
| Priority: | hoch → höchste |
|---|---|
| Severity: | normal → kritisch |
Das Drucken im LZ ist nicht wirklich möglich.
Der Drucksdialog von Libre Office stürzt dauernd ab, bzw. verdammt einen in den "freeze".
Der Lehrerzimmerdrucker wird gar nicht erst aufgezeigt- dafür aber der Kopierer :)
comment:12 by , 10 years ago
Scheinen die selben Nachwehen zu sein, wie kürzlich, als wir die speziellen Druckerqueues entfernt haben. Ich bin genauso vorgegangen: Auf allen LZ-Rechnern ausgeführt:
service cups-browsed stop service cups stop rm /etc/cups/printers.conf rm /etc/cups/printers.conf.O service cups start service cups-browsed start
Danach dauert es mehrere Minuten, bis nach und nach die Drucker entdeckt werden. Inzwischen haben sich die LZ-Rechner auf einen Satz von 14 Druckern geeinigt:
<Printer BioLaser>
<Printer BuecherLaser>
<Printer ChemLaser>
<Printer Kopierer>
<Printer KopiererSekret>
<Printer Laser0027a>
<Printer Laser0027b>
<Printer Laser523>
<Printer Laser527>
<Printer Laser547>
<Printer LaserLZ>
<Printer LaserNwT>
<Printer PDF-Printer>
<Printer PhysikLaser>
<Printer QL550_PH>
Die Liste scheint jetzt stabil zu sein. LaserLZ und Kopierer sind jeweils dabei. Bitte mal Probedrucke probieren!
follow-up: 15 comment:13 by , 10 years ago
Ich erhalte beim Abfragen der Druckerwarteschlange folgende Fehlermeldung:
"Beim Betrieb von CUPS trat ein fehler auf: Der Socket ist nicht verbunden"
Das sieht aus, als ob die Netzwerkkonfiguration noch nicht völlig passt -- muss auf dem paedml an der CUPS-Konfiguration etwas geändert werden, damit die Druckerqueues aus dem VLAN62 zugegriffen werden können?
comment:14 by , 10 years ago
Z.B. die Einträge in /etc/cups/custom_access.conf? Da steht bei allen Druckern:
<Location /printers/Kopierer> Order Deny,Allow Deny From All Allow From 127.0.0.1 Allow From 10.32.1.1 Allow From 10.16.* Allow From 10.32.* Allow FROM 172.16.* Allow From 10.41.* Allow From 10.45.* </Location> <Location /printers/LaserLZ> Order Deny,Allow Deny From All Allow From 127.0.0.1 Allow From 10.32.1.1 Allow From 10.16.* Allow From 10.32.* Allow FROM 172.16.* Allow From 10.41.* Allow From 10.45.* </Location>
Muss hier irgendwo das VLAN62 aufgeführt werden?
comment:15 by , 10 years ago
| Owner: | changed from to |
|---|---|
| Status: | accepted → assigned |
Replying to kup:
"Beim Betrieb von CUPS trat ein fehler auf: Der Socket ist nicht verbunden"
Die Drucker stehen so in der printers.conf (z.B. LaserLZ):
Location 10.16.112.252 DeviceURI ipp://10.16.112.252:631/printers/LaserLZ
Wenn ich im LZ im Firefox die Adresse "http:/10.16.112.252:631" eingebe, erhalte ich keine Verbindung. "http:/10.16.112.4:631" zeigt das CUPS-Interface.
Also ist Port 631 aus VLAN62 nicht erreichbar. Das dürfte das Problem sein.
comment:16 by , 10 years ago
| Resolution: | → erledigt |
|---|---|
| Status: | assigned → closed |
Routingproblem behoben, siehe http://paedml.kg-fds.de/trac/ticket/2329#comment:2
Replying to bau:
Hm, funktioniert denn das Browsing nur um selben Subnetz? Ich habe an den Einstellungen seit Ferienbeginn nichts verändert. Da sah man die Drucker doch noch, oder?
Muss ich mir ansehen.