[doc] clarify usage of manager.json #9

New Issue

Ghost · 2019-11-03T01:46:17Z

Ghost commented

2019-11-03 01:46:17 +00:00

I'm having trouble figuring out how to migrate my koa/http2 app to greenlock-express@3. With 2.x I would use the following code:

const server = new Koa();

const gLock = greenlock.create({...});

const http2Server = http2.createSecureServer({
	...gLock.tlsOptions,
	allowHTTP1: true,
}, server.callback());

const acmeChallengeHandler = gLock.middleware(redirectHttps());
http.createServer(acmeChallengeHandler).listen(80, () => {
	console.log('Listening for ACME http-01 challenges on 80');
});

return http2Server.listen(443, (err: Error) => {
	if (err) throw err;
	console.log('Listening for http2 requests on 443');
});

I tried to migrate to 3.0 using the suggested code in the http2 example, like this:

const server = new Koa();

return greenlock.init(() => ({...})).serve((glx) => {
	const http2Server = glx.http2Server(server);

	http2Server.listen(443, '0.0.0.0', () => {
		console.info('Listening on ', http2Server.address());
	});

	const httpServer = glx.httpServer();
	httpServer.listen(80, '0.0.0.0', () => {
		console.info('Listening on ', httpServer.address());
	});
});

However, it doesn't work. I get the following error when running the app:

[DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
UnhandledPromiseRejectionWarning: Error [ERR_HTTP_HEADERS_SENT]: Cannot set headers after they are sent to the client
|     at ServerResponse.setHeader (_http_outgoing.js:455:11)
|     at respondWithGrace (/var/www/mysite/node_modules/@root/greenlock-express/http-middleware.js:61:9)
|     at /var/www/mysite/node_modules/@root/greenlock-express/http-middleware.js:34:24

Any tips or recommendations would be greatly appreciated.

I'm having trouble figuring out how to migrate my `koa`/`http2` app to `greenlock-express@3`. With 2.x I would use the following code: ```js const server = new Koa(); const gLock = greenlock.create({...}); const http2Server = http2.createSecureServer({ ...gLock.tlsOptions, allowHTTP1: true, }, server.callback()); const acmeChallengeHandler = gLock.middleware(redirectHttps()); http.createServer(acmeChallengeHandler).listen(80, () => { console.log('Listening for ACME http-01 challenges on 80'); }); return http2Server.listen(443, (err: Error) => { if (err) throw err; console.log('Listening for http2 requests on 443'); }); ``` I tried to migrate to 3.0 using the suggested code in the `http2` example, like this: ``` const server = new Koa(); return greenlock.init(() => ({...})).serve((glx) => { const http2Server = glx.http2Server(server); http2Server.listen(443, '0.0.0.0', () => { console.info('Listening on ', http2Server.address()); }); const httpServer = glx.httpServer(); httpServer.listen(80, '0.0.0.0', () => { console.info('Listening on ', httpServer.address()); }); }); ``` However, it doesn't work. I get the following error when running the app: ``` [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code. UnhandledPromiseRejectionWarning: Error [ERR_HTTP_HEADERS_SENT]: Cannot set headers after they are sent to the client | at ServerResponse.setHeader (_http_outgoing.js:455:11) | at respondWithGrace (/var/www/mysite/node_modules/@root/greenlock-express/http-middleware.js:61:9) | at /var/www/mysite/node_modules/@root/greenlock-express/http-middleware.js:34:24 ``` Any tips or recommendations would be greatly appreciated.

coolaj86 commented

2019-11-03 01:59:19 +00:00

Can you give me more description on what you mean by "doesn't work"?

Fails to issue certificates?
Fails to respond to http? https? http2?
Exits unexpectedly?

I've been seeing the "headers sent" warning myself and I'm interested to track it down, but it hasn't actually caused any problems that I'm aware of.

From when I've seen it I think it means that something in the http2 server stack has already sent headers or closed the connection before the "Not Found" callback fires in the ACME middleware.

Can you give me more description on what you mean by "doesn't work"? * Fails to issue certificates? * Fails to respond to http? https? http2? * Exits unexpectedly? I've been seeing the "headers sent" warning myself and I'm interested to track it down, but it hasn't actually caused any problems that I'm aware of. From when I've seen it I think it means that something in the http2 server stack has already sent headers or closed the connection before the "Not Found" callback fires in the ACME middleware.

coolaj86 commented

2019-11-03 02:03:28 +00:00

P.S. I'm finishing up the CLI tools right now so I can then go and finish up the docs.

Hit me up on Keybase (I'm @coolaj86) if you'd like to have some realtime Q&A to better help identify the bug or config issue.

P.S. I'm finishing up the CLI tools right now so I can then go and finish up the docs. Hit me up on Keybase (I'm @coolaj86) if you'd like to have some realtime Q&A to better help identify the bug or config issue.

Ghost commented

2019-11-03 02:18:46 +00:00

I'm not entirely sure but there's no exits. The server seems to run fine, and from what I can see the issuing of the certificate is okay, but the server is having issues responding. I see the following printed in stdout when the server starts:

  | 2019-11-03 02:14:14.373: ACME Directory URL: https://acme-v02.api.letsencrypt.org/directory
  | 2019-11-03 02:14:14.434: Greenlock Manager Config File: ~/.config/greenlock/manager.json
  | 2019-11-03 02:14:14.449: Listening on  { address: '0.0.0.0', family: 'IPv4', port: 443 }
  | 2019-11-03 02:14:14.450: Listening on  { address: '0.0.0.0', family: 'IPv4', port: 80 }

But when I try to navigate to my site via HTTPS, Chrome says:

This site can’t be reached. Unexpectedly closed the connection.

When I try to navigate via HTTP, Chrome says:

This site can’t provide a secure connection
Site uses an unsupported protocol.
ERR_SSL_VERSION_OR_CIPHER_MISMATCH

So seems like it's failing to respond to both https and http requests. Almost as if it's not actually routing requests to my koa app at all.

I'm not entirely sure but there's no exits. The server seems to run fine, and from what I can see the issuing of the certificate is okay, but the server is having issues responding. I see the following printed in `stdout` when the server starts: ``` | 2019-11-03 02:14:14.373: ACME Directory URL: https://acme-v02.api.letsencrypt.org/directory | 2019-11-03 02:14:14.434: Greenlock Manager Config File: ~/.config/greenlock/manager.json | 2019-11-03 02:14:14.449: Listening on { address: '0.0.0.0', family: 'IPv4', port: 443 } | 2019-11-03 02:14:14.450: Listening on { address: '0.0.0.0', family: 'IPv4', port: 80 } ``` But when I try to navigate to my site via HTTPS, Chrome says: ``` This site can’t be reached. Unexpectedly closed the connection. ``` When I try to navigate via HTTP, Chrome says: ``` This site can’t provide a secure connection Site uses an unsupported protocol. ERR_SSL_VERSION_OR_CIPHER_MISMATCH ``` So seems like it's failing to respond to both https and http requests. Almost as if it's not actually routing requests to my `koa` app at all.

coolaj86 commented

2019-11-03 02:41:15 +00:00

Would you mind trying a debug version I just published?

npm install @root/greenlock-express@next

Note that it's @next, not @latest.

Would you mind trying a debug version I just published? ``` npm install @root/greenlock-express@next ``` Note that it's **`@next`**, not `@latest`.

coolaj86 commented

2019-11-03 02:43:30 +00:00

P.S. I think your SSL problem is unrelated. That's probably because you forgot to edit ~/.config/greenlock/manager.json (or it was an error on my part in not making it clear in the documentation you were following).

P.S. I think your SSL problem is unrelated. That's probably because you forgot to edit `~/.config/greenlock/manager.json` (or it was an error on my part in not making it clear in the documentation you were following).

Ghost commented

2019-11-03 03:01:02 +00:00

Hmm, no luck with the @root/greenlock-express@next version. Same behavior as before and no new output in the console or logs. However, your comment regarding the config did lead to me discover that it's likely the issue.

On my webserver, I don't have control to write anything to ~/.config. I tried to inject the config values into greenlock.init() like this:

return greenlock.init((): {} => ({
	agreeToTerms: true,
	cluster: false,
	maintainerEmail: 'myemail@site.com',
	package: {name: pkg.name, version: pkg.version},
	sites: {
		'mydomain.com': {
			subject: 'mydomain.com',
			altnames: ['mydomain.com', 'www.mydomain.com'],
		},
	},
	subscriberEmail: 'myemail@site.com',
}))

But it doesn't seem like I can inject config values that way. Is there a way to pass those config values directly in my server code without using an external file?

P.S. Thanks so much for the fast responses (and on a Saturday!)

Hmm, no luck with the `@root/greenlock-express@next` version. Same behavior as before and no new output in the console or logs. However, your comment regarding the config did lead to me discover that it's likely the issue. On my webserver, I don't have control to write anything to `~/.config`. I tried to inject the config values into `greenlock.init()` like this: ```js return greenlock.init((): {} => ({ agreeToTerms: true, cluster: false, maintainerEmail: 'myemail@site.com', package: {name: pkg.name, version: pkg.version}, sites: { 'mydomain.com': { subject: 'mydomain.com', altnames: ['mydomain.com', 'www.mydomain.com'], }, }, subscriberEmail: 'myemail@site.com', })) ``` But it doesn't seem like I can inject config values that way. Is there a way to pass those config values directly in my server code without using an external file? P.S. Thanks so much for the fast responses (and on a Saturday!)

coolaj86 commented

2019-11-03 03:06:57 +00:00

With the CLI you'll be able to run something like this:

npx greenlock add --subject example.com --altnames 'example.com,*.example.com'

I'm thinking that adding the config to the code is a bad idea because it makes it difficult to debug when you're also using the CLI or the Web GUI.

For example, you can think you "deleted" something and not know why it keeps coming back.

I'd much rather make it easier to work with the config than against it. Do you have any suggestions for that?

I will release greenlock-store-cloud and greenlock-manager-cloud in the near future and make them usable from the default package. With those you'll have an api key and server id, and the config will sync as needed between cloud instances, dev machines, etc.

And you're welcome. :)

With the CLI you'll be able to run something like this: ```bash npx greenlock add --subject example.com --altnames 'example.com,*.example.com' ``` I'm thinking that adding the config to the code is a bad idea because it makes it difficult to debug when you're also using the CLI or the Web GUI. For example, you can think you "deleted" something and not know why it keeps coming back. I'd much rather make it easier to work _with_ the config than _against_ it. Do you have any suggestions for that? I will release `greenlock-store-cloud` and `greenlock-manager-cloud` in the near future and make them usable from the default package. With those you'll have an _api key_ and _server id_, and the config will sync as needed between cloud instances, dev machines, etc. And you're welcome. :)

