Writing cockpit extensions
by Jim Campbell
Hi All,
I think it is the case that all cockpit extensions need to be written in Javascript. Is that the case, or can they be written in other languages, as well (as long as they only use the Cockpit APIs)?
Thanks,
Jim
6 years
Cockpit Losing Connectivity
by Ryan McClung
Cockpit running on CentOS 7 VM currently monitoring ~5 hosts.
Upon logging out then back in the user needs to re-authenticate with each
host on the dashboard to have access to their resources.
Unsure what you need to troubleshoot as I am brand new. Thoughts?
6 years
Multiple Hosts Not A Lot of Time
by Ryan McClung
Hey All,
We are running an instance of Cockpit on a CentOS 7 vm. We have ~40
computers and we would like to add all of them to Cockpit. Is there a
faster method other than manually adding it to the ui?
6 years
Using cockpit over Apache HTTPD Proxy.
by Daniel Hilst Selli
I want to avoid the :9090 in the browser and, since I have Apache HTTPD
as a dependency of another tool in my stack I though about proxying
the
ports 80 and 443 to 9090.
I wrote this config based on some reads on internet:
<VirtualHost *:80 *:443>
ProxyPreserveHost On
ProxyRequests Off
ServerName myserver.com
ProxyPass / http://localhost:9090/
ProxyPassReverse / http://localhost:9090/
</VirtualHost>
When I hit https://myserver.com I see the cockpit's login page, but if
I try to login it just reload the login page as soon as I hit Log In
button.
I fired a journalctl in the server and found a timeout being reported
by cockpit-ws:
Apr 12 11:29:24 vydog.versatushpc.com.br cockpit-session[5924]:
pam_ssh_add: Identity added: /home/vhpc/.ssh/id_ed25519
(vhpc(a)vydog.versatushpc.com.br)Apr 12 11:29:24 vydog.versatushpc.com.br
systemd[1]: Started Session 21 of user vhpc.-- Subject: Unit session-
21.scope has finished start-up-- Defined-By: systemd-- Support: http://
lists.freedesktop.org/mailman/listinfo/systemd-devel-- -- Unit session-
21.scope has finished starting up.-- -- The start-up result is done.Apr
12 11:29:24 vydog.versatushpc.com.br systemd-logind[547]: New session
21 of user vhpc.-- Subject: A new session 21 has been created for user
vhpc-- Defined-By: systemd-- Support: http://lists.freedesktop.org/mail
man/listinfo/systemd-devel-- Documentation: http://www.freedesktop.org/
wiki/Software/systemd/multiseat-- -- A new session with the ID 21 has
been created for the user vhpc.-- -- The leading process of the session
is 5924.Apr 12 11:29:24 vydog.versatushpc.com.br systemd[1]: Starting
Session 21 of user vhpc.-- Subject: Unit session-21.scope has begun
start-up-- Defined-By: systemd-- Support: http://lists.freedesktop.org/
mailman/listinfo/systemd-devel-- -- Unit session-21.scope has begun
starting up.Apr 12 11:29:24 vydog.versatushpc.com.br cockpit-
session[5924]: pam_unix(cockpit:session): session opened for user vhpc
by (uid=0)Apr 12 11:29:24 vydog.versatushpc.com.br polkitd[546]:
Registered Authentication Agent for unix-session:21 (system bus name
:1.107 [cockpit-bridge], object path
/org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8)Apr
12 11:29:24 vydog.versatushpc.com.br cockpit-ws[4886]: logged in user
session
Apr 12 11:29:39 vydog.versatushpc.com.br cockpit-ws[4886]: session
timed outApr 12 11:29:39 vydog.versatushpc.com.br polkitd[546]:
Unregistered Authentication Agent for unix-session:21 (system bus name
:1.107, object path /org/freedesktop/PolicyKit1/AuthenticationAgent,
locale en_US.UTF-8)Apr 12 11:29:39 vydog.versatushpc.com.br cockpit-
session[5924]: pam_unix(cockpit:session): session closed for user
vhpcApr 12 11:29:39 vydog.versatushpc.com.br systemd-logind[547]:
Removed session 21.-- Subject: Session 21 has been terminated--
Defined-By: systemd-- Support: http://lists.freedesktop.org/mailman/lis
tinfo/systemd-devel-- Documentation: http://www.freedesktop.org/wiki/So
ftware/systemd/multiseat-- -- A session with the ID 21 has been
terminated.
Any idea on how to troubleshooting this? I fell like something is
missing in my httpd configuration. After login I
see the login page again as if the proxy was breaking the backend
redirect, ...
Regards,
6 years
Project for profiles and defaults for libvirt domains
by Martin Kletzander
Hi everyone!
First of all sorry for such wide distribution, but apparently that's the
best way to make sure we cooperate nicely. So please be considerate as
this is a cross-post between huge amount of mailing lists.
After some discussions with developers from different projects that work
with libvirt one cannot but notice some common patterns and workarounds.
So I set off to see how can we make all our lives better and our coding
more effective (and maybe more fun as well). If all goes well we will
create a project that will accommodate most of the defaulting, policies,
workarounds and other common algorithms around libvirt domain
definitions. And since early design gets you half way, I would like to
know your feedback on several key points as well as on the general idea.
Also correct me brutally in case I'm wrong.
In order to not get confused in the following descriptions, I will refer
to this project idea using the name `virtuned`, but there is really no
name for it yet (although an abbreviation for "Virtualization
Abstraction Definition and Hypervisor Delegation" would suit well,
IMHO).
Here are some common problems and use cases that virtuned could solve
(or help with). Don't take it as something that's impossible to solve
on your own, but rather something that could be de-duplicated from
multiple projects or "done right" instead of various hack-ish solutions.
1) Default devices/values
Libvirt itself must default to whatever values there were before any
particular element was introduced due to the fact that it strives to
keep the guest ABI stable. That means, for example, that it can't just
add -vmcoreinfo option (for KASLR support) or magically add the pvpanic
device to all QEMU machines, even though it would be useful, as that
would change the guest ABI.
For default values this is even more obvious. Let's say someone figures
out some "pretty good" default values for various HyperV enlightenment
feature tunables. Libvirt can't magically change them, but each one of
the projects building on top of it doesn't want to keep that list
updated and take care of setting them in every new XML. Some projects
don't even expose those to the end user as a knob, while others might.
One more thing could be automatically figuring out best values based on
libosinfo-provided data.
2) Policies
Lot of the time there are parts of the domain definition that need to be
added, but nobody really cares about them. Sometimes it's enough to
have few templates, another time you might want to have a policy
per-scenario and want to combine them in various ways. For example with
the data provided by point 1).
For example if you want PCI-Express, you need the q35 machine type, but
you don't really want to care about the machine type. Or you want to
use SPICE, but you don't want to care about adding QXL.
What if some of these policies could be specified once (using some DSL
for example), and used by virtuned to merge them in a unified and
predictable way?
3) Abstracting the XML
This is probably just usable for stateless apps, but it might happen
that some apps don't really want to care about the XML at all. They
just want an abstract view of the domain, possibly add/remove a device
and that's it. We could do that as well. I can't really tell how much
of a demand there is for it, though.
4) Identifying devices properly
In contrast to the previous point, stateful apps might have a problem
identifying devices after hotplug. For example, let's say you don't
care about the addresses and leave that up to libvirt. You hotplug a
device into the domain and dump the new XML of it. Depending on what
type of device it was, you might need to identify it based on different
values. It could be <target dev=''/> for disks, <mac address=''/> for
interfaces etc. For some devices it might not even be possible and you
need to remember the addresses of all the previous devices and then
parse them just to identify that one device and then throw them away.
With new enough libvirt you could use the user aliases for that, but
turns out it's not that easy to use them properly anyway. Also the
aliases won't help users identify that device inside the guest.
<rant>
We really should've gone with new attribute for the user alias instead
of using an existing one, given how many problems that is causing.
</rant>
5) Generating the right XML snippet for device hot-(un)plug
This is kind of related to some previous points.
When hot-plugging a device and creating an XML snippet for it, you want
to keep the defaults from point 1) and policies from 2) in mind. Or
something related to the already existing domain which you can describe
systematically. And adding something for identification (see previous
point).
Doing the hot-unplug is easy depending on how much information about
that device is saved by your application. The less you save about the
device (or show to the user in a GUI, if applicable) the harder it might
be to generate an XML that libvirt will accept. Again, some problems
with this should be fixed in libvirt, some of them are easy to
workaround. But having a common ground that takes care of this should
help some projects.
Hot-unplug could be implemented just based on the alias. This is
something that would fit into libvirt as well.
========================================================================
To mention some pre-existing solutions:
- I understand OpenStack has some really sensible and wisely chosen
and/or tested default values.
- I know KubeVirt has VirtualMachinePresets. That is something closely
related to points 1) and 2). Also their abstraction of the XML might
be usable for point 3).
- There was an effort on creating policy based configuration of libvirt
objects called libvirt-designer. This is closely related to points 2)
and 3). Unfortunately there was no much going on lately and part of
virt-manager repository has currently more features implemented with
the same ideas in mind, just not exported for public use.
We could utilize some of the above to various extents.
Let me know what you think and have a nice day.
Martin
6 years
