Nyomtatás PDF printerre és utána a fájl automatikus megjelenítése.

Beküldte Káldeus -

Fórum: 

Sziasztok! A Linuxon a PDF printer haszálata során felmerült olyan igényem, hogy a kinyomtatott fájlt a nyomtatás után automatikusan látni szeretném egy megjelenítőben. A Wi* operációs rendszeren ez a különféle PDF nyomtatók telepítése során az esetek 90%-ában egy egyszerű checkbox kiválasztásával aktiválható, azonban Linux alatt nem találtam erre megoldást. (Akinek van, az ne is olvasson tovább, hanem küldje a megoldást...)

Mindenesetre én nem találtam. Ezért nekiláttam saját megoldást összehozni. Ennek során az Interneten láttam megoldásokat, amelyek nem működtek és megválaszolatlanok maradtak, illetve amik nekem legalább is nem bizonyultak használhatónak, de jó kiindulás alapok voltak.

Sikerült megoldást találnom, de a végső befejezés még hiányzik, ezért gondoltasm, hogy közzéadom, hátha valakinek van ötlete. Mivel ez haladó szintű topic, nem vacakolnék a részletekkel, csak a lényeget írom le, ebből minden látszani fog:

A Cups ProstProcessing funckióját aktiválom úgy, hogy az indítja el az általam létrehozott szkriptet, ami indít egy PDF nézőt a paraméterként átadott fájlnévvel és kész. Ez így szépen hangzik és működik is, problémát ld. a legvégén. Részletezve:

A szkript rövid, tehát bemásolom ide:

#!/bin/bash
DISPLAY=":0.0"
export DISPLAY
XAUTHORITY=/home/$2/.Xauthority
export XAUTHORITY
xdg-open $1 &

1.) Bemásolom a szkriptet ide az alábbi névvel: /var/spool/cups-pdf/pdf_to_view.sh
2.) A fájlt a felhasználó tulajdonába és csoportjába helyezem;
3.) Tulaj minden, többiek olvasási és végrehajtási jog neki (755);
4.) Módosítom az /etc/cups/cups-pdf.conf fájlt kb. a 258. sornál így:
PostProcessing /bin/bash /var/spool/cups-pdf/pdf_to_view.sh
(Itt ahol köztes blank van, szigorúan csak 1 legyen, úgyszintén az esetleges trailing blankseket törölni)

És maris mehet a nyomtatás PDF printerre akárhonnét, nyomtatás után azonnal meg fog jelenni a nézőben....azaz mégsem!

Ez a probléma legfőbb oka! Ugyanis az apparmor nem engedi a cups megváltozott viselkedését, ezért ez a projekt csak akkor életképes, ha még az első pont előtt végrehajtom a következőket (nyugi, Virtualboxban tesztelek mindig):
a) Leállítom az apparmor service-t
b) Törlöm végleg az apparmort (purge)
c) Törlöm a visszamaradt appamor könyvtárakat: sudo rm -R /etc/apparmor*
d) Újraindítom a gépet

És csak eztuán kezdem el az 1,2,3,4 pontokat és akkor működik! A hosszú bevezető után akkor itt a kérdésem/kérésem magától adódik: aki érzi magában az erőt és tudást, hogy hogyan kell az apparmort úgy paraméterezni, hogy ne tiltsa le a PostProcessing szkriptemet, az mutasson utat, hogy mit kell csinálnom ehhez. Mert azért az nem megoldás, hogy kiirtjuk az apparmort, ez tesztelés során OK, de minden napi használatra nem. Néhányan a Neten az aa-complain módban látták a megoldást, de ez is biztonsági rés, gyakorlag kikapcsolta az apparmor védelmi funckióját, csak loggol, nálam még azt sem, nem sok a különbség.

Én ezzel próbálkoztam: megnyitottam az
/etc/apparmor.d/usr.sbin.cupsd -t
lementem oda, ahol valami ilyesféle volt: /usr/lib/cups/backend/cups-pdf és ott beszúrtam ezt a három sort
/bin/bash ixr,
/var/spool/cups-pdf/pdf_to_view.sh r,
/usr/bin/xdg-open ixr,

de ez sem segített, a logban DENY volt. Tehát: apparmor szakértők és lelkes fanok, várom ötleteiteket!

kimarite képe

/var/spool/cups-pdf/pdf_to_view.sh r

Beküldte kimarite -

