Si nos dedicamos a administrar servidores es normal encontrarnos con varias sesiones SSH abiertas contra el mismo equipo. Si utilizas OpenSSH por encima de la version 4 se puede ahorrar tiempo a la hora de abrir nuevas conexiones añadiendo lo siguiente al fichero ~/.ssh/config :

1
2
3

Host *
ControlMaster auto
 ControlPath /tmp/%r@%h:%p

Lo puedes meter directamente en tu configuracion con este comando que lo descarga de un gist:

1

 curl https://raw.github.com/gist/1156836/dc964be4043b33fabb8cfd02e90168e91d2c5354/ssh_multiplex >> ~/.ssh/config

Esto le dice tu cliente SSH que siempre use un ControlMaster en todos los hosts por lo que reutiliza la conexion que ya está abierta en lugar de abrir otra. Puedes configurarlo para que te pregunte cada vez que conectas con la opcion “autoask”. En la configuracion tambien indicamos que use /tmp para guardar la informacion del socket.

El unico problema que tiene esto es que si usas tuneles SSH los tienes que inizializar con la opcion: -o ControlMaster=no

Ultimamente mi macbook air funcionaba muy mal cuando se calentaba mucho. Por lo visto, en los air si la temperatura de la CPU sube demasiado, el proceso kernel_task se pone al 150% de CPU y el equipo en general va fatal.

Desde que me compré la ipad apenas había usado el portátil y creo que la pasta térmica se había secado aun mas porque estos últimos días que si lo he usado me estaba dando muchos problemas.

Hacer que kernel_task consuma toda la CPU para intentar refrigerarla es algo que empezaron a hacer en una de las actualizaciones OSX para evitar que el propio procesador cerrase completamente un core si se estaba calentando demasiado. Como solución es una chapuza ya que cuanto mas intensivas las cosas que estés haciendo mas problemas da (los coredumps por lo menos lo enfriaban).

Una forma de evitarlo es bajando el voltaje del procesador con una aplicación que se llama coolbook. Suele funcionar bien pero hoy he estado generando indices de búsqueda de sphinx que le mete bastante carga a la cpu y era un infierno porque en media hora ya casi no podía usar el ordenador. Me he puesto a buscar en los mil hilos que hay hablando al respecto y al final lo he podido solucionar cambiando la pasta térmica.

Abrir el air es muy fácil y para acceder al procesador solo hay que quitar la tapa de abajo y unos 6 tornillos del disipador. Limpiar la que tiene y poner una cantidad muy fina de pasta nueva lleva unos 5 minutos. Lo volvemos a cerrar y solucionado.

Poner pasta térmica mala y en cantidades brutales como en la foto es una practica bastante normal de apple en todos sus portatiles. Limpiandola y poniendo una pequeña cantidad ha bajado las temperaturas 10 grados y ya no hay mas core dumps ni kernel_task comiendose la CPU.

Unos cuantos enlaces sobre el tema:

• Flickr - MacBook Air Core Shutdown - Thermal Paste Removal
• Ejemplos de como deberia estar
• Be gone. Noisy Macbook Air

En los foros de apple hay varios hilos enormes sobre kernel_task, el mas grande es este:

• Kernel_task on a new MacBook Air

Acabo de terminar de leer un libro técnico muy interesante, está orientado a administradores de sistemas o gente que tiene que administrar o desarrollar webs grandes y es de lo mejor que he leído en los últimos años.

Se llama “Web Operations - Keeping the data on time” y cada capitulo está escrito por un autor distinto centrandose en un tema concreto como por ejemplo monitorización, métricas de rendimiento, backup, provisión de equipos, S3 como almacenamiento o bases de datos NoSQL. Temas bastante normales sobre los que seguro que ya has leido mucho pero lo interesante del libro es que no explica como instalar o utilizar X programa, sino la importancia y la razón de hacerlo con las mejores practicas de expertos en cada tema.

Por ejemplo en el capitulo 5 el autor de ganglia explica las razones por las que comenzó a desarrollarlo y la forma correcta de usarlo (sacando métricas de absolutamente todo lo que puedas) pero el capitulo no se centra en ganglia sino en la funcion de las métricas en general.

En otro capitulo el creador de Chef (una herramienta de provisión de servidores similar a puppet o enginecf), nos pone en una situación muy interesante haciendonos pensar que haríamos si un tornado destruye completamente el CPD, estamos de guardia y nos toca recuperarlo. Algo que parece imposible pero es sencillo si definimos la infraestructura como código con puppet/chef.

