jueves, 30 de octubre de 2014




Instalar Solaris paso a paso, en Virtual Box.
A continuación se muestra un video tutorial de la instalación paso a paso del Sistema Operativo Solaris, en Virtual Box.
El presente video fue realizado por:
Universidad Autónoma del Estado de México.
Centro Universitario UAEM Atlacomulco
Ingeniería en Computación

Marlen Mendoza Antonio.
Cuauhtémoc Morelos Martínez.

Link del Video:

Recuerden que la imagen iso del Sistema Operativo Solaris la pueden Descargar desde la página oficial de Solaris.
 Novedades de Solaris

 Solaris Service Manager es una nueva infraestructura que viene
a sustituir al clásico inicio secuencial de Unix System V. Esta
nueva infraestructura permite arrancar los servicios de forma
paralela acorde a sus relaciones de dependencia. Permite al
administrador observar, deshabilitar, arrancar y parar de una
manera sencilla y eficiente.
• Solaris Fault Manager es un sistema de auto recuperación que
cuando detecta un fallo informa al administrador y le dirige a las
web de Sun proponiéndole posibles soluciones al problema.
Entre sus funciones automáticas comprende la desactivación del
elemento hardware o software que esta generando el problema.
• Solaris Containers es una tecnología de virtualización que
permite la ejecución de servicios y aplicaciones de forma
totalmente aisladas.
• ZFS (Solaris Zeta File System) nuevo sistema de archivos de
128bits. Su capacidad de almacenamientos es practicante
ilimitada. Su implantación y administración comparada con los
sistemas anteriores muy sencilla. Implementa un nuevo modelo
de ACL sencillo de administrar utilizando los comandos chmod y
ls.
 DTrace es una potente herramienta que permite a los
administradores observar procesos del núcleo y de los usuarios.
Se compone de más de 30.000 sensores que aportan información
sobre las aplicaciones asociadas a estos.
• PatchPro que anteriormente era un producto independiente a
Solaris 9 ahora se incorpora al Sun Patch Manager y permite una
gestión automática de los parches detectando los parches
necesarios y su aplicación.


Cómo trabajar con Boot Environments en Solaris - Parte 1
Introducción
Los boot environments son una característica que Solaris introdujo en la versión 8, es decir, hace ya mucho tiempo de aquello. Sin embargo, parece que esta característica pasa desapercibida entre muchos SysAdmin de Solaris y realmente es algo "vital" para nuestros sistemas de producción.

Como decía mi padre, "Los experimentos, con gaseosa", pues bien, los boot environments son lo más parecido a la gaseosa que tenemos en Solaris, ;)

Qué es un boot environment
Como su nombre indica, es un arranque completo y totalmente diferente. Esto, nos permite por ejemplo, parchear un sistema "OnLine" sin tener que detener sus servicios. Comprobar que todo está correcto e iniciar la máquina con el nuevo boot environment si todo está correcto.

De esta forma, pasamos de tener un tiempo de parada de X horas a el tiempo que tarde la máquina en iniciarse -mucho menos que X, por supuesto- y lo más importante, tenemos un proceso de "rollback" rápido y sencillo.

Cómo funcionan los boot environments
La gestión de los boot environments se realiza mediante el comando <beadm> el cual nos proporciona las siguientes opciones:
Ver todos los boot environments que tenemos disponibles
Activar/Desactivar boot environments
Crear/Destruir boot environments
Montar/Desmontar boot environments
Vamos a ver algunos ejemplos, y así entendemos esta utilidad tan potente.

Ver todos BE
Para ver todos los BE que disponemos en el sistema deberemos utilizar la opción <list> del comando <beadm>, por ejemplo:

havoc@h100:~$ pfexec beadm list
BE        Active Mountpoint Space   Policy Created         
--        ------ ---------- -----   ------ -------         
HSeries   -      /mnt       441.51M static 2013-03-07 23:57
solaris   -      -          3.06M   static 2011-04-16 04:06
solaris-1 NR     /          103.78G static 2011-04-16 04:41 

Los datos más importantes que vamos a ver en esta primera parte son los siguientes:
BE: Nombre único del boot
Active: Si es el boot activo, es decir, el que estamos ejecutando ahora mismo
MountPoint: Dónde esta montado -luego veremos para qué es interesante-
Space: El espacio que ocupa
Policy: El tipo de boot -lo veremos con más detalle en la segunda parte-
Crear un nuevo BE
Para crear un nuevo BE, deberemos utilizar la opción <create> con un nombre de BE nuevo y único -en nuestro caso se llama "PreUpdate"-

havoc@h100:~$ pfexec beadm create PreUpdate

Si ahora volvemos a ver todos los BE que existen en el sistema, veremos cómo hay uno nuevo.

havoc@h100:~$ pfexec beadm list
BE        Active Mountpoint Space   Policy Created         
--        ------ ---------- -----   ------ -------         
HSeries   -      /mnt       489.39M static 2013-03-07 23:57
PreUpdate -      -          122.0K  static 2013-03-08 10:15
solaris   -      -          3.06M   static 2011-04-16 04:06
solaris-1 NR     /          103.81G static 2011-04-16 04:41

Cuándo crear un nuevo BE
Lo cierto es que, tanto si tienes equipos de pruebas, como si no, siempre que quieras hacer algún cambio en los sistemas de producción, deberías comprobar que todo va a ir bien, por ejemplo, si queremos realizar las pruebas de una actualización que vamos a instalar, un nuevo parche, un nuevo paquete, etc.

Destruir un BE
Para destruir un BE deberemos tener en cuenta dos cosas importantes:
El BE no puede estar montado, es decir, el valor de Mountpoint debe ser "-"
El BE no puede ser el activo, es decir, el valor de Active debe ser "-"
 Si cumplimos con esas condiciones, simplemente deberemos utilizar la opción <destroy> y el nombre del BE a eliminar, en nuestro caso "PreUpdate"

havoc@h100:~$ pfexec beadm destroy PreUpdate
Are you sure you want to destroy PreUpdate?  This action cannot be undone(y/[n]): y

Comprobamos cómo lo ha destruido utilizando la opción <list> -como en casos anteriores-

havoc@h100:~$ pfexec beadm list
BE        Active Mountpoint Space   Policy Created         
--        ------ ---------- -----   ------ -------         
HSeries   -      /mnt       532.16M static 2013-03-07 23:57
solaris   -      -          3.06M   static 2011-04-16 04:06
solaris-1 NR     /          103.83G static 2011-04-16 04:41

