Este es el texto que se va a utilizar para trabajar como ejemplo. Sí, es un fichero de configuración de un Cluster MySQL de prueba, pero es que no tenía otra cosa a mano y no me apetecía preparar un fichero específicamente para esto ;)

[ndb_mgmd]
hostname=192.168.0.10           # Hostname or IP address of management node
datadir=/var/lib/mysql-cluster  # Directory for management node log files

# Options for data node "A":
[ndbd]
                                # (one [ndbd] section per data node)
hostname=192.168.0.30           # Hostname or IP address
datadir=/usr/local/mysql/data   # Directory for this data node's data files

# Options for data node "B":
[ndbd]
hostname=192.168.0.40           # Hostname or IP address
datadir=/usr/local/mysql/data   # Directory for this data node's data files

# SQL node options:
[mysqld]
hostname=192.168.0.20           # Hostname or IP address
                                # (additional mysqld connections can be
                                # specified for this node for various
                                # purposes such as running ndb_restore)

Buscar dos ó n strings distintas dentro de un mismo fichero

La sintaxis es ‘(cadena1|cadena2|cadenaN)’. La salida será todas aquellas líneas que contienen cualquiera de esas strings. Esto nos permite hacer múltiples búsquedas en un único comando:

$ egrep '(192.168.0.30|192.168.0.40)' test
hostname=192.168.0.30           # Hostname or IP address
hostname=192.168.0.40           # Hostname or IP address

$ egrep '(192.168.0.30|192.168.0.40|192.168.0.20)' test
hostname=192.168.0.30           # Hostname or IP address
hostname=192.168.0.40           # Hostname or IP address
hostname=192.168.0.20           # Hostname or IP address

Usar los corchetes para reducir el rango de búsqueda

Podemos hacer uso de los corchetes [] para definir, dentro de una misma string, que una sección contenga únicamente X carácteres, un rango de ellos, etc.

En este caso queremos sacar únicamente los resultados que contengan 192.168.0.30 y 192.168.0.40:

$ egrep 192.168.0.[30,40] test
hostname=192.168.0.30           # Hostname or IP address
hostname=192.168.0.40           # Hostname or IP address

Pero si quisiéramos definir los rangos que queremos mostrar para los dos últimos caracteres, en este caso numéricos (se podría hacer con alfanuméricos) podemos hacerlo separando el valor inicial y el final con “-”. En este ejemplo queremos que nos muestre aquello que cumpla la condición de que el primer número del último bloque tiene que ser 0,1 ó 2:

$ egrep 192.168.0.[0-2]0 test
hostname=192.168.0.10           # Hostname or IP address of management node
hostname=192.168.0.20           # Hostname or IP address

Y en este que el primer número del último bloque sea 1,2 ó 3 y el último entre 0 y 9:

$ egrep 192.168.0.[0-3][0-9] test
hostname=192.168.0.10           # Hostname or IP address of management node
hostname=192.168.0.30           # Hostname or IP address
hostname=192.168.0.20           # Hostname or IP address

Un ejemplo práctico con caracteres alfanuméricos sería usar por ejemplo [a-c]test, que buscaría atest, btest y ctest ó por ejemplo [ar4d]test que buscaría atest, rtest, 4test y dtest.

Uso de clases predefinidas

Existen clases predefinidas que nos pueden llegar a ahorrar mucho trabajo. Son las siguientes:

[:alnum:], [:alpha:], [:cntrl:], [:digit:], [:graph:], [:lower:], [:print:], [:punct:], [:space:], [:upper:], [:xdigit:]

Lo que hace cada una de ellas está claro por su nombre, no obstante vamos a ver un ejemplo. Podemos buscar toda línea que contenga un carácter en mayúsculas:

$ egrep [[:upper:]] test
hostname=192.168.0.10           # Hostname or IP address of management node
datadir=/var/lib/mysql-cluster  # Directory for management node log files
...
...

Todo lo que comienza o termina por…

Esto es sencillo, las líneas comienzan por el carácter ^ y terminan con $. Por lo que:

Buscar todo lo que comience por “hostname”:

$ egrep ^hostname test
hostname=192.168.0.10           # Hostname or IP address of management node
hostname=192.168.0.30           # Hostname or IP address
hostname=192.168.0.40           # Hostname or IP address
hostname=192.168.0.20           # Hostname or IP address

O todo lo que termine por “node”:

$ egrep node$ test
hostname=192.168.0.10           # Hostname or IP address of management node

Más expresiones regulares

Ya hicimos un artículo sobre ello hace tiempo, podéis revisarlo aquí: unix: Expresiones regulares, ahí también encontraréis unos cuantos ejemplos de grep. Son muy útiles los operadores de repetición:

       ?      El carácter que precede es opcional y coincide al menos una vez.
       *      El carácter que precede coincidirá 0 o más veces.
       +      El carácter que precede coincidirá 1 o más veces.
       {n}    El carácter que precede coincidirá exactamente n veces.
       {n,}   El carácter que precede coincidirá n o más veces.
       {,m}   El carácter que precede coincidirá como máximo m veces.
       {n,m}  El carácter que precede coincidirá entre n y m veces.

