miércoles, 14 de enero de 2015

Jugando con systemD

Hola!! después de un largo tiempo sin escribir aquí y como propósito de año nuevo, espero poder seguir escribiendo en el blog. Desde que me "lié" con el proyecto [awbian] GNU/Linux dispongo de poco tiempo para mis "frikadas" y menos para escribirlas. Ya que en awbian se ha hecho la apuesta de usar systemd como gestor del sistema, voy a recopilar un pequeño manual básico de su uso.

Esquema de la arquitectura de systemd:


Empezamos con systemctl que básicamente es el subtituto de /etc/init.d/... start/restart/stop de toda la vida. Éste tiene algunos casos de uso útiles que veremos en unas pocas líneas. Llegados a este punto, creo que es útil definir como systemd usa el término "Unit"; este se refiere a servicio, sockets, devices, puntos de montage, particiones, paths, timers, ttys... y las "units" será quien recibirá las acciones que ordenaremos con systemctl:
  1. systemctl (Lista todas las unidades, su estado, descripción)
  2. systemctl start/stop [Unidad] (arranca o para una unidad)
  3. systemctl status [Unidad] (estado de la unidad)
  4. systemctl help [Unidad](un pequeño man de cada unidad)
  5. systemctl daemon-reload (escanea si hay cambios en la Unidades)
Por ejemplo:
# systemctl status syslog-ng.service
syslog-ng.service - System Logger Daemon
   Loaded: loaded (/lib/systemd/system/syslog-ng.service; enabled)
   Active: active (running) since Wed, 14 Jan 2015 12:18:08 +0100; 2h 17min ago
 Main PID: 18789 (syslog-ng)
   CGroup: name=systemd:/system/syslog-ng.service
    └ 18789 /usr/sbin/syslog-ng -F

Podemos ver la configuración de cada unidad en  /lib/systemd/ por ejemplo en el caso de syslog tal como dice el "status" está loaded en /lib/systemd/system/syslog-ng.service
Ahora es muy facil activar o desactivar un servicio:
  1. systemctl enable/disable [unidad] (activa o desactiva una unidad) Podria ser equivalente a chkconfig o a un update-rc.d...
Esto hace surgir la duda de en que runlevel está activo... systemd controla el runlevel también:
  1. systemctl isolate graphical.target (equivale hacer init 5)
  2. systemctl isolate multi-user.target (equivale hacer init 3)
  3. systemctl reboot/poweroff/suspend/hibernate/hybrid-sleep (apagados,reinicios, etc..)
  4. systemctl set-default multi-user.target (serializamos iniciar sin X)
Las unidades se escriben con su propia sintaxis, por lo que he podido ver, basada en XDG Desktop, similar a los .ini de Windows y se hubican en: 
/lib/systemd/system/ (los paquetes suelen dejarlos aquí) 
/etc/systemd/system/ (aquí es donde haremos las modificaciones)
Otra cosa que me parece muy interesante es el análisis del arranque que nos ofrece systemd. Por ejemplo:
# systemd-analyze (nos da el resumen de lo que tarda en arrancar el sistema)
Startup finished in 3100ms (kernel) + 18727ms (userspace) = 21828ms
# systemd-analyze blame (lo mismo pero sin resumen)
  5591ms cryptsetup@ferran_home.service
  4828ms lvm2.service
  4785ms wicd.service
  4361ms exim4.service
  3668ms keyboard-setup.service
#systemd-analyze plot > bootplot.svg (genera un gráfico del tiempo de boot)
Y con esto, el primer ladrillo del año ;)
Gracias por estar aquí. Como siempre, comenta, añade lo que consideres oportuno.
Saludos

jueves, 15 de mayo de 2014

XenServer - Useful Commands Chart

Hola! Después de unos cuantos años lanzando comandos contra XenServers me planteado hacer un resumen en un solo papel (no se si lo voy a conseguir). De momento les presento la versión mas alpha que beta de lo que me gustaría que sobretodo fuera útil. Espero ir actualizándolo y mejorarlo con sus consejos y sugerencias.


Saludos!

jueves, 8 de mayo de 2014

XenServer - Autenticar XAPI mediante PAM

Hola! ¿Cómo podemos hacer para crearnos un usuario en XenServer que nos sirva para conectarnos a la XAPI por HTTP/RPC?

Pues esto es lo que veremos paso a paso en este Post gracias a mi colega OPP.

Nos conectamos al Host Master y ejecutamos:
#Añadimos PAM como external Auth
xe pool-enable-external-auth auth-type=PAM service-name=pam

#Creamos un usuario, por ejemplo xenapiuser 
useradd -s /sbin/nologin xenapiuser

#Le ponemos un password 
echo "xenapiuser:xpassword" | chpasswd

#Añade un "sujeto" (mola llamarle sujeto...)
xe subject-add subject-name=xenapiuser
#Este comando nos devolvera un uuid, por ejemplo 9fec6479-5114-d69e-c384-e2d00f4c638d

#Le asignamos el rol que queramos, por ejemplo read-only
xe subject-role-add role-name=read-only uuid=9fec6479-5114-d69e-c384-e2d00f4c638d

