Du bist nicht angemeldet.

Eine Antwort schreiben

Schreibe deinen Beitrag und versende ihn
Beitragsoptionen
Deine Antwort

Zurück

Themen-Übersicht (Neuester Beitrag zuerst)

Martin-MS
03.11.2014 22:08:49
k.osmo schrieb:

Die Units sind ja nicht mehr da, nur die Symlinks stehen noch drin.

Eben... und deshalb geht auch das "disable" für die anderen beiden Units in die Hose und bleiben als tote Links stehen weil die Informationen aus cups.service nicht mehr greifbar sind.

Hat mit den Fehlermeldungen gemäß pacman- Qkk cups aber wohl nichts zu tun.

Genau; dieses Problem scheint es aber schon seit 2007 (!) zu geben und ist damit nicht wirklich neu: https://bugzilla.redhat.com/show_bug.cgi?id=245748
Ich weiß nicht ob es vor dem Hintergrund noch sinnvoll ist, einen Bugreport einzureichen. 

Ich frage mich allerdings, wenn Du Recht hast mit deiner Einschätzung bezüglich der Paketierung, ob dann nicht alle CUPS-Installationen unter ARCH davon betroffen sein müssten?

Also hier war es jedenfalls so. Aber nicht jeder wird ständig pacman die Berechtigungen überprüfen lassen, deswegen wird das auch erst einmal nicht auffallen. Ich kam ja auch nur deswegen darauf, weil pacman die permissions von /var/cache/cups bemängelte.
Eine gesamte Suche über das Dateisystem brachte übrigens noch weitere Dateien hervor, deren aktuelle Berechtigungen sich von denen in den Paketen unterscheiden.

k.osmo
03.11.2014 17:20:58
Martin-MS schrieb:

Leider erfährt der Benutzer erst nach der Installation, dass sich die unit-Namen geändert haben. Und die Hinweise aus pacman sind so gesehen auch nicht korrekt, eigentlich müsste darauf hingewiesen werden, dass alle drei units entferne werden müssen, und nicht nur cups.service.

Die Units sind ja nicht mehr da, nur die Symlinks stehen noch drin. Hat mit den Fehlermeldungen gemäß pacman- Qkk cups aber wohl nichts zu tun. Ich frage mich allerdings, wenn Du Recht hast mit deiner Einschätzung bezüglich der Paketierung, ob dann nicht alle CUPS-Installationen unter ARCH davon betroffen sein müssten?

Martin-MS
03.11.2014 16:12:44
jlp2 schrieb:

bei mir lief es mit
$ systemctl stop cups.service && systemctl disable cups.service

Das wäre eigentlich die korrekte Variante. Denn mit systemctl enable cups.service werden auch die units cups.path und cups.socket nachgezogen und bei einem systemctl disable cups.service werden alle drei die Links auch wieder entfernt. Nach dem Upgrade gibt es die unit cups.service aber nicht mehr, also wird bei einem systemctl disable cups.service auch nur genau dieser eine Link wieder entfernt und die beiden anderen bleiben als tote Links stehen.

Leider erfährt der Benutzer erst nach der Installation, dass sich die unit-Namen geändert haben. Und die Hinweise aus pacman sind so gesehen auch nicht korrekt, eigentlich müsste darauf hingewiesen werden, dass alle drei units entferne werden müssen, und nicht nur cups.service.

jlp2
03.11.2014 14:55:36

OK wenns so auch geht super...

bei mir lief es mit

$ systemctl stop cups.service && systemctl disable cups.service
$ rm -r /var/cache/cups
$ pacman -Syy && pacman -S cups
$ systemctl daemon-reload
$ systemctl start org.cups.cupsd.service && sudo systemctl enable org.cups.cupsd.service
$ systemctl daemon-reload

Jetzt gibt ein....

$ journalctl -b | grep cups

...nur noch das aus.

Nov 03 13:14:53 X121e colord[327]: Device added: cups-HP_LaserJet_farbe
Nov 03 13:14:53 X121e colord[327]: Device added: cups-HP_LaserJet_monochrom
Nov 03 13:14:53 X121e colord[327]: Device added: cups-HP_Officejet_Best
Nov 03 13:14:53 X121e colord[327]: Device added: cups-HP_Officejet_Entwurf
Nov 03 13:14:53 X121e colord[327]: Device added: cups-HP_Officejet_Normal
Nov 03 13:14:53 X121e colord[327]: Device added: cups-HP_Officejet_Photo

