Partimos de la base de un servidor corriendo samba, del que quiero montar sus shares (compartidos) desde mi FreeBSD. Esto ya lo he hecho antes desde Linux, donde hay una gran abundancia de recursos para configurar esta situación (aunque también vale la pena que reces un poco para encontrar algo que esté un poco en condiciones, no esté muy desfasado, no sea para una distribución concreta con sus «particularidades», etc, etc). El caso es que llegado el turno de hacer lo mismo en FreeBSD, la documentación para este tipo de acción es muy escasa. Más que nada debido a que la información para el automounter para cualquier cosa que no sea NFS es muy rara. Pero por otro lado también a que el desarrollo de las herramientas AMD ha estado inactivo durante unos años, hasta hará cuestión de 2 ó 3 años atrás, momento en que el proyecto fué acogido de nuevo por un mantenedor. Actualmente el nombre del nuevo proyecto AMD es “am-utils”. Pero en contra de la tradición, hay que decir que la documentación de FreeBSD tampoco es que sea muy clara, así que lo que aquí os expongo es la traducción y adaptación de un magnífico escrito al respecto que he encontrado en inglés.

El HOWTO

Lo primero de todo es saber cómo montar un compartido samba bajo FreeBSD, usando para ello el comando mount. Algo tan simple como: mount -t smbfs //user@servidor/share /punto/demontaje. Lo que ocurre es que el comando lo debes ejecutar como usuario root, y además deberás tener presente una serie de temas al respecto:

• Por defecto el comando te preguntará el password del usuario de forma interactiva. Evidentemente con el automounter no hay posibilidad alguna de poder hacer esto. Para ello el comando necesita de opciones adicionales para evitar que pida el password. Sería algo así como: mount -t smbfs -o rw,-N //user@servidor/share /mount/point. La opción -N permite que la operación de montaje continue sin preguntar por el password, pero a no ser que hayas configurado una cuenta de usuario invitado, tendrás que escribir las credenciales de usuario (nombre usuario y password para servidores) en el fichero /etc/nsmb.conf. Echale un vistazo a la página man (si, en FreeBSD si haces “man nsmb.conf”, al contrario que en la gran mayoría de distros Linux, te indicará todo lo necesario sobre ese fichero de configuración y las indicaciones a otra documentación de ser necesaria).

• A veces es útil usar la opción -I (“i” latina mayúscula) para especificar la dirección IP o el nombre DNS del servidor samba, especialmente si hay algún problema en la resolución del nombre NetBIOS del servidor. El comando mount pasaría a ser algo como esto: mount -t smbfs -o rw,-N,-I=192.168.1.5 //user@server/share /mount/point.

• Encontrareis información adicional sobre todas las opciones en la página man del comando mount_smbfs. Este comando es el que hace el montaje para compartidos samba. Notad que en el comando mount, cualquier opción a pasar a mount_smbfs necesita ser escrita con el valor -o opción, separado por comas, con opción y sus valores separados por “=”. Por ejemplo, dada la siguiente línea de órdenes de comando mount_smbfs mount_smbfs -r -N -E gbk:cp936 //user@server/share /mount/point, la correspondiente línea de comando mount sería: mount -t smbfs -o ro,-N,-E=gbk:cp936 //user@server/share /mount/point.

Pasemos entonces ya a la parte del automounter. El automounter en FreeBSD se llama AMD, y es bastante diferente del automounter en Linux, por cómo trabaja y la configuración y formato de los ficheros correspondientes. Comenzaremos con los ficheros de configuración. AMD no soporta smbfs nativamente. Así que la solución pasa por usar un programa para ello en AMD, el cual nos permitirá especificarle los comandos para montar y desmontar un filesystem. Con esto, virtualmente se podrá añadir dentro de AMD cualquier sistema de ficheros en AMD aunque no lo soporte nativamente.

Crearemos un fichero llamado /etc/amd.conf que contenga lo siguiente (siempre como usuario root):

[global]

