Can we setup PeerTube on naked OpenBSD ?

Without Nginx actually.

NB : this article has been updated to reflect developments. It is useful as an install method, but I do not recommend not using Nginx, explanations later in the text. I will keep the Httpd+Relayd part as reminder. Maybe someone will find it usefull.

Why ?

Several reasons for this questioning:

  • Nginx is not in Base.
  • We have http daemons in Base, could we use them instead of Nginx?
  • These daemons are designed with the OpenBSD culture in mind and use its successive improvements, notably pledge().
  • Nginx is, from what I understand, a really twisted thing.

Basically, we have the basics, why not use them. What’s more, Relayd will then use LibreSSL directly and we’ll have a TLS connection with the latest protocols.

Inconvenient

We’ll use TLS 1.3 (when Nginx only delivers 1.2 on OpenBSD) but we’ll only use http/1.1 when Nginx delivers http/2. So it’s a blessing in disguise.

We have to transform the entire Nginx configuration that is provided by the PeerTube developer into a relayd + httpd configuration, which is far from simple.

Preliminaries

I recommend reading Michael W Lucas’ books for OpenBSD, Relayd and TLS. It will save you a lot of trouble.

Also, have the relayd.conf manual open. Seriously, this thing makes no sense without the manual. It does not makes sense with it either. But you have a chance to go through somehow.

I’m going to take important bits from previous articles to describe the installation process. The advantage is that you don’t need to go back and read them, unless you want the history or a more detailed explanation.

Installation / Upgrade

You have to install PostgreSQL, Redis and nodejs. There is no way around it.

    doas pkg_add postgresql-contrib redis node python3 youtube-dl ffmpeg

Don’t forget to check the PostgreSQL port doc, it doesn’t just come oven-ready like the Brexit deal - sic. At the same time you want to set up a PeerTube instance, it will be a challenge sometimes…

You have to create a dedicated user.

    doas useradd -L daemon -d /var/www/peertube _peertube
    doas chown _peertube:_peertube /var/www/peertube
    doas -u _peertube mkdir /var/www/peertube/(versions|storage|config) 

Note that as the name implies, storage will contain the videos and all other data of the instance apart from the configuration and the program itself. You might want to put it on a dedicated mount point. With a big partition. A very large partition.

Oh, by the way. PeerTube itself, the program… it weighs around 700 MB. It also requires space to compile and install. As does PostgreSQL, which will happily exceed one gigabyte. So don’t forget to regularly make room in /var, get rid of old versions, check that the logs are running and not cluttering up the space. We don’t play in the small pool anymore.

I don’t use the PeerTube upgarde script. The symbolic link created at the end is buggy. And node plays tricks with /tmp.

Well, let’s start again. We download the latest version of PeerTube to the adequate directory.

    cd /var/www/peertube/versions
    doas -u _peertube wget https://github.com/Chocobozzz/PeerTube/releases/download/$VERSION/peertube-v$VERSION.zip
    doas -u _peertube unzip peertube-v$VERSION.zip

That paragraph is now irrelevant. You should instead install yarn from openbsd packages (devel/yarn in ports). Yarn does not need /tmp/node.

During compilation, npm/yarn will ask for /tmp/node. Better take care of it now. And also install yarn itself.

    cd /tmp
    ln -s /usr/local/bin/node .
    doas npm install --global yarn

Now let’s compile.

    cd /var/www/peertube/versions/peertube-$VERSION
    doas -u _peertube yarn install --production --pure-lockfile

Here is it running …

    yarn install v1.22.4
    [1/5] Validating package.json...
    warning peertube@3.1.0: The engine "postgres" appears to be invalid.
    warning peertube@3.1.0: The engine "redis-server" appears to be invalid.
    warning peertube@3.1.0: The engine "ffmpeg" appears to be invalid.
    [2/5] Resolving packages...
    warning Resolution field "oauth2-server@3.1.0-beta.1" is incompatible with requested version "oauth2-server@3.0.0"
    warning Resolution field "http-signature@1.3.5" is incompatible with requested version "http-signature@~1.2.0"
    ...
    [4/4] Building fresh packages...
    Done in 39.90s.
    Done in 60.43s.

