Bonjour à tous : pour ceux que ça intéresse, j'ai mis à disposition un installer automatique apache, php, mysql pour Debian 8. C'est du shell,facile à personnaliser.
Il est fondé sur des bases très simples qui lui permettent de s'installer un peu n'importe où, il est en constante évolution et bien entendu gratuit. N'hésitez pas à m'envoyer vos feedbacks, bugs rencontrés, etc. !
Pour avoir la liste des features en cours et le tester : https://www.bit.ly/brainpali
amicalement,
Le 07/12/2016 à 19:39, Christophe Casalegno (DN) a écrit :
Hello,
Pour ce genre de chose désormais j'utilise des outils qui permettent de faire ce genre de chose à grande échelle... au taff, j'utilise "ansible" Il y a même un repo (Ansible Galaxy) avec plein de gens qui écrivent des rôles dont on peut s'inspirer...
Néanmoins quelques remarques, au passage à propos de ton script : - Ton script fonctionne-t-il quelque soit la LANG positionnée ? - Pourquoi modifier ds ta conf ssh à PermitRootLogin à yes ? J'espère que ton mot de passe est béton et que ton serveur n'est pas sur internet... - Pourquoi utiliser ntpdate ds un cron pour ta mise à l'heure ? Utilise plutôt ntpdate au démarrage + le démon ntpd, c'est mieux - pure-ftpd sur un serveur ? C'est pas tip-top sur un serveur surtout depuis que l'on peut chrooter sftp (mais au taff je me bas aussi contre ça) - attention si tu rebootes ton serveur, les produits ne démarreront pas automatiquement... il faut probablement que tu ajoutes des update-rc.d à ton script (ou des systemctl enable xxx) - pourquoi forcer la sortie d'exécution de ton script à 0 ? D'ailleurs tu ne trappes pas bcp les codes retours de tes commandes...
JYL
Hello, pas les mêmes objectifs, pour ça on utilise puppet, aucun intérêt pour un quidam qui veut déployer son vps chez ovh ou online.
D'après l'absence de retour que j'ai malgré de nombreuses exécution aux usa, je dirais "sans doute", je vais cependant vérifier ce point. Cependant, tout l'intérêt d'un script est justement de l'adapter à ses propres besoins... ou envies
Le mot de passe est généré automatiquement par le script, tu peux toujours essayer de le bruteforcer par internet : il va te falloir longtemps (quelques siècles), beaucoup d'ips (à cause de Fail2ban entre autre), et que la personne n'est pas changé le port par défaut (ce que permet le script en standard via ex : -s 44232 installera ssh sur ce port).
Ce n'est donc clairement pas la même fréquence de test qu'avec un John the reaper entre de s'amuser avec une Geforce 1080 via openCL
J'administre plusieurs milliers de serveurs bastions sur internet avec un ssh (et précedemment telnet) ouvert en mode password sans incident sécurité lié au pass. Il faut juste respecter quelques règles comme http://www.christophe-casalegno.fr/2007/01/30/petit-point-sur-les-strategies... mais il y en a d'autres.
En parlant de sécurité, disons que le démon ntpd a eu sa phase d'utilisation pour faire du ddos udp, même s'il est toujours possible de positionner des filtres adéquats, l'objectif est de rester simple.
Le protocole ftp reste le plus utilisé pour publier un site aujourd'hui, rien en effet ne t'empêche d'utiliser sftp (faut bidouiller un minimum pour le chrooter correctement et surtout qu'il ne puisse pas servir à créer des tunnels ssh), ou ftps (il est supporté par pure-ftpd d'ailleurs).
J'ai fais le choix de pure-ftpd car c'est un soft qu'on a eu à auditer en pentest plusieurs fois, je trouve sa conception robuste (comme pour vsftpd) et dans ma "philo".
Quels produits ?
Les tests, ça vient(dra) après, bien bien après, même si j'en ai mis 2 ou 3 de base. L'objectif est seulement de permettre à un quidam de prendre un serveur chez l'hébergeur de son choix, même si ce n'est pas chez moi, et avoir une stack lamp relativement propre sans rien connaître. Si tu sais déjà installer ton stack, tu as probablement déjà tes scripts
amicalement,
-- Christophe Casalegno http://www.christophe-casalegno.com
Bonsoir,
On 07/12/2016 20:34, Christophe Casalegno (DN) wrote:
ntpdate en cron, c'est quand même un peu violent. Certains daemons n'apprécient pas du tout les sautes de temps : Dovecot par exemple, qui se suicide :) quand il voit qu'il y a soudainement une trop grosse différence de temps en cours de fonctionnement (essaie, le log avant le kill est assez amusant).
Fabien
Voilà pourquoi j'utilise encore courrier :-D. D'ailleurs tu viens de me donner une idée sur une nouvelle approche pentest pour le coup. Il fait quoi, il ne coupe que la connexion en cours, ou il segfaulte carrément ?
Pour le temps, avant je jouais avec clockspeed, avec une satisfaction mitigée. Je trouve qu'un ntpdate récurrent pour du lamp, ça fait le taf, d'autant plus que les corrections sont pour le coup, ultra minimes.
amicalement,
On 07/12/2016 21:34, Christophe Casalegno (DN) wrote:
Il s'arrête complètement : http://dovecot.dovecot.narkive.com/ud92gPCI/time-just-moved-backwards
Fabien
Bon pour le coup, on va voir si ça passionne : https://twitter.com/Brain0verride/status/806598323830456320
une install ntpd est de toute manière plus rapide que taper dans la cron, ça c'est sur :)
amicalement,
Le 08/12/2016 à 07:16, Guillaume Tournat a écrit :
Mais ça va mieux depuis que j'ai trouvé un howto pour remettre sysvinit sur debian8 ;-)
'tégriste !
Fais-voir ce HOWTO ?
J.
Bonjour chez toi.
Bonjour
Le 08/12/2016 17:52, Jacques Lav!gnotte. a écrit :
C'est dans la doc officielle ;-) https://www.debian.org/releases/jessie/amd64/release-notes/ch-information.en... https://wiki.debian.org/fr/systemd#Installation_sans_systemd
Salut,
Loin de moi de vouloir relancer un troll qui devient vieux comme le monde à ce stade, mais que reproche-tu concrètement à sytemd? C'est le point de vue de l'admin qui fait de la prod qui m’intéresse (je ne sais pas si tu es dans ce cas).
En ce qui me concerne, et étant sysadmin, je trouve que ça a apporté un grand confort, surtout quand on utilise des outils du type Ansible/Puppet sur différentes plateforme. Une interface pour tous les masteriser. J'ai encore du mal à comprendre ce que l'on peut reprocher a systemd.
Note; C'est le point de vue qui m’intéresse, je cherche pas à démontrer que systemd est le meilleur. -- MrJK GPG: https://jeznet.org/jez.asc
Le 8 décembre 2016 à 01:16, Guillaume Tournat guillaume@ironie.org a écrit :
Bonjour,
On va éviter de lancer le troll, même si c'est 'dredi, mais personnellement, même si je trouve que la couche de gestion apportées par systemd est pratique, on se retrouve souvent à démêler des problèmes qu'on avait pas avant, et surtout, souvent plus complexes (ça me rappelle d'ailleurs un peu le passage de LILO à GRUB à l'époque (*)). Bref, notre ami Lennart Poettering a juste oublié que sous Linux, il fallait faire KISS (https://fr.wikipedia.org/wiki/Principe_KISS). Même si du point de vue utilisateur, oui, c'est plus simple...
My 2 cts,
Rémy
(*) plus de capacité, gestion simplifiée, mais du point de vue du cœur du système et de son fonctionnement, c'est en réalité bcp plus complexe.
Le 08/12/2016 à 19:21, Mrjk a écrit :
Pour contribuer au débat, je suis entierement d'accord avec le constat de Remy Dernat. Je rajouterai qu'une partie du probleme a mon sens est l'espece de monstre a mi chemin entre sysvinit et systemd qui a été pondu par Debian/Ubuntu... Ca ne ressemble a rien, c'est encore plus compliqué a gerer... Autant un Archlinux se gere "plus" facilement en pure systemd, alors qu'une débian avec des scripts d'init et du systemd va etre l'enfer entre ce qui est executé quand tu run a la mano ou quand tu reboot ton serveur...
Cordialement
Le 9 décembre 2016 à 09:34, Remy Dernat remy.dernat@univ-montp2.fr a écrit :
Le 09/12/2016 à 09:34, Remy Dernat a écrit :
On va éviter de lancer le troll, même si c'est 'dredi, mais personnellement, même si je trouve que la couche de gestion apportées par systemd est pratique, on se retrouve souvent à démêler des problèmes qu'on avait pas avant, et surtout, souvent plus complexes (ça me rappelle d'ailleurs un peu le passage de LILO à GRUB à l'époque (*)). Bref, notre ami Lennart Poettering a juste oublié que sous Linux, il fallait faire KISS
J'aime systemd, il nécessite un temps d'adaptation comme tous les nouveaux systèmes mais il apporte de la modernité à l'init poussiéreux.
Modifier le démarrage d'un démon avec un fichier .ini, superviser certains services, gérer proprement les groupes de processus c'est un gain appréciable. J'attends Debian 9 et l'intégration de systemd-nspawn plus récent pour vraiment exploiter toutes les fonctionnalités.
J'ai systemd sur quelques centaines de serveurs web sous Debian 8. Les seuls soucis rencontrés viennent d'une mauvaise intégration dans Debian (systemd + vieux scripts init), il est aussi moins tolérants aux erreurs de configuration (programme qui plante, filesystem qui n'exite pas).
Systemd est l'aboutissement de l'évolution de l'init linux. Ça reste un logiciel récent, complexe et en plein développement. On tape sur Lennart mais beaucoup de monde travaille sur systemd depuis que c'est intégré aux distributions linux.
Frédéric.
Le 08/12/2016 19:21, Mrjk a écrit :
Je suis sysadmin, j'utilise ansible et je n'ai encore jamais rien vu que systemd améliorait avec cet outil. J'ai un playbook qui réinstalle sysv au lieu de systemd sur toutes les machines que l'on gère.
Les raisons de mon désamour de systemd sont très nombreuses et je vais la résumer en quelques points : - systemd est incapable de faire démarrer une machine dans toutes les conditions (notamment l'utilisation de FS en réseau / tmpfs / RO) - systemd peut avoir des problèmes pour éteindre certaines machines (je l'ai déjà retrouver à ne pas réussir à démonter des points montés en réseau avec un timeout de... 5 minutes. Par point de montage. 2h de down pour une upgrade de kernel ça fait super mal quand même, ça va que c'était que pour de l'interne) - systemd est peut-être plus modulaire que beaucoup d'anti le disent, dans les faits il l'est beaucoup moins que Lennart Poettring veut bien le faire croire et beaucoup de distribs se retrouvent presques forcées d'intégrer des extensions à systemd qui sont au mieux inutiles, au pire dangereuses (genre systemd-resolvd) - systemd casse des features du kernel (chroot, LXC, terminaux virtuels, ...) et ses développeurs refusent de corriger leur code - systemd rend plus complexe l'écriture de scripts (start / stop / restart / status ne retournent pas d'état, les commandes retournent leur résultats dans un pager par défaut, etc.) - BEAUCOUP de surprises sur des binaires usuels qui changent de comportement (genre halt qui n'éteint plus électriquement une machine)... Même si, j'avoue que c'est juste chiant parce que ça casse les habitudes, en vrai une fois que tu le sais ça va vite a prendre en compte. Et faut vérifier tes scripts au cas où.
Je serais moins virtulent avec systemd, si ce n'était qu'un système d'init. Le problème c'est que ses développeurs veulent le faire grossir en fonctionnalités avant même de savoir faire booter un système Linux correctement. C'est fâcheux, vraiment. C'est avant tout une question de confiance dans le produit fini et en l'état, je suis incapable de prédire que ma prod tournera correctement (ni même démarrera) avec systemd. Accessoirement, je préfère les scripts d'init que je peux facilement débugger alors qu'avec systemd si quelque chose ne démarre pas, je peux me brosser pour avoir les détails qui m'intéressent.
Après, je dis pas que y'a des choses pratiques dans systemd, notamement : - Les scripts d'init faciles à faire - L'utilisation de cgroups pour chaque daemon lancé - La gestion de daemons utilisateurs
Cependant, c'est rien qui n'ait pas déjà été fait ailleurs de façon plus propre. Partant de là, j'ai du mal à comprendre que systemd ait été autant poussé en avant alors qu'il casse plus de choses qu'il n'en corrige tout en retirant aux admins la possibilité de contourner les problèmes.
Note; C'est le point de vue qui m’intéresse, je cherche pas à démontrer que systemd est le meilleur.
Pour le coup, je tiens à dire que j'ai vraiment tenté d'utiliser systemd. Malgré le fait que je le trouvais dégeulasse par design, je me suis quand même dit que ça pouvait pas être si mal que ça si Debian l'intégrait par défaut : - Sur mes postes persos, 4 machines sur 5 ne démarraient plus, la dernière mettait plus de temps à démarrer. - En prod, le playbook ansible est assez récent (4 mois d'après git), il fait suite aux multiples problèmes qu'on a pu rencontrer au fur et à mesure (et quand je dis "multiple", c'est en grande partie parce qu'on a rarement eu le même plusieurs fois, rien qu'écrire de la doc sur ce que cassait systemd à nécessité un boulot de dingue, vraiment). Au début on repassait sous sysv uniquement les machines où systemd nous posait de gros problèmes. Puis on s'est rendu compte que c'était plus de la moitié de nos setups et on a préféré jouer la carte de la sécurité.
Hello
Pour résumer c'etait mieux avant concernant, le système d'init ! Par contre je ne vois pas l’intérêt d'installer automatiquement un Lamp avec un script Bash maintenant que tout peut être fait très proprement avec Ansible / puppet / chef !
Un fidèle utilisateur qui n'a pas du tout aimé systemd et qui utilise openRC tous les jours, et qui n'aime pas du tout pulseaudio ....
Amicalement Alexandre
Le 9 décembre 2016 à 10:50, Benjamin Boudoir benjamin+frsag@boudoir.name a écrit :
Dans le genre système d'init pour server j'eviterai drastiquement système en effet : -openRC pour le tout venant - l'init de busybox pour le compromis efficacité/simplicité - carrément sinit quand on est sur du micro service - voir pas d'init du tout, avec le service final qui est codé pour faire office d'init - voir carrément le service final qui est Codé pour être aussi le bootloader, à la bare_metal sur vm x86 (j'aime les Unikernel, chacun ses vices)
Mais sinon se passer de systemd semble résoudre pas mal de problème.
En revanche pour Barberousse mon précédent je dirait quand même que mettre l'usine a gaz "j'abuse des système convergents" "j'ai découvert l'idempotence et j'en ai fait une drogue" à.k.a chef quand on Parle à cote d'éviter systemd, c'est plutôt rigolo comme namedropping (et inconsistant).
"Chef, y'en à qu'on essayé, ils ont eu des problème." Du moins on connait pas mal de boîte qui jouent beaucoup de transparence sur leur propres erreurs et qui n'ont pas manque de bien expliciter pourquoi aujourd'hui ils se mordent les doigt d'avoir parié sur chef.
Envoyé par TypeApp
Le 9 déc. 2016 11:53, à 11:53, Alexandre Legrix alex@bragonux.net a écrit:
Pour le coup je parlais de machines perso en dehors du cadre professionnel.
Le 9 déc. 2016 12:57, "Colin Brigato" colin@brigato.fr a écrit :
Confirmant donc que nul part ou systemd passe l’adminsys ne trouve ça classe. Clairement, OpenRC + ansible pour du perso et on est bien.
Dans la série "c'est mon choix"...
Systemd me semble plus simple/robuste à utiliser (oui, c'est pas KISS, mais à l'utilisation basique que j'en fait, ça me convient bien). De là à dire que je préfère l'un plus que l'autre, non..
Je suis un "petit" consommateur de linux, non habitué à chef / puppet, etc.. ça doit expliquer ma satisfaction fataliste de ce que je vais trouver sur les distribs.
Voilà,un commentaire qui sert à rien, sinon juste à infirmer "que nul part ou systemd passe l’adminsys ne trouve ça classe". Moi, j'ai laissé systemd (aussi parce que je sais pas le remplacer). Je vois le troll arriver en hurlant que du coup, je dois pas être un vrai sysadmin. ;-)
Olivier.
Et sinon, vous préférez quoi : le rhinocéros ou une petite cuillère ? (astuce : la petite cuillère, elle brille... )
-----Message d'origine----- De : FRsAG [mailto:frsag-bounces@frsag.org] De la part de Colin J. Brigato Envoyé : vendredi 9 décembre 2016 13:09 À : Alexandre Legrix Cc : French SysAdmin Group Objet : Re: [FRsAG] Un installer lamp automatique pour Debian 8
Confirmant donc que nul part ou systemd passe l’adminsys ne trouve ça classe. Clairement, OpenRC + ansible pour du perso et on est bien.
Le 9 décembre 2016 à 13:30, VAILLEAU Olivier Olivier.VAILLEAU@ch-sevrey.fr a écrit :
Dans la série "c'est mon choix"...
Pareil, moi je n'ai rien contre bien Systemd, mais chuuuut :)
Bonjour à tous,
On 12/09/2016 02:03 PM, Jonathan Leroy wrote:
Pareil, moi je n'ai rien contre bien Systemd, mais chuuuut :)
Ben oui, moi c'est pareil. Et, tant que j'y suis, confidence pour confidence, je « surkiffe » carrément Puppet 4.
Voilà, je me sens un peu soulagé maintenant. :p
-- François Lafont
Hello C'est vendredi c'est kdo : http://linuxfr.org/news/systemd-l-init-martyrise-l-init-bafoue-mais-l-init-l... et je ne vous dis pas que j'aime salt mais l'idée de contrôler des minions me fascinent.
/po
vendredi 9 décembre 2016, 12:30:16 CET VAILLEAU Olivier wrote:
Perso, je n'ai pas eu d'embrouille avec systemd qui mériterait de perdre du temps à l'enlever. En fait, je n'ai pas eu d'embrouille du tout… sur mes serveurs. C'est vrai que parfois, mon laptop est long à éteindre, mais comme je le mets en veille généralement et que je ne l'éteint qu'une fois tous les 36 du mois, ça passe.
Et au contraire, systemd m'a simplifié la vie avec les .service simples à écrire, sans oublier les .service génériques, ceux avec @ dans leur nom : ça c'est top, j'écris un modèle de service, et poum, je peux lancer autant d'instances différentes que je veux.
Ce qui m'embête avec systemd, c'est qu'il grossit beaucoup et veut tout faire, même le café (quoi, vous n'avez pas encore vu coffeed ? :P). Ça n'est plus juste un system d'init, et ça me gène un peu.
Le Fri, Dec 09, 2016 at 02:09:35PM +0100, Luc Didry [luc@didry.org] a écrit: [...]
Sur un portable/ordinateur de bureau, à usage "poste de travail" (ou facebook, ou jeux, ou ...), ça a pourquoi pas sa place, l'init Unix classique (et les services que ca lance) ne convient plus forcement aux usages modernes.
C'est ça le vrai probleme de systemd sur des serveurs, c'est que ça a un coté bulldozer, qui remplace les outils de configuration reseau, le collecteur de logs, etc. Systemd arrive avec tout un ecosysteme qui fait qu'on a plus "un Unix" (un peu comme MacosX), avec des fichiers plats editables et lisibles par un humain adminsys, des fichiers logs qu'on peut grep/awk/..., des noms d'interface reseau deterministes, etc.
Le 9 décembre 2016 à 14:59, Dominique Rousseau d.rousseau@nnx.com a écrit :
Mais la plupart de ces fonctionnalités sont désactivables, voire désactivées par défaut. C'est le cas par défaut sous Debian, qui n'utilise que la partie "init" de Systemd.
Aahhaha. Et la gestion des logs, et la gestion des montages et surement d'autres choses :D Regarde aussi ce qui se passe quand tu veux demarrer un service et que systemd ouvre une socket reseau avant meme que le demon soit lancé :D Essaye de faire un swapoff -a et regarde ce qu'il se passe au bout de quelques secondes ou minutes en fonction de ce que va trapper systemd. Malheureusement comme dit plus tot, systemd c'est parti d'un bon sentiment mais si on avait voulu bosser sur macosX on aurait fait ce choix. Dorenavant on a plus vraiment le choix...
Le 9 décembre 2016 à 15:27, Jonathan Leroy jonathan@unsigned.inikup.com a écrit :
On est en 2016, la question ‘est plus du tout de savoir si tu es un vrai sysadmin, mais si tu es un vrai devops mec, le sysadmin, c’est sys-has-been.
Et un vrai devops ca utilise une technologie convergente idempotente qui prefère largement le rhinocéros, ca utilise des buzzword, c’est fataliste que par respect irraisonné pour un type qui est défini comme “plus agile que les autres” (surement un vieux truc de ninja), et en effet y’a rien de tout ça dans ton mail.
Je propose qu’on te rase la tête et qu’on te mette un Tshirt qui mentionne bien ton insalubrité vis à vis de l’année 2016, pire encore vis à vis de 2017 qui s’en vient.
Et tu partira travailler pour la SNCF, pour aller avec ton retard.
Hello,
Le 09/12/2016 à 10:50, Benjamin Boudoir a écrit :
https://www.debian-fr.org/t/pb-demarrage-suite-maj-wheezy-jessie-a-cause-reg... pour une solution
Semble être ça, non ? Effectivement il semble qu'il y ait un pb, mais il y a des pistes de solution https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798314
Est-ce obligatoire ? Des faits, des liens ?
Je ne sais pas quel problème tu rencontres exactement, mais pour le chroot, tu peux faire des chroot assez facilement avec systemd directement : http://0pointer.de/blog/projects/changing-roots.html
Tu dois parler de ça pour LXC ? https://wiki.debian.org/fr/LXC#Incompatibilit.2BAOk-s_avec_systemd
C'est quoi le pb des terminaux virtuels ?
echo $? te donne un return code normalement, non ?
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=753830
Read the sources, Luke ;-) OK elle est facile et c'est clair qu'un script shell c'est plus simple à écrire... mais faire des scripts shells merdiques par rapport à script init de qq lignes, il y a matière à débat
Ah quand même un peu d'objectivité ;-)
Je me demande si tes pbs ne seraient pas plus du au fait que chez Debian, ils ne sont pas partis tous dans la même direction par rapport à systemd, au contraire de RedHat (après le dev principal de systemd bosse chez RH si j'ai bien suivi)... Si je pousse un peu ton raisonnement tu devrais aussi rester sous un kernel 2.4 parce que le kernel 2.6.9 était bien pourri, pour autant désormais j'entends plus bcp de personnes critiquer les versions plus récentes.
Cdlt,
JYL
Le 10/12/2016 23:27, Jean-Yves LENHOF a écrit :
La solution la plus simple est quand même d'utiliser un init qui sait démarrer :-) Une fois que ton desktop démarre plus, t'as plus tellement accès à ce genre de ressources.
Effectivement, c'est un des bugs rencontré.
Je t'avoue que j'ai pas tellement envie de lire ça, donc j'ai juste cherché ce que je voulais : systemd-nspawn c'est le trashfix de systemd parce qu'ils ont cassé chroot. J'ai plus les détails de ce qui était
Tu dois parler de ça pour LXC ? https://wiki.debian.org/fr/LXC#Incompatibilit.2BAOk-s_avec_systemd
Tiens, oui, y'a aussi. Non, je parle du fait que si tu as dbus dans un conteneur LXC sur un hôte avec systemd, tu peux balancer des commandes à ton PID 1 depuis ton conteneur. J'ai eu plusieurs conteur qui ont éteint électriquement leur hôte parce qu'un shutdown avait été fait dessus :-)
C'est quoi le pb des terminaux virtuels ?
https://bugzilla.redhat.com/show_bug.cgi?id=817186
Oui, toujours 0. Bon, là j'avoue que j'ai appris plus tard que ça dépend du type de service (mais j'ai pas retrouvé mon lien). En tout cas, sous Debian j'ai eu plusieurs scripts qui cassaient après une utilisation de type "service service reload && faituntruc" parce que le service n'avait pas reload / restart / stop / start.
Exemple : http://serverfault.com/questions/751030/systemd-ignores-return-code-while-st...
L'avis qu'on a de si oui ou non c'est un comportement intelligent ou pas ne doit pas entrer en ligne de compte. A partir du moment ou des tas de softs reposent dessus, tu peux pas juste changer silencieusement le comportement d'un binaire. C'est quoi déjà un des arguments des pro-systemd ? Ah oui, c'est une API unique pour toutes les distribs.... Mouais.
Surtout que bon, c'est pas comme si systemd trashait pas ses API régulièrement (genre systemd-sysv ou systemd-fstab). D'ailleurs, une unit de type mount c'est pas beaucoup plus chiant à écrire qu'une ligne de fstab, sérieusement ?
Je suis d'avis que l'init devrait être indépendant de l'API pour les couches hautes.
Bah "read the sources" dans un script d'init en shell c'est vachement plus simple que dans un ensemble de binaires bloatés que tu peux pas toujours mettre à jour ;-)
C'est rigolo parce que plus tôt :
Rien à voir. Entre une upgrade et un changement complet d'un système pour un nouveau qui n'améliore pas l'existant. Aussi, la branche 2.4 a continuée d'être maintenue un bon moment alors que systemd ne maintient que sa master et ne supporte pas les vieux kernels... D'ailleurs, ils vont faire comment RHEL / CentOS alors qu'ils sont sensés supporter leurs distibs pendant 10+ ans ? ( https://access.redhat.com/support/policy/updates/errata/ )
pour autant désormais j'entends plus bcp de personnes critiquer les versions plus récentes.
Normal, on est retourné utiliser des inits capables de faire démarrer nos machines et les éteindre sans bugs ;-)
Le 08/12/2016 à 19:21, Mrjk a écrit :
leur manie de tout recoder dans systemd, jusqu'au resolver dns, au client dhcp, ... les logs en binaire, illisible directement, sans les commandes idoines c'est développé par gnome je trouve que ça opacifie le boot, à faire trop de trucs et quand ça bug, du coup, ça fait des trucs moches.
et puis, j'ai du prendre mes petites habitudes aussi :-)
Le Wed, Dec 07, 2016 at 08:56:34PM +0100, Fabien Germain [fabien@klipz.fr] a écrit:
Ce que dovecot n'aime pas et le pousse a se suicider, c'est lorsqu'il remonte le temps. Et c'est meme dans leur wiki : http://wiki.dovecot.org/TimeMovedBackwards
-
Alexandre Legrix -
Benjamin Boudoir -
Bruno Pagani -
Christophe Casalegno (DN) -
Colin Brigato -
Colin J. Brigato
-
Dominique Rousseau -
Fabien Germain -
Francois Lafont -
frsag＠jack.fr.eu.org -
Frédéric VANNIÈRE -
Guillaume Tournat -
Jacques Lav!gnotte. -
Jean-Yves LENHOF -
Jonathan Leroy -
Luc Didry -
Mrjk -
Pierre-Olivier Grangaud -
Remy Dernat -
Sébastien FOUTREL -
VAILLEAU Olivier