Manual Solaris

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:

https://www.youtube.com/watch?v=9l0MQCHzWyA&feature=youtu.be

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

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

Manual Solaris

jueves, 30 de octubre de 2014

No hay comentarios:

Publicar un comentario