Profundizando en PAM: Passwd sobre PAM (2/2)

conjuntoEntradas() {

 Profundizando en PAM: Passwd sobre PAM (1/2)
 Profundizando en PAM: Passwd sobre PAM (2/2)
}

La luz del final del túnel

Hace unas tres semanas tuve que cambiar el password porque estaba a punto de caducarse y como no el diablo que me perseguía apareció; harto de él y con ganas de enfrentarme a él, nos metimos en el lío.

Preguntando al Sr. Google, encontré un post de un tal Jason Howk, que habla de aplicar una política fuerte de contraseñas bajo Linux donde se explica cosas que ya sabía y otras no, concretamente lo del PAM; así que en el post encontré la madre del cordero.

PAM (Pluggable authentication module), permite definir un proceso de autenticación asociado a un ejecutable/proceso a modo de plugin, es decir que se integra sin la necesidad de alterar el binario o código fuente que lo requiere.

Así que una vez tener a partir de la definición como actúa y después de haber leído el post del tal Jason Howk entendí que con un fichero de configuración se puede definir el modo de autorización totalmente externa, llamando al servicio PAM, evitando que tengas que implementarlo, y encima puedes amoldarlo a tus necesidades, siempre y cuando haya un módulo PAM que haga lo que quieres, y sino lo hay, ya sabes que te toca implementarte uno.

Tirando del hilo

Cuando ya me había enterado que con un fichero de configuración de PAM se puede definir como se comporta el cambio del password de acceso al sistema a través comando passwd, concretamente el fichero /etc/pam.d/passwd, me fui a ver que había ahí dentro para ver porque sucedía lo de solicitar el cambio de password por duplicado y encontré esto

#%PAM-1.0
auth       sufficient   pam_rootok.so
auth       include system-auth
account    include system-auth
password   include system-auth

Como podemos ver en el fichero no se define nada, se delega cada grupo (auth, account, password), al fichero /etc/pam.d/system-auth, el cual tiene el siguiente contenido

auth  required pam_env.so 
auth  required pam_unix.so try_first_pass likeauth nullok 
auth  optional pam_permit.so
 
account  required pam_unix.so 
account  optional pam_permit.so
 
password required pam_cracklib.so difok=2 minlen=8 lcredit=1 ucredit=1 dcredit=2 ocredit=2 retry=3
password required pam_passwdqc.so min=8,8,8,8,8 retry=3
password required pam_unix.so try_first_pass use_authtok nullok sha512 shadow 
password optional pam_permit.so
 
session  required pam_limits.so 
session  required pam_env.so 
session  optional pam_mktemp.so
session  required pam_unix.so 
session  optional pam_permit.so

El fichero llama a varios modulos PAM en cada fase, y como no tenía ni idea que hacía cada uno de ellos me fui a buscar la documentación para tener una idea de lo que hace cada uno, bueno solo de los que he encontré de manera rápida, y poder definir el flujo de del servicio PAM que deseaba sobre el comando passwd.

Después de tener más o menos claro lo que hace cada módulo que aparecía en el fichero /etc/pam.d/system-auth, me puse a definir el flujo que deseaba sobre el comando passwd. No obstante, no alteré el fichero /etc/pam.d/system-auth, que es el que se referenciaba en todos los ficheros de configuración de los procesos/comandos que usan PAM, es decir como hacía el fichero /etc/pam.d/passwd, que delegaba la definición del flujo al fichero /etc/pam.d/system-auth, sino que modifque directamente el fichero /etc/pam.d/passwd.

El juicio final: definiendo el flujo PAM sobre passwd

Con la documentación y viendo el contenido del fichero /etc/pam.d/system-auth, me puse definir el contenido de /etc/pam.d/passwd, desde 0.

1. Quité todos los modules pam_permit porque solo con ver en la documentación la siguiente frase “PAM module that always permit access” a uno ya le queda bastante claro que no puede ser muy bueno, no obstante, por sino queda claro, la propia documentación te le deja más claro con la siguiente frase “This module is very dangerous. It should be used with extreme caution”.
2. Mantuve los módulos pam_env aunque actualmente en el fichero /etc/security/pam_env.conf está todo comentado, pero para un posible futuro puede ser útil que al meter configuraciones en él, se apliquen a las configuraciones existentes.
3. De los dos módulos de verificación de complejidad de contraseña, pam_passwdqc y pam_cracklib, para esta situación, opté por utilizar el pam_passwdqc.
4. Mantuve el módulo pam_unix, para sincronizarlo con el sistema tradicional de autenticación de los sistemas Unix, pero me cargué el parámetro nullok para dejar de permitir el acceso a usuarios sin password.
5. Al igual que pensé con lo que hacer con el módulo pam_env, pensé lo mismo con pam_limits, es decir lo mantuve a pesar de que el directorio /etc/security/limits.d/ esté vacío, para si establezco configuraciones futuras dentro de éste.
6. Mantuve pam_mktemp, a pesar de que en mi caso no se vaya a dar el caso de tener directorio home en sistemas de ficheros compartidos por la red, pero creí que no estaba de más mantenerlo.

El resultado de todo esto fue este

#%PAM-1.0

auth  required pam_env.so 
auth  required pam_unix.so try_first_pass nullok
 
account  required pam_unix.so 
 
password required pam_passwdqc.so min=disabled,disabled,15,10,8 passphrase=3 retry=3 ask_oldauthtok check_oldauthtok
password required pam_unix.so try_first_pass use_authtok sha512 shadow 
 
session  required pam_limits.so 
session  required pam_env.so 
session  optional pam_mktemp.so
session  required pam_unix.so

Final de la pesadilla

Y a aquí termino todo, una vez definido esto, comprobé que el comando passwd funcionaba correctamente y que solo me pedía el password (y claro está, su verificación) una sola vez.

Aunque seguro que está muy claro, menciono explicitamente el porque ahora no se pide el password más de una vez; básicamente es porque si nos fijamos en el fichero /etc/pam.d/system-auth, se realiza dos llamadas al proceso de verificación de complejidad, una sobre al módulo pam_cracklib y otra pam_passwdqc.

