El comando "at" de Solaris/OpenIndiana

Introducción
El comando <at> de Solaris nos permite planificar la ejecución de un comando en un intervalo de tiempo. A diferencia de cómo gestionar el cron en Solaris, donde se pueden definir repeticiones <at> nos permite ejecutar un comando "luego".

El formato de <at> es el siguiente:

/usr/bin/at [-c | -k | -s] [-m] [-f file] [-p project] [-q queuename] timespec

donde

• -c indica que queremos utilizar <C Shell>
• -k indica que queremos utilizar <Korn Shell>
• -s indica que queremos utilizar <Bash Shell>
• -f indica que queremos utilizar <file> como comando en vez de la entrada estandar
• -p indica que queremos utilizar <project> como proyecto para la ejecución
• -q indica el nombre de la <queue> que queremos utilizar
• timespec indica cuándo queremos ejecutarlo

Colas de Ejecución
<at> dispone de diferentes <queue> de ejecución que nos van a permitir gestionar nuestras peticiones. Estas <queue> pueden ser letras en minúsculas de la <a ... z> donde debemos tener en cuenta que la <queue>b> está reservada para <batch> y la <c> para <cron>

La cola de ejecución <batch>
Este tipo especial de <queue> nos permite ejecutar los comandos en modo "secuencial" cuando el equipo está <idle> y, por lo tanto, no nos interfiere en la carga del sistema.

Su formato no requiere una definición de tiempo -ya que lo ejecutará cuando pueda-, por ejemplo

havoc@h100:/# echo "ls >/tmp/ls.batch"| at -q b
commands will be executed using /bin/bash
job 1308472386.b at dom jun 19 10:33:06 2011

Variables definidas para definir la hora de ejecución <timespec>
Existen algunas definiciones ya establecidas para <timespec<, por ejemplo, <now>, <midnight>, etc.

A estas definiciones podemos añadirles (utilizando +) un intervalo, por ejemplo, <minute, hour, day, week> con lo que tendremos una expresión como esta:

havoc@h100:/# echo "ls" | at now + 1 minute

Ver el estado de las <queue>
Para ver el estado de las colas de ejecución, comandos pendientes y la fecha/hora planificada, utilizaremos la opción <-l>, por ejemplo

havoc@h100:/# at -l
user = root     1308473222.a    dom jun 19 10:47:02 2011

Borrar un comando de la <queue>
Podemos borrar un comando utilizando la opción <-r {id}>, por ejemplo,

havoc@h100:/# echo "ls > /tmp/ls.at" | at now + 5 minutes
commands will be executed using /bin/bash
job 1308473822.a at dom jun 19 10:57:02 2011
havoc@h100:/# at -l
user = root     1308473822.a    dom jun 19 10:57:02 2011
havoc@h100:/# at -r 1308473822.a
havoc@h100:/# at -l

Permitir o denegar la ejecución de comandos
Al igual que sucede con <cron>, podemos establecer qué usuarios pueden ejecutar comandos mediante <at o cron> editando el archivo </etc/cron.d/at.allow> y denegar editando el archivo </etc/cron.d/at.deny>

Además, debemos tener en cuenta que si el usuario/role no tiene establecida una contraseña, no podrá ejecutar comandos.

Algun ejemplo más ...
Por ejemplo, si queremos que se lance el sistema de actualización de paquetes hoy por la noche, podemos utilizar el siguiente formato:

havoc@h100:/# echo "pkg refresh --full" | at -q z midnight
commands will be executed using /bin/bash
job 1306792800.z at mar may 31 00:00:00 2011

Conclusiones
Este comando -a veces desconocido- nos puede solucionar algún que otro problema, sobre todo cuando queremos dejar "algo para luego", o si queremos aprovecharnos de la ejecución en formato "batch".

Referencias

• Cómo editar el crontab en Solaris/OpenIndiana
• Cómo funciona el sistema de paquetes IPS en OpenIndiana

Cómo funciona el sistema de instalación por paquetes IPS en OpenIndiana y Solaris - Parte 1

