Re: does 'xset(1) dpms 20' activate xidle(1) after 20sec?
On Wed, Nov 28, 2018 at 10:56:13AM +0100, Marcus MERIGHI wrote: > j...@openbsd.org (joshua stein), 2018.11.27 (Tue) 18:12 (CET): > > On Tue, 27 Nov 2018 at 14:32:50 +0100, Marcus Merighi wrote: > > > does 'xset(1) dpms 20' activate xidle(1) after 20 seconds? > > > > > > How to repeat: > > > > > > $ xset dpms 20 > > > $ xidle -timeout 180 & > > > > > > With this I am locked out after 20 seconds, not 180. > > > > The DPMS event activates the X screensaver which generates an X > > event that xidle is listening for. xidle then runs its specified > > program (or defaults to xlock). > > Thanks for confirming and the explanation of the cause! > > I know you are having piles of experience with OpenBSD on all sorts of > fancy hardware... what do you do for dimming the display and locking? This is what I use to give myself a three second grace period between the screen going blank and the lock kicking in. The scroll lock led was for fun and cosmetics. $ egrep '^xidle|^xlock' .Xresources xidle.*.timeout: 300 xidle.*.delay: 9 xlock.*.lockdelay: 3 xlock.*.startCmd: xset dpms 3; sleep 3; xset led named "Scroll Lock" xlock.*.endCmd: xset -dpms; xset -led named "Scroll Lock" I start xidle in my ~.xsession /Alesxander
Re: PF Outbound traffic Load Balancing over multiple tun/openvpn interfaces/tunnels
Hi,
So for completeness, I did some more testing with your suggestions.
First I tried using different nexthop’s in each of the interface-nexthop pairs
in the route-to pool (as the next hop doesn’t really matter with p2p
interfaces). And it did start to work! :)
But after some more testing it still wasn’t behaving very well, and was nearly
always using the first tunX defined.. (I didn’t do much more testing). And if I
ran a bunch of downloads to load test, they all ended up on tun1..
I had never heard of the ‘pair’ interfaces before, but as soon as I realised
what they were I realised what a great idea! :)
So I created multiple pairs of ‘pair’ interfaces, one pair member in the
default rdomain along with the internal interface, and the other pair member in
the relevant vpn rdomain along with the tun interface. I.e. Creating an rdomain
tunnel between domain 0 and each vpn rdomain.
This allowed me to configure unique none-overlapping subnets on each of the
‘pair’ based p2p tunnels.
And that of course simplified the ‘route-to’ statement to just be a list of
different next-hops; one for each of the ‘pair’ interfaces in the default
rdomain, for each vpn (without needing to define the interfaces as they are all
in rdomain 0).
So without requiring PF to do any rdomain jumping/tunnelling (leaving rdomain
tunnelling to the ‘pair’ interfaces), vpn load balancing is now working really
very well.
I can now utilise all the cpu cores on my router where I couldn’t before :) I
have four real cores, so I’m running four OpenVPN tunnels :D
This appears to confirm that ‘route-to’ only works well for rdomain tunnelling
when routing towards a single rdomain, per pf configuration line.
I guess Henning would need to pass his wisdom on this and decide if it’s a bug
or just not supported yet.
Thanks guys :)
> On 28 Nov 2018, at 06:04, Tom Smyth wrote:
>
> Sorry the "here" I was referring to earlier was "here" as shown below
> https://lab.rickauer.com/post/2017/07/16/OpenBSD-rtables-and-rdomains
>
>
>> Howdy...
>> starting Openvpn in different rdomains works pretty well for us
>>
>> a crude way of doing that ... is to add the following line to the
>> bottom of your tun interface...
>> (starting openvpn in rdomain2 )
>>
>> !/sbin/route -T 2 exec /usr/local/sbin/openvpn --config
>> /etc/openvpn2.conf & /usr/bin/false
>>
>> we were using the L2 tunnels (not l3) ... but this worked pretty well for us
>>
>> you I think you can use rcctl and set rtable also as described very well
>> here
>>
>> using symbolic links in /etc/rc.d/ you can create multiple openvpn
>> services, each with their own
>> settings...
>> I hope this helps
>>
>>
>>
>>> On Wed, 28 Nov 2018 at 02:59, Philip Higgins wrote:
>>>
>>> At a guess, route-to is confused by the same ip, but I haven't looked at
>>> the internals.
>>>
>>> Maybe try adding pair interfaces (with different addresses) to each rdomain,
>>> and you can use route-to to select between them.
>>> You already have default route set in each rdomain, so it will find its way
>>> from there.
>>>
>>> eg.
>>>
>>> # /etc/hostname.pair1
>>> group pinternal
>>> rdomain 1
>>> inet 10.255.1.1 255.255.255.0
>>> !/sbin/route -T1 add 10.255.1.2
>>>
>>> # /etc/hostname.pair11
>>> group pinternal
>>> inet 10.255.1.2 255.255.255.0
>>> patch pair1
>>>
>>> # /etc/hostname.pair2
>>> group pinternal
>>> rdomain 2
>>> inet 10.255.2.1 255.255.255.0
>>> !/sbin/route -T2 add 10.255.2.2
>>>
>>> # /etc/hostname.pair12
>>> group pinternal
>>> inet 10.255.2.2 255.255.255.0
>>> patch pair2
>>>
>>> # /etc/pf.conf
>>> ...
>>> pass on pinternal
>>> ...
>>> pass in quick on { $if_int } to any route-to { 10.255.1.1, 10.255.2.1 } \
>>> round-robin set prio (3,6)
>>>
>>> Have not tested exactly this, but similar to my current setup.
>>> Might not need the static routes, if the right pf magic is happening.
>>>
>>>
>>> -Phil
>>>
> On 28/11/18 8:18 am, Andrew Lemin wrote:
Hi,
So using the information Stuart and Andreas provided, I have been testing
this (load balancing across multiple VPN servers to improve bandwidth).
And I have multiple VPNs working properly within there own rdomains.
* However 'route-to' is not load balancing with rdomains :(
I have not been able to use the more simple solution you highlighted Stuart
(using basic multipath routing), as the tunnel subnets overlap.
So I think this is a potential bug, but I need your wisdom to verify my
working first :)
Re; Load Balancing SSL VPNs using OpenBSD 6.4, with VPN TunX interfaces in
unique rdomains (overlapping tunnel subnets)
Configure sysctl's
# Ensure '/etc/sysctl.conf' contains;
net.inet.ip.forwarding=1# Permit forwarding (routing) of packets
net.inet.ip.multipath=1 # 1=Enable IP multipath routing
# Active sysctl's now without reboot
sysctl net.inet.ip.forwarding=1
Re: icmp6_reflect misbehaviour ?
On Wed, Nov 28, 2018 at 06:33:23PM -0200, Martin Pieuchot wrote: > On 28/11/18(Wed) 17:48, Stuart Henderson wrote: > > On 2018-11-27, Arnaud BRAND wrote: > > > Good evening everyone, > > > > > > I am stuck with a IPv6 traceroute problem in an OSPFv3 environment. > > > > > > Long story short : > > > - IPv6 routes are propagated using OSPFv3 > > > - so they are installed with link-local gateways in the fib > > > - ICMPv6 "time exceeded" packets are generated with link-local source > > > address > > > - these packets are not to be routed so they do not get past the next > > > hop > > > - the endpoint never receives the "time exceeded packets" > > > > > > This of course is only true if the router generating the icmp packet is > > > not the endpoint, but only a hop in the path. > > > > > > I checked the code (or at least tried to). > > > It seems like it's in function icmp6_reflect in file icmp6.c at lines > > > 1144/1147. > > > > > > This code (if I understood it correctly) : > > > - fetches the route to the destination > > > - gets the interface source address for this route > > > - uses it as the source for the generated IP packet > > > > > > As my routes are installed with link-local addresses by OSPFv3, I get a > > > generated packet with a link local source-address. > > > The problem is when the destination is not on the local subnet : the > > > generated packet is unroutable and never makes it to its destination > > > > > > Would it be better to try to find another address on the interface that > > > is not link local if the destination address isn't on the interface > > > subnets ? > > That could be a solution. But if you do that, why don't you attach the > routes to a routable address in the first place? > > Why is ospfd(8) not doing that? ospf6d is using link-local addresses for nexthops because the standard says so. It is indeed an annoyance that some systems bypass by using a loopback IP for all ICMP packates. -- :wq Claudio
Re: icmp6_reflect misbehaviour ?
On 2018/11/28 18:33, Martin Pieuchot wrote: > That could be a solution. But if you do that, why don't you attach the > routes to a routable address in the first place? > > Why is ospfd(8) not doing that? It's how the OSPFv3 protocol works for IPv6 addresses, it doesn't know the globally-routable address for the interface (AFAIK it doesn't even *need* a globally routable address on the interface - can just have link-locals there and one global address, e.g. just on a loopback address).
Re: icmp6_reflect misbehaviour ?
Le 2018-11-28 21:33, Martin Pieuchot a écrit : On 28/11/18(Wed) 17:48, Stuart Henderson wrote: On 2018-11-27, Arnaud BRAND wrote: > Good evening everyone, > > I am stuck with a IPv6 traceroute problem in an OSPFv3 environment. > > Long story short : > - IPv6 routes are propagated using OSPFv3 > - so they are installed with link-local gateways in the fib > - ICMPv6 "time exceeded" packets are generated with link-local source > address > - these packets are not to be routed so they do not get past the next > hop > - the endpoint never receives the "time exceeded packets" > > This of course is only true if the router generating the icmp packet is > not the endpoint, but only a hop in the path. > > I checked the code (or at least tried to). > It seems like it's in function icmp6_reflect in file icmp6.c at lines > 1144/1147. > > This code (if I understood it correctly) : > - fetches the route to the destination > - gets the interface source address for this route > - uses it as the source for the generated IP packet > > As my routes are installed with link-local addresses by OSPFv3, I get a > generated packet with a link local source-address. > The problem is when the destination is not on the local subnet : the > generated packet is unroutable and never makes it to its destination > > Would it be better to try to find another address on the interface that > is not link local if the destination address isn't on the interface > subnets ? That could be a solution. But if you do that, why don't you attach the routes to a routable address in the first place? Why is ospfd(8) not doing that? I'm not 100% sure, but afaik that's standard behavior for ospf6d. At least that's what I have seen on the few different brands I've worked with so far. The old thread contains more information imho, so I'm gonna revive it.
Re: icmp6_reflect misbehaviour ?
On 28/11/18(Wed) 17:48, Stuart Henderson wrote: > On 2018-11-27, Arnaud BRAND wrote: > > Good evening everyone, > > > > I am stuck with a IPv6 traceroute problem in an OSPFv3 environment. > > > > Long story short : > > - IPv6 routes are propagated using OSPFv3 > > - so they are installed with link-local gateways in the fib > > - ICMPv6 "time exceeded" packets are generated with link-local source > > address > > - these packets are not to be routed so they do not get past the next > > hop > > - the endpoint never receives the "time exceeded packets" > > > > This of course is only true if the router generating the icmp packet is > > not the endpoint, but only a hop in the path. > > > > I checked the code (or at least tried to). > > It seems like it's in function icmp6_reflect in file icmp6.c at lines > > 1144/1147. > > > > This code (if I understood it correctly) : > > - fetches the route to the destination > > - gets the interface source address for this route > > - uses it as the source for the generated IP packet > > > > As my routes are installed with link-local addresses by OSPFv3, I get a > > generated packet with a link local source-address. > > The problem is when the destination is not on the local subnet : the > > generated packet is unroutable and never makes it to its destination > > > > Would it be better to try to find another address on the interface that > > is not link local if the destination address isn't on the interface > > subnets ? That could be a solution. But if you do that, why don't you attach the routes to a routable address in the first place? Why is ospfd(8) not doing that?
Re: AWS
Hello Ahmad, Yes, it is definitely possible, and I have been running openbsd on AWS for a few years. When I initially set it up, I used the following: https://github.com/ajacoutot/aws-openbsd But there are other ways to do it, as outlined by the following (which I have no tried yet) : http://embaby.com/blog/deploying-openbsd-6-3-on-aws/ I guess it depends on your work/dev environment and process. Hope this helps, Regards, Youssef -- Sent from: http://openbsd-archive.7691.n7.nabble.com/openbsd-user-misc-f3.html
AWS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Everyone or Salaam Is there a easy way to use OpenBSD on AWS EC2? I'm looking for guide to do so, if its possible. I know about Vultr, but no I don't want to switch from AWS just yet. I'm currently running FreeBSD on Lightsail. Sent with ProtonMail Secure Email. -BEGIN PGP SIGNATURE- Version: ProtonMail Comment: https://protonmail.com wsBcBAEBCAAQBQJb/sRgCRD3irc5ItUgGgAA1yUIAI6BGjoTIygIMQwmf3re Ty3hnLCc4wciPynZtglZe1lyKDqkiusILR9T+IY6bsFQOGkcY/eFRBbH5Bjn mDCNXGJV2uK6SaPsTd5uz90ryvhXG+WS1g/3qgqcmwUocsfYrw4QNHkkrq9O +L/fqkGl/iqaNP4QEAozpFrSw0UO07igPjZ2GV68NZw//JgNi2qLuNvftRxB SuVMWDfTlfzVW6wVGQw8Qp7WiraAHk4JQD2GeStOB6owIx0oLuWS+M7CF73m r8zz/nFQ94vx+2nHhcW1zFxNZLvYeUjdUfEfzdr+bU4tYWGIFLY3eOA1zQsw Bzz9zOL6wrmD0KLR/ZyQD3Q= =rpLt -END PGP SIGNATURE- publickey - ssabs@protonmail.com - 0x39054E9B.asc Description: application/pgp-keys publickey - ssabs@protonmail.com - 0x39054E9B.asc.sig Description: PGP signature
Re: icmp6_reflect misbehaviour ?
Le 2018-11-28 18:48, Stuart Henderson a écrit : On 2018-11-27, Arnaud BRAND wrote: Good evening everyone, I am stuck with a IPv6 traceroute problem in an OSPFv3 environment. Long story short : - IPv6 routes are propagated using OSPFv3 - so they are installed with link-local gateways in the fib - ICMPv6 "time exceeded" packets are generated with link-local source address - these packets are not to be routed so they do not get past the next hop - the endpoint never receives the "time exceeded packets" This of course is only true if the router generating the icmp packet is not the endpoint, but only a hop in the path. I checked the code (or at least tried to). It seems like it's in function icmp6_reflect in file icmp6.c at lines 1144/1147. This code (if I understood it correctly) : - fetches the route to the destination - gets the interface source address for this route - uses it as the source for the generated IP packet As my routes are installed with link-local addresses by OSPFv3, I get a generated packet with a link local source-address. The problem is when the destination is not on the local subnet : the generated packet is unroutable and never makes it to its destination Would it be better to try to find another address on the interface that is not link local if the destination address isn't on the interface subnets ? Sadly, I can't provide a patch, sorry, I'm not that skilled in OpenBSD. I thought of a pf trickery like : pass out quick inet6 proto icmp6 from fe80::/10 to any icmp6-type timex nat-to lo1 but that won't work because the generated packet itself will be matching a state and this rule won't even be evaluated. Does anyone have an idea how I could get these icmp6 packets to reach their destination ? Thanks for your help ! Arnaud Known problem, no known workaround. I tried hard to find a way to do this with PF but I don't think there is one. bluhm@ pointed out "pf with IPv6 link-local addresses does not work properly. I think it cannot parse the %if suffixes. The KAME hack scope id is not handled" in my previous thread on this (https://marc.info/?t=15387538651=1=2). Thanks Stuart ! God, I can't understand how I missed this one. What are you guys using as a search engine to find theses messages ? I was looking at adding a call to in6_ifawithscope() after line 1144 in icmp6_reflect. Sadly I had no time to do it/test it today. Don't you reckon this would/could work ?
Re: icmp6_reflect misbehaviour ?
On 2018-11-27, Arnaud BRAND wrote: > Good evening everyone, > > I am stuck with a IPv6 traceroute problem in an OSPFv3 environment. > > Long story short : > - IPv6 routes are propagated using OSPFv3 > - so they are installed with link-local gateways in the fib > - ICMPv6 "time exceeded" packets are generated with link-local source > address > - these packets are not to be routed so they do not get past the next > hop > - the endpoint never receives the "time exceeded packets" > > This of course is only true if the router generating the icmp packet is > not the endpoint, but only a hop in the path. > > I checked the code (or at least tried to). > It seems like it's in function icmp6_reflect in file icmp6.c at lines > 1144/1147. > > This code (if I understood it correctly) : > - fetches the route to the destination > - gets the interface source address for this route > - uses it as the source for the generated IP packet > > As my routes are installed with link-local addresses by OSPFv3, I get a > generated packet with a link local source-address. > The problem is when the destination is not on the local subnet : the > generated packet is unroutable and never makes it to its destination > > Would it be better to try to find another address on the interface that > is not link local if the destination address isn't on the interface > subnets ? > Sadly, I can't provide a patch, sorry, I'm not that skilled in OpenBSD. > > I thought of a pf trickery like : > pass out quick inet6 proto icmp6 from fe80::/10 to any icmp6-type timex > nat-to lo1 > but that won't work because the generated packet itself will be matching > a state and this rule won't even be evaluated. > > Does anyone have an idea how I could get these icmp6 packets to reach > their destination ? > > Thanks for your help ! > Arnaud > > Known problem, no known workaround. I tried hard to find a way to do this with PF but I don't think there is one. bluhm@ pointed out "pf with IPv6 link-local addresses does not work properly. I think it cannot parse the %if suffixes. The KAME hack scope id is not handled" in my previous thread on this (https://marc.info/?t=15387538651=1=2).
openbsd 6.4 as guest VM on Xen cannot detect disk
Hello there, I have been struggling to create a obsd 6.4 VM on xen(4.10.1) with HVM. After booting from the CD (install64.iso as a virtual cdrom), the installer cannot detect the disk to install the OS. During the installation, the installer says: "Available disks are: none." I already have a obsd 6.0 VM instance running for a while, I tried to do the same with the installer from 6.0 (install60.iso) The installer worked fined and detected the disk as wd0 device. See below the boot console output of both versions (obsd6.4 and obsd6.0) In the obsd6.4 output, I noticed the following timeout which could explain why the disk is not detected. xbf0 at xen0 backend 0 channel 5: disk xbf0: timed out waiting for backend to connect xbf1 at xen0 backend 0 channel 5: cdrom I tried multiple configurations of guest VM on Xen, but cannot find a way to make it work with the 6.4 installer. Any idea of what could going on? Any help would be appreciated. Regards, Youssef OBSD6.4 console output -- boot> cannot open cd0a:/etc/random.seed: No such file or directory booting cd0a:/6.4/amd64/bsd.rd: 354+1500160+3892040+0+598016 [372715+111+441072+293323]=0xa208a0 entry point at 0x1000158 Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2018 OpenBSD. All rights reserved. https://www.OpenBSD.org OpenBSD 6.4 (RAMDISK_CD) #348: Thu Oct 11 13:36:16 MDT 2018 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD real mem = 1048571904 (999MB) avail mem = 1013063680 (966MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xfc001000 (11 entries) bios0: vendor Xen version "4.10.1_08-lp150.2.9" date 08/17/2018 bios0: Xen HVM domU acpi0 at bios0: rev 2 acpi0: tables DSDT FACP APIC HPET WAET SSDT SSDT acpimadt0 at acpi0 addr 0xfee0: PC-AT compat ioapic0 at mainbus0: apid 1 pa 0xfec0, version 11, 48 pins, remapped cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) CPU E3-1246 v3 @ 3.50GHz, 3492.32 MHz, 06-3c-03 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,XSAVEOPT,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: apic clock running at 99MHz acpiprt0 at acpi0: bus 0 (PCI0) acpicpu at acpi0 not configured "PNP0B00" at acpi0 not configured "ACPI0007" at acpi0 not configured pvbus0 at mainbus0: Xen 4.10 xen0 at pvbus0: features 0x2705, 32 grant table frames, event channel 1 xbf0 at xen0 backend 0 channel 5: disk xbf0: timed out waiting for backend to connect xbf1 at xen0 backend 0 channel 5: cdrom scsibus0 at xbf1: 2 targets cd0 at scsibus0 targ 0 lun 0: SCSI3 5/cdrom fixed "vkbd" at xen0: device/vkbd/0 not configured xnf0 at xen0 backend 0 channel 6: address 00:16:3e:a4:6f:cb pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel 82441FX" rev 0x02 "Intel 82371SB ISA" rev 0x00 at pci0 dev 1 function 0 not configured pciide0 at pci0 dev 1 function 1 "Intel 82371SB IDE" rev 0x00: DMA, channel 0 wired to compatibility, channel 1 wired to compatibility atapiscsi0 at pciide0 channel 0 drive 1 scsibus1 at atapiscsi0: 2 targets cd1 at scsibus1 targ 0 lun 0: ATAPI 5/cdrom removable cd1(pciide0:0:1): using PIO mode 4, DMA mode 2 pciide0: channel 1 disabled (no drives) "Intel 82371AB Power" rev 0x03 at pci0 dev 1 function 3 not configured xspd0 at pci0 dev 2 function 0 "XenSource Platform Device" rev 0x01 vga1 at pci0 dev 3 function 0 "Cirrus Logic CL-GD5446" rev 0x00 vga1: aperture needed wsdisplay1 at vga1 mux 1: console (80x25, vt100 emulation) isa0 at mainbus0 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo com0: console pckbc0 at isa0 port 0x60/5 irq 1 irq 12 pckbd0 at pckbc0 (kbd slot) wskbd0 at pckbd0: console keyboard, using wsdisplay1 softraid0 at root scsibus2 at softraid0: 256 targets root on rd0a swap on rd0b dump on rd0b erase ^?, werase ^W, kill ^U, intr ^C, status ^T Welcome to the OpenBSD/amd64 6.4 installation program. (I)nstall, (U)pgrade, (A)utoinstall or (S)hell? OBSD6.0 console output -- boot> cannot open cd0a:/etc/random.seed: No such file or directory booting cd0a:/6.0/amd64/bsd.rd: 3351980+1411120+2413568+0+585728 [72+440424+283008]=0x819cb0 entry point at 0x1001000 [7205c766, 3404, 24448b12, b4c0a304] Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2016 OpenBSD. All rights reserved. http://www.OpenBSD.org OpenBSD 6.0 (RAMDISK_CD) #2100: Tue Jul 26 13:05:59 MDT 2016 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD real mem = 1048571904 (999MB) avail mem = 1015132160 (968MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @
Re: OpenBGPD - Adding Diversity to the Route Server Landscape (ripe.net)
Why worry about HTTPS? What's to gain? Job's Twitter is very promising. - Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP - Original Message - From: "Kollar Arpad" To: misc@openbsd.org, edit...@undeady.org Sent: Wednesday, November 28, 2018 8:21:42 AM Subject: OpenBGPD - Adding Diversity to the Route Server Landscape (ripe.net) Hello, 1) fyi: https://news.ycombinator.com/item?id=18549983 -> https://labs.ripe.net/Members/claudio_jeker/openbgpd-adding-diversity-to-route-server-landscape 2) why the heck isn't there a https://openbgpd.org/ ? why is it only via plain http? I know httpS is not a holy grail, but at least it is something.. lets encrypt, like the other domains for OpenBSD? and what is with: https://openntpd.org/ - can we have https there too? Many thanks for reading. Great people! :)
OpenBGPD - Adding Diversity to the Route Server Landscape (ripe.net)
Hello, 1) fyi: https://news.ycombinator.com/item?id=18549983 -> https://labs.ripe.net/Members/claudio_jeker/openbgpd-adding-diversity-to-route-server-landscape 2) why the heck isn't there a https://openbgpd.org/ ? why is it only via plain http? I know httpS is not a holy grail, but at least it is something.. lets encrypt, like the other domains for OpenBSD? and what is with: https://openntpd.org/ - can we have https there too? Many thanks for reading. Great people! :)
Re: radeondrm failure on amd64 but not on i386?
Thus said Allan Streib on Tue, 27 Nov 2018 15:51:57 -0500: > The issue was also reported here, with no follups but more debug info: > > https://marc.info/?l=openbsd-bugs=153398230416756=2 That seems to be an identical problem, but definitely with more debug info. In my system, the card is also in a PCIe slot. By the way, it is possible to workaround the problem to some extent by just adding to sysctl.conf: machdep.allowaperture=2 X will then start up, but it won't be using the firmware. Andy -- TAI64 timestamp: 40005bfeb246
Re: Help with LibreSSL manpages
On Sunday 25 November 2018 17:36:16 Ingo Schwarze wrote: > Stephen Gregoratto wrote on Mon, Nov 26, 2018 at 12:26:21AM +1100: > > > > Would I need to fully grok the code before I could write the docs? > > Absolutely not. You could spend an infinite amount of time to > understand the code if you tried to understand everything. > Of course, there is nothing wrong with studying whatever interests > you. In addition to what Ingo has already said, I would add that I think it is actually beneficial for someone who is not highly familiar with the code to write the documentation, as it gives you a fresh set of eyes and a different perspective. You'll question and challenge things rather than accepting them at face value. However, you obviously you need to at least be able to read the code to generally understand what it is doing. Furthermore, I'd suggest that you start small (fix some typos, correct some gramatical issues) and then work up to bigger changes (rewriting poorly written documentation or creating new man mages). This will let you become familiar with the documentation style and review/commit process, with faster reviews and feedback.
Re: Boot reboot issue after upgrade to 6.4 on amd64
On Tuesday 27 November 2018 16:07:18 Riccardo Mottola wrote: > Hi Nick, > > Nick Holland wrote: > > So far, with one or two exceptions, everyone complaining about this has > > a One Big Partition disk layout. A bad idea, not suggested, and I don't > > think you will get much sympathy. > > yes of course (TM).. I won't get much sympathy, but it is the best > set-up for a dual-booting laptop it works for every OS I test and worked > until 6.3 for me. > For other set-ups I use different partitioning schemes, but I suppose in > the past twenty years or so, we all had our issues with disk layouts. > > > I know of one machine that behaves as you describe with a very modest > > (smaller than suggested) root partition, but I'm feeling very alone > > here. :D > > what is the actual size limit? from where? I wonder that I cannot even > boot the old kernel which worked.. at the previous boot! > > I cannot shuffle the partitions, I cannot even reinstall from scratch, > since I am unable to boot from an USB key with the installer image, it > crashes both the 6.4 installer image as the old 6.3. The specific "heap full" issue that can be triggered by using a single large partition is not likely to be at fault here - if you cannot boot the ramdisk (bsd.rd/installer) for 6.3 or 6.4 from a USB key, then something else is presumably up (unless you're actually trying to load the installed kernel or ramdisk from the hard disk). > All important data is backed up, but I need to reinstall at least and > cennot even do that. Of course booting abd being able to copy a last > snapshot of my home directory would be even best, to retain my profiles. > > Should I try boot from optical media? could that help? I suppose not... > > Thanks, > > > Riccardo
Re: Boot reboot issue after upgrade to 6.4 on amd64
On Tuesday 27 November 2018 21:54:36 Angelo Rossi wrote: > Sorry, > > To fix this problem I changed /usr/src/sys/arch/amd64/stand/Makefile.inc > > line #45 from > > HEAP_LIMIT=0xA > > to > > HEAP_LIMIT=0xB That may work on your machine, however it is not a change that can be safely made (at least, not without a massive amount of testing). The correct solution is to reduce the memory usage/requirements, such that it remains within the existing allocated heap size. > On Tue, Nov 27, 2018 at 9:37 PM Angelo Rossi > > wrote: > > -- Forwarded message - > > From: Angelo Rossi > > Date: Tue, Nov 27, 2018 at 9:31 PM > > Subject: Re: Boot reboot issue after upgrade to 6.4 on amd64 > > To: > > > > > > I agree with you, but it happens, anyway I found a simple trick to > > override the problem: recompile boot changing HEAP_SIZE to 1 MB. > > > > Angelo > > > > On Tue, Nov 27, 2018 at 9:28 PM Theo de Raadt wrote: > >> Angelo Rossi wrote: > >> > Now it is a bug... Nice, when me and other people posted same comment > >> > >> it wasn't! And > >> > >> > yes OpenBSD is indeed a magical OS. > >> > >> It is a bug. > >> > >> > >> And using a single large partition is idiotic, completely ignoring a > >> safety pattern built into the system. Similar to making your password > >> "1234" because your machine isn't always on the internet.
Re: Instructions to build OpenBSD for RISC-V?
On 2018 Nov 28 (Wed) at 16:30:56 +0530 (+0530), Dinesh Thirumurthy wrote: :Hi, : :Searched the list to find messages about riscv. I would :appreciate instructions on getting it to boot on spike. : :Thanks. :Dinesh Step one: write a bunch of code. OpenBSD has not been ported to RISC-V yet, so you (or someone) would have to do that work. Porting OpenBSD to any new architecture would be welcome, but so far nobody has done it. Good luck! -- Money is the root of all wealth.
Instructions to build OpenBSD for RISC-V?
Hi, Searched the list to find messages about riscv. I would appreciate instructions on getting it to boot on spike. Thanks. Dinesh
Re: does 'xset(1) dpms 20' activate xidle(1) after 20sec?
j...@openbsd.org (joshua stein), 2018.11.27 (Tue) 18:12 (CET): > On Tue, 27 Nov 2018 at 14:32:50 +0100, Marcus Merighi wrote: > > does 'xset(1) dpms 20' activate xidle(1) after 20 seconds? > > > > How to repeat: > > > > $ xset dpms 20 > > $ xidle -timeout 180 & > > > > With this I am locked out after 20 seconds, not 180. > > The DPMS event activates the X screensaver which generates an X > event that xidle is listening for. xidle then runs its specified > program (or defaults to xlock). Thanks for confirming and the explanation of the cause! I know you are having piles of experience with OpenBSD on all sorts of fancy hardware... what do you do for dimming the display and locking? Marcus
