Re: Firefox extension broken in -current's v71.0
>Synopsis: "1Password X" extension on Firefox shows 0 passwords >When logging into the 1Password X extension, you'll see a brief flash > of your vault items (passwords), but after ~100ms they >disappear and are replaced with the text "No items in this vault." I had this problem until I changed /etc/login.conf default class to use datasize-max=7000M: and datasize-cur=7000M and rebooted. I have 8GB RAM and haven't tried lower values yet for datasize-max and -cur. I am using only three extensions: 1Password X, Firefox Containers, and UBlock Origin. For me, 1Password X will not work until I disable UBlock Origin and then restart Firefox. I then sign in to 1 Password X. At that point, I can re-enable UBlock Origin and everything works. The problem started with 1Password's new version 1.17.0. This workaround does work on all my -current machines. If I go to about:debugging# and This Firefox and UBlock Origin, I see "WebAssembly.Memory failed to reserve a large virtual memory region. This may be due to low configured virtual memory limits on this system." I don't know how to fix this, and my increased datasize-max and -cur don't change this. But if UBlock Origin starts before 1Password X, my guess is that this memory error stops 1Password X from working. As a side note, I have to start Firefox from the Downloads folder if I want to be able to upload files from it.
small update to man smtpd.conf
Synopsis: small update to man smtpd.conf to include from local syntax Category: documentation Environment: System : OpenBSD 6.6 Details : OpenBSD 6.6-current (GENERIC.MP) #509: Tue Dec 3 19:03:47 MST 2019 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP Architecture: OpenBSD.amd64 Machine : amd64 Description: man smtpd.conf doesn't yet include the new "from local" syntax in EXAMPLES section The man page is not wrong. However, I think "from local" can be included in the section about forwarding email to other servers. I've tested it with several servers. I don't know if this next bit should also be in the man page, but in order to get forwarding to work, I fill in the well-known aliases on the sending machine with a different domain than the actual hostname. For example, the server that sends email may have foo.my.local in /etc/myname, but I fill in root@fictional.domain in the well-known aliases in /etc/mail/aliases. The receiving server of course needs a match statement for that fictional domain. How-To-Repeat: man smtpd.conf Fix: Index: usr.sbin/smtpd/smtpd.conf.5 === RCS file: /cvs/src/usr.sbin/smtpd/smtpd.conf.5,v retrieving revision 1.236 diff -u -p -u -r1.236 smtpd.conf.5 --- usr.sbin/smtpd/smtpd.conf.5 5 Dec 2019 14:49:35 - 1.236 +++ usr.sbin/smtpd/smtpd.conf.5 5 Dec 2019 17:12:34 - @@ -1151,8 +1151,8 @@ action "local_mail" mbox alias action "outbound" relay host smtp+tls://b...@smtp.example.com \e auth -match for local action "local_mail" -match for any action "outbound" +match from local for local action "local_mail" +match from local for any action "outbound" .Ed .Pp In this second example,
neomutt segmentation faults when command line email sent
Synopsis: neomutt segmentation faults when command line email sent Category: user Environment:OpenBSD 6.6 Details : OpenBSD 6.6-current (GENERIC.MP) #427: Sat Nov 2 13:23:11 MDT 2019 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP Architecture: OpenBSD.amd64 Machine : amd64 Description: Neomutt segmentation faults when command line email is sent. How-To-Repeat: echo "hi there" | neomutt -s hi root@localhost OR neomutt -s somesubject somebody@any.where < sometextfile This happens with or without a subject, to any email address. It also happens with or without a muttrc or neomuttrc file present. It happens on several different current boxes with different hardware, including one box with kern.version=OpenBSD 6.6-current (GENERIC) #410: Tue Nov 5 17:00:09 MST 2019 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC, and no packages other than neomutt dependencies. Sending email with neomutt from the command line stopped working for me around Oct 27. I use cwm and have tried from an xterm with and without tmux. Sending does with neomutt-20180716p1-gpgme-sasl on one box that runs 6-6.current GENERIC.MP #389. I've tried neomutt-20191102-gpgme-sasl and neomutt-20191102 on a few current boxes, but it always seg faults. I'm very sorry that I don't know where to start fixing it. I will also build it from ports on another current box. I can include a diff of neomutt -D 5 on a working vs nonworking version if needed. I could run gdb on neomutt, but I'm not sure how to run it on something like "neomutt some@company.domain
umount usb drive after using openrsync
Synopsis: umount says device busy after having used openrsync Category: user Environment: System : OpenBSD 6.5 Details : OpenBSD 6.5-current (GENERIC.MP) #158: Tue Jul 30 15:25:51 MDT 2019 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP Architecture: OpenBSD.amd64 Machine : amd64 Description: After using openrsync to sync files from a mounted USB drive to a local directory, I then always see a device busy error when trying to unmount the USB drive. This has been happening on several machines on amd64 for the last few snapshots (maybe a month or so.) Sometimes fuser will show nothing; other times it shows lots of processes including 1, so a reboot is necessary in order to unmount. This happens for me with any USB drive I try and from three different OpenBSD machines with different hardware running snapshots. I've checked ps, fstat -v, fuser, pstat -s, looked for symbolic links, exited all programs and terminals, logged and and back in, but only a reboot helps. I'm running cwm and haven't tried when booting to console instead of enabling xenodm. I'm definitely not in /mnt from any terminal when trying to umount. /sbin/umount -f does work. I haven't had this problem on 6.5-release. How-To-Repeat: mount a USB drive, use openrsync to sync files to a local directory, then try to unmount the USB drive. I'm including a script below. It shows that unmounting works before running openrsync, but fails after syncing. (The syncing itself is great though -- I thank everyone who worked on it and of course all of OpenBSD!!!) Script started on Wed Jul 31 09:25:35 2019 root@joe$ /sbin/mount /dev/sd3a on / type ffs (local) /dev/sd3d on /tmp type ffs (local, nodev, nosuid) /dev/sd3f on /usr type ffs (local, nodev) /dev/sd3g on /usr/X11R6 type ffs (local, nodev) /dev/sd3h on /usr/local type ffs (local, nodev, wxallowed) /dev/sd3k on /usr/obj type ffs (local, nodev, nosuid) /dev/sd3j on /usr/src type ffs (local, nodev, nosuid) /dev/sd3e on /var type ffs (local, nodev, nosuid) /dev/sd3l on /home type ffs (local, nodev, nosuid) /dev/sd4a on /mnt type ffs (local) root@joe$ /sbin/umount /mnt root@joe$ /sbin/mount /dev/sd4a /mnt root@joe$ /bin/ls /mnt root@joe$ /sbin/umount /mnt root@joe$ /sbin/mount /dev/sd4a /mnt root@joe$ /usr/bin/touch /mnt/a /mnt/b /mnt/c root@joe$ /bin/mkdir /tmp/testbak root@joe$ cd /mnt root@joe$ /usr/bin/openrsync --rsync-path=/usr/bin/openrsync -vvv -r -t. /tmp/testbak/ /usr/src/usr.bin/rsync/main.c:466: exec[0] = /usr/bin/openrsync /usr/src/usr.bin/rsync/main.c:466: exec[1] = --server /usr/src/usr.bin/rsync/main.c:466: exec[2] = -r /usr/src/usr.bin/rsync/main.c:466: exec[3] = -t /usr/src/usr.bin/rsync/main.c:466: exec[4] = -v /usr/src/usr.bin/rsync/main.c:466: exec[5] = -v /usr/src/usr.bin/rsync/main.c:466: exec[6] = -v /usr/src/usr.bin/rsync/main.c:466: exec[7] = . /usr/src/usr.bin/rsync/main.c:466: exec[8] = /tmp/testbak/ /usr/src/usr.bin/rsync/client.c:71: client detected client version 27, server version 27, seed -2038779841 /usr/src/usr.bin/rsync/server.c:99: server detected client version 27, server version 27, seed -2038779841 /usr/src/usr.bin/rsync/client.c:82: client starting sender: (local) /usr/src/usr.bin/rsync/server.c:128: server starting receiver /usr/src/usr.bin/rsync/flist.c:1002: generated 4 filenames: . /usr/src/usr.bin/rsync/flist.c:1028: recursively generated 4 filenames /usr/src/usr.bin/rsync/flist.c:268: sending file metadata list: 4 /usr/src/usr.bin/rsync/flist.c:305: .: sending file metadata: size 512, mtime 1564583177, mode 40755 /usr/src/usr.bin/rsync/flist.c:305: ./a: sending file metadata: size 0, mtime 1564583177, mode 100644 /usr/src/usr.bin/rsync/flist.c:305: ./b: sending file metadata: size 0, mtime 1564583177, mode 100644 /usr/src/usr.bin/rsync/flist.c:305: ./c: sending file metadata: size 0, mtime 1564583177, mode 100644 /usr/src/usr.bin/rsync/flist.c:739: .: received file metadata: size 512, mtime 1564583177, mode 40755, rdev (0, 0) Transfer starting: 4 files /usr/src/usr.bin/rsync/flist.c:739: ./a: received file metadata: size 0, mtime 1564583177, mode 100644, rdev (0, 0) /usr/src/usr.bin/rsync/flist.c:739: ./b: received file metadata: size 0, mtime 1564583177, mode 100644, rdev (0, 0) /usr/src/usr.bin/rsync/flist.c:739: ./c: received file metadata: size 0, mtime 1564583177, mode 100644, rdev (0, 0) /usr/src/usr.bin/rsync/flist.c:765: received file metadata list: 4 /usr/src/usr.bin/rsync/receiver.c:233: /tmp/testbak/: receiver destination /usr/src/usr.bin/rsync/receiver.c:329: /tmp/testbak/: ready for phase 1 data /usr/src/usr.bin/rsync/uploader.c:544: .: updating directory /usr/src/usr.bin/rsync/uploader.c:952: ./a: not mapped /usr/src/usr.bin/rsync/uploader.c:952: ./b: not mapped /usr/src/usr.bin/rsync/uploader.c:952: ./c: not mapped /usr/src/usr.bin/rsync/blocks.c:392: ./a: read block prologue: 0 blocks of 32768 B,
/usr/src/etc/unbound.conf example for DNS over TLS has port 953 instead of port 853
Synopsis: example DNS-over-TLS port in unbound.conf is 953 instead of 853 Category: unbound DNS-over-TLS Environment: System : OpenBSD 6.5 Details : OpenBSD 6.5-current (GENERIC.MP) #139: Wed Jul 24 05:11:28 MDT 2019 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP Architecture: OpenBSD.amd64 Machine : amd64 Description: example port is 953 instead of 853 in forward-addr example in /usr/src/etc/unbound.conf How-To-Repeat: see /usr/src/etc/unbound.conf Fix: Index: etc/unbound.conf === RCS file: /cvs/src/etc/unbound.conf,v retrieving revision 1.15 diff -u -p -u -r1.15 unbound.conf --- etc/unbound.conf15 Jul 2019 10:18:20 - 1.15 +++ etc/unbound.conf26 Jul 2019 17:08:03 - @@ -71,4 +71,4 @@ remote-control: # forward-tls-upstream: yes # use DNS-over-TLS forwarder # forward-first: no # do NOT send direct # # the hostname after "#" is not a comment, it is used for TLS checks: -# forward-addr: 192.0.2.53@953#resolver.hostname.example +# forward-addr: 192.0.2.53@853#resolver.hostname.example
man ports says set PLIST_DB but PLIST_DB is deprecated
>Synopsis: man ports says set PLIST_DB but PLIST_DB is deprecated >Category: man pages >Environment: System : OpenBSD 6.5 Details : OpenBSD 6.5-current (GENERIC.MP) #22: Wed Jun 12 20:26:15 MDT 2019 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP Architecture: OpenBSD.amd64 Machine : amd64 >Description: In USING A READ_ONLY PORTS tree section of man ports, it says set PLIST_DB but (I believe it) should say set PLIST_REPOSITORY Please note that man bsd.port.mk says PLIST_DB is deprecated. Also, setting PLIST_DB in /etc/mk.conf doesn't change permissions when one runs make fix-permissions, but make fix-permissions does work if one sets PLIST_REPOSITORY in /etc/mk.conf. This occurs because /usr/ports/infrastructure/mk/bsd.port.mk in the fix-permissions sections affects PLIST_REPOSITORY but not PLIST_DB. >How-To-Repeat: set PLIST_DB in /etc/mk.conf and then run make fix-permissions in /usr/ports. The directory permissions for PLIST_DB are not changed. But if PLIST_REPOSITORY is set in /etc/mk.conf and make fix-permissions in /usr/ports is run, the permissions are changed appropriately. >Fix: Index: share/man/man7/ports.7 === RCS file: /cvs/src/share/man/man7/ports.7,v retrieving revision 1.126 diff -u -p -u -r1.126 ports.7 --- share/man/man7/ports.7 30 May 2019 09:24:08 - 1.126 +++ share/man/man7/ports.7 16 Jun 2019 12:12:42 - @@ -641,7 +641,7 @@ Set .Ev UPDATE_COOKIES_DIR , .Ev DISTDIR , and -.Ev PLIST_DB +.Ev PLIST_REPOSITORY in .Pa /etc/mk.conf accordingly.
man page possible correction for ports, bsd.port.mk
1. man ports: In the Using a Read-Only Ports Tree section of man ports, I
believe
it should read PLIST_REPOSITORY instead of PLIST_DB.
(To support the change from PLIST_DB to PLIST_REPOSITORY,
please note that man bsd.port.mk says PLIST_DB is deprecated. Also,
make fix-permissions won't change permission if PLIST_DB is set
in /etc/mk.conf, but it does work if PLIST_REPOSITORY is set.)
2. man bsd.port.mk: in the PORTS_PRIVSEP section, where one adds
these commands to doas.conf: /usr/bin/touch, /usr/sbin/pkg_add, and
/usr/sbin/pkg_delete, I think an additional line is needed:
permit nopass setenv { TERM } solene cmd /usr/bin/env
(To support this addtion, please see these lines in
/usr/ports/infrastructure/mk/bsd.port.mk:
SETENV ?= /usr/bin/env -i
and
===> Installing . . . @${SUDO} ${SETENV} . . .)
These are in snapshots 6.5-current #19 Wed Jun 12 01:15:09 MDT 2019
