Re: why thread is not usable in perl5 of OpenBSD6.4?
Thank you very much gunther and Philip for your technical response to my question. Ok, thread support is not recommended officially, then I follow it. I just watnted it, because Ubuntu linux support it etc., and I'd like to use a perl script of 2chproxy.pl at github.com. - for a convenience, I include a diff file, which is made by the procedure below: make -f Makefile.bsd-wrapper make test >file1 2>&1 -- Add -Dusethreads at the end of CONFIG_ARG parameter of Makefile.bsd-wrapper make -f Makefile.bsd-wrapper make test >file2 2>&1 (This tread support perl can do use threads; without error, after make install) diff file1 file2 >ken.diff Kenji 2018年11月27日(火) 2:26 Andrew Hewus Fresh : > On Sun, Nov 25, 2018 at 09:32:33PM -0800, Philip Guenther wrote: > > On Sun, Nov 25, 2018 at 1:57 AM 岡本健二 wrote: > > > > > I have to use thread on the perl5 of OpenBSD 6.4. > > > However, it was disabled on the distribution. > > > > > > > Hmm, is this something that worked in previous releases, or is something > > that you've only tried in OpenBSD 6.4? > > > > Off-hand, it's still disabled by default in the Configure script that > perl > > people ship, and I don't see anything in the OpenBSD bits to override > their > > choice. > > > One of the main reasons is that the "use of interpreter-based threads in > perl is officially discouraged" and has been unofficially discouraged > for a lot longer. > > http://perldoc.perl.org/threads.html#WARNING > > My understanding of the reason it is discouraged is that the threading > mechanism in perl does not lend itself to correct code and you're > probably better off doing something simpler and getting nearly as good > results using another mechanism. > > > > > > I tried to make the thread active to recompile the perl5 with > -Dusethreads, > > > which led me to many test fails. > > > > > > > Were there tests that failed with -Dusethreads that passed when that > wasn't > > used? If so, which, and what was their output? > > The perl test suite does not like to run in the OpenBSD source tree, I > don't recall why off the top of my head, just that it doesn't. If you > had failures that are different than you get without enabling threads, > that might be interesting to diagnose. > > > > To put it another way: if you're suggesting that we build the base perl > > with -Dusethreads, what are the consequences of that? Test failures? > > Bigger binary? pkg_add is slower? > > It does make perl anecdotally 10% slower overall (as I recall) for non > threaded operations. Obviously that depends on the workload, but since > we don't use them, making pkg_add and other things that use perl faster > seems more useful. > > http://perldoc.perl.org/perlthrtut.html#Performance-considerations > > > > > > Why the thread function was disabled in this release? > > > Is it security reason? > > > > > > > Upstream has it off by default, nothing so far has needed it, and it > makes > > things slower (or at least that's why upstream says). Why would we > enable > > it? > > > See above for more reasoning and you might look at p5-Coro if you > really need threads, I haven't had a need for them but have heard they > work better than the core implementation. > > https://metacpan.org/pod/Coro > > l8rZ, > -- > andrew - http://afresh1.com > > People who invent random theories which only defend the vendor must have > been beaten as children. Beaten with sticks. > At least, that's my theory. > -- Theo De Raadt > ken.diff Description: Binary data
Re: iked for travelling clients
On 2018-11-26, Thuban wrote:
> Hi,
> I need some advice to configure an iked server. I guess it's called
> "roadwarrior", but as english is not my main language, here is what I
> need :
> * Connect to this server via any device (no certificate at first)
> * Allow any incoming IP to connect.
> * Route the traffic to the web through the vpn.
>
> What I did on the server after reading the list and manpages :
>
> # cat /etc/sysctl.conf
> net.inet.ip.forwarding=1
> net.inet.ipcomp.enable=1
>
> # echo "up" > /etc/hostname.enc0
> # sh /etc/netstart enc0
>
> # cat /etc/pf.conf
> set skip on enc0
Here you tell PF to completely ignore traffic on enc0...
> pass in on egress proto udp from any to any port {isakmp, ipsec-nat-t}
> pass out on egress proto udp from any to any port {isakmp, ipsec-nat-t}
> pass in on egress proto esp
> pass out on egress proto esp
> match out on enc0 from 192.168.47.160/27 nat-to (egress:0)
...and here you tell it to NAT traffic on enc0. This isn't going to
do what you want because it's already ignoring that traffic.
> # cat /etc/iked.conf
> user "test" "password12345"
> ikev2 "warrior" passive ipcomp esp \
> from any to any \
> peer any \
> srcid "hostname.tld" \
> local ip.ip.ip.ip \
> peer any \
> eap "mschap-v2" \
> config address 192.168.47.160/27 \
> tag "$name-$id"
iked only supports mschapv2 on the responder ("server side"), not on
the client ("initiator").
If you're only doing openbsd<>openbsd here then see "PUBLIC KEY
AUTHENTICATION" in iked(8), that's the simplest way and doesn't
require x509 certificates.
Re: OpenBGPD set nexthop blackhole qualify question
Auto answering myself because the answer was alrady in the mailling lists : Just set nexthop=127.0.0.1 on the neighbor, then you can blackhole. https://misc.openbsd.narkive.com/7jcjKEkQ/openbgpd-match-clause-with-multihop-bgp-session Le 2018-11-23 16:16, Arnaud BRAND a écrit : Hi misc@ readers, I have a question regarding the "set nexthop blackhole" nexthop qualification in OpenBGPD 6.4 stable. It looks like I have to add "nexthop qualify via default" in order for the blackholed route to make it from the rib to the fib. I understand this is standard behaviour for normal BGP nexthop qualification, but is this mandatory/normal/expected for blackholed prefixes too ? I would have thought that since I am blackholing the prefix there's nothing to qualify for anyway. Thanks for your help and tremendous work ! Have a nice day ! Arnaud
Re: non-interactive sh and SIGTERM
Thanks for the explanation, it makes sense to use pgids for that purpose. In the case in which I am interested (vimtex plugin failing to kill latexmk, which works on another machine running debian linux) I guessed that the plugin sent a SIGTERM signal only to the 'sh -c' process, which would work with bash because bash somehow terminates the subprocess immediately. But I guessed wrong: vimtex uses vim's job_stop, which according to vim's help should send the signal to the process group, with the explicit intent of terminating 'sh -c' commands. So this issue comes from either vim or vimtex. On Sun, Nov 25, 2018 at 09:04:22PM -0800, Philip Guenther wrote: > On Fri, Nov 23, 2018 at 1:51 PM Olivier Taïbi wrote: > > > Sorry about the wrong report, I just tested again and I can see the same > > behaviour with OpenBSD 6.4: sending SIGTERM to the sh process after > > launching sh -c 'sleep 1000' does not result in sh sending a SIGTERM to > > the sleep process. > > > > Hmm, why should it? If you wanted to kill whatever processes where started > from that invocation, shouldn't you send SIGTERM to the process group? > > > > > Philip, what was your test? > > > > : morgaine; sh -c 'while :; do :; done' & > [3] 16632 > : morgaine; kill 16632 > [3] - Terminated sh -c "while :; do :; done" > : morgaine; > : morgaine; sh -c 'while :; do sleep 1; done' & > [3] 59539 > : morgaine; kill 59539 > : morgaine; > [3] - Terminated sh -c "while :; do sleep 1; done" > : morgaine; > > sh itself doesn't ignore SIGTERM, but rather exits after receiving it. > > > Philip Guenther
iked for travelling clients
Hi,
I need some advice to configure an iked server. I guess it's called
"roadwarrior", but as english is not my main language, here is what I
need :
* Connect to this server via any device (no certificate at first)
* Allow any incoming IP to connect.
* Route the traffic to the web through the vpn.
What I did on the server after reading the list and manpages :
# cat /etc/sysctl.conf
net.inet.ip.forwarding=1
net.inet.ipcomp.enable=1
# echo "up" > /etc/hostname.enc0
# sh /etc/netstart enc0
# cat /etc/pf.conf
set skip on enc0
pass in on egress proto udp from any to any port {isakmp, ipsec-nat-t}
pass out on egress proto udp from any to any port {isakmp, ipsec-nat-t}
pass in on egress proto esp
pass out on egress proto esp
match out on enc0 from 192.168.47.160/27 nat-to (egress:0)
# cat /etc/iked.conf
user "test" "password12345"
ikev2 "warrior" passive ipcomp esp \
from any to any \
peer any \
srcid "hostname.tld" \
local ip.ip.ip.ip \
peer any \
eap "mschap-v2" \
config address 192.168.47.160/27 \
tag "$name-$id"
It doesn't work as expected.
Here is the trace of "iked -vvd" on the server at auth attempt :
reiva# iked -vvd
ikev2 "warrior" passive esp from any to any local any peer any ikesa
enc aes-256,aes-192,aes-128,3des prf hmac-sha2-256,hmac-sha1 auth
hmac-sha2-256,hmac-sha1 group modp2048,modp1536,modp1024 childsa enc
aes-256,aes-192,aes-128 auth hmac-sha2-256,hmac-sha1 lifetime 10800 bytes
536870912 signature
/etc/iked.conf: loaded 2 configuration rules
ca_privkey_serialize: type RSA_KEY length 1191
ca_pubkey_serialize: type RSA_KEY length 270
config_new_user: inserting new user test
user "test" "password12345"
ca_privkey_to_method: type RSA_KEY method RSA_SIG
ca_getkey: received private key type RSA_KEY length 1191
ca_getkey: received public key type RSA_KEY length 270
ca_dispatch_parent: config reset
ca_reload: local cert type RSA_KEY
config_getocsp: ocsp_url none
ikev2_dispatch_cert: updated local CERTREQ type RSA_KEY length 0
config_getpolicy: received policy
config_getpfkey: received pfkey fd 3
config_getcompile: compilation done
config_getsocket: received socket fd 4
config_getsocket: received socket fd 5
config_getsocket: received socket fd 6
config_getsocket: received socket fd 7
config_getmobike: mobike
ikev2_recv: IKE_SA_INIT request from initiator 176.180.81.105:19956 to
46.23.92.147:500 policy 'warrior' id 0, 716 bytes
ikev2_recv: ispi 0x515201836a3a178d rspi 0x
ikev2_policy2id: srcid FQDN/reiva.openbsd.amsterdam length 27
ikev2_pld_parse: header ispi 0x515201836a3a178d rspi 0x
nextpayload SA version 0x20 exchange IKE_SA_INIT flags 0x08 msgid 0 length 716
response 0
ikev2_pld_payloads: payload SA nextpayload KE critical 0x00 length 492
ikev2_pld_sa: more 2 reserved 0 length 228 proposal #1 protoid IKE
spisize 0 xforms 26 spi 0
ikev2_pld_xform: more 3 reserved 0 length 12 type ENCR id AES_CBC
ikev2_pld_attr: attribute type KEY_LENGTH length 128 total 4
ikev2_pld_xform: more 3 reserved 0 length 12 type ENCR id AES_CBC
ikev2_pld_attr: attribute type KEY_LENGTH length 192 total 4
ikev2_pld_xform: more 3 reserved 0 length 12 type ENCR id AES_CBC
ikev2_pld_attr: attribute type KEY_LENGTH length 256 total 4
ikev2_pld_xform: more 3 reserved 0 length 8 type ENCR id 3DES
ikev2_pld_xform: more 3 reserved 0 length 8 type INTEGR id
HMAC_SHA2_256_128
ikev2_pld_xform: more 3 reserved 0 length 8 type INTEGR id
HMAC_SHA2_384_192
ikev2_pld_xform: more 3 reserved 0 length 8 type INTEGR id
HMAC_SHA2_512_256
ikev2_pld_xform: more 3 reserved 0 length 8 type INTEGR id HMAC_SHA1_96
ikev2_pld_xform: more 3 reserved 0 length 8 type INTEGR id AES_XCBC_96
ikev2_pld_xform: more 3 reserved 0 length 8 type PRF id HMAC_SHA2_256
ikev2_pld_xform: more 3 reserved 0 length 8 type PRF id HMAC_SHA2_384
ikev2_pld_xform: more 3 reserved 0 length 8 type PRF id HMAC_SHA2_512
ikev2_pld_xform: more 3 reserved 0 length 8 type PRF id AES128_XCBC
ikev2_pld_xform: more 3 reserved 0 length 8 type PRF id HMAC_SHA1
ikev2_pld_xform: more 3 reserved 0 length 8 type DH id ECP_256
ikev2_pld_xform: more 3 reserved 0 length 8 type DH id ECP_384
ikev2_pld_xform: more 3 reserved 0 length 8 type DH id ECP_521
ikev2_pld_xform: more 3 reserved 0 length 8 type DH id BRAINPOOL_P256R1
ikev2_pld_xform: more 3 reserved 0 length 8 type DH id BRAINPOOL_P384R1
ikev2_pld_xform: more 3 reserved 0 length 8 type DH id BRAINPOOL_P512R1
Re: why thread is not usable in perl5 of OpenBSD6.4?
On Sun, Nov 25, 2018 at 09:32:33PM -0800, Philip Guenther wrote: > On Sun, Nov 25, 2018 at 1:57 AM 岡本健二 wrote: > > > I have to use thread on the perl5 of OpenBSD 6.4. > > However, it was disabled on the distribution. > > > > Hmm, is this something that worked in previous releases, or is something > that you've only tried in OpenBSD 6.4? > > Off-hand, it's still disabled by default in the Configure script that perl > people ship, and I don't see anything in the OpenBSD bits to override their > choice. One of the main reasons is that the "use of interpreter-based threads in perl is officially discouraged" and has been unofficially discouraged for a lot longer. http://perldoc.perl.org/threads.html#WARNING My understanding of the reason it is discouraged is that the threading mechanism in perl does not lend itself to correct code and you're probably better off doing something simpler and getting nearly as good results using another mechanism. > > I tried to make the thread active to recompile the perl5 with -Dusethreads, > > which led me to many test fails. > > > > Were there tests that failed with -Dusethreads that passed when that wasn't > used? If so, which, and what was their output? The perl test suite does not like to run in the OpenBSD source tree, I don't recall why off the top of my head, just that it doesn't. If you had failures that are different than you get without enabling threads, that might be interesting to diagnose. > To put it another way: if you're suggesting that we build the base perl > with -Dusethreads, what are the consequences of that? Test failures? > Bigger binary? pkg_add is slower? It does make perl anecdotally 10% slower overall (as I recall) for non threaded operations. Obviously that depends on the workload, but since we don't use them, making pkg_add and other things that use perl faster seems more useful. http://perldoc.perl.org/perlthrtut.html#Performance-considerations > Why the thread function was disabled in this release? > > Is it security reason? > > > > Upstream has it off by default, nothing so far has needed it, and it makes > things slower (or at least that's why upstream says). Why would we enable > it? See above for more reasoning and you might look at p5-Coro if you really need threads, I haven't had a need for them but have heard they work better than the core implementation. https://metacpan.org/pod/Coro l8rZ, -- andrew - http://afresh1.com People who invent random theories which only defend the vendor must have been beaten as children. Beaten with sticks. At least, that's my theory. -- Theo De Raadt
Re: Help with LibreSSL manpages
Hi Stephen, Stephen Gregoratto wrote on Mon, Nov 26, 2018 at 09:24:25PM +1100: > Thanks for your response Ingo. I think I'll start with the missing > functions and go through them by order of length. Not saying "by order of length" is impossible, but keep in mind that * There are few section 3 manual pages documenting only a single function, especially in bloaty libraries like libcrypto/libssl, it is usually better to document very closely related functions together on one page. (Rule of thumb: avoid text duplication, but don't make pages too long and complicated.) * Going by length implies that you will have to learn about a new sub-library for almost every function you tackle. * Going by length implies that you will be sending a mix of diffs for functions of vastly different importance; it may be harder to get reviews for functions of lower importance and to get those committed. So the criterion "by length" will surely make things harder for you. Not saying the criterion is impossible to use, just making sure you know it has some serious downsides for you. > I'll try and peruse > through the ports and check for any examples. Be aware that functions exist that are notoriously misused, and code in ports is of widely varying quality. Large parts of the ports tree contain code that is way below OpenBSD quality standards, so you will learn much less from looking at ports code than from looking at base system code, unless you know which ports are of unusually high code quality. > Speaking of functions: I'm trying to generate a list of each function, Not saying "don't do that" - but be aware that the reason why nobody did that yet (not even when giving a public talk that included statements about "future directions") is that it is not really needed in the current situation to make progress. Such a list becomes useful when we get very close to the goal of having everything documented. That is years in the future at best. A list containing hundreds of functions doesn't seem all that useful to me. > the source file it's defined in and the corresponding line number, > similar to the format of `grep -n`. Is there a way to force ctags to > output in some tabular format that can be AWK'd? The -x option isn't > cutting it for me. I have no idea, i never used ctags(1), nor any similar tool for that matter. I never saw a use for it. I you want to use it, figure it out. :) There is no need to try and refute the points made in this posting, and you can proceed as described here if you really want to. I'm merely trying to make sure that you are not making the project harder for yourself without even being aware that that's what you are doing. After all, you asked for advice on how to proceed and neither "producing a complete list of missing functions" nor "mastering automated tools for static source code analysis" was anyway near my list of potential obstactles that might have to be overcome. ;-) Yours, Ingo
Re: OpenBGP announce customer routes
On 2018-11-26, Michail Iordanidis wrote: > Dear all, > > is there a way to advertise IP prefixes generated from a customer AS & > prefixes to an EBGP neighbor in Openbgpd? > > Can I somehow create an outgoing prefix list our something like a > route-map for outgoing filtering? > > Please help > > > Normally you talk BGP with the customer and use filter rules to allow them to send announcements for their prefixes (and no others), either from a prearranged list, or from their IRR database entries (maybe using bgpq3 or similar to generate it). Does that match what you're trying to do? Or are they asking you to announce for them?
OpenBGP announce customer routes
Dear all, is there a way to advertise IP prefixes generated from a customer AS & prefixes to an EBGP neighbor in Openbgpd? Can I somehow create an outgoing prefix list our something like a route-map for outgoing filtering? Please help
Re: Help with LibreSSL manpages
Thanks for your response Ingo. I think I'll start with the missing functions and go through them by order of length. I'll try and peruse through the ports and check for any examples. Speaking of functions: I'm trying to generate a list of each function, the source file it's defined in and the corresponding line number, similar to the format of `grep -n`. Is there a way to force ctags to output in some tabular format that can be AWK'd? The -x option isn't cutting it for me. -- Stephen Gregoratto
Re: apmd: howto resume with screen locked
On 2018 Nov 26 (Mon) at 01:18:59 + (+), shadrock uhuru wrote: : :also how do i resume from hibernate or suspend with the screen locked : :i use i3 and lock the screen with xautolock and i3lock in .i3/config : :i put i3lock in /etc/apm/resume : :when i resume from ZZZ no lock screen appears, i am brought straight :to my desktop : :shadrock : /etc/apm/resume is ran as root, so you'll need that script to run i3lock as your user, or to trigger i3's screenlock mechanism I have a similar thing enabled on my laptop, but it's in /etc/apm/suspend: pkill -USR1 -x xidle -- Jacquin's Postulate on Democratic Government: No man's life, liberty, or property are safe while the legislature is in session.
