Easy Audio Setup: installazione guidata di sistemi audio HQ

[antonellocaroli]

Marco io penso che l´"unico" comando utile sia service squeezelite restart

stop e start penso siano inutili....credo....

[UnixMan]

e, secondo me, non hai capito.

tranquillo, ho capito benissimo.

su + psw = funziona tutto, ma non service...

che funzioni tutto ne dubito fortemente... estratto dalle man page di "su" e "sudo":

NAME
       su - change user ID or become superuser

SYNOPSIS
       su [options] [username]

DESCRIPTION
       The su command is used to become another user during a login session. Invoked without a username, su defaults to becoming the
       superuser. The optional argument - may be used to provide an environment similar to what the user would expect had the user logged
       in directly.

       Additional arguments may be provided after the username, in which case they are supplied to the user's login shell. In particular,
       an argument of -c will cause the next argument to be treated as a command by most command interpreters. The command will be
       executed by the shell specified in /etc/passwd for the target user.
...

invece, sudo:

NAME
     sudo, sudoedit — execute a command as another user

SYNOPSIS
     sudo -h | -K | -k | -V
     sudo -v [-AknS] [-a type] [-g group] [-h host] [-p prompt] [-u user]
     sudo -l [-AknS] [-a type] [-g group] [-h host] [-p prompt] [-U user] [-u user] [command]
     sudo [-AbEHnPS] [-a type] [-C num] [-c class] [-g group] [-h host] [-p prompt] [-r role] [-t type] [-u user] [VAR=value] [-i | -s]
          [command]
     sudoedit [-AknS] [-a type] [-C num] [-c class] [-g group] [-h host] [-p prompt] [-u user] file ...

DESCRIPTION
     sudo allows a permitted user to execute a command as the superuser or another user, as specified by the security policy.

     sudo supports a plugin architecture for security policies and input/output logging.  Third parties can develop and distribute their
     own policy and I/O logging plugins to work seamlessly with the sudo front end.  The default security policy is sudoers, which is
     configured via the file /etc/sudoers, or via LDAP.  See the Plugins section for more information.

     The security policy determines what privileges, if any, a user has to run sudo.  The policy may require that users authenticate
     themselves with a password or another authentication mechanism.  If authentication is required, sudo will exit if the user's pass‐
     word is not entered within a configurable time limit.  This limit is policy-specific; the default password prompt timeout for the
     sudoers security policy is unlimited.

     Security policies may support credential caching to allow the user to run sudo again for a period of time without requiring authen‐
     tication.  The sudoers policy caches credentials for 15 minutes, unless overridden in sudoers(5).  By running sudo with the -v
     option, a user can update the cached credentials without running a command.

     When invoked as sudoedit, the -e option (described below), is implied.

     Security policies may log successful and failed attempts to use sudo.  If an I/O plugin is configured, the running command's input
     and output may be logged as well.

     The options are as follows:
...

I due comandi NON sono per nulla equivalenti. A te serve "sudo" (opportunamente configurato), non puoi usare "su". Full stop.

ma a parte quello, non ho capito cosa devo fare dai tuoi esempi. WEB esegue SLSTOP come 'su' senza che gli vega richiesta la password?

esatto. Quello che ho postato è un esempio (per grandi linee, e che potrebbe contenere errori - era solo per rendere l'idea) di come puoi/devi configurare "sudo" per ottenere quello che ti serve (la configurazione di sudo è contenuta nel file "/etc/sudoers" e/o nei files in "/etc/sudoers.d"; in questo caso però i files non vanno editati direttamente ma sempre e soltanto attraverso l'apposito comando "visudo").

Quindi cosa devo fare?

configurare "sudo" (cioè, il file "/etc/sudoers") in modo che l'utente che vuoi (in questo caso "www-data") sia autorizzato ad utilizzare "sudo" per eseguire i comandi che ti servono e "sudoedit" per accedere ai files che devi leggere/modificare (in entrambi i casi, senza che venga chiesta alcuna password).

N.B.: l'esempio che ho postato si riferiva (esclusivamente) a tale configurazione (file "sudoers").

Come detto... RTFM!

man sudo
man sudoers
man visudo