NOTA: Aunque al destruir un BE se nos avisa, aunque no está de más que lo recordemos: Esta acción no puede deshacerse

Montar un BE en un directorio
Hasta ahora, no hemos hecho más que crear y destruir BE, sin embargo, en sí eso no aporta nada, verdad ...

Es hora de montar nuestro nuevo BE y poder trabajar con él, para ello, deberemos utilizar la opción <mount> seguida del <nombre> y del <path de montaje>.

En nuestro caso el BE será "PreUpdate" y el path de montaje será "/tmp/preupdate" -al igual que sucede con el comando <mount> el path de montaje deberá existir-

havoc@h100:~$ pfexec mkdir /tmp/preupdate
havoc@h100:~$ pfexec beadm create PreUpdate
havoc@h100:~$ pfexec beadm mount PreUpdate /tmp/preupdate
havoc@h100:~$ pfexec beadm list
BE        Active Mountpoint     Space   Policy Created         
--        ------ ----------     -----   ------ -------         
HSeries   -      /mnt           546.31M static 2013-03-07 23:57
PreUpdate -      /tmp/preupdate 122.0K  static 2013-03-08 10:28
solaris   -      -              3.06M   static 2011-04-16 04:06
solaris-1 NR     /              103.88G static 2011-04-16 04:41

 Si nos situamos en el path de nuestro nuevo BE -/tmp/preupdate- veremos que contiene la estructura idéntica a nuestro "sistema online", realmente, hemos realizado un "snapshoot" del sistema -entraremos en más detalle en la segunda parte-

havoc@h100:~$ cd /tmp/preupdate
havoc@h100:/tmp/preupdate$ ls
bin   cdrom  devices  export  kernel  media  net  platform  root   sbin  tmp  usr boot  dev    etc      home    lib     mnt    opt  proc  rpool  system  u01  var

Desmontar un BE
Para desmontar un BE simplemente deberemos utilizar la opción <umount> seguido del nombre del BE. Continuando con nuestro ejemplo,

havoc@h100:/$ pfexec beadm umount PreUpdate
havoc@h100:/$ pfexec beadm list
BE        Active Mountpoint Space   Policy Created          
--        ------ ---------- -----   ------ -------         
HSeries   -      /mnt       546.31M static 2013-03-07 23:57
PreUpdate -      -          144.0K  static 2013-03-08 10:28
solaris   -      -          3.06M   static 2011-04-16 04:06
solaris-1 NR     /          104.11G static 2011-04-16 04:41

Activar un BE
Una vez tenemos nuestro BE creado, podemos hacer que sea nuestro BE de arranque por defecto. Esto se llama "activar un BE". Para ello, utilizaremos la opción <activate> y el nombre del BE que queremos activar.

Continuando con nuestro ejemplo, queremos activar el BE "PreUpdate" para que la próxima vez que inicie el sistema sea con este BE.

havoc@h100:/$ pfexec beadm activate PreUpdate
havoc@h100:/$ pfexec beadm list
BE        Active Mountpoint Space   Policy Created         
--        ------ ---------- -----   ------ -------         
HSeries   -      /mnt       546.31M static 2013-03-07 23:57
PreUpdate R      -          103.83G static 2013-03-08 10:28
solaris   -      -          3.06M   static 2011-04-16 04:06
solaris-1 N      /          204.15M static 2011-04-16 04:41

Fijaros en el valor de "Active" que ahora nuestro BE "PreUpdate" tiene una "R" -de Root Boot-. La "N" que aparece en el BE "solaris-1" indica que es el "actual"

Para volver a ponerlo sobre el actual, simplemente activamos el BE que cuente con la opción "Active=N", por ejemplo:

havoc@h100:/$ pfexec beadm activate solaris-1
havoc@h100:/$ pfexec beadm list
BE        Active Mountpoint Space   Policy Created         
--        ------ ---------- -----   ------ -------         
HSeries   -      /mnt       546.31M static 2013-03-07 23:57
PreUpdate -      -          166.0K  static 2013-03-08 10:28
solaris   -      -          3.06M   static 2011-04-16 04:06
solaris-1 NR     /          104.21G static 2011-04-16 04:41




Cómo trabajar con Boot Environments en Solaris - Parte 2
Introducción
En la primera parte de Cómo trabajar con Boot Environments hacíamos una introducción a los comandos de gestión y su funcionamiento básico.

En esta segunda parte, vamos a aplicar lo que hemos aprendido en cuanto a la gestión de Boot Environments y cómo podemos utilizarlo en "un mundo real".

Si no recuerdas las opciones más importantes, te recomiendo hacer un pequeño repaso a la primera parte de Cómo trabajar con boot environments antes de entrar ya en materia.

Instalación de paquetes
Una de las características más interesantes de los Boot Environments es la capacidad de instalar paquetes -o parches- sin tener "downtime" en nuestro sistema principal.

Para ello, deberemos utilizar la opción "-R /punto_montaje" del comando <pkg>, es decir:

havoc@h100:~$ pfexec pkg -R /mnt <acción>

Un Ejemplo Completo
Como siempre, lo mejor es verlo con un ejemplo. Así que vamos a actualizar una versión de OpenIndiana b148 a la última versión utilizando la opción <image-update>

1.- Creamos y Montamos un Boot Environment Nuevo (PreUpdate)

havoc@h100:~$ pfexec mkdir /mnt/preupdate
havoc@h100:~$ pfexec beadm create PreUpdate
havoc@h100:~$ pfexec beadm mount PreUpdate /mnt/preupdate
havoc@h100:~$ pfexec beadm list
BE        Active Mountpoint     Space   Policy Created         
--        ------ ----------     -----   ------ -------         
PreUpdate -      /mnt/preupdate 122.0K  static 2013-03-08 10:28
solaris   -      -              3.06M   static 2011-04-16 04:06
solaris-1 NR     /              103.88G static 2011-04-16 04:41

2.- Actualizamos la distribución completamente utilizando "image-update"

havoc@h100:~$ pfexec pkg -R /mnt/preupdate image-update
                Packages to remove:    71
               Packages to install:   120
                Packages to update:   419
           Create boot environment:    No
               Services to restart:     6
