kqueue

[Friedrich Locke]

Hi Folks,

am i wrong or kqueue support for socket descriptor  is limited to 2 ^ 16 
open sockets ?


Thanks in advance.

Lumina enable Shut Down

[Sha'ul]

In Lumina desktop how do I enable shutdown from GUI menu for point and
click poweroff and reboot?

Re: Read sysctl from file

[Theo de Raadt]

Peter, please leave.  People around here don't need to read your
insults.
 

Re: Read sysctl from file

[Peter Faiman]

> On Jul 21, 2017, at 1:30 PM, Mihai Popescu  wrote:
> 
>> Also it does not fail halfway, it will report errors for each of the 
>> settings that cannot  > be applied,
> 
> So Peter, just to check if i got it right, you did a script who
> reports errors about things people knows in advance they will generate
> errors, that despite the warnings that the concept is wrong from the
> start till the end.
> 
> Nice, I remember about a Dilbert situation, but I'm too lazy to search for it.

Yes, my script reports errors. Since apparently everyone knows in advance
which sysctls will produce errors, it is bad for me to report them? Is that
what you're saying?

Well then you should submit a patch to /sbin/sysctl that stops reporting
errors. After all, as you say, "people knows in advance they will generate
errors.” Now THAT is a Dilbert situation.

Peter

Re: Read sysctl from file

[Theo de Raadt]

> > On Jul 21, 2017, at 3:42 PM, li...@wrant.com wrote:
> >=20
> > Fri, 21 Jul 2017 12:33:31 -0700 Peter Faiman 
> >> # ./sysctl -p example.conf
> >> Peter
> >=20
> > Hi Peter, ansibles,
> >=20
> > No guarantee systems controls stay affixed, wrapper tools comply got =
> it?
> 
> The point of sysctl -p is reloading from a file. So that you put controls in
> the file and load that file, exactly as happens in system startup. The whole
> point is to ensure consistency with system startup. True, securelevel throws
> a bit of a wrench in that, but this works for all other settings.

We don't have -p.

It is an addition made by a foreign system which barely uses sysctl,
and has been acting for years like they will be removing support.

THERE IS NO SUPPORT FOR -p.

It is unlikely to happen.

Let's just stop this.  You just aren't capable of listening to what
is being said.  Also, you are ridiculously rude.

Re: Read sysctl from file

[Peter Faiman]

> On Jul 21, 2017, at 3:42 PM, li...@wrant.com wrote:
> 
> Fri, 21 Jul 2017 12:33:31 -0700 Peter Faiman 
>> # ./sysctl -p example.conf
>> Peter
> 
> Hi Peter, ansibles,
> 
> No guarantee systems controls stay affixed, wrapper tools comply got it?

The point of sysctl -p is reloading from a file. So that you put controls in
the file and load that file, exactly as happens in system startup. The whole
point is to ensure consistency with system startup. True, securelevel throws
a bit of a wrench in that, but this works for all other settings.

> Wrap around as advised for a system operator, don't push for short cuts.

It’s not a short cut. Ansible wants sysctl -p, I implemented sysctl -p
exactly as Linux does it, using the OpenBSD /etc/rc code that actually
applies sysctls from /etc/sysctl.conf.

I never said anyone should use Ansible. I don't use it, I don't like it. But
clearly this person is going to use it, so I might as well give them
something that will do what they want, even if I don't agree with it.

> Please, stop imposing your designs on our systems wasting precious time.

I'm not imposing my designs on anyone. Someone on the mailing list needed
the exact Linux behavior, so I spent 5 minutes on the train to work writing
and testing a compatible tool.

I already _specifically_ said I wrote a wrapper this way because it's the
easiest way to be compatible without changing ANY OpenBSD code, or ANYTHING
else about the OpenBSD system. In other words I deliberately chose to solve
this problem in a way that imposes NOTHING on anyone else.

> Kind regards,

You should stop putting this at the bottom of your emails if you think it's
acceptable to talk to others this way. When you send out half-baked
responses that clearly demonstrate you did not bother to read what I said,
you're the one wasting my time.

Peter

Re: Read sysctl from file

[lists]

Fri, 21 Jul 2017 12:33:31 -0700 Peter Faiman 
> # ./sysctl -p example.conf
> Peter

Hi Peter, ansibles,

No guarantee systems controls stay affixed, wrapper tools comply got it?
Wrap around as advised for a system operator, don't push for short cuts.
Please, stop imposing your designs on our systems wasting precious time.

Kind regards,
Anton Lazarov

Re: Read sysctl from file

[Mihai Popescu]

> Also it does not fail halfway, it will report errors for each of the settings 
> that cannot  > be applied,

So Peter, just to check if i got it right, you did a script who
reports errors about things people knows in advance they will generate
errors, that despite the warnings that the concept is wrong from the
start till the end.

Nice, I remember about a Dilbert situation, but I'm too lazy to search for it.

Re: Read sysctl from file

[Peter Faiman]

> On Jul 21, 2017, at 12:22 PM, Theo de Raadt  wrote:
> 
>>> On Jul 21, 2017, at 3:47 AM, Stuart Henderson  =
>> wrote:
>>> =20
>>> On 2017-07-20, BARDOU Pierre  wrote:
 Is there a way to make sysctl re-read its conf file, or even another =
>> file, like sysctl -p does on linux systems ?
 Supporting this option would be nice, as it is used by the sysctl =
>> module of ansible.
>>> =20
>>> Sounds risky. It won't reset default values thag are unspecified in
>>> sysctl.conf, so you could be sitting on a configuration that appears =
>> ok,
>>> but will fail after a reboot.
>> 
>> Stuart makes a good point. So does Theo, adding -p to the sysctl binary =
>> when
>> it doesn't currently do any file handling at all seems extreme. So I =
>> wrote a
>> wrapper script that emulates Linux sysctl -p. I put very simple =
>> directions
>> at the top of the file. Find it here:
>> 
>> https://gist.github.com/PeterFaiman/5b67c530b0ffa009ebef904ed0678e26
>> 
>> Ideally these tools wouldn't use Linux-specific features. But emulating
>> simple features like sysctl -p in a non-invasive way isn't too hard.
> 
> One more point to add:
> 
> Some setting can only be changed before securelevel.  They fail afterwards.
> 
> I'd say the entire approach is wrong, because it cannot tell them apart.
> It will fail halfway.
> 
> It was obviously written by people who don't care.

True, there is no way to get around the securelevel problem without
rebooting, by definition. But if this MUST be done with these workflow
constraints, I think this is the "best" way to do it.

Also it does not fail halfway, it will report errors for each of the
settings that cannot be applied, e.g. with a config that sets
kern.securelevel=0 and net.inet.udp.sendspace=9216, this happens:

# ./sysctl -p example.conf
sysctl: kern.securelevel: Operation not permitted
net.inet.udp.sendspace: 9216 -> 9216

Peter

Re: Read sysctl from file

[Theo de Raadt]

> > On Jul 21, 2017, at 3:47 AM, Stuart Henderson  =
> wrote:
> >=20
> > On 2017-07-20, BARDOU Pierre  wrote:
> >> Is there a way to make sysctl re-read its conf file, or even another =
> file, like sysctl -p does on linux systems ?
> >> Supporting this option would be nice, as it is used by the sysctl =
> module of ansible.
> >=20
> > Sounds risky. It won't reset default values thag are unspecified in
> > sysctl.conf, so you could be sitting on a configuration that appears =
> ok,
> > but will fail after a reboot.
> 
> Stuart makes a good point. So does Theo, adding -p to the sysctl binary =
> when
> it doesn't currently do any file handling at all seems extreme. So I =
> wrote a
> wrapper script that emulates Linux sysctl -p. I put very simple =
> directions
> at the top of the file. Find it here:
> 
> https://gist.github.com/PeterFaiman/5b67c530b0ffa009ebef904ed0678e26
> 
> Ideally these tools wouldn't use Linux-specific features. But emulating
> simple features like sysctl -p in a non-invasive way isn't too hard.

One more point to add:

Some setting can only be changed before securelevel.  They fail afterwards.

I'd say the entire approach is wrong, because it cannot tell them apart.
It will fail halfway.

It was obviously written by people who don't care.

Re: Read sysctl from file

[Peter Faiman]

> On Jul 21, 2017, at 3:47 AM, Stuart Henderson  wrote:
> 
> On 2017-07-20, BARDOU Pierre  wrote:
>> Is there a way to make sysctl re-read its conf file, or even another file, 
>> like sysctl -p does on linux systems ?
>> Supporting this option would be nice, as it is used by the sysctl module of 
>> ansible.
> 
> Sounds risky. It won't reset default values thag are unspecified in
> sysctl.conf, so you could be sitting on a configuration that appears ok,
> but will fail after a reboot.

Stuart makes a good point. So does Theo, adding -p to the sysctl binary when
it doesn't currently do any file handling at all seems extreme. So I wrote a
wrapper script that emulates Linux sysctl -p. I put very simple directions
at the top of the file. Find it here:

https://gist.github.com/PeterFaiman/5b67c530b0ffa009ebef904ed0678e26

Ideally these tools wouldn't use Linux-specific features. But emulating
simple features like sysctl -p in a non-invasive way isn't too hard.

Peter

Re: Disk I/O performance of OpenBSD 5.9 on Xen

[Mike Belopuhov]

On Fri, Jul 21, 2017 at 09:15 -0400, Maxim Khitrov wrote:
> On Sat, Jul 16, 2016 at 6:37 AM, Mike Belopuhov  wrote:
> > On 14 July 2016 at 14:54, Maxim Khitrov  wrote:
> >> On Wed, Jul 13, 2016 at 11:47 PM, Tinker  wrote:
> >>> On 2016-07-14 07:27, Maxim Khitrov wrote:
> >>> [...]
> 
>  No, the tests are run sequentially. Write performance is measured
>  first (20 MB/s), then rewrite (12 MB/s), then read (37 MB/s), then
>  seeks (95 IOPS).
> >>>
> >>>
> >>> Okay, you are on a totally weird platform. Or, on an OK platform with a
> >>> totally weird configuration.
> >>>
> >>> Or on an OK platform and configuration with a totally weird underlying
> >>> storage device.
> >>>
> >>> Are you on a magnet disk, are you using a virtual block device or virtual
> >>> SATA connection, or some legacy interface like IDE?
> >>>
> >>> I get some feeling that your hardware + platform + configuration 
> >>> crappiness
> >>> factor is fairly much through the ceiling.
> >>
> >> Dell R720 and R620 servers, 10 gigabit Ethernet SAN, Dell MD3660i
> >> storage array, 1.2 TB 10K RPM SAS disks in RAID6. I don't think there
> >> is anything crappy or weird about the configuration. Test results for
> >> CentOS on the same system: 170 MB/s write, 112 MB/s rewrite, 341 MB/s
> >> read, 746 IOPS.
> >>
> >> I'm assuming that there are others running OpenBSD on Xen, so I was
> >> hoping that someone else could share either bonnie++ or even just dd
> >> performance numbers. That would help us figure out if there really is
> >> an anomaly in our setup.
> >>
> >
> > Hi,
> >
> > Since you have already discovered that we don't provide a driver
> > for the paravirtualized disk interface (blkfront), I'd say that most likely
> > your setup is just fine, but emulated pciide performance is subpar.
> >
> > I plan to implement it, but right now the focus is on making networking
> > and specifically interrupt delivery reliable and efficient.
> >
> > Regards,
> > Mike
> 
> Hi Mike,
> 
> Revisiting this issue with OpenBSD 6.1-RELEASE and the new xbf driver
> on XenServer 7.0. The write performance is much better at 74 MB/s
> (still slower than other OSs, but good enough). IOPS also improved
> from 95 to 167. However, the read performance actually got worse and
> is now at 16 MB/s. Here are the full bonnie++ results:
> 
> Version  1.97   --Sequential Output-- --Sequential Input- 
> --Random-
> Concurrency   1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- 
> --Seeks--
> MachineSize K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec 
> %CP
> web4.dhcp.bhsai. 8G   76191  43 10052  17   16044  25 167.3  
> 43
> Latency 168ms 118ms   416ms 488ms
> 
> Here are two dd runs for writing and reading:
> 
> $ dd if=/dev/zero of=test bs=1M count=2048
> 2147483648 bytes transferred in 25.944 secs (82771861 bytes/sec)
> 
> $ dd if=test of=/dev/null bs=1M
> 2147483648 bytes transferred in 123.505 secs (17387767 bytes/sec)
> 
> Here's the dmesg output:
> 
> pvbus0 at mainbus0: Xen 4.6
> xen0 at pvbus0: features 0x2705, 32 grant table frames, event channel 3
> xbf0 at xen0 backend 0 channel 8: disk
> scsibus1 at xbf0: 2 targets
> sd0 at scsibus1 targ 0 lun 0:  SCSI3 0/direct fixed
> sd0: 73728MB, 512 bytes/sector, 150994944 sectors
> xbf1 at xen0 backend 0 channel 9: cdrom
> xbf1: timed out waiting for backend to connect
> 
> Any ideas on why the read performance is so poor?
> 

Yes, 6.1 has a bug that was fixed recently.  Please use -current.
Given how serious were recent fixes, I cannot possibly recommend
using anything but -current on Xen at this point.

Re: Disk I/O performance of OpenBSD 5.9 on Xen

[Maxim Khitrov]

On Sat, Jul 16, 2016 at 6:37 AM, Mike Belopuhov  wrote:
> On 14 July 2016 at 14:54, Maxim Khitrov  wrote:
>> On Wed, Jul 13, 2016 at 11:47 PM, Tinker  wrote:
>>> On 2016-07-14 07:27, Maxim Khitrov wrote:
>>> [...]

 No, the tests are run sequentially. Write performance is measured
 first (20 MB/s), then rewrite (12 MB/s), then read (37 MB/s), then
 seeks (95 IOPS).
>>>
>>>
>>> Okay, you are on a totally weird platform. Or, on an OK platform with a
>>> totally weird configuration.
>>>
>>> Or on an OK platform and configuration with a totally weird underlying
>>> storage device.
>>>
>>> Are you on a magnet disk, are you using a virtual block device or virtual
>>> SATA connection, or some legacy interface like IDE?
>>>
>>> I get some feeling that your hardware + platform + configuration crappiness
>>> factor is fairly much through the ceiling.
>>
>> Dell R720 and R620 servers, 10 gigabit Ethernet SAN, Dell MD3660i
>> storage array, 1.2 TB 10K RPM SAS disks in RAID6. I don't think there
>> is anything crappy or weird about the configuration. Test results for
>> CentOS on the same system: 170 MB/s write, 112 MB/s rewrite, 341 MB/s
>> read, 746 IOPS.
>>
>> I'm assuming that there are others running OpenBSD on Xen, so I was
>> hoping that someone else could share either bonnie++ or even just dd
>> performance numbers. That would help us figure out if there really is
>> an anomaly in our setup.
>>
>
> Hi,
>
> Since you have already discovered that we don't provide a driver
> for the paravirtualized disk interface (blkfront), I'd say that most likely
> your setup is just fine, but emulated pciide performance is subpar.
>
> I plan to implement it, but right now the focus is on making networking
> and specifically interrupt delivery reliable and efficient.
>
> Regards,
> Mike

Hi Mike,

Revisiting this issue with OpenBSD 6.1-RELEASE and the new xbf driver
on XenServer 7.0. The write performance is much better at 74 MB/s
(still slower than other OSs, but good enough). IOPS also improved
from 95 to 167. However, the read performance actually got worse and
is now at 16 MB/s. Here are the full bonnie++ results:

Version  1.97   --Sequential Output-- --Sequential Input- --Random-
Concurrency   1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
MachineSize K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
web4.dhcp.bhsai. 8G   76191  43 10052  17   16044  25 167.3  43
Latency 168ms 118ms   416ms 488ms

Here are two dd runs for writing and reading:

$ dd if=/dev/zero of=test bs=1M count=2048
2147483648 bytes transferred in 25.944 secs (82771861 bytes/sec)

$ dd if=test of=/dev/null bs=1M
2147483648 bytes transferred in 123.505 secs (17387767 bytes/sec)

Here's the dmesg output:

pvbus0 at mainbus0: Xen 4.6
xen0 at pvbus0: features 0x2705, 32 grant table frames, event channel 3
xbf0 at xen0 backend 0 channel 8: disk
scsibus1 at xbf0: 2 targets
sd0 at scsibus1 targ 0 lun 0:  SCSI3 0/direct fixed
sd0: 73728MB, 512 bytes/sector, 150994944 sectors
xbf1 at xen0 backend 0 channel 9: cdrom
xbf1: timed out waiting for backend to connect

Any ideas on why the read performance is so poor?

Thanks,
Max

Re: DUMP: Invalid argument: [block -60912738518]

[Jan Stary]

On Jul 19 09:25:22, h...@stare.cz wrote:
> On Jul 18 21:53:02, h...@stare.cz wrote:
> > Below is what my daily (nightly) dump said. In short,
> > 
> >   read error from /dev/rsd5a: Invalid argument: [block -60912738498]: 
> > count=10240
> > 
> > Thats daily.loca running `dump -0 -a -l 0 -f - /home > /backup/dump.home'
> > The filesystem (/dev/sd5a = /home) is fine; fsck says it's clean.
> > 
> > What could be causing this? During the dump, there was some activity
> > on the filesystem (bitcoind catching up to the blockchain).
> 
> Same thing on another machine:
> 
> errors dumping /home:
>   DUMP: Date of this level 0 dump: Wed Jul 19 01:30:48 2017
>   DUMP: Date of last level 0 dump: the epoch
>   DUMP: Dumping /dev/rsd2a (/home) to standard output
>   DUMP: mapping (Pass I) [regular files]
>   DUMP: mapping (Pass II) [directories]
>   DUMP: estimated 105512095 tape blocks.
>   DUMP: Volume 1 started at: Wed Jul 19 01:31:34 2017
>   DUMP: dumping (Pass III) [directories]
>   DUMP: dumping (Pass IV) [regular files]
>   DUMP: 0.60% done, finished in 13:54
>   DUMP: 1.13% done, finished in 14:36
>   DUMP: 1.70% done, finished in 14:27
>   DUMP: 2.17% done, finished in 15:01
>   DUMP: 2.71% done, finished in 14:56
>   DUMP: 3.22% done, finished in 15:00
>   DUMP: 3.78% done, finished in 14:50
>   DUMP: 4.30% done, finished in 14:50
>   DUMP: 4.81% done, finished in 14:50
>   DUMP: 5.31% done, finished in 14:50
>   DUMP: 5.86% done, finished in 14:44
>   DUMP: 6.41% done, finished in 14:35
>   DUMP: 6.91% done, finished in 14:35
>   DUMP: 7.44% done, finished in 14:31
>   DUMP: 7.97% done, finished in 14:26
>   DUMP: 8.53% done, finished in 14:17
>   DUMP: 9.06% done, finished in 14:13
>   DUMP: 9.62% done, finished in 14:05
>   DUMP: 10.17% done, finished in 13:58
>   DUMP: 10.84% done, finished in 13:42
>   DUMP: 11.47% done, finished in 13:30
>   DUMP: 12.10% done, finished in 13:19
>   DUMP: 12.73% done, finished in 13:08
>   DUMP: 13.49% done, finished in 12:49
>   DUMP: 14.32% done, finished in 12:28
>   DUMP: 15.13% done, finished in 12:09
>   DUMP: 16.00% done, finished in 11:48
>   DUMP: 17.08% done, finished in 11:19
>   DUMP: 18.28% done, finished in 10:48
>   DUMP: 19.82% done, finished in 10:06
>   DUMP: 23.18% done, finished in 8:33
>   DUMP: 28.19% done, finished in 6:47
>   DUMP: 33.37% done, finished in 5:29
>   DUMP: 40.13% done, finished in 4:13
>   DUMP: 47.48% done, finished in 3:13
>   DUMP: 55.27% done, finished in 2:25
>   DUMP:   DUMP:   DUMP: read error from /dev/rsd2a: Invalid argument: [block 
> -57913999616]: count=7168
> read error from /dev/rsd2a: Invalid argument: [block -57913999602]: 
> count=10240
>   DUMP: read error from /dev/rsd2a: Invalid argument: [block -57913999616]: 
> count=512
>   DUMP: read error from /dev/rsd2a: Invalid argument: [block -57913999582]: 
> count=10240
>   DUMP: read error from /dev/rsd2a: Invalid argument: [block -57913999602]: 
> count=512
> read error from /dev/rsd2a: Invalid argument: [block -57913999615]: count=512
>   DUMP:   DUMP: read error from /dev/rsd2a: Invalid argument: [block 
> -57913999582]: count=512
[...]

On Jul 20 11:46:16, skin...@britvault.co.uk wrote:
> On Tue, 18 Jul 2017 21:53:03 +0200 Jan Stary wrote:
> > ... During the dump, there was some activity on the filesystem ...
> 
> Try altering your scripts stop relevant daemons, then umount the
> partition before dumping & see if the problem persists.

If nothing is happening on the filesystem, it dumps OK;
it does not matter that it's mounted.

> See sections '5.0 Conclusions' and '2.0 Active Tests' of Elizabeth D.
> Zwicky's paper "Torture-testing Backup and Archive Programs: Things You
> Ought to Know But Probably Would Rather Not".
> 
> http://www.CoreDumps.De/doc/dump/zwicky/testdump.doc.html
> 
> Specifically for /home;- also see '/etc/nologin' in login(1), which file
> I've found to be usefully created & nuked by my dump driving scripts.

In my case, it does not make a difference that someone is logged in,
but that there are files being written (heavily) during the dump.

At any rate, the negative block numbers seem wrong.

Jan

Re: OT: protonmail mail body

[Stuart Henderson]

On 2017-07-20, Rupert Gallagher  wrote:
> If you make business in Europe, or with people in Europe, then you know about 
> legal compliance with the Commision's standards, and their pdf and p7m signed 
> attachments. Similar standards exist in other countries, and they use mime 
> parts. If your email client cannot read mime parts, you are out of business. 
> If your email server rejects mime messages, you are out of business.
> Sent from ProtonMail Mobile
>
> On Thu, Jul 20, 2017 at 10:22 AM, Paul de Weerd  wrote:
>
>> On Thu, Jul 20, 2017 at 02:46:02AM -0400, Rupert Gallagher wrote: | Out of 
>> curiosity, I just checked what all the fuss is about. It turns out that 
>> someone reads mail with a non-RFC compliant client, and thus fails to read 
>> mime parts. Screw it, update your client. | The other problem seemed to be 
>> with the list archive. It turns out that at least one archive has no problem 
>> at all (*). If other archives have mime problems, they can update themselves 
>> or just delete the mail. All of this while large parts of the world consider 
>> those sending such mails to be spam (after spammers abused trick this to 
>> evade anti-spam solutions), never to deliver them. Your base64-encoded mime 
>> parts are braindead, but nobody is really worried: those e-mails will simply 
>> be ignored by those that might otherwise have had useful replies. Just 
>> because something is a standard, doesn't mean everybody should do it. There 
>> are (very many) harmful standards (caused in large part by a lack of 
>> ax-murderers, I hear). Ch
 eers, Paul 'WEiRD' de Weerd -- 
>[<++>-]<+++.>+++[<-->-]<.>+++[<+ 
+++>-]<.>++[<>-]<+.--.[-] 
http://www.weirdnet.nl/

1. This is not a business list. 

2. I can read the words you write. But it's such a jumbled up mess
that it's not worth taking the time to read them.

People posting to a technical mailing list, particularly if they're
asking for assistance, are expected to follow the standards of that
list.

Re: Read sysctl from file

[Stuart Henderson]

On 2017-07-20, BARDOU Pierre  wrote:
> Is there a way to make sysctl re-read its conf file, or even another file, 
> like sysctl -p does on linux systems ?
> Supporting this option would be nice, as it is used by the sysctl module of 
> ansible.

Sounds risky. It won't reset default values thag are unspecified in
sysctl.conf, so you could be sitting on a configuration that appears ok,
but will fail after a reboot.

Re: Read sysctl from file

[BARDOU Pierre]

Hello,

I didn't realized that, but you have a point here.
For future reference, I got ansible sysctl working tuning the options :

Task :
- name: "Tuning sysctl"
  sysctl:
name: "{{ item.name }}"
value: "{{ item.value }}"
reload: no
sysctl_set: yes
  with_items: "{{ sysctl }}"

Vars :
sysctl:
  - name: "net.inet.ip.forwarding"
value: 1
  - name: "net.inet.carp.preempt"
value: 1

--
Cordialement,
Pierre BARDOU


-Message d'origine-
De : Theo de Raadt [mailto:dera...@openbsd.org] 
Envoyé : jeudi 20 juillet 2017 15:46
À : BARDOU Pierre 
Cc : misc@openbsd.org
Objet : Re: Read sysctl from file

> Is there a way to make sysctl re-read its conf file, or even another 
> file, like sysctl -p does on linux systems ?
> Supporting this option would be nice, as it is used by the sysctl 
> module of= ansible.

But sysctl doesn't have a configuration file.

there is a file called sysctl.conf, but it isn't a configuration file for the 
command.  It is a list of sysctl changes, which will be made by the rc scripts 
at startup.

someone in linux land went off the map here.  and then another piece of 
software started un-portably assuming that's the way to do things?

Re: Preferred configuration for SLAAC in hostname.if

[Peter N. M. Hansteen]

On 07/21/17 00:29, Carlos Cardenas wrote:
> Doing a new install from a long hiatus, I've noticed SLAAC is now
> in the kernel.
> 
> Looking through the archives:
> https://marc.info/?l=openbsd-misc=14335917638=2
> 
> seems to indicate that the keyword 'rtsol' and 'inet6 autoconf' are
> "equivalent" as far as /etc/netstart is concerned.
> 
> What's the preferred setting for SLAAC in hostname.if(5)?

"inet6 autoconf" is what you get if you choose the autoconf option
during install.

I wasn't even aware that the old style "rtsol" was still supported.

- P
-- 
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.

Re: Read sysctl from file

[Remi Locherer]

On Thu, Jul 20, 2017 at 06:14:03PM -0700, Lyndon Nerenberg wrote:
> 
> > On Jul 20, 2017, at 6:35 AM, BARDOU Pierre  wrote:
> > 
> > Hello,
> > 
> > Is there a way to make sysctl re-read its conf file, or even another file, 
> > like sysctl -p does on linux systems ?
> > Supporting this option would be nice, as it is used by the sysctl module of 
> > ansible.

I'm also using Ansible to distribute sysctl configs to OpenBSD hosts. In the
sysctl tasks I set sysctl_set to yes and reload to no. That works fine.

Remi