coolaj86 changed title from ~~Trouble migrating to 3.0 when using koa and http2~~ to [doc] clarify usage of `manager.json`

2019-11-03 03:47:11 +00:00

Ghost commented

2019-11-04 03:03:10 +00:00

I see. I'm okay with that info living in a separate file. Is there a way to specify a different path for it other than ~/.config/greenlock/manager.json? I'd prefer to keep it right next to my site files.

I think to make the docs more clear, I would do something like:

In order to use greenlock-express you must create a configuration file on your server ~/.config/greenlock/manager.json prior to running your web server.

Add adding that to the v3 migration docs would help a lot. 👍

I see. I'm okay with that info living in a separate file. Is there a way to specify a different path for it other than `~/.config/greenlock/manager.json`? I'd prefer to keep it right next to my site files. I think to make the docs more clear, I would do something like: > In order to use `greenlock-express` you must create a configuration file on your server `~/.config/greenlock/manager.json` prior to running your web server. Add adding that to the v3 migration docs would help a lot. :+1:

coolaj86 commented

2019-11-04 05:50:04 +00:00

Yes, you absolutely can. I'm going to release v3.1 that has the CLI tool tomorrow, and will be forwards-compatible with greenlock-manager-cloud.

However, you can try it out today!

npm install 'git+https://git.coolaj86.com/coolaj86/greenlock.js.git#next'

npx greenlock init --manager greenlock-manager-fs --manager-config-file ./config/manager.json

