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.

Como cabe esperar, aparte de poder meterle mano a la consola con él, vale para destripar el PC sin mayor problema, un must en estos tiempos modernos.

Array Size : 7325679680 (6986.31 GiB 7501.50 GB)

Los discos elegidos han sido 6 Western Digital Caviar Green (WD15EADS). Y para facilitar las tareas de administración (física) de los mismos, he adquirido dos blackplanes SATA con capacidad de 4 discos cada uno. Los backplanes son una maravilla, puedes controlar el encendido/apagado de cada disco por separado, proporcionan un LED de actividad para cada disco y permiten cambiar los discos sin apagar el equipo (comprobado).

Una de las cosas que más me preocupaba con los Caviar Green era su rendimiento, en teoría funcionan entre 5400 y 7200 RPM según haga falta, para obtener un buen equilibrio entre consumo y rendimiento. De forma cualitativa y con un uso normal, no los noto más lentos que los Seagate a los que sustituyen, que si eran 7200RPM constantes. Como dato (poco fiable) os dejo la salida de hdparm -tT para el RAID-5:

/dev/md4:

Timing cached reads:   14748 MB in  2.00 seconds = 7382.40 MB/sec

Timing buffered disk reads:  1104 MB in  3.00 seconds = 367.73 MB/sec

Usando dig @8.8.8.8 www.google.es obtengo los siguientes resultados:

;; Query time: 87 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu Dec  3 18:46:41 2009
;; MSG SIZE  rcvd: 175

Consultando con 194.179.1.101 (servidor DNS de Telefonica Data): dig @194.179.1.101 www.google.es

;; Query time: 23 msec
;; SERVER: 194.179.1.101#53(194.179.1.101)
;; WHEN: Thu Dec  3 18:46:55 2009
;; MSG SIZE  rcvd: 175

87 msec de Google VS 23msec de Telefonica, de momento está claro quien es más rápido

Hace unos días los desarrolladores de Remote’s Buddy liberaron candleair, un driver para el receptor IR que sustituye al original de Snow Leopard que permite el acceso exclusivo por parte de una aplicación al Apple Remote y soluciona los problemas anteriormente descritos. La instalación es muy sencilla y parece funcionar perfectamente. 100% recomendado

Descargas mediante los métodos habituales y subs-team.tv / tusseries.com / seriessubs.com / subtitulos.es para los subtítulos (en castellano o inglés según la serie). Y para verlas en el salón, el Plex indexando el directorio que contiene las series, de forma que las muestra con carátulas, sinopsis y todas las pijadas imaginables:

Aunque sé que es posible automatizar la descarga de series, nunca me he animado a dejarlo automatizado debido a la existencia de diferentes versiones de cada capítulo (PROPER,REPACK…) y que el hecho de bajarlos me permite ir controlando que subtítulos tengo que buscar.

Para hacernos la vida más fácil existe Netwrix USB Blocker. Disponible en dos versiones, una gratuita y otra comercial, permite bloquear mediante GPOs (políticas de grupo) el acceso a puertos USB.

La versión gratuita nos limita a un control mediante una lista de equipos y a dispositivos de almacenamiento. La versión de pago nos permite aplicar las restricciones a todo tipo de dispositivos, proporcionar acceso temporal a un usuario en concreto, gestionar las restricciones en base a las OUs (Unidades Organizativas) de nuestro Active Directory.

Una aplicación muy interesante que podría evitar muchos disgustos en sitios por donde pasa mucha gente distinta al cabo del día, como pueden ser los equipos de una facultad.

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?