Bernez a écrit 1089 commentaires

un peu moins la partie avec les --tcp-flags (c'est ma lecture du moment, tout lire sur ce qui suis ce paramètre).

Le pare-feu iptables est conçu d'une façon telle qu'il faut d'abord apprendre TCP/IP avant de réussir à l'utiliser. Tu t'y prends à l'envers à lire la doc d'iptables avant de la doc généraliste sur TCP/IP.

j'ai passé des heures et des heures à tester chaque règle jusqu'à ce que firefox, transmission etc. fonctionne, avec le nombre de ligne minimal

Encore une fois c'est une approche qui me semble bien plus laborieuse que de commencer par lire un peu de doc sur TCP/IP et les grands principes d'iptables.

Où se trouve les erreurs dans ce qui suis ?

Difficile de faire un retour cohérent tellement tes règles partent dans tous les sens. Voici juste des commentaires sur quelques unes d'entre elles :
iptables -A INPUT -p tcp --tcp-flags ALL ALL -j DROP
Avec ça tu bloques tout le trafic TCP.

̀iptables -A FORWARD -m state --state INVALID -j DROP
La chaîne FORWARD ne sert à rien sur une machine qui ne fait pas routeur.

iptables -A OUTPUT -m state --state ESTABLISHED -j ACCEPT
De l'ESTABLISHED dans la chaîne OUTPUT n'a pas trop de sens.

iptables -A INPUT -p icmp -j DROP
Mauvaise idée de bloquer tout l'ICMP comme ça. Non seulement tu empêches l'utilisation de ping, mais en plus tu bloques des messages utiles de routeurs (style host unreachable).

̀ # SSH
iptables -A INPUT -p tcp --dport 666 -j DROP`
Le protocole SSH utilise le port 22 (par défaut).

Sinon, comme dit par Gérald, ce n'est pas très utile de bloquer des paquets dans OUTPUT.

Il faut aussi avoir conscience qu'un pare-feu ne sert à peu près à rien sur un ordinateur de particulier derrière une box qui fait du NAT.

Mais une fois ce contact établi, le serveur te renvoie un autre numéro de port aléatoire pour que la communication réelle puisse se faire, sans bloquer un autre utilisateur voulant accéder à la même page web, qui se retrouverait à attendre que tu veuilles bien libérer le port 80.

Absolument pas. Les ports utilisés tout le temps de la connexion ne changent pas. Les serveurs sont capables de gérer plusieurs connexions simultanées sur un même port, et encore heureux.

C'est là que le ESTABLISHED rentre en compte.

Non. En gros ESTABLISHED sert à autoriser les réponses aux initiations de connexion de la machine.

Ça va peut-être paraître dur, mais l'ensemble de règles que tu utilises n'a ni queue ni tête. On dirait que tu as fait des copier-coller de règles de droite et de gauche sans comprendre à quoi elles servent. Iptables n'est pas utilisable si on n'a pas un minimum de connaissance sur TCP/IP.
Si ton objectif est d'apprendre à utiliser iptables de façon autodidacte, je te conseille de commencer par acquérir les bases de TCP/IP. Ensuite il faut apprendre les grands principes d'iptables. Une fois que c'est fait, tu peux commencer à écrire toi-même des règles que tu comprends.

Le paquet linux-libc-dev (à moins qu'il porte un autre nom sur ta distribution) est-il installé ?

On peut exploiter le fait qu'en MySQL, les opérateurs booléens renvoient 0 ou 1 : YEAR(date) - (MONTH(date) < 9).

de nombreux salaires / revenus sont indexés automatiquement ([…] points des fonctionnaires

Depuis 8 ans, le point d'indice des fonctionnaires a augmenté de 1,2 %. On est très loin de l'inflation, et ça concerne du monde.

+1
J'utilise radicale pour un besoin tout à fait similaire à celui de ted. Je n'ai quasiment rien eu à configurer. Les calendriers sont stockés dans des fichiers texte (icalendar).

Si de base il n'y a pas les options pour utiliser les identifiant, il te faudra surement éditer le PPD. Pour cela va voir ici: Printer Job Options for User Accounts il semble y avoir une solution.

Il y a malheureusement des photocopieuses Sharp pour lesquelles ce n'est pas si simple. Pour opérer l'authentification, leurs drivers utilisent comme filtre un binaire disponible uniquement pour windows et osx. Cependant un libriste a fait du reverse engineering sur le protocole utilisé, et a développé une solution pour Linux : https://benjamin.sipsolutions.net/Projects/sharp-cups/. À essayer.

Loyalty Card Keychain pour stocker et afficher des cartes de fidélité (ou d'autres cartes basées sur des codes à barre ou matriciels, par exemple ma carte de bibliothèque)

Merci de m'avoir fait découvrir ce logiciel. J'aime beaucoup le concept. En pratique, ça marche bien ? Tu ne te heurtes jamais à un refus d'utiliser ça plutôt que la carte d'origine ?

J'ai un serveur Debian sur lequel la récupération de session par xrdp fonctionne très bien en utilisant une session Xorg. Je n'ai quasiment pas touché à la configuration par défaut. Dans xrdp.ini j'ai laissé la session Xorg telle quelle :

[Xorg]
name=Xorg
lib=libxup.so
username=ask
password=ask
ip=127.0.0.1
port=-1
code=20

J'ai juste mis ça dans /etc/X11/Xwrapper.config :

allowed_users=anybody

(Cf. explications dans le README.Debian du paquet xrdp.)

Franchement, à cette échelle-là, utiliser un vrai système de liste de diffusion me paraît indispensable. Peut-être peux-tu utiliser Framalistes ?

Comme l'a dit Axone, il y a Okular. Sinon tu peux aussi essayer celui intégré dans Firefox.

Tu as essayé de faire le copier coller depuis un autre logiciel que Evince ?

Ce script doit tourner avec Python 3. Lance-le comme ça : "python3 mozlz4a.py -d search.json.mozlz4 search.json". T'auras ensuite ton fichier décompressé dans search.json. Tu le modifies, puis tu recompresses en appelant le script sans le "-d" et en inversant les deux autres arguments.

J'ai comparé le contenu des 2 fichiers PDFs et les différences se trouvent dans une zone de 128 octets au tout début (de 0x0c0 à 0x140) Je ne sais pas comment interpréter les PDF mais je suppose que cette zone contient une palette de couleur.

Le site de shattered fournit une illustration pour l'expliquer :

La fonctionnalité de copie dans le répertoire d'envoi avec Gmail doit venir d'une configuration spécifique du serveur SMTP de Google, qui fonctionne en lien avec l'identité d'un expéditeur authentifié.

Hors de ce contexte, la solution est effectivement d'envoyer le mail avec un programme faisant office de client IMAP. Il existe plusieurs logiciels permettant de faire ça (chercher "imap sync" dans le logiciel de gestion de paquets de sa distribution), ainsi que des modules pour tous les langages de programmation qui se respectent.
À ta place, je configurerais mon MTA (serveur SMTP) pour appeler automatiquement un tel programme ou script pour envoyer le message en IMAP en même temps qu'il envoie le mail par SMTP au destinataire. Même si ton hébergement ne te permet pas d'éditer le fichier de configuration global de ton MTA dans /etc, tu dois pouvoir spécifier un autre chemin de fichier de configuration en ligne de commande. Au pire, tu remplaces ton appel au MTA par un script shell qui fait à la fois un appel au client IMAP et au MTA.

Pour donner une réponse plus précise, il faudrait savoir quels programmes et quel MTA tu peux ou veux utiliser.

Personnellement je préfère avoir la dernière version majeure de l'application plutôt qu'une version plus ancienne patchée au fur et à mesure.

Le problème c'est qu'il existe tout un tas d'entreprises (et même de geeks adeptes de l'autohébergement) qui sont utilisatrices d'applications web, mais dont le développement web n'est pas la cœur de métier et qui préfèrent avoir une version stable et sécurisée plutôt qu'une version « au summum de la modernité ».

on a pas forcément envie de voir tous les scripts sous /usr/share appartenant à root. Si une faille est exploitée avec une injection de code les dégâts risquent d'être beaucoup plus importants que si l’application est dans son propre dossier, les scripts appartenant à un utilisateur spécifique avec des droits limités au strict nécessaire.

Même quand elles sont empaquetées par les distributions, les applications web sont exécutées par l'intérmédiaire d'un serveur web qui tourne sous un utilisateur dédié (qui n'est pas forcément le même entre toutes les applications web). Le fait que les fichiers soient stockés dans un sous-répertoire de /usr/share et appartiennent au root ne diminue pas la sécurité.

Je ne vois aucun avantage à avoir des paquets pour des applications Web ou des CMS.

Ça a le même intérêt que pour toute application : installation facile et standardisée, mises à jour de sécurité gérées par la distribution. L'intérêt est même supérieur à la moyenne vu que les applications web sont particulièrement affectées par les problèmes de sécurité.

De plus ces applications s'installent systématiquement dans /var/www/html et placent souvent des fichiers de configuration dans /etc/default et autres, ce qui ne correspond pas forcément aux choix de l'administrateur système.

Ces applications s'installent là ou le mainteneur l'a décidé, ce qui est correspond donc précisément au choix de l'administrateur système (puisque l'administrateur a choisi sa distribution, et que tout le principe d'une distribution est d'avoir une politique cohérente d'administration système).

D'autant que Nextcloud, par exemple, propose maintenant son propre système de mise à jour fonctionnel.

Cette mode d'avoir un système de mise à jour par logiciel finit par devenir pénible. Toutes les entreprises (sans parler des particuliers) ne peuvent pas se permettre de payer des armées d'informaticiens à passer leur vie à tenir à jour tous les logiciels utilisés.

L'utilisateur www-data a-t-il bien les droits en lecture sur le répertoire /var/www/dezert ? (et sur index.html)

Autre idée : as-tu bien fait "a2ensite dezert ; service apache2 reload" après avoir créé ton fichier de configuration ?

La commande sync agit au niveau du système de fichiers, je ne suis pas certain qu'elle fonctionne aussi après un dd vers un raw device…

D'expérience, si, ça le fait. D'ailleurs la doc de sync dit "Synchronize cached writes to persistent storage". Je rejoins donc le conseil de Marc Quinton, sauf que lancer la commande une seul fois suffit.

Une solution pourrait être de surveiller l'onduleur depuis un ordinateur qui démarre vite et consomme peu, genre un raspberry pi. Tu configures uniquement le raspberry pi pour se rallumer dès que le courant revient (avec un système en lecture seule pour limiter les risques de casse), tu surveilles la charge de l'onduleur depuis ce raspberry pi, puis quand elle est suffisante tu réveilles les autres appareils avec du wake-on-lan ou en pilotant – depuis le GPIO – leur alimentation électrique avec une carte relais. Comme ça tu peux utiliser un onduleur classique bon marché.

Et après, comment sont faite les API pour celle-ci par exemple?

As-tu regardé le lien que j'ai dans mon tout premier message ? À ta place je lirais les chapitres 1 à 3, puis le 4.4, puis commencerais à expérimenter en lisant le 4.3.

On peut aller plus loin, est-ce qu'il existe une API particulière pour EPSON ou autre marque sous Linux.
SANE si je ne me trompe pas c'est un driver generic.

Non. SANE est une ensemble de drivers pour tout un tas de marques de scanners (dont Epson), et surtout une interface permettant à des logiciels de communiquer de façon transparente et uniforme avec tout type de scanner.

Mon but est de faire tourner aussi le programme Qt sous windows et de pourquoi pas ajouter des fonctionnalitées comme celle qui existent déjà sous le logiciel Epson ayant pour cible windows.

A priori utiliser SANE sous windows est quasiment impossible. Tu ferais mieux d'utiliser TWAIN sous windows et de créer une couche d'abstraction pour interfacer ton programme avec les deux environnements (à moins qu'une telle bibliothèque de gestion multiplateforme de scanners n'existe déjà). Mais ça risque d'être un très gros boulot.

Installer QuiteInsane ne sert à rien. C'était juste un exemple de logiciel prouvant qu'il est possible d'interfacer Qt avec SANE. Mais ce logiciel est n'est visiblement plus maintenu et n'est pas utile en soi (même en tant qu'exemple, puisqu'il est obsolète).

Ce qu'il faut faire, c'est installer le paquet de ta distribution qui contient les fichiers de développement de libsane (un truc genre "libsane-dev"). L'API native de SANE est en C, qui ne devrait poser aucune difficulté à être utilisée dans un programme C++ Qt.

Dans la mesure où tu écris un programme en Qt et non juste un petit script shell, à mon avis tu ferais mieux d'utiliser directement l'API de SANE plutôt que lancer des processus externes et traiter leur sortie.

Pour compléter, il est normal que la plupart des fichiers de /etc soient accessibles en lecture, mais les fichiers contenant des données sensibles sont bel et bien protégés. Pour s'en convaincre, il suffit de regarder les droits de /etc/ssh/*key ou /etc/shadow.