Re: How effectiate login.conf changes in console? ("ksh -l" does not)
On Mon, Oct 29, 2018 at 8:40 PM Joseph Mayer wrote: > After having changed /etc/login.conf I'd like to effectuate the > changes directly in the console, without doing a logout-relogin > cycle. > > Running "ksh -l" does *not* effectuate login.conf changes but only > re-runs the profile script [1]. > > Running "login" asks for username and password which seems less > efficient than possible. > > Is there any way to do this? Since changes to login.conf may mean raising/increasing hard limits, which can only be done by privileged processes, the only sure fire way to have login.conf changes take effect is to logout and log back in. Philip Guenther
How effectiate login.conf changes in console? ("ksh -l" does not)
Hi, After having changed /etc/login.conf I'd like to effectuate the changes directly in the console, without doing a logout-relogin cycle. Running "ksh -l" does *not* effectuate login.conf changes but only re-runs the profile script [1]. Running "login" asks for username and password which seems less efficient than possible. Is there any way to do this? Joseph [1] http://man.openbsd.org/ksh#DESCRIPTION
Re: acme-client memory setup failure
Unfortunately, I don't have any backup of the original cert.pem file. So I wonder if I'm correct with this: I will get a new cert.pem if I upgrade the os (current version is 6.3) to 6.4, and then, before merging the new one, I could test similar to what you told me. I am just now suddenly wondering: - when I upgrade the os, I get a new cert.pem -- correct? - Therefore I have to add again other certificates to the "new" cert.pem. -- correct? - And the old cert.pem is no longer needed so there's no need to "merge" the old cert.pem or any other. -- correct? = So could the merging wrong one have caused the issue? Thank you, TronDD. On 29/10/2018 00:20, TronDD wrote: > > > On October 28, 2018 12:09:02 AM EDT, "연락 연락" wrote: >> Thank you indeed for your reply, trondd. >> Yes, I added certificate(s) to cert.pem, probably more than one time so >> far. >> But the size looks not much bigger than normal one that I see from >> another host. >> size of the cert.pem modified(?): 357*** >> size of cert.pem I see from another host where I didn't add anything to >> >> the cert.pem: 349*** >> >> Do you think 357*** is too big? >> How did you solve the issue? >> What can I do if something went wrong when I added certificates or when >> >> upgrading openbsd and adding the certificates again? >> > > Put the original cert.pem back and see if it solves the issue first. > > >> If the router/gateway before the host has been changed so the cert.pem >> of the gateway is not the same of the previous one, can it be also a >> matter? >> >> > > The cert.pem only matters on the machine making the SSL connection. > > >> On 28/10/2018 04:54, trondd wrote: >>> On Sat, October 27, 2018 6:19 am, ì*°ë*½ ì*°ë*½ wrote: Dear misc, I am getting an error saying "ssl verify memory setup failure" >> whenever I try to renew existing certificates on a host -- Openbsd 6.3, >> httpd, acme-client. Recently there were changes in a few configurations, including >> network, name servers, etc. The below is all I get when I try command acme-clilent -vv >> example.com: ..domain key ..account key ..cert ...days left ..directory ..DNS: (some ip) (some ip):tls_connect_socket: acme-v01.api.letsencrypt.org, ssl >> verify memory setup failure ..bad comm bad exit... Could someone let me know what could cause the ssl verify memory >> setup failure, or if the memory setup failure could be some kind of common error, such as something occurred by memory configuration, such as >> in login.conf? For your information, those worked before. Recently thinking about hardware issues, especially for RAM. Because I can't share detailed configurations, names, etc., I am wondering if someone could kindly give some advice on the above information. Any help and your time would be greatly appreciated indeed. >>> >>> Did you modify certs.pem? I've run into this when accidentally >> adding >>> certs multiple times growing the file too big or writing a DOS >> formatted >>> cert to it. >>>
Re: doas behaviour in recent snapshot [was Re: 6.4 doas gives "command not found" if no #!/bin/sh up top]
Known bug. Use full path until it's fixed.
doas behaviour in recent snapshot [was Re: 6.4 doas gives "command not found" if no #!/bin/sh up top]
On 10/30/18 10:11 AM, Ted Unangst wrote: > tomr wrote: >> I'm a bit confused here. I have some cwm keybindings that `doas rcctl` >> things, which now aren't working as they used to - which isn't >> necessarily a problem - but I'm surprised at the behaviour below: >> >> # this doesn't work anymore.. >> $ doas rcctl >> doas: rcctl: command not found > > are you using a snapshot? there's something broken, but 6.4 should work. > Quite right. I spun up 6.4-RELEASE in a vm and it works as expected. I'm seeing the issue on this snapshot: OpenBSD 6.4-current (GENERIC.MP) #408: Sun Oct 28 23:10:11 MDT 2018 Apologies for piggybacking an older thread and assuming this was the same issue! t
Re: 6.4 doas gives "command not found" if no #!/bin/sh up top
Tom you have changed a conversation about one problem into a conversation about a different problem It is confusing. Please don't do that. > On 10/22/18 9:48 AM, Ted Unangst wrote: > > Ted Unangst wrote: > >> Ted Unangst wrote: > >>> Derek wrote: > Adding a "#!/bin/sh" at the top of the scripts made them all work again. > >>> > >>> i don't believe this is a change; that's how it should always work. > >> > >> sorry, this appears wrong. doas actually uses execvpe() from libc, which is > >> supposed to do the sh interpretation thing, except now it doesn't work > >> right. > >> this is a behavior change. > > > > sorry for the burst of email. i was a little out of touch about what was > > happening. there were changes made, but they were not entirely expected or > > planned. > > > > old behavior: doas uses execvpe(), which as the man page notes, follows sh > > behavior and will execute the command using the sh if it has the x bit but > > lacks a magic header. > > > > new behavior: some unveil() calls were added to doas which restricts access > > to > > /bin/sh, meaning execvpe() no longer works as before. > > > > as hinted in my original reply below, i kind of like this behavior. the > > change > > to restrict commands to only those with valid headers was inadvertent, but > > the > > outcome seems positive. we will probably stick with it. > > > > so... the behavior changed, that's probably a bug, but we're going to call > > it > > a feature. problem solved. :) > > > > some documentation changes may be forthcoming to make everything clear. > > > > thanks for finding and reporting this. > > I'm a bit confused here. I have some cwm keybindings that `doas rcctl` > things, which now aren't working as they used to - which isn't > necessarily a problem - but I'm surprised at the behaviour below: > > # this doesn't work anymore.. > $ doas rcctl > doas: rcctl: command not found > > # these all still work.. > $ doas sh -c rcctl > usage: rcctl get|getdef|set service | daemon [variable [arguments]] > rcctl [-df] check|reload|restart|stop|start daemon ... > rcctl disable|enable|order [daemon ...] > rcctl ls all|failed|off|on|started|stopped > # tried with ktrace to see where it was getting stuck, but it worked.. > $ doas ktrace rcctl > usage: rcctl get|getdef|set service | daemon [variable [arguments]] > rcctl [-df] check|reload|restart|stop|start daemon ... > rcctl disable|enable|order [daemon ...] > rcctl ls all|failed|off|on|started|stopped > $ doas /usr/sbin/rcctl > usage: rcctl get|getdef|set service | daemon [variable [arguments]] > rcctl [-df] check|reload|restart|stop|start daemon ... > rcctl disable|enable|order [daemon ...] > rcctl ls all|failed|off|on|started|stopped > > # /usr/sbin is in my path > $ echo $PATH > /home/tomr/perl5/bin:/home/tomr/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/local/sbin:/usr/games > > # other commands from /usr/sbin still work > $ which vmctl > /usr/sbin/vmctl > $ doas vmctl > usage: vmctl [-v] command [arg ...] > vmctl console id > vmctl create "path" [-b base] [-i disk] [-s size] > vmctl load "path" > vmctl log [verbose|brief] > vmctl reload > vmctl reset [all|vms|switches] > vmctl show [id] > vmctl start "name" [-Lc] [-b image] [-r image] [-m size] > [-n switch] [-i count] [-d disk]* [-t name] > vmctl status [id] > vmctl stop [id|-a] [-fw] > vmctl pause id > vmctl unpause id > vmctl send id > vmctl receive id > $ > > So, what's special about rcctl? > > t > > > > >> > >> > >>> > >>> execve() returns ENOEXEC if the file doesn't have the right magic header. > >>> sh > >>> will attempt to interpret the file as a script after that error, but i > >>> don't > >>> think doas should have such a fallback. it may not be a sh script, and > >>> then > >>> weird and possibly bad things will happen (has happened before). > > >
Re: 6.4 doas gives "command not found" if no #!/bin/sh up top
tomr wrote: > I'm a bit confused here. I have some cwm keybindings that `doas rcctl` > things, which now aren't working as they used to - which isn't > necessarily a problem - but I'm surprised at the behaviour below: > > # this doesn't work anymore.. > $ doas rcctl > doas: rcctl: command not found are you using a snapshot? there's something broken, but 6.4 should work.
Re: 6.4 doas gives "command not found" if no #!/bin/sh up top
On 10/22/18 9:48 AM, Ted Unangst wrote: > Ted Unangst wrote: >> Ted Unangst wrote: >>> Derek wrote: Adding a "#!/bin/sh" at the top of the scripts made them all work again. >>> >>> i don't believe this is a change; that's how it should always work. >> >> sorry, this appears wrong. doas actually uses execvpe() from libc, which is >> supposed to do the sh interpretation thing, except now it doesn't work right. >> this is a behavior change. > > sorry for the burst of email. i was a little out of touch about what was > happening. there were changes made, but they were not entirely expected or > planned. > > old behavior: doas uses execvpe(), which as the man page notes, follows sh > behavior and will execute the command using the sh if it has the x bit but > lacks a magic header. > > new behavior: some unveil() calls were added to doas which restricts access to > /bin/sh, meaning execvpe() no longer works as before. > > as hinted in my original reply below, i kind of like this behavior. the change > to restrict commands to only those with valid headers was inadvertent, but the > outcome seems positive. we will probably stick with it. > > so... the behavior changed, that's probably a bug, but we're going to call it > a feature. problem solved. :) > > some documentation changes may be forthcoming to make everything clear. > > thanks for finding and reporting this. I'm a bit confused here. I have some cwm keybindings that `doas rcctl` things, which now aren't working as they used to - which isn't necessarily a problem - but I'm surprised at the behaviour below: # this doesn't work anymore.. $ doas rcctl doas: rcctl: command not found # these all still work.. $ doas sh -c rcctl usage: rcctl get|getdef|set service | daemon [variable [arguments]] rcctl [-df] check|reload|restart|stop|start daemon ... rcctl disable|enable|order [daemon ...] rcctl ls all|failed|off|on|started|stopped # tried with ktrace to see where it was getting stuck, but it worked.. $ doas ktrace rcctl usage: rcctl get|getdef|set service | daemon [variable [arguments]] rcctl [-df] check|reload|restart|stop|start daemon ... rcctl disable|enable|order [daemon ...] rcctl ls all|failed|off|on|started|stopped $ doas /usr/sbin/rcctl usage: rcctl get|getdef|set service | daemon [variable [arguments]] rcctl [-df] check|reload|restart|stop|start daemon ... rcctl disable|enable|order [daemon ...] rcctl ls all|failed|off|on|started|stopped # /usr/sbin is in my path $ echo $PATH /home/tomr/perl5/bin:/home/tomr/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/local/sbin:/usr/games # other commands from /usr/sbin still work $ which vmctl /usr/sbin/vmctl $ doas vmctl usage: vmctl [-v] command [arg ...] vmctl console id vmctl create "path" [-b base] [-i disk] [-s size] vmctl load "path" vmctl log [verbose|brief] vmctl reload vmctl reset [all|vms|switches] vmctl show [id] vmctl start "name" [-Lc] [-b image] [-r image] [-m size] [-n switch] [-i count] [-d disk]* [-t name] vmctl status [id] vmctl stop [id|-a] [-fw] vmctl pause id vmctl unpause id vmctl send id vmctl receive id $ So, what's special about rcctl? t > >> >> >>> >>> execve() returns ENOEXEC if the file doesn't have the right magic header. sh >>> will attempt to interpret the file as a script after that error, but i don't >>> think doas should have such a fallback. it may not be a sh script, and then >>> weird and possibly bad things will happen (has happened before). >
Re: bgpd: announce loopback / local prefix
Le lun. 29 oct. 2018 à 22:44, Claudio Jeker a écrit : > > This is a problem of the parser. Use "42" with the quotes to make the > number a string. Or use a non-digit label (as you figured out already). Thanks Claudio, this is a handy workaround.
Re: bgpd: announce loopback / local prefix
On Mon, Oct 29, 2018 at 10:26:40PM +0100, Pierre Emeriaud wrote: > Le lun. 29 oct. 2018 à 22:04, Claudio Jeker a > écrit : > > > > Another option is to set the rtlabel on the interface and then use network > > rtlabel to redistribute it. > > I tried that, but it's refused by bgpd parser: > > $ doas bgpd -n > /etc/bgpd.conf:39: syntax error > $ doas nl -ba -nln /etc/bgpd.conf | grep ^39 > 39 network inet6 rtlabel 42 > > I do have routes with this label: > $ route -n show -label 42 > Internet6: > DestinationGateway > Flags Refs Use Mtu Prio Iface > 2001:db8:3cc:10:1000::12001:db8:3cc:10:1000::1UHl > 00 32768 1 lo0 > > I wanted to upgrade to 6.4 before re-trying that, this is done, but no > luck. Am I missing something obvious? This is a problem of the parser. Use "42" with the quotes to make the number a string. Or use a non-digit label (as you figured out already). -- :wq Claudio
Firefox requires pledge customization when home is on NFS
Posting this here for documentation purposes:
After the 6.4 / Firefox 63.0 upgrade the ublock/umatrix addons in
Firefox stopped working.
After some discussion with landry@ it turned out that the root cause is
that my home folder is on NFS. This causes a pledge violation, as seen
in these log records:
firefox[24601]: pledge "getpw", syscall 33
The fix is to open the Firefox configuration ("about:config") and add
"getpw" to the "security.sandbox.pledge.content" parameter.
/Robert
Re: bgpd: announce loopback / local prefix
Le lun. 29 oct. 2018 à 22:26, Pierre Emeriaud a écrit : > > Le lun. 29 oct. 2018 à 22:04, Claudio Jeker a > écrit : > > > > Another option is to set the rtlabel on the interface and then use network > > rtlabel to redistribute it. > > I tried that, but it's refused by bgpd parser: > > $ doas bgpd -n > /etc/bgpd.conf:39: syntax error > $ doas nl -ba -nln /etc/bgpd.conf | grep ^39 > 39 network inet6 rtlabel 42 Erm, this works with a text-only label: $ route -n show -label foo Internet6: DestinationGateway Flags Refs Use Mtu Prio Iface 2001:db8:3cc:10:1000::12001:db8:3cc:10:1000::1UHl 00 32768 1 lo0 $ doas nl -ba -nln /etc/bgpd.conf | grep ^39 39 network inet6 rtlabel foo $ doas bgpd -n configuration OK
Re: bgpd: announce loopback / local prefix
Le lun. 29 oct. 2018 à 22:04, Claudio Jeker a écrit : > > Another option is to set the rtlabel on the interface and then use network > rtlabel to redistribute it. I tried that, but it's refused by bgpd parser: $ doas bgpd -n /etc/bgpd.conf:39: syntax error $ doas nl -ba -nln /etc/bgpd.conf | grep ^39 39 network inet6 rtlabel 42 I do have routes with this label: $ route -n show -label 42 Internet6: DestinationGateway Flags Refs Use Mtu Prio Iface 2001:db8:3cc:10:1000::12001:db8:3cc:10:1000::1UHl 00 32768 1 lo0 I wanted to upgrade to 6.4 before re-trying that, this is done, but no luck. Am I missing something obvious?
Re: bgpd: announce loopback / local prefix
On Mon, Oct 29, 2018 at 09:51:46PM +0100, Pierre Emeriaud wrote: > Le lun. 29 oct. 2018 à 14:43, Pierre Emeriaud > a écrit : > > > > Is there a good way to redistribute those local prefixes? like what > > "network local" would do. > > denis@ informed me about the recently introduced "network inet6 > priority 1", I guess that could fit with some appropriate filtering. > Thanks! Another option is to set the rtlabel on the interface and then use network rtlabel to redistribute it. -- :wq Claudio
Re: bgpd: announce loopback / local prefix
Le lun. 29 oct. 2018 à 14:43, Pierre Emeriaud a écrit : > > Is there a good way to redistribute those local prefixes? like what > "network local" would do. denis@ informed me about the recently introduced "network inet6 priority 1", I guess that could fit with some appropriate filtering. Thanks!
Re: Monit logs vfprintf %s NULL in "%s" all the time
W dniu 29/10/2018 o 19:24, Caspar Schutijser pisze: (...) which seems to solve the same problem that you are experiencing. Ok, if this is a known problem, I'll upgrade. Thanks. Best regards, Chris
Re: Monit logs vfprintf %s NULL in "%s" all the time
Hi Chris, On Mon, Oct 29, 2018 at 12:09:29AM +, Chris Narkiewicz wrote: > I'm running Monit to look at few services on OpenBSD 6.3 and I'm logging > to syslog. > > In my /var/log/messages I routinely observe the following log entries: > > Oct 27 22:00:01 alpha syslogd[97814]: restart > Oct 27 22:00:02 alpha monit: vfprintf %s NULL in "%s" > Oct 27 22:00:32 alpha last message repeated 11 times > Oct 27 22:02:32 alpha last message repeated 24 times > Oct 27 22:12:33 alpha last message repeated 120 times > Oct 27 22:22:33 alpha last message repeated 120 times > ...and so on... > > Monit is installed from ports. > > $ monit --version > This is Monit version 5.25.1 Can you upgrade to OpenBSD 6.4 and see whether the problem persists? After OpenBSD 6.3 was released, a patch was backported to the monit port [1] (and subsequently removed because the monit port was upgraded to a new upstream version) which seems to solve the same problem that you are experiencing. Thanks, Caspar Schutijser [1] https://cvsweb.openbsd.org/ports/sysutils/monit/patches/Attic/patch-src_process_ProcessTree_c
Re: vmm(4) on apu2c4
On Mon, Oct 29, 2018 at 10:25:41AM +0100, Klemens Nanni wrote: > On Mon, Oct 29, 2018 at 01:38:18AM -0700, Mike Larkin wrote: > > does dmesg have a vmm0: SVM/RVI line? > Yes. > Then it should work. Does it not?
bgpd: announce loopback / local prefix
Hello misc, I'm currently advertising my prefix with "network $mynet", so as redistributing connected networks with "network (inet6) connected". However, loopback prefixes are not announced. They are seen as local instead of connected: $ route -n get 2001:db8:3cc:10:1000::1/128 route to: 2001:db8:3cc:10:1000::1 destination: 2001:db8:3cc:10:1000::1 mask: ::::::: interface: lo0 if address: 2001:db8:3cc:10:1000::1 priority: 1 (local) flags: use mtuexpire 0 32768 0 true connected/interface prefix: $ route -n get 2001:db8:3cc:201::/64 route to: 2001:db8:3cc:201:: destination: 2001:db8:3cc:201:: mask: ::::: interface: em0 if address: 2001:db8:3cc:201::2 priority: 4 (connected) flags: use mtuexpire 16 0 0 $ bgpctl show net flags: S = Static flags destination *S 0 2001:db8:3cc::/48:: (truly static w/ "network $mynet") *S 0 2001:db8:3cc:200::/64 :: (actually connected instead of static) *S 0 2001:db8:3cc:201::/64 :: (same) Is there a good way to redistribute those local prefixes? like what "network local" would do. I currently use "bgpctl network add", but I have to remember to do (or net del) it every time I add a service prefix on the loopback interface... thanks.
Re: pcppi boot hang
No, I don't have speaker connected. Do you think, connecting speaker can solve the problem? 29.10.2018 11:28, Katherine Rohl пишет: I have that same motherboard and I don’t have any problems with pcppi... Do you have a PC speaker hooked up? I’d just disable the driver completely if not. On Oct 29, 2018, at 3:47 AM, kasak wrote: hello everybody! i have ASUS Z170-K board with i7-6700 CPU. It has a problem, it hangs on boot when probing pcppi0. Every time when i have to reboot i enter UKC and disable pcppi, only after that i can boot. Is there any workaround to this ?
Re: Replacing old versions of Android with OpenBSD
While the idea seems fantastic upon the first glance, I'm afraid that OpenBSD's no-blob policy would not be compatible with the humongous amounts of blobs and proprietary drivers needed to run just about everything on mobile devices. Have you already thought of a particular device to do it on? V V pon., 29. okt. 2018 ob 07:23 je oseba Jyri Hovila [Turvamies.fi] < jyri.hov...@turvamies.fi> napisala: > Hi everyone! > > There used to be a project called GreenOS, with plans on creating a > FreeBSD based OS for Android devices: > > > https://www.freebsdnews.com/2012/07/09/greenos-freebsd-based-project-android-devices/ > > Has anybody here had plans (or tried out?) hacking OpenBSD into some old, > rootable Android handset? > > I'd be interested in setting up a little project around this idea. There's > no need to worry about any of the 3G/4G stuff at first -- it would be more > than enough just to see OpenBSD booting on an ex-Android device. > > -j. > -- > +358-404-177133 (24/7) > jyri.hov...@turvamies.fi > > -- Kristjan Komloši
Re: bgpctl not showing rib entries, pftables empty
On 29 Oct 2018, at 20:17, Claudio Jeker wrote:
> On Mon, Oct 29, 2018 at 09:30:44AM +0100, Peter Hessler wrote:
>> Hi Ashe
>>
>> Sorry about that, I forgot a part of the config file.
>>
>> You'll need to add "nexthop qualify via default" to the global part of
>> the configuration. Since the routers sending you the information are
>> not on your local link, there isn't a valid nexthop so the routes are
>> not selected. Once the nexthops are accepted, the prefixes will be
>> processed and will be used.
>
> Also don't forget the default deny policy of 6.4. Looking at the config it
> seems there is no 'allow from group "spam-bgp"' and so nothing is put into
> the RIB.
And just like that:
--8<--
elisheva:~$ cat /etc/bgpd.conf
spam_rs1="64.142.121.62"
spam_rs2="217.31.80.170"
spam_asn="65066"
AS 65500
fib-update no
nexthop qualify via default
group "spam-bgp" {
remote-as $spam_asn
multihop 64
export none
neighbor $spam_rs1
neighbor $spam_rs2
}
match from group "spam-bgp" community $spam_asn:42 set pftable
"bgp_spamd_bypass"
match from group "spam-bgp" community $spam_asn:666 set pftable "bgp_spamd"
allow from group "spam-bgp"
elisheva:~$ bgpctl show
Neighbor ASMsgRcvdMsgSent OutQ Up/Down State/PrfRcvd
217.31.80.170 65066222103 0 00:49:51 37172
64.142.121.62 65066226103 0 00:49:52 37172
elisheva:~$ bgpctl show rib | wc -l
74350
elisheva:~$
--8<--
Thank you so much, both!
Ashe
Re: vmm(4) on apu2c4
On Mon, Oct 29, 2018 at 01:38:18AM -0700, Mike Larkin wrote: > does dmesg have a vmm0: SVM/RVI line? Yes.
Re: bgpctl not showing rib entries, pftables empty
On Mon, Oct 29, 2018 at 09:30:44AM +0100, Peter Hessler wrote:
> Hi Ashe
>
> Sorry about that, I forgot a part of the config file.
>
> You'll need to add "nexthop qualify via default" to the global part of
> the configuration. Since the routers sending you the information are
> not on your local link, there isn't a valid nexthop so the routes are
> not selected. Once the nexthops are accepted, the prefixes will be
> processed and will be used.
Also don't forget the default deny policy of 6.4. Looking at the config it
seems there is no 'allow from group "spam-bgp"' and so nothing is put into
the RIB.
> -peter
>
>
> On 2018 Oct 29 (Mon) at 03:37:23 + (+), Ashe Connor wrote:
> :Hi all,
> :
> :I’ve set up bgpd for use with bgp-spamd.net’s servers. As far as I can
> tell, the BGP connection and transfer is working fine:
> :
> :--8<--
> :elisheva:~$ cat /etc/bgpd.conf
> :spam_rs1="64.142.121.62"
> :spam_rs2="217.31.80.170"
> :spam_asn="65066"
> :
> :AS 65500
> :fib-update no
> :
> :group "spam-bgp" {
> :remote-as $spam_asn
> :multihop 64
> :export none
> :neighbor $spam_rs1
> :neighbor $spam_rs2
> :}
> :
> :match from group "spam-bgp" community $spam_asn:42 set pftable
> "bgp_spamd_bypass"
> :match from group "spam-bgp" community $spam_asn:666 set pftable "bgp_spamd"
> :elisheva:~$ bgpctl show
> :Neighbor ASMsgRcvdMsgSent OutQ Up/Down
> State/PrfRcvd
> :217.31.80.170 65066410322 0 02:39:41 37096
> :64.142.121.62 65066460318 0 01:25:30 37096
> :elisheva:~$ bgpctl show rib memory
> :RDE memory statistics
> : 37096 IPv4 unicast network entries using 1.4M of memory
> : 37096 rib entries using 2.3M of memory
> : 74192 prefix entries using 6.8M of memory
> :10 BGP path attribute entries using 1.1K of memory
> : 2 BGP AS-PATH attribute entries using 82B of memory,
> : and holding 10 references
> : 7 BGP attributes entries using 280B of memory
> : and holding 10 references
> : 7 BGP attributes using 48B of memory
> :RIB using 10.5M of memory
> :
> :RDE hash statistics
> :path hash: size 131072, 10 entires
> :min 0 max 2 avg/std-dev = 0.000/0.000
> :aspath hash: size 131072, 2 entires
> :min 0 max 1 avg/std-dev = 0.000/0.000
> :attr hash: size 16384, 7 entires
> :min 0 max 1 avg/std-dev = 0.000/0.000
> :--8<--
> :
> :However, despite the entry counts being shown by `bgpctl show rib memory`,
> no other command lists entries as one might expect, and the pf tables are
> empty:
> :
> :--8<--
> :elisheva:~$ bgpctl show rib
> :flags: * = Valid, > = Selected, I = via IBGP, A = Announced,
> : S = Stale, E = Error
> :origin validation state: N = not-found, V = valid, ! = invalid
> :origin: i = IGP, e = EGP, ? = Incomplete
> :
> :flags ovs destination gateway lpref med aspath origin
> :elisheva:~$ bgpctl show rib community 65066:42
> :flags: * = Valid, > = Selected, I = via IBGP, A = Announced,
> : S = Stale, E = Error
> :origin validation state: N = not-found, V = valid, ! = invalid
> :origin: i = IGP, e = EGP, ? = Incomplete
> :
> :flags ovs destination gateway lpref med aspath origin
> :elisheva:~$ doas pfctl -Ts -t bgp_spamd
> :elisheva:~$ doas pfctl -Ts -t bgp_spamd_bypass
> :elisheva:~$
> :--8<--
> :
> :Any hints as to how to further diagnose? I’ve tried most conceivable
> additional arguments to `bgpctl show rib` and I haven’t found a way to list
> entries yet. Log entries are benign ((re)configuration success messages).
> :
> :Thanks,
> :
> :Ashe
> :
>
> --
> For those who like this sort of thing, this is the sort of thing they like.
> -- Abraham Lincoln
>
--
:wq Claudio
Re: vmm(4) on apu2c4
miracu...@gmail.com (Thomas Huber), 2018.10.29 (Mon) 08:27 (CET): > Hi misc, > > is vmm(4) working on the PC-Engines APU2 with -release 6.4 ? > I thought I've read something like that a view months ago but can not find > any further information about which CPU-Feature is needed and how it is > named at the AMD. > > This are the CPU-Specs for the APU2: > "AMD Embedded G series GX-412TC, 1 GHz quad Jaguar core with 64 bit and > AES-NI support, 32K data + 32K instruction cache per core, shared 2MB L2 > cache." The test from faq16.html, on pcengines apu2c4: $ dmesg | egrep '(VMX/EPT|SVM/RVI)' vmm0 at mainbus0: SVM/RVI A little more info: $ dmesg | grep -e apu -e vmm0 -e GX-412TC bios0: PC Engines PC Engines apu4 cpu0: AMD GX-412TC SOC, 998.31 MHz cpu1: AMD GX-412TC SOC, 998.26 MHz cpu2: AMD GX-412TC SOC, 998.15 MHz cpu3: AMD GX-412TC SOC, 998.31 MHz vmm0 at mainbus0: SVM/RVI Following faq16.html I got: $ vmctl show ID PID VCPUS MAXMEM CURMEM TTYOWNER NAME 3 15040 11.0G1.0M ttyp1 root example Marcus
Re: vmm(4) on apu2c4
On Mon, Oct 29, 2018 at 08:27:31AM +0100, Thomas Huber wrote: > Hi misc, > > is vmm(4) working on the PC-Engines APU2 with -release 6.4 ? > I thought I've read something like that a view months ago but can not find > any further information about which CPU-Feature is needed and how it is > named at the AMD. > > This are the CPU-Specs for the APU2: > "AMD Embedded G series GX-412TC, 1 GHz quad Jaguar core with 64 bit and > AES-NI support, 32K data + 32K instruction cache per core, shared 2MB L2 > cache." > > Thanks! > --mirac does dmesg have a vmm0: SVM/RVI line?
Re: bgpctl not showing rib entries, pftables empty
Hi Ashe
Sorry about that, I forgot a part of the config file.
You'll need to add "nexthop qualify via default" to the global part of
the configuration. Since the routers sending you the information are
not on your local link, there isn't a valid nexthop so the routes are
not selected. Once the nexthops are accepted, the prefixes will be
processed and will be used.
-peter
On 2018 Oct 29 (Mon) at 03:37:23 + (+), Ashe Connor wrote:
:Hi all,
:
:I’ve set up bgpd for use with bgp-spamd.net’s servers. As far as I can tell,
the BGP connection and transfer is working fine:
:
:--8<--
:elisheva:~$ cat /etc/bgpd.conf
:spam_rs1="64.142.121.62"
:spam_rs2="217.31.80.170"
:spam_asn="65066"
:
:AS 65500
:fib-update no
:
:group "spam-bgp" {
:remote-as $spam_asn
:multihop 64
:export none
:neighbor $spam_rs1
:neighbor $spam_rs2
:}
:
:match from group "spam-bgp" community $spam_asn:42 set pftable
"bgp_spamd_bypass"
:match from group "spam-bgp" community $spam_asn:666 set pftable "bgp_spamd"
:elisheva:~$ bgpctl show
:Neighbor ASMsgRcvdMsgSent OutQ Up/Down
State/PrfRcvd
:217.31.80.170 65066410322 0 02:39:41 37096
:64.142.121.62 65066460318 0 01:25:30 37096
:elisheva:~$ bgpctl show rib memory
:RDE memory statistics
: 37096 IPv4 unicast network entries using 1.4M of memory
: 37096 rib entries using 2.3M of memory
: 74192 prefix entries using 6.8M of memory
:10 BGP path attribute entries using 1.1K of memory
: 2 BGP AS-PATH attribute entries using 82B of memory,
: and holding 10 references
: 7 BGP attributes entries using 280B of memory
: and holding 10 references
: 7 BGP attributes using 48B of memory
:RIB using 10.5M of memory
:
:RDE hash statistics
:path hash: size 131072, 10 entires
:min 0 max 2 avg/std-dev = 0.000/0.000
:aspath hash: size 131072, 2 entires
:min 0 max 1 avg/std-dev = 0.000/0.000
:attr hash: size 16384, 7 entires
:min 0 max 1 avg/std-dev = 0.000/0.000
:--8<--
:
:However, despite the entry counts being shown by `bgpctl show rib memory`, no
other command lists entries as one might expect, and the pf tables are empty:
:
:--8<--
:elisheva:~$ bgpctl show rib
:flags: * = Valid, > = Selected, I = via IBGP, A = Announced,
: S = Stale, E = Error
:origin validation state: N = not-found, V = valid, ! = invalid
:origin: i = IGP, e = EGP, ? = Incomplete
:
:flags ovs destination gateway lpref med aspath origin
:elisheva:~$ bgpctl show rib community 65066:42
:flags: * = Valid, > = Selected, I = via IBGP, A = Announced,
: S = Stale, E = Error
:origin validation state: N = not-found, V = valid, ! = invalid
:origin: i = IGP, e = EGP, ? = Incomplete
:
:flags ovs destination gateway lpref med aspath origin
:elisheva:~$ doas pfctl -Ts -t bgp_spamd
:elisheva:~$ doas pfctl -Ts -t bgp_spamd_bypass
:elisheva:~$
:--8<--
:
:Any hints as to how to further diagnose? I’ve tried most conceivable
additional arguments to `bgpctl show rib` and I haven’t found a way to list
entries yet. Log entries are benign ((re)configuration success messages).
:
:Thanks,
:
:Ashe
:
--
For those who like this sort of thing, this is the sort of thing they like.
-- Abraham Lincoln
Re: pcppi boot hang
I have that same motherboard and I don’t have any problems with pcppi... Do you have a PC speaker hooked up? I’d just disable the driver completely if not. > On Oct 29, 2018, at 3:47 AM, kasak wrote: > > hello everybody! > > i have ASUS Z170-K board with i7-6700 CPU. > > It has a problem, it hangs on boot when probing pcppi0. > > Every time when i have to reboot i enter UKC and disable pcppi, only after > that i can boot. > > Is there any workaround to this ? >
pcppi boot hang
hello everybody! i have ASUS Z170-K board with i7-6700 CPU. It has a problem, it hangs on boot when probing pcppi0. Every time when i have to reboot i enter UKC and disable pcppi, only after that i can boot. Is there any workaround to this ?
Re: Benchmarking kernel, userland and Xenocara build processes
On Mon, Oct 29, 2018 at 08:11:03AM +0200, Jyri Hovila [Turvamies.fi] wrote: > Hi, > > just for the record, and to inform others who may still be at loss regarding > this matter: when compiling stuff (particularly Big Stuff, such as the > userland) on an OpenBSD machine with several CPU cores, it's important to > pass the '-j ' argument to the make command, in order to > benefit from the (much) reduced compiling time. > > It would probably make sense to add a tip to the Building the system from > source FAQ and/or the release man page. > > I feel so, so newbie... =P This assumes everything is parallel-make safe. It didn't use to be, and I'm pretty sure make release is still not parallel safe on all architectures... The number of jobs in make is NOT that straightforward either. You'll have to measure to figure out the best number. On high numbers of cores, going THAT high with -j is generally counter-productive...
vmm(4) on apu2c4
Hi misc, is vmm(4) working on the PC-Engines APU2 with -release 6.4 ? I thought I've read something like that a view months ago but can not find any further information about which CPU-Feature is needed and how it is named at the AMD. This are the CPU-Specs for the APU2: "AMD Embedded G series GX-412TC, 1 GHz quad Jaguar core with 64 bit and AES-NI support, 32K data + 32K instruction cache per core, shared 2MB L2 cache." Thanks! --mirac
Replacing old versions of Android with OpenBSD
Hi everyone! There used to be a project called GreenOS, with plans on creating a FreeBSD based OS for Android devices: https://www.freebsdnews.com/2012/07/09/greenos-freebsd-based-project-android-devices/ Has anybody here had plans (or tried out?) hacking OpenBSD into some old, rootable Android handset? I'd be interested in setting up a little project around this idea. There's no need to worry about any of the 3G/4G stuff at first -- it would be more than enough just to see OpenBSD booting on an ex-Android device. -j. -- +358-404-177133 (24/7) jyri.hov...@turvamies.fi
Re: Benchmarking kernel, userland and Xenocara build processes
Hi, just for the record, and to inform others who may still be at loss regarding this matter: when compiling stuff (particularly Big Stuff, such as the userland) on an OpenBSD machine with several CPU cores, it's important to pass the '-j ' argument to the make command, in order to benefit from the (much) reduced compiling time. It would probably make sense to add a tip to the Building the system from source FAQ and/or the release man page. I feel so, so newbie... =P Thanks to tfrohwein! -j. -- +358-404-177133 (24/7) jyri.hov...@turvamies.fi
