Connettersi al database da remoto


Come ovviare al messaggio di errore: “psql: could not connect to server: Connection refused Is the server running on host host.domain.com and accepting TCP/IP connections on port 5432?”

Prima di tutto assicuriamoci che il server PostgreSQL remoto sia attivo

/etc/init.d/postgresql start

Verifichiamo il file /var/lib/pgsql/data/pg_hba.conf che nelle Ubuntu si trova invece sotto /etc/postgres* (il nome del percorso cambia a seconda della versione di PostgreSQL che state usando).

Ricordiamoci che questi file vanno modificati agendo con i privilegi di root. Per consentire l’accesso al database da parte di un client appartenente alla rete 192.168.100.0/24 occorre aggiungere una riga come segue

host all all 192.168.100.0 255.255.255.0 trust

In seguito occorre aggiornare il file postgresql.conf per attivare il socket TCP/IP

tcpip_socket = true

Riavviare PostgreSQL

/etc/init.d/postgresql restart

Controllare la configurazione usando il comando

psql -h indirizzo-server-postgresql -U nomeutente -d nomedatabasecuisivuoleaccedere

Ad esempio, ipotizzando che il vostro server abbia indirizzo IP 192.168.100.5 il comando sarebbe questopsql -h 192.168.1.5 -U peppino -d protocolli

Per rigirare una connessione ad un server PostgreSQL di appoggio per Zope/PAFlow tramite SSH, invece

ssh -p 12345 -L 54321:localhost:5432 root@serverscarso

Annunci

Migrare a PostgreSQL


Una migrazione da qualche altro database server a PostgreSQL, o addirittura da una versione precedente di PostgreSQL, può essere una procedura complicata, con molti particolari ai quali prestare attenzione.

Dovendo trasmettere la mia esperienza ho messo a punto una lista di controllo allo scopo di assicurarmi che si stiano valutando tutti gli aspetti della migrazione.

Inoltre, a luglio 2010 terminerà il ciclo di vita delle versioni 7.4 e 8.0 e a novembre dello stesso anno anche la 8.1. È importante, quindi iniziare a pensare ad un piano di migrazione, eventualmente appoggiandosi a chi possiede competenze specifiche su PostgreSQL che affianchi il personale interno.

Questo elenco include anche le domande da sottoporre al cliente e apprezzerò volentieri considerazioni proprie aggiuntive o suggerimenti, poiché non sempre arrivano dai colleghi di cui sopra, a conferma che “non la sanno poi così lunga” come vorrebbero far credere a gli paga lo stipendio…

Partiamo dalle questioni tecniche.

Quanti server di database ci sono?

Per ciascuno di essi occorre raccogliere le specifiche del sistema operativo, l’architettura della CPU, la memoria RAM, tipologia e geometria dei dischi, eccetera.

Particolare attenzione va posta alla tipologia di memoria di massa usata per ospitare i database esistenti, e quale si pianifica per i futuri database: direct-attached storage (SAS, SATA, eccetera), SAN (attenzione alle peculiarità del fornitore), oppure qualcosa che sia altro? Si userà qualche strumento di configuration management come Puppet o Chef?

Application server e altri tipi di accesso remoto

Quanti Application Server esistono già? Per ciascuno, qual’è la configurazione di sistema (al solito, sistema operativo, tipo di CPU e dimensione della RAM, geometria dischi, eccetera)? Configurazione della rete (si sta adottando SSL e/o VPN)? Si sta usando ODBC?

Sono coinvolti diversi centri elaborazione dati? Ci sono firewall in ingresso e/o in uscita? Anche in questo caso è importante chiedersi se si intende utilizzare Puppet, Chef o altri programmi simili.

Middleware

Viene utilizzato qualche connection pooling o sistema per il bilanciamento del carico? Quale altro sistema intermedio interagisce con il server di database?

Descrivere la base dati

Esistono dei rapporti, ad esempio, su quali dati siano acceduti meno frequentemente e cosa invece più spesso? Esistono delle statistiche sul traffico di rete e sul numero di query?

Dimensione

Quanti sono i dati da gestire? Che tipo di transazioni sono eseguite? Quante tabelle ci sono e quanto sono grandi? Quanti utenti si connettono al data base?

