[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#32845: guix.info: Missing manual
From: |
Ricardo Wurmus |
Subject: |
bug#32845: guix.info: Missing manual |
Date: |
Thu, 27 Sep 2018 17:28:32 +0200 |
User-agent: |
mu4e 1.0; emacs 26.1 |
Ludovic Courtès <address@hidden> writes:
> Hello,
>
> Ricardo Wurmus <address@hidden> skribis:
>
>> The copy at guix.info does not use the same gnu.org/software/guix
>> prefix, so all links to the manual are likely wrong.
>>
>> This needs to be fixed in our website code, so that the same code works
>> for both sites.
>
> I wonder what should be done with guix.info: should we keep it as a
> mirror, or should it redirect to gnu.org, or the opposite?
I really don’t know. I didn’t plan for guix.info to become popular, but
it certainly is convenient right now as we can change DNS records at a
whim.
Currently, the manual shown on guix.info is fairly close to the latest
in git. This means it contains documentation about channels, which
cannot be found in the latest release that matches the manual on
gnu.org.
> My initial plan was to use guix.gnu.org as the primary domain but we’re
> stuck with the “Let’s Encrypt vs. multiple entries in DNS A records”
> issue. At the same time, guix.info works just fine.
I thought the bigger issue was running a DNS server, which is something
I’ve never done and wouldn’t like to take on myself.
The problem with naive Let’s Encrypt updates is that automatic
challenges might fail when the “wrong” server is returned by the DNS
server. “certbot” can be used with manual DNS validation, which
requires us to deploy a DNS TXT record. This can be automated with
certbot hooks (scripts that have access to the token that should be
published via environment variables) or through JSON mode, which returns
an object with the token that can be processed through other means.
I think the Let’s Encrypt updates shouldn’t be a blocker.
--
Ricardo