date:20180525

Re: Beg for Atheros wifi driver

2018-05-25 Thread Patrick Harper

Is this a laptop you're dealing with? Vendor firmwares tend to enforce a 
whitelist of permitted cards for the internal mini-PCI(e) slot.

-- 
  Patrick Harper
  paia...@fastmail.com

On Wed, 23 May 2018, at 13:46, Chris Bennett wrote:
> On Mon, Apr 16, 2018 at 07:43:09AM +, Antal Ispanovity wrote:
> > By the way, you just need to have a look at this page, click on a driver
> > and you can see a list of supported devices:
> > https://man.openbsd.org/?query=wireless=1
> > 
> 
> This DOES NOT always work. I have bought several supported model numbers
> that had been replaced with new chipsets.
> I'm having the same problem and I am going to order one online today.
> Pretty frustrating buying one after the next only to fail.
> 
> Chris Bennett
> 
> P.S.
> I'm installing a snapshot first to see if that solves the problem since
> I have one to return to the store with me
> 
>

Re: acme-client new cert error

2018-05-25 Thread Bryan Harris

Ah okay. In my different situation I did

mv /etc/ssl/cert /tmp

Then ran command again.

I will try -D next time instead.

V/r,
Bryan 



> On May 25, 2018, at 5:51 PM, Scott Vanderbilt  wrote:
> 
>> On 5/25/2018 2:41 PM, Bryan Harris wrote:
>> Did you already have a cert for datagenic.com but which didn’t include the 
>> new name?
>> I think the -A argument only makes a new cert when old one doesn’t exist. 
>> Otherwise tries to use found cert and failed because old cert doesn’t have 
>> new name. At least that’s my understanding.
>> Or maybe I misunderstood the error message.
>> V/r,
>> Bryan
> 
> Thanks for chipping in.
> 
> Regrettably, I get the same error with -D flag only (i.e., no -A).
> 
> 
>>> On May 25, 2018, at 4:10 PM, Scott Vanderbilt  wrote:
>>> 
>>> I'm having difficulty creating a new SSL cert for a virtual host I'm just 
>>> standing up for the first time. I get the following error on successive 
>>> attempts:
>>> 
>>> urn:acme:error:unauthorized
>>> Error creating new cert :: authorizations for these names not found or 
>>> expired: aeneas.datagenic.com
>>> 
>>> I've verified it's not a web server access issue, as I am able to 
>>> successfully retrieve a static HTML file from the challenge directory
>>> 
>>>aeneas$ curl 
>>> http://aeneas.datagenic.com/.well-known/acme-challenge/test.html
>>>Foo
>>>aeneas$
>>> 
>>> Complete verbose error message, config file, and dmesg follow.
>>> 
>>> Thanks in advance for any assistance you can lend.
>>> 
>>> 
>>> 
>>> aeneas# acme-client -vvAD aeneas.datagenic.com
>>> acme-client: /etc/ssl/acme/private/aeneas.datagenic.com/privkey.pem: domain 
>>> key exists (not creating)
>>> acme-client: /etc/acme/letsencrypt-privkey.pem: account key exists (not 
>>> creating)
>>> acme-client: /etc/ssl/acme/private/aeneas.datagenic.com/privkey.pem: loaded 
>>> RSA domain key
>>> acme-client: /etc/acme/letsencrypt-privkey.pem: loaded RSA account key
>>> acme-client: https://acme-v01.api.letsencrypt.org/directory: directories
>>> acme-client: acme-v01.api.letsencrypt.org: DNS: 23.75.196.250
>>> acme-client: transfer buffer: [{ "key-change": 
>>> "https://acme-v01.api.letsencrypt.org/acme/key-change;, "meta": { 
>>> "caaIdentities": [ "letsencrypt.org" ], "terms-of-service": 
>>> "https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf;, 
>>> "website": "https://letsencrypt.org; }, "new-authz": 
>>> "https://acme-v01.api.letsencrypt.org/acme/new-authz;, "new-cert": 
>>> "https://acme-v01.api.letsencrypt.org/acme/new-cert;, "new-reg": 
>>> "https://acme-v01.api.letsencrypt.org/acme/new-reg;, "revoke-cert": 
>>> "https://acme-v01.api.letsencrypt.org/acme/revoke-cert;, "sw0ePngTU-0": 
>>> "https://community.letsencrypt.org/t/adding-random-entries-to-the-directory/33417;
>>>  }] (658 bytes)
>>> acme-client: https://acme-v01.api.letsencrypt.org/acme/new-authz: req-auth: 
>>> aeneas.datagenic.com
>>> acme-client: acme-v01.api.letsencrypt.org: cached
>>> acme-client: acme-v01.api.letsencrypt.org: cached
>>> acme-client: transfer buffer: [{ "identifier": { "type": "dns", "value": 
>>> "aeneas.datagenic.com" }, "status": "pending", "expires": 
>>> "2018-06-01T19:22:23Z", "challenges": [ { "type": "tls-sni-01", "status": 
>>> "pending", "uri": 
>>> "https://acme-v01.api.letsencrypt.org/acme/challenge/xFIciSX0MzV47lV98sOT6mojdXIXXfIh_2yiH-dzT6k/4809114624;,
>>>  "token": "TpW1KNEcns3ebXVxbBwYToVOjsMEzR78MWySuyKvdhI" }, { "type": 
>>> "dns-01", "status": "pending", "uri": 
>>> "https://acme-v01.api.letsencrypt.org/acme/challenge/xFIciSX0MzV47lV98sOT6mojdXIXXfIh_2yiH-dzT6k/4809114625;,
>>>  "token": "Iq66R_OgKJ2VURMLyVxLD8hjnWtLqrjqSYb0L3YRqNU" }, { "type": 
>>> "http-01", "status": "pending", "uri": 
>>> "https://acme-v01.api.letsencrypt.org/acme/challenge/xFIciSX0MzV47lV98sOT6mojdXIXXfIh_2yiH-dzT6k/4809114626;,
>>>  "token": "iJcmtseVVljOzlLIKYoN0-Pu5SQ4sLcqmCGgtwUj3co" } ], 
>>> "combinations": [ [ 1 ], [ 0 ], [ 2 ] ] }] (998 bytes)
>>> acme-client: 
>>> /var/www/htdocs/default/acme/iJcmtseVVljOzlLIKYoN0-Pu5SQ4sLcqmCGgtwUj3co: 
>>> created
>>> acme-client: 
>>> https://acme-v01.api.letsencrypt.org/acme/challenge/xFIciSX0MzV47lV98sOT6mojdXIXXfIh_2yiH-dzT6k/4809114626:
>>>  challenge
>>> acme-client: acme-v01.api.letsencrypt.org: cached
>>> acme-client: acme-v01.api.letsencrypt.org: cached
>>> acme-client: transfer buffer: [{ "type": "http-01", "status": "pending", 
>>> "uri": 
>>> "https://acme-v01.api.letsencrypt.org/acme/challenge/xFIciSX0MzV47lV98sOT6mojdXIXXfIh_2yiH-dzT6k/4809114626;,
>>>  "token": "iJcmtseVVljOzlLIKYoN0-Pu5SQ4sLcqmCGgtwUj3co", 
>>> "keyAuthorization": 
>>> "iJcmtseVVljOzlLIKYoN0-Pu5SQ4sLcqmCGgtwUj3co.oHnB0_JsMCOWBPKhfVMYsIDZr_T2Wo-Y5z0fh-cmkA4"
>>>  }] (336 bytes)
>>> acme-client: 
>>> https://acme-v01.api.letsencrypt.org/acme/challenge/xFIciSX0MzV47lV98sOT6mojdXIXXfIh_2yiH-dzT6k/4809114626:
>>>  status
>>>

Re: connect two midi devices

2018-05-25 Thread Sebastian Reitenbach

Am Freitag, Mai 25, 2018 22:22 CEST, Alexandre Ratchov  schrieb:

> On Fri, May 25, 2018 at 10:22:26AM +0200, Sebastian Reitenbach wrote:
> > Hi Alexandre,
> >
> > Am Freitag, Mai 25, 2018 08:41 CEST, Alexandre Ratchov  
> > schrieb:
> >
> > > On Fri, May 25, 2018 at 12:21:18AM +0200, Alexandre Ratchov wrote:
> > > >
> > > > Maybe, but unlikely. If the device attaches, generally it works. Show
> > > > what's received on midi2 when you type on the keyboard or do any other
> > > > simple actions.
> > > >
> > >
> > > fwiw, here's a small utility that I use very often to debug & connect
> > > MIDI ports.
> > >
> > > http://caoua.org/alex/obsd/midicat.tar.gz
> > >
> > > To connect two rmidi/2 -> rmidi/1 and dump the data on stderr, run:
> > >
> > > midicat -d -q rmidi/2 -q rmidi/1
> >
> >  Actually, that midicat seems to do the trick. When I run it in debug, and 
> > press some keys on the
> > system-1, output looks like:
> >
> > f8
> > f8
> > fe
> > f8
> > f8
> > f8
> > 90 80 9b
>
> ^^^
>
> these 3 bytes make no sense. The status byte 0x90 is correct but the
> two args are wrong. This is when you pressed the key, right?
>
> > ...
> > 90 9b b2
>
> These are also wrong, and this is when you released the key, right?
> Interestingly the 0x9b is repeated.
>

To verify, I reconnected it again, and pushed same note multiple times:
f8
f8
90 34 64
 pressed key
f8
fe
f8
f8
f8
f8
90 80 34
90 40 f8
 released key
f8
f8
f8
f8
90 34 64
f8
f8
f8
f8
f8
f8
90 80 34
90 40 f8
f8
f8
f8
fe
f8
90 34 64
f8
f8
f8
f8
f8
f8
f8
f8
90 80 34
90 40 f8
f8
f8

> >
> >  However, some keys I have to press multiple times until the Rocket Synth 
> > recognizes it, and
> > some other note from the synth, doesn't produce any sound on the Rocket.
> > However, when I connect the System 1 MIDI out, with a straight MIDI cable 
> > to MIDI in
> > on the Rocket, I can play these notes, and it produces sound, on each key 
> > press.
> >
>
> Clearly, the midi events are corrupted by the usb interface. Does the
> midi interface claim to be "class compliant"? does it come with
> drivers for MacOS or Windows?

It was advertized as class compliant, and it just came the cable, no drivers.
But as I said, it was el-chepo from ebay not even 3 EUR incl. shipping from 
China.

>
> > The System-1, as well as the TB-3 are connected to my MX-1 via USB.
> > I noticed I have to disconnect the USB from the system-1. Only then it 
> > seems to
> > send out MIDI data on the MIDI port.
> > Maybe that was my main problem yesterday.
> > Since I use the USB connection to the MX-1 for MIDI and SOUND, disconnecting
> > the USB cable from the system-1 or tb-3 would spoil my setup.
> > The Roland Aira gear doesn't seem to have a mode to support class compatible
> > MIDI via USB. It only provides some USB Disk modes for backup/restore and
> > firmware updates.
> >
> >
> > I wonder how I could tell midicat which midi channel to use. I.e. I cound 
> > connect
> > the USB-to-MIDI converter to the Roland MX-1, and since all the other gear 
> > is
> > connected there, it might work out, when the MX-1 is set to MIDI 
> > passthrough.
> > But I might be able to tell midish to connect that same hardware midi device
> > as input to output, but with different midi channels?
>
> If you use the MIDI passthrough, events will be broadcast to both
> devices, so you'll have to configure each device to ignore channels
> that you want the other device to handle.
None of the connected devices is in Omni mode, they are all configured
with their specific MIDI channel.
>
> midicat just moves the data, so you it can't change the channel
> numbers. To change the channel you can use the fmap rule in midish.