Introducción
Entre las muchas novedades que introdujo OpenSolaris, se encuentran el nuevo formato de instalación de paquetes (IPS).

Esta nueva forma de instalación elimina los problemas de dependencias que podíamos tener en el formato anterior (SrV4) aunque, también nos incluye algunas limitaciones que veremos cómo podemos evitarlas.

Sistema IPS
El formato de paquetes IPS es muy parecido al sistema utilizado por FreeBSD, es decir, nos permite instalar, actualizar y desinstalar de una forma sencilla un paquete y sus dependencias, todo ello utilizando un único comando <pkg>

Funcionamiento básico
Su funcionamiento consiste en incluir repositorios donde podemos encontrar los paquetes -en formato binario-, por lo tanto, disponemos de diversas fuentes desde la cuales instalar.

Estos repositorios se pueden encontrar en una dirección web pública, por ejemplo, http://pkg.x86.havoctec.com/ o en un servidor interno, http://localhost:1000/.

Cuando al principio os comentaba sobre "algunas limitaciones" esta era una de ellas, el hecho de necesitar de un acceso a Internet, pero como veis, es muy sencillo de solucionar creando un repositorio "interno" desde el cual instalar los paquetes -lo veremos más adelante-


Repositorios
Un repositorio es un servicio web que nos proporciona el funcionamiento de control y acceso. En OpenIndiana/Solaris debemos activar y configurar el servidor <svc:/application/pkg/server:default> para poder gestionarlo.

Cada repositorio está "asociado" un "publisher", es decir, quién lo publica. De esta forma, si instalamos el paquete <nagios-core> desde el repositorio <http://pkg.x86.havoctec.com/>, nuestro sistema IPS, buscará las actualizaciones siempre en este repositorio.

Para evitar esto, es decir que los paquetes se puedan actualizar desde cualquier repositorio hay que utilizar la opción <--non-sticky> pero luego hablamos con más detalle de todo esto.

Gestionar los Repositorios de Paquetes y Publisher
Como hemos comentado, todo el sistema de administración se realiza utilizando el comando <pkg>, para ello, debemos utilizar las opciones <publisher y unset-publisher>

Ver los Publicadores -publisher-
Debemos utilizar la opción <publisher> para obtener el detalle de los repositorios instalados, y su estado, por ejemplo

havoc@tikko:~$ pfexec pkg publisher
PUBLISHER           TYPE                  STATUS   URI
openindiana.org     (preferred)  origin   online   http://pkg.openindiana.org/dev/
opensolaris.org                  origin   online   http://pkg.openindiana.org/legacy/

Añadir un nuevo publisher
Para añadir un publisher, simplemente deberemos utilizar la opción <publisher> del comando <pkg>.

Por ejemplo, para añdir el publicador HavocTec.Com utilizaremos el siguiente comando, donde la opción <-O< representa la URL del repositorio, y havoctec.com es el nombre del publisher.

havoc@tikko:~$  pfexec pkg set-publisher -O http://pkg.x86.havoctec.com/ havoctec.com

Y nos quedará de la siguiente forma, donde vemos ahora nuestro nuevo publisher "HavocTec.Com"

havoc@tikko:~$ pfexec pkg publisher
PUBLISHER                             TYPE     STATUS   URI
openindiana.org          (preferred)  origin   online   http://pkg.openindiana.org/dev/
opensolaris.org                       origin   online   http://pkg.openindiana.org/legacy/
havoctec.com                          origin   online   http://pkg.x86.havoctec.com/

Modificar la URL del repositorio
Alguna vez puede que necesitemos modificar la URL en la que se encuentra el repositorio del publisher, para ello, deberemos utilizar la opción <set-publisher< con las opciones <-G direccion_a_eliminar> y <-g direccion_nueva>.

Por ejemplo, para modificar la dirección del repositorio <http://pkg.x86.havoctec.com/> por <http://pkg.havoctec.com/> haremos lo siguiente:

