Cron automaticos en GNU/Linux

Linux programa que permite a usuarios Linux/Unix ejecutar automáticamente comandos o scripts (grupos de comandos) a una hora o fecha específica. Es usado normalmente para comandos de tareas administrativas, como respaldos, pero puede ser usado para ejecutar cualquier cosa.

Campo Descripción
Minuto Controla el minuto de la hora en que el comando será ejecutado, este valor debe de estar entre 0 y 59.
Hora Controla la hora en que el comando será ejecutado, se especifica en un formato de 24 horas, los valores deben estar entre 0 y 23, 0 es medianoche.
Día del Mes Día del mes en que se quiere ejecutar el comando. Por ejemplo se indicaría 20, para ejecutar el comando el día 20 del mes.
Mes Mes en que el comando se ejecutará, puede ser indicado numéricamente (1-12), o por el nombre del mes en inglés, solo las tres primeras letras.
Día de la semana Día en la semana en que se ejecutará el comando, puede ser numérico (0-7) o por el nombre del día en inglés, solo las tres primeras letras. (0 y 7 = domingo)
Usuario Usuario que ejecuta el comando.
Comando Comando, script o programa que se desea ejecutar. Este campo puede contener múltiples palabras y espacios.

Un asterisco * como valor en los primeros cinco campos, indicará inicio-fin del campo, es decir todo. Un * en el campo de minuto indicará todos los minutos.

Para entender bien esto de los primeros 5 campos y el asterisco usaré mejor varios ejemplos:
Ejemplo Descripción
01 * * * * Se ejecuta al minuto 1 de cada hora de todos los días
15 8 * * * A las 8:15 a.m. de cada día
15 20 * * * A las 8:15 p.m. de cada día
00 5 * * 0 A las 5 a.m. todos los domingos
* 5 * * Sun Cada minuto de 5:00a.m. a 5:59a.m. todos los domingos
45 19 1 * * A las 7:45 p.m. del primero de cada mes
01 * 20 7 * Al minuto 1 de cada hora del 20 de julio
10 1 * 12 1 A la 1:10 a.m. todos los lunes de diciembre
00 12 16 * Wen Al mediodía de los días 16 de cada mes y que sea Miércoles
30 9 20 7 4 A las 9:30 a.m. del dia 20 de julio y que sea jueves
30 9 20 7 * A las 9:30 a.m. del dia 20 de julio sin importar el día de la semana
20 * * * 6 Al minuto 20 de cada hora de los sábados
20 * * 1 6 Al minuto 20 de cada hora de los sábados de enero

También es posible especificar listas en los campos. Las listas pueden estar en la forma de 1,2,3,4 o en la forma de 1-4 que sería lo mismo. Cron, de igual manera soporta incrementos en las listas, que se indican de la siguiente manera:

Valor o lista/incremento

De nuevo, es más fácil entender las listas e incrementos con ejemplos:
Ejemplo Descripción
59 11 * 1-3 1,2,3,4,5 A las 11:59 a.m. de lunes a viernes, de enero a marzo
45 * 10-25 * 6-7 Al minuto 45 de todas las horas de los días 10 al 25 de todos los meses y que el día sea sábado o domingo
10,30,50 * * * 1,3,5 En el minuto 10, 30 y 50 de todas las horas de los días lunes, miércoles y viernes
*/15 10-14 * * * Cada quince minutos de las 10:00a.m. a las 2:00p.m.
* 12 1-10/2 2,8 * Todos los minutos de las 12 del día, en los días 1,3,5,7 y 9 de febrero y agosto. (El incremento en el tercer campo es de 2 y comienza a partir del 1)
0 */5 1-10,15,20-23 * 3 Cada 5 horas de los días 1 al 10, el día 15 y del día 20 al 23 de cada mes y que el día sea miércoles
3/3 2/4 2 2 2 Cada 3 minutos empezando por el minuto 3 (3,6,9, etc.) de las horas 2,6,10, etc (cada 4 horas empezando en la hora 2) del día 2 de febrero y que sea martes

Como se puede apreciar en el último ejemplo la tarea cron que estuviera asignada a ese renglón con esos datos, solo se ejecutaría si se cumple con los 5 campos (AND). Es decir, para que la tarea se ejecute tiene que ser un martes 2 de febrero a las 02:03. Siempre es un AND booleano que solo resulta verdadero si los 5 campos son ciertos en el minuto específico.

