JJD a écrit 516 commentaires

Salut,

Tout est dans le titre aussi : il est possible de créer des formulaires avec libreoffice writer et il suffit ensuite de les exporter en PDF.

… où est-ce que tu étais installé et pourquoi tu avais besoin d'un accès internet haut débit.

En suivant le lien de ta « page perso », j'ai au moins la réponse à ma deuxième question !

Pour la plupart des paquets Debian, les symboles de debug existent mais sont dans des paquets qui ont été sortis des dépôts principaux.
Jette un coup d'œil sur cette page :
https://wiki.debian.org/HowToGetABacktrace

En résumé, les symboles de debug sont maintenant (depuis 2015 ?) dans une archive à part (ligne «deb http://debug.mirrors.debian.org/debian-debug/ unstable-debug main» à ajouter au source.list pour Sid).

J'espère que ça te redonnera envie de tenter l'expérience Debian ;-)

Salut,

Je n'ai pas d'expérience concernant l'utilisation de cette interface d'administration mais pour pouvoir l'utiliser, il faut l'activer dans le fichier de configuration de prosody (prosody.cfg.lua). Dans la section modules_enabled, il faut indiquer "admin_telnet" (sur mon serveur, il suffit de dé-commenter la ligne en supprimant les deux tirets).
Après modification du fichier de conf, il faut redémarrer prosody.

Là où MAXS conserve un avantage, à mon avis, c'est que KDE Connect nécessite que le téléphone et le PC soient sur le même réseau local alors qu'avec MAXS je peux consulter ou envoyer des SMS du bureau lorsque j'ai oublié mon téléphone à la maison.
À moins que je n'ai raté quelque chose…

Oui mais que donne «dpkg -l 'linux-image*'»

Dans ta réponse, on voit seulement que le paquet linux-image-4.9.0-3-amd64 fournissant la version 4.9.30-2+deb9u5 du kernel est installé. On ne sait pas si tu as d'autres paquets linux-image*, et en particulier des méta-paquets, présents sur ton serveur.

Si linux-image-4.9.0-3-amd64 est bien le seul paquet présent, tu as bien la dernière version et rebooter ta machine ne servira à rien.
En revanche, il me semble qu'habituellement, on installe le méta-paquet linux-image-amd64 (pour une archi amd64, sinon la dernière partie du nom change) qui dépend de la dernière version disponible (en ce moment, la dépendance, dans le dépôt security, est vers linux-image-4.9.0-5-amd64 (en version 4.9.65-3+deb9u2)

Tu devrais regarder quelles versions du kernel sont installées sur ton serveur avec «dpkg -l 'linux-image*'»

Et bien évidemment, tu ne verras la dernière version du noyau installé avec un "uname -a" qu'après avoir rebooté ton serveur.

#!/bin/bash
cpt=1
while ((cpt<10))
   do
       var=x${cpt}
       eval $var=projet$cpt
       echo  "${var}=${!var}"
       cpt=$(( $cpt + 1 ))
   done
exit 0

Mais c'est vrai qu'il aurait été plus simple de répondre s'il y avait eu une question…

et surtout, comme le DocumentRoot défini pour ce VirtualHost est /var/www/html/039_ebsf, il y a de grandes chances pour que les différents documents soient accessibles avec l'URL http://sites.csvt.qc.ca/ plutôt que http://sites.csvt.qc.ca/039_ebsf (sauf si le répertoire /var/www/html/039_ebsf/039_ebsf existe, ce qui serait étonnant).
Le souci vient certainement du fait qu'il y a des liens absolus dans le code (comme http://sites.csvt.qc.ca/039_ebsf/wp-content/plugins/wp-events-manager/inc/libraries//countdown/css/jquery.countdown.css). Il doit il y avoir une erreur dans la configuration de WordPress.