se proprio non ti piacciono i manuali, ... Let me google that for you

http://it.wikipedia.org/wiki/Sudo (per capire per sommi capi cos'è e come funziona sudo)

AmministrazioneSistema/Sudo - Wiki di ubuntu-it

Guida a Sudo - Guide@Debianizzati.Org (questa è la guida più completa)

Quick HOWTO : Ch09 : Linux Users and Sudo - Linux Home Networking

ecc, ecc...

[antonellocaroli]

Dando il comando da root visudo

ti si apre un file di testo...dove puoi aggiungere un utente che abbia i permessi per eseguire sudo

direttamente sotto questa riga root ALL=(ALL:ALL) ALL

tipo filippo ALL=(ALL:ALL) ALL ho i permessi di usare sudo da per tutto...

opp

utente ALL = (ALL) NOPASSWD: /percorso/del/programma

utente ALL = (ALL) NOPASSWD: /sbin/reboot

[marcoc1712]

tranquillo, ho capito benissimo.


che funzioni tutto ne dubito fortemente... estratto dalle man page di "su" e "sudo":

NAME
       su - change user ID or become superuser

SYNOPSIS
       su [options] [username]

DESCRIPTION
       The su command is used to become another user during a login session. Invoked without a username, su defaults to becoming the
       superuser. The optional argument - may be used to provide an environment similar to what the user would expect had the user logged
       in directly.

       Additional arguments may be provided after the username, in which case they are supplied to the user's login shell. In particular,
       an argument of -c will cause the next argument to be treated as a command by most command interpreters. The command will be
       executed by the shell specified in /etc/passwd for the target user.
...

invece, sudo:

NAME
     sudo, sudoedit — execute a command as another user

SYNOPSIS
     sudo -h | -K | -k | -V
     sudo -v [-AknS] [-a type] [-g group] [-h host] [-p prompt] [-u user]
     sudo -l [-AknS] [-a type] [-g group] [-h host] [-p prompt] [-U user] [-u user] [command]
     sudo [-AbEHnPS] [-a type] [-C num] [-c class] [-g group] [-h host] [-p prompt] [-r role] [-t type] [-u user] [VAR=value] [-i | -s]
          [command]
     sudoedit [-AknS] [-a type] [-C num] [-c class] [-g group] [-h host] [-p prompt] [-u user] file ...

DESCRIPTION
     sudo allows a permitted user to execute a command as the superuser or another user, as specified by the security policy.

     sudo supports a plugin architecture for security policies and input/output logging.  Third parties can develop and distribute their
     own policy and I/O logging plugins to work seamlessly with the sudo front end.  The default security policy is sudoers, which is
     configured via the file /etc/sudoers, or via LDAP.  See the Plugins section for more information.

     The security policy determines what privileges, if any, a user has to run sudo.  The policy may require that users authenticate
     themselves with a password or another authentication mechanism.  If authentication is required, sudo will exit if the user's pass‐
     word is not entered within a configurable time limit.  This limit is policy-specific; the default password prompt timeout for the
     sudoers security policy is unlimited.

     Security policies may support credential caching to allow the user to run sudo again for a period of time without requiring authen‐
     tication.  The sudoers policy caches credentials for 15 minutes, unless overridden in sudoers(5).  By running sudo with the -v
     option, a user can update the cached credentials without running a command.

     When invoked as sudoedit, the -e option (described below), is implied.

     Security policies may log successful and failed attempts to use sudo.  If an I/O plugin is configured, the running command's input
     and output may be logged as well.

     The options are as follows:
...

I due comandi NON sono per nulla equivalenti. A te serve "sudo" (opportunamente configurato), non puoi usare "su". Full stop.


esatto. Quello che ho postato è un esempio (per grandi linee, e che potrebbe contenere errori - era solo per rendere l'idea) di come puoi/devi configurare "sudo" per ottenere quello che ti serve (la configurazione di sudo è contenuta nel file "/etc/sudoers" e/o nei files in "/etc/sudoers.d"; in questo caso però i files non vanno editati direttamente ma sempre e soltanto attraverso l'apposito comando "visudo").