Podemos entonces buscar todas las líneas del fichero que contienen una IP. Usamos primero los corchetes para definir que puede haber números del 0 al 9, con las llaves decimos que habrá 1 o 3 números en cada bloque y así cuatro veces (nota: hay que escapar las llaves):

$ grep '[0-9]\{1,3\}.[0-9]\{1,3\}.[0-9]\{1,3\}.[0-9]\{1,3\}' test
hostname=192.168.0.10           # Hostname or IP address of management node
hostname=192.168.0.30           # Hostname or IP address
hostname=192.168.0.40           # Hostname or IP address
hostname=192.168.0.20           # Hostname or IP address

Buscar palabras completas, contar resultados

Para indicar a grep que queremos que la búsqueda se centre en palabras y no en caracteres sueltos especificamos el parámetro “-w”. Podemos ver la diferencia buscando “data” en el ejemplo, contamos los resultados satisfactorios con el parámetro “-c”:

$ grep -cw data test
5
$ grep -c data test
6

Excluir resultados, sensibilidad a mayúsculas

Algo básico a la hora de usar grep es conocer los parámetros “-v” que excluye la cadena indicada en el resultado y “-i” que especifica que no se tendrá en cuenta si el resultado es mayúscula o minúscula.

Eliminamos las líneas que tienen comodines:

$ grep -v "#" test
[ndb_mgmd]

[ndbd]

[ndbd]

[mysqld]

Uso de pipes

Todos usamos pipes (|) para acotar resultados. Hacemos un primer grep, con el resultado de ese hacemos otro y así sucesivamente:

$ grep -iw hostname test | grep 192.168.0.[0-9]0 | grep -v 192.168.0.40 | grep -vw node
hostname=192.168.0.30           # Hostname or IP address
hostname=192.168.0.20           # Hostname or IP address

Listar los archivos que contienen la cadena

Con el parámetro -l podemos ejecutar grep contra varios archivos (y de forma recursiva en múltiples directorios con -R) y recibiremos el listado de archivos con coincidencias sin mostrar las líneas que contienen la cadena:

$ grep -lR SQL *
config.ini
header.xcf
iptables.sh
test
dir1/test.sql
dir2/prueba.txt
...

Número de línea en la que se encuentran los resultados

Para saber el número de línea en la que se encuentra el resultado utilizaremos el parámetro -n:

$ grep -n hostname test
2:hostname=192.168.0.10           # Hostname or IP address of management node
8:hostname=192.168.0.30           # Hostname or IP address
...

Cuantas veces se encuentran resultados

Si “-n” nos monstraba el nº de línea en el que estaba la coincidencia, “-c” nos dice cuantas veces está la búsqueda en el fichero:

$ grep -c hostname test
4

Bueno, de momento esto es todo. Por supuesto hay muchas más opciones y explotar la potencia de grep llevaría mucho tiempo así que a partir de aquí investigáis vosotros ;)

También te puede interesar:

• AWK: imprimir a partir de una expresión regular hasta el final del fichero
• Truco GREP: Mostrar líneas anteriores/posteriores al resultado de la búsqueda
• Truco shell Unix: quitar líneas en blanco de un fichero con grep
• Vim: Manual de expresiones regulares

¿Cómo averiguamos el UUID de una partición?

Hay varias formas: con el comando blkid, tune2fs… Vamos a localizar el UUID de la partición /dev/sda2:

# tune2fs -l /dev/sda2 | grep UUID
Filesystem UUID:          528c141b-66fd-43d5-808b-4a94a639f323

# blkid /dev/sda2
/dev/sda2: UUID="528c141b-66fd-43d5-808b-4a94a639f323" TYPE="ext4"

Con esta información ya podemos añadir la entrada correspondiente al fichero /etc/fstab. Si antes estaba así:

/dev/sda2     /datos               ext4    defaults        1 1

Ahora quedaría así:

UUID=528c141b-66fd-43d5-808b-4a94a639f323     /datos        ext4    defaults   1 1

¿Y cómo averiguamos o configuramos la etiqueta del filesystem?

Es sencillo, con el comando tune2fs seguido del parámetro -L podemos configurar la etiqueta que queramos:

# tune2fs -L "DATOS" /dev/sda2
tune2fs 1.41.12 (17-May-2010)

Para consultar la etiqueta/label de la partición:

# tune2fs -l /dev/sda2 | grep "Filesystem volume name"
Filesystem volume name:   DATOS

También podemos verla con el comando anterior blkid, ahora que la partición tiene label nos muestra tanto el UUID como la etiqueta:

# blkid /dev/sda2
/dev/sda2: UUID="528c141b-66fd-43d5-808b-4a94a639f323" TYPE="ext4" LABEL="DATOS"

Y para montarla en /etc/fstab tan sencillo como:

LABEL=DATOS     /datos        ext4    defaults   1 1