Copie di sicurezza

Qual’è (se esiste) la politica adottata per garantire le copie di sicurezza del database? In che modo, eventualmente, deve essere modificata dopo il passaggio a PostgreSQL?

Replicazione e bilanciamento del carico

Che tipo di sistema di ridondanza c’è attualmente oppure occorrerebbe? È usato qualche tipo di replica master-slave?

Monitoraggio

Qual’è il sistema di monitoraggio esistente? Si fa ricorso ad un team di sistemisti interni? Possono essere facilmente aggiornati al nuovo tipo di database?

Interfacce

In che lingua sono i driver per la connessione al database corrente? Ci sarà un driver compatibile PostgreSQL disponibile nella lingua scelta?

Infine un paio di considerazioni riguardanti l’aspetto gestionale.

Pianificazione

È stato stilato un calendario per la migrazione? Quanto tempo di inattività del database ci si può permettere?

Personale

Esiste almeno una risorsa interna dedicata alla gestione della base dati attuale? Questa risorsa è in grado di gestire il nuovo database server (ha esperienza PostgreSQL)?

Essere in grado di rispondere a tutte queste domande è fondamentale per la formulazione di un piano di migrazione di successo.

http://rcm.amazon.com/e/cm?lt1=_blank&bc1=FFFFFF&IS2=1&npa=1&bg1=FFFFFF&fc1=000000&lc1=0000FF&t=liin03-20&o=1&p=8&l=as1&m=amazon&f=ifr&asins=1590599780

SqlNinja


Quando si parla di “penetration test” e “vulnerability assessment” spesso si ha l’impressione che tali attività siano semplici perché basate sull’utilizzo di strumenti automatizzati. Il mercato italiano è sempre di più infestato da “squali pavone” e “remore” che causano solo confusione nei clienti sull’esatto significato di termini quali Vulnerability Assessment, Penetration Test ed Ethical Hacking, e sulle differenze che li contraddistinguono.

Parimenti viene prestata scarsa attenzione al fatto che l’efficacia di queste tecniche è proporzionale alle competenze delle persone che le usano. Non si tratta di prendere a noleggio a 100 euro al giorno tutto incluso il “ragazzino appassionato di Linux” e fargli lanciare un paio di scan automatici.

Standard come l’OSSTMM sono in questo senso molto utili per definire una metodologia comune e condivisa, con una terminologia chiara, e per far sì che chi richiede questo tipo di attività possa verificare che dall’altra parte ci sia qualcuno che sappia fornire un elevato livello qualitativo.

Uno di questi strumenti è SqlNinja, un programma (scritto da Alberto Revelli) usato per effettuare “sql injection” su Microsoft SQL Server. Il sito ufficiale del progetto è sqlninja.sourceforge.net/ mentre una dimostrazione pratica del suo funzionamento è visibile sul sito sqlninja.sourceforge.net/sqlninjademo.html oltre che sul blog di Scott Herbert

SqlNinja è un utile strumento per testare la sicurezza di un Microsoft SQL Server. È un piccolo programma in Perl che funziona quindi su tutte le distribuzioni Unix, Linux incluso, ovviamente. Serve principalmente per sferrare attacchi sfruttando la vulnerabilità chiama “SQL Injection”.

SqlNinja permette di ottenere una shell sul database “obiettivo”. Il programma è in grado si di effettuare una fingerprint del server SQL, un attacco forza bruta della password dell’amministratore di sistema, un port scanning per individuare porte aperte e anche un tunnel tramite la porta DNS, quando tutte le porte TCP/UDP sono chiuse ma il server risolve i nomi host esterni.

Per installare SqlNinja su Ubuntu ecco come fare:

sudo apt-get install libnet-dns-perl libnet-pcap-perl libio-socket-ssl-perl libnet-rawip-perl

perl -MCPAN -e "install NetPacket"

Installazione manuale di più istanze di MySQL


Installare MySQL su Linux è abbastanza semplice

apt-get install mysql-server

Ma se abbiamo l’esigenza di installare più di un’istanza di MySQL? Posto che i binari di MySQL siano in /usr/localprocediamo creando dei link simbolici

