• Solucionar burn in en monitor LCD

    Por domingo, 11 diciembre, 2016 0 Permalink

    ¡Hola, buenas! En este post vamos a ver como solucionar un burn in en un monitor LCD. Créase o no, no es un problema exclusivo de monitores CRT y aún existe este problema hasta en los últimos monitores del mercado.

    Hace unas semanas apareció inesperadamente en mi monitor una línea brillante de aproximadamente medio centímetro de ancho.

    Burn in en monitor benq
    Linea  por burn in

    Este fallo es debido a una sobrecarga de voltaje en algunos pixeles, en los monitores LCD no es persistente y tiene arreglo, excepto que se trate de una avería de hardware. En mi caso, la sobrecarga vino por una línea negra de alto contraste del Firefox. En los monitores LCD el color de reposo es el blanco puro, mientras que el color negro es el que más voltaje utiliza.

    La solución pasa por dejar la pantalla con el color blanco durante varias noches o, mejor aún, una pantalla que vaya cambiando los colores blanco y negro. Ayuda que el monitor esté en la frecuencia más baja posible.

    Hay algunas aplicaciones de pago para solucionar el burn in, pero hay otro modo de conseguir lo mismo. Durante toda esta semana, he estado utilizando un vídeo en Youtube de diez horas de duración y, tras varias noches y algún día entero, la línea que se ve en la foto de arriba ha desaparecido por completo.

    Para un monitor 16:9, este es el vídeo:

    Para prevenir que vuelva a tener otro burn in como éste, es tan sencillo como no dejar las ventanas de los programas abiertas si no hay necesidad de hacerlo y activar el salvapantallas más a menudo.

    Probad esto antes de llevarlo a reparar.

    Un saludo

  • Automatización de backups de WordPress

    Por jueves, 1 diciembre, 2016 0 , Permalink

    En este post vamos a seguir con la serie automatización para ver como realizar un backup de la instalación de WordPress. Conviene realizar backups de manera periódica, por lo que seria conveniente planificar con qué frecuencia se realizan, para automatizar también la ejecución del script de backup. Quiero recordar que estos scripts de la serie van en conjunto, es decir, que hay que tener instalado WordPress con el script del primer post de esta serie, que podéis leer aquí.

    La copia de seguridad será almacenada en un directorio de un servidor remoto, los cuales serán definidos en un archivo junto con otros parámetros.

    Usaremos algunas funciones que ya fueron explicadas en el post sobre el script de la desinstalación con los mismo objetivos:

    • iferror. Utilizada para detener la ejecución el script con un mensaje diciendo en qué parte de la ejecución ha fallado
    • read_root_path.  Utilizada para definir el directorio root de la instalación que respaldamos.
    • get_config_parameters. Utilizada para definir los parámetros para acceder a la base de dato.

    Para leer estas tres funciones podéis consultar el post de la desinstalación o visitar mi repositorio en Github desde aquí.

    Para la ejecución de este script necesitaremos un archivo con los siguientes parámetros:

    • Nombre de dominio de la instalación a respaldar.
    • Usuario remoto de backup. El usuario que tendrá permisos para escribir en el directorio de almacenamiento.
    • IP o FQDN del host remoto.
    • Directorio remoto para almacenar la copia de respaldo, que será una copia con fecha de la base de datos y archivos.
    domain=torestore.org
    backup_user=gustavo	
    backup_host=192.168.1.254
    backup_remote_dir=backup

    La primera función específica de este script es mysql_dump. Esta función utiliza los datos leídos con get_config_parameters para acceder a la base de datos con las tablas de la instalación de WordPress y envía una copia al directorio definido en el archivo de parámetros mediante una conexión ssh. El script crea un directorio con nombre igual al nombre de dominio de la instalación en el host remoto de backups:

    # function: mysql_dump
    # Produces a backup of full database in a tar.gz file
    
    function mysql_dump {
      ssh $backup_user@$backup_host "mkdir -p $backup_remote_dir/$domain"
      mysqldump --user $db_user --password=$db_password  \
      $db_name | gzip -c | ssh $backup_user@$backup_host "cat > \
      $backup_remote_dir/$domain/$(date +%Y%m%d)$db_name.sql.gz" \
      || iferror "Backup for database named $db_name has failed" \
      && wp_simple_backup_files;
    }

    La función wp_simple_backup_files realiza una copia de todo el directorio raíz de WordPress. «Todo» quiere decir que también hace un respaldo del directorio upload, dónde están las imágenes y otros archivos que pueden tener un gran peso. Los archivos son comprimidos y empaquetados con una nomenclatura que incluye la fecha en el nombre del archivo. La copia será enviada con el comando scp al host remoto:

    # function: wp_simple_backup_files
    # Produces a tar.gz to a remote host
    
    function wp_simple_backup_files {
      wp_targz="/tmp/$(date +%Y%m%d)$domain.tar.gz";
      if [[ -d $wp_path ]]; then
        tar czfp $wp_targz -C $wp_path . \
        && scp $wp_targz $backup_user@$backup_host:$backup_remote_dir/$domain/. \
        && rm -f $targz_file \
        || iferror "Backup file not sended to $backup_host"
      fi
    }

    La función nginx_site_backup hace una copia del servidor virtual de Nginx que usa la instalación de WordPress y la envía al directorio del backup:

    # function: nginx_site_backup
    # Produces a file with Nginx configurarion of the given server
    
    function nginx_site_backup {
      if [[ -e /etc/nginx/sites-enabled/$domain.conf ]]; then
        scp /etc/nginx/sites-enabled/$domain.conf \
        $backup_user@$backup_host:$backup_remote_dir/$domain/.
      fi
    }
    

    Como en scripts anteriores de la serie, el script de backup también comprueba que lo haya ejecutado el usuario root y que exista el archivo de parámetros:

    if [[ -e ./params/backup.conf ]];then
     		source ./params/backup.conf;
    else
        iferror "First you need configure parameters";
    fi
    
    if [ "$(id -u)" != "0" ]; then
      echo "This script must be run as root" 1>&2
      exit 1
    fi

    La funcion start, que es llamada para iniciar el programa:

    function start {
     read_root_path \
     && get_config_parameters \
     && mysql_dump \
     && nginx_site_backup
    }
    

    El script que he explicado en este post puede lanzarse desde cron para planificar la ejecución de las copias de respaldo. En el siguiente post veremos como restaurar la copia de seguridad. Al haber copiado el blog entero y la configuración servidor virtual, para restaurar la copia no habrá que instalar necesariamente otro WordPress y ambos scripts pueden ser muy útiles para realizar migraciones. Aunque todo eso lo veremos en el próximo post.

    Hasta entonces.

  • Automatización de la desinstalación de WordPress

    Por miércoles, 23 noviembre, 2016 0 , Permalink

    El segundo post de la serie sobre automatización trata sobre la desinstalación de un servidor WordPress que fue instalado con el script que explicamos en el post anterior de la serie. Con otras instalaciones es muy probable que este script de desinstalación no funcione sin modificaciones.

    El script de desinstalación no utiliza ningún archivo de configuración. Tan solo requiere un parámetro al lanzar el script, el cual debe ser el nombre del dominio del servidor que vamos a desinstalar. El script funciona en local.

    Como en el script anterior, tenemos las función iferror que, en caso de que sea llamada, sale de script con un mensaje.

    # function: iferror
    # produces an exit code 1 with message
    function iferror {
      if [[ $? -eq 1 ]]; then
        echo $1; exit 1;
      fi
    }

    Justo al iniciarse la ejecución, comprueba que el administrador haya introducido un parámetro.

    if [[ $# -eq 0 ]]; then
      echo "You must enter a FQDN as parameter. \
      Example: ./uninstall_wordpress.sh yourdomain.org"; exit 1;
    else
      domain=$1
    fi

    Esta comprobación aún requiere mejoras. Si el parámetro no es un nombre de dominio, el script terminará su ejecución antes de hacer modificación alguna, cuando no encuentre el dominio para ser desinstalado.

    A continuación, comprueba que el usuario que ha lanzado el script sea root.

    if [ "$(id -u)" != "0" ]; then
      echo "This script must be run as root" 1>&2
      exit 1
    fi

    A partir del nombre de dominio introducido como parámetro, el script encuentra el directorio dónde WordPress está instalado:

    # function: read_root_path
    # Read root path from Nginx server
    
    function read_root_path {
        if [[ -e /etc/nginx/sites-available/$domain.conf ]];then
              wp_path=$(grep -E "root.*$domain" /etc/nginx/sites-available/$domain.conf \
              | awk -F' ' '{print substr($2, 1, length($2)-1)}');
        else
             iferror "Site is not available";
        fi
    }
    

    Para ello lee el archivo de configuración del servidor en Ngnix y almacena el directorio en la variable wp_path

    Conociendo la ruta en la que se encuentra la instalación, es posible leer el archivo wp-config.php adecuado.

    # function: get_config_parameters
    # Read wp-config.php to get parameters needed to uninstall
    
    function get_config_parameters {
      wp_cnf=$wp_path/wp-config.php
    
      db_name=$(grep "DB_NAME" $wp_cnf | awk -F"'" '{print $4}')
      db_user=$(grep "DB_USER" $wp_cnf | awk -F"'" '{print $4}')
      db_password=$(grep "DB_PASSWORD" $wp_cnf | awk -F"'" '{print $4}')
      db_host=$(grep "DB_PASSWORD" $wp_cnf | awk -F"'" '{print $4}')
      if [[ $db_host == '' ]]; then
          db_host=localhost
      fi
    }

    Define las variables con el nombre de la base de datos, junto usuario y password de la misma, además del host en la que está funcionando.

    Con esos datos, podemos proceder. Siguiente paso, el script elimina la base de datos:

    # function: mysql_remove_database
    # Remove database from mysql
    
    function mysql_remove_database {
       SQL="drop database if exists $db_name;";
       mysql -u$db_user -p$db_password -e "$SQL" || iferror "Database not removed";
    }
    

    Ejecuta una sentencia Mysql con las variables que hemos definido antes. Esta función eliminará la base de datos y no será posible recuperarla sin no hay alguna copia en algún otro lugar. En el siguiente post de la serie, publicaré un script para automatizar backups de todo el sitio y enviarlos a un host remoto.

    La siguiente función, elimina el directorio raíz del sitio de WordPress:

    # function: remove_root_path
    # remove path of WordPress installation
    
    function remove_root_path {
      if [[ -d $wp_path ]]; then
        rm -rf $wp_path;
      else
        iferror "Root path does not exists"
      fi
    }

    La siguientes dos funciones, eliminan el servidor de Nginx. La primera de ellas deshabilita el servidor borrando el enlace simbólico; la segunda, elimina la disponibilidad del servidor.

    # function: nginx_disable_site
    # disable site from sites-enabled
    
    function nginx_disable_site {
      if [[ -e /etc/nginx/sites-enabled/$domain.conf ]]; then
          rm -f /etc/nginx/sites-enabled/$domain.conf;
          systemctl reload nginx;
      else
          iferror "Site is not enabled"
      fi
    }
    
    #function nginx_remove_site
    # remove server from sites-available
    
    function nginx_remove_site {
      if [[ -e /etc/nginx/sites-available/$domain.conf ]]; then
          rm -f /etc/nginx/sites-available/$domain.conf;
      else
          iferror "Site is not available "
      fi
    }
    

    La función start ejecuta la funciones en serie.  Una función a las que llame esta función no se ejecuta si la función anterior no se ha ejecutado con éxito, a excepción de la primera de ellas.

    function start {
      read_root_path \
      && get_config_parameters \
      && mysql_remove_database \
      && remove_root_path \
      && nginx_disable_site \
      && nginx_remove_site
    }
    

    Por último, tan sólo hay que llamar a la función start para ejecutar todo el script.

    Todos los scripts de esta serie relacionados con WordPress están en mi github.

    Saludos 🙂

  • Automatización de la instalación de WordPress

    Por martes, 15 noviembre, 2016 0 , Permalink

    Éste será el primero de una serie de posts sobre automatización en varios lenguajes de scripting. En este post expongo una automatización para instalación de WordPress, con un backend de MariaDB y PHP 7.0, en una distribución Debian Jessie. En próximas entregas desgranaré scripts de desinstalación, backup y restauración de la instalación realizada con este script.

    Continuar Leyendo…

  • Testeo automático de conectividad en bash

    He creado el script de más abajo para comprobar la conectividad de varios servidores, siempre que haya una desconexión total entre cliente y servidor, es decir, si lo que ha caído es un host virtual y el dispositivo donde está el mismo sigue con funciones de red, se considiera que hay conectividad. En mi caso, tengo ejecutándose en el mismo servidor donde alojo el blog y estoy pensando en instalarlo en la Raspi que tengo en casa haciendo otras funciones de networking.

    El script envía un ping a los hosts que indiquemos en un archivo de texto. Si algun host no devuelve el ping, el script ejecuta el comando mail para enviar un email a los destinatarios para que realicen una comprobación manual. Si la máquina servidor tiene conectividad, no envia ningún email.

    Continuar Leyendo…

  • Como cambiar esquema de colores a Vim

    Por sábado, 17 agosto, 2013 0 , Permalink

    Vim es un clásico imperecedero en muchos sistemas operativos. A mí me resulta muy útil para editar archivos de configuración en servidores, ya que al menos Vi esta en todos los servidores Unix/Linux, y es potentísimo. Uno de las primeros pasos que me gusta dar es configurar el esquema de colores para la consola. Hay multitud de esquemas disponibles en la red para la descarga, por ejemplo, en Vivify.

    Continuar Leyendo…

  • Transferencia multicast de archivos en una LAN

    Por lunes, 12 agosto, 2013 1 Permalink

    Una trasferencia multicast consiste en que la máquina origen de la comunicación envía datos a través de la LAN, que reciben varios equipos de manera simultánea y todos ellos se identifican como destinatarios del mensaje, a diferencia de las transmisiones unicast, en las que un sólo dispositivo de la red es el destinatario del mensaje enviado.

    La transmisiones multicast tampoco son broadcast. Las transmisiones broadcast son recibidas por todos los dispositivos de la red, mientras que la multicast van dirigidas a un grupo específico de dispositivos.

    Continuar Leyendo…