martes, 4 de septiembre de 2012

Agregar Scripts al autoarranque de systemd

Hace mucho que no escribía nada por cuestiones personales y pues me coloque a revisar mi nuevo fedora 17 y vi que necesitaba agregar un script al inicio del sistema, lo lógico hubiese sido buscar /etc/rc.d/rc.local o similar /etc/rc.local pero o sorpresa este archivo ya no existe en fedora 16 y 17 , asi que decidi documentarme al respecto y en la documentación de fedora [1] nos dicen que creemos el archivo /etc/rc.d/rc.local, le demos permisos de ejecución y ya podemos utilizar normalmente ya que el sistema revisa si existe el archivo mencionado anteriormente y si existe que tenga permisos de ejecución y lo podrá utilizar. Pero la pregunta real es si hay un nuevo sistema de arranque por que seguir con los viejos métodos?, teniendo esta pregunta en la cabeza pues vamos a aprender como escribir nuestros script para que arranquen con el sistema haciendo uso de systemd.

Lo primero que debemos tener en cuenta es en donde van a quedar ubicados nuestros scripts, estos van a estar ubicados en /etc/systemd/system.
Como systemd controla otros aspectos del sistema operativo necesita un poco mas de información que no es muy compleja en sus aspectos básicos, para invocar un script necesitamos colocarlo como un demonio del sistema por lo tanto debemos escribirlo de tal forma que systemd lo entienda, lo primero que debemos tener en cuenta es el nombre del script que debe ser algo similar a esto "ejemplo.service" para una mayor información podemos ver la documentación de la nomenclatura utilizada por el sistema [2], ahora debemos crear el contenido del script, podemos tomar como ejemplo otro script que este dentro del directorio donde residen los scripts de systemd, básicamente esta compuesto de tres partes:

[Unit]
Description=Daemon of axample
After=syslog.target

En esta sección se da información básica del script, una descripción básica de la tarea que ejecuta el script y en donde va a estar ubicado en el orden de arranque.

[Service]
ExecStart=/usr/sbin/example
Type=forking

En esta sección se da la ruta en donde realmente esta el script a ejecutar y el tipo de script o demonio que va a ser para esto ver mas detalladamente la documentación de systemd
[Install]
WantedBy=multi-user.target
Y por ultimo la sección Install que nos dice en que runlevel se ejecutará en el modo multiusuario o en el clásico sysv seria el runlevel 3.

Con esto ya tenemos todo listo para agregar nuestro script al inicio del sistema, el archivo final sería algo como lo siguiente.
--------------------/etc/systemd/system/ejemplo.service-----------------------
[Unit]
Description=Daemon of axample
After=syslog.target

[Service]
ExecStart=/usr/sbin/example
Type=forking

[Install]
WantedBy=multi-user.target
----------------------------------------------
pero primero tenemos que refrescar al systemd para que lea de nuevo las configuraciones, esto lo hacemos con systemctl daemon-reload, ahora podemos probar con systemctl start ejemplo.service lo cual nos inicia el servicio (No debe mostrar errores), ahora verificamos que el servicio se este ejecutando con systemctl status ejemplo.service lo cual nos mostrará algo similar a lo siguiente:

ejemplo.service - Daemon  of example
          Loaded: loaded (/etc/systemd/system/ejemplo.service; enabled)
          Active: activating (start) since Tue, 00 Sep 2010 10:04:02 -0600; 9s xx
         Control: 23604 (lkl)
          CGroup: name=systemd:/system/ejemplo.service
                  └ 23604 /usr/sbin/example
Sep 04 22:04:02 xxx ejemplo[23604]:

Ahora podemos verificar que el servicio esta activo, lo cual solo nos queda habilitar el servicio para el autoarranque, esto lo haremos con systemctl enable ejemplo.servicey lo cual nos mostrara algo como lo siguiente:

ln -s '/etc/systemd/system/ejemplo.service' '/etc/systemd/system/multi-user.target.wants/ejemplo.service'

Finalmente tenemos listo nuestro script ejecutándose al inicio del sistema y homologado al esquema de systemd.

[1] http://docs.fedoraproject.org/es-ES/Fedora/16/html/Release_Notes/sect-Release_Notes-Changes_for_Sysadmin.html
[2] http://0pointer.de/public/systemd-man/systemd.special.html

jueves, 31 de mayo de 2012

squid NONE/417

Hoy trabajando con una de las tantas herramientas que se tiene (herramientas del gobierno que en su mayoria NO cumplen estandares) y una en especial que se llama efiquest, la cual tiene que pasar por un proxy empresarial para poder llegar a una base de datos en linea.

El problema en si era que en el log del squid mostraba:

127.0.0.1 NONE/417 886 POST http://www.rentec.com.co/rentecALic/rentecAlic.asmx - NONE/- text/html

lo cual investigando por la web me encontré con esta respuesta en una lista de correo (http://www.mail-archive.com/squid-users@squid-cache.org/msg83683.html)  en donde se recomienda utilizar la directiva  en la configuración del squid.

ignore_expect_100 ON

Y con esto termino mi pesadilla con dicha herramienta y se pudo acceder sin problemas.