DOWNLOAD                            PKGS       FILES    XFER (MB)
Completed                          610/610 20899/20899  325.4/325.4

PHASE                                        ACTIONS
Removal Phase                             9232/14882
Warning - directory /mnt/usr/share/man/cat1m not empty or not expected during operation - contents preserved in /mnt/var/pkg/lost+found/usr/share/man/cat1m-20130402T001646Z
Removal Phase                            14882/14882
Install Phase                            15359/15359
Update Phase                             12439/23150
Update Phase                             23150/23150

PHASE                                          ITEMS
Package State Update Phase                 1029/1029
Package Cache Update Phase                   490/490
Image State Update Phase                         2/2
------------------------------------------------------------------
NOTE: Please review release notes posted at:

http://docs.sun.com/doc/821-1479
------------------------------------------------------------------

3.- Comprobamos que todo se ha actualizado correctamente
Vamos a comprobar, por ejemplo, el paquete PostGreSQL9 que tenemos instalado en el Boot Environment actual y el actualizado (PreUpdate)

havoc@h100:~$ pfexec pkg info postgresql9
          Name: postgresql9
       Summary: PostgreSQL Database Server for OpenIndiana
         State: Installed
     Publisher: havoctec
       Version: 9.0.10
 Build Release: 5.11
        Branch: 0.148
Packaging Date: 25 de octubre de 2012 10:08:03
          Size: 41.04 MB
          FMRI: pkg://havoctec/postgresql9@9.0.10,5.11-0.148:20121025T100803Z
havoc@h100:~$ pfexec pkg -R /mnt/preupdate info postgresql9
          Name: postgresql9
       Summary: PostgreSQL Database Server for OpenIndiana
         State: Installed
     Publisher: havoctec
       Version: 9.0.12
 Build Release: 5.11
        Branch: 0.151
Packaging Date: 12 de febrero de 2013 11:00:46
          Size: 31.16 MB
          FMRI: pkg://havoctec/postgresql9@9.0.12,5.11-0.151:20130212T110046Z

4.- Forzar la reconfiguración.
Aunque este paso no es obligatorio, puede que nos encontremos con algún problema -como en este caso- de drivers que han cambiado y Solaris necesita reconfigurarse.

havoc@h100:~$ pfexec touch /mnt/preupdate/reconfigure

5.- Ciclo completo de boot iniciando con el nuevo Boot Enviroment
Este paso se puede realizar de dos formas (la segura y la rápida), aunque yo voy a centrarme en la más "segura" que requiere de un acceso físico a la consola para poder seleccionar el Boot Environment de forma "manual" en Grub (x86).

a) La más segura
Vamos a realizar un ciclo completo de boot, para ello utilizaremos la opción 6 del comando <init> o si lo preferís "apagar/encender".

havoc@h100:~$ pfexec init 6

Cuando se muestre la opción de arranque del Grub (x86) veremos una nueva entrada que será igual al nombre del Boot Environment que hemos definido, en nuestro caso "PreUpdate".

Seleccionamos ese entorno y comprobamos que todo funciona correctamente haciendo las pruebas necesarias para, finalmente, dejar como "activado" este nuevo entorno.

NOTA: Una vez comprobado que todo el proceso se realiza correctamente, a mí personalmente, me gusta tener el nombre del Boot Environment de una forma correcta, así que renombro el Boot Environment, pero, no es estríctamente necesario.

havoc@h100:/$ pfexec beadm activate PreUpdate
havoc@h100:~$ pfexec beadm list
BE        Active Mountpoint Space Policy Created
PreUpdate NR     /          141G  static 2013-03-07 23:57
solaris   -      -          3,06M static 2011-04-16 04:06
solaris-1 -      -          5,81G static 2011-04-16 04:41

b) En un sólo paso
Todo el proceso se puede realizar en un sólo paso. Suponiendo que hemos realizado varias pruebas de integración, y el proceso de actualización siempre ha sido correcto, podemos, por ejemplo, activar el nuevo Boot Environment y realizar un ciclo completo de boot, así:

havoc@h100:/$ pfexec beadm activate PreUpdate
havoc@h100:~$ pfexec init 6

6.- Actualizar el "zpool" (SOLO CUANDO ESTEMOS SEGUROS)
Por último, una vez comprobado que todo funciona correctamente  -y si me lo permitís, pasados unos días- ya sólo queda actualizar nuestro zpool, si fuese necesario, para comprobarlo, utilizaremos la opción <status> del comando <zpool>, por ejemplo así:

havoc@h100:~$ pfexec zpool status
  pool: rpool
 state: ONLINE
status: The pool is formatted using a legacy on-disk format.  The pool can still be used, but some features are unavailable.
action: Upgrade the pool using 'zpool upgrade'.  Once this is done, the pool will no longer be accessible on software that does not support feature flags.
  scan: resilvered 4,10G in 0h1m with 0 errors on Sat Apr 16 13:30:56 2011
config:

        NAME        STATE     READ WRITE CKSUM
        rpool       ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            c2d0s0  ONLINE       0     0     0
            c3d1s0  ONLINE       0     0     0

errors: No known data errors

¿Y qué hago si falla?
Esta pregunta tiene una solución sencilla:
"activar el Boot Environment anterior y reiniciar"
El proceso de "rollback" es tan sencillo como volver a iniciar con el Boot Environment que funcionaba correctamente, para ello, tenemos tres escenarios:

a) Nuestro sistema arranca hasta level 3.
En este caso, simplemente activaremos el boot environment anterior utlizando el comando

havoc@h100:/$ pfexec beadm activate <NombreAnteriorBoot>

b) Nuestro sistema no arranca.
Este caso suele ser más problemático porque necesitamos acceso a la consola, e iniciar el sistema en Single Mode y activar el Boot Environment anterior.

c) Nuestro sistema no arranca y hemos actualizado la versión de zpool
Este es un escenario un poco "raro", ya que por algún motivo, hemos certificado que el nuevo Boot Environment era correcto, hemos actualizado la versión del zpool y ahora queremos "echarlo para atrás".

La solución sencilla, pasaría por iniciar desde un CDROM -o similar- una versión de Solaris "compatible" con esa versión de zpool, reparar lo que falle y volver a iniciar.

Conclusiones
Hemos visto en estas dos partes cómo utilizar los Boot Environments para actualizar nuestros equipos Solaris a versiones nuevas, o para hacer experimentos con un "rollback" sencillo.