havoc@tikko:~$ pfexec pkg set-publisher -G http://pkg.x86.havoctec.com/ -g http://pkg.havoctec.com/ havoctec.com

Eliminar un Publisher
Para eliminar un publisher, simplemente deberemos utilizar la opción <unset-publisher>.

Por ejemplo, para eliminar el  publisher <havoctec.com> haremos lo siguiente:

havoc@tikko:~$ pfexec pkg unset-publisher havoctec.com

Instalar nuevos paquetes
Ya hemos utilizado muchas veces el comando, pero hasta ahora no habíamos entrado en detalle de su funcionamiento, :D. Para instalar un paquete nuevo, siemplemente deberemos ejecutar el comando <pkg install {frmi}>, por ejemplo para instalar el core de nagios, haremos lo siguiente

havoc@tikko:~$ pfexec pkg install nagios-core
                Packages to update:     1
           Create boot environment:    No
DOWNLOAD                 PKGS       FILES    XFER (MB)
Completed                1/1         2/2      0.0/0.0

PHASE                                        ACTIONS
Update Phase                                     3/3

PHASE                                          ITEMS
Package State Update Phase                       2/2
Package Cache Update Phase                       1/1
Image State Update Phase                         2/2

PHASE                                          ITEMS
Reading Existing Index                           8/8
Indexing Packages                                1/1

havoc@tikko:~$ pfexec svcs nagios
STATE          STIME    FMRI
disabled        1:15:17 svc:/application/network/nagios:server

Limitaciones de IPS
Una de las limitaciones que tenemos en el nuevo sistema de paquetes es que no podemos ejecutar scripts -como antes teníamos post-install, pre-install, etc.- por lo tanto, algunas de las características más "avanzadas" de OpenIndiana/Solaris no se pueden llevar a cabo, por ejemplo crear nuevas autorizaciones, desde el propio sistema de instalación.

Pero, como siempre, tenemos una solución, bueno en este caso hay muchas y diversas, aunque yo he utilizado una sencilla: Crear un script <post-install> en el paquete y llamarlo luego "a mano", por ejemplo:

havoc@tikko:/$ pfexec sh /usr/local/nagios/scripts/post-install

Si estáis interesados en "el por qué" aquí os dejo algunos links a las explicaciones: pkg no script zone y pkg postinstall using smf

Eliminar un paquete
Para eliminar un paquete, simplemente utilizaremos la opción <uninstall> seguido del nombre del paquete, por ejemplo, si queremos eliminar <nagios-core> haremos lo siguiente:

havoc@tikko:/$ pfexec pkg uninstall nagios-core
                Packages to remove:     1
           Create boot environment:    No
               Services to restart:     1
PHASE                                        ACTIONS
Removal Phase                                   1/72
Removal Phase                                  72/72

PHASE                                          ITEMS
Package State Update Phase                       1/1
Package Cache Update Phase                       1/1
Image State Update Phase                         2/2

PHASE                                          ITEMS
Reading Existing Index                           8/8
Indexing Packages                                1/1

Conclusiones
En esta primera parte hemos vista algunas funciones básicas de IPS, en las siguientes veremos cómo crear un servidor IPS para tener réplicas locales y, de esta forma, no tener que depender de la conexión de Internet para las instalaciones.

Además, os dejo el link del repositorio público que he creado -gracias a HavocTec por cederme recursos- para que todas las instalaciones que os voy enseñando, se puedan instalar con <pfexec pkg instal {frmi}> y simplificar el proceso.

Aunque actualmente no hay muchos paquetes, poco a poco ire subiendo los principales: PostgreSQL, Apache HTTP, Nagios, etc.


Referencias

• Repositorio HavocTec.Com
• Documentación IPS en OpenSolaris

Qué es Crossbow y Cómo Utilizarlo en Solaris/OpenIndiana - Parte 3

Introducción
En las primeras parte de Crossbow Qué y Cómo Utilizarlo hacíamos una introducción a la tecnología. En esta ocasión vamos a ver una nueva utilidad <flowadm> que nos permitirá aplicar QoS de una forma muy sencilla.

