Hi cockpit developers,
I'm new to cockpit and working on creating a new plugin, which should enable oVirt users to install oVirt hosted engine through cockpit UI. I'm at the beginning of the project and trying to create a proper development environment. I'm using react and want to work with webserver I need a special configuration on cockpit side which I'm hoping you can help me with.
On my local env I installed cockpit and cloned the starter-kit, created a link to base1 directory, and added this script line to my index.html file: <script type="text/javascript" src="../base1/cockpit.js"></script> My app can import cockpit, now I need to configure cockpit to interact with a local running VM instead of my own PC. I want that the cockpit service which is running local on my machine connect to a cockpit bridge running on a local VM as a primary server, basically: [image: image.png]
The end result I want to achieve is that when I'm developing my plugin I will use webserver and only see the plugin windows (without the cockpit UI) and each interaction with cockpit will be triggered on a remote VM running cockpit, this way I will not have to refresh my page to see changes in the UI.
Can you help me understand the required configuration for cockpit ?
Hello Gal,
Gal Zaidman [2020-03-17 13:43 +0200]:
On my local env I installed cockpit and cloned the starter-kit, created a link to base1 directory
What do you mean by that? You don't need to create any links for base1 yourself. Cockpit's web server (cockpit-ws) knows how to find base1.
My app can import cockpit, now I need to configure cockpit to interact with a local running VM instead of my own PC. I want that the cockpit service which is running local on my machine connect to a cockpit bridge running on a local VM as a primary server, basically: [image: image.png]
There was no actual attachment, but it's fine. I suppose it looks like https://piware.de/gitweb/?p=talk-cockpit-auth-anywhere.git;a=blob_plain;f=ss... ?
You can do that by adding your VM as a remote server in the dashboard, then the local cockpit session will connect over SSH to the VM. You can also do that on the login screen directly in "> Other Options → Connect to".
Honestly I'd find it easier to just install cockpit-ws into the VM and directly point your web browser to the VM IP. But I guess you have your reasons, and remote ssh logins work just as well.
The end result I want to achieve is that when I'm developing my plugin I will use webserver and only see the plugin windows (without the cockpit UI)
This is unrelated to the local vs. ssh question, but you can also specify an URL that just shows your page's frame, instead of the whole thing: https://cockpit-project.org/guide/latest/embedding.html
For example, this only shows the Machines page:
http://your.server:9090/cockpit/@localhost/machines/index.html
Likewise, you can replace @localhost with @1.2.3.4 after you logged in (the URL will already contain the remote server part).
and each interaction with cockpit will be triggered on a remote VM running cockpit, this way I will not have to refresh my page to see changes in the UI.
You will still have to refresh the page. I. e. if you build your new code, scp it to your VM, then cockpit's web server and the remote bridge need to load it at some point. But a Ctrl+R is fairly cheap, you don't even lose your authentication, you just see your new page. (That's what everyone in the dev team is using, too)
HTH,
Martin
On Tue, Mar 17, 2020 at 6:37 PM Martin Pitt mpitt@redhat.com wrote:
Hello Gal,
Gal Zaidman [2020-03-17 13:43 +0200]:
On my local env I installed cockpit and cloned the starter-kit, created a link to base1 directory
What do you mean by that? You don't need to create any links for base1 yourself. Cockpit's web server (cockpit-ws) knows how to find base1.
My app can import cockpit, now I need to configure cockpit to interact
with
a local running VM instead of my own PC. I want that the cockpit service which is running local on my machine connect to a cockpit bridge running on a local VM as a primary server, basically: [image: image.png]
There was no actual attachment, but it's fine. I suppose it looks like
https://piware.de/gitweb/?p=talk-cockpit-auth-anywhere.git;a=blob_plain;f=ss... ?
You can do that by adding your VM as a remote server in the dashboard, then the local cockpit session will connect over SSH to the VM. You can also do that on the login screen directly in "> Other Options → Connect to".
Honestly I'd find it easier to just install cockpit-ws into the VM and directly point your web browser to the VM IP. But I guess you have your reasons, and remote ssh logins work just as well.
The end result I want to achieve is that when I'm developing my plugin I will use webserver and only see the plugin windows (without the cockpit
UI)
This is unrelated to the local vs. ssh question, but you can also specify an URL that just shows your page's frame, instead of the whole thing: https://cockpit-project.org/guide/latest/embedding.html
For example, this only shows the Machines page:
http://your.server:9090/cockpit/@localhost/machines/index.html
Likewise, you can replace @localhost with @1.2.3.4 after you logged in (the URL will already contain the remote server part).
and each interaction with cockpit will be triggered on a remote VM
running
cockpit, this way I will not have to refresh my page to see changes in
the
UI.
You will still have to refresh the page. I. e. if you build your new code, scp it to your VM, then cockpit's web server and the remote bridge need to load it at some point. But a Ctrl+R is fairly cheap, you don't even lose your authentication, you just see your new page. (That's what everyone in the dev team is using, too)
HTH,
Martin
Martin that a lot for the quick reply, 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. 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
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.
cockpit-devel mailing list -- cockpit-devel@lists.fedorahosted.org To unsubscribe send an email to cockpit-devel-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/cockpit-devel@lists.fedorahoste...
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
cockpit-devel@lists.fedorahosted.org
-
Gal Zaidman -
Martin Pitt