Thanks so much for replying, Charles!
Question #1
Loaded from "apt-get install" on both platforms.
Not compiled from source on either one.
Libraries:
I'm confused too, given that someone else (the person in another blog,
who'd pointed out running the upsstats.cgi from the CLI) also said that the
same libraries serve upsc and upsstats.cgi
Question #2
Anyhow:
Output of your suggested command from P2
root@Pi2:~# ldd /usr/lib/cgi-bin/nut/upsstats.cgi
linux-vdso.so.1 (0x0000ffff8c44e000)
libupsclient.so.4 => /lib/aarch64-linux-gnu/libupsclient.so.4
(0x0000ffff8c3d2000)
libpthread.so.0 => /lib/aarch64-linux-gnu/libpthread.so.0
(0x0000ffff8c3a1000)
libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000ffff8c22d000)
/lib/ld-linux-aarch64.so.1 (0x0000ffff8c41e000)
libnss3.so => /lib/aarch64-linux-gnu/libnss3.so (0x0000ffff8c0dd000)
libssl3.so => /lib/aarch64-linux-gnu/libssl3.so (0x0000ffff8c06c000)
libplds4.so => /lib/aarch64-linux-gnu/libplds4.so
(0x0000ffff8c058000)
libplc4.so => /lib/aarch64-linux-gnu/libplc4.so (0x0000ffff8c043000)
libnspr4.so => /lib/aarch64-linux-gnu/libnspr4.so
(0x0000ffff8bff3000)
libnssutil3.so => /lib/aarch64-linux-gnu/libnssutil3.so
(0x0000ffff8bfb2000)
libdl.so.2 => /lib/aarch64-linux-gnu/libdl.so.2 (0x0000ffff8bf9e000)
root@Pi2:~#
And on Pi1
root@quantar-A-model:~# ldd /var/www/cgi-bin/nut/upsstats.cgi
/usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so =>
/usr/lib/arm-linux-gnueabihf/libarmmem-v6l.so (0xb6ebe000)
libupsclient.so.4 => /lib/arm-linux-gnueabihf/libupsclient.so.4
(0xb6ea1000)
libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0
(0xb6e75000)
libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb6d21000)
/lib/ld-linux-armhf.so.3 (0xb6ed1000)
libnss3.so => /lib/arm-linux-gnueabihf/libnss3.so (0xb6bf1000)
libssl3.so => /lib/arm-linux-gnueabihf/libssl3.so (0xb6b94000)
libplds4.so => /lib/arm-linux-gnueabihf/libplds4.so (0xb6b81000)
libplc4.so => /lib/arm-linux-gnueabihf/libplc4.so (0xb6b6d000)
libnspr4.so => /lib/arm-linux-gnueabihf/libnspr4.so (0xb6b2c000)
libnssutil3.so => /lib/arm-linux-gnueabihf/libnssutil3.so
(0xb6af8000)
libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0xb6ae4000)
root@quantar-A-model:~#
One difference I just realised ---
I'd forgotten that the hardware at the repeater site is NOT actually a
Raspberry board, although it's supposed to be compatible - so much so, that
it's running Raspian "bullseye"
just like a true hardware Pi would do.
Per 'cat /proc/device-tree/model'
The Pi1 platform is an "Raspberry Pi Model B Rev 2"
The Pi2 platform is different:
Libre Computer AML-S905X-CCr
That's a "Le Potato", as they're known.
https://libre.computer/products/aml-s905x-cc/
I didn't think that mattered, since I was able to get the USB-hid driver
and the /usr/bin/upsc
all were working -- thought I was above hardware/software
versions/libraries, and somewhere up to "configuration" or "permissions"
But maybe, now that I see some differences in the ldd output, there IS
something missing.
Hopefully it's perhaps merely a missed step in getting CGI working with
Apache, and I missed adding a required library or something.
Thanks, Tim
####
Tim, KA4LFP####
####
Morse code, the original digital mode
Real radios glow in the dark.
SWAN rule number 1: Life is too short to have a puny signal. © K0MHP
SWAN rule number 2: No menu required. © K0MHP
##
On Thu, Dec 21, 2023 at 7:24 AM Charles Lepple <clep...@gmail.com> wrote:
> On Dec 20, 2023, at 5:17 PM, Tim Reimers KA4LFP via Nut-upsuser wrote:
> >
> > First, a summary:
> > - I have a RasPI (hereafter referred to as Pi1) running Bullseye in
> which this all WORKS FINE -- the upsd/upsc/ monitor services, etc
> > - I have a SECOND RasPI (hereafter referred to as Pi2) running Bullseye
> in which ONLY the CGI scripts do not work.
> > All other (upsc/upsd/systemctl) show normal status and work to retrieve
> data from the single UPS attached to each Pi.
> >
> I'm not quite sure what is missing[*], but when you get no output from a
> program, and a "file not found" error from bash, it is usually a missing
> shared library that prevents the executable from fully loading.
>
> [*] the confusing part is that the other NUT command line tools aren't
> affected.
>
> Was the CGI program installed from the Debian nut-cgi package? Or was it
> built from source, or copied from the other Pi?
>
> You should get output similar to this from ldd (this is from an amd64
> Ubuntu system, so details may differ, but consider overall structure):
>
> $ ldd /usr/lib/cgi-bin/nut/upsstats.cgi
> linux-vdso.so.1 (0x00007fff1a99b000)
> libupsclient.so.4 => /lib/x86_64-linux-gnu/libupsclient.so.4
> (0x00007eff6ebec000)
> libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
> (0x00007eff6ebc9000)
> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007eff6e9d7000)
> libnss3.so => /usr/lib/x86_64-linux-gnu/libnss3.so (0x00007eff6e888000)
> libssl3.so => /usr/lib/x86_64-linux-gnu/libssl3.so (0x00007eff6e829000)
> libplds4.so => /usr/lib/x86_64-linux-gnu/libplds4.so (0x00007eff6e824000)
> libplc4.so => /usr/lib/x86_64-linux-gnu/libplc4.so (0x00007eff6e81b000)
> libnspr4.so => /usr/lib/x86_64-linux-gnu/libnspr4.so (0x00007eff6e7db000)
> /lib64/ld-linux-x86-64.so.2 (0x00007eff6ec29000)
> libnssutil3.so => /usr/lib/x86_64-linux-gnu/libnssutil3.so
> (0x00007eff6e7a8000)
> libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007eff6e7a2000)
>
> If any of the libraries don't have a path after "=>", that's something to
> investigate on the working Pi (e.g. "dpkg --search libnss3.so <
> http://libnss3.so/>" to see which package provides that library)
>
> - Charles
_______________________________________________
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