Denke so sollte es sein.

systemctl list-unit-files | grep cups

org.cups.cupsd.path                         enabled
cups-browsed.service                        disabled
org.cups.cupsd.service                      enabled
org.cups.cupsd.socket                       enabled

k.osmo
03.11.2014 13:12:32

@jlp2

$ journalctl -b | grep cups

Nov 03 11:30:42 h0st systemd[1]: Cannot add dependency job for unit cups.socket, ignoring: Unit cups.socket failed to load: No such file or directory.
Nov 03 11:30:42 h0st systemd[1]: Cannot add dependency job for unit cups.path, ignoring: Unit cups.path failed to load: No such file or directory.
Nov 03 11:30:44 h0st systemd[1]: Cannot add dependency job for unit cups.socket, ignoring: Invalid argument
Nov 03 11:30:46 h0st systemd[1]: Cannot add dependency job for unit cups.socket, ignoring: Unit cups.socket failed to load: No such file or directory.
Nov 03 11:30:48 h0st systemd[1]: Cannot add dependency job for unit cups.socket, ignoring: Unit cups.socket failed to load: No such file or directory.
Nov 03 11:30:49 h0st systemd[1]: Cannot add dependency job for unit cups.socket, ignoring: Unit cups.socket failed to load: No such file or directory.
Nov 03 11:30:49 h0st colord[343]: Device added: cups-Brother_DCP-130C
Nov 03 11:34:09 h0st systemd[1]: Cannot add dependency job for unit cups.socket, ignoring: Unit cups.socket failed to load: No such file or directory.
Nov 03 11:36:02 h0st systemd[1]: Cannot add dependency job for unit cups.socket, ignoring: Unit cups.socket failed to load: No such file or directory.
Nov 03 11:37:16 h0st systemd[1]: Cannot add dependency job for unit cups.socket, ignoring: Unit cups.socket failed to load: No such file or directory.
Nov 03 11:37:17 h0st systemd[1]: Cannot add dependency job for unit cups.socket, ignoring: Unit cups.socket failed to load: No such file or directory.
Nov 03 11:37:32 h0st systemd[1]: Cannot add dependency job for unit cups.socket, ignoring: Unit cups.socket failed to load: No such file or directory.

$ systemctl list-unit-files | grep cups

org.cups.cupsd.path                         enabled 
cups-browsed.service                        disabled
org.cups.cupsd.service                      enabled 
org.cups.cupsd.socket                       enabled

# rm /etc/systemd/system/sockets.target.wants/cups.socket
# rm /etc/systemd/system/multi-user.target.wants/cups.path
# systemctl daemon-reload
$ journalctl -b | grep cups
(Keine neuen Einträge)

tapsiturtle
03.11.2014 10:05:50

Der Ursprung ist hier zu finden: http://www.cups.org/str.php?L3917 Beitrag Mar 19, 2014 by Michael Sweet: "I've called the service "org.cups.cupsd" since at some point I think I'll add an org.cups.cups-lpd service as well". Zumindest sind die Entwickler damit intern konsequent.

Martin-MS
02.11.2014 18:13:42
Kopfweh schrieb:

edit: Nachtrag: Auch wenn ich nach der Neuinstallation von cups nochmal

 sudo systemctl restart org.cups.cupsd.service

mache kommt immernoch der gleiche Output.

Die Warnungen über nicht übereinstimmende Berechtigungen bei den Dateien bekomme ich dauerhaft auch nicht beseitigt.
Für "classes.conf" setzt der Paketbetreuer die Zugriffsrechte folgendermaßen:

-rw-r--r-- 1 root lp      0 21. Okt 19:41 classes.conf

Wenn ich dann org.cups.cupsd.service neu starte wird daraus

-rw------- 1 root lp      0 21. Okt 19:41 classes.conf

Und schon berichtet pacman wieder über Unterschiede in den Berechtigungen.
Ob das immer schon so war oder neu mit cups-2.0.0 weiß ich nicht; ich habe die Berechtigungen in der Vergangenheit nie überprüft. Immerhin bleiben die Rechte von /var/cache/cups so wie sie gesetzt wurden.
Nachdem ich in den units keinen Hinweis darauf gefunden habe dass dort die Rechte der Dateien geädert werden vermute ich mal, dass cups das selber macht. Dann müsste man das aber mal dem Paketbetreuer melden damit er untersucht, warum die Dateien mit anderen Rechten verpackt werden als cups sie erwartet. Sonst kommt es immer wieder zu diesen Warnungen.

