Possibly breaking changes in next package
-
Recent minio versions include a new console UI (removes the old basic object browser). The way it's done is that there are now two http endpoints - one is the console UI and another is the API (S3) endpoint. There are two way to package this:
-
Expose the console UI as the default. This way, the UI is available if you navigate to https://minio.example.com . The S3 API port has to exposed in some other port like say 6000. Users will then have to change the configuration of their tools (s3cmd, awscli etc) and any Cloudron backups to use port 6000. Unfortunately, it exposes the port as HTTP which is obviously insecure. An idea was to use the tls addon to make it use https using the --certs-dir argument. However, this makes both the API and the console use https. This won't work with Cloudron because we expect the main app to be http.
-
An alternate idea is to have an nginx that routes to the two endpoints. This will work but there is some "conflict" in paths between the two endpoints. For example, "static" is a path used by the console UI and thus cannot be a bucket name. This approach has the advantage that users do not need to re-configure tools/backups.
I am looking into the second approach. Does anyone have buckets named 'static' since they might stop working from the next minio version? (maybe there is some User Agent hack I can use to work around this, I have to see).
-
-
-
I have asked them here for a recommendation - https://github.com/minio/minio/discussions/12780
-
In the old days of IRC in the 90s, we used to run many IRC bots,
Eggdrop was one of those, and we eventually took over development of it.
One cool innovation at the time was to be able to sense on the webserver side if it was a browser connecting or not. If not, visiting the TLD would simply serve you the latest Eggdrop.tgz which was convenient for quick downloads from the CLI.
I vote for the alternate approach, and perhaps a protocol shim to sense the difference between HTTPS and S3.
As for the buckets issue, just put it in the upgrade notes as a warning. It's easy to rename buckets these days.
From my experience, "static" is not a common bucket name.
-
@mehdi Currently, the multiDomain flag doesn't force a user to specify an extra domain at install time (in the UI). I guess we can make something like we do for the tcpPorts where we show a bunch of port names with description. So, in this case, we would have two domains with descriptions as "console domain" and "api domain". It's a bit of work, so I am trying to avoid it since no other app needs this. But if we cannot figure out a solution, looks like we will do that.
-
@mehdi Currently, the multiDomain flag doesn't force a user to specify an extra domain at install time (in the UI). I guess we can make something like we do for the tcpPorts where we show a bunch of port names with description. So, in this case, we would have two domains with descriptions as "console domain" and "api domain". It's a bit of work, so I am trying to avoid it since no other app needs this. But if we cannot figure out a solution, looks like we will do that.
@girish I had a "similar" issue with Minio in Docker on two different Synology NAS's. The WatchDog automatically updated the containers, the backups from Cloudron to these kept on working however accessing the GUI was not possible.
Yesterday and today I took a lot of time to solve this, in words:
- API is still on the default port (ie. 9000, 9001 etc), accessing this with a browser will redirect to the GUI port
- GUI I moved to port 9100 (or 9101, etc)
With the command below and some port forwarding in my router it's all working again (the trick that solved issues was MINIO_SERVER_URL, because of TLS):
sudo docker run -dit --restart unless-stopped -p 9000:9000 -p 9100:9100 --name minio -e "MINIO_ROOT_USER=**********************" -e "MINIO_ROOT_PASSWORD=********************" -e "MINIO_SERVER_URL=https://sub.domain.tld:9000" -v /volume1/IT/cloudron-backup:/data -v /volume1/docker/minio/config:/root/.minio minio/minio server /data --console-address ":9100" -
As an update, it seems upstream prefers to have separate domains. So I think we will extend multi-domain feature to implement this like @mehdi suggested. I think this will also help mailtrain v2, maybe mautic as well.
-
Recent minio versions include a new console UI (removes the old basic object browser). The way it's done is that there are now two http endpoints - one is the console UI and another is the API (S3) endpoint. There are two way to package this:
-
Expose the console UI as the default. This way, the UI is available if you navigate to https://minio.example.com . The S3 API port has to exposed in some other port like say 6000. Users will then have to change the configuration of their tools (s3cmd, awscli etc) and any Cloudron backups to use port 6000. Unfortunately, it exposes the port as HTTP which is obviously insecure. An idea was to use the tls addon to make it use https using the --certs-dir argument. However, this makes both the API and the console use https. This won't work with Cloudron because we expect the main app to be http.
-
An alternate idea is to have an nginx that routes to the two endpoints. This will work but there is some "conflict" in paths between the two endpoints. For example, "static" is a path used by the console UI and thus cannot be a bucket name. This approach has the advantage that users do not need to re-configure tools/backups.
I am looking into the second approach. Does anyone have buckets named 'static' since they might stop working from the next minio version? (maybe there is some User Agent hack I can use to work around this, I have to see).
@girish said in Possibly breaking changes in next package:
two endpoints
maybe we can add support for multiple http port in the manifest?
so one subdomain go to a port for S3 and the other for the console.EDIT:
Just see that you post my same conclusion on the minio git discussion -
-
G girish referenced this topic on
