cockpit-devel March 2014

cockpit-devel@lists.fedorahosted.org

6 participants
4 discussions

Patternfly
by Marius Vollmer 25 Mar '14

25 Mar '14

Hi, the port to Patternfly is now on master! Hurrah! :-) I have updated the demo machines: https://209.132.178.141:21064/ Login: fedora / foobar Feedback welcome!

2 1

Fedora Server Role D-BUS API Design Discussion
by Stephen Gallagher 20 Mar '14

20 Mar '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 During this week's Fedora Server Working Group meeting[1], we started planning out how we want the public D-BUS API to look. I volunteered to take the discussion to the list so we could start hashing it out with a wider audience. I'm CC-ing the cockpit-devel list since a lot of this will affect that project, but I'd prefer to keep replies on server(a)lists.fedoraproject.org please (easier to track on one list). Some pre-conditions/goals (many of these are reminders from earlier discussions): 1) We want to be able to support two initial clients of this API: the Cockpit management console and a local command-line tool (I've been tentatively calling it 'fedora-role-manage') A third, future option will be to also support remote access to this API via the OpenLMI Project. 2) We do not need to have a single generic API that will work for any conceivable Role. We've identified in the past that the selection of Featured roles will (for the conceivable future) remain a small, manageable list. For this reason, it is acceptable for the deployment and post-deployment configuration APIs to be entirely different between two roles. However, some functionality such as the backup and firewall queries should be stable between all roles. 3) The supported clients should be able to determine if a target system supports the deployment of a particular role (for backwards- compatibility and architecture differences), but the Role API should *NOT* be attempting to dictate the UI experience. UIs should merely check whether the role is available and then use a previously- developed experience. We don't want to be reimplementing PAM or debconf here. 4) The D-BUS API must be stable. If it is likely that the set of input required to deploy or configure will change, this should be planned for in the design. 5) As it is not possible to plan for all contingencies, the API must be versioned such that the clients can determine whether they can properly perform the requested actions. Some initial thoughts on the matter (all are open to discussion): Standard Objects: /org/fedoraproject/server/ServerRoleManager: * properties: * all_roles: list of object references to Roles that can be installed and deployed * staging_roles: list of object references to Roles that have been pre-loaded but not yet configured * active_roles: list of object references to deployed Roles * version: API version * methods: # These properties and methods should be available and identical on # all Roles /org/fedoraproject/server/role/$ROLE: * properties: * version: API version * loaded: Bool: whether the packages are installed * deployed: Bool: whether the Role has been deployed * methods: * PreloadRole: Install all necessary software packages for default operation * GetFirewallPorts: list of port/protocol pairs that the Role needs open in the firewall * PrepBackup: method to invoke any necessary pre-backup steps (such as running a database dump to a file) * GetBackupFiles: list of filesystem path objects that identifies all data that should be copied by backup software # Individual Roles should have unique implementations of installation # and deployment e.g. /org/fedoraproject/server/role/DomainController * methods: * DeployPrimaryDomainController: Set up the first domain controller in the domain. * DeployReplicaDomainController: Add a new replica domain controller to the domain * AddCertificateAuthority: Add a certificate authority to this domain controller * EnableDisableDNS: Enable or disable the DNS server on this server == Open questions == 1) How do we handle configuring the Firewall? I think we want to have a Firewall object (/org/fedoraproject/server/RoleFirewallManager) available to query the firewall as a whole, but we may also want to be able to view and apply firewall rules from the Role objects directly. (Note: I'm not suggesting we need a complete firewall solution here. This should be a wrapper that deals only with the Roles). Firewalld already provides a more comprehensive firewall interface for the general case. I'm sure there are other questions we'll discover out there, but this email is already running long for an "introduction" to the topic. [1] http://meetbot.fedoraproject.org/fedora-meeting-1/2014-03-18/fedora-meeting… -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMpn+gACgkQeiVVYja6o6Ou5wCeJw5zELa1zwLj++EBf66PKMKh z6EAn1MOkhPQhY4bj9afTy1of68/QhXR =xz9N -----END PGP SIGNATURE-----

2 1

SCAP support in cockpit-project
by Martin Preisler 05 Mar '14

05 Mar '14

