Gestione di gruppi di lavoro con strumenti open source

L’organizzazione di una azienda, di uno studio, necessità di condividere tra i collaboratori molte informazioni. Molto spesso queste informazioni sono sparse su una quantità di supporti eterogenea: rubrica cartacea, appunti, file sui diversi computer, conoscenze non scritte dei collaboratori. Questo comporta molto spesso inefficienze, ritardi nella trasmissione delle informazioni, perdita di informazioni.

Le organizzazioni più efficienti, da anni si sono dotate di strumenti di collaborazione per sopperire a ciò. Nella mia esperienza sono ancora troppo poche, soprattutto in Italia e non solo presso le piccole organizzazioni mancano questi strumenti.

Spesso si dice che costano troppo, che non servono, che sono troppo complesse. Niente di più falso.

Costi: Le soluzioni open source, quindi libere da costi di licenza sono sempre più numerose e sempre più complete.

Non servono: avere a disposizione in ogni momento la propria agenda, la propria rubrica e quella dei collaboratori, avere sottomano l’ultima offerta o lo stato di un ordine molto spesso fa la differenza tra acquisire e concludere un contratto o perderlo. Immagazzinare la conoscenza dell’organizzazione in questi strumenti puo’ sopperire alla mancanza di alcuni collaboratori (che magari se ne vanno portando via conoscenza).

Troppo complesse: sono tutte web based, intuitive. Con pochi clic si trovano le informazioni grazie anche ai potenti motori di ricerca inseriti all’interno.

La verità molto spesso è un’altra: non sono mai state provate a fondo per un periodo sufficiente, si pensa di perdere tempo ad inserire i dati. In sostanza è solo ed esclusivamente un fatto culturale.

Vediamo una applicazione che da tempo propongo ai clienti e che utilizziamo all’interno della nostra struttura: E-Groupware.

L’applicazione è presente sul mercato da svariati anni ed ha raggiunto una buona stabilità. Gira su qualsiasi sistema su cui gira un interprete php, un database mysql, un server web. Quindi gira su piattaforma Windows, Mac, Linux. E’ accessibile esclusivamente via web da qualsiasi dispositivo su cui giri un web browser: PC, MAC, Linux, iPhone, iPad, BlackBerry, cellulari in genere con capacità grafiche.

L’applicazione o, meglio il sistema, è composto da vari sottosistemi integrati tra di loro ad esempio:

  1. Rubrica condivisa o personale estendibile. E’ possibile garantire l’accesso alla propria rubrica ai membri dell’organizzazione in svariati livelli di accesso;
  2. Agenda personale condivisibile con i membri dell’organizzazione. E’ possibile ad esempio dare l’accesso alla propria segretaria per l’aggiornamento degli appuntamenti. Le viste possono essere giornaliere, settimanali, mensili. Gli appuntamenti si possono esportare rapidamente presso altre agende.
  3. Un completo sistema di gestione delle varie attività per gestire telefonate, mail, to do, note. Si possono categorizzare liberamente e gestire gli stati di avanzamento delle azioni (un mini crm praticamente)
  4. Un buon sistema per la gestione dei progetti (se la nostra azienda lavora per progetti ad esempio uno studio di ingegneria, di architettura);
  5. Un buon sistema di gestione del foglio ore utile per tracciare ad esempio attività da fatturare ai nostri clienti
  6. Un sistema per la gestione delle risorse aziendali su prenotazioni, ad esempio sale riunioni, auto aziendali, furgoni aziendali, apparecchiature di prova
  7. Un sistema completo per la gestione documentale aziendale completo di versioning, scadenza documenti, access list, ricerca per metadati (nella nostra organizzazione abbiamo svariate migliaia di documenti salvati all’interno e non da segni di cedimento o di lentezza)
  8. Un sistema di gestione documentale privato per ogni membro dell’organizzazione (che si usa poco, l’altro è molto più potente)
  9. Un sistema per la gestione della conoscenza aziendale classificabile in categorie utile per esprimere in documenti metodologie di lavoro, guide interne, policy aziendali.
  10. Un sistema wiki integrato, dalle funzionalità basilari;
  11. Integrazione e-mail, siti, notizie interne e molto altro ma meno utilizzati
  12. Soprattutto si puo’ estendere grazie alla buona documentazione offerta. Si possono quindi creare moduli ad hoc per l’azienda.