Tada

Don’t forget to link the directory like following.

    cd /var/www/peertube
    doas rm peertube-latest/ && doas ln -s versions/peertube-v$VERSION ./peertube-latest

You can then create a symbolic link into the configuration. Good side is that this will always follow the version you are using. No need to update it.

    ln -s /var/www/peertube/peertube-latest/config/default.yaml /var/www/peertube/config/default.yaml

Rcctl

Now, we need to be able launching PeerTube like a regular daemon. Ok.

Never did I succeed.

So actually I finally used a Node hypervisor, just like there are for PHP or Python. PM2. Let’s install it like the doc says.

doas npm install pm2 -g

I write a ecosystem.config.js file in /etc/pm/. And actually as you understood, it’s pm2 which starts. Which itself shall start peertube.

module.exports = {
apps : [{
    name: 'peertube',
    cwd:  '/var/www/peertube/peertube-latest/',
    "listen_timeout" : 2000,
    env: {
        "USER":         "_peertube",
        "NODE_ENV":     "production",
        "HOME":         "/var/www/peertube/",
        "NODE_CONFIG_DIR": "/var/www/peertube/config/",
    },
    script: '/var/www/peertube/peertube-latest/dist/server',
    }, ]
};

Just start PM2 like any other daemon now with rcctl.

So let’s write a /etc/rc.d/peertube file, and don’t forget to enable it in /etc/rc.conf.local :

#!/bin/ksh

daemon="/usr/local/bin/pm2"

daemon_user="_peertube"

. /etc/rc.d/rc.subr

pexp="node: PM2.*God Daemon.*"

rc_start() {
    ${rcexec} "${daemon} start /etc/pm/ecosystem.config.js"
}

rc_reload() {
    ${rcexec} "${daemon} reload /etc/pm/ecosystem.config.js"
}

rc_cmd $1    

We cannot yet launch the whole thing as it lacks the http(s) conf’. PeerTube checks during its initialization that it can reach its own webserver with https. So lets’ take care of it.

Httpd

I do not recommend using Httpd+relayd instead of Nginx. This insallation crashed a few times when trying to upload large videos.

Httpd web server configuration is extremly simple as it serves only static files.

/etc/httpd.conf

server "tube.example.com" {
        listen on * port www

        location "/.well-known/acme-challenge/*" {
                root "/acme"
                request strip 2
        }
        location * {
                block return 302 "https://$HTTP_HOST$REQUEST_URI"
        }
}

server "tube.example.com" {
        listen on * port 8000

        root "/var/www/peertube/storage"

        location "/.well-known/acme-challenge/*" {
                root "/acme"
                request strip 2
        }
}

You will notice that I do not redirect the ACME challenge to https. This corresponds well to my installation with Buypass.

Relayd does the most complicated work. And we’re going to tackle it.

Relayd

Relayd will be used to terminate the TLS connection and dispatch the outgoing http streams

  • either to Httpd to serve static content.
  • or to the peertube server itself (you know, the one listening on port 9000 on localhost).
  • in addition to that we can terminate the live connection in ipv6, which is not possible natively.

We’ll analyse the relayd.conf, starting from the top.

NB: as described by M Lucas, protocols are before relays, no matter if it makes sense or not.

/etc/relayd.conf

    # Macros
    #
    ext4="192.0.2.10"
    ext6="2001:DB8:96b1::100"
    webhost="lo0"

    #
    # Global Options
    #
    # interval 10
    # timeout 1000
    # prefork 5

    #
    # Each table will be mapped to a pf table.
    #
    table <webhosts> { $webhost }
    table <apihosts> { 127.0.0.1 }

At the top of the file, macros are used to indicate the addresses where incoming requests arrive. In other words: your public addresses.