También te puede interesar:

• OpenVZ & Virtuozzo: activar noatime para un contenedor
• atime, noatime y relatime
• Gestión de particiones con parted en Linux
• Autofs y automount para servir nfs

Para visualizar la tabla de rutas tenemos dos posibilidades, utilizar el comando netstat -rn o route -n, ambos nos ofrecen la misma salida:

# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.1.0     0.0.0.0         255.255.255.0   U         0 0          0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 eth0
0.0.0.0         192.168.1.1     0.0.0.0         UG        0 0          0 eth0

Las tres primeras columnas nos indican, por un lado las redes de destino (Destination), la puerta de enlace que utilizan (Gateway) y la máscara de red (Genmask). En las Flags vemos “U”, que significa que la interfaz de red está levantada y G que indica que esa ruta utiliza la puerta de enlace. 0.0.0.0 es tratado como un wildcard (también se suele representar con un *) y especifica el destino a cualquier red no especificada.

Explicando la salida del comando route anterior, vemos en primer lugar que todo paquete dirigido a las redes 192.168.1.0/255.255.255.0 y 169.254.0.0/255.255.0.0 serán enviados a través de redes LAN (vemos que no hay flag de gateway) por lo que no harán uso de puerta de enlace. En cambio todo paquete con destino 0.0.0.0, es decir, el resto de redes sí que pasará por nuestra puerta de enlace 192.168.1.1. Todas estas rutas trabajan bajo la interfaz de red eth0, si tuviéramos más interfaces levantadas aparecerían marcadas como ethX en la columna Iface.

También te puede interesar:

• Enrutar en Linux (route add/del)
• Snort: FATAL ERROR: OpenPcap() device eth0 open: bind: Network is down
• Netstat: Estado de las conexiones
• Configurar spamassassin para aceptar conexiones remotas

Antes de Solaris 9 los servicios se gestionaban como en la mayoría de sistemas Unix y Linux (legacy), teníamos scripts de arranque en /etc/init.d y se creaban enlaces simbólicos contra ellos en los distintos runlevels (directorios RC) para su arranque/parada. A partir de Solaris 9 se introdujo SMF (Service Management Facility) y se ha convertido en la manera por defecto de gestionar los servicios en Solaris 10.

Los beneficios de SMF sobre el método anterior son sustanciales. Entre ellos la posibilidad de mantener monitorizados los servicios para que en el momento que se produzca una caída levanten de forma instantánea, la gestión inteligente de arranque mediante la cual el servicio tiene unas dependencias y hasta que no estén activas el servicio no está disponible, el arranque en paralelo y de forma asíncrona, etc.

Los comandos básicos para gestion de servicios en SMF son svcs, svccfg y svcadm. Mediante svcs a secas podemos ver el estado de los servicios del sistema (incluidos los del sistema antiguo legacy), a través de distintos parámetros podemos filtrar únicamente los deshabilitados, etc:

# svcs
STATE          STIME    FMRI
legacy_run      9:04:48 lrc:/etc/rc2_d/S20sysetup
legacy_run      9:04:48 lrc:/etc/rc2_d/S47pppd
legacy_run      9:04:49 lrc:/etc/rc2_d/S72autoinstall
legacy_run      9:04:49 lrc:/etc/rc2_d/S73cachefs_daemon
legacy_run      9:04:49 lrc:/etc/rc2_d/S81dodatadm_udaplt
legacy_run      9:04:49 lrc:/etc/rc2_d/S89PRESERVE
disabled        9:02:34 svc:/platform/i86pc/acpihpd:default
online          9:01:28 svc:/system/svc/restarter:default
online          9:01:35 svc:/system/early-manifest-import:default
online          9:01:38 svc:/network/netcfg:default
online          9:01:39 svc:/network/datalink-management:default
online          9:01:39 svc:/network/socket-config:default
...
...

Básicamente vemos el estado del proceso, la última vez que el servicio cambió de estado y su FMRI (Fault Management Resource Identifier). El FMRI es el identificador del servicio. El FMRI se divide en tres partes separadas por “:”. La primera el esquema (svc o lrc según el tipo de servicio), la categoría en la que se encuentra (network, system…) y el nombre del servicio, y finalmente la instancia.

Podemos ver también con detalle el estado de un único servicio con el parámetro “-x” y sus dependencias con “-d”:

# svcs -x  svc:/system/cron:default
svc:/system/cron:default (clock daemon (cron))
 State: online since  1 de noviembre de 2011 09:02:51 WET
   See: cron(1M)
   See: crontab(1)
   See: /var/svc/log/system-cron:default.log
Impact: None.

# svcs -d svc:/system/cron:default
STATE          STIME    FMRI
online          9:02:35 svc:/milestone/name-services:default
online          9:02:49 svc:/system/filesystem/local:default

Podemos verificar rápidamente cómo SMF monitoriza activamente los servicios que están bajo su control, vamos a ver el estado del servicio cron, matarlo con una señal kill y verificar que al momento SMF lo ha levantado de nuevo:

# date
martes  1 de noviembre de 2011 09:46:24 WET
# svcs -v system/cron
STATE          NSTATE        STIME    CTID   FMRI
online         -              9:02:51     62 svc:/system/cron:default
# ps -ef | grep cron
    root   441     1   0 09:02:51 ?           0:00 /usr/sbin/cron
    root   841   687   0 09:46:33 pts/1       0:00 grep cron
# kill 441
# svcs -v system/cron
STATE          NSTATE        STIME    CTID   FMRI
online         -              9:46:38     96 svc:/system/cron:default

A través de svcs también podemos ver el estado de un servicio y diagnosticarlo cuando no es satisfactorio. Encontraremos los siguientes estados: online, offline, disabled, degraded, maintenance y legacy-run. Los cuatro primeros estados están claros, online, offline, deshabilitado y degradado. Cuando un servicio está en estado maintenance es debido a que hay algún problema con el servicio y no puede ser arrancado. Como requiere nuestra intervención se pone a nuestra disposición la ruta hacia el log del servicio para verificar el origen del problema. El estado legacy-run simplemente indica que se trata de un servicio legacy.

Mediante svcadm podemos gestionar el estado de cada uno de los servicios, con los parámetros “enable”, “disable”, “refresh”, “clear”, “mark” y “restart”. Aparte de los obvios, conviene comentar que “refresh” sirve para leer de nuevo los ficheros de configuración del servicio por si se ha realizado algún cambio, “clear” sirve para resetear el servicio si se encuentra en estado de mantenimiento y “mark” para marcar un servicio como degradado, mantenimiento, etc.

Para que veáis un ejemplo de fichero xml básico para un servicio aquí tenéis uno para la gestión de Oracle iPlanet webserver 7 que instalamos hace unos días. Básicamente hemos establecido como dependencias los servicios de red, los sistemas de ficheros locales y el arranque bajo el milestone multi-user (lo que viene siendo el runlevel 3 en legacy). Después establecemos los tres comandos para el arranque, parada y reinicio del servicio:

<?xml version='1.0'?>

<!DOCTYPE service_bundle SYSTEM '/usr/share/lib/xml/dtd/service_bundle.dtd.1'>

<service_bundle type='manifest' name='webserver7'>

<service name='network/webserver7' type='service' version='0'>
<create_default_instance enabled='true'/>
<single_instance/>
<dependency name='fs' grouping='require_all' restart_on='none' type='service'>
<service_fmri value='svc:/system/filesystem/local'/>
</dependency>
<dependency name='net' grouping='require_all' restart_on='none' type='service'>
<service_fmri value='svc:/network/physical'/>
</dependency>
<dependent name='webserver7_multi-user' restart_on='none' grouping='optional_all'>
<service_fmri value='svc:/milestone/multi-user'/>
</dependent>
<exec_method name='start' type='method' exec='su www -c "/opt/webserver7/bin/webserver7 start"' timeout_seconds='60'>
<method_context/>
</exec_method>
<exec_method name='stop' type='method' exec='su www -c "/opt/webserver7/bin/webserver7 stop"' timeout_seconds='60'>
<method_context/>
</exec_method>
<exec_method name='restart' type='method' exec='su www -c "/opt/webserver7/bin/webserver7 restart"' timeout_seconds='60'>
<method_context/>
</exec_method>
</service>

</service_bundle>

Para importar un servicio creado de este modo ejecutamos el siguiente comando:

# svccfg import webserver7.xml

Como siempre os recomiendo revisar las páginas man de todos estos comandos para recibir información detallada sobre cada uno de ellos, esto es una pequeña introducción que podría extenderse mucho más si entráramos en detalle de cada una de las características y posibilidades de SMF. Ahí van unas cuantas referencias para aprender más sobre Service Management Facility:

• Using Solaris SMF (O’Reilly)
• Universidad de Princeton, Service Management Facility
• OpenSolaris SMF FAQ

También te puede interesar:

• Stub Start Error en Oracle iPlanet Web Server: PHP + FastCGI
• Configurar PHP + FastCGI en Oracle iPlanet Web Server
• Gestionar el storage en Solaris con zfs y zpool
• Gestión de snapshots en ZFS

Hiciera lo que hiciera con el comando ipadm (sustituto de ifconfig) no me dejaba desactivar en la interfaz de red el DHCP. Tras un rato trasteando y buscando en google encontré una opción que permite desactivar nwam (NetWork Auto Magic, que configura la red de forma automática), el responsable de esta asignación dinámica y activar la opción ‘por defecto’ para la configuración de las interfaces.

Ante todo desconozco (de momento) si esta es la solución más óptima para hacerlo, pero desde luego es rápida y efectiva. Únicamente son dos pasos:

# pfexec svcadm enable physical:default
# pfexec svcadm disable physical:nwam

