Re: dhclient and ipv6 DNS Servers

[Pascal Hambourg]

Le 14/01/2020 à 21:14, Rainer Dorsch a écrit :


prepend dhcp6.name-servers 2001:4860:4860::, 2001:4860:4860::8844;

avoids the error message, but has no visible effect I can see. The IPv6 DNS
servers still do not show in resolv.conf.


You may receive IPv6 DNS information from IPv6 Router Advertisements 
(RA) with rdnssd, not DHCPv6.

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: Root is in RO after boot

[Pascal Hambourg]

Le 07/01/2020 à 16:45, Kenneth Parker a écrit :


So are you saying that initrd is called without /
being mounted at all!


Of course. The main purpose of the initramfs is to mount the final root 
filesystem before starting the final init.

Re: Root is in RO after boot

[Pascal Hambourg]

Le 07/01/2020 à 15:28, Kenneth Parker a écrit :


As far as I know, it's mounted ro, so that initrd can check if it is okay


Nonsense. The initramfs can check the root filesystem before mounting 
it, so it does not need to mount it read-only.



(via fsck).  And initrd is then supposed to remount it rw.


I don't think so. If you change the default final init with something 
like init=/bin/bash for example, you can see that the root filesystem is 
still mounted read-only. So something in the init system remounts it 
read-write. With sysvinit it is done in checkroot.sh according to mount 
options in fstab. I don't know about systemd.

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: Debian Graphical Installer: why does it format swap?

[Pascal Hambourg]

Le 05/01/2020 à 18:50, Joe a écrit :


Windows uses a swap file, not a separate partition. We are told that
there is no performance penalty for Linux to do so also.


Using a swap file can cause a performance penalty if the file is heavily 
fragmented. Granted, it also applies to a fragmented LVM logical volume, 
but the granularity is bigger (4 MiB extents for LVM vs 4 KiB for usual 
filesystem blocks). Also, not all filesystems support swap files 
properly. For those which don't, you can still use a swap file through a 
loop device, but this will cause a performance penalty and I doubt it is 
supported in /etc/fstab.



As far as I can recall, the expert system allows you to designate
existing partitions to be used or not, and also whether to reformat
them.


This has nothing to do with the expert install but with the manual 
partitioning, which is also available in the standard install.

Re: Debian Graphical Installer: why does it format swap?

[Pascal Hambourg]

Le 05/01/2020 à 16:40, Clod Turner a écrit :


Why does the Debian Graphical installer compromise any other Linux install
on the same HDD/SSD by reformatting swap.


This is a well known long standing "feature" of the Debian installer. It 
is not specific to the graphical installer. Also it does not break all 
other Linux systems, only those which use a swap device (not a swap 
file, like Ubuntu and Mint do now) and identify it by UUID or LABEL. 
Linux systems which identify their swap device by PARTUUID, PARTLABEL or 
persistent device node (such as LVM logical volumes) are unaffected, as 
the reformat does not affect these identifiers. Those which rely on 
systemd-auto-gpt-generator to activate any swap partition on a GPT 
system disk are also unaffected.



no matter what options you try to select in the
partitioning dialogue, the installer will always reformat swap and


This is not correct. You have the option to not use existing swap 
devices, and the installer will not reformat them.

Re: uefi boot install and disk partitions

[Pascal Hambourg]

Le 05/01/2020 à 11:00, to...@tuxteam.de a écrit :

On Sun, Jan 05, 2020 at 10:47:52AM +0100, Pascal Hambourg wrote:

Le 04/01/2020 à 20:47, Sven Joachim a écrit :


[FAT, hard links]


a feature that is crucial for dpkg.


I vaguely remember this, but not when and why dpkg needs to create
additional hard links. Can you refresh my memories ?


   
https://unix.stackexchange.com/questions/208073/dpkg-replacing-files-on-a-fat-filesystem


Thanks. I would be very careful when using a hard link to back up a file 
before replacing it, because it depends on the method used to replace 
the original file with the new file. For example plain 'cp' or shell 
redirection does not break the link and overwrites the contents of the 
original file (and of the hard link), whereas 'cp -d' breaks the link 
and creates a new file.



I'd be more worried about whatever packagers do in their post-install
scripts. After all, hard links are pretty handy when trying to do
atomic operations on file systems.


What kind of atomic operations ?

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: uefi boot install and disk partitions

[Pascal Hambourg]

Le 04/01/2020 à 20:47, Sven Joachim a écrit :

On 2020-01-04 13:38 +0100, Pascal Hambourg wrote:


Some new boot specification mounts the EFI partition on /boot


Citation needed, which specification is that?


Freedesktop/systemd's Boot Loader Specification.
<https://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/>
now <https://systemd.io/BOOT_LOADER_SPECIFICATION/>

Also mentionned in the Discoverable Partitions Specification.
<https://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/>
<https://www.freedesktop.org/software/systemd/man/systemd-gpt-auto-generator.html>


but Debian does not follow it (yet) and still
mounts the EFI partition on /boot/efi.


There are good reasons for not mounting the EFI system partition on
/boot, the most important one is that FAT filesystems do not support
files with multiple hard links,


You mean that FAT filesystems do not support hard links at all. The 
concept of hard link requires some level of indirection between a 
directory entry and a file. In common Unix-like filesystems such as 
ext*, this is provided by inodes structures which contain the file 
metadata. FAT filesystems do not have such indirection and the file 
metadata are contained in the directory entry instead.



a feature that is crucial for dpkg.


I vaguely remember this, but not when and why dpkg needs to create 
additional hard links. Can you refresh my memories ?

Re: uefi boot install and disk partitions

[Pascal Hambourg]

Le 04/01/2020 à 11:25, Bonno Bloksma a écrit :


I have been creating a small (300MB) primary /boot partition at the beginning 
of the disk for as long as I can remember... That is after disks got to be too 
big for the BIOS to reach all of the disk to be able to boot from a file 
anywhere on the disk.