configurare "sudo" (cioè, il file "/etc/sudoers") in modo che l'utente che vuoi (in questo caso "www-data") sia autorizzato ad utilizzare "sudo" per eseguire i comandi che ti servono e "sudoedit" per accedere ai files che devi leggere/modificare (in entrambi i casi, senza che venga chiesta alcuna password).

N.B.: l'esempio che ho postato si riferiva (esclusivamente) a tale configurazione (file "sudoers").

Come detto... RTFM!

se proprio non ti piacciono i manuali, ... Let me google that for you

http://it.wikipedia.org/wiki/Sudo (per capire per sommi capi cos'è e come funziona sudo)

AmministrazioneSistema/Sudo - Wiki di ubuntu-it

Guida a Sudo - Guide@Debianizzati.Org (questa è la guida più completa)

Quick HOWTO : Ch09 : Linux Users and Sudo - Linux Home Networking

ecc, ecc...

Intendevo che funziona tutto quello che mi dicevi di fare al precedente post... con SU divento root e quindi funziona, Ma non SERVICE, nemmeno se mi connetto come ROOT, mi pareva (e mi pare) non avessi capito questo, tutto qui.

Si, sono pigro, dopo una modifica ad un programma C, un plugin in PERL ed un miniosito di configurazione in HTML, javascript e PERL vorrei evitare di dover studiare i manuali di tutti i sistemi operativi ospite, scusate, ma non mi diverte.

GLi script (EXIT) per farlo sono tutti disponibili, non funzionano sul sistema installato con lo script perchè l'utente non ha i permessi, SE qualcuno è interessato, può modificarli, io sono disponibile a supportarlo per quanto compete la logica applicativa e volendo posso comprenderli nella cartella standard con riferimento a Debian ed all'installazione con script, se ritenuto utile, ma mi fermo qui, in nessun modo produrrò o distribuirò 'pacchetti' dedicati ad un particolare sistema ospite ed alla sua configurazione, altrimenti avrei fatto Daphile2, la logica è sempre quella di rilasciare componenti 'standard' che ognuno, singolo utente o mantainer di una distribuzione, cala nell'ambiente ospite.

p.s.

per tua info:

Ho ripetuto l'installazione con lo script selezionando nuovamente il mirror italiano e si ferma allo stesso punto (problema di chiave pubblica). Forse i problemi sono 2.
Dopo l'esecuzione dello script in un ambiente con GUI, il browser non funziona più, mentre da ROOT accedo a risorse internet ed il web server è comunque attivo.

[marcoc1712]

Dando il comando da root visudo

ti si apre un file di testo...dove puoi aggiungere un utente che abbia i permessi per eseguire sudo

direttamente sotto questa riga root ALL=(ALL:ALL) ALL

tipo filippo ALL=(ALL:ALL) ALL ho i permessi di usare sudo da per tutto...

opp

utente ALL = (ALL) NOPASSWD: /percorso/del/programma

utente ALL = (ALL) NOPASSWD: /sbin/reboot

Grazie Filippo.

Lo provo, ma non riesco a capire come 'proceduralizzare' il tutto:

OGGI FACCIO:

a. installo da webInterface cioè (nel rispetto di quanto previsto da TUTTI i web server) copio la mia versione della cartella WWW in \var, ove la root (\var\www) del sito ed eventualmente la cartella HTML_public hanno privilegio di esecuzione, lettura e scrittura per tutti, mentre le altre cartelle sono private e consentono l'esecuzione a www-data.

b. aggiungo l'utente www-data al gruppo AUDIO, così che possa accedere alla configurazione di ALSA.


DOVREI AGGIUNGERE:

Come faccio in batch (sono in fase di installazione, non è interattiva) lanciare VISUDO e fare queello che devo fare?

Risolto questo, quello che dovrei ottenere è:

www-data ALL = (ALL) NOPASSWD: /etc/init.d/squeezelite
www-data ALL = (ALL) NOPASSWD: /bin/perl 5.0/perl (emmesso sia questo il percorso al perl)
www-data ALL = (ALL) NOPASSWD: /var/www/exit/script1.pl
...
www-data ALL = (ALL) NOPASSWD: /var/www/exit/scriptn.pl
...
www-data ALL = (ALL) NOPASSWD: /etc/default/squeezelite

