The football expression is fourth and inches, so this is not a sport tale. Making a loom required 3 teeth per inch to get 19 across a 7 inch span conforming to the available loops. Imperial scale rules don't help, and rather than get out the metric equivalent I drew a quick sketch in LibreOffice then exported to PNG and PDF.
ODG:
 |
| Hammering teeth |
 |
| Teeth on edge |
Lining up for pre-drilling in clamp.
I wanted to upgrade my Zabbix server running on a NetBSD amd64 host and at almost the same time install NetBSD on an NVME card instead of SSD. The mainboard has no graphics, so I played hit-or-miss with cheap-ish cards, getting NetBSD 9 to run but then not, and using FreeBSD under low-res VGA mode. Anyway, to avoid missing data in case the reinstall had surprises I decided to clone the running Zabbix system to a FreeBSD host on a recycled laptop.
NetBSD pkgsrc has Zabbix 6.0, which I'm running, with 6.4 in the work-in-progress prep area, that I have tested but not deployed. FreeBSD has 6.4 in ports, with the modules I've used so the copy would also test the auto-upgrade.
Export and import with PostgreSQL was quick and tidy once I set up the target with an empty database and the necessary glue. The export file was just over 1GB, and imported with no (visible) errors. Starting up the 6.4 server triggered upgrade steps, also showing no noticeable gaffes.
75396:20240925:142052.283 hosts_name_upper_update trigger for table "hosts" already exists, skipping patch of adding "name_upper" column to "hosts" table
75396:20240925:142052.877 completed 99% of database upgrade
75396:20240925:142052.890 completed 100% of database upgrade
75396:20240925:142052.891 database upgrade fully completed
75406:20240925:142053.025 starting HA manager
75406:20240925:142053.056 HA manager started in active mode
Typical summer thunderstorms cause occasional power grid outages, some short, some long. With a battery backup a blip can have minimal repercussions, longer down times are opportunities to move hardware around, rewire, etc. A recent gap of several hours revealed one of my in-house Zabbix front-ends unusable. Probably self-inflicted by updating packages somewhere, and not having the database, server and front end web pieces all on one image.
I tried a few things, and among other errors, was told PostgreSQL was unsupported.
A different fix path led to "almost" but no banana on the Pi, trying to set up 6.0 and 6.4 frontends on the same FreeBSD Pi.
Sigh. I tried to repair this on a NetBSD system, failed to launch there, then tried a full install on a Raspberry Pi OS, which stumbled around the Apache-PHP-SQL-HTTP part, and ended up promoting a Raspberry Pi 3 running NetBSD with a clean slate off front end whirly-gigs.
(0)
"The Zabbix database version does not match current requirements. Your database version: 6000000. Required version: 6040000. Please contact your system administrator."
(1)
PHP Fatal error: Uncaught Error: Call to undefined function mb_check_encoding() in /usr/pkg/share/httpd/htdocs/zabbix/include/validate.inc.php:234
\n
Stack trace:\n#0 /usr/pkg/share/httpd/htdocs/zabbix/include/validate.inc.php(356): check_type()\n#1 /usr/pkg/share/httpd/htdocs/zabbix/include/validate.inc.php(438): check_field()\n#2 /usr/pkg/share/httpd/htdocs/zabbix/include/validate.inc.php(462): check_fields_raw()\n#3 /usr/pkg/share/httpd/htdocs/zabbix/setup.php(72): check_fields()\n
#4 {main}\n thrown in /usr/pkg/share/httpd/htdocs/zabbix/include/validate.inc.php on line 234, referer: http://am4.home/zabbix/setup.php
(2)
$ pkgin in ap24-php83
ap24-php83-8.3.8nb11 gimp-2.10.38nb1 ncurses-6.5 p5-DBD-SQLite-1.74nb1 p5-DBI-1.643nb5 pdal-lib-2.7.1nb4 py311-httpx-0.27.0
php-8.2.20
php82-bcmath-8.2.20 php82-gd-8.2.20nb8 php82-gettext-8.2.20 php82-ldap-8.2.20nb2 php82-mbstring-8.2.20 php82-sockets-8.2.20 php82-sysvsem-8.2.20
(4)
Fourth times a charm
pkgin in zabbix-frontend-postgresql
calculating dependencies...done.
1 package to refresh: [...]
12 packages to install:
gd-2.3.3nb13 libimagequant-4.3.1 oniguruma-6.9.9 ... php82-ldap-8.2.20nb2 ...
php82-mbstring-8.2.20 ... zabbix-frontend-postgresql-6.0.24nb1
Now that NetBSD 10 is released (for a few weeks) I have been reviewing tests I ran, benchmarking and other studies, trying to fix the dangling problem reports I opened, and mainly using the OS for as many daily tasks as feasible. In that context are wireless network connections to the somewhat closed but open Raspberry Pi network drivers, as replicated in the BSD space instead factory-floor Linux.
When I checked the FreeBSD page, wifi shows as "unsupported", listing some chip or board IDs that must mean something ('brcmfmac43455-sdio").
Based on : https://wiki.freebsd.org/arm/Raspberry%20Pi we see:WiFi/Unsupported on the Pi series, including the 4, which would be the best available, until the 5 has been encompassed. Understood that wiki page documentation may lag development, and I haven't dug to far to see what is newer than the doc. To research one of the above bugs (overflow arithmetic) I installed a recent FreeBSD image on a Pi0W, only to find it crash hard with "unresolved symbols" or other architecture clashes as soon as I tried any command. So my hands-on with Pi and FreeBSD is limited to Pi3 and Pi4 models at hand. None of them show "bw" interfaces.
NetBSD can see the "bw" interface on the Pi4, and I definitely had that working during the long beta campaign. Except now I can't get it to work on the 10.0 release for reasons yet to be found. It would show up in ifconfig output:
 |
| Chart of Pi bake-off |
A while back I started using Rasberry Pi systems to monitor environmental data around the house. I tried several "hats" that included different sensors. Most read temperature; some could check humidity, luminosity, and barometric pressure, allegedly.
The sensors I ended up liking the most connect to the Pi via the SparkFun QWIIC connection. The "all-in-one" sensors suffered by being too close to the Pi CPU, necessitating adjustments to the readings to compensate for the excess heat. Putting sensors just an inch or 2 away (5 cm) avoided that.
After getting ambient in-house temperature readings and placing sensors in places like the water heater pipes and the clothes dryer door let me check out energy efficiency, in a way. Or just seeing when and for how long we use high energy appliances. The local electric utility has hourly metrics I can download; a data acquisition story for another time.
With inside conditions measured I thought about putting a Pi sensor outside, and got as far as placing one temperature sensor in a window. But that is only on the edge of "outside" and gets some heat from the building instead of the atmosphere. I looked at getting a full-fledged weather station [ see: https://blog.netbsd.org/tnf/entry/the_geeks_way_of_checking ], then decided the investment wasn't necessary. There's a full-fledged airport meteorological station at a nearby airport which publishes ambient conditions that suit my needs [Insert George Carlin's joke about airport weather: nobody cares about the airport; downtown is on fire!].
Among other published data streams, there is a set that has evolved from early web days of FTP content into HTML pages that contain plain text (and bear "ftp" in their URL).
The site I am using is "KMTN"; many many others are there for the browsing. A few hundred sites have data not updated since 2008, interestingly.
Yes, you could use curl or wget, but I like Lynx:
# get metar data into a file
/usr/pkg/bin/lynx -dump https://tgftp.nws.noaa.gov/data/observations/metar/decoded/${SITE}.TXT > $DATAFILE
Complex title, just to say how stable and feature-rich is NetBSD 10 on a Raspberry Pi (4)?
Pretty good, not bad, can't complain.
At one time during RC (release candidate) testing I had wi-fi engaged on a Pi 3A, a 3B, and a 4. Beyond those, the Pi0W and Pi02W wireless has been unflappable on start-up, if a bit squeezed on speed, and an occasional miss of the beat. Since I took this screenshot, the 4 has lost the ifconfig (again), and the 2 3's are humming along. All of those are on the same GENERIC64 kernel.
Reply from 192.168.1.39: bytes=32 time=4ms TTL=255
Scanning color slides at 1600 dpi off a Pi:
Besides the ubiquitous VLC app (GUI and CLI), I've used mpg123 and mp3blaster on NetBSD systems as command line audio/video players. With a miniDLNA UPnP set-up and steaming internet radio stations I have good tunes at will. In the good old days. a SoundBlaster interface card was the way to go. Theses days, audio circuity is either built-in the system, or ready as easily as popping in a USB dongle.
Prior versions of NetBSD on Raspberry Pi systems had challenges with the wired headphone circuit and with audio through HDMI (in some cases not the system fault but a lack of speakers in a monitor. The audio streams would play okay for a while but within a day or so various buffer/cache issues came up, causing no sound, or worse, choppy static.
Mar 21 21:59:01 nb4 /netbsd: [ 547447.7922531] audio0(vcaudio0): device timeout
I'm getting about a week of playing, at intervals, before contention creeps in.
Continuing with getting more QGIS skills, I planned to run the tutorial for changing symbols based on rules or other data conditions. Before I got there, I found a treasure trove of GIS data feeds from the local state government, particularly apt as the sources include property shapes as well as many details on property values. I had looked at the Comptroller's site first only to find the better results on the state planning site.
I had gathered a few data records on specific properties from public information about drinking water wells and mapped a good set of views with QGIS. I was trying not to trace property lines from downloaded imagery and was rewarded for my delay by finding the official records. Of course with caveats, as with any data feed, especially government fed.
I found 4 data sets eventually, 3 as data points and the fourth as polygons. 2 of the 3 point files have "property" records with one having few columns and the other many; the 3rd has building-specific info.
For my first data loads, I unzipped the procured files then added that data set as a shapefile by telling QGis that the file was the one with the dBASE extension (.dbf). Later I tried point the "Add Layer" file finder at the ZIP file without unpacking the archive and that seemed to work fine. Yay QGis!
Having the data in the GIS console opened many more possibilities. Once I figured out which key column to use (Account ID, go figure) I was able to create a join in QGis. A different experience than mine with database joins with command line SQL scripts, and a bit wrinkly around the edges I'd say.
Part of what I learned in the loading attempts was that source file names might need to be escaped in order to write SQL scripts or filters with QGis itself. The couple files with ASCII/mixed case simply worked with quotes around it. The file name with a Unicode "em dash" on the other hand i struggled with.
| SELECT * FROM "public"."CAROparcels0124 — CAROMDPV.shp" LIMIT 10 |
|
create or replace view carobldg_dist07_v as select * from "CaroBldg" where acctid like '0607%' ; |
| 2024-03-16T01:02:21 INFO Task complete : Exporting BACOparcels0124 — BACOMDPV.shp | 2024-03-16T01:06:08 INFO Task complete : Exporting BACOparcels0124 — BACOPOLY.shp |