auto_dir = /.amd

log_file = /var/log/amd.log

log_options = error,fatal,warning

map_type = file

search_path = /etc

[/smb]

map_name = amd.smb

Esta configuración indica a AMD lo necesario sobre su directorio raiz de automontaje, localización de logs y opciones de contenido, además de donde buscar sus ficheros de mapeo. Luego la sección [/smb] define un punto de automontaje /smb, y su correspondiente fichero de mapeo amd.smb.

He mencionado el fichero /etc/amd.smb, así que es hora de crearlo con lo siguiente:

share    fs:=${autodir}${path};type:=program;mount:=”/sbin/mount mount -t smbfs -o rw,-N \\/\\/user@server/share ${fs}”;

Este fichero de mapeo indica a AMD que cuando necesite automontar un share samba, necesitará ejecutar el programa definido por la flag de mount. Fíjate, la línea de comando en mount:=… parece un pelín rarilla. Dos cosas debes tener en cuenta:

1.  
   1.  

      1. La línea de comando en mount:=… no es simplemente un comando a ejecutar. En vez de eso está compuesta de dos partes. La primera palabra en la línea de comando es el nombre del ejecutable, y después, las palabras que siguen son argumentos para ejecutar el comando, incluyendo argv[0] (o $0). Ahí teneis el porqué hay un comando “mount” extra ahí metido.

      2. La opción por defecto de AMD normalizará las barras en su fichero de configuración. Las dobles barras (como la que aparece al principio de una URL de un compartido samba) serán normalizadas en una sola barra. Pero las barras de escape extras son necesarias para ello (“\\/\\/user@server/share”).

Un comando unmount puede también darse aquí si el “umount ${fs}” por defecto no se aplicase (por ejemplo para un filesystem fuse).

Con estos dos ficheros preparados, podemos activar AMD. Para ello editamos el fichero /etc/rc.conf, y añadimos (o modificamos) las siguientes líneas:

amd_enable=”YES”

amd_flags=””

La segunda línea permite a AMD iniciar sin ninguna opción extra. Esto hará leer el fichero AMD /etc/amd.conf para buscar las opciones.

A continuación inicia AMD con el comando /etc/rc.d/amd start. Esto iniciará todo y, dado que hemos puesto las dos líneas anteriores en el fichero rc.conf, cuando se reinicie la máquina se activará automáticamente el servicio.

Terminado esto, cuando accedamos a /smb/share AMD ejecutará el comando mount y montará todo automáticamente. Y además, si el mount está inactivo durante 5 minutos, AMD los desmontará automáticamente también.

Espero que pueda seros de utilidad a más de uno/a, y no haber fallado mucho en la traducción/adaptación realizada.

Have a nice day ;-)

TooManySecrets

Posted via web from TooManySecrets HeadQuarters | Comment »

No puedo aguantarlo más y, por lo tanto, tengo que escribir algo al respecto (y vaya por delante que ni trabajo en Sun/Oracle, ni me pagan ningún “extra” (que no me iría nada mal y ya me gustaría)).

Que gran verdad es aquella que dice que el individuo, aislado, es minimamente inteligente. Pero en cambio la masa (la compuesta por por los individuos, no la verde y cabreada), es más tonta que los pelos del culo (si, ya sabeis, que ven venir la mierda y no se apartan).

Como muchos ya sabeis (está el tema como para no haber oido siquiera hablar de ello), Oracle ha cerrado el uso del sistema operativo Unix Solaris, de manera que ahora te lo puedes bajar igualmente, pero tienes un tiempo limitado de 90 días para usarlo libremente. Pasado ese tiempo, o pagas o a la puta calle.