Le informazioni vengono tutte salvate su database relazionale e quindi è molto agevole accedere al sistema per effettuare ricerche non previste, analizzare le attività aziendali in ottica di migliorare la performance, etc.

Non vedo motivi quindi per non adottare un sistema del genere, in quanto i vantaggi che offre sono molti e di indiscutibile validità.

Articoli Correlati

Datawarehouse e Business Intelligence: Strumenti open source per soluzioni enterprise – Capitolo 2

Riprendiamo la nostra serie di articoli sul datawarehoure e la business intelligence in ambiente open source, vista la crescente domanda di spiegazioni che quotidianamente riceviamo sul nostro sito.

Oggi ci occuperemo dell’installazione del server Pentaho e della sua configurazione per un uso più aziendale, su un ambiente server linux Ubuntu 9.04 (dovrebbe andare bene anche con l’ultima release, magari con qualche piccolo cambiamento).

Procuratevi l’ultima release del server da sourceforge.

Creiamo la directory /opt/pentaho  eseguento in un terminale il comando sudo mkdir /opt/pentaho

Fatto questo creiamo un utente per esguire il server pentaho:

sudo addgroup pentaho

sudo adduser –system –ingroup pentaho –disabled-login pentaho

scompattiamo il software sulla cartella desiderata:

sudo  cd /opt/pentaho

sudo tar -zxvf  /directory/di/downloads/biserver-ce-stable-3.5.2.stable.tar.gz (è la versione corrente al momento della scrittura)

Cambiamo permessi alla directory:

sudo chown -R pentaho:pentaho /opt/pentaho

A questo punto siamo pronti per fare partire il server con il seguente comando:

sudo -u pentaho JAVA_HOME=/usr/lib/jvm/java-6-sun ./start-pentaho.sh

Se tutto è andato bene, indirizzando il proprio browser su http://localhost:8080/pentaho dovreste vedere la pagina di benvenuto.

Nel caso voleste cambiare la porta su cui ascolta il server, dovrete modificare le configurazioni di tomcat. Cercate quindi sotto la directory /opt/pentaho/biserver-ce/tomcat/conf il file server.xml e cambiate la seguente parte:

<Connector port=”8080″ maxHttpHeaderSize=”8192″
maxThreads=”150″ minSpareThreads=”25″ maxSpareThreads=”75″
enableLookups=”false” redirectPort=”8443″ acceptCount=”100″
connectionTimeout=”20000″ disableUploadTimeout=”true” />

Se cambiate la porta di ascolto, dovrete modificare anche un altro file, web.xml, situato in tomcat/webapps/pentaho/WEB-INF nella seguente parte:

<context-param>
<param-name>base-url</param-name>
<param-value>http://localhost:8080/pentaho/</param-value>
</context-param>

Riavviate il server e verificate la nuova configurazione.

Buona norma sarebbe a questo punto creare uno script per l’avvio automatico del sistema quando si accende il server. (ma lo vedremo un’altra volta)

Un altro punto per la configurazione del server in ambito aziendale, è la configurazione dei connettori agli svariati database che si possono trovare in ambito aziendale. Di default il sistema viene fornito con i driver per i seguenti tre database:

  1. HSQLDB
  2. MySQL
  3. PostgreSQL

Tali driver li troverete nella directory tomcat/commn/lib. In tale directory dovrebbero essere messi ulteriori driver per la connesisone ad altri database (ad esempio i driver per la connessione ai sistemi Oracle oppure SQL Server).

Di default il sistema viene fornito con tre databases di sistema:

  1. hibernate – usato per registrare gli utenti, le password, i repositary di soluzioni ed altro;
  2. quartz – lo scheduler;
  3. sampledata – un database di esempio per cominciare a lavorare con il sistema.

