Re: The simplest full cray data core with 3 cpu's and a physics hack that makes it work
> On 2 Apr 2021, at 14:17, Benjamin Baier wrote: > > GPT-3 gone wild, or what? Definitely to late for Aprilfools-day. > If it’s GPT-3, it’s slipping.
Re: The simplest full cray data core with 3 cpu's and a physics hack that makes it work
On Sat, 3 Apr 2021 at 10:09, Balder Oddson wrote: [...] > Many old and cool antique architectures, Cray is the premiere > architecture, he promised 10x performance and did so, not likely to get > one on ebay to boot BSD on, not sure if you can get the OS or blueprints > either. > To drag this a tiny bit toward the approximate direction of being on-topic: if you do find one and want to run OpenSSH on it, you'll need to use 7.6p1 or earlier since I removed UNICOS support in 7.7p1 ( https://github.com/openssh/openssh-portable/commit/ddc0f3814881ea279a6b6d4d98e03afc60ae1ed7 ). -- Darren Tucker (dtucker at dtucker.net) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement.
problems with outbound load-balancing (PF sticky-address for destination IPs)
Hi smart people :) The current implementation of ‘sticky-address‘ relates only to a sticky source IP. https://www.openbsd.org/faq/pf/pools.html This is used for inbound server load balancing, by ensuring that all socket connections from the same client/user/IP on the internet goes to the same server on your local server pool. This works great for ensuring simplified memory management of session artefacts on the application being hosted (the servers do not have to synchronise the users session data as extra sockets from that user will always connect to the same local server) However sticky-address does not have an equivalent for sticky destination IPs. For example when doing outbound load balancing over multiple ISP links, every single socket is load balanced randomly. This causes many websites to break (especially cookie login and single-sign-on style enterprise services), as the first outbound socket will originate randomly from one of the local ISP IPs, and the users login session/SSO (on the server side) will belong to that first random IP. When the user then browses to or uses another part of that same website which requires additional sockets, the additional sockets will pass the SSO credentials from the first socket, but the extra socket connection will again be randomly load-balanced, and so the remote server will reject the connection as it is originating from the wrong source IP etc. Therefore can I please propose a “sticky-address for destination IPs” as an analogue to the existing sticky-address for source IPs? This is now such a problem that we have to use sticky-address even on outbound load-balancing connections, which causes internal user1 to always use the same ISP for _everthing_ etc. While this does stop the breakage, it does not result in evenly distributed balancing of traffic, as users are locked to one single transit, for all their web browsing for the rest of the day after being randomly balanced once first-thing in the morning, rather than all users balancing over all transits throughout the day. Another pain; using the current source-ip sticky-address for outbound balancing, makes it hard to drain transits for maintenance. For example without source sticky-address balancing, you can just remove the transit from the Pf rule, and after some time, all traffic will eventually move over to the other transits, allowing the first to be shut down for whatever needs. But with the current source-ip sticky-address, that first transit will take months to drain in a real-world situations.. lastly just as a nice-to-have, how feasible would a deterministic load balancing algorithm be? So that balancing selection is done based on the “least utilised” path? Thanks for your time and consideration, Kindest regards Andy Sent from a teeny tiny keyboard, so please excuse typos.
Re: The simplest full cray data core with 3 cpu's and a physics hack that makes it work
On Fri, Apr 02, 2021 at 02:39:42PM +0200, Balder Oddson wrote: > Made of three processing rings, with 3 control wires, direct opposite > ring segment, and its two neighbours, this is your double data rate, or > dead beef and the global clock. The local clock is the segment and its > immediate neighbours. Stack three of them, and add a dimension in the > topology, and as many datapaths as possible between the faster parts of > the system, with digital sync between the local clock and speed of light > in vacume. Which is an architecture where scatter-gather is extremely > useful, as that works on the global clock. So a total 18 die's and a > very difficult juggling act, where cable length's are legendary for the > premium original Cray's. If you think you have a problem with your local > segment, just feed beef. > > Not many explanations of this architecture that's around, but culture > references like cult of the dead cow as a pun and wishes on those that > occupied the whole system. Anyone that's been around a real one to know? > If you want to know what's inside a cray, it's basically evil inside if > you thought that would reveal something. > Yes and no, as this likely works because: With direct wires and shortest distance and speed of light in the material as the clock. Simplest setup is one ring with 6 sockets, what's on each segment, which is a beef, or a processor as usual. Guarantees on digital sync that it knows. #1 being wrriten to, or writing to another. #2 that you are beef, and may or may not being doing a shared task. #3 idle or beef, exception level, local/global root. This being important, as the digital clock should be the same as the wired clock, where the die clock can skew just fine as long as being in the state of feedbeef or deadbeef is very tight. This being the general purpose brute force method you have, of scattering instructions in memory to your exact opposite node in the circle, with or without your neighbours. This allows wriggleroom where this may work, and where spending extra on cooling and perhaps carbon nano tubes for the wries to make this cache coherent beast fly. These pop-culture references like feedbeef, deadcow, deadbeef and feedface (terminal), likewise the temptation of calling it a scalar-vector machine data-core as its not an inefficient or rubbish architecture, just complicated about this 6 segment configuration. Due to the ability to skew, its practically going faster than the speed of light with the premiss that it is cache coherent with control wires to direct opposite node and its neighbours, not your own, with just one datapath across with wires for each segment. You SIMD and vector scatter and gather as if it werent for Cray aspirations in most things ever since. And it should be open for relying on some ideal properties and quirks. How that system would behave and make noise I don't know, but you could likely guess when it was writing the results, or gathering it in memory. Doubt this would be interesting to bitcoin, but you should be able to scrub any size link you can fit on a segment. Many old and cool antique architectures, Cray is the premiere architecture, he promised 10x performance and did so, not likely to get one on ebay to boot BSD on, not sure if you can get the OS or blueprints either.
speedtest-cli gives too bad result
Hi, I think speedtest-cli port is misbehaving.When i run speedtest-cli under OpenBSD OS it scores less then 40Mbit/s. But when i use this openbsd device as a router i can get the real internet speed which is 400mbit/s. (IP Forward + PF + NAT) I deployed an OpenBSD server on vultr.com assuming there might be a problem with my ISP. But the result was even worse. (7mbit / s) Later I installed another OS using only the change os option on vultr and I got 4380.05 Mbit / s speed as download. I think there is some oddness about speedtest-cli port of OpenBSD. Thanks for reading.
Re: Performance Degradation And acpi0 CPU Usage
I think I've found a correlation: it seems like the system gets stuck in some sort of hard power save mode once the battery hits critical, even after plugging the charger in. Has anyone seen this behavior?
How I got iked in -current to work with iOS
Hi I had some time today, and decided to send this now. This is how I got OpenBSD's iked daemon (version in current about 3/28/2021) to work with Apple's iOS (iphone/ipad's) version (about) 14.4.2. Some prelude: So, I have no real reason to do this, other than that I want to. I think of it as a learning exercise, so my knowledge is limited in many ways. I got this to work for my specific use case. Specially, I only have a few devices that I want/need to have access to my home's VPN. I do this to have a secure gateway for access to my email/calendar/files/etc when not at home (yes, I host my own services - I know that Apple and Google and other respect my privacy, etc., but ...). I have NOT tried to set this up as a VPN to route all traffic from associated devices (I don't have the a connection with the bandwidth necessary to do so). Because I am only "managing" a handful of devices, I did all of this manually. Limitations/Requirements: Apple's iOS: Recently, Apple has put several restrictions on the certificates iOS devices will accept for ikev2 connections. These are "disclosed" at https://support.apple.com/en-us/HT211025 and https://support.apple.com/en-us/HT210176. Specifically, certificates must: - CA and TLS certs using RSA must use key => 2048 - CA and TLS certs must use SHA-2 - TLS certs must have a SubjectAlternativeName with the DNS name of the server; a CommonName only is not enough For certificates issued after 7/1/2019: - ExtendedKeyUsage for TLS server and TLS client must be included - TLS certs can only be valid for 825 days or less For certificates issued by the Root CA's preinstalled in iOS, after 9/1/2020: - TLS certs can only be valid for 398 days or less OpenBSD's iked: OpenBSD ikev2 also has some specific requirements for certificate authentication. iked requires specific key/authentication combinations: - rfc7427 only supports SHA2-256 (not sure if iOS supports rfc7427) - ecdsa256 only supports P-256 with SHA2-256 - ecdsa382 only supports P-384 with SHA2-384 - ecdsa521 only supports P-521 with SHA2-512 - rsa suppors RSA but only with SHA1 Other/General: In terms of ECDSA certificates, it seems that P-256 and P-384 are the ones that are more generally accepted, and will likely continue to be generally accepted. This appears to be based on NIST's inclusion of them in their "Suite B Cryptography" information. P-521 was not included in "Suite B," and it seems some things have not included support for it. So, I concluded, to be safe (and since it seems the computational/security cost/benefit of P-384 vs P-521 is narrow), and based on the requirements above, to use P-384 with SHA2-384. My setup: Certificates: In order to do this, I used openssl commands directly. I did not use ikectl to create certs or the CA. Before I go into details, I wanted to have certs that would last longer than the Apple limit. Therefore, I needed to have a CA certificate, and TLS certs, that had a "Not Before" date before 7/1/2019. In order to do this, when I created my CA certificate, I changed the time/date on the system using "date 20190101" before creating the CA, and then reset the date when I was done. Creating back-dated TLS certs is a bit more direct, all that is necessary is to add "-startdate 2019010200Z" to the openssl ca command when signing the TLS certificate. Obviously, you need to have complete control of the CA (and not care that you are doing this) to accomplish this and get certificates with a longer time horizon for iOS. So, first I created a CA using ECDSA384: I created/edited the openssl.cnf file to have the appropriate additions/defaults I need for these certificates. I will not cover everything, but I think these are the basic requirements (I have edited out many things in the actual file I used, but I THINK what is left is all that may be really needed, but my openssl knowledge is not absolute, and I may have errors that I don't realize): (NOTE: When I was trying to get this to work, I began to believe that the current iOS has a problem with "-" [hyphens] in the CN/SAN, so I did not use them. I now am not sure if "-"'s will work or not.] General defaults for generating the signing request (csr), openssl.cnf: default_bits= 4096 default_keyfile = key.pem default_md = sha384 string_mask = utf8only distinguished_name = req_distinguished_name attributes = req_attributes The distinguished name/attributes are basically from the default cnf file. For the CA cert, openssl.cnf: basicConstraints= CA:TRUE subjectKeyIdentifier= hash authorityKeyIdentifier = keyid:always,issuer:always issuerAltName = issuer:copy For the TLS certs, when creating the signing request, openssl.cnf: basicConstraints= CA:FALSE subjectKeyIdentifier= hash authorityKeyIdentifier = keyid:always,issuer:always subjectAltName = email:move
Steve Vai froze my machine ... but most probably an amdgpu issue
On Wed, Feb 24, 2021 at 06:23:07AM +0900, rgc wrote: > On Fri, Feb 19, 2021 at 06:26:40AM +0900, rgc wrote: > > On Fri, Feb 12, 2021 at 07:02:41PM +0900, rgc wrote: > > shimer/flicker happened again once on 338. > zzz and wake-up again seems to restore things back to normal. > > updated to the following in the last few days > and haven't encountered shimer/flicker or the original issue (X crash) > > kern.version=OpenBSD 6.9-beta (GENERIC.MP) #344: Fri Feb 19 10:01:51 MST 2021 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > kern.version=OpenBSD 6.9-beta (GENERIC.MP) #350: Sun Feb 21 11:04:59 MST 2021 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP just sharing some information for those tracking down amdgpu issues no issues until today machine has been suspened several times thru the course of the week (last update was 03/31 with #436, shown below) watching Steve Vai on youtube (firefox-esr) and screen froze i could ssh to the machine. top showed machine was mostly idle. OpenBSD 6.9-beta (GENERIC.MP) #436: Mon Mar 29 12:55:53 MDT 2021 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 25417670656 (24240MB) avail mem = 24631955456 (23490MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.2 @ 0xbd60a000 (24 entries) bios0: vendor American Megatrends Inc. version "GU502DU.305" date 01/07/2021 bios0: ASUSTeK COMPUTER INC. Zephyrus G GU502DU_GA502DU acpi0 at bios0: ACPI 6.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT FIDT ECDT SSDT MCFG MSDM SSDT HPET UEFI VFCT TPM2 IVRS SSDT CRAT CDIT BGRT SSDT SSDT SSDT SSDT SSDT SSDT WSMT acpi0: wakeup devices GPP0(S4) GPP1(S4) GPP4(S4) GPP5(S4) GPP6(S4) GP17(S4) XHC0(S4) XHC1(S4) GP18(S4) acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat >8< snipped >8< last log below, before i finally rebooted the system [drm] *ERROR* Error in DP aux read transaction, not writing source specific data [drm] *ERROR* ring sdma0 timeout, signaled seq=26973, emitted seq=26973 [drm] *ERROR* Process information: process pid 0 thread pid 0 fetching new snapshots now. and will continue to watch Steve Vai (it's a Friday night in Japan) rgc ~
Re: The simplest full cray data core with 3 cpu's and a physics hack that makes it work
GPT-3 gone wild, or what? Definitely to late for Aprilfools-day.
acme-client, error 21 at 0 depth lookup:unable to verify the first certificate
Hello, I need some help to configure my acme-client the right way.
Obtain certificates itself works using OpenBSD -current #434 from April
1st.
I have a CAA record
$ dig -t CAA our.bio-planet.earth +short
0 issue "letsencrypt.org"
The configuration for httpd.conf and relayd.conf are taken fron honk
https://cvsweb.openbsd.org/ports/www/honk/pkg/README?rev=1.4=text/x-cvsweb-markup
The acme-client.conf is taken from /etc/examples/ and the settings for
the domain are
$ tail -f /etc/acme-client.conf
domain our.bio-planet.earth {
domain key "/etc/ssl/private/our.bio-planet.earth.key"
domain certificate "/etc/ssl/our.bio-planet.earth.crt"
domain full chain certificate
"/etc/ssl/our.bio-planet.earth.fullchain.pem"
sign with letsencrypt
}
The FQHN equals the domain and I don´t want to use other / sub domains.
The .crt file is required for the tls keypair part in relayd.conf.
If I try to verify the certificate using
$ openssl verify our.bio.planet.earth.fullchain.pem
CN = our.bio-planet.earth
error 21 at 0 depth lookup:unable to verify the first certificate
CN = our.bio-planet.earth
error 21 at 0 depth lookup:unable to verify the first certificate
/etc/ssl/our.bio-planet.earth.fullchain.pem: verification failed: 21
(unable to verify the first certificate)
On the other hand
$ openssl verify /etc/ssl/cert.pem
cert.pem: OK
How can I fix this as it did not work if I try to use the certs for
example for prosody.
Thanks and regards,
Christoph
The simplest full cray data core with 3 cpu's and a physics hack that makes it work
Made of three processing rings, with 3 control wires, direct opposite ring segment, and its two neighbours, this is your double data rate, or dead beef and the global clock. The local clock is the segment and its immediate neighbours. Stack three of them, and add a dimension in the topology, and as many datapaths as possible between the faster parts of the system, with digital sync between the local clock and speed of light in vacume. Which is an architecture where scatter-gather is extremely useful, as that works on the global clock. So a total 18 die's and a very difficult juggling act, where cable length's are legendary for the premium original Cray's. If you think you have a problem with your local segment, just feed beef. Not many explanations of this architecture that's around, but culture references like cult of the dead cow as a pun and wishes on those that occupied the whole system. Anyone that's been around a real one to know? If you want to know what's inside a cray, it's basically evil inside if you thought that would reveal something. -- Balder Oddson
Re: Iked windows client using certificates?
On 2021-04-01, Justin Mayes wrote: > Hello everyone > > Just wanted to check my sanity after so many days. I have ikev2 setup working > for windows machine for a long time using the following. So, to repeat this > works, it connects fine. > > ikev2 passive esp \ > from 0.0.0.0/0 to 10.0.5.0/24 \ 10.0.5.0/24 should be "to 0.0.0.0" in <=6.8, or "to dynamic" in -current/6.9 > peer any local 50.247.187.177 \ > srcid 50.247.187.177 \ > config address 10.0.5.0/24 > > now I have a second windows client with a different certificate that I also > want to connect at the same time but client B will disconnect client A. I > need to add a dstid to this config to make specific entries for each machine > I believe using ASN1_DN such as this? Or is there better way for clients with > no fixed IP or FQDN? It has been said that you should be able to match by dstid with iked, but I have been unable to make that work.
Using httpd to add ACME Challenge support to existing relayd setup
Hi!
I have some webapps that need Let's Encrypt certificates. I currently
use relayd to forward matching hostnames to my Ruby on Rails ports
(https://puma.io/), and was wondering what would be the ideal way of
adding ACME Challenge support to this setup?
So far I've added an ACME challenge table, a port and a forward rule.
I've also enabled httpd, and attempted to set up a catch-all directive
listening on port 5000. Unfortunately though it doesn't work, so any
feedback or criticism would be greatly appreciated!
Thanks!
Regards,
Murk
--
% acme-client -v mysite.com
acme-client: Fetching http://mysite.com/.well-known/acme-challenge
/TgxaQYLZ0iwwH4VR-Ss5Zf6sBGxlKvn8ra8V-o4SpLs: Connection refused
--
# relayd.conf
localhost="lo0"
ext_if="vio0"
table { $localhost }
acme_challenge_port="5000"
table { $localhost }
mysite_port="8080"
table { $localhost }
mysite2_port="8081"
http protocol "http" {
pass request quick path "/.well-known/acme-challenge/*" forward to
pass request header "Host" value "mysite.com" forward to
pass request header "Host" value "www.mysite.com" forward to
pass request header "Host" value "mysite2.com" forward to
pass request header "Host" value "www.mysite2.com" forward to
}
http protocol "https" {
pass request header "Host" value "mysite.com" forward to
pass request header "Host" value "www.mysite.com" forward to
tls keypair "mysite"
pass request header "Host" value "mysite2.com" forward to
pass request header "Host" value "www.mysite2.com" forward to
tls keypair "mysite2"
# Preserve address headers
match header set "X-Client-IP" value "$REMOTE_ADDR:$REMOTE_PORT"
match header set "X-Forwarded-For" value "$REMOTE_ADDR"
match header set "X-Forwarded-By" value "$SERVER_ADDR:$SERVER_PORT"
# Best practice security headers
# https://securityheaders.com/
match response header remove "Server"
match response header set "X-Frame-Options" value "SAMEORIGIN"
match response header set "X-XSS-Protection" value "1; mode=block"
match response header set "Referrer-Policy" value "strict-origin"
match response header set "Feature-Policy" value "accelerometer
'none'; ambient-light-sensor 'none'; battery 'none'; camera 'none';
geolocation 'none'; gyroscope 'none'; magnetometer 'none'; microphone
'none'; midi 'none'; payment 'none'; usb 'none';"
# Log extras
match header log "Host"
match header log "X-Forwarded-For"
match header log "User-Agent"
match header log "Referer"
match url log
}
relay "http" {
listen on $ext_if port http
protocol "http"
forward to port $acme_challenge_port
forward to port $mysite_port
forward to port $mysite2_port
}
relay "https" {
listen on $ext_if port https tls
protocol "https"
# Assumes that Rails has force HTTPS enabled
# https://api.rubyonrails.org/classes/ActionDispatch/SSL.html
forward to port $mysite_port
forward to port $mysite2_port
}
--
# httpd.conf
types {
include "/usr/share/misc/mime.types"
}
localhost="lo0"
acme_challenge_port="5000"
server "*" {
listen on $localhost port $acme_challenge_port
root "/"
location "/.well-known/acme-challenge/*" {
root "/acme"
request strip 2
}
}
--
# acme-client.conf
authority letsencrypt {
api url "https://acme-v02.api.letsencrypt.org/directory;
account key "/etc/ssl/private/letsencrypt.key"
}
domain mysite.com {
alternative names { www.mysite.com }
domain key "/etc/ssl/private/mysite.key"
domain full chain certificate "/etc/ssl/mysite.crt"
sign with letsencrypt
}
domain mysite2.com {
alternative names { www.mysite2.com }
domain key "/etc/ssl/private/mysite2.key"
domain full chain certificate "/etc/ssl/mysite2.crt"
sign with letsencrypt
}
