Par ce qu'un systeme d'init a besoin d'etre turing complet ?
Je sais pas… Tu penses que l'informatique va évoluer ou pas ? Si tu penses que ca va encore évoluer ben il vaut mieux avoir un système turing compler, parceque sinon si on se retrouve sur un cas que l'on ne sait pas gérer on risque de devoir encore changer de système d'init.
Par cotnre si tu penses que l'informatique c'est un produit fini et stable, alors ca ne pose pas de problème.
Faudrait choisir. Systemd c'est nul par ce que : - c'est pas KISS, ca fait trop de choses - c'est pas turing complet, ca fait pas assez de choses
C'est clair qu'il faut faire un choix, mais tu as l'air de considérer que si je considère le produit à la fois comme incomplet ET surchargé c'est parce que je ne sais pas ce que je veux.
Et pourtant le produit est à la fois bloated (40 dépendances pour les units - et qu'on ne vienne pas me dire qu'on peut désactiver des units, il y a tellement de dépendances croisées et de d'assomptions que c'est un cauchemar) et incomplet (pas moyen de faire des templates par exemple - dans un monde ou on créé dynamiquement des VM à la demande c'est quand même dommage)
Le systeme de fichier chiffré que j'utilise ne ferait donc pas partie de la plupart des systemes de fichiers chiffrés ?
Grosso modo systemd fonctionne avec deux méthode de chiffrement, et recommande fortement d'utiliser luks. Egalement systemd ne fonctionne pas avec tous les systemes de fichiers à clef distante (ie il faut s'authentifier sur un serveur pour récupérer les infos sur la clef). Tu as un des deux systemes qui marche et ca te convient, tant mieux pour toi. Mais systemd continue quand même à ne pas fonctionner avec la plupart des systèmes de chiffrement existant.
On peut choisir si il faut tuer tous les process, uniquement le principal, ou aucun mais executer une commande particulière
Je sais je l'ai dit : On peut mettre un mode dégradé en place pour dire à systemd de ne surtout toucher à rien, mais du coup on est moins bien qu'avec SystemV init
Seulement si on choisit de ne rien tuer (la seule option valable dans ce cas) on ne peut plus rien piloter avec systemctl, il faut donc créer d'autres scripts (donc travail double et maintenance en parallèle) pour les opérations standard du daemon (restart/stop/reload etc.)
Il suffit que le service soit configuré pour utiliser systemd-ask-password pour demander le mot de passe.
Petit extrait : The purpose of this tool is to query system-wide passwords—that is passwords not attached to a specific user account.
Petit problème le mot de passe d'un certificat (apache par exemple) est à la fois non global au système ET lié à un utilisateur ET plusieurs instance du serveur peuvent avoir besoin de mots de passe différents (le proxy n'utilise pas forcément le même certificat que le serveur frontal). Donc pour débloquer des certificats systemd-ask-password ne marche pas.
Tout comme le reste c'est faux. http://0pointer.de/blog/projects/instances.html
Et blam en plein dedans, tout le but de cet article est d'expliquer comment se passer des templates en créant un service par fichier de config (et en éditant à la suite les liens symboliques à la main pour que ca marche).
Donc le but de cet article tout entier est d'expliquer comment contourner le problème des templates qui ne fonctionnent pas sous systemd.
Au final au lieu d'un script toto.sh que l'on peut appeler comme on veut (par exemple /etc/init.d/toto.sh config1) on se retrouve avec une horreur immonde. Si on a dix fichiers de config il faut créer 10 services
systemctl start toto@config0
systemctl start toto@config1
systemctl start toto@config2
…
systemctl start toto@config9
Puis ensuite bien sur aller éditer 10 liens symboliques à la main
Y a il un seul truc exact dans cette liste ? La quantité de mensonges par ligne dans ce message est assez impressionante !
Je suis supposé dire quoi là ? Te renvoyer ton commentaire insultant au visage en t'indiquant qu'il ne suffit pas de lire trois mots d'un article en anglais qui semble aller dans ton sens (de loin et dans le brouillard) mais qu'il faut aussi lire les specs et les comprendre.
[^] # Re: Tu portes vraiment bien ton pseudonyme
Posté par Kaane . En réponse au journal Archlinux est morte.... Évalué à 10.
Par ce qu'un systeme d'init a besoin d'etre turing complet ?
Je sais pas… Tu penses que l'informatique va évoluer ou pas ? Si tu penses que ca va encore évoluer ben il vaut mieux avoir un système turing compler, parceque sinon si on se retrouve sur un cas que l'on ne sait pas gérer on risque de devoir encore changer de système d'init.
Par cotnre si tu penses que l'informatique c'est un produit fini et stable, alors ca ne pose pas de problème.
Faudrait choisir. Systemd c'est nul par ce que :
- c'est pas KISS, ca fait trop de choses
- c'est pas turing complet, ca fait pas assez de choses
C'est clair qu'il faut faire un choix, mais tu as l'air de considérer que si je considère le produit à la fois comme incomplet ET surchargé c'est parce que je ne sais pas ce que je veux.
Et pourtant le produit est à la fois bloated (40 dépendances pour les units - et qu'on ne vienne pas me dire qu'on peut désactiver des units, il y a tellement de dépendances croisées et de d'assomptions que c'est un cauchemar) et incomplet (pas moyen de faire des templates par exemple - dans un monde ou on créé dynamiquement des VM à la demande c'est quand même dommage)
Le systeme de fichier chiffré que j'utilise ne ferait donc pas partie de la plupart des systemes de fichiers chiffrés ?
Grosso modo systemd fonctionne avec deux méthode de chiffrement, et recommande fortement d'utiliser luks. Egalement systemd ne fonctionne pas avec tous les systemes de fichiers à clef distante (ie il faut s'authentifier sur un serveur pour récupérer les infos sur la clef). Tu as un des deux systemes qui marche et ca te convient, tant mieux pour toi. Mais systemd continue quand même à ne pas fonctionner avec la plupart des systèmes de chiffrement existant.
On peut choisir si il faut tuer tous les process, uniquement le principal, ou aucun mais executer une commande particulière
Je sais je l'ai dit : On peut mettre un mode dégradé en place pour dire à systemd de ne surtout toucher à rien, mais du coup on est moins bien qu'avec SystemV init
Seulement si on choisit de ne rien tuer (la seule option valable dans ce cas) on ne peut plus rien piloter avec systemctl, il faut donc créer d'autres scripts (donc travail double et maintenance en parallèle) pour les opérations standard du daemon (restart/stop/reload etc.)
Il suffit que le service soit configuré pour utiliser systemd-ask-password pour demander le mot de passe.
Petit extrait :
The purpose of this tool is to query system-wide passwords—that is passwords not attached to a specific user account.
Petit problème le mot de passe d'un certificat (apache par exemple) est à la fois non global au système ET lié à un utilisateur ET plusieurs instance du serveur peuvent avoir besoin de mots de passe différents (le proxy n'utilise pas forcément le même certificat que le serveur frontal). Donc pour débloquer des certificats systemd-ask-password ne marche pas.
Tout comme le reste c'est faux.
http://0pointer.de/blog/projects/instances.html
Et blam en plein dedans, tout le but de cet article est d'expliquer comment se passer des templates en créant un service par fichier de config (et en éditant à la suite les liens symboliques à la main pour que ca marche).
Donc le but de cet article tout entier est d'expliquer comment contourner le problème des templates qui ne fonctionnent pas sous systemd.
Au final au lieu d'un script toto.sh que l'on peut appeler comme on veut (par exemple /etc/init.d/toto.sh config1) on se retrouve avec une horreur immonde. Si on a dix fichiers de config il faut créer 10 services
systemctl start toto@config0
systemctl start toto@config1
systemctl start toto@config2
…
systemctl start toto@config9
Puis ensuite bien sur aller éditer 10 liens symboliques à la main
Y a il un seul truc exact dans cette liste ?
La quantité de mensonges par ligne dans ce message est assez impressionante !
Je suis supposé dire quoi là ? Te renvoyer ton commentaire insultant au visage en t'indiquant qu'il ne suffit pas de lire trois mots d'un article en anglais qui semble aller dans ton sens (de loin et dans le brouillard) mais qu'il faut aussi lire les specs et les comprendre.