Tutti e tre sono gestiti tramite il sistema HSQLDB, ma è più utile migrarli su qualcosa di più conosciuto, come MySQL, ORACLE oppure PostgreSQL.

Qui vediamo come migrarli su MySQL (premesso che il server MySQL sia gia’ installato e configurato).

Spostatevi quindi nella directory /opt/pentaho/biserver-ce/data/mysql5 ed eseguite i seguenti comandi:

  1. mysql -h localhost –u root -p < /opt/pentaho/biserver-ce/data/mysql5/create_repositary_mysql.sql
  2. mysql -h localhost –u root -p < /opt/pentaho/biserver-ce/data/mysql5/create_sample_datasource_mysql.sql
  3. mysql -h localhost –u root -p < /opt/pentaho/biserver-ce/data/mysql5/create_quartz_mysql.sql

A questo punto, dobbiamo riconfigurare Quartz e Hibernate.

Niente di più semplice.

Quartz:

Aprite il file tomcat/webapps/pentaho/META-INF/context.xml e modificatelo così:

<?xml version=”1.0″ encoding=”UTF-8″?>
<Context path=”/pentaho” docbase=”webapps/pentaho/”>
<Resource name=”jdbc/Hibernate” auth=”Container” type=”javax.sql.DataSource”
factory=”org.apache.commons.dbcp.BasicDataSourceFactory” maxActive=”20″ maxIdle=”5″
maxWait=”10000″ username=”hibuser” password=”password”
driverClassName=”org.hsqldb.jdbcDriver” url=”jdbc:hsqldb:hsql://localhost/hibernate”
validationQuery=”select count(*) from INFORMATION_SCHEMA.SYSTEM_SEQUENCES” />

<Resource name=”jdbc/Quartz” auth=”Container” type=”javax.sql.DataSource”
factory=”org.apache.commons.dbcp.BasicDataSourceFactory” maxActive=”20″ maxIdle=”5″
maxWait=”10000″ username=”pentaho_user” password=”password”
driverClassName=”com.mysql.jdbc.Driver” url=”jdbc:mysql://localhost:3306/quartz
validationQuery=”select 1“/>
</Context>

Hibernate:

aprite il file tomcat/webapps/pentaho/META-INF/context.xml e modificatelo nel seguente modo:

<?xml version=”1.0″ encoding=”UTF-8″?>
<Context path=”/pentaho” docbase=”webapps/pentaho/”>
<Resource name=”jdbc/Hibernate” auth=”Container” type=”javax.sql.DataSource”
factory=”org.apache.commons.dbcp.BasicDataSourceFactory” maxActive=”20″ maxIdle=”5″
maxWait=”10000″ username=”hibuser” password=”password”
driverClassName=”com.mysql.jdbc.Driver” url=”jdbc:mysql://localhost:3306/hibernate
validationQuery=”select 1” />

<Resource name=”jdbc/Quartz” auth=”Container” type=”javax.sql.DataSource”
factory=”org.apache.commons.dbcp.BasicDataSourceFactory” maxActive=”20″ maxIdle=”5″
maxWait=”10000″ username=”pentaho_user” password=”password”
driverClassName=”com.mysql.jdbc.Driver” url=”jdbc:mysql://localhost:3306/quartz
validationQuery=”select 1“/>
</Context>

Ora spostatevi in pentaho-solutions/system/hibernate e modificate il file hibernate-settings.xml:

<?xml version=’1.0′ encoding=’utf-8′?>
<settings>

<!–
* This setting allows the deployment to specify where to find the
* database-specific hibernate configuration. The samples supplied
* include the following:
*
* system/hibernate/hsql.hibernate.cfg.xml
* system/hibernate/mysql5.hibernate.cfg.xml
* system/hibernate/postgresql.hibernate.cfg.xml
* system/hibernate/oracle10g.hibernate.cfg.xml
*
–>
<config-file>system/hibernate/mysql5.hibernate.cfg.xml</config-file>

