Seguridad Wireless - Wifi

Sistemas operativos => Zona GNU/Linux => Live Wifiway (sólo 32 bits) => Mensaje iniciado por: Hwagm en 30-12-2019, 02:24 (Lunes)

Título: Entrañas de slax
Publicado por: Hwagm en 30-12-2019, 02:24 (Lunes)
Estructura de directorios Slax

Todos los archivos de datos Slax se encuentran en el medio de arranque en un solo directorio. No sorprende que el nombre de ese directorio sea 'slax'. Toda la magia sucede adentro. Aquí hay una descripción general de la estructura de directorios simplificada; los directorios son rojos , también se mencionan algunos archivos interesantes, en cursiva :

slax
├─── arranque
│ ├─── isolinux.bin
│ ├─── syslinux.cfg
│ ├─── initrfs.img
│ ├─── vmlinuz
│ └─── ...
├─── cambios
├─── rootcopy
├─── 01-core.sb
├─── 02-xorg.sb
├─── 03-desktop.sb
├─── 04-chromium.sb
└─── ...


Arrancar el kernel de Linux

Cuando el BIOS de su com****dora arranca Slax, en realidad solo ejecuta el cargador de arranque SYSLINUX.
El cargador de arranque en sí se almacena en el archivo isolinux.bin o ldlinux.sys, dependiendo de su medio de arranque: el CD / DVD usa isolinux.bin, el disco USB o el disco duro usan ldlinux.sys.

Tan pronto como se ejecuta el gestor de arranque SYSLINUX, aprende qué hacer a continuación desde su archivo de configuración (lo adivinó) syslinux.cfg.

En Slax, este archivo de configuración contiene instrucciones para mostrar un logotipo de arranque y, opcionalmente, proporcionar un menú de arranque si el usuario presiona una tecla antes del tiempo de espera.
Cuando el contador de tiempo de espera llega a cero o el usuario sale del menú de arranque, el cargador de arranque SYSLINUX carga dos archivos en la memoria:
 vmlinuz (kernel de Linux) e initrfs.img (sistema de archivos raíz base).
El progreso se indica mediante un flujo continuo de puntos impresos en la pantalla. Una vez que se cargan los archivos, el binario vmlinuz se ejecuta para iniciar el kernel de Linux.

Pre-inicio

En condiciones normales (cuando una distribución estándar de Linux está comenzando desde un disco duro), el kernel de Linux montaría el sistema de archivos raíz desde el disco duro y /sbin/init se ejecutaría como el proceso principal que se encarga del inicio del sistema.
 En Slax, la situación es diferente: no hay un disco duro para montar el sistema de archivos raíz, pero el núcleo seguramente necesita algún proceso de inicio para iniciarse.
 Para ese propósito, Slax lleva un sistema de archivos base en el archivo initrfs.img: es un archivo comprimido de CPIO con algunos directorios y archivos dentro, incluidas las herramientas principales de Linux (comandos) y el init deseado.

Entonces, después de que el kernel de Linux se haya inicializado con éxito y tenga un control total de su com****dora, su última tarea es encontrar el archivo CPIO mencionado en la memoria (fue cargado allí desde el archivo initrfs.img por el cargador de arranque syslinux como seguramente recordará), extracto it (en un área de memoria que actúa como un sistema de archivos raíz temporal, llamado initramfs) y ejecuta el proceso temporal /init desde allí.


Escaping initramfs

En este momento, tenemos un kernel de Linux totalmente inicializado en ejecución, el área initramfs en la memoria está poblada por un sistema de archivos raíz temporal con solo los comandos más básicos de Linux, y el inicio temporal recién iniciado.

Tener el sistema de archivos raíz temporal en initramfs no es ideal, ya que no admite la pivot_root sistema pivot_root , una operación importante que se utilizará más adelante en el proceso de arranque.

Necesitamos cambiar de initramfs a otra cosa. Para hacer eso, el init temporal primero monta un sistema de archivos tmpfs sobre /m , mueve todos los archivos y directorios allí, incluido el script init, y usa switch_root para hacer de este tmpfs /m la nueva raíz y reiniciar el init desde allí también . La estrella negra denota el directorio que se mueve.

initramfs como root:
(initramfs)
/ /
├─── bin
│ ├─── sh
│ ├─── monte
│ └─── ...
├─── dev
├─── mnt
├─── m (tmpfs) ★
├─── memoria
├─── proc
├─── sys
├─── init
└─── apagado
->