Még nem igazán látom át a módszered, de az r szerintem kevés az Apparmor-nak a '/var/spool/cups-pdf/pdf_to_view.sh' sorban, kéne egy x is (a futtatás, hiszen ez egy futtatható script). Régebben használtam az Apparmor-t, a mások által említett 'sudo aa-complain /path/to/bin' egy tesztelős dolog, nem úgy biztonsági rés, ahogy gondolod. Így beállítva, a logolásból lehet szabályokat alkotni és aztán, ha minden rendben, jöhet a 'sudo aa-enforce /path/to/bin'. Inkább ezt kéne erőltetni és nem vaktában lőni, mert más összefüggések is lehetnek.
-- https://wiki.ubuntu.com/DebuggingApparmor # bár én inkább valami más Wiki-t nézegettem, mert van még néhány parancs ezeken kívül, de az említtetek is elegendők lehetnek.
-- https://www.apt-browse.org/browse/ubuntu/trusty/main/i386/cups-daemon/1.... # egy példa

Értékelés: 

0
Még nincs értékelve

/var/spool/cups-pdf/pdf_to_view.sh r

Beküldte Káldeus -

#1 Köszi válaszodat :-) viszont nem csak a read nem megy le, hanem mindhárom sorra "deny"-t kapok. A cups logja 0-ás return kóddal simán lemegy, tehát ok:

paste.ubuntu.com/25853192/

Viszont az apparmor kernel log azt mutatja, hogy mind a három sorom elutasításra került.

paste.ubuntu.com/25853210/

Ha csak az x hiányzona, akkor a többi jó kellene hogy legyen (szerintem, de ez nem biztos). Akkor, ha legalább egy sorom "átmegy", akkor sejteném a jövőt, mint macska az esőt, de így egyelőre sötétben toporgok...

Értékelés: 

0
Még nincs értékelve
kimarite képe

/var/spool/cups-pdf/pdf_to_view.sh r

Beküldte kimarite -

#1 Másfelől nézve, itt
http://www.cups-pdf.de/cups-pdf-CURRENT/extra/cups-pdf.conf

### Key: Grp (config)
##  group cups-pdf is supposed to run as - this will also be the gid for all
##  created directories and log files
### Default: lp

#Grp lp

próbáld így beállítani:

### Key: Grp (config)
##  group cups-pdf is supposed to run as - this will also be the gid for all
##  created directories and log files
### Default: lp

Grp lpadmin

Ha ez a nyomtatási csoportod.

Erre
https://www.cups.org/doc/man-cups-files.conf.html?TOPIC=Man+Pages
(https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1088448)

SystemGroup group-name [ ... group-name ]
    Specifies the group(s) to use for @SYSTEM group authentication. The default contains "admin", "lpadmin", "root", "sys", and/or "system".

alapozok.

Értékelés: 

0
Még nincs értékelve
kimarite képe

/var/spool/cups-pdf/pdf_to_view.sh r

Beküldte kimarite -

#2 Egyszerre írtunk, de én nem erre:
„Ha csak az x hiányzona, akkor a többi jó kellene hogy legyen (szerintem, de ez nem biztos).”
-- szerintem összefüggések vannak, legalábis így értelmeztem, amikor anno én megoldottam valamit. :D
-- most nem pörög annyira erre rá az agyam, de megtaláltam az egyik megfigyelt oldalt:
http://wiki.apparmor.net/index.php/AppArmor_Failures
-- szóval, ki kell találni a gondot, és összerázod egésszé:
https://www.youtube.com/watch?v=nfWlot6h_JM (ahogy linkelik az egyik fórumon, hasonló problémára)
;)

Értékelés: 

0
Még nincs értékelve
kimarite képe

Saccperkábé

Beküldte kimarite -

#4 Szóval így kell debuggolni  _a cím szerint_

output is:
- mysql cannot read /etc/mysql
Aug 7 18:22:17 c505 kernel: [ 1485.490459] audit: type=1400 audit(1470619337.926:98): apparmor="DENIED" operation="open" profile="/usr/sbin/mysqld" name="/etc/mysql/my.cnf.migrated" pid=11219 comm="mysqld" requested_mask="r" denied_mask="r" fsuid=109 ouid=0