<!–
*
* managed should be set to true if running the BI Platform
* in a managed environment (like JBoss, Orion, etc). In this configuration,
* you should specify another location for the hibernate.cfg.xml (see below)
* instead of simply using the default one provided. This setting essentially
* tells the HibernateUtil class to use JNDI to locate the factory class for
* getting sessions. This allows the platform to use Hibernate across boundaries
* in message beans (for example).
*
<managed>false</managed>
–>

<managed>false</managed>
</settings>

Editate quindi il file mysql5.hibernate.cfg.xml:

<?xml version=’1.0′ encoding=’utf-8′?>
<!DOCTYPE hibernate-configuration
PUBLIC “-//Hibernate/Hibernate Configuration DTD//EN”
“http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd”>
<hibernate-configuration>
<session-factory>

<property name=”cache.provider_class”>org.hibernate.cache.EhCacheProvider</property>

<property name=”hibernate.generate_statistics”>true</property>
<property name=”hibernate.cache.use_query_cache”>true</property>

<!–  MySQL Configuration –>
<property name=”connection.driver_class”>com.mysql.jdbc.Driver</property>
<property name=”connection.url”>jdbc:mysql://localhost:3306/hibernate</property>
<property name=”dialect”>org.hibernate.dialect.MySQL5InnoDBDialect</property>
<property name=”connection.username”>hibuser</property>
<property name=”connection.password”>password</property>
<property name=”connection.pool_size”>10</property>
<property name=”show_sql”>false</property>
<property name=”hibernate.jdbc.use_streams_for_binary”>true</property>
<!– replaces DefinitionVersionManager –>
<property name=”hibernate.hbm2ddl.auto”>update</property>
<!– load resource from classpath –>
<mapping resource=”hibernate/mysql5innodb.hbm.xml” />
<!–  This is only used by Pentaho Administration Console. Spring Security will not use these mapping files –>
<mapping resource=”PentahoUser.hbm.xml” />
<mapping resource=”PentahoRole.hbm.xml” />

</session-factory>
</hibernate-configuration>

Siamo quasi alla fine.

editate il file pentaho-solutions/system/applicationContext-sring-security-jdbc.xml:

<?xml version=”1.0″ encoding=”UTF-8″?>
<!DOCTYPE beans PUBLIC “-//SPRING//DTD BEAN//EN” “http://www.springsource.org/dtd/spring-beans.dtd”>

<!–+
| Application context containing JDBC AuthenticationProvider
| implementation.
+–>

<beans>

<bean id=”daoAuthenticationProvider”
class=”org.springframework.security.providers.dao.DaoAuthenticationProvider”>
<property name=”userDetailsService”>
<ref bean=”userDetailsService” />
</property>
<property name=”passwordEncoder”>
<ref bean=”passwordEncoder” />
</property>
</bean>

<bean id=”userDetailsService”
class=”org.springframework.security.userdetails.jdbc.JdbcDaoImpl”>
<property name=”dataSource”>
<ref local=”dataSource” />
</property>
<property name=”authoritiesByUsernameQuery”>
<value>
<![CDATA[SELECT username, authority FROM GRANTED_AUTHORITIES WHERE username = ? ORDER BY authority]]>
</value>
</property>
<property name=”usersByUsernameQuery”>
<value>
<![CDATA[SELECT username, password, enabled FROM USERS WHERE username = ? ORDER BY username]]>
</value>
</property>
</bean>
<!–  This is only for Hypersonic. Please update this section for any other database you are using –>
<bean id=”dataSource”
class=”org.springframework.jdbc.datasource.DriverManagerDataSource”>
<property name=”driverClassName” value=”com.mysql.jdbc.Driver” />
<property name=”url”
value=”jdbc:mysql://localhost:3306/hibernate” />
<property name=”username” value=”hibuser” />
<property name=”password” value=”password” />
</bean>

<bean id=”passwordEncoder”
/>

</beans>

editate il file pentaho-solutions/system/applicationContext-spring-security-hibernate.properties:

jdbc.driver=com.mysql.jdbc.Driver
jdbc.url=jdbc:mysql://localhost:3306/hibernate
jdbc.username=hibuser
jdbc.password=password
hibernate.dialect=org.hibernate.dialect.MySQLDialect