#Vemos que está OK
xe subject-list
 uuid ( RO)                  : 9fec6479-5114-d69e-c384-e2d00f4c638d
 subject-identifier ( RO): u501
 other-config (MRO): subject-name: xenapiuser; subject-uid: u501; subject-gid: g501; subject-gecos: ; subject-displayname: xenapiuser; subject-is-group: false; subject-account-disabled: false; subject-account-expired: false; subject-account-locked: false; subject-password-expired: false
                 roles (SRO): read-only
En el resto de "Slaves" solo hemos de ejecutar:
useradd -s /sbin/nologin xenapiuser 
echo "xenapiuser:xpassword" | chpasswd
Y con esto ya tendríamos un usuario con que poder atacar la XAPI, sin permisos para hacerle nada ;)
Saludos

viernes, 7 de febrero de 2014

AWbuntu - Awesome + mini ubuntu

Hola amigos, hoy presento aquí a AWbuntu otra metadistribución de Ubuntu con unos detalles que a mi parecer valen la pena. Básicamente es el GNU/Linux que estoy creando a partir de mis necesidades y gustos (también de los contribuidores) .

Minimalista, para mi el top one. No quiero nada de GNome, KDE, XFce... Awesome lo encuentro formidable (por no decir increíble, valga la redundancia) en cuanto a rendimiento, flexibilidad y simpleza.

Instalable o bootable en llave USB. Cómo no siempre tengo a mano mi propio PC, pues me va perfecto que sea "live", pero estar con el pendrive enchufado mientras trabajo... me parece cuanto más problemático, así que gracias a mi colega Oscar, me dio la idea de "bootear" toda la distro en RAM, así por un lado me olvido del USB, una vez arrancado el SO y por otro lado, tengo todo el rendimiento del PC al estar todo en memoria. Eso si, 1Gb de RAM lo va a usar como FileSystem, así que si un PC no tiene como mínimo 2GB deRAM... Mejor arrancar como una live normal.

Con un core Debian, aunque me gusta mucho Arch y Gentoo por su filosofía, poder usar toda paquetización ya hecha de ubuntu, me ahorra tiempo, así que en el fondo es un Xubuntu más recortado, sin xfce, clientes de mail, etc...  32 bits de momento para máxima compatibilidad.

Todo el soft mínimo para un sysadmin... Chromium-browser, Nmap, ssh, rdesktop, minicom, dropbox...

Pues nada, espero haberte vendido la moto y que la pruebes XD

Cómo de momento es una prueba, muy prueba, estoy alojando la ISO en mi Google Drive y lo puedes descargar desde aquí: http://dstats.net/fwd/3iae4

También puedes ver lo que sería su web de presentación en: http://awbuntu.zsh.jp/

Saludos!!


jueves, 16 de enero de 2014

Overflow /tmp de 1.0M

Hola! Hoy he visto un tema que me ha parecido suficientemente importante como para escribir este post.
Resulta que un server tenía montado el /tmp como overflow. Viendo un df se ve claro:
root@server:/var/log# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/xvda2      7.5G  2.4G  4.7G  34% /
udev            2.9G  4.0K  2.9G   1% /dev
tmpfs           1.2G  168K  1.2G   1% /run
none            5.0M     0  5.0M   0% /run/lock
none            3.0G     0  3.0G   0% /run/shm
overflow        1.0M  128K  896K  13% /tmp
Y dices... WTF!! Si el fstab no hay nada para el /tmp.

Pues resulta que es un sistema de protección contra quedarse sin espacio. En el caso que llegue a llenarse, se crea un nuevo punto de montaje /tmp en RAM. El tema es que no vuelve al estado original de forma automática.

Cómo tengas un JBOSS o algo que lo use, no vas a poder desmontarlo y habrá que hacer unos cuantos KILLS para poder llegar hacer un umount.

He visto que también se puede hacer:
echo 'MINTMPKB=0' > /etc/default/mountoverflowtmp 
Para desactivarlo definitivamente, pero bueno no se hasta que punto nos puede interesar dejarlo tal y como viene de serie. Que cada uno elija.

Saludos

miércoles, 18 de diciembre de 2013

XenServer Tools ISO must be ejected from all running VMs

Hola!

Algo que personalmente me parece muy pesado es cuando vas a instalar un patch en XenServer que actualiza las XenTools, como el Service Pack (XS62ESP1), recibas un mensaje de error como el siguiente:

# xe patch-apply uuid=0850b186-4d47-11e3-a720-001b2151a503 host-uuid=d1dda2db-29fe-41c6-a82b-e35ae8f05a69
The patch precheck stage failed with an unknown error.  See attached info for more details.
patch: 0850b186-4d47-11e3-a720-001b2151a503 (XS62ESP1)
info: XenServer Tools ISO must be ejected from all running VMs.

Para contraatacar esta problema, simplemente ejecutamos:
# xe vbd-list vdi-uuid=$(xe vdi-list name-label=xs-tools.iso --minimal) 

