Et bien, oui, FreeBSD 6.3 release est sorti !
Amis lutins, bienvenue dans le jardin magique nouveau ...
Amis lutins, bienvenue dans le jardin magique nouveau ...
> Lire le journal (28 commentaires, moyenne: 3,1).
Vous avez demandé le commentaire #897427.
Run by 
Cette page a été générée par Templeet en 0.1038s (dont 0.0237 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Plaf
Et ben dis donc, si c'est tout ce qu'il y a à dire sur la dernière release c'est que ça doit pas être bien terrible FreeBSD.
On est encore vendredi, j'ai le droit non? ;-)
[^]Re: Plaf
c'est surtout qu'il y a tellement de configurations pénibles à faire à la main, que les utilisateurs de freebsd sont tous en train de galérer pour la mise à jour en ce moment, alors que leurs homologues sous linux ont tout leur temps libre pour mouler et troller tellement tout fonctionne bien chez eux...
You can't grep dead trees...
[+] [^]Re: Plaf
C'est clair que tout fonctionne mieux sous linux :
- les attaques dos
- les rootkit
- flash
...
[^]Re: Plaf
ne t'inquiète pas, cela n'arrive tellement jamais des rootkit sous bsd, qu'il y a maintenant des livres qui montrent comment ça fonctionne, "pour s'en protéger" :
http://www.eyrolles.com/Informatique/Livre/9782744022203/
You can't grep dead trees...
[^]Re: Plaf
Oui enfin, entre maintenir un fichier rc.conf sous FreeBSD et l'arborescence /etc/sysconfig sur une RHEL ou une Fedora, le plus compliqué n'est pas le premier, loin de là.
Ayant plusieurs dizaines de serveurs à maintenir, j'aurai tendance à dire que statistiquemen les linux nous posent plus de problèmes que les BSD... et pas qu'un peu.
(désolé, on n'est plus vendredi ;)
[+] [^]Re: Plaf
> Oui enfin, entre maintenir un fichier rc.conf sous FreeBSD et l'arborescence /etc/sysconfig sur une RHEL ou une Fedora, le plus compliqué n'est pas le premier, loin de là.
Tu connais hypra mal Fedora.
Ce qui concerne apache dans Fedora :
/etc/systemconfig/httpd
Tout est dans ce registre. Il n'y a dans /etc/sysconfig que des options que tu ne peux pas changer avec /etc/httpd/conf*.
Mais au-lieu de faire un truc de porc en bidouillant les /etc/rc.*, tu fais la configuration en un lieu précis dans un cadre qui l'a prévu (plus ou moins car prévoir tout les cas est impossible).
[root@one ~]# du -s /etc
111596 /etc
[root@one ~]# du -s /etc/sysconfig/
864 /etc/sysconfig/
/etc/sysconfig est moins d'1 % de la configuration du système.
> Ayant plusieurs dizaines de serveurs à maintenir, j'aurai tendance à dire que statistiquemen les linux nous posent plus de problèmes que les BSD... et pas qu'un peu.
Je ne vois pas pourquoi.
[^]Re: Plaf
Déjà, j'avoue, je connais bien moins Fedora que CentOS ou RHEL.
Ensuite, je ne considère pas qu'apache fasse parti du système de base.
Mais pour comparaison, voici ce que l'on peut mettre dans le rc.conf concernant apache, sachant qu'il suffit de mettre le premier et le dernier à yes pour activer un serveur web :
Maintenant, je parlais bien de sysconfig, qui même s'il ne représente qu'un pourcent en taille est assez pénible en comparaison lorsque l'on a des configurations un peu pénibles (certains serveurs ont plusieurs cartes réseaux et une diszaines d'alias IP, par exemple).
Le gros intéret de rc.conf est qu'il permet d'avoir une vision synthétique de toute la configuration non par défaut du système, des services démarrés, etc.
Tu as déjà regardé comment sont organisés les rc.* sur un BSD ?
(tip: C'est à l'image du reste lorsque l'on compare Linux vs. BSD)
Entre autre, les problèmes sur certains montage nfs (montages ro qui est en fait rw), client nfs qui ne remonte pas forcement suite à un problème sur sa connexion avec le serveur, nscd qui se gaufre sous forte charge, nfs4 qui ne tient pas non plus avec en message d'erreur des problèmes VFS non traités qui n'auraient pas du remonter en userland (ces 2 derniers datent de nos tests d'il y a un an, on est revenu en arrière depuis), /bin/sh qui est en fait un bash, avec toutes les gnuteries associées pour le shell root...
(pour préciser : certains chez nous sont plutot orientés Linux, d'autres plutot BSD... donc ce n'est pas forcement qu'une question de connaitre mieux un systeme)
[+] [^]Re: Plaf
> Déjà, j'avoue, je connais bien moins Fedora que CentOS ou RHEL.
C'est la même chose techniquement. RHEL 5 est une FC6 avec quelques bricoles de plus. Faut être un expert pointu pour voir la différence. C'est le support qui change entre Fedora et RHEL. Techniquement c'est la même chose. RHEL est toujours basé sur Fedora.
> Mais pour comparaison, voici ce que l'on peut mettre dans le rc.conf concernant apache
Dans l'idée c'est la même chose. Donc ne voit pas pourquoi tu critiques le principe de Fedora et pas celui de FreeBSD. C'est le chemin /etc/sysconfig qui te pose problème ?
> Le gros intéret de rc.conf est qu'il permet d'avoir une vision synthétique de toute la configuration
Ça c'est les goûts et les couleurs. Certains développeurs veulent tout dans le même répertoire et d'autres veulent une arborescence.
> Tu as déjà regardé comment sont organisés les rc.* sur un BSD ?
Non, et je n'ai jamais dit que rc.* sur BSD était naze.
Mais ta critique de /etc/sysconfig de Fedora est gratuite et ça m'énerve.
> (tip: C'est à l'image du reste lorsque l'on compare Linux vs. BSD)
Faisons dans le troll. C'est limité et d'une autre époque ?
> Entre autre, les problèmes sur certains montage nfs (montages ro qui est en fait rw),
Puisque tu le dis.
> client nfs qui ne remonte pas forcement suite à un problème sur sa connexion avec le serveur,
Puisque tu le dis.
> nscd qui se gaufre sous forte charge,
Puisque tu le dis.
> nfs4 qui ne tient pas non plus avec en message d'erreur des problèmes VFS non traités qui n'auraient pas du remonter en userland (ces 2 derniers datent de nos tests d'il y a un an, on est revenu en arrière depuis),
Puisque tu le dis.
En passant, tu as fait ses tests sur quoi ?
Parce que NFS ça existe depuis longtemps et c'est très utilisé.
C'est bien gentil de mettre une liste de bug/limitation/manquement/etc.
Si on veut faire la liste de FreeBSD ça serait pire.
> /bin/sh qui est en fait un bash, avec toutes les gnuteries associées pour le shell root...
C'est connu, BSD est parfait est GNU ça pue, c'est le mal et ça veut la mort de BSD. Mais le monde est injuste, BSD c'est qu'une niche (même dans les serveurs).
[^]Re: Plaf
Il y a quelques différences tout de même, comme yum.
Mais nous sommes d'accord, d'ou le rapprochement dans mon premier message.
Ce qui me gène dans sysconfig n'est pas dans le contenu, qui est proche comme le montre ma citation, mais dans l'aspect "fouilli" : rien que pour le réseau, l'information est parfois répartie sur une dizaine de fichiers, ce qui en complique la maintenance je trouve.
Sans aucun doute.
Elle n'est pas completement gratuite : Rien que cette année j'ai du installer une trentaine de serveurs sous CentOS, et mon portable est longtemps resté sous FC6, puis FC7.
Le "problème" est que ce que qui me gène est plus de l'ordre du ressenti : difficile a exprimé et pouvant parfaitement ne pas être partagé.
Tests faits sur une CentOS 4, avec discution avec l'une des personnes en charge de cette distrib.
Pour les problèmes NFS, la plupart sont référencés sur le bugzilla de RedHat ou autre et sont restés ouverts un certain temps malgré ce que tu dis sur l'utilisation de NFS...
Alors je m'excuse pour le mot "gnuteries", ce n'est pas le point le plus important que je voulais soulever. Ce qui me gène surtout c'est d'avoir fait de /bin/sh un simple lien vers /bin/bash sur nombre de distribs alors que pour moi le shell de root par défaut devrait être minimaliste de chez minimaliste, question de sécurité, quitte à lancer un bash à la main après. Cela éviterait de se retrouver coincé par un truc dans /etc/bashrc lorsque l'on essaye de se connecter root sur une machine ayant un problème...
[^]Re: Plaf
> Il y a quelques différences tout de même, comme yum.
RHEL 5 est passé à yum (puisque RHEL 5 est basé sur FC6). Par contre il y a un plugin yum pour accéder à rhn dans RHEL 5. RHEL 5 fournit toujours up2date pour des raisons de compatibilité, mais il ne sera plus dans RHEL 6 (ça a été annoncé à la sortie de RHEL 5).
> Ce qui me gène dans sysconfig n'est pas dans le contenu, qui est proche comme le montre ma citation, mais dans l'aspect "fouilli" : rien que pour le réseau, l'information est parfois répartie sur une dizaine de fichiers, ce qui en complique la maintenance je trouve.
OK, c'est principalement sur la forme. Il y a aussi des scripts (donc programmes) dans /etc/sysconfig ce qui est tout à fait discutable (pour ma part ils ne devraient pas être là). M'enfin, c'est limité à /etc/sysconfig/network-scripts/ .
Pour info, la doc est dans /usr/share/doc/initscripts-*/sysconfig.txt .
Normalement system-config-network (marche aussi en mode texte) gère ça très bien pour 98 % des cas.
> Tests faits sur une CentOS 4, avec discution avec l'une des personnes en charge de cette distrib.
CentOS 4 est RHEL 4 qui est basé sur FC3 je crois. Au pif la distribution à 3 ans.
Tu as comparé avec une FreeBSD de la même époque ?
Ceci dit, t'as trouvé une distribution Linux qui ne t'as pas donné satisfaction avec NFS. Que dire à part "c'est la vie".
Il me semble que RHEL 4 était une des premières distributions à passer au code NFS 4. Peut-être que Red Hat a fait une connerie avec ce choix. Ben ça arrive. Faut pas que ça arrive trop souvent :-)
> Alors je m'excuse pour le mot "gnuteries"
Ça roule, c'est oublié.
> Ce qui me gène surtout c'est d'avoir fait de /bin/sh un simple lien vers /bin/bash sur nombre de distribs
Faut comprendre la raison. Tout le monde (99%) utilise/choisi bash. Au-lieu de maintenir deux shells, d'en avoir deux en mémoire, etc et bien il n'y en a qu'un. C'est une raison qu'on peut ne pas trouver suffisante, mais elle a du sens.
> alors que pour moi le shell de root par défaut devrait être minimaliste de chez minimaliste, question de sécurité
Pour l'aspect sécurité je suis très sceptique. Par définition un shell doit tout permettre (même les pires conneries de l'admin). C'est l'OS (noyau, login, ssh, selinux, etc) qui fait la sécurité.
Si c'est très minimaliste, c'est probablement un shell qu'utilise rarement les admins. Donc les risques d'erreur augmente (d'autant plus que l'admin va "s'énerver" avec ce shell minimaliste).
Si c'est pour les bugs du shell, ben bash est plus utilisé, testé, audité, etc.
Si on te suit, pourquoi pas un ls mininum, un find minimum, etc. Pourquoi pas faire de busybox le shell de root ?
Je ne peux pas démontrer que tu as tord. M'enfin l'histoire montre que les problèmes de sécurité viennent rarement de la. Il n'y a pas de daemon bash a l'écoute du réseau :-)
> quitte à lancer un bash à la main après.
Tu avances ce que tu considères comme un atout sécurité et après tu le contournes :-)
> Cela éviterait de se retrouver coincé par un truc dans /etc/bashrc lorsque l'on essaye de se connecter root sur une machine ayant un problème...
Mouaif. Il y a toujours des compromis. Tu peux te faire un sh-mini avec dedans "bash --noprofile --norc". Je crois que le boot en initlevel 1 lance un shell avec ces options (je n'ai pas envis de rebooter pour vérifier ça :-). Tu peux aussi booter avec en paramètre "init=/bin/mon_shell_mini" ou "init=/usr/bin/mc" etc.
Faut toujours évaluer les problèmes globalement et ne pas seulement s'en tenir aux principes "simplistes". Oui avec un shell minimum tu auras moins de problèmes "théoriquement". Mais es-ce que ça vaut la peine d'"emmerder" tout le monde avec un shell minimum dont le gain en sécurité/fiabilité est quasi insignifiant ? Pour ma part, et c'est subjectif, la réponse est non.
Puis il y a tellement de truc qui peuvent merder... Si dans chaque cas il faut un contournement car un utilisateur a eu le problème, ça devient une usine à gaz (et avec paradoxalement plus de possibilité pour que ça merde).
Je me rappelle qu'un débat animé sur mailing Fedora car Fedora voulait virer toutes les lib statiques et qu'aucun programme ne soit linké statiquement (même plus de bash_static). Ceux qui étaient contre étaient dans ton esprit, c'est-à-dire qu'un programme static c'est bien si la mise à jour d'une lib déconne (comme un shell mini c'est bien s'il y a une connerie dans bashrc). Le problème avec ce type de raisonnement c'est que c'est sans fin. Il faut bash en static, puis ln en static, puis vim, puis login, puis init, etc...
Une bécane qui ne boote plus, un shell qui ne marche pas et qui ne permet plus de se logguer est un vrai problème. Mais la solution n'est pas d'avoir un contournement pour chaqu'un de ces problèmes. La solution est d'utilise un CD de secours. Le CD d'installation de Fedora ou RHEL le fait et probablement que toutes les distributions le font.
Une autre solution (c'est ce que je fais) est d'installer deux systèmes. Un système mininum (2 Go sur une partition suffisse). S'il y a une catastrophe, on boote sur le système minimum.
Il y a d'autre solution évidemment. Mais il ne faut pas chercher un contournement pour un problème, mais pour un ensemble de problème. Un CD de secours ou un second système (minimum ou un mirroir du système principal) sont les bonnes solutions (à mon avis).
[^]Re: Plaf
> Je me rappelle qu'un débat animé sur mailing Fedora car Fedora voulait virer toutes les lib statiques et qu'aucun programme ne soit linké statiquement (même plus de bash_static).
Pour info, ça a été fait. Il ne reste que insmod et les outils lié à raid/lvm qui ont une version statique (pour des raisons que j'ignore).
[^]Re: Plaf
Je me mêle trente secondes de ce thread pour (tenter) d'expliquer en quoi bash comme shell root c'est mal.
Le shell root est parfois la seule arme qu'il reste quand on a un gros problème sur une machine, notament en cas de corruption de disque dur et de problème sur la table de partition.
Ce qui casse le plus les pieds à un admin (et de loin) et de devoir descendre en salle machine, voir de devoir prendre un taxi pour aller jusqu'à la salle machine quand un truc part en vrille. le but est donc d'avoir un système totalement indépendant du reste sur le /. C'est pour celà que l'on a un /root et non un /home/root.
Dans la plupart des Unix, comme dans FreeBSD et OpenBSD l'intégralité du contenu de /sbin et la majorité du contenu de /bin est linké en statique et est aussi light que possible (par exemple pas de dépendance à la libc). Le but du jeu étant de pouvoir travailler et tenter de récupérer des données sur un système dont on est même pas sur qu'il reboote. La solution LiveCD a deux inconvennients : tout d'abord elle necessite un accès physique à la machine (ce qui est lourd) et ensuite elle requiert de devoir redémarrer la machine, ce qui est potentiellement dangereux. Une carte RAID qui envoit message d'alerte sur message d'alerte peut parfaitement décider au reboot que les disques sont inutilisables et les achever ou refuser de les rendre accessible.
Dans ce genre de cas, je suis personellement assez content d'avoir tout un BSD minimaliste et linké statiquement sur ma machine, ce qui me permet de récupérer un maximum de données même si le /usr est mort ou si le /var fait des siennes.
On peut faire une version minimaliste et lié en statique de bash, mais elle sera toujours plus grosse que son équivalent sh/csh et donc plus sensible aux corruptions et ensuite bash a une facheuse tendance à remplacer certaines commandes Unix de base par les siennes propres. La bonne façon d'invoquer bash sur un système à l'agonie est bash --noprofile --norc --noediting --posix. Mais si on fait celà il n'apporte vraiment pas grand chose de plus que csh...
Kha
root est un privilège, pas un droit !
[^]Re: Plaf
Dans la plupart des Unix, comme dans FreeBSD et OpenBSD l'intégralité du contenu de /sbin et la majorité du contenu de /bin est linké en statique et est aussi light que possible (par exemple pas de dépendance à la libc).
Sous FreeBSD ce n'est plus le cas depuis qq annees deja (en juillet/aout 2003 IIRC. et pour la premiere fois dans FreeBSD 5.2). Tout simplement pour que les binaires dans /bin et /sbin puissent profiter des DSO pour PAM et NSS, seuls qq binaires restent statiques (genre init, devd).
L'astuce chez FreeBSD est d'avoir un /rescue avec un crunched binary (avec les hardlink qui vont avec) qui contient presque tout ce qui permet de fix l'OS au cas ou.
[^]Re: Plaf
> Dans la plupart des Unix, comme dans FreeBSD et OpenBSD l'intégralité du contenu de /sbin et la majorité du contenu de /bin est linké en statique et est aussi light que possible (par exemple pas de dépendance à la libc).
Très bien. Mais c'est d'un intérêt quasi insignifiant pour moi.
> C'est pour celà que l'on a un /root et non un /home/root.
Comme sous Linux, mais ce n'est pas pour les mêmes raisons.
> La solution LiveCD a deux inconvennients
La solution linké statiquement ne manque pas d'inconvennient aussi.
> elle requiert de devoir redémarrer la machine, ce qui est potentiellement dangereux.
Mouaif... Un admin qui met en place quelque chose qui ne supporte pas un reboot est un mauvais admin.
[^]Re: Plaf
ahahaha :) les joies du misquoting :)
[^]Re: Plaf
Dans la plupart des Unix, comme dans FreeBSD et OpenBSD l'intégralité du contenu de /sbin et la majorité du contenu de /bin est linké en statique et est aussi light que possible (par exemple pas de dépendance à la libc).
Sun ne fourni plus libc.A depuis solaris 10. Ce qui est assez enervant, par exemple quand on veut compiler en static un outil de verification d'intégrité.
[^]Re: Plaf
Sun ne fourni plus libc.A depuis solaris 10. Ce qui est assez enervant, par exemple quand on veut compiler en static un outil de verification d'intégrité.
Oui, enfin Solaris prend une approche résolument différente des Unix classiques depuis la version 10. Notamment sous Solaris 10 et OpenSolaris il est assez fortement recommandé de ne pas mettre /usr sur une partition à part justement pour des questions de liens dynamiques. En fait il semblerait que Solaris soit bien décidé à tuer sur ses systèmes toute notion de liens statiques.
Kha
root est un privilège, pas un droit !
[^]Re: Plaf
ouais je rigolais hein... :)
honnêtement, pour avoir testé les 2 j'ai trouvé des bons points des 2 côtés. Pour un utilisateur linux, il peut bien entendu avoir de petites choses déroutantes, mais rien de grave... Le système de pkg_add n'est pas mal fait, et permet d'installer rapidement beaucoup d'applications utiles. Pour le reste, je n'ai pas assez essayé pour juger, en tout cas l'installation est aisée.
PCBSD est bien fait aussi...
You can't grep dead trees...
[^]Re: Plaf
Tiens voilà la liste des commandes à passer pour :
- Télécharger l'ensemble des mises à jour de FreeBSD 6.x à FreeBSD 6.3
- Vérifier la cohérence de la configuration avant la mise à jour
- Valider l'ensemble de la mise à jour du kernel space avec ou non installation et activations des modules kernel et des docs associées.
- Valider l'ensemble de la mise à jour du user space et la mettre en place :
# fetch http://people.freebsd.org/~cperciva/freebsd-update-upgrade.t(...)
Télécharger et vérifier la signature numérique du paquet de mise à jour est hautement recomandé (signature par le responsable sécurité FreeBSD)
# fetch http://people.freebsd.org/~cperciva/freebsd-update-upgrade.t(...)
# gpg --verify freebsd-update-upgrade.tgz.asc freebsd-update-upgrade.tgz
La nouvelle version de freebsd-update peut alors être extraite et lancée comme suit :
# tar -xf freebsd-update-upgrade.tgz
# sh freebsd-update.sh -f freebsd-update.conf -r 6.3-RELEASE upgrade
# sh freebsd-update.sh -f freebsd-update.conf install
Le système doit alors être redémaré pour mettre en place le nouveau kernel
# shutdown -r now
Enfin freebsd-update doit être lancé une dernière fois pour mettre à jour l'espace utilisateur et la machine doit etre redémarrée une fois de plus.
# sh freebsd-update.sh -f freebsd-update.conf install
# shutdown -r now
Mise à jour de ma machine FreeBSD 6.1 en 12mn30sec sans aucun problème. Les fonctionnalités web (Apache et Yaws), base de données (Postgres et MySQL), mail (Postfix, Dovecot, Majordomo, RoudCube), authentification (Cyrus SASL, OpenLDAP, ssh) et le système se portent bien.
Mise à jour faite à distance sur une machine Dedibox.
Je ne saurais en aucun cas être tenu responsable des dégats si un utilisateur frustré par ce poste s'amusait à tenter le même genre de chose sur une distrib Linux....
Kha
root est un privilège, pas un droit !
[^]Re: Plaf
d'un autre côté si un utilisateur freebsd frustré tape un "apt-get dist-upgrade" sur son système, cela ne risque pas de casser grand chose non plus... ;)
bon je rigole, mais la procédure de freebsd n'est pas bien compliquée non plus...
You can't grep dead trees...
[^]Re: Plaf
et on rigole, on rigole, mais c'est pas facile pour tout le monde les mises à jour...
Tandis que les utilisateurs de FreeBSD, ceux de Debian, Ubuntu, Fedora, OpenSuse, Mandriva, Archlinux (désolé pour ceux que j'ai oublié) etc etc font Whoaaaa, il y en a d'autres qui font "pouahhhh" :
http://www.generation-nt.com/windows-update-vista-80073712-a(...)
You can't grep dead trees...
[^]Re: Plaf
Incroyable. On croit rêver: et ces mecs sont les leaders mondiaux des systèmes d'exploitation? C'est vraiment affligeant. Je commence à croire que Linux restera définitivement circoncis aux geeks et aux utilisateurs un peu conscients, les gens ou le marché je sais pas sont vraiment trop cons.</séquence monde_de_merde>
[^]Re: Plaf
même si Windows c'est un peu un système de glands, je pense que tu voulais écrire "circonscrit" ;)
You can't grep dead trees...