Una vez instalado OpenFiler nos encontramos con algo así:

Una pantalla de login normal y corriente muy similar a la de cualquier linux, instándonos a que abramos el interface de administración de OpenFiler:

El usuario por defecto es openfiler y la contraseña password. Lo primero que vamos a hacer es configurar los discos duros para alojar nuestros datos. En este caso configuraremos un RAID-1 para mantenerlos a buen recaudo.

Para crear el RAID-1 lo primero es preparar la tabla de particiones de cada uno de los discos miembros de dicho RAID. Para ello nos dirigimos a Volumes –> Block Devices, seleccionamos uno de los discos que va a formar parte del RAID  y creamos una partición del tipo “RAID Array Member”:

Repetimos el proceso para el otro disco duro y cuando lo tengamos listo nos dirigimos a Volumes –> Software RAID, escogemos el tipo de RAID deseado (RAID-1 en nuestro caso) y marcamos los dispositivos que queremos utilizar para crear el RAID y hacemos click en Add array:
Una vez que tenemos el RAID creado crearemos un grupo de volúmenes (VG para quien esté acostumbrado a la nomenclatura de LVM) para poder “particionar” el RAID usando LVM (Hay que tener en cuenta que con la creación del RAID va implícita la creación del PV correspondiente). Para ello nos dirigimos a Volumes -> Volume Groups y creamos un nuevo VG, en mi caso “data”, y escogemos el volúmen físico (physical volume) que acabamos de crear (nuestro RAID-1):

Una vez creado el Volume Group nos dirigimos a “Volumes –> Add Volume” para crear los diferentes volúmenes/particiones donde almacenaremos nuestros datos. En mi caso creo 2 volúmenes de 4Gb cada uno, uno para documentos y otro para fotografías. La selección de sistema de ficheros está un poco limitada, podemos escoger entre XFS y ext3, no soporta ext4 ya que el kernel con el que viene es un 2.6.26 y si mal no recuerdo ext4 fue marcado como estable para su uso de forma segura en el kernel 2.6.29. La otra opción es escoger iSCSI, y entonces tendríamos que darle formato en el equipo que actuase como iSCSI initiator. En nuestro caso y para no complicarnos escogeremos XFS. No utilicéis acentos ni caracteres no ASCII (como la ñ) en la descripción de los volúmenes ya que eso creará problemas a la hora de gestionar los mismos.

A continuación deberemos definir las redes que van a poder acceder a los recursos compartidos, para ellos vamos a la sección System y en “Network Access Configuration” damos de alta nuestra red:

Una vez hecho esto deberemos configurar el sistema de autenticación que usará OpenFiler. OpenFiler basa la autenticación de todos los servicios en LDAP y nos da dos alternativas: usar un servidor LDAP existente como un Active Directory, o bien instalar un servidor OpenLDAP propio. Como en nuestro caso queremos un servidor independiente que no necesite infraestructura añadida nos decidiremos por la segunda opción. Nos dirigimos a Accounts –> Authentication y configuramos el server LDAP local:

• Marcamos la opción “Use LDAP”
• Marcamos la opción “Use Local LDAP Server”
• Server: 127.0.0.1
• Base DN: dc=<DOMINIO>,dc=<SUFIJO-DOMINIO>
• Root bind DN: cn=Manager,dc=<DOMINIO>,dc=<SUFIJO-DOMINIO>
• Root bind password: establecemos una contraseña para nuestro servidor LDAP

Una vez configurado esto debería quedarnos algo así:

Con LDAP configurado nos dirigimos a Account -> Administration y creamos los grupos y usuarios que consideremos pertinentes. El proceso es bastante sencillo así que no lo detallaré.

A continuación activaremos los servicios con los cuales podrán acceder los usuarios a nuestros recursos, nos dirigimos a Services –> Manage Services y activamos SMB / CIFS server para permitir el acceso vía samba (Recursos compartidos de Windows).

