[mysql] Enable InnoDB support in MySQL (Unknown table engine ‘InnoDB’)

I converted MyISAM tables to InnoDB engine via PHPmyadmin.

The result was the warning Unknown table engine ‘InnoDB’ and my data were gone!

No problem:

service mysqld stop

rm -f /var/lib/mysql/ib_logfile*

service mysqld start

SSH Tunneling + SSH port forwarding + multiple hops ALL-IN-ONE (ITALIANO, ENGLISH)

*** ITALIANO *** (ENGLISH BELOW)

Se abbiamo la gestione di una macchina linux remota in LAN1, a cui accediamo via SSH, potremmo aver necessità di connetterci ad una rete LAN2 collegata ad essa es. in VPN. In sostanza quella macchina ci serve da proxy per l'accesso a LAN2 e la strada più semplice è settare il port forwarding via SSH, quindi otteniamo un tunnel criptato con SSL. I più maliziosi hanno già pensato di sfruttarla come proxy di navigazione anonima o come testa di ponte, ma le considerazioni sulla sicurezza sono oltre lo scopo di questo post. A noi serve avere i controllo di entrambe le macchine raggiunte su LAN1 e LAN2, oltre ovviamente alla macchina su cui stiamo lavorando.

Tento di rappresentare uno schema tipico:

mia macchina locale IP 192.168.0.123

host1 su LAN1
IP pubblico 123.123.123.123
IP privato 192.168.1.123

host2 su LAN2, raggiungibile da host1 via VPN o altro poco importa
IP privato 10.10.10.123

la richiesta da es. browser che vogliamo ottenere è una risposta a http://10.10.10.123:34567

I tunnel saranno 2:
tun1 = dalla macchina locale a host1 su una porta arbitraria
tun2 = da host2 a host1 sulla porta da raggiungere

se volessi avere altri hop, il meccanismo è lo stesso, es. con 4 hops:
tun1 = dalla macchina locale a host1 su una porta arbitraria
tun2 = da host2 a host1 su una porta arbitraria
tun3 = da host3 a host2 su una porta arbitraria
tun4 = da host4 a host3 su una porta arbitraria
tun5 = da host5 a host4 sulla porta da raggiungere

L'opzione -L del comando ssh serve a specificare che segue un binding tra 2 porte.
La porta di sinistra è quella più vicina a noi (macchina locale o hop successivo).
Quella di destra è quella remota, per cui immaginiamo uno schema tipo:
NOI --> portalocale:host1:porta1 --> porta1:host2:porta2  --> porta2:host3:porta3 etc fino all'ultimo host e all'ultima porta.

Tornando ai 2 tunnel:

dalla macchina locale verso host1
ssh -L 9999:localhost:9999 root@host1

da host1 verso host2
ssh -L 34567:localhost:9999 root@host2

Con l'esempio dei 5 tunnel:

ssh -L 9999:localhost:9999 root@host1
ssh -L 9999:localhost:9999 root@host2
ssh -L 9999:localhost:9999 root@host3
ssh -L 9999:localhost:9999 root@host4
ssh -L 34567:localhost:9999 root@host5

Ora basta puntare il browser così:
http://localhost:34567

Se vogliamo concatenare i comandi in modo da inviarli via SSH in un'unica riga:
ssh -v -L 9999:localhost:9999 root@host1 -t ssh -v -L 9999:localhost:9999 root@host2 -t ssh -v -L 9999:localhost:8080 root@host3 -t ssh -v -L 9999:localhost:8080 root@host4 -t ssh -v -L 34567:localhost:8080 root@host5

************************************************************************
*** ENGLISH ***

If we manage a linux remote machine inside LAN1, on which we access via SSH, we could need to access to a LAN2 connected e.g. through a VPN. Essentially that machine can be a proxy for accessing to LAN2 and the easiest way is setting the port forwarding via SSH, so we obtain an encrypted SSL tunnel. The smartest of you have already though to use it as an anonymous navigation proxy or as a bounce, but any security matter is beyond the scope of this post. We only need to control both the machines on LAN1 and LAN2, in addition to the PC we are workin on.

I try to represent a typical situation:

IP on my local machine 192.168.0.123

host1 on LAN1
public IP 123.123.123.123
private IP 192.168.1.123

host2 on LAN2, reachable from host1 via VPN or else we don't mind
private IP 10.10.10.123

the request we want to achieve (e.g. browser) is a reply to http://10.10.10.123:34567

There will be 2 tunnels in place:
tun1 = from the local machine to host1 on any arbitrary port
tun2 = from host2 to host1 on the port we need to reach

if I would need additional hops, the mechanism is the same, e.g. with 4 hops:
tun1 = from the local machine to host1 on any arbitrary port
tun2 = from host2 to host1 on any arbitrary port
tun3 = from host3 to host2 on any arbitrary port
tun4 = from host4 to host3 on any arbitrary port
tun5 = from host5 to host4 on the port we need to reach

The ssh -L argument needs to specify that a bind between 2 ports will follow.

The leftmost port is the nearest to us (local machine or next hop).
The rightmost port is the remote, so we can imagine the following scheme:
ME --> localport:host1:port1 --> port1:host2:port2  --> port2:host3:port3 etc until the last host and the last port.

Let's go back to the 2 tunnels:

from the local machine to host1
ssh -L 9999:localhost:9999 root@host1

from host1 to host2
ssh -L 34567:localhost:9999 root@host2

Let's go back also to the 5 tunnels example:

ssh -L 9999:localhost:9999 root@host1
ssh -L 9999:localhost:9999 root@host2
ssh -L 9999:localhost:9999 root@host3
ssh -L 9999:localhost:9999 root@host4
ssh -L 34567:localhost:9999 root@host5

