Bertrand Mathieu a écrit 126 commentaires

Il existe une solution qui consiste à combiner local + cloud. En clair, un petit NAS prêt à l'emploi à la maison, qui se débrouille tout seul pour se sauvegarder sur un ou plusieurs fournisseur de cloud (amazon, google, hubic, crashplan…). De ce que j'en connais, les nas synology peuvent faire tout ça, et simplement (interface web, bonne aide en ligne, zéro ligne de commande nécessaire), donc accessible à pas mal de monde à mon avis.

L'intérêt c'est que la sauvegarde est faite très vite en réseau local, et ensuite le NAS prendra tout le temps nécessaire pour se sauvegarder sur un service sur internet, ce qui retire le problème de la sauvegarde qui ne finit jamais parce qu'on doit éteindre et/ou emmener l'ordinateur portable.

L'UUID dans fstab c'est génial bien, mais attention avec LVM!

J'ai eu une mauvaise surprise en jouant avec la fonction snapshot (sur le home): il y a du coup 2 systèmes de fichiers avec le même UUID. Là où ça se corse, c'est quand le système monte l'un ou l'autre alternativement, y compris en sortant de veille (et oui, on peut écrire sur un snapshot). On peut modifier l'uuid du snapshot, mais dans ce cas il vaut mieux éviter de reverser celui-ci dans le LV d'origine (snapshot merge), puisqu'on perdra l'uuid d'origine.

Bref, tout ça pour dire que pour une partition LVM il est tout aussi simple et stable d'indiquer le chemin "/dev/mapper/Aurora_VG-Home" plutôt que l'uuid, ce chemin ne devrait pas changer sauf si on s'amuse à renommer le VG ou le LV. (il doit aussi exister un alias du genre "/dev/lvm/Aurora/Home")

Dans les montages amusants il aurait été possible d'ajouter le SSD au volume RAID 1, éventuellement retirer l'un des disques durs du RAID, et de déclarer le disque restant dans la raid "write-mostly", mais il n'aurait pas été possible d'étendre le fs (ou alors le raid ne sert plus à rien puisqu'il ne contient pas toutes les données).

Ils utilisent docker pour le développement alors que virtualenv est fait pour ça.

Faux et il n'y a pas à chercher bien loin: c'est juste documenté sur la page d'accueil du dépôt, et juste avant la section qui explique comment utiliser le projet avec docker, ce qui laisse supposer que docker est une méthode alternative de leur point de vue.

https://github.com/pagekite/Mailpile#developing-using-virtualenv

Pour faire ce que tu décris on ne part pas d'un dump fait par pg_dump, car c'est une simple photo de la base (pg_dump a plusieurs formats de sortie, dont 1 en insertions SQL, mais ils sont tous équivalents).

Pour rejouer des WAL, il faut partir d'une copie des fichiers de la base de données (l'état binaire), et seuls les WAL émis après peuvent être pris en compte. Jusqu'à présent pour avoir une copie de la base il fallait:
* émettre une requête "pg_start_backup": le serveur commence à accumuler les WAL sans toucher aux fichiers de la base
* copier tous les fichiers
* émettre pg_stop_backup

Depuis la version 9 il y a un outil qui s'appelle pg_basebackup qui simplifie la procédure en faisant toutes ces opérations uniquement avec le protocol de postgres, et éventuellement depuis un serveur distant (donc pas besoin de paramétrer en plus un accès ssh pour la copies des fichiers).

Il n'y a pas 36 solutions si on veut un backup avec PITR: il faut faire un pg_basebackup régulier (1/semaine? 1/jour? ça dépend des cas) et archiver les WAL à côté, mais il faudra toujours de la place disponible. En case de restauration à l'instant t, il faut créer une base à partir du backup précédent t, et rejouer les WALs jusqu'à cet instant. Plus les backup sont réguliers, moins il y a de WAL à rejouer.