www-data ALL = (ALL) NOPASSWD: /var/log/squeezelite/squeezelite.log
www-data ALL = (ALL) NOPASSWD: /var/pref/squeezelite/squeezelite.pref
www-data ALL = (ALL) NOPASSWD: /var/cache/squeezelite/squeezelite.pid
...

elencando TUTTI i files cui devo aver accesso, siano essi eseguibili, script o file di dati?

Se lancio ViSudo, mi dice che sarebbe meglio non scrivere li ma altrove (ora non sono su LINUX, non riesco a controllare), me ne frego?

riesci, per cortesia, a fornirmi un 'prototipo' funzionante ove l'utente 'www-data' sia abilitato ad eseguire i servizi di start e stop di squeezelite e tutti gli script PERL contenuti in una cartella che si chiama '/var/www/exits', leggendo da

'/var/www/conf/squeezelite-R2.conf'

e potendo leggere e scrivere:

' /etc/default/squeezelite'
'/var/log/squeezelite/squeezelite-r2.log'
'/var/pref/squeezelite/squeezelite-r2.pref'
'/var/cache/squeezelite/squeezelite.pid'

Così facciamo prima.

[antonellocaroli]

Marco provo a rispondere...considera che ne sono abbastanza ignorante...

Come faccio in batch (sono in fase di installazione, non è interattiva) lanciare VISUDO e fare queello che devo fare?

Cosa intendi di preciso? non ho capito che intendi....

Diciamo che quando le righe da inserire diventano troppe sarebbe meglio usare /etc/sudoers.d/ .....ma credo che vada bene direttamente /etc/sudoers



modificabile con visudo comando da dare da shell....

Se lancio ViSudo, mi dice che sarebbe meglio non scrivere li ma altrove (ora non sono su LINUX, non riesco a controllare), me ne frego?

direi di si

elencando TUTTI i files cui devo aver accesso, siano essi eseguibili, script o file di dati?

probabilmente gli eseguibili (non provenienti da deb) e gli script presumo che prima deveno aver ricevuto i permessi per l´eseguibilitá

tipo chmod +x nomescript

probabilmente un pacchetto .deb del tutto risolverebbe un sacco di rogne....

[marcoc1712]

Marco provo a rispondere...considera che ne sono abbastanza ignorante...


Cosa intendi di preciso? non ho capito che intendi....

Diciamo che quando le righe da inserire diventano troppe sarebbe meglio usare /etc/sudoers.d/ .....ma credo che vada bene direttamente /etc/sudoers



modificabile con visudo comando da dare da shell....

direi di si



probabilmente gli eseguibili (non provenienti da deb) e gli script presumo che prima deveno aver ricevuto i permessi per l´eseguibilitá

tipo chmod +x nomescript

probabilmente un pacchetto .deb del tutto risolverebbe un sacco di rogne....

Grazie Filippo,

Sono convinto che un pacchetto potrebbe risolvere, ma io non mi ci metto a farlo e mantenerlo. Forse ho peccato e non avrei MAI dovuto iniziare questa attività, io non sono omniscente e non mi interessa impararare a creare e mantenere pacchetti per debian. Se qualcuno lo vuole fare, io ho già messo a disposizione tutte le componenti applicative.

Venendo a noi, il primo problema è come usare Visudo da uno script PERL per sua natura batch e non interattivo. Non ho modo di lanciare SUDO dalla web gui.

Per fare una prova, posso certamente usarlo, per questo chiedevo un 'prototipo' funzionante che facesse le cose che ho elencato, ma questo vale solo per me qui ed ora, non posso generalizzarlo nell'applicazione, mentre è possibilissimo ed adeguato farlo nel corso dell'installazione

Comunque, In Ubuntu con Lighttpd ed installazoione di Squeezelite-r2 'manuale' funziona come un orologio svizzero, sto tentando da tre giorni di fare lo stesso con l'installazione su Debian via script e mi pianto sulle 'banalità' che per me sono l'everest, sto chiedendo aiuto per questo.

Grazie

[antonellocaroli]

Ti aiuterei volentieri...ma io ho dei limiti ,)