Now we only need to address the browser to:
http://localhost:34567

If we want to concatenate the commands in order to send them via SSH in a whole row:
ssh -v -L 9999:localhost:9999 root@host1 -t ssh -v -L 9999:localhost:9999 root@host2 -t ssh -v -L 9999:localhost:8080 root@host3 -t ssh -v -L 9999:localhost:8080 root@host4 -t ssh -v -L 34567:localhost:8080 root@host5

Split Tunneling + VPN + VMware (Windows, Mac OS X, Linux)

Mi è capitata l'esigenza di monitorare intere classi di apparati tramite VPN (in questo caso erano Cisco, ma è indifferente).

Purtroppo il router aziendale non supportava il Cisco Client, in quanto si trattava di una customizzazione di linux in cui il client vpnc si rifiutava di funzionare, ma forse il problema era il concentratore, antichissimo e in gestione a terzi. Per farla breve, l'unico apparato in grado di connettersi era una macchina Windows con a bordo XP o 2003 Server, tramite l'ordinario Cisco VPN Client o addirittura il VPN client integrato. Questo però mi impediva di svolgere operazioni che potevo compiere solo tramite server linux, ma ho trovato la soluzione forzando il 2003 Server (o XP... non avrebbe fatto differenza) a fare da gateway a una pletora di macchine virtuali linux.

192.168.101.0 è la LAN dell'ufficio

192.168.101.1 è il router di connettività

192.168.101.19 è il server WIndows 2003 Server che useremo come gateway VPN per via di RAM e CPU abbondanti (serve a ospitare le virtual machines)

VMware VIRTUAL MACHINE (NO PLAYER, es. VMware Workstation, Fusion, etc)

VMware Player non permette di editare il Virtual Networking, quindi non è adatto.

Concettualmente il VPN client di Microsoft permette di fare da gateway di connessione, sia per le VM ospitate al suo interno (VMware Workstation, Fusion ed altri futuri paritetici), ma anche per tutte le macchine della LAN.

WINDOWS CON CLIENT VPN E VMWARE WORKSTATION GIA' INSTALLATO

START / ESEGUI / regedit HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Linkage\Bind sposta in alto \Device\NdisWanIp riavvia

Connessione VPN / Proprietà / Rete / TCPIP / Proprietà:

• DNS server remoto (es. 10.0.0.101)
• Avanzate lascia flag gateway predefinito

Connessione VPN / Proprietà / Avanzate:

• consenti ad altri utenti
• scegli VMnet8 (è l'interfaccia di NAT di VMware)
• il sistema automaticamente imposta VMnet8 a 192.168.0.1, se è un secondo gateway (es. ridondante) metti un indirizzo diverso es. 192.168.0.2

Connetti la VPN e controlla quale indirizzo abbia il gateway, es.172.16.1.1.

VMware Workstation / Edit / Virtual Network Editor, sostituisci VMnet8 "Use local DHCP" il default 192.168.137.0 con 192.168.0.0.

START / ESEGUI / cmd

• route print (in basso non ci sono rotte statiche)
• route -p add 172.16.0.0 mask 255.255.0.0 172.16.1.1 metric 1
• (route -p sta per "persistent", cioè statica, si conserva al riavvio)
• ping 10.0.0.101 e anche ping google.it
• se non pinga google:
• route delete 0.0.0.0
• route add 0.0.0.0 mask 0.0.0.0 192.168.1001.1 metric 0

LINUX NELLA VM (usa la classe della VMnet8)

Le Virtual Machines devono avere 2 interfacce di rete (/etc/network/interfaces): eth0 è su VMnet8, eth1 invece in è bridge su VMnet1

sudo -i

nano /etc/networking/interfaces

# The loopback network interface

auto lo

iface lo inet loopback

#QUESTA E' LA LAN TRA MACCHINE VMWARE

auto eth0

iface eth0 inet static

   address 192.168.0.20

   netmask 255.255.255.0

   gateway 192.168.0.1

   dns-nameservers 10.0.0.101 10.0.0.102

#ATTENZIONE! QUESTA E' LA LAN ORDINARIA DELLE MACCHINE DELL'UFFICIO

auto eth1

iface eth1 inet static

   address 192.168.101.20

   netmask 255.255.255.0

   gateway 192.168.101.1

   dns-nameservers 192.168.101.1 208.67.222.222

/etc/init.d/networking restart

Considerati alcuni problemi di rotte di default (0.0.0.0 / 0) che ritornano, preferisco fare un cronjob di questo tipo:

# m h  dom mon dow   command

*/1 * * * * /home/conf/network_fab.sh

#!/bin/bash

sudo /sbin/route del -net 10.0.0.0/8 gw 192.168.0.1 dev eth0

sudo /sbin/route del -net 172.16.0.0/12 gw 192.168.0.1 dev eth0

sudo /sbin/route add -net 10.0.0.0/8 gw 192.168.0.1 dev eth0

sudo /sbin/route add -net 172.16.0.0/12 gw 192.168.0.1 dev eth0

sudo /sbin/route delete default dev eth0

e ci puoi infilare tutte le reti raggiungibili dal gateway remoto che ora raggiungi via VPN

OSX (ricorda di usare l'IP di Windows nella LAN come gateway)

sudo route -n add 10.0.0.0/8 192.168.101.19
sudo route -n add 172.16.0.0/12 192.168.101.19

Windows XP e 2003 (ricorda di usare l'IP di Windows nella LAN come gateway)

route -p add 10.0.0.0 mask 255.0.0.0 192.168.101.19 metric 1
route -p add 172.16.0.0 mask 255.255.0.0 192.168.101.19 metric 1