Re: Problems with sites using Let's Encrypt certificates
Thanks to help from my colleague who is a network expert, the failure
of "pkg install pkg" on my new DragonFlyBSD 6.0 VM has been resolved.
Here is what on saw repeatedly over the last two weeks:
# pkg install pkg
Updating Avalon repository catalogue...
Certificate verification failed for /O=Digital Signature Trust
Co./CN=DST Root CA X3
...
Here is what we did to diagnose and workaround the failure:
(1) On another machine, check the certificates on the DragonFlyBSD master site:
% openssl s_client -connect mirror-master.dragonflybsd.org:443
-showcerts
CONNECTED(0003)
depth=1 O = Digital Signature Trust Co., CN = DST Root CA X3
verify error:num=10:certificate has expired
notAfter=Sep 30 14:01:15 2021 GMT
... long output ...
I'm advised that such certificates expire in about 90 days, and
then renew automatically, so by the end of December, my VM might
finally be usable. That is hardly acceptable.
(2) On the VM running the new 6.0 release, look at this file:
% less /usr/local/etc/pkg/repos/df-latest.conf
# If multiple repositories are enabled, they are ordered by their
priorities
# and then listing orders.
# United States, California
Avalon: {
url :
https://mirror-master.dragonflybsd.org/dports/${ABI}/LATEST,
mirror_type : NONE,
signature_type : NONE,
pubkey : NONE,
fingerprints: /usr/share/fingerprints,
priority: 0,
enabled : yes
}
There are 31 mirror sites listed, but all but the first have "enabled: no".
(3) Use step (1) above to check the certificates of `nearby' mirrors
successively until finding that mirrors.nycbug.org has a
still-valid certificate.
(4) Set "enabled: no" in the df-latest.conf file for
mirror-master.dragonflybsd.org
and "enabled: yes" for mirrors.nycbug.org.
(5) Run
# pkg install pkg
success
# pkg install ... many more
My VM is now usable, and up to date.
I remain puzzled, however, why the mirror-master.dragonflybsd.org site
could have had an expired Web certificate for the last two weeks
without manual repair and reports on this list that first appeared on
30-Sep-2021, the day the certificate expired.
194) 30-Sep Antonio Huete = Problems with sites using Let's Encrypt
certificates (9820 chars)
195) 30-Sep Antonio Huete = Re: Problems with sites using Let's Encrypt
certificates (10187 chars)
197) 1-Oct =?UTF-8?B?SsOhd Re: Problems with sites using Let's Encrypt
certificates (20573 chars)
198) 6-Oct "Nelson H. F. B Re: Problems with sites using Let's Encrypt
certificates (2526 chars)
199) 6-Oct Phansi Re: Problems with sites using Let's Encrypt
certificates (12079 chars)
200) 6-Oct Antonio Huete = Re: Problems with sites using Let's Encrypt
certificates (11948 chars)
Also, if the df-latest.conf file had 2 or 3 sites with "enabled: yes",
then I expect that the pkg command might have retried on multiple
sites to finding a working mirror. In the Linux world, I've seen
package installer try another mirror if one is unreachable.
---------------
- Nelson H. F. BeebeTel: +1 801 581 5254 -
- University of UtahFAX: +1 801 581 4148 -
- Department of Mathematics, 110 LCBInternet e-mail: be...@math.utah.edu -
- 155 S 1400 E RM 233 be...@acm.org be...@computer.org -
- Salt Lake City, UT 84112-0090, USAURL: http://www.math.utah.edu/~beebe/ -
---
Re: Problems with sites using Let's Encrypt certificates
Antonio reports about the certificate verification problem for the DragonFlyBSD package system: >> There is a fix already available, please check: >> >> https://lists.dragonflybsd.org/pipermail/users/2021-October/404826.html I saw that response when it was originally posted, but I have a newly installed VM with no working package system, and no interest in building kernels or anything else on DragonFlyBSD from remote source code repositories. What does >> Only a 'world' upgrade is needed, please proceed with the usual >> procedure mean in my context? The phrase "world" does not exist in the output of "man pkg". I need to install scores of packages on this VM before it can be used for my work in software testing and development. ----------- - Nelson H. F. BeebeTel: +1 801 581 5254 - - University of UtahFAX: +1 801 581 4148 - - Department of Mathematics, 110 LCBInternet e-mail: be...@math.utah.edu - - 155 S 1400 E RM 233 be...@acm.org be...@computer.org - - Salt Lake City, UT 84112-0090, USAURL: http://www.math.utah.edu/~beebe/ - ---
Re: Problems with sites using Let's Encrypt certificates
Earlier this week, it was reported that the expired Let's Encrypt certificate problem has been resolved. However, on two DragonFlyBSD 6.0 VMs at my site, one created from an RC1 ISO image, and the other more recently from the official ISO image dfly-x86_64-6.0.0_REL.iso dated 7-May-2021, I still get certificate verification failures. For the new VM, this means I cannot even install the pkg command: # pkg install pkg Updating Avalon repository catalogue... Certificate verification failed for /O=Digital Signature Trust Co./CN=DST Root CA X3 ... Can other list readers confirm whether they too still have similar problems? Some pkg systems on Linux have ways to temporarily disable certificate checking, but I could not spot a similar option in the DragonFlyBSD pkg command collection. Advice welcome! --- - Nelson H. F. BeebeTel: +1 801 581 5254 - - University of UtahFAX: +1 801 581 4148 - - Department of Mathematics, 110 LCBInternet e-mail: be...@math.utah.edu - - 155 S 1400 E RM 233 be...@acm.org be...@computer.org - - Salt Lake City, UT 84112-0090, USAURL: http://www.math.utah.edu/~beebe/ - ---
Improving I/O efficiency and resilience
Today's new issue of ACM Transactions on Storage contains a long
article on SSD performance that may be of interest to HAMMER
architects:
Performance Modeling and Practical Use Cases for Black-Box {SSDs}
ToS 17(2) 14:1--14:38 June 2021
https://doi.org/10.1145/3440022
The same issue contains another article on filesystem resilience:
Can Applications Recover from fsync Failures?
ToS 17(2) 12:1--12:30 June 2021
https://doi.org/10.1145/3450338
At least for Linux's EXT4, XFS, and BTRFS, the answer to the
title question is no.
---
- Nelson H. F. BeebeTel: +1 801 581 5254 -
- University of UtahFAX: +1 801 581 4148 -
- Department of Mathematics, 110 LCBInternet e-mail: be...@math.utah.edu -
- 155 S 1400 E RM 233 be...@acm.org be...@computer.org -
- Salt Lake City, UT 84112-0090, USAURL: http://www.math.utah.edu/~beebe/ -
---
TeX Live 2021 status on DragonFlyBSD
The annual TeX Live release work began a week ago, and I'm pleased to report that the first binaries, and build comments, for DragonFlyBSD 5.8.3 are now available from these URLs: http://www.math.utah.edu/pub/texlive-utah-2021/ http://www.math.utah.edu/pub/texlive-utah-2021/#dragonflybsd-5.8.3-x86_64 Kudos go to the DragonFlyBSD team for keeping compilers and packages at modern levels: the first TeX Live 2021 source tree build on DragonFlyBSD 5.8.3 was flawless and problem free. Alas, FreeBSD is now almost six years behind in its packaging of TeX Live, and DragonFlyBSD is too: /usr/bin/tex reports "TeX Live 2015". There is not yet a TeX Live 2021 pretest package, so I just copied over the recently updated 2020 tree into a 2021 tree under which the bin directory contains executable files for numerous platforms. The official release of TeX Live 2021 DVDs and ISO images is expected to be available in late April or early May; however, because of severe space constraints, they contain binaries only for the most widely used platforms; the Utah archive above usually supplies them for scores of additional systems. As always, TeX executables expect to find at run time a precompiled `format' file (*.fmt) that includes all of the standard packages expected for that executable; that considerably speeds processing of small jobs, because the *.fmt files can be directly loaded into TeX's memory without parsing. The *.fmt files are easily updated like this: fmtutil --sys --all They are CPU and O/S and byte-order INdependent, but DEPENDENT on the current TeX Live source tree. Thus, a single TeX Live tree needs to have the *.fmt files created on just one architecture; all other architectures can use them directly. Feedback and suggestions are always welcome; send e-mail to me off list. --- - Nelson H. F. BeebeTel: +1 801 581 5254 - - University of UtahFAX: +1 801 581 4148 - - Department of Mathematics, 110 LCBInternet e-mail: be...@math.utah.edu - - 155 S 1400 E RM 233 be...@acm.org be...@computer.org - - Salt Lake City, UT 84112-0090, USAURL: http://www.math.utah.edu/~beebe/ - ---
Re: pkg update breaks pkg system
Antonio asks:
>> What is the error you're getting? Only the lua one?
There was both the issue of two missing libraries (solved by temporary
symlinks), and this lua failure:
# pkg install sudo
...
1/1] Installing sudo-1.9.3p1...
[1/1] Extracting sudo-1.9.3p1: 100%
pkg: Failed to execute lua script: [string "args = {}..."]:11:
attempt to call a nil value (field 'stat')
pkg: lua script failed
It seems to me that the packaging system must have errors in its
dependencies for the package named "pkg": it should not have been
possible to install pkg-1.15.10 unless its dependent libraries were
downloaded and installed first.
The Lua versions are these:
# /usr/local/bin/lua54 -v
Lua 5.4.1 Copyright (C) 1994-2020 Lua.org, PUC-Rio
# /usr/local/bin/luac54 -v
Lua 5.4.1 Copyright (C) 1994-2020 Lua.org, PUC-Rio
Unfortunately, pkg reports "lua script failed", but does not identify
the name of the failing script, which is another serious flaw in pkg.
---------------
- Nelson H. F. BeebeTel: +1 801 581 5254 -
- University of UtahFAX: +1 801 581 4148 -
- Department of Mathematics, 110 LCBInternet e-mail: be...@math.utah.edu -
- 155 S 1400 E RM 233 be...@acm.org be...@computer.org -
- Salt Lake City, UT 84112-0090, USAURL: http://www.math.utah.edu/~beebe/ -
---
Re: pkg update breaks pkg system
>> Antonio Huete =?utf-8?b?Smltw6luZXo=?= >> writes on Thu, 31 Dec 2020 20:39:07 + in my posting about a >> broken package system: >> >> What's the output of? >> uname -a >> openssl version They report: DragonFly dragonflybsd59.vm.math.utah.edu 5.9-DEVELOPMENT DragonFly 5.9-DEVELOPMENT #0: Wed Feb 26 11:22:49 UTC 2020 r...@pkgbox64.dragonflybsd.org:/usr/obj/usr/src/sys/X86_64_GENERIC x86_64 LibreSSL 2.9.1 ----------- - Nelson H. F. BeebeTel: +1 801 581 5254 - - University of UtahFAX: +1 801 581 4148 - - Department of Mathematics, 110 LCBInternet e-mail: be...@math.utah.edu - - 155 S 1400 E RM 233 be...@acm.org be...@computer.org - - Salt Lake City, UT 84112-0090, USAURL: http://www.math.utah.edu/~beebe/ - --- ----------- - Nelson H. F. BeebeTel: +1 801 581 5254 - - University of UtahFAX: +1 801 581 4148 - - Department of Mathematics, 110 LCBInternet e-mail: be...@math.utah.edu - - 155 S 1400 E RM 233 be...@acm.org be...@computer.org - - Salt Lake City, UT 84112-0090, USAURL: http://www.math.utah.edu/~beebe/ - ---
pkg update breaks pkg system
On a VM running DragonFlyBSD 5.9-SYNTH (DFLYVERSION=500900), I just
did a package update like this:
# pkg-static update
# pkg-static upgrade
and got this output:
Updating Avalon repository catalogue...
Fetching meta.conf: 100%246 B 0.3kB/s00:01
Fetching packagesite.txz: 100%6 MiB 2.1MB/s00:03
Processing entries: 100%
Avalon repository update completed. 31784 packages processed.
All repositories are up to date.
Updating Avalon repository catalogue...
Avalon repository is up to date.
All repositories are up to date.
New version of pkg detected; it needs to be installed first.
The following 1 package(s) will be affected (of 0 checked):
Installed packages to be UPGRADED:
pkg: 1.14.7 -> 1.15.10 [Avalon]
Number of packages to be upgraded: 1
3 MiB to be downloaded.
Proceed with this action? [y/N]: y
[1/1] Fetching pkg-1.15.10.txz: 100%3 MiB 3.0MB/s00:01
Checking integrity... done (0 conflicting)
[1/1] Upgrading pkg from 1.14.7 to 1.15.10...
[1/1] Extracting pkg-1.15.10: 100%
You may need to manually remove /usr/local/etc/pkg.conf if it is no
longer needed.
pkg-static: Failed to execute lua script: [string "args = {}..."]:11:
attempt to call a nil value
(field 'stat')
pkg-static: lua script failed
No active remote repositories configured.
/usr/local/sbin/pkg
/usr/local/sbin/pkg-static
# pkg search pkg
Shared object "libprivate_ssl.so.48" not found, required by "pkg"
# pkg-static search pkg
No active remote repositories configured.
Has anyone seen this before, and is there an easy fixup?
I fixed the missing *.so.* file problem with this temporary workaround
that I've used on multiple O/Ses in the past when similar
missing-library problems surfaced during upgrades.
# ln -s libprivate_ssl.so.47 /lib/libprivate_ssl.so.48
# ln -s libprivate_crypto.so.45 /lib/libprivate_crypto.so.46
I also tried renaming /usr/local/etc/pkg.conf to
/usr/local/etc/pkg.conf.old, but that does not change the "No active
..." output, so I put the file back under its old name.
I can easily revert to last night's snapshot of the VM, but it would
be good for all DragonFlyBSD users to know how to recover from a
broken package system (which is why I have habitually used pkg-static,
instead of pkg, in the BSD family of operating systems);
---------------
- Nelson H. F. BeebeTel: +1 801 581 5254 -
- University of UtahFAX: +1 801 581 4148 -
- Department of Mathematics, 110 LCBInternet e-mail: be...@math.utah.edu -
- 155 S 1400 E RM 233 be...@acm.org be...@computer.org -
- Salt Lake City, UT 84112-0090, USAURL: http://www.math.utah.edu/~beebe/ -
---
Re: Missing libraries
Jonathan Engwall asks: >> I need to know how to find the package that supply shared libraries, by the >> libraries the packages provide. I strongly recommend always installing the pkg-provides package on FreeBSD and its derivatives, and on DragonFlyBSD. After installation pkg-provides, a three lines in /usr/local/etc/pkg.conf need tweaking to look like this: PKG_PLUGINS_DIR = "/usr/local/lib/pkg/"; PKG_ENABLE_PLUGINS = true; PLUGINS [ provides ] ; You then need to run (just once): # pkg provides -u >From then on, an index of providing packages is maintained for all currently, and subsequently, installed files. You can then find the package that supplies a particular file like this: % pkg provides /usr/local/bin/gmake Name: gmake-4.3_2 Desc: GNU version of 'make' utility Repo: Avalon Filename: usr/local/bin/gmake ----------- - Nelson H. F. BeebeTel: +1 801 581 5254 - - University of UtahFAX: +1 801 581 4148 - - Department of Mathematics, 110 LCBInternet e-mail: be...@math.utah.edu - - 155 S 1400 E RM 233 be...@acm.org be...@computer.org - - Salt Lake City, UT 84112-0090, USAURL: http://www.math.utah.edu/~beebe/ - ---
Re: TeX Live 2020 status on DragonFlyBSD
>> We usually pull TeX via FreeBSD ports. Looks like there is an open PR in >> FreeBSD ports to update it. Thanks for that report. On my FreeBSD 12.1 and 13.0 systems, /usr/local/bin/tex is still from 2015, so they are indeed way behind. ------- - Nelson H. F. BeebeTel: +1 801 581 5254 - - University of UtahFAX: +1 801 581 4148 - - Department of Mathematics, 110 LCBInternet e-mail: be...@math.utah.edu - - 155 S 1400 E RM 233 be...@acm.org be...@computer.org - - Salt Lake City, UT 84112-0090, USAURL: http://www.math.utah.edu/~beebe/ - ---
TeX Live 2020 status on DragonFlyBSD
The TeX Live 2020 build season is nearing its end, with an expected full release, and DVD production, near the end of March (this month). I have been actively involved in building it on numerous platforms, including several releases of DragonFlyBSD. The current status is documented at this Web site: http://www.math.utah.edu/pub/texlive-utah/ The DragonFlyBSD notes are in the section at http://www.math.utah.edu/pub/texlive-utah/#dragonflybsd Last week, a pretest package for the 2020 installation tree became available, and it is easily installable with just five simple steps documented in the section at http://www.math.utah.edu/pub/texlive-utah/#install The tlmgr program that is used subsequently to apply updates during the year does not yet run on DragonFlyBSD, but I have filed a request to its developers to add such support: it should be a minor tweak to their perl code, and should require just a few lines of new code. Inasmuch as even the latest DragonFlyBSD 5.9 development release still supplies a version of TeX Live that is 5 years behind the yearly release schedule, now would be a good time for the folks on the DragonFlyBSD build team to advance the package from 2015 to 2020. Portability improvements have been made this year to several of the subpackages in the TeX Live source tree, and the 2020 builds have proved to be largely problem free on most systems, including DragonFlyBSD, where a one-line command using the default gcc and g++ compilers, builds the entire system: /path/to/source/tree/build-texlive-2020.sh texlive-20200307 The fine drawing program, Asymptote, builds with similar one-liner: /path/to/source/tree/build-asymptote.sh texlive-20200307 --- - Nelson H. F. BeebeTel: +1 801 581 5254 - - University of UtahFAX: +1 801 581 4148 - - Department of Mathematics, 110 LCBInternet e-mail: be...@math.utah.edu - - 155 S 1400 E RM 233 be...@acm.org be...@computer.org - - Salt Lake City, UT 84112-0090, USAURL: http://www.math.utah.edu/~beebe/ - ---
Re: DragonFlyBSD 5.6.2 installation failures
This is a final status report on the failure of DragonFlyBSD 5.6.2 to install on my new Dell Precision 7920 workstation. There appear to be two problems with my environment: the DragonFlyBSD installer does not recognize the Realtek USB controller on the Dell, nor does it recognize the SATA controller. By numerous experiments, we found that switching the keyboard from a USB one to a PS/2 one solved the no-keyboard-input problem. We successfully installed DragonFlyBSD 5.6.2 on Crucial MX500 1TB SSD on a Lenovo ThinkCenter all-in-one workstation, and were able to boot that installation to a login prompt on both that system, and on a Mac Pro tower, confirming that both the USB stick with the installer and the Crucial SSD are OK. On the Dell, today we installed a new 2-port Inateck USB-3.0 PCI-E card, and plugged the keyboard and a Sabrent SATA-to-USB-3 box into that card. The system now boots to a login prompt on the Dell, and I've done extensive binary package installations, and a fresh build of the latest TeX Live 2020 source tree. The only drawback of this workaround is that the Crucial disk is accessed over a USB-3 connection, rather than a direct SATA connection. My thanks go to several list members for helpful offline correspondence that led to a solution! --- - Nelson H. F. BeebeTel: +1 801 581 5254 - - University of UtahFAX: +1 801 581 4148 - - Department of Mathematics, 110 LCBInternet e-mail: be...@math.utah.edu - - 155 S 1400 E RM 233 be...@acm.org be...@computer.org - - Salt Lake City, UT 84112-0090, USAURL: http://www.math.utah.edu/~beebe/ - ---
Re: DragonFlyBSD 5.6.2 installation failures
This is just a status update on my long problem report about being unable to install DragonFlyBSD 5.6.2 on my new Dell Precision 7920 workstation. Some correspondents have since kindly provided suggestions, and I have accordingly made several more attempts, all without success, and all with the same hang during the boot. I have tried both *.img and *.iso DragonFlyBSD file types, removed the conv=fdatasync from the dd command used to copy those files to USB drives, tried the Ubuntu /usr/bin/usb-creator-gtk tool to write the USB drive instead of using dd, tried USB devices from at least six different hardware vendors, and tried recent daily snapshots of DragonFlyBSD, as well as the official 5.6.2, 5.6.1, 5.4.1, and 5.4.0 releases. I then attempted installs of OpenBSD 6.5 and 6.6 from *.iso and *.fs files: the *.iso files result in "no bootable device found", but the *.fs files got a bit further, finally hanging, either with no further keyboard input possible, or completing the boot, but being unable to see the installation disk. A quick reboot with an Ubuntu 20.04 USB showed that the target disk is definitely there. Next, I tried Trident/TrueOS: installation succeeded, but the system would then not reboot. With Trident/Void Linux, installation failed with property 'autotrim' is not a valid filesystem property ERROR: could not create pool: trident on /dev/sda3 The target disk is a brand new Crucial MX500 1TB SSD. Yesterday afternoon, I tried GhostBSD 20.01, and that succeeded. I've installed 100+ packages on it, and successfully built TeX Live 2020 (see http://www.math.utah.edu/pub/texlive-utah-2020/ for a status report: a build from a DragonFlyBSD 5.2 VM is included there). I'm now installing several recent gcc releases with support for decimal floating-point arithmetic. Once my GhostBSD work is done, I'll return to the DragonFlyBSD builds and followup on another helpful suggestion sent this morning by a list member. Thanks again for your kind suggestions! --- - Nelson H. F. BeebeTel: +1 801 581 5254 - - University of UtahFAX: +1 801 581 4148 - - Department of Mathematics, 110 LCBInternet e-mail: be...@math.utah.edu - - 155 S 1400 E RM 233 be...@acm.org be...@computer.org - - Salt Lake City, UT 84112-0090, USAURL: http://www.math.utah.edu/~beebe/ - ---
DragonFlyBSD 5.6.2 installation failures
I've been running about 20 different DragonFlyBSD releases from 3.x to 5.6 on VMs (VMware workstation, VMware/ESX, VirtManager QEMU/KVM, and OVirt) without any serious difficulties. Today, I decided to try installation of 5.6.2 on my new workstation, a Dell Precision 7920 (1 16-core CPU, 32 hyperthreads, 2200MHz Intel Xeon Platinum 8253, 32GB DDR-4 RAM). That system has 8 externally-accessible disk drives, and I'm using it as a test bed for O/S installations, with recent Fedora, FreeBSD, Microsoft Windows, NetBSD, OS108, TrueOS, and Ubuntu releases in place and working normally. Solaris 11.4 installs, but then fails at boot time with an infinite loop that is probing for USB devices. Until today, that was the only O/S that has failed to produce a working installation on my Dell box. This morning, I made a copy of a 4-day old ISO image for DragonFlyBSD 5.6.2 on a new KOOTION 64GB USB-3 drive and attempted to install it. The boot proceeded normally for some time, but finally reached a point in text mode on the console that looks like this (typed by hand): ... CAM: Configuring 1 busses CAM: finished configuring all busses Device Mapper version 4.16.0 loaded dm_target_error: Successfully initialized dm_target_zero: Successfully initialized no disk named 'part-by-label/DragonFly_v5.7.0.1310.g63d3b.a setrootbyname failed ffs_mountroot: can't find rootvp Root mount failed: 6 Manual root filesystem specification: : Specify root (e.g. ufs:da0s1a) ? List valid disk boot devices panic Just panic abort Abort manual input At that point, no further keyboard input is possible, and Ctl-Alt-Del does not reboot the system. A power cycle is necessary. I also attempted a boot from the recovery mode menu item: it hangs the same way. The same hang happens with a "without AHCI" and with a "without ACPI" menu item boot choice, and with both legacy boot, and UEFI boot. On the Dell system, I've removed all but the USB drive and one disk: in the disk bay, I've tried an old Hitachi 5K750-500 500GB SSD, and a brand new never-written-to Crucial MX500 1 TB SSD. I then tried a 5.6.2 ISO image from 1-Jan-2020, and copied it onto a Kingston USB: same behavior. Then I tried last night's *.img file, copying it onto a Crucial USB with a command like this on another box running Ubuntu 19.10: % dd bs=4M if=DragonFly-x86_64-LATEST-IMG.img of=/dev/sdc conv=fdatasync status=progress Again I got the same behavior on a boot. I then tried the three USB drives on an Intel NUC with a M.2 NVMe drive, and an old Lenovo all-in-one desktop. On the NUC, the *.img file reaches the installer/root prompt, but on login as root, "camcontrol devlist" shows only the USB drive. I suspected that the M.2 disk might be a problem, and it is. On the Lenovo, "camcontrol devlist" shows the USB drive and the normal disk, so an install might be possible. I did not do so, because it already has a working O/S on it that I didn't want to destroy. The fact that booting from three different USB drives, three different DragonFly snapshots in two different formats (*.iso and *.img), and two different target SSDs, all behave the same way suggests that the failures are NOT due to boot media errors or installation target media errors. Has any list member seen the hang that I describe, and if so, does anyone have some idea of how I might reach an DragonFlyBSD installer prompt on my Dell Precision 7920? --------------- - Nelson H. F. BeebeTel: +1 801 581 5254 - - University of UtahFAX: +1 801 581 4148 - - Department of Mathematics, 110 LCBInternet e-mail: be...@math.utah.edu - - 155 S 1400 E RM 233 be...@acm.org be...@computer.org - - Salt Lake City, UT 84112-0090, USAURL: http://www.math.utah.edu/~beebe/ - ---
Reduce algebra system successfully built on DragonFlyBSD 5.2
Recent correspondence on the Reduce algebra system developers list at reduce-algebra-develop...@lists.sourceforge.net raised the issue of porting that system to OpenBSD and other BSD members. Reduce is the second oldest computer algebra system, and was developed at Utah, shortly after MIT's Macsyma; both first appeared in 1968, a half century ago this year. Older versions of Reduce have been ported to FreeBSD (e.g., binary package reduce-20170124 in FreeBSD 10.x, 11.x and 12.x, and in PCBSD and its succcessor TrueOS), but packaging systems of all other BSD family members, including DragonFlyBSD, appear to lack Reduce. I'm happy to report that a recent version of Recent has been successfully built on the new DragonFlyBSD 5.2 (11-Apr-2018) with this recipe: cd $prefix/ashare/reduce gtar xf ~/Reduce-svn4372-src.tar.gz cd Reduce-svn4372-src mkdir /tmp/bin ln -s /usr/local/bin/guname /tmp/bin/uname set path = ( /tmp/bin /bin /usr/bin /usr/local/bin ) env CC='gcc6 -I/usr/local/include/freetype2 -I/usr/local/include/ncurses' \ CXX='g++6 -I/usr/local/include/freetype2 -I/usr/local/include/ncurses' \ ./configure --with-csl && gmake all check ln -s `pwd`/bin/redcsl $prefix/bin/reduce-20180228-csl ln -s reduce-20180228-csl $prefix/bin/reduce-csl ln -s reduce-csl $prefix/bin/reduce Here is a short demonstration: % set path=( $path $prefix/ashare/reduce/Reduce-svn4372-src/scripts ) Reduce (Free CSL version, revision 4330), 21-Apr-18 ... 1: int(sin(x), x); - cos(x) 2: int(exp(-x) * sin(x), x); - (cos(x) + sin(x)) -- x 2*e 3: on rounded; 4: precision 75; 12 5: sin(22); -0.00885130929040387592169025681577233246328920395133256644233083529808955201463 More information about publications about Reduce can be found in bibliographies at http://www.math.utah.edu/tex/bib/ in the files red-a-f.bib red-g-l.bib red-m-z.bib redbooks.bib redextra.bib reduce.bib and at the FAQ at http://www.math.utah.edu/faq/reduce/ The official SourceForce site for Reduce source code is http://reduce-algebra.sourceforge.net/ Its release as Free Software was announced in its original author's paper Anthony C. Hearn REDUCE is free software as of January 2009 ACM Communications in Computer Algebra 43(1--2) 15--16 March/June 2009 https://doi.org/10.1145/1610296.1610299 and its first 40 years are described at http://reduce-algebra.com/reduce40.pdf Three further points should be noted: (1) Reduce can be hosted on either Portable Standard Lisp (PSL) or on Codemist Standard Lisp (CSL). My DragonFlyBSD build selected the latter, because the PSL version has proved more difficult to port, and because PSL will not currently work on systems with W^X (write, or execute, but not both) protection for stack memory. (2) Reduce must currently be built where it is to be installed; that restriction may be lifted in the future, because it makes Reduce unusual compared to other packages. (3) I had to extend PATH above to run it outside its build tree; that has not been necessary on other O/Ses, but a 3-line wrapper shell script could easily hide that misfeature on DragonFlyBSD. Perhaps someone on this list who is familiar with package construction for DragonFlyBSD might be willing to build and repackage the latest version of Reduce for inclusion in the DragonFlyBSD package repository. I'm now turning to build attempts for Reduce on older DragonFlyBSD releases. --- - Nelson H. F. BeebeTel: +1 801 581 5254 - - University of UtahFAX: +1 801 581 4148 - - Department of Mathematics, 110 LCBInternet e-mail: be...@math.utah.edu - - 155 S 1400 E RM 233 be...@acm.org be...@computer.org - - Salt Lake City, UT 84112-0090, USAURL: http://www.math.utah.edu/~beebe/ - ---
Re: ASLR and PIE disabled by default
List members have been discussing security mechanisms for DragonFlyBSD
today.
I recently watched OpenBSD architect Theo de Raadt's presentation
Pledge:a new security technology in OpenBSD
https://www.youtube.com/watch?v=F_7S1eqKsFk
He argues that most security wrappers for software from other O/Ses
are too complex, as evidenced by their low rate of adoption.
He then goes on to describe the pledge() call that allows software to
declare their needed security features, after which the kernel ensures
that they are not violated.
I was sufficiently intrigued to try it on one of my own software
packages, and here is all that it took to get it implemented:
In configure.in, add
AC_CHECK_HEADERS(sys/pledge.h)
In the main() program, near the top, add
#if defined(HAVE_SYS_PLEDGE_H)
if (pledge("cpath rpath stdio tty wpath", NULL) != 0)
{
perror("pledge system call failed: perror says");
exit(EXIT_FAILURE);
}
#endif
For more on pledge(), see its manual pages at
http://man.openbsd.org/pledge
Starting with a guess of "stdio" for the needed security classes, it
took me about 20 minutes to figure out what other classes my program
needed.
Matt Dillon is correct that having to add security declarations in
software is onerous, and a possible source of error, and having
external global mechanisms, such as in the kernel or the shell, or
stack W^X (write-or-execute, but not both) protection, are more
secure.
Because we see increasing attacks against software, it seems to me
that we realistically have to use both approaches, and given how
little code that pledge() takes, I am prepared to use it in new
releases of my own code.
Unfortunately, for those scripting languages such as perl, python, and
ruby, that make pretty much any Unix system call available, the
pledge() approach cannot just be put into the language interpreter: it
has to be put into the scripts themselves.
-----------
- Nelson H. F. BeebeTel: +1 801 581 5254 -
- University of UtahFAX: +1 801 581 4148 -
- Department of Mathematics, 110 LCBInternet e-mail: be...@math.utah.edu -
- 155 S 1400 E RM 233 be...@acm.org be...@computer.org -
- Salt Lake City, UT 84112-0090, USAURL: http://www.math.utah.edu/~beebe/ -
---
Status report on TeX Live 2016 release preparation
I am one of the team members who work each year on the preparation and testing of the annual TeX Live releases. About this time each year, the work is announced complete, and a DVD is prepared for distribution to TeX User Group members and other TeX user groups around the world, and conference attendees at the annual TUG meeting (this year in Toronto, ON, Canada: see http://www.tug.org/meetings.html ). For several years, the DVD has been full, so it has had to be trimmed to fit, and the number of binary distributions for particular operating-system/CPU platforms has been limited. DragonflyBSD has not been included in past years, although the DragonflyBSD support team has provided TeX Live packages installable via "pkg install". This year, I have prepared a Web site at http://www.math.utah.edu/pub/texlive/ that reports on the status of the team work, and supplied binaries for numerous platforms (74 as of this morning), along with a list of binaries missing from particular platforms. The bin link at the start of the above Web page leads to downloadable .tar.xz files, and the purpose of this note is to report that DragonflyBSD 3.8, 3.9, 4.0, 4.2, 4.4, and 4.6, all on x86-64, are included there. The end of that Web page tells how to fetch the rest of the TeX Live 2016 system, and keep it up-to-date with the tlmgr utility. It has not been possible for me to build either asymptote (asy and xasy executables), or xindy, on DragonflyBSD. Asymptote builds fail in the libatomic_ops code portion, and xindy needs clisp, which seems never to have been ported to DragonflyBSD (and I've never succeeded in building it myself on any version of that O/S). Perhaps some DragonflyBSD experts on this list would like to take on the challenge of getting clisp working on that system, and fixing the libatomic_ops issues for asymptote. If you wish to do so, feel free to communicate with me off list, either via e-mail, or via telephone if e-mail seems not to get a response (I have numerous filters in place that block many domains, but can open up particular addresses as needed). --- - Nelson H. F. BeebeTel: +1 801 581 5254 - - University of UtahFAX: +1 801 581 4148 - - Department of Mathematics, 110 LCBInternet e-mail: be...@math.utah.edu - - 155 S 1400 E RM 233 be...@acm.org be...@computer.org - - Salt Lake City, UT 84112-0090, USAURL: http://www.math.utah.edu/~beebe/ - ---
[DragonFly-users] real dragonflies in the news
According to a just-published story about new research, it seems that our insect mascot has an interesting property: Dragonfly Sets Record for Insect Migration http://www.rdmag.com/articles/2016/03/dragonfly-sets-record-insect-migration The story notes that one species of the insect travels 4400 miles (7100 km) or more in migration. --- - Nelson H. F. BeebeTel: +1 801 581 5254 - - University of UtahFAX: +1 801 581 4148 - - Department of Mathematics, 110 LCBInternet e-mail: be...@math.utah.edu - - 155 S 1400 E RM 233 be...@acm.org be...@computer.org - - Salt Lake City, UT 84112-0090, USAURL: http://www.math.utah.edu/~beebe/ - ---
DragonFly 3.6-RELEASE: how to crash the kernel from userland
I run DragonFly 3.6-RELEASE (and also 3.4) on VMware ESX on Sun AMD64 hardware, along with dozens of other virtual machines. Today, I found out how to reliably, and preproducibly, crash the 3.6 kernel from a user process: build GNU rcs-5.9.1 or rcs-5.9.2, available at ftp://ftp.gnu.org/gnu/rcs/ There is a kernel panic immediately after this report from the configure run: checking signal received if referencing nonexistent part of mmapped file... I cannot capture the exact panic report easily from the VMware console, which puts me into a debugger with prompt db, at which typing reset reboots the system. After the reboot, examination of /var/log/messages shows something similar to what I saw in the VMware console window: Jul 17 14:52:47 xxx syslogd: kernel boot file is /boot/kernel/kernel Jul 17 14:52:47 xxx kernel: pid 23179 (conftest), uid 887: exited on signal 11 Jul 17 14:52:47 xxx kernel: panic: assertion ref = td-td_toks_base ref-tr_tok == tok failed in lwkt_reltoken at /build/home/justin/src/sys/kern/lwkt_token.c:812 Jul 17 14:52:47 xxx kernel: cpuid = 0 Jul 17 14:52:47 xxx kernel: Trace beginning at frame 0xffe05ce377d8 Jul 17 14:52:47 xxx kernel: panic() at panic+0x223 0x80561c0c Jul 17 14:52:47 xxx kernel: panic() at panic+0x223 0x80561c0c Jul 17 14:52:47 xxx kernel: lwkt_reltoken() at lwkt_reltoken+0x5d 0x80575f98 Jul 17 14:52:47 xxx kernel: sigexit() at sigexit+0xce 0x80564a78 Jul 17 14:52:47 xxx kernel: postsig() at postsig+0x1c7 0x80564c46 Jul 17 14:52:47 xxx kernel: userret() at userret+0x18d 0x8092ed6d Jul 17 14:52:47 xxx kernel: trap() at trap+0x6b4 0x8092fb4c Jul 17 14:52:47 xxx kernel: calltrap() at calltrap+0x9 0x80919bef Jul 17 14:52:47 xxx kernel: --- trap 000c, rip = 00400ab4, rsp = ffe05ce37ab0, rbp = 7fffe990 --- Jul 17 14:52:47 xxx kernel: kernmxps() at 0x400ab4 0x400ab4 Jul 17 14:52:47 xxx kernel: kernmxps() at 0x400926 0x400926 Jul 17 14:52:47 xxx kernel: Debugger(panic) Jul 17 14:52:47 xxx kernel: Jul 17 14:52:47 xxx kernel: CPU0 stopping CPUs: 0x Jul 17 14:52:47 xxx kernel: stopped Can anyone reproduce this crash on physical hardware? Builds of the two named releases of GNU rcs on DragonflyBSD 3.4 work just fine. All of the files in /boot/kernel on my 3.6 system are dated 20-Feb-2014 14:47, and the panic persists even after running pkg update pkg upgrade to ensure that all software components are current (as expected, because the kernel files themselves do not change). --- - Nelson H. F. BeebeTel: +1 801 581 5254 - - University of UtahFAX: +1 801 581 4148 - - Department of Mathematics, 110 LCBInternet e-mail: be...@math.utah.edu - - 155 S 1400 E RM 233 be...@acm.org be...@computer.org - - Salt Lake City, UT 84112-0090, USAURL: http://www.math.utah.edu/~beebe/ - ---
