Como siempre, os dejo aqui cosas que encuentro interesantes y que pruebo. 

La idea es tener un servidor linux al que mediente rsync se conecte un servidor windows para disponer de una copia de los ficheros. Esta copia solo se realiza sobre los documentos que han cambiado. Algo más que interesante para ahorrar en ancho de banda.

Set up rsync server on Ubuntu

1. Run sudo apt-get install rsync (it’s probably already installed)
2. Create a file named rsyncd.conf in /etc

   1. sudo nano /etc/rsyncd.conf

   2. Add the following to rsyncd.conf, replacing all instances ofusername with your Ubuntu username:

      [usernamebackup]
      
          path = /home/username/backup
          comment = Backup
          uid = username
          gid = username
          read only = false
          auth users = username
          secrets file = /etc/rsyncd.secrets

   3. sudo chmod 644 /etc/rsyncd.conf

3. Create a file named rsyncd.secrets in /etc

   1. sudo nano /etc/rsyncd.secrets

   2. Add the following to rsyncd.secrets, replacing usernamewith your username and password with a password of your choosing:

      username:password

   3. sudo chmod 600 /etc/rsyncd.secrets

4. Open rsync port by editing /etc/default/rsync and setting

   RSYNC_ENABLE=true

5. Restart rsync

   sudo /etc/init.d/rsync restart

Set up rsync client on Windows

1. Install Cygwin, making sure Editors > nano and Net > rsync are selected
2. Add C:\cygwin\bin; to the Windows PATH statement
   1. Right-click on My Computer and select Properties
   2. Switch to the Advanced tab and click the Environment Variables button at the bottom
   3. Find the “Path” or “PATH” variable in the System variables list at the bottom and click Edit
   4. Add C:\cygwin\bin; to the beginning of the list
3. Create secret file to store password in Cygwin
   1. Start Cygwin Bash Shell
   2. Create secret file in the filesystem root and enter only the password in rsyncd.secrets above, with no spaces or line breaks

      nano /secret

   3. chmod 600 /secret

   4. chown Administrator:SYSTEM /secret

4. Create bat file to run rsync
   1. Open Notepad and enter the following command, replacingUser Name with your Windows User Name directory,username with your Ubuntu username, and ipaddresswith the IP address of your Ubuntu server (e.g. 192.168.0.100):

      C:\cygwin\bin\rsync.exe -qrtz --password-file=c:\cygwin\secret --delete "/cygdrive/c/Documents and Settings/User Name” username@ipaddress::usernamebackup

      As you may have guessed, the "/cygdrive/c/Documents and Settings/User Name" command line option designates where to start backing up from. As currently configured, this will backup your Windows home directory (Desktop, My Documents, etc). If you want to backup your whole hard drive, change that option to "/cygdrive/c".

   2. Save the file as C:\rsync.bat

Create scheduled task to run C:\rsync.bat once a day

1. Create scheduled task
   1. Goto Start > Programs > Accessories > System Tools > Scheduled Tasks
   2. From the File menu, select New > Scheduled Task
   3. Name this task “rsync backup”
   4. Right-click on the task and select properties
   5. Enter C:\rsync.bat in the Run field
   6. Switch to the Schedule tab and select the time you want the backup to run every day and click Ok
2. Test the scheduled task
   1. Create a folder called C:\data and put a few photo files in it
   2. Edit C:\rsync.bat and change "/cygdrive/c/Documents and Settings/User Name“ to "/cygdrive/c/data"
   3. Add the command pause on a new line at the bottom of C:\rsync.bat and save the file
   4. Right-click on the “rsync backup” scheduled task and select “Run”—A command window should popup and with either errors or the list of files being transfered. If there are errors, troubleshoot them.
   5. Once the scheduled task and C:\rsync.bat appear to be working correctly, change "/cygdrive/c/data" back to"/cygdrive/c/Documents and Settings/User Name“and remove the pause command
   6. Finally, edit the scheduled task properties and change “Run as:” to NT AUTHORITY\SYSTEM—this will ensure that the process runs in the background, without popping up a command prompt window

Run your first backup

Run C:\rsync.bat from the command line before going to bed. Backing up 35GB over a wireless-g connection took me over 8 hours. Subsequent backups take less than a minute. Behold the beauty of rsync.

