c'est clair, un PC sous Linux suffit largement à administrer un parc de clients MS. C'est comme ça que je bosse depuis près 1,5 ans et c'est assez peinard.
Par contre, pour les tests utilisateurs, pas moyen, me faut une machine de test sous MS.
Tiens, pendant qu'on y est, la majorité des mes postes de travail sont en win2K Pro. Pas de problèmes avec les licences, on les a payées assez cher... Ce qui m'inquiète plus c'est le jour où je vais "devoir" passer à WinXP Pro (que je ne connais mais alors pas du tout): c'est possible d'installer l'OS sans devoir répondre à 3000 questions demandant le n° de licence, la clef d'activation, l'âge du capitaine , la deuxième clef d'activation,etc... parce que je me vois mal attendre derrière la machine pour répondre aux questions (pas que ça à foutre !).
MS propose un truc qui s'appelle RIS (pour Remote Installation Service je crois). Je ne l'ai jamais utilisé donc, je ne peux pas dire ce que cela vaut.
Néanmoins, unattended est, à mon sens, plus une méthode qu'une application:
- on utilise une distrib linux ultra allégée pour booter une machine.
- une fois la machine bootée, on utilise la puissance de Perl pour faire des choses extraordinaires.
- Au final, on lance dosemu qui lance le setup.exe d'install de windows.
- A la fin, on lance des scripts à la première connexion pour installer les applis.
L'inconvénient est qu'il faut passer du temps pour chaque nouvelle appli qu'on veut intégrer au processus: c'est bien connu, les installations silentieuses sous MS (qui n'est pas trop en faute d'ailleurs sur ce coup là vu que le problème vient essentiellement des paquets d'install pas forcément bien réalisés par les éditeurs de logiciels) sont assez minables. Du coup, il faut trouver comment faire pour automatiser le processus à tout prix (AutoIT est ton ami, min gaillard !)
L'avantage est une modularité exemplaire: j'avais besoin de chercher des infos pour l'installation des postes de travail dans un annuaire LDAP: une petite fonction perl de 20 lignes et c'est réglé !
J'ai même poussé le vice plus loin pour vraiment comprendre le fonctionnement en basant la distrib de boot intégralement sur Debian (je sais, je suis gravement atteint) ,celle de sourceforge est basée sur Fedora Core... et bien , ça marche du feu de dieu.
Néanmoins, il manque encore un truc mais qui, en fait, n'est pas trop du ressort de la technique unattended: c'est, l'installation programmée à distance de programmes.
-Sous linux: pas de problème: LDAP ou autre DB pour centraliser les données+ SSHD + cron + PERL/Shell et le tour est joué.
- Sous MS win: c'est franchement moins simple.
De ce côté , il y a ADAMOTO: http://adamoto.sourceforge.net/(...)
Il permet de gérer et (surtout) de réaliser les déploiements d'applis (en fait des packages) aussi bien dans le monde MS que dans le monde UNIX. Je ne l'ai pas encore testé mais je pense que ça va bientôt se faire.
Quand je pense que j'ai encore des collègues qui font des installs à la main !!! Pour un poste complet (OS+ Applis), faut compter pas loin de 5H pour un type moyen. Avec Unattended, c'est environ 30 secondes...
Bref, y a pas photo et c'est OpenSource based alors mangez-en...
je dis que c'est dommage ! J'aurais bien aimé avoir une carte graphique avec des specs ouvertes histoire d'être complètement dans le bain de l'opensource.
Franchement, j'étais même prêt à me passer des performances de ma NVidia Geforce 4600 (qui date un peu mais qui me suffit largement) pour avoir une carte "libre" et même payer plus cher (enfin sauf si matériellement, ça buggue à outrance et ça arrache les yeux).
Je trouve l'idée du matos libre assez séduisante:
- on sait comment c'est fait: pas de boîte noire.
- les gurus du domaine peuvent contribuer et améliorer le concept.
Bref, pareil que dans le software sauf que, et c'est là la différence majeure à mon avis: ce n'est pas que de la pensée (algos, boucles, traitements, tout ça relève de l'idée) et il faut de quoi réaliser physiquement le projet.
Mais bon, le projet n'est pas enterré, c'est juste le côté réalisation physique qui est remis à plus tard...
C'est dommage parce qu'après le matériel électronique libre, on pourrait envisager plein d'autres trucs libres: la bière (c'est déjà en projet), des bagnoles, des appareils de transformation de l'énergie, des êtres humains...
depuis que j'ai intégré ma boîte, j'ai fait passer l'architecture serveur de 100% MS à 80% Debian...
Franchement, Debian / Mandriva / Redhat /Suse, ce n'est pas vraiment le flacon qui compte : un sysadmin moyen aura autant de mal avec toutes les distribs. De plus, l'intérêt de l'opensource est justement que, d'une manière générale, comme le code est ouvert, la doc de l'appli est bien souvent très étoffée. La communauté est également très active, ce qui fait que, en cas de problèmes, on obtient la réponse finalement assez rapidement.
Pour info, MS me coûte un temps énorme (déploiement, résolutions de bugs, instabilités, tests en tout genre, applis pas assez "verbeuses" pour comprendre les origines du problème, etc...). Et franchement, je me vois mal faire une remontée de bugs chez MS. Je n'ai jamais eu besoin de leur support, en revanche, grâce à quelques éléments de leur communauté, j'ai parfois pu m'en sortir.
LA question qui se pose c'est: qui a vraiment déjà utilisé le support MS ?
Pour l'instant, sur toutes les applis opensource que j'utilise en production, tous les jours, il n'y a jamais eu un seul bug ou problème de fonctionnement que je n'ai sû résoudre et je suis loin d'être un gourou. Avec la quasi-totalité des applis proprios (MS OS inclus), j'ai une liste de bugs non résolus et mon temps passé à les chasser ou les comprendre s'allonge de jours en jours.
Sinon Debian, ça roxe:
- bonne philosophie (pas de commerce, contrat social)
- stabilité (même en testing) donc sur des serveurs, c'est le pied
- finalement, paquets souvent très récents
- Communauté non newbie très réactive
- système de paquets de folie (important en prod)
- Si ça tourne sur une Debian, ça a de très grandes chances de marcher avec une autre distrib.
Si j'étais décideur, je ferais plus confiance à un type qui relève le défi d'utiliser Debian en prod qu'à un clampin de base qui s'autoproclame sysadmin après avoir installé sa distrib comme le dernier MSWinserver... Mais, c'est mon opinion et je ne suis pas toujours décideur ;-)
Heartbeat (de Linux-HA) fait également du actif-passif ou du actif-actif. Tiens, je me demande si HA-Oscar ne l'utilise pas directement.
Néanmoins, un problème se pose avec la réplication des données par DRBD: seul un serveur sur les deux peut monter les partitions sur les volumes DRBD. Dans ces conditions, un SGBD en HA ne peut être posé que sur un serveur. Par contre, on peut très bien envisager de panacher les services HA , tout dépend de la réplication des données.
Ah les clusters (High Avaibility ou High Perfs) ! Une fois qu'on y a gouté, on ne peut plus s'en passer...
En fait, c'est ce que j'ai essayé de faire... sans succès: j'avais des messages d'erreur avec la glibc lors du lancement de firefox (pas de support de cette locale : normal, je n'avais mis que l'UTF8).
Enfin, il faut être honnête, c'est pas franchement utilisable pour le moment.
Je l'utilise en prod depuis 2 mois sur mon serveur bureautique Samba3. C'est vrai que comparé aux droits NT, il y a moins de détails mais ça reste largement fonctionnel.
Bon , pour ceux qui cherchent désespérement comme moi pourquoi ils ne peuvent signer leur télédéclaration, le problème vient des locales.
Je passe sur la manip pour récupérer l'applet pour le certificat, c'est assez décrit depuis 2 ans...
Le bug: le certificat est bien généré, la partie déclarative se passe bien mais, au moment de signer électroniquement, on est redirigé systématiquement vers une page indiquant qu'il y a un problème d'accès. Au début, je pensais que c'était dû à la charge serveur du minéfi mais en fait, le problème vient d'ailleurs puisque ce matin à 7H30, je ne pouvais toujours pas signer...
Après avoir consultés moults forums et discussions, j'ai vu qu'il fallait modifier la variable d'environnement LANG (export LANG=fr_FR). Bon, ça ne marchait pas bien chez moi (je n'ai pas généré les locales pour fr_FR, je suis en fr_FR.UTF8).
Donc, en pratique, il est bon de repasser par la case locales pour éviter de perdre trois heures alors que le moindre windows user a déjà fini depuis longtemps (j'entends encore ma femme insulter ma Debian).
Dans l'ordre:
- dpkg-reconfigure locales
- choisir fr_FR@euro ISO-8859-15 (mais pas UTF8)
- activer fr_FR@euro par défaut
- fermer la session (au besoin redémarrer X)
- se logguer
- ouvrir une console pour voir sous quelle locale on se trouve: locale
- lancer firefox/mozilla (bien configuré avec Java et l'applet dgi)
- suivre le processus de télédéclaration
- ça marche !
chaque fois que je commande des machines (pour le taff), je n'ai jamais aucun problème pour les obtenir sans OS (et surtout sans licence) et ce quelquesoit la marque (Dell, Nec, HP, etc...).
Sinon, pour Sarge, j'ai toujours été étonné par sa bonne adaptation au hardware. Exemple concret, j'ai utilisé deux serveurs Dell PowerEdge 1800SC en RAID SATA pour faire mon cluster HA.
Avant la commande et pendant les comparatifs, j'ai bien regardé les détails sur le matériel inclus dedans. J'ai acheté parce que j'avais vu qu'il y avait au moins des sources pour faire les modules pour le matos spécifique. Donc je pensais être bon pour me compiler un noyau dès la fin de l'installation.
Que nenni: Sarge (et en plus, la netinst) a très bien reconnu du matériel "exotique" comme une carde RAID 5 SATA (aacraid), un contrôleur SCSI intégré (LSI) et un contrôleur SATA intégré (je ne sais plus quoi d'ailleurs). Donc, même pas besoin de recompil; utilisation directe dès la fin de l'installation.
Hors-sujet: un des seuls défaut de Sarge: OpenLDAP en V2.1 (alors que la V2.2 est sortie il y a plus d'un an) et le support TLS/SSL.
je n'ai pas les problèmes que tu indiques et j'ai un serveur en prod avec Apache2 et PHP4. J'utilise la version mpm-prefork d'apache2 qui est celle recommendée par PHP.
Vois si jamais tu n'as pas autre chose comme apache2-mpm-worker d'installé !
bon, j'ai fait le test de chez moi avec une conf à peu près identique. J'arrive à répeter le bug.
En modifiant le fichier du client /etc/ldap/ldap.conf, ça marche !
Donc PHP lit bien ce fichier ce qui est assez suprenant (enfin pour moi ça l'est).
En mattant en mode debug, je n'ai pas l'impression que les transferts se fassent en non cryptés (seuls les DN sont affichés en clair). Bon, pour me punir, un bon man slapd.conf devrait suffir.
je ne saisis pas bien. Le fichier de conf /etc/ldap/ldap.conf est normalement celui du client. Donc, à priori, il faut que sur mon serveur Web (c'est lui qui est client via PHP), je place le fichier /etc/ldap/ldap.conf comme il faut.
Donc, ça implique que PHP va lire ce fichier pour voir comment se comporter en LDAP ? Un tel comportement me semble louche (m'enfin si ça marche...) parce que la doc PHP ne le précise pas (enfin, à priori).
Je me trompe complètement de route ou je suis sur la bonne voie ?
bon ben ça marche comme il faut finalement !
Donc, les seuls changements que j'ai fait sont la mise en place d'ACL par défaut (avec dedans les droits en rwx pour les administrateurs du domaine : le groupe Posix 512 et le groupe Samba dont le SID se termine par 512) et surtout, ajouter des users à ce groupe !!!
Seuls les utilisateurs de ce groupe peuvent changer les ACL sur les fichiers et les répertoires(qui ne leur appartiennent pas). J'ai essayé avec un autre utilisateur hors de ce groupe, il ne peut pas le faire. Par contre, dès que je l'ajoute au groupe 512, pas de problèmes. Dans l'annuaire LDAP, l'ajout ou non du SambaSIDList n'a aucun effet.
De plus, pour un autre groupe que le 512 (un groupe samba d'utilisateurs d'un secteur par exemple), même si je mets les droits en ACL par défaut sur un répertoire , en contrôle total (rwx) pour ce groupe, un utilisateur de ce groupe ne peut pas modifier les ACL.
Tout cela se passe dans Samba et uniquement par Samba. Les ACL Posix sous Linux ne permettent pas ce genre de choses. Pour résumer, dans Samba, le groupe 512 peut modifier les ACL de tous les fichiers ce qui est une bonne chose.
j'ai testé pendant la matinée Apache::ASP. Bon, c'est bien du Perl (perlmod) et je dirais que ça s'installe presque les doigts dans le nez si on utilise des binaires tout faits (fainéantise, quand tu nous tiens...).
J'ai testé les exemples fournis par Apache::ASP qui fonctionnent tous à la perfection. Hélas, en fin de matinée, je me suis risqué à prendre ma pseudo-appli ASP (qui n'est pas du .NET) qui tournait sous IIS4 et à l'intégrer directement.
Après avoir reconfiguré Apache en ajoutant quelques lignes dans httpd.conf, j'ai réussi à faire interpréter le code... sauf que j'ai un maximum d'erreur de compilation.
J'ai essayé de transformer le VB en Perl mais pour l'instant, je n'ai aucun résultat satisfaisant. M'enfin, on est juste au début... néanmoins, si j'ai du code à modifier, ça part plutôt mal (surtout pour faire une transformation VB-> PERL, autant faire de l'ASP=>PHP).
Je teste de ce pas OpenSA.
Je suis lucide, je n'aime pas rêver: une solution qui consisterait à installer et claquer des doigts pour que ça marche, j'ai jamais vu en opensource. Maintenant, tout est une histoire de charge de travail derrière.
j'ai pratiquement eu le même problème que toi: j'ai des postes sous win2K avec un CPD Samba. Pour ma part, je ne bosse que sous Linux et avant la mise en place du CPD Linux, j'ai anticipé mon problème.
Voici la solution que j'ai retenue , qui a le mérite de marcher même si elle est perfectible (largement):
- Désolé mais, faut utiliser un annuaire LDAP. L'avantage c'est que tu regroupes facilement tes comptes POSIX et SAMBA dans un seul endroit.
- Pour les stations win2K, il y a samba: les users vont et viennent dans leur monde connu.
- Pour les stations Unix: deux problèmes à régler: l'authentification, monter le répertoire home qui va bien et éventuellement d'autres emplacements réseau.
- Pour l'authentification à partir de la station cliente, j'utilise nssldap (pour tous les progs qui ont besoin de savoir qui sont les users et les groupes valides) et pam_ldap (pour l'authentification). Avantage de PAM: c'est souple et modulaire: je peux créer une config pour KDM mais pas forcément pour SSH, etc...
- Pour les homes, j'ai un bordel monstrueux: je monte par NFS, l'endroit où je stocke les profils Windows de mes users (enfin, deux niveaux avant en fait pour ne pas écraser et affoler windows). En réglant bien les droits d'accès, j'évite que n'importe qui puisse écraser le contenu du "profil" Linux de l'autre.
- Pour les autres lecteurs réseaux, idem: des lignes à ajouter dans le fstab.
Je conçois que le truc sur NFS est franchement baclé mais ça m'a coûté seulement 1H pour mettre ça en place (doc +serveur + client)...
Configuration sur le serveur:
- OpenLDAP
- OpenSSL (ou GnuTLS pour les Debianneux)
- NFS serveur
- Samba
Configuration requise sur le client:
- installer libpam-nss et configurer avec une communication TLS histoire de ne pas faire transiter les mots de passe en clair.
- installer pam_ldap et le configurer (fichier de conf identique à celui de libpam-nss).
- installer les bons fichiers de config pour les différents progs qui vont utiliser PAM (et surtout les tester avant histoire de ne pas se retrouver avec une machine lockée !!!!).
- installer un client NFS et le configurer (5 secondes)
- régler le fstab pour NFS
Avantage indéniable du LDAP: quand mes users Win2K changent de mot de passe, ça met à jour leur mot de passe POSIX. Donc, deux interfaces différentes mais un seul compte (en fait deux comptes en un).
Au final, ça marche plutôt bien. Quelques idées à prévoir:
- voir pour les quotas sous NFS (si c'est géré ou pas)
- voir si on peut se passer du serveur NFS et utiliser Samba
- tiens, des scripts lancés à la connexion ça serait pas mal des fois aussi sous Linux...
tout est dans le titre: j'ai essayé avec les outils qui vont bien et tout de suite, ça à l'air de mieux marcher (faut encore que je pousse les tests): Panneau de configuration->Système -> profils -> Copier dans... -> droits qui vont bien => Profil mandataire qui à l'air de marcher.
Bon, à priori,les outils Kro$oft doivent modifier un truc dans le profil (NTUSER.DAT) pour qu'il puisse être chargé correctement: la taille change à fond (elle double en fait).
Finalement, j'aurai droit quand même aux mandatory profiles qui vont bien m'aider (faut dire, y a du pain sur la planche).
Désolé de vous avoir embêté avec un pur problème Win2K mais j'avais des soupçons sur Samba qui, au final, se révèle innocent !
Bon, en fait, c'était marqué dans le man de setfacl. J'ai parcouru la mailing list des dev, quelques complaintes à ce sujet mais pas d'implémentation réelle derrière.
Va falloir se la jouer plus fin que ça: déjà , je vais me débrouiller avec les Defaults ACL sur les répertoires, ça permettra de mettre au moins des droits d'accès qui vont bien.
Ensuite, en cas de soucis, il me reste toujours mon compte root pour faire le job (changer les ACL). Si ça devient ingérable, un petit script qui "chownise" à outrance...pas terrible mais à voir.
Ben... le proprio s'il a w, le groupe s'il a w (y compris les users qui ont ce groupe comme secondaire), et "le reste de l'univers" s'ils ont w... enfin je crois... non ?
Ben non...
J'ai fait un petit test avec les élements suivants:
- admin1 et admin2 font partie d'un groupe (primaire) administrateurs.
- j'ai créé un groupe groupe1 d'utilisateurs et aussi une groupe2 d'utilisateurs.
- sous l'identité de admin1, j'ai créé une ACL sur un fichier (qui appartient à admin1).
- voici ce qui se passe sous l'identité d'admin2:
getfacl ./fichier_test3.acl
# file: fichier_test3.acl
# owner: admin1
# group: administrateurs
user::rwx
group::rwx
group:groupe1:r-x
mask::rwx
other::rwx
medspxdeb:/data/share/ADMIN$ setfacl -m g:groupe2:rx ./fichier_test3.acl
setfacl: ./fichier_test3.acl: Opération non permise
J'ai volontairement mis les droits au max à tout le monde juste pour voir: pas moyen que ça marche. Par contre, dès que je reviens à admin1 ou à root, je peux changer l'ACL.
J'avais pensé au vscan mais il paraît qu'il réduit les perfs de Samba comme peau de Chagrin...
Pour ma part, je conserve un serveur MS Win qui utilise NAV Corpo (bien proprio tout ça). Il se charge de la protection en temps réel.
Sur le serveur Linux, un scan avec clamav. Néanmoins, le scan prend beaucoup de temps (de mémoire j'avais calculé de l'ordre de 6H pour environ 200Go) et je ne le lance que la nuit...
Bon maintenant, c'est facile quand on a les deux (NAV et Clam) mais je n'ai pas le choix (NAV imposé par la boîte)...
Plus sérieusement, une appli opensource est indispensable: j'en ai marre de ne pas pouvoir mater le code pour voir d'où peuvent provenir les bugs.
Pour le problème des pointeuses, je suis prêt à en acheter des "compatibles"... Mais je peux faire du reverse avec celles dont je dispose (en fait, c'est pratiquement déjà fait !).
Même s'il y a des adaptations, je prends parce que j'en ai vraiment assez de claquer du temps sur cet élément qui bugge à outrance. Il ne se passe pas une semaine sans que le comportement qui, auparavant était à peu près stable, dégénère totalement.
Au niveau de fournir des $$ pour faire le dev, je ne pense pas que ça passe au niveau du boss. Néanmoins, s'il n'y a rien, je me lance dans un code tout propre: le principe est assez simple et les besoins sont, au final, assez limités. Pas de calculs différentiels, pas de filtres alambiqués. Juste besoin d'une petite DB (forcément sous pgsql :!) et une interface Web pour la consultation (+la reprise des données des badgeuses).
Mais bon, s'il existe déjà un truc, même un embryon...
C'est bizarre mais, c'est un truc que presque toutes les boîtes doivent avoir. Donc ça m'étonne qu'il n'y ait rien en libre.
bien joué pour l'OS level...
En effet, mon OS level était à 32 (avant la migration, j'ai un domaine temporaire pour tests et si je mets un OS level trop important, l'autre domaine a du mal à être visible). Je viens de le passer à 66 et ça marche correctement.
Personnellement, je ne fais pas confiance aux os non stables de redmond, et donc, j'ai forcé la valeur de ce paramètre à la valeur la plus haute : 255.
Moi non plus....
J'ai aussi supprimé le cache (/var/cache/samba/browse.dat) mais je doute que cela y soit pour quelquechose: les entrées étaient bonnes.
mon opinion sur cette emission rejoint la tienne. J'apprécie ce sens critique. Même si , de prime abord, on peut facilement penser qu'il ne s'agit là que de journalistes en train de se masturber le cerveau sur des détails (bref, un peu fouille merde). Toutefois, au bout d'un an, je trouve que les questions posées et les sujets soulevés sont assez pertinents et mettent le doigt là où ça fait mal. Ca permet de regarder la télé avec un regard un peu différent (en tout cas moins consensuel...).
Pour en revenir à un sujet plus Linuxien, j'avoue que je suis déçu par les illustrations des sites internets à l'antenne: tout se fait avec MS IE alors qu'on pourrait se passer des éléments susceptibles d'encourager la pratique et l'usage de ce soft: seul le contenu des pages web est intéressant; le reste (cadre, titre de la fenêtre, habillage du navigateur, etc...), on s'en fout.
Vous me direz que s'ils avaient utilisé Mozilla je n'aurais pas eu le même discours et bien je vous répondrais par oui... j'ai choisi mon camp !
[^] # Re: Administration des PC
Posté par Médéric RIBREUX (site web personnel) . En réponse au journal Microsoft récidive.... Évalué à 3.
c'est clair, un PC sous Linux suffit largement à administrer un parc de clients MS. C'est comme ça que je bosse depuis près 1,5 ans et c'est assez peinard.
Par contre, pour les tests utilisateurs, pas moyen, me faut une machine de test sous MS.
Tiens, pendant qu'on y est, la majorité des mes postes de travail sont en win2K Pro. Pas de problèmes avec les licences, on les a payées assez cher... Ce qui m'inquiète plus c'est le jour où je vais "devoir" passer à WinXP Pro (que je ne connais mais alors pas du tout): c'est possible d'installer l'OS sans devoir répondre à 3000 questions demandant le n° de licence, la clef d'activation, l'âge du capitaine , la deuxième clef d'activation,etc... parce que je me vois mal attendre derrière la machine pour répondre aux questions (pas que ça à foutre !).
[^] # Re: Unattended différent de celui de MS ?
Posté par Médéric RIBREUX (site web personnel) . En réponse au journal L'attirail de l'administrateur de parc hétérogène. Évalué à 4.
MS propose un truc qui s'appelle RIS (pour Remote Installation Service je crois). Je ne l'ai jamais utilisé donc, je ne peux pas dire ce que cela vaut.
Néanmoins, unattended est, à mon sens, plus une méthode qu'une application:
- on utilise une distrib linux ultra allégée pour booter une machine.
- une fois la machine bootée, on utilise la puissance de Perl pour faire des choses extraordinaires.
- Au final, on lance dosemu qui lance le setup.exe d'install de windows.
- A la fin, on lance des scripts à la première connexion pour installer les applis.
L'inconvénient est qu'il faut passer du temps pour chaque nouvelle appli qu'on veut intégrer au processus: c'est bien connu, les installations silentieuses sous MS (qui n'est pas trop en faute d'ailleurs sur ce coup là vu que le problème vient essentiellement des paquets d'install pas forcément bien réalisés par les éditeurs de logiciels) sont assez minables. Du coup, il faut trouver comment faire pour automatiser le processus à tout prix (AutoIT est ton ami, min gaillard !)
L'avantage est une modularité exemplaire: j'avais besoin de chercher des infos pour l'installation des postes de travail dans un annuaire LDAP: une petite fonction perl de 20 lignes et c'est réglé !
J'ai même poussé le vice plus loin pour vraiment comprendre le fonctionnement en basant la distrib de boot intégralement sur Debian (je sais, je suis gravement atteint) ,celle de sourceforge est basée sur Fedora Core... et bien , ça marche du feu de dieu.
Néanmoins, il manque encore un truc mais qui, en fait, n'est pas trop du ressort de la technique unattended: c'est, l'installation programmée à distance de programmes.
-Sous linux: pas de problème: LDAP ou autre DB pour centraliser les données+ SSHD + cron + PERL/Shell et le tour est joué.
- Sous MS win: c'est franchement moins simple.
De ce côté , il y a ADAMOTO: http://adamoto.sourceforge.net/(...)
Il permet de gérer et (surtout) de réaliser les déploiements d'applis (en fait des packages) aussi bien dans le monde MS que dans le monde UNIX. Je ne l'ai pas encore testé mais je pense que ça va bientôt se faire.
Quand je pense que j'ai encore des collègues qui font des installs à la main !!! Pour un poste complet (OS+ Applis), faut compter pas loin de 5H pour un type moyen. Avec Unattended, c'est environ 30 secondes...
Bref, y a pas photo et c'est OpenSource based alors mangez-en...
# C'est dommage !
Posté par Médéric RIBREUX (site web personnel) . En réponse à la dépêche Le projet OpenGraphics abandonné par Tech Source. Évalué à 10.
je dis que c'est dommage ! J'aurais bien aimé avoir une carte graphique avec des specs ouvertes histoire d'être complètement dans le bain de l'opensource.
Franchement, j'étais même prêt à me passer des performances de ma NVidia Geforce 4600 (qui date un peu mais qui me suffit largement) pour avoir une carte "libre" et même payer plus cher (enfin sauf si matériellement, ça buggue à outrance et ça arrache les yeux).
Je trouve l'idée du matos libre assez séduisante:
- on sait comment c'est fait: pas de boîte noire.
- les gurus du domaine peuvent contribuer et améliorer le concept.
Bref, pareil que dans le software sauf que, et c'est là la différence majeure à mon avis: ce n'est pas que de la pensée (algos, boucles, traitements, tout ça relève de l'idée) et il faut de quoi réaliser physiquement le projet.
Mais bon, le projet n'est pas enterré, c'est juste le côté réalisation physique qui est remis à plus tard...
C'est dommage parce qu'après le matériel électronique libre, on pourrait envisager plein d'autres trucs libres: la bière (c'est déjà en projet), des bagnoles, des appareils de transformation de l'énergie, des êtres humains...
[^] # Re: le support pose probleme
Posté par Médéric RIBREUX (site web personnel) . En réponse au message Qui utilise Debian ?. Évalué à 1.
depuis que j'ai intégré ma boîte, j'ai fait passer l'architecture serveur de 100% MS à 80% Debian...
Franchement, Debian / Mandriva / Redhat /Suse, ce n'est pas vraiment le flacon qui compte : un sysadmin moyen aura autant de mal avec toutes les distribs. De plus, l'intérêt de l'opensource est justement que, d'une manière générale, comme le code est ouvert, la doc de l'appli est bien souvent très étoffée. La communauté est également très active, ce qui fait que, en cas de problèmes, on obtient la réponse finalement assez rapidement.
Pour info, MS me coûte un temps énorme (déploiement, résolutions de bugs, instabilités, tests en tout genre, applis pas assez "verbeuses" pour comprendre les origines du problème, etc...). Et franchement, je me vois mal faire une remontée de bugs chez MS. Je n'ai jamais eu besoin de leur support, en revanche, grâce à quelques éléments de leur communauté, j'ai parfois pu m'en sortir.
LA question qui se pose c'est: qui a vraiment déjà utilisé le support MS ?
Pour l'instant, sur toutes les applis opensource que j'utilise en production, tous les jours, il n'y a jamais eu un seul bug ou problème de fonctionnement que je n'ai sû résoudre et je suis loin d'être un gourou. Avec la quasi-totalité des applis proprios (MS OS inclus), j'ai une liste de bugs non résolus et mon temps passé à les chasser ou les comprendre s'allonge de jours en jours.
Sinon Debian, ça roxe:
- bonne philosophie (pas de commerce, contrat social)
- stabilité (même en testing) donc sur des serveurs, c'est le pied
- finalement, paquets souvent très récents
- Communauté non newbie très réactive
- système de paquets de folie (important en prod)
- Si ça tourne sur une Debian, ça a de très grandes chances de marcher avec une autre distrib.
Si j'étais décideur, je ferais plus confiance à un type qui relève le défi d'utiliser Debian en prod qu'à un clampin de base qui s'autoproclame sysadmin après avoir installé sa distrib comme le dernier MSWinserver... Mais, c'est mon opinion et je ne suis pas toujours décideur ;-)
[^] # Re: HA oscar ou openssi
Posté par Médéric RIBREUX (site web personnel) . En réponse à la dépêche OSCAR sort en version 4.1. Évalué à 2.
Heartbeat (de Linux-HA) fait également du actif-passif ou du actif-actif. Tiens, je me demande si HA-Oscar ne l'utilise pas directement.
Néanmoins, un problème se pose avec la réplication des données par DRBD: seul un serveur sur les deux peut monter les partitions sur les volumes DRBD. Dans ces conditions, un SGBD en HA ne peut être posé que sur un serveur. Par contre, on peut très bien envisager de panacher les services HA , tout dépend de la réplication des données.
Ah les clusters (High Avaibility ou High Perfs) ! Une fois qu'on y a gouté, on ne peut plus s'en passer...
[^] # Re: Télédéclaration sous Sarge
Posté par Médéric RIBREUX (site web personnel) . En réponse au journal Les impot en ligne c'est bien, mais.... Évalué à 1.
[^] # Re: ACL
Posté par Médéric RIBREUX (site web personnel) . En réponse au journal Les droits sous Longhorn : un plagiat d'Unix ?. Évalué à 2.
Je l'utilise en prod depuis 2 mois sur mon serveur bureautique Samba3. C'est vrai que comparé aux droits NT, il y a moins de détails mais ça reste largement fonctionnel.
# Ca marche mais y a de la config dans l'air
Posté par Médéric RIBREUX (site web personnel) . En réponse au message bug télédéclaration. Évalué à 2.
mate le journal suivant:
https://linuxfr.org/~lordcow/17646.html(...)
Pour info, l'applet créé un répertoire teleir dans le home du user.
# Télédéclaration sous Sarge
Posté par Médéric RIBREUX (site web personnel) . En réponse au journal Les impot en ligne c'est bien, mais.... Évalué à 2.
Je passe sur la manip pour récupérer l'applet pour le certificat, c'est assez décrit depuis 2 ans...
Le bug: le certificat est bien généré, la partie déclarative se passe bien mais, au moment de signer électroniquement, on est redirigé systématiquement vers une page indiquant qu'il y a un problème d'accès. Au début, je pensais que c'était dû à la charge serveur du minéfi mais en fait, le problème vient d'ailleurs puisque ce matin à 7H30, je ne pouvais toujours pas signer...
Après avoir consultés moults forums et discussions, j'ai vu qu'il fallait modifier la variable d'environnement LANG (export LANG=fr_FR). Bon, ça ne marchait pas bien chez moi (je n'ai pas généré les locales pour fr_FR, je suis en fr_FR.UTF8).
Donc, en pratique, il est bon de repasser par la case locales pour éviter de perdre trois heures alors que le moindre windows user a déjà fini depuis longtemps (j'entends encore ma femme insulter ma Debian).
Dans l'ordre:
- dpkg-reconfigure locales
- choisir fr_FR@euro ISO-8859-15 (mais pas UTF8)
- activer fr_FR@euro par défaut
- fermer la session (au besoin redémarrer X)
- se logguer
- ouvrir une console pour voir sous quelle locale on se trouve: locale
- lancer firefox/mozilla (bien configuré avec Java et l'applet dgi)
- suivre le processus de télédéclaration
- ça marche !
[^] # Re: Dell...
Posté par Médéric RIBREUX (site web personnel) . En réponse au message Quel type UC ?. Évalué à 1.
chaque fois que je commande des machines (pour le taff), je n'ai jamais aucun problème pour les obtenir sans OS (et surtout sans licence) et ce quelquesoit la marque (Dell, Nec, HP, etc...).
Sinon, pour Sarge, j'ai toujours été étonné par sa bonne adaptation au hardware. Exemple concret, j'ai utilisé deux serveurs Dell PowerEdge 1800SC en RAID SATA pour faire mon cluster HA.
Avant la commande et pendant les comparatifs, j'ai bien regardé les détails sur le matériel inclus dedans. J'ai acheté parce que j'avais vu qu'il y avait au moins des sources pour faire les modules pour le matos spécifique. Donc je pensais être bon pour me compiler un noyau dès la fin de l'installation.
Que nenni: Sarge (et en plus, la netinst) a très bien reconnu du matériel "exotique" comme une carde RAID 5 SATA (aacraid), un contrôleur SCSI intégré (LSI) et un contrôleur SATA intégré (je ne sais plus quoi d'ailleurs). Donc, même pas besoin de recompil; utilisation directe dès la fin de l'installation.
Hors-sujet: un des seuls défaut de Sarge: OpenLDAP en V2.1 (alors que la V2.2 est sortie il y a plus d'un an) et le support TLS/SSL.
# apache2-mpm-prefork
Posté par Médéric RIBREUX (site web personnel) . En réponse au message Apache 2 et php4 sur sarge . Segmentation fault sur apache. Évalué à 2.
je n'ai pas les problèmes que tu indiques et j'ai un serveur en prod avec Apache2 et PHP4. J'utilise la version mpm-prefork d'apache2 qui est celle recommendée par PHP.
Vois si jamais tu n'as pas autre chose comme apache2-mpm-worker d'installé !
[^] # Re: config cliente LDAP
Posté par Médéric RIBREUX (site web personnel) . En réponse au message Sarge PHP ldaps. Évalué à 1.
bon, j'ai fait le test de chez moi avec une conf à peu près identique. J'arrive à répeter le bug.
En modifiant le fichier du client /etc/ldap/ldap.conf, ça marche !
Donc PHP lit bien ce fichier ce qui est assez suprenant (enfin pour moi ça l'est).
En mattant en mode debug, je n'ai pas l'impression que les transferts se fassent en non cryptés (seuls les DN sont affichés en clair). Bon, pour me punir, un bon man slapd.conf devrait suffir.
[^] # Re: config cliente LDAP
Posté par Médéric RIBREUX (site web personnel) . En réponse au message Sarge PHP ldaps. Évalué à 1.
je ne saisis pas bien. Le fichier de conf /etc/ldap/ldap.conf est normalement celui du client. Donc, à priori, il faut que sur mon serveur Web (c'est lui qui est client via PHP), je place le fichier /etc/ldap/ldap.conf comme il faut.
Donc, ça implique que PHP va lire ce fichier pour voir comment se comporter en LDAP ? Un tel comportement me semble louche (m'enfin si ça marche...) parce que la doc PHP ne le précise pas (enfin, à priori).
Je me trompe complètement de route ou je suis sur la bonne voie ?
[^] # Re: UP
Posté par Médéric RIBREUX (site web personnel) . En réponse au journal Samba + ACL: the mistery machine !. Évalué à 2.
vérification faite, c'est ça !!!
Franchement, j'ai honte d'avoir remué tout un foin pour si peu.
Merci à tous pour votre collaboration.
# UP
Posté par Médéric RIBREUX (site web personnel) . En réponse au journal Samba + ACL: the mistery machine !. Évalué à 1.
bon ben ça marche comme il faut finalement !
Donc, les seuls changements que j'ai fait sont la mise en place d'ACL par défaut (avec dedans les droits en rwx pour les administrateurs du domaine : le groupe Posix 512 et le groupe Samba dont le SID se termine par 512) et surtout, ajouter des users à ce groupe !!!
Seuls les utilisateurs de ce groupe peuvent changer les ACL sur les fichiers et les répertoires(qui ne leur appartiennent pas). J'ai essayé avec un autre utilisateur hors de ce groupe, il ne peut pas le faire. Par contre, dès que je l'ajoute au groupe 512, pas de problèmes. Dans l'annuaire LDAP, l'ajout ou non du SambaSIDList n'a aucun effet.
De plus, pour un autre groupe que le 512 (un groupe samba d'utilisateurs d'un secteur par exemple), même si je mets les droits en ACL par défaut sur un répertoire , en contrôle total (rwx) pour ce groupe, un utilisateur de ce groupe ne peut pas modifier les ACL.
Tout cela se passe dans Samba et uniquement par Samba. Les ACL Posix sous Linux ne permettent pas ce genre de choses. Pour résumer, dans Samba, le groupe 512 peut modifier les ACL de tous les fichiers ce qui est une bonne chose.
# Up
Posté par Médéric RIBREUX (site web personnel) . En réponse au journal On va tester le Apache-ASP !!!. Évalué à 1.
j'ai testé pendant la matinée Apache::ASP. Bon, c'est bien du Perl (perlmod) et je dirais que ça s'installe presque les doigts dans le nez si on utilise des binaires tout faits (fainéantise, quand tu nous tiens...).
J'ai testé les exemples fournis par Apache::ASP qui fonctionnent tous à la perfection. Hélas, en fin de matinée, je me suis risqué à prendre ma pseudo-appli ASP (qui n'est pas du .NET) qui tournait sous IIS4 et à l'intégrer directement.
Après avoir reconfiguré Apache en ajoutant quelques lignes dans httpd.conf, j'ai réussi à faire interpréter le code... sauf que j'ai un maximum d'erreur de compilation.
J'ai essayé de transformer le VB en Perl mais pour l'instant, je n'ai aucun résultat satisfaisant. M'enfin, on est juste au début... néanmoins, si j'ai du code à modifier, ça part plutôt mal (surtout pour faire une transformation VB-> PERL, autant faire de l'ASP=>PHP).
Je teste de ce pas OpenSA.
Je suis lucide, je n'aime pas rêver: une solution qui consisterait à installer et claquer des doigts pour que ça marche, j'ai jamais vu en opensource. Maintenant, tout est une histoire de charge de travail derrière.
# LDAP est ton ami...
Posté par Médéric RIBREUX (site web personnel) . En réponse au message Monter un réseau de Linux.. Évalué à 2.
j'ai pratiquement eu le même problème que toi: j'ai des postes sous win2K avec un CPD Samba. Pour ma part, je ne bosse que sous Linux et avant la mise en place du CPD Linux, j'ai anticipé mon problème.
Voici la solution que j'ai retenue , qui a le mérite de marcher même si elle est perfectible (largement):
- Désolé mais, faut utiliser un annuaire LDAP. L'avantage c'est que tu regroupes facilement tes comptes POSIX et SAMBA dans un seul endroit.
- Pour les stations win2K, il y a samba: les users vont et viennent dans leur monde connu.
- Pour les stations Unix: deux problèmes à régler: l'authentification, monter le répertoire home qui va bien et éventuellement d'autres emplacements réseau.
- Pour l'authentification à partir de la station cliente, j'utilise nssldap (pour tous les progs qui ont besoin de savoir qui sont les users et les groupes valides) et pam_ldap (pour l'authentification). Avantage de PAM: c'est souple et modulaire: je peux créer une config pour KDM mais pas forcément pour SSH, etc...
- Pour les homes, j'ai un bordel monstrueux: je monte par NFS, l'endroit où je stocke les profils Windows de mes users (enfin, deux niveaux avant en fait pour ne pas écraser et affoler windows). En réglant bien les droits d'accès, j'évite que n'importe qui puisse écraser le contenu du "profil" Linux de l'autre.
- Pour les autres lecteurs réseaux, idem: des lignes à ajouter dans le fstab.
Je conçois que le truc sur NFS est franchement baclé mais ça m'a coûté seulement 1H pour mettre ça en place (doc +serveur + client)...
Configuration sur le serveur:
- OpenLDAP
- OpenSSL (ou GnuTLS pour les Debianneux)
- NFS serveur
- Samba
Configuration requise sur le client:
- installer libpam-nss et configurer avec une communication TLS histoire de ne pas faire transiter les mots de passe en clair.
- installer pam_ldap et le configurer (fichier de conf identique à celui de libpam-nss).
- installer les bons fichiers de config pour les différents progs qui vont utiliser PAM (et surtout les tester avant histoire de ne pas se retrouver avec une machine lockée !!!!).
- installer un client NFS et le configurer (5 secondes)
- régler le fstab pour NFS
Avantage indéniable du LDAP: quand mes users Win2K changent de mot de passe, ça met à jour leur mot de passe POSIX. Donc, deux interfaces différentes mais un seul compte (en fait deux comptes en un).
Au final, ça marche plutôt bien. Quelques idées à prévoir:
- voir pour les quotas sous NFS (si c'est géré ou pas)
- voir si on peut se passer du serveur NFS et utiliser Samba
- tiens, des scripts lancés à la connexion ça serait pas mal des fois aussi sous Linux...
# Bon ben en fait faut utiliser les outils Kro$oft
Posté par Médéric RIBREUX (site web personnel) . En réponse au message Samba et profils obligatoires non chargés :-\. Évalué à 1.
tout est dans le titre: j'ai essayé avec les outils qui vont bien et tout de suite, ça à l'air de mieux marcher (faut encore que je pousse les tests): Panneau de configuration->Système -> profils -> Copier dans... -> droits qui vont bien => Profil mandataire qui à l'air de marcher.
Bon, à priori,les outils Kro$oft doivent modifier un truc dans le profil (NTUSER.DAT) pour qu'il puisse être chargé correctement: la taille change à fond (elle double en fait).
Finalement, j'aurai droit quand même aux mandatory profiles qui vont bien m'aider (faut dire, y a du pain sur la planche).
Désolé de vous avoir embêté avec un pur problème Win2K mais j'avais des soupçons sur Samba qui, au final, se révèle innocent !
[^] # Re: Droits de modifs d'ACLs
Posté par Médéric RIBREUX (site web personnel) . En réponse au message Samba et ACL Posix. Évalué à 1.
Bon, en fait, c'était marqué dans le man de setfacl. J'ai parcouru la mailing list des dev, quelques complaintes à ce sujet mais pas d'implémentation réelle derrière.
Va falloir se la jouer plus fin que ça: déjà , je vais me débrouiller avec les Defaults ACL sur les répertoires, ça permettra de mettre au moins des droits d'accès qui vont bien.
Ensuite, en cas de soucis, il me reste toujours mon compte root pour faire le job (changer les ACL). Si ça devient ingérable, un petit script qui "chownise" à outrance...pas terrible mais à voir.
[^] # Re: Droits de modifs d'ACLs
Posté par Médéric RIBREUX (site web personnel) . En réponse au message Samba et ACL Posix. Évalué à 1.
Ben non...
J'ai fait un petit test avec les élements suivants:
- admin1 et admin2 font partie d'un groupe (primaire) administrateurs.
- j'ai créé un groupe groupe1 d'utilisateurs et aussi une groupe2 d'utilisateurs.
- sous l'identité de admin1, j'ai créé une ACL sur un fichier (qui appartient à admin1).
- voici ce qui se passe sous l'identité d'admin2:
getfacl ./fichier_test3.acl
# file: fichier_test3.acl
# owner: admin1
# group: administrateurs
user::rwx
group::rwx
group:groupe1:r-x
mask::rwx
other::rwx
medspxdeb:/data/share/ADMIN$ setfacl -m g:groupe2:rx ./fichier_test3.acl
setfacl: ./fichier_test3.acl: Opération non permise
J'ai volontairement mis les droits au max à tout le monde juste pour voir: pas moyen que ça marche. Par contre, dès que je reviens à admin1 ou à root, je peux changer l'ACL.
# Attention aux perfs...
Posté par Médéric RIBREUX (site web personnel) . En réponse au message Samba et Clamav. Évalué à 1.
Pour ma part, je conserve un serveur MS Win qui utilise NAV Corpo (bien proprio tout ça). Il se charge de la protection en temps réel.
Sur le serveur Linux, un scan avec clamav. Néanmoins, le scan prend beaucoup de temps (de mémoire j'avais calculé de l'ordre de 6H pour environ 200Go) et je ne le lance que la nuit...
Bon maintenant, c'est facile quand on a les deux (NAV et Clam) mais je n'ai pas le choix (NAV imposé par la boîte)...
A voir, un lien vers un site qui, à l'époque était pas mal pour les infos:
https://etud.epita.fr/~nowick_c/index.php?publications.html(...)
[^] # Re: libre mais pas forcément gratuite, hein ?
Posté par Médéric RIBREUX (site web personnel) . En réponse au message Application de gestion des employés. Évalué à 1.
Plus sérieusement, une appli opensource est indispensable: j'en ai marre de ne pas pouvoir mater le code pour voir d'où peuvent provenir les bugs.
Pour le problème des pointeuses, je suis prêt à en acheter des "compatibles"... Mais je peux faire du reverse avec celles dont je dispose (en fait, c'est pratiquement déjà fait !).
Même s'il y a des adaptations, je prends parce que j'en ai vraiment assez de claquer du temps sur cet élément qui bugge à outrance. Il ne se passe pas une semaine sans que le comportement qui, auparavant était à peu près stable, dégénère totalement.
Au niveau de fournir des $$ pour faire le dev, je ne pense pas que ça passe au niveau du boss. Néanmoins, s'il n'y a rien, je me lance dans un code tout propre: le principe est assez simple et les besoins sont, au final, assez limités. Pas de calculs différentiels, pas de filtres alambiqués. Juste besoin d'une petite DB (forcément sous pgsql :!) et une interface Web pour la consultation (+la reprise des données des badgeuses).
Mais bon, s'il existe déjà un truc, même un embryon...
C'est bizarre mais, c'est un truc que presque toutes les boîtes doivent avoir. Donc ça m'étonne qu'il n'y ait rien en libre.
# Ben c'est bien...
Posté par Médéric RIBREUX (site web personnel) . En réponse à la dépêche Délégation de pouvoirs avec un contrôleur de domaine Samba. Évalué à 1.
Va falloir que je recommence...
Fonctionnalité plus: avoir des "admins" autres que root. C'est plutôt bien (utile pour partir en congés et éviter de partager un compte root).
Ya pu ka attendre l'intégration dans Debian !
[^] # Re: Piste ?
Posté par Médéric RIBREUX (site web personnel) . En réponse au message Samba3: Serveur inaccessible par le nom netbios. Évalué à 2.
bien joué pour l'OS level...
En effet, mon OS level était à 32 (avant la migration, j'ai un domaine temporaire pour tests et si je mets un OS level trop important, l'autre domaine a du mal à être visible). Je viens de le passer à 66 et ça marche correctement.
Moi non plus....
J'ai aussi supprimé le cache (/var/cache/samba/browse.dat) mais je doute que cela y soit pour quelquechose: les entrées étaient bonnes.
Merci !
# Mon avis sur ASI
Posté par Médéric RIBREUX (site web personnel) . En réponse au journal Emissions sur France5.... Évalué à 3.
mon opinion sur cette emission rejoint la tienne. J'apprécie ce sens critique. Même si , de prime abord, on peut facilement penser qu'il ne s'agit là que de journalistes en train de se masturber le cerveau sur des détails (bref, un peu fouille merde). Toutefois, au bout d'un an, je trouve que les questions posées et les sujets soulevés sont assez pertinents et mettent le doigt là où ça fait mal. Ca permet de regarder la télé avec un regard un peu différent (en tout cas moins consensuel...).
Pour en revenir à un sujet plus Linuxien, j'avoue que je suis déçu par les illustrations des sites internets à l'antenne: tout se fait avec MS IE alors qu'on pourrait se passer des éléments susceptibles d'encourager la pratique et l'usage de ce soft: seul le contenu des pages web est intéressant; le reste (cadre, titre de la fenêtre, habillage du navigateur, etc...), on s'en fout.
Vous me direz que s'ils avaient utilisé Mozilla je n'aurais pas eu le même discours et bien je vous répondrais par oui... j'ai choisi mon camp !