Re: mount softdep — does it improve the situation for unexpected shutdowns?

2023-11-05 Thread Geoff Steckel

I'm going to blame softdep:
A long time ago when modifying large numbers of files
  on a machine with limited memory suddenly:
   the system became completely unresponsive,
   the disk light was on solid
   the poor little disk was rattling continuously.
That went on for minutes.

The same job on the same machine without softdep
ran slowly and with lots of moderate disk rattle but it
completed normally.

My guess is that softdep ran out of buffers and purged
every one of them. All at once.
Never enabled softdep after that.

Geoff Steckel




Loongson: Version 7.3 package information in 7.4 SHA256 file

2023-11-05 Thread Carsten Strotmann
Hi,

(sorry for the misdirected subscribe mail this morning - I've recognised the 
error soon after sending, but could not cancel the message)

I found a possible issue with the SHA256 file for the Loongson architecture for 
OpenBSD 7.4

That file contains the names and hashes of (some) 7.3 install packages (along 
with the correct 7.4 names and hashes).


"sysupgrade" will try to download the 7.3 packages from the 7.4 installurl, and 
will fail.

Removing the wrong 7.3 references fixes the file.

Patch to create a fixed SHA256 file:

--- SHA256.old  Sun Nov  5 11:33:19 2023
+++ SHA256.new  Sun Nov  5 11:33:42 2023
@@ -8,11 +8,7 @@
 SHA256 (game74.tgz) = 
358caf89d2a8b7d22aaa59e26ca34ad66c43e37de6e8579c64b25476b5371e59
 SHA256 (man74.tgz) = 
94782f99765a612ffa6a27fb11433f53088e3ca7fb90aee19be196a35e8cb997
 SHA256 (miniroot74.img) = 
749d275bc67355c742b1c25ff13508442d38fe7c2e8494bafdeff46d26025e2d
-SHA256 (xbase73.tgz) = 
d5844b1f2c172e10496efc1baa8eeb355940956a907a9275f1f096833e260f09
 SHA256 (xbase74.tgz) = 
dcaf6e3d636663319c765dae90212b9864ece9a5ad4e45656a221caf0a28a943
-SHA256 (xfont73.tgz) = 
6bdf10f73be2cb2f5d83288ee882a49fa91a93244a5dfff3b6ffd77ca2650658
 SHA256 (xfont74.tgz) = 
9bd11d9d1213713b5c394a7259841aef52f6d237875002fd452d4cfd84e15a81
-SHA256 (xserv73.tgz) = 
7140a67c48460a148f71e20aea677e5a20e0819eccb39fbbe1884210c253ebe4
 SHA256 (xserv74.tgz) = 
3cd38cd95760d71febc6c13213279081bdab2ec2facf4709f383dd6594af5c9c
-SHA256 (xshare73.tgz) = 
d9eedf413cfce03eafc09f4a90e4d71f511fafcd90379ac2305ac9ae350d6c43
 SHA256 (xshare74.tgz) = 
014a306a6c98c6e55f682242a2ede50c3a98d2a0b426df974c3fdfae89913f1e


Maybe this can be fixed on the mirror servers.

Greetings

Carsten Strotmann

P.S.: if this was an attempt to check if there is anyone still using OpenBSD on 
Loongson, it worked. It's me ;)



Re: mount softdep — does it improve the situation for unexpected shutdowns?

2023-11-05 Thread Marc Espie
Not quite sure how much has been discussed publically, but we don't
currently have the manpower to handle lots of complicated parts,
and it seems that softdep, in its current state, needs the hand of
Kirk McKusick to work.

So the current strategy has been to make the moving parts simpler
(softdep, scheduler) in order to reduce the amount of bugs, so that
hopefully we can make things faster again later once they're
rock-solid.

(in case you're wondering how softdep might be an issue, for instance
there are lots of moving parts in swap, the buffecache, the page
zeroer, that tend to run amok unless carefully tended, and until
we get a better grasp on this, something akin to softdep is unlikely
to come back)



Re: mount softdep — does it improve the situation for unexpected shutdowns?

2023-11-05 Thread Mike Fischer
Thanks! End of discussion ;-)

(Except for a potential update of the man page.)


Mike

> Am 05.11.2023 um 19:39 schrieb Martin Schröder :
> 
> Am So., 5. Nov. 2023 um 19:33 Uhr schrieb Mike Fischer
> :
>> However the default /etc/fstab does not make use of it.
> 
>> From the 7.4 release notes:
> --
> Make the softdep mount(8) option a no-op. Softdep was a
>  significant impediment to improving the vfs layer.
> --
> 
> Methinks the man page could mention that.
> 
> Best
>Martin
> 