59 11 * 1-3 1,2,3,4,5 A las 11:59 a.m. de lunes a viernes, de enero a marzo
45 * 10-25 * 6-7 Al minuto 45 de todas las horas de los días 10 al 25 de todos los meses y que el día sea sábado o domingo
10,30,50 * * * 1,3,5 En el minuto 10, 30 y 50 de todas las horas de los días lunes, miércoles y viernes
*/15 10-14 * * * Cada quince minutos de las 10:00a.m. a las 2:00p.m.
* 12 1-10/2 2,8 * Todos los minutos de las 12 del día, en los días 1,3,5,7 y 9 de febrero y agosto. (El incremento en el tercer campo es de 2 y comienza a partir del 1)
0 */5 1-10,15,20-23 * 3 Cada 5 horas de los días 1 al 10, el día 15 y del día 20 al 23 de cada mes y que el día sea miércoles
3/3 2/4 2 2 2 Cada 3 minutos empezando por el minuto 3 (3,6,9, etc.) de las horas 2,6,10, etc (cada 4 horas empezando en la hora 2) del día 2 de febrero y que sea martes

Como se puede apreciar en el último ejemplo la tarea cron que estuviera asignada a ese renglón con esos datos, solo se ejecutaría si se cumple con los 5 campos (AND). Es decir, para que la tarea se ejecute tiene que ser un martes 2 de febrero a las 02:03. Siempre es un AND booleano que solo resulta verdadero si los 5 campos son ciertos en el minuto específico. en GNU/Linux

Zimbra incrementar tamaño buzones adjuntos en GNU/Linux

Linux para incrementar el tamaño de los adjuntos en zimbra podemos hacer los siguientes pasos, es de aclarar como la modificación del tamaño máximo de un archivo es valido para los tamaños de lo cargado en el maletín, mensajes de correo, citas de la agenda, tareas, y los adjuntos, ingresamos como administrador.

Si lo deseamos hacer por las herramientas gráficas o sea la consola web administradora:
Ingresamos la consola de administración.
Opción configurar.
Luego la opción configuración general.
Encontramos un formulario y en este tenemos una casilla la cual tiene en valor por defecto 10240 y hacer referencia al tamaño de lo mencionado en el punto inicial de este documento, aclarando este tamaño es en KB, este valor lo cambia por el tamaño deseado para la cuenta de zimbra, debemos hacer la operación del tamaño deseado en KB por ejemplo si desea tener un tamaño de 85 KB se hace 85X1024X1024 = 89128960/1000= 89128, la división por se hace por el valor dado en bits, este seria el valor a colocar en la casilla.

En ocasiones cuando las cuentas están en operación y el servidor esta atendiendo servicios de correo, no toma la modificación, para estos casos se hace el cambio por consola como administrador:

Cambiar de usuario a zimbra
[root@correo ~]# su - zimbra

Verificar el tamaño actual
[zimbra@correo ~]$ zmprov gcf zimbraMtaMaxMessageSize
zimbraMtaMaxMessageSize: 10240000

Modificar el tamaño del adjunto
[zimbra@correo ~]$ zmprov modifyConfig zimbraMtaMaxMessageSize 89128960

El tamaño esta dado en bits, para calcular el tamaño en Megas, se puede ejecutar el siguiente comando:

[zimbra@correo ~]$ echo 85*1024*1024 | bc
89128960

De donde 85 MB sera el tamaño deseado de nuestra parte para el buzón

Para el cambio en el tamaño de los adjuntos no es necesario reiniciar el servicio, únicamente con cerrar y abrir la sesión del usuario desde la interface web se toman los cambios, para el caso de de los MUA, se toma automático, en GNU/Linux

Squid mejorar rendimiento en GNU/Linux

Linux para saber como calcular el uso de memoria requerido para nuestro entorno y además recomendaciones para la selección del mejor hardware para el cache en disco y los sistemas de archivos.

CPU

Squid es un proceso que se ejecuta en un solo hilo y no hace uso intensivo de CPU, en las únicas ocasiones en las que hace uso intensivo de CPU es cuando el proceso es inicializado, es en este momento cuando realiza diferentes cálculos para verificar el contenido del cache. Por lo anterior es posible instalar squid en sistemas con un solo CPU de velocidades modestas.

