Je suis parfaitement honnête, tu peux donc mourir si tu veux.
Je me répète j'aime mettre en place des solutions maitrisées et huilées sur la durée.
J'avais investi beaucoup de temps à l'époque sur OpenVz chez moi à bien tout paramétrer mes services. Etre capable de remonter en disaster recovery from ISO + mes services, me prenait 10 minutes montre en main, opération fièrement testées et retestée. C'est le genre de chose ou une fois installé j'ai pas envie d'y revenir tout les 2 ans pour réfléchir à mon infra. Du coup bêtement je me dis que je vais pouvoir "capitaliser" longtemps sur cette techno ...
J'ai autre chose à faire que de passer mes hivers à geeker mon serveur pour mettre en place un backup, c'est long et chronophage.
Je veux juste venir sur le systeme faire apt-get update / upgrade de temps en temps et le faire vivre le système comme ça pendant des années.
Bref ça c'est de la production, 0 coupure, 0 problème, environnement maitrisé.
On est pas en mode bidouille je me fais plaisir je patch le dernier kernel parce que j'ai lu la dernière dépêche de patrick_g.
Debian 7.x -> apt-get install linux-image-openvz-amd64 et fin de chantier : c'est ça que j'appelle sans bidouilles et "natif" avec installation fluide.
Debian 8.0 -> Alors bon on va commencer par downgrader le Noyo, faut mettre un kernel patché RH sous Debian voilà ça commence bien et ça rassure pour l'avenir ... Ca j'appelle ça de la bidouille du truc pour les bricoleurs sûrement pas un truc sérieux.
Puis ça tombe bien parce que pour redémarrer les services c'est plus du tout pareil non plus, impeccable.
Rien à faire de savoir si pourquoi et comment si c'est upstream ou pas, en l'état qu'on m'explique pourquoi un jour ce mécanisme de virtu est présent dans les packets Debian et la version d'après faut tout triturer.
Ils avaient qu'a se mettre d'accord avant entre eux avant de proposer ça aux utilisateurs
C'est souvent comme ça avec Debian, c'est probablement le côté GNU un peu qui provoque ça. Le côté cathédrale maitrisée de FreeBSD me convient mieux et m'apporte plus de stabilité.
Voilà typiquement ce genre de scénarios qui n'arrivera jamais sous FreeBSD d'une version à une autre aucune surprise.
Rc.conf reste à la même place, tout reste à la même place, les commandes ne changent pas, l'arborescence de fichier ne change pas.
Même après un freebsd-update vers la nouvelle stable, tu prends tes jails, tu les détarres et hop tout roule et ce depuis le tout début pas de surprise, on maitrise.
C'est ça ce que j'appelle être carré.
Rien à voir non plus avec aucun logiciel d'automation de déploiement comme puppet/ansible, j'vois pas ce qu'ils viennent faire la dedans (ça c'était la reflexion d'une autre personne du forum je crois mais peu importe).
Aucun rapport avec une éventuelle feignant ou flemme de customisation.
Au fait un bon admin est quelqu'un de feignant.
LxC au tout début de Debian 8.0 clairement c'était pas ça navré et surtout pété de bug, les templates ne marchait pas fallait aller bidouiller des choses à côté également ..
La configuration c'était bien hardcore, surtout la conf réseau pour obtenir quelque chose d'aussi secure et closonné que FreeBSD, bien malin qui voulait partir sur une archi LxC dans ses tout début, sans à nouveau y passes ses nuits à tout configurer et clairement.
L'aventure OpenVz m'avait déjà bien refrodit.
Rebooter FreeBSD ? Non lorsque tu fais pkg upgrade/update -> absolument aucun besoin de reboot.
Seul freebsd-update/upgrade qui t'oblige à reboot ensuite.
Oui ajouté une ligne dans un fichier répond à tout mes besoins, je vois pas plus simple.
Remonter une FreeBSD en disaster recovery c'est un fichier rc.conf + les services en archives jails en tar.gz, un script sh permet de remonter une machine au poil et up-to-date, et je parle d'une machine faisant hyperviseur avec des jails dans des environnement sécurisés + chroot, avec VLAN différents.
Pas une machine qui fait tourner nginx dans /var/www.
Niveau simplicité pour un herbergement @home, j'ai rien rencontré de plus simple.
Tiens prends ta corde M. Le Responsable d'Equipe, ça doit être beau la bidouille ...
[^] # Re: Ah les BSDistes
Posté par Kwiknclean . En réponse au journal Debian sur mon serveur plus jamais, de chez jamais.. Évalué à -7. Dernière modification le 14 décembre 2017 à 17:26.
Je suis parfaitement honnête, tu peux donc mourir si tu veux.
Je me répète j'aime mettre en place des solutions maitrisées et huilées sur la durée.
J'avais investi beaucoup de temps à l'époque sur OpenVz chez moi à bien tout paramétrer mes services. Etre capable de remonter en disaster recovery from ISO + mes services, me prenait 10 minutes montre en main, opération fièrement testées et retestée. C'est le genre de chose ou une fois installé j'ai pas envie d'y revenir tout les 2 ans pour réfléchir à mon infra. Du coup bêtement je me dis que je vais pouvoir "capitaliser" longtemps sur cette techno ...
J'ai autre chose à faire que de passer mes hivers à geeker mon serveur pour mettre en place un backup, c'est long et chronophage.
Je veux juste venir sur le systeme faire apt-get update / upgrade de temps en temps et le faire vivre le système comme ça pendant des années.
Bref ça c'est de la production, 0 coupure, 0 problème, environnement maitrisé.
On est pas en mode bidouille je me fais plaisir je patch le dernier kernel parce que j'ai lu la dernière dépêche de patrick_g.
Debian 7.x -> apt-get install linux-image-openvz-amd64 et fin de chantier : c'est ça que j'appelle sans bidouilles et "natif" avec installation fluide.
Debian 8.0 -> Alors bon on va commencer par downgrader le Noyo, faut mettre un kernel patché RH sous Debian voilà ça commence bien et ça rassure pour l'avenir ... Ca j'appelle ça de la bidouille du truc pour les bricoleurs sûrement pas un truc sérieux.
Puis ça tombe bien parce que pour redémarrer les services c'est plus du tout pareil non plus, impeccable.
Rien à faire de savoir si pourquoi et comment si c'est upstream ou pas, en l'état qu'on m'explique pourquoi un jour ce mécanisme de virtu est présent dans les packets Debian et la version d'après faut tout triturer.
Ils avaient qu'a se mettre d'accord avant entre eux avant de proposer ça aux utilisateurs
C'est souvent comme ça avec Debian, c'est probablement le côté GNU un peu qui provoque ça. Le côté cathédrale maitrisée de FreeBSD me convient mieux et m'apporte plus de stabilité.
Voilà typiquement ce genre de scénarios qui n'arrivera jamais sous FreeBSD d'une version à une autre aucune surprise.
Rc.conf reste à la même place, tout reste à la même place, les commandes ne changent pas, l'arborescence de fichier ne change pas.
Même après un freebsd-update vers la nouvelle stable, tu prends tes jails, tu les détarres et hop tout roule et ce depuis le tout début pas de surprise, on maitrise.
C'est ça ce que j'appelle être carré.
Rien à voir non plus avec aucun logiciel d'automation de déploiement comme puppet/ansible, j'vois pas ce qu'ils viennent faire la dedans (ça c'était la reflexion d'une autre personne du forum je crois mais peu importe).
Aucun rapport avec une éventuelle feignant ou flemme de customisation.
Au fait un bon admin est quelqu'un de feignant.
LxC au tout début de Debian 8.0 clairement c'était pas ça navré et surtout pété de bug, les templates ne marchait pas fallait aller bidouiller des choses à côté également ..
Sous Ubuntu : http://linuxfr.org/forums/linux-general/posts/problemes-avec-contener-lxc-qui-ne-demarrent-plus
La configuration c'était bien hardcore, surtout la conf réseau pour obtenir quelque chose d'aussi secure et closonné que FreeBSD, bien malin qui voulait partir sur une archi LxC dans ses tout début, sans à nouveau y passes ses nuits à tout configurer et clairement.
L'aventure OpenVz m'avait déjà bien refrodit.
Rebooter FreeBSD ? Non lorsque tu fais pkg upgrade/update -> absolument aucun besoin de reboot.
Seul freebsd-update/upgrade qui t'oblige à reboot ensuite.
Oui ajouté une ligne dans un fichier répond à tout mes besoins, je vois pas plus simple.
Remonter une FreeBSD en disaster recovery c'est un fichier rc.conf + les services en archives jails en tar.gz, un script sh permet de remonter une machine au poil et up-to-date, et je parle d'une machine faisant hyperviseur avec des jails dans des environnement sécurisés + chroot, avec VLAN différents.
Pas une machine qui fait tourner nginx dans /var/www.
Niveau simplicité pour un herbergement @home, j'ai rien rencontré de plus simple.
Tiens prends ta corde M. Le Responsable d'Equipe, ça doit être beau la bidouille ...