Add cross-compliation and package building for arm64 for go-ssb-room #23

notplants · 2021-06-23T21:04:04Z

mhfowler commented

2021-06-23 21:04:04 +00:00

(Migrated from github.com)

This PR adds the capability to peach-package-builder to build a debian package of go-ssb-room for arm64 for running on a peachcloud device.

Its tested and working, and I was able to access the go-ssb-room admin interface through the web and to accept invites from the room via other devices.

A few open TODOS/questions, if this were to be more polished:
A- How to dynamically get the dns name into the go-ssb-room systemd service file. Currently its hardcoded for the domain I was testing with (roomtest2.commoninternet.net). We would probably want this to be read from /var/lib/peachcloud/config.yml , which would involved using some type of script from within the systemd unit file which parses that value (I imagined perhaps we could have another peach-config command, peach-config env ENV_VAR which looks up and returns the value of an ENV_VAR in config.yml, or something along these lines... a microservice for looking up peachcloud environmental variable values, which the go-ssb-room systemd file could make use of.)
B- There is another small little issue, that the peachcloud admin interface, and the go-ssb-room admin interface, would actually need to have different domains, so that they don't conflict... perhaps if the main domain is littleorchard.dyn.peachcloud.org , the room domain could be room.littleorchard.dyn.peachcloud.org ... I would also need to build stuff in to the dyndns logic, to make sure that it keeps both domains dynamically up to date and pointing to the IP of the pi
C- I've been having issues getting certbot to work from the pi on my local network. I keep getting a firewall error from certbot (although I haven't figured out what firewall its running into). What I ended up doing was running certbot on a digital ocean droplet, where certbot ran successfully for my domain, and then copying over the SSL certificates to the pi. This worked. However, if we wanted something more automated in the future, we might need some type of utility on the pi that generates the ssl certificates for the dynamic dns domain, and then configures the nginx conf appropriately using these certs. This sounds possible but non-trivial

cc @mycognosist