Il faut surtout penser à mettre une ligne vide au dessus des ```.
En respectant cela, le code de mon premier post s'affiche comme ça :

eval $(wget -O - https://toolslib.net/downloads/finish/1-adwcleaner/ 2>/dev/null | \
egrep 'var (projectId|projectAlias|fileId|downloadToken)' | sed -e 's/^ *var //' | \
tr -d '\015 ') && \
wget -O ${projectAlias}.exe https://toolslib.net/downloads/finish/${projectId}-${projectAlias}/${fileId}/get/${downloadToken}/

c'est tout de même plus joli !

il y a une petite erreur sur le dernier wget : la bonne commande est :

wget -O ${projectAlias}.exe https://toolslib.net/downloads/finish/${projectId}-${projectAlias}/${fileId}/get/${downloadToken}/
et je n'ai pas trouvé comment insérer correctement du code…

Salut,

Une solution est de récupérer les variables ou le lien transitoire dans la page renvoyée par le serveur.
Ça donnerait quelque chose dans ce genre :

eval $(wget -O - https://toolslib.net/downloads/finish/1-adwcleaner/ 2>/dev/null | \
egrep 'var (projectId|projectAlias|fileId|downloadToken)' | sed -e 's/^ *var //' | \
tr -d '\015 ') && \
wget -O ${projectAlias}.exe "https://toolslib.net/downloads/finish/${projectId}-${projectAlias}/${fileId}/${downloadToken}"

En espérant que ça t'aide…
JJD

Effectivement, faire un test de performance disque en utilisant les données issues de /dev/urandom (ou pire de /dev/random) n'est pas vraiment pertinent en raison de la vitesse de génération de ces données pseudo-aléatoires.
D'un autre côté, utiliser /dev/zero ne me semble pas pertinent non plus, puisque c'est la même donnée qui se répète dans tous le fichier.
Un voie possible pourrait être d'utiliser /dev/urandom pour créer un gros fichier sur un système de fichiers en RAM (/dev/shm par exemple) et de prendre ce fichier comme source pour l'écriture sur le disque à tester. Mais même dans ce cas, le résultat peut être biaisé en raison des optimisations faites par l'OS (cache en lecture, même si avec un fichier en RAM ça ne doit pas jouer, et bufferisation des écritures [je ne sais pas comment dd gère cela]).

Sinon, il existe aussi la commande hdparm qui, avec l'option «-t», permet de se faire une idée des performances en lecture du disque.

Peut-être simplement parce que cela ne répond pas à son besoin… Son serveur doit pouvoir envoyer des mails et donc il faut que la sortie vers le port 25 des autres serveurs SMTP soit ouverte.

Si j'ai bien compris, il s'agit de n'autoriser la connexion entrante sur le port 25 qu'en provenance des autres serveurs SMTP et d'obliger les clients de messagerie (ceux utilisant des adresses d'émission sur les domaines gérés par ce serveur) à se connecter sur les ports 587 (submission) ou 465 (SMTPS).
Je n'ai pas de réponses précises à cette question mais voici quelques éléments en vrac.

Je ne pense pas que l'on puisse interdire à un client SMTP de se connecter sur le port 25 puisque ce port doit être ouvert pour que les serveurs puissent envoyer les mails à destination des domaines gérés. En revanche, on doit pouvoir interdire l'envoi de mail à destination de domaines externes via le port 25. Pour cela, on peut :
- n'accepter les mails entrants et à destination d'un domaine externe que si le client s'est authentifié ;
- n'autoriser l'authentification que si le canal est chiffré (TLS)
- interdire l'authentification sur le port 25.

Il me semble que les deux premiers points sont déjà actifs dans une conf standard sous Debian. En revanche, il est normalement possible de chiffrer la communication sur le port 25 (avec STARTTLS, aussi utilisé pour la communication entre serveurs) et donc de s'y authentifier. Est-ce grave ou même gênant ?
Si c'est le cas, on doit pouvoir interdire cette authentification avec l'option 'smtpd_sasl_auth_enable=no' au niveau du protocole smtp dans master.cf (à tester tout de même, parce que je suis loin d'être un expert pour la configuration de postfix).

J'espère avoir bien compris la problématique et avoir apporté quelques éléments de réponse.

À+,
JJD

Salut,

En fait, dans ces deux cas, le "echo" qui est utilisé est certainement une commande interne du shell. Sous Debian 7, le shell par défaut était certainement bash alors que sous Debian 8 il s'agit vraisemblablement de dash (le changement est fait pour des raisons de performances et d'empreinte mémoire : dash est plus restreint mais bien plus léger que bash).
Du coup, on observe parfois des différences de comportement, comme pour echo (dans le cas de dash, echo ne comprend qu'une seule option, -n, et interprète systématiquement les séquences \…).

La solution pourrait donc être de simplement supprimer cette option -n, mais à ce moment-là, ça ne fonctionnera plus avec bash.

Tu peux aussi utiliser explicitement la commande externe /bin/echo avec l'option -n. Mais là encore, le résultat n'est pas garanti à 100%.

Ou alors, tu testes pour savoir si le echo utilisé a besoin du -n ou pas :
if [ "$(echo '\n')" = '\n' ]; then ECHO="echo -e" ; else ECHO=echo; fi
puis tu utilises $ECHO à la place de echo pour obtenir le résultat désiré.

Mais la meilleure solution est peut-être d'utiliser printf à la place d'echo :
printf "\\033[1;31m ERR - génération du dh pour le certificat\n"
devrait marcher à tous les coups.

À+,
JJD

Donc pour toi, ce procédé augmente la sécurité du réseau de l'entreprise ?

Ce n'est pas exactement ce que j'ai écrit (ou voulu écrire)…
J'ai indiqué que l'entreprise faisait cela dans le but d'augmenter sa sécurité mais je ne me suis pas prononcé sur l'efficacité de la méthode !

D'un côté, je comprends l'objectif : déchiffrer le flux permet de filtrer le contenu pour détecter d'éventuels virus (mais les postes de travail on aussi des anti-virus normalement à jour) ou pour interdire l'accès à certains sites (jeux, pornographie, …)

Mais ce qui me dérange, au moins dans les cas que je connais bien (c'est à dire là où je bosse), ce sont les "effets secondaires" et la façon dont tout cela est géré.
La maintenance des listes blanches est laissée au prestataire externe (genre énorme boîte aussi connue pour ses anti-virus) et il semble difficile de paramétrer quoi que ce soit la dessus (ou alors nos administrateurs et exploitants manquent de maîtrise de la solution). Je n'ai jamais réussi à avoir cette liste (qui en plus doit bouger régulièrement).
Le plus grave, à mon avis, c'est que, en tant qu'utilisateur, je n'ai plus aucune maîtrise sur les certificats que j'accepte ou pas. Afin d'éviter d'avoir de trop nombreuses réclamations, le proxy a été paramétré pour accepter TOUS les certificats, quels que soient leur état, l'AC signataire ou le sujet. Comme en interne on ne voit que le certificat signé par l'AC interne, tout est toujours valide pour peu que l'on ait accepté cette AC interne (lorsque mes collègues se connectent à mon serveur auto-hébergé avec un certificat auto-signé, ils n'ont jamais d'alerte !)

On voit donc que rien n'est parfait et que tout est une question d'équilibre. Pour ma part, j'avoue que j'aurais préféré que ce type de choses ne soient pas mises en place et que l'on investisse plutôt sur la formation des collaborateurs à la sécurité. Mais je suis un peu naïf : je suis dans une grosse boîte dans le domaine de l'IT et pourtant je dois bien avouer que les plus grosses failles de sécurité viennent du comportement des utilisateurs, y compris lorsqu'ils occupent des postes techniques (développeurs, voire même administrateurs/exploitants). On peut donc comprendre que les entreprises choisissent d'encadrer et de restreindre (contraindre ?) plutôt que de former et responsabiliser : c'est plus simple et (faussement) plus sécurisant (faire confiance aux gens ? quelle idée absurde !)

Salut,

Et bien, de toute évidence, le proxy de ton entreprise déchiffre le flux SSL pour analyser le contenu comme il le fait pour des connexions non sécurisées. En pratique, lorsque tu établis une connexion HTTPS, le proxy se fait passer pour le serveur distant en générant un certificat SSL signé par l'AC de l'entreprise. Le certificat racine de cette AC étant poussé dans les magasins SSL sur les postes des utilisateurs via des procédure internes de l'entreprise, les navigateurs qui utilisent ce magasin (IE mais peut-être aussi Chrome) n'y voient que du feu. Ensuite, le proxy communique avec le serveur distant en SSL (HTTPS). La communication est donc chiffrée entre ton poste et le proxy ainsi qu'entre le proxy et le serveur distant mais le flux est bien en clair sur le proxy (c'est d'ailleurs bien le but : appliquer les mêmes règles de filtrage aux sites HTTPS et HTTP).
Normalement, l'entreprise doit vous signaler ce mode de fonctionnement.

Il est possible (c'est le cas là où je travaille) que certains sites, dans une liste de confiance, soient accessibles sans ce déchiffrement intermédiaire (chez nous, cela concerne la plupart des sites bancaires, les gros fournisseurs de messagerie, comme gmail, les sites gouvernementaux [impots.gouv.fr ;-)], etc). On peut vérifier cela en regardant l'émetteur du certificat SSL : s'il s'agit de l'AC de l'entreprise (xxxInfrastructureProxyCA) c'est déchiffré, sinon le flux reste bien confidentiel de bout en bout.

Note tout de même que ce procédé, mis en place pour augmenter la sécurité et protéger l'entreprise (sa responsabilité est-elle engagée en cas d'accès, depuis son réseau, à des sites "non légaux" ?) soulève aussi d'autres problèmes. En particulier, il devient compliqué de laisser l'utilisateur final choisir comment réagir en cas de certificat non valide : le certificat du serveur HTTPS n'étant pas transmis jusqu'au navigateur, on peut difficilement choisir d'accepter ou pas un certificat périmé, auto-signé ou signé par une AC autre que celles que l'on accepte habituellement (soit le proxy accepte tout, soit il n'accepte que ce qui est strictement valide par rapport à sa liste d'AC, soit, beaucoup plus rarement, il essaie de générer un certificat imitant le certificat final [périmé, auto-signé, …]).

Au final, et dans le doute, considère que les administrateurs de ton entreprise peuvent intercepter tout ce qui passe, y compris quand l'accès au site se fait en HTTPS.

Il faut indiquer le content-type dans les en-têtes du mail.
Ça doit pouvoir se faire ainsi :
mail -a "Content-Type: text/html; charset="utf-8"" -s "test" example@example.com < /tmp/mail.html
Note tout de même que, en fonction de ton client "mail", la syntaxe peut varier. L'option "-a" fonctionne avec bsd-mailx mais certainement aussi avec gnu-mailutils (avec ce dernier, il y a aussi des options pour ajouter directement le content type). Dans le doute, regarde la page de manuel de ton client (man mail).

Non, on ne configure pas forcément à la main ni même en IP statique.
Normalement, mDNS doit permettre de faire de la résolution de nom en IPv4 ou IPv6 sur le domaine .local.
En clair, une machine toto présente sur le réseau local doit pouvoir être jointe avec le nom toto.local sans rien n'avoir à faire d'autre qu'installer et configurer le logiciel mDNS (normalement il s'agit d'avahi sous Linux).

Pour que la résolution se fasse correctement (en IPv6), il faudra peut-être également indiquer "mdns6" ou "mdns6_minimal" sur la ligne hosts du fichier /etc/nsswitch.conf (ça dépend de ce que la distribution paramètre elle-même).

Salut,

Pour indiquer le relai SMTP à utiliser, tu peux utiliser la directive "relayhost" dans main.cf ainsi :
relayhost = [smtp.example.com]:587

Tu peux également spécifier l'authentification dans ce même fichier :

smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous

Dans ce cas, tu indiques cette authentification dans le fichier /etc/postfix/sasl_passwd :
[smtp.example.com]:587 user:password
et tu n'oublie pas, après chaque modification, d'exécuter
postmap /etc/postfix/sasl_passwd

En fonction de la configuration de ton relai de messagerie, il faudra peut-être faire attention à avoir un émetteur du mail valide ou au moins un nom de domaine valide.

À+,
JJD

Attention au fait que les options de recherche ne sont pas les mêmes suivant que l'on coche ou pas la recherche sur le serveur.

Avec cette option, on n'a pas, par exemple, la possibilité de choisir le statut des pièces jointes ou des indésirables (mais on y gagne la recherche dans le corps du message).

Il faut tout de même réussir à recadrer un minimum le débat. On est là dans le cadre professionnel d'une entreprise, pas sur un hotspot WIFI ou un réseau public, avec du matériel fourni par l'entreprise et des règles qui sont normalement communiquées aux collaborateurs (salariés ou prestataires). Si l'on en arrive à un tel niveau de paranoïa vis à vis de ses admin réseau et système, il faut effectivement réduire au minimum les échanges personnels, voire professionnels comme indiqué plus bas, sur ce matériel et ce réseau (actuellement avec un téléphone perso ou une tablette + un accès 4G, ça n'est pas bien compliqué).

Mais je ne pense pas que l'objectif (premier) de ce type d'infrastructure soit de venir découvrir les codes d'accès aux sites bancaires ou les mots de passe des comptes LinuxFr.org. J'ai vu des entreprises mettre en place ces proxy SSL filtrant au fur et à mesure que les flux https se sont développés de façon à filtrer de la même façon les contenus https ou http. Sans vouloir défendre ces pratiques, il faut aussi comprendre les contraintes auxquelles sont soumises les entreprises :
- responsabilité en cas d'accès à certains sites ;
- irresponsabilité/manque de compétences des utilisateurs qui téléchargent un peu n'importe quoi ou cliquent n'importe où (avec des risques d'infection qu'un antivirus local ne suffit pas toujours à réduire) ;
- obligation de conserver certaines logs de connexion pendant un certain temps (cette obligation n'est pas forcément légale mais peut être liée à certaines procédures de sécurité ou à des agréments).

Donc, je ne pense pas que ces entreprises aient un intérêt particulier à dissimuler leur AC derrière un nom particulier, l'objectif n'étant pas de tromper les collaborateurs mais de protéger le réseau interne (ou au pire de surveiller les employés ou des les dissuader d'utiliser les ressources professionnelles pour des besoins perso). Je pense même qu'elles auraient tout intérêt à communiquer largement sur ce filtrage.
La vérification de l'AC émettrice du certificat me semble donc suffisante. Si ce n'est pas le cas, rien ne le sera (et il faut alors certainement penser à changer de boite).

Salut,

Dans ma boîte, ça se passe aussi comme ça. Nous avons un proxy filtrant (sites ou contenus interdits, antivirus, …) qui déchiffre aussi le contenu SSL (sauf pour certains sites reconnus, comme ceux des banques, gmail, et quelques autres). Cela peut se faire de façon transparente parce que le proxy génère à la volée un certificat correspondant au site visité mais signé par l'AC de l'entreprise (et le certiticat racine est diffusé sur tous les postes, Windows, via la GPO).
Le moyen le plus simple que j'ai trouvé pour savoir si le site visité est filtré par le proxy est de vérifier l'autorité qui a délivré le certificat : lorsque le proxy déchiffre, il s'agit de l'AC interne, sinon c'est une AC "reconnnue" (Gandi, Commodo, Thawte, Verisign, let's Encrypt, …)
Bien évidemment, tout cela est clairement annoncé par l'entreprise (il s'agit peut-être d'une obligation) mais la liste des sites en liste blanche n'est pas publiée (il me semble que cette liste ainsi que la détection de contenus "illicites" s'appuient sur des données fournies par un prestataire externe).

Il faut cependant noter que ce mécanisme, introduit pour des raisons de sécurité et de confidentialité (ça peut permettre de tracer des fuites de données) peut aussi induire des problèmes : la gestion des certificats serveur non valides (certificats expirés, autosignés ou signés par une AC non présente sur la machine locale) n'est plus possible du côté de l'utilisateur final. Soit le serveur intermédiaire accepte tout sans discernement (avec un risque d'usurpation d'identité) soit il rejette,sans laisser la possibilité à l'utilisateur de choisir (il existe des mécanismes pour gérer ces cas mais cela reste délicat et imparfait).

C'est bizarre…
Sur ma Debian (SID mais stretch devrait en être assez proche), le display :0 est utilisé par GDM et, lorsque l'on ouvre une session graphique, on a le display :1. Dans /tmp/.X11-unix on a alors deux sockets, X0 et X1.

Je pense que si tu crées le fichier manquant, ça pourrait fonctionner (mkfifo /tmp/.X11-unix/X0). Ça devrait fonctionner aussi si, avant de te connecter en SSH, tu fait un export DISPLAY=localhost:0 (la connexion au serveur X doit alors passer alors par une socket TCP plutôt que par une socket Unix).

Mais cela ne nous dit pas pourquoi ton fichier /tmp/.X11-unix/X0 n'existe pas. Est-ce que ta session est ancienne (et le fichier aurait pu être supprimé) ? As-tu essayé en te déconnectant/reconnectant localement sur ta machine cliente ?

Bonjour,

Lorsque tu fais tu ForwardX11 SSH, sur ton serveur SSH, le DISPLAY n'est pas positionné à monclient:0.0 mais à localhost:10 (ou 11 ou 12…). En fait les clients X sur le serveur (applications graphiques) contactent un serveur X "local" mais ce flux est transporté dans un tunnel SSH vers le serveur X du client SSH. Faire un export DISPLAY=monclient:0 sur le serveur SSH ne sert donc pas à grand chose (sinon à faire que ça ne marche pas).

Pour essayer de comprendre ce qui ne marche pas, il faudrait avoir plus d'infos. Que donnent, sur monclient, les commandes echo $DISPLAY et xclock (ou xlogo ou n'importe quelle autre commande qui doit afficher une fenêtre) ?
Sur monclient, est-ce que le fichier /tmp/.X11-unix/X0 existe ? Que donne ls -l /tmp/.X11-unix/ ?

À+
JJD