Re: ratble and rdomain support on dhcpd and openvpn

[bytevolcano]

Kapetanakis Giannis wrote:

On 15/07/16 22:34, Difan Zhao wrote:

Thank you sir! So I probably just stick with my hacking approach and
wait for
the 6.0. I see that will come in November so not too much waiting.

So any idea how the openvpn might start to support rtable or rdomain?

Thanks,
Difan



OpeBSD -current (snapshots) is quite stable.
I would suggest you try it and don't wait for the next release.

G



Be careful though; the API/ABI in -current is essentially a moving 
target, so if you do want to stick to -current, be certain the packages 
you run are downloaded roughly the same date you download the snapshot.


Running -current vs -release/-stable should be considered on a 
case-by-case basis. If you know exactly what packages you expect to run, 
and are likely to keep that set, then -current is for you.

Re: ratble and rdomain support on dhcpd and openvpn

[Kapetanakis Giannis]

On 15/07/16 22:34, Difan Zhao wrote:

Thank you sir! So I probably just stick with my hacking approach and wait for
the 6.0. I see that will come in November so not too much waiting.

So any idea how the openvpn might start to support rtable or rdomain?

Thanks,
Difan



OpeBSD -current (snapshots) is quite stable.
I would suggest you try it and don't wait for the next release.

G

Route via gre0 works different than route via gre{1,2}?

[Florian Ermisch]

Hi,

while debugging a problem with routing via GRE I figured 
out I have to use `route add $LAN_A $GRE_REMOTE_A`
for the route going via gre0 but `route add -iface $LAN_B
$GRE_LOCAL_B` for a route via gre1. When I used `route
$LAN_B $GRE_REMOTE_B` packets for $LAN_B were 
send via gre0 (and probably ended up at LAN_A's endpoint
which I don't have access to).
While `route get $LAN_B` stated the gateway was 
$GRE_REMOTE_B, the local interface address was 
$GRE_LOCAL_B and the remote address was 
$GRE_REMOTE_B the route's interface was gre0.

The mentioned `route add -iface …` fixed this and also
works for a route to $LAN_C via gre2. But configuring the 
route to $LAN_A with the same command seems to break
forwarding to this network, the packets don't enter the GRE
tunnel anymore.

Is this how it's supposed to work?

Regards, Florian

Re: ratble and rdomain support on dhcpd and openvpn

[Difan Zhao]

Thank you sir! So I probably just stick with my hacking approach and wait for
the 6.0. I see that will come in November so not too much waiting.

So any idea how the openvpn might start to support rtable or rdomain?

Thanks,
Difan

-Original Message-
From: Chris Cappuccio [mailto:ch...@nmedia.net]
Sent: Friday, July 15, 2016 11:07 AM
To: Difan Zhao 
Cc: Pierre Emeriaud ; misc@openbsd.org
Subject: Re: ratble and rdomain support on dhcpd and openvpn

Difan Zhao [difan.z...@pason.com] wrote:
> Hi Pierre,
>
> I just upgraded the soekris box to openbsd 5.9 however I am still having the
problem setting the rtable...
>

This requires OpenBSD 6.0 which is not yet released. You can use snapshots at
http//ftp.openbsd.org/pub/OpenBSD/snapshots/amd64/ to install the beta code.

Re: jot(1) changed behavior

[Ted Unangst]

Philippe Meunier wrote:
> jot -r 10 1 3 | sort -n | uniq -c
> 
> which the man page clearly indicates should produce something like:
> 
> 24950 1
> 50038 2
> 25012 3
>   
> which is also more in line with the "generate random floating point
> number and truncate to even" model which is described (not very
> clearly, IMHO) in the man page.

That's an artifact of implementation and the fact that the code was written in
a particular way 900 years ago. As a user, 'jot -r 1 1 6' looks like it should
give me a fair roll. I should not have to scavenge around in the man page
to find out jot uses loaded dice.

Re: ratble and rdomain support on dhcpd and openvpn

[Chris Cappuccio]

Difan Zhao [difan.z...@pason.com] wrote:
> Hi Pierre, 
> 
> I just upgraded the soekris box to openbsd 5.9 however I am still having the 
> problem setting the rtable...
> 

This requires OpenBSD 6.0 which is not yet released. You can use snapshots at 
http//ftp.openbsd.org/pub/OpenBSD/snapshots/amd64/ to install the beta code.

