Linux

Revertir a una version anterior un paquete en Debian

root — Sat, 14 Jul 2018 20:10:45 +0000

Revertir a una version anterior un paquete en Debian

Sábado, Julio 14, 2018 - 22:10

Una de las diversiones de utilizar la versión Sid (inestable) de Debian, es actualizar paquetes. Cualquier cosa puede pasar.

Hoy tenia un rato libre y le he dado al apt upgrade a ver que pasaba. Lo que ha pasado es que VirtualBox ha dejado de funcionar, y no arranca las máquinas virtuales, con este error:

virtualbox: fails to start vm (VERR_LDRELF_RELOCATION_NOT_SUPPORTED)

Después de revisar el hilo del error, parece que lo mas rápido es bajar de versión el paquete, ya que la última instalada es la 5.2.14-dfsg-4, por lo que parece, la versión anterior (5.2.14-dfsg-3 en este caso) parece que funciona bien.

Así que voy a intertar explicaros como he hecho para bajar el paquete de versión, sin tener que bajar e instalar a mano el paquete, sino usando los repos de Debian.

Primero, vamos a snapshot.debian.org y buscamos el paquete que nos da problemas, en mi caso virtualbox. Podemos usar la caja de búsqueda o rebuscar a mano por el índice, lo que os de mas morbo.

Hay que seleccionar la versión que buscamos, y debajo del nombre del paquete vereis algo como esto:

Seen in debian on 2018-07-12 14:59:27 in /pool/contrib/v/virtualbox.

Al pinchar en el enlace, llegamos a una dirección de este tipo:

http://snapshot.debian.org/archive/debian/20180712T211510Z/pool/contrib…

Una vez encontrada esta URL, vamos a usarla configurando una nueva fuente para Apt:

cd /etc/apt/sources.list.d

Y creamos un nuevo archivo de fuente:

sudo vi virtualbox.list

Tenemos que usar parte de la URL de antes, sin poner la parte final. En mi caso añado la versión unstable, y el contrib, porque el paquete es de contrib. Quedaría algo así:

deb https://snapshot.debian.org/archive/debian/20180712T211510Z/ unstable contrib

Guardamos el archivo y actualizamos el Apt para que incluya el nuevo índice:

apt update

Una vez termine de actualizar, podemos sacar la lista de versiones disponibles del paquete que necesitamos:

apt-cache showpkg virtualbox

E instalar la que necesitemos, usando el nombre de la version en el mismo comando de Apt:

apt install virtualbox=5.2.14-dfsg-3

En mi caso, el paquete virtualbox tenía un paquete recomendado llamado virtualbox-qt, que Apt muy amablemente me indicó al tratar de instalarlo, así que decidí bajarlo de versión también por si acaso:

apt install virtualbox=5.2.14-dfsg-3 virtualbox-qt=5.2.14-dfsg-3

Con esto se actualizaron los paquetes necesarios para esas versiones, y encima tuve la suerte de que VirtualBox volvió a funcionar perfectamente. Ahora veremos que pasa cuando salga la version siguiente (5.2.14-dfsg-3) y quiera actualizarlo...

Ya os contaré.

Añadir nuevo comentario

Desarrollo Drupal con Sublime Editor 3

root — Sat, 02 Sep 2017 13:20:09 +0000

Desarrollo Drupal con Sublime Editor 3

Sábado, Septiembre 2, 2017 - 15:20

Sublime Text lleva siendo mi editor preferido para trabajar desde hace un montón de años. Es muy ligero, me gustan los atajos de teclado, muy configurable y tiene un sistema de plugins que le da mucha potencia.

La versión 3 lleva en beta por lo menos desde 2013, y todo el tiempo que llevo usándola no he tenido problemas.

Quería escribir un articulo con mi configuración personal que utilizo para trabajar en proyectos Drupal, y que aporta funcionalidad y facilita la vida. Como resumen:

Revisión de código al momento: Marcado de estándares de Drupal, errores de sintaxis, etc.
Marcado de modificaciones en Git: Cada cambio que hacemos en un fichero lo vemos resaltado, muy útil para saber de un vistazo las modificaciones que hemos hecho al archivo.

Lo primero de todo es instalar el editor. Estamos de suerte porque tenemos paquetes binarios empaquetados para unas cuantas distribuciones Linux. Este es el enlace de descargas:

https://www.sublimetext.com/docs/3/linux_repositories.html

Package Control

La primera extensión que vamos a instalar es básica para sacarle buen partido a este editor: Package Control. Este plugin nos va a ayudar a instalar fácilmente otros plugins, básicamente. Para instalar paquete Package Control, vayamos a su pagina:

https://packagecontrol.io/installation

Una vez instalado podremos utilizar CTRL + SHIFT + p para abrir una consola donde podremos ejecutar comandos.

Instalar Sublime linter

Sublime Linter es un plugin genérico que sirve de base para otros 'linters' mas específicos (PHP, Java, SASS, etc.) que necesitamos instalar primero. Estos plugins nos ayudarán a mantener nuestro código limpio y seguir los estándares del lenguaje en el que estamos programando, de forma que nos van avisando si cometemos errores de formato o sintaxis, a media que escribimos el código. Lint significa pelusa en ingles, y eso es justo lo que hacen estos plugins, quitar pelusa.

Instalarlo es sencillo una vez tenemos el package manager instalado:

Abrimos comandos con CTRL+SHIFT+p
Teclear install y ENTER
buscamos el paquete SublimeLinter
ENTER otra vez

Y ya lo tenemos. Seguimos adelante.

Instalar PHP_CodeSniffer (phpcs)

PHP_CodeSniffer es la herramienta que nos va a ayudar a identificar cualquier violación de los estándares de PHP. Es un ejecutable que debemos instalar en nuestro sistema, por lo que necesitamos tenerlo en nuestra variable PATH. La ultima versión a fecha de escribir este articulo es la 3.0.2, pero para hacerlo funcionar con el modulo Coder de Drupal necesitamos quedarnos con la 2.7.0. Cuidado con esto que puede cambiar en el futuro, así que revisa las versiones antes de instalar.

