freem a écrit 5059 commentaires

Sauf si le chiffrement s'est fait avec une clé avec passphrase. Mais pas très pratique pour un serveur. D'ailleurs je doute qu'on puisse indiquer la passphrase au lancement d'un serveur sur OVH…

Si, justement, c'était une des raisons qui m'ont persuadé de faire ça :) jouer avec l'initrd, améliorer ma compréhension du système. Désolé, j'y suis accroc, le LL me donne la possibilité de comprendre comment marche mon système, en automatiser les trucs chiants, simplifier le compliqué, adapter l'outil au côté humain qu'il me reste, et ça, moi, j'aime.

Je vais être honnête, je l'ai fait uniquement sur conseil d'une personne (certes, sans expérience pro a ma connaissance) qui a été formée pour ça (être admin), et ses arguments m'ont pas semblé stupides, même s'ils m'ont pas frappé par la pertinence.
Mais, ajoutes à ça le fait de faire un truc que je savais pas faire, et de l'automatiser… ça a titillé mes instincts.

Aussi, je fait de savoir le faire sur un serveur (vps, au pire les mecs ont accès à la ram… et je compte juste y stocker du libre, t'façon…) implique que je saurais le faire sur des machines plus critiques, si besoin est.

Je suis intéressé, si tu as un nom. S'il me faut apprendre, je le ferais, de toute façon, l'air de rien, je l'ai fait ici.

Fatiguant ce bashing ovh

J'ai jamais remarqué de bashing OVH particulier, tu veux dire qu'il y pas que moi?

C'est surtout de ta faute : si tu n'indiques pas de clé ssh dans ton profil

Tu as donc raté ceci:

Je suppose que ce mode laxiste est pour éviter de surcharger la hotline, mais j'aurais aimé avoir l'option d'un truc un peu plus sécurisé, comme on a sur les forges logicielles: la possibilité d'envoyer une clé publique, et qu'il ne soit possible de le logguer que par elle si elle a été envoyée. Si ça existe, j'ai pas trouvé. Bref.

Auquel tu réponds ensuite. Je t'en remercie, d'ailleurs. Je reste quand même surpris des liens morts comme celui-ci qui sont inclus dans le mail. Nope, même pas un 404, juste une page neutre.
Aussi, sache qu'il m'a semblé obligatoire de renseigner certaines infos, type @physique. Me suis dis que c'était pour aider la sécurité…

Bref, je dois encore regardé ce cheminement, oui, mais de manière générale, c'est même pas clair qu'il est possible de le faire. La sécu, c'est pour les initiés?

Les dépôts sont ceux d'OVH, pour plusieurs raisons :

Ça, en vrai, je comprend un point: la bande passante.

ils sont sur leur lan, ça va donc plus vite à installer (et pas de bande passante à payer pour eux vers l’extérieur)

Mais pour ça, il est possible d'utiliser un proxy. Bon, pour être honnête, c'est juste un point en plus sur le reste, hein. J'aurai du le mettre en 1er, en théorie, vue que c'est le point le plus faible: après tout, un utilisateur peut vérifier les signatures.
Il s'agit du point que tu mentionnes aussi. Pour le kernel, j'ai un doute, et pour les installs d'outils de monitoring, c'est avéré, ils en ajoutent, sur l'install par défaut. Mais je n'ai pas vu d'indice évident pour expliquer ce qu'ils font. Bon, je doute qu'ils aillent pourrir leurs propres perfs quand même.

Mais

Ma foi, s'ils avaient vraiment voulu être lours, ils auraient remplacés les paquets de debootstrap, et j'aurais été bien emmerdé.

Pour le reste, peut être que l'offre VPS n'est pas ce qu'il te faut pour ton besoin. Je ne sais plus pour les VPS, mais je sais qu'en prenant un serveur physique (j'en gère des dizaines), tu partitionnes comme tu veux avant l'installation de l'OS.

En gros, je considère juste avoir enfin assez de «connaissances» a partager pour utiliser une machine dans un DC, et je compte aussi y héberger du code public. Même y coller un blog, si le coeur m'en dit. Rien qui ne mérite un dédié, pour moi.

J'aimerais bien un retour d'expérience pour les VPS chez d'autres hébergeurs, voir si c'est aussi "compliqué" de partitionner et de chiffrer…

Je suis preneur aussi. Après, tu sembles rôdé, hors, comme je ne crois pas l'avoir caché, mon retour est celui, à chaud, d'un dev (pas d'un admin, donc, donc pas forcément habitué à utiliser des machines des autres: sur mes machines, je suis dieu, je fais la pluie et le beau temps, la, c'était différent) qui s'y essaie, et essaie de faire les choses pas trop mal.

Mais, je reconnaît avoir été trop loin sur certains points.

NB: voila pourquoi j'apprécie ce site, y'a toujours quelqu'un pour me montrer mes erreurs. Je le pense sérieusement.

Le prix semble pas être le même.

Finalement, les problèmes arrivent plus vite avec plusieurs partitions.

C'est vrai et faux. Dans mon cas, je pense être un utilisateur, disons, avancé, et je pense savoir quel espace maxi prendrons certaines partitions.
Et, quand je me trompe sur une machine (ça m'est arrivé, une fois, j'avais rempli /var/cache/apt-cacher ou un truc du genre, j'ai été au plus rapide), ben je suis capable de contourner le problème, avec ou sans LVM.
Avec LVM, en vrai, je saurais pas comment faire.
Sans LVM, c'est «facile», il suffit de créer un fichier d'une certaine taille, par exemple avec dd, de le formater en ext4 ou autre, et de lui coller un point de montage. C'est sale, je sais, mais ça marche.
Depuis que ça m'est arrivé, cela dis, je garde systématiquement un espace non alloué sur mes disques qui dépassent les 80 Gio (presque tous). C'est p'tet du gâchis, mais le jour ou y'a besoin pour une raison X ou Y d'une nouvelle partoche, utilisable par n'importe quel système, c'est agréable d'avoir un p'tit espace de 2+Gio a dispo (moins de 5% du disque, et ça diminue avec la capacité du disque).

D'un autre côté, tu as dis «Alors attention, je parle dans le cas d'un serveur géré par un admin.».
Je suis pas admin, j'ai pas les compétences, et pas la vision nécessaire pour ça. Je suis un dev, qui s'est improvisé admin pendant plus de deux ans, parce que le seul a savoir (vaguement, au début, pas beaucoup mieux maintenant) comment marchent les réseaux et systèmes.
Mon recul reste faible, et ira pas plus loin concernant cette boîte, mais mes réglages ont permis d'avoir un dual boot sur des systèmes «embarqués» (~200, sans accès physique, par radio… j'ai appris beaucoup), et l'espace disque (8Gio max, 4Gio sur une majorité du parc, je sais, j'ai joué dans le grand luxe, d'où les «») n'a jamais été un problème, malgré l'usage d'outils pas adaptés (pour diverses raisons).
En théorie, ce dual boot si on poussait les racines que j'ai mises, permettrait un fallback automatique sur système sain si une MàJ merde. Ironiquement, le mécanisme est implémenté que sur les beaglebone black, Das-UBoot étant moins pire que UEFI quand il s'agit de trouver des infos: au moins, y'a le source!

Bref, pour moi, pas besoin d'être admin. Ou du moins, pas de métier… p'tet qu'il suffit d'avoir plus de 30 ans? Se souvenir d'une époque ou il existait des disques durs de moins de 20Gio, ou l'on faisait régulièrement du propre dans les données obsolètes? Je ne sais pas.

C'est /tmp qui était plein.

Et /tmp étais sur le disque réel, pas un tmpfs?

Bref, je ne suis pas assez calé en git côté serveur pour savoir si on ne peut pas mettre en place, justement, un hook quelconque en cas de commit.

La solution moche, ça serais un script de ce goût la:

REPO="${1:?"need the repo as param 1"}"
while true
do
  inotifywait -r $REPO
  whatever()
done

mais je soupçonne git d'avoir un hook dédié, ce qui serais nettement plus propre et performant, par exemple .git/hooks/pre-receive, mais je ne suis pas sûr de mon coup.

@toi et @gabbros:

ah, ok, certes, si on joue avec ça, forcément… bien vu de vous deux.

et pourquoi ne pas poster la solution? Si quelqu'un d'autre se pose la question, ça pourrais lui être utile, a moins que seul toi ai le droit d'avoir des réponses sur le net?

Désolé, je suis acerbe, mais le net est un résau pour partager le savoir à la base, pas pour partager le fait d'arriver a faire un truc.

Note: je t'ai pas moinssé, je trouve ça dommage de moinsser sans explications

Je pige pas la complexité sur les dates, le 1er exemple…

Si on pars du principe d'une date aux formats dd/mm/yyyy, dd-mm-yyyy ou dd.mm.yyyy (copié du lien, hein) je vois pas pourquoi il faut faire:

(?:(?:31(\/|-|\.)(?:0?[13578]|1[02]))\1|(?:(?:29|30)(\/|-|\.)(?:0?[1,3-9]|1[0-2])\2))(?:(?:1[6-9]|[2-9]\d)?\d{2})$|^(?:29(\/|-|\.)0?2\3(?:(?:(?:1[6-9]|[2-9]\d)?(?:0[48]|[2468][048]|[13579][26])|(?:(?:16|[2468][048]|[3579][26])00))))$|^(?:0?[1-9]|1\d|2[0-8])(\/|-|\.)(?:(?:0?[1-9])|(?:1[0-2]))\4(?:(?:1[6-9]|[2-9]\d)?\d{2})

que j'arrive pas a lire…

En quoi [0-9]([0-9])?[/.-][0-9]([0-9])?[/.-][0-9]{4} ça marcherais pas? Pas super lisible, mais, il file juste des regex sans explications, la…

Je sais qu'il est tard, mais bon…

Donc finalement, est-ce encore de la Science ? (question ouverte qui n'appelle pas de réponse :-))

(Méthode scientifique est pompeux et ne réfère à pas grand chose de bien définie : voir toute la philosophie des sciences ;-))

Pour le coup, ce que j'imagine être la méthode scientifique c'est, en gros, observer un certain nombre de cause et de résultats, essayer de déduire la règle, puis prouver qu'elle est relativement juste avec un jeu d'expériences, preuve qui doit être validée par d'autres.
Mes propos restent vagues, c'est normal, c'est pas mon domaine. Par contre, je trouve pas ça si pompeux que ça.

Pour être explicite, le compilateur peut introduire une backdoor à la compilation.

Mais il faut bien partir d'un binaire exécutable, parce que sinon, on doit se fier a un humain au niveau de l'intention et de la qualité (faut bien le construire, le 1er compilo). Dans le cas des compilateurs, c'est déjà le cas, mais on peut tester avec un certain nombre d'implémentations les résultats, plus ou moins, via fuzzing.
C'est pas idéal, mais ça me semble la seule solution avec un vrai potentiel de confiance. Et sur ce point, l'absence de standardisation de l'ABI du C et du C++ seraient, ironiquement, une force, alors que ça cause tant de problèmes de portabilité…

Enfin moi cela ne me dérange pas d'utiliser GHC parce qu'Haskell c'est chouette

Voila, la, je te rejoins :)
Bon, pas sur l'haskell parce que je connaît pas, mais je rejoins le fait qu'on doive faire l'équilibre entre la confiance et le sympa. Perso, un de mes arguments pour le C ou le C++, c'est que, justement, on a plusieurs implémentations, et je pense que pouvoir tester un code sur toutes ces implémentations est une force dont peu de langages «sûrs» peuvent se targuer (hein, rust?).
Je joue le conservatisme sur ce point.

Traduction libre d'une réponse Alan Cox :-)
L'ingénierie ne requiert pas de science. La science aide beaucoup mais les gens construisait des mûrs en brique parfaitement bien bien avant qu'ils sachent pourquoi le ciment fonctionne.

Magnifique. Merci, même si, pour moi, l'ingénierie est un peu une science de la pratique: on a observé que telle combinaison marche dans certaines situations, mais une autre est meilleure. On sait pas pourquoi, certes. Du coup, un mélange de science, d'expérience et d'intuition?

Bref, la question que vous posez sort du cadre de Guix et de LinuxFr et prendrait un peu plus qu'un commentaire pour y répondre. Êtes-vous dispo pour une bière ? ;-)

Ça m'amuserais énormément d'améliorer mes opinions lors d'une rencontre physique.

Pour moi RPM c'est Red hat Package Manager et APT c'est Advanced Package Tools. Donc mes excuses si c'est un raccourci mais je voulais dire RPM pour toute l'infrastructure RedHat (et consort), un peu comme je pourrais aussi dire APT pour tout l'écosystème Debian.

Justement, je pense que les étiquettes officielles sont foireuses, quand on ouvres un peu les boîtes. Par exemple, Debian dispose de plusieurs outils pour gérer packages et dépôts: apt, apt-get, aptitude, dselect, synaptics… leur point commun? L'outil qui installe le paquet dans le système. Et cet outil, c'est dpkg. Pour moi, c'est lui, le vrai gestionnaire de paquets, mais j'aime le low level, j'aime avoir la maîtrise de mes systèmes, je suis probablement pas dans la norme.

Abus de langage.

Qui est commun et difficile a ne pas faire, je pense. Ou peut-être que je n'ai pas la même définition, c'est un problème récurrent…

Mais on ne manipule jamais un fichier .nar manuellement.

C'est aussi ce qu'on dit d'un fichier .deb, mais moi, dans la pratique, tant a titre perso que professionnel, ça m'arrive chaque semaine.
La raison principale, c'est que l'environnement officiel de debian est trop complexe. Par contre le format est bien documenté, et facile a implémenter de façon très automatique en shell, si on se contente d'un jeu de fonctionnalités (en gros: ne pas utiliser pré/post rm/inst, dont le résultat final est trop complexe pour mon esprit simple).
Ah, quand j'évalue un logiciel, je tends a… lire le code et les formats. Pour que, si un jour un problème surviens, je puisse le patcher. Parce que c'est bien beau d'avoir le droit, encore faut-il avoir les compétences pour. Hors, un deb, je pourrais l'ouvrir avec un éditeur hexa, si besoin est. C'est une qualité non négligeable pour moi.

Parce que le soft (le kernel est un soft) sous linux ne permets pas cette hypothèse. Et Nix/Guix l'affirment a chaque fois comme forte.
J'aime pas ça, c''est pas honnête.

Qu'est-ce qui n'est pas honnête ?

Le fait de garantir un truc que même les manpages disent que ce n'est pas garantit. À savoir, que sur les FS de linux, il semble être impossible de garantir qu'un autre process n'écrit pas en même temps sur le même fichier, parce que les verrous sont juste informatifs, si un process ne veux pas les respecter, il peut ne pas le faire.

J'espère que vous prendrez le temps de tester Guix parce que notre discussion là est beaucoup plus large de ce qu'apporte le gestionnaire de paquets Guix comparé à ce qui existe (avec Debian par exemple). Et je ne voudrais pas qu'avec cette déviation, certes intéressante, vous ayez une fausse impression de ce que Guix fait/est.

Pas de soucis, j'ai bien conscience de ce que peux ou non un gestionnaire de paquet. Je pense depuis longtemps que l'approche de Nix/Guix est intéressante, sinon je n'aurais pas pris la peine de répondre.

Hélas, les TODOlist des geeks ont tendance a s'allonger plus vite qu'autre chose, mais, honnêtement, il me suffirais de pas grand chose, genre, un outil qui permets de naviguer et manipuler les paquets installés (idéalement en ncurses), pour que j'adopte. Parce que pour moi, les forces de Debian, c'est 1) sa stabilité, et 2) aptitude.