Re: mount softdep — does it improve the situation for unexpected shutdowns?

2023-11-05 Thread Martin Schröder
Am So., 5. Nov. 2023 um 19:33 Uhr schrieb Mike Fischer
:
> However the default /etc/fstab does not make use of it.

>From the 7.4 release notes:
--
Make the softdep mount(8) option a no-op. Softdep was a
  significant impediment to improving the vfs layer.
--

Methinks the man page could mention that.

Best
Martin



mount softdep — does it improve the situation for unexpected shutdowns?

2023-11-05 Thread Mike Fischer
OpenBSD 7.4 amd64

I have just noticed that mount(8) has a softdep option for FFS file systems. 
And I saw this:
https://en.wikipedia.org/wiki/Soft_updates
where OpenBSD is mentioned.

However the default /etc/fstab does not make use of it.

We have been discussing how to deal with unexpected system crashes/loss of 
power/etc. and found that with a probability of significantly greater than zero 
such an event will cause inconsistent file systems, sometimes irreparable, with 
data loss or worse with lurking modified files that may be noticed much later.

So I’d like to know if adding the softdep option for the FFS file systems in 
/etc/fstab would improve the situation? Is anyone using this?

Is there a reason it is not used by default?

I realise that no solution will be 100%. Backups, snapshots from a powered down 
machine (in the case of VMs), etc. will still be required. But at least 
improving the odds of surviving an unexpected reboot without file system sync 
would help, unless there are drawbacks I am not aware of.

I did see https://marc.info/?l=openbsd-misc=157537250901987=2
are the comments there still valid (for VMs using SSD storage)? Personally I 
would not mind a bit of memory usage and speed impact in exchange for a more 
robust system.


Thanks!
Mike



Subscribe misc@openbsd.org

2023-11-05 Thread Carsten Strotmann
subscribe misc@openbsd.org



OpenBSD FDE: Protect with keydisk + passphrase

2023-11-05 Thread misc

Hi misc,

In the past, I used to mount a secondary drive into /mnt/, the keydisk 
protected by a password.


Now I use FDE with a keydisk, but would like to protect the bootable 
system with a keydisk + passphase (something you have + something you know).


Any chance doing this directly using bioctl ?

-fm



Re: texlive and tlmgr

2023-11-05 Thread Robert Alessi
On Sun, Nov 05, 2023 at 10:44:36AM +0100, Luciano Ribichini wrote:
> Hallo openbsd-mailinglist,
> 
> 1) my name is Luciano, I am a long time linux user.
> 
> 2) Currently I keep an eye on openbsd.
> 
> 3) Thanks a lot for your work, really.
> 
> 4) Having plenty of operating systems to choose from is a good thing.
> 
> 5) Since I use TeX/LaTeX I ask:
> 
> does Texlive work on openbsd, and does tlmgr work too?
> 
> (I read that there are issues).

Basically all you have to do is to install your preferred flavor of
texlive from ports and it will just work.[1]

If by texlive you mean the one supplied by https://tug.org/texlive,
you can use the custom binary set build by Nelson Beebe.  Instructions
on how to do this can be found here:

   https://tug.org/texlive/custom-bin.html

and you will find Nelson Beebe's binary sets for OpenBSD here:

https://ftp.math.utah.edu/pub/texlive-utah/bin/

Once this is done, you can use texlive pretty much in the same way as
under Linux and update it with tlmgr.

This is what I do.  Either way, you will have to install biber by
yourself.

> Thanks a lot again for your work
> 
> Luciano

Footnotes:
[1]  e.g. https://openports.pl/path/print/texlive/texmf,-full



Re: texlive and tlmgr

2023-11-05 Thread David
On Sun, 2023-11-05 at 10:44 +0100, Luciano Ribichini wrote:
> Hallo openbsd-mailinglist,
> 
> 1) my name is Luciano, I am a long time linux user.
> 
> 2) Currently I keep an eye on openbsd.
> 
> 3) Thanks a lot for your work, really.
> 
> 4) Having plenty of operating systems to choose from is a good thing.
> 
> 5) Since I use TeX/LaTeX I ask:
> 
> does Texlive work on openbsd,

Yes.

https://openbsd.app/?search=texlive

>  and does tlmgr work too?

I have no idea, and should advise against using it.
All the different Linux and BSDs have their different packages and
tlmgr would probably not cater to that.
I've used texlive for ages, and experience no problems with the system
specific package managers.
Cheers!