La forma mas sencilla de instalarlo es usando pear:

sudo pear install PHP_CodeSniffer-2.7.0

Con esto tendremos dos ejecutables:

phpcs: el "code sniffer" para inspeccionar el código y reportar errores.
phpcbf: el "Code Beautifier and Fixer", que se utiliza para realizar correcciones automáticas en el código.

Añadir los estándares de Drupal a phpcs. Módulo Coder

Ahora que ya tenemos instalado phpcs, necesitamos incluirle las definiciones de los estándares de código de Drupal. Para esto instalaremos el módulo Coder de Drupal. Vayamos a la carpeta donde lo queramos dejar instalado, que puede ser cualquier sitio, no hace falta que sea dentro de un proyecto o sitio Drupal. Eso si, antes necesitaremos tener instalado Drush. Por ejemplo:

cd /path/para/coder

drush dl coder

Con esto deberíamos haber instalado la versión 8.x que es la última. Ahora ya podemos decir a phpcs donde están estos estándares de Drupal:

sudo phpcs --config-set installed_paths /path/para/coder/coder/coder_sniffer

Y ahora ya podemos ejecutar phpcs para revisar cualquier archivo de código Drupal, así:

phpcs --standard=Drupal ruta/al/archivo/a/revisar

Volvemos a Sublime: SublimeLinter-phpcs

Ahora que ya tenemos phpcs funcionando nos volvemos a Sublime para instalar el plugin que vamos usar mientras picamos código, SublimeLinter-phpcs. Para instalarlo:

Abrimos comandos con CTRL+SHIFT+p
Teclear install y ENTER
buscamos el paquete SublimeLinter-phpcs
ENTER otra vez

Una vez instalado el paquete, seguimos las instrucciones de configuración que nos detallan. Al final, si vamos a Preferences / Package settings / Sublime linter / User, debemos tener una sección en la configuración parecida a esto:

        "linters": {
            "phpcs": {
                "@disable": false,
                "args": [],
                "excludes": [],
                "standard": "Drupal"
            }
        },

Cuando funcione, Sublime nos ira mostrando los errores que tengamos en el código de esta manera:

Cambios en Git: GitGutter

Por ultimo, otro pequeño plugin que nos mostrará los cambios que hayamos hecho al archivo en local, desde el último commit de Git. Es muy útil porque de un vistazo nos deja ver las lineas que hemos añadido, modificado o borrado del fichero. Si lo combinamos con cualquiera de los otros plugins de Git para Sublime, nos puede ayudar bastante para tener claro que estamos tocando.

Instalarlo es sencillo, como los anteriores:

Abrimos comandos con CTRL+SHIFT+p
Teclear install y ENTER
buscamos el paquete gitgutter
ENTER otra vez

Una vez este funcionando, podremos ir viendo las modificaciones que vayamos haciendo en el fichero en la parte de la izquierda, con diferentes símbolos para líneas nuevas o modificadas, como se puede ver en la siguiente imagen.

Preferencias generales de Sublime

Para terminar os dejo aquí las preferencias básicas de Sublime que utilizo con proyectos Drupal

{
  "bold_folder_labels": true,
  "caret_style": "wide",
  "default_line_ending": "unix",
  "draw_white_space": "all",
  "ensure_newline_at_eof_on_save": true,
  "fade_fold_buttons": false,
  "fallback_encoding": "UTF-8",
  "find_selected_text": true,
  "font_options":
  [
      "subpixel_antialias"
  ],
  "highlight_line": true,
  "line_padding_bottom": 1,
  "open_files_in_new_window": false,
  "rulers":
  [
      80
  ],
  "shift_tab_unindent": true,
  "soda_classic_tabs": true,
  "tab_size": 2,
  "theme": "Flatland Dark.sublime-theme",
  "translate_tabs_to_spaces": true,
  "trim_automatic_white_space": true,
  "trim_trailing_white_space_on_save": true,
  "use_tab_stops": true,
  "word_separators": "./\\()\"'-:,.;<>~!@#%^&*|+=[]{}`~?",
}

Referencias

Añadir nuevo comentario

HTTPS con un certificado gratuito de letsencrypt.org y Certbot

root — Mon, 27 Feb 2017 21:03:16 +0000

HTTPS con un certificado gratuito de letsencrypt.org y Certbot

Lunes, Febrero 27, 2017 - 22:03

Let’s Encrypt es una autoridad certificadora (CA) abierta, gratuita, y libre. Llevan funcionando menos de un año, desde 2016, y se puede decir que es un servicio público, dirigido a promover y facilitar la obtención y configuración de certificados de seguridad para la web. Lo que ofrecen son certificados X.509 por dominio que podemos usar para TLS.

https://letsencrypt.org/

Hay varias organizaciones involucradas en el proyecto, siendo la principal la Internet Security Research Group (ISRG), junto a otras como Linux Foundation o Mozilla Foundation, pero también gigantes como Akamai o Cisco Systems. Es decir, que hay gente grande detrás, y el proyecto es bastante interesante, esperemos que dure.

Hasta ahora conseguir un certificado de seguridad para configurar HTTPS como es debido era bastante engorroso, además de que solía ser bastante caro. Últimamente los precios habían comenzado a bajar, pero ahora podemos conseguir un certificado propio por la cara, y con una instalación muy sencilla.

La principal ventaja del servicio se basa en la automatización de todo el proceso. El objetivo es configurar un servidor HTTPS y obtener un certificado de confianza para los navegadores sin intervención humana. Y dejarme deciros que me ha funcionado de verdad, y a la primera.