Problème facile à résoudre: A certifie que B est conforme pour x€, et en même temps B certifie que A est conforme pour x€. Bon, si il faut mettre vraiment beaucoup, il faut potentiellement faire un emprunt, mais vu que les transactions se font au même moment, il ne dure que l'espace de quelques heures (le temps que les banques bossent), les intérêts ne devraient pas monter trop haut.

Blague à part, je pense que l'on considère que tout ce qui est rare est cher, et je soupçonne que les boîtes qui sont dignes de confiance pour ce genre de choses sont rares, donc leur aval est cher. Je n'ai pas d'opinion sur ce sujet précis par contre (enfin, si, mais à l'emporte pièce, pas très pertinente): pas assez d'expérience pour m'en forger une.

Ceux qui supportent pas la souris, ils utilisent pas i3, qui implémente le support des fenêtres flottantes, mais un truc plus adapté a leurs envies, genre… ratpoison.

D'ailleurs, si c'étais le cas, i3blocks aurais jamais été codé, un de ses avantages principaux étant de supporter la souris sur la barre de statut.

Et plus il y a d'utilisateurs plus c'est pentesté.

Par des chapeaux blancs ou des noirs? Dans le cas des blancs, les correctifs arrivent-ils réellement rapidement? Sur quelles distro?
Et plus la base de code est grosse, plus il y a de choses à tester, plus le fuzzing prendra du temps. Plus, aussi, il est difficile d'envoyer un patch.

