Fedora Server Role D-BUS API Design Discussion
by Stephen Gallagher
-----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-meeti...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlMpn+gACgkQeiVVYja6o6Ou5wCeJw5zELa1zwLj++EBf66PKMKh
z6EAn1MOkhPQhY4bj9afTy1of68/QhXR
=xz9N
-----END PGP SIGNATURE-----
10 years, 1 month
SCAP support in cockpit-project
by Martin Preisler
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/us...
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
10 years, 1 month
Re: Call for votes: Server Technical Specification
by Stephen Gallagher
-----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-----
10 years, 1 month
