Re: opensmtpd / ldap unreliable
On Thu, May 24, 2018 at 11:45:40AM -0700, Paul B. Henson wrote: > > From: Gilles Chehade > > Sent: Wednesday, May 23, 2018 1:20 PM > > > > That's bad but could easily be fixed if you want to help us > > So I dropped in the latest table-ldap from git, and it still failed > authentications after an LDAP server outage. It looks like the check is only > in the table_ldap_check function? I'm not sure what that's for, but it > doesn't seem to be called at all when doing authentication. I added a > similar check into the table_ldap_lookup function, and also had to reorder > the functions in the file a bit due to errors like this: > > table_ldap.c:92:15: warning: implicit declaration of function 'ldap_open' is > invalid in C99 > [-Wimplicit-function-declaration] > > Afterwards, opensmtpd successfully reconnected to LDAP and performed > authentication after an LDAP outage :). > > users[14726]: debug: table_ldap: ldap_query: > filter=(&(objectClass=uidObject)(uid=henson)), ret=0 > users[14726]: debug: table-ldap: reconnecting > users[14726]: info: table-ldap: closed previous connection > users[14726]: debug: ldap server accepted credentials > users[14726]: debug: table_ldap: ldap_query: > filter=(&(objectClass=uidObject)(uid=henson)), ret=1 > > > Here's what my changes currently are. I can submit a pull request on github > if you'd like. Thanks. > please do so we have more people able to test I'll review shortly > diff --git a/extras/tables/table-ldap/table_ldap.c > b/extras/tables/table-ldap/table_ldap.c > index 88c9ffd..9d20526 100644 > --- a/extras/tables/table-ldap/table_ldap.c > +++ b/extras/tables/table-ldap/table_ldap.c > @@ -74,45 +74,6 @@ table_ldap_update(void) > return 1; > } > > -static int > -table_ldap_check(int service, struct dict *params, const char *key) > -{ > - int ret; > - > - switch(service) { > - case K_ALIAS: > - case K_DOMAIN: > - case K_CREDENTIALS: > - case K_USERINFO: > - case K_MAILADDR: > - if ((ret = ldap_run_query(service, key, NULL, 0)) >= 0) { > - return ret; > - } > - log_debug("debug: table-ldap: reconnecting"); > - if (!(ret = ldap_open())) { > - log_warnx("warn: table-ldap: failed to connect"); > - } > - return ret; > - default: > - return -1; > - } > -} > - > -static int > -table_ldap_lookup(int service, struct dict *params, const char *key, char > *dst, size_t sz) > -{ > - switch(service) { > - case K_ALIAS: > - case K_DOMAIN: > - case K_CREDENTIALS: > - case K_USERINFO: > - case K_MAILADDR: > - return ldap_run_query(service, key, dst, sz); > - default: > - return -1; > - } > -} > - > static int > table_ldap_fetch(int service, struct dict *params, char *dst, size_t sz) > { > @@ -361,6 +322,32 @@ err: > return 0; > } > > +static int > +table_ldap_lookup(int service, struct dict *params, const char *key, char > *dst, size_t sz) > +{ > + int ret; > + > + switch(service) { > + case K_ALIAS: > + case K_DOMAIN: > + case K_CREDENTIALS: > + case K_USERINFO: > + case K_MAILADDR: > + if ((ret = ldap_run_query(service, key, dst, sz)) > 0) { > + return ret; > + } > + log_debug("debug: table-ldap: reconnecting"); > + if (!(ret = ldap_open())) { > + log_warnx("warn: table-ldap: failed to connect"); > + return ret; > + } > + return ldap_run_query(service, key, dst, sz); > + default: > + return -1; > + } > +} > + > + > static int > ldap_query(const char *filter, char **attributes, char ***outp, size_t n) > { > @@ -498,6 +485,31 @@ end: > return ret; > } > > +static int > +table_ldap_check(int service, struct dict *params, const char *key) > +{ > + int ret; > + > + switch(service) { > + case K_ALIAS: > + case K_DOMAIN: > + case K_CREDENTIALS: > + case K_USERINFO: > + case K_MAILADDR: > + if ((ret = ldap_run_query(service, key, NULL, 0)) >= 0) { > + return ret; > + } > + log_debug("debug: table-ldap: reconnecting"); > + if (!(ret = ldap_open())) { > + log_warnx("warn: table-ldap: failed to connect"); > + } > + return ret; > + default: > + return -1; > + } > +} > + > + > int > main(int argc, char **argv) > { > > -- Gilles Chehade https://www.poolp.org @poolpOrg
Re: Checking my new smtpd.conf syntax
On Fri, May 25, 2018 at 09:37:07PM +0200, Walter Alejandro Iglesias 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". > > 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?) > don't touch a knob if you don't KNOW that you absolutely need it. I know why some people would like to use a custom CA certificate instead of the one shipped with the system, I don't know why YOU should do it so if you are asking I can only guess you are going to break your setup. -- Gilles Chehade https://www.poolp.org @poolpOrg
Re: opensmtpd / ldap unreliable
Hello, Thanks for this patch! I'm setting up a similar configuration. I'll have a test also. Regards. Christophe Le 05/24/18 à 20:45, Paul B. Henson a écrit : From: Gilles Chehade Sent: Wednesday, May 23, 2018 1:20 PM That's bad but could easily be fixed if you want to help us So I dropped in the latest table-ldap from git, and it still failed authentications after an LDAP server outage. It looks like the check is only in the table_ldap_check function? I'm not sure what that's for, but it doesn't seem to be called at all when doing authentication. I added a similar check into the table_ldap_lookup function, and also had to reorder the functions in the file a bit due to errors like this: table_ldap.c:92:15: warning: implicit declaration of function 'ldap_open' is invalid in C99 [-Wimplicit-function-declaration] Afterwards, opensmtpd successfully reconnected to LDAP and performed authentication after an LDAP outage :). users[14726]: debug: table_ldap: ldap_query: filter=(&(objectClass=uidObject)(uid=henson)), ret=0 users[14726]: debug: table-ldap: reconnecting users[14726]: info: table-ldap: closed previous connection users[14726]: debug: ldap server accepted credentials users[14726]: debug: table_ldap: ldap_query: filter=(&(objectClass=uidObject)(uid=henson)), ret=1 Here's what my changes currently are. I can submit a pull request on github if you'd like. Thanks. diff --git a/extras/tables/table-ldap/table_ldap.c b/extras/tables/table-ldap/table_ldap.c index 88c9ffd..9d20526 100644 --- a/extras/tables/table-ldap/table_ldap.c +++ b/extras/tables/table-ldap/table_ldap.c @@ -74,45 +74,6 @@ table_ldap_update(void) return 1; } -static int -table_ldap_check(int service, struct dict *params, const char *key) -{ - int ret; - - switch(service) { - case K_ALIAS: - case K_DOMAIN: - case K_CREDENTIALS: - case K_USERINFO: - case K_MAILADDR: - if ((ret = ldap_run_query(service, key, NULL, 0)) >= 0) { - return ret; - } - log_debug("debug: table-ldap: reconnecting"); - if (!(ret = ldap_open())) { - log_warnx("warn: table-ldap: failed to connect"); - } - return ret; - default: - return -1; - } -} - -static int -table_ldap_lookup(int service, struct dict *params, const char *key, char *dst, size_t sz) -{ - switch(service) { - case K_ALIAS: - case K_DOMAIN: - case K_CREDENTIALS: - case K_USERINFO: - case K_MAILADDR: - return ldap_run_query(service, key, dst, sz); - default: - return -1; - } -} - static int table_ldap_fetch(int service, struct dict *params, char *dst, size_t sz) { @@ -361,6 +322,32 @@ err: return 0; } +static int +table_ldap_lookup(int service, struct dict *params, const char *key, char *dst, size_t sz) +{ + int ret; + + switch(service) { + case K_ALIAS: + case K_DOMAIN: + case K_CREDENTIALS: + case K_USERINFO: + case K_MAILADDR: + if ((ret = ldap_run_query(service, key, dst, sz)) > 0) { + return ret; + } + log_debug("debug: table-ldap: reconnecting"); + if (!(ret = ldap_open())) { + log_warnx("warn: table-ldap: failed to connect"); + return ret; + } + return ldap_run_query(service, key, dst, sz); + default: + return -1; + } +} + + static int ldap_query(const char *filter, char **attributes, char ***outp, size_t n) { @@ -498,6 +485,31 @@ end: return ret; } +static int +table_ldap_check(int service, struct dict *params, const char *key) +{ + int ret; + + switch(service) { + case K_ALIAS: + case K_DOMAIN: + case K_CREDENTIALS: + case K_USERINFO: + case K_MAILADDR: + if ((ret = ldap_run_query(service, key, NULL, 0)) >= 0) { + return ret; + } + log_debug("debug: table-ldap: reconnecting"); + if (!(ret = ldap_open())) { + log_warnx("warn: table-ldap: failed to connect"); + } + return ret; + default: + return -1; + } +} + + int main(int argc, char **argv) {
Re: Beg for Atheros wifi driver
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&apropos=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
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 >>> acme-client: acme-v01.api.letsenc
Re: connect two midi devices
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
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
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 exit: netpr
Re: acme-client new cert error
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 "/etc/acme/lets
Re: acme-client new cert error
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
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" } doma
Re: Viewport for man.openbsd.org -- readability on phones
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(&id_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(&id_unique, &slot); + while (cp != NULL) { + free(cp); + cp = ohash_next(&id_unique, &slot); + } + ohash_delete(&id_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(&id_unique, buf); + cp = ohash_find(&id_unique, slot); + if (cp != NULL) { + while (cp != NULL) { +
Re: connect two midi devices
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
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 { sec
Re: Checking my new smtpd.conf syntax
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
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) ?
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 ?
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.
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?
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) ?
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
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 ?
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
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