VPNSSL Juniper en Ubuntu 14.04 64bits

Recientemente necesitaba acceder a una VPNSSL de Juniper y obviamente estas soluciones están pensadas para sistemas operativos Windows. En Ubuntu funciona, pero hay que instalar varias dependencias.

Esto está testeado en Ubuntu 14.04 Trusty Tahr sobre 64bits, aunque también lo he hecho funcionar en versiones anteriores. Al lanzar el «Network Connect» nos dará un error quejándose de la falta de unas librerías de 32 bits.
Lo primero que haremos será instalar el JRE y el plugin para el navegador, en este caso de OpenJDK:

$ sudo apt-get install openjdk-7-jre icedtea-7-plugin

A continuación instalaremos la versión de 32 bits, con todas las dependencias que nos pida:

$ sudo apt-get install openjdk-7-jre:i386

Tendremos que instalar otra serie de paquetes para poder utilizar la versión de 32 bits:

$ sudo apt-get install libstdc++6:i386 lib32z1 lib32ncurses5 lib32bz2-1.0 libxext6:i386 libxrender1:i386 libxtst6:i386 libxi6:i386

Por último deberemos crear un link en el directorio sbin. Por algún motivo el «Network Connect» usa el listado «update-alternatives» para determinar si la versión de 32 bits está instalada y lo busca bajo el directorio /usr/sbin. Para solucionarlo basta con crear el link apuntando a /usr/bin:

$ sudo ln -s /usr/bin/update-alternatives /usr/sbin/

Una vez hechos estos cambios ya podremos utilizar nuestra vpn desde Ubuntu:

 

Referencias:

Anuncio publicitario

Puppet I: Instalación de Puppet Master sobre CentOS

Tenia pendiente realizar algunas pruebas con puppet y para ello me he montado un entorno de pruebas en Vagrant con 2 máquinas virtuales, una será el Master y otra el agente.

Instalación

La instalación es muy sencilla, se instala el paquete de los repositorios de PuppetLabs correspondiente a nuestra distribución y a continuación se instala el paquete puppet-server:

p { margin-bottom: 0.25cm; line-height: 120%; }a:link { }

[root@centos1 ~]# yum install puppet-server 

Configuración

Con estos dos comandos ya tendremos instalado nuestro Puppet Master. A continuación hace falta configurarlo. Para ello nos aseguraremos que nuestro host resuelve correctamente la dirección puppet. Verificaremos que IP tenemos asignada a la red interna y lo configuraremos en el fichero hosts (lo ideal en un entorno productivo es que vaya todo por DNS):
[root@centos1 ~]#  ip addr list
h3.western { font-family: «Liberation Sans»,sans-serif; }h3.cjk { font-family: «Droid Sans Fallback»; }h3.ctl { font-family: «FreeSans»; }p { margin-bottom: 0.25cm; line-height: 120%; }a:link { }
3: eth1: mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 08:00:27:a7:b7:8c brd ff:ff:ff:ff:ff:ff
inet 10.10.10.10/24 brd 10.10.10.255 scope global eth1
inet6 fe80::a00:27ff:fea7:b78c/64 scope link
valid_lft forever preferred_lft forever

[root@centos1 ~]# grep puppet /etc/hosts
10.10.10.10 puppet puppet.localdomain
El servicio puppet master lo configuraremos de forma que arranque con el sistema operativo y lo arrancaremos. Utilizaremos el mismo puppet para configurarlo:
p { margin-bottom: 0.25cm; line-height: 120%; }a:link { }
[root@centos1 ~]# puppet resource service puppetmaster ensure=running enable=true
Notice: /Service[puppetmaster]/ensure: ensure changed ‘stopped’ to ‘running’
service { ‘puppetmaster’:
ensure => ‘running’,
enable => ‘true’,
}
y podemos verificar que se han arrancado los servicios y configurado para el arranque:
 p { margin-bottom: 0.25cm; line-height: 120%; }a:link { }
[root@centos1 ~]# ps -ef | grep -i puppet
puppet 9336 1 0 09:55 ? 00:00:00 /usr/bin/ruby /usr/bin/puppet master
[root@centos1 ~]# service puppetmaster status
puppet (pid 9336) is running…
[root@centos1 manifests]# chkconfig puppetmaster –list
puppetmaster 0:off 1:off 2:on 3:on 4:on 5:on 6:off 
 
[root@centos1 puppet]# netstat -ant | grep 8140
tcp     0     0 0.0.0.0:8140     0.0.0.0:*     LISTEN
El instalador nos habrá creado los usuarios y grupos correspondientes:
  p { margin-bottom: 0.25cm; line-height: 120%; }a:link { }
[root@centos1 puppet]# grep puppet /etc/{passwd,group}
/etc/passwd:puppet:x:52:52:Puppet:/var/lib/puppet:/sbin/nologin
/etc/group:puppet:x:52:
El directorio /var/lib/puppet debe pertenecer al usuario puppet y al grupo puppet:
   p { margin-bottom: 0.25cm; line-height: 120%; }a:link { }
[root@centos1 puppet]# ls -ld /var/lib/puppet/
drwxr-x— 11 puppet puppet 4096 Apr 19 09:55 /var/lib/puppet/
Ya tendremos nuestro servidor de puppet listo, ahora bastará con firmar los certificados de los agentes para empezar a trabajar con ellos.
p { margin-bottom: 0.25cm; line-height: 120%; }a:link { }
[root@centos1 ~]# puppet cert list
«centos2.homestation» (SHA256) 67:6F:54:C7:AE:C7:11:F7:58:75:C2:98:E9:A1:7A:E0:07:EE:A3:D4:38:CD:78:FB:F4:92:0A:07:C9:0C:DC:AA
[root@centos1 ~]# puppet cert sign centos2.homestation
Notice: Signed certificate request for centos2.homestation
Notice: Removing file Puppet::SSL::CertificateRequest centos2.homestation at ‘/var/lib/puppet/ssl/ca/requests/centos2.homestation.pem’
También podriamos haber firmado todos los certificados pendientes con el comando puppet cert sign all.

Testeo