Tal y como acabais de leer, he dicho que «ha cerrado», aunque quizás la palabra correcta es ha limitado su uso. Por que claro está, no puede cerrar algo que no estaba abierto. Y digo esto porque antes de la compra de Sun por parte de Oracle, te podías bajar el Solaris con el único requisito de registrarte y ya está. Eso si, si querías disfrutar de las actualizaciones/parches o de soporte, «pagando San Pedro canta». Pero eso si, NUNCA, JAMÁS, ha tenido Sun el código de Solaris abierto como la masa de vociferantes… ¿borregos? se empeñan en proclamar a los cuatro vientos. Y me perdonareis por lo de «borregos», pero es que cuando uno se tira por un puente y el resto le sigue detrás sin mirar ni prestar la más mínima atención a lo que está haciendo, se le adjetiva como tal. No teneis más que ir a twitter, y en la búsqueda poner la palabra «opensolaris»; es que uses o no este sistema operativo, te guste o no, acabas con una depresión de caballo gracias a los fud-comentarios que la gregaria composión del rebaño va dejando ahí, desde hace como unos 3-4 días bien bien.

¿Y donde entra OpenSolaris en todo esto? Pues en que la masa borreguil, a pesar de no tener pajotera idea de que el código de OpenSolaris está liberado y no tiene nada que ver con los derroteros que siga Solaris, se ha empeñado en proclamar a los cuatro vientos el mencionado mega-FUD; “si el código de Solaris se cierra, el fin de OpenSolaris ya está aquí, o se está mascando y no tardará nada” ¡¡Arrepentíos!! ¡¡El día del arrebatamiento está próximo!!…

¿Cómo se puede cerrar un proyecto que está libre? Personalmente, la única forma que conozco es que la comunidad que lo sostiene lo abandone, y finalmente muera por desatención. También existe otra forma que algunas personas han indicado; que Oracle ejerza sus derechos sobre el copyright e impida su desarrollo. Bien, si, esto es perfectamente factible. Al igual que Intel, IBM, Novell y otros de los grandes del kernel Linux podrían hacer. Digamos que es una espada de Damocles que pende sobre cualquier proyecto como estos. Pero de ahí, a estar enterrando ya un sistema y proyecto como es OpenSolaris… manda huevos.

Pero vamos, en resumidas cuentas; ¡¡que noooo!! Que OpenSolaris, como proyecto independiente de Solaris y Oracle, sigue ahí. Y si no han sacado ya la versión 2010.03, es sencillamente porque están solucionando bugs demasiado importantes como para hacer la release y que sigan ahí (¿esto, digo yo, se conseguirá entender no? vamos, tampoco es muy difícil). Que no hay ningún jodido contubernio judeo-masónico…

Además, qué es mejor, ¿que saquen el sistema ya para «ir sobre fechas» y llenito de bugs, o que tarden 15 días, 1 mes o varios más, y que la nueva versión del sistema salga funcionando de maravilla y con una cantidad de bugs mínima y no crítica?

Como dicen en el programa de Pablo Motos; “relaaaajaaateeee”. Y como dice el dicho; «no vendas la piel antes de cazar la pieza».

Y para acabar ya del todo, si alguien se ha sentido ofendido… En fin, mi idea/intención es disculparme porque tampoco ha sido mi idea (aunque a mí me ofenda profundamente toda esta soplapoyez del FUD). Así que si alguien se ha sentido ofendido, pues lo siento y siento mucho también haber llamado al pan pan, y al vino wine.

Por cierto, es cierto que todo el código de OpenSolaris no está abierto. Hay, principalmente, algunos drivers que se distribuyen como binarios por los fabricantes (vamos, que no son de Sun/Oracle), y que por lógica no están abiertos. Lo que en el mundo open source se suele conocer por BloB (en el mundo Linux y FreeBSD son harto conocidos). Fuera de eso, lo demás, limpio como culito de bebé.

Have a nice day ;-)

TooManySecrets

Posted via web from TooManySecrets HeadQuarters | Comment »

Si te haces un apaño con el inglés, pero seguir los vídeos te cuesta un poco (especialmente cuando cada persona tiene ciertos acentos), ahora ya no tendrás excusa para ver los vídeos del canal FreeBSD en YouTube.

