Actualizaste tu OpenSolaris y no te funcionan las zonas?

Resulta que si una persona realiza una serie de comandos normales en su maquinilla OpenSolaris, y resulta que de ellos se actualiza la versión a algo superior a snv_98, se encontrará con que no podrá seguir utilizando el mismo procedimiento que antes para generar una zona porque se encontrará con el error:

Error: no zonepath dataset.

ó

Error: unable to determine global zone boot environment.

Qué hacemos entonces?
Pues bien, el primer paso es entender que hay que generar un dataset diferente del que ahora tenemos, para entonces sí generar la zona como antes.
Pero antes de eso, tal parece que a nueva versión de ZFS ha cambiado, por lo que habrá que actualizarla, por un lado, y generar un nuevo BE (boot environment) que contiene un UUID que permite la generación de estas nuevas versiones de zonas.

Los primeros comandos, entonces, serán:

# zpool upgrade -a
# beadm create -a osol2008.11

(el primer comando actualiza a la última versión los pool's ZFS, y el segundo, genera un nuevo boot environment que contendrá la llamada al famoso UUID, llamada osol2008.11).

Luego, no olvidemos instalar un paquetito, que de seguro por omisión no está instalado, que es el correspondiente a rcap (veamos que en la zona del ejemplo, estamos usando resource capping, y por eso necesitamos de este paquete):

# pkg install SUNWrcap

Entonces, ejecutaremos:

# zfs create rpool/zones
# zfs set mountpoint=/zones rpool/zones
# zfs list
NAME USED AVAIL REFER MOUNTPOINT
rpool 14.0G 16.3G 65.5K /rpool
rpool/ROOT 8.74G 16.3G 18K /rpool/ROOT
rpool/ROOT/opensolaris-6 8.74G 16.3G 7.17G legacy
rpool/ROOT/opensolaris-6/opt 1.57G 16.3G 1.57G /opt
rpool/export 5.25G 16.3G 19K /export
rpool/export/home 5.25G 16.3G 5.25G /export/home
rpool/zones 18K 16.3G 18K /zones

Con estos bonitos comandos lo que hice fue generar un dataset denominado "rpool/zones", que monté en /zones. Nada más que eso.
Luego, configuraré mi zonita como lo hacía antes de este tema:

# zonecfg -z osol1
osol1: No such zone configured
Use 'create' to begin configuring a new zone.
zonecfg:osol1> create
zonecfg:osol1> set zonepath=/zones/osol1
zonecfg:osol1> set autoboot=false
zonecfg:osol1> add capped-memory
zonecfg:osol1:capped-memory> set physical=128m
zonecfg:osol1:capped-memory> set swap=256m
zonecfg:osol1:capped-memory> end
zonecfg:osol1> add net
zonecfg:osol1:net> set address=192.9.200.105/24
zonecfg:osol1:net> set physical=iprb0
zonecfg:osol1:net> end
zonecfg:osol1> commit
zonecfg:osol1> exit
root@invid:~# zoneadm -z osol1 install
A ZFS file system has been created for this zone.
Authority: Using http://pkg.opensolaris.org:80/.
Image: Preparing at /zones/osol1/root ... done.
Cache: Using /var/pkg/download.
Installing: (output follows)
...

Ahora bien, luego de haber creado las nuevas zonas, en algún momento querrás actualizar el sistema operativo mediante un "pkg refresh --full" y "pkg image-update".
Cuando quise hacer esto, me encontré con que no pude, debido a que me aparecieron los mensajes:

pkg: unable to create BE None
pkg: image-update cannot be done on live image

Entonces, destruí las zonas generadas mediante el comando "zonecfg -z osol1 delete -F", y "zonecfg -z osol2 delete -F". Sí, tenía dos zonas funcionando.
Luego de esto, borré los nuevos datasets que generé en los pasos anteriores:

# umount -f /zones/osol1
# umount -f /zones/osol2
# rm -rf /zones/osol1
# rm -rf /zones/osol2
# zfs umount -f /zones
# zfs destroy -r rpool/zones

Ahora sí, a actualizar el sistema operativo, como de costumbre:

# pkg image-update

Y ahora todo funciona! Ya tengo el S.O. actualizado, como lo esperaba.
Ah! olvidaba algo! Puede que en el primer intento luego de haber tenido un par de errores de booteo de la zona aparezca un error del estilo:

zone 'osol1': Error: error mounting zone root dataset.
zone 'osol1':
zoneadm: zone 'osol1': call to zoneadmd failed

...y eso es porque antes de este intento de booteo, el sistema ya había montado un filesystem en particular, que es el siguiente:

rpool/zones/osol1/ROOT/zbe
98518633 237113 98281520 1% /zones/osol1/root

En este caso, sencillamente lo desmontamos, y luego reintentamos el booteo, y listo!

Como ven, soluciones sencillas.
Saludos cordiales,

HeCSa.

Servidor de correo con Ubuntu 8.04

En este artículo abordaremos la implementación de un servidor de correo utilizando solamente software libre.

Su sistema operativo será Ubuntu 8.04, y el MTA (Mail Transfer Agent) será Postfix.

Fase I: Instalación del sistema operativo

Bueno, como ya se debe estar pensando, esta fase no presenta ningún problema en sí mismo, dado que la instalación que se seguirá es la del sistema operativo Ubuntu 8.04 Server por omisión.

Comienza con el booteo, se selecciona el lenguaje (yo elegí "English"), luego por la zona en la cual me encuentro (yo elegí "other", y luego "South America - Argentina"), luego por el teclado, donde seguí todas las instrucciones hasta que detectó que el teclado de seguro estaba configurado como "latam".

Configuró sólo la tarjeta de red, y por un error de planificación, levantó su dirección IP desde un servidor de DHCP. Eso no hace sino más interesante la tarea, dado que también debo explicar aquí cómo hacer para que se fije una dirección IP. El nombre que elegí para el servidor, en un esfuerzo de imaginación, fue "mailer".

Luego configuró el reloj, particioné el disco (en la sección "Partition Disks" elegí "Manual", luego generé tres particiones, la /dev/sda1, de sólo 150 MB, para /boot, la /dev/sda2, de 1.5 GB, para swap, y la /dev/sda3, del resto, para /), instaló todos los paquetes básicos del servidor, lo cual me llevó menos de 15 minutos, y me solicitó la creación de un nuevo usuario, que será luego el que hará "sudo" cuando sea necesario.

Luego de eso, le avisé que no estaba usando ningún proxy, se realizó la configuración automática de "apt", me pidió que seleccione qué paquetes de software quería instalar, en base a la función del equipo (DNS, LAMP, Mail, OpenSSH, PostgreSQL, Print ó Samba server, de las cuales no seleccioné ninguna, dado que me ocuparé luego de esa instalación de una forma más personalizada y selectiva de paquetes), comenzó la instalación de software (Select and Install software), realizó automáticamente la instalación del GRUB, y finalizó la instalación, con reboot.

En el primer booteo parecía que el servidor estaba colgado, dado que tardó un poco más de lo normal para un equipo de sus características (casi 15 segundos en dar alguna señal de vida), pero a continuación levantó perfectamente.

El nombre del equipo es, sencillamente, "mailer".

Al realizar un "ifconfig -a" encontré que la dirección IP, efectivamente, coincidía con una del rango del DHCP Server que tengo conectado a la red, por lo que ahora comienza la parte donde configuramos la dirección IP final de la tarjeta de red.

Ingresé como el usuario que había configurado, y cambié mi personalidad (no es recomendable trabajar como root siempre) haciendo "sudo /bin/bash". Me pidió la contraseña mía propia, y pude obtener el tan amado prompt "#". Todas las siguientes tareas serán realizadas mediante la cuenta del usuario generado, y el "sudo /bin/bash".

Edité el archivo "/etc/network/interfaces" para que su contenido sea:

auto lo
iface lo inet loopback

iface eth0 inet static
address 192.9.200.20
netmask 255.255.255.0
gateway 192.9.200.1

network 192.9.200.0
broadcast 192.9.200.255

auto eth0

...dado que la dirección de red que le quiero dar es la 192.9.200.200, suponiendo que esa es una dirección pública válida (obviamente, quien alguna vez tuvo algún contacto con Internet desde el punto de vista serio, sabe que no lo es).

Edité el archivo "/etc/resolv.conf", agregándole los que son mis dos servidores de DNS:

nameserver 200.42.0.108
nameserver 200.42.0.109
domain hecsa.com.ar

Ahora, para verificar que todo quedaba como es debido, relancé los procesos de red mediante "/etc/init.d/networking restart"

El siguiente paso, dentro de lo que es el sistema operativo en sí mismo, consistió en instalarle el paquete OpenSSH Server, lo cual hice como siempre, con "apt-get install openssh-server"

Fase II: Vamos por los paquetes

Ahora, lo jugoso. Se viene la instalación del sistema de correo electrónico, se viene!!!

Vamos a comenzar instalando los paquetes que sean necesarios, y para eso, también como siempre, realizaremos las actualizaciones que correspondan.

Para eso, la receta de cocina adecuada es ejecutar "apt-get update", y "apt-get upgrade", aceptando las actualizaciones que nos proponga nuestro amigo "mailer". Se recomienda, luego de esto, realizar un nuevo reboot, sólo por si las actualizaciones han sido profundas, y sus efectos, luego de un "reboot", son requeridos.

Ahora, con los últims paquetes instalados, procedemos a instalar los que serán necesarios para nuestro servidor de correo electrónico, a través de los siguientes comandos:

# apt-get install postfix courier-imap courier-pop mailx

Pocos paquetes, no? Bueno, esto nos va a dejar bajando cerca de 10 MB de paquetes, lo cual nos permite tomar algún café en el medio de la implementación, que nunca viene mal.

Cuando instalemos el paquete postfix, se nos preguntará qué tipo de sistema queremos, a lo cual responderemos que el mismo será un "Internet Site". Acto seguido, nos pedirá que agreguemos un valor para el dominio, considerando que los mails salientes que no lo posean lo terminarán teniendo como agregado. Si bien en este caso la opción por default es el hostname completo, se deberá colocar el nombre del dominio del cual saldrán los mensajes.

Cuando instalemos los paquetes courier-imap y courier-pop, veremos que se nos pregunta si queremos generar algunos directorios del tipo Maildir para algunos usuarios, a lo cual responderemos que no.

Fase III: A configurar todo

Por suerte, la simplicidad de estos paquetes nos llevarán a no tener que configurar demasiadas cosas cuando lo que queremos es un servidor de correo para un solo dominio, por lo que en general, veremos que los pasos son pocos, y sencillos.

El primer archivo que tocaremos será el "/etc/postfix/main.cf". Allí configuraremos lo siguiente:

smtpd_banner = Cualquiera (OpenCualquiera)
biff = no

append_dot_mydomain = no

readme_directory = no

smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
smtpd_use_tls=yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

myhostname = mailer.dominio.com.ar
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = dominio.com.ar, mailer.dominio.com.ar, localhost.dominio.com.ar, localhost
relayhost =
mynetworks = 192.9.200.0/24, 192.168.100.0/24, 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 # Redes desde las cuales permito que se envíen mails.
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
inet_protocols = all
home_mailbox = Maildir/ # Este es el formato del mail, maildir, y en cada home directory habra un subdirectorio llamado Maildir, que contendra cur, tmp y new.
mailbox_command =

Por ahora, no tengo que tocar nada más, ya que el mismo courier-imap y courier-pop se han ocupado de configurarse como es debido.

Fase IV: Seguridad

Ahora bien, con la configuración anterior, tendremos un excelente servidor de correo, pero será un blanco perfecto para cuanto spammer haya dando vueltas, por lo que se recomienda seguir estos pasos para asegurar que no terminaremos en una blacklist de spam.

Fase IV-A: Shorewall

Como este servidor tiene más de una tarjeta de red (véase que hay dos en la declaración de mail.cf, una con IP 192.9.200.x y la otra con 192.168.100.x), se ha configurado la misma desde el archivo "/etc/network/interfaces":

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
        address 192.9.200.20
        netmask 255.255.255.0
        network 192.9.200.0
        broadcast 192.9.200.255
        gateway 192.9.200.1
        dns-nameservers 200.42.0.108 200.42.0.109
        dns-search dominio.com.ar

auto eth1
iface eth1 inet static
        address 192.168.100.250
        netmask 255.255.255.0
        network 192.168.100.0
        broadcast 192.168.100.255

Ahora, comenzaremos a realizar la configuración del paquete shorewall. Primero, lo instalamos con el comando "apt-get install shorewall shorewall-doc".

Una vez que tengamos estos dos paquetes instalados, procederemos a configurar sus archivos, de la siguiente manera:

cp /usr/share/doc/shorewall-common/default-config/interfaces /etc/shorewall/ vi /etc/shorewall/interfaces

En este archivo agregaremos las definiciones de nuestras dos tarjetas de red:

net eth0 detect dhcp,tcpflags,logmartians,nosmurfs

net eth1 detect dhcp,tcpflags,logmartians,nosmurfs

Luego:

cp /usr/share/doc/shorewall-common/default-config/zones /etc/shorewall/ vi /etc/shorewall/zones

Aquí configuraremos las dos zonas que estaremos utilizando, es decir, la de la red, y la del firewall en sí mismo:

net ipv4

Luego:

cp /usr/share/doc/shorewall-common/default-config/hosts /etc/shorewall/

Luego:

cp /usr/share/doc/shorewall-common/default-config/policy /etc/shorewall/ vi /etc/shorewall/policy

Aquí agregaremos las políticas que deseamos:

$FW net ACCEPT

net $FW DROP info

net all DROP info

# Esta politica debe estar al final

all all REJECT info

Luego:

cp /usr/share/doc/shorewall-common/default-config/routestopped /etc/shorewall/ vi /etc/shorewall/routestopped

Y agregamos:

eth0 0.0.0.0 routeback

eth1 0.0.0.0 routeback

Luego:

cp /usr/share/doc/shorewall-common/default-config/rules /etc/shorewall/ vi /etc/shorewall/rules

Y agregamos:

SSH/ACCEPT net $FW

Ping/ACCEPT net $FW

# Permit all ICMP traffic FROM the firewall TO the net zone

ACCEPT $FW net icmp

# mail lines

SMTP/ACCEPT net $FW

SMTPS/ACCEPT net $FW

Submission/ACCEPT net $FW

IMAP/ACCEPT net $FW

IMAPS/ACCEPT net $FW

POP3/ACCEPT net $FW

#web

Web/ACCEPT net $FW

Chequearemos que todo esté correctamente configurado mediante:

shorewall check

Editamos "vi /etc/default/shorewall" y modificamos el valor de "startup" para que esté en 1:

startup=1

Ahora, si queremos, podemos realizar un reboot y ver cómo levantan todos los servicios implementados, inclusive los del firewall (shorewall - realmente iptables)

Fase IV-B: Fail2ban

Si bien en este mismo blog habrán visto algunos detalles sobre cómo implementar estar herramienta, les cuento que la misma ha cambiado desde la publicación de este artículo, por lo que ahora veremos la versión que se puede implementar desde un servidor Ubuntu 8.04 (fail2ban 0.8.2-2).

Comenzamos instalando un paquete como lo hacemos siempre, mediante la ejecución de "apt-get install fail2ban".

Una vez instalado, sólo les recomiendo que modifiquen el archivo "/etc/fail2ban/jail.conf" de la siguiente forma:

destemail = yo@dominio2.com.ar

De esa manera, cada vez que algún caco de la información y el ancho de banda quiera ingresar y falle por más de cierta cantidad de veces, le llegará un mail a esta dirección, aparte de deshabilitar a la dirección IP de origen.

Recordemos que siempre luego de hacer cualquier modificación a los archivos del fail2ban, tendremos que relanzar sus procesos mediante "/etc/init.d/fail2ban stop" y "/etc/init.d/fail2ban start".

Fase IV-C: Postgrey

Ahora, uno de los platos fuertes de esta noche, aparte de todo lo que vimos antes. Vamos a implementar el sistema postgrey, que no es ni más ni menos que un greylisting para el servidor de correos Postfix.

El principio del proceso es el mismo de siempre, debemos instalarlo con el comando "apt-get install postgrey".

Luego, tendremos que modificar el archivo "/etc/postfix/main.cf" para que comience a utilizar este sistema. Le agregaremos las siguientes líneas:

smtpd_recipient_restrictions =
        permit_mynetworks,
        permit_sasl_authenticated,
        reject_unauth_destination,
        check_policy_service inet:127.0.0.1:60000

Y finalmente relanzamos los procesos del postfix para que se tomen los cambios ("/etc/init.d/postfix stop" y "/etc/init.d/postfix start").

Servidor Hogareño - Versión GNU/Linux

Este artículo tendrá por objeto dar las explicaciones necesarias para poder montar un servidor hogareño basado en GNU/Linux. Los servicios que se pretenden brindar son: DHCP, PDC, FileServer, Proxy, y Filtrado de Páginas. Si hay tiempo, un servidor del tipo Portal estaría también muy bueno.

La versión de GNU/Linux elegida, en este momento, es la Ubuntu 8.04, que si bien ha demostrado que no es la más rápida, por lo menos está basada en paquetes .deb, verifica de una forma medianamente coherente dependencias, y permite su actualización con un grado bastante sencillo de tareas.

El primer punto ha sido instalar la distribución por default, generando una partición de 8 GBpara el swap, y de 130 GB para /.

Lo ideal no es dejar todo el contenido del primer disco sin dividir filesystems, pero en este caso, como el servidor tendrá características hogareñas, no hace falta más.

Cayendo sin red

Mi motherboard es un ASUS P5GC-MX/1333, que tiene una tarjeta de red Attansic L2, por supuesto, como me gustan los desafíos, no soportada directamente por Ubuntu 8.04. Y digo no soportada directamente, porque si bien el driver aparece dentro de los existentes en esta versión, sencillamente no funcionan con este motherboard. Los módulos de esta tarjeta de red aparecen como cargados al ejecutar un "lspci", pero no funcionan, lo cual nos lleva, ante todo, a tener que buscar un nuevo driver, que deberá funcionar mejor que éste.

Efectivamente, con el motherboard me llegó un CD con drivers. Entre ellos, encontré que aparecía un directorio llamado "LinuxDrivers". Excelente, me dije, y sin pensarlo, seguí el procedimiento necesario para compilarlos. Nada más inútil, porque llegué a un mensaje de error que me decía que no tenía el directorio /usr/src/linux-headers-2.6.24-16-generic. No hay problema, utilicé el ingenio, y saqué de internet, en otra máquina, desde el sitio packages.ubuntu.com, esos paquetes y sus dependencias. Los grabé en un memory stick, y los instalé en el equipo.

Para poder compilar lo que necesitaba, sin saber si era o no necesario, pero sabiendo que en algún momento lo sería, instalé, desde el CD de Ubuntu, el paquete build-essential.

Pero tampoco funcionó, dado que me apareció, al ejecutar "make", un mensaje haciendo referencias a problemas de CFLAGS, requiriendo que se modifiquen los parámetros para que se utilicen EXTRA_CFLAGS. Cuando estaba a punto de darme por vencido, y comenzar con alguna otra distro, que me diera más y mejores drivers (según tengo entendido, ya hay varias que así lo hacen), encontré un código fuente dedicado a esta tarjeta, que se encuentra en http://people.redhat.com/csnook/atl2/atl2-2.0.4.tar.bz2 . Lo bajé, lo compilé, y el módulo atl2.ko resultante, lo copié a /lib/modules/2.6.24-16-generic/ubuntu/net/atl2/atl2.ko.

Rebooteé el equipo, y la configuración de red comenzó a funcionar. La familia, contenta. Ahora puedo hacer un "apt-get update", y que funcione. Lo sé, no me olvidé de comentar las entradas del CD de Ubuntu en "/etc/apt/sources.list".

Conexión vía terminal y VNC

Una de las primeras cosas que necesité, fue el servidor OpenSSH, dado que me resultaría más cómodo trabajar con el servidor de esta manera, en forma remota. Para ello, instalé el paquete openssh-server con el comando "apt-get install openssh-server". El sistema bajó también el "libssl0.9.8.0.9.8g-4ubuntu", el "openssh-client", y el "openssh-blacklist". Luego de la instalación, y sólo para ver si todo levantaba correctamente desde el principio, rebotee el sistema.

Una cosa que me encantó de este motherboard es que un reboot dura menos de 30 segundos. Increíble.

Inmediatamente después, me pude conectar desde otros equipos sin problemas:

login as: hecsa
hecsa@192.9.200.2's password:
Linux dshecsa01 2.6.24-16-generic #1 SMP Thu Apr 10 13:23:42 UTC 2008 i686

The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.

To access official Ubuntu documentation, please visit:
http://help.ubuntu.com/
hecsa@dshecsa01:~$

Excelente, el primer paso estaba dado!

Ahora, vamos por la conexión vía VNC. Como es sabido, el paquete a instalar es el vncserver.

Al hacer un "apt-cache search vncserver", encontré que uno de los listados era el "vnc4server". Lo instalé con el comando "apt-get install vnc4server", y posteriormente lo inicié con el comando "vncserver". Así de sencillo.

Ahora bien, la primera imágen es que el entorno en sí se veía bastante básico, por lo que descomenté las siguientes dos líneas en el archivo $HOME/.vnc/xstartup, para que levante por VNC un entorno más completo, como el que tengo en la consola del equipo:

unset SESSION_MANAGER
exec /etc/X11/xinit/xinitrc

Claro que lo que el sistema quiere es levantar el TWM, que no tenía instalado, por lo cual ejecuté "apt-get install twm". Reinicé el servidor con los comandos "vncserver -kill :1", y "vncserver", y todo quedó de maravillas.

Compartiendo los archivos

Por supuesto, lo que debía hacer ahora era instalar el servidor Samba, y configurarlo para que pueda funcionar como un PDC.

Primer paso, instalar el paquete samba: "apt-get install samba".

El paquete aparentemente, se instaló correctamente, pero arrojó unos mensajes extraños, que luego analizaré (Veremos el resultado de este análisis en el apéndice dedicado a tales fines):

tdbsam_open: Converting version 0 database to version 3.
account_policy_get: tdb_fetch_uint32 failed for field 1 (min password length), returning 0
account_policy_get: tdb_fetch_uint32 failed for field 2 (password history), returning 0
account_policy_get: tdb_fetch_uint32 failed for field 3 (user must logon to change password), returning 0
account_policy_get: tdb_fetch_uint32 failed for field 4 (maximum password age), returning 0
account_policy_get: tdb_fetch_uint32 failed for field 5 (minimum password age), returning 0
account_policy_get: tdb_fetch_uint32 failed for field 6 (lockout duration), returning 0
account_policy_get: tdb_fetch_uint32 failed for field 7 (reset count minutes), returning 0
account_policy_get: tdb_fetch_uint32 failed for field 8 (bad lockout attempt), returning 0
account_policy_get: tdb_fetch_uint32 failed for field 9 (disconnect time), returning 0
account_policy_get: tdb_fetch_uint32 failed for field 10 (refuse machine password change), returning 0

Ahora, pasaremos a la configuración, que calculo que no será una tarea menor. Veamos cómo transformamos este servidor en un Samba PDC.

Para eso, lo primero que hago es generar un archivo "/etc/samba/smb.conf" como el siguiente:

[global]
workgroup = GRUPETE
netbios name = SERVER1
server string = %h server
obey pam restrictions = Yes
passdb backend = tdbsam
passwd program = /usr/bin/passwd %u
passwd chat = *Enter\snew\sUNIX\spassword:* %n\n *Retype\snew\sUNIX\spassword:* %n\n .
log level = 2
log file = /var/log/samba/log.%m
max log size = 1000
socket options = TCP_NODELAY IPTOS_LOWDELAY SO_SNDBUF=8192 SO_RCVBUF=8192
add user script = /usr/sbin/useradd -m %u
delete user script = /usr/sbin/userdel -r %u
add group script = /usr/sbin/groupadd %g
delete group script = /usr/sbin/groupdel %g
add user to group script = /usr/sbin/usermod -G %g %u
add machine script = /usr/sbin/useradd -d /var/lib/nobody -s /bin/false -M %u
logon script = %U.cmd
domain logons = Yes
os level = 65
domain master = Yes
dns proxy = No
wins support = Yes
ldap ssl = no
panic action = /usr/share/samba/panic-action %d
invalid users = bin, daemon, sys, man, postfix, mail, ftp
admin users = @wheel

[homes]
comment = Home Directories
valid users = %S
read only = No
create mask = 0700
directory mask = 0700
browseable = No
dont descend = profile

[netlogon]
comment = Network Logon Service
path = /home/samba/netlogon
share modes = No

[printers]
comment = All Printers
path = /tmp
create mask = 0700
printable = Yes
browseable = No

[print$]
comment = Printer Drivers
path = /var/lib/samba/printers

[archive]
comment = Directorio Archivos
path = /archivos
valid users = @interno, root
read only = No
create mask = 0770
directory mask = 0770
browseable = No

Ahora, a generar los usuarios. Comienzo por el mío, así que como sé que está generado en el sistema GNU/Linux, ejecuto "smbpasswd -a hecsa".

Inmediatamente, o mejor dicho, luego de esperar unos minutos, pude levantar desde una máquina separada los directorios compartidos mediante el protocolo de Samba. Otro éxito, y ya van varios!

Dame una dirección, por favor

Ahora, le llegaba el turno al servidor DHCP, que tantas alegrías nos da siempre.

Lo primer, es instalar el paquete que nos dará este servicio. Al hacer un "apt-cache search dhcpd" encontré a mi viejo amigo y aliado "dhcp3-server", que como siempre, instalé con el comando "apt-get install dhcp3-server".

Lo interesante es que luego de instalarlo, aparecen estos mensajes:

* Starting DHCP server dhcpd3 [fail]
invoke-rc.d: initscript dhcp3-server, action "start" failed.

Pero al mirar archivos como el "/var/log/messages", o el "/var/log/daemon.log", no encontramos más que mensajes de subida el dhcpd, lo cual desconcierta bastante.

Para evitar seguir hurgando en detalles extravagantes, sencillamente dejé el archivo "/etc/dhcp3/dhcpd.conf" de la siguiente forma:

option domain-name "hecsa.com.ar";
option domain-name-servers 200.42.0.108, 200.42.0.109;

default-lease-time 600;
max-lease-time 7200;

subnet 192.9.200.0 netmask 255.255.255.0 {
range 192.9.200.220 192.9.200.230;
option routers 192.9.200.1;
option domain-name-servers 200.42.0.108, 200.42.0.109;
authoritative;
}

host hecsadv {
hardware ethernet 00:13:02:61:23:C4;
fixed-address 192.9.200.142;
}

A que no se imaginan qué pasó cuando levantó de nuevo el servicio dhcpd, con los comandos "/etc/init.d/dhcp3-server stop" y "/etc/init.d/dhcp3-server start"? Mírenlo ustedes mismos:

root@dshecsa01:/etc# /etc/init.d/dhcp3-server stop
* Stopping DHCP server dhcpd3 [fail]
root@dshecsa01:/etc# /etc/init.d/dhcp3-server start
* Starting DHCP server dhcpd3 [ OK ]

Sí, así es...quedó funcionando. Ya tenemos servidor de direcciones, y hasta una dirección fijada para una de las máquinas de la red. Qué tal, eh?

Servidor Proxy

Nada más sencillo que instalar un servidor proxy en GNU/Linux, y ni que hablar sobre Ubuntu.
Lo único que tendremos que hacer es ejecutar "apt-get install squid".
Ahora viene la parte de la configuración, que si bien tampoco es complicada, merece que se explique de forma adecuada para evitar problemas.
Lo primero que tendremos que hacer es ingresar al directorio /etc/squid, y copiar el archivo instalado por omisión, squid.conf, como squid.conf.original, o lo que querramos que sea.
Ahora, lo editaremos, y le cambiaremos las siguientes líneas:

visible_hostname dshecsa01
acl mi_red src 192.9.200.0/24
http_access allow mi_red

Ahora, bajamos y subimos el squid con el set de comandos "/etc/init.d/squid stop" y "/etc/init.d/squid start", y todo queda funcionando.

Apéndices

Solución de backup

Para realizar backups, y dado que remarco la característica de "hogareño" de este servidor, nada como un buen DVD-RW.

Para poder usarlo con GNU/Linux, nada como implementar el excelente programa K3B, realmente una versión mejorada de cualquier programa de grabación de CD/DVD que haya visto.

Como siempre, lo instalo con el comando "apt-get install k3b". Pero como el K3B requiere de otros programas para funcionar perfectamente, ejecuto también "apt-get install normalize-audio", "apt-get install sox", "apt-get install transcode", "apt-get install vcdimager", y me faltaría algo que levante el eMovix, pero por ahora no lo encuentro. Con lo que tengo, ya podré realizar la mayor parte de todas las cosas que generalmente hago con un programa como el K3B.

Diario íntimo de mis experiencias con OpenSolaris en una HP DV5000

Prefacio
Veremos que la primer instalación de OpenSolaris corresponderá a la 2008.05, que es la que me ha llegado a mis manos en este momento. A medida que vaya actualizando el sistema operativo, encontraremos en el futuro modificaciones a este blog basándonos en estas novedades.
Bueno, gracias a la llegada a mis manos del tan esperado Indiana, decidí instalarlo en mi notebook HP DV5000, desde la cual estoy escribiendo este artículo (eso quiere decir que instalarlo pude, y fue bien sencillo).
Símplemente, reventé mis particiones de GNU/Linux (no lloren, tengo otra de mis máquinas que tiene instalada la versión que hasta ahora veo con mayor performance del mercado, que es Arch Linux), y decidí comenzar con el proceso de booteo desde el LiveCD, para luego darle un click en el ícono de "Install OpenSolaris".
Todo se instaló perfectamente. Pude setear los locales en español, que en este momento ya me parece una rareza para lo que venía siendo OpenSolaris (o mejor dicho, antes de OSOL 2008.05, lo que era el SXDE y el SXCE), y tengo un bonito escritorio con el Compiz instalado, gracias a haber habilitado los efectos de escritorio. Para esto, sólo hice un click derecho sobre el escritorio, y cuando abrí el selector de fondos de escritorio, elegí habilitar los efectos. Nada más, y absolutamente igual a cualquier escritorio que haya instalado en esta misma máquina.
Lo que vengo probando de funciones de Internet realmente funcionan muy bien, está bastante aceitado, y es hasta más rápido que en el entorno Ubuntu que tenía antes (eso no es raro, Ubuntu ya hace tiempo que tardaba en bootear hasta más que Windoze eXtraPollution SystemPanic 2, que no es poco).
Ahora bien, comienzo este blog para registrar las vueltas que tendré que dar hasta tanto tenga configurado todo de la forma que debiera.

Sonamos
Comienzo por el sonido, que por lo visto, es parte de las figuritas difíciles de OpenSolaris.
Mi tarjeta de sonido, según la salida del comando /usr/X11/bin/scanpci es:

-bash-3.2# ./scanpci | grep -i audio
Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller

Los primeros indicios que encontré en la red son poco alentadores, así que me tendré que poner a ver cómo hago que esta belleza me entregue el primer mp3 como la gente.

Así es que me bajé de la página del proyecto OSS el paquetito famoso, y lo instalé:

-bash-3.2# pkgadd -d oss-solaris-v4.0-1015-i386.pkg

The following packages are available:
1 oss Open Sound System
(i386) v4.0-1015

Select package(s) you wish to process (or 'all' to process
all packages). (default: all) [?,??,q]:

Processing package instance from
...
Using as the package base directory.
## Processing package information.
## Processing system information.
## Verifying disk space requirements.
## Checking for conflicts with packages already installed.
## Checking for setuid/setgid programs.

This package contains scripts which will be executed with super-user
permission during the process of installing this package.

Do you want to continue with the installation of [y,n,?] y

Installing Open Sound System as

## Installing part 1 of 1.
...
[ verifying class ]
[ verifying class ]
## Executing postinstall script.
Setting up Open Sound System....please wait
add_drv -m '* 0666 root sys' osscore
add_drv -m '* 0666 root sys' -i '"pci8086,27d8"' hdaudio
add_drv -m '* 0666 root sys' -i '"usbif,class1"' ossusb
add_drv -m '* 0666 root sys' vmix
add_drv -m '* 0666 root sys' sadasupport

Open Sound System installation complete

You can use the osstest command to test audio playback in your system.

It may be necessary to reboot the system before all devices get properly
detected by the system.

Installation of was successful.
Rebooteé, ejecuté "osstest", saqué los pedazos de parlante que quedaron pegados en las paredes, y seguí adelante con mi linda máquinita.
Ni hablar de la forma en la que mejoró el sonido cuando levanté el programa gráfico "ossxmix", y cambié, en el jack, la entrada de "mix" por "pcm1". Créanme, suena mejor, por lejos!!!

Samba de mi esperanza
Otra de las cosas que yo, exótico del arte informático quise hacer es montar un espacio compartido de un servidor Samba que tengo en mi casa. Claro, lo que pasa es que yo soy un extraño vicioso, y quiero cosas estrafalarias en mi máquina. Por eso no me funcionó de entrada. Acá les copio la salida inmoral al intentar montar el filesystem famoso:

-bash-3.2# mount -F smbfs -o username=hecsa,password=QueTeImportaPibe //192.9.200.2/hecsarchive /media/samba
mount_smbfs: service "svc:/network/smb/client:default" not enabled.

Divino, no? Claro, montar un filesystem Samba es algo que no es común que la gente haga, así que es muy lógico tener que habilitar un servicio, mandar un cohete a la luna y pensar en la fusión en frío para poder volver a hacer uso de este extraño feature.
Así que me cargué de paciencia, y ejecuté este comando:

-bash-3.2# svcadm enable -r smb/client
Luego de un mensaje que me decía que dependía de varios rezos para que funcione, pude montar mi filesystem, pero con otros flags, como podrán ver aquí:
-bash-3.2# mount -F smbfs //hecsa@192.9.200.2/hecsarchive /media/samba
Password:
-bash-3.2# df -k /media/samba
Filesystem kbytes used avail capacity Mounted on
//hecsa@192.9.200.2/hecsarchive
240362656 170983848 69378808 72% /media/samba

Bien! Primer prueba superada! Ya tengo mi filesystem Samba montado en mi máquina! Juro que mi emoción es sublime. Y casi no tuve que hacer nada.

No me gustaban los horarios de oficina
Bueno, ahora me digo: quiero editar un archivo de "oficina". Oh, sorpresa, en el menú de Oficina sólo tengo el Evince. Parece que en una oficina la gente sólo mira PDF's, por ejemplo.
Vamos, nomás. Instalemos el openoffice, a ver si podemos llegar a la victoria, y tener un sistema de escritorio funcionando como se debe.
Ejecuto los siguientes comandos:
(Para ver qué paquete instalar)

-bash-3.2# pkg search -s pkg.opensolaris.org openoffice
INDEX ACTION VALUE PACKAGE
basename dir opt/openoffice.org2.4/share/registry/modules/org/openoffice pkg:/openoffice@2.4.0-0.86
basename dir opt/openoffice.org2.4/share/registry/modules/org/openoffice pkg:/openoffice@2.4.0-0.86
basename dir opt/openoffice.org/share/registry/modules/org/openoffice pkg:/openoffice@0.5.11-0.79

(Y para instalarlo)

-bash-3.2# pkg install openoffice
DOWNLOAD PKGS FILES XFER (MB)
Completed 1/1 4220/4220 420.64/420.64

PHASE ACTIONS
Install Phase 4798/4798

Luego de un minuto, me aparecieron en el menú los íconos tan gloriosos de todos los productos incluídos en el OpenOffice, y la familia oficinista, contenta...

El compilado de este verano
Ahora bien, como de seguro voy a tener que usar el compilador C para poder hacer uso de cualquier driver que haya que compilar, me decido a buscarlo, simplemente con "which gcc". No está en el path, o directamente no está instalado.
Vamos:
(Para buscar el paquetito)

-bash-3.2# pkg search -s pkg.opensolaris.org gcc
INDEX ACTION VALUE PACKAGE
basename link usr/bin/gcc pkg:/SUNWgcc@3.4.3-0.86
basename link usr/bin/gcc pkg:/SUNWgcc@3.4.3-0.79
basename link usr/bin/gcc pkg:/SUNWgcc@3.4.3-0.75
basename link usr/bin/gcc pkg:/SUNWgcc@3.4.3-0.86
(Y para instalar el bendito paquete)
(Me baja el SUNWgcc, SUNWbinutils, SUNWarc, y el SUNWhea)
-bash-3.2# pkg install SUNWgcc
DOWNLOAD PKGS FILES XFER (MB)
Completed 4/4 2035/2035 88.13/88.13

PHASE ACTIONS
Install Phase 2457/2457

Bien, ahora ya puedo hacer mi "Hola, mundo" sin problemas...bueno, casi...

Permiso, por favor!
Lo cierto es que para poder hacer muchas de las cosas que quiero hacer, necesitaría algo parecido al gtksu, lo cual no pido, por lo que ejecuto:
-bash-3.2# usermod -R root hecsa
UX: usermod: hecsa is currently logged in, some changes may not take effect until next login.
[ACTUALIZACIÓN] Luego de algunas actualizaciones, este efecto ya no aparece. El entorno se ha vuelto bastante dinámico. Creo que estoy viviendo el proceso de construcción de un S.O., pero esta vez, en serio.

Mi primera vez
Sin duda, tiene que tener un apartado especial el dedicado a la primera actualización. Lo intenté realizar desde la interface gráfica, y al menos al primer intento, no pude. La razón? No sé, la veremos luego.
Un delirio que cuando me fijo en el tamaño de lo que tenía que bajar de internet era ni más ni menos que 1900 MB!!!
Encima de eso, la interface sistemáticamente se colgó cuando llegaba a los 1000 MB, por lo que tuve que cerrar la interface gráfica, y volver a abrirla.
No sé qué problema tiene, pero cuatro pulgares para abajo al gestor de paquetes, justamente por haber hecho que baje ni más ni menos que 1 GB de información que luego no sirvió para nada.
Aparte, las descripciones de los upgrades son un chiste.
Me aparecieron sólo cuatro paquetes que actualizar, y con sus dependencias llegamos a ese tamaño abominable.
[ACTUALIZACIÓN] - Luego de determinados updates, las imágenes son más chicas, y el gestor de paquetes ha sido mejorado notablemente. Ahora puedo instalar paquetes desde allí, si bien mi naturaleza de antaño me hace usar CLI. Bien por los desarrolladores, que están haciendo las cosas como se debe!

The (wired) network is the computer
Bueno, le llegó la hora a la tarjeta de red WiFi.
La cuestión es sencilla: en esta maquinita, he instalado los sistemas operativos más estrafalarios que una mente enferma pueda concebir. Y no me refiero sólo a los compatibles con M$ o Linux.
Pero al intentar levantar la tarjeta de red WiFi, oh, sorpresa, ni siquiera se digna a encender su luz.
Al ejecutar un scanpci, como lo hice antes, encontré que la tarjeta es una:

pci bus 0x0006 cardnum 0x00 function 0x00: vendor 0x8086 device 0x4222
Intel Corporation PRO/Wireless 3945ABG Network Connection

Cómo hacemos para que esta verdadera belleza funcione?
Buscando en foros del más allá, encontré uno que mencionaba que era necesario instalar el driver wpi, y por eso ejecuté:

-bash-3.2# pkg search wpi
INDEX ACTION VALUE PACKAGE
basename file kernel/drv/wpi pkg:/SUNWwpi@0.5.11-0.86
driver_name driver wpi pkg:/SUNWwpi@0.5.11-0.86

...quería ver si había algo de ese estilo dando vueltas por ahí.
Pero la sorpresa la tuve cuando quise instalarlo, y me encontré con que ya estaba en el sistema:

-bash-3.2# pkg install SUNWwpi
Nothing to install in this image (is this package already installed?)

Entonces...qué le pasa a la niña?
Bueno, el primer lugar para buscar es en /var/log/messages. Lo que ahí encontré fue esto:

May 10 01:38:38 invid wpi: [ID 133862 kern.warning] WARNING: wpi_init(): timeout waiting for firmware init

Entonces, usamos la munición gruesa:
La salida del comando scanpci -v nos entrega:

pci bus 0x0006 cardnum 0x00 function 0x00: vendor 0x8086 device 0x4222
Intel Corporation PRO/Wireless 3945ABG Network Connection
CardVendor 0x103c card 0x135b (Hewlett-Packard Company, Card unknown)
STATUS 0x0010 COMMAND 0x0046
CLASS 0x02 0x80 0x00 REVISION 0x02
BIST 0x00 HEADER 0x00 LATENCY 0x00 CACHE 0x10
BASE0 0xd2100000 addr 0xd2100000 MEM
MAX_LAT 0x00 MIN_GNT 0x00 INT_PIN 0x01 INT_LINE 0x03

...y el comando prtconf -pv nos entrega:

Node 0x000017
assigned-addresses: 82060010.00000000.d2100000.00000000.00001000
reg: 00060000.00000000.00000000.00000000.00000000.02060010.00000000.00000000.00000000.00001000
compatible: 'pciex8086,4222.103c.135b.2' + 'pciex8086,4222.103c.135b' + 'pciex8086,4222.2' + 'pciex8086,4222' + 'pciexclass,028000' + 'pciexclass,0280' + 'pci8086,4222
.103c.135b.2' + 'pci8086,4222.103c.135b' + 'pci103c,135b' + 'pci8086,4222.2' + 'pci8086,4222' + 'pciclass,028000' + 'pciclass,0280'
model: 'Network controller'
power-consumption: 00000001.00000001
devsel-speed: 00000000
interrupts: 00000001
subsystem-vendor-id: 0000103c
subsystem-id: 0000135b
unit-address: '0'
class-code: 00028000
revision-id: 00000002
vendor-id: 00008086
device-id: 00004222
pcie-capid-pointer: 000000e0
pcie-capid-reg: 00000011
name: 'pci103c,135b'

Cómo sé que se trata de la tarjeta en cuestión, y no de la ethernet? Sencillo, porque en "model" no dice nada de ethernet.
Intenté, entonces, removiendo el driver con el comando "rem_drv wpi", y luego agregándolo de nuevo con "add_drv -i "pci8086,4222" wpi", pero no pasó nada...snif...
[ACTUALIZACIÓN] - Luego de pasar la versión snv_95, todo funciona perfectamente. Me conecto a redes WiFi como con cualquier otro S.O. Brillante!!! Luego de la snv_101a, hasta me aparece un bonito mensaje avisándome de cuanto elemento necesito para saber el estado de la red. Brillante x 2!!!

Ambiente de desarrollo en pleno desarrollo
Bueno, otra de las cosas que deseo de mi escritorio es que me sirva como ambiente de desarrollo.
Para eso, necesito tener instalado por lo menos el Netbeans 6.1, y el Glassfish v2.
El Netbeans 6.1 no está en el repositorio, pero por suerte sí el 6.0.1, que dado mi nivel de desarrollo es más que suficiente para lo que necesito hacer.
El tema viene con el Glassfish, que no está disponible desde el momento en el cual se instala el sistema operativo, como pasó con el OpenOffice.org.
Al final, descubrí la trampita. Hay que hacer un "pkg install glassfishv2", lo cual me muestra un par de cuestiones interesantes.
La primera, que es medio complicado tener que hacer una búsqueda por palabras para saber qué paquete instalar, y la segunda (que es peor que la primera) es que no hay un metapaquete que permita, en el futuro, pasar automáticamente de una versión a la siguiente, si uno lo desea.
Atención, que se entienda bien este punto, no me parece mal que haya un paquete específico para el Glassfish V2, ya que si queremos mantener una versión, y probar con la siguiente, podríamos hacer, en el futuro, "pkg install glassfishv3", por ejemplo; el problema está en los que, como yo, quieren tener metapaquetes para este tipo de programas.
[ACTUALIZACIÓN] - Actualicé a la versión snv_101b, y para mi sorpresa, toda la paquetería de Netbeans quedó en versión 6.5, que es la última y flamante. Realmente, un caño. Mis viejos proyectos siguien siendo reconocidos por la nueva IDE, y cuando los ejecuto, aún funcionan. Mis miedos, por ahora, quedan guardados.

Ojo con las actualizaciones
Atención, y mucho cuidado con las actualizaciones, dado que hay ciertas cosas que nos pueden poner los pelos de punta, sobre todo si nuestra máquina no tiene un dual boot (o aún teniéndolo), o si se hizo la instalación por default, como ocurre en el 100% de los casos que conozco (y eso incluye el uso de ZFS como filesystem por default).
El tema viene cuando al ejecutar "pkg refresh", y luego "pkg image-update", y si por algún motivo se genera un error en la actualización del sistema operativo, ya que quedará un ambiente de booteo absolutamente inutilizable, que sólo rebooteará nuestra máquina, sin ningún sistema operativo.
Ante eso, lo primero que nos vendrá a la mente es hacer un "beadm destroy nombre_del_ambiente". Bueno, dado uno de esos bonitos bugs, ocurrirá que el GRUB quedará completamente vacío, motivo por el cual habrá que encontrar formas bastantes extravagantes de recuperar todo nuestro trabajo sobre el entorno OpenSolaris.
Dado lo anterior, el nivel de recuperabilidad del sistema operativo, en caso de problemas (incluso generados por las mismas "características" del mismo), se puede considerar como prácticamente nulo (al menos en la versión que estoy probando).
[ACTUALIZACIÓN] - Luego de algunas actualizaciones, este problema desapareció por completo, y ahora todo me funciona perfectamente en lo que respecta a boot environments. Cool!
Sumado a lo anterior, encontré algunas cosas interesantes respecto de las actualizaciones, como por ejemplo:
- La actualización a snv_94 nunca funcionó. Sencillamente, el sistema operativo rebooteaba sin parar, por lo que tuve que eliminar el boot environment a mano, con el comando beadm destroy.
- La actualización a snv_95 sí funcionó, pero no me dejó arrancar el Sun xVM (VirtualBox) a menos que antes le configure una variable de ambiente (mensaje: Failed to create COM object), específicamente la LD_NODIRECT=1. Esta solución me ha llevado un buen rato para encontrarla. Espero que no se repita la experiencia. De todas formas, intenté instalar un RH4.5, y luego de todo el proceso de instalación, se queda colgado en "booting the kernel". A seguir remando, que hay agua para rato.
- La actualización a snv_101b fue buenísima, no sólo me instaló las últimas versiones de Netbeans, OpenOffice, etc., sino que aparte cambió mucho de lo que antes no me funcionaba. Se puede decir que ahora me anda todo, inclusive la tarjeta WiFi en forma nativa, cosa que verifiqué hoy mismo.

Resumen general, mi general - Just the facts
Como resumen, sólo se puede pensar en que el OpenSolaris es un buen sistema operativo, sus funciones de virtualización están perfectamente armadas, como pasa con el SXDE y SXCE.
Un aspecto interesante es que automáticamente detectó mi tarjeta gráfica, y la puso a trabajar, inclusive activando el entorno Compiz.

Conversión de smbpaswd a tdbsam

En este artículo veremos la forma de modificar la configuración de un servidor Samba para que las cuentas de los usuarios pasen de almacenarse en el formato smbpasswd (específicamente en el archivo /etc/samba/smbpasswd, por ejemplo), al formato tdbsam.

Esta nota nace como respuesta a algunas necesidades planteadas por usuarios de Samba 3 que, luego de haber estado trabajando un buen tiempo con este producto, descubrieron que un error en la configuración del archivo smb.conf implicó que las cuentas de los usuarios se almacenen en el archivo smbpasswd, en lugar de en la base de datos tdbsam, como es conveniente.

En uno de los casos particulares, se produjo el error de, en lugar de agregar, en el archivo de configuración smb.conf la entrada "passdb backend = tdbsam", se había agregado la entrada "passwd backend = tdbsam", con lo cual, al ejecutar el comando smbstatus, aparecía el mensaje:

Unknown parameter encountered: "passwd backend"
Ignoring unknown parameter "passwd backend"

Como no se había advertido dicho error, se agregaron usuarios, los que fueron depositados en el archivo smbpasswd, en lugar de en la base tdbsam, como se deseaba.

El error lo pude reproducir, y encontré que mi usuario, en la base smbpasswd, aparecía de la siguiente forma:

hecsa:1002:ABBF1A51422B62ABB14FD58A657A9CA6:D4356FE201D376F0FEE4B2A355BA1FB1:[U
         ]:LCT-47CF4463:

Como dato anecdótico, veamos que el UID que aparece en este archivo es el mismo que aparece en /etc/passwd para este usuario:

hecsa:x:1002:1002::/home/hecsa:/bin/sh

Ahora bien, manos a la obra! Lo que tenemos que hacer es usar el comando pdbedit, con las opciones de exportación e importación de contenidos, de manera que el usuario "hecsa" aparezca en la base de datos tdbsam.

Cambiaremos la entrada en el archivo /etc/samba/smb.conf, pasando de ser "passwd backend = tdbsam" a ser "passdb backend = tdbsam", bajaremos y subiremos el servicio de samba con el comando "/etc/init.d/samba stop; /etc/init.d/samba start".

Entonces ejecutaremos:

servidor:/etc/samba# pdbedit -i smbpasswd -e tdbsam
Importing accout for hecsa...ok

...y listo!

Ya podemos verificar a nuestro usuario, que ahora se encuentra en la base de datos tdbsam.

Segurización de un servidor VHCS2 sobre Ubuntu Server 6.06 - Apache 2 / PHP / Postfix / FTP / iptables

Segurización de PHP

Una de las primeras cosas que hacemos para segurizar el servidor, es cambiar el php.ini, que en el caso de esta versión de sistema operativo, se encuentra ubicado en /etc/php4/apache2/php.ini.
Se le agregarán las siguientes entradas:

disable_functions = system, exec, shell_exec, passthru, pcntl_exec, proc_close, proc_get_status, proc_nice, proc_open, proc_terminate, popen, pclose, ini_alter, virtual, openlog, escapeshellcmd

allow_url_fopen = Off

register_globals = Off

Se debió quitar de la lista una serie de valores que originalmente estaban, como ser:

putenv: Con este valor, no funciona el Squirrelmail.
set_time_limit: Con este valor, no funciona el Webmail OverLook3.

Finalmente, deberemos reiniciar el servidor web para efectivizar los cambios realizados. Eso, como veremos en general en todos los casos, lo hacemos con /etc/init.d/apache2 stop y /etc/init.d/apache2 start.

Segurización de Apache 2

Se cambió el shell por omisión del usuario dueño de la ejecución de apache 2 (en mi caso es el www-data). El shell era /bin/sh, y ahora se configuró el /usr/sbin/nologin.
Al mismo tiempo, se cambió el directorio del usuario del apache, que por mosión era el /home/www-data, por el /dev/null.
Esos dos cambios se realizaron editando directamente el archivo /etc/passwd, localizando la entrada del usuario www-data, y cambiando sus campos para que queden así:

www-data:x:33:33:www-data:/dev/null:/usr/sbin/nologin

Luego se bajó y subió el servidor apache con el comando /etc/init.d/apache2 stop y /etc/init.d/apache2 start.
Se verificó que las páginas existentes funcionen bien, y con eso tenemos el primero de nuestros procesos de segurización de apache 2 finalizado.

Segurización de SSH - Uso de fail2ban

El sistema fail2ban es famoso por reaccionar ante muchos intentos de login fallidos por parte de una direccion IP en particular, impidiendo que se le proporcione el mismísimo promt del ssh.
Este comando reacciona incorporando reglas de iptables en forma automática.
Para implementarlo en Ubuntu 6.06 (viejo al día de la fecha, pero muy buen servidor), se deberá instalar con el típico comando de la suite apt:

# apt-get install fail2ban

Una vez instalado, se podrá recorrer su configuración verificando el archivo /etc/fail2ban.conf, que entre otras cosas, deberá tener:

[DEFAULT] (esta sección tendrá los valores mínimos necesarios para que fail2ban funcione correctamente)
...
logtargets = /var/log/fail2ban.log (archivo donde se logueará el comportamiento de fail2ban)
maxfailures = 5 (cantidad de intentos de login antes de estar baneado)
bantime = 600 (tiempo que el servidor no permitirá conexiones desde esa dirección IP)
...

[MAIL] (esta sección indicará las configuraciones destinadas a enviar un mail cada vez que se banee una dirección IP)
...
enabled = true
host = mail.firulete.com
port = 25
user = webmaster@firulete
password = firulete01
from = fail2ban@firulete.com
to = webmaster@serverremoto.com
...

Luego de estas configuraciones, sólo tendremos que reinicializar el servicio fail2ban con los comandos /etc/init.d/fail2ban stop y /etc/init.d/fail2ban start.
Podremos verificar que el programa está en ejecución mediante un "ps aux | grep fail2ban", que nos entregará algo del estilo "/usr/bin/python /usr/bin/fail2ban".


En breve estaré agregando las secciones correspondientes a la forma de segurizar el servidor de correo, Postfix, el FTP server, y la forma cómo configurar el sistema iptables2 para que tengamos, aparte de todo, un excelente firewall en nuestro servidor VHCS2.

Instalacion de Windows XP, Linux Ubuntu 7.10 y Solaris Express Developer Edition snv_70b en una Dell D630

Ante todo, como el disco de esta máquina tiene ni más ni menos que 120 GB, lo dividimos en particiones.
Generamos una de 60 GB para Windows, una de 4 GB para el swap de Linux, una de 26 GB para el / de Linux, y una de 30 GB para Solaris Express Developer Edition snv_70b (OpenSolaris, para los amigos).
Para realizar esta instalación, ante todo, implementamos Windows, que es el que mas problemas puede traernos a la hora de pensar en que su boot loader, de instalarse al final, borraría todas las demas opciones de sistemas operativo.

Instalacion de Ubuntu 7.10

Luego, implementamos Ubuntu, y para ello sólo tendremos que utilizar las dos particiones que comenté más arriba.
Por un lado, creamos una partición de swap (en mi caso será la segunda partición del disco) de 4 GB, dado que la Dell D630 tiene 2 GB de RAM; y por el otro, generamos una partición de / de 26 GB.
La instalación luego de estas sencillas consideraciones deberá continuar como es común, dado que el instalador de Ubuntu detectará nuestra tarjeta gráfica, que si bien no está completamente soportada, por lo menos nos permitirá disfrutar de una definición de 1440x900.
No debemos olvidar, dado que luego lo necesitaremos, copiar FUERA DE ESTA MÁQUINA el archivo /boot/grub/menu.lst. Es importantísimo que este copiado, y que sea fuera de esta máquina. Si aún usas papel, es una excelente idea copiarlo a mano, no es tanto!
Dado que SXDE detectará la partición de swap como si fuera una mas de SXDE, deberemos desactivarla, y cambiarle el flag de partición, de linux-swap, a algo del estilo ext2, por ejemplo.
Para hacer eso, hay dos caminos, ambos sencillos.
Uno es utilizar el comando fdisk, con el cual podremos seleccionar la opcion "t", para hacer un toggle del flag de la partición, y otro, que es que yo estuve usando, es la instalación de la utilidad "gparted".
Al abrirlo, podremos ver esa partición, que en mi caso es la segunda del disco, desactivarla, y luego cambiarle su flag por el de ext2. No olvides presionar el botón "Apply" del "gparted" luego de hacer los cambios!
Luego de ejecutar la instalación por omisión, hay ciertas cosas que no quedaron funcionando del todo.
Una de ellas es el sonido. Lo que hice para que funcione fue lo siguiente:

# more /proc/asound/devices
2: : timer
3: : sequencer

Instalé el paquete linux-backports-modules, y agregué las siguientes líneas en el archivo /etc/modprobe.d/alsa-base:

options snd-hda-intel model=dell-m42

Al rebootear, las cosas han cambiado un poco. Al hacer un "more /proc/asound/devices", aparece lo siguiente:

2: : timer
3: : sequencer
4: [ 0- 1]: digital audio playback
5: [ 0- 0]: digital audio playback
6: [ 0- 0]: digital audio capture
7: [ 0- 1]: hardware dependent
8: [ 0- 0]: hardware dependent
9: [ 0] : control

Inmediatamente instalé el paquete alsamixergui, para poder hacer el ajuste fino del volumen. Levanté un poco el volumen, y con el xmms, pude escuchar mis mp3 sin ningún problema.

Otra cosa que no funcionó bien desde el principio fueron los efectos de pantalla. Para ello, lo que hice fue agregar en el archivo /etc/xdg/compiz/compiz-manager la siguiente línea:

SKIP_CHECKS=yes

Nuevamente rebooteé, y probé los efectos. Funcionaron, pero debo cuidarme de no enloquecer con algunos, porque pueden "colgarme" la interface gráfica.

Instalación de SXDE

En la lista de instalaciones, finalmente llegamos al SXDE.
Para instalarlo no hay mucha ciencia, dado que con sólo presionar "F12" en nuestra máquina cuando está arrancando, y luego, en el menú de booteo, seleccionar la entrada de CD/DVD, el SXDE comenzará su proceso de instalación.
La "falta de ciencia" se debe a que, en esta versión de Osol, no podremos especificarle el tamaño de las particiones, por lo que sólo le diremos que utilice el espacio que queda, que será de 30 GB.
Cuando termina de instalarse (aproximadamente una hora, en la Dell D630), rebootearemos el sistema, y veremos con alegría la ventana de login. Pero esto recién empieza!
Tocamos el archivo /boot/grub/menu.lst, para agregarle las entradas de Linux, dado que el boot loader por omisión, ahora, es el implementado por SXDE.
Se le agregan las siguientes entradas:

title Ubuntu 7.12, kernel-2.6.22-14-generic
root (hd0,2)
kernel /boot/vmlinuz-2.6.22-14-generic root=UUID=1ddc3c8e-168b-4f68-ab82-36203ed5dd1b ro quiet splash
initrd /boot/initrd.img-2.6.22-14-generic

Estas entradas, que parecen tan crípticas, son un extracto del /boot/grub/menu.lst de la partición de Linux, que habiamos copiado antes.

Una vez que hayamos salvado esta porción del archivo, y hayamos rebooteado con Linux Ubuntu, no olvidemos volver a configurar el espacio de swap, es decir, dejarlo como estaba antes. Para eso, volvemos a ejecutar el "gparted", tal como lo hicimos en la sección anterior.

Luego de rebootear para ver que todo funciona bien, tendremos un gran problema, y es ver que nuestra tarjeta de red, una Broadcom NetXtreme, basada en el chipset 5755M, no levanta para nada.
Luchando contra el hardware, encontre un link que apuntaba a poder bajar un driver del sitio "opendrivers".
Luego de bajarlo, lo instale con:

# pkgadd -d ./BRCMbcme.pkg

...y la tarjeta de red, luego de un

# ifconfig bcme0 plumb
# ifconfig bcme0 192.9.200.3 netmask 255.255.255.0 up

...quedó funcionando.

Virtualización de linux 2.4 y 2.6 con Brandz en OpenSolaris

Procedimiento rápido para la generación de una Brand Linux 2.4 y 2.6 con OpenSolaris (SXDE, SXCE y OpenSolaris)

Éste es un procedimiento para generar una zona de linux 2.4 ó 2.6, usando el esquema de virtualización BrandZ de OpenSolaris.
Como habrán podido notar, no se soporta aún la implementación de una Brand desde el CD de instalación de la misma distro de GNU/Linux, por lo que se deberá generar, previamente, usando un sistema operativo ya instalado, mediante los comandos:
# cd /
# tar jcf distro24.tar.bz --exclude distro24.tar.bz --exclude dev --exclude proc --exclude sys --exclude boot *
Sencillamente, para generar una brand de linux 2.4, que por omisión posee sus archivos xml de configuración en el sistema operativo inmediatamente después de haber sido implementado, se deberán seguir estos pasos:

# mkdir /zones (éste será el directorio donde se depositarán los archivos correspondientes a la zona que vamos a crear)
# zonecfg -z linux24 (éste será el nombre que le daremos a esta zona)
linux24: No such zone configured (lógicamente, como aún no existe, aparecerá este mensaje)
Use 'create' to begin configuring a new zone.
zonecfg:linux24> create -t SUNWlx (aquí creamos la nueva zona, basándonos en el template SUNWlx)

Si el brand a generar fuera del tipo de kernel 2.6, habría que ejecutar, en lugar del anterior, el siguiente comando:
zonecfg:linux24> create -t SUNWlx26 (aquí creamos la nueva zona, basándonos en el template SUNWlx26, similar al anterior)

zonecfg:linux24> set zonepath=/zones/linux24 (aquí anunciamos cuál será el path donde se ubicarán los archivos de esta zona)
zonecfg:linux24> set autoboot=true (esto sólo lo agregamos si queremos que cuando bootee el equipo, es decir, la zona global, también bootee la zona linux24)
zonecfg:linux24> add capped-memory (al principio no hacía esto, pero luego de ver cómo una zona podía comerse toda mi RAM, lo tomé como buena práctica)
zonecfg:linux24:capped-memory> set physical=128m (sólo le doy 128 Mbytes. Soy tacaño)
zonecfg:linux24:capped-memory> set swap=256m (el doble de RAM para el swap, también limitado, y también una buena práctica para evitar que los recursos sean comidos por esta zona)
zonecfg:linux24:capped-memory> end (finalización de la configuración de la memoria limitada)
zonecfg:linux24> add net (aquí agregamos una interface de red a la zona)
zonecfg:linux24:net> set address=192.9.200.105/24 (aquí configuramos la dirección de red de esta interface de red, nótese cómo el prompt cambió, y ahora tiene como último elemento la palabra "net")
zonecfg:linux24:net> set physical=bge0 (le decimos que la tarjeta de red por la cual se deberá salir es la bge0)
zonecfg:linux24:net> end (finalizamos la configuración de la tarjeta de red)
zonecfg:linux24> add attr
zonecfg:linux24:attr> set name="audio" (agregamos un atributo, que será la utilización de una interface de audio)
zonecfg:linux24:attr> set type=boolean
zonecfg:linux24:attr> set value=true
zonecfg:linux24:attr> end
zonecfg:linux24> commit (hacemos efectivos los cambios)
zonecfg:linux24> exit (salimos de la configuración de la zona linux24)
# zoneadm -z linux24 install -d /Documents/distro24.tar.bz2 (atención, antes de poder instalar la zona, debemos poseer un archivo con el árbol de archivos de una distro basada en el kernel 2.4, tareada y bzipeada)

- Aquí veremos aparecer mensajes como éstos:
Installing zone 'linux24' at root directory '/zones/linux24'
from archive '/Documents/centos_fs_image.tar.bz2'
This process may take several minutes.
Setting up the initial lx brand environment.
System configuration modifications complete.
Setting up the initial lx brand environment.
System configuration modifications complete.
Installation of zone 'linux24' completed successfully.
Details saved to log file:
"/zones/linux24/root/var/log/linux24.install.2453.log"

# zoneadm -z linux24 boot (booteamos la zona linux24)
# zlogin -C linux24 (le decimos -C para que arranque la consola, y podamos ejecutar los pasos de configuración que faltan)

- Aquí finalizará la instalación de la zona linux. Salir de la
consola con ~.

# zlogin linux24 (ahora sí, con el sentimiento del deber cumplido, nos logueamos a esta zona)

Luego, algo importante a realizar, si es que vas a realizar instalaciones de productos que tienen grandes dependencias con los nombres de los servidores, es cambiar el archivo /etc/hosts de forma tal que contenga entradas como las siguientes:

127.0.0.1 localhost.localdomain localhost
192.9.200.105 linux24.hecsa.com.ar linux24

Ahora bien, para bajar esta zona linux 2.4, sólo tendremos que ejecutar:

# zoneadm -z linux24 halt

Nada más para una zona linux con kernel 2.4 (medio viejo al día de la fecha, pero sirve para unas cuantas cosas, como en mi caso, que pruebo si me funcionan viejos programas).

Esto que has visto en las notas de más arriba, lo reproduje bajándome el archivo SUNWlx26.xml, e instalando un CentOS 4 update 5, es decir, una distro basada en RPM's, y con kernel 2.6.x, y me anduvo perfectamente.

UN DETALLE INTERESANTE es que hay diferencias notables de espacio cuando la máquina virtualizada está en funcionamiento, y cuando se baja:

a) Funcionando:

-bash-3.2# du -ks ./*
5817 ./bin
1 ./boot
3 ./dev
42021 ./etc
12 ./home
1 ./initrd
86294 ./lib
1 ./lost+found
4 ./media
1 ./misc
1 ./mnt
3128241 ./native
1 ./opt
21 ./proc
289 ./root
17527 ./sbin
1 ./selinux
1 ./srv
28 ./tftpboot
44 ./tmp
1759444 ./usr
47876 ./var

b) Sin funcionar:

-bash-3.2# du -ks ./*
5817 ./bin
1 ./boot
1 ./dev
42021 ./etc
12 ./home
1 ./initrd
86294 ./lib
1 ./lost+found
4 ./media
1 ./misc
1 ./mnt
21 ./native
1 ./opt
1 ./proc
290 ./root
17527 ./sbin
1 ./selinux
1 ./srv
28 ./tftpboot
43 ./tmp
1759444 ./usr
47876 ./var

Dónde es que está la diferencia? Fíjense en el directorio /native. Ahí tienen unos 3 GB.
Eso se debe a que cuando no está funcionando todos sus directorios, que son dev, etc, lib, proc, tmp, usr y var, están vacíos, pero cuando arranca la máquina virtualizada, se llena con contenidos típicos del GNU/Linux que está en ejecución.

Ahora bien, si la prueba salió bien, y queremos eliminar esa zona, qué comandos utilizaríamos? Eso es bien sencillo, sólo hay que ejecutar dos comandos (atención, no hay undo de estos comandos, así que a ejecutarlos con bastante cuidado!):

# zoneadm -z linux24 uninstall
# zonecfg -z linux24 delete

Así de sencillo!

Apéndice: Diferencias entre el archivo SUNWlx.xml y el SUNWlx26.xml

A simple vista (con perdón de la palabra), las diferencias que existen entre el archivo SUNWlx.xml y el SUNWlx26.xml es sólo la línea, por lo que la sección que la contiene quedaría:

<zone name="default" zonepath="" autoboot="false" brand="lx"><attr name="kernel-version" type="string" value="2.6"/></zone>

Eso es todo, y con esta línea extra se podrá generar el archivo en cuestión.

Suerte con las pruebas!!!

HeCSa.