Fate ripartire tutto e… buon divertimento.

Alla prossima



Articoli Correlati

Datawarehouse e Business Intelligence: Strumenti open source per soluzioni enterprise

In un precedente articolo abbiamo dato la classica definizione di data warehouse (l’articolo può essere letto qui).

Ora vediamo quali sono gli strumenti che si possono usare seguendo ovviamente una logica open source come da nostra prassi:

  1. Una buona conoscenza di cosa è e cosa non è un datawarehouse;
  2. Un buon database server;
  3. Una buona suite di Business Intelligence (BI nel seguito) per poter estrapolare informazioni dai dati contenuti nel data warehouse costruito;

Per quanto riguarda il punto 1 non c’e’ che un percorso: documentarsi in rete, leggere e studiare qualche buon libro teorico, sperimentare alcuni piccoli progetti di prova. Un percorso lungo che pero’ ne vale la pena se si vuole lavorare nel settore.

Per quanto riguarda il punto due le alternative open source da tenere in considerazione, ovviamente a mio parere, sono soprattutto due: Mysql e Postgresql. Nei nostri progetti scegliamo spesso Mysql ma non in modo esclusivo.

Per quanto riguarda il punto 3 da tempo abbiamo scelto la piattaforma Open Source  di Pentaho (esiste anche la versione commerciale). E nel seguito vediamo anche il perchè.

La piattaforma pentaho integra tutta una serie di prodotti utili per la costruzione di un sistema completo di BI:

  1. Mondrian: il motore Olap;
  2. Kettle: lo strumento ETL;
  3. Report Designer:tool visuale per creare analisi e report;
  4. Weka: il tool per le analisi di data mining;
  5. Dashboards: per creare cruscotti aziendali si semplice e immediato uso;
  6. Il server vero e proprio.

Il server pentaho, cuore del motore, puo’ essere eseguito dentro un web server Java EE compliant quale Apache Tomcat oppure Jboss. Questo componente provvede a garantire i servizi di scheduling, sicurezza, integrazione, navigazione dei contenuti, invio di e-mail e molto altro.

Il sistema è abbastanza semplice da installare e da provare sugli ambineti più comuni quali Microsoft Windows, Linux, Mac OS X avendo la pazienda di scaricare  molte decine di megabyte dal sito di pentaho oppure dal classico Sourceforge.

In un prossimo articolo vedremo come installare il server e gli altri applicativi necessari al progetto. Per adesso se volete provare installate il server e visualizzate gli esempi che vengono installati con essi.

Articoli Correlati

Amministratori di sistema: un sistema di log open source

Domani entra in vigore il famigerato decreto sugli amministratori di sistema.

Questa è una soluzione che abbiamo sviluppato e che proponiamo ai nostri clienti per quanto riguarda la parte tecnica, gestione dei log degli accessi degli amministratori di sistema.

Nel pieno rispetto dell’open source presentiamo una soluzione a basso costo utilizzando sistemi liberamente scaricabili da internet.

Sistemi per la gestione dei log ne esistono di tutti i tipi e per tutte le tasche ma, leggendo le caratteristiche di molti a pagamento… abbiamo subdorato che molto spesso sono dei pc embedded con programmi open source venduti a svariati migliaia (se non decine di migliaia) di euro. Vediamo come fare utilizzando la rete.

Prendimao un pc con una buona dotazione di spazio disco (e poi vedremo perchè) e installiamoci una distribuzione open source linux (noi lavoriamo con ubuntu… ma il discorso si puo’ fare con qualsiasi altra distribuzione avendo l’accortezza di utilizzare i comandi adeguati).

A questo punto montiamoci un server MySql e quindi utilizziamo come log server centralizzato il sistema Syslog-ng per salvare tutti i dati sul database menzionato.

Seguendo le direttive trovate sul seguente link:  http://www.openskill.info/infobox.php?ID=1466

