Hello everyone,

I know this is a bit of a stretch but I wanted to know if there's
anyone who tried running Molly Brown under Yggdrasil [1]. I don't
know if I'm just being stupid or if Molly Brown doesn't properly
recognize IPv6 addressing.

I was mostly trying it out to see whether I would be able to make
it work but at this point I'm just dumbfounded. I was really hoping
it would work since I really liked that server's feature of
autogenerating personal gemini capsules.

Either way, I'm also curious whether anyone tried hosting a capsule
under Yggdrasil.

Cheers everyone!

[1] https://yggdrasil-network.github.io/

--
Ang kalayaan ay dili gihatag, ini'y giabot.
--
{gemini,gopher}://kalayaan.xyz

On 2022-02-07, rtr <rtr@haraya.invalid> wrote:
> I know this is a bit of a stretch but I wanted to know if there's
> anyone who tried running Molly Brown under Yggdrasil [1]. I don't
> know if I'm just being stupid or if Molly Brown doesn't properly
> recognize IPv6 addressing.

Molly Brown is just using a call to the Go standard library to listen
on a host and a port. Molly Brown doesn't specify an IP to listen on,
so in theory it should be listening on every [anycast or
unicast](https://pkg.go.dev/net#Listen) address, so I wonder if
Yggdrasil is marking the address as neither. Regardless it should be
trivial to extend the code to listen on a given IP and port. If you'd
be interested, I could put a patch together for that.

Apologies for the double follow-up.

On 2022-02-07, rtr <rtr@haraya.invalid> wrote:
> Either way, I'm also curious whether anyone tried hosting a capsule
> under Yggdrasil.

There's also the matter that you're not getting much out of the TLS on
Gemini since Yggdrasil is encrypting traffic onto the overlay
anyway. That shouldn't stop you from generating a certificate for the
Yggdrasil IP as long as you're holding onto a stable IPv6 address and
not grabbing random addresses from your /64.

Am 07.02.22 um 14:17 schrieb rtr:
> Either way, I'm also curious whether anyone tried hosting a capsule
> under Yggdrasil.

Nice idea. Just tell me/us, if your done with your setup. I will try to
reach your capsule and will try it out on my own vps too with gmid
server from Omar Polo.

Martin

meff <email@example.com> writes:

> Apologies for the double follow-up.
>
> On 2022-02-07, rtr <rtr@haraya.invalid> wrote:
>> Either way, I'm also curious whether anyone tried hosting a capsule
>> under Yggdrasil.
>
> There's also the matter that you're not getting much out of the TLS on
> Gemini since Yggdrasil is encrypting traffic onto the overlay
> anyway. That shouldn't stop you from generating a certificate for the
> Yggdrasil IP as long as you're holding onto a stable IPv6 address and
> not grabbing random addresses from your /64.

Hi meff, thanks for the response. I was able to make it work. My
problem was a bunch of things not going right, partly because I
don't know how to deal with IPv6 addresses and partly because I
don't know what I'm doing in general. Anyway, I will post here
what I did to make it work just in case someone else found
themselves in the position that I was.

Yes, you're right. Molly Brown doesn't really discriminate if
you're accessing an IPv6 or IPv4 address.

However, the first problem that I had was that the HOSTNAME
variable and the certificate that you are generating must
match. While that seems obvious enough, I wasn't sure whether I
ought to include the square brackets used in IPv6 addresses. I
first generated a certificate that has an address with square
brackets as its certificate name and then set-up my HOSTNAME
variable the same way.

Molly Brown doesn't like that. The hostname variable should only be
an address without any brackets when used with IPv6. I changed it
back but then I kept getting certificate mismatch errors. So I
generated a new certificate with the one without brackets.

I thought I already solved the problem but now I kept getting
"40 -- Temporary Error". I was trying to figure out the issue and
when I ran molly as root the server popped up. So I know, by then,
that the issue was either with the rc.d script or permissions that
I've set for the folders.

(I'm running Molly Brown in FreeBSD)

After some fruitless documentation diving, I figured I should mess
with the file permissions in DOCDIR and my configuration
directory. I've set both of those folders to be owned by
daemon:daemon and played around with the file permissions. What
worked were the following:

# chmod -R 555 /your/gemini/config/path
# chmod -R 755 /your/doc/dir/path

So in gist. If you want to run Molly Brown under Yggdrasil, you'll
need to set your HOSTNAME variable and certificate variable to your
Yggdrasil address without square brackets and make sure that your
config folder and DOCDIR folder is owned by daemon with the
permissions set to 555 and 755 respectively.

If anyone's interested here's Yggdrasil Capsule:
gemini://[209:dead:1cc2:970:637b:450f:6575:9a24]/~/rtr/

Cheers everyone!

--
Ang kalayaan ay dili gihatag, ini'y giabot.
--
{gemini,gopher}://kalayaan.xyz

Martin <martin@datapulp.de> writes:

> Am 07.02.22 um 14:17 schrieb rtr:
>> Either way, I'm also curious whether anyone tried hosting a capsule
>> under Yggdrasil.
>
> Nice idea. Just tell me/us, if your done with your setup. I will try
> to reach your capsule and will try it out on my own vps too with gmid
> server from Omar Polo.
>
> Martin
>

Hi Martin, I was able to make the capsule work. I was having a
problem with a conflict with the HOSTNAME variable and the
certificate name that I was generating. Basically, you need to
provide the Yggdrasil address without any square brackets.

Also, if you're running under FreeBSD make sure that the DOCDIR and
config directory is owned by daemon with the file permissions set
to 555 and 755 respectively.

Here's my Yggdrasil Capsule if you want to try reaching it:
gemini://[209:dead:1cc2:970:637b:450f:6575:9a24]/~/rtr/

--
Ang kalayaan ay dili gihatag, ini'y giabot.
--
{gemini,gopher}://kalayaan.xyz

On 2022-02-08, rtr <rtr@haraya.invalid> wrote:
> However, the first problem that I had was that the HOSTNAME
> variable and the certificate that you are generating must
> match. While that seems obvious enough, I wasn't sure whether I
> ought to include the square brackets used in IPv6 addresses. I
> first generated a certificate that has an address with square
> brackets as its certificate name and then set-up my HOSTNAME
> variable the same way.
>
> Molly Brown doesn't like that. The hostname variable should only be
> an address without any brackets when used with IPv6. I changed it
> back but then I kept getting certificate mismatch errors. So I
> generated a new certificate with the one without brackets.
>

Oh I've never made a certificate with a bare IP address, let alone an
IPv6 address so this is new info for me at least, thanks!

Am 09.02.22 um 01:00 schrieb rtr:
> Hi Martin, I was able to make the capsule work.
Hi rtr,

I'm not that successful up to now:

I can ping your host via yggdrasil.
I can ping my vps via yggdrasil.

... but I can't call your capsule or my capsule, same error:

Loading gemini://[209:dead:1cc2:970:637b:450f:6575:9a24]/~/rtr/...

╔═════════════════════ URL Fetch Error ═════════════════════╗

║ ║

║ Failed to connect to the server: hostname does not ║

║ verify: x509: certificate relies on legacy Common Name ║

║ field, use SANs instead. ║

║ ║

║ Ok ║

║ ║

╚═══════════════════════════════════════════════════════════╝

I'm using amfora. I made my certificate this way, would the CN be ok in
your eyes? How did you do it? Which browser do you use?

openssl req -x509 -newkey rsa:4096 -days 36500 -nodes \
-keyout yggdrasil.key -out yggdrasil.crt -subj \
"/CN=201:112e:4d49:1af1:9190:6da8:bf38:aa9d"

But: THIS IS THE WRONG WAY

I successfully created a self signed certificate for localhost, but I
never managed to call the gemini server just by it's ip, always I need
to call it localhost.

I googled a lot but up to now I did not find a way to work just with ip.

Ciao
Martin

On 2022-02-09, Martin <martin@datapulp.de> wrote:
> Loading gemini://[209:dead:1cc2:970:637b:450f:6575:9a24]/~/rtr/...
>
> ╔═════════════════════ URL Fetch Error ═════════════════════╗
> ║ ║
> ║ Failed to connect to the server: hostname does not ║
> ║ verify: x509: certificate relies on legacy Common Name ║
> ║ field, use SANs instead. ║
> ║ ║
> ║ Ok ║
> ║ ║
> ╚═══════════════════════════════════════════════════════════╝

This means that the cert should use a SAN and not a CN, but may be
indicative of a different error underneath.

> I'm using amfora. I made my certificate this way, would the CN be ok in
> your eyes? How did you do it? Which browser do you use?
>
> openssl req -x509 -newkey rsa:4096 -days 36500 -nodes \
> -keyout yggdrasil.key -out yggdrasil.crt -subj \
> "/CN=201:112e:4d49:1af1:9190:6da8:bf38:aa9d"
>
>
> But: THIS IS THE WRONG WAY

Interesting, did you try this method to create the cert and it didn't
work?

- meff

Am 09.02.22 um 22:16 schrieb meff:
> This means that the cert should use a SAN and not a CN, but may be
> indicative of a different error underneath.

Yes, with my own capsule I also tried SAN, this is the openssl.cnf:

[req]
default_bits = 2048
distinguished_name = req_distinguished_name
req_extensions = req_ext
x509_extensions = v3_req
prompt = no

[req_distinguished_name]
countryName = XX
stateOrProvinceName = N/A
localityName = N/A
organizationName = Self-signed certificate
commonName = localhost

[req_ext]
subjectAltName = @alt_names

[v3_req]
subjectAltName = @alt_names

[alt_names]
IP.1 = 127.0.0.1
DNS.1 = localhost

Although the ip address appears in the certificate as whished, I still
am just able to connect to the capsule via the name "localhost"

THe openssl command for the above config:

openssl req -x509 -nodes -days 36500 -newkey rsa:4096 -keyout
yggdrasil.key -out yggdrasil.crt -config openssl.cnf

> Interesting, did you try this method to create the cert and it didn't
> work?

I tried the above and according to different explainations it should
also work with the raw ip adress calling.

Well, in the end I thought: maybe gmid does not support raw ip
addresses. I do think so.

Did anybody other manage to get a raw ip address access to a capsule?

Martin

Martin <martin@datapulp.de> writes:

> Am 09.02.22 um 01:00 schrieb rtr:
>> Hi Martin, I was able to make the capsule work.
> Hi rtr,
>
> I'm not that successful up to now:
>
> I can ping your host via yggdrasil.
> I can ping my vps via yggdrasil.
>
> .. but I can't call your capsule or my capsule, same error:
>
>
> Loading gemini://[209:dead:1cc2:970:637b:450f:6575:9a24]/~/rtr/...
> ╔═════════════════════ URL Fetch Error ═════════════════════╗
> ║ ║
> ║ Failed to connect to the server: hostname does not ║
> ║ verify: x509: certificate relies on legacy Common Name ║
> ║ field, use SANs instead. ║
> ║ ║
> ║ Ok ║
> ║ ║
> ╚═══════════════════════════════════════════════════════════╝
>
>
>
> I'm using amfora. I made my certificate this way, would the CN be ok
> in your eyes? How did you do it? Which browser do you use?
>
> openssl req -x509 -newkey rsa:4096 -days 36500 -nodes \
> -keyout yggdrasil.key -out yggdrasil.crt -subj \
> "/CN=201:112e:4d49:1af1:9190:6da8:bf38:aa9d"
>
> But: THIS IS THE WRONG WAY
>
> I successfully created a self signed certificate for localhost, but I
> never managed to call the gemini server just by it's ip, always I need
> to call it localhost.
>
> I googled a lot but up to now I did not find a way to work just with ip.
>

Hi Martin,

That's odd. I was able to access my capsule in Yggdrasil through Elpher
and Lagrange. I've just tried Amfora and I can confirm that that error
does show up on my end too.

I've used roughly the same command as you did above. I've set the CN
variable to the IP address of my Yggdrasil machine. If that's the wrong
way then I have no idea at the moment to properly do it. I've just
looked into SAN but I'll probably need to look at it when I have more
time in my hands.

Also, I don't think setting the HOSTNAME variable to localhost will work
since Molly Brown assumes that the variable to be connectable
from the outside. If that would be an issue, probably something like
gnmisrv might be more apt since it (seems) to not look for a hostname
variable [1].

One solution that I'm thinking right now is to just get a DNS record for
your Yggdrasil capsule. I believe you can use Alfis to do this
[2]. I haven't messed around with DNS for Yggdrasil yet though so I
don't have any informed opinion about that.

Cheers!

[1] https://sr.ht/~sircmpwn/gmnisrv/

[2] https://github.com/Revertron/Alfis

--
Ang kalayaan ay dili gihatag, ini'y giabot.
--
{gemini,gopher}://kalayaan.xyz