Roger Jordan Blog

Apenas queda una semana para que se celebre el OpenSolaris Day en la Universidad Complutense de Madrid. Un evento grande para la toda la comunidad OpenSource.

Podéis consultar aquí la agenda del evento.

Diagnosticar un problema de io siempre ha sido una tarea compleja. Las herramientas que disponen los distintos unix proporcionan datos a nivel de dispositivo o filesystem. Usando Solaris teníamos alguna ayuda extra usando truss, mdb, scat, ... sin embargo ninguna de ellas proporciona una respuesta rápida y sencilla a las preguntas que tiene un administrador de sistemas cuando se enfrenta a un problema de io

Que proceso es el que está generando el problema ?

Sobre que archivo esta escribiendo ?

Por fortuna OpenSolaris dispone de dtrace que puede proporcionarnos de forma sencilla las respuestas. Vamos a ver algunos ejemplos sencillos para diagnosticar la causa de un throughput alto de escritura.

Este comando nos lista la cantidad de bites escritos a disco por cada pid:

dtrace -n 'sysinfo:::writech { @dist[pid] = sum(arg0); }'

( Una vez identificado el pid origen del problema, el comando pfiles nos ayudará a identificar los ficheros a los que accede )

Sin embargo la carga de io puede ser debida a distintos procesos, así que quizás nos interese ver que archivos concentran el mayor número de accesos:

dtrace -n 'syscall::write:entry { @dist[fds[arg0].fi_pathname] = count(); }'

También nos puede interesar enfocar el diagnóstico de forma contraria, es decir, ver quien está accediendo a un fichero en concreto:

dtrace -q -n 'syscall::write:entry / fds[arg0].fi_pathname == "path_fichero" / { printf("Proceso %d \n", pid );}'

Como veis las posibilidades son casi infinitas, dtrace nos permite enfocar el diagnóstico desde la perspectiva que más nos interesa. Como última nota, tened en cuenta que los comandos anteriores pueden generar salidas bastante grandes en sistemas con bastante carga, así que sería aconsejable redirigirlas a un fichero y luego manipular los datos con nuestra herramienta favorita.

Seguimos con la tercera entrega del quiz de OpenSolaris a pesar de la baja participación de la semana pasada. Espero que la gente no pensara que las preguntas eran en exceso difíciles, ya que las de esta solo son aptas para un administrador Senior, lo eres tu ? ;)

Las preguntas de la semana anterior y sus respuestas correctas eran:

Como pasarías el sistema desde multiusuario a single user ?

c) ejecutar "#svcadm milestone single-user".

Como deshabilitarías el rutado de paquetes ipv6 en opensolaris ?

c) ejecutar "#svcadm disable ipv6-forwarding".

Que comando usarías para ver el número de paquetes erróneos en una interfaz de red en el último minuto ?

netstat -i -I interfaz 60

Con este comando netstat nos ira mostrando cada 60 segundos las estadísticas de la interfaz, incluido los paquetes erróneos (entrantes y salientes).

Ramses a bordado su respuesta y con un poco de mágia de shell y awk, nos da la suma ya hecha del último minuto, felicidades !! :)

netstat -i -I NOMBRE_INTERFAZ 60 2 |awk 'NR==4{print $2+$4}'

Su sugerencia para hacer lo mismo con dtrace la apuntamos para la 4 ronda del quiz.

Las preguntas para esta semana son:

Como impedirías que desde una zona no global alguien llene /tmp ?

a) configuraría el parámetro capped-memory [swap] a n Mb en la zona.
b) no se puede, /tmp tiene permisos 777 para todos los usuarios, cualquiera puede copiar lo que quiera.
c) habilitaría las quotas para /tmp.
d) crearía un tmp distinto para cada zona.

Como limitarías a un máximo de 512m el uso de shared memory por parte de cualquier usuario del sistema ?

a) Añadir en el fichero "/etc/system" la linea " set shmsys:shminfo_shmmax = 536870912" y rebotar.
b) ejecutar "projmod -K "project.max-shm-memory=(priv,512MB,deny)" default".
c) ejecutar "export MAX-SHM-MEMORY = 512M"
d) Añadir en el fichero "/etc/default/memory" la linea "MAX-SHM-MEMORY = 512M" y rebotar.

