Support different base/config directories about teddycloud HOT 16 CLOSED

On unix systems, we may start searching in /etc/teddyCloud/

Actually it would be /usr/local/etc/teddyCloud

from teddycloud.

And while I'm reading, I think #112 is already the first part of this issue solved 👍

from teddycloud.

I would suggest to make the default configurable at compile time (for data and for config), and then have an option like suggested to use another config file. One might want to quickly test changes by copying the config.ini to a config2.ini or whatever to test some temporary changes. Not sure if there is a use case for changing the data dir at runtime. Maybe if you'd want to run different instances at the same time?

from teddycloud.

At compile time is a good idea, just setting a compiler-var to override the default set in the Makefile.
The data dir can be set in the configfile itself, so I see no need to override it, if you can override the configfile.

from teddycloud.

The data dir can be set in the configfile itself

Ah nice, didn't know that! Haven't been looking too hard tbh

from teddycloud.

use /usr/local/etc/teddycloud as base dir for data/config/certs if exists.
fix path for symbolic link

With those commits, /usr/local/etc/teddycloud will be checked for existence and if so the internal (relative) paths will be rerouted to that location.
A cli option is missing, but overriding BASE_PATH can set this path to a custom location.

from teddycloud.

Oh wow, you guys are incredibly fast! I don't think you need /usr/local/etc/.. for the container though. You could either go with what you had or use /etc/, as this seems to be the standard for Linux (don't take my word for it, haven't done much on Linux for some time). I'll go and fork your dev branch. If I come up with something I can sen you a change request.

from teddycloud.

Just read, that /etc is for mostly for system related thing, so went for /usr/local/etc as it was also existing. I added /etc as an alternative option, for the container it will shorten the path a bit.

I added it to the container for one reason: have an absolute config path, so you can call the teddyCloud executable not only from /teddycloud

from teddycloud.

Ah yes, I totally agree! Having an absolute Path is exactly what you want.

from teddycloud.

@SciLor is it possible that the workflow for change requests is slightly broken? There seem to be issues that I think are not related to my changes. #108

from teddycloud.

The workflows don't run until the end, if the user is not allowed to push the docker image. So it fails at this point and cannot do the smoke test. (I currently have solution for that).
But as long as the zip generation workflow is fine (and the docker based workflows are running to this point) this is fine, as the bills itself is working.

from teddycloud.

@SciLor with the current develop branch I'm good to go. My port is installing and running fine, with everything where it should belong. What is your current release cycle? I had to create my own release on my fork, but don't want to use that as a base for the port.

from teddycloud.

We do releases, as soon as the current develop branch made some progress, has some changes that fix critical bugs and is tested well.
We can do a release at any point. If you need one for clean progress, we can create a new one ..

from teddycloud.

A new release would make me very happy at this point :)

from teddycloud.

Thanks heaps @SciLor ! Now it's just waiting: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276541

from teddycloud.

done with the enhanced cli

from teddycloud.