Gracias al proyecto de subtitulado realizado por Murray Stokely, ahora puedes ver estos vídeos subtitulados en inglés. Pero lo mejor de todo es que gracias al método empleado, si pulsas en el vídeo podrás ver que puedes pedir la traducción del subtitulado a castellano (por ejemplo), o el idioma que prefieras. Podreis ver un ejemplo de todo esto en esta otra página.

Por último comentaros que de los 73 vídeos que hay, se han ido viendo hasta 200.000 veces desde el año 2008, fecha en que se inició el canal BSD Conferences.

Y como muestra un botón; el vídeo de Marshall Kirk McKusick titulado FreeBSD Kernel Internals:

Pulsa con el botón derecho sobre el vídeo y podrás ver los subtítulos traducidos al idioma que quieras.

Have a nice day ;-)

TooManySecrets

Posted via web from TooManySecrets HeadQuarters | Comment »

Esto me lo ha enviado un compañero de trabajo desde Argentina (¡saludos Dani!), y realmente define muy bien lo que somos los sysadmins xDDDD

Posted via web from TooManySecrets HeadQuarters | Comment »

Hasta el build snv_124, OpenSolaris no tenía consola virtual. Pero debido a algún bug, ahora viene pero deshabilitada. Para habilitarla hay que hacer lo siguiente:

$ pfexec svcadm enable vtdaemon
$ pfexec svcadm enable console-login:vt2
$ pfexec svcadm enable console-login:vt3
$ pfexec svcadm enable console-login:vt4
$ pfexec svcadm enable console-login:vt5
$ pfexec svcadm enable console-login:vt6

Para habilitar las “hot keys” para cambiar entre consolas virtuales ejecutar:

$ pfexec svccfg -s vtdaemon setprop options/hotkeys=true
$ pfexec svcadm refresh vtdaemon
$ pfexec svcadm restart vtdaemon

La consola de seguridad viene activada por defecto. Esto significa que si dejas una consola virtual y te mueves a otra, la anterior de donde vienes pasará a bloquearse, y deberás dar el password para desbloquearla cuando quieras volver a ella. Si no quieres que ocurra esto, deberás deshabilitar la consola virtual así:

$ pfexec svccfg -s vtdaemon setprop options/secure=false
$ pfexec svcadm refresh vtdaemon
$ pfexec svcadm restart vtdaemon

Si ya estás logado en una sesión X mientras haces esto, haz un logout y espera a que las X se reinicien. Después de esto, podrás cambiar hacia las consolas virtuales pulsando la combinación ALT+CTRL+F#, donde “#” puede tener un valor entre 1 y 7. La consola 1 es la consola primaria, de la 2 a la 6 son las consolas virtuales, y la 7 es la de las X.

Have a nice day ;-)

TooManySecrets

Posted via web from TooManySecrets HeadQuarters | Comment »

Una de las cosas buenas sobre OpenSolaris y ZFS es la habilidad para crear múltiples configuraciones de inicio (BE) en un mismo sistema.

Desafortunadamente, el comando pkg no crea un nombre “amigable” hace por defecto cuando se actualiza la actual imagen. Incrementa el nombre, pero ¿quien quiere realmente que su sistema tenga por nombre algo como opensolaris-1349?

Sin embargo, si ejecutamos pkg con el flag —be-name, nos permitirá especificar un nombre, el que nosotros queramos:

pfexec pkg image-update --be-name=snv_133

Esto convierte la salida del comando beadm en algo mucho más útil:

pfexec beadm list
BE      Active Mountpoint Space  Policy Created          
--      ------ ---------- -----  ------ -------          
snv_132 -      -          59.02M static 2010-02-05 20:12 
snv_133 NR     /          83.00G static 2010-02-21 12:13 (traducido del original: http://unixben.com/post/401760620/friendly-be-names-in-opensolaris)
Have a nice day ;-)
TooManySecrets

Posted via web from TooManySecrets HeadQuarters | Comment »