Que privilegios debe tener un usuario para poder para usar el provider lockstat de dtrace ?

Respuesta libre ...

Recordad que la dificultad irá ascendiendo cada semana. Animaros a participar !!!

En el último Viernes Técnico quedó pendiente comprobar como el control de recursos de una Zona funciona igualmente cuando virtualizamos Linux usando brandz.

El motivo de la duda era que la información respecto al consumo de memoria que mostraba el operativo virtualizado superaba al máximo que habíamos configurado para esa zona. Por falta de tiempo no pudimos profundizar en el tema, así que prometí escribir un poco sobre el tema.

Para hacer las pruebas he usado la siguiente configuración inicial:

bash-3.2# zonecfg -z linux zonecfg:linux> info zonename: linux zonepath: /linux-zone brand: lx autoboot: false bootargs: pool: limitpriv: scheduling-class: ip-type: shared [max-lwps: 128] capped-cpu: [ncpus: 0.10] capped-memory: physical: 128M [swap: 128M] rctl: name: zone.cpu-cap value: (priv=privileged,limit=10,action=deny) rctl: name: zone.max-swap value: (priv=privileged,limit=134217728,action=deny) rctl: name: zone.max-lwps value: (priv=privileged,limit=256,action=deny)

Básicamente he limitado el uso de cpu al 10%, permitido un máximo de 128 threads y limitado a 128M el consumo de ram.

A continuación he ejecutado una fork bomb dentro de la zona, usando perl, "#perl -e ' fork while 1;'". Una vez alcanzado el límite de hilos no se han creado nuevos hijos, es decir el control de recursos ha funcionado como era esperado.

Para el segundo experimento he establecido el límite en 256. Sin embargo se ha quedado parado en 171 y no ha seguido aumentando. Podemos observarlo lanzando un prstat desde la zona global.

#prstat -z linux -t NPROC USERNAME SWAP RSS MEMORY TIME CPU 170 root 188M 98M 19% 0:00:00 8.2% 1 43 2564K 8620K 1.6% 0:00:00 0.0% Total: 171 processes, 171 lwps, load averages: 89.13, 40.49, 22.91

Al hacer un truss a cualquiera de los procesos perl el motivo ha quedado claro.

bash-3.2# truss -faelid -p 8113 Base time stamp: 1207823679.1278 [ Thu Apr 10 03:34:39 PDT 2008 ] 8113/1: psargs: perl -e fork while 1; 8113/1: 0.0478 forkx(0) Err#12 ENOMEM

La zona no disponía de más memoria, es decir el control de recursos funcionaba bien otra vez.

Resumiendo, a la hora de evaluar la performance de los procesos linux dentro del brandz, las herramientas típicas de este sistema operativo no nos proporcionan datos fiables.

Espero haber terminado de aclarar las dudas que quedaron durante la charla. :)

Segunda semana del mini-quiz de OpenSolaris, haciendo caso del feedback de gente que ha participado he ampliado el número de preguntas por semana a 3. Además una de ellas será de respuesta libre, en vez de ser de tipo test. De esta forma no bastará copiar y pegar los comandos para ver cual funciona.

La pregunta de la semana anterior y su respuesta correcta eran:

Que comando ejecutarías para listar la configuración de las interfaces de red de tu sistema ?

"#ifconfig -a"

Las preguntas para esta semana son:

Como pasarías el sistema desde multiusuario a single user ?

a) ejecutar "#init S".
b) ejecutar "#init 2".
c) ejecutar "#svcadm milestone single-user".
d) ejecutar "boot -s" en el arranque de la maquina.

Como deshabilitarías el rutado de paquetes ipv6 en opensolaris ?

a) crear un fichero llamado "/etc/notrouter".
b) crear un fichero llamado "/etc/not_ipv6_router".
c) ejecutar "#svcadm disable ipv6-forwarding".
d) crear un fichero "/etc/default/network" con el contenido "IPV6-FORWARDING=no".