Flow o Flujos
Los <flow> nos permiten discriminar el tráfico en función de unos parámetros, como por ejemplo puerto origen <local_port>, puerto destino <remote_port>, tipo de protocolo <protocol>, etc. y asignarle una prioridad y un ancho de banda.

Cómo utilizar flujos
Supongamos que tenemos un servidor con varias zonas, donde a su vez tenemos instalados diferentes servicios -por ejemplo Apache HTTP y PostgreSQL- y, queremos asignar unos "anchos de banda y prioridades" para garantizar los servicios.

Así crearemos dos flujos -uno para HTTP y otro para PostgreSQL- donde asignemos unos límites y prioridades sabiendo que ninguno de ellos "usará el ancho de banda del otro" y, de esta forma garantizando nuestros servicios.

Gestión de Flujos
Aunque pueda parecer que es lo mismo que veíamos en la Crossbow y Cómo utilizarlo en OpenIndiana - Parte 1, tiene algunas pequeñas diferencias.

En sí, se obtiene un mismo objetivo: "Asignar un ancho de banda máximo" sin embargo, si utilizamos la opción de asignarlo al interface todos los servicios estarán limitados -y no podemos establecer un ajuste más fino-, pero si utilizamos <flowadm>, seremos capaces de diferenciar por servicios y, de esta forma, hacer un ajuste muy fino.

El comando <flowadm>
Toda la gestión se realiza utilizando el comand </usr/sbin/flowadm> -al igual que sucedía con <dladm>- y sus opciones son las siguientes:

havoc@h100:~$ pfexec flowadm
usage: flowadm <subcommand> <args>...
    add-flow       [-t] -l <link> -a <attr>=<value>[,...]
                   [-p <prop>=<value>,...] <flow>
    remove-flow    [-t] {-l <link> | <flow>}
    show-flow      [-p] [-l <link>] [<flow>]

    set-flowprop   [-t] -p <prop>=<value>[,...] <flow>
    reset-flowprop [-t] [-p <prop>,...] <flow>
    show-flowprop  [-cP] [-l <link>] [-p <prop>,...] [<flow>]

Nota: Recordar que se debe ejecutar como <root> o con un usuario con los privilegios suficientes. Si no sabes mucho de Privilegios y Roles te aconsejo que mires RBAC: Roles y Privilegios en Solaris/OpenIndiana.

Creación de un <flow>
Para crear un flow, simplemente deberemos utilizar la opción <add-flow> y definir sobre que interface queremos que se aplique. Recordar que ahora podemos utilizar tanto interface virtuales como físicos.

Así que vamos a crear un <flow> que nos asigne siempre una prioridad muy alta a los accesos que realicemos a nuestra PostgreSQL sobre nuestro interface es un virtual <vnic1&gt.

Podemos crear un <flow> utilizando las siguientes opciones como "filtros":

• Puerto: Local <local_port> o remoto <remote_port>
• Tipo Conexión: <transport>, tcp, udp, sctp, icmp, icmp6
• IP: Origen <local_ip> o destino <remote_ip>

Utilizaremos las opciones <transport=TCP> para indicar que será de tipo TCP y que el puerto local <local_port>.

havoc@h100:~$ pfexec flowadm add-flow -l vnic1 -a transport=TCP,local_port=5432 postgres-flow

Ver y Cambiar las propiedades
Como sucedía con los interfaces virtuales, podemos cambiarle las propiedades al flujo "en caliente", para ello, utilizaremos las opciones <show-flowprop> para mostrar las propiedades y <set-flowprop -p {PROPIEDAD=VALOR}< para asignar una nueva.

havoc@h100:~$ pfexec flowadm show-flowprop postgres-flow
FLOW         PROPERTY     VALUE      DEFAULT   POSSIBLE
postgres-flow maxbw       --         --        ?
postgres-flow priority    --         --        ?

