LaBienPensanceMaTuer a écrit 1611 commentaires

Que certains jeunes choississent "Youtubeur" devant "Musicien" ou "Athlète de haut niveau" me parait suffisant en fait …

1. N'oublie pas que le débit communiqué est le débit "théorique", atteint sous certaines conditions uniquement. Dans la réalité, il est rare d'atteindre ce débit.

2. Ton test introduit déjà des biais: tu écris via dd un fichier sur un filesystem. Tu amènes donc déjà un facteur limitant dans ton test: les performances de ton filesystem.

3. Tu as choisis de travailler avec une taille de bloc de 1Mo pour ton dd: es tu sûr que cette taille de bloc est optimale ?

4. Si ton CPU monte à 90% d'utilisation, le goulot d'étranglement est peut être plus du côté de ce dernier que du côté du SSD (et la gestion du FS n'y est probablement pas étrangère).

Au final, après une recherche google rapide, les débits que tu annonces semblent similaire à ceux constatés lors d'un benchmark effectué par un site spécialisé.

Si tu veux réellement faire un test de performance pure, je te conseille de:

• Travailler directement sur une partition ou sur le disque entier, sans filesystem entre deux: dd if=/dev/zero of=/dev/sdX

• Faire varier les tailles de bloc (bs=XX).

Si tu as l'occasion de faire ces tests, je serai curieux d'avoir tes résultats !

Pourrais tu tenter de te retourner contre l'éditeur de l'application ?
Ne serait-ce que pour voir la réponse qu'on t'apporterait …

Autre petite précision/correction:

De mon point de vue, le bootloader s'apparente plus à Grub qu'au BIOS puisque c'est bien le bootloader qui va démarrer le noyau Linux.

Le rôle du BIOS est, quant à lui, plus assuré par le DTB (Device Tree Blob) qui, comme stipulé dans l'article, renseigne au kernel le mapping hardware du device.

Mais sur plateforme ARM, j'avoue que les deux rôles sont de plus en plus difficile à distinguer :)

Gnome est un environnement de bureau, pas une distribution.
Cependant, vu le numéro de version que tu donnes, je pense que ta distribution est une ubuntu.

Généralement, "migrer" d'une distribution vers une autre ne marche pas, sauf rares exceptions entrainant généralement des galères…
De plus, ta distribution source (Ubutun 16.04) est relativement ancienne, ce qui ne va rien arranger.

Je te recommande plutôt de faire une installation "from scratch" en ayant au préalable sauvegardé ton répértoire utilisateur (/home/TON_USERNAME).

Ou comment un outil qui était sensé nous offrir des possibilités de communication illimitées (internet) a amené toute une société à se tourner vers son nombril et à ne plus communiquer que par selfies interposés.

Y a des jours ou je me dis que je suis quand même bien content d'avoir eu 16 ans à l'époque des modems 56k… époque ou télécharger un MP3 prenait 30 minutes et ou on payait internet à l'heure.
Peut être que si j'avais eu 16 ans aujourd'hui, je n'aurai jamais téléchargé tout ces fanzines de hacking (NoWay, NoRoute, Phrack, le site de Ouah…), ces mêmes fanzines qui m'ont mis des étoiles dans les yeux et m'ont entrainé dans la spirale des systèmes libres et de la quête avide et insatiable de savoir !

Ta remarque est assez intéressante…
Il y a probablement du vrai (et c'est dommage vu le prix d'un expert Linux sur le marché actuellement) mais de ce coup … quelles sont les technos qui attirent les djeunz geek ?

Le dev oueb avec NodeJS, Angular & co ? Le dev mobile ?

Hey, vous, les 15-25 qui fréquentez le site, vous pourriez nous donner un peu de feedback ?

Lol :-)
Le problème n'est pas tant l'administration que le contenu …

Perso, j'ai l'impression que "c'était mieux avant", mais c'est peut être mon côté vieux c*n qui parle…

Plus sérieusement, j'ai l'impression que les gens qui sont actuellement dans la tranche d'age 18-25 n'utilisent pas internet comme nous: ils vont davantage se tourner vers Facebook, Twitter, Youtube, etc… plutôt que sur les bons vieux forums comme LinuxFR.

Moi je trouve ça plutôt intéressant au final…

Je fais partie des trentenaires (même si je suis plus près des 40 que des 30), et je me demande comment évolue la population de ce site, dans quelle mesure on a un apport de jeunes passionnés.
Ce sondage a en partie répondu à mes interrogations ;-)

Maintenant, je dois me mettre aux clients IMAP et SMTP, mais je ne suis pas sûr de la meilleure façon de faire : dois-je utiliser un client dans mon code, ou utiliser un service externe ? J'ai vu par exemple qu'il existe un daemon SMTP, mais je ne suis pas sûr qu'il soit fait pour être utilisé par un client mail. Pareil pour un daemon IMAP. Dans tous les cas, je n'ai pas trouvé beaucoup d'informations sur eux.

Euh … Je crois qu'avant de voir coder un client mail, il serait bon de mieux maitriser le sujet ;-)
Je veux pas être méchant hein … mais si tu te poses la question d'intégrer un "daemon SMTP", c'est qu'il y a quelques lacunes qui risque d'être bloquantes…

Pour t'aider dans tes recherches, regarde un peu les différences entre MTA (Mail Transport Agent), MDA (Mail Delivery Agent), MUA (Mail User Agent).

Dans les grandes lignes, le daemon est le service en écoute côté serveur… c'est le service qui va répondre au requête quand ton client va s'y connecter.

Le protocole SMTP est en charge de traiter les mails entrants. (donc, sur le serveur smtp.TON_FAI.fr, c'est lui qui va recevoir tout les mails avec @TON_FAI.fr).

Les protocoles POP3 et IMAP servent quant à eux à récupérer tes emails (c'est le protocole que quelqu'un qui a un @TON_FAI.fr pour récupérer ses emails via imap.TON_FAI.fr).

De façons plus générale, un client mail a, grosso modo, 2 façons de récupérer les emails:

• Si il tourne sur la machine ou le daemon tourne (cas de plus en plus rare), alors il peut aller directement piocher dans la mbox ou le maildir rempli par le daemon.

• Si il tourne sur une machine différente du serveur, alors il doit utiliser soit le protocole POP3, soit le protocole IMAP, soit une variante chiffrée de ces deux là.

De la même façon, un client a 2 façons d'envoyer un mail:

• Si il tourne sur la machine ou un daemon SMTP tourne, il peut faire un appel à l'executable "sendmail" qui va pousser le mail au daemon (bien souvent via un socket Unix).

• Sinon, il doit utiliser le service SMTP exposé par le serveur (typiquement, stmp.TON_FAI.fr) ou sa variante chiffrée (SMTP avec TLS ou SMTPS)

De ce coup, si tu ne veux pas ré-inventer la roue, il faudrait trouver une lib qui implémente la partie "client" des protocoles IMAP, POP3 et SMTP.
Tu peux toujours implémenter à la main hein … SMTP et POP3 sont des protocoles très simples.
IMAP est un poil plus pénible…

Après faut voir ce qui t'intéresse …
Si tu veux mieux maitriser les protocoles de messagerie, alors potasse les RFC des 3 protocoles cités plus haut et implémente les from scratch.
Si le but est plutôt de gagner en compétence sur la programmation graphique sous Linux, alors trouve toi une lib toute faites.

De plus s'ils utilisent D-Bus, j'ai peur que ce soit compliqué à utiliser (pas du tout utilisateur-amical).

Euh un daemon qui utilies D-Bus… es tu bien sûr ?
Sinon, D-Bus risque d'être le passage obligatoire pour intégrer correctement ton client au gestionnaire de desktop: les notifications sont généralement véhiculées via D-Bus.

Comment feriez-vous ? Que me conseillez-vous ?

Comme dit plus haut, du but que tu poursuis en t'étant lancé dans ce projet.

Ce que je te conseille ? De mieux te documenter sur le MTA, MDA, MUA, POP3, SMTP, IMAP.

Arf en effet ….
Bon après, je pense que la population visée par l'extension de Raphj est suffisament compétente pour récupérer une clef d'API et la renseigner dans une éventuelle page de configuration de l'extension …
Mais j'avoue, c'est pénible.

Ton journal a piqué ma curiosité.

De ce coup, j'ai cherché un peu, et je suis tombé la dessus:

https://www.digital.sncf.com/startup/api

Ca ne semble malheureusement pas offrir la possibilité de réserver directement un billet, mais tu pourras déjà récupérer aisément tout les informations liés au horaires, gares & co.

Peut être un moyen plus efficace de connaitre l'ID du train que tu veux réserver et de "sauter" directement vers la page de reservation…

En sus, tu as aussi une autre API orienté "big data": https://data.sncf.com/explore/?sort=modified

Probablement intéressant, mais pas sûr que ça aie une utilité pour le but que tu poursuis.

A la lecture de la page de man d'ucf, j'ai l'impression que l'outil questionne l'utilisateur pour savoir ce qu'il doit faire.

Si il le fait systématiquement, à priori tu seras notifié lors de ton upgrade du changement de fichier de config.

J'y ai également lu que ucf pouvait créer des ucf-new ou ucf-old pour les fichiers modifiés.

De ce coup, vu que, comme tu le dis, c'est géré dans les scripts de postinst je ne vois qu'une issue: le find bourrin … :-(

Pour une raison qui m'échappe, la coloration syntaxique a totalement f*cké le bout de shell:

• Un {mathjax} s'est glissé là … à supprimer.
• Des backquotes (`) se sont également glissés là … à supprimer également.

dpkg stocke tout les "meta-fichiers" liés au package dans /var/lib/dpkg/info.

C'est à cet endroit que tu vas retrouver:

• Les fichiers .postinst, .preinst, .postrm, .prerm qui sont les scripts executés lors des étapes du même nom

• Les fichiers .md5sums contenant les sommes MD5 des fichiers.

• Les fichiers .list qui contiennent la liste des fichiers installés par le package.

• Les fichiers .shlibs servant à configurer le loader (lib partagées embarquées par le paquet).

• Et et et … les fichiers .conffiles qui contiennent les fichiers configuration gérés par les paquets.

Donc grosso modo, le petit bout de shell suivant devrait te permettre de traquer les fichiers qui t'intéressent:

for file in *.conffiles; do 
   cat ${file} | while read conffile; do 
     [ -f ${conffile}.dpkg-dist ] && echo "${conffile}.dpkg-dist exists ";
   done
done

Là, je t'ai donné des pistes pour présenter sur internet des services hébergés par la machine qui fera tourner le client VPN.
L'unique chose à faire dans ce contexte est de t'assurer que les services que tu souhaites exposer soient également en écoute sur l'interface montée par OpenVPN (généralement, ça marche tout seul quand le service est configuré pour écouter sur INADDR_ANY/0.0.0.0.

Si, outre ces services, tu dois exposer d'autres services sur d'autres machines de ton LAN domestique, il y a probablement un peu de boulot supplémentaire.

Pour revenir sur la chaine FORWARD, iptables est composée de plusieurs tables elles même consistant en plusieurs chaines.

La table la plus connue, celle utilisée par défaut si on omet le -t <table> est la table filter qui te permet de dire "ce port la je le ferme, celui la je l'ouvre que pour tel IP source", etc…
Cette table contient, par défaut, les chaines INPUT (paquets entrants à destination de la machine), OUTPUT (paquets sortants de ta machine) et FORWARD (paquets pour lesquels ta machine n'est qu'un intermédiaire, ex: une GW internet).

La table nat, qui régie les altérations de paquets (donc les redirections/translations) contient quant à elle les chaines PREROUTING (décision préalable au routage des paquets), POSTROUTING (décision après que le routage des paquets aie été actés) et égalementINPUT et ̀ OUTPUT(même contexte que pour la tablefilter`).

Là, je t'ai donné des commandes permettant d'ajouter des règles dans la table nat.
Cependant, ce n'est pas parce qu'une règle de translation existe dans la table nat qu'elle est automatiquement autorisé côté filter.
C'est dans la chaine forward de la table filter que tu vas ensuite devoir autoriser les flux en question.

J'ai cependant dit que y toucher était hypothétique car, sur une config "stock", la policy (décision par défaut) de la table FORWARD est bien souvent ACCEPT.
Si toutefois, sur ta machine, elle est en policy DROP il te faudra autoriser explicitement les flux que tu auras configuré dans ta table nat.

Je t'invite à lire une introduction à iptables qui te permettra d'avoir les idées plus claires à ce sujet.

Lol … Hopital, charité, toussa … Qui a dégainé ses "20 ans d'expérience" comme si c'était quelque chose de sans appel qui devait forcer respect ?

En effet, j'ai 16 ans d'XP pro. Mais ça fait 20 ans que j'utilise exclusivement Linux… Et je ne pense pas qu'on doive passer sous silence 4 ans ou 90% de mon temps libre a été consacré à apprendre à dompter ce système, à développer dessus, à y déployer des services, etc… sous pretexte que je n'étais pas payé.

Pour finir, vues les inepties que tu sors, je pense qu'avant même d'entrer dans la vie pro, j'avais déjà un meilleur niveau que toi en Linux aujourd'hui …

C'est de la news de qualité !!!

J'ai un peu délaissé Perl ces dernières années au profit de Python, ça m'a donné envie de m'y remettre un peu :)

Pas besoin de reverse proxy.
Suffit de poser les bonnes règles de NAT avec iptables.
En admettant que:
1/ Ton VPN soit en 192.168.10.0/24
2/ l'IP VPN de ta machine soit 192.168.10.100
3/ L'ip publique de ton serveur est 1.2.3.4 et cette IP est sur eth0

Si tu veux rediriger le port 8000 vers le port 10000 de ta machine (tout en root):

iptables -t nat -A PREROUTING -i eth0 -d 1.2.3.4 -p tcp --dport 8000 -j DNAT --to 192.168.10.100:10000

Tu auras probablement quelques ajustements à faire sur la table FORWARD également.

Pour finir il faut également:
1/ activer le forwarding niveau noyau (voir sysctl).

2/ activer le masquerading pour éviter que les paquets réponses sortent avec l'IP du VPN: iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Attention cependant, contrairement à la solution à base de reverse proxy, ta machine va voir ses services directement exposés sur le net ce qui représente un potentiel risque de sécurité..

Note: j'ai écrit tout ça de tête, des erreurs peuvent s'être glissées…

Quelle idée de rafraichir les clefs depuis un serveur aussi ! ;-)
Plus sérieusement, ça va pourrir les recherches de nouvelles clefs, mais pour l'existant, je ne vois pas de menace.
De base, lors de l'importation depuis un serveur, les clefs sont considérées non-trustées.

Pourquoi sexisme ?

As tu essayé de déplacer ou supprimer le fichier listé dans le log ( /home/user/.var/app/org.signal.Signal/cache/.org.chromium.Chromium.ATF8wi) ?

Ah bein tiens, il s'avère que moi aussi j'ai 20 ans d'expérience… On fait quoi de ce coup ? On compare nos CV, nos b*tes, la taille de nos barbes ???

Par contre, cet argument ("ça fait 20 ans que je fais ça comme ça") est tout aussi sans valeur que les autres fournis: rien ne t'empêche de faire n'imp pendant 20 ans hein !

Maintenant, si tu lis le moindre bouquin d'initiation à Linux, qu'il date d'aujourd'hui ou d'il y a 20 ans, tu y liras toujours le même conseil: faites des partoches séparées, à minima pour le /home…
Il me semble même que, à l'époque, l'installeur de Debian 2.2 faisait, par défaut, une installation avec des partitions séparées…

Mais bon, je vais arrêter de perdre mon temps … tes 20 ans d'expérience semblent t'avoir donné une confiance en tes compétences qui te rend totalement hermetique à la remise en cause.
Continue de faire comme tu veux, et tu repenseras à moi le jour ou tu te louperas sur un de tes bidouillage à coup de fdisk.

Tu cherches à montrer que tu as raisons sans chercher à comprendre ce que j'écris. Oui, on peut découper en n partitions, et vu que le resize est pris en compte par ext4, LVM ne t'apporte rien de plus la dessus.

Je comprend parfaitement ce que tu écris.
C'est juste du mauvais bricolage qui n'est acceptable que parce que tu as une install dégueu.

Croire que mettre un "/home" dans une partition aide pour un migration, c'est se mettre le doigt dans l’œil jusqu'au coude.

Des vrais arguments ?

Tu es de toute façon censé avoir tout sauvegardé

Merci pour l'info … j'étais un peu courant.

et si tu garde /home tel quel il faut ensuite s'amuser à vérifier toutes les .config et autres, de tous les logiciels pour voir si les versions sont les mêmes ou compatibles, bref, tu te traines un tas de boue d'upgrade en upgrade.

C'est ça ton argument ? C'est nul.
Mon home contient actuellement:
* 75GiB de musique.
* 10GiB de photos.
* 66GiB de sources, recipes Yocto pour le boulot.

Donc si je suis ton raisonnement, pour quelques malheureux fichiers (que je peux inhiber en faisant un mkdir old-config && mv .* old_config/) de config, je dois me repalucher la copie de 150GiB de stuff ?
Si t'as du temps à perdre, tant mieux pour toi.
D'autant qu'il est rare d'avoir une rupture de compatibilité telle que tu l'écris.
En pas loin de 10 piges à utiliser awesome comme gestionnaire de fenêtre, j'ai du réécrire 1 fois la config lors du passage de 3.x vers 4.x …
Mon .muttrc doit me suivre aussi depuis environ 10 ans …
A ma connaissance, firefox migre sa config tout seul…
Non, cet argument est sans fondement, désolé.

De plus, il faut ensuite faire correspondre les uid et gid sous peine de futur gros problème.

Encore un faux problème/argument bidon:

• Le premier user créer est toujours le mien. Sous ma Debian, il prend toujours l'UID 1000.
• Au pire, si l'UID change, alors un chown -R <nouvel UID>:<nouveau GID> ~/ et c'est fini.

"/var" séparé pour une machine perso, j'ai du mal à voir l’intérêt. soit, c'est trop petit et c'est chiant, soit c'est gros, et de l'espace est gâché.

Merci de me donner un argument supplémentaire pour faire la promo de LVM…

Je me répond, car j'ai dit quelque chose d'erroné: si j'en crois cette doc dans les sources du kernel, l'hibernation est possible via un fichier de swap …. grâce à une petite feinte.

Il s'agit de préciser, outre le resume=/dev/sdx un resume_offset qui permet au kernel de savoir exactement ou aller chercher sans pour autant avoir besoin de monter le filesystem, parser le fstab, etc…

Le détail de la procédure est décrit dans cette seconde doc.