Hi,
I would like to renew the effort on Host Devices for Cockpit [1].
To move forward, let's implement it step by step while opening brand new PR
picking just a subset of the already implemented functionality [1] while
adjusted to generally acceptable form.
Initial implementation would meet:
- PCI support only
- initially read-only: just the List of devices by their Class (according
to [2])
- example: by Audio device, Ethernet Controller, etc
- data source: sysfs
- make use of backward-compatible lspci for data preprocessing (especially
manipulation with HW database)
- monitor for changes by listening kernel uevents
Follow-ups will lead to [3] scope:
- for pci, active actions are allowed for selected device classes, one PR
per each:
- (un)bind VFIO driver
- configure SR-IOV network cards
- vGPU configuration
- additional view by Driver
- What devices is the driver bound to?
- additional view by IOMMU Groups
- For server fine-tuning, what devices are within single IOMMU Group?
- support for other buses, i.e. USB or SCSI
- their views are independent on each other due to fundamental differences
Please let me know your thoughts.
Thanks,
Marek
[1] https://github.com/cockpit-project/cockpit/pull/5523
[2] http://pci-ids.ucw.cz/
[3]
https://github.com/cockpit-project/cockpit/wiki/Feature:-Hardware-Devices
--
Marek Libra
senior software engineer
Red Hat Czech
<https://www.redhat.com>
Hi,
there's already an epic in trello related to Improved SELinux
troubleshooting and Management [1]. There seems to be missing a
user story for SELinux management so I put together a document which
should cover basic SELinux local policy management using either semanage
command or org.selinux DBUS interface:
https://plautrba.fedorapeople.org/manage-local-selinux-policy-in-cockpit.ht…
I'd like to ask you for a review and comments if it makes sense and for
help with design for this effort when there's an agreement
[1] https://trello.com/c/WiFrlt4C/381-epic-improved-selinux-troubleshooting-and…
Thanks,
Petr
After I have done running the diagnostic report, the blue "download report" button shows up.
But when I click on it, a popup windows asks me if I want to save the file"sos-report-hostname-20171026143147.tar.xz".
When I click "Save", the popup closes and well nothing else happens! No file is saved.
The browser does not show any downloaded file.
On the "System" tab, the version of the kernel (output of uname -r) should be printed along with "Hardware", "Asset Tag", "Machine iD", "Operating System", ...
Hello,
I have installed cockpit 151 on a F26 client and when checking the "Software Updates" on the cockpit server, it says "Updates are disabled. You need to re-subscribe this system."
When I click on "View Registration Details", it show a page with "Not found" on it.
I remioved the client and re-added it but still same problem.
https://imgur.com/a/ah6Hm
What can I do?
F.
Hello all,
https://hub.docker.com/r/cockpit/ has accumulated a lot of images, which is
confusing. I'd like to clean up the obsolete ones.
These are user-facing "products" generated by our release:
cockpit/kubernetes
cockpit/ws
These provide the bots:
cockpit/infra-base (base image for the following; NOT cockpit/base!)
cockpit/tests
cockpit/images
cockpit/release
These are unrelated to cockpit, I think they are from Lars. I guess "keep for now":
cockpit/system-api-test
cockpit/linux-system-roles-test
These are the old names for cockpit/tests and cockpit/release, and I believe
they can be removed:
cockpit/infra-verify
cockpit/infra-release
This (confusingly) is *not* the base image for the bots. Our test images have a
cockpit/base container, but this is built on the fly in *.setup from
bots/images/scripts/lib/base/ and thus something else. Last update was from two
years ago, based on EOL fedora 23. I believe this can be removed:
cockpit/base
Similar to cockpit/base, these were all pushed two years ago, neither cockpit
nor cockpituous have their Dockerfiles, and it's not even clear what's inside
or what their purpose is:
cockpit/infra-irc
cockpit/infra-guide
cockpit/infra-files
cockpit/infra-sink
Thanks,
Martin
Hi,
so recently I managed to destroy[1] two production servers by removing what
I saw as useless web-config utility. Apparently Cockpit depends on
NetworkManager, which nobody would expect and is easily overlooked.
PLEASE FIX
[1] https://cloud.rhea-ayase.eu/s/eH6JX43kYErHJ3s
Cheers,
Radka
------------------------------
*Radka Janeková*
.NET & OpenShift Engineer, Red Hat
*radka.janek(a)redhat.com <radka.janek(a)redhat.com>*
IRC: radka | Freenode: Rhea
Hello list,
my friends and I are working on an experimental configuration interface
based on Cockpit for the NethServer project [1]. So far we are really
comfortable with Cockpit and I hope we'll be able to contribute back in
some way.
Now I have a question about the API. file.close(), process.close() and
dbus/client.close(): should I call them carefully to release underlying
resources, or I need them only in special case (i.e. abort an
operation)?
[1] https://github.com/NethServer/nethserver-cockpit
--
Davide Principi
#davidep | @davideprincipi | GPG 0x5651EA71
Hello all,
Stef spotted and fixed a leakage of Cockpituous' GitHub token to public log
files [1] (e. g. [2]). I now generated a new token, deployed it to
cockpit-{7,11}, verifymachine{4,5}, and OpenShift, restarted all Pods, and
deleted the old token.
At first sight everything should be in order again, but please watch out for
error messages of tasks that indicate permission errors when talking to GitHub
-- the token might still hide in places that I'm not aware of.
Thanks,
Martin
[1] https://github.com/cockpit-project/cockpit/pull/7843
[2] https://github.com/cockpit-project/cockpit/issues/7838