Cuando no tenemos asignado un valor a la propiedad se muestran como "--" para indicarnos que no hay nada.

Y para cambiar una propiedad, por ejemplo asignarle la máxima prioridad haremos lo siguiente:

havoc@h100:~$ pfexec flowadm set-flowprop -p priority=high postgres-flow

Comprobamos sus propiedades, utilizando la opción <show-flowprop>

havoc@h100:~$ pfexec flowadm show-flowprop postgres-flow
FLOW         PROPERTY   VALUE       DEFAULT        POSSIBLE
postgres-flow maxbw     --          --             ?
postgres-flow priority  high        --             high

Asignar un Ancho de Banda (maxbw)
Para limitar el ancho de banda máximo para el <flow>, deberemos utilizar la propiedad <maxbw>. El valor a asignar será un valor entero y deberemos añadir la escala (K, M o G para Kilobits, Megabits o Gigabits), si no añadimos ninguna, Solaris entenderá que estamos introduciendo Megabits.

Un pequeño apunte sobre la limitación de ancho de banda a tener en cuenta es, si hemos limitado nuestro interface a un determinado valor, nuestro <flow> nunca superará éste aunque se mayor, es decir, si hemos puesto que nuestro interface tiene un valor de <maxbw=10M> y tenemos un flow con <maxbw=20M>, nuestro <flow> nunca nos dará un valor superior a 10M -porque lo limita el interface-

havoc@h100:~$ pfexec flowadm set-flowprop -p maxbw=2M postgres-flow
havoc@h100:~$ pfexec flowadm show-flowprop postgres-flow
FLOW           PROPERTY    VALUE     DEFAULT     POSSIBLE
postgres-flow  maxbw       2         --          2M
postgres-flow  priority    high      --          high

Resetear todas las propiedades
Cuando se está "jugando" con las propiedades, hay veces que queremos empezar "de cero" para poder asignar otros parámetros, para ello, utilizaremos la opción <reset-flowprop&ght;, por ejemplo:

havoc@h100:~$ pfexec flowadm reset-flowprop postgres-flow
havoc@h100:~$ pfexec flowadm show-flowprop postgres-flow
FLOW         PROPERTY   VALUE       DEFAULT        POSSIBLE
postgres-flow maxbw     --          --             ?
postgres-flow priority  --          --             ?

Eliminar un flujo
Para eliminar un <flow> simplemente utilizaremos la opción <remove-flow> del comando <flowadm>, siguiendo con nuestro ejemplo:

havoc@h100:~$ pfexec flowadm remove-flow postgres-flow

Ver las Estadísticas
Podemos ver las estadísticas de un <flow> utilizando el comando <flowstats> que nos proporcionará los valores totales de los flujos, por ejemplo:

havoc@h100:~$ pfexec flowstat
           FLOW IPKTS  RBYTES  IERRS OPKTS   OBYTES    OERRS
  postgres-flow 14,14K 987,97K 0     15,68K  17,09M    0
       pkg-flow 47     3,13K   0     47      2,54K     0

Si queremos ver las estadísticas de un período concreto, debemos activar los sistemas de auditoría que ... esto lo dejaremos para la Parte 4 ya que así lo podremos unir a Auditoría sobre RBAC en Solaris


<< Qué es Crossbow y Cómo Utilizarlo en Solaris/OpenIndiana - Parte 1
<< Qué es Crossbow y Cómo Utilizarlo en Solaris/OpenIndiana - Parte 2


Conclusión
Poco a poco avanzamos en el uso de Crossbow, y, en esta ocasión nos hemos centrado en una parte importante de Calidad de Servicio (QoS) que, sinceramente se ha simplificado en gran medida.

Resumen de mi Trabajo en HavocTec

Hoy no voy a hablar sobre Solaris, OpenIndiana o PostgreSQL .... no, no, no, hoy voy a hacer un "resumen en voz alta" de mis experiencias en HavocTec.