Sinon, c'est forcément un dump, avec l'avantage de pouvoir choisir quelle "database" voire quelles tables sont à restaurer. On peut combiner les 2 approches pour se créer un dump d'une database particulière à un instant "t". Ça nécessite quand même d'avoir la capacité monter la base de production: gros serveur, ou autre serveur.

Pour faire plus finement et moins "lourd", il faut connaître et comprendre les données stockées, et donc que ce soit l'application (donc le développeur) gère ça.

Enfin la "streaming réplication" depuis 9.1 ça marche bien et à part le cas 1 maître pour écrire et des esclaves pour lire cela permet de maintenir un serveur prêt à l'emploi pour devenir maître en moins d'1s. Depuis la 9.2 un esclave peut se répliquer à partir d'un autre esclave.

Pour ces problèmes de support hébergeur et de disques assemblés en raid, c'est plus simple lorsque le raid est géré par une carte plutôt que par logiciel.

le disque est déclaré défaillant? avec le raid soft, tu as les ennuis que tu viens de connaître pour que le support trouve un problème, puis lorsque le disque est remplacé il faut que tu t'occupes de recréer les partitions (généralement swap, root, home) puis de les réassembler avec mdadm, ce qui implique d'y passer un peu de temps à chercher la bonne manipulation lorsqu'on n'a pas l'habitude. Dans l'intervalle de temps tu ne fonctionnes que sur un disque.

