Re: ratble and rdomain support on dhcpd and openvpn
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
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}?
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
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
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
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
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&m=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
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
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
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
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.