== NOTE ==

 * la env directory (che e` la directory di lavoro vera e propria
 di trac) e` definita dalla variabile trac-server.datadir, e punta
 come default a (workdir)/trac

 * la directory di lavoro di bazaar non e` parte di questo modulo:
 anche se tra i pkgs installati c'e` bazaar, se lo si vuole usare
 come server locale si configuri la macchina aggiungendo la classe
 server.fs (NOTA: quest'ultima classe, semmai, e` da rivedere in
 base agli ultimi cambiamenti di rotta sulla suddivisione dei
 servizi, vedi note aggiuntive)

== ATTIVAZIONE UTENTE SU PGSQL ==

<!> ATTENZIONE: questa procedura non e` valida, in quanto
per come funziona trac occorre creare un diverso database per
ogni repository bzr in gestione: dato che si prevede, per via
della pacchettizzazione dei progetti, di avere diverse decine
di progetti (e quindi repos bzr), diventa impraticabile
gestire la creazione e la manutenzione di cosi` tanti db
differenti, a meno di non trovare il modo di fare tutto in
modo batch; possibili soluzioni:

 * utilizzare sqlite (che e` locale ad ogni istanza trac) al
 posto di postgres

 * rivedere l'assunto per cui 1 package (.deb) = 1 progetto,
 che in effetti e` assurdo, ad esempio kusa pur essendo
 divisibile in decine di packages diversi, e` comunque un
 progetto unico: voglio vedere come si fa a gestire, ad
 esempio, il bug tracking se viene diviso in 50 progetti
 differenti; a questo scopo trac torna utile anche per capire
 queste storture di impostazione, dato che 1 istanza trac =
 1 progetto

riporto comunque le istruzioni per la configurazione e la
creazione di un db postgres (ipotetica, perche` al momento
ho interrotto la sua implementazione)

=== procedura creazione/attivazione postgres ===

l'attivazione necessita di informazioni condivise tra il server
che ospita trac e quelle che ospita postgres (che sia la stessa
macchina o meno non importa), in quanto per postgres si deve
modificare programmaticamente il file pg_hba.conf, quindi procedere
in questo modo:

 * nel file di configurazione di trac, quindi presente su questa
 macchina, inserire il server di riferimento, ad esempio nel
 file '''trac_server''' (sotto /etc/kusa/conf.d):
 {{{
[trac-server]
  db_server	srvdb	# questo dovrebbe essere comune
 }}}

 * per ogni istanza di trac, creare un corrispondente file di
 configurazione con questi dati (ovviamente con i valori
 corretti, NAME indica il nome dell'istanza = progetto), ad
 esempio nel file '''trac_NAME''':

 {{{
[trac_NAME]
  db_name	trac_NAME
  db_user	\::auth.trac_NAME.db_user\::
  db_password	\::auth.trac_NAME.db_password\::

[pgsql.hba.trac_NAME]
  database      \::trac_NAME.db_name\::
  user          \::trac_NAME.db_user\::
  method        md5
  include       \::trac.db_server\::	# abilita per questo host
 }}}

 suggerimento: utilizzare "kusa-conf --dump trac" per vedere i default

 * le informazioni sensibili (utente e password) sono da
 memorizzare in un file separato, con prefisso adm_ in modo che
 kusa le possa proteggere adeguatamente, come si vede nell'esempio
 precedente infatti i due valori rimandano ad altre definizioni
 inserite nella sezione [auth], creare quindi un file, ad
 esempio '''adm_trac_NAME''':
 {{{
[auth.trac_NAME]
  db_user	....
  db_password	....
 }}}

 * sulla macchina che ospita postgres, aggiungere all'elenco dei
 repos di configurazione la directory dove prendere il file sopra
 (ad esempio la subdir hosts/srvemsp), in modo da poter avere
 accesso alle informazioni di cui sopra

 * lanciando kusa sulla macchina db questo ricrea automaticamente
 il file di accesso di postgres per tutte le istanze trac definite

 * lanciando kusa sulla macchina trac, tramite il comando
 ku-trac-update, crea o aggiorna i files di configurazione di trac
 per accedere ai vari db in modo opportuno

== creazione database ==

 * connettersi in ssh al server db specificato nel config,
 direttamente come utente ''postgres'' o come utente ''root'' e poi
 eseguire un "su - postgres"

 * lanciare il comando
 {{{
psql template1 -W
 }}}
 ed inserire questo script sql:
 {{{
create database tracdb with encoding = 'utf8';
create user tracuser password 'password';
grant all on database tracdb to tracuser;
\q
 }}}
 sostituendo ovviamente alle keywork ''tracdb'', ''tracuser'' e ''password''
 i rispettivi valori come da configurazione

== creazione configurazione per istanza trac ==

Si utilizza per ogni istanza un file di kusa-conf, quindi presente
direttamente in /etc/kusa/conf.d o meglio, attraverso la sua
creazione nel repo di configurazione (progetto kucfg), come
abbiamo gia` visto nel capitolo riguardante la configuarzione per
l'accesso a postgres.

 * per ogni istanza trac esiste un file, il cui nome e` ad
 esempio, ''trac.NAME'', con questo contenuto:

 {{{
[trac.NAME]
  bzr_path	path_to_repository
  allow		\::perms.trac_NAME.allow\::
 }}}

 (oltre alle informazioni per l'accesso a postgress se si decide
 di passare per questa strada)

 * le info di accesso (allow=lista ip di accesso)
 sono da mettere in un corrispondente file '''adm_trac_NAME'''
 (assieme eventualemnte alla sezione per l'accesso a postgres):
 {{{
[perms.trac_NAME]
  allow		\::perms.applications_iplist\::
 }}}

 nella sezione generica [perms] sono indicati i default
 di accesso per le applicazioni, usate nell'esempio sopra,
 nulla vieta di creare entry specifiche ad esempio per
 gruppi di utenti, o di indicare direttamente nel file
 qui sopra la lista degli ip autorizzati, ad esempio creando
 una entry di default (ereditata quindi da tutte le sezioni
 trac.*):
 {{{
[trac]
  allow		\::perms.application_iplist\::
 }}}

Il comando ku-trac-update crea o aggiorna le directories e i
files di configurazione per l'istanza trac:

 * environment dir di trac
 * alias entry di apache

== NOTE AGGIUNTIVE ==

 * classe server.fs: attualmente il fileserver e` considerato il
 punto di riferimento del network, e quindi la classe server.fs
 comprende anche servizi diversi, come spooler di stampa, scanner,
 ecc., che convivono con altri servizi come quelli di archiviazione
 e versioning (bzr), probabilmente sarebbe bene separare in classi
 distinte questi servizi e rivedere quindi la definizione dei
 macro servers
