YvanM a écrit 54 commentaires

De ce que je comprends et imagine, la porte d'entrée privilégiée des virus est la messagerie, avec des arnaques de plus en plus élaborées :

• soit avec un virus en pièce jointe (ou un document avec macro)
• soit avec un lien pointant vers un virus

Notamment, je trouvais très instructif l'un des derniers rapports de l'ANSSI au chapitre 2.2.1.

La plupart du temps un utilisateur éduqué ne se fera pas avoir, mais un jour ou l'autre il finira par cliquer, ça me semble inévitable (et oui, ça m'est déjà arrivé malgré toutes mes précautions)… D'un autre côté je n'ai pas souvenir qu'il y ait déjà eu de "virus" ciblant les postes de travail Linux, donc ça reste vraiment une précaution en plus et peut-être inutile, d'où l'idée de choisir le plus intelligemment possible quels fichiers scanner.

Merci pour la piste, je vais tester (je n'aurais malheureusement pas le temps dans les prochains jours) et je vous tiendrai au courant.

Un antivirus sur les postes de travail Linux me paraît de plus en plus nécessaire.

J'ai essayé dernièrement de configurer ClamAV (l'antivirus libre pour ceux qui ne connaissent pas) sur des postes de travail. Ça me semble malheureusement impossible de trouver une configuration efficace et pas trop gourmande en ressources :

• par défaut il ne scanne les fichiers qu'à la demande, ce qui me semble insuffisant
• il est possible de configurer et utiliser l'utilitaire clamonacc fournit avec ClamAV, mais il scanne les fichiers à chaque ouverture, visiblement sans aucun cache : ça me semble un gaspillage de ressources absurde
• il est possible d'utiliser le système de fichiers FUSE clamfs, mais le fonctionnement ne me semble pas adapté pour du desktop : les fichiers doivent transiter par un répertoire spécial pour être scannés avant d'être déplacé dans le répertoire "normal", il faudrait donc forcer tous les téléchargements (Firefox, client de messagerie…) à passer par ce répertoire spécial. Du point de vue utilisateur ça me semble une vraie régression de ne plus pouvoir enregistrer un téléchargement directement où on le souhaite.

J'envisage deux solutions qui ne me semblent actuellement pas implémentées :
- le plus simple peut-être, une extension pour Firefox et Thunderbird qui scanne automatiquement tous les fichiers téléchargés / pièces jointes
- avoir une configuration de clamonacc pour scanner les fichiers à l'écriture seulement (pas à chaque lecture)

Je suis preneur de tous vos avis / retours d'expérience sur ce sujet !

Debian i386 ? Y a t'il une raison pour ne pas installer la version amd64, bien plus testée ?