So far so good, that still works but do I still need that partition when I 
create an EFI System Partition (ESP) to boot using UEFI?


A separate /boot is required only if GRUB cannot read the root 
filesystem. Possible reasons include :

- root device not supported by the firmware
- root filesystem type not supported by GRUB
- root device type not supported by GRUB (e.g. RAID linear, maybe some 
LVM volume types)

- encrypted root device


If I had not created that /boot partition would those files be in /boot folder 
on the / (root) partition or would /boot then be on the EFI partition?


On the root partition. Some new boot specification mounts the EFI 
partition on /boot but Debian does not follow it (yet) and still mounts 
the EFI partition on /boot/efi.



Do I still need that /boot partition now that the ESP has the boot flag set?


The EFI partition has no boot flag. If you are using parted or Gparted, 
the boot flag is only a virtual representation of the EFI partition type.



Do I still want it?


You may still want a separate plain /boot partition for safety when the 
root uses some complex setup such as LVM even though it is supported by 
GRUB.

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: Fresh-installed Debian 10 (UEFI, LUKS) not accessible through Secure Boot

[Pascal Hambourg]

Le 01/01/2020 à 13:59, l0f...@tuta.io a écrit :

1 janv. 2020 à 10:36 de didier.gau...@gmail.com:


SecureBoot has its own limitations and perhaps your use case is covered here:
  https://wiki.debian.org/SecureBoot#Secure_Boot_limitations

for example, I cannot use SecureBoot on my recent laptop due to my Realtek 
RTL8821ce wireless card, for which there is a driver that is out out of the 
linux kernel tree. So I have to build a DKMS module that forbids use of 
SecureBoot (I could sign my own module to use SB, though) ...

(...)

I understand that when you go Debian off-road (i.e install some specific 
packages/drivers for your unsupported hardware), you don't comply with Secure 
Boot out-of-the-box anymore.

However, is it normal that I cannot boot my Debian as soon as I installed it?


No. This was only an irrelevant example. Secure boot does not prevent 
booting when an unsigned kernel module is present, it would only prevent 
loading such module.

Re: No security support for binutils and libqt5webkit5, what to do?

[Pascal Hambourg]

Le 29/12/2019 à 20:28, Andreas Goesele a écrit :


I just went from jessie to buster and I didn't discover any serious
problem so far.

But I tried to remove all packages where there is no or only limitid
security support and ended up with 5 packages I don't think I should/can
remove:

binutils (and binutils-common, libbinutils, binutils-x86-64-linux-gnu)
and libqt5webkit5.


Why do you say that these packages have no or limited security support ?

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: New Install Boots to Grub

[Pascal Hambourg]

Le 16/12/2019 à 16:55, Dr. Jason Amerson a écrit :

Hello,

I installed Debian 10.2.0 from a USB drive and the installation finished 
without errors. The only thing that happened during install is that it was 
unable to setup the network. Anyways, I removed the USB drive and rebooted the 
computer. It then booted into grub.


This is expected, as GRUB is Debian's default boot loader.


There was a message telling me I can press TAB to get a list of commands


This is less expected. GRUB should display a menu.
What was the GRUB prompt, simply "grub>" or "grub rescue>" ?
If "grub>", the config file grub.cfg is missing.
If "grub rescue>", GRUB was not installed properly.


but I know nothing about grub and I do not know how to fix the computer so that 
it boots into Debian. Will someone please help me with this?


If you don't know GRUB shell's syntax, then I guess the easier way is to 
boot the Debian installer, select "rescue", follow the steps and 
reinstall GRUB when the option is offered. Make sure you select the 
proper root/boot partition.

Re: Help! Borked suspend/hibernate after adding swap partition

[Pascal Hambourg]

Le 14/12/2019 à 16:35, Ottavio Caruso a écrit :

On Sat, 14 Dec 2019 at 13:47, Pascal Hambourg  wrote:


Le 14/12/2019 à 14:20, Ottavio Caruso a écrit :



I've also added:
GRUB_CMDLINE_LINUX_DEFAULT="resume d823f1ee-2e16-4327-b0c1-639f377002bb"


Wrong syntax. It should be "resume=UUID=d823...".
This will override the RESUME value embedded into the initramfs by
update-initramfs.


Thanks. So, if it is already embedded in initramfs, does it make sense
to have that line in /etc/default/grub?


Only if you need to override the resume value embedded in the initramfs.


Shall I just use the default boot option?


Either is fine.

Re: Help! Borked suspend/hibernate after adding swap partition

[Pascal Hambourg]

Le 14/12/2019 à 14:20, Ottavio Caruso a écrit :


$ sudo update-initramfs -u -k all
update-initramfs: Generating /boot/initrd.img-4.9.0-11-amd64
I: The initramfs will attempt to resume from /dev/sda7
I: (UUID=d823f1ee-2e16-4327-b0c1-639f377002bb)
I: Set the RESUME variable to override this.

(...)

I've also added:
GRUB_CMDLINE_LINUX_DEFAULT="resume d823f1ee-2e16-4327-b0c1-639f377002bb"


Wrong syntax. It should be "resume=UUID=d823...".
This will override the RESUME value embedded into the initramfs by 
update-initramfs.



to /etc/default/grub

and "sudo update-grub"

but I don't have "/etc/initramfs-tools/conf.d/resume"

Is this file necessary?


No. This file used to define the RESUME variable, but it is not created 
by the installer any more and RESUME can be defined in any other 
configuration file in /etc/initramfs-tools/conf.d or in 
/etc/initramfs-tools/initramfs.conf. If RESUME is not defined, 
update-initramfs will use the active swap.

Re: Help! Borked suspend/hibernate after adding swap partition

[Pascal Hambourg]

Le 14/12/2019 à 12:26, Ottavio Caruso a écrit :


