Sziasztok. Pénteken este, és a hétvégén a Cups-pdf beállításaival bajlódtam, de a végén sikerült az egészet valahogy elqúrni. Ezt nem is vettem észre, csak hétfő reggel, mikor jelezték, hogy nem mennek a nyomtatók. A jelenség röviden a következő: A nyomtatás létrejön, a /var/spool/cupsban létrejön a leíró file és a nyomtatandó tartalom, de a filterek már nem férnek hozzá ezekhez, "Unable to open file "/var/spool/cups/d1234567-001": Permission denied". Ha manuálisan átírom a jogosultságot, és újraindítom a nyomtatót, akkor kinyomtatódik, de a következő már megint bentragad. Ez a jogosultság hiba az összes filternél előjön. A nyomtatásnál root:lp -rw-r----- a nyomtatandó tartalom, ezt nem tudják olvasni a filterek. (amiknek elvileg lp userként kéne menniük) Ami még érdekes, hogy a próbanyomtatás képe megváltozott, az eredeti, "csecsás" cups mintaoldal helyett csak egy egyszerű oldalt nyomtat, és más a grafika.
A rendszer: Linux 2.6.37.6-24-desktop #1 SMP PREEMPT 2012-10-18 22:36:08 +0200 x86_64 x86_64 x86_64 GNU/Linux openSUSE 11.4 (x86_64) CODENAME = Celadon CUPS=1.4.6., root:lp
A rendszer tartalmazza az elérhető frissítéseket, de dist upgrade nem lehet szerveren futó linuxos ERP rendszer miatt, ami egyedi fejlesztés(volt) és itt megállt. Előtte tökéletesen működött, most valami nagyon el lett cseszve.
Eddig az alábbiakat néztem át: debug bekapcsolva, logban a hibán kívül semmi támpont. Apparmor cups profil letiltva, apparmor eltávolítva. cups config default (sys root), a könyvtárak és a file-ok mérete, jogosultsága (/etc/cups, usr/lib/cups, usr/share/cups) megegyeznek a telepítőcsomag eredeti állományaival. Próbáltam azt is, hogy a /var/cache/cups alól kitöröltem amit lehetett, semmi. Próbáltam azt is, hogy egy-egy nyomtatót töröltem, majd újratelepítettem. Semmi. Egy másik szerveren levő ugyanilyen CUPS jogosultságai, beállításai alapján átnéztem mindent. Semmi. Így három nap után kezdem feladni, már minden szóba jöhető ötletet végignéztem.
Jelenleg egy végtelenített script fut, ami kb 30 másodpercenként átírja a jogosultságot, és újraindítja a nyomtatást, így működőképes maradt a rendszer, de ez csak gányolás.
Ami nem jöhet szóba: Dist upgrade, Cups újratelepítés (kb 50 nyomtató van szanaszét a megyében, ami 05-22 idő alatt full-ba nyomja, utána meg indulnak a mentési és egyéb hosszabb scriptek)
Valakinek valami ötlete, tippje??? Előre is köszönöm!
Utóirat, hátha így érthetőbb:
$id lp -> uid=4(lp) gid=7(lp) csoportok=7(lp)
Ezeket a dir jogosultságokat a cups állítja be, mikor újrainditódik, hiába módosítod bármi másra, a beállítás az első cups restartig él.
/var/spool │drwxr-xr-x│root│root│
/var/spool/cups │drwx--x---│root│lp │
/var/spool/cups/c1429149 │ 815│-rw-------│root│lp │
/var/spool/cups/d1429149-001 │ 5759│-rw-r-----│root│lp │
Az auditlogban az látszik, hogy az lp jogosultsággal futó socket (de mindegyik filternél ugyan ez a helyzet) nem tudja olvasni a nyomtatást
type=PATH msg=audit(1488573307.419:2162): item=0 name="/var/spool/cups/" inode=6029564 dev=08:13 mode=040710 ouid=0 ogid=7 rdev=00:00
type=PATH msg=audit(1488573307.419:2162): item=1 name="/var/spool/cups/" inode=6029564 dev=08:13 mode=040710 ouid=0 ogid=7 rdev=00:00
type=PATH msg=audit(1488573307.419:2162): item=2 name="/var/spool/cups/00000000" inode=6035245 dev=08:13 mode=0100640 ouid=0 ogid=7 rdev=00:00
type=PATH msg=audit(1488573307.419:2162): item=3 name="/var/spool/cups/d1429149-001" inode=6035245 dev=08:13 mode=0100640 ouid=0 ogid=7 rdev=00:00
type=SYSCALL msg=audit(1488573307.422:2163): arch=c000003e syscall=2 success=no exit=-13 a0=7fff3ccdbcc9 a1=0 a2=0 a3=7fff3ccd8b60 items=1 ppid=18624 pid=18790 auid=1277 uid=4 id=7 euid=4 suid=4 fsuid=4 egid=7 sgid=7 fsgid=7 tty=(none) ses=1337 comm="socket" exe="/usr/lib/cups/backend/socket" key="cups_spool_dir_access"
/var/log/audit # ausearch -a 2162
time->Fri Mar 3 21:35:07 2017
type=PATH msg=audit(1488573307.419:2162): item=3 name="/var/spool/cups/d1429149-001" inode=6035245 dev=08:13 mode=0100640 ouid=0 ogid=7 rdev=00:00
type=PATH msg=audit(1488573307.419:2162): item=2 name="/var/spool/cups/00000000" inode=6035245 dev=08:13 mode=0100640 ouid=0 ogid=7 rdev=00:00
type=PATH msg=audit(1488573307.419:2162): item=1 name="/var/spool/cups/" inode=6029564 dev=08:13 mode=040710 ouid=0 ogid=7 rdev=00:00
type=PATH msg=audit(1488573307.419:2162): item=0 name="/var/spool/cups/" inode=6029564 dev=08:13 mode=040710 ouid=0 ogid=7 rdev=00:00
type=CWD msg=audit(1488573307.419:2162): cwd="/"
type=SYSCALL msg=audit(1488573307.419:2162): arch=c000003e syscall=82 success=yes exit=0 a0=7f22f4936e64 a1=7fff4c69d670 a2=7fff4c69d68c a3=63205d303031302b items=4 ppid=1 pid=18624 auid=1277 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1337 comm="cupsd" exe="/usr/sbin/cupsd" key="cups_spool_dir_access"
/var/log/audit # ausearch -a 2163
time->Fri Mar 3 21:35:07 2017
type=PATH msg=audit(1488573307.422:2163): item=0 name="/var/spool/cups/d1429149-001" inode=6035245 dev=08:13 mode=0100640 ouid=0 ogid=7 rdev=00:00
type=CWD msg=audit(1488573307.422:2163): cwd="/"
type=SYSCALL msg=audit(1488573307.422:2163): arch=c000003e syscall=2 success=no exit=-13 a0=7fff3ccdbcc9 a1=0 a2=0 a3=7fff3ccd8b60 items=1 ppid=18624 pid=18790 auid=1277 uid=4 gid=7 euid=4 suid=4 fsuid=4 egid=7 sgid=7 fsgid=7 tty=(none) ses=1337 comm="socket" exe="/usr/lib/cups/backend/socket" key="cups_spool_dir_access"
A CUPS webes admin felületén pedig ott virít, hogy: pending since 2017....Unable to open print file "/var/spool/cups/d1429149-001": Permission denied
Ezek után tipp valakitől? Mit nem látok???
Megoldás:
A cups-pdf (valami béta verzió volt) elállította a /var/spool/cups umask értékét, konkrétan kitörölte, üres volt. Ennek beállítása után (getfacl, setfacl) helyreállt minden.
- 1682 megtekintés
Hozzászólások
Csak egy ötlet: ha a user-eket felveszed az lp csoportba, tudják majd olvasni a file-okat, hiszen az lp csoportnak van olvasási joga a file-ra.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Kipróbáltam, nem ez a gond. Az userek tudnak nyomtatni, a spool file-ok létrejönnek, a command, postscript, és egyéb filterek nem tudják olvasni a spool-t.
- A hozzászóláshoz be kell jelentkezni
Akkor azt nézd meg, azok a process-ek, amelyek nem tudják olvasni, kinek a nevében futnak.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
A cups root-ként fut, de a processeket nem tudom monitorozni, mert nem marad futó állapotban, hanem leáll azonnal. (Az előző lp+userekhez még annyit, hogy előtte sem kellett, és a másik gépen is e nélkül megy. de én is kipróbáltam.)
- A hozzászóláshoz be kell jelentkezni
Ugyan Fedora 25-ön nézem, 4.9.13-as kernelem van, 2.2.0-ás cups, de ezt látom az /etc/cups/cups-files.conf file-ban:
# Default user and group for filters/backends/helper programs; this cannot be
# any user or group that resolves to ID 0 for security reasons...
#User lp
#Group lp
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Itt számit a verzió. Az 1.4.6-nál az LP:LP-re azt mondja újraindítás után, hogy az nem jó, és átállitja lp:nobody-ra, de ne kérdezd, hogy miért. Ez a verzio sys:root configgal megy, ebben biztos vagyok.
- A hozzászóláshoz be kell jelentkezni
Nem ez volt a mondandóm lényege, hanem az, hogy a konfigurációs file-ban megadhatod, ezek a file-ok milyen tulajdonossal és csoporttal jöjjenek létre. Figyelj arra, hogy default ki van kommentelve!
Szerk.: és persze LP:LP != lp:lp
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Az én mondandóm meg az volt, hogy ezen a verzión ez nem működik, mert ha a configban ez van:
#SystemGroup sys root
SystemGroup lp lp
akkor ez van a logban:
Loaded configuration file "/etc/cups/cupsd.conf"
Group and SystemGroup cannot use the same groups!
Resetting Group to "nobody"...
és igen, az LP:LP != lp:lp :-)
Update, hogy megnyugodjon a lelkiismeretem:
Configba bekerült: user:lp group:lp, majd próbanyomtatás:
"Unable to open banner file "/var/spool/cups/d1422070-001" - Permission denied", a létrehozott file: root │lp │-rw-r-----│
- A hozzászóláshoz be kell jelentkezni
OK, de nálam nem ez van. Van SystemGroup is, de amit én mondtam, az fölötte van. Hogy jobban lásd:
#
# File/directory/user/group configuration file for the CUPS scheduler.
# See "man cups-files.conf" for a complete description of this file.
#
# List of events that are considered fatal errors for the scheduler...
#FatalErrors config
# Do we call fsync() after writing configuration or status files?
#SyncOnClose Yes
# Default user and group for filters/backends/helper programs; this cannot be
# any user or group that resolves to ID 0 for security reasons...
#User lp
#Group lp
# Administrator user group, used to match @SYSTEM in cupsd.conf policy rules...
# This cannot contain the Group value for security reasons...
SystemGroup sys root wheel
# User that is substituted for unauthenticated (remote) root accesses...
#RemoteRoot remroot
# Do we allow file: device URIs other than to /dev/null?
#FileDevice No
# Permissions for configuration and log files...
#ConfigFilePerm 0640
#LogFilePerm 00600
# Location of the file logging all access to the scheduler; may be the name
# "syslog" (syslog means systemd journal by default). If not an absolute path, the value of ServerRoot is used as the
# root directory. Also see the "AccessLogLevel" directive in cupsd.conf.
AccessLog /var/log/cups/access_log
# Location of cache files used by the scheduler...
#CacheDir /var/cache/cups
# Location of data files used by the scheduler...
#DataDir /usr/share/cups
# Location of the static web content served by the scheduler...
#DocumentRoot /usr/share/cups/www
# Location of the file logging all messages produced by the scheduler and any
# helper programs; may be the name "syslog" (syslog means systemd journal by default). If not an absolute path, the value
# of ServerRoot is used as the root directory. Also see the "LogLevel"
# directive in cupsd.conf.
ErrorLog syslog
# Location of fonts used by older print filters...
#FontPath /usr/share/cups/fonts
# Location of LPD configuration
#LPDConfigFile
# Location of the file logging all pages printed by the scheduler and any
# helper programs; may be the name "syslog" (syslog means systemd journal by default). If not an absolute path, the value
# of ServerRoot is used as the root directory. Also see the "PageLogFormat"
# directive in cupsd.conf.
PageLog /var/log/cups/page_log
# Location of the file listing all of the local printers...
#Printcap /etc/printcap
# Format of the Printcap file...
#PrintcapFormat bsd
#PrintcapFormat plist
#PrintcapFormat solaris
# Location of all spool files...
#RequestRoot /var/spool/cups
# Location of helper programs...
#ServerBin /usr/lib/cups
# SSL/TLS keychain for the scheduler...
#ServerKeychain ssl
# Location of other configuration files...
#ServerRoot /etc/cups
# Location of Samba configuration file...
#SMBConfigFile
# Location of scheduler state files...
#StateDir /var/run/cups
# Location of scheduler/helper temporary files. This directory is emptied on
# scheduler startup and cannot be one of the standard (public) temporary
# directory locations for security reasons...
#TempDir /var/spool/cups/tmp
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Az user/group paraméter nem volt az előző konfigban, és a másik két szerveren is enélkül a paraméter nélkül MŰKÖDIK. Most még egyszer kipróbáltam az összes verziót (root:lp, lp:lp, lp:root) de az eredmény ugyanaz mindegyiknél. Valami más van elállítódva.
Up!
- A hozzászóláshoz be kell jelentkezni
Erre azt tudom mondani, hogy te tudod, mihez nyúltál hozzá, hiszen ez valaha működött. Sőt, ha jól értelek, van olyan géped, ami most is jó, tehát akár file-onként össze tudod hasonlítani őket.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Az összehasonlításon már túl vagyok. Fájlonként. Dátumonként. Méretenként. Jogosultságonként. A cups-pdf lett telepítve, majd eltávolítva. Ennek ellenére sem stimmel valami. Igen. Ha tudnám, hogy mi állítódott el, akkor valószínűleg nem ide írtam volna. :-( De ezzel kezdtem az egész topicot... Ezeken már túl vagyok.
- A hozzászóláshoz be kell jelentkezni
Azért gondolom, érzed az ellentmondást. Még felhasználónként is vannak a cups-nak beállításai, bár azt nem hiszem, hogy ilyen globális dolog, mint a jogosultság kezelés így lenne megoldva. Gyakorlatilag kizárt.
Jut eszembe, írtad a cups-pdf-et. Egyrészt jó cucc, én használom, szeretem, működik, amellett van fizikai nyomtatóm, az is működik, szóval nem hinném, hogy önmagában ez lenne a baj. Ugyanakkor gondold csak végig, mi történik.
Telepítéskor felkerülnek a cups-pdf csomag file-jai. Módosítasz a konfigján. Aztán eltávolítod. Minden eltávolításra kerül, kivéve a cups-pdf módosított konfigja, illetve azok a file-ok, amelyek esetleg a post install script által jöttek létre. Ennek is nézz utána, mert ez a konfig hatással lehet a cups szerver működésére.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Process accounting vagy auditd segitene kibogaraszni, mi is tortenik (mi milyen felhasznalokent fut). Utana mar konnyebb lenne rajonnod, mi ment felre. A frissithetetlen rendszer meg vagy containerbe, vagy VM-be valo.
- A hozzászóláshoz be kell jelentkezni
Köszi a tippet, én is átnéztem már, de ha kiküldök egy nyomtatást, ide semmi hibát nem ír, sőt, semmit se ír.
Ilyeneket látok benne:
type=AVC msg=audit(1488523445.665:1153): apparmor="DENIED" operation="change_hat" info="unconfined" error=-1 pid=21267 comm="sshd"
- A hozzászóláshoz be kell jelentkezni
Gondolom nincs audit szabalyod a /var/spool/cups konyvtarra, vmi ilyesmit vegyel fel pl:
-w /var/spool/cups/ -p rw -k cups_spool_dir_access
es utana nezd meg ausearch-csel, az minden osszetartozo rekordot kikeres, abbol latszik, tenylegesen milyen felhasznaloval futott a filter.
- A hozzászóláshoz be kell jelentkezni
Köszönöm! Kipróbálom ezt is! Itt az eredmény...
$id lp -> uid=4(lp) gid=7(lp) csoportok=7(lp)
Ezeket a dir jogosultságokat a cups állítja be, mikor újrainditódik, hiába módosítod, a beállítás az első cups restartig él.
/var/spool │drwxr-xr-x│root│root│
/var/spool/cups │drwx--x---│root│lp │
/var/spool/cups/c1429149 │ 815│-rw-------│root│lp │
/var/spool/cups/d1429149-001 │ 5759│-rw-r-----│root│lp │
Az auditlogban az látszik, hogy az lp jogosultsággal futó socket (de mindegyik filternél ugyan ez a helyzet) nem tudja olvasni a nyomtatást
type=PATH msg=audit(1488573307.419:2162): item=0 name="/var/spool/cups/" inode=6029564 dev=08:13 mode=040710 ouid=0 ogid=7 rdev=00:00
type=PATH msg=audit(1488573307.419:2162): item=1 name="/var/spool/cups/" inode=6029564 dev=08:13 mode=040710 ouid=0 ogid=7 rdev=00:00
type=PATH msg=audit(1488573307.419:2162): item=2 name="/var/spool/cups/00000000" inode=6035245 dev=08:13 mode=0100640 ouid=0 ogid=7 rdev=00:00
type=PATH msg=audit(1488573307.419:2162): item=3 name="/var/spool/cups/d1429149-001" inode=6035245 dev=08:13 mode=0100640 ouid=0 ogid=7 rdev=00:00
type=SYSCALL msg=audit(1488573307.422:2163): arch=c000003e syscall=2 success=no exit=-13 a0=7fff3ccdbcc9 a1=0 a2=0 a3=7fff3ccd8b60 items=1 ppid=18624 pid=18790 auid=1277 uid=4 id=7 euid=4 suid=4 fsuid=4 egid=7 sgid=7 fsgid=7 tty=(none) ses=1337 comm="socket" exe="/usr/lib/cups/backend/socket" key="cups_spool_dir_access"
/var/log/audit # ausearch -a 2162
time->Fri Mar 3 21:35:07 2017
type=PATH msg=audit(1488573307.419:2162): item=3 name="/var/spool/cups/d1429149-001" inode=6035245 dev=08:13 mode=0100640 ouid=0 ogid=7 rdev=00:00
type=PATH msg=audit(1488573307.419:2162): item=2 name="/var/spool/cups/00000000" inode=6035245 dev=08:13 mode=0100640 ouid=0 ogid=7 rdev=00:00
type=PATH msg=audit(1488573307.419:2162): item=1 name="/var/spool/cups/" inode=6029564 dev=08:13 mode=040710 ouid=0 ogid=7 rdev=00:00
type=PATH msg=audit(1488573307.419:2162): item=0 name="/var/spool/cups/" inode=6029564 dev=08:13 mode=040710 ouid=0 ogid=7 rdev=00:00
type=CWD msg=audit(1488573307.419:2162): cwd="/"
type=SYSCALL msg=audit(1488573307.419:2162): arch=c000003e syscall=82 success=yes exit=0 a0=7f22f4936e64 a1=7fff4c69d670 a2=7fff4c69d68c a3=63205d303031302b items=4 ppid=1 pid=18624 auid=1277 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1337 comm="cupsd" exe="/usr/sbin/cupsd" key="cups_spool_dir_access"
/var/log/audit # ausearch -a 2163
time->Fri Mar 3 21:35:07 2017
type=PATH msg=audit(1488573307.422:2163): item=0 name="/var/spool/cups/d1429149-001" inode=6035245 dev=08:13 mode=0100640 ouid=0 ogid=7 rdev=00:00
type=CWD msg=audit(1488573307.422:2163): cwd="/"
type=SYSCALL msg=audit(1488573307.422:2163): arch=c000003e syscall=2 success=no exit=-13 a0=7fff3ccdbcc9 a1=0 a2=0 a3=7fff3ccd8b60 items=1 ppid=18624 pid=18790 auid=1277 uid=4 gid=7 euid=4 suid=4 fsuid=4 egid=7 sgid=7 fsgid=7 tty=(none) ses=1337 comm="socket" exe="/usr/lib/cups/backend/socket" key="cups_spool_dir_access"
A CUPS webes admin felületén pedig ott virít, hogy: pending since 2017....Unable to open print file "/var/spool/cups/d1429149-001": Permission denied
Ezek után tipp valakitől? Mit nem látok???
- A hozzászóláshoz be kell jelentkezni
Hmm... A /var/spool alatt minden jo, szoval csak az okozhatna gondot, ha a /var nem lenne jol beallitva, azaz ha nem lenne hozza mindenkinek x joga.
- A hozzászóláshoz be kell jelentkezni
Szerintem az is jó. Ezért nem értem. :-(
/var │4096│root│root│drwxr-xr-x│
De azt is kipróbáltam, hogy su lp, majd cat /var/spool/cups/d1429149-001 : permission denied. :-(
up.
- A hozzászóláshoz be kell jelentkezni
Na jó, de az már a jogokból látszik, hogy nem fog menni. Neked az lp csoportban kell lenned. Tényleg, nem lehet, hogy csak valami ilyesmi hiányzik?
usermod -a -G lp lp
Persze root-ként kiadva, s feltéve, hogy az lp csoport már létezik.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Nem. Olvass vissza, és nézd meg az audit kimenetét.
- A hozzászóláshoz be kell jelentkezni
Bocs, tényleg odamásoltad az id lp kimenetét, s az jó.
Szerk.: komolyabb végiggondolás nélkül jártatom a szám... A /var nem önálló filerendszer? Nem lehet, hogy ebben az esetben valamilyen mount opció korlátoz?
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Ez vonatkozik rá, nincs külön var partició
/dev/disk/by-id/scsi-....b6-part3 / ext4 acl,user_xattr 1 1
de ehhez meg aztán végképp nem nyúlt senki... Valami ACL lesz, de nem tudom, hogy mi?
- A hozzászóláshoz be kell jelentkezni
Akkor lsattr meg getfacl.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Megvan, hogy a .....
A spool/cups mask üres volt, így az effektív acl is üres lett. Javítva, és láss csodát :-) :-) :-) Megint jó!!! Legalábbis itthonról nézve úgy tűnik :-)
Köszönöm a segítséget!!!
- A hozzászóláshoz be kell jelentkezni
Szívesen. :) Különben az a vicces, hogy magadat vezetted rá, én csak egy hajszálnyit tettem hozzá azzal a két paranccsal. :) Viszont magam is tapasztaltam, hogy az együtt gondolkodás motiválttá teszi az embert, s olykor képessé arra, hogy kívülről, más aspektusból lássuk a problémát.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni