mururoa69 a écrit 287 commentaires

Euh si c'était un serveur, un vrai, un tatoué tu aurais une interface de prise contrôle à distance. RSA, ILO, ALOM ou l'équivalent chez Dell.
C'est quoi ta machine ?

:up:

Et un routeur flashable à base de linux openembeded ça ne te conviendrait pas ? Type linksys wrt54GL ou asus wl500 gp.
Question consommation et encombrement tu aura difficilement mieux. Environ 70-90 € tout compris et 5 ports réseau + 2 usb dans le cas de l'asus avec carte wifi comprise.
Evidemment c'est pas du BSD si c'est un critère impératif. Certains routeurs sont également compabibles BSD et ça devrait se répandre avec l'adoption par BSD 7 de l'architecture ARM.
Moi j'ai un asus wl500g deluxe avec un disque usb derriere et ça me sert de :
- routeur
- print server
- serveur ssh
- nas
- firewall
- serveur dhcp

Et oui et il manque certaines infos disponibles sur la console au moment du boot.

Mea coulpa, j'ai pas indiqué la distrib. Je pensais que ça devrait être similaire sur les distrib linux mais visiblement non.
La distrib est une redhat 5.1.
Il n'y a pas de bootlogd sur la rhel51.
Je pense donc toujours que c'est dans le syslog.conf (sur la redhat) mais quoi mettre ?

Oui mais au bout d'un an en suivant la méthode préconisé et quand ça n'a pas avancé d'un seul centimètre il faut quand même remettre la méthode en question et trouver un moyen d'avancer.

Ouais ouais ouais, bonne piste ça.
Je vais creuser de ce coté là.
Merci.

1 : mais si c'est tout à fait légal. On a même les licences c'est dire ;)
2 : ça a été fait. J'en ai parlé à mon chef, et a son chef qui en ont parlé au responsable encore au dessus qui ont tous appuyé mes demandes tamponnées validées et urgentes ... sans résultat.

Attention, je n'ai pas un problème avec l'admin ou les admin, je parle juste à un mur. Personne en face, juste une hotline qui fait tampon et personne à qui parler derriere.

Oui je sais ça mais je disais dans le post : en évitant un tunnel ssh qui impose d'avoir une machine externe à l'entreprise et qui introduit un problème de sécurité.

Je crois que tu as mal lu mon post. Ca fait plus d'un an que j'essaye de faire débloquer la situation par la voie normale mais je me heurte à un mur. C'est pas une question de bande passante ou de protocole. Ils ont mis en place un système de filtre et ça les fait chier de changer quoi que ce soit donc ils jouent à fond l'immobilisme. Pour traiter une quelconque question avec eux il faudrait déjà que j'arrive à avoir un interlocuteur identifié et ce n'est même pas le cas. Je remplis des formulaires de demande qui sont tout simplement ignorés alors j'appelle suite à la demande et on me réponds que le problème va être pris en charge par quelqu'un prochainement mais en fait il reste juste enterré. Quand ça n'a pas avançé d'un cheveux au bout d'un an on peut raisonnablement penser que ça ne bougeras pas beaucoup à moyen terme. Alors bypasser le proxy c'est pas la mauvaise solution, c'est juste la seule solution raisonnable. La mauvaise solution ça serait de hacker les serveurs du proxy. Et je pourrais le faire sans problème mais là je risque clairement ma place alors que c'est purement une problématique qui concerne l'entreprise et pas moi personnellement. Donc je me refuse à hacker les serveurs mais j'aimerais quand même, si possible, pouvoir faire mon boulot. D'où le bypass. Si quelqu'un me reproche un jour d'avoir bypassé le proxy je pourrai sortir les formulaires de demandes classés sans suite et justifier le contournement.

Ok, merci.
Pour le raid ça a l'air équivalent mais le reste n'a pas l'air top top oui.
Je regarde pour ASU. Jusque là j'avais trouvé qq utilitaires sur le site IBM mais sans manuel. Le top reste aacraid avec une archive qui contient 2 exécutables pour le 32 et le 64 bits et c'est tout.

Merci pour l'idée vga=, je suis déjà passé de 80x25 à 100x37.
Reste à affiner un peu.

J'ai revendu un rack 19" recemment ;(
Il faut bien comprendre que ce n'est pas une question d'économie c'est une question de facilités d'installation de maintenance et de rangement. Si tu veux faire des économies reste en tour mais avec le nombre de serveurs augmentant + les baies de disques et les équipement réseau ta salle machine va vite devenir un beau bordel.

Et bien moi j'ai acheté l'année dernière une radeon 1950 pro. J'avais longuement hésité entre ça et une nvidia 7900 et j'ai été obligé de la revendre quelques semaines plus tard pour prendre une nvidia 8800 tellement les drivers était mal supportés sous linux et inexistants sous BSD.
Donc au départ on peut dire que j'ai fait confiance à ATI mais que dans la pratique cette 1950 pro qui était très suffisante et marchait très bien sous windows ne marchait QUE sous windows.
NVidia fournit des drivers qui marchent et récents pour linux ET BSD.

Non les développeurs de linux n'envisagent pas de tout revoir pour parvenir à un linux SSI parce que ce n'est tout simplement par leur but.
C'est pas non plus dans la philosophie de linux. Personne ne dirige vraiment le développement du kernel. Il y a juste un comité qui valide les modifications/ajouts du kernel mais n'importe qui peut participer et dans la direction qu'il veut. Après c'est incorporé dans le kernel où pas. Linux est un système assemblé. Pas grand chose à voir entre une open embedded et une redhat 5.
BSD est complètement différent de ce coté là. C'est un système d'exploitation conçu de a à Z.
Ce qui en résulte c'est que linux est pratiquement toujours à la pointe et est très souple mais reste très chaotique alors que BSD avance plus lentement mais est cohérent et stable. Un effet de bord est que les dev sur linux écrivent la doc et le man quand et si ils en ont envie.
Pour le cas de DragonFly c'est un fork d'une ancienne version de FreeBSD qui a pour but de faire un système SSI. Tout développeur qui veut participer à DragonFly doit le faire sous les directives du projet leader.
A mon sens DragonFly est le système qui pourrait être le plus intéressant à terme si il tient toutes ces ambitions mais ce n'est qu'un point de vue partial d'un admin système Unix (Tru64, HP/UX) qui vient du monde cluster et qui a souvent du mal à encaisser les incohérences et l'aspect pas fini de linux ;)

3 questions et trois réponses fausses.
Renseignes-toi avant de dire n'importe quoi.

--create n'a pas marché car les devices étaient déjà dans une config. --force n'a rien changé.

--build arrivait à construire qq chose mais ça ne résistait pas au reboot.

Merci pour l'info sur les raid 1 qui sont toujours en ext3.
Je fais des tests dès que j'ai une sauvegarde propre.

Et pour la question bonus GFS nécessite la cluster suite de redhat pour fonctionner et aussi, forcement, un stockage commun à tous les serveurs qui y accèdent donc sur ton NSLU2 rien qu'avec les démons de la cluster suite et de gfs il risque déjà de manquer de ram sans compter ce qu'il faudrait mettre en place pour avoir du stockage partagé.

Arf, 1 GB de swap pour une machine de 32 MB de ram ça fait juste 32 fois la taille de la ram du NAS ;)
De la swap sur un disque externe c'est bien évidemment la meilleure solution mais pas plus de 2-4 fois la taille de la ram.
De toute façon si ton NSLU2 swap en fonctionnement normal les performances ne pourront être que très mauvaises à catastrophiques. Il faut absolument limiter la consommation de ram pour que la swap ne soit là qu'en cas de surcharge ou de traitement exceptionnel sinon ton NSLU2 va passer son temps à swapper au lieu de fournir un service.

Et quand à la connerie ben je ne vois vraiment pas. Le serveur était en etch à jour (auto mise à jour hehe). L'arrêt à été propre. Probablement la mauvaise idée de faire du raid 0 sur des devices raid 1. C'est supporté à la création mais visiblement pas trop au reboot.

Salut,

Bon a priori rien n'a marché en mode manage, ni le remove ni le fail, et donc j'ai été réduit à détruire le md4 avec :

mdadm --misc --zero-superblock /dev/md4

reconfigurer le paquet mdadm avec

dpkg-reconfigure mdadm

Ensuite j'ai abandonné l'idée de faire du raid 0 sur mes devices en raid 1 et donc j'ai juste rajouté les 3 raid 1 dans la configuration lvm.

J'ai perdu juste 55 GB. Avis aux amateurs de raid soft ! Enfin perdu oui mais comme c'était juste un miroir debian j'ai rechargé ensuite les GB perdus sur les autres miroirs.
J'ose espérer que de simples raid 1 seront moins sensibles que le raid 1 + 0.
J'attends d'avoir des sauvegardes valides pour arracher des disques en cours de fonctionnement et voir comment ça se comporte en récupération.

1/ non. Contrairement à ce qui est dit dans le précédent commentaire openmosix (paix à son âme, projet mort avant-hier) et openssi (en cours de torpillage permanent par HP) ne sont pas intégrés (mais alors pas du tout) dans le kernel linux. En l'état actuel le kernel de linux n'est pas du tout conçu dans cette optique.

2/ il faudrait revoir tout le kernel pratiquement. C'est ce que fait dragonFly pour le kernel BSD 4.

3/ c'est très utile oui ça permet de n'avoir pratiquement qu'un seul système à administrer alors que le système comporte plusieurs serveurs physiques.

4/ (oui je sais il n'y a que 3 questions) Tu fais reference au but de DragonFly; pas à son état actuel. Actuellement DragonFly n'est qu'à la phase un de son développement : revoir tous les mécanismes internes de l'OS pour permettre de mettre en place un véritable cluster SSI. Les seuls clusters SSI opérationnels que je connaisse sont Tru64 et VMS.

Le clonage se fait par rsync avec les options qui permettent de conserver tout en l'état y-compris les liens hard et soft de l'original.
Comme rsync peut s'appuyer sur ssh c'est toujours ça de gagné concernant la sécurité des systèmes.

Tks.
J'ai testé et ça marche.
C'est pas forcement intelligent mais ça marche ;)

Bon, tout ça ne me dit pas comment récupérer les mises à jour de sécurité ;)
A part le cas par cas ( fichier par fichier ), attendre la prochaine update qui integre aussi les patch de sécurité si je ne me plante pas et utiliser les outils de redhat il n'y a pas de solution ?
Et concernant CentOS, ils integrent les mises à jour de sécurité dans leurs updates standard ou pas ?