Que comando usarías para ver el número de paquetes erróneos en una interfaz de red en el último minuto ?

Respuesta libre.

Recordad que la dificultad irá ascendiendo cada semana. Animaros a participar !!!

He preparado un pequeño quiz con preguntas acerca de OpenSolaris, para todos aquellos que quieran poner a prueba sus conocimientos acerca de este sistema operativo. La dificultad será ascendente, comenzando por una pregunta casi trivial y terminando con un buen nivel de "geekismo".

El funcionamiento es sencillo, cada miércoles pondré una pregunta nueva y la respuesta de la correspondiente a la semana anterior. Mi idea es que se prolongue a lo largo de 5 semanas, aunque todo depende del nivel de aceptación que tenga la propuesta. Si queréis participar podéis dejar un comentario con la respuesta en la entrada del blog correspondiente.

También podéis participar sugiriendo preguntas a mi correo electrónico (quiz at rjblog es). En caso de publicarlas se indicaría el nombre del autor.

La pregunta de esta semana es:

Que comando ejecutarías para listar la configuración de las interfaces de red de tu sistema ?

1. ifconfig
2. ifconfig -a
3. lanscan
4. ethlist -a

Para aquellos que quieran sacar provecho de las ventajas de Drtace sin necesidad de aprender a programar D ni de tener conocimientos profundos del Kernel de OpenSolaris, podéis descargar de la web de la comunidad dtrace el Dtrace ToolKit.

Una vez descargado, disfrutaremos de una serie de scripts (actualmente 260) para poder obtener información acerca de nuestro sistema. Algunos de ellos sustituyen herramientas ya disponibles anteriormente (tipo truss, snoop, etc) que cuando las ejecutamos tienen un coste notable de recursos. En otros casos se trata de scripts que nos presentan datos que hasta ahora era complicado obtener de forma sencilla.

Para empezar a usarlo solo tenemos que descomprimir el tar que nos descargamos, hay que destacar que está perfectamente documentado, con ejemplos de cada uno de los scripts que incluye.

Por mi parte me gustaría remarcar unos pocos que, por un motivo u otro, me han llamado especialmente la atención

iotop

El nombre es auto explicativo, con el fácilmente podemos detectar el responsable de los problemas de io de nuestro sistema.

2008 Mar 31 10:17:39, load: 2.64, disk_r: 28193 KB, disk_w: 42485 KB UID PID PPID CMD DEVICE MAJ MIN D BYTES 0 2639 1 scdpmd ssd26 118 208 R 48 0 3 0 fsflush ssd22 118 183 W 512 0 3 0 fsflush ssd21 118 175 W 512 [..] 700 5828 1 oracle ssd30 118 240 W 8347648 700 5828 1 oracle did30 239 64 W 8347648

dtruss

Truss siempre ha sido una de mis herramientas favoritas, sin embargo su impacto en la performance hacía desaconsejable su uso en algunas ocasiones. Este script nos presenta la misma información, con la ventaja que su consumo de recursos es mucho menor.

bash-3.2# /opt/DTT/Bin/dtruss -eo date Mon Mar 31 02:06:13 PDT 2008 ELAPSD CPU SYSCALL(args) = return 85 60 resolvepath("/usr/lib/ld.so.1\0", 0x80476E0, 0x3FF) =12 0 28 17 resolvepath("/usr/bin/date\0", 0x80476E0, 0x3FF) = 13 0 12 3 sysconfig(0x6, 0x0, 0x1DA) = 4096 0 21 11 xstat(0x2, 0x8047FEE, 0x8047B18) = 0 0 [...]

dispqlen

Este script me ha parecido muy interesante, es muy útil para comprobar el nivel de saturación de las distintas CPUS de nuestro sistema, nos indica en cuantas ocasiones el número de procesos esperado en la cola de ejecución era de 1,2,3, etc.

bash-3.2# /opt/DTT/Bin/dispqlen.d Sampling... Hit Ctrl-C to end. ^C CPU 0 value ---- Distribution ------ count 0 | 0 0 |@@@@@@@@@@@@@@@@@@@@@@@ 12441 1 | 47 2 | 95 3 | 17 [...]

