Easy Audio Setup: installazione guidata di sistemi audio HQ

[UnixMan]

Per la cronaca, la "pezza" consiste nell'aver spostato l'aggiunta del repository di Liquorix all'interno della funzione che installa tale kernel e nell'aggiunta del pacchetto "apt-transport-https" a quelli installati di default. Questo dovrebbe far tornare a funzionare tutto. Nella peggiore delle ipotesi, se ancora non dovesse funzionare, dovrebbe essere sufficiente saltare l'installazione del kernel Liquorix (che è sempre opzionale) ed il resto dovrebbe procedere liscio.

Altra piccola modifica "cosmetica": ho tolto la redirezione (su log file) dell'output di "apt-get update", così che ne sia visibile lo stato di avanzamento e vengano evidenziati immediatamente eventuali problemi.

Però non ho ancora avuto modo di testarlo dopo le modifiche. Fatemi sapere...

[marcoc1712]

Per la cronaca, la "pezza" consiste nell'aver spostato l'aggiunta del repository di Liquorix all'interno della funzione che installa tale kernel e nell'aggiunta del pacchetto "apt-transport-https" a quelli installati di default. Questo dovrebbe far tornare a funzionare tutto. Nella peggiore delle ipotesi, se ancora non dovesse funzionare, dovrebbe essere sufficiente saltare l'installazione del kernel Liquorix (che è sempre opzionale) ed il resto dovrebbe procedere liscio.

Altra piccola modifica "cosmetica": ho tolto la redirezione (su log file) dell'output di "apt-get update", così che ne sia visibile lo stato di avanzamento e vengano evidenziati immediatamente eventuali problemi.

Però non ho ancora avuto modo di testarlo dopo le modifiche. Fatemi sapere...

OK, adesso finisce, ma mi pare che se non ci si connette come root non funzioni. Non si riesce al lanciare i servizi e squeezelite non viene attivato alla partenza.
Sudo non va (l'utente non è nel gruppo sudoer) e SU riesce a far partire /etc/init.d/squeezelite start ma non service squeezelite start.

In questo modo sono bloccato, a meno di non far usare root al web server, cosa altamente sconsigliabile, richiedere la password di amministratore da web (ancora meno consigliabile) o scriverla negli script (non ne parliamo neppure).

Che fare?

p.s. quanto sopra usando l'utente creato automaticamente dall'installazione di Debian che è lo stesso usato per far partire easetup.sh.

[antonellocaroli]

OK, adesso finisce, ma mi pare che se non ci si connette come root non funzioni. Non si riesce al lanciare i servizi e squeezelite non viene attivato alla partenza.
Sudo non va (l'utente non è nel gruppo sudoer) e SU riesce a far partire /etc/init.d/squeezelite start ma non service squeezelite start.

In questo modo sono bloccato, a meno di non far usare root al web server, cosa altamente sconsigliabile, richiedere la password di amministratore da web (ancora meno consigliabile) o scriverla negli script (non ne parliamo neppure).

Che fare?

p.s. quanto sopra usando l'utente creato automaticamente dall'installazione di Debian che è lo stesso usato per far partire easetup.sh.

sudo deve essere configurato a mano per adesso
con il comando visudo si apre un file di testo dove aggiungere l´utente con i permessi...

dopo la partenza controlla se é attivo il servizio con

service squeezelite status da root (su invio pw) o con sudo dopo aver configurato sudo

[UnixMan]

SU riesce a far partire /etc/init.d/squeezelite start ma non service squeezelite start.

"su" ha una sintassi leggermente diversa da quella di "sudo".

man su
man sudo

Normalmente "su" si usa semplicemente per "impersonare" un altro utente (ottenere una shell). Per eseguire un solo comando devi usare una sintassi del tipo:

su -c "service squeezelite start"

però "su" richiede sempre la password; è pensato per l'uso interattivo da parte dell'amministratore di sistema, non per fare quello che ti serve.

In questo modo sono bloccato, a meno di non far usare root al web server, cosa altamente sconsigliabile, richiedere la password di amministratore da web (ancora meno consigliabile) o scriverla negli script (non ne parliamo neppure).

Che fare?

devi configurare "sudo" in modo che l'utente con cui gira il web server possa utilizzare "sudo" (senza password) per far girare soltanto alcuni ben specifici comandi. Vedi:

man sudoers
man visudo

e/o cerca documentazione ed esempi in rete. Probabilmente ad es. qualcosa del genere:

User_Alias      WEB = www-data
Cmnd_Alias      SLSTOP  = "service squeezelite stop"
Cmnd_Alias      SLSTART = "service squeezelite start"
WEB             ALL = (root) NOPASSWD: SLSTOP
WEB             ALL = (root) NOPASSWD: SLSTART

ecc.

In sostanza devi dirgli che un dato utente (o una lista di utenti, oppure un gruppo, ecc) sono autorizzati ad utilizzare "sudo" per eseguire alcuni comandi (definiti sempre all'interno del file sudoers) impersonando un altro utente (in questo caso root).

p.s. quanto sopra usando l'utente creato automaticamente dall'installazione di Debian che è lo stesso usato per far partire easetup.sh.

quello è indifferente... easetup gira sempre come "root" (non appena lo lanci, se non sei già root come prima cosa usa "su" per ri-eseguire sé stesso come root).

[marcoc1712]

"su" ha una sintassi leggermente diversa da quella di "sudo".

man su
man sudo

Normalmente "su" si usa semplicemente per "impersonare" un altro utente (ottenere una shell). Per eseguire un solo comando devi usare una sintassi del tipo:

su -c "service squeezelite start"

però "su" richiede sempre la password; è pensato per l'uso interattivo da parte dell'amministratore di sistema, non per fare quello che ti serve.


devi configurare "sudo" in modo che l'utente con cui gira il web server possa utilizzare "sudo" (senza password) per far girare soltanto alcuni ben specifici comandi. Vedi:

man sudoers
man visudo

e/o cerca documentazione ed esempi in rete. Probabilmente ad es. qualcosa del genere:

User_Alias      WEB = www-data
Cmnd_Alias      SLSTOP  = "service squeezelite stop"
Cmnd_Alias      SLSTART = "service squeezelite start"
WEB             ALL = (root) NOPASSWD: SLSTOP
WEB             ALL = (root) NOPASSWD: SLSTART

ecc.

In sostanza devi dirgli che un dato utente (o una lista di utenti, oppure un gruppo, ecc) sono autorizzati ad utilizzare "sudo" per eseguire alcuni comandi (definiti sempre all'interno del file sudoers) impersonando un altro utente (in questo caso root).

quello è indifferente... easetup gira sempre come "root" (non appena lo lanci, se non sei già root come prima cosa usa "su" per ri-eseguire sé stesso come root).

Non ho capito...

e, secondo me, non hai capito.

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

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?

Io OGGI ho un utenet es. www-data (con apache) che via CGI arriva a lanciare uno script che, poniamo esegua: "service start squezeite".

non funziona, perchè ww-data non è amministratore.

Quindi cosa devo fare?

1.Creo l'alias WEB per www-data
2. creo l'alias SLSTART per "service start squeezelite"

ed a quel punto cosa faccio? metto WEB come user di apache? diventa automaticamente SU senza chiedere la password?

Non riuscirest a frire un esempio?

[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]

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.

[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.