tuneles SSH por consola.

A partir de la version 19.04 de Ubuntu, el gstm (Gnome SSH Tunnel Manager) dejo de funcionar, lo cual me llevo a repasar como se creaban los port forwarding desde consola. Sin demasiado misticismo ahi va la explicacion con un ejemplo

ssh -N -f usuario@direccionweb.algo -p 1052 -L 5000:localhost:3050

Vamos por partes.

ssh -> es el comando ssh

-N -> evita que ejecute un comando remoto, en este caso no nos abrira un shell remoto.

-f -> que se ejecute en background. esto permite dejar el tunel establecido corriendo en segundo plano. 

usuario@direccionweb.algo -> esta es la ruta del servidor al que vamos a conectarnos. 

-p 1052 -> en caso de que no utilice el puerto por defecto del servicio ssh (22) aclaramos el puerto con la opcion -p, en este caso el servidor al que nos conectamos, el servicio ssh escucha en el puerto 1052

-L 5000:localhost:3050 -> una vez conectados al servidor, le informamos que queremos acceder al puerto 3050 de la maquina localhost de la red remota a traves del puerto local 5000. si quisieramos acceder a otra maquina de la red remota, reemplazariamos "localhost" por la ip de la otra maquina.

Y eso es todo.
En caso de necesitar mas de un mapeo, se repite dentro de la misma sentencia el comando -L con cada mapeo que se quiera agregar.
Finalmente, para eliminar los tuneles creados, los listamos con el siguiente comando:

sudo lsof -i -n | egrep '\<ssh\>'

y hacemos

kill 9859

(tomando la imagen como ejemplo)

Cambiar a www-data a usuario comun

Si necesitan ejecutar comandos como www-data, lo que habitualmente hacemos es lo siguiente:

sudo -u www-data 

el problema de este metodo es que, habitualmente, olvido poner el la ejecucion como usuario y si estoy logueado como root entonces termino modificando archivos y dejandolos inaccesibles para el usuario www-data con los consiguientes errores de apache. para tal fin es preferible permitir que www-data pueda loguearse y existir como un usuario comun. para ello basta con:

usermod -s /bin/bash www-data

luego de esto y habiendonos logueados como root

sudo su

solo basta hacer

su www-data

y podremos trabajar como dicho usuario.

Simular una ejecución de CRON.

Esto lo publicó alguien aquí https://serverfault.com/questions/85893/running-a-cron-job-manually-and-immediately/85906

Una maravilla!.

crontab -l | grep -v '^#' | cut -f 6- -d ' ' | while read CMD; do eval $CMD; done

Las explicaciones del caso:

crontab -l       => lista todas las tareas en cron
grep -v '^#'     => elimina de la salida todos los comentarios.
cut -f 6- -d ' ' => borra la programación de tareas de cron
while...         => ejecuta una por una las tareas de cron.


GENIAL!

PHP FLUSH(), anda?

Despues de pasear por toda una serie de inutiles escribiendo soluciones mágicas devuelvo la única que realmente sirve.

header("Cache-Control: no-cache, must-revalidate");
header('X-Accel-Buffering: no');

Setear ambos headers provoca que la sentencia flush() del php funcione correctamente. Cualquier otra solucion que encuentren son solo pérdidas de tiempo.

Nobleza obliga, la solución la encontré aqui: http://www.jeffgeerling.com/blog/2016/streaming-php-disabling-output-buffering-php-apache-nginx-and-varnish

FIREBIRD - Ejemplo: Como insertar registros entre gdb diferentes a traves de PSQL

No encontré un ejemplo completo, así que ahí va el mío. Lo generé en transacciones autónomas con COMMIT cada 5000 registros. Cualquier duda pregunten.

*Actualizado 22/07/2016 la inserción de los 5000 registros queda en una transacción separada, lo que permite por un lado, generar un commit pequeño y por otro ver el progreso del script, ya que podemos ir chequeando como se va llenando la tabla destino. He modificado el numero de registros de 5000 a 10000, 15000, 20000, 25000 y 30000. Tuve resultados significativos entre los 5000 y los 20000. Luego los commits comenzaron a demorarse un poco con lo cual no ganaba nada mas allá de los 20000. No encontré demasiada documentación a este respecto, si alguien me puede aportar algo le estaré agradecido. Las pruebas se hicieron copiando tablas entre bases de 30 millones de registros y mas. Si bien el proceso es lento, no repercutió en la performance general del servidor. Se trata de bases de producción con muchos usuarios trabajando sobre la base de origen. 

EXECUTE BLOCK
AS
DECLARE VARIABLE QUERY VARCHAR(5000);
DECLARE VARIABLE REGISTROS INTEGER;
DECLARE VARIABLE FLAG SMALLINT;
DECLARE VARIABLE FCAMPO1 VARCHAR(15);
DECLARE VARIABLE FCAMPO2 VARCHAR(15);
DECLARE VARIABLE FCAMPON VARCHAR(50);
BEGIN
  REGISTROS=1;
  FLAG=1;

  IN AUTONOMOUS TRANSACTION DO DELETE FROM TABLALOCAL;

  WHILE (FLAG=1) DO BEGIN
    FLAG=0;
    QUERY ='SELECT CAMPO1, CAMPO2, CAMPON
            FROM TABLAORIGEN
            ROWS '||:REGISTROS||' TO '||(:REGISTROS + 4999);

    IN AUTONOMOUS TRANSACTION DO BEGIN
      FOR
        EXECUTE STATEMENT QUERY
        ON EXTERNAL DATA SOURCE 'server:/ruta/base.gdb'
        AS USER 'SYSDBA'
        PASSWORD 'masterkey'
        INTO :FCAMPO1, :FCAMPO2, :FCAMPON
        DO BEGIN
          FLAG=1;
          INSERT INTO TABLALOCAL (CAMPO1, CAMPO2, CAMPON)
          VALUES (:FCAMPO1, :FCAMPO2, :FCAMPON);
        END
    END
    REGISTROS = REGISTROS + 5000;
  END
END