Con svcadm activamos la opción default y desactivamos nwam. pfexec es algo así como el sudo de Solaris, ya hablaremos de él más adelante. Una vez realizado esto, ya podéis configurar ips estáticas en Oracle Solaris 11 con ipadm.

También te puede interesar:

• Introducción a SMF (Service Management Facility) en Solaris
• Stub Start Error en Oracle iPlanet Web Server: PHP + FastCGI
• Configurar PHP + FastCGI en Oracle iPlanet Web Server
• Gestionar el storage en Solaris con zfs y zpool

La filosofía es similar al apt en Debian o yum en RHEL, así que vamos a ver unos cuantos ejemplos de instalación, eliminación, actualización de paquetes, etc.

Buscar un paquete

La sintaxis a utilizar es la siguiente:

# pkg search <paquete>

Si por ejemplo quisiéramos buscar el servidor web Lighttpd podríamos buscar las versiones disponibles así:

# pkg search lighttpd
INDEX ACTION VALUE PACKAGE
description set Lighttpd Web Server pkg:/web/server/lighttpd-14@1.4.23-0.151.0.1
pkg.description set The Lighttpd Web Server (1.4.23) pkg:/web/server/lighttpd-14@1.4.23-0.151.0.1
pkg.summary set Lighttpd Web Server pkg:/web/server/lighttpd-14@1.4.23-0.151.0.1
basename dir etc/lighttpd pkg:/web/server/lighttpd-14@1.4.23-0.151.0.1
basename dir usr/lighttpd pkg:/web/server/lighttpd-14@1.4.23-0.151.0.1
basename dir var/lighttpd pkg:/web/server/lighttpd-14@1.4.23-0.151.0.1
basename file etc/security/auth_attr.d/lighttpd pkg:/web/server/lighttpd-14@1.4.23-0.151.0.1
basename file etc/security/prof_attr.d/lighttpd pkg:/web/server/lighttpd-14@1.4.23-0.151.0.1
basename file usr/lighttpd/1.4/sbin/lighttpd pkg:/web/server/lighttpd-14@1.4.23-0.151.0.1
pkg.fmri set solaris/web/server/lighttpd pkg:/web/server/lighttpd@1.4.23-0.134

También podemos buscar en un repositorio determinado con el parámetro -s:

# pkg search -s http://pkg.repo.com/ lighttpd

O utilizar las cláusula AND y OR para encadenar consultas y/o utilizar comodines:

# pkg search lighttpd AND htt*d OR apache

Ver la información de un paquete

Para ver toda la información de un paquete usaremos el parámetro info seguido del paquete a consultar:

# pkg info pkg://solaris/web/server/lighttpd-14@1.4.23-0.151.0.1
          Name: web/server/lighttpd-14
       Summary: Lighttpd Web Server
   Description: The Lighttpd Web Server (1.4.23)
      Category: Web Services/Application and Web Servers
         State: Not installed
     Publisher: solaris
       Version: 1.4.23
 Build Release: 5.11
        Branch: 0.151.0.1
Packaging Date:  5 de noviembre de 2010 06:22:12
          Size: 794.78 kB
          FMRI: pkg://solaris/web/server/lighttpd-14@1.4.23,5.11-0.151.0.1:20101105T062212Z

Instalación de un paquete

La instalación es sencilla, como en cualquier gestor de paquetes:

# pkg install <paquete>

Vamos a instalar una de las versiones de lighttpd encontradas antes:

# pkg install pkg:/web/server/lighttpd-14@1.4.23-0.151.0.1
Packages to install: 2
Create boot environment: No
Services to restart: 1
DOWNLOAD PKGS FILES XFER (MB)
Completed 2/2 52/52 4.5/4.5

PHASE ACTIONS
Install Phase 143/143

PHASE ITEMS
Package State Update Phase 2/2
Image State Update Phase 2/2

Como véis, a la hora de instalar un paquete se puede especificar la versión exacta a instalar de todas las disponibles, y también el “publisher” del cual la queremos instalar. Si quisieramos instalarla desde otro repositorio/publisher lo especificaríamos del siguiente modo, donde repo-mirror.com es el publisher.:

# pkg install pkg://repo-mirror.com/test/paquete-solaris

Simular la instalación de un paquete

Pasando los parámetros -nv a install podemos ver lo que se instalaría en el sistema sin necesidad de hacerlo:

# pkg install -nv <paquete>

# pkg install -nv pkg:/system/management/webmin@1.510-0.151.0.1
               Packages to install:     1
           Create boot environment:    No
               Services to restart:     1
              Rebuild boot archive:    No
Changed fmris:
  None -> pkg://solaris/system/management/webmin@1.510,5.11-0.151.0.1:20101105T061636Z
Services:
  restart_fmri: svc:/system/manifest-import:default

Actualizar un paquete

A la hora de actualizar un paquete se puede usar tanto la orden install como update:

# pkg update <paquete>
# pkg install <paquete>

Verificar la instalación de un paquete

