Hace un tiempo que me instalé una Debian en mi portátil. Pero como este trasto HP Pavilion x360 es un poco especialito no me dejaba configurar la tarjeta de red inalámbrica. Y la verdad me ha costado que a pesar de que sí que aparecía al buscar con comandos como 

# dmesg

O

# lspci -vnn | grep -i 14e4

Al menos estos los tuve que lanzar unas cuantas veces.

También están los distintos drivers e historias que tiene Debian en su repositorio. Eso sí, hay que acordarse antes de poner en el fichero /etc/apt/sources.list el parámetro non-free a la ristra de los que ya tiene la url del repositorio.

deb http://url contrib ... non-free 

Y con 

# apt-cache search broadcom

Instalar los paquetes adecuados. Ahora mismo no los tengo a mano pero eran algunos como broadcom-sta-dkms, broadcom-sta-source, firmware-43-installer o similares. Al final el que te dirá qué módulos te pueden funcionar para tu tarjeta es el comando lspci en la sección Kernel driver in use (aunque realmente no es del todo cierto).

El driver que en mi caso me ocupaba era wl. Pero buscando tanto en los logs como en dmesg o incluso ejecutando 

# modprobe -vv wl

No había manera de que funcionara. Es más, en este último caso me devolvía un error. Por cierto, para el que no lo sepa, las "v" son para que devuelva más información. Un posible error que me salía (he tenido que buscar el ejemplo ya que  no lo documenté):

modprobe: ERROR: could not insert 'wl': Required key not availablemodprobe: ERROR:../libkmod/libkmod-module.c:977 command_do() Error running install command for wl
modprobe: ERROR: could not insert 'wl': Operation not permitted

No recuerdo si era con modprobe, pero sí buscando en resultados del dmesg o journal una línea muy interesante:

Kernel is locked down from Kernel configuration; see man kernel_lockdown.7

Esto viene a querer decir que si se tiene activado el arranque seguro y el driver no está firmado no se podrá instalar. ¿Solución? Los hay que tiran por la calle de en medio: "deshabilita el arranque seguro". Pero hay otra solución. Crear un certificado de firma, instalarlo en la máquina y después firmar el driver. 

¿Cómo creo que certificado de firma?

Me encontré un tutorial bastante interesante en la pregunta de un foro en ITecTec. Y la verdad es que funcionó mucho mejor de lo que esperaba. Pero antes de nada conecta la máquina con un cable de red, actualiza todo el sistema y asegúrate de que tienes instalado linux-headers. Al menos en algún punto me suena que los instalé. Repasando algunas rutas estoy viendo que es muy posible que instalara build-essential y linux-headers-generic. Ya contaré esto último más adelante. Antes de que empieces con lo siguiente: más adelante te tocará preparar un script porque el driver dejará de funcionar cada vez que se actualice el kernel.

Vete a una carpeta. En mi caso hice con el usuario root directamente.

1. Situate en una carpeta fácil y créate una en la que vas a crear los certificados. Por seguir ele ejemplo: module-signing. 
1. # mkdir module-signing
2. Entra dentro de la carpeta:
1. # cd module-signing
3. Ahora crearemos nuestro certificado de firma:
1. # openssl req -new -x509 -newkey rsa:2048 -keyout mok.priv -outform DER -out mok.der -nodes -days 36500 -subj "/CN=Nombre/"
4. Le reasignamos los permisos para que sólo tenga lectura por parte del propietario:
1. # chmod 600 mok.priv
5. Con la herramienta mokutil nos pedirán asignar una contraseña que (parece ser) apenas se usará un par de veces y con esto se instalará el certificado en algún punto de la UEFI:
1. # mokutil --import /rutaCompletaCertificados/mok.der

¿Cómo instalo certificado de firma en la UEFI?

1. Una vez hayas introducido la contraseña apaga la máquina. ¿No te sale el grub por defecto? Tendrás que vigilarlo y hacer lo que siempre hagas para que te aparezca. De todas formas, en este paso debería de aparecerte en la pantalla un menú que nunca has visto. Había un pequeño paso adicional que no indican en el ejemplo y no me acuerdo cuál. Pero una selección por descarte. ¡Ah! Los teclados externos podrían no funcionar.
1. Presionar cualquier tecla cuando te lo pidan si quieres acceder al MOK.
2. Selecciona "Enroll MOK"
3. Selecciona "Continuar" o "Continue"
4. Me suena que en mi caso salió por aquí ese otro paso.
5. Seleccionar "Yes" o "Sí".
6. Introducir la contraseña del certificado.
7. Aceptar para continuar el arranque. Recuerda: si no te suele salir el grub, es posible que te arranque el sistema por defecto y tengas que arrancar tu Linux como siempre lo hagas.

¿Cómo firmo el módulo?

1. Ahora puedes firmar el módulo en cuestrión:
1. /usr/src/linux-headers-$(uname -r)/scripts/sign-file sha256 /rutaCompletaCertificados/mok.priv /rutaCompletaCertificados/mok.der /rutaCompletaMódulo

Con estos pasos ahora si ejecutas modprobe tal y como hicimos al principio del artículo dejará de darte problemas.

Otros cambios realizados

La verdad es que entre medias hice otros cambios que se proponían y que a pesar de que no hacían lo que esperaba creo que también funcionaron bien para otras historias. 

En los parámetros del kernel en el grub puse dos parámetros adicionales:

• pci=biosirq
• acpi_osi= (tal cual. Así es como lo ponían en la página donde lo encontré)

La verdad, no he sido capaz de encontrar qué hacen pero sin estos alguna cosa no acaba de funcionar.

Una ruta interesante en la que se explican los distintos módulos de Broadcom está en Ubuntu. 

Sorpresa

En todo este proceso para instalar los drivers de la tarjeta inalámbrica Broadcom 43142 no sé cómo el se consiguió instalar el grub en el almacén de sistemas operativos accesibles por la UEFI. El problema está en que a pesar de que los ficheros necesarios para poder arrancar el sistema sí que se guardaban en /boot/efi/ el siguiente paso era que la UEFI lo identificara automáticamente y no había manera. Por lo tanto tocaba forzar a darle al F9 en el arranque, navegar por la ruta mencionada y seleccionar el fichero shimx64.efi. El comando que intentaba usar para crear en la entrada que necesitaba la UEFI era algo parecido a

# efibootmgr -c -d /dev/sda -p 3 -L "etiqueta" -l \EFI\"label"\grubx64.efi

Pero como digo, me decía algo así como "el directorio no existe". 

Pues bueno, para resumir, con todo el lío que he hecho para que se inicie la tarjeta de red inalámbrica, la entrada se ha puesto ella solita. Por lo que ahora en el menú de la UEFI puedo indicarle qué sistema quiero que arranque. En mi caso será el grub, que a su vez me permitirá lanzar Windows cuando quiera.

OpenMediaVault y dupeGuru

Hace menos de una semana me instalé en una máquina OpenMediaVault, una distribución Linux para montar un NAS. 

De momento estoy intentando hacerme con el sistema. La idea es hacer backups de los datos, sobre todo de los distintos discos que tengo dispersos. Pero de momento tengo que tener cuidado porque no he podido configurar la redundancia de los discos. Ya veré si acabo contando algo sobre la configuración después de su instalación (como cualquier otro Debian). 

Uno de los módulos que tiene es la posibilidad de instalar containers en de docker. En OpenMediaVault 5 usan Portainer. La verdad, nunca había trabajado con Portainer (realmente nada de docker). Y para la instalación de los distintos stacks (¿son como las imágenes que después puedes pedir que se carguen como si fuesen máquinas virtuales?), que son realmente las aplicaciones con las que se trabajan, se puede hacer pasando la URL de un git, subiendo un fichero de texto escribiendo el contenido de ese fichero en el textarea. Sé que es un poco lío (y cuando lo lea dentro de unos meses me llevaré las manos a la cabeza sorprendiéndome de lo mal que me expreso).