Comunque, In Ubuntu con Lighttpd ed installazoione di Squeezelite-r2 'manuale' funziona come un orologio svizzero, sto tentando da tre giorni di fare lo stesso con l'installazione su Debian via script e mi pianto sulle 'banalità' che per me sono l'everest, sto chiedendo aiuto per questo.

dov é la differenza?
dovrebbe funzionare +o- allo stesso modo....

Venendo a noi, il primo problema è come usare Visudo da uno script PERL per sua natura batch e non interattivo. Non ho modo di lanciare SUDO dalla web gui.

per adesso io consiglierei di fare una modifica manuale con visudo vedere se il tutto funziona e poi o fare uno script a parte tipo quello di Paolo incluso nei tuoi file che come root modifica il "file visudo" o includere la modifica direttamente nello script di paolo.

[UnixMan]

Intendevo che funziona tutto quello che mi dicevi di fare al precedente post... con SU divento root e quindi funziona, Ma non SERVICE, nemmeno se mi connetto come ROOT, mi pareva (e mi pare) non avessi capito questo, tutto qui.

allora avevi ragione... questo non lo avevo capito!

La cosa mi sorprende alquanto. In che senso "service" non ti funziona? Che errore ti da?

(riporta sempre i msg di errore... altrimenti non ci capiamo nulla).

GLi script (EXIT) per farlo sono tutti disponibili, non funzionano sul sistema installato con lo script perchè l'utente non ha i permessi,

se mi dai l'elenco completo dei comandi che devono essere eseguiti e dei file cui si deve accedere come root vedo di preparare una configurazione appropriata per "sudo". Una volta testato tutto, vedrò se posso anche mettere insieme un pacchetto deb che si occupa di tutto.

Ho ripetuto l'installazione con lo script selezionando nuovamente il mirror italiano

dov'è che hai selezionato il mirror?!

[marcoc1712]

allora avevi ragione... questo non lo avevo capito!

La cosa mi sorprende alquanto. In che senso "service" non ti funziona? Che errore ti da?

(riporta sempre i msg di errore... altrimenti non ci capiamo nulla).


se mi dai l'elenco completo dei comandi che devono essere eseguiti e dei file cui si deve accedere come root vedo di preparare una configurazione appropriata per "sudo". Una volta testato tutto, vedrò se posso anche mettere insieme un pacchetto deb che si occupa di tutto.


dov'è che hai selezionato il mirror?!

a. comando non trovato.
b. sono quelli al post precdente, comunque:

in prima battuta:

- accesso in lettura ed esecuzione a Squeezelite-R2
- accesso in scrittura a default/squeezelite.
- accesso in scrittura a ??? (pref/squeezelite-r2.pref), nuovo file con i settings creato dala web gui, da mettere dove si vuole var\cache o var\lib o ...
- acceso in lettura a xxx Squeezelite.pid (nuovo file, creato da squeezelite da mettere dove si vuole var\cache o var\lib o ...
- accesso in scrittura al log, comunquevenga chiamato.

A questo fine, io uso lo stesso gruppo per l'utente di esecuzione di squeezelie-R2 e www-data (audio, così risolvo anche il problema di proc assound...).

Con quanto sopra funziona già tutto, ma ci sono comandi opzionali:

1. Service squeezelite start, stop, restart,...
2. quello che serve per attivare/disattivare l'avvio automatico (non so cosa sia, lo chiedevo a te).
3. reboot, shutdown.
4. il comando da utilizzare per il test della scheda audio (v. richiesta di Giovanni, credo proc asound/...).

Per TUTTI i punti è previsto uno script SPECIFICO per OS o singola installazione speciicabile nel file di configurazione e richiamato dal controller del sito, quindi in realtà io non so nemmeno quali sono i comandi da dare,ma se si vuole farli funzionare devono essere eseguibili da utente www-data.

Gli script PERL in oggetto stanno in var/www/exits e vengono attivati in base a quanto scritto in /var/www/confsqueezelite-r2.conf, www-data ha accesso in lettura su questi, in quanto compresi nella home del sito (www).


c. in fase di installazione di Debian in uno degli ultimi passaggi chiede di selezionare prima la noazione e poi il mirror. Con US ed il tuo script modificato arriva in fondo, con IT no