Re: Debian 12 - IPv4 blocked without fail2ban & co
On Fri, Sep 8, 2023 at 10:52 PM Max Nikulin wrote: > On 08/09/2023 04:39, Romain wrote: > > I can confirm that when this happens, it's the OVH server that fails to > > send the response to my network. > > > > 35 9.862648672 MY_PUBLIC_IP_AT_HOME → 54.38.38.159 ICMP 78 Echo (ping) > > request id=0x4b30, seq=33150/32385, ttl=1 > > 36 9.862704895 54.38.38.159 → MY_PUBLIC_IP_AT_HOME ICMP 106 Destination > > unreachable (Port unreachable) > Your hosting company may have PING flood protection. If you are running a constant PING from your PC to your server it could be detected as a PING flood. Are you able to SSH to the server while the PING is failing? > Some intermediate firewall may have specific rules for ICMP. > > It is better to try tcpdump (its capture file may be later loaded to > wireshark) for HTTP and SSH packets at 54.38.38.159 and 192.168.0.2 > rpi4.home, or if your router allows it, even better at 192.168.0.1 > livebox.home. > > > -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/ ⠈⠳⣄⠀⠀
Re: Debian 12 - IPv4 blocked without fail2ban & co
On 08/09/2023 04:39, Romain wrote: I can confirm that when this happens, it's the OVH server that fails to send the response to my network. 35 9.862648672 MY_PUBLIC_IP_AT_HOME → 54.38.38.159 ICMP 78 Echo (ping) request id=0x4b30, seq=33150/32385, ttl=1 36 9.862704895 54.38.38.159 → MY_PUBLIC_IP_AT_HOME ICMP 106 Destination unreachable (Port unreachable) Some intermediate firewall may have specific rules for ICMP. It is better to try tcpdump (its capture file may be later loaded to wireshark) for HTTP and SSH packets at 54.38.38.159 and 192.168.0.2 rpi4.home, or if your router allows it, even better at 192.168.0.1 livebox.home.
Re: usrmerge on root NFS will not be run automatically
> root@foobar:~# /usr/lib/usrmerge/convert-usrmerge > > FATAL ERROR: > Both /lib/udev/rules.d/60-libsane1.rules and > /usr/lib/udev/rules.d/60-libsane1.rules exist. The problem is that "usrmerge" needs to unify those two and doesn't know how. So you need to do it by hand. E.g. get rid of one of those two (or maybe if you can make them 100% identical `usrmerge` will be happy as well). Stefan
Re: usrmerge on root NFS will not be run automatically
On Fri, 8 Sep 2023 16:55:23 +0200 zithro wrote: > On 08 Sep 2023 12:54, Marco wrote: > >Warning: NFS detected, /usr/lib/usrmerge/convert-usrmerge will > > not be run automatically. See #842145 for details. > > Read : > - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=842145 “I repeated it a few times. I had to restart various services in between retries (I think I restarted everything by the end). Eventually it succeeded.” I tried it 30 times to no avail. The report doesn't offer another solution. > - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039522 “instead of converting the client, convert the server first.” I don't want to convert the server. The server is running fine and has no issues. I don't have a clue what this has to do with the server. “So there is a workaround when your NFS server is a Linux machine and you may use chroot on it, at least.” The server doesn't run Linux. So also no solution there. > carefully copy the files over a Linux machine, chroot+convert > there, then move back to the NFS server. That is quite an involved task. I didn't expect such fiddling for a simple OS update. I'm a bit worried that the permissions and owners go haywire when I copy stuff directly off the server onto a VM and back onto the server. Is there a recommended procedure or documentation available? > Can help: > https://unix.stackexchange.com/questions/312218/chroot-from-freebsd-to-linux I cannot install stuff on the server unfortunately. Thanks for your quick reply. Marco
Re: usrmerge on root NFS will not be run automatically
On 08 Sep 2023 12:54, Marco wrote:
Warning: NFS detected, /usr/lib/usrmerge/convert-usrmerge will not be run
automatically. See #842145 for details.
Read :
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=842145
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039522
The solution would be :
"convert-usrmerge can be run in a chroot on the NFS server"
If your NFS server is not Linux-based, carefully copy the files over a
Linux machine, chroot+convert there, then move back to the NFS server.
Make backups ;)
Can help:
https://unix.stackexchange.com/questions/312218/chroot-from-freebsd-to-linux
As per the why, I don't know.
Maybe the symlink handling by NFS ?
Reading the script "/usr/lib/usrmerge/convert-usrmerge", you get the
reasons why it fails :
142 # The other cases are more complex and there are some corner
cases that
143 # we do not try to resolve automatically.
144
145 # both source and dest are links
[...]
168 # the source is a link
[...]
175 # the destination is a link
[...]
191 # both source and dest are directories
192 # this is the second most common case
You may change the script to detect where/why it fails, so edit
fatal("Both $n and /usr$n exist");
to
fatal("Both $n and /usr$n exist - err line 145");
fatal("Both $n and /usr$n exist - err line 168");
Also found this on
"https://en.opensuse.org/openSUSE:Usr_merge#Known_Problems"; :
- "File systems that do not support RENAME_EXCHANGE such as ZFS or NFS
cannot perform live conversion (Bug 1186637)"
- "Conversion fails if there's a mount point below
(/usr)/{bin,sbin,lib,lib64}"
Good luck
--
++
zithro / Cyril
usrmerge on root NFS will not be run automatically
Hi, I'm in the process of upgrading my Debian stable hosts and run into a problem with usrmerge: Setting up usrmerge (35) ... Warning: NFS detected, /usr/lib/usrmerge/convert-usrmerge will not be run automatically. See #842145 for details. E: usrmerge failed. dpkg: error processing package usrmerge (--configure): installed usrmerge package post-installation script subprocess returned error exit status 1 Errors were encountered while processing: usrmerge E: Sub-process /usr/bin/dpkg returned an error code (1) True, root is mounted via NFS. So I ran usrmerge manually: root@foobar:~# /usr/lib/usrmerge/convert-usrmerge FATAL ERROR: Both /lib/udev/rules.d/60-libsane1.rules and /usr/lib/udev/rules.d/60-libsane1.rules exist. You can try correcting the errors reported and running again /usr/lib/usrmerge/convert-usrmerge until it will complete without errors. Do not install or update other Debian packages until the program has been run successfully. It instructs me to: You can try correcting the errors reported and running again But it's not mentioned anywhere *how* to correct those errors. It's true that both files exist. I've read https://wiki.debian.org/UsrMerge But the page doesn't cover the error I face. How to fix the error? Is there a command I can run (e.g. rsync?) to fix whatever usrmerge complains about? Like keeping only the newest file or deleting the old one? I feel there's very little info out there how to recover from this situation. Any tips are much appreciated. Marco Debian stable 6.1.0-11-amd64
qtcreator: no qml utility
Hello, on Debian 12 (Plasma Desktop) i've installed qtcreator from Debian repository. In the settings of qtcreator the qt 5.15.8 is listed as Qt version. But with a exclamation mark. Below i see "no QML utility installed". But if i execute on cmdline qml -v the output is Qml Runtime 5.15.8 "which qml" says /usr/bin/qml This packages are installed: apt install qtcreator qml build-essential qtbase5-dev qt5-qmake cmake Why qtcreator does not detect the qml utility ? What is missing ? kind regards Petric