Resumen: quieres instalar una aplicación de docker, escribes una ristra de parámetros con su sintaxis, y si es capaz de encontrarla con esos parámetros, la instala.

Una de las aplicaciones que se proponen para buscar ficheros repetidos es dupeguru. Es muy básica y por lo que he podido averiguar, no verifica los hashes. Ya buscaré otra que lo haga. El problema es que no hay publicada la estructura que hace falta para esta forma de instalar y para esta aplicación.

Para ver si podía instalarla del mismo modo que lo hice con una anterior que sí lo tenían publicado lo que intenté hacer es basarme en los sus parámetros y después cambiar o añadir los valores necesarios.

Este es el resultado:

---
version: "2.1"
services:
  dupeguru:
    image: jlesage/dupeguru
    container_name: dupeguru
    environment:
      - PUID=XYZ
      - PGID=ZYP
      - TZ=Europe/Madrid
    ports:
      - 5800:5800
      - 5900:5900
    volumes:
      - /srv/dev-disk-by-_______/dirConfigs/dupeguru:/config
      - /srv/dev-disk-by-_______/carpetaVirtualRaiz:/storage
      - /srv/dev-disk-by-_______/trash:/trash
    restart: unless-stopped

El PUID y el GUI se consiguen accediendo por ssh al servidor, y ejecutando

#id usuarioDeseado

Así se obtienen el id de usuario y de grupo principal.

Aunque me estoy adelantando un poco: en OpenMediaVault se trabaja con carpetas compartidas. Al final son carpetas virtuales que están asociadas a un disco duro y a una ruta dentro de ese disco duro. Realmente esa carpeta está asociada a una ruta, y es la que se corresponde con

/srv/dev-disk-by-_label_o_ID_del_disco/carpeta

Para esta aplicación, el puerto 5800 está asociado al acceso a la aplicación vía web y el 5900 está para acceder por VNC.

