Re: dhcpd with failover

2024-10-01 Thread Otto Moerbeek
On Tue, Oct 01, 2024 at 12:34:31PM +0300, Kapetanakis Giannis wrote:

> 
> On 01/10/2024 08:36, Otto Moerbeek wrote:
> > On Mon, Sep 30, 2024 at 10:50:06PM +0300, Kapetanakis Giannis wrote:
> >
> >> How did you solve the problem of initial sync?
> >>
> >> Suppose one server goes down for maintenance. When it comes up it does not
> >> know what new leases have been given by the other server which was all the
> >> time up.
> >>
> >> There are chances that later it gives an IP already given by the other dhcp
> >> server. The leases (while down) were not synced.
> >>
> >> I don't think there is an option for initial sync (like pfsync) and even if
> >> you scp the lease file you can't be 100% sure since you might miss 
> >> something
> >> while copying and starting service.
> >>
> >> This is the primary reason I've sticked with isc-dhcpd and failover peer.
> >>
> >> G
> >>
> > IIRC on dhcpd statup all leases from the lease db are advertized to
> > the other dhcpds.
> >
> > -Otto
> 
> Didn't know about this but I don't think it solves the problem.
> The starting server is behind and missing entries from the lease file.
> 
> Does the starting server also request a full lease advertisement from the 
> other server?
> 
> What happens with the other server (which is NOT restarting) and how will it 
> notify the starting server that there are new leases (without a restart)?
> 
> Unless a server startup triggers full advertizement on all sides.
> 
> G
> 

Look in src/usr.sbin/dhcpd/sync.c, on receiving a lease, dhcpd checks
if the other deamon has old info:

   /*
 * our partner sent us a lease
 * that is older than what we have,
 * so re-educate them with what we
 * know is newer.
 */

So if the starting dhcpd daemon sends out info that is known to be
outdated, it wil be corrected by the others.

I'm not 100% sure that will cover all cases though.

-Otto



Re: dhcpd with failover

2024-09-30 Thread Otto Moerbeek
On Mon, Sep 30, 2024 at 10:50:06PM +0300, Kapetanakis Giannis wrote:

> How did you solve the problem of initial sync?
> 
> Suppose one server goes down for maintenance. When it comes up it does not
> know what new leases have been given by the other server which was all the
> time up.
> 
> There are chances that later it gives an IP already given by the other dhcp
> server. The leases (while down) were not synced.
> 
> I don't think there is an option for initial sync (like pfsync) and even if
> you scp the lease file you can't be 100% sure since you might miss something
> while copying and starting service.
> 
> This is the primary reason I've sticked with isc-dhcpd and failover peer.
> 
> G
> 

IIRC on dhcpd statup all leases from the lease db are advertized to
the other dhcpds.

-Otto



Re: Building -current incrementally.

2024-09-25 Thread Otto Moerbeek
On Thu, Sep 26, 2024 at 08:46:19AM +0200, Christian Schulte wrote:

> On 9/26/24 07:15, Otto Moerbeek wrote:
> > On Thu, Sep 26, 2024 at 06:38:00AM +0200, Christian Schulte wrote:
> > 
> >> So I installed 7.5-stable on a VPS and that kernel panicked during 
> >> installation
> >> several times. I then grabbed a 7.6-current image and installed the system
> >> using that. That kernel does not panic so I am running -current on that 
> >> system
> >> since then. Checked out /usr/src, build the system from source using
> >> make build. Did cvs -q update -dP -A every now and then and just ran
> >> make followed by doas make install from time to time in the various 
> >> directories.
> >> Accidentally ran make in /usr/src and got an unexpected Permission denied
> >> error. I would have expected to be able to run make in /usr/src without any
> >> permission issues. Is this a bug in the build system? There must be a way 
> >> to
> >> build base incrementally without having to rebuild everything.
> >> $cd /usr/src && make currently stops with a Permission denied error I 
> >> would not
> >> have expected to happen.
> >>
> >>
> >> build: atu-intersil-int: Permission denied
> >> *** Error 1 in sys/dev/microcode/atmel (Makefile:22 'atu-intersil-int')
> >> *** Error 2 in sys/dev/microcode (:48 'all': @for entry in 
> >> afb atmel bnx cirruslogic fxp kue neomagic myx ral rsu rtwn rum  s...)
> >> *** Error 2 in sys (:48 'all': @for entry in dev/microcode  
> >> arch/alpha arch/amd64 arch/arm64 arch/armv7  arch/hppa arch/i386 ...)
> >> *** Error 2 in /usr/src (:48 'all': @for entry in lib 
> >> include bin libexec sbin usr.bin usr.sbin share games gnu sys; do  set ...)
> >>
> > 
> > 1. Note that "make build" builds kernels and install images but does
> > not install them.
> > 
> > 2. Did you follow the steps in the FAQ and release(5):
> > https://www.openbsd.org/faq/faq5.html? And no, it is not *always*
> > possible to build incrementally. Sometimes a clean build is needed.
> 
> Of course I followed those steps. That's what makes me think something
> is not working the way it is intended. After installing a recent
> snapshot, I checked out /usr/src and did a make build. I thought this
> leaves me with a pre built tree I can just build incrementally. Indeed
> this is working. So, after a cvs -q update -dP -A I just cd'ed into the
> directories containing files with changes and did make followed by doas
> make install. Also in /sys/arch/amd64/compile/GENERIC.MP. This has been
> working as expected. I then accidentally ran make directly in /usr/src
> which is failing due to some Permission denied I do not understand. I
> can still run make install in /usr/src without issues.

Your method is flawed, as parts of the build proces may be rebuilding
parts that depend on e.g. installed libraries or include files that
changed, so more than just the dir containing changed files should be
rebuilt in many cases.

If you are doing partial builds and run into issues, they are yours to
fix.

> 
> 
> > 
> > 3. You might want to consider not building from source, but install a
> > snapshot by running sysupgrade -s.
> 
> I am keen on knowing how those snapshots are build. Do they really wipe
> out everything and then do a fresh build - lasting nearly 24h here for
> me. I doubt it.

Your doubts are unfounded and not really relevant. A fast machine does
a full make build in an hour or so. Slower architecturs require more
time, of course. 

-Otto



Re: Building -current incrementally.

2024-09-25 Thread Otto Moerbeek
On Thu, Sep 26, 2024 at 06:38:00AM +0200, Christian Schulte wrote:

> So I installed 7.5-stable on a VPS and that kernel panicked during 
> installation
> several times. I then grabbed a 7.6-current image and installed the system
> using that. That kernel does not panic so I am running -current on that system
> since then. Checked out /usr/src, build the system from source using
> make build. Did cvs -q update -dP -A every now and then and just ran
> make followed by doas make install from time to time in the various 
> directories.
> Accidentally ran make in /usr/src and got an unexpected Permission denied
> error. I would have expected to be able to run make in /usr/src without any
> permission issues. Is this a bug in the build system? There must be a way to
> build base incrementally without having to rebuild everything.
> $cd /usr/src && make currently stops with a Permission denied error I would 
> not
> have expected to happen.
> 
> 
> build: atu-intersil-int: Permission denied
> *** Error 1 in sys/dev/microcode/atmel (Makefile:22 'atu-intersil-int')
> *** Error 2 in sys/dev/microcode (:48 'all': @for entry in afb 
> atmel bnx cirruslogic fxp kue neomagic myx ral rsu rtwn rum  s...)
> *** Error 2 in sys (:48 'all': @for entry in dev/microcode  
> arch/alpha arch/amd64 arch/arm64 arch/armv7  arch/hppa arch/i386 ...)
> *** Error 2 in /usr/src (:48 'all': @for entry in lib include 
> bin libexec sbin usr.bin usr.sbin share games gnu sys; do  set ...)
> 

1. Note that "make build" builds kernels and install images but does
not install them.

2. Did you follow the steps in the FAQ and release(5):
https://www.openbsd.org/faq/faq5.html? And no, it is not *always*
possible to build incrementally. Sometimes a clean build is needed.

3. You might want to consider not building from source, but install a
snapshot by running sysupgrade -s.

-Otto



Re: Need some information about fork(2) -- Pedantic Correction

2024-09-23 Thread Otto Moerbeek
On Sun, Sep 22, 2024 at 04:47:33PM -0500, Jay F. Shachter wrote:

> 
> > 
> > It's an exact copy, all memory allocations remain the same.
> >
> 
> Please forgive the pedantic correction, but, although I don't know how
> OpenBSD does it, I certainly hope that OpenBSD does it the way other
> operating systems do it: the memory in the child process is not "an
> exact copy" -- the memory is not copied at all, but it is marked "copy
> on write" so that a copy of a page will be made when either the parent
> or the child alters it.  But as long as neither parent nor child
> alters the memory there is no need to make a copy of it.  Certainly if
> the fork() will be followed soon afterward by an exec(), copying all
> that memory which is all going to be freed up a microsecond later
> anyway would be folly.
> 
> Similarly, a later poster made a comparison to a file copy: there are
> now two copies of a file, altering one does not alter the other.  Now
> again, I don't know how the native OpenBSD filesystem does it, but I
> hope that (at least as a mount or tunefs option, you might not want it
> in every case) the native OpenBSD filesystem does it the way ZFS and
> other proper filesystems do it: the data blocks are not copied, but
> they are marked "copy on write" and a copy is made when either file is
> altered.  As long as neither file is altered, there is no need to copy
> the data blocks on which the file resides.
> 
> And yes, I do know that OpenBSD refuses to support ZFS, because
> OpenBSD is terrified of the patent, or maybe it's a copyright, even
> though FreeBSD and NetBSD have no fear of it.  But I digress.
> 

Indeed, these are digressions. What you are talking about are
implementation details/optimizations. From a userland memory
management perspecive, it does not matter if your process virtual
memory is copy-on-write or not. Same for filesystems. It's the
kernel's job to abstract these differences away, and it a good thing a
userland developer does not have to worry about cow.

-Otto



Re: Need some information about fork(2)

2024-09-22 Thread Otto Moerbeek
On Sun, Sep 22, 2024 at 08:07:54PM +0200, Страхиња Радић wrote:

> Дана 24/09/22 07:59PM, Страхиња Радић написа:
> > Of course, that would cause a memory leak if the memory was assigned to 
> > a variable, like this:
> > 
> > char* tmp = malloc(13);
> > 
> > otherwise, like this:
> > 
> > malloc(13);
> > 
> > the result is discarded and a warning is printed if the program is 
> > compiled by GCC.
> 
> Correction/clarification: even if the result is discarded, this still
> causes the leak, just the pointer to the allocated memory is not
> assigned to a variable. This is easily verifiable by using
> ktrace(1)/kdump(1).
> 

All correct, but still, on process exit all resources used by a
program are cleaned up. In that sense it is not a memory leak to not
call free. Especially for one-time allocations.

It is differrent if the malloc is e.g. in a loop, causing memory usage
to grow while executing the program. That is a memory leak you want to
fix, especially if the program is a long running one, like a daemon.

-Otto



Re: Need some information about fork(2)

2024-09-22 Thread Otto Moerbeek
On Sun, Sep 22, 2024 at 05:33:36PM +0200, bi...@iscarioth.org wrote:

> Sorry for disturbing you, again...
> 
> Does it means we should also free virtual memory from the child
> process before exiting ?

All resources used by a process are freed automatically when the
process ends. Typically, a fork in the child is followed by an
execve(2) call, which replaces the current process by a new one, whith
only a few things inherited.

-Otto

