Ce que j'ai fait pour améliorer la réactivité du système est d'utiliser un ssd pour /, et de monter un disque de stockage dans le répertoire /home/~/data. En effet les applis comme Thunderbird font beaucoup d'accès à des fichiers situés dans ~/.* et donc avoir ce répertoire sur un SSD améliore leur temps de démarrage et leur réactivité également.
Ne se trompe-t-on pas d'objectif dans ce cas là, vu que le l'intérêt du cloud est justement de ne pas avoir à s'occuper d'un serveur ? Ne devrait-on pas trouver des solutions pour réellement garantir à l'utilisateur la maitrise de ses données, sans qu'il ait à maintenir un serveur, le sauvegarder, etc ?
Si le but est protéger les utilisateurs de "cloud", utiliser des piles libres (Openstack et consorts) ne garantit rien à ce sujet là, puisque que le fournisseur peut toujours verrouiller l'utilisateur.
Quelles sont donc les initiatives pour garantir la liberté dans le reste de la chaine ?
La difficulté est de pouvoir discriminer les différents flux utilisés, et principalement le P2P. La méthode la plus simple que j'ai trouvée est d'utiliser une seedbox pour tout le monde avec Deluge, et de configurer Deluge pour ajouter un champ TOS particulier dans les paquets IP.
Ensuite tu mets ce trafic dans une file qdisc avec une priorité minimale, le reste du trafic allant dans d'autres files.
Avec cette solution tu peux permettre à tout le monde de télécharger pleine balle toute la journée, tout en gardant des très bons débit et latence pour le reste.
Suis-je un original de trouver le fait que RHEL 7 utilisera XFS comme FS par défaut bien plus important et étonnant que le changement de l'interface par défaut d'une distribution majoritairement utilisée pour des serveurs sans interface graphique ?
Faire du support, de la formation, des certifications et du service liés à Nagios Core, c'est gagner de l'argent avec un logiciel libre.
Vendre une surcouche propriétaire c'est gagner de l'argent avec du logiciel propriétaire, mais tout en gagnant de la légitimité grâce au produit libre.
Je persiste donc à dire qu'ils gagnent de l'argent autour d'un logiciel libre.
Au début il avait du mal. Ensuite il a monté sa boîte (Nagios Enterprises), qui fait du support, de la formation, du consulting, et qui vend du logiciel sous la forme open core (Nagios core en GPL et Nagios XI en propriétaire). Maintenant ça va mieux pour lui.
Ça montre qu'il est possible d'avoir un modèle pour gagner de l'argent autour d'un logiciel libre (même s'il faut ajouter des add-ons proprio) mais sa base d'utilisateurs est sans commune mesure avec la tienne.
Ce n'est pas nécessaire sous RedHat/Fedora, car yum le gère automatiquement (le nombre de noyaux à garder est configurable), sous ArchLinux il n'y a toujours qu'un noyau installé dans /boot (sous réserve que l'utilisateur n'installe pas des paquets de noyau alternatifs, mais chacun n'installera toujours qu'un noyau dans /boot).
Pas forcément, j'ai eu récemment le cas d'un ordinateur portable avec aucun pilote réseau (ni ethernet ni wifi) ne fonctionnant avec une debian wheezy.
Tu compiles toi-même les logiciels dont tu as besoin, sur un système identique au système cible, ensuite tu les installes dans un chemin distinct pour ne pas avoir de collision avec ton système.
Tu peux avoir besoin d'embarquer des librairies plus à jour, et donc là en effet tu as besoin de modifier ton chemin de chargement des librairies partagées comme expliqué par d'autres commentaires.
Je n'avais pas vu que tu voulais une version plus récente de bash. Ça permet d'installer certains composants manquants sans toucher au reste du système car les versions en dépendance de ces composants sont cohérentes avec celles installées sur le système, mais j'ai mal compris ton besoin.
Si cette machine n'a vraiment jamais été mise à jour, tu récupères une image du DVD (trouvable sur des sites d'archéologie je pense) et tu installes tes paquets en configurant yum pour qu'il utilise le DVD comme source.
D'après le Changelog il faut mettre "glamor" comme AccelMethod. D'ailleurs ce paramètre a bien un effet puisqu'il fait freezer mon système. À noter que XV n'est pas supporté avec Glamor.
Machine inutilisable pendant 1 ou 2 jours à la suite d'une maj de arch ? Ça ne m'est jamais arrivé pourtant… Après c'est vrai que des fois il faut lire la page d'accueil du site de arch et faire ce qui est écrit, en effet ça ne marche pas toujours tout seul.
2 x 8 Gio. Ce qui prenait le plus de place était le scheduler et les brokers (livestatus et webui).
Le temps de redémarrage était de plus de cinq minutes, avec une indisponibilité totale de la supervision pendant ce laps de temps.
Avec Nagios ça prend bien moins de temps, surtout que dans un archi distribuée je peux redémarrer uniquement le serveur qui le nécessite, et ça va donc beaucoup plus vite, et sans interférer sur le reste.
Pour info j'ai environ une minute de temps de redémarrage sur un server Nagios avec 30k services, et moins de 10s pour un serveur avec environ 5k services, donc c'est tout de même beaucoup mieux.
C'est une architecture distribuée à base de NDOMOD (archi distribuée standard Centreon).
Elle est distribuée d'abord pour des besoins de localisation (plusieurs datacenters) et aussi de performance (nous montons jusqu'à 25K services sur un serveur Nagios physique, on doit pouvoir faire plus mais il faut mettre un peu les mains dans le cambouis).
Un autre type d'architecture distribuée peut être d'avoir un seul serveur Nagios, et rajouter avec mod_gearman des "workers" autant que nécessaire.
Tu peux aussi découper la conf sur plusieurs serveurs et tous les visualiser avec une interface qui le supporte comme Thruk.
Et Nagios 4 qui devrait arriver un jour supportera nativement le principe de workers (comme avec Shinken ou mod_gearman).
Tu as donc de multiples possibilités, il ne te reste plus qu'à choisir ;-)
On fait tourner du Nagios/Centreon avec 50k services et 50 utilisateurs simultanés, tu as de la marge donc ;-)
J'ai testé Shinken sur un environnement avec 24k services, j'ai eu pas mal de problèmes de perf (conso mémoire et temps de redémarrage). C'était il y a 10 mois donc les choses ont du évoluer depuis mais je ne suis pas super enthousiaste quand même.
[^] # Re: Ok je réponds
Posté par paulez (site web personnel) . En réponse au message Cherche SSD pour partition système. Évalué à 1.
Ce que j'ai fait pour améliorer la réactivité du système est d'utiliser un ssd pour /, et de monter un disque de stockage dans le répertoire /home/~/data. En effet les applis comme Thunderbird font beaucoup d'accès à des fichiers situés dans ~/.* et donc avoir ce répertoire sur un SSD améliore leur temps de démarrage et leur réactivité également.
# btrfs
Posté par paulez (site web personnel) . En réponse au message Une partition sur deux disques ?. Évalué à 1.
Sinon tu peux faire ça avec btrfs : https://btrfs.wiki.kernel.org/index.php/Using_Btrfs_with_Multiple_Devices
Plus simple qu'avec LVM je trouve, mais moins éprouvé.
[^] # Re: OpenStack et verrouillage de l'utilisateur
Posté par paulez (site web personnel) . En réponse à la dépêche Open Cloud : the next step? Avec John Sullivan, FSF. Évalué à 2.
Ne se trompe-t-on pas d'objectif dans ce cas là, vu que le l'intérêt du cloud est justement de ne pas avoir à s'occuper d'un serveur ? Ne devrait-on pas trouver des solutions pour réellement garantir à l'utilisateur la maitrise de ses données, sans qu'il ait à maintenir un serveur, le sauvegarder, etc ?
# OpenStack et verrouillage de l'utilisateur
Posté par paulez (site web personnel) . En réponse à la dépêche Open Cloud : the next step? Avec John Sullivan, FSF. Évalué à 6.
Si le but est protéger les utilisateurs de "cloud", utiliser des piles libres (Openstack et consorts) ne garantit rien à ce sujet là, puisque que le fournisseur peut toujours verrouiller l'utilisateur.
Quelles sont donc les initiatives pour garantir la liberté dans le reste de la chaine ?
# qdisc
Posté par paulez (site web personnel) . En réponse au message Limitation débit sur un routeur. Évalué à 2.
Ça se fait avec qdisc, voici la section qui va bien dans LARTC (the Linux Advanced Routing and Traffic Control HOWTO).
La difficulté est de pouvoir discriminer les différents flux utilisés, et principalement le P2P. La méthode la plus simple que j'ai trouvée est d'utiliser une seedbox pour tout le monde avec Deluge, et de configurer Deluge pour ajouter un champ TOS particulier dans les paquets IP.
Ensuite tu mets ce trafic dans une file qdisc avec une priorité minimale, le reste du trafic allant dans d'autres files.
Avec cette solution tu peux permettre à tout le monde de télécharger pleine balle toute la journée, tout en gardant des très bons débit et latence pour le reste.
[^] # Re: Une autre pépite :
Posté par paulez (site web personnel) . En réponse au journal RHEL 7 utilisera GNOME Shell en mode Classique.... Évalué à 2.
Le changement c'est pour le choix par défaut, lors d'une mise à jour je ne pense pas qu'ils proposent de convertir les FS existants.
[^] # Re: Une autre pépite :
Posté par paulez (site web personnel) . En réponse au journal RHEL 7 utilisera GNOME Shell en mode Classique.... Évalué à 3.
Suis-je un original de trouver le fait que RHEL 7 utilisera XFS comme FS par défaut bien plus important et étonnant que le changement de l'interface par défaut d'une distribution majoritairement utilisée pour des serveurs sans interface graphique ?
Merci pour l'info en tous cas !
[^] # Re: oui, classique.
Posté par paulez (site web personnel) . En réponse au journal L'open source va me tuer .... Évalué à 3.
Faire du support, de la formation, des certifications et du service liés à Nagios Core, c'est gagner de l'argent avec un logiciel libre.
Vendre une surcouche propriétaire c'est gagner de l'argent avec du logiciel propriétaire, mais tout en gagnant de la légitimité grâce au produit libre.
Je persiste donc à dire qu'ils gagnent de l'argent autour d'un logiciel libre.
[^] # Re: oui, classique.
Posté par paulez (site web personnel) . En réponse au journal L'open source va me tuer .... Évalué à 3.
Au début il avait du mal. Ensuite il a monté sa boîte (Nagios Enterprises), qui fait du support, de la formation, du consulting, et qui vend du logiciel sous la forme open core (Nagios core en GPL et Nagios XI en propriétaire). Maintenant ça va mieux pour lui.
Ça montre qu'il est possible d'avoir un modèle pour gagner de l'argent autour d'un logiciel libre (même s'il faut ajouter des add-ons proprio) mais sa base d'utilisateurs est sans commune mesure avec la tienne.
[^] # Re: Utile uniquement sous Debian ?
Posté par paulez (site web personnel) . En réponse au message comment je vide proprement mon /boot des vieux noyaux installés par ma distrib. Évalué à 1. Dernière modification le 31 mai 2013 à 12:35.
Sous Arch non tu ne l'as plus en effet.
Généralement j'installe aussi un LTS pour parer à ce genre de cas (qui arrive rarement mais qui arrive).
# Utile uniquement sous Debian ?
Posté par paulez (site web personnel) . En réponse au message comment je vide proprement mon /boot des vieux noyaux installés par ma distrib. Évalué à 2.
Ce n'est pas nécessaire sous RedHat/Fedora, car yum le gère automatiquement (le nombre de noyaux à garder est configurable), sous ArchLinux il n'y a toujours qu'un noyau installé dans /boot (sous réserve que l'utilisateur n'installe pas des paquets de noyau alternatifs, mais chacun n'installera toujours qu'un noyau dans /boot).
[^] # Re: Carte graphique Intel
Posté par paulez (site web personnel) . En réponse au message Portable récent et Debian (stable, free). Évalué à 1.
Pas forcément, j'ai eu récemment le cas d'un ordinateur portable avec aucun pilote réseau (ni ethernet ni wifi) ne fonctionnant avec une debian wheezy.
# Compil'
Posté par paulez (site web personnel) . En réponse au message Rendre autonome un logiciel. Évalué à 1.
Tu compiles toi-même les logiciels dont tu as besoin, sur un système identique au système cible, ensuite tu les installes dans un chemin distinct pour ne pas avoir de collision avec ton système.
Tu peux avoir besoin d'embarquer des librairies plus à jour, et donc là en effet tu as besoin de modifier ton chemin de chargement des librairies partagées comme expliqué par d'autres commentaires.
[^] # Re: DVD
Posté par paulez (site web personnel) . En réponse au message Rendre autonome un logiciel. Évalué à 1.
Je n'avais pas vu que tu voulais une version plus récente de bash. Ça permet d'installer certains composants manquants sans toucher au reste du système car les versions en dépendance de ces composants sont cohérentes avec celles installées sur le système, mais j'ai mal compris ton besoin.
# Noyau
Posté par paulez (site web personnel) . En réponse au message Linux sur calculette (TI 83+) ?. Évalué à 1.
Je n'ai pas l'impression que le noyau lui-même supporte l'architecture Z80, donc je doute fort qu'il existe un système Linux tournant sur un Z80.
# DVD
Posté par paulez (site web personnel) . En réponse au message Rendre autonome un logiciel. Évalué à 0.
Si cette machine n'a vraiment jamais été mise à jour, tu récupères une image du DVD (trouvable sur des sites d'archéologie je pense) et tu installes tes paquets en configurant yum pour qu'il utilise le DVD comme source.
# Fetchmail
Posté par paulez (site web personnel) . En réponse au journal Être averti de ses emails intelligemment. Évalué à 7.
Je n'ai peut-être pas bien compris, mais Fetchmail ne répond-il pas à ton besoin ?
[^] # Re: Driver proprio
Posté par paulez (site web personnel) . En réponse au message Plus de gnome3 sous ma debian testing après la dernière mise à jour. Évalué à 2.
Regarde ce que ça raconte dans /var/log/Xorg.0.log ?
[^] # Re: AccelMethod
Posté par paulez (site web personnel) . En réponse au journal Pilotes ATI libres, voici venu le temps du Glamour. Évalué à 1.
À priori il faut aussi ajouter le chargement du module dans la conf. cf https://wiki.archlinux.org/index.php/Ati#Glamor
# AccelMethod
Posté par paulez (site web personnel) . En réponse au journal Pilotes ATI libres, voici venu le temps du Glamour. Évalué à 4.
D'après le Changelog il faut mettre "glamor" comme AccelMethod. D'ailleurs ce paramètre a bien un effet puisqu'il fait freezer mon système. À noter que XV n'est pas supporté avec Glamor.
# Serveur X dédié
Posté par paulez (site web personnel) . En réponse au message Ecran déporté + Ubuntu = Probleme !. Évalué à 2.
Tu peux lancer un serveur X distinct dédié à cet écran et y lancer ton appli sans gestionnaire de fenêtre.
[^] # Re: Des trucs de ce genre ça m'est arrivé 1 fois sur 2 à chaque mise à jour de Arch ...
Posté par paulez (site web personnel) . En réponse au journal Les paquets, c'est merveilleux !. Évalué à 5.
Machine inutilisable pendant 1 ou 2 jours à la suite d'une maj de arch ? Ça ne m'est jamais arrivé pourtant… Après c'est vrai que des fois il faut lire la page d'accueil du site de arch et faire ce qui est écrit, en effet ça ne marche pas toujours tout seul.
[^] # Re: Perf Nagios/Centreon et Shinken
Posté par paulez (site web personnel) . En réponse au message Supervision: je ne sais lequel choisir. Évalué à 1.
2 x 8 Gio. Ce qui prenait le plus de place était le scheduler et les brokers (livestatus et webui).
Le temps de redémarrage était de plus de cinq minutes, avec une indisponibilité totale de la supervision pendant ce laps de temps.
Avec Nagios ça prend bien moins de temps, surtout que dans un archi distribuée je peux redémarrer uniquement le serveur qui le nécessite, et ça va donc beaucoup plus vite, et sans interférer sur le reste.
Pour info j'ai environ une minute de temps de redémarrage sur un server Nagios avec 30k services, et moins de 10s pour un serveur avec environ 5k services, donc c'est tout de même beaucoup mieux.
[^] # Re: Perf Nagios/Centreon et Shinken
Posté par paulez (site web personnel) . En réponse au message Supervision: je ne sais lequel choisir. Évalué à 2.
C'est une architecture distribuée à base de NDOMOD (archi distribuée standard Centreon).
Elle est distribuée d'abord pour des besoins de localisation (plusieurs datacenters) et aussi de performance (nous montons jusqu'à 25K services sur un serveur Nagios physique, on doit pouvoir faire plus mais il faut mettre un peu les mains dans le cambouis).
Un autre type d'architecture distribuée peut être d'avoir un seul serveur Nagios, et rajouter avec mod_gearman des "workers" autant que nécessaire.
Tu peux aussi découper la conf sur plusieurs serveurs et tous les visualiser avec une interface qui le supporte comme Thruk.
Et Nagios 4 qui devrait arriver un jour supportera nativement le principe de workers (comme avec Shinken ou mod_gearman).
Tu as donc de multiples possibilités, il ne te reste plus qu'à choisir ;-)
# Perf Nagios/Centreon et Shinken
Posté par paulez (site web personnel) . En réponse au message Supervision: je ne sais lequel choisir. Évalué à 3.
On fait tourner du Nagios/Centreon avec 50k services et 50 utilisateurs simultanés, tu as de la marge donc ;-)
J'ai testé Shinken sur un environnement avec 24k services, j'ai eu pas mal de problèmes de perf (conso mémoire et temps de redémarrage). C'était il y a 10 mois donc les choses ont du évoluer depuis mais je ne suis pas super enthousiaste quand même.