easy-rsa on 5.9: STR_COPY variable has no value

[Marko Cupać]

Hi,

I've been using easy-rsa on OpenBSD to manage rsa keys for OpenVPN for
years, but after I upgraded to 5.9 (and applied all the errata patches
up to 020_amap.patch.sig), I get an error when I try to create and sign
new certificate:

# ./easyrsa build-client-full test.example.org

Note: using Easy-RSA configuration from: ./vars
9974260989908:error:0E065068:configuration file routines:STR_COPY:variable has
no
value:/usr/src/lib/libcrypto/crypto/../../libssl/src/crypto/conf/conf_def.c:5
73:line 3

Easy-RSA error:

Missing or invalid OpenSSL
Expected to find openssl command at: /usr/bin/openssl

Needless to say, openssl is in place:
# which openssl
/usr/bin/openssl

All I could find about this is this 6 months old thread:
[http://marc.info/?l=openbsd-misc=145032585015119]

It says eays-rsa is broken in 5.8, but that -stable ports tree should
have working version.

Any advice how to make this work on 5.9?

Thank you in advance,
--
Before enlightenment - chop wood, draw water.
After  enlightenment - chop wood, draw water.

Marko Cupać
https://www.mimar.rs/

Re: jot(1) changed behavior

[Philippe Meunier]

Theo Buehler wrote:
>$ jot -r -p 0 10 1 3 | sort -n | uniq -c
>33464 1
>33246 2
>33290 3

According to the man page, "in the absence of -p, the precision is the
greater of the numbers begin and end".  Since both 1 and 3 have a
precision of zero, therefore I would expect your command:

jot -r -p 0 10 1 3 | sort -n | uniq -c

to behave exactly the same way as this one:

jot -r 10 1 3 | sort -n | uniq -c

which the man page clearly indicates should produce something like:

24950 1
50038 2
25012 3
  
which is also more in line with the "generate random floating point
number and truncate to even" model which is described (not very
clearly, IMHO) in the man page.

Philippe

Re: shm_mkstemp(3) without the file name

[bytevolcano]

Philip Guenther wrote:


Well, I am amazed. I guess I just have to do some more investigation into
workarounds for this, as RAM-based tmpfs file systems will get full very
quickly with shared memory segments, and large segments result in high disk
activity when munmap() is called. And SysV shared memory is too limiting for
my purposes.


Could you clarify what underlying problem you're trying to solve?
Maybe there's just a misunderstanding about the POSIX APIs, or about
how OpenBSD implements them, or what alternative APIs exist.


Philip Guenther



Basically:

1. shm_mkstemp() will result in the creation of a file with a long 
random name in /tmp, which is quite small on the target system (512M 
mfs). The system has 4GB of RAM.


 - The buffers tend to be somewhat large (several dozen MB 
occasionally). I cannot create a shared memory segment larger than the 
remaining free space on the /tmp FS. This creates an issue where 
multiple applications have a buffer each.


 - On a system where /tmp is a disk partition, this file does not 
actually occupy any space until munmap() is called; this results in a 
long pause as it writes the data to the disk.
   This occurs even if shm_unlink() is called before the unmap/close. 
In fact, shm_unlink() is called immediately after shm_mkstemp(), because 
I only am interested in the descriptor from now on. This disk write is 
unnecessary for shared memory; I don't want the file to persist at all. 
When both the application and server are done with the buffer, all 
should be gone.


 - The only way to resolve the issue with disk I/O is to call 
ftruncate(fd, 0) before munmap(), and even this only works where /tmp is 
a huge MFS partition or a huge disk partition.


 - There is a brief point in time (between shm_mkstemp() and 
shm_unlink()) where a rogue application can grab the buffer file, call 
ftruncate(), and map its contents, without either my server or 
applications knowing. Whilst file permissions are good at stopping other 
users accessing the segment, this goes against the idea that the app


To summarise, the major issue I am having is that the "shared memory" 
buffer looks like a file on disk, and acts like a file on disk, rather 
than a section of memory that I am sharing in between processes. As a 
result, I need to have a huge /tmp file system just to accommodate the 
buffer, regardless of how much RAM I have.



The problem I have with the SysV shm* API is that it gets hard to clean 
up shared memory segments. Whilst that I can live with to some degree, 
the biggest issue with it is the 32MB limit per segment 
(kern.shminfo.shmmax).

Re: shm_mkstemp(3) without the file name

