giovedì 21 aprile 2011

Export e Import reservation dhcp su Win2008

Gli scope dei dhcp in windows2008 non possono essere modificati una volta creati, la subnet mask non può essere cambiata, quindi quando bisogna espandere una classe di una lan, bisogna ricreare un nuovo scope.
Il problema è che cancellando lo scopo esistente, vanno perse anche le reservation e le option, quindi bisogna esportarle in questo modo:

netsh dhcp server scope dump>dump.txt

mentre per importarle:

netsh exec dump.txt

martedì 22 febbraio 2011

Architettura database Mysql

L’articolo descrive le caratteristiche tecniche di un Database creato in ambiente MySQL, la corrispondenza tra Database e Directory sul filesystem, i tipi di tabella supportati da MySQL e l’uso della memoria.

Caratteristiche generali

Tutti i database creati in ambiente MySQL corrispondono fisicamente a delle sottodirectory della directory definita come datadir nel file di configurazione /etc/mysql/my.cnf

All’interno del file my.cnf troviamo qualcosa di simile a:

user = mysql pid-file = /var/run/mysqld/mysqld.pid socket = /var/run/mysqld/mysqld.sock port = 3306 basedir = /usr datadir = /var/lib/mysql tmpdir = /tmp language = /usr/share/mysql/english

In questo caso la directory definita come datadir è la /var/lib/mysql. Questo significa che se si crea un nuovo database db_name, automaticamente verrà creata la seguente directory sul filesystem: /var/lib/mysql/db_name.

Un database può essere vuoto, in tal caso la directory corrispondente sul filesystem sarà vuota, oppure può contenere alcune tabelle, in questo caso la directory conterrà alcuni file. Un database non può contenere un altro database. A ogni tabella del database corrisponde un file all’interno della directory corrispondente al database sul filesystem. Il file della tabella, conterrà la definizione della struttura della tabella stessa. A seconda del tipo di tabella creata, nella directory del database possiamo trovare diversi tipi di file. Per tutti i tipi di tabelle create in un database MySQL, viene generato un file che ha lo stesso nome della tabella ed estensione .frm, tale file contiene al suo interno la definizione della struttura della tabella. Quando viene creato un nuovo database in MySQL, all’interno della diretory del database viene generato il file db.opt dove vengono registrate le caratteristiche del database.

Il contenuto del file db.opt potrebbe essere simile a:

default-character-set=latin1
default-collation=latin1_swedish_ci

Tipi di tabelle

MySQL supporta i seguenti tipi di tabelle:

Tabelle tipo MyISAM
Tabelle tipo InnoDB
Tabelle tipo MERGE
Tabelle tipo HEAP
Tabelle di tipo MyISAM

Le tabelle di tipo MyISAM hanno le seguenti caratteristiche:

Ogni tabella è rappresentata sul disco da un file che ne descrive il formato con estensione .frm, da un file che contiene i dati con estensione .MYD e da un file contenente gli indici con estensione .MYI. Tutti i file sono memorizzati all’interno della directory del database;
La clausola AUTO_INCREMENT è più flessibile di tutti gli altri tipi di tabelle;
Possono essere utilizzate per creare tabelle di tipo MERGE;
Possono essere convertite in tabelle compresse, a sola lettura, molto veloci;
Supportano il tipo di ricerca FULLTEXT;
Supportano il lock a livello di tabella. In lettura l’accesso è consentito simultaneamente a più query, mentre in scrittura viene utilizzato un lock esclusivo a livello di tabella;
Tabelle di tipo InnoDB

Le tabelle di tipo InnoDB hanno le seguenti caratteristiche:

Ogni tabella è rappresentata sul disco da un file che ne descrive il formato con estensione .frm, mentre i dati e gli indici sono scritti all’interno di uno o più file utilizzati come tablespace comune a tutte le tabelle di questo tipo;
Questo tipo di tabella supporta le transazioni, operazioni definite all’interno degli statement BEGIN, COMMIT, ROLLBACK...
InnoDB fornisce un sistema per il recupero automatico dei dati in caso di crash server MySQL o del pc sul quale il server è in esecuzione;
InnoDB supporta le relazioni (foreign keys) e i vincoli di integrità referenziali;
La gestione della concorrenza per le query è gestita tramite multi- versioning e il lock a livello di riga;
Tabelle di tipo MERGE

