bug#37631: service zabbix-server (and zabbix-agent) fails starting (cannot run as root!)

[Giovanni Biscuolo]

Hi Guix,

executive summary: do we really need to start zabbix_server in
foreground mode?

I have a Guix System in which I defined this services (thanks to the
work in guix-maintenance):

--8<---cut here---start->8---
   ;; For the Zabbix database.  It was created by manually
   ;; following the instructions here:
   ;; 
https://www.zabbix.com/documentation/4.2/manual/appendix/install/db_scripts
   (postgresql-service)

   ;; Monitoring

   (service zabbix-agent-service-type)

   (service zabbix-server-service-type
(zabbix-server-configuration
 (include-files '("/root/secrets/zabbix-server-dbpass"))
 (log-type "file")))

   (service zabbix-front-end-service-type
(zabbix-front-end-configuration
 (nginx (list
 (nginx-server-configuration
  (root #~(string-append #$zabbix-server:front-end 
"/share/zabbix/php"))
  (listen '("7878"))
  (index '("index.php"))
  (locations
   (let ((php-location (nginx-php-location)))
 (list (nginx-location-configuration
(inherit php-location)
(body (append 
(nginx-location-configuration-body php-location)
  (list "
fastcgi_param PHP_VALUE \"post_max_size = 16M 
  max_execution_time = 300\";
"))
   (db-secret-file 
"/root/secrets/zabbix-front-end-dbpass"
--8<---cut here---end--->8---

The zabbix frontend service is running well but the zabbix-server
refuses to start

--8<---cut here---start->8---
$ herd start zabbix-server
Service zabbix-server could not be started.
herd: failed to start service zabbix-server
--8<---cut here---end--->8---

looking in the current system profile (built with a guix master branch
on 27 Sept)

--8<---cut here---start->8---
Generation 12   Sep 27 2019 21:18:26(current)
  file name: /var/guix/profiles/system-12-link
  canonical file name: /gnu/store/h03qdv70sgndclgp04dpkka4rqlk9fg3-system
  label: GNU with Linux-Libre 5.2.17
  bootloader: grub
  root device: UUID: 9862e534-946d-4323-b7ce-9937661bdb7d
  kernel: /gnu/store/bjs8k11phqhn39n7cs1wix5x147fwhnn-linux-libre-5.2.17/bzImage
--8<---cut here---end--->8---

I found the shepherd uses
/gnu/store/lm1d60d0kra3z86hcjmav828cfxjcgi8-shepherd-zabbix-server.scm
with this (partial) parameters:

--8<---cut here---start->8---
#:start (make-forkexec-constructor (list 
"/gnu/store/qcm5j0wk8rs6ykn6b10vg8awf2v6kvx1-zabbix-server-4.2.0/sbin/zabbix_server"
 "--config" "/gnu/store/w1vgvlbzs3jks014r5dra7ih6g7r26n7-zabbix_server.conf" 
"--foreground") #:user "zabbix" #:group "zabbix" #:pid-file 
"/var/run/zabbix/zabbix_server.pid"
--8<---cut here---end--->8---

and if I try to start it from the command line:

--8<---cut here---start->8---
/gnu/store/qcm5j0wk8rs6ykn6b10vg8awf2v6kvx1-zabbix-server-4.2.0/sbin/zabbix_server
 --config /gnu/store/w1vgvlbzs3jks014r5dra7ih6g7r26n7-zabbix_server.conf 
--foreground
--8<---cut here---end--->8---

I get:

--8<---cut here---start->8---
zabbix_server [879]: cannot run as root!
--8<---cut here---end--->8---

I had a look in upstream bug reports but was not able to find nothing
strictly related to zabbix_server, but I was able fo find this for
zabbix_agentd https://support.zabbix.com/browse/ZBX-10611 (fixed since
4.2.1rc1)

actually if I start zabbix_server without ``--foreground'' the server
starts without problems

I thought upgrading to the last stable release of zabbix was the
solution, so I submitted a patch (bug#37629) to upgrade to 4.2.7 and now
I'm using a custom channel with that patch applied:

--8<---cut here---start->8---
(list (channel
(name 'guix)
(url "https://gitlab.com/gbiscuolo/guix.git";)
(branch "wip-zabbix-update")))
--8<---cut here---end--->8---

but if I switch to my last system generation (built with the above channel):

--8<---cut here---start->8---
Generation 13   Oct 05 2019 10:24:28
  file name: /var/guix/profiles/system-13-link
  canonical file name: /gnu/store/bmmjbk6sidqjahq0i53mgp38b342lnda-system
  label: GNU with Linux-Libre 5.3.2
  bootloader: grub
  roo

bug#37593: [core-updates] Linux-Libre fails to build on aarch64-linux

[Marius Bakke]

Pierre Langlois  writes:

> Hi Marius,
>
> Marius Bakke writes:
>
>> Berlin fails to build "linux-libre" for AArch64 on the 'core-updates'
>> branch.  Here is a recent attempt:
>>
>> https://ci.guix.gnu.org/build/1758844/details
>>
>> Log file for the latest build:
>>
>> https://ci.guix.gnu.org/log/aq2rnrmjsgnyk8vmsm7aa3mgdj39dcwh-linux-libre-5.2.17.drv
>>
>> This seems to be the salient bit:
>>
>> CC [M]  arch/arm64/lib/xor-neon.o
>> In file included from 
>> /gnu/store/nr1aw4i32h7rmxwmq7d2da0mwcwg551j-glibc-2.29/include/stdint.h:34:0,
>>  from 
>> /gnu/store/yckkivhynk4hjcr0iry9vbcyc0lqqnxj-gcc-7.4.0-lib/lib/gcc/aarch64-unknown-linux-gnu/7.4.0/include/arm_neon.h:33,
>>  from ./arch/arm64/include/asm/neon-intrinsics.h:33,
>>  from arch/arm64/lib/xor-neon.c:11:
>> /gnu/store/nr1aw4i32h7rmxwmq7d2da0mwcwg551j-glibc-2.29/include/bits/stdint-intn.h:27:19:
>>  error: conflicting types for 'int64_t'
>>  typedef __int64_t int64_t;
>>^~~
>> In file included from ./include/linux/list.h:5:0,
>>  from ./include/linux/module.h:9,
>>  from arch/arm64/lib/xor-neon.c:10:
>> ./include/linux/types.h:114:15: note: previous declaration of 'int64_t' was 
>> here
>>  typedef s64   int64_t;
>>^~~
>> In file included from 
>> /gnu/store/nr1aw4i32h7rmxwmq7d2da0mwcwg551j-glibc-2.29/include/stdint.h:37:0,
>>  from 
>> /gnu/store/yckkivhynk4hjcr0iry9vbcyc0lqqnxj-gcc-7.4.0-lib/lib/gcc/aarch64-unknown-linux-gnu/7.4.0/include/arm_neon.h:33,
>>  from ./arch/arm64/include/asm/neon-intrinsics.h:33,
>>  from arch/arm64/lib/xor-neon.c:11:
>> /gnu/store/nr1aw4i32h7rmxwmq7d2da0mwcwg551j-glibc-2.29/include/bits/stdint-uintn.h:27:20:
>>  error: conflicting types for 'uint64_t'
>>  typedef __uint64_t uint64_t;
>> ^~~~
>> In file included from ./include/linux/list.h:5:0,
>>  from ./include/linux/module.h:9,
>>  from arch/arm64/lib/xor-neon.c:10:
>> ./include/linux/types.h:112:15: note: previous declaration of 'uint64_t' was 
>> here
>>  typedef u64   uint64_t;
>>^~~~
>> make[1]: *** [scripts/Makefile.build:285: arch/arm64/lib/xor-neon.o] Error 1
>> make: *** [Makefile:1073: arch/arm64/lib] Error 2
>> make: *** Waiting for unfinished jobs
>>
>> Not sure what's going on here.  Ideas?
>
> Ha, that looks familiar, the same issue happened back in July:
> https://lists.gnu.org/archive/html/guix-devel/2019-07/msg00175.html
>
> I don't think we worked out what was the problem exactly though :-/

So I was able to build it with this patch:

From 43d2ab5a046e5da378f062cb2885c1345278d378 Mon Sep 17 00:00:00 2001
From: Marius Bakke 
Date: Fri, 4 Oct 2019 21:36:42 +0200
Subject: [PATCH] gnu: linux-libre: Hide glibc from CPATH during build.

Fixes .

* gnu/packages/linux.scm (make-linux-libre*)[arguments]: Drop "libc" from CPATH.
---
 gnu/packages/linux.scm | 13 +
 1 file changed, 13 insertions(+)

diff --git a/gnu/packages/linux.scm b/gnu/packages/linux.scm
index dda95c29ac..525b18d1e2 100644
--- a/gnu/packages/linux.scm
+++ b/gnu/packages/linux.scm
@@ -663,6 +663,7 @@ for ARCH and optionally VARIANT, or #f if there is no such configuration."
  `(#:modules ((guix build gnu-build-system)
   (guix build utils)
   (srfi srfi-1)
+  (srfi srfi-26)
   (ice-9 match))
#:phases
(modify-phases %standard-phases
@@ -679,6 +680,18 @@ for ARCH and optionally VARIANT, or #f if there is no such configuration."
  ,@(if (%current-target-system)
'((unsetenv "CROSS_CPATH"))
'())
+
+ ;; On AArch64 (at least), we need to remove glibc headers from CPATH
+ ;; (they are still available as "system headers"), so that the kernel
+ ;; can override uint64_t.  See .
+ (setenv "CPATH"
+ (string-join
+  (remove (cut string-prefix? (assoc-ref inputs "libc") <>)
+  (string-split (getenv "CPATH") #\:))
+  ":"))
+ (format #t "environment variable `CPATH' changed to `~a'~%"
+ (getenv "CPATH"))
+
  ;; Avoid introducing timestamps
  (setenv "KCONFIG_NOTIMESTAMP" "1")
  (setenv "KBUILD_BUILD_TIMESTAMP" (getenv "SOURCE_DATE_EPOCH"))
-- 
2.23.0


It's not very pretty though.  Thoughts?


signature.asc
Description: PGP signature

bug#37631: service zabbix-server (and zabbix-agent) fails starting (cannot run as root!)

[Giovanni Biscuolo]

Giovanni Biscuolo  writes:

> executive summary: do we really need to start zabbix_server in
> foreground mode?

executive answer: I don't know **but** this is not the cause of my issue
:)

> --8<---cut here---start->8---

[...]

>(service zabbix-server-service-type
>   (zabbix-server-configuration
>(include-files '("/root/secrets/zabbix-server-dbpass"))
>(log-type "file")))

ouch!... looking at the console (it's a remote VM so I usually connect
via ssh only, but today I also connected via SPICE):

--8<---cut here---start->8---
zabbix_server [1942]: /root/secrets/zabbix-server-dbpass: [13] Permission denied
--8<---cut here---end--->8---

unfortunately shepherd did not catch this error (due to foreground
mode?) in syslog :-(

I just had to adjust the permissions to allow zabbix (I allowed the
zabbix group to traverse /root/secrets and read the file) to read the
included file

this now works with both zabbix 4.2.0 and zabbix 4.2.7

[...]

Thanks! Gio'

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

bug#37605: [core-updates] MariaDB fails tests on armhf-linux

[Marius Bakke]

Marius Bakke  writes:

> "mariadb" consistently fails a single test on the core-updates branch on
> armhf-linux:
>
> https://ci.guix.gnu.org/build/1689172/details
>
> [...]
>
> This does not happen on current 'master', so the problem was introduced
> somewhere in between ccbc1c5eb..cbc8c658d.

Upstream bug report here:

https://jira.mariadb.org/browse/MDEV-20573

I'm not sure what to do about it.  We could skip it, but then users who
rely on encrypted binary logs could potentially get in trouble.  I
haven't found a compile-time flag to disable just this one feature.

Thoughts?


signature.asc
Description: PGP signature

bug#37501: [core-updates] Entropy starvation during boot

[Marius Bakke]

Ludovic Courtès  writes:

> Ludovic Courtès  skribis:
>
>> I read some of these, and our ‘urandom-seed-service-type’ has the same
>> bug as .  Namely, we
>> write the previous seed to /dev/urandom but we don’t credit the
>> entropy.
>
> Now that I think about it, ‘urandom-seed’ normally contributes 512 bytes
> of entropy, but immediately after it *consumes* 512 bytes of entropy:
>
>   ;; Immediately refresh the seed in case the system doesn't
>   ;; shut down cleanly.
>   (call-with-input-file "/dev/urandom"
> (lambda (urandom)
>   (let ((previous-umask (umask #o077))
> (buf (make-bytevector 512)))
> (mkdir-p (dirname #$%random-seed-file))
> (get-bytevector-n! urandom buf 0 512)
> (call-with-output-file #$%random-seed-file
>   (lambda (seed)
> (put-bytevector seed buf)))
> (umask previous-umask
>
> This comes from commit 71cb237a7d98dafda7dfbb5f3ba7c68463310383 by Leo.
>
> What about deleting the seed instead of populating it right at boot
> time?
>
> That way, we would actually have entropy available at boot time.  In
> case of a crash, the system may lack entropy upon reboot, but that’s
> better than always lacking entropy when booting.
>
> Marius, Leo, WDYT?

I tried it, but it did not make any discernible difference in the
available entropy right after boot, nor did it aid the CRNG seeding.

So I think we should go with Linus' solution for now, as well as your
original fix Ludo because it seems to be the right thing to do anyway.


signature.asc
Description: PGP signature

bug#37347: 'guix environment' fails after trying to follow the steps from "Running Guix Before It Is Installed" page

[Marius Bakke]

Bengt Richter  writes:

> On +2019-10-04 09:15:56 +0200, Jelle Licht wrote:
>> Bengt Richter  writes:
>> 
>> > [snip]
>> > ...
>> > [19:40 ~/bs]$ ping guix.gnu.org
>> > ping: guix.gnu.org: Name or service not known
>> I actually have this sometimes as well. Are you on a less-than-stellar
>> WiFi-connection perhaps? I noticed the default (nscd?) configuration on
>> Guix systems caches 'negative' results for quite a while.
>> 
>> Could you try this command again after issuing:
>> `sudo herd invalidate nscd hosts'?
>> 
>> HTH!
>> - Jelle
>
> Hi Jelle, thanks for your reply.
>
> I am a grateful courtesy guest sharer of internet access in
> a small office complex via cat5 to their switches, so it should
> not be a WiFi problem.
>
> I get DNS automatically along with ip from their server dhcp,
> but I have other options I could explore.
>
> I can't try the herd command right now, as I am in strictly "foreign"
> mode at the moment.

If you are using systemd, perhaps you are hitting
?

Does it work if you create /etc/resolv.conf with a "nameserver x.x.x.x"
entry?


signature.asc
Description: PGP signature

bug#37593: [core-updates] Linux-Libre fails to build on aarch64-linux

[Gábor Boskovits]

Hello Marius,

Marius Bakke  ezt írta (időpont: 2019. okt. 5., Szo,
14:40):

> Pierre Langlois  writes:
>
> > Hi Marius,
> >
> > Marius Bakke writes:
> >
> >> Berlin fails to build "linux-libre" for AArch64 on the 'core-updates'
> >> branch.  Here is a recent attempt:
> >>
> >> https://ci.guix.gnu.org/build/1758844/details
> >>
> >> Log file for the latest build:
> >>
> >>
> https://ci.guix.gnu.org/log/aq2rnrmjsgnyk8vmsm7aa3mgdj39dcwh-linux-libre-5.2.17.drv
> >>
> >> This seems to be the salient bit:
> >>
> >> CC [M]  arch/arm64/lib/xor-neon.o
> >> In file included from
> /gnu/store/nr1aw4i32h7rmxwmq7d2da0mwcwg551j-glibc-2.29/include/stdint.h:34:0,
> >>  from
> /gnu/store/yckkivhynk4hjcr0iry9vbcyc0lqqnxj-gcc-7.4.0-lib/lib/gcc/aarch64-unknown-linux-gnu/7.4.0/include/arm_neon.h:33,
> >>  from ./arch/arm64/include/asm/neon-intrinsics.h:33,
> >>  from arch/arm64/lib/xor-neon.c:11:
> >>
> /gnu/store/nr1aw4i32h7rmxwmq7d2da0mwcwg551j-glibc-2.29/include/bits/stdint-intn.h:27:19:
> error: conflicting types for 'int64_t'
> >>  typedef __int64_t int64_t;
> >>^~~
> >> In file included from ./include/linux/list.h:5:0,
> >>  from ./include/linux/module.h:9,
> >>  from arch/arm64/lib/xor-neon.c:10:
> >> ./include/linux/types.h:114:15: note: previous declaration of 'int64_t'
> was here
> >>  typedef s64   int64_t;
> >>^~~
> >> In file included from
> /gnu/store/nr1aw4i32h7rmxwmq7d2da0mwcwg551j-glibc-2.29/include/stdint.h:37:0,
> >>  from
> /gnu/store/yckkivhynk4hjcr0iry9vbcyc0lqqnxj-gcc-7.4.0-lib/lib/gcc/aarch64-unknown-linux-gnu/7.4.0/include/arm_neon.h:33,
> >>  from ./arch/arm64/include/asm/neon-intrinsics.h:33,
> >>  from arch/arm64/lib/xor-neon.c:11:
> >>
> /gnu/store/nr1aw4i32h7rmxwmq7d2da0mwcwg551j-glibc-2.29/include/bits/stdint-uintn.h:27:20:
> error: conflicting types for 'uint64_t'
> >>  typedef __uint64_t uint64_t;
> >> ^~~~
> >> In file included from ./include/linux/list.h:5:0,
> >>  from ./include/linux/module.h:9,
> >>  from arch/arm64/lib/xor-neon.c:10:
> >> ./include/linux/types.h:112:15: note: previous declaration of
> 'uint64_t' was here
> >>  typedef u64   uint64_t;
> >>^~~~
> >> make[1]: *** [scripts/Makefile.build:285: arch/arm64/lib/xor-neon.o]
> Error 1
> >> make: *** [Makefile:1073: arch/arm64/lib] Error 2
> >> make: *** Waiting for unfinished jobs
> >>
> >> Not sure what's going on here.  Ideas?
> >
> > Ha, that looks familiar, the same issue happened back in July:
> > https://lists.gnu.org/archive/html/guix-devel/2019-07/msg00175.html
> >
> > I don't think we worked out what was the problem exactly though :-/
>
> So I was able to build it with this patch:
>
>
> It's not very pretty though.  Thoughts?
>

I believe that we encountered similar CPATH related problems earlier, which
were fixed by pathes like this, so it looks good to me. Maybe it would
worth investigating the pattern though, and create some generic mechanism
to deal with it. Wdyt?


Best regards,
g_bor
-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

bug#37631: service zabbix-server (and zabbix-agent) fails starting (cannot run as root!)

[Gábor Boskovits]

Hello Giovanni,

Giovanni Biscuolo  ezt írta (időpont: 2019. okt. 5., Szo,
14:51):

> Giovanni Biscuolo  writes:
>
> > executive summary: do we really need to start zabbix_server in
> > foreground mode?
>
> executive answer: I don't know **but** this is not the cause of my issue
> :)
>
> > --8<---cut here---start->8---
>
> [...]
>
> >(service zabbix-server-service-type
> >   (zabbix-server-configuration
> >(include-files
> '("/root/secrets/zabbix-server-dbpass"))
> >(log-type "file")))
>
> ouch!... looking at the console (it's a remote VM so I usually connect
> via ssh only, but today I also connected via SPICE):
>
> --8<---cut here---start->8---
> zabbix_server [1942]: /root/secrets/zabbix-server-dbpass: [13] Permission
> denied
> --8<---cut here---end--->8---
>
> unfortunately shepherd did not catch this error (due to foreground
> mode?) in syslog :-(
>
> I just had to adjust the permissions to allow zabbix (I allowed the
> zabbix group to traverse /root/secrets and read the file) to read the
> included file
>
> this now works with both zabbix 4.2.0 and zabbix 4.2.7
>
> [...]
>
> Thanks! Gio'
>
> --
> Giovanni Biscuolo
>
> Xelera IT Infrastructures
>
>
>
> Can we consider this resolved then?

Best regards,
g_bor
-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

bug#37631: service zabbix-server (and zabbix-agent) fails starting (cannot run as root!)

[Giovanni Biscuolo]

Gábor Boskovits  writes:

[...]

>> Can we consider this resolved then?

oh yes sorry, forgot to (auto) close this bug as done: this message
should do it

Thanks! Gio'

[...]

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

bug#37501: [core-updates] Entropy starvation during boot

[Ludovic Courtès]

Hi,

Marius Bakke  skribis:

> I tried it, but it did not make any discernible difference in the
> available entropy right after boot, nor did it aid the CRNG seeding.

Bah, too bad, though it still doesn’t sound right to consume this much
entropy right from the start.  I’m surprised it doesn’t make any
difference when you remove that bit.

Perhaps we should print the value of /proc/…/entropy_avail in several
places during boot time to get a better understanding.

> So I think we should go with Linus' solution for now, as well as your
> original fix Ludo because it seems to be the right thing to do anyway.

Sounds good.  I’ve pushed it as
81bc4533aa1d7d81472c1d8d9f697ba2a9c9cbf9.

Thanks!

Ludo’.

bug#37533: waybar fails to build

[Bradley Haggerty]

This issue has persisted across a few guix updates now, but I would
like to add that I am running Guix System. My current guix version is:
guix (GNU Guix) 5a54baf67cfb91ad5062a4a061bc6d083096f9d8

This program is a customizable panel for use on wayland, possibly
comparable to polybar. I haven't gotten around to switching to it from
Sway's default "swaybar" yet, but I've kept it installed for a rainy
day. I know we don't have many wayland users, so I fear if I just
uninstall it to make updates less annoying, it may go unsolved for a
long time. Let me know if more info is needed here. I am bdju on the
guix irc.