- Arch-general - lists.archlinux.org

[arch-general] fail2ban archlinux
by Maykel Franco 18 Feb '21

18 Feb '21

Hi, I've configured fail2ban with action, filter for my php application. My app output log like this: unknown user foo (192.x.x.x) My jail conf: [php-app-login] enabled = true port = 80 protocol = tcp filter = php-app-login logpath = /var/www/php-app-login/var/logs/dev.log findtime = 3600 bantime = 86400 maxretry = 3 ignoreip = 127.0.0.1/8 My filter definition: [Definition] failregex = unknown user .* $<HOST>$ ignoreregex = It works well, but I like fail2ban add comment in iptables rule when add ban IP. For example: iptables -A INPUT -p tcp --dport 80 -m comment --comment "Ban foo" -j DROP iptables -L -n -v Chain INPUT (policy ACCEPT 94 packets, 23457 bytes) pkts bytes target prot opt in out source destination 0 0 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 /* Ban foo */ I've googled and I think something needs to be changed in action but I can't find how to pass the user variable to that action.

2 1

[arch-general] [RFC] Potentially deprecating primus, bumblebee, virtualGL and primus_vk
by Emil Velikov 16 Feb '21

16 Feb '21

Hello all, As some of you may know, I have been an Arch user for over 5 years and a Linux graphics developer working on the whole stack from the kernel DRM all the way up-to Mesa and X. I would like to propose, partially deprecating and potentially removing some of the said packages in light of the development that has been happening over the last few years. tl;dr: these solutions have been partially or completely obsolete, for a while now ## OpenGL/GLX/etc # Background As you know, in the early days we would have both Mesa and vendors provide their own libGL.so.1 and in some cases libglx.so (xorg module). Alongside that drivers lacked dynPM, allowing you to powering off the GPU, when it's not used. To address those primus and bumblebee came about. Note: dynPM is mentioned for completeness, it won't be covered any more. # Since then Nvidia and open source drivers support client - Mesa drivers - since v17.2.0 (at least), packaged 7 Sep 2017 - Nvidia drivers - since v390.25 (at least), packaged 29 Jan 2018 ... and server-side glvnd: - xorg-xserver - since v1.20.6, packaged 23 Nov 2019 - Nvidia drivers - since v435.21, packaged 30 Aug 2019 ## Vulkan # Background On the Vulkan side the drivers are clearly separated from the start - libvulkan_$vendor.so. Yet very few applications would bother selecting the GPU, plus server-side (when using WSI_X11) wasn't complete. GL Vulkan interop was also tricky, with libGL.so.1 being provided by vendors. This resulted in primus_vk. # Since then - Mesa drivers - since 20.1.0, packaged 28 May 2020 Driver selection layer was added, falling back to DRI_PRIME [1] - Nvidia drivers - since v390.25 (at least), packaged 29 Jan 2018 Vulkan implicit layer was added - see [2] ## My proposal: Cleanup the packages, as outlined below and update the wiki. Please check out the Extra notes below. I will be more than happy to tackle this although maintainers will have to push/rebuild the packages for obvious reasons. - primus: replace with a simple compat script primusrun, which a) finds the ID_PATH_TAG for the Nvidia GPU and sets DRI_PRIME=$tag $@ - bumblebee: optirun - replace with script calling primusrun xorg config - should not be needed, double-check and drop bumblebeed - (optionally) remove no longer applicable code, config etc bumblebee - remove no longer applicable group - virtual GL: move to AUR, since it has no more users - primus_vk: replace with a simple compat script pvkrun akin to primusrun, making use of [1] and [2] ## Extra notes: - primus/bumblebee - seemingly been abandoned upstream for 4+ years. Arch maintainers having to carry fixes locally. - primus/virtualgl/primus_vk performance is worse than natively - compat primusrun/optirun/pvkrun are to minimise breakage - some legacy Nvidia drivers may lack support - those drivers live in the AUR, thus a solution for them should also be packaged there. ## Feedback I would love to hear the input from the respective maintainers and the overall Arch developer base as a whole. Is there a particular use-case that I've missed? How would you like this handled - as mentioned above, I'm happy to submit patches be that via Flyspray, email, MR or otherwise. Looking forward to your input -Emil [1] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/1766 [2] http://download.nvidia.com/XFree86/Linux-x86_64/435.17/README/primerenderof…

