|
Bas de page | |
---|---|
Auteur | Sujet : Les technos à connaitre, à étudier, à oublier... |
roscocoltran L'enfer c'est les utilisateurs | Salut, Je viens de lire un sujet qui parle de udev, avec sa syntaxe cabalistique et je ne peux pas m'empêcher de penser: "est-ce que ça vaut la peine de se pencher sur ce truc, ou est-ce que cela passera aux oubliettes avec la sortie du/des prochain kernel ?" Bref, je veux bien investir du temps à apprendre de nouvelle techniques de gestion de mes systèmes, mais je ne voudrais pas miser sur le mauvais cheval. Qui à dit selinux ? Donc en résumé, quelles sont selon vous les outils à connaitre absolument et ceux dont on peut se dispenser ? - Selinux par exemple, vous avez vu cette syntaxe ? Ca me rappelle le chapitre 4 du manuel o'reilly de sendmail, quel enfer. Ca vous sert vous ou vous avez un équivalent plus abordable ? - NFSv4 + kerberos. Je me demande quoi penser de ce truc. J'ai eu beau lire des documents, je n'ai jamais compris si l'on pouvait au final monter un répertoire en NFS en échange de son mot de passe et pas simplement de son user id. Le fichier de conf fonctionne différemment de la version 3 et le fonctionnement dépend encore de l'implémentation des fabricants de NAS il me semble. Ca fait peur. - Zope: la dernière fois que j'ai regardé, la version 3 n'avait pas convaincu grand monde, la plupart des gens préférant rester sur la 2. D'ailleurs python est plutôt en perte de vitesse j'ai l'impression. - IMAP, POP, etc... J'ai l'impression qu'aucun logiciel n'arrive à remplacer un ensemble postfix/courier/exim/cyrus/squirrelmail/ - virtualisation: haaa, xen et KVM. Que choisir ? Redhat est en train de lâcher Xen pour KVM. Et xen n'a pas la faveur des devs du noyau, ils le trouvent trop compliqué à intégrer. J'ai toujours eu l'impression que KVM était plutôt destiné à un usage desktop et que Xen était plutôt prévu pour des serveurs. Là j'ai installé un host et un guest xen et faut avouer que ça marche vite et bien. Pas de soucis réseau, très peu de prise de tête, alors qu'avec KVM, c'est déjà plus compliqué. Je suis tiraillé... - LVM: Ca a déjà aidé quelqu'un ? Pour autant que l'on dimensionne bien ses partition, je ne vois pas trop l'intérêt de LVM. A part compliquer l'utilisation des outils de bas niveau. Ca va rester ou est que qu'il vaut mieux y passer ?
Message cité 2 fois Message édité par roscocoltran le 09-09-2008 à 10:11:22 --------------- "Your god is too small", Giordano Bruno, 1548 - 1600 |
Publicité | Posté le 05-09-2008 à 13:52:20 |
M300A Sehr hopfen, vielen IBU, wow! | Pour la messagerie un coup d'oeil à dovecot vaut le coup.
|
roscocoltran L'enfer c'est les utilisateurs | Finalement, j'ai adopté LVM pour un Serveur Xen, on dirait que LVM est la façon la plus simple de faire la backup d'une machine virtuelle sans l'arrêter. On fait un snapshot de la partition LVM qui héberge la machine (attention, il faut installer la machine dans la partition, pas dans un fichier) puis on copie le snapshot. En fait l'idée c'est de créer une partition LVM pour chaque machine. Ca n'a pas l'air mal. Mais je crains un peu cette couche supplémentaire, je ne saurais pas trop réagir en cas de panne ou de fonctionnement bizarre. Je précise que j'ai perdu ma partition /var lors d'un redimensionnement de LVM , qui a entraîné un fsck du diable. Bref c'est tendu.
Au fait vous pouvez oublier syslog, maintenant c'est soit rsyslog soit syslog-ng Message édité par roscocoltran le 06-09-2008 à 17:29:09 --------------- "Your god is too small", Giordano Bruno, 1548 - 1600 |
M300A Sehr hopfen, vielen IBU, wow! | Je préfère syslog-ng d'ailleurs. La conf est très simple à triturer et mes tests on mis en avant une empreinte mémoire inférieure à rsyslog |
xam_orpheus | Ce qu'il manque à syslog-ng c'est la gestion native du TLS, c'est un peu lourd d'avoir un stunnel en plus.
|
zecrazytux |
--------------- Blog photo/récits activités en montagne http://planetcaravan.net |
Publicité | Posté le 08-09-2008 à 14:47:34 |
Profil supprimé | Posté le 08-09-2008 à 22:45:00
|
e_esprit |
--------------- Ce n'est point ma façon de penser qui a fait mon malheur, c'est celle des autres. |
Hrolf |
Message édité par Hrolf le 09-09-2008 à 14:07:05 --------------- Il y a trois sortes de mensonges : les mensonges, les gros mensonges et les statistiques ! |
Gf4x3443 Killing perfection |
Comme beaucoup de choses chez linux, on ne regarde pas l'état de l'art avant. Ce qui n'est pas fait par eux est forcément mauvais, et à refaire. On en arrive là, avec des bêtises genre udev/devfs, kvm/xen, systemtap/dtrace, etc.
usine à gaz, comme quelques unes des fonctionnalités de sécurité dans le noyau linux. Politique et technique, malheureusement.
Ca doit être linux centric ou pas? Tu as d'autres systèmes très bien, des BSD à Solaris, qui sont tout aussi libres.
Dépend du client/serveur, du support NFS idoine dans le système (il y a encore des distros qui n'ont qu'un support correct de AUTH_SYS, et pas de l'API GSS - avec, encore à la clé, des "bidouilles" nécessaires comme la libgssglue). Pour les montages, non. Voir ma signature. Ca ne se monte pas avec un mot de passe, mais un keytab (qui en est l'équivalent, mais host-based et non user-based). NFS4 avec kerberos est vraiment nécessaire dans un environnement ou les clients ne sont pas sécurisés (à peu près la majorité des cas en entreprise aujourd'hui). La solution retenue actuellement reste quand même CIFS avec samba, pour la raison évoquée juste au dessus.
Il faut distinguer le transport du delivery, et de la consultation. Y'a le choix pour chacun ici. Je conseille d'éviter cyrus, qui est une vraie usine à gaz dans sa manière de gérer les mails.
Marketing . Forcément, rivalité redhat vs xensource/citrix, chacun veut sa part du gateau pour controler la virtualisation en entreprise.
Pour être en train de travailler sur le port-xen de netbsd, entre paravirt_ops et le système xenstore/API drivers, l'un rachète pas l'autre. D'ailleurs, certaines personnes se demandent si paravirt_ops était une bonne idée au final.
La manière d'aborder la virtualisation est différente entre KVM et Xen. KVM repose sur un kernel qui utilise (à l'instar de qemu) des instructions pour "émuler" les comportements d'une machine type, y compris drivers. L'overhead est quand même significatif, même s'il est moindre au fil du temps avec l'arrivée des instructions VT. L'OS invité est standalone. Xen est architecturellement un micronoyau, aux fonctionnalités réduites (presque aucun driver), qui délègue la gestion des périphériques à un domaine (dom0 actuellement, ou dans le futur, des driver domain). Les domU, eux, communiquent avec le dom0 via des API standardisées par l'archi Xen, et n'ont quasiment aucun droit. La frontière entre Xen et KVM s'amenuise si on utilise Xen sous HVM, mais garde le concept de micro noyau.
Utile pour la gestion de volumétrie. Quasiment aucun pour un particulier à la maison (si ce n'est des déboires en plus). Avantage indéniable de gérer l'augmentation à chaud de tailles des volumes en raid, chose qui n'est presque infaisable sans. Utiliser aussi pour gérer des miroirs de VM Xen (avec des montages COW). Edit: y'a plein d'autres exemples, tout n'est pas parfait avec LVM(2) mais force est de constater que c'est bien nécessaire Message édité par Gf4x3443 le 09-09-2008 à 16:58:04 --------------- Petit guide Kerberos pour l'administrateur pressé |
zecrazytux |
--------------- Blog photo/récits activités en montagne http://planetcaravan.net |