Re: Quid du support nvidia en mars 2024

[Pascal Obry]

Bonjour,

> Qu'en est-il actuellement du support nvidia ?

Pour moi ça marche nickel et cela depuis pas mal de temps (plus de 5
ans). J'ai une Nvidia et la seule chose que je fasse est un:

$ apt install nvidia-kernel-dkms

Et ça marche ! Je ne sais pas si c'est difficile pour les développeurs
à intégrer ou pas, mais en tant qu'utilisateur c'est sans soucis.

J'éviterais AMD si tu souhaites faire de l'OpenCL, on a des problèmes
avec AMD sur le projet darktable.

Voilà mon retour !

-- 
  Pascal Obry /  Magny Les Hameaux (78)

  The best way to travel is by means of imagination

  http://photos.obry.net

  gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: [ HS ] find et les gros fichiers

[Pascal Le Bris]

Re 
pour la démo en testant sur /etc ( mais sur des gros fs (64To) c'est etonnant 
l'efficacité) 
apt-get install ncdu 

Pour scruter une arbo par exemple /etc : 
ncdu /etc 

Pour sauver le resultat 
ncdu -o /tmp/etc.ncdu /etc/ 

Pour sauver le resultat 
ncdu -f /tmp/etc.ncdu 

Pascal 

> De: "David Martin" 
> À: "debian-user-french@lists.debian.org French"
> 
> Envoyé: Jeudi 31 Mars 2022 07:54:34
> Objet: Re: [ HS ] find et les gros fichiers

> Bonjour Pascal,
> Merci pour cette info, tu as un exemple d'utilisation ?

> La commande de bernard est vraiment bien... par contre si l'un de vous connais
> exim (je suis plus à l'aise avec Postfix), je cherche
> le moyen d'ajouter notre relais smtp pour l'envoi automatique d'un mail du
> rapport à la fin de la commande.

> Sous postfix je renseigne la variable relay_host =
> sous exim ça à l'air plus compliqué non ?

Re: [ HS ] find et les gros fichiers

[Pascal Le Bris]

Bonjour 
Sans répondre vraiment à la question: pour la chasse aux gros j'utilise 'ncdu' 
qui a la bonne idée de pouvoir exporter le résultat dans un fichier qu'il peut 
rejouer. 
Cordialement 

> De: "David Martin" 
> À: "debian-user-french@lists.debian.org French"
> 
> Envoyé: Mercredi 30 Mars 2022 15:47:42
> Objet: [ HS ] find et les gros fichiers

> Bonjour,
> Je suis en train d'essayer de chercher sur un partage samba d'environ plus de
> 1500 utilisateurs
> (solution libre eole / scribe) ceux qui auraient des gros fichiers.
> Les répertoires a, b, c, d, . z héberge les comptes utilisateurs.

> Pour ça j'utilise la commande find

> find ./a -xdev -type f -size +500M

> Ca fonctionne plutot bien, mais je dois à chaque fois changer la lettre,
> est-ce qu'il est possible que la commande pour le dossier "a" passe en suite 
> au
> répertoire "'b" autrement que de faire un script en l'éxécutant l'une après
> l'autre ?

> J'aimerai aussi afficher la taille des fichiers, mais je ne vois pas comment
> combiner la commande "du -sh" pour qu'elle m'affiche la taille en bout de
> ligne. l'idée est de constituer un fichier à transmettre à ma hiérarchie.

> Je suis preneur de toute idée ;-)

> --
> david martin

Re: remettre windows

[Pascal Le Bris]

Bonjour
  Peut-etre une piste via un une clé usb et refind
https://www.rodsbooks.com/refind/getting.html
https://sourceforge.net/projects/refind/
A
- Mail original -
> De: "hamster" 
> À: "debian-user-french" 
> Envoyé: Jeudi 24 Mars 2022 12:48:19
> Objet: Re: remettre windows

> Le 03/10/2017 à 17:28, Pascal Hambourg a écrit :
>> Le 03/10/2017 à 17:11, hamster a écrit :
>>> Quelqu'un a qui j'ai installé débian en double boot n'est pas séduit par
>>> le bidule et me demande de lui remettre l'ordi avec uniquement windows.
>>> Je me fais un point d'honneur a satisfaire sa demande, seulement voila :
>>> si je vire debian, grub ne marche plus.
>>> Une solution serait de restaurer le bootloader de windows, mais je sais
>>> pas faire.
>>
>> Moi non plus. J'ai entendu parler de fixboot et fixmbr avec un CD ou
>> DVD d'installation de Windows, mais jamais fait.
> 
> Souci, j'ai pas de CD d'installation.
> 
>>> Est-ce qu'il existe des bootloaders indépendants
>>> de linux pour remplacer grub (et dans ce cas lequel me conseillez
>>> vous) ?
>>
>> mbr, qui installe un code amorce presque standard dans le MBR.
>> Lancer l'installateur Debian en mode expert.
>> Sélectionner mbr dans les composants additionnels.
>> Dès que possible, passer dans une console (Alt+F2 ou F3) et installer
>> le code amorce avec la commande
>>
>> install-mbr /dev/sdX
> 
> Ca a l'air très bien, mais je reviens vers vous parce que l'ordi que
> j'ai a traiter maintenant est en UEFI. Du coup je suis un peu perdu et
> j'ai pas envie de faire une betise. Si je passe en mode legacy le
> windows (qui a été installé sur UEFI) ne marchera plus, et si je reste
> en UEFI le démarrage n'est plus géré par le MBR. Ou alors c'est que j'ai
> pas tout compris.
> 
> Merci pour vos lumières.

Re: photo opensource

[Pascal Obry]

Le vendredi 04 juin 2021 à 20:12 +0200, Kohler Gerard a écrit :
> en fait c'est la gestion de certain matériel bien spécifique :
> 
>  imprimantes photo professionnelle,
> 
>  scanners (surtout pour la retouche des négatifs )
> 
> ou il n'existe pas encore de solution open source, surtout du fait
> que les fabricants ne communiquent pas sur leurs firmware.

C'est vrai ! Mais une bonne solution non Open Source est Turboprint. La
qualité est très bonne (je tire des A3 avec sur une Epson 3880). Je
suis aussi l'auteur du module turboprint dans darktable qui est
certainement l'un des meilleurs logiciels Open Source pour la photo et
peut être même meilleurs que pas mal de concurrents privatifs comme Lr
(et je connais bien Lr que j'ai utilisé pendant des années, j'ai même
animé des sessions de formation).

Cordialement,

-- 
  Pascal Obry /  Magny Les Hameaux (78)

  The best way to travel is by means of imagination

  http://www.obry.net

  gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: recette de cuisine à corriger

[Pascal Le Bris]

Bonjour
  Mon grain de sel
  Avec awk : awk '(NR%2 == 1){printf $0}(NR%2 == 0){print $0}' nom-du-fichier

Pascal
- Mail original -
> De: "Bernard Schoenacker" 
> À: "debian-user-french@lists.debian.org French" 
> 
> Envoyé: Mercredi 3 Mars 2021 20:11:06
> Objet: recette de cuisine à corriger

> Bonjour,
> 
> J'ai une recette de cuisine qui est un copié coller
> dans un fichier texte et je souhaiterai le remettre
> en forme de telle façon que les quantités soient
> en face des ingrédients ...
> 
> Pour l'instant et sur la première ligne j'ai
> la quantité et sur la seconde j'ai l'ingrédient
> et ainsi de suite, comment faire pour le remettre
> en forme à l'aide d'une "règle" ?
> 
> Merci pour votre aimable attention
> 
> bien à vous
> 
> Bernard

Re: Plus de son avec Debian Sid

[Pascal Obry]

David,

> En effet, ta procédure était OK !
> Je ne comprends pas bien la différence entre la tienne et la mienne 
> mais, visiblement, le résultat n'était pas le même.

Je pense que la différence et que j'utilise "-t testing" pour demander
à apt de considérer testing dans la vérification des dépendances en
priorité et non unstable comme c'est indiqué dans mon apt/preferences.

Cordialement,

-- 
  Pascal Obry /  Magny Les Hameaux (78)

  The best way to travel is by means of imagination

  http://www.obry.net

  gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: Plus de son avec Debian Sid

[Pascal Obry]

David, et la liste,

Pour information, la version 0.3.15 disponible sur GNU/Debian/sid
corrige le problème de son.

Bonne journée,

-- 
  Pascal Obry /  Magny Les Hameaux (78)

  The best way to travel is by means of imagination

  http://www.obry.net

  gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: Plus de son avec Debian Sid

[Pascal Obry]

Le jeudi 05 novembre 2020 à 16:25 +0100, Klaus Becker a écrit :
> Bonjour,
> 
> j'utilise également unstable, j'ai actualisé mon système ce matin et
> le 
> son fonctionne toujours:
> $ cat /proc/asound/modules
>   0 snd_hda_intel
>   1 snd_ca0106
> 
> J'utilise XFCE4

As-tu rebooté ? Car sans rebooter il n'y pas de problème je pense.


-- 
  Pascal Obry /  Magny Les Hameaux (78)

  The best way to travel is by means of imagination

  http://www.obry.net

  gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: Plus de son avec Debian Sid

[Pascal Obry]

Le jeudi 05 novembre 2020 à 16:02 +0100, David BERCOT a écrit :
> # apt install pipewire-bin=0.3.12-1 libpipewire-0.3-modules=0.3.12-1 
> libpipewire-0.3-0=0.3.12-1 libspa-0.2-modules=0.3.12-1

De mon coté j'ai fait sans souci:

$ sudo apt install -t testing gstreamer1.0-pipewire/testing 
libpipewire-0.3-0/testing libpipewire-0.3-modules/testing 
libspa-0.2-modules/testing

Cordialement,

-- 
  Pascal Obry /  Magny Les Hameaux (78)

  The best way to travel is by means of imagination

  http://www.obry.net

  gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: Plus de son avec Debian Sid

[Pascal Obry]

David,

> Bonjour à tous,
> 
> Depuis ce matin, je n'ai subitement plus de son (et, dans Gnome,
> aucun 
> périphérique n'est proposé)...
> Je suis en Sid, noyau en 5.9.

Même problème, j'ai analysé cela et trouvé que le problème vient de
pipewire. Un downgrade vers la version sur testing (0.3.12-1) permet de
remettre le son en fonction.


Les paquets impactés sont:

libpipewire-0.3-0
libpipewire-0.3-modules
libspa-0.2-modules
pipewire-bin

Cordialement,

-- 
  Pascal Obry /  Magny Les Hameaux (78)

  The best way to travel is by means of imagination

  http://www.obry.net

  gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: insserv: FATAL: service mountkernfs is missed

[Pascal Hambourg]

Le 10/01/2020 à 22:31, ajh-valmer a écrit :

On Friday 10 January 2020 21:34:25 Pascal Hambourg wrote:

Le 10/01/2020 à 14:34, ajh.val...@free.fr a écrit :

Je ne vais pas retirer "initscripts" mais retirer "mountkernfs.sh",
qui n'a plus raison d'être dans Buster car intégré à son noyau.



mountkernfs.sh n'est pas du tout intégré au noyau. C'est absurde.


Réponse trop courte, sans précision :
soit..., mais ou est-il passé ?
Le package n'existe plus sous Buster.


Si : cf. <https://packages.debian.org/buster/initscripts>


Alors le service mountkernfs est géré par systemd,


Disons plutôt qu'il le remplace, puisque le paquet systemd installe un 
lien symbolique qui inhibe ce service.


/lib/systemd/system/mountkernfs.service -> /dev/null

Re: insserv: FATAL: service mountkernfs is missed

[Pascal Hambourg]

Le 10/01/2020 à 14:34, ajh.val...@free.fr a écrit :


Je ne vais pas retirer "initscripts" mais retirer "mountkernfs.sh",
qui n'a plus raison d'être dans Buster car intégré à son noyau.


mountkernfs.sh n'est pas du tout intégré au noyau. C'est absurde.

Re: insserv: FATAL: service mountkernfs is missed

[Pascal Hambourg]

Le 07/01/2020 à 14:17, Pascal Hambourg a écrit :

Le 07/01/2020 à 12:05, ajh-valmer a écrit :


Si mountkernfs.sh figure dans : initscripts: /etc/init.d/
peut-on supprimer sans conséquences "initscripts" ?


Non, car le paquet ifupdown (qui installe le service networking) en dépend.


Oups, ce n'est plus le cas depuis Stretch.

Re: insserv: FATAL: service mountkernfs is missed

[Pascal Hambourg]

Le 07/01/2020 à 12:05, ajh-valmer a écrit :

On Tuesday 07 January 2020 00:33:12 Pascal Hambourg wrote:

On Tuesday 07 January 2020 11:50:13 Luc Novales wrote:

Puisque la ligne précédente indique que systemd fournit déjà ce service,
cela n'en fait il pas un de trop ?


Non. /lib/systemd/system/mountkernfs.service est un lien symbolique 
pointant vers /dev/null qui sert par conséquent à le désactiver.



Je réitère ma question :
Si mountkernfs.sh figure dans : initscripts: /etc/init.d/
peut-on supprimer sans conséquences "initscripts" ?


Non, car le paquet ifupdown (qui installe le service networking) en dépend.

Re: insserv: FATAL: service mountkernfs is missed

[Pascal Hambourg]

Le 05/01/2020 à 23:50, Pascal Hambourg a écrit :

Le 05/01/2020 à 21:57, ajh-valmer a écrit :


"S01mountkernfs.sh" est dans /etc/rcS.d
mais pas de mountkernfs.sh dans "sysv-rc-conf".

Aucun "S01mountkernfs.sh" dans les rc1.d à rc6.d.


Bizarre.


Au temps pour moi. Rien de bizarre, la présence dans rcS.d seul est 
normale et correspond au contenu de l'en-tête LSB.

Re: insserv: FATAL: service mountkernfs is missed

[Pascal Hambourg]

Le 05/01/2020 à 21:57, ajh-valmer a écrit :


"S01mountkernfs.sh" est dans /etc/rcS.d
mais pas de mountkernfs.sh dans "sysv-rc-conf".

Aucun "S01mountkernfs.sh" dans les rc1.d à rc6.d.


Bizarre. Il faut peut-être réinstaller les liens avec

update-rc.d mountkernfs.sh defaults

Re: insserv: FATAL: service mountkernfs is missed

[Pascal Hambourg]

Le 04/01/2020 à 22:28, ajh-valmer a écrit :


/etc/init.d/networking :
### BEGIN INIT INFO
# Provides: networking ifupdown
# Required-Start: mountkernfs $local_fs urandom
# Required-Stop: $local_fs
# Default-Start: S
# Default-Stop: 0 6

(...)

/etc/init.d/mountkernfs.sh :
### BEGIN INIT INFO
# Provides: mountkernfs
# Required-Start:
# Required-Stop:
# Should-Start: glibc
# Default-Start: S
# Default-Stop:


C'est conforme à ce que je vois sur mon système. Les deux scripts ne 
demandent à être démarrés que dans le runlevel S, donc je ne vois pas 
pourquoi insserv se plaint à propos des runlevels 1 à 5.


Peux-tu regarder dans les différents répertoires /etc/rc*.d/ lesquels 
contiennent des liens S*mountkernfs.sh et S*networking ? Normalement ils 
ne devraient être que dans /etc/rcS.d/.



Je constate que dans le dernier :
# Required-Start:
# Required-Stop:
# Default-Stop:
n'ont pas d'infos derrière.


Parce qu'il n'a pas de dépendance de ces types.

Re: Protéger le grub linux par mot de passe - Console en qwerty - Comment passer en azerty

[Pascal Hambourg]

Le 04/01/2020 à 02:50, G2PC a écrit :



Ce n'est pas suffisant. Le chiffrement seul protège contre la
divulgation des données en cas de perte ou de vol, mais pas contre une
intervention illicite non détectée sur la partie du système qui doit
inévitablement rester non chiffrée. Ne pas oublier qu'une installation
standard de Debian avec chiffrement laisse l'intégralité de /boot en
clair, ce qui inclut le chargeur d'amorçage, l'image du noyau et
l'initramfs. GRUB et le noyau peuvent être protégés par le secure boot
UEFI, mais pas l'initramfs ni la configuration de GRUB.


Pour ma part, j'ai comme un doute pour le secure boot UEFI.


Un doute à propos de quoi exactement concernant le secure boot ?


J'ai installé Debian, Windows, et, Mint, en dual Boot.
Pour cela, j'ai bien du désactiver le secure boot UEFI depuis le BIOS.


Pourtant en principe ces trois OS sont compatibles avec le secure boot 
(Debian depuis la version 10).



Dès lors le chargeur d'amorçage, l'image du noyau et l'initramfs ne sont
pas protégés ?


Non puisque le firmware ne va pas vérifier l'intégrité du chargeur 
d'amorçage qui ne va pas vérifier l'intégrité de l'image du noyau et 
ainsi de suite.



Quels sont les conséquences ? Le chiffrement du disque pourrait alors
être rendu inopérant ?


Un attaquant qui a un accès physique à la machine pourrait modifier 
l'initramfs pour intercepter et enregistrer la phrase de passe de 
chiffrement, attendre qu'un utilisateur légitime tape la phrase de 
passe, puis la récupérer et déchiffrer le disque.


Mais une telle modification est détectable en introduisant dans la 
partie chiffrée du système (inaccessible à l'attaquant tant qu'il n'a 
pas récupéré la passphrase) une vérification de l'intégrité des fichiers 
de démarrage. Pour contrer cette protection, l'attaquant peut introduire 
dans le noyau (image principale ou module inclus dans l'initramfs) un 
rootkit qui masque les fichiers modifiés et présente les fichiers 
originels à la place.


Le secure boot n'empêcherait pas la modification des fichiers de 
démarrage mais empêcherait de démarrer avec un noyau compromis masquant 
les modifications. Certes l'initramfs compromis pourrait aussi 
désactiver la détection une fois le disque déchiffré avant de passer la 
main au système principal, mais cela suppose que l'attaquant a une 
connaissance a priori du mécanisme de cette détection, donc accès d'une 
façon ou d'une autre au système déchiffré ou à ses spécifications.

Re: insserv: FATAL: service mountkernfs is missed

[Pascal Hambourg]

Le 03/01/2020 à 22:05, ajh-valmer a écrit :


etc/init.d/mountkernfs.sh et "/etc/init.d/networking" :
Qu'appelles tu "en-têtes LSB" ?


La partie entre "BEGIN INIT INFO" et "END INIT INFO".

Re: insserv: FATAL: service mountkernfs is missed

[Pascal Hambourg]

Le 26/12/2019 à 19:53, ajh-valmer a écrit :


insserv: FATAL: service mountkernfs is missed in the runlevels 1 2 3 4 5
to use service networkinginsserv: exiting now!


On peut voir les en-têtes LSB des fichiers /etc/init.d/mountkernfs.sh et 
/etc/init.d/networking, ainsi que le contenu du répertoire 
/etc/insserv/overrides/ ?

Re: Protéger le grub linux par mot de passe - Console en qwerty - Comment passer en azerty

[Pascal Hambourg]

Le 03/01/2020 à 16:59, Haricophile a écrit :

Le vendredi 27 décembre 2019 à 20:15 +0100, G2PC a écrit :

Protéger le Grub par mot de passe, ça c'est fait. Par contre, la
   console du grub, pour la saisie du mot de passe, est en qwerty.


Si le but est seulement de taper un mot de passe en AZERTY, il me semble 
que le plus simple est de définir comme mot de passe l'équivalent en 
QWERTY de ce qu'on veut taper en AZERTY. Cela exclut les caractères 
spéciaux à taper avec AltGr ou une touche morte, mais il en reste encore 
pas mal.



En sachant que c'est une protection très relative. Si on veut vraiment
protéger le système contre quelqu'un qui a accès à la machine, il faut
chiffrer le disque.


Ce n'est pas suffisant. Le chiffrement seul protège contre la 
divulgation des données en cas de perte ou de vol, mais pas contre une 
intervention illicite non détectée sur la partie du système qui doit 
inévitablement rester non chiffrée. Ne pas oublier qu'une installation 
standard de Debian avec chiffrement laisse l'intégralité de /boot en 
clair, ce qui inclut le chargeur d'amorçage, l'image du noyau et 
l'initramfs. GRUB et le noyau peuvent être protégés par le secure boot 
UEFI, mais pas l'initramfs ni la configuration de GRUB.

Re: Debian 10.2 ne démarre pas

[Pascal Hambourg]

Le 24/12/2019 à 18:09, fw a écrit :


- kvm: disabled by bios => Entrer dans BIOS Setup et activer le 
multithreading, ou qqchose comme ça ...


Non, rien à voir avec le multithreading. Plutôt le support de la 
virtualisation (VT-x ou AMD-v).

Re: Debian 10.2 ne démarre pas

[Pascal Hambourg]

Le 17/12/2019 à 01:39, G2PC a écrit :


De plus en plus désagréable la communauté du libre.


Je ne connais pas cette communauté, et n'en fais pas partie.


Le seul problème qui reste, c'est les entrée du debian qui ne fonctionne
pas sur mon système


Déjà répondu :


man efibootmgr


Qu'est-ce qu'il te faut de plus ?

Re: Debian 10.2 ne démarre pas

[Pascal Hambourg]

Le 16/12/2019 à 19:24, G2PC a écrit :


Si cela apparait dans le Bios dans les choix de démarrage, c'est qu'il
s'agit donc de la MBR ?


Non. Visiblement tu ne comprends rien et tu fais n'importe quoi, mais 
j'ai la flemme de t'expliquer.



J'aimerais bien me débarrasser de ses deux lignes, avant de continuer à
bidouiller.


man efibootmgr

Re: Impossible de supprimer repertoire : Fonction non implantée

[Pascal Hambourg]

Le 09/12/2019 à 23:04, ajh-valmer a écrit :

On Monday 09 December 2019 22:17:34 Pascal Hambourg wrote:

Le 09/12/2019 à 21:16, ajh-valmer a écrit :

Je souhaite supprimer des répertoires dans ce répertoire :
/var/lib/os-prober/mount/home/vmail/

Pour quelle raison ?

(...)

Ça ne répond pas à la question.


Toi non plus, tu ne réponds pas à ma question.

"Dis-moi de quoi tu as besoin et je te dirai comment t'en passer" n'est 
pas toujours une blague communiste.



Ce répertoire contient une quantité énorme de répertoires et fichiers,
qui correspond à mon serveur de mails.


Et donc, pourquoi veux-tu les supprimer ?
Et pourquoi via /var/lib/os-prober/mount/ et non via son emplacement 
normal /home/vmail/ ?



D'ou vient ce répertoire "virtuel" ?


Qu'en dit mount ?

Re: Impossible de supprimer repertoire : Fonction non implantée

[Pascal Hambourg]

Le 09/12/2019 à 21:16, ajh-valmer a écrit :


Je souhaite supprimer des répertoires dans ce répertoire :
/var/lib/os-prober/mount/home/vmail/


Pour quelle raison ?


rm -Rf Maildir/cur
rm: impossible de supprimer 'Maildir/cur': Fonction non implantée
ce répertoire existe pourtant...


Le message ne dit pas que le répertoire n'existe pas mais que la 
suppression n'est pas implantée (implémentée).



Google ne connait pas ce message.


As-tu essayé en anglais ? Il faut préfixer la commande avec LANG=C sur 
la même ligne.


Mais il me semble que /var/lib/os-prober/mount/ est un point de montage 
temporaire utilisé par os-prober avec le type fuse.grub-mount pour 
explorer les systèmes de fichiers à la recherche d'autres systèmes 
d'exploitation.


$ mount | grep grub
grub-mount on /var/lib/os-prober/mount type fuse.grub-mount 
(rw,nosuid,nodev,relatime,user_id=0,group_id=0)


Il se pourrait que ce type de montage interdise la modification.

Re: comment configurer /etc/whois.conf avec Free comme FAI

[Pascal Hambourg]

Le 07/12/2019 à 12:11, Étienne Mollier a écrit :

On 07/12/2019 10.56, Pascal Hambourg wrote:

$ whois --host whois.ripe.net 212.37.27.58
[...tout plein de choses...]

auquel cas, effacer ou remplacer la ligne incriminée par :

.* whois.ripe.net


Le RIPE n'a autorité que pour les adresses IP allouées à l'Europe et au 
Moyen-Orient.

Re: comment configurer /etc/whois.conf avec Free comme FAI

[Pascal Hambourg]

Le 07/12/2019 à 10:11, Étienne Mollier a écrit :

On 07/12/2019 09.29, Basile Starynkevitch wrote:

Actuellement whois 212.37.27.58 reste sans réponse. Mais 
https://dnschecker.org/ip-whois-lookup.php m'indique que ça vient de Suède.

(...)

D'après votre whois.conf, la machine en charge de la Suède est
whois.nic-se.se


C'est le serveur whois défini pour le domaine .se, pas pour les adresses 
IP allouées en Suède (qui doivent être gérées par le RIPE).

Re: Fwd: Re: comment configurer /etc/whois.conf avec Free comme FAI

[Pascal Hambourg]

Le 07/12/2019 à 09:55, Basile Starynkevitch a écrit :

On 12/7/19 9:48 AM, Pascal Hambourg wrote:


Je ne vois pas le rapport avec le FAI. La commande whois interroge 
divers serveurs Whois à travers le monde qui n'ont rien à voir avec le 
FAI du client.


     En bonne logique, elle devrait d'abord interroger celui de Free 
(qui a aussi un serveur DNS, et c'est quand même lié).


Non, pas du tout.


Actuellement whois 212.37.27.58 reste sans réponse.


Depuis Debian Stretch derrière une freebox 5 ADSL, ça marche.


Avec ou sans /etc/whois.conf ? depuis que je l'ai supprimé, ça marche 
aussi  chez moi.


Sans.

Re: comment configurer /etc/whois.conf avec Free comme FAI

[Pascal Hambourg]

Le 07/12/2019 à 09:29, Basile Starynkevitch a écrit :


Abonné chez Free (à Bourg La Reine, près de Paris, France) depuis 
quelques mois (et content de leur service) avec une Freebox revolution à 
fibre optique (mon desktop linux/Debian/Sid est visible de l'internet 
comme ours.starynkevitch.net en ssh pour /certains/ amis) je cherche à 
configurer /etc/whois.conf pour que la commande whois marche bien.


Je ne vois pas le rapport avec le FAI. La commande whois interroge 
divers serveurs Whois à travers le monde qui n'ont rien à voir avec le 
FAI du client.



Actuellement whois 212.37.27.58 reste sans réponse.


Depuis Debian Stretch derrière une freebox 5 ADSL, ça marche.

Re: Debrancher/rebrancher disque USB a distance ?

[Pascal Hambourg]

Le 17/11/2019 à 09:55, Patg a écrit :


Ça m'indique des erreurs lorsque je le partitionne.
Le disque est un LaCie quadra.
J'ai tenté, mais après un partprobe ça m'indique toujours 130 mo.


Qui est "ça" ?
Qu'est-ce que "ça" indique exactement ? Un disque ne change pas de 
taille à cause d'un partitionnement raté.

Re: Méthode pour passer debian de 32 à 64 bits

[Pascal Hambourg]

Le 09/11/2019 à 15:05, ajh-valmer a écrit :

On Thursday 07 November 2019 18:14:32 Haricophile wrote:


Quand on utilise multi-arch les logiciels 32 bits fonctionnent normalement.


Je voudrais dissiper un éventuel malentendu : multi-arch n'est pas 
nécessaire pour exécuter des programmes 32 bits mais pour installer des 
paquets d'architecture différente de celle du système. On pouvait faire 
tourner un userland 32 bits avec un noyau 64 bits bien avant multi-arch.



Est-on obligé d'utiliser une multi-architecture (multi-arch),


Non.


et peut-on utiliser que des applis purement 64 bits ?


Bien sûr. Drôle de question.

Re: /boot et lvm

[Pascal Hambourg]

Le 25/10/2019 à 09:21, Patg a écrit :


Les problématiques, il s'agit de celles qui existaient déjà avec GRUB 1 au sujet de 
lvm, et que je pensais à tord résolu dans la version 2, que tu énonces "ses 
inconvénients et notamment une complexité supplémentaire.


Je ne comprends pas trop ce que tu veux dire. GRUB 1 ne supportait pas 
du tout LVM. GRUB 2 comble cette carence (au moins pour les volumes 
logiques simples) mais il est évident qu'il ne change rien à la 
complexité intrinsèque de LVM (qui est le prix de sa souplesse et de ses 
fonctionnalités).



En cas de problème qui empêcherait GRUB d'accéder aux volumes logiques, tout 
démarrage est impossible"

Je pense notamment suite à un plantage du serveur ou autre... Et qui 
empêcherait GRUB d'avoir la main sur le boot en lvm.


Il ne faut pas exagérer la gravité de cet inconvénient. Il reste 
possible de démarrer un système de dépannage depuis un support amovible.



Je n'ai pas non plus besoin de thin provisioning. Dont je n'ai pas bien compris 
l'intérêt d'ailleurs, mais c'est pas la question.


L'intérêt du thin provisioning est de pouvoir créer des volumes d'une 
taille définie sans allouer immédiatement tout l'espace disque 
correspondant. Cela permet notamment d'éviter de devoir redimensionner 
ces volumes et leur contenu (systèmes de fichiers) pour répartir 
l'espace disque a posteriori.

Re: /boot et lvm

[Pascal Hambourg]

Le 22/10/2019 à 09:20, Patg a écrit :

Je pensais que le grub2 répondait aux problématiques d'avant.


Quelles problématiques ?


Un lvm en raid ne répond pas à ce problème de GRUB, donc... Il faut rester sur 
l'option sans lvm...


GRUB 2 supporte l'empilement LVM sur RAID 0, 1, 4, 5, 6 et 10 logiciel 
(mais pas le RAID "linear"). Il ne supporte peut-être pas des 
fonctionnalités particulières comme les volumes en thin provisioning 
(pas testé), mais il me semble qu'une racine ou /boot en thin 
provisioning est un cas assez spécial. J'ignore aussi ce qu'il en est 
des fonctionnalités RAID natives de LVM (jamais utilisé).



Pour la partition fine, j'ai vu ça dans le lien ci dessous indiquant que le 
/boot sur partition fine n'est pas recommandé. Mais j'ai pas creusé plus que ça 
:

https://wiki.archlinux.fr/LVM


Sauf erreur il s'agit d'un volume logique en "thin provisioning" 
(allocation fine). Drôle d'appellation pour quelque chose qui n'est pas 
une partition.

Re: /boot et lvm

[Pascal Hambourg]

Le 21/10/2019 à 18:46, Patg a écrit :


Habituellement l'installation du /boot se fait hors lvm. Mais depuis grub2, ça 
semble gérer le lvm. Debian utilise par défaut le grub2.


En effet.


L'idée du GRUB2 hors de lvm est il toujours d'actualité ? Ou est il possible de 
l'utiliser sur du lvm ?


C'est possible. /boot peut ainsi bénéficier des avantages de LVM. Mais 
il est aussi soumis à ses inconvénients et notamment une complexité 
supplémentaire. En cas de problème qui empêcherait GRUB d'accéder aux 
volumes logiques, tout démarrage est impossible. Avec /boot hors LVM, 
GRUB pourra au moins charger le noyau et l'initramfs, procurant un 
système minimal permettant au moins de faire un diagnostic voire de réparer.



J'utilise un serveur en raid5 avec le /boot en lvm (pas de partitions fines). 
Quel peut être le risque ?


Qu'appelles-tu "partitions fines" ?

Re: Faut t'il bloquer le Multicast - IGMP avec Iptables

[Pascal Hambourg]

Le 10/10/2019 à 19:58, G2PC a écrit :

Voilà, cette partie a été traitée.

J'ai également remplacé :

-A INPUT -p tcp --sport 49152:65534 --dport 49152:65534 -m state --state 
ESTABLISHED,RELATED,NEW -j ACCEPT
par
-A INPUT -p tcp --sport 49152:65534 --dport 49152:65534 -m state --state 
ESTABLISHED,NEW -j ACCEPT


Donc tu as supprimé RELATED de la liste des états autorisés.


J'espère que c'est cohérent.


C'est cohérent si tu n'utilises pas le suivi de connexion FTP pour ces 
connexions de données passives. Si tu l'utilises, le premier paquet de 
ces connexions sera classé dans l'état RELATED et ne pourra être accepté 
par cette règle. Il faudra donc une autre règle spécifique pour accepter 
ce premier paquet, sinon la connexion échouera.

Re: Port ouvert ou pas ?

[Pascal Hambourg]

Le 09/10/2019 à 13:26, Eric Degenetais a écrit :


localhost est une carte réseau virtuelle qui n'est visible que de
l'ordinateur lui-même.


Non, "localhost" n'est pas une interface mais une adresse IP : 127.0.0.1 
en IPv4 et ::1 en IPv6. Cf. /etc/hosts.



Il n'y a donc pas de soucis : le serveur n'écoute
pas le port 8000 sur les adresses visibles de l'extérieur (carte WiFi,
carte ethernet).


L'explication est fausse, mais la conclusion est juste dans le cas par 
défaut. Cf. mon autre réponse dans ce fil.



Qu'appelez vous l'ip publique ? En ipv4, la configuration la plus courante
est que votre machine reçoit une adresse ip locale délivrée par un routeur
et contrôleur de domaine local (rôle tenu par la box en filaire ou en WiFi


Depuis quand les box internet jouent-elles le rôle de contrôleur de 
domaine ? Tu ne confondrais pas avec serveur DHCP ?



En ipv6 il y a
plus d'adresses possibles, l'ordinateur peut recevoir de son contrôleur de
domaine directement son ip publique.


En IPv6 généralement les hôtes en configuration automatique ne reçoivent 
pas une adresse mais un préfixe /64 diffusé par le routeur, et se 
choisissent une ou plusieurs adresses à l'intérieur de ce préfixe.

Re: Port ouvert ou pas ?

[Pascal Hambourg]

Le 09/10/2019 à 13:22, Alexandre Goethals a écrit :


la commande ss (qui est incluse dans Debian à la place de netstat depuis
Stretch) permet de visualiser les ports d'écoute de la machine.


ss ne remplace pas netstat, c'est une alternative à netstat (pas au sens 
de dpkg). netstat est toujours disponible dans le paquet net-tools. La 
différence est qu'il n'est plus forcément installé par défaut (ça dépend 
de l'environnement de bureau).



Il faut regarder alors quelle est l'adresse
(Local Address) associée au port 8000. Si c'est 127.0.0.1, le socket est
en écoute uniquement sur l'interface locale (loopback).


C'est inexact. La socket écoute sur une adresse, pas une interface. Le 
"weak host model" appliqué par le noyau Linux ne restreint pas l'usage 
d'une adresse locale à l'interface à laquelle elle est affectée.


Il est néanmoins vrai que la plage 127.0.0.0/8 est traitée de façon 
particulière pour se conformer au standard d'internet qui impose que ces 
adresses ne devraient jamais être vues sur un réseau en dehors d'un 
hôte. Mais d'une part cette restriction est appliquée par le noyau au 
niveau du routage des paquets (en empêchant l'envoi ou la réception de 
paquets ayant une adresse source ou destination dans cette plage sur une 
interface non loopback) et non des sockets, et d'autre part le noyau a 
un paramètre net.ipv4.conf..route_localnet qui permet de la 
désactiver sur une interface donnée.

Re: Portable à deuxcartes graphiques NVidia et Amd

[pascal gosse]

Malheureusement le bios du portable en question n'offre pas cette
possibilité (pas de multiplexer autre que logiciel)

Le ven. 11 oct. 2019 à 16:14, ajh-valmer  a écrit :

> J'ai 2 cartes graphiques sur un pc de bureau,
> une intégrée et une Nvidia.
> Je passe par le BIOS pour déclarer l'une ou l'autre.
> Aucun problème.
>
> On Friday 11 October 2019 16:07:29 pascal gosse wrote:
> > Je  fait il y a quelque temps l'acquisition d'un portable Asus
> > FX570zd-dm121 avec "endless os".
> > Je n'avais pas vu que ce portable était équipé de deux cartes graphiques
> > (une NVidia GeForce 1050 Mobile (discrète) et une AMD Radeon Vega 20
> > (intégrée) ce qui n'est pas indiqué dans le descriptif technique) avant
> de
> > me lancer dans une installation en règle d'une testing (avec firmware
> > non-free, la plus récente) via clé USB.
> > Celle-ci s'est passée à peu près correctement jusqu'au passage en mode
> > graphique, après reboot, à la première tentative de login avec lightdm :
> le
> > firmware amd n'avait pas été installé (c'est là que je me suis aperçu du
> > caractère hybride de  l'affichage). Je suis donc allé le chercher sur la
> > clé, l'ai installé et ça a fonctionné.
> > Dans l'euphorie j'ai voulu installer le pilote Nvidia (dans ma grande
> > naïveté et ignorance) et là ...freeze total au login graphique sans
> > possibilité d’accéder à aucune console virtuelle.
> > Après avoir purgé et être repassé par "nouveau"  j'ai découvert
> Bumblebee,
> > Optimus (la carte NVidia en est apparemment pourvue) mais malgré mes
> > tentatives multiples, aucun moyen d'obtenir l'affichage graphique. C'est
> > l'écran noir après login...Mais je peux accéder aux consoles virtiuelles.
> > Il est à noter qu'une personne assure avoir réussi à installer Ubuntu sur
> > ce portable sans problème (sur Linuxfr me semble-t-il).
> > Quelqu'un aurait il un retour avec debian sur ce laptop ? Ou avec le
> couple
> > de cartes NVidia-AMD Radeon (Tout ce que j'ai vu concernait NVidia +
> Intel)
>
>

Portable à deuxcartes graphiques NVidia et Amd

[pascal gosse]

Bonjour la liste

Je  fait il y a quelque temps l'acquisition d'un portable Asus
FX570zd-dm121 avec "endless os".

Je n'avais pas vu que ce portable était équipé de deux cartes graphiques
(une NVidia GeForce 1050 Mobile (discrète) et une AMD Radeon Vega 20
(intégrée) ce qui n'est pas indiqué dans le descriptif technique) avant de
me lancer dans une installation en règle d'une testing (avec firmware
non-free, la plus récente) via clé USB.

Celle-ci s'est passée à peu près correctement jusqu'au passage en mode
graphique, après reboot, à la première tentative de login avec lightdm : le
firmware amd n'avait pas été installé (c'est là que je me suis aperçu du
caractère hybride de  l'affichage). Je suis donc allé le chercher sur la
clé, l'ai installé et ça a fonctionné.
Dans l'euphorie j'ai voulu installer le pilote Nvidia (dans ma grande
naïveté et ignorance) et là ...freeze total au login graphique sans
possibilité d’accéder à aucune console virtuelle.

Après avoir purgé et être repassé par "nouveau"  j'ai découvert Bumblebee,
Optimus (la carte NVidia en est apparemment pourvue) mais malgré mes
tentatives multiples, aucun moyen d'obtenir l'affichage graphique. C'est
l'écran noir après login...Mais je peux accéder aux consoles virtiuelles.

Il est à noter qu'une personne assure avoir réussi à installer Ubuntu sur
ce portable sans problème (sur Linuxfr me semble-t-il).

Quelqu'un aurait il un retour avec debian sur ce laptop ? Ou avec le couple
de cartes NVidia-AMD Radeon (Tout ce que j'ai vu concernait NVidia + Intel)
?
Voire un conseil ?
Merci d'avance

Re: [testing] ecran noir apres mise a jour

[Pascal Obry]

Le samedi 05 octobre 2019 à 14:31 +0200, Gaëtan PERRIER a écrit :
> Effectivement  ça résout le problème. Merci.
> Pas vu de rapport de bug sur le sujet. Tu confirmes ? Je vais en faire quand
> j'aurai 2 minutes.

Pas vu non plus. Je te laisse faire le rapport de bug.

Ça a été aussi un problème transitoire sur Unstable qui est maintenant
résolu depuis que GNOME 3.34 est dispo.

-- 
  Pascal Obry /  Magny Les Hameaux (78)

  The best way to travel is by means of imagination

  http://www.obry.net

  gpg --keyserver keys.gnupg.net --recv-key F949BD3B


signature.asc
Description: This is a digitally signed message part

Re: [testing] ecran noir apres mise a jour

[Pascal Obry]

Oui, j'ai eu ce problème sur plusieurs machines. Je ne peux pas vérifier
mais de mémoire en downgradant gir1.2-gnome-desktop-3.18 en version stable
ça corrige le problème.

Le sam. 5 oct. 2019 à 13:47, Gaëtan PERRIER  a
écrit :

> Le samedi 05 octobre 2019 à 13:33 +0200, Gaëtan PERRIER a écrit :
> > Bonjour,
> >
> > Je viens de faire la mise à jour du jour de testing et quand j'ouvre ma
> > session
> > gnome, j'obtiens un écran noir avec juste le curseur de la souris ...
> > Ça dit quelque chose à quelqu'un ?
> >
> > Gaëtan
>
> Rectification, je n'arrive même plus sur gdm et pas moyen de chopper une
> console avec CTRL+ALT+Fx ... :(
>
> Gaëtan
>

Re: mount: /mnt: /dev/sdb1 n'est pas un périphérique bloc valable

[Pascal Hambourg]

Le 26/09/2019 à 17:09, Sébastien NOBILI a écrit :

26 septembre 2019 16:40 "Matthieu GIRARD-COLIN"  a écrit:

Oui ce message est présent et le lien symbolique existe que le disque soit 
branché ou non,
toutefois il est cassé

# ls -l /sys/class/block/
lrwxrwxrwx 1 root root 0 sept. 26 15:06 sda ->
../../devices/pci:00/:00:01.3/:03:00.1/ata1/host0/target0:0:0/0:0:0:0/block/sda
lrwxrwxrwx 1 root root 0 sept. 26 15:06 sda1 ->
../../devices/pci:00/:00:01.3/:03:00.1/ata1/host0/target0:0:0/0:0:0:0/block/sda/sda1
lrwxrwxrwx 1 root root 0 sept. 26 15:06 sda2 ->
../../devices/pci:00/:00:01.3/:03:00.1/ata1/host0/target0:0:0/0:0:0:0/block/sda/sda2
lrwxrwxrwx 1 root root 0 sept. 26 15:06 sdb1 ->
../../devices/pci:00/:00:01.3/:03:00.0/usb2/2-1/2-1:1.0/host9/target9:0:0/9:0:0:0/block/
db/sdb1




Logiquement le problème
viendrais donc du lien symbolique mais il s'agit d'un fichier protégé en 
écriture même pour root
donc pas moyen de le virer..


Je ne sais pas bien comment /sys est rempli…


/sys n'est pas un système de fichiers classique, c'est une interface 
avec le noyau, comme /proc. Donc il y a eu un méchant bug dans le noyau. 
Je n'avais jamais vu ça.



Il y a des unités Systemd associées :


Rien à voir avec systemd.

Re: Script Iptables pour serveur web Apache2 MySQL ProFTPD avec Port Knocking pour SSH

[Pascal Hambourg]

Le 25/09/2019 à 14:14, G2PC a écrit :



# J'enlève la valeur SYN et l'accès web et terminal fonctionne
correctement.
-A PREROUTING -p tcp -m multiport --dports 22,80,443 -m tcp
--tcp-flags FIN,RST,ACK SYN -j CT --notrack


Cette règle n'a aucune chance de s'appliquer puisque la combinaison
masque/drapeaux est impossible. Tu testes un drapeau qui n'est pas
dans le masque, ça ne peut pas marcher.

Hum. Bon, je te crois, je commente donc cette règle, le temps d'avoir
plus d'informations sur raw et les règles conseillées.
Est ce que le masque avec le SYN (que j'ai retiré) " FIN,SYN,RST,ACK SYN
" est plus cohérente que " FIN,RST,ACK SYN " ?


Bien sûr. C'est de l'algèbre booléenne de base. La seconde liste de 
--tcp-flags doit être incluse dans la première liste.
"FIN,RST,ACK SYN" signifie "conserver les valeurs des drapeaux FIN, RST 
et ACK et mettre à 0 les autres (dont SYN), puis renvoyer vrai si dans 
le résultat SYN=1 (ce qui est impossible) et tous les autres à 0".



Comme dit, avec le SYN en deuxième position, les accès sont coupés une
fois que je place la règle *filter


L'état UNTRACKED doit interférer soit avec le filtrage en entrée, soit 
avec le filtrage en sortie. Si un paquet SYN a été classé UNTRACKED, 
alors les paquets suivants de la poignée de main (SYN+ACK sortant et ACK 
entrant) sont classés par défaut dans l'état INVALID.



# Je ne sais pas si il est nécessaire d'autoriser le loopback vers
l'extérieur, voir à trouver un exemple.


Cette phrase n'a aucun sens puisque le trafic envoyé sur l'interface
de loopback ne va pas vers l'extérieur mais revient.


Tu parles de mon commentaire concernant la règle OUTPUT qui n'a pas de
sens, dès lors ?


Je parle de la phrase ci-dessus que j'ai laissée.


-A OUTPUT -m conntrack ! --ctstate INVALID -j ACCEPT


Typiquement, le paquet de réponse SYN/ACK à un paquet SYN dans l'état
UNTRACKED (à cause de -j CT --notrack) serait classé par défaut dans
l'état INVALID. Je ne connais pas l'interaction éventuelle avec SYNPROXY.


Je ne sais pas comment appréhender ce retour.
Le -j CT --notrack est dans la ligne qui a été désactivée dans la table *raw
A suivre.


Tu pourrais accepter les paquets SYN+ACK sortants ayant un des ports 
source concernés par le SYNPROXY.



# Autoriser les connexions DNS.
-A INPUT -p tcp --dport 53 -j ACCEPT


La machine fait serveur DNS pour l'extérieur ?


Je ne pense pas ? C'est à dire, est ce qu'elle transmet des informations
vers un autre service extérieur ?


C'est-à-dire qu'elle répond à des requêtes DNS.


Hormis les pages web, non, donc, si je t'entend bien, je peux supprimer
les règles DNS ?


Il vaut mieux ne pas supprimer les règles qui acceptent les requêtes DNS 
en sortie.



Qu'est-ce que la connexion fstp ?

Oups ! sFTP


Ça utilise SSH, donc rien à voir avec le protocole FTP.


-A OUTPUT -p tcp --sport 21 -m state --state ESTABLISHED -j LOG_ACCEPT
-A OUTPUT -p tcp --sport 49152:65534 --dport 49152:65534 -m state
--state ESTABLISHED -j LOG_ACCEPT


Inutiles puisque ces paquets ont déjà été acceptés par la règle
générique qui autorise les connexions déjà établies.
De toute façon, serait-il vraiment nécessaire de loguer ces paquets ?


ça fait beaucoup de paquets à loguer ?


Ça loguerait tous les paquets sortants des connexions de commande et de 
données FTP, soit grosso modo un paquet par commande FTP et un paquet 
par bloc de 1400 octets de données de fichier téléchargé ou de contenu 
de répertoire lu. Je ne vois pas l'intérêt, loguer le premier paquet suffit.



Le client me dit ceci, on observe que j'arrive bien à me connecter la
première fois, puis, sur un second compte il n'arrive pas à récupérer le
contenu du dossier.
Je me reconnecte au second compte, et, il arrive alors a récupérer le
contenu du dossier. Vraiment étrange.
Statut :    Connexion à 139.99.173.195:21...
Statut :    Connexion établie, attente du message d'accueil...
Statut :    Initialisation de TLS...
Statut :    Vérification du certificat...
Statut :    Connexion TLS établie.


Note : si tu utilises TLS avec FTP, alors le module de suivi de 
connection nf_conntrack mentionné dans mon message précédent est aveugle 
et inutile.



Statut :    Récupération du contenu du dossier...
Commande :    PWD
Réponse :    257 "/" est le répertoire courant
Commande :    TYPE I
Réponse :    200 Type paramétré à I
Commande :    PASV
Réponse :    227 Entering Passive Mode (139,99,173,195,202,139).
Commande :    LIST
Erreur :    Connection interrompue après 20 secondes d'inactivité


Il faudrait vérifier le port source utilisé par le client pour la 
connexion de données servant au listage. Attention : si le client est 
derrière un dispositif NAT (routeur, box), ce dernier peut modifier le 
port source à la volée. Regarde dans les logs générés par iptables.



-A INPUT -p tcp --dport 21 -m state --state NEW,ESTABLISHED -j
LOG_ACCEPT
-A INPUT -p tcp --sport 49152:65534 --dport 49152:65534 -m state
--state ESTABLISHED,RELATED,NEW -j LOG_ACCEPT


Côté serveur, tu ne 

Re: Raid 1

[Pascal Hambourg]

Le 25/09/2019 à 09:25, Erwan RIGOLLOT a écrit :


Un raid 1 sur 3 disques fait que les 3 disques ont les données et t'autorise 
donc à perdre jusqu'à 2 disques sans perte de données mais dans ce cas les 3 
disques fonctionneront en permanence et s'userons mais tu n'auras pas de temps 
de reconstruction en cas de perte d'un disque.


Si, il y aura de toute façon un temps de reconstruction quand le disque 
défaillant sera remplacé.


PS : bizarre que ce message soit arrivé plusieurs heures après avoir été 
envoyé.

Re: Raid 1

[Pascal Hambourg]

Le 25/09/2019 à 12:20, Pascal Hambourg a écrit :

Le 25/09/2019 à 11:39, steve a écrit :


L'argument du spare qui ne travaille pas, et donc ne s'use pas, est un
bon argument, par exemple.


Oui. Du moins qui s'use moins que s'il travaillait, mais plus que s'il 
était sur une étagère. Il reste sous tension et soumis à la chaleur de 
la machine.


Un autre argument est le temps de reconstruction. Avec les disques de 
très grande capacité (qui augmente plus vite que le débit), la 
reconstruction prend de plus en plus de temps - plusieurs heures - et le 
risque que le seul disque actif restant, qui a subi la même usure, 
flanche à son tour avant la fin n'est pas négligeable, d'autant plus 
qu'il est plus fortement sollicité lors de la reconstruction qu'en temps 
normal.


Et si la performance importe, le RAID 1 peut faire de la répartition de 
charge en lecture entre tous les disques actifs.

Re: Raid 1

[Pascal Hambourg]

Le 25/09/2019 à 11:39, steve a écrit :

Le 25-09-2019, à 10:12:49 +0200, Pascal Hambourg a écrit :


Le 25/09/2019 à 09:07, steve a écrit :

Bonjour,

J'ai trois disques que je souhaiterais monter en Raid 1.

J'ai le choix entre créer une grappe de deux disque plus un spare ou
alors créer une grappe de trois disques sans spare.

Qu'est-ce qui est le mieux ?


Le mieux pour quoi ?


Pour moi.


Je parlais du critère d'optimisation choisi.


L'argument du spare qui ne travaille pas, et donc ne s'use pas, est un
bon argument, par exemple.


Oui. Du moins qui s'use moins que s'il travaillait, mais plus que s'il 
était sur une étagère. Il reste sous tension et soumis à la chaleur de 
la machine.


Un autre argument est le temps de reconstruction. Avec les disques de 
très grande capacité (qui augmente plus vite que le débit), la 
reconstruction prend de plus en plus de temps - plusieurs heures - et le 
risque que le seul disque actif restant, qui a subi la même usure, 
flanche à son tour avant la fin n'est pas négligeable, d'autant plus 
qu'il est plus fortement sollicité lors de la reconstruction qu'en temps 
normal.

Re: Script Iptables pour serveur web Apache2 MySQL ProFTPD avec Port Knocking pour SSH

[Pascal Hambourg]

Le 24/09/2019 à 23:46, G2PC a écrit :


Par exemple, pour ProFTPD, il me semble avoir configuré correctement le
service, mais, le client FileZilla ne semble pas réussir à se connecter
lors de toutes ses tentatives.
Actuellement, j'arrive régulièrement à me connecter au client FTP, mais,
pas à 100%.
Je précise, ce n'est pas la connexion qui semble bloquer
occasionnellement, mais, la lecture des dossiers une fois connecté,
d'après ce que je lis sur FileZilla.


Donc les connexions de données avec les ports de destination dynamiques.
Est-ce que tu as chargé le module de suivi de connexion FTP 
nf_conntrack_ftp ?
Si oui, est-ce que tu as réglé l'option nf_conntrack_helper du module 
nf_conntrack à 1 puisque je ne vois pas de règle avec CT --helper pour 
affecter explicitement le helper ftp aux connexions de commande FTP ?



*raw

# Anti DDOS.
# Les paquets TCP avec le flag SYN à destination des ports 22,80 ou 443 ne 
seront pas suivi par le connexion tracker et donc traités plus rapidement.
## Les pages ne chargent plus avec cette règle de décommentée tout comme la 
connexion SSH devient impossible !


En temps normal, ce n'est pas seulement le paquet SYN mais tous les 
paquets suivants (entrants et sortants) qu'il faut exclure du suivi de 
connexion et accepter. Par contre j'ai vu que tu utilises SYNPROXY qui 
interagit avec le suivi de connexion, mais je ne connais pas bien.



# J'enlève la valeur SYN et l'accès web et terminal fonctionne correctement.
-A PREROUTING -p tcp -m multiport --dports 22,80,443 -m tcp --tcp-flags 
FIN,RST,ACK SYN -j CT --notrack


Cette règle n'a aucune chance de s'appliquer puisque la combinaison 
masque/drapeaux est impossible. Tu testes un drapeau qui n'est pas dans 
le masque, ça ne peut pas marcher.



# On pourrait interdire le ping avec icmp directement en PREROUTING.
# Pour le moment je vais l'interdire par défaut depuis *filter et autoriser le 
ping aux services OVH.
# -A PREROUTING -p icmp -j DROP


Erreur fréquente : ICMP, ce n'est pas seulement le ping mais aussi des 
messages d'erreur qu'il vaut mieux ne pas bloquer si on veut que les 
communications marchent bien.



# Pas de filtrage sur l'interface de loopback.

# Le serveur ne doit pas avoir de soucis à communiquer avec lui-même au niveau 
des services internes.
# Accepter toutes les connexions de la machine locale pour permettre aux 
services de communiquer entre eux.
-A INPUT -i lo -j ACCEPT
# Par la suite, la règle par défaut va DROP sur tous les OUTPUT non autorisés.
# Je ne sais pas si il est nécessaire d'autoriser le loopback vers l'extérieur, 
voir à trouver un exemple.


Cette phrase n'a aucun sens puisque le trafic envoyé sur l'interface de 
loopback ne va pas vers l'extérieur mais revient.



# L'absence d'autorisation en sortie peut t'elle interférer avec certains 
services attendant une communication en sortie de loopback ?
# -A OUTPUT -o lo -j ACCEPT


Evidemment ça interfère. Tout paquet envoyé sur l'interface de loopback 
passe successivement par les chaînes OUTPUT, POSTROUTING, PREROUTING et 
INPUT et doit être accepté dans toutes pour arriver à destination.



-A OUTPUT -m conntrack ! --ctstate INVALID -j ACCEPT


Typiquement, le paquet de réponse SYN/ACK à un paquet SYN dans l'état 
UNTRACKED (à cause de -j CT --notrack) serait classé par défaut dans 
l'état INVALID. Je ne connais pas l'interaction éventuelle avec SYNPROXY.




# Autoriser les services web.

# Autoriser les connexions DNS.
-A INPUT -p tcp --dport 53 -j ACCEPT


La machine fait serveur DNS pour l'extérieur ?


-A INPUT -p udp --sport 53 -j ACCEPT


Cette règle est une faille de sécurité en plus d'être inutile.


# Configurer le FTP et le pare-feu pour utiliser la plage de ports passifs 
entre 49152-65534 proposée par IANA.
# Noter que la connexion de semble pas s'établir à chaque fois et qu'il est 
nécessaire de retenter la connexion.
# Noter que la connexion fstp n'est pas configurée actuellement. A faire !


Qu'est-ce que la connexion fstp ?


-A OUTPUT -p tcp --sport 21 -m state --state ESTABLISHED -j LOG_ACCEPT
-A OUTPUT -p tcp --sport 49152:65534 --dport 49152:65534 -m state --state 
ESTABLISHED -j LOG_ACCEPT


Inutiles puisque ces paquets ont déjà été acceptés par la règle 
générique qui autorise les connexions déjà établies.

De toute façon, serait-il vraiment nécessaire de loguer ces paquets ?


-A INPUT -p tcp --dport 21 -m state --state NEW,ESTABLISHED -j LOG_ACCEPT
-A INPUT -p tcp --sport 49152:65534 --dport 49152:65534 -m state --state 
ESTABLISHED,RELATED,NEW -j LOG_ACCEPT


Côté serveur, tu ne maîtrises pas la plage de ports du client. 
Restreindre les ports source du client à la même plage que celle du 
serveur est abusif.



# Autoriser les connexions au serveur web Apache2.
-A INPUT -p tcp --dport 80 -j ACCEPT
-A OUTPUT -p tcp --dport 80 -j ACCEPT
-A INPUT -p tcp --dport 443 -j ACCEPT
-A OUTPUT -p tcp --dport 443 -j ACCEPT


Maintenant que ces paquets sont acceptées, toutes les règles suivantes 

Re: Raid 1

[Pascal Hambourg]

Le 25/09/2019 à 10:14, kaliderus a écrit :



Si tu veux de la redondance (donc du Raid 1),


Non. On peut aussi avoir de la redondance avec du RAID 4, 5, 6 ou 10.


il te faut un disque de parité.


Non, pas forcément. Les RAID 1 et 10 n'ont pas de parité. Seul le RAID 4 
a un disque de parité dédié. Les RAID 5 et 6 ont une parité répartie sur 
tous les disques actifs.



" une grappe de trois disques sans spare " je ne sais pas trop ce que
c'est ; à priori du Raid 0


Tu confirmes que tu ne sais pas de quoi tu parles et tu racontes 
n'importe quoi.

Re: Raid 1

[Pascal Hambourg]

Le 25/09/2019 à 09:07, steve a écrit :

Bonjour,

J'ai trois disques que je souhaiterais monter en Raid 1.

J'ai le choix entre créer une grappe de deux disque plus un spare ou
alors créer une grappe de trois disques sans spare.

Qu'est-ce qui est le mieux ?


Le mieux pour quoi ?
Le mieux dans l'absolu, ça n'existe pas.

Re: Envoyer mail avec autre IP que le sien

[Pascal Hambourg]

Le 23/09/2019 à 16:32, ajh-valmer a écrit :

On Saturday 21 September 2019 13:28:24 Pascal Hambourg wrote:


Pour cacher ton identité (mais pourquoi ne pas avoir le courage de ses
opinions ?
pour moi c'est un comportement adulte que de les assumer
nominativement) :


Ce n'est pas moi qui ai écrit cela. Merci d'attribuer correctement les 
citations.

Re: Faut t'il bloquer le Multicast - IGMP avec Iptables

[Pascal Hambourg]

Le 18/09/2019 à 22:48, Jean-Michel a écrit :


Personnellement, je trouve qu'un DROP par défaut de tout en fin 
de chaîne (ou en action par défaut) va très bien et évite de surcharger 
inutilement les règles.


Une règle DROP en fin de chaîne n'est pas commode si on veut pouvoir 
ajouter des règles ACCEPT à la volée. Je préfère régler la politique par 
défaut à DROP.


Pour l'IPv6, le jour où tu le déploieras, en effet, comme l'a rappelé 
Pascal, il faut faire attention à bien autoriser le protocole NDP qui 
reprend, entre autre, le rôle d'ARP en IPv4 et qui s'appuie sur de 
l'ICMPv6. Autant en IPv4 tu ne peux pas bloquer l'ARP avec iptables, 


Mais on peut assez souvent oublier d'autoriser le trafic DHCP. Par 
chance (?), les clients DHCP comme dhclient injectent et capturent les 
paquets directement sur l'interface réseau sans passer par la couche IP, 
ce qui court-circuite iptables.


autant en IPv6 c'est assez facile de se couper les pattes en bloquant 
NDP ou plutôt en oubliant de l'autoriser
NDP repose sur des paquets ICMPv6 échangés localement en multicast 
certes, mais surtout des paquets ICMPv6 particuliers.
Personnellement, je n'autorise pas le multicast sur mes règles ip6tables 
mais uniquement les paquets ICMPv6 dont les caractéristiques concordent 
précisément avec les paquets attendus (adresses fe80::, HL = 255, types 
& codes qui vont bien, etc...).


Attention, les paquets NDP peuvent contenir des adresses non link-local.

Autoriser RELATED sans restriction est une mauvaise habitude de beaucoup 
de docs en ligne et la source de problèmes de sécurité importants même 
si depuis la version 4.7 du kernel les helpers ne sont plus activés par 
défaut pour éviter ce problème.


Pour moi ce sont deux problèmes distincts. Certes un helper peut être 
abusé donc l'activer uniquement sur les connexions qui en ont besoin 
renforce la sécurité, mais cela n'empêche pas d'en abuser lorsqu'il est 
activé. Par exemple un paquet dans l'état RELATED lié au helper ftp 
(initiant une connexion de données FTP) ne devrait être accepté que si 
ses caractéristiques intrinsèques (ports source et destination, 
éventuellement adresses IP source et destination) sont conformes au 
trafic attendu :
- dans le cas d'une connexion active, port source 20 et port destination 
dans la plage de ports actifs autorisée pour le client ;
- dans le cas d'une connexion passive, port source > 1023 et port 
destination dans la plage de ports passifs définie dans la configuration 
du serveur FTP.


En revanche, c'est mieux de le laisser 
autoriser pour l'ICMP.


Si on est préoccupé à ce point par la sécurité, alors on ne devrait même 
pas accepter tous les types ICMP dans l'état RELATED. Par exemple le 
type "source quench" a été reconnu comme dangereux (déni de service) et 
officiellement abandonné, et le type "redirect" peut être exploité pour 
détourner du trafic. Pour ma part je n'autorise que les types d'erreur 
"destination unreachable", "time exceeded" et "parameter problem".


De plus, il faudra activer le helper FTP pour ton serveur FTP. Une doc 
ici sur le sujet : 
https://gist.github.com/azlux/6a70bd38bb7c525ab26efe7e3a7ea8ac. Cela te 
permettra en plus de fermer le port TCP/20


On n'a jamais eu besoin d'ouvrir le port TCP 20 pour FTP. C'est 
uniquement un port source de connexions sortantes.

Re: Faut t'il bloquer le Multicast - IGMP avec Iptables

[Pascal Hambourg]

Le 21/09/2019 à 12:39, G2PC a écrit :


# Mon serveur ne retrouve pas les deux lignes de configuration suivantes, que 
je commente. A SUIVRE !
# sysctl: cannot stat /proc/sys/net/netfilter/nf_conntrack_tcp_loose: Aucun 
fichier ou dossier de ce type
# sysctl: cannot stat /proc/sys/net/netfilter/nf_conntrack_max: Aucun fichier 
ou dossier de ce type


Ces sysctls n'existent que si le module nf_conntrack_ipv4 ou 
nf_conntrack_ipv6 est chargé, ce qui est fait automatiquement à la 
création de la première règle utilisant le suivi de connexion (state, 
conntrack, connmark...) ou au chargement de la table nat.


Pour pouvoir les initialiser via /etc/sysctl{,.d/*}.conf, il faut 
charger un de ces modules via /etc/modules{,-load.d/*.conf}.

Re: Envoyer mail avec autre IP que le sien

[Pascal Hambourg]

Le 21/09/2019 à 11:22, ajh-valmer a écrit :

On Saturday 21 September 2019 00:10:55 Pascal Hambourg wrote:

Le 20/09/2019 à 10:27, ajh-valmer a écrit :

Est-il possible et si oui une piste,
afin d'envoyer un mail avec numéro IP autre que le sien :



Pour pouvoir répondre, il faudrait que tu définisses précisément ce que
tu entends par là :


Que le n° IP de ton FAI ne figure pas dans le mail reçu
par le destinataire, c'est à dire un IP LAN (192.168...)
ou un autre.


Qu'appelles-tu "numéro IP de ton FAI" ?
S'il s'agit de l'adresse IP publique attribuée par le FAI qui fournit 
l'accès internet "primaire" (pas un FAI par VPN ou un hébergeur), c'est 
possible en passant par un intermédiaire qui ne transmet pas l'adresse 
IP source dans les en-têtes techniques : certains prestataires de 
courrier, VPN, proxy anonymisant, TOR...



Ça peut paraitre bizarre, mais parfois c'est bien utile,



Utile à quoi ? :


Cacher au destinataire qui a envoyé le mail,


Quel rapport avec l'anti-spam (à part pour s'y soustraire) ?

Re: Envoyer mail avec autre IP que le sien

[Pascal Hambourg]

Le 20/09/2019 à 10:27, ajh-valmer a écrit :


Est-il possible et si oui une piste,
afin d'envoyer un mail avec numéro IP autre que le sien,


Pour pouvoir répondre, il faudrait que tu définisses précisément ce que 
tu entends par là.



Ça peut paraitre bizarre, mais parfois c'est bien utile,


Utile à quoi ?


comme avoir un mail anti-spams.


Je ne vois pas le rapport. Merci d'expliquer.

Re: Faut t'il bloquer le Multicast - IGMP avec Iptables

[Pascal Hambourg]

Le 16/09/2019 à 12:57, G2PC a écrit :

Bonjour,

Je ne pense pas en avoir besoin pour le moment, d'utiliser le multicast, il me 
semble de ce fait inutile de l'autoriser dans ma configuration Iptables ?


Il ne s'agit pas de penser mais de savoir. Si tu n'utilises pas le 
multicast, tu n'as pas besoin de l'autoriser.



Par contre, je trouve deux types de règles via mes recherches, et, je ne suis 
pas très sur de la bonne façon de l'interdire.


Il suffit de ne pas l'autoriser. Tu interdis tout par défaut et 
n'autorises que ce dont tu as besoin, n'est-ce pas ?



# DROP IGMP :
# Également pour bloquer le multicast ? Quelle méthode préférer, les deux ?


IGMP n'est pas le multicast, ce n'est que le protocole de gestion du 
multicast. Tous les flux multicast ne font pas forcément l'objet d'un 
abonnement avec IGMP. J'ignore si tout le trafic IGMP est aussi en 
multicast.


Note que si tu fais aussi du filtrage pour IPv6, réfléchis à deux fois 
avant de bloquer du trafic multicast. Certains flux multicast sont 
indispensables au bon fonctionnement d'IPv6.

Re: Dnsmasq: interdire /etc/hosts aux requètes provenant d'un VLAN particulier

[Pascal Hambourg]

Le 16/09/2019 à 08:26, Olivier a écrit :

Ma question n'était sans doute pas très bien formulée.

Elle ne portait pas sur la façon de router le DNS, mais d'avoir plusieurs
résolutions locales différenciées.


Si, c'était très clair (excepté le titre qui n'est pas terrible). Ce que 
tu veux faire s'appelle du "split DNS". Dans BIND 9, cela correspondrait 
à des "vues" (views). Malheureusement je ne connais pas bien dnsmasq et 
ignore s'il possède une fonctionnalité équivalente.

Re: Resolvconf/Openresolv

[Pascal Hambourg]

Le 10/09/2019 à 17:28, Olivier a écrit :


1. Il m'est dernièrement arrivé de modifier le contenu de mon fichier
/etc/resolv.conf avec la commande resolvconf.
Plus précisément:
echo "nameserver 192.168.3.45
nameserver 192.168.8.10
search example.com" | sudo resolvconf -a eth0.inet

(Une simple était peut-être suffisante mais pour la beauté du geste, j'ai
utilisé resolvconf).


Une simple quoi ? Redirection dans /etc/resolv.conf ? Non, ce n'est pas 
une bonne idée de modifier directement resolv.conf lorsque resolvconf 
est installé. D'une part ces modifications peuvent être écrasées par 
resolvconf, d'autre part lors de son installation resolvconf remplace le 
fichier par un lien symbolique qui pointe vers /run/resolvconf, 
emplacement situé en tmpfs donc non persistant.



Pourquoi ce paramètre eth0.inet est-il nécessaire ?


Parce que c'est ainsi que resolvconf fonctionne : il associe une 
configuration DNS a une interface. Cela lui permet de gérer les 
configurations DNS associées à plusieurs interfaces avec un système de 
priorité (au lieu que la plus récente écrase la précédente), et de 
supprimer la configuration d'une interface lorsque cette dernière est 
désactivée.



Une machine a-t-elle plusieurs instances de daemon de résolution de noms de
domaine ?


Il n'y a pas forcément de démon de résolution de noms DNS. Dans Debian, 
c'est juste une bibliothèque partagée utilisée par les programmes et qui 
utilise /etc/resolv.conf.



2. Raspbian installe dhcpcd et openresolv.
Comment se comparent resolvconf et openresolv ?


Je n'ai jamais utilisé openresolv mais il est marqué comme fournissant 
resolvconf (Provides: resolvconf), donc son fonctionnement externe doit 
être suffisamment proche pour pouvoir le remplacer de façon transparente 
pour les programmes qui l'utilisent. Par contre ses options de 
configuration semblent différentes.

Re: Install buster sur lvm chiffré complètement foirée

[Pascal Hambourg]

Le 10/09/2019 à 16:33, Daniel Caillibaud a écrit :


Il n'y a pas de partition /boot non chiffrée ? Risqué, car impossible de
démarrer au moindre problème.


Même avec une partition non chiffrée ça démarre pas ;-)


Mais si, ça démarre. Jusqu'à l'initramfs. Evidemment il n'y a pas de 
raison que ça aille plus loin puisque le problème ne vient pas de la 
lecture de /boot par GRUB mais du montage de la racine par l'initramfs.



Ouais, une : comme tu n'as pas créé de volume chiffré avec
l'installateur, il n'a pas inclus ce qu'il faut (paquets
cryptsetup-initramfs et cryptsetup-run, fichier /etc/crypttab) pour
pouvoir démarrer avec une racine chiffrée.

Démarre avec l'installateur en mode rescue, lance un shell sur la racine
et vérifie tout ça.


Après une réinstall avec un /boot séparé non chiffré ça bootait toujours pas, 
j'avais bien le
menu grub mais ensuite il me demandait pas de passphrase (et évidemment 
trouvait pas ses
volumes lvm).


C'est bien la preuve que l'initramfs est incomplet.


J'avais bien cru avoir trouvé en voyant qu'il manquait le /etc/crypttab, mais
l'ajouter ne change rien.


Tu as regénéré l'initramfs ensuite ? Sinon ça ne sert à rien.


Et cette fois j'avais choisi l'option "tout mettre dans l'initramfs" (plutôt que 
"seulement ce
qui est nécessaire pour cette machine").


Je ne pense pas que ça change quelque chose à ton problème. Par contre 
l'initramfs réduit (MODULES=dep dans /etc/initramfs-tools/) est un piège 
à con qui risque d'empêcher le démarrage en cas de changement quelconque 
de la configuration matérielle. En général on n'est pas à quelques Mo près.



J'ai vérifié, il a bien les paquets cryptsetup-initramfs et cryptsetup-run 
installés
(avec cryptsetup-bin, les 3 étants des dépendances de "cryptsetup"), mais ça 
veut toujours pas…


Et /etc/crypttab est présent et contient ce qu'il faut pour ouvrir le 
volume chiffré ? Tu as vérifié que l'initramfs contient bien les boot 
scripts de cryptsetup ? Au cas où, tu as ajouté, l'option "initramfs" 
pour forcer l'ouverture du volume dans l'initramfs (et regénéré 
l'initramfs ensuite) ?

Re: Install buster sur lvm chiffré complètement foirée

[Pascal Hambourg]

Le 10/09/2019 à 12:44, Daniel Caillibaud a écrit :


- pas trouvé comment préciser à l'installeur que j'ai un clavier bépo


Peut-être en lançant l'installateur en mode expert ?


- mis des plombes à trouver comment l'installer dans un LV chiffré (sans 
détruire tout le VG
   existant),


Effectivement la réutilisation d'un volume chiffré existant est une 
grosse lacune de l'installateur. Il peut activer les ensembles RAID et 
volumes logiques LVM existants mais pas les volumes chiffrés...



   faut commencer l'install, aller jusqu'au partitonnement manuel, sortir de
   l'installeur (ouvrir une autre console) pour déchiffrer le PV manuellement 
(cryptsetup open
   --type luks /dev/sdxN monVolumeChiffré && vgchange -ay) puis retourner dans 
l'installeur,
   gestion lvm, détruire le lv root existant et le recréer (sinon impossible de 
l'utiliser, il
   me le propose pas dans les choix) et l'utiliser comme /, ouf !
- c'était pas fini, grub install plante plus loin sans dire pourquoi
=> reboot sur la clé en rescue, chroot dans le lv root de buster fraichement 
installé puis
grub-install me dit qu'il veut dans /etc/default/grub la ligne
GRUB_ENABLE_CRYPTODISK=y


Il n'y a pas de partition /boot non chiffrée ? Risqué, car impossible de 
démarrer au moindre problème.



Je l'ajoute, grub-intstall ok mais au reboot
- clavier qwerty pour saisir la passphrase, fallait deviner


Normal dans GRUB. Configurer le clavier dans GRUB semble compliqué, je 
n'ai jamais essayé. Encore un autre inconvénient du /boot chiffré.



- après pass ok, j'ai bien le menu grub mais il trouve pas le lv root
   et m'affiche l'erreur en boucle...

J'ai bien tenté d'éditer l'entrée grub pour préciser du /dev/vg/lv plutôt que
le /dev/mapper--vg-lv mais ça change rien...


Pas une bonne idée de toute façon, c'est avec la forme 
root=/dev/mapper/vg-lv que l'initramfs identifie que la racine est un 
volume logique LVM.



Une idée ?


Ouais, une : comme tu n'as pas créé de volume chiffré avec 
l'installateur, il n'a pas inclus ce qu'il faut (paquets 
cryptsetup-initramfs et cryptsetup-run, fichier /etc/crypttab) pour 
pouvoir démarrer avec une racine chiffrée.


Démarre avec l'installateur en mode rescue, lance un shell sur la racine 
et vérifie tout ça.



Par ailleurs, j'espère pouvoir récupérer mon 2e disque, mais j'ai pas encore 
trouvé comment (il
voit un PV mais me dit qu'il n'y a pas de vg dedans), je suis aussi preneur de 
conseil.


C'est un autre VG que celui qui contient la racine chiffrée ?

Re: /etc/network/interfaces et inet6

[Pascal Hambourg]

Le 04/09/2019 à 11:26, BERTRAND Joël a écrit :



Si le problème vient de la DAD tu peux essayer de la désactiver avec

   dad-attemps 0


Directement dans le fichier interfaces ?


Oui, dans la définition inet6 de br0. Cf. man interfaces.

Re: /etc/network/interfaces et inet6

[Pascal Hambourg]

Le 04/09/2019 à 11:21, BERTRAND Joël a écrit :

net.ipv6.conf.all.disable_ipv6 = 0
net.ipv6.conf.br0.disable_ipv6 = 0
net.ipv6.conf.default.disable_ipv6 = 0
net.ipv6.conf.eth0.disable_ipv6 = 0
net.ipv6.conf.eth1.disable_ipv6 = 0
net.ipv6.conf.eth2.disable_ipv6 = 0
net.ipv6.conf.lo.disable_ipv6 = 0
net.ipv6.conf.tap0.disable_ipv6 = 0
net.ipv6.conf.tap1.disable_ipv6 = 1
net.ipv6.conf.tap2.disable_ipv6 = 1

Je me demande bien d'où proviennent les deux dernières lignes,
d'ailleurs...


Peut-être du pontage, pour éviter que les interfaces membres d'un pont 
se ramassent des adresses IPv6 (link local ou autoconf).

Re: /etc/network/interfaces et inet6

[Pascal Hambourg]

Le 04/09/2019 à 10:06, BERTRAND Joël a écrit :


sept. 04 05:35:16 rayleigh ifup[1368]: Cannot find device "tap1"
sept. 04 05:35:16 rayleigh ifup[1368]: interface tap1 does not exist!
sept. 04 05:35:16 rayleigh ifup[1368]: Cannot find device "tap2"
sept. 04 05:35:16 rayleigh ifup[1368]: interface tap2 does not exist!
sept. 04 05:35:17 rayleigh ifup[1368]: Waiting for br0 to get ready
(MAXWAIT is 32 seconds).
sept. 04 05:35:33 rayleigh ifup[1368]: Waiting for DAD... Timed out
sept. 04 05:35:33 rayleigh ifup[1368]: ifup: failed to bring up br0
sept. 04 05:35:33 rayleigh systemd[1]: networking.service: Main process
exited, code=exited, status=1/FAILURE
sept. 04 05:35:33 rayleigh systemd[1]: networking.service: Failed with
result 'exit-code'.
sept. 04 05:35:33 rayleigh systemd[1]: Failed to start Raise network
interfaces.

tap1 et tap2 n'existent pas encore (il faut du temps pour qu'ils
montent).


Déjà, ça ce n'est pas terrible. A mon avis les ports ne devraient pas 
être spécifiés s'ils n'existent pas à la création du pont.



Mais visiblement, ce qui ne lui plaît pas, c'est "Waiting for
DAD... Timed out". Or je suis en adressage IPv6 _statique_. Je ne vois
pas trop ce que les paquets DAD viennnt faire ici.


Pourquoi la DAD ne s'appliquerait-elle pas en statique ?
Si le problème vient de la DAD tu peux essayer de la désactiver avec

  dad-attemps 0

Re: Configuration de la variable d'environnement HOME

[Pascal Hambourg]

Le 31/08/2019 à 14:31, contact a écrit :


j'ai crée l'utilisateur TEST avec adduser dans la configuration 
initiale. Et ce dernier fonctionne parfaitement avec mon disque d'origine.


j'avais bien vu cette présente de /home/test dans /etc/passwd

ce qui me surprend c'est que le changement dans le fstab de ma partition 
home entraine ce problème.


Le nouveau disque est-il correctement monté ?
Le répertoire test/ a-t-il été correctement créé à la racine du nouveau 
disque, avec les bons propriétaires et permissions ?

Re: Question

[Pascal Hambourg]

Le 21/08/2019 à 20:48, Pascal Hambourg a écrit :

Le 21/08/2019 à 15:33, steve a écrit :


Oui. Par défaut, Debian ne demande plus de mot de passe root à
l'installation


Ça sort d'où ? Je viens de faire plusieurs installations de Buster, et 
il m'est systématiquement proposé de définir un mot de passe root.


Des informations parvenues à ma connaissance suggèrent que le 
comportement ci-dessus pourrait être celui de l'installateur Calamares 
[1] inclus dans l'environnement graphique des images Debian live [2].


Je n'utilise pas Debian live et je ne vais pas télécharger une image de 
plus de 2 Go juste pour vérifier. Quelqu'un peut-il confirmer ?


En revanche l'installateur Debian traditionnel (debian-installer) inclus 
dans les images d'installation - et peut-être dans le menu de démarrage 
des images live, à confirmer - continue de demander un mot de passe root 
optionnel, que ce soit en mode normal ou expert. En mode expert la 
création d'un compte utilisateur normal est aussi optionnelle.


[1] <https://packages.debian.org/buster/calamares>
[2] 
<https://www.debian.org/releases/stable/amd64/release-notes/ch-whats-new.fr.html#debian-live>

Re: DNS : pas de résolution en local

[Pascal Hambourg]

Le 21/08/2019 à 23:17, Migrec a écrit :


La livebox fait DHCP (décodeur TV branché dessus via du CPL) et elle 
indique son IP interne (192.168.1.1) comme DNS lorsque le serveur reçoit 
son bail DHCP.
Le serveur fait du DHCP/DNS pour le réseau local. Son IP est donc dans 
le resolv.conf.


Ça me paraissait pas mal car si mon serveur DNS est down, celui de la 
box fait au moins la résolution "externe", non ?


Dans ce cas il faut faire en sorte que le DNS de la box soit positionné 
après le DNS local dans resolv.conf, et ce de façon fiable (donc pas en 
réordonnant les interfaces). Il me semble que resolvconf qui gère ton 
resolv.conf a des possibilités dans ce sens.

Re: Question

[Pascal Hambourg]

Le 22/08/2019 à 10:36, steve a écrit :

Le 21-08-2019, à 20:48:14 +0200, Pascal Hambourg a écrit :


Le 21/08/2019 à 15:33, steve a écrit :


Oui. Par défaut, Debian ne demande plus de mot de passe root à
l'installation


Ça sort d'où ? Je viens de faire plusieurs installations de Buster, et 
il m'est systématiquement proposé de définir un mot de passe root.


En effet. Mais, tiré du manuel d'installation:

6.3.2.1. Mot de passe pour « Root »

Dans le cas où vous ne saisissez pas de mot de passe pour le
superutilisateur, ce compte sera désactivé.


C'est très différent de "Par défaut, Debian ne demande plus de mot de 
passe root à l'installation".

Re: Question

[Pascal Hambourg]

Le 21/08/2019 à 21:03, Bernard Schoenacker a écrit :



De: "Pascal Hambourg" 

Le 21/08/2019 à 15:33, steve a écrit :


Oui. Par défaut, Debian ne demande plus de mot de passe root à
l'installation 


Ça sort d'où ? Je viens de faire plusieurs installations de Buster,
et il m'est systématiquement proposé de définir un mot de passe root.


bonjour, si tu es en mode avancé


Qu'est-ce que le mode avancé ? Je ne connais que le mode expert, et je 
n'ai pas constaté de différence de comportement de l'installateur 
vis-à-vis du mot de passe root.



et que tu ne renseignes par le
compte root, le système passe alors par sudo ...


Un mot de passe root est quand même demandé mais pas exigé. Libre à 
chacun de le renseigner ou pas.

Re: deux connections Internet sur le meme poste Debian Buster

[Pascal Hambourg]

Le 21/08/2019 à 18:09, Étienne Mollier a écrit :


Le 192.168.0.0/23 me chiffonne un peu dans votre "ip route", je
me serais attendu à un 192.168.1.0/24, mais peut-être que vous
avez vos raisons.  Les réseaux internes 192.168.0.0/16 sont en
fait un ensemble de réseaux de classe C (CIDR/24) et non un seul
réseau de classe B (CIDR/16), si je n'écris pas de bêtises.


Les classes sont obsolètes depuis l'entrée en vigueur de CIDR (dont le C 
signifie "classless"). Donc on peut bien découper comme on veut.

Re: Question

[Pascal Hambourg]

Le 21/08/2019 à 15:33, steve a écrit :


Oui. Par défaut, Debian ne demande plus de mot de passe root à
l'installation


Ça sort d'où ? Je viens de faire plusieurs installations de Buster, et 
il m'est systématiquement proposé de définir un mot de passe root.

Re: DNS : pas de résolution en local

[Pascal Hambourg]

Le 21/08/2019 à 13:05, Daniel Huhardeaux a écrit :

Le 21/08/2019 à 07:34, Pascal Hambourg a écrit :

Le 20/08/2019 à 11:00, Daniel Huhardeaux a écrit :

Ou alors les nameserver sont interrogés en même temps et la réponse 
du 1er répondant est utilisée.


Non.


Si. Exemple avec dnsmasq: si on ne met pas strict-order celui ci 
interroge tous les serveurs qui sont up et prend la réponse du 1er 
serveur qui a répondu.


Je parlais du résolveur de la libc utilisé par les programmes, pas d'un 
serveur DNS récursif.

Re: DNS : pas de résolution en local

[Pascal Hambourg]

Le 21/08/2019 à 10:00, Migrec a écrit :

Le 21/08/2019 à 07:34, Pascal Hambourg a écrit :


Conclusion : tous les DNS mentionnés dans resolv.conf doivent être 
équivalents.


Merci pour ces précisions.
Mon problème était lié à l'odre des DNS inscrits dans /etc/resolv.conf. 


Non. Ton problème est lié au fait que resolv.conf contient l'adresse 
d'un serveur DNS qui ne fournit pas les bonnes réponses.


Comme je l'ai écrit ci-dessus, tous les DNS inscrits dans resolv.conf 
sont censés être équivalents et fournir les mêmes réponses, donc l'ordre 
ne devrait pas avoir d'importance.


Or ce fichier est dynamique et je n'ai pas trouvé comment modifier 
l'ordre. Ça semble lié au montage des interfaces réseau.
Du coup, j'ai inversé mes 2 cables ethernet et modifié enp2s0 en enp3s0 
(et vice-versa). De cette façon, c'est ok.


Pas fiable. Si un serveur DNS ne doit pas être interrogé parce qu'il ne 
fournit pas les bonnes réponses, il ne doit pas être inscrit dans 
resolv.conf. dhclient (request, supersede, prepend) et NetworkManager 
(méthode : "adresses automatiques uniquement") ont des options pour 
l'empêcher.

Re: DNS : pas de résolution en local

[Pascal Hambourg]

Le 20/08/2019 à 11:00, Daniel Huhardeaux a écrit :

Le 20/08/2019 à 10:55, Daniel Caillibaud a écrit :

Le 20/08/19 à 00:47, Migrec  a écrit :

Ça peut paraître logique car la box n'a pas connaissance de mon réseau
local (elle est juste en liaison avec le serveur). Mais pourquoi l'échec
de la résolution ne passe pas la main au serveur DNS local ?


Parce qu'il me semble que la résolution n'utilise le 2e dns que si le 
1er ne répond pas.


En effet. Ou alors répond qu'une erreur interne l'empêche de fournir une 
réponse (SERVFAIL, REFUSED...). En revanche NXDOMAIN (domaine 
inexistant) n'est pas considéré comme une absence de réponse.



Ici le 1er répond que le nom n'existe pas, donc ça s'arrête là.


En fait ici il ne dit pas que le nom n'existe pas, sinon il aurait 
répondu avec status=NXDOMAIN. Il répond avec status=NOERROR et ANSWER=0, 
ce qui signifie normalement que le nom existe mais qu'il n'a pas 
d'enregistrement du type demandé (A=adresse IPv4). Pour un client cela 
revient au même, mais cette réponse n'est pas correcte. Si je fais la 
même requête à mon serveur DNS, j'obtiens bien status=NXDOMAIN.


Ou alors les nameserver sont interrogés en même temps et la réponse du 
1er répondant est utilisée.


Non.

Conclusion : tous les DNS mentionnés dans resolv.conf doivent être 
équivalents.

Re: Migration des noms des interfaces réseau

[Pascal Hambourg]

Le 17/08/2019 à 17:48, Frederic Zulian a écrit :


Une autre possibilité est d'enlever systemd-networkd  et  continuer à
utiliser /etc/network/interfaces   avec les noms classiques d'interfaces
eth0, eth1, ...,


Cette réponse me surprend. Que je sache, ni le fichier 
/etc/network/interfaces ni systemd-networkd n'influent sur le nommage 
des interfaces. C'est plutôt l'inverse.


Comme ça a été dit, c'est systemd.link qui gère le nommage en 
remplacement des règles udev.

Re: lenteur maladive

[Pascal Hambourg]

Le 09/08/2019 à 09:52, Pierre L. a écrit :


existe-il une certaine possibilité à un OS de
régler/discuter avec le bios ?


Bien sûr. Notamment via l'ACPI.

Re: Noyau >= 4.19.0.5 et disque chiffré

[Pascal Hambourg]

Le 09/08/2019 à 11:33, David BERCOT a écrit :


En effet, c'était bien ça... J'ai suivi la doc : purge et réinstallation de 
cryptsetup et cryptsetup-initrams et tout est rentré dans l'ordre.


Rien à voir avec GRUB, donc.


Le 08/08/2019 à 18:30, Jean-Marc a écrit :


Ne serait-ce pas plutôt un soucis au niveau de GRUB ?

J'ai vu passé quelques bugs relatifs à l'amorçage GRUB + disques chiffrés.


Ça concerne uniquement le cas où /boot est chiffré et empêche 
l'affichage du menu de démarrage et bien sûr le chargement du noyau, 
quelle que soit la version.

Re: mais ou est passee la place manquante ?

[Pascal Hambourg]

Le 07/08/2019 à 00:17, hamster a écrit :

Pascal Hambourg a écrit :

Le 06/08/2019 à 12:48, hamster a écrit :


if [[ "$(grep "/home" /etc/mtab | cut -d" " -f3)" = "ext?" ]]


Cette expression n'est pas assez sélective. Elle prend en compte
n'importe quel montage contenant "/home" dans le point de montage
(/home/data) ou le périphérique (/dev/vg/home).


Très juste. Je pense que rajouter des espaces résout le problème :
if [[ "$(grep " /home " /etc/mtab | cut -d" " -f3)" = "ext?" ]]


C'est mieux, et probablement suffisant. Pour provoquer un faux positif 
il faudrait un chemin contenant des espaces, ce qui n'est pas courant.

Re: mais ou est passee la place manquante ?

[Pascal Hambourg]

Le 06/08/2019 à 12:48, hamster a écrit :


if [[ "$(grep "/home" /etc/mtab | cut -d" " -f3)" = "ext?" ]]


Cette expression n'est pas assez sélective. Elle prend en compte 
n'importe quel montage contenant "/home" dans le point de montage 
(/home/data) ou le périphérique (/dev/vg/home).

Re: Buster problème réseau étonnant

[Pascal Hambourg]

Le 01/08/2019 à 15:13, roger.tar...@free.fr a écrit :

De manière épisodique, l'accès au réseau internet se coupe.
Je peux  constater une latence pendant des accès ssh, depuis FF (pages ne 
chargent pas ou tardivement) ou avec un ping qui passe ou pas d'une minute à 
l'autre :

$ ping -c 3 yahoo.com
ping: yahoo.com: Name or service not known


Ce n'est pas le ping qui ne passe pas, c'est la résolution DNS qui 
foire. Cela peut être juste une défaillance du DNS ou une perte de 
connectivité IP totale. Pour différencier les deux, il faut cibler 
directement une adresse IP connue pour répondre au ping.

Re: Difficile création d'une cle usb multiboot uefi gpt grub !

[Pascal Hambourg]

Le 28/07/2019 à 16:08, toto a écrit :

RESOLU 


De quelle manière ?

Re: Difficile création d'une cle usb multiboot uefi gpt grub !

[Pascal Hambourg]

Le 25/07/2019 à 21:59, Basile Starynkevitch a écrit :


A partir d'une image .iso qui traine sur le net, par exemple une Debian 
netinst (...)


il suffit de la copier, kilo-octets par kilo-octets, avec l'utilitaire 
dd


Et ensuite, comment mets-tu en place le multiboot ?

Re: Difficile création d'une cle usb multiboot uefi gpt grub !

[Pascal Hambourg]

Le 25/07/2019 à 20:28, toto a écrit :


Périphérique   Début  Fin Secteurs Taille Type
/dev/sdb1   2048  1050623  1048576   512M Système EFI
/dev/sdb21050624 60062466 59011843  28,1G Système de fichiers Linux


La partition système EFI est-elle bien formatée en FAT ? Quel type (16 
ou 32) ?



mount /dev/sdb1 /mnt/efi
mount /dev/sdb2 /mnt/data

grub-install --efi-directory=/mnt/efi --boot-directory=/mnt/data/boot
--removable (termine avec succes)


Ça m'a l'air correct, même si je ne me serais pas embêté à créer un 
répertoire /boot.

As-tu vérifié le contenu de la partition EFI ?


cp firmware-10.0.0-amd64-netinst.iso /mnt/data/iso/ (il s'agit d'un simple
essai d'image iso)


Mais ce n'est pas forcément un choix judicieux. Si ça n'a pas changé 
avec Buster, l'initramfs (initrd.gz) pour cdrom inclus dans les images 
d'installation de Debian ne peut pas utiliser un fichier image mais 
seulement un périphérique (disque ou partition). Il faut utiliser le 
fichier initrd.gz pour hd-media à la place de celui inclus dans l'image.





( remarque   :je également fait "Echap" au boot de pc pour tomber
directectement sur  "boot options" (F9) mais cela conduit au même problème)


PC de marque HP ? J'en ai connu plusieurs modèles dont l'amorçage UEFI 
était défectueux.



* puis s'affiche le choix du bios et je choisi "boot options" (F9) et parmi
les choix je prends "usb hard drive (uefi)"

* enfin le message suivant s'affiche et reboot le pc sans que le menu grub
de ma cle s'affiche :

system bootorder not found  initializing defaults
reset system


Je n'ai jamais vu ce message et ne le comprends pas. BootOrder est une 
variable EFI indiquant l'ordre de priorité des différentes sources 
d'amorçage. Mais il est sans objet quand on force un périphérique 
d'amorçage. Tu peux afficher les variables de boot EFI avec efibootmgr.

Re: Problème récurrent avec les clés USB

[Pascal Hambourg]

Le 25/07/2019 à 15:09, Nicolas FRANCOIS a écrit :


Depuis quelques temps (disons moins d'un an), j'ai parfois des soucis
avec mes clés USB : celles-ci sont montés en "Read-only", avec souvent
un propriétaire root, et je n'arrive à rien faire avec.


Une démonstration serait plus parlante.
La ligne dans /proc/mounts relative au montage de la clé.
Les propriétaires et permissions du point de montage.
Un exemple de commande qui échoue.

Re: Une erreur dans les messgaes de boot que j'aimerais corriger !

[Pascal Hambourg]

Le 23/07/2019 à 17:25, toto a écrit :


3) EXT4-fs (sda2): re-mounted. Opts: errors=remount-ro


Ce n'est pas une erreur. C'est le remontage de la racine avec les 
options spécifiées dans /etc/fstab (le montage initial étant fait en 
lecture seule par l'initramfs avant qu'il puisse lire /etc/fstab puisque 
la racine n'est pas encore montée).

Aucune idée concernant les autre messages.


Remaque / Info  :  j'ai du lancer update-initramfs à la main pour que le
firmware non-free de ma carte ati soit pris en compte au boot. En effet sous
stretch il me semble que je n'avais pas eu besoin de le faire ?


Il se pourrait donc que le module radeon ou amdgpu soit inclus dans 
l'initramfs de Buster. Ce n'était pas le cas dans Stretch.

Vérifiable avec lsinitramfs /boot/initrd.img-

Re: Mise à jour du bios UEFI ?

[Pascal Hambourg]

Le 21/07/2019 à 13:55, Eric Degenetais a écrit :

Le dim. 21 juil. 2019 13:32, ajh-valmer  a écrit :


On Sunday 21 July 2019 13:21:15 hamster wrote:

Le 21/07/2019 à 13:07, ajh-valmer a écrit :

Quel est l'intérêt de mettre le BIOS en mode UEFI ?


En principe, une meilleure gestion du multiboot entre plusieurs systèmes 
installés sur un même disque : il n'y a plus de concurrence pour le MBR 
entre les différents chargeurs d'amorçage.



(sécurité ?).


La sécurité de l'UEFI est une vaste blague.

Inutile d'évoquer la prise en charge des disques de plus de 2 To et du 
format GPT : n'importe quel BIOS pas trop vieux ni buggé peut gérer bien 
plus de 2 To et je n'ai pas encore vu un BIOS ou un firmware UEFI en 
mode legacy refuser d'amorcer un disque au format GPT (mais l'inverse, 
UEFI sur DOS/MBR, si), parfois au prix d'une petite entorse à la 
spécification.



Le mode Legacy est si simple et on peut booter
sur tous les périphériques.


D'après un doc d'Intel, certains firmwares UEFI ne gèreraient pas les 
SSD NMVe en mode legacy. Je n'ai pas connaissance d'exemple concret.



Si on a un ordi ou y'a déjà windows installé en UEFI et qu'on veut
rajouter linux a coté en double boot, on est obligé de gardes l'UEFI
sinon windows démarre plus.


Aaah ?

Chez moi, c'est le contraire :

UEFI : que boot Windows et pas possible de booter
sur clé USB et DVD Live.

LEGACY : boot Windows + Linux, et boot sur clé USB et DVD Live.


Si on reinstalle Windows en mode legacy, sûrement, mais s'il a été installé
en mode UEFI, pas sûr.


A ma connaissance une même installation de Windows ne peut pas booter 
indifféremment en mode UEFI et legacy. C'est soit l'un, soit l'autre et 
c'est fixé à l'installation. Ce que ajh-valmer appelle "LEGACY" ne 
serait-il pas plutôt "UEFI+legacy" ?



Debian stretch fonctionne aussi en mode UEFI si on désactive "secure boot",
il me semble.


Oui.


Et alors Windows installé en mode UEFI continue de démarrer.


Sauf si BitLocker est activé sur le disque. Déjà vu un cas.


Buster fonctionne en UEFI avec "secure boot" aussi bien que sans, si j'ai
bien compris.


Oui, mais la variante de GRUB compatible avec le secure boot a (ou 
avait, si ça a été corrigé) un défait qui l'empêche de fonctionner 
correctement quand on change l'identifiant du système ("debian" par défaut).

Re: Re : monter une clé usb en ne connaissant pas son adresse

[Pascal Hambourg]

Le 20/07/2019 à 07:14, k6dedi...@free.fr a écrit :


Ici, j'ai 3 périphériques de stockage :
∙   mon SSD principal (vendu comme 512 Gb) /dev/sda
∙   et 2 clés USB :
 ∘  un SanDisk (64 Go) /dev/sdb
 ∘  et un no-name 2GB /dev/sdc
Vous pouvez ensuite croiser cette information avec la sortie lsblk pour 
apprendre comment ces points de montage (mountpoints) sont utilisés et quelles 
sont leurs partitions.


/dev/sd? ne sont pas des points de montage, ce sont des fichiers 
spéciaux de périphériques blocs.



sdb 8:16   1  58,4G  0 disk
sdc 8:32   0   1,9G  0 disk
└─sdc1  8:33   0   1,9G  0 part  /media/siltaar/Framakey
Ici, nous apprenons que /dev/sdb n'a pas de sous-partitions en elle, tandis que 
/dev/sdc a la sous-partition /dev/sdc1, qui est montée sur 
/media/siltaar/Framakey.


Partition. "Sous-partition" impliquerait qu'il y ait une partition dans 
une partition, ce qui n'est pas le cas.



Donc, si vous voulez formater la petite clé USB que vous voulez cibler, elle se 
nomme /dev/sdc1.


Sans oublier de démonter le système de fichiers au préalable, sinon des 
choses bizarres et désagréables pourraient se produire (plantage, 
corruption). Le noyau n'aime pas qu'on modifie un système de fichiers 
monté dans son dos.

Re: Buster problème réseau étonnant

[Pascal Hambourg]

Le 18/07/2019 à 13:50, roger.tar...@free.fr a écrit :



From: "Pascal Hambourg" 

J'ai tout simplement l'impression que le nouveau paramètrage est
enregistré mais pas appliqué immédiatement par cet outil (lequel
d'ailleurs ? l'applet NetworkManager ?), et qu'il n'est appliqué qu'à
la prochaine activation de l'interface.


Je suis un peu paumé.


Pourquoi ?


Dans mon /etc/network/interfaces, Je n'ai plus rien d'autre que ce que j'ai 
communiqué.


/etc/network/interfaces n'a rien à voir ici. C'est une autre méthode de 
configuration concurrente.



M'install de Buster a 2 jours et je n'avais pas encore touché à la config du 
réseau.


Et donc ?


C'est un mystère pour moi.


Qu'est-ce qui est un mystère ? En quoi mon explication ne suffit pas ?

Re: Buster problème réseau étonnant

[Pascal Hambourg]

Le 18/07/2019 à 12:52, roger.tar...@free.fr a écrit :


Pendant une bête configuration de routeur, j'ai constaté la chose suivante pour 
l'opération simple qui consiste à paramétrer une adresse IP fixe pour la 
machine (Debian Buster) :
1/ ip a   donne l'adresse IP de la machine qui accède normalement à internet

2/ par Settings/Network onglet IPv4 / Bouton radio Manual puis valeurs (IP / 
mask / gateway).
Je fais Apply (bouton)

3/ ip a   affiche toujours l'ancienne addresse IP.

4/ Dans Settings/Network, je fais désactiver puis activer la Wired connection 
(avec le bouton coulissant)

5/ ip a   affiche l'adresse IP fixe paramétrée


J'ai tout simplement l'impression que le nouveau paramètrage est 
enregistré mais pas appliqué immédiatement par cet outil (lequel 
d'ailleurs ? l'applet NetworkManager ?), et qu'il n'est appliqué qu'à la 
prochaine activation de l'interface.

Re: Configuration d'un ordinateur comme passerelle

[Pascal Hambourg]

Le 17/07/2019 à 13:13, Stephane Ascoet a écrit :

Le 16/07/2019 à 17:58, ajh-valmer a écrit :

- Hub = concentrateur,


Bonjour, en STS d'informatique, on m'a appris que c'etait un "repeteur 
multiports"


De même qu'un switch ou commutateur est un "pont multiport".
Et donc, qu'est-ce que ça apporte au sujet ?

Re: Configuration d'un ordinateur comme passerelle

[Pascal Hambourg]

Le 16/07/2019 à 15:45, Christian Quentin a écrit :

Et sinon, l'utilisation d'un petit switch de quelques ports n'est pas
envisageable ?


Ce serait de loin la solution la plus simple et la plus fiable.


ou encore moins coûteux, l'utilisation d'une paire de dédoubleurs RJ45


Si je ne m'abuse, c'est limité au fast ethernet (100 Mbit/s) qui 
n'utilise que 2 paires par liaison sur les 4 d'un câble ethernet. Le 
gigabit ethernet (1000 Mbit/s) utilise les 4 paires.


Note pour Samy : "passerelle" ("gateway") est un terme vague dont 
l'usage est déconseillé et devrait être banni. Ce que tu proposes dans 
ton message initial est un pont ethernet (ni plus ni moins qu'un switch 
logiciel). L'autre type de configuration possible, plus compliquée, 
serait un routeur IP (v4 et/ou v6).

Re: blocage du système USB

[Pascal Hambourg]

Le 11/07/2019 à 11:32, Kohler Gerard a écrit :


j'utilise une tablette graphique Wacom, et j'ai un bug au niveau du 
mountage USB : lorsque je branche ma tablette en USB, je ne peux plus 
mounter des clés USB


On ne dit pas "mounter" mais "monter". Quand il existe un équivalent 
français convenable, pourquoi inventer un barbarisme franglais hideux ?



ou des cartes mémoires


Une carte mémoire n'est pas un périphérique USB.
Un lecteur de carte mémoire peut être un périphérique USB, mais pas 
forcément. Le lecteur de carte SD d'un ordinateur portable est souvent 
un périphérique PCI. Qu'en est-il ici ?



- comment relancer le système udev sans relancer la machine ?


Qu'est-ce qu'udev vient faire ici ? Il n'est pas utile au montage d'un 
système de fichiers contenu dans un support de stockage USB.


- lorsque je me déconnecte il reste des processus actifs dont je suis 
l'utilisateur entre autre udev est-ce normal ?


|$ps aux |grep gerard|

|gerard    2072  0.0  0.0  21516  9572 ?    Ss juil.10   0:09 
/lib/systemd/systemd --user|


Je ne vois pas de processus udev, seulement systemd.

/- /quelle démarche diagnostique pour comprendre ce bug (problème au 
niveau  des modules Wacom ?)


Commencer par examiner les messages du noyau lors du branchement de la 
tablette et d'un support de stockage avec dmesg ou dans /var/log/kern.log.

Re: Quel test unitaire illustre le problème que corrige "-j TCPMSS --clamp-mss-to-pmtu" ?

[Pascal Hambourg]

Le 11/07/2019 à 14:38, Olivier a écrit :

Le jeu. 11 juil. 2019 à 14:04, Bernard Schoenacker <
bernard.schoenac...@free.fr> a écrit :


serait il possible de régler le mtu à 1492 sur la passerelle ?


Sauf erreur, le MTU était déjà réglé à 1492 sur le lien ppp0, si j'en crois
la sortie d' "ip link" .


Evidemment, sinon l'option --clamp-mss-to-pmtu serait sans effet.


ping -M do -s 1492 192.168.4.254
PING 192.168.4.254 (192.168.4.254) 1492(1520) bytes of data.
ping: local error: Message too long, mtu=1492

où 192.168.4.254 est l'IP de mon serveur PPPoE (sur lequel le MTU est aussi
valorisé à 1492).

La valeur la plus grande pour laquelle le ping ci-dessus réussit est 1464


1464 + 8 (en-tête ICMP) + 20 (en-tête IPv4) = 1492


(le hack iptables ne change rien à cet égard).


Normal, il n'affecte que les paquets TCP.
Effectivement, le mot est juste : c'est un hack.

Re: Quel test unitaire illustre le problème que corrige "-j TCPMSS --clamp-mss-to-pmtu" ?

[Pascal Hambourg]

Le 11/07/2019 à 12:53, Olivier a écrit :


Avec des captures Wireshark, j'ai vu que dans l'environnement en défaut, un
message "ICMP Don't Fragment" était émis.


Ça m'étonnerait. Ce type de message n'existe pas. Tu dois confondre avec 
"Fragmentation needed but DF (Don't Fragment) set".



Plus spécifiquement, j'aimerai a minima, savoir quelle commande permet de
détecter le problème corrigé par la cible -j TCPMSS --clamp-mss-to-pmtu de
mes règles iptables ?


Il n'existe pas de commande qui détecte le problème à coup sûr. Cette 
cible contourne un problème de gestion de MTU qui se situe dans le sens 
descendant : l'émetteur distant n'est pas informé que les paquets qu'il 
envoie sont trop gros (soit à cause d'un trou noir de MTU causé par un 
pontage PPPoe-PPP par exemple, soit à cause d'un routeur qui ne renvoie 
pas de message ICMP "Fragmentation needed" à l'émetteur, soit à cause 
d'un filtrage de ce message entre le routeur et l'émetteur, soit parce 
que l'émetteur ne tient pas compte de ce message).


Envoyer un gros ping avec -M do (fragmentation interdite) est vain : le 
ping sera bloqué dès l'émission alors que le problème à détecter se 
situe en réception. Envoyer un gros ping fragmenté a plus de chances de 
détecter quelque chose : la cible devrait envoyer une réponse fragmentée 
mais en cas de problème seul le petit fragment sera reçu par l'interface 
PPPoE.

Re: Installer windows 8.1 à partir de son image iso sur une clé usb avec grub2 ?

[Pascal Hambourg]

Le 07/07/2019 à 13:54, didier gaumet a écrit :

Le 07/07/2019 à 07:46, toto a écrit :


Je souhaite aujourd'hui installer windows 8.1 puis debian stretch 9.9.0 sur
un disque dur (table de partition GPT et bios UEFI) en amorçant mon pc
portable avec une clé multiboot sur laquelle il y grub2 et les images iso de
ces 2 os.

Que dois je mettre dans mon fichier grub.cfg ?

Voilà un début :

===debut grub.cfg===

menuentry 'windows 8.1 64 bits' {
 iso=/boot/win8_1.iso
 loopback loop $iso
 ntldr (loop)/bootmgr


Marchera pas. La commande ntldr n'est disponible qu'en mode BIOS.


 boot
}


Inutile, c'est implicite dans les entrées de menu.


menuentry 'hdMedia' {
 linux /boot/hdMedia/vmlinuz
 initrd /boot/hdMedia/initrd.gz
}

fin grub.cfg===

Les images iso se trouvent dans le répertoire /boot de la clé usb :

/boot/win8_1.iso
/boot/firmware-9.9.0-amd64-DVD-1.iso

(...)

- pour lancer l'installateur Debian, tu peux à mon sens détruire ton
entrée Grub "hdmedia" et la remplacer par une entrée du style de
SystemrescueCD en chainload ISO dans ce tutoriel du wiki Gentoo:


Ta suggestion a un léger problème : l'initrd.gz pour "cdrom" inclus dans 
les images ISO hybrides d'installation officielles n'est pas capable de 
monter une image disque, et je suppose qu'il en est de même avec les 
images non officielles incluant les firmwares non libres. Certes 
l'installateur se lancera mais il échouera à l'étape "détecter et monter 
un CD-ROM". C'est pourquoi toto a utilisé à juste titre l'initrd.gz pour 
"hd-media" qui peut monter une image disque. En revanche l'image du 
noyau vmlinuz est identique.

Re: Extension "tray icons"

[Pascal Legrand]

Ici mon fichier de conf et une copie d'écran de ce que ça donne.
Sachant qu'avec Wayland tout ne fonctionne pas nikel.

http://plegrand1.free.fr/tint2.png
http://plegrand1.free.fr/tint2rc

Re: Extension "tray icons"

[Pascal Legrand]

De mon côté sur Debian SID avec Gnome, j'utilise Tint2 avec bonheur
Bonne journée

--

Pascal

Re: Extension "tray icons"

[Pascal Legrand]

De mon côté sur Debian SID avec Gnome, j'utilise Tint2 avec bonheur
Bonne journée

--

Pascal

Re: Re : Passer de Debian Stretch 32 bits à 64 bits

[Pascal Hambourg]

Le 02/07/2019 à 23:42, Pascal Hambourg a écrit :

Le 02/07/2019 à 23:14, Sébastien NOBILI a écrit :

Le mardi 02 juillet 2019 à 20:05, Pascal Hambourg a écrit :

Le 02/07/2019 à 14:54, Sébastien NOBILI a écrit :


Les paquets x86 sur le système amd64 pourront rester installés, mais 
on ne pourra pas les faire fonctionner directement.


Pardon ? Il me semble que si un paquet reste installé, c'est que ses
éventuelles dépendances sont satisfaites. Qu'est-ce qui pourrait alors
l'empêcher de fonctionner ?


Le fait qu’un système intégralement amd64 ne sera pas capable 
d’exécuter un ELF

32 bits (ABI incompatible).

Mon système est intégralement amd64 :

(...)

Je vais extraire un paquet i386 et tenter d’exécuter un de ses binaires :


Tatata. Merci de relire la question. Il ne s'agit pas d'exécuter un 
binaire i386 extrait à la sauvage mais faisant partie d'un paquet 
*installé* proprement donc a priori avec toutes ses dépendances, et 
notamment une libc i386.


PS : Si tu veux faire ça, essaie plutôt avec un exécutable statique 
comme bash-static ou busybox-static.

Re: Re : Passer de Debian Stretch 32 bits à 64 bits

[Pascal Hambourg]

Le 02/07/2019 à 23:14, Sébastien NOBILI a écrit :

Le mardi 02 juillet 2019 à 20:05, Pascal Hambourg a écrit :

Le 02/07/2019 à 14:54, Sébastien NOBILI a écrit :


Les paquets x86 sur le système amd64 pourront rester installés, mais on ne
pourra pas les faire fonctionner directement.


Pardon ? Il me semble que si un paquet reste installé, c'est que ses
éventuelles dépendances sont satisfaites. Qu'est-ce qui pourrait alors
l'empêcher de fonctionner ?


Le fait qu’un système intégralement amd64 ne sera pas capable d’exécuter un ELF
32 bits (ABI incompatible).

Mon système est intégralement amd64 :

 $ uname -r
 4.9.0-9-amd64
 $ dpkg --print-architecture
 amd64

Je vais extraire un paquet i386 et tenter d’exécuter un de ses binaires :


Tatata. Merci de relire la question. Il ne s'agit pas d'exécuter un 
binaire i386 extrait à la sauvage mais faisant partie d'un paquet 
*installé* proprement donc a priori avec toutes ses dépendances, et 
notamment une libc i386.