Innanzitutto e’ necessario  connettendosi a mysql con il comando mysql -u username -p passwhord -h 127.0.0.1 e creare il database che conterra’ i log con il comando create database db_log;.
Si presuppone che mysql sia in esecuzione sullo stesso sistema del syslog server ed in ascolto sull’indirizzo di loopback.
Una voltra create il database si suggerisce di creare un utente apposito che abbia i privilegi sullo stesso, in modo di evitare di utilizzare l’utenza di root. Anche in questo caso e’ necessario loggarsi al dbms con un mysql -u username -p password -h 127.0.0.1 ed eseguir eil seguente comando:
GRANT ALL PRIVILEGES ON db_syslog.* TO syslog_user@127.0.0.1 IDENTIFIED BY 'syslog_password'.
L’ultima operazione da eseguire sul database e’ la creazione della tabella che conterra’ i messaggi syslog salvati da syslog-ng. Tale operazione puo’ essere portata a termine con il comando mysql -u syslog_user -p syslog_password -h 127.0.0.1 < syslog_table.sql .
syslog_table.sql sara’ un file di testo contenente le istruzione per creare la tabella, e dovra’ contenere le seguenti linee:

#
# Table structure for table `logs`
#

CREATE TABLE logs (

host varchar(32) default NULL,
facility varchar(10) default NULL,
priority varchar(10) default NULL,
level varchar(10) default NULL,
tag varchar(10) default NULL,
date date default NULL,
time time default NULL,
program varchar(15) default NULL,
msg text,
seq int(10) unsigned NOT NULL auto_increment,

PRIMARY KEY (seq),

KEY host (host),
KEY seq (seq),
KEY program (program),
KEY time (time),
KEY date (date),
KEY priority (priority),
KEY facility (facility)

) TYPE=MyISAM;

Ovviamente nel caso il file syslog_table non sia nella stessa directory dalla quale viene lanciato il client mysql sara’ necessario specificare il percorso del file in questione.
Una volta predisposta la parte relativa al database, e’ stata aggiunta la seguente destinazione al file di configurazione di syslog-ng /etc/syslog-ng/syslog-ng.conf:

#file di destinazione con query sql che saranno processate dal feeder
destination file_sql {
file(“/var/log/sqllog/log_sql_$HOUR.$MIN”
template(“INSERT INTO logs (host, facility, priority, level, tag, date, time, program, msg) VALUES ( ‘$HOST’, ‘$FACILITY’, ‘$PRIORITY’, ‘$LEVEL’, ‘$TAG’, ‘$YEAR-$MONTH-$DAY’, ‘$HOUR:$MIN:$SEC’,’$PROGRAM’, ‘$MSG’ );n”)
template_escape(yes));
};

Questa direttiva fa in modo che all’interno del file /var/log/sqllog/log_sql_ORA.MINUTO vengano inserite una serie di istruzioni INSERT SQL che una volta eseguite dal client mysql andranno ad inserire i dati nella tabella logs del database db_syslog.
A meno che nel file di configurazione di syslog-ng non sia posta a yes l’opzione create_dirs sara’ necessario creare la directory /var/log/sqllog ed impostare dei permessi coerenti con le opzioni owner, group, perm, dir_owner, dir_group e dir_perm se definite nel file di configurazione di syslog-ng.
Inoltre, come si puo’ notare dall’opzione file della direttiva destination, non verra’ creato un singolo file ma diversi a seconda dell’ora e del minuto in cui verranno generati. Tale scelta si e’ resa necessaria per semplificare la creazione e l’esecuzione dello shellscript che eseguira effettivamente gli inserimenti nek database e che verra’ successivamente illustrato.

Infine, la nuova destinazione creata dovra’ essere utilizzata all’interno di una direttiva log del file /etc/syslog-ng/syslog-ng.conf perche’ qualcosa possa essere scritto all’interno del file /var/log/sqllog/log_sql_ORA.MINUTO:

#log query per il feeder
log { source(s_all); destination(file_sql); };