Ça ne répond pas à tous les points soulevés plus haut (il n'est pas possible de prendre la main sur plusieurs ordinateurs en même temps, ça ne passe pas les pare-feu qui font de l'inspection profonde de paquet, mais j'ai justement publié une procédure pour se faire un client SSH + VNC.

En étant un peu malin et avec quelques bases de programmation / script shell / python, je suis sûr qu'il serait possible de l'améliorer pour le rendre compatible avec plusieurs assistances en parallèle.

le son et l'audio sont maintenant séparés sur deux pistes différentes dans la timeline

Ce ne serait pas plutôt le son et la vidéo ? Ou alors ce serait sympa d'expliquer :-)

Tu n'as du écraser que le début de ton disque en faisant ton dd, donc tout le reste doit être récupérable "en vrac" :
- utilise photorec pour tout récupérer en vrac
- trie tes fichiers par type et classe les photos par date en utilisant ce petit script python : https://github.com/tfrdidi/sort-PhotorecRecoveredFiles
- supprime les fichiers dont le type n'a pas été trouvé, à priori il ne te sont pas utiles
- met de côté les types de fichier dont tu penses qu'ils ne servent à rien
- supprime les doublons (un même fichier peut ressortir plusieurs fois) : rdfind -outputname doublons-recup -deleteduplicates true /fichiers/récupérés
- renomme les morceaux en MP3 en utilisant leurs métadonnées : for dir in ./MP3/*; do for file in "$dir"/*; do mp3rename "$file"; done; done (note que ça doit pouvoir s'adapter à d'autres formats)

C'est loin d'être idéal mais c'est déjà ça… L'avantage de ta situation :
- c'est que tu feras attention avant de faire un dd (si tu es sous Gnome, tu peux utiliser le logiciel
"Disque" pour faire tes clés, ça réduit les chances de se rater)
- c'est que ça te donnera envie de faire de meilleures sauvegardes :-)

Bon courage !

Sauf erreur de ma part, la partie serveur n'est pas libre.

C'est bien le problème : ne pas avoir à toucher à la box des personnes à aider.

Merci pour la documentation !

Effectivement on en revient à un système équivalent, peut-être un peu plus simplement. Mais les "grosses" étapes restent identiques :
- pondre un script avec Zenity/Yad pour que ce soit accessible à la personne aidée
- empaqueter ça dans un .deb (ou Flatpak / Snap / Appimage que sais-je encore) pour que ce soit installable facilement

Pour quelqu'un qui ne doit aider que des personnes sous Linux, ta solution semble la meilleure. Pour quelqu'un qui doit aider des gens sous Linux et Windows, la solution que je présente à le (petit) avantage d'être "similaire" pour ces deux OS.

Je viens d'aller vérifier, X2Go permet cela mais seulement si l'ordinateur de la personne à aider est accessible sur son port 22 (https://wiki.x2go.org/doku.php/doc:usage:desktop-sharing), donc c'est un autre cas d'usage.

SSH ne doit pas être bloqué par un pare-feu (le port d'écoute et configurable).

Du coup, impossible de proposer une solution qui marche "partout" comme Teamviewer, et c'est la où ça coince, car on ne peut dire génériquement "ben tu n'as qu'à prendre l'équivalent libre".
C'est ce qui a "tué" (disons ne pas faire décoller) pas mal de projets libres, à ne pas s'adapter aux contraintes des clients.

Effectivement, ça ne marche pas si la personne à aider se trouve derrière un pare-feu qui fait de l'inspection de paquet (donc de plus en plus d'entreprises), mais pour des particuliers et pas mal d'entreprise et d'associations pas de soucis. J'ai bien conscience que mon outil ne convient qu'à un cas d'usage spécifique. Peut-être que je devrais le préciser plus clairement dans la documentation ?

Je viens de clarifier les manques de cet outils au début du README, ça permet en effet d'éviter des déconvenues.

SSH ne doit pas être bloqué par un pare-feu (le port d'écoute et configurable).

Du coup, impossible de proposer une solution qui marche "partout" comme Teamviewer, et c'est la où ça coince, car on ne peut dire génériquement "ben tu n'as qu'à prendre l'équivalent libre".
C'est ce qui a "tué" (disons ne pas faire décoller) pas mal de projets libres, à ne pas s'adapter aux contraintes des clients.

Effectivement, ça ne marche pas si la personne à aider se trouve derrière un pare-feu qui fait de l'inspection de paquet (donc de plus en plus d'entreprises), mais pour des particuliers et pas mal d'entreprise et d'associations pas de soucis. J'ai bien conscience que mon outil ne convient qu'à un cas d'usage spécifique. Peut-être que je devrais le préciser plus clairement dans la documentation ?

C'est un début de quelque chose, reste à avoir une interface pour l'admin plutôt que créer en terminal les mot de passe, et tunneler SSH en HTTPS… Curieux de voir si il y a du monde intéressé par un équivalemment libre à Teamviewer (perso Teamviewer me va et pas près à développer un concurrent libre pour le moment, mais je trouverai ça positif comme projet de titiller Teamviewer la dessus comme Framadate a pu arriver au niveau de Doodle).

J'aurais vraiment aimé trouvé quelque chose de "tout fait" mais ce n'était pas le cas, j'ai fait au mieux avec les moyens dont je dispose (pas le niveau pour développer un vrai logiciel et pas d'argent pour payer un développeur). Je serai par contre prêt (comme pas mal de monde je pense) à poser quelques sous sur la table si un développeur proposait un projet crédible dans ce sens.

Je ne connaissais pas cette fonctionnalité de Jitsi (que je n'ai jamais testé) : est-il possible de contrôler l'ordinateur distant ou seulement de voir son écran ?

Bien que je ne pense pas qu'il ai été conçu au départ pour de la sauvegarde, mais plutôt pour le la « synchronisation de fichiers », je trouve FreeFileSync très pertinent et le recommande dès que possible :

• respecte tous tes critères:
• très bien maintenu et amélioré régulièrement
• peut conserver les fichiers supprimés et les anciennes versions
• utilisation de VSS (le système d'instantané de Windows, pour la sauvegarde des fichiers en cours d'utilisation)

Les moins :

• pas de dépôt public à ma connaissance, il faut télécharger l'archive contenant le code source…

Je n'avais pas bien compris que tu voulais : je n'ai jamais testé cette configuration, mais je partirais sur pam_mount si je devais le faire (peut-être que je me trompe, mais je pense qu'avec smbnetfs tu auras un débit réduit, comme avec gvfs).

Après ce que je ne sais pas si SMB et le serveur qui est derrière (Samba ou Windows) fournissent bien les fonctionnalités dont ton environnement de bureau et tes logiciels ont besoin (liens symboliques, permissions…). J'imagine qu'une bonne source d'information serait notamment cette page : https://wiki.samba.org/index.php/UNIX_Extensions

Tiens nous au courant !

Ça commence à dater un peu, mais la documentation que j'avais rédigée et dont j'avais fait la pub dans un journal est encore en grande partie d'actualité : https://unptitcoin.fr/data/t2t/prepa-Xub14.04/Prepa-Xubuntu-14.04.html

Je n'avais pas modifié le thème de Lightdm et il n'y avait pas besoin de taper le nom du domaine. La création du home sur la machine est automatique, le montage des répertoires réseau aussi (2 méthodes différentes). Bref, je pense que ça répond à tous tes critères.

Je t'encourage à préciser dans ce rapport de bug que tes postes sous Linux sont aussi affectés : il ne porte pour l'instant que sur les versions Windows.

J'avais eu un problème similaire : les documents de plusieurs pages étaient imprimé page par page, et non toutes les pages en même temps. Autant dire que sur des documents de 30 pages, très fréquents, les utilisateurs commençaient à s'arracher les cheveux et à vouloir ma peau…

Article très intéressant, un grand merci.

Je me permets de signaler que la commande btrfs balance start -dusage 30 -musage 30 s'écrit en fait btrfs balance start -dusage=30 -musage=30.

Après beaucoup de réflexion sur le sujet, je ne peux que plussoyer pour Lubuntu :

• l'intégration de LXDE est franchement bien :
  • il y a de quoi contrôler simplement la mise en veille et le verrouillage de l'ordinateur
  • l'apparence et les composants du "panneau" sont bien réfléchis
  • les raccourcis claviers sont bien retravaillés
• le gestionnaire de mise à jour d'Ubuntu est vraiment bien pour les débutants
• la logithèque est toujours ce qui se fait de plus accessible pour installer des logiciels (même si Gnome Software commence à arriver la rattraper)
• les firmwares non libres sont là par défaut (je ne suis pas pour dans l'absolu, mais les gens sont content que le WiFi et le Bluetooth marchent tout seul…)
• l'installation des pilotes graphiques non libres se fait au clic (même si sur de vieux ordinateurs le besoin est rare)
• résoudre des problèmes, où du moins comprendre leur cause, est souvent plus simple sous Ubuntu (les utilisateurs sont plus nombreux)
• Plymouth est déjà intégré (c'est un petit détail qui fait que ça semble "finit" pour les utilisateurs)

Les points faibles :

• le jeu d'icônes par défaut qui peut perturber l'utilisateur
• il manque quelques logiciels "de base" : LibreOffice, Thunderbird, VLC, gnome-screenshot (scrot n'est pas vraiment user-friendly), rhythmbox (pour ceux qui ont des iPod), gthumb (pour la retouche de base)
• il faut également installer libdvdcss pour les DVD chiffrés

Même si je n'aime pas particulièrement *Ubuntu (et je ne m'en sers pas personnellement), il manque toujours quelque chose chez la "concurrence" quand on se met dans la peau d'un grand débutant.

Edit : j'avais oublié de parler de la logithèque.

Je serais moi aussi très heureux de savoir où on peut acheter ce genre de matériel !

Le montage graphique des partages SMB se fait via GVFS.

Visiblement, il n'est pas possible de spécifier des options pour un montage en particulier.

Peut-être, mais je n'ai trouvé aucune documentation à ce propos, qu'il serait possible de créer un nouveau "schéma" de montage, en s'inspirant de /usr/share/gvfs/mounts/smb.mount (sous Debian), et en précisant les options souhaitées à l'exécutable qui est appelé :

$ /usr/lib/gvfs/gvfsd-smb -h
Utilisation : /usr/lib/gvfs/gvfsd-smb clé=valeur clé=valeur ...

Mais bon, à mon avis tu as bien meilleur temps de passer par la commande mount.cifs du paquet cifs-utils (toujours sous Debian). L'option vers= est celle qui t'intéresse ici.

L'administration propre d'un serveur LDAP étant déjà un gros travail, je ne peux que vous dire un grand merci pour ces outils !

Ah oui je suis passé à côté… Si j'arrive à publier une nouvelle version avec les corrections proposées, ce sera sous AGPL.

Merci pour l'intérêt ainsi que pour ces remarques très pertinentes.

Le PHP est mélangé au HTML généré, et les variables sont insérées par simple concaténation de chaînes de caractères. Sans même parler de faille XSS, cela signifie que si une imprimante ou une option a un nom qui contient le caractère " par exemple, tout l'affichage de la page est cassé. Je vous recommanderais d'utiliser un système de template, qui en plus régler ces problèmes, rendra le code plus lisible.

Je n'avais que vaguement connaissance de ce système de template… Je vais regarder ça comme il faut.

De même, le script lance des commandes sur la machine sans vérifier les arguments. Cela signifie que vous laissez n'importe quel invité exécuter n'importe quelle commande sur votre serveur.

Là je comprends moins : la majorité des arguments sont des listes à choix, les choix étant fournis par l'administrateur. Ils y a éventuellement des champs textes, mais les principaux (les seuls jamais utiles ?) sont contrôlés (le nombre de copie doit être un entier non négatif, la liste des pages à imprimer est vérifiée directement par la commande "lp"). Finalement, toutes les commandes lancées sont échappées avec "escapeshellarg()" : là effectivement vous avez raison (je viens de relire le manuel) cette fonction devrait être utilisée sur chaque argument individuellement.

Et le fichier de configuration est dans un langage inventé pour l'occasion, qui ressemble au json, mais n'est pas totalement compatible, à cause du système de commentaires. Je conseillerais l'utilisation d'un langage existant, comme YAML par exemple, qui supporte les commentaires.

Je n'ai ajouté le support des commentaires que tout à la fin, ils ne sont à mon avis que très rarement utiles (sauf à avoir 10 imprimantes disponibles). Je vais regarder du côté de YAML : quitte à faire de gros changements dans le code, c'est vrai que ça vaudrait le coup d'utiliser un format standard et peut-être plus évolutif.

Je vais essayer de trouver le temps de remettre ça au propre en suivant vos conseils. Encore merci d'avoir jeté un coup d'œil au code.