$ sudo update-initramfs -u -k all
update-initramfs: Generating /boot/initrd.img-4.9.0-11-amd64
I: The initramfs will attempt to resume from /dev/sda7
I: (UUID=d823f1ee-2e16-4327-b0c1-639f377002bb)
I: Set the RESUME variable to override this.

I'll reboot and test it and we'll take it from there. (Not sure if
reboot is needed)


Reboot is needed to run the new initramfs.

Re: Help! Borked suspend/hibernate after adding swap partition

[Pascal Hambourg]

Le 14/12/2019 à 10:43, Alexander V. Makartsev a écrit :

Simple swap partition creation is not enough for hibernation to work, it
also has to be configured in initrd. [2]


Despite the file name it is no longer an initrd but an initramfs.


https://wiki.debian.org/Hibernation#Changing_or_moving_the_swap_partition


The advice of reinstalling initramfs-tools given in this wiki page is 
just crazy. You only need to rebuild the initramfs with


update-initramfs -u -k all

However I fail to understand the relationsip between the swap and 
suspend-to-RAM.

Re: [Solved] iptables firewall and web sites not loading

[Pascal Hambourg]

Le 10/12/2019 à 20:13, nektarios a écrit :

Pascal Hambourg  wrote:


Maybe a "MTU black hole" issue with PPPoE.
Workarounds :
- lower the MTU on the client side to 1492
- add a "TCPMSS --clamp-to-pmtu" iptables rule on the router

(...)

The tip you gave me really did the job! I found this page in tldp.org
describing the mtu issue
http://www.tldp.org/HOWTO/IP-Masquerade-HOWTO/mtu-issues.html and the I
simply ran the iptables command
```
  iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS
  --clamp-mss-to-pmtu
```
and it was fixed!


Please note that
- It's a hack. It does not fix the actual issue (inbound packets bigger 
than the PMTU are silently dropped).

- It works only for TCP.
- This rule works only for IPv4. If you have IPv6 connectivity, you must 
add a similar ip6tables rule.

- It does not work inside VPNs and tunnels which hide the actual PMTU.

Re: iptables firewall and web sites not loading

[Pascal Hambourg]

Le 10/12/2019 à 00:01, Nektarios Katakis a écrit :


I am running an iptables firewall on an openwrt router I ve got. Which
acts as Firewall/gateway and performs NATing for my internal network -
debian PCs and android phones.

All good but specific web sites are not loading for the machines that
are sitting behind the home router.

When attempting on the browser (firefox but tried different ones) the
browser stays at `Performing a TLS handshake to bitbucket.org`. wget has
similar results:
```
wget  https://bitbucket.org
--2019-12-09 22:07:32--  https://bitbucket.org/
Resolving bitbucket.org (bitbucket.org)... 18.205.93.0, 18.205.93.1,
18.205.93.2, ... Connecting to bitbucket.org
(bitbucket.org)|18.205.93.0|:443... connected.
```
When doing a tcpdump on the router side I can see some initial TCP
session establishment and then nothing:

(...)

Of course doing a wget from the router itself works fine as it also
works fine on my desktop if I do dynamic port-forwarding with eg. `ssh
-D 1050 router` (and configure of course firefox to use it).


Maybe a "MTU black hole" issue with PPPoE.
Workarounds :
- lower the MTU on the client side to 1492
- add a "TCPMSS --clamp-to-pmtu" iptables rule on the router

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: nftables is not accepting rules from ufw

[Pascal Hambourg]

Le 06/12/2019 à 04:15, Brian Vaughan a écrit :


ERROR: problem running ufw-init
Bad argument `DROP'
Error occurred at line: 4
Try `iptables-restore -h' or 'iptables-restore --help' for more 
information.

