Sigo explorando el sistema Oracle Solaris Express, tras su instalación y configuración de la red vamos a ver la utilización del gestor/repositorio de paquetes que incorpora, pkg.

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.

En el sistema Oracle Solaris 11 Express tenemos la posibilidad de utilizar un nuevo comando para realizar tareas de configuración y mantenimiento de nuestras interfaces de red. Este comando puede sustituir al ya conocido por todos ifconfig, se trata de ipadm.

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

Hoy vamos a ver lo sencillo que resulta instalar Oracle Solaris 11 Express 2010.11 tanto en una máquina virtual como en un equipo físico. Lo primero que tenemos que hacer es descargar la imagen de instalación correspondiente desde este enlace del sitio web de Oracle (es necesario registro). En mi caso, como es habitual he utilizado la versión de instalación en modo texto para x86.

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.

El otro día hablábamos sobre securizar un sistema Linux con iptables y en otro artículo encontrábamos un firewall basado en FreeBSD llamado pfSense. Hoy vamos a ver cómo securizar un sistema Unix (Linux, BSD…) a través de TCP Wrappers,  un buen complemento de iptables. La wikipedia lo define como:

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

Siguiendo con el tema tratado en el anterior post sobre como encontrar fallos e inconsistencias en los ficheros passwd y shadow vamos a ver como a la hora de editar ciertos ficheros críticos del sistema debemos asegurarnos de hacerlo de forma correcta. Ficheros como /etc/passwd, /etc/group, /etc/shadow o /etc/sudoers pueden editarse ‘al vuelo’ con un editor normal (gedit, vi, vim, nano…) pero corremos el peligro de que mientras lo estamos editando sus datos se hayan actualizado y se pierdan los cambios.

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.

Me he encontrado con un problema ante el que el origen parecía un fallo en la variable $PATH que se define al hacer login con un usuario en el sistema. La situación era la siguiente: accedemos por ssh y seguidamente hacemos su para autenticarnos como root. El problema viene en que algunos comandos no se encuentran en el PATH por lo que recibimos errores como estos:

[alex@server  ~$] su
Contraseña:
[root@server alex#] echo $PATH
/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/home/alex/bin

[root@server  ~#] tcpdump
bash: tcpdump: command not found
[root@server   ~#] sendmail
bash: sendmail: command not found

Como podéis ver en la secuencia de comandos, el resultado de la variable $PATH está incompleto, faltan /usr/sbin y /sbin. El correcto sería algo así:

[root@server alex#] echo $PATH
/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin

Probablemente algunos ya hayáis visto donde está el error, y otros no. El fallo es el paso de la autenticación a root, en lugar de su a secas hay que hacerlo con su -<:

$ su -

La aclaración de esto es que el comportamiento por defecto de su es mantener tanto el directorio home del usuario como sus variables de entorno en lugar de adquirir las del nuevo usuario, en este caso root. Así que si queremos adquirir todas las variables de entorno del usuario contra el que hacemos su deberemos especificar el usuario, o en caso de root el guión por lo menos:

$ su - usuario

En los sistemas Unix, cada una de las particiones/sistema de ficheros cuenta con un directorio llamado /lost+found en el cual se almacenan ficheros y directorios (o restos de ellos…) recuperados tras una revisión del sistema de ficheros  a través de la herramienta fsck, todo ello provocado habitualmente por cuelgues del sistema, apagados forzados del equipo, cortes de corriente, etc.

Todos aquellos ficheros y directorios recuperados tras un fsck se almacenan con la siguiente estructura en el directorio /lost+found, el nombre de cada fichero es el número de inodo:

# ls -l /lost+found/
total 1512
drwxr-xr-x 3 root root   4096 2010-03-12 09:38 #123805
drwxr-xr-x 3 root root   4096 2010-03-12 09:38 #125488
drwxr-xr-x 3 root root   4096 2010-03-12 09:38 #135836
-rw-r--r-- 2 root root   2473 2010-03-02 16:03 #137864
-rw-r--r-- 2 root root  18505 2010-03-02 16:03 #137865
-rw-r--r-- 2 root root  56140 2010-03-02 16:03 #137866
-rw-r--r-- 2 root root  25978 2010-03-02 16:03 #137867
-rw-r--r-- 2 root root  16247 2010-03-02 16:03 #137868
-rw-r--r-- 2 root root 138001 2010-03-02 16:03 #137869
-rw-r--r-- 2 root root  63623 2010-03-02 16:03 #137870
-rw-r--r-- 2 root root  34032 2010-03-02 16:03 #137871
-rw-r--r-- 2 root root   2536 2010-03-02 16:03 #137872

Estos ficheros pueden estar corruptos o incompletos, pero podemos tener suerte y encontrar aquello que creíamos perdido tras el fsck:

# cd \#125488/
#125488# ls
images  index.html

Tendremos que revisar uno a uno los ficheros y directorios debido a que el nombre del fichero se ha perdido, en este caso una imagen GIF:

# file \#89952
#89952: GIF image data, version 89a, 169 x 20

Como os podéis imaginar, puede ser una ardua tarea revisar todos los ficheros y directorios e intentar volverlos a poner en su sitio, lo más sensato es recuperar una copia de seguridad y trabajar con ella, reinstalar en caso de ser librerías, binarios… En caso de no disponer de un backup, con los comandos ‘file’ como hemos visto antes o ‘strings’, ‘more’, etc. podemos intentar recuperar algo de información de los ficheros pero puede llegar a ser prácticamente imposible en algunos casos. ¡Suerte!

La variable de entorno TMOUT nos permite definir el tiempo que queremos permitir a un usuario permanecer dentro de la shell o sesión SSH sin hacer nada (estado idle o inactivo). Por defecto no hay límite de tiempo por lo que un usuario podrá permanecer de forma indefinida conectado al sistema independientemente de que la sesión se esté utilizando o no.

Para configurar esta variable, simplemente la añadimos dentro de nuestro perfil de variables/configuraciones de bash ~/.bash_profile o ~/.bashrc. Conviene configurarla como read only para evitar que el propio usuario pueda modificarla:

# Establecemos en 2 minutos (120 segundos) el Timeout para la sesión bash/ssh
TMOUT=120
readonly TMOUT

Refrescamos la shell o entramos y salimos para que sea efectivo:

$ bash

También podemos establecerla a tiempo real mediante export:

$ export TMOUT=120

A partir de ahora, si dejamos la shell abierta durante 2 minutos sin realizar ninguna tarea automáticamente nos desconectará de la sesión:

$ timed out waiting for input: auto-logout