Explicaré tres casos sencillos para probar la instalación de puppet. Se trata de exportar un fichero de configuración, iniciar un servicio y instalar un paquete. En cualquier caso hay que crear un manifiesto indicándole a puppet las acciones a realizar. Los manifiestos se ubican por defecto en el siguiente directorio: /etc/puppet/manifests
  • Compartir fichero: Deberemos editar ademas el fichero /etc/puppet/fileserver.conf indicando el path donde iremos ubicando nuestros ficheros de configuración y quién tiene acceso a ellos:
    p { margin-bottom: 0.25cm; line-height: 120%; }a:link { }
    [root@centos1 puppet]# vi fileserver.conf
    [files]
    path /etc/puppet/files
    allow * 
    A continuación crearemos el manifiesto, que consiste en un fichero con extensión .pp:
      p { margin-bottom: 0.25cm; line-height: 120%; }a:link { }
    [root@centos1 manifests]# cat 1.file.pp
    file { «/etc/motd» : source => «puppet:///files/motd», }
    Para aplicar el manifiesto ejecutaremos: 
    p { margin-bottom: 0.25cm; line-height: 120%; }a:link { }
    [root@centos1 manifests]# puppet apply 1.file.pp
    Notice: Compiled catalog for centos1.homestation in environment production in 0.09 seconds
    Notice: /Stage[main]/Main/File[/etc/motd]/content: content changed ‘{md5}d41d8cd98f00b204e9800998ecf8427e’ to ‘{md5}b3bdce950fdd660ebbdac96fbb02f374’
    Notice: Finished catalog run in 0.09 seconds
    y finalmente verificamos que ha hecho los cambios que le hemos pedido:
    p { margin-bottom: 0.25cm; line-height: 120%; }a:link { }
    [root@centos1 manifests]# cat /etc/motd
    This is a secured system, authorized access 
  • Arrancar un servicio: al igual que en el caso anterior se creará el manifiesto indicando que queremos que el servicio esté habilitado por defecto y que esté arrancado:

[root@centos1 manifests]# cat 2.service.pp
service { «sshd» :
ensure => running,
enable => true,

  • Instalar un paquete: en este manifiesto se indicará el paquete que queremos tener instalado en nuestro sistema. Es posible que el nombre del paquete difiera entre varias distribuciones, para eso es posible hacer filtrados. En este caso sencillo, al conocer donde lo queremos instalar el manifiesto será el siguiente:

[root@centos1 manifests]# cat 3.package.pp
package { «nmap» : ensure => installed, } 

Podemos ver que el ejecutable no está instalado antes de aplicar el manifiesto. Una vez aplicado el cambio ya tenemos disponible la nueva aplicación:

 [root@centos1 manifests]# nmap-bash: nmap: command not found 
[root@centos1 manifests]# puppet apply 3.package.pp
Notice: Compiled catalog for centos1.homestation in environment production in 0.56 seconds
Notice: /Stage[main]/Main/Package[nmap]/ensure: created
Notice: Finished catalog run in 19.49 seconds

[root@centos1 manifests]# nmap -version
Nmap version 5.51 ( http://nmap.org

En proximas entradas comentaré cómo configurar el agente y cómo se instala la interfaz web Puppet Dashboard.

Ubuntu 14.04 y el maldito UEFI

Cada vez que me toca realizar un upgrade de versión de Ubuntu en mi portátil me tengo que pelear con el Boot Manager de UEFI. Mi portátil vino preinstalado con Windows 8 y lo mantuve porque nunca se sabe para que lo puedo necesitar.

La cuestión es que con cada cambio sobre el gestor de arranque hace que o el sistema se quede colgado en el modo rescate de grub o que directamente se salte el grub y entre en Windows.

En la documentación de Ubuntu salen una serie de recomendaciones que no me han servido en ningún caso. Por último recomiendan utilizar el programa Boot repair que en mi caso no me sirvió. Se trata de un arduo proceso de prueba y error hasta que das con la tecla.


En mi caso, al pulsar la tecla F11 arranca el Boot Manager donde me permite arrancar Ubuntu o Windows (en el menú aparece como OS Boot Manager :-O):

Descubrí la herramienta efibootmgr que permite solucionar el problema con unos pocos comandos. Voy con el ejemplo:

  • Listado de los sistemas instalados en mi portátil, donde se muestra el orden de arranque y como se ve arranca directamente en el Windows Boot Manager:

root@jupiter:# efibootmgr -v
BootCurrent: 0002
Timeout: 0 seconds
BootOrder: 3002,3000,3001,3003,3004,3005,2001,2002,2003
Boot0000* ubuntu    HD(2,c8800,82000,882c04c8-a541-4a44-aeaa-522da6211d8d)File(\EFI\ubuntu\shimx64.efi)
Boot0001* Ubuntu    HD(2,c8800,82000,882c04c8-a541-4a44-aeaa-522da6211d8d)File(\EFI\ubuntu\grubx64.efi)RC
Boot0002* Windows Boot Manager    HD(2,c8800,82000,882c04c8-a541-4a44-aeaa-522da6211d8d)File(\EFI\Microsoft\Boot\bootmgfw.efi)RC
Boot0003* Ubuntu    HD(2,c8800,82000,882c04c8-a541-4a44-aeaa-522da6211d8d)File(\EFI\ubuntu\grubx64.efi)RC
Boot0004* Ubuntu    HD(2,c8800,82000,882c04c8-a541-4a44-aeaa-522da6211d8d)File(\EFI\ubuntu\grubx64.efi)RC
Boot0005* Ubuntu    HD(2,c8800,82000,882c04c8-a541-4a44-aeaa-522da6211d8d)File(\EFI\ubuntu\grubx64.efi)RC
Boot2001* USB Drive (UEFI)    RC
Boot3000* Internal Hard Disk or Solid State Disk    RC
Boot3001* Internal Hard Disk or Solid State Disk    RC
Boot3002* Internal Hard Disk or Solid State Disk    RC
Boot3003* Internal Hard Disk or Solid State Disk    RC
Boot3004* Internal Hard Disk or Solid State Disk    RC
Boot3005* Internal Hard Disk or Solid State Disk    RC

  • Para limpiar el orde de arranque se ejecuta efibootmgr con la opción -O.
  • Establezco de nuevo el orden que yo quiero con el siguiente comando:

 root@jupiter:# efibootmgr -o 0000,0001,0002

  • También cambié el fichero de arranque de EFI de Windows, lo vi comentado en stackoverflow, pero creo que realmente no hacia falta:

 root@jupiter:# cd /boot/efi/EFI/Microsoft/Boot/
 root@jupiter:# mv bootmgfw.efi bootmgfwB.efi
 root@jupiter:#  cp ../../ubuntu/grubx64.efi bootmgfw.efi

Espero que este post me sirva para acordarme de lo que hice la última vez! 

Upgrade zpool

Cada vez que se parchea un servidor o se sube la release es muy probable que exista una nueva versión de ZFS. Por ello, si queremos tener las nuevas características y funcionalidades deberemos actualizar nuestros zpools. Para ello basta con lanzar el comando zpool upgrade . Podemos ver en la ayuda las diferentes versiones que disponemos en nuestro sistema:


root@server1 # zpool help upgrade

usage:
        upgrade
        upgrade -v
        upgrade [-V version]

root@server1 # zpool upgrade -v
This system is currently running ZFS pool version 32.

The following versions are supported:

VER  DESCRIPTION
—  ——————————————————–
 1   Initial ZFS version
 2   Ditto blocks (replicated metadata)
 3   Hot spares and double parity RAID-Z
 4   zpool history
 5   Compression using the gzip algorithm
 6   bootfs pool property
 7   Separate intent log devices
 8   Delegated administration
 9   refquota and refreservation properties
 10  Cache devices
 11  Improved scrub performance
 12  Snapshot properties
 13  snapused property
 14  passthrough-x aclinherit
 15  user/group space accounting
 16  stmf property support
 17  Triple-parity RAID-Z
 18  Snapshot user holds
 19  Log device removal
 20  Compression using zle (zero-length encoding)
 21  Reserved
 22  Received properties
 23  Slim ZIL
 24  System attributes
 25  Improved scrub stats
 26  Improved snapshot deletion performance
 27  Improved snapshot creation performance
 28  Multiple vdev replacements
 29  RAID-Z/mirror hybrid allocator
 30  Reserved
 31  Improved ‘zfs list’ performance
 32  One MB blocksize

For more information on a particular version, including supported releases,
see the ZFS Administration Guide.
Si utilizamos únicamente el comando zpool upgrade nos muestra la versión que está corriendo actualmente y la versión con la que se creó el pool, con lo que será posible actualizarlo:

root@server1 # zpool upgrade 
This system is currently running ZFS pool version 32.

The following pools are out of date, and can be upgraded.  After being
upgraded, these pools will no longer be accessible by older software versions.

VER  POOL
—  ————
29   test-zpool

Use ‘zpool upgrade -v’ for a list of available versions and their associated
features.

Para actualizar el pool lo haremos de la siguiente forma:

root@server1 # zpool upgrade -V 32 test-zpool
This system is currently running ZFS pool version 32.

Successfully upgraded ‘test-zpool’ from version 29 to version 32
Se puede verificar que todos los pools están a la última versión:

root@server1 # zpool upgrade 
This system is currently running ZFS pool version 32.

All pools are formatted using this version.

Identificar zona global

En Solaris es posible crear zonas que no son mas que «particiones» del sistema operativo. Desde la zona Global, el equivalente a un ESXi en VMware, puede acceder a los procesos y sistemas de ficheros de las zonas. No así desde una zona, que están aisladas unas de otras y es imposible acceder a la zona global desde una zona. Es mas, es muy difícil identificar la zona global sobre la que esta corriendo una zona en concreto.

Para hacer mas fácil esta identificación he montado un script que lo que hace es generar un fichero /etc/GLOBALZONE en cada una de las zonas con el nombre de la zona:

#!/usr/bin/python

#
# zoneadm list output
# zoneadm list -cv
#  ID NAME             STATUS     PATH                           BRAND    IP    
#   0 global           running    /                              native   shared
#   5 zona1      running    /zonas/zona1             native   shared
#   7 zona2      running    /zonas/zona2             native   shared
#   – zona3      installed  /zonas/zona3             native   shared
#
#
from subprocess import *

p = Popen([‘hostname’], stdout=PIPE, stderr=PIPE)
hostname, err = p.communicate() 

p = Popen([‘zoneadm’, ‘list’, ‘-cv’], stdout=PIPE, stderr=PIPE)
zoneList, err = p.communicate()

for zone in zoneList.splitlines():
name = zone.split()[1]
if (name ==’NAME’) or (name == ‘global’): continue
cfgfile = «/zonas/%s/root/etc/GLOBALZONE» % name
try:
f = open(cfgfile, «w»)
f.write(hostname)
f.close()
except:
pass
El script lo he configurado en el cron para que se ejecute cada hora por ejemplo. De esta forma, si creo alguna zona nueva, o si muevo una zona de un servidor a otro, este fichero se actualizará.

También se puede modificar el perfil del usuario, de modo que el nombre de la zona global aparezca en la variable PS1:
PS1 = "\u@\h \w (`cat /etc/GLOBALZONE`) $ "

Widgets en Ubuntu: Conky

Hoy me he encontrado con una aplicación que nos permite tener unos widgets perfectamente integrados con el escritorio de Unity en Ubuntu. Se trata de Conky. Lo he probado y me parece mucho mas ligero que otros que había utilizado antes, y ademas, parece que hay muchos temas disponibles en internet. Para instalarlo simplemente basta con instalarlo desde el Ubuntu Software Center o desde un terminal:
sudo apt-get install conky-all
En la documentación oficial de Ubuntu indica como se puede configurar tocando un fichero de configuración. Sin embargo existe un programa que nos puede servir de gran ayuda. Este es Conky Manager y para instalarlo, desde un terminal añadimos el PPA y lo instalamos:
sudo apt-add-repository ppa:teejee2008/ppa
sudo apt-get update
sudo apt-get install conky-manager
Una vez instalado se puede lanzar desde el panel de Unity. Es un programa muy sencillo que nos permite seleccionar los widgets y temas que queremos tener habilitados y dependiendo del seleccionado alguna opción adicional. Permite ademas configurar opciones como la transparencia o la posición del widget. Ademas existe la opción de habilitar el arranque automático con el sistema.
Resumiendo, me parece una muy buena opción para tener un escritorio mucho mas interesante. Estos son algunos de los widgets que yo me he puesto:
Existe un paquete de temas que se puede importar desde la aplicación. Se puede descargar aqui.

Mis entrevistas con Facebook

«Success is not final, failure is not fatal; it is the courage to continue that counts.» slidesha.re/18IDRZY

Hace unas semanas recibí un mensaje de LinkedIn. El remitente era una reclutadora de Facebook, donde me comentaba que tenian algunas vacantes en las que podría encajar. Como no tenía nada que perder accedí a hablar con ella.

Es conocido que los gigantes de internet tienen unos procesos de selección muy duros con infinidad de entrevistas. En mi caso únicamente fueron dos, ambas por teléfono. Voy a contar un poco mi experiencia por si le puede servir a alguien que esté interesado en un trabajo en este tipo de empresas.

Yo no me apunté a ninguna oferta en la web de Facebook ni nada parecido. Únicamente mantengo actualizado mi perfil de LinkedIn y parece ser que tras la útlima actualización, puse las palabras clave que buscan los reclutadores. La reclutadora de Facebook me encontro, sin yo buscarlo, con lo que me pareció interesante seguir con el proceso.

Una vez revisó mi curriculum me pidió si podríamos tener una entrevista telefónica. En un principio estuve dudando puesto que la entrevista sería en ingles y mi ingles es peor que el de Ana Botella. Finalmente quedamos un día y me llamó. La reclutadora fué muy amable en todo momento, y por suerte, al no ser irlandesa, le entendía lo suficiente para mantener la conversación.

La entrevista estaba dividida en dos partes, la primera mas orientada en la descripción del puesto, las tareas, como estaban organizados, etc. La segunda parte consistió en preguntas básicas de networking y linux, todas muy básicas aunque alguna muy rebuscada.

En la primera parte me explicó que el puesto que buscaban era un SRO (Site Reliability Operations) para el equipo de Dublín. El equipo de SRO es el que se encarga de mantener la infraestructura de Facebook, con lo que pensé que mi perfil se ajustaba perfectamente, puesto que es lo que hago actualmente pero a gran escala. También hizo especial énfasis en lenguajes de programación y scripting, especialmente python. En mi trabajo suelo programar algunos scripts, pero tampoco es mi principal tarea. Parece que eso no le acabó de gustar.

Al finalizar la primera parte empezó a hacerme un pequeño cuestionario sobre diferentes temas. A nivel de networking las preguntas fueron muy básicas: que puertos utilizan los servicios típicos (ssh, dns, http), que tipo de paquetes se envian para establecer una conexión TCP, que es la MTU o como detectar que se pierden paquetes en una red. Sobre linux me preguntó cosas como que significaban los números que aparecen en la salida del comando uptime, el significado de $*, $$, $?; como se chequean errores de disco y luego algunas preguntas sobre señales entre procesos. Esto último lo tenia bastante verde y creo que es lo único en lo que falle.

Cuando terminó el cuestionario me dijo que habíamos terminado y que si quería preguntarle algo. Me pilló algo desprevenido y no había preparado nada. Eso creo que tampoco le gustó, ya que deben pensar que no estas interesado en el puesto, con lo que recomiendo tener algunas preguntas preparadas para preguntarle al reclutador. Esta entrevista duró unos 20 minutos y la verdad es que tuve buenas sensaciones puesto que la mayoría de preguntas técnicas las había respondido con soltura.

A los dos días recibí un mail diciendo que lo sentian mucho pero que mi perfil no se ajustaba a lo que estaban buscando. Pensé que se habría acabado, pero al día siguiente me llamó de nuevo la reclutadora diciendome que un manager había visto mi curriculum y que le había interesado mi experiencia como sysadmin. Parece ser que lo que buscaban inicialmente era un experto en python y con mas experiencia en programación pero que tenían alguna otra vacante en la que si podría encajar.

Al dia siguiente me envió otro mail pidiendome cuando podría hacer una segunda entrevista con un SRO y ademas me dió algunas recomendaciones, sobre todo que preparase preguntas para demostrarle interes.

Finalmente me llamó el SRO y ya empezó mal la cosa. Entre mi mal ingles y que se le oia fatal, puesto que estaba en un sitio con bastante ruido y con un manos libres, era dificil entenderlo. Me explicó en que iba a consistir la entrevista, varias preguntas de networking, otras tantas de linux y solucionar algunos casos prácticos.

Para esta segunda entrevista me esperaba un tipo de preguntas y al final fueron diferentes, llegando a muy bajo nivel. Preguntas sobre cómo funciona el comando traceroute, que le puedes explicar que sirve para conocer la ruta que siguen los paquetes en la conexión entre dos hosts. Sin embargo, lo que quería era una descripción de que tipo de paquetes se enviaba, el TTL de cada paquete, porque pasaba por un router y no por otro, etc.

Las preguntas sobre linux estaban enfocadas a los procesos. Que estados puede tener un proceso, que señales se le pueden enviar, que implica que un proceso sea zombie. Fueron muchas preguntas sobre señales que en realidad, a la hora de administrar servidores, no las utilizo mucho y como en la primera entrevista dejé mucho que desear.

Los casos prácticos se basaron en como reiniciar un servidor remotamente desde una consola y como recuperar la password de root de un servidor. La verdad que creo que le respondí como debía pero parece que él lo hubiese hecho de otra manera, quizás porque el conoce su infraestructura y como lo tienen montado y yo estaba a ciegas y respondía de forma algo mas genérica.

Finalmente, para terminar la entrevista me preguntó si quería hacerle algunas preguntas. Las típicas preguntas que sabía que le iba a hacer las tenia bien preparadas y estudiadas y sabía hasta donde podía decirme. Luego le hice alguna pregunta mas técnica y me dijo que no podía responderme ni darme detalles.

Al dia siguiente de la entrevista con el SRO recibí otro mail de la reclutadora diciendome que no seguia. Despues de la entrevista con el SRO sabía que iba a ser ese el resultado así que no me sorprendió demasiado.

Como recomendaciones para alguien que esté interesado en participar en un proceso parecido me quedo con esto:

 Algunos enlaces interesantes:

Instalación y configuración de Pure-ftp en Solaris 10

Pure-FTP es un servidor FTP muy potente y que permite facilmente configurar cosas que con el cliente que viene por defecto en Solaris es mas complicado, por ejemplo, enjaular usuarios.

En el repositorio de openCSW (http://www.opencsw.org) existe el paquete y las dependencias de pureFTPd, con lo que no es necesario compilar las fuentes. Para poder instalarlo en varios sistemas creo un paquete con el software y todas sus dependencias. Suponiendo que ya tenemos la aplicación pkgutil instalada en un sistema con acceso a internet, crearemos el paquete de la siguiente forma:

# PATH=$PATH:/opt/csw/bin/
# pkgutil –stream –target=i386:5.10 –output pure-ftp-dep.pkg –yes –download pureftpd
Solving needed dependencies …
Solving dependency order …
Package list:
        CSWcacertificates-20120511,REV=2012.05.11 (opencsw/testing)
        CSWcas-migrateconf-1.47,REV=2012.02.14 (opencsw/testing)
        CSWcas-preserveconf-1.42,REV=2010.11.26 (opencsw/testing)
        CSWcommon-1.5,REV=2010.12.11 (opencsw/testing)
        CSWlibssl0-9-8-0.9.8x,REV=2012.05.12 (opencsw/testing)
        CSWosslrt-0.9.8x,REV=2012.05.12 (opencsw/testing)
        CSWpureftpd-1.0.27,REV=2010.01.23 (opencsw/testing)
Total size: 4.3 MB
Esta utilidad ademas proporciona los comandos para instalar todo el software de forma correcta:
Install commands in dependency safe order:

pkgadd -d pure-ftp-dep.pkg CSWcommon
pkgadd -d pure-ftp-dep.pkg CSWcas-preserveconf
pkgadd -d pure-ftp-dep.pkg CSWcas-migrateconf
pkgadd -d pure-ftp-dep.pkg CSWcacertificates
pkgadd -d pure-ftp-dep.pkg CSWlibssl0-9-8
pkgadd -d pure-ftp-dep.pkg CSWosslrt
pkgadd -d pure-ftp-dep.pkg CSWpureftpd
Una vez instalado el software pasaremos a configurarlo. Lo primero que deberemos hacer es crear un grupo y un usuario que será el que utilice la aplicación con los usuarios virtuales.
# groupadd pftpgroup
# useradd -g pftpgroup -d /dev/null -s /bin/false pftpuser
Crearemos ademas los directorios necesarios para la aplicación. En mi caso creare un directorio /ftp donde irán todas las cuentas de usuario. También será necesario crear un directorio donde se ubicarán los ficheros de configuración del servidor.

# mkdir /ftp
# mkdir  -p /opt/csw/etc/pure-ftpd/
Una vez instalada ya podemos utilzar los comandos que proporciona pure-ftp. El principal comando para trabajar con usuarios es pure-pw. Con este comando podemos crear, modificar y borrar usuarios. Nos permitirá establecer cuotas, tamaños de ficheros, horarios de conexión, etc. Existe otra utilidad que nos permitirá convertir todos los usuarios de sistema al formato que utiliza pureftp. Para convertirlos lo haremos de la siguiente forma:
(Añadimos los directorios donde se encuentran los binarios al PATH para mayor comodidad)

PATH=$PATH:/opt/csw/bin:/opt/csw/sbin
# pure-pwconvert >> /opt/csw/etc/pure-ftpd/pureftpd.passwd
# pure-pw mkdb /opt/csw/etc/pure-ftpd/pureftpd.pdb
Entre los metodos de autenticación que permite pure-FTP utilizaremos el metodo puredb. Este método hace uso de dos ficheros, el pureftpd.passwd, que tiene un formato similar al /etc/passwd. El otro es el fichero binario que utliza pure-FTP para leer la configuración de usuarios, haciendolo que sea mas rápido que el acceso a un fichero de texto. Por tanto, cada vez que se modifica el fichero pureftpd.passwd porque se ha añadido/borrado/modificado algún usuario, es necesario confirmar los cambios en el fichero pureftpd.pdb con el comando pure-pw mkdb. Como veremos mas adelante, este último paso nos lo podemos ahorrar con el parámetro -m cuando hagamos algúna modificación de usuarios. Estos cambios siempre serán en caliente, con lo que no será necesario reiniciar el servidor de FTP.
A partir de este momento ya podemos arrancar el servidor, de la siguiente forma:

/opt/csw/sbin/pure-ftpd -j -A -lpuredb:/opt/csw/etc/pure-ftpd/pureftpd.pdb

Con la opción -j se creará el directorio home del usuario en caso de que no exista y con la opción -d le indicamos que todos los usuarios deben estar enjaulados en su home y no pueden salirse de ahí (chroot).
Veamos ahora como trabajar con usuarios con el comando pure-pw. Este comando tiene varias opciones, entre ellas useradd, usermod y userdel para añadir, modificar y borrar usuarios, respectivamente. Para crear un usuario lo haremos de la siguiente forma:

pure-pw useradd joe -u pftpuser -d /ftp/joe
Password: 
Enter it again: 
Como hemos comentado antes, los cambios se deberán aplicar en el fichero pureftpd.pdb.

pure-pw mkdb /opt/csw/etc/pure-ftpd/pureftpd.pdb
Podemos modificar también algunos parámetros como el límite del tamaño de fichero que el usuario puede subir o bajar al ftp:

pure-pw usermod joe -N 10

Si queremos aplicar directamente este cambio en el fichero pureftpd.pdb utilizaremos la opción -m:

pure-pw usermod joe -N 3 -m

Otra opción interesante es la de aplicar un horario de conexión permitido:

# pure-pw usermod joe -z 0900-1800 -> conexión de 09h a 18h
pure-pw usermod joe -z » -> deshabilitar el control horario
pure-pw usermod joe -z 0000-0000 -> no permite las conexiones para ese usuario
Con la opción show del comando pure-pw podemos ver información del usuario: 

pure-pw show joe
Login              : joe
Password           : $2a$07$E3eQ4sJhytw.DOz3yEHIxuq34.Omp6MwIA0ZlUFagosFqqO/HOUvO
UID                : 102 (ftpuser)
GID                : 100 (ftpgroup)
Directory          : /ftp/joe/./
Full name          : 
Download bandwidth : 0 Kb (unlimited)
Upload   bandwidth : 0 Kb (unlimited)
Max files          : 0 (unlimited)
Max size           : 10 Mb (enabled)
Ratio              : 0:0 (unlimited:unlimited)
Allowed local  IPs : 
Denied  local  IPs : 
Allowed client IPs : 
Denied  client IPs : 
Time restrictions  : 0900-1800 (enabled)
Max sim sessions   : 0 (unlimited)
Para hacer mas cómoda el arranque y parada del servidor pure-FTP se puede crear un servicio de Solaris. Para ello crearemos el manifiesto y el metodo:

  • pure-ftp-manifest.xml
 
   
   
   
     
   
   
     
   
   
     
   
   
     
   
   
     
   
   
     
   
   
     
        Pure-ftp Service
     
     
        Pure-ftp service
     
   
 

  • pure-ftp-method
#!/sbin/sh
#
# Julian Garcia-Sotoca Pascual 16/07/2013
#

. /lib/svc/share/smf_include.sh

case «$1» in
start)
        /opt/csw/sbin/pure-ftpd \
–altlog /var/log/pure-ftpd.log \
–verboselog \
–login puredb:/opt/csw/etc/pure-ftpd/pureftpd.pdb \
–noanonymous \
–maxclientsnumber 100 \
–chrooteveryone \
–ipv4only \
–pidfile /var/run/pure-ftpd.pid \
–daemonize 2>&1 >/dev/null
        ;;
stop)
        /usr/bin/pkill pure-ftpd 2>&1 >/dev/null
        exit 0
        ;;
*)
        echo «Usage: $0 { start | stop }»
        exit 1
        ;;
esac
exit 0
Como vemos, se arrancará el servicio añadiendo algunas opciones mas, para que cree un fichero de log, otro con el pid y que trabaje en modo demonio, por ejemplo. Para realizar la instalación mas automatizada he creado el siguiente script:

  • inst_pureFTP.sh
:

echo «Deshabilitar FTP de solaris»
svcadm disable svc:/network/ftp:default
svcs -a | grep network/ftp:default
echo «Pulse intro para continuar»
read
clear

echo «Instalando pure-FTP»
pkgadd -d pure-ftp-dep.pkg CSWcommon
pkgadd -d pure-ftp-dep.pkg CSWcas-preserveconf
pkgadd -d pure-ftp-dep.pkg CSWcas-migrateconf
pkgadd -d pure-ftp-dep.pkg CSWcacertificates
pkgadd -d pure-ftp-dep.pkg CSWlibssl0-9-8
pkgadd -d pure-ftp-dep.pkg CSWosslrt
pkgadd -d pure-ftp-dep.pkg CSWpureftpd
echo «Pulse intro para continuar»
read
clear

echo «Creacion usuario ftp»
groupadd pftpgroup
useradd -g pftpgroup -d /dev/null -s /bin/false pftpuser
echo «Pulse intro para continuar»
read
clear

echo «Creando directorios»
mkdir /ftp
mkdir -p /opt/csw/etc/pure-ftpd/
echo «Pulse intro para continuar»
read
clear

PATH=$PATH:/opt/csw/bin:/opt/csw/sbin

echo «Importando usuarios»
echo «IMPORTANTE: los usuarios que se quieren migrar deben tener shell y home»
pure-pwconvert >> /opt/csw/etc/pure-ftpd/pureftpd.passwd
pure-pw mkdb /opt/csw/etc/pure-ftpd/pureftpd.pdb
echo «Usuarios importados:»
cut -d: -f1 /opt/csw/etc/pure-ftpd/pureftpd.passwd
echo «Pulse intro para continuar»
read
clear

echo «Instalando servicio»
cp pure-ftp-manifest.xml /var/svc/manifest/site
cp pure-ftp-method /lib/svc/method/pure-ftp
chmod u+x /lib/svc/method/pure-ftp
svccfg -v import /var/svc/manifest/site/pure-ftp-manifest.xml
svcs -a | grep pure-ftp
echo «Pulse intro para continuar»
read
clear

Upgrade de versión Servidor Solaris 11

Con la llegada de Solaris 11 ya se puede subir la versión de «release» fácilmente. Hasta ahora, en Solaris 10, si queríamos pasar del «Update X» al «Update Y» había que reinstalar el servidor. El instalador detectaba que existía una versión instalada y daba la opción de subir de «release«. En Solaris 11 sin embargo, gracias al gestor de paquetes que tiene es mucho mas fácil y el tiempo de parada se ha disminuido al máximo.

 

Veamos como se haría en el siguiente ejemplo. Tenemos un servidor con los siguientes datos:
  • Release:
# more /etc/release 
             Oracle Solaris 11 11/11 X86 
Copyright (c) 1983, 2011, Oracle and/or its affiliates. 
     All rights reserved. Assembled 18 October 2011 

  • Uname:

# uname -a 
SunOS HOSTNAME 5.11 11.0 i86pc i386 i86pc 
  • Kernel:
# pkg info system/kernel 
          Name: system/kernel 
       Summary: Core Kernel 
   Description: Core operating system kernel, device drivers and other modules. 
      Category: System/Core 
         State: Installed 
     Publisher: solaris 
       Version: 0.5.11 
 Build Release: 5.11 
        Branch: 0.175.0.11.0.4.1 
Packaging Date: 30 de agosto de 2012 14:21:42 
          Size: 32.04 MB 
          FMRI: pkg://solaris/system/kernel@0.5.11,5.11-0.175.0.11.0.4.1:20120830T142142Z
  • Entire:
# pkg info entire 
         Name: entire 
      Summary: entire incorporation including Support Repository Update (Oracle Solaris 11 11/11 SRU 11.4). 
  Description: This package constrains system package versions to the same 
               build. WARNING: Proper system update and correct package 
               selection depend on the presence of this incorporation. 
               Removing this package will result in an unsupported system. For
               more information see https://support.oracle.com/CSP/main/article 
               ?cmd=show&type=NOT&doctype=REFERENCE&id=1372094.1. 
     Category: Meta Packages/Incorporations 
        State: Installed 
    Publisher: solaris 
      Version: 0.5.11 (Oracle Solaris 11 SRU 11.4) 
Build Release: 5.11 Branch: 0.175.0.11.0.4.1 
Packaging Date: 1 de septiembre de 2012 01:14:39 
          Size: 5.45 kB 
          FMRI: pkg://solaris/entire@0.5.11,5.11-0.175.0.11.0.4.1:20120901T011439Z 
  • Boot Environments:
root@solaris11repo:~# beadm list 
BE Active Mountpoint Space Policy Created 
— —— ———- —– —— ——- 
solaris-1 NR / 10.82G static 2012-10-10 16:26

Como vemos actualmente tenemos la versión 5.11 SRU 11.4. Procedemos a lanzar el parcheo del servidor indicando que cree un nuevo Boot Environment:

# pkg update –require-new-be –be-name SolarisU11.1 –accept
———————————————————— 

Package: pkg://solaris/consolidation/osnet/osnet-incorporation@0.5.11,5.11-0.175.1.0.0.24.2:20120919T184141Z 
License: usr/src/pkg/license_files/lic_OTN 

Oracle Technology Network Developer License Agreement 

Oracle Solaris, Oracle Solaris Cluster and Oracle Solaris Express 

… 

Oracle may contact you to ask if you had a satisfactory experience installing and using this OTN software download. 

            Packages to remove: 1 
           Packages to install: 36 
            Packages to update: 455 
           Mediators to change: 2 
       Create boot environment: Yes 
Create backup boot environment: No 
DOWNLOAD                      PKGS         FILES        XFER (MB) 
Completed                  492/492   25247/25247      467.8/467.8 
PHASE                                    ACTIONS 
Removal Phase                          8164/8164 
Install Phase                        17909/17909 
Update Phase                         14639/14639 
PHASE                                      ITEMS 
Package State Update Phase               945/945 
Package Cache Update Phase               455/455 
Image State Update Phase                     2/2 
A clone of solaris-1 exists and has been updated and activated. 
On the next boot the Boot Environment SolarisU11.1 will be 
mounted on ‘/’. Reboot when ready to switch to this updated BE. 

The following unexpected or editable files and directories were 
salvaged while executing the requested package operation; they 
have been moved to the displayed location in the image: 

    var/crash -> /tmp/tmpa0wceg/var/pkg/lost+found/var/crash-20121029T111717Z 

————————————————————————— 

—————————————————————————  

Se ha creado un nuevo «Boot Environment» donde se ha realizado el upgrade de versión y que se ha activado para el próximo reinicio:

# beadm list 
BE Active Mountpoint Space Policy Created 
— —— ———- —– —— ——- 
SolarisU11.1 R – 7.41G static 2012-10-29 11:11 
solaris-1 N / 525.0K static 2012-10-10 16:26
Una vez reiniciado y arrancado con el nuevo «Boot Environment» podemos realizar las mismas comprobaciones que al inicio y veremos como estamos en una nueva ««Release» de Solaris 11, la 11.1:

  • Release

# cat /etc/release 
                           Oracle Solaris 11.1 X86 
Copyright (c) 1983, 2012, Oracle and/or its affiliates. All rights reserved. 
                         Assembled 19 September 2012

  • Uname

# uname -a 
SunOS solaris11repo 5.11 11.1 i86pc i386 i86pc

  • Kernel

# pkg info system/kernel 
          Name: system/kernel 
       Summary: Core Kernel 
   Description: Core operating system kernel, device drivers and other modules. 
      Category: System/Core 
         State: Installed 
     Publisher: solaris 
       Version: 0.5.11 
 Build Release: 5.11 
        Branch: 0.175.1.0.0.24.2 
Packaging Date: 19 de septiembre de 2012 18:50:11 
          Size: 32.59 MB 
          FMRI: pkg://solaris/system/kernel@0.5.11,5.11-0.175.1.0.0.24.2:20120919T185011Z

  • Entire

# pkg info entire 
          Name: entire 
       Summary: Incorporation to lock all system packages to the same build
   Description: This package constrains system package versions to the same
                build. WARNING: Proper system update and correct package
                selection depend on the presence of this incorporation. 
                Removing this package will result in an unsupported system. 
      Category: Meta Packages/Incorporations 
         State: Installed 
     Publisher: solaris 
       Version: 0.5.11 
 Build Release: 5.11 
        Branch: 0.175.1.0.0.24.2 
Packaging Date: 19 de septiembre de 2012 19:01:35 
          Size: 5.46 kB 
          FMRI: pkg://solaris/entire@0.5.11,5.11-0.175.1.0.0.24.2:20120919T190135Z

En el caso de que deseemos actualizar el servidor que contiene nuestro repositorio para poder actualizar el resto de nuestra infraestructura, deberemos primero realizar el upgrade sobre este servidor. A continuación, ya se podría actualizar el repositorio para tener los paquetes de la última Release:

  • Desde los repositorios de release (publicos de Oracle)

# pkgrecv -s http://pkg.oracle.com/solaris/release/ -d /export/repoSolaris11 ‘*’ 

Processing packages for publisher solaris… 
Retrieving and evaluating 4401 package(s)… 
PROCESS                                       ITEMS   GET (MB)    SEND (MB) 
Completed                                 1270/1270  5894/5894  19638/19638

  • Desde los repositorios de Soporte (es necesario un CSI activo):

# pkgrecv -s https://pkg.oracle.com/solaris/support/ -d /export/repoSolaris11\ –key /var/pkg/ssl/Oracle_Solaris_11_Support.key.pem \ –cert /var/pkg/ssl/Oracle_Solaris_11_Support.certificate.pem ‘*’ 
Processing packages for publisher solaris … 
Retrieving and evaluating 4414 package(s)… 

PROCESS                                      ITEMS     GET (MB)   SEND (MB) 
Completed                                      6/6      4.5/4.5   12.0/12.0

Crear repositorio local solaris 11

Una de las novedades de Solaris 11 con respecto a sus versiones anteriores es la utilización, por fin, de un sistema de gestión de paquetes parecido a los disponibles en linux. Este sistema permite la instalación de software de manera sencilla, conectandose a un repositorio (por defecto el de Oracle) de donde baja el software y todas sus dependencias. Ya no es necesario bajarse el paquete, revisar las dependencias, bajarse las dependencias, revisar a su vez las dependencias de las primeras, etc, etc…
Si solo vamos a tener unos pocos servidores será suficiente con mantener el repositorio de Oracle. En cambio, si vamos a tener una gran instalación puede interesar montar un repositorio local. De esta forma, el repositorio estará sincronziado con el de Oracle y los servidores no necesitarán conectarse a internet para la instalación de software. 
El aprovisionado de zonas también es mas rápido ya que en Solaris 11 es necesario la conexión al repositorio, haciendo que sea mas rápido si está en la red local.
Para la instalación del repositorio bajamos las imágenes ISO que ofrece Oracle desde su web de descargas. Son necesarias dos imágenes ISO que deberemos concatenarlas y montarlas en un directorio:

# cat sol-11-1111-repo-full.iso-a sol-11-1111-repo-full.iso-b > sol-11-1111-repo-full.iso
# mkdir /export/repoSolaris11
# mv sol-11-1111-repo-full.iso /export/repoSolaris11/
# mount -F hsfs /export/repoSolaris11/sol-11-1111-repo-full.iso /mnt
# ls /mnt
COPYRIGHT NOTICES README repo

A continuación se deberá sincronizar el contenido de la ISO con el directorio que servirá como repositorio:  

# rsync -aP /mnt/repo/ /export/repoSolaris11
sending incremental file list
./
pkg5.repository

240 100% 0.00kB/s 0:00:00 (xfer#1, to-check=1378/1380)

publisher/
publisher/solaris/
publisher/solaris/catalog/
publisher/solaris/catalog/catalog.attrs

1250 100% 23.94kB/s 0:00:00 (xfer#2, to-check=1369/1380)

publisher/solaris/catalog/catalog.base.C

602328 100% 6.24MB/s 0:00:00 (xfer#3, to-check=1368/1380)

publisher/solaris/catalog/catalog.dependency.C

Una vez haya terminado de sincronizar podemos desmontar la ISO:

root@s11template:/var/tmp# umount /mnt

    Con el contenido ya en su ubicación final es momento de crear el indice del repositorio:

    # pkgrepo -s /export/repoSolaris11 refresh
    Initiating repository refresh

      El repositorio hara uso de servicios que deberán ser configurados adecuadamente para que sirvan correctamente el software. El servicio publisher se configurará de la siguiente manera para hacer accesible el repositorio por http:

      # svccfg -s application/pkg/server setprop pkg/inst_root=/export/repoSolaris11
      # svccfg -s application/pkg/server setprop pkg/readonly=true
      # svcprop -p pkg/inst_root application/pkg/server /export/repoSolaris11

        Podemos verificar que se han guardado los cambios en la configuración y a continuación aplicar las modificaciones refrescando el servicio:

          # svcprop application/pkg/server
          pkg/address net_address
          pkg/cfg_file astring «»
          pkg/content_root astring usr/share/lib/pkg
          pkg/debug astring «» pkg/file_root astring «»
          pkg/log_access astring none
          pkg/log_errors astring stderr
          pkg/mirror boolean false
          pkg/pkg_root astring /
          pkg/port count 80
          pkg/proxy_base astring «»
          pkg/socket_timeout count 60
          pkg/sort_file_max_size astring «»
          pkg/ssl_cert_file astring «»
          pkg/ssl_dialog astring smf
          pkg/ssl_key_file astring «»
          pkg/threads count 60
          pkg/writable_root astring «»
          pkg/inst_root astring /export/repoSolaris11
          pkg/readonly boolean true
          pkg_bui/feed_description ustring «»
          pkg_bui/feed_icon ustring web/_themes/pkg-block-icon.png
          pkg_bui/feed_logo ustring web/_themes/pkg-block-logo.png
          pkg_bui/feed_name ustring package\ repository\ feed
          pkg_bui/feed_window count 24
          pkg_secure/read_authorization astring solaris.smf.read.pkg-server
          pkg_secure/ssl_key_passphrase astring «»
          fs/entities fmri svc:/system/filesystem/local
          fs/grouping astring require_all
          fs/restart_on astring none
          fs/type astring service
          autofs/entities fmri svc:/system/filesystem/autofs
          autofs/grouping astring optional_all
          autofs/restart_on astring none
          autofs/type astring service
          ntp/entities fmri svc:/network/ntp
          ntp/grouping astring optional_all
          ntp/restart_on astring none
          ntp/type astring service
          network/entities fmri svc:/milestone/network
          network/grouping astring require_all
          network/restart_on astring none
          network/type astring service
          manifestfiles/lib_svc_manifest_application_pkg_pkg-server_xml astring /lib/svc/manifest/application/pkg/pkg-server.xml
          general/entity_stability astring Unstable
          start/exec astring %{pkg/pkg_root}/lib/svc/method/svc-pkg-depot\ %m
          start/timeout_seconds count 0
          start/type astring method
          stop/exec astring %{pkg/pkg_root}/lib/svc/method/svc-pkg-depot\ %m\ %{restarter/contract}
          stop/timeout_seconds count 30
          stop/type astring method tm_common_name/C ustring image\ packaging\ repository

          # svcadm refresh application/pkg/server
          # svcadm enable application/pkg/server

            Con esto ya esta el servicio configurado. Ahora, al propio servidor se le puede configurar el publisher local como repositorio principal:

            # pkg set-publisher -G ‘*’ -M ‘*’ -g http://localhost:80/ solaris
            # pkg publisher
            PUBLISHER TYPE STATUS URI
            solaris origin online http://localhost:80/

              Si quisieramos volver al repositorio de Oracle:

              # pkg set-publisher \
              > -k /var/pkg/ssl/Oracle_Solaris_11_Support.key.pem \
              > -c /var/pkg/ssl/Oracle_Solaris_11_Support.certificate.pem \
              > -g https://pkg.oracle.com/solaris/support/ \
              > -G http://pkg.oracle.com/solaris/release/ solaris

              # pkg publisher
              PUBLISHER TYPE STATUS URI
              solaris origin online https://pkg.oracle.com/solaris/support/

                NOTA: Oracle dispone de dos repositorios, uno público, en el que no publica parches y otro privado que requiere el uso de certificados. Los certificados se consiguen aqui: http://pkg-register.oracle.com/ y es requesito disponer de un CSI válido para obtenerlos.

                Con el repositorio ya configurado podemos realizar una simulación de actualización:

                # pkg update -nv

                Packages to install: 6
                Packages to update: 238
                Mediators to change: 1
                Estimated space available: 1.67 GB
                Estimated space to be consumed: 1.04 GB
                Create boot environment: Yes
                Activate boot environment: Yes
                Create backup boot environment: No
                Rebuild boot archive: Yes

                Changed mediators:
                mediator java:
                version: None -> 1.6 (system default)

                Changed packages:
                solaris
                database/mysql-51/library
                None -> 5.1.37,5.11-0.175.0.0.0.2.537:20111019T091844Z
                library/apr-util-13/apr-ldap

                  Con este nuevo sistema podemos sacar un listado de paquetes con actualizaciones disponibles:

                  # pkg list -u
                  NAME (PUBLISHER) VERSION IFO
                  consolidation/SunVTS/SunVTS-incorporation 0.5.11-0.172.0.0.0.0.0 i–
                  consolidation/X/X-incorporation 0.5.11-0.175.0.0.0.0.1215 i–
                  consolidation/cacao/cacao-incorporation 0.5.11-0.174.0.0.0.0.0 i–
                  consolidation/cns/cns-incorporation 0.5.11-0.175.0.0.0.1.0 i–
                  consolidation/desktop/desktop-incorporation 0.5.11-0.175.0.0.0.2.0 i–
                  consolidation/desktop/gnome-incorporation 0.5.11-0.175.0.0.0.2.0 i–
                  consolidation/install/install-incorporation 0.5.11-0.175.0.0.0.2.1482 i–
                  consolidation/ips/ips-incorporation 0.5.11-0.175.0.0.0.2.2576 i–
                  consolidation/java/java-incorporation 0.5.11-0.173.0.0.0.0.0 i–
                  consolidation/l10n/l10n-incorporation 0.5.11-0.175.0.0.0.1.765 i–
                  consolidation/ldoms/ldoms-incorporation 0.5.11-0.175.0.0.0.1.0 i–

                  Actualización del Repositorio:

                  Existen dos repositorios de oracle, uno con los paquetes de la release y otro con los paquetes con actualizaciones y parches. Con el primero es normal que no actualice nada:

                  # pkgrecv -s http://pkg.oracle.com/solaris/release/ -d /export/repoSolaris11 ‘*’
                  Processing packages for publisher solaris …
                  Retrieving and evaluating 4292 package(s)…

                  En cambio, si configuramos el repositorio de soporte, si que bajará los parches que se han ido añadiendo al repositorio. Para poder configurar este repositorio deberemos disponer de las claves.

                  # pkgrecv -s https://pkg.oracle.com/solaris/support/ -d /export/repoSolaris11 \
                  > –key /var/pkg/ssl/Oracle_Solaris_11_Support.key.pem \
                  > –cert /var/pkg/ssl/Oracle_Solaris_11_Support.certificate.pem ‘*’
                  Processing packages for publisher solaris …
                  Retrieving and evaluating 4304 package(s)…
                  PROCESS ITEMS GET (MB) SEND (MB)
                  mail/thunderbird 21/391 56.5/2535.6 56.9/8402.3

                  Actualizando un sistema

                    Una vez tenemos el repositorio local actualizado podríamos parchear un sistema de la siguiente manera

                    # pkg update
                    Packages to install: 6
                    Packages to update: 238
                    Mediators to change: 1
                    Create boot environment: Yes
                    Create backup boot environment: No

                    DOWNLOAD PKGS FILES XFER (MB)
                    Completed 244/244 6412/6412 166.1/166.1

                    PHASE ACTIONS
                    Removal Phase 1944/1944
                    Install Phase 2455/2455
                    Update Phase 8580/8580

                    PHASE ITEMS
                    Package State Update Phase 482/482
                    Package Cache Update Phase 238/238
                    Image State Update Phase 2/2

                    A clone of solaris exists and has been updated and activated.
                    On the next boot the Boot Environment solaris-1 will be mounted on ‘/’.
                    Reboot when ready to switch to this updated BE.

                    —————————————————————————
                    NOTE: Please review release notes posted at:
                    http://www.oracle.com/pls/topic/lookup?ctx=E23824&id=SERNS
                    ————————————————————————–

                      Al existir parches de Kernel nos ha creado un nuevo Boot Environment, aunque no lo hayamos especificado explícitamente. Listanto los Boot Enviroments verificamos que se ha creado uno nuevo y se ha activado para el próximo reboot:

                      # beadm list
                      BE Active Mountpoint Space Policy Created
                      — —— ———- —– —— ——-
                      solaris N / 6.72M static 2012-10-08 17:42
                      solaris-1 R – 4.04G static 2012-10-10 16:26

                       
                      Antes de reiniciar para activar el nuevo Boot Environment verificaremos la versión de Kernel que tenemos actualmente instalada:

                      # pkg info system/kernel
                      Name: system/kernel
                      Summary: Core Kernel
                      Description: Core operating system kernel, device drivers and other modules.
                      Category: System/Core
                      State: Installed
                      Publisher: solaris
                      Version: 0.5.11
                      Build Release: 5.11
                      Branch: 0.175.0.0.0.2.1
                      Packaging Date: October 19, 2011 07:57:11 AM
                      Size: 32.33 MB
                      FMRI: pkg://solaris/system/kernel@0.5.11,5.11-0.175.0.0.0.2.1:20111019T075711Z

                       Una vez reiniciado el sistema, podemos ver que ha arrancado con una versión superior:

                      # pkg info system/kernel
                      Name: system/kernel
                      Summary: Core Kernel
                      Description: Core operating system kernel, device drivers and other modules.
                      Category: System/Core
                      State: Installed
                      Publisher: solaris
                      Version: 0.5.11
                      Build Release: 5.11
                      Branch: 0.175.0.11.0.4.1
                      Packaging Date: August 30, 2012 02:21:42 PM
                      Size: 32.04 MB
                      FMRI: pkg://solaris/system/kernel@0.5.11,5.11-0.175.0.11.0.4.1:20120830T142142Z

                      Vuelta atrás de un parcheo

                      Siempre que se lanza un parcheo existe la posibilidad de indicarle sobre que Boot Enviroment aplicarlo. Se le puede especificar que cree uno nuevo, donde se instalarán los parches, y posteriormente reiniciar el servidor con ese nuevo Boot Enviroment. El nuevo Boot Enviroment no siempre se crea de forma automática, pero si se lanza una simulacion de la actualización se indica en el resumen de la misma.
                      Para lanzar una actualización forzando la creación de un nuevo Boot Enviroment lo haremos de la siguiente forma:
                       
                      root@s11client:~# pkg update –require-new-be –be-name parcheo –accept
                      Packages to install: 6
                      Packages to update: 238
                      Mediators to change: 1
                      Create boot environment: Yes
                      Create backup boot environment: No

                      DOWNLOAD PKGS FILES XFER (MB)
                      Completed 244/244 6412/6412 166.1/166.1

                      PHASE ACTIONS
                      Removal Phase 1944/1944
                      Install Phase 2455/2455
                      Update Phase 8580/8580

                      PHASE ITEMS
                      Package State Update Phase 482/482
                      Package Cache Update Phase 238/238
                      Image State Update Phase 2/2

                      A clone of solaris exists and has been updated and activated.
                      On the next boot the Boot Environment parcheo will be mounted on ‘/’.
                      Reboot when ready to switch to this updated BE.

                      —————————————————————————
                      NOTE: Please review release notes posted at:
                      http://www.oracle.com/pls/topic/lookup?ctx=E23824&id=SERNS
                      —————————————————————————

                      Verificaremos el nuevo Boot Enviroment creado y que será el activo en el próximo arranque del servidor. Posteriormente reiniciamos para aplicarlo.

                      # beadm list
                      BE Active Mountpoint Space Policy Created
                      — —— ———- —– —— ——-
                      parcheo R – 4.15G static 2012-10-11 09:37
                      solaris N / 502.0K static 2012-10-08 17:42
                      # init 6

                      Al reiniciar vemos que la versión del kernel es la nueva, el boot enviroment activo es el creado durante el parcheo:

                      $ beadm list
                      BE Active Mountpoint Space Policy Created
                      — —— ———- —– —— ——-
                      parcheo NR / 4.22G static 2012-10-11 09:37
                      solaris – – 11.08M static 2012-10-08 17:42 

                      # pkg info system/kernel
                      Name: system/kernel
                      Summary: Core Kernel
                      Description: Core operating system kernel, device drivers and other modules.
                      Category: System/Core
                      State: Installed
                      Publisher: solaris
                      Version: 0.5.11
                      Build Release: 5.11
                      Branch: 0.175.0.11.0.4.1
                      Packaging Date: August 30, 2012 02:21:42 PM
                      Size: 32.04 MB
                      FMRI: pkg://solaris/system/kernel@0.5.11,5.11-0.175.0.11.0.4.1:20120830T142142Z

                      Si queremos volver atras el parcheo por algún motivo, basta con activar el boot enviroment original y reiniciar:

                      # beadm activate solaris
                      # beadm list BE
                      Active Mountpoint Space Policy Created
                      — —— ———- —– —— ——-
                      parcheo N / 810.33M static 2012-10-11 09:37
                      solaris R – 3.52G static 2012-10-08 17:42
                      root@s11client:~# init 6

                      Una vez reinicado vemos que el boot enviroment original es el activo y que la versión de kernel es la que teniamos inicialmente:

                      # pkg info system/kernel
                      Name: system/kernel
                      Summary: Core Kernel
                      Description: Core operating system kernel, device drivers and other modules.
                      Category: System/Core
                      State: Installed
                      Publisher: solaris
                      Version: 0.5.11
                      Build Release: 5.11
                      Branch: 0.175.0.0.0.2.1
                      Packaging Date: October 19, 2011 07:57:11 AM
                      Size: 32.33 MB
                      FMRI: pkg://solaris/system/kernel@0.5.11,5.11-0.175.0.0.0.2.1:20111019T075711Z
                      # beadm list BE
                      Active Mountpoint Space Policy Created
                      — —— ———- —– —— ——-
                      parcheo – – 812.17M static 2012-10-11 09:37
                      solaris NR / 3.57G static 2012-10-08 17:42
                       

                      Configuración del servicio a traves de proxy

                      Si no funciona la actualización y da time out es posible que sea debido a la configuración del proxy. Hay que configurar en las propiedades del servicio para que tome el proxy y también en las variables de entorno:
                       
                      # svccfg -s svc:/application/pkg/system-repository:default setprop config/http_proxy=astring: «http://USUARIO:PASSWORD@X.X.X.X:PPPP»
                      # svccfg -s svc:/application/pkg/system-repository:default setprop config/https_proxy=astring: «http://USUARIO:PASSWORD@X.X.X.X:PPPP»


                      Reconfigurar el servicio

                      # svcadm refresh svc:/application/pkg/system-repository:default

                      Verificacion de las propiedades:

                      # svcprop pkg/system-repository | grep proxy
                      config/http_proxy astring http://USUARIO:PASSWORD@X.X.X.X:PPPP
                      config/https_proxy astring http://USUARIO:PASSWORD@X.X.X.X:PPPP

                      Además es recomendable definir las variables de entorno:
                       
                      # export http_proxy=»http://USUARIO:PASSWORD@X.X.X.X:PPPP»
                      # export https_proxy=»http://USUARIO:PASSWORD@X.X.X.X:PPPP»