- Arch-general - lists.archlinux.org

Fwd: Does anyone have Fresh Nextcloud Install on PHP-legacy with cache working?
by Paul Dann 27 Sep '23

27 Sep '23

On Fri, 15 Sept 2023, 01:38 David C. Rankin, <drankinatty(a)gmail.com> wrote: > If I duplicate the complete LAMP setup in > docker as well as running my other apps, that will likely make a 4G > Celeron > roll over a croak? On Mon, 18 Sept 2023 at 19:33, Dee Moore <dee42moore(a)gmail.com> wrote: > It's really close, actually. The cost is mostly in storage, a little in > RAM due to the libraries not being shared by other processes. In my real > life experience with redis, it adds about 1-2% CPU overhead. Well worth it. > Sorry, I missed the original question. Yes, I agree with Dee - even with a second webserver as a frontend proxy (I recommend nginx), it's not like doing twice the work - the heavy lifting will be done in the container. There are some small overheads in CPU, a bit more in RAM, and then maybe storage is the most noticeable, but probably nothing compared to what NextCloud is using anyway. Paul

2 1

Any though of having archlinux-keyring-wkd-sync check for iptables and recommend rule?
by David C. Rankin 24 Sep '23

24 Sep '23

Archdevs, Depending on how restrictive the iptables rules, if the IP for archlinux-keyring-wkd-sync falls into a blocked range, the logs quickly fill. An idea is to have the service insert a temporary rule to either (1) allow the IP for the sync check, or (2) allow established, related connections while the service runs. It may also be worth updating the wiki to provide model rules for iptables/nftables to allow archlinux-keyring-wkd-sync to run successfully. Just food for thought. -- David C. Rankin, J.D.,P.E.

6 15

Webkit2gtk 2.42.0-1 upgrade breaks claws mail fancy plugin html rendering
by Richard Ullger 23 Sep '23

23 Sep '23

Hi, As the subject states. The preview pane for html emails is blank. Downgrading webkit2gtk to 2.40.5-2 fixes the issue. Regards, Richard

2 2

New spurious journal entry begins 9/11 - DIGEST-MD5 common mech free
by David C. Rankin 22 Sep '23

22 Sep '23

