Just wanted to see if anyone has made any lead way with supporting
CentOS/RHEL 6.7 via a bridge / agent so these os releases can be brought
into cockpit for resource / servcice monitoring
I know about 8 or 9 months ago this was talked about but not sure if anyone
has taken it upon themselves to come up with a solution yet or if there is
one in the works.
Let me know as we still have a few hundred 6.7 clients hosted in our cloud
and it will take a very long time to safely migrate them if even possible
to a 7.x release.
Donald R. D'Avanzo Jr
*Chief Technology OfficerRed Rock Tech LLC. / Sin City Cloud*
*Office:* (702) 660-1500 | *Direct:* (702) 302-9432
*9205 West Russell Road,Suite 240 | **Las Vegas, Nevada 89148*
(Had to put these together by hand, since the urls meetbot gave me at
the end of the meeting were gone...or something like that... got a 404)
Cockpit weekly IRC meeting 2015-11-30
* External channels
* OpenSCAP container support
andreasn #startmeeting Weekly cockpit meeting 2015-11-30
andreasn did that work I wonder
zodbot Meeting started Mon Nov 30 14:03:14 2015 UTC. The chair is
andreasn. Information about MeetBot at http://wiki.debian.org/MeetBot.
Useful Commands: #action #agreed #halp #info #idea #link #topic.
The meeting name has been set to 'weekly_cockpit_meeting_2015-11-30'
andreasn yup, just slow bot
mvollmer .hello mvo
stefw .hello stefw
zodbot mvollmer: mvo 'Marius Vollmer' <marius.vollmer(a)gmail.com>
stefw: stefw 'Stef Walter' <stefw(a)redhat.com>
andreasn: andreasn 'Andreas Nilsson' <anilsson(a)redhat.com>
dperpeet .hello dperpeet
zodbot dperpeet: dperpeet 'None' <dperpeet(a)redhat.com>
andreasn #topic Agenda
* External channels
andreasn * OpenSCAP container support
mvollmer * Debian
andreasn all right
#topic External Channels
mvollmer stef has been doing great work on the "external channels"
propmted by the sosreport download feature
mvollmer now we can open channels just from a GET request with a
stefw, would you like to add?
stefw the GET request uses a CSRF token
which is sent via the WebSocket in the "init" message
i tried different approaches for these external channels
stefw and this one ended up making the most sense
mvollmer i have changes the sosreport code to use this, and it works
anything else on that subject?
mvollmer review is ongoing, hopefully can be merged very soon.
so I changed sosreport to use external channels. :-)
the removes the need to add a file server
now we just open a superuser fsread1 channel
works very well after stefw helped me remember the "binary" option for a
stefw should that be the default for external channels?
dperpeet has disconnected (Ping timeout: 246 seconds)
stefw it would be a bit unexpected
but may help things go better?
mvollmer i don't know...
or depending on the content-type?
stefw yeah, could be
if content type is set, then make it binary
mvollmer what other uses do we have for the external channels?
stefw well all the resource loading is actually external channels
and they do set binary by default
hmm, we should decide this before merging
changing the default later is nasty
or culd it be a per-payload default?
fsread1 is binary
fslist1 is not
let's discuss later
mvollmer andreasn, sosreport has "needsdesign"
I would say, let's not do profiles
andreasn all right
so regarding profiles, I looked into that
and made some mockups
but I ran into the hurdle that Fedora doesn't ship any profiles(?!)
but I could have gotten that backwards
mvollmer they are already inconsistent between f22 and f23 I think.
or rather, don't work on f23
let's bother about that later
andreasn yes, I think it would make sense as a version 2
andreasn I'll remove the label for now
mvollmer I'll look into this then.
andreasn and I'll keep investigating this situation with profiles
all right, next up
#topic OpenSCAP container support
mvollmer i have to check the integration test and make new images,
then sosreport should be ready again
andreasn so I went back to researching Atomic SCAP scanning a bit,
sketching things out and such
but I wonder when and when we need to develop that, if it's urgent and such
or if some other fire is more urgent
mvollmer not a fire, but what about rolekit?
andreasn I have a lot of design done on rolekit already, but I'm
revisiting those a bit as well
mvollmer is that in good shape from your point of view?
andreasn it's in like a half-good state maybe
andreasn so it would work, but could be better
I'll do some more work on rolekit as well during this week
mvollmer I am thinking that I start with that towards the end of the
andreasn sounds good
andreasn #topic Debian
stefw has to go in 6 minutes
mvollmer let's do stef's topic
andreasn sure, what was that?
this old fight
stefw i'm trying to make progress in the direction of having them
replacable at *build* time
not at *runtime*
mvollmer yes, that makes sense
stefw so as a first step, i'm trying to move all deps into a sane
place (rather than copying them around our tree)
and trying to use unmodified upstream files
andreasn so that a distro could ship a certain patternfly version and
have us pick up that?
stefw this is also interesting for the image registry package i'm
andreasn (maybe a bad example)
stefw lets see how far we get
andreasn, well i would suggest we lock down the versions very specifically
stefw and the distro needs to ship that version (perhaps the dotted
point version can vary)
mvollmer i think we should still ship 'known good' versions in the
stefw mvollmer, yes, we could do that
mvollmer but allow them to be replaced
stefw and i'm going to do that for the bower dependencies
mvollmer so that we can point fingers
andreasn newer patternfly could break an older cockpit theoretically
stefw 1. the nodejs devel dependencies listed in package.json
2. the bower runtime dependencies currently controlled via 'make
i would like to continue to ship known good versions of the latter
in our git repo
stefw especially because then it makes development so much easier
andreasn, yes, and it has
we can be less stringent about the nodejs deps
even though those have broken our build in the past
but for the runtime bower dependencies we need to be quite strict about
versions, or we'll have a mess on our hands
so anyway, just a step in this direction
hopefully there will be a pull request soon
mvollmer it's more or less equivalent to patching configure.ac, no?
if you do it, you need to run some extra steps and need more builddeps
stefw yes, distros will need to place symlinks in the right places
so our build can find them
and then yes, many mor ebuild deps are need.ed
but if distros want to meddle
then they need everything
stefw the open question becomes
how can we guarantee that our tests catch the bugs?
likely we'll have to upstream their meddling ... in some way
so it's not a handsoff thing
lets see how it goes
dperpeet they can run our tests with their packages
it should be drop-in, basically
stefw has got to go
dperpeet our tests only expect cockpit running on the system, they
don't care where it comes from
mvollmer let's see
stefw, see you!
dperpeet mvollmer, go ahead with Debian
I have been making good progress
some status here:
I'll continue with this
have to figure out network-manager and FreeIPA
and user synching might be a challenge
but it looks good
dperpeet nice work
5 tests failing
mvollmer a lot of work still to be done, of course
but we need help with that, I'd say
dperpeet I think we can leave storaged out of the picture for now
dperpeet and pick up the work when someone has it running on debian
mvollmer we still don't have a maintainer in Debian, right?
dperpeet not that I know of
mvollmer it's a good chunk of work
for a volunteer
about the PR itself
there is one big commit that adds support for Debian 8
and many small ones that tweak the tests and Cockpit in small ways
I would appreciate it if you could have a look at the PR
looks like a lot, but really isn't
mvollmer petervo, still here?
mvollmer petervo, Debian doesn't have ssh_set_agent_port
it's essential for ssh public key stuff, right?
petervo right so no key auth support
mvollmer can we do something about getting it into Debian?
aruiz has disconnected (Ping timeout: 260 seconds)
jfilak has disconnected (Ping timeout: 260 seconds)
mvollmer newer version? patch against upstream?
petervo it's probably a matter of upgrading libshh i can look into it
jsgrant has disconnected (Ping timeout: 260 seconds)
mhabrnal has disconnected (Ping timeout: 260 seconds)
mvollmer so, I don't feel like spendin 100% on Debian for much longer
andreasn probably makes sense
phatina has disconnected (Ping timeout: 260 seconds)
mvollmer but network-manager and freeipa need to be tackled
I should talk more to mbiebl etc
andreasn what was up with networkmanager?
mvollmer the tests fail, and I haven't bothered to check
also, the tests are pretty fedora specific
fedora and debian have different ways to configure the network
andreasn ah, but networkmanager itself is functional?
ahh, one more thing
installiong build dependencies during vm-create
right now, they are installed during vm-install
but I think I know how to do it
#topic open floor
since mvollmer is going to start looking at rolekit at the end of the
week, should we move it up one point on the roadmap?
(NFS client that is)
mvollmer I'd say yes
andreasn cool, I'll do that then
andreasn anything else?
did I go offline?
mvollmer i think we are done
andreasn__ hups, seems I dropped off
I'm a member of a team on storage which is trying to make storage more accessible to consumers.
Yesterday, there was a brief dicussion in the Project Springfield meeting of pyblk,
which is a sort of lsblk-like library.
We believe that the capabilities of pyblk would enhance the smart storage administrator's
abilities a lot.
I'm looking for feedback on how Cockpit might be able to use these capabilities, and
what Cockpit would require to make these capabilities accessible to it.
If you can, could you take a look at the whitepaper here:
We have discussed a lot of ways the info pyblk can generate could be served up to the
user. For example, we could attach graphs (or pointers to the graphs) to journal
entries. We could be more independent and instead have a facility to look up graphs by
means of time-stamps. We can present diffs of graphs of the state of storage before
and after a certain time.
What do you think of any of this? Please let us know.
On RHEL, the rhel-tools container has it. Not sure if Fedora or CentOS are carrying something similar.
Sent from Nine
From: Stef Walter
Sent: Nov 19, 2015 5:47 AM
To: Development discussion for the Cockpit Project; SGhosh
Subject: Re: Cockpit 0.83 and 0.84
On 19.11.2015 11:34, Subhendu Ghosh wrote:
> Nice work on SOSreport.
> Would be interesting to support SOSreport inside a container on atomic host.
Is there such a container? If so, it would be simple matter of changing
the command to do something like 'atomic run soscontainer --arguments'.
Is that right Marius?
> *From:* Stef Walter
> *Sent:* Nov 19, 2015 5:27 AM
> *To:* Development discussion for the Cockpit Project
> *Subject:* Cockpit 0.83 and 0.84
> This is a summary of the Cockpit weekly releases. Over the last weeks
> there was was 0.83 and 0.84
> Building Cockpit on Debian
> At systemd.conf Dominik worked with Michael Biebl one of the Debian
> systemd maintainers on packaging Cockpit for Debian. We're still looking
> for a maintainer long term.
> Cross Distro Integration Tests
> In Cockpit we run hundreds of tests on real operating systems for each
> pull request. Without running these tests on an OS it's impossible to
> know that the features of Cockpit actually works.
> So far we've been running these tests on Fedora, Atomic, and RHEL. But
> we'd really like to run them on Debian as well. That'll make Cockpit
> much more well rounded.
> Marius worked on the first steps toward this, doing the Cockpit build
> inside of our test VM images:
> Hopefully we'll see more progress on this.
> SELinux certificate file type
> The cockpit.service helpfully sets the appropriate user and group on the
> certificates that cockpit-ws will use for TLS. Now it also sets the
> SELinux file context type properly, so this is one less things to break
> for an admin.
> Cockpit manual page
> There is now a 'man cockpit' overview manual page that links to the
> guide and elsewhere.
> Marius has done work on an SOS reporting view. Needs some further
> backend work, but should be ready soon:
> Peter has mostly completed the work to add machines with alternate
> users, and non-standard SSH ports. Among other things, this is useful
> for cloud instances. I'm looking forward to seeing this in Cockpit 0.85.
> Pull request: https://github.com/cockpit-project/cockpit/pull/3018
> There's lots of other work in progress. You can see it here in the
> Design and Implementation columns:
> Get it
> You can get Cockpit 0.84 in Fedora 23 or Fedora Rawhide:
> Or via COPR for CentOS, RHEL, and earlier versions of Fedora:
> Or download the tarball here:
> cockpit-devel mailing list