El 14/09/16 a les 13:23, Xavi Drudis Ferran ha escrit: > El Tue, Sep 13, 2016 at 08:31:50PM +0200, Narcis Garcia deia: >> Hola; >> >> He aprofitat la característica de CUPS per crear una impressora virtual >> i fer-la treballar amb un programet (script) a /etc/cups/interfaces/ >> La meva intenció és que, quan l'usuari trii imprimir amb aquesta >> impressora virtual, transferir el document a un ordinador remot (~scp) i >> executar la instrucció «lp document» a l'ordinador remot per a què >> s'imprimeixi localment des d'allà. >> >> Això implica pel cas un programet com a: >> /etc/cups/interfaces/Epson1 > > Sense veure l'script costa (més) de dir... > >> El qual s'executa quan CUPS rep l'orddre d'imprimir per la impressora >> «Epson1», i es fa com a usuari «lp». >> El programet fa la còpia del document, però en intentar executar ssh >> (+expect per posar contrasenya) diu: >> >> You have too many files are open. Close some files or increase your >> per-process descriptor limit. >> > > Aquest error és del client o ve del servidor ? Massa fitxers oberts > no em quadra amb problemes de permissos ni tal. És com si hi hagués > alguna crida recursiva descontrolada, o si provés infinites vegades > d'obrir algun fitxer sense tancar-lo. >
Al servidor tot va bé (he provat a fer manualment des del client tot allò que ha de fer el programet ...interfaces/Epson1); els problemes els tinc al client quan ho fa a partir de la crida de CUPS. Això dels «too many files» no podria ser per una recursivitat provocada per mi, ja que passa quan el programet tira pel dret sense fer «sudo» ni executar-se a sí mateix. >> Com que penso que el límit de 800.000 a nivell de sistema ja és gran, i >> no sé com modificar-ho per «lp»*, doncs intento que el programet es >> cridi a sí mateix com a un usuari normal: >> sudo -n -u UnUsuari "$0" >> > > /etc/security/limits.conf ? He mirat el fitxer i no té cap restricció específica per l'usuari «lp». > man bash i buscar ulimit ? Aquests són els límits per un usuari normal amb Bash: $ ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 63575 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 63575 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited Aquests són els límits obtinguts des del programet (/bin/sh = Dash): $ ulimit -a time(seconds) unlimited file(blocks) unlimited data(kbytes) unlimited stack(kbytes) 8192 coredump(blocks) 0 memory(kbytes) unlimited locked memory(kbytes) 64 process 63575 nofiles 4096 vmemory(kbytes) unlimited locks unlimited > >> I he hagut d'afegir una línia amb visudo**: >> lp ALL = (%users) NOPASSWD: /etc/cups/interfaces/* >> >> Penso que això significa: «L'usuari lp de tots els hosts poden actuar >> com a un membre del grup users sense contrasenya per executar allò que >> hi hagi a /etc/cups/interfaces/» > > Però CUPS surt de tots els grups menys el primari entre el fork() i el exec() > de l'script, vols dir que cola ? > https://github.com/apple/cups/blob/master/scheduler/process.c#L736 > > [...] > > > En qualsevol cas, el que no entenc és perquè no pot el servidor compartir > la impressora per CUPS mateix i accedir-hi el client per IPP. Llavors tindries > més informació de l'estat del treball i tot això, no ? > Hi ha problemes per contactar directament amb el servidor via IPP i altres protocols d'impressió, i la única solució que puc controlar és via fitxer + instrucció per terminal SSH.