All, There a number of reports from different distributions over time of spurious log messages of "XXXXX DIGEST-MD5 common mech free" that have been encountered with everything from mail packages to web servers. Starting September 11, this started on Arch with php-legacy installed. On this box I have 32 journals going back to April, 2023, After saving the entries from the journal, it's clear this error started on September 11 and that roughly corresponds to my setup of nextcloud on this box. The journal entries get quite chatty, e.g. Sep 22 06:55:25 2pi httpd[35305]: DIGEST-MD5 common mech free Sep 22 06:58:34 2pi systemd[1]: Started Nextcloud; run cron.php. Sep 22 06:58:36 2pi php-legacy[35340]: DIGEST-MD5 common mech free Sep 22 06:58:36 2pi systemd[1]: nextcloud-cron.service: Deactivated successfully. Sep 22 06:59:58 2pi httpd[35307]: DIGEST-MD5 common mech free Sep 22 07:03:35 2pi systemd[1]: Started Nextcloud; run cron.php. Sep 22 07:03:36 2pi php-legacy[35405]: DIGEST-MD5 common mech free Sep 22 07:03:36 2pi systemd[1]: nextcloud-cron.service: Deactivated successfully. Sep 22 07:08:27 2pi sudo[35454]: david : TTY=pts/1 ; PWD=/home/david ; USER=root ; COMMAND=/usr/bin/journalctl --no-pager --full -f Sep 22 07:08:27 2pi sudo[35454]: pam_unix(sudo:session): session opened for user root(uid=0) by david(uid=1000) Sep 22 07:08:35 2pi systemd[1]: Started Nextcloud; run cron.php. Sep 22 07:08:36 2pi php-legacy[35457]: DIGEST-MD5 common mech free Sep 22 07:08:36 2pi systemd[1]: nextcloud-cron.service: Deactivated successfully. Sep 22 07:08:47 2pi systemd[1]: Reloading Apache Web Server... Sep 22 07:08:47 2pi httpd[35289]: DIGEST-MD5 common mech free Sep 22 07:08:47 2pi httpd[35294]: DIGEST-MD5 common mech free Sep 22 07:08:47 2pi httpd[35308]: DIGEST-MD5 common mech free Sep 22 07:08:47 2pi systemd[1]: Reloaded Apache Web Server. Sep 22 07:08:47 2pi httpd[35310]: DIGEST-MD5 common mech free Sep 22 07:08:47 2pi httpd[35293]: DIGEST-MD5 common mech free Sep 22 07:08:47 2pi httpd[35295]: DIGEST-MD5 common mech free Sep 22 07:08:47 2pi httpd[35296]: DIGEST-MD5 common mech free Sep 22 07:08:47 2pi httpd[35303]: DIGEST-MD5 common mech free Sep 22 07:08:47 2pi httpd[35304]: DIGEST-MD5 common mech free Sep 22 07:08:47 2pi httpd[35309]: DIGEST-MD5 common mech free Sep 22 07:08:50 2pi httpd[35292]: DIGEST-MD5 common mech free Sep 22 07:09:16 2pi httpd[35473]: DIGEST-MD5 common mech free Sep 22 07:09:23 2pi php-fpm-legacy[35063]: pool nextcloud[35063]: DIGEST-MD5 common mech free Sep 22 07:09:30 2pi php-fpm-legacy[35207]: pool nextcloud[35207]: DIGEST-MD5 common mech free Sep 22 07:09:35 2pi httpd[35470]: DIGEST-MD5 common mech free Sep 22 07:13:35 2pi systemd[1]: Started Nextcloud; run cron.php. Sep 22 07:13:36 2pi php-legacy[35525]: DIGEST-MD5 common mech free There are a dozen or so on server startup and then when nextcloud runs it's cron job. Dumping the journal entries, it's clear when it started and it looks like most entries are due to php-legacy, but there are httpd and php-fpm-legacy in there as well e,g, $ jcnl | grep 'DIGEST-MD5 common mech free' > tmp/DIGEST-MD5commonMechFree.txt $ head tmp/DIGEST-MD5commonMechFree.txt Sep 11 02:44:53 2pi php-legacy[12486]: DIGEST-MD5 common mech free Sep 11 02:49:53 2pi php-legacy[12526]: DIGEST-MD5 common mech free Sep 11 02:54:53 2pi php-legacy[12558]: DIGEST-MD5 common mech free Sep 11 03:00:03 2pi php-legacy[12589]: DIGEST-MD5 common mech free Sep 11 03:05:03 2pi php-legacy[12727]: DIGEST-MD5 common mech free Sep 11 03:10:03 2pi php-legacy[12763]: DIGEST-MD5 common mech free Sep 11 03:15:03 2pi php-legacy[12798]: DIGEST-MD5 common mech free Sep 11 03:20:13 2pi php-legacy[12895]: DIGEST-MD5 common mech free Sep 11 03:25:13 2pi php-legacy[25576]: DIGEST-MD5 common mech free Sep 11 03:30:13 2pi php-legacy[25691]: DIGEST-MD5 common mech free Is this something of concern or just something that is chatty but does no harm? -- David C. Rankin, J.D.,P.E.

1 0

bash 5.2 and BASH_COMPAT question
by Genes Lists 19 Sep '23

19 Sep '23

Hi: I believe that bash 5.2 was/is held back due to incompatible Changes with 5.1 [1]. The obvious first thought would be to set BASH_COMPAT="5.1" globally and then update to the current 5.2 version. This would work for any shell which sees the BASH_COMPAT variable. User login shells, users running things which in turn invoke bash would get the variable passed down. Users who want to use the 5.2 features would have the ability to unset the variable - but recognizing the caveat below. I do see one caveat (may be others): When bash is invoked from a non-login shell without the BASH_COMPAT variable or from a tool which cleans it's env before invoking bash, those would need adjusting to set their own BASH_COMPAT variable should they depend on the 5.1 behavior or be changed to support 5.2 Which leads to: - do we have a list of tools that invoke bash but clean env variables before doing so? (pacman perhaps) - is their a task list of what needs to be done (either fix the incompatibilities or push the BASH_COMPAT variable down). - what else needs to be done to allow us to update to 5.2 Thoughts? thanks gene [1] https://github.com/bminor/bash/blob/master/COMPAT

