guix.info: Missing manual

Pierre Neidhardt wrote on 26 Sep 2018 12:33

Recipients:(address . bug-guix@gnu.org)

Message-ID:87y3bolf9v.fsf@ambrevar.xyz

The manual is missing from https://guix.info/manual/.

Pierre Neidhardt

Ricardo Wurmus wrote on 26 Sep 2018 20:01

Recipients:(name . Pierre Neidhardt)(address . mail@ambrevar.xyz)(address . 32845@debbugs.gnu.org)

Message-ID:874lect9x0.fsf@elephly.net

Pierre Neidhardt <mail@ambrevar.xyz> writes:

Toggle quote (2 lines)

> The manual is missing from https://guix.info/manual/.

It’s actually available at https://guix.info/manual/en/and

https://guix.info/manual/fr/.

The index is missing, though.

Ricardo

Pierre Neidhardt wrote on 26 Sep 2018 21:44

Recipients:(name . Ricardo Wurmus)(address . rekado@elephly.net)(address . 32845@debbugs.gnu.org)

Message-ID:87efdgjb7h.fsf@ambrevar.xyz

Then we need to update the links on https://guix.info/help/.
I think the Savannah version is not in sync with those localized manuals.

-- 
Pierre Neidhardt
https://ambrevar.xyz/

Ricardo Wurmus wrote on 26 Sep 2018 22:10

Recipients:(name . Pierre Neidhardt)(address . mail@ambrevar.xyz)(address . 32845@debbugs.gnu.org)

Message-ID:87zhw4rpel.fsf@elephly.net

Pierre Neidhardt <mail@ambrevar.xyz> writes:

Toggle quote (3 lines)

> Then we need to update the links on https://guix.info/help/.

> I think the Savannah version is not in sync with those localized manuals.

Indeed. The problem here is that the documentation is not actually part

of our website build. It is part of the GNU-hosted manuals.

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.

Ricardo

Ludovic Courtès wrote on 27 Sep 2018 15:46

Recipients:(name . Ricardo Wurmus)(address . rekado@elephly.net)

Message-ID:87ftxv3vf4.fsf@gnu.org

Hello,

Ricardo Wurmus <rekado@elephly.net> skribis:

Toggle quote (6 lines)

> 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?

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.

Thoughts?

Ludo’.

Ricardo Wurmus wrote on 27 Sep 2018 17:28

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)

Message-ID:87r2hfrmcf.fsf@elephly.net

Ludovic Courtès <ludo@gnu.org> writes:

Toggle quote (13 lines)> Hello,
>
> Ricardo Wurmus <rekado@elephly.net> 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.

Toggle quote (4 lines)

> 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

Pierre Neidhardt wrote on 27 Sep 2018 19:37

Recipients:(name . Ricardo Wurmus)(address . rekado@elephly.net)

Message-ID:87va6q2652.fsf@ambrevar.xyz

Toggle quote (5 lines)

> 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.

This is crucial, I believe.  I believe.  "Static" documentation is a Bad Idea.
I think the manual is better than a wiki, but only if contributors can work on
it "live".

-- 
Pierre Neidhardt
https://ambrevar.xyz/

Ludovic Courtès wrote on 28 Sep 2018 22:03

Recipients:(name . Ricardo Wurmus)(address . rekado@elephly.net)

Message-ID:87h8i91jaq.fsf@gnu.org

Hello!

Ricardo Wurmus <rekado@elephly.net> skribis:

Toggle quote (2 lines)

> Ludovic Courtès <ludo@gnu.org> writes:

[...]

Toggle quote (12 lines)>> 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.

Yes, it’s convenient.

Toggle quote (7 lines)

>> 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.

I’ve never done it either :-) but our Knot service makes it looks easy.

Toggle quote (8 lines)

> 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 didn’t know about all this! Looks like our Certbot service doesn’t

support it though?

Toggle quote (2 lines)

> I think the Let’s Encrypt updates shouldn’t be a blocker.

To me it was the main blocker.

Let’s see if we can bring more knowledgeable people on board…

Ludo’.

Ludovic Courtès wrote on 28 Sep 2018 22:08

Recipients:(name . Pierre Neidhardt)(address . mail@ambrevar.xyz)

Message-ID:877ej51j2n.fsf@gnu.org

Pierre Neidhardt <mail@ambrevar.xyz> skribis:

Toggle quote (9 lines)

>> 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.

> This is crucial, I believe. I believe. "Static" documentation is a Bad Idea.

> I think the manual is better than a wiki, but only if contributors can work on

> it "live".

One obvious problem with documentation on the web is that it’s hard to

tell if it matches the version of what you’re actually using. (That’s

one of the reasons for the “Documentation” section in the manual.)

The only reason IMO that justifies keeping “static” documentation (for

the latest release) is the installation instructions: these may change

anytime in ‘master’, but it’s important that those on-line match what

people will actually download.

Thoughts?

Ludo’.

Tobias Geerinckx-Rice wrote on 28 Sep 2018 22:39

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)

Message-ID:87a7o1nypy.fsf@tobias.gr

Ludo', Guix,

Ludovic Courtès wrote:

Toggle quote (15 lines)> Ricardo Wurmus <rekado@elephly.net> skribis:
>> “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 didn’t know about all this!  Looks like our Certbot service 
> doesn’t
> support it though?

Not out of the box, and last time I checked vanilla certbot didn't

provide an nsupdate (RFC2136) hook alongside all the DNSaaS API

rubbish.

But it's certainly possible, and wonderfully stable once set

up. t.gr runs entirely on GuixSD + Knot + DNS-validated LE certs.

Kind regards,

T G-R

Ludovic Courtès wrote on 29 Sep 2018 18:14

Recipients:(name . Tobias Geerinckx-Rice)(address . me@tobias.gr)

Message-ID:87o9cgz3f7.fsf@gnu.org

Hi Tobias,

Tobias Geerinckx-Rice <me@tobias.gr> skribis:

Toggle quote (20 lines)> Ludovic Courtès wrote:
>> Ricardo Wurmus <rekado@elephly.net> skribis:
>>> “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 didn’t know about all this!  Looks like our Certbot service
>> doesn’t
>> support it though?
>
> Not out of the box, and last time I checked vanilla certbot didn't
> provide an nsupdate (RFC2136) hook alongside all the DNSaaS API
> rubbish.
>
> But it's certainly possible, and wonderfully stable once set up. t.gr
> runs entirely on GuixSD + Knot + DNS-validated LE certs.

Neat. Would you like to help come up with a Knot & Certbot config for

guix.gnu.org? :-)

The peculiarity is this:

Toggle snippet (5 lines)

$ getent hosts guix.gnu.org

141.80.181.40 guix.gnu.org

185.233.100.56 guix.gnu.org

Ludo’.

Ricardo Wurmus wrote on 28 Sep 2018 22:38

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)

Message-ID:87mus1bbnz.fsf@elephly.net

Ludovic Courtès <ludo@gnu.org> writes:

Toggle quote (11 lines)>> 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 didn’t know about all this!  Looks like our Certbot service doesn’t
> support it though?

That’s right. The question is what we want to do in the auth hook when

this is performed in the service. We could just punt and have the user

supply the path to a custom hook script.

Toggle quote (2 lines)

> Let’s see if we can bring more knowledgeable people on board…

Yes please! :)

Ricardo

sirgazil wrote on 25 Jan 2020 19:00

guix.info: Missing manual

Recipients:(name . 32845)(address . 32845@debbugs.gnu.org)

Message-ID:16fdddcb579.10f3166aa32604.7332330738350003672@zoho.com

The "https://guix.info/manual/"currently redirects to "https://guix.gnu.org/manual/", which links to the manual in different languages.

Problem solved?

Ludovic Courtès wrote on 28 Jan 2020 11:28

Recipients:(name . sirgazil via Bug reports for GNU Guix)(address . bug-guix@gnu.org)

Message-ID:87a767j2o0.fsf@gnu.org

Hi,

sirgazil via Bug reports for GNU Guix <bug-guix@gnu.org> skribis:

Toggle quote (4 lines)

> The "https://guix.info/manual/"currently redirects to "https://guix.gnu.org/manual/", which links to the manual in different languages.

> Problem solved?

I think so, thanks!

Ludo’.

Your comment

This issue is archived.

To comment on this conversation send email to 32845@debbugs.gnu.org

is:open	open issues
is:done	closed issues
submitter:<who>	search issue submitter
author:<who>	search by message author
date:yesterday..now	search by issue date
mdate:3m..2d	search by message date