Meeting Summary / December 3, 2013

Dan Mashal dan.mashal at
Tue Dec 10 04:35:04 UTC 2013

On Mon, Dec 9, 2013 at 3:54 PM, Máirín Duffy <duffy at> wrote:
> Sorry for the lateness of this. I had a very busy week.
> Blog post is here:
> Copy/pasta below for your convenience:
> Agenda
> Our agenda was set ahead of time on the mailing list after an active
> discussion on the call for agenda post.
> - Adam Williamson Confirmation
> -  Discuss Role Implementation
> - PRD (we didn’t get to this topic)
> Members Present
>     sgallagh
>     nirik
>     mizmo
>     simo
>     adamw
>     mitr
>     Evolution
>     davidstrauss
> Adam Williamson Confirmation
> As discussed at last week’s meeting, sgallagh approached the Fedora QA
> team to seek a nomination for a new Server working group member to fill
> Viking-Ice’s vacated spot. Adam Williamson volunteered to fill the
> vacated seat. This was supported all of the by the seven present voting
> members with no disagreement, so adamw is now the newest Server working
> group member.
> Discuss Role Implementation
> This conversation was very dense and meandering, and after spending a
> couple of hours trying to turn it into a useful readable dialog I
> decided it’s going to be more valuable to just summarize it up,
> point-by-point. That summary follows.
> Cockpit
> stefw and andreasn participated in this discussion from the perspective
> of the Cockpit project – a server console UI. They have been thinking
> about “ways to make more advanced server roles (sorta like some of the
> wizards in windows) discoverable and accessible via cockpit. [To] have a
> nice way to configure one of your servers as a Freeipa server, for
> example, is a goal of ours. Or to have a way to configure a server as a
> monitoring server.”
> Server Role APIs
> There was some discussion about designing an API – stefw cautioned the
> group against designing a generic server role API from the bottom up and
> instead recommended looking at how people should interact with it first.
> sgallagh noted that OpenLMI could be a good abstract API to use.
> davidstrauss remarked that [cockpit?] seems to map to systemd and thus
> it isn’t generic.
> mitr pointed out that based on server list discussions:
>     UI is important
>     Automated installations are at least equally important.
>     One possibility that was suggested is to have a single
> ‘configuration’ for a role and to be able to ‘(re)apply it,’ i.e. not an
> API to change a value, but to remove/read a role with a new
> configuration (retaining data, of course).”
> simo is fine with enabling cockpit and OpenLMI, but isn’t sure it’s a
> good idea to have Fedora Server rely on them.
> Configuration
> Some suggestions that were brought up:
>     Move most of the package and operational config to post-installation
> so we can better support remote tools. (davidstrauss)
>     We should do as little configuration as possible by default, with
> the option for “advanced” knobs post-deployment. (sgallagh)
>     Install all packages, install config, and bring up a ‘standard’ (I’m
> not talking static. I mean, ‘ask for the minimum information necessary
> to reasonably install) config of the service, and then allow users to
> tweak after the fact. The way that most boxed server vendors work.
> (sgallagh)
>     Without a lot of info from the user up front (nirik)
>     It’s a spectrum from: just install the needed packages and user goes
> from there all the way to: install all packages, install config and
> bring up a ‘standard’ config of the service… (nirik)
>     For most networking services, config generally needs to be delayed
> anyway because you need hostnames and sometimes IP addresses to be the
> final ones, anyway. A lot of software can’t be correctly tweaked after
> install easily. (simo)
>     My vision of a ‘default install’ for a server OS would be basically
> Fedora’s current minimal. (adamw)
>     I would like to see minimum be truly minimal though. Not minimal for
> basic. but absolute bare-bones. (Evolution)
>     We could work with package maintainers to just have the package
> provide whatever default ‘standard’ thing to tweak out of the box? (nirik)
>     Should we ask at OS install time or at firstboot time? (simo)
>         That’s the part we need to figure out and the part that I was
> talking about having an ‘API’ for… To configure it for “default” use.
> I’m not committing to a complete configuration API right now. (sgallagh)
>     Basic configuration should be able to be performed by the installer
> or a management console like cockpit. (sgallagh)
>     stefw is hoping that openlmi will provide the scripting and cockpit
> the UI, and cockpit can use OpenLMI as appropriate.
>     Scripts are complex, but using scripts to manage configuration
> sounds like debconf, and it seems debconf is a model we’d like to avoid:
>         The scripts create a lot of maintenance overhead
>         It breaks automated config tools because of how its interactive
> configuration works
>         It starts things after installation, without using the config
> you wanted for initial startup.
>         It’s integrated with the packaging system. Package installation
> and configuration are two very separate steps.
> Even with the bulleted list approach above, you can see how this was
> kind of all over the place. :)
> Taking a Step Back
> I tried to come up with a rough long-term vision for how server role
> installation and configuration would work based on the discussion:
>     “When you install a role, it comes prepackaged with a set of sane
> defaults which you can configure post-install.”
> davidstrauss noted that it’s already 95% of the case. I asked how is
> this vision solving anything, and stefw said that sane defaults don’t
> come with many packages. “Fixing up software and packages so that
> they’re ‘roleable’ is a big part of this,” he also said.
> adamw also suggested,
>     “It sounds like we’re discussing some sort of distro-owned
> configuration/wizard/helper layer between the default configuration we
> set in packages and whatever configuration guides/tools the upstream
> software provides, which I thought was a business Fedora had been trying
> to get out of.”
> sgallagh explained,
>     “We want to behave more like Windows Server does here: If someone
> tells Server Manager that ‘that machine over there is a domain
> controller,’ it gives you a wizard to set up the basic information and
> then later allows you to tweak it further.”
> I brought up that I recently tried to set up postfix and it was a bit of
> a nightmare, and I wasn’t sure how you could configure it to run
> out-of-the-box when so much of the setup was specific to a given network
> / domain.
> “You cannot solve that problem w/o building something like kolab,” said
> simo. “I do not want to get Fedora in the business of building in
> tightly integrated roles, because we will fail.”
> simo, mitr, and sgallagh agreed that, for at least the short term,
> packaging only simple roles or existing integrated roles is something we
> should focus on, and we shouldn’t try to integrate non-existing roles.
> davidstrauss suggested using containers to allow tight integration
> between daemons. “[It's] easy to run into conflicts between how one
> ‘app’ wants DNS configured and another one does.” mitr disagreed with
> the container approach, though, “containers do pretty much nothing
> valuable to the user in this aspect – isolation is an aspect of
> reliability, not an end-user feature.”
> “I’m actually saying with the container stance that we should punt on
> the problem,” said davidstrauss. “I don’t think we’re equipped to do the
> integrated recipes.”
> There was some discussion about implementation – OpenShift gear recipes
> and docker were brought up.
> “I’m very anti-NIH. Proudly invented elsewhere should be a goal of
> ours,” said davidstrauss, and the whole group appeared to agree.
> Vision Statement
> Post-meeting, I expanded the vision statement for role installation
> based on the above discussion,
>         Roles will be maintainable objects in a repo managed with Fedora
>         maintainer standards, integrated & coherent for things like email
>         server, groupware, etc.
>         Users can select roles to add to a system, and would be provided
> with
>         a (wordpress first-run like) wizard for some initial information and
>         they’ll be given a working server using sane defaults.
> Optionally, the
>         user should also be able to deploy the role in a mass deployment
> without
>         having to interact with the wizard.
>         The configuration should be able to be modified post-install
> (but not
>         necessarily via GUI right away; it’s hard to commit to this.)
> How to move forward
> Generally everyone seemed to suggest that we need to choose 1-3 roles
> for the first release, and learn the best approach from exploring them.
> simo also suggested that someone needs to take a stab at proposing a
> clear view and provide a well-thought-out example. sgallagh volunteered
> to do this using FreeIPA as the example, which he has already posted.
> Meetbot Minutes

Thanks for the summary Máirín.

I like the idea of having UI based wizards for "roles" a la Windows
server. I think it's a great idea. I spend days at a time learning a
new "role" or often forget how to do something.. like getting a
website up in apache or nginx.. and then getting PHP working.
Constantly having to look at error logs and googling to see what I
forgot or how I messed up each time.

mitr made a great point in that UI will be very important here, and I
do think a common UI will be crucial. Another thing is that we don't
want to end up designing something like plesk or cpanel. They have bad
repuations for good reasons.

I really like the way Anaconda on RHEL/CentOS basically asked you
these sort of role questions in a way. But I didn't like how when I
chose an option there were like 75 sub options for something. Most of
which I didn't even know what they did.

I think we should put out some kind of "most common goals/objectives"
type of list together and a "most common type of configuration" list
together as well.

Here are some off the top of my head:

Networking config:
Primary IPs?
Additional IPs?
Written to config file for you. (Kind of like system-config-network)

Example role: web server
Question: nginx, lighthttpd, or apache?
PHP support? Y/N
Perl-CGI support? Y/N
Python support? Y/N
Create a site now? Y/N
Hostname of site? Y/N
Install SSL cert now? Y/N
"Site created! Config written."
"Want to create another site?" Y/N

Example role: Mail server
Question: postfix, sendmail, or qmail?
Smarthost (insert explanation of smarthost here)?

Example role: Database server
Question: Maria (MySQL), Postgresql, or MongoDB?
Create your first database now?
Configure backups now? Simple? Full?
Configure backup schedule now?

Example role: DNS server (this probably requires a GUI in itself..
windows GUI is great and should be looked at.)
Example role: High Availability/Clustering
Example role: Load balancer
Example role: Backup server/Dedupe box
Example role: Firewall
Example role: Build machine
Example role: Print services
Example role: File server/NAS (should support smb and nfs and can be
integrated with print services like Windows)
Example role: 389 Active Directory integration (aka server that syncs
with windows AD for linux AD authentication)

List of Windows Server 2012 roles:

Windows server also does further configuration of roles via role
services. For example instead of having a question for PHP support in
a webserver it can be done the way role services are done on Windows.

Screenshot of Windows DNS Manager GUI:

Windows does use a common UI in MMC for managing. From "computer
management" you can view logs, manage services, hardware, etc. etc.

So I guess the question really is "How far are we willing to go with
this" and "How much time do we want to spend on it?"

Regardless, I think these enhancements are a long time coming.


More information about the server mailing list