+ o -, ma in Ubuntu non ho bisogno di 'giocare' con SUDO perchè tutto quello che mi serve è accessibile al gruppo (audio) cui appartiene il mio utente (marco) e www-data. Fino a li ci arrivo ed è anche molto semplice da mettere in uno script (dove per script io intendo gli script di JavaScripr e/o perl usati dall'applicazione web), dato che non devo fare nulla interattivamente, ma solo configurare correttamente il web server (vera difficoltà inevitabile).
Ciao, Marco.
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction."
— E. F. Schumacher (mis-attributed to A. Einstein)
________________________________________________________________________________
Autore della patch R2 per Squeezelite e del plugin C-3PO. note libere
Logitech media Server 7.9 > miniPc + squeezelite-R2 / SB+ > "Lu Scalmentu" NOS R2R DAC by TubeOne/ AudioResearch DAC 1-20 >
Klimo Merlino Gold TPS > DIS Interconnect > Kent Gold > Reference > Monitor Audio Studio 20 SE
forse hai fatto una installazione un po' troppo minimale? (hai selezionato anche "standard utilities"?)
Comunque ora ho appena aggiunto allo script (ver. 0.15b4) anche l'installazione del pacchetto che installa quel comando.
questo non dovrebbe essere un problema: salvo errori (miei) nel pacchetto, dovrebbe già esserlo per tutti gli utenti.
ok
questo penso ti convenga scriverlo da qualche parte all'interno dell'albero dov'è installata la web-ui... che presumibilmente dovrebbe già essere accessibile all'utente www-data.
OK. I pid files vanno in /run (o /var/run, che è lo stesso).
accesso in scrittura al log di squeezelite? perché? o ad un altro file di log specifico della web-ui?
cioè aggiungi "www-data" al gruppo audio. Non è molto bello... sarebbe preferibile utilizzare sudo per permettere solo i comandi specifici che ti servono (come root o altro utente meno privilegiato, se basta)
OK., anche questi li sistemiamo facilmente con sudo.
OK. Appena ho un attimo ci do una occhiata e preparo un file di configurazione per sudo.
ah. Allora forse c'è qualche problema con il mirror italiano... non sarebbe la prima volta.Meglio NON usarlo. Se si è su rete fastweb conviene usare il loro mirror ( http://debian.fastweb.it/debian/ ), altrimenti quello sulla rete GARR ( http://mi.mirror.garr.it/mirrors/debian/ ), oppure lasciare banalmente quelli di default ( http://ftp.debian.org/debian/ ): tanto poi se si usa lo script al setup dei repositories ci pensa lui.
Ciao, Paolo.
«Se tu hai una mela, e io ho una mela, e ce le scambiamo, allora tu ed io abbiamo sempre una mela per uno. Ma se tu hai un'idea, ed io ho un'idea, e ce le scambiamo, allora abbiamo entrambi due idee.»
Le std utilities le ho installate.forse hai fatto una installazione un po' troppo minimale? (hai selezionato anche "standard utilities"?)
Comunque ora ho appena aggiunto allo script (ver. 0.15b4) anche l'installazione del pacchetto che installa quel comando.
questo non dovrebbe essere un problema: salvo errori (miei) nel pacchetto, dovrebbe già esserlo per tutti gli utenti.
ok
questo penso ti convenga scriverlo da qualche parte all'interno dell'albero dov'è installata la web-ui... che presumibilmente dovrebbe già essere accessibile all'utente www-data.
OK. I pid files vanno in /run (o /var/run, che è lo stesso).
accesso in scrittura al log di squeezelite? perché? o ad un altro file di log specifico della web-ui?
cioè aggiungi "www-data" al gruppo audio. Non è molto bello... sarebbe preferibile utilizzare sudo per permettere solo i comandi specifici che ti servono (come root o altro utente meno privilegiato, se basta)
OK., anche questi li sistemiamo facilmente con sudo.
OK. Appena ho un attimo ci do una occhiata e preparo un file di configurazione per sudo.
ah. Allora forse c'è qualche problema con il mirror italiano... non sarebbe la prima volta.
Squeezelite-R2 -l se eseguito da un utente non nel gruppo audio NON riporta le info su tutti i dispositivi, se eseguito da www-data (ma non da marco, per esempio) restituisce errori, tra cui alcuni di permessi di accesso negato.
Non ho capito perchè e non è nel codice di squeezelite, probabilmente è qualche libreria richiamata da qualche parte.
L'accesso in scrittura al Log mi serve per ruotarlo, altrimenti cresce sempre...
Non ho capito cosa intendi fare (per non perderci tempo in due) uno script che configura sudo all'installazione, cioè senza bisogno per il singolo utente di usare visudo manualmente?
Se è così è esattamente quello che cerco e che non riesco a fare.
Cerco di spiegarti bene come funziona il tutto, così da non perdere tempo in cose inutili:
1. l'applicazione WEB comunica con il server (la macchina su cui gira squeezelite-r2) tramite script CGI scritti in PERL che altro non fanno che trasmettere il comando con i suoi parametri e ricevere l'output, di volta in volta JSON, HTML o testo semplice.
2. Sul server c'è un'applicazione CONTROLLER che intercetta TUTTI i comandi e li indirizza a specifiche classi dedicate, sempre in PERL.
3. Per alcuni comandi che prevedono interazioni specifiche con l'OS ospite CONTROLLER esegue quanto stabilito in CONFIGURATION, una classe apposita il cui contenuto in termini di dati è registrato nel file /var/www/conf/squeezelite-r2.conf
Lì per esempio trovi la locazione dei files pref e pid, dell'eseguibile ed il default per il log, quali comandi sono accesibili e come si devono attivare (pathname alla exit).
Il file .conf è pensato per essere gestito principalmente dal gestore delle singole distribuzioni, NON dall'utente finale, nessuno lo vieta, solo non è a prova di scimmia. Attualmente la WebInterface NON scrive nel file .conf, ma non è escluso possa arrivare a farlo (i.e. advanced settings), quindi è bene che www-data abbia accesso in scrittura in conf.
Se devo pensare a dove posizionare .pref all'interno dell'albero di www, direi in conf.
Parallelamente al file .conf, c'è un la directory exit, organizzata per sottocartelle: Local e Standard, l'ultima suddivisa per OS: Linux, OsX e Win, al di sotto l'organizzazione è libera (i.e Debian i386, ARM,...)
Qui possono essere posizionati gli script PERL SPECIFICI richiamati dal file .conf.
Local è per le cose strettamente dipendendi dalla specifica installazione, es. il comando per interrogare lo stato della scheda audio, che per essere determinato richiede una 'conversione' non dipendente solo dal sistema operativo ma anche dallo specifico hardware e driver installato.
Tutti questi comandi devono essere eseguibili ed acccessibili in lettura da www-data, in scrittura da chi li manutiene.
Quello che sto cercando di fare io ormai da troppo tempo è provare una configurazione funzionante sul sistema impostato dallo script, intendendo con questo un insieme di EXIT ed una CONFIGURATION specifica, che - superato il problema dei permessi - sarebbe immediatamente funzionante su quqlsiasi sistema impostato dallo script.
Il web server dell'installazione di Debian è Apache2 (versione specifica per debian) e la sua configurazione per la mia applicazione è banale, 2 righe nel file di configurazione.
Ciao, Marco.
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction."
— E. F. Schumacher (mis-attributed to A. Einstein)
________________________________________________________________________________
Autore della patch R2 per Squeezelite e del plugin C-3PO. note libere
Logitech media Server 7.9 > miniPc + squeezelite-R2 / SB+ > "Lu Scalmentu" NOS R2R DAC by TubeOne/ AudioResearch DAC 1-20 >
Klimo Merlino Gold TPS > DIS Interconnect > Kent Gold > Reference > Monitor Audio Studio 20 SE
Ho impostat ovisudo come segue:
User_Alias WEB = www-data, marco
Cmnd_Alias SQUEEZELITE = /usr/bin/squeezelite, /usr/bin/squeezelite-R2
WEB ALL = (root) NOPASSWD: SQUEEZELITE
all'usicta da visudo non ho errori e se da marco provo sudo -l mdic che posso eseguire queezelite.
connesso come "marco" :
/usr/bin/squeezelite OK
sudo /usr/bin/squeezelite OK
da web ottengo errore 500 (non riesco a dire di più).
non riuscendo a fare login come www-data, l'unica cosa che riesco a fare è questa:
su
password
su -u www-data /usr/bin/squeezelite -l
Risultato: diversi messaggi di errore, tra cui accesso negato e quindi l'elenco corretto (perchè www-data è in aaudio, se lo tolgo immagino di no.
su -u www-data sudo /usr/bin/squeezelite -l OK.
Questo significa che, supponendo tu rilasci la corretta configurazione di sudo, devo mettere sudo davanti ad ogni comando negli script? Vorrebbe dire rendere obbligatoria la configurazione di sudo su tutti i sistemi, anche dove oggi non servirebbe, come Ubuntu, oppure la completa separazione di Debian dal resto, possibile, ma più onerosa da manutenere.
Per favore ditemi se ho capito bene.
Grazie.
Ciao, Marco.
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction."
— E. F. Schumacher (mis-attributed to A. Einstein)
________________________________________________________________________________
Autore della patch R2 per Squeezelite e del plugin C-3PO. note libere
Logitech media Server 7.9 > miniPc + squeezelite-R2 / SB+ > "Lu Scalmentu" NOS R2R DAC by TubeOne/ AudioResearch DAC 1-20 >
Klimo Merlino Gold TPS > DIS Interconnect > Kent Gold > Reference > Monitor Audio Studio 20 SE
Ciao,
sto continuando le mie prove su Docker. Vi aggiorno, tanto per chiacchierarne un po'.
Ho utilizzato di base l'immagine debian ufficiale, circa 50Mb, davvero minima - già solo l'installazione di wget porta dentro 10 pacchetti, non vi dico il resto.
Sto pensando quindi di creare un template mio, da cui far partire lo script di installazione. Ognitanto si incricca, ma è normale: gira su una specie di VM e non su macchina fisica.
Forse sarebbe più comodo per voi, che testate invece l'installazione "bare metal" piuttosto che per me che, invece, andrei sempre a virtualizzare il servizio... sto dubitando un po' dell'utilità della cosa, ma si sta rivelando divertente.
Vediamo che ne esce!
hai ragione, ho visto anche io. Deve essere cambiato qualcosa dopo qualche aggiornamento... il pacchetto che contiene il comando "service" (essendo probabilmente considerato obsoleto e "deprecated" dopo la migrazione a systemd) non viene più installato di default. Al suo posto si potrebbe convenientemente utilizzare l'apposito comando di systemd (systemctl), ma per il momento preferirei evitare di "dipendere" da systemd e mantenere la compatibilità con sistemi basati su Init diversi, per cui ora ho incluso l'installazione di quel pacchetto nello script.
è normale e giusto che sia così: se un utente non è nel gruppo audio, non può accedere in alcun modo (neanche in sola lettura) all'hardware audio (questioni di sicurezza e di privacy... ricorda che i sistemi Unix/Linux sono multiutente).
quella è una cosa di cui normalmente in Linux si occupa "logrotate"...
Logrotate: configurare la rotazione automatica dei log - Guide@Debianizzati.Org
Per gestire tale funzione la procedura "standard" in Debian (e derivate) consiste banalmente nell'aggiungere un semplice file di configurazione nella directory /etc/logrotate.d/ (cosa di cui normalmente si occupa il pacchetto debian del software di cui si devono gestire i log).
sostanzialmente sì. È una delle cose di cui si deve occupare il pacchetto deb. Il modo migliore è aggiungere un apposito file di configurazione nella directory /etc/sudoers.d/ (ad es. /etc/sudoers.d/squeezelite-web-gui).
come mai?
OK, fin qui mi pare tutto giusto.
la cosa si dovrebbe risolvere banalmente utilizzando "sudo" per tutti i comandi che richiedono l'accesso "all'hardware" e/o a files che non sono accessibili direttamente dall'utente "www-data" (ovviamente previa opportuna configurazione di sudo come detto).
come mai poi hai optato per apache (che mi sembra overkill...) anziché lighttpd?
per esserne certo dovrei provare, ma ad occhio e croce mi sembra corretto.
utilizzare "su" (e/o sudo) è esattamente la cosa da fare ogni qual volta si ha la necessità di impersonare un utente "speciale", però mi pare che continui ad utilizzare sintassi sbagliate per "su":
* il comando "su" non prevede una opzione "-u";
* il comando "su" non accetta altri comandi da eseguire se non attraverso l'opzione "-c"!
Di solito, la sequenza di comandi può essere banalmente:
(cioè prima acquisisci una shell come utente "root" e poi da quella usi i privilegi di root per impersonare un altro utente qualsiasi). Poiché però di solito all'utente "www-data" (così come ad altri utenti "speciali) non è consentito il login e quindi non ha una shell di default valida (come "shell" di default spesso c'è il comando "/usr/sbin/nologin", oppure "/bin/false", ecc) non puoi ottenere direttamente una shell in quel modo. Puoi farlo però ad es. sfruttando l'opzione "-s" di su, così:codice:su - su nome_utente
a quel punto ottieni una shell dalla quale puoi dare qualsiasi comando (come utente "www-data").codice:su - su -s /bin/bash www-data
N.B.: se invece vuoi dare direttamente un singolo comando, devi fare qualcosa del genere:
Incidentalmente l'opzione "-s" esiste, con il medesimo significato, anche in "sudo". Se lo configuri opportunamente, puoi usare "sudo" anziché "su" anche per diventare "www-data" (o qualsiasi altro utente); la cosa più semplice e comoda da fare è aggiungere il tuo utente al gruppo "sudo", ad es. dando (come root) il comando "adduser marco sudo":codice:su - su -s /bin/bash -c "/usr/bin/squeezelite -l" www-data
La configurazione di default di sudo (/etc/sudoers) dovrebbe già includere una riga come questa:adduser USER GROUP
Add an existing user to an existing group
che consente a tutti gli utenti membri del gruppo "sudo" di eseguire qualsiasi comando impersonando qualsiasi altro utente (fornendo la propria password, non quella dell'utente da impersonare che potrebbe non esistere).# Allow members of group sudo to execute any command
%sudo ALL=(ALL:ALL) ALL
Così facendo puoi diventare "www-data" direttamente dal tuo utente, semplicemente con il comando:
sì.codice:sudo -s -u www-data
?? a differenza di Debian (dove sudo di default non c'è e per averlo bisogna mettercelo esplicitamente) in Ubuntu (e derivate) sudo è sempre installato di default, quindi non vedo proprio quale sarebbe la limitazione (casomai è il contrario, è in Debian che obblighi all'installazione di sudo).
Tra parentesi, se la tua web-gui è scritta interamente in Perl (e/o php, o altri linguaggi interpretati), l'eventuale pacchetto deb risulterebbe utilizzabile non solo in Debian ma anche nelle sue derivate, incluse le *buntu (e sarebbe anche del tipo "noarch", cioè indipendente dall'architettura... quindi utilizzabile sia su sistemi i386 ed amd64 che su tutti gli altri quali ARM, ecc).
Ultima modifica di UnixMan : 08-02-2016 a 16:33
Ciao, Paolo.
«Se tu hai una mela, e io ho una mela, e ce le scambiamo, allora tu ed io abbiamo sempre una mela per uno. Ma se tu hai un'idea, ed io ho un'idea, e ce le scambiamo, allora abbiamo entrambi due idee.»
Troppe cose in una volta... restringo:hai ragione, ho visto anche io. Deve essere cambiato qualcosa dopo qualche aggiornamento... il pacchetto che contiene il comando "service" (essendo probabilmente considerato obsoleto e "deprecated" dopo la migrazione a systemd) non viene più installato di default. Al suo posto si potrebbe convenientemente utilizzare l'apposito comando di systemd (systemctl), ma per il momento preferirei evitare di "dipendere" da systemd e mantenere la compatibilità con sistemi basati su Init diversi, per cui ora ho incluso l'installazione di quel pacchetto nello script.
è normale e giusto che sia così: se un utente non è nel gruppo audio, non può accedere in alcun modo (neanche in sola lettura) all'hardware audio (questioni di sicurezza e di privacy... ricorda che i sistemi Unix/Linux sono multiutente).
quella è una cosa di cui normalmente in Linux si occupa "logrotate"...
Logrotate: configurare la rotazione automatica dei log - Guide@Debianizzati.Org
Per gestire tale funzione la procedura "standard" in Debian (e derivate) consiste banalmente nell'aggiungere un semplice file di configurazione nella directory /etc/logrotate.d/ (cosa di cui normalmente si occupa il pacchetto debian del software di cui si devono gestire i log).
sostanzialmente sì. È una delle cose di cui si deve occupare il pacchetto deb. Il modo migliore è aggiungere un apposito file di configurazione nella directory /etc/sudoers.d/ (ad es. /etc/sudoers.d/squeezelite-web-gui).
come mai?
OK, fin qui mi pare tutto giusto.
la cosa si dovrebbe risolvere banalmente utilizzando "sudo" per tutti i comandi che richiedono l'accesso "all'hardware" e/o a files che non sono accessibili direttamente dall'utente "www-data" (ovviamente previa opportuna configurazione di sudo come detto).
come mai poi hai optato per apache (che mi sembra overkill...) anziché lighttpd?
per esserne certo dovrei provare, ma ad occhio e croce mi sembra corretto.
utilizzare "su" (e/o sudo) è esattamente la cosa da fare ogni qual volta si ha la necessità di impersonare un utente "speciale", però mi pare che continui ad utilizzare sintassi sbagliate per "su":
* il comando "su" non prevede una opzione "-u";
* il comando "su" non accetta altri comandi da eseguire se non attraverso l'opzione "-c"!
Di solito, la sequenza di comandi può essere banalmente:
(cioè prima acquisisci una shell come utente "root" e poi da quella usi i privilegi di root per impersonare un altro utente qualsiasi). Poiché però di solito all'utente "www-data" (così come ad altri utenti "speciali) non è consentito il login e quindi non ha una shell di default valida (come "shell" di default spesso c'è il comando "/usr/sbin/nologin", oppure "/bin/false", ecc) non puoi ottenere direttamente una shell in quel modo. Puoi farlo però ad es. sfruttando l'opzione "-s" di su, così:codice:su - su nome_utente
a quel punto ottieni una shell dalla quale puoi dare qualsiasi comando (come utente "www-data").codice:su - su -s /bin/bash www-data
N.B.: se invece vuoi dare direttamente un singolo comando, devi fare qualcosa del genere:
Incidentalmente l'opzione "-s" esiste, con il medesimo significato, anche in "sudo". Se lo configuri opportunamente, puoi usare "sudo" anziché "su" anche per diventare "www-data" (o qualsiasi altro utente); la cosa più semplice e comoda da fare è aggiungere il tuo utente al gruppo "sudo", ad es. dando (come root) il comando "adduser marco sudo":codice:su - su -s /bin/bash -c "/usr/bin/squeezelite -l" www-data
La configurazione di default di sudo (/etc/sudoers) dovrebbe già includere una riga come questa:
che consente a tutti gli utenti membri del gruppo "sudo" di eseguire qualsiasi comando impersonando qualsiasi altro utente (fornendo la propria password, non quella dell'utente da impersonare che potrebbe non esistere).
Così facendo puoi diventare "www-data" direttamente dal tuo utente, semplicemente con il comando:
codice:sudo -s -u www-data
sì.
?? a differenza di Debian (dove sudo di default non c'è e per averlo bisogna mettercelo esplicitamente) in Ubuntu (e derivate) sudo è sempre installato di default, quindi non vedo proprio quale sarebbe la limitazione (casomai è il contrario, è in Debian che obblighi all'installazione di sudo).
Tra parentesi, se la tua web-gui è scritta interamente in Perl (e/o php, o altri linguaggi interpretati), l'eventuale pacchetto deb risulterebbe utilizzabile non solo in Debian ma anche nelle sue derivate, incluse le *buntu (e sarebbe anche del tipo "noarch", cioè indipendente dall'architettura... quindi utilizzabile sia su sistemi i386 ed amd64 che su tutti gli altri quali ARM, ecc).
a. Mi avevi detto tu che non andava bene mettere www-data in audio, ti ho spiegato perché l'ho fatto, ma non ho capito SE lo devo lasciare o se la tua configurazione risolve in altro modo.
b. Logrotate lo fa per data/ dimensione. Io lo faccio 'a richiesta'.
c. Ma perché ho bisogno (applicativamente) di impersonare un utente speciale? Quello che serve è un utente impersonando il quale sia consentito fare TUTTO e SOLO quello che serve e che ti ho elencato. Inserire nell'applicazione le istruzioni specifiche per farlo in uno specifico sistema sarebbe profondamente sbagliato, mi pare ovvio.
Ogni gestore può decidere COME abilitare l'utente del web server a svolgere le sue funzioni, l'applicazione deve rimanere agnostica in merito es.
Anche solo rimanendo in Linux, Sul mio Ubuntu, www-data ha accesso alle risorse necessarie perché è inserito in un gruppo che lo consente, senza bisogno di sudo, quindi visudo non è configurato per dare gli stessi accessi senza chieder la password, sarebbe del tutto inutile. Lo stesso risultato lo is può ottenere in modi diversi.
Di conseguenza, se io mettessi sudo davanti ai comando, su questi sistemi mi chiederebbe la password e lo script - ovviamente - abortirebbe.
d. Non ci salto fuori perché sono una capra, pigra e svogliata ...
e. Apache2 è quello installato con Debian, ho voluto solo fare una prova. Il 'peso' in esecuzione è minimo in entrambi i casi, installare Lighttpd è semplice ma è una cosa in più, la configurazione è equivalente (2 righe in un file), con Apache2 può risultare forse ancora più semplice, dato che basta sostituire il file con uno predisposto ad hoc (forse anche con Lighttpd, non so).
Dal mio punto di vista (applicativo) non cambia nulla.
f. Il problema (per me ed immagino per utenti 'normalmente ovini' ') è e rimane l'incubo dei permessi, che in un modo o nell'altro vanno sistemati a seguito dell'installazione, a meno di non tagliare la testa al toro e dare tutti i permessi su tutto a www-data con visudo, ma allora mi domando perché e tanto vale connettersi direttamente come root...
g. l'installazione dell'applicazione in se, in assenza di altro, può avvenire direttamente da git, con un semplice comando: git clone https://github.com/marcoc1712/falcon.git all'interno della cartella /var/www, molto comodo per gli aggiornamenti continui.
Ciao, Marco.
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction."
— E. F. Schumacher (mis-attributed to A. Einstein)
________________________________________________________________________________
Autore della patch R2 per Squeezelite e del plugin C-3PO. note libere
Logitech media Server 7.9 > miniPc + squeezelite-R2 / SB+ > "Lu Scalmentu" NOS R2R DAC by TubeOne/ AudioResearch DAC 1-20 >
Klimo Merlino Gold TPS > DIS Interconnect > Kent Gold > Reference > Monitor Audio Studio 20 SE
non è che non vada bene "tout-court". Può essere una soluzione semplice ed efficace, almeno per parte delle necessità. In generale ed in linea di principio però non è delle migliori, in quanto dà al web server ed a qualsiasi processo avviato da questo pieno accesso ai dispositivi audio, cosa non esattamente desiderabile. Se un "intruder" riuscisse a sfruttare qualche buco per far eseguire un suo codice al web server, avrebbe direttamente accesso a qualsiasi dispositivo audio presente. Per dire, se sul sistema dove gira il web server ci fosse anche una interfaccia di input collegata ad un microfono, l'intruso potrebbe utilizzarlo per ascoltare/registrare tutto quello che succede senza che nessuno se ne accorga...
Sarebbe quindi preferibile utilizzare una soluzione più "granulare", che consenta al tuo programma di fare solo quello che serve (ad es. eseguire squeezelite) e non altro. Cosa che si può fare ad es. utilizzando "sudo".
Azz, e ti pare un vantaggio?! Molto meglio lasciarlo fare automaticamente a logrotate! Altrimenti l'utente sarebbe costretto a ricordarsi di farlo a mano periodicamente. Oltre ad essere una grossa quanto inutile seccatura, l'utente potrebbe facilmente dimenticarsene. Tanto più che, di fatto, quella di squeezelite è per lo più una configurazione "una tantum", che una volta che tutto funziona come si vuole non si tocca mai più o quasi, per cui niente di più facile che ci si dimentichi di accedere alla relativa interfaccia web...
perché... non si può. Non esiste (e non è definibile) un utente che possa fare tutto e solo quel che ti serve... se non attraverso meccanismi come per l'appunto "sudo", che consentono di specificare in modo fine cosa un dato utente può o non può fare.
Come puoi capire dall'esempio precedente, perfino il semplice inserimento dell'utente con il quale gira il web server nel gruppo audio può avere possibili conseguenze decisamente sgradevoli (sebbene in pratica sia improbabile).
se vuoi che SL sia avviato automaticamente all'avvio del sistema (e sarebbe oltremodo scomodo se così non fosse...), in qualche modo devi integrarti con il sistema. Il che vuol dire che devi seguire una procedura che è necessariamente ed inevitabilmente system-dependent, non c'è un modo universale che funzioni su qualsiasi sistema... neanche limitatamente a qualsiasi sistema Linux (per la maggior parte magari sì, ma non tutti).
Se poi vuoi farlo "nel modo giusto", seguendo le convenzioni ed i metodi standard del sistema ospite, su Linux (ma in sostanza anche su windows) ciò implica far girare SL come servizio; ma, per poter controllare un servizio (avviarlo/fermarlo/riavviarlo), almeno su Linux hai sempre bisogno dei privilegi di root (a prescindere dall'utente con il quale poi effettivamente gira il servizio stesso). La cosa più semplice, comoda ed oggi come oggi pressoché universalmente diffusa per gestire esigenze del genere è proprio l'utilizzo di sudo. L'alternativa è quella di utilizzare dei propri eseguibili "suid e/o sgid", che cioè vengono eseguiti con i privilegi dell'utente (e/o del gruppo) proprietario del file a prescindere da quale sia l'utente che li esegue (a patto ovviamente che questi abbia il permesso di eseguirli). In passato questo era il metodo standard, nonché spesso l'unico possibile (per altro è proprio quello che utilizzano i tool quali "su" e "sudo"), ma presenta una infinità di rischi e problemi... sudo è stato inventato apposta proprio per evitarne l'uso diffuso. Senza contare che (a meno di non usare suid/gid su uno script, cosa assolutamente sconsigliabile) diventeresti architecture-dependet e perderesti la portabilità. Insomma la "cura" sarebbe di gran lunga peggiore del "male" (che tale poi non è affatto).
non è necessario. Utilizzato correttamente, limitando i permessi in modo molto specifico alle sole operazioni che servono, puoi tranquillamente configurarlo in modo che non venga richiesta nessuna password.
per quello serve un pacchetto... l'utente installa quello e non deve fare altro, il sistema si preoccupa di tutto il resto.
Ultima modifica di UnixMan : 08-02-2016 a 21:53
Ciao, Paolo.
«Se tu hai una mela, e io ho una mela, e ce le scambiamo, allora tu ed io abbiamo sempre una mela per uno. Ma se tu hai un'idea, ed io ho un'idea, e ce le scambiamo, allora abbiamo entrambi due idee.»
Paolo, non ci capiamo, ma va bene uguale, tanto ci sono abituato.
Tutto quello che dici è giusto, non lo metto in dubbio, ma DEVE essere fatto ESTERNAMENTE all'applicazione, che - ovviamente - deve essere in grado di richiamare 'strumenti' di integrazione messi a disposizione dal sistema ospite.
Esempio:
L'esecuzione come servizio:
Avviene in modi diversi su sistemi diversi ed in linux, dipendentemente dalla specifica configurazione, può richiedere permessi diversi.
Ora, l'applicazione CORRETTAMENTE sa solo che esiste la possibilità di attivare/disattivare questo servizio, mediante la chiamata a 'comandi' incapsulati in script da richiamare, ma NON SA e non è interessata al contenuto di tali script.
La realizzazione di questi script è DIPENDENTE dal sistema ospite e normalmennte a carico di chi 'integra' l'applicazione nel sistema. E' chiaro quello che intendo? c'è qualcosa di sbagliato in questa logica?
Continui ad indicarmi COME dovrei farlo, non mi interessa (come realizzatore dell'applicazione) , dimmi piuttosto SE ci sono cose particolari che devo prevedere (ma non specifiche per Debian o LInux).
L'applicazione WEB usa un utente (come tutte le applicazioni web) che normalmente è www-data.
Quali prerogative (astratte) debba avere per poter funzionare su ogni sistema te l'ho già elencato, come si traduce questo in una specifica configurazione di uno specifico sistema anche in funzione dei livelli di sicurezza che si vogliono mantenere è una scelta di integrazione.
L'esempio del sudo è significativo:
Sistema A -> www-data è configurato per 'impersonare' root senza password sul comando squeezelite -l, ma di per se non può eseguirlo perchè non è nel gruppo 'audio'.
Sistema B -> www-data è nel grippo audio ma NON può impersonare root.
Sistema C = A, ma con richiesta di password.
Se ho capito bene (e questa è la domanda) A richiede il comando: sudo squeezelite -l, b no, anzi, produce un errore, C si, ma richiede la password e quindi abortisce.
Se è così e non c'è altro modo (cosa che non credo) è EVIDENTE che la sezione di applicazione che 'esegue' squeezelite-l DEVE dipendere dal sistema ospite ed essere configurata di conseguenza.
Lo stesso vale per tutti i comandi emessi ed è per questo che li ho sottoposti a configurazione su più livelli
SE, come credo sia possibile, tutto il casino di cui sopra potesse essere evitato con una opportuna configurazione dei permessi nel sistema ospite, attribuiti con la granularità richiesta alle risorse nessarie ed all'utente utilizzato (es. squeezelite), tutto quanto risulterebbe più facile ed immediato.
La tua risposta continua ad essere quella di fare un pacchetto, OK, ma
A. non credo che un pacchetto possa gestire le situazioni A, B e C o qualsiasi combinazione diversa, un pacchetto è mirato ad una specifica configurazione, quindi serve un pacchetto per debian configurato da eaSetup, con squeezelite installato come root ed un'altro per debian ove sia installato max2play, un terzo per ubuntu configurato come il mio,...
B. Il pacchetto è un modo, certamente 'il modo' in Linux, ma non c'è solo Linux. Tutte le cose che fa il pacchetto son possibili anche senza pacchetto, ovviamente ed io sto ancora cercando di capire COSA sono queste cose, prima di pensare a COME distribuirle.
C. Io NON farò nessun pacchetto di installazione mirato a nessun sistema ospite specifico, ma dovessi arrivare a fare un 'sistema di installazione' lo farei partendo dalla creazione di un utente specifico (o l'utilizzo di uno già presente) e dalla sua configurazione di privilegi in base a quello che deve poter fare, quindi a ritroso costruirei tutte le strutture necessarie affinché il tutto possa funzionare. In linux sarebbe probabilmente un pacchetto, in Win un installer, ma questo è un dettaglio.
Adesso però, se ne hai voglia, dovremmo risolvere un problema specifico:
Come integrare falcon (l'applicazione di controllo di squeezelite-R2, richiamata dalla web gui, ma generica, può servire anche un rich client JAVA o uno script di installazionesi chiama così ) nel sistema installato con eaSetup.
1. Lato applicativo: tutte le exit sono disponibili, se non è così segnalamelo e le pubblico.
2. Puoi decidere di utilizzare Apache2 integrato in debian in fase di installazione o un altro Web server (es lighttpd), in entrambi i casi la configurazione è banale e si riduce ad indicare l'utente di esecuzione (v. 3) e la cartella ove risiede l'applicazione (/var/www/falcon), oltre ad abilitare le CGI.
3. Dovresti garantire all'utente selezionato l'accesso alle risorse necessarie (se ho capito bene è quello che stai facendo).
4. Anche in funzione delle scelte che fai per 3, si devono attivare glli script che realizzano le exit di cui al punto 1 e compilare di conseguenza il file di configurazione.
5. Fatto questo, l'installazione dovrebbe essere funzionate senza problemi e puoi certamente pacchettizzarla ed integrarla in eaSetup, dato che è in funzione di come è configurato il sistema frutto della sua esecuzione.
Non credo si possa definire 'standard'.
Lo stato è questo:
1. alfa e pubblicato, in fase di test e completamento.
2. testato e funzionato in entrambe le soluzioni
3. ? EDIT: hai risposto nell'altro THD: "non ho ancora avuto modo di metterci le mani, ma da quel che mi hai detto non penso ci siano problemi di sorta".
4. ho realizzato i principali come prototipo, attendo 3 per un fine tuning, disponibile a qualsiasi supporto.
5. Non ho ancora capito qual'è l'obiettivo:
a. fare un pacchetto da integrare in eaSetup (manutenuto in e con easetup)
b. fare un pacchetto a se stante, ma mirato al sistema configurato da eaSetup (?)
c. fare un pacchetto a se stante ed indipendente (???).
Se l'obiettivo è diverso da A, per favore spiegami come intendi procedere, io non ho nessun interesse (ne la capacità) di farlo, la smetterei quindi qui abortendo il progetto web gui , a meno che qualcun altro non se ne faccia carico, nel qual caso pronto a fornire tutto il supporto necessario.
Ultima modifica di marcoc1712 : 09-02-2016 a 13:21
Ciao, Marco.
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction."
— E. F. Schumacher (mis-attributed to A. Einstein)
________________________________________________________________________________
Autore della patch R2 per Squeezelite e del plugin C-3PO. note libere
Logitech media Server 7.9 > miniPc + squeezelite-R2 / SB+ > "Lu Scalmentu" NOS R2R DAC by TubeOne/ AudioResearch DAC 1-20 >
Klimo Merlino Gold TPS > DIS Interconnect > Kent Gold > Reference > Monitor Audio Studio 20 SE
Buona serata. Come utilizzatore dello script di installazione vorrei riportare come feedback quanto ho potuto verificare nell'ultimo fine settimana.
Premetto che non istallo Liquorix perchè molto probabilmente il mio thin client non lo supporta infatti al boot successivo si inchioda. Quindi l'opzione di non installare Liquorix si rivela utile.
Sabato ho usato lo script su VoyageMPD. Ho provato singolarmente l'installazione base, quella di LMS e quella di un sistema completo. L'istallazione termina riconoscendo anche la scheda audio installata.
Domenica su una installazione minimale debian lo script termina correttamente riconoscendo anche la scheda audio. Ho riprovato a reistallare sulla chiavetta con s.o. VoyageMPD l'opzione solo player. Anche questa funziona correttamente; volendo lasciare sulla chiavetta un sistema completo ho rieseguito lo schipt che però questa volta non termina dando come messaggio la mancanza di spazio al momento dello spacchettamento di LMS. La cosa mi fa pensare che ad ogni esecuzione dello script vengono scaricati i pacchetti senza che sia stata effettuata la rimozione di pacchetti scaricati precedentemente.
Sono partito con una re-installazione con solo sistema base e richiedendo allo script un sistema completo, con successo. Il mio obbiettivo è quello di avere un sistema che occupi lo spazio minimo idealmente la CF da512MByte. E' per questo motivo che insisto ad usare VoyageMPD. Ma la contropartita è che il sistema di protezione dalla scrittura (comando remountrw) interferisce con LMS impedendone l'avvio perchà LMS richiede di scrivere il log nella cache ma la trova solo in lettura! Occorre sbloccare la situazione dando il comando remountrw e riavviare LMS. Un altro problema che si è verificato è che al momento di installare il plugin C3PO nella pagina di impostazione mi chiede di riavviare LMS, io lo faccio ma questo poi non compare tra quelli attivi; ripetendo l'operazione si ottiene lo stesso messaggio di riavvio e così via.
Molto probabilmente mi conviene limitarmi ad una installazione solo player e usare un altro thin client che ho per far girare LMS. In ogni caso al momento mi sto godendo un sistema su thin client con resampling 2x, frutto del vostro lavoro e di cui vi ringrazio.
Ci sono attualmente 1 utenti che stanno visualizzando questa discussione. (0 utenti e 1 ospiti)
|
nexthardware.com - © 2002-2022 |
Rispondi quotando
