cockpit customization: UI, modules, etc
by Stefano Zamboni
Hi all
first of all thank you for this really impressive piece of code.
Premise:
I'm a contributor of Koozali SME server linux distribution
(http://www.koozali.org); ATM our distro is C6 based, but we (finally)
starting moving to C7
we need to rethink/redo our server manager (from here S-M) web gui and
cockpit come to our attention.
the idea is to use cockpit as a base for our S-M, but we need to know if
it supports some kind of customization.. we don't want to create "our"
cockpit, just enhance it via plugin, trying to stay adherent to the
upstream version
I have some question:
1) I know that branding is possible/quite easy, but, for example, I
didn't find any way to change the background color of the main bar, on
top of the page.. I see that all the style is inline.. is it a choiche?
is editing that code the only way to change colors/fonts and so on?
2) is there any way to "override" some features? for example, I'd like
to replace users' logic creation with mine; is it feasible? moreover, is
possible to disable/hide some elements (buttons or a single menu item in
the left bar)?
3) OTOH, is there an easy way to enhance an available panel with some
custom buttons/elements?
IIUC, supposing that only root will have access to cockpit, I can
override an existing module just creating a new one in
////root///.local/share/cockpit/ /dir.. am I right?
thank you in advance for your patience and attention.
Ciao
S.
8 years, 1 month
Re: Cockpit as systemd API test suite
by Stef Walter
CC'ing to cockpit-devel mailing list.
On 24.02.2016 13:57, Daniel Mack wrote:
> In Brno, we've briefly talked about using Cockpit as extensive systemd
> DBus API tester. I wanted to follow up on that idea, and prepared a test
> framework that runs on the CentOS CI infrastructure. This CI test is not
> yet linked to our GitHub project, but I'm working on that.
>
> The script provisions a host from a pool of bare metal machines with
> CentOS 7, checks out systemd from a given PR branch, builds it, installs
> it, and reboots the machine. Once it's back up, it SSHs back into it and
> then checks out and builds Cockpit. The bits related to Cockpit are here:
>
> https://github.com/systemd/systemd-centos-ci/blob/master/slave/cockpit.sh
>
> As you can see, I'm using a fork of cockpit here, which has one extra
> patch to disable 3 tests that failed in my test runs:
>
> https://github.com/systemd/cockpit/commit/750f8702
>
> Ideally, I would like to get rid of that and use the official upstream
> with a specific tag of course. Without this extra patch, however, a
> 'make check' based on the 0.95 tag results in the following log:
>
> http://zonque.org/cockpit-test-suite.log
Probably caused by running 'make check' as root. Can try and fix this,
or disable the test in that situation.
> Kerberos is certainly outside of the scope of what we want to test, so
> it might be a good idea to make such tests fail gracefully if the server
> can't be reached, or make them optional in some other way.
>
> In total, the script currently takes around 4 minutes, 45 seconds to
> complete. While that's not a whole lot, I wonder whether we can speed it
> up in some way by only building or running a subset of the cockpit code.
> After all, all we want to test is the systemd DBus API, everything else
> can be omitted. Is there a sane way to limit the tests to just this?
The first thing to note is that you're running the Cockpit unit tests.
These barely interact with systemd.
The integration tests are where the actual testing of cockpit features,
such as the systemd interaction happens.
Running the integration tests are documented here:
https://github.com/cockpit-project/cockpit/blob/master/test/README
To try this out, install the stuff documented at the top of the file.
And then you would do something like this. Run as non-root:
$ cd test
$ sudo ./vm-prep # only necessary the first time
$ ./check-verify # runs the entire test suite
But since you want a custom systemd, and not the entire test suite, you
would probably end up moving towards something like this:
$ TEST_OS=fedora-23
$ ./vm-reset
$ ./vm-download $TEST_OS
$ ./vm-install --quick
$ ./vm-customize -i systemd*.rpm # Or similar source of binaries
$ ./verify/check-system-info # Just one of the tests
You'll note that this is downloading an image (or in the former case) a
few images. Jan Scotka has been running this these tests with custom
images ... certainly possible. Update the link it the test/images directory.
Anyway ... you'll find that running these tests is a bit more complex
and involved. But this is where the real continuous integration stuff
happens.
Other projects are starting to run some of them to test various things,
and if there's big issues making them work, we can try and solve the
issues. Poke someone in #cockpit if you run into trouble.
Stef
8 years, 1 month
Download generated file, content-security-policy
by Marek Libra
Hi,
Does anyone know how to setup the content-security-policy to allow content generated by JavaScript to be downloaded in a similar way as a file?
Please have a look at the code bellow.
I would expect the download of "myFile.txt" with content "hello" starts when clicking on the link.
Unfortunately, Firefox 44 complains with:
Content Security Policy: The page's settings blocked the loading of a resource at data:plain/text,hello ("default-src https://192.168.122.101:9090 'unsafe-inline' 'unsafe-eval'").
Thanks for your help,
Marek
-----------------
maanifest.json:
{
"version": 0,
"tools": {
"mytest": {
"label": "cspTest",
"path": "csp.html"
}
},
"content-security-policy": "default-src 'self' data: https: 'unsafe-inline' 'unsafe-eval'"
}
-----------------
csp.html:
<html>
charset="utf-8">
href="../base1/cockpit.css" type="text/css" rel="stylesheet">
href="data:plain/text, hello" download="myFile.txt">Static content
html
8 years, 1 month
Weekly meeting
by Marius Vollmer
=================
#cockpit: meeting
=================
Meeting started by mvollmer at 14:01:46 UTC. The full logs are available
at
http://meetbot.fedoraproject.org/cockpit/2016-02-15/meeting.2016-02-15-14...
.
Meeting summary
---------------
* Agenda (mvollmer, 14:02:49)
* weekly images (mvollmer, 14:05:37)
* pcp/metric tests (mvollmer, 14:16:02)
* storage polish (mvollmer, 14:22:08)
* package updates (mvollmer, 14:26:42)
* issue handling (mvollmer, 14:30:51)
* LINK:
https://github.com/cockpit-project/cockpit/wiki/Feature:-Troubleshooting
(andreasn, 14:34:37)
* compressed test images (mvollmer, 14:35:51)
* open floor (mvollmer, 14:49:18)
Meeting ended at 14:53:05 UTC.
Action Items
------------
Action Items, by person
-----------------------
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* mvollmer (97)
* dperpeet (41)
* andreasn (28)
* zodbot (6)
* abhishekg5 (6)
* github (2)
* petervo (1)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
8 years, 2 months
Build failure on Ubuntu Vivid
by Jared Sutton
All,
I recently uploaded the current debian package profile for 0.92 to my
Ubuntu PPA. The upload for wily (Ubuntu 15.10) built correctly and is now
published. I uploaded the same source package for vivid (Ubuntu 15.04) and
it failed with the following test failures:
--- mock/ssh/1-output 2015-11-03 17:36:41.000000000 +0000
> +++ - 2016-01-21 04:30:56.392228214 +0000
> @@ -1,4 +1,4 @@
> 2048 FINGERPRINT authorized_keys (RSA)
> ssh-rsa
> AAAAB3NzaC1yc2EAAAADAQABAAABAQDpAQgUA3efyrzjxijOvvEPT4wtIk2GGVW8/Lw6tFa98yNpwT9xOZZnnyzlFwiCwjeBCqo8I7xwIPZVaoTb9yEuygUQj0FRi7CQfo6l63rgz3dXWMg09PYQgF3MX2Vo2fgMtsQgaZaHNJ+Mqew8Toe9dIQKup0gPrOw6mtAltmWUfDpDO33eljQV/BnjvHd3zoWw+EyJRUZ213FzfXnVVCOdY9sbIOT86rl6MpoGyCa+9OY6cSpVeFkCUwNplaYwGC4wBY74d0ZGI9GnSDEj1mU4XOSEWXSMFUxNcMkrIukZaNYzDYDsbgJJMy+M/DLfyrxQXpMe6MQQ5jhYXBm5NfF
> -2048 FINGERPRINT Comment Here (RSA)
> +2048 FINGERPRINT authorized_keys (RSA)
> ssh-rsa
> AAAAB3NzaC1yc2EAAAADAQABAAABAQDpAQgUA3efyrzjxijOvvEPT4wtIk2GGVW8/Lw6tFa98yNpwT9xOZZnnyzlFwiCwjeBCqo8I7xwIPZVaoTb9yEuygUQj0FRi7CQfo6l63rgz3dXWMg09PYQgF3MX2Vo2fgMtsQgaZaHNJ+Mqew8Toe9dIQKup0gPrOw6mtAltmWUfDpDO33eljQV/BnjvHd3zoWw+EyJRUZ213FzfXnVVCOdY9sbIOT86rl6MpoGyCa+9OY6cSpVeFkCUwNplaYwGC4wBY74d0ZGI9GnSDEj1mU4XOSEWXSMFUxNcMkrIukZaNYzDYDsbgJJMy+M/DLfyrxQXpMe6MQQ5jhYXBm5NfF
> Comment Here
> FAIL: pkg/users/test-list-public-keys.sh 1 mock/ssh/1-input
> PASS: pkg/users/test-list-public-keys.sh 2 mock/ssh/2-input
> --- mock/ssh/3-output 2015-11-03 17:36:41.000000000 +0000
> +++ - 2016-01-21 04:30:56.408036648 +0000
> @@ -1,2 +1,2 @@
> -2048 FINGERPRINT Comment Here (RSA)
> +2048 FINGERPRINT authorized_keys (RSA)
> ssh-rsa
> AAAAB3NzaC1yc2EAAAADAQABAAABAQDpAQgUA3efyrzjxijOvvEPT4wtIk2GGVW8/Lw6tFa98yNpwT9xOZZnnyzlFwiCwjeBCqo8I7xwIPZVaoTb9yEuygUQj0FRi7CQfo6l63rgz3dXWMg09PYQgF3MX2Vo2fgMtsQgaZaHNJ+Mqew8Toe9dIQKup0gPrOw6mtAltmWUfDpDO33eljQV/BnjvHd3zoWw+EyJRUZ213FzfXnVVCOdY9sbIOT86rl6MpoGyCa+9OY6cSpVeFkCUwNplaYwGC4wBY74d0ZGI9GnSDEj1mU4XOSEWXSMFUxNcMkrIukZaNYzDYDsbgJJMy+M/DLfyrxQXpMe6MQQ5jhYXBm5NfF
> Comment Here
> FAIL: pkg/users/test-list-public-keys.sh 3 mock/ssh/3-input
> PASS: pkg/users/test-list-public-keys.sh 4 mock/ssh/4-input
I'm not even sure I know what these test are doing, much less why
they're failing. Anyone shed any light?
Thanks,Jared
8 years, 2 months
