Vicente Hernández

BEACH HOUSE – Walk In The Park

THE BLACK KEYS – Little Black Submarines

MASTERS IN FRANCE – Playin With My Friends

GRIMES – Oblivion

DIE ANTWOORD – Baby’s On Fire

WOODKID – Run Boy Run

THE SHOES – Time To Dance

CITIZENS! – True Romance

LOGO – Fabrice

THE NEIGHBOURHOOD – Sweater Weather

iamamiwhoami – in due order

COMPUTER MAGIC – The End Of Time

ALT-J – Tessellate

SNAKADAKTAL – Dance Bear

THE NAKED AND FAMOUS – The Sun

http://www.youtube.com/watch?v=TjpKGcnEa80

No me sorprende que ‘Hosting’ tenga un coste actual de 31$, en 2007 ya pagábamos entre 5-10€ por palabras relacionadas, como ‘servidores dedicados’

Me recomendaron este documental que explica qué es el dinero actualmente y cómo es creado.

Interesante documental que explica de forma asequible qué es Linux, GNU y qué representa para la industria informática. Personalmente tengo mucho que agradecer a Linux, sin este sistema operativo no habría podido existir un proyecto como Veloxia. Hoy en día Linux está presente de forma indirecta en muchísimos elementos de nuestra vida, además de ser un elemento esencial en Internet, lo tenemos en multitud de aparatos domésticos, en teléfonos móviles y cada vez se le dan más usos.

Normalmente la escalabilidad es un aspecto que no se suele valorar hasta el momento en el que uno se arrepiente de no haberlo hecho, usualmente hasta que el proyecto tiene éxito (no tiene por que ser económico) y muchos usuarios hacen uso del mismo, esto es algo que he podido observar tanto en proyectos propios como de clientes. Es algo usual que durante la fase de desarrollo del proyecto tengamos prisa y dediquemos poco esfuerzo a hacer escalable la web, no consideramos que sea un aspecto importante. Es un gran error, aunque no hay que obsesionarse tampoco con el tema y alargando el tiempo de desarrollo, en esta fase inicial nos cuesta muy poco tener en cuenta cómo puede crecer el sistema y definir la estructura del mismo para que este crecimiento no sea doloroso.

Tener en cuenta estos pequeños detalles nos puede facilitar muchísimo trabajo futuro.

¿Cómo podemos preparar nuestro proyecto para que sea escalable en esta primera fase? Tenemos que tratar de identificar los posibles cuellos de botella que tendrá nuestra aplicación. En una típica aplicación web seguramente el cuello de botella vendrá en DB y con optimizar nuestras queries seguramente estaremos dando un gran paso.  Es importante optimizar la estructura de la base de datos, así como los índices de las tablas para optimizar el acceso a las mismas y no generar consultas que hagan uso de columnas o conjunto de columnas no indexadas.

Un buen libro para documentarse sobre cómo mejorar y optimizar el rendimiento en consultas SQL y la estructura de bases de datos para este SGBD es High Performance MySQL de O’reilly. Además también trata temas como la replicación y escalabilidad horizontal vía sharding. Es muy importante optimizar en la medida de lo posible las consultas a la DB porque un escalado horizontal resulta bastante complejo, más allá de la simple replicación de nodos.

Una vez el proyecto arranca es importante medir el crecimiento en consumo de recursos para tratar de planificar el crecimiento  correctamente. Cuantos más parámetros usemos mejor y más no podremos anticipar a situaciones problemáticas. No basta con monitorizar el consumo de CPU de los servidores, si nuestra aplicación puede tener un cuello de botella en acceso a disco deberemos monitorizar el acceso a los discos, si procesamos imágenes debemos medir el tiempo que dedica un servidor por imágen, por ejemplo. Si medimos además datos relativos a negocio, como número de usuarios nuevos al día, nuevos servicios creados por los usuarios, tiempo medio de uso de la aplicación del usuario, etc podemos cruzar datos y tratar de definir un plan que nos ayude a dimensionar recursos necesarios de una forma bastante realista en base a datos de negocio. Si sabemos que el consumo medio de espacio en disco por usuario es de 36MB/mes podemos planificar que probablemente necesitaremos al menos 432GB para almacenar los datos que generen 1000 usuarios durante un año (36MBx12x1000).

Actualmente gracias a servicios cloud como AWS resulta relativamente sencillo escalar el hardware y el almacenamiento, pero no por ello deja de costar dinero, así que cualquier optimización que hagamos redundará en nuestro bolsillo.

Por defecto Symfony no permite que las URL de acceso terminen en barra (/). Para hacer que sean accesibles todas las URL de forma indistinta con y sin barra cambiamos la clase request:

En el archivo /apps/frontend/config/factories.yml:

all:
  routing:
    class: sfPatternRouting

  request:
    class: myWebRequest

y en el archivo apps/frontend/lib/myWebRequest.class.php:

<?php
class myWebRequest extends sfWebRequest
{
  public function getPathInfo()
  {
    $pathInfo = parent::getPathInfo();

    // cut off trailing slash
    $pathInfo = preg_replace('/\/$/', '', $pathInfo);

    return $pathInfo;
  }
}

vía Vacskamati’s daily code snippet