Con los usuarios creados y los servicios activados nos dispondremos a crear los recursos que pueden acceder dichos usuarios. Nos dirigimos a la sección Shares y creamos una carpeta dentro de uno de los volúmenes existentes haciendo click en el nombre del volumen. Hacemos click en la carpeta recién creada y hacemos click en “Make share”:

Una vez creado el recurso compartido configuraremos sus diferentes opciones: nombre, grupos que tienen acceso y redes que tienen acceso a dicho recurso:

En las capturas se muestra al grupo “Usuarios” establecido como grupo principal (PG) y con acceso de lectura/escritura (RW). Además se autoriza a la red 10.211.55.0 creada anteriormente para acceder a través de samba con acceso de lectura/escritura. Los permisos reales serán la combinación de los permisos de red y permisos de grupo, aplicándose los más restrictivos. Prestad atención a la opción “Override SMB/rsync share name”, en la captura está establecido a “apuntes” si estuviese en blanco que es valor por defecto, el nombre del recurso compartido en samba (red de windows) sería “data.documents.apuntes”.

Con esto tenemos todo lo necesario para acceder a través de samba a nuestro recurso compartido, como pudisteis en la última parte del proceso, acceder a través de FTP ó NFS sería tan sencillo como activar el servicio y darle los permisos necesarios en los recursos deseados.

Cuando hacemos un ls por cada archivo/directorio que tenemos obtenemos algo así:

-rw-r–r– 1 nico equipaje 0 ene  6 11:49 file.dat

Lo primero que vemos es el tipo de fichero (-) los posibles son los siguientes:

• “-” -> fichero normal
• “d” -> directorio
• “l” -> enlace simbólico
• “s” -> UNIX socket
• “p” -> pipe/tubería
• “c” -> character special file (no se me ocurre una traducción aceptable para esto)
• “b” -> block special file

A continuación está la representación simbólica de los permisos (rw-r–r–), los 3 primeros (rw-) son los permisos de usuario, el segundo bloque de 3 (r–) representa los permisos del grupo y el último bloque (r–) son los permisos de otros usuarios. Los posibles permisos son los siguientes:

• r -> lectura (Read)
• w -> escritura (Write)
• x -> ejecución en ficheros, búsqueda en directorios (eXecution)
• s -> setuid con ejecución/búsqueda. Si un achivo ejecutable tiene el bit setuid activo, se ejecutará con los permisos efectivos del dueño del fichero, en vez de usar los permisos de quien ejecuta el archivo.
• S -> setuid sin ejecución/búsqueda
• t -> pegajoso (sticky) con ejecución/búsqueda. Un directorio pegajoso es un directorio append-only, es decir, los usuarios pueden añadir ficheros nuevos pero no pueden borrar ni renombrar los archivos existentes.
• T -> pegajoso sin ejecución/búsqueda.

A partir de eso, podemos ver que el dueño del fichero (nico) file.dat puede leer y escribir en el fichero, el grupo equipaje podrá leer el fichero y el resto de usuario también podrá leer el fichero.

El siguiente dato que se puede ver es el propietario del archivo (nico) seguido del grupo (equipaje).

Ahora que ya sabemos para que valen las letritas.. ¿cómo modificamos los permisos? chown permite modificar el propietario del fichero, ejemplo: “chown root file.dat” haría a root propietario del archivo file.dat. chgrp nos permite cambiar el grupo del fichero, ejemplo: “chgrp users file.dat” otorgaría al grupo users el fichero file.dat

Los permisos se modifican con el comando chmod. chmod nos permite representar los permisos de dos formas, utilizando la notación simbólica explicada anteriormente o mediante notación octal (0-7). La notación octal utiliza un dígito de 0 a 7 para cada bloque de permisos, así “chmod 0755 file.dat” el 7 afecta a los permisos del propietario, el primer 5 a los permisos de grupo y el segundo 5 a los permisos de otros usuarios.

El significado de los numeritos es el siguiente:

• 0 -> sin permisos
• 1 -> ejecución (–x)
• 2 -> escritura (-w-)
• 3 -> escritura y ejecución (-wx)
• 4 -> lectura (r–)
• 5 -> lectura y ejecución (r-x)
• 6 -> lectura y escritura (rw-)
• 7 -> lectura, escritura y ejecución (rwx)

