blog.interrupciones.net

El Filesystem Hierarchy Standard es una especificación que define una pautas y requerimentos para la construcción del árbol de directorios que constituye un sistema operativo tipo-UNIX. Algunas distribuciones GNU/Linux se adhieren a este estándar y otras no, los BSD tampoco. Algunos de los puntos pueden ser bastante discutibles, pero tiene aspectos interesantes.

Al principio me sorprendió que uno de los consejos fuera que el directorio /usr tendría que estar en una partición separada y montada como sólo lectura. Pero el objetivo es que /usr pueda ser compartido entre distintos servidores por red. A mi personalmente me parece más interesante pensando en aspectos de seguridad:  ¿quién es el guapo que mete un rootkit en los ejecutables de un sistema de sólo lectura?

Así que decidí montar en mi sistema el directorio /usr como read-only. Esta es la entrada correspondiente en el fichero /etc/fstab, en mi caso la partición correspondiente a /usr es /dev/sda6.

/dev/sda6    /usr    ext4    ro    0    1

Pero esto supone un problema, ¿cómo actualizo el sistema sin permiso de escritura en /usr? Fácil, el sistema puede remontarse (no hace falta desmontar y volver a montar, con el riesgo que esto supondría para la estabilidad), podemos usar mount con el parámetro remount para aplicar cambios en un sistema de ficheros montado. Ejemplos:

# mount /dev/sda6 /usr -o remount,ro
# mount /dev/sda6 /usr -o remount,rw

Lo que yo hice para facilitar las cosas fué añadir estas dos entradas de alias en /root/.bashrc

alias usrro='mount /dev/sda6 /usr -o remount,ro && mount | grep sda6'
alias usrrw='mount /dev/sda6 /usr -o remount,rw && mount | grep sda6'

Ahora puedo usar los comandos usrrw y usrro antes y después de actualizar el sistema. En estos comandos de alias, la parte que hay a partir de && es puramente informativa, así podemos asegurarnos que los cambios se han aplicado correctamente.

Si se diera el caso de que somos unos paranoicos de la seguridad, no estaría nada mal aplicar el mismo cuento a los directorios /bin y /sbin, aunque hacer particiones expresamente para directorios que ocupan tan poco puede parecer un poco ridículo. Quizás la solución sería que estos dos directorios, donde encontramos los comandos básicos del sistema, no estuviesen montados en una partición sinó en un fichero con la opción loop, aunque hay que tener claro que esto es peligroso, si se corrompiera dicho fichero nos quedaríamos con un sistema inusable.

Se aceptan ideas.

Una de las coas que más me ha gustado siempre de X.org (implementación de X Window System) es su capacidad para reiniciarse con una combinación de teclas.

Es un problema típico tener una aplicación colgada que está molestando al resto del sistema, hasta el punto de no poder hacer nada, pero si esta aplicación corre sobre el entorno gráfico y se nos permite usar el teclado podremos reiniciar todo este entorno sin tener que reiniciar todo el sistema operativo, cosa que es de muy agradecer.

Hasta ahora esto era tan simple como hacer Ctrl + Alt + Backspace, pero alguien ha decidido que esto es peligroso y confuso para el usuario. Y a partir de la versión 1.6.0 del servidor X.org esta función ha sido deshabilitada por defecto, con lo que más de uno ha roto el teclado intentando la maldita combinación.

Para volver a la configuración anterior, hay un montón de formas; al igual que hay un montón de formas de arrancar este software (con .xinitrc o con .xsession, con la configuración en /etc/X11/xorg.conf o al vuelo con HAL, etc). Veremos los casos más típicos:

Generalmente, aunque ahora X.org ya soporta el arranque sin archivo de configuración gracias a HAL, la mayoria de los mortales seguimos usando /etc/X11/xorg.conf para definir cómo queremos que se comporte, por lo tanto este es el caso que explicaré. Si queremos recuperar esa funcionalidad (conocidacomo zap o zapping) podemos añadir a xorg.conf las siguientes líneas:

Section "ServerFlags"
    Option  "DontZap" "false"
EndSection

Entonces buscamos la sección InputDevice y añadimos:

Option  "XkbOptions" "terminate:ctrl_alt_bksp"

Ahora, cuando hagamos iniciado Xorg de nuevo, podemos reiniciarlo con la famosa combinación de teclas.

Recientemente me he encontrado con el problema de tener un desorden brutal en mis archivos, y la necesidad de encontrar cuáles tengo duplicados y en qué sitios. El problema se complica, y mucho, cuando estamos hablando de un servidor que comparte discos en red y en el que acceden más de 100 usuarios todos los dias. El espacio usado en disco ha crecido rápidamente y tenemos sospechas de que hay cosas repetidas por todas partes… ¿cómo localizar las consecuencias del desorden colectivo?

Solución para BSD, GNU/Linux y otros UNIX

Descargamos la aplicación fdupes, que se autodefine como un programa para identificar o eliminar archivos duplicados que residen en los directorios especificados. Podemos compilarlo nosotros mismos o, como siempre, descargarlo de los repositorios de software de nuestro sistema operativo. El uso es así de simple:

$ fdupes <directorio>

Este comando compara el tamaño de cada archivo, su MD5 y finalmente hace una comparación byte a byte. Podemos añadir el parámetro -d para que nos vaya peguntando si queremos eliminar los repetidos. También tenemos opciones para seguir los directorios symlink e incluso para tratar archivos con hardlink.

Solución para MS Windows

Descargamos la aplicación findrepe, la descomprimimos en el directorio Archivos de Programa y luego, desde línea de comandos ejecutamos:

C:\Archivos de Programa> java -jar findrepe-0.5.1/FindRepe.jar --install

Ahora tenemos instalado el ejecutable findrepe.bat en el directorio de nuestro sistema, esto es sólo un script que llama a la aplicación Java pasándole los parámetros que nosotros deseemos, por esto es importante no eliminar los archivos descomprimidos al finalizar el paso anterior.

Ahora ya podemos usar el programa del siguiente modo:

C:\> findrepe c:\<directorio>

…y nos devolverá una lista de todos los archivos repetidos en dicho directorio. Además podemos pasarle más de un directorio o unidad como parámetros.

Warning: The next generation of the GRand Unified Bootloader (GRUB2) is still under development and therefore all usual points apply. GRUB2 may fry your computer, burn your house, make you breakfast or eat your cat. You’ve been warned! For most people, except those with more exotic configurations, GRUB2 should just work.

Visto en ArchWiki