totof2000 a écrit 9656 commentaires

Par contre, sur le cas GUI Cluster Suite de Redhat : je suis très étonné d'une chose : que l'interface ne soit pas déportable. Vraiment très étonné. -> Es tu sûr que tu ne puisses pas utiliser la cluster Suite depuis ton laptop Redhat, en ciblant ton cluster distant ? Ainsi tu ne déportes pas l'affichage de la GUI, mais la GUI elle même : et la consommation réseau (ports, bp) se résume à la synchronisation de tes fichiers de conf.


La difficulté est que je n'ai pas de laptop RedHat à l'extérieur. J'ai réussi à trouer une autre machine en interne (pas sous redhat d'ailleurs), export display et ensuite me connecter via VNC sur cette machine, avec un débit réseau pourri. Si j'avais eu un laptop redhat, je n'aurais pas été ennuyé.

Perso je crois que je ferais un rsync sur clefs entre mon poste d'admin et la machine centrale du cluster. (Et ça me semble étrange que cela ne soit pas intégré de base...bah de toutes façons c'est possible)

Mon poste de travail est sous Windows. :(. Pour la plupart des environnements que j'ai à gérer, je dispose d'un environnement x (au pire des cas, je peux travailler avec exceed), mais là je suis sur un cas particulier : ce n'est pas possible de façon simple.

Sinon, Conga c'est une interface web ... A moins que quelque chose m'ait échappé, toujours est-il que je n'ai pas

Oui, et tu en connais un bon en mode texte ? De préférence qui soitinstallé par défaut dans les distribs car il est interdit sur une machine de prod d'ajouter comme on veut ce genre de soft.

Oui et je ne trouve pas la commande. Il y a bien une commande permettant d'initialiser le fichier de conf, ajouter des noeuds dans le cluster, mais elle ne permet pas de définir les ressources ni de créer un failover domain.

Je n'ao pas mis d'attributs expres, le fait qu'il y en ait ne change pas grand chose dans les deux cas.

ce n'est pas "mon" xml .....

[masection]
typeDOption="valeur"

GRRRR!!!!! Je recite l'exmple :
Voici un exemple de fichier de configuration XML :


<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE kcfg SYSTEM "http://www.kde.org/standards/kcfg/1.0/kcfg.dtd">
<kcfg>
<kcfgfile name="korganizerrc"/>
<group name="General">
<entry type="Bool" key="Auto Save">
<label>Enable automatic saving of calendar</label>
<default>true</default>
</entry>
<entry type="Int" key="Auto Save Interval">
<default>10</default>
</entry>
</group>
</kcfg>

Il a le même effet que :

[General]
Auto Save=false
Auto Save Interval=25

un exemple :
http://docs.kde.org/stable/fr/kdebase-runtime/userguide/conf(...)

L'exemple à la fin me fait d'ailleurs bien rire :

Je cite :

Voici un exemple de fichier de configuration XML.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE kcfg SYSTEM "http://www.kde.org/standards/kcfg/1.0/kcfg.dtd">




Enable automatic saving of calendar
true


10




Il a le même effet que :

[General]
Auto Save=false
Auto Save Interval=25


Les fichiers ini à la Windows n'étaient pas mal fichus pour ce qui me reste en mémoire.

Bon je reprends ...
arbre {
branche {
fruit {
}
fruit {
}
branche {
fruit
}
}
}

<arbre>
<branches>
<fruit ... />
<fruit ... />
</branche>
<branche>
<fruit ... />
</branches>
</arbre>

Et si on parle de lisibilité :
<arbre><branches><fruit ... /><fruit ... /></branche><branche>
<fruit ... /></branches></arbre>


le <branches> ... </branches> est volontaire : c'est ce qu'on rencontre dans RedHAt Cluster avec les balises <clusternodes> <node></node></clusternodes>

Et pour la longueur :

<Supercalifragilisticexpialidocious>
<balise1>.....</balise1>
</Supercalifragilisticexpialidocious>

Supercalifragilisticexpialidocious {
balise1{ ... }
}

merci :)

Alors oui il y a de plus en plus de dev qui vont à la facilité, et dans certain cas on pourrait utiliser quelque chose de plus léger . Mais j'ai plus l'impression que certains font une réaction allergique par principe ou simplement par ce qu'ils ne veulent pas prendre 10 minutes pour se former. C'est peut être un peu plus verbeux, mais en utilisant les outils adéquats il a aussi des avantages, tant pour le développeur que pour l'utilisateur:
MA réaction n'est ni une réaction de principe ni une réaction allergique.