Lo cierto es que, aunque no tengo todo el tiempo que me gustaría para dedicarme al blog -creo que ninguno lo tenemos-, muchos de los posts están inspirados en algo que he hecho -o he tenido que diseñar- tanto en HavocTec como en los productos que disponemos (HSeries, SafeChildren).

Han pasado muchas cosas desde que decidí incorporarme a HavocTec, y, ciertamente no me arrepiento de haberlo hecho, ya que, creo que contribuir a la creación de un Sistema de Gestión de Internet me ha servido para aprender mucho, y, poner ese "granito de arena" contra lo Pornografía Infantil, Acoso, CyberBulling y otras lacras que nos empiezan a sonar bastante más de lo que me gustaría.

Me ha permitido llevar temas de seguridad a niveles "más humanos" -por ejemplo Charlas con Padres preocupados por sus niños- y, eso, hace ver que la tecnología tiene un lado humano muy gratificante.

Por eso, quería felicitar a todo el equipo de HavocTec y espero seguir disfrutando como hasta ahora con ellos.

Urko Benito,

Qué es Crossbow y Cómo Utilizarlo en Solaris/OpenIndiana - Parte 2

Introducción
En la primera parte hablábamos de Qué es Crossbow y Cómo Utilizarlo en nuestros equipos de producción.

En esta ocasión, vamos a seguir profundizando en las opciones que nos aporta la creación de nic virtuales (vnic)


Optimización en Servidores CMT (MultiThread)
Una de las opciones más interesantes cuando hablamos de servidores Web, es la posibilidad de "unir" nuestras vnic a cores -o threads- de nuestro equipo.

De esta forma, podemos hacer que si tenemos una zona de en la cual tengamos instalado nuestro servidor Web Apache (o varios servidores), la interrupciones que se producen en la tarjeta de red, no afecten a los demás.

Dicho de otra forma, si tenemos una zona donde está nuestro servidor de aplicaciones, pongamos Apache Tomcat y sobre otra zona nuestro Squid como Proxy Reverso, y nuestra máquina tiene 4 cpus. Así que vamos a asignar las CPUs 0,1,2 al Proxy Reverso y la 3 a nuestro servidor Tomcat.

Para ello, vamos a utilizar la propiedad <cpus> y <priority>, para crear dos VirtualNIC -como vimos en la primera parte-

root@h1-cl1:/# psrinfo
0       on-line   since 05/09/2011 00:07:24
1       on-line   since 05/09/2011 00:07:26
2       on-line   since 05/09/2011 00:07:26
3       on-line   since 05/09/2011 00:07:26
root@h1-cl1:/# dladm create-vnic -l e1000g0 vnic10
root@h1-cl1:/# dladm create-vnic -l e1000g0 vnic11
root@h1-cl1:/# dladm show-vnic
LINK     OVER     SPEED  MACADDRESS       MACADDRTYPE  VID
vnic10   e1000g0  1000   2:8:20:20:17:9f  random        0
vnic11   e1000g0  1000   2:8:20:70:e5:b1  random        0
root@h1-cl1:/# dladm set-linkprop -p cpus=0,1,2 vnic10
root@h1-cl1:/# dladm set-linkprop -p cpus=3 vnic11
root@h1-cl1:/# dladm set-linkprop -p priority=high vnic10
root@h1-cl1:/# dladm set-linkprop -p priority=medium vnic11

De esta forma hemos hecho que las tarjetas "no se pisen" cuando tenga un tráfico muy elevado, y, si tenemos CPUs CMT -como los UltraSPARC T- podemos aprovechar al máximo el número de Threads que nos aportan.



<< Qué es Crossbow y Cómo Utilizarlo - Parte 1

Conclusiones
En esta ocasión no hemos hablado -a simple vista- de mucho, sin embargo, cuando empecéis a hacer vuestras pruebas, veréis cómo se obtienen unos resultados sorprendentes.

De todas formas, queda mucho por descubrir en Crossbow, y, en las siguientes entregas veremos algo más sobre optimización de anchos de banda (QoS)