[Philip Guenther]

On Fri, Jul 15, 2016 at 1:56 AM,   wrote:
> Ted Unangst wrote:
>>
>> bytevolc...@safe-mail.net wrote:
>>>
>>> I see where you are coming from, but what I am getting at is, where in
>>> the POSIX standard does it say that it needs to be anywhere in the file
>>> system at all? If it is shared memory, then surely this doesn't require
>>> backing up.
>>
>> Oh. It doesn't have to be a file. It can be a file. (And you can't asusme
>> it's not a file.)
>
> Well, I am amazed. I guess I just have to do some more investigation into
> workarounds for this, as RAM-based tmpfs file systems will get full very
> quickly with shared memory segments, and large segments result in high disk
> activity when munmap() is called. And SysV shared memory is too limiting for
> my purposes.

Could you clarify what underlying problem you're trying to solve?
Maybe there's just a misunderstanding about the POSIX APIs, or about
how OpenBSD implements them, or what alternative APIs exist.


Philip Guenther

Re: shm_mkstemp(3) without the file name

[bytevolcano]

Ted Unangst wrote:

bytevolc...@safe-mail.net wrote:

I see where you are coming from, but what I am getting at is, where in
the POSIX standard does it say that it needs to be anywhere in the file
system at all? If it is shared memory, then surely this doesn't require
backing up.


Oh. It doesn't have to be a file. It can be a file. (And you can't asusme it's
not a file.)



Well, I am amazed. I guess I just have to do some more investigation 
into workarounds for this, as RAM-based tmpfs file systems will get full 
very quickly with shared memory segments, and large segments result in 
high disk activity when munmap() is called. And SysV shared memory is 
too limiting for my purposes.

Thanks for the info, Ted.

Re: jot(1) changed behavior

[Theo Buehler]

> The second exmaple:
> 
> $ jot -r -p 0 10 0.5 3.5 | sort -n | uniq -c
> 25120 0
> 49882 2
> 24998 4
> 
> So I'd says there are real bugs introduced with the latest commit.
> 
>   -Otto
> 

Indeed, this is bad. The following patch lets the code fall back to the
old version in the cases that the new code doesn't handle well:

As we discussed on icb, if -p 0 is given, only use the new code if both
endpoints are integers seems to work nicely.

$ jot -r -p 0 10 0.5 3.5 | sort -n | uniq -c
33434 1
33228 2
8 3
$ jot -r -p 0 10 1 3 | sort -n | uniq -c
33464 1
33246 2
33290 3

Bad bias in some cases is unavoidable:

$ jot -r -p 0 10 1 3.5 | sort -n | uniq -c
19923 1
39934 2
40143 3

Index: jot.c
===
RCS file: /var/cvs/src/usr.bin/jot/jot.c,v
retrieving revision 1.27
diff -u -p -r1.27 jot.c
--- jot.c   10 Jan 2016 01:15:52 -  1.27
+++ jot.c   15 Jul 2016 06:26:29 -
@@ -277,9 +277,6 @@ main(int argc, char *argv[])
if (prec > 9)   /* pow(10, prec) > UINT32_MAX */
errx(1, "requested precision too large");
 
-   while (prec-- > 0)
-   pow10 *= 10;
-
if (ender < begin) {
x = begin;
begin = ender;
@@ -287,16 +284,22 @@ main(int argc, char *argv[])
}
x = ender - begin;
 
-   /*
-* If pow10 * (ender - begin) is an integer, use
-* arc4random_uniform().
-*/
-   use_unif = fmod(pow10 * (ender - begin), 1) == 0;
-   if (use_unif) {
-   uintx = pow10 * (ender - begin);
-   if (uintx >= UINT32_MAX)
-   errx(1, "requested range too large");
-   uintx++;
+   if (prec == 0 && (fmod(ender, 1) != 0 || fmod(begin, 1) != 0))
+   use_unif = 0;
+   else {
+   while (prec-- > 0)
+   pow10 *= 10;
+   /*
+* If pow10 * (ender - begin) is an integer, use
+* arc4random_uniform().
+*/
+   use_unif = fmod(pow10 * (ender - begin), 1) == 0;
+   if (use_unif) {
+   uintx = pow10 * (ender - begin);
+   if (uintx >= UINT32_MAX)
+   errx(1, "requested range too large");
+   uintx++;
+   }
}
 
for (i = 1; i <= reps || infinity; i++) {