Como buenos observadores, habréis visto que faltan los permisos de sticky y setuid, para eso se usa el primer dígito:

• 1 -> pegajoso (sticky)
• 2 -> setgid
• 4 -> setuid

Poniendo todo junto, “chmod 1750 file.dat” activaría el bit pegajoso para file dat, daría permisos de lectura, escritura y ejecución al propietario, lectura y ejecución al grupo y ningún permiso a otros. Utilizando notación simbólica los comandos serían: “chmod u+rwx file.dat” para los permisos del propietario, “chmod g+rx-w file.dat” para los del grupo, “chmod o-rwx file.dat” para los permisos de otros y “chmod +t fichero” para activar el bit pegajoso (sticky). De ahí que a la hora de aplicar permisos se utilice la notación octal, por su comodidad.

En mi ignorancia, creía que podía arreglarlo reparando la tabla DSDT del ACPI de la BIOS de mi placa base (una Gigabyte P35-DS3R).

Lo primero que hice fue obtener un volcado de la tabla DSDT con el siguiente comando: cat /sys/firmware/tables/DSDT > dsdt.dat

Una vez que tuve el volcado disponible lo desensamblé para poder echarle un ojo a las tripas del mismo. Para esto se utiliza el iasl, un compilador de tablas ACPI de Intel: iasl -d dsdt.dat. Esto genera un fichero llamado dsdt.dsl con el código de la tabla, si fuese correcto al compilarlo de nuevo no debería darnos ningún error, pero como podéis ver el mío me daba 2 errores y 1 advertencia:

Intel ACPI Component Architecture
ASL Optimizing Compiler version 20090123 [Feb 15 2009]
Copyright (C) 2000 - 2009 Intel Corporation
Supports ACPI Specification Revision 3.0a

dsdt.dsl   221:     Method (\_WAK, 1, NotSerialized)
Warning  1080 -                 ^ Reserved method must return a value (_WAK)

dsdt.dsl   284:             Store (Local0, Local0)
Error    4050 -                         ^ Method local variable is not initialized (Local0)

dsdt.dsl   289:             Store (Local0, Local0)
Error    4050 -                         ^ Method local variable is not initialized (Local0)

ASL Input:  dsdt.dsl - 5588 lines, 187085 bytes, 2337 keywords
Compilation complete. 2 Errors, 1 Warnings, 0 Remarks, 641 Optimizations

Después de echarle un ojo a las especificaciones ACPI y manual de referencia de ASL decidí hacer lo siguiente:

• Añadir Return (Package(0×02){0×00, 0×00}) al final del método _WAK para evitar la advertencia en la línea 221. Según la especificación ACPI, _WAK debe devolver un Package con 2 campos DWORD, el primero indicando 0 en caso de éxito, cualquier otro valor para indicar error, y un segundo parámetro indicando el motivo del error si lo hubiese. Así que devolviendo {0×00, 0×00} le indicamos que todo ha ido bien.
• En cuanto a las líneas de los errores, son las 2 iguales: Store (Local0, Local0). La función Store almacena el valor del primer argumento en el segundo, lo cual en este caso no tiene mucho sentido, porque básicamente lo que hace es igualar Local0 a Local0, así que simplemente comenté ese par de líneas y adiós a los errores.

Una vez modificado el código fuente, se compila con iasl -tc dsdt.dsl obteniendo un fichero .hex que debemos pasarle como parámetro (a la hora de compilarlo) al kernel, concretamente la opción CONFIG_ACPI_CUSTOM_DSDT_FILE.

Con la tabla DSDT reparada y el kernel actualizado reinicié el sistema, esperando que todo estuviese arreglado, pero sigo en las mismas

Por lo que he visto, uno de los E8500 solo está soportado por una versión beta de la BIOS de mi placa base, no sé si ese será el problema, pero no sé que prefiero, si usar una BIOS beta o prescindir del escalado de frecuencia de la CPU.

