Old:Kernel 2.6 su Debian Woody: differenze tra le versioni

Vai alla navigazione Vai alla ricerca
m
Formattazione
m (Formattazione)
Riga 1: Riga 1:
==Premessa==
=Premessa=
Questa piccola guida, in questa sua prima versione, descrive velocemente la procedura per abilitare il logging di sistema su di un database MySQL. Essendo questo un compito di indirizzo prettamente professionale, non mi sono soffermato pi� di tanto nello spiegare i dettagli della procedura. Tantomeno ho elencato nel dettaglio _tutti_ i comandi necessari, presumendo che chi legge abbia le competenze necessarie a completare le mie eventuali lacune. Qualsiasi commento o correzione � il benvenuto e sar� integrato in eventuali riscritture di questa guida che, in questa stesura, � poco pi� della traccia da me seguita in diverse occasione per realizzare quanto spiegato.
A volte si ha la necessità o il desiderio di poter sfruttare un kernel della serie 2.6.x sulla versione Woody (la stable al momento in cui scrivo).
Buona lettura e happy hacking!
Niente di più facile usando i backports!


=Preparare il sistema=
Editiamo il nostro '''/etc/apt/sources.list''' e aggingiamo la riga:
<pre>deb http://www.backports.org/debian woody kernel-2.6</pre>
che mette a disposizioni i nuovi pacchetti '''modutils''', '''module-init-tools''' e '''sysfsutils'''.


==Logging su MySQL==
=Scegliere il kernel=
Spesso, specie in ambiente professionale, si ha la necessit� di memorizzare i logs di sistema in una localit� centralizzata vuoi per motivi di sicurezza che di semplice monitoraggio. Syslogd permette di implementare in maniera banale questa possibilit�, ma a volte ci si trova nella necessit�/desiderio di voler dare a questi logs una forma facilmente gestibile e interrogabile come ad esempio un database MySQL.
A questo punto è necessario indicare esplicitamente nel sources.list il pacchetto che vogliamo utilizzare per il nuovo kernel. Questo può essere l' immagine di un kernel o i sorgenti di un kernel debianizzato a scelta tra quelli disponibili all' url: [http://www.backports.org/debian/dists/stable]
Esiste un syslogger che fa questo per noi, si tratta di syslogd-ng, per� non sempre � possibile sostituire il logger in maniera indolore e trasparente.
e costruendo una riga del sources.list così fatta:
In tutte queste situazioni viene in nostro aiuto una piccola utility : sqlsyslogd, realizzata da [mailto:venglin@freebsd.lublin.pl Przemyslaw Frasunek].
<pre>deb http://www.backports.org/debian woody nome_directory</pre>


Sqlsyslogd � un wrapper per syslogd scritto in C per FreeBSD, ma � comunque compatibile con qualsiasi piattaforma POSIX e ANSI-C compliant (chi scrive non ha mai avuto problemi nell' usarlo su piattaforma GNU/Linux, in particolare Debian).
=Installazione=
A questo punto sono sufficienti i classici:
<pre># apt-get update
# apt-get upgrade</pre>
per poter sfruttare la nuova serie di kernels.


Andiamo con ordine:
{{box|Nota Bene:|In alternativa ai kernels debianizzati disponibili su Backports.org, è anche possibile utilizzare i sorgenti ufficiali 'vanilla', a patto di aver seguito il punto "'''Preparare il sistema'''"}}


1. procuriamoci il sorgente all' indirizzo: [http://www.frasunek.com/sources/security/sqlsyslogd/sqlsyslogd.c sqlsyslogd.c]. Procuriamoci anche il [http://www.frasunek.com/sources/security/sqlsyslogd/Makefile MakeFile] e lo [http://www.frasunek.com/sources/security/sqlsyslogd/sqlsyslogd.sql script] che useremo per creare il nostro database:sqlsyslogd.sql
=Conclusioni=
Solo una piccola precisazione per finire: alcuni programmi/demoni/tools installati sul sistema potrebbero mostrare anomalie, una volta installato un kernel della serie 2.6.x: questo perchè fanno ricorso a funzioni non più disponibili o disponibili sotto nomi diversi rispetto ai kernels 2.4.x. Chi scrive ha ad esempio notato questo comportamento nei pacchetti "snmp" e "snmpd".<br>
In questa situazione si deve disinstallare il pacchetto "ribelle" e provveredere ad installarne la versione aggiornata sfruttando i backports (se disponibili), i sorgenti aggiornati o un repository debian alternativo.


2. una volta ottenuto il sorgente del file compiliamolo digitando semplicemente:
Happy hacking!


<pre>
$ make
</pre>
nella directory in cui abbiamo scaricato i nostri files.
3. ora copiamo l' eseguibile creato in /usr/local/sbin (ad esempio):
<pre>
$ su
Password:
# cp sqlsyslogd /usr/local/sbin/
</pre>
4. creiamo il database con il comando:
<pre>
$ mysql -u root -p < sqlsyslogd.sql
</pre>
questo comando crea il database sqlsyslogd, che contiene l' unica tabella logs.
Fermiamoci un momento a spiegare il funzionamento del wrapper: sqlsyslogd un programma C che "intercetta" le chiamate di syslogd e le redirige verso una pipe. Dato che il syslogger syslogd non pu puntare direttamente ad un altro programma (come invece pu fare il suo cugino di FreeBSD), ma soltanto ad una named pipe, abbiamo bisogno di un ulteriore passaggio:
5. Scarichiamo questo script perl e rinominiamolo ad esempio in "sqlsyslogd.wrapper".
Questo script crea per noi un FIFO socket. Syslogd mander i suoi messaggi al socket, e il wrapper li inoltrer a sqlsyslogd.
6. creaimo il file /usr/local/etc/sqlsyslogd.conf e come unica riga, digitiamo la password necessaria a poter scrivere nel nostro database. Dato che sqlsyslogd gira con le credenziali dell' utente che lo lancia e che - presumibilmente - vorremo avviarlo al boot della nostra macchina, potremo creare un utente apposito o pi semplicemente usare le creadenziali dell' utente "root". In questo caso in sqlsyslogd.conf inseriremo la password di root (occhio ai permessi su questo file!).
Lo script perl permette di specificare sia il server che ospita il database, sia l' utente con con collegarsi.
Il mio suggerimento, rivolto a ovvie questioni di sicurezza, consiste nel creare un apposito utente con cui far girare il wrapper e con cui accedere al database!!
7. Siamo a un passo dalla conclusione:
Editiamo il file sqlsyslogd.wrapper e adattiamolo alla nostra configurazione e alle nostre esigenze.
8. editiamo /etc/syslogd.conf e scriviamo una riga del tipo:
<pre>
*.* |/path/to/sqlsyslogd.wrapper
</pre>
Possiamo specificare tutte le facilities che vogliamo e loggare soltano quello che ci interessa. La direttiva dell' esempio regirige tutto quello che viene loggato.
9. Assicuriamoci che sqlsyslogd e sqlsyslogd.wrapper vengano lanciati ad ogni riavvio della macchina, aggiungendoli ad esempio ad uno script di avvio.
10. Finalmente possiamo riavviare syslogd e cominciare a importare in tempo reale i nostri logs in MySQL!!
<pre>
# killall -HUP syslogd
</pre>
o anche
<pre>
# /etc/init.d/sysklogd reload
</pre>
----
Autore: [[User:Keltik|Keltik]]
Autore: [[User:Keltik|Keltik]]
806

contributi

Menu di navigazione