dnlcstat.d

Este script me ha llamado la atención por lo original de los datos que presenta, se trata del hit rate la caché de nombres de directorios.

root@happybox # ./dnlcstat dnlc %hit hit miss 100 4007 0 100 4077 0 100 4044 0 100 1439 0

lockbydist.d

Muchas veces se atribuyen problemas de perfomance a los bloqueos, generalmente sin ningún tipo de argumentación coherente. En este caso podemos sacar estadísticas acerca del tiempo en que cada proceso ha estado esperando por culpa de bloqueos, datos que pueden ser de mucha ayuda cuando tratemos de diagnosticar un problema de performance.

En el siguiente ejemplo vemos como sched ha estado esperando en un bloqueo en 4 ocasiones entre 32 y 65 microsegundos y una ocasión entre 16 y 32 microsegundos.

root@happybox # ./lockbydist.d > /tmp/lockstat dtrace: script './lockbydist.d' matched 1 probe crsd.bin value -------- Distribution -------- count 8192 | 0 16384 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 1 32768 | 0 sched value -------- Distribution -------- count 8192 | 0 16384 |@@@@@ 1 32768 |@@@@@@@@@@@@@@@@@@@@@@ 4 65536 | 0 oracle value -------- Distribution -------- count 16384 | 0 32768 |@@@@@@ 2 65536 |@@@ 1 131072 |@@@@@@@@@@@@@@@@@@@@ 7 262144 |@@@ 1 524288 | 0 1048576 |@@@@@@ 2 2097152 |@@@ 1 4194304 | 0

topsyscall

Imagino que no hace falta explicar mucha cosa, en este caso obtenemos un listado de las llamadas al sistema más ejecutadas.

Tracing... Please wait. 2008 Mar 31 12:28:11, load average: 1.95, 2.45, 2.36 syscalls: 22647 SYSCALL COUNT waitsys 67 munmap 85 fcntl 102 setcontext 117 open 138 resolvepath 153 getpid 163 lwp_sigmask 198 ioctl 199 stat 237 close 279 brk 291 mmap 329 write 349 sigaction 441 sendmsg 609 recvmsg 872 read 1101 pollsys 1398 times 14660

Si le dedicáis un rato seguro que encontrareis muchos scripts que os pueden ser de utilidad en vuestros entornos, en total son 260 (por el momento), también os podéis pasar por la página de la comunidad drtace si necesitáis obtener algún dato y no veis claro como hacerlo.

Esta semana promete para la comunidad, para empezar se celebraran dos Viernes Técnicos en el mismo día, una en Granada y otro en Madrid. Señal del interés que despierta Opensolaris.

Además se va a presentar la primera versión de la Guía del Estudiante (Community Edition), y se colgará del portal para la descarga en formato electrónico, bajo una licencia libre. Espero que el proyecto crezca y en el futuro tengamos una versión 1.1, 1.2, etc.

Por otro lado ya tenéis disponible para la descarga la presentación del Viernes Técnico correspondiente a Virtualización, en el que se trata de LDOMs, xVM, Zonas y BrandZ, dando una visión global de todas las posibilidades que ofrece en esta área Opensolaris.

Por mi parte espero veros el viernes en Madrid, para tratar de nuevo el tema de zonas. Esta vez me llevaré mi propia copia de la presentación, que ya quedé escarmentado cuando el viernes anterior me encontré dando la charla con una versión donde faltaban la mitad de cosas y el resto estaban descolocadas. Aunque no creo que esta vez Mora me deje estar dos horas haciendo experimentos, para luego tener que dar su parte de charla en 40 minutos. :)

Dtrace es una de las grandes innovaciones de OpenSolaris, permite un nivel de monitorización difícil de imaginar anteriormente sin apenas afectar al rendimiento.

Si estamos dentro de una zona, por defecto, no podremos usarlo. La seguridad de dtrace viene definida por tres privilegios dtrace_proc, dtrace_user, y dtrace_kernel. Ninguno de los tres está incluido en el set por defecto que se aplica a los procesos de una zona.

Para que el administrador de una zona pueda depurar sus aplicaciones, debemos añadir los dos primeros cuando se la configuramos.