2 2

gdm3 stalled
by Zener 19 Sep '23

19 Sep '23

After an upgrade several months ago, gdm3 get stalled at each boot and gnome can't run properly. So, I've disabled gdm.service and gnome start properly without gdm. All the upgrade system in these months have not been able to solve. Could you help me to do an useful debug in order to solve? Thanks.

3 9

keyboard shortcut became really slow after update.
by Zener 19 Sep '23

19 Sep '23

After an update in june/july keyboard shortcut became really slow (and gdm doesn’t work any more). I use wayland on Arch. Could you help me to solve please? tnks.

1 1

Does anyone have Fresh Nextcloud Install on PHP-legacy with cache working?
by David C. Rankin 18 Sep '23

18 Sep '23

All, I've spent a few days trying to get either APCu or Redis (or both) caching working with a fresh install of nextcloud on php-legacy. Nextcloud works fine and I can enable both caches per the wiki but adding anything to /etc/webapps/nextcloud/config/config.php as shown in the wiki immediately results in an "Internal server error" crash of nextcloud. A full explanation of all steps tried is in https://bbs.archlinux.org/viewtopic.php?id=288622 Does anyone have nextcloud 27.0.2 running on php-legacy with APCu or Redis (or both) enabled and working? Something is really wrong here. -- David C. Rankin, J.D.,P.E.

3 3

Archlinux Con
by Hritik Vijay 17 Sep '23

17 Sep '23

Hello I attended debconf23 yesterday and it got me wondering about Arch Cons. According to what I've seen, we mostly had online cons (if any). Can we plan for an offline con for archlinux ? Is there enough interest around it ? Are there enough sponsors for us (｡◕‿‿◕｡) ? Hritik

1 0

Arch Mailing List queries
by Polarian 16 Sep '23

16 Sep '23