A la limite, dans le cas qui m'intéresse (cluster RedHat), si je disposais d'un utilitaire en ligne de commande permettant de générer correctement le fichier de conf, ça ne me gênerait pas plus que ça. Je suis sur d'ailleurs d'utiliser à mon insu des outils qui stockent leur config dans des fichiers XML, et ça ne me gène pas. Au pire si ça m'amuse je vais toucher le fichier XML. La ce que je déplore pour Redhat Cluster (et il ne doit pas être le seul), c'est d'utiliser un fichier XML et de ne pas avoir d'autre alternative que l'édition direct XML, soit une interface graphique.
Et pour ton info, je me suis renseigné sur le XML, je connais assez bien celui-ci. Dans pas mal de cas c'est bien pratique. Mais dans le cas de fichier de conf pour une appli ça ne sert à rien. Il y a bien plus simple et plus pratique que ça.

GRRRR! Mon commentaire n'est pas passé comme il le faut :(.

Tu mets le doigt sur un point qui justement penche en défaveur de XML.

Déjà :

arbre {
branche {
fruit {
}
fruit {
}
branche {
fruit
}
}
}

C'est déjà moins verbeux que :




<fruit .... />
<fruit ... />


<fruits ... />
<fruits ... />




Et la c'est un exemple tout simple.
C'est plus parce que l'équipe de développement veut que son fichier de conf puisse être généré par un écosystème large et intégré dans un workflow (flux de travail :)) unifié et la, le XML à sa place (et je ne veux voir personne crier foutaise !) :)
Explique-moi ce que vient faire la conf d'un système dans un workflow.

Ca reste quand même plus lisible que du XML.

Le fichier de conf en XML a beaucoup d'avantages (Encodage, xquery, accessibilité en ligne, publication) et peu d'inconvénients (taille du fichier).
Si tu dois créer des config pour un client qui a son serveur sous windows avec de l'iso-8859-5 et que tu prépares sa config sur un serveur linux avec de l'utf-8 tu apprécieras (iconv çà va 5 minutes).


http://vimdoc.sourceforge.net/htmldoc/mbyte.html

Supported 'encoding' values are: *encoding-values*
1 latin1 8-bit characters (ISO 8859-1)
1 iso-8859-n ISO_8859 variant (n = 2 to 15)
1 koi8-r Russian
1 koi8-u Ukrainian
1 macroman MacRoman (Macintosh encoding)
1 8bit-{name} any 8-bit encoding (Vim specific name)
1 cp437 similar to iso-8859-1
1 cp737 similar to iso-8859-7
1 cp775 Baltic
1 cp850 similar to iso-8859-4
1 cp852 similar to iso-8859-1
1 cp855 similar to iso-8859-2
1 cp857 similar to iso-8859-5
1 cp860 similar to iso-8859-9
1 cp861 similar to iso-8859-1
1 cp862 similar to iso-8859-1
1 cp863 similar to iso-8859-8
1 cp865 similar to iso-8859-1
1 cp866 similar to iso-8859-5
1 cp869 similar to iso-8859-7
1 cp874 Thai
1 cp1250 Czech, Polish, etc.
1 cp1251 Cyrillic
1 cp1253 Greek
1 cp1254 Turkish
1 cp1255 Hebrew
1 cp1256 Arabic
1 cp1257 Baltic
1 cp1258 Vietnamese
1 cp{number} MS-Windows: any installed single-byte codepage
2 cp932 Japanese (Windows only)
2 euc-jp Japanese (Unix only)
2 sjis Japanese (Unix only)
2 cp949 Korean (Unix and Windows)
2 euc-kr Korean (Unix only)
2 cp936 simplified Chinese (Windows only)
2 euc-cn simplified Chinese (Unix only)
2 cp950 traditional Chinese (on Unix alias for big5)
2 big5 traditional Chinese (on Windows alias for cp950)
2 euc-tw traditional Chinese (Unix only)
2 2byte-{name} Unix: any double-byte encoding (Vim specific name)
2 cp{number} MS-Windows: any installed double-byte codepage
u utf-8 32 bit UTF-8 encoded Unicode (ISO/IEC 10646-1)
u ucs-2 16 bit UCS-2 encoded Unicode (ISO/IEC 10646-1)
u ucs-2le like ucs-2, little endian
u utf-16 ucs-2 extended with double-words for more characters
u utf-16le like utf-16, little endian
u ucs-4 32 bit UCS-4 encoded Unicode (ISO/IEC 10646-1)
u ucs-4le like ucs-4, little endian