Après sudo a énormément de fonctionnalités

D'ailleurs, si quelqu'un pouvait m'expliquer pourquoi il fait une requête DNS sur le hostname (que contourne Debian en ajoutant 127.0.1.1 dans /etc/hosts) ça m'intéresse, parce que perso, j'ai bien du mal a voir l'intérêt de cette… fonctionnalité.

Bonnes remarques.

n'était-ce pas plus pertinent de coder un truc pour passer la chanson sur un mot clé énoncé verbalement?

Bof. Mon bricolage me permets de savoir si la musique que j'écoute est celle qui viens de mpd ou d'un onglet en arrière-plan (le "bouton" pause/play, même si ça a ses limites) et c'est utilisable au bureau, contrairement à des commandes vocales.

Je dis-ça je dis rien moi quand je lis un article j'ai de toute façon tendance à avoir le clavier dans les mains pour scroller et accéder rapidement au pageup/pagedown. L'article tient rarement sur un seul écran.

Perso, la molette me suffit. Et mon navigateur me permets nativement d'utiliser juste la souris (sans avoir a aller chercher un bouton ou menu quelconque, j'entend, hein… sinon ils le font tous, j'imagine…) pour un tas de trucs. Du coup, en «mode lecture», le clavier est plus une gêne qu'autre chose.
Le seul truc que je regrette, c'est le fait qu'il faille choisir entre le buffer sélection de X11 et le «scroll mode» que j'utilisais quand j'étais sous windows, ça, j'avoue, ça me manque. Me semble qu'Opera 12 (et moins) permettais de config ça, mais bon… J'imagine que je pourrais créer un mouvement de souris pour le remplacer…

