v2.3.2 MDMessageCmd :: Mailsend is broken #198

SteffenAL · 2020-03-15T11:59:21Z

Have a messagecmd.bat file to send a mail, in contains:

@ECHO OFF
D:\servers\apache\bin\mailsend -q -f steffen@xxxxxx.com -smtp 127.0.0.1 -user xxxx@xxxxx.com -pass xxxxx  -name "SteffenAL" -t xxxxx@xxxx -sub "Lets Encrypt MDMessageCmd" -M "Something happened with a managed domain:" -M "%~1" -M "%~2"  -M "%~3" -M "%~4"  -M "."

with v2.2.7 and v2.3.1 all is working fine

With 2.3.2 no mail is sent and in the log:

[md:info] [pid 16032:tid 2268] cmd(D:/servers/apache/bin/MDMessageCmd.bat) stderr: Could not connect to 127.0.0.1:25\r\n
[md:info] [pid 16032:tid 2268] cmd(D:/servers/apache/bin/MDMessageCmd.bat) stderr: Error: Could not connect to SMTP server "127.0.0.1" at port 25\r\n

Running Windows.

The text was updated successfully, but these errors were encountered:

tlhackque · 2020-03-15T14:34:13Z

That's very strange.

The only change in that area is that a couple of environment variables are passed to your script: MD_STORE adn MD_VERSION

The error says that your script is being run, but is unable to connect to your mail server on 127.0.0.1.

Are you sure that the mail server is running when the error occurs?

It would be helpful to know what specific error mailsend is encountering.
A MDMessageCmd script is run with stderr logged, but stdout is not connected.

Does 1>&2 give log any more information? Does -v (instead of -q) - you'll want the redirect?

If you open a command window, does telnet 127.0.0.1 25 give you a banner?

Does that work from the account that httpd is running under?

Anything in your firewall logs?

I'll be back in a couple of hours...

SteffenAL · 2020-03-15T14:43:49Z

Mailserver is running, all is fine . When I switch back to 2.2.7 or 2.3.1 mail is sent.

with -v