Para finalizar solo quiero decir que para realizar las distintas pruebas antes de definir por completo el flujo PAM sobre passwd cree un nuevo usuario en el sistema, para evitar que probando no me vaya a cargar el acceso de mi usuario habitual, y cuando todo funcionó, me lo cargué.


Hasta la próxima enfermos.

Profundizando en PAM: Passwd sobre PAM (1/2)

conjuntoEntradas() {

 Profundizando en PAM: Passwd sobre PAM (1/2)
 Profundizando en PAM: Passwd sobre PAM (2/2)
}

Introducción

En varias ocasiones leo o oigo hablar de algo que en un primer momento no conozco, en algunas de ellas tengo la oportunidad de preguntarle a la persona que está hablando que me explique lo que es, otras no tengo esa oportunidad y es cuando entonces decido preguntarle a Mr. Google, si puedo en ese mismo momento y sino en otro momento, es lo que tiene que siempre esté a tu disposición.
Una vez que he tenido una breve descripción de lo que es, entonces ya estoy en contexto, y normalmente (hablando de temas focalizados en el mundo de la informática) puedo comprender, lamentablemente no siempre al 100%, lo que estoy leyendo o lo que me están contando, si es el caso la problemática y la posible solución o mitigación.

Una de estas situaciones, aunque no recuerdo ni cuando ni donde, fue lo que me pasó con PAM; en ese momento me enteré de lo que era y luego cuando me hablado en otras ocasiones de algo donde PAM se siente involucrado no tengo problema en entender lo que me están contando.
Dejando de banda de como voy dando mis primeros pasos en este mundo tan amplio, me centro un poco en lo que es la entrada en sí.

Los inicios

Cuando decidí meter Gentoo en la mi máquina de casa, lo hice, intentando enterarme, de para que sirve y porque se hace todo lo que el handbook explica paso a paso, así consideré que era una manera de aprender aspectos que hasta el momento desconocía y añadir algún granito más al monto de conocimientos que voy almacenando sobre este enorme mundo; además, como el handbook en ciertos puntos deja abiertas indicaciones que se puede hacer esto y esto otro, en algunas de ellas me fui informando para hacerlo en un futuro o directamente me informé y me puse a configurarlo como me gustaría tenerlo, por eso que dicen de “no dejes para mañana lo que puedes hacer hoy”.

Una de esas cosas, fue securizar la configuración de acceso de las cuentas de usuarios del SO (/etc/login.defs), es decir meter un mínimo de valores en los parámetros necesarios para garantizar un password con longitud mínima y con una caducidad para, básicamente, auto-obligarme a cambiarlo de vez en cuando.

Con esto yo ya creía que todo estaba, de hecho en parte no porque no había puesto la mínima complejidad requerida, algo que me preocupaba poco porque by default me complico la vida en el momento de asignar passwords de acceso a cualquier sistema.

El día a día

Después de tener el sistema listo, el empacho me duró un tiempo, además empecé a liarme con otras cosas, demasiadas, que me ocuparon y me ocupan el tiempo para dedicarme, de nuevo, con mente y cuerpo a trabajar para el SO, eso sí, sin tener en cuenta las incidencias de actualizaciones, de despliegue de nuevos servicios/aplicaciones, etc., que me han ido surgiendo y algunas de ellas ya he ido comentando en alguna que otra entada de este blog.

Una de las cosas que me ha ido persiguiendo desde entonces es que cada vez que cambio el password, el SO me solicitaba dos veces, más bien dos pares de veces, el nuevo password.

Ejecución de passwd para cambiar el password de acceso al SO; se ve como se pregunta el password dos veces

¿El motivo? Ni idea, sino lo hubiese solucionado desde un primer momento; el hecho es que no me importaba mucho, ya que metiendo las dos veces el mismo se cambiaba y como estaba perezoso en googlear para buscar un poco para saber que puñetas pasaba, la cosa se ha quedado así hasta hace un par o tres de semanas.


Hasta la próxima enfermos.

Root power a lo old school

Después de haber caído de nuevo en la tentación de dar preferencias a otros temas profesionales y personales por distintas causas antes que a este blog, aprovecho esta tarde de sábado, de un fin de semana de esos que estoy agotado físicamente por liarme a organización de eventos deportivos, concretamente de BTT, para escribir una de las entradas que hace tiempo que tenía ganas de escribir.

Bueno después de lavarme la conciencia con excusas vamos al lío.

Menciono de antemano que nadie se tome el contenido de esta entrada como una buena práctica, y menos para usuarios no catalogados como frikis de muchos de las distribuciones Linux que corren por ahí, sino como algo totalmente de gusto personal, aunque muchas de los aspectos los argumente desde un sentido que pueda parecer racional. Advertidos estáis, paso a meterme de lleno en el tema.

Todos sabemos que desde ya hace bastante tiempo en gran parte de las distribuciones de Linux viene con la herramienta sudo instalada y con una configuración básica que permite ejecutar cualquier comando del sistema desde el usuario que se crea en la instalación del SO.

A mi la herramienta me parece cojonuda, pero cuando me topé con ella sin haber consultado su documentación y habiendo enterado de ella cuando volví a la carga con un SO Linux, después de un tiempo sin usarlo, me saltaron chispas al ver que no podía entrar con la cuenta de root al sistema; en ese tiempo sabático que me tomé después de haber terminado la universidad y haber empezado lo que podríamos llamar entre comillas “mi vida completamente laboral/profesional”, no estuve muy al día sobre el mundo Linux y los recuerdos que me quedaron fueron los de la universidad, tiempo en el que la herramienta sudo o no existía, o yo no la conocía, y con las distribuciones que tocaba, no venía instalada y preconfigurada como ahora viene, es decir, que cuando instalabas un Linux, metía las contraseña de root y luego según si eras aplicado y te dejabas recomendar, optabas por crear una cuenta sin privilegios administrativos para usar el sistema tu día a día.

El momento inicial me jodí y adopte lo que venía dado, ejecutar todo lo que necesitaba derechos administrativos con sudo.