Y sabremos que máquinas virtuales tienen la iso de las Xentools "attached". Si lo que quieres es ya directamente, quitar la iso de todas, ejectuar:
# for vbd in `xe vbd-list vdi-uuid=$(xe vdi-list name-label=xs-tools.iso --minimal) --minimal | sed s/','/' '/g` ; do xe vbd-eject uuid=$vbd ; done 

También encontré en el Blog de Citrix un script llamado all-dvd-eject.sh que funciona de maravilla
http://blogs.citrix.com/2010/01/28/eject-all-dvds-from-xenserver-vms/

Saludos!!

lunes, 16 de septiembre de 2013

Cómo ver los 50 ficheros abiertos, más grandes con lsof

Hola!

Como a muchos nos ha pasado alguna vez... pasteo el lsof de la muerte que nos mostrará los 50 ficheros más grandes que tenemos abiertos en el sistema.
# lsof -s | awk '$5 == "REG"' | sort -n -r -k 7,7 | head -n 50
Así podemos ver ficheros que nos pueden estar gastando disco de forma indisciminada y verlos fácilmente ;)

Otro caso que tambien requiere una red de tuberías arcanas, para ver que procesos Dead de un sistema, y contarlos. Muy útil si por ejemplo tienes un Load Average alto o muy alto, sin embargo, haciendo un top, ves que no estas consumiendo CPU... Con lo siguiente los puedes ver y destruir con un kill -9

# top -b -n 1 | awk '{if (NR <=7) print; else if ($8 == "D") {print; count++} } END {print "Total status D: "count}'
Fuente aquí  y aquí Saludos

martes, 10 de septiembre de 2013

Configurar Powerpath en Oracle VM en vez de usar Multipath

Hola amigos! Como algunos ya sabéis estoy probando Oracle VM para backends de bases de datos. Y aquí va primer post, para configurar powerpath en vez de multipath para todos los que tengáis cabinas EMC.

Para luego verificar que vemos las mismas LUNS y mismos UUIDs, podemos guardar la salida de:
#  ls -l /dev/mapper/
total 0
lrwxrwxrwx 1 root root      12 sep 10 10:08 360060160ce2027004ed03e645919e311
lrwxrwxrwx 1 root root      12 sep 10 10:08 360060160ce202700a2ffea74fe15e311
lrwxrwxrwx 1 root root      12 sep 10 10:08 360060160ce202700ec38369a364be111
Primeramente desactivamos multipath y reniciamos el servidor
# chkconfig multipathd off
# /etc/init.d/multipathd stop
Una vez UP, miramos que no tengamos ningún device en el /dev/mapper
# ls -l /dev/mapper
total 0
crw------- 1 root root 10, 236 sep  9 15:48 control
Nos descargamos el nuevo udev del repositorio de Oracle y lo instalamos
# wget http://public-yum.oracle.com/repo/OracleVM/OVM3/latest/x86_64/udev-095-14.27.100.1.el5_7.4.2.x86_64.rpm
# rpm -Uvh udev-095-14.27.100.1.el5_7.4.2.x86_64.rpm
warning: udev-095-14.27.100.1.el5_7.4.2.x86_64.rpm: Header V3 DSA signature: NOKEY, key ID 1e5e0159
Preparing...                ########################################### [100%]
   1:udev                   ########################################### [100%]
Ahora, lo mismo pero con las versión correcta de powerpath.
# rpm -iv EMCPower.LINUX-5.7.1.01.00-006.OL5_UEK2_R3.x86_64.rpm 
Ya podemos añadir la key y reniciar
# emcpreg -add XXXX-XXXX
# reboot
Cuando tengamos otra vez el servidor arrancado, verificamos que en el device mapper estan las LUNS que teniamos con multipah con el mismo UUID. Pero primeramente acabamos de configurar PowerPath:
# powermt check_registration
# powermt set policy=co dev=all
# powermt display dev=all
# powermt save
Comprobamos el dev mapper:
# ls -l /dev/mapper/
total 0
lrwxrwxrwx 1 root root      12 sep 10 10:08 360060160ce2027004ed03e645919e311 ../emcpowerc
lrwxrwxrwx 1 root root      12 sep 10 10:08 360060160ce202700a2ffea74fe15e311 ../emcpowerb
lrwxrwxrwx 1 root root      12 sep 10 10:08 360060160ce202700ec38369a364be111 ../emcpowera
Con esto ya tendríamos que tener incluso montado el cluster ocfs2
# df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda2              3050092   1498204   1394452  52% /
/dev/sda1               101086     28542     67325  30% /boot
tmpfs                   541872         0    541872   0% /dev/shm
none                    541872        96    541776   1% /var/lib/xenstored
/dev/emcpowere        20971520    269076  20702444   2% /poolfsmnt/0004fb0000050000b8c6c5abcb3fd94b
/dev/emcpowerd       419430400  56515584 362914816  14% /OVS/Repositories/0004fb00000300000e98b1c9f943d355
Tengo que reconocer que en algunos aspectos como el RawDevice Mapping que tiene OVM está muy bien, es una lástima que con XenServer no lo tengamos solucionado ahún :D
Saludos