Linuxmuster-linuxclient7: Müssen Drucker über GPOs installiert werden?

Ist in der Raumgruppe dann auch ein memberOf mit der Druckergruppe?

Hab grad Besuch. Ich melde mich später…
Gruß,
Mathias

… da bin ich wieder…

Ja:


und

Sieht eigentlich richtig aus, oder?

Ich habe mich jetzt nochmal angemeldet.
Der LZFLaser1 ist jetzt da :upside_down_face:

Dann habe ich die anderen Drucker auch eingetragen. Die sind noch nicht da?!? Vielleicht braucht es einfach etwas Zeit?
Ich warte mal und melde mich wieder…
Gruß,
Mathias

So, jetzt sind zwei Stunden vergangen und siehe da, die Drucker sind alle verfügbar. Manchmal braucht es eben etwas Geduld :slight_smile:

Naja, wenn man als Lehrer in der Schulkonsole unter Einschreiben einen Drucker anwählt, war der bei der nächsten Anmeldung da.
Aber das ist halb so wild. Die Drucker-Raumzuordnung ist ja nichts, was sich ständig ändert :slightly_smiling_face:

Nochmals vielen Dank für deine Unterstützung.

Gruß,
Mathias

1 „Gefällt mir“

Super! Freut mich :upside_down_face:
Die Wartezeit entstteht dadurch, dass die Gruppenmitgliedschaften lokal gecached werden. Mit einem linuxmuster-linuxclient7 prepare-image lässt sich der cache auch sofort löschen. Das macht das Testen ein bisschen einfacher :wink:

VG, Dorian

1 „Gefällt mir“

Perfekt!
Danke für den Tip.
Gruß,
Mathias

Hallihallo,

hilfe, ich habe jz das gleiche Problem.
Ein knappes 3/4 Jahr hat alles sehr (nach erfolgter Installation) problemlos funktioniert. Die Drucker wurden über CUPS auf dem Server angesprochen - prima! Plötzlich ging nach den Ferien das Internet nicht mehr (Zeiten waren synchron). Dann habe ich die Anleitung für sso abgearbeitet… (dabei lief durch ein Update von OpenSense der Proxydienst einfach nicht!). Nach einem Neustart dachte ich, es wäre alles oke und aktualisierte den Server. Nun stelle ich fest, dass keine Drucker mehr verfügbar sind!!!
Was ich sonst noch gemacht/überprüft habe:

  1. sophomorix-repair -all liefert „0 Errors“
  2. Auf Client und Server ist Samba Version 4.7.6-Ubuntu installiert. (noch der „alte“ Client Adsso, aktualisiert im März 21)
  3. Auf der CUPs-Konfigurationsseite kann nicht einmal mehr root eine Testseite drucken. Die Fehlermeldung weist darauf hin, dass evtl. Kerberos-Aut verwendet wird. Das Häkchen bei „verwende Kerberos“ (oder s. ä.) habe ich dann gesetzt. Drucken geht dennoch nicht.
  4. Auf github habe ich beim linuxmuster-Projekt eine Anleitung zur Installation und Anmeldung am AD mit dem Apache AD Studio (Explorer) gefunden. Die Anmeldung am AD des Servers funktioniert. Leider schaffe ich das nicht mit dem MS tool, das rettich oben verwendet.
  5. Die AD-Einträge der Drucker gleichen sich den Einträgen von rettich vom 12.09… 10.58: Die Raumgruppe (der Raum) ich noch kein Member des Druckers.
  6. Ich schaffe es mit dem AD Explorer nicht, den Raum als Member der Gruppe Drucker einzutragen: wie geht das? Wo gibt es eine Anleitung? In der Doku fehlt der entsprechende Eintrag.
  7. Die Schulkonsole erzeugt einen Fehler, wenn ich Klassen (z. B. 8a) als Gruppe zu den Druckern hinzufügen will: „… this is likely a bug“. Räume sind als Gruppe unbekannt.

Ich hoffe, ihr könnt mir zeitnah helfen…

LG,
Fritz

Hi Fritz,

Das Problem bei dir ist der Cups. Den musst du zuerst wieder zum.Laufen bekommen. Solange du nicht im Cups als Root eine Testseite drucken kannst, kann es auch sonst nirgends funktionieren. Am Besten, du probierst mal, alle Drucker zu löschen und neu zu erstellen, das hat bei mir scjon oft geholfen.

VG, Dorian

Drucker löschen geht nicht: keine Rechte.
Komme nun wieder als root auf die CUPS-Seite. (habs geschafft, dass ich Kerberos-Auth zur Anmeldung wieder ausgeschaltet habe, über /etc/cups/cupsd.conf).
Sind durch das Update oder die Aktivierung von SSO die Rechte so extrem gesetzt worden?
Wie muss ich die cupsd.conf verändern? Einen Absatz mit Kerberos… habe ich gefunden. Auf der Cups-Seite ist keine Doku über diese „Schalter“ aufgelistet. Was ist hier passiert? Wie soll ich weiter vorgehen? Ich will nicht gleich alles zurstören…
Cups durch „apt purge cups“ deinstallieren und dann wieder installieren?
LG, Fritz

