credo di aver capito che (forse) l'incomprensione nasce banalmente da una diversa interpretazione del termine "applicazione".
Per me "una applicazione" è "tutto il pacchetto", cioè tutto l'insieme di files, directories, configurazioni e quant'altro serve per poter utilizzare tale applicazione (incluse le eventuali integrazioni con il sistema, software accessori, ecc... insomma tutto quanto, installazione compresa).
Al contrario mi pare di capire che tu con "applicazione" ti riferisci soltanto alla parte relativa all'interfaccia web.
Se è così, rileggi quanto ho scritto in precedenza tenendo presente questa differenza semantica e vedrai che tutto dovrebbe chiarirsi.
stando a quel che dicevi, mi pare che tale separazione tu la abbia già fatta: non vedo quindi quale sia il problema. Quello di cui parlavo io ha a che fare (quasi) esclusivamente con quelli che tu chiami i "metodi esterni" (per integrare la web-ui con il sistema specifico).
Dico "quasi" perché, ovviamente, anche nella parte comune e portabile (web) devi necessariamente tenere conto di ciò che puoi o non puoi fare nei diversi sistemi su cui poi il tutto dovrà girare, ed evitare a priori eventuali "conflitti", incompatibilità o problemi vari.
ovvio... e non vedo dove sia il problema.
fatto salvo quanto sopra... no.
Parlando in generale devi solo avere l'accortezza di tener presente che stai realizzando una applicazione che di fatto ha proprio lo scopo di controllare il sistema su cui gira, quindi non puoi basare il progetto della tua applicazione su un modello totalmente astratto ed avulso dai diversi sistemi reali con cui questa dovrà interagire.
Tornando allo specifico, per quanto ho capito non credo che ci siano problemi di sorta (e casomai ce ne fossero sarebbero comunque facilmente risolvibili senza rendere dipendente dal sistema la parte che tu chiami "applicazione").
questo te lo potrò dire non appena riesco a metterci le mani, nel caso rilevassi qualche problema...
va benissimo. Si tratta semplicemente di trovare il modo migliore per consentire a quell'utente di fare tutto (e solo) ciò che serve (cosa che, come detto, secondo me si può fare facilmente e comodamente utilizzando sudo: qualsiasi altra soluzione sarebbe molto più complessa e macchinosa, o limitante, o insicura).
che www-data non possa eseguirlo (direttamente, come sé stesso) in quanto non è nel gruppo audio è non solo normale, ma cosa buona e giusta.
Non capisco però quale sia il problema: non sei riuscito a configurare sudo in modo che "www-data" possa eseguire "squeezelite -l" come root senza che venga richiesta alcuna password?
esatto. Se sudo è configurato correttamente, tutto deve funzionare senza il benché minimo problema.
Deve funzionare tanto su su Ubuntu quanto su Debian o su qualsiasi altro Linux... e non solo: ad es., se non vado errato, "sudo" si può usare anche per OS/X.
Ovviamente, ove sudo non sia già presente (ad es. Debian) è necessario installarlo (e, in tutti i casi, aggiungere la configurazione specifica per quel che serve).
Qualche problema potrebbe esserci solo su quei sistemi (ad es. RHEL, CentOS, ecc) che abilitano di default "SELinux" o simili.
Mi spiego. Normalmente, nei sistemi Unix l'utente "root" è "dio onnipotente": qualsiasi processo che sia eseguito con uid=0 e gid=0 può fare qualsiasi cosa, senza nessuna limitazione. Alcuni sistemi moderni hanno però introdotto delle ulteriori misure di sicurezza che possono porre delle stringenti limitazioni non solo agli utenti "normali" ma anche a root. Questo ci scombinerebbe non poco le cose, costringendoci a configurare opportunamente (anche) quello. Però per quanto ci riguarda mi guarderei bene dall'avere cose come SELinux attive, che introdurrebbero soltanto delle ulteriori complicazioni inutili (dopo tutto non abbiamo certo le esigenze di sicurezza di una banca, o di un sistema militare, ecc...).
se non ho capito male, hai già previsto che ad eseguire "squeezelite -l" sia uno script "system dependent" eseguito a sua volta dalla web gui. Se è così, non vedo dove sia il problema. Nei sistemi Linux lo script eseguirà "sudo squeezelite -l", negli altri quel che serve... (in realtà in questo caso non serve neanche uno "script esterno", basta che si possa configurare la riga di comando).
err... mi pare che tu metta troppa carne al fuoco.
Partiamo da un punto: qual è lo scopo della web-ui?
se non ho capito male, dovrebbe essere quello di semplificare la configurazione di squeezelite.
In che consiste tale configurazione?
nello scrivere (o modificare) UNA o DUE RIGHE in un file di testo e nel dare successivamente un semplice comando per riavviare il servizio (o ancora più banalmente, riavviare il sistema).
Se per installare la web-ui devo compiere qualsiasi sequenza di operazioni più complessa di questa, IMHO la web-ui non avrebbe alcun senso di esistere... che faccio, curo un raffreddore con un farmaco che causa il cancro?
Ergo l'installazione della web-ui deve essere assolutamente banale ed a prova di idiota... o non ha senso.
Ma come fai a fare un sistema di installazione che sia banale ed al contempo "universale", avendo a che fare con sistemi diversi e che non conosci a priori? Ovvio che non puoi farlo: qualsiasi sistema di installazione automatizzato non può che dipendere da una infrastruttura e da "condizioni al contorno" già ben note e standardizzate, altrimenti non ci cavi i piedi.
Devi scegliere una strada, che poi sarà la stessa per tutti. Chi vuole seguire strade diverse, se proprio vuole la web-ui, dovrà arrangiarsi da solo a manina.
BTW: ho l'impressione che una cosa non ti sia troppo chiara: lo script (easetup) usa (cioè, scarica ed installa) i pacchetti di squeezelite-R2, ma questi non "dipendono" e non hanno nulla a che vedere con easetup!
I pacchetti sono pacchetti standard, "uguali" a quelli forniti da Debian. Li puoi scaricare ed installare "a mano" (con gdebi o dpkg) su qualsiasi sistema Debian Jessie o compatibile (comunque sia stato installato e configurato: utilizzare easetup non è assolutamente necessario).
E non solo: previo un banale "rebuild" del pacchetto a partire dai relativi "sorgenti" si possono facilmente produrre pacchetti adatti anche per (quasi) qualsiasi altra versione recente di Debian o derivate (incluse ovviamente Ubuntu, Mint, Voyage, ecc).
Lo stesso varrebbe per l'eventuale pacchetto della web-ui. Anzi, meglio: se infatti questo non contiene binari (e quindi non ha dipendenze da compilatori e librerie specifiche) lo stesso pacchetto funzionerebbe tanto su varie versioni di Debian quanto di Ubuntu e molte altre ancora, sia a 32 che a 64 bit, ed anche su architetture diverse da quelle "x86".
Ma ovviamente dovrebbe dipendere da una installazione "standard" di squeezelite(-R2), cioè nella fattispecie dai relativi pacchetti (altrimenti non ci sarebbe modo di verificare che tale dipendenza sia soddisfatta).
un pacchetto è come un "installer" di windows... "on steroids".
Si tratta di un file (un "archivio") che contiene tutto il software (o quel che sia: potrebbe trattarsi di documentazione, ecc) da installare, con tutte le informazioni su come e dove deve essere installato ciascun file (inclusi proprietari, permessi, ecc). Tra i files installati dal pacchetto ci può essere ad es. il file di configurazione aggiuntivo per sudo, quello per il web-server, ecc.
Tra le altre cose contiene inoltre la lista delle dipendenze, cioè la lista di tutti gli altri pacchetti che devono (o non devono) essere installati sul sistema per consentire la sua installazione (ed il suo funzionamento).
Può inoltre contenere degli script (opzionali) di pre- e post- installazione e disinstallazione, cioè script che vengono eseguiti automaticamente (dal package manager) quando il pacchetto stesso viene installato, disinstallato o aggiornato, subito prima (preinst, prerm) o subito dopo (postinst, postrm) che i relativi files (e directory) siano copiati sul (o eliminati dal) sistema - cosa di cui si occupa sempre il package manager.
Al momento dell'installazione, tutte le informazioni contenute nel pacchetto vengono registrate in un apposito "database", così che il sistema è sempre in grado di sapere esattamente "chi ha installato cosa" (e dove), "chi dipende da chi", ecc, in modo da poter mantenere un sistema sempre consistente e di non lasciare "residui" in giro se/quando un pacchetto viene disinstallato (o aggiornato). Nello stesso DB sono conservati anche gli script del pacchetto, che consentono di dis-fare automaticamente qualsiasi modifica sia stata apportata al sistema dal pacchetto stesso al momento della sua eventuale disinstallazione (o aggiornamento).
Rispondi quotando