También tenemos al director técnico de flickr explicando como los problemas mas importantes que tuvieron al migrar millones de imágenes desde Yahoo, el de Picnik con los problemas que encontraron usando S3 de amazon o al de dealnews explicando como tratan y se preparan para picos de trafico.

Los capítulos 6 y 11 hablan de la diferencia entre métricas de rendimiento y monitorizacion, y como los dos son necesarios. Es normal tener gráficas y alertas del rendimiento de las maquinas pero a veces es bueno tener alertas a nivel lógico como por ejemplo: “Si se han registrado menos de 10 usuarios en 24 horas, alerta”. Este tipo de métricas a nivel de la applicacion para saber cuantos usuarios se registran, el numero de ventas en una semana, el numero de imágenes que se añaden cada día, etc, son muy útiles para planificar la infraestructura que necesitaremos en el futuro.

El capitulo 10 trata la colaboración entre los departamentos de sistemas y desarrollo y los conflictos entre los dos grupos. Es algo que yo vivo a diario donde trabajo ya que casi siempre hay una gran separación entre los dos equipos y muchas veces no existen procedimientos para colaborar, hacer deployments o tests de forma sencilla (sobre todo para los desarrolladores).

El libro presupone que quieres tener una infraestructura resistente a fallos y estas dispuesto a trabajar para tenerla. Vamos, que te importa la aplicación en la que estas trabajando, la gente con la que trabajas y los usuarios que utilizan la aplicación.

Enlaces y mas reviews

• Web Operations - O’really - Pagina oficial con la tabla de contenidos
• Web Operations - Google Preview - Preview del libro en google books
• Web Operations - Amazon
• A review of web operations @Xapbr

Cron es un servicio típico de maquinas unix para ejecutar comandos a horas predefinidas. Nos permite ejecutar un script de forma automática cada 4 minutos, los viernes a las 3:34 de la mañana, o todos los días a las 12 de la noche. Casi todos los servidores unix tienen varios scripts de mantenimiento que se ejecutan mediante cron por las noches y la mayoría de aplicaciones web grandes suelen necesitar también varios comandos en el cron.

En frozen-layer por ejemplo tenemos bastantes trabajos en el crontab, cada 15 minutos se actualizan los seed/peers de torrents, cada 2 horas se actualizan los indices de búsquedas, a diario se sincronizan los usuarios con el foro, backups de las bases de datos, feeds rss de usuarios, etc, etc…

Una función de cron bastante interesante y no muy conocida son las variables especiales que se le puede pasar en lugar de la hora, sobre todo @reboot.

Si ponemos @reboot en lugar de la hora el comando se ejecutará al arrancarse la maquina. Es muy útil para lanzar servicios sin tocar archivos en init.d/rc.d o lanzar comandos bajo otros usuarios de forma sencilla. Yo lo suelo utilizar para que una maquina virtual sin configurar ejecute puppet automáticamente la primera vez que arranca.

Por ejemplo, si ponemos en nuestro crontab:

@reboot www nginx start

Al encender la maquina arrancaría nginx bajo el usuario www.

También podemos sustituir la fecha por otras cosas, la lista completa de palabras reservadas:

1
2
3
4
5
6
7
8
9
10

Entry    Description     Equivalent To

@reboot   Run once, at startup.   None
@yearly   Run once a year     0 0 1 1 *
@annually     (same as @yearly)   0 0 1 1 *
@monthly  Run once a month    0 0 1 * *
@weekly   Run once a week     0 0 * * 0
@daily    Run once a day  0 0 * * *
@midnight     (same as @daily)    0 0 * * *
@hourly   Run once an hour    0 * * * *

Es muy útil a la hora de crear maquinas virtuales ya que nada mas arrancar se conectan automáticamente al servidor de puppet y empiezan a configurar los servicios.

Enlaces

• Manual de cron
• Tips for cron

Uno de los problemas de configurar la terminal a tu gusto es mantenerla sincronizada entre ordenadores. Cuando tienes muchos aliases y te acostumbras a poner por ejemplo “sshr” en lugar de “ssh root@ ” es realmente frustrante llegar a otro ordenador y no poder usar ese mismo comando. A diario suelo usar 3 ordenadores (portátil, casa y trabajo) y la terminal es el programa que mas uso. Antes solía mantener un repositorio de subversion para sincronizar este tipo de ficheros pero desde hace casi un año lo hago de una forma mucho mas cómoda usando Dropbox.