Squid no obtiene mucho beneficio de sistemas SMP ya que no se ejecuta en múltiples hilos Además del CPU que usa el proceso principal de squid, tome en consideración aquellos programas auxiliares que usa squid para operaciones de autenticación de usuarios y grupos (external helpers) y/o programas externos para filtrado de URLs (url redirectors). Estos programas requieren de recursos de CPU de forma independiente.

Es recomendable que invierta más en la optimización de en recursos como memoria RAM y disco duro ya que estos recursos suelen ser los cuellos de botella que evitan que squid ofrezca un servicio de proxy eficiente y óptimo.

Memoria

Cuando dimensione las capacidades de memoria RAM que usara el sistema que hará de proxy con squid, no solo considere la memoria que usa el proceso principal de squid, también considere el uso de memoria de otros programas que se ejecuten aparte del sistema operativo, como pueden ser servicios DNS, Web, bases de datos, etc. A continuación mencionaremos las partes en las que squid hace uso de memoria RAM.

Una de las principales funcionalidades del proxy squid es el uso de cache en memoria RAM, squid utiliza la memoria RAM para almacenar una tabla o indice con los objetos más usados, estos objetos son conocidos como objetos calientes o en transito, esto permite acelerar el tiempo de respuesta a las peticiones de los clientes ya que siempre es más rápido acceder a la memoria RAM que a disco duro como en el caso de cache a disco (más para objetos recurrentes), el uso predeterminado de cache en memoria RAM es de 8MB, para entornos con grandes volúmenes de peticiones se recomienda incrementar el valor y agregar más memoria RAM para acelerar el servicio.

Además, por cada GB de espacio en disco que asigne para el cache en disco, squid usará aproximadamente 6MB de memoria RAM para mantener una tabla o índice con la referencia a los objetos almacenados en el cache de disco. Esto significa que, entre más grande sea el cache de disco, más memoria RAM usará squid.

Veamos como calcular el espacio de cache en disco y ver como afectaría el uso de memoria RAM.

Por cada objeto almacenado en disco, squid usa aproximadamente 56 bytes (32-bit) y 88 bytes (64-bit) de RAM para el índice y otros 16 bytes para la suma md5 del objeto, por lo que se requieren 72 o 104 bytes por cada objeto almacenado en el índice. El tamaño promedio de un objeto en el Internet es de aproximadamente 13KB.

Veamos un ejemplo de como calcular el uso de memoria de squid para almacenar el índice de objetos en el cache de disco: si dedica 1GB de espacio en disco duro para el cache en disco y suponiendo un tamaño promedio de 13KB por objeto podríamos almacenar aproximadamente 80,000 objetos en el cache de disco. Para un cache de 1GB con 80,000 objetos de 72 bytes y suponiendo un tamaño de objeto promedio de 13KB, squid va a requerir aproximadamente 6MB de memoria RAM para la tabla índice. En la practica se recomienda que dedique 1MB de RAM por cada 1GB asignado a cache_dir.

Además de la memoria usada para el cache de objetos en memoria RAM, squid también almacena en memoria los resultados de consultas DNS, las ACLs y reglas de acceso. Squid además usará memoria RAM para los programas auxiliares o redirectores de URL, por ejemplo si usa programas externos para autenticar usuarios y grupos en bases de datos externas entonces también deberá de sumar el uso de memoria de estos procesos a la cuenta, y si usa filtros de URL como squidGuard también hará uso de memoria independientemente.

Disco duro y sistemas de archivos Cuando evalué los requerimientos de disco duro para el proxy deberá de tomar en cuenta que entre más rápido sea el acceso a los objetos en el cache de disco, más rápidas serán las respuestas y mejor el servicio. El acceso al cache de disco debe ser rápido, y por lo tanto debemos almacenarlos en discos duros rápidos, veamos la información que requerimos saber en cuanto a las especificaciones técnicas que los discos duros deben cumplir para ofrecer un rendimiento eficiente en un servidor proxy cache. La velocidad de rotación de los discos duros SATA actuales son de 7200 RPM y en discos SAS de 15000 RPM, siempre se recomiendan los discos duros más rápidos, sin embargo los discos SATA son más accesibles en precio. Más importante que la velocidad de rotación es el tiempo promedio que toman las cabezas del disco en moverse de un track aleatorio a otro, esta medida es conocida como random seek time o random read time, y se mide en segundos. Entre más bajo sea el valor, mejor será el rendimiento del acceso al cache de disco.

Por ejemplo un disco duro SATA de un servidor pequeño tiene un disco duro donde en las especificaciones se ve:

Average Seek Time: < 9.0 ms

El cache en disco se almacena en un directorio del sistema de archivos, se recomienda que este en una partición independiente de la del sistema operativo, de preferencia en un disco duro independiente, se recomienda usar el sistema de archivos ext2 ya que es un sistema de archivos sin journaling y montarlo con la opción noatime para no gastar recursos en la actualización de las fechas de acceso de los archivos en el cache.

Importante Ya que el sistema de archivos no tiene journaling es propenso a que se corrompa en caso de que se apague de forma repentina el sistema, por ejemplo con un apagón, por lo que se recomienda que por lo menos el servidor este conectado a un UPS y use el programa NUTS para monitorizar el estado del UPS y en caso de que se vaya la luz NUTS apague el servidor de forma limpia antes de que se quede sin batería.

Squid esta especialmente diseñado para ofrecer un mejor rendimiento cuando tiene múltiples caches esparcidos en diferentes sistemas de archivos, en diferentes discos duros ya que puede balancear el acceso al cache entre los diferentes discos. No se recomienda que use squid en sistemas con RAID con mirroring como RAID1 o RAID5. squid balanceará las lecturas y escrituras en los diferentes discos por lo que mejorará el rendimiento del cache.

El espacio en disco que asigne al cache debe ser lo suficientemente grande para poder almacenar los objetos estáticos de los sitios visitados por lo menos por un día para que el uso del proxy sea eficiente, si las peticiones son a sitios con objetos estáticos que no cambian tan seguido entonces se recomienda que calcule el espacio en base al número de días que quiere conservar los objetos en el cache y la velocidad de descargas asignada al servidor proxy. También tienen que ver factores como el tamaño promedio de los objetos en el cache y los hábitos de descargas de los usuarios.

Para definir el espacio de disco que se asignara al cache es importante determinar la cantidad aproximada de datos que pasaran por el cache cada día. Si no es capaz de determinarlo, puede usar la tasa teórica de transferencia máxima de su enlace o el ancho de banda dedicado para la navegación en especifico para HTTP, HTTPS y FTP. Un enlace de 1Mb/s puede transferir aprox 111,000 bytes por segundo (111 KB/s).

Suponiendo que manteniendo una tasa de transferencia fija de 111 KB/s y que todos los objetos van al cache, podremos descargar aproximadamente 400MB por hora, y si el cache solo es usado en horarios de trabajo (8 horas al día) entonces podemos determinar que el espacio requerido para un día sería de 3.2 GB, y si desea mantener los objetos por una semana (5 días laborales) entonces podría necesitar aproximadamente 16GB de espacio de disco para el cache de una conexión de 111KB/s. Recuerde que también debe considerar el espacio requerido para almacenar los logs del proceso squid y logs de accesos, por lo que en sistemas con bastantes peticiones puede llegar a tener archivos de logs diarios de 1GB o más, en este documento se recomiendan 5GB para logs de squid que se rotan una vez por semana y se almacenan de forma comprimida los logs de las últimas 5 semanas para cuestiones de reportes.

En sistemas con volúmenes de peticiones grandes se recomienda dedicar una partición de 20 GB para la partición /var/log. Si va a almacenar reportes web de los accesos al proxy se recomienda que dedique por lo menos 10 GB adicionales para el sistema de archivos /var/www para almacenar los reportes por 6 meses.

Es importante tener en cuenta ademas:

1. Cambia la opción "cache_mem" de 8MB, el predeterminado, a 32 MB. Si tu máquina tiene memoria disponible, aumentar esta opción de memoria caché puede mejorar mucho el rendimiento. Algunas personas ponen esto a 100 MB o más.
2. Añade la opción "half_closed_clients" para ponerla en "off" en el archivo de configuración. Además, cambia la opción "maximum_object_size" por "1024KB" para mejoras menores.
3. Indica tus servidores de nombres DNS usando la opción "dns_nameserves". Esto es importante puesto que Squid se queda atascado cuando hace búsquedas de DNS.
4. Añade las opciones "cache_swap_low" y "cache_swap_high" que ayudan a determinar cuando Squid empezará a vaciar la caché. Esto es importante para mantener la caché dentro de unos límites razonables y accesibles rápidamente.
5. Ajusta la opción "memory_pools" en "off" para que Squid libere la RAM que no está usando el servidor y la coloque en la fuente de memoria.
en GNU/Linux