Cher journal,
Tu n'es pas sans savoir que systemd use (et abuse ?) des cgroups pour gérer les services qu'il démarre. Ceci est une bonne façon de traquer les processus pour les auteurs mais cela rend le logiciel incompatible avec les autres système libre de type Unix (avec les autres systèmes tout court en fait mais ça, on s'en (d|f)outait). Dans les autres Unix libre, un développeur Debian/Hurd qui passe son Google Summer of Code à tenter d'avoir des script d'initialisation commun entre Debian/Linux et Debian/Hurd s'est rendu compte que le futur de l'init chez Debian, c'était Upstart ou systemd afin d'avoir un init qui puisse offrir plus de fonctionnalités.
Or, même Upstart vise l'utilisation des cgroup parce que la technique actuelle (utilisation de ptrace) est plus un hack qu'autre chose et ptrace n'existe pas dans Mach (le noyau de Hurd) (parce que ptrace n'est pas une belle interface et qu'il y a moyen de faire les choses mieux). Cela étant, il reste le choix entre les cgroup avec systemd et les cgroups avec Upstart. Il a donc décider de commencer l'écriture d'une interface de traduction pour cgroupfs qui soit compatible avec celle de Linux. On se rend donc compte que les BSD sont en train de se faire dépasser par le Hurd, ce qui est un peu la honte.
Pour ceux qui n'aiment pas les noyaux, un narticle sur l'intégration de Marble Cloud (un serveur de carte utilisant, entre autres, Openstreetmap) dans owncloud.
Et pour ceux qui n'aime pas le libre, une nimage.
# C'était déjà le cas.
Posté par Renault (site web personnel) . Évalué à 10.
On m'explique comment les scripts init de Linux qui était déjà incompatible entre les distributions pouvaient l'être avec *BSD et d'autres UNIX ?
Non car en fait, je ne vois pas dans ces circonstances en quoi Upstart et systemd c'est pire.
Puis à un moment, sur les couches bas niveau, il afut bien profiter de l'API du noyau à disposition, si on se limite au dénominateur commun, quel est l'intérêt de développer des fonctionnalités de lo mort qui tue dans le noyau ?
[^] # Re: C'était déjà le cas.
Posté par Tonton Benoit . Évalué à 8.
+1, d'ailleurs, s'il cherche un système d'init moderne et portable il devrait regarder du coté d'OpenRC, à mon avis le seul qui mérite qu'on y jette un œil avant de le bazarder pour utiliser systemd à la place.
OpenRC est classique (scripts shell, runlevels…), mais il supporte aussi des plugins sous forme de bibliothèques, OpenRC est portable (pas de bashisms) et porté (Gentoo-FreeBSD), OpenRC est moderne il est adapté aux différents systèmes de virtualisations et permet le suivi des processus au lieu de n'être qu'une bête collection de scripts hétéroclites comme l'init de Debian.
[^] # Re: C'était déjà le cas.
Posté par Misc (site web personnel) . Évalué à 6.
Openrc reste en bash.
Ce qui veut dire "pas de jeux de tests", "pas de vérification statique des fonctions" et "support assez pauvre des types de données". C'est pas vraiment ce que je qualifie de moderne, au moins au point de vue du développement.
[^] # Re: C'était déjà le cas.
Posté par Tonton Benoit . Évalué à 9. Dernière modification le 06 septembre 2013 à 01:18.
OpenRC reste un init classique avec des scripts sh (mais pas en Bash), classique aussi dans sa gestion des processus à base de pidfiles, même si les cgroups sont aussi supportés sous Linux.
SystemD à l'avantage de partir sur des bases nouvelles c'est pour ça que je le préfère quand-même, mais OpenRC à l'avantage d'être portable, lui.
Franchement, vu la bouse qu'est upstart, pour moi SystemD et OpenRC sont les deux seuls systèmes d'init "à voir".
[^] # Re: C'était déjà le cas.
Posté par Olivier Serve (site web personnel) . Évalué à 1.
OpenRC a un noyau en C avec du bash au dessus.
[^] # Re: C'était déjà le cas.
Posté par Bapt (site web personnel) . Évalué à 5.
Pas du bash, du shell sh! c'est pas du tout pareil :)
[^] # Re: C'était déjà le cas.
Posté par barmic . Évalué à 2.
Pour tenter de créer une compatibilité, j'avais vu certains avancer l'idée de faire comme CMake : un format source qui serait compilé vers le système d'init que l'on souhaite. L'idée me paraissait intéressante, mais je n'ai aucune idée de s'il existe un quelconque projet pour le mettre en place.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Bah...
Posté par Zenitram (site web personnel) . Évalué à 10.
Si un étudiant du Summer of Code est capable d'ajouter la fonctionnalité à Hurd, je ne doute pas que quand il y aura un besoin, la même chose sera faite pour les BSD.
Bref, beaucoup de trolls pour juste un non besoin en fait.
Donc le prochain sera Debian/kBSD, et tout le monde sera content, Debian passera à systemd et les admins nostalgiques "c'était mieux avant" n'auront plus aucune distro qui souhaite s'emmerder à leur place avec les vieux scripts difficiles à debugger ou il vont passer à Ubuntu la distro pour "admins du dimanche", un comble (ça, c'est pour tenter de lancer un grand grand fil de commentaires)
[^] # Re: Bah...
Posté par Etienne Bagnoud (site web personnel) . Évalué à 3. Dernière modification le 05 septembre 2013 à 19:03.
Bah, d'ici la prochaine Debian, il y aura un nouveau système d'init encore plus révolutionnaire que systemd. Non parce que ce qui manque dans l'init actuel c'est de pouvoir, par exemple, lancer le service X quand le service Y a été lancé sur une autre machine puisqu'X est une réplication de Y ….
Qui pour commencer un projet d'init qui va mélanger les fonctionnalités de systemd et celles de pacemaker ?
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Bah...
Posté par Misc (site web personnel) . Évalué à 1.
Upstart pourrait le faire, vu que le but est d'avoir des events, et ça me semble logique de relier upstart et juju pour obtenir ça. L'orchestration sur le cloud à ce niveau ne me semble pas déconante, et si ça permet d'unifier et d'avoir qu'une base de code qui fait abstraction de la machine, avec une seule syntaxe de configuration, ça peut donner des choses.
Ensuite, sachant que systemd permet déjà le démarrage à la demande d'un autre système dans un container, faire l'ajout d'un démarrage à la demande d'un système ailleurs, ça peut se faire aussi ( par exemple, j'ai un truc qui monte un tunnel ssh automatiquement, et je pourrais avoir le serveur de l'autre coté à la demande aussi ).
[^] # Re: Bah...
Posté par Etienne Bagnoud (site web personnel) . Évalué à 2.
Non mais pacemaker fait ça. Tu démarres avec l'init classique les services de bases et ensuite pacemaker (corosync avant lui) et tu laisses pacemaker démarrer tes services l'un après l'autre en fonction des diverses contraintes que tu lui as indiqué. Sur les serveurs, l'init risque de devenir de plus en plus négligeable, il sera là juste pour lancer les deux, trois services de bases et les vrais services seront délégués à un système comme pacemaker. Et même dans les petites entreprises, le coût de deux machines est négligeable et l'installation d'un Pacemaker/DRBD/OCFS2/CTDB/Samba devrait tendre à se démocratiser.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Bah...
Posté par ZeroHeure . Évalué à 4.
Les inscriptions pour le stage d'apprentissage de l'humour commencent bientôt. Je fais des prix…
:-)
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
# Tout va bien, je t'assure
Posté par Kaane . Évalué à 10.
On se rend donc compte que les BSD sont en train de se faire dépasser par le Hurd, ce qui est un peu la honte.
Non, non. Tout est OK. BSD possède tous les outils nécessaires pour implémenter un init façon systemd très facilement. Regarde simplement du coté des MAC de FreeBSD par exemple.
Donc si un jour il y a vraiment obligation d'avoir un truc similaire, on l'aura très très vite sous BSD.
[^] # Re: Tout va bien, je t'assure
Posté par Anonyme . Évalué à 6.
Awé ? I need explanations! (ce n’est pas ironique).
[^] # Re: Tout va bien, je t'assure
Posté par Kaane . Évalué à 9.
Awé ? I need explanations! (ce n’est pas ironique).
Dans les MAC il y a à peu près tout ce que font les CGroups et bien plus. On a du partitionnement, de la délégation de privilège, de l'isolement, de l'héritage de droits etc.
Pour faire court, il y a dans FreeBSD un système qui est proche de SELinux niveau fonctionnalité, mais nettement plus utilisable et lisible.
Ensuite le système d'init lui même n'est pas sysV - Il s'agit de l'init BSD historique - en l'occurence RC - Dont la conversion vers un système type upstart/systemd serait très simple. Les fichiers RC sont déjà très très normés, les places pour les différents éléments sont connus etc. Il faut bien voir que les *BSD ne fournissent pas un kernel mais tout un OS - de fait il n'y a qu'un seul système d'init et un seul groupe qui le maintien. Le bazar que l'on a eu au niveau des inits Linux ne s'est jamais vraiment produit sous BSD.
Il existe tout un tas d'init alternatifs qui fonctionneraient très bien sous FreeBSD si ons se donnait un peu de mal (OpenRC par exemple).
Après malgré la facilité qu'il y aurait à changer le système d'init et le fait que le système posséde depuis des années des utilitaires éprouvés pour faire tourner la nouvelle solution (certaines opérations sont déjà asynchrone au boot depuis des lustres) - ben personne de sérieux ne voit l'intéret de s'y mettre. En l'état actuel de qualité du rc, un changement permettrait peut-être de gratter une dizaine de secondes au boot (dans certaines conditions très particulières - pas de DHCP ou de firmwares à charger par exemple) mais n'aurait pas d'impact majeur. Le point le plus interressant étant ce que ça pourrait apporter à une machine avec beaucoup de jails qui tournent…
Pour une longue discussion sur le sujet en Anglais http://lists.freebsd.org/pipermail/freebsd-hackers/2012-June/039287.html
(Attention les experts systèmes arrivent un peu tard sur le thread, prendre les 10 premiers posts avec des pincettes).
[^] # Re: Tout va bien, je t'assure
Posté par Misc (site web personnel) . Évalué à 10.
proche, tu veux dire "si on rajoute les trucs manquants" et "si on code une policy, parce c'est tellement simple que personne commence, sauf des boites qui gardent ça pour elle grace à la license BSD" ?
Parmi les trucs manquants, tu peux mettre des labels sur les bases postgresql, sur les paquets réseaux via CIPSO ( notamment utilisé par openshift afin de sécuriser les échanges entre containers ), ou directement sur X.
Le systéme de MAC décrit sur le handbook Freebsd ( http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/mac.html ) ne permet pas de restreindre par type d'operation.
Tout au plus, tu arrives à remplacer un policy MLS de Selinux, avec les limitations que ça ne marche que pour un type plus restreint d'objet ( ie, les process, les fichiers et les interfaces réseaux ) la ou SELinux va plus loin, comme transmettre le lalbel via le réseau, sur une base postgresql, sur les comms dbus, et classifie ça par type de fichier ( socket, répertoire, etc ).
Les comms dbus, ç'est ce qui ressort du travail d'ubuntu pour le confinement des applications bureautiques. Les bases postgresql, c'est pour faire du multitenant pour un hébergeur, que ça soit publique ou interne. Transmettre le label sur le réseau, c'est utilisé par Openshift, pour être sur que ta machine ne parle que avec ton autre machine, ou ce genre de choses.
Donc le système de mac FreeBSD fait déjà des trucs simples , mais ça remplace quand même pas SELInux pour le MLS, loin de la.
Et ce qui intéresse AMHA la plupart des gens, c'est d'une part, de pas configurer la machine ( ie, ne pas passer son temps à faire des sysctl security.mac.portacl.rules=uid:80:tcp:80 pour dire que apache peut faire un bind sur le port 80 ), mais que ça soit fait par défaut. Et d'autre part, pouvoir avoir une granularité plus fine.
Tout les LSMs ou assimilés du monde se vante d'être plus simple que SELinux. Tomoyo, AppArmor, Smack, etc. Mais la simplification n'a pas l'air d'aider les gens à rajouter des politiques pour les softs ou à l'adoption, AppArmor se faisant ramoner la tronche à ce niveau, vu que je pense que c'est ce qui se rapproche le plus de SELinux sur la partie MCS, ie la policy targetted. Ramoner la tronche parce qu'il y a vachement moins de programmes confinés. Ramoner la tronche parce que les dites policys étaient troués, et ça va mettre du temps à tout fermer.
Donc soit c'est pas plus simple que SELinux, soit la complexité vient pas de SELinux mais du système à protéger.
[^] # Re: Tout va bien, je t'assure
Posté par Kaane . Évalué à 8.
proche, tu veux dire "si on rajoute les trucs manquants"
Non par proche je veux dire "Dans le même esprit que". C'est clair que SELinux fait pleins de choses que MAC ne fait pas, et que MAC avec les jails fait des trucs que tu peux imiter avec SELinux+OpenVZ - mais tu vas y passer un moment quand même.
Maintenant SELinux est ultra monolithique dans son approche. Chez FreeBSD tu vas avoirs plusieurs outils pour arriver grosso modo au même résultat.
C'est vrai que SELinux a une granularité plus fine que MAC (nettement) - mais c'est vraiment trop lourd à mettre en place et à maintenir.
et "si on code une policy, parce c'est tellement simple que personne commence, sauf des boites qui gardent ça pour elle grace à la license BSD" ?
C'est clair - et c'est surement parceque c'est très très difficile à faire qu'aucune distrib linux ou presque n'active les ACL ou le mapping de ports par défaut ? Ca fait quand même un peu mal en 2013 d'avoir le serveur Apache qui se lance en root et de devoir mettre le stagiaire dans le groupe "www" pour qu'il puisse modifier les CSS….
Parmi les trucs manquants, tu peux mettre des labels sur les bases postgresql, sur les paquets réseaux via CIPSO ( notamment utilisé par openshift afin de sécuriser les échanges entre containers ), ou directement sur X.
En ce qui concerne les bases postgresql tu peux faire quelquechose de très similaire avec des labels multiples sur FreeBSD en utilisant un partitionnement par tablespace.
En ce qui concerne CIPSO j'ai décroché depuis 2007 environ. Je ne sais pas du tout ou ca en est. En 2007 ils relancaient une grosse phase de draft, la 42ième depuis 1990. On a tenté de mettre en place un truc de tests pour des échanges en trusted Solaris et NetLabel. Ben plouf. Une recherche rapide sur internet me donne une page blanche à l'IETF et deux liens de 2006 sur les NetLabels Linux. En insistant un peu on trouve trois lignes dans un article Wikipedia sur Solaris. Vrai question : "C'est utilisé ce truc là ?" (Attention par utilisé je veux dire est ce que l'on arrive à faire négocier ensemble des machines qui n'ont pas la même version du kernel redhat, avec les policy redhat et tout le toutim - si ca permet juste à deux machines configurées à l'identiques par un admin unique de dialoguer de façon sécure c'est moyennement interressant)
------------------------------------------------------------------------------ SNIP
Pour en revenir au sujet de mon post, j'ai comparé les MAC BSD à du SELinux juste pour bien expliquer que FreeBSD a mieux que les cgroups en stock. C'est très largement possible de faire tout ce que font les cgroups avec MAC dans le cadre d'un portage systemd - surtout vu la façon assez légère dont les cgroups sont utilisés par systemd.
[^] # Re: Tout va bien, je t'assure
Posté par Misc (site web personnel) . Évalué à 4.
l'approche de selinux, c'est de mettre des labels et dire qui a le droit de faire quoi. la ou tu vois du monolitiques, d'autres vont voir de l'unification.
Les ACL sur les fs sont par défaut depuis un bon bout de temps.
Quand au mapping de port par défaut, j'ai pas vraiment pigé dans quel contexte est ce que tu parles de ça. Tout au plus, ça serait pour nfs et rpc, mais il me semble que c'est fait aussi.
c'est vrai qu'en 2013, ça me ferait aussi mal au cul de pas utiliser de vcs pour le site web et de laisser le stagiaire directement modifier le site.
D'une part, ça serait un gros hack, vu que ça implique d'avoir un servuer postgresql par personne que tu veux séparer ( car si tu as un serveur commun, les accès se font via le dit serveur, sous l'uid du dit serveur ). Et si tu as 1 serveur par personne, tu as quand même une consommation de ressources accrue, genre le cache, etc.
D'autre part, sepostgresql fait plus que ça comme on peut voir sur les objets :
http://selinuxproject.org/page/NB_SQL_9.0
Un tablespace postgresql va pas stocker une colonne, c'est la table, l'index ou la db.
http://www.postgresql.org/docs/9.2/static/sql-createtablespace.html
Donc la solution est encore une fois trés largement moins précise, loin de "très similaire".
encore une fois, c'est ce qui est prévu d'être utilisé par openshift online. Et il y a pas besoin que ça soit configurer à l'identique, juste de suivre les mêmes nomenclatures. Un peu comme dire "ton serveur web écoute sur le port 80 donc le web passe par ce port". Et le fait d'avoir une politique de sécurité unifié n'est pas une contrainte technique mais juste du bon sens. Il est claire que si tu restreint un accés à un type de document, faut le restreindre partout pour que ça soit globalement efficace.
Et comme tout ce qui concerne les questions de confiance dans le réseau, si tu as pas confiance dans l'autre machine, c'est pas un souci technique.
donc tu as comparé 2 frameworks de securité pour dire que Freebsd a un truc mieux pour gérer les ressources ? Et tu as comparé un truc granulaire et complet à un truc moins granulaire et qui fait la moitié. J'ai du mal à suivre, il suffit juste de dire "regarde, on remplace les cgroups par les jails pour la partie isolation", et "on remplace les cgroups par rctl pour la partie gestion de groupe", suivi par "du coup, si y a pas systemd, c'est bien parce qu'on pense que ça sert à rien, et qu'il faut pas attendre les BSDs pour avancer sur linux, on se débrouille bien tout seul".
[^] # Re: Tout va bien, je t'assure
Posté par Kaane . Évalué à 4.
l'approche de selinux, c'est de mettre des labels et dire qui a le droit de faire quoi. la ou tu vois du monolitiques, d'autres vont voir de l'unification.
Unification et coté monolithique n'ont pas grand chose à voir. C'est très bien que SELinux unifie les politiques d'accès (sans ironie hein), mais c'est un peu domage de devoir mettre en place tout le framework de a à z pour une politique de 3 lignes. J'ai bien conscience que vu la nature et les ambitions de SELinux il n'est pas possible de découper le framework en pleins de petits morceaux utilisables séparément, mais je préfère quand même l'approche biba de FreeBSD.
Les ACL sur les fs sont par défaut depuis un bon bout de temps.
Sur quelle distribution ? Parceque si les outils pour les ACL sont intégrés, c'est rare que les FS aient les ACL activés par défaut. Je change pas de sitrib tous les deux jours, mais l'année dernière il n'y avait guère que Suse et Fedora qui activaient les ACL par défaut.
Quand au mapping de port par défaut, j'ai pas vraiment pigé dans quel contexte est ce que tu parles de ça.
Tout simplement faire démarrer un service en écoute sur un port local non privilégié et rajouter une règle firewall pour faire le lien. Ca évite de devoir lancer tout un tas de service en utilisateur root (même si après les privilèges redescendent - c'est quand même pas top).
c'est vrai qu'en 2013, ça me ferait aussi mal au cul de pas utiliser de vcs pour le site web et de laisser le stagiaire directement modifier le site.
Même avec un VCS, à un moment ou à un autre il va bien falloir aller écrire dans /var/www (ou autre répertoire) et là sans les ACL tu as deux solutions : soit tu donnes le groupe www a tous les utilisateurs susceptible de devoir modifier le site (ou faire un commit si tu préfères), soit tu ajoutes l'utilisateur apache dans 200 groupes.
D'une part, ça serait un gros hack, vu que ça implique d'avoir un servuer postgresql par personne que tu veux séparer ( car si tu as un serveur commun, les accès se font via le dit serveur, sous l'uid du dit serveur ).
Alors distinguons bien deux cas :
a) Il s'agit d'un utilisateur avec un compte et un uid qui est logué en console et qui utilise, par exemple, psql - et là avec les labels multiples le mec il peut toujours se brosser pour accéder au contenu d'un tablespace qui n'est pas autorisé. (Je pensais que tu parlais de ce cas là)
b) Il s'agit d'un utilisateur logué à distance (par exemple sur le port 5432 via réseau) - et là de toutes les façons les accès se font via le serveur, sous l'uid du serveur. La seule chose qu'apporte SE-Postgres dans ce cas c'est que les restrictions et les droits ne sont plus validé seulement contre le système interne à Postgres mais aussi vis à vis d'un jeu de police de sécurité SELinux. Cependant si le plugin est compromis (ce qui implique qu'il n'était pas lui même protégé par une policy - ce qui serait idiot je l'admet) SE Linux ne verra rien passer des requètes faites à PostgreSQL.
Et comme tout ce qui concerne les questions de confiance dans le réseau, si tu as pas confiance dans l'autre machine, c'est pas un souci technique.
La question est de quoi ai-je besoin pour faire confiance à l'autre machine ? Si c'est juste tester la présence d'une clef ipsec est très bien dans le rôle, si j'ai besoin de plus que ça il faut que je sache le valider chez une machine tiers. A aujourd'hui si j'ai besoin de plus que la présence d'une clef privée, il faut que je maintienne le serveur complètement - ce qui peut être lourd. CIPSO était supposé répondre à ce problème - on devait être capable de s'envoyer des paquets certifiés qui anoncnet que le serveur distant est bien en train de faire tourner un apache à jour avec mod_rewrite désactivé, que le routeur machin droppe les paquets DHCP ver telle ou telle branche réseau, que les url de type xxx://#!!%/*.truc sont interdite etc.
Est-ce que aujourd'hui c'est possible vis à vis d'une machine que je n'administre pas ? Oui/partiellement/non ?
[^] # Re: Tout va bien, je t'assure
Posté par Johann Ollivier-Lapeyre (site web personnel) . Évalué à 4.
Le stagiaire peut (et doit) commiter dans le VCS…et n'a même pas d'accès au serveur (ou en tout cas il ne s'en sert pas). C'est un process d'intégration continue comme Jenkins qui va pousser (via un deb ou rpm) sur le serveur après une série de tests.
Et le retour à la version précédente en cas de soucis est aisé.
Et le stagiaire, il est content car personne ne va lui râler dessus parce qu'il aurait cassé le serveur (et personne ne râle sur son chef non plus du coup).
[^] # Re: Tout va bien, je t'assure
Posté par Kaane . Évalué à 2.
Le stagiaire peut (et doit) commiter dans le VCS…et n'a même pas d'accès au serveur
Le stagiaire a accès à un truc qui accès au serveur ("un truc" pouvant être composé de milliers de programmes à la queue leu leu).
Donc le stagiaire a des droits sur le serveur.
Le truc qui va écrire au final sur le disque dur du serveur (via deb, rpm, shadow copy etc.) doit avoir des droits sur le répertoire cible sur le serveur. Avec des ACL on peut limiter la surface d'attaque - avec des droits unix de bases on ne peut pas avoir des groupes qui ont des droits en lecture, d'autres qui ont des droits en écriture etc. et on se retrouve systématiquement à donner plus de droits qu'il n'en a besoin au stagiaire (Même si c'est au travers de 112 000 outils).
[^] # Re: Tout va bien, je t'assure
Posté par ckyl . Évalué à 5.
Bon non c'est la base du développement de tout produit.
Le stagiaire comme la plupart des contributeur il a un espace de travail une branche dédiée où sur une branche d'intégration qui n'est pas directement reliée à la production. La granularité en module se fait générallement à ce niveau là, tu n'as accès qu'aux projets sur lesquels tu dois bosser. Après c'est le rôle de quelqu'un d'intégrer vers la production en ayant valider les changements et en s'assurant de la cohérence de l'ensemble. Cette chaîne peut souvent être hierarchique.
Bienvenue dans les années 2000 ! C'est juste la facon standard de travailler pour les gens qui ont réfléchit 10 minutes et ont compris que le problème n'était pas une question de droit d'accès sur le serveur. De toute facon tout est packagé correctement et livré automatiquement.
Tu penses que ce sont les ACL sur le www de kernel.org qui s'occupe de la sécurité du noyau où alors l'organisation hierarchique des relectures/intégrations. Par ce que la aussi ton argument s'applique: le stagiaire qui soumet un patch il a accès au serveur.
[^] # Re: Tout va bien, je t'assure
Posté par Kaane . Évalué à 4.
On se moque que ce soit relié directement ou indirectement à la production. Le stagiaire a les droits sur le serveur et basta.
C'est amusant cette façon que vous avez tous de confondre organisation et sécurité - surtout dans un thread qui est centré sur les access control.
Peut importe que le chemin soit tortueux, passe par trente applis qui redistribuent les fichiers dans tous les sens et que quinze procédures de vérifications automatiques se déclenchent - la question est "le stagiaire peut-il créer des fichiers sur un répertoire situé sur le serveur sans l'intervention d'un admin ?". Si la réponse est oui, le stagiaire a les droits sur le serveur. (Et si la réponse est non - il y a des admins qui doivent sérieusement trouver la blague saumâtre).
Je ne remets pas en cause les avantages d'un VCS, mais il faut bien se rendre compte qu'un VCS est un outil d'organisation, pas de sécurité - même avec un VCS, même avec un système très complexe de validation automatique, le stagiaire a toujours les droits sur le serveur. Ca ne veut pas dire qu'il a un uid qui peut se loguer sur le serveur et écrire dans un répertoire directement - ça veut dire qu'il fait une manip sur une machine et que quelques temps plus tard un fichier sur le serveur est créé/modifié/supprimé.
Les VCS permettent de s'organiser pour éviter les accidents et pouvoir revenir facilement en arrière au cas ou un accident se produit quand même. Mais ils apportent 0 au niveau sécurité.
Et quand le stagiaire a besoin de pouvoir écrire (même indirectement) sur un répertoire qui doit être lisible par Apache mais pas par le monde entier, on se retrouve très vite limité avec les droits Unix standard - sur toute machine (même mono utilisateur) les ACL devraient être activés par défaut sur toutes les partitions, et l'admin ne devrait les éteindre que si il a une excellente raison de le faire. Ce n'est pas le cas aujourd'hui.
[^] # Re: Tout va bien, je t'assure
Posté par ckyl . Évalué à 4.
L'admin on s'en balance et c'est pas son soucis. On livre des briques spécifiées, packagées et compartimentées. Le problème de qui a contribué cette ligne ou ce fichier dans chaque brique ce n'est pas son problème et il ne peut et veut de toute facon pas le gérer. L'admin à papa, ca n'existe plus car ca ne scale pas et ca n'a pas de valeur ajouté bien au contraire. On livre des paquets intégrés aux systèmes cibles dans des repos spéciaux qui répondent aux specs, avec des processus de mise en prod/rollback automatique. L'admin traditionel ne peut pas suivre le dev de 200 briques, avec des dizaines/centaines/milliers de gars qui bossent. Il ne comprend même pas les besoins fonctionnels des briques. Par contre on intégre les admin dans les équipes de dev par ce qu'ils ont pleins de choses intéressantes à dire sur les contraintes opérationelles ou sécu. Ca permet de les prendres en compte dès la conception et pas une fois que ca plante et ca leur permet de gauler l'infra pour les besoins de leurs utilisateurs.
Si je prends ton exemple, il y a fort longtemps j'ai contribué quelques chapitres aux deux handbooks de FreeBSD. J'ai donc créé les fichiers avec mes petites mains, créé des patchs, puis envoyé des patchs sur le BTS, puis quelqu'un a poussé les patchs sur de CVS, puis quelqu'un d'autre à merger les commits dans les différentes branches, qui se sont finallement automatiquement retrouvés publiés sur le www de FreeBSD.org.
Donc tu penses qu'il y a un problème de sécu avec ce processus ? Je suis le stagiaire là ! Où faudrait-il mettre des ACLs ? L'admin de FreeBSD.org ne sait même pas que j'existe. D'ailleurs pourquoi il le devrait. Ce qui l'intêresse lui c'est qu'un handbook produise des fichiers html non modifiable/exécutable dans un répertoire précis du wwww/ et rien en dehors. Et c'est comme ca qu'on assure la sécurité. Que j'ai modifié le chapitre 2 c'est pas son soucis. C'est le soucis des commiters doc qui s'assurent de la qualité/sécurité de leur produit (j'aurais très bien pu mettre un lien pishing ou effacer un paragraphe ACL ou non).
Si on va part là, les ACL c'est la même chose. Le mec qui efface des ressources par erreur alors qu'il a le droit bha voilà… Ce n'est pas la bonne réponse.
Les politiques de sécurité doivent s'appliquer aux briques pas aux personnes. Pas de raison de plus compartimenter telle ou telle personne à l'exécution, ce n'est pas ca l'unité logique. Chaque brique est responsable de ce qui se passe chez elle. L'infra la compartimente, l'empêche de faire ce quelle ne doit pas faire, et assure l'isolation entre les briques. Les personnes n'ont rien a voir là dedans. Après chaque brique prend la resonsabilité de sa qualité et s'occupe de la question des personnes.
Si tu bosses comme ca tu es resté dans les années 80 ou il y a un énorme problème d'organisation. Je t'invite à regarder les processus de release engineering modernes.
En l'occurence ici tu as une brique fonctionnelle qui doit être isolée des autres sur lequel travail un stagiaire (mais ca pourrait être n'importe qui…). Cette brique va livrer des artifacts bien définis qui seront déployés à un endroit et un contexte sécu précis. Ta sécurité vient de là. Que la brique fasse de la merde fonctionnellement on s'en balance. De toute facon le taff du mec c'est de la modifier et l'admin ni comprend rien. Par contre elle ne peut pas impacter le reste, elle ne peut pas sortir. Et l'équipe qui s'occupe de la brique à plutôt intêret à se surveiller. C'est comme ca qu'on assure à la fois la sécurité du système, la qualité fonctionnelle et qu'on arrête d'avoir des équipes d'admin qui coûtent le même prix que les équipes de devs sans aucune plus value. Il vaut mieux les occuper à faire des choses utiles et contribué à la qualité du système en amont non ?
[^] # Re: Tout va bien, je t'assure
Posté par Kaane . Évalué à 4.
Tout d'abord un grand merci de m'expliquer ce qu'est un VCS quand j'explique depuis maintenant 5 posts que la question posées n'a rien à voir avec les VCS.
Je sais ce qu'est un VCS, comment on s'en sert, je les utilises quotidiennement (et plutôt deux fois qu'une vu que le backup des systèmes est aussi un VCS sur mes machines), je fais du centralisé aussi bien que du distribué etc.
Donc tu as fait des handbook pour le FreeBSD ? Très bien. Estc-e que les modifications que tu as faites se sont retrouvées automatiquement en ligne ?
Non hein ?
Ben voilà.
Maintenant on se moque que ce soit l'admin FreeBSD himself en personne, ou une personne qui qu'elle soit qui a les droits d'administration d'un projet (Hint : il n'est pas forcément root sur tout le domaine) qui ait fait le taf. La sécurité dans les projets FreeBSD vient de la validation humaine. Rien ne se fait sans validation humaine si le mec qui soumet des modifs n'a pas les droits de commiter (i.e : il est probablement pas "stagiaire").
Après comme tu le dis très bien quand il y a 200 briques projets, des centaines de milliers de lignes de codes sur des sujets aussi variés que les I/O bas niveau et les CSS level3 compatibles IOS, c'est rarissime d'avoir assez d'admins (i.e chef de projets/commiteurs/responsables etc. par forcément des mecs root) pour faire une validation manuelle et fiable de tout ce qui passe. C'est ce que je soulignais en disant "L'admin va probablement trouver la blague saumâtre".
Et les VCS n'aident absolument pas à résoudre les problèmes de sécurité qui se posent.
Si on va part là, les ACL c'est la même chose. Le mec qui efface des ressources par erreur alors qu'il a le droit bha voilà… Ce n'est pas la bonne réponse.
Avec les ACL le mecs ne peut effacer que les fichiers sur lesquels il a les droits. Donc le mec peut lire le code HTML, mais n'avoir le droit que de modifier certains fichiers CSS. Alors que les fichiers sont lisibles aussi bien par le proxy nginx que par apache et qu'un autre stagiaire ne peut modifier que les fichiers images.
Sans ACL (et sans MLS/MAC ) forcément, il faudra mettre des droits inutiles à un des uid qui écrivent ou lisent sur le disque. Peut importe que ce soit l'uid du VCS, d'apache ou de nginx. Les fichiers ont un propriétaire et un groupe - avec à chaque fois un seul set de droits. Forcément tu augmentes la surface d'attaque en conservant les droits Unix plutôt qu'en mettant des ACL bien foutu. Et peut importe que ce soit le stagiaire, le VCS, Apache, ou nginx qui ait trop de droits (ie accès à des fichiers auquel il ne devrait pas avoir accès) ca pose un problème de sécurité qui est ultra-simple à résoudre.
Cette brique va livrer des artifacts bien définis qui seront déployés à un endroit et un contexte sécu précis.
Non. Elle va livrer des artefacts dans une section artificiellement restreinte d'un contexte beaucoup trop large - et on reporte sur le processus de déploiement la charge de limiter, via du code userspace, la zone d'impact de ce déploiement.
La surface d'attaque est l'ensemble de tous les répertoires que l'utilisateur (au sens uid) VCS peut lire ou écrire. Sans ACL cette surface est disproportionnée par rapport au besoin.
[^] # Re: Tout va bien, je t'assure
Posté par ckyl . Évalué à 1.
Ca doit bien scaler et être très productif de gérer les utilisateurs, au sens employé, qui font les modifications au niveau de la prod !
Tu te focalises sur la gestion des personnes alors que ce qui est important c'est la gestion des briques et de leurs interactions. Tu veux empêcher un mec particulier de modifier une brique où un boût de brique ? C'est pas à la prod de le faire. Par contre la prod elle peut décider d'isoler deux briques.
Bidouiller pour empêcher un stagiaire de modifier un fichier sur la prod, ca sent très mauvais pour l'orga. Comme tu le dis toi même, la fiabilité et la sécurité passe par une gestion/validation humaine de ce qui est livré. Processus en deux étapes. Conception du produit puis déploiement.
Donc tes ACL ne sont pas par utilisateur comme tu t'obstines à l'expliquer avec l'exemple du mauvais stagiaire qui pourrait suprimer un png alors qu'il doit faire que du css. Alors que ce n'est pas du tout pour ca qu'on s'en sert. C'est bien pour séparer les briques. On peut utiliser les ACLs mais tu peux aussi avoir deux UID différentes avec des instances différentes et reverse-proxifier, balancer ca dans des VM, où un milliard d'approches différentes en fonction des briques et technos (par ce que les ACL sur www on arrive vite aux limites de l'exemple).
Personne ne dit que les ACL ne servent à rien, bien au contraire. Mais la justification utilisées me laisse très perplexe. Vérouiller qui fait quelle modification sur la prod avec une granularité fichier/rep ca sent pas bon du tout. L'info du mec qui a fait le changement devrait être perdu depuis longtemps entre le VCS, le packaging et le déploiement et ce n'est pas là qu'il faut s'en soucier. D'ailleurs ton stagiaire il a un UID spécifique sur la prod ? Sinon pourquoi dire que c'est un stagiaire et pourquoi insister sur la relation avec les ACL alors que ce n'est pas la solution à ce problème ?
[^] # Re: Tout va bien, je t'assure
Posté par Kaane . Évalué à 2.
Tu te focalises sur la gestion des personnes alors que ce qui est important c'est la gestion des briques et de leurs interactions.
Bon apparemment je ne dois pas parler en français. Je vais donc être clair, au risque de paraitre un peu vulgaire :
Dans le cadre de cette discussion, qui porte sur la sécurite je me FOUS COMPLETEMENT de l'aspect gestion de projet.
Voilà. Est-ce clair ? Je sais très bien gérer un projet merci.
Mais même si les VCS c'est bien, même si ca permet de faire pleins de choses, même si ca apporte énormément en terme d'organisation etc. Ca n'apporte rien au niveau sécurité.
C'est comme les duplications et les sauvegardes - ca n'a rien à voir. Ca ne veut pas dire que les duplications soient meilleures que les sauvegardes, ou que les sauvegardes sont au dessus des duplications - ca n'a juste **AUCUN RAPPORT*
Ben les VCS et la sécurité c'est pareil. Les ACL apportent de la sécurité, les VCS non. Ce qui ne veut absolument pas dire que l'on peut remplacer les VCS par des ACL. Ce sont deux choses distinctes.
Mais la justification utilisées me laisse très perplexe. Vérouiller qui fait quelle modification sur la prod avec une granularité fichier/rep ca sent pas bon du tout. L'info du mec qui a fait le changement devrait être perdu depuis longtemps entre le VCS, le packaging et le déploiement et ce n'est pas là qu'il faut s'en soucier.
Je te rassure, je ne fais absolument pas comme ça. Je vérouille au niveau fichier/repertoire par mission. Chaque mission correspond à un groupe au sens Unix, et chaque groupe a ses propres ACL. Et mon VCS/packageur/script Node et j'en passe n'appartienent à aucune mission et n'ont aucun droit pour faire la moindre modif sur le système. Ils assument les droits utilisateurs qui sont donnés par la mission de l'utilisateur.
En espérant avoir été clair ce coup ci.
[^] # Re: Tout va bien, je t'assure
Posté par Alex . Évalué à 1.
dans les 2 cas le stagiaire exécute du code sous www-data
du coup je ne vois pas trop la différence entre utilisé une acl, ou faire ça proprement
[^] # Re: Tout va bien, je t'assure
Posté par groumly . Évalué à 0.
Encore mieux: t'utilise chef pour faire un git pull. Ton jenkins lui se contente de tagger le repo une fois que tes tests sont tous verts.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
# Est ce que la solution...
Posté par flagos . Évalué à 9.
Ne serait pas de tirer tout le monde vers le haut plutôt que vers le bas ?
A quand les cgroups dans *BSD ?
[^] # Re: Est ce que la solution...
Posté par Jean Gabes (site web personnel) . Évalué à 2.
Tout à fait. Demander à ce que tous les noyaux soient au même niveau quand on souhaite améliorer les souches supérieures reviendrait à ne pas avancer. Linux et les BSD n'avancent pas sur les mêmes sujets en effet, mais est-ce un mal? De plus personne n'a le droit de demander à un autre d’arrêter d'avancer sur un sujet car son "camp" ne suit pas le rythme. Par contre ça doit motiver à suivre, voir innover ;)
[^] # Re: Est ce que la solution...
Posté par Anonyme . Évalué à 3.
Quelqu’un a demandé à un autre d’arrêter de faire quoi que ce soit ?
[^] # Re: Est ce que la solution...
Posté par Renault (site web personnel) . Évalué à 10.
Bah quand les gens demandent qu'un outil n'exploite pas des fonctionnalités spécifiques au noyau Linux pour être compatible avec les autres UNIX, oui c'est une demande déguisée mais similaire.
Dans les couches basses il faut exploiter les fonctionnalités du noyau (si possible de manière optionnelle, activable à la compilation)…
Surtout pour un init la compatibilité on s'en fout, c'est un truc qui doit être très proche du noyau et qui n'a jamais été compatible entre différents UNIX de toute façon…
[^] # Re: Est ce que la solution...
Posté par Anonyme . Évalué à 0.
Tout ça ok mais qui a demandé à ce que ça soit portable ?
[^] # Re: Est ce que la solution...
Posté par navaati . Évalué à 4.
Un paquet de trolls ont comme argument contre systemd que "Ah mais ça pue c'est pas portable".
[^] # Re: Est ce que la solution...
Posté par Anonyme . Évalué à 2.
Ils comptent ceux-là ? Beuh…
[^] # Re: Est ce que la solution...
Posté par Jean Gabes (site web personnel) . Évalué à 3.
Malheureusement ce sont ceux qui font le plus de bruits en effet. Je ne doute pas qu'il y ai aussi une armée de bonne volontés qui travaille à faire encore mieux que les cgroups pour les BSD, mais par définition ils travaillent, donc on ne les entends pas c'est dommage.
[^] # Re: Est ce que la solution...
Posté par Emmanuel Seyman . Évalué à 1.
Soyons honnête, s'entendre dire "tes applications préférés vont arrêter de tourner sur ton système d'exploitation préféré", ça n'incite pas à faire des critiques constructives.
[^] # Applications qui ne fonctionnent qu'avec sytemd ?
Posté par Sylvain Blandel . Évalué à 5.
Quelles sont ces applications qui, actuellement, ne nécessitent pas systemd, et qui, dans leurs versions futures, exigeront systemd ?
(ce n'est pas de l'ironie, les réponses m'intéressent sincèrement)
[^] # Re: Applications qui ne fonctionnent qu'avec sytemd ?
Posté par Emmanuel Seyman . Évalué à 5.
Les discussions de l'époque portaient sur Gnome et on redoutait que d'autres applications suivent le même chemin.
[^] # Re: Est ce que la solution...
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 6.
Pourquoi faire ?
FreeBSD (par exemple) a déjà RCTL.
[^] # Re: Est ce que la solution...
Posté par Misc (site web personnel) . Évalué à 3.
C'est cool, mais c'est non portable, ni openbsd, ni netbsd n'a ça.
Et ça me semble, d'après la page de man, que ça ne gère ni les I/Os, ni le réseau.
De plus, je ne voit pas comment rctl permet de bloquer et tuer tout un groupe de processus. Les jails le font, mais le souci est qu'un jail isole totalement les processus, alors que les cgroups peuvent faire juste du regroupement sans rien d'autre. Et un jail, sauf erreur de ma part, requiert un os complet à part.
Donc bien que ça remplisse fonctionnellement certains besoins des cgroups ( et plus, vu que rctl va plus finement sur les réglages ), ça ne remplace pas les cgroups. ( Le but de suivre et tuer les processus étant pour éviter les races conditions, les cas pénibles, etc, j'ai assez donné d'exemple dans les dernières discussions sur systemd, genre sur bind )
[^] # Re: Est ce que la solution...
Posté par barmic . Évalué à 2.
Je ne sais pas ce que tu entend par « bloquer », mais les cgroups non plus ne permettent pas de tuer tous les processus d'un groupe.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Est ce que la solution...
Posté par Joris Dedieu (site web personnel) . Évalué à 3.
En fait de ce que j'ai compris systemd utilise principalement les cgroups pour identifier les fils rebelles des processus qu'il lance.
Quelque chose comme : reste-t-il des processus attachés à ce cgroup ? Si oui alors je les déquille.
[^] # Re: Est ce que la solution...
Posté par Misc (site web personnel) . Évalué à 3.
Le cgroups freezer :
https://www.kernel.org/doc/Documentation/cgroups/freezer-subsystem.txt
non, c'est pas un perso de dbz :)
[^] # Re: Est ce que la solution...
Posté par Joris Dedieu (site web personnel) . Évalué à 10.
Non. Tu peux très bien par exemple jailer un process dans /var/empty ou dans /. jail() est un appel système qui crée un contexte noyau particulier. Celui-ci n'est pas forcement restrictif. Tu peux très bien le créer dans /, autoriser les ipc … Ensuite tu attaches ton processus dans le jail avec jail_attach() qui positionne le numéro de contexte dans la la structure ucred du processus (hérité sans retour possible par tous ses fils).
Donc si le but est uniquement d'être sûr de pouvoir massacrer tous ses fils à l’arrêt d'un daemon, alors des jails dans / font clairement le job.
Tu peux même faire plusieurs niveau hiérarchiques ce qui permet par exemple de tuer tous les fils sans tuer le process master lors d'un reload.
[^] # Re: Est ce que la solution...
Posté par Miod in the middle . Évalué à 8.
À quand une spécification définitive des cgroups ?
[^] # Re: Est ce que la solution...
Posté par patrick_g (site web personnel) . Évalué à 9.
Salut Miod.
AMHA si tu explores de nouvelles possibilités et que tu tentes d'aller au delà de POSIX, alors une certaine période d'expérimentation est inévitable avant que les choses ne se stabilisent. C'est ce que font les devs Linux.
Je trouve ce paragraphe de Jon Corbet (issu de cet article) particulièrement intéressant :
Donc ta question est pertinente. Les cgroups ne sont pas encore spécifiés avec la perfection formelle d'une norme. Mais ta question reflète aussi le fait que Linux est le pionnier et que les BSDs sont, au moins sur ce sujet, les suiveurs. Pourquoi attendre que le travail soit terminé côté Linux pour ensuite décider d'adopter, ou pas, cette nouvelle techno ? Je trouve assez paradoxal de reprocher aux cgroups de ne pas avoir de specs définitives pour l'instant et en même temps de ne pas chercher à aller au delà de POSIX. Si tout le monde participe, discute, expérimente et implémente on arrivera à un truc stable bien plus rapidement.
[^] # Re: Est ce que la solution...
Posté par Miod in the middle . Évalué à 1.
En ce qui concerne les cgroups, remplace Linux par google.
Non. Ma question reflète le fait que l'écosystème Linux explore beaucoup de directions différentes, pour le meilleur comme pour le pire. Je n'ai rien a priori contre les cgroups, mais je n'ai rien pour : leur intérêt pratique reste à démontrer, et lorsqu'il le sera, alors il faudra que l'interface soit raisonnablement figée. En attendant qu'elle le soit, j'ai mieux à faire de mon temps que de coder une interface vouée à être fortement remaniée. C'est le côté Darwiniste du libre : si une API survit et s'avère utilisée, elle mérite que l'on s'y intéresse. Si elle crève dans son coin, on aura bien fait de ne pas s'y intéresser.
[^] # Re: Est ce que la solution...
Posté par patrick_g (site web personnel) . Évalué à 6.
Google utilise intensivement les cgroups mais ce ne sont pas les devs payés par Googe qui pilotent le développement. Le fichier MAINTAINERS liste Tejun Heo (qui bosse pour Novell) et Li Zefan (qui bosse pour Huawei) comme mainteneurs officiels.
Soit. C'est une réponse parfaitement sensée…mais cela signifie également que tu ne peux pas intervenir lors de la phase de construction pour orienter le développement. C'est un choix.
[^] # Re: Est ce que la solution...
Posté par Sylvain Blandel . Évalué à 2.
Et si elle survit parce que tu as utilisé cette API pour créer des technologies innovantes, pertinentes et efficaces ? Bin non, vu que tu n'auras rien fait, « l'interface n'était pas raisonnablement figée, alors j'attendais ». Tu laisses les autres décider quelles seront les technologies dominantes de demain.
La version 7 de Red Hat Enterprise Linux utilisera systemd, et systemd dépend des cgroups. Sachant que la maintenance de Red Hat Enterprise Linux peut s'étendre jusqu'à 13 ans, l'existence des cgroups me semble garantie pour quelques années
# Et launchd ?
Posté par flan (site web personnel) . Évalué à 2.
Je sais, c'est vraiment une question bête, mais est-ce que les *BSD pourraient passer à launchd ?
[^] # Re: Et launchd ?
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 3.
Y en a qui ont essayé : launchd.
Mais je n’ai pas l’impression que ça motive beaucoup les foules…
# Si je comprends bien
Posté par Sam E. (site web personnel) . Évalué à 10.
J'ai l'impression que les seuls à se plaindre du fait que Systemd ne soit pas compatible BSD sont des linuxiens traumatisés par le petit Poettering.
On a demandé à la communauté BSD si elle en avait quelque chose à faire ? Parce qu'il me semble qu'ils ont des systèmes d'init qui leur conviennent bien et ils n'ont pas l'air d'envier plus que ça journald ou systemctl.
[^] # Re: Si je comprends bien
Posté par Maclag . Évalué à 5.
Moi ce que j'avais compris c'est que c'est pas systemd qui inquiète, mais son utilisation progressive par des applis largement utilisées sous BSD.
Exemple: Gnome qui utiliserait de plus en plus systemd jusqu'à le rendre obligatoire.
[^] # Re: Si je comprends bien
Posté par claudex . Évalué à 8.
Tu as des sources ? Parce que Gnome tournent sous Ubuntu qui utilise Upstart. Gnome utilise certaines API de systemd mais ce sont des API qui peuvent être implémenter par n'importe quel système d'init, et Canonical les porte sur Upstart.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Si je comprends bien
Posté par Sylvain Blandel . Évalué à 2.
Il semble que tu as raison. Sur le wiki de Gnome, il est écrit :
Et à la section « Recommended components », il est écrit :
Systemd est mentionné, mais pas Upstart. J'en déduis que « Gnome upstream » fonctionne naturellement avec systemd, mais pas avec Upstart. Ainsi, les distributions utilisant Upstart (comme Ubuntu) doivent fournir un travail supplémentaire pour utiliser Gnome.
[^] # Re: Si je comprends bien
Posté par claudex . Évalué à 2.
Tu déduis mal, ça veut dire que les développeurs Gnome se basent sur ces technologies, et, notamment, ne garantissent pas que ça fonctionne parfaitement si on ne les utilisent pas. Par contre, les distributions utilisant Upstart ne doivent pas faire de travail supplémentaire pour que Gnome marche, ce sont les développeurs Upstart qui doivent réimplémenter les API de systemd pour que Gnome marche. Ainsi, une distribution qui utiliserait maintenant Upstart et Gnome n'aurait rien besoin de faire (sous réserve que Canonical ait poussé dans Upstart upstream ses patch et que la distribution soit compatible avec ces patchs (mais c'est valable avec systemd aussi)).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Si je comprends bien
Posté par Maclag . Évalué à 4. Dernière modification le 07 septembre 2013 à 21:23.
Euh, tu me dis que pour les BSD c'est bon parce que les dévs d'Upstart implémentent l'API de systemd au fur-et-à-mesure que Gnome y a recourt?
Les dévs de Gnome ont déjà annoncé la couleur: noyau Linux, systemd.
Qui ne peut pas suivre… ben tant pis!
[^] # Re: Si je comprends bien
Posté par claudex . Évalué à 8.
Non, je dis que systemd n'est pas obligatoire, c'est tout.
Les API utilisé, c'est par exemple, un démon pour changer le nom d'hôte dans la configuration du système. Après, certaines sont spécifiques à systemd mais c'était déjà le cas avant où c'était spécifique à une distribution parce le type qui avait coder le changement de nom d'hôte (par exemple) ne l'avait que pour une poignée de distribution.
À partir du moment où ils utilisent une API spécifique à systemd parce qu'il n'en existe pas de portable (et les API portable Linux/BSD, ça ne court pas les rues), je ne vois pas ce qu'on peut leur reprocher à moins de leur demander d'écrire une couche d'abstraction Linux/BSD mais c'est un autre boulot.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# Remplacer cron par systemd
Posté par Sylvain Blandel . Évalué à 5.
Sur ma bécane, je suis parvenu à remplacer cron par systemd. J'en ai fait un tutoriel : Remplacer cron par systemd
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.