Esta automatización es la clave de todo el asunto, primero porque los certificados que nos ofrecen solamente son válidos por 90 días, lo que nos va a obligar a configurar la renovación de forma automática si no queremos estar cada tres meses renovando el certificado de forma manual.

Para esto han ideado un protocolo llamado ACME (Automated Certificate Management Environment), y el truco consiste en instalar un agente que se encargue de realizar automáticamente la petición y renovación del certificado, validando el solito nuestros dominios. Tenemos unos cuantos disponibles, pero el que recomiendan desde letsencrypt.org es Certbot:

https://certbot.eff.org

Certbot esta empaquetado en los repos de Debian, pero deberemos usar el repositorio de backports. Para ello basta con incluir una línea en nuestro fichero /etc/apt/sources.list. Si estáis usando Jessie (Debian 8) será:

deb http://ftp.debian.org/debian jessie-backports main

Después actualizamos:

apt-get update

Ahora ya podemos instalar el cliente de Certbot:

$ sudo apt-get install python-certbot-apache -t jessie-backports

Una vez instalado, ya podemos ejecutarlo, si estamos usando Apache, así:

$ certbot --apache

Y ya está. Lo juro. El instalador nos hará una serie de preguntas sobre los certificados que queremos instalar y listo. En mi caso tenia un Apache2 con varios VirtualHosts con diferentes nombres de dominio y alias, todos por el puerto 80. El instalador hizo solito todo esto:

Realizo una copia de cada fichero de configuración de VirtualHost, añadiendo -le-ssl.conf al nombre, y configuró en ellos el certificado.
En cada VirtualHost original, añadió una redirección automática a su versión de HTTPS
Configuró un servicio en Cron /etc/cron.d/certbot para realizar automáticamente la renovación de los certificados.
Reinicio el servidor Apache para cargar la nueva configuración.

Si no os hace mucha gracia que os toque la configuración, o tenéis algo realmente chungo montado, también podemos hacer que solamente consiga el certificado, y configurarlo nosotros a mano, así:

$ certbot --apache certonly

En mi caso, añadió las siguientes líneas a mis archivos de VirtualHost originales en el 80:

RewriteEngine on
RewriteCond %{SERVER_NAME} =xxxxx.com [OR]
RewriteCond %{SERVER_NAME} =www.xxxxx.com
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,QSA,R=permanent]

Los nuevos ficheros para SSL que creó Certbot son copias de los que yo tenía, en los que se añade la configuración del certificado:

SSLCertificateFile /etc/letsencrypt/live/xxxxxxx/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/xxxxxxxx/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf

Y este es el archivo que añade al Cron en /etc/cron.d/certbot para automatizar la renovación de los certificados:

# /etc/cron.d/certbot: crontab entries for the certbot package
#
# Upstream recommends attempting renewal twice a day
#
# Eventually, this will be an opportunity to validate certificates
# haven't been revoked, etc.  Renewal will only occur if expiration
# is within 30 days.
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

0 */12 * * * root test -x /usr/bin/certbot -a \! -d /run/systemd/system && perl -e 'sleep int(rand(3600))' && certbot -q renew

Podemos hacer una simulación del proceso de renovación de los certificados con este comando:

certbot renew --dry-run

Esto nos dará una idea de si funcionará o no cuando lo tenga que hacer el solo.

De momento, está funcionando perfectamente. Ya veremos cuando llegue la primera renovación...

Referencias

Proceso de como funciona completo: https://letsencrypt.org/how-it-works/
Porque 90 días: https://letsencrypt.org/2015/11/09/why-90-days.html
Lista de clientes soportados: https://community.letsencrypt.org/t/list-of-client-implementations/2103
Let's Encrypt en Wikipedia
Debian backports
How to install Certbot

Añadir nuevo comentario

Servidor de Git privado con Gogs

root — Sun, 19 Feb 2017 00:45:21 +0000

Servidor de Git privado con Gogs

Domingo, Febrero 19, 2017 - 01:45

Linux

Git

Servicios

El único problema que tengo con GitHub es que en su versión gratuita todos los repos tienen que ser públicos. Si queremos tener repositorios privados tenemos que pasar por caja, y creo que son unos 7$ al mes, que me parece cojonudo, pero en mi caso necesito minimizar al máximo el coste de mis sistemas, principalmente porque no me da dinero.

Así que estuve investigando que alternativas tenia para instalar un servidor de Git privado. Lo primero que me vino a la cabeza fue GitLab, porque lo he utilizado durante una buena temporada en el trabajo con equipos relativamente grandes y nos ha dado muy buen resultado. En mi actual empresa estamos usando Bitbucket de Atlasian, y prácticamente es lo mismo que teníamos con GitLab, pero al ser de pago no es una opción para mi.

Una vez decidido a instalar GitLab, el problema está cuando te pones a mirar los requisitos:

4GB de RAM es lo recomendado.
2GB de RAM + 2GB de swap, ya te dicen que va a ir como el culo
Se necesitan varios GB de espacio en disco solo para la instalación de GitLab

Demasiada caña para mi pobre servidor, y mas si pienso servir desde la misma máquina un par de sitios o algún otro servicio, necesitaba algo mas ligero pero que al menos molase (ya que estamos...).

Así que después de dar algunas vueltas e investigar un poco, acabé encontrando Gogs:

https://gogs.io/

Según ellos mismos, Gogs es:

Gogs is a painless self-hosted Git service.

Que viene a ser un servicio de Git que te alojas tu mismo e indoloro.

Y la verdad es que no ha sido nada doloroso, llevo ya varios meses usándolo y ha sido una gran opción, y es que fue muy sencillo de instalar, viene con un montón de funcionalidades de serie, y tiene una interfaz muy pulida y que es calcada a GitHub.

Entre las funcionalidades interesantes:

Open Source
Ligero, muy ligero. Esta ocupando menos de 500Mb en disco (con las sus fuentes y las de Go) y aun no lo he visto sobrecargar la máquina.
Gravatar (venga va...)
Pull request, funcionan igual que Github
Webhooks !! (esto ya es lo mas, pero no los he probado aún)
Notificaciones por correo
Soporta SSH, tanto para servir la aplicación como para los repos
Tickets para incidencias, sencillo pero útil.
Wiki para cada proyecto
Creación de cuentas de usuario: Con registro o manual
Permite desactivar el registro de usuarios
Permite configurar repositorios privados
Webhooks, espera esto ya lo había dicho, ¿no?

Instalación

La ayuda oficial para la instalación la podéis encontrar aquí (todo en inglés):

Instalación desde fuentes: https://gogs.io/docs/installation/install_from_source
Ejecución: https://gogs.io/docs/installation/configuration_and_run
Instalación avanzada: https://gogs.io/docs/advanced/configuration_for_source_builds
Instalación desde binarios: https://gogs.io/docs/installation/install_from_binary

La instalación oficial la están haciendo con Ngnix y postgresql. Yo lo monté tirando de un viejo Apache2 y MySQL que ya tenia corriendo. Voy a hacer una traducción de la instalación que son los pasos que yo he seguido, y luego pongo mis archivos de configuración. Y ojo, que estos pasos son para instalarlo desde el fuente, que es lo que hice yo.

Lo que queremos hacer es:

Servir ‘Gogs’ desde un dominio midominio.com, por ejemplo como git.midominio.com
Apache2 como servidor web
MySQL como servidor de base de datos

Primero creamos un usuario para que corra la aplicación:

$ sudo adduser --disabled-login --gecos 'Gogs' git

Descarga e instalación de Go

Vamos a instalar Go dentro del home del usuario que acabamos de crear para no interferir con ninguna otra versión de la distribución que usemos. Usaremos

/home/git/local/go

Creamos un directorio:

$ sudo su - git
$ cd ~
$ mkdir local

Bajamos la versión disponible:

$ wget https://storage.googleapis.com/golang/go1.7.3.linux-amd64.tar.gz
$ tar -C /home/git/local -xzf go1.7.3.linux-amd64.tar.gz

Añadimos unas cuantas rutas al fichero bashrc de nuestro usuario git:

$ sudo su - git
$ cd ~
$ echo 'export GOROOT=$HOME/local/go' >> $HOME/.bashrc
$ echo 'export GOPATH=$HOME/go' >> $HOME/.bashrc
$ echo 'export PATH=$PATH:$GOROOT/bin:$GOPATH/bin' >> $HOME/.bashrc
$ source $HOME/.bashrc

Instalar Gogs

La forma rápida de instalar Gogs parece ser esta:

$ go get -u github.com/gogits/gogs 
$ cd $GOPATH/src/github.com/gogits/gogs 
$ go build

Y una vez compilado, podemos probarlo con:

$ cd $GOPATH/src/github.com/gogits/gogs
$ ./gogs web

Configuración

La configuración por defecto está en conf/app.ini pero no vamos a editar ese fichero. En lugar de eso Gogs nos permite crear una copia que será donde pondremos nuestras modificaciones. Primero vamos a crear unos directorios:

mkdir -p $GOPATH/src/github.com/gogits/gogs/custom/conf
mkdir -p ~/gogs-repositories
sudo mkdir -p /var/log/gogs
sudo chown git:git /var/log/gogs

Hacemos una copia del fichero de configuración original, en donde haremos nuestros cambios:

cd $GOPATH/src/github.com/gogits/gogs
cp conf/app.ini custom/conf/

En teoría en nuestro fichero de configuración 'custom' solamente deberíamos tener la configuración especifica que necesitemos. Es decir, que podemos borrar todo lo que se quede por defecto. La principal razón de esto es que cuando actualicemos la versión de Gogs, nuestra configuración no se modificará, ya que tienen un .gitignore para este fichero local. Este es el fichero que yo tengo:

; Change it if you run locally
RUN_USER = git
; Either "dev", "prod" or "test", default is "dev"
RUN_MODE = prod

[repository]
ROOT                      = /home/git/gogs-repositories

[server]
PROTOCOL               = http
DOMAIN                 = git.midominio.com
ROOT_URL               = http://git.midominio.com/
HTTP_ADDR              = 0.0.0.0
HTTP_PORT              = 3000

[database]
; Either "mysql", "postgres" or "sqlite3", it's your choice
DB_TYPE  = mysql
HOST     = 127.0.0.1:3306
NAME     = gogs
USER     = gogs
PASSWD   = **CONTRASEÑA**

[admin]

[security]
INSTALL_LOCK                      = true
; !!CHANGE THIS TO KEEP YOUR USER DATA SAFE!!

#@FDEWREWR&*(
SECRET_KEY                        = *KEY*

; Auto-login remember days
LOGIN_REMEMBER_DAYS               = 7
COOKIE_USERNAME                   = gogs_awesome
COOKIE_REMEMBER_NAME              = gogs_incredible
; Reverse proxy authentication header name of user name
REVERSE_PROXY_AUTHENTICATION_USER = X-WEBAUTH-USER

[service]
ACTIVE_CODE_LIVE_MINUTES               = 180
RESET_PASSWD_CODE_LIVE_MINUTES         = 180
; User need to confirm e-mail for registration
REGISTER_EMAIL_CONFIRM                 = false
; Does not allow register and admin create account only
DISABLE_REGISTRATION                   = true
; User must sign in to view anything.
REQUIRE_SIGNIN_VIEW                    = false
; Mail notification
ENABLE_NOTIFY_MAIL                     = false

[log]
ROOT_PATH  = /home/git/go/src/github.com/gogits/gogs/log
; Either "console", "file", "conn", "smtp" or "database", default is "console"
; Use comma to separate multiple modes, e.g. "console, file"
MODE = file
; Buffer length of channel, keep it as it is if you don't know what it is.
BUFFER_LEN = 10000
; Either "Trace", "Debug", "Info", "Warn", "Error", "Critical", default is "Trace"
LEVEL = Info

