Sommaire
Bonjour journal,
J'aime bien lâcher des pavés sur Internet.
Déjà ça me sert d'exutoire pour extérioriser ma frustration, ensuite ça permet également d'échanger et d'avoir vos avis qui je dois le dire sont loin d'être toujours inintéressants.
Depuis que j'ai découvert FreeBSD il y a maintenant 4 ou 5 ans, je ne me sers plus que ça en environnement serveur à la maison et je ne comprends même pas qu'on puisse installer des trucs de bricoleurs comme Debian, qui est tout sauf un truc à mettre en entreprise
De façon subjective je vais tâcher d'expliquer pourquoi je trouve que FreeBSD c'est mieux que Debian lorsqu'on veut poser une machine pour des années (ou d'autres d'ailleurs), distribution de branleurs à réserver aux Facultés et autres associations pour bidouilleurs et certainement pas des informaticiens qui aiment les choses qui tournent longtemps. (J'écris comme je l'entends ici c'est mon journal).
Je ne m'attarderais pas sur les détails de l'aspect licencing, GNU/BSD y a déjà eu moult journaux de spécialistes à ce sujet, et ce n'est pas mon propos.
Honnêtement GNU/Linux je trouve que c'est le bordel d'une version à l'autre y a rien qui est pareil.
Je dis Debian mais RedHat sérieusement c'est pas mieux.
La gestion du multipathing pour utiliser un exemple d'une fonctionnalité "pro", d'une version à l'autre c'est un sketch tout change faut tout réimplémenter la grosse blague. Je ne parle pas de l'arborescence du système de paquets…
La découverte :
C'était il y a 4 ou 5 ans. Comme beaucoup j'utilisais fièrement une distribution GNU/Debian, une nouvelle stable veinaient de sortir, j'étais plein de motivations, je faisais mumuse à l'époque avec OpenVZ que je trouvais sympathique, j'avais bien rodé mon système de backup/resto (très important et très long à valider), comme quelqu'un qui aime la stabilité dans le temps et les choses bien huilées, j'aime bien poser des choses qui sont conçus pour durées des années sans devoir y faire des opérations trop lourdes. Et clairement j'ai pas l'impression que ça soit la philosophie des distributions GNU.
Debian 8.0 vient d'arriver là niveau "virtualisation" (Note les guillemets je sais que LxC/KVM/OpenVz tout ça c'est pas du tout la même chose hein merci) c'est le bordel. LxC est encore version 0.x, Docker n'existe pas encore je crois, se pointe et je n'ai plus l'explication technique détaillée mais en gros fallait downgrader son noyau < 3.0 sur les nouvelles Debian pour pouvoir continuer à Utiliser OpenVz (Compatibilité Cgroups de mémoire).
Pardooooooooon, tu te fous de ma gueule ? Donwgrader un noyau t'en as d'autres des comme ça ? C'est quoi cette bidouille ? En gros j'utilise quoi moi pour être tranquille pour 10 ans ?!!
Bon on essaie Ubuntu Serveur pour rigoler LxC a l'air plus mature chez eux, je teste un peu … bon ça a l'air prometteur, hop je fais une p'tite mise à jour de mon OS et PAN :
Allez hop au revoir toute cette merde !
Dat Documentation :
On commence par poser là l'argument qui a lui seul devrait vous convaincre que y a deux mondes.
La documentation EST béton, d'entrée de jeu ça rassure, et moi j'aime les choses carrés fignolées et surtout documentées !
Là on ne cherche pas sur des wordpress de blogueurs douteux, là on va ici :
https://www.freebsd.org/doc/fr/books/handbook/ et ça couvre 90% de nos questions, pour le reste on s’inscrit sur le forum FreeBSD.
La base n'est pas mélangée avec les paquets.
Tu vois comment on met à jours sous Debian apt-get install et ça te met tout à jour logiciels tiers et noyaux + base système, quel truc de bourrin.
Sous FreeBSD, ce sont deux choses différents.
Le système de paquets pkg ne met à jour QUE les logiciels et ne touche pas à la base et au noyau, pas besoin de reboot ensuite (de toutes façons toutes tes applications tournent en Jails).
Pour mettre à jour la base c'est une autre commande bien distincte.
freebsd-update fetch
freebsd-update install
Un problème après la mise à jour système ?
freebsd-update rollback , mon ami.
Pour rassurer ceux qui j'imagine que les repositories FreeBSD sont un comptoir marchand Soviétique, je n'ai jamais été obligé d'installer quoique ce soit par les sources, j'ai toujours tout trouvé dans les packets, et souvent bien plus à jour que sous Debian (CentOs et Red Hat j'en parle même pas p'têt d'ici 2035 on aura PHP 7)
Packet-Filter, encore un logiciel qui fait passer IPtable pour un firewall Windows.
Quand t'as commencé à toucher à Packet Filter tu te demandes comment IPtable encore être autant plébiscité …
Obligé de mettre des Fails2Ban et autres trucs de rigolos pour empêcher le brut Force SSH, obligé d'aller lire des logs quelle blague … Installé un module supplémentaire pour blacklister des plages d'IP … mais c'est quoi toutes ces verrues, des rustines partout … ça devient tellement fatiguant ..
Moi je rajoute quelque chose comme ça :
# Block SSH bruteforce
pass in on $ext_if proto tcp from !<whitelist> to $ext_if port 22 \
flags S/SA keep state \
(max-src-conn-rate 3/60, \
overload <blacklist> flush global)
Et ça suffit largement, pas besoin de bidouilles partout, Note qu'ici nous seulement ça empêche le brut force (si plus 3 tentatives dans les 30 secondes), et en plus ça ne passe que si de toutes façons l'IP source fait partie d'une table whitelist, et ça remplit une autre table Blacklist lorsque l'IP déclenche la règle.
Non laisse tomber IPtable sait pas faire ça.
La configuration.
Sous FreeBSD y a globalement un fichier à connaitre il s'agit de /etc/rc.conf fin de discussion.
Tu veux démarrer un service en auto, activer une fonctionnalité noyau, démarrer tes Jails au boot, ajouter ssh au boot, configurer ton réseau, ajouter des interfaces réseaux virtuelles ?
vi /etc/rc.conf
ifconfig_lcn0_alias0="192.168.1.5 netmask 255.255.255.255"
sshd_enable="YES"
hostname="MaMachine"
pf_enable="YES"
jail_enable="YES"
Et ce depuis FreeBSD hum … le début non ?
Comment on fait sous Debian ou Red Hat déjà ?
Ha ouiiiiiiiii ça dépend de ta version évidemment .. un coup c'est avec sysv-rc-conf , l'autre c'est avec update-rc.d quand c'est pas /etc/rc.conf … ha merde j'suis sous RedHat c'est avec chkconfig
Non mais t'appelle ça du boulot toi ? T'es sérieux là ?
# Ha merde j'ai mal cliqué ...
Posté par Kwiknclean . Évalué à 9.
Bon j'ai pas finis d'écrire et d'éditer mon Journal … :(
J'ai cliqué par mégarde sur publier au lieu de prévisualiser, ce n'est pas fini du tout et plein de fautes … :(
[^] # Re: Ha merde j'ai mal cliqué ...
Posté par eingousef . Évalué à 10.
ne t inquiète pas au milieu des journaux linuxfr ça passera inaperçu
*splash!*
[^] # Re: Ha merde j'ai mal cliqué ...
Posté par Nitchevo (site web personnel) . Évalué à 10.
Tiens un rédacteur de journaux précoce…..
[^] # Re: Ha merde j'ai mal cliqué ...
Posté par Kwiknclean . Évalué à 3.
Du coup je vais en prendre plein la tronche, sur le fond et la forme (je vous connais les lascars), mais tant pis pour moi, j'avais qu'a faire plus attention.
M'en fiche, la prochaine fois j'en remets un sous une autre forme, plus finalisée construite et argumentée d'exemple concret, je lâcherai rien.
[^] # Re: Ha merde j'ai mal cliqué ...
Posté par BAud (site web personnel) . Évalué à 4.
Tu as https://linuxfr.org/redaction pour l'espace de rédaction qui te permet de laisser en visibilité de tous les inscrits un pamphlet factuel agrémenté par des contributeurs de passage ajoutant leurs arguments pour constituer une dépêche publiable (un 'dredi de préférence).
Et en plus, tu peux l'éditer quand tu veux et les phôtes d'ortografe se corrigeront d'elles-même (oui, faute c'est féminin, pas le fait d'un homme par nature :p)
jdçjdr :-)
[^] # Re: Ha merde j'ai mal cliqué ...
Posté par Benoît Sibaud (site web personnel) . Évalué à 7.
J'ai corrigé le plus gros a priori.
[^] # Re: Ha merde j'ai mal cliqué ...
Posté par Bruce Le Nain (site web personnel) . Évalué à 3.
Et ce… :)
[^] # Re: Ha merde j'ai mal cliqué ...
Posté par Arkem . Évalué à 3.
Ouille! Vu tout ce qui reste, ça devait être beau :D
[^] # Re: Ha merde j'ai mal cliqué ...
Posté par NumOpen . Évalué à 2.
ajouté des interfaces->ajouter des interfaces
[^] # Re: Ha merde j'ai mal cliqué ...
Posté par Nibel . Évalué à 3. Dernière modification le 14 décembre 2017 à 16:41.
Surtout que je suis venu en pensant à un trolldi précoce mais même pas…
J'aurai bien aimé lire un billet argumenté entier, je suis actuellement en train de réfléchir à changer Debian sur mes VPS et je connais moins les systèmes BSD, cela aurait pu m'aider à me décider. Chez moi, j'utilise du Arch pour tout, autant sur ma machine perso, ma machine pro, mon Raspberry ou mon petit serveur auto-hébergé. L'avantage c'est que toutes les technologies sont à jour, après je sais bien que Arch c'est pas forcément conçu pour les serveurs.
Un autre défaut, au delà des versions de logiciels souvent dépassées, ce qui m'énerve le plus c'est la multiplication des gestionnaires de paquets sur Debian. Pour un débutant, comment se retrouver au milieu de apt, aptitude, dpkg, synaptic… Bien qu'au final tous se basent sur dpkg, tous les softs ne s'installent pas sur tous les gestionnaires…
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
[^] # Re: Ha merde j'ai mal cliqué ...
Posté par gnumdk (site web personnel) . Évalué à 4.
What? Déjà, tu trouveras aussi des interfaces graphique pour FreeBSD donc je vois pas trop ce que viens faire synaptic…
Sous debian, c'est apt/apt-get point barre… Mais je vois pas ce qui ne s'installerait pas avec l'un ou l'autre…
[^] # Re: Ha merde j'ai mal cliqué ...
Posté par BAud (site web personnel) . Évalué à 3.
désormais, c'est apt : apt-get n'étant qu'un synonyme. Mais il y a eu une période avec aptitude/apt-get dont le résolveur de dépendance ne donnait pas toujours le même résultat et le mix des deux amenait à quelques dysfonctionnements… en graphique, synaptic faisait le taf' (jamais utilisé).
Et sinon, tu ne voudrais pas renommer ton pseudo en gnumga ? :D (histoire de revenir avec ta joie et ta bonne humeur dans notre communauté accueillante et constructive :p).
[^] # Re: Ha merde j'ai mal cliqué ...
Posté par Framasky (site web personnel) . Évalué à 5.
Ah non, c'est pas un synonyme. Ils le disent implicitement dans le man (le gras est de moi) :
Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.
[^] # Re: Ha merde j'ai mal cliqué ...
Posté par Kwiknclean . Évalué à 4.
Une des raisons qui m'ont fait quitter Debian … tout ce chaos tout le temps … bref … j'en rajoute pas.
Fut un temps, j'avais un blog planqué sur un VPS (avec plein d'articles sur FreeBSD ..) mais c'était à l'époque ou j'imaginais que les backup c'était pour les peureuses, et qu'un VPS OVH c'était indestructible.
J'ai encore les sources quelques parts je vais me servir de tout ça pour vous compiler faire une présentation bien léchée (et qui troll moins à charge, J'utilise Mint sur mon desktop les gars ça va …).
Avec des exemples de montage d'architectures sécurisées de montage Jails dans des environnement réseau séparés etc etc … et ça c'est en quelques lignes de commandes seulement :-)
Remonter un hyperviseur up-to-date en desaster recovery avec ses jails sous un seul script sh sous FreeBSD c'est le B.a.BA et c'est ça qui me séduit tant dans cet OS.
Je veux bien également en faire une dépêche collaborative ça m'arrangerait pour la forme (on parlerait moins des photes) et ça permettrait d'améliorer la prose aussi qu'est pas folichonne.
[^] # Re: Ha merde j'ai mal cliqué ...
Posté par Zatalyz (site web personnel) . Évalué à 3.
Plus qu'une solution, en faire une dépêche… Parce que ça commence bien. Côté serveur ça fait un moment que je suis tentée pour voir à quoi BSD ressemble, mes derniers déboires avec Debian commencent à peser lourd sur la balance, un retour d'expérience dans ton genre va peut-être me décider à sauter le pas :)
# Tu m'as convaincu !
Posté par gUI (Mastodon) . Évalué à 2.
Non, je déconne, mais je reconnais sans pb les défauts dont tu parles. Je m'en étais formulé certains, d'autres étaient plus "inconscients", mais comme c'est inhérent à plus ou moins toutes les distributions, j'avais un petit côté fataliste qui me contentait de mon sort.
Mais toujours pareil, quand on a eu du mal à prendre ses habitudes dans un système plus ou moins bancal, c'est dur de rechanger ses habitudes, y compris dans un système globalement mieux foutu.
Demande aux utilisateurs de Windows ;)
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Tu m'as convaincu !
Posté par Kwiknclean . Évalué à 3.
J'suis vraiment navré, j'étais tellement excité sur mon clavier que j'ai publié le journal alors que ce dernier n'était pas terminé … :(
C'est ça d'être un gros bourrin ..
[^] # Re: Tu m'as convaincu !
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 10.
Du coup changer de pseudo : KwiknDirty ?
Juste une petite question sur un détail : reprocher à Debian de ne pas utiliser exactement les mêmes commandes, outils et organisations que RedHat, ou autre distribution GNU/Linux, ne serait-ce pas un peu comme reprocher à FreeBSD de ne pas être un clone parfait de NetBSD, OpenBSD, et consorts ?
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Tu m'as convaincu !
Posté par Kwiknclean . Évalué à 3.
Héhéhé, c'est bien fait pour ma gueule.
Ce que je reproche surtout c'est que d'une version à l'autre, sur la même distribution, ce n'est pas la même chose !
[^] # Re: Tu m'as convaincu !
Posté par kna . Évalué à 10.
Ben, ça évolue.
Pour les services tu as systemd qui est arrivé, donc ça change. celà dit les anciennes commandes fonctionnent toujours. Pour tout dire, j'aurais préféré qu'elles ne fonctionnent plus et qu'ils aient migré totalement vers systemd, plutôt que le monstre mi-systemd mi-sysv avec des wrappers de l'un vers l'autre…
Pour le firewall, tu as xft qui a débarqué, parce que oui, la syntaxe iptables est pas terrible. Mais iptables est toujours disponible, tes vieux scripts iptables écrit il y a 10 ans fonctionnent toujours.
[^] # Re: Tu m'as convaincu !
Posté par Le Gab . Évalué à 3.
Totalement d'accords, c'est l'une des plus grosses erreurs selon moi, le côté cul entre 2 chaises.
Pareil pour le gestionnaire réseau, NetworkManager et pis c'est tout.
Suivre la logique systemd/RedHat jusqu'au bout.
Tout comme PulseAudio qui nous a enterré Alsa* qui avait lui-même remplacé OSS.
Parce que finalement, il reste quoi aux distros non Red hat? Á part absorber les technos du chapeau rouge sans réellement les assumer, bon après, le côté "legacy" est aussi encore un peu présents sous Fedora/CentOS bien que moins conflictuel.
mes 2 centimes.
* oui, PulseAudio n'est peut-être pas sur ta distro kevinRoxPC-0.12 fork de Mint dont le desktop est openbox et son server son OSS pour plus de légèreté tout en proposant une logithèque incroyable: LibreOffice, VLC, Firefox, Gimp, Audacious.
[^] # Re: Tu m'as convaincu !
Posté par kna . Évalué à 3. Dernière modification le 15 décembre 2017 à 12:33.
Ben c'est pareil chez RedHat, il reste des scripts dans /etc/init.d (par exemple network). Si tu les lances, le bash intercepte la commande pour lancer systemctl à la place qui génère un unit à la volée…
Cela dit, j'utilise en majorité debian, mais j'ai l'impression que plus de services ont été migrés vers systemd sur RH/CentOS en comparaison à debian.
Et je ne sais pas si on trouve des services aussi mal migrés chez RedHat. Mais sous debian, je suis tombé sur des trucs assez moches, par exemple :
- opendkim utilise maintenant un unit systemd, mais il ne lit plus /etc/default/opendkim (bien que le fichier soit toujours installé par le paquet)
- openvpn installe un unit avec
ExecStart=/bin/true! Il y a toujours un script dans /etc/init.d mais il ne sera jamais lancé si systemd est installé…[^] # Re: Tu m'as convaincu !
Posté par -=[ silmaril ]=- (site web personnel) . Évalué à 3.
oui c'est justement l'idée il me semble, ou en partie.
par contre tu peut activer les différents clients ou serveurs openvpn via l'unit "modèle" openvpn@, par "systemctl enable openvpn@"
[^] # Re: Tu m'as convaincu !
Posté par gouttegd . Évalué à 4.
Il faut appeler le script
/lib/opendkim/opendkim.service.generatepour que le contenu du fichier/etc/default/opendkimsoit pris en compte.Et je suis d’accord, c’est assez moche.
# Troll
Posté par Sacha Trémoureux (site web personnel) . Évalué à 10.
C'est pas vendredi hein.
[^] # Re: Troll
Posté par Le Gab . Évalué à 2.
Je trouve cela injuste voire discriminatoire pour les autres jours de la semaines qui n'ont jamais demandé.e.s être placé.e.s à leurs… places et qui aimeraient bien être le jour de ses échanges enrichissant.e.s
#JourDeLaSemaine pour une écriture randomisé.e.s du calendrier grégorien qui d'ailleurs devrait porter another nom: Conchita Wruth?
[^] # Re: Troll
Posté par Yth (Mastodon) . Évalué à 5.
Ouais, d'ailleurs le vendredi ça ne tombe jamais le même jour de la décade !
Demain ça sera quintidi, alors que vendredi dernier c'était octidi, on ne s'y retrouve jamais.
Yth, joyeuse Oseille en cette année 226 !
# Ah les BSDistes
Posté par gnumdk (site web personnel) . Évalué à 10.
Plus malhonnêtes, tu meurs…
https://packages.debian.org/jessie/lxc
OpenVZ ne fait parti ni de Linux ni de Debian. En gros, ça veut dire que tu utilisais un noyau de chez OpenVZ et que tu n'as pas attendu qu'ils supportent Debian 8… Si tu ne comprends pas ce que tu fais…
Ah bon, le noyau FreeBSD se met à jour en mémoire tout seul?
Le whitelist/blacklist oui mais le reste IPtables fait très bien… Et pas besoin de troller avec fail2ban qui ne répond pas du tout au même besoin. Si pour toi, bloquer en fonction du nombre de tentatives de connexion c'est une bonne idée, alors franchement, je sais pas où tu bosses…
Et est ce que c'est souple, est ce que ça répond à tous les besoins? Absolument pas, mais il est sur que c'est bien pour les vieux admin trop feignants pour configurer leur serveur (troll inside)
Note pour plus tard: BSD sur un CV == boulet == dehors
[^] # Re: Ah les BSDistes
Posté par Kwiknclean . É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 …
[^] # Re: Ah les BSDistes
Posté par Anonyme . Évalué à 10.
Tu le fais exprès ? C'est quoi que tu comprends pas dans le fait que openvz n'est pas supporté ni par Debian, ni par le noyaux et qu'il s'agit d'un kernel patché distribué par une société commerciale ?
Si c'est pas de la malhonnêteté, c'est de l'incompétence…
[^] # Re: Ah les BSDistes
Posté par Kwiknclean . Évalué à -10. Dernière modification le 15 décembre 2017 à 14:56.
… l’incompétent va détailler sa pensée.
IL y a un moment il va falloir que certains ayatollahs de l'OpenSource prennent conscience que chaque lignes de code insérées dans les projets GNU, ne sont pas écrites par des développeurs autonomes seuls dans leur garage, vivant d'amour et d'eau fraiche.
Et qu'avant commit dans un projet ils ne reçoivent pas une bénédiction de Stallman ou Torvalds pour validation éthique visant à s'assurer que surtout rien ne vient d'une société commerciale, le mal absolu !
Oui Virtuozzo est une société qui supporte OpenVZ sous licence GNU/GPL
Tout comme Proxmox Server Solutions GmbH propose un support Proxmox, ou d'autres sociétés encore plus sales, comme RedHat, Intel, Vmware, EMC, Dell, Google … même Microsoft toutes des sociétés de l'axe du mal contribuent également aux différents projets GNU (Kernel compris) et crois moi ils ne commit pas Gnome ou VLC … Donc il va falloir m'expliquer en quoi incorporer des lignes de codes venant d'une sociétés "commerciale" comme Virtuozzo pose plus de problème qu'une autre ?
En suivant ta logique, on devrait donc commencer à aller épurer tout ce qui a été ajouté par ces dernières sociétés il resteraient plus grand chose de la sacro-sainte Debian.
Donc oui Virtuozzo aurait du commit dans l'upstream du kernel, j'ignore pourquoi ça ne s'est pas fait, à vrai dire je n'ai pas cherché avec ces histoires de licencing, ça m'a bien assez saouler comme ça cette affaire … j'ai lâché tout ça, j'me suis tourné vers un OS à la ligne sur.
[^] # Re: Ah les BSDistes
Posté par Moonz . Évalué à 10.
Quel est donc cet OS miracle qui donne des garanties de sureté même quand tu remplaces leur kernel par une version modifiée par un tiers ?
[^] # Re: Ah les BSDistes
Posté par madhatter (site web personnel) . Évalué à 3. Dernière modification le 16 décembre 2017 à 23:24.
Non, une solution open source supportée par une entreprise ce n'est pas le mal.
Mais c'est juste un petit peu pénible parfois.
Dans le cas d'OpenVZ, le fait que ce ne soit pas intégré au noyau rend compliqué la maintenance pour les adminsys. Je ne sais pour quelle raison mais pour Xen, c'était aussi le cas, parce que (à tort ou à raison, je ne sais pas) le code était trop compliqué à intégrer. L'équipe de Xen a fait ce qu'il fallait et ils ont fini par être intégrés.
Dans le cas de Proxmox, c'est un très bon produit, mais qui a l'énorme défaut d'avoir une API de management spécifique le rendant incompatible avec des outils basés sur libvirt. Et en ce qui me concerne en tant qu'adminsys, je vais bientôt être face à la problématique de devoir unifier dans une seule console web, environ 500 hyperviseurs Proxmox répartis sur 300 sites distants… Ce qui n'est pas possible avec Proxmox.
There is no spoon...
[^] # Re: Ah les BSDistes
Posté par claudex . Évalué à 10.
Merci de rester courtois dans les commentaires.
« 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: Ah les BSDistes
Posté par johnnyflame . Évalué à 1.
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.
le paquet linux-image-openvz-amd64 n'existe pas.
https://packages.debian.org/search?keywords=openvz&searchon=names&suite=oldstable§ion=all
du coup le natif sans bidouille…
[^] # Re: Ah les BSDistes
Posté par Misc (site web personnel) . Évalué à 4.
Netfilter/iptable a le support d'ipset, ce qui est grosso modo suffisant pour faire des blacklists/whitelists.
Et iptables/netfilter fait en effet aussi le matching par paquet vu par seconde, etc.
[^] # Re: Ah les BSDistes
Posté par claudex . Évalué à 6.
Et nftables a la notion de set qui peuvent aussi être utilisé pour des ports tcp (contrairement à pf).
« 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: Ah les BSDistes
Posté par jyes . Évalué à 3.
À gnumdk, Goldy et Moonz, vous accusez sans fondement ! J’aime Debian, mais la déconvenue de Kwiknclean n’est pas due à son incompétence vis-à-vis d’OpenVZ ou LXC. OpenVZ était dans Debian, avant d’être remplacé par un LXC encore bancal à l’époque. La transition était amusante, mais je comprends qu’elle ait pu laisser un goût amer.
# Re: Debian sur mon serveur plus jamais, de chez jamais
Posté par Moonz . Évalué à 10.
Moi, ce que je lis de cette règle, c’est placer dans la blacklist toute connexion "trop rapide" (ie >3/minute). fail2ban ne met en blacklist que les tentatives infructueuses.
Avec ta règle, si j’ouvre 4 connections valides (avec la bonne clé/le bon mot de passe), ben je me fais quand même jeter.
[^] # Re: Debian sur mon serveur plus jamais, de chez jamais
Posté par Vincent Bernat (site web personnel) . Évalué à 10.
Suffit de mettre fail2ban qui te rajoute dans la whitelist lors de la première tentative réussie.
[^] # Re: Debian sur mon serveur plus jamais, de chez jamais
Posté par David Marec . Évalué à 5.
Moi quand je lis cette règle, je me dis qu'il serait temps d'utiliser
blacklistd
Et de se concocter un blacklistd.conf.
# C'est pas vendredi
Posté par MTux . Évalué à 10. Dernière modification le 14 décembre 2017 à 12:19.
C'est pas vendredi. Pour avoir longuement utilisé les deux, je propose d'apporter les précisions suivantes :
OpenVZ n'est pas upstream, c'est de leur faute s'ils n'ont longtemps supporté que le kernel 2.6.32, pas celle de Debian. Après des années et des années de "oui, on réécrit ça en upstream dans le kernel, c'est pour bientôt" je ne sais pas si ça a fini par évoluer. C'est dommage car oui c'est probablement le meilleur truc pour faire des vps bien isolés et pilotables.
La documentation de FreeBSD est bien mais : elle reste légère (pour les jails c'est pas très clair je trouve), elle ne couvre que le système de base (alors que dans la vraie vie tu va avoir besoin des ports/packages sinon tu fais pas grand chose). Tu va me dire qu'il y a les manpage, mais pour moi rien ne vaut des exemples pratiques pour comprendre une techno. Pour debian tu as une énorme communauté d'utilisateurs (blogs, stackoverflow, collègues…) qui n'est pas négligeable. J'accorde cependant que les logiciels de base de FreeBSD ont tous une conf humainement lisible et compréhensible.
Oui LXC c'est bancal, c'est un autre point que j'accorde. Je rajoute que sous Wheezy il y avait un bug qui faisait que certains templates ne marchait pas et le mainteneur était de mauvaise foi ("oui mais sous Sid ça marche"), les utilisateurs ont du monter un mini scandale pour que ce soit corrigé. Sous Linux on ne sait jamais quel système de container/virtualisation sera mature ou upstream l'année prochaine. Mais basiquement aujourd'hui tout le monde a les yeux rivés sur Docker pour les containers et KVM pour la virtualisation.
Iptables ça se discute, perso je suis habitué à leur syntaxe. Par contre je regrette qu'il n'y ait pas de daemon officiel pour charger les règles au démarrage, tout le monde y va de sa sauce (édition du /etc/rc.local, unit systemd…).
La base n'est pas mélangée avec les packets : bouais là encore l'intérêt se discute. Sur debian le même soin est apporté au système de base ou aux logiciels tiers (qui n'ont même pas de distinction). Sur FreeBSD, par expérience j'ai toujours fini par avoir des problèmes avec pkg upgrade à cause des logiciels tiers en rolling release. Le dernier en date c'était deluge (dépendance python ou liboost pétée je crois). Sous debian c'est figé il n'y a pas de surprise (ou rarement, et le mainteneur corrige). Ou encore cet aspect rolling release fait que les fichiers de conf peuvent changer, moi j'avais tout automatisé avec Ansible, et suite à une maj mon playbook ne fonctionnait plus (unbound qui intégrait deux lignes "listen" au lieu d'une, soudainement).
Le /etc/rc.conf : mouais, ça ne concerne que les logiciels de base de FreeBSD, par exemple si tu installe nginx à partir des ports tu aura toujours un /usr/local/etc/nginx/nginx.conf à gérer hein. Faut penser à tout l'écosystème qui va avec.
Point que je rajoute : FreeBSD n'a pas systemd. Si vous mettez de côté tout le FUD qu'on a fait sur cette techno et essayez d'écrire un service ou un container (systemd-nspawn) vous verrez que c'est génial, unifié, et qu'on gagne un temps fou. Jetez un oeil à l'init de nginx et à son unit systemd, le second est tellement plus simple et lisible. Chaque fois que j'ai du bidouiller un init pour FreeBSD je me suis dit "putain, j'y ai passé des heures alors qu'avec systemd j'aurais juste mis ma commande, mon user et hop".
Après c'est sûr que FreeBSD est un super OS, de part son support natif de ZFS, son développement rapide, sa grande compatibilité hardware, ses jails, ses services réseau. Mais perso par expérience j'en reviens toujours à Debian qui est plus universel, qui est figé (pas de rolling release), mais c'est un choix.
[^] # Re: C'est pas vendredi
Posté par Kwiknclean . Évalué à 2. Dernière modification le 14 décembre 2017 à 13:08.
Oui bon on est Jeudi, mais c'était prévu pour demain tout ça … j'ai miscliqué sur publier l'article n'était même pas terminé -_- Tant pis pour ma gueule la prochaine fois je ferai ça dans le bloc-note + bonpatron.
Voilà le genre de commentaire auquel je m'attendais, de quelqu'un qui effectivement comprend de quoi je parle, et qui n'essaie pas de m'expliquer que je suis de mauvaise foi ou incompétent … merci.
J'aime la stabilité et poser des choses solides pour des années, je ne suis pas un afficionados de la mode et de la nouvelle feature qui va tout tuer, mais qui peut faire planter ton système quand même … J'aime le robuste et le solide, le sur et le fiable, bref je fais de l'informatique de production par de la bidouille.
Pour OpenVz, je n'ai pas dit que c'était de la faute de l'un ou l'autre. Mais qu'est ce que vient foutre un outil de Virtualisation dans tout les OS si la version d'après plus rien n'est supporté, sérieusement c'est quoi cette organisation ? Après des années et des années de "oui, on réécrit ça en upstream dans le kernel, c'est pour bientôt" je ne sais pas si ça a fini par évoluer." J'crois que faut utiliser "Devuan" un un truc comme ça enfin encore une énième bidouille. J'ai lâche l'affaire, bref j'ai bien perdu mon temps avec OpenVZ. Ca va que c'était pour un usage perso, mais j'imagine si j'avais monté un business articulé entièrement autour de cette solution bonjour le merdier …
Pour la documentation BSD, effectivement pour les jails c'est vrai qu'il faut un peu aller voir à côté, mais les informations fiables se trouvent assez facilement.
Pour les Updates, je trouve vraiment que c'est un plus, tu peux update tes paquets comme un sauvage jamais avoir besoin de reboot, si tu ne fais pas de mise à jour de base. PS : pkg est beaucoup, beaucoup plus jeune que apt d'ailleurs c'est lequel qu'il faut utiliser apt-get, aptitude C'est bon les mecs vous vous êtes mis d'accord entre vous ?! Là encore on sait pas trop c'est le bordel … classique.
Pour Iptable, clairement ça me semble à la ramasse, j'ai pas envie de préciser ceux qui ont touchés les deux savent de quoi je parle.
/etc/rc.conf bha oui uniquement les services de l'OS encore heureux que la configuration de nginx se fait dans son fichier !! Honnêtement pour répondre à ceux qui demandent si ça répond à tout mes besoins, mais bien sur que voulez-vous de plus simple bon sang ?!!
T'as une ligne à ajouter dans un seul fichier, toujours le même, partout tout le temps. C'est quoi ce triturage d'esprit ?
Dans mon cas je n'ai jamais été bidouillé, ou alors pas que je me rappelle, un init donc je dirais que ça ne correspond pas à mes besoins.
Après attention je ne dis pas que FreeBSD est le super OS qui est avance sur tout qui répond à tout (toute la gestion Clustering H/A, virtu c'est bien à la ramasse, on est d'accord, mais ça bouge et plutôt que d'aller vite, ça avance de façon réfléchit et maitrisé et cohérente ).
Mais qui à la maison ou sur son Kimsufi ou chez soit a besoin d'implétementer HAST/CARP ?!
Et sont atout majeur -> c'est carré ! Et ça ça fait plaisir, ça avance doucement certes, mais ça avance !
Marre des bricoleurs, des bidouilleurs, 5 façons de relancer un service, 2 façons de faire les mises à jour, et la doc elle est faite quand ?
Sinon je voulais finir mon journal en évoquant le cas entreprise, j'étais étonné d'en trouvé si peu (en fait j'en ai jamais vu en Entreprise …) Pourtant ça serait un OS parfait pour certains usage serveur non ?
Ou même déployer rapidement des services quand même un peu secure avec les templates de jails ? (Oui, Docker tout ça, mais ce n'est pas la même chose, et les Jails ca existe depuis un bail déjà, hors jamais vue)
Tout ce que demande de la stabilité extrême dans le temps, milieu bancaire, haute criticité ?!
Je sais que Netflix pour les frontaux web probablement et NetApp utilise FreeBSD (t'achète leur filer c'est un BSD dessous), Sony avec le PS4 aussi etc .. mais j'en ai jamais jamais croisé en environnement pro.
J'veux dire remplacer des AIX par des RedHat pour faire tourner des batchs, c'est un peu de la blague quand même ?!
Si y a un truc que j'adore au taf c'est te connecter sur une machine tomber sur une vieille merde du genre RH 5.4, alors que y a 2 minutes t'étais quand même une 6.5 récente (rire), et pif ya plus rien qu'est pareil rien n'est ISO, un vrai merdier.
Comment veux-tu gérer un parc ISO ? Moi j'appelle pas ça être carré.
De la cohérence et de la maîtrise voilà ce qu'il manque à GNU/Debian.
[^] # Re: C'est pas vendredi
Posté par Renault (site web personnel) . Évalué à 10.
Si ça te paraît si idéal, c'est quand que tu montes ta boîte pour faire du support professionnel autour de FreeBSD ? Si c'est si facile et efficace, tu devrais y arriver facilement.
Sauf que RedHat apporte un support de 10 ans (voire plus), que ce soit pour maintenir les composants (donc sécurité) ou développé certaines fonctionnalités sur mesure. C'est ça que veulent des pro, des garanties, un interlocuteur sur qui taper quand ça foire.
Sans compter aussi que Red Hat a une politique de formation pour former ses intervenants en internes mais aussi les admins sys des clients. Je ne connais aucun acteur d'envergure qui propose cela pour FreeBSD.
C'est pourtant des critères essentiels pour une infrastructure d'un client.
[^] # Re: C'est pas vendredi
Posté par Jiel (site web personnel) . Évalué à 2. Dernière modification le 15 décembre 2017 à 16:54.
Et c'est d'ailleurs justement pour ça que RHEL ou openSUSE existent en parallèle de Debian. C'est un peu incohérent de vouloir utiliser Debian et se plaindre de devoir bidouiller : Debian est faite pour les gens qui aiment bidouiller et ne se préoccupe pas en premier lieu de servir le monde professionnel (même s'il peut y arriver aussi).
[^] # Re: C'est pas vendredi
Posté par Kerro . Évalué à 5.
Selon moi c'est plutôt : Debian est faite pour les gens qui
aimentn'ont pas peur debidouillersi besoin (mais c'est franchement hyper rare)etne se préoccupe pas en premier lieu dec'est une des distributions parfaites pourservir le monde professionnel[^] # Re: C'est pas vendredi
Posté par Jiel (site web personnel) . Évalué à 2.
Ce que je mettais en avant, c'est qu'une distribution qui est faite pour le monde pro correspond en général encore mieux que Debian au monde pro.
[^] # Re: C'est pas vendredi
Posté par Faya . Évalué à 3.
Disons que si on veut du Debian dans le monde pro il faut trouver un pro Debian. Et ce n'est pas ce qui manque :
https://www.debian.org/consultants/#FR
[^] # Re: C'est pas vendredi
Posté par Psychofox (Mastodon) . Évalué à 6.
Ceux qui utilisaient openvz ont toujours des versions supportées à disposition et ce depuis le temps que ça a été viré du kernel (il y'a 5-6 ans déjà ?). Bref largement le temps faire un plan de migration.
Avec des outils professionnels comme puppet, chef, salt, cfengine ou ansible ?
[^] # Re: C'est pas vendredi
Posté par NeoX . Évalué à 3.
et la migration OpenVZ => LXC c'est pas non plus la mer à boire
[^] # Re: C'est pas vendredi
Posté par MTux . Évalué à 5.
OpenVZ se souciait surtout de RedHat6 / CentOS6 d'où le choix du kernel 2.6.32.
Avec NixOS le fichier /etc/nixos/configuration.nix contient toute la conf du système et des logiciels. Rien qu'avec ce fichier tu peux dupliquer/reconstruire ton serveur en quelques commandes (faut juste penser à copier les données persistantes, s'il y en a). Moi j'adore.
Ben le titre de ton article laisse penser que Debian c'est de la merde quand même, d'où l'hostilité récoltée.
Concernant l'environnement Pro, FreeBSD ça existe, mais plutôt dans l'embarqué j'ai l'impression : FreeNAS, pfSense, et probablement d'autres appliances plus ou moins connues. C'est probablement du à l'aisance avec laquelle on peut construire un système minimaliste (NanoBSD) et ça marche plutôt bien.
Mais il faut voir que Red Hat a un poids énorme en terme de contribution et de parts de marché, ça donne une crédibilité importante à Linux sur les serveurs.
[^] # Re: C'est pas vendredi
Posté par Renault (site web personnel) . Évalué à 6.
Mouais non, dans l'embarqué les *BSD ne sont pas très populaires non plus, tout comme Minix. Linux, FreeRTOS, Vworks, etc. ont bien plus de poids.
Des Linux très minimaliste, il y a un savoir faire énorme. Des solutions permettant de générer ta distribution pour une flotte de machines, ça existe aussi (Yocto). FreeBSD n'a pas beaucoup d'avantages de son côté pour ce domaine.
[^] # Re: C'est pas vendredi
Posté par David Marec . Évalué à 4.
Yocto, c'est une machinerie énorme à coté d'une poudrière, pour un résultat équivalent.
Il a déjà le SIGINFO.
[^] # Re: C'est pas vendredi
Posté par Nico C. . Évalué à 10. Dernière modification le 14 décembre 2017 à 15:48.
Dans tous tes messages, ce qui me gêne le plus dans ton discours est résumé dans cette phrase :
Or, dans tous les exemples que tu donnes, pour toi, robuste/fiable/production = figé pendant des années.
exemple :
Moi, j'appelle pas ça de la production. Ou alors seulement dans une boite elle-même figée.
Une boite qui grandit, qui évolue, qui bouge quoi, rien n'est figé, au contraire même. On est tout le temps en train de remplacer des choses, ajouter et mettre à jour.
Alors je sais pas comment tu bosses ni quel est ton job exact mais si tu es sysadmin, j'ai vraiment l'impression que tu fais partie de ces gens qui font tout à la main, aux petits oignons certes, mais avec des outils qui leurs conviennent à eux et pas nécessairement aux besoins des utilisateurs et du reste de l'équipe. Ces gens qui ne se préoccupent pas de savoir qui sera en charge après eux ou avec eux, ces gens qui râlent au moindre changement car il va falloir toucher au chateau de cartes qu'ils ont patiemment monté de leurs petits doigts d’orfèvres…
En vrai, le problème de la version d'un OS n'en est pas un. Quand tout bouge tout le temps, on automatise beaucoup le provisionnement des serveurs/VM et l'install des softs. L'OS entre dans le tronc commun et n'est plus vraiment un point différenciant (sauf dans des cas très particuliers).
Quand on veut mettre à jour un OS, on monte une nouvelle VM en 5 ou 6 min, on réinstalle le soft et les données en 10min et on bascule le load balancer ou l'IP virtuelle.
Rien à foutre que la MAJ de Debian 8 à Debian 9 se fasse bien ou pas. Rien à foutre que Debian supporte ses OS 3 ans, 5 ans ou 20 ans. Tant que ça tient 1 ou 2 ans max, c'est suffisant.
Rien à foutre que la syntaxe de machin ou truc soit comme ceci ou comme cela, mon outil de provisonning/déploiement masque les différences entre les versions de Debian et même entre les différentes distribs…
Aujourd'hui, au niveau pro, je reste sur Debian car c'est une des distribs les plus utilisées et possédant un des écosystèmes les plus gros et varié. Contrairement à FreeBSD, justement.
Et ça, c'est une différence nette entre les 2 qui rend la 1ère bien plus "professionnelle" que le second…
Mais après, chacun voit midi à sa porte et les défauts que tu relèves sont réels. Aucun doute la dessus.
[^] # Re: C'est pas vendredi
Posté par Misc (site web personnel) . Évalué à 6.
Ceci dit, il y a suffisament de changement pour que l'automatisation puisse devenir un truc relou à maintenir. Par exemple, j'ai fait beaucoup d'automatisation via Ansible, et l'intégration avec l'OS a son importance (genre la gestion du firewall, du reaseau, etc, qui change de version majeur de RHEL en version majeur de RHEL).
Oui, pour reprendre encore une fois Ansible, j'ai du rajouter une paire de trucs pour NetBSD (support de la detection de pkgin, divers facts, etc), justement parce que la communauté semble moins active. J'ai toujours pas trouvé de méthode propre pour l'installation automatique de VM FreeBSD via virt-install, et j'ai pas d'image officiel pour usage dans un cloud openstack (Rackspace dans mon cas) pour NetBSD.
C'est ça aussi l'écosystéme et son intégration.
[^] # Re: C'est pas vendredi
Posté par MTux . Évalué à 3.
Mouais, ça me parait quand même assez éloigné de la réalité. Ou alors tu bosse chez Google ou dans une boite qui a tout kubernetisé et qui n'a pas de base de données / DNS / serveur mail / stockage et d'autres services bien moins évidents à bouger…
C'est pas pour rien si debian propose des versions figées des logiciels, ahem.
[^] # Re: C'est pas vendredi
Posté par Psychofox (Mastodon) . Évalué à 5.
L'exemple de la réinstallation en 10min par MTux est un peu fantaisiste (en vrai on a des infras de dev, inté, test avant de passer en prod) mais il est vrai que dans toutes les boites où j'ai bossé on passe son temps à migrer des trucs d'un serveur/stockage/solution de virtualisation, souvent pour des raisons économiques.
Si tes procédures de disaster recovery sont au points, tu peux normalement migrer relativement facilement et rapidement toute appli, et souvent de façon relativement rapide et indolore. Une appli est généralement divisée en un certain nombre de composants frontend, backends, DB, webservices, annuaires, message queue…Tous ces composants peuvent souvent être migrés séparément, sont individuellement pas sorcier à comprendre/gérer et sont souvent multiplateformes. Ces dernières années j'ai fais beaucoup de migrations de Solaris vers Redhat qui sont au moins aussi différents que debian l'est de freebsd. Je n'ai pas l'impression d'avoir été devant des montagnes insurmontables. À vrai dire le pire c'était des alfresco. Pas parce que l'appli est compliquée mais uniquement parce que les filesystems hébergeaient des multitudes de petits fichier et que d'un point de vue perf c'est ce qu'il y'a de plus long à copier. Les applis web, c'est hyper simple. Ton nginx/Apache, ton php, python, nodejs où que sais-je ne fonctionnent pas différemment qu'ils soient sous Linux, Solaris, Aix ou FreeBSD (voire même windows dans la plupart des cas où la sensibilité à la casse n'est pas primordiale).
Tu parles de bases de données mais en général c'est justement ce qu'il y'a de plus facile à migrer. Tu fous une réplication en place entre la nouvelle et l'ancienne machine (même sous des OS différents), tu laisses la synchro se faire, et le jour où tu bascules c'est l'affaire de quelques minutes. Je l'ai fais encore cette semaine avec Oracle Dataguard. Et au pire même avec des bases non répliquées ça se résume généraleemnt à un dump d'un côté suivi d'un restore de l'autre et à un changement de records DNS. Je n'ai rencontré aucun moteur de base de donnée qui nécessitait un seul OS et dans une seule version pour tourner.
Le stockage sur les 3 boites où j'ai bossé ces 15 dernières années j'ai fais des migrations à peu près tous les 2-3 ans. Je ne vois pas trop en quoi c'est compliqué à vrai dire, d'autant plus quand tu utilises de la virtualisation. Faux être méticuleux pour que ça se passe bien oui, mais je ne connais aucune boite qui a freiné des 4 fers pour éviter des migrations devant l'ampleur de la tâche. Au contraire.
Les messageries c'est souvent dur d'en changer si on est dans le monde proprio (exchange, Lotus Domino, etc) mais pour migrer des serveurs je n'ai pas vu de difficultés particulières.
Bref oui dans le monde pro, ça migre un peu tout le temps. Les seuls qui restent figés dans des versions, c'est les cas de logiciels dont le développement a été fais une fois que ce soit par un employé ou un presta sans qu'un cycle de vie ou une maintenance n'ait été définie. Mais bon dans la plupart ça n'empêche pas de migrer. De toute façon le jour où c'est plus supporté tu t'en fous d'être en conformité avec les specs originale du fournisseur, ce qui compte c'est que ça tourne donc tu vas pas garder un vieux serveur qui est déjà aux soins paliatifs, si tu dois le changer tu le fais et tu fais en sorte que l'appli tourne quand même en copiant les vieilles librairies où en la faisant tourner dans un chroot, zone, container, jail ou vm. De toute façon Murphy fait toujours en sorte que la vieille bécane va cramer et que même si tu trainais des pieds pour migrer t'es quand même obligé un jour à te sortir les doigts du cul et la migrer.
[^] # Re: C'est pas vendredi
Posté par Kwiknclean . Évalué à -5.
Ce n'est pas une histoire de Salt/Puppet/Chef … ou d'outils d'orchestration pour déployer des OS en masse où même de changement … ça n'a même strictement rien à voir et tout n'est pas que "livraison".
Tout n'est pas virtualisé ou virtualisable beaucoup de sociétés ont des gros cluster physiques.
Entre Red Hat 5.5 6 et 7, l'architecture de yum la façon de configurer les repos, les configuration des fichiers de mutltipathing, rien n'est foutu pareil.
Et je ne parle pas d'une petite option ou deux en plus ou d'amélioration au fur et à mesure des versions.
Oui ça c'est bien quand tu livres des vm pour faire tourner des serveurs webs en effet. Debian c'est cool pour faire tourner Apache en effet, bien pour des gens qu'en ont "rien à foutre" en effet.
Pour des clusters de BDD physique sous Oracle ou SAP une Debian c'est parfait c'est sur t'es niquel dans les matrices pour rattacher ça à ta Vmax.
Lorsqu'il faut changer la baie de stockage qui livre les LUN aux différents cluster Oracle sous RH physique, alors qu'ils sont sous plusieurs versions différentes et que tu ne peux pas toujours choisir, car tu es dans un contexte herbergement/infogérance sur une baie de stockage mutualisée, ce sont les OS du client, t'as un RH 5.5 un 6, un 6.5, un 7
Un peu bêtement tu te dis ça va être plus ou moins similaire la conf du multipathing allez … bha non pas du tout, t'as l'impression que les mecs qui gèrent ça adore tout réinventer à chaque version, allez les gars ont dégage tout et on refait.
Super-pratique pour donner les best-practices et les tunnings aux admins des machines ensuite.
La je parle de RH je suis sympa chez chez eux y a de la documentation au moins.
[^] # Re: C'est pas vendredi
Posté par Psychofox (Mastodon) . Évalué à 8.
Ouais enfin c'est de la mauvaise foi entre une 6 et une 6.5 ça ne change pas. Et entre une 5.0, une 6.0 et une 7.0 il s'est passé 3 à 4 ans si t'es pas foutu de renouveler tes connaissances tous les 3 ans et ajuster des docs c'est que t'as rien à faire dans ce métier.
À moins que t'utilises encore gopher, rsh et telnet parce que oh my god ces connards ont tout remplacé par http et ssh c'est trop compliqué t'y comprends plus rien. C'est ça ?
[^] # Re: C'est pas vendredi
Posté par claudex . Évalué à 6.
Surtout que sous FreeBSD, entre 2010 (RHEL 6) et 2014 (RHEL 7), il y a eu pkgng, bsdconfig, rctl…
« 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: C'est pas vendredi
Posté par Jiel (site web personnel) . Évalué à 6.
Cela dépend vraiment de ton coeur de métier. Si ton parc c'est des serveurs web, pas de souci, mais si tu bosses dans l'industrie, tu as définitivement besoin d'un support long. Monter une VM en 5 min en production, c'est bien quand on bosse dans une startup ou sur un site marchand, mais c'est pas ce que l'on fait quand on a besoin d'une application stable, testée, vérifiée pour gérer une centrale nucléaire ou lancer une fusée.
[^] # Re: C'est pas vendredi
Posté par Nico C. . Évalué à 1. Dernière modification le 16 décembre 2017 à 10:43.
Oui mais ça, ça entre dans ce que j'appelle "les cas très particuliers"…
[^] # Re: C'est pas vendredi
Posté par Jiel (site web personnel) . Évalué à 6.
L'industrie ce n'est pas si très particulier que ça, cela regroupe pas mal d'entreprise. C'est tout ce qui est infrastructure, transport, énergie, armée, construction, automobile etc.
[^] # Re: C'est pas vendredi
Posté par barmic . Évalué à 5.
Tu gère ça comment dans un gestionnaire de configuration du genre puppet/ansible/fabric/salt/… ? Des
seddans tous les sens ? Le fait d'avoir plusieurs fichiers permet d'utiliser des templates séparés (sans avoir à les concaténer par exemple.[^] # Re: C'est pas vendredi
Posté par Bapt (site web personnel) . Évalué à 6.
/etc/rc.conf.d c'est supporté aussi du coup ultra simple pour puppet & co
[^] # Re: C'est pas vendredi
Posté par Kwiknclean . Évalué à -3.
Je ne connais pas du tout le fonctionnement de ces outils (Je vois à quoi ils servent mais je ne m'en suis jamais servis), ce n'est pas ma fonction de livrer des OS.
Cela dit si les outils en questions ne sont pas capable d'aller écrire une ligne dans un fichier, faut se poser des questions …
[^] # Re: C'est pas vendredi
Posté par kna . Évalué à 5.
Tu bosses où ? Histoire que je n'y aille pas…
Ils peuvent. C'est juste plus sûr pour être idempotent d'avoir des fichiers séparés, soit le fichier est présent soit il ne l'est pas. T'es certain de ne pas t'être planté dans ta regex et d'insérer la ligne en double, ou une ligne avec ON et l'autre avec OFF.
Vraie question : comment tu gères plusieurs instances d'un même service sous FreeBSD ?
[^] # Re: C'est pas vendredi
Posté par Psychofox (Mastodon) . Évalué à 10.
Je crois que l'auteur de ce journal parle d'environnement pro qu'il en connait pas en se basant sur ses petites expériences de bidouilleur à la maison.
C'est un peu le noeud du problème.
[^] # Re: C'est pas vendredi
Posté par Kerro . Évalué à 2.
Je dirais même que c'est le neuneu du problème :-)
[^] # Re: C'est pas vendredi
Posté par Kwiknclean . Évalué à -1. Dernière modification le 16 décembre 2017 à 01:08.
Ma fonction est bien avant l'OS c'est de livrer des infras : Fibre/ Machine physiques/Chassis/ESX/Noeud proxomx/ par paquets de 10 ainsi que des gros volumes de données sur diverses technos de stockage et de m'assurer que tout ça ne coupe jamais.
Les déploiements de VM qui tournent dessus sont gérées par une autre équipe, c'est déjà la couche du dessus pour moi, ce n'est pas mon soucis. Donc puppet/salt/chef - accumule 10 techno pour avoir un outil fini pour livrer un Linux - j'en ai cure. (A ce propos les mecs des équipes Windows ont tout de même l'air vachement moins emmerdée et de bien moins se poser de question pour livrer leur machines … wé j'suis un peu dingue de dire ça sur LinuxFr)
Avant d'installer des VM faut monter des infras physique solide, le "cloud" c'est pas magique ça ne tourne pas dans tout seul dans le ciel, sinon tu te retrouves comme OVH avec des coupures sur des DC entier (tiens pas une dépêche pas un article ici bizarre …)
C'est pourtant con je bosse dans une boite ou il y a des projets super passionnant sur d’innombrable technos toute l'année et c'est pas de la SSII bien au contraire.
Vraie réponse : comme n'importe quel hyperviseur lambda, faut se renseigner un poil.
Demander au réseau de faire tomber les VLAN sur les switchs TOR, configurer les IP Virtuelles callés sur les VLAN, faire tomber les instances de jails, sur un bon DL560 avec commençons tranquille disons, 500Go de RAM tu dois pouvoir empiler un bon paquet de jail Nginx qu'écoutent tous sur le 443, j'aimerais bien me faire un petit POC d'ailleurs.
T'as l'air de croire que tout ça peut pas écouter le même port avec l'infra adéquate … t'es sur de faire de l'informatique dans ta boite tu répares par le mac de ton boss ?
[^] # Re: C'est pas vendredi
Posté par Psychofox (Mastodon) . Évalué à 7.
Ça n'a aucun sens ce que tu dis.
Je déploie des machines physiques comme des VMs de la même façon avec Foreman et ça se fait tout seul. Et c'est pas parce que tu fais du bare-metal sur de la machine physique que puppet (ou ses comparses) ne sont pas utiles. Ma config multipath elle est définie une fois pour chaque type d'OS / stockage et après elle se fait toute seule sur n machines physiques que je déploie.
Dans le monde Windows, Puppet commence à devenir très populaire pour piloter DSC. Donc ta remarque sur les collègues windows qui se démerde mieux ne veut dire qu'une chose : tu bosses dans une boite d'amateurs avec des méthodes de la préhistoire de l'informatique.
[^] # Re: C'est pas vendredi
Posté par Kwiknclean . Évalué à -7. Dernière modification le 16 décembre 2017 à 13:02.
Wé bon j'ai compris …
Vous êtes vraiment des amateurs, ce que vous dîtes n'existe pas, et n'a aucun sens si vous ne faîtes pas la même chose que moi.
[^] # Re: C'est pas vendredi
Posté par Kerro . Évalué à 7.
[insérez ici une image de facepalm]
[^] # Re: C'est pas vendredi
Posté par Marotte ⛧ . Évalué à 5.
C’est quoi le contraire d’une SSII ? Une société qui ne rend pas service à l’informatique ?
[^] # Re: C'est pas vendredi
Posté par barmic . Évalué à 1.
Si si ça se fait mais c'est pas très pratique ni lisible. Pour maintenir les configurations et avoir des diff lisibles dans mon gestionnaire de version, je préfère avoir les choses les plus simples possible (pas de shell entre autre), pas d'expressions régulières.
[^] # Re: C'est pas vendredi
Posté par ff9097 . Évalué à 7.
Vu comment est rédigé ton journal….
[^] # Re: C'est pas vendredi
Posté par Misc (site web personnel) . Évalué à 8.
En l'occurrence, c'est OpenVZ qui a fait le choix d'être en dehors du kernel.
Alors je pense que si tu avais monter un business, soit tu l'aurais fait sur la version communautaire, et dans ce cas, tout le monde t'aurais dit "ne pas prendre des trucs non mergés upstream". Soit tu aurais payé auprés de la boite derrière openvz, et le support est la pour toi.
Y a pas 3 firewalls sur FreeBSD ?
Parce que bon, tu parles de coherence, mais si j'ai le choix entre pf (ou un fork différent d'openbsd), ipfw, et ipf, ça fait un peu tache dans la partie "cohérence".
De surcroit, aucun n'est extensible comme le serait netfilter (ou du moins, pf n'avais pas l'air à l'époque ou c’était mon taf de faire du firewall, mais peut être que c'est le cas maintenant)
CARP est implementé dans FreeBSD 10:
https://www.freebsd.org/doc/handbook/carp.html
Je suis d'accord, c'est pour ça que j'utilise un outil de gestion de config qui fait une abstraction sur tout ça.
En prenant une distribution d'entreprise, tu as la doc. Vu que tu dit que Debian et RHEL, c'est kifkif, je vais donc comparé avec RHEL et surprise, tu as une tonne de doc traduite et vérifié sur
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/
Visiblement non. À un moment, faut se dire 2 choses. Soit tu as une idée de génie et le reste du monde ne sait pas ce qu'il fait. Soit tu as pas toutes les infos, et c'est pas une idée de génie.
La, tu as pas l'air d'avoir des idées de génie.
Ma foi, va demander à tes admins la raison de pas avoir fait la mise à jour. Je sais que c'est pas une question de cout, c'est le même prix dans un cas et dans l'autre. C'est peut être une question de temps, mais RHEL 7 est deja sorti y a longtemps, donc c'est pas vraiment "en regarde et on mets à jour plus tard".
Il est fort probable que la raison soit sans doute plus complexe que tu crois, et que FreeBSD ne change rien à ça.
[^] # Re: C'est pas vendredi
Posté par Arkem . Évalué à 9. Dernière modification le 14 décembre 2017 à 21:01.
Si je comprend bien ton explication, ce que tu n'aime pas dans Debian, c'est les différences quand on passe de RedHat 5.4 à RedHat 6.5 et inversement… j'ai bien tout compris?
[^] # Re: C'est pas vendredi
Posté par ff9097 . Évalué à 1.
Tu gères comment la dépendances entre les services au démarrage ? Le démarrage conditionnel ?
[^] # Re: C'est pas vendredi
Posté par Misc (site web personnel) . Évalué à 4.
Sur NetBSD et FreeBSD, c'est via des headers proches de la LSB (donc provides, requires) dans les scripts d'init.
Sur OpenBSD, ça n'a pas l'air de le faire, mais j'ai regardé en détail (j'ai juste fait du ssh et des rapides coups d'oeils à des scripts au pif).
Sur OpenBSD, via une fonction dans le script d'init (exemple, le script de démarrage de nfsd avec la fonction rc_pre() ).
Sur FreeBSD et NetBSD, tu déclares une variable start_precmd qui pointe vers une fonction , comme pour OpenBSD.
Au final, la différences est de savoir si tu exposes un langage de programmation complet, avec tout ce que ça entraine comme bons et mauvais cotés, ou pas. J'ai tendance à favoriser 'approche configuration plutôt que l'approche programmation, vu que tu arrives assez vite à rajouter de la complexité, et à avoir du code dupliqué partout. Mais je comprends aussi que des gens préfèrent l'autre approche.
[^] # Re: C'est pas vendredi
Posté par Albert_ . Évalué à 4.
Ouh la la tu t'avances beaucoup pour Docker je trouve. Actuellement dans le monde HPC cela regarde plus du cote de singularity et cela pour des raisons de securité (un HPC ne donnera jamais l'acces sudo a tous ses utilisateurs…).
[^] # Re: C'est pas vendredi
Posté par Cédric Chevalier (site web personnel) . Évalué à 3.
Pour le HPC, il y a aussi pcocc.
[^] # Re: C'est pas vendredi
Posté par Albert_ . Évalué à 3. Dernière modification le 14 décembre 2017 à 15:56.
Putain ca sent encore la merde avec des HPC utilisant une technologie et un autre une autre…
En meme temps ce n'est pas exactement la meme chose. Il y en a un pour des VM et l'autre pour des containers.
[^] # Re: C'est pas vendredi
Posté par dzecniv . Évalué à 2.
Containers + HPC ? Envie de citer Guix: https://matutine.gitlab.io/2016/09/26/gnu-guix-dans-un-environnement-de-supercalculateurs.html
[^] # Re: C'est pas vendredi
Posté par Exosta . Évalué à 2.
Firewalld ne fait pas l'affaire ?
[^] # Re: C'est pas vendredi
Posté par JPEC . Évalué à 3. Dernière modification le 14 décembre 2017 à 16:40.
Sur debian, iptables-persistent sert à ça.
[^] # Re: C'est pas vendredi
Posté par bubar🦥 (Mastodon) . Évalué à 2. Dernière modification le 14 décembre 2017 à 20:22.
++ Autre exemple : comment limiter la consommation RAM à 4G et le limiter sur le CPU, pour un utilisateur ? systemd sait faire :
systemctl set-property user-UID.slice CPUQuota=60% MemoryLimit=4096MVous connaissez un rapport plus simple / efficace ailleurs ?
On est loin de l'usage, au départ à la main dans /sys (pas moyen de retrouver mon vieux journal à ce sujet) des cgroups, puis avec des outils spécifiques simplifiant les tâches. Maintenant avec systemd une seule commande fait le job correctement.
[^] # Re: C'est pas vendredi
Posté par David Marec . Évalué à 8.
rctl -a user:joe:vmemoryuse:deny=1g[^] # Re: C'est pas vendredi
Posté par Misc (site web personnel) . Évalué à 3.
C'est pas non plus strictement équivalent, vu que system (et Linux) est aussi capable de limiter les I/Os, ce qui ne semble pas être le cas sur FreeBSD (en tout cas, pas sur FreeBSD 10 d'après la doc).
Je reconnait que FreeBSD a des trucs en plus, mais à choisir entre le fait de limiter le nombre de PTY et limiter le disque, j'ai quand même le sentiment que le partage du disque va plus souvent me servir.
[^] # Re: C'est pas vendredi
Posté par David Marec . Évalué à 3.
Pourquoi ça le serait ?
Dans un cas on appelle un outil conçus pour contrôler et limiter les ressources dans un autre
un outil conçu pour, euh, plein de trucs en fait.
Les I/Os ? quelles I/O ?
S'il s'agit des accès disques,
rctlle permet avecreadiops/writeiopsoureadbps/writebps.J'ai beaucoup de mal à voir la pertinence d'une limitation sur ces ressources, sauf peut-être dans le cas d'une jail ou
d'un process (et encore).
Si l'on veut vraiment partager son disque, on utilise des quotas.
[^] # Re: C'est pas vendredi
Posté par Misc (site web personnel) . Évalué à 2.
Autant pour moi, c'était pas dans la page de man de rctl sur le freebsd 10 que j'ai regardé.
L'idée principal, c'est si tu veux pas que tes backups fassent des I/O qui pourrait ralentir ton site web, ce genre de choses. J'aurais en effet tendance à dire que si tu es à ce niveau de détails, tu as sans doute plus besoin de racheter une machine ou des disques plus rapides, mais ça ne parait pas inutile.
[^] # Re: C'est pas vendredi
Posté par Le Gab . Évalué à 0. Dernière modification le 15 décembre 2017 à 00:58.
C'est tout de même pas très beau ni intuitif, non? Que dire en plus de l'usage de minuscule/MAJUSCULE ?
EDIT: L'exemple de David qui a répondu juste avant moi est juste limpide:
rctl -a user:joe:vmemoryuse:deny=1g
Sérieusement, les gars, ça juste claque. :)
[^] # Re: C'est pas vendredi
Posté par aiolos . Évalué à 6.
Quand tu dis
et que tu sors
comme exemple ultime, je m'interroge quand même : autant dans la première je vois bien ce que ça fait même si je ne connais pas trop systemd, pour la deuxième, ben autant je vois bien mieux à quel user ça s'adresse, pas contre les limites de 1096M sur la mémoire et les 60% de CPU, je sèche…
M'en fous, je ne suis pas maniaque… Et j'ai fait du java :-P
[^] # Re: C'est pas vendredi
Posté par Le Gab . Évalué à 1.
Rien à voir avec de la psychorigidité, tu fais comment pour retenir tout ça??? Ah, un coup de man à chaque fois que tu veux faire cette action? Du tab-tab complétion? systemctl set-tab-tab.. j'ai droit à 2 suggestions:
set-default
set-environment
Pourtant si je tapes "systemctl set-property"… j'ai droit à un "Too few arguments"… J'essaye avec "systemctl set-property --help", déjà on ne sait jamais si help doit être une commande ou une option aux sous commandes systemctl mais au final ça me renvoit vers le "Usage" de la commande systemctl. YAY!
J'ai bien entendu invoqué man mais je vous invite à le faire, c'est lumineux! Du coup, ben, j'ai besoin de chercher les infos sur le net, frictions au possible.
La commande rctl est bien plus intuitive pour un sysadmin qui ne cherche pas à faire du code Meta ou qui ne veut pas dégainer un IDE spécifique à base de Java ou Electron pour exécuter des commandes ou rédiger des scripts. Je t'invite à lire son man également, c'est sans appel.
Quant aux "shares" cpu en %, ça ne semblent pas implémentés sous FreeBSD, il n'y a qu'une capacité temporelle (cputime). Je ne suis pas utilisateur FreeBSD hors appliances, ne me demande pas comment faire et pourquoi c'est pas fait.
Je reconnais quand cet FreeBSD fait des choses bien mais pour dans ma vie de tous les jours, j'apprends à souffrir avec systemd car je suis utilisateur de GNU/linux depuis bien trop longtemps pour changer et systemd apporte néanmoins certaines solutions a des problèmes existants, ne serait-ce que par une certaine uniformisation, enfin, c'est plutôt une soumission à "la méthode Red hat" qu'un soucis d'uniformité, ça ne me pose pas de problème ceci dit tant qu'on s'aligne.
[^] # Re: C'est pas vendredi
Posté par Misc (site web personnel) . Évalué à 5.
Comme tout le reste, tu lit la doc, elle est la pour ça.
Les devs passent leur temps à chercher des trucs sur Google, les sysadmins aussi. Croire que ça n'arrive pas, ou que ça n'est pas la norme, c'est malsain.
Malsain parce que c'est faire croire que les ingés ont des capacités mémoriels au dela du raisonnable, et faire douter les gens qui ont des capacités normales en se disant "j'arrive pa sà retenir, je suis pas normal", ou pour les plus égocentriques "j'arrive pas à retenir, le soft doit être de la merde".
Je dit pas qu'on doit pas faire un effort pour la cohérence, mais non, on peut pas tout retenir, et c'est normal, et c'est pas requis. Savoir que tu peux limiter le cpu devrait suffire.
En l'occurrence, je pense que tu te trompes.La page de man parle de "pcpu":
pcpu %CPU, in percents of a single CPU core
[^] # Re: C'est pas vendredi
Posté par Le Gab . Évalué à 0.
Te rends-tu compte que ni la complétion ni le man ne m'ont aidé???
Je n'ai pas dit ça, je recherche sur Google quand la solution du man et de la doc officielle ne suffisent plus, j'arrive encore à aller sur le site/forum du projet avant de googler: "comment c'est qu'on fait ça?".
Mais je m'attends à ce que la documentation d'un composant système ne nécessite pas internet.
Et si tu trouves ça exceptionnel, ben MERDE.
La mémoire n'est pas critique, il y les capacités de déduction logique et une certaine intuition pour quiconque ayant plus de 10 années d'administration système - vrai pour les autres domaines d'ailleurs.
Il n'y a jamais eu de "casse" dans les commandes systèmes sous Unix/Linux*.
Je rappelle, je suis principalement utilisateur de Linux ça n'empêche pas de reconnaître le mauvais travail chez "soit" et le bon travail chez les autres, fussent-ils freebsd, osx, windows.
C'est dingue, on en est à ne me plus tolèrer la critique sur systemd alors qu'on ne rejete aucunement toute le framework.
…
* OS X se permet peut-êre ce genre de windowserie.
[^] # Re: C'est pas vendredi
Posté par claudex . Évalué à 2.
Je ne sais pas quel man tu as mais sur ma Debian 9. La section
set-propertyrenvoit verssystemd.resource-control(5)qui liste tous ces paramètres. Accessoirement, la completion complète bien avecset-propertyet le nom du service mais pas les options listées dans la man.« 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: C'est pas vendredi
Posté par Misc (site web personnel) . Évalué à 4.
On a pas du lire la même page de man.
set-property NAME ASSIGNMENT...
Set the specified unit properties at runtime where this is
supported. This allows changing configuration parameter properties
such as resource control settings at runtime. Not all properties
may be changed at runtime, but many resource control settings
(primarily those in systemd.resource-control(5)) may. The changes
are applied instantly, and stored on disk for future boots, unless
--runtime is passed, in which case the settings only apply until
the next reboot. The syntax of the property assignment follows
closely the syntax of assignments in unit files.
C'est la page de man de systemctl sur une RHEL 7. On peut pas dire que ça soit la dernière version ou quelqu'un aurait vite fait corriger la doc pour te contredire, c'est une version 219, qui date quand même d'il y a un ou deux ans. Et parce que je part pas du principe que tu mens, j'ai aussi vérifié sur une Fedora, et la page de man dit grosso modo la même chose.
Encore une fois, je veux bien reconnaitre qu'il y a beaucoup à lire, parce que il y a beaucoup de features, mais dire "la page de man ne m'a pas aidé" me semble être un raccourci qui n'a pas l'air de resister à un examen rapide de la dite page de man, sauf si tu as eu une page de man différente.
Foutaises.
La migration de ifconfig vers ip a commencé y a plus de 10 ans.
L'interface de firewall sous Linux a changé 3 fois avant d'arriver à iptables/netfilter et va encore changer avec nftables.
Solaris a eu des changements de systémes d'init et des tas de commandes nouvelles avec Solaris 10 (sauf erreur de ma part).
Apt-get est devenu Apt sur debian (ou Aptitude pendant un temps, bien que les 2 vont sans doute cohabiter pendant longtemps). Yum est devenu DNF.
Et même au niveau du noyau, quand j'ai commencé, c'est sur /dev/hda1 que j'avais mon bootloader lilo, avec un /dev statique remplacé par devfs assez rapidement.
Ou sur FreeBSD, le fait d'avoir intégré zfs a forcément entrainé des changements de commandes pour gérer les partitions.
C'est bien la preuve que c'est rien de personnel que de répondre sur le point précis sans se préoccuper du reste.
[^] # Re: C'est pas vendredi
Posté par claudex . Évalué à 4.
Je crois qu'il veut dire "casse" des caractères (majuscules/minuscules).
« 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: C'est pas vendredi
Posté par Misc (site web personnel) . Évalué à 4.
En effet, si c'est le cas, ma réponse serait différente.
A savoir qu'il y a toujours pas de changement de casse dans les commandes. La commande systemctl est en minuscule. Si je m'en tiens à l'exemple, le reproche est sur l'argument, mais dans ce cas, c'est cohérent parce que l'argument est un bout de configuration, une option dans les fichiers .services et autres.
C'est la propriété "CPUQuota" qui est changé. Et la, je pense que personne ne va dire "on a jamais eu de CamelCase dans la configuration d'un soft", parce que c'est faux. L'exemple le plus parlant serait Apache, mais je peux citer aussi OpenSSH comme logiciel présent dans le systéme de base de tout les BSD.
Les commandes utilisent aussi la casse pour avoir plus d'options (entre -C et -c pour tar), c'est donc pas non plus rare.
Alors oui, du coup, l'usage du CamelCAse déborde vers la CLI, et je comprends que ça puisse déranger les gens, sans doute parce que comme tout compromis fait, quelqu'un ne va pas être 100% satisfait.
Il y a sans doute des gens qui préfèrent tout en minuscule parce que c'est plus facile à retenir, et d'autres qui préfèrent en CamelCase parce que c'est plus facile à lire. Mais tu peux difficilement satisfaire tout le monde (sauf à supporter tout, mais d'un coup, tu va avoir de l'inconsistence dans la doc ).
De la même façon que tu ne peux pas avoir un truc rapide à taper comme "cp" et en même temps avoir un truc clire comme "copy".
[^] # Re: C'est pas vendredi
Posté par David Marec . Évalué à 6.
Si vous êtes capable de comprendre l'une vous êtes capable de comprendre l'autre, sans déconner.
Le plus important d'ailleurs, n'est il pas, non pas de la lire, mais de l'écrire;
de retrouver facilement la commande ?
Je vous invite à la lire la page de
man systemctlpour la trouver.Astuce: en fait, c'est dans
man systemd.resource-control… et en partie danssystemd.slice…A comparer avec le
man rctl.C'est parce que je n'ai pas pris la peine d'écrire la commande pour le cpu ?
# FreeBSD
Posté par Psychofox (Mastodon) . Évalué à 10.
J'ai beau être relativement pro-BSD (mais pas anti-debian/linux non plus) mais force est de constater que FreeBSD c'est trop DLA MERD YA PAD'KOREKTEUR ORTOGRAFIK.
Voilà comme ça j'ai répondu à de la mauvaise foi par de la mauvaise foi.
# Du coté de chez Fedora
Posté par Yuul B. Alwright . Évalué à 4.
[^] # Re: Du coté de chez Fedora
Posté par Yuul B. Alwright . Évalué à 1.
Et j'ai oublié de dire, pour les mises à jours, le retour en arrière dans les versions en cas de foirage d'une version est prévu.
[^] # Re: Du coté de chez Fedora
Posté par fredoche . Évalué à 1.
Parait que Modular Server est dead pour F27. Je sais ni pourquoi, ni s'il y aura un 2eme round. Si qqun passe avec plus d'info que ce qui a filtré sur fedora magazine, ça intéressera du monde je pense.
[^] # Re: Du coté de chez Fedora
Posté par Renault (site web personnel) . Évalué à 4.
Non il n'est pas mort en tant que tel. Mais l'objectif pour cette version n'est pas atteinte.
Il faut bien comprendre que l'aspect modulaire, le découpage du système en différentes couches, etc. est un objectif de long terme, amorcé depuis Fedora 21. Seulement Fedora 27 devait être une grande étape (et de nombreuses choses ont été faites en ce sens d'ailleurs) mais il reste du chemin.
De ce que j'ai compris une partie du système va être revu, ce qui explique l'annulation pour ce cycle. Notamment l'objectif est d'avoir accès aux dépôts normaux et modulaires, ce qui n'était pas je crois prévu dans la conception précédente. Comme c'est un objectif complexe, d'ici sa réalisation finale il faut s'attendre à quelques essais / erreurs du genre avant d'aboutir.
# LXC
Posté par Yuul B. Alwright . Évalué à 3.
Pour LXC, je ne suis pas fan des templates qu'il faut tout le temps construire et qui parfois font peur (installation de paquets rpm sans vérification de la signature). Les développeurs de LXC ne pourraient pas faire un système qui télécharge des images prêtes à l'emploi?
[^] # Re: LXC
Posté par smumu . Évalué à 2. Dernière modification le 14 décembre 2017 à 14:30.
Si tu utilises le template "download" lors de la création, tu as le choix de la distro, la version et l'architecture. C'est ce que j'utilise (pas le choix quand on fait du unprivileged), toutefois je crois savoir que si tu les crées en tant que root, tu as aussi accès à quelques templates tous prêts. Un petit
man lxc-create: la partie-t, --template templateindique leur emplacement (chez moi,/usr/share/lxc/templates).Et sinon pour les images prêtes à l'emploi : c'est exactement ce que fait Docker (mais peut-être que justement ton commentaire avait pour but d'y faire référence de manière détournée ?).
# RHEL/CentOS
Posté par WhiteCat . Évalué à 9.
Sur RHEL/CentOS, si par exemple je fais un "yum update httpd" ça va me mettre à jour que Apache aussi hein. Ça va pas m'installer une màj du noyau ou que sais-je encore.
PHP 5.4 de base dans CentOS 7. Support de 10 ans.
Ben tu utilises RHEL/CentOS justement. Si tu déploies une appli PHP dessus, elle marchera pendant 10 ans au moins.
Et puis si tu as besoin d'autres versions de PHP en parallèle, tu peux installer PHP 5.6, 7.0 et 7.1 en même temps via un autre dépôt nommé "Software Collections", officiellement supporté par Red Hat. La durée du support pour chaque version est de 3 ans seulement par contre pour ces versions.
C'est aussi limpide que de la vase ton truc.
On utilise systemd. Fin de discussion.
Professionnellement, j'évite de déployer un OS (fusse FreeBSD, Ubuntu ou Debian) sur un serveur physique (ou virtuel d'ailleurs…) qui n'est pas validé sur un OS en particulier. Sinon comment garantir la stabilité du truc.
Les constructeurs (HPE, Dell, Lenovo, etc.) garantissent la compatibilité de leur matos sur certaines distributions (généralement RHEL et SUSE, parfois aussi des BSD) et réciproquement (Red Hat fournit un catalogue de machines validées).
# Encore une rupture
Posté par smumu . Évalué à 2.
Ça me rappel un autre journal qui évoquait la séparation d'une moule avec une distro qu'il a utilisé si longtemps.
Bon par contre, le divorce semblait plus paisible, ou du moins, était présenté de manière plus posée.
Et sinon, je pense que ce journal aurait pu convaincre plein de personnes des (nombreux) avantages de FreeBSD, mais cette présentation … On dirait juste un coup de gueule de quelqu'un qui n'a pas creusé (alors que je suis sûr que tu as cherché et comparé avant de sortir tous ces arguments).
Personnellement je me pose deux questions sur FreeBSD qui font que la transition me rebute un peu (et j'avoue, je n'ai pas vraiment cherché de réponses récemment en dehors de quelques articles, ma flemme gagne toujours) :
- niveau support matériel, on en est où ? J'ai du matériel relativement récent (< 2 ans) et j'ai ouïe dire que ça pouvait ne pas passer (mais là on parle plus d'utilisation desktop c'est vrai) ;
- je travaille sur différents projets et j'utilise des conteneurs LXC unprivileged (et j'en suis très satisfait). Les jails me font de l'œil, toutefois est-ce que je pourrai installer une Debian/Ubuntu dans une jail, compatible avec les binaires Debian GNU/Linux habituels ?
Ah et :
J'imagine qu'actuellement la puissance des jails n'a pas pu être égalée par une solution qui serait adoptée par tout le monde. Pour moi LXC s'en sort très bien mais personne ne s'y intéresse parce que Docker (que je n'apprécie pas nécessairement mais qui a le côté très pratiques des registres d'images par exemple) a le vent en poupe. Quoique, KVM ressort pas mal non plus …
[^] # Re: Encore une rupture
Posté par Kwiknclean . Évalué à 1.
Oui je suis parti en rupture, d'ailleurs j'ai livré du boulot pas terminé, mais j'y reviendrai :-)
Le support matériel, ça dépend de ton usage, mais pour un environnement de bureau, faut aimer se faire du mal quand même … j'ai jamais tenté l'aventure.
La je parlais d'un environnement purement cli/serveur (je précise sur mon desktop je suis sur Linux Mint !)
C'est vrai que j'ai toujours réalisé des installes sur des bécanes qui dataient un peu. Mais à mon sens ça ne devrait pas poser plus de problème que ça (2 ans c'est pas l'âge de la dernière release), les instructions CPU modernes notamment pour virtu sont supportées les contrôleurs réseaux modernes également.
La ou ça a du retard c'est surtout sur les archi type ARM ou y a encore un peu de taf, mais ça avance.
Je précise que ZFS n'est absolument pas obligatoire, je ne m'en sers d'ailleurs pas sur mes installations, trop consommateur de RAM et inutile pour moi, je veux du super-light, et je préfère avoir une bonne politique de backup qu'un super FS.
Je trouvais ça trop bordélique à l'époque déjà oui,
Le mieux est de te monter ça dans une VM est de maquetter non ?
Niveau jails tu partages la base de ton système avec ton OS hôte, comme pour LxC.
Y a encore quelques limitations, tu ne peux pas faire de limitation CPU/RAM par exemple je crois (mais ça va arriver !)
Il y a effectivement un projet pour faire tourner Debian dans une Jail BSD, j'avais boutiqué un peu à l'époque, tu as accès à tout les packets Debian ( avec apt-get), tu t'y crois une fois à l'intérieur : https://wiki.debian.org/Debian_GNU/kFreeBSD/Jails
Sinon pourquoi ne pas reproduire ton environnement directement dans une jail ?
Tu as Java, PHP, Nginx, Python3 … comme sous n'importe quel OS.
Ensuite tu joues un peu avec les templates jail par exemple et hop tu construit tout ça à la volée. Tu peux même faire tourner des jails à l'intérieur de jails ..
Les jails sont plus proches des LxC que de Docker tout de même, je ne sais pas ou en est LxC mais à l'époque je trouvais ça bien complexe à mettre en place surtout la partie réseau … ça a du évoluer depuis, j'espère.
Il y a également la Virtu plus "lourde" avec Bhyve mais pas sur que ça réponde à ton besoin, ce n'est plus la même chose.
[^] # Re: Encore une rupture
Posté par palm123 (site web personnel) . Évalué à 2.
Dans cette optique tu as Linuxkit, tu crées une mini distrib Linux qui fait tourner un process (un serveur SSH par exemple), si tu fais un
ps -eftu vois
init
sshd
ton_process_connecté
et c'est tout
https://github.com/linuxkit/linuxkit
ウィズコロナ
[^] # Re: Encore une rupture
Posté par smumu . Évalué à 2.
Si j'aime beaucoup ce que j'ai côté serveur, j'essaie en général d'avoir la même chose côté desktop si c'est pertinent.
En l'occurrence, ça le serait parce que l'idée serait d'avoir la même manière de configurer mon PC de bureau et mes serveurs de backup/media/whatever.
Après, quand c'est impossible … Tant pis !
J'ai un appareil ARM sur lequel je peux installer l'OS de mon choix mais celui-ci reste sous Debian parce que … Meilleur support fournisseur. Puis la communauté aussi.
Donc la question de l'architecture se règle par : full AMD64 !
Je parlais surtout niveau, effectivement, réseaux mais aussi graphiques (notamment dès qu'on a deux CG c'est déjà un peu le bazar sur GNU/Linux alors j'imagine pas pour BSD) et éventuellement instructions processeur (mais bon à ce niveau c'est de l'opti invisible).
C'est pour ça que j'utilise exclusivement LXC et Docker à l'heure actuelle : le premier pour faire des stacks complètes (genre toutes les dépendances d'un projet dans un seul conteneur dont l'OS est généralement imposé par le lead du projet, enfin là je parle de problématiques de prestataire/client surtout) et le second pour les projets qui l'utilisent (puis bon, c'est quand même pratique aussi pour faire des tests vite-fait avec des versions précises de tel ou tel soft).
Effectivement, je devrait prendre le temps de tester un peu.
Je sais que c'est le même principe (même kernel que le host), c'est pour ça que j'utilise LXC : c'est performant et léger. Comme pour les jails effectivement !
Par contre, il me manquerait de ne pas pouvoir limiter la RAM et le CPU, chose que je fais couramment sur mes conteneurs parce qu'il m'arrive d'en avoir plusieurs qui tournent en parallèle (bon, avec 16Go de RAM, généralement on est pas mal, mais un processeur de PC portable, même un Core i7, ça reste un peu bridant).
J'avais vu un peu cette histoire, toutefois il me semble que Debian GNU/kFreeBSD est abandonné, non ? Il n'y a pas d'image avec ce kernel pour Stretch …
Et est-ce qu'il est compatible avec les binaires Debian GNU/Linux ? Car c'est bien ma problématique : par exemple, j'ai un projet sur lequel on me fournit une lib compilée pour du GNU/Linux (et la source n'est pas disponible, sinon ce n'est pas drôle).
Pour la raison évoquée juste au-dessus du coup (librairie compilée pour GNU/Linux).
Je fais tourner du Docker dans du LXC, mais j'ai pas encore tenté LXC dans LXC. Mmmmh tiens j'ai du temps libre ce week-end … :)
Alors je ne saurai pas te dire par rapport à "l'époque". Mais personnellement j'ai suivi le wiki de Debian (pour Stretch) : quelques fichiers à toucher mais ça passe.
J'ai mes conteneurs unprivileged qui ont chacun un sous-réseau avec une IP fixe, et je modifie mon
/etc/hostspour faire pointer des domaines qui finissent en.localsur les conteneurs de mon choix. Ça marche plutôt bien.Tu peux aussi faire en sorte que le réseau soit le même que pour le host mais dans ce cas tu partages les ports avec ton système host, chose que je ne veux pas. Et tu expose tous les ports de ton conteneurs au réseau sur lequel tu es connecté (alors que dans mon cas, seul l'hôte peut taper sur les conteneurs).
Bien sûr tu peux mixer ces deux méthodes, avec des conteneurs en sous-réseaux et d'autres sur le réseau de ton hôte. Je n'ai jamais testé mais aussi tu dois pouvoir donner un même sous-réseau pour plusieurs conteneurs (je ne vois aucune raison qui rendrait ça impossible).
J'imagine que les jails me permettraient de faire pareil, surtout depuis le temps qu'elles existent elles doivent bien avoir une configuration réseau béton. Pareil, il faudrait que je me penche dessus.
Oui effectivement, le jour où j'en arrive là, j'aurai sûrement des problématiques plus impressionnantes que les projets clients qui utilisent des libs spécifiques et propriétaires. Mais j'avais suivi un peu les actualités sur Bhyve il fût un temps, ça a l'air intéressant.
J'ai aussi un peu regardé vmm de l'ami OpenBSD (qui me fait de l'œil je l'admets), ça m'a l'air plus simpliste (mais encore très basique).
[^] # Re: Encore une rupture
Posté par Psychofox (Mastodon) . Évalué à 4.
https://www.freebsd.org/doc/handbook/security-resourcelimits.html
[^] # Re: Encore une rupture
Posté par smumu . Évalué à 2.
Ah voilà exactement ce dont j'ai besoin en terme de limites !
Bon, il semble qu'il manque juste une chose : le nombre de CPU autorisés (chose que les cgroup, et donc LXC, permettent de faire en précisant les cœurs autorisés pour un conteneur). Mais ça permet déjà de brider l'essentiel de la jail.
Merci !
[^] # Re: Encore une rupture
Posté par David Marec . Évalué à 4.
En ce qui concerne
rctlon peut définir une règle sur le pourcentage de CPU.Si l'on veut affecter un ou plusieurs CPU à une jail, c'est le rôle de
cpuset.
[^] # Re: Encore une rupture
Posté par MTux . Évalué à 5. Dernière modification le 15 décembre 2017 à 09:38.
Oui LXC marche bien mais je lui trouve encore quelques manques:
Dans un container, en faisant df ou htop, tu vois la charge de l'hôte, pas celle de ton container. Ubuntu essaie de colmater ça avec LXD/LXCFS, je ne sais pas ce que ça donne.
Le root du container est aussi root sur l'hôte, je ne sais pas si c'est encore d'actualité et ça peut être contourné par le mode unpriviliged.
Le réseau bridgé sous Linux c'est chiant, tu peux pas juste démarrer ton container en lui disant "met toi en bridge", non il faut monter un pont avec brctl, puis déplacer l'IP de ton serveur dessus (elle peut pas rester sur eth0), y'a pas ce problème sous FreeBSD avec les jails. RedHat essayait de changer ça avec macvlan mais je n'ai jamais réussi à le faire marcher.
A vérifier mais pas sûr qu'on puisse qu'on puisse manipuler les interfaces réseau et le pare-feu depuis un container LXC (par exemple créer un tun0/tap0 pour OpenVPN). Avec les jails on peut.
A une époque les images de distributions Linux dans LXC avaient un OpenSSH déjà configuré et démarré, ce qui fait qu'elles avaient toutes le même fingerprint. Je ne sais pas si c'est encore d'actualité.
Après Docker c'est vraiment pas le même usage selon moi, c'est fait de pour de l'applicatif pur. Ceux qui l'utilisent pour faire des VPS le détournent très largement. Rien que le fait qu'il n'y ait pas de système d'init dans docker devrait être un indice pour eux…
[^] # Re: Encore une rupture
Posté par smumu . Évalué à 2.
Pour df, effectivement tu vois les partitions de l'hôte.
Toutefois, je viens de lancer un htop, et je n'ai que les process de mon conteneur. Bon, dans le doute j'ai aussi lancé top, même résultat : aucun process host.
Par contre effectivement, le load est le même si tu parles de ça (à vrai dire je n'avais jamais remarqué ce "problème").
N'étant pas sur Ubuntu et utilisant LXC en première version, je ne saurai dire si ça évolue selon l'OS et/ou la version.
À ma connaissance c'est toujours d'actualité et un problème classique des conteneurs (Docker a le même) : si tu arrives à sortir du conteneur, tu seras l'utilisateur qui l'a lancé.
Docker est toujours en root, pour un truc de plus en plus utilisé en production j'ai toujours trouvé ça moyen (je l'utilise très régulièrement mais si j'avais le choix, je tenterai de regarder ce qu'il se passe ailleurs). Après, peut-être que les développeurs n'ont pas trouvé la manière propre de faire des Docker unprivileged ?
LXC peut effectivement être utilisé en unprivileged (ce que je fais tout le temps), toutefois cela signifie qu'en arrivant à sortir du conteneur et que l'utilisateur qui a lancé le conteneur a beaucoup de droits (ou pire : peut utiliser des commandes sudo sans mot de passe), on retombe un peu dans un problème similaire (mais normalement moindre).
J'utilise lxc-usernet comme indiqué dans le wiki Debian pour les conteneurs unprivileged et ça m'a paru assez simple.
Après je ne sais pas ce que ça donne en privileged, si quelqu'un a testé je suis preneur !
J'aimerai pouvoir te répondre … Mais là je vais juste spéculer : je pense que tu peux créer des interfaces et gérer un pare-feu interne au conteneur en question.
Tu éveilles ma curiosité. Peut-être que cet article donne quelques pistes malgré son âge.
Là encore, les conteneurs unprivileged te forcent à utiliser un template téléchargé et il semble que le serveur SSH ne soit pas toujours installé par défaut (dans le cas d'un template Debian 9 amd64, je n'ai pas de serveur SSH).
Toutefois en lisant le template lxc-debian fourni pour créer des privileged, il semblerait que le paquet openssh-server soit installé pour cette même distro (petite déception je dois avouer …).
Je plussoies largement. D'ailleurs les concepteurs n'ont jamais caché que Docker est normalement prévu pour faire tourner une application par conteneur.
Je n'ai jamais vu de VPS basés sur Docker jusque là (plus du OpenVZ et du KVM), ça existe vraiment ? Décidément, il y aura toujours des personnes pour enfoncer des vis avec un marteau …
# Merci pour tout ton amour mon cher journal.
Posté par Kwiknclean . Évalué à 5. Dernière modification le 14 décembre 2017 à 16:21.
J'ai bien compris que ce sujet soulevait les passions.
D'ores et déjà je tiens à m'excuser :
Des choses se mélangent un peu du coup c'est regrettable.
Mais ne t'en fais pas je te promets de revenir très rapidement expliquer très en détail mon point de vue, mon vécu et mon analyse basé sur mon expérience perso, des arguments et des faits.
Pour que l'on puisse débattre dans la galanterie dont je suis accoutumé sur ce forum.
Et non il ne s'agissait pas de troller, j'ai vraiment dégagé Debian de mes "serveurs persos" …
Je n'en ai pas 50 non plus, mais quand je dois installer un serveur en CLI à l'arrache (chez moi, au taf je ne fais pas ce que je veux malheureusement).
Mon choix ne va plus instinctivement vers Debian comme c'était naturellement le cas à une époque.
Voilà comme ça c'est mieux.
A très vite journal.
# Joli coup de gueule
Posté par microlinux (site web personnel) . Évalué à -2.
T'inquiète pas pour le côté pas fini. Y'a justement ce côté brut de décoffrage que l'on retrouve par exemple dans le tout premier Nirvana (je parle de Bleach, hein). Le chaos contrôlé, mais ça envoie du steak derrière.
J'ai longtemps flirté avec FreeBSD sans jamais l'utiliser en production. Je ne suis pas toujours maître du hardware, je prends ce que les clients me balancent à la gueule, du coup je préfère utiliser Linux (CentOS, Slackware, Debian, Ubuntu, peu importe).
Un jour peut-être. Ton post m'a redonné un peu envie, donc c'est bien.
Un gentil bonjour de la garrigue gardoise.
Dyslexics have more fnu.
# En prévision de Vendredi
Posté par Misc (site web personnel) . Évalué à 3.
En voyant le programme du 34C3, j'ai vu https://fahrplan.events.ccc.de/congress/2017/Fahrplan/events/8968.html
Et je me suis dit "ça a l'air cool comme présentation, mais est ce que par hasard, je l'aurais pas déjà vu ?". Et oui, la présentation a déjà été donné à Defcon 25:
https://media.defcon.org/DEF%20CON%2025/DEF%20CON%2025%20presentations/DEFCON-25-Ilja-van-Sprundel-BSD-Kern-Vulns.pdf
Du coup, je laisse les gens tirer les conclusions, c'est sur les slides (teaser: 115 bugs de sécu en 90 jours)
[^] # Re: En prévision de Vendredi
Posté par claudex . Évalué à 6.
C'est bon, on a déjà tiré les conclusions 😀 https://linuxfr.org/users/patrick_g/journaux/les-bsd-sont-ils-tous-egaux-devant-les-bugs
« 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
# Oui et non
Posté par David Demelier (site web personnel) . Évalué à 8.
Je suis aussi adepte de FreeBSD et n'utilise que ça en serveur, mais je peux pas dire qu'il n'y aucun défaut. En fait il y en a plein.
Les ports ne sont pas versionnés
Ça pose pas mal de problème quand tu veux mettre à jour ta machine. Par exemple, chez OpenBSD les ports sont faits pour aller avec une version précise de ton OS. Du coup chez FreeBSD on peut se retrouver avec des conditions de versions dans les ports les rendant beaucoup plus compliqués à tester. Mais ils ne souhaitent pas changer ça pourtant c'est clairement ce qu'il faudrait faire. Pire encore, à chaque mise à jour, vous ne pouvez pas être sur que tout va encore fonctionner. Exemple : j'utilise etherpad qui dépend de nodejs. J'avais une version 6 de node.js et en mettant à jour mes ports (dans une poudriere, je suis pas masochiste), je me suis retrouvé avec une version 7 et etherpad ne fonctionnait plus. Avec un système de version par OS, ça ne serait jamais arrivé. Alors oui de temps en temps on rajoute des ports comme www/node6, www/node7 etc. Mais ce n'est pas non plus la solution.
Le support matériel est anémique
Non franchement, oubliez votre thinkpad de 2016, c'est même pas la peine d'y penser.
Les ports ne sont pas testés
Beaucoup de committers ne testent pas leur ports avant de les mettre à jour. En fait, ils le mettent à jour, vérifient que ça compile et commit.
Sauf que je me suis déjà retrouvé dans ce genre de cas :
Pas mal d'incohérences
Bien que ce soit purement esthétique, il y a quand même pas mal d'incohérence chez FreeBSD. Exemples bêtes, en général on aime bien concevoir un service sous forme serviced, servicectl. Chez FreeBSD on a préféré le suffixe control, du coup on a du mélange
C'est pas grand chose, mais j'aime le souci du détail :)
C'est à peu près pareil avec les fichiers de conf, ils ont pas toujours la même syntaxe (blacklistd.conf, jail.conf, devfs.conf).
Le bluetooth
Oui j'utilise des technologies comme le bluetooth. En fait sur FreeBSD je pense qu'il devrait être complètement supprimé. Le mainteneur ne travaille plus dessus et le support est plus que dérisoire.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Oui et non
Posté par Kwiknclean . Évalué à 2.
J'avais prévu d'aborder ces points là et techniquement de finir par les "cons", une note de synthèse plus mesurée histoire de faire comprendre que j'suis anti rien du tout et de bonne foi.
Parce que comme tu le notes y en a quand même quelques points …
Je rajouterai que "le retard" sur la virtualisation et les technologies de clustering H/A qui sont tout de même un peu limitées, UFS qui commence à dater un peu en alternative de ZFS qu'est "overkill" à mon sens pour un usage perso …
Ca sera pour le prochain journal :-)
[^] # Re: Oui et non
Posté par Lawless . Évalué à 2.
Les ports ne sont pas testés et comment pourrait-il en être autrement ? Combien y a-t-il de développeurs contribuent à FreeBSD, quatre cents développeurs auraient accès au dépôt des sources qui peuvent aussi pousser des correctifs de tiers. Corrigez moi si je me trompe, les développeurs FreeBSD développent tout, le noyau, la bibliothèque C, les ports, les paquets, … ? En face chez Debian il y a plus de mille développeurs qui ne font que de l'empaquetage et sont guidés par une charte et un contrat social.
Pour moi l'intérêt principal de FreeBSD reste ZFS. J'ai rencontré beaucoup de problème avec le système de paquets de FreeBSD, mais bon je ne suis pas un spécialiste de ce système. Exemple, refus d'installation car même UID déjà utilisé par un autre paquet, mauvaise gestion de dépendances (l'installation d'un nouveau paquet nécessitait la mise à jour d'un paquet déjà installé), logiciel plantant au démarrage (certaines versions de Samba), pkg ne fonctionnant plus car mon système était en 10.2 et que les paquets était compilés pour la 10.3, bug du service SNMP qui gèle régulièrement ou qui retourne une erreur de segmentation (corrigé par une désinstallation et une réinstallation du paquet), …
La principale différence entre Debian et FreeBSD c'est que Debian ne pousse pas de nouvelle version du logiciel, si vous avez Vim 8.0 sur votre système vous resterez avec cette version, plus les correctifs que Debian estime nécessaire, alors que FreeBSD peut très bien vous installer Vim 8.1 lors d'une prochaine mise à jour et Vim 8.2 lors de la prochaine. FreeBSD n'a pas hésité aussi à retirer Samba 3.6 de ses dépôts.
Que FreeBSD propose des ports (logiciels qu'on peut compiler avec des options) et des paquets binaires à installer est une bonne chose. Cependant la mise à jour de paquets avec pkg upgrade ou même l'installation d'un paquet avec pkg install peut réinstaller une nouvelle version du paquet et effacer le port compilé avec les bonnes options.
[^] # Re: Oui et non
Posté par claudex . Évalué à 4.
Ce n'est pas tout à fait vrai. Déjà, il y a ceux qui développent les outils Debian (dpkg, apt, reportbug…), ensuite, il y a ceux qui développent des projets sans que ça rentre dans le cadre d'être développeur Debian.
« 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: Oui et non
Posté par Kwiknclean . Évalué à -1.
Nous n'avons certainement pas le même usage, je n'utilise pas ZFS et je trouve pas mal d’intérêt à son utilisation.
Voilà une très bonne chose, quand on sait le nid à insectes qu'est Samba.
Windows, à partir de 2008 serveur et Windows7, sait maintenant parfaitement gérer les montages NFS (deux clics pour aller activer le service …).
Pourquoi continuer d'utiliser des shares SMB avec des filers Unix/Linux ?
[^] # Re: Oui et non
Posté par WhiteCat . Évalué à 6.
Déjà rien que pour les gestion des droits d'accès.
[^] # Re: Oui et non
Posté par Kwiknclean . Évalué à 3. Dernière modification le 15 décembre 2017 à 12:37.
Il va falloir être plus précis et développer le "déjà" …
Car peut-être hormis certains cas d'implémentation particuliers, non gérables avec les ACLs et l'authentification Kerberos apportées par la version 4 de NFS, je ne vois vraiment aucun avantage à se trainer des partages SMB sur un filer Unix.
FreeBSD est justement un OS à la pointe sur les amélioration NFS, c'est vraiment bête de passer à côté.
https://svnweb.freebsd.org/base?view=revision&revision=261054
https://svnweb.freebsd.org/base?view=revision&revision=261055
[^] # Re: Oui et non
Posté par WhiteCat . Évalué à 3. Dernière modification le 15 décembre 2017 à 15:15.
Honnêtement je ne saurais pas trop parler de NFS, car j'ai très peu utilisé.
Mais…
là où je bosse, je déploie quelques serveurs avec du Samba pour pouvoir donner accès des partages à des postes Windows (environnement AD). Donc SMB = natif Windows, pas de problème. NFS ? C'est natif sur Windows 7 ?! Non, dans ce cas exit NFS.
j'ai jamais déplorer de problème de stabilité avec Samba. Au contraire, il y a quelques années j'ai même migré un partage Windows 2003 sous CentOS 6, et c'était devenu bien plus stable.
j'ai lu pas mal de documentation à propos de NFS. Et franchement tout ça ne m'a pas donné une super image de ce protocole. Il semble avoir pas mal de problème et être d'un autre âge. En réalité, le cas d'usage le plus safe me semble uniquement d'utiliser du NFS pour de la diffusion de fichiers en lecture seule. SMB me semble bien plus actif et proche des besoins de partage et travail collaboratif.
au boulot, j'ai un serveur Linux qui fait des montages de partage depuis un filer NetApp. J'utilise des montages SMB et ça marche sans problème. J'ai essayé pour quelques partages de les monter via NFS v3. Ça marche, certes, mais la sécurité est nulle (pas d'ACL, sans parler des identifiants Unix à rajouter à la main sur la config /etc/passwd du NetApp !!! Sérieux ?!), donc je l'ai testé que pour des partages de documents en lecture seule. Et sur le serveur Linux je ne peux plus voir les fichiers du montage dans mon arborescence Linux depuis le compte root car le montage NFS a les droit d'un autre compte (apache dans mon cas). Et j'ai pas constaté de meilleures performances avec le montage NFS (v3) comparé à SMB (1.0).
Constatant tout ça, j'ai plus d'inconvénients à utiliser du NFS que du SMB.
[^] # Re: Oui et non
Posté par Lawless . Évalué à 7. Dernière modification le 15 décembre 2017 à 12:51.
Pour la petite histoire je gère un FreeBSD comme serveur de fichiers CIFS de dizaine poste de travail sous Windows. C'est historique depuis plus de dix ans, donc on ne va pas changer ça. La configuration Samba 3.6 a migré de Debian à Ubuntu puis à FreeBSD pour pouvoir utiliser ZFS.
Au début je faisais les mise à jour de sécurité FreeBSD, mais après avoir fait une mise à jour de bibliothèques utilisées par Samba, ce dernier faisait une erreur de segmentation. Me rappelant un problème similaire sur plusieurs FreeBSD, où le service SNMP faisait une erreur de segmentation, que j'avais corrigé en désinstallant et réinstallant le paquet net-snmp, j'ai voulu faire pareil avec le paquet samba36. Cependant, après avoir supprimé le paquet samba36, grosse frayeur, ce paquet avait disparu des dépôts ! J'ai donc commencé une migration sur Samba 4 dans l'urgence. Après avoir installé deux paquets Samba qui plantaient, la troisième marcha enfin. J'ai pu migrer assez rapidement les utilisateurs de Samba 3 vers Samba 4 et adapter la configuration pour rétablir le service. Depuis ce jour là j'ai une confiance très limitée aux paquets FreeBSD et je ne fais plus de mises à jour.
[^] # Re: Oui et non
Posté par Kwiknclean . Évalué à -4.
Bha le problème est simplement là alors, faut migrer ça vers un filer Windows.
Je ne peux plus entendre ce genre de phrases, ni ce mot "historique" :-)
[^] # Re: Oui et non
Posté par Lawless . Évalué à 6.
Et bien, sous Windows on perd l'intérêt de ZFS, sans compter le coût prohibitif des licences Windows, l'exposition aux ransomwares (Windows reste la cible de 99,1 % des malwares en 2017, tout systèmes confondus) et la difficulté d'administration au clickodrome. :-)
Si tu veux gratuitement, ce week-end sur ton temps libre, migrer le serveur CIFS vers NFS et passer sur les cinquante postes Windows faire les deux clics pour activer le service et me garantir que tout fonctionne à l'identique lundi matin, n'hésite pas à me contacter. :-)
[^] # Re: Oui et non
Posté par Misc (site web personnel) . Évalué à 3.
Deja, en mettant en place un process pour ça. Je sais bien que c'est plus facile à dire qu'à faire, mais si je prends l'exemple d'une distribution comme Fedora, il y a un systéme en 2 temps. D'abord le paquet va dans updates-testing, puis dans update quand suffisament de gens ont validés le paquet. Installer un paquet depuis la version updates-testing, c'est un switch à donner. Revenir en arriére est aussi simple.
Tu as une incitation à vérifier les paquets (bien que faible), et je pense que le processus pourrait aller plus loin, en laissant les gens s'inscrire comme testeur officiel d'un paquet, et donc en ayant des notifications pour le paquet en ayant directement les versions de tests, etc.
Ou encore, aller vers plus d'automatisation. Avoir un truc qui automatiquement déploie le paquet (style piuparts), avoir un outil qui lance des tests basiques (exemple, un playbook ansible qui install un serveur httpd de base et qui le lance, verifie que ça écoute sur le port 80).
FreeBSD, y a pas tout ça que je sache. Du coup, oui, structurellement, le test est difficile si on suppose que ça va tomber sur une et une seule personne, à savoir le committer.
Et pourtant, la communauté FreeBSD est composé de gens avec des compétences, mais il n'y a pas l'air d'avoir d'efforts pour les utiliser.
Ensuite et encore une fois, je ne dit pas que c'est facile. Les ports étant distribués via svn (sauf erreur de ma part), et avoir une branche par version de test ne me parait pas terrible. Le tooling autour bouge bien, mais l'infrastructure est pas maintenu de maniére ouverte, sans doute plus pour des raisons de ressources et d'historique que pour autre choses. Du coup, oui, faire changer les choses va prendre du temps.
Mais c'est faisable, et dire "Debian a du monde, et pas FreeBSD", c'est à mon avis confondre cause et conséquence. Debian a des gens qui testent parce c'est faisable (faciliter de mise à jour vers testing, incitation social à le faire, etc). Fedora a du monde qui teste pour les mes raisons avec des mécanismes différents. FreeBSD n'a pas l'air d'avoir ça, donc ça n'arrive pas.
Ensuite, je peux me tromper, peut etre que c'est autre chose.
[^] # Re: Oui et non
Posté par Psychofox (Mastodon) . Évalué à 2.
Soit-dit en passant openZFS est maintenu pour Linux aussi. Il n'y a que ubuntu à ma connaissance qui le fournit par défaut et aucune qui ne supporte "officiellement" le boot sous ZFS mais ZFS est déjà très utilisable (je l'ai sur mon laptop là par exemple.
[^] # Re: Oui et non
Posté par claudex . Évalué à 4.
Il est dans les paquets Debian.
« 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: Oui et non
Posté par Psychofox (Mastodon) . Évalué à 2.
Je parlais de l'avoir dans les choix de partitionnement dans l'installeur officiel.
Dans toutes les distribs il y'a toujours moyen de le faire à partir d'un livecd, c'est juste moins user-friendly pour les néophytes.
[^] # Re: Oui et non
Posté par Kwiknclean . Évalué à 0. Dernière modification le 17 décembre 2017 à 02:16.
Je me permets de corriger, libre à chacun d'être mainteneur/créateur de paquet comme sous Debian. T'es pas non plus sous un Unix proprio …
Et le forum est là pour te donner un coup de main si tu rencontres des difficultés,
Forum ports
Si un paquet ne semble plus à jour mais toujours maintenu suffit de pinger le mainteneur.
Si, comme moi t'es vraiment un flemmard, tu peux simplement aller éditer cette page et quelqu'un s'en chargera.
WantedPorts
[^] # Re: Oui et non
Posté par Lawless . Évalué à 1.
Sous Debian comme sur FreeBSD chacun est libre de créer son paquet dans son coin et de le proposer en téléchargement sur son site web. Mais sous Debian pour être mainteneur d'un paquet, qui sera disponible sur les dépôts Debian, il faut être développeur Debian. On peut aussi proposer son paquet à un développeur Debian qui acceptera ou non de le pousser dans les dépôts Debian. Mais il y a des règles assez strictes pour qu'un paquet soit accepté sous Debian. À lire le journal pourquoi vous ne devriez pas packager vous-même votre logiciel pour Debian ?
Ce qui je pense doit être la même chose sur FreeBSD, enfin je l'espère, tout le monde ne peut pas pousser un paquet dans les dépôts officiels FreeBSD ? Qui accepte qu'un nouveau paquet soit inclus dans FreeBSD ? Un committer je suppose ?
Les committers correspondent certainement aux développeurs Debian. Donc nous avons bien 400 committers sur FreeBSD et plus de mille développeurs sous Debian. Et même si les développeurs Debian développement aussi des outils internes (comme dpkg, apt, reportbug, …), ils n'ont pas à développer le noyau, ni la bibliothèque C, comme doivent le faire les développeurs FreeBSD.
Ensuite d'après mon ressenti, les parquets FreeBSD ont plus l'air d'être juste l'archive tar originale avec le minimum de correctifs pour compiler sous FreeBSD, pas toujours bien testé et sans configuration par défaut. Alors que les paquets Debian les développeurs adaptent le logiciel pour qu'il s'intègre parfaitement leur distribution et passera par les banches unstables, testing et enfin stable et quand vous installez un paquet, le logiciel fonctionne avec une configuration par défaut.
# BSD oui à la stabilité mais pas sans inconvénients
Posté par abriotde (site web personnel, Mastodon) . Évalué à -4.
BSD n'a pas la même visé ni la même méthode de gouvernance, c'est ce qui explique leurs différences.
Inconvénient BSD:
- BSD est axé serveur et donc il est parfait sur un serveur, à la limite sur un PC mais pas sur de l'embarqué ou sur un super-calculateur. Il supporte moins d'architecture et une moins grande variété de configuration matériel. Étant axé serveur il est logique qu'ils soit plus stable.
- Étant moins répandu que les système Linux, il bénéficie de moins de logiciels même s'ils ont développés une couche de compatibilité Linux.
Inconvénient Linux:
- Linux même si le noyau est dirigé par l'intransigeant Linus Torwarld, de nombreuse distributions existe et de là une grande diversité d'où de nombreuses distributions et une grande effervescence. Deplus, victime de son succès (face à BSD) cela stimule un peu plus la diversité, l'enthousiasme et donc l'instabilité.
- Malgré tout certains choix assez risqué ont été faits et, je trouve, de manière un peu trop rapide et brutal sur une grande majorité de distributions (dont les majeure : Debian/Red-Hat/Slackware). Je pense notamment au controversé SystèmeD. J'imagine que si c'est choix ont été faits, l'enfeu en vaux la chandelle. Il n'empêche que de tel changement sont risqué.
En conclusion, pour un serveur qui a de gros besoin de sécurité, je choisi OpenBSD. Pour un serveur avec de gros besoin de stabilité, je choisi FreeBSD. Et pour tous le reste je choisi Linux.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: BSD oui à la stabilité mais pas sans inconvénients
Posté par ff9097 . Évalué à 2.
Ah bon Linux n'est pas axé serveur ?
[^] # Re: BSD oui à la stabilité mais pas sans inconvénients
Posté par Maclag . Évalué à 4.
Faudrait déjà définir ce que "axé serveur" est censé vouloir dire.
Il me semblait que FreeBSD s'accommodait très bien de matériel très léger tels que les routeurs. Alors on n'est peut-être pas encore dans l'embarqué, mais j'y trouve une différence avec le cliché du serveur = grosse machine qui remplit la pièce.
Quant à Linux, il peut tout faire. Est-ce que ça veut dire qu'il va forcément tout faire mal?
Et bien entre les serveurs, les super-calculateurs et les téléphones mobiles, il y a eu bien du monde qui aura eu l'occasion de chercher mieux dans chaque domaine.
Je pense que FreeBSD est plus stable parce que:
1. Ça vient sans doute un peu avec l'idéologie. Le bazar favorise la révolution partielle de chaque composant.
2. L'équipe de dév n'a tout simplement pas les moyens de faire des grandes manœuvres.
[^] # Re: BSD oui à la stabilité mais pas sans inconvénients
Posté par David Demelier (site web personnel) . Évalué à 2. Dernière modification le 18 décembre 2017 à 15:28.
Arrêtez avec ce mythe. J'ai eu des kernel panic sur un HP ProBook parce que je débranchais mon câble d'alimentation. J'en ai eu parce que j'ai utilisé conky. J'en ai eu parce que j'ai utilisé mon touchpad.
Mon serveur a aussi crashé il y a quelques semaines, sans raison.
Mon dernier kernel panic sous Linux remonte aux alentour de 2003, quand j'avais encore une carte nvidia.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: BSD oui à la stabilité mais pas sans inconvénients
Posté par David Demelier (site web personnel) . Évalué à 1.
Tiens comme par hasard, crash de mon serveur aujourd'hui :))
git is great because linus did it, mercurial is better because he didn't
[^] # Re: BSD oui à la stabilité mais pas sans inconvénients
Posté par Maclag . Évalué à 3.
Je parlais de stabilité dans les outils, la config, etc.
[^] # Re: BSD oui à la stabilité mais pas sans inconvénients
Posté par abriotde (site web personnel, Mastodon) . Évalué à 0.
On est d'accord. BSD de part l'idée de fournir un OS complet axé serveur, s’éparpille un peu moins (encore une fois cela ne veux pas dire qu'il ne puisse pas tourné sur de l'embarqué ou que Linux ne puisse pas tourné sur un serveur). Et donc tout est un peu plus cohérent. Il y a moins de distributions. Ayant aussi moins d'utilisateurs, BSD dispose de moins d'enjeux politique susceptible de le disperser. Et BSD est, par tradition, plus attaché à la philosophie UNIX (et KISS) que Linux. Bref BSD et Linux sont 2 idées totalement différentes mais complémentaire de l'OS Open-Source issu d'UNIX.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: BSD oui à la stabilité mais pas sans inconvénients
Posté par David Demelier (site web personnel) . Évalué à 2.
Ça dépend des points. Linux est beaucoup plus orienté « tout est fichier » que les BSD. Par exemple, sous FreeBSD regarder le niveau de la batterie, la luminosité ou quelque paramètres liés aux sont se passent avec
sysctl.En revanche, les outils de l'userland sont beaucoup plus simples.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: BSD oui à la stabilité mais pas sans inconvénients
Posté par abriotde (site web personnel, Mastodon) . Évalué à 0.
Je maintiens, Linux est beaucoup plus généraliste. Il tourne sans problème sur un serveur mais pas seulement. Cela ne veux pas dire que l'on ne puisse pas faire tourner un BSD sur un supercalculateur ou dans de l'embarqué, ce sera juste plus complexe. Cela ne veux pas dire que Linux fais mal les choses mais a parfois des choix qui nuise un peu (très légèrement) à sa simplicité ou ses capacités serveur.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
# Tout doux
Posté par sqbbthn . Évalué à 3.
Salut,
Tu as un problème.
Tu le règles non pas en réglant le problème, mais faisant autre chose qui n'a rien à voir.
J'utilise LXC en production depuis des années, je n'ai aucun souci. Bien sûr je ne suis pas sur Debian mais Ubuntu, c'est pareil, en un peu plus dépoussiéré, la version LTS couvre 4 ans, deux trois commandes changent mais ils font un maximum d'effort pour pérenniser l'utilisation de la distro.
Alors oui c'est pas Debian, mais c'est exactement la même chose… Ton LxC 0.x, je ne sais pas où tu vas le chercher, la production chez moi elle est avec LXC 2.x et je n'ai pas à t'en parler puisque j'utilise LXD. T'as déjà utilisé LXD ? Ça te changerait la vie, comparé à OpenVZ.
Tu mélanges ta mésaventure avec OpenVZ, Debian, et BSD.
Oui BSD a ses avantages, mais OpenVZ est un truc qui n'est même pas supporté vraiment sur Debian vu que c'est censé tourner sur CentOS à la base… si tu veux du container, utilise quelque chose à jour tel que Ubuntu ?
Si t'es vieux, et que t'as tes habitudes de vieux, que tu n'es pas prêt à faire le moindre effort pour voir ce qui se fait de nouveau, BSD est parfait pour toi : rien ne changera, puisque ça ne bouge pas. Linux bouge beaucoup, comment tu peux lui en vouloir ?
Note que je n'ai rien contre BSD, j'ai créé un compte juste pour toi, tellement j'ai lu des bêtises…
# pourquoi tant de FUD ?
Posté par johnnyflame . Évalué à 0.
Non je ne vois pas. apt install c'est pour installer un paquet pas pour mettre à jour.
Avec debian ce sont deux choses différentes aussi.
apt update
apt upgrade
rimmer@rimmer-Lenovo-IdeaPad-S10-2:~$ sudo apt-get upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages have been kept back:
linux-generic linux-headers-generic linux-image-generic
0 upgraded, 0 newly installed, 0 to remove and 3 not upgraded.
apt dist-upgrade
rimmer@rimmer-Lenovo-IdeaPad-S10-2:~$ sudo apt-get dist-upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following NEW packages will be installed:
linux-headers-3.0.0-13 linux-headers-3.0.0-13-generic
linux-image-3.0.0-13-generic
The following packages will be upgraded:
linux-generic linux-headers-generic linux-image-generic
3 upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
Need to get 48.5 MB of archives.
Pourquoi tant de FUD?
https://www.debian.org/doc/
https://www.debian.org/releases/stable/installmanual
Et sinon tu connais nftables ? ça remplace iptables depuis le noyau 3.13 en 2014.
http://netfilter.org/projects/nftables/
https://wiki.nftables.org/
Au final tu fais beaucoup plus de tort à ton propos en avancant des arguments qui montrent surtout que tu ne sais pas vraiment de quoi tu parles. Et c'est dommage parce qu'il n'y a pas de raisons de faire du tort aux *BSD ainsi.
Maintenant que tu as découvert FreeBSD, on attends ta prochaine évolution quand tu vas découvrir openBSD et netBSD et dragonfly et trueOS etc.
# version finalisée
Posté par chimay . Évalué à -1.
quelques petites astuces sympas, la version finalisée serait intéressante en effet
# J'ai une bonne nouvelle
Posté par Katyucha (site web personnel) . Évalué à 2.
Oui, j'ai une bonne nouvelle : Personne t'oblige à utiliser Debian !
Je le répête comme pour les windowmanager : si ça te plait pas, utilise autre chose. On a une diversité qui permet à chacun de trouvr chaussure à son pied
Par contre, fait attention quand même : BSD en entreprise, c'est rare ! Tu auras plus du Redhat/CentOs ou Debian …etc
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.