4 28

[arch-general] knotes crashes on start
by SET 14 Feb '21

14 Feb '21

Hello, Just upgraded and found knotes crashing with this backtrace : (gdb) run Starting program: /usr/bin/knotes [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/libthread_db.so.1". [New Thread 0x7ffff0108640 (LWP 1547)] [New Thread 0x7fffef4d5640 (LWP 1548)] Thread 1 "knotes" received signal SIGSEGV, Segmentation fault. 0x00007ffff7bdd6e3 in ?? () from /usr/lib/libKF5DNSSD.so.5 (gdb) bt #0 0x00007ffff7bdd6e3 in ?? () from /usr/lib/libKF5DNSSD.so.5 #1 0x00007ffff7be7057 in KDNSSD::PublicService::PublicService(QString const&, QString const&, unsigned int, QString const&, QSt ringList const&) () from /usr/lib/libKF5DNSSD.so.5 #2 0x000055555556f869 in ?? () #3 0x0000555555576953 in ?? () #4 0x000055555556ec79 in ?? () #5 0x00007ffff7f02a3b in KontactInterface::PimUniqueApplication::start(QStringList const&) () from /usr/lib/libKF5KontactInterface.so.5 #6 0x000055555556b4f6 in ?? () #7 0x00007ffff5db1b25 in __libc_start_main () from /usr/lib/libc.so.6 #8 0x000055555556b6fe in ?? () Using : KDE Plasma Version: 5.20.5 KDE Frameworks Version: 5.79.0 Qt Version: 5.15.2 This happens launching knotes standalone or embedded in kontact. Don't know if I should report on the KDE forum or if the package maintainer can fix. Thanks for any feedback.

3 2

[arch-general] https://git.archlinux.org/svntogit obsolete?
by Erich Eckner 13 Feb '21

13 Feb '21

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, I was surprised to find git.archlinux.org/svntogit/packages.git/ and git.archlinux.org/svntogit/community.git/ being no longer updated since a few days. I know, there was a github mirror of the repositories set up some time ago - did I miss some deprecation notice for the old locations or is this some oversight on the arch end? regards, Erich -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAl/ffMIACgkQCu7JB1Xa e1qskg//T0HkTdj33ygNCpDNwvDf2H6V1zOBkjadlHrXph4/WkQIyYa7QJxmWXfV d0CWioelIJM4qkBpXrwTa4xMvowW7HLgvpUnCfnXSSaiCODEbJDXC/b0OokHSS9c K+9rGdMgVwfmsMevc/k919ifzmNIUkmX3tOd4lRc1CO6A2EHxFELndY3MbBhpz12 gP599BPvopC+AlYg0MEu1l0/1wAq5p0zSJvneyh2R8LIo8RW/8N7JWnmt0CJf8sM iNiBHvj7byk1Y8uXghibaN9LqLAtRTodhb++Fm5NKdHmlVAnGxrdA3aKlYJYYXsL Q/OYBSTwuhNvxXJnewLtErWjcVu7IL29gPX2Hh7Yhyf+XHScond/Z6WWza3dBYMx rEC9sknS9aSQeuvJqAyfq0mCDQJxbDFAs2p2zh0LG65pbY04yZstmDo/Al+xZV5D wwqedpiTAUVI23m9IePMfxEUnWuRaF5GYeJIa/EFmYn5OXPWMuUO/Y5p2G54QLvX Zwbxu08NDzf+jznhVw2CiP/V7SDMtdLa0hMblvD63z+ywZql0KGIjhiyA9EtXMZm NGQexY5yHyb2R5gKx8e4a7o8ZRJP/n/85laRj3dBYA1ulr5Sp7FCNdYFOLs9xz64 IygVzAJG6Og4kDD7trPl++OwLzaKZ//Qodm3w/+egG3HY75/KvM= =vYL+ -----END PGP SIGNATURE-----

3 3

Re: [arch-general] strip command of binutils 2.36 changes ownership in fakeroot 1.25.3
by Genes Lists 10 Feb '21

10 Feb '21

On 2/10/21 4:35 PM, Levente Polyak via arch-dev-public wrote: > Hi all, > Thanks for the update Levente. Separately, I also note that you briefly put 2.36.1 in testing but then pulled it. AM curious what your thinking was around that version as well (seems to be different issues [1]) thanks. gene [1] https://sourceware.org/pipermail/binutils/2021-February/115240.html

2 2

[arch-general] Mounted ext4 filesystem without journal
by Alexander Kapshuk 08 Feb '21

08 Feb '21

Most probably due to a buggy custom kernel, fsck on /dev/sda2, i.e the root partition, failed with a rootfs prompt and an invitation to run fsck on /dev/sda2 presented. On having done that and rebooted, when performing fsck on /dev/sda2, the system reported that: /dev/sda2 had not been cleanly unmounted 0.4% non-contiguous blocks mounting /dev/sda2 on real root EXT4-fs (sda2) mounted filesystem without journal Root device mounted successfully, but /sbin/init does not exist. The wiki article on fsck troubleshooting, https://wiki.archlinux.org/index.php/Fsck#Troubleshooting, suggests using tune2fs to write a new journal to /dev/sda2. But it doesn't seem to be available when in rootfs. Booting into the Arch Linux installation CD and mounting /dev/sda2 over /mnt reveals lost+found as the sole contents of the directory. As an experiment, mounting /dev/sda1 over /mnt confirms the presence of all the files there are on my boot partition. Any pointers on how to proceed with this would be much appreciated.

5 8

[arch-general] Arch Linux OVH end of support
by Óscar García Amor 08 Feb '21

08 Feb '21

Hi, Seems that Arch Linux will be unsupported in OVH [1] maybe a big warning should be added on the wiki [2], especially considering that the contract with OVH is usually signed for one year. Greetings. [1]: https://services.ovhcloud.com/optiext/optiextension.dll?ID=JbaJfV6QoXt4c_Kt… [2]: https://wiki.archlinux.org/index.php/Arch_Linux_on_a_VPS -- Óscar García Amor | ogarcia at moire.org | http://ogarcia.me

4 5

[arch-general] Change how cross compilers are packaged
by Christer Solskogen 08 Feb '21

08 Feb '21

I've been using the aarch64 cross compiler packages for some time, lately I've also taken a look at how that PKGBUILD looks and how it relates to Cross-compiling tools package guidelines. The situation now is that aarch64-linux-gnu-glibc installs into a sysroot in /usr/aarch64-linux-gnu. Where also aarch64-linux-gnu-binutils installs some files into. This is bad because the sysroot is a directory thats supposed to be reserved for the target system. This is fine on bare-metal systems, but not for linux/mingw targets. What do you think of having /usr/sysroot/$target as sysroots instead for targets that are supposed to be configured that way? Only a small hand full of packages needs to be rewritten (aarch64, mingw-w64 and riscv64) - and I can fix that I (the package maintainers still need to review my changes, as I don't have git access) One other option would be to follow gcc's defaults, which is $prefix/$target/sys-root But before I do that, I'd like some comments if you think this is needed. I don't want to waste time :-) At the same time, I would remove some of the old/deprecated options for binutils, glibc and gcc that are present in the current PKGBUILDs. -- chs

1 0

[arch-general] nsd 4.3.5 broken
by Genes Lists 06 Feb '21

06 Feb '21

Good morning nsd package (4.3.5-1) in testing doesn't start for me. 4.3.4 works but 4.3.5 fails - lacks permission in the working directory. This is what log says: service: Changing to the requested working directory failed: Not a directory service: Failed at step CHDIR spawning /bin/kill: Not a directory service: Control process exited, code=exited, status=200/CHDIR The new service start file has: WorkingDirectory=~ I tried: WorkingDirectory=/etc/nsd but this still fails Thanks.

3 8

[arch-general] DKMS problem with the latest linux-ck kernel
by Randy DuCharme 06 Feb '21

06 Feb '21

Greetings, Seems the latest linux-ck kernel and DKMS don't play well together. The post-install goes something like this: :: Running post-transaction hooks... (1/4) Arming ConditionNeedsUpdate... (2/4) Updating module dependencies... (3/4) Install DKMS modules ==> dkms install --no-depmod -m openrazer-driver -v 2.9.0 -k 5.10.13-3-ck Error! Bad return status for module build on kernel: 5.10.13-3-ck (x86_64) Consult /var/lib/dkms/openrazer-driver/2.9.0/build/make.log for more information. ==> Warning, `dkms install --no-depmod -m openrazer-driver -v 2.9.0 -k 5.10.13-3-ck' returned 10 ==> dkms install --no-depmod -m nvidia -v 390.138 -k 5.10.13-3-ck Error! Bad return status for module build on kernel: 5.10.13-3-ck (x86_64) Consult /var/lib/dkms/nvidia/390.138/build/make.log for more information. ==> Warning, `dkms install --no-depmod -m nvidia -v 390.138 -k 5.10.13-3-ck' returned 10 ==> depmod 5.10.13-3-ck (4/4) Updating linux initcpios... ==> Building image from preset: /etc/mkinitcpio.d/linux-ck.preset: 'default' -> -k /boot/vmlinuz-linux-ck -c /etc/mkinitcpio.conf -g /boot/initramfs-linux-ck.img ==> Starting build: 5.10.13-3-ck -> Running build hook: [base] -> Running build hook: [udev] -> Running build hook: [autodetect] -> Running build hook: [modconf] -> Running build hook: [block] -> Running build hook: [filesystems] -> Running build hook: [keyboard] -> Running build hook: [fsck] ==> ERROR: module not found: `nvidia' ==> ERROR: module not found: `nvidia_modeset' ==> ERROR: module not found: `nvidia_uvm' ==> ERROR: module not found: `nvidia_drm' . . . The pertinent lines in the DKMS logs complain about my GLIBC - mine's at 2.35. CC [M] /var/lib/dkms/nvidia/390.138/build/nvidia/nv-cray.o CC [M] /var/lib/dkms/nvidia/390.138/build/nvidia/nv-dma.o scripts/basic/fixdep: /usr/lib/libc.so.6: version `GLIBC_2.33' not found (required by scripts/basic/fixdep) make[2]: *** [scripts/Makefile.build:279: /var/lib/dkms/nvidia/390.138/build/nvidia/nv-cray.o] Error 1 make[2]: *** Deleting file '/var/lib/dkms/nvidia/390.138/build/nvidia/nv-cray.o' make[2]: *** Waiting for unfinished jobs.... scripts/basic/fixdep: /usr/lib/libc.so.6: version `GLIBC_2.33' not found (required by scripts/basic/fixdep) make[2]: *** [scripts/Makefile.build:279: /var/lib/dkms/nvidia/390.138/build/nvidia/nv-instance.o] Error 1 make[2]: *** Deleting file '/var/lib/dkms/nvidia/390.138/build/nvidia/nv-instance.o' . . . I spent some time scratching around looking for where/how this is configured but so far I haven't figured it out. Can someone point the way? Where is this set? I looked into the kernel fixdep code a little and tried tweaking it some just to see if I could coax it into installing but haven't yet been able to spend a bunch of time on it. Thanks in advance! -- Randall DuCharme (Radio AD5GB) Powered entirely by Open Source software.

2 1