Hay que decir que en función de lo que queramos actualizar, deberemos realizar más o menos tareas, por ejemplo, si queremos actualizar PostgreSQL y no queremos bajar la base de datos, tendremos que tirar de WAL ... pero eso es otro post.

Cómo saber la versión de Solaris Instalada
Introducción
Para saber la versión de Solaris que tenemos instalada, basta con hacer un cat al archivo release que se encuentra en etc
# cat /etc/release
Solaris 10 5/09 s10s_u7wos_08 SPARC
Copyright 2009 Sun Microsystems, Inc. All Rights Reserved.
Use is subject to license terms.
Assembled 30 March 2009
Como podemos ver, la versión instalada es Solaris 10u7 sobre SPARC


Cómo cambiar el planificador por defecto en Solaris

Para establecer el planificador FSS por defecto en Solaris, ejecutaremos en la zona global y reiniciaremos para que tenga efecto.
# dispadmin -d FSS
Y para saber cuántos tipos de planificadores hay, simplemente ejecutaremos
# dispadmin -l
CONFIGURED CLASSES
==================

SYS (System Class)
TS (Time Sharing)
FSS (Fair Share)
RT (Real Time)
FX (Fixed Priority)
IA (Interactive)


Cómo sincronizar el reloj mediante NTP en Solaris
Para hacer que el reloj de Solaris se sincronice automáticamente, simplemente crearemos un archivo en /etc/inet/ntp.conf con la IP/host del que queremos se actualice
# echo "server hora.rediris.es" > /etc/inet/ntp.conf
# svcadm enable svc:/network/ntp
Cómo saber cuántas CPU hay instaladas en Solaris
Para saber el número de procesadores y tipo instalados en una máquina con Solaris, utilizaremos el comando psrinfo
# /usr/sbin/psrinfo
0 en línea desde 08/03/2009 14:17:57
1 en línea desde 08/04/2009 11:59:19
Y si quisiera saber el tipo de CPU que tenemos instalado, simplemente añadiremos la opción -v
# /usr/sbin/psrinfo -v
Estado del procesador virtual 0 a: 08/07/2009 14:06:03
en línea desde 08/03/2009 14:17:57.
El procesador sparcv9 funciona a 900 MHz,
y tiene un procesador de coma flotante sparcv9 .
Estado del procesador virtual 1 a: 08/07/2009 14:06:03
en línea desde 08/04/2009 11:59:19.
El procesador sparcv9 funciona a 900 MHz,
y tiene un procesador de coma flotante sparcv9 .


Sin embargo, si queremos saber cuántas CPU Físcas tenemos, utilizaremos la opción -p del comando psrinfo
# psrinfo
0 en lí­nea desde 08/29/2009 05:20:41
1 en lí­nea desde 08/29/2009 05:20:42
2 en lí­nea desde 08/29/2009 05:20:42
3 en lí­nea desde 08/29/2009 05:20:42
8 en lí­nea desde 08/29/2009 05:20:42
9 en lí­nea desde 08/29/2009 05:20:42
10 en lí­nea desde 08/29/2009 05:20:42
11 en lí­nea desde 08/29/2009 05:20:42
# psrinfo -pv
El procesador físico dispone de 4 virtuales virtuales (0-3)
SPARC64-VI (portid 1024 impl 0x6 ver 0x93 clock 2150 MHz)
El procesador físico dispone de 4 virtuales virtuales (8-11)
SPARC64-VI (portid 1032 impl 0x6 ver 0x93 clock 2150 MHz)


Cómo desactivar/activar una CPU en Solaris
Puede que nos interese poner en offline una cpu bien porque está fallando, o porque queremos experimentar el comportamiento con una cpu menos, para ello utilizaremos el comando /usr/sbin/psradm como se muestra a continuación
# psrinfo
0 en línea desde 08/03/2009 14:17:57
1 en línea desde 08/04/2009 11:59:19
# psradm -f 1
# psrinfo
0 en línea desde 08/03/2009 14:17:57
1 fuera de línea desde 08/07/2009 14:08:06
Y para activar la cpu haremos la llamada con el argumento -n y el número de cpu que queremos activar
# psradm -n 1
# psrinfo
0 en línea desde 08/03/2009 14:17:57
1 en línea desde 08/07/2009 14:11:17
Nota Importante:
No desactivéis una cpu con Oracle SE en una Zona con Solaris 10, existe un bug que nos permite añadir cpus pero no eliminar cpus, esto hará que Oracle se caiga.


Cómo saber si Solaris está paginando
Introducción
Solaris tiene una gestión de la swap realmente avanzada, tanto, que hay veces que es muy dificil saber cuándo un proceso está swapeando y cuando no. Vamos a utilizar los comandos /usr/bin/vmstat y /usr/bin/iostat los cuales nos aportan información sobre el uso de la swap y discos.

Uso del comando vmstat
Este comando nos proporciona las estadísticas de uso de la memoria virtual de Solaris, en él, nos fijaremos en las columnas SwapIn - SwapOut (si,so) y PageIn - PageOut (pi,po). El problema es, a veces, no saber qué buscar, bien, vamos a ver si podemos aclararlo.

Si los valores de si o so no son 0, realmente tenemos un servidor muy cargado y swapeando (tal como entendemos todos, es decir, escribiendo en disco porque no le queda RAM), sin embargo, si estos valores son "0" (con en el ejemplo) lo siguiente que debemos mirar es el estado de pi y po. Estos valore indican las páginas que se han cargado (PageIn) y las que se han eliminado (PageOut), pero debemos tener en cuenta que est no significa que se utice espacio swap de disco para ello.