The MX-1 has 4 USB ports to connect other Aira gear to it. Via those it 
sends/receives
MIDI as well as receives Audio from the connected device. The system-1
is connected via USB to such port onto the MX-1.
I ensured the MX-1 is in MIDI-Through mode, connected that USB-to-MIDI
device to the MX-1, and first checked with hexdump what happens:

hexdump -e '1/1 "%02x\n"' < /dev/rmidi2

But nothing happens when I pushed any of the keys on the system-1.
Reading the Manual, it says, MIDI Through mode is for what comes in in MIDI-IN
and that will be sent out to MIDI-OUT. I guess the MIDI from the USB connections
are not added to the MIX of signals out to MIDI-OUT.

Seems have bad luck here getting it to work.
Nevertheless,  I tied midish:, I put this into my .midishrc:
dnew 0 "rmidi/0" wo
dnew 1 "rmidi/2" rw

The Rocket currently on midi0, the MX-1 via USB-to-MIDI converter on midi2.

and then in midish:

[:00]> fnew newsong
[:00]> fmap {any {1 1}}{any {0 2}}
[:00]> i
[:00]>

then pushing keys on the system-1 but no sound on the rocket.

 thanks,
Sebastian

Re: acme-client new cert error

2018-05-25 Thread Scott Vanderbilt


On 5/25/2018 2:41 PM, Bryan Harris wrote:

Did you already have a cert for datagenic.com but which didn’t include the new 
name?

I think the -A argument only makes a new cert when old one doesn’t exist. 
Otherwise tries to use found cert and failed because old cert doesn’t have new 
name. At least that’s my understanding.

Or maybe I misunderstood the error message.

V/r,
Bryan


Thanks for chipping in.

Regrettably, I get the same error with -D flag only (i.e., no -A).



On May 25, 2018, at 4:10 PM, Scott Vanderbilt  wrote:

I'm having difficulty creating a new SSL cert for a virtual host I'm just 
standing up for the first time. I get the following error on successive 
attempts:

urn:acme:error:unauthorized
Error creating new cert :: authorizations for these names not found or expired: 
aeneas.datagenic.com

I've verified it's not a web server access issue, as I am able to successfully 
retrieve a static HTML file from the challenge directory

aeneas$ curl 
http://aeneas.datagenic.com/.well-known/acme-challenge/test.html
Foo
aeneas$

Complete verbose error message, config file, and dmesg follow.

Thanks in advance for any assistance you can lend.



