Por favor, por su seguridad, instale un navegador más actualizado y seguro.
Fantástico truco de Steve Adams. Con cron podemos programar tareas por horas, días, semanalmente, mensualmente... pero, ¿cómo programar una tarea para que se ejecute cada dos semanas?
#----+-----+-----+-----+-----+------------------------------------------------- #min |hour |day |month|day |command # | |of mn| |of wk| #----+-----+-----+-----+-----+------------------------------------------------- 03 04 * * 4 expr `date +%W` % 2 >/dev/null || script_a_ejecutar
El comando comprueba si la semana actual es par o impar, y ejecuta el comando en caso de ser par.
En caso de querer ejecutar el comando sólo en las semanas impares, para evitar el error de cron por un valor de retorno distinto a cero, se debe usar:
expr `date +%W` % 2 >/dev/null && run_my_script || true
Me acaba de ocurrir: tengo un listado de ficheros en un archivo, un fichero por línea, y debo hacer un paquete con ellos. Así que pruebo lo obvio:
$ tar zcf fichero.tgz < lista_ficheros tar: Rechazo cobarde a crear un archivo vacío
Sorpresa, a tar no le gusta recibir la lista de ficheros a empaquetar "en columna", sino que los espera "en fila". Parecía trivial fusionar todas las líneas del listado de ficheros en una sola, pero al final me llevó un rato, así que lo anoto aquí para futuras referencias:
$ echo `cat lista_ficheros` >> lista_ficheros_linea $ tar zcf fichero.tgz `cat lista_ficheros_linea`
Esto funcionará si el fichero con la lista de archivos no contiene líneas en blanco. Si es el caso, basta con filtrar caracteres:
$ echo `cat lista_ficheros | cut -f2 | grep ".${X}"` >> lista_ficheros_linea
$ tar zcf fichero.tgz `cat lista_ficheros_linea`
A veces tenemos un equipo que se cuelga frecuentemente o que tiene errores extraños y que no podemos aislar. En estos casos hay que mirar con sospecha a la RAM, ya que es probable que sea la causa del problema. Soluciones como Memtest86+ son de sobra conocidas, pero, ¿y si no podemos arrancar con un disco de inicio para ejecutar Memtest? ¿Por ejemplo, en un servidor VPS?
Según la Wikipedia: La tecnología S.M.A.R.T. acrónimo de Self Monitoring Analysis and Reporting Technology consiste en la capacidad de detección de fallos del disco duro. La detección con anticipación de los fallos en la superficie permite al usuario el poder realizar una copia de su contenido, o reemplazar el disco, antes de que se produzca una pérdida de datos irrecuperable.
En Linux lo tenemos muy sencillo para monitorizar cómodamente nuestro disco. Lo primero, instalar el conjunto de herramientas SMART:
$ sudo apt-get install smartmontools
Y comprobar que nuestro disco es compatible y que tenemos SMART activado en la BIOS del equipo:
$ sudo smartctl -a /dev/sda
Este comando nos devolverá una larga lista de información que muestra los valores actuales de salud de nuestro disco. Por ahora sólo interesa que no devuelva un error de Device does not support SMART, en otra anotación trataré esta información y para qué nos sirve.
Si hemos obtenido la información, sin ese mensaje de error, es que el disco es compatible y tenemos SMART activado en la BIOS, así que pasamos al último paso: instalar un monitor que nos avise en caso de que se detecte la posibilidad de algún futuro problema en el disco. Haremos esto con smart-notifier, un pequeño programita que lee la información de smartmontools en el inicio del sistema y si detecta algún valor peligroso nos avisa.
$ sudo apt-get install smart-notifier
Para que smartmontools se ejecute al incio del sistema, descomentamos una línea en /etc/default/smartmontools:
$ sudo vi /etc/default/smartmontools start_smartd=yes
Y ya sólo nos quedaría añadir el ejecutable /usr/bin/smart-notifier para que se ejecute al iniciar nuestra sesión gráfica. Esto se hace de forma distinta en KDE, Gnome, Xfce... por lo que no lo anoto aquí.
Una vez añadido, cada vez que arranquemos el equipo se ejecutará el demonio smartd que monitorizará los datos de salud del disco duro, y smart-notifier nos avisará con una ventana en caso de detectar algún problema.
Para estar seguros del funcionamiento, nada mejor que hacer una prueba, editando /etc/smartd.conf y añadiendo el parámetro -M test a la línea DEVICESCAN dejando el resto de la línea igual, por ejemplo:
$ sudo vi /etc/smartd.conf DEVICESCAN -m root -d sat -M test -M exec /usr/share/smartmontools/smartd-runner
Al reiniciar el demonio smartd debería aparecernos un error de prueba:
$ sudo /etc/init.d/smartmontools restart
Para terminar, quitamos el parámetro -M test que acabamos de poner, reiniciamos de nuevo el demonio smartd y listo, ya podemos estar un poco más tranquilos al respecto de la pérdida de nuestros datos.
Supongamos un caso que, antes o después, nos pasará en algún servidor: la máquina muere y es preciso acceder a ella desde un sistema de rescate (un LiveCD por ejemplo). Una de las tareas imprescindibles en ese escenario es hacer un backup de los datos antes de iniciar cualquier actuación de reparación. Los archivos se pueden respaldar sin problemas, pero, ¿qué hay de las bases de datos?
Veamos cómo hacer un mysqldump de nuestras bases de datos desde un entorno chroot en Ubuntu Server.
Lo primero es, una vez arrancado el sistema de rescate, montar el directorio de sistema de nuestro servidor, por ejemplo:
$ mkdir /mnt/sistemax $ sudo mount /dev/sda1 /mnt/sistema1
Donde sda1 es el directorio raíz de la instalación que no funciona. Si hubiera más particiones que nos interesen para el backup, se montan de la misma forma.
A continuación, y para que el chroot funcione correctamente, es preciso exportar ciertos directorios de sistema que necesitará el kernel para arrancar servicios en el entorno chroot:
$ sudo mount ‐‐bind /dev /mnt/sistema1/dev $ sudo mount ‐‐bind /proc /mnt/sistema1/proc $ sudo mount ‐‐bind /sys /mnt/sistema1/sys
Y ya podemos arrancar el entorno chroot:
$ sudo chroot /mnt/sistema1
Desde hace algunas versiones (Karmic Koala, creo), Ubuntu Server usa upstart para gestionar los servicios y demonios. Los servicios que funcionan bajo upstart no se pueden arrancar en un entorno chroot porque upstart funciona como un supervisor de servicios y los procesos dentro del entorno chroot no pueden comunicarse con el servicio upstart externo al chroot (Bug 430224). Esto causa que algunos paquetes, como MySQL, que ahora usan upstart en lugar de los clásicos scripts init no arrancarán en el entorno chroot. Para poder arrancar estos servicios, se debe configurar el entorno chroot para que /sbin/initctl apunte a /bin/true, con estos comandos:
$ sudo dpkg-divert --local --rename --add /sbin/initctl $ sudo ln -s /bin/true /sbin/initctl
Una vez hecho esto, ya podemos arrancar MySQL en modo seguro y hacer el dump de las bases de datos que debamos respaldar, dump que posteriormente copiaremos a un lugar seguro:
$ sudo mysqld_safe --skip-grant-tables --skip-networking & $ mysqldump unabasededatos > unabasededatos.sql
El Centro Nacional de Información Geográfica (CNIG) es la referencia en España en mapas, y OruxMaps es la referencia en gestión de rutas en Android (y además es producto nacional). Y usar los mapas del CNIG con OruxMaps es, afortunadamente, muy sencillo.
El ecosistema de las aplicaciones Ruby on Rails es bastante extenso, y puede generar problemas a la hora de mover la aplicación al servidor de producción o al actualizar el servidor. Rails ofrece una posibilidad: congelar la versión de una aplicación.
La base es muy simple: en una aplicación Rails, se usará la versión definida en RAILS_GEM_VERSION en config/environment.rb... salvo en el caso de que en el directorio /vendor de la aplicación exista un directorio /vendor/rails con el código del framework, en cuyo caso se usará este. Así, da igual la versión de Rails que exista en el servidor, la aplicación usará la versión incluida en su directorio /vendor.
¿Cómo congelamos la versión?
Todos sabemos lo importantes que son las copias de seguridad. Hay dos tipos de personas: los que ya han perdido sus datos y los que los van a perder; y tal. Que levante la mano el que tenga una política de backup correcta en su casa.
En mi caso, me puede la vagancia y el no querer gastar dinero en un NAS ni resultarme interesante un RAID1 por software. Así que, para mis datos uso una solución que si bien no es perfecta al menos me da una cierta tranquilidad. Tengo dos discos duros, de 500GB cada uno, de marca y modelo distintos y comprados con un cierto margen de varios meses. En el segundo tengo replicada la tabla de particiones del primero (se pude hacer de forma automática, pero es un momento hacerlo a mano con lápiz, papel y fdisk). Las particiones que tengo (sin contar swap) son simples:
aremesal@midgard:/mnt$ df -h S.archivos Tam. Usado Disp. % Uso Montado en /dev/sda1 76G 5,8G 66G 9% / /dev/sda5 384G 142G 225G 44% /home
Una vez o dos al mes, sincronizo ambos discos con rsync. Mis premisas son:
Así, cuando voy a hacer un backup, lo que hago es simplemente lo siguiente:
$ mount /dev/sdb1 /mnt/sdb1 $ sudo rsync -av --delete --exclude-from=/etc/lista_backup_exclude / /mnt/sdb1/ $ mount /dev/sdb5 /mnt/sdb5 $ sudo rsync -av --delete /home/ /mnt/sdb5/
En ambos rsync, la opción -a (--archive) combina el parámetro -r para que el recorra toda la estructura de directorios que le indiquemos, el -l para que copie enlaces simbólicos como enlaces simbólicos, la -p para que mantenga los permisos, la -t para que se mantenga la hora del fichero, la -g para que se mantenga el grupo, la -o para que se mantenga el propietario, la -D para que se mantengan los ficheros de dispositivo (sólo para root). Ni se mantienen los hard links (-H) ni las ACLs (-A) por defecto. En definitiva, con la opción -a obtenemos una copia exacta de una jerarquía de ficheros y directorios.
En el primer caso, además, uso una lista de exclusión, de forma que no me copie los directorios contenidos en dicha lista. Esta lista, en mi caso, es:
- /home/ - /home/** - /mnt/ - /mnt/** - /media/ - /media/** - /tmp/ - /tmp/** - /proc/ - /proc/** - /var/cache/apt/archives/ - /var/cache/apt/archives/** + *
Lo que esta lista significa es que excluya de la sincronización a cada directorio indicado, y a todo el contenido de dicho directorio (esto es el **). Al final, la última línea indica que incluya todo lo demás. Lo que excluyo es el directorio /home (se copia aparte), directorio temporal, /proc ya que se crea en tiempo de ejecución, /mnt ya que sino estaría copiado la propia copia, /media para no copiar posibles DVD o pendrives montados, y el directorio de caché de Apt, donde puede haber paquetes descargados en la última actualización.
Esta web
http://alvaroremesal.net
, su contenido, texto e imágenes está licenciado bajo una
Licencia Creative Commons Reconocimiento-Compartir bajo la misma licencia 3.0 España.