#zonecfg:zone1>set limitpriv="default,dtrace_proc,dtrace_user"

El tercero no está permitido, ya que proporciona derechos para observar sucesos a nivel de kernel, de modo que podríamos obtener información de procesos que no pertenecen a nuestra zona, o hacer alguna trastada usando dtrace en modo destructivo (dtrace -w). De hecho si tratamos de asignarlo, nuestra zona no arrancará.

Sin embargo podemos monitorizar los eventos del kernel relacionados con nuestros procesos desde la zona Global, para ello usaremos el predicado zonename.

dtrace -n 'fbt:genunix:: /zonename == "zone1"/ { @num[probefunc] = count(); }' dtrace: description 'fbt:genunix:: ' matched 12757 probes ^C bt_gethighbit 2 bt_getlowbit 2 clear_stale_fd 2 disp_lock_exit 2 lwp_park 2 [...]

Espero veros en un par de días en el próximo Viernes Técnico.

El pasado viernes tuve el placer de participar, de forma activa, en el "viernes Técnico" que organizó la Comunidad Hispana de OpenSolaris en Madrid.

A priori no estaba prevista mi intervención, sin embargo, debido a un problema personal de uno de los conferenciantes (que le impidió asistir), me encontré frente 60 personas (aprox.), explicando que eran las zonas y como funcionaban.

Pese a los nervios, la experiencia fue grata, espero que los asistentes disfrutaran igual que yo. Además fue interesante en vistas a preparar el viernes dedicado puramente a la virtualización, ya que me permitió apreciar cuales eran los principales puntos de interés de la gente.

Por otra parte, como asistente, disfruté especialmente con la presentación de Cheeroke, un web server ligero que me dejó un grato sabor de boca y muchas ganas de probarlo en mi pequeño kurobox.

Espero que la siguiente sesión sea, si cabe, aun mejor. Nos vemos allí.

Brandz es una tecnología que incorpora OpenSolaris, gracias a ella podemos ejecutar binarios de otros sistemas operativos en nuestro kernel.

¿ Como funciona ?, he preparado un pequeño artículo explicándolo. Al final he añadido un pequeño ejemplo de como configurar un BrandZ con Linux como invitado en unos pocos pasos.

Como posiblemente sabréis desde hace unos días está disponible para la descarga la nueva preview de Indiana. Para quienes no lo conozcan, se trata de una nueva distribución basada en OpenSolaris que ocupa un solo cd. A pesar que aún falta para la publicación de la versión final, no me he podido esperar y he querido probarla, dejando aquí mis primeras impresiones. Básicamente me he centrado en valorar su facilidad de uso.

La instalación es realmente sencilla, unas pocas pantallas nos preguntan las opciones que deseamos y pasa a copiarse a disco. Quizá en exceso simple, he echado de menos la opción de personalizar el software que se va a instalar.

Debo reconocer que hacía mucho tiempo que no utilizaba un escritorio basado en GNOME, por lo que me he encontrado un poco desorientado. Lo primero ha sido mirar las herramientas de administración que trae. En principio las tareas más comunes pueden realizarse desde un asistente gráfico, sin embargo queda algún detalle por pulir, por ejemplo la herramienta para gestionar los servicios tiene el campo de descripción vacío.

Algunas tareas nos veremos forzados ha realizarlas en modo comando, como la gestión de los discos con ZFS. Para aun usuario novel esto puede ser desconcertante. Por otro lado el uso de ZFS es una maravilla, con un par de comandos he añadido unas gigas a mis filesystem en caliente. :)

Las pruebas las he realizado sobre una máquina virtual vmware, es necesario usar las VmWare-tools para que os detecte una interfaz de red, por otro lado la instalación de estas falla debido a que faltan algunos directorios, la solución es tan simple como crearlos a mano.

Añadir software adicional ha sido sencillo, un simple #pkg install openoffice y el instalador ha hecho el trabajo solo. Aquí, una vez más, he echado de menos un asistente para facilitar la vida a los usuarios menos experimentados.