El tiempo ha ido pasando, y finalmente en mi mundo personal (el de trastear por casa con los equipos que más utilizo) opté por seguir cultivándome con Linux, ya que en el mundo profesional estaba y estoy inmerso en el mundo Microsoft (que esto no se tome como una discriminación entre ambos, cada uno, como todo en este mundo, tiene cosas buenas y otras malas, cosas que nos gustan y que no nos gustan, pero yo soy de los de según lo que necesitemos optar por la que mejor cumpla las necesidades de cada momento, sin casarme con nadie); eso si mi cultivo no era el de productor agrario sino el del típico dominguero que tiene un huerto en su segunda residencia, es decir que gran parte de mi tiempo libre me dedico a jugar en este inmenso mundo de la informática, con ojos de generar beneficio económico, pero si no lo hay, me divierto un poco según lo que me voy topando y también si me va viniendo en gana.

Hace algún tiempo, le tocó el turno a profundizar un poco en el tal sudo; algo que no vino antes, porque como mi evolución del uso personal de un Linux, cambió de distribución, de una Ubuntu a una Gentoo, perdí de manera intrínseca las cadenas que me ataban a no ser el amo del sistema, y que vino más tarde porque me metí un poco en aspectos de la seguridad, añadiéndola a la lista de curiosidades tecnológicas que me gustan, aprovechando que encima, eran importantes para mi posición profesional actual.

Después de ver de manera general como funciona la herramienta, no es que sea un gurú de ésta, la configuré sobre mi Gentoo, para evitar tener que ir cambiando de cuenta cuando a la vez que administraba el sistema, por ejemplo lo actualizaba, tuviese que estar constantemente cambiando de sesión con mi cuenta de usuario cuando la tarea administrativa toma algún tiempo, ya que la opción de usar el sistema de manera convencional (navegar por internet, etc.) desde un Dios, no me gusta nada, porque ya somos muy vulnerables para encima meter más leña al fuego. No obstante la configuración no fue como la que acostumbra a venir por defecto en la instalación de varias de las distribuciones disponibles, sino que limité las aplicaciones y/o comandos a ejecutar como root desde el usual usuario, así creo que hay menos riesgo si me usurpan la contraseña de éste.

Mi vida con Gentoo fue tirando así, pero ya hace bastante menos tiempo, que decidí cambiar la configuración de sudo del Ubuntu que tengo instalado en mi netbook, máquina que uso para llevármela por ahí y para estar tirado en algún lugar de casa haciendo el ganso, como ahora mientras escribo este post, es decir que necesito que esté estable de manera fácil lo máximo posible y que el hardware esté disponibles sin tener que romperme mucho la cabeza, sin perder lo que ya he mencionado, estar inmerso en el mundo y filosofía Linux en mi tiempo libre. La configuración que establecí partió del mismo concepto que la de Gentoo pero como root continuaba sin ser accesible mediante una sesión tuve que investigar el porque, ya que hasta entonces lo ignoraba, descubriendo el porque no se podía iniciar sesión, que concretamente es porque la cuenta root es bloqueada con la opción --lock, comando passwd.

Descripción de la opción --lock del comando passwd

Así que activé la cuenta root con la manera tan fácil como asignándole un nuevo password ya que entiendo que al no haberme pedido ninguno en el momento de la instalación la cuenta estaba bloqueada pero no tenía ninguno asignado y si lo tenía lo desconocía, y desde ese momento ya podía hacer lo que siempre había deseado, que si quiero dedicarme a solo administrar la máquina no tenga que estar constantemente ejecutando sudo.

Bueno ya acabando con esto voy a responder algunas de las preguntas que yo mismo me hice.

1. Con el cambio que he hecho en la configuración de sudo ¿mi sistema es más vulnerable?
   Yo entiendo que no, incluso menos, porque habiendo quitado la configuración estándar de sudo, que viene por defecto en la instalación de Ubuntu, he eliminado aspectos, como el tiempo que se guarda la autorización, cambiándola a 0 segundos, es decir que cada ejecución de sudo siempre me pide el password, independientemente del tiempo que haga de la última ejecución, y además he limitado que V solo autorice un número limitado de comandas y/o aplicaciones en vez de poder ejecutar cualquiera de estos.
   
   
2. Ahora que root puede logearse en el sistema mi equipo ¿es más vulnerable?
   Podría ser lo si no le hemos asignado ningún password, o si hacemos mal uso de ella, utilizándola para otros menesteres que no sean los de administrar. Además, aunque tenga poco impacto, y sea una paranoia personal, teniendo otra cuenta con otro password que nos permita administrar la máquina, considero que es más seguro porque también exponer mucho menos el password, ya que usando sudo cada vez que ejecutas aplicaciones con derechos administrativos necesitas proporcionar el password de usuario exponiendo esté continuamente.
   
   
3. ¿Es aplicable esta configuración a todos los distintos perfiles/tipos de usuarios?
   Considero que no, que la configuración por defecto de la instalación del SO es más aceptable para un usuario si no conocemos a que tipo pertenece, ya que los usuarios que no son unos frikis de los sistemas, no les gusta hacer muchos esfuerzos en mantener dos cuentas de usuarios, teniendo que recordar dos passwords distintos, así que configurándolo como a mi me mola, creo que una parte de estos caería en la tentación de utilizar la cuenta de root como la habitual, dejando olvidado la de usuario, corriendo el riesgo que se corre ejecutando la mayor parte de las aplicaciones con derechos administrativos, y más concretamente hoy en día, con la manera masiva en que utilizamos los navegadores conjuntamente con Internet.
   
   

Hasta la próxima enfermos.

Gnome loves ConsoleKit

El otro día, como hago cada semana durante el fin de semana que es cuando uso mi PC de casa para frikear, me puse a actualizar el Gentoo que tengo instalado, es decir que ejecute el comando:

$ emerge --deep --update --newuse world

No obstante, como también siempre hago, revisé que es lo que iba a actualizar (opción -pv), y sin ver nada que me llamará la atención o actualizaciones que requieren que luego haga otra cosa, como actualización de las fuentes del kernel, las cuales me implican migrar el fichero de configuración de la versión anterior a la versión recientemente descargada y luego compilar y reconfigurar el boot, lancé la ejecución del comando mencionado.
Entre las distintas actualizaciones había la actualización del Gnome, escritorio que utilizo, a la versión 2.30.