Así, tuve mucha suerte y después de poner estos datos (y algunos problemas como, por ejemplo, no poner en el textbox el nombre del stack y el valor de algunos parámetros (como la versión, no sirve la 3) conseguí que funcionase. 

Yyyyy... ya está. Aquí lo tenemos. 

Para cualquier duda o problema por favor, avisadme. Pero como comento, en esto de los dockers soy bastante nuevo. No obstante, se hará lo que se pueda. También, como de costumbre, las aportaciones también son muy bienvenidas. 

Failed to start raise network interfaces

Hace mucho tiempo que recuperé un PC y me puse a reconfigurarle una Debian. Además del lío que tengo montado para dejarle un kernel perfecto (para mí), que me está llevando bastante más tiempo de lo que invertí en mis primeros pinitos con Gentoo, la lié bien con la configuración de la tarjeta de red.

El resumen: entre configuraciones del kernel (que esto es otra historia que ya veré si cuento) y toquetear la tarjeta de red, nadas más arrancarlo desde grub me aparecía un mensaje parecido a:

Failed to start Raise network interfaces

Lo que hacía que no cargasen las tarjetas de red y aunque las levantase a mano tampoco funcionaban. Con un poco de tiempo he podido buscar la solución, y no tenía nada que ver con el kernel (pero como lo estaba toqueteando me imaginé que iban por ahí los tiros).

La pena es que las direcciones de las soluciones las cerré por el pequeño afán de quitar pestañas y ventanas abiertas (y aún así tengo un montón más. ¡Muchas!).

Al lío: ¿Qué comandos encontré para debuguear o localizar la solución?  Estos los siguientes comandos (cuyos resultados acabé pasando posteriormente a un fichero para escribir este post).

journalctl -xe

Por lo que recuerdo, y buscando en los resultados, tampoco arrojó mucha luz sobre el problema.

journalctl -u networking.service

A pesar de que este comando me estaba gritando cuál era el problema:

-- Logs begin at Tue 2020-03-17 15:47:36 CET, end at Tue 2020-03-17 19:52:11 CET. --
mar 17 15:47:41 mihostname systemd[1]: Starting Raise network interfaces...
mar 17 15:47:41 mihostname ifup[409]: ifup: /etc/network/interfaces:27: option with empty value
mar 17 15:47:41 mihostname ifup[409]: ifup: couldn't read interfaces file "/etc/network/interfaces"
mar 17 15:47:41 mihostname systemd[1]: networking.service: Main process exited, code=exited, status=1/FAILURE
mar 17 15:47:41 mihostname systemd[1]: networking.service: Failed with result 'exit-code'.
mar 17 15:47:41 mihostname systemd[1]: Failed to start Raise network interfaces.

La típica lectura en diagonal hizo que no lo viera. El fichero /etc/network/interfaces.

systemctl status {systemd-network,systemd-resolved,networking,NetworkManadager}

Este comando, también daba un resultado similar. Y viendo lo que hice después en ese fichero de "log" improvisado que hice, en efecto, aquí me encontré con el problema para solucionarlo:

 systemd-resolved.service - Network Name Resolution
   Loaded: loaded (/lib/systemd/system/systemd-resolved.service; disabled; vendor preset: enabled)
  Drop-In: /lib/systemd/system/systemd-resolved.service.d
           └─resolvconf.conf
   Active: inactive (dead)
     Docs: man:systemd-resolved.service(8)
           https://www.freedesktop.org/wiki/Software/systemd/resolved
           https://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers
           https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients

networking.service - Raise network interfaces
   Loaded: loaded (/lib/systemd/system/networking.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Tue 2020-03-17 15:47:41 CET; 4h 13min ago
     Docs: man:interfaces(5)
  Process: 409 ExecStart=/sbin/ifup -a --read-environment (code=exited, status=1/FAILURE)
 Main PID: 409 (code=exited, status=1/FAILURE)

mar 17 15:47:41 mihostname systemd[1]: Starting Raise network interfaces...
mar 17 15:47:41 mihostname ifup[409]: ifup: /etc/network/interfaces:27: option with empty value
mar 17 15:47:41 mihostname ifup[409]: ifup: couldn't read interfaces file "/etc/network/interfaces"
mar 17 15:47:41 mihostname systemd[1]: networking.service: Main process exited, code=exited, status=1/FAILURE
mar 17 15:47:41 mihostname systemd[1]: networking.service: Failed with result 'exit-code'.
mar 17 15:47:41 mihostname systemd[1]: Failed to start Raise network interfaces.

El fichero /etc/network/interfaces. En este punto me quedaba revisar qué podía tener mal. Es el típico fichero que has modificado tantas veces que deberías de saberte de memoria cómo se configura pero siempre hay algún pequeño punto que se queda colgando.

En mi caso, los datos importantes que contenía eran:

auto lo

iface lo inet loopback

# The primary network interface

#iface eth0 inet static

allow-hotplug eth0

iface eth0 inet dhcp

#allow-hotplug wlan0

iface wlan0 inet static

        wpa_supplicant

El problema, básicamente: era que el parámetro wpa_supplicant estaba mal. No sé si es porque en algún momento leí que poniéndolo buscaba el fichero de configuración directamente (si fue así me pregunto "¿¿¿por qué lo pensaría???"), ¿me olvidaría de que había que ponerlo? (una vez más, si fue así: ¿por qué no me daría cuenta?) pero, lo más sorprendente es que para verificar si me estaba dejando algo en esta configuración me encontré con que ahora ese parámetro no es así (o al menos, para lo que yo necesitaba). Esta tarjeta la tendría que dejar configurada de esta otra forma:

#allow-hotplug wlan0

iface wlan0 inet static

        wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

Y así dejaría de quejarse. Eso sí, y como curiosidad o anécdota: no conseguí conectarme a la red cableada... Un poco más tarde acabaría crimpando dos cables de red: el de esta máquina y el de otra que también me estaba dando problemas de conexión.

Sólo como histórico para que cuando tenga problemas tan básicos de estos problemas, y aunque no debería de pasarme, me voy a dejar algunos enlaces por aquí:

• NetworkConfiguration
• Network interfaces
• Tarjetas de red wifi /Wifi network interfaces 
• Debian y wpa_supplicant

Debian/Linux: cambiando arquitectura x86 a x64

Hace poco os conté que no me aparecía el comando shutdown una vez había elevado privilegios con su y cómo lo solucioné. Todo ello porque descubrí que mi instalación de Debian estaba como x86 cuando mi máquina era x64. No recuerdo por qué lo hice en su momento: si fue un despiste o si tenía una razón que en ese momento era lógica. Así que busqué el procedimiento, lo seguí, me dio problemas, acabé actualizando (de casualidad) a la nueva versión de Debian hasta que me encontré con dicho problema y con su solución, ahí contada.

Como dije escribiría un post contando qué procedimientos seguí. No tomé nota, pero sí he estado manteniendo las distintas pestañas que estuve viendo, por lo que lo más seguro es que alguna cosa no termine de coincidir.

También, y antes de ponernos en harina, toca el típico disclaimer: no hagas esto si no estás muy seguro. Podrías terminar necesitando reinstalar muchísimos paquetes y te volverás loco. Vamos: que casi, casi podrías necesitar reinstalar (tal y como recomiendan en algunos sitios: hacer una instalación limpia antes de hacer el cambio).

Todo lo vamos a hacer en consola con privilegios.

Ejecutamos:

# dpkg --print-architecture

Que nos mostrará la arquitecura actual (que es la que nos indica que estamos en x86)

i386

Vamos a añadir la nueva para poder tirar de x64:

dpkg --add-architecture amd64

Si ahora ejecutamos:

dpkg --print-foreign-architectures

Nos mostrará:

amd64

Ahora toca actualizar el repostorio e instalar el kernel para x64. El mayor misterio es indicar en el que queremos que tire de amd64.

apt-get update
apt-get install linux-image-amd64:amd64

Toca reiniciar. Acuérdate de seleccionar el kernel recién instalado.

Al ejecutar dpkg con los dos parámetros anteriores los resultados se intercambiarán, siendo amd64 el principal e i386 el foreing.

Desconozco por qué hacen un clean pero normalmente para estos casos yo lanzo todos: purge, clean, autoclean, etc.

apt-get clean
apt-get autoclean
apt-get purge
...

Ahora toca descargamos tres paquetes para esta arquitectura y forzar su instalación con dpkg:

apt-get --download-only install dpkg:amd64 tar:amd64 apt:amd64
dpkg --install /var/cache/apt/archives/*_amd64.deb

Tampoco estoy muy seguro si le llegué a pasar el parámetro --force-architecture en alguno  de estos dos comandos. Me suena que sí pero no recuerdo en cuál (mínimo en el segundo).

En teoría ahora podrías instalar cosas en la recién configurada arquitectura. Esto tiene su aquel. Porque según las distintas fuentes ponen un orden u otro sobre cómo o cuándo instalar los paquetes. Al final lo que hace falta es actualizar todos los máximos paquetes necesarios. Además, hay más librerías que harán falta (gcc, libgcc1, libc6...) y se te quejará mucho el sistema si no las has actualizado.

Un ejemplo para las actualizaciones y correcciones de los paquetes puede ser el siguiente...

Actualizar el repositorio:

apt-get update

En algunas de esas instalaciones te forzará a escribir algo así como "Sí, ¡haz lo que yo digo!". Además, no metas ningún typo o no lanzará la instalación. Al final hace una comparación literal de lo que busca (entiendo que se incluyen exclamaciones y todo).

Aunque será necesario corregir o reparar muchas instalaciones (ambos son los mismos):

apt-get -f install
apt-get --fix-broken install

También se puede hacer reinstalación de paquetes. Este parámetro no recuerdo si lo llegué a poner: pero revisando la ayuda de apt-get viene y seguro que en algún momento lo lancé. Más adelante mostraré un ejemplo.

Actualizar todos los paquetes del sistema con respecto al repositorio:

apt-get upgrade
apt-get dist-upgrade

Ir buscando los paquetes instalador como i386 para ver si puedes forzar a que se instalen como amd64:

dpkg --get-selections | grep i386

Y a partir de aquí, forzar la reinstalación:

apt-get --fix-broken --reinstall paqueteParaReinstalar:amd64

Y de todas formas, te encontrarás con que hay paquetes que tienen ambas versiones instaladas. Algunas las podrás desinstalar (no te olvides de poner :i386 no vayas a perder la de la nueva arquitectura).

Así, será necesario repetir muchas, muchas, muchas... muchas veces todos estos procesos de apt-get. Por eso, al ser una locura y encontrarme con tantos problemas, se me ocurrió actualizar a la nueva versión de Debian. Que por suerte llevaba apenas dos semanas publicada. Y aún así, terminé corrigiendo problemas montando el entorno con una unidad de arranque y actualizando muchos más paquetes en ese entorno.

Como podéis ver es... Vamos. Que es bastante lío. ¿Compensa reinstalar de cero e ir montando el sistema de nuevo? Pues no lo sé. Para suele ser mejor recuperar un sistema que montarlo de cero. Pero de vez en cuando toca hacerlo. En mi caso, que llevaba relativamente poco tiempo con la instalación original, no me compensaba ponerlo de cero.

Si puedo ayudar en cualquier duda del procedimiento, por favor, avisadme. A ver si hay suerte y puedo ayudar.

***
Algunas de las fuentes que tuve que utilizar:

https://askubuntu.com/questions/5018/is-it-possible-to-upgrade-from-a-32bit-to-a-64bit-installation
https://unix.stackexchange.com/questions/40463/how-to-convert-a-32-bit-x86-debian-based-system-to-64-bit
https://wiki.debian.org/CrossGrading

Debian; shutdown: command not found

Por cierto: este post lo escribiendo desde el móvil. Espero que el corrector no haga de las suyas.

Hace poco hice una actualización de mi Debian "scratch" a... "buster". Pero por intentar pasar la arquitectura de instalación de 32 bits a 64. Como la cosa no me terminó de ir del todo bien al intentar sustituir las aplicaciones me dio por buscar y encontré con que había nueva versión de Debian.

Para resumir: después de muchas sustituciones y malabarismos varios, di por finalizada la tarea. Pero mi usuario root era incapaz de apagar o. reiniciar la máquina con los comandos.

Así, buscando, me he encontrado con la solución.

El problema se da sólo al elevar simplemente con

#su

Porque ahora, tal cual está, no incluye la variable de entorno $PATH de root. Para que la incluya hay que pasar alguno de los siguientes parámetros: [- | -l (L minúscula) | --login]

Así, ejecutando:

#su -l

Ya nos incluirá en el $PATH la carpeta

/sbin

Que ha dejado de ponerla con el su de toda la vida.

Espero que si os sucede os sea de utilidad.

/etc/resolv.conf: se sobreescribe

A ver si me sale corto este post.

Esta es la típica solución que cuesta mucho encontrar, uno cree que se acordará de la solución y tiempo después la necesita y se ha olvidado.

Problema que llevo queriendo solucionar desde hace mucho tiempo: el fichero /etc/resolv.conf de un Debian que tengo instalado se me sobreescribe. Todo el tiempo que he querido solucionarlo he intentado quitar distintos servicios que ya ni me acuerdo. Pero me he encontrado con que una persona ha mostrado distintas soluciones al problema.

Una de ellas me ha permitido solucionarlo encontrándome con que mi resolv.conf era un enlace a un fichero de NetworkManager. En mi caso, su solución la he aplicado modificando directamente /etc/NetworkManager/NetworkManager.conf.

Ojo, que ese mismo enlace tiene más soluciones.

En el segundo enlace dan unas pocas pistas más. Pero habiéndolo solucionado con el primero poco más he leído del segundo (a parte de que he llegado a este a partir del segundo).

Espero que en algún momento os sea de utilidad.

Rsyslog: Logrotate

Voy a añadir una opción más a la configuración que hice recientemente para rsyslog. Para poder ver los datos que se envían desde el dispositivo que estamos analizando al servidor de logs correctamente, el hecho de que esté lleno de resultados de hace días no ayuda nada. Para ello se usa logrotate.

¿Cómo lo he configurado? Bien. He encontrado que existe un fichero en /etc/logrotate.conf y otros ficheros dentro de la carpeta /etc/logrotate.d/. De los ficheros que aparecían estaban asterisk, dpkg, samba, rsyslog.

Para forzar a que se cambien los ficheros diariamente para los dos aparatos que me interesa analizar, el SPA3102 y el teléfono Grandstream he incluido las siguientes líneas en el fichero de rsyslog:

/var/log/spa3102.log
/var/log/grandstream.log
{
        rotate 31
        daily
        dateext
        missingok
        notifempty
}

Las notas que puedo hacer al respecto:

• rotate: número de ficheros que quiero que se me generen.
• daily: quiero que se hagan diariamente.
• dateext: concatenar la fecha en los ficheros cuando se copian en vez de usar números.
• missingok: Por lo que he entendido, si el fichero de log (¿original?) falta, no se genera ningún error.
• notifempty: no rotar el fichero cuando este esté vacío.

Como no me terminaba de convencer hacer la prueba con todo lo que contiene rsyslog he decidido copiar y pegar la configuración aquí mostrada, sólo para Grandstream, en su propio fichero.

Después de la configuración he ejecutado la siguiente instrucción:

#logrotate -f -v /etc/logrotate.d/grandstream.conf

El resultado, además de rotar ficheros que no se habían tocado en mucho tiempo, es que me ha concatenado al fichero /var/log/grandstream.log la fecha, pero no me ha generado otro nuevo. Si miro su contenido, puedo ver que en dicho fichero se siguen guardando datos. Esto me hace preguntarme: ¿Me concatenará siempre la fecha o será sólo hoy? 

---

Si bien cuando empecé escribiendo este artículo, el sistema no se comportó como esperaba, me esperé unos días más para ver qué sucedía. ¿Qué tengo ahora? 

Ahora sí que tengo los ficheros con su nombre original y sus copias diarias con la extensión de "-aaaammdd" (año, mes, día). El único problema: no se están haciendo en el momento adecuado, por lo que tengo ficheros que dicen que son, por ejemplo, del día 15, que contienen datos del 14 y del 15. :

Así, tengo:

• grandstream.log-20190515: registros de las 6H del 14 a las 6H del día 15.
• grandstream.log: a partir de las 6H del día 15.

Ejecutando:

#cat /var/lib/logrotate/status

Es posible ver cuándo se rotó cada fichero. Y, en efecto, las horas cuadran con respecto al desfase mostrado en los logs que necesito analizar. Repasando el comando de más arriba:

#logrotate -dfv /etc/logrotate.d/grandstream.conf

Gracias a que he revisado con más detenimiento el resultado de su ejecución he podido corregir algunos de los ficheros de configuración aquí explicados (pero yo lo muestro sin me avise de errores). 

Con respecto a las horas a las que se produce la rotación ya he encontrado la razón de esa hora tan rara. La rotación se realiza con un cron diario (/etc/cron.daily/). Dentro de esa carpeta, entre otros ficheros, se encuentra el relacionado con logrotate. A su vez, la ejecución de cada uno de los scripts que tiene que lanzar cron, independientemente de que sean diarios, semanales, mensuales... Se hace a través de la configuración que se encuentra dentro de /etc/crontab. Este fichero muestra la hora y minuto que cuadra con la que se muestra en el contenido de los logs al final del más reciente con su extensión de fecha y al principio del que se ha creado.

Lo voy a dejar aquí. Sólo me queda tomar la decisión de dejarlo tal cual, quitar la extensión de fecha (y que me salga la numeración), cambiar la hora para la ejecución de todos los diarios, forzar a que se roten sólo esos ficheros a las 0H (y por lo tanto, al intentar hacerlo de nuevo a las 6H no tendrá efecto)... Ya veré.

Sólo para tener un listado de los distintos sitios que he visitado (y así poder buscar en un posible futuro si es necesario, aunque creo que he perdido alguno):

• https://www.networkworld.com/article/3218728/how-log-rotation-works-with-logrotate.html
• https://kifarunix.com/how-to-configure-log-rotation-with-logrotate-on-ubuntu-18-04-lts/
• https://www.svennd.be/rotate-rsyslog-logs-using-logrotate/
• https://www.loggly.com/docs/log-rotate/
• https://www.reddit.com/r/sysadmin/comments/309coq/a_little_help_with_logrotate_and_rsyslog/

Rsyslog v8: actualización

Hace un tiempo hice un post sobre rsyslog. Ahora que creía que lo tenía activo, me he encontrado con que no era así. Posiblemente porque reinstalé el sistema. Ahora que he querido volver a ponerlo me he encontrado con que la configuración es ligeramente distinta y no me termina de funcionar del todo bien.

Primero: en /etc/rsyslog.conf descomentar:

• module(load="imudp")
• input(type="imudp" port="514")

También habrá que asegurarse de que esta línea está descomentada:

• $IncludeConfig /etc/rsyslog.d/*.conf

Como se puede ver, hasta aquí la única diferencia que hay con respecto a los parámetros antiguos es que ya no se usan "$ModLoad" ni "$UDPServerRun".

A su vez, en /etc/rsyslog.d/ he creado dos ficheros, uno para cada sistema que necesitaba logear. Su contenido:

:FROMHOST-IP, isequal, "_direccion_ip_sistema_" /var/log/_nombre_fichero_.log

& stop

Me he encontrado con un problema: no se me generan los ficheros. Algunas de las cosas que he leído que se podía hacer era ejecutar:

#/etc/init.d/rsyslog rotate

Que a su vez, según he entendido, fuerza a rotar los ficheros de log y a su vez generar los que no estuvieran creados. Pero no han funcionado.

También he querido buscar datos ejecutando rsyslog en modo debug (o eso he entendido al buscar soluciones:

#rsyslog -dn | more

Como son muchas líneas permitirá ver las lineas. Otra opción: mandarlo a un fichero auxiliar y después hacer un pipe ( | ) con grep. 

Nos permitirá ver que:

• Se han localizado los ficheros que hemos incluido en /etc/rsyslog.d/ (puedes buscar la cadena "requested to include" o "config parser".
• El contenido del filtro, al menos de uno de ellos.

Así, se podrá ver si hay algún problema. En mi caso no me ha terminado de ayudar. 

No obstante, uno de los sistemas sí que están guardando datos en /var/log/messages y en /var/log/syslog.

Que se estén guardando datos en estos ficheros para sólo uno de estos sistemas lo único que me indica es que realmente está escuchando. Por lo tanto, tengo que solucionar varios problemas:

1. Que no se guarden los datos en los otros ficheros: syslog ni messages.
2. Que se generen los ficheros que quiero.
3. Que el equipo del los equipos de los que no se están guardando logs sí se guarden.

La verdad, he hecho muchas pruebas con distintos resultados.

En teoría para el número 1 estaba la opción "& stop". Pero como no se generan (generaban), tampoco estoy muy seguro de que esté sirviendo. 

Asegúrate de que la dirección IP del emisor es la correcta ya que en uno de los casos puse la propia del servidor de logs. De las muchas pruebas que he conseguido hacer, he tenido todo tipo de resultados. 

Continuando con la línea "& stop" para solucionar el número 2: he conseguido que se generen los ficheros comentando esa instrucción. Por un lado, hice la prueba de incluir el contenido de los dos ficheros (sin el stop) en la configuración directamente y así sí que se me generaban los dos ficheros. Pero después, si comentaba esas líneas, dejaba de funcionar. 

También hice lo siguiente: reiniciar tirando del cable el equipo que en ningún momento generaba el log. Como no tiene ninguna otra opción para apagar y encender no ha quedado otro remedio que hacerlo así.

Lo extraño: este del que hablo sólo genera el fichero si se reinicia. Aunque se produzca un evento, desconozco el por qué de ese comportamiento.

Como costará entender las soluciones, a ver si las puedo resumir:

1. Evitar guardar en messages y syslog: A día de hoy no tengo solución viable.
2. Reiniciar dispositivos si es necesario. Además, aplicar número 3.
3. No poner "& stop" bajo ningún concepto, al menos para las necesidades básicas.

Aunque juraría que hice pruebas comentando esa línea maldita, no llego a entender por qué habiendo hecho lo mismo que mostré la anterior vez me ha costado tanto hacerlo funcionar.

Montar davfs con fstab

A ver si consigo escribir esta entrada en poco tiempo y que se entienda.

Hace tiempo que tenía configurado en una raspberry un Kodi con la distribución raspbian. Una de las configuraciones que tenía era que fstab se tenía que conectar contra un servidor ftp montando así la carpeta en local. Pero de repente, dejó de funcionar. Y así se quedó. Hoy, he conseguido recuperar el montaje, con la diferencia de que ahora se conectará por webdav. Y es la primera vez que lo he hecho. Espero no dejarme ningún dato imprescindible.

Lo primero, instalar davfs2:

# apt-get davfs2

A mi me ha preguntado si quería configurar el setuid para que todos los usuarios pudieran utilizar este tipo de sistema de ficheros (al fin y al cabo es como se comporta). Por mi parte lo he aceptado.

Después, hay que editar el fichero /etc/davfs2/secrets, indicando el punto de montaje, usuario y contraseña (por lo tanto, estarán en claro):

/mnt/puntoDeMontaje miUsuario elChorroConLaContraseña

¡Mucho ojo! Aquí me he vuelto loco porque en varios manuales me he encontrado con que indican

https://laUrlAlRecursoDeRed miUsuario elChorroConLaContraseña

Pero no me terminaba de funcionar. Si no es por SleeplessBeastIE no hubiera probado la primera opción que he indicado.

Ahora toca modificar fstab. Intentaré poner tal y como lo tengo, porque a decir la verdad, además de las diferencias con el tipo de sistema de ficheros, los parámetros básicos estándares que antes funcionaban ya no lo hacen:

https://laUrlAlRecursoDeRed /mnt/puntoDeMontaje davfs defaults,auto,ro,uid=1000,gid=1000,_netdev 0 0

Así, si estando como root ejecutamos:

mount -a

Al buscar datos en nuestro punto de montaje deberíamos de poder ver los datos esperados. Por mi parte, he probado reiniciando y en efecto, los recursos se han montado automáticamente.

Como de costumbre, habrá otras maneras de hacerlo pero en mi caso, y para mis necesidades, esto es suficiente.

Linux y algunos parámetros del kérnel: Linux casado

La primera parte creía que ya la había contado en otra ocasión, pero, una vez más, no he sido capaz de encontrarlo. Pero bueno, para refrescar la memoria...

Como muchos sabréis, en linux, si quieres saltarte la contraseña de root, porque, por ejemplo, ésta se haya perdido, lo que hay que hacer es editar el menú del grub cuando éste se muestre y añadir al final de la línea la palabra single:

Editando el grub en linux

Y vamos a editar el kernel:

Editando grub: añadiendo single como parámetro del kernel

Dependerá de la versión que tengas el cómo te lo muestre, pero en definitiva, hay que añadirlo ahí. 

Una vez lo tengas, tendrás acceso al sistema con permisos de root sin haber usado la contraseña. Eso sí, la carga es muy limitada, por lo que tendrás servicios que no funcionen. 

Lo curioso es el resultado que nos ofrece si en vez de single, le ponemos married. Me gustaría mucho que lo probaseis y me lo comentarais para que después os pueda dar mis resultados y así los contrastamos. ¿Os parece?

Fabrica tu propio router con Gentoo y Debian

Hace tiempo... Mucho, mucho tiempo... Tenía un equipo, como dicen en inglés, headless.  Es decir, sin monitor. Típico ordenador que se deja en un rincón. Y, lo convertí en un router. La verdad, ahora mismo no lo tengo ni montado. Algún backup seguro que tengo. Pero tendría que buscarlo. Y muchas cosas de las aquí contadas están escritas de memoria, con alguna mirada al manual, pero tendré que montar una máquina para probarlo.

A lo que iba. Me monté un router con un PC. ¿Cómo lo hice? Pues, tendré que hacer memoria. Pero, como en esa época utilizaba Gentoo, es el sistema operativo que uilicé. Por lo tanto, me hacía una búsqueda parecida a

howto router gentoo

teniendo dos posibilidades, la inglesa o la española (ojo! es una traducción de la inglesa: el contacto que han puesto en la versión española no habla español [o no lo hablaba]).

Pero, hay que tener en cuenta una cosa: el router que proponían era para dar acceso a internet.  Como si quisíeramos sustituir el de Telefónica por el nuestro. Nosotros lo vamos a poner entre medias de ese router y nuestros equipos. Por lo tanto, hay que realizar unos pocos cambios a las propuestas que nos hacen en ese HowTo.

Este post lo estoy reescribiendo. Tenía pensado poner más o menos lo que hice en su momento, y lo tenía paralizado. Hasta que este fin de semana he tenido que montarme uno, y he decidido terminarlo poniendo lo que he utilizado, que tiene alguna que otra diferencia de lo que hice en su momento. Pero, lo que hecho ha sido utilizar los manuales de Gentoo en una Debian.

Vamos a ponernos en situación: te pasan un ordenador de sobremesa y tienes que enchufarlo a los perifericos. Pero, el lugar donde los tienes es otro PC Por lo tanto, lo que vas a hacer es conectar un switch KVM (Keyboard Video Mouse), de tal forma que podrás utilizar los mimos perféricos para dos ordenadores y así ir alternando entre ambos. Después, utilizarás un cable de red cruzado para que ambos ordenadores estén conectados por red.

Ahora, configuraremos el ordenador principal, que tienes una Debian instalada.  Lo primero es ponerse en situación: un ordenador que tiene su tarjeta de red inalámbrica (wlan0), que es la que le da conexión a internet como cualquier otro equipo. Por lo tanto, estará configurada tal y como lo hicimos en reyes.

La segunda tarjeta de red sólo la configuraremos en el mismo instante en el que vamos a utlizarla. Por lo que vamos a lanzar ifconfig:

ifconfig eth0 192.168.2.1 netmask 255.255.255.0 up

Esta tarjeta de red será la que haga de gateway.

Después, lancé una serie de parámetros para iptables. Al final, después de varios chascos metiéndolos a mano y que no me funcionase, acabé montándome el script:

# Limpieza total de todas las reglas: se pierde toda configuración existente
iptables -F 
iptables -t nat -F

# Reglas por defecto cuando las reglas explicitas no se cumplen
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT 
iptables -P FORWARD DROP

#Variables de entorno:
export LAN=eth0
export WAN=wlan0

# Para que los servicios sólo funcionen desde la LAN
iptables -I INPUT 1 -i ${LAN} -j ACCEPT
iptables -I INPUT 1 -i lo -j ACCEPT 

#Serivicios del los puertos 67 y 53 (entre otros, los utilizados por los boot-pe)
iptables -A INPUT -p UDP --dport bootps ! -i ${LAN} -j REJECT 
iptables -A INPUT -p UDP --dport domain ! -i ${LAN} -j REJECT

#Ejemplo para aceptar servicios desde la WAN: apertura de puertos
iptables -A INPUT -p TCP --dport ssh -i ${WAN} -j ACCEPT

#Tira los paquetes TCP y UDP para los puertos entre 0 y 1023:
iptables -A INPUT -p TCP ! -i ${LAN} -d 0/0 --dport 0:1023 -j DROP
iptables -A INPUT -p UDP ! -i ${LAN} -d 0/0 --dport 0:1023 -j DROP

#Reglas NAT:
iptables -I FORWARD -i ${LAN} -d 192.168.2.0/255.255.0.0 -j DROP
iptables -A FORWARD -i ${LAN} -s 192.168.2.0/255.255.0.0 -j ACCEPT 
iptables -A FORWARD -i ${WAN} -d 192.168.2.0/255.255.0.0 -j ACCEPT 
iptables -t nat -A POSTROUTING -o ${WAN} -j MASQUERADE

#Configurar el kernel para que el ip forwarding funcione:
echo 1 > /proc/sys/net/ipv4/ip_forward 
for f in /proc/sys/net/ipv4/conf/*/rp_filter ; do echo 1 > $f ; done

#Guardar los cambios. En Debian, es mejor utilizar la que no está tachada:
/etc/init.d/iptables save  
rc-update add iptables default
iptables-save

#Abrir el fichero /etc/sysctl.conf y cambiar los valores a lo siguiente:
net.ipv4.ip_forward = 1
net.ipv4.conf.default.rp_filter = 1 

Con todo esto, y teniendo configurada la tarjeta de red del equipo con el que vas a trabajar (porque, ten en cuenta que estamos trabajando con direccionamiento estático, y que [si no recuerdo mal], los paquetes DHCP están incluidos en los que estamos tirando), podrás acceder a la red principal. En mi caso, quería poder acceder a internet. Pero, algo que se podría hacer es, por ejemplo, y escrito así a bote pronto:

iptables -A OUTPUT -i ${LAN} ! --dport 80 -j DROP

Así, si hubiese alguna conexión que tuviese que salir y no fuese para http, se tumbaría.

No estoy muy seguro de si me acordaré de cómo lo hice, pero ya veré si encuentro algún sitio donde contaba cómo montar un spamassasin y pop3-scan (o algo parecido): un proxy para correo.

Volviendo a configurar WPA y la red en Debían

Esta configuración, aunque básica, es de esas que se hacen apenas una vez por instalación y te olvidas. Como hacía tiempo que no tenía que ponerla, había cosas que no me acordaba cómo se indicaban en los ficheros correspondientes. Por lo que aquí voy a contar, lo más rápido posible, qué poner para que al menos funcione todo el tinglado. A tener en cuenta que algunas cosas a lo mejor sobran.

El fichero /etc/network/interfaces:

#auto fuerza a que se cargue al iniciar el sistema
auto lo
iface lo inet loopback

#allow-hotplug iniciliza la interfaz cuando el kernel detecta que se ha conectado la interfaz en caliente
allow-hotplug wlan0
auto wlan0

#quiero que el direccionamiento sea estático
iface wlan0 inet static
  addess 192.168.1.123
  netmask 255.255.255.0
  gateway 192.168.1.1
  wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

En realidad, después de la instalación, me había metido mucha más morralla, pero entre que no me acababa de gustar, que no me conectaba a la wifi, y que podía indicarle esos datos por otros medios, decidí comentarla. Con estas líneas, funciona bien.

Para más información (como por ejemplo, más configuraciones), podemos encontrarla este mismo enlace, buscando este fichero que estamos modificando.

Para la resolución de nombres, es decir, para los DNSs, puedes introducir los datos en el fichero /etc/resolv.conf:

nameserver 8.8.8.8
nameserver 8.8.4.4

Siempre tengo la duda de si es nameserver o nameservers. He puesto estas direcciones como podría haber puesto otras. Con esto debería de servir.

Ahora, vamos a modificar /etc/wpa_supplicant/wpa_supplicant.conf. Creo recordar que la primera vez que hice la configuración de wpa_supplicant estaba directamente en /etc/, pero viendo que puedes indicar dónde tiene que buscar el fichero, lo mismo da. Con tal de que el sistema sepa dónde cogerlo, no debería de importar mucho:

#Directorio donde se crearán los distintos sockets para cada una las interfaces de red que necesiten estas ocnfiguraciones:
ctrl_interface=/var/run/wpa_supplicant
#Grupo o GID de aquellos que quieras que puedan cambiar la configuración de la interaz. Por defecto (y si no se pone), será el de root. Podrías cambiarlo, por ejemplo, al nombre de grupo wheel.
ctrl_interface_group=0

network={
  ssid="nombreDeTuRed"
  scan_ssid=1
  proto=WPA
  key_mgmt=WPA-PSK
  psk="elChorroDeLaPassMásGrandeEnFormatoCamelloSiAsíLoDeseas"
}

En principio, teniendo esto cargado, debería de funcionar. Una forma de probarlo, y ver wpa_supplicant está funcionando, sería ejecutar esto:

wpa_supplicant -Dwext -iwlan0 -c/etc/wpa_supplicant/wpa_supplicant.conf

Si se queja de que algún parámetro no está bien puesto, tendrás que mirarlo. En micaso eran alguno de las opciones del wpa_supplicant.conf que no existían o tenían un valor erroneo. Y me indicaban cuál era. A mi me está dando un aviso, pero sí me funciona la conexión:

ioctl[SIOCSIWENCODEEXT]

Sale dos veces. Pero, las pocas búsquedas que he hecho no me han ayudado mucho (también mucha perecitis, después de la comilona de hoy).

Aún así, si quieres más información sobre qué significa cada cosa, tenemos un ejemplo de fichero de configuración que está comentado.

En principio, esto ya funciona y está conectado al router / AP y a internet. Si haces ping hacia una dirección externa deberías de poder salir hacia afuera.

Con esto, ya tenemos una pequeña documentación para cuando dentro de unos pocos años volvamos a necesitarlo, poder tirar de aquí sin ningún problema.

Desmontar unidad en linux: device is busy

Ahora mismo estoy intentando desmontar una de las unidades que tengo (valga la redundancia) montadas en mi backtrack con un

#umount /mnt/usb

pero sin éxito, dado que me está dando un error como el siguiente:

umount: /mnt/usb: device is busy.
(In some cases useful info about processes that use
the device is found by lsof(8) or fuser(1))

Por lo que he decidido seguir las instrucciones. Pero, dado que el listado es demasiado grande, he decidido aplicarle un pipe (más comunmente conocido como "tuberia") para filtrar la salida y que sea más sencillo de encontrar el resultado:

#lsof | grep /mnt

Y, así, a la segunda, me ha salido un único resultado que es el que necesitaba. Entre otras cosas, sale el pid del proceso que tendré que matar para desmontar correctamente ese mapeo:

bash      3697       miUsuario  cwd       DIR               8,33        20480          5 /mnt/usb

Aún así, tengo curiosidad por el resultado que me devolvería el otro comando. fuser. Por eso, antes de matar el proceso anterior, vamos a ver el resultado que me suelta.

Vale. He tenido que hacer un pequeño ensayo y error. El comando fuser necesita recibir un parámetro para funcionar. Además, ese parámetro puede necesitar a su vez un valor determinado. En mi caso tengo que poner

#fuser -m /mnt/usb

Porque, de no pasarle uno, nos devolverá la ayuda.

El resultado sería:

/mnt/usb: 3697c

que, como se puede observar, coincide (en gran medida) con el que nos da lsof.

Total, que al ejecutar:

#kill -9 3697

#umount /mnt/usb

deja de quejarse.

Esto hay que apuntárselo para que no nos olvidemos. Que muchas veces sucede y al final acabamos quitando el dispositivo sin desconectarlo correctamente.

Review: Herramienta CAINE

Más que herramienta, es una LiveCD de linux pensada para análisis forense. Hace poco tiempo, tanto Security by Default como Flu-Project hablaron de ella (me suena que en Flu ya habían hablado más extensamente de esta distro, pero ahora mismo, no la encuentro).

Cuando quise hacer el reto forense que montaron en Flu hace una semana y media, además de utilizar backtrack, hice uso de esta distribución.

Si bien trae bastantes herramientas, como puede ser foremost (para recuperar datos), Xsteg (para análisis de estenografía), autopsy (para analizar imágenes dd), hasheadores...

Se puede decir que de herramientas para hacer análisis forense está bastante bien. Es posible que alguien con más experiencia eche de menos alguna que otra, todo hay que decirlo.

Esos sí, hay una cosa que ha hecho que la descarte. Es un detalle que me hizo perder mucho, mucho, mucho tiempo. Es la configuración de la tarjeta de red.

Si estás en un entorno virtualizado, donde no se utiliza DHCP, hay que configurar la tarjeta a mano. Si además tienes que realizar alguna instalación determinada (teniendo en cuenta que se perderá en cuanto reinicies) y el paquete se lo tiene que descargar de Internet, hará falta que esa configuración sea plenamente operativa. Y en mi caso, eso no fue así. La conexión se perdía cada dos por tres. A veces, tardaba un minuto en perderse. Otras veces, segundos. Otras, unos pocos minutos. Eso pudo conmigo. Y en una pequeña búsqueda no encontré nada que me pudiera ayudar. Tampoco tenía mucho tiempo para dedicarle.

Otro detalle es que siempre se trabaja con un usuario pelado. Un mortal. Sí, es cierto que lo normal es trabajar siempre así. Pero que no haya forma de elevar privilegios con el comando su... También es cierto que está el comando sudo y que una vez que te acostumbras a usarlo no debería de haber ningún problema. Pero que no existiera la otra posibilidad...

Total, que mis primeras experiencias con esta herramienta, no fueron del todo buenas. Es posible que dedicándole un poco más de tiempo, acabe dándole más nota. Aún así. A vosotros: ¿Qué os ha parecido?¿Os ha dado más problemas?

Vamos a ~

Hace poco me re-envié un tweet que decía algo así como...

HackToon! (@hacktoon) twitteó a las 5:27 p.m. on mar, ene 22, 2013: Porque o til "~" é o símbolo para a home do usuário no Unix: http://t.co/AGxTIuGk(https://twitter.com/hacktoon/status/293756720650543105)

Y, ahí está la respuesta. Resulta, que en los teclados para los terminales Lear-Siegler ADM-3A, tenían una tecla (justo donde ahora podemos ver la de backspace), que ponía Home, ~ y ^ (siempre según las imágenes que podemos ver en los enlaces aquí presentes).

Por lo tanto, cada vez que queramos ir a casa, podríamos resumirlo en vamos a ~. Un gran ahorro de 3 caracteres si hiciese falta apurar.

Particionando Android

¿Cuántos de vosotros habéis instalado Linux a manubrio alguna vez? Supongo que la pregunta debería de ser: ¿Cuántos de vosotros habéis particionado alguna vez una unidad X desde Linux?

Mmmh… Bueno. Para los que no lo hayan hecho, vamos a verlo. Y para los que sí lo hayan hecho, os lo refresco, por si las moscas. Lo haré a mi manera. Por lo tanto, puede que no sea del todo exacto, pero, para realizar la tarea básica, puede bastar.

Lo primero de todo, y muy, muy importante. Las operaciones que haremos aquí harán que los datos se pierdan. Por lo tanto, cualquier dato al que le tengas mucho aprecio y que se encuentre en el equipo que utilices para realizar todas estas operaciones, hazle un backup. Por si las moscas. Cualquier cosa que suceda, no me responsabilizo. Vamos, típico disclaimer de exoneración de responsabilidad.

Lo siguiente: ahora mismo (justo cuando estoy editando estos párrafos), no puedo asegurar que vaya a funcionar del todo. Léete todo antes de realizar cualquier operación.

Paso 1: Localizar la unidad que queremos particionar. En Linux, los dispositivos se encuentran en la carpeta /dev.

Si es un dispositivo IDE, su nombre será hdX donde X será a, b, c o d según la posición donde se encuentre instalado en la placa base. Si tiene un número, ése indica la partición detectada.

Si es un dispositivo SATA, USB… su nombre empezará por sdX. La X será a, b, c… no se hasta cuándo terminará, la verdad. Y no se en qué se basa para asignarlas. Lo normal es que vaya asignando según vayan haciendo falta y de manera consecutiva. Pero, no sería raro que alguna vez me haya puesto otra que no me esperaba.

Paso 2: Ejecutar el comando fdisk para realizar la partición. Lo podemos lanzar de esta manera:

fdisk /dev/sdb

Donde el parámetro que necesita fdisk es el dispositivo, y no la partición.

Paso 3: Manipular la tabla de particiones elimando las que hagan falta, creando nuevas, indicando el sistema de ficheros que planeamos alojar, y guardando los cambios (o saliendo sin guardalos).
--

Un ejemplo práctico. Tenemos una nueva tarjeta microSD en nuestro flamante super Android Modelo Cojojundo XYZ con una ROM CyanogenMod9 (vale, ahora acaba de salir el 10, es un ejemplo!). . Queremos particionar la tarjeta por cualquier motivo. El que más os guste.

Termial en Android - Donde 'au' debía de ser 'su' 

Abriremos el emulador de terminal que tengamos instalado (repito: necesitamos un terminal instalado en el móvil), y elevar privilegios con su.

Ahora, necesitaremos saber cómo identifica el móvil las tarjetas. Un problema: no es hdX ni sdX. Una opción para saberlo sería googlear. ¿Para qué, si lo puedo decir yo? Las tarjetas las identifica en

/dev/block/vold/*

donde el asterisco será un número, como, por ejemplo, 179:8. A ver. El problema está en que no conseguí hacer funcionar esto del todo desde el móvil la primera vez que lo hice. No se si es que no guardé bien la tabla, pero el resultado que obtenía era raríiiisimo.

También hará falta saber dónde está montada. Normalmente se indentifica ejecutando

mount

y obtendremos el listado de los dispositivos montados en qué carpetas.

Sigo contando el proceso que hice (o que debería de haber hecho [esta segunda vez, lo voy a repetir mientras lo escribo], a ver si ahora me sale a la primera).

fdisk /dev/block/vold/179:8

Nos pide que introduzcamos el parámetro deseado. Pulsaremos "m" (sin comillas) para pedir la ayuda. Queremos eliminar las particiones que nos solicite, Para ello pulsaremos la letra "d". Pondremos una a una cada una de las particiones que tenemos. Se pueden ver si, estando en el prompt que nos pide hacer una acción, ponemos una "p". Así:

Imprimiendo las particines existentes

Eliminando las particiones de la tarjeta microSD 

Posiblemente, lo mejor sea guardar con "w" (lo veremos casi al final), y continuar por aquí. Si te sale otra partición "rara" o "enana", podrás eliminarla y ahora, sí que sí, intenta continuar.

Y ahora creamos las particiones. Le diremos que queremos que sean primarias,("p", de primaria y, otra vez, sin las comillas), un número de partición, en mi caso será 1 y 2, y un tamaño, yo pondré 7GB y 8GB respectivamente. Con un ejemplo debería de bastar:

Creando nuevas particiones, 7GB y 8 GB 

Una vez tenemos las particiones hechas, tendremos que seleccionar el tipo de sistema de ficheros que alojaremos para cada una de las particiones realizadas. Para ello, podremos buscar con la "l" (L minúscula) el listado con los códigos necesarios:

Listando los distintos tipos de particiones disponibles 

que serán los que más te plazcan. Para que la partición sea visible con el terminal conectado al USB será necesario utilizar el código C (antes estaba usando el 7). Se podrá cambiar utilizando el "paramétro" "t":

Cambiando los tipos de particiones 

Para terminal con el fdisk,

Ahora, sólo queda salir presionando la tecla "w". Si te arrepientes de cualquier cambio, puedes salir introduciendo como parámetro la "q" (¿se ve que es una Q minúsucla?).

¿Guardando tabla de particiones? 

Mmmh.... Pues... no. No me ha funcionado. Se ha quedado tal y como lo tenía antes de escribir este post. Es decir, al conectar el USB, se muestra la partición de esa tarjeta con el fichero ya que tenía dentro.

A reiniciar, entre cada operación, sí que han empezado a salir. Por lo tanto, la clave parece estar en que cuando se eliminan las particiones, tenemos que reiniciar el terminal y continuar con el proceso por donde lo hemos dejado.

He de reconocer que cuando lo hice la primera vez, lo acabé haciéndolo desde una VM, pero es muy raro. Sin reiniciar dice que sí, que está hecho, pero... No se.

Ahora que parece que están las particiones, puedo hacer el formateo.

mkfs.vfat -F 32 /dev/block/mmcblk1pX

donde la X será el número de partición.

Si te sale un error como "value too large for defined type" se resuleve... con el comando

newfs_dos /dev/block/mmcblk1p1

Lo he encontrado aquí.

Total, y para resumir:
- desmontar las particiones de la tarjeta:
- fdisk: eliminar partciones con "d". Reiniciar por si las moscas.
- fdisk: crear las particiones. Ojo: acordarse de poner el símbolo "+" (más) antes del valor del tamaño y las unidades (muy importante). Indicar el tipo de particion si se quiere cambiar.
- fdisk: ¿Reiniciar?
- Formatear (si se deja)

Y ya está!!

Soy consciente de que es mucho lío lo que he puesto. Esa es la razón del resumen. Y también que la primera vez que lo hice hace unas semanas fue haciendo trampa: conectando el adaptador de microSD a SD y después, desde una VM particionándolo. En principio, el comando newfs_dos debería de funcionar bien. El resto, os lo dejo a vosotros!!

Update, 2013-08-21: He actualiazdo los estilos. Se me habían puesto horrorosos.

YouPorn comprometido

A lo largo del día se ha hecho público que YouPorn ha tenido un problema de seguridad que ha permitido que bastantes cuentas de usuario (se habla de más de un millón, en otros sitios de "tan solo" ~6500) han sido comprometidas y se han hecho públicas.

Parece ser que el problema estaba en su sistema de chat. Pero, la verdad, no he podido buscar mucho más sobre lo que ha pasado. Algunos datos que he podido encontrar sobre las características de las contraseñas han sido los siguientes (fuente en Pastebin):

YouPorn Account Analysis - 2012-02-21
Total entries = 6428
Total unique entries = 4062
Top 10 passwords
123456 = 115 (1.79%)
123456789 = 78 (1.21%)
12345 = 30 (0.47%)
melinda = 23 (0.36%)
fuck = 20 (0.31%)
1234567890 = 18 (0.28%)
Nightmare = 17 (0.26%)
allzen = 16 (0.25%)
password = 15 (0.23%)
anal = 15 (0.23%)
Top 10 base words
qwerty = 42 (0.65%)
youporn = 25 (0.39%)
melinda = 24 (0.37%)
password = 23 (0.36%)
fuck = 20 (0.31%)
nightmare = 18 (0.28%)
allzen = 16 (0.25%)
anal = 15 (0.23%)
qwer = 15 (0.23%)
asdfgh = 14 (0.22%)
Password length (length ordered)
1 = 2 (0.03%)
2 = 6 (0.09%)
3 = 35 (0.54%)
4 = 196 (3.05%)
5 = 219 (3.41%)
6 = 1223 (19.03%)
7 = 904 (14.06%)
8 = 1375 (21.39%)
9 = 957 (14.89%)
10 = 729 (11.34%)
11 = 311 (4.84%)
12 = 204 (3.17%)
13 = 111 (1.73%)
14 = 71 (1.1%)
15 = 47 (0.73%)
16 = 26 (0.4%)
17 = 6 (0.09%)
18 = 16 (0.25%)
19 = 2 (0.03%)
20 = 3 (0.05%)
21 = 2 (0.03%)
22 = 2 (0.03%)
25 = 2 (0.03%)
26 = 2 (0.03%)
27 = 2 (0.03%)
Password length (count ordered)
8 = 1375 (21.39%)
6 = 1223 (19.03%)
9 = 957 (14.89%)
7 = 904 (14.06%)
10 = 729 (11.34%)
11 = 311 (4.84%)
5 = 219 (3.41%)
12 = 204 (3.17%)
4 = 196 (3.05%)
13 = 111 (1.73%)
14 = 71 (1.1%)
15 = 47 (0.73%)
3 = 35 (0.54%)
16 = 26 (0.4%)
18 = 16 (0.25%)
2 = 6 (0.09%)
17 = 6 (0.09%)
20 = 3 (0.05%)
25 = 2 (0.03%)
19 = 2 (0.03%)
1 = 2 (0.03%)
21 = 2 (0.03%)
22 = 2 (0.03%)
26 = 2 (0.03%)
27 = 2 (0.03%)

Y es que la gente no aprende... ¡¡¡Las direcciones de correo personales no se usan para estas!!! El hecho de repetir las contraseñas en distintos sitios es secundario. xD En serio. No es secundario. Es tan importante lo uno como lo otro.

Apagar Windows con comandos I

***
Entrega I (esta)
Entrega II
***

Una vez más, voy a hacer una comparación de un comando muy útil que se encuentra tanto en Linux como en Windows. De hecho, en Windows no estoy muy seguro de que se utilice tanto. Ese comando es el shutdown. Sí, en Linux tenemos halt y reboot. Pero, la gracia está ahí, en que también podemos un tercero que tiene su equivalente en el sistema operativo de los ventanucos (como decía un compañero de clase).

Nos vamos a Linux. Pedimos la ayuda con

shutdown -?

devolviéndonos la siguiente captura:

shutdown -?

Luego, si probamos a hacer 

shutdown 3 apago el sistema

el resultado será que se apagrá en 3 minutos con el mensaje introducido:

shutdown 3 apago el sistema

Es decir, que es la forma más básica de usar este comando. Ahora. ¿Y si quisiéramos ver la ayuda de Windows? Para pedir la ayuda de Windows ejecutamos

shutdown -?

con el siguiente resultado

Shutdown -?

Y el apagado similar al que he mostrado antes es poniendo en la consola

shutdown -s -t 0 /c "Adiooooos"

Ahora, pongamos que queremos cancelar el apagado estando en Linux. ¿Qué haríamos? Ejecutaríamos 

shutdown -c

shutdown -c

Y en Windows... Es que se me ha colado el Melissa, Sasser, MyDoom (¿eran estos?) y me sale un cartelito diciendo que se me va a apagar en un minuto... y no se pararlo. No me deja quitarlo. Para poderlo quitar, vamos a usar

shutdown -a

El otro comando que nos va a ser de utilidad va a ser el de reiniciar. En Windows podemos usar directamente

shutdown -r -t 0

y ya está, en unos instantes debería de estar reinciándose. Si hubiese algún problema, siempre se puede añadir la opcion -f para forzar el cierre de las aplicaciones.

Como se podréis observar, los parámetros se pueden usar con el guión (-) o con la barra (/).

¿Cómo se podría hacer en Linux? Hay dos formas. Una, ya comentada es usar

reboot

La otra, que es la que nos ocupa, es seguir usando shutdown.

shutdown -r 1 adioooossss

y saldría algo parecido a lo del pantallazo:

shutdown -r 1 adioooossss

Vamos a recopilar. Porque parece mucho, pero han sido dos cosas: apagar, reiniciar, y parar cualquiera de las dos acciones.

Nos queda otra opción muy interesante. Y es hibernar. La verdad, no se cómo pedirle al shutdown de Linux que hiberne. Ahora lo busco y os lo cuento. En Windows lo descubrí escribiendo este post por casualidad. Como nunca lo había hecho, se me ocurrió escribir

shutdown  -h

para volver ver la ayuda... y se me apagó el equipo. Así es como descubrí que le había pedido que lo hibernara.

En Linux... ni idea. He encontrado alguna cosa rápido y corriendo pero no me acaba de convencer. Hay una opción más que quería contar, pero he visto que hacía muy largo el post, por lo que he decidido montarlo en 2 entregas. Como siempre, si queréis comentar algo al respecto, sois bienvenidos.