Oui! Cela gère du LDAP, du SQL (pas par fichier mais en se connectant sur la base), fichier…
Effectivement, la doc a de gros manquements. Il manque une vrai doc et plus d'exemples sur le site, parce que c'est un outil qui fonctionne super bien (j'en suis très content, synchronisation Active Directory -> LDAP chez nous).
Je ne connais pas assez Gitlab pour te faire un diff fonctionnel complet, mais cela semble très très proche.
Quelques différences que je remarque tout de suite:
- Le système / administration / contribution: Gitlab est en Ruby, Gitblit en Java (et hooks en Groovy). La suite dépend des adminsys qui maintiendront derrière, ou de ceux qui écriront les hooks
- Gitlab est fait avec une société, donc certaines fonctionnalités comme les Groups LDAP ou les Hooks sont réservé à une version payante. Gitblit est purement communautaire, totalement gratuite, sur Github et contribution acceptés. Par contre pas de support société (forcement)
Rien que ces 2 points, sans prendre parti, peuvent faire pencher d'un coté ou de l'autre lors d'un choix.
Beau moinssage (assez mérité il est vrai malgré le trolldi ;)
Ce que je reprocherai à Pulse audio, ce n'est pas d'avoir eu des merdes au début (même si c'était lourd…), ni même de lever les bugs de drivers. Je fais partie de ceux qui sont conscient de l'apport fonctionnel (bluetooth, volume par application, …).
Mais j'ai l'impression d'une occasion manqué pour l'instant avec Pulse sur le spaguetti mille feuille de la pile audio Linuxienne (Alsa and co, OSS, Jack, ….). La où systemd remplace avantageusement tout ce qui précède. Wayland aussi… journald aussi… avec une conception robuste, moderne et performante… le compte n'y est pas à mon avis avec Pulse (pas de nettoyage de ce bordel, pas de latence réduite, conso CPU et Ram élevé…). Sur toute la couche basse, cela manque d'intégration avec le noyau (il y a probablement des gains a trouver en virant/simplifiant la couche alsa entre le noyau et Pulse).
J'avoue avoir eu quelques frayeurs en voyant systemd venir du même Lennart, mais j'ai changé d'avis en voyant la qualité technique de systemd. Il semble avoir appris de ses erreurs, gère mieux la collaboration avec les dev du kernel, ainsi que sa communication publique sans pour autant troquer son caractère affirmé (il en faut pour changer les choses).
Si on imagine une distrib de dans 2 ans, on peut imaginer:
- Un noyau linux toujours au top (incroyable une communauté et un leader aussi efficace)
- Un linux "userland" toujours plus modernisé avec systemd, journald… Un boot ultra rapide, des outils efficace pour chaque tache, des confs simple…
- Une gestion graphique enfin modernisé avec Wayland (sécurité, maintenance simplifié, légèreté…)
- Nos bureaux KDE/Gnome toujour plus moderne mais peut-être aussi des nouveautés favorisé par wayland car on voit que cela bouge un peu plus (Hawaii, LXDE, E…)
- Et toujours un beau bordel au niveau de la pile audio…. Et j'aimerai que Lennart, fort de son expérience, nous refasse maintenant une 2eme passe pour changer tout cela…
Déja je corrige mon message, je voulais dire "Redhat/Centos et Debian".
Ensuite, je crois que tu te plantes sur "logstash très intéressant si tu utilises syslog old school et si tu as 30 serveurs pour stocker tes log". Mais je peux comprendre que l’énervement des fudeurs et autre conservateurs n'aide pas…
Sur le coté syslog old school: logstash permet d'agreger et d'hamoniser les logs venant de plusieurs sources (dont syslog certes) mais permet donc de s'affranchir de ses limites. Avec des appli java, utiliser syslog signifie tronquer les messages par exemple. Avec un parc hétérogène (windows, linux variés, éléments réseaux….), c'est une bonne solution pour avoir quelque chose d'exploitable.
Et sur le coté "30 serveurs pour stocker tes log", il faut juste ne pas être trop archiviste ou collectionneur, mais suivre le cycle de vie:
- Enregistrer
- Transmettre
- Analyser
- Stocker
- Détruire (a ne pas oublier)
Elastic search est clusterisable certes (contrairement à find/grep d'ailleur), mais on s'en sort généralement très bien avec une seule machine si on n'a pas une ame de syllogomane ;)
Si tu souhaites avoir une bonne gestion des logs et permettre des analyses éventuellement poussées, il ne faut de toute manière pas les garder sur la machine (qui peut de toute manière partir en vrille, tant pour journalctl que grep ou cat).
Part sur une centralisation des logs avec des outils comme logstash + elastic search + kibana3, graylog2, les 2 ensembles…, ou un très onéreux splunk si le ROI le permet.
Cela offre plein d'avantages:
- logs harmonisés (formats de date, encodage…) et qualifiés (date, processus, multiligne [trace java]…)
- Recherche rapide dans les logs grâce à un moteur de cherche, possibilité de créer des graphiques
- De comprendre des anomalies liés à une combinaison de facteurs, éventuellement répartie sur plusieurs machines
- D'analyser même si la machine fait du kernel panic
- D'analyser en temps réel, déclencher des alertes
- Donner la capacité d'analyser des problemes aux développeurs, sans ouvrir d'accès aux machines de prod (et brouillage des infos sensibles)
- Utiliser ou déclencher des événements entre machine via de la messagerie comme AMQP, ce qui permet par d'exemple d'ajouter ou retirer des noeuds à un cluster en fonction de temps de réponses)
Lorsqu'on qu'on voit en plus comment cela peut être simple et puissant de mettre en place un logstash, je ne comprends même pas que l'on puisse encore vouloir s'emmerder avec rotations, cat et grep, qui sont des silex à coté. Je ne dis pas que cela ne peut pas aider de temps à autre pour des trucs rapide et sans importance, mais pour le reste, il y a bien mieux aujourd'hui.
Si le sujet t'intéresse, prends 30min et regarde cela http://www.youtube.com/watch?v=RuUFnog29M4#t=353 et cette dépêche: https://linuxfr.org/news/gestion-des-logs-avec-logstash-elasticsearch-kibana
Je pense que dans quelques temps, lorsque les versions stable Redhat/Centos utiliseront en standard journald (qui génére des logs de qualité) envoyé dans un outil comme logstash+elastic search+kibana3 + graylog2, on aura une arme libre assez incroyable au niveau des logs. Allo quoi…
Oui, et encore je trouve que systemd respecte bien la philosophie justement, avec un découpage en de multiples utilitaire indépendants et modulaires, des fichiers d'init qui font le strict nécessaire (configurer).
C'est pas un gros bloc systemd .. et AMHA, c'est plus a comparer avec les outils gnu (qui eux aussi ne respectent donc pas la philosophie unix ??)
Merci, c'est bien le site (et la dépèche) que je cherchais. le site n'est pas parfais dans les subtilités juridique, mais dégrossis bien pour des gens pas familiarisé qui pourraient mélanger tout et n'importe quoi sans savoir.
Merci beaucoup aussi pour les bon liens.
Tu as droits aussi à un bisous de mon voisin de bureau.
Perso, j'avais assisté à une discussion à l'akademy ou ça parlait des batons dans les roues. Etait par exemple cité l'exemple d'un gas connu/responsable chez KDE et Qt (j'ai zappé le nom) qui n'arrivait pas a obtenir les droits de commiter au bout d'un an de tentative de portage Qt, ce qui nous scandalisait, nous autres.
Anecdote datant de quelques années, ma dernière Akademy date de 2008 (donc cela vaut ce que cela vaut…).
Peut-etre, mais la situation Nagios aurait mérité un gros fork façon xfree86/xorg ou Hudson/Jenkins.
Là, c'est pleins de fork partout et un gros bordel au final. En ce moment, je réfléchi à une réforme supervision et monitoring (*) dans une société, j'ai le choix entre Nagios dont le nom est connu mais qui a perdu récemment son dernier développeur réel (qui a forké a son tour), et une multitude de forks dont la visibilité est assez réduite.
Comment faire un choix résonné (et justifiable auprès d'une hiérarchie) dans un foutoir pareil???
Pour la centralisation et analyse des logs par contre, logstash+elasticsearch+kibana3 d'un coté, graylog2+elasticsearch d'un autre, c'est pas mal du tout (et moderne par construction).
Sans aller jusqu'a "instruire", je me rends compte que les entreprises, dans la "grande compétition internationale", cherchent de plus en plus le zéro faute, le zéro plantage, les mise à jour sans interruption de service, …
Et pour y arriver, on trace de plus en plus de chose, éléments susceptible de défaillir ou intéressant à analyser, scruté en temps réel pour agir dans l'instant. Mais globalement la quantité de data récolté/analysé explose [constatation perso]. Dans un petit SI, on compte rapidement en dizaine de Go/jours.
Toujours mon expérience, le format binaire ne me dérange pas, c'est un format interne, tout comme le format interne de mysql. Personne n'utilise mysql par son format de fichier binaire, mais plutôt par son API (SQL) et ses outils. C'est juste pareil avec systemd.
De toute façon, si on veut faire un travail sérieux dans un S.I. avec les logs (au delà des script à 2 balles qui font des grep dans des cron), on va se retrouver à centraliser ailleurs les logs dans d'autres bases servant à l'analyse, elle-même binaire, comme elasticsearch ou mongodb.
CAS, je connais (le logiciel qui implémente le protocole disons). LemonLdap a donc l'air plus complet, et offre plus de possibilité si par exemple l'application n'est pas "casifiable" (appli proprio par exemple).
a) Pour le Webservice, tu parles donc du mode "Soap Admin Session"?… J'avoue que j'étais totalement passé a coté en regardant le site. C'est donc au site qui implémente le client Soap d'écrire le cookie. Et cela marchera tant que les différents sites à "SSOiser" sont dans le même domaine.
Petites questions si des gens ont joué avec les outils SSO traînent par là:
1) Comment se situe LemonLDAP par rapport à CAS (que je connais) qui semble proche sur la logique (différence, atouts/faiblesses).
2) CAS (et semble t'il LemondDAP) fonctionne sur la logique j'essaye de m'authentifier sur un site, celui me redirige sur un autre site qui possède un champ login/pwd, puis, je suis redirigé vers le site initial. Désormais, je suis connu dans les sites géré par le SSO.
Quel outils pour faire du SSO pour 2 use-case différents:
a) Les champs login/pwd sont directement sur le site initial, ils sont envoyé en ajax sur le système SSO. Sans rediriger l'utilisateur sur un autre site.
b) Faire du SSO en supportant l'auth basic d'apache. Pour authentifier des utilisateurs à des services avec par exemple des URL https://login:password@monservice.com . Ce genre de chose serait possible avec le mod Apache "qui va bien". Vous connaissez quelque chose?
Même avec un VCS, à un moment ou à un autre il va bien falloir aller écrire dans /var/www (ou autre répertoire) et là sans les ACL tu as deux solutions : soit tu donnes le groupe www a tous les utilisateurs susceptible de devoir modifier le site (ou faire un commit si tu préfères), soit tu ajoutes l'utilisateur apache dans 200 groupes.
Le stagiaire peut (et doit) commiter dans le VCS…et n'a même pas d'accès au serveur (ou en tout cas il ne s'en sert pas). C'est un process d'intégration continue comme Jenkins qui va pousser (via un deb ou rpm) sur le serveur après une série de tests.
Et le retour à la version précédente en cas de soucis est aisé.
Et le stagiaire, il est content car personne ne va lui râler dessus parce qu'il aurait cassé le serveur (et personne ne râle sur son chef non plus du coup).
Je n'ai pas pu faire non plus ce que j'aurai aimé (en recherche d'appart et déménagement…). J'ai eu l'impression que c'était un peu la news maudite alors que cette release de KDE est très intéressante vis à vis de la qualité (le gestionnaire de tache ou l'affichage des icônes dans Dolphin par exemple).
Plutôt que de traiter la communauté Gnome/KDE/… et moi même de paranoïaque, tu n'aura qu'a ressortir mon message dans 5 ans (et on verra au passage, si dans 5 ans, les applications Mir pourront s'exécuter dans Wayland via XWayland de manière fiable). On verra bien si l'incompatibilité n'est pas voulu.
La version du 13 Juillet faisait ça systématiquement. La suivante corrige cela mais cela dépend du matériel/driver.
Tu es sensé avoir un bouton menu et des raccourcis d'applis en haut (une fois la session ouverte).
Perso, c'est nickel avec une Intel HD3000 (Core i5) mais toi tu dois avoir un problème avec tes drivers, ou lié à l'intégration de la distrib qui est très artisanale (j'ai prévenu dans la news ;).
Je complète un peu un peu: La communauté des développeurs au sens large (X, Gnome, KDE, E, les differents "buntu"…) a compris que l'objectif de Mir est de rendre Ubuntu incompatible avec les autres distributions et/ou de les rendre marginale.
par exemple:
- Un stream compilé pour Mir sera incompatible avec les autres distributions. En faisant un travail de partenariat et d'exclusivité, ils marginalisent les autres.
- Le duo attribution/GPL3 fait qu'un éditeur voulant éditer du propriétaire pour Ubuntu devra obtenir une licence spéciale de Mir: Il auront la main pour faire payer ou négocier une exclusivité.
Après, pour pas trop passer pour des salauds, on fait de l'enrobage marketo-communautaire. Ex:
- Justifications techniques foireuses démonté directement (pouquoi n'ont t'il pas vérifié aupres des développeurs wayland? pas un mail en 6 mois de développement sous le manteau?)
- Des discutions avec la team Kubuntu qui cherche une solution et les développeurs Mir qui ne proposent aucune solutions réaliste ou acceptable.
(presque) personne n'est dupe. Bientôt même ce sera Ubuntu les victimes pour les fanboys, on croit rêver…. C'est comme Apple, plus c'est gros, plus ça passe.
Après, on peut dire que la communauté du dev libre voit le mal partout… mais il serait assez facile pour Ubuntu de démontrer qu'il n'ont pas cette volonté de contrôle… pas par des paroles creuse comme cette pseudo "aide" envers Kubuntu qui était d'un cynisme absolu, mais par des ACTES:
Fin de l'attribution des commits extérieur à Ubuntu
Pas de GPLV3 uniquement, afin d'être compatible avec les autres environnement
Travail/contribution upstream des patchs pour Qt, Gtk, … avec détection au runtime, afin qu'un soft Qt/Gtk/EFL déjà compilé puisse tourner sous Wayland ou Mir.
Dans la même veine, développement d'un WaylandMir et d'un MirWayland
Mise en place d'un protocole pour pas qu'un compositeur différent d'Unity soit cassé tout les quatre matins à chaque mise à jour système.
Mais les actes, on est pas prêt de les voir… les faux semblant par contre, c'est pas fini… Et quand viendront les problèmes, je suis certain qu'il rejetteront la faute sur les autres pour se dédouaner.
Après, on peut penser que c'est une bonne chose qu'il ne reste qu'un seul bureau libre (Unity) et qu'une seule distrib (Ubuntu) sur le marché du desktop. Le tout avec un store payant comme Android.
Mais prendre autant les gens pour des cons [dont les dev qui fabriquent l'essentiel de la logithèque du "store"], c'est vraiment énervant.
[^] # Re: Et les bases de données ?
Posté par Johann Ollivier-Lapeyre (site web personnel) . En réponse à la dépêche Sortie de LDAP Synchronization Connector 2.1.0. Évalué à 2.
Oui! Cela gère du LDAP, du SQL (pas par fichier mais en se connectant sur la base), fichier…
Effectivement, la doc a de gros manquements. Il manque une vrai doc et plus d'exemples sur le site, parce que c'est un outil qui fonctionne super bien (j'en suis très content, synchronisation Active Directory -> LDAP chez nous).
[^] # Re: par rapport à Gitlab …
Posté par Johann Ollivier-Lapeyre (site web personnel) . En réponse à la dépêche Sortie de Gitblit 1.4.x. Évalué à 4.
Je ne connais pas assez Gitlab pour te faire un diff fonctionnel complet, mais cela semble très très proche.
Quelques différences que je remarque tout de suite:
- Le système / administration / contribution: Gitlab est en Ruby, Gitblit en Java (et hooks en Groovy). La suite dépend des adminsys qui maintiendront derrière, ou de ceux qui écriront les hooks
- Gitlab est fait avec une société, donc certaines fonctionnalités comme les Groups LDAP ou les Hooks sont réservé à une version payante. Gitblit est purement communautaire, totalement gratuite, sur Github et contribution acceptés. Par contre pas de support société (forcement)
Rien que ces 2 points, sans prendre parti, peuvent faire pencher d'un coté ou de l'autre lors d'un choix.
# Désolé...
Posté par Johann Ollivier-Lapeyre (site web personnel) . En réponse au journal Huawei s'apprête à installer du SAP et du Linux partout !. Évalué à 10.
En espérant que ce ne soit pas la rigueur chinoise et douceur germanique ;)
[^] # Re: Troll
Posté par Johann Ollivier-Lapeyre (site web personnel) . En réponse au journal systemd ca a l'air super.... Évalué à 10.
Merci a toi, maintenant, systemd accélère aussi les trolls ;)
[^] # Re: fin de l'histoire ?
Posté par Johann Ollivier-Lapeyre (site web personnel) . En réponse au journal Ubuntu passera lui aussi sur systemd. Évalué à 10.
Beau moinssage (assez mérité il est vrai malgré le trolldi ;)
Ce que je reprocherai à Pulse audio, ce n'est pas d'avoir eu des merdes au début (même si c'était lourd…), ni même de lever les bugs de drivers. Je fais partie de ceux qui sont conscient de l'apport fonctionnel (bluetooth, volume par application, …).
Mais j'ai l'impression d'une occasion manqué pour l'instant avec Pulse sur le spaguetti mille feuille de la pile audio Linuxienne (Alsa and co, OSS, Jack, ….). La où systemd remplace avantageusement tout ce qui précède. Wayland aussi… journald aussi… avec une conception robuste, moderne et performante… le compte n'y est pas à mon avis avec Pulse (pas de nettoyage de ce bordel, pas de latence réduite, conso CPU et Ram élevé…). Sur toute la couche basse, cela manque d'intégration avec le noyau (il y a probablement des gains a trouver en virant/simplifiant la couche alsa entre le noyau et Pulse).
J'avoue avoir eu quelques frayeurs en voyant systemd venir du même Lennart, mais j'ai changé d'avis en voyant la qualité technique de systemd. Il semble avoir appris de ses erreurs, gère mieux la collaboration avec les dev du kernel, ainsi que sa communication publique sans pour autant troquer son caractère affirmé (il en faut pour changer les choses).
Si on imagine une distrib de dans 2 ans, on peut imaginer:
- Un noyau linux toujours au top (incroyable une communauté et un leader aussi efficace)
- Un linux "userland" toujours plus modernisé avec systemd, journald… Un boot ultra rapide, des outils efficace pour chaque tache, des confs simple…
- Une gestion graphique enfin modernisé avec Wayland (sécurité, maintenance simplifié, légèreté…)
- Nos bureaux KDE/Gnome toujour plus moderne mais peut-être aussi des nouveautés favorisé par wayland car on voit que cela bouge un peu plus (Hawaii, LXDE, E…)
- Et toujours un beau bordel au niveau de la pile audio…. Et j'aimerai que Lennart, fort de son expérience, nous refasse maintenant une 2eme passe pour changer tout cela…
[^] # Re: fin de l'histoire ?
Posté par Johann Ollivier-Lapeyre (site web personnel) . En réponse au journal Ubuntu passera lui aussi sur systemd. Évalué à -8.
Sauf que systemd est bien conçu, LUI
[^] # Re: Mon avis personnel
Posté par Johann Ollivier-Lapeyre (site web personnel) . En réponse au journal Debian adopte systemd comme init par défaut. Évalué à 3.
Et en json, et en text, et …
[^] # Re: Mon avis personnel
Posté par Johann Ollivier-Lapeyre (site web personnel) . En réponse au journal Debian adopte systemd comme init par défaut. Évalué à 2.
Déja je corrige mon message, je voulais dire "Redhat/Centos et Debian".
Ensuite, je crois que tu te plantes sur "logstash très intéressant si tu utilises syslog old school et si tu as 30 serveurs pour stocker tes log". Mais je peux comprendre que l’énervement des fudeurs et autre conservateurs n'aide pas…
Sur le coté syslog old school: logstash permet d'agreger et d'hamoniser les logs venant de plusieurs sources (dont syslog certes) mais permet donc de s'affranchir de ses limites. Avec des appli java, utiliser syslog signifie tronquer les messages par exemple. Avec un parc hétérogène (windows, linux variés, éléments réseaux….), c'est une bonne solution pour avoir quelque chose d'exploitable.
Et sur le coté "30 serveurs pour stocker tes log", il faut juste ne pas être trop archiviste ou collectionneur, mais suivre le cycle de vie:
- Enregistrer
- Transmettre
- Analyser
- Stocker
- Détruire (a ne pas oublier)
Elastic search est clusterisable certes (contrairement à find/grep d'ailleur), mais on s'en sort généralement très bien avec une seule machine si on n'a pas une ame de syllogomane ;)
[^] # Re: Mon avis personnel
Posté par Johann Ollivier-Lapeyre (site web personnel) . En réponse au journal Debian adopte systemd comme init par défaut. Évalué à 10.
Si tu souhaites avoir une bonne gestion des logs et permettre des analyses éventuellement poussées, il ne faut de toute manière pas les garder sur la machine (qui peut de toute manière partir en vrille, tant pour journalctl que grep ou cat).
Part sur une centralisation des logs avec des outils comme logstash + elastic search + kibana3, graylog2, les 2 ensembles…, ou un très onéreux splunk si le ROI le permet.
Cela offre plein d'avantages:
- logs harmonisés (formats de date, encodage…) et qualifiés (date, processus, multiligne [trace java]…)
- Recherche rapide dans les logs grâce à un moteur de cherche, possibilité de créer des graphiques
- De comprendre des anomalies liés à une combinaison de facteurs, éventuellement répartie sur plusieurs machines
- D'analyser même si la machine fait du kernel panic
- D'analyser en temps réel, déclencher des alertes
- Donner la capacité d'analyser des problemes aux développeurs, sans ouvrir d'accès aux machines de prod (et brouillage des infos sensibles)
- Utiliser ou déclencher des événements entre machine via de la messagerie comme AMQP, ce qui permet par d'exemple d'ajouter ou retirer des noeuds à un cluster en fonction de temps de réponses)
Lorsqu'on qu'on voit en plus comment cela peut être simple et puissant de mettre en place un logstash, je ne comprends même pas que l'on puisse encore vouloir s'emmerder avec rotations, cat et grep, qui sont des silex à coté. Je ne dis pas que cela ne peut pas aider de temps à autre pour des trucs rapide et sans importance, mais pour le reste, il y a bien mieux aujourd'hui.
Si le sujet t'intéresse, prends 30min et regarde cela http://www.youtube.com/watch?v=RuUFnog29M4#t=353 et cette dépêche: https://linuxfr.org/news/gestion-des-logs-avec-logstash-elasticsearch-kibana
Je pense que dans quelques temps, lorsque les versions stable Redhat/Centos utiliseront en standard journald (qui génére des logs de qualité) envoyé dans un outil comme logstash+elastic search+kibana3 + graylog2, on aura une arme libre assez incroyable au niveau des logs. Allo quoi…
[^] # Re: je suis le seul ou quoi ?
Posté par Johann Ollivier-Lapeyre (site web personnel) . En réponse au journal Debian rejoint les utilisateurs de Systemd. Évalué à 9.
Oui, et encore je trouve que systemd respecte bien la philosophie justement, avec un découpage en de multiples utilitaire indépendants et modulaires, des fichiers d'init qui font le strict nécessaire (configurer).
C'est pas un gros bloc systemd .. et AMHA, c'est plus a comparer avec les outils gnu (qui eux aussi ne respectent donc pas la philosophie unix ??)
[^] # Re: En fait la discussion continue
Posté par Johann Ollivier-Lapeyre (site web personnel) . En réponse au journal Debian rejoint les utilisateurs de Systemd. Évalué à 6.
Et avec ce vote UDOFV maintenant de Colin Watson, ce n'est pas maintenant plié en faveur de systemd?
https://lists.debian.org/debian-ctte/2014/02/msg00332.html
# Merci !!
Posté par Johann Ollivier-Lapeyre (site web personnel) . En réponse au message site de compatibilité de licenses. Évalué à 1.
Merci, c'est bien le site (et la dépèche) que je cherchais. le site n'est pas parfais dans les subtilités juridique, mais dégrossis bien pour des gens pas familiarisé qui pourraient mélanger tout et n'importe quoi sans savoir.
Merci beaucoup aussi pour les bon liens.
Tu as droits aussi à un bisous de mon voisin de bureau.
[^] # Re: Plus sérieusement
Posté par Johann Ollivier-Lapeyre (site web personnel) . En réponse au journal Firefox en GTK3. Évalué à 4.
Perso, j'avais assisté à une discussion à l'akademy ou ça parlait des batons dans les roues. Etait par exemple cité l'exemple d'un gas connu/responsable chez KDE et Qt (j'ai zappé le nom) qui n'arrivait pas a obtenir les droits de commiter au bout d'un an de tentative de portage Qt, ce qui nous scandalisait, nous autres.
Anecdote datant de quelques années, ma dernière Akademy date de 2008 (donc cela vaut ce que cela vaut…).
[^] # Re: Propriété
Posté par Johann Ollivier-Lapeyre (site web personnel) . En réponse au journal Changement d'URL pour les "plugins" Nagios. Évalué à 1.
Peut-etre, mais la situation Nagios aurait mérité un gros fork façon xfree86/xorg ou Hudson/Jenkins.
Là, c'est pleins de fork partout et un gros bordel au final. En ce moment, je réfléchi à une réforme supervision et monitoring (*) dans une société, j'ai le choix entre Nagios dont le nom est connu mais qui a perdu récemment son dernier développeur réel (qui a forké a son tour), et une multitude de forks dont la visibilité est assez réduite.
Comment faire un choix résonné (et justifiable auprès d'une hiérarchie) dans un foutoir pareil???
# NSA Cloud backup
Posté par Johann Ollivier-Lapeyre (site web personnel) . En réponse au journal "The NSA is Coming to Town" une vidéo didactique sur la NSA, avec des pères noël.. Évalué à 9.
Puisque on a un journal bookmark, allons y gaiement:
La NSA pour les décideurs pressés:
http://www.youtube.com/watch?v=1tSTtmX3v3w
[^] # Re: GNU/SystemD/Linux
Posté par Johann Ollivier-Lapeyre (site web personnel) . En réponse au journal Systemd va gagner une console système, un bootsplash et un login-screen. Évalué à 3.
Sans aller jusqu'a "instruire", je me rends compte que les entreprises, dans la "grande compétition internationale", cherchent de plus en plus le zéro faute, le zéro plantage, les mise à jour sans interruption de service, …
Et pour y arriver, on trace de plus en plus de chose, éléments susceptible de défaillir ou intéressant à analyser, scruté en temps réel pour agir dans l'instant. Mais globalement la quantité de data récolté/analysé explose [constatation perso]. Dans un petit SI, on compte rapidement en dizaine de Go/jours.
Toujours mon expérience, le format binaire ne me dérange pas, c'est un format interne, tout comme le format interne de mysql. Personne n'utilise mysql par son format de fichier binaire, mais plutôt par son API (SQL) et ses outils. C'est juste pareil avec systemd.
De toute façon, si on veut faire un travail sérieux dans un S.I. avec les logs (au delà des script à 2 balles qui font des grep dans des cron), on va se retrouver à centraliser ailleurs les logs dans d'autres bases servant à l'analyse, elle-même binaire, comme elasticsearch ou mongodb.
[^] # Re: [:alerte...
Posté par Johann Ollivier-Lapeyre (site web personnel) . En réponse au journal Les JT c'était déjà pas glorieux, mais là on atteint des sommets.... Évalué à 10.
C'est triste ton avis sur les sommets…
[^] # Re: En comparaison de CAS, et sur quels Use Case?
Posté par Johann Ollivier-Lapeyre (site web personnel) . En réponse à la dépêche Sortie de LemonLDAP::NG 1.3. Évalué à 1.
Merci pour ta réponse.
CAS, je connais (le logiciel qui implémente le protocole disons). LemonLdap a donc l'air plus complet, et offre plus de possibilité si par exemple l'application n'est pas "casifiable" (appli proprio par exemple).
a) Pour le Webservice, tu parles donc du mode "Soap Admin Session"?… J'avoue que j'étais totalement passé a coté en regardant le site. C'est donc au site qui implémente le client Soap d'écrire le cookie. Et cela marchera tant que les différents sites à "SSOiser" sont dans le même domaine.
b) Ca c'est bon.
# En comparaison de CAS, et sur quels Use Case?
Posté par Johann Ollivier-Lapeyre (site web personnel) . En réponse à la dépêche Sortie de LemonLDAP::NG 1.3. Évalué à 3.
Petites questions si des gens ont joué avec les outils SSO traînent par là:
1) Comment se situe LemonLDAP par rapport à CAS (que je connais) qui semble proche sur la logique (différence, atouts/faiblesses).
2) CAS (et semble t'il LemondDAP) fonctionne sur la logique j'essaye de m'authentifier sur un site, celui me redirige sur un autre site qui possède un champ login/pwd, puis, je suis redirigé vers le site initial. Désormais, je suis connu dans les sites géré par le SSO.
Quel outils pour faire du SSO pour 2 use-case différents:
a) Les champs login/pwd sont directement sur le site initial, ils sont envoyé en ajax sur le système SSO. Sans rediriger l'utilisateur sur un autre site.
b) Faire du SSO en supportant l'auth basic d'apache. Pour authentifier des utilisateurs à des services avec par exemple des URL https://login:password@monservice.com . Ce genre de chose serait possible avec le mod Apache "qui va bien". Vous connaissez quelque chose?
[^] # Re: Fais-le...
Posté par Johann Ollivier-Lapeyre (site web personnel) . En réponse au journal C(++) ?. Évalué à 1.
Ben dans ce cas, fait le en groovy ;)
[^] # Re: Tout va bien, je t'assure
Posté par Johann Ollivier-Lapeyre (site web personnel) . En réponse au journal Les BSD isolés. Évalué à 4.
Le stagiaire peut (et doit) commiter dans le VCS…et n'a même pas d'accès au serveur (ou en tout cas il ne s'en sert pas). C'est un process d'intégration continue comme Jenkins qui va pousser (via un deb ou rpm) sur le serveur après une série de tests.
Et le retour à la version précédente en cas de soucis est aisé.
Et le stagiaire, il est content car personne ne va lui râler dessus parce qu'il aurait cassé le serveur (et personne ne râle sur son chef non plus du coup).
[^] # Re: Ma maigre contribution
Posté par Johann Ollivier-Lapeyre (site web personnel) . En réponse à la dépêche KDE SC 4.11. Évalué à 5.
Je n'ai pas pu faire non plus ce que j'aurai aimé (en recherche d'appart et déménagement…). J'ai eu l'impression que c'était un peu la news maudite alors que cette release de KDE est très intéressante vis à vis de la qualité (le gestionnaire de tache ou l'affichage des icônes dans Dolphin par exemple).
[^] # Re: Waylands et Mir ?
Posté par Johann Ollivier-Lapeyre (site web personnel) . En réponse à la dépêche X.Org est mort, vive Wayland ! (3). Évalué à 6.
Plutôt que de traiter la communauté Gnome/KDE/… et moi même de paranoïaque, tu n'aura qu'a ressortir mon message dans 5 ans (et on verra au passage, si dans 5 ans, les applications Mir pourront s'exécuter dans Wayland via XWayland de manière fiable). On verra bien si l'incompatibilité n'est pas voulu.
[^] # Re: Rebecca Black OS
Posté par Johann Ollivier-Lapeyre (site web personnel) . En réponse à la dépêche X.Org est mort, vive Wayland ! (3). Évalué à 3.
La version du 13 Juillet faisait ça systématiquement. La suivante corrige cela mais cela dépend du matériel/driver.
Tu es sensé avoir un bouton menu et des raccourcis d'applis en haut (une fois la session ouverte).
Perso, c'est nickel avec une Intel HD3000 (Core i5) mais toi tu dois avoir un problème avec tes drivers, ou lié à l'intégration de la distrib qui est très artisanale (j'ai prévenu dans la news ;).
[^] # Re: Waylands et Mir ?
Posté par Johann Ollivier-Lapeyre (site web personnel) . En réponse à la dépêche X.Org est mort, vive Wayland ! (3). Évalué à 10.
Je complète un peu un peu: La communauté des développeurs au sens large (X, Gnome, KDE, E, les differents "buntu"…) a compris que l'objectif de Mir est de rendre Ubuntu incompatible avec les autres distributions et/ou de les rendre marginale.
par exemple:
- Un stream compilé pour Mir sera incompatible avec les autres distributions. En faisant un travail de partenariat et d'exclusivité, ils marginalisent les autres.
- Le duo attribution/GPL3 fait qu'un éditeur voulant éditer du propriétaire pour Ubuntu devra obtenir une licence spéciale de Mir: Il auront la main pour faire payer ou négocier une exclusivité.
Après, pour pas trop passer pour des salauds, on fait de l'enrobage marketo-communautaire. Ex:
- Justifications techniques foireuses démonté directement (pouquoi n'ont t'il pas vérifié aupres des développeurs wayland? pas un mail en 6 mois de développement sous le manteau?)
- Des discutions avec la team Kubuntu qui cherche une solution et les développeurs Mir qui ne proposent aucune solutions réaliste ou acceptable.
(presque) personne n'est dupe. Bientôt même ce sera Ubuntu les victimes pour les fanboys, on croit rêver…. C'est comme Apple, plus c'est gros, plus ça passe.
Après, on peut dire que la communauté du dev libre voit le mal partout… mais il serait assez facile pour Ubuntu de démontrer qu'il n'ont pas cette volonté de contrôle… pas par des paroles creuse comme cette pseudo "aide" envers Kubuntu qui était d'un cynisme absolu, mais par des ACTES:
Mais les actes, on est pas prêt de les voir… les faux semblant par contre, c'est pas fini… Et quand viendront les problèmes, je suis certain qu'il rejetteront la faute sur les autres pour se dédouaner.
Après, on peut penser que c'est une bonne chose qu'il ne reste qu'un seul bureau libre (Unity) et qu'une seule distrib (Ubuntu) sur le marché du desktop. Le tout avec un store payant comme Android.
Mais prendre autant les gens pour des cons [dont les dev qui fabriquent l'essentiel de la logithèque du "store"], c'est vraiment énervant.