The webhosts and apihosts tables can actually be separated. For example, you can run the peertube and httpd daemons on separate hosts. However, the peertube daemon is listening in priority in ipv4. Hence my 127.0.0.1 in apihosts. I have no idea if it is possible to use load balancing (building a large instance with multiple backend servers distributed via these tables).

The rtmp protocol is presented so that it can be relayed in ipv6 at the very end of the file.

    protocol rtmp {
            tcp { nodelay, sack, socket buffer 65536, backlog 128 }
    }

Well, now we’re really getting down to business.

The first part describes the generic options. I have tried to use the same values as the configuration provided by PeerTube.

The tls keypair options are described in the manual. That you go back and read from time to time isn’t it… ISN’T IT …

http websockets is important for PeerTube.

The ciphers line can’t be replaced by HIGH because apparently you include declassified suites. And also: you need one line. You cannot have several options and I couldn’t make a return with \ . Deal with it.

    http protocol https {
            match request header append "X-Forwarded-For"   value "$REMOTE_ADDR"
            match request header append "X-Forwarded-By"    value "$SERVER_ADDR:$SERVER_PORT"

            match response header set "Feature-Policy" value "camera 'none'; microphone 'none'"
            match response header set "Strict-Transport-Security" value "max-age=31536000"
            match response header set "X-Content-Type-Options" value "nosniff"

            # Various TCP options
            tcp { nodelay, sack, socket buffer 65536, backlog 128 }

            tls { tlsv1.3 tlsv1.2, ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384 }

            tls edh params auto
            tls keypair tube.example.com

            http websockets

Here we start to differentiate the requests according to their destination. I will try to stick as much as possible to the configuration provided by PeerTube. We could certainly do a lot more. The Nginx conf file is way more granular. For example, it restricts the allowed HTTP methods, which I can’t do.

            match request path "/api/v1/videos/upload" tag "UPLOAD"
            match response tagged "UPLOAD" header set "Access-Control-Allow-Methods" value "POST, HEAD"
            match response tagged "UPLOAD" header set "X-File-Maximum-Size 8G always"

            match request path "/client/*" tag "CLIENT"
            match response tagged "CLIENT" header set "Cache-Control" value "public, max-age=31536000, immutable"

            match request path "/static/*" tag "STATIC"
            match response tagged "STATIC" header set "Access-Control-Allow-Methods"        value "GET, OPTIONS"
            match response tagged "STATIC" header set "Access-Control-Max-Age"      value "1728000"
            match response tagged "STATIC" header set "Content-Type"                value "text/plain charset=UTF-8"

            match response tagged "STATIC" header set "Access-Control-Allow-Headers" value "Range,DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type"

            pass request tagged "STATIC" forward to <webhosts>

            pass request path "/tracker/socket"     forward to <apihosts>
            pass request path "/socket.io"          forward to <apihosts>
            pass request path "/*"                  forward to <apihosts>
    }

If you can do better, please comment. I will update my installation and this article.

Now we have the three relays, tls in ipv6, tls in ipv4 and rtmp (for live broadcasting) relayed from ipv6 to PeerTube listening in ipv4.

    relay wwwtls6 {
            # Run as a SSL/TLS accelerator
            listen on $ext6 port https tls

            protocol https

            # httpd serve static and the rest on port 8000
            forward to <webhosts> port 8000

            # peertube stuff listens on 9000
            forward to <apihosts> port 9000
    }

    relay wwwtls4 {
            # Run as a SSL/TLS accelerator
            listen on $ext4 port https tls

            protocol https

            # httpd serve static and the rest on port 8000
            forward to <webhosts> port 8000

            # peertube stuff listens on 9000
            forward to <apihosts> port 9000
    }

    relay live {
            listen on $ext6 port 1935
            forward to <apihosts> port 1935
            protocol rtmp
    }

Conclusion

There it is.

The whole installation of PeerTube on OpenBSD, without Nginx but Httpd and Relayd.

You can open the bottle.

    doas rcctl restart peertube