Google Tech Talks June 23, 2007 ABSTRACT This talk will discuss some of the scalability challenges that have arisen during YouTube's short but extraordinary history. YouTube has grown incredibly rapidly despite having had only a handful of people responsible for scaling the site. Topics of discussion will include hardware scalability, software scalability, and database scalability. Speaker: Cuong Do Cuong is currently an engineering manager at YouTube/Google. He was part of the engineering team that scaled the YouTube software and hardware infrastructure from its infancy to its current scale. Prior to YouTube/Google, he held various software development and management positions at PayPal and Inktomi.
Según demuestran en la página de la Universidad de Princeton, al apagar el ordenador no se borra inmediatemente el contenido de la memoria RAM dle ordenador, y la persistencia de la información aumenta si los chips de memoria se enfrían.
En el vídeo a continuación se muestra el experimento de recuperar claves de encriptación a partir de la memoria de otro equipo:
Una de las sorpresas que me encontré al visitar el Visvesvarya industrial and Technological Museum en Bangalore, India, en agosto de 2006, fue que lo que menos me interesó fue la exposición itinerante de la fundación Nobelque, desde 2001, y con motivo del centenario de la existencia de la fundación y sus conocidos premios, se anunciaba a bombo y platillo por todas partes. La verdad es que Bangalore me pareció una ciudad mucho menos interesante de lo que había imaginado. Como dicen de ella que es el Sillicon Valley indio, yo me imaginaba más presencia tecnológica en las tiendas y el centro, pero como mi visita fue breve, no di con la zona correcta.
El caso es que uno de los planes más interesantes para una estancia corta parecía ser la visita a este museo y ver la exposición itinerante. El museo en sí es bastante interesante, uno de esos lugares donde puedes participar en los experimentos técnicos que te proponen en lugar de limitarte a leer una sesuda explicación. Pero la sorpresa fue una instalación casi completa de un IBM 1401, el mainframe más emblemático de IBM.
Estas eran las unidades de almacenamiento en cinta, que se usaban no solamente para hacer backups, sino también para procesar ficheros. Montabas el fichero secuencial de entrada en una unidad de cinta, y en otra unidad de cinta montabas una vacía. El programa en COBOL que hacíamos definía las dos cintas con la instrucción "SELECT cinta ASSIGN TO UNIVERVO", iba leyendo secuencialmente de la primera, procesando y haciendo las modificaciones oportunas en el registro leído y escribiendo el resultado en la segunda unidad de cinta. Al final del proceso teníamos la segunda cinta actualizada y se descartaba la primera.
A mi me trae recuerdos de mi infancia tecnológica, ya que cuando yo empecé a estudiar programación en 1978 en el centro de educación de IBM en Madrid, las prácticas de COBOL se hacían en un S/370, que fue el "nieto" de los 1401, y cuando comencé a trabajar como programador en un entorno de mainframes UNIVAC-1100, escribíamos los programas COBOL en hojas de codificación especiales para que las cuatro chicas del departamento de perforación los pasaran a fichas usando la perforadora-verificadora de IBM, justamente éste modelo que estaba en el museo:
Aún recuerdo los sonidos típicos de la sala de máquinas, muy distintos de los zumbidos de los ventiladores que hoy son el único y monótono sonido de los CPD. Para los que no los hayan escuchado, es imprescindible ver este vídeo que muestra un 1401 en pleno funcionamiento en la actualidad y los sonidos de la impresora, las lectoras de fichas, las lectoras de cintas magnéticas y las perforadoras de fichas.
A continuación las fichas ya perforadas se leían en máquinas como la máquina de la derecha en la siguiente foto, una 1402 Card/reader/punch. Se apilaba el montón de fichas, se introducían en la máquina (cabían hasta 1000 fichas de una vez, y las leía en poco más de un minuto. Podemos ver la 1402 junto a la impresora, una 1403 de 1400 líneas por minuto.
El corazón del sistema era el armario donde estaba la CPU y la memoria de ferritas, que incluía el panel de control, lleno de luces, botones y palancas, algo impensable en los ordenadores de hoy día controlados exclusivamente por software.
Visto desde el punto de vista actual ésta máquina no parece muy potente, con sus 4K de memoria, pero la falta de recursos nunca ha sido un límite para la creatividad, lo cual dice mucho de los programadores de esta generación. Al parecer en el año 2000 aún quedaban 1401 aplicaciones ejecutándose en 1401 simuladores de este mainframe.
Tal como comenta la Wikipedia en su artículo sobre el IBM 1401, éste ha sido uno de los productos de más éxito de los que IBM ha fabricado. Muchos paises lo compraron (India, Pakistán, Islandia...) y ha sido el entorno en el que se formó toda una generación de informáticos.
Cuando estuve dando clases de informática en Nepal les enseñé a los chavales de la Gladstone Academy las fotos del 1401, ya que uno como este fue el primer ordenador que se usó en Nepal, en 1971, para hacer el censo de la población.
Es curiosa la página de Johann Johannsson (
http://www.ausersmanual.com
), músico islandés, hijo de un informático con dotes musicales que consiguió producir música con esta máquina, hecho que ha inspirado a su hijo a escribir una obra para instrumentos de cuerda que a mi me parece preciosa, incorporando en ella la música original producida por su padre en el 1401, y la voz de las instrucciones originales de mantenimiento del manual en cinta de audio que venía junto con el mainframe. Resulta interesante oir las instrucciones sobre cómo engrasar la máquina, lo cual no extraña cuando cae en la cuenta de que además de sus 50.000 componentes electrónicos, el sistema tenía 20.000 piezas mecánicas.
Más información sobre el 1401 se puede encontrar en
http://1401.org/
y en sitio sobre el fascinante proyecto del Computer History Museum de mantener en perfecto funcionamiento un IBM 1401. Incluso se pueden visitar estas instalaciones en Mountain View, California
El proyecto mantiene un informe diario de sus actividades que resulta muy curioso de leer para un administrador de sistemas actual, pues muestra lo mucho que ha cambiado este oficio en 40 años.
Además de fotos muy interesantes y una exhaustiva documentación del sistema, en la web ya mencionada del CHM (Computer History Museum) hay un interesante manual (el original escaneado) sobre cómo programar el 1401, titulado IBM Principles of Programming. Impagable.
A los que les interesen más los sistemas posteriores, les puede resultar curiosa este página, que contiene las ilustraciones del libro "Introduction to IBM Data Processing Systems", de 1968, dirigido a los usuarios del sistema 360 de IBM.
Por cierto, que el padre del músico islandes no fue el único en intentar hacer música con el 1401.
Uno de los problemas que podrían suceder por mantener dos (o más) ficheros de resolución de nombres/direcciones para implementar views en DNS como comentamos el otro día es que puede que agregues un nombre a uno de los ficheros (por ejemplo, para resolver la IP pública de ese nombre), y se te olvide introducir ese nombre en la vista para las direcciones privadas.
Para detectar estas diferencias, es decir, nombres que están definido en una de las vistas y no lo están en otra, podemos ejecutar este script, al que pasaremos como parámetros los dos ficheros que queremos comparar.
# diffviews db.dominio.com db.dominio.com.local
El script hace una verificación básica de que se haya pasado dos nombres de ficheros como parámetros y que no sean el mismo y a continuación produce un listado de las diferencias entre ellos o un mensaje que indica que son iguales. Incluso genera un código de salida para poder incluirlo en scripts que tengan que verificar si las zonas son iguales o no.
que lo que hacen es extraer los nombres de cada fichero de zona, ordenarlos alfabéticamente y crear con cada uno de los conjuntos de nombres un fichero temporal. A continuación hacemos un diff de esos dos ficheros temporales y nos dirá qué nombres están en un fichero y faltan en el otro.
Este es el script "diffviews", que hace el trabajo de comparación de dos ficheros de definición de zona DNS:
#/bin/sh
# diffviews (C) 2008 Joaquin Herrero, Creative Codeworks
#
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program. If not, see .
_ZONES_DIRECTORY="/var/named/master/"
echo ""
if [ $# != 2 ]
then
echo "Must specify two zone files to process"
exit 127
fi
if [ ! -f $1 ]
then
echo "Error: $1 not found."
exit 127
fi
if [ ! -f $2 ]
then
echo "Error: $2 not found."
exit 127
fi
if [ $1 == $2 ]
then
echo "Files must exist and have different names"
exit 127
fi
echo "diff between addresses in $1 and $2"
_FILE_1=$_ZONES_DIRECTORY$1
_FILE_2=$_ZONES_DIRECTORY$2
_TEMPFILE1=/tmp/_diffzona_`echo $USER`_`date +%Y%m%d%H%M%S`_$1
_TEMPFILE2=/tmp/_diffzona_`echo $USER`_`date +%Y%m%d%H%M%S`_$2
awk '$3 == "A" {print $1}' $_FILE_1 | sort > $_TEMPFILE1
awk '$3 == "A" {print $1}' $_FILE_2 | sort > $_TEMPFILE2
diff $_DIFF_OPTS $_TEMPFILE1 $_TEMPFILE2
if [ $? == 0 ]
then
echo "No differences were found."
_EXIT_STATUS=0
elif [ $? == 1 ]
then
echo "Differences were found."
_EXIT_STATUS=1
elif [ $? > 1 ]
then
echo "Errors were found."
_EXIT_STATUS=127
fi
rm $_TEMPFILE1 $_TEMPFILE2
exit $_EXIT_STATUS
Para ejecutar "diffviews" para todas las zonas que tengan un view asociado (suponiendo que el view tenga una extensión predeterminada, "local" en este caso) podemos usar este otro script:
#/bin/sh
# checkviews (C) 2008 Joaquin Herrero, Creative Codeworks
#
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program. If not, see .
_ZONES_DIRECTORY="/var/named/master/"
cd $_ZONES_DIRECTORY
for i in *local
do
_FILE_1=$i
_FILE_2=`basename $i .local`
diffviews $_FILE_1 $_FILE_2
done
echo "done."
Este script se puede poner en las tareas diarias de administración del sistema y así cada día, o cada semana, automáticamente se nos enviaría un email con las diferencias entre las vistas de un mismo dominio.
En OpenBSD esto se haría incluyendo la ejecución de este script en /etc/daily o /etc/weekly o /etc/monthly dependiendo de la periodicidad con la que lo queramos ejecutar.
Cualquiera que tenga una red de servidores con direcionamiento privado (RFC 1918), a los que se tenga también acceso desde internet se enfrenta con un dilema a la hora de definir los servidores de nombres (DNS). ¿Un servidor DNS en la DMZ para resolver los nombres a direcciones públicas y un servidor DNS en la red privada para resolver los nombres a direcciones privadas? Esto es una posibilidad (de hecho, la que más se utiliza) pero plantea el problema de administrar lo que conceptualmente es un único servicio en dos máquinas distintas.
A mi me gusta más la solución de usar un único servidor DNS en la red interna, accesible desde internet, y que resuelva de forma distinta los nombres que le sean consultados en función de si el que pide el servicio está en Internet o en la red interna: si el que consulta el DNS está en Internet se le da una dirección pública, si el que pide está en la red interna se le da la dirección interna del servidor.
Así, si hago un ping a mi dominio desde la red interna obtengo esto:
$ ping creativecodeworks.com
PING creativecodeworks.com (192.168.0.90): 56 data bytes
64 bytes from 192.168.0.90: icmp_seq=0 ttl=255 time=0.567 ms
64 bytes from 192.168.0.90: icmp_seq=1 ttl=255 time=0.445 ms
--- creativecodeworks.com ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 0.445/0.506/0.567/0.061 ms
Y si hago el mismo ping desde una máquina en Internet el resultado sería:
$ ping creativecodeworks.com
PING creativecodeworks.com (80.37.203.191): 56 data bytes
64 bytes from 80.37.203.191: icmp_seq=0 ttl=250 time=34.417 ms
64 bytes from 80.37.203.191: icmp_seq=1 ttl=250 time=32.818 ms
--- creativecodeworks.com ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 32.818/33.617/34.417/0.820 ms
¿Cómo se consigue hacer esto usando un único servidor DNS? Mediante el uso de views en la configuración del DNS. Vamos a ver ejemplos de cómo configurar views en DNS usando BIND versión 9.3.1.
Fichero named.conf
En el fichero named.conf, que en mi OpenBSD está en /var/named/etc/named.conf) hay que definir dos cosas:
1.- Qué direcciones son locales (las demás serán usuarios de Internet). Esto lo definiremos en una ACL (Access Control List).
2.- Qué ficheros de configuración de dominios se aplican a las direcciones locales y cuáles a las direcciones de Internet.
El truco está en que tendremos DOS ficheros de configuración por cada dominio, uno para la red interna y otro para internet, y el DNS usará uno u otro en función de la ACL que se le aplique al que consulta en función de su dirección IP.
Vamos a editar (como root o usando el comando sudo) el fichero named.conf y creamos una ACL para definir las direcciones internas:
Con esta definición, cualquier máquina que consulte este DNS y cuya dirección IP comience por 192.168 o por 10.10.0 (observese la diferente máscara de subred) será catalogada como interna y consultará el fichero de configuración del dominio para la red interna, que contiene solo IPs privadas. El resto de máquinas que consulten este DNS y que no tengan estas direcciones IP serán consideradas máquinas de Internet y se les darán los datos del fichwero de configuración del dominio para internet.
Ficheros de configuración del dominio
Vamos a crear los DOS ficheros que necesitamos para cada dominio, uno para la red interna y otro para las direcciones públicas. El dominio que vamos a definir es "creativecodeworks.com" y los ficheros que crearemos son:
db.creativecodeworks.com para ser consultado desde internet
db.creativecodeworks.com.local para ser consultado desde la red interna
En mi sistema estos ficheros están en /var/named/master, ya que este servidor es el servidor maestro para este dominio.
El contenido de los dos ficheros será:
$ cd /var/named/master
$ cat db.creativecodeworks.com
$ORIGIN creativecodeworks.com.
$TTL 6h
@ IN SOA ns0.creativecodeworks.com. boss.creativecodeworks.com. (
2008020500 ; serial
3h ; refresh after 3 hours
1h ; retry after 1 hour
1w ; expire after 1 week
1h ) ; negative caching TTL of 1 hour
NS ns0.creativecodeworks.com.
NS ns0.xname.org.
MX 10 smtp.creativecodeworks.com.
creativecodeworks.com. IN A 80.37.203.191
www IN A 80.37.203.191
smtp IN A 80.37.203.191
ns0 IN A 80.37.203.191
$ cd /var/named/master
$ cat db.creativecodeworks.com.local
$ORIGIN creativecodeworks.com.
$TTL 6h
@ IN SOA ns0.creativecodeworks.com. boss.creativecodeworks.com. (
2008020500 ; serial
3h ; refresh after 3 hours
1h ; retry after 1 hour
1w ; expire after 1 week
1h ) ; negative caching TTL of 1 hour
NS ns0.creativecodeworks.com.
NS ns0.xname.org.
MX 10 smtp.creativecodeworks.com.
creativecodeworks.com. IN A 192.168.0.90
www IN A 192.168.0.90
smtp IN A 192.168.0.90
ns0 IN A 192.168.0.90
Como puede verse, ambos ficheros son exactamente iguales con la excepcción de la dirección IP asociada a cada nombre, que en un caso es pública y en el otro es privada.
Creación del "view"
Ahora lo que nos falta es la forma de "asociar" cada uno de los dos ficheros de configuración a la ACL que le corresponda. Hemos creado solo una ACL, que define las direcciones privadas, y se sobreentiende que todas las IPs que no figuren en una ACL explícitamente corresponden a una ACL implícita, llamada "any". Osea, que, en principio, todas las direcciones IP pertenecen a la ACL implícita "any", y lo que hacemos definiendo ACL explícitas es "sacar" de "any" a ese grupo de direcciones.
Vamos a crear dos vistas, o "views", una para los clientes asociados a la ACL que hemos llamado "interna", y a esa vista la llamaremos "interna" en un alarde de originalidad, y vamos a crear una segunda vista, que llamaremos "internet" y a la que asociaremos la ACL implícita "any":
// ------------------------------------------------------------------------
// Vista para la red interna
// ------------------------------------------------------------------------
view "interna" {
match-clients { "interna"; };
recursion yes;
zone "." {
type hint;
file "standard/root.hint";
};
zone "localhost" {
type master;
file "standard/localhost";
allow-transfer { localhost; };
};
zone "127.in-addr.arpa" {
type master;
file "standard/loopback";
allow-transfer { localhost; };
};
zone "10.in-addr.arpa" {
type master;
file "standard/db.10";
allow-transfer { localhost; };
};
zone "creativecodeworks.com" {
type master;
file "master/db.creativecodeworks.com.local";
};
}
La instrucción match-clients define la ACL que corresponde a esta vista. Aquí asociamos a esta vista la ACL "interna".
Dentro de la zona hemos metido el fichero de configuración "db.creativecodeworks.com.local" para resolver los nombres del dominio "creativecodeworks.com", y además he metido los ficheros de configuración inversa que me permiten resolver los nombres cuando le pregunte al servidor por una dirección.
El parámetro recursion puede activarse, o no, en función de lo que necesitemos. Si está activado, nuestro servidor DNS podrá resolver cualquier nombre del mundo mundial, pues escalará la pregunta a los servidores DNS globales; y si ponemos recursion no solamente resolverá los nombres de los dominios que tenga definido este servidor, en este caso solamente creativecodeworks.com.
Yo he puesto para la vista interna recursion yes, lo que me permite definir en mis máquinas internas a este servidor como DNS para los PC's clientes, y usando ese servidor DNS poder consultar cualquier dirección de internet.
El otro "view", el que define qué hacer si nos consultan desde internet es:
// ------------------------------------------------------------------------
// Vista para Internet
// ------------------------------------------------------------------------
view "internet" {
match-clients { any; };
recursion no;
zone "." {
type hint;
file "standard/root.hint";
};
zone "creativecodeworks.com" {
type master;
file "master/db.creativecodeworks.com";
allow-transfer { 195.234.42.0/24; 193.218.105.144/28; 87.98.164.164; };
};
}
Observe que aquí he quitado la posibilidad de hacer búsquedas recursivas, esto significa que no quiero que usen desde internet este servidor como servidor DNS para máquinas. Solo se consultará este servidor cuando el sistema DNS global necesite resolver direcciones de los dominios que yo alojo en mis máquinas.
Activar las nuevas configuraciones
Una vez definido todo lo anterior, recargamos tanto la configuración del servicio DNS como la configuración de los dominios:
rndc reconfig hace efectivos los cambios en el fichero de configuración del servicio DNS (named.conf)
rndc reload carga de nuevo las definiciones de los dominios (ficheros en /var/named/master definidos en named.conf)
Podemos comprobar si ha habido algun error consultando el fichero de log /var/log/messages.
En este post quiero documentar la infraestructura de mi red que da servicio a Internet.
Los equipos son:
- Servidor soekris 4801 CPU Geode 266 MHz, 256Mb RAM, con sistema operativo OpenBSD, haciendo funciones de firewall, punto de acceso WiFi, servidor DNS interno y externo, servidor Web, servidor de base de datos MySQL. Este blog está alojado en esta máquina.
- Router Comtrend con ADSL2 de 10Mbps
- Teléfono Nokia 9210 Communicator con software newTelnet9200 de emulación de terminal y cable serie, conectado al puerto de consola del servidor Soekris.
El dmesg del servidor de la DMZ es este:
OpenBSD 3.8 (GENERIC) #138: Sat Sep 10 15:41:37 MDT 2005
deraadt@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Geode(TM) Integrated Processor by National Semi ("Geode by NSC" 586-class) 267 MHz
cpu0: FPU,TSC,MSR,CX8,CMOV,MMX
cpu0: TSC disabled
real mem = 268017664 (261736K)
avail mem = 237674496 (232104K)
using 3297 buffers containing 13504512 bytes (13188K) of memory
mainbus0 (root)
bios0 at mainbus0: AT/286+(00) BIOS, date 20/50/29, BIOS32 rev. 0 @ 0xf7840
pcibios0 at bios0: rev 2.0 @ 0xf0000/0x10000
pcibios0: pcibios_get_intr_routing - function not supported
pcibios0: PCI IRQ Routing information unavailable.
pcibios0: PCI bus #0 is the last bus
bios0: ROM list: 0xc8000/0x9000
cpu0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Cyrix GXm PCI" rev 0x00
sis0 at pci0 dev 6 function 0 "NS DP83815 10/100" rev 0x00: DP83816A, irq 10, ad dress 00:00:24:c7:a5:b8
nsphyter0 at sis0 phy 0: DP83815 10/100 PHY, rev. 1
sis1 at pci0 dev 7 function 0 "NS DP83815 10/100" rev 0x00: DP83816A, irq 10, ad dress 00:00:24:c7:a5:b9
nsphyter1 at sis1 phy 0: DP83815 10/100 PHY, rev. 1
sis2 at pci0 dev 8 function 0 "NS DP83815 10/100" rev 0x00: DP83816A, irq 10, ad dress 00:00:24:c7:a5:ba
nsphyter2 at sis2 phy 0: DP83815 10/100 PHY, rev. 1
ath0 at pci0 dev 14 function 0 "Atheros AR5212" rev 0x01: irq 11
ath0: AR5212 5.9 phy 4.3 rf2112 4.6, FCC1A, address 00:02:6f:39:cb:a6
gscpcib0 at pci0 dev 18 function 0 "NS SC1100 ISA" rev 0x00
gpio0 at gscpcib0: 64 pins
"NS SC1100 SMI/ACPI" rev 0x00 at pci0 dev 18 function 1 not configured
pciide0 at pci0 dev 18 function 2 "NS SCx200 IDE" rev 0x01: DMA, channel 0 wired to compatibility, channel 1 wired to compatibility
wd0 at pciide0 channel 0 drive 0:
wd0: 16-sector PIO, LBA, 57231MB, 117210240 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
geodesc0 at pci0 dev 18 function 5 "NS SC1100 X-Bus" rev 0x00: iid 6 revision 3 wdstatus 0
ohci0 at pci0 dev 19 function 0 "Compaq USB OpenHost" rev 0x08: irq 5, version 1 .0, legacy support
usb0 at ohci0: USB revision 1.0
uhub0 at usb0
uhub0: Compaq OHCI root hub, rev 1.00/1.00, addr 1
uhub0: 3 ports with 3 removable, self powered
isa0 at gscpcib0
isadma0 at isa0
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard
pcppi0 at isa0 port 0x61
midi0 at pcppi0:
spkr0 at pcppi0
sysbeep0 at pcppi0
nsclpcsio0 at isa0 port 0x2e/2: NSC PC87366 rev 9: GPIO VLM TMS
gpio1 at nsclpcsio0: 29 pins
gscsio0 at isa0 port 0x15c/2: SC1100 SIO rev 1:
npx0 at isa0 port 0xf0/16: using exception 16
pccom0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
pccom0: console
pccom1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
biomask f3e5 netmask ffe5 ttymask ffe7
pctr: no performance counters in CPU
dkcsum: wd0 matches BIOS drive 0x80
root on wd0a
rootdev=0x0 rrootdev=0x300 rawdev=0x302
En otra parte de la casa, conectada via WiFi con la DMZ, hay este otro grupo de máquinas:
- Servidor soekris 4801 CPU Geode 266 MHz, 128Mb RAM, con sistema operativo OpenBSD, que hace de respaldo de su gemelo de la DMZ
- Wireless G Ethernet Adapter de Belkin
- Hub 3Com OfficeConnect
- Servidor Sun Ultra 10 Elite3D con OpenBSD, funciones de desktop
- Unidad de cinta DAT40 HP SureStore SCSI
El servidor Ultra 10 tiene dos teclas curiosas, la de puesta en marcha (adoro usar hardware de Sun, con la consola por puerto serie y el botón de encendido en el teclado), y la tecla "any" por si me sale alguna vez el famoso mensaje "press any key to continue" ;).
El dmesg del servidor Sun Ultra 10 es este:
console is keyboard/display
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
Copyright (c) 1995-2007 OpenBSD. All rights reserved. http://www.OpenBSD.org
OpenBSD 4.2 (GENERIC) #1427: Tue Aug 28 10:46:40 MDT 2007
deraadt@sparc64.openbsd.org:/usr/src/sys/arch/sparc64/compile/GENERIC
real mem = 1073741824 (1024MB)
avail mem = 1028055040 (980MB)
mainbus0 at root: Sun Ultra 5/10 UPA/PCI (UltraSPARC-IIi 440MHz)
cpu0 at mainbus0: SUNW,UltraSPARC-IIi (rev 9.1) @ 440 MHz, version 0 FPU
cpu0: physical 16K instruction (32 b/l), 16K data (32 b/l), 2048K external (64 b /l)
psycho0 at mainbus0 addr 0xfffc4000: SUNW,sabre, impl 0, version 0, ign 7c0
psycho0: bus range 0-3, PCI bus 0
psycho0: dvma map c0000000-dfffffff, iotdb 1bbe000-1c3e000
pci0 at psycho0
ppb0 at pci0 dev 1 function 1 "Sun Simba PCI-PCI" rev 0x13
pci1 at ppb0 bus 1
ebus0 at pci1 dev 1 function 0 "Sun PCIO EBus2" rev 0x01
auxio0 at ebus0 addr 726000-726003, 728000-728003, 72a000-72a003, 72c000-72c003, 72f000-72f003
power0 at ebus0 addr 724000-724003 ipl 37
"SUNW,pll" at ebus0 addr 504000-504002 not configured
sab0 at ebus0 addr 400000-40007f ipl 43: rev 3.2
sabtty0 at sab0 port 0
sabtty1 at sab0 port 1
comkbd0 at ebus0 addr 3083f8-3083ff ipl 41: layout 42
wskbd0 at comkbd0: console keyboard
com0 at ebus0 addr 3062f8-3062ff ipl 42: mouse: ns16550a, 16 byte fifo
lpt0 at ebus0 addr 3043bc-3043cb, 30015c-30015d, 700000-70000f ipl 34: polled
"fdthree" at ebus0 addr 3023f0-3023f7, 706000-70600f, 720000-720003 ipl 39 not c onfigured
clock1 at ebus0 addr 0-1fff: mk48t59
"flashprom" at ebus0 addr 0-fffff not configured
audioce0 at ebus0 addr 200000-2000ff, 702000-70200f, 704000-70400f, 722000-72200 3 ipl 35 ipl 36: nvaddrs 0
audio0 at audioce0
hme0 at pci1 dev 1 function 1 "Sun HME" rev 0x01: ivec 0x7e1, address 08:00:20:f e:3f:6c
nsphy0 at hme0 phy 1: DP83840 10/100 PHY, rev. 1
vgafb0 at pci1 dev 2 function 0 "ATI Mach64 GP" rev 0x5c
wsdisplay0 at vgafb0
wsdisplay0: screen 0 added (std, sun emulation)
pciide0 at pci1 dev 3 function 0 "CMD Technology PCI0646" rev 0x03: DMA, channel 0 configured to native-PCI, channel 1 configured to native-PCI
pciide0: using ivec 0x7e0 for native-PCI interrupt
wd0 at pciide0 channel 0 drive 0:
wd0: 16-sector PIO, LBA, 19458MB, 39851760 sectors
wd0(pciide0:0:0): using PIO mode 4, DMA mode 2
atapiscsi0 at pciide0 channel 1 drive 0
scsibus0 at atapiscsi0: 2 targets
cd0 at scsibus0 targ 0 lun 0: SCSI0 5/cdrom r emovable
cd0(pciide0:1:0): using PIO mode 4, DMA mode 2
ppb1 at pci0 dev 1 function 0 "Sun Simba PCI-PCI" rev 0x13
pci2 at ppb1 bus 2
ppb2 at pci2 dev 1 function 0 "DEC 21153 PCI-PCI" rev 0x04
pci3 at ppb2 bus 3
"Sun PCIO EBus2" rev 0x01 at pci3 dev 0 function 0 not configured
hme1 at pci3 dev 0 function 1 "Sun HME" rev 0x01: ivec 0x7d1, address 08:00:20:f 6:85:94
luphy0 at hme1 phy 1: LU6612 10/100 PHY, rev. 1
"Sun PCIO EBus2" rev 0x01 at pci3 dev 1 function 0 not configured
hme2 at pci3 dev 1 function 1 "Sun HME" rev 0x01: ivec 0x7d2, address 08:00:20:f 6:85:95
luphy1 at hme2 phy 1: LU6612 10/100 PHY, rev. 1
"Sun PCIO EBus2" rev 0x01 at pci3 dev 2 function 0 not configured
hme3 at pci3 dev 2 function 1 "Sun HME" rev 0x01: ivec 0x7d3, address 08:00:20:f 6:85:96
luphy2 at hme3 phy 1: LU6612 10/100 PHY, rev. 1
"Sun PCIO EBus2" rev 0x01 at pci3 dev 3 function 0 not configured
hme4 at pci3 dev 3 function 1 "Sun HME" rev 0x01: ivec 0x7d0, address 08:00:20:f 6:85:97
luphy3 at hme4 phy 1: LU6612 10/100 PHY, rev. 1
siop0 at pci2 dev 2 function 0 "Symbios Logic 53c875" rev 0x14: ivec 0x7d4, usin g 4K of on-board RAM
scsibus1 at siop0: 16 targets
siop1 at pci2 dev 2 function 1 "Symbios Logic 53c875" rev 0x14: ivec 0x7d5, usin g 4K of on-board RAM
scsibus2 at siop1: 16 targets
ohci0 at pci2 dev 3 function 0 "NEC USB" rev 0x43: ivec 0x7d8, version 1.0
ohci1 at pci2 dev 3 function 1 "NEC USB" rev 0x43: ivec 0x7d9, version 1.0
ehci0 at pci2 dev 3 function 2 "NEC USB" rev 0x04: ivec 0x7da
usb0 at ehci0: USB revision 2.0
uhub0 at usb0: NEC EHCI root hub, rev 2.00/1.00, addr 1
usb1 at ohci0: USB revision 1.0
uhub1 at usb1: NEC OHCI root hub, rev 1.00/1.00, addr 1
usb2 at ohci1: USB revision 1.0
uhub2 at usb2: NEC OHCI root hub, rev 1.00/1.00, addr 1
creator0 at mainbus0 addr 0xfebc0000: Elite3D, model SUNW,XXX-XXXX, dac 0
wsdisplay1 at creator0: console (std, sun emulation), using wskbd0
"pcons" at mainbus0 not configured
bootpath: /pci@1f,0/pci@1,1/ide@3,0/disk@0,0
root on wd0a swap on wd0b dump on wd0b
El xorg.conf de esta máquina, preparado para conectar doble monitor, es el siguiente:
Las herramientas que tenemos desde línea de comandos para procesar fotografías son muy potentes, y permiten hacer modificaciones en un grupo de fotografías de forma automatizada.
Algunas de estas herramientas son:
convert: transforma una fotografía (resize, blur, crop, despeckle, dither, draw on, flio, join, re-sample, etc) creando una nueva imagen que será el resultado de la transformación
mogrify: igual que convert pero la imagen original es sobrescrita con los cambios
jhead: proceso de los datos EXIF que contiene la fotografía
Tanto "convert" como "mogrify" son parte del conjunto de utilidades denominadas ImageMagick, "jpegtran" es parte de las utilidades para procesar JPEG's que en algunos sistemas se instala en la instalación básica (en Ubuntu no), y "jhead" es una utilidad que se puede instalar independientemente.
El uso más básico de jhead para visualizar los datos exit de la foto es muy simple: simplemente le pasamos como parámetro el fichero de la imagen.
$ jhead test.jpg
File name : test.jpg
File size : 106697 bytes
File date : 2008:02:08 12:31:21
Camera make : OLYMPUS OPTICAL CO.,LTD
Camera model : C5050Z
Date/Time : 2006:09:03 18:38:42
Resolution : 800 x 571
Flash used : No
Focal length : 7.1mm
Exposure time: 1.300 s
Aperture : f/1.8
ISO equiv. : 400
Metering Mode: matrix
Exposure prog: shutter priority (semi-auto)
Jpeg process : Baseline
Y esta es la salida del mismo comando cuando la imagen no contiene datos EXIF:
$ jhead test.jpg
File name : test.jpg
File size : 9155 bytes
File date : 2008:02:08 12:44:31
Resolution : 172 x 162
Algunas utilidades para transformar imágenes no respetan la cabecera EXIF, por lo que es una buena costumbre salvar la cabecera EXIF de la foto que vamos a procesar, hacer las transformaciones que queramos, y finalmente reinsertar la cabecera EXIF en la foto final.
Por ejemplo, si quisieramos usar mogrify para escalar nuestra imagen a 320x240 para usarla en una página web, o para subirla a Flickr, sin perder los datos EXIF, necesitaríamos usar este comando:
$ mogrify -resize 320 test.jpg
Nota que con especificar la anchura deseada (320), el comando calcula la altura que le corresponde sin deformar la foto.
Pero, ¿qué ocurre si nuestro mogrify (u otra utilidad) no conserva los datos EXIF? En este caso podemos usar este comando:
$ jhead -cmd "mogrify -resize 320 &i" *.jpg
que ordena a jhead sacar la cabecera EXIF de la fotografía, procesarla mediante el comando que aparezca en el parámetro "-cmd" (&i es el nombre de la foto), y finalmente reinsertar la cabecera EXIF antes de terminar.
Si en lugar de poner un comando en el parámetro "-cmd" usamos ahí un script que llame a mogrify y a jpegtran, podremos hacer todas las modificaciones que queramos manteniendo la cabecera EXIF de las fotos.
Con estos ingredientes se pueden hacer scripts que automaticen el reescalado de fotos, la inserción de comentarios, o cualquier otra transformación que deseemos.
Gustavo hoy ha recibido su Mac mini y lo hemos instalado en un periquete. Tanto el teclado como el ratón son inhalámbricos y hay que ponerles la pila correspondiente. El sistema operativo Leopard viene preinstalado y tras unas pocas preguntas al iniciar el sistema por primera vez, detecta las redes de cable o wifi y aparece un precioso escritorio, con lo que el sistema queda listo para trabajar.