Vamos a verlo con el siguiente ejemplo, utilizaremos la opción -S para que vmstat nos muestre los valores de swap en un intervalo de 6 seg. (No hay que utilizar un valor menor de 5 ya que sino el propio comando interferirá en los resultados)
# vmstat -S 6
kthr memory page disk faults cpu
r b w swap free si so pi po fr de sr rm s6 sd sd in sy cs us sy id
0 0 0 6475424 838488 0 0 847 27 28 0 8 -0 -0 -0 -0 1441 1487 580 22 4 74
0 0 0 5541664 494480 0 0 536 0 0 0 0 0 0 0 0 2057 2599 1017 62 10 28
2 0 0 5534672 489152 0 0 389 1 1 0 0 0 0 0 0 1439 3772 876 67 9 25
0 0 0 5534248 489024 0 0 1047 0 0 0 0 0 0 0 0 1960 1945 1078 50 5 45
0 0 0 5534424 488872 0 0 342 0 0 0 0 0 0 0 0 2361 1742 1154 54 5 40
0 0 0 5538232 491632 0 0 361 0 0 0 0 0 0 0 0 1921 2148 1015 65 5 30
1 0 0 5545752 498264 0 0 351 0 0 0 0 0 0 0 0 3855 27594 1553 73 11 16
0 0 0 5550552 502264 0 0 769 1 1 0 0 0 0 0 0 3387 18331 1550 70 10 20
Como podemos ver, los valores de si y so están a cero, sin embargo, el sistema está cargando continuamente páginas en memoria. Con el uso de iostat podremos ir afinando si nuestro sistema está o no realmente paginando en disco.

A continuación podemos ver un host que no tiene problemas de memoria ya que los valores de free, si,so,pi y po son constantes.
$ vmstat -S 6
kthr memory page disk faults cpu
r b w swap free si so pi po fr de sr s0 s2 s4 sd in sy cs us sy id
0 0 0 11655392 2971784 0 0 2408 4 5 0 1 1 0 -0 163 2077 24269 2186 22 2 76
0 0 0 15870360 5630928 0 0 0 0 0 0 0 0 0 0 1044 3554 5886 3391 14 1 84
0 1 0 15865784 5626720 0 0 0 0 0 0 0 0 0 0 907 3367 10856 3295 18 1 81
0 1 0 15868640 5631256 0 0 0 0 0 0 0 0 0 0 934 3169 12233 3068 18 1 80
0 0 0 15871672 5634888 0 0 0 1 1 0 0 0 0 0 699 2855 10245 2876 15 1 83
0 0 0 15870600 5633928 0 0 0 0 0 0 0 0 0 0 1782 4977 6176 4957 16 2 82
0 0 0 15873832 5636952 0 0 0 0 0 0 0 0 0 0 1882 4608 4920 4869 17 2 82
0 0 0 15856600 5621712 0 0 0 0 0 0 0 0 0 0 123 2385 11685 2360 24 2 74
0 1 0 15868976 5631416 0 0 0 0 0 0 0 0 0 0 129 1897 36965 1819 26 2 73
0 0 0 15890056 5648016 0 0 23 1 1 0 0 0 0 0 61 1886 35675 1861 29 2 69
Uso del comando iostat
Vamos a utiliza el comando iostat el cual nos proporciona el uso de los discos, limitándonos a aquellos que se encuentren asignados a nuestro área de swap, de esta forma, podremos verificar si nuesto equipo está realmente utilizándolos
# swap -l
swapfile dev swaplo bloques libre
/dev/dsk/c5t20000004CF8F7B64d0s1 118,1489 16 8389632 7261120
/dev/dsk/c5t20000004CF7FE30Ed0s1 118,1497 16 8389632 7265360

# iostat -xnPzm 6
extended device statistics
r/s w/s kr/s kw/s wait actv wsvc_t asvc_t %w %b device
0.5 0.6 5.0 0.6 0.0 0.0 0.7 16.4 0 0 c5t20000004CF8F7B64d0s0 (/)
0.1 0.0 0.7 1.3 0.0 0.0 7.8 9.3 0 0 c5t20000004CF8F7B64d0s1
0.1 0.3 6.9 17.4 0.0 0.0 4.2 23.9 0 0 c5t20000004CF7FE30Ed0s0 (/opt/zones)
0.1 0.0 0.7 1.3 0.0 0.0 7.6 8.5 0 0 c5t20000004CF7FE30Ed0s1
0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.3 0 0 c5t600A0B80002AF618000007A94A710D33d0s0
0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.3 0 0 c5t600A0B80002AF618000007A94A710D33d0s1
0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.4 0 0 c5t600A0B80002AF618000007A94A710D33d0s2
0.0 0.1 15.1 73.3 0.0 0.0 16.0 80.8 0 0 c5t600A0B80002AF618000007A94A710D33d0s6
0.4 1.1 8.1 39.3 0.0 0.0 0.0 3.3 0 0 c5t600A0B80002AF618000007A74A70F3ACd0s6
4.4 2.4 126.8 59.9 0.0 0.0 0.0 5.3 0 2 c5t600A0B80002AF618000007A54A70F35Fd0s6
0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.1 0 0 sol10-oracle-applications:vold(pid491)
extended device statistics
r/s w/s kr/s kw/s wait actv wsvc_t asvc_t %w %b device
5.6 0.2 46.4 0.5 0.0 0.1 1.7 9.5 1 5 c5t20000004CF8F7B64d0s0 (/)
2.4 8.2 19.1 1039.9 0.3 0.5 28.7 47.7 2 5 c5t20000004CF8F7B64d0s1
0.0 0.2 0.0 2.9 0.0 0.0 0.0 7.0 0 0 c5t20000004CF7FE30Ed0s0 (/opt/zones)
0.9 7.8 6.8 974.4 0.3 0.4 30.3 49.6 2 4 c5t20000004CF7FE30Ed0s1
0.9 22.5 6.8 5528.8 0.0 1.2 0.0 50.0 0 98 c5t600A0B80002AF618000007A94A710D33d0s6
0.0 1.9 0.0 350.4 0.0 0.1 0.0 37.7 0 7 c5t600A0B80002AF618000007A74A70F3ACd0s6
55.6 13.3 1266.3 372.3 0.0 2.2 0.0 32.0 0 97 c5t600A0B80002AF618000007A54A70F35Fd0s6
extended device statistics
r/s w/s kr/s kw/s wait actv wsvc_t asvc_t %w %b device
3.5 0.0 39.3 0.0 0.0 0.0 0.0 6.9 0 2 c5t20000004CF8F7B64d0s0 (/)
1.5 2.7 12.0 338.7 0.0 0.1 0.1 29.4 0 2 c5t20000004CF8F7B64d0s1
0.2 2.7 1.3 338.7 0.0 0.1 0.0 38.0 0 2 c5t20000004CF7FE30Ed0s1
0.3 27.2 2.7 4387.7 0.0 1.1 0.0 39.8 0 99 c5t600A0B80002AF618000007A94A710D33d0s6
0.2 3.7 2.7 356.2 0.0 0.1 0.0 17.6 0 7 c5t600A0B80002AF618000007A74A70F3ACd0s6
47.0 3.2 841.6 236.9 0.0 2.9 0.0 57.3 0 100 c5t600A0B80002AF618000007A54A70F35Fd0s6