Avec le raid "hard", généralement le support peut voir directement sur la carte que le disque est rejeté (et pour peu que la carte ait une interface réseau il n'y a même pas prise en main du serveur, donc pas de coupure), le disque peut même être retiré sans extinction du serveur, et dès que le nouveau disque est en place la carte reconstruit le raid.

Après chez ovh il faut payer plus cher pour ça (option "utilisation pro" + option "raid hard"), et chez online dès 40€ HT les serveurs sont équipés.

Au niveau serveur il y a Zentyal (anciennement ebox), qui propose une interface web pour gérer un serveur passerelle, comptes utilisateurs, vpns, et j'en passe. La prochaine version sort bientôt, basée sur Ubuntu 12.04. Simple, efficace, et quand même assez puissant.

Mais ça ne résout pas le problème côté configuration des postes clients :-/

A propos, ça existe l'auth centralisée sous linux (ldap par exemple) qui permet le "roaming"? (pour les utilisateur de portables qui ne sont pas toujours connectés sur le même réseau que le serveur ldap)

Justement, pour les .deb par exemple les derniers paquets disponibles dans debian sid sont pour la version 0.6.5, idem pour ubuntu. On ne trouve pas la version 1.0.x, même en ppa.

C'est dommage, car c'est un frein à l'adoption AMA.
L'installation par script, c'est bien pour tester sur une machine, mais pour la production il faut avoir une raison impérieuse pour ne pas passer par un paquet; à moins de tout installer en tant qu'utilisateur simple dans un seul répertoire, éventuellement.

Ça faisait belle lurette que google ne s'occupait plus de picasa sous linux (3.0beta, alors que 3.8 sous windows).

Comme c'était effectivement un package wine+picasa, une solution était de mettre à jour la version installée par le package en 3.8. A part la géolocalisation intégrée avec google maps qui plantait le soft, ça marchait.

Là google vient mettre à jour en version 3.9. Le problème? Ça devait faire au moins 2 ans qu'il n'avaient pas touché picasa, et là la plus grosse nouveauté c'est "google+" avec la possibilité de tagger avec les noms de comptes google+. Alors le support de picasa, quel que soit l'OS, ça fait surtout penser à un truc pas loin de l'abandonware.

Il me semble que l'intérêt de feedburner est surtout pour l'auteur: cela lui permet de suivre les stats de consultation par RSS de ses articles et donc d'avoir une meilleure idée de l'audience.

Je ne crois pas que les flux disparaissent au profit de FB et twitter: l'intérêt de ces 2 derniers est surtout de pouvoir générer et fidéliser du trafic, c.à.d avoir de nouveaux lecteurs qui reviennent par la suite.

ça fait un peu plus de 5 mois maintenant.

Par contre je donne rarement mon numéro de téléphone fixe: en premier lieu, il est vrai, parce que je ne le connais pas par coeur (comme pas mal de monde de nos jours); mais aussi parce que ça doit bien aider à éviter le spam, quand même.

Je confirme: j'ai été abonné 1 an et demi à SFR adsl (notamment en espérant avoir la fibre dans l'année, vu que le quartier était en cours de pose, mais c'est même pas arrivé à mon immeuble finalement), même désagréments: beaucoup de sollicitations commerciales par téléphone (pas toujours directement SFR en plus) et ce malgré une inscription en liste orange dès la mise à disposition du numéro; un peu à toutes heures (disons entre 7h30 et 21h30), y compris le samedi. J'aurais résilié plus tôt si je n'avais pas eu à attendre la nouvelle freebox!

Je suis revenu chez free: plus rien.

Et après on peut évoquer le problème de la distribution: la taille des paquets augmenterait sensiblement, et à ce niveau on peut estimer que la bande-passante est encore un problème, au moins côté serveur. Avec les médiums physiques il faudrait passer au DVD pour une installation minimum (et encore?!) et au Blueray pour installation standard.

(à propos de bande-passante, il n'y avait pas un projet d'apt-torrent? plus il y a de monde mieux ça marche!)

C'est ça qui donne ce ressenti d'une "arnaque": toute marque créé à partir d'octobre 2011 ne pourra plus s'offrir cette mise en liste noire. Inversement, si une marque disparaît il n'y a plus de raisons de conserver le nom en liste noire, non? Ça ne semble pas prévu pourtant.

Ces derniers mois j'ai eu entre les mains 2 cartons d'ordinateur portable de marque "Toshiba" scellé avec un autocollant rouge titré «Quality Seal» et stipulant:

«Remarque Importante: TOSHIBA Corporation (TOSHIBA) et/ou ses filiales vendent actuellement des ordinateurs portables disposant en standard d'un système d'exploitation Microsoft en tant que solution informatique. Quel que soit le contenu de la documentation accompagnant votre ordinateur TOSHIBA et/ou ses filiales n'acceptent pas le retour des composants ou des logiciels intégrés qui auraient été retirés du système informatique. Tout remboursement au pro-rata de composants ou de logiciels intégrés, ce qui inclu le système d'exploitation, ne sera pas accordé.»

Après les constructeurs ont de plus en plus souvent un système de mise à jour du BIOS qui ne fonctionne que sous windows, ce qui incite à garder windows dans un coin (alors qu'il est techniquement possible et relativement simple d'avoir ça directement dans le BIOS et de lire la mise à jour sur une clé USB par exemple).

D'ailleurs - je digresse - est-ce que le passage aux bios EFI va limiter la nécessité de mettre à jour le bios? (il me semble qu'avec EFI le BIOS en fait le moins possible pour laisser la main le plus tôt possible à l'OS?)

Je pense que certaines entreprises ayant des exigences importantes en terme de sécurité et de confidentialité y voient un intérêt (pensons par exemple aux accès conditionnés à une habilitation confidentiel défense, mais cela s'élargit à tous les risques d'espionnage industriel). Dans ce cas il faut le voir comme un journal (log) d'activité, permettant par exemple d'aider à rechercher l'origine d'une fuite d'information.

Certes les intervenants (personnels, prestataires) sont engagés contractuellement. Mais si ça suffisait, ça se saurait! ;-)

Proxmox fonctionne avec openVZ mais également KVM (et très bien même), et Proxmox 1.6 propose le noyau 2.6.32: c'est pas si ancien que ça je trouve.

A part ça, on y trouve trouve une interface d'administration web, et un mode de fonctionnement en grappe permettant de migrer une VM d'une machine à une autre.