Sympa, cet outil.

Il est presque utilisable pour les bases de données APT/DPKG/APTITUDE en plus, il faut 'juste' virer tous les dash ('-') et ajouter un nom de champ pour les entrées multi-lignes, par exemple:

cp /var/lib/dpkg/status /tmp/test
sed /tmp/test -i -e 's!^ .*$!Description:&!g' -e  's!^\([^:-]*\)-\([^:]*\)!\1\2!g'
recsel -i -e 'Package = "apt"' -P Version test

me sors 1.4.9 sur cette machine. Bon, c'est un peu plus lent que dpkg-query -W apt (en moyenne sur 4 essais: 0.16s avec system a 99% pour recsel, contre 0.01s avec system à 76% pour dpkg, selon time) et moins fiable (la modif pour le multi-ligne casse des trucs en vrai), mais peut s'avérer utile pour du post-mortem ou autre usages.

Merci du partage du coup (ça me servira pas sur apt, mais ça m'a permis de voir l'usage sur une DB déjà bien fournie).

Et cette même page fait remonter le terme à bien plus ancien:

The terms upcycling and downcycling were first used in print in an article in SalvoNEWS by Thornton Kay quoting Reiner Pilz and published in 1994

Ce qui nous fait du 26 ans. Si ça a été fait pour un OS MS, ça doit être windows 3.1 :)