Hasta aquí nada raro, se empezó a descargarse cada paquete en el orden estipulado, a compilarse y desplegarse. Una vez terminada las actualizaciones a reiniciar la máquina, y a partir de aquí fue cuando empezaron los dolores de cabeza por una estupidez, pero que se me alargo unas cuantas horas, todo por que Mr. Google, no me daba la respuesta que quería, con las preguntas que yo le hacía, seguramente porque no estaba haciendo las preguntas correctas.

Los inconvenientes que tuve después de actualizar, no eran graves, pero si toca pelotas:

1. No podía apagar, reiniciar, hibernar, etc. la máquina desde la sesión del usuario, sin privilegios, que utilizo día a día; no solo era porque no tenía derechos, sino porque en el menú de la interfaz gráfica no aparecían los botones correspondientes.
2. Los Pen Drives, que pinchaba no se automontaban, así que tenía que hacerlo manualmente desde un usuario con privilegios.

Después de leer varias historias de la peña que va preguntando en posts, otros que escriben en blogs, como yo estoy haciendo ahora, respuestas de listas de correo y otras de las distintas fuentes que corren por este mundo intangible, no encontré nada que me dijera como tenía que solucionar el problema.

Así que con todo lo que iba leyendo, iba enterándome de cosas que desconocía, y mezclándolas con las cosas que ya conozco, empecé a trastear en el sistema que si meto las entradas en el /etc/fstab de los Pen Drives, que si reviso la configuración de Gnome con el gconf-editor, a revisar los servicios iniciados, etc.

Algo que ya sabía y que debido a la antigüedad de alguna de la información que encontraba, no estaba reflejado, es que HAL (Hardware Abstraction Layer) ya no se usa, es decir que está deprecated, así que lo de cargar el servicio HAL, nada de nada; otras de las historias que me llevo a trastear eran las referencias que la peña hacía a udev y udisk y apartir de aquí, junto con la frase que venía a decir algo así como “Gnome necesita ConsoleKit para su correcto funcionamiento”, que obtuve de la documentación del propio proyecto de Gnome, me encaminé hacia la dirección correcta para solucionar el problema.

El servicio udev estaba iniciado, pero udisks no se iniciaba, daba un error al hacerlo, así que algo pasaba; a raíz de esto y de la frase que he comentado que obtuve de la documentación del proyecto Gnome, revisé si ConsoleKit estaba iniciado, y no lo estaba así que lo inicié y entonces si que udisks se iniciaba así que parecía que todo estaba solucionado, añadí al inicio del sistema la ejecución del servicio:

$ rc-update add consolekit boot

y a reiniciar para acabar de ver si solucionaba los inconvenientes.
Inicio sesión con mi usuario sin privilegios y buahlá ya tenía botones de apagar, reiniciar, suspender e hibernar la máquina y si pinchaba un Pen Drive, grrrrr, nada de nada, “espera, espera, ….. que antes he tocado el /etc/fstab y no lo he dejado como estaba, así que vamos a borrar esas entradas (la del Pen Drive) que había metido y que no he quitado”; y ahora sí los Pen Drives ya vuelven a automontarse de nuevo.

Así que solucioné los inconvenientes, me enteré de bastantes cosas, como habitualmente me pasa cuando me veo obligado a solucionar problemas, esta es una de las razones por las que instalé un Gentoo, y de rebote solucione el inconveniente que tenía desde el inicio del sistema, que las unidades ópticas (DVD-ROM, etc) no se automontaban, ¿porqué? Porque había metido las entradas en el /etc/fstab.

Así que ya sé para la siguiente vez que el Gnome haga cosas raras revisar si ConsoleKit está iniciado ya que con algún cambio del sistema puede que no se inicie o directamente haya desparecido de la lista de servicios a iniciar en el arranque del sistema.

Hasta la próxima enfermos.

Flexibilizando el almacenamiento

Después de un tiempo de haber probado y utilizado el método de alocación de alamencamiento en disco duros denominado LVM (Logical Volume Management) bajo la implementación de linux LVM2 (Logical Volume Manager version 2) he decidido escribir una breve entrada de él y de como empecé y como lo uso en mis máquinas.

Mis inicios
Todo empezó un día de esos en los que gozando de tener tiempo libre me dedique a trastear con una de mis máquinas; si no recuerdo mal ese día tenía la intención de hacer un ghost del disco porque hacía tiempo del último que tenía y normalmente me gusta tener uno que no sea muy antiguo, sobre todo cuando has invertido bastante tiempo cultivando el sistema y no quieres encontrarte un día con que toda la siembra se ha ido a tomar por culo.
Ese día visité la página de System Rescue, supongo que para intentar descargar la última versión, porque la copia que debía tener era de hacía algún tiempo, y que mejor que antes de hacer un ghost, que descargarse la últimar versión. Navengando por la página me tope con que en ella hay unos pequeños manuales sobre ciertas utilidades de linux, y en los cuales se explican un poco que son y que hacen esas aplicaciones y como se utilizan, sin detallar llegar al detalle de todas sus funcionalidades, sino más bien dando un pincelada para su rápida utilización.

Una de estas guías es de LVM2, y con ella es donde me enteré que es y que posibilidades tiene, provocando en mí un gran deseo por empezar a utilizar esta utilidad en mis máquinas e inducido por esa obsesión que tengo en siempre de pensar en el futuro y anticiparme a él, pensando y valorando las cosas antes de hacerlas, es decir no caer en lo de "pan para hoy y hambre para mañana".

Los primeros pasos
A raíz de esto, investigué un poco más sobre LVM2, sin llegar a leerme toda la documentación ya que el tiempo no me da para todo lo que me gustaría saber y priorizo en función de las necesidades, y en el caso de LVM2, por ahora solo lo he podido poner en práctica a nivel hogareño, no a nivel empresarial, ya que tampoco en mi empresa es que vayan a darme tiempo explicito para dedicarle él ni tiempo para implantarlo y por mi parte esto ya no me cabe en las numerosas horas extras, que sinceramente no repercuten positivamente en mis cuentas bancarias, ya que entonce podría poner un saco bajo la mesa del despacho, pero esto son otros temas que no tienen que ver mucho con este post.