Le tabelle di tipo MERGE hanno le seguenti caratteristiche:

Una tabella MERGE è il risultato dell’insieme di più tabelle MyISAM. Ogni tabella MERGE è rappresentata da due file, uno con estenzione .frm che contiene la definizione della struttura della tabella e uno con estensione .MRG contenente la lista dei file MyISAM che costituiscono le tabelle unite nella MERGE;
L’interrogazione di una tabella MERGE comporta l’interrogazione di tutte le tabelle che la compongono;
Una tabella MERGE può essere utile quando si ha la necessità di memorizzare grandi quantità di dati essendo un’unità logica che supera di gran lunga la capacità massima di memorizzazione dati di una tabella MyISAM;
Tabelle di tipo HEAP

Le tabelle di tipo HEAP hanno le seguenti caratteristiche:

Ogni tabella è rappresentata sul disco da un file che ne descrive il formato con estensione .frm, mentre i dati e gli indici sono scritti in memoria. Ne consegue che questo tipo di tabella è molto veloce, per contro i dati memorizzati in queste tabelle non sopravvivono al riavvio del server;
Le tabelle HEAP utilizzano una gran quantità di memoria, quindi non vengono usate per memorizzare grandi moli di dati;
MySQL e la memoria

Il server MySQL è multithread, tecnicamente un thread è un flusso di controllo, ovvero un percorso di esecuzione attraverso il codice indipendente all’interno di un processo. Per ogni client connesso, il server di MySQL crea un thread per gestire quella connessione. Il server mantiene una cache dei gestori dei thread; quando avviene la disconnessione da parte di un client, il thread che gestiva quella connessione viene messo in cache se la cache non è piena, allo stesso modo quando un client si connette al server, gli viene assegnato un thread presente in cache. Questa gestione dei thread in cache aumenta notevolmente le prestazioni in termini di tempi di connessione e disconnessione al database.

Il server MySQL, utilizza una serie di buffer per mantenere in memoria le informazioni necessarie a ridurre al minimo il numero degli accessi al disco. Tra i buffer utilizzati dal server di MySQL troviamo:

le grant tables (tabelle di sistema) dove sono memorizzati i dati degli utenti del database (info, permessi, etc.). In MySQL l’accesso ai dati viene controllato per ogni query inviata dai client, bufferizzando le grant tables i tempi di risposta del server diminuiscono notevolmente;
il key buffer che tiene in memoria i blocchi degli indici delle tabelle;
la table cache che tiene in memoria i descrittori delle tabelle aperte;
la query cache che tiene in memoria il piano di esecuzione delle query eseguite ripetutamente;
la host cache che tiene in memoria la coppia nome_host / indirizzo_ip ottenuta mediante interrogazione del server DNS

mercoledì 19 gennaio 2011

Montare cartella windows su Ubuntu/debian con Samba

Se non lo avete fatto in precedenza, installate il pacchetto smbfs:

sudo apt-get install smbfs

Create in /mnt una cartella con il nome del pc o della condivisione alla quale connettersi. Nell’esempio creeremo una cartella di nome punto_di_mount:

sudo mkdir /mnt/punto_di_mount

Si presume che si abbiano delle valide credenziali di accesso al sistema Windows.

Adesso montiamo una ipotetica cartella condivisa di Windows chiamata cartella_condivisa:

sudo mount -t smbfs -o username=username_valida //nome_pc_win/nome_condivisione /mnt/punto_di_mount


In ambiente di rete Windows, avendo crededenziali appartenenti al gruppo Administrator, ci si può connettere direttamente alla “root” di un determinato hard disk pur non essendo formalmente stato condiviso come “cartella condivisa” semplicemente aggiungendo il simbolo $ accanto alla lettera d’unita.

Stessa tipologia di connessione vale per il comando mount.