initramfs después de pasar a tmpfs:
(initramfs)
/ /
└─── m (tmpfs) ★
├─── bin
│ ├─── sh
│ ├─── monte
│ └─── ...
├─── dev
├─── mnt
├─── memoria
├─── proc
├─── sys
├─── init
└─── apagado
->


tmpfs después de switch_root:

(tmpfs) ★
/ /
├─── bin
│ ├─── sh
│ ├─── monte
│ └─── ...
├─── dev
├─── mnt
├─── memoria
├─── proc
├─── sys
├─── init
└─── apagado


No importa cuán extraña parezca toda esta acción (hemos terminado con la misma estructura de directorios que antes, parece que no hay ninguna mejora en absoluto), el cambio es significativo. Desde ahora, el sistema de archivos raíz temporal está en tmpfs en lugar de initramfs y, por lo tanto pivot_root operación pivot_root estará disponible cuando sea necesario en el futuro.

Quizás se pregunte por qué el sistema de archivos raíz actual todavía está etiquetado como temporal. Es porque todavía estamos al comienzo de la fase de construcción y construiremos el sistema de archivos raíz real más tarde, como se explica a continuación, combinando imágenes de datos comprimidos de Slax para la unión AUFS.


Búsqueda de datos Slax


Antes de que el proceso init pueda comenzar a buscar datos Slax en los dispositivos disponibles, debe configurar el entorno de trabajo. Los sistemas de archivos proc y sysfs se montan sobre /proc y /sys respectivamente.

Algunos controladores importantes del núcleo, como aufs, squashfs y loop, se cargan mediante modprobe, y los archivos de dispositivo se crean en el directorio /dev mediante el comando mdev.

Tan pronto como se pueda acceder a los dispositivos de almacenamiento a través de los archivos del dispositivo en /dev , el comando blkid se usa para filtrar solo aquellos que se pueden montar (que contienen un sistema de archivos conocido por el núcleo en ejecución).
Los dispositivos se examinan (montados en solo lectura sobre /memory/data/ ) uno tras otro, hasta que se encuentra un directorio de datos Slax válido.
Luego, se procesan todos los archivos con extensión .sb (Slax Bundles): para cada Slax Bundle, se crea un directorio en /memory/bundles/ y el paquete (que de hecho es un archivo de imagen comprimido de squashfs) se monta sobre él. . En el diagrama a continuación, el contenido de squashfs está en negrita.

(tmpfs)
/ /
├─── bin
├─── dev
├─── ...
├─── memoria
│ ├─── paquetes
│ │ ├─── 01-core.sb (montaje squasfhs) < ───┐
│ │ │ ├─── bin
│ │ │ ├─── etc
│ │ │ ├─── sbin
│ │ │ └─── ... │
│ │ ├─── 02-xorg.sb ...................... │ ...
│ │ │ ├─── etc │:
│ │ │ ├─── usr │:
│ │ │ └─── ... │:
│ │ ├─── 03-desktop.sb ................... │ ..: ...
│ │ │ ├─── usr │::
│ │ │ └─── ... │::
│ │ └─── ... │:: bucle
│ ├─── datos (dispositivo slax montado aquí) │:: montajes
│ │ └─── slax │::
│ │ ├─── boot │::
│ │ ├─── cambios │::
│ │ ├─── rootcopy │::
│ │ ├─── 01-core.sb ──── > ──── > ───┘::
│ │ ├─── 02-xorg.sb ....................::
│ │ ├─── 03-desktop.sb ....................:
│ │ └─── ...
│ ├─── cambios (todavía vacío)
│ └─── union (vacía todavía)
├─── proc (procfs montado aquí)
├─── sys (sysfs montados aquí)
└─── init


Poniéndolo junto con AUFS

Varias partes del sistema de archivos raíz final ahora se montan de solo lectura en carpetas separadas en /memory/bundles .
 Las utilidades y bibliotecas principales del sistema Linux como /bin/bash o /lib/ld-linux.so se encuentran en /memory/bundles/01-core.sb/ ,
 los archivos relacionados con el entorno de escritorio se pueden encontrar en
/memory/bundles/03-desktop.sb/
 , y así sucesivamente. Combinarlos en un solo sistema de archivos raíz, que incluso se puede escribir, solo es posible gracias a AUFS, un sistema de archivos tipo unión desarrollado por el Sr. Junjiro Okajima. AUFS es capaz de tomar varias carpetas (llamadas ramas) y combinarlas en un solo directorio. Eso es exactamente lo que sucede a continuación, las partes separadas se combinan, junto con un directorio  /memory/changes , en la unión AUFS, que se monta en /memory/union .

