Index | Thread | Search

From:
Stuart Henderson <stu@spacehopper.org>
Subject:
Re: Update to minio-0.20241107
To:
Daniel Jakots <danj@chown.me>
Cc:
ports@openbsd.org
Date:
Fri, 15 Nov 2024 09:34:47 +0000

Download raw body.

Thread
On 2024/11/14 21:03, Daniel Jakots wrote:
> On Sun, 10 Nov 2024 17:52:04 +0000, Stuart Henderson
> <stu@spacehopper.org> wrote:
> 
> > As long as it's not destructive to run the new version on an old
> > setup, I'd not do anything special with @pkgpath, let the old update
> > to the new as normal, and people can pkg_delete the new and add the
> > old if needed.
> 
> Yes it's not, it will only fail to start.
> 
> > I'd probably just add a MESSAGE or maybe even just an FAQ entry
> > rather than @ask-update as it should be easy enough to recover as the
> > old version is available. @ask-update stops non-interactive updates
> > from working.
> > 
> 
> so something like that?
> 
> Index: faq/current.html
> ===================================================================
> RCS file: /cvs/www/faq/current.html,v
> retrieving revision 1.1122
> diff -u -p -r1.1122 current.html
> --- faq/current.html	3 Oct 2024 00:53:36 -0000	1.1122
> +++ faq/current.html	15 Nov 2024 01:43:44 -0000
> @@ -56,7 +56,30 @@ use a snapshot to recover.
>  <p>
>  Most of these changes will have to be performed as root.
>  
> -<h3 id="r20240930">2024/09/30 - No entries yet</h3>
> +
> +<h3 id="r20241120">2024/11/20 - [packages] Removal of Gateway and filesystem modes in MinIO</h3>

I'd put the package name first for quicker reading, and mention
that it's just server:

<h3 id="r20241120">2024/11/20 - [packages] minio server: Removal of Gateway and filesystem modes</h3>

> +<p>
> +The last MinIO version supporting the MinIO is provided under the package
> +<tt>minio-old</tt>.

If you want to change the package stem you also need to deal with
making sure the packages conflict. Also it's a bit different to other
examples where we have multiple versions of a port in the tree.

Attached diff is a simpler approach keeping the same pkgstem, giving
this:

$ make show="FULLPKGNAME FULLPKGPATH"|paste - - - 
===> net/minio/client	minioc-0.20221022	net/minio/client
===> net/minio/server	minio-0.20241107	net/minio/server
===> net/minio/server-old	minio-0.20221024p3	net/minio/server-old

If some version is already installed, pkg_add -u will use the pkgpath
to find updates. So existing users of minio-0.20221024p2 (pkgpath
net/minio/server) will move to minio-0.20241107 without prompting,
and then receive further updates of net/minio/server without prompting.

If minio-0.20241107 is removed and minio-0.20221024p3 (new one with
net/minio/server-old pkgpath) is installed, pkg_add -u will then stick
with 0.20221024p*.

A plain "pkg_add minio" on a clean system will offer the choice of
minio-0.20221024p3 or minio-0.20241107.

> 1. should minio and minio-old conflict? To migrate to the SNSD mode,
> only the old version is enough, you don't need to have both.
> Otherwise if we don't set a conflict marker I'll rename the minio.rc to
> minio-old.rc I guess

Yes I think so.

> 2. what should be done for credentials? As pointed out in
> https://min.io/docs/minio/linux/reference/minio-server/settings/root-credentials.html
> 
> > If MINIO_ROOT_PASSWORD is unset, minio defaults to minioadmin.
> 
> currently I have
> /usr/ports/net/minio/server$ cat pkg/minio.login 
> minio:\
> 	:openfiles-cur=4096:\
> 	:openfiles-max=8192:\
> 	:setenv=MINIO_ROOT_USER=root,MINIO_ROOT_PASSWORD=yourstrongpassword:\
> 	:tc=daemon:
> plus a MESSAGE telling the user to update the password, should I go
> that way?
> or comment out the setenv line?

If you want to make sure that users do actually change it from the
default, you could check that in the rc.d script,

getcap -f /etc/login.conf.d/minio:/etc/login.conf -c setenv minio

I have not touched that in the minio/server part of the diff I've
included. And that could be done later.

I have made one change though: you presumably don't want this
password world-readable, so I have set the @sample'd login.conf.d
file to @owner root, @group _minio, @mode 640.

> or don't provide the minio.login at all and put it in the README? maybe
> it won't work well without the bumped limits so it will force the user
> to check it (and not use a default password)?

I don't know about minio, but a lot of software handles things very
poorly when it runs out of FDs. If it is likely to need raised FDs then
I would make sure it gets them.

And by providing the file, you can make sure it has sane permissions.