Hi,
I would like to have following interfaces auto-connected for enonic snap
I work for Enonic and this is our CLI tool for managing and maintaining Enonic XP instances:
network – to be able to make HTTP requests to local Enonic XP instance
network-bind – Enonic XP is a web-based CMS system and CLI should be able to start and stop them locally
personal-files – for R/W access to $HOME/.enonic where we store data and configs
home – CLI can create projects from github hosted starters, and it can happen anywhere user can roam. In case this is not allowed for snaps I added interface to be at least able to do it in home folder.
There is no need to request auto-connection of home and network since these are auto-connectable by default already. For snaps, $HOME is already set to a private, per-snap home of $HOME/snap/<snap-name>/<snap-revision> (so that the snap version of an application is kept isolated and doesn’t interfere with a system-installed version of the same application) - so there should be no need to access $HOME/.enonic.
However, we often support use-cases of snaps being given read-access to such directories / files automatically so that they can import an existing configuration which might exist. Can you please outline any specific reasons why you feel you need access to this local directory?
Regarding network-bind can you explain more how this is used to start / stop local instances from the cli?
Thanks for explaining @alexmurray!
It’s my turn now
I believe that $HOME/snap/<snap-name>/<snap-revision> should work for us as long as cli doesn’t notice any difference between real home and snap home. The only gripe is that it will differ from mac’s homebrew and windows’ scoop behavior that don’t seem to have such confinement and we’ll have to outline that difference for linux users.
Read access is not enough as we store enonic XP server distros there and runtime data such as XP process id and session id.
And distros are the first cornerstone of CLI.
Here is the enonic XP repo which is basically a jetty-based web-server written in Java.
CLI is capable of downloading different versions from our repository and storing them in $HOME/.enonic folder.
Starting any of these versions boils down to invoking server.sh file bundled with that distro that starts the jetty server. Using cli it is possible to stop it at any time and start a different version that comes in handy for consultants working with different versions for different clients.
Vast majority of the commands available in cli make http requests to that running enonic XP instance using API.
The other cornerstone of CLI are projects.
Projects is a way to build plugins and web-sites for enonic XP (which is a CMS). They are usually cloned from github-hosted starters like this one, edited by consultants, and deployed to locally running enonic XP instance using cli.
The main concern here is: user should be able to create projects where he wants it.
As far as I understood it from the snap policies, this is not allowed by default. If that is the case, how can it be done ?
So the bottom line is, cli does 2 things:
downloads desired version of enonic XP server to $HOME/.enonic, starts it and makes http requests to it.
downloads project skeletons from github, saves them to a user chosen place, builds them and deploys to XP server.
Ok so since you are running enonic versions directly from the cli, they then run under the same confinement as enonic CLI and so hence why enonic itself needs network-bind.
Regarding where a user stores projects - the home interface provides full access to the users real $HOME (except for hidden . directories) so if a user stores their project in their home directory then that should suffice?
In that case, I vote +1 for network, network-bind and home and -1 for personal-files since it would seem that the snap version of $HOME for enonic should be sufficient as I understand it.
@alexmurray Yes, RW access to real HOME should suffice for storing projects there.
Storing .enonic inside snap folder would be fine if users didn’t have a need to access it, but the thing is they are aware of its existence and might have a need to edit enonic XP server configs inside it.
CLI downloads enonic XP servers into .enonic folder and when enonic XP server starts it reads environment config from the files that are inside that folder as well.
So from my point of view it would be much more user-friendly if we had .enonic folder inside user HOME as well if that is possible.
It is clear that enonic is the owner of the .enonic directory, however I agree with @alexmurray that $HOME/.enonic is already available and it isn’t clear why this must be the top level directory? Is this file managed by the enonic cli tool itself? Or put another way, how often are users expected to edit the config files by hand? How well does enonic handle forward and backward compatibility of its configuration? Eg, if a user installed a deb/rpm/etc of enonic and the snap at the same time, and they were different versions, could the snap break the deb/rpm/etc or vice versa?
Good question about the backward compatibility @jdstrand !
It helped me to realize an important fact that .enonic folder should not in any way be affected by enonic snap update and is intended to be shared across different versions and packet managers.
This is essential because we don’t want to download and config same versions of enonic XP servers every time we update version. It can all end up occupying quite a lot of space otherwise.
Same goes for rpm/deb/etc, .enonic is intended and is safe to be shared between them all.
There are checks to prevent starting two XP servers at a time.
And despite the way user installed enonic they expect to have same access to downloaded XP servers.
Thank you for responding considering forward/backward compatibility. The following questions still remain: “It is clear that enonic is the owner of the .enonic directory, however I agree with @alexmurray that $HOME/.enonic is already available and it isn’t clear why this must be the top level directory? Is this file managed by the enonic cli tool itself? Or put another way, how often are users expected to edit the config files by hand?”
Oh, sorry @jdstrand.
I though that my explanation rendered that question obsolete because snap home is bound to snap revision
and we can’t let it happen because $HOME/.enonic contents should be shared between versions and is independent of them.
Regarding your question: enonic snap is intended not for site end users, but rather for devops and consultants (people developing sites using enonic XP). Thus I’d say that they will definitely have a need to make changes to enonic XP server configs after they are downloaded by CLI. Later operations can add/remove features to enonic XP server by putting OSGI jars in a folder inside it. And although CLI provides means for deploying projects (web-sites) to enonic XP server, consultants will most likely do adjustments to projects on the fly.
3 votes for, 0 against for use of and auto-connection of personal-files with the interface name of dot-enonic. The snap declaration has been issued and the review-tools updated.
I put ‘read’ above, but it was always understood that write was needed and that is what I granted. Please adjust your snap to omit read and use write, like so:
Feel free to upload. There is a corresponding update to the review-tools that needs to be in production for this to pass automated review, but now that this is granted, I can keep an eye on the review queue for updates to the snap. I might take a week or so for this to be in production.
