Despedida
Hace un tiempo que quería escribir esta entrada, pero por una cosa o por otra, siempre acababa dejándolo para luego. Bien, el luego ya ha llegado y hoy he decidido "dejar al lado el tema de Solaris" para despedirme de mis compañeros de MasterD.
Si, he cambiado de trabajo, y la verdad es que después de cinco años de trabajo con ellos, lo cierto es que los voy a echar de menos. Echaré de menos esos marrones que -aunque siempre complicados- conseguiamos solucionarlos poniendo nuestro esfuerzo y sobre todo, nuestro compañerismo.
No os voy a aburrir sobre las miles de anécdotas que he acumulado en este tiempo, pero si que os puedo decir que las personas con las que he compartido este tiempo, son más que simples compañeros de trabajo.
Realmente, creo que todo este tiempo hemos sido una pequeña familia -con nuestros más y nuestros menos- pero que siempre hemos estado ahí para cualquier cosa, aunque no tuviese nada que ver con nuestro área de trabajo. No nos importaba "remamgarnos" y, "ale", a ver cómo lo solucionamos.
Y ahora qué
Pues ahora, comienzo una nueva andadura en Havoc Tec, una consultora especializa en Seguridad, Solaris y PostgreSQL. Espero que en esta nueva historia, también pueda escribir comenatrios así algún día.
Havoc Tec - www.havoctec.com
Aunque es un proyecto muy joven, tiene muchas de las cosas que considero interesantes: Solaris, Hadoop, PostgreSQL. Por ello, y, por qué no, porque soy uno de los socios fundadores, creo que será una experiencia muy gratificante.
Ya no os aburro más, y os prometo que seguiré contando historias de Solaris, PostgreSQL y Hadoop durante mucho tiempo ... :D
Por último, quiero despedirme de mis compañeros de trabajo, Luis, Javi, Ricardo, Victor, J, Vero, Sara, Julio alias "el becario", Ana, Pedro, Fermín, Cristian y especialmente de Nazareth. Para los que habéis abandonado el barco antes que yo, también os deseo lo mejor, Marcos y Luisito.
Ha sido un placer trabajar con vosotros,
Urko Benito
SafeChildren Banner
jueves, 28 de octubre de 2010
lunes, 18 de octubre de 2010
Cómo ver las estadísticas de Memoria en Solaris
Introducción
Ya hemos hablado en varias ocasiones de la swap y Cómo ampliar el tamaño swap en Solaris. Sin embargo, en esta ocasión vamos a ver Cómo se reparte nuestra memoria del sistema.
Para ello, utilizaremos el comando <mdb> con la opción <-k> para depurar nuestro kernel. Realmente, <mdb> es un debugger, y vamos a llamar a <::memstat> para que nos muestre la distribución de la memoria en nuesto sistema vivo
Referencias
Ya hemos hablado en varias ocasiones de la swap y Cómo ampliar el tamaño swap en Solaris. Sin embargo, en esta ocasión vamos a ver Cómo se reparte nuestra memoria del sistema.
Para ello, utilizaremos el comando <mdb> con la opción <-k> para depurar nuestro kernel. Realmente, <mdb> es un debugger, y vamos a llamar a <::memstat> para que nos muestre la distribución de la memoria en nuesto sistema vivo
root@openzooey:~# mdb -k
Loading modules: [ unix genunix specfs dtrace mac cpu.generic uppc pcplusmp scsi_vhci zfs ip hook neti sockfs arp usba fctl stmf stmf_sbd lofs random idm sd ipc crypto sppp cpc fcip nfs ufs logindmux ptm ]
> ::memstat
Page Summary Pages MB %Tot
------------ -------- ------------ ----
Kernel 73508 287 28%
ZFS File Data 69386 271 27%
Anon 82635 322 32%
Exec and libs 2169 8 1%
Page cache 9139 35 4%
Free (cachelist) 7849 30 3%
Free (freelist) 15296 59 6%
Total 259982 1015
Physical 259981 1015
> ^D
Referencias
sábado, 16 de octubre de 2010
Modelo de Seguridad de Solaris: RBAC, Roles y Privilegios - Parte 6
Introducción
Continuando con nuestra serie de RBAC, Roles y Privilegios y cómo podemos aplicarlo a nuestras instalaciones. En esta ocasión, toca hablar de, ya que hemos avanzado en nuestros conceptos del modelo de seguridad de Solaris.
Qué son las Autorizaciones
Una autorización es un privilegio discreto que puede ser asignado a un usuario o un rol, dicho de otro modo, es un privilegio que nosotros definimos sin que por ello deba ir asignado a un privilegio de UNIX. De esta forma, hacemos que la verificación <UID=0> pase a ser secundaria.
No todos los comandos de Solaris aceptan el uso de autorizaciones, actualmente está soportado en:
Formato de una autorización
Las autorizaciones se encuentran definidas en el fichero </etc/security/auth_attr> y tienen el siguiente formato:
Para ver las autorizaciones asignadas a un usuario o role, simplemente deberemos ejecutar el comando <auths [nombre]>, dónde nombre será un role o un usuario, si no ponemos nada, entonces nos mostrará las autorizaciones del usuario actual, por ejemplo:
Asignar una Autorización
Las autorizaciones pueden ser asignadas a roles o usuarios, para ello utilizaremos el comando <rolemod> o <usermod> con la opción <-A autorizacion1, autorizacion2, autorizacion>.
Esta opción sustituye no añade, por lo tanto, si quereis conservar las actuales, debereis incluirlas. Para eliminar las autorizaciones, simplemente utilizamos la opción <-A "">, por ejemplo:
Veamos un Ejemplo Completo
Vamos a partir de Cómo Instalar Apache Tomcat en Solaris utilizando SMF, para realizar algunos cambios en la instalación, uso de roles y autorizaciones.
En ese post -Instalación de Tomcat- creabamos un grupo y usuario llamado <webrunner>, en esta ocasión, vamos a crear el grupo de igual forma, pero en vez de un usuario llamado <webrunner> vamos a crear un <role> llamado <tomcat6>.
Por lo tanto, tendremos la siguiente estructura de instalación de Apache Tomcat
Como hemos hecho en otras ocasiones, crearemos un grupo, projecto y un role para nuestra instalación
Creación de las Autorizaciones
Vamos a crear las autorizaciones necesarias para la gestión de nuestro servicio Apache Tomcat desde Solaris SMF, para ello, definiremos una para <gestión>, otra para <cambio> y por último nuestro <grant>
Dentro de Solaris SMF, debemos asignar una autorización para la propiedad <action> que nos permitirá gestionar los servicios, y la propiedad <value> para cambiar los valores. Básicamente, si tenemos sólo la autorización para <action> podremos activar/desactivar los servicios, pero "de forma temporal" -es decir utilizando la opción <-t>- ya que no tenemos la autorización <value> para "guardar el cambio"
Modificación del Manifest
A continuación editaremos nuestro archivo Manifest para Apache Tomcat 6, o bien, podéis bajaros la versión modificada para Apache Tomcat 6 con Autorizaciones de Solaris. Y, aunque el method no ha sido modificado, podéis descargarlo desde Apache Tomcat Method for Solaris SMF
En las sección general añadiremos las siguientes propiedades:
Cargar el Nuevo Manifest de Apache Tomcat
Si habéis decidido descargar el nuevo Manifest para Apache Tomcat 6 utilizando Autorizaciones, simplemente deberemos utilizar <wget> y volverlo a cargar. Si, por el contrario lo habéis modificado, sólo será necesario recargarlo con <svccfg>
Asignar las Autorizaciones
Por último, vamos a asignar las autorizaciones a un usuario que será el encargado de gestionar el servicio, pero no de configurarlo, en nuestro caso, será <webope>
Espero que con este ejemplo completo de uso de autorizaciones aplicado al servicio SMF, podáis utilizar un elemento muy interesante en cuanto a sistemas de seguridad granulados.
Tal vez alguno se cuestione el por qué asignar las autorizaciones a un usuario (o role) que no tiene permisos de configuración pero si de inicio y parada, parece una tontería, no? Bueno, la verdad es que si pensamos en sistemas autónomos de monitorización, como por ejemplo, Nagios para Solaris 10, entenderemos que podemos configurar una acción para el estado MAINTANCE que llame a un script que haga un refresh del servicio.
Es cierto que podemos utilizar el usuario del servicio -en nuestro caso tomcat6- pero, si alguien tomase el control de nuestra máquina "nagios" puede hacer mucho daño ...
Además, de esta forma, podemos tener separado el rol de cada uno de nuestros empleados, por ejemplo, Administradores de Sistemas de Operadores, y por lo tanto, dejar a un Operador que haga un "refresh" pero no un "stop" del servicio.
Queda un último punto, que iremos viendo a lo largo de más ejemplos que es Cómo Aplicar Autorizaciones a Scripts y Programas Antiguos
<< RBAC, Roles y Privilegios en Solaris 10 - Parte 1
<< RBAC, Roles y Privilegios en Solaris 10 - Parte 2
<< RBAC, Roles y Privilegios en Solaris 10 - Parte 3
<< RBAC, Roles y Privilegios en Solaris 10 - Parte 4
<< RBAC, Roles y Privilegios en Solaris 10 - Parte 5
Referencias
Continuando con nuestra serie de RBAC, Roles y Privilegios y cómo podemos aplicarlo a nuestras instalaciones. En esta ocasión, toca hablar de
Qué son las Autorizaciones
Una autorización es un privilegio discreto que puede ser asignado a un usuario o un rol, dicho de otro modo, es un privilegio que nosotros definimos sin que por ello deba ir asignado a un privilegio de UNIX. De esta forma, hacemos que la verificación <UID=0> pase a ser secundaria.
No todos los comandos de Solaris aceptan el uso de autorizaciones, actualmente está soportado en:
- Suite Solaris Management Console
- Comandos de administración de Auditoria, como auditconfig y auditreduce
- Comandos de administración de Impresión, como lpadmin y lpfilter
- Comandos de Jobs, como at, atq, batch y crontab
- Comandos orientados a dispositivos, como allocate, deallocate, list_devices y cdrw.
Formato de una autorización
Las autorizaciones se encuentran definidas en el fichero </etc/security/auth_attr> y tienen el siguiente formato:
prefix.suffix:res1:res2:short desc:long desc:attrDonde
- prefix: Identifica el prefijo, por conveniencia las autorizaciones de Sun Solaris comienzan con <solaris.>, para las nuestras debemos utilizar nuestro Dominio de Internet al revés, por ejemplo, <com.sfchildren.>
- suffix: Sufijo del componente. Cuando una autorización termina con <grant> hacemos que quien posea dicha autorización pueda otorgarla a otros, por ejemplo, teniendo la autorizaciones <solaris.com.sfchildren.asengine.grant y solaris.com.sfchildren.asengine.analyzer>, si asignamos <solaris.com.sfchildren.asengine.grant>, a un role o usuario, éste podrá asignar la autorización <solaris.com.sfchildren.asengine.analyzer> a otro role o usuario.
- res1 y res2: Campos reservados
- short desc: Descripción corta
- long desc: Descripción larga
- attr: Definición de atributos con el formato <KEY=VALUE>
solaris.admin.usermgr.pswd:::Change Password::help=AuthUserMgrPswd.htmlVer las autorizaciones asignadas
Para ver las autorizaciones asignadas a un usuario o role, simplemente deberemos ejecutar el comando <auths [nombre]>, dónde nombre será un role o un usuario, si no ponemos nada, entonces nos mostrará las autorizaciones del usuario actual, por ejemplo:
root@openzooey:~# auths
solaris.*
root@openzooey:~# auths tomcat
solaris.admin.wusb.read,
solaris.device.cdrw,
solaris.device.mount.removable,
solaris.mail.mailq,
solaris.profmgr.read
Asignar una Autorización
Las autorizaciones pueden ser asignadas a roles o usuarios, para ello utilizaremos el comando <rolemod> o <usermod> con la opción <-A autorizacion1, autorizacion2, autorizacion>.
Esta opción sustituye no añade, por lo tanto, si quereis conservar las actuales, debereis incluirlas. Para eliminar las autorizaciones, simplemente utilizamos la opción <-A "">, por ejemplo:
root@openzooey:~# rolemod -A solaris.org.apache.smf.value.tomcat,solaris.org.apache.smf.manage.tomcat
root@openzooey:~# auths tomcat
solaris.org.apache.smf.manage.tomcat,
solaris.org.apache.smf.value.tomcat,
solaris.admin.wusb.read,
solaris.device.cdrw,
solaris.device.mount.removable,
solaris.mail.mailq,
solaris.profmgr.read
Veamos un Ejemplo Completo
Vamos a partir de Cómo Instalar Apache Tomcat en Solaris utilizando SMF, para realizar algunos cambios en la instalación, uso de roles y autorizaciones.
En ese post -Instalación de Tomcat- creabamos un grupo y usuario llamado <webrunner>, en esta ocasión, vamos a crear el grupo de igual forma, pero en vez de un usuario llamado <webrunner> vamos a crear un <role> llamado <tomcat6>.
Por lo tanto, tendremos la siguiente estructura de instalación de Apache Tomcat
- TOMCAT_HOME: /opt/www/tomcat6
- JAVA_HOME: /usr/java
- TOMCAT_USER: tomcat6
- TOMCAT_GROUP: webrunner
- PROJECT_NAME: tomcat6
Como hemos hecho en otras ocasiones, crearemos un grupo, projecto y un role para nuestra instalación
# groupadd webrunner
# roleadd -s /bin/pfbash -d /export/home/tomcat6 -m -g webrunner tomcat6
# projadd -c 'Tomcat6 Project' -G webrunner -U tomcat6 tomcat6
# passwd tomcat6
New Password: *********
Re-enter new Password: *********
passwd: password successfully changed for tomcat6
Creación de las Autorizaciones
Vamos a crear las autorizaciones necesarias para la gestión de nuestro servicio Apache Tomcat desde Solaris SMF, para ello, definiremos una para <gestión>, otra para <cambio> y por último nuestro <grant>
Dentro de Solaris SMF, debemos asignar una autorización para la propiedad <action> que nos permitirá gestionar los servicios, y la propiedad <value> para cambiar los valores. Básicamente, si tenemos sólo la autorización para <action> podremos activar/desactivar los servicios, pero "de forma temporal" -es decir utilizando la opción <-t>- ya que no tenemos la autorización <value> para "guardar el cambio"
# echo "solaris.org.apache.smf.value.tomcat:::Change value of Apache Tomcat::" >> /etc/security/auth_attrLa estructura de la autorización utilizada es solaris.org.apache.smf., por un tema de compatibilidad, pero podíamos haber puesto cualquier cadena, por ejemplo, solaris.org.apache.tomcat6.administrar
# echo "solaris.org.apache.smf.manage.tomcat:::Manage Apache Tomcat service states::" >> /etc/security/auth_attr
Modificación del Manifest
A continuación editaremos nuestro archivo Manifest para Apache Tomcat 6, o bien, podéis bajaros la versión modificada para Apache Tomcat 6 con Autorizaciones de Solaris. Y, aunque el method no ha sido modificado, podéis descargarlo desde Apache Tomcat Method for Solaris SMF
En las sección general añadiremos las siguientes propiedades:
<property_group name='general' type='framework'>Y dentro de nuestra instancia, añadiremos una propiedad llamada <value_authorization> para definir el valor de la autorización.
<propval
name='value_authorization'
type='astring'
value='solaris.org.apache.smf.value.tomcat' />
<propval
name='action_authorization'
type='astring'
value='solaris.org.apache.smf.manage.tomcat' />
</property_group>
<property_group name='tomcat_6' type='application'>
<propval name='home' type='astring'
value='/opt/www/tomcat-6.0' />
<propval name='jvmargs' type='astring'
value='-d32 -Xms64m -Xmx128m' />
<propval name='project' type='astring'
value='tomcat6' />
<propval name='java_home' type='astring'
value='/usr/java' />
<propval name='value_authorization' type='astring'
value='solaris.org.apache.smf.value.tomcat' />
</property_group>
Cargar el Nuevo Manifest de Apache Tomcat
Si habéis decidido descargar el nuevo Manifest para Apache Tomcat 6 utilizando Autorizaciones, simplemente deberemos utilizar <wget> y volverlo a cargar. Si, por el contrario lo habéis modificado, sólo será necesario recargarlo con <svccfg>
root@openzooey:/# mkdir -p /var/svc/manifest/application/web/
root@openzooey:/# cd /var/svc/manifest/application/web
root@openzooey:/var/svc/manifest/application/web# wget http://blog.sfchildren.com/blogger/tomcat-roles/smf/tomcat_6.xml
root@openzooey:/var/svc/manifest/application/web# svccfg
svc:> validate tomcat_6.xml
svc:> import tomcat_6.xml
svc:> quit
root@openzooey:/var/svc/manifest/application/web# svcs tomcat_6
STATE STIME FMRI
disabled 16:17:08 svc:/application/web/tomcat_6:default_32bits
disabled 16:17:08 svc:/application/web/tomcat_6:default_64bits
Asignar las Autorizaciones
Por último, vamos a asignar las autorizaciones a un usuario que será el encargado de gestionar el servicio, pero no de configurarlo, en nuestro caso, será <webope>
$ idSi intentamos activar el servicio <tomcat_6:default_64bits> con el usuario <webope> antes de asignar las autorizaciones, veremos el siguiente error:
uid=108(webope) gid=100(webope)
$ auths
solaris.admin.wusb.read,
solaris.device.cdrw,
solaris.device.mount.removable,
solaris.mail.mailq,
solaris.profmgr.read
webope@openzooey:~$ svcadm enable tomcat_6:default_64bitsBien, ahora asignaremos las autorizaciones y volveremos a repetir el comando de activación.
svcadm: svc:/application/web/tomcat_6:default_64bits: Permission denied.
root@openzooey:/# usermod -A solaris.org.apache.smf.manage.tomcat,solaris.org.apache.smf.value.tomcat webopeY también podemos desactivar el servicio, utilizando la opción <disable>
root@openzooey:/# su - webope
OpenIndiana SunOS 5.11 oi_147 September 2010
webope@openzooey:~$ svcadm enable tomcat_6:default_64bits
webope@openzooey:~$ svcs tomcat_6:default_64bits
STATE STIME FMRI
online 16:47:42 svc:/application/web/tomcat_6:default_64bits
webope@openzooey:~$ svcadm disable tomcat_6:default_64bitsConclusiones
webope@openzooey:~$ svcs tomcat_6:default_64bits
STATE STIME FMRI
disabled 16:48:40 svc:/application/web/tomcat_6:default_64bits
Espero que con este ejemplo completo de uso de autorizaciones aplicado al servicio SMF, podáis utilizar un elemento muy interesante en cuanto a sistemas de seguridad granulados.
Tal vez alguno se cuestione el por qué asignar las autorizaciones a un usuario (o role) que no tiene permisos de configuración pero si de inicio y parada, parece una tontería, no? Bueno, la verdad es que si pensamos en sistemas autónomos de monitorización, como por ejemplo, Nagios para Solaris 10, entenderemos que podemos configurar una acción para el estado MAINTANCE que llame a un script que haga un refresh del servicio.
Es cierto que podemos utilizar el usuario del servicio -en nuestro caso tomcat6- pero, si alguien tomase el control de nuestra máquina "nagios" puede hacer mucho daño ...
Además, de esta forma, podemos tener separado el rol de cada uno de nuestros empleados, por ejemplo, Administradores de Sistemas de Operadores, y por lo tanto, dejar a un Operador que haga un "refresh" pero no un "stop" del servicio.
Queda un último punto, que iremos viendo a lo largo de más ejemplos que es Cómo Aplicar Autorizaciones a Scripts y Programas Antiguos
<< RBAC, Roles y Privilegios en Solaris 10 - Parte 1
<< RBAC, Roles y Privilegios en Solaris 10 - Parte 2
<< RBAC, Roles y Privilegios en Solaris 10 - Parte 3
<< RBAC, Roles y Privilegios en Solaris 10 - Parte 4
<< RBAC, Roles y Privilegios en Solaris 10 - Parte 5
Referencias
martes, 12 de octubre de 2010
Cómo Cambiar el TimeOut de arranque en OpenIndiana
Introducción
OpenIndiana al igual que OpenSolaris utiliza GRUB para iniciar el sistema. Sin embargo, debemos tener en cuenta el tipo de instalación en OpenIndiana, ya que si utilizamos ZFS como sistema de ficheros la ubicación del archivo de configuración para GRUB será diferente.
Si tenemos UFS como sistema de ficheros, encontraremos el archivo de configuración en </boot/grub/menu.lst>
Si tenemos ZFS como sistema de ficheros, entonces el archivo de configuración se encontrará en </{pool}/boot/grub/menu.lst>
Ya que OpenIndiana el sistema de ficheros es ZFS, vamos a ver cómo podemos editar nuestro <boot.lst>, para ello, primero vamos a identificar nuestro pool -en nuestro caso será rpool1-
Conclusión
La única diferencia que existe se encuentra en el formato de sistema de ficheros, pero una vez superado eso, ya podemos editar nuestro sistema de configuración <menu.lst> de la misma forma de siempre.
Referencias
OpenIndiana al igual que OpenSolaris utiliza GRUB para iniciar el sistema. Sin embargo, debemos tener en cuenta el tipo de instalación en OpenIndiana, ya que si utilizamos ZFS como sistema de ficheros la ubicación del archivo de configuración para GRUB será diferente.
Si tenemos UFS como sistema de ficheros, encontraremos el archivo de configuración en </boot/grub/menu.lst>
Si tenemos ZFS como sistema de ficheros, entonces el archivo de configuración se encontrará en </{pool}/boot/grub/menu.lst>
Ya que OpenIndiana el sistema de ficheros es ZFS, vamos a ver cómo podemos editar nuestro <boot.lst>, para ello, primero vamos a identificar nuestro pool -en nuestro caso será rpool1-
urko@openzooey:~$ pfexec /usr/sbin/zpool listPor lo tanto, deberemos editar nuestro
NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT
rpool1 15,9G 9,96G 5,91G 62% 1.00x ONLINE -
urko@openzooey:~$ pfexec vi /rpool1/boot/grub/menu.lst
splashimage /boot/grub/splash.xpm.gz
background 215ECA
default 1
timeout 5
:wq
Conclusión
La única diferencia que existe se encuentra en el formato de sistema de ficheros, pero una vez superado eso, ya podemos editar nuestro sistema de configuración <menu.lst> de la misma forma de siempre.
Referencias
jueves, 7 de octubre de 2010
Instalar OpenIndiana desde OpenSolaris
Introducción
Cuando se anunció IllumOS, hablábamos de Cómo sería el futuro de OpenSolaris y Si existiría una forma de migrar desde OpenSolaris. Posteriormente, nace OpenIndiana una distribución de OpenSolaris que quiere tomar el relevo de éste.
Bien, después de unos días ya podemos decir que la migración de OpenSolaris a OpenIndiana es fácil, sencilla y rápida, por eso, hoy hablaremos de ello.
Lo primero, vamos a utilizar una instalación limpia de OpenSolaris realizada utilizando el Instalador de Texto como ya hablábamos en Cómo Instalar OpenSolaris desde Consola, para, posteriormente actualizarnos a la última versión de OpenIndiana.
El único requisito que existe, es que debemos tener conexión a Internet, ya que el upgrade se realiza utilizando IPS -paquetes de repositorios- y por lo tanto, es necesario
Para hacer más sencillo el paso, he decidido hacerlo desde el repositorio principal de OpenIndiana, aunque volveremos a retomar el tema de Cómo montar un repositorio IPS Local en un futuro.
Instalación de OpenSolaris
Como he comentado en la introducción, vamos a utilizar una instalación de OpenSolaris siguiendo el post que escribí de Cómo Instalar OpenSolaris desde Consola. Una vez instalado, y con conexión a la red, podemos proceder con la actualización.
Instalación de OpenIndiana
Durante el proceso de instalación de OpenIndiana, el sistema nos creará un nuevo boot, por lo tanto, debéis tener en cuenta el espacio disponible en vuestro sistema.
Una vez nuestro sistema OpenSolaris esté online, verificamos que tenemos la versión svn_134 ya que esto nos facilitará bastante las cosas.
Añadir los "publisher" de OpenIndiana
Debemos añadir los repositorios de OpenIndiana desde los cuales nuestro sistema actulalizará los paquetes, además y muy importante "no debemos eliminar el repositorio de OpenSolaris" ya que, los paquetes que no se encuentren en OpenIndiana, se buscarán en OpenSolaris.
Lanzamos <image-update>
Una vez nuestro catálogo se encuentra actualizado, volveremos a lanzar el comando de actualización, y sí, en esta ocasión nos dirá que hay actualizaciones.
El proceso de actualización son unos 300Mb, así que tardará un poquito ...
Reboot del Sistema
Una vez finalizada la actualización, se nos informa que se ha creado un nuevo boot llamado "opensolaris-1" y que será montado en "/" -es decir, se activará-
Para ello, deberemos rebootar la máquina "utilizando el comando <init 6>
Después del boot
Una vez el sistema se ha iniciado, podemos comprobar cómo ahora ya no es OpenSolaris, sino OpenIndiana haciendo una Verificación versión de Solaris
Conclusiones
Vemos cómo el proceso de actualización ha mejorado mucho desde los primeros días de vida de OpenIndiana. He optado por esperar para tener la seguridad de que todo fuese bien y así ha sido en muchas actualizaciones -ya he migrado mis OpenSolaris a OpenIndiana :D-
El único inconveniente -como en OpenSolaris- es la necesidad de tener conexión a Internet, pero espero que con el post de Cómo crear un repositorio de OpenIndiana se solucionen esos problemas.
Referencias
Cuando se anunció IllumOS, hablábamos de Cómo sería el futuro de OpenSolaris y Si existiría una forma de migrar desde OpenSolaris. Posteriormente, nace OpenIndiana una distribución de OpenSolaris que quiere tomar el relevo de éste.
Bien, después de unos días ya podemos decir que la migración de OpenSolaris a OpenIndiana es fácil, sencilla y rápida, por eso, hoy hablaremos de ello.
Lo primero, vamos a utilizar una instalación limpia de OpenSolaris realizada utilizando el Instalador de Texto como ya hablábamos en Cómo Instalar OpenSolaris desde Consola, para, posteriormente actualizarnos a la última versión de OpenIndiana.
El único requisito que existe, es que debemos tener conexión a Internet, ya que el upgrade se realiza utilizando IPS -paquetes de repositorios- y por lo tanto, es necesario
- Conexión a Internet
- Tener una "réplica" del repositorio IPS en local
Para hacer más sencillo el paso, he decidido hacerlo desde el repositorio principal de OpenIndiana, aunque volveremos a retomar el tema de Cómo montar un repositorio IPS Local en un futuro.
Instalación de OpenSolaris
Como he comentado en la introducción, vamos a utilizar una instalación de OpenSolaris siguiendo el post que escribí de Cómo Instalar OpenSolaris desde Consola. Una vez instalado, y con conexión a la red, podemos proceder con la actualización.
Instalación de OpenIndiana
Durante el proceso de instalación de OpenIndiana, el sistema nos creará un nuevo boot, por lo tanto, debéis tener en cuenta el espacio disponible en vuestro sistema.
Una vez nuestro sistema OpenSolaris esté online, verificamos que tenemos la versión svn_134 ya que esto nos facilitará bastante las cosas.
urko@openzooey:~$ cat /etc/releaseVerificamos que nuestro usuario tiene el rol de root -recordar el Uso de Roles y Privilegios en Solaris- o nos cambiamos a root
OpenSolaris Development snv_134 X86
Copyright 2010 Sun Microsystems, Inc. All Rights Reserved.
Use is subject to license terms.
Assembled 01 March 2010
urko@openzooey:~$ rolesActualizamos nuestro OpenSolaris, este comando, si nos encontramos en la versión svn_134 no informará que "no hay nada que actualizar", si estuviésemos en otra inferior, actualizaría los paquetes necesarios.
root
urko@openzooey:~$ pfexec pkg image-update
No updates available for this image.
Añadir los "publisher" de OpenIndiana
Debemos añadir los repositorios de OpenIndiana desde los cuales nuestro sistema actulalizará los paquetes, además y muy importante "no debemos eliminar el repositorio de OpenSolaris" ya que, los paquetes que no se encuentren en OpenIndiana, se buscarán en OpenSolaris.
urko@openzooey:~$ pfexec pkg set-publisher --non-sticky opensolaris.org
urko@openzooey:~$ pfexec pkg set-publisher -P -O http://pkg.openindiana.org/dev openindiana.org
Lanzamos <image-update>
Una vez nuestro catálogo se encuentra actualizado, volveremos a lanzar el comando de actualización, y sí, en esta ocasión nos dirá que hay actualizaciones.
El proceso de actualización son unos 300Mb, así que tardará un poquito ...
urko@openzooey:~$ pfexec pkg image-update -v
Solver: [ Variables: 871 Clauses: 5072 Iterations: 2 State: Succeeded]
Timings: [phase 1: 0.993, phase 2: 0.016, phase 3: 9.573, phase 4: 1.953, phase 5: 0.005]
Maintained incorporations: None
Package version changes:
DOWNLOAD PKGS FILES XFER (MB)
Completed 431/431 17037/17037 241.5/241.5
PHASE ACTIONS
Removal Phase 7356/7356
Install Phase 12612/12612
Update Phase 17674/17674
A clone of opensolaris exists and has been updated and activated.
On the next boot the Boot Environment opensolaris-1 will be mounted on '/'.
Reboot when ready to switch to this updated BE.
Reboot del Sistema
Una vez finalizada la actualización, se nos informa que se ha creado un nuevo boot llamado "opensolaris-1" y que será montado en "/" -es decir, se activará-
Para ello, deberemos rebootar la máquina "utilizando el comando <init 6>
urko@openzooey:~$ pfexec init 6
Después del boot
Una vez el sistema se ha iniciado, podemos comprobar cómo ahora ya no es OpenSolaris, sino OpenIndiana haciendo una Verificación versión de Solaris
urko@openzooey:~$ cat /etc/release
OpenIndiana Development oi_147 X86
Copyright 2010 Oracle and/or its affiliates. All rights reserved.
Use is subject to license terms.
Assembled 14 September 2010
Conclusiones
Vemos cómo el proceso de actualización ha mejorado mucho desde los primeros días de vida de OpenIndiana. He optado por esperar para tener la seguridad de que todo fuese bien y así ha sido en muchas actualizaciones -ya he migrado mis OpenSolaris a OpenIndiana :D-
El único inconveniente -como en OpenSolaris- es la necesidad de tener conexión a Internet, pero espero que con el post de Cómo crear un repositorio de OpenIndiana se solucionen esos problemas.
Referencias
domingo, 3 de octubre de 2010
Cómo Limitar el tamaño de /tmp en Solaris y OpenIndiana
Introducción
En Solaris el directorio temporal </tmp>, o mejor dicho, el sistema de archivos <tmpfs> es un sistema de archivos en memoria, y por lo tanto, es muy eficiente, pero ... si no tenemos cuidado podemos tener problemas en nuestro host.
Por defecto, <tmpfs> utilizará nuestro área <swap> para crear la unidad, y por lo tanto, si no definimos unos valores máximos, podremos sufrir un desvanecimiento de nuestro host -por que se quede sin memoria física-.
Para solucionarlo, simplemente definiremos la opción <size=XYZm> en el archivo </etc/vfstab>, por ejemplo:
Referencias
En Solaris el directorio temporal </tmp>, o mejor dicho, el sistema de archivos <tmpfs> es un sistema de archivos en memoria, y por lo tanto, es muy eficiente, pero ... si no tenemos cuidado podemos tener problemas en nuestro host.
Por defecto, <tmpfs> utilizará nuestro área <swap> para crear la unidad, y por lo tanto, si no definimos unos valores máximos, podremos sufrir un desvanecimiento de nuestro host -por que se quede sin memoria física-.
Para solucionarlo, simplemente definiremos la opción <size=XYZm> en el archivo </etc/vfstab>, por ejemplo:
# cat /etc/vfstab |grep tmp
swap - /tmp tmpfs - yes -
# vi /etc/vfstab
swap - /tmp tmpfs - yes size=512m
:wq
# cat /etc/vfstab |grep tmp
swap - /tmp tmpfs - yes size=512m
Referencias
Suscribirse a:
Entradas (Atom)