Nell’esempio seguente montiamo nella solita cartella tutto il disco C del pc windows senza che sia stata ufficialmente condiviso il disco:

sudo mount -t smbfs -o username=username_valida //nome_pc_win/c$ /mnt/punto_di_mount

In questi casi, senza esplicita condivisione e avendo credenziali del gruppo Administrator, possiamo montare solo la “root” del disco. File e directory saranno però liberamente sfogliabili.

Una piccola nota sui parametri del comando mount:

Il parametro -t smbfs specifica che stiamo montando un filesystem di tipo smbfs

Il parametro -o indica che ciò che segue è un opzione. Nel nostro caso l’opzione è il parametro username


Montare automaticamente una cartella condivisa
Per fare in modo che la nostra Debian monti automaticamente all'avvio la risorsa condivisa Windows, dobbiamo modificare il file /etc/fstab, il file che contiene tutte le informazioni sui filesystem montati:

# nano /etc/fstab
Alla fine del file aggiungiamo la riga:

//windowsserver/cartella /mnt/windowsserver smbfs username=ferdy,password=MiaPassword 0 0

martedì 21 dicembre 2010

Spam Control su Webmin permettere ip a mandare mail

Per consentire un ip ad usare il nostro SMTP, bisogna aggiungere l'ip del pool di nat allo spam control rule su Webmin:

description: nome da assegnare
mail source: network + IP
match against: Connection information
Action: Allow relayng

venerdì 10 dicembre 2010

Installare Apache2 su Debian Lenny

n questo articolo effettueremo un’installazione passo-passo del web server apache2, integreremo il php come modulo ed infine installeremo proftpd per poter aggiornare il nostro sito via ftp.

-Installazione di apache2 e php

Ecco i primi comandi da eseguire

apt-get update

apt-get install apache2-mpm-prefork libapache2-mod-php5 php-pear php5-imagick php5-curl php5-gd php5-imap php5-mcrypt php5-mysql php5-xmlrpc php5-xsl

Eseguendo “ps ax” vedrete gia’ apache in esecuzione:

6163 ? Ss 0:00 /usr/sbin/apache2 -k start
9227 ? S 0:00 /usr/sbin/apache2 -k start
9228 ? S 0:00 /usr/sbin/apache2 -k start
9229 ? S 0:00 /usr/sbin/apache2 -k start
9230 ? S 0:00 /usr/sbin/apache2 -k start
9231 ? S 0:00 /usr/sbin/apache2 -k start

La configurazione di default crea un sito con la document root in

/var/www/

inserire in /etc/apache2/apache2.conf questo prima della riga “# Include the virtual host configurations:” (verso la fine del file)

AddType application/x-httpd-php .php

e riavviate il servizio

/etc/init.d/apache2 restart



Se dopo il riavvio appare questo messaggio di errore:

* Restarting web server apache2 apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1 for ServerName
... waiting apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1 for ServerName

To fix that problem, you need to edit the httpd.conf file. Open the terminal and type,

sudo gedit /etc/apache2/httpd.conf
By default httpd.conf file will be blank. Now, simply add the following line to the file.

ServerName localhost
Save the file and exit from gEdit.

Finally restart the server.

sudo /etc/init.d/apache2 restart


Se dobbiamo ospitare un solo dominio, allora il lavoro e’ quasi terminato.

Pubblicando questo file

/var/www/info.php

con questo contenuto



Avremo modo (accedendo con un browser web all’indirizzo www.tuosito.it/info.php) di visualizzare la configurazione del php installato.
Tutte le modifiche al php dovranno essere effettuate al file /etc/php5/apache2/php.ini e dovrete riavviare il server web (/etc/init.d/apache2 restart)


Virtualhost (più siti sullo stesso host)

Se invece desiderate ospitare piu’ di un sito allora dovrete create dei virtual host. Si possono creare di due tipi, ip based (quando ad ogni sito e’ riservato un proprio indirizzo ip) oppure name based (se sullo stesso indirizzo ip sono ospitati piu’ siti). In questo articolo vediamo come installare sullo stesso indirizzo ip piu’ di un sito. Cancelliamo la configurazione del sito di default:


rm -f /etc/apache2/sites-available/*
rm -f /etc/apache2/sites-enabled/*

creiamo le cartelle che dovranno contenere i dati del sito sito (dati web e file di log)

mkdir -p /var/www/virtual_hosts/www.tuosito.it/htdocs
mkdir -p /var/www/virtual_hosts/www.tuosito.it/logs

Generiamo un file index con un messaggio di benvenuto

echo “Il mio primo sito” > /var/www/virtual_hosts/www.tuosito.it/htdocs/index.html

accediamo nella cartella /etc/apache2/sites-available/ (qui sono contenuti i siti ospitati, anche quelli non abilitati)

cd /etc/apache2/sites-available/

creiamo il file associato al sito. chiamiamolo per esempio www.tuosito.it e scriviamo questo al suo interno:



ServerName www.tuosito.it
ServerAdmin luca@tuosito.it

DocumentRoot /var/www/virtual_hosts/www.tuosito.it/htdocs

ErrorLog /var/www/virtual_hosts/www.tuosito.it/logs/error.log

LogLevel crit

CustomLog /var/www/virtual_hosts/www.tuosito.it/logs/access.log combined
ServerSignature On


N.B. cambiare il nome del virtualhost e correggere il percorso di riferitmento dei log e della document root adattandola al vostro sito.

Adesso abilitiamolo. I siti abilitati sono quelli presenti nella cartella /etc/apache2/sites-enabled/. Dato che abbiamo gia’ creato la nostra configurazione, per abilitare il sito bastera’ creare un link simbolito da sites-enabled verso sites-available. Si fa in questo modo:


cd /etc/apache2/sites-enabled/
ln -s ../sites-available/www.tuosito.it

Riavviare apache

/etc/init.d/apache2 restart

Although I'm listed as a best-preference MX or a for that host

Another one that I don't have to fix often so I'll likely forget it.

Qmail error "Although I'm listed as a best-preference MX or a for that host, it isn't in my controls/locals file, so I don't treat it as local. (#5.4.6)"

It shows up in the log concatenated:

failure: Sorry._Although_I'm_listed_as_a_best-preference_MX_or_A_for_that_host,/it_isn't_in_my_cont
rol/locals_file,_so_I_don't_treat_it_as_local._(#5.4.6)/

Anyway, I fixed it, hopefully correctly, by placing the hostname in the /var/qmail/control/locals file and the /var/qmail/control/rcpthosts file and restarting qmail.

Restart qmail /etc/init.d/qmail restart

giovedì 18 novembre 2010

Install Suhosin debian Lenny

I am quite surprised about it but not many people know Suhosin extension, particularly shared webhosts and even administrators of dedicated web servers. Suhosin is a well-known PHP extension made by Stefan Esser, PHP security researcher.

With any PHP software, you cannot protect yourself from unexperienced programmers, creating errors in applications that lead to most obvious security issues (unsecure include() on user input, unprotected mail forms, etc.).

We have been running Suhosin on all our servers with a great success and so far we didn't find any problems with Drupal and any other PHP software.

How does Suhosin work and what does it protects against? You can either install it as a PHP module or as a PHP patch and recompile yourself. The huge advantage of a standard module is that you don't have to recompile PHP itself and you might not loose any possible vendor support. With the patch, you get a bit more protection but you need to recompile PHP everytime there is a new PHP version (And without proper server administration, I bet you will forget and make things even worse).

Therefore I usually recommend installing Suhosin module as it's also in standard Debian/Ubuntu:

sudo apt-get install php5-suhosin
For Red Hat/CentOS, there are quite a few howtos on installing Suhosin (second option).

What does Suhosin protect against?

■The only stable and real PHP remote file include protection available - including php://input, etc. (very important)
■Protects against HTTP Response Splitting Vulnerabilities
■Protects against scripts manipulating the memory_limit
■Adds protection against newline attacks to mail() (very important)
■Filters ASCIIZ characters from user input
■Ignores GET, POST, COOKIE variables with the following names: GLOBALS, _COOKIE, _ENV, _FILES, _GET, _POST, _REQUEST, _SERVER, _SESSION, HTTP_COOKIE_VARS, HTTP_ENV_VARS, HTTP_GET_VARS, HTTP_POST_VARS, HTTP_POST_FILES, HTTP_RAW_POST_DATA, HTTP_SERVER_VARS, HTTP_SESSION_VARS
■Supports verification of uploaded files through an external script (want automatic antivirus checking of EVERY uploaded file? Done!)
■Allows disabling the preg_replace() /e modifier
■Allows disabling eval() and blacklist/whitelist of eval functions!
■And more and lot more and a lot much more.
Did I tell you that I consider shared webhosts running PHP without Suhosin as irresponsible?

Configuration
What about configuring Suhosin? The configuration file is either in /etc/php5/conf.d/suhosin.ini or integrated in php.ini, based on your Linux distribution. This is a config we use, together with explanation:

# Enable Suhosin.
extension=suhosin.so

# How many directory traversals are permitted? "../dir" is OK,
# "../../../../../dir" is not (5 times > 4).
suhosin.executor.include.max_traversal=4

# Disable /e in preg_replace which is usually used insecurely. Feel free to
# turn on at dedicated servers and slap everybody who uses /e.
suhosin.executor.disable_emodifier=Off

# Protect mail forms against spammer attacks (Effectively disables any headers
# injected from user input. Very important.
suhosin.mail.protect=2

# Upper limit for memory. When safe_mode is disabled, users can use ini_set to
# change their memory limit, with Suhosin up to this amount.
suhosin.memory_limit=256M

# What to do when Suhosin filters out something. 402 = 402 HTTP response.
# See Suhosin conf.
suhosin.filter.action=402

# Maximum limits for variables coming from COOKIE, POST and GET.
# These are reasonable values (based on experience).
suhosin.request.max_array_depth=4096
suhosin.request.max_array_index_length=2048
suhosin.request.max_name_length=2048
suhosin.request.max_value_length=650000
suhosin.request.max_vars=4096
suhosin.post.max_array_depth=8048
suhosin.post.max_array_index_length=1024
suhosin.post.max_name_length=2048
suhosin.post.max_totalname_length=8048
suhosin.post.max_vars=4096

# Maximum file uploads in a script.
suhosin.upload.max_uploads=100

# Newest thing we learned. Disable any include,curl,fpassthru,base64_encode,mail
# and others in eval(). This is Security by obscurity, however it works
# very well for shared hosts when an attacker is able to upload a bad
# script. Most of the current scripts use obfuscated code decoded from
# base64 and then eval()'ed. This stops them, until they learn something new.
suhosin.executor.eval.blacklist=include,include_once,require,require_once,
curl_init,fpassthru,file,base64_encode,base64_decode,mail,exec,system,proc_open,
leak,syslog,pfsockopen,shell_exec,ini_restore,symlink,stream_socket_server,
proc_nice,popen,proc_get_status,dl, pcntl_exec, pcntl_fork, pcntl_signal,
pcntl_waitpid, pcntl_wexitstatus, pcntl_wifexited, pcntl_wifsignaled,
pcntl_wifstopped, pcntl_wstopsig, pcntl_wtermsig, socket_accept,
socket_bind, socket_connect, socket_create, socket_create_listen,
socket_create_pair,link,register_shutdown_function,register_tick_function

# Feel free to turn on, disables eval() at all.
suhosin.executor.disable_eval=Off

# We don't use but feel free. Function whitelist!
# Anything that's not in this list will not be permitted!
suhosin.executor.func.whitelist=

# This is equivalent to disable_functions in php.ini.
suhosin.executor.func.blacklist=

# Log all actions into Syslog.
suhosin.log.syslog = S_ALL & ~S_SQL

# Check all file uploads using some script.
# The script must write "1" as a first line of standard output
# to allow the upload, anything else to disallow.
suhosin.upload.verification_script=/opt/check.sh
Based on my experience, Suhosin works very well, even together with PHP Xcache and Memcache.

See Hardened PHP for more configuration directives.