.bash_profile es un archivo oculto (por eso lleva un punto delante) que se ejecuta cada vez que abres una nueva terminal y puedes encontrarlo en tu home (en mi mac: /Users/deasunrise/.bash_profile ).  Hay varias formas de mantener el fichero sincronizado usando dropbox. Una de ellas es crear un enlace simbólico contra el archivo en dropbox, otra opcion que para mi es mejor es poner una linea en el bash_profile original que cargue el bash que nos interesa:

. ~/Dropbox/Configs/bash_profile

Y en ese bash_profile que mantenemos en dropbox ponemos la configuración que necesitemos y unos cuantos alias para evitar tener que teclear los mismos comandos una y otra vez.  Algunos ejemplos de mi configuración:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

# Prompt
export TERM=xterm

#Configuramos el color y formato del prompt, esta linea nos muestra el usuario con el que estamos logeados
# y el directorio actual en color verde  (ej: deadsunrise /home $   )

export PS1="\[\e[32;1m\]\u \w \$ \[\e[0m\]"

export PATH=/usr/local/git/bin:/Users/deadsunrise/.gem/ruby/1.8/bin:/Developer/android/tools:/opt/subversion/bin:$PATH

#Ponemos textmate como editor de texto
export SVN_EDITOR='/usr/bin/mate -w'
export EDITOR='/usr/bin/mate -w'

export MANPATH=/usr/local/git/man:$MANPATH
#activamos los colores en la terminal

export CLICOLOR=1

# Un atajo para poder editar este archivo de forma rapida
alias bbash="mate ~/Deadsunrise/Configs/bash_profile"

# Atajos varios
alias ls='ls -Ga'
alias ll='ls -hal'
alias alive='ping 194.30.0.1'
alias sshr='ssh -l root'
alias sshp='ssh -l portero'
alias flushdns='dscacheutil -flushcache'
alias vi='vim'

#Alias a servidores
alias ss-ime='ssh 10.10.32.89 -l portero'
alias ss-ime_extranet='echo "blahu13" ; ssh extranet.ime.com -l exranet'
alias ss-lanoeu='ssh sarps.lanoue.es -l root'

#  ....
# y asi unos cuantos cientos de servidores mas.
# Tambien guardo comandos mas complejos para por ejemplo
# hacer un flush del memcached de frozenlayer o abrir el entorno de desarrollo

# TextMate
alias mater='mate app/ config/ db/ public/ spec/'

# Apps homes
alias market='cd /Users/deadsunrise/Devel/market/Market'
alias fln='cd /Users/deadsunrise/Devel/fln'
alias flnr='source /var/folders/SU/SUdKQzcrE9ynWiP4bz+ZSU+++TI/-Tmp-//E742B37E-1DFA-41C1-B63B-4DFFC367CACE-598-000034009204D547.environment.bash'
alias operadorr='source /var/folders/SU/SUdKQzcrE9ynWiP4bz+ZSU+++TI/-Tmp-//E02DF05A-FBB8-4719-A558-367F5CA70961-598-0000463851E0088E.environment.bash'
alias tpuppet='mate /Users/deadsunrise/Devel/puppet'

# Capistrano
alias capfile='mate ~/Deadsunrise/Configs/Capfile'
alias capi='cap -f ~/Deadsunrise/Configs/Capfile'
alias capi-all='ruby ~/Deadsunrise/Scripts/serial_cap.rb'
if  [[ ! "" == `find ~ -name .captabs\* -ctime +1 -maxdepth 1` ]]; then
 echo "Borrando cache capistrano... "
 rm ~/.captabs*
fi
complete -C ~/Deadsunrise/Configs/cap_complete.rb -o default capi

De esta forma con escribir “ss” y dar al tabulador me sale una lista de todas las maquinas ordenadas por el nombre del cliente y al ejecutar el comando se conecta automáticamente mediante claves privadas o en las que es necesario escribirlas te muestra las claves (o incluso la mete al portapapeles usando el comando pbcopy ).

Si necesito meter una nuevo alias no tengo mas que poner el alias “bbash” en cualquier terminal y se abre el archivo de configuración en textmate, meto la linea nueva y al guárdalo como se sincroniza con dropbox y puedo usar el nuevo alias al instante en cualquiera de los ordenadores. Por regla general si es un servidor al que me he conectado mas de 2 veces lo intento meter en los alias porque es probable que tenga que volver a hacerlo.