FreeBSD: Teclado castellano (internacional) bajo Xorg usando Hal.

Y es que no todo el mundo usa Gnome, KDE o XFce, y en más de una ocasión, lo único que necesitamos es un buen window manager (lease windowmaker, icewm, dwm, fluxbox, etc, etc...). El problema es que si no estás en una distro GNU/Linux (donde habitualmente, que no todas, te lo dan todo masticadito), puede llegar a convertir algo más o menos trivial, en un infierno. Y lo peor es que una experiencia que se inicia como agradable bajo FreeBSD, cambiando de aires de otro sistema operativo, puede hacer desistir rapidamente al neófito de continuar con FreeBSD, para volver a su anterior sistema operativo.

Concretamente estoy hablando del teclado en castellano (español/España) bajo Xorg (sistema X-Window) compilado para usar Hal.

Y es que la experiencia puede fustrar: Te logas en el sistema, te instalas en un momento (tirando de paquetes binarios en remoto con "pkg_add -r -v <paquete>") un window manager ligero, configuras el sistema X en nano segundos con un "X -configure", copias el fichero resultante llamado "xorg.conf.new" como /etc/X11/xorg.conf, te creas un fichero en tu $HOME/.xinitrc con un texto que diga algo así como: "exec /usr/local/bin//wmaker" (sin las dobles comillas), inicias las X con el comando "startx" y..... ¡¡¡ZAS, en toda la boca!!! Tienes el teclado bajo las X configurado como inglés.

Pongámosle solución rápida. Haz un copy&paste de lo que pongo aquí abajo, y grábajo en un fichero llamado:

/usr/local/etc/hal/fdi/policy/x11-input.fdi

=======Inicio fichero========================================

<?xml version="1.0" encoding="ISO-8859-1"?>
<deviceinfo version="0.2">
 <device>
  <match key="info.capabilities" contains="input.keyboard">
   <merge key="input.x11_options.XkbModel" type="string">pc105</merge>
   <merge key="input.x11_options.XkbLayout" type="string">es</merge>
  </match>
 </device>
</deviceinfo>

======Fin fichero==========================================

 

(no se os ocurra copiar las líneas de Inicio y Fin de fichero; tan solo os las pongo para que quede bien delimitada la zona a copiar).

Una vez lo hayais copiado y grabado, reiniciad el servicio hald:

/usr/local/etc/rc.d/hald forcerestart

Y ahora ya podreis disfrutar de vuestro teclado en castellano tranquilamente, bajo Xorg+Hal, con cualquier window manager (bajo Gnome o KDE, los dos grandes desktops a día de hoy, no hace falta hacer ésto, ya que las propias utilidades que llevan de configuración de teclado ya os lo configuran (si se lo indicais, claro)).

 

Después de configurarme un Acer Aspire D-250-0bk con FreeBSD 8.1-RELEASE, me he dado cuenta que en un post que puse al respecto de este tema hace ya un tiempo, no quedaba para nada claro qué había que hacer para solucionar este handicap, y disfrutar plenamente de nuestro sistema.

 

Have a nice day ;-)

TooManySecrets

FreeBSD 8.1 a la vistaaa!!!

Según Ken Smith y este correo suyo, ya hay una agenda preliminar definida para la liberación del FreeBSD 8.1-RELEASE; el 9 de Julio.

Este es, tal y como podeis ver en el correo mencionado, el desarrollo de la agenda:

Freeze		May 24th, 2010 
BETA1		May 28th, 2010 
RC1		June 11th, 2010 
RC2		June 25th, 2010 
RELEASE		July 9th, 2010

Personalmente creo que acabará yéndose, en el más optimista de los casos, 
para finales de Julio. Y para la opción más pesimista, creo que será hacia finales 
de Septiembre, principios de Octubre.
Sea como sea, una muy buena noticia!!

Have a nice day ;-)
TooManySecrets

 

FreeBSD Status Report Enero-Marzo 2010

Ya está en la calle (desde ayer) el report de estado de FreeBSD para el primer trimestre de este año. Como siempre, viene llenito de cosas muy muy muy interesantes; el soporte del navegador web Chromium, el estado de Clang como compilador para substituir a GCC, el soporte de webcam, 802.11n, mejoras y avances en IPFW y dummynet, la implementación ATA basada en CAM, ZFS, SUJ (SoftUpdates con Journaling), etc, etc, etc... Vamos, para hacerle la boca agua a cualquiera.

FreeBSD Status Report Enero-Marzo 2010

Have a nice day ;-)

TooManySecrets

El Android Libre premia la fidelidad de sus seguidores.

El sitio web de referencia sobre Android El Android Libre, está premiando a sus seguidores con un sorteo. Esto es práctica habitual. El caso es que el sorteo no es cualquier cosa; sortean un Nexus One de Google, así como una camiseta de EAL + una chapa + muñequito Android.

Quien esté interesado puede leer las bases de su concurso, pero os puedo ir adelantando que el concurso da comienzo hoy día 21 de Abril, y se cerrará la participación el día 16 de Mayo a las 21 horas.

Esta es una web que para quien esté metido en el mundo Android, vale mucho la pena seguir, ya que nos brinda unos buenos artículos sobre diversos temas, como por ejemplo análisis, trucos, nuevos terminales, etc. Desde luego, desde que tengo mi Magic y me la recomendó mi amigo Raul (aka BgTA or BGAndroid) es una web que me gusta ir siguiendo por todos sus contenidos.

 

Configurar el automounter (AMD) de FreeBSD para compartidos samba.

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

OpenSolaris y el actual mega-FUD.

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

Subtítulos en vídeos del canal BSDConferences de YouTube.

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:

Vereis que el vídeo aparece subtitulado en inglés. Si mientras lo visionais pulsais sobre el vídeo para abrir el mismo en YouTube, una vez allí, vereis que en la barra de control del mismo hay un icono con dos CC blancas sobre fondo rojo. Pulsad el icono y os aparecerá el menú para traducir los subtítulos.

 

Have a nice day ;-)

TooManySecrets

Los SysAdmins somos una especie aparte.

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

 

Habilitar consolas virtuales en Opensolaris.

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