Con questa configurazione, pero’, nessun dato viene ancora scritto all’interno del database ma vengono solo scritte delle istruzioni INSERT nei file /var/log/sqllog/log_sql_ORA.MINUTO.
E’ quindi necessario creare uno script che prenda questi file e inserisca effettivamente i log all’interno del database, ad esempio /opt/syslg-db/feeder.sh:

#!/bin/bash
# Script adattato da process_logs di  Casey Allen Shobe

dbhost=”localhost”
dbuser=”syslog_user”
dbpass=”syslog_password”
dbname=”db_log”
datadir=”/var/log/sqllog”

while true; do
logfiles=`find $datadir -name “log_sql_[0-2][0-9].[0-5][0-9]”`
sleep 70 # This is to ensure we don’t screw up a log currently being written.
for logfile in $logfiles; do
cat $logfile | mysql –user=$dbuser –password=$dbpass $dbname
if [ $? -ne 0 ]; then
echo “[ERRORE] Problema nel processare il file $logfile!!!” >> $datadir”/feeder_log.log”
#exit 1 #Comment out this line if you want the script to
else
echo “[OK] $logfile inserito nel db in data `date –rfc-3339=seconds`” >> $datadir”/feeder_log.log”
rm -f $logfile
fi
done
done

Nella parte iniziale dello script vengono definite alcune variabili d’ambiente che indicano i parametri da utilizzare per la connessione al database e la directory dove si trovano i files scritti da syslog-ng contenenti le istruzioni inserti da eseguire.
Un aspetto importante dello script e’ l’istruzione sleep 70 eseguita all’interno del ciclo while dopo avere settato la variabile contenente i nomi dei file da processare durante l’iterazione corrente. Quando eseguita essa sospende l’esecuzione dello script per 70 secondi, in modo da impedire che possa essere processato un file in corso di scrittura da parte di syslog-ng.
Poiche’ la destination definita nel file di configurazione di syslog-ng, prevede la creazione di un nuovo file di log ogni minuto (grazie all’utilizzo della macro $MIN), con una sleep di 70 secondi si avra’ la sicurezza che i files definiti nella variabile logfiles non siano piu’ oggetto di scrittura, essendo trascorsi almeno 60 secondi dalla loro creazione.
Per ognuno di questi file, infine, vengono eseguite le istruzioni INSERT in essi contenute passandole in input al client mysql tramite la linea cat $logfile | mysql --user=$dbuser --password=$dbpass $dbname.
Una volta processato, il file viene rimosso tramite il comando rm -f. Lo script verifica inoltre l’exit code del comando mysql ed in base ad esso scrive l’esito del processing del file in /var/log/sqllog. Questa operazione puo’ anche essere considerata superflua ed evitata semplicemente commentando le due istruzioni echo all’interno del ciclo for.
Infine, per automatizzare l’utilizzo dello script feeder.sh e’ possibile modificare lo script /etc/syslog-ng/syslog-ng in modo da avviare e terminare automaticamente feeder.sh insieme al syslog server:

#!/bin/sh
#
[…]

start() {
echo -n $”Starting $prog: ”
daemon $exec $SYSLOGNG_OPTIONS
retval=$?
echo
[ $retval -eq 0 ] && touch $lockfile
echo “Starting Feeder”
/opt/syslg-db/feeder.sh &
return $retval
}

stop() {
echo “Stopping Feeder”
killall feeder.sh
echo -n $”Stopping $prog: ”
killproc $prog
retval=$?
echo
[ $retval -eq 0 ] && rm -f $lockfile
return $retval
}

[…]

Bene a questo punto il server è a posto, ricordandosi di abilitare la ricezione dei log remoti modificando una riga su /etc/syslog-ng/syslog-ng.conf . La riga in questione comincia con #udp(). Cancellate il carattere #, salvate riavviate il server syslog- Bene il sistema è quasi pronto.

Passiamo ai clients.

Se i client sono linux, nessun problema, installate su tutti il demone syslog-ng e modificatene il contenuto aggiungendo le seguenti righe:

destination d_loghost  { udp(“ip_server_log”);  };

log { source (s_all); destination (d_loghost);};

Riavviate sui client il demone syslog-ng e il server comincerà a ricevere i log.