Hello, So I have two things I would like to address which I have realised: Firstly is the fact that Arch Linux almost always picks IPv4 over IPv6 when delivery the mail. I am aware this is not a big issue because I still receive the email but Arch Linux has full support for IPv6, and I would like to have it used (especially for the hope in the future we can all use single stack IPv6 and get rid of legacy IPv4). I believe this is not an issue with Arch Linux, but the mailing list software used (which I believe is mailman). I have discussed the same issue with the Gajim developers on XMPP. I believe GNU mailman uses Happy Eyeballs (like which Gajim uses) (more info: https://en.wikipedia.org/wiki/Happy_Eyeballs) which when I test it on my network for about 200-300 attempts, IPv6 is picked 299/300 of the times, so I should be seeing almost always IPv6, but I get the opposite. I assume GNU mailman uses the GNU python network library (forgot what it is called) which contains a Happy Eyeballs implementation (the same one Gajim uses). So there is a strong likelihood that it is an issue with the library being biased towards picking IPv4 over IPv6, because I do not have this issue with any other software. So this is not something which Arch is responsible for, but if anyone has more information about this, I would be grateful to be given it :) I did think for a while I had setup IPv6 incorrectly, but when I see Microsoft delivering emails solely over IPv6 (not a single use of IPv4), I do not believe it is an issue on my end, but correct me if I am wrong :D The second issue I want to bring up is the issue of gmail (and also sometimes outlook emails) spamming my emails. I have a few thoughts on this: - Google employs IP whitelisting, my email server is small and thus is suspicious, other small email servers know the going trend of "it being impossible to stay out of gmail spam folders", even legitimate emails from big companies sometimes end up in gmail spam, so for those who keep complaining about my emails being put into your spam, it is not an issue on my end, I have checked numerous times. - DKIM signatures are broken in transit, and depending on how the spam filter classifies something as spam, it could be picked up as a incorrect DKIM signature and thus spammed instantly, I will use David Rankin's email from this morning as a reference for this (https://lists.archlinux.org/archives/list/arch-general@lists.archlinux.org/…) Here are the relevant headers: Received: from mail.polarian.dev by email with LMTP id +Pw5ALfTAmV1LwAAotfoXQ (envelope-from <arch-general-bounces(a)lists.archlinux.org>) for <polarian@localhost>; Thu, 14 Sep 2023 09:34:47 +0000 Received: from lists.archlinux.org (lists.archlinux.org [IPv6:2a01:4f9:c010:9eb4::1]) by mail.polarian.dev (Postfix) with ESMTPS id 9B5AB10A0772 for <polarian(a)polarian.dev>; Thu, 14 Sep 2023 09:34:46 +0000 (UTC) Authentication-Results: mail.polarian.dev; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=(a)gmail.com header.a=rsa-sha256 header.s=20221208 header.b=S2HFsXca Received: from lists.archlinux.org (localhost [IPv6:::1]) by lists.archlinux.org (Postfix) with ESMTP id AD29AF4E9A0; Thu, 14 Sep 2023 09:34:30 +0000 (UTC) Received: from mail-oo1-xc35.google.com (mail-oo1-xc35.google.com [IPv6:2607:f8b0:4864:20::c35]) by lists.archlinux.org (Postfix) with ESMTPS id 3AC84F4E993 for <arch-general(a)lists.archlinux.org>; Thu, 14 Sep 2023 09:34:20 +0000 (UTC) Authentication-Results: lists.archlinux.org; dkim=pass header.d=gmail.com header.s=20221208 header.b=S2HFsXca; spf=pass (lists.archlinux.org: domain of drankinatty(a)gmail.com designates 2607:f8b0:4864:20::c35 as permitted sender) smtp.mailfrom=drankinatty(a)gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-oo1-xc35.google.com with SMTP id 006d021491bc7-57355a16941so450114eaf.2 for <arch-general(a)lists.archlinux.org>; Thu, 14 Sep 2023 02:34:20 -0700 (PDT) Sorry for the bad formatting, and apologies to David Rankin for using your email headers as a reference, but I assume its fine because it was posted to a public mailing list which we can already see, its public information, but if you do mind, I am sorry. The bottom hop is just google hopping the email between their servers, but once it hits lists.archlinux.org you can see that the authentication results is that it passes both spf and dkim, also I would like to draw attention to the fact that it was delivered to the mailing list via IPv6, which does show that IPv6 is definitely functioning on Arch's end. It is then hopped to my mail server, this was the only email which I have so far which was hopped to me via IPv6, so I was amazed when I saw it, so it definitely seems to be a issue with Happy Eyeballs. Anyways back to the topic, the signature then fails dkim validation (Yes I do not currently check spf, ip address spoofing is trivial compared to cryptographic signing and thus I was lazy and haven't yet bothered (its been over a year since my current mail server was configured :P). I assume that Google with their strict (and pointless) spam filter, sees that their mail server has failed to validate dkim and spams said email. I know I am not the only person being spammed too, I have seen other people being informed "hey your email was spammed for me", and 9 times out of 10 its those who self host, and thus are less known. Welcome to Googles dictatorship on email. I believe people running rspamd picks up that further down the hop chain it was valid, and thus takes that into account possibly, because I haven't heard people struggling to pass rspamd filtering. The reason for me bringing this up is getting an email every time I post to a mailing list from 3 different people complaining how google spammed my emails is a pain, and heres the kicker, half the time DKIM is valid and half the time it is broken when hopping through lists.archlinux.org, so wrap your ahead around that one! If you are getting legitimate emails spammed, then you either need to relax your email spam filter, or simply get used to checking your spam often to pull legitimate emails out. Personally I do not employ a spam filter, because just the likelihood of a legitimate email being spammed or bounced is a bad idea in my mind. As people complain about my email length, I will give a TL;DR: - Arch Linux (or GNU mailman) seems to have issues when it comes to picking between IPv4 and IPv6. - DKIM signatures are randomly broken when passing through lists.archlinux.org - If emails from the mailing list are being spammed, it might be wise to relax your spam settings, as even fully verified emails can be spammed from companies like google simply because their AI doesn't like the content of said email, or their IP whitelist doesn't include the sender. Maybe I should start putting a TL;DR at the top of every email? and then below that is the usual email with all the context and explanation. If someone thinks this is a good idea let me know (any way for me to annoy people less is a good thing :P) Any advice on how to improve (or hopefully fix) the two above issues would be highly appreciated. Take care, -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian(a)icebound.dev

6 6