rolekit D-Bus API
by Thomas Woerner
rolekit D-Bus API
=================
org.fedoraproject.rolekit1
--------------------------
Properties
version:i # server role manager version
roles:ao # role objects list
Methods
getNamedRole(name:s)→o # get role by name
getRolesByState(state:i)→ao # get all roles with the given state
org.fedoraproject.rolekit1.roles.$name
--------------------------------------
Properties (general) # role settings
name:s (ro) # role name
version:i (ro) # role implementation version
state:i (ro) # deployed/started/inactive/dead?
packages:as (ro) # package list: packages and @groups
(similar to kickstart)
services:as (ro) # service list: services to be enabled and
started
firewall:a{sas} (ro) # firewall settings: ports and services
dict {
"ports" => array (
portid:s["-"portid:s]"/"protocol:s ),
"services" => array( name:s ),
}
ports are similar to firewalld port
definitions
firewall_zones:as (rw) # firewall zones to apply the firewall
settings to
custom_firewall:b (rw) # custom firewall: firewall settings will
not be applied if set to true
errorlog:s (ro) # errorlog string
#backup_paths:as (ro) # backup paths (files and directories)
# ... # role specific settings
Methods
start() # start the role (startServices,
installFirewall), fails if not deployed
stop() # stop the role (stopServices,
uninstallFirewall), fails if not started
restart() # stop and start
deploy() # deploy role (i.e. running initial setup
post-package-install, ipa-server-install)
decommission() # decommision (example: moved to another
machine, ipa-server-install -u ), stop if started
updateRole() # update role: yum update; restartServices;
updateFirewall
getFirewallZones() # get firewall zone list from firewalld, add
used ones to firewall_zones
Role States
===========
Nascent 0
Deploying 1
ReadyToStart 2
Starting 3
Running 4
Stopping 5
Decomissioning 6
Error 255
9 years
Multibooting UX, how well it ought to work
by Chris Murphy
This is largely directed to the WG, as a request to clarify a part of the workstation product tech spec. It relates to a thread on the anaconda list regarding os-prober, and a thread on this list regarding release criteria, both of which are referenced below.
I am cross posting to the server@ list as well, while they don't have a dual-boot requirement in their spec it stands to reason the ability to dual-boot Fedora Server/CentOS/RHEL version n and n+1 could come in handy when doing migrations while still having a fall back position. Perhaps replies should drop the other cross posting since the requirements for the two products are different? But I leave up to the person replying to decide.
The WorkstationTechnical Spec says:
"One aspect of storage configuration that will be needed is support for dual-boot setups (preserving preexisting Windows or OS X installations), since e.g. students may be required to run software on those platforms for their coursework."
1a. Does preserve preexisting include providing a working menu entry in the boot manager (e.g. in the GRUB menu)?
1b. Or is it sufficient to just preserve the installation data — meaning it's permissible for its bootability to be either non-obvious or broken?
2. If the answer to 1a. is yes, and 1b. is no, does this dual-boot requirement apply to both BIOS and UEFI?
3. If resources cannot meet the dual-boot requirement by ship time, should the installer inform the user that their previous installation will be preserved but may not be bootable?
4. Why is the preservation of an existing Linux OS, including a previous Fedora, not explicit in the spec? Should it be?
The answers to the above will help determine the scope of QA testing in this area, and avoid lengthy debate during blocker meetings. Maybe it'll provide some kick in the pants for old bugs with unimplemented solutions. Or maybe it will make it clear that the UX in this area doesn't need improvement and therefore effort testing and developing can be better spent elsewhere. So in any case, clarification will be helpful.
References:
"grub2, 30_os-prober, os-prober: A Proposal"
https://www.redhat.com/archives/anaconda-devel-list/2014-June/msg00020.html
Initial very rough Workstation release criteria draft
https://lists.fedoraproject.org/pipermail/desktop/2014-June/009931.html
https://bugzilla.redhat.com/show_bug.cgi?id=825236
https://bugzilla.redhat.com/show_bug.cgi?id=964828
https://bugzilla.redhat.com/show_bug.cgi?id=1048999
https://bugzilla.redhat.com/show_bug.cgi?id=1010704
Thanks,
Chris Murphy
9 years, 1 month
Proposal: Implementation of Server Roles
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I've finally gotten around to putting together my thoughts on how (at
a high level) the roles should be implemented. NOTE: this is
specifically about the Roles as a concept, not the implementation of
the logic within the roles, except for a couple restrictions I make on
input and output format.
Please see the design page I've written at
https://fedorahosted.org/rolekit/wiki/Design/RolePackaging and comment
on it here.
I will be the first to admit that the "First-Boot Configuration"
approach is a bit of a hack, but it's a hack that will work regardless
of installation during anaconda or a live system (it defers the
configuration step to a systemd unit that runs just prior to the first
start-up of the role). The implication here is strong: while the UI
that prepares the configuration may be interactive, the content fed
into rolekit is non-interactive.
Comments and clarifications requested.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlOi9v8ACgkQeiVVYja6o6NO+wCfXtPdDdb3nSkrooM+NCeoK4gw
JsUAn3j0jUtV8NDhAjuRzBaW2iF0A7LX
=7qj0
-----END PGP SIGNATURE-----
9 years, 3 months
Server File Diffs to Fedora Rawhide
by Stef Walter
So this may be obvious to some of you, but how do we handle the case
where installed files need to be different between Fedora Server and
other Fedora flavors?
For example for Cockpit to be installed by default we need to:
* Add the cockpit service to all relevant zone files in
/usr/lib/firewalld/zones (currently owned by firewalld rpm).
See 'man firewalld.zone' and 'man firewalld.service'
* /etc/pam/sshd needs an addition module, for Cockpit reauthorize to
work with added servers. See:
https://github.com/stefwalter/cockpit/blob/reauthorize/doc/reauthorize.md
... and likely others.
So I guess the question is how do we adapt behavior of rpms that are
installed both on Fedora Server *and* on other Fedora flavors.
Follow up question: How would I install Fedora Server today? What and
where are the diffs from the usual Fedora Rawhide represented? Is Fedora
Server still a completely theoretical construct at this point?
Cheers,
Stef
9 years, 3 months
Release criteria draft revised again
by Adam Williamson
I've revised the release criteria draft again, with reference to the
useful discussions both on-list and at this morning's meeting:
https://fedoraproject.org/wiki/User:Adamwill/Draft_server_release_criteria
I added the firewall exception for the Cockpit web interface, clarified
the issue about role deployment "at install time", and added new
criteria for the cockpit management interface to be running OOTB and for
roles to meet their "functional requirements, as defined in their role
specification documents" - role specification documents being something
I invented out of my ass at the meeting this morning. View that one as a
trial balloon. :)
As always, thoughts / comments welcome!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
9 years, 3 months
Soliciting agenda items for 2014-06-24 meeting
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
What's on the list this week, folks?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlOoFLQACgkQeiVVYja6o6NP7ACgsGOZyryQ98w59kz0SYU1fyCf
3aQAoKWurWBF20q92+5F1fbFxnz7hZRj
=ctII
-----END PGP SIGNATURE-----
9 years, 3 months
Fedora Server Test Day?
by Stef Walter
Does Fedora still have the concept of Test days? I followed the usual
links but couldn't find a list of Fedora 21 test days ... hence the
question.
If so, should we have a combined test day for Fedora Server related
things like Roles and Cockpit, or better separate?
Stef
9 years, 3 months