Tu veux dire que ce liens va faire un flop?

tout est dans le titre

Mais même si je ne suis qu’un « ingénieur » (non diplômé), j’ai du mal à voir l’intérêt au delà de la satisfaction personnelle.

Perso, je me considère plus comme un gêneur qu'un ingénieur, dans le sens ou j'empêche au mieux de mes capacités les gens qui me payent de faire de la merde. Et j'y mets toute mon ingéniosité, croyez-moi.

C'est quoi, déjà, l'expression… «l'enfer est pavé de bonnes intentions», c'est ça? Oui, c'est vieillot, comme quoi, on n'invente pas tant de choses que ça :)

ce clavier est usb…

En Pré-Scriptum: j'ai pas suivi les liens, je vais le faire, ça semble super intéressant. Je ne fais que réagir à tes arguments ici, qui sont intéressants.

L'intérêt est double:

sécurité

pardon, on m'a appris a considérer le mot sécurité comme un buzzword, quand il est tout seul.

Ça protège de quoi, et dans quelles limitations?

science computationnelle reproductible

Arf… pardonnes donc le pauvre auto-didacte que je suis du manque de connaissances théorique…. mais je renifle ici quand même… euh, pour être poli, 3 mots mis ensembles pour impressionner la galerie. Désolé si c'est crû. En fait, non, pas tant désolé que ça, ce coin du web reste un coin ou je peux m'exprimer et apprendre sans faussetés.