En general la impresión que me he llevado ha sido grata, lo habría sido más de poder usar un escritorio KDE, aunque imagino que solo será cuestión de tiempo que alguien añada los paquetes en el repositorio.

Sinceramente, creo que es el comienzo de una larga amistad.

Hace unos días se realizó el primer viernes técnico en las oficinas de Sun, se trataba de una presentación general de OpenSolaris y sus tecnologías asociadas. Como es lógico, se habló brevemente de las zonas. Uno de los aspectos que despertó más interés fue el modelo de seguridad aplicado para aislar unos procesos de otros.

Así pues, previendo una lluvia de preguntas al respecto cuando demos la charla de virtualización, he decidido profundizar un poco en el tema. Como siempre tomando algunos apuntes.

Como Álvaro, genialmente, introdujo en la charla, el modelo de seguridad de OpenSolaris va más allá del tradicional en *nix, root (id =0) todos los privilegios, los demás usuarios ninguno. En su lugar tenemos un modelo m´s granular, donde podemos asignar a los procesos/usuarios un set de privilegios específicos para realizar las tareas que necesiten.

Por ejemplo, ya no es necesario arrancar un servidor web como root, en su lugar podemos dar a un usuario privilegios para que sus procesos puedan hacer un bind al puerto 80. El hecho que cada proceso pueda ejecutarse con los mínimos privilegios necesarios, en contra del todo o nada tradicional, favorece enormemente la seguridad global del sistema.

Aquí tenemos los privilegios que tiene el demonio sshd:

7194:   /usr/sbin/sshd
flags = <none> 
    E: basic,contract_event,contract_observer,file_chown,
       file_chown_self,fil e_dac_execute,file_dac_read,
       file_dac_search,file_dac_write,file_owner,file_setid,
       ipc_dac_read,ipc_dac_write,ipc_owner,net_bindmlp,
       net_icmpaccess,net_mac_aware,net_privaddr,proc_audit,
       proc_chroot,proc_lock_memory,proc_owner,proc_setid,proc_t
       askid,sys_acct,sys_admin,sys_audit,sys_mount,sys_nfs,sys_resource
   I:  basic
   P:  basic,contract_event,contract_observer,file_chown,
       file_chown_self,fil e_dac_execute,file_dac_read,
       file_dac_search,file_dac_write,file_owner,file_setid,
       ipc_dac_read,ipc_dac_write,ipc_owner,net_bindmlp,
       net_icmpaccess,net_mac_aware,net_privaddr,proc_audit,
       proc_chroot,proc_lock_memory,proc_owner,proc_setid,proc_t
       askid,sys_acct,sys_admin,sys_audit,sys_mount,sys_nfs,sys_resource
   L:  basic,contract_event,contract_observer,file_chown,
       file_chown_self,fil e_dac_execute,file_dac_read,
       file_dac_search,file_dac_write,file_owner,file_setid,
       ipc_dac_read,ipc_dac_write,ipc_owner,net_bindmlp,
       net_icmpaccess,net_mac_aware,net_privaddr,proc_audit,
       proc_chroot,proc_lock_memory,proc_owner,proc_setid,proc_t
       askid,sys_acct,sys_admin,sys_audit,sys_mount,sys_nfs,sys_resource

Los privilegios que tienen los procesos dentro de una zona no global están prefijados y no pueden ser alterados por el administrador, este set está diseñado de manera que evita la interacción de los threads entre zonas , así como el uso de algún privilegio para conseguir otros adicionales. Incluso los hilos que se ejecutan con id 0 tienen este set. Estas restricciones no se aplican en la zona global.

Como consecuencia hay una serie de privilegios no podrán adquirir los procesos ejecutándose en una zona no global:

Privilege 			Description
PRIV_NET_RAWACCESS  		Allows a process to have direct access to the 
				network layer.
PRIV_PROC_CLOCK_HIGHRES 	Allows process to create high-resolution timers.
PRIV_PROC_LOCK_MEMORY 		Allows process to lock pages in physical memory.
PRIV_PROC_PRIOCNTL 		Allows process to change scheduling priority or 
				class.
PRIV_PROC_ZONE 			Allows process to control/signal other processes 
				in different zones.
