¿Qué es Ganeti y para qué sirve? ¶
Ganeti es un sistema administrador de clusters basado en Xen, el cual integra un conjunto de herramientas, a saber:
* LVM
* XEN
* DRBD
que permiten facilitarle al administrador la gestión de servidores virtuales. Es opensource creada por Google. Posee capacidad de debootstraping.
Documentación Posta
* http://code.google.com/p/ganeti/
Jerga de ganeti
* Nodo: equipo físico, contenedor de máquinas virtuales.
* Instancia: máquina virtual administrada por el cluster.
Requesitos obligatorios
* Un Volume Group de al menos de 20GB, para almacenamiento de las máquinas virtuales.
* Resolución para el cluster ganeti, diferente de la resolución del nodo primario que forma parte del cluster.
* Xen.
* Configuración de bridge para Xen.
Requisitos opcionales
* Drbd.
Instalación
Suponiendo una distribución Debian.
apt-get install ganeti
La versión utilizada y probada es la 1.2.6-3.
Configuración del cluster
Configuración de red para el ganeti cluster
1. Obligatoriamente el Xen inicial debe estar trabajando en modo bridge.
marte:# cat /etc/network/interfaces
allow-hotplug xenbr0
auto xenbr0
iface xenbr0 inet static
address 10.0.0.2
netmask 255.255.255.0
network 10.0.0.0
gateway 10.0.0.1
pre-up ifconfig eth4 up
bridge_ports eth4
bridge_stp off
bridge_fd 0
2. Resolución propia para el cluster y diferente de la resolución del nodo master.
marte:/srv/ganeti/os# cat /etc/hosts
10.0.0.4 cluster1.intranet cluster1
3. Definición del hostname
marte:# echo "marte.intranet" > /etc/hostname
marte:# /etc/init.d/hostname.sh start
Sí o sí la salida del comando hostname debe ser marte.intranet, si devuelve tan solo marte las configuraciones sgtes. no funcionarán.
4. Configuración final de red
marte:/srv/ganeti/os# ifconfig
eth4 Link encap:Ethernet HWaddr 00:22:19:18:29:7b
inet6 addr: fe80::222:19ff:fe18:297b/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:727133 errors:0 dropped:0 overruns:0 frame:0
TX packets:39613 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:150008152 (143.0 MiB) TX bytes:5237793 (4.9 MiB)
Interrupt:16 Memory:da000000-da012100
xenbr0 Link encap:Ethernet HWaddr 00:22:19:18:29:7b
inet addr:10.0.0.2 Bcast:10.0.0.255 Mask:255.255.255.0
inet6 addr: fe80::222:19ff:fe18:297b/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:724972 errors:0 dropped:0 overruns:0 frame:0
TX packets:36700 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:136587142 (130.2 MiB) TX bytes:4721560 (4.5 MiB)
xenbr0:0 Link encap:Ethernet HWaddr 00:22:19:18:29:7b
inet addr:10.0.0.4 Bcast:0.0.0.0 Mask:255.255.255.255
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Inicialización del cluster ganeti
1. Inicializo el cluster. Para esto es necesario especificar: el nombre del volume group el cual almacenará las instancias ganeti (máquinas virtuales); y el bridge por defecto.
# gnt-cluster init -g vgganeti --bridge=xenbr0 cluster1.intranet
2. Compruebo el paso anterior.
# gnt-node list
Node DTotal DFree MTotal MNode MFree Pinst Sinst
marte.intranet 95368 0 32762 1024 30768 0 0
Incorporación de un nodo al cluster
Hasta aquí el nodo marte es el único nodo que conforma el cluster (denominado cluster1). Para agregar un nuevo nodo (venus.intranet) al mismo, es necesario:
1. Redefinir el hostname del nodo
venus:~# echo "venus.intranet" > /etc/hostname && /etc/init.d/hostname.sh start;
2. Regenerar par de claves ssh. la clave DEBE SER dsh.
marte:~/.ssh# rm id_dsa*
marte:~/.ssh# ssh-keygen -t dsa
3. Decirle a ganeti que incorporo un nuevo nodo al cluster.
marte:~/.ssh# gnt-node add venus.intranet
4. Compruebo que el nodo antes agregado forme parte del cluster.
marte:~/.ssh# gnt-node list
Node DTotal DFree MTotal MNode MFree Pinst Sinst
marte.intranet 445244 438588 32762 1024 31024 2 0
venus.intranet 445244 445244 32762 1024 31280 0 0
Generación de templates de Sistema Operativo
Según la documentación de ganeti se pueden generar diferentes templates de sistemas operativos a partir de debootstrap.
1. La disponibilidad de los S.O se pueden ver a través del sgte. comando:
marte:# gnt-os list
Name
debian-etch
debootstrap
2. Si se desea generar otros templates de S.O es necesario instalar el sgte. paquete:
marte:# apt-get install ganeti-instance-debootstrap
3. Configuración para el debootsrap de las variables: $MIRROR, $PROXY,$ARCH y $LENNY.
marte:~# vi /etc/default/ganeti-instance-debootstrap
4. Adaptación del script create de deboostrap
marte:/srv/ganeti/os/rect64# vi create
Administración de instacias
Definición del kernel que usarán las instancias (domU)
marte:/boot# ln -s vmlinuz-2.6.26-1-xen-amd64 vmlinuz-2.6-xenU
marte:/boot# ln -s initrd.img-2.6.26-1-xen-amd64 initrd-2.6-xenU
Creación de una instancia
El comando que spre. se utilizará a nivel instancia (antes domU) será spre. gnt-instance con diferentes combinaciones de parámetros según se requiera, a saber:
* -t plain: indica que las particiones de la instancia serán LVM.
* -n marte: la instancia se creará en el node (antes denominado dom0) marte.
* -o rect64: la instancia se creará a partir del template utilizado en rectorado rect64.
* -s 3g: tamaño de la partición /dev/sda de la instancia.
* --swap-size 256: tamaño de la partición de swap de la instancia.
* -m 64: cant. de memoria asignada a la instancia.
* --mac 00:16:3e:00:00:25: mac asignada a la instancia, que en el caso de estar declarada dn DHCP+DNS la misma levantará con red configurada.
* minmei: nombre de la instancia, spre. debe ser el último parámetro.
marte:~# gnt-instance add -t plain -n marte.intranet -o rect64 -s 3g --swap-size 256 -m 64 --mac 00:16:3e:00:00:25 --no-start minmei
Levantar una instancia
Luego de crear una instancia, es OBLIGATORIO correr los sgtes. dos comandos. NO USAR COMANDOS DE XEN.
gnt-instance startup --extra "xencons=tty1 console=tty1" minmei
gnt-instance console minmei
Verificar estado de una instancia
Una instancia luego de estar creada, puede estar corriendo o pausada. El sgte. comando permite verificar cualq. de los casos antes mencionados. Ver la columna Status.
gnt-instance list
Instance OS Primary_node Status Memory
minmei.intranet rect64 marte.intranet running 64
Ver información general de una instancia
La información gral. comprende: nodo en el cual está creada la instancia, tipo de S.O, kernel, memoria, cant. de CPUS, mac, bridge y devices.
marte:~# gnt-instance info Instance name:
minmei.intranet
State: configured to be up, actual state is up
Considered for memory checks in cluster verify: True
Nodes:
- primary: marte.intranet
- secondaries:
Operating system: rect64
Kernel path: (default: /boot/vmlinuz-2.6-xenU)
initrd: (default: /boot/initrd-2.6-xenU)
Hardware:
- VCPUs: 1
- memory: 64MiB
- NICs: {MAC: 00:16:3e:00:00:25, IP: None, bridge: xenbr0}
Block devices:
- sda, type: lvm, logical_id: (u'vgganeti', u'316f28b2-e8c1-4618-b329-504656abc1ba.sda')
primary: /dev/vgganeti/316f28b2-e8c1-4618-b329-504656abc1ba.sda (254:1)
- sdb, type: lvm, logical_id: (u'vgganeti', u'a78b14a1-4f77-424a-af57-8e30fd3d2ba6.sdb')
primary: /dev/vgganeti/a78b14a1-4f77-424a-af57-8e30fd3d2ba6.sdb (254:2)
Modificar tamaño de una instancia
Que pasa si el /dev/sda de la instancia es de 2GB y necesito hacerlo crecer a 4GB?? A continuación se encuentran en orden los comandos para extender (no disminuir) una partición en una instancia.
marte:~# gnt-instance grow-disk minmei sda 2g
marte:~# gnt-instance stop minmei
marte:~# gnt-instance startup --extra "xencons=tty1 console=tty1" minmei
marte:~# gnt-instance console minmei
Loguearse a la instancia y dentro de la misma ejecutar:
minmei:~# resize2fs /dev/sda
Reasignar memoria a una instancia
El cambio debe hacerse desde el cluster.
marte:~# gnt-instance modify -m 128 minmei
All the changes take effect at the next restart. If the instance is
running, there is no effect on the instance.
Mostrando las entradas con la etiqueta Administración. Mostrar todas las entradas
Mostrando las entradas con la etiqueta Administración. Mostrar todas las entradas
Xen
Utilizaremos como estándar de documentación:
# para referirnos a superusuario (root)
$ para referirnos a un usuario
1. Instalo ifrename.
zaphod:~#apt-get install ifrename xen-linux-system-2.6.26-1-xen-amd64 xen-tools xen-utils bridge-utils -t testing
2. Configuro el ifrename.
zaphod:~# echo "intranet mac 00:22:19:18:29:7b" > /etc/iftab
zaphod:~# ifdown eth4
zaphod:~# ifup intranet
zaphod:~# /etc/init.d/ifrename start
3. Configuro la interfaz de red en modo estático.
zaphod:~# cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
allow-hotplug xenbr0
iface xenbr0 inet static
address 172.16.0.44
netmask 255.255.128.0
gateway 172.16.0.1
bridge_ports intranet
bridge_stp off
bridge_fd 0
4. Aparentemente tenemos el xen andando:
zaphod:~# ps ax|grep xen
31 ? S< 0:00 [xenwatch]
32 ? S< 0:00 [xenbus]
3340 ? S 0:00 /usr/lib/xen-3.2-1/bin/xenstored --pid-file /var/run/xenstore.pid
3348 ? S 0:00 python /usr/lib/xen-3.2-1/bin/xend start
3350 ? Sl 0:01 python /usr/lib/xen-3.2-1/bin/xend start
3352 ? Sl 0:00 /usr/lib/xen-3.2-1/bin/xenconsoled
3655 pts/0 R+ 0:00 grep xen
5. Configuración inicial de bridge
zaphod:~# brctl show
bridge name bridge id STP enabled interfaces
xenbr0 8000.00221918297b no intranet
6. Levantar un domU. Copiar la imagen generada al dom0.
6.1. marte:/etc/xen# mkdir zaphod
6.2. marte:/etc/xen/zaphod# scp -r root@cualquiera:/srv/xendomains/imagen_test .
6.3. marte:/etc/xen/zaphod# scp -r root@cualquiera:/etc/xen/imagen_test.cfg .
6.4. marte:/etc/xen/zaphod# xm create -c imagen_test.cfg
7. Una vez levantado el domU: se prueba loguearse al mismo y salir a internet.
7.1. Se comprueba que el domU ya esté levantado.
zaphod:~# xm list
Name ID Mem VCPUs State Time(s)
Domain-0 0 1024 4 r----- 144.4
imagen_test 1 512 2 -b---- 1.5
7.2. Se accede al domU (minmei), y se prueba salir a internet.
user@imagen_test:~$ ping google.com
PING google.com (74.125.45.100) 56(84) bytes of data.
64 bytes from yx-in-f100.google.com (74.125.45.100): icmp_seq=1 ttl=243 time=173 ms
# para referirnos a superusuario (root)
$ para referirnos a un usuario
1. Instalo ifrename.
zaphod:~#apt-get install ifrename xen-linux-system-2.6.26-1-xen-amd64 xen-tools xen-utils bridge-utils -t testing
2. Configuro el ifrename.
zaphod:~# echo "intranet mac 00:22:19:18:29:7b" > /etc/iftab
zaphod:~# ifdown eth4
zaphod:~# ifup intranet
zaphod:~# /etc/init.d/ifrename start
3. Configuro la interfaz de red en modo estático.
zaphod:~# cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
allow-hotplug xenbr0
iface xenbr0 inet static
address 172.16.0.44
netmask 255.255.128.0
gateway 172.16.0.1
bridge_ports intranet
bridge_stp off
bridge_fd 0
4. Aparentemente tenemos el xen andando:
zaphod:~# ps ax|grep xen
31 ? S< 0:00 [xenwatch]
32 ? S< 0:00 [xenbus]
3340 ? S 0:00 /usr/lib/xen-3.2-1/bin/xenstored --pid-file /var/run/xenstore.pid
3348 ? S 0:00 python /usr/lib/xen-3.2-1/bin/xend start
3350 ? Sl 0:01 python /usr/lib/xen-3.2-1/bin/xend start
3352 ? Sl 0:00 /usr/lib/xen-3.2-1/bin/xenconsoled
3655 pts/0 R+ 0:00 grep xen
5. Configuración inicial de bridge
zaphod:~# brctl show
bridge name bridge id STP enabled interfaces
xenbr0 8000.00221918297b no intranet
6. Levantar un domU. Copiar la imagen generada al dom0.
6.1. marte:/etc/xen# mkdir zaphod
6.2. marte:/etc/xen/zaphod# scp -r root@cualquiera:/srv/xendomains/imagen_test .
6.3. marte:/etc/xen/zaphod# scp -r root@cualquiera:/etc/xen/imagen_test.cfg .
6.4. marte:/etc/xen/zaphod# xm create -c imagen_test.cfg
7. Una vez levantado el domU: se prueba loguearse al mismo y salir a internet.
7.1. Se comprueba que el domU ya esté levantado.
zaphod:~# xm list
Name ID Mem VCPUs State Time(s)
Domain-0 0 1024 4 r----- 144.4
imagen_test 1 512 2 -b---- 1.5
7.2. Se accede al domU (minmei), y se prueba salir a internet.
user@imagen_test:~$ ping google.com
PING google.com (74.125.45.100) 56(84) bytes of data.
64 bytes from yx-in-f100.google.com (74.125.45.100): icmp_seq=1 ttl=243 time=173 ms
Puppet
Es un sistema que permite la administración centralizada de un gran numero de máquinas basada en una estructura cliente-servidor. Es una herramienta open source escrita en Ruby, diseñada para funcionar en la mayoría de los sistemas operativos UNIX.
En puppet los servidores centrales, llamados puppetmasters, son instalados y configurados. La configuración es definida en el puppetmaster, compilada y luego es empujada a los clientes puppets cuando éstos se conectan.
El término cliente refiere al servicio del cliente puppet (ó puppetd), el cual se conecta al puppetmaster y se trae la configuración; mientras que el término nodo hace referencia al host sobre el cual las configuraciones son aplicadas.
Las sesiones de puppet son encriptadas y autenticadas mediante el uso de certificados autofirmados. Cada cliente puppet, nodo, genera un certificado autofirmado, que es validado y autorizado por el puppetmaster. Luego, cada cliente se conecta al puppetmaster para confirmar que su configuración se encuentra al día, si la misma ha cambiado, se recompilará y se aplicarán los cambios al cliente puppet.
Los resultados de todas las actividades son logueadas y transmitidas al puppetserver, y podrán ser visualizadas con coquetos colores.
Puppet es una combinación de: un lenguaje declarativo, mediante el uso de ruby; y la abstracción de la capa de recursos, pues puppet detecta la plataforma del nodo y funciona con la gran mayoría de los Unix.
Requerimientos en el servidor
* Los desarrolladores de puppet recomiendan un cpu con 2GB de ram para la administración de 50 a 100 nodos.
Comunicación inicial cliente-servidor (certificados)
1. Para la comunicación entre servidor puppet y cliente puppet es necesario tener habilitado y disponible el puerto 8140.
2. El servidor puppet se denominará simplemente PUPPET. El nodo puppet será MINMEI.
Configuración del servidor
1. Instalación de paquetes en el servidor puppet:
puppet:~# apt-get install puppetmaster -t testing
El finalizar el paso anterior el servidor puppet, denominado puppetmaster en debian, intentará levantar. El cual fallará debido a que no hay ningún manifiesto instalado, don't worry es inofensivo, necesitamos seguir configurando.
2. Habilitar el "servidor de archivos" (ubicado en /etc/puppet/files) propio de puppet:
puppet:~# vi /etc/puppet/fileserver.conf
[files]
path /etc/puppet/files
allow *.intranet
Creación de un manifiesto o receta (ubicado en /etc/puppet/manifests).
puppet:/etc/puppet/manifests# vi site.pp
########################
# Test inicial site.pp #
########################
class test_class {
file { "/tmp/testfile":
ensure => present,
mode => 644,
owner => root,
group => root,
}
}
node minmei {
I include test_class
}
El manifiesto anterior le dirá a puppet que genere en el nodo minmei un archivo de configuración vacío con los permisos antes definidos. El manifiesto por default debe llamarse site.pp, si existiesen otros manifiestos los mismos deben ser llamados desde site.pp a través de la claúsula import.
4. Lanzar el servicio en modo foreground y debug, de modo de tener la salida por consola.
puppet:~# puppetmasterd --debug --no-daemonize
Nota: puede lanzarse el servicio al modo clásico de debian "/etc/init.d/puppetmaster start" , es opcional. El primer modo es útil para informarnos debido a que puppet no genera logs muy descriptivos en "/var/log/puppet".
Configuración del cliente
1. Instalación de paquetes en el cliente puppet en minmei.
minmei:~# apt-get install puppet -t testing
Una vez que el paquete ha sido instalado es necesario configurar en el cliente puppet el nombre del servidor puppet. Por defecto intentará resolver el hostname puppet y conectarse al mismo.
2. En caso de que el servidor puppet no se llame puppet, es necesario explicitarlo manualmente así:
minmei:~# vi /etc/puppet/puppet.conf
[puppetd]
server = nombre_del_servidor.intranet
logdir = /var/log/puppet
vardir = /var/lib/puppet
rundir = /var/run
Nota: si el hostname del servidor puede resolverse como puppet NO ES NECESARIO llevar adelante éste paso.
3. Testear la conectividad del cliente puppet , puppetd, con el servidor puppet. Para ello lanzar el servicio así:
minmei:~# puppetd --server puppet.intranet --waitforcert 60 --no-daemonize --test
err: No certificate; running with reduced functionality.
info: Creating a new certificate request for pclient.example.con
info: Requesting certificate
warning: peer certificate won't be verified in this SSL session
notice: Did not receive certificate
De éste modo tendremos la salida por consola, lo cual es más práctico de debuggear. Igualmente es posible lanzar el servicio del cliente puppet al modo clásico de debian: "/etc/init.d/puppetd start".
Intercambio de certificados
Como mencioné al principio, puppet utiliza certificado para la comunicación en la red y el control de acceso al servidor.
La primera vez que se lanza el servicio del puppet cliente en el nodo, como se explica en el paso anterior, puppetd enviará su certificado y solicitará que el puppetmaster lo firme.
1. Del lado del servidor puppet, se debería correr el sgte comando, que listará aquellos certificados a la espera de ser firmados:
puppet:~# puppetca --list
minmei.intranet
Luego que el servidor master firma el certificado (que se encuentra a la espera del nodo minmei) el cliente puppet de minmei solicitará cada X tiempo las configuraciones definidas en el servidor puppet.
2. Firma de certificados:
puppet:~# puppetca --sign minmei.intranet
Si el certificado fué firmado, al ejecutar "puppetca --list" no debería mostrar certificados a la espera de ser firmados.
Los certificados se encuentran almacenados, tanto en el cliente como en el servidor, en /var/lib/puppet/ssl. En el servidor puppet los certificados firmados se encuentran en /var/lib/puppet/ssl/ca/signed. Si bien debian los almacena en /etc/ssl/certs, puppet no los busca allí.
Compruebo que las configuraciones fueron tomadas en el cliente
1. Compruebo si existe el archivo con sus correspondientes permisos en minmei:
minmei:# ls -l /tmp/testfile
-rw-r--r-- 1 root root 0 2008-12-16 13:00 /tmp/testfile
Casos de uso
Gestión de APT: el nodo minmei se trae del servidor puppet (a través del protocolo puppet) la configuración completa de apt y realiza una actualización del listado de paquetes una vez al día en el rango horario especificado.
puppet:~# vi /etc/puppet/manifests/site.pp
## Gestión de APT vía puppet
class apt {
file {
"/etc/apt":
ensure => directory,
owner => "root",
group => "root",
recurse => true,
source => "puppet:///files/apt";
"/etc/apt/preferences":
ensure => "/etc/apt/preferences-host"
}
schedule {
"daily":
period => daily,
range => "10-12",
repeat => 1
}
exec {
"/usr/bin/apt-get update":
schedule => daily
}
}
## Nodos que tomaran la configuración
node minmei {
include apt
}
Nota: la línea source => "puppet:///files/apt"; busca en el directorio de archivos del servidor puppet.intranet el directorio de configuración apt que se trae el cliente. Cuando el nombre del servidor puppet no es puppet la línea de source sería source => "puppet://nombre_servidor_puppet.intranet/files/apt";.
En puppet los servidores centrales, llamados puppetmasters, son instalados y configurados. La configuración es definida en el puppetmaster, compilada y luego es empujada a los clientes puppets cuando éstos se conectan.
El término cliente refiere al servicio del cliente puppet (ó puppetd), el cual se conecta al puppetmaster y se trae la configuración; mientras que el término nodo hace referencia al host sobre el cual las configuraciones son aplicadas.
Las sesiones de puppet son encriptadas y autenticadas mediante el uso de certificados autofirmados. Cada cliente puppet, nodo, genera un certificado autofirmado, que es validado y autorizado por el puppetmaster. Luego, cada cliente se conecta al puppetmaster para confirmar que su configuración se encuentra al día, si la misma ha cambiado, se recompilará y se aplicarán los cambios al cliente puppet.
Los resultados de todas las actividades son logueadas y transmitidas al puppetserver, y podrán ser visualizadas con coquetos colores.
Puppet es una combinación de: un lenguaje declarativo, mediante el uso de ruby; y la abstracción de la capa de recursos, pues puppet detecta la plataforma del nodo y funciona con la gran mayoría de los Unix.
Requerimientos en el servidor
* Los desarrolladores de puppet recomiendan un cpu con 2GB de ram para la administración de 50 a 100 nodos.
Comunicación inicial cliente-servidor (certificados)
1. Para la comunicación entre servidor puppet y cliente puppet es necesario tener habilitado y disponible el puerto 8140.
2. El servidor puppet se denominará simplemente PUPPET. El nodo puppet será MINMEI.
Configuración del servidor
1. Instalación de paquetes en el servidor puppet:
puppet:~# apt-get install puppetmaster -t testing
El finalizar el paso anterior el servidor puppet, denominado puppetmaster en debian, intentará levantar. El cual fallará debido a que no hay ningún manifiesto instalado, don't worry es inofensivo, necesitamos seguir configurando.
2. Habilitar el "servidor de archivos" (ubicado en /etc/puppet/files) propio de puppet:
puppet:~# vi /etc/puppet/fileserver.conf
[files]
path /etc/puppet/files
allow *.intranet
Creación de un manifiesto o receta (ubicado en /etc/puppet/manifests).
puppet:/etc/puppet/manifests# vi site.pp
########################
# Test inicial site.pp #
########################
class test_class {
file { "/tmp/testfile":
ensure => present,
mode => 644,
owner => root,
group => root,
}
}
node minmei {
I include test_class
}
El manifiesto anterior le dirá a puppet que genere en el nodo minmei un archivo de configuración vacío con los permisos antes definidos. El manifiesto por default debe llamarse site.pp, si existiesen otros manifiestos los mismos deben ser llamados desde site.pp a través de la claúsula import.
4. Lanzar el servicio en modo foreground y debug, de modo de tener la salida por consola.
puppet:~# puppetmasterd --debug --no-daemonize
Nota: puede lanzarse el servicio al modo clásico de debian "/etc/init.d/puppetmaster start" , es opcional. El primer modo es útil para informarnos debido a que puppet no genera logs muy descriptivos en "/var/log/puppet".
Configuración del cliente
1. Instalación de paquetes en el cliente puppet en minmei.
minmei:~# apt-get install puppet -t testing
Una vez que el paquete ha sido instalado es necesario configurar en el cliente puppet el nombre del servidor puppet. Por defecto intentará resolver el hostname puppet y conectarse al mismo.
2. En caso de que el servidor puppet no se llame puppet, es necesario explicitarlo manualmente así:
minmei:~# vi /etc/puppet/puppet.conf
[puppetd]
server = nombre_del_servidor.intranet
logdir = /var/log/puppet
vardir = /var/lib/puppet
rundir = /var/run
Nota: si el hostname del servidor puede resolverse como puppet NO ES NECESARIO llevar adelante éste paso.
3. Testear la conectividad del cliente puppet , puppetd, con el servidor puppet. Para ello lanzar el servicio así:
minmei:~# puppetd --server puppet.intranet --waitforcert 60 --no-daemonize --test
err: No certificate; running with reduced functionality.
info: Creating a new certificate request for pclient.example.con
info: Requesting certificate
warning: peer certificate won't be verified in this SSL session
notice: Did not receive certificate
De éste modo tendremos la salida por consola, lo cual es más práctico de debuggear. Igualmente es posible lanzar el servicio del cliente puppet al modo clásico de debian: "/etc/init.d/puppetd start".
Intercambio de certificados
Como mencioné al principio, puppet utiliza certificado para la comunicación en la red y el control de acceso al servidor.
La primera vez que se lanza el servicio del puppet cliente en el nodo, como se explica en el paso anterior, puppetd enviará su certificado y solicitará que el puppetmaster lo firme.
1. Del lado del servidor puppet, se debería correr el sgte comando, que listará aquellos certificados a la espera de ser firmados:
puppet:~# puppetca --list
minmei.intranet
Luego que el servidor master firma el certificado (que se encuentra a la espera del nodo minmei) el cliente puppet de minmei solicitará cada X tiempo las configuraciones definidas en el servidor puppet.
2. Firma de certificados:
puppet:~# puppetca --sign minmei.intranet
Si el certificado fué firmado, al ejecutar "puppetca --list" no debería mostrar certificados a la espera de ser firmados.
Los certificados se encuentran almacenados, tanto en el cliente como en el servidor, en /var/lib/puppet/ssl. En el servidor puppet los certificados firmados se encuentran en /var/lib/puppet/ssl/ca/signed. Si bien debian los almacena en /etc/ssl/certs, puppet no los busca allí.
Compruebo que las configuraciones fueron tomadas en el cliente
1. Compruebo si existe el archivo con sus correspondientes permisos en minmei:
minmei:# ls -l /tmp/testfile
-rw-r--r-- 1 root root 0 2008-12-16 13:00 /tmp/testfile
Casos de uso
Gestión de APT: el nodo minmei se trae del servidor puppet (a través del protocolo puppet) la configuración completa de apt y realiza una actualización del listado de paquetes una vez al día en el rango horario especificado.
puppet:~# vi /etc/puppet/manifests/site.pp
## Gestión de APT vía puppet
class apt {
file {
"/etc/apt":
ensure => directory,
owner => "root",
group => "root",
recurse => true,
source => "puppet:///files/apt";
"/etc/apt/preferences":
ensure => "/etc/apt/preferences-host"
}
schedule {
"daily":
period => daily,
range => "10-12",
repeat => 1
}
exec {
"/usr/bin/apt-get update":
schedule => daily
}
}
## Nodos que tomaran la configuración
node minmei {
include apt
}
Nota: la línea source => "puppet:///files/apt"; busca en el directorio de archivos del servidor puppet.intranet el directorio de configuración apt que se trae el cliente. Cuando el nombre del servidor puppet no es puppet la línea de source sería source => "puppet://nombre_servidor_puppet.intranet/files/apt";.
GnuPG
Los métodos de cifrado son una buena alternativa como barrera de seguridad. En Linux disponemos de GnuPG, versión del código libre de PGP, la que nos permite cifrar los mensajes utilizando pares de claves asimétricas. Las claves públicas suelen ser compartidas con otros usuarios depositándolas en los servidores de claves, mientras que la privada debe permanecer SOLO con su propietario. GPG usa para ello algoritmos no patentados, a saber: ElGamal, CAST5, 3DES, AES y Blowfish.
Utilizaremos como estándar de documentación:
# para referirnos a superusuario (root)
$ para referirnos a un usuario
Definir un server por default
vi .gnupg/gpg.conf
keyserver hkp://subkeys.pgp.net
Generar par de claves pública/privada
Se generará un par de llaves público/privada.
gpg --gen-key
Se requiere especificar, según se pida, a continuación:
1. Tamaño de la llave.
2. Caducidad de el par de claves.
3. Ingresar información de usuario.
Agregar GPG pública
gpg --keyserver hkp://subkeys.pgp.net --recv-keys ABCDEGFH
Listar keys privadas
Lista todas aquellas claves públicas adheridas a tu ” ~/.gnupg/pubring.gpg”.
gpg --list-keys
Validar key
Se valida verificando la huella digital de la key y firmándola para certificar su validez.
La huella digital de una clave se verifica con el propietario de la clave. Esto puede hacerse en persona o por teléfono, o por medio de otras maneras. Si la huella digital que se obtiene por medio del propietario es la misma que la que se obtiene de la clave, entonces se puede estar seguro de que se está en posesión de una copia correcta de la clave. Después de comprobar la huella digital ya se puede firmar la clave con el fin de validarla.
gpg --edit-key username@gmail.com
Command> fpr
Command> sign
Command> check
Command> quit
Renovar key privada
La idea es que la key privada tiene una fecha de caducación que es definida cuando es creada. Una vez cumplida esa fecha, la misma expira, y es requerido renovarla. A saber: La actualizo localmente, y guardo los cambios.
gpg --edit-key ID expire
Command> save
Donde ID podría ser nombre y apellido de persona. Envió los cambios a algún server para que se actualicen.. A partir de allí puede decirse que la key privada fué renovada exitosamente.
gpg --keyserver hkp://subkeys.pgp.net --send-keys ABCDEFGH
Puedo comprobar la esperada actualización de expiración de la key.
gpg --list-key
Renovar subkey privada
La subkey es “El gamal”(que permite cifrar + firmar). Es posible que una vez caducada nuestro par de claves gpg, y luego de renovadas (Paso anterior) NO SE HAYA ACTUALIZADO la fecha de expiración de la subkey. Cómo hacerlo? »
gpg --edit-key ABCDEFGH
Command> key 1 # donde key 1=subkey. pub 1024D/ABCDEFGH created: 2007-03-12 expires: never usage: SC trust: ultimate validity: ultimate sub* 1024g/ABCDEFGH created: 2007-03-12 expires: never usage: E [ultimate] (1). Username username@gmail.com Command> save
gpg --keyserver hkp://subkeys.pgp.net --send-keys ABCDEFGH
Puedo comprobar la esperada actualización de expiración de la key.
gpg --list-key
Generar certificado de revocación
En el caso de perder contraseña, extravío de key privada, el certificado de revocación sse hará público. De modo que los usuarios de la misma serán notificados de que la clave pública NO DEBERÁ ser usada nunca más.
gpg --output revoke.asc --gen-revoke ABCDEFGH
gpg --keyserver hkp://subkeys.pgp.net --send-keys ABCDEFGH
OBLIGATORIAMENTE: se pedirá ingresar la passprhase para confirmar la operación.
Cifrar archivo
gpg -c file_a_encriptar
El comando anterior generará “file_a_encriptar.gpg”, el cual es una copia idéntica de “file_a_encriptar” pero encriptado. Lo encriptará luego de ingresar correctamente dos veces la passphrase.
Descifrar archivo
gpg --output file_desencriptado --decrypt file_encriptado.gpg
“file_desencriptado” es un archivo idéntico a “file_encriptado.gpg” DESENCRIPTADO. Para hacer esta acción pedirá passphrase.
Exportar clave pública
La idea es copiar la llave pública a un archivo, en este caso file_with_publickey.asc, en formato ASCII, para después trasladarlo.
gpg --armor --output file_with_publickey.asc --export usuario@gmail.com
Utilizaremos como estándar de documentación:
# para referirnos a superusuario (root)
$ para referirnos a un usuario
Definir un server por default
vi .gnupg/gpg.conf
keyserver hkp://subkeys.pgp.net
Generar par de claves pública/privada
Se generará un par de llaves público/privada.
gpg --gen-key
Se requiere especificar, según se pida, a continuación:
1. Tamaño de la llave.
2. Caducidad de el par de claves.
3. Ingresar información de usuario.
Agregar GPG pública
gpg --keyserver hkp://subkeys.pgp.net --recv-keys ABCDEGFH
Listar keys privadas
Lista todas aquellas claves públicas adheridas a tu ” ~/.gnupg/pubring.gpg”.
gpg --list-keys
Validar key
Se valida verificando la huella digital de la key y firmándola para certificar su validez.
La huella digital de una clave se verifica con el propietario de la clave. Esto puede hacerse en persona o por teléfono, o por medio de otras maneras. Si la huella digital que se obtiene por medio del propietario es la misma que la que se obtiene de la clave, entonces se puede estar seguro de que se está en posesión de una copia correcta de la clave. Después de comprobar la huella digital ya se puede firmar la clave con el fin de validarla.
gpg --edit-key username@gmail.com
Command> fpr
Command> sign
Command> check
Command> quit
Renovar key privada
La idea es que la key privada tiene una fecha de caducación que es definida cuando es creada. Una vez cumplida esa fecha, la misma expira, y es requerido renovarla. A saber: La actualizo localmente, y guardo los cambios.
gpg --edit-key ID expire
Command> save
Donde ID podría ser nombre y apellido de persona. Envió los cambios a algún server para que se actualicen.. A partir de allí puede decirse que la key privada fué renovada exitosamente.
gpg --keyserver hkp://subkeys.pgp.net --send-keys ABCDEFGH
Puedo comprobar la esperada actualización de expiración de la key.
gpg --list-key
Renovar subkey privada
La subkey es “El gamal”(que permite cifrar + firmar). Es posible que una vez caducada nuestro par de claves gpg, y luego de renovadas (Paso anterior) NO SE HAYA ACTUALIZADO la fecha de expiración de la subkey. Cómo hacerlo? »
gpg --edit-key ABCDEFGH
Command> key 1 # donde key 1=subkey. pub 1024D/ABCDEFGH created: 2007-03-12 expires: never usage: SC trust: ultimate validity: ultimate sub* 1024g/ABCDEFGH created: 2007-03-12 expires: never usage: E [ultimate] (1). Username username@gmail.com Command> save
gpg --keyserver hkp://subkeys.pgp.net --send-keys ABCDEFGH
Puedo comprobar la esperada actualización de expiración de la key.
gpg --list-key
Generar certificado de revocación
En el caso de perder contraseña, extravío de key privada, el certificado de revocación sse hará público. De modo que los usuarios de la misma serán notificados de que la clave pública NO DEBERÁ ser usada nunca más.
gpg --output revoke.asc --gen-revoke ABCDEFGH
gpg --keyserver hkp://subkeys.pgp.net --send-keys ABCDEFGH
OBLIGATORIAMENTE: se pedirá ingresar la passprhase para confirmar la operación.
Cifrar archivo
gpg -c file_a_encriptar
El comando anterior generará “file_a_encriptar.gpg”, el cual es una copia idéntica de “file_a_encriptar” pero encriptado. Lo encriptará luego de ingresar correctamente dos veces la passphrase.
Descifrar archivo
gpg --output file_desencriptado --decrypt file_encriptado.gpg
“file_desencriptado” es un archivo idéntico a “file_encriptado.gpg” DESENCRIPTADO. Para hacer esta acción pedirá passphrase.
Exportar clave pública
La idea es copiar la llave pública a un archivo, en este caso file_with_publickey.asc, en formato ASCII, para después trasladarlo.
gpg --armor --output file_with_publickey.asc --export usuario@gmail.com
Servidor de logs con Syslog-ng
Servidor de logs con Syslog-ng ¶
Los registros de logs nos sirven para comprobar la salud del sistema. Puede utilizarse localmente o enviar mensajes a través de la red desde una fuente a otro host de registro. La "buena nueva" se llama Syslog-ng que vino a salvar las falencias de syslog. Si bien éste último se convirtió en un estándar de facto, tiene falencias importantes, a saber:
- Falta de métodos de autenticación, es decir, Syslogd no puede distinguir entre distintos hosts.
- Transmisión de mensajes en claro.
- No registra el orígen de la fuente, es decir, cuando un mensaje pasa por distintos servidores de registros cambia su ip. Syslog no almacena el FQDN. Y en grandes redes, esto se vuelve un poco impráctico.
- Syslogd solo utiliza mensajes UDP para la transferencia, entonces si un paquete se pierde en la red, el mensaje nunca llegará a destino.
Syslog-ng vino para salvar estas falencias :)
Instalación ¶
En Debian..
apt-get update ; apt-get install syslog-ng
Configuración ¶
El único archivo de configuración se encuentra en /etc/syslog-ng/syslog-ng.conf
En el original syslog teníamos: original y priority. En syslog-ng tenemos: logpaths formado por: source, filter y destination. Los controladores fuentes:
- file y pipe usadas como fuentes desde las cuales el servicio lee mensajes y no como destino a donde redirigirlos.
- file abre el archivo especificado.
- UDP y TCP, escucha mensajes en un perto udp/tcp respectivamente.
Los filtros determinan como syslog-ng deberia filtrar los mensajes que recibe de las diferentes fuentes. Mediante los filtros se organizan y restringen los mensajes para enviarlos a sus correspondientes destinos quedando los registros de logs finalmente ordenaditos.
Los distintos filtros que pueden utilizarce son:
- facility: utilidad que origina los logs.
- level / priority
- program: filtra aquellos mensajes donde el campo "nombre del programa" es coincidente con la expresión regular especificada.
- host: filtra mensajes donde el campo "nombre del host" coincide con la expresión regular especificada.
- filter: llama a otra "regla filtro".
- match: aplica la expresión regular especificada.
Los destinos especifian dónde y porqué medios un mensaje debe ser redirigido y procesado.
Syslog-ng llama al controlador una única vez y lo mantiene ejecutándose hasta que el servicio recibe la señal de "terminar" (SIGHUP). Esto es muy eficiente porque si Syslog-ng lanzace un programa externo por cada mensaje entonces sería muy fácil para un atacante lanzar varios procesos similar a un ataca DOS.
Opciones Globales ¶
vi /etc/syslog-ng/syslog-ng.conf
chain_hostnames(0);
time_reopen(10);
time_reap(360);
sync(0);
stats(43200);
log_fifo_size(2048);
use_dns(no);
use_fqdn(no);
source s_all {
internal();
# standard Linux log source (this is the default place for the syslog()
# function to send logs to)
unix-stream("/dev/log");
# messages from the kernel
file("/proc/kmsg" log_prefix("kernel: "));
};
Lado cliente ¶
###########
# Destinos
destination df_auth { udp("172.16.0.17");};
destination df_syslog { udp("172.16.0.17"); };
##########
# Filtros
# Todos los mensajes vienen de las utilidades: auth y authpriv
filter f_auth { facility(auth, authpriv); };
# Todos los mensajes vienen EXCEPTO de las utilidades: auth y authpriv
filter f_syslog { not facility(auth, authpriv); };
#########
# Reglas
log {
source(s_all);
filter(f_auth);
destination(df_auth);
};
log {
source(s_all);
filter(f_syslog);
destination(df_syslog);
};
Lado servidor ¶
vi /etc/syslog-ng/syslog-ng
source s_net {
udp(); #los mensajes de logs pueden ser enviados electivamente a través de TCP o UDP
# tcp();
};
filter f_slapd {match("slapd"); };
filter f_dhcp {match("dhcp"); };
destination df_slapd { file("/var/log/slapd.log"); };
destination df_dhcp { file("/var/log/dhcpd3.log"); };
log{
source(s_net);
filter(f_dhcp);
destination(df_dhcp);
};
log{
source(s_net);
filter(f_slapd);
destination(df_slapd);
};
Manejo de logs con Socklog
Introducción
Es un sistema de log que trabaja en conjunto con runit y se encarga de rotar los logs automáticamente. Para utilizar socklog es necesario que el programa svlogd esté instalado, ya que es parte runit.
Instalando socklog
apt-get install socklog socklog-run
Configurando sistema de logs
Es necesario que socklog-unix escuche en el socket local de unix /dev/log. Se crean los directorios del servicio y de los logs, a través de la herramienta socklog-conf:
socklog-conf unix nobody log
Hacer un stop del syslogd/syslog-ng, en el caso de que éste se encuentre corriendo. No rebootear antes de finalizar la configuración de socklog.
ln -s /etc/sv/socklog-unix /var/service/
Verificar que socklog-unix esté siendo supervisado por runit. sv status socklog-unix
run: socklog-unix: (pid 27461) 3086s; run: log: (pid 1338) 254110s
Ver que socklog esté logueando
less /var/log/socklog/main/current
Modificar parámetros de rotación
s999999
#Cant. de archivos de logs que deberían mantenerse
n5
#Opcionalmente, se le especifica que sean compresos.
!/bin/bzip2
Remoto a través de UDP
La idea es transmitir logs a un host remoto, dentro de una red interna, a través de UDP. No es fiable, y tampoco provee autenticación entre las partes.
Lado cliente
Puede especificarse el envío de logs por servicio o decirle que envíe directamente todo.
Para el primer caso debe crearse el archivo /var/log/$SERVICIO/config.
Para el segundo caso, se especifica debajo.
s9999
n2
# '+*': se toman todos los datos. '-*': se descartan todos los datos
+*
# 'U'= se realizan logs locales, además de enviarse a un server de logs remoto. 'u'= solo se realizan logs locales.
U10.0.0.16:514
sv restart socklog-unix
Lado servidor
Remoto a traves de TCP
Es un sistema de log que trabaja en conjunto con runit y se encarga de rotar los logs automáticamente. Para utilizar socklog es necesario que el programa svlogd esté instalado, ya que es parte runit.
Documentación:
Instalando socklog
apt-get install socklog socklog-run
Configurando sistema de logs
Es necesario que socklog-unix escuche en el socket local de unix /dev/log. Se crean los directorios del servicio y de los logs, a través de la herramienta socklog-conf:
socklog-conf unix nobody log
Hacer un stop del syslogd/syslog-ng, en el caso de que éste se encuentre corriendo. No rebootear antes de finalizar la configuración de socklog.
Avisarle al supervisor de servicios, runsvdir, para que comience a supervisar socklog.
ln -s /etc/sv/socklog-unix /var/service/
Verificar que socklog-unix esté siendo supervisado por runit. sv status socklog-unix
run: socklog-unix: (pid 27461) 3086s; run: log: (pid 1338) 254110s
Ver que socklog esté logueando
less /var/log/socklog/main/current
Modificar parámetros de rotación
Vi /var/log/socklog/$SERVICIO
#Tamaño del archivo en bytes, antes de ser rotado.s999999
#Cant. de archivos de logs que deberían mantenerse
n5
#Opcionalmente, se le especifica que sean compresos.
!/bin/bzip2
Remoto a través de UDP
La idea es transmitir logs a un host remoto, dentro de una red interna, a través de UDP. No es fiable, y tampoco provee autenticación entre las partes.
Lado cliente
Puede especificarse el envío de logs por servicio o decirle que envíe directamente todo.
Para el primer caso debe crearse el archivo /var/log/$SERVICIO/config.
Para el segundo caso, se especifica debajo.
vi /var/log/socklog/main/config
s9999
n2
# '+*': se toman todos los datos. '-*': se descartan todos los datos
+*
# 'U'= se realizan logs locales, además de enviarse a un server de logs remoto. 'u'= solo se realizan logs locales.
U10.0.0.16:514
sv restart socklog-unix
sv hup socklog-unix/log
Lado servidor
Remoto a traves de TCP
Acelerando el arranque del sistema con RUNIT
Runit es un esquema de servicios supervisados. A diferencia de Sysvinit, runit permite la supervisión de servicios, y en caso de que alguno de ellos caiga, Runit tratará de levantarlo.
Utilizaremos como estándar de documentación:
# para referirnos a superusuario (root)
$ para referirnos a un usuario
1. Instalación de paquetes:
#apt-get install runit-services runit-run runit
Suponiendo que "SERVICIO" es el daemon que se quiere instalar.
1. Crear directorio donde se encontrará la configuración de servicios a supervisiar y levantar por Runit.
# mkdir /etc/sv/${SERVICIO}/
# mkdir /etc/sv/${SERVICIO}/log
5. Hago los archivos, ejecutables.
# chmod +x /etc/sv/${SERVICIO}/run
# chmod +x /etc/sv/${SERVICIO}/log/run
Es importante destacar que no todos los servicios son posible poner bajo supervisión de Runit. Debido a que Runit requiere que el nuevo servicio a supervisar funcione en FOREGROUND, u opcionalmente en modo DEBUG. Aquellos que funcionen únicamente en FOREGROUND no será posible que runit lo supervise.
Cuando un servicio corre en background, el mismo se desprende del terminal, por ejemplo: iceweasel & devolviéndonos el control y uso del terminal nuevamente, en el cual se lanzó anteriormente el navegador. En cambio cuando un servicio corre en foreground, por ejemplo: iceweasel, el terminal sigue teniendo el control del mismo, por lo cual la misma queda inutilizable, salvo por el navegador antes lanzado.
Utilizaremos como estándar de documentación:
# para referirnos a superusuario (root)
$ para referirnos a un usuario
1. Instalación de paquetes:
#apt-get install runit-services runit-run runit
Crear configuración de servicio a supervisar
Para que Runit monitoree y supervise un servicio, necesita algunos scripts y links particulares que se encuentran en el directorio /etc/sv (para la distribución STABLE). En caso que no exista la entrada del servicio a supervisar, crearla siguiendo estos pasos:Suponiendo que "SERVICIO
1. Crear directorio donde se encontrará la configuración de servicios a supervisiar y levantar por Runit.
# mkdir /etc/sv/${SERVICIO}/
# mkdir /etc/sv/${SERVICIO}/log
2. Creo directorio para logs de "mi_servicio"
# mkdir /var/log/${SERVICIO}
3. Creo script que se encarga de lanzar "mi_servicio"
# vi /etc/sv/${SERVICIO}/run
#!/bin/sh
exec 2>&1
# FIXME: poner el nombre adecuado del servicio a lanzar.
# verificar que los parametros que se pasan son adecuados, de acuerdo al init.d
# original.
exec servicio
4. Creo un ejecutable que se encarga de loguear mi_servicio
#!/bin/sh
set -e
# FIXME: Poner el nombre del servicio adecuado
# Tambien verificar si los logs estaran centralizados
SERVICIO=
LOG=/var/log/${SERVICIO}
test -d "$LOG" || mkdir -p -m0750 "$LOG" && chown log:adm "$LOG"
exec chpst -ulog:adm svlogd -tt "$LOG"
5. Hago los archivos, ejecutables.
# chmod +x /etc/sv/${SERVICIO}/run
# chmod +x /etc/sv/${SERVICIO}/log/run
6. Testear ${SERVICIO}
# cd /etc/sv/${SERVICIO}
# ./run
Poner el servicio bajo el monitoreo de Runit ¶
Luego, para poder poner bajo supervisión un servicio, debemos realizar los siguiente pasos:
1. Detener el servicio, utilizando el método tradicional.
/etc/init.d/${SERVICIO} stop
2. Luego debemos realizar un divert del paquete en el que viene el servicio. Esto es para que cuando apt actualize el paquete, no modifique el script.
Esto se realiza de la siguiente manera:
# dpkg-divert --add --rename /etc/init.d/${SERVICIO}
3. Reemplazamos el script de init del servicio por un enlace simbólico a /usr/bin/sv, para lo que previamente se recomienda realizar un backup del mismo.
# cd /etc/init.d/
# ln -s /usr/bin/sv /etc/init.d/${SERVICIO}
4. Le informamos a RunIt del nuevo servicio.
# ln -s /etc/sv/${SERVICIO} /var/service/
y listo, ya deberíamos tener bajo supervisión nuestro servicio.
5. Para poder chequear que efectivamente todo funcione bien, ejecutamos
# sv status ${SERVICIO}
y deberiamos obtener algo como:
run: cron: (pid 19833) 3s
o sino, por medio del viejo método:
# /etc/init.d/${SERVICIO} status
# run: mi_servicio: (pid 19833) 4s
Es importante destacar que no todos los servicios son posible poner bajo supervisión de Runit. Debido a que Runit requiere que el nuevo servicio a supervisar funcione en FOREGROUND, u opcionalmente en modo DEBUG. Aquellos que funcionen únicamente en FOREGROUND no será posible que runit lo supervise.
Cuando un servicio corre en background, el mismo se desprende del terminal, por ejemplo: iceweasel & devolviéndonos el control y uso del terminal nuevamente, en el cual se lanzó anteriormente el navegador. En cambio cuando un servicio corre en foreground, por ejemplo: iceweasel, el terminal sigue teniendo el control del mismo, por lo cual la misma queda inutilizable, salvo por el navegador antes lanzado.
Suscribirse a:
Entradas (Atom)
