search

guysoft / OctoPi

Scripts to build OctoPi, a Raspberry PI distro for controlling 3D printers over the web
GNU General Public License v3.0
2.49k stars 368 forks source link

OctoPi 0.18.0 RC1 Status #692

Closed guysoft closed 3 years ago

guysoft commented 3 years ago

First release candidate for OctoPi 0.18.0

There are both 32bit and 64bit Based on RpiOS images available. Which give support to Raspberry Pi 4B 8GB and Raspberry Pi 400

The main change that would be likely noticable to plugin developers is that OctoPi comes with Python3 now.

Please try the release candidate.

32bit armf: Download it at: http://unofficialpi.org/Distros/OctoPi/2020-11-02_2020-08-20-octopi-buster-armhf-lite-0.18.0.zip

Md5: d3cb6af431e326cb8bd27719016d3922.

64bit arm64/aarch64: Download it at: http://unofficialpi.org/Distros/OctoPi/2020-11-02_2020-08-20-octopi-buster-arm64-lite-0.18.0.zip

Md5: 643a6f4da6170607c57769a0c5bf2e7e.

Changes in the image

Build notes

cp2004 commented 3 years ago

Create a request over on the OctoPrint repository, for a wizard for software update. Something like that can probably be done.

guysoft commented 3 years ago

I actually have OctoPi building for Ubuntu 64bit. Thankfully most of the lifting was done in CustomPiOS for PhotoPrismPi/UbuntuDockerPi (BTW UbuntuDockerPi is pretty awesome). I did a few commits last week that build it, the only missing part now is the PPA. Here is the issue I am facing: https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1849714

foosel commented 3 years ago

Considering that this issue has been open for 1.5y that doesn't look too promising. And as you know, it building and it actually working in the field in a stable way are two different pairs of shoes. I'd rather not have this block progress of getting 0.18 out further. There's IMHO no harm in pushing out a 32bit rc2 (with a stable release within a month or so) and playing around with 64bit in the nightlies until we have something stable.

guysoft commented 3 years ago

So I found out that libraspberrypi-bin is not part of the Ubuntu repos. Its only there from groovy (20.10) and AFAIK there is no way to get in to focal (20.04). I'd rather have 20.04 because its LTS. But it seems to work and I have a nightly built: http://unofficialpi.org/Distros/OctoPi/nightly-arm64/2021-01-11_octopi-20.10-preinstalled-server-arm64+raspi-0.18.0.zip md5: b0296e50919cc16d1d84bfb0e15e0b2c

It seems to load but

  1. There is an Ubuntu user and also the Pi user (can be fixed).
  2. Pi user has no sudo
  3. HA proxy does not load. I get: 
    /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -S /run/haproxy-master.sock
[NOTICE] 010/111929 (4074) : haproxy version is 2.2.3-2
[NOTICE] 010/111929 (4074) : path to executable is /usr/sbin/haproxy
[ALERT] 010/111929 (4074) : parsing [/etc/haproxy/haproxy.cfg:35] : The 'reqrep' directive is not supported anymore since HAProxy 2.1. Use 'http-request replace-path', 'http-request replace-uri' or 'http-request replace-header' instead.
[ALERT] 010/111929 (4074) : parsing [/etc/haproxy/haproxy.cfg:36] : The 'reqadd' directive is not supported anymore since HAProxy 2.1. Use 'http-request add-header' instead.
[ALERT] 010/111929 (4074) : parsing [/etc/haproxy/haproxy.cfg:37] : The 'reqadd' directive is not supported anymore since HAProxy 2.1. Use 'http-request add-header' instead.
[ALERT] 010/111929 (4074) : parsing [/etc/haproxy/haproxy.cfg:43] : The 'reqrep' directive is not supported anymore since HAProxy 2.1. Use 'http-request replace-path', 'http-request replace-uri' or 'http-request replace-header' instead.
[ALERT] 010/111929 (4074) : Error(s) found in configuration file : /etc/haproxy/haproxy.cfg
[ALERT] 010/111929 (4074) : Fatal errors found in configuration.
CRCinAU commented 3 years ago 
        acl needs_scheme req.hdr_cnt(X-Scheme) eq 0
        reqrep ^([^\ :]*)\ /(.*) \1\ /\2
        reqadd X-Scheme:\ https if needs_scheme { ssl_fc }
        reqadd X-Scheme:\ http if needs_scheme !{ ssl_fc }

Is this just to redirect to from http -> https?

If so, its better to use:

redirect scheme https code 301 if !{ ssl_fc }

I'm not sure why you need the X-Scheme: header at all - unless its used in OctoPrint somewhere?

If so, use:

http-request add-header X-Scheme https if needs_scheme { ssl_fc }
http-request add-header X-Scheme http if needs_scheme !{ ssl_fc }

To make life easier, I think these blocks will work:

backend octoprint
        acl needs_scheme req.hdr_cnt(X-Scheme) eq 0

        http-request replace-path ^([^\ :]*)\ /(.*) \1\ /\2
        http-request add-header X-Scheme https if needs_scheme { ssl_fc }
        http-request add-header X-Scheme http if needs_scheme !{ ssl_fc }
        option forwardfor
        server octoprint1 127.0.0.1:5000
        errorfile 503 /etc/haproxy/errors/503-no-octoprint.http

backend webcam
        http-request replace-path ^([^\ :]*)\ /webcam/(.*)     \1\ /\2
        server webcam1  127.0.0.1:8080
        errorfile 503 /etc/haproxy/errors/503-no-webcam.http
guysoft commented 3 years ago

New RC2: #710

guysoft commented 3 years ago

Ubuntu talks will continue elsewhere

CRCinAU commented 3 years ago

Just edited my comment above with what I believe could be working haproxy config...