aeneas# acme-client -vvAD aeneas.datagenic.com
acme-client: /etc/ssl/acme/private/aeneas.datagenic.com/privkey.pem: domain key 
exists (not creating)
acme-client: /etc/acme/letsencrypt-privkey.pem: account key exists (not 
creating)
acme-client: /etc/ssl/acme/private/aeneas.datagenic.com/privkey.pem: loaded RSA 
domain key
acme-client: /etc/acme/letsencrypt-privkey.pem: loaded RSA account key
acme-client: https://acme-v01.api.letsencrypt.org/directory: directories
acme-client: acme-v01.api.letsencrypt.org: DNS: 23.75.196.250
acme-client: transfer buffer: [{ "key-change": "https://acme-v01.api.letsencrypt.org/acme/key-change;, "meta": { "caaIdentities": [ "letsencrypt.org" ], "terms-of-service": 
"https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf;, "website": "https://letsencrypt.org; }, "new-authz": "https://acme-v01.api.letsencrypt.org/acme/new-authz;, "new-cert": 
"https://acme-v01.api.letsencrypt.org/acme/new-cert;, "new-reg": "https://acme-v01.api.letsencrypt.org/acme/new-reg;, "revoke-cert": "https://acme-v01.api.letsencrypt.org/acme/revoke-cert;, "sw0ePngTU-0": 
"https://community.letsencrypt.org/t/adding-random-entries-to-the-directory/33417; }] (658 bytes)
acme-client: https://acme-v01.api.letsencrypt.org/acme/new-authz: req-auth: 
aeneas.datagenic.com
acme-client: acme-v01.api.letsencrypt.org: cached
acme-client: acme-v01.api.letsencrypt.org: cached
acme-client: transfer buffer: [{ "identifier": { "type": "dns", "value": "aeneas.datagenic.com" }, "status": "pending", "expires": "2018-06-01T19:22:23Z", "challenges": [ { "type": "tls-sni-01", "status": "pending", "uri": 
"https://acme-v01.api.letsencrypt.org/acme/challenge/xFIciSX0MzV47lV98sOT6mojdXIXXfIh_2yiH-dzT6k/4809114624;, "token": "TpW1KNEcns3ebXVxbBwYToVOjsMEzR78MWySuyKvdhI" }, { "type": "dns-01", "status": "pending", "uri": "https://acme-v01.api.letsencrypt.org/acme/challenge/xFIciSX0MzV47lV98sOT6mojdXIXXfIh_2yiH-dzT6k/4809114625;, 
"token": "Iq66R_OgKJ2VURMLyVxLD8hjnWtLqrjqSYb0L3YRqNU" }, { "type": "http-01", "status": "pending", "uri": "https://acme-v01.api.letsencrypt.org/acme/challenge/xFIciSX0MzV47lV98sOT6mojdXIXXfIh_2yiH-dzT6k/4809114626;, "token": "iJcmtseVVljOzlLIKYoN0-Pu5SQ4sLcqmCGgtwUj3co" } ], "combinations": [ [ 1 ], [ 0 ], [ 2 ] ] }] 
(998 bytes)
acme-client: 
/var/www/htdocs/default/acme/iJcmtseVVljOzlLIKYoN0-Pu5SQ4sLcqmCGgtwUj3co: 
created
acme-client: 
https://acme-v01.api.letsencrypt.org/acme/challenge/xFIciSX0MzV47lV98sOT6mojdXIXXfIh_2yiH-dzT6k/4809114626:
 challenge
acme-client: acme-v01.api.letsencrypt.org: cached
acme-client: acme-v01.api.letsencrypt.org: cached
acme-client: transfer buffer: [{ "type": "http-01", "status": "pending", "uri": 
"https://acme-v01.api.letsencrypt.org/acme/challenge/xFIciSX0MzV47lV98sOT6mojdXIXXfIh_2yiH-dzT6k/4809114626;, "token": 
"iJcmtseVVljOzlLIKYoN0-Pu5SQ4sLcqmCGgtwUj3co", "keyAuthorization": 
"iJcmtseVVljOzlLIKYoN0-Pu5SQ4sLcqmCGgtwUj3co.oHnB0_JsMCOWBPKhfVMYsIDZr_T2Wo-Y5z0fh-cmkA4" }] (336 bytes)
acme-client: 
https://acme-v01.api.letsencrypt.org/acme/challenge/xFIciSX0MzV47lV98sOT6mojdXIXXfIh_2yiH-dzT6k/4809114626:
 status
acme-client: acme-v01.api.letsencrypt.org: cached
acme-client: https://acme-v01.api.letsencrypt.org/acme/new-cert: certificate
acme-client: acme-v01.api.letsencrypt.org: cached
acme-client: acme-v01.api.letsencrypt.org: cached
acme-client: https://acme-v01.api.letsencrypt.org/acme/new-cert: bad HTTP: 403
acme-client: transfer buffer: [{ "type": "urn:acme:error:unauthorized", "detail": "Error 
creating new cert :: authorizations for these names not found or expired: aeneas.datagenic.com", "status": 403 }] 
(176 bytes)
acme-client: bad exit: netproc(38047): 1

Re: acme-client new cert error

2018-05-25 Thread Bryan Harris

Did you already have a cert for datagenic.com but which didn’t include the new 
name?

I think the -A argument only makes a new cert when old one doesn’t exist. 
Otherwise tries to use found cert and failed because old cert doesn’t have new 
name. At least that’s my understanding. 

Or maybe I misunderstood the error message.

V/r,
Bryan

> On May 25, 2018, at 4:10 PM, Scott Vanderbilt  wrote:
> 
> I'm having difficulty creating a new SSL cert for a virtual host I'm just 
> standing up for the first time. I get the following error on successive 
> attempts:
> 
> urn:acme:error:unauthorized
> Error creating new cert :: authorizations for these names not found or 
> expired: aeneas.datagenic.com
> 
> I've verified it's not a web server access issue, as I am able to 
> successfully retrieve a static HTML file from the challenge directory
> 
>aeneas$ curl 
> http://aeneas.datagenic.com/.well-known/acme-challenge/test.html
>Foo
>aeneas$
> 
> Complete verbose error message, config file, and dmesg follow.
> 
> Thanks in advance for any assistance you can lend.
> 
> 
> 
> aeneas# acme-client -vvAD aeneas.datagenic.com
> acme-client: /etc/ssl/acme/private/aeneas.datagenic.com/privkey.pem: domain 
> key exists (not creating)
> acme-client: /etc/acme/letsencrypt-privkey.pem: account key exists (not 
> creating)
> acme-client: /etc/ssl/acme/private/aeneas.datagenic.com/privkey.pem: loaded 
> RSA domain key
> acme-client: /etc/acme/letsencrypt-privkey.pem: loaded RSA account key
> acme-client: https://acme-v01.api.letsencrypt.org/directory: directories
> acme-client: acme-v01.api.letsencrypt.org: DNS: 23.75.196.250
> acme-client: transfer buffer: [{ "key-change": 
> "https://acme-v01.api.letsencrypt.org/acme/key-change;, "meta": { 
> "caaIdentities": [ "letsencrypt.org" ], "terms-of-service": 
> "https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf;, 
> "website": "https://letsencrypt.org; }, "new-authz": 
> "https://acme-v01.api.letsencrypt.org/acme/new-authz;, "new-cert": 
> "https://acme-v01.api.letsencrypt.org/acme/new-cert;, "new-reg": 
> "https://acme-v01.api.letsencrypt.org/acme/new-reg;, "revoke-cert": 
> "https://acme-v01.api.letsencrypt.org/acme/revoke-cert;, "sw0ePngTU-0": 
> "https://community.letsencrypt.org/t/adding-random-entries-to-the-directory/33417;
>  }] (658 bytes)
> acme-client: https://acme-v01.api.letsencrypt.org/acme/new-authz: req-auth: 
> aeneas.datagenic.com
> acme-client: acme-v01.api.letsencrypt.org: cached
> acme-client: acme-v01.api.letsencrypt.org: cached
> acme-client: transfer buffer: [{ "identifier": { "type": "dns", "value": 
> "aeneas.datagenic.com" }, "status": "pending", "expires": 
> "2018-06-01T19:22:23Z", "challenges": [ { "type": "tls-sni-01", "status": 
> "pending", "uri": 
> "https://acme-v01.api.letsencrypt.org/acme/challenge/xFIciSX0MzV47lV98sOT6mojdXIXXfIh_2yiH-dzT6k/4809114624;,
>  "token": "TpW1KNEcns3ebXVxbBwYToVOjsMEzR78MWySuyKvdhI" }, { "type": 
> "dns-01", "status": "pending", "uri": 
> "https://acme-v01.api.letsencrypt.org/acme/challenge/xFIciSX0MzV47lV98sOT6mojdXIXXfIh_2yiH-dzT6k/4809114625;,
>  "token": "Iq66R_OgKJ2VURMLyVxLD8hjnWtLqrjqSYb0L3YRqNU" }, { "type": 
> "http-01", "status": "pending", "uri": 
> "https://acme-v01.api.letsencrypt.org/acme/challenge/xFIciSX0MzV47lV98sOT6mojdXIXXfIh_2yiH-dzT6k/4809114626;,
>  "token": "iJcmtseVVljOzlLIKYoN0-Pu5SQ4sLcqmCGgtwUj3co" } ], "combinations": 
> [ [ 1 ], [ 0 ], [ 2 ] ] }] (998 bytes)
> acme-client: 
> /var/www/htdocs/default/acme/iJcmtseVVljOzlLIKYoN0-Pu5SQ4sLcqmCGgtwUj3co: 
> created
> acme-client: 
> https://acme-v01.api.letsencrypt.org/acme/challenge/xFIciSX0MzV47lV98sOT6mojdXIXXfIh_2yiH-dzT6k/4809114626:
>  challenge
> acme-client: acme-v01.api.letsencrypt.org: cached
> acme-client: acme-v01.api.letsencrypt.org: cached
> acme-client: transfer buffer: [{ "type": "http-01", "status": "pending", 
> "uri": 
> "https://acme-v01.api.letsencrypt.org/acme/challenge/xFIciSX0MzV47lV98sOT6mojdXIXXfIh_2yiH-dzT6k/4809114626;,
>  "token": "iJcmtseVVljOzlLIKYoN0-Pu5SQ4sLcqmCGgtwUj3co", "keyAuthorization": 
> "iJcmtseVVljOzlLIKYoN0-Pu5SQ4sLcqmCGgtwUj3co.oHnB0_JsMCOWBPKhfVMYsIDZr_T2Wo-Y5z0fh-cmkA4"
>  }] (336 bytes)
> acme-client: 
> https://acme-v01.api.letsencrypt.org/acme/challenge/xFIciSX0MzV47lV98sOT6mojdXIXXfIh_2yiH-dzT6k/4809114626:
>  status
> acme-client: acme-v01.api.letsencrypt.org: cached
> acme-client: https://acme-v01.api.letsencrypt.org/acme/new-cert: certificate
> acme-client: acme-v01.api.letsencrypt.org: cached
> acme-client: acme-v01.api.letsencrypt.org: cached
> acme-client: https://acme-v01.api.letsencrypt.org/acme/new-cert: bad HTTP: 403
> acme-client: transfer buffer: [{ "type": "urn:acme:error:unauthorized", 
> "detail": "Error creating new cert :: authorizations for these names not 
> found or expired: aeneas.datagenic.com", "status": 403 }] (176 bytes)
> acme-client: bad

Re: acme-client new cert error

2018-05-25 Thread Scott Vanderbilt


On 5/25/2018 2:20 PM, Fred wrote:

On 05/25/18 21:10, Scott Vanderbilt wrote:
I'm having difficulty creating a new SSL cert for a virtual host I'm 
just standing up for the first time. I get the following error on 
successive attempts:


urn:acme:error:unauthorized
Error creating new cert :: authorizations for these names not found or 
expired: aeneas.datagenic.com


I've verified it's not a web server access issue, as I am able to 
successfully retrieve a static HTML file from the challenge directory


    aeneas$ curl 
http://aeneas.datagenic.com/.well-known/acme-challenge/test.html

    Foo
    aeneas$

Complete verbose error message, config file, and dmesg follow.

Thanks in advance for any assistance you can lend.

 



aeneas# acme-client -vvAD aeneas.datagenic.com
acme-client: /etc/ssl/acme/private/aeneas.datagenic.com/privkey.pem: 
domain key exists (not creating)
acme-client: /etc/acme/letsencrypt-privkey.pem: account key exists 
(not creating)
acme-client: /etc/ssl/acme/private/aeneas.datagenic.com/privkey.pem: 
loaded RSA domain key

acme-client: /etc/acme/letsencrypt-privkey.pem: loaded RSA account key
acme-client: https://acme-v01.api.letsencrypt.org/directory: directories
acme-client: acme-v01.api.letsencrypt.org: DNS: 23.75.196.250
acme-client: transfer buffer: [{ "key-change": 
"https://acme-v01.api.letsencrypt.org/acme/key-change;, "meta": { 
"caaIdentities": [ "letsencrypt.org" ], "terms-of-service": 
"https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf;, 
"website": "https://letsencrypt.org; }, "new-authz": 
"https://acme-v01.api.letsencrypt.org/acme/new-authz;, "new-cert": 
"https://acme-v01.api.letsencrypt.org/acme/new-cert;, "new-reg": 
"https://acme-v01.api.letsencrypt.org/acme/new-reg;, "revoke-cert": 
"https://acme-v01.api.letsencrypt.org/acme/revoke-cert;, 
"sw0ePngTU-0": 
"https://community.letsencrypt.org/t/adding-random-entries-to-the-directory/33417; 
}] (658 bytes)
acme-client: https://acme-v01.api.letsencrypt.org/acme/new-authz: 
req-auth: aeneas.datagenic.com

acme-client: acme-v01.api.letsencrypt.org: cached
acme-client: acme-v01.api.letsencrypt.org: cached
acme-client: transfer buffer: [{ "identifier": { "type": "dns", 
"value": "aeneas.datagenic.com" }, "status": "pending", "expires": 
"2018-06-01T19:22:23Z", "challenges": [ { "type": "tls-sni-01", 
"status": "pending", "uri": 
"https://acme-v01.api.letsencrypt.org/acme/challenge/xFIciSX0MzV47lV98sOT6mojdXIXXfIh_2yiH-dzT6k/4809114624;, 
"token": "TpW1KNEcns3ebXVxbBwYToVOjsMEzR78MWySuyKvdhI" }, { "type": 
"dns-01", "status": "pending", "uri": 
"https://acme-v01.api.letsencrypt.org/acme/challenge/xFIciSX0MzV47lV98sOT6mojdXIXXfIh_2yiH-dzT6k/4809114625;, 
"token": "Iq66R_OgKJ2VURMLyVxLD8hjnWtLqrjqSYb0L3YRqNU" }, { "type": 
"http-01", "status": "pending", "uri": 
"https://acme-v01.api.letsencrypt.org/acme/challenge/xFIciSX0MzV47lV98sOT6mojdXIXXfIh_2yiH-dzT6k/4809114626;, 
"token": "iJcmtseVVljOzlLIKYoN0-Pu5SQ4sLcqmCGgtwUj3co" } ], 
"combinations": [ [ 1 ], [ 0 ], [ 2 ] ] }] (998 bytes)
acme-client: 
/var/www/htdocs/default/acme/iJcmtseVVljOzlLIKYoN0-Pu5SQ4sLcqmCGgtwUj3co: 
created
acme-client: 
https://acme-v01.api.letsencrypt.org/acme/challenge/xFIciSX0MzV47lV98sOT6mojdXIXXfIh_2yiH-dzT6k/4809114626: 
challenge

acme-client: acme-v01.api.letsencrypt.org: cached
acme-client: acme-v01.api.letsencrypt.org: cached
acme-client: transfer buffer: [{ "type": "http-01", "status": 
"pending", "uri": 
"https://acme-v01.api.letsencrypt.org/acme/challenge/xFIciSX0MzV47lV98sOT6mojdXIXXfIh_2yiH-dzT6k/4809114626;, 
"token": "iJcmtseVVljOzlLIKYoN0-Pu5SQ4sLcqmCGgtwUj3co", 
"keyAuthorization": 
"iJcmtseVVljOzlLIKYoN0-Pu5SQ4sLcqmCGgtwUj3co.oHnB0_JsMCOWBPKhfVMYsIDZr_T2Wo-Y5z0fh-cmkA4" 
}] (336 bytes)
acme-client: 
https://acme-v01.api.letsencrypt.org/acme/challenge/xFIciSX0MzV47lV98sOT6mojdXIXXfIh_2yiH-dzT6k/4809114626: 
status

acme-client: acme-v01.api.letsencrypt.org: cached
acme-client: https://acme-v01.api.letsencrypt.org/acme/new-cert: 
certificate

acme-client: acme-v01.api.letsencrypt.org: cached
acme-client: acme-v01.api.letsencrypt.org: cached
acme-client: https://acme-v01.api.letsencrypt.org/acme/new-cert: bad 
HTTP: 403
acme-client: transfer buffer: [{ "type": 
"urn:acme:error:unauthorized", "detail": "Error creating new cert :: 
authorizations for these names not found or expired: 
aeneas.datagenic.com", "status": 403 }] (176 bytes)

acme-client: bad exit: netproc(38047): 1


-
aeneas$ cat /etc/acme-client.conf
#
# $OpenBSD: acme-client.conf,v 1.7 2018/04/13 08:24:38 ajacoutot Exp $
#
authority letsencrypt {
 api url "https://acme-v01.api.letsencrypt.org/directory;
 account key "/etc/acme/letsencrypt-privkey.pem"
}

authority letsencrypt-staging {
 api url "https://acme-staging.api.letsencrypt.org/directory;
 account key

Re: acme-client new cert error

2018-05-25 Thread Tim van der Molen

I have run into a problem that seems similar to yours. I'm still
debugging it (or rather trying to find the time to do so), but I believe
the problem is that acme-client does not correctly handle the "pending"
status: it is handled as "valid". As a result, the challenge file is
removed before the acme server could verify it.

In my case, disabling the code that removes the challenge file (see diff
below) improves the chance of success. Perhaps that's helpful to you too
as a temporary workaround.

Index: chngproc.c
===
RCS file: /cvs/src/usr.sbin/acme-client/chngproc.c,v
retrieving revision 1.12
diff -p -u -r1.12 chngproc.c
--- chngproc.c  24 Jan 2017 13:32:55 -  1.12
+++ chngproc.c  25 May 2018 21:10:39 -
@@ -139,8 +139,10 @@ out:
if (fd != -1)
close(fd);
for (i = 0; i < fsz; i++) {
+#if 0
if (unlink(fs[i]) == -1 && errno != ENOENT)
warn("%s", fs[i]);
+#endif
free(fs[i]);
}
free(fs);

Scott Vanderbilt (2018-05-25 22:10 +0200):
> I'm having difficulty creating a new SSL cert for a virtual host I'm just
> standing up for the first time. I get the following error on successive
> attempts:
> 
> urn:acme:error:unauthorized
> Error creating new cert :: authorizations for these names not found or
> expired: aeneas.datagenic.com
> 
> I've verified it's not a web server access issue, as I am able to
> successfully retrieve a static HTML file from the challenge directory
> 
>    aeneas$ curl
> http://aeneas.datagenic.com/.well-known/acme-challenge/test.html
>    Foo
>    aeneas$
> 
> Complete verbose error message, config file, and dmesg follow.
> 
> Thanks in advance for any assistance you can lend.
> 
> 
> 
> aeneas# acme-client -vvAD aeneas.datagenic.com
> acme-client: /etc/ssl/acme/private/aeneas.datagenic.com/privkey.pem: domain
> key exists (not creating)
> acme-client: /etc/acme/letsencrypt-privkey.pem: account key exists (not
> creating)
> acme-client: /etc/ssl/acme/private/aeneas.datagenic.com/privkey.pem: loaded
> RSA domain key
> acme-client: /etc/acme/letsencrypt-privkey.pem: loaded RSA account key
> acme-client: https://acme-v01.api.letsencrypt.org/directory: directories
> acme-client: acme-v01.api.letsencrypt.org: DNS: 23.75.196.250
> acme-client: transfer buffer: [{ "key-change":
> "https://acme-v01.api.letsencrypt.org/acme/key-change;, "meta": {
> "caaIdentities": [ "letsencrypt.org" ], "terms-of-service":
> "https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf;,
> "website": "https://letsencrypt.org; }, "new-authz":
> "https://acme-v01.api.letsencrypt.org/acme/new-authz;, "new-cert":
> "https://acme-v01.api.letsencrypt.org/acme/new-cert;, "new-reg":
> "https://acme-v01.api.letsencrypt.org/acme/new-reg;, "revoke-cert":
> "https://acme-v01.api.letsencrypt.org/acme/revoke-cert;, "sw0ePngTU-0": 
> "https://community.letsencrypt.org/t/adding-random-entries-to-the-directory/33417;
> }] (658 bytes)
> acme-client: https://acme-v01.api.letsencrypt.org/acme/new-authz: req-auth:
> aeneas.datagenic.com
> acme-client: acme-v01.api.letsencrypt.org: cached
> acme-client: acme-v01.api.letsencrypt.org: cached
> acme-client: transfer buffer: [{ "identifier": { "type": "dns", "value":
> "aeneas.datagenic.com" }, "status": "pending", "expires":
> "2018-06-01T19:22:23Z", "challenges": [ { "type": "tls-sni-01", "status":
> "pending", "uri": 
> "https://acme-v01.api.letsencrypt.org/acme/challenge/xFIciSX0MzV47lV98sOT6mojdXIXXfIh_2yiH-dzT6k/4809114624;,
> "token": "TpW1KNEcns3ebXVxbBwYToVOjsMEzR78MWySuyKvdhI" }, { "type":
> "dns-01", "status": "pending", "uri": 
> "https://acme-v01.api.letsencrypt.org/acme/challenge/xFIciSX0MzV47lV98sOT6mojdXIXXfIh_2yiH-dzT6k/4809114625;,
> "token": "Iq66R_OgKJ2VURMLyVxLD8hjnWtLqrjqSYb0L3YRqNU" }, { "type":
> "http-01", "status": "pending", "uri": 
> "https://acme-v01.api.letsencrypt.org/acme/challenge/xFIciSX0MzV47lV98sOT6mojdXIXXfIh_2yiH-dzT6k/4809114626;,
> "token": "iJcmtseVVljOzlLIKYoN0-Pu5SQ4sLcqmCGgtwUj3co" } ], "combinations":
> [ [ 1 ], [ 0 ], [ 2 ] ] }] (998 bytes)
> acme-client:
> /var/www/htdocs/default/acme/iJcmtseVVljOzlLIKYoN0-Pu5SQ4sLcqmCGgtwUj3co:
> created
> acme-client: 
> https://acme-v01.api.letsencrypt.org/acme/challenge/xFIciSX0MzV47lV98sOT6mojdXIXXfIh_2yiH-dzT6k/4809114626:
> challenge
> acme-client: acme-v01.api.letsencrypt.org: cached
> acme-client: acme-v01.api.letsencrypt.org: cached
> acme-client: transfer buffer: [{ "type": "http-01", "status": "pending",
> "uri": 
> "https://acme-v01.api.letsencrypt.org/acme/challenge/xFIciSX0MzV47lV98sOT6mojdXIXXfIh_2yiH-dzT6k/4809114626;,
> "token": "iJcmtseVVljOzlLIKYoN0-Pu5SQ4sLcqmCGgtwUj3co", "keyAuthorization": 
> "iJcmtseVVljOzlLIKYoN0-Pu5SQ4sLcqmCGgtwUj3co.oHnB0_JsMCOWBPKhfVMYsIDZr_T2Wo-Y5z0fh-cmkA4"
> }] (336 bytes)
> acme-client: 
>

Re: acme-client new cert error

2018-05-25 Thread Fred


On 05/25/18 21:10, Scott Vanderbilt wrote:
I'm having difficulty creating a new SSL cert for a virtual host I'm 
just standing up for the first time. I get the following error on 
successive attempts:


urn:acme:error:unauthorized
Error creating new cert :: authorizations for these names not found or 
expired: aeneas.datagenic.com


I've verified it's not a web server access issue, as I am able to 
successfully retrieve a static HTML file from the challenge directory


    aeneas$ curl 
http://aeneas.datagenic.com/.well-known/acme-challenge/test.html

    Foo
    aeneas$

Complete verbose error message, config file, and dmesg follow.

Thanks in advance for any assistance you can lend.

 



aeneas# acme-client -vvAD aeneas.datagenic.com
acme-client: /etc/ssl/acme/private/aeneas.datagenic.com/privkey.pem: 
domain key exists (not creating)
acme-client: /etc/acme/letsencrypt-privkey.pem: account key exists (not 
creating)
acme-client: /etc/ssl/acme/private/aeneas.datagenic.com/privkey.pem: 
loaded RSA domain key

acme-client: /etc/acme/letsencrypt-privkey.pem: loaded RSA account key
acme-client: https://acme-v01.api.letsencrypt.org/directory: directories
acme-client: acme-v01.api.letsencrypt.org: DNS: 23.75.196.250
acme-client: transfer buffer: [{ "key-change": 
"https://acme-v01.api.letsencrypt.org/acme/key-change;, "meta": { 
"caaIdentities": [ "letsencrypt.org" ], "terms-of-service": 
"https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf;, 
"website": "https://letsencrypt.org; }, "new-authz": 
"https://acme-v01.api.letsencrypt.org/acme/new-authz;, "new-cert": 
"https://acme-v01.api.letsencrypt.org/acme/new-cert;, "new-reg": 
"https://acme-v01.api.letsencrypt.org/acme/new-reg;, "revoke-cert": 
"https://acme-v01.api.letsencrypt.org/acme/revoke-cert;, "sw0ePngTU-0": 
"https://community.letsencrypt.org/t/adding-random-entries-to-the-directory/33417; 
}] (658 bytes)
acme-client: https://acme-v01.api.letsencrypt.org/acme/new-authz: 
req-auth: aeneas.datagenic.com

acme-client: acme-v01.api.letsencrypt.org: cached
acme-client: acme-v01.api.letsencrypt.org: cached
acme-client: transfer buffer: [{ "identifier": { "type": "dns", "value": 
"aeneas.datagenic.com" }, "status": "pending", "expires": 
"2018-06-01T19:22:23Z", "challenges": [ { "type": "tls-sni-01", 
"status": "pending", "uri": 
"https://acme-v01.api.letsencrypt.org/acme/challenge/xFIciSX0MzV47lV98sOT6mojdXIXXfIh_2yiH-dzT6k/4809114624;, 
"token": "TpW1KNEcns3ebXVxbBwYToVOjsMEzR78MWySuyKvdhI" }, { "type": 
"dns-01", "status": "pending", "uri": 
"https://acme-v01.api.letsencrypt.org/acme/challenge/xFIciSX0MzV47lV98sOT6mojdXIXXfIh_2yiH-dzT6k/4809114625;, 
"token": "Iq66R_OgKJ2VURMLyVxLD8hjnWtLqrjqSYb0L3YRqNU" }, { "type": 
"http-01", "status": "pending", "uri": 
"https://acme-v01.api.letsencrypt.org/acme/challenge/xFIciSX0MzV47lV98sOT6mojdXIXXfIh_2yiH-dzT6k/4809114626;, 
"token": "iJcmtseVVljOzlLIKYoN0-Pu5SQ4sLcqmCGgtwUj3co" } ], 
"combinations": [ [ 1 ], [ 0 ], [ 2 ] ] }] (998 bytes)
acme-client: 
/var/www/htdocs/default/acme/iJcmtseVVljOzlLIKYoN0-Pu5SQ4sLcqmCGgtwUj3co: created 

acme-client: 
https://acme-v01.api.letsencrypt.org/acme/challenge/xFIciSX0MzV47lV98sOT6mojdXIXXfIh_2yiH-dzT6k/4809114626: 
challenge

acme-client: acme-v01.api.letsencrypt.org: cached
acme-client: acme-v01.api.letsencrypt.org: cached
acme-client: transfer buffer: [{ "type": "http-01", "status": "pending", 
"uri": 
"https://acme-v01.api.letsencrypt.org/acme/challenge/xFIciSX0MzV47lV98sOT6mojdXIXXfIh_2yiH-dzT6k/4809114626;, 
"token": "iJcmtseVVljOzlLIKYoN0-Pu5SQ4sLcqmCGgtwUj3co", 
"keyAuthorization": 
"iJcmtseVVljOzlLIKYoN0-Pu5SQ4sLcqmCGgtwUj3co.oHnB0_JsMCOWBPKhfVMYsIDZr_T2Wo-Y5z0fh-cmkA4" 
}] (336 bytes)
acme-client: 
https://acme-v01.api.letsencrypt.org/acme/challenge/xFIciSX0MzV47lV98sOT6mojdXIXXfIh_2yiH-dzT6k/4809114626: 
status

acme-client: acme-v01.api.letsencrypt.org: cached
acme-client: https://acme-v01.api.letsencrypt.org/acme/new-cert: 
certificate

acme-client: acme-v01.api.letsencrypt.org: cached
acme-client: acme-v01.api.letsencrypt.org: cached
acme-client: https://acme-v01.api.letsencrypt.org/acme/new-cert: bad 
HTTP: 403
acme-client: transfer buffer: [{ "type": "urn:acme:error:unauthorized", 
"detail": "Error creating new cert :: authorizations for these names not 
found or expired: aeneas.datagenic.com", "status": 403 }] (176 bytes)

acme-client: bad exit: netproc(38047): 1


-
aeneas$ cat /etc/acme-client.conf
#
# $OpenBSD: acme-client.conf,v 1.7 2018/04/13 08:24:38 ajacoutot Exp $
#
authority letsencrypt {
     api url "https://acme-v01.api.letsencrypt.org/directory;
     account key "/etc/acme/letsencrypt-privkey.pem"
}

authority letsencrypt-staging {
     api url "https://acme-staging.api.letsencrypt.org/directory;
     account key "/etc/acme/letsencrypt-staging-privkey.pem"
}

domain

Re: Viewport for man.openbsd.org -- readability on phones

2018-05-25 Thread Ingo Schwarze

Hi,

Ingo Schwarze wrote on Thu, May 24, 2018 at 09:15:29PM +0200:
> justina colmena wrote on Thu, May 24, 2018 at 05:54:45PM +:
>> On Wed, 23 May 2018 11:47:47 +0200 Marko Cupac wrote:

>>> I am sure OpenBSD will correct their errors in html/css code, if any,

>> Right now, https://man.openbsd.org/relayd.conf.5 fails html validation.
>> https://validator.w3.org/nu/?doc=https%3A%2F%2Fman.openbsd.org%2Frelayd.conf.5
>> There are several html  elements with duplicate IDs.

> Sure, that's on the TODO list:
[...]
> It's not the worst HTML syntax violation left in mandoc,
> and it's among the easier ones to fix.

Anyway, i just fixed it with the commit below (and also installed
the fix on man.openbsd.org).

[...]
> Actually, just skipping dupes may be better than suffixes because
> permalinks with suffixes don't make much sense.  As soon as someone
> inserts or deletes text, subsequent permalink anchors with suffixes
> might suddenly point to different places, which defeats the very
> purpose of permalinks.
> 
> Besides, the main virtue of mandoc permalinks is their simplicity,
> allowing people to type them by hand without even looking at the
> manual page first.  I just know that
> 
>   https://man.openbsd.org/cat#v
> 
> will work (and is harmful), without even testing it first.
> Appending suffixes would compromise that virtue.

After re-reading the discussion with Jakub, i came to the conclusion
that suffixes do *not* compromise that virtue -
  https://man.openbsd.org/cat#v
still works just like before even with suffixes because the first
occurence does of course not get a suffix.

Generating the deduplication suffixes is simple, does not force
anybody to actually use them, but they may occasionally be useful
in some situations - probably not so much as links from a static
website to man.openbsd.org, but for example for quickly directing
somebody from a chat to a particular point in the current version
of a specific manual page:

   i feel confused...  :-(
   well i'm talking about
https://man.openbsd.org/relayd.conf#forward_to_6
not about
https://man.openbsd.org/relayd.conf#forward_to_3

Yours,
  Ingo


Log Message:
---
Do not write duplicate id= attributes, they violate HTML syntax.
Append suffixes for disambiguation.  Issue first reported by Jakub
Klinkovsky  (Arch Linux).

Modified Files:
--
mandoc:
TODO
html.c
html.h
man_html.c
mdoc_html.c

Revision Data
-
Index: html.c
===
RCS file: /home/cvs/mandoc/mandoc/html.c,v
retrieving revision 1.228
retrieving revision 1.229
diff -Lhtml.c -Lhtml.c -u -p -r1.228 -r1.229
--- html.c
+++ html.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -29,6 +30,7 @@
 #include 
 
 #include "mandoc_aux.h"
+#include "mandoc_ohash.h"
 #include "mandoc.h"
 #include "roff.h"
 #include "out.h"
@@ -117,6 +119,9 @@ static  const char  *const roffscales[SCAL
"ex", /* SCALE_FS */
 };
 
+/* Avoid duplicate HTML id= attributes. */
+static struct ohash id_unique;
+
 static void a2width(const char *, struct roffsu *);
 static void print_byte(struct html *, char);
 static void print_endword(struct html *);
@@ -144,6 +149,8 @@ html_alloc(const struct manoutput *outop
if (outopts->fragment)
h->oflags |= HTML_FRAGMENT;
 
+   mandoc_ohash_init(_unique, 4, 0);
+
return h;
 }
 
@@ -152,15 +159,22 @@ html_free(void *p)
 {
struct tag  *tag;
struct html *h;
+   char*cp;
+   unsigned int slot;
 
h = (struct html *)p;
-
while ((tag = h->tag) != NULL) {
h->tag = tag->next;
free(tag);
}
-
free(h);
+
+   cp = ohash_first(_unique, );
+   while (cp != NULL) {
+   free(cp);
+   cp = ohash_next(_unique, );
+   }
+   ohash_delete(_unique);
 }
 
 void
@@ -257,10 +271,12 @@ print_metaf(struct html *h, enum mandoc_
 }
 
 char *
-html_make_id(const struct roff_node *n)
+html_make_id(const struct roff_node *n, int unique)
 {
const struct roff_node  *nch;
-   char*buf, *cp;
+   char*buf, *bufs, *cp;
+   unsigned int slot;
+   int  suffix;
 
for (nch = n->child; nch != NULL; nch = nch->next)
if (nch->type != ROFFT_TEXT)
@@ -277,6 +293,30 @@ html_make_id(const struct roff_node *n)
if (*cp == ' ')
*cp = '_';
 
+   if (unique == 0)
+   return buf;
+
+   /* Avoid duplicate HTML id= attributes. */
+
+   bufs = NULL;
+   suffix = 1;
+   slot = ohash_qlookup(_unique, buf);
+   cp = ohash_find(_unique, slot);
+   if (cp != NULL) {
+   while (cp != NULL) {
+   free(bufs);
+

Re: connect two midi devices

2018-05-25 Thread Alexandre Ratchov

On Fri, May 25, 2018 at 10:22:26AM +0200, Sebastian Reitenbach wrote:
> Hi Alexandre,
> 
> Am Freitag, Mai 25, 2018 08:41 CEST, Alexandre Ratchov  
> schrieb:
> 
> > On Fri, May 25, 2018 at 12:21:18AM +0200, Alexandre Ratchov wrote:
> > >
> > > Maybe, but unlikely. If the device attaches, generally it works. Show
> > > what's received on midi2 when you type on the keyboard or do any other
> > > simple actions.
> > >
> >
> > fwiw, here's a small utility that I use very often to debug & connect
> > MIDI ports.
> >
> > http://caoua.org/alex/obsd/midicat.tar.gz
> >
> > To connect two rmidi/2 -> rmidi/1 and dump the data on stderr, run:
> >
> > midicat -d -q rmidi/2 -q rmidi/1
> 
>  Actually, that midicat seems to do the trick. When I run it in debug, and 
> press some keys on the
> system-1, output looks like:
> 
> f8
> f8
> fe
> f8
> f8
> f8
> 90 80 9b

^^^

these 3 bytes make no sense. The status byte 0x90 is correct but the
two args are wrong. This is when you pressed the key, right?

> ...
> 90 9b b2

These are also wrong, and this is when you released the key, right?
Interestingly the 0x9b is repeated.

> f8
> f8
> f8
> f8
> 
>  However, some keys I have to press multiple times until the Rocket Synth 
> recognizes it, and
> some other note from the synth, doesn't produce any sound on the Rocket.
> However, when I connect the System 1 MIDI out, with a straight MIDI cable to 
> MIDI in
> on the Rocket, I can play these notes, and it produces sound, on each key 
> press.
> 

Clearly, the midi events are corrupted by the usb interface. Does the
midi interface claim to be "class compliant"? does it come with
drivers for MacOS or Windows?

> The System-1, as well as the TB-3 are connected to my MX-1 via USB.
> I noticed I have to disconnect the USB from the system-1. Only then it seems 
> to
> send out MIDI data on the MIDI port.
> Maybe that was my main problem yesterday.
> Since I use the USB connection to the MX-1 for MIDI and SOUND, disconnecting
> the USB cable from the system-1 or tb-3 would spoil my setup.
> The Roland Aira gear doesn't seem to have a mode to support class compatible
> MIDI via USB. It only provides some USB Disk modes for backup/restore and
> firmware updates.
> 
> 
> I wonder how I could tell midicat which midi channel to use. I.e. I cound 
> connect
> the USB-to-MIDI converter to the Roland MX-1, and since all the other gear is
> connected there, it might work out, when the MX-1 is set to MIDI passthrough.
> But I might be able to tell midish to connect that same hardware midi device
> as input to output, but with different midi channels?

If you use the MIDI passthrough, events will be broadcast to both
devices, so you'll have to configure each device to ignore channels
that you want the other device to handle.

midicat just moves the data, so you it can't change the channel
numbers. To change the channel you can use the fmap rule in midish.

acme-client new cert error

2018-05-25 Thread Scott Vanderbilt

I'm having difficulty creating a new SSL cert for a virtual host I'm 
just standing up for the first time. I get the following error on 
successive attempts:


urn:acme:error:unauthorized
Error creating new cert :: authorizations for these names not found or 
expired: aeneas.datagenic.com


I've verified it's not a web server access issue, as I am able to 
successfully retrieve a static HTML file from the challenge directory


   aeneas$ curl 
http://aeneas.datagenic.com/.well-known/acme-challenge/test.html

   Foo
   aeneas$

Complete verbose error message, config file, and dmesg follow.

Thanks in advance for any assistance you can lend.



aeneas# acme-client -vvAD aeneas.datagenic.com
acme-client: /etc/ssl/acme/private/aeneas.datagenic.com/privkey.pem: 
domain key exists (not creating)
acme-client: /etc/acme/letsencrypt-privkey.pem: account key exists (not 
creating)
acme-client: /etc/ssl/acme/private/aeneas.datagenic.com/privkey.pem: 
loaded RSA domain key

acme-client: /etc/acme/letsencrypt-privkey.pem: loaded RSA account key
acme-client: https://acme-v01.api.letsencrypt.org/directory: directories
acme-client: acme-v01.api.letsencrypt.org: DNS: 23.75.196.250
acme-client: transfer buffer: [{ "key-change": 
"https://acme-v01.api.letsencrypt.org/acme/key-change;, "meta": { 
"caaIdentities": [ "letsencrypt.org" ], "terms-of-service": 
"https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf;, 
"website": "https://letsencrypt.org; }, "new-authz": 
"https://acme-v01.api.letsencrypt.org/acme/new-authz;, "new-cert": 
"https://acme-v01.api.letsencrypt.org/acme/new-cert;, "new-reg": 
"https://acme-v01.api.letsencrypt.org/acme/new-reg;, "revoke-cert": 
"https://acme-v01.api.letsencrypt.org/acme/revoke-cert;, "sw0ePngTU-0": 
"https://community.letsencrypt.org/t/adding-random-entries-to-the-directory/33417; 
}] (658 bytes)
acme-client: https://acme-v01.api.letsencrypt.org/acme/new-authz: 
req-auth: aeneas.datagenic.com

acme-client: acme-v01.api.letsencrypt.org: cached
acme-client: acme-v01.api.letsencrypt.org: cached
acme-client: transfer buffer: [{ "identifier": { "type": "dns", "value": 
"aeneas.datagenic.com" }, "status": "pending", "expires": 
"2018-06-01T19:22:23Z", "challenges": [ { "type": "tls-sni-01", 
"status": "pending", "uri": 
"https://acme-v01.api.letsencrypt.org/acme/challenge/xFIciSX0MzV47lV98sOT6mojdXIXXfIh_2yiH-dzT6k/4809114624;, 
"token": "TpW1KNEcns3ebXVxbBwYToVOjsMEzR78MWySuyKvdhI" }, { "type": 
"dns-01", "status": "pending", "uri": 
"https://acme-v01.api.letsencrypt.org/acme/challenge/xFIciSX0MzV47lV98sOT6mojdXIXXfIh_2yiH-dzT6k/4809114625;, 
"token": "Iq66R_OgKJ2VURMLyVxLD8hjnWtLqrjqSYb0L3YRqNU" }, { "type": 
"http-01", "status": "pending", "uri": 
"https://acme-v01.api.letsencrypt.org/acme/challenge/xFIciSX0MzV47lV98sOT6mojdXIXXfIh_2yiH-dzT6k/4809114626;, 
"token": "iJcmtseVVljOzlLIKYoN0-Pu5SQ4sLcqmCGgtwUj3co" } ], 
"combinations": [ [ 1 ], [ 0 ], [ 2 ] ] }] (998 bytes)
acme-client: 
/var/www/htdocs/default/acme/iJcmtseVVljOzlLIKYoN0-Pu5SQ4sLcqmCGgtwUj3co: 
created
acme-client: 
https://acme-v01.api.letsencrypt.org/acme/challenge/xFIciSX0MzV47lV98sOT6mojdXIXXfIh_2yiH-dzT6k/4809114626: 
challenge

acme-client: acme-v01.api.letsencrypt.org: cached
acme-client: acme-v01.api.letsencrypt.org: cached
acme-client: transfer buffer: [{ "type": "http-01", "status": "pending", 
"uri": 
"https://acme-v01.api.letsencrypt.org/acme/challenge/xFIciSX0MzV47lV98sOT6mojdXIXXfIh_2yiH-dzT6k/4809114626;, 
"token": "iJcmtseVVljOzlLIKYoN0-Pu5SQ4sLcqmCGgtwUj3co", 
"keyAuthorization": 
"iJcmtseVVljOzlLIKYoN0-Pu5SQ4sLcqmCGgtwUj3co.oHnB0_JsMCOWBPKhfVMYsIDZr_T2Wo-Y5z0fh-cmkA4" 
}] (336 bytes)
acme-client: 
https://acme-v01.api.letsencrypt.org/acme/challenge/xFIciSX0MzV47lV98sOT6mojdXIXXfIh_2yiH-dzT6k/4809114626: 
status

acme-client: acme-v01.api.letsencrypt.org: cached
acme-client: https://acme-v01.api.letsencrypt.org/acme/new-cert: certificate
acme-client: acme-v01.api.letsencrypt.org: cached
acme-client: acme-v01.api.letsencrypt.org: cached
acme-client: https://acme-v01.api.letsencrypt.org/acme/new-cert: bad 
HTTP: 403
acme-client: transfer buffer: [{ "type": "urn:acme:error:unauthorized", 
"detail": "Error creating new cert :: authorizations for these names not 
found or expired: aeneas.datagenic.com", "status": 403 }] (176 bytes)

acme-client: bad exit: netproc(38047): 1


-
aeneas$ cat /etc/acme-client.conf
#
# $OpenBSD: acme-client.conf,v 1.7 2018/04/13 08:24:38 ajacoutot Exp $
#
authority letsencrypt {
    api url "https://acme-v01.api.letsencrypt.org/directory;
    account key "/etc/acme/letsencrypt-privkey.pem"
}

authority letsencrypt-staging {
    api url "https://acme-staging.api.letsencrypt.org/directory;
    account key "/etc/acme/letsencrypt-staging-privkey.pem"
}

domain aeneas.datagenic.com {
#   alternative names {

Re: Checking my new smtpd.conf syntax

2018-05-25 Thread Walter Alejandro Iglesias

On Fri, May 25, 2018 at 03:58:59PM +0300, Consus wrote:
> On 14:31 Fri 25 May, Gilles Chehade wrote:
> > On Fri, May 25, 2018 at 02:20:50PM +0200, Walter Alejandro Iglesias wrote:
> > > Could someone tell me if my changes below are OK. :-)
> > > 
> > > The part I'm not clear is I read in current.html remote authenticated
> > > users need a explicit rule.  Do I need to add some "match auth" rule?
> > > 
> > 
> > yes.
> > 
> > before, "from local" would match authenticated users as if they had sent
> > mail from the local machine but this led to being unable to express some
> > setups where depending on the source you want to relay to different hubs
> > even though users are authenticated.
> > 
> > 
> > With this:
> > 
> > > match from local for local apply local_users
> > > match from any for domain  virtual  apply local_users
> > > match from local sender  for any apply remote_users
> > 
> > you need an additonal rule such as:
> > 
> > match auth from any sender  for any apply remote_users
> > 
> > 
> > because:
> > 
> > > #accept from local sender  for any relay
> > 
> > no longer matches authenticated users
> 
> Ain't it "action local_users" instead of "apply local_users"? The man
> page states "action".

I took the "apply" from here:

  https://undeadly.org/cgi?action=article;sid=20180430122930

Now reading this:

  https://poolp.org/posts/2018-05-21/switching-to-opensmtpd-new-config/

I see I also have to change the "certificate" keyword to "cert" here:

  pki $server cert "/etc/ssl/server.crt"


Gilles, I also saw the "ca" directive.  I've been using the acme
certificates in pki directives, can I use them in the "ca" directive
too? (any advantage in doing this?)



Walter

Ubiquiti Networks EdgeRouter 6P

2018-05-25 Thread Chris Jones

Good afternoon,

I see that the Ubiquiti EdgeRouter 6P is supported under octeon port. 
Just wondering if anyone on the list is running OpenBSD 6.3 or current 
on the EdgeRouter 6P? I'm mainly interested in the performance of this 
unit as a home firewall but also interested in using it for other SMB 
applications.

I would generally be running standard network services plus 
isakmpd/iked, ospfd, unbound. Also, is it fair to assume the PoE ports 
are just active by default?

Cheers,
-Chris

Inconsistent stats between snmpd(8) and pfctl(8) ?

2018-05-25 Thread Joel Carnat


Hi,

On OpenBSD 6.3/amd64, I'm using snmpd(8) to gather pf(4) statistics.
It seems that some stats are not coherent.

For example, on egress and vio0 interfaces.
Asking snmpd(8), I get :
OPENBSD-PF-MIB::pfIfDescr.3 = STRING: "egress"
OPENBSD-PF-MIB::pfIfDescr.12 = STRING: "vio0"
OPENBSD-PF-MIB::pfIfType.3 = INTEGER: group(0)
OPENBSD-PF-MIB::pfIfType.12 = INTEGER: instance(1)
OPENBSD-PF-MIB::pfIfRules.3 = Gauge32: 12
OPENBSD-PF-MIB::pfIfRules.12 = Gauge32: 1
Asking pfctl(8), I get :
# pfctl -s rules | grep -c egress
8
# pfctl -s rules | grep -c vio0
0

According to the MIB, pfIfRules is "The number of rules which reference 
the interface."


Am I wrong expecting the numbers should be the same ?

Thank you.

Re: programs crash on Dell Latitude E7470

2018-05-25 Thread Ken MacKenzie

Minor OTA

This morning, before my coffee, this email really messed with me.

> $ uname -a
> OpenBSD ultron.hulten.org 6.3 GENERIC.MP#45 amd64

One of my machines is named ultron as well...

Ken

Re: programs crash on Dell Latitude E7470

2018-05-25 Thread Marco van Hulten

Hello, some more information,

On 25 May 14:15 Marco van Hulten wrote:
> I have a Dell Latitude E7470 with the latest OpenBSD snapshot.  
> 
> [...]

I also updated the software packages to the snapshot (pkg_add -u);
problem persists.

> Applications crash.  For instance for Claws Mail:
> 
> Segmentation fault  (core dumped) claws-mail
> [...]

This happens at apparantly arbitrary moments, with or without user
interaction, usually within 20 minutes or so after starting the program
(same behaviour of Firefox, Claws Mail, Gajim, ...).

Marco

Re: Dell Latitude and E-Port II: system hangs

2018-05-25 Thread Marco van Hulten

Hello, responding to my own post,

On 25 May 13:50 Marco van Hulten wrote:
> I have a Dell Latitude E7470 with the latest OpenBSD snapshot.  It
> boots fine when not connected to a docking station.  When I connect it
> to a DELL E-Port II (Model No: PR03X) docking station, it crashes with
> the following kernel error:
> 
> error: [drm:pid8048:i915_gem_init_hw] *ERROR* Failed to initialize
> GuC, error -9 (ignored) error:
> [drm:pid73911:intel_dp_link_training_clock_recovery] *ERROR* too many
> full retries, give up error: [drm:pid73911:intel_dp_aux_wait_done]
> *ERROR* dp aux hw did not signal timeout (has irq: 1)! error:
> [drm:pid73911:intel_dp_set_idle_link_train] *ERROR* Timed out waiting
> for DP idle patterns

This specific issue appears to have disappeared (for now).  I'm typing
this on the laptop, running OpenBSD, with the docking station attached.

There is still a current issue with the docking station.  When I
connect or disconnect, the laptop freezes (no kernel messages show up),
and I can only do a hard shutdown by pressing the power button for
about 5 s or so.

Marco

Re: Checking my new smtpd.conf syntax

2018-05-25 Thread Gilles Chehade

On Fri, May 25, 2018 at 09:27:21AM -0400, Amelia A Lewis wrote:
> On Fri, 25 May 2018 16:15:00 +0300, Consus wrote:
> > On 15:14 Fri 25 May, Gilles Chehade wrote:
> >> On Fri, May 25, 2018 at 03:58:59PM +0300, Consus wrote:
> >>> On 14:31 Fri 25 May, Gilles Chehade wrote:
>  
>  you need an additonal rule such as:
>  
>  match auth from any sender  for any apply remote_users
>  
>  because:
>  
> > #accept from local sender  for any relay
>  
>  no longer matches authenticated users
> >>> 
> >>> Ain't it "action local_users" instead of "apply local_users"? The man
> >>> page states "action".
> >> 
> >> oopsie, yes, action, forget about apply, it doesn't exist, I should not
> >> answer mail while talking on the phone :-)
> > 
> > Frankly, I like apply better :(
> 
> For what it's worth (this is *not* a democracy), I like apply better as 
> well. "action" to declare; "apply" to refer. There's then no 
> possibility that someone will attempt to create an action "inline" in a 
> match directive; the syntax of reference is 'keyword barename' while 
> the syntax of declaration is 'keyword uniquename activities'. Different 
> keywords makes it unambiguous for humans; can't use declaration syntax 
> where reference keyword is used.
> 
> I looked at your tests, Gilles, and was hopeful because they all use 
> 'apply'. I found that easier to understand. However ... chances are, if 
> the tests were created early, that others have already argued in favor 
> of using the same keyword for declarations and references.
> 

indeed, but at least your mail made me update the tests :-)

thanks!


-- 
Gilles Chehade

https://www.poolp.org  @poolpOrg

Re: Checking my new smtpd.conf syntax

2018-05-25 Thread Amelia A Lewis

On Fri, 25 May 2018 16:15:00 +0300, Consus wrote:
> On 15:14 Fri 25 May, Gilles Chehade wrote:
>> On Fri, May 25, 2018 at 03:58:59PM +0300, Consus wrote:
>>> On 14:31 Fri 25 May, Gilles Chehade wrote:

 you need an additonal rule such as:

 match auth from any sender  for any apply remote_users

 because:

> #accept from local sender  for any relay

 no longer matches authenticated users
>>> 
>>> Ain't it "action local_users" instead of "apply local_users"? The man
>>> page states "action".
>> 
>> oopsie, yes, action, forget about apply, it doesn't exist, I should not
>> answer mail while talking on the phone :-)
> 
> Frankly, I like apply better :(

For what it's worth (this is *not* a democracy), I like apply better as 
well. "action" to declare; "apply" to refer. There's then no 
possibility that someone will attempt to create an action "inline" in a 
match directive; the syntax of reference is 'keyword barename' while 
the syntax of declaration is 'keyword uniquename activities'. Different 
keywords makes it unambiguous for humans; can't use declaration syntax 
where reference keyword is used.

I looked at your tests, Gilles, and was hopeful because they all use 
'apply'. I found that easier to understand. However ... chances are, if 
the tests were created early, that others have already argued in favor 
of using the same keyword for declarations and references.

Amy!
Amelia A. Lewisamyzing {at} talsever.com
  Light is the left hand of darkness
  and darkness the right hand of light.
Two are one, life and death, lying
together like lovers in kemmer,
  like hands joined together,
  like the end and the way.
-- Tormer's Lay [Ursula K. Le Guin, "The Left Hand of Darkness"]

Re: Checking my new smtpd.conf syntax

2018-05-25 Thread Consus

On 15:20 Fri 25 May, Gilles Chehade wrote:
> no matter the keywords, there's no way 100% people would be satisfied :)
> 
> be happy, first iteration was "match [...] => foobar", now 'action'
> does not look so bad hu ?

Guess so :D

Re: Checking my new smtpd.conf syntax

2018-05-25 Thread Gilles Chehade

On Fri, May 25, 2018 at 04:15:00PM +0300, Consus wrote:
> On 15:14 Fri 25 May, Gilles Chehade wrote:
> > On Fri, May 25, 2018 at 03:58:59PM +0300, Consus wrote:
> > > On 14:31 Fri 25 May, Gilles Chehade wrote:
> > > > On Fri, May 25, 2018 at 02:20:50PM +0200, Walter Alejandro Iglesias 
> > > > wrote:
> > > > > Could someone tell me if my changes below are OK. :-)
> > > > > 
> > > > > The part I'm not clear is I read in current.html remote authenticated
> > > > > users need a explicit rule.  Do I need to add some "match auth" rule?
> > > > > 
> > > > 
> > > > yes.
> > > > 
> > > > before, "from local" would match authenticated users as if they had sent
> > > > mail from the local machine but this led to being unable to express some
> > > > setups where depending on the source you want to relay to different hubs
> > > > even though users are authenticated.
> > > > 
> > > > 
> > > > With this:
> > > > 
> > > > > match from local for local apply local_users
> > > > > match from any for domain  virtual  apply 
> > > > > local_users
> > > > > match from local sender  for any apply remote_users
> > > > 
> > > > you need an additonal rule such as:
> > > > 
> > > > match auth from any sender  for any apply remote_users
> > > > 
> > > > 
> > > > because:
> > > > 
> > > > > #accept from local sender  for any relay
> > > > 
> > > > no longer matches authenticated users
> > > 
> > > Ain't it "action local_users" instead of "apply local_users"? The man
> > > page states "action".
> > 
> > oopsie, yes, action, forget about apply, it doesn't exist, I should not
> > answer mail while talking on the phone :-)
> 
> Frankly, I like apply better :(
> 

no matter the keywords, there's no way 100% people would be satisfied :)

be happy, first iteration was "match [...] => foobar", now 'action' does
not look so bad hu ?


-- 
Gilles Chehade

https://www.poolp.org  @poolpOrg

Re: Checking my new smtpd.conf syntax

2018-05-25 Thread Consus

On 15:14 Fri 25 May, Gilles Chehade wrote:
> On Fri, May 25, 2018 at 03:58:59PM +0300, Consus wrote:
> > On 14:31 Fri 25 May, Gilles Chehade wrote:
> > > On Fri, May 25, 2018 at 02:20:50PM +0200, Walter Alejandro Iglesias wrote:
> > > > Could someone tell me if my changes below are OK. :-)
> > > > 
> > > > The part I'm not clear is I read in current.html remote authenticated
> > > > users need a explicit rule.  Do I need to add some "match auth" rule?
> > > > 
> > > 
> > > yes.
> > > 
> > > before, "from local" would match authenticated users as if they had sent
> > > mail from the local machine but this led to being unable to express some
> > > setups where depending on the source you want to relay to different hubs
> > > even though users are authenticated.
> > > 
> > > 
> > > With this:
> > > 
> > > > match from local for local apply local_users
> > > > match from any for domain  virtual  apply 
> > > > local_users
> > > > match from local sender  for any apply remote_users
> > > 
> > > you need an additonal rule such as:
> > > 
> > > match auth from any sender  for any apply remote_users
> > > 
> > > 
> > > because:
> > > 
> > > > #accept from local sender  for any relay
> > > 
> > > no longer matches authenticated users
> > 
> > Ain't it "action local_users" instead of "apply local_users"? The man
> > page states "action".
> 
> oopsie, yes, action, forget about apply, it doesn't exist, I should not
> answer mail while talking on the phone :-)

Frankly, I like apply better :(

Re: Checking my new smtpd.conf syntax

2018-05-25 Thread Gilles Chehade

On Fri, May 25, 2018 at 03:58:59PM +0300, Consus wrote:
> On 14:31 Fri 25 May, Gilles Chehade wrote:
> > On Fri, May 25, 2018 at 02:20:50PM +0200, Walter Alejandro Iglesias wrote:
> > > Could someone tell me if my changes below are OK. :-)
> > > 
> > > The part I'm not clear is I read in current.html remote authenticated
> > > users need a explicit rule.  Do I need to add some "match auth" rule?
> > > 
> > 
> > yes.
> > 
> > before, "from local" would match authenticated users as if they had sent
> > mail from the local machine but this led to being unable to express some
> > setups where depending on the source you want to relay to different hubs
> > even though users are authenticated.
> > 
> > 
> > With this:
> > 
> > > match from local for local apply local_users
> > > match from any for domain  virtual  apply local_users
> > > match from local sender  for any apply remote_users
> > 
> > you need an additonal rule such as:
> > 
> > match auth from any sender  for any apply remote_users
> > 
> > 
> > because:
> > 
> > > #accept from local sender  for any relay
> > 
> > no longer matches authenticated users
> 
> Ain't it "action local_users" instead of "apply local_users"? The man
> page states "action".

oopsie, yes, action, forget about apply, it doesn't exist, I should not
answer mail while talking on the phone :-)


-- 
Gilles Chehade

https://www.poolp.org  @poolpOrg

Re: Checking my new smtpd.conf syntax

2018-05-25 Thread Consus

On 14:31 Fri 25 May, Gilles Chehade wrote:
> On Fri, May 25, 2018 at 02:20:50PM +0200, Walter Alejandro Iglesias wrote:
> > Could someone tell me if my changes below are OK. :-)
> > 
> > The part I'm not clear is I read in current.html remote authenticated
> > users need a explicit rule.  Do I need to add some "match auth" rule?
> > 
> 
> yes.
> 
> before, "from local" would match authenticated users as if they had sent
> mail from the local machine but this led to being unable to express some
> setups where depending on the source you want to relay to different hubs
> even though users are authenticated.
> 
> 
> With this:
> 
> > match from local for local apply local_users
> > match from any for domain  virtual  apply local_users
> > match from local sender  for any apply remote_users
> 
> you need an additonal rule such as:
> 
> match auth from any sender  for any apply remote_users
> 
> 
> because:
> 
> > #accept from local sender  for any relay
> 
> no longer matches authenticated users

Ain't it "action local_users" instead of "apply local_users"? The man
page states "action".

Re: Checking my new smtpd.conf syntax

2018-05-25 Thread Gilles Chehade

On Fri, May 25, 2018 at 02:20:50PM +0200, Walter Alejandro Iglesias wrote:
> Could someone tell me if my changes below are OK. :-)
> 
> The part I'm not clear is I read in current.html remote authenticated
> users need a explicit rule.  Do I need to add some "match auth" rule?
> 

yes.

before, "from local" would match authenticated users as if they had sent
mail from the local machine but this led to being unable to express some
setups where depending on the source you want to relay to different hubs
even though users are authenticated.


With this:

> match from local for local apply local_users
> match from any for domain  virtual  apply local_users
> match from local sender  for any apply remote_users

you need an additonal rule such as:

match auth from any sender  for any apply remote_users


because:

> #accept from local sender  for any relay

no longer matches authenticated users



-- 
Gilles Chehade

https://www.poolp.org  @poolpOrg

Checking my new smtpd.conf syntax

2018-05-25 Thread Walter Alejandro Iglesias

Could someone tell me if my changes below are OK. :-)

The part I'm not clear is I read in current.html remote authenticated
users need a explicit rule.  Do I need to add some "match auth" rule?


# /etc/mail/smptd.conf

egress_int="em0"
server="server.roquesor.com"

table aliases   file:/etc/mail/aliases
table valiases  file:/etc/mail/valiases
table vdomains  file:/etc/mail/vdomains
table addresses file:/etc/mail/addresses
table users file:/etc/mail/users

pki $server certificate "/etc/ssl/server.crt"
pki $server key "/etc/ssl/private/server.key"

listen on lo0
listen on $egress_int port 25 tls pki $server
listen on $egress_int port 465 smtps pki $server auth \
senders  masquerade

# Old
#accept from local for local alias  deliver to mbox
#accept from any for domain  virtual  deliver to mbox
#accept from local sender  for any relay

# New
action local_users mbox alias 
action remote_users relay

match from local for local apply local_users
match from any for domain  virtual  apply local_users
match from local sender  for any apply remote_users

# End of file

programs crash on Dell Latitude E7470

2018-05-25 Thread Marco van Hulten

Hello—

I have a Dell Latitude E7470 with the latest OpenBSD snapshot.  

$ uname -a
OpenBSD ultron.hulten.org 6.3 GENERIC.MP#45 amd64

dmesg is attached.

Applications crash.  For instance for Claws Mail:

Segmentation fault  (core dumped) claws-mail

For Firefox there might be more useful output:

...
runSafeSyncWithoutClone@resource://gre/modules/ExtensionUtils.jsm:73:129
runSafeWithoutClone@resource://gre/modules/ExtensionCommon.jsm:133:38
wrapPromise/<@resource://gre/modules/ExtensionCommon.jsm:312:13
]]
runSafe failure: cloning into [object Sandbox]: out of memory

runSafeSync@resource://gre/modules/ExtensionUtils.jsm:102:86
runSafe@resource://gre/modules/ExtensionCommon.jsm:123:32
_fireCommon/<@resource://gre/modules/ExtensionUtils.jsm:667:49
Assertion failure: [unhandlable oom] Failed to allocate object while 
tenuring., at 
/usr/obj/ports/firefox-esr-52.8.0/firefox-52.8.0esr/js/src/jscntxt.cpp:1153
[Child 68754] ###!!! ABORT: Aborting on channel error.: file 
/usr/obj/ports/firefox-esr-52.8.0/firefox-52.8.0esr/ipc/glue/MessageChannel.cpp,
 line 2152
[Child 68754] ###!!! ABORT: Aborting on channel error.: file 
/usr/obj/ports/firefox-esr-52.8.0/firefox-52.8.0esr/ipc/glue/MessageChannel.cpp,
 line 2152
Segmentation fault (core dumped)


Other programs gave a segfault as well; my guess is these segfaults
have a common reason.  There are core files
{abiword,calcures,chrome,claws-mail,conkey,firefox-esr}.core in my
homedir.  Is it useful to provide a traceback of one or more?  Here is
just the last few lines of one of them (abiword), and the only one that
give a hint to the issue, as far as I can see:

...
#0  _libc_towctrans (c=-247532, desc=0x6) at 
/usr/src/lib/libc/locale/iswctype.c:195
195 /usr/src/lib/libc/locale/iswctype.c: No such file or directory.
in /usr/src/lib/libc/locale/iswctype.c
(gdb) 


Any help is appreciated.

—Marco

Dell Latitude and E-Port II: system hangs

2018-05-25 Thread Marco van Hulten

Hello—

I have a Dell Latitude E7470 with the latest OpenBSD snapshot.  It
boots fine when not connected to a docking station.  When I connect it
to a DELL E-Port II (Model No: PR03X) docking station, it crashes with
the following kernel error:

error: [drm:pid8048:i915_gem_init_hw] *ERROR* Failed to initialize GuC, error 
-9 (ignored)
error: [drm:pid73911:intel_dp_link_training_clock_recovery] *ERROR* too many 
full retries, give up
error: [drm:pid73911:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal 
timeout (has irq: 1)!
error: [drm:pid73911:intel_dp_set_idle_link_train] *ERROR* Timed out waiting 
for DP idle patterns

Is this an issue with the docking station, the laptop or OpenBSD?  Does
someone have an idea how this issue can be solved?


$ uname -a
OpenBSD ultron.hulten.org 6.3 GENERIC.MP#45 amd64

—Marco

Re: build and ports mismatching ?

2018-05-25 Thread Marc Espie

On Fri, May 25, 2018 at 07:51:15AM +, Stuart Henderson wrote:

> That is at least detected by package tools and more easily fixed :)

The package tools err on the side of caution because we've been burnt
too many times.

There is often whining about it from other developers because sometimes
it's a pain to keep everything in synch, but it saves the ass of end users.

Re: Fair Pay In Cyberspace! Addendum.

2018-05-25 Thread Ywe Cærlyn


And regarding earlier statements:

Indeed, printers should have good drivers.

Best Regards,
Fair Pay In Cyberspace
https://www.youtube.com/watch?v=DnvPGTvI8hw

Status of Bluetooth support?

2018-05-25 Thread Ken M

I know Bluetooth support was pulled, but I was wondering if there was any new
information about it being rekindled in some fashion. My primary interest is the
bluetooth audio side. 

If there is or isn't I would be interested in helping to make it happen. Not
sure I am the best person to code it, but testing, advocating, documenting,
whatever.

Anyway if someone is working on it, would like to know what I could do to help.
If no one is, well I guess I gotta figure out how to help change that.

Thanks,
Ken

Re: attach chroot-jail to switchd(8) ?

2018-05-25 Thread Thomas Huber

rdomain is interessting, wasn´t aware of that.
thanks for this input Claudio.

On 24 May 2018 at 19:58, trondd  wrote:

> On Thu, May 24, 2018 1:28 pm, Claudio Jeker wrote:
> > On Thu, May 24, 2018 at 09:22:32AM -0400, trondd wrote:
> >> On Wed, May 23, 2018 4:35 am, Thomas Huber wrote:
> >> > Hi all,
> >> >
> >> > IÃ*Â´m just tinkering a little bit and try to mimic some
> >> "containerization"
> >> > on
> >> > OpenBSD with chroot. Is it somehow possible to attach a chrooted
> >> > envirionment to swtichd(8) ?
> >> >
> >> > Thanks
> >> > Thomas
> >> >
> >>
> >> OpenBSD's chroot is not like a Linux contianer or FreeBSD jail.  There
> >> is
> >> no network isolation.  Inside the chroot, you get all the same
> >> interfaces,
> >> IP's, routes, ports as on the "host" or in another chroot.  So doing
> >> anything with the network in the chroot is exactly as same as doing it
> >> normally.
> >>
> >> If you want to isolate, you probably need vether or tap or the like to
> >> make virtual interfaces and manually tie them to whatever you have
> >> running
> >> in the chroots and muanully set up proxies or whatever you need to make
> >> services accessible.
> >>
> >
> > This is only partially true. If you use alternate routing tables or
> > rdomain, route -T  exec will get you network isolation. Processes can
> > not change the rtable unless they run as superuser. It is not perfect but
> > neither is the linux or freebsd solution when it comes to networking.
> >
> > --
> > :wq Claudio
> >
>
> Sorry, yes.  I meant to mention rdomains, which I think it a pretty cool
> option worth tinkering with.
>
>


-- 
+49.179.1448024
Karl-Kunger-Straße 68
D - 12435 Berlin

Re: connect two midi devices

2018-05-25 Thread Sebastian Reitenbach

Hi Alexandre,

Am Freitag, Mai 25, 2018 08:41 CEST, Alexandre Ratchov  schrieb:

> On Fri, May 25, 2018 at 12:21:18AM +0200, Alexandre Ratchov wrote:
> >
> > Maybe, but unlikely. If the device attaches, generally it works. Show
> > what's received on midi2 when you type on the keyboard or do any other
> > simple actions.
> >
>
> fwiw, here's a small utility that I use very often to debug & connect
> MIDI ports.
>
> http://caoua.org/alex/obsd/midicat.tar.gz
>
> To connect two rmidi/2 -> rmidi/1 and dump the data on stderr, run:
>
> midicat -d -q rmidi/2 -q rmidi/1

 Actually, that midicat seems to do the trick. When I run it in debug, and 
press some keys on the
system-1, output looks like:

f8
f8
fe
f8
f8
f8
90 80 9b
f8
f8
f8
f8
f8
f8
f8
f8
f8
f8
f8
f8
f8
f8
f8
f8
fe
f8
f8
f8
f8
f8
f8
f8
f8
f8
f8
f8
f8
f8
f8
f8
f8
f8
f8
f8
fe
f8
90 9b b2
f8
f8
f8
f8

 However, some keys I have to press multiple times until the Rocket Synth 
recognizes it, and
some other note from the synth, doesn't produce any sound on the Rocket.
However, when I connect the System 1 MIDI out, with a straight MIDI cable to 
MIDI in
on the Rocket, I can play these notes, and it produces sound, on each key press.

The System-1, as well as the TB-3 are connected to my MX-1 via USB.
I noticed I have to disconnect the USB from the system-1. Only then it seems to
send out MIDI data on the MIDI port.
Maybe that was my main problem yesterday.
Since I use the USB connection to the MX-1 for MIDI and SOUND, disconnecting
the USB cable from the system-1 or tb-3 would spoil my setup.
The Roland Aira gear doesn't seem to have a mode to support class compatible
MIDI via USB. It only provides some USB Disk modes for backup/restore and
firmware updates.

I wonder how I could tell midicat which midi channel to use. I.e. I cound 
connect
the USB-to-MIDI converter to the Roland MX-1, and since all the other gear is
connected there, it might work out, when the MX-1 is set to MIDI passthrough.
But I might be able to tell midish to connect that same hardware midi device
as input to output, but with different midi channels?

Thanks,
Sebastian

Re: build and ports mismatching ?

2018-05-25 Thread Stuart Henderson

On 2018-05-24, Sebastian Benoit  wrote:
> Base system snapshots (including xenocara) and packages are not build
> at the same time. Package builds use the latest snapshot, but since
> building packages takes a day or so (depending on the arcitecture and
> build machines available) and distribution of the packages to the mirrors
> also tkes time, there is a time lag between the newer version of a base
> library available and the package that uses it being available.

Build time is around a day on the amd64 cluster, i386 a little longer,
some other arches a *lot* longer.

The exact problem here is:

- packages are built against libfreetype.so.28.2

- X provides libfreetype.so.29.0

- some other X libraries (libfontconfig etc) depend on new libfreetype
but the library version on those remained the same

- some packages depend on *both* libfontconfig and libfreetype, so the
dynamic linker loads one of the libfreetype versions and the other
libraries, notices the conflict, and warns you. (sometimes it's
harmless enough, but there could be disastrous consequences).

In this case the best thing to do is sit it out and wait for new
packages but the commit process was wrong. To avoid problems with
packages or locally compiled software, the other libraries in X that
dependg on libfreetype should have received the same type of library
bump as libfreetype itself.

> Add to that that you (as user) probably do not catch every library bump of
> base system libries when updating your machine, you can get into the
> situation that base has a newer lib than what a package needs, but the older
> lib that the package needs is newer than the old version thats still on
> your system because you skipped that.

That is at least detected by package tools and more easily fixed :)

Re: smtpd.conf new grammar

2018-05-25 Thread Gilles Chehade

On Thu, May 24, 2018 at 04:38:17PM -0400, Rupert Gallagher wrote:
> On Thu, May 24, 2018 at 14:18, Gilles Chehade  wrote:
> 
> > In effect, instead of having:
> > accept from any for local deliver to mbox
> >
> > You will have:
> > action "my_action" mbox
> > match from any for local action "my_action"
> 
> It may solve some obscure technical problem, but is a horrible thing to read 
> and write. How about keeping the best of both worlds? Leave the old beautiful 
> PF-like syntax to humans, and translate it into the newEgyptian(tm) on the 
> fly?

It doesn't solve "obscure" technical problems, it solves _many_ issues a
lot of users have reported ranging from syntax ambiguity to envelopes on
disk not reflecting changes in configuration. One-line rules have lot of
consequences which go far beyond the configuration phase: the structures
are impacted, the ruleset evaluation is impacted, the aliases expansions
are impacted, the queue is impacted, format of envelopes are impacted, I
could go on and on since this impacts almost the entire daemon actually.

The impact is not just cosmethic stuff. I removed _hundreds_ of lines of
very unnecessary and complex code that was ONLY there to make the design
error work. Some of these removals led to concrete security improvements
like .forward files, written by untrusted users, be processed with their
privileges rather than _smtpd. Not doable with one-line rules.

I could write pages about the shortcomings from the previous config, and
pages about why it can't be made to work and why the new config fixes it
in the proper way. We tried hard to find ways to retain a one-line rules
configuration but after months we exhausted the ideas and we have a much
clearer understanding that it's NOT doable. Either we accept that, or we
are just going to grow more complex and slowly stop writing code because
every time you touch an area there's a risk you run into the complexity.

You don't have to trust my word:

> How about keeping the best of both worlds? Leave the old beautiful PF-like 
> syntax to humans,
> and translate it into the newEgyptian(tm) on the fly?

If this was possible, then you could easily write a translator that will
convert old grammar to new one without removing all the benefits and not
reintroducing the complex code.

By all means, show me, I'd be impressed for real.

-- 
Gilles Chehade

https://www.poolp.org  @poolpOrg

Re: connect two midi devices

2018-05-25 Thread Alexandre Ratchov

On Fri, May 25, 2018 at 12:21:18AM +0200, Alexandre Ratchov wrote:
> 
> Maybe, but unlikely. If the device attaches, generally it works. Show
> what's received on midi2 when you type on the keyboard or do any other
> simple actions.
> 

fwiw, here's a small utility that I use very often to debug & connect
MIDI ports.

http://caoua.org/alex/obsd/midicat.tar.gz

To connect two rmidi/2 -> rmidi/1 and dump the data on stderr, run:

midicat -d -q rmidi/2 -q rmidi/1

Re: Autocompletion with pass in ksh

2018-05-25 Thread Niels Kobschaetzki


> On 6. May 2018, at 06:33, Niels Kobschaetzki  wrote:
> 
> Hi,
> 
> I learned yesterday of ksh's cusom auto completion. Now I try to figure
> out how to use it together with pass, but maybe someone already did the
> work.

I got a reply on twitter from Roman Zolltarif who wrote a blog post about it :)
https://www.romanzolotarev.com/pass.html#Completions%20in%20Korn%20shell

Niels


smime.p7s
Description: S/MIME cryptographic signature

37 matches

Mail list logo