Passiamo ai clienti Windows (per client, intendo server windows che manderanno i log sul server di log centralizzato)

Per windows ho testato  Snare Agent per windows, un pacchetto open source che installa un servizio per il log degli eventi su windows ed è amministrabile tramite una pagina web. L’installazione si limita al solito doppio click sull’eseguibile, all’impostazione della password ed alla scelta se permettere o meno l’accesso remoto alla pagina di configurazione del servizio. Per effettuare la configurazione è sufficiente puntare il browser su localhost:6161. Utente e password di default sono snare/snare, da cambiare immediatamente.

La configurazione da impostare per avere il log remoto è sulla pagina network. Basta impostare  Destination Snare Server address con l’indirizzo ip del server di log e come  destination  port  514. Attivare Enable Syslog  Header e selezionare come syslog facility auth, con livello notice.

Stanchi? un attimo di pazienza tra un po’ è finito.

A questo punto abbiamo tutti i nostri log su un server mysql. La normativa ci impone di salvarli su supporti non modificabili (cd o dvd in pratica).

Lo risolviamo in questo modo:

Scriviamo un piccolo script che ad una certa ora (impostata con cron) viene eseguito per estrarre i dati dal database e scriverli in un file che poi recupereremo per trasferirlo in un cd  e/o DVD.

lo script è il seguente:

#!/bin/bash
dbhost=”localhost”
dbuser=”syslog_user”
dbpass=”syslog_password”
dbname=”db_log”
filebackup=backup-log-$(date +%d-%m-%Y –date=”yesterday”)
/usr/bin/mysql –user=$dbuser –password=$dbpass $dbname < /opt/syslg-db/query.sql > /home/log/$filebackup.txt
gzip /home/log/$filebackup.txt

il contenuto del file sql query.sql è questo:

select * from logs where date=(select curdate() – interval 1 day);

Per recuperare il tutto abbiamo utilizzato il servizio ftp (il server  non ha monitor e/o tastiera). Installiamo il demone proftpd, lo configuriamo e creiamo un utente log. A questo punto, a tempi prefissati, ci recuperiamo i files da scrivere sui CD e/o DVD

Alcune note di prestazione: da un nostro cliente con una decina di server e con circa 100 client con tale sistema in meno di cinque giorni abbiamo un db con oltre 2 milioni di righe!!!!  Diventa importante quindi eseguire ogni tanto un task per cancellare dal db i record vecchi di n giorni ( a questo punto è banale l’implementazione).

Altra nota: il garante ci dice che dobbiamo loggare anche tutti gli accessi degli amministratori sui pc che trattano dati pernonali e/o sensibili.. i log diventeranno ancora di più.

Abbiamo finito, questa è una soluzione che abbiamo ritenuto soddisfacente i requisiti minimi del garante (a seguito anche di incontri con esponenti del Garante stesso). Non saraà perfetta, sarà migliorabile, ma funziona.

Attendiamo commenti

Articoli Correlati

Mysql Versus MS SQL Server

Da utilizzatore di Database (anche programmatore molto spesso) mi sono imbattuto su questo articolo, di parte certo, che pero’ nell’esperienza nei diversi database che ho mi sembra ben fatto.

E’ molto tecnico, è in inglese ma, a fronte dei costi di soluzioni open source (attenzione che non vuol dire aggratis!!!!) in tempi in cui le aziende hanno bisogno di soluzioni valide ma comunque “economiche”, una lettura va fatta.

E poi non dimentichiamo che il database server Mysql è usato in moltissime applicazioni proprio per le sue caratteristiche di semplicità e di performance. Da alcuen versioni fa all’attuale poi ha introdotto anche le transazioni, i cluster e molto altro che lo stanno portando un po’ fuori da quell’ambiente di smanettoni a cui era relegato fino a poco tempo. Resta comunque un’ombra, che spero si dipani presto, sulla possibile futura licenza di Mysql dopo l’acquisizione avvenuta da Sun e poi quest’ultima acquisita da Oracle.

Comunque buona lettura.

Articoli Correlati