[...]

De esta manera los procesos se hallan aislados de forma efectiva de aquellos que no se están ejecutando en su misma zona.

Obviamente, a parte de la restricción nivel de privilegios, es vital para la seguridad de las zonas, que los derechos de acceso a los distintos recursos sean correctos. Es decir, los privilegios nos indican que "acciones" podemos realizar (p. ej. Un chown), pero donde realizarlas está controlado a nivel de objetos (p. ej. Usando zonecfg damos acceso a los filesystem que nos interesa.).

Es la combinación de ambas cosas, privilegios y restricciones de acceso , lo que finalmente garantiza la seguridad entre zonas.

Espero que esta aburrida entrada ayude un poco a aclarar como funciona la seguridad en las zonas... :)

Una de las grandes ventajas de usar zonas es la posibilidad de hacer clones. Esto nos permite ahorrar tiempo cuando tenemos que hacer una instalación nueva. De esta forma también nos aseguramos que tendremos los mismos binarios y librerías en todas ellas, optimizando el uso de memoria.

Para realizar un clon de una zona tenemos que usar el comando zoneadm, si nuestro filesystem es ufs usaremos la opción copy, en cambio si nuestra zona está en un filesystem ZFS podemos usar la opción zfs snapshoot que nos ahorrará un poco de tiempo. Consultad la página man para ver la sintaxis concreta.

Hay que tener en cuenta que la zona de origen de la copia ha de estar detenida.

Os copio la captura mi shell clonando una zona sobre un filesystem Ufs, como podéis ver son unos pocos pasos para nada complejos.

bash-3.00# zoneadm list -cv
  ID NAME             STATUS    PATH          BRAND    IP
  0  global           running   /             native   shared
  1  linux            running   /zone         lx       shared
  -  test             installed /zone_OS      native   shared

bash-3.00# zonecfg -z new_zone
new_zone: No such zone configured
Use 'create' to begin configuring a new zone.
zonecfg:new_zone> create
zonecfg:new_zone> set zonepath=/zone_clone
zonecfg:new_zone> commit
zonecfg:new_zone> exit
bash-3.00# mkdir /zone_clone
bash-3.00# chmod 700 /zone_clone
bash-3.00# zoneadm -z new_zone clone test
Copying /zone_OS...
bash-3.00# zoneadm -z new_zone boot
bash-3.00# zoneadm list -cv
ID	NAME		STATUS		PATH		BRAND	IP
0	global		running		/		native	shared
1	linux		running		/zone		lx	shared
5	new_zone	running		/zone_clone	native	shared
-	test		installed	/zone_OS	native	shared

bash-3.00# zlogin -C new_zone
[Connected to zone 'new_zone' console]

A partir de aquí nos saldrá el menú para personalizar el entorno. En unos pocos pasos más tenemos una copia de la zona original configurada.

Poco a poco la web va creciendo, hasta ahora estaba alojada en un pequeño ordenador que tengo en casa. La conexión es una línea ADSL normal y corriente. El dominio eregion.no-ip.org está alojado en un DNS dinámico gratuito. La principal ventaja es un coste mensual bajo y la libertad de configurar el servidor como quiera.

Sin embargo desde el principio he estado teniendo problemas con la conexión, a parte de ser lenta, he sufrido frecuentes cortes, por lo que la web se quedaba inaccesible durante un rato (la última vez un fin de semana entero). Además cuando el crawler de google u otro buscador examinaba el contenido la línea se quedaba frita, dando muchas veces errores de web inaccesible.

Esto ha motivado que decida mover el contenido a un servidor más profesional, con una conexión estable y más rápida. Aprovechando la circunstancia he contratado también un dominio propio.

He decidido mantener el mismo motor y estilo para poder hacer la migración lo más rápida posible, quizá en el futuro me anime a montar algo más sofisticado.

La actual página continuará activa durante unos meses más pero ya no añadiré nuevo contenido.

Actualizad vuestros marcadores y suscripciones RSS al nuevo dominio, por favor.

A partir de ahora estamos en http://rjblog.es
Suscripción a todo el blog
Suscripción al canal OpenSolaris