Configurar Apache2 con Gogs

Si quereis usar Nginx en lugar de Apache, la ayuda oficial tiene la info necesaria. En Debian podemos instalar Apache2 si no lo tenemos ya:

sudo apt-get install apache2

La instalación de Gogs que acabamos de hacer corre en el puerto 3000 por defecto. Lo que queremos hacer es utilizar un servidor web como proxy para poder servir Gogs desde el puerto 80, como un subdominio de nuestro dominio, por ejemplo en este caso:

http://git.midominio.com

La mejor forma de hacer esto es crear un fichero de configuración para hacer un VirtualHost y usar mod_proxy para poder servir Gogs en el puerto 80 con Apache.

vi /etc/apache2/sites-available/080-gogs.conf

El contenido del fichero puede ser tan simple como esto:

<VirtualHost *:80>
  ServerName git.midominio.com

  ProxyPreserveHost On
  ProxyPass        / http://localhost:3000/
  ProxyPassReverse / http://localhost:3000/

  ErrorLog ${APACHE_LOG_DIR}/gogs-error.log
  CustomLog ${APACHE_LOG_DIR}/gogs-access.log combined

</VirtualHost>

El nombre del dominio que usemos aqui será el mismo que pondremos en la configuración de Gogs. Aún tenemos que activar este VirtualHost:

ln -s /etc/apache2/sites-available/080-gogs.conf /etc/apache2/sites-enabled/

Ahora activaremos el módulo mod_proxy de Apache. Podemos probar con a2enmod:

$ sudo a2enmod proxy

Esto debería crear los dos ficheros necesarios dentro de /etc/apache2/mods-enabled/ : proxy.conf y proxy.load

Reiniciar Apache y a correr. Con suerte no tendreis ningún error.

$ sudo service apache2 restart

Configurar MySQL

No voy a entrar en detalles sobre la configuración inicial de MySQL, porque eso daría para un libro entero. En principio bastará con crear una base de datos nueva y asignar todos los permisos a un usuario para Gogs:

CREATE DATABASE gogs CHARACTER SET utf8 COLLATE utf8_general_ci;
GRANT ALL PRIVILEGES ON gogs.* To 'gogs'@'localhost' IDENTIFIED BY 'password';

Lo suyo sería ahora verificar la conexión a la nueva base de datos para estar seguros de que funciona correctamente, por ejemplo, desde la linea de comandos:

mysql --user=gogs --password=password --host=localhost gogs

Ejecutar el instalador

Llegado este punto deberíamos tener todo lo necesario para arrancar el dichoso Gogs. Lo arrancamos manualmente con:

$ cd $GOPATH/src/github.com/gogits/gogs
$ ./gogs web

Si ahora usamos un navegador para acceder a la dirección que hayamos configurado en nuestro Apache, deberiamos acceder a la primera pantalla del instalador, que nos guiará por la configuración básica. En nuestro ejemplo seria:

http://git.midominio.com

Añadir Gogs a init.d

Llegados a este punto todo deberia estar funcionando, sin embargo necesitamos arrancar Gogs a mano. Lo que necesitamos es poder levantar y parar Gogs como un servicio mas de nuestra máquina, y además, que este arranque automaticamente al levantar o reiniciar el servidor.

Para esto los chavales de Gogs nos han preparado una plantilla que nos facilitará mucho las cosas (para Debian / Ubuntu). Esta aqui:

$GOPATH/src/github.com/gogits/gogs/scripts/init/debian/gogs

La copiamos al directorio de init.d:

$ sudo cp $GOPATH/src/github.com/gogits/gogs/scripts/init/debian/gogs /etc/init.d/gogs

Y ahora modificamos un par de cosas. Editaremos las dos primeras lineas:

# Required-Start:    $syslog $network
# Required-Stop:     $syslog

De esta manera

# Required-Start:    $syslog $network $local_fs apache2 mysql
# Required-Stop:     $syslog $local_fs

Y nos aseguramos de que la variable WORKINGDIR apunte al directorio correcto:

WORKINGDIR=/home/git/go/src/github.com/gogits/gogs

El script necesita permisos de ejecución, y lo añadimos a la configuración de inicio:

$ sudo chmod ug+x /etc/init.d/gogs
$ sudo update-rc.d gogs defaults 30 70

Ahora podemos probar nuestra configuración y levantar el servicio gogs:

$ sudo service gogs start

Y conectar con un navegador a la URL que hemos configurado

http://git.midominio.com

Listo, espero que disfrutéis tanto como yo montando este pollo. Ahora ya nadie podrá ver los WTF que tenéis en vuestro código.

Añadir nuevo comentario

Problemas con Baloo en KDE4 en Debian Sid

root — Mon, 19 Oct 2015 10:20:25 +0000

Problemas con Baloo en KDE4 en Debian Sid

Lunes, Octubre 19, 2015 - 12:20

Linux

Debian

Sid

Con las últimas actualizaciones el indexador de Baloo se esta volviendo loco y se lleva la CPU como un salvaje.

Como no se puede desactivar con un servicio o por medio del /etc/init.d, y no quería que siguiese activo, he estado buscando como desactivarlo. Al final lo que he hecho es editar el fichero de configuración

$HOME/.kde/share/config/baloofilerc

y añadir esto:

Indexing-Enabled=false

Después maté el proceso baloo_file_extractor con un kill y se acabó el problema.

En este hilo de los foros de Ubuntu teneis mas info.

Añadir nuevo comentario

Instalar compilador de less en Debian

root — Fri, 02 Oct 2015 23:24:29 +0000

Instalar compilador de less en Debian

Sábado, Octubre 3, 2015 - 01:24