Bad argument `-'
Error occurred at line: 4

(...)

Problem running '/etc/ufw/user.rules'
Problem running '/etc/ufw/user6.rules'


Did you check the contents of these two files ?

Re: hdd partition alignment parted vs fdisk, partition 1 does not start on physical sector boundary, parted bug?

[Pascal Hambourg]

Le 04/12/2019 à 13:15, Sergey Spiridonov a écrit :


Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 33553920 bytes
Disklabel type: gpt
Disk identifier: 82DD924B-BF0E-40FF-9037-1FD4E7307D26

Device Start End Sectors  Size Type
/dev/sdd1  65535 27344740889 27344675355 12,8T Linux filesystem

Partition 1 does not start on physical sector boundary.

What? Why?


Probably because of the reported "optimal" I/O size.
65535 * 512 = 33553920

Don't know where this value is taken from.

Re: external drive

[Pascal Hambourg]

Le 02/12/2019 à 22:28, Gene Heskett a écrit :

On Monday 02 December 2019 16:02:59 Pascal Hambourg wrote:


Le 02/12/2019 à 02:30, Gene Heskett a écrit :

What I did was plug the u-sd into a card reader/writer.

The card wasn't recognized and dd refused to write to it.


What do you mean *precisely* by "wasn't recognized" ?


Ack dmesg, it was /dev/sdf but that was all.


Could you post the output of dmesg after
1/ connecting the reader to the computer
2/ inserting the card into the reader ?


So it sounds like I actually have a bad card.


Or the reader and the card are incompatible.
There are several spcifications of SD/HC/XC cards.

Re: external drive

[Pascal Hambourg]

Le 02/12/2019 à 02:30, Gene Heskett a écrit :


What I did was plug the u-sd into a card reader/writer.

The card wasn't recognized and dd refused to write to it.


What do you mean *precisely* by "wasn't recognized" ?


Then someone said I need to install exfat,


Bullshit.
dd does not care about the filesystem.


but that it took a kernel version of 5.4 to use it.


Bullshit again.
Exfat is managed in userspace (FUSE), not by the kernel.

Re: Booting Debian 10 installer ISO from USB

[Pascal Hambourg]

Le 23/11/2019 à 20:13, Brian a écrit :

On Sat 23 Nov 2019 at 11:00:58 -0600, pru...@finsakxim.com.mx wrote:


This
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=841135
would explain why it works for you, as well as in other cases.

It seems to only work at maximum level 1 directories;


I already told you exactly this in my previous post :
"The quick scan only searches in top-level directories."


Thank you for the link. I had not seen this report before. One bit of it
is the statement:

  > From what I understand now, iso-scan is not meant to use
  > any iso filename supplied to it via grub command line, but
  > it rather prefers to scan the USB stick for usable images


This is what I understood from a quick look at the script.


  > itself, and then present the user with a menu.


Only with lower priority. With default priority, it automatically 
selects the first "usable" image found.



My understanding is that iso-scan/filename= simply says which ISO is to
be searched for.


How did you understand this ? It matches neither the script nor the 
experiences.



I put two Debian ISOs in /boot/iso and had a similar grub.cfg to yours:

   iso_path=/boot/iso/debian-10.2.0-amd64-xfce-CD-1.iso
   export iso_path
   search --set=root --file "$iso_path"
   loopback loop "$iso_path"
   menuentry "Test" {
  linux /boot/vmlinuz  iso-scan/filename=$iso_path priority=low
  initrd /boot/initrd.gz
   }

I get a list of sixteen partitions and devices and choose the one that I
know holds the ISOs (/dev/sdg1).


This is the effect of priority=low.


This comes up with (as it did for you):

  > The quick scan for installer ISO images, which looks only
  > in common places

But a full disk search immediately scans /dev/sdg1 and presents a choice
between the two ISOs.


Again the effect of priority=low.

So iso-scan seems to ignore the iso-scan/filename value provided in the 
command line. If I understood the script correctly, it does not read 
this parameter, it only writes the selected image pathname into it.

Re: Booting Debian 10 installer ISO from USB

[Pascal Hambourg]

Le 21/11/2019 à 19:08, pru...@finsakxim.com.mx a écrit :


Now, my last issue is: quick scan always fails, looking only in "common 
places". So perhaps the location in the USB sdb3/boot/isos is not 
considered a "common place" and thus only full search can find it here. 


The quick scan only searches in top-level directories.


Can this behavior be changed?


Try iso-scan/ask_second_pass=true.


For this matter, why isn't iso-scan/filename actually working?


It does not seem to be an input but an output.

Re: Orphaned Inode Problem

[Pascal Hambourg]

Le 18/11/2019 à 20:06, Stephen P. Molnar a écrit :


The CPU is an AMD FX-8320 Eight-Core Processor on an ASUSTeK M5A97 R2.0 
Motherboard with 8GB Ram. I have started having orphaned inodes when I 
run a major piece of software in my research program.


How do you know you have orphaned inodes and that they are the cause of 
the system hang ?


AFAIK, orphaned inodes are not a cause but a consequence of an uncleanly 
unmounted filesystem, and fsck spots them at the next boot. They are 
often caused by a hard reboot.

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: no ethernet drivers in testing/10 netinstall image?

[Pascal Hambourg]

Le 02/11/2019 à 20:07, Joe a écrit :

Kent Dorfman  wrote:


I'd make a strong argument that removing the common drivers from
whatever kernel is used in "testing" is more an "unstable" action.

(...)

But at no time should a mature and extremely important device driver get
pulled from it. Something has gone wrong here.


This is getting ridiculous. No such thing happened. The OP used a daily 
build.


Quotes from  :

"The CDs built in each run are the "sid" netinst for each arch, i.e. a 
version of the installer that will install testing but uses the latest 
d-i build from the porters for each architecture."


""arch-latest" points to the last successful CD build for each 
architecture. (NOTE: that's not a guarantee that the CDs are useful, 
just that the build script did not fail!)."

Re: no ethernet drivers in testing/10 netinstall image?

[Pascal Hambourg]

Le 02/11/2019 à 19:34, Kent Dorfman a écrit :

I think we have slightly different perceptions of what the scope of
the "testing" release is.


I think you have a wrong perception of what Debian testing is. Testing 
is not stable. Besides, the testing installer images are not intended to 
install testing but to test the installer. By the way, the daily testing 
images are based on sid (unstable) debian installer. Sometimes these 
images are broken. That's what testing is for.

Re: what is the proper way to recover grub in an EFI environment ?

[Pascal Hambourg]

Le 02/11/2019 à 17:45, shirish शिरीष a écrit :

 Directory: P:\EFI


ModeLastWriteTime Length Name
- -- 
d-   15-02-2018 19:21Microsoft
d-   15-02-2018 19:26Boot
d-   25-06-2019 07:08debian

As can be seen it can be in EFI partition but not within Boot, dunno
if that is normal or not.


It is normal. As you can see, each system creates its own directory in 
/EFI. /EFI/Boot contains the fallback bootloader bootx64.efi.



 Directory: P:\EFI\debian


ModeLastWriteTime Length Name
- -- 
-a   07-09-2019 15:571631600 grubx64.efi
-a   07-09-2019 15:57121 grub.cfg
-a   07-09-2019 15:571322936 shimx64.efi
-a   07-09-2019 15:571261192 mmx64.efi
-a   07-09-2019 15:571206824 fbx64.efi
-a   07-09-2019 15:57108 BOOTX64.CSV


Expected contents with grub-efi-amd64-signed.


How did you change Debian boot mode to EFI ?


I don't think I did that, although am not sure. Is there a way to see
if that has been done or not ?


In your original post, you wrote :


The install I had done was in legacy mode when I had Debian installed
and subsequently had changed the boot mode from legacy to EF


After a legacy installation, the EFI partition did not mount itself on 
/boot/efi and GRUB EFI did not install itself in it.



What I remember doing is being asked to try to change the BIOS from
legacy mode to a UEFI and see if the grub menu appeared. I tried and
did that and it worked for quite sometime.


This is not enough to change Debian boot from legacy to EFI.
Why were you asked to do this ? Didn't GRUB appear after you installed 
Debian when the BIOS was still set up for legacy boot ?



Can you see a "debian" entry in the UEFI boot menu or boot order ?


Sadly no, in the UEFI boot menu or boot order I just have the MS boot
manager and one without.


Without what ?
If there is no Debian entry then I don't see how GRUB could show up when 
booting in EFI mode, unless you messed with Windows Boot Manager from 
within Windows using bcdedit.


If you want to boot properly with GRUB EFI, you must start a Linux 
system in EFI mode. Then you can use efibootmgr for instance to create 
an EFI boot entry for Debian.

Re: no ethernet drivers in testing/10 netinstall image?

[Pascal Hambourg]

Le 02/11/2019 à 15:21, Reco a écrit :

On Sat, Nov 02, 2019 at 03:12:10PM +0100, Pascal Hambourg wrote:


IIUC the OP is talking about the netinst installer, not an installed
system. Maybe he encountered a situation where the d-i package
containing NIC modules was not installed yet, or the installer was
damaged.


Except that they include e1000 in the netinst's initrd:

$ wget -q 
http://ftp.debian.org/debian/dists/bullseye/main/installer-amd64/current/images/netboot/netboot.tar.gz


netboot is not netinst.

Re: what is the proper way to recover grub in an EFI environment ?

[Pascal Hambourg]

Le 02/11/2019 à 13:30, shirish शिरीष a écrit :


/boot/efi/ is empty


As expected. /boot/efi is just a mount point for the EFI partition.
Check /EFI/debian in the EFI partition (FAT).

How did you change Debian boot mode to EFI ?
Can you see a "debian" entry in the UEFI boot menu or boot order ?
Can you boot in EFI mode with a live system or Debian installer ?

Re: no ethernet drivers in testing/10 netinstall image?

[Pascal Hambourg]

Le 02/11/2019 à 14:03, to...@tuxteam.de a écrit :

Kent Dorfman  wrote:


There are no ethernet drivers in the modules directory for the
netinstall image, other than a single broadcomm file...and no, it's
not an obscure nic that requires custom firmware.  It needs the humble
e1000 driver.


This is pretty strange: the e1000 driver should be part of the base
kernel package:


IIUC the OP is talking about the netinst installer, not an installed 
system. Maybe he encountered a situation where the d-i package 
containing NIC modules was not installed yet, or the installer was damaged.

Re: Raspberry Pi with Debian and LUKS

[Pascal Hambourg]

Le 30/10/2019 à 19:44, basti a écrit :


- setup luks on 3rd partition and edit cryptfs


Can you describe the setup ?
What is cryptfs ? Do you mean /etc/crypttab ?


- update initramfs included crptsetup, lvm, busybox, dm_crypt, dm_mod
- reboot


What it the point in including crypto and LVM support in the initramfs 
if the root filesystem does not use them ?

If Debian 10, is cryptsetup-initramfs installed ?


I'm not ask for passphrase. Boot hangs on "device-mapper"


Please post the complete messages.


I don't know how I can start busybox for debuging in this state.


Add "break" to the kernelcommand line.

Re: Bootable USB Buster System

[Pascal Hambourg]

Le 29/10/2019 à 20:37, Jimmy Johnson a écrit :
the file system you use matters, some file systems only use uefi and 
will give you no legacy support.


Utter nonsense.

Re: Bootable USB Buster System

[Pascal Hambourg]

Le 29/10/2019 à 17:23, deloptes a écrit :

Jimmy Johnson wrote:

I personally do not see a reason why I should mess up with the bios to
switch back and fort to legacy and not legacy


Because some (many ?) UEFI firmwares are defective and having them boot 
a GNU/Linux system in EFI mode can be a real pain. All the UEFI 
firmwares I have used had boot bugs. Legacy boot is usually much easier 
to achieve.



- the one HP I have does not support legacy too.


HP UEFI firmwares were among the most broken ones, ignoring EFI boot 
entries created for GRUB.

Re: Is it a bug that the iptable_filter module isn't loaded automatically with Debian 10 iptables-nft?

[Pascal Hambourg]

Le 28/10/2019 à 09:14, Andy Smith a écrit :


I will take a guess that the switching of the iptables commands to
use the nftables framework has somehow caused this iptable_filter
module to not be loaded even though the firewall still works.


Correct.


Is it a bug that loading rules into the filter table using
iptables-nft command (actually called as "iptables" due to
alternatives) no longer causes iptable_filter module to be loaded
and thus "filter" to appear in /proc/net/ip_tables_names?


No, it is expected. iptable_* modules and /proc/net/ip_tables_names are 
part of the iptables framework. But iptables-nft uses the nftables 
framework (by translating iptables rules into nftables rules).


I understand that a management software using iptables may look up 
/proc/net/ip_tables_names to check whether a tables is active, for 
instance so that it can initialize or list it properly (initializing or 
listing an unused inactive table would needlessly activate it).



Is there a different proc file that will list the active netfilter
tables?


There are no netfilter tables. Tables belong to frameworks running 
inside netfilter such as iptables and nftables.



Is it safe for me to continue forcing the load of the iptable_file
and ip6table_filter modules, or should I stop doing that and seek to
get the management software fixed instead? Though doing that will
need some other way to obtain the same information. >
If it is bad to force load those modules, perhaps I should be using
update-alternatives to go back to using iptables-legacy?


Loading an iptables table makes it process packets needlessly. Also, 
some some iptables extensions are not supported by nftables 
compatibility layer. So yes, IMO you should go back to using 
iptables-legacy, even though I cannot think of any undesirable side 
effect beside performance when the chains are empty with policy ACCEPT.



I am aware that we should be switching to nftables now


IMO there is no hurry yet.

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: Dual boot: one legacy, the other uefi

[Pascal Hambourg]

Le 07/10/2019 à 09:42, Joe a écrit :

On Sun, 6 Oct 2019 23:26:32 +0200
Pascal Hambourg  wrote:


Le 06/10/2019 à 22:45, Beco a écrit :


Now the system can boot both systems ok. But to choose which one
you want, you need to enter the BIOS, change legacy to UEFI, and
vice-versa, then you can boot.


Would you mind telling which systems boots in EFI mode and which one
boots in legacy mode ?


Windows 8/8a/10 boot only in EFI.


I don't think so. Source ?

Re: Dual boot: one legacy, the other uefi

[Pascal Hambourg]

Le 06/10/2019 à 22:45, Beco a écrit :


Now the system can boot both systems ok. But to choose which one you want,
you need to enter the BIOS, change legacy to UEFI, and vice-versa, then you
can boot.


Would you mind telling which systems boots in EFI mode and which one 
boots in legacy mode ?



Not a good way to keep.


Some people think otherwise. It is not the most convenient, but it 
prevents Windows to interfere with GRUB's operation.



Lets give the devices some names.

/dev/sda4 is windows 10
/dev/sda5 is debian buster 10
/dev/sda6 is swap



Grub is installed at sda5 with Debian, but when updated it doesn't
recognize A Windows partition.


Of course not. Both systems must be set up to boot in the same mode.


Can you point me to a possible howto, blog, set of instructions or even
abstract ideas that are in the right direction?


If Windows boots in EFI mode :
Mount the EFI partition on /boot/efi.
Install grub-efi-amd64.
Boot some Linux media in EFI mode.
Chroot into the Debian system, mount the usual pseudo-filesystems 
(/proc, /dev...) and the EFI partition.

Run grub-install.
Run update-grub.
Done.

If Windows boots in legacy mode :
Create a partition with "BIOS boot" type. 100 ko is more than enough.
Install grub-pc.
Done.

Re: fstrim and Luks / dm-raid

[Pascal Hambourg]

Le 05/10/2019 à 21:12, Reco a écrit :



The way I heard it, to trigger the corruption one should issue TRIM
asynchronously *and* utilize NCQ for it. fstrim is synchronous.


Asynchronous and synchronous to what ?


To SSD's I/O queue.


Can you explain what it means or provide any pointers ?

Re: fstrim and Luks / dm-raid

[Pascal Hambourg]

Le 05/10/2019 à 18:27, Reco a écrit :


mdraid and dm-raid have discard disabled by default
with RAID4/5/6 for safety reasons. One must pass the parameter
devices_handle_discard_safely=Y to the module raid456 or dm-raid
respectively to enable it.


I want to make it clear that using this option with drives which do not 
read zeroes from TRIMmed sectors is unsafe.



It's safe only if your SSD firmware is sane and does not corrupt your
data while processing TRIM with NCQ enabled.
For instance, some noname Chinese SSD (ADATA, for instance) can corrupt
your filesystem in such circumstances, Samsung 850 PRO should not.
Manual fstrim invocation seems to be safe.


Why should fstrim be safer that the discard mount option ? AFAIK they
use the same TRIM command.


The way I heard it, to trigger the corruption one should issue TRIM
asynchronously *and* utilize NCQ for it. fstrim is synchronous.


Asynchronous and synchronous to what ?

Re: fstrim and Luks / dm-raid

[Pascal Hambourg]

Le 05/10/2019 à 15:55, Reco a écrit :


On Sat, Oct 05, 2019 at 02:52:55PM +0200, Erwan David wrote:

I've got a computer with 3 SSD in RAID5 (dm-raid) containing a LUKS
partition, then a lvm


dm-raid (device-mapper) or mdraid (mdadm) ?


Is fstrim useful in suc a case ?


It's disabled by default, but you can enable by setting
"issue_discards=1" in lvm.conf, and by adding "discard" option to your
crypttab. There's no SSD-specific mdraid configuration.


Actually there is. mdraid and dm-raid have discard disabled by default 
with RAID4/5/6 for safety reasons. One must pass the parameter 
devices_handle_discard_safely=Y to the module raid456 or dm-raid 
respectively to enable it.


TRIM/discard needs special care with parity RAID (4/5/6). Discarded data 
are useless for the upper layer, but they are still useful for parity 
calculation. So discard is considered safe only if all drives in the 
array consistently return zeroes for discarded data reads.



Should I add the discard option in fstab ?


It's safe only if your SSD firmware is sane and does not corrupt your
data while processing TRIM with NCQ enabled.
For instance, some noname Chinese SSD (ADATA, for instance) can corrupt
your filesystem in such circumstances, Samsung 850 PRO should not.
Manual fstrim invocation seems to be safe.


Why should fstrim be safer that the discard mount option ? AFAIK they 
use the same TRIM command.

Re: disk going bad? or fuser related issues? . . .

[Pascal Hambourg]

Le 04/10/2019 à 16:45, Albretch Mueller a écrit :

  I use ntfs as a data transfer file system between Mac OS, *nix and
Windows (I code primarily in java). Even though while using that
partition through fuser it is noticeable slower, afaik, it is the only
viable option there is.


What does fuser have to do with all this ? Do you mean FUSE ?


  Is that disk partition somehow going bad or there might be something
else going on?


Check the disk with smartctl (from smartmontools) and badblocks.


root@mrme:~# mount --types ntfs --verbose /dev/sdc1 /media/mrme/NTFS
Mount is denied because the NTFS volume is already exclusively opened.
The volume may be already mounted, or another software may use it which
could be identified for example by the help of the 'fuser' command.

$ mount | grep "/dev/sd"

(...)

/dev/sdc1 on /media/mrme/NTFS type fuseblk
(rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096,uhelper=udisks2)


The volume is already mounted.

Re: USB flash drive opens read only -- how to fix?

[Pascal Hambourg]

Le 03/10/2019 à 05:05, David Christensen a écrit :

On 10/1/19 11:51 PM, to...@tuxteam.de wrote:

Yep. Never forget -- there's a whole computer with its own OS in
your flash drive. That "write protect" (sometimes) available as a
physical switch is just communicated to your drivers via some
protocol over USB.

(...)
It was my expectation that the write-protect switch is read by the flash 
drive controller, and that the flash drive controller will enforce 
read-only behavior (e.g. prohibiting writes).  Do you have information 
indicating otherwise?


On the contrary. The usb-storage module has a parameter "quirks" which 
allows to ignore the write-protect flag for a specific vid:pid device (I 
do not remember the exact syntax). I was afraid that it could be used to 
by-pass the write-protect switch so I tested it with my only flash drive 
with a write-protect switch on. Although the kernel considered the drive 
as writable, any write attempt resulted to an error.


It is my understanding that Tomas meant that the write-protect switch 
does not cut the transmission of the electrical write signal to the 
flash memory chips and that the USB mass storage protocol also includes 
rejecting write commands, not only advertising the write-only flag.

Re: USB flash drive opens read only -- how to fix?

[Pascal Hambourg]

Le 01/10/2019 à 23:09, Ken Heard a écrit :


- - after unmounting and closing encryption running as root 'wipefs -a -f
   /dev/sdd' returns 'wipefs: error: /dev/sdd: probing initialization
   failed: Read-only file system'.


The USB flash drive is probably physically write-protected.
Check the kernel logs juste after inserting it for confirmation.

Re: GRUB key repeat too fast

[Pascal Hambourg]

Le 25/09/2019 à 17:27, Alberto Luaces a écrit :

Pascal Hambourg writes:

Le 25/09/2019 à 13:34, Alberto Luaces a écrit :

Pascal Hambourg writes:



I read a report about a similar issue in a Debian-related forum. IIRC,
a workaround was to connect the keyboard to a USB port of different
type (USB 2 -> USB 3 or the other way around).


Thank you! that solves it.  It was indeed the change from 2 → 3 what I did.


Interesting. What is the computer/motherboard/firmware make/model ?
The one reported in a forum was an Aorus x470 Ultra Gaming motherboard.


Close! B450 AORUS M :-)


There must be something wrong is Aorus firmwares.

Also, it was later reported that replacing the keyboard with a different 
model solved the issue. The original keyboard was Logitech G510.

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: GRUB key repeat too fast

[Pascal Hambourg]

Le 25/09/2019 à 13:34, Alberto Luaces a écrit :

Pascal Hambourg writes:


I have searched for a key repeat delay in the manual, but I found
nothing.


Which manual ? GRUB or the computer/motherboard ?


GRUB's.


You won't find anything useful there. By default, the keyboard in GRUB 
is managed by the BIOS/UEFI firmware. The firmware setup may have 
typematic delay and rate settings.



I read a report about a similar issue in a Debian-related forum. IIRC,
a workaround was to connect the keyboard to a USB port of different
type (USB 2 -> USB 3 or the other way around).


Thank you! that solves it.  It was indeed the change from 2 → 3 what I did.


Interesting. What is the computer/motherboard/firmware make/model ?
The one reported in a forum was an Aorus x470 Ultra Gaming motherboard.

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: GRUB key repeat too fast

[Pascal Hambourg]

Le 25/09/2019 à 10:27, Alberto Luaces a écrit :


I have switched to a new computer an existing Debian installation.

At boot time, at the GRUB menu, each key press is repeated very fast, as
if the key repeat delay were close to zero: I can only select either the
first or the last option, since pressing the arrow keys go all the way
up or down.

If, for example, I press 'e' to edit an entry, it is shown, but also
almost 70 'e' characters are typed as well in the editing box.

I have searched for a key repeat delay in the manual, but I found
nothing.


Which manual ? GRUB or the computer/motherboard ?


Does this ring a bell for someone?


I read a report about a similar issue in a Debian-related forum. IIRC, a 
workaround was to connect the keyboard to a USB port of different type 
(USB 2 -> USB 3 or the other way around).

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: issues with initramfs after recently updating buster

[Pascal Hambourg]

Le 08/09/2019 à 02:28, ernst doubt a écrit :


Today I saw the following errors on one of the machines (an HP EliteBook
laptop) that I upgraded today:

update-initramfs: Generating /boot/initrd.img-4.19.0-5-amd64
cryptsetup: WARNING: The initramfs image may not contain cryptsetup binaries
 nor crypto modules. If that's on purpose, you may want to uninstall the
 'cryptsetup-initramfs' package in order to disable the cryptsetup
initramfs
 integration and avoid this warning.
W: Possible missing firmware /lib/firmware/i915/bxt_dmc_ver1_07.bin for module
i915

(...)

These are warnings, not errors.


So I have two questions. On the HP laptop I do use cryptsetup (because it's
older and I originally ran stretch on that machine -- only my homedir is
encrypted (not the entire LV as is the Dell laptop, which is newer and got a
virgin buster install recently). Is there anything I need to do in order to
make sure that I don't lose support for cryptsetup with a new kernel on the HP
laptop?


No. You need to worry about this warning only if /, /usr (if in a 
separate filesystem) or the swap used for hibernation is encrypted 
because these must be opened by the initramfs. Any other encrypted 
device will be opened later by the main init system.


You can uninstall cryptsetup-initramfs (do not worry if it uninstalls 
cryptsetup too, this is a dummy package) to remove the warning.



My 2nd question is about the missing firmware. How do I get modules i915 and
amdgpu so that my initramfs will be fully functional on these laptops (i'm fine
with installing nonfree packages).


For i915 : install firmware-misc-nonfree.
For amdgpu/radeon : install firmware-amd-graphics.
Or install firwmware-linux-nonfree which will pull both.
All are in the non-free section which must be enabled in sources.list.


On one laptop (the HP), when I try to run 'apt-get upgrade' again, the
following message appears:

The following packages have been kept back:
   linux-headers-amd64 linux-image-amd64

On the other laptop (the Dell), 'apt-get upgrade' produces output that
indicates that only linux-image-amd64 has been kept back.


These are meta-packages which depend on the latest available kernel 
packages version. Upgrading them requires installing new kernel 
packages. But apt-get won't install new packages by default. You can 
upgrade them using "apt-get dist-upgrade" or apt-get --with-new-pkgs 
update" or "apt upgrade" (instead of apt-get). Or just install the 
packages as if they were not installed.

Re: What is the location of the "depmod" program on your machine? vmware tools installation error

[Pascal Hambourg]

Le 06/09/2019 à 21:05, Charles Curley a écrit :


Fresh install:

root@jhegaala:~# ll /sbin/depmod /usr/sbin/depmod
lrwxrwxrwx 1 root root 9 Feb  9  2019 /sbin/depmod -> /bin/kmod*
lrwxrwxrwx 1 root root 9 Feb  9  2019 /usr/sbin/depmod -> /bin/kmod*

Upgraded:

root@hawk:~# ll /sbin/depmod /usr/sbin/depmod
ls: cannot access '/usr/sbin/depmod': No such file or directory
lrwxrwxrwx 1 root root 9 Feb  9  2019 /sbin/depmod -> /bin/kmod*


depmod has been in /sbin for ages. What kind of crazy program would 
expect it to be in /usr/sbin ?



Going back to the OP, it appears he has the option to supply the full
path to depmod; perhaps he should try that.


The OP tried to run the script calling depmod as a standard user. The 
user $PATH missing /sbin caused the error. Anyway depmod itself would 
have failed without root privileges.

Re: usr merge apparently breaks amanda

[Pascal Hambourg]

Le 06/09/2019 à 16:39, Gene Heskett a écrit :

On Friday 06 September 2019 10:20:14 Greg Wooledge wrote:


I could very easily see amanda itself breaking from usrmerge, if it
contains programs that try to invoke commands using their full paths
(e.g. /bin/rm -f ...).


Why would that break ? Old paths are still valid, this is the purpose of 
the symlinks.


Before usr merge :
/bin/rm -> ok
/usr/bin/rm -> ko

After usr merge :
/bin/rm -> ok
/usr/bin/rm -> ok

Unless something is unable to follow symlinks.

FAILURE DUMP SUMMARY:
   picnc / lev 0  FAILED [data timeout]
   picnc / lev 0  FAILED [[request failed: No route to host]]
   picnc / lev 0  FAILED [dumper TRYAGAIN: [request failed: No route to
host]]


This is a network error (ARP or NDP address resolution failure). I 
wonder what it has to do with usr merge.

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: Cannot boot after distro upgrade

[Pascal Hambourg]

Le 03/09/2019 à 01:47, Miroslav Skoric a écrit :

On 9/2/19 1:19 AM, Pascal Hambourg wrote:


You should have upgraded the kernel as 
soon as you upgraded from Wheezy to Jessie. Same when upgrading from 
Jessie to Stretch.


Probably you are right. But it makes me wonder why the previous upgrade 
(from Wheezy to Jessie), as well as this one (from Jessie to Stretch) 
did not upgrade the kernel automatically, as it did with other packages.


Because each time you did not follow the release notes chapter about 
upgrading the kernel, and you had not installed a meta-package which 
depends on the latest available kernel.


Unlike most packages, a new kernel version is not a new version of an 
older kernel package, they are different packages (with different names, 
which contain the kernel version). This is why you can have several 
kernel versions installed at the same time. Upgrading a kernel package 
does not bring a new kernel version.


There are two ways to install a new kernel :
- install it manually ;
- install a kernel meta-package linux-image- without a 
specific kernel version in its name which depends on the latest 
available kernel package. When upgraded, il will "pull" the new kernel 
package by dependency.


The Debian installer installs a kernel meta-package by default now.

Re: Cannot boot after distro upgrade

[Pascal Hambourg]

Le 02/09/2019 à 16:44, Miroslav Skoric a écrit :

On 9/2/19 10:28 AM, Reco wrote:


fsck.ext4 -f /dev/localhost/tmp
mount -t ext4 /dev/localhost/tmp /tmp
umount /tmp
fsck.ext4 -f /dev/localhost/tmp

If the mounting succeeds, change filesystem type to ext4 for /tmp in
/etc/fstab, and do the same for /home.


New pictures ... looked to me as the second command (mount) failed.

Btw, somewhere it suggested 'dmesg | tail' so I inserted it too.


It seems that you are still running the old kernel which does not 
support the inline_data feature. You won't be able to mount a filesystem 
with this feature enabled until you run a kernel 3.8 or newer, or 
disable the feature (but tune2fs does not seem to support disabling it).


I dit a bit of testing and it appears that
- mke2fs requires an inode size of 256 to enable inline_data
- tune2fs does not support turning inline_data on or off

So I really wonder how this feature could be turned on on your ext3 
filesystem with an inode size of 128. It looks like metadata corruption. 
Also I am a bit pessimistic about how a newer kernel will react.

Re: Cannot boot after distro upgrade

[Pascal Hambourg]

Le 02/09/2019 à 09:56, Miroslav Skoric a écrit :


lsblk didn't bring any difference regardless the stick is inserted or 
not. So I send photos :-)


There was a wrong free block count on /dev/localhost/tmp, but it seems 
to be corrected now. Anyway this kind of minor error should not prevent 
mounting.


Your display is in low resolution (25 lines) so the beginning of the 
output of dumpe2fs, which contains the filesystem features, is truncated.