Arch Linux

nologin

Gast

cups.service

mit dem Update vom 1.11.14 wird cups.service umbennannt in org.cups.cupsd.service. Also mit systemctl den Dienst cups.service eleminieren und org.cups.cupsd.service starten.

Gruß

maltem

Mitglied

Re: cups.service

Ui, wer hat sich das denn ausgedacht...

stefanhusmann

Moderator

Re: cups.service

Danke für den Hinweis.

systemctl disable cups.servisce
systemctl enable org.cups.cupsd.service
systemctl start org.cups.cupsd.service

Kerberos

Mitglied

Re: cups.service

Bei mir bekam ich folgende Meldung von pacman:

[ALPM-SCRIPTLET] > systemd unit names have been renamed
[ALPM-SCRIPTLET] > you should systemctl stop and disable cups.service and
[ALPM-SCRIPTLET] > systemctl daemon-reload, start and enable org.cups.cupsd.service

Dirk

Moderator

Re: cups.service

Ui, wer hat sich das denn ausgedacht...

Das kommt vermutlich direkt aus der Kanzel des Elfenbeinturms, genau wie enp0s26f7u3u3 für eine Netzwerkkarte.

runiq

Mitglied

Re: cups.service

Das sieht nach DBus-Pfad aus. Was mich ein bisschen wundert, da CUPS keine Aktivierung über den DBus unterstützt.

Dirk

Moderator

Re: cups.service

Jo Es ergibt ohne Erklärung absolut keinen logisch herleitbaren Sinn.

k.osmo

Mitglied

Re: cups.service

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?

ArchChem

Mitglied

Re: cups.service

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

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

Beste Grüßle
ArchChem

nologin

Gast

Re: cups.service

Danke für den Hinweis.

Immer wieder gerne,

pitt

stefanhusmann

Moderator

Re: cups.service

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.

jlp2

Mitglied

Re: cups.service

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...

Beitrag geändert von jlp2 (02.11.2014 10:16:58)

Martin-MS

Mitglied

Re: cups.service

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.

Kopfweh

Mitglied

Re: cups.service

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.

Beitrag geändert von Kopfweh (02.11.2014 15:01:53)

k.osmo

Mitglied

Re: cups.service

@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?

Beitrag geändert von k.osmo (02.11.2014 15:37:38)

Martin-MS

Mitglied

Re: cups.service

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.

tapsiturtle

Mitglied

Re: cups.service

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.

k.osmo

Mitglied

Re: cups.service

@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)

jlp2

Mitglied

Re: cups.service

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

Martin-MS

Mitglied

Re: cups.service

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.

k.osmo

Mitglied

Re: cups.service

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

Mitglied

Re: cups.service

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.