Copyright upper or lower case (c)?
Hi, Before I wrote this email I searched under marc.info and did a google search, but I didn't get a definitive answer. I found this under openbsd.org: https://www.openbsd.org/policy.html Whoever put that together I thank thee. In code, I see the (c) and the (C) used interchangibly, I'm wondering if it's correct. Here is an example of the ftp program in main.c: beta$ grep Copyright main.c * Copyright (C) 1997 and 1998 WIDE Project. * Copyright (c) 1985, 1989, 1993, 1994 Let me know if either is correct. I want to use it for guidance on my own project too. Where I use a lower case (c). Best Regards, -peter
collectd graphs
Hi everyone! I noticed facette became broken in 6.7. Do you guys use any neat tool to graph collectd RRDs? Preferrably in ports or at most something git-pullable but with no outside deps (relative to base or ports). Thanks for the input! Dani
Re: Copyright upper or lower case (c)?
On Tue, May 19, 2020 at 9:10 AM Peter J. Philipp wrote: > > Hi, > > Before I wrote this email I searched under marc.info and did a google search, > but I didn't get a definitive answer. I found this under openbsd.org: > > https://www.openbsd.org/policy.html > > Whoever put that together I thank thee. > > In code, I see the (c) and the (C) used interchangibly, I'm wondering if it's > correct. Here is an example of the ftp program in main.c: > > beta$ grep Copyright main.c > * Copyright (C) 1997 and 1998 WIDE Project. > * Copyright (c) 1985, 1989, 1993, 1994 > > Let me know if either is correct. I want to use it for guidance on my own > project too. Where I use a lower case (c). You might as well write "(<)" or "[C]". Neither is a copyright mark an any sense of the law, and using it does not do anything else than informing the reader that you claim the rights - you already have the rights even if you don't write anything. If you can only use ASCII, the "most proper" way would be to spell out "Copyright", but that is also just for information. As you can see, your example is using both forms.
Birthday wishes Theo
Happy birthday Theo! On your 22nd anniversary of releasing OpenBSD 2.3 Cheers, -- Craig Skinner | http://linkd.in/yGqkv7
Re: RT_TABLEID_MAX behavior changed?
it seems i figured out why userland was 'broken' on recompiled kernel
with changed RT_TABLEID_MAX.
I dont think things are really broken, may be i dont them right way, please
advice.
I could reproduce the issue (all steps are done exactly as in openbsd.org
faq).
I changed RT_TABLEID_MAX, recompiled the kernel, booted from it, and change
didnt work on userland.
Then i rebuilt userland, rebooted, all works now.
Now if i apply some patch from errata, there is kernel re-linking done, and
just after that kernel change doesnt work.
Is it expected behavior? How can i fix it? syspacth -r doesnt help.
пн, 18 мая 2020 г. в 13:31, Bars Bars :
> To be more convinient, when i said about that its limit became shorter its
> relevant to sys/net/rtable.c struct dommp.
> struct dommp {
> unsigned int limit;
> /*
> * Array to get the routing domain and loopback interface related
> to
> * a routing table. Format:
> *
> * 8 unused bits | 16 bits for loopback index | 8 bits for rdomain
> */
> unsigned int *value;
> };
>
> In past the maxumum value was limited to u_int16_t in some deep places,
> but nowadays there is only 8 bits allocated to it based on the struct + 8
> unused bits which i hop i can safely add to allocation.
> I worried these unused bits are not guaranteed to users, so actually the
> limit is 8 bits instead of 16 in earlier releases.
>
>
>
> пн, 18 мая 2020 г. в 11:51, Bars Bars :
>
>> Hi, Claudio
>>
>> I mean these in sys/socket.h
>> /*
>> * Maximum number of alternate routing tables
>> */
>> #define RT_TABLEID_MAX 8000
>> #define RT_TABLEID_BITS 16
>> #define RT_TABLEID_MASK 0x
>>
>>
>> пн, 18 мая 2020 г. в 10:18, Claudio Jeker :
>>
>>> On Sun, May 17, 2020 at 10:16:28PM +0300, Bars Bars wrote:
>>> > it seems the things work just when i rebuild userland completely (im
>>> pretty
>>> > sure i did it only with compiling kernel in past, correct me if i
>>> wrong?).
>>> >
>>> > btw, questions for the Devs.
>>> > Looking at the cvs history, i really worried that you do not expand
>>> > rt_tableid_max limit for the years, moreover now its actually 8 bits
>>> > shorter than it was before loopback to rdomain map. There are many
>>> people
>>> > with more than such a number of vpns, for example if they setup
>>> centralized
>>> > vpns setup, or border inter AS router role on the box.
>>>
>>> Sorry your mail is incredibly inprecise and unclear. There is no
>>> rt_tableid_max in OpenBSD at least not in my tree (grep -r rt_tableid_max
>>> returned nothing). So I have no idea what you are talking about and am
>>> therefor not able to give you a better answer.
>>>
>>> > вс, 17 мая 2020 г., 10:25 Bars Bars :
>>> >
>>> > > Hey, guys.
>>> > >
>>> > > I always used the rt_tableid_max expanded to 16 bit range in past
>>> releases
>>> > > 5.x and after rebuilding the kernel it worked immediately.
>>> > > But now I installed 6.6 on the new system, and after changing
>>> > > rt_tableid_max (and new rt_tableid_mask and bits values too), my
>>> whole
>>> > > userland throw an rtable / rdomain too large error.
>>> > > Is there behaviour change?
>>> > > The only thing changed (as i know) it is news net/trable.c struct to
>>> map
>>> > > loopback to domain, where there is only 8 unused bits to which i can
>>> expand
>>> > > tableid value.
>>> > >
>>> > >
>>>
>>> --
>>> :wq Claudio
>>>
>>
Re: RT_TABLEID_MAX behavior changed?
as i understand, kernel relinking currently used object file and installs
new kernel.
what i do not understand is how could it 'rollback' kernel changes done
during compilation,
if it using current object files which arre built during compilation.
Just one note, i not yet rebooted after re-linking done, because of created
domains are working (the traffic on them),
just userland does not, and im afraid they will fail to create after reboot
and i should repeat userland rebuild again.
вт, 19 мая 2020 г. в 11:21, Bars Bars :
> it seems i figured out why userland was 'broken' on recompiled kernel
> with changed RT_TABLEID_MAX.
> I dont think things are really broken, may be i dont them right way,
> please advice.
>
> I could reproduce the issue (all steps are done exactly as in openbsd.org
> faq).
> I changed RT_TABLEID_MAX, recompiled the kernel, booted from it, and
> change didnt work on userland.
> Then i rebuilt userland, rebooted, all works now.
> Now if i apply some patch from errata, there is kernel re-linking done,
> and just after that kernel change doesnt work.
> Is it expected behavior? How can i fix it? syspacth -r doesnt help.
>
>
>
> пн, 18 мая 2020 г. в 13:31, Bars Bars :
>
>> To be more convinient, when i said about that its limit became shorter
>> its relevant to sys/net/rtable.c struct dommp.
>> struct dommp {
>> unsigned int limit;
>> /*
>> * Array to get the routing domain and loopback interface related
>> to
>> * a routing table. Format:
>> *
>> * 8 unused bits | 16 bits for loopback index | 8 bits for rdomain
>> */
>> unsigned int *value;
>> };
>>
>> In past the maxumum value was limited to u_int16_t in some deep places,
>> but nowadays there is only 8 bits allocated to it based on the struct + 8
>> unused bits which i hop i can safely add to allocation.
>> I worried these unused bits are not guaranteed to users, so actually the
>> limit is 8 bits instead of 16 in earlier releases.
>>
>>
>>
>> пн, 18 мая 2020 г. в 11:51, Bars Bars :
>>
>>> Hi, Claudio
>>>
>>> I mean these in sys/socket.h
>>> /*
>>> * Maximum number of alternate routing tables
>>> */
>>> #define RT_TABLEID_MAX 8000
>>> #define RT_TABLEID_BITS 16
>>> #define RT_TABLEID_MASK 0x
>>>
>>>
>>> пн, 18 мая 2020 г. в 10:18, Claudio Jeker :
>>>
On Sun, May 17, 2020 at 10:16:28PM +0300, Bars Bars wrote:
> it seems the things work just when i rebuild userland completely (im
pretty
> sure i did it only with compiling kernel in past, correct me if i
wrong?).
>
> btw, questions for the Devs.
> Looking at the cvs history, i really worried that you do not expand
> rt_tableid_max limit for the years, moreover now its actually 8 bits
> shorter than it was before loopback to rdomain map. There are many
people
> with more than such a number of vpns, for example if they setup
centralized
> vpns setup, or border inter AS router role on the box.
Sorry your mail is incredibly inprecise and unclear. There is no
rt_tableid_max in OpenBSD at least not in my tree (grep -r
rt_tableid_max
returned nothing). So I have no idea what you are talking about and am
therefor not able to give you a better answer.
> вс, 17 мая 2020 г., 10:25 Bars Bars :
>
> > Hey, guys.
> >
> > I always used the rt_tableid_max expanded to 16 bit range in past
releases
> > 5.x and after rebuilding the kernel it worked immediately.
> > But now I installed 6.6 on the new system, and after changing
> > rt_tableid_max (and new rt_tableid_mask and bits values too), my
whole
> > userland throw an rtable / rdomain too large error.
> > Is there behaviour change?
> > The only thing changed (as i know) it is news net/trable.c struct
to map
> > loopback to domain, where there is only 8 unused bits to which i
can expand
> > tableid value.
> >
> >
--
:wq Claudio
>>>
Re: RT_TABLEID_MAX behavior changed?
Thank you much.
Do you mean i should not do syspatch if a modified kernel sources?
When reading KARL notes i tough that it only incompatible with kernel
changed
with config -e or kernel configuration file, which i did not modified.
What about kernel relinking at boot time?
Kernel changes was working after reboot, before applying syspatch.
So it seems at boot time relinking script took right base kernel to relink.
And as i understand, to fix current state it is enough if i
rebuild kernel only w/o userland?
вт, 19 мая 2020 г. в 12:41, Claudio Jeker :
> On Tue, May 19, 2020 at 11:21:13AM +0300, Bars Bars wrote:
> > it seems i figured out why userland was 'broken' on recompiled kernel
> > with changed RT_TABLEID_MAX.
> > I dont think things are really broken, may be i dont them right way,
> please
> > advice.
> >
> > I could reproduce the issue (all steps are done exactly as in
> openbsd.org
> > faq).
> > I changed RT_TABLEID_MAX, recompiled the kernel, booted from it, and
> change
> > didnt work on userland.
> > Then i rebuilt userland, rebooted, all works now.
> > Now if i apply some patch from errata, there is kernel re-linking done,
> and
> > just after that kernel change doesnt work.
> > Is it expected behavior? How can i fix it? syspacth -r doesnt help.
> >
>
> You can not syspatch a system with a custom kernel. You need to do apply
> the patches yourself. syspatch only works for non-modified kernels.
> It should actually check this by making sure that the kernel signature is
> correct so not sure what exactly happend but I guess you never properly
> installed your kernel including the relink directory and so syspatch
> relinked a default kernel over your modified one.
>
> > пн, 18 мая 2020 г. в 13:31, Bars Bars :
> >
> > > To be more convinient, when i said about that its limit became shorter
> its
> > > relevant to sys/net/rtable.c struct dommp.
> > > struct dommp {
> > > unsigned int limit;
> > > /*
> > > * Array to get the routing domain and loopback interface
> related
> > > to
> > > * a routing table. Format:
> > > *
> > > * 8 unused bits | 16 bits for loopback index | 8 bits for
> rdomain
> > > */
> > > unsigned int *value;
> > > };
> > >
> > > In past the maxumum value was limited to u_int16_t in some deep places,
> > > but nowadays there is only 8 bits allocated to it based on the struct
> + 8
> > > unused bits which i hop i can safely add to allocation.
> > > I worried these unused bits are not guaranteed to users, so actually
> the
> > > limit is 8 bits instead of 16 in earlier releases.
> > >
> > >
> > >
> > > пн, 18 мая 2020 г. в 11:51, Bars Bars :
> > >
> > >> Hi, Claudio
> > >>
> > >> I mean these in sys/socket.h
> > >> /*
> > >> * Maximum number of alternate routing tables
> > >> */
> > >> #define RT_TABLEID_MAX 8000
> > >> #define RT_TABLEID_BITS 16
> > >> #define RT_TABLEID_MASK 0x
> > >>
> > >>
> > >> пн, 18 мая 2020 г. в 10:18, Claudio Jeker :
> > >>
> > >>> On Sun, May 17, 2020 at 10:16:28PM +0300, Bars Bars wrote:
> > >>> > it seems the things work just when i rebuild userland completely
> (im
> > >>> pretty
> > >>> > sure i did it only with compiling kernel in past, correct me if i
> > >>> wrong?).
> > >>> >
> > >>> > btw, questions for the Devs.
> > >>> > Looking at the cvs history, i really worried that you do not expand
> > >>> > rt_tableid_max limit for the years, moreover now its actually 8
> bits
> > >>> > shorter than it was before loopback to rdomain map. There are many
> > >>> people
> > >>> > with more than such a number of vpns, for example if they setup
> > >>> centralized
> > >>> > vpns setup, or border inter AS router role on the box.
> > >>>
> > >>> Sorry your mail is incredibly inprecise and unclear. There is no
> > >>> rt_tableid_max in OpenBSD at least not in my tree (grep -r
> rt_tableid_max
> > >>> returned nothing). So I have no idea what you are talking about and
> am
> > >>> therefor not able to give you a better answer.
> > >>>
> > >>> > вс, 17 мая 2020 г., 10:25 Bars Bars :
> > >>> >
> > >>> > > Hey, guys.
> > >>> > >
> > >>> > > I always used the rt_tableid_max expanded to 16 bit range in past
> > >>> releases
> > >>> > > 5.x and after rebuilding the kernel it worked immediately.
> > >>> > > But now I installed 6.6 on the new system, and after changing
> > >>> > > rt_tableid_max (and new rt_tableid_mask and bits values too), my
> > >>> whole
> > >>> > > userland throw an rtable / rdomain too large error.
> > >>> > > Is there behaviour change?
> > >>> > > The only thing changed (as i know) it is news net/trable.c
> struct to
> > >>> map
> > >>> > > loopback to domain, where there is only 8 unused bits to which i
> can
> > >>> expand
> > >>> > > tableid value.
> > >>> > >
> > >>> > >
> > >>>
> > >>> --
> > >>> :wq Claudio
> > >>>
> > >>
>
> --
> :wq Claudio
>
mfs mount loosing permissions on -current
Hi, sounds strange, but is anyone else seeing mfs mounted fs loosing permissions after reboot in -current (12h old)? I saw lots of permission denied errors for /tmp while trying to build via dpb. Reason was /tmp mounted 755 after boot. # chmod 1777 /tmp; ls -l / drwxrwxrwt 6 root wheel 512 May 19 12:42 tmp # mount mfs:66540 on /tmp type mfs (asynchronous, local, nodev, nosuid, size=1048576 512 -blocks) reboot... # ls -l / drwxr-xr-x 6 root wheel 512 May 19 12:43 tmp # mount mfs:66540 on /tmp type mfs (asynchronous, local, nodev, nosuid, size=1048576 512 -blocks) No issues on a 6 days old -current. -- Mark Patruck ( mark at wrapped.cx ) GPG key 0xF2865E51 / 187F F6D3 EE04 1DCE 1C74 F644 0D3C F66F F286 5E51 https://www.wrapped.cx
Re: RT_TABLEID_MAX behavior changed?
On Tue, May 19, 2020 at 11:21:13AM +0300, Bars Bars wrote:
> it seems i figured out why userland was 'broken' on recompiled kernel
> with changed RT_TABLEID_MAX.
> I dont think things are really broken, may be i dont them right way, please
> advice.
>
> I could reproduce the issue (all steps are done exactly as in openbsd.org
> faq).
> I changed RT_TABLEID_MAX, recompiled the kernel, booted from it, and change
> didnt work on userland.
> Then i rebuilt userland, rebooted, all works now.
> Now if i apply some patch from errata, there is kernel re-linking done, and
> just after that kernel change doesnt work.
> Is it expected behavior? How can i fix it? syspacth -r doesnt help.
>
You can not syspatch a system with a custom kernel. You need to do apply
the patches yourself. syspatch only works for non-modified kernels.
It should actually check this by making sure that the kernel signature is
correct so not sure what exactly happend but I guess you never properly
installed your kernel including the relink directory and so syspatch
relinked a default kernel over your modified one.
> пн, 18 мая 2020 г. в 13:31, Bars Bars :
>
> > To be more convinient, when i said about that its limit became shorter its
> > relevant to sys/net/rtable.c struct dommp.
> > struct dommp {
> > unsigned int limit;
> > /*
> > * Array to get the routing domain and loopback interface related
> > to
> > * a routing table. Format:
> > *
> > * 8 unused bits | 16 bits for loopback index | 8 bits for rdomain
> > */
> > unsigned int *value;
> > };
> >
> > In past the maxumum value was limited to u_int16_t in some deep places,
> > but nowadays there is only 8 bits allocated to it based on the struct + 8
> > unused bits which i hop i can safely add to allocation.
> > I worried these unused bits are not guaranteed to users, so actually the
> > limit is 8 bits instead of 16 in earlier releases.
> >
> >
> >
> > пн, 18 мая 2020 г. в 11:51, Bars Bars :
> >
> >> Hi, Claudio
> >>
> >> I mean these in sys/socket.h
> >> /*
> >> * Maximum number of alternate routing tables
> >> */
> >> #define RT_TABLEID_MAX 8000
> >> #define RT_TABLEID_BITS 16
> >> #define RT_TABLEID_MASK 0x
> >>
> >>
> >> пн, 18 мая 2020 г. в 10:18, Claudio Jeker :
> >>
> >>> On Sun, May 17, 2020 at 10:16:28PM +0300, Bars Bars wrote:
> >>> > it seems the things work just when i rebuild userland completely (im
> >>> pretty
> >>> > sure i did it only with compiling kernel in past, correct me if i
> >>> wrong?).
> >>> >
> >>> > btw, questions for the Devs.
> >>> > Looking at the cvs history, i really worried that you do not expand
> >>> > rt_tableid_max limit for the years, moreover now its actually 8 bits
> >>> > shorter than it was before loopback to rdomain map. There are many
> >>> people
> >>> > with more than such a number of vpns, for example if they setup
> >>> centralized
> >>> > vpns setup, or border inter AS router role on the box.
> >>>
> >>> Sorry your mail is incredibly inprecise and unclear. There is no
> >>> rt_tableid_max in OpenBSD at least not in my tree (grep -r rt_tableid_max
> >>> returned nothing). So I have no idea what you are talking about and am
> >>> therefor not able to give you a better answer.
> >>>
> >>> > вс, 17 мая 2020 г., 10:25 Bars Bars :
> >>> >
> >>> > > Hey, guys.
> >>> > >
> >>> > > I always used the rt_tableid_max expanded to 16 bit range in past
> >>> releases
> >>> > > 5.x and after rebuilding the kernel it worked immediately.
> >>> > > But now I installed 6.6 on the new system, and after changing
> >>> > > rt_tableid_max (and new rt_tableid_mask and bits values too), my
> >>> whole
> >>> > > userland throw an rtable / rdomain too large error.
> >>> > > Is there behaviour change?
> >>> > > The only thing changed (as i know) it is news net/trable.c struct to
> >>> map
> >>> > > loopback to domain, where there is only 8 unused bits to which i can
> >>> expand
> >>> > > tableid value.
> >>> > >
> >>> > >
> >>>
> >>> --
> >>> :wq Claudio
> >>>
> >>
--
:wq Claudio
Re: [www] wrong release date of rpki-client 6.6p2
The same thing, but for 6.7p0. Cheers, Alex On Mon, May 18, 2020 at 2:54 PM Alex Naumov wrote: > Hey, > there is a typo on /cvs/www/rpki-client/portable.html > > Cheers, > Alex > Index: rpki-client-portable.html.head === RCS file: /cvs/www/build/mirrors/rpki-client-portable.html.head,v retrieving revision 1.6 diff -u -p -r1.6 rpki-client-portable.html.head --- rpki-client-portable.html.head 18 May 2020 14:25:41 - 1.6 +++ rpki-client-portable.html.head 19 May 2020 10:32:56 - @@ -18,7 +18,7 @@ Portable Release -rpki-client 6.6p2 portable: released April 19, 2020 +rpki-client 6.7p0 portable: released May 18, 2020 The portable version of rpki-client adds support for other Unix flavors by adding
Re: mfs mount loosing permissions on -current
On 2020-05-19, Mark Patruck wrote: > Hi, > > sounds strange, but is anyone else seeing mfs mounted fs > loosing permissions after reboot in -current (12h old)? Problem tracked down, diff is on bugs@. > > I saw lots of permission denied errors for /tmp while > trying to build via dpb. Reason was /tmp mounted 755 > after boot. > > # chmod 1777 /tmp; ls -l / > drwxrwxrwt 6 root wheel 512 May 19 12:42 tmp > # mount > mfs:66540 on /tmp type mfs (asynchronous, local, nodev, nosuid, size=1048576 > 512 > -blocks) > > reboot... > > # ls -l / > drwxr-xr-x 6 root wheel 512 May 19 12:43 tmp > # mount > mfs:66540 on /tmp type mfs (asynchronous, local, nodev, nosuid, size=1048576 > 512 > -blocks) > > No issues on a 6 days old -current. >
Re: RT_TABLEID_MAX behavior changed?
Bars Bars wrote: > Thank you much. > > Do you mean i should not do syspatch if a modified kernel sources? syspatches can deliver replacements for kernel .o files So if you have changed a .h or .c file, the syspatches are not going to work correctly. Once you use source-code methods, you can't use those binary methods.
Re: mfs mount loosing permissions on -current
On 2020-05-19 13:45, Stuart Henderson wrote: On 2020-05-19, Mark Patruck wrote: Hi, sounds strange, but is anyone else seeing mfs mounted fs loosing permissions after reboot in -current (12h old)? Problem tracked down, diff is on bugs@. Thanks. Missed that one. I saw lots of permission denied errors for /tmp while trying to build via dpb. Reason was /tmp mounted 755 after boot. # chmod 1777 /tmp; ls -l / drwxrwxrwt 6 root wheel 512 May 19 12:42 tmp # mount mfs:66540 on /tmp type mfs (asynchronous, local, nodev, nosuid, size=1048576 512 -blocks) reboot... # ls -l / drwxr-xr-x 6 root wheel 512 May 19 12:43 tmp # mount mfs:66540 on /tmp type mfs (asynchronous, local, nodev, nosuid, size=1048576 512 -blocks) No issues on a 6 days old -current. -- Mark Patruck ( mark at wrapped.cx ) GPG key 0xF2865E51 / 187F F6D3 EE04 1DCE 1C74 F644 0D3C F66F F286 5E51 https://www.wrapped.cx
Re: Why isn't src included with OpenBSD? (documentation)
On Mon, May 18, 2020 at 08:43:19PM +0100, Ottavio Caruso wrote: > Some of these documents have a proprietary licence attached to it and > I believe it's due to the 1994 AT settlement. There are third party > collections (like this: https://github.com/sergev/4.4BSD-Lite2) but > I'm not sure if one could import them all in the source tree or in the > ports tree without violating some copyright here and there. If the README.md is accurate, that could be imported in the ports tree, but there would be a lot of work to extract useful stuff from there. Looks like a standard 4-clauses old-style BSD licence. I've had a look, and it is very strange, some of the PSD documents have been converted to pdf, BUT not all of them. There are also no actual releases, so you'd have to pull a specific tag from github, always hasardous...
Re: i386 kernel relinking
On Fri, Apr 10, 2020 at 10:25:14AM -0400, Nick Holland wrote: > On 2020-04-10 10:10, Stefan Sperling wrote: > > On Fri, Apr 10, 2020 at 09:35:16AM -0400, Nick Holland wrote: > > FWIW, my soekris net5501 with 256MB of RAM and 512MB swap does manage > > to relink a kernel (on 6.6 + syspatches). > > Whoops. Guess I should have mentioned, that was -current, as of > yesterday > OpenBSD 6.7-beta (GENERIC.MP) #110: Thu Apr 9 01:20:52 MDT 2020 > dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP > real mem = 334970880 (319MB) > avail mem = 313077760 (298MB) > > and probably a couple weeks ago for the real (old) hw. > > I'm curious if your Soekris can handle 6.7-beta. > > Nick. It's been fixed in 6.7 release! This was indeed a problem on my alix and soekris machines for a while. And I could also reproduce it in a 6.7-beta low memory VM as you did. I attempted to debug ld.lld for a while but eventually gave up (debugging the linker is quite painful). I did not come to any conclusion but did notice that ld.lld uses mmap to write ELF data to the output file. That file always ended up being corrupt under low memory conditions. The old ld.bfd linker uses stdio and worked OK. With 6.7 kernel relinking with little amounts of memory suddenly started working again. To make sure I'm not dreaming I bisected the commit which fixed it. Turns out this problem was fixed by beck@ in the commit below. I can even relink kernels on i386 in 64MB of RAM now. Didn't test lower than that. Case closed. Just upgrade to 6.7 and it'll be fine :-) CVSROOT:/cvs Module name:src Changes by: b...@cvs.openbsd.org2020/04/28 20:25:48 Modified files: sys/kern : vfs_bio.c Log message: Ensure that if we are doing a delayed write with a NOCACHE buffer, we clear the NOCACHE flag, since if we are doing a delayed write the buffer must be cached or it is thrown away when the "write" is done. fixes vnd on mfs regress tests. ok kettenis@ deraadt@
Re: i386 kernel relinking
On Tue, May 19, 2020 at 05:21:59PM +0200, Stefan Sperling wrote: > On Fri, Apr 10, 2020 at 10:25:14AM -0400, Nick Holland wrote: > > On 2020-04-10 10:10, Stefan Sperling wrote: > > > On Fri, Apr 10, 2020 at 09:35:16AM -0400, Nick Holland wrote: > > > FWIW, my soekris net5501 with 256MB of RAM and 512MB swap does manage > > > to relink a kernel (on 6.6 + syspatches). > > > > Whoops. Guess I should have mentioned, that was -current, as of > > yesterday > > OpenBSD 6.7-beta (GENERIC.MP) #110: Thu Apr 9 01:20:52 MDT 2020 > > dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP > > real mem = 334970880 (319MB) > > avail mem = 313077760 (298MB) > > > > and probably a couple weeks ago for the real (old) hw. > > > > I'm curious if your Soekris can handle 6.7-beta. > > > > Nick. > > It's been fixed in 6.7 release! Thank you!!! Awesome!!!
Re: RT_TABLEID_MAX behavior changed?
thanks, i got it. so probably i should manually patch, recompile and install kernel again. Then should i care about boot time kernel re-linking if i have such a custom kernel? Claudio, please, do not forget to advice with the question about RT_TABLEID_MAX itself, i hope i clarified you what im talking about. if not, ask me please. вт, 19 мая 2020 г. в 15:05, Theo de Raadt : > Bars Bars wrote: > > > Thank you much. > > > > Do you mean i should not do syspatch if a modified kernel sources? > > syspatches can deliver replacements for kernel .o files > > So if you have changed a .h or .c file, the syspatches are not > going to work correctly. > > Once you use source-code methods, you can't use those binary > methods. >
upgrade 6.6 -> 6.7
Hi, just for info: Upgrading from 6.6 to 6.7 worked without flaws on my OpenBSD VMs on Linux/KVM and FreeBSD/bhyve hypervisors! 6.7 feels faster and snappier! Thanks to you all for your hard work! Regards, infoomatic
Re: Why isn't src included with OpenBSD? (documentation)
On Tue, 19 May 2020 at 13:31, Marc Espie wrote: > > On Mon, May 18, 2020 at 08:43:19PM +0100, Ottavio Caruso wrote: > > Some of these documents have a proprietary licence attached to it and > > I believe it's due to the 1994 AT settlement. There are third party > > collections (like this: https://github.com/sergev/4.4BSD-Lite2) but > > I'm not sure if one could import them all in the source tree or in the > > ports tree without violating some copyright here and there. > > If the README.md is accurate, that could be imported in the ports tree, > but there would be a lot of work to extract useful stuff from there. > > Looks like a standard 4-clauses old-style BSD licence. > > I've had a look, and it is very strange, some of the PSD documents have > been converted to pdf, BUT not all of them. That's because of the legal proviso, as below. > > There are also no actual releases, so you'd have to pull a specific tag > from github, always hasardous... Not sure if it's safe import from that project, as it lacks all the legal proviso, like this for example: https://svnweb.freebsd.org/base/head/share/doc/psd/title/Title?revision=307807=co=307807 As long as I know, the FreeBSD SVN has all the PSD, SMM and USD source tree that can be used legally. How one makes an OpenBSD ports from that, I don't know: https://svnweb.freebsd.org/base/head/share/doc/ -- Ottavio Caruso
Re: net.inet.ip6.forwarding=1 ?
On Tue, May 19, 2020 at 08:36:56PM +0200, Harald Dunkel wrote: > Hi folks, > > congrats to the new release. > > Question about https://www.openbsd.org/faq/upgrade67.html: > Shouldn't it be > > net.inet.ip.forwarding=1 > net.inet6.ip6.forwarding=1 > > Thats what I found in my sysctl.conf (before upgrade). > Fixed, thank you.
Re: Why isn't src included with OpenBSD? (documentation)
> Proposed release poster design: > Puffy with puffed out cheeks & paper sticking out of his mouth. > Headline: "Man pages are all you need to live!" > Alternate headlines: > "We *can* live on man pages alone!" I think it's better to clarify who this "we" is/are. Not _all_ needed info for install and usage is in the man, but I think it was not the intent to crowd _all_ the info there.
net.inet.ip6.forwarding=1 ?
Hi folks, congrats to the new release. Question about https://www.openbsd.org/faq/upgrade67.html: Shouldn't it be net.inet.ip.forwarding=1 net.inet6.ip6.forwarding=1 Thats what I found in my sysctl.conf (before upgrade). Regards Harri
Re: collectd graphs
Levai, Daniel wrote: > Hi everyone! > > I noticed facette became broken in 6.7. Do you guys use any neat tool to > graph collectd RRDs? Preferably in ports or at most something > git-pullable but with no outside deps (relative to base or ports). > > Thanks for the input! > > Dani Hi Dani, Before I replay to your question just as a side note. This is not really OpenBSD related question so please feel free to send me a private email if you want to discuss this further instead of bothering everyone. The lack of decent front-end is really achilles tendon of Collectd. Even the website https://collectd.org/wiki/index.php/List_of_front-ends is grossly outdated. The net/librenms port https://openports.pl/path/net/librenms is your best bet. LibreNMS is SNMP-based network monitoring system written in PHP and requires MySQL database. It is a fork of Observium. https://www.observium.org/ While Observium/LibreNMS primary focus is on monitoring SNMP capable devices both can can integrate with Collectd to show graphs drawn from Collectd modules in the web interface. https://docs.observium.org/collectd/ I use Observium running of Ubuntu 16.04 to monitor a smallish infrastructure consisting of about 100 devices. I monitor through SNMP pretty much everything you can think of: batteries on UPSs, electric consumption of GPU computing nodes via switched PDUs monitoring, managed switches, servers, named it. In addition to SNMP polling, I also run Collectd on all my production servers (about 70 Open/Free BSD infrastructure and Red Hat computing nodes) and push RRDs to the centralized Observium server. Observium automatically build incredibly pretty and informative graphs from RRDs. You don't need to build your own dashboards like with Grafana (IIRC facette requires to build your own dashboards and it is not even very good). On Red Hat where Collectd IPMI plugin actually works you also get those nice IPMI graphs. I tried to run LibreNMS of OpenBSD kernel on bare metal. It was just too sluggish and web interface was not really usable comparing to Observium on Ubuntu. I never really bothered to troubleshoot the problem. It could be that LibreNMS at that time was just not polished enough (they were much more agressive in adding features than Observium free community edition). It could be the file system performance. I tried using both SSD and spinning drives but no big difference. I tried memcached and few other things. If you search through misc archive with keyword LibreNMS you will see bunch of my posts and developers/users who were trying to help. Observium is officially(per alpha male Adam Armstrong) is designed to run only designed to run on Ubuntu or Debian and my experience confirms that. My Observiu/Ubuntu runs as DomU on Alpine Linux Xen Dom0 instance. I do use raw SSD block devices as a storage. Network interface is 1 Gigabit and even though I have 10 Gigabit card and 10 Gigabit network I didn't bother to upgrade. Before I wrap up this long email I would like to bring to your attention another option. Instead of directly drawing Collectd RRDs you can use carbon or gmond plugin https://collectd.org/wiki/index.php/Plugin:Carbon https://collectd.org/wiki/index.php/Plugin:gmond to feed collectd into Graphite or Ganglia. I vaguely remember playing with Graphite plugin but I lost enthusiasm after realizing that I will have to build by custom dashboards. Jason Dixon who wrote a book on Monitoring with Graphite should be luring around here so he might be able to pitch a bit. I never tried running Ganglia on OpenBSD as it is not in official ports tree. Just as a final note, if you are doing this to monitor few devices in your home lab you are way above your head. While all I said is trivial I would have never done it if somebody was not paying for it. There are far simpler ways to accomplish above on a small home network. Best, Predrag
Re: Why isn't src included with OpenBSD? (documentation)
First of all, I'd like to thank everyone who replied to me! Thank you for explaining things. On Mon, May 18, 2020 at 2:59 PM Ingo Schwarze wrote: > Andras Farkas wrote on Mon, May 18, 2020 at 01:07:36PM -0400: > > For example, I first learnt vi a few years ago, back > > when I was first learning Unix, with these files: > > https://cvsweb.openbsd.org/src/usr.bin/vi/docs/tutorial/ > > Hum, looks like a reference to those files is indeed missing > from the manual page. > > Also, i don't see what would be wrong with installing them to > /usr/share/doc/vi/tutorial/ > Yes, the tutorial is painfully slow and extremely wordy, and some > parts are hilariously antiquated, like this: > "Learning a new computer system implies learning a new text editor." > That wasn't even accurate at the time it was presumably written, > probably around 4.4BSD (i.e. almost 30 years ago). It may have > been more or less true 40 years ago, though. I'd say that sentence still contains some truth: when someone's trying out OpenBSD as a desktop OS when they've only used Windows as a desktop OS before... > Can somebody work through the tutorial and confirm that everything > still works as described with our -current vi(1)? It is too > wordy for my personal taste, so i would hate having to read it all. I can do this. I'll begin sometime this week, and send a report on it, and a diff too if necessary. I'd love to see it included. :D On Mon, May 18, 2020 at 3:01 PM Marc Espie wrote: > On Mon, May 18, 2020 at 01:07:36PM -0400, Andras Farkas wrote: > > I saw in fsck_ffs.8 > > https://man.openbsd.org/fsck_ffs.8 > > that the answers could be found in > > Fsck_ffs - The UNIX File System Check Program > > This is perfectly fine. Not every piece of information belongs in a > > man page. Man pages are the right format for some sorts of info, and > > absolutely the wrong format for some other sorts. > > BUT: I looked and couldn't find it, and ended up using > > https://docs.freebsd.org/44doc/smm/03.fsck/paper.pdf > > which is where I found my answer. > > Only after I already solved the problem did I find that the mentioned > > file exists here: > > https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sbin/fsck_ffs/SMM.doc/ > Most of these files haven't been updated in ages. That is true, and important. > Seriously, *none* of those files are necessary *for beginners*. Once you > reach the stage where you might benefit from them (say, because you actually > want to become a developer, and could learn from worse sources), you should > be able to figure out how to get them. I disagree. In general: man pages are reference material (meant for people who are already familiar with unix or with the man page's topic, often not meant to be read cover to cover, definitely doesn't hold your hand) and in contrast, a considerable amount of the documentation (though certainly not all!) in /usr/src is tutorial material (meant for learning something for the first time, easily read cover to cover, holds your hand) usable by newbs. Examples supporting this comparison: man 1 ed versus the Brian W. Kernighan "A Tutorial Introduction to the UNIX Text Editor" man 1 yacc versus the Stephen C. Johnson Yacc "Yacc: Yet Another Compiler-Compiler" man 1 vi versus vi.beginner (though indeed, vi.1 has the Fast Startup section, vi.1 is an exception rather than the norm) Just looking at a list of BSD USD (UNIX User's Supplementary Documents) documents or Unix v7 supplementary documents (The UNIX Programmer's Manual volume 2) can provide more examples. Some of them don't particularly have a man page they match up to, by being broader and more newb-oriented in theme. The only point against this, though a BIG and important one, is that the datedness of the tutorial materials does make them less usable for newbs. I agree much of the stuff is outdated and less usable than it used to be. I also think having it with a disclaimer is better than not having it at all. Ideally... I myself should put in effort into checking some of them and fixing and updating them. Also: I do like OpenBSD's man pages and FAQ! Don't let anything I've said above convince you otherwise. I use them a lot and appreciate them. Thanks so much, everybody.
Re: upgrade 6.6 -> 6.7
On Tue, 19 May 2020 at 17:39, infoomatic wrote: > > Hi, > > just for info: Upgrading from 6.6 to 6.7 worked without flaws on my > OpenBSD VMs on Linux/KVM and FreeBSD/bhyve hypervisors! 6.7 feels faster > and snappier! Thanks to you all for your hard work! You might want to share how you did it. bsd.rd, sysupgrade, manual upgrade? -- Ottavio Caruso
OpenBSD 6.7 - uncommon behavior
Hello guys. Today, I've installed OpenBSD 6.7 on Windows 10 pro ( Hyper-V ) which I already has 6.6 running very well. So, the planning was: Migrate my conf's, turn off my 6.6 and make use of 6.7. 1 - By default hyper-v add's one processor. In the end of my fresh install it doesn't work ( tried two times ) ( My NTFS has 1M alignment ) - doesn't work = not boot 2 - I've recreated the VM and add two processors. It booted and I have installed some packages: pkg_add vim pkg_add tor pkg_add curl and pkg_add openvpn shutdown ( disks were synced ) Add additional network card and then Power ON again. ( with a lot of errors on filesystem ) My /etc/group file just get blank. Regards,
Re: using aggr interface instead of trunk
> On 14 May 2020, at 4:22 pm, mabi wrote: > > Hi Iain, > > ‐‐‐ Original Message ‐‐‐ > On Wednesday, May 13, 2020 7:55 PM, Iain R. Learmonth wrote: > >> More details are at:https://marc.info/?l=openbsd-cvs=156229058006706=2 > > I actually already read that one after seeing the announcement on > undeadly.org iirc ;) > >> Assuming you mean trunk, not tun, yes. > > Right, thanks for spotting that, I meant trunk of course. > >> I don't see mention of any aggr fixes in the 6.7 changelog, so I guess it >> didn't have any disasters in it. Others are using it on production systems. > > Nice to hear that, I will give it a shot as soon as I upgrade to 6.6 my HA > CARP cluster of two OpenBSD firewalls. I might first try using it on one of > the two firewalls so that I can easily switch to the other firewall in any > case of issue. I would wait for 6.7 before using aggr(4) in production. Considering 6.7 is out now, there's no reason not to use it instead of 6.6. dlg
