Lokaler Firefox sieht die Netzwerkdrucker nicht

[Rüdiger Kupper]

Die printers.conf liegt ja auf den Servern -> in chroot kopieren sollte helfen.

[Rüdiger Kupper]

Hm, der lokale Firefox zeigt aber den Laser128 an? Wie das??

[Rüdiger Kupper]

Und alle Rechner im SMV-Raum sehen den dort befindlichen Lexmark-Drucker. Wie das? Broadcasten die sich selbst?

[Rüdiger Kupper]

Argh! In der lokalen chroot läuft natürlich nicht mal ein CUPS-Daemon. Also installiere ich dort nun auch ein CUPS. Dieser lokale Firefox zieht wirklich einen ziemlichen Rattenschwanz an weiteren benötigten Paketen in der lokalen chroot nach sich...

[Rüdiger Kupper]

Jetzt hapert es daran, dass der paedml von den individuellen Clients nicht erreichbar ist:

kup@LZ1:~$ lpstat -l
lpstat: Connection refused
kup@LZ1:~$ ssh paedml
ssh: connect to host paedml.kg-fds.de port 22: Connection refused
kup@LZ1:~$ 

Sollen wir den CUPS-Port zum paedml aufmachen (und wollen wir das?)

[bau]

OK, ich habe das Problem eingegrenzt:
Der User linadmin auf dem Server sieht alle Drucker, deren User nicht eingegrenzt sind.
Hat das lokale Unix Zugriff auf die Gruppendaten des LDAP? In der printers.conf steht nämlich bei den meisten Druckern @teachers, folglich muss der lokale Client die Gruppenzugehörigkeit auflösen können!

[Rüdiger Kupper]

Ah, interessante Beobachtung!
-- Ich habe keine Ahnung, nehme aber an, LDAP-Zugriff von den lokalen Clients ist nicht vorgesehen, und ich habe sie auch nicht eingerichtet. Dazu muss das PAM-LDAP-Modul installiert sein, und dann müssen die beiden ldap.conf-Files und das andere Configfile für die Authentifizierung (mir fällt gerade der Name nicht ein) in die Clientumgebung kopiert werden.

Aber weißt Du, wir sind gerade dabei, unsere Thin Clients "zu Fuß" zu Fat Clients aufzublasen. All diese Sachen sind auf den Clients normalerweise nicht nötig. Wir können das zwar alles einrichten, es wird mir aber nächsten Monat wiederum Arbeit machen, wenn die neue Ubuntu-Version herauskommt. Es gibt nämlich keine sichere Methode, die Client-Umgebung auf die neue Version upzugraden: Das Upgrade-Tool von Ubuntu geht von einem vollständigen System aus und wird für die Clients nicht empfohlen. Der bei LTSP empfohlene Weg ist, den Server upzugraden und dann die zugehörige Clientumgebung neu zu erzeugen. Wenn ich das aber mache, dann muss ich sämtliche Anpassungen, die wir jetzt vornehmen, danach wieder machen. Inzwischen ist das so einiges...

Vielleicht haben wir aber auch Glück, und das Upgrade-Tool kommt mit der Client-Umgebung klar. Dann sollte der Upgrade reibungslos klappen.

Eine Alternative ist natürlich, das Fat-Client-Modell von LTSP mal zu testen. Aber dazu sind unsere Client eigentlich zu schwach, oder? Andererseits könnte es unsere Grafikprobleme reduzieren, die DVD-Wiedergabe problemloser machen und die allgemeine Performance verbessern.

Probieren würd' ich's schon mal, wenn ich eine Woche dafür frei hätte ;-).

[bau]

Ich habe grade mal genauer nachgelesen, was FAT-Clients überhaupt anders machen. Ich bin zum Schluss gekommen, dass unsere Clients ja schon fast FAT sind, als Mischung von Thin/Fat erscheinen die mir aber als relatives Optimum. Bei der Lektüre von ​https://help.ubuntu.com/community/UbuntuLTSP/FatClients scheint mir, dass wir uns mehr Probleme einhandeln werden, als dass es gut sein wird!

Für das Druckerproblem:
Ich denke, dass es den Kollegen zumutbar ist, den anderen Firefox zu benutzen, wer das nicht kapiert druckt halt einfach aus dem Firefox nichts aus oder eben nur als PDF, welches er anschließend mit evince öffnet und dann ausdrucken kann.

Ich werde noch checken, ob auf der lokalen Konsole ein groups bau möglich ist oder eben nicht!

[Rüdiger Kupper]

Das Problem ist einstweilen nicht wichtig, weil der Firefox wieder auf dem Server läuft.