Hi, I would like to follow up discussions from devconf.cz regarding SCAP cockpit integration. For now I think we are better off starting with a very basic integration and building more on top in the future. There are talks about the future of SCAP results archival, diffing, etc. but right now we don't have anything ready to be used for this integration. Just scheduling a scan and getting a result file back is enough for this stage IMO. The following form "fields" are needed to perform a single machine evaluation: - Target machine - I assume this will be provided by the cockpit UI itself. - Content file - By default scap-security-guide will be selected. - Allow option to upload any content in datastream form (a single file). - Tailoring file - Optional - can be empty and ignored - Allow upload of a single xml file. - Can only be uploaded and processed after Content is uploaded. - Affects list of available profiles but can only add more profiles. - Checklist - Which Benchmark from given datastream will be evaluated. - In most cases there is only one Benchmark. - Select the first checklist by default. - Profile - There will be one or more profiles in any given benchmark. - Profile decides which rules are selected and which values are used for evaluation (password size, e.g.). - Select the first profile by default. By default when the form loads it will be populated with usable values. Scan can be performed immediately without any manual changes. After user submits the request to evaluation `oscap` will be run with parameters generated according to the form field values. Results can be collected as XCCDF results and displayed as HTML report (openscap provides tools to make HTML report from XCCDF result). I don't think it makes sense to implement customization / tailoring in cockpit, as well as "Save as RPM" and several other features from scap-workbench. Users can tailor in a separate application and then just use the tailoring file. Inspiration, prior work: 1) Spacewalk SCAP integration - http://isimluk.livejournal.com/1027.html - https://fedorahosted.org/spacewalk/wiki/Scap 2) scap-workbench - GUI application that allows people to scan local or remote machines. - install in Fedora : # yum install scap-workbench scap-security-guide - user manual: https://fedorahosted.org/scap-workbench/raw-attachment/wiki/UserManual/user… My questions are: 1) Can cockpit schedule future actions? Does it have cron-like functionality? 2) Does cockpit have means to schedule "actions" on multiple machines at once? Or do we have to implement this specifically for the plugin to get the functionality? Please let me know how to proceed. Should I make a graphical mockup of the GUI? I don't think I am the right person for that but I may try. -- Martin Preisler

2 1

Re: Call for votes: Server Technical Specification
by Stephen Gallagher 03 Mar '14

03 Mar '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/02/2014 09:58 PM, Máirín Duffy wrote: > Hi, > > > On 02/28/2014 01:55 PM, Stephen Gallagher wrote: >> If you have serious concerns, please raise them immediately. > > I'll +1 but my concerns are as follows: > > - The Accessibility section makes no statements about Cockpit's > a11y or required state of a11y; is the web ui designed in such a > way to be usable by those using screen readers? I've not used it > but with the general popularity if JS frameworks that aren't > necessarily screen-reader friendly it is a concern. This is a really good question, actually. I'm CCing the Cockpit development list to get a response from them. That being said, I think our accessibility efforts in the first release need to be "best reasonable effort". We want to support them, but we need to figure out where our limited resources are best spent in the short term. In the medium to long term, this becomes vastly more important. > > - Encryption - I think this was raised elsewhere in the thread but > we should probably have a section to talk about encryption support > (altho we missed this in PRD :-/) This would affect the filesystem > and install defaults specifications. > I'd actually be slightly in favor of leaving encryption support to the custom path, for several reasons: 1) Encrypting a filesystem means that startup/reboot cannot be handled unattended. Someone will need to provide a password (or insert security device, etc.) 2) Servers in the "pets" category tend to remain running all the time. Encryption is only useful when the drive has been removed from the machine. 2b) Even if the drive is encrypted only for theft protection, in order to accomplish unattended install, the admin will have to customize the mechanism they use to provide the decryption key, in which case they're likely doing a custom install of the filesystem anyway. 3) While much less so than it once was, encryption requires CPU time to be used on I/O, which is often wasteful in a server environment. So I'd suggest that Fedora Server recommends the use of LUKS for disk encryption and makes it available in the custom configuration path only. Thoughts? > - Appearance - ok maybe this is stupid but it would be nice to > have installed and configured by default a nice console font like > inconsolata or something like that with reasonable fallbacks for > i18n. > Perfectly reasonable. Mind if I phrase it as: "The Fedora Server team will consult with the Fedora Design Team to select a suitable console font." > - Backup - we talk about roles req lists of things to back up - do > we have a blessed backup system(s) we support tying into? > No, we've discussed that in the past. We don't currently want to try to dictate that (though in the future we may provide a Role for such a solution). At present, what we want to do is provide a programmatic interface for a backup solution to learn dynamically what we want it to back up (rather than requiring admins to maintain a whitelist themselves). -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMUfN8ACgkQeiVVYja6o6NLtgCgpflOWctFvpIxcfxN3eqDDhw1 dcMAn2/8CqGN5+KrVGzkqO1Rx1a4wuw0 =NOix -----END PGP SIGNATURE-----

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

cockpit-devel March 2014