k.osmo
02.11.2014 14:57:55

@all: Danke für die Rückmeldungen.
@Martin-MS: Ich habe mich an deinen Entscheidungen orientiert, d. h. die Verzeichnisrechte geändert und den Benutzer der Gruppe lp hinzugefügt. Dies ist der Output von pacman -Qkk cups, vermutlich bei dir ähnlich?

Warnung: cups: /etc/cups/classes.conf (Berechtigungen stimmen nicht überein)
Warnung: cups: /etc/cups/classes.conf (Zeit der Veränderung stimmt nicht überein)
Warnung: cups: /etc/cups/classes.conf (Größen stimmen nicht überein)
Warnung: cups: /etc/cups/cupsd.conf (Zeit der Veränderung stimmt nicht überein)
Warnung: cups: /etc/cups/cupsd.conf (Größen stimmen nicht überein)
Warnung: cups: /etc/cups/printers.conf (Berechtigungen stimmen nicht überein)
Warnung: cups: /etc/cups/printers.conf (Zeit der Veränderung stimmt nicht überein)
Warnung: cups: /etc/cups/printers.conf (Größen stimmen nicht überein)
Warnung: cups: /etc/cups/subscriptions.conf (Berechtigungen stimmen nicht überein)
Warnung: cups: /etc/cups/subscriptions.conf (Zeit der Veränderung stimmt nicht überein)
Warnung: cups: /etc/cups/subscriptions.conf (Größen stimmen nicht überein)
Warnung: cups: /etc/dbus-1/system.d/cups.conf (Zeit der Veränderung stimmt nicht überein)
Warnung: cups: /etc/pam.d/cups (Zeit der Veränderung stimmt nicht überein)
Warnung: cups: /etc/xinetd.d/cups-lpd (Zeit der Veränderung stimmt nicht überein)
cups: 506 Dateien gesamt,7 veränderte Dateien

edit: Ups, @Kopfweh sitzt im gleichen Boot… *g*
edit2: Sind nur sudo-Nutzer betroffen?

Kopfweh
02.11.2014 14:55:50
Martin-MS schrieb:
jlp2 schrieb:

Durch die veränderten, eingeschränkten Rechte des neueren cups-Packetes, kann auf die angelegten Cache-Verzeichnisse nicht mehr zugegriffen werden.
Nach dem löschen werden die Verzeichnisse neu angelegt, OHNE Zugriffsfehler...

Ich hatte die Meldung nach dem Update auch und die Rechte dann mit chmod 770 angepasst.

Zuvor konnte jeder in das Verzeichnis /var/cache wechseln, das scheint wohl ein Sicherheitsrisiko gewesen zu sein. Jetzt kann es nur noch der Benutzer "root" und die Gruppe "lp". Das Verzeichnis aber einfach zu löschen und neu anlegen zu lassen kann aber nicht die Lösung sein, denn damit wird das Sicherheitsrisiko erneut provoziert.

Statt dessen sollte man sich bzw. die Benutzer die in dieses Verzeichnis wechseln dürfen in die Gruppe "lp" aufnehmen. Abgesehen davon wird pacman bei der nächste Installation wieder die Rechteabweichung reklamieren. "pacman -Qkk cups" zeigt übrigens bei mir noch einige weitere Abweichung der Rechte für einzelne Dateien an.

Bei mir ist das auch so.

Ich habe

sudo pacman -Syu
sudo systemctl stop cups.service
sudo systemctl daemon-reload
sudo systemctl disable cups.service
sudo systemctl daemon-reload
sudo systemctl start org.cups.cupsd.service
sudo systemctl enable org.cups.cupsd.service
sudo rm -R /var/cache/cups/
sudo pacman -S cups libcups
sudo pacman -Syu

gemacht, und dann kommt folgendes:

[me@mypc ~]$ sudo pacman -Qkk cups
Warnung: cups: /etc/cups/classes.conf (Berechtigungen stimmen nicht überein)
Warnung: cups: /etc/cups/classes.conf (Zeit der Veränderung stimmt nicht überein)
Warnung: cups: /etc/cups/classes.conf (Größen stimmen nicht überein)
Warnung: cups: /etc/cups/printers.conf (Berechtigungen stimmen nicht überein)
Warnung: cups: /etc/cups/printers.conf (Zeit der Veränderung stimmt nicht überein)
Warnung: cups: /etc/cups/printers.conf (Größen stimmen nicht überein)
Warnung: cups: /etc/cups/subscriptions.conf (Berechtigungen stimmen nicht überein)
Warnung: cups: /etc/cups/subscriptions.conf (Zeit der Veränderung stimmt nicht überein)
Warnung: cups: /etc/cups/subscriptions.conf (Größen stimmen nicht überein)
Warnung: cups: /etc/dbus-1/system.d/cups.conf (Zeit der Veränderung stimmt nicht überein)
Warnung: cups: /etc/pam.d/cups (Zeit der Veränderung stimmt nicht überein)
Warnung: cups: /etc/xinetd.d/cups-lpd (Zeit der Veränderung stimmt nicht überein)
cups: 506 Dateien gesamt,6 veränderte Dateien

Muss ich mir darüber Gedanken machen?


edit: Nachtrag: Auch wenn ich nach der Neuinstallation von cups nochmal

 sudo systemctl restart org.cups.cupsd.service

mache kommt immernoch der gleiche Output.

Martin-MS
02.11.2014 11:52:11
jlp2 schrieb:

Durch die veränderten, eingeschränkten Rechte des neueren cups-Packetes, kann auf die angelegten Cache-Verzeichnisse nicht mehr zugegriffen werden.
Nach dem löschen werden die Verzeichnisse neu angelegt, OHNE Zugriffsfehler...

Ich hatte die Meldung nach dem Update auch und die Rechte dann mit chmod 770 angepasst.

Zuvor konnte jeder in das Verzeichnis /var/cache wechseln, das scheint wohl ein Sicherheitsrisiko gewesen zu sein. Jetzt kann es nur noch der Benutzer "root" und die Gruppe "lp". Das Verzeichnis aber einfach zu löschen und neu anlegen zu lassen kann aber nicht die Lösung sein, denn damit wird das Sicherheitsrisiko erneut provoziert.

Statt dessen sollte man sich bzw. die Benutzer die in dieses Verzeichnis wechseln dürfen in die Gruppe "lp" aufnehmen. Abgesehen davon wird pacman bei der nächste Installation wieder die Rechteabweichung reklamieren. "pacman -Qkk cups" zeigt übrigens bei mir noch einige weitere Abweichung der Rechte für einzelne Dateien an.

jlp2
02.11.2014 09:40:57

Was sagt

journalctl -b | grep cups

Werden da Zugriffsfehler angezeigt, neuen org.cups.cupsd.service noch mal stoppen und das Verzeichnis /var/cache/cups löschen.

Danach die Pakete "cups libcups" nochmal installieren.

Durch die veränderten, eingeschränkten Rechte des neueren cups-Packetes, kann auf die angelegten Cache-Verzeichnisse nicht mehr zugegriffen werden.

Nach dem löschen werden die Verzeichnisse neu angelegt, OHNE Zugriffsfehler...

stefanhusmann
01.11.2014 23:37:43
k.osmo schrieb:

Hat im Zuge des Updates noch jemand die Meldung von pacman:

[2014-11-01 10:19] [ALPM] warning: directory permissions differ on /var/cache/cups/
filesystem: 775  package: 770

zu verzeichnen, und/oder kann mir einen Tipp geben, was der Hintergrund des Rechtekonflikts sein könnte?

Bei mir hat /var/cache/cups die Rechte 770.  Warum bei die die Rechte 775 sind, weiß ich nicht. Kommt mir zu weitgehend vor.

nologin
01.11.2014 22:05:23
stefanhusmann schrieb:

Danke für den Hinweis.

Immer wieder gerne,

pitt

ArchChem
01.11.2014 21:01:55

Hallo und ganz lieben Dank fürs schnelle Posten (schneller als im englischen Forum smile)!

Ich hätte nämlich sonst echt Probleme gekriegt, wenn mein CUPS plötzlich nicht mehr funktioniert hätte... Diese Änderung ist echt sinnlos... sad

Beste Grüßle
ArchChem

k.osmo
01.11.2014 19:22:10

Hat im Zuge des Updates noch jemand die Meldung von pacman:

[2014-11-01 10:19] [ALPM] warning: directory permissions differ on /var/cache/cups/
filesystem: 775  package: 770

zu verzeichnen, und/oder kann mir einen Tipp geben, was der Hintergrund des Rechtekonflikts sein könnte?

Fußzeile des Forums

Powered by FluxBB