Hello Gal,
Gal Zaidman [2020-03-18 17:38 +0200]:
I think that you have miss understood my intention, I aim to create
a
separate development environment which will use webpack-dev-server.
I don't want to login with cockpit UI,
I want the that the js will be served by webpack-dev-server and not
cockpit-ws (It will have to run in the background but I will not use
cockpit UI),
that is why I needed to link to base1 in the dev env.
I'm afraid this doesn't work. You *have* to use cockpit-ws if you want your
code to do anything with the base1 cockpit API, as the communication is done
over a websocket to the bridge. Any other web server does not do this.
You may be able to test some initial pure UI bits, but that won't get you very
far.
But there is really no reason to be afraid of cockpit-ws -- it runs
unprivileged, you can even start it as your own user with
/usr/libexec/cockpit-desktop (see its manpage). Yesterday I even sent a PR to
teach cockpit-desktop to start the bridge (i. e. the machine that you want to
look at in Cockpit) on a remote ssh host:
https://github.com/cockpit-project/cockpit/pull/13754
It didn't land yet, but it's trivial to apply the change locally. If you are
interested in this route, I can tell you the details.
You can still use things like `webpack --progress` to efficiently build your
pages, of course. You just need to symlink your build directory to
`~/.local/share/cockpit/yourproject, or scp it into your test machine
(depending on where you want to run cockpit-ws).
So I basically need to have what you cockpit-es --> cockpit
session -->
Remote machine bridge.
But I need to configure it with the CLI and not via cockpit UI, I know that
I can start cockpit service like a normal service with systemctl
I'm afraid I can't parse that properly. I still don't understand what exactly
you are trying to do. Perhaps take a step back and don't try to explain *how*
you want to do things ("CLI, "cockpit-bridge", "webpack dev
server"), but
*what* you want to do?
BTW one big reason that I don't want to refresh is that I'm
working with
modal on a process which runs ansible scripts which can take a lot of time
to execute and a refresh will send me back.
What is "modal" here, do you mean your UI opens modal dialogs that run Ansible
scripts? If merely reloading your page is so expensive, then I suppose you
should rather redesign it. Cockpit pages should not trigger long-running,
un-interruptible/resumable actions like that.
It might be easier if you say hello in #cockpit on Freenode, so that we can
discuss this more interactively?
Martin