Forse non tutti sanno che… ssh permette il forwarding.
-L [bind_address:]port:host:hostport
Specifies that the given port on the local (client) host
is to be forwarded to the given host and port on the
remote side. This works by allocating a socket to listen
to port on the local side, optionally bound to the
specified bind_address. Whenever a connection is
made to this port, the connection is forwarded over the
secure channel, and a connection is made to host port
hostport from the remote machine. Port forwardings
can also be specified in the configuration file. […] Only
the superuser can forward privileged ports. By default,
the local port is bound in accordance with the
GatewayPorts setting. However, an explicit
bind_address may be used to bind the connection to
a specific address. The bind_address of “localhost”
indicates that the listening port be bound for local use
only, while an empty address or ‘*’ indicates that the
port should be available from all interfaces.
Nel caso vi servisse ridirigere l’input in una porta locale verso un qualcosa di remoto, il gioco è fatto:
Questa riga permette di collegare la porta 9999 locale con la porta 80 dell’ip 209.85.135.105 – google (è necessario l’inserimento della password dell’utente@127.0.0.1)!
Se per caso doveste ridirigere il traffico da un server ad un altro o voleste un tunnel criptato per accedere a certi servizi (qualcuno ha detto mail?), potrebbe essere utile.
Altre info qua.
Ok, capita anche ai migliori.
A me però sta particolarmente sulle balle.
Così, visto che mi è già capitato due volte di chiudermi fuori da una box remota pistolando sul firewall a caso – ed è decisamente umilante rompere le balle al prossimo per il riavvio in loco del server – ho ben deciso di scrivere un semplice scriptino in bas in cron.daily, che rilancia periodicamente il file con la configurazione del firewall “standard”.
Che odio.
Dopo gli accidenti tirati precedentemente, ho scoperto che dare un comando CHANGE su una colonna dichiarandola come TIMESTAMP ha il seguente effetto: il default diventa CURRENT_TIMESTAMP e l’extra è ON UPDATE CURRENT_TIMESTAMP.
Avevo letto che CHANGE e MODIFY cancellavano gli attributi (l’Extra) delle colonne cui cambiavano il tipo, e così mi sono messo ad assegnare TIMESTAMP e DATETIME ai due campi created/updated in modo da togliermi i dubbi.
(dal man: “When you use CHANGE or MODIFY, column_definition must include the data type and all attributes that should apply to the new column, other than index attributes such as PRIMARY KEY or UNIQUE. Attributes present in the original definition but not specified for the new definition are not carried forward.“)
sim:test> ALTER TABLE A CHANGE created created DATETIME; sim:test> ALTER TABLE A CHANGE updated updated TIMESTAMP; [...] | created | datetime | YES | | NULL | | | updated | timestamp | NO | | CURRENT_TIMESTAMP | on update CURRENT_TIMESTAMP |
Alla fine mi sono un po’ capito leggendo qua.
I dati di tipo timestamp dovrebbero essere dei datetime (e lo sono come formato), ma a differenza di questi ultimi si aggiornano con l’ora attuale.
The TIMESTAMP data type offers automatic initialization and updating.
Dopo aver reso la colonna updated CURRENT_TIMESTAMP con aggiornamento sull’UPDATE dei dati, ho potuto fare:
ALTER TABLE A MODIFY created TIMESTAMP NOT NULL DEFAULT '0000-00-00 00:00:00';
e inserire un paio di dati:
sim:test> INSERT INTO A (word) VALUES ('gastone');
sim:test> INSERT INTO A (word,created) VALUES ('paperino',NULL);
col risultato:
| 5 | gastone | 0000-00-00 00:00:00 | 2010-02-11 23:42:03 | | 6 | paperino | 2010-02-11 23:42:23 | 2010-02-11 23:42:23 |
Sul man c’è scritto pure questo, ma a me continua a sembrare un comportamento strano.
TIMESTAMP columns are NOT NULL by default, cannot contain NULL values, and assigning NULL assigns the current timestamp.
In conclusione, se volete avere dei campi con la creazione e l’aggiornamento automatico delle date incluso, leggetevi la pagina di Mysql sui timestamp.
E col sole di oggi, macinati altri 100 km abbondanti. 
Finalmente ho fatto il mio primo giro del nuovo anno con la mia amata drosera.
81 chilometri da Bologna passando per Calderino, Badia , Savigno, l’abbazia di Monteveglio, Stiore, Monte San Pietro e ritorno.
Peccato gli ultimi 20 chilometri abbia piovuto, ma ai fini del giro è stato irrilevante.
Troppo bello.
Un paio di scatti col cellulare. Fanno veramente schifo come taglio, ma almeno non sono venuti pessimi.
A Savigno.
Sotto l’abbazia di Monteveglio:
Il tragitto.
Oggi nel canale perl ci si è chiesto come individuare stringhe arbitrarie ricorrenti in un file (ie: query SQL in un file php).
La risposta di per se sarebbe semplice: si fa una regex che inizia con SELECT e finisce con qualcosa (ie: 
e si è a cavallo.
Il grado di difficoltà però aumenta se le stringhe sono su più righe…
Avendo trovato una soluzione che non richiede nemmeno un ciclo, la scrivo poichè ne sono orgoglioso e mi è valsa un ++.
use strict;
use File::Slurp;
my $text = read_file(‘file.php’);
my @queries = $text =~ /("SELECT.*?");/msg
Ogni valore di @queries conterrà uno dei SELECT nel file, siano essi su più righe o meno.
Più breve di così…
Segnalo anche un paio di letture sulle regex che potrebbero venire comode per capire i modificatori /m e /s, che si usano pochino.
Regexp Power by Simon Cozens (1 e 2)
acronimo: dal greco akron (estremo) + onoma (nome). Indica una sigla composta dalle iniziali di piùparole.