En los últimos años los sistemas GNU/Linux han evolucionado mucho. De la parte de GNU casi diría que queda poco más que el compilador.
Una de las cosas que más ha cambiado es el sistema de arranque. Ahora systemd es un sistema que se ocupa de casi todo.
No hay mucha, o no la he encontrado, documentación sobre esto en castellano. Ni siquiera es que haya mucha en inglés, salvo un montón de generalidades, foros donde se dice lo que se podría hacer, consultas… pero muy poca documentación concreta de cómo podemos utilizar todo esto.
No es fácil ponerse con un proyecto de documentación en la wiki. Hay un montón de cosas pendientes de terminarse, algunas de actualizarse… En fin. Al caso.
Habéis manejado servicios y objetivos en Linux? ¿Temporizadores? Conocéis alguna documentación de calidad sobre ello? O tenéis una mano para ponerla en la wiki?
Hola @karlggest :
La verdad es que lo he tocado poco , pero cuando algún servicio me ha dado algún problema , principalmente cuando se inició la transición a systemd pues tiraba de terminal , por ejemplo si quería saber de packagekit , pues man pkcon.
Sé que está en inglés , pero al que no se maneje puede traducirla en línea rápidamente ya que manpages-es pues le falta por traducir mucho y es difícil tenerlo al día.
Temporizadores , lo suelo hacer con crontab , en el servidor me va muy bien.
Que sirva de up , a ver si alguno por ahí tiene más referencias.
Saludos.
Hola:
Por seguir comentando , otras de las cosas que suelo usar , es enmascarar servicios de systemd que no uso.
Por ejemplo , en escritorio no uso lv2-monitor , mdamd , postfix y así systemd no tarda tanto en revisar todo.
Saludos.
Quizá buena parte de la carencia de documentación se explique porque el sistema sigue soportanto todo lo que era “el viejo estilo system V”. Una cosa guay del sistema nuevo es tener servicios y disparadores (temporizadores) en el espacio de usuario.
Por supuesto hay un montón de cosas que cambian. Por ejemplo, los ficheros temporales ahora los maneja systemd-tmpfiles. Aparte de categorizar y alguna corrección, he añadido timers a la lista de unidades y un esbozo de página para ellos y poco más. También he añadido la sección “instantáneas” (snapshots con systemd).
[edito]
¿Qué podría poner al principio como información relacionada o necesaria?
Me parece que si he visto información de systemd ¿ en SUSE o en OpenSUSE? miraste ahí ?
El principio o inicial SysV (init) , seguido de Upstart (entre ellos creo que estuvo SUSE y no se si openSUSE en versión 11, en 12.1 se pasa a systemd.
En esas épocas hubo mucha polémica sobre esto.
En principio la SysV tenía una jerarquía en serie (fácil para determinar un fallo) , upstart creo que al principio empezaba en serie y después en paralelo.
Y systemd en paralelo .
Systemd, a cambiado bastante desde que salio, se ven partes sencillas, donde se puede comparar con las de init (sysVinit) , ejemplo los target y run level , y la compatibilidad que sigue manteniendo (creo que se puede instalar un mini sysVinit , en yast soft, no se si está relacionado con systemd-sysvinit y las tools) , podría en parte ser algunos de los log que se mantinen ? , no todo paso a journalctl
Las partes, siguen siendo las mismas : 6 ;
Systemd : utilidades, demonios,target, core,librerías y kernel , en utilidades no se si se añadió alguna nueva .
También está la de arch en español y algún que otro tuto, la de la wiki, de openSUSE, la veo muy bien (aunque hay partes que tengo dudas, ejemplo se crea un archivo de texto, después se abre y se añade, ¿cual se abre? no dice cual es , eso está en el ejemplo , es decir 1º creas un archivo foo.sh y a continuación abres uno nuevo para editar lo , creo que se refiere a foo.service, no lo se, me supongo que sera ese.
Hola @karlggest :
Lo primero darte las gracias por el esfuerzo y tu trabajo.
Sobre tu edit:
En la página de inicio de systemd (la del enlace que has puesto) , haría --es mi opinión-- una pequeña introducción que sin ser una perorata sea un poco más amplia.
Por ejemplo esto:
" Systemd es un sistema de inicio, administración de servicios y gestión de sistemas para sistemas operativos GNU/Linux. Fue desarrollado por Red Hat y se ha convertido en el sistema de inicio predeterminado en la mayoría de las distribuciones de Linux modernas, incluidas Archlinux,Debian, Fedora, openSUSE y Ubuntu .
Systemd tiene varias características principales que lo distinguen de otros sistemas de inicio, como SysVinit y Upstart:
Paralelismo: systemd puede iniciar servicios en paralelo, lo que acelera el proceso de arranque.
Dependencias: systemd puede establecer dependencias entre servicios, lo que garantiza que los servicios se inicien en el orden correcto.
Unidades: systemd utiliza un sistema de unidades para describir el comportamiento del sistema y de los servicios.
Registros: systemd utiliza un sistema de registros central para registrar los eventos del sistema.
Cómo funciona systemd
Systemd se basa en un modelo de unidades para describir el comportamiento del sistema y de los servicios. Cada unidad es un archivo de texto que contiene información sobre un servicio o una función del sistema.
Las unidades se pueden clasificar en tres tipos principales:
Servicios: Las unidades de servicio describen servicios que se ejecutan en segundo plano.
Objetos: Las unidades de objeto describen objetos del sistema, como puntos de montaje o dispositivos de almacenamiento.
Targets: Las unidades de target describen un conjunto de unidades que se inician juntas.
Cómo utilizar systemd
Systemd proporciona una serie de herramientas para gestionar servicios y unidades. La herramienta principal es systemctl, que se utiliza para iniciar, detener, habilitar y deshabilitar servicios, así como para establecer dependencias entre servicios.
Para obtener más información sobre systemd, visite la documentación oficial: Index of /software/systemd.
Ventajas de systemd
Systemd ofrece una serie de ventajas sobre otros sistemas de inicio, como:
Eficiencia: systemd es más eficiente que otros sistemas de inicio, ya que puede iniciar servicios en paralelo.
Flexibilidad: systemd ofrece un mayor control sobre el comportamiento del sistema y de los servicios.
Seguridad: systemd incluye funciones de seguridad integradas para proteger el sistema de ataques. "
Esto no significa que lo que está puesto esté mal.
Pero en la página de inicio , da una idea general algo más amplia.
He puesto ese texto en la página de sytemd con unos ligeros cambios para organizar mejor la página (introduciendo secciones de Acerca De, Características y Ver Más, y he enlazado el “uso” a la página sobre el “uso”.
Sí, la hay. Pero salvo documentación específica en inglés, todo lo que he visto es muy general e incluso la documentación en inglés es, bien, general.
Por ejemplo, si quieres editar un servicio puedes hacerlo con systemctl edit servicio. Esto crea una versión en un fichero llamado .d/override.conf y utiliza el editor de texto que tengas definido en la variable de entorno correspondiente.
Tanto la sección de temporizadores como la de instantáneas que he añadido son traducción directa de la documentación en openSUSE.
He añadido la aclaración de que es un ejemplo sobre un script que tendrías previamente. La parte de editar no estoy seguro de cómo ponerlo, ya que creo que una forma de crear una unidad es con systemctl edit --full servicio.
Precisamente.
Una cosa interesante es cómo afecta esto a MicroOS. Entiendo que al editar un servicio con systemctl crea una instancia nueva automáticamente, pero no sé si es el caso en general.
Sobre MicroOS --aun no lo he probado-- quiero pensar que systemd está en la capa inmutable.
Es decir /usr , /bin , /sbin no se pueden modificar , pero /etc ¿si?
Porque de ser así se podría modificar el comportamiento del servicio , pero sería imposible hacer uno nuevo , salvo que al instalar un programa este creara su servicio correspondiente.
Tendría que analizar una máquina con MicroOS para averiguarlo.
En este caso , por ejemplo sé que NixOS tiene una herramienta para esto que se llama nixos-rebuild y de ella penden varios tipos de rebuild.
Habrá que seguir estudiando…
/etc está en su sistema de ficheros de solo-lectura. Tengo un error al apagar que es precisamente que no es capaz de desmontarlo Lo he reportado para kalpa pero lo he visto en MicroOS y en Aeon.
Lo que leo en SLE Micro Administration Guide me deja más dudas que certezas, aunque reconozco que mi inglés es un poco así también.
En la documentación que he traducido se incluye la posiblidad de crear snapshots. Entonces en MicroOS es posible que se creen automáticamente al usar systemctl edit? O cómo hago para aplicar un cambio? De hecho, en la documentación de Aeon se sugiere por ejemplo el comando
# hostnamectl set-hostname <new name>
para cambiar el nombre de la máquina y que al reiniciar se habrá aplicado el cambio. Eso me hace pensar que tal comando crea un snapshot y por eso hay que reiniciar. En otros comandos (por ejemplo systemctl edit …) tampoco se indica que haya que hacer nada específico para modificar el sistema en curso, simplemente reiniciar.
Pero una deducción es eso, una deducción. No veo nada que aclare si esos comandos aplican un snapshot automáticamente, o si modifican directamente /etc por mucho que se supone que no.
Todo este rollo para decir que si /etc es solo lectura, cómo demonios se modifica!
Hola:
Gracias por el enlace.
A primera vista entiendo que /etc también está en la capa inmutable , pero no lo está exactamente , es una capa “overlay”…esté término podríamos traducirlo como recubrir , por lo tanto es como si hubiese 2 /etc (que pueden ser iguales o no) , los llaman lowerdir y upperdir , pero para que esto ocurra hay que crear una nueva instantánea.
De hecho pone esto: " Cada vez que se crea una nueva instantánea (por ejemplo, como resultado de una actualización del sistema), el contenido de “/etc” se sincroniza y se utiliza como base en la nueva instantánea. En términos “OverlayFS” , la instantánea actual “/etc” se monta como “lowerdir” . La nueva instantánea de “/etc” se monta como “upperdir” .
Si no hubo cambios en “/etc” “upperdir” , cualquier cambio realizado en “lowerdir” es visible para “upperdir” .
Por lo tanto, la nueva instantánea también contiene los cambios con respecto a la instantánea actual “/etc” …"
Ahora también aclara que si se modifican las dos instantáneas no se realizarán los cambios de hecho pone:
" Por lo tanto, no recomendamos realizar cambios “/etc” después de que se haya creado una nueva instantánea y el sistema no se haya reiniciado.
Sin embargo, aún puede encontrar los cambios en el “/var/lib/overlay/” directorio de la instantánea en la que se realizaron los cambios.
Mi favorito es cuando a Brown le preguntan por documentación y tal y dice que como mucho un manual de Podman
Aunque reconozco que el mayor asunto está en que como se ha mantenido la compatibilidad hacia atrás, hemos estado usando el sistema “como siempre” cuando en los últimos tiempos ha cambiado un montón.
A ver si aprovecho para ponerme al día y de paso poner al día la wiki…
Hola:
Acabo de instalar Micro OS (Kalpa).
De momento es “alfísima” vamos está en pañales.
Ya sé que criticar es fácil.
El overlay funciona sobre una transacción , si haces varias , solo toma la primera.
Ejemplo:
sudo transactional-update pkg in ubuntu-fonts
Lo hace y si en unos minutos después instalo otra cosa , por ejemplo: terminus-ttf-fonts
Y Después reinicio , solo estarán las ubuntu-fonts , las terminus no aparecen.
Si quiero instalar las dos , tengo que hacer un
sudo transactional-update pkg in ubuntu-fonts terminus-ttf-fonts
Con el sistema en marcha solo hace una transacción , la primera , las demás no las hace , hay que reiniciar primero.
Un atraso , por lo menos de momento.
Seguiremos probando , pero de momento tumbleweed con timeshift , fácil sencillo y para toda la familia.
En un servidor tal vez , en escritorio tienen que darle la vuelta.
Saludos.
En este caso la teoría y la práctica coinciden:
" Por lo tanto, no recomendamos realizar cambios “/etc” después de que se haya creado una nueva instantánea y el sistema no se haya reiniciado .
Yo la tengo puesta (Kalpa) en un viejo portátil y oye, funciona bien y todo. Tiene cosas.
Por defecto no tenía activada la actualización automática, y Discover no es capaz de hacer su propia activación automática.
Lo primero es asegurarse de que el temporizador (timer) correspondiente está activado y habilitado. Lo segundo puede arreglarse manualmente así:
No hay razón para no usar eso también para Tumbleweed o incluso Leap: simplemente se aplicará a los paquetes instalados con Discover (o flatpaks en general).
El servicio de actualización (el general, con transactions-update) incluye la configuración de que esté conectado a corriente. No estoy seguro de si eso es razonable para un portátil: si no está conectado, se salta la actualización hasta que pasen 12 horas.
Aunque también es verdad que esa opción permite usar cualquier instantánea a condición de que sepas cuál es.
Me parece curioso que se recomende sudo transactional-updates shell solo para depurar. Esa opción usa transactional-update para crear una nueva instantánea y te abre un shell bash como root en ella. Eso te
permite ejecutar cualquier número de comandos -pero no puedes usar systemctl edit servicio, por ejemplo.
Hay que reconocer que la idea es no usar transactional-update para instalar paquetes salvo que no haya más remedio. Lo suyo es usar flatpak y en caso de emergencia, distrobox. Así que con un poco de amor en Plasma (Wayland, probablemente, Discover: al final deberías poder ir a Configuración del Sistema y en Actualización del software seleccionar “automáticamente” y ya poder olvidarte del asunto, y bueno, paquetes o servicios para dolphin como kim y tal)
Hola:
Seguro que tienes razón.
Pero para un “animal de la terminal” como yo , usar discover con flatpack me va a costar.
En esto veo a snap por delante , de cara al usuario , dejando de lado el tema de la “tienda cerrada de software libre”.
Saludos.
Seguiremos investigando y probando.
Brown asegura que snap lo del tema de la seguridad se la trae al pairo y que cada vez que reportan cosas que ni siquiera los mandan a paseo, así que snap es una guerra para montarlo -además hay que usar apparmor y todo esto está con selinux. No sé si es algo que se pueda cambiar sin coste.
Pero que no se nos escape que Aeon y Kalpa están enfocados en las personas usuarias de aplicaciones gráficas, no del terminal. No he usado ChromeOS pero me da en la nariz que no es muy diferente a Android.
Aunque bueno, con los contenedores, distrobox y toolbox, etc. sí que se le puede dar vidilla al terminal, pero yo creo que en eso Slowroll/Tumbleweed siempre serán mejores.
Hola:
ChromeOS es Gentoo con aplicaciones propias (privadas google) y una licencia muy retorcida para hacer encaje de bolillo.
Pero ahí hay dos particiones /root distintas y una tercera de transición , que ellos llaman A y B y si estás trabajando en A y la modificas , el sistema cuando reinicias , si no hay problemas con la transición la mantiene como A y la antigua A que se fue a la transición pasará a ser la nueva B.
La verdad funciona muy bien , el problema es que es un sistema limitado a su ecosistema , eso si , puedes instalar un consola GNU/Linux (Debian stable) para hacer cosas.
Pero en si el sistema no está mal concebido , de hecho pienso que NixOS sigue esa impronta.
Sobre lo de apparmor , Tumbleweed lo usa , de hecho MicroOS usa selinux por temas de SUSE , me imagino que ahí irá a parar con el tiempo.
Si ,de momento para escritorio veo más futuro a slowroll y tumbleweed porque no limita el uso , puedes hacerlo por la vía que quieras.
Por cierto mañana --en un rato-- toca actualizar ambas a ver que tal van este viernes.
Saludos.
En la sección Estructura_básica_de_una_unidad aunque el título sea chulo, el contenido se limita a un ejemplo
Veamos. Entiendo que un fichero de configuración de una unidad requiere necesariamente la sección [Unit]. No estoy seguro de que [Install] sea obligatorio: ¿puede que sólo lo sea para servicios?
Después tendrá que haber una sección que defina el tipo de unidad: [Timer], [Service]… pero por ejemplo network.target sólo tiene sección de [Unit].
Hay una página para Objetivos (target) y otra para Temporizadores (Timers), así que tiene sentido que haya una para Servicios (Service). Me gustaría en ese caso que las tres páginas tuvieran una estructura más parecida para facilitar su consulta.
[Añado]
En cada página va a ir un cuadro con dos columnas para añadir páginas de la propia wiki relacionadas o bien páginas externas también relacionadas. Ahora el asunto es seleccionar cuáles Obviamente, ninguna de las que viene en el menú
Lo he reportado para kalpa pero lo he visto en MicroOS y en Aeon.
Obviamente, ninguna de las que viene en el menú