Du bist nicht angemeldet.
Seiten: 1
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ß
Ui, wer hat sich das denn ausgedacht...
Offline
Danke für den Hinweis.
systemctl disable cups.servisce
systemctl enable org.cups.cupsd.service
systemctl start org.cups.cupsd.service
Offline
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
Offline
Ui, wer hat sich das denn ausgedacht...
Das kommt vermutlich direkt aus der Kanzel des Elfenbeinturms, genau wie enp0s26f7u3u3 für eine Netzwerkkarte.
Offline
Das sieht nach DBus-Pfad aus. Was mich ein bisschen wundert, da CUPS keine Aktivierung über den DBus unterstützt.
Offline
Jo Es ergibt ohne Erklärung absolut keinen logisch herleitbaren Sinn.
Offline
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?
Offline
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
Offline
Danke für den Hinweis.
Immer wieder gerne,
pitt
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.
Offline
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)
Offline
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.
Offline
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.
Beitrag geändert von Kopfweh (02.11.2014 15:01:53)
Offline
@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)
Offline
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.
Offline
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.
Offline
@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)
Offline
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
Offline
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.
Offline
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?
Offline
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.
Offline
Seiten: 1