Pensaba que el sistema gestionaba de forma automática el spindown de discos pero he podido comprobar que no es así, y en el servidor de casa por durabilidad de los discos quiero que los dedicados a almacenar pelis y música sólo se activen cuando son usados. He localizado este sencillo script que monitoriza /proc/diskstats para el disco que indiques y si en el intervalo que deseas no ha sido usado lo desactiva mediante sdparm. La forma de lanzar el script sería autospindown.pl /dev/sdb1 300 (el segundo parámetro es el intervalo en segundos). Así de sencillo.

#!/usr/bin/perl -w

$statfile = "/proc/diskstats";
die "$0: Cannot read $statfile\n" unless -r $statfile;

$| = 1;
($disk, $interval) = (@ARGV);
$disk =~ s,/dev/,,;
print "$0: disk: $disk, interval: $interval\n";

$halted_data = $last_seen = '';
while (1) {
open(STATUS, $statfile);
($_) = grep(/^\s+\d+\s+\d+\s+$disk\s/o, );
close STATUS;

if ($last_seen eq $_ && $halted_data ne $_) {
print "Spinning down: $disk\n";
system "sdparm", "--command=stop", "/dev/$disk";
$halted_data = $_;
}
$last_seen = $_;
sleep $interval;
}

Es muy común utilizar ntpdate en cron para mantener sincronizado un servidor linux, lo cual es un error. Es mejor utilizar ntpd, que de forma aleatoria conecta a distintos ntpd remotos y calcula márgenes de error de forma más optimizada que ntpdate.

Del man de ntpdate(8):

ntpdate can be run manually as necessary to set the host clock, or it can be run from the host startup script to set  the  clock  at  boot  time. This  is  useful  in  some  cases  to set the clock initially before starting the NTP daemon ntpd. It is also possible to run ntpdate from a cron script. However, it is important to note that ntpdate with contrived cron scripts is no substitute for the NTP daemon, which  uses  sophisticated algorithms  to  maximize  accuracy  and reliability while minimizing resource use. Finally, since ntpdate does not discipline the host clock frequency as does ntpd, the accuracy using ntpdate is limited.

Al migrar a macOS no he podido encontrar una herramienta como SecureCRT para Windows (sí, hay una versión para macOS pero no es compatible con Cinch) y finalmente me he decantado por montar scripts con expect para automatizar el acceso a los distintos servidores que administro.

expect es una herramienta que permite automatizar procesos que usualmente requieren interacción con usuario. En este caso se trata simplemente de automatizar la instroducción del password, pero podríamos ampliar el script y ejecutar una serie de comandos tras el acceso, o automatizar el acceso a X servidores y ejecutar una serie de comandos.

el script sería este:

#!/usr/bin/expect -f
# Expect script to supply root/admin password for remote ssh server

# set Variables
set password “contraseña”
set ipaddr “213.149.224.2″
set port 22

set timeout -1
# now connect to remote UNIX box (ipaddr)
spawn ssh $ipaddr -l root -p 22
match_max 100000
# Look for passwod prompt
expect “*?assword:*”
# Send password aka $password
send — “$password\r”
# send blank line (\r) to make sure we get back to gui
send — “\r”
interact

Este script es una pequeña modificación, aquí puedes encontrar el original, que pasa la IP, passwd y un comando a ejecutar como parámetro, pero que no permite la interacción posterior del usuario.

Puesto que guardamos la contraseña de acceso en texto plano, no es mala idea utilizar una herramienta como Truecrypt para encriptar el directorio, o montar un disco encriptado donde almacenemos los scripts expect.

En la web de DELL resulta muy sencillo actualizar la BIOS de tu ordenador, siempre y cuando tengas un Windows. Si tienes Ubuntu, centOS, Redhat ó SLES resulta también relativamente sencillo, simplemente ejecutando los siguientes comandos:

wget -q -O - http://linux.dell.com/repo/firmware/bootstrap.cgi | bash
aptitude install firmware-addon-dell
aptitude install $(bootstrap_firmware -a)
update_firmware

En cambio debian no está soportado por DELL de forma oficial y lo podemos hacer a mano como detallo a continuación.

Instalamos el paquete libsmbios-bin.

apt-get install libsmbios-bin

Obtenemos la información del modelo mediante getSystemId. La ejecución de este comando debe darnos una salida similar a esta:

root@sulaco:~# getSystemId
Libsmbios: 2.0.3
System ID: 0x0220
Service Tag: 123453J
Express Service Code: 12345123456
Product Name: OptiPlex 330
BIOS Version: A00
Vendor: Dell Inc.
Is Dell: 1

Index of -repo-firmware-bios-hdrs

Anotamos el System ID (en este caso 0×0220 y nos vamos a esta web de DELL y buscamos la última versión para nuestro System ID. En mi caso la última es la A07. Descargamos el archivo .HDR y lo guardamos en nuestro equipo. Para comprobar que vamos a poder actualizar debemos ejecutar el comando modprobe dell_rbu y no debería dar ningún error, en tal caso ejecutamos dellBiosUpdate -u -f bios.hdr

y reiniciamos la máquina ejecutando reboot. Deberíamos ver ya en el arraque la nueva versión, o comprobarla ya en el sistema mediante getSystemId.