Ich wollte mein Ubuntu-Notebook zum Drucken an ein Windows-Netzwerk hängen

"System->Systemverwaltung->Drucken" ruft system-config-printer auf. Dort wird immer ein Kennwort für root erfragt. Mit dem sudo-Passwort lief es nicht.

Erfolgreich war ich nur aus dem Terminal heraus mit

sudo system-config-printer

Jetzt wurde kein weiteres Mal das Passwort abgefragt.

Änderungen der Druckereigenschaften scheitern aus dem Menü heraus weiterhin, da wieder das root-Passwort benötigt wird.

Möglicherweise ist das Problem in den Folgeversionen schon behoben. Sollte noch dieser Workaround für Lucid eingebaut werden?

Wäre sinnig, da Lucid als LTS-Version von vielen genutzt wird.

Mittlerweile habe ich herausgefunden, dass der Fehler durch die Befolgung der Anleitung http://wiki.ubuntuusers.de/ecryptfs/Einrichten#Homeverzeichnis-umstellen entstanden ist.

Entgegen der Aussage auf dieser Seite wurde mir von der Live-CD die Verschlüsselung nicht angeboten. Bei der manuellen Umstellung reicht das

adduser <Benutzername> admin

offensichtlich nicht aus, sondern muss durch

adduser <Benutzername> lpadmin

ergänzt werden. Dann läuft es.

Der Diskussion zur Seite ecryptfs/Einrichten werde ich einen Link auf diesen Beitrag setzen.

Hallo klang,

dass ist schon richtig so, was Du festgestellt hast - adduser wird immer mit

• adduser user group

spezifiziert - hier also Deine Erweiterung (Gruppe) mit lpadmin!

Nur dieses WIKI beschreibt ecryptfs und nicht alle Optionen von adduser, das würde das WIKI sprengen, wenn ich alle Fälle des Lebens hier unterbringe (hier wurde die häufigste Option als Beispiel herangezogen). Der nächste Leser stellt dann wieder andere Ansprüche und in meinem Verständnis ist es zulässig, von jedem die Optionen der anderen Befehle in den

• man-Seiten

oder im WIKI abzufragen, hier im Speziellen, einem allgemein bekannten Befehl ist m.E. keine weitere Ergänzung bzw. Hinweis erforderlich.

gruß syscon-hh

Hallo syscon-hh

ich habe ein kleines Testsystem eingerichtet. Ein frisch installierter Benutzer gehört zu folgenden Gruppen:

ich@test:~$ sort /etc/group | grep ich
admin:x:119:ich
adm:x:4:ich
cdrom:x:24:ich
dialout:x:20:ich
ich:x:1000:
lpadmin:x:105:ich
plugdev:x:46:ich
sambashare:x:122:ich
ich@test:~$ 

Es ging in meinem Hinweis nicht um die Nutzung von man oder adduser an sich, sondern, dass man in der Gruppe admin scheinbar alle Rechte der anderen Gruppen hat, bis auf lpadmin.

Das fände ich in deinem Artikel im Hinblick auf die nachträgliche Verschlüsselung erwähnenswert.

gruß klang

@klang schrieb:

Es ging in meinem Hinweis nicht um die Nutzung von man oder adduser an sich, sondern, dass man in der Gruppe admin scheinbar alle Rechte der anderen Gruppen hat, bis auf lpadmin.

Das stimmt so auch nicht . Der in ecryptfs bestehende Hinweis auf das Setzen bzw. Überprüfen in den diversen Gruppen muss halt nur beachtet werden. Was mich erstaunt ist, dass Du Probleme mit lpadmin hattest, dieser ist in der Regel gesetzt (analog wie plugdev) - dann hattest Du den vorher mal verändert, zumindest in einer frischen Installation (gerade mal mit Lucid gemacht) ist dieser gesetzt. Und dieser Rechner hatte noch nie Kontakt mit einem Drucker noch mit einem Netztwerk!

Nachtrag: Nach x-Versuchen im Laufe des Tages kann ich nur feststellen, dass die Datei

• /etc/group

in keinster Weise von ecryptfs beeinflusst wird - außer man legt einen neuen Benutzer an, aber das hat ja nur indirekt was damit zu tun. Also lassen wir es mal so, wie es sich im Moment beschrieben wird.

Habe das jetzt mit

• Karmic

• Lucid

• Maverick

• Natty (noch unverbindlich)

durchgetestet - immer das gleiche Verhalten, der Fehler muss also in Deinem System liegen!!!

Hallo syscon-hh,

vielen Dank für deine Mühe. Auch ich habe noch einmal mehrere Versuche gemacht. Wie auch in meinem vorherigen Beitrag sind nach der Installation die gezeigten Gruppen immer gesetzt. Aber nach der Verschlüsselung sind ja logischerweise alle Zuordnungen weg. Die müsste man also alle wieder "von Hand" herstellen, was für admin ja auch in der Anleitung steht. Und diesen Punkt habe ich jetzt erst im Nachhinein begriffen, da admin scheinbar mehr als die dokumentierten Rechte hat, weshalb andere Dinge funktionierten, obwohl dafür auch eigene Gruppenzuordnungen existieren, aber nicht alle.

Der einzige Schritt, der über die Anleitung hinaus nötig gesesen wäre, hätte im Notieren der bisherigen Zuordnungen bestanden. Dies werde ich an der entsprechenden Stelle ergänzen. Ansonsten betrachte ich das Problem als gelöst.

Vielen Dank noch einmal!

gruß klang

Der einzige Schritt, der über die Anleitung hinaus nötig gesesen wäre, hätte im Notieren der bisherigen Zuordnungen bestanden. Dies werde ich an der entsprechenden Stelle ergänzen. Ansonsten betrachte ich das Problem als gelöst.

Ich kann mit der Änderung leben, allerdings ist dieser spezielle Sachverhalt doch schon hier

• adduser

eingebracht und dort gehört er auch hin (siehe den Hinweiskasten bei "adduser"). Ich hätte dann den Link hierauf geleitet, anstelle auf Benutzer und Gruppen, der steht ja ein paar Zeilen darunter. Und die oberste Prämisse vom WIKI ist ja, doppelte Beschreibungen zu vermeiden. Also reicht der vorhandene Querverweis, ansonsten kicken das die WIKI-Admins wieder raus

OK, ein Wiki kann nicht alles.

Nur finde ich es gerade für Tätigkeiten, die man extrem selten ausführt, sehr hilfreich, mich an vollständigen Schritt - für - Schritt- Anleitungen entlang hangeln zu können.

In dem Sinne ...

Hallo,

mich an vollständigen Schritt - für - Schritt- Anleitungen entlang hangeln zu können.

How-Tos in diesem Sinne haben (und wollen) wir hier im Wiki nicht - wir setzen auf den Wissensblock und darauf, dass jede Info einmal aber dafür richtig im Wiki steht. Wenn Infos redundant hat, führt das zu einer (sehr) schlechten Wartbarkeit und irgendwann zu Fehlern.

In so fern hat syscon-hh schon recht.

Gruß, noisefloor