Una vez realizada una instalación podemos verificar si todo se ha realizado de forma correcta, si el paquete se ha instalado bien, busqueda de errores, etc. Para ello utilizamos el parámetro verify. Con el parámetro -v vemos toda la información y con -q únicamente los errores:

# pkg verify -v pkg:/web/server/lighttpd-14@1.4.23-0.151.0.1
Verifying: PACKAGE                                             STATUS
pkg://solaris/web/server/lighttpd-14                    OK

Arreglar fallos en paquetes instalados

En caso de haber recibido algún error en el punto mencionado anteriormente (verify), podemos tratar de arreglarlo mediante la siguiente orden:

pkg fix --accept <paquete>

Desinstalar un paquete

Muy sencillo:

pkg uninstall <paquete>

Vamos a desinstalar el servidor web lighttpd instalado anteriormente:

# pkg uninstall pkg://solaris/web/server/lighttpd-14@1.4.23-0.151.
                Packages to remove:     1
           Create boot environment:    No
               Services to restart:     1
PHASE                                        ACTIONS
Removal Phase                                  1/104
Warning - directory //var/lighttpd/1.4/logs not empty or not expected during operation - contents preserved in /var/pkg/lost+found/var/lighttpd/1.4/logs-20110925T204323Z

Warning - directory //var/lighttpd/1.4/docroot not empty or not expected during operation - contents preserved in /var/pkg/lost+found/var/lighttpd/1.4/docroot-20110925T204323Z
Removal Phase                                104/104

PHASE                                          ITEMS
Package State Update Phase                       1/1
Package Cache Update Phase                       1/1
Image State Update Phase                         2/2

Ver el contenido de un paquete

Siempre es útil conocer el contenido del paquete a instalar para saber con exactitud que es lo que vamos a instalar en nuestro sistema y donde. Si queremos, podemos especificar que nos indique el path, el tamaño de cada fichero, etc:

# pkg contents -r -o pkg.size,path pkg://solaris/web/server/lighttpd-14@1.4.23-0.151.0.1
PKG.SIZE PATH
  1503
    1503
         etc
         etc/lighttpd
         etc/lighttpd/1.4
         etc/lighttpd/1.4/conf.d
    1934 etc/lighttpd/1.4/conf.d/fcgi-php.conf
    1105 etc/lighttpd/1.4/conf.d/ssl.conf
   11497 etc/lighttpd/1.4/lighttpd.conf
         etc/security
....
....
....
   11696 usr/lighttpd/1.4/lib/mod_extforward.so

Visualizar el historial de acciones realizadas con pkg

Podemos ver un registro de las acciones realizadas:

# pkg history
TIME                OPERATION                 CLIENT          OUTCOME
2010-11-05T16:14:56 purge-history             pkg             Succeeded
2011-09-22T18:41:16 uninstall                 pkg             Succeeded
2011-09-22T18:41:37 uninstall                 pkg             Succeeded
2011-09-22T18:41:53 set-property              pkg             Succeeded
2011-09-22T18:42:03 set-property              pkg             Succeeded
2011-09-25T10:21:01 uninstall                 pkg             Succeeded
2011-09-25T17:05:22 refresh-publishers        pkg             Succeeded
2011-09-25T17:05:22 install                   pkg             Failed (Bad Request)
2011-09-25T17:12:25 refresh-publishers        pkg             Succeeded

Y para eliminar este registro:

# pkg purge-history

Espero que os haya sido de utilidad esta guía de iniciación a pkg en Oracle Solaris, seguiré profundizando en los secretos de este sistema en próximos artículos.

También te puede interesar:

• Introducción a SMF (Service Management Facility) en Solaris
• Stub Start Error en Oracle iPlanet Web Server: PHP + FastCGI
• Configurar PHP + FastCGI en Oracle iPlanet Web Server
• Gestionar el storage en Solaris con zfs y zpool

Vamos a ver como haríamos para configurar una IP estática en nuestro sistema para la interfaz de red e1000g0. Una IP dentro del rango 192.168.0.0/24 y con puerta de enlace 192.168.1.1.

Lo primero que podemos hacer es echar un vistazo a lo que ya tenemos configurado, en este caso únicamente las interfaces locales, con show-if vemos el estado de las interfaces y con show-addr el estado de las direcciones asignadas:

# ipadm  show-if
IFNAME     STATE    CURRENT      PERSISTENT
lo0        ok       -m-v------46 ---
# ipadm  show-addr
ADDROBJ           TYPE     STATE        ADDR
lo0/v4            static   ok           127.0.0.1/8
lo0/v6            static   ok           ::1/128

Bien, lo primero que debemos hacer es ‘dar de alta’ nuestra interfaz, activarla. Para ello utilizaremos el parámetro create-if:

Una vez creada, vemos con show-if que efectivamente ya figura, aunque de momento está caída:

# ipadm show-if e1000g0
IFNAME     STATE    CURRENT      PERSISTENT
e1000g0    down     bm--------46 -46

Procedemos a asignar ya una IP estática y máscara a la interfaz, en este caso la 192.168.1.100, con máscara /24 y tipo ipv4:

# ipadm create-addr -T static -a 192.168.1.100/24 e1000g0/v4

Ahora podemos verificar, ya sea con ifconfig como con ipadm que la IP ha sido configurada correctamente:

# ifconfig e1000g0
e1000g0: flags=1000843 mtu 1500 index 2
        inet 192.168.1.100 netmask ffffff00 broadcast 192.168.1.255
        ether 8:0:27:30:43:df 

# ipadm show-addr e1000g0/v4
ADDROBJ           TYPE     STATE        ADDR
e1000g0/v4        static   ok           192.168.1.100/24

Efectivamente, tenemos conectividad con otros nodos de la red:

# ping 192.168.1.128
192.168.1.128 is alive

Sólo nos queda configurar el enrutado y los servidores DNS para tener la red configurada de forma correcta:

# route -p add default 192.168.0.1
add net default: gateway 192.168.0.1
add persistent net default: gateway 192.168.0.1

Verificamos la tabla de rutas con el comando netstat:

# netstat -r

Routing Table: IPv4
  Destination           Gateway           Flags  Ref     Use     Interface
-------------------- -------------------- ----- ----- ---------- ---------
default              192.168.1.1          UG        1          0
solaris              solaris              UH        2         24 lo0
192.168.1.0          192.168.1.100        U         4        369 e1000g0   

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

Las DNS las añadiríamos en el fichero /etc/resolv.conf como en cualquier sistema Unix. También verificaríamos que estas dos entradas del fichero /etc/nsswitch.conf tienen añadida la opción dns:

hosts:      files dns
ipnodes:    files dns

También te puede interesar:

• Introducción a SMF (Service Management Facility) en Solaris
• Stub Start Error en Oracle iPlanet Web Server: PHP + FastCGI
• Configurar PHP + FastCGI en Oracle iPlanet Web Server
• Gestionar el storage en Solaris con zfs y zpool

Vamos a ello, arrancamos el equipo con un CD con la imagen ISO grabada y empezamos la instalación. Seleccionamos el tipo de teclado, en nuestro caso ’39′ (español):

Ahora toca elegir el idioma, en mi caso selecciono inglés ya que prefiero instalar los sistemas en inglés que en español, sobre todo porque a la hora de buscar documentación y errores hay mucha más información:

Comienza la instalación de Oracle Solaris, elegimos ’1′ para empezar:

Tras la pantalla de bienvenida, empezamos con la configuración de discos y particiones. Primero toca elegir el disco sobre el que hacer la instalación y después la estructura de particiones. En este caso es un disco virtual sobre Virtualbox, así que elegimos el único disco disponible y usamos todo el disco para instalar el sistema.

Ahora introducimos el nombre de la máquina (hostname) y especificamos si deseamos que la configuración de red sea automática o si preferimos realizarla de forma manual posteriormente:

Establecemos la configuración regional del equipo, fecha, etc:

Llega el momento de asignar una clave al usuario root y la creación de una cuenta de usuario extra:

Antes de comenzar la instalación, podemos ver un resumen de las opciones configuradas y elegir cambiar alguna de ellas volviendo atrás (F3):

Cuando todo esté correcto, presionamos F2 y la instalación comenzará:

Una vez finalizada la instalación sólo nos queda presionar F8 para hacer un reboot y ya podemos comenzar a disfrutar de nuestro sistema Oracle Solaris:

alex@solaris:~$ uname -a
SunOS solaris 5.11 snv_151a i86pc i386 i86pc

En las próximas entradas empezaremos a ver cómo configurar las interfaces de red, la instalación de paquetes y una visión general del sistema.

También te puede interesar:

• Introducción a SMF (Service Management Facility) en Solaris
• Stub Start Error en Oracle iPlanet Web Server: PHP + FastCGI
• Configurar PHP + FastCGI en Oracle iPlanet Web Server
• Gestionar el storage en Solaris con zfs y zpool

TCP Wrapper (“Envoltorio de TCP”) es un sistema de red ACL que trabaja en terminales y que se usa para filtrar el acceso de red a servicios de protocolos de Internet que corren en sistemas operativos (tipo UNIX), como Linux o BSD. Permite que las direcciones IP, los nombres de terminales y/o respuestas de consultas ident de las terminales o subredes sean usadas como tokens sobre los cuales filtrar para propósitos de control de acceso.

Bien, partimos de la base de que tenemos dos ficheros configurables, /etc/hosts.deny y /etc/hosts.allow. En ellos podemos especificar que IPs, hostnames o redes pueden acceder a determinados servicios del sistema. TCP Wrappers suele venir instalado por defecto en la mayoría de sistemas operativos Unix.

La sintaxis básica de estos ficheros es la siguiente:

daemon : dirección : acción
ó
daemon : dirección

Daemon es el demonio/servicio a filtrar, dirección es la dirección, host o subred y acción si denegamos o aceptamos el acceso. Para saber si un servicio puede ser configurado para filtrado vía TCP Wrappers hay que saber si su binario está enlazado con la biblioteca libwrap.a. Para ello:

# ldd /usr/sbin/sshd | grep libwrap.so
	libwrap.so.0 => /lib/libwrap.so.0 (0x001ce000)

Si la salida es NULL el demonio no está compilado con TCP Wrappers y no funcionará. Si devuelve algo como lo anterior sí que lo está. Vamos a ver entonces unos cuantos ejemplos:

Permitir acceso ssh únicamente a unas IPs

/etc/hosts.allow Permitimos acceso a las IPs 192.168.0.111, 192.168.0.112, 192.168.0.113.

sshd: 192.168.0.111 192.168.0.112 192.168.0.113

/etc/hosts.deny Denegamos al resto.

sshd: ALL

Bloquear todo excepto lo declarado en /etc/hosts.allow

/etc/hosts.allow

sshd: 192.168.0.111 192.168.0.112 192.168.0.113

/etc/hosts.deny Denegamos acceso al resto de servicios excepto SSH a las Ips indicadas. La máquina quedará blindada excepto el acceso SSH a las Ips permitidas:

ALL: ALL

Permitir también el uso de sendmail a una subred y unos hosts concretos

/etc/hosts.allow Permitimos acceso a las IPs 192.168.0.111, 192.168.0.112, 192.168.0.113.

sshd: 192.168.0.111 192.168.0.112 192.168.0.113
sendmail: 10.0.0.0/24 test.com prueba.com

/etc/hosts.deny

ALL: ALL

Permitir todo y bloquear el acceso total a una única IP

/etc/hosts.allow

ALL: ALL

/etc/hosts.deny

ALL: 192.168.0.115

Filtrar y ejecutar un comando tras un intento de acceso

/etc/hosts.allow

ALL: ALL

/etc/hosts.deny

ALL: 192,168.0.115 \
   : spawn (/bin/echo %a desde %h intento acceder a %d >> \
    /var/log/connections.log) \
   : deny

Aquí ya depende todo si queremos aplicar una política restrictiva desde el principio, bloquear todo y a partir de ahí comenzar a abrir servicios a determinadas Ips, rangos o hosts o si por el contrario queremos dejar todo abierto y cerrar servicios a determinadas Ips,etc.

Si os resulta interesante, disponéis de más información en el handbook de freebsd o en Linux about.com. Esta ha sido una mera introducción a TCP Wrappers

También te puede interesar:

• Encriptar un filesystem con LUKS y cryptsetup
• 10 trucos para securizar PHP
• Comando chage: tiempo de vida de claves y usuarios en GNU/Linux
• Permisos especiales (setuid, setgid, sticky bit)

visudo

El comando visudo permite modificar en modo seguro el fichero /etc/sudoers. La diferencia de editarlo con visudo a hacerlo con cualquier otro editor es que visudo bloquea el fichero para evitar ediciones sumultaneas. Otro punto a favor de editar sudoers de esta forma es que en el momento de guardar los cambios realiza un chequeo del fichero en busca de fallos de sintaxis y todo tipo de errores, y en caso de encontrarlos no nos permitirá guardar el fichero y nos indicará el número de línea donde se encuentra el error, permitiendonos editar el ficehro o salir sin guardar.

# visudo

vipw y vigr

Los comandos vipw y vigr permiten editar los ficheros /etc/passwd y /etc/group respectivamente de forma segura. Si quisieramos editar el fichero /etc/shadow y /etc/gshadow deberíamos utilizar el parámetro -s.

Cabe decir que es recomendable evitar la manipulación directa de estos ficheros y que es conveniente usar los comandos correspondientes para gestión de usuarios: crear, eliminar y modificar usuarios de sistema en Unix. Si fuera estrictamente necesario, la modificación de passwd y shadow sería del siguiente modo:

Primero editamos el fichero /etc/passwd:

# vipw
Ha modificado /etc/passwd.
Necesitará modificar /etc/shadow por consistencia.
Use la orden «vipw -s» para hacerlo.

Y posteriormente editamos el fichero shadow y gshadow:

# vipw -s
vipw: /etc/shadow no está cambiado

Si no quisieramos editar el fichero shadow a mano podemos decirle al sistema que lo actualice de forma automática con el comando pwconv:

# pwconv

Y lo mismo cuando editamos grupos con vigr, para evitar la modificación manual de gshadow podemos usar grpconv:

# grpconv

Al igual que con visudo, vigr y vipw bloquean los ficheros para evitar que puedan ser editados a la vez. Para evitar esto se crea un fichero temporal /etc/ptmp y se deshabilita la escritura del mismo.

Os recomiendo revisar las páginas man de los comandos para encontrar información más detallada sobre el funcionamiento y posibilidades de cada uno de ellos.

También te puede interesar:

• Cómo encontrar fallos e inconsistencias en los ficheros passwd y shadow
• Crear, eliminar y modificar usuarios de sistema en Unix
• Securizar la gestión de claves en Linux mediante PAM
• Generador de passwords aleatorios