Después de haber indagado un poco más en su funcionamiento, empecé a probar en el sistema que por aquel entonces utilizaba, un Ubuntu 8.04 Hardy Heron, utilizando un disco que tenía poca información, la cual volqué a otra partición y empecé a particionar el disco para luego empezar a jugar creando los volúmenes fisicos (Physical Volumes [PV]), los grupos de volúmenes (Volume Group [VG]) y finalmente los volúmenes lógicos (Logical Volume [LV]).
Durante mis juegos experimenté con varios sistemas de ficheros, y entre ellos NTFS, para ver que también funcionaba; también experimenté lo de crear snapshots y ver que realmente funcionaban.

Convivendo juntos
Después de ver que todo funcionaba como había leído y que eso me iba a permitir flexibilizar mi sistema, hace un poco menos de tiempo he empezado a convivir junto a él, aprovechando los últimos despliegues que he hecho en mis máquinas junto a la distribución Gentoo, permitiendo flexibilizar el almacenamiento de mis máquinas.

No he entrado en utilizar LVM2 sobre la partición root, por ahora he querido mantener una partición de disco normal para albergar los ficheros del sistema operativo y de las aplicaciones y lo mismo para la partición de arranque (boot); porque aunque pueden crecer, sobre todo más bien en el caso de la root, debido a la instalación de múltiples utilidades; he creído que con el espacio de disco que tengo en las máquinas actualmente voy sobrado para tener una partición adecuadamente grande que me permita albergar el sistema operativo y todas las utilidades que le acabaré metiendo con el paso de los días y si crece desmesuradamente empezare a pensar que algo me está contaminando el sistema (virus, intrusiones, etc).

Mi utilización del LVM2 ha sido para albergar el home, permitiéndome redimensionar el tamaño de este árbol de directorios en función de la información, personal, que vaya almacenando, algo bastante difícil de prever y a la vez tengo la posibilidad de crear snapshots cuando crea conveniente hacerlo, por ejemplo, cuando voy a hacer una modificación importante o una reorganización considerable, sobre todo cuando en ella se ve implicada información de trabajo (esto no quiere decir que no haga copias de seguridad, estas también las hago). Además en el home también almaceno los disco (virtuales) de mis máquinas virtuales, y aunque intento utilizar un disco independiente para almacenarlas, debido al tamaño que tengo como disco independiente el cual difícilmente voy a ocupar completamente con estos, el LVM me da la posibilidad de utilizar parte de él para almacenar más información personal, en el caso que me haga falta, sin tener que ubicar la en otro directorio; simplemente redimensiono el grupo lógico donde albergo la información personal y de esta manera puedo mantener la organización de directorios que he utilizado hasta el momento.

Conclusiones
LVM2 me permite flexibilizar el almacenamiento de mis máquinas, asignando y reasignando las particiones de los discos físicos que tengo en mi máquina o los futuros que pueda meter, a los distintos directorios de información los cuales gestiono con grupos y volúmenes lógicos.


Detallando esta experiencia creo que alguien puede valorar y ayudarle a razonar si le puede ser útil o no utilizar LVM2 en su sistemas hogareño, ya que a nivel empresarial creo que el juego que da este sistema está más que justificado.

Hasta la próxima enfermos.

Gentoo: Domesticando a la criatura (2/2)

conjuntoEntradas() {

  Gentoo: Domesticando a la criatura (1/2)

  Gentoo: Domesticando a la criatura (2/2)

}

Configurando el kernel

Este es uno de los puntos clave el proceso de instalación y dónde parece que estemos en el punto más clave de la domesticación.
Aunque el kernel va a ser el centro de nuestro de sistema, ya que el funcionamiento básico del sistema y el resto de parte del sistema depende de éste, para mí no es el único, ya que el resto de configuraciones del proceso de instalación comentadas en el post 1, de esta serie, son de vital importancia a la hora de compilar y optimizar las múltiples herramientas que día día vamos ir metiendo le a la criatura y vamos a usarlas con cierta regularidad. No obstante el kernel coge mayor relevancia cuando nos encontramos configurándolo para una máquina con una función específica como podría ser un servidor con un rol determinado, pero en mi caso actual, es para una máquina de trabajo, así que lo que necesito son las herramientas que voy a ir necesitando para poder trabajar, experimentar y hacer el capullo el día a día.

Dejando de lado mis creencias, me leo el capítulo del handbook dedicado a la configuración del kernel, claro está ignorando la alternativa de utilizar genkernel.
Antes de contaros mis aventuras entre el enorme mundo de las opciones del kernel, quiero hacer especial mención a la frase: "Manually configuring a kernel is often seen as the most difficult procedure a Linux user ever has to perform. Nothing is less true -- after configuring a couple of kernels you don't even remember that it was difficult ;)", y solo indicar que el tío que ha escrito esto tiene mucha razón, después de mi primera configuración ahora me cuesta bastante poco reconfigurarlo para amoldarlo a mis necesidades.
Bueno vamos al lío, hacemos lo que dicen las instrucciones, es decir compilamos el menú de configuración y una vez dentro de él activamos, como buenos niños, lo que nos indican que es básico para que nuestro sistema, por lo menos, arranque. Posteriormente empecé a mirar casi de una en una las múltiples opciones que se pueden activar o modularizar o desactivar y por supuesto activando las en el caso que vea que carguen algún driver de mi hardware.
A lo largo de mi andadura por el mundo de las opciones del kernel, me veo obligado a, cuando no sé de que puñetas me estaban hablando, documentarme un poco para no ignorar esa opción a la ligera y entre esto y algunos aspectos de redes que ya sé de que iban a raíz de documentarme cuando configuré los trunks en las empresa y descartando las opciones que hacen referencia a hardware muy concreto, por ejemplo de sistemas embedidos, no me costo mucho más de una tarde y media, enteras, en hacer mi primera configuración después de varios años de haber tocado esta distribución y no haber vuelto a jugar, desde entonces, con un kernel de Linux.