[Sun Mar 15 13:19:29.792956 2020] [md:info] [pid 15476:tid 2268] cmd(D:/servers/apacheS/bin/MDMessageCmd.bat) stderr: > libmsock: using getaddrinfo\r\n
[Sun Mar 15 13:19:29.792956 2020] [md:info] [pid 15476:tid 2268] cmd(D:/servers/apacheS/bin/MDMessageCmd.bat) stderr: > AF_INET IPv4\r\n
[Sun Mar 15 13:19:29.792956 2020] [md:info] [pid 15476:tid 2268] cmd(D:/servers/apacheS/bin/MDMessageCmd.bat) stderr:  WSAAddressToString failed with 10106\r\n
[Sun Mar 15 13:19:29.792956 2020] [md:info] [pid 15476:tid 2268] cmd(D:/servers/apacheS/bin/MDMessageCmd.bat) stderr: > EINPROGRESS=10036,EWOULDBLOCK=10035\r\n
[Sun Mar 15 13:19:29.792956 2020] [md:info] [pid 15476:tid 2268] cmd(D:/servers/apacheS/bin/MDMessageCmd.bat) stderr: > connect(): socket=-1,rc=-1, errno=10038\r\n
[Sun Mar 15 13:19:29.792956 2020] [md:info] [pid 15476:tid 2268] cmd(D:/servers/apacheS/bin/MDMessageCmd.bat) stderr: Could not connect to 127.0.0.1:25\r\n
[Sun Mar 15 13:19:29.792956 2020] [md:info] [pid 15476:tid 2268] cmd(D:/servers/apacheS/bin/MDMessageCmd.bat) stderr: Error: Could not connect to SMTP server "127.0.0.1" at port 25\r\n
[

Bottom line is that it stops working with 2.3.2

tlhackque · 2020-03-15T17:09:28Z

Hmmm. mod_md is definitely starting your script.
The windows errors are helpful. 10106 means a provider failed to initialize.
I wonder if the change we made caused a change in the environment (especially PATH) that is causing this.

Can you add a set >&2 command to your batch job in both cases?

That would log the environment variables that the batch job see and show us if this is the case...

I'd do this, but I don't have a Windows environment with httpd...

SteffenAL · 2020-03-15T17:44:15Z

With 2.3.1, mail sent:

stderr: ALLUSERSPROFILE=C:\\ProgramData\r\n
stderr: APPDATA=C:\\Windows\\system32\\config\\systemprofile\\AppData\\Roaming\r\n
stderr: CommonProgramFiles=C:\\Program Files (x86)\\Common Files\r\n
stderr: CommonProgramFiles(x86)=C:\\Program Files (x86)\\Common Files\r\n
stderr: CommonProgramW6432=C:\\Program Files\\Common Files\r\n
stderr: COMPUTERNAME=FATHER\r\n
stderr: ComSpec=C:\\Windows\\system32\\cmd.exe\r\n
stderr: DriverData=C:\\Windows\\System32\\Drivers\\DriverData\r\n
stderr: LOCALAPPDATA=C:\\Windows\\system32\\config\\systemprofile\\AppData\\Local\r\n
stderr: NUMBER_OF_PROCESSORS=8\r\n
stderr: OS=Windows_NT\r\n
stderr: Path=C:\\Windows\\system32;C:\\Windows;D:\\programs\\perl\\bin;C:\\Windows\\System32\\Wbem;C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\;C:\\Program Files\\Dell\\SysMgt\\oma\
stderr: PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC;.PY;.PYW\r\n
stderr: PROCESSOR_ARCHITECTURE=x86\r\n
stderr: PROCESSOR_ARCHITEW6432=AMD64\r\n
stderr: PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 42 Stepping 7, GenuineIntel\r\n
stderr: PROCESSOR_LEVEL=6\r\n
stderr: PROCESSOR_REVISION=2a07\r\n
stderr: ProgramData=C:\\ProgramData\r\n
stderr: ProgramFiles=C:\\Program Files (x86)\r\n
stderr: ProgramFiles(x86)=C:\\Program Files (x86)\r\n
stderr: ProgramW6432=C:\\Program Files\r\n
stderr: PROMPT=$P$G\r\n
stderr: PSModulePath=C:\\Program Files\\WindowsPowerShell\\Modules;C:\\Windows\\system32\\WindowsPowerShell\\v1.0\\Modules\r\n
stderr: PUBLIC=C:\\Users\\Public\r\n
stderr: SystemDrive=C:\r\n
stderr: SystemRoot=C:\\Windows\r\n
stderr: TEMP=C:\\Windows\\TEMP\r\n
stderr: TMP=C:\\Windows\\TEMP\r\n
stderr: USERDOMAIN=MSHOME\r\n
stderr: USERNAME=FATHER$\r\n
stderr: USERPROFILE=C:\\Windows\\system32\\config\\systemprofile\r\n
stderr: windir=C:\\Windows\r\n

With 2.3.2 only these, no mail sent:

stderr: COMSPEC=C:\\Windows\\SysWOW64\\cmd.exe\r\n
stderr: MD_STORE=D:/servers/apacheS/md\r\n
stderr: MD_VERSION=2.3.2-git\r\n
stderr: PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.JS;.WS;.MSC\r\n
stderr: PROMPT=$P$G\r\n
stderr: Could not connect to 127.0.0.1:25\r\n
stderr: Error: Could not connect to SMTP server "127.0.0.1" at port 25\r\n

tlhackque · 2020-03-15T17:47:16Z

Thanks. That's what I suspected. Instead of adding the new variables to the environment, the change put ONLY those into the environment!

I didn't make that change (though I asked for it). I'll see if I can come up with a patch.

Thanks for the report and for your help.

tlhackque · 2020-03-15T19:36:35Z

You can try this (untested & ugly) patch.
It's probably not the final solution, but it should at least show the way.

diff --git a/src/md_util.c b/src/md_util.c
index d71ad36..545ec0d 100644
--- a/src/md_util.c
+++ b/src/md_util.c
@@ -16,8 +16,10 @@

 #include <assert.h>
 #include <stdio.h>
+#include <string.h>

 #include <apr_lib.h>
+#include <apr_env.h>
 #include <apr_strings.h>
 #include <apr_portable.h>
 #include <apr_file_info.h>
@@ -1015,7 +1017,6 @@ apr_status_t md_util_exec(apr_pool_t *p, const char *cmd, const char * const *ar
     apr_procattr_t *procattr;
     apr_proc_t *proc;
     apr_exit_why_e ewhy;
-    const char * const *envp = NULL;
     char buffer[1024];

     *exit_code = 0;
@@ -1023,17 +1024,27 @@ apr_status_t md_util_exec(apr_pool_t *p, const char *cmd, const char * const *ar
         return APR_ENOMEM;
     }
     if (env && env->nelts > 0) {
+        /* We want to inherit the current environment variables, adding/setting these.
+         * There's no portable way to do this only for the child, but it turns out
+         * that what we need to pass is harmless to keep in our environment.
+         * Do we need a mutex (the environment is not thread-safe)??
+         */
         apr_array_header_t *nenv;
-
+        char *np, *vp;
         nenv = apr_array_copy(p, env);
-        APR_ARRAY_PUSH(nenv, const char *) = NULL;
-        envp = (const char * const *)nenv->elts;
+
+        while ((np = apr_array_pop( nenv )) != NULL) {
+            if ((vp = strchr(np, '=')) != NULL) {
+                *vp++ = '\0';
+                (void) apr_env_set( np, vp, p );
+            }
+        }
     }
     if (   APR_SUCCESS == (rv = apr_procattr_create(&procattr, p))
         && APR_SUCCESS == (rv = apr_procattr_io_set(procattr, APR_NO_FILE,
                                                     APR_NO_PIPE, APR_FULL_BLOCK))
         && APR_SUCCESS == (rv = apr_procattr_cmdtype_set(procattr, APR_PROGRAM))
-        && APR_SUCCESS == (rv = apr_proc_create(proc, cmd, argv, envp, procattr, p))) {
+        && APR_SUCCESS == (rv = apr_proc_create(proc, cmd, argv, NULL, procattr, p))) {

         /* read stderr and log on INFO for possible fault analysis. */
         while(APR_SUCCESS == (rv = apr_file_gets(buffer, sizeof(buffer)-1, proc->err))) {
@@ -1043,7 +1054,7 @@ apr_status_t md_util_exec(apr_pool_t *p, const char *cmd, const char * const *ar
         apr_file_close(proc->err);

         if (APR_CHILD_DONE == (rv = apr_proc_wait(proc, exit_code, &ewhy, APR_WAIT))) {
-            /* let's not dwell on exit stati, but core should signal something's bad */
+            /* let's not dwell on exit status, but core should signal something's bad */
             if (*exit_code > 127 || APR_PROC_SIGNAL_CORE == ewhy) {
                 return APR_EINCOMPLETE;
             }

@icing

Adding the environment variables for MDMessageCmd and friends had the unintended side-effect of passing ONLY those variables (and a couple of others) to the child. This means no Path on Windows, among other things. icing#198 reported this issue. This patch should work - except that technically, the environment variables aren't thread-safe. The right thing is probably to add a mutex - but figuring out how APR spells that is for another day. @icing?

SteffenAL · 2020-03-17T09:06:26Z

Sending mail again now with the patch.

But no MOD_md env's :

stderr: ALLUSERSPROFILE=C:\\ProgramData\r\n
stderr: APPDATA=C:\\Windows\\system32\\config\\systemprofile\\AppData\\Roaming
stderr: CommonProgramFiles=C:\\Program Files (x86)\\Common Files\r\n
stderr: CommonProgramFiles(x86)=C:\\Program Files (x86)\\Common Files\r\n
stderr: CommonProgramW6432=C:\\Program Files\\Common Files\r\n
stderr: COMPUTERNAME=FATHER\r\n
stderr: ComSpec=C:\\Windows\\system32\\cmd.exe\r\n
stderr: DriverData=C:\\Windows\\System32\\Drivers\\DriverData\r\n
stderr: LOCALAPPDATA=C:\\Windows\\system32\\config\\systemprofile\\AppData\\Lo
stderr: NUMBER_OF_PROCESSORS=8\r\n
stderr: OS=Windows_NT\r\n
stderr: Path=C:\\Windows\\system32;C:\\Windows;D:\\programs\\perl\\bin;C:\\Win
stderr: PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC;.PY;.PYW
stderr: PROCESSOR_ARCHITECTURE=x86\r\n
stderr: PROCESSOR_ARCHITEW6432=AMD64\r\n
stderr: PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 42 Stepping 7, GenuineInte
stderr: PROCESSOR_LEVEL=6\r\n
stderr: PROCESSOR_REVISION=2a07\r\n
stderr: ProgramData=C:\\ProgramData\r\n
stderr: ProgramFiles=C:\\Program Files (x86)\r\n
stderr: ProgramFiles(x86)=C:\\Program Files (x86)\r\n
stderr: ProgramW6432=C:\\Program Files\r\n
stderr: PROMPT=$P$G\r\n
stderr: PSModulePath=C:\\Program Files\\WindowsPowerShell\\Modules;C:\\Windows
stderr: PUBLIC=C:\\Users\\Public\r\n
stderr: SystemDrive=C:\r\n
stderr: SystemRoot=C:\\Windows\r\n
stderr: TEMP=C:\\Windows\\TEMP\r\n
stderr: TMP=C:\\Windows\\TEMP\r\n
stderr: USERDOMAIN=MSHOME\r\n
stderr: USERNAME=FATHER$\r\n
stderr: USERPROFILE=C:\\Windows\\system32\\config\\systemprofile\r\n
stderr: windir=C:\\Windows\r\n
stderr: AP_PARENT_PID=13184\r\n

tlhackque · 2020-03-17T15:03:52Z

We're on the right track. I'm not surprised that it's only a partial fix - the whole environment area is very OS-dependent.

@icing has to make a call - there are only bad choices.

I looked at what mod_cgi and others do, and at how creating a process is done in the guts of httpd.

If a NULL environment pointer is passed into apr_proc_create, the parent's environment is copied - at least on POSIX systems. Windows is a little different
@icing's initial change was to pass a non-NULL pointer. This doesn't add to the child's environment variables - it becomes the complete list. The reason mail isn't sent is because PATH and friends are in the list.
What variables are needed is determined in a very OS-specific (lots of conditional code) part of ap_add_common_vars (in server/util_script.c), which other modules use to setup the base environment for a child process. They actually use ap_create_environment directy, which uses a table that is populated by ap_add_common_vars with all the system-dependent variables. The other modules add to the table, and It would be nice to use it. But for input, it requires a request record - which mod_md's working thread does not have.

ap_add_common_vars sets up more than we need - or want. It needs the request headers - or at least an empty table, since it's trying to setup the CGI gateway environment. And a connection (for the remote IP address). And the server (for the SERVER_NAME). And so on. So it would be a fair bit of work to create a "fake" request record for that purpose. And fragile.

Also note that copying the parent's environment table is not a great idea - but even if one wanted to, there is no portable way to list all the entries. (there's an extra argument to main(), a global environ variable, a Windows system call (in ASCII and Unicode variants), and some less common mechanisms. (Copying a variable by name, if you know the name, is quite portable - getenv(), and APR provides functions for get, set, and delete.

This leaves several unpleasant alternatives:

Copy the necessary conditional code from (mostly) ap_add_common_vars into mod_md - just what's needed to run a process. This is a maintenance issue. But would work.
Break out the code in ap_add_common_vars into a base & extended version. Easy to maintain but creates a dependency on the updated httpd for mod_md. Not desirable.
Pass the mod_md parameters some other way - perhaps on the command line or on stdin
Do (1) and (2) now, Backport (2) into current httpd. Then switch mod_md to (2) later.

These are all bad - just different flavors of bad.

Since I don't own mod_md, the decision isn't up to me....

SteffenAL · 2020-03-17T17:30:35Z

Did not tested mdnotifycmd. Same issue ?

Ps.
Why Env’s and not just passing the two as args.

tlhackque · 2020-03-17T18:21:35Z

Yes, same issue, common code.

Why Env’s and not just passing the two as args.

Funny you should ask :-)

This started when I wanted to add just one arg, and submitted a very small Pull request.
I said that even adding a few args was lower risk and less work than EnvVars.

I was overruled. And, to be fair, when it works, EnvVars are the more scalable solution.

The test suite was updated, and passed. It checked that in fact the new items
were delivered to the environment. Unfortunately, it didn't check that all the
old ones are still there. That's what you encountered.

I'm sorry for the difficulty that it caused you. Thanks again for your help with
the diagnosis.

This reverts commit 27098cc. It did restore the PATH variables that caused the issue reported in icing#198. However, it did not pass the new variables needed for the MDMessage/events work. It also (as noted in the commit) is unsafe.

icing · 2020-03-23T11:12:05Z

Interesting. Thanks for the summary! Now what to do...

tlhackque · 2020-03-23T12:39:02Z

It's a tough call, with no good choices. That's why you're the project leader, and I'm just the helper.

I'm willing to discuss further if it would help. Here, or off-line (my e-mail is in commits.)

icing · 2020-03-23T12:42:13Z

I still believe in the env thingie. I will make a change later, after I get the last merge working here.

tlhackque · 2020-03-23T13:01:13Z

I agree that setting up a workable env is the best place to end up. It's how to get there that has no good choices.

On the merge - it should just work. On the mod_ssl patch, it is based on the 2.4.41 mod_ssl with the client verification patch that you know about.

I'll be away for a bit, but back later. Let me know if I can do anything to make merges easier.

icing · 2020-03-23T14:08:25Z

@SteffenAL, could you check if v2.3.3 fixes the problem for you? Thanks!

SteffenAL · 2020-03-23T15:07:14Z

No.

In the .bat file the mail is now send. This is what is passed

stderr: MD_STORE=D:/servers/apacheS/md\r\n
stderr: MD_VERSION=2.3.3-git\r\n
stderr: PROMPT=$P$G\r\n
stderr: TMP=C:\\Windows\\TEMP\r\n
stderr: SystemRoot=C:\\Windows\r\n
stderr: COMSPEC=C:\\Windows\\system32\\cmd.exe\r\n
stderr: PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC;.PY;.PYW\r\n
stderr: WINDIR=C:\\Windows\r\n

But a Powershell call in the .bat is not executed:

powershell' is not recognized as an internal or external command,

Looks like the script needs more env's (it is missing a few). Powershell is nowadays mostly used)

Please pass all ?

icing · 2020-03-23T15:13:19Z

I would pass all, I just do not know how to iterate them.

SteffenAL · 2020-03-23T15:20:13Z

...how to iterate them.

Do not understand ? Because you can pass now 6.

icing · 2020-03-23T15:44:50Z

I can lookup a variable if I know the name. But I cannot get all names of existing variables on all operating systems in a common way.

SteffenAL · 2020-03-23T16:41:35Z

Thanks for explain.

Also the command Ping is not working:
ping' is not recognized as an internal or external command

I think we need all. otherwise I prognose that quit some scripts from our users are not working anymore.

tlhackque · 2020-03-23T17:04:52Z

I would pass all, I just do not know how to iterate them.

You can't. At least not portably. As I noted above, there are several mechanisms, and we can't catch them all. Further, they're not all necessarily desirable.

As I pointed out several replies back, the code that sets up for CGI has lots of OS-dependent conditionals to find the "important" variables. But it requires a request, which we don't have.

And we don't want to maintain a duplicate list.

I'm leaning toward choice 4 as the quickest fix in the short term, but longer term reducing the maintenance effort. It really ought to be common code - for loggers, etc.

There is a choice 5 that you might also try. Run the command in a shell - e.g. pass "sh -c properly-quoted command". Then the shell will setup the usual variables. It's not very efficient, but it might buy some time to get the core work done. There are also issues with shell escape characters - but since we can trust the admin who is setting up mod_md, that's probably an acceptable risk.

...

icing · 2020-03-24T08:54:19Z

After some more thought, i want to give up on using the environment. Even if we have a (shared) list of names, that doesn't preclude someone from introducing other important (to her) variables that are needed.

So, I think it is time to revert back to @tlhackque original idea of just passing one additional argument, but with a twist:

We add a MDEventCmdconfiguration on top of MDMessageCmd(then deprecated). That command gets called with the synopsis:

<MDEventCmd>  event mdomain [ param=value ... ]

With base as the first parameter specifying the md store directory. Unknown parameter should be ignored. Example:

my-event-cmd.sh renewed mydomain.com base=/etc/apache2/state/md

Does this work for everyone?

SteffenAL · 2020-03-24T09:41:46Z

No version arg ? Extra arg's no problem here.

MDNotifyCmd same as with 2.2.7 ?

Should work for me. MDEventCmd is a better name.

Just check that I understand :
MDMessageCmd D:/servers/apacheS/bin/Some.bat
Becomes:
MDEventCmd D:/servers/apacheS/bin/Some.bat

And MDMessageCmd no directive anymore ?

icing · 2020-03-24T09:45:31Z

We'll keep MDMessageCmd and it will be called the same way as before. Same for MDNotifyCmd. The extra parameters only get added for the new one.

If you want, we can add the parameter version as well.

SteffenAL · 2020-03-24T09:55:50Z

I the post above you said MDMessageCmd(then deprecated) , so I was understanding that is was replaced by MDEventCmd.

Version should be useful here. Special with testing I sometimes are mixed up when report an issue.

Now we get two almost the same (differ two exta args) two directives.
Why not just add the args to MDMessageCmd . No limit in Windows for using arg's.

tlhackque · 2020-03-24T09:57:33Z

I was afraid that's where we'd end up. But then, I've been through a lot of these problems :-(

That might work; effectively we are passing an environment of the form var=value (and the script/program can actually do something like:
event= shift; domain=shift; eval "$@".

It does limit us to the maximum line length of the shell - probably not too bad.

We do, however, already have more than one var - and problem to solve.

As noted (and in my code), "domain": is currently ambiguous. It's the certificate issuing domain for events like renew, but it's the DNS name to be updated for a DNS01 challenge - and that's a problem. I went to some trouble to get the issuing domain to DNS01 too.

It's very important to always have the cert domain - by that I mean the <MDDomain foo> value. That's how we can find out the right data - including the directory where the certs are stored. The DNS domain for a challenge is useless for that (but necessary to update the DNS.)

I really want one common argument format for all callouts to a script. And the cert issuing domain needs to always be there.

So, I suggest this:

The directive is MDEventCmd <optional-parameters> program_name
The program gets $0 = it's name, $1 ... $n = <optional-parameters> <the event name> <the cert domain> <event fixed params> <var=val...&gt

This allows the program to get it's options as currently. It ensures that the program ALWAYS knows what cert domain is the subject of the event.

It doesn't make sense to add names for things that we absolutely know that we need - e.g. for a DNS challenge, we need the DNS domain and token; for an HTTP-01 challenge we need the host, token-name and token contents. The program knows what to expect if it handles that event. All the var=val does for those is add complexity for the program - and consume command line space.

For the unexpected or useful to a more limited audience, like version and MDStoreDir, I like your idea of var=val.

icing · 2020-03-24T10:05:12Z

I think it is better and more clear to keep MDEventCmd and MDChallengeDns01 separate. The former is about events at an MDomain, the latter on how to answer challenges to a DNS domain.

It does not make sense to give the DNS names in events for me. Do you want 20 'renewed' and 'installed' events for a certificate with that many alt names?

If you want to use a single script, give it a first parameter 'event' or 'dns-01'.

tlhackque · 2020-03-24T10:06:19Z

I the post above you said MDMessageCmd(then deprecated) , so I was understanding that is was replaced by MDEventCmd.

Deprecated means "not prefered, but still works". Might be removed eventually. But people have time to adapt.

Version should be useful here. Special with testing I sometimes are mixed up when report an issue.
Yes, that's why it was the second thing I asked for!

Now we get two almost the same (differ two exta args) two directives.
Why not just add the args to MDMessageCmd . No limit in Windows for using arg's.

There is a limit - it's larger than it used to be. I think on the order of several KB.

The nice thing about @icing's proposal is that for things we don't think of now, the data is self-identifying. So a script written today can display or log without knowing what it is. Also, it's like having named parameters to a subroutine rather than counting arguments. I think it's a good idea.

My suggestion is a mixture - use fixed parameters where we know, from the event definition, what's required. Use named parameters for the helpful, "nice to have", and we don't know what we want today...

icing · 2020-03-24T10:07:35Z

If we end up with a lot of parameter, we can always add a env=filepath parameter where the more static things are kept togehter.

tlhackque · 2020-03-24T10:24:46Z

I think it is better and more clear to keep MDEventCmd and MDChallengeDns01 separate. The former is about events at an MDomain, the latter on how to answer challenges to a DNS domain.

It does not make sense to give the DNS names in events for me. Do you want 20 'renewed' and 'installed' events for a certificate with that many alt names?

If you want to use a single script, give it a first parameter 'event' or 'dns-01'.

I do want to handle everything in one script. There's a lot commonality.

Events are things that happen. They all need data about the certificate that triggered them.

And yes, if I have 20 names, I probably have at least 10 hosts (www.example.net & example.net); more if they're SMTP or other services. Remember that if they are remote, I need to know the names and push the certificates to the remote hosts. This is possible (for me common) for DNS challenges.

For http-01, it's the same situation, just a different way of installing the challenge.

If mod_md doesn't provide an event per target, the progam will have to find the certificate (or CSR), parse it (probably running openssl), and then work over the SANs. This seems unnecessary, since mod_md already has all this information parsed...

The way the md_events script now works is that it has a hierarchy of configuration:
global, per-certificate, per-host. So it can define a hander for logging and sending mail for expiration warnings. But have a per-host decision on whether the cert was magically installed by mod_md (the script does nothing), or needs to be pushed to a remote host.

If we end up with a lot of parameter, we can always add a env=filepath parameter where the more static things are kept togehter.

Effectively that's what I'm calling the cert domain (to distinguish from the dns challenge domain name).

I don't think we will end up with a lot of parameters coming directly from mod_md. We need the event name. We need the things that are intrinsic to the event. And we need enough environmental information to find out how to handle the event - which includes the targets. (Which can be hosts now; in the near future, IP addresses are coming; and some provider will deliver e-mail addresses - all these are SubjectAlternativeNames.) Finally, the optional args allows the script to get data from the admin - like "use this global configuration file - e.g. because that goes with customer a".

I suppose eventually we might want some information from the mod_md database - like next renewal. But that is available as json from the md-status handler....

Beyond those, information lives in configuration files or a database - mod_md doesn't really have it.

I've been working all night - it's now breakfast time here. Expect some delay on further response. ...

tlhackque · 2020-03-24T10:27:35Z

If you want to use a single script, give it a first parameter 'event' or 'dns-01'.

Oh, and for that, as a placeholder, I currently accept setup and teardown as meanng "for dns-01", and reserved setup-http-o1 and teardown-http-01 for for the corresponding http-01 events. That was to stay compatible with the current mechanisms.

tlhackque · 2020-03-24T16:09:31Z

This discussion ties in to a document that I committed back on 12-Mar -- event_interface_notes.txt.

I've updated it, the latest version is in my repo. It's a bit rough (I'm short on sleep), but I think worth reading.

Also note that contrib/md_events/md_events has a lot of documentation -- run it -h for an overview. If you use -I (or -i) to install it, the template config files have more details on how I want to use an event interface.... The latest version was merged to the project's master yesterday...

…NotifyCmd. This prevented the inheritance of existing environment variables as there seems to be no portable way to iterate those on all platforms. This led to a regression on Windows, see #198.

icing · 2021-01-11T15:01:03Z

@SteffenAL could you test the lastest 2.3.x release if the mail command is working again? I remove the meddling with the environment settings. Thanks!

SteffenAL · 2021-01-27T10:00:00Z

Oeps missed this one question.

v2.3.5-git: looks ok, get Installed, OCSP-renewed, expiring. But dealing with no renew, see #235

No MDNotifyCmd message seen and missing MDMessageCmd renewed

SteffenAL · 2021-06-03T17:56:53Z

In HTTPD 2.4.48 all my issues are solved. And with nice additions.

Thanks!

tlhackque mentioned this issue Mar 23, 2020

Latest md_events. Plumbing for MD_MDOMAIN #194

Merged

SteffenAL closed this as completed Jun 3, 2021

andreblanke mentioned this issue Aug 14, 2023

Environment variable inheritance using MDNotifyCmd and MDMessageCmd #319

Closed

v2.3.2 MDMessageCmd :: Mailsend is broken #198

v2.3.2 MDMessageCmd :: Mailsend is broken #198

Comments

SteffenAL commented Mar 15, 2020 • edited Loading

tlhackque commented Mar 15, 2020

SteffenAL commented Mar 15, 2020

tlhackque commented Mar 15, 2020

SteffenAL commented Mar 15, 2020 • edited Loading

tlhackque commented Mar 15, 2020

tlhackque commented Mar 15, 2020

SteffenAL commented Mar 17, 2020

tlhackque commented Mar 17, 2020

SteffenAL commented Mar 17, 2020

tlhackque commented Mar 17, 2020

icing commented Mar 23, 2020

tlhackque commented Mar 23, 2020

icing commented Mar 23, 2020

tlhackque commented Mar 23, 2020

icing commented Mar 23, 2020

SteffenAL commented Mar 23, 2020 • edited Loading

icing commented Mar 23, 2020

SteffenAL commented Mar 23, 2020 • edited Loading

icing commented Mar 23, 2020

SteffenAL commented Mar 23, 2020

tlhackque commented Mar 23, 2020

icing commented Mar 24, 2020

SteffenAL commented Mar 24, 2020

icing commented Mar 24, 2020

SteffenAL commented Mar 24, 2020

tlhackque commented Mar 24, 2020

icing commented Mar 24, 2020

tlhackque commented Mar 24, 2020

icing commented Mar 24, 2020

tlhackque commented Mar 24, 2020

tlhackque commented Mar 24, 2020

tlhackque commented Mar 24, 2020

icing commented Jan 11, 2021

SteffenAL commented Jan 27, 2021 • edited Loading

SteffenAL commented Jun 3, 2021

SteffenAL commented Mar 15, 2020 •

edited

Loading

SteffenAL commented Mar 15, 2020 •

edited

Loading

SteffenAL commented Mar 23, 2020 •

edited

Loading

SteffenAL commented Mar 23, 2020 •

edited

Loading

SteffenAL commented Jan 27, 2021 •

edited

Loading