One caveat (which is why this isn't officially released yet) is that configFile is relative to process.cwd(). Tomorrow I'm going to try a few cheap tricks to make it resolve relative to the package root instead.

However, assuming you're running npm start (or whatever) from the project directory - or if you use an absolute path - it's all good.

Yes, you absolutely can. I'm going to release v3.1 that has the CLI tool tomorrow, and will be forwards-compatible with `greenlock-manager-cloud`. However, you can try it out today! ```bash npm install 'git+https://git.coolaj86.com/coolaj86/greenlock.js.git#next' ``` ``` npx greenlock init --manager greenlock-manager-fs --manager-config-file ./config/manager.json ``` One caveat (which is why this isn't officially released yet) is that `configFile` is relative to `process.cwd()`. Tomorrow I'm going to try a few cheap tricks to make it resolve relative to the package root instead. However, assuming you're running `npm start` (or whatever) from the project directory - or if you use an absolute path - it's all good.

coolaj86 commented

2019-11-04 05:52:05 +00:00

typo fix:

npx greenlock init --manager greenlock-manager-fs --manager-config-file ./config/manager.json

typo fix: ``` npx greenlock init --manager greenlock-manager-fs --manager-config-file ./config/manager.json ```

coolaj86 commented

2019-11-05 11:08:06 +00:00

I've updated the Greenlock Express docs and published the latest version to npm. Let me know what you think.

Ghost commented

2019-11-05 12:01:10 +00:00

Same here :

I would like an easy way to use letsencrypt in a node server.

No CLI, no config file, no cloud.

Just a simple

greenlock({
	agreeToTerms: true,
	maintainerEmail: 'myemail@site.com',
	sites: {
		'mydomain.com': {
			subject: 'mydomain.com',
			altnames: ['mydomain.com', 'www.mydomain.com'],
		},
	},
	subscriberEmail: 'myemail@site.com',
}).serve(app)

For me that's the benefit of using an in process solution.
If I need to install a CLI, to create config files, ... I would use traeffik or other proxy

Sorry, but I would like to keep the simple case, simple... and I see greenlock-express more complicated every day since the last week where I tried to migrate.

Same here : I would like an easy way to use letsencrypt in a node server. No CLI, no config file, no cloud. Just a simple ``` greenlock({ agreeToTerms: true, maintainerEmail: 'myemail@site.com', sites: { 'mydomain.com': { subject: 'mydomain.com', altnames: ['mydomain.com', 'www.mydomain.com'], }, }, subscriberEmail: 'myemail@site.com', }).serve(app) ``` For me that's the benefit of using an in process solution. If I need to install a CLI, to create config files, ... I would use traeffik or other proxy Sorry, but I would like to keep the simple case, simple... and I see greenlock-express more complicated every day since the last week where I tried to migrate.

coolaj86 commented

2019-11-05 16:55:58 +00:00

@syvuilliot as much as it sucks for me to hear "You're doing it wrong!", I appreciate your feedback.

I'm trying to reduce the overall complexity of "you con figure it this way for this use case and that way for that use case" and make it simply: "You do it like this: 1, 2, 3, done".

What do you think about this?

npx greenlock init --maintainer-email 'myemail@site.com'
npx greenlock defaults --subscriber-email 'myemail@site.com' --agree-to-terms
npx greenlock add --subject 'mydomain.com' --altnames 'mydomain.com,www.mydomain.com'

Edit app.js to add express.

Run npm start -- --staging to test and npm start to go live

I could shorten that down to just:

npx greenlock init \
  --email 'myemail@site.com' \
  --agree-to-terms
npx greenlock add \
  --subject 'mydomain.com' \
  --altnames 'mydomain.com,www.mydomain.com'

Or is your issue more that you really dislike the CLI?

There's a good split between people that are only serving one domain, and need no configuration, and people who are serving many domains and need configuration.

My thought with the CLI is that it makes it easy in both cases.

If you're available for chat, I'd like to talk with you and understand how you use it. I'm really adverse to going back to "configuration in code" because it's been so problematic overall, and it doesn't scale well, but I can definitely be convinced.

@syvuilliot as much as it sucks for me to hear "You're doing it wrong!", I appreciate your feedback. I'm trying to reduce the overall complexity of "you con figure it this way for this use case and that way for that use case" and make it simply: "You do it like this: 1, 2, 3, done". What do you think about this? ```bash npx greenlock init --maintainer-email 'myemail@site.com' npx greenlock defaults --subscriber-email 'myemail@site.com' --agree-to-terms npx greenlock add --subject 'mydomain.com' --altnames 'mydomain.com,www.mydomain.com' ``` > Edit `app.js` to add express. > > Run `npm start -- --staging` to test and `npm start` to go live I could shorten that down to just: ```bash npx greenlock init \ --email 'myemail@site.com' \ --agree-to-terms npx greenlock add \ --subject 'mydomain.com' \ --altnames 'mydomain.com,www.mydomain.com' ``` Or is your issue more that you really dislike the CLI? There's a good split between people that are only serving one domain, and need no configuration, and people who are serving many domains and need configuration. My thought with the CLI is that it makes it easy in both cases. If you're available for chat, I'd like to talk with you and understand how you use it. I'm really adverse to going back to "configuration in code" because it's been so problematic overall, and it doesn't scale well, but I can definitely be convinced.

Ghost commented

2019-11-05 17:32:21 +00:00

@solderjs
I'm sorry for the way I answered and I really appreciate your support and the time you spend.
But the pain for me, is I though greenlock-express was aimed at doing this : wrapping a web server with SSL with minimum effort for a single domain.
And that's why I supported the project on indiegogo.

So I just wanted to be compliant with the new letsencrypt API.
And I'm discovering that I need an rc file, to install a cli, to execute commands, and perhaps to create an account on a cloud service... all I wanted to avoid !

So please, tell me what's the objective and the roadmap for greenlock-express, so I could figure if it fits my needs or not... and find an alternative quickly if not.

Thank you again... I know it's difficult to answer all use cases and I respect your decisions. And sorry for my english that's not as nuanced as I would like.

Regards

@solderjs I'm sorry for the way I answered and I really appreciate your support and the time you spend. But the pain for me, is I though greenlock-express was aimed at doing this : wrapping a web server with SSL with minimum effort for a single domain. And that's why I supported the project on indiegogo. So I just wanted to be compliant with the new letsencrypt API. And I'm discovering that I need an rc file, to install a cli, to execute commands, and perhaps to create an account on a cloud service... all I wanted to avoid ! So please, tell me what's the objective and the roadmap for greenlock-express, so I could figure if it fits my needs or not... and find an alternative quickly if not. Thank you again... I know it's difficult to answer all use cases and I respect your decisions. And sorry for my english that's not as nuanced as I would like. Regards

coolaj86 commented

2019-11-05 18:22:14 +00:00

@syvuilliot Your English is great and I 100% empathize with your frustration.

I'm here to serve

I'm completely sincere when I say that your feedback is valuable. I believe that you'll get exactly what you're expecting out of Greenlock - I just need to hear the frustration and see the examples.

The first feedback that I got on the feedback was "wow, this is awesome". Then I got a few people saying "ugh, this sucks". Hearing both and seeing examples, like what you gave above, helps me to see past what people say, and understand what they actually want.

You'll get your simple server, similar to what you describe above.

Call?

I'd really like to get on a call with you if possible. I'd like to be able to ask questions back and forth in real time because I believe that part of the frustration is due to misunderstanding that I've created and, for me, talking it out is the best way for me to learn how to simplify what I'm trying to communicate.

Could we get on Google hangouts? coolaj86@gmail.com

Q/A

I want to hear your feedback and suggestion on these points. It will help me to make the right decision for you, and everyone else.

I need an rc file

Here's the issue:

Different projects want the default place for things to be different:

local, relative to the project
in the home directory
some other explicit place

But...

require() is relative to __dirname
fs.readFile() is relative to process.cwd()

The idea behind .greenlockrc was to provide a bootstrap anchor point to say "hey, start over at this file in a deterministic location" or "go straight to the database".

However, in trying it out, I think that all I really need is { packageRoot: __dirname }.

to install a cli

I hate having to install CLIs, which is why I thought npx was such a cool option.
It's part of node.

So

npx greenlock init

is equivalent to

node node_modules/\@root/greenlock/bin/init.js

You don't have to install anything extra.

Is it that you don't want to use the CLI at all? Or that you were frustrating thinking that you had to install something extra?

What's the pain point?

My Goal / Roadmap

My goal with Greenlock Express is to make it the easiest option for self-hosting a node app.

I want it to be easy for people with just 1 domain, and people with 10,000 domains.

I believe that it's possible to offer both power and simplicity, I just got it wrong at first.

Again, with feedback like yours, I can see where my mistakes are and what I need to do better.

The optional cloud service

I've noticed that a ton of people want to be able to use Greenlock Express, but they don't like having local files.

I prefer to have everything local myself, but having the option to put in an API token and not have to worry about mounting volumes in Docker or setting up S3 or learning Postgres.

You won't need to use it. You can stick with the greenlock-manager-fs, greenlock-store-fs, and greenlock-challenge-standalone.

I just want to have something there for the people who struggle with basic linux-y things and want something that "Just Works" for their circumstance.

@syvuilliot Your English is great and I 100% empathize with your frustration. ### I'm here to serve I'm completely sincere when I say that your feedback is valuable. I believe that you'll get exactly what you're expecting out of Greenlock - I just need to hear the frustration and see the examples. The first feedback that I got on the feedback was "wow, this is awesome". Then I got a few people saying "ugh, this sucks". Hearing both and seeing examples, like what you gave above, helps me to see past what people say, and understand what they actually want. You'll get your simple server, similar to what you describe above. ### Call? I'd really like to get on a call with you if possible. I'd like to be able to ask questions back and forth in real time because I believe that part of the frustration is due to misunderstanding that I've created and, for me, talking it out is the best way for me to learn how to simplify what I'm trying to communicate. Could we get on Google hangouts? coolaj86@gmail.com ### Q/A I want to hear your feedback and suggestion on these points. It will help me to make the right decision for you, and everyone else. > I need an rc file Here's the issue: Different projects want the default place for things to be different: * local, relative to the project * in the home directory * some other explicit place But... * `require()` is relative to `__dirname` * `fs.readFile()` is relative to `process.cwd()` The idea behind `.greenlockrc` was to provide a bootstrap anchor point to say "hey, start over at this file in a deterministic location" or "go straight to the database". However, in trying it out, I think that all I really need is `{ packageRoot: __dirname }`. > to install a cli I hate having to install CLIs, which is why I thought `npx` was such a cool option. It's part of node. So ``` npx greenlock init ``` is equivalent to ``` node node_modules/\@root/greenlock/bin/init.js ``` You don't have to install anything extra. Is it that you don't want to use the CLI at all? Or that you were frustrating thinking that you had to install something extra? What's the pain point? ### My Goal / Roadmap My goal with Greenlock Express is to make it the easiest option for self-hosting a node app. I want it to be easy for people with just 1 domain, and people with 10,000 domains. I believe that it's possible to offer both power and simplicity, I just got it wrong at first. Again, with feedback like yours, I can see where my mistakes are and what I need to do better. ### The optional cloud service I've noticed that a ton of people want to be able to use Greenlock Express, but they don't like having local files. I prefer to have everything local myself, but having the option to put in an API token and not have to worry about mounting volumes in Docker or setting up S3 or learning Postgres. You won't need to use it. You can stick with the `greenlock-manager-fs`, `greenlock-store-fs`, and `greenlock-challenge-standalone`. I just want to have something there for the people who struggle with basic linux-y things and want something that "Just Works" for their circumstance.

coolaj86 commented

2019-11-05 18:59:07 +00:00

P.S. bd5ee84e25

What do you think about this?

require('greenlock-express').init({
    maintainerEmail: 'jon@example.com',
    packageRoot: __dirname
}).serve(app)

./greenlock.json

{
  "sites": [
    {
      "subject": "mydomain.com",
      "altnames": [ "mydomain.com", "www.mydomain.com"]
    }
  ]
}

P.S. https://git.rootprojects.org/root/greenlock-express.js/commit/bd5ee84e258a2ca4c66e22873ee9c5fff9aab0c7 What do you think about this? ```js require('greenlock-express').init({ maintainerEmail: 'jon@example.com', packageRoot: __dirname }).serve(app) ``` `./greenlock.json` ```json { "sites": [ { "subject": "mydomain.com", "altnames": [ "mydomain.com", "www.mydomain.com"] } ] } ```

Ghost commented

2019-11-06 12:49:30 +00:00

Thank you so much for your time, that I don't want to abuse.

After some reflexion on my side, and if it can help, I give you my remarks below.

I see my SSL config as a stateless and idempotent process: when a request occurs, retrieve a certificate according to the config or trigger a renew if necessary, and serve the request.
The config is not dynamic, I don't need to add or remove or change the config at runtime.

So I could provide the config as a file in a well known path on the file system, but I think it could be even easier to register a callback that provide this config because I can even skip the file generation, and the subtleties of finding the place to put it (but I recognize that's not a big deal, nonetheless, it's quite a gap from the users coming from v2)

Considering the usage of a cli, it is not about installing the cli by itself or using npx (even if I think that npx is effectively easier), it is about having to add steps to my deployment process and to learn a new API that can evolve in the future. Not a big deal again, but things that don't go toward simplicity (in my opinion).

Even in this case of a simple non dynamic config, I know that greenlock needs to store, not only the certificates but also, some data related to their management (renewAt, email, ...)
And in line with what you've done for the default strategy to store the certificates on the file system, you could also use a default strategy to store the management data on the file system at a default path that I don't really care.

Can the problem be that the config file become the storage for data management ? Or do I miss something ?

In conclusion, I think I better understand your intentions with the file config and the cli to manage it. And I will adapt to it.
Thank you again for your suggestion and your support.
Regarding your suggestion for a call, I prefer to decline it since I'm not that comfortable in english and prefer to exchange by writing.

Thank you so much for your time, that I don't want to abuse. After some reflexion on my side, and if it can help, I give you my remarks below. I see my SSL config as a stateless and idempotent process: when a request occurs, retrieve a certificate according to the config or trigger a renew if necessary, and serve the request. The config is not dynamic, I don't need to add or remove or change the config at runtime. So I could provide the config as a file in a well known path on the file system, but I think it could be even easier to register a callback that provide this config because I can even skip the file generation, and the subtleties of finding the place to put it (but I recognize that's not a big deal, nonetheless, it's quite a gap from the users coming from v2) Considering the usage of a cli, it is not about installing the cli by itself or using npx (even if I think that npx is effectively easier), it is about having to add steps to my deployment process and to learn a new API that can evolve in the future. Not a big deal again, but things that don't go toward simplicity (in my opinion). Even in this case of a simple non dynamic config, I know that greenlock needs to store, not only the certificates but also, some data related to their management (renewAt, email, ...) And in line with what you've done for the default strategy to store the certificates on the file system, you could also use a default strategy to store the management data on the file system at a default path that I don't really care. Can the problem be that the config file become the storage for data management ? Or do I miss something ? In conclusion, I think I better understand your intentions with the file config and the cli to manage it. And I will adapt to it. Thank you again for your suggestion and your support. Regarding your suggestion for a call, I prefer to decline it since I'm not that comfortable in english and prefer to exchange by writing.

Ghost commented

2019-11-10 23:08:53 +00:00

Still having a few issues.

I tried adding a .greenlockrc to the root of my project that contains all the configuration values, and I specified the packageRoot: __dirname in the init() call but it doesn't seem like greenlock-express is using it. It's still auto generating a file in ~/.config/greenlock/manager.json and returning the following error when the server starts:

2019-11-10 23:04:07.004: warning: No sites available. Did you add them?
2019-11-10 23:04:07.005:          npx greenlock add --subject example.com --altnames example.com

Any recommendations on how I can debug this?

I'm hoping to avoid having to run any CLI commands on the server so that everything can be handled declaratively either via configuration file(s) or in code.

Still having a few issues. I tried adding a `.greenlockrc` to the root of my project that contains all the configuration values, and I specified the `packageRoot: __dirname` in the `init()` call but it doesn't seem like `greenlock-express` is using it. It's still auto generating a file in `~/.config/greenlock/manager.json` and returning the following error when the server starts: ``` 2019-11-10 23:04:07.004: warning: No sites available. Did you add them? 2019-11-10 23:04:07.005: npx greenlock add --subject example.com --altnames example.com ``` Any recommendations on how I can debug this? I'm hoping to avoid having to run any CLI commands on the server so that everything can be handled declaratively either via configuration file(s) or in code.

coolaj86 commented

2019-11-12 16:10:58 +00:00

All the CLI does is call the manager to edit the config file.

So just do as it says right in the message, and check the change it makes to the config file.

The CLI doesn’t replace the declarative config files - rather it’s a shortcut to build them in a predictable way so that there’s no possibility for error.

I had to take a break to fully focus on client work, and let all the feedback seep in, and I’ll be back to completing the documentation this week.

All the CLI does is call the manager to edit the config file. So just do as it says right in the message, and check the change it makes to the config file. The CLI doesn’t replace the declarative config files - rather it’s a shortcut to build them in a predictable way so that there’s no possibility for error. I had to take a break to fully focus on client work, and let all the feedback seep in, and I’ll be back to completing the documentation this week.

Sign in to join this conversation.

No Label

No Milestone

No Assignees

2 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: root/greenlock-express.js#9

[doc] clarify usage of manager.json #9

I'm here to serve

Call?

Q/A

My Goal / Roadmap

The optional cloud service

[doc] clarify usage of `manager.json` #9