Re: [riminilug-general] Scelta server per repository Git ed alternative

[Antonino <antonino.cardillo@xxxxxxxxxxxx>]

>----Messaggio originale----
>Da: antonino.cardillo@xxxxxxxxxxxx
>Data: 05/12/2012 10.21
>A: <riminilug-general@xxxxxxxxxxxx>
>Ogg: [riminilug-general] Scelta server per repository Git ed alternative
>
>Salve a tutti, di seguito riporto una discussione sull'argomento in oggetto 
che 
>c'è stata in questi giorni fra i soci Antonino (io), Ivan e Roberto 
Forlani, 
>che abbiamo creduto bene di estendere ai soci del RiminiLug e non solo, per 
>avere anche una vostro contributo al riguardo.
>
>Antonino
>Ciao, dimmi che ne pensi di questo server per repository git open e
>privati, se fà al caso nostro oppure no.
>https://bitbucket.org/
>
>Ivan
>l'avevo valutato anch'io (anche se non lo conosco bene) e potrebbe essere 
>un'alternativa a github.
>C'è il limite, per i repository privati, di max 5 utenti. Magari nel nostro 
>caso potrebbe non essere un grosso problema, almeno finchè i soci attivi 
sui 
>progetti non sono molti.
>La cosa che finora mi ha frenato è la mancanza di alcune features 
interessanti 
>rispetto a github e la pigrizia (github lo conosco, bitbucket no, e a naso 
mi 
>sembra meglio il primo).
>In realtà stavo anche valutando un'altra soluzione che mi era venuta in 
mente: 
>invece di salvare le credenziali nel file di cfg asterisk, si potrebbero 
usare 
>delle variabili d'ambiente opportunamente settate.
>In questo caso, nel file comparirebbero solo i nomi di queste variabili, 
poi 
>queste verrebbero assegnate sul server asterisk e non finirebbero su git.
>la cosa avrebbe 2 vantaggi principali:
>- le credenziali non finoscono sul file e quindi su git pubblico
>- volendo replicare il funzionamento su un altro server magari con account 
SIP 
>diverso (dopo aver fatto il git checkout) non devo modificare il file cfg, 
ma 
>solo settare le mie variabili d'ambiente.
>Quest'ultimo punto mi pare importante; se infatti le credenziali rimangono 
sul 
>file, e io faccio un checkout, modifico le credenziali per usare il mio SIP 
>account, faccio qualche modifica e voglio rifare il commit... al successivo 
>checkout di qualcun altro, questo dovrebbe rimettere mano al file per 
cambiare 
>l'account SIP.
>Devo sperimentare però se la cosa può funzionare.... anzi sarebbe 
>un'interessante cosa da provare assieme al lab;
>
>Antonino 
>La scelta del server legata al numero di account credo si potrebbe aggirare 
>creando più registrazioni per ogni progetto, se poi anche in quel caso il 
>numero di chi collabora al progetto è superiore a 5 (speriamo :-) ) allora 
>credo che è da evitare in partenza.
>L'idea delle variabili d'ambiente mi gusta, ma se invece utilizzassimo la 
>memorizzazione in db come dizionari, il quale non committiamo su git...
>
>Ivan
>anche il db può andare...ma poi come si collega il db ad asterisk?
>Io pensavo alle variabili perchè mi sembrava di aver visto che nei files di 
>configurazione sia possibile utilizzare un formalismo che permette di 
usarle. 
>Per il db non so, ma possiamo approfondire.
>Oppure (ma non so se e come sia possibile) usare un file esterno di cui 
fare 
>una sorta di include dal file di cfg principale.
>
>Antonino
>Ho trovato queste funzioni, mercoledì le provo se non prima, credo che si 
>possono dare i comandi anche dalla CLI, quindi senza avere traccia nei 
file, 
>per quanto riguarda la scrittura delle chiavi/valori, mentre per la lettura 
>usiamo il comando nel file specifico. Teoricamente è fattibile, come ti ho 
>detto provo e ti faccio sapere. Ciao.
>http://www.voip-info.org/wiki/view/Asterisk+func+db
> 
>Roberto
>mi intrometto, la scelta del db non mi dispiace, ma soprattutto per 
utilizzi 
>futuri oltre che per questa necessità in particolare, invece creare uno 
script 
>(magari chiamandolo da un comando alias in bash), che alla chiamata apre il 
>file di configurazione e setta i parametri sensibili?
>
>Antonino
>Ok , possiamo usare l'applicazione ReadFile() di Asterisk in concomitanza 
con 
>l'applicazione System() se serve.
>http://www.voip-info.org/wiki/view/Asterisk+cmd+ReadFile
>
>Antonino
>Questa di seguito la mia soluzione per leggere da un file scritto in 
>precedenza formattato con separatore la virgola
>
>File extensions.conf
>[default]
>exten=>500,1,Set(varname=${FILE(/myfile,0,30)}) ;leggo il contenuto del 
file 
>per una lunghezza di 30 caratteri e lo memorizzo nella variabile 'varname'
>exten=>500,n,Set(user=${CUT(varname,\,,2)}) ;faccio un CUT della variabile 
>prendendo il secondo elemento e lo memorizzo nella variabile 'user'
>exten=>500,n,Set(password=${CUT(varname,\,,4)}) ; idem ma memorizzo nella 
>variabile 'password'
>exten=>500,n,NoOp(${user}, ${password}) ; visualizzo in console il 
contenuto 
>delle 2 variabili
>
>file "myfile" posizionato in root
>user,5000,password,1234
>
>Ivan
>Giusto una nota:
>il file lo strutturerei in maniera un po' diversa, cosě forse si potrebbe 
>utilizzare per multipli account evitando ripetizioni e lasciandolo piů 
pulito:
>
>;user,password
>5000,1234
>5001,1234
>
>Ivan
>
>PS
>ho trovato i riferimenti per usare le variabili d'ambiente:
>http://www.voip-info.org/wiki/view/Asterisk+variables
>
>Come vedete, di modi ce ne sono tanti :)
>
>Roberto
>per quanto concerne git, si potrebbe creare un server git remoto su cloud 
>storage gratuito tipo ubuntu one oppure dropbox:
>vi passo qualche link "ad usum pizzaiolum napolitanur"
>
>http://michael.otacoo.com/linux-2/setting-a-git-server-with-dropbox/
>http://rogerstringer.com/2012/04/16/using-dropbox-as-a-git-repository/
>http://www.informit.com/articles/article.aspx?p=1629015&seqNum=3
>
>quante ne so!! ma quante ne so!!!
> 
>Ivan
>In effetti anche questa è un'alternativa. E testimonia l'enorme 
flessibilità 
>di git rispetto ad altri vcs.
>Io però personalmente preferirei usare github, con l'accortezza di gestire 
le 
>credenziali su file separati, come stiamo analizzando.
>Alcune personalissime considerazioni:
>
>- a livello di progetto RiminiLUG, sarebbe imo meglio condividere al 
massimo 
>il lavoro svolto
>- github è più votato alla condivisione, rispetto a repo più "nascosti" 
come 
>potrebbero essere su ubuntu one e dropbox; seppure li possiamo fare 
pubblici, 
>se non pubblicizziamo il link nessuno lo saprà... invece in github, se uno 
>naviga sull'account riminilug può vedere anche gli altri progetti
>- su github posso creare i miei fork, che rimangono comunque "legati" al 
>progetto principale; questo facilita i test da parte di terzi, senza 
sporcare 
>il repo diciamo così "ufficiale"
>- github mette a disposizione anche strumenti di notifiche (segui un 
>progetto), commenti e social-sourcing
>- github mette a disposizione un wiki (ok, semplificato) su cui 
eventualmente 
>inserire alcune nozioni di base per l'installazione e l'uso del progetto, 
>oppure delle licenze
>- github si integra con redmine... chissà, un giorno ?!?
>- NON HO azioni di github :D
>
>
>---------------------------------------------------------------------
>Per cancellarsi, scrivi a: riminilug-general-unsubscribe@xxxxxxxxxxxx
>Se vuoi conoscere altri comandi, scrivi a: riminilug-general-help@riminilug.
it
>
>

Se riusciamo a trovare un'alternativa all'esposizione dei dati sensibili, come 
quelle esposte fin ora , credo che la scelta di GitHub vada più che bene.

---------------------------------------------------------------------
Per cancellarsi, scrivi a: riminilug-general-unsubscribe@xxxxxxxxxxxx
Se vuoi conoscere altri comandi, scrivi a: riminilug-general-help@xxxxxxxxxxxx