L'interface web permet de lancer une console graphique distante en applet java. Java si y a vraiment pas le choix mais on peut aussi s'en sortir un peu mieux avec les commandes standard de kvm + netcat pour avoir un flux vnc ("nc -l -p 5900 -s 127.0.0.1 -c "qm vncproxy id_vm vnc_password"; et une redirection ssh du port 5900).

Généralement, une fois la VM installée on installe immédiatement ssh ou autre accès réseau direct, donc plus besoin de ce genre d'acrobaties.


En tout cas c'est une très bonne solution serveur à mes yeux.

Je pense que le but est de faire un serveur très graphique pour les admin-clic-clic

Si tu regardes bien tout est administré via un navigateur, donc à distance. L'interface physique se résume à un serveur X avec firefox ouvert sur l'interface d'administration (mais ça n'empêche pas la ligne de commande).

Pour Ubuntu contre Debian, je n'ai jamais fait de mise à jour de serveur Ubuntu d'une LTS à la suivante. Quels sont les problèmes que vous promettez qu'on ne rencontrerait pas en utilisant Debian stable? (je précise que je ne suis pas développeur sur Zentyal)

Enfin j'utilise Zentyal (enfin... actuellement ebox 1.2) au boulot depuis quelques temps pour gérer la répartition du traffic entre 3 box ADSL, et c'est vraiment simple! Pour l'instant c'est que ce j'utiliserais sans hésiter pour monter un nouveau petit réseau d'entreprise.

ssh permet de faire à peu près ce que tu veux je crois. Il faut ajouter quelque paramètre devant la clé publique dans le fichier authorized_keys.

Les paramètres intéressants entre autres (man ssh pour les avoir toutes ;-))
command="command"
environment="NAME=value"
from="pattern-list"
no-pty

"command" va déclencher l'utilisation de cette commande lors de la connexion ssh. Notamment dans l'environnement il y a SSH_ORIGINAL_COMMAND, donc lorsque tu fais:

"ssh user@machine_distante ma_commande"

tu peux tout à fait faire que la machine distante exécutera toujours:

"sudo -u utilisateur_restreint ma_commande"

avec un sudo bien réglé.

Tu peux mettre ton petit programme aussi, comme ça ça lui évitera de tourner en root mais uniquement lors de la connexion et avec l'identité "finale". A charge de ce programme de vérifier si tel utilisateur peut exécuter ce programme, à la rigueur.

Voilà un lien où cette solution est évoquée: https://linuxfr.org/comments/1014767.html#1014767


En tous cas tu peux faire en sorte que l'utilisateur n'aie aucun shell à sa disposition, voire pas de pty, c'est un cas prévu par ssh.