Asi que ..., sí, está swapeando y mucho ... ahora toca parametrizar correctamente nuestro Oracle

Conclusión
Para comprobar el correcto funcionamiento de nuestro sistema deberemos utilizar los comandos vmstat, iostat y sar


Cómo ejecutar un proceso con un project diferente en Solaris
Puede que nos interese ejecutar algún comando con un project diferente, para ello, utilizaremos el comando /usr/bin/newtask con las opciones -p project comando.
$ id -p
uid=2011(oracle) gid=2010(dba) projid=100(group.dba)
$ newtask -p oracle.hestia ps -o project,args
PROJECT COMMAND
oracle.hestia ps -o project,args
Y si queremos, podemos utilizar esta forma si vamos a lanzar varios procesos
$ id -p
uid=2011(oracle) gid=2010(dba) projid=100(group.dba)
$ newtask -p oracle.hestia
$ id -p
uid=2011(oracle) gid=2010(dba) projid=102(oracle.hestia)
$ ps -o project,args
PROJECT COMMAND
oracle.hermes bash
oracle.hestia ps -o project,args
group.dba -bash
$ exit
exit
$ id -p
uid=2011(oracle) gid=2010(dba) projid=100(group.dba)
Debemos tener en cuenta que el usuario debe pertenecer al projecto, sino nos mostrará el siguiente error.
$ newtask -p system ps
newtask: user "oracle" is not a member of project "system".


Cómo activar los interfaces de red sin saber cómo se llaman en Solaris
Podemos encontrarnos con una instalación de Solaris que necesitemos activar un interface de Red que, o bien previamente hemos desactivado o no lo activamos por defecto, sin embargo, no sabemos cómo se llama. Puede ser eri, em, ce, ... para ello, podemos utilizar el siguiente comando para que active todos los interfaces que reconoce el sistema.
# ifconfig -a plumb

Cómo cambiar el project de un proceso en Solaris
Introducción
Puede que necesitemos cambiar el project asignado a un proceso en Solaris, para ello, utilizaremos el comando /usr/bin/newtask -p project-name -c pid

Por ejemplo, vamos a cambiar el daemon sshd del project system a user.root

# ps -ef -o user,group,pid,args,project|grep sshd
root root 16839 /usr/lib/ssh/sshd system
# newtask -p user.root -c 16839
# ps -ef -o user,group,pid,args,project|grep sshd
root root 16839 /usr/lib/ssh/sshd user.root


Cómo saber cuál es el project actual
Para saber cuál es el project que tenemos asignado en nuestro proceso, utilizaremos el comando /usr/bin/id con la opción -p
$ id -p
uid=2011(oracle) gid=2010(dba) projid=100(group.dba)
Cómo saber si Solaris soporta binarios de 64 bits
Para comprobar si nuestra instalación de Solaris soporta binarios de 64bits utilizaremos el siguiente comando:
# /usr/bin/isainfo -v
64-bit amd64 applications
sse3 sse2 sse fxsr mmx cmov amd_sysc cx8 tsc fpu
32-bit i386 applications
ahf sse3 sse2 sse fxsr mmx cmov sep cx8 tsc fpu
Y si fuese SPARC
$ /usr/bin/isainfo -v
64-bit sparcv9 applications
vis2 vis
32-bit sparc applications
vis2 vis v8plus div32 mul32


Cómo saber cuánta memoria hay instalada en Solaris
Para saber la memoria que tenemos instalada en nuestra máquina, simplemente llamaremos a prtconf buscando Memory
# /usr/sbin/prtconf |grep Mem
Memory size: 4096 Megabytes


Cómo reconfigurar el kernel de Solaris 10
Cuando instalamos un nuevo device puede que necesitemos reiniciar nuestro solaris para que busque cambios y actualice el kernel con los nuevos dispositivos, para ello podemos los siguiente métodos

SPARC y x86
# touch /reconfigure
# shutdown -g 30 -i 6 -y
SPARC
# reboot -- -r


Cómo configurar cliente DHCP en Solaris
Introducción
Para configurar un interface de red mediante DHCP en Solaris, utilizaremos el comando ifconfig como veremos a continuación. En nuestro ejemplo, vamos a habilitar nuestro interface e1000g0
# ifconfig e1000g0 plumb
# ifconfig e1000g0 dhcp start
Si queremos que se nos configure nuestro interface cada vez que iniciemos nuestro sistema, debemos crear un archivo /etc/dhcp._interface_
# touch /etc/dhcp.e1000g0
Si por el contrario queremos el estado de nuestra concesión, utilizaremos el argumento status de la siguiente forma.
# ifconfig e1000g0 dhcp status


Cómo registrar los login fallidos en Solaris
Introducción
Por defecto, Solaris muestra en la consola los intentos de error fallidos al sistema, así como los accesos de root, sin embargo, no los guarda en un log.

Para activar esta función, simplemente debemos crear el archivo /var/adm/loginlog, entonces Solaris registrará los intentos fallidos a partir del quinto (5)

Es importante crear el archivo con los permisos -rw- -- -- root:sys para que el sistema de log funcione correctamente, veamos un ejemplo
# touch /var/adm/loginlog
# chmod 600 /var/adm/loginlog
# chown root:sys /var/adm/loginlog


Cómo Registrar los Accesos de SSH en Solaris
Introducción
En Solaris, por defecto, los registros de intentos de acceso mediante SSH no quedan registrados. Para poder registrarlos debemos modificar el valor de la variable de configuración <auth.notice> de <syslog>.

