• Sun LDAP Server
• Cliente Red Hat Enterprise Linux con LDAP nativo configurado contra el servidor de Sun

La configuración del LDAP Nativo en Red Hat es relativamente sencilla, únicamente lanzamos el authconfig-tui o pasamos los parámetros correspondientes al comando authconfig. Una vez configurado, ya deberíamos poder autenticarnos con los usuarios del LDAP.

En este caso concreto, todo funcionaba correctamente a excepción de la autenticación. Si hacíamos su desde root a cualquier usuario del LDAP funcionaba, la salida del comando getent passwd o getent shadow mostraba todos los usuarios, podíamos hacer ldapsearch, etc.

Con la autenticación, nos pedía continuamente cambiar la password porque había expirado:

$ ssh test@10.0.0.15
You are required to change your LDAP password immediately.
Warning: Your password has expired, please change it now
...
...

Por lo que sea, los servidores Solaris en nuestro caso hacían caso omiso a los atributos de expiración, llevabamos años sin problemas, pero RHEL sí que los revisaba. Todo debería haber funcionado una vez cambiada la clave, pero los servidores RHEL seguían pidiendo continuamente que se cambiara (en Solaris sí que se accedía con la nueva clave).

Para poder acceder correctamente desde Red Hat (y creo que desde cualquier máquina Linux) hay que prestar especialmente atención a estos atributos de LDAP para cada usuario:

shadowMax:
shadowMin:
shadowWarning:

Si están presentes, es necesario que su valor este vacío (no 0) para solucionar el problema. O eso, o especificar una expiración de 99999 en shadowMax… una vez cambiado accederéis sin problemas vía ssh  y con el resto de autenticación.

También te puede interesar:

• Monitorizar Oracle iPlanet Web Server con get-perfdump
• Usar autenticación LDAP (OpenLDAP) con OpenSSHD (sshd)
• Login SSH sin password de forma rápida y sencilla
• ¿Qué es APIPA/zeroconf y cómo deshabilitarlo en CentOS/RHEL (169.254.x.y)?

Como ya sabéis la mayoría, el comando ulimit -a nos dice los valores y límites establecidos para nuestro usuario:

$ ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 20
file size               (blocks, -f) unlimited
pending signals                 (-i) 16382
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) unlimited
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

Los que más se suelen cambiar son el número de ficheros abiertos de forma simultanea por el usuario, el número de procesos por usuario, ciclos de cpu, etc. Para nuestra sesión, lo solemos hacer directamente en la línea de comandos:

# ulimit -n
1024
# ulimit -n 2048
# ulimit -n
2048

Si salimos de la sesión y entramos de nuevo, el valor volverá a ser 1024. En el caso de Red Hat y derivados, así como Debian debemos especificar estos valores en el fichero /etc/security/limits.conf, así los haremos persistentes.

El propio fichero está perfectamente documentado con comentarios, sino, también tenemos la página man de limits.conf para más información:

$ man limits.conf

# /etc/security/limits.conf
#
#Each line describes a limit for a user in the form:
#
#            
#
#Where:
# can be:
#        - an user name
#        - a group name, with @group syntax
#        - the wildcard *, for default entry
#        - the wildcard %, can be also used with %group syntax,
#                 for maxlogin limit
#        - NOTE: group and wildcard limits are not applied to root.
#          To apply a limit to the root user,  must be
#          the literal username root.
#
# can have the two values:
#        - "soft" for enforcing the soft limits
#        - "hard" for enforcing hard limits
#
# can be one of the following:
#        - core - limits the core file size (KB)
#        - data - max data size (KB)
#        - fsize - maximum filesize (KB)
#        - memlock - max locked-in-memory address space (KB)
#        - nofile - max number of open files
#        - rss - max resident set size (KB)
#        - stack - max stack size (KB)
#        - cpu - max CPU time (MIN)
#        - nproc - max number of processes
#        - as - address space limit (KB)
#        - maxlogins - max number of logins for this user
#        - maxsyslogins - max number of logins on the system
#        - priority - the priority to run user process with
#        - locks - max number of file locks the user can hold
#        - sigpending - max number of pending signals
#        - msgqueue - max memory used by POSIX message queues (bytes)
#        - nice - max nice priority allowed to raise to values: [-20, 19]
#        - rtprio - max realtime priority
#        - chroot - change root to directory (Debian-specific)
#
#                 
#

#*               soft    core            0
#root            hard    core            100000
#*               hard    rss             10000
#@student        hard    nproc           20
#@faculty        soft    nproc           20
#@faculty        hard    nproc           50
#ftp             hard    nproc           0
#ftp             -       chroot          /ftp
#@student        -       maxlogins       4

También te puede interesar:

• The Debian Administrator’s Handbook
• Nmap Online para tu IP o Clase C
• FAQ de RHCS (Red Hat Cluster Suite)
• Red Hat Cluster: “generic error” al crear un IP Resource

En estos casos, podemos configurar el enrutamiento para ese dominio en concreto y que sea el servidor local el que haga relay contra ese MX externo. En Communigate Pro se hace como vemos a continuación.

Vamos a suponer que tenemos dado de alta el dominio pruebas.com en el servidor local Communigate Pro, pero realmente el servicio de correo lo gestiona el servidor de correo 10.0.0.100. Lo que tenemos que hacer es decir al sistema que cuando detecte la recepción de un correo para este dominio lo enrute y envíe al servidor 10.0.0.100.

Para ello accedemos desde la HTTPA a Settings > Router y añadimos la siguiente línea a la tabla de enrutamiento:

prueba.com = prueba.com@[10.0.0.100]

Como podéis ver, la estructura es:

dominio.com = dominio.com@[IP_MX]

Podemos realizar la prueba con el botón TEST que tenemos en la misma pantalla y verificar el enrutamiento:

Routed to SMTP host [10.0.0100](test@pruebas.com)

Para más información sobre el routing en CG Pro acceded a la ayuda oficial, sección routing.

También te puede interesar:

• ¿Qué es APIPA/zeroconf y cómo deshabilitarlo en CentOS/RHEL (169.254.x.y)?
• Añadir la cabecera Content-type al usar el comando mail o mailx
• cPanel: Configurar exim en puerto alternativo
• Utilidades para Mailenable

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
• Hacer cambios en un filesystem GFS2 con gfs2_tool y gfs2_edit
• Clustered Logical Volume Manager (CLVM) y GFS2

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:

• ¿Qué es APIPA/zeroconf y cómo deshabilitarlo en CentOS/RHEL (169.254.x.y)?
• Enrutar en Linux (route add/del)
• Snort: FATAL ERROR: OpenPcap() device eth0 open: bind: Network is down
• Netstat: Estado de las conexiones

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:

• Monitorizar Oracle iPlanet Web Server con get-perfdump
• 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

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:

• Monitorizar Oracle iPlanet Web Server con get-perfdump
• 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

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:

• Monitorizar Oracle iPlanet Web Server con get-perfdump
• 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

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:

• Monitorizar Oracle iPlanet Web Server con get-perfdump
• 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