Linux

Debian

less

Primero vamos a probar la versión rápida y sencilla, que es con el paquete de Debian, que instalamos como root:

# apt-get install node-less

Esto nos instalará el paquete principal de node.js y el compilador de less. Ahora ya podemos probar el compilador, con salida por stdout:

$ lessc styles.less

O con salida a un fichero

$ lessc styles.less > styles.css

Al ser un paquete de Debian, es posible que esta versión no este muy actualizada. En mi caso en el momento de instalarlo la versión que ha traido es esta (en Debian Sid):

$ lessc --version
lessc 1.6.3 (LESS Compiler) [JavaScript]

Si queremos tirar de una versión mas actualizada, es mejor instalarlo de otra manera, que es con el gestor de paquetes de node.js: npm. Para ello, lo instalamos tirando del paquete de Debian:

# apt-get install npm

Y después instalamos less usando npm, con la opción -g para que lo instale global todo el sistema (hacer esto como root):

# npm install -g less

Y comprobamos la versión, mucho mas nueva:

lessc --version
lessc 2.5.3 (Less Compiler) [JavaScript]

En mi caso, al instalar con npm, se hace un lío con el ejecutable de node.js, que en unos sitios es node y en otros nodejs, y al ejecutar da errores como este:

lessc
/usr/bin/env: node: No existe el fichero o el directorio

Esto tiene fácil solución, creando un enlace dinámico para que lo encuentre (también hay que hacer esto como root):

# ln -s /usr/bin/nodejs /usr/bin/node

Eso es todo. Supongo que la mayoría funcionara también en Ubuntu, pero eso ya os lo dejo a vosotros...

Añadir nuevo comentario

Encontrar procesos que causan bloqueos de IO (iowait)

root — Thu, 11 Jun 2015 22:21:19 +0000

Encontrar procesos que causan bloqueos de IO (iowait)

Viernes, Junio 12, 2015 - 00:21

Linux

Debian

IOWait es la medida del tiempo que los procesos de la CPU pasan sin hacer nada, en espera de poder hacer una operación de IO, es decir, leer o escribir en el disco.

Generalmente es un indicador claro de un cuello de botella en el sistema, y se produce cuando alguno de los discos (o todos) no dan a basto con operaciones de lectura y/o escritura.

Los síntomas suelen ser bastante claros, en forma de bajada general de rendimiento, largas esperas, etc.

La forma más sencilla y estándar de comprobar la carga de iowait que tenemos es usar el comando top, que tenemos disponible en cualquier sistema GNU / Linux, y en muchos casos no es necesario ni siquiera tener permisos de root. En la primera parte de la salida del top es donde tenemos esta información en la línea de %Cpu(s), marcada como wa.

top - 20:26:25 up 5 days, 22:50,  3 users,  load average: 0,02, 0,31, 0,54
Tasks: 220 total,   1 running, 219 sleeping,   0 stopped,   0 zombie
%Cpu(s):  3,3 us,  1,8 sy,  0,0 ni, 94,3 id,  0,7 wa,  0,0 hi,  0,0 si,  0,0 st
KiB Mem :  7614832 total,   144824 free,  2784012 used,  4685996 buff/cache
KiB Swap:  7815164 total,  7718864 free,    96300 used.  4251800 avail Mem

En este caso, según la salida de top, tenemos 3,3% de procesos de usuario (us), 1,8% un de sistema (sy), 0,0% de procesos de baja prioridad (ni), un 94,3% de CPU sin hacer nada, o en estado idle (id), y solamente un 0,7% de iowait (wa), lo cual está bastante bien. El resto está a cero, y si hacemos la suma sale un 100,1 %. Cosas del redondeo...

Para refrescar, según la información de man del comando top...

us: user cpu time (or) % CPU time spent in user space
sy: system cpu time (or) % CPU time spent in kernel space
ni: user nice cpu time (or) % CPU time spent on low priority processes
id: idle cpu time (or) % CPU time spent idle
wa: io wait cpu time (or) % CPU time spent in wait (on disk)
hi: hardware irq (or) % CPU time spent servicing/handling hardware interrupts
si: software irq (or) % CPU time spent servicing/handling software interrupts
st: steal time - - % CPU time in involuntary wait by virtual cpu while hypervisor is servicing another processor (or) % CPU time stolen from a virtual machine

Ahora veamos un ejemplo de proceso generando esperas de iowait. Lo que voy a hacer es ejecutar un comando sencillo pero que va a generar muchas operaciones de lectura, en este caso, un simple du para comprobar el espacio usado, pero sobre el raiz del sistema de ficheros:

du -h /

Al ejecutar el comando, los resultados del top ya empiezan a mostrar una subida del iowait.

Tasks: 226 total,   3 running, 223 sleeping,   0 stopped,   0 zombie
%Cpu(s): 11,5 us,  6,5 sy,  2,0 ni, 60,8 id, 19,0 wa,  0,0 hi,  0,1 si,  0,0 st
KiB Mem :  7614832 total,    52068 free,  3388748 used,  4174016 buff/cache
KiB Swap:  7815164 total,  7711876 free,   103288 used.  3580684 avail Mem 

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                      
 2356 charles   20   0  882788 147036  83488 S  17,6  1,9   0:30.12 chrome                                                       
 2513 charles   20   0    7076   3156   2384 D  14,6  0,0   0:02.09 du                                                           
12156 charles   20   0  564288  62128  43656 S  13,6  0,8   0:36.61 konsole                                                      
 2442 charles   20   0  623544 182416 134288 S   7,0  2,4  26:52.05 chrome

Aquí podemos ver que el %wa ha subido al 19,0%, con lo que vamos a empezar a notar problemas de rendimiento. En este caso, y solamente usando el comando top, podemos identificar rápidamente el proceso, fijándonos en la columna de estado (S) del top, vemos que hay un proceso du que tiene su estado a D. El estado D significa 'uninterruptible sleep', lo que suele ser indicativo de que el proceso está esperando por una operación de IO.