-- 
`I intend to live forever,
or die trying'.

--Groucho Marx



texlive and tlmgr

2023-11-05 Thread Luciano Ribichini

Hallo openbsd-mailinglist,

1) my name is Luciano, I am a long time linux user.

2) Currently I keep an eye on openbsd.

3) Thanks a lot for your work, really.

4) Having plenty of operating systems to choose from is a good thing.

5) Since I use TeX/LaTeX I ask:

does Texlive work on openbsd, and does tlmgr work too?

(I read that there are issues).


Thanks a lot again for your work

Luciano



smtpd[68513]: warn: lost processor: spamassassin exited abnormally

2023-11-05 Thread Harald Dunkel

Hi folks,

since OpenBSD 7.4 the spamassassin filter seems to be broken. On
the first EMail opensmtpd dies with a message in maillog saying

Nov  5 08:59:23 mhost smtpd[60460]: bcc4f33a095bb28e smtp connected 
address=xx.xx.xx.xx host=mail.example.com
Nov  5 08:59:23 mhost filter-spamassassin[7782]: bcc4f33a095bb28e protocol 
report 0.7
Nov  5 08:59:23 mhost filter-spamassassin[7782]: exit
Nov  5 08:59:23 mhost smtpd[68513]: warn: lost processor: spamassassin exited 
abnormally
Nov  5 08:59:23 mhost smtpd[68513]: Exiting


smtpd is configured according to /usr/local/share/doc/pkg-readmes/\
opensmtpd-filter-spamassassin (except for the tls option):

xname = "mailhost.example.de"
pki $xname cert "/etc/ssl/example.de/fullchain.pem"
pki $xname key  "/etc/ssl/example.de/privkey.pem"
pki $xname dhe  auto

filter "spamassassin" proc-exec "filter-spamassassin"

listen on all tls pki $xname filter "spamassassin"
listen on socket filter "spamassassin"
:
:

If I kick out the tls stuff, it is still broken.

Can anybody reproduce this? Every helpful hint is highly
appreciated.


Harri



Re: smtpd[68513]: warn: lost processor: spamassassin exited abnormally

2023-11-05 Thread Omar Polo
On 2023/11/05 09:59:14 +0100, Harald Dunkel  wrote:
> Hi folks,
> 
> since OpenBSD 7.4 the spamassassin filter seems to be broken. On
> the first EMail opensmtpd dies with a message in maillog saying
> 
> Nov  5 08:59:23 mhost smtpd[60460]: bcc4f33a095bb28e smtp connected 
> address=xx.xx.xx.xx host=mail.example.com
> Nov  5 08:59:23 mhost filter-spamassassin[7782]: bcc4f33a095bb28e protocol 
> report 0.7
> Nov  5 08:59:23 mhost filter-spamassassin[7782]: exit

This seems to suggest that it's due the filter-protocol version bump.

(+cc filter-spamassassin maintainers)

I don't use filter-spamassassin and can't test, but since it doesn't
seem to use link-auth it shouldn't care about this protocol change, so
just bumping the version should be enough.

Can you try the following diff to see if it helps?

Index: Makefile
===
RCS file: /home/cvs/ports/mail/opensmtpd-filters/spamassassin/Makefile,v
retrieving revision 1.8
diff -u -p -r1.8 Makefile
--- Makefile26 Sep 2023 12:28:14 -  1.8
+++ Makefile5 Nov 2023 09:20:27 -
@@ -4,7 +4,7 @@ V = 0.7
 FILTER_NAME =  spamassassin
 DISTNAME = filter-spamassassin-${V}
 HOMEPAGE = https://www.umaxx.net/
-REVISION = 0
+REVISION = 1
 
 CATEGORIES =   mail
 
Index: patches/patch-filter-spamassassin_go
===
RCS file: patches/patch-filter-spamassassin_go
diff -N patches/patch-filter-spamassassin_go
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-filter-spamassassin_go5 Nov 2023 09:20:36 -
@@ -0,0 +1,14 @@
+handle the smtpd filter-protocol version 0.7
+
+Index: filter-spamassassin.go
+--- filter-spamassassin.go.orig
 filter-spamassassin.go
+@@ -211,7 +211,7 @@ func run() {
+   for in.Scan() {
+   f := strings.Split(in.Text(), "|")
+   t, ver, ev, sid := f[0], f[1], f[4], f[5]
+-  if (t != "filter" && t != "report") || ver != "0.6" {
++  if (t != "filter" && t != "report") || ver != "0.7" {
+   l3.Err(fmt.Sprintln(sid, "protocol", t, ver))
+   return
+   }