¿Alguno ha tenido un problema similar con un E8500 y una P35-DS3R de Gigabyte?

iptables -A INPUT -m policy --pol ipsec --dir in -p tcp --dport 1701 -j ACCEPT

iptables -A INPUT -m policy --pol ipsec --dir in -p udp --dport 1701 -j ACCEPT

Especificamos que aceptamos el tráfico TCP/UDP entrante en el puerto 1701 para tráfico IPSec entrante, evitando así el aceptar paquetes con destino al l2tpd desde orígenes dudosos.

Para acabar descubriendo que hay algún tipo de problema entre VMware & 2.6.21, ha sido bajar la versión del kernel a 2.6.20 y dejar de tener problemas.

Como en tiempos había conseguido hacer que un xmms mandase la salida de audio a un esound remoto decidí probar por el camino de compartir altavoces.

Resulta que esound actualmente está viejo/desfasado/deprecated/oxidado, buscando un poco encontré en Pulseaudio la solución perfecta. Pulseaudio es un servidor de audio con soporte de red, con la ventaja de estar soportado por el propio ALSA, con lo cual no sólo ciertas aplicaciones se escucharán en los altavoces remotos, si no que todo lo que soporte ALSA ó OSS (ALSA nos ayuda a emular OSS) podrá ser escuchado en nuestros altavoces compartidos.

Manos a la obra, en el equipo que posee los altavoces y tarjeta de sonido deberemos de tener el demonio de Pulseaudio funcionando y admitiendo conexiones via TCP/IP. En mis gentoo es algo así:

1. emerge pulseaudio (con USE=”alsa” como mínimo para que pueda mandar el audio a la tarjetea de sonido, que en mi caso lo tengo definido en /etc/make.conf)
2. editamos /etc/pulse/default.pa y descomentamos la siguiente línea para que la salida de Pulseaudio sea el ALSA del equipo que tiene la tarjeta de sonido funcionando:
   • load-module module-alsa-sink
3. en el mismo /etc/pulse/default.pa añadimos las siguientes líneas para admitir conexiones entrantes desde localhost y la red local (192.168.0.0/24 en mi caso):
   • load-module module-native-protocol-tcp auth-ip-acl=127.0.0.1;192.168.0.0/24
   • load-module module-esound-protocol-tcp auth-ip-acl=127.0.0.1;192.168.0.0/24
4. Arrancamos pulseaudio: /etc/init.d/pulseaudio start

En los equipos cliente deberemos de hacer lo siguiente:

1. Añadimos pulseaudio al USE del /etc/make.conf e instalamos pulseaudio, xine-lib (si ya está instalado la reinstalamos para que vaya con soporte de pulseaudio) y alsa-plugins: emerge pulseaudio xine-lib
2. Editamos /etc/pulse/client.conf y añadimos la siguiente línea para que el pulseaudio de los clientes mande el audio al pulseaudio que si tiene tarjeta de sonido como salida (multivac en mi caso):
   • default-server = multivac
3. Configuramos ALSA para que utilice pulseaudio por defecto añadiendo las siguientes líneas a /etc/asound.conf:
   • pcm.pulse { type pulse }
   • ctl.pulse { type pulse }
   • pcm.!default { type pulse }
   • ctl.!default { type pulse }

Una vez hecho esto he comprobado que el amarok ejecutado en los clientes, que usa xine-lib, usa pulseaudio tanto si elegimos como salida ALSA o Pulseaudio, así que teoricamente cualquier cosa que sea capaz de usar ALSA la escucharemos en el equipo con salida de altavoces

set charset utf-8

Lo sé… resulta evidente, pero en parte por pereza ni siquiera lo había mirado, y fue Sevein quien me dio la solución, thx.

account add jabber cuenta@gmail.com contraseña talk.google.com:5223:ssl

Esto funciona tanto con las cuentas gmail.com como con el servicio que ofrece google de dar correo, chat a tu propio dominio, yo lo tengo funcionando para mi cuenta @mundodisco.net sin problemas.