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.»
Ciao, ti sottopongo alcune domande su come integarre al meglio la WEB GUI con il lavoro fatto dallo script in DEBIAN:
1. Il Pathname di squeezelite-R2 è fissato in: /usr/bin/squeezelite-R2?
2. La riga di comando è generata ad ogni partenza ESCLUSIVAMENTE da quanto presente in: /etc/default/squeezelite ?
Se, come credo, è così, occorrerebbe mantenere allineato il file /etc/default/squeezelite con le opzioni settate nella wegui, mediante la valorizzazione delle righe:
SL_NAME="R2@$(hostname -s)"
SL_SOUNDCARD="default:CARD=Amanero"
SB_SERVER_IP="192.168.x.y"
SB_EXTRA_ARGS="tutte le altre opzioni"
Se è cos¨, OK, ma ho alcune perplessità:
a. Sicuro che SB_SERVER debba contenere solo l'IP e non anche la porta :9000 ?
In ogni caso, sempre se ho capito bene, tutto il file viene rinominato e sovrascritto dall'esecuzione dello script e tutte le impostazioni riscritte.
In questo modo, molte informazioni vengono impostate (o non impostate) a valori fissati dallo script, perdendo quanto eventualmente impostato in precedenza manualmente.
Se è accettabile per uno script di prima installazione, non credo lo sia per una successiva 'manutenzione', quindi non ritengo di poter applicare lo stesso metodo dalla webgui, pertanto riscriverei completamente il file derivando il valore delle variabili di configurazione in modo opportuno.
Nel farlo, eliminerei tutti i commenti e metterei solo una riga che avvisa che sono state scritte in automatico dalla web gui e di non modificarle manualmente, tanto verrebbero riscritte, potrei salvare il fie attuale prima di farlo usando un'estensione diversa da .bak, che usi tu per salvare l'originale. E' necessario?
Lo script fissa molti parametri, tra cui il pathname del file di log a: /var/log/squeezelite.log, anche se ovviamente può essere variato manualmente. Per il corretto funzionamento dell'installazione e dello script, è necessario sia quello (quindi bloccarne la modifica in webgui) o è libero?
Già in questo modo, l'integrazione 'minima' è garantita, anche se avere 3 variabili complica la comunicazione ma non è sufficiente, quindi di mio andrei su una di queste tre strade:
a. si usa una sola variabile contenete tutta la riga, scritta dallo script/webgui solo quando cambia e letta dal servizio, che non deve 'interpretare' più nulla ma solo eseguire. Semplice ed efficace.
b. si modificare il file in etc/init.d in modo che costruisca la riga di comando a partire dai settings 'elementari' della webGui, la cui struttura è condivisa con lo script di installazione e la web gui.
c. un misto delle due, il servizio legge una sola variabile, costruita da script e web gui a partire da una struttura di parametri 'atomici' condivisa.
A mio avviso C è la preferibile.
In ogni caso resta una implementazione specifica (su windows sarà diverso), quindi io prevedo una exit al momento della scrittura della riga di comando + una implementazione 'pilota' sull'attuale struttura, se e quando vorrai potremo migliorare la cosa.
Attendo il tuo parere, oltre ad altre considerazioni in merito a come installare il tutto ( il primo problema è la configurazione dei gruppi ed i permessi da attribuire all'utente del web server, così¨ che possa leggere e scrivere i files necessari).
p.s.
ho visto che Debian prevede un web server suo in fase di installazione, forse si può usare quello, in alternativa lighttpd mi pare ottimo e leggero.
Fammi sapere.
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,
sì. C'è anche un link "/usr/bin/squeezelite" che punta allo stesso file, cioè si possono usare indifferentemente entrambi i nomi (questo lo fa il pacchetto, a prescindere dallo script). Comunque, che te ne fai? La web gui non deve interagire con quello. Per fermare/avviare/riavviare il processo devi utilizzare l'apposito comando per la gestione dei servizi:
service squeezelite stop
service squeezelite start
service squeezelite restart
Il nome del file eseguibile è predefinito e fissato all'interno dell'init script, non ti serve conoscerlo. Devi solo conoscere il nome del servizio (cui corrisponde il nome dell'init script), e questo è (sempre e solo) "squeezelite", sia che tu stia utilizzando R2 che la versione "standard" distribuita da Debian.
sì. Puoi vedere come viene generata leggendo lo script di avvio (installato dal pacchetto), "/etc/init.d/squeezelite" (è banale... vengono lette le variabili dal file di configurazione e combinate opportunamente con le opzioni corrispondenti per formare la riga di comando).
esatto.
Quella variabile viene utilizzata così:
cioè viene aggiunta come parametro all'opzione "-s". Dalla man page di squeezelite:codice:# add squeezebox server ip address if set if [ -n "$SB_SERVER_IP" ]; then DAEMON_ARGS="${DAEMON_ARGS} -s ${SB_SERVER_IP}" fi
l'indicazione della porta è tra parentesi quadre, cosa che indica un valore opzionale. Se è omessa, assume il default (9000).-s <server>[:<port>]
Connect to the specified Logitech Media Server, otherwise uses automatic discovery to find server on the local network. This option should
only be needed if automatic discovery does not work, or the server is not on the local network segment (e.g. behind a router).
(le parentesi angolari indicano invece un valore obbligatorio; il numero della porta diventa obbligatorio se metti ':' dopo l'IP).
sì.
sì. Si presuppone che SL sia appena stato installato dallo script stesso, quindi non ci sono impostazioni precedenti (a parte quelle di default presenti nel file di configurazione installato dal pacchetto), per cui per semplicità ho evitato di fare il parsing, ecc.
In ogni caso, prima di sovrascrivere qualsiasi file lo script fa sempre una copia di backup di quello preesistente, quindi se lo script viene fatto girare su una installazione già configurata è facile recuperare le impostazioni precedenti.
banalmente la GUI dovrebbe leggere ed "importare" il valore delle variabili, quindi riscriverle con i nuovi valori quando salva le proprie impostazioni (ignorando tutto il resto).
aggiungere il warning è una buona idea, ma il resto lo lascerei così com'è (vedi sopra). Un utente potrebbe voler tenere i commenti (che magari contengono anche configurazioni alternative da richiamare velocemente commentando/scommentando le righe del file).
se decidi di sovrascrivere completamente il file, direi proprio di sì. Ma fallo solo se non trovi il "warning" della gui, cioè se il file non è stato generato da quella. Altrimenti alla seconda volta che salvi dalla gui perdi tutto.
è libero, ma lo lascerei almeno come default visto che quello (/var/log/) è il file system standard dove dovrebbero andare tutti i files di log, vedi: Filesystem Hierarchy Standard.
è brutto... ma si può fare: basta che ometti tutte le altre variabili ed aggiungi tutte le opzioni ed i relativi parametri alla variabile "SB_EXTRA_ARGS".
(però se l'utente scommenta/aggiunge a mano una delle altre variabili può succedere un pasticcio...).
fuori questione.
Ad eccezione dei files di configurazione, per i quali ovviamente è previsto (e che per questo sono trattati in modo speciale), i files installati dai pacchetti devono essere gestiti esclusivamente dal package-manager, non devono mai essere modificati dall'utente (o da altri software).
assolutamente... NO.
Se proprio non vuoi gestire tutte le variabili previste separatamente, come sarebbe preferibile, l'unica soluzione praticabile è la 'a.'.
...con un apposito pacchetto?
cosa non proprio banale. Per modificare il file di configurazione ed utilizzare il comando "service" servono i privilegi di "root"... ma il web server, la GUI ecc. non devono assolutamente girare come "root". È quindi necessario prevedere un opportuno meccanismo per permettergli di acquisire i privilegi per poter fare ciò che devono fare e non altro, solo quando serve.
Ad es. si potrebbe aggiungere un utente apposito (questo dovrebbe farlo già lighttpd) e poi configurare opportunamente "sudo" per permettere l'esecuzione come root di alcuni ben determinati comandi da parte di quell'utente (senza che sia richiesta la password).
non ci avevo mai fatto caso... "dove" / a che scopo? hai idea di quale sia?
sì, va benissimo.
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.»
a. l'eseguibile mi serve per lanciarlo con -l e -t per recuperare l'elenco delle schede audio, la verisone, le modalità disponibili ed il copyright.
b. come viene generato l'ho visto, ma è 'povero' da una parte perchè considera solo 3 variabili e 'complicatoì dall'altro perchè costringe ad interpretare 'semanticamete' la linea di comando per spezzarle nelle tre variabili da salvare.
In ogni caso è una realizzazione specifica per Debian (o linux?) in altri sistemi sarà diversa, quindi non può essere l'unica e di conseguenza può essere realizzata come meglio aggrada.
La domanda rimane: è 'legittimo' sovrascrivere il file da un processo runtime di 'libera' esecuzione? Non dovrebbe stare in var/lib ?
Quale estensione uso per salvarlo (diversa da .bak)
c. La web gui FA cosi (se riesce) la prima volta legge l'attuale riga di comando (o meglio chiama lo scrip che la restituisce), la interpreta e ne scopmone i parametri quindi alla conferma salva i parametri e chiama lo script che scrive la riga. Da quando dispone dei propri parametri, usa quelli INDIPENDENTEMENTE dal calore eale della riga di comando (potrei aggiunger eun messaggio di Warning, vedremo). I due script di lettura/scrittura sono OS (o installazione) dipendenti e selezionabili tramite configurazione (locale).
d. Il valore del default del log file dipende dall'OS. Il modo più semplice è prevederlo nella prima riga di comando impostata dallo script, in quel modo viene utilizzato ma rimane modificabile.
e. Quanto dici è comprensibile SE si vuole utilizzare il servizio squeezelite. Questa è una versione R2 ed a mio avviso può tranquillamente richiedere il servizio in versione R2, che fa cose leggermente diverse. Comunque andrebbe mantenuo, io non lo farò, quindi capisco se non lo vuoi fare tu.
f. Installazione, a me va bene tutto ma non sono in grado/ non intendo mantenerlo, ne per Debian ne per qualsiasi altro OS, v. sotto.
g. In ligthttpd (ed in apache) si può usare un utente a scelta, quindi va configurato almeno inserendolo nel gruppo audio (nella mia installazionedi LMS) e dandogli privilegio di lettura/scrittura sul log, ma potrebbero nascere altre esigenze.
Di mio, propenderei per usare in Lighttpd lo stesso utente usato per eseguire squeezelite-R2 mediante i servizi, tanto siamo in una LAN e quello è il modo 'normale' per accedere a squeezelite, ma anche qui mi tiro fuori, il come è una scelta del manutentore/utente, ma è un prerequisito.
h. Il web server: ho visto l'opzione in fase di installazione, ma non ho ancora provato.
NOTA GENERALE:
La webGui preevede TRE livelli di utilizzo:
a. Configurazione e SCRIPT per lo specifo OS e Web Server, come hai fatto per le altre componenti in Debian
b. Installazione (web server, l'applicazione in se è banale).
c. utilizzo.
a richiede la progettazione di qualcuno che decide la configurazione inziale delle componenti per lo specifico target, a partire dal web server. In LInux, probabilmente, si realizza mediante un 'pacchetto' di instalazione, non lo so, in WIN probabilmente basta mettere un server 'portable' nella stessa cartella.
b. L'ideale è comprenderlo in uno script di installazione, meglio se integrato in quello che installa squeezelite-r2.
c. qualsiasi utente
Per Debian, ti occupi tu di A (ovviamente sono a disposizione) inserendo B nell'attuale script?
Fammi sapere.
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
Altre domande:
Ove su linux sia presente la definizione del servizio "XXX" (nella fattispecie squeezelite), quindi sia possibile eseguire service XXX start|stop|restart, come si fa a far si che questo parta in automatico all'avvio? e come si sospende/riattiva l' avvio automatico se impostato?
Da cosa dipende (logicamente e fisicamente) la scelta di richiedere privilegi SU per avviare/fermare alcuni servizi ed altri no?
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
come detto nel post precedente, volendo puoi anche evitarlo usando solo l'ultima variabile, mettendo tutto lì. Le altre variabili puoi banalmente ometterle. In altre parole, il file di configurazione si riduce ad una sola riga che contiene tutte le opzioni assegnate alla variabile "SB_EXTRA_ARGS".
nei dettagli è specifica di quel pacchetto Debian (e del mio che è derivato da quello). Di solito tutte le distribuzioni basate su Debian (incluse le Ubuntu e sue derivate) utilizzano i pacchetti ufficiali di Debian quanto meno come base per quelli propri (spesso banalmente ricompilando il pacchetto sorgente Debian per la distribuzione specifica), quindi è molto probabile che sia lo stesso anche in quelle.
In linea di principio nelle altre distribuzioni (non derivate da Debian) l'init script (e quindi anche il meccanismo di configurazione) potrebbe essere completamente diverso. Però in generale quello di definire delle variabili di shell in un file "di configurazione" di cui viene fatto il "source" dall'init script è il metodo più comune e diffuso di gestire cose del genere.
Per altro, la questione mi pare accademica: al momento "squeezelite-R2" non è incluso in nessuna distribuzione, gli unici pacchetti esistenti sono quelli che ho fatto io... per cui o è fatto così o non c'è proprio.
Ovviamente puoi anche prevedere un meccanismo alternativo che usi un eseguibile "sciolto" installato manualmente o addirittura distribuito direttamente insieme alla web-ui e che gestisci (fai avviare/fermare/riavviare) direttamente da quella. Però non so come potresti fare per farlo partire automaticamente all'avvio del sistema in tal caso...
se si vuole mantenere una certa integrazione con i diversi sistemi, in ciascuno andrebbe adottato quello che è metodo "standard" per quel sistema (o quanto meno un metodo "compatibile" con quello).
IMHO è importante che gestisci le cose in modo flessibile, separando la UI e tutta la parte comune/portabile da quello che invece è codice specifico per ciascuna piattaforma (e che gestisce il processo di SL/R2, la sua configurazione, ecc).
Se parli del file di configurazione di SL, perché non dovrebbe? certo che è lecito: i files di configurazione sono pensati per essere modificabili dall'amministratore di sistema (root), con qualsiasi mezzo, che può essere tanto un editor di testo quanto qualsiasi altra cosa, incluso un processo come quello della tua web-ui.
(possono fare eccezione alcuni sistemi particolarmente "totalitari", come ad es. la teutonica SuSe, che hanno una propria interfaccia di configurazione centralizzata e pretendono che tutte le modifiche al sistema vengano fatte solo ed esclusivamente attraverso di essa; in caso contrario le modifiche vengono automaticamente annullate e le precedenti impostazioni ripristinate. Ma ovviamente di solito questo vale solo per i files conosciuti e gestiti da tale interfaccia, per cui presumibilmente non sarebbe comunque il ns. caso a meno che "squeezelite" non faccia parte di quanto gestito da una tale UI).
Certo non sarebbe male prevedere un qualche meccanismo di autenticazione per impedire che chiunque possa mettersi a pasticciare con la configurazione di SL e magari sarebbe anche il caso di curare la sicurezza della web-ui (ad es. per impedire che un eventuale intruso tenti di sfruttare un "buffer overflow") ma, se l'accesso allla web-ui (ed al web server stesso) resta limitato e confinato alla LAN domestica, il problema non è poi così pressante.
cos'è che dovrebbe stare in /var/lib?
non ha molta importanza: in Unix/Linux il concetto di "estensione" (così come inteso negli ambienti DOS/Windows) non esiste. In generale i nomi dei files non hanno alcun significato speciale per il sistema (che non si basa sul nome od una sua parte per determinare cos'è, cosa contiene o come vada trattato un dato file). All'interno del nome di un file (o di una dir) il '.' è infatti un carattere valido come un altro. Ce ne possono essere quanti se ne vuole, o anche nessuno (per dire, qualcosa come '.....' può essere un nome perfettamente valido, tanto per un file quanto per una directory, sebbene non sia buona norma usare nomi del genere).
Esistono solo due eccezioni: i nomi '.' e '..' (che indicano sempre rispettivamente la directory corrente e quella "parent"). Inoltre, quando il '.' costituisce il primo carattere del nome di un file o di una directory (come ad es. "~/.profile" o i citati '.' e '..', ecc), questi sono considerati "nascosti", cioè non vengono mostrati da 'ls' e simili a meno che non sia richiesto espressamente di farlo (è circa analogo all'attributo "HIDDEN" nei sistemi DOS/Windows).
Ciò non di meno, spesso alcuni "suffissi" sono utilizzati convenzionalmente: di solito soprattutto a favore degli utenti umani, ma talvolta anche alcuni software possono "interpretarli" in modo particolare.
Divagazioni "didattiche" a parte, io ho usato il suffisso ".bak" per cercare di rendere ovvio il significato di tali files agli utenti, in particolare a quelli poco avvezzi ai sistemi Unix/Linux. In realtà, convenzionalmente, di solito nei sistemi *nix i files "di backup" sono indicati aggiungendo semplicemente un carattere '~' in fondo al nome del file (senza '.' davanti) . Nello specifico però potrebbe essere preferibile utilizzare come suffisso ad es. la data di quando è stato salvato il file (e.g. /etc/default/squeezelite -> /etc/default/squeezelite.YYYY-MM-DD) e/o il nome dell'applicazione (la web-ui), ecc.
OK. Ma forse non sarebbe meglio ri-leggere il file di configurazione ad ogni avvio?
hai previsto la possibilità di non abilitare affatto la scrittura del log? IMHO "in produzione" sarebbe meglio evitarla...
?? R2 installato attraverso il pacchetto è un servizio (che si chiama comunque "squeezelite", come quello standard; non è previsto che i pacchetti delle due versioni possano convivere: se installi il pacchetto -R2, questo sostituisce l'altro e viceversa).
Se vuoi supportare l'installazione fatta con il pacchetto (che sia installato dallo script o diversamente), devi gestire le cose in quel modo: l'interfaccia web deve solo aggiornare il file di configurazione e poi riavviare il servizio (con "service squeezelight restart", oppure stop e poi start... che è lo stesso) quando gli dici di applicare le eventuali modifiche, mentre tutto il resto funziona come se la web-UI non ci fosse (e continuano a funzionare anche se la elimini).
a cosa ti riferisci?
se vuoi fare un pacchetto posso darti una mano. Creare l'infrastruttura del pacchetto (fatta bene) può non essere banale ma, una volta fatto quello, a meno di stravolgimenti mantenerlo è abbastanza banale.
che c'entra LMS?
su quale log?
al momento (con la versione attuale dei pacchetti) SL gira come root. Il che è una cosa veramente pessima (mi ero ripromesso di modificare i pacchetti per fargli usare un utente dedicato, ma non l'ho ancora fatto).
???
si può fare in vari modi, ma la cosa più "pulita", affidabile e semplice (per gli utenti finali) è senz'altro il pacchetto. Questo installerà i vari files dell'applicazione nei posti appropriati ed ovviamente dovrà "dipendere" da squeezelite|squeezelite-R2 nonché da un web server compatibile e qualsiasi altro software/libreria che sia necessario per farlo funzionare.
In questo modo quando si installa il pacchetto della web-ui vengono automaticamente installati (se non ci sono già) anche squeezelite, un web server appropriato, ecc. I pacchetti possono anche contenere eventuali script che siano eventualmente necessari per adattare il setup al caso specifico e che vengono eseguiti automaticamente al momento dell'installazione e/o della disinstallazione/aggiornamento del pacchetto stesso (senza che l'utente debba far nulla).
Una possibile alternativa potrebbe essere il classico, banale archivio (.tar.gz, zip o quel che sia) che contiene un albero di directory con i vari files dell'applicazione da copiare sul sistema. Soluzione questa che probabilmente è più semplice per lo sviluppatore, ma molto più complessa e foriera di errori e problemi vari per l'utente finale.
quello che cerchi si chiama "pacchetto". Anche l'integrazione esiste già (anche tra pacchetti completamente separati e sviluppati in modo indipendente): si chiama "package manager".
Non c'è alcun bisogno (ed anzi è sconsigliabile) che il pacchetto di "-R2" includa anche la web-ui (o viceversa).
Al contrario, basta creare un pacchetto "squeezelite-web-ui" (o comunque lo si voglia chiamare) che dipende da lighttpd|httpd, squeezelite-R2|squeezelite e qualsiasi altra cosa di cui abbia bisogno.
Dall'altra parte nuove versioni del pacchetto di R2 potrebbero includere una "dipendenza opzionale" verso il pacchetto della web-ui (cioè "suggerire" o "raccomandare" l'installazione del pacchetto della web-ui).
È proprio così che funzionano le cose per tutti i software in praticamente tutte le distribuzioni Linux moderne. Ogni singola applicazione (o parte del sistema stesso) è installata da un pacchetto specifico, che al suo interno specifica di quali altri pacchetti ha bisogno per funzionare, quali altri sono consigliati in aggiunta, quali invece sono eventualmente "in conflitto" e non potranno essere installati (o, se presenti, devono essere disinstallati) insieme a questo, ecc.
ci provo.
Se si fa il pacchetto, il più è fatto: l'inserimento nello script diventa banale (basta aggiungere una sola riga di codice...).
si può fare in molti modi, ma dipende dal sistema di "Init" adottato dalla distribuzione. In passato il sistema più diffuso, adottato (quasi) universalmente era l'Init system in stile Unix System V (AKA "SysVInit"), ma in seguito molte distribuzioni hanno cominciato a sviluppare/adottare sistemi più o meno diversi. Ad es. Ubuntu aveva sviluppato ed adottato un suo sistema specifico, chiamato "Upstart". Oggi la maggior parte delle distribuzioni (per lo meno quelle "desktop-oriented"), inclusa le stesse Ubuntu a partire dalla versione 15.04 e Debian a partire da "Jessie" (ma non le Mint, o almeno non ancora) hanno adottato "systemd":
Systemd - Guide@Debianizzati.Org
https://wiki.archlinux.org/index.php/Systemd
Con systemd la via preferenziale per la gestione di queste ed altre cose è l'uso del comando "systemctl":
https://www.linux.com/learn/tutorial...x-with-systemd
Non di meno, praticamente tutti i sistemi mantengono ancora un minimo di compatibilità verso le strutture e le interfacce del buon vecchio sysvinit (che quindi hanno il vantaggio di funzionare ancora su quasi tutti i sistemi):
SysV - Guide@Debianizzati.Org
Ad es. su Debian Jessie i vecchi comandi "service", "sysv-rc-conf", ecc. esistono e funzionano ancora.
D'altro canto, benché "systemd" sia installato di default (e molte applicazioni dipendano da quello, per cui rimpiazzarlo non è proprio banale...) su Debian è ancora possibile decidere di sostituirlo con sistemi di Init diversi, a partire proprio dal buon vecchio sysv, che è proprio ciò che fanno alcune sue derivate (ad es. la Mint LMDE2).
di norma la gestione dei servizi (così come qualsiasi altra modifica a livello di sistema) richiede sempre i privilegi di amministratore (cioè di "impersonare" in qualche modo l'utente root). I moderni sistemi "desktop-oriented" hanno introdotto vari meccanismi che permettono un controllo più o meno fine su "chi può fare cosa", anche attraverso meccanismi nuovi e diversi da quelli tradizionali... ma per alcuni di questi la possibilità di utilizzarli implica l'esistenza di una serie di software e di servizi che nel ns. caso potrebbero non essere presenti, per cui nel ns. caso probabilmente la cosa migliore è utilizzare "sudo" (che, opportunamente configurato, consente comunque un controllo abbastanza fine su "chi può fare cosa").
Ultima modifica di UnixMan : 01-02-2016 a 20:38
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.»
Ho terminato una prima versione e vorrei provarla su Debian, quindi come prima cosa ho installato 8.3 i386 su una VM e lanciato lo script, rispondendo sempre come da default, tranne che ho scelto di installare solo il player (1).
Tutto procede speditamente fino ad
...
"Aggiunta del repository del Kernel Liquorix"
"Aggiornamento delle liste dei pacchetti..."
FATAL ERROR: Aggiornamento del DB di APT fallito.
Aborted:
$
NOTA BENE: ho riscritto copiando manualmente, non ho il browser sulla WM.
Cosa devo fare?
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
azz... c'è un problema con qualcuno dei repositories, forse proprio quello di liquorix. La rete nella VM funziona?
Prova a dare "apt-get update" a mano e guarda dov'è che da errore. Potrebbe essere un problema transitorio di uno dei repository... oppure è cambiato qualcosa e devo aggiornare lo script di conseguenza.
P.S.: ovviamente stai usando l'ultima versione dello script, giusto?
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.»
Si e si, l'ho scaricato dalla wm con il comando del primo post, poi ho anche fatto la verifica di aggiornamento.
Allora: apt-get update mi dice che non sono root.
su apt-get update
apt-get cannot execute binary file
Io ho installato questo: http://cdimage.debian.org/debian-cd/...86-netinst.iso senza Desktop, con il web server e le utilities comuni.
Installazione ripetuta prima di segnalare il problema.
Loggato come root:
riscaricato ed eseguito easetup, stesso problema.
apt-get update:
Get:1 http://mirror.unit193.net sid InRelease [6,700 B]
W: GPG error: ttp://mirror.unit193.net sid InRelease; The following signatres couldn't be verified because the public key is not available: NO_PUBKEY 3EFF4F272FB2CD80
E: The method driver /usr/lib/apt/methods/https could not be found.
N: Is the package apt-transport-https installed?
ò!°%__çççç°°°°°àààà####@@@@¡¡¡¡
apt-get install apt-transport-https
Unable to locate apt-transport-https
Ultima modifica di marcoc1712 : 03-02-2016 a 16:01
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
Ci sono attualmente 2 utenti che stanno visualizzando questa discussione. (0 utenti e 2 ospiti)
|
nexthardware.com - © 2002-2022 |
Rispondi quotando