(tmpfs)
/ /
├─── ...
└─── memoria
├─── paquetes
│ ├─── 01-core.sb ───────── > ──────┐
│ ├─── 02-xorg.sb .................. │ .......
│ ├─── 03-desktop.sb ............... │ ......: ........
│ └─── ... │::
├─── cambios ──────── > ───────┐ │::
├─── ... ˅ ˅ ::
└─── unión < ═══════ < ═══════ < ───── <─────┘ <────┘
├─── bin AUFS
├─── montaje etc.
├─── mnt
├─── root
├─── sbin
├─── usr
├─── ...
└─── var



Cambios

El directorio vacío /memory/changes se puede escribir, por lo tanto, todo el montaje de AUFS en /memory/union puede escribir. Todos los archivos nuevos o modificados dentro de la unión se copian en este directorio vacío antes de que el sistema los cree o los modifique. Dado que el directorio para los cambios reside en tmpfs (que está en la RAM), todos los archivos nuevos y modificados se almacenan en la RAM y, por lo tanto, se pierden al reiniciar.

Sin embargo, si Slax se inicia desde un medio grabable, como un dispositivo USB o un disco duro, lo reconoce y monta la unidad grabable sobre /memory/changes antes de unirse con las otras ramas en unión, lo que significa que los archivos nuevos y cambiados se almacenará en el dispositivo de arranque en lugar de en la RAM, y el reinicio no los borrará.
 Esta característica se llama Cambios persistentes y se puede activar o desactivar mediante una configuración del menú de inicio.

Cambiando a la raíz real

En este punto, el sistema de archivos raíz final totalmente editable se ha integrado en /memory/union . La vida del init temporal está llegando a su fin. Utiliza las llamadas del sistema pivot_root y chroot para hacer /memory/union la nueva raíz, transfiriendo la raíz temporal tmpfs a /run/initramfs/ en la nueva raíz.
 Finalmente, se ejecuta el verdadero /sbin/init del sistema de archivos raíz aufs. El arranque del sistema operativo Slax apenas comienza.


tmpfs root antes de pivot_root syscall:

(tmpfs) ★
/ /
├─── ...
└─── memoria
└─── unión (aufs) ★
├─── bin
├─── etc.
├─── raíz
├─── correr
│ └─── initramfs (vacío)
├─── sbin
│ ├─── ...
│ └─── init
├─── usr
├─── ...
└─── var

aufs como nueva raíz:

(aufs) ★
/ /
├─── bin
├─── etc.
├─── raíz
├─── correr
│ └─── initramfs (tmpfs) ★
│ ├─── ...
│ └─── memoria
│ └─── unión (vacía)
├─── sbin
│ ├─── ...
│ └─── init <- se ejecuta
├─── usr
├─── ...
└─── var


Agregar módulos a Slax sobre la marcha

El sistema de archivos raíz es editable y podríamos instalar nuevos paquetes de software mientras ejecuta Slax de la manera habitual, desempacándolos.
 Sin embargo, existe otra posibilidad de agregar nuevos archivos y directorios a Slax sobre la marcha sin instalar ningún paquete.
 Gracias al hecho de que Slax se está ejecutando con AUFS como root, podemos tomar algún otro sistema de archivos comprimido squashfs, montarlo en bucle sobre un directorio que reside fuera del árbol de aufs(por ejemplo, sobre /run/initramfs/memory/bundles/name.sb/ que está en tmpfs), y luego emite un comando de montaje que agrega el directorio recién montado a aufs como una nueva rama.

Todos los archivos y directorios del nuevo módulo squashfs aparecerán instantáneamente como si estuvieran instalados en el sistema desde el principio, mientras que la descompresión se realiza sobre la marcha, solo para los archivos a los que realmente se accede.

Del mismo modo, podemos eliminar una rama AUFS agregada previamente (squashfs montados) de la raíz aufs mediante otro comando de montaje. Los archivos que formaban parte de la rama desaparecerán instantáneamente del sistema, lo que efectivamente desinstala el paquete.

Apagado Slax

Cuando Slax se apaga para reiniciar o para apagar el sistema, realiza todas las tareas estándar como lo haría cualquier otro Linux, como desmontar todas las particiones montadas por el usuario, finalizar todos los procesos, etc.
Pero dado que el dispositivo de arranque aún puede estar montado y utilizado para cambios persistentes al final, se deben seguir algunos pasos antes de que se emita el apagado real, para garantizar que el dispositivo de arranque se desmonte limpiamente.

