* certbot service experience
@ 2017-04-29 21:33 Christopher Allan Webber
2017-04-30 2:15 ` Chris Marusich
2017-05-02 7:47 ` Andy Wingo
0 siblings, 2 replies; 6+ messages in thread
From: Christopher Allan Webber @ 2017-04-29 21:33 UTC (permalink / raw)
To: Guix-devel, Andy Wingo; +Cc: 26685
I'm crossposting this to guix-devel, even though it's in reply to
guix-patches bug #26685 adding the cerbot service, because I think it's
more about my experiences with workflow and less about what might affect
that specific bug. (If you reply on guix-devel, maybe remove the
debbugs address.)
Andy Wingo writes:
> Attached patch adds a certbot service extending nginx. Only question
> is, how to ensure that nginx is runing when the certbot activation runs?
> In practice I bet this races so it's not a big issue but if there's a
> way to require nginx before activation, that would be nice.
So I got a server up and running using certbot and this. Yay! It went
pretty well, and I'm happy about it now that it's running, though I did
run into some bumps (which is okay, I ran into bumps doing this on
Debian too, I just think now's a good time to reflect on the experience
and see if we can do anything better... plus maybe it's useful to
explore for someone else too). I figured I'd document what the process
was like for me. Here's my observations:
- I was surprised that I was prompted for an email while doing guix
system reconfigure (and in being asked if I was willing to supply
that info to the EFF so they can put me on their mailing lists, which
I'm not against but was surprising to encounter in a reconfigure).
IIRC this is the first time anything like that has happened. I
generally anticipate such a reconfigure to be "prompt-less".
I wonder if there should be an email field we can provide, so that it
doesn't do this prompt? Granted, it's for the first time run only.
Maybe it's okay to do things as they are, but we should document it?
I dunno?
- Not specifically something to do with this package, but nginx wasn't
coming up at a few points (btw, default nginx configuration won't
work, because it points at certificate filepaths that we don't
"automatically" put in place). When nginx doesn't come up, there's
pretty much no information as to why; nothing in the shepherd logs,
nothing useful from shepherd itself ("shepherd: Service nginx could
not be started."), and nothing in the nginx logs either.
- Getting the certbot stuff to work basically involved three stages:
1) Enable nginx without cert certbot, and point the root somewhere
which will be the same place you'll set certbot-configuration's
webroot at in the next step. This looks something like the
following:
(service nginx-service-type
(nginx-configuration
(server-blocks
(list
(nginx-server-configuration
;; Replace these with your own domain and web root
(server-name '("test.activitypub.rocks"))
(root "/srv/activitypub.rocks/site/")
;; Note that you have to disable https and any certificates
;; esp because our nginx config defaults to pointing at keys
;; that probably aren't there. Without doing this nginx
;; will die mysteriously.
(https-port #f)
(ssl-certificate #f)
(ssl-certificate-key #f))))))
(You can maybe do this in the same phase as the next step but
there's a risk of a race condition I think.)
Anyway now do "guix system reconfigure" and nginx should come up
and serve your stuff *without* https.
2) Enable the certbot-service-type (and mcron-service-type if you
haven't already):
(service certbot-service-type
(certbot-configuration
;; Replace these with your own domain and web root
(hosts '("test.activitypub.rocks"))
(webroot "/srv/activitypub.rocks/site/")))
;; if you don't have an mcron service already
(service mcron-service-type)
Okay, with those added, run "guix system reconfigure" again.
You'll be prompted for your email address and about whether or not
you want to join the EFF mailing lists, so watch for that.
3) Okay hopefully that went successfully! It should say. Assuming it
did, *now* we can add the keys appropriately to the nginx config.
(service nginx-service-type
(nginx-configuration
(server-blocks
(list
(nginx-server-configuration
;; Again, adjust to your site
(server-name '("test.activitypub.rocks"))
(root "/srv/activitypub.rocks/site/")
(ssl-certificate
"/etc/letsencrypt/live/test.activitypub.rocks/fullchain.pem")
(ssl-certificate-key
"/etc/letsencrypt/live/test.activitypub.rocks/privkey.pem"))))))
Reconfigure and cross your fingers!
4) At this point I was surprised that it seemed like nginx should have
been working with https since everything was in place, but I
couldn't access it from my browser over https. Frustrated, I
restarted the server.
And then it worked! :)
So, this involved reconfiguring, reconfiguring, reconfiguring, and then
a restart, then it worked for me. (Well, plus a few reconfigures where
nothing worked at all because I broke things of course. ;)) I wonder if
that can be improved?
That said, it's still really exciting to be able to describe these
things declaratively, and to have Guix take care of keeping things
renewed for me. :) Excited to have this landing, and to be that much
closer to doing server deployment with GuixSD!
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: certbot service experience
2017-04-29 21:33 certbot service experience Christopher Allan Webber
@ 2017-04-30 2:15 ` Chris Marusich
2017-04-30 2:35 ` Christopher Allan Webber
2017-05-02 7:47 ` Andy Wingo
1 sibling, 1 reply; 6+ messages in thread
From: Chris Marusich @ 2017-04-30 2:15 UTC (permalink / raw)
To: Christopher Allan Webber; +Cc: Guix-devel, 26685
[-- Attachment #1: Type: text/plain, Size: 2981 bytes --]
Christopher Allan Webber <cwebber@dustycloud.org> writes:
> - I was surprised that I was prompted for an email while doing guix
> system reconfigure
That does seem odd. Why were you prompted for an email address? Can
that be fixed somehow?
> 2) Enable the certbot-service-type (and mcron-service-type if you
> haven't already):
>
> (service certbot-service-type
> (certbot-configuration
> ;; Replace these with your own domain and web root
> (hosts '("test.activitypub.rocks"))
> (webroot "/srv/activitypub.rocks/site/")))
> ;; if you don't have an mcron service already
> (service mcron-service-type)
Where is the certbot-service-type defined? I couldn't find it in the
master branch. Also, why is mcron required? I don't know much about
LetsEncrypt, but I thought certbot was a one-time thing that you do
manually... Why is it a "service" here?
> 3) Okay hopefully that went successfully! It should say. Assuming it
> did, *now* we can add the keys appropriately to the nginx config.
>
> (service nginx-service-type
> (nginx-configuration
> (server-blocks
> (list
> (nginx-server-configuration
> ;; Again, adjust to your site
> (server-name '("test.activitypub.rocks"))
> (root "/srv/activitypub.rocks/site/")
> (ssl-certificate
> "/etc/letsencrypt/live/test.activitypub.rocks/fullchain.pem")
> (ssl-certificate-key
> "/etc/letsencrypt/live/test.activitypub.rocks/privkey.pem"))))))
>
> Reconfigure and cross your fingers!
>
> 4) At this point I was surprised that it seemed like nginx should have
> been working with https since everything was in place, but I
> couldn't access it from my browser over https. Frustrated, I
> restarted the server.
>
> And then it worked! :)
>
> So, this involved reconfiguring, reconfiguring, reconfiguring, and then
> a restart, then it worked for me. (Well, plus a few reconfigures where
> nothing worked at all because I broke things of course. ;)) I wonder if
> that can be improved?
I wonder if it is possible to define a custom service which orchestrates
the execution of nginx and certbot in the way you require, so that you
can define it all in one place, at once, without needing to reconfigure
multiple times?
> That said, it's still really exciting to be able to describe these
> things declaratively, and to have Guix take care of keeping things
> renewed for me. :) Excited to have this landing, and to be that much
> closer to doing server deployment with GuixSD!
Pretty cool! Thanks for sharing your experience. It's always neat to
read about how people are using the system.
--
Chris
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: certbot service experience
2017-04-30 2:15 ` Chris Marusich
@ 2017-04-30 2:35 ` Christopher Allan Webber
2017-04-30 3:00 ` Chris Marusich
0 siblings, 1 reply; 6+ messages in thread
From: Christopher Allan Webber @ 2017-04-30 2:35 UTC (permalink / raw)
To: Chris Marusich; +Cc: Guix-devel
[-bug]
Chris Marusich writes:
> Christopher Allan Webber <cwebber@dustycloud.org> writes:
>
>> - I was surprised that I was prompted for an email while doing guix
>> system reconfigure
>
> That does seem odd. Why were you prompted for an email address? Can
> that be fixed somehow?
It's the certbot initial-setup script firing off here. The email
address is given so you can be notified for security updates, etc.
Maybe recovery? Don't remember about that last bit.
>> 2) Enable the certbot-service-type (and mcron-service-type if you
>> haven't already):
>>
>> (service certbot-service-type
>> (certbot-configuration
>> ;; Replace these with your own domain and web root
>> (hosts '("test.activitypub.rocks"))
>> (webroot "/srv/activitypub.rocks/site/")))
>> ;; if you don't have an mcron service already
>> (service mcron-service-type)
>
> Where is the certbot-service-type defined? I couldn't find it in the
> master branch. Also, why is mcron required? I don't know much about
> LetsEncrypt, but I thought certbot was a one-time thing that you do
> manually... Why is it a "service" here?
It's not in the master branch is why. I was looking at the
wip-git-https branch. :) I think it's also in the wip-potluck branch.
It's extending the mcron service so it can install an auto-update rule
for you, which is pretty cool!
>> 3) Okay hopefully that went successfully! It should say. Assuming it
>> did, *now* we can add the keys appropriately to the nginx config.
>>
>> (service nginx-service-type
>> (nginx-configuration
>> (server-blocks
>> (list
>> (nginx-server-configuration
>> ;; Again, adjust to your site
>> (server-name '("test.activitypub.rocks"))
>> (root "/srv/activitypub.rocks/site/")
>> (ssl-certificate
>> "/etc/letsencrypt/live/test.activitypub.rocks/fullchain.pem")
>> (ssl-certificate-key
>> "/etc/letsencrypt/live/test.activitypub.rocks/privkey.pem"))))))
>>
>> Reconfigure and cross your fingers!
>>
>> 4) At this point I was surprised that it seemed like nginx should have
>> been working with https since everything was in place, but I
>> couldn't access it from my browser over https. Frustrated, I
>> restarted the server.
>>
>> And then it worked! :)
>>
>> So, this involved reconfiguring, reconfiguring, reconfiguring, and then
>> a restart, then it worked for me. (Well, plus a few reconfigures where
>> nothing worked at all because I broke things of course. ;)) I wonder if
>> that can be improved?
>
> I wonder if it is possible to define a custom service which orchestrates
> the execution of nginx and certbot in the way you require, so that you
> can define it all in one place, at once, without needing to reconfigure
> multiple times?
It might be, I dunno! Maybe in starting the service, if it sees that
the keys have not been generated yet, it pulls up nginx temporarily just
to do the registration with the nginx that doesn't have the keys in it,
does the generation of the keys and verifies them with letsencrypt, then
pulls up the proper nginx at last.
I don't know how easy/feasible this is.
>> That said, it's still really exciting to be able to describe these
>> things declaratively, and to have Guix take care of keeping things
>> renewed for me. :) Excited to have this landing, and to be that much
>> closer to doing server deployment with GuixSD!
>
> Pretty cool! Thanks for sharing your experience. It's always neat to
> read about how people are using the system.
Yeah! I'm excited to finally move to hosting my servers with GuixSD at
last, after ages of talking about it. ;)
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: certbot service experience
2017-04-30 2:35 ` Christopher Allan Webber
@ 2017-04-30 3:00 ` Chris Marusich
0 siblings, 0 replies; 6+ messages in thread
From: Chris Marusich @ 2017-04-30 3:00 UTC (permalink / raw)
To: Christopher Allan Webber; +Cc: Guix-devel
[-- Attachment #1: Type: text/plain, Size: 4460 bytes --]
Christopher Allan Webber <cwebber@dustycloud.org> writes:
> [-bug]
>
> Chris Marusich writes:
>
>> Christopher Allan Webber <cwebber@dustycloud.org> writes:
>>
>>> - I was surprised that I was prompted for an email while doing guix
>>> system reconfigure
>>
>> That does seem odd. Why were you prompted for an email address? Can
>> that be fixed somehow?
>
> It's the certbot initial-setup script firing off here. The email
> address is given so you can be notified for security updates, etc.
> Maybe recovery? Don't remember about that last bit.
I see. Having never used certbot before myself, I don't think I can
really give useful advice here. It just seems a little strange to
require user interaction during the reconfigure. One would think that
one could provide any necessary information declaratively in the
operating system configuration file.
>
>>> 2) Enable the certbot-service-type (and mcron-service-type if you
>>> haven't already):
>>>
>>> (service certbot-service-type
>>> (certbot-configuration
>>> ;; Replace these with your own domain and web root
>>> (hosts '("test.activitypub.rocks"))
>>> (webroot "/srv/activitypub.rocks/site/")))
>>> ;; if you don't have an mcron service already
>>> (service mcron-service-type)
>>
>> Where is the certbot-service-type defined? I couldn't find it in the
>> master branch. Also, why is mcron required? I don't know much about
>> LetsEncrypt, but I thought certbot was a one-time thing that you do
>> manually... Why is it a "service" here?
>
> It's not in the master branch is why. I was looking at the
> wip-git-https branch. :) I think it's also in the wip-potluck branch.
>
That explains it! :)
>
> It's extending the mcron service so it can install an auto-update rule
> for you, which is pretty cool!
I see. I would have thought that if service A extends service B, and
one defines service A in the operating system configuration file,
service B gets pulled in automatically. Is that not true?
>>> 3) Okay hopefully that went successfully! It should say. Assuming it
>>> did, *now* we can add the keys appropriately to the nginx config.
>>>
>>> (service nginx-service-type
>>> (nginx-configuration
>>> (server-blocks
>>> (list
>>> (nginx-server-configuration
>>> ;; Again, adjust to your site
>>> (server-name '("test.activitypub.rocks"))
>>> (root "/srv/activitypub.rocks/site/")
>>> (ssl-certificate
>>> "/etc/letsencrypt/live/test.activitypub.rocks/fullchain.pem")
>>> (ssl-certificate-key
>>> "/etc/letsencrypt/live/test.activitypub.rocks/privkey.pem"))))))
>>>
>>> Reconfigure and cross your fingers!
>>>
>>> 4) At this point I was surprised that it seemed like nginx should have
>>> been working with https since everything was in place, but I
>>> couldn't access it from my browser over https. Frustrated, I
>>> restarted the server.
>>>
>>> And then it worked! :)
>>>
>>> So, this involved reconfiguring, reconfiguring, reconfiguring, and then
>>> a restart, then it worked for me. (Well, plus a few reconfigures where
>>> nothing worked at all because I broke things of course. ;)) I wonder if
>>> that can be improved?
>>
>> I wonder if it is possible to define a custom service which orchestrates
>> the execution of nginx and certbot in the way you require, so that you
>> can define it all in one place, at once, without needing to reconfigure
>> multiple times?
>
> It might be, I dunno! Maybe in starting the service, if it sees that
> the keys have not been generated yet, it pulls up nginx temporarily just
> to do the registration with the nginx that doesn't have the keys in it,
> does the generation of the keys and verifies them with letsencrypt, then
> pulls up the proper nginx at last.
>
> I don't know how easy/feasible this is.
It would be nice if we could just declare what we want in the operating
system configuration file, and get it without having to run multiple
reconfigures or interact with the user. But hey, anything that works is
a step in the right direction!
--
Chris
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: certbot service experience
2017-04-29 21:33 certbot service experience Christopher Allan Webber
2017-04-30 2:15 ` Chris Marusich
@ 2017-05-02 7:47 ` Andy Wingo
2017-05-03 0:07 ` Christopher Allan Webber
1 sibling, 1 reply; 6+ messages in thread
From: Andy Wingo @ 2017-05-02 7:47 UTC (permalink / raw)
To: Christopher Allan Webber; +Cc: Guix-devel, 26685
On Sat 29 Apr 2017 23:33, Christopher Allan Webber <cwebber@dustycloud.org> writes:
> I'm crossposting this to guix-devel, even though it's in reply to
> guix-patches bug #26685 adding the cerbot service, because I think it's
> more about my experiences with workflow and less about what might affect
> that specific bug. (If you reply on guix-devel, maybe remove the
> debbugs address.)
Oh, I think this does bear on the service. Thanks for the detailed
report!
> - I was surprised that I was prompted for an email while doing guix
> system reconfigure (and in being asked if I was willing to supply
> that info to the EFF so they can put me on their mailing lists, which
> I'm not against but was surprising to encounter in a reconfigure).
> IIRC this is the first time anything like that has happened. I
> generally anticipate such a reconfigure to be "prompt-less".
> I wonder if there should be an email field we can provide, so that it
> doesn't do this prompt? Granted, it's for the first time run only.
> Maybe it's okay to do things as they are, but we should document it?
> I dunno?
Yeah I don't know :) I mean, good that it worked. I hadn't tested this
bit entirely -- I didn't have a spare source of domain names handy (!).
And I forgot about it asking me for my email.
However apparently what happens is that certbot will prompt you for
things if you run it with an interactive terminal. We can pass
--no-interactive, but AFAIU that will require you to go later and
"register" your account with an after-step -- and if you miss that you
have to do that, perhaps your cert stops working soon. Not sure what
the best practice is here. In any case we need to document this!
> - Not specifically something to do with this package, but nginx wasn't
> coming up at a few points (btw, default nginx configuration won't
> work, because it points at certificate filepaths that we don't
> "automatically" put in place). When nginx doesn't come up, there's
> pretty much no information as to why; nothing in the shepherd logs,
> nothing useful from shepherd itself ("shepherd: Service nginx could
> not be started."), and nothing in the nginx logs either.
I think the default nginx configuration works, because it defines no
servers. If you run just (nginx-configuration), then certbot extends it
correctly to allow it to request a certificate. You are right that the
default server config does want to listen on HTTPS and it will balk
if/when there is no cert. (Does that prevent the whole nginx server
from running? That would be a bummer.)
> - Getting the certbot stuff to work basically involved three stages:
>
> 1) Enable nginx without cert certbot, and point the root somewhere
> which will be the same place you'll set certbot-configuration's
> webroot at in the next step. This looks something like the
> following:
>
> (service nginx-service-type
> (nginx-configuration
> (server-blocks
> (list
> (nginx-server-configuration
> ;; Replace these with your own domain and web root
> (server-name '("test.activitypub.rocks"))
> (root "/srv/activitypub.rocks/site/")
> ;; Note that you have to disable https and any certificates
> ;; esp because our nginx config defaults to pointing at keys
> ;; that probably aren't there. Without doing this nginx
> ;; will die mysteriously.
> (https-port #f)
> (ssl-certificate #f)
> (ssl-certificate-key #f))))))
Pretty sure you could do this with just the default nginx-configuration
and no sites configured and having the certbot service.
> 3) Okay hopefully that went successfully! It should say. Assuming it
> did, *now* we can add the keys appropriately to the nginx config.
>
> (service nginx-service-type
> (nginx-configuration
> (server-blocks
> (list
> (nginx-server-configuration
> ;; Again, adjust to your site
> (server-name '("test.activitypub.rocks"))
> (root "/srv/activitypub.rocks/site/")
> (ssl-certificate
> "/etc/letsencrypt/live/test.activitypub.rocks/fullchain.pem")
> (ssl-certificate-key
> "/etc/letsencrypt/live/test.activitypub.rocks/privkey.pem"))))))
Now it works yes :)
> 4) At this point I was surprised that it seemed like nginx should have
> been working with https since everything was in place, but I
> couldn't access it from my browser over https. Frustrated, I
> restarted the server.
>
> And then it worked! :)
Incidentally I found this a few times too. Like you change the
nginx config but the nginx server never restarts because somehow
shepherd wasn't updated with the new config. Why would that be? I
didn't understand it either and just restarted the server. Oh well.
Thanks again for the feedback! Definitely needs to be better documented
I guess. We need to make sure nginx can partially start, and if that's
not the case, then introduce a dependency between nginx start and
certbot run, and arrange for the initial certbot run to make its own web
server for that initial phase.
Andy
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: certbot service experience
2017-05-02 7:47 ` Andy Wingo
@ 2017-05-03 0:07 ` Christopher Allan Webber
0 siblings, 0 replies; 6+ messages in thread
From: Christopher Allan Webber @ 2017-05-03 0:07 UTC (permalink / raw)
To: Andy Wingo; +Cc: Guix-devel, 26685
Andy Wingo writes:
> On Sat 29 Apr 2017 23:33, Christopher Allan Webber <cwebber@dustycloud.org> writes:
>
>> I'm crossposting this to guix-devel, even though it's in reply to
>> guix-patches bug #26685 adding the cerbot service, because I think it's
>> more about my experiences with workflow and less about what might affect
>> that specific bug. (If you reply on guix-devel, maybe remove the
>> debbugs address.)
>
> Oh, I think this does bear on the service. Thanks for the detailed
> report!
Glad it helps!
>> - I was surprised that I was prompted for an email while doing guix
>> system reconfigure (and in being asked if I was willing to supply
>> that info to the EFF so they can put me on their mailing lists, which
>> I'm not against but was surprising to encounter in a reconfigure).
>> IIRC this is the first time anything like that has happened. I
>> generally anticipate such a reconfigure to be "prompt-less".
>> I wonder if there should be an email field we can provide, so that it
>> doesn't do this prompt? Granted, it's for the first time run only.
>> Maybe it's okay to do things as they are, but we should document it?
>> I dunno?
>
> Yeah I don't know :) I mean, good that it worked. I hadn't tested this
> bit entirely -- I didn't have a spare source of domain names handy (!).
> And I forgot about it asking me for my email.
>
> However apparently what happens is that certbot will prompt you for
> things if you run it with an interactive terminal. We can pass
> --no-interactive, but AFAIU that will require you to go later and
> "register" your account with an after-step -- and if you miss that you
> have to do that, perhaps your cert stops working soon. Not sure what
> the best practice is here. In any case we need to document this!
Not sure what the best practice is either, but documenting it would be a
step in the right direction!
>> - Not specifically something to do with this package, but nginx wasn't
>> coming up at a few points (btw, default nginx configuration won't
>> work, because it points at certificate filepaths that we don't
>> "automatically" put in place). When nginx doesn't come up, there's
>> pretty much no information as to why; nothing in the shepherd logs,
>> nothing useful from shepherd itself ("shepherd: Service nginx could
>> not be started."), and nothing in the nginx logs either.
>
> I think the default nginx configuration works, because it defines no
> servers. If you run just (nginx-configuration), then certbot extends it
> correctly to allow it to request a certificate. You are right that the
> default server config does want to listen on HTTPS and it will balk
> if/when there is no cert. (Does that prevent the whole nginx server
> from running? That would be a bummer.)
> [...]
> Pretty sure you could do this with just the default nginx-configuration
> and no sites configured and having the certbot service.
>
Oh, I didn't realize certbot was extending the nginx config...! Clever.
>> 4) At this point I was surprised that it seemed like nginx should have
>> been working with https since everything was in place, but I
>> couldn't access it from my browser over https. Frustrated, I
>> restarted the server.
>>
>> And then it worked! :)
>
> Incidentally I found this a few times too. Like you change the
> nginx config but the nginx server never restarts because somehow
> shepherd wasn't updated with the new config. Why would that be? I
> didn't understand it either and just restarted the server. Oh well.
>
> Thanks again for the feedback! Definitely needs to be better documented
> I guess. We need to make sure nginx can partially start, and if that's
> not the case, then introduce a dependency between nginx start and
> certbot run, and arrange for the initial certbot run to make its own web
> server for that initial phase.
Cool. I have no idea how to do that with current shepherd setup! But
maybe it doesn't need to be complex; maybe these tests can just be part
of the service start-up recipe or something.
Thanks for the thoughtful reply :)
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2017-05-03 0:08 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-04-29 21:33 certbot service experience Christopher Allan Webber
2017-04-30 2:15 ` Chris Marusich
2017-04-30 2:35 ` Christopher Allan Webber
2017-04-30 3:00 ` Chris Marusich
2017-05-02 7:47 ` Andy Wingo
2017-05-03 0:07 ` Christopher Allan Webber
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).