También para refrescar, esta es la lista de estados que muestra el man del comando top.

D = uninterruptible sleep
R = running
S = sleeping
T = stopped by job control signal
t = stopped by debugger during trace
Z = zombie

Normalmente, los procesos en top estarán en estado S (durmiendo a gusto) o R (corriendo). Si empezamos a ver procesos en D, es señal de que estamos teniendo lo esperas largas de IO.

Para sacar algo más de información de que están haciendo nuestros procesos conflictivos, otro comando muy útil y más específico el top es iotop. Ojo, porque este no viene "de serie" en la mayoría de distribuciones, aunque es muy recomendable tenerlo a mano. En Debian, lo tenemos sencillo:

apt-get install iotop

Con iotop tenemos un listado del uso de operaciones de IO por procesos. La primera información que nos muestra son los totales de lectura y escritura del sistema, y después las de cada proceso ordenados por actividad. Y aquí sí que podremos ver de forma muy clara cuáles son los procesos que más recursos están utilizando.

Total DISK READ :    1265.11 K/s | Total DISK WRITE :       0.00 B/s
Actual DISK READ:     875.85 K/s | Actual DISK WRITE:       0.00 B/s
  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND                                                                  
14344 be/4 charles  1265.11 K/s    0.00 B/s  0.00 % 64.06 % du -h /
    1 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % init
    2 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [kthreadd]
    3 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [ksoftirqd/0]
    5 be/0 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [kworker/0:0H]

Ahora si podemos ver sin duda que el proceso du es el que está leyendo del disco como si no hubiese mañana, y bueno, en este caso la solución es sencilla: podemos matarlo con un kill, con el PID que nos da el iotop.

kill 14344

Si queremos seguir investigando un poco más, podemos usar el comando lsof, que nos va a mostrar un listado de los archivos que está utilizando un proceso, con su PID:

lsof -p 14344

La salida mostrará algo parecido a lo que vemos a continuación, y en muchos casos también nos puede dar pistas de lo que está sucediendo.

COMMAND   PID    USER   FD   TYPE DEVICE SIZE/OFF     NODE NAME
du      14883 charles  rtd    DIR  252,0     4096        2 /
du      14883 charles  txt    REG  252,0   113576  5796815 /usr/bin/du
du      14883 charles  mem    REG  252,0   341146 10477596 /usr/share/locale/es/LC_MESSAGES/coreutils.mo
du      14883 charles  mem    REG  252,0  1729984 13221996 /lib/x86_64-linux-gnu/libc-2.19.so
du      14883 charles  mem    REG  252,0   140928 13221991 /lib/x86_64-linux-gnu/ld-2.19.so
du      14883 charles  mem    REG  252,0  1607632  4309902 /usr/lib/locale/locale-archive
du      14883 charles  mem    REG  252,0   151111 16318536 /usr/share/locale/es/LC_MESSAGES/libc.mo
du      14883 charles  mem    REG  252,0    26258  4322370 /usr/lib/x86_64-linux-gnu/gconv/gconv-modules.cache
du      14883 charles    0u   CHR  136,1      0t0        4 /dev/pts/1
du      14883 charles    1u   CHR  136,1      0t0        4 /dev/pts/1
du      14883 charles    2u   CHR  136,1      0t0        4 /dev/pts/1

Otro comando útil para estos casos es iostat, que nos muestra estadísticas de operaciones de IO sobre los discos. En este caso, no tenemos información de los procesos que las causan, solamente las operaciones globales que se están realizando, y principalmente nos va a permitir descubrir, o confirmar, en cuál de nuestros discos es en el que se están produciendo los bloqueos.

Al igual que con iotop, normalmente tendremos que instalarlo a parte. En Debian:

apt-get install iostat

La primera muestra de iostat nos muestra el resumen total desde que levantó la máquina, y en las siguientes iteraciones se muestra la estadística desde el informe anterior, y es donde podremos ver que está pasando.

iostat 2

La salida de iostat, con iteraciones cada 2 segundos:

Linux 4.2.0-1-amd64 (totoro2)    20/10/15        _x86_64_        (4 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           2,38    0,32    1,15    2,69    0,00   93,45

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda              31,91        84,58       725,86    7867640   67517095
dm-0             37,82        83,47       723,61    7764404   67308108
dm-1              0,64         0,59         2,00      54648     185684

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           4,79    0,00    2,52   24,34    0,00   68,35

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda             573,50      2304,00        18,00       4608         36
dm-0            580,50      2304,00        18,00       4608         36
dm-1              0,00         0,00         0,00          0          0

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           5,51    0,00    2,38   23,53    0,00   68,59

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda             197,00       780,00        10,00       1560         20
dm-0            197,00       780,00        10,00       1560         20
dm-1              0,00         0,00         0,00          0          0

En este caso, vemos que tenemos un iowait de alrededor de un 24%, que se está produciendo en el disco sda. Este comando es muy útil cuando tenemos varios, por ejemplo, y podemos combinar con lsof para indagar más sobre los ficheros que están causando el problema.

A partir de aquí, las soluciones dependen del tipo de problema que tengamos entre mano, y eso ya daría no para otro artículo, sino para un libro entero, pero siempre podremos recurrir a nuestro querido kill, al menos para quedarnos agusto.

Para ampliar un poco de información, y como fuentes que he utilizado para consulta, recomiendo varias lecturas interesantes, aunque todas en inglés.

http://serverfault.com/questions/12679/can-anyone-explain-precisely-wha…

http://stackoverflow.com/questions/666783/how-to-find-out-which-process…

http://bencane.com/2012/08/06/troubleshooting-high-io-wait-in-linux/

Comments

IO Wait

Muchas gracias por este blog.. Me ayudó mucho..

Saludos.

buena info, se agradece

IO Wait

Muchas gracias por esta entrada, Carlos. Me resultó muy útil

Util

Me ha resultado muy util, me estaba volviendo loco.

Me ha resultado muy util

Gracias me estaba volviendo loco

Artículo IO

Hola, quiero agradecerte por este blog y este artículo, lo explicas de una manera sencilla y muy fácil de entender.

Añadir nuevo comentario

Normalización de volumen de mp3

root — Mon, 28 Apr 2014 20:28:48 +0000

Normalización de volumen de mp3

Lunes, Abril 28, 2014 - 22:28

Con los años mi colección de mp3 no para de crecer, hace años que no utilizo otro soporte para la música, pero como las fuentes son muy variadas, siempre hay cambios de volumen entre las distintas canciones cuando uno esta reproduciendo distintos álbumes o artistas. Esto es especialmente molesto en el coche, o a las tres de la mañana, susto incluido.

Hace tiempo descubrí una herramienta para normalizar el volumen de audio en los mp3, que me viene funcionando de maravilla, llamada mp3gain.

En Debian, lo podemos instalar sin mucho problema:

apt-get install mp3gain

Lo que hago es ejecutarlo con un comando en el directorio donde guardo la música:

find . -type f -iname "*.mp3" -exec mp3gain -k -r "{}" \;

Lo que hace este comando es ejecutar mp3gain sobre todos los archivos mp3 del disco, procurando que una subida de volumen no haga distorsionar el audio (parámetro -k), y equiparando el volumen de todas las pistas al mismo nivel (parámetro -r).

En teoria estos ajustes sobre los archivos son "lossless", es decir, sin pérdida de calidad, ya que no se recodifican los datos, sino que se aplican directamente los cambios sobre el fichero. También tiene un modo de funcionamiento que guarda los ajustes solamente en una etiqueta del fichero, pero de esta forma nuestro reproductor tendrá que saber procesar dicha etiqueta. Yo no he tenido ningún problema haciendo los ajustes directamente a los ficheros.

Para más información, la página del proyecto es:

http://mp3gain.sourceforge.net/

Añadir nuevo comentario

Script de backup para Drupal

root — Mon, 28 Apr 2014 19:12:10 +0000

Script de backup para Drupal

Lunes, Abril 28, 2014 - 21:12

Drupal

Linux

Backup

Cuando hablamos de Drupal, el espectro de productos desarrollados con el es amplísimo. Me refiero a que podemos encontrar desde pequeños portales montados con lo justo y desplegados en un pequeño servidor, hasta completos sites empresariales con varios nodos frontales, balaceadores de carga, cluster de bases de datos, etc.

Normalmente en proyectos grandes se dispone de copias de seguridad de ficheros y bases de datos, por cuenta de los chicos de sistemas, pero este tipo de backups suelen ser complicados de restaurar, por afectar a mas componentes del sistema opertivo ademas de nuestro querido Drupal que se nos acaba de romper. Además, muchas veces ni siquiera pueden ser restaurados por el equipo de desarrollo, con lo que en la práctica no suele ser recomendable fiarnos solo de este tipo de respaldos.

Si queremos estar tranquilos, lo mejor es verlo de esta manera: hoy en día, el espacio en disco es barato.

En la mayoría de los casos, lo normal será que tengamos espacio disponible en disco que podemos usar para realizar nuestros propios backups, programados con una sencilla tarea en el crontab de la máquina, digamos suficiente para guardar una copia diaria durante al menos una semana.

Para ello, suelo utilizar alguna variación de este script, que saca copia de la base de datos y del directorio fisico que le indiquemos, con lo que tendremos un backup completo del sitio Drupal en dos ficheros.

Para utilizar este script necesitaremos:

mysqldump, como herramienta para realizar la copia de la BBDD
tar, como herramienta para generar un archivo comprimido de los ficheros.

OJO: Cuidado donde dejamos este script y los permisos del fichero, ya que tendremos en el los datos de acceso al MySQL de Drupal. No podemos tenerlo en un directorio público y su juego de permisos deberia ser algo como 700, dependiendo de como lo vayamos a ejecutar.


#!/bin/bash

# DATOS
DRUPAL_FILES=/var/www/nuestro-drupal
BACKUP_DIR=/la/carpeta/raiz/de/backup
FILENAME=drupal_auto_backup_

USER=usuarioBBDD
PASSWORD=passwordBBDD
DATABASE=nombreBBDD
HOST=hostBBDD

# Numero de dias a conservar los ficheros
DIAS=7


# COMIENZO
DATE=`date +%Y"-"%m"-"%d"--"%H"-"%M`

PATH_MYSQL=$BACKUP_DIR/ddbb/
PATH_FILES=$BACKUP_DIR/files/

if [ ! -d "$PATH_MYSQL" ]; then
 echo "Creando directorio $PATH_MYSQL"
 mkdir -p $PATH_MYSQL
fi

if [ ! -d "$PATH_FILES" ]; then
  echo "Creando directorio $PATH_FILES"
  mkdir -p $PATH_FILES
fi


FILE_MYSQL=$PATH_MYSQL$FILENAME$DATE".sql"
FILE_TAR=$PATH_FILES$FILENAME$DATE".tar.gz"


echo "Generando backup de MySQL $FILE_MYSQL"
mysqldump --user=$USER --password=$PASSWORD --host=$HOST $DATABASE  > $FILE_MYSQL

echo "Generando backup de ficheros $FILE_TAR"
cd $DRUPAL_FILES
tar cvvzf $FILE_TAR *


echo "Eliminando backups antiguos"
find $PATH_MYSQL -type f -name "$FILENAME*" -mtime +$DIAS -exec rm -v {} \;
find $PATH_FILES -type f -name "$FILENAME*" -mtime +$DIAS -exec rm -v {} \;