This PR adds the capability to peach-package-builder to build a debian package of [go-ssb-room](https://github.com/ssb-ngi-pointer/go-ssb-room) for arm64 for running on a peachcloud device. Its tested and working, and I was able to access the go-ssb-room admin interface through the web and to accept invites from the room via other devices. A few open TODOS/questions, if this were to be more polished: A- How to dynamically get the dns name into the go-ssb-room systemd service file. Currently its hardcoded for the domain I was testing with (roomtest2.commoninternet.net). We would probably want this to be read from /var/lib/peachcloud/config.yml , which would involved using some type of script from within the systemd unit file which parses that value (I imagined perhaps we could have another peach-config command, ```peach-config env ENV_VAR``` which looks up and returns the value of an ENV_VAR in config.yml, or something along these lines... a microservice for looking up peachcloud environmental variable values, which the go-ssb-room systemd file could make use of.) B- There is another small little issue, that the peachcloud admin interface, and the go-ssb-room admin interface, would actually need to have different domains, so that they don't conflict... perhaps if the main domain is littleorchard.dyn.peachcloud.org , the room domain could be room.littleorchard.dyn.peachcloud.org ... I would also need to build stuff in to the dyndns logic, to make sure that it keeps both domains dynamically up to date and pointing to the IP of the pi C- I've been having issues getting certbot to work from the pi on my local network. I keep getting a firewall error from certbot (although I haven't figured out what firewall its running into). What I ended up doing was running certbot on a digital ocean droplet, where certbot ran successfully for my domain, and then copying over the SSL certificates to the pi. This worked. However, if we wanted something more automated in the future, we might need some type of utility on the pi that generates the ssl certificates for the dynamic dns domain, and then configures the nginx conf appropriately using these certs. This sounds possible but non-trivial cc @mycognosist

🎉 1

mhfowler commented

2021-06-23 21:04:41 +00:00

(Migrated from github.com)

This is the nginx configuration I used, for now manually on the pi, to reverse proxy to the go-ssb-room:

server {
    server_name roomtest2.commoninternet.net;

    listen 443 ssl; # managed by Certbot

    ssl_certificate /etc/letsencrypt/live/roomtest2.commoninternet.net/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/roomtest2.commoninternet.net/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

    location / {
        proxy_pass http://localhost:8899;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-For $remote_addr:$remote_port;
        proxy_set_header X-Forwarded-Proto $scheme;
        # for websocket
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
    }

    # TODO: https://blog.tarq.io/nginx-catch-all-error-pages/
}

# this server uses the (same) wildcard cert as the one above but uses a regular expression on the hostname
# which extracts the first subdomain which holds the alias and forwards that to the prox_pass server
server {
    server_name "~^(?<alias>\w+)\.roomtest2\.commoninternet\.net$";

    listen 443 ssl; # managed by Certbot

    ssl_certificate /etc/letsencrypt/live/roomtest2.commoninternet.net/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/roomtest2.commoninternet.net/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

    location = / {
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-For $remote_addr:$remote_port;
        proxy_set_header X-Forwarded-Proto $scheme;
        # "rewrite" requests with subdomains to the non-wildcard url for alias resolving
        # $is_args$args pass on ?encoding=json if present
        proxy_pass http://localhost:8899/alias/$alias$is_args$args;
    }

    location / {
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-For $remote_addr:$remote_port;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_pass http://localhost:8899;
    }

    # TODO: https://blog.tarq.io/nginx-catch-all-error-pages/
}

server {
    if ($host ~ roomtest2.commoninternet.net$ ) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


    listen 80;
    listen [::]:80;
    server_name roomtest2.commoninternet.net;
    return 404; # managed by Certbot
}

This is the nginx configuration I used, for now manually on the pi, to reverse proxy to the go-ssb-room: ``` server { server_name roomtest2.commoninternet.net; listen 443 ssl; # managed by Certbot ssl_certificate /etc/letsencrypt/live/roomtest2.commoninternet.net/fullchain.pem; # managed by Certbot ssl_certificate_key /etc/letsencrypt/live/roomtest2.commoninternet.net/privkey.pem; # managed by Certbot include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot location / { proxy_pass http://localhost:8899; proxy_set_header Host $host; proxy_set_header X-Forwarded-Host $host; proxy_set_header X-Forwarded-For $remote_addr:$remote_port; proxy_set_header X-Forwarded-Proto $scheme; # for websocket proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection $connection_upgrade; } # TODO: https://blog.tarq.io/nginx-catch-all-error-pages/ } # this server uses the (same) wildcard cert as the one above but uses a regular expression on the hostname # which extracts the first subdomain which holds the alias and forwards that to the prox_pass server server { server_name "~^(?<alias>\w+)\.roomtest2\.commoninternet\.net$"; listen 443 ssl; # managed by Certbot ssl_certificate /etc/letsencrypt/live/roomtest2.commoninternet.net/fullchain.pem; # managed by Certbot ssl_certificate_key /etc/letsencrypt/live/roomtest2.commoninternet.net/privkey.pem; # managed by Certbot include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot location = / { proxy_set_header Host $host; proxy_set_header X-Forwarded-Host $host; proxy_set_header X-Forwarded-For $remote_addr:$remote_port; proxy_set_header X-Forwarded-Proto $scheme; # "rewrite" requests with subdomains to the non-wildcard url for alias resolving # $is_args$args pass on ?encoding=json if present proxy_pass http://localhost:8899/alias/$alias$is_args$args; } location / { proxy_set_header Host $host; proxy_set_header X-Forwarded-Host $host; proxy_set_header X-Forwarded-For $remote_addr:$remote_port; proxy_set_header X-Forwarded-Proto $scheme; proxy_pass http://localhost:8899; } # TODO: https://blog.tarq.io/nginx-catch-all-error-pages/ } server { if ($host ~ roomtest2.commoninternet.net$ ) { return 301 https://$host$request_uri; } # managed by Certbot listen 80; listen [::]:80; server_name roomtest2.commoninternet.net; return 404; # managed by Certbot } ```

notplants closed this pull request

2021-11-08 09:45:57 +00:00