Dans la doc ils détaillent comment utiliser une autre méthode, dite de "preseeding" (j'ai pas la traduction sous la main):
[https://help.ubuntu.com/10.04/installation-guide/i386/automa(...)]

=> dans le premier paragraphe, renvoi vers l'appendice B, "Automating the installation using preseeding"

Cette méthode semble pouvoir aller plus loin que Kickstart, dans la mesure où elle est proche du système de gestion des paquets.

J'ai pu constater l'efficacité du téléchargement avec bittorrent lors des nouvelles releases Ubuntu. Dans les jours suivant la sortie, aucun FTP n'est en mesure d'envoyer les données au maximum de ta bande passante (BP) en réception. Avec bittorrent le téléchargement est effectué au maximum de ta BP: il y a un maximum de pairs .

Mieux: au boulot on a 3 box ADSL derrière un routeur (au passage: machine installée avec eBox, excellent). Avec FTP/HTTP, la connexion ne passe que par une seule box. Avec bittorrent, toutes les box sont exploitées: chaque pair représente une connexion différente. Là où 1 lien ADSL permet de recevoir au maximum à 1,5Mo/s, bittorrent permet d'exploiter les 3 box, 1 CD est téléchargé en quelques minutes à peine :-)

Le reste du temps il n'y a pas de grande différence (dommage que les miroirs FTP ne servent pas également de pairs bittorrent!).

Il y a un truc que je trouve très bien fait dans trac, c'est la navigation dans le code source du dépot SVN (historique, diff, etc).
Avec Redmine j'ai beaucoup plus de mal à voir rapidement ce qui m'intéresse (fichiers concernés par un commit dont je suis en train d'examiner un diff sur l'un d'eux, par exemple; mais mon Redmine n'est peut-être pas assez à jour).

Avec PACKT Publishing les PDFs sont verrouillés par mot de passe (et marqués avec l'email de l'acheteur), et ça se lit très bien sous linux (avec Evince par exemple). Nulle DRM et autres amusements, et en bonus les bouts de codes peuvent être copiés-collés sans problèmes.

J'attend avec impatience de recevoir ce livre, mais en comparaison avec PACKT la version électronique est décevante: si on veut du PDF il faut le faire à travers l'interface du site de l'éditeur (y a un bouton dédié), et uniquement sous-chapitre par sous-chapitre. Faut vraiment le vouloir, en somme.

C'est vraiment dommage, car le gros intérêt d'avoir un PDF sur son PC de travail est justement d'avoir un accès permanent à la référence, avec recherche dans le texte et tout.

J'ai trouvé une réponse à un intérêt d'avoir le snapshot au niveau de btrfs (il se trouve que je cherchais des infos sur la fonction snapshot merge de LVM dispo depuis linux 2.6.33, c.à.d depuis pas longtemps; ça permet de faire, entre autres, un "rollback" de toutes les écritures par exemple, ou inversement de tester qq chose dans un snapshot, et si c'est ok alors on peut tout balancer dans le volume principal).

Voir http://linux-attitude.fr/post/snapshot-temporaires notamment le dernier paragraphe:

«Enfin n'oubliez pas une chose, les snapshot lvm ne fonctionnent qu'au niveau block device, c'est-à-dire en dessous du système de fichiers. C'est comme si vous enleviez le disque sans éteindre la machine, il se peut que le système de fichier ne soit pas au mieux de sa forme au moment ou vous le lancez, ayez au moins un système journalisé pour éviter les surprises et jouez du sync pour un peu plus de garanties.»

De ce point de vue on peut s'attendre à ce que btrfs gère bien l'intégrité du FS en cas de "rollback", en tout cas mieux que LVM non?

Il me semble que pour faire un snapshot d'un volume LVM, il faut pouvoir allouer un autre volume LVM dédié à cela.
Si jamais ton volume de snapshot sature (parce que tu n'as pas prévu assez de place), tu perd le snapshot.
Si ton disque n'a plus de place dispo pour allouer un volume (parce que tu n'avais pas pensé à ça avant), tu ne pourras pas faire de snapshot, à moins de passer par une réduction de ton volume existant, et donc probablement une réduction du FS installé dessus. Si jamais tu l'avais formaté avec xfs, tu ne pourras pas le faire (les outils xfs ne savent pas réduire le FS).

Or avec btrfs j'ai plutôt l'impression que tu n'as pas besoin d'avoir pensé à tout ça: le snapshot est créé à l'intérieur du FS, et non dans une autre partition/volume LVM/etc.

Cela dit, LVM conserve un intérêt au moins pour sa capacité à augmenter ou diminuer la place disponible pour le FS.

(j'admet également que ma connaissance des ces trucs n'est pas parfaite, loin de là; mais m'étant déjà intéressé au sujet, voilà ce que j'en avais retenu ;-))

http://en.wikipedia.org/wiki/Btrfs#Subvolumes_and_snapshotsBtrfs

Coïncidence! en lisant ton journal je repense à une histoire lue hier, histoire qui n'est plus toute récente mais le moins qu'on puisse dire c'est qu'ils ne se sont pas découragés!

http://www.justpasha.org/folk/rm.html