💾 Archived View for mozz.us › journal › 2020-07-07.gmi captured on 2023-03-20 at 17:49:39. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

Re: Gemini on Tor (fox)

Published 2020-07-07

(in reply to)

gemini://tilde.black/users/fox/journal/20200706-gemini-on-tor.gmi

The jetforce wrapper

I stuck with the example code as much as possible here. I probably don't need app_a, app_b, and app_default at all and could have just used one. I'm not 100% sure though and once it worked I stopped messing with it. The idea is to serve up files for either tilde.black or the onion address and this does that. Note I needed to tell the server where my keys were and to run on 0.0.0.0. I'm not sure what I would need to do to get this to run on both ipv4 and ipv6 at the same time. Maybe one of you can chime in?

Using an empty string for the host is the weird python convention for "bind to all interfaces".

Here's how I would refactor your launch script:

from jetforce import GeminiServer, StaticDirectoryApplication
from jetforce.app.composite import CompositeApplication

onion_url = "black6kfjetfuzaeozz7fs53whh7xtd4e27telrf5fg5kgdt5ah5plad.onion"

default_app = StaticDirectoryApplication()

app = CompositeApplication(
    {
        onion_url: default_app,
        None: default_app,  # Fallback, will use the hostname defined by the server below
    }
)

if __name__ == "__main__":
    server = GeminiServer(
        app,
        certfile="/etc/gemini/tilde.black.crt",
        keyfile="/etc/gemini/tilde.black.key",
        hostname="tilde.black",  # The default hostname
        host="",  # Listen on both 0.0.0.0 and [::]
    )
    server.run()

The rc.d service

Running python scripts in rc.d is annoying because the check method doesn't find the running code properly and all sorts of problems happen. I separate the code for the daemon and the python3 instigator so I can get it all to play nice. I have no idea how I'd get virtualenv to work with this. This is why python gives me a headache.

Yea python virtual environments are a pain 😩. I try to avoid them when possible, but now that jetforce uses twisted it also bundles in some transitive dependencies that may conflict with your system's python libraries.

Try this. Instead of pointing your init script to the default python interpreter, point it at the python interpreter for your virtualenv:

#!/bin/ksh

# /etc/rc.d/jetforce

daemon="/opt/jetforce/vhost.py"
daemon_user="gemini"
. /etc/rc.d/rc.subr

# assuming virtualenv root is /opt/jetforce/venv/
pexp="/opt/jetforce/venv/bin/python ${daemon}"

rc_reload="NO"

rc_check() {
  pgrep -q -f "${daemon}"
}

rc_start() {
  ${rcexec} "${pexp}" &
}

rc_cmd $1

Alternatively, you could give +x permission to the file and specify the interpreter using a shebang. Then you could run the script directly without pointing to the python interpreter every time.

#!/opt/jetforce/venv/bin/python

from jetforce import GeminiServer, StaticDirectoryApplication
from jetforce.app.composite import CompositeApplication
...