ln -s /usr/local/mysql-path /usr/local/mysql-uno

ln -s /usr/local/mysql-path /usr/local/mysql-due

Meglio non collocare my.cnf in /etc mettendolo invece in ciascuna directory

touch /usr/local/mysql-uno/my.cnf

touch /usr/local/mysql-due/my.cnf

Per ciascun file di configurazione impostiamo una diversa porta

[mysql]
port=9950

[mysqld]

port=9950

ad esempio per “mysql-uno”.
Quindi distinguiamo i socket


[mysql]

port=9950

socket=/tmp/mysql-uno.sock

[mysqld]

port=9950

socket=/tmp/mysql-uno.sock

distinguiamo anche i “data paths”


[mysql]

port=9950

socket=/tmp/mysql-uno.sock

[mysqld]

port=9950

socket=/tmp/mysql-uno.sock

datadir=/san/mysql-uno/

E, infine, creaiamo i demoni personalizzati in /etc/init.d/

cp /usr/local/mysql-uno/support_files/mysql.server

/etc/init.d/mysqld-uno

cp /usr/local/mysql-due/support_files/mysql.server

/etc/init.d/mysqld-due

ln -s /usr/local/mysql-uno/bin/mysql /usr/bin/mysql-uno

ln -s /usr/local/mysql-due/bin/mysql /usr/bin/mysql-due

chkconfig -add mysqld-uno

Installare Oracle XE su Ubuntu


Installiamo Apache

sudo apt-get install apache2

e successivamente il supporto a PHP5

sudo apt-get install php5 libapache2-mod-php5

sudo apt-get install build-essential php5-dev php-pear

Apriamo il file /etc/apt/source.list e alla fine aggiungiamo

## Oracle

deb http://oss.oracle.com/debian unstable main non-free

aggiungiamo la chiave per il repository appena inserito eseguendo

wget http://oss.oracle.com/el4/RPM-GPG-KEY-oracle -O- | sudo apt-key add -

Aggiorniamo la lista del software disponibile dai repository con

sudo apt-get update && sudo apt-get upgrade

Installiamo Oracle XE con

sudo apt-get install oracle-xe oracle-xe-client

Lanciare XE

sudo /etc/init.d/oracle-xe configure

Impostiamo le variabile d’ambiente per l’utente Oracle con

sudo su - oracle

Editiamo il file .bash_profile ed aggiungiamo le seguenti righe

export ORACLE_HOME=/usr/lib/oracle/xe/app/oracle/product/10.2.0/server

export PATH=$ORACLE_HOME/bin:$PATH

export ORACLE_SID=XE

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$ORACLE_HOME/lib

Per avviare l’interfaccia di amministrazione di Oracle XE (web)

sudo su – oracle sqlplus / as sysdba

inseriamo la password e continuiamo

EXEC DBMS_XDB.SETLISTENERLOCALACCESS(FALSE);

quit;

logout

Richiamare da browser

http://%5Bip della macchina]:8080/apex

Per la configurazione di PHP5 per Oracle procedere come segue

cd /usr/src

sudo pecl download oci8

sudo tar xzvf oci8-1.3.4.tgz

cd oci8-1.3.4

sudo -s

export ORACLE_HOME=/usr/lib/oracle/xe/app/oracle/product/10.2.0/server

export PATH=$ORACLE_HOME/bin:$PATH

export ORACLE_SID=XE

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$ORACLE_HOME/lib

phpize

./configure –with-oci8=shared,$ORACLE_HOME

make

make install

logout

sudo -s

echo "extension=oci8.so" >> /etc/php5/apache2/php.ini

echo "extension=oci8.so" >> /etc/php5/cli/php.ini

logout

Impostiamo le variabili di ambiente modificando il file /etc/apache2/envvars

export ORACLE_HOME=/usr/lib/oracle/xe/app/oracle/product/10.2.0/server

export PATH=$ORACLE_HOME/bin:$PATH

export ORACLE_SID=XE

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$ORACLE_HOME/lib

Riavviare Apache e richiare l’indirizzo http://%5Bip della macchina]/phpinfo.php dovremmo vedere le informazioni relative ad Oracle.