> 
> On 2024-09-22T10:27:56.000+02:00, Otto Moerbeek 
> wrote:
> 
> > On Sun, Sep 22, 2024 at 10:08:56AM +0200, bi...@iscarioth.org wrote:
> > 
> >>  Hello OpenBSD team
> >>  
> >>   I'm having a little trouble understanding how this works.
> >>  
> >>   of fork(2), according to man. It's an exact copy of the parent
> >>  
> >>   process.
> >>  
> >>   There are limitations that are explicit in the man. However,
> >>  
> >>   I wanted to know if the pointers we use are the same.
> >>  
> >>   For example, if I had allocated 4 bytes in my parent process, I
> >>  would
> >>  
> >>   launch the fork...
> >>  
> >>   If I release this address from the child, is the father's pointer
> >>  
> >>   still intact, or is it released?
> >>  
> >>   Translated with DeepL.com [http://DeepL.com] (free version)
> > 
> > It's an exact copy, all memory allocations remain the same. The
> > trick
> > 
> > is the new process virtual memory space is seperate, so the equal
> > 
> > pointer actually refer to different sets of memory (each process has
> > 
> > it's onwn virual memory space). So an allocatoon or free done by the
> > 
> > parent or child does not interfere with the other process.
> > 
> >  -Otto
> 



Re: Need some information about fork(2)

2024-09-22 Thread Otto Moerbeek
On Sun, Sep 22, 2024 at 10:08:56AM +0200, bi...@iscarioth.org wrote:

> Hello OpenBSD team
> 
> I'm having a little trouble understanding how this works.
> 
> of fork(2), according to man. It's an exact copy of the parent
> process.
> 
> There are limitations that are explicit in the man. However,
> 
> I wanted to know if the pointers we use are the same.
> 
> For example, if I had allocated 4 bytes in my parent process, I would
> launch the fork...
> 
> If I release this address from the child, is the father's pointer
> still intact, or is it released?
> 
> Translated with DeepL.com (free version)

It's an exact copy, all memory allocations remain the same. The trick
is the new process virtual memory space is seperate, so the equal
pointer actually refer to different sets of memory (each process has
it's onwn virual memory space). So an allocatoon or free done by the
parent or child does not interfere with the other process.

-Otto



Re: unbound(8) + host(1) + AAAA-only issue

2024-09-20 Thread Otto Moerbeek
On Fri, Sep 20, 2024 at 12:45:08PM +0200, Mike Fischer wrote:

> 
> > Am 20.09.2024 um 12:13 schrieb Stuart Henderson :
> > 
> >> From what you've shown I can only assume the auth servers are broken
> > and probably refusing to respond for A (rather than an empty NOERROR
> > response).
> 
> I agree, that is probably the root cause.
> 
> So that would cause host(1) to abort looking for other RRsets? Is that not a 
> bug in host(1)?
> 
> Note: I tried looking at the source code of host(1) but I can’t figure out 
> how it works.
> 
> 
> > -only is a somewhat rare case and IPv6 has only been supported in
> > DNS since 2008 or so, it takes time to get the bugs worked out
> > especially in custom DNS software like is probably used for a dynamic
> > dns zone.
> 
> Yes, a mere 18 years is rather new ;-)
> 
> 
> > If you show the real hostname, maybe someone can figure it out in
> > more detail.
> 
> This is an example hostname I created at dynv6.com for the purpose of 
> figuring out this issue:
> test.fwml42.v6.rocks
> 
> $ dig +short test.fwml42.v6.rocks 
> 2001:db8::dead:beaf
> $ host test.fwml42.v6.rocks
> Host test.fwml42.v6.rocks not found: 2(SERVFAIL)
> $ 

Here host just succeeds with that name (not using unbound as resolver
but PowerDNS recursor)

$ host test.fwml42.v6.rocks
test.fwml42.v6.rocks has IPv6 address 2001:db8::dead:beaf

A tip to investigate further: use -v with host (it shows more
details), don't use +short with dig (it hides useful information).

-Otto



Re: rw- directory mode : different ls behavior

2024-09-17 Thread Otto Moerbeek
On Tue, Sep 17, 2024 at 10:40:23AM +0100, Zé Loff wrote:

> On Tue, Sep 17, 2024 at 10:56:27AM +0200, Denis Bodor wrote:
> > On Tue, Sep 17, 2024 at 09:43:27AM +0200, tomas.ri...@tutanota.com wrote:
> > > I would expect that without the 'x' bit, the directory is not searchable
> > > and I won't be able to list its contents. But in fact I can, unless I
> > > use a long format (-l, -g or -n).
> > >
> > > Can someone please explain the above behaviour? Thank you. Tom
> > 
> > Very roughly...
> > The list of files in a directory is information about the directory.
> > If you chmod -r my-test-dir, this information will no longer be available,
> > for example.
> > The file size is information about the files themselves; to read it, you
> > need to be in the directory. But as you can't, it's unreadable.
> > 
> > -- 
> > Denis
> > 
> 
> It's a bit more complicated than that AFAICT.  Although I can reproduce
> this inside /tmp, the behaviour is not consistent.  If I try to ls the
> folder on a different shell -- e.g. a different terminal, or after
> exiting script(1) -- the files aren't shown.  Also, if I rm -rf the
> folder and recreate it (i.e. reuse the name) the files also aren't shown
> the second time around.
> 
> -- 
>  
> 

Please take great care when testing this, it is easy to fool yourself.
For example, often ls is aliased to add some flags. I have 

alias ls='ls -F'

which fails because it needs to look inside the dir.

For proper testing, use \ls i.e. the non-aliased version.

-Otto



Re: Automatic Disk Partitioning

2024-08-12 Thread Otto Moerbeek
On Wed, Aug 07, 2024 at 01:50:39AM +0200, David Uhden Collado wrote:

> > The rationale is that the installer is not able to make a reasonable
> > guess about
> > how you plan to use the system.  It knows the minimum required filesystem
> > sizes, and if you have a moderate amount of extra disk it has rules on how
> > to allocate the extra.
> > 
> > But if you have an extremely large amount of extra space there's no way to
> > tell what you have planned for it.  Are you going to run a database? Maybe
> > the extra space should go into /var.  Or better yet, use that extra space to
> > make a new filesystem like /var/mariadb or /var/postgresql.  Or maybe you
> > are setting up a web server and you'll want /var/www enlarged.  Maybe you
> > will want the extra space in an entirely new directory like /nfs.
> > 
> > If the installer can't reasonably guess, it is better to leave the space
> > unused
> > as it's easy to add space somewhere if you have extra, but hard if you
> > don't.
> > The idea here is to start with sane defaults, not immediately paint you into
> > a corner.
> 
> Now I understand the rationale. It might be beneficial for the installer to
> offer multiple templates when selecting the automatic partitioning option.
> These templates could cater to various common use cases, making the process
> more convenient and often eliminating the need for manual disk partitioning.


It's also possible to tweak the auto partitioned proposal when
installing. Choose the appropriate option ((E)dit auto layout) and use
the R command to resize the partition sizes you don't like. If you
shrink or grow a partition, the partitons after it wil be moved. You
can also delete or add partitions in that step.

-Otto



Re: tcpdump on openbsd

2024-07-05 Thread Otto Moerbeek
On Fri, Jul 05, 2024 at 02:39:48PM +, Mik J wrote:

> Hello,
> 
> I notice that tcpdump on openbsd differs from the linux version.
> 
> Some options don't exist:
> - G rotate_seconds
> - W filecount
> 
> Do you know why tcpdump on openbsd don't include these switch ?
> 
> Would it be possible to implement them on openbsd ?
> 
> Regards
> 

A long time ago, tcpdump was forked by the OpenBSD project and later
rewritten to use privilege separation by canacar@ and myself. This
means than all the interpretation of network data is done in a
seperate, unprivileged process that can do no damage even if one of
the disectors is buggy.

Before and after that moment (about 20 years ago), the code bases
diverged, and OpenBSD's version does not have all the new/fancy stuff
that the original upstream version has.  The big advantage is that I
dare to run the OpenBSD one.

You can always take a look to see if new features can be ported to
OpenBSD's tcpdump. Sometimes it's easy, sometimes not.

-Otto



Re: /sys is a symlink to an empty directory

2024-07-04 Thread Otto Moerbeek
On Fri, Jul 05, 2024 at 04:15:32AM +, Anon Loli wrote:

> On Thu, Jul 04, 2024 at 07:34:43PM +0200, Omar Polo wrote:
> > On 2024/07/04 17:08:53 +, Anon Loli  wrote:
> > > Hello mailing list
> > > Probably a stupid question, but I reinstalled OpenBSD like 10 times this 
> > > week,
> > > and every time I went to compile the kernel like it says in the 
> > > documentation,
> > > I could always cd into /sys/dev..., but this install it seems like /sys 
> > > points
> > > to "usr/src/sys" (it's "usr", not "/usr").
> > > 
> > > All I did on this install was download tar.gz files and extract them in 
> > > /usr,
> > > including the /usr/sys folder, which was supposed to be in /sys 
> > > pre-installed
> > > with the system, what's happening?
> > > Did I broke something again and need to install again? -_-
> > > 
> > > I'm currently following documentation and doing everything in /usr/sys
> > > (extracted AND VERIFIED from tar.gz) as if it were /sys
> > > 
> > > I'm sorry if this is a stupid question
> > > 
> > > Partition table:
> > > /
> > > /home
> > > /tmp
> > > /usr
> > > /usr/X11R6
> > > /usr/local
> > > /usr/obj
> > > /usr/ports
> > > /usr/ports/pobj
> > > /usr/src
> > > /var
> > > 
> > > All of them are <25% of capacity, it's a fresh install
> > 
> > Don't think it's a stupid question, but also nothing to worry.  AFAICS
> > /sys is always installed as a symlink to /usr/src/sys which works assuming
> > that you have the sources checked out in /usr/src (either via the
> > tarball, cvs, or got/git.)
> > 
> > I guess it's just to save some typing, not really sure, but nothing to
> > worry about :)
> > 
> > 
> > Cheers,
> > 
> > Omar Polo
> 
> 
> Really? Phew! That's a relief!
> But I wonder why it was empty before I manually planted the /usr/sys via tar
> extraction... does cvs checkout of SRC also fetch the sys directory?? because
> it wasn't empty when I worked with cvs instead
> 
> Thanks
> 

You are confused. 
The link in / is sys -> usr/src/sys

There is no such thing as a /usr/sys dir. You probably have extracted the
src or sys tarball in the wrong directory.

When you say: "I followed the instructions" it is always good to say
explicitly which instructions.

-Otto



Re: async-signal-safe *printf

2024-07-03 Thread Otto Moerbeek
On Wed, Jul 03, 2024 at 05:16:45PM +0900, Kensuke Matsuzaki wrote:

> Hi,
> 
> I'm reading libc source code.
> 
> According to man signal(3), dprintf(), vdprintf() etc are
> "async-signal-safe in OpenBSD except when used with floating-point
> arguments or directives".
> However __vfprintf seems to call malloc or wcrtomb when it is called
> with "%ls" or "%lc".
> 
> Is it async-signal-safe to call printf family with wide char?
> 
> Thank you.
> -- 
> Kensuke Matsuzaki
> 

Hi,

unless I'm missing something this seems to be an omission in the
signal(3) man page.

-Otto





Re: fsck similar to boot

2024-07-02 Thread Otto Moerbeek
On Tue, Jul 02, 2024 at 11:15:33AM +0100, 04-psyche.tot...@icloud.com wrote:

> Hi all,
> 
> I have removed my second drive away from /etc/fstab and I am now manually 
> mounting it as needed.
> 
> I believe this means there is no automatic fsck check ran, and that feels 
> like a bad thing.
> 
> I was thinking I should run the same fsck check when I manually mount my 
> drive.
> 
> How can I manually run a fast fsck check, equal to what is performed at boot 
> time?
> 
> I tried fsck -n and fsck -p but both of these are way too long, whereas the 
> boot check is fast.
> 
> Thanks!

Don't worry.  mount won't mount a dirty filesystem.

-Otto



Re: How are default config files populated?

2024-06-21 Thread Otto Moerbeek
On Fri, Jun 21, 2024 at 11:43:14PM +0100, Jo MacMahon wrote:

> Hello,
> 
> I recently needed to restore the file `/var/unbound/etc/unbound.conf`, which 
> is in the base system, to its original version, and assumed I could get it 
> out of one of the file sets, most likely `base75.tgz`. However the file is 
> not present in base75.tgz and none of the other sets look like they ought to 
> have it in. In the end I found the file I needed on GitHub, but I was curious 
> as to how it gets put in my system if it's not in a file set.
> 
> I noticed the same with `/etc/ssh/sshd_config`.
> 
> Are they generated after install time somehow? Or on first run of the 
> service? I don't think I had run unbound(8) before.
> 
> Jo
> 

Once upon a time the config files were in a separate set. These days
they are in the base tarball, packaged in ./var/sysmerge/etc.tgz. So
on installed systems /var/sysmerge has tarballs with the originals.

See sysmerge(8)

-Otto



Re: cpu cores

2024-06-08 Thread Otto Moerbeek
On Sat, Jun 08, 2024 at 03:58:30PM +0200, Andreas Kähäri wrote:

> On Sat, Jun 08, 2024 at 11:39:28AM +0100, Kirill A. Korinsky wrote:
> > On Sat, 08 Jun 2024 11:09:29 +0100,
> > Omar Polo  wrote:
> > > 
> > > On 2024/06/08 10:09:07 +0100, Kirill A. Korinsky  wrote:
> > > > On Sat, 08 Jun 2024 04:57:49 +0100,
> > > > Gustavo Rios  wrote:
> > > > > 
> > > > > i have installed obsd on my dell notebook 8 cores processor. When i 
> > > > > execute
> > > > > the top utility, it is showed the cores, from 0 (cpu0) to 7 (cpu7), 
> > > > > but
> > > > > cpu1 and cpu3 is not listed. What is the problem ?
> > > > > 
> > > > 
> > > > A blind guess: sysctl hw.smt=1 may return your hypertreading cores.
> > > 
> > > which is a very bad advice to give.  There's a reason sysctl hw.smt=1
> > > defaults to that value.  One should rather give a "blind guess" of "your
> > > hyperthread cores are disabled by default" rather than give a bad advice
> > > without explanation.
> > 
> > I'll make my advice cleaner, I defently mean that missed cores probably is
> > disabled becuae it is hyperthreading ones which can be seen as offline in
> > htop, or enable via sysctl.
> 
> 
> Not knowing too much about these things, I think it looks a bit strange
> that *two* out of eight CPUs are disabled due to hypethreading.  I would
> have expected every second one be disabled, i.e., four out of eight.

This simple rule does not apply to more modern CPUs, which can have
different types of cores, some with hyperthreading and some without.

-Otto

> 
> 
> 
> > 
> > Also, I'd like to add that from security point of view SMT in general and
> > hyperthreading as an example is very bad idea.
> > 
> > Thus, here old but interesting results that enabling hyperthreading has
> > negative effect on performance of have CPU used applications:
> > https://web.archive.org/web/20220325090914/http://users.telenet.be/nicvroom/performanceP4.htm
> > 
> > -- 
> > wbr, Kirill
> 
> -- 
> Andreas (Kusalananda) Kähäri
> SciLifeLab, NBIS, ICM
> Uppsala University, Sweden
> 
> .
> 



Re: [Solved] Edit: Installation amd64 7.5: How to access the distribution sets on the USB stick?

2024-06-08 Thread Otto Moerbeek
On Sat, Jun 08, 2024 at 03:33:15PM +0200, rfab...@mhsmail.ch wrote:

> Dear Jan
> 
> Thanks for your mail.
> 
> Am 2024-06-08 08:28, schrieb Jan Stary:
> 
> > When asked where the file sets are,
> > you tell the installer where on the USB stick they are.
> 
> The issue was the USB stick did not appear in the disk selection dialog.

Why do you think that? It is likely to be one of the sd disks.

-Otto

> 
> > > Installing the sets via http works without any issues, but that's not
> > > my plan for the remaining and future installations.
> 
> > Why?
> 
> - I'd like to spare the OpenBSD servers redundant download requests.
> 
> - The "INSTALLATION NOTES for OpenBSD/amd64 7.5" say: "It may save much
> time and frustration to download the distribution sets to a local server
> or disk and perform the installation from there, rather than directly
> from the internet."
> 
> Best regards
> 
> Rolf
> 



Re: Edit: Installation amd64 7.5: How to access the distribution sets on the USB stick?

2024-06-08 Thread Otto Moerbeek
On Fri, Jun 07, 2024 at 07:05:49PM -0400, Nick Holland wrote:

> On 6/7/24 18:26, rfab...@mhsmail.ch wrote:
> > Edit: I have just found in Michael W. Lucas' "OpenBSD Mastery:
> > Filesystems" that "the rd recovery disk image is the OpenBSD install
> > environment", not the USB stick. But my question (see below) remains the
> > same.
> > 
> > Am 2024-06-07 23:21, schrieb rfab...@mhsmail.ch:
> > Dear community
> > 
> > I have copied the 'install75.img' to a USB stick, booted from it and
> > chosen the "(I)nstall" option. My intention is to install the
> > distribution sets from the stick, and not via http, because I'd like to
> > install OpenBSD on our 4 home office PCs without downloading the sets 4
> 
> well...OpenBSD is small, and bandwidth is cheap/free.  But yeah, I was
> "recycling" back when it was called being "a cheap bastard", I get it.
> 
> > Escaping to a shell and entering 'sysctl hw.disknames' shows: 'sd0, sd1,
> > sd2, rd0'. 'sdX' are the 3 internal SSDs. Am I right in assuming that
> > 'rd0' is the USB stick?
> 
> as you have discovered...no.
> 
> > Installation step "Let's install the sets!":
> > I have chosen the option to install from a local disk partition, and
> > answered with "partition not mounted".
> 
> correct.
> 
> > Issue:
> > The installer shows 'sd0 sd1 sd2' as available disks, but not the USB
> > stick 'rd0'.
> 
> also correct.  Besides, rd0 is mounted. But it is also wrong.
> 
> > Question:
> > What do I have to do to make the USB installation stick available for
> > accessing the distribution sets? Concerning 'install75.img', the
> > "Installation notes" say: "An install or upgrade can be done with a
> > USB key without network connectivity."
> > But how?
> 
> dmesg|grep sd
> will show you what all the devices are, pick your USB drive.  It will guess
> correctly after that.

Or press ? at the right prompt and the installer will show you the
disk details so you can pick the right one.

-Otto

> > Installing the sets via http works without any issues, but that's not
> > my plan for the remaining and future installations.
> 
> But here's an easier way, if you understand a bit of what is going on.
> The system booted from bsd.rd, and it has utilities in "rd0".  At this
> point, it is NOT ACTUALLY USING the USB drive.  So...you can now unplug
> and plug it back in...and you will get some white on blue text telling
> you what device was unplugged and what was plugged in.
> 
> Of course, you don't really want to do that if you don't know for
> sure that the drive is unused, but if things are as you describe it,
> it's safe.
> 
> But most likely, it's sd2, because USB devices are enumerated AFTER
> IDE/SATA/SCSI/SAS/RAID connected drives.  (but there are things that
> can happen that keep me saying, "most likely" and "here's how you
> find out" rather than just assuming sd2. :) )
> 
> Nick.
> 



Re: wifi

2024-05-24 Thread Otto Moerbeek


I have no idea 

It depends on a lot of tings: availbility of docs from Realtek,
availability of hardware, availability of desire and time from a
developer.

FreeBSD has a driver, it uses their "bolt a Linux driver on a FreeBSD
kernel" framework we don't have. So no easy port of that one.

-Otto


On Fri, May 24, 2024 at 08:54:40PM -0300, Gustavo Rios wrote:

> Is there plan to add support ?
> 
> Thanks a lot
> 
> Em qui., 23 de mai. de 2024 às 04:10, Otto Moerbeek 
> escreveu:
> 
> > On Thu, May 23, 2024 at 03:56:01AM -0300, Gustavo Rios wrote:
> >
> > > Here you have them:
> >
> > ...
> > "Realtek 8821CE" rev 0x00 at pci2 dev 0 function 0 not configured
> >
> > That means there is no driver available in OpenBSD for that card.
> >
> > -Otto
> >
> 
> 
> -- 
> The lion and the tiger may be more powerful, but the wolves do not perform
> in the circus



Re: wifi

2024-05-23 Thread Otto Moerbeek
On Thu, May 23, 2024 at 03:56:01AM -0300, Gustavo Rios wrote:

> Here you have them:

...
"Realtek 8821CE" rev 0x00 at pci2 dev 0 function 0 not configured 

That means there is no driver available in OpenBSD for that card.

-Otto



Re: wifi

2024-05-22 Thread Otto Moerbeek
On Thu, May 23, 2024 at 01:44:57AM -0300, Gustavo Rios wrote:

> Hi folks!
> 
> I would like to setup my openbsd wifi but up to now, no success.
> Here is my lspci output. May some one help me ?
> 
> Thanks a lot.
> 
> 02:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8821CE
> 802.11ac PCIe Wireless Network Adapter
> 
> -- 
> The lion and the tiger may be more powerful, but the wolves do not perform
> in the circus

It helps more to send a dmesg, to see what the kernel thinks about the device,

-Otto



Re: smtpd outgoing mail configuration

2024-05-16 Thread Otto Moerbeek
On Fri, May 17, 2024 at 08:12:27AM +0200, fr...@lilo.org wrote:

> How to forward outgoing mail to a remote SMTP server with smtpd?
> 
> I found this page, but it's out of date I think.
> https://romanzolotarev.com/openbsd/smtpd-forward.html
> 
> Tks
> Pascal

man smtpd.conf, first exmaple

-Otto



Re: maximum file system size

2024-04-25 Thread Otto Moerbeek
On Thu, Apr 25, 2024 at 07:26:41AM +0200, Peter J. Philipp wrote:

> On Thu, Apr 25, 2024 at 12:45:29AM -0300, Gustavo Rios wrote:
> > Hi folks!
> > 
> > What is the maximum file size in OpenBSD ?
> > 
> > Thanks a lot.
> > 
> > -- 
> > The lion and the tiger may be more powerful, but the wolves do not perform
> > in the circus
> 
> There is this comment in /usr/include/ufs/ffs/fs.h:
> 
> /* Maximum file size the kernel allows.
>  * Even though ffs can handle files up to 16TB, we do limit the max file
>  * to 2^31 pages to prevent overflow of a 32-bit unsigned int.  The buffer
>  * cache has its own checks but a little added paranoia never hurts.
>  */
> #define FS_KERNMAXFILESIZE(pgsiz, fs)   ((u_int64_t)0x8000 * \
> MIN((pgsiz), (fs)->fs_bsize) - 1)
> 
> 
> Now page sizes differ within OpenBSD, so then it depends between 8 TB (4096
> bytes page size) and higher perhaps?
> 
> Best Regards,
> -pjp
> 
> -- 
> my associated domains:  callpeter.tel|centroid.eu|dtschland.eu|mainrechner.de
> 

dumpfs /dev/rsd0a | grep maxfilesize 

tells you the answer for a specific filesystem. A mentiomned in the
code commment, it depends on the blocksize used by the filesystem and
the page size of the platform.

-Otto



Re: errors rebuilding binaries after sysupgrade to 7.5

2024-04-22 Thread Otto Moerbeek
On Mon, Apr 22, 2024 at 10:09:51PM +0100, Steve Fairhead wrote:

> Hi folks,
> 
> (Apologies if this is a dupe. Looks to me like this didn't originally get
> far.)
> 
> Pretty sure this is pilot error, so please be gentle.
> 
> I sysupgraded 3 machines (all different) to 7.5; no problems. I then
> updated installed packages; again no problem.
> 
> Then I updated the source trees:
> 
> cd /usr/src
> cvs -q -d anon...@anoncvs.spacehopper.org:/cvs up -rOPENBSD_7_5 -Pd
> cd /usr/ports
> cvs -q -d anon...@anoncvs.spacehopper.org:/cvs up -rOPENBSD_7_5 -Pd
> 
> I then (following https://man.openbsd.org/release) rebuilt the kernel:
> 
> cd /sys/arch/amd64/compile/GENERIC.MP
> make obj
> make config
> make && make install
> reboot
> 
> Still no problem. Then I started to rebuild the binaries:
> 
> cd /usr/src
> make obj && make build
> 
> ... but eventually ran into shedloads of errors until it bailed. The first
> few errors are:
> 
> c++ -O2 -pipe  -fno-ret-protector -mno-retpoline -ffunction-sections
> -fdata-sections -std=c++17 -fvisibility-inlines-hidden -fno-exceptions
> -fno-rtti -fno-semantic-interposition -Wall -Wc++98-compat-extra-semi
> -Wcast-qual  -Wcovered-switch-default -Wctad-maybe-unsupported
> -Wdelete-non-virtual-dtor -Werror=date-time
> -Werror=unguarded-availability-new -Wextra  -Wimplicit-fallthrough
> -Wmisleading-indentation  -Wmissing-field-initializers -Wno-long-long
> -Wno-noexcept-type  -Wno-unused-parameter -Wnon-virtual-dtor
> -Wstring-conversion  -Wsuggest-override -Wwrite-strings -fno-pie  -MD -MP
>  -I/usr/src/gnu/usr.bin/clang/libclangAST/obj/../include/clang/AST
> -I/usr/src/gnu/usr.bin/clang/libclangAST/../../../llvm/clang/include
> -I/usr/src/gnu/usr.bin/clang/libclangAST/../../../llvm/llvm/include
> -I/usr/src/gnu/usr.bin/clang/libclangAST/../include
> -I/usr/src/gnu/usr.bin/clang/libclangAST/obj
> -I/usr/src/gnu/usr.bin/clang/libclangAST/obj/../include -DNDEBUG
> -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS  -D__STDC_FORMAT_MACROS -c
> /usr/src/gnu/usr.bin/clang/libclangAST/../../../llvm/clang/lib/AST/Interp/ByteCodeExprGen.cpp
> -o ByteCodeExprGen.o
> /usr/src/gnu/usr.bin/clang/libclangAST/../../../llvm/clang/lib/AST/Interp/ByteCodeExprGen.cpp:119:18:
> error: no member named 'emitCast' in
> 'clang::interp::ByteCodeExprGen'
> return this->emitCast(*FromT, *ToT, CE);
>  ^
> /usr/src/gnu/usr.bin/clang/libclangAST/../../../llvm/clang/lib/AST/Interp/ByteCodeExprGen.cpp:1428:16:
> note: in instantiation of member function
> 'clang::interp::ByteCodeExprGen::VisitCastExpr'
> requested here
> template class ByteCodeExprGen;
>^
> /usr/src/gnu/usr.bin/clang/libclangAST/../../../llvm/clang/lib/AST/Interp/ByteCodeExprGen.cpp:204:26:
> error: no member named 'emitRem' in
> 'clang::interp::ByteCodeExprGen'
> return Discard(this->emitRem(*T, BO));
>  ^
> /usr/src/gnu/usr.bin/clang/libclangAST/../../../llvm/clang/lib/AST/Interp/ByteCodeExprGen.cpp:1428:16:
> note: in instantiation of member function
> 'clang::interp::ByteCodeExprGen::VisitBinaryOperator'
> requested here
> template class ByteCodeExprGen;
>^
> 
> What did I do wrong?

What you normally do in these cases of build errors:

- Make sure that you do not have sticky tags in your tree (use -A with cvs up)
- Double check that the cvs update did not produce a report line on
any file
- Clean your object dir: rm -rf /usr/obj/*

Then try again.

-Otto
> 
> Thanks,
> 
> Steve
> 
> 
> 
> Virus-free.www.avg.com
> 
> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>



Re: Upgraded to 7.5: vfs.ffs.dirhash_dirsize no longer exists and large directory ere veeery slow

2024-04-12 Thread Otto Moerbeek
On Fri, Apr 12, 2024 at 12:21:43PM +0200, Dan wrote:

> 
> Really, I fear this value is due to a wrong tweak..


Fear is a bad advisor.

If you look at man 3 sysctl, you'll see what vfs.ffs.dirhash_mem
means:

 FFS_DIRHASH_MEM (vfs.ffs.dirhash_mem)
  The amount of memory currently used by all directory
  hashes.

In other words a harmless mem usage metric. 

-Otto

> 
> -Dan
> 
> Apr 12, 2024 09:09:06 Dan :
> 
> > 
> >> Yes, that fixes it for me:
> >> 
> >> $ sysctl vfs.ffs
> >> vfs.ffs.dirhash_dirsize=2560
> >> vfs.ffs.dirhash_maxmem=5242880
> >> vfs.ffs.dirhash_mem=767359
> > 
> > 
> > I have this value in 7.4 stable:
> > 
> > vfs.ffs.dirhash_mem=1412837
> > 
> > is it correct? or how to fix it?
> > 
> > 
> > -Dan
> 



Re: Upgraded to 7.5: vfs.ffs.dirhash_dirsize no longer exists and large directory ere veeery slow

2024-04-11 Thread Otto Moerbeek
On Thu, Apr 11, 2024 at 05:29:14PM +0200, Otto Moerbeek wrote:

> On Thu, Apr 11, 2024 at 05:20:24PM +0200, Otto Moerbeek wrote:
> 
> > On Thu, Apr 11, 2024 at 05:08:01PM +0200, Federico Giannici wrote:
> > 
> > > On 4/11/24 16:15, Claudio Jeker wrote:
> > > > On Thu, Apr 11, 2024 at 03:36:29PM +0200, Federico Giannici wrote:
> > > > > On 4/11/24 14:12, Nick Holland wrote:
> > > > > > On 4/11/24 05:47, Federico Giannici wrote:
> > > > > > > We have a server with A LOT of files in some directories (an email
> > > > > > > server in maildir format).
> > > > > > > 
> > > > > > > Since we upgraded from OpenBSD amd64 7.3 to 7.5 (passing through 
> > > > > > > 7.4) it
> > > > > > > became very very very slow to access these large directories!
> > > > > > ,,,
> > > > > > You may be being bitten by the removal of softdeps (soft updates)
> > > > > > in 7.4 more than the availability of a knob to twist.  This was a
> > > > > > huge hit for some things -- I had one backup job go from a couple
> > > > > > hours to eight or so hours.  However, it turned out that increase
> > > > > > in time has not inconvenienced me at all, and some random lockups
> > > > > > related to softdeps have gone away.  Overall, win for me (the
> > > > > > fscks after a lockup took hours, too, not to mention all the time
> > > > > > and effort spent replacing part after part assuming it was a HW
> > > > > > issue).
> > > > > > 
> > > > > > As I understand it...there were known (known unknown?) bugs in the
> > > > > > softdep code, the code was ugly, and it made it difficult to
> > > > > > actually improve the code.
> > > > > 
> > > > > No, we knew that softdeps were being deprecated and we removed from
> > > > > everywhere some time ago. It must be something else.
> > > > > 
> > > > > Anyway, it's strange that dirhash parameters has being changed and 
> > > > > removed
> > > > > without any mention...
> > > > 
> > > > It was not (this is on -current amd64):
> > > > vfs.ffs.dirhash_dirsize=2560
> > > > vfs.ffs.dirhash_maxmem=5242880
> > > > vfs.ffs.dirhash_mem=4832510
> > > > 
> > > > Are you sure your kernel and userland are in sync?
> > > 
> > > Well, I followed the prescribed procedure (I'm using OpenBSD since... 
> > > about
> > > 20 years).
> > > 
> > > In EVERY machine upgraded to 7.5 now I have something like this:
> > > 
> > > Elrond:/home/giannici$ sysctl vfs.ffs
> > > 
> > > 
> > > 
> > > vfs.ffs.dirhash_maxmem=2560
> > > vfs.ffs.dirhash_mem=5242880
> > > 
> > > Elrond:/home/giannici$ uname -a
> > > 
> > > 
> > > 
> > > OpenBSD Elrond.neomedia.it 7.5 GENERIC.MP#82 amd64
> > > 
> > > 
> > > So, I'm the only one?
> > > 
> > > Thanks.
> > > 
> > 
> > I suspect 
> > 
> > In 
> > https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/ufs/ffs/ffs_exatern.h.diff?r1=1.45&r2=1.46&f=h
> > 
> > The max_softdeps entry in ffs_extern.h should have been replace by a
> > { 0, 0 }
> > 
> > instead of being removed.
> > 
> > -Otto
> > 
> 
> Yes, that fixes it for me:
> 
> $ sysctl vfs.ffs
> vfs.ffs.dirhash_dirsize=2560
> vfs.ffs.dirhash_maxmem=5242880
> vfs.ffs.dirhash_mem=767359
> $
> 

to elaborate a bit: the vfs.ffs.dirhash_maxmem enty was actually
showing the value of the vfs.ffs.dirhash_dirsize entry. Trying to set the
vfs.ffs.dirhash_maxmem entry would result into setting the
vfs.ffs.dirhash_dirsize entry, which effectively disables dirhash if
yon set it to a high value.

It remains a mystery why Claudio is seeing the correct values... you'd
almost think he uses an old sysctl binary, or his tree is out of sync
somehow. 

-Otto



Re: Upgraded to 7.5: vfs.ffs.dirhash_dirsize no longer exists and large directory ere veeery slow

2024-04-11 Thread Otto Moerbeek
On Thu, Apr 11, 2024 at 05:20:24PM +0200, Otto Moerbeek wrote:

> On Thu, Apr 11, 2024 at 05:08:01PM +0200, Federico Giannici wrote:
> 
> > On 4/11/24 16:15, Claudio Jeker wrote:
> > > On Thu, Apr 11, 2024 at 03:36:29PM +0200, Federico Giannici wrote:
> > > > On 4/11/24 14:12, Nick Holland wrote:
> > > > > On 4/11/24 05:47, Federico Giannici wrote:
> > > > > > We have a server with A LOT of files in some directories (an email
> > > > > > server in maildir format).
> > > > > > 
> > > > > > Since we upgraded from OpenBSD amd64 7.3 to 7.5 (passing through 
> > > > > > 7.4) it
> > > > > > became very very very slow to access these large directories!
> > > > > ,,,
> > > > > You may be being bitten by the removal of softdeps (soft updates)
> > > > > in 7.4 more than the availability of a knob to twist.  This was a
> > > > > huge hit for some things -- I had one backup job go from a couple
> > > > > hours to eight or so hours.  However, it turned out that increase
> > > > > in time has not inconvenienced me at all, and some random lockups
> > > > > related to softdeps have gone away.  Overall, win for me (the
> > > > > fscks after a lockup took hours, too, not to mention all the time
> > > > > and effort spent replacing part after part assuming it was a HW
> > > > > issue).
> > > > > 
> > > > > As I understand it...there were known (known unknown?) bugs in the
> > > > > softdep code, the code was ugly, and it made it difficult to
> > > > > actually improve the code.
> > > > 
> > > > No, we knew that softdeps were being deprecated and we removed from
> > > > everywhere some time ago. It must be something else.
> > > > 
> > > > Anyway, it's strange that dirhash parameters has being changed and 
> > > > removed
> > > > without any mention...
> > > 
> > > It was not (this is on -current amd64):
> > > vfs.ffs.dirhash_dirsize=2560
> > > vfs.ffs.dirhash_maxmem=5242880
> > > vfs.ffs.dirhash_mem=4832510
> > > 
> > > Are you sure your kernel and userland are in sync?
> > 
> > Well, I followed the prescribed procedure (I'm using OpenBSD since... about
> > 20 years).
> > 
> > In EVERY machine upgraded to 7.5 now I have something like this:
> > 
> > Elrond:/home/giannici$ sysctl vfs.ffs
> > 
> > 
> > 
> > vfs.ffs.dirhash_maxmem=2560
> > vfs.ffs.dirhash_mem=5242880
> > 
> > Elrond:/home/giannici$ uname -a
> > 
> > 
> > 
> > OpenBSD Elrond.neomedia.it 7.5 GENERIC.MP#82 amd64
> > 
> > 
> > So, I'm the only one?
> > 
> > Thanks.
> > 
> 
> I suspect 
> 
> In 
> https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/ufs/ffs/ffs_exatern.h.diff?r1=1.45&r2=1.46&f=h
> 
> The max_softdeps entry in ffs_extern.h should have been replace by a
> { 0, 0 }
> 
> instead of being removed.
> 
>   -Otto
> 

Yes, that fixes it for me:

$ sysctl vfs.ffs
vfs.ffs.dirhash_dirsize=2560
vfs.ffs.dirhash_maxmem=5242880
vfs.ffs.dirhash_mem=767359
$



Re: Upgraded to 7.5: vfs.ffs.dirhash_dirsize no longer exists and large directory ere veeery slow

2024-04-11 Thread Otto Moerbeek
On Thu, Apr 11, 2024 at 05:08:01PM +0200, Federico Giannici wrote:

> On 4/11/24 16:15, Claudio Jeker wrote:
> > On Thu, Apr 11, 2024 at 03:36:29PM +0200, Federico Giannici wrote:
> > > On 4/11/24 14:12, Nick Holland wrote:
> > > > On 4/11/24 05:47, Federico Giannici wrote:
> > > > > We have a server with A LOT of files in some directories (an email
> > > > > server in maildir format).
> > > > > 
> > > > > Since we upgraded from OpenBSD amd64 7.3 to 7.5 (passing through 7.4) 
> > > > > it
> > > > > became very very very slow to access these large directories!
> > > > ,,,
> > > > You may be being bitten by the removal of softdeps (soft updates)
> > > > in 7.4 more than the availability of a knob to twist.  This was a
> > > > huge hit for some things -- I had one backup job go from a couple
> > > > hours to eight or so hours.  However, it turned out that increase
> > > > in time has not inconvenienced me at all, and some random lockups
> > > > related to softdeps have gone away.  Overall, win for me (the
> > > > fscks after a lockup took hours, too, not to mention all the time
> > > > and effort spent replacing part after part assuming it was a HW
> > > > issue).
> > > > 
> > > > As I understand it...there were known (known unknown?) bugs in the
> > > > softdep code, the code was ugly, and it made it difficult to
> > > > actually improve the code.
> > > 
> > > No, we knew that softdeps were being deprecated and we removed from
> > > everywhere some time ago. It must be something else.
> > > 
> > > Anyway, it's strange that dirhash parameters has being changed and removed
> > > without any mention...
> > 
> > It was not (this is on -current amd64):
> > vfs.ffs.dirhash_dirsize=2560
> > vfs.ffs.dirhash_maxmem=5242880
> > vfs.ffs.dirhash_mem=4832510
> > 
> > Are you sure your kernel and userland are in sync?
> 
> Well, I followed the prescribed procedure (I'm using OpenBSD since... about
> 20 years).
> 
> In EVERY machine upgraded to 7.5 now I have something like this:
> 
> Elrond:/home/giannici$ sysctl vfs.ffs
> 
> 
> 
> vfs.ffs.dirhash_maxmem=2560
> vfs.ffs.dirhash_mem=5242880
> 
> Elrond:/home/giannici$ uname -a
> 
> 
> 
> OpenBSD Elrond.neomedia.it 7.5 GENERIC.MP#82 amd64
> 
> 
> So, I'm the only one?
> 
> Thanks.
> 

I suspect 

In 
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/ufs/ffs/ffs_exatern.h.diff?r1=1.45&r2=1.46&f=h

The max_softdeps entry in ffs_extern.h should have been replace by a
{ 0, 0 }

instead of being removed.

-Otto



Re: Upgraded to 7.5: vfs.ffs.dirhash_dirsize no longer exists and large directory ere veeery slow

2024-04-11 Thread Otto Moerbeek
On Thu, Apr 11, 2024 at 04:15:19PM +0200, Claudio Jeker wrote:

> On Thu, Apr 11, 2024 at 03:36:29PM +0200, Federico Giannici wrote:
> > On 4/11/24 14:12, Nick Holland wrote:
> > > On 4/11/24 05:47, Federico Giannici wrote:
> > > > We have a server with A LOT of files in some directories (an email
> > > > server in maildir format).
> > > > 
> > > > Since we upgraded from OpenBSD amd64 7.3 to 7.5 (passing through 7.4) it
> > > > became very very very slow to access these large directories!
> > > ,,,
> > > You may be being bitten by the removal of softdeps (soft updates)
> > > in 7.4 more than the availability of a knob to twist.  This was a
> > > huge hit for some things -- I had one backup job go from a couple
> > > hours to eight or so hours.  However, it turned out that increase
> > > in time has not inconvenienced me at all, and some random lockups
> > > related to softdeps have gone away.  Overall, win for me (the
> > > fscks after a lockup took hours, too, not to mention all the time
> > > and effort spent replacing part after part assuming it was a HW
> > > issue).
> > > 
> > > As I understand it...there were known (known unknown?) bugs in the
> > > softdep code, the code was ugly, and it made it difficult to
> > > actually improve the code.
> > 
> > No, we knew that softdeps were being deprecated and we removed from
> > everywhere some time ago. It must be something else.
> > 
> > Anyway, it's strange that dirhash parameters has being changed and removed
> > without any mention...
> 
> It was not (this is on -current amd64):
> vfs.ffs.dirhash_dirsize=2560
> vfs.ffs.dirhash_maxmem=5242880
> vfs.ffs.dirhash_mem=4832510
> 
> Are you sure your kernel and userland are in sync?
> -- 
> :wq Claudio
> 

Strange, on a very recent snap:

$ sysctl | grep ffs.d   
vfs.ffs.dirhash_maxmem=2560
vfs.ffs.dirhash_mem=5242880
$
-Otto



Re: newfs fast, but newfs_msdos and newfs_ext2fs very slow

2024-04-10 Thread Otto Moerbeek
On Wed, Apr 10, 2024 at 08:31:26AM -, Stuart Henderson wrote:

> On 2024-04-09, Stanislav Syekirin 
>  wrote:
> > Hi,
> >
> > I'm trying to figure out the best way to format a USB stick as FAT32. 
> > This is what I've tried:
> >
> > $ time doas newfs_msdos /dev/rsd1c
> > /dev/rsd1c: 60007944 sectors in 7500993 FAT32 clusters (4096 
> > bytes/cluster)
> > bps=512 spc=8 res=32 nft=2 mid=0xf0 spt=63 hds=255 hid=0 bsec=60125184 
> > bspf=58602 rdcl=2 infs=1 bkbs=2
> > 20m08.34s real  0m00.35s user   0m12.81s system
> >
> > As you can see, it takes many minutes, and the elapsed time is much 
> > larger than the CPU time. Looking at top while the command runs shows 
> > that newfs_msdos has PRI -5, its CPU usage fluctuates around 0.5%, 
> > STATE is mostly "sleep" with WAIT being "physio".
> >
> > The same happens if I call newfs_ext2fs -I.
> >
> > For comparison, `newfs /dev/rsd1c` is almost instantaneous: 0m00.88s 
> > real 0m00.06s user 0m00.16s system. It doesn't work if the disk is 
> 
> IIUC newfs_msdos has to wrote a lot more than FFS2 newfs.
> And writes to USB drives are not particularly quick on OpenBSD.
> 
> > already formatted as FAT32, though: I have to call `fdisk -e sd1`, and 
> > reinit, otherwise I get a "can't rewrite disk label" error; I'm not 
> > sure why newfs cares and newfs_msdos doesn't, maybe I'm doing it wrong 
> > somehow.
> 
> sd1c shouldn't be used for filesystems. It is a special device node for
> "the entire disk". See disklabel(8). For a single filesystem on a drive,
> use either a BSD disklabel with an 'a' partition, or a DOS/GPT partition
> (whuch you can setup with fdisk) and the 'spoofed' partition letter
> (/dev/sd1i for the first one).
> 
> > How can I speed the creation of a FAT32 or Ext2 file system up?
> 
> Maybe increasing block size will help. If not, I don't think there's
> really much you can do. There's no "quick format" option for newfs_msdos
> lile there is on Windows.
> 
> 
> -- 
> Please keep replies on the mailing list.
> 

On a side note: when using newfs with ffs1 it does a full write of all
the (empty) inode tables and is also much slower than ffs2. In the
ffs2 case (default since quite a while) a lazy approach is used; only
the superblocks and a small set of inodes is initialized, the rest is
done while the fs is being used and there is need for more inodes.

-Otto



Re: Ping blocked by firewall

2024-04-09 Thread Otto Moerbeek
On Tue, Apr 09, 2024 at 10:52:45AM +0200, Karel Lucas wrote:

> I defined the table as stated in your book (3rd edition, page 42). However,
> that gives an error message. In the lines with that table: macro 'martians'
> not defined. Moreover, I now also have a Syntax error in lines 38, 39 and
> 46, causing the pf lines not to be loaded.

How abot showing what you did, showing the actual error messages so
people here can actually help you? Just saying "it does not work" does
not get you anywhere.

-Otto
> 
> Op 09-04-2024 om 08:53 schreef Peter N. M. Hansteen:
> > On Tue, Apr 09, 2024 at 08:39:08AM +0200, Karel Lucas wrote:
> > > Hi all,
> > > 
> > > For the first time I tested my new firewall with ping, and it is blocked. 
> > > I
> > > don't know what the reason is, you can find the information below. I have 
> > > a
> > > network with only regular clients, so no servers. I'm still using OpenBSD
> > > V7.4, and will upgrade once the firewall is up and running so I can test 
> > > the
> > > upgrade process.
> > Upgrading to 7.5 will not affect this particular problem I think.
> > 
> > Still low on caffeine I spot two likely factors - your $localnet range 
> > overlaps
> > with one of the ranges in $martians (which I anyway would recommend 
> > converting
> > into a table), and your block referencing $martians comes after the pass 
> > rules
> > that would have let icmp through. With no previous matching quick, last 
> > match
> > applies.
> > 
> > - Peter
> > 
> 



Re: need help to access my machine after upgrade -- system immediately logs me out

2024-04-02 Thread Otto Moerbeek
On Wed, Apr 03, 2024 at 12:45:33AM +0530, Sandeep Gupta wrote:

> Thank you for all the inputs. This is so useful. I am able to at least
> access the file system and rescue the data.
> However, I'm not able to restore the system yet.  The command "pkg_add -u"
> runs into "out of memory error".
> ulimit -a shows decent memory:
> memory(kbytes) 11872836.

you want to increase the data limit, ulimit -d

-Otto

> 
> On Tue, Apr 2, 2024 at 5:04 PM Stuart Henderson 
> wrote:
> 
> > On 2024-04-01, Sandeep Gupta  wrote:
> > >
> > > However when i tried to log from the console -- the login message shows
> > but
> > > the system logs me out immediately.
> > > On the desktop gui too, with only root I was able to login. But running
> > > xterm from the fvwm menu fails.
> > > I am a bit clueless as to how to gain access to the system.
> >
> > Try this:
> >
> > Boot into single-user mode ("boot -s" at the boot loader prompt)
> > fsck -p
> > mount -a -t nonfs
> >
> > Hopefully that will get you access to the system. You can try looking at
> > system logs to see if that gives any clues about the problem. TERM won't
> > be set so you may want to use e.g. "TERM=xterm less /var/log/messages"
> > etc. $HOME/.xsession-errors might give some clues too.
> >
> > If you think that updating packages might help then 'sh /etc/netstart'
> > to get working net and proceed with pkg_add -u as usual.
> >
> >
> >



Re: unbound signature expired

2024-03-21 Thread Otto Moerbeek
On Mon, Mar 18, 2024 at 08:04:38PM +0100, Evan Sherwood wrote:

> > Wild guess, your time is off.
> 
> Huh, I think you're right. `date` shows me 7 hours ahead of my timezone. 
> 
> I restarted ntpd and I see no errors in /var/log/daemon, but the time is
> still off. I should be 1200 PDT but it's showing me as 1900 PDT (not
> UTC).
> 
> What do I do to fix this? Pretty sure I had set my timezone to
> America/Los_Angeles when I installed OpenBSD.
> 

ntpd will not jump the clock backwards.  You need to do a manual set.

-Otto



Re: disklabel and df -h don't show same size

2024-03-03 Thread Otto Moerbeek
On Sun, Mar 03, 2024 at 12:14:14PM -, beecdadd...@danwin1210.de wrote:

> On Sun, March 3, 2024 12:07 pm, Otto Moerbeek wrote:
> > On Sun, Mar 03, 2024 at 12:01:12PM -, beecdadd...@danwin1210.de
> > wrote:
> >
> >
> >> oh okay reserved for root? I ran those commands as root, or you mean
> >> something else? I didn't know overhead was that big.. so this is okay,
> >> then? thanks for very fast reply
> >
> > 3.5G meta data overhead is less than 1.5% of your partition. Not that
> > high, I'd say.
> 
> 235-223 is 8G, not 3.5G?

Your 238.5 partition maps to a filesystem of size 235G, of which 5% is
reserved (but usable by root).

> 
> > Only root processes can write crossing the reserved space limit. The
> > disk will than show a Capacity number larger than 100%.
> 
> so root process, not root user? ok

Any proces has a uid as well.

> 
> > Non-root proceses will see failed writes.
> >
> >
> > You can change that 5% by using tunefs, or when doing newfs from the
> > start).
> >
> > -Otto
> 
> newfs from the start? I did newfs from the start?
> https://www.openbsd.org/faq/faq14.html#softraidcrypto
> is this not what you mean by newfs from the start?

When doing newfs, you can specify a non-default reserved space by
supplying a -m parameter. For example, newfs -m 0 ... will not reserve
any space for root, and the FS Size will be equal to Available (if the
FS is empty).

The reserved space can *also* be changed after FS creatiomn, using
tunefs(8).

-Otto

> 
> >
> >>
> >> On Sun, March 3, 2024 11:57 am, Otto Moerbeek wrote:
> >>
> >>> On Sun, Mar 03, 2024 at 11:48:01AM -, beecdadd...@danwin1210.de
> >>> wrote:
> >>>
> >>>
> >>>
> >>>>
> >>>> disklabel -h sd3 shows this
> >>>>
> >>>> # /dev/rsd3c:
> >>>> type: SCSI
> >>>> disk: SCSI disk
> >>>> label: SR CRYPTO
> >>>> duid: some-number
> >>>> flags:
> >>>> bytes/sector: 512
> >>>> sectors/track: 63
> >>>> tracks/cylinder: 255
> >>>> sectors/cylinder: 16065
> >>>> cylinders: 31130
> >>>> total sectors: 500117600 # total bytes: 238.5G boundstart: 64
> >>>> boundend: 500117600
> >>>>
> >>>>
> >>>>
> >>>> 16 partitions:
> >>>> #size   offset  fstype [fsize bsize   cpg]
> >>>> c:   238.5G0  unused
> >>>> i:   238.5G   64  4.2BSD   4096 32768 26062 #
> >>>> /mnt/extssd
> >>>>
> >>>>
> >>>>
> >>>> but df -h shows that sd3i is of size 235G but only 223G is
> >>>> available, and the Used space is 4.0k.. SSD is new and I followed
> >>>>
> >>>
> >>> A fileystem has meta data overhead. That space is not avalailable for
> >>>  user files. Also, by default 5% of available space is reserved for
> >>> root only. That fraction is represented in available space. See
> >>> newfs(8).
> >>>
> >>> -Otto
> >>>
> >>>
> >>>
> >>
> >>
> >
> 
> 



Re: disklabel and df -h don't show same size

2024-03-03 Thread Otto Moerbeek
On Sun, Mar 03, 2024 at 12:01:12PM -, beecdadd...@danwin1210.de wrote:

> oh okay
> reserved for root? I ran those commands as root, or you mean something
> else? I didn't know overhead was that big.. so this is okay, then?
> thanks for very fast reply

3.5G meta data overhead is less than 1.5% of your partition. Not that
high, I'd say.

Only root processes can write crossing the reserved space limit. The
disk will than show a Capacity number larger than 100%.

Non-root proceses will see failed writes.

You can change that 5% by using tunefs, or when doing newfs from the
start).

-Otto

> 
> On Sun, March 3, 2024 11:57 am, Otto Moerbeek wrote:
> > On Sun, Mar 03, 2024 at 11:48:01AM -, beecdadd...@danwin1210.de
> > wrote:
> >
> >
> >>
> >> disklabel -h sd3 shows this
> >>
> >> # /dev/rsd3c:
> >> type: SCSI
> >> disk: SCSI disk
> >> label: SR CRYPTO
> >> duid: some-number
> >> flags:
> >> bytes/sector: 512
> >> sectors/track: 63
> >> tracks/cylinder: 255
> >> sectors/cylinder: 16065
> >> cylinders: 31130
> >> total sectors: 500117600 # total bytes: 238.5G boundstart: 64
> >> boundend: 500117600
> >>
> >>
> >> 16 partitions:
> >> #size   offset  fstype [fsize bsize   cpg]
> >> c:   238.5G0  unused
> >> i:   238.5G   64  4.2BSD   4096 32768 26062 #
> >> /mnt/extssd
> >>
> >>
> >> but df -h shows that sd3i is of size 235G but only 223G is available,
> >> and the Used space is 4.0k.. SSD is new and I followed
> >>
> >
> > A fileystem has meta data overhead. That space is not avalailable for
> > user files. Also, by default 5% of available space is reserved for root
> > only. That fraction is represented in available space. See newfs(8).
> >
> > -Otto
> >
> >
> 
> 



Re: disklabel and df -h don't show same size

2024-03-03 Thread Otto Moerbeek
On Sun, Mar 03, 2024 at 11:48:01AM -, beecdadd...@danwin1210.de wrote:

> 
> disklabel -h sd3 shows this
> 
> # /dev/rsd3c:
> type: SCSI
> disk: SCSI disk
> label: SR CRYPTO
> duid: some-number
> flags:
> bytes/sector: 512
> sectors/track: 63
> tracks/cylinder: 255
> sectors/cylinder: 16065
> cylinders: 31130
> total sectors: 500117600 # total bytes: 238.5G
> boundstart: 64
> boundend: 500117600
> 
> 16 partitions:
> #size   offset  fstype [fsize bsize   cpg]
>   c:   238.5G0  unused
>   i:   238.5G   64  4.2BSD   4096 32768 26062 #
> /mnt/extssd
> 
> but df -h shows that sd3i is of size 235G but only 223G is available, and
> the Used space is 4.0k.. SSD is new and I followed
> 

A fileystem has meta data overhead. That space is not avalailable for
user files. Also, by default 5% of available space is reserved for
root only. That fraction is represented in available space. See
newfs(8).

-Otto



Re: mount not working as expected? and what are my default bioctl rounds?

2024-03-03 Thread Otto Moerbeek
On Sun, Mar 03, 2024 at 10:47:31AM -, beecdadd...@danwin1210.de wrote:

> hi list
> I want to know how many rounds my computer defaults to for bioctl -r, so I
> can change it and know how stronger it is can you help me?
> 
> after reading mount manual about DUID I realized that it is not working
> for me as expected
> in /etc/fstab I have the same DUID I got from disklabel of that same
> crypto volume (sd3), and when I do mount sd3i, it goes to look at fstab
> and should find that same DUID.i entry, but it gives me this
> mount: can't find fstab entry for sd3i.
> 
> the fstab line is this
> DUID-of-sd3.i /mnt/extssd ffs rw,noatime,noexec,nodev,nosuid 0 0

When you have a duid entry in fstab, you should refer to is by duid.

> 
> the real RAID non-crypto volume of external ssd is sd2, as said crypto
> volume gets attached as sd3
> 
> and on topic of fstab, I couldn't find what the last two '0 0' are called,
> I remember linux has had it in manual in past so I know they say if system
> can boot without those drives or something like that

You did not look very hard:

man fstab: 
...
A line has the following format:

   fs_spec fs_file fs_vfstype fs_mntops fs_freq fs_passno
...



Re: Not getting any reply, are bug report fixed?

2024-02-18 Thread Otto Moerbeek
On Sun, Feb 18, 2024 at 05:13:23PM +0700, Discord is hell wrote:

> The title says all, although it is somewhat offensive. I'm not
> going to disregard OpenBSD developers' efforts.
> 
> I saw many bug report sent to b...@openbsd.org but get
> no reply. I saw some bug are silently fixed (not sure fixed or
> not). I have a question: I have to watch cvs commits to know
> if a bug is fixed?
> 
> The developers never respond to bug report unless they
> need more detail or confirm that is not a bug?
> 
> Thanks
> 

It depends. Not every developer works in the same way and some have
very little time. Most of OpenBSD work is done by volunteers, people
work on it next to their regular job or other business. So some bugs
get fixed with feedback, some gey fixed silently, some get missed,
some are spotted but only worked on later to name a few examples. It's
just the way it is.

-Otto



Re: KeyTrap DNS vulnerability

2024-02-13 Thread Otto Moerbeek
On Wed, Feb 14, 2024 at 04:55:20AM +0100, b...@fea.st wrote:

> “A single packet can exhaust the processing 
> capacity of a vulnerable DNS server, effectively
> disabling the machine, by exploiting a 
> 20-plus-year-old design flaw in the DNSSEC
> specification.
> 
> https://www.theregister.com/2024/02/13/dnssec_vulnerability_internet/

To be clear, this does not mean DNSSEC is cryptographically broken.

The RFCs specifying the DNSSEC validation algorithm do not take into
account potential resource usage validating many potential signatures
so the implementations following the RFCs suffered from the same.

By constraining the amount of work (limiting the potential signatures
considered) while validating these issues are worked around.

-Otto



Re: ksh horizontal line scrolling

2024-02-08 Thread Otto Moerbeek
On Fri, Feb 09, 2024 at 01:17:06PM +1300, Jeremy Baxter wrote:

> Hi all, I'm trying to disable the horizontal line scrolling feature in ksh,
> enabled through `set -o vi' or `set -o emacs'. ksh(1) says this about it:
> 
> In these editing modes, if a line is longer than the screen width (see
> the COLUMNS parameter), a `>', `+', or `<' character is displayed in
> the last column indicating that there are more characters after, before
> and after, or before the current position, respectively.  The line is
> scrolled horizontally as necessary.
> 
> Is it possible to completely disable this feature at the moment? Setting
> COLUMNS to a large number "disables" it for the most part but brings in
> other weird behaviours like massive gaps between lines when pressing
> ctrl-u and random newlines showing up when scrolling through history.
> 
>  -Jeremy
> 

Disable both emacs and vi mode:

$ set +o emacs +o vi

-Otto




Re: socket core

2024-01-15 Thread Otto Moerbeek
On Tue, Jan 16, 2024 at 08:16:38AM +0100, Janne Johansson wrote:

> Den tis 16 jan. 2024 kl 01:16 skrev Gustavo Rios :
> > Hi folks.
> > I have a simple question :  How many cores does OBSD support ?
> 
> amd64 says
> 
> #define MAXCPUS 64 /* bitmask */
> 
> but different arches have different limits.
> 
> i386 has 32, ppc64 has 48, sparc64 has 256, HP/PA has 4 and so on.
> 
> /sys/arch//include/cpu.h
> is where it is set.
> 
> For amd64, I believe the limit is set so that each cpu can have a bit
> in a uint64 in various structs used to keep track on the cores without
> using far larger and more cpu intensive lists or arrays.
> 
> -- 
> May the most significant bit of your life be positive.


But do note that OpenBSD is not great in using many cores, expect it
to not scale in a linear way. It's best to make decisison on actual
measurments.

-Otto



Re: time keeping fallback mechanics during reboot on octeon

2024-01-14 Thread Otto Moerbeek
On Sun, Jan 14, 2024 at 09:32:10AM +0100, Alexander Hall wrote:

> I don't have mine (EdgeRouter lite) running anymore, but IIRC, I had a cron 
> job poking the root fs to"resolve" this.
> 
> Sth like "mkdir /bump && rmdir /bump && sync".

I have no idea how this would solve the "boot sets last modified time
of fs in superblock wrongly" issue.

-Otto
> 
> /Alexander
> 
> On January 12, 2024 2:35:47 PM GMT+01:00, Christian Gut  
> wrote:
> >Hi,
> >
> >Could somebody point me to documentation or tell me where OpenBSD gets the 
> >time from, when the system has no RTC and ntpd is not working?
> >
> >I am using an EdgeRouter / octeon and at every reboot, the date/time gets 
> >reset to the exact same date.
> >
> >I tried to read the source code of boot(9) and inittodr(9). I can see, that 
> >there seems to be a fallback to some timestamp that comes from the 
> >filesystem. Maybe when the root filesystem is mounted as of ffs_mountroot() 
> >for example. But my understanding did not go so far to identify from which 
> >file, directory, superblock or other filesystem metadata the information 
> >really comes from.
> >
> >It seems to me, that either my system is broken or something on octeon does 
> >not work correctly for this fallback to happen correctly.
> >
> >Kind Regards,
> >Christian
> >
> 



Re: time keeping fallback mechanics during reboot on octeon

2024-01-13 Thread Otto Moerbeek
On Sat, Jan 13, 2024 at 11:47:44AM +0100, Christian Gut wrote:

> 
> 
> > On 13. Jan 2024, at 10:03, Christian Gut  wrote:
> > 
> > 
> > 
> >> On 13. Jan 2024, at 00:58, Theo de Raadt  wrote:
> >> 
> >> I suspect this is due to how powerpc64 and octeon boot.  Their bootblocks 
> >> are
> >> a special kernel called BOOT which mounts the ffs filesystem diretly.  I 
> >> suspect
> >> during the transition to loading GENERIC.MP something wrong happens with 
> >> the
> >> on-disk time information, which misleads the next kernel.
> > 
> > Any thing I could do my self or provide information to improve that?
> > I think I have one other of these machines where it seems to behave 
> > differently.
> 
> I might have found the reason:
> 
> octeon seems to boot that special “BOOT” kernel, which has a ram disk. Inside 
> that small boot process in 
> 
> src/sys/arch/octeon/stand/rdboot/disk.c
>disk_init() calls disk_proberoot()
> 
> all possible filesystems are iterated over and are mounted to /mnt. This is 
> done to find the root filesystem. I would assume inside that boot kernel, the 
> time had been set to the ramdisk time. As it mounts the root filesystem 
> temporarily, the time of that filesystem gets set back to the time that had 
> been set from the ramdisk kernel.
> 
> But that mount uses MNT_RDONLY?
> 
> A lot of assumptions, maybe you can confirm with deeper understanding.

In that file there's also disk_open() that does an r/w mount.  That
mount is used and later unmounted buy disk_close() (as the code in
kexec() shows). So the superblock gets updated with the ramdisk root
time, assuming the rest of your analysis is correct.

-Otto



Re: time keeping fallback mechanics during reboot on octeon

2024-01-13 Thread Otto Moerbeek
On Sat, Jan 13, 2024 at 10:03:20AM +0100, Christian Gut wrote:

> 
> 
> > On 13. Jan 2024, at 00:58, Theo de Raadt  wrote:
> > 
> > I suspect this is due to how powerpc64 and octeon boot.  Their bootblocks 
> > are
> > a special kernel called BOOT which mounts the ffs filesystem diretly.  I 
> > suspect
> > during the transition to loading GENERIC.MP something wrong happens with the
> > on-disk time information, which misleads the next kernel.
> 
> Any thing I could do my self or provide information to improve that?
> I think I have one other of these machines where it seems to behave 
> differently.
> 
> That special kernel resides on a fat32 partition, as far as I know. Maybe I 
> would need to “touch” or update that filesystem on shutdown? I did try to 
> mount, change and unmount it. But I had no luck.
> 
> Kind Regards,
> 
> Christian
> 

I would start adding printfs to the ffs_mountroot(), inittodr() and
ffs_unmount() functions to show what arguments they receive, what
timestamp they read or write and what decicisons they make. Building
and running the new boot kernel and then the regular kernel then might
give a more concrete clue on what's going on.

-Otto



Re: time keeping fallback mechanics during reboot on octeon

2024-01-12 Thread Otto Moerbeek
On Fri, Jan 12, 2024 at 07:15:43PM +0100, Christian Weisgerber wrote:

> Otto Moerbeek:
> 
> > http://man.openbsd.org/octrtc seems to suggest EdgeRouter does not have
> > an RTC. A dmesg should give more certainty.
> 
> I think the original poster is aware of this.
> 
> If I understand correctly, he expects that on reboot the system
> clock is restored to the last value from before the reboot (so only
> a minute or so is lost), and that this value is transported by a
> time stamp on the root filesystem.  Apparently that doesn't happen.

Which is strange as the code to fall back to fs time is MI.
That's why I asked for a dmesg, it might give a clue of what is going on.

-Otto



Re: time keeping fallback mechanics during reboot on octeon

2024-01-12 Thread Otto Moerbeek
On Fri, Jan 12, 2024 at 04:47:06PM +0100, Christian Gut wrote:

> Hi Otto,
> 
> 
> > On 12. Jan 2024, at 15:52, Otto Moerbeek  wrote:
> > 
> > On Fri, Jan 12, 2024 at 02:35:47PM +0100, Christian Gut wrote:
> > 
> >> Hi,
> >> 
> >> Could somebody point me to documentation or tell me where OpenBSD gets the 
> >> time from, when the system has no RTC and ntpd is not working?
> >> 
> >> I am using an EdgeRouter / octeon and at every reboot, the date/time gets 
> >> reset to the exact same date.
> >> 
> >> I tried to read the source code of boot(9) and inittodr(9). I can see, 
> >> that there seems to be a fallback to some timestamp that comes from the 
> >> filesystem. Maybe when the root filesystem is mounted as of 
> >> ffs_mountroot() for example. But my understanding did not go so far to 
> >> identify from which file, directory, superblock or other filesystem 
> >> metadata the information really comes from.
> >> 
> >> It seems to me, that either my system is broken or something on octeon 
> >> does not work correctly for this fallback to happen correctly.
> >> 
> >> Kind Regards,
> >> Christian
> >> 
> > 
> > When there is no RTC or reading it fails, the "last written" timestamp
> > of the root filesystem is used. 
> 
> Somehow this does not seem to work on that system. 
> 
> > What are you observing exactly? You did not tell any details.  How
> > does ntpd fail? Please show some logs (/var/log/daemon should have some
> > lines).
> 
> I know why ntpd does not work. The system operates in a very constrained 
> environment. No ntp servers reachable, no https reachable.
> 
> I am okay if the time stays roughly the same during reboot. Like the same 
> day, even only some days off is okay. But on that 7.4 system it always gets 
> reset to Oct 9, 2023.
> 
> I checked the root filesystem. It is clean after reboot.
> When the system runs and time has been corrected the following output 
> suggests, that fallback from the filesystem should work correctly, but it 
> doesnt:
> 
> # file -s /dev/rsd0a

> /dev/rsd0a: Unix Fast File system [v2] (big-endian) last mounted on /, last 
> written at Fri Jan 12 16:45:42 2024, clean flag 0, readonly flag 0, number of 
> blocks 441848, number of data blocks 425527, number of cylinder groups 5, 
> block size 16384,
 fragment size 2048, average file size 16384, average 
> number of files in dir 64, pending blocks to free 0, pending inodes to free 
> 0, system-wide uuid 0, minimum percentage of free blocks 5, TIME optimization
> 
> Anything I could check?
> Maybe it has to do with the way Octeon boots?
> 
> Kind Regards,
> Christian

http://man.openbsd.org/octrtc seems to suggest EdgeRouter does not have
an RTC. A dmesg should give more certainty.

If you have ann RTC that is read but gives a wrong value you should see
a consistency check messages from inittodr().

So can you show the dmesg? It contains the relevant kernel messages at
the end and allow us to see if you actually have an RTC.

-Otto



Re: time keeping fallback mechanics during reboot on octeon

2024-01-12 Thread Otto Moerbeek
On Fri, Jan 12, 2024 at 02:35:47PM +0100, Christian Gut wrote:

> Hi,
> 
> Could somebody point me to documentation or tell me where OpenBSD gets the 
> time from, when the system has no RTC and ntpd is not working?
> 
> I am using an EdgeRouter / octeon and at every reboot, the date/time gets 
> reset to the exact same date.
> 
> I tried to read the source code of boot(9) and inittodr(9). I can see, that 
> there seems to be a fallback to some timestamp that comes from the 
> filesystem. Maybe when the root filesystem is mounted as of ffs_mountroot() 
> for example. But my understanding did not go so far to identify from which 
> file, directory, superblock or other filesystem metadata the information 
> really comes from.
> 
> It seems to me, that either my system is broken or something on octeon does 
> not work correctly for this fallback to happen correctly.
> 
> Kind Regards,
> Christian
> 

When there is no RTC or reading it fails, the "last written" timestamp
of the root filesystem is used. 

What are you observing exactly? You did not tell any details.  How
does ntpd fail? Please show some logs (/var/log/daemon should have some
lines).

-Otto



Re: Partition completely wiped out, why?

2024-01-09 Thread Otto Moerbeek
On Wed, Jan 10, 2024 at 12:21:12AM +0100, Jonas Bechtel wrote:

> 
> 
> Dear "misc" list attendees,
> 
> maybe someone of you has an idea what happened.
> 
> Ten years ago I installed OpenBSD 5.[?] which included setting up a
> small partition of 2 GB, including the full OS with kernel, programs,
> web-related data, etc.. Occasionally the partition was full so I had to
> gzip some logs. Please don't mind that I didn't update the OS - I must
> have been very lucky that nothing serious happened, at least I didn't
> notice anything suspicious.
> 
> What also may be noted is that the ufs magic 0x00011954 (or,
> 1954 0001, in hexdump switched 2-bytes) was present at position 0x255c
> and 0x455c and several times at larger offsets. (very helpful, this
> post: https://bugzilla.kernel.org/show_bug.cgi?id=197733; looked
> similar to mine few days ago)
> 
> This weekend I installed OpenBSD 7.4. (Btw I dislike that the fdisk
> "quit" command writes changes, just a side note. Finally I
> reconstructed the partition table (fresh MBR pointing to the still
> intact disklabel) with the help of GNU/Linux tools i'm familiar with) I
> assigned a mount point to the old partition, "/oldbsd5", which worked
> on first boot. I just saw the usual files usr, mnt, ... when invoking
> "ls /oldbsd5", assumed it was working then. Automatic fstab entry was 
> 
> [hash].j /oldbsd5 ffs rw,nodev,nosuid 1 2
> 
> Then I deleted "rw," from fstab and maybe rebooted the system once or
> twice. I'm pretty sure that I never made rm -rf on that directory. Then
> I found out (with df -h) that the partition is empty. Really actually
> empty, so theres no hidden file, no file, no lost+found, just nothing.
> 
> The data, however, is still scattered on disk. I can see the lines of
> known text files with grep. I also can see the signature at 0x455c, but
> not any more at 0x255c. fsck doesn't find anything problematic.
> 
> 
> I have no clue. a) What happened?, b) How easy would it be to get the
> data back? (not too important, not my first data loss, but annoying,
> anyway)
> 
> 
> 
> Best Regards
>  Jonas

Is the disk mounted?  I seem to remember a fstab line without rw or ro
is not mounted.

-Otto



Re: mountd

2024-01-09 Thread Otto Moerbeek
On Tue, Jan 09, 2024 at 10:13:56AM +0300, 4 wrote:

> >> i'm quoting the man page for mountd:
> >>  The -n flag historically allowed clients to use non-reserved ports 
> >> when
> >>  communicating with mountd.  In OpenBSD, a reserved port is always 
> >> used.
> >> "reserved port". "always".. however the port is different each time. how 
> >> to deal with this?
> >> 
> 
> > resreved means that the port number is below 1024. The RPC system,
> > (which is used to implement NFS) iuses portmapper to determine which
> > service runs on which port. What problem are you trying to solve?
> 
> > -Otto
> i'm trying to solve the problem of which port need to open on the pf. the 
> variant of processing rpcinfo output with script and then putting a rules 
> into an anchor is not very pretty. especially considering that this is not 
> enough, and i still need to repeat this action by cron. this variant works, 
> but it's not even close to how it should work %\ why i should solve such the 
> task at a time when humanity is flying to conquer Mars?
> 

These kind of off-topic remarks won't help you getting answers,

-Otto



Re: mountd

2024-01-08 Thread Otto Moerbeek
On Tue, Jan 09, 2024 at 04:16:43AM +0300, 4 wrote:

> i'm quoting the man page for mountd:
>  The -n flag historically allowed clients to use non-reserved ports when
>  communicating with mountd.  In OpenBSD, a reserved port is always used.
> "reserved port". "always".. however the port is different each time. how to 
> deal with this?
> 

resreved means that the port number is below 1024. The RPC system,
(which is used to implement NFS) iuses portmapper to determine which
service runs on which port. What problem are you trying to solve?

-Otto



Re: ignore dns dhcpleased

2024-01-03 Thread Otto Moerbeek
On Wed, Jan 03, 2024 at 12:15:04PM +0100, Peter Wens wrote:

> Hi,
> 
> I noticed that ignoring nameservers from leases only works
> on IPv4 addresses.
> 
> in /etc/dhcpleased.conf
> 
> interface vio0 {
>   ignore dns
> }
> 
> resolvd still adds a IPv6 nameserver
> 
> nameserver 2001:19f0:300:1704::6 # resolvd: vio0
> 
> Is this intentional?
> 
> 
> Best regards,
> 
> Peter
> 

This very likely happens via slaacd, as v6 route proposals can
contais DNS resolver info. AFAIK, there is no way to tell slaacd to
not send DNS entries to resolvd, so you should try to tell the device
sending the v6 route advertisements to stop include DNS info.

-Otto



Re: as cannot do endbr64 instructions (too old)

2024-01-03 Thread Otto Moerbeek
On Wed, Jan 03, 2024 at 08:50:43AM +0100, Lorenz (xha) wrote:

> On Tue, Jan 02, 2024 at 08:32:00PM -, Stuart Henderson wrote:
> > I can't say. Though I doubt there would much objection if it's clean and
> > not a copy of a GPLv3-licensed upstream commit.
> 
> what about this?
> 
> i am not sure about the situation on arm64. it looks like newer gnu
> assemblers don't like bti instructions unless explicitly enabled.
> llvm seems to be using hint #34 for compatibility.
> 
> is /usr/bin/as the GNU assembler on arm64 aswell?

There is no as(1) installed on arm64.

-Otto
> 
> Index: include/opcode/i386.h
> ===
> RCS file: /cvs/src/gnu/usr.bin/binutils-2.17/include/opcode/i386.h,v
> retrieving revision 1.11
> diff -C5 -r1.11 i386.h
> *** include/opcode/i386.h 9 Sep 2018 21:59:43 -   1.11
> --- include/opcode/i386.h 3 Jan 2024 07:35:49 -
> ***
> *** 1532,1541 
> --- 1532,1545 
>   
>   /* Intel PCID extension */
>   {"invpcid", 2, 0x660f3882, X, CpuNEW|CpuNo64, 
> Modrm|IgnoreSize|No_bSuf|No_wSuf|No_sSuf|No_qSuf|No_xSuf|NoRex64, { 
> BaseIndex|Disp8|Disp16|Disp32|Disp32S, Reg32 } },
>   {"invpcid", 2, 0x660f3882, X, CpuNEW|Cpu64, 
> Modrm|IgnoreSize|No_bSuf|No_wSuf|No_sSuf|No_qSuf|No_xSuf|NoRex64, { 
> BaseIndex|Disp8|Disp16|Disp32|Disp32S, Reg64 } },
>   
> + /* Intel Indirect Branch Tracking extensions */
> + {"endbr64", 0, 0xF30F1E, 0xFA, Cpu64, NoSuf|ImmExt, { 0, 0, 0 } },
> + {"endbr32", 0, 0xF30F1E, 0xFB, CpuNo64, NoSuf|ImmExt, { 0, 0, 0 } },
> + 
>   /* sentinel */
>   {NULL, 0, 0, 0, 0, 0, { 0, 0, 0} }
>   };
>   #undef X
>   #undef NoSuf
> 



Re: as cannot do endbr64 instructions (too old)

2024-01-02 Thread Otto Moerbeek
On Tue, Jan 02, 2024 at 08:56:55PM +1100, Alexis wrote:

> 
> "Lorenz (xha)"  writes:
> 
> > On Mon, Jan 01, 2024 at 08:47:07PM +1100, Alexis wrote:
> > > 
> > > "Lorenz (xha)"  writes:
> > > 
> > > > just out of couriosity, why is "as" in the base system if it > is
> > > > outdated and is updating it an option?
> > > 
> > > i presume it's due to subsequent versions being licensed under later
> > > versions of the GPL, but i'd be happy to be corrected on this point.
> > 
> > i couldn't find any discussions on why the later versions are not
> > acceptable in the base system. are there any?

WRT the GPL the policy boils down to:

- We do not want new software using GPL in our tree
- For existing software we only allow GPL2. For projects that switched
license like gcc, we stick at the latest GPL2 version and try to
replace the software.

> 
> There's a discussion about GPL software in base at
> https://www.openbsd.org/policy.html, although it doesn't mention GPL
> versions:
> 
> > The GNU Public License and licenses modeled on it impose the restriction
> > that source code must be distributed or made available for all works
> > that are derivatives of the GNU copyrighted code.
> > 
> > While this may superficially look like a noble strategy, it is a
> > condition that is typically unacceptable for commercial use of software.
> > So in practice, it usually ends up hindering free sharing and reuse of
> > code and ideas rather than encouraging it. As a consequence, no
> > additional software bound by the GPL terms will be considered for
> > inclusion into the OpenBSD base system.
> > 
> > For historical reasons, the OpenBSD base system still includes the
> > following GPL-licensed components: the GNU compiler collection (GCC)
> > with supporting binutils and libraries, GNU CVS, GNU texinfo, the
> > mkhybrid file system creation tool, and the readline library.
> > Replacement by equivalent, more freely licensed tools is a long-term
> > desideratum.
> 
> But, again, someone else will have to describe what's happening with 'as'
> specifically; i'm not an OpenBSD dev myself. My speculation about the GPL
> version potentially being involved comes from Apple not including versions
> of software whose license had been changed from GPL2 to GPL3 (such that e.g.
> versions of macOS prior to Catalina only included GNU Emacs 22).
> 
> 
> Alexis.

Dunno what haoppened to as(1) specifically.  But as we do not use
standalone as(1) for our own builds, it does not get a lot of
attention (in additional to the potential licensing issues).

-Otto





Re: as cannot do endbr64 instructions (too old)

2024-01-01 Thread Otto Moerbeek
On Mon, Jan 01, 2024 at 10:00:34AM +0100, Lorenz (xha) wrote:

> On Sun, Dec 31, 2023 at 03:39:14PM +0100, Otto Moerbeek wrote:
> > On Sun, Dec 31, 2023 at 04:51:14AM +0100, Lorenz (xha) wrote:
> > 
> > > hi misc@,
> > > 
> > > like the subject says, `as` in the base system cannot do endbr64
> > > instructions. should it be updated?
> > > 
> > > background: i am maintaining hare for openbsd and we always have
> > > to install "gas" from the "binutils" package because the normal one
> > > is too old. i'd be nice if we don't depend on any packages from
> > > ports and don't have some specific workarounds in hare just for
> > > openbsd because "as" is too old.
> > > 
> > > if updating "as" is not an option, is there a way to invoke the
> > > llvm assembler directly in the base system?
> > > 
> > > thanks.
> > > 
> > > - lorenz
> > > 
> > 
> > cc will assesmbly a .s or .S file.
> > 
> 
> it looks like cc cannot combine multiple assembly files into one. this
> is a simplified version of the command line:
> 
>   $(AS) -o example.o example_a.s example_b.s
> 
> it works when defining "AS = gas", but not when doing "AS = cc -c":
> 
>   "cc: error: cannot specify -o when generating multiple output files"
> 
> is there a way to do this with llvm?

Assemble the files individually and link them? Concat and assemble?

> 
> why is "as" so old?

-Otto



Re: as cannot do endbr64 instructions (too old)

2023-12-31 Thread Otto Moerbeek
On Sun, Dec 31, 2023 at 09:55:25AM -0700, Theo de Raadt wrote:

> That's curious.
> 
> We never invoke as directly these days.
> 
> It feels like an upstream llvm bug, and I say that because noone else has
> embraced BTI/IBT as much as we have, everyone else is still considering it
> a thing for specific applications or the future.

/usr/bin/as is stil GNU as (at least on amd64).

-Otto

> 
> Lorenz (xha)  wrote:
> 
> > hi misc@,
> > 
> > like the subject says, `as` in the base system cannot do endbr64
> > instructions. should it be updated?
> > 
> > background: i am maintaining hare for openbsd and we always have
> > to install "gas" from the "binutils" package because the normal one
> > is too old. i'd be nice if we don't depend on any packages from
> > ports and don't have some specific workarounds in hare just for
> > openbsd because "as" is too old.
> > 
> > if updating "as" is not an option, is there a way to invoke the
> > llvm assembler directly in the base system?
> > 
> > thanks.
> > 
> > - lorenz
> > 
> 



Re: Recovery binary from lost+found

2023-12-31 Thread Otto Moerbeek
On Sun, Dec 31, 2023 at 03:01:10PM +0100, Kirill A. Korinsky wrote:

> 
> > On 31. Dec 2023, at 11:02, Otto Moerbeek  wrote:
> > 
> > Amongst other things, fsck_ffs(8) looks for inodes not mentioned in
> > any directory, i.e. files that are orphans. fsck_ffs links those files
> > into the lost+found dir, using the inode number for a name.
> 
> 
> sounds like just remove it and forgot, isn't it?
> 
> > 
> > Try to figure the contents of the file, using e.g. file(1) or
> > hexdump(1). On success, just move the files to the right place with
> > the right name. Often you'll find that those files are not longer
> > useful, in that case  just remove them from lost+found.
> 
> 
> As was said before this is binary files:
> 
> island# file *
> #1866245: ELF 64-bit LSB shared object, x86-64, version 1
> #2021828: ELF 64-bit LSB shared object, x86-64, version 1
> island#
> 
> and it has quite different size:
> 
> island# ls -la
> total 7912
> -r--r--r--   1 root  bin3680832 Dec 31 00:30 #1866245
> -r--r--r--   1 root  bin 317600 Dec 31 00:30 #2021828
> drw--T   2 root  wheel  512 Dec 31 01:10 .
> drwxr-xr-x  16 root  wheel  512 Dec 31 01:27 ..
> island#
> 
> an attempt to run it leads to crash, yes I've tried move to bin.
> 
> --
> wbr, Kirill
> 

There are toos like objdump and readelf that can tell you more, but
just removing them is likely best. Object files can always be
re-created on an open-source system.

-Otto



Re: as cannot do endbr64 instructions (too old)

2023-12-31 Thread Otto Moerbeek
On Sun, Dec 31, 2023 at 04:51:14AM +0100, Lorenz (xha) wrote:

> hi misc@,
> 
> like the subject says, `as` in the base system cannot do endbr64
> instructions. should it be updated?
> 
> background: i am maintaining hare for openbsd and we always have
> to install "gas" from the "binutils" package because the normal one
> is too old. i'd be nice if we don't depend on any packages from
> ports and don't have some specific workarounds in hare just for
> openbsd because "as" is too old.
> 
> if updating "as" is not an option, is there a way to invoke the
> llvm assembler directly in the base system?
> 
> thanks.
> 
> - lorenz
> 

cc will assesmbly a .s or .S file.

-Otto



Re: Recovery binary from lost+found

2023-12-31 Thread Otto Moerbeek
On Sun, Dec 31, 2023 at 01:59:28AM +0100, Kirill A. Korinsky wrote:

> Greetings,
> 
> How can I recovery binary files from lost+found?
> 
> I have:
> island$ doas ls -l /usr/lost+found
> total 7904
> -r--r--r--  1 root  bin  3680832 Dec 31 00:30 #1866245
> -r--r--r--  1 root  bin   317600 Dec 31 00:30 #2021828
> island$
> 
> --
> wbr, Kirill
> 

Amongst other things, fsck_ffs(8) looks for inodes not mentioned in
any directory, i.e. files that are orphans. fsck_ffs links those files
into the lost+found dir, using the inode number for a name.

Try to figure the contents of the file, using e.g. file(1) or
hexdump(1). On success, just move the files to the right place with
the right name. Often you'll find that those files are not longer
useful, in that case  just remove them from lost+found.

-Otto



Re: self-hosted man.openbsd.org script?

2023-12-24 Thread Otto Moerbeek
On Sun, Dec 24, 2023 at 05:25:55AM -0800, Paul Pace wrote:

> I have this vague memory of reading someone who posted a script, IIRC, to
> convert the system's man pages to HTML, or similar, into somewhere under
> /var/www and the pages worked just like the highly useful man.openbsd.org,
> and not like the plain text pages that everyone always posts to their
> websites.
> 
> Does someone happen to know where that is?

My guess would be 'mandoc -T html' is the core utility used.

-Otto
> 
> On 12/23/23 11:16 AM, Nick Holland wrote:
> > On 12/19/23 15:38, Nick Holland wrote:
> > > Hello,
> > > 
> > > man.openbsd.org, cvsweb.openbsd.org, openbsd.cs.toronto.edu
> > > and obsdacvs.cs.toronto.edu will be unavailable for site
> > > maintenance starting Thursday, December 21 about 6:00am ET
> > > (UTC-5) and hopefully be back up and running by Saturday,
> > > December 23, 6:00am ET.
> > > 
> > > Sorry for any inconvenience.
> > > 
> > > Nick.
> > > 
> > 
> > Unfortunately, it seems there's a problem impacting our servers,
> > and everyone is celebrating the holiday.
> > 
> > So ... return of man.openbsd.org, cvsweb.openbsd.org and
> > the install and anoncvs mirrors will be delayed.
> > 
> > Nick.
> 



Re: ntpd not adjusting clock in vm

2023-12-17 Thread Otto Moerbeek
On Mon, Dec 18, 2023 at 02:02:47AM +, Chris Narkiewicz wrote:

> I'm running OpenBSD 7.4 in qemu VM on my laptop. After hibernation,
> vm clock is delayed.
> 
> ntpd works in background, but it fails to adjust the clock:
> 
> reply from 162.159.200.1: offset 0.005599 delay 0.013842, next query 32s
> reply from 139.162.219.252: offset 0.007199 delay 0.011274, next query 30s
> reply from 162.159.200.123: offset 0.007154 delay 0.010765, next query 31s
> reply from 131.111.8.61: offset 0.007642 delay 0.016057, next query 30s
> adjusting local clock by 4686.953122s
> (...)
> reply from 83.151.207.133: offset 0.011828 delay 0.014193, next query 33s
> reply from 139.162.219.252: offset 0.009902 delay 0.011271, next query 32s
> reply from 131.111.8.61: offset 0.010350 delay 0.015616, next query 33s
> adjusting local clock by 4686.164970s
> reply from 162.159.200.1: offset 0.013156 delay 0.011764, next query 34s
> reply from 131.111.8.61: offset 0.013905 delay 0.017363, next query 30s
> adjusting local clock by 4686.001301s
> 
> However, the lock does not budge at all. I can still manually set
> the clock by date -s HHMM.
> 
> Not sure how to debug it. Is it because I'm using vm and it doesn't
> support?
> 
> diso# dmesg | grep pvclock
> pvclock0 at pvbus0
> 
> Best regards,
> Chris Narkiewicz
> 

The offset is first 4686.953122s and a bit later 4686.001301s. So ntpd
works, the offset gets smaller. ntpd *only* moves the clocks in one go
(setting) on boot. After that, it adjusts the clock by making it tick
a bit slower of faster. That takes time.

Dunno why the clock is wrong after hibernation though, that's a
different issue.

-Otto



Re: ls in color

2023-12-08 Thread Otto Moerbeek
On Fri, Dec 08, 2023 at 07:45:06PM +0100, Karel Lucas wrote:

> 
> 
> Op 08-12-2023 om 19:42 schreef Theo de Raadt:
> > Karel Lucas  wrote:
> > 
> > > In openBSD V7.4 I would like to see the output of ls in color, and
> > > therefore would like to know how to configure that. The output of "man
> > > ls" provides no information about this. Can anyone give me a tip?
> > Black and white are also colours.
> > 
> That is not what I had in mind!

How about green or amber on black?

-Otto





Re: Is Pip Available On OpenBSD?

2023-12-02 Thread Otto Moerbeek
On Sun, Dec 03, 2023 at 01:38:07AM -0600, Jay F. Shachter wrote:

> 
> Esteemed Colleagues:
> 
> I am trying to build some software which claims that it needs glad2.
> Glad2 does not seem to exist as an OpenBSD package but it claims that
> it can be installed with pip.   There does not seem to be an OpenBSD
> package named py310-pip or anything similar.  Is it possible to
> install pip on OpenBSD (other than thru the dubious means of compiling
> python from source)?  Alternately, is it possible to install glad2
> without installing pip?  Or, as an alternative to the alternative, is
> it possible to install the current version of libplacebo (the OpenBSD
> package is at version 4.208.0, whereas I need at least version 6.292.0)
> without building it from source?
> 
> I haven't upgraded to OpenBSD 7.4 yet and am still running 7.3, if
> that makes a difference.
> 
> Thank you in advance for any and all replies.
> 
> 
>   Jay F. Shachter
>   6424 North Whipple Street
>   Chicago IL  60645-4111
>   (1-773)7613784   landline
>   (1-410)9964737   GoogleVoice
> http://m5.chicago.il.us
>   j...@m5.chicago.il.us
> 
>   "But when she traced the killer's IP address ... it was in the 
> 192.168/16 block!"
> 

The name of the pip package for python3 is is py3-pip.

-Otto



Re: openbsd.org DNS problems

2023-11-16 Thread Otto Moerbeek
On Fri, Nov 17, 2023 at 07:14:58AM +, tux2bsd wrote:

> I understand you're choosing to be ornery about 
> the SOA record.  Seems to matter more to you lot
> than to me, given the defense being run around it.

You claim the SOA serial being a timestamp would have helped in
diagnosis. It would not have helped.

> 
> > The issue was spotted 
> 
> You're welcome.
> 
> Only 1 of your 10 name servers was returning an 
> A record, when I raised the issue.
> 
> > and fixed.
> 
> What would be interesting is finding out what
> happened, what it a mistake or a software problem?
> 
> tux2bsd

The people running the OpenBSD project and its infra decide what to
share, not you.

-Otto



Re: openbsd.org DNS problems

2023-11-16 Thread Otto Moerbeek
On Fri, Nov 17, 2023 at 06:29:02AM +, tux2bsd wrote:

> > > Stuart Henderson wrote:
> > well, if you're nitpicking things which don't matter
> 
> I would have rather not have needed to look at all.
> 
> Useful: when was a change made, who to contact.
> (strangely enough, easy to provide via SOA)
> 
> OpenBSD list: fuck that, deflection is more fun
> 
> >> Host openbsd.org not found: 2(SERVFAIL)
> 
> Someone should prevent that from happening again.
> 
> tux2bsd
> 

"Someone should prevent that from happening again" thanks for you
insight. We never would have thouhgt that up. 

In this case using a time based SOA serial would have only told you
when the last working zone was created as the primary DNS was
ServFailing and the secondaries kept on serving what they had for the
SOA expiry period.

As for the contact address: it's mostly a spam attractor, I can
understand very well it's not a working address.

Anyway, why continue whining? The issue was spotted and fixed.

-Otto






Re: openbsd.org DNS problems

2023-11-15 Thread Otto Moerbeek
On Wed, Nov 15, 2023 at 11:49:05AM +, Craig Skinner wrote:

> Hello,
> 
> OpenBSD's root A record was deliberately removed about 5-10 years ago.
> 
> The website is http://www.openbsd.org, not http://openbsd.org
> 
> I can't find the thread of complaints from the time it changed.
> 
> Cheers,
> Craig.
> 

The report was showing ServFail answers, which is not a good thing,
whetehr a record i supposed to exist or not. But thimgs are fixed now
(and openbsd.org *does* have an A record).

-Otto



Re: openbsd.org DNS problems

2023-11-15 Thread Otto Moerbeek
On Wed, Nov 15, 2023 at 08:43:06AM +, tux2bsd wrote:

> 
> It'd be good to sort this, a bit of a meta remote hole...
> 
> This = bad.  Only people with necessary access can fix.
> 
> $ host -t a openbsd.org 199.185.230.19
> Using domain server:
> Name: 199.185.230.19
> Address: 199.185.230.19#53
> Aliases: 
> 
> Host openbsd.org not found: 2(SERVFAIL)
> $ host -t a openbsd.org 199.185.230.18
> Using domain server:
> Name: 199.185.230.18
> Address: 199.185.230.18#53
> Aliases: 
> 
> Host openbsd.org not found: 2(SERVFAIL)
> 
> 
> Web page tool:
> 
> https://dnschecker.org/all-dns-records-of-domain.php?query=openbsd.org&rtype=A&dns=dnsauth
> 

Noted. The persons capable of fixing this are travelling right now,
may take some time.

-Otto



Re: CVS checkout

2023-10-25 Thread Otto Moerbeek
On Wed, Oct 25, 2023 at 01:04:12PM +0600, Maria Morisot wrote:

> got it now, thanks. I'll start editing; but I still don't know how to submit 
> changes. Since I'm new I can't imagine anyone giving me write access; so what 
> is the process for uploading changes to the source tree for someone just 
> starting out?

diffs for the base tree are handled on the t...@openbsd.org mailing
list. http://www.openbsd.org/mail.html

-Otto

> --
> Google doesn't need to
> know every time I fart.
> 
> > On Oct 25, 2023, at 12:44, Otto Moerbeek  wrote:
> > 
> > On Wed, Oct 25, 2023 at 11:13:44AM +0600, Maria Morisot wrote:
> > 
> >> I've been trying now for a month to download source via CVS as per 
> >> instructions on openbsd.org; I get operation timed out every time. I get 
> >> no ping from anoncvs.ca.openbsd.org
> >> 
> >> I want to help work on the project in any way I can; I love OpenBSD.
> > 
> > See https://www.openbsd.org/anoncvs.html: Choose the Anonymous CVS
> > server you are going to use from the list of servers
> > (https://www.openbsd.org/anoncvs.html#CVSROOT)
> > 
> > 
> > Some examples use anoncvs.ca.openbsd.org, but that server is no longer
> > operational.
> > 
> > Pick one fomr the list mentioned.
> > 
> >-Otto



Re: CVS checkout

2023-10-24 Thread Otto Moerbeek
On Wed, Oct 25, 2023 at 11:13:44AM +0600, Maria Morisot wrote:

> I've been trying now for a month to download source via CVS as per 
> instructions on openbsd.org; I get operation timed out every time. I get no 
> ping from anoncvs.ca.openbsd.org
> 
> I want to help work on the project in any way I can; I love OpenBSD.

See https://www.openbsd.org/anoncvs.html: Choose the Anonymous CVS
server you are going to use from the list of servers
(https://www.openbsd.org/anoncvs.html#CVSROOT)


Some examples use anoncvs.ca.openbsd.org, but that server is no longer
operational.

Pick one fomr the list mentioned.

-Otto



malloc leak detection

2023-10-19 Thread Otto Moerbeek
Hello,

I made a small tutorial with some usage notes for the new malloc leak
detection which is available in OpenBSD 7.4:

https://www.drijf.net/malloc/

While I have you attention, I'd like to mention that I can use a
reasonably modern laptop as well, more detais in the last entry of

https://www.openbsd.org/want.html

-Otto



Re: OpenBSD 7.3 latest snaphots

2023-10-10 Thread Otto Moerbeek
On Tue, Oct 10, 2023 at 07:00:36AM +, jonathon575 wrote:

> Hello everyone,
> 
> How to get the latest openbsd 7.3 snapshot?! On the website, the snapshots 
> are showing for 7.4 beta version.
> 
> Also would the security patches and bugs be integrated in the openbsd 7.3 
> latest snapshots.
> 
> Kindly advise.
> 
> Many Thanks,
> John

Snapshots are about the current state of the source tree by their very
nature.

If you want to have an up-to-date 7.3, install the release and then
install patches, see http://www.openbsd.org/faq/faq10.html#Patches.

-Otto



Re: pkg_add -vV slow progression

2023-09-18 Thread Otto Moerbeek
On Sun, Sep 17, 2023 at 09:17:58PM +0300, Mihai Popescu wrote:

> Hello,
> 
> Is there any recent major change in base packages or pkg_add?
> I ask because the pkg_add -vV is slower than usual at each package,
> most of the time spent in Extracting ... phase.
> I use amd64 recent snapshot. I checked my disk and https downloads,
> they are fine.
> 
> Thank you.
> 

Maybe the switching off of softdep? But that's been a while already,
and you don't say if had that enabled.

-Otto



Re: X host-based access control token

2023-09-10 Thread Otto Moerbeek
On Sun, Sep 10, 2023 at 06:51:58PM +0200, Daniele B. wrote:

> Hello,
> 
> Trying to securing my X server beyond my pf conf, and sorry if I do
> again the compliments to the quality of the X engineering (well beyond
> OpenBSD devs effort, at X origins).
> 
> 'man X' says:
> 
> ACCESS CONTROL
>
>An X server can use several types of access control. Mechanisms
>provided in Release 7 are: 
>Host Access   Simple host-based access control. 
>MIT-MAGIC-COOKIE-1Shared plain-text "cookies". 
>XDM-AUTHORIZATION-1   Secure DES based private-keys. 
>SUN-DES-1 Based on Sun's secure rpc system, etc
> 
> 
> Launching:
> # xauth -f .XauthorityDan generate :0.0 HOST ACCESS 
> 
> I get the following error about the erroneous protocol name:
> 
> SecurityBadAuthorizationProtocol  (invalid authorization name or data)
> xauth: (argv):1:  couldn't generate authorization
> 
> Indeed, I grasped that "Host Access" is wrong in man.
> 
> So I'm here to ask the protocol token to pass to xauth to use
> host access control mechanism.
> 
> Thanks, appreciated.

See `man Xsecurity`. Host Access mode does not use xauth.

-Otto



Re: unbound and root.hints

2023-09-09 Thread Otto Moerbeek
On Sat, Sep 09, 2023 at 04:45:51PM +0200, Alessandro Baggi wrote:

> Hi list,
> when using unbound on OpenBSD 6.5 in the default configuration unbound comes
> with root.hints file.
> 
> Upgrading to OpenBSD 7.3 I noticed that root.hints is not more supplied but
> unbound manual page says:
> 
> "root-hints: 
>  read the root hints from this file. Default is nothing, using
>  builtin hints for the IN class. The file has the format of zone
>  files, with root nameserver names and addresses only. The
>  default may become outdated, when servers change, therefore it
>  is good practice to use a root-hints file."
> 
> Where I can find root-hints file?
> 
> Thank you in advance.
> 

https://www.iana.org/domains/root/files

But don't worry too much, as long as at least one IP in the (builtin)
hints works, a DNS resolver can bootstrap.

-Otto



Re: Both serial and pc consoles on Super Micro A1SRi-2758F machine

2023-08-28 Thread Otto Moerbeek
On Mon, Aug 28, 2023 at 10:33:23AM -0400, Christopher Sean Hilton wrote:

> On Mon, Aug 28, 2023 at 07:41:19AM +0200, Otto Moerbeek wrote:
> > On Sun, Aug 27, 2023 at 08:40:44PM -0400, Christopher Sean Hilton wrote:
> > 
> 
> [ ...snip... ]
> 
> > > I can solve my problems in one of two ways. If I can boot with serial
> > > consoles by setting them up in /etc/boot.conf and also have terminals
> > > on the pc consoles, I'd be happy. I'd also be happy if I could figure
> > > out how to configure the BIOS to make enable the serial port as just
> > > a plain serial port. Super Micro seems to have other ideas and I
> > > understand that this is *my* problem.
> > > 
> > > I'll tak any suggestions here.
> > 
> > What did you put into /etc/ttys when using a VGA console?
> > 
> > -Otto
> > 
> 
> I've moved it to the serial console config. Admitting in advance that
> I could be mistaken, I've posted the relevant files below. I annotated
> the dmesg output with marks to show where the serial port is detected
> and that the wsdisplay *does not attach* to the detected vga1
> device. I think that if I could make the wsdisplay device attach then
> my problem would be solved.

Having wsdisplay(4) without being the under;ying device being marked
as console is atypical. Don't know if it is possible at all. 

> 
> Thanks again
> 
> -- Chris
> 
> Attached output follows:
> 
> 
> == /etc/boot.conf ==
> 
> stty com0 115200
> set tty com0
> 
> 
> == /etc/ttys ==
> 
> #
> #   $OpenBSD: ttys,v 1.2 2008/01/09 17:39:42 miod Exp $
> #
> # name  getty   typestatus  comments
> #
> console "/usr/libexec/getty std.9600"   vt220   off secure
> ttyC0   "/usr/libexec/getty std.9600"   vt220   on  secure
> ttyC1   "/usr/libexec/getty std.9600"   vt220   on  secure
> ttyC2   "/usr/libexec/getty std.9600"   vt220   on  secure
> ttyC3   "/usr/libexec/getty std.9600"   vt220   on  secure
> ttyC4   "/usr/libexec/getty std.9600"   vt220   off secure
> ttyC5   "/usr/libexec/getty std.9600"   vt220   on  secure
> ttyC6   "/usr/libexec/getty std.9600"   vt220   off secure
> ttyC7   "/usr/libexec/getty std.9600"   vt220   off secure
> ttyC8   "/usr/libexec/getty std.9600"   vt220   off secure
> ttyC9   "/usr/libexec/getty std.9600"   vt220   off secure
> ttyCa   "/usr/libexec/getty std.9600"   vt220   off secure
> ttyCb   "/usr/libexec/getty std.9600"   vt220   off secure
> tty00   "/usr/libexec/getty std.115200" unknown on  secure

might need to play with "local" and/or "softcar" (I always forget
which does what) when using a vga console to get a login prompt on tty00
See ttys(5).

-Otto

> tty01   "/usr/libexec/getty std.115200" unknown on  secure
> tty02   "/usr/libexec/getty std.9600"   unknown off
> tty03   "/usr/libexec/getty std.9600"   unknown off
> tty04   "/usr/libexec/getty std.9600"   unknown off
> tty05   "/usr/libexec/getty std.9600"   unknown off
> tty06   "/usr/libexec/getty std.9600"   unknown off
> tty07   "/usr/libexec/getty std.9600"   unknown off
> ...
> 
> 
> == dmesg.boot ==
> 
>  OpenBSD 7.3 (GENERIC.MP) #3: Tue Jul 25 08:20:26 MDT 2023
>  
> r...@syspatch-73-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>  real mem = 8541495296 (8145MB)
>  avail mem = 8263225344 (7880MB)
>  random: good seed from bootblocks
>  mpath0 at root
>  scsibus0 at mpath0: 256 targets
>  mainbus0 at root
>  bios0 at mainbus0: SMBIOS rev. 2.8 @ 0x7f4d8000 (50 entries)
>  bios0: vendor American Megatrends Inc. version "2.1" date 01/18/2018
>  bios0: Supermicro A1SRi-2758F
>  acpi0 at bios0: ACPI 5.0
>  acpi0: sleep states S0 S5
>  acpi0: tables DSDT FACP FPDT FIDT SPMI MCFG WDAT UEFI APIC BDAT HPET 
> SSDT SPCR HEST BERT ERST EINJ
>  acpi0: wakeup devices PEX1(S0) PEX2(S0) PEX3(S0) PEX4(S0) EHC1(S0)
>  acpitimer0 at acpi0: 3579545 Hz, 24 bits
>  acpimcfg0 at acpi0
>  acpimcfg0: addr 0xe000, bus 0-255
>  acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
>  cpu0 at mainbus0: apid 0 (boot processor)
>  cpu0: Intel(R) Atom(TM) CPU C2758 @ 2.40GHz, 2400.37 MHz, 06-4d-08
>  cpu0: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,
>  cpu0: 24KB 64b/line 6-way D-cache, 32KB 64b/line 

Re: Both serial and pc consoles on Super Micro A1SRi-2758F machine

2023-08-27 Thread Otto Moerbeek
On Sun, Aug 27, 2023 at 08:40:44PM -0400, Christopher Sean Hilton wrote:

> I run my firewall on a SuperMicro A1SRi-2758F. On this hardware, I've
> noticed that I seem to have the choice of either a PC console or a
> serial console. If I ask for a serial console *on this hardware* I get
> a console on uart:com0 and it works great but I don't have any PC/VGA
> consoles. On the other hand, if I configure for a PC console, hoping
> to just enable the serial port in /etc/ttys, I have a getty running
> against the UART hardware but it can't use it as a console. Hitting
> return in a cu window from my oob server doesn't get any output.
> 
> I can solve my problems in one of two ways. If I can boot with serial
> consoles by setting them up in /etc/boot.conf and also have terminals
> on the pc consoles, I'd be happy. I'd also be happy if I could figure
> out how to configure the BIOS to make enable the serial port as just
> a plain serial port. Super Micro seems to have other ideas and I
> understand that this is *my* problem.
> 
> I'll tak any suggestions here.

What did you put into /etc/ttys when using a VGA console?

-Otto



Re: PF rate limiting options valid for UDP?

2023-07-20 Thread Otto Moerbeek
On Thu, Jul 20, 2023 at 05:52:07PM +, mabi wrote:

> --- Original Message ---
> On Wednesday, July 19th, 2023 at 10:58 PM, Stuart Henderson 
>  wrote:
> 
> > For rules that pass traffic to your authoritative DNS servers,
> > I don't think you need much longer than the time taken to answer a
> > query. So could be quite a bit less.
> 
> Right good point, I will add custom state timeouts for this specific UDP pass 
> rule on port 53.
> 
> > Usually carp/ospf will enter the state table before the machines start
> > seeing large amounts of packets and stay there, which is what you would
> > normally want. If the state table is full, you have more problem
> > opening new connections that require state to be added than you do
> > maintaining existing ones.
> > 
> > fwiw I typically use this on ospf+carp machines, "pass quick proto
> > {carp, ospf} keep state (no-sync) set prio 7"
> 
> That's very interesting, I never realized there was a simple priority system 
> ready to use in PF without the need of setting up any queues. Probably the 
> "set prio 7" option on OSPF+CARP pass rules will juts do the trick and I will 
> definitely also implement this. 
> 
> > DNS server software is written with this type of traffic in mind, and
> > has more information available (from inside the DNS request packet)
> > to make a decision about what to do with it, than is available in a
> > general-purpose packet filter like PF.
> > 
> > Also it stores the tracking information in data structures that have
> > been chosen to make sense for this use (and common DNS servers default
> > to masking on common subnet sizes, reducing the amount they have to
> > store compared to tracking the full IP address).
> > 
> > http://man.openbsd.org/nsd.conf#rrl
> > https://bind9.readthedocs.io/en/latest/reference.html#response-rate-limiting
> > https://www.knot-dns.cz/docs/2.4/html/reference.html#module-rrl
> 
> Too bad I use PowereDNS, it does not seem to offer much parameters related to 
> rate-limiting for UDP but for TCP I found at least max-tcp-connections. Maybe 
> it's time for a change as Gabor mentions his tests in his reply (thanks 
> btw!)...
> 

In a typical PowerDNS setup the task of rate limiting is done by dnsdist.

-Otto



Re: dhcpleased[59824]: sendto: Permission denied

2023-07-04 Thread Otto Moerbeek
On Mon, Jul 03, 2023 at 10:34:24AM -0600, Zack Newman wrote:

> On 7/3/23 11:25, Mark wrote:
> > I'm getting (I think once per day) "dhcpleased[59824]: sendto: Permission
> > denied" error message in my daemon and messages log files.
> > 
> > I think that's happening due to my PF configuration.
> 
> Certainly could be. If this happens consistently around a particular
> time, you can "live dangerously" and allow all traffic temporarily to
> see if the issue is resolved. More safely, use tcpdump(8) to see if you
> can find the problem.
> 
> > I tried to add:
> > pass log quick on $ext_if proto udp from any to any port = 67
> > in my pf.conf file, didn't help.
> 
> Completely useless. DHCP traffic never makes its way to pf(4) due to
> being handled by bpf(4) first, so you don't need such a rule-in fact
> you could explicitly block such traffic, and it won't matter. Proof:

That may be true for reading dhcp packets, but in some cases
dhcpleased sends UDP datagram lika any ordinary program, for other
cases it uses BPF for sending. As the error reported is for sending,
it *is* possible that pf plays a role.

-Otto

> 
> router# cat /etc/pf.conf
> # Options.
> set block-policy drop
> 
> # Macros.
> wan = em0
> 
> # Filtering rules.
> block in quick on $wan inet proto udp to port 68
> block out quick on $wan inet proto udp to port 67
> pass quick
> 
> router# rcctl stop dhcpcd
> dhcpcd(ok)
> router# rm -rf /var/run/dhcpcd/
> router# ifconfig em0 -inet
> router# ifconfig em0 -inet6
> router# ifconfig em0 down
> router# pfctl -f /etc/pf.conf
> router# tcpdump -ntt -i em0 -w pkts.dat 'udp and ip and (dst port 67 or dst 
> port 68)' &
> [1] 98425
> router# tcpdump: listening on em0, link-type EN10MB
> router# rcctl start dhcpcd
> dhcpcd(ok)
> router# pkill -x tcpdump
> 
> 12551 packets received by filter
> 0 packets dropped by kernel
> router# tcpdump -nr pkts.dat
> 10:02:29.663056 0.0.0.0.68 > 255.255.255.255.67:  xid:0x3544268 [|bootp]
> 10:02:32.802098 0.0.0.0.68 > 255.255.255.255.67:  xid:0x3544268 secs:3 
> [|bootp]
> 10:02:32.857942 96.120.140.45.67 > 73.78.65.184.68:  xid:0x3544268 
> Y:73.78.65.184 G:96.120.140.45 [|bootp] [tos 0x10]
> 
> The use of dhcpcd(8) is not relevant. I choose to use it for both DHCPv6
> and DHCP so that I only have one daemon. I am _not_ recommending its
> use over dhcpleased(8). The point is to show that such traffic is
> allowed regardless of what rules you have in pf(4).
> 
> If it is a pf(4) issue, then it not related to that traffic.
> 



recent malloc changes

2023-06-04 Thread Otto Moerbeek
Hi,

no idea how many people run snapshots or current here, but if you do,
please note

https://marc.info/?l=openbsd-tech&m=168587666517667&w=2

-Otto



Re: NFS mounted but shows nothing even df -h has it

2023-05-31 Thread Otto Moerbeek
On Thu, Jun 01, 2023 at 06:15:35AM +0800, Jazzi Hong wrote:

> Fixed, thanks Otto. I checked this drive and found an error of "BAD
> SUPER BLOCK: MAGIC NUMBER WRONG", it's fixed in the end. So I changed
> the last option of the fstab file from ZERO to TWO thus the command
> fsck can check it automatically. Thank you all for the great help, I
> am so happy my little NAS works again. The OpenBSD community is so
> helpful and there are so many nice people here, hopefully I can serve
> you all a cup of the tea I made from the mountain, actually I am
> making tea today.
> 
> > $ doas fsck -v -t ffs sd0i
> start sd0i wait fsck_ffs sd0i
> ** /dev/sd0i (sd0i)
> 
> BAD SUPER BLOCK: MAGIC NUMBER WRONG
> 
> LOOK FOR ALTERNATE SUPERBLOCKS? [Fyn?] y
> USING ALTERNATE SUPERBLOCK AT 256
> 
> ** File system is already clean
> ** Last Mounted on
> ** Phase 1 - Check Blocks and Sizes
> ** Phase 2 - Check Pathnames
> ** Phase 3 - Check Connectivity
> ** Phase 4 - Check Reference Counts
> ** Phase 5 - Check Cyl groups
> FREE BLK COUNT(S) WRONG IN SUPERBLK
> SALVAGE? [Fyn?] y
> 32580 files, 68466851 used, 40554992 free (312 frags, 5069335 blocks,
> 0.0% fragmentation)
> UPDATE STANDARD SUPERBLOCK? [Fyn?] y
> 
> * FILE SYSTEM WAS MODIFIED *
> 
> ===
> Check the drive after fsck
> ===
> ibox$ doas mount /mnt/hdd
> ibox$ ls /mnt/hdd
> Book   Picture???

Good. Some background info: soomething corrupted the standard
(primary) superblock. You might want to think what that could be. 

ffs and ffs2 have extra copies of the of the superblock available and
fskc used the 1st alternate to fix the primary superblock. Only the
summary information then has to be updated, as only the primary
superbock records summary information. This is done by computing a new
summary based on the actual disk contents.

Please use 2 as the last number in fstab lines (except for the root
fs, which whould be 1), unless you have a very good reason to use 0.

-Otto


> 
> On Wed, May 31, 2023 at 10:41 PM Otto Moerbeek  wrote:
> >
> > On Wed, May 31, 2023 at 10:25:06PM +0800, Jazzi Hong wrote:
> >
> > > Thanks for all the help. Hereby is the result of command `disklabel
> > > sd0`, seems the drive is well detected by failed mounted:
> > >
> > > > $ doas disklabel sd0
> > > # /dev/rsd0c:
> > > type: SCSI
> > > disk: SCSI disk
> > > label: SAMSANG ST1000LM
> > > duid: 2b6c2b5b929f9a55
> > >
> > > 16 partitions:
> > > #size   offset  fstype [fsize bsize   cpg]
> > >
> > >   c:   19535251680  unused
> > >   i:   1758185664   64  4.2BSD   8192 65536 52270 # 
> > > /mnt/hdd
> >
> > In your fstab, sd0i is marked ar "do not run fsck on it" (last zero in
> > its fstab line). That is bad.
> >
> > Try running fsck on sd0i. It might be that the filesystem is damaged
> > so mount does not like it, but fsck still has a chance to repair it.
> >
> > -Otto
> >
> > >
> > > On Wed, May 31, 2023 at 7:56 PM Otto Moerbeek  wrote:
> > > >
> > > > On Wed, May 31, 2023 at 11:21:15AM +0100, Zé Loff wrote:
> > > >
> > > > > On Wed, May 31, 2023 at 05:25:07PM +0800, Jazzi Hong wrote:
> > > > > > You made the point, thank you Maksim.
> > > > > > I checked /mnt/hdd and nothing there.
> > > > > > > # cat /etc/fstab
> > > > > > 1593ab2ee369c420.b none swap sw
> > > > > > 1593ab2ee369c420.a / ffs rw 1 1
> > > > > > 1593ab2ee369c420.e /var ffs rw,nodev,nosuid 1 2
> > > > > > 2b6c2b5b929f9a55.i /mnt/hdd ffs rw,noexec,nosuid,nodev 0 0
> > > > > > > # doas sysctl hw.disknames
> > > > > > hw.disknames=sd0:2b6c2b5b929f9a55,sd1:1593ab2ee369c420
> > > > > > > # doas fdisk sd0
> > > > > > Disk: sd0 geometry: 121601/255/63 [1953525168 Sectors]
> > > > > > Offset: 0 Signature: 0xAA55
> > > > > > Starting Ending LBA Info:
> > > > > >  #: id  C   H   S -  C   H   S [   start:size ]
> > > > > > ---
> > > > > >  0: 00  0   0   0 -  0   0   0 [   0:   0 ] 
> > > > > > unused
> > > > > >  1: 00  0   0   0 - 

Re: NFS mounted but shows nothing even df -h has it

2023-05-31 Thread Otto Moerbeek
On Wed, May 31, 2023 at 10:25:06PM +0800, Jazzi Hong wrote:

> Thanks for all the help. Hereby is the result of command `disklabel
> sd0`, seems the drive is well detected by failed mounted:
> 
> > $ doas disklabel sd0
> # /dev/rsd0c:
> type: SCSI
> disk: SCSI disk
> label: SAMSANG ST1000LM
> duid: 2b6c2b5b929f9a55
> 
> 16 partitions:
> #size   offset  fstype [fsize bsize   cpg]
> 
>   c:   19535251680  unused
>   i:   1758185664   64  4.2BSD   8192 65536 52270 # /mnt/hdd

In your fstab, sd0i is marked ar "do not run fsck on it" (last zero in
its fstab line). That is bad.

Try running fsck on sd0i. It might be that the filesystem is damaged
so mount does not like it, but fsck still has a chance to repair it.

    -Otto

> 
> On Wed, May 31, 2023 at 7:56 PM Otto Moerbeek  wrote:
> >
> > On Wed, May 31, 2023 at 11:21:15AM +0100, Zé Loff wrote:
> >
> > > On Wed, May 31, 2023 at 05:25:07PM +0800, Jazzi Hong wrote:
> > > > You made the point, thank you Maksim.
> > > > I checked /mnt/hdd and nothing there.
> > > > > # cat /etc/fstab
> > > > 1593ab2ee369c420.b none swap sw
> > > > 1593ab2ee369c420.a / ffs rw 1 1
> > > > 1593ab2ee369c420.e /var ffs rw,nodev,nosuid 1 2
> > > > 2b6c2b5b929f9a55.i /mnt/hdd ffs rw,noexec,nosuid,nodev 0 0
> > > > > # doas sysctl hw.disknames
> > > > hw.disknames=sd0:2b6c2b5b929f9a55,sd1:1593ab2ee369c420
> > > > > # doas fdisk sd0
> > > > Disk: sd0 geometry: 121601/255/63 [1953525168 Sectors]
> > > > Offset: 0 Signature: 0xAA55
> > > > Starting Ending LBA Info:
> > > >  #: id  C   H   S -  C   H   S [   start:size ]
> > > > ---
> > > >  0: 00  0   0   0 -  0   0   0 [   0:   0 ] 
> > > > unused
> > > >  1: 00  0   0   0 -  0   0   0 [   0:   0 ] 
> > > > unused
> > > >  2: 00  0   0   0 -  0   0   0 [   0:   0 ] 
> > > > unused
> > > > *3: A6  0   1   2 - 121601  80  63 [  64:  1953525104 ] 
> > > > OpenBSD
> > > > 
> > > > So /dev/sd0 is my NFS share hard disk, and when I tried to mount it 
> > > > manually:
> > > > > # doas mount /mnt/hdd
> > > > mount_ffs: 2b6c2b5b929f9a55.i on /mnt/hdd: Invalid argument
> > > > +++
> > > > The error message mentioned about "Invalid argument" of mount, anything 
> > > > wrong?
> > > > So the problem now is why can not mount the drive even it's detected?
> > >
> > > It can detect the drive, but it doesn't find the i partition.  What does
> > > disklabel sd0 say?
> >
> > Or it can find the i partition but mount_ffs does not like it for some 
> > reason.
> > By convention i partitions are often FAT. But we need the dislabel to
> > see what type it has.
> >
> > -Otto
> 
> 
> 
> -- 
> jazzi
> 
> Best Regard,



Re: NFS mounted but shows nothing even df -h has it

2023-05-31 Thread Otto Moerbeek
On Wed, May 31, 2023 at 11:21:15AM +0100, Zé Loff wrote:

> On Wed, May 31, 2023 at 05:25:07PM +0800, Jazzi Hong wrote:
> > You made the point, thank you Maksim.
> > I checked /mnt/hdd and nothing there.
> > > # cat /etc/fstab
> > 1593ab2ee369c420.b none swap sw
> > 1593ab2ee369c420.a / ffs rw 1 1
> > 1593ab2ee369c420.e /var ffs rw,nodev,nosuid 1 2
> > 2b6c2b5b929f9a55.i /mnt/hdd ffs rw,noexec,nosuid,nodev 0 0
> > > # doas sysctl hw.disknames
> > hw.disknames=sd0:2b6c2b5b929f9a55,sd1:1593ab2ee369c420
> > > # doas fdisk sd0
> > Disk: sd0 geometry: 121601/255/63 [1953525168 Sectors]
> > Offset: 0 Signature: 0xAA55
> > Starting Ending LBA Info:
> >  #: id  C   H   S -  C   H   S [   start:size ]
> > ---
> >  0: 00  0   0   0 -  0   0   0 [   0:   0 ] unused
> >  1: 00  0   0   0 -  0   0   0 [   0:   0 ] unused
> >  2: 00  0   0   0 -  0   0   0 [   0:   0 ] unused
> > *3: A6  0   1   2 - 121601  80  63 [  64:  1953525104 ] OpenBSD
> > 
> > So /dev/sd0 is my NFS share hard disk, and when I tried to mount it 
> > manually:
> > > # doas mount /mnt/hdd
> > mount_ffs: 2b6c2b5b929f9a55.i on /mnt/hdd: Invalid argument
> > +++
> > The error message mentioned about "Invalid argument" of mount, anything 
> > wrong?
> > So the problem now is why can not mount the drive even it's detected?
> 
> It can detect the drive, but it doesn't find the i partition.  What does
> disklabel sd0 say?

Or it can find the i partition but mount_ffs does not like it for some reason.
By convention i partitions are often FAT. But we need the dislabel to
see what type it has.

-Otto



Re: NFS mounted but shows nothing even df -h has it

2023-05-31 Thread Otto Moerbeek
On Wed, May 31, 2023 at 05:25:07PM +0800, Jazzi Hong wrote:

> You made the point, thank you Maksim.
> 
> I checked /mnt/hdd and nothing there.
> 
> > # cat /etc/fstab
> 1593ab2ee369c420.b none swap sw
> 1593ab2ee369c420.a / ffs rw 1 1
> 1593ab2ee369c420.e /var ffs rw,nodev,nosuid 1 2
> 2b6c2b5b929f9a55.i /mnt/hdd ffs rw,noexec,nosuid,nodev 0 0
> 
> > # doas sysctl hw.disknames
> hw.disknames=sd0:2b6c2b5b929f9a55,sd1:1593ab2ee369c420
> 
> > # doas fdisk sd0
> 
> Disk: sd0 geometry: 121601/255/63 [1953525168 Sectors]
> Offset: 0 Signature: 0xAA55
> 
> Starting Ending LBA Info:
> 
>  #: id  C   H   S -  C   H   S [   start:size ]
> 
> ---
> 
>  0: 00  0   0   0 -  0   0   0 [   0:   0 ] unused
> 
>  1: 00  0   0   0 -  0   0   0 [   0:   0 ] unused
> 
>  2: 00  0   0   0 -  0   0   0 [   0:   0 ] unused
> 
> *3: A6  0   1   2 - 121601  80  63 [  64:  1953525104 ] OpenBSD
> 
> 
> 
> So /dev/sd0 is my NFS share hard disk, and when I tried to mount it manually:
> 
> > # doas mount /mnt/hdd
> mount_ffs: 2b6c2b5b929f9a55.i on /mnt/hdd: Invalid argument
> 
> +++
> The error message mentioned about "Invalid argument" of mount, anything wrong?
> 
> So the problem now is why can not mount the drive even it's detected?

Show thsi disklabel of sd0:

# disklabel sd0

-Otto

> 
> Thank you,
> jazzi
> 
> On Wed, May 31, 2023 at 2:38 PM Maksim Rodin  wrote:
> >
> > The /mnt/hdd partition on your NFS server might just be not mounted
> > which does not prevent nfs service from successfully serving an empty
> > directory.
> > Or one of your two nfs clients might have deleted all your files and you
> > did not notice this.
> >
> > On Wed May 31 09:27:04 2023, Maksim Rodin wrote:
> > > Hello,
> > > Silly question but...
> > > Are you sure that your NFS server still has any files on /mnt/hdd?
> > >
> > > On Wed May 31 09:07:15 2023, Jazzi Hong wrote:
> > > > Hello,
> > > >
> > > > I have OpenBSD 7.2 installed and NFS service running on Cubieboard2,
> > > > one Linux client and one MacOS client, everything works fine for the
> > > > last 6 months.
> > > >
> > > > Yesterday as usual I mounted NFS share and showed mounting
> > > > successfully even command `df -h` got it, but `ls /Users/jazzi/nfs`
> > > > showed nothing. Tried on both Linux and MacOS.
> > > >
> > > > OpenBSD is 24*7 running and I didn't do anything to change the system,
> > > > maybe it's too hot so I shut it down for the whole night and power on
> > > > the next day but it didn't work.
> > > >
> > > > +++
> > > > Here is how I mount it on MacOS:
> > > >
> > > > > sudo mount -t nfs -o 
> > > > > resvport,async,nolocks,locallocks,soft,wsize=32768,rsize=32768 
> > > > > 192.168.31.231:/mnt/hdd /Users/jazzi/nfs
> > > >
> > > > +++
> > > > Here is the settings on OpenBSD NFS server:
> > > >
> > > > # $ cat /etc/exports
> > > >
> > > > # For Macbook Air
> > > > /mnt/hdd -alldirs -mapall=root 192.168.31.76
> > > >
> > > > # For Linux desktop
> > > > /mnt/hdd -alldirs -mapall=root 192.168.31.77
> > > >
> > > > 
> > > >
> > > > Any help will be appreciated, thank you.
> > > >
> > > >
> > > >
> > > > --
> > > > jazzi
> > > >
> > > > Best Regard,
> > > >
> > >
> > > --
> > > С уважением,
> > > Родин Максим
> >
> > --
> > С уважением,
> > Родин Максим
> 
> 
> 
> -- 
> jazzi
> 
> Best Regard,
> 



Re: Pkg_add Python version and LibreSSL seem to be incompatible in OpenBSD 7.3

2023-05-14 Thread Otto Moerbeek
On Sun, May 14, 2023 at 12:25:28PM -0400, Judah Kocher wrote:

> After updating one of my routers to OpenBSD 7.3, my python scripts that
> update various public DNS records when my public IP changes started failing
> with generic segfaults. I did see the note in the OpenBSD Upgrade Guide
> about 3.10 being the new default so I ran pkg_add -u which updated python to
> 3.10 and now the same scripts fail but with this error:
> 
> ImportError: urllib3 v2.0 only supports OpenSSL 1.1.1+, currently the 'ssl'
> module is compiled with LibreSSL 3.7.2. See:
> https://github.com/urllib3/urllib3/issues/2168
> 
> The included github link mentions that older versions of SSL are no longer
> usable with the urllib library but makes no mention of LibreSSL.
> 
> Some web searching has not turned up any details around this. I also do not
> see python 3.9 as an installable option via pkg_add, just 3.10 and 3.11.
> Does this mean that installing python via pkg_add installs a python version
> that is incompatible with LibreSSL? When I look at the info for the OpenSSL
> package it includes this warning:
> 
> This package is not intended for general-purpose use in OpenBSD - it
> is present for test/comparison purposes, and occasionally to provide
> support for applications which cannot be made compatible with LibreSSL
> (mostly due to use of removed APIs); in the latter case care must be
> taken - it will conflict if library dependencies use LibreSSL libraries.
> 
> What would be the best way to resolve this issue? I would guess that plenty
> of others are using python with OpenBSD so there must be a recommended
> resolution, but I have not found it documented anywhere yet.
> 
> 
> Thanks!
> 
> Judah
> 

The problem is very likely a version of urllib3 installed via pip, and
has little to do with the python version itself.

-Otto



Re: OpenBSD Hackathons

2023-05-12 Thread Otto Moerbeek
On Sat, May 13, 2023 at 09:18:45AM +1000, David wrote:

> On Fri, 2023-05-12 at 22:07 +0200, Anders Andersson wrote:
> > On Fri, May 12, 2023 at 9:39 PM Katherine Mcmillan
> >  wrote:
> > > 
> > > Hi Stuart,
> > > 
> > > Thank you for your response.  The upcoming OpenBSD Hackathons
> > > aren't published anywhere?  How do new people know where/when they
> > > are?
> > > 
> > > Thank you,
> > > Katie
> > 
> > From the website you linked: "Hackathon attendees come by invitation
> > only. Some new people in the community who show promise are sometimes
> > invited to see if they have what it takes. However, hackathons are
> > not
> > developer training events."
> 
> 
> 
> Perhaps it might be an idea to develop another tier of these to develop
> exactly that.
> If only 5% go on to contribute something of value, whether that be
> coding or docs, it may well be worth it. It would also contribute to
> aspects such as community building which, for a number of community-
> based projects (and one or two quite notable ones) is an aspect which
> is under-appreciated these days.
> Just some thoughts, but community-based projects are only as healthy as
> their communities.
> Cheers!
> 
> -- 
> A Kiwi in Australia,
> doing my bit toward raising the national standard.
> 

You are free to organize any event you like. For example in the
Netherlands there's a small group of people organizing get-togethers
that are open to anyone interested. Sometimes developers attend.

-Otto



Re: dhcpleased losing route

2023-05-10 Thread Otto Moerbeek
On Wed, May 10, 2023 at 08:56:10PM +1000, David Diggles wrote:

> dhcpleasectl -l cnmac2
>   
> cnmac2 [Bound]
>   inet x.x.x.x netmask x.x.x.x
>   default gateway x.x.x.1
>   nameservers x.x.x.x x.x.x.x
>   lease 6 minutes
>   dhcp server x.x.x.1
> 
> I've gone on to try isc-dhcp-client from ports and it gets exactly the same 
> problem.
> 
> It's almost as though I have an arch issue - I've tried on another identical 
> device
> with identical install - same problem.
> 
> I've tried plugging in with Apple Airport Extreme (NetBSD 4.0 ARM) does not 
> have the problem.
> I've tried plugging in with Linux/NetworkManger - does not have the problem.
> 
> I might try swapping the egress interface from cnmac2 to cnmac1,cnmac0 and 
> try my luck there.

You might find better luck by following Stuart's directions: collect
logging information and packet dumps. That will allow developers to
see what is going on, very likely.

-Otto

> 
> [ using 762392 bytes of bsd ELF symbol table ]
> Copyright (c) 1982, 1986, 1989, 1991, 1993
> The Regents of the University of California.  All rights reserved.
> Copyright (c) 1995-2023 OpenBSD. All rights reserved.  https://www.OpenBSD.org
> 
> OpenBSD 7.3 (GENERIC.MP) #1242: Sat Mar 25 18:04:31 MDT 2023
> dera...@octeon.openbsd.org:/usr/src/sys/arch/octeon/compile/GENERIC.MP
> real mem = 536870912 (512MB)
> avail mem = 521093120 (496MB)
> random: good seed from bootblocks
> mainbus0 at root: board 20002 rev 2.12, model CN3xxx/CN5xxx
> cpu0 at mainbus0: CN50xx CPU rev 0.1 500 MHz, Software FP emulation
> cpu0: cache L1-I 32KB 4 way D 16KB 64 way, L2 128KB 8 way
> cpu1 at mainbus0: CN50xx CPU rev 0.1 500 MHz, Software FP emulation
> cpu1: cache L1-I 32KB 4 way D 16KB 64 way, L2 128KB 8 way
> clock0 at mainbus0: int 5
> octcrypto0 at mainbus0
> iobus0 at mainbus0
> simplebus0 at iobus0: "soc"
> octciu0 at simplebus0
> octsmi0 at simplebus0
> octpip0 at simplebus0
> octgmx0 at octpip0 interface 0
> cnmac0 at octgmx0: port 0 RGMII, address dc:9f:db:28:14:bd
> atphy0 at cnmac0 phy 7: AR8035 10/100/1000 PHY, rev. 2
> cnmac1 at octgmx0: port 1 RGMII, address dc:9f:db:28:14:be
> atphy1 at cnmac1 phy 6: AR8035 10/100/1000 PHY, rev. 2
> cnmac2 at octgmx0: port 2 RGMII, address dc:9f:db:28:14:bf
> atphy2 at cnmac2 phy 5: AR8035 10/100/1000 PHY, rev. 2
> com0 at simplebus0: ns16550a, 64 byte fifo
> com0: console
> dwctwo0 at iobus0 base 0x118006800 irq 56
> usb0 at dwctwo0: USB revision 2.0
> uhub0 at usb0 configuration 1 interface 0 "Octeon DWC2 root hub" rev 
> 2.00/1.00 addr 1
> octrng0 at iobus0 base 0x14000 irq 0
> umass0 at uhub0 port 1 configuration 1 interface 0 "Imation Atom USB Device" 
> rev 2.00/1.00 addr 2
> umass0: using SCSI over Bulk-Only
> scsibus0 at umass0: 2 targets, initiator 0
> sd0 at scsibus0 targ 1 lun 0:  removable 
> serial.071805340503380BB56D
> sd0: 7644MB, 512 bytes/sector, 15654912 sectors
> vscsi0 at root
> scsibus1 at vscsi0: 256 targets
> softraid0 at root
> scsibus2 at softraid0: 256 targets
> root on sd0a (1e748e9c1a25cfa3.a) swap on sd0b dump on sd0b
> 
> On Wed, May 10, 2023 at 08:09:17AM +0200, Mike Fischer wrote:
> > What does `# dhcpleasectl -l cnmac2` output on the machine you are using?
> > 
> > Mine (OpenBSD 7.3 amd64 vm on the LAN) looks like this (anonymised):
> > root@vm2:~# dhcpleasectl -l vio0
> > vio0 [Bound]
> > inet 192.168.x.220 netmask 255.255.255.0
> > default gateway 192.168.x.1
> > nameservers 192.168.x.1
> > lease 24 hours  < what is your lease time?
> > dhcp server 192.168.x.1
> > root@vm2:~# 
> > 
> > I suspect your lease time is much higher than 5 min. An ISP issuing leases 
> > as short as 5 min. would be highly unusual.
> > 
> > You could try running dhcpleased manually like this to see details about 
> > what is going on:
> > # dhcpleased -vv -d
> > 
> > (But you???d need to stop the processes started by rc(8) first. E.g.: `# 
> > rcctl stop dhcpleased`. Don???t forget to `# rcctl start dhcpleased` when 
> > you are done with the testing.)
> > 
> > 
> > Does the interface go down and up for some reason every 5 minutes? That 
> > might cause dhcpleased(8) to renew the lease.
> > 
> > 
> > HTH
> > Mike
> > 
> > > Am 10.05.2023 um 07:28 schrieb Otto Moerbeek :
> > > 
> > > On Wed, May 10, 2023 at 01:17:05PM +1000, David Diggles wrote:
> > > 
> > >>

Re: dhcpleased losing route

2023-05-09 Thread Otto Moerbeek
On Wed, May 10, 2023 at 01:17:05PM +1000, David Diggles wrote:

> 
> Just to update, I've added the following to dhclient.conf but
> it's still renewing every 5 minutes (approximately) and the
> default route is disappearing for a couple of seconds. :(
> 
> send dhcp-lease-time 86400;

dhcpleased does not use dhclient.conf, it used dhcpleased.conf, which
does not have a way to influence the lease time requested (if that is a
thing).

-Otto
> 
> On Wed, May 10, 2023 at 01:00:00PM +1000, David Diggles wrote:
> > My ISP provides connection via DHCP.
> > 
> > Every 5 minutes or so when dhcpleased is renewing the lease,
> > my default route disappears for a few seconds.
> > 
> > Definitely I'll be looking at requesting a longer lease by
> > putting a setting in /etc/dhclient.conf but is there any way
> > I can stop the default route disappearing with each renew event?
> > 
> > The route didn't disappear when I tested with NetBSD and Linux.
> > 
> > This seems like I'm missing a setting in dhclient.conf to make
> > the default route sticky? I can't see any obvious answers in
> > the man page for dhclient.conf unfortunately.
> > 
> > (IP fudged log snippet below)
> > 
> > May 10 12:23:21 openbsd-gateway dhcpleased[77979]: deleting nameservers 
> > x.x.x.x x.x.x.x (lease from x.x.x.1 on cnmac2)
> > May 10 12:23:21 openbsd-gateway dhcpleased[77979]: deleting x.x.x.30 from 
> > cnmac2 (lease from x.x.x.1)
> > May 10 12:23:23 openbsd-gateway dhcpleased[77979]: adding x.x.x.30 to 
> > cnmac2 (lease from x.x.x.1)
> > May 10 12:23:23 openbsd-gateway dhcpleased[77979]: adding nameservers 
> > x.x.x.x x.x.x.x (lease from x.x.x.1 on cnmac2)
> > May 10 12:28:23 openbsd-gateway dhcpleased[77979]: deleting nameservers 
> > x.x.x.x x.x.x.x (lease from x.x.x.1 on cnmac2)
> > May 10 12:28:23 openbsd-gateway dhcpleased[77979]: deleting x.x.x.30 from 
> > cnmac2 (lease from x.x.x.1)
> > May 10 12:28:25 openbsd-gateway dhcpleased[77979]: adding  x.x.x.30 to 
> > cnmac2 (lease from x.x.x.1)
> > May 10 12:28:25 openbsd-gateway dhcpleased[77979]: adding nameservers 
> > x.x.x.x x.x.x.x (lease from x.x.x.1 on cnmac2)
> > May 10 12:33:26 openbsd-gateway dhcpleased[77979]: deleting nameservers 
> > x.x.x.x x.x.x.x (lease from x.x.x.1 on cnmac2)
> > May 10 12:33:26 openbsd-gateway dhcpleased[77979]: deleting x.x.x.30 from 
> > cnmac2 (lease from x.x.x.1)
> > May 10 12:33:28 openbsd-gateway dhcpleased[77979]: adding x.x.x.30 to 
> > cnmac2 (lease from x.x.x.1)
> > May 10 12:33:28 openbsd-gateway dhcpleased[77979]: adding nameservers 
> > x.x.x.x x.x.x.x (lease from x.x.x.1 on cnmac2)
> > May 10 12:38:28 openbsd-gateway dhcpleased[77979]: deleting nameservers 
> > x.x.x.x x.x.x.x (lease from x.x.x.1 on cnmac2)
> > May 10 12:38:28 openbsd-gateway dhcpleased[77979]: deleting  x.x.x.30 from 
> > cnmac2 (lease from x.x.x.1)
> > May 10 12:38:30 openbsd-gateway dhcpleased[77979]: adding  x.x.x.30 to 
> > cnmac2 (lease from x.x.x.1)
> > May 10 12:38:30 openbsd-gateway dhcpleased[77979]: adding nameservers 
> > x.x.x.x x.x.x.x (lease from x.x.x.1 on cnmac2)
> > 
> 



malloc leak detection available in -current

2023-04-17 Thread Otto Moerbeek


If you're developing C or C++ code on OpenBSD, this might be of
interest:

https://marc.info/?l=openbsd-tech&m=168171382927798&w=2

-Otto



Re: Weird clang behavior

2023-03-02 Thread Otto Moerbeek
On Thu, Mar 02, 2023 at 12:00:18PM +, Ali Farzanrad wrote:

> Hi,
> 
> Is it normal to have such behavior?
> 
> $ cat loop.c
> int
> main(void)
> {
>   for (;;)
>   ;
> }
> $ clang -O1 -Wall -Wextra -S -o loop.c.s loop.c
> $ clang++ -O1 -Wall -Wextra -S -o loop.cxx.s loop.c
> clang++: warning: treating 'c' input as 'c++' when in C++ mode, this behavior 
> is deprecated [-Wdeprecated]
> $ diff -U8 loop.c.s loop.cxx.s
> --- loop.c.s  Thu Mar  2 11:55:02 2023
> +++ loop.cxx.sThu Mar  2 11:55:08 2023
> @@ -5,20 +5,16 @@
>   .type   main,@function
>  main:   # @main
>   .cfi_startproc
>  # %bb.0:
>   pushq   %rbp
>   .cfi_def_cfa_offset 16
>   .cfi_offset %rbp, -16
>   movq%rsp, %rbp
> - .cfi_def_cfa_register %rbp
> - .p2align4, 0x90
> -.LBB0_1:# =>This Inner Loop Header: Depth=1
> - jmp .LBB0_1
>  .Lfunc_end0:
>   .size   main, .Lfunc_end0-main
>   .cfi_endproc
>  # -- End function
>   .section
> .text.__llvm_retpoline_r11,"axG",@progbits,__llvm_retpoline_r11,comdat
>   .hidden __llvm_retpoline_r11# -- Begin function 
> __llvm_retpoline_r11
>   .weak   __llvm_retpoline_r11
>   .p2align4, 0xcc
> 
> 
> See that jmp instruction which is removed.
> Without that jmp instruction the main function might reach other codes!
> 

See https://en.cppreference.com/w/cpp/language/for "Notes"

In C++, a for loop that has no observable behaviour can be removed.
Note that "observable behaviour" has a specific definition in C++.

-Otto



Re: Performance optimizing OpenBSD 7.2

2023-02-15 Thread Otto Moerbeek
On Tue, Feb 14, 2023 at 11:04:57PM +0100, Lars Bonnesen wrote:

> What can be done to optimize obsd 7.2 running on top of ESXi 7 with
> 
> 7 vmx "phys" ifs
> 3 em "phys" ifs
> 22 virtual ifs
> 
> Very simply pf ruleset - the box is only running VPN solution between two
> sites up against a similar configured obsd 7.2
> 
> I came across https://calomel.org/network_performance.html which has a
> section concerning obsd 5.1 "and later" - is this also valid for 7.2? I did
> implement the suggestions adapted to the setup, but I can't really see any
> noticeable difference.

This site is genereally regarded as garbage. Do not use it.

> 
> I configured the box with 8 vCPUs and 8 gig RAM and after running for some
> time getting more and more load, I started to face massive package loss
> both for packages between the two sites but also from the obsd and to the
> rest of the world. CPU was far from reaching any critical level and loads
> of memory left
> 
> I downscaled from 8 to 4 vCPUs and from 8 to 4 gig RAM - and the two obsd
> now seems to hold the packages decently. But for instance when pinging
> 1.1.1.1, I sometimes get:
> 
> # ping 1.1.1.1
> PING 1.1.1.1 (1.1.1.1): 56 data bytes
> ping: sendmsg: Permission denied
> ping: wrote 1.1.1.1 64 chars, ret=-1
> ping: sendmsg: Permission denied
> ping: wrote 1.1.1.1 64 chars, ret=-1
> ping: sendmsg: Permission denied
> ping: wrote 1.1.1.1 64 chars, ret=-1
> 64 bytes from 1.1.1.1: icmp_seq=3 ttl=61 time=0.826 ms
> 64 bytes from 1.1.1.1: icmp_seq=4 ttl=61 time=0.797 ms
> 64 bytes from 1.1.1.1: icmp_seq=5 ttl=61 time=0.799 ms
> 
> Some permissions denied and then it continues to ping
> 
> Sometimes when trying to ping a FQDN, I get:
> ping: no address associated with name
> as it cannot resolve the name
> 
> The name is of course registered correctly in DNS.
> 
> We are planning to put even more load on the setup, but I am not sure that
> it is a good idea

Hard to say, but this could very well be pf running out of states.
pfctl -s info and look at state-limit and/or src-limit. If you are
natting, also look at translate.

-Otto
> 
> The ESX server has hyperthreading enabled.There are many discussions about
> this, and what I can summarize is that apart from a security perspective,
> hyperthreading should be left enabled
> 
> How to get better performance?
> 
> Regards, Lars.



Re: Taring a "posix problemozauro"..

2023-02-10 Thread Otto Moerbeek
On Fri, Feb 10, 2023 at 11:24:55AM +0100, Peter N. M. Hansteen wrote:

> On Fri, Feb 10, 2023 at 11:12:44AM +0100, Daniele Bonini wrote:
> > 
> > But when it is matter to deliver things from OpenBSD eg. to other
> > live destination taring the same stuff I get the following error:
> > 
> > tar: File name too long for ustar
> > "go/Pippo/Pluto_Pluto_Pluto_Pluto/pippo/EN/pippo pippo pippo pippo
> > technical assistance and sale of appliances emergency service
> > throughout the pippo area pippo pippo superpippopippo.com"
> > 
> > and these folder and files doesn't comes compressed at all.
> 
> The first thing that comes to my mind is to try with GNU tar
> which is available as a package on OpenBSD - pkg_add gtar should get
> you that one. 
> 
> It is possible or even likely you are being tripped up by "differing 
> interpretations" of the archive format spec.
> 
> Also, spaces in file names could be part of the problem set.
> 
> - Peter

The default tar format (ustar) has path length and file name length
limits. See pax(1) for some details.

GNU tar has code to handle the long names. iirc we do handle these
when unpacking, but have no code to create tar archives with these
long names.

-Oto



Re: permission denied when writing to mounted directory exported by NFS server

2023-02-10 Thread Otto Moerbeek
On Fri, Feb 10, 2023 at 09:10:55AM +0100, carsten.re...@t-online.de wrote:

> On Fri, Feb 10, 2023 at 12:58:21PM +0530, Sandeep Gupta wrote:
> > On test setup I got this fixed. I will try to see if it works on actual
> > system.
> > 
> > I made following changes:
> > - modified /etc/exports entry
> > `
> > /nfs/testdir -alldirs  -maproot=root:wheel -network=192.168.0
> > -mask=255.255.255.0
> 
> This sounds like the typical "fix your access rights" problem
> 
> > `
> > The not-working version used "-maproot=root".
> > 
> 
> probably your "not-working" user wasn't root ? but is a member of the group 
> wheel ?

I asked that already. As NFS in general to seems work (at least for
r/o access), this is almost 100% a permission issue. But other went of
to chase geese.

So again, run in the dir:

ls -ld
id

And show the output.

-Otto

> 
> > - started nfsd from command line
> > `
> > doas /sbin/nfsd -tun 4
> > `
> > For some reason starting using rcctl fails as can be seen below:
> > ```
> > You have new mail.
> > openbsd$ doas rcctl start portmap mountd nfsd
> > nfsd(failed)
> 
> nfsd(failed) is bad ...
> 
> > openbsd$ doas /sbin/nfsd -tun 4
> > openbsd$ ps aux | grep nfsd
> > root 21178  0.0  0.1   480  1132 ??  S  12:51PM0:00.01 nfsd:
> > master
> > root 95864  0.0  0.0   176   520 ??  S  12:51PM0:00.00 nfsd:
> > server
> > root 29237  0.0  0.0   176   520 ??  S  12:51PM0:00.00 nfsd:
> > server
> > root 37092  0.0  0.0   176   520 ??  S  12:51PM0:00.00 nfsd:
> > server
> > root 40371  0.0  0.0   176   520 ??  S  12:51PM0:00.00 nfsd:
> > server
> > adming   20594  0.0  0.1   524  1264 00  S+p12:51PM0:00.02 grep nfsd
> > ```
> > 
> > For debugs, here is output of rpcinfo:
> > [adming@cluster-node2]~% rpcinfo -p 192.168.0.122
> >program vers proto   port  service
> > 102   tcp111  portmapper
> > 102   udp111  portmapper
> > 151   udp859  mountd
> > 153   udp859  mountd
> > 151   tcp806  mountd
> > 153   tcp806  mountd
> > 132   udp   2049  nfs
> > 133   udp   2049  nfs
> > 132   tcp   2049  nfs
> > 133   tcp   2049  nfs
> > 
> > Since, on both client and server, the root is writing -- the uid and gid is
> > 0.
> 
> Never do this ... I don't remember exactly, but NFS might not like it ...
> 
> Never play with root
> 
> 
> > 
> > On Fri, Feb 10, 2023 at 5:13 AM  wrote:
> > 
> > > On Thu, Feb 09, 2023 at 08:40:50AM +0100, Daniele B. wrote:
> > > > Unfortunately - personal experience - NFS is not the best offering from
> > > OpenBSD: it is enough
> > > > combersome to setup and easy to lose grip: something unsafe to keep me
> > > away from it.
> > > >
> > >
> > >
> > > What exactly do you mean ?
> > >
> > > rcctl enable portmap mountd nfsd
> > >
> > > what is so cumbersome with that ?
> > >
> > > What can we do better ?
> > >
> > >
> > > > However, for your testing purposes, I can suggest you there is a
> > > specific tool to test, server and client
> > > > status. looking to the man I guess it should be nfsstat pointed to one
> > > or the other host same time.
> > > > Probably some other people could be more detailed.
> > > >
> > > > -- Daniele Bonini
> > > >
> > > > Feb 8, 2023 17:00:09 Sandeep Gupta :
> > > >
> > > > > Looking at the docs I am not able
> > > > > to find any otherconfig options for access control on the client side.
> > > > > There is nothing in the logs on the server side as well. Any pointers
> > > to
> > > > > debug/fix would be of great help.
> > > >
> > >
> > >
> 



Re: permission denied when writing to mounted directory exported by NFS server

2023-02-08 Thread Otto Moerbeek
On Thu, Feb 09, 2023 at 11:41:12AM +0530, Sandeep Gupta wrote:

> Following up on this. I looked into the /var/log/messages/ and
> /var/log/daemon. Both are quite after starting the portmap, mountd, and
> nfsd services.
> 
> Here is verbose output from the client side when mounting the share:
> ```
> [adming@cluster-node2]~% sudo mount -t nfs -o rw,noauto -v
> 192.168.0.122:/nfs/testdir
>  /home/adming/mntpt2
> mount.nfs: timeout set for Thu Feb  9 11:34:52 2023
> 
> mount.nfs: trying text-based options
> 'vers=4.2,addr=192.168.0.122,clientaddr=192.168.0.187'
> mount.nfs: mount(2): Protocol not supported
> mount.nfs: trying text-based options
> 'vers=4,minorversion=1,addr=192.168.0.122,clientaddr=192.168.0.187'
> mount.nfs: mount(2): Protocol not supported
> mount.nfs: trying text-based options
> 'vers=4,addr=192.168.0.122,clientaddr=192.168.0.187'
> mount.nfs: mount(2): Protocol not supported
> Created symlink
> /run/systemd/system/remote-fs.target.wants/rpc-statd.service →
> /usr/lib/systemd/system/rpc-statd.service.
> mount.nfs: trying text-based options 'addr=192.168.0.122'
> mount.nfs: prog 13, trying vers=3, prot=6
> mount.nfs: trying 192.168.0.122 prog 13 vers 3 prot TCP port 2049
> mount.nfs: prog 15, trying vers=3, prot=17
> mount.nfs: trying 192.168.0.122 prog 15 vers 3 prot UDP port 724
> [adming@cluster-node2]~% cd mntpt2
> [adming@cluster-node2]~/mntpt2% ls
> alfpha  testfile
> [adming@cluster-node2]~/mntpt2% touch y
> touch: cannot touch 'y': Permission denied
> ```
> 
> Am out of ideas as what to test/debug.

run the commands
$ ls -ld 
$ id

to see what the permissions are on te dir and what user you are running as.

-Otto

> 
> 
> 
> On Wed, Feb 8, 2023 at 9:27 PM Sandeep Gupta 
> wrote:
> 
> > I have a default installation of openbsd, with portmap, mountd, nfsd
> > services started via rcctl. I have following entry in /etc/exports
> >
> > /nfs/testdir -alldirs  -maproot=root -network=192.168.0 -mask=255.255.255.0
> >
> > I am able to mount the exported share on client (centos) as follows:
> >
> > sudo mount -t nfs -o rw,noauto -v 192.168.0.122:/nfs/testdir mntpt3
> >
> > From the client, I can read the contents. But writing inside the mounted
> > directory yields permission denied error. Looking at the docs I am not able
> > to find any otherconfig options for access control on the client side.
> > There is nothing in the logs on the server side as well. Any pointers to
> > debug/fix would be of great help.
> >



Re: hw.ncpuonline

2023-01-31 Thread Otto Moerbeek
On Wed, Feb 01, 2023 at 07:35:16AM +0100, Janne Johansson wrote:

> Den ons 1 feb. 2023 kl 03:08 skrev Justin Muir :
> > I've got an AMD A10 with 4 cores and only 2 are online. I'm not sure how to
> > enable the other 2.
> >
> > hw.ncpufound=4 btw
> > Any ideas out there?
> 
> OpenBSD disables hyperthreading (or symmetric multithreading, smt), so
> if your "4-core" cpu is actually 2 real cores and 2 hyperthreads, then
> this sounds perfectly reasonable.
> 
> For example, this box of mine (not the same cpu, but still), it looks like 
> this:
> 
> hw.ncpufound=8
> hw.smt=0
> hw.ncpuonline=4
> 
> so I get the 4 real cores running out of possibly 8.
> 
> -- 
> May the most significant bit of your life be positive.
> 

It is posible to enable symmetric multithreading, at your own risk as
it makes certain types of attack easier. Often it does not increase
performance.

sysctl hw.smt=1

See man sysctl.conf for a permanent solution.

-Otto



Re: Unbound fails to resolve some domains

2023-01-26 Thread Otto Moerbeek
On Fri, Jan 27, 2023 at 01:26:10AM +, Rodrigo Readi wrote:

> It still happens. But when I kill unbound and start it again, then
> resolves domains that previously did not resolve.
> 
> BTW, I am using Wifi with weak signal. Perhaps this plays a role?
> 
> Rod.
> 
> 
> 2023-01-11 20:06 GMT, Rodrigo Readi :
> > I have unbound 1.16.3 on OpenBSD 7.2, all obtained by succesive upadates
> > (no new installation).
> >
> > It stopped to resolve some domains, for example qwant.com
> >
> > Any Idea what is happening?
> >
> > Thanks
> > Rodrigo
> >
> 

Increase log level and look at the logs? Otherwise it's just a
guessing game.

-Otto



Re: chmod change means dump(8) the file

2023-01-25 Thread Otto Moerbeek
On Thu, Jan 26, 2023 at 12:18:45AM +0100, Jan Stary wrote:

> I have a large /media disk that I backup nightly using dump(8):
> full level 0 on the Sun/Mon night, incrementals through the week.
> The level 0 dump is huge, the incrementals are usualy trivial
> unless I add something to /media.
> 
> Yesterday I chmod'd a lot of the files, without making any other change.
> That resulted in a huge level 2 dump; I suppose a chmod change counts
> as a changed file, so they all got dumped anew, even though the content
> of the file(s) has not changed.

The filesystem has no way to tell that. e.g. there could be rm
followed by inode re-use. So dump *has* to be conservative and
consider both mtime and ctime changes.

-Otto

> 
> Is that intentional? It seems there is a lot of space to be saved
> if it's "only" the metadata that have changed. Is that decided by
> simply looking at the stat(2)? In particular, newer ctime is
> just as good a reason to dump the _content_ as newer mtime?
> 
>   Jan
> 



Re: Is CRONTAB(5) random really random ?

2023-01-05 Thread Otto Moerbeek
On Fri, Jan 06, 2023 at 12:58:48AM +0100, Rachel Roch wrote:

> 
> 
> 
> 5 Jan 2023, 18:24 by purushar...@gmx.com:
> 
> > Namaste Rachel, Theo(s),
> >
> >> Sent: Thursday, January 05, 2023 at 5:50 PM
> >> From: "Theo de Raadt" 
> >> To: "Theo Buehler" 
> >> Cc: "Rachel Roch" , "Misc" 
> >> Subject: Re: Is CRONTAB(5) random really random ?
> >>
> >> Theo Buehler  wrote:
> >>
> >> > On Thu, Jan 05, 2023 at 06:15:43PM +0100, Rachel Roch wrote:
> >> > > According to the docs :
> >> > > 
> >> > > > A random value (within the legal range) may be obtained by using
> >> > > > the ???~??? character in a field.
> >> > 
> >> > The random numbers are drawn once and then repeated regularly. This
> >> > behavior has always bothered me but never enough to spend the time
> >> > needed to fix it (it's not immediately obvious how to do it). A
> >> > workaround is to use a 
> >> > 
> >> >  sleep $((RANDOM \% 512)) && run_whatever
> >> > 
> >> > construct. The number to the right of the modulo should be a power of 2
> >> > to avoid modulo bias.
> >>
> >> Any solution would need to be careful, so that a operation doesn't run
> >> multiple times in an hour.  Each column should be '0 + random % range',
> >> but multiple columns contain ~, it gets weird.
> >>
> >
> > The following thread may be helpful:
> >
> > "Regarding randomized times in crontab"
> > https://marc.info/?l=openbsd-misc&m=158705405304672&w=2
> >
> > Dhanyavaad,
> > Dharma Artha Kama Moksha
> >
> 
> Thank you all for your insightful input, looks like the $RANDOM prefix idea 
> is the only quick-fix to this.
> 
> I didn't realise the random value was only set once. Maybe someone should 
> update the man page accordingly ?
> 

To be clear, it is "once per ~ occurrence in the crontab", not once
for all ~ or once per crontab line.

-Otto



Re: fsck UNREF FILE

2023-01-02 Thread Otto Moerbeek
On Mon, Jan 02, 2023 at 05:53:25PM -0800, Randall wrote:

> After my OpenBSD 7.2 box lost power, bootup halted when rc ran fsck which
> reported problems with inodes. At the root prompt, I ran fsck and answered
> 'y' to each prompt. Now, in normal mode, running fsck reports a few
> unreferenced files, auto-answers "no" to its "CLEAR?" prompt, and continues.
> 
> $ sudo fsck
> 
> ...
> 
> ** /dev/sd0f (1cc70a7feb167ca7.f) (NO WRITE)
> ** Last Mounted on /usr
> ** Phase 1 - Check Blocks and Sizes
> ** Phase 2 - Check Pathnames
> ** Phase 3 - Check Connectivity
> ** Phase 4 - Check Reference Counts
> UNREF FILE I=1710838  OWNER=root MODE=100444
> SIZE=2935688 MTIME=Jan  1 15:44 2023
> CLEAR? no
> 
> UNREF FILE I=2799427  OWNER=root MODE=100444
> SIZE=220408 MTIME=Jan  1 15:44 2023
> CLEAR? no
> 
> ** Phase 5 - Check Cyl groups
> 16199 files, 373887 used, 14859799 free (447 frags, 1857419 blocks, 0.0%
> fragmentation)
> 
> ...
> 
> 1 files, 1 used, 1520726 free (14 frags, 190089 blocks, 0.0% fragmentation)
> ** /dev/sd0e (1cc70a7feb167ca7.e) (NO WRITE)
> ** Last Mounted on /var
> ** Phase 1 - Check Blocks and Sizes
> ** Phase 2 - Check Pathnames
> ** Phase 3 - Check Connectivity
> ** Phase 4 - Check Reference Counts
> UNREF FILE I=518412  OWNER=root MODE=100444
> SIZE=11479 MTIME=Jan  1 15:44 2023
> CLEAR? no
> 
> ** Phase 5 - Check Cyl groups
> 404 files, 15061 used, 4232530 free (226 frags, 529038 blocks, 0.0%
> fragmentation)
> 
> Why does fsck say "NO WRITE" for each partition? Is this why it auto-answers
> "no" to the "CLEAR?" question?
> 
> --Randall
> 

When yo run fsck on an mounted filesystem, fsck does not write. That's
why it auto-answer "no" to each question. Unmount the file system and
try again. You might need to go to single-user mode for that.

-Otto



Re: pf tcpdump rule def ?

2022-12-26 Thread Otto Moerbeek
On Tue, Dec 27, 2022 at 04:23:13AM +, Shadrock Uhuru wrote:

> hi everyone
> viewing my pf logs with
> tcpdump -nettt -i pflog0 there are lines with no rule numbers
> just rule def on the line instead,
> i've tried googling without success,
> need to know if they are wolf,sheep or misconfigurations causing them,
> and against which rule do i match them up with.
> 
> the following is a snippet showing the rules
> thanks shadrock
> 
> Dec 27 03:00:40.557716 rule 7/(match) block in on em0: 192.168.1.1 > 
> 224.0.0.1: igmp query [tos 0xc0] [ttl 1]
> Dec 27 03:00:59.495834 rule 35/(match) block in on pppoe0: 
> 167.248.133.160.60037 > 88.97.5.79.12473: S 904362479:904362479(0) win 1024
>  
>  Dec 27 03:00:59.813362 rule def/(match) pass in on pppoe0: 
> 198.252.206.25.443 > 10.2.1.79.13522: P 3251931305:3251931366(61) ack 27080
>  26055 win 63 
>  Dec 27 03:00:59.820893 rule def/(match) pass out on pppoe0: 88.97.5.79.14256 
> > 198.252.206.25.443: P 4273536371:4273536410(39) ack 334
>  5204755 win 256  (DF)
>  Dec 27 03:00:59.823015 rule def/(match) pass out on pppoe0: 88.97.5.79.14256 
> > 198.252.206.25.443: P 39:78(39) ack 1 win 256   timestamp 380012019 1163664932> (DF)
>  Dec 27 03:00:59.825388 rule def/(match) pass out on pppoe0: 88.97.5.79.14256 
> > 198.252.206.25.443: P 78:117(39) ack 1 win 256  1163664932> (DF)
>  Dec 27 03:00:59.900318 rule def/(match) pass in on pppoe0: 
> 198.252.206.25.443 > 10.2.1.79.13522: . ack 40 win 63  1163665020 380012019>
>  Dec 27 03:00:59.902502 rule def/(match) pass in on pppoe0: 
> 198.252.206.25.443 > 10.2.1.79.13522: . ack 79 win 63  1163665022 380012019>
>  Dec 27 03:00:59.904998 rule def/(match) pass in on pppoe0: 
> 198.252.206.25.443 > 10.2.1.79.13522: . ack 118 win 63  1163665024 380012019>
>  Dec 27 03:01:03.661072 rule 35/(match) block in on pppoe0: 45.64.84.24.27789 
> > 88.97.5.79.23: S 1482753359:1482753359(0) win 30613 
>  Dec 27 03:01:11.480942 rule 35/(match) block in on pppoe0: 
> 205.185.127.238.40598 > 88.97.5.79.60001: S 1843251311:1843251311(0) win 
> 65535 
>  Dec 27 03:01:11.935746 rule 7/(match) block in on bge0: 0.0.0.0 > 224.0.0.1: 
> igmp query [len 12] [tos 0xc0] [ttl 1]
>  Dec 27 03:01:25.422772 rule 38/(match) pass in on pppoe0: 145.131.132.84.443 
> > 10.2.1.79.42434: P 5666:5697(31) ack 1264 win 244  3399431690 2022623608>
>  Dec 27 03:01:25.422795 rule 38/(match) pass in on pppoe0: 145.131.132.84.443 
> > 10.2.1.79.42434: F 5697:5697(0) ack 1264 win 244  3399431690 2022623608>
>  Dec 27 03:01:25.424055 rule 38/(match) pass out on pppoe0: 88.97.5.79.8748 > 
> 145.131.132.84.443: . ack 5698 win 255  3399431690> (DF)
>  Dec 27 03:01:28.600657 rule 37/(match) pass in on pppoe0: 93.184.220.29.80 > 
> 10.2.1.79.12939: . ack 481 win 131 
>  Dec 27 03:01:28.601419 rule 37/(match) pass out on pppoe0: 88.97.5.79.31263 
> > 93.184.220.29.80: . ack 575 win 256  235524325> (DF)
> 

def is the default rule. From pf.conf(5):

 Each time a packet processed by the packet filter comes in on or goes out
 through an interface, the filter rules are evaluated in sequential order,
 from first to last.  For block and pass, the last matching rule decides
 what action is taken; if no rule matches the packet, the default action
 is to pass the packet without creating a state.  For match, rules are
 evaluated every time they match; the pass/block state of a packet remains
 unchanged.

-Otto



Re: How to set up a data disk of 4TB?

2022-12-09 Thread Otto Moerbeek
On Fri, Dec 09, 2022 at 04:19:49PM +, James Johnson wrote:

> Hi all,
> 
> I have installed an internal hard drive of 4TB. This drive will be used for 
> storing data only. It will not contain the OpenBSD system itself.
> 
> Knowing the limitations of MBR, I have opted for a GPT partitioning system : 
> fdisk -A sd0
> 
> Following this, I am trying to add the partition with disklabel.
> 
> I have created the a partition, of 2TB (the size suggested by the system).
> Then I try to add another partition, but disklabel tells me I have no space 
> remaining.
> 
> I am stuck. The only option that seems relevant in the man page is to modify 
> the boundary with the -b option. I am scared to do so without specific advice 
> though, as it could corrupt the OS if done improperly, from what the manual 
> says.
> 
> I just want to be able to use the full size of the disk. Ideally, I would 
> like a single 4TB partition, but if not possible, I am fine with 2 partitions 
> of 2TB.
> 
> Any recommendation?
> 
> Thanks!

When asking a question like this, always shows the commands you typed
and their output. Without that we can only guess.

-Otto



  1   2   3   4   5   6   7   8   9   10   >