J'administre une galerie privée depuis quelques années. J'avais choisi Gallery 3 de Menalto. Pour moi, ce qui fait la différence entre Gallery 3 et les autres galeries, c'est le soin qui a été apporté à l'ergonomie.
Ma galerie me sert principalement à partager des photos d'événements (vacances, week-end, repas, sorties, …) avec des connaissances (amis, famille). Chaque utilisateur (ou groupe d'utilisateurs) a un login/mot de passe. J'ai donc un panel d'utilisateurs assez varié : de ceux qui maitrisent bien la "chose" informatique à ceux qui galèrent pour joindre un fichier à un email. La galerie doit donc être (littéralement) KISS, pour qu'ils puissent tous naviguer, télécharger et envoyer des photos/vidéos.
Après l'annonce de la fin du projet G3 (ça semble acquis, il y a eu un petit espoir de reprise du projet, mais ça bouge plus), j'ai testé différents logiciels de galeries, dont Piwigo. Il m'a semblé qu'aucun d'entre eux n'a apporté le même soin de faire une interface simple d'utilisation. Je suis donc toujours "coincé" sur Gallery 3, jusqu'au jour ou je n'aurais plus le choix (faille de sécurité non patché)
Un exemple en ce qui concerne Piwigo : pour envoyer une photo il faut aller dans "administration > ajouter une photo", puis choisir l'album. C'est 3 étapes de trop. Lorsque je suis dans l'album, ça me parait naturel d'avoir un bouton "envoyer des photos" sans que le contexte change. Envoyer une photo ou créer un album, c'est pas acte d'administration, c'est de l'utilisation.
Il ne faut voir aucune attaque dans mon message, juste une critique qui j'espère sera constructive. Je souhaites une longue vie à Piwigo, même s'il ne me convient pas, c'est une belle réussite.
Effectivement, tout se passe côté navigateur. Les seules données qui transitent sont :
1. les fichiers de l'application elle même (html/js/css) => aucun risque ici
2. le fichier KDBX s'il est stocké sur le serveur. Ce fichier est chiffré, le risque est donc très limité.
L'utilisation de SSL n'est donc pas absolument nécessaire.
Mais si tu crains un MITM qui remplacerait les fichiers de l'application pour voler ta passphrase, le SSL est une réponse.
Il y a deux méthodes :
1/ ouvrir un fichier distant, en fournissant l'URL dans l'écran de déverrouillage ;
2/ ouvrir un fichier local, en le glissant sur l'écran de déverrouillage.
Dans le premier cas, c'est du total distant (c'est cloud ;-) )
Le second cas est utile si tu n'as pas de serveur webdav et que tu n'est pas chez toi. Tu n'as pas forcément envie d'installer toute la couche mono chez tes amis/ta famille juste pour lancer KeePass pour récupérer un mot de passe. Alors tu sors ta clé USB, et voilà :-D
Le format KDBX, c'est un fichier qui contient tout. Donc ce n'est pas trop adapté au travail en équipe, il y aurait des problèmes de concurrence.
Il suffit que ton collègue enregistre une nouvelle version du fichier et qu'ensuite tu enregistre également sans avoir rechargé entre temps -> tu écrase ces modifications.
Il te faut une solution client/serveur où c'est le serveur qui gère les données pour pouvoir gérer la concurrence. CloudKeePass est une application qui stockera en WebDAV un fichier, mais le serveur n'a aucune idée de la nature des données.
Le format de fichier entre KeePass v1 et KeePass v2 a changé. KeePassX lit les fichiers KeePass v1. CloudKeePass lit les fichiers KeePass v2. Donc c'est pas compatible.
C'est exactement ça. Dans ma vision, CloudKeePass est complémentaire à KeePass ou tout autre logiciel sachant lire le format KDBX.
Néanmoins, ça ne coûterait pas cher d'ajouter quelques entêtes meta, mais il faut que je vérifie la faisabilité dans SproutCore. Je note ça sur ma TODO, j'y jetterai un œil à l'occasion.
J'ai essayé aussi, mais beaucoup ne comprennent même pas de quoi je leur parle.
Et puis, les habitudes ont la vie dure. Il n'y a pas longtemps j'ai donnée l'accès root à un prestataire du client en installant une clé SSH. Jusque là tout va bien. Deux mois après, parce qu'il faisait des tests d'authentification LDAP, le prestataire met un mot de passe au compte root. En moins de 24h le mot de passe a été brute-forcé. J'imagine même pas la tronche du mot de passe (root/root ?).
Autre exemple qui illustre la même problématique. Un client décide d'installer PostgreSQL sur son serveur. Il trouve un tuto sur Internet et le suit à la lettre. Dans le tuto, il fallait créer un compte utilisateur postgres avec un mot de passe. Dans le tuto, le MdP était postgres. Ai je besoin de dire ce qui s'est passé…
Bref, il y a malheureusement beaucoup de personnes dont ce n'est pas le métier qui administrent des serveurs…
EmberJS devait être Sproutcore v2. Sauf qu'ils sont partis tellement loin dans les changements, qu'ils ont finalement décidé d'en faire un projet à part. Par ailleurs, un vrai Sproutcore v2 est en approche (aucune date prévue).
Les deux approches sont assez différentes selon moi, mais on retrouve une partie des concepts de Sproutcore dans EmberJS (bindings, observers, …). J'ai essayé EmberJS, mais je n'ai pas du tout accroché. Question de goûts certainement (ou peut être que je n'ai pas assez fait d'effort pour me mettre à EmberJS)…
J'aime bien que tout soit en Javascript (pas de HTML, pas de langage exotique comme Objective-J, …).
J'aime bien le concept des bindings où j'attache un élément de l'interface graphique à un attribut d'un objet, et que quand la valeur de l'un est modifiée, l'autre le soit aussi.
J'aime bien les observers où je peux déclencher une action quand une valeur est modifiée.
J'aime bien que je puisse utiliser des diagrammes d'état et que donc ça aide à éliminer une partie des bugs.
J'aime bien que les tests unitaires ne soient une sorte de vérue/rajout sur le projet existant.
Chez moi, pas un seul serveur n'a un uptime de plus de 30 jours, et c'est volontaire. Un serveur jamais redémarré, ça veut dire un noyau jamais mis à jour. Entre les problèmes de sécurité et les bugs, il y a au moins une mise à jour par mois.
La dernière fois que je n'ai pas été rigoureux dans le suivi des mises à jours, je suis tombé sur un bug qui faisait un kernel panic au bout de 208 jours d'uptime. Le paquet mis à jour était dispo depuis plusieurs semaines…
remarque, il faudrait peut-etre simplement tout doubler.
- 2 cartes reseaux sur le serveur de VM
- 2 switchs (un par carte reseau)
- 2 cartes reseaux sur le serveur de stockage
C'est la bonne solution. Si tu fais de l'ISCSI, tu as donc 2 fois le block device qui apparait sur ton système (ex: sdf et sdh), ce qui te permet de faire du multipath. C'est simple à déployer et très robuste si bien configuré. Attention, le channel bonding n'est pas une bonne solution car il ne teste pas l'applicatif, il ne fait que vérifier que l'interface est UP (il y a bien une possibilité de ping ARP mais je n'ai jamais testé).
Dernier conseil : l'ISCSI c'est de l'IP, donc attention à la table de routage. Avoir deux interfaces c'est bien, si tout est routé par la même interface, ça ne sert plus à rien.
Interco en IP privée. Comme le dit Vincent, c'est tout à fait classique. Ca ne veut pas dire pour autant que tu peux joindre 10.99.99.2 de chez toi. En gros, ton paquet IP qui véhicule l'ICMP contient l'IP 10.99.99.2 en source et ton IP en destination.
Tout est dit : si tu n'a qu'un serveur on s'en fout. Comme Arcaik, je travaille dans une TPE (hébergeur/FAI). Je gère au quotidien quelques centaines de serveurs (95% Linux, 5% Windows et FreeBSD) et une quarantaine d'équipements réseaux (commutateur, routeur, pare-feu).
Pour changer de plan IP, ça implique :
- prévenir tous les clients que le changement va avoir lieu
- configurer le nouveau plan IP en parallèle de l'ancien sur toute la couche réseau
- Vérifier toutes les règles de filtrage, que la supervision est à jour, …
- ajouter la nouvelle IP à chaque serveur
- valider pour chaque serveur qu'il est prêt à passer sur la nouvelle IP (vérifier avec le client)
- Retirer l'ancienne IP de chaque serveur
- Réparer les merdes (parce qu'il y en aura)
- Déconfigurer l'ancien plan IP
Pour nous, avec deux /21 et un /23, c'est un minimum de 6 mois du début à la fin (oui, on est qu'en IPv4 pour le moment, mais on aura mis en prod IPv6 avant février prochain).
Toutes ces étapes sont nécessaires car tu ne sais jamais où sont utilisé tes IP. Dans tes DNS (là tu as la main), mais aussi dans les zones DNS de tes clients (qui sont parfois gérer à l'étranger à cause de certains TLD). Les IP peuvent être inscrite en dur dans un équipement (j'ai le cas d'un client qui fait de l'embarqué, un changement d'IP pour lui c'est une galère)
C'est sûr, on peux aussi y aller comme des bourrin comme tu le suggère, mais alors là c'est l'assurance d'une grosse gamelle !
Le matériel c'est nul, ça tombe en panne, ça chauffe, ya des faux contact, …
Prend une machine virtuelle au lieu d'un serveur physique. En t'abstrayant du matériel, tu laisse le soin à l'hébergeur de gérer ça (et lui il aura un SAN et tout ce qu'il faut pour garantir que ça tourne).
Par contre, si tu veux toi même virtualiser sur ton serveur physique, ben y a pas d'autre solution que de se prendre la tête à gérer le matériel.
Couper l'alimentation des barrettes de RAM ? Tu m'intrigue. Parce que le principe de la RAM telle qu'on la trouve dans nos ordinateurs, c'est que sans électricité les données sont perdues.
Posté par ondex2 .
En réponse au journal realloc.
Évalué à 6.
Ca dépend. Pour ceux qui sont à TH2, les coupures de courant régulières permettent de libérer la mémoire avant qu'une fuite de mémoire ne vautre le serveur…
Assez d'accord. J'ajouterais le manque de contraste entre les éléments d'une fenêtre. Je trouve que ça manque de "lisibilité", et que donc ça fatigue l'œil qui dois toujours être en train de chercher les limites de la fenêtre.
Mon thème de référence sous GNOME c'est Adwaita Cupertino SL (3ème capture d'écran). Surement que d'avoir également un Mac a influencé mon choix de thème, mais j'en suis juste très satisfait.
Si les entreprises prennent RHEL, c'est en partie (surtout?) pour la durée de la période de maintenance.
Puisque RHEL5 est maintenue jusqu'en 2017 (voire 2020 pour ceux qui paient), ça ne sert à rien de se précipiter pour tout basculer. Il sera bien temps de s'en inquiéter 1 à 2 ans avant la fin de maintenance, selon la complexité des applicatifs installés dessus.
Par contre, j'espère que pour les nouveaux déploiement, c'est du RHEL6.
Parce que sur quelques dizaines de serveurs, des centaines de VM dont certaines pas du tout à jours (il y a encore une ou deux Debian Sarge qui trainent), des équipements SAN et réseau, rien dans la supervision, rien dans la métrologie non plus…
Je dormirai tranquille cette nuit, on verra demain matin si j'ai eu raison…
Niveau client caldav/carddav, il y a le choix. Avec SOGo, j'utilise, avec succès les clients suivant :
- Thunderbird + lightning (+connecteur SOGo) : CalDAV et CardDAV
- Evolution : CalDAV et CardDAV
- le "truc" de KDE 4 avec Kontact & co : CalDAV et CardDAV
- Mac OS X iCal et Address Book : CalDAV et CardDAV
- iOS Agenda et Contacts : CalDAV et CardDAV
- Android, CalDAV-Sync et CardDAV-Sync : CalDAV et CardDAV
Tout ça fonctionne bien à très bien avec SOGo donc j'imagine que si l'implémentation de OwnCloud est correct, ça le fait. Pour info, le moins bon est Evolution car il faut rentrer tous les agendas et carnets d'adresses à la main (par de detection auto des inscriptions).
[^] # Re: Aucune chance de percer (bis)
Posté par ondex2 . En réponse au journal Nouveau format d'image BPG. Évalué à 3.
Quelqu'un qui sert des dizaines/centaines de millions d'images par jour (ex: une grosse régie pub). La bande passante ça coute cher.
# Ergonomie
Posté par ondex2 . En réponse à la dépêche Piwigo 2.7 : un chez-soi pour vos photos. Évalué à 2.
J'administre une galerie privée depuis quelques années. J'avais choisi Gallery 3 de Menalto. Pour moi, ce qui fait la différence entre Gallery 3 et les autres galeries, c'est le soin qui a été apporté à l'ergonomie.
Ma galerie me sert principalement à partager des photos d'événements (vacances, week-end, repas, sorties, …) avec des connaissances (amis, famille). Chaque utilisateur (ou groupe d'utilisateurs) a un login/mot de passe. J'ai donc un panel d'utilisateurs assez varié : de ceux qui maitrisent bien la "chose" informatique à ceux qui galèrent pour joindre un fichier à un email. La galerie doit donc être (littéralement) KISS, pour qu'ils puissent tous naviguer, télécharger et envoyer des photos/vidéos.
Après l'annonce de la fin du projet G3 (ça semble acquis, il y a eu un petit espoir de reprise du projet, mais ça bouge plus), j'ai testé différents logiciels de galeries, dont Piwigo. Il m'a semblé qu'aucun d'entre eux n'a apporté le même soin de faire une interface simple d'utilisation. Je suis donc toujours "coincé" sur Gallery 3, jusqu'au jour ou je n'aurais plus le choix (faille de sécurité non patché)
Un exemple en ce qui concerne Piwigo : pour envoyer une photo il faut aller dans "administration > ajouter une photo", puis choisir l'album. C'est 3 étapes de trop. Lorsque je suis dans l'album, ça me parait naturel d'avoir un bouton "envoyer des photos" sans que le contexte change. Envoyer une photo ou créer un album, c'est pas acte d'administration, c'est de l'utilisation.
Il ne faut voir aucune attaque dans mon message, juste une critique qui j'espère sera constructive. Je souhaites une longue vie à Piwigo, même s'il ne me convient pas, c'est une belle réussite.
[^] # Re: Je plussoie
Posté par ondex2 . En réponse au journal Cloud Kee Pass - version « même pas encore alpha ». Évalué à 1.
Effectivement, tout se passe côté navigateur. Les seules données qui transitent sont :
1. les fichiers de l'application elle même (html/js/css) => aucun risque ici
2. le fichier KDBX s'il est stocké sur le serveur. Ce fichier est chiffré, le risque est donc très limité.
L'utilisation de SSL n'est donc pas absolument nécessaire.
Mais si tu crains un MITM qui remplacerait les fichiers de l'application pour voler ta passphrase, le SSL est une réponse.
[^] # Re: Oui mais
Posté par ondex2 . En réponse à la dépêche Cloud Kee Pass - version « même pas encore alpha ». Évalué à 2.
Il y a deux méthodes :
1/ ouvrir un fichier distant, en fournissant l'URL dans l'écran de déverrouillage ;
2/ ouvrir un fichier local, en le glissant sur l'écran de déverrouillage.
Dans le premier cas, c'est du total distant (c'est cloud ;-) )
Le second cas est utile si tu n'as pas de serveur webdav et que tu n'est pas chez toi. Tu n'as pas forcément envie d'installer toute la couche mono chez tes amis/ta famille juste pour lancer KeePass pour récupérer un mot de passe. Alors tu sors ta clé USB, et voilà :-D
[^] # Re: En entreprise
Posté par ondex2 . En réponse à la dépêche Cloud Kee Pass - version « même pas encore alpha ». Évalué à 2.
Le format KDBX, c'est un fichier qui contient tout. Donc ce n'est pas trop adapté au travail en équipe, il y aurait des problèmes de concurrence.
Il suffit que ton collègue enregistre une nouvelle version du fichier et qu'ensuite tu enregistre également sans avoir rechargé entre temps -> tu écrase ces modifications.
Il te faut une solution client/serveur où c'est le serveur qui gère les données pour pouvoir gérer la concurrence. CloudKeePass est une application qui stockera en WebDAV un fichier, mais le serveur n'a aucune idée de la nature des données.
[^] # Re: KeePassX
Posté par ondex2 . En réponse à la dépêche Cloud Kee Pass - version « même pas encore alpha ». Évalué à 2.
Le format de fichier entre KeePass v1 et KeePass v2 a changé. KeePassX lit les fichiers KeePass v1. CloudKeePass lit les fichiers KeePass v2. Donc c'est pas compatible.
[^] # Re: Application Web hors-ligne
Posté par ondex2 . En réponse à la dépêche Cloud Kee Pass - version « même pas encore alpha ». Évalué à 2.
C'est exactement ça. Dans ma vision, CloudKeePass est complémentaire à KeePass ou tout autre logiciel sachant lire le format KDBX.
Néanmoins, ça ne coûterait pas cher d'ajouter quelques entêtes meta, mais il faut que je vérifie la faisabilité dans SproutCore. Je note ça sur ma TODO, j'y jetterai un œil à l'occasion.
[^] # Re: Hum
Posté par ondex2 . En réponse au journal Hypocrisie de Nvidia envers le libre : le pilote graphique Linux volontairement dégradé ?. Évalué à 3.
Je connais plusieurs personnes (moi compris), travaillant avec 4 écrans ou plus. Et pour ne rien gâcher, on utilise des cartes Nvidia…
Inexistant tu disais ?
# Mort aux AC, vive DANE
Posté par ondex2 . En réponse à la dépêche Certificat SSL/TLS pour serveur web, HTTPS et problèmes associés. Évalué à 5.
DANE semble être une solution séduisante. Plutôt que de faire un mauvais résumé : http://www.bortzmeyer.org/6698.html
[^] # Re: CPanel soupçonné
Posté par ondex2 . En réponse à la dépêche Infection par rootkit « SSHd Spam » sur des serveurs RHEL/CentOS. Évalué à 10.
J'ai essayé aussi, mais beaucoup ne comprennent même pas de quoi je leur parle.
Et puis, les habitudes ont la vie dure. Il n'y a pas longtemps j'ai donnée l'accès root à un prestataire du client en installant une clé SSH. Jusque là tout va bien. Deux mois après, parce qu'il faisait des tests d'authentification LDAP, le prestataire met un mot de passe au compte root. En moins de 24h le mot de passe a été brute-forcé. J'imagine même pas la tronche du mot de passe (root/root ?).
Autre exemple qui illustre la même problématique. Un client décide d'installer PostgreSQL sur son serveur. Il trouve un tuto sur Internet et le suit à la lettre. Dans le tuto, il fallait créer un compte utilisateur postgres avec un mot de passe. Dans le tuto, le MdP était postgres. Ai je besoin de dire ce qui s'est passé…
Bref, il y a malheureusement beaucoup de personnes dont ce n'est pas le métier qui administrent des serveurs…
[^] # Re: Sproutcore
Posté par ondex2 . En réponse au journal Écrire une application web de nos jours. Évalué à 2.
EmberJS devait être Sproutcore v2. Sauf qu'ils sont partis tellement loin dans les changements, qu'ils ont finalement décidé d'en faire un projet à part. Par ailleurs, un vrai Sproutcore v2 est en approche (aucune date prévue).
Les deux approches sont assez différentes selon moi, mais on retrouve une partie des concepts de Sproutcore dans EmberJS (bindings, observers, …). J'ai essayé EmberJS, mais je n'ai pas du tout accroché. Question de goûts certainement (ou peut être que je n'ai pas assez fait d'effort pour me mettre à EmberJS)…
# Sproutcore
Posté par ondex2 . En réponse au journal Écrire une application web de nos jours. Évalué à 4.
Moi, je fais du Sproutcore, et j'aime bien ça.
Mais, chacun ses goûts…
[^] # Re: Je confirme que ça marche bien
Posté par ondex2 . En réponse au journal Mon Raspberry pi a un uptime de 14 jours !. Évalué à 7.
Chez moi, pas un seul serveur n'a un uptime de plus de 30 jours, et c'est volontaire. Un serveur jamais redémarré, ça veut dire un noyau jamais mis à jour. Entre les problèmes de sécurité et les bugs, il y a au moins une mise à jour par mois.
La dernière fois que je n'ai pas été rigoureux dans le suivi des mises à jours, je suis tombé sur un bug qui faisait un kernel panic au bout de 208 jours d'uptime. Le paquet mis à jour était dispo depuis plusieurs semaines…
[^] # Re: question sur la HA justement.
Posté par ondex2 . En réponse à la dépêche Proxmox, la virtualisation facile. Évalué à 2.
C'est la bonne solution. Si tu fais de l'ISCSI, tu as donc 2 fois le block device qui apparait sur ton système (ex: sdf et sdh), ce qui te permet de faire du multipath. C'est simple à déployer et très robuste si bien configuré. Attention, le channel bonding n'est pas une bonne solution car il ne teste pas l'applicatif, il ne fait que vérifier que l'interface est UP (il y a bien une possibilité de ping ARP mais je n'ai jamais testé).
Dernier conseil : l'ISCSI c'est de l'IP, donc attention à la table de routage. Avoir deux interfaces c'est bien, si tout est routé par la même interface, ça ne sert plus à rien.
[^] # Re: PEBKAC Comme d'hab...
Posté par ondex2 . En réponse au journal Gnome-Shell, toujours pas convainquant après 1 an et demi. Évalué à 1.
Quelques informations sur le sujet :
http://worldofgnome.org/keywords-in-desktop-promises-better-app-discovery-in-gnome-shell/
# Normal
Posté par ondex2 . En réponse au journal RFC 3251 : 10.0.0.0/24 est désormais routable sur internet. Évalué à 2.
Interco en IP privée. Comme le dit Vincent, c'est tout à fait classique. Ca ne veut pas dire pour autant que tu peux joindre 10.99.99.2 de chez toi. En gros, ton paquet IP qui véhicule l'ICMP contient l'IP 10.99.99.2 en source et ton IP en destination.
[^] # Re: ipv8
Posté par ondex2 . En réponse à la dépêche IPv6 : des poules et des hommes. Évalué à 5.
Tout est dit : si tu n'a qu'un serveur on s'en fout. Comme Arcaik, je travaille dans une TPE (hébergeur/FAI). Je gère au quotidien quelques centaines de serveurs (95% Linux, 5% Windows et FreeBSD) et une quarantaine d'équipements réseaux (commutateur, routeur, pare-feu).
Pour changer de plan IP, ça implique :
- prévenir tous les clients que le changement va avoir lieu
- configurer le nouveau plan IP en parallèle de l'ancien sur toute la couche réseau
- Vérifier toutes les règles de filtrage, que la supervision est à jour, …
- ajouter la nouvelle IP à chaque serveur
- valider pour chaque serveur qu'il est prêt à passer sur la nouvelle IP (vérifier avec le client)
- Retirer l'ancienne IP de chaque serveur
- Réparer les merdes (parce qu'il y en aura)
- Déconfigurer l'ancien plan IP
Pour nous, avec deux /21 et un /23, c'est un minimum de 6 mois du début à la fin (oui, on est qu'en IPv4 pour le moment, mais on aura mis en prod IPv6 avant février prochain).
Toutes ces étapes sont nécessaires car tu ne sais jamais où sont utilisé tes IP. Dans tes DNS (là tu as la main), mais aussi dans les zones DNS de tes clients (qui sont parfois gérer à l'étranger à cause de certains TLD). Les IP peuvent être inscrite en dur dans un équipement (j'ai le cas d'un client qui fait de l'embarqué, un changement d'IP pour lui c'est une galère)
C'est sûr, on peux aussi y aller comme des bourrin comme tu le suggère, mais alors là c'est l'assurance d'une grosse gamelle !
# Virtualisation
Posté par ondex2 . En réponse au journal Avoir un serveur sans trop se casser la tête avec l'administration ?. Évalué à 8.
Le matériel c'est nul, ça tombe en panne, ça chauffe, ya des faux contact, …
Prend une machine virtuelle au lieu d'un serveur physique. En t'abstrayant du matériel, tu laisse le soin à l'hébergeur de gérer ça (et lui il aura un SAN et tout ce qu'il faut pour garantir que ça tourne).
Par contre, si tu veux toi même virtualiser sur ton serveur physique, ben y a pas d'autre solution que de se prendre la tête à gérer le matériel.
[^] # Re: GreenIT
Posté par ondex2 . En réponse à la dépêche Sortie de PostgreSQL 9.2. Évalué à 3.
Couper l'alimentation des barrettes de RAM ? Tu m'intrigue. Parce que le principe de la RAM telle qu'on la trouve dans nos ordinateurs, c'est que sans électricité les données sont perdues.
# Virtualisation
Posté par ondex2 . En réponse au journal Un instantané du parc serveur du Conseil général de Maine-et-Loire. Évalué à 3.
118 VM, mais pour combien de serveur de virtualisation ? Le ratio est intéressant à connaitre.
[^] # Re: Ne le fait pas.
Posté par ondex2 . En réponse au journal realloc. Évalué à 6.
Ca dépend. Pour ceux qui sont à TH2, les coupures de courant régulières permettent de libérer la mémoire avant qu'une fuite de mémoire ne vautre le serveur…
[^] # Re: KDE, « What else ? »
Posté par ondex2 . En réponse à la dépêche KDE 4.9 est sorti. Évalué à 0.
Assez d'accord. J'ajouterais le manque de contraste entre les éléments d'une fenêtre. Je trouve que ça manque de "lisibilité", et que donc ça fatigue l'œil qui dois toujours être en train de chercher les limites de la fenêtre.
Mon thème de référence sous GNOME c'est Adwaita Cupertino SL (3ème capture d'écran). Surement que d'avoir également un Mac a influencé mon choix de thème, mais j'en suis juste très satisfait.
[^] # Re: Adoption en entreprise
Posté par ondex2 . En réponse à la dépêche Le chapeau rouge arrive bientôt dans sa version 7 !. Évalué à 3.
Si les entreprises prennent RHEL, c'est en partie (surtout?) pour la durée de la période de maintenance.
Puisque RHEL5 est maintenue jusqu'en 2017 (voire 2020 pour ceux qui paient), ça ne sert à rien de se précipiter pour tout basculer. Il sera bien temps de s'en inquiéter 1 à 2 ans avant la fin de maintenance, selon la complexité des applicatifs installés dessus.
Par contre, j'espère que pour les nouveaux déploiement, c'est du RHEL6.
# Il existe vraiment ce bug ?
Posté par ondex2 . En réponse au journal Leap second. Évalué à -2.
Il existe vraiment ce bug ?
Parce que sur quelques dizaines de serveurs, des centaines de VM dont certaines pas du tout à jours (il y a encore une ou deux Debian Sarge qui trainent), des équipements SAN et réseau, rien dans la supervision, rien dans la métrologie non plus…
Je dormirai tranquille cette nuit, on verra demain matin si j'ai eu raison…
[^] # Re: oudClown, une solution qu’elle est bien pour mon nuage
Posté par ondex2 . En réponse à la dépêche ownCloud 4 est sorti. Évalué à 5.
Niveau client caldav/carddav, il y a le choix. Avec SOGo, j'utilise, avec succès les clients suivant :
- Thunderbird + lightning (+connecteur SOGo) : CalDAV et CardDAV
- Evolution : CalDAV et CardDAV
- le "truc" de KDE 4 avec Kontact & co : CalDAV et CardDAV
- Mac OS X iCal et Address Book : CalDAV et CardDAV
- iOS Agenda et Contacts : CalDAV et CardDAV
- Android, CalDAV-Sync et CardDAV-Sync : CalDAV et CardDAV
Tout ça fonctionne bien à très bien avec SOGo donc j'imagine que si l'implémentation de OwnCloud est correct, ça le fait. Pour info, le moins bon est Evolution car il faut rentrer tous les agendas et carnets d'adresses à la main (par de detection auto des inscriptions).