Request for auto-connection for enonic


#1

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.

Thanks in advance,
Pavel


#2

Here’s the CLI repo link https://github.com/enonic/cli-enonic
We use goreleaser for publishing so snapcraft config can be found in goreleaser.yml


#3

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?


#4

Thanks for explaining @alexmurray!
It’s my turn now :wink:

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:

  1. downloads desired version of enonic XP server to $HOME/.enonic, starts it and makes http requests to it.
  2. downloads project skeletons from github, saves them to a user chosen place, builds them and deploys to XP server.

#5

Doesn’t network-bind already auto-connect by default?

Also note that the home interface does not auto-connect on Ubuntu Core devices


#6

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.


#7

@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.