Para ello, editaremos el archivo de configuración /etc/syslog.conf y descomentaremos la entrada <auth.notice>
# vi /etc/syslog.conf
    auth.notice                    ifdef(`LOGHOST', /var/log/authlog, @loghost)
    # si queremos todos los niveles
   #auth.notice;auth.info;auth.debug                ifdef(`LOGHOST', /var/log/authlog, @loghost)
Una vez modificado, debemos recargar la configuración de nuestro syslogd de la siguiente forma
# pkill -HUP syslogd
Podemos consultar los intentos de accesos en el archivo</var/log/authlog> utilizando -por ejemplo- el comando <tail> o si queremos algo más avanzado LogWatch.








Cómo ver un Calendario desde línea de comandos en Solaris 10
Introducción
Puede que alguna vez necesitemos ver el calendario -no sólo la fecha actual- y, no tengamos uno a mano. Para ello, podemos contar con el comando <cal>. Su formato es el siguiente
cal [ [mes] [año]]
Cal utiliza la variable de entorno <LC_ALL> y <LC_MESSAGES> para formatear la salida en uno y otro idioma, además, si ejecutamos el comando sin opciones, nos mostrará el calendario del mes actual
$ export LC_ALL=es.UTF-8
$ cal
   abril 2010
Do Lu Ma Mi Ju Vi Sa
             1  2  3
 4  5  6  7  8  9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30


$ export LC_ALL=en.UTF-8
$ cal

   April 2010
 S  M Tu  W Th  F  S
             1  2  3
 4  5  6  7  8  9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30
Si queremos ver el calendario del año 2010, simplemente ejecutaremos el siguiente comando -he tenido que ajustar las fuentes para que se refleje el resultado de salida del comando en Solaris-
$ cal 2010
                                2010

         ene                    feb                    mar
Do Lu Ma Mi Ju Vi Sa   Do Lu Ma Mi Ju Vi Sa   Do Lu Ma Mi Ju Vi Sa
                1  2       1  2  3  4  5  6       1  2  3  4  5  6
 3  4  5  6  7  8  9    7  8  9 10 11 12 13    7  8  9 10 11 12 13
10 11 12 13 14 15 16   14 15 16 17 18 19 20   14 15 16 17 18 19 20
17 18 19 20 21 22 23   21 22 23 24 25 26 27   21 22 23 24 25 26 27
24 25 26 27 28 29 30   28                     28 29 30 31
31
         abr                    may                    jun
Do Lu Ma Mi Ju Vi Sa   Do Lu Ma Mi Ju Vi Sa   Do Lu Ma Mi Ju Vi Sa
             1  2  3                      1          1  2  3  4  5
 4  5  6  7  8  9 10    2  3  4  5  6  7  8    6  7  8  9 10 11 12
11 12 13 14 15 16 17    9 10 11 12 13 14 15   13 14 15 16 17 18 19
18 19 20 21 22 23 24   16 17 18 19 20 21 22   20 21 22 23 24 25 26
25 26 27 28 29 30      23 24 25 26 27 28 29   27 28 29 30
                       30 31
         jul                    ago                    sep
Do Lu Ma Mi Ju Vi Sa   Do Lu Ma Mi Ju Vi Sa   Do Lu Ma Mi Ju Vi Sa
             1  2  3    1  2  3  4  5  6  7             1  2  3  4
 4  5  6  7  8  9 10    8  9 10 11 12 13 14    5  6  7  8  9 10 11
11 12 13 14 15 16 17   15 16 17 18 19 20 21   12 13 14 15 16 17 18
18 19 20 21 22 23 24   22 23 24 25 26 27 28   19 20 21 22 23 24 25
25 26 27 28 29 30 31   29 30 31               26 27 28 29 30

         oct                    nov                    dic
Do Lu Ma Mi Ju Vi Sa   Do Lu Ma Mi Ju Vi Sa   Do Lu Ma Mi Ju Vi Sa
                1  2       1  2  3  4  5  6             1  2  3  4
 3  4  5  6  7  8  9    7  8  9 10 11 12 13    5  6  7  8  9 10 11
10 11 12 13 14 15 16   14 15 16 17 18 19 20   12 13 14 15 16 17 18
17 18 19 20 21 22 23   21 22 23 24 25 26 27   19 20 21 22 23 24 25
24 25 26 27 28 29 30   28 29 30               26 27 28 29 30 31
31


Y si quiero ver el mes de Mayo de 2008, por ejemplo,
cal 5 2008
   mayo 2008
Do Lu Ma Mi Ju Vi Sa
             1  2  3
 4  5  6  7  8  9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31


Cómo crear un Banner/Poster desde linea de comandos
Introducción
Para crear banner -o poster- desde línea de comandos para hacer más interesantes nuestros mensajes de </etc/motd> o </etc/issue> utilizaremos el comando <banner _texto_>. El tamaño máximo de nuestro <texto> es de 10 caracteres por línea
banner Hola
#     #
#     #   ####   #         ##
#     #  #    #  #        #  #
#######  #    #  #       #    #
#     #  #    #  #       ######
#     #  #    #  #       #    #
#     #   ####   ######  #    #

Por ejemplo, podemos utilizarlo para crear nuestro Banner de acceso de SSH, FTP, etc
banner SFChildren >> /etc/issue



Cómo ver la tabla de enrutado en Solaris 10
Introducción
Para poder ver la tabla de rutas activa utilizaremos el comando <netstat> con la opción <-r>

root@http:~# netstat -r

Routing Table: IPv4
  Destination           Gateway           Flags  Ref     Use     Interface
-------------------- -------------------- ----- ----- ---------- ---------
localhost            localhost            UH        2          0 lo0
172.26.0.0           http                 U         3         39 e1000g0
192.168.20.0         172.26.17.2          UG        2         39

Routing Table: IPv6
  Destination/Mask            Gateway                   Flags Ref   Use    If
--------------------------- --------------------------- ----- --- ------- -----
localhost                   localhost                   UH      2       0 lo0

Sin embargo, si queremos que no nos resuelva las IPs y nos muestre los valores -no los DNS-, añadiremos la opción <-n>, así
root@http:~# netstat -rn

Routing Table: IPv4
  Destination           Gateway           Flags  Ref     Use     Interface
-------------------- -------------------- ----- ----- ---------- ---------
127.0.0.1            127.0.0.1            UH        2          0 lo0
172.26.0.0           172.26.17.1          U         3         41 e1000g0
192.168.20.0         172.26.17.2          UG        2         41

Routing Table: IPv6
  Destination/Mask            Gateway                   Flags Ref   Use    If
--------------------------- --------------------------- ----- --- ------- -----
::1                         ::1                         UH      2       0 lo0



Crear un archivo de un tamaño en concreto
Introducción
Muchas veces para poder realizar pruebas de rendimiento necesitamos tener archivo con tamaños concretos, por ejemplo para medir la latencia de nuestros servidores Apache HTTP con JMeter.

Para ello, podemos utilizar varios comandos, aunque yo principalmente utilizo dos: <dd> y <mkfile>.

Vamos a crear un archivo de <8Mb> utilizando primero <dd> y luego <mkfile>. El formato del comando <dd> es el siguiente:
dd if={device_origen} of={destino} bs={tamaño de bloque} count={número de veces}
Por lo tanto, si queremos crear un archivo de 8Mb, podemos tener un BlockSize (bs) de 8k y realizar la operación 1024 veces. Vamos a utilizar el device </dev/zero> que nos va a crear un archivo lleno de "ceros".

# time dd if=/dev/zero of=test.dd bs=8k count=1024
1024+0 registros dentro
1024+0 registros fuera

real    0m0.082s
user    0m0.006s
sys     0m0.043s
Pero si queremos que esté lleno de contenido variable podemos utilizar el device </dev/random> para que nos generes secuencias pseudo aleatorias, por ejemplo,
# time dd if=/dev/random of=test.dd_random count=1024
0+1024 registros dentro
0+1024 registros fuera

real    1m52.687s
user    0m0.012s
sys     1m50.498s

Podemos comprobar con un visor octal <od> como al crear el archivo con el device </dev/zero> está lleno de ceros -como es lógico- pero, cuando hacemos lo mismo con el archivo creado utilizando el device </dev/radom> nos ha creado un archivo completamente distinto.

Esto será muy importante cuando utilicemos servicios de compresión -por ejemplo mod_gzip, mod_defalte- ya que comprimirá prácticamente al 99% el archivo creado con </dev/zero> haciéndonos creer que el rendimiento será muy superior al real.

# od -c test.dd
0000000  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
*
40000000
# od -c test.ddrandom |head -3
0000000 017 260   Ò   -   ;   Р  à  ¿   x   N   < 230   ü 217   a   e
0000020   O   æ 254       k   û   ö   c   4   û 257   -   à  {   þ 271
0000040   Æ   Ù   l 243   Ü   ê   å   å   ] 217   f   >   l   C   É   q
Y si comprimimos los archivos utilizando <gzip> y su máxima compresión <-9>, veremos lo que os he comentado,
# ls -l
total 2048
-rw-r--r--   1 root     root      524288 may 20 11:42 test.dd
-rw-r--r--   1 root     root      524288 may 20 11:13 test.ddrandom
# gzip -9 test.ddrandom
# gzip -9 test.dd
# ls -l
total 1056
-rw-r--r--   1 root     root         551 may 20 11:42 test.dd.gz
-rw-r--r--   1 root     root      524400 may 20 11:13 test.ddrandom.gz
Como vemos, el archivo que hemos creado utilizando <dd if=/dev/zero> comprimido tiene un tamaño de 551 bytes y el creado con <dd if=/dev/random> no solo no ha sido comprimido, sino que ha aumentado de tamaño -por las cabeceras de GZIP-

Por el contrario, si no tenemos intención de utilizar sistemas de compresión, o queremos hacer métricas de uso de disco, podemos utilizar el comando <mkfile> con el siguiente formato
mkfile {tamaño}{unidad} {nombre archivo}
Donde unidad será k para Kb, m para Mb. Por ejemplo, para crear el mismo archivo de 8Mb, utilizaremos el siguiente comando.
# time mkfile 8m test.mkfile

real    0m0.049s
user    0m0.003s
sys     0m0.037s
# od -c test.mkfile
0000000  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
*
40000000
Como vemos, <mkfile> genera un archivo utilizando como device </dev/zero> al igual que <dd> pero de una forma más sencilla.



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:
# 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








Cómo Montar ISO en Solaris
Introducción
En Solaris disponemos de un comando para administrar archivos como dispositivos de bloques, este comando es <lofiadm> y nos va a permitir montar un archivo ISO como un dispositivo de bloques y poder montarlo.

Para ello, simplemente ejecutaremos <lofiadm> con la opción <-a> y posteriormente, montarlo con normalidad
# lofiadm -a /custom/sfchildren.iso
/dev/lofi/1
# mount -F hsfs -o ro /dev/lofi/1 /mnt
Y para finalizar, simplemente desmontaremos la unidad montada y eliminaremos el dispositivo loopback que hemos creado "/dev/lofi/1"
# umount /mnt
# lofiadm -d /dev/lofi/1
Si intentamos hacerlo dentro de una zona no global, Solaris nos mostrará el siguiente mensaje de error
# lofiadm -a /custom/sfchildren.iso
lofiadm: /dev/lofictl: No existe tal archivo o directorio



Activar Salida por Consola Serie en OpenIndiana/Solaris 10
Introducción
Si queremos hacer que nuestro OpenIndiana/Solaris utilice nuestro puerto serie como salida en vez de la tarjeta gráfica, por ejemplo en servidores, simplemente deberemos incluir la opción "console=ttya" en nuestra entrada "kernel" del archivo <menu.lst> de GRUB.

Debemos recordar que si tenemos ZFS como sistema de archivos, el archivo <menu.lst> se encontrará en <POOL/boot/grub>, por ejemplo, en mi caso el nombre del POOL es "rpool".
root@h100:/rpool/boot/grub# zpool status
  pool: rpool
 state: ONLINE
 scan: resilvered 4,10G in 0h1m with 0 errors on Sat Apr 16 13:30:56 2011
config:

        NAME        STATE     READ WRITE CKSUM
        rpool       ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            c2d0s0  ONLINE       0     0     0
            c3d1s0  ONLINE       0     0     0

errors: No known data errors
Editaremos el archivo "menu.lst", e incluiremos la opción "console=ttya" teniendo en cuenta que debemos incluir un "," para separar la opción.
root@h100:/# vi /rpool/boot/grub/menu.lst
 title ASEngine Enterprise Platform
 findroot (pool_rpool,0,a)
 bootfs rpool/ROOT/solaris-1
 kernel$ /platform/i86pc/kernel/$ISADIR/unix -B $ZFS-BOOTFS,console=ttya
 module$ /platform/i86pc/$ISADIR/boot_archive
:wq

Ahora, la próxima vez que iniciemos nuestro OpenIndiana, la salida se producirá por nuestro puerto de serie 1 -ttya- y, por lo tanto, podremos acceder con nuestro programa favorito, por ejemplo <minicom