En lugar de apagar el sistema en el momento en que init cree que debería hacerlo, Slax vuelve a initramfs (esto es manejado automáticamente por systemd) y ejecuta un script de apagado /run/initramfs/shutdown .

El script de apagado que se encarga de anunciar el disco montado restante desde el cual Slax se inició y el dispositivo de arranque se expulsa limpiamente. Al final, la com****dora se reinicia o se apaga, dependiendo de lo que el usuario pretendía hacer.
Título: Re:Entrañas de slax
Publicado por: Hwagm en 30-12-2019, 02:25 (Lunes)
Traducido de la fuente original

https://www.slax.org/internals.php
Título: Re:Entrañas de slax
Publicado por: CristianEdgardo en 03-04-2020, 21:13 (Viernes)
saudos!!!

sera posible, que luego que monte /mnt/livemedia, monte /mnt/data.img (siendo data.img un archivo de imagen de disco guardado en el pendriverque esta wifislax64) para luego convertir la carpeta de usuario ¨root¨  en una accesodirecto que lleve a ¨/mnt/data.img/root¨ y guardarlos datos alli...

en otras seria montar changesdata abiertamente... pero se controlaria el espacio... que uno pueda entrar modificar (crear, borrar a gusto) y que no se vallael espacio a la miercole...tampoco seria de todo, en relidad root completo no, pero en el pen como es fat 32 no acepta los accesos directos, para eso crear la img con extension ext4...

se entiendo algo?
Título: Re:Entrañas de slax
Publicado por: Hwagm en 31-08-2020, 23:20 (Lunes)
no nada se entendio xd
Título: Re:Entrañas de slax
Publicado por: Hwagm en 31-08-2020, 23:22 (Lunes)
Sin embargo, si Slax se inicia desde un medio grabable, como un dispositivo USB o un disco duro, lo reconoce y monta la unidad grabable sobre /memory/changes antes de unirse con las otras ramas en unión, lo que significa que los archivos nuevos y cambiados se almacenará en el dispositivo de arranque en lugar de en la RAM, y el reinicio no los borrará.
 Esta característica se llama Cambios persistentes y se puede activar o desactivar mediante una configuración del menú de inicio.emos

Eso quiere decir que usamos modo persistente, y luego inicio fresco, como tenemos las cosas en la raiz, los cargara ???

hay que probar

Tambien me he encontrado en modo live HD que me guarda las cosas en la particion de desarollo, me refiero a luego cuando monto en live usb

Que cosas mas raras... algo no esta bien

reformateando usb
Título: Re:Entrañas de slax
Publicado por: Hwagm en 01-09-2020, 02:29 (Martes)
Eso quiere decir que usamos modo persistente, y luego inicio fresco, como tenemos las cosas en la raiz, los cargara ???

hay que probar

No , no los carga, tanto si estamos en live HD o en live USB, pasa olímpicamente de la carpeta /wifiway/changes como tiene que ser

Tambien me he encontrado en modo live HD que me guarda las cosas en la partición de desarrollo, me refiero a luego cuando monto en live usb

Que cosas mas raras... algo no esta bien, si estaba bien, solo que hay tener cuidado y saber donde estamos, si estamos en modo persistente, aunque hayamos iniciado en modo live usb, si el sistema detecta una partición de linux, con la carpeta wifiway, es hay donde gravara las cosas, pero no como changes.dat, sino todas las carpetas raiz que se hayan modificado, ejemplo wifiway/changes/root ... etc... bin ...

reformateando usb -- listo, todo ok para probar.

Título: Re:Entrañas de slax
Publicado por: CristianEdgardo en 10-11-2020, 04:42 (Martes)
yo ya hablo de los sitemas como WS64 2.3
lo que pregunto es, si monto una imagen de disco y pongo en esa imagen montada la carpeta /root, funcionaria, se guardaria la dat ahi, y al proximo reinicio, las levantaria el sitema?
Título: Re:Entrañas de slax
Publicado por: Hwagm en 10-11-2020, 22:25 (Martes)
Es sencillo si trabajas en modo live HD usa módulos nuevos

Si es modo live usb usa el dat

Es sencillo de entender

Si trabajas modo live usb  nuevo módulo de /memory/changes

Todo lo demás pruébalo tu mismo y nos dices