GET_AROUND:
sudo nano /etc/apparmor.d/usr.sbin.mysqld
line 25 after:
# Allow config access
  /etc/mysql/** r,
-add line:
  /etc/mysql/* r,

systemctl restart apparmor.service

service mysql stop
service mysql start

- problem is gone

Forrás: https://bugs.launchpad.net/ubuntu/+source/mysql-5.7/+bug/1610765

Szerk.: remélem, már te is érted (legtöbbször csak úgy egyszerűen 'működik' is, csak néha függ össze mással is), de még két példa:
https://askubuntu.com/questions/172030/how-to-allow-bind-in-app-armor/22...
https://askubuntu.com/questions/175704/unable-to-start-mysql-server-afte...

Értékelés: 

0
Még nincs értékelve

Saccperkábé

Beküldte Káldeus -

#5 Igen, kezdem érteni...és minél inkább belemélyedek, annál inkább hatalmasodik el bennem az érzés, hogy az egész apparmor projekt rossz irányba mutat. Mert most, hogy már kicsit belülről is látom a dolgokat: mindössze néhány profil van települve alapértelmezésben. Jó, van még az apparmor-profiles és az apparmor-profiles-extra, de az sem fedi le az alapértelmezett programkészletet sem, amivel a Mint feltelepül. Ráadásul az utóbbi két profil között, ami a Xenial Xerus tárolóból települ, már van eleve "gyári hibás", amit a log szerint nem is vesz figyelembe. Maradék ötven százalék pedig "complain" módban települ, ami teszteléshez biztos jó, de védelem szempotjából annyit ér, mint hintalovon a patkó.
Ráadásul mi van akkor, ha új programot telepítek? Ez olyan meglepő számára? Az egésznek akkor lenne értelme, ha képes lenne együttműködni valamelyik csomagtárolóval és az új program telepítése után triggerelődne valami eljárás, amivel beveszi őt is a szárnyai alá. De erről szó sincs. És ezzel el is jutottunk az elejére: hamis biztonságértzetet kelt, mivel fut és Besenyő Á.F. István, aki vagyok, azaz Besenyő Átlag Felhasználó Pista abban a hitben élek, hogy fut a védelem, pedig lyukas, mint a szita. És miért kellene nekem vért izzadva kitalálnom egy új program minden rezdülését, hogy armor alá helyezzem??? A 21. században??? Íme egy konkrét példa: használom a masterpdfeditor nevű programot, amelyik a 3.xx verzióig ezen a néven futott. A frissítések során a 4.xx verziótól kezdve már masterpdfeditor4 névre hallgat, de ez kutakodás nélkül nem derül ki. Ha kiizzadtam volna korábban egy armort neki, itt máris elbukott volna, mivel a frissítés ezt nem jelzi ki és nem is feladata.
Összefoglalva: részemről az apparmornak annyi, csak akadályoz és nem nyújt semmit, ami használható lenne. Annyit kiderítettem, hogy amennyiben csak a kér "cups" profilt törlöm, akkor már működik is az, ami a topic címe, tehát nem muszáj az egészet letörölni. De ezt én megoldásnak tekintem a magam számára, de épp a fenti egyéni véleményem miatt nem merném "megoldva" flaggel ellátni, habár én a felvetésemet így megoldottnak tekintem.
Ismét egy jó kis meccs volt... Reméltem, hogy rákapsz erre a témára, nem is csalódtam, az összefoglalásomhoz várom utóvéleményedet... Üdv: ~K~

P.S.: a témákhoz kapcsolódó Youtube-os videóidat mindig felüldülés nézni, le ne szokj róla... :-)

Értékelés: 

0
Még nincs értékelve

Utóirat utóirata: +egy érv az

Beküldte Káldeus -

Utóirat utóirata: +egy érv az apparmor ellen: ez az egész topic meg sem született volna, ha ez az általam most már egyáltalán nem tisztelt "program" dobott volna valamilyen hibaüzenetet, hogy megadályozta egy program futását. Fáj neki a Zenity vagy valami??? Ez a minimális elvárás már a ZX Spectrumok idején is működött... Az, hogy sunyiban hallgat és hazavág egy amúgy jól működő programot, sőt, program-ágat, logikailag inkább hasonlít egy vírus működéséhez... Többet egy szót sem írok róla, esküszöm, de ezt ki kellett mondanom...

Értékelés: 

0
Még nincs értékelve
kimarite képe

Utóirat utóirata: +egy érv az

Beküldte kimarite -

#7 Ha jól tudom, az Apparmor profilokat a Canonical kezdte felépíteni, vagyis egészen pontosan több profilt készített, mint volt eleve, aztán meg, mint látod, abbahagyták. És úgy használható, hogy te készíted el (javítod) a profilokat az 'aa-complain' jelzések alapján, aztán, ha nincs hiba jelzés, akkor az 'aa-enforce'-val fixálod, azaz élesíted a tanulási, másképpen beállítási folyamatot. Van egy parancs (most nem jut eszembe), ami nagyjából elkészít egy profilt, de nem túl sok dolgot tesz bele sajnos, tehát nem eleget. Jó lett volna, ha a Canonical -vagy valaki, tulajdonképpen a világban- továbbra is foglalkozik a témával, ha már elkezdte :-), úgymond nyugodtan belehízhattak volna a pólóba (mint az egyszeri programozó), és örökké szerelmesek egy 'néger' (Ubuntu) lányba (Apparmor). Így meg csak ez van sajna: ... „együtt a világ végén boldogok lehettünk volna”. És elkészítik a letölthetően kész profilokat mindegyik vagy a legtöbb alkalmazásra, illetőleg valami olyasmit (is) elkészítenek, ami akár egy script, hogy a környezettől függően elkészülhessenek a profilok, ahelyett, hogy neked kéne ennyit 'varázsolnod' ezzel a témával. Hasonló alkalmazás: az SELinux ... .

Értékelés: 

0
Még nincs értékelve