Tu peux être amené à créer des configs pour des serveurs pour lesquels tu n'as pas (de carte graphique, tout à fait d'accord, mais aussi) pas de term, juste un login/password ftp.
Das le cas d'un cluster, ou même d'un serveur (je pense à l'usine a gaz d'arrêt/relance de services sous Solaris censé remplacer init.d), si tu n'as pas un accès shell à ta machine, un accès ftp ne sert à rien.

Sérieusement je conçois que pour certaines choses, XML est bien pratique, mais dans le cas d'un service qui touche à l'administration de la machine, c'est n'importe quoi.

Le fichier de conf en XML a beaucoup d'avantages (Encodage, xquery, accessibilité en ligne, publication) et peu d'inconvénients (taille du fichier).
Non, XML est verbeux et ne sert à RIEN pour un fichier de conf. Ce n'est facile QUE pour le développeur.
Si tu dois créer des config pour un client qui a son serveur sous windows avec de l'iso-8859-5 et que tu prépares sa config sur un serveur linux avec de l'utf-8 tu apprécieras (iconv çà va 5 minutes).
Tu peux développer STP ? Parce que je ne vois pas en quoi XML apporte quelque chose.

Il me semblait bien avoir lu un truc du genre il n'y a pas longtemps mais je ne me rappelais pas ou ...

Je l'avais vu ...
http://www.redhat.com/docs/manuals/enterprise/RHEL-3-Manual/(...)

Je suis en RHEL5.

Le XML c'est pratique grâce à l'écosystème de librairie permettant de créer ou charger en mémoire des fichiers.
C'est faisable sans XML : les tableaux associatifs sont intégrés dans la plupart des langages modernes, et cen'est pas dur d'écrire les libs en question (qui doivent exister depuis longtemps). Comment faisait-on avant XML ?

La encore, c'est "pratique pour le développeur"


Pourquoi les développeurs font des GUI ?
Parce que ça permet de faire des choses basique sans avoir aucune compétence ou presque, et sans "perdre" de temps à faire un man appli.
OK mais je perds du temps a me trouver une machine sur laquele je peux faire tourner un serveur X, installer un Linux dessus, instaler un VNC, faire un export du display et ensuite me battre avec les regles de filtrage pour accéder àmon VNC distant avec un débit minable, tout ca pour configurer un pauvre cluster. De plus ce n'est pas une interface graphique qui donne des compétences. Sinon il y a longtemps que voyages.sncf.com serait ergonomique rapide joli, tout ça ... vu le nombre d'outils graphiques permettant de faire de zolies pages web. Puis c'est sur qu'on ne perd pas de temps à faire un "man appli", on essaie des tas d'options, on clique sur l'aide en ligne et quand on se trompe le système envoie un message d'erreur stupide et imbitable car ça prend du temps de tester tous les cas possibles et imaginables, et on se retrouve a passer du temps à essayuer dans tous les sens l'option qui n'a pas marché. un man appli me donnera en général plus d'infos qu'un GUI.

C'est bien ou pas ? Ce n'est pas à moi de le dire ! En tout cas, ce n'est pas mes interfaces graphiques qui t'embêterons, je n'en fait pas, ça me fait trop ch### :)

Oh comme je te remercie. :). En tout cas dire que ce n 'est pas bien, oui je le dis. Rien que le fait qu'en environnement serveur, il est fort possible de ne pas disposer d'interface graphique devrait inciter les developpeurs à proposer une alternative. Sinon pourquoi ne pas installer un Windows ?

Oui mais ..... non. L'exemple typique est celui de Redhat Cluster. Qu'est-ce que vient faire un workflow dedans ? Et un workflow n'est-il pas capable de générer de simples paires clés/valeurs ?
La encore c'est le développeur qui est favorisé et non l'utilisateur.

Oups, désolé grosse fatigue, j'ai lu la norme rapidement et je l'ai compris à l'envers.

N'empêche que ça fait un peu stupide cette histoire de gibi ...

Non, ma femme me rale dessus quand l'ordinateur ne marche pas.
Je ne veux plus l'entendre raler donc je lui ai mis ubuntu, depuis elle ne rale plus, nous nous entendons à merveille ... :)

Oui mais pour qui est écrit le soft ? Pour l'utilisateur ou pour le développeur. L'argument que tu avences ne me parait pas un argument valable : depuis le temps qu'on fait des softs avec des fichiers de conf texte, ça a déjà été fait, le code libre existe.

la mort de :
- sim
- michael Jackson
- René des Musclés
- Patrick Swayze
- David Carradine
- Filip Nikolic

Et d'autres que j'ai oublié ...