Update: for information on how to backup Ubuntu to Ubuntu (or Linux to Linux really) using rsync with passphraseless keys, check out Playing with rsync on Ubuntu.

Cuando tenemos dudas de que algun correo electrónico proviene de donde dice, de si es spam o no, etc, debemos analizar sus cabeceras. Aqui os dejo una herramienta online para poder obtener esta informacion.

http://www.levinecentral.com/mail_parse/default.aspx

PDT Eclipse + Zend Debugger + PHP

Este es un post de un compañero de blogs…. www.jesusyepes.com , os lo dejo aqui a ver si como a mi os solventa algún problema.

Hace poco me tope con un problema en uno de los servidores que administro, el mysql se colgo un par de veces en un mes y no sabía por qué.

Decidí buscar información para ver como podía ver que consultas estaban demorándose mucho y podían causar el cuelgue del servidor. Nota: Los comandos que he utilizado están sobre un servidor que usa plesk y centos 4, si usas otro sistema es posible que las ubicaciones de los archivos cambien.

Bien, primero, editamos el archivo de configuración de mysql, y añadimos las lineas:

long_query_time = 1
log_slow_queries = /var/log/slow-queries.log

La primera es el numero, en segundos, a partir del cual se considerará que la consulta es lenta. La segunda, el archivo en el que se guardarán dichas consultas (en mi caso, tuve que crearlo a mano para que me las guardara).

Después, tendremos que reiniciar el servidor mysql con /etc/initd/mysqld restart.

Si queremos comprobar que las consultas lentas están siendo logeadas, lo podemos hacer escribiendo mysqladmin -u admin -p var |grep log_slow_queries. Esto nos devolverá On o Off, según esté activado o desactivado.

Si tenemos phpmyadmin instalado, podemos entrar a este, después picnhamos sobre “mostrar información en tiempo de ejecución de MySql”. Podremos ver un campo llamado “slow_queries” que nos mostrará la cantidad de consultas lentas que han sido ejecutadas.

También puede sernos util ver que consultas se están ejecutando actualmente en el servidor. Podemos ejecutar mysqladmin -u admin -p proc status para saberlo.

Slow queries en el manual de mysql

http://fleksray.org/Flex_skin.html

http://flashcommander.org/

Aqui teneis una libreria interesante:

http://code.google.com/p/assql/

Codigo de ejemplo:

public boolean appConnect(IConnection conn, Object[] params){

//Se enviaran 2 parametros, el parametro 0 indica si es modelo o usuario, el parametro 1 el nombre del room, el parametro 2 el modo privado

   if (params[2].toString()==”privado”){ 

if (!this.appScope.hasChildScope(params[1].toString()) && params[0].toString() ==”modelo”)

           this.appScope.createChildScope(params[1].toString());

       IScope room = this.appScope.getScope(params[1].toString());

       if (this.appScope != room)//guard against re-entrancy

       {

//appScope=room;

           conn.connect(room);//this will reconnect to the room scope

           return appConnect(conn, params);

       }

   }

return true;

}

Como previamente habíamos comentado, Microsoft agregó algunas mejoras al store de Exchange standard edition.

Adios a los 16 GB
Ya todos sabemos que antes del SP2 de Exchange 2003, el límite de la base de datos era de 16 GB, sumando el .edb y el .stm. Es de recontra público conocimiento que con el SP2, este límite se va a 75 GB.
PERO, attenti a esto. Apenas instalamos SP2, el límite se va a 18 GB, y el resto lo deberemos configurar por entradas en el registro (registry) de Windows. Porqué se va a 18 GB y no a 75? Bueno, el grupo de desarrollo pensó en dos opciones:

1) Todas las implementaciones de Exchange, anteriores a SP2, se pudieron haber hecho pensando en el límite de 16 GB, por lo tanto los servidores podrían haber estado configurados para soportar sólo este tamaño (con particiones reducidas).
2) Tener mayor granularidad y evitar crecimiento no deseado en la base. A parte, sería bueno no configurarla al 100% de su capacidad, así tenemos la opción de volverla a montar con un nuevo límite y nos daría la posibilidad de reducir su “peso” bajando los correos a .pst.

La razón del cambio en registry? No se sabe, pero podemos suponer que no tuvieron tiempo para desarrollar una interface en tantos idiomas como Exchange está desarrollado.

El cambio en registry debería ser en la siguientes claves:

Store privado:
HKLM\System\CurrentControlSet\Services\MSExchangeIS\{server name}\Private-{GUID}

Para el store público:
HKLM\System\CurrentControlSet\Services\MSExchangeIS\{server name}\Public-{GUID}

La clave que debemos agregar es:
Tipo de valor: REG_DWORD
Nombre de valor: Database Size Limit in GB

Para la versión estándar, el valor que se puede agregar va de 1 a 75. Para la Enterprise, de 1 a 8000. Estos numeritos significan GB.

Para que los cambios apliquen, solamente debemos desmontar y montar el store. Si todo salió bien, un evento en el Visor de Sucesos con el número de ID 1216 será creado. Y dirá algo así como:

Tipo de suceso: Información
Origen del suceso: MSExchangeIS Mailbox Store
Categoría del suceso: General
Id. suceso: 1216
Fecha: 11/11/2005
Hora: 05:48:26 p.m.
Usuario: No disponible
Equipo: MSX01
Descripción:
El almacén de Exchange ‘Primer grupo de almacenamiento\Almacén del buzón (MSX01)’ está limitado a 53 GB. El tamaño físico actual de esta base de datos (el archivo .edb y el archivo .stm) es 13 GB. Si el tamaño físico de esta base de datos menos su espacio libre lógico excede el límite de 53 GB, la base de datos se desmontará de forma regular.

Para más información, haga clic en http://www.microsoft.com/contentredirect.asp.

Es capricho 18 GB?

Seguramente nos preguntaremos ¿porqué 18 GB y no otro número? Bien, para entender esto, tendremos que tener en mente el concepto de Database Size Buffer. Básicamente es un seteo que informa a Exchange para que grabe en el Visor de Sucesos (ID de evento: 9688) si la base de datos está cerca de su límite. La cercanía del límite sale del 10%… Cuando a la base le queda 10% para llegar al límite, Exchange entiende que está en esa cercanía. Teniendo un default de 18 GB, su frontera sería a los casi 2 GB, lo que significa que la entrada en el Visor de Sucesos sería a los 16 GB, el viejo límite.

El control del Database Size Buffer también es controlado via registro. Para modificar este valor, deberíamos tocar:

Tipo de Valor: REG_DWORD
Nombre de Valor: Database Size Buffer in Percentage

El valor ingresado debería ser el procentaje. Si ponemos 20, la advertencia se generará al 20%.

Tamaño físico o tamaño lógico?
Como previamente habíamos comentado Exchange SP2 hará diferencias entre tamaño físico y lógico para determinar el tamaño de la base. El tamaño físico hacer referencia al tamaño del .edb y .stm como lo vemos en el Explorer, o viendo sus propiedades. El tamaño lógico es ese mismo tamaño, menos los bloques libres que quedaron en la base cuando los elementos son eliminados, o descargados a PSTs. La cantidad de espacio libre, lo podremos revisar mirando el Visor de Sucesos, específicamente el suceso con ID 1221.

De manera predeterminada, estos análisis son realizados a las 5 AM, pero se puede cambiar esta config. via registry (también…):

Tipo de Valor: REG_DWORD
Nombre de Valor: Database Size Check Start Time in Hours From Midnight

El valor que tenemos que poner acá es la cantidad de horas pasada la medianoche que queremos que espere Exchange para hacer el análisis. Por ejemplo, si queremos que se haga a las 6 de la tarde, el valor acá sería de 18.

Anterior al SP2, cuando la base de datos llegaba a su límite, se desmontaba. Desde ya, podremos encontrar distintos trucos para darle un respiro de 1 GB más. Los muchachos de Redmond se pusieron las pilas y cambiaron un poquito estsa cosas. Veamos que pasa cuando llegamos a nuestro límite.
Cuando la base de datos llega a su límite, y el primer chequeo ha sido realizado por Exchange (a las 5 am) la base no es desmontada. En su lugar, un evento con ID 9689 es creado. Luego de esta advertencia, tendremos 24 horas para resolver el problema, de lo contrario al siguiente chequeo (5 am del día siguiente), la base de datos se desmontará informando un evento con ID 9690…

PERO!! Podremos montar nuevamente la base. Lástima que se desmontará a las 5 am del otro día, cuando el chequeo periódico se realice. Al menos le ganamos 24 horas más al Server…