Cockpit Devs:
As we talked about earlier, we need to expose more Linux users to
Cockpit. As such, I wanted to let you know about a few upcoming
conferences which are heavily patronized by Linux admins and would be a
good place to start:
Usenix LISA https://www.usenix.org/conference/lisa17
Deadline Monday, April 24, 2017, 11:59 pm PDT
Open Source Summit (was LinuxCon)
http://events.linuxfoundation.org/events/open-source-summit-north-america
Deadline May 6, 2017
Open Source Summit Prague
http://events.linuxfoundation.org/events/open-source-summit-europe
Deadline July 8, 2017
... there will be others as the calendar progresses (as well as
Meetups). If anyone is interested in presenting to external audiences
about Cockpit, please let me know ... I can help with reviewing
conference submissions, travel funding and more.
--
--
Josh Berkus
Project Atomic
Red Hat OSAS
Hi!
We're organizing a Cockpit workshop in the two days preceding All
Systems Go! conference [1] in Berlin — on the 19th and 20th of October.
The idea is to bring the Cockpit community together to help each other
out in various areas relating to Cockpit. For example, getting started
writing a module, tackling beginner tasks, or understanding Cockpit's
general architecture.
If you're interested, please let us know (either on this list or to me
directly) that you're planning on coming and which topics you'd like to
learn or teach about. This will help us to plan accordingly.
Also, spread the word if you like the idea!
Cheers
Lars
[1] All Systems Go! is the more broad successor to last year's
systemd.conf:
https://all-systems-go.io/
The use of 'unsafe-inline' or 'unsafe-eval' or '*' in the
Content-Security-Policy lines of manifest.json files is the equivalent
of 'setenforce 0'.
http://cockpit-project.org/guide/latest/packages.html#package-manifest
It's not okay to disable this security measure for code included in the
Cockpit codebase. This security measure prevents XSS, code-injection and
other security attacks.
https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP
To bring this closer to home, the following aren't allowed:
* onclick='...' attributes
-> Attach event handlers from javascript instead.
* <script> ... </script> inline scripts
-> Include a script file rather than inline scripts
* <style> ... </style> inline CSS
-> Include this in your CSS file rather than inline
* style='...' attributes
-> Use your CSS file or javascript to set dynamic styles
* eval() or Function()
-> Never evaluate javascript directly
By default Cockpit will refuse to allow them in loaded pages or
javascript ... and we shouldn't use 'unsafe-inline' or 'unsafe-eval' in
the manifest.json file to bypass this.
I've added some testing so that such code in the Cockpit repository will
be detected.
https://github.com/cockpit-project/cockpit/pull/7391
Happy hacking,
Stef
Hello all,
TL;DR: casync is an interesting piece of technology, but doesn't work for our
current test images.
As I just merged another fedora-26 test image refresh, I took some time to
evaluate casync [1]. On my laptop I still have the old image (c75882fd), and on
my colo server (which has a really fast internet connection) I downloaded the
new image (554546f5).
The main tradeoff is the chunk size: smaller sizes increase the likelihood of a
particular chunk already being present locally, but increase the number chunks
that need to be downloaded. As this usually happens through HTTP, lots of small
files kill performance completely (mostly due to the usual TCP slow start
behaviour, but also due to the extra effort of making the connection itself).
The reference time on my VDSL-25:
$ time bots/image-download fedora-26
real 9m52.313s
This is still bearable, but it would be even more interesting to improve image
uploads (they take about 45 mins here).
First I created a casync index from the fedora 26 qcow image on my server, with
the the default option (64 kB chunk size):
server$ cd /path/to/testdir
server$ casync make fedora-26.caibx images/fedora-26-*.qcow2
Now on my laptop I use casync to get the new image, using as many chunks from
the previous one as a basis, plus the new chunks from my server:
$ casync extract --seed images/fedora-26-c75882*.qcow2 http://piware.de/tmp/cockpit-images-casync/fedora-26.caibx images/fedora-26-554546f5c12141c3bc2e92ba53564ad490f6974aea5f7df831ebcab563bf1b62.qcow2
This has to download thousands of chunks, each using one HTTP request: It took
slightly over 22 minutes. Oddly enough this didn't save the downloaded chunks
anywhere, so I'm unable to tell whether this actually saved any bandwidth.
Next I changed the average chunk size to 8 MB, and produced a new chunk store:
server$ casync --store 8m.castr --chunk-size=8M make fedora-26-8mb.caibx images/fedora-26-*.qcow2
Trying to download it fails:
$ casync -vv --store http://piware.de/tmp/cockpit-images-casync/8m.castr --seed images/fedora-26-c75882fdee8847229eb89707d41b4488286605fc9f150811a5d950b8a1399825.qcow2 extract http://piware.de/tmp/cockpit-images-casync/fedora-26-8mb.caibx images/fedora-26-554546f5c12141c3bc2e92ba53564ad490f6974aea5f7df831ebcab563bf1b62.qcow2
[...]
Chunk too large
Failed to acquire http://piware.de/tmp/cockpit-images-casync/8m.castr/6265/626515b391d445efc7…
Failed to run synchronizer: Broken pipe
OK, fair enough. Next attempt with 1MB worked, but took pretty much exactly the
same time as bots/image-download. Apparently there wasn't any actual saving,
the qcow images seem to differ too much in between image rebuilds.
Cross-checking with rsync over ssh (against the old image):
| 1,515,291,648 100% 2.68MB/s 0:09:00 (xfr#1, to-chk=0/1)
|
| sent 282,439 bytes received 1,479,233,072 bytes 2,712,219.09 bytes/sec
| total size is 1,515,291,648 speedup is 1.02
Maybe there is some trick ("sort" the blocks on the file system or so) to make
qcow files rsyncable better. But in conclusion, right now this delta approach
doesn't buy us much.
Martin
[1] http://0pointer.net/blog/casync-a-tool-for-distributing-file-system-images.…
Hello all,
This is Devyani Kota, part of the RHGS team at RedHat, currently
contributing
to the Gluster storage plugin for cockpit-ovirt.
We have created a few mockups for the same, that are attached along with the
mail. We plan to add the 'Gluster' info under the Storage Tab listed on the
overview page.
Under this "Gluster" Tab, we will be listing:
1. The information of the hosts in the cluster, labelling the host machine
which is the hosted-engine.
2. The volumes on every host, and their respective info like, the device
that
they are mounted on, the size of the disk that they occupy, etc.
The mockups listed give a clear picture of the concept, and a simple
overview
on what we are trying to achieve.
Any reviews/suggestions on the same will be appreciated :)
Looking forward to the feedback.
Thanks and regards,
Devyani Kota.
--
Devyani Kota
[image: https://]about.me/devyanikota
<https://about.me/devyanikota?promo=email_sig>
Hi everyone,
Over the last couple of weeks I've been learning about Cockpit internals, and
hacked together a little proof-of-concept page listing and playing back user
sessions recorded with tlog [1]. Here is a little demo of it I recorded:
https://youtu.be/BPiqFKvW0q4
And here's the code:
https://github.com/Scribery/cockpit/tree/hacking/pkg/session_recording
The POC has absolutely minimal functionality and is not pretty, but it proves
we can record sessions to systemd journal, and list them and play them back.
Tlog-rec-session (a part of tlog) logs a recording as a series of messages,
with several extra journal fields attached to allow for filtering all or
specific recorded sessions from the rest of the journal log. Cockpit goes
through journal extracting all tlog messages to collate a session list. When
asked to playback a session, it starts tlog-play (another part of tlog) on the
host, specifying how to extract session messages, connects it to a terminal
emulator in the browser, and lets it play.
Next, me and Kyrill are going to work on verifying we can implement the rest
of the required core functionality [2] with this approach, learn more about
Cockpit, and prepare a design as required by Cockpit team [3]. We will also
see if we can make this into an out-of-tree package for Cockpit.
We would appreciate any comments you might have, be it on the architecture,
the code, or the way you think it should look!
Thank you.
Nick
[1] Tlog - Terminal I/O logger
https://github.com/Scribery/tlog
[2] User Stories for Session Recording Playback
https://github.com/Scribery/meta/blob/master/playback_ui_user_stories.md
[3] Hacking on Cockpit - Contributing a Change
https://github.com/cockpit-project/cockpit/blob/master/HACKING.md#contribut…