C'est le cas d'usage le plus courant. Mais il faut garder en tête :

Que vous n'avez aucune garantie que le compilateur n'a pas introduit de code frauduleux. C'est ce que l'on appelle la Trusting Trust attaque et le problème du bootstrapp.

Je le sais, je suis un nerd comme les autres. Enfin, p'tet moins doué, certes.

Mais, oui, on sait, tu peux être espionné dès lors que tu confies ton hard a un autre. On sait, même le CPU peut leak… ça fait que 2 ans qu'on a des preuves, certes.
Mais, y'a un moment, soit on fait abstinence, soit on reste un minimum optimiste, non? A noter que, j'ai lu 1984.

Cela permet de ré-écrire partiellement la recette d'une paquet.

Tu parles de science. Je te parle d'ingénierie. C'est p'tet la qu'on se comprend pas, je suis pas assez intelligent pour la science, mais je reste captivé par l'idée de supprimer toute contrainte inutile a l'humain. Il parait aussi que je suis pas idiot, mais, je connais pas de scientifique.
Bref, à quoi ça sert?

Je crois que RPM est capable de faire du transactionnel.

Atta… tu compares RPM, un format de fichier, avec APT, un exécutable et… nix, une distro?
Justement, parlons simples, parlons binaires, ça ressemble a quoi le format de nix?

Le fait d'être "fonctionnel" rend les transactions faciles à implémenter. Ou disons plus facile que dans les approches "classiques" de gestion de paquets.

Ah… le paradigme «silver bullet»… Java a essayé. Java a bien marché, mais n'a pas conquis le monde. Je vous souhaite le même succès.
Désolé, tu n'as pas fournis un seul fait réel, donc je me permets de faire de même, et, en bon dev c++, de troller le java :) (y'a des traditions que j'aime, c'est un peu le folklore de l'info).

Oui, c'est légitime comme question. Et à ma connaissance il n'y a pas encore vraiment de réponse par manque d'observation.

Bien. Ici, pas moyen de troller, on cause tech.

Par contre, j'ai un doute sur le "manque d'observation". Tu entends quoi? Si Nix est si robuste, faites donc du fuzzing. Il faut un stress root constant pour estimer le niveau de fragilité. Et même si vous avez des failles, hé, vous, au moins, vous permettez un certain parallélisme, et ça c'est un argument de vente pour moi. Parce que c'est fort, la vitesse.
Ou alors vous jouez la sécurité, le tout séquentiel, et alors votre paradigme, bah, il sers pas a grand chose.

Guix fait l'hypothèse (forte) qu'il y a suffisamment de stabilité dans le noyau, le système de fichiers, etc. pour ne pas influencer sur la transparence binaire. Mais oui il y a une question pertinente sur l'effet du hardware.

Tu vois, c'est justement par l'intermédiaire de Nix que j'ai appris cette faiblesse. Et de mon job. Je suis tellement curieux… j'ai cherché, j'ai voulu reproduire cette fiabilité supposée, et… j'ai trouvé que c'était de la poudre aux yeux.
Parce que le soft (le kernel est un soft) sous linux ne permets pas cette hypothèse. Et Nix/Guix l'affirment a chaque fois comme forte.
J'aime pas ça, c''est pas honnête.

Cependant, qui peut le plus peut le moins. ;-)

Pitié, non… Un dev sys ne seras jamais un bon dev web, un architecte ne sera jamais un bon maçon, et vice versa. Cette expression je la prend comme une forme de mépris. C'est désagréable, même si je sais que je l'ai moi aussi commise, cette erreur.
On peut avoir les notions des métiers adjacents, mais jamais on ne les fait aussi bien que des pros.

Je me permets de faire un petit résumé.

Merci pour ça

Il suffit de dire qu'on doit accepter et prendre conscience de ça, le fait que l'on doit faire confiance a un organe initial?