Hallo Fritz,
ich hatte das auch, schau mal in die /etc/cups/cupsd.conf da war bei mir eine Allow… Zeile drin, die mal wegmachen oder passend ändern, dann gings wieder mit dem Zugriff.
LG
Max

Gute Frage … Cups neigt manchmal zur Selbstzerstörung. Hatte ich auch schon ein paar mal. Deinstallieren, alle configs löschen, und neu installieren, könnte als aller letztes Mittel helfen. Da musst du aber vorsichtig sein. Mach aber vorher ein Snapshot vom Server und pass auf, dass beim Löschen nicht sophomorix oder sowas wegfliegt (wegen eventuellen Abhängigkeiten).

Ach ja - mit Kerberos musst du nichts einstellen. Cups läuft standardmäßig ohne Authentifizierung.

VG, Dorian

N’Abend,
ich grätsch mal quer rein und beantwortet die Urpsrungsfrage mit einem klaren NEIN, sie müssen nicht – ich habe meine Drucker als linuxadmin lokal installiert und achte beim prepare-image darauf, dass die dort nicht gelöscht werden…funktioniert im Moment problemlos…
Wenn ich einen neuen Drucker installiere, mache ich das an irgendeinem Client, kopiere dann die printers.conf und die neu hinzugekommene ppd in das Verzeichnis, dass das Standardpostsyncskript verarbeitet und kann dadurch Drucker nachinstallieren, ohne ein Image schreiben zu müssen.

Gruß
Sascha

Hi Sascha,

Kann man so machen, ist halt aufwendiger :upside_down_face:

VG, Dorian

Hallo,
vielen Dank für die Antworten.
Bin nun wieder schlauer geworden:

  1. Der Schalter in der cupsd.conf für die kerberos-Authentifizierung lautet: „DefaultAuthType=Negotiate“. Wenn man „Negotiate“ durch „Basic“ ersetzt, dann kann man sich wieder anmelden (das Häkchen habe ich aus Versehen gesetzt).
  2. Ein Zugriff auf „Verwaltung (der Drucker)“ war dennoch nicht möglich und wurde mit der Meldung „verboten“ quittiert. Erst durch das Aufrufen von „http://ip…:631/admin“ (wichtig: nicht „https://…“!) erschien die Meldung „Sie werden weitergeleitet…“ und ich kam wieder auf die Seite, auf der man die Drucker verwalten kann (jetzt doch per „https://…“)???.
  3. Eine Testseite durfte root jedoch immer noch nicht drucken, Drucker löschen jedoch schon. Erst als ich die Gruppe „@printing“ als autorisierte Gruppe löschte, kam die erste Testseite wieder aus dem Drucker (das habe ich allerdings erst gemerkt, als ich allles gelöscht habe und dann wieder nach der Anleitung die Drucker neu installierte).
    WARUM IST DAS SO? Die Doku verlangt eindeutig die Gruppe @printing einzutragen, damit den Schülern der Drucker gesperrt werden kann. Das hat auch immer einwandfrei funktioniert. Wurden irgendwelche Gruppenzugehörigkeiten verändert? Oder ist bei mir der „Wurn drin“? In der Doku fehlt z. Z. auch die Anleitung für das Anpassen des AD. Ich erlaube den Zugriff auf die Drucker über das Netz (Raum 1 mit 10.0.1.x, Raum 2 mit 10.0.2.x,…), das ich in die cupsd.conf passend mit „Allow“ eintrage. Ist das oke so?
  4. Mit dem pcl 6-Tereiber funktionierte der P2015 bisher einwandfrei. Nach dem Update benötigt er leider ca. 10 s pro Seite! Welcher Treiber wäre besser?

Viele Grüße,
Fritz

Hallo 0815tux,

zu 4.
Ich hatte auch mal Probleme mit der Wartezeit beim Drucken und versch. Treiber ausprobiert. Vielleicht ist das eine Anregung für Dich:

Gruß
Stefan

Hi Stefan,

danke für den Hinweis! Das werde ich testen…

VG,
Fritz

Getestet: Komisch, wirklich viel schneller… Nur jz stimmt die Anzahl der Exemplare nicht mehr, die man drucken will. Mit dem hp-Treiber passt das, nur ewig langsam… Hat wer einen Tipp???
Warum kann auf den Drucker nicht mehr zugreifen, wenn ich die Gruppe @printing eintrage?
Doku für die Anpassung des AD?

VG,
Fritz

Geht so — alternativ hätte ich die Linuxdruckertreiber in den Microsoftdruckerserver installieren müssen, das klingt für mich nicht unbedingt nach weniger Arbeit.

Gruß
Sascha

Nein. Du musst die Treiber auf dem Schulserver installieren, damit Cups damit läuft. Das ist eigentlich genau das gleiche wie auf den Linuxclients.

VG, Dorian

Sorry, muss hier noch einmal nachfragen:
Warum kann ich nach einem Update des Servers nicht mehr auf die Drucker zugreifen, wenn die Gruppe „@printing“ eingetragen ist? Vorher hat alles prima funktiniert…
Liegt es evtl. an dem alten Linuxmusterclient?
Fehlt die Konfiguration im AD?

VG, Fritz