Bueno finalmente configuré mi kernel y aprendí varias cosas, entre ellas:

• Pinceladas de ciertos aspectos de la arquitectura de un sistema Linux actual, a raíz de documentarme con ciertas opciones que de un inicio no tenía ni p... idea de que iban.
• El gran número de opciones que tiene el kernel 2.6 de Linux y gracias a ellas poder optimizar tu sistema según tus necesidades.
• Mientras lo configuraba me tuve que enterar de que implicaciones tenía modularizar o activar directamente, para tomar la mejor decisión; sobre este hecho leía que habían detractores de cada una de las opciones, unos dicen que mejor modularizar porque así tu Kernel ocupa menos memoria RAM y por otra parte los detractores de modularizar dicen que cargando los módulos al no estar contiguos en el espacio en memoria ocupado por el kernel (cargado durante el inicio del sistema) los accesos son más lentos, así que yo he decidido activar todo lo que quiero que siempre esté cargado porque a estas alturas con la de RAM que les metemos a los sistemas no me va de que el kernel ocupe unos cuantos kilobytes más y modularizar lo que voy a usar de manera esporádica así solo cargo cuando lo necesite no siempre. ¿de cual sois vosotros detractores?

Hasta la próxima enfermos.

Instalando Marvell Yukon Ethernet Controller en Ubuntu

Después de un tiempo sin poder dedicarme a dejar bien configurado mi Netbook el cual ya compré hace algún tiempo, finalmente me he decidido dedicarle un rato, hoy mismo, para dejar funcionando la tarjeta ethernet integrada en el sistema operativo que le puse desde el primer momento que lo tuve, que es concretamente un Ubuntu 9.10 Netbook remix. Si ya sé que alguno podéis llegar a pensar que como es que no lo hice desde un primer momento, pues esto se reduce a básicamente 3 aspectos:

1. Falta de preferencia de mi tiempo libre para dedicarle a esto.
2. El aspecto 1 se debe a que la tarjeta Wireless Broadcom si que fue detectada en la instalación base.
   
3. El aspecto 2 queda justificado por los 2 objetivos por el cual lo compré, que fueron tener menos pereza en cargar un ordenador a cuestas y para que en los momentos de mayor pasividad no me diera tanta pereza estar delante de un ordenador; este último objetivo implícitamente requiere el uso de la wireless, ya que en esos momentos es cuando necesito estar en el sofa o en la cama, por lo que los cables me sobran, además debido a esto inicialmente no me día cuenta que el sistema operativo no la había detectado.
   

Bueno ya no me enrollo más y paso a explicar la aventurita de instalar el driver, que me ha llevado un rato algo largo, pero como siempre a parte de ahora tener la tarjeta ethenet funcionando me ha llevado a aprender, como siempre, alguna cosa más.

Buscando el dispositivo
He empezado buscando el fabricante del dispositivo que lleva el Netbook porque aunque alguno de vosotros penséis que como es que no podía saberlo, pues básicamente se debe a que cuando compré el Netbook no miré concretamente que tarjeta ethernet llevaba.
Esto fue fácil de solucionar buscando en la Web de HP el modelo y viendo con que hardware se comercializaba; esta vez ha sido fácil ya que en el caso de la ethernet solo habían utilizado un fabricante y modelo, concretamente se trata de una Marvell Yukon Gigabit Ethernet.

Buscando el driver
Aunque parezca una parida, resulta que encontrar el driver apropiado para linux no lo ha sido tanto, por tres motivos:

1. En los repositorios de paquestes de Ubuntu no hay o no he encontrado un driver; por lo que se jodió la instalación más fácil y rápida a la que podía optar.
   
2. HP no ofrece drivers para linux para este Netbook.
3. Resulta que los drivers te los puedes descargar de dos lugares, de SysKonnect y de Marvell, siendo distintos.
   

Bueno, así que me descargo los dos el SysKonnect y el de Marvell.

Analizando los drivers
Una vez descargados, que en el caso de Marvell he descagado el que indica para kernels de la versión 2.6 pero con una coletilla que pone "Fedora", les he echado un vistazo rápido y ya he visto que el de Marvell es de una versión superior, concretamente la 10.84.3.3 frente a la 10.70.1.3 de SysKonnect.

Después he leído detalladamente el README del driver de Marvell y ver que cumplía con todos los requisitos de instalación, he visto que hay dos modos de instalación, uno llamado "Modo de Instalación" y otro "Modo de Generación de Parche"; por lo que he leído más adelante en mi caso lo que quiero es instalarlo no parchear un kernel para que luego el driver quede integrado en las fuentes de este y pueda ser distribuido con este driver añadido.

Una vez ya he tenido claro el proceso de instalación he decidido echarle un ojo al README del drivers de SysKonnect y con un simple vistazo vemos que son iguales; así que dando se esta divergencia, claro está que he optado primero por probar con el de Marvell que es de versión superior.

Instalando los drivers
La primera prueba
Lo primero que he probado es lo más sencillo que uno puede hacer, que es ejecutar las instrucciones y ver si todo funciona y no se genera ningún problema.

Como el resultado no ha sido satisfactorio, he hecho lo mismo con de SysKonnect y el resultado ha sido el mismo, así que va a tocar mirar los errores generados.

Chequeando los errores
En ese momento he empezado a mirar si los errores eran parecidos en un driver y en el otro y efectivamente lo eran así que me quedo con el Marvell definitivamente, ya que es de versión superior como ya he comentado anteriormente.

El primer error que me ha aparecido al lanzar la instalación

$ sudo ./install.sh

parecía que era un problema del código del script de instalación, pero después de buscar un poco google, he encontrado en un post, que se soluciona fácilmente cambiando el intérprete de comandos indicado en el script de "#!bin/sh" a "#!bin/bash" y el error que daba de que la sintaxis era incorrecta para un "(" después de la declaración de la primera función del fichero "functions", incluido con los ficheros de instalación, se solucionaba.

