If your SSH connection is slow, it may depends on your SSH server that is executing reverse DNS lookups to try to identify your details.
Try setting the parameter below to your /etc/ssh/sshd_config and restart your ssh server daemon:
UseDNS no
It worked perfectly for me, it may work perfectly with you too.
If you encounter an error like this one on your SVN client:
svn: OPTIONS di ‘https://192.168.1.36/svn/myprj‘: SSL handshake failed: SSL error: Key usage violation in certificate has been detected. (https://192.168.1.36)
you can try to fix your problem linking your libneon-gnutls.so.27 library used by your svn client to /usr/lib/libneon.so.27.
Try with this one:
mv /usr/lib/libneon-gnutls.so.27 /usr/lib/libneon-gnutls.so.27.old
ln -s /usr/lib/libneon.so.27 /usr/lib/libneon-gnutls.so.27
Tested on Debian 6.0 and Ubuntu 11.10
Retrieving the client IP address from an application deployed in tomcat, jboss, bea weblogic o something else sitting behind a reverse proxy is a simple matter of getting the Proxy HTTP headers setted by apache, for example”X-Forwarded-Host”, “X-Forwarded-For”, etc.
Sometimes, in enterprise environments, you could be asked to find the solution that make the application able to get the client source port too. In some cases, the police could ask the client’s provider to show the real identity of the contract person using the HTTP service, and in natted environments it’s impossible for the provider to do this without the source port.
Well, if your reverse proxy is apache, the solution is simple. Just add those lines to your httpd.conf:
RewriteEngine on
RewriteRule .* – [E=REMOTE_PORT:%{REMOTE_PORT},NE]
RequestHeader set X-Forwarded-SourcePort %{REMOTE_PORT}e
This way apache will set the HTTP request Header called “X-Forwarded-SourcePort“. The application can now get the TCP client source port.
You may know that the PHP version coming with debian squeeze is 5.3. Since the 5.3 version of PHP breaks some compatibility with 5.2 you may find that an old PHP application is no longer working with the new version of PHP on squeeze.
The steps required to install PHP 5.2 on debian squeeze are very simple, you just need to setup APT to install the PHP packages coming with debian lenny.
The first thing to do is to add the lenny repository to the end of /etc/apt/sources.list:
deb http://archive.debian.org/debian lenny main contrib non-free
Then you need to make sure that your favourite PHP packages will be downloaded from lenny instead of squeeze. You can do this creating the file /etc/apt/preferences.d/lenny, with this stuff inside:
Explanation: choose Lenny as installation source if the package is not already installed and not available from Squeeze
Package: *
Pin: release n=lenny*
Pin-Priority: 100Explanation: choose Lenny as installation source for those packages
Package: libapache2-mod-php5 php5-common php5-curl php5-gd php5-mcrypt php5-mysql php5-cli php5-mhash php5-xsl php5-imap php5-xmlrpc php5-sqlite
Pin: release n=lenny*
Pin-Priority: 999
After that, remove any previously installed PHP 5.3 package, for example with the command
apt-get remove –purge php5\*
and then install the PHP 5.2 packages from lenny:
apt-get update
apt-get clean
apt-get install libapache2-mod-php5 php5-common php5-curl php5-gd php5-mcrypt php5-mysql php5-cli php5-mhash php5-xsl php5-imap php5-xmlrpc php5-sqlite
That procedure saved my life twice, I hope it will save yours too!
Tonight at 03.00 GTM the NuvolaBase team publicly released the new NuvolaBase Dashboard.
As you may know, with NuvolaBase you can handle your private database on the cloud.
The new dashboard aims to be simple, stable and powerful. You can login using your google, twitter, facebook, linkedin account.
In the next days the NuvolaBase guys will release many new cool features like a powerful REST API to handle your databases in the cloud from your application.
This is the official article on the NuvolaBase blog: http://nuvolabase.blogspot.it/2012/12/nuvolabase-dashboard-upgrade.html
Sometimes you may need to forward remote traffic to a local host through a SSH connection. In other words you can bind a given TCP port to a server running SSH and make remote clients connecting to it, letting the traffic to be redirected to a local server.
You may need to add the parameter GatewayPorts clientspecified to /etc/ssh/sshd_config on the SSH server and restart sshd. This is to enable ssh clients to bind remote connections on a given ip, otherwise you can only connect to the remote port just from 127.0.0.1.
At this point, let me do an example:
If you have the given situation, you can execute the following command to bind the TCP port 18443 on the remote server:
ssh -l root 192.168.1.2 -R:18443:11.22.33.44:18443
Now, you can apply your changes:
You can even do the reverse, letting local traffic flowing to an external host, passing through a SSH connection.
Let me do another example:
If you have the given situation, you can execute the following command to bind the TCP port 18443 of your computer to the remote server:
ssh -g -l root 192.168.1.2 -L18443:192.168.1.3:18443
Now, apply your changes:
This is a very quick guide to get your feet wet with PHP 5.3 + PHP-FPM fastcgi support and apache webserver.
The PHP-FPM is basically a fastcgi compliant pool of PHP processes spawned on the system, ready to quickly accept connections, for example via TCP. It’s generally used to greatly improove PHP scalability, security and performance.
Start by installing apache, no matter if it’s a binary installation or if it’s compiled from source code (I assume this step is already done).
Once you have a valid apache installation, you need to compile the mod_fastcgi module.
NOTE: don’t use mod_fcgid or any other fastcgi provider but mod_fastcgi: it’s proved to be stable and to work well with PHP-FPM.
To install mod_fastcgi you have to:
Now, compile PHP with the fpm support, or install a already compiled PHP binary package.
Here I’ll cover how to compile it from source.
Start by downloading the latest php 5.3 version from http://www.php.net/downloads.php
When you have done, untar the PHP source package and enter into the extracted php-5.3.x directory.
Now create a file called conf.sh and put this stuff inside it:
./configure \
–prefix=/usr/local/php53 \
–with-libdir=lib64 \
–enable-pcntl \
–enable-mbstring=shared \
–enable-mbregex \
–with-gd=shared \
–enable-bcmath=shared \
–with-xmlrpc=shared \
–with-mysql=shared,/usr \
–with-mysqli=shared,/usr/bin/mysql_config \
–enable-dom=shared \
–enable-soap=shared \
–with-xsl=shared,/usr \
–enable-xmlreader=shared –enable-xmlwriter=shared \
–with-pdo-mysql=shared,/usr \
–enable-json=shared \
–enable-zip=shared \
–with-readline \
–with-jpeg-dir=/usr \
–with-png-dir=/usr \
–with-pear \
–with-ldap=shared \
–enable-fpm \
–with-fpm-user=apache \
–with-fpm-group=apache
Your mileage may vary here, so please double check row by row if you need to modify something. The FPM part are the last 3 lines.
NOTE: you cannot compile PHP as FPM and SAPI at the same time.
Now, make the file executable with: chmod 755 conf.sh
and run the executable with: ./conf.sh
Wait that the configure script is done. If no errors are encountered you can proceed with make and make install as usual.
Remember to create the php.ini configuration file if you need it.
You should now end up with a fresh PHP installation into /usr/local/php53 (or any other path you given to the prefix configure attribute).
Ok, now it’s time to configure the php-fpm (change /usr/local/php53 with your path if it’s different):
cd /usr/local/php53/etc
cp php-fpm.conf.default php-fpm.conf
vi php-fpm.conf
You generally don’t need to modify anything here, but if you want you can touch something.
Now start the php-fpm process pool by running this command by the root user: /usr/local/php53/sbin/php-fpm
If anything gone ok you should have some process up and running, something like this:
25976 ? Ss 0:00 php-fpm: master process (/usr/local/php53/etc/php-fpm.conf)
4945 ? S 0:00 \_ php-fpm: pool www
4946 ? S 0:00 \_ php-fpm: pool www
4947 ? S 0:00 \_ php-fpm: pool www
If you didn’t modify the php-fpm.conf, the process pool listen for fastcgi requests to TCP 127.0.0.1:9000.
It’s time to configure a apache virtualhost with PHP support using this brand new fpm.
Edit the httpd.conf apache configuration file (or another included file where you store the virtualhost) and append this stuff (I assume that apache is installed into /opt/apache2):
<VirtualHost *:80>
ServerAdmin webmaster@dummy-host.example.com
DocumentRoot “/opt/apache2/htdocs”
ServerName “your_servername.com”
ErrorLog “logs/your_servername-error_log”
CustomLog “logs/your_servername-access_log” commonFastCgiExternalServer /opt/apache2/htdocs/php5.sock -host 127.0.0.1:9000
AddHandler php5-fcgi .php
Action php5-fcgi /tmp/php5.sock
Alias /tmp /opt/apache2/htdocs<Directory “/opt/apache2/htdocs”>
Options FollowSymLinks
AllowOverride All
Order deny,allow
Allow from all
</Directory>
</VirtualHost>
Any file whose name ends for “.php” into your document root should now be associated to the PHP fastcgi handler and the requests should be routed to the php-fpm process pool. Each php-fpm process is reused according to the php-fpm.conf configuration file.
Restart apache and enjoy (any comment are welcome).
As previously said, nuvolabase.com is a great service that permits you to have a distributed nosql document database in the cloud. This is very cool: think each time you would had the need of a database always available in the cloud that you would access via simple HTTP/Rest queries. The possibilities are endless.
Here is a very simple but powerful PHP curl agent to submit commands (queries) to nuvolabase via HTTP.
<?php
/*
* Author: Dino Ciuffetti <dino@tuxweb.it>
* Object: Execute a remote query to a distributed database on nuvolabase.com (free account) using HTTP (OrientDB REST API)
*//* user configurable parameters */
$nuvolabasedb = ‘db$free$youruser$yourdb’;
$command = ‘select from yourclass’;
$user = ‘admin’;
$password = ‘qwerty’;
$useragent = “NuvolaBase PHP REST agent/v0.8 (compatible; Mozilla 4.0; MSIE 5.5; http://www.nuvolabase.com/)”;
/* END of user configurable parameters */$nuvolabasehost = ‘studio.nuvolabase.com’;
$url = ‘http://’.$user.’:’.$password.’@’.’studio.nuvolabase.com/command/’.$nuvolabasedb.’/sql/’;$ch = curl_init();
// set user agent
curl_setopt($ch, CURLOPT_USERAGENT, $useragent);// return the result or false in case of errors
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);// set the target url
curl_setopt($ch, CURLOPT_URL, $url);// do basic login authentication
curl_setopt($ch, CURLOPT_HTTPAUTH, CURLAUTH_BASIC);// howmany parameter to post
curl_setopt($ch, CURLOPT_POST, 1);// the post data to send
curl_setopt($ch, CURLOPT_POSTFIELDS, $command);// execute curl,fetch the result and close curl connection
$res = curl_exec ($ch);
curl_close ($ch);// display result
if ($res !== FALSE);
print_r (json_decode($res));?>
Please use the attached file.
Ciao.
C’e’ un modulo molto carino non official per apache che permette di bloccare o comunque mitigare facilmente attacchi di tipo DDOS.
Si scarica il modulo mod_evasive dal sito http://www.zdziarski.com/blog/?page_id=442, si decomprime il tar.gz e si compila con la seguente stringa:
<directory_di_installazione_apache>/bin/apxs -i -c mod_evasive20.c
Ora bisogna inserire due cosette in httpd.conf e successivamente riavviare gli apache:
1) LoadModule evasive20_module modules/mod_evasive20.so
2) La sua configurazione
Per quanto riguarda la numero 2 bisogna fare una considerazione importante, ovvero che il tuning del presente modulo con parametri errati o maldimensionati puo’ provocare dei falsi positivi che creano gravi disservizi per un periodo anche prolungato di tempo.
La configurazione e’ simile a questa (effettuo già un pre tuning che comunque dovrete ricontrollare e confermare voi che conoscete il vostro sistema):
<IfModule mod_evasive20.c>
DOSHashTableSize 196613
DOSLogDir “/tmp”
DOSPageCount 20
DOSPageInterval 10
DOSSiteCount 350
DOSSiteInterval 5
DOSBlockingPeriod 10
</IfModule>
Di seguito una breve spiegazione dei parametri:
DOSHashTableSize: e’ la dimensione della tabella di lookup interna usata dal modulo. Su server carichi il numero non deve essere troppo basso. Non andrebbe messo un numero casuale ma un numero primo presente nella struct dei numeri primi dentro mod_evasive20.c.
DOSLogDir: e’ una directory dove evasive appoggia dei dati che vengono utilizzati internamente per motivi di locking tra i processi child di apache
DOSPageCount: e’ la soglia per il numero di richieste effettuate verso una stessa url da uno stesso IP entro un determinato intervallo di tempo specificato dalla direttiva DOSPageInterval. Se il numero di richieste verso una stessa pagina/oggetto/uri viene superato nell’intervallo di tempo specificato apache blocchera’ l’IP del client per un determinato numero di secondi specificati dalla variabile DOSBlockingPeriod. Consiglio vivamente di non impostare questo parametro troppo basso per evitare falsi positivi all’interno di ambienti nattati o dietro proxy server (ad esempio clienti fastweb, utenti all’interno di grosse organizzazioni che usano un proxy server, ecc.)
DOSPageInterval: e’ l’intervallo di tempo espresso in secondi che attiva la soglia relativa al parametro precedente (DOSPageCount)
DOSSiteCount: e’ la soglia per il numero di richieste complessive verso tutto il sito effettuate da uno stesso IP entro un determinato intervallo di tempo specificato dalla direttiva DOSSiteInterval. Se il numero complessivo di richieste verso apache viene superato nell’intervallo di tempo specificato, apache blocchera’ l’IP del client per un determinato numero di secondi specificati dalla variabile DOSBlockingPeriod. Anche qui consiglio vivamente di non impostare questo parametro troppo basso per evitare falsi positivi all’interno di ambienti nattati o dietro proxy server (ad esempio clienti fastweb, utenti all’interno di grosse organizzazioni che usano un proxy server, ecc.)
DOSSiteInterval: e’ l’intervallo di tempo espresso in secondi che attiva la soglia relativa al parametro precedente (DOSSiteCount)
DOSBlockingPeriod: e’ l’intervallo di tempo espresso in secondi durante i quali tutti i client finiti in blacklist avendo superato i limiti imposti dai parametri specificati sopra non potranno collegarsi ad apache e navigare sul sito ottenendo invece un codice di errore HTTP/403 (Forbidden). Se i clients bloccati continuano ad effettuare nuove richieste durante il periodo di blocco, ogni richiesta resetta il timer percui il conteggio ricomincia. Consiglio quindi VIVAMENTE di non impostare questo parametro troppo alto, in genere non vanno mai superati i 20 secondi. Il motivo principale e’ la mitigazione di eventuali disservizi causati da falsi positivi. Il discorso e’ inoltre valido perche’ durante un attacco DDOS il timer viene continuamente resettato e l’attacco viene comunque mitigato anche impostando il parametro ad un valore molto basso.
Riavviate apache e buon divertimento.
Dino Ciuffetti.