05 Dic 13 As you can see, this site is reachable via IPv6!
If you are using IPv6 (like me) you can see that this blog is reachable via IPv6. Pretty cool!
14 Nov 13 LVM Hot backups with snapshot
As you may know, LVM make it possible to create live snapshots of running logical volumes.
Imagine a guest virtual machine that has its virtual disk backed on a LVM logical volume on the host system.
You may create a live hot backup of your virtual machine on the fly, while it is working.
To do this, I created a small script that makes a compressed backup of all the logical volumes on the /dev/vg0 volume group.
The script make use of the standard LVM utilities to have the snapshot, the pv utility to get a cool progress bar and pigz utility to compress (gzip) using all of your processors.
If everything went ok, when the script finishes you’ll find your LVM hot backups on the /backups directory, and the temporary lvm snapshots removed.
This is how I make hot backups of some of my virtual machines (lvm_hot_backup.sh):
#!/bin/bash
for lv in `lvdisplay /dev/vg0 | grep ‘LV Name’ | awk ‘{print $3}’`
do
LV_SIZE=”`lvs –units m –noheadings –nosuffix $lv | cut -d’ ‘ -f7 | cut -d. -f 1`” # LV size in MB
LV_UUID=”`lvdisplay $lv | grep ‘LV UUID’ | awk -F’LV UUID’ ‘{print $2}’ | sed ‘s/^ *//g’`”
LV_SNAPNAME=”SNAP_`basename $lv`”echo “LVM Logical Volume: $lv”
echo “Size: $LV_SIZE MB”
echo “UUID: $LV_UUID”
echo “Snapshot name: $LV_SNAPNAME”
echo “Removing old snapshot (if any)…”
lvremove -f “/dev/vg0/$LV_SNAPNAME”
echo “Creating snapshot…”
lvcreate -L+2G –snapshot -n”$LV_SNAPNAME” “$lv”
sleep 4
echo “Backing up snapshot…”
dd if=”/dev/vg0/$LV_SNAPNAME” bs=512k of=/dev/stdout | pv -pterbW -i 2 –buffer-size 512k –size “$LV_SIZE”m | /usr/bin/pigz -9 -b 256 > “/backups/$LV_SNAPNAME.lv.gz”
echo “Removing snapshot…”
lvremove -f “/dev/vg0/$LV_SNAPNAME”
echo “–”
done
03 Nov 13 SSH connection is slow? Did you try to disable DNS lookups?
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.
10 Ott 13 How to fix svn error: OPTIONS ‘https://1.2.3.4/svn/prj’: SSL handshake failed: SSL error: Key usage violation in certificate has been detected
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
05 Mar 13 How to get the client source port with apache as reverse proxy
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.
03 Mar 13 How to install php 5.2 on debian squeeze (6.0.x), the debian way
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!
31 Dic 12 Happy new year!
This is the end of this year. Fuck you 2012, and welcome to 2013!!
02 Dic 12 New NuvolaBase Dashboard
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
17 Set 12 SSH local and remote tunnels
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:
- A TCP client wants to connect to 192.168.1.2 on TCP port 18443
- You want to forward TCP traffic from 192.168.1.2:18443 to 11.22.33.44:18443
- You have a client host with IP address 11.22.33.41 that can reach 11.22.33.44
- You can establish a SSH connection from your client (11.22.33.41) to the remote server (192.168.1.2)
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:
- Substitute “root” with your SSH user on the remote SSH server
- Substitute “192.168.1.2” with your remote SSH server IP/host
- Substitute the first “18443” with the port your remote TCP clients need to connect
- Substitute “11.22.33.44” with your internal TCP server to forward traffic coming from the outside
- Substitute the second “18443” with the TCP port listening on the internal host
You can even do the reverse, letting local traffic flowing to an external host, passing through a SSH connection.
Let me do another example:
- You have a client host with IP address 11.22.33.41
- A TCP client wants to connect to 11.22.33.41 (your IP) on TCP port 18443
- You want to forward local TCP traffic from 11.22.33.41:18443 to 192.168.1.3:18443
- You can establish a SSH connection from your client (11.22.33.41) to a remote server (192.168.1.2) that can reach 192.168.1.3
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:
- Substitute “root” with your SSH user on the remote SSH server
- Substitute “192.168.1.2 with your remote SSH server IP/host
- Substitute the first “18443” with the port your local TCP clients need to connect
- Substitute “192.168.1.3” with the remote TCP server you want to reach from your local TCP clients
- Substitute the second “18443” with the TCP port of the remote server
Follow me!
Stack Overflow
IPv6 Certified (he.net)