Una vez solucionado este pequeño mal entendido he vuelto a ejecutar la instalación y me he encontrado con un error que indicaba que no encontraba las fuentes del kernel, ya que lo que va a hacer es recompilar el driver para el kernel que se esté usando. He empezado mirando el synaptics y he visto que si tenía instalado las fuentes del kernel (los headers) así que algo pasa que no los encuentra.
A raíz de eso, he mirado un poco más específicamente y he visto que lo que necesita es generar un link en /usr/src llamado linux que apunté a los headers del kernel que estas corriendo, por lo que manos a la obra:

$ sudo ln -s /usr/src/linux-headers-2.6.31.19 /usr/src/linux

Después de esto, volvemos a probar y el resultado es que nada que continua fallando, indicando que o que las fuentes están corruptas o que no coinciden con la versión del kernel que se está ejecutando, así que ejecuto el siguiente comando para ver que versión estoy ejecutando y poder comparar a que versión de las fuentes he creado el link

$ uname -r
2.6.31-19-generic

Así que la he cagado de dos posibilidades que habían (ya sabía que estaba utilizando la 2.6.31-19, por lo que los headers de versiones anteriores los había descartado), he linkado con la que no era ,así que he cambiado el link

$ sudo rm /usr/src/linux
$ sudo ln -s /usr/src/linux-headers-2.6.31.19-generic /usr/src/linux

De nuevo he vuelto a ejecutar y otro vez ha fallado, viendo que estaba sucediendo he visto que ahora lo que no ecuentra es las fuentes del kernel pero esta vez accediendo desde "/lib/modules/2.6.31-19-generic/source", así que viendo que hay en ese directorio, veo que "source" no existe y ¿porque no?, pues no lo sabía pero después de ver que haya en ese directorio he visto que había un link llamado "build" que apuntaba a "/usr/src/linux-headers-2.6.31-19-generic", así que he decidido probar de linkar "source" al mismo lugar

$ sudo ln -s /usr/src/linux-headers-2.6.31.19-generic /lib/modules/2.6.31-19-generic/source

Y de nuevo he vuelto a probar y esta vez sí, se ha compilado, instalado y cargado el módulo en el kernel.

Conclusiones
Con todo esto he aprendido a que tampoco están difícil compilar e instalar un dirver para linux si el script esta bien hecho, solo tienes que tener un compilador (lo más habitual es el gcc), las fuentes del kernel que estas ejecutando y los links correctos a los directorios donde se encuentran las fuentes.
Por cierto el módulo se llama sk98lin, por si alguien en algún momento se necesita descargarlo o cargarlo manualmente.

Hasta la próxima enfermos.

Gentoo: Domesticando a la criatura (1/2)

conjuntoEntradas() {

  Gentoo: Domesticando a la criatura (1/2)

  Gentoo: Domesticando a la criatura (2/2)

}

Después de meteros el rollo, en el post anterior, de como empecé mis aventuras con la distribución Gentoo, voy a contar, como ya anticipé, las aventuras que voy viviendo con mi retorno.

La instalación base

Después de descargar el live CD y quemarlo (aquí no doy explicaciones, ya que sería ridículo), empecé la instalación de la criatura en mi máquina.

Enciendo la maquina, meto el CD y arranco desde él. Una vez ya se ha cargado el Linux del live CD empiezo a seguir los pasos que se especifican en el handbook.Voy haciendo lo que pone y a la vez entendiendo lo que voy haciendo, es decir nada de ejecutar instrucciones una tras otra sin saber que puñetas hacen, y entonces me topo con el primer punto que me toca documentar me un poco para conseguir una criatura bien domesticada.

Configurando los flags del GCC

Leo el párrafo del handbook y la breve explicación de unos cuantos de los flags ya me empieza a despertar las ansias de saber más de cada uno de ellos y de los valores que se les pueden dar por tal de domesticar la criatura a mí máquina y así conseguir que todo el software que compile, que es la mayoría del que se instala desde el portage de Gentoo, esté lo más optimizado para mi propia máquina.
Para ello voy a la documentación del propio gcc y veo que hay mucho que leer, como no dispongo de tanto tiempo, y el objetivo actual no es conseguir ser el un gurú del gcc, leo con especial atención el capítulo dedicado a los flags de optimización para la arquitectura i386 y x86-64, a la que pertenece mi máquina.
Después de leerme el capítulo, y con la intención de domesticar la criatura lo mejor posible decido indicar al compilador que lo que compile lo haga exclusivamente para mi arquitectura (-mtune=native) además de activar otros flags y darles el mismo valor que el handbook recomienda.

Configurando los USE flags

Después de tener al domador configurado (el gcc) toca configurar los USE flags. Los USE flags son un conjunto, bueno mejor dicho un enorme conjunto, de flags que se activan o se desactivan asignando los a la variable de entorno USE, bueno concretamente también hay otros ficheros de configuración donde indicarlos pero en la fase de instalación podemos ignorarlos y dejarlos para cuando ya estemos en la fase de afinamiento del sistema.
Estos flags son utilizados por el portage de Gentoo para especificar la configuración, funciones adicionales y/o librerías concretas a utilizar por parte de las funcionalidades del paquete a instalar.
Hay USE flags genéricos, es decir que indican lo mismo para los distintos paquetes que los soportan y otros que en función del paquete se producen resultados algo distintos. A raíz de esto y del gran número de flags que hay es difícil desde la instalación inicial activar y desactivar todos los que realmente deseamos ya que revisar todos los flags de todos los paquetes básicos que el sistema necesita puede ser un tarea bastante tediosa, además cuando activas ciertos flags se añaden nuevos paquetes que a su vez pueden tener flags los cuales no habían aparecido en la lista de paquetes a instalar que anteriormente teníamos.
Por mi parte considero que la mejor opción es revisar por encima los flags que hay, especialmente los genéricos o los que veamos que puedan influir en el core del SO y posteriormente ya afinaremos activando y desactivando los flags a medida que vayamos instalando nuevos paquetes, y en el caso que se active alguno que no se había activado el portage ya nos indicará que tiene que recompilar el paquete.
Para concluir, solo indicar que hay flags excluyentes, es decir que si se activa uno otro tiene que estar desactivado o sin indicar (entonces es como desactivado pero no se está indicando de manera forzosa) y también se puede dar el caso que al activar ciertos flags sea necesario recompilar ciertos paquetes que a raíz de esto se provoque una dependencia cíclica entre ciertos paquetes, teniendo que resolverla manualmente debido a que el sistema del portage (comando emerge) no puede resolverlo de manera autónoma, así que nos va a tocar recompilar individualmente uno de los paquetes activando y desactivando de manera temporal los flags que provocan la dependencia cíclica.

Hasta la próxima enfermos.

Aprendiendo a ostias

Después de bastante tiempo sin escribir nada en el blog, algo que me avergüenza, estoy escribiendo este post que ya tendría que haber escrito hace ya un tiempo cuando empecé a jugar de nuevo con la distribución de Linux, Gentoo.

He dicho, que he empezado a jugar de nuevo, porque con ella ya estuve jugando a eso del año 2004, cuando estaba realizando el tercer trimestre del fatídico curso de tercero de carrera, sin duda el más duro, ya que el primer trimestre era de locos, el segundo más de lo mismo y el tercero dependía un poco de las ganas y motivación que te imaginabas que tendrías por aprender lo máximo posible y acabar la carrera en sus cuatro apretados años que la universidad (en la que yo estudié) estipulaba; aunque era luego, cuando estabas metido en el meollo, cuando realmente te dabas cuenta que tendrías que haber matriculado un poco menos de asignaturas para no acabar en el podio del "ranking de estresados" o en el "número de asignaturas con convocatorias anuladas".

Bueno dejando la dura vida del estudiante a parte, como decía empecé jugando con esta distribución sobre mayo del 2004. En ese momento, motivado, en parte, por el revuelo que la distribución tuvo entre algunos compañeros, la instalación podía hacerse desde el stage 1, el stage 2 y el stage 3, y no recuerdo si había la posibilidad o no de instalar el SO sin tener que compilar absolutamente nada, es decir como cualquier instalación de otra distribución de Linux que muchos habremos hecho alguna vez. En ese momento, de esas 3 posibilidades, la que más me llamó la atención era la que más trabajo y tiempo tenías que dedicar, pero que sin duda, la que más cosas aprendería, como ya debéis suponer estoy hablando de la stage 1.

La instalación la hacías y se continua haciendo igual actualmente, siguiendo el manual denominado handbook, donde se explican en detalle los pasos a seguir para acabar con el SO arrancándo se y ejecutando se en tu máquina. Aunque el handbook es muy completo, dificilmente te escapas de que en algún momento no cuadre lo que allí pone con lo que tu estas viendo o con lo que pone que utilizan y que si tu máquina no tiene eso utilices el que le toca, por ejemplo con el caso de un driver; ni de lejos te vas a encontrar de como instalar el SO en tu máquina, sino en una máquina similar a la tuya, algo lógico, ya que con la de miles de modelos de máquinas que hay es imposible documentar la instalación en todas.

El stage 1, era fenomenal si lo que querías era atentar contra el medio ambiente, ya que ibas a dejar tu máquina chupando recursos eléctricos durante un buen rato. Si no recuerdo mal, el stage 1, compilabas el bootstrap del sistema operativo, cuando terminabas estabas en el stage2, donde compilabas todo lo básico que el sistema operativo necesita para ejecutarse a excepción del kernel y en el stage 3, compilabas el kernel, después de configurar lo que querías meter en él o si no querías estrujarte un poco más el celebro podías optar, igual que ahora, por compilar lo que se denomina el genkernel, que básicamente es una configuración por defecto que lleva todo lo que seguramente vas a necesitar ahora y/o en el futuro, y si no lo usas, es igual lo tienes por si en el algún momento lo necesitas.

No recuerdo cuanto CO2 debí emitir a la atmósfera durante toda la instalación, lo que si recuerdo es que el stage 2 fue el que estuvo más tiempo la máquina compilando, fueron algo más de 24 horas, aunque la máquina que estaba usando no era de lo último que corría en esa época, recuerdo que era un P-III a 550 Mhrz, y que la había reciclado de vete tú a saber. Después de eso no recuerdo mucho más los problemas que tuve, si que recuerdo que configuré yo mismo el kernel, es decir que no usé el genkernel y que posteriormente le instalé como escritorio Window Maker.

Esa máquina, la construí, con mucha ilusión y motivación, y gracias a estas dos cosas superé todos los problemas que fui teniendo y que también pude aguantar porque tenía mi máquina habitual de trabajo funcionando y así no me vi limitado en continuar haciendo las obligaciones del día a día. Además de construirla para aprender y probar cosas nuevas, el objetivo fue convertirse en un servidor casero, y así fue, se convirtió en un servidor casero donde configuré algún que otro servicio como el SSH, el FTP y alguno más. Más tarde, durante el verano lo utilice para hacer el trabajo de la beca que conseguí en un departamento de la universidad y que posteriormente me renovaron en octubre y con ello dejé el trabajo que desempeñaba en Esteyco S.A.P. y donde actualmente vuelvo a trabajar, lo que provocó que continuase utilizando esa máquina pero esta vez de manera remota ya que me sirvió para hacer pruebas de comunicaciones seguras utilizando la librería OpenSSL y en la cual se basó parte de mi proyecto final de carrera.

Más tarde cuando terminé la carrera, abondoné esa máquina, para hacer otras cosas y también porque empezó a tener problemas de hardware, por lo que finalmente desapareció de mi vida y junto con ella también lo hizo Gentoo.

Fueron tiempo que ahora he querido recordar y he buscado entre el poco tiempo libre que me queda entre las obligaciones y responsabilidades que tengo, para volver a jugar y aprender cosas nuevas, con esta distribución y que poco a poco os iré contando en distintos post con todo lo que me he ido encontrando; esperando no alargarme tanto tiempo entre uno y otro, como me ha pasado entre este y el anterior.

Hasta la próxima enfermos.