So, a number of people have written to me to let me know that comments
don't work on the Server WG blog. I took a look at it today and
discovered the following:
1) Logging in with OpenID first seems to allow comments for me. I am
unclear on whether that's limited to admin users.
2) Disabling the WP-Spamfree plugin restores functionality.
I'm inclined for the time being to just set all comments to moderated
and disable the Spamfree plugin. Any opposition?
#fedora-meeting: Server SIG Weekly Meeting (2014-12-16)
Meeting started by sgallagh at 16:02:57 UTC. The full logs are available
* roll call (sgallagh, 16:02:57)
* Agenda (sgallagh, 16:07:53)
* Agenda Item: Database Server Role Design (sgallagh, 16:08:04)
* adamw will work on a proposal for defining/documenting server role
capabilities and requirements outside of the release criteria
* Database Server Role Design (sgallagh, 16:15:19)
* rolekit should support creating an admin account when creating the
DB, but stay out of user management otherwise (sgallagh, 16:32:09)
* AGREED: The Database Server Role will be built with a single local
process, with rolekit instances maintaining the databases within it.
(lazy consensus) (sgallagh, 16:37:28)
* If we select a graphical tool for managing PostgreSQL, it must be
able to manage user rights, replication and other system-level tasks
* A UI for SQL queries is a non-requirement (sgallagh, 16:44:04)
* Any UI we employ for the Database Server Role must be integrated
with Cockpit in some reasonable way (sgallagh, 16:47:07)
* Cantas (sgallagh, 16:54:36)
* LINK: http://cantas-fedoraserver.rhcloud.com/ (danofsatx-work,
* LINK: https://github.com/xychu/cantas ? (adamw, 16:56:15)
* LINK: https://github.com/onepiecejs/nodejs-cantas (sgallagh,
* Cantas authentication does not integrate with fedoauth (yet)
* Current authentication is only through Google or Kerberos.
* Fedora Infrastructure does not support Kerberos (sgallagh,
Meeting ended at 17:09:01 UTC.
Action Items, by person
People Present (lines said)
* sgallagh (117)
* simo (69)
* danofsatx-work (27)
* adamw (17)
* zodbot (12)
* hanthana (8)
* mclasen (4)
* kushal (3)
* mizmo (1)
* nirik (0)
* mitr (0)
* stefw (0)
* danofsatx (0)
* tuanta (0)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
Sorry for the late agenda folks. Currently, the only topic on my radar
is the Database Server Role. Anything else we should cover? This is
probably the last Server SIG meeting this year, as I expect a lot of
folks will be on vacation starting next week.
In an effort to make Fedora Server fully buzzword-compliant, I have
created a Trello organization and board for keeping tabs on the open
tasks we need to complete. This will help us visualize what work we want
to get done, who is doing it and whether it's blocked.
The new board is public and located at
https://trello.com/b/Cxf1YFs7/fedora-server and the organization is
located at https://trello.com/fedoraserver
The purpose of this Trello board is to track those high-level issues
that apply to the Fedora Server project as a whole. Tracking of
individual project-level implementation should continue to be done
within those projects.
I've added a few existing tasks that we have on our plate.
Members of the Server SIG: if you're interested in following along (and
ideally picking up and working on a few tasks), please create a Trello
account and email me with your ID so that I can add you to the
organization. If you are sitting on the Server WG, please consider this
to be strongly encouraged.
Intentionally breaking the thread here. I realize that my initial email
made a lot of assumptions, so I'm going to try to take this back to the
drawing board and have us identify the goals of the Database Server
before we attempt to define an implementation.
So first let's agree on the intention here: the purpose of a Database
Server Role is to provide a place for end-users to store data in an
SQL-compliant format. We (the Server SIG) consider this to be core
infrastructure functionality that will be needed by many (nee. most)
applications deployed in a user's environment.
Requirements from a user perspective:
* I must be able to create one or more databases for my
* I must be able to set up users with some level of privilege for
the individual databases
* My database must be able to speak some dialect of SQL
* I want to be able to use the same Fedora machine/VM for running
* I want to be able to replicate my databases between Fedora
* I want to have regular, automated backups of my databases.
By its very nature, PostgreSQL (and MariaDB and many others) can support
multiple databases running inside of a single service on a system. One
common approach to reducing resources is to host several such databases
on one physical or virtual machine (or cluster of machines), rather than
assuming the overhead of running an additional operating system to host
the database server.
On the other side of this, there are those who prefer to isolate their
databases entirely from one another, so that a flaw found in one cannot
escalate to revealing data about the others. There are generally two
approaches that people take to this these days. The most secure one is
to run the database on separate physical or virtual hardware. The
second, more recent approach is to run on the same node but inside a
different container environment (such as Docker or rocket). This
approach has its own advantages and disadvantages.
When we designed rolekit, we designed it to have the concept of role
"instances". Our first role, the Domain Controller, allows only a single
instance at present (because it really doesn't make sense to run more
than one Domain Controller on a single machine). However, as we see
above, it *may* in fact make sense to run multiple instances of the
Database Server Role through rolekit. There are several potential
approaches we could take:
1. We run a single database service on the local machine, using
PostgreSQL's built-in functionality. The first time a Database
Server Role is deployed on the system, it sets up the service
and then creates a rolekit instance associated with the specific
database on the server. This rolekit settings associated with
this instance will apply to that database only. The difficulty
of this approach is that rolekit will not be able to start or
stop the instances of the database separately. We will need to
start or stop them all together.
2. We run a single database service on the local machine with
multiple databases as above, but instead of using rolekit's
instancing technology, we treat it as a single role, with more
complicated deploy/redeploy settings that controls all databases
running on the system. This approach works around the start/stop
issue above, but it makes it more difficult to apply settings
(and creating a new database results in a redeploy call, which
would seem like an odd user experience).
3. We run multiple database services in individual containers on
the system. Each of these services is provided by a rolekit
instance and is a full, isolated copy of the PostgreSQL
processes. Each of these databases will need to operate on a
separate port (or the same port on separate interfaces, etc.)
4. We run multiple database services in individual Fedora Cloud VMs
that we spin up and kickstart into being and manage through
rolekit (talking to libvirt and OpenLMI on the VM). This is a
very complicated approach and will not be feasible in the F22
Option 4) above is actually kind of a special-case of 1) and 2) except
that we're managing the creation of a new VM (and need to add the
OpenLMI remoting capabilities). This might be an interesting project
down the road, but I think we can rule it out for Fedora 22 Server,
particularly with the slightly-shortened schedule.
Option 2) provides a workaround to certain peculiarities of how rolekit
works, but I personally don't think that the user-experience trade-off
is worthwhile. I'm open to arguments, of course.
So, from my perspective, Option 1) and Option 3) are the most
interesting. Option 1) is definitely the more traditional approach (and
probably easier to get up and running quickly), but Option 3) has a bit
of a security advantage at the cost of some additional management
difficulty. So this is the part where I end this email and ask for
feedback. Thank you for reading this far.
I'm looking into designing the plan for the Database Server Role (which
the Fedora Server WG previously agreed would be based on PostgreSQL).
One of the things we didn't really discuss in the PRD was whether we
would have a *requirement* for the Roles to have a GUI/WebUI management
console for configuring their services.
With the use of Cockpit for our top-level system GUI, I think it makes
sense that we would want to be able to have a link within Cockpit's UI
that takes us to the Role-specific web-based configuration tool. For the
Domain Controller, this link is obvious: it should go to the FreeIPA Web
For the Database Server, it's less clear-cut. PostgreSQL upstream does
not provide a "blessed" GUI/WebUI configuration tool for managing it.
Many exist and are provided by the project's very vibrant community. I
think we need to select one of these and consider making it a core part
of the Database Server role.
A (probably incomplete) list of potential tools are provided at
I'd like to recommend that for now we stick with one of the ones that is
already included in Fedora and are available via a web browser (not
requiring a desktop environment/X server). From a quick search, that
probably brings the list down to phpPgAdmin.
Does anyone on this list know of an alternative web-based tool that they
strongly prefer and would like to see us use (and possibly package, if
it's not already in Fedora)? I'd like to nail this down fairly soon.
My goal is to finish the design for the Database Server Role before the
holidays and spend January implementing it.
----- Original Message -----
> From: "Simo Sorce" <simo(a)redhat.com>
> To: "Stephen Gallagher" <sgallagh(a)redhat.com>
> Cc: "Server SIG" <server(a)lists.fedoraproject.org>
> Sent: Wednesday, December 10, 2014 3:26:54 AM
> Subject: Re: Database Server Role Design Considerations
> On Tue, 09 Dec 2014 09:50:06 -0500
> Stephen Gallagher <sgallagh(a)redhat.com> wrote:
>> I'm looking into designing the plan for the Database Server Role
>> (which the Fedora Server WG previously agreed would be based on
>> One of the things we didn't really discuss in the PRD was whether we
>> would have a *requirement* for the Roles to have a GUI/WebUI
>> management console for configuring their services.
> To be honest, while a Graphical UI of sorts would be nice I think we
> shouldn't have a requirement to have a WebUI/GUI to actually manage the
> We can allow to optionally install one maybe, but not require one, for
> one it would basically disqualify some roles because the great
> underlying software has no viable graphical UI, and it would also
> annoy admins that do not care for a webUI (unless it is part of the
> software on its own) and wants to maintain a small footprint.
I think GUI admin should not be mandatory for roles too. Of course, they
could be managed by Cockpit (start/stop/etc.) as usual.
This change could encourage people to make their own roles.
>> With the use of Cockpit for our top-level system GUI, I think it makes
>> sense that we would want to be able to have a link within Cockpit's UI
>> that takes us to the Role-specific web-based configuration tool. For
>> the Domain Controller, this link is obvious: it should go to the
>> FreeIPA Web UI.
>> For the Database Server, it's less clear-cut. PostgreSQL upstream does
>> not provide a "blessed" GUI/WebUI configuration tool for managing it.
>> Many exist and are provided by the project's very vibrant community. I
>> think we need to select one of these and consider making it a core
>> part of the Database Server role.
>> A (probably incomplete) list of potential tools are provided at
>> I'd like to recommend that for now we stick with one of the ones that
>> is already included in Fedora and are available via a web browser (not
>> requiring a desktop environment/X server). From a quick search, that
>> probably brings the list down to phpPgAdmin.
> I would not like to have phpPgAdmin "forced down my throat" to be
> honest. Mostly because of the php dependency which I try to remove on
> my servers on abysmal security grounds, but also because I do not think
> I would use a webui on the same DB server.
If it is still mandatory, we should consider another tool,because of not
only usability, but also security.
#fedora-meeting-1: Server SIG Weekly Meeting (2014-12-09)
Meeting started by sgallagh at 16:05:15 UTC. The full logs are available
* roll call (sgallagh, 16:05:28)
* Agenda (sgallagh, 16:08:46)
* Agenda Item: Select new WG member (sgallagh, 16:09:09)
* Agenda Item: Fedora 22 High-Level Planning (sgallagh, 16:09:19)
* Select new WG member (sgallagh, 16:11:04)
* Candidate: Dan Callaghan (sgallagh, 16:11:32)
* Candidate: Brandon Vincent (sgallagh, 16:11:32)
* Candidate: Dan Mossor (sgallagh, 16:11:32)
* Candidate: Danishka Navin (sgallagh, 16:11:32)
* Candidate: Michael J Wolf (sgallagh, 16:11:32)
* Reminder to all candidates: a seat on the Working Group is not
required to participate in the Fedora Server SIG (sgallagh,
* LINK: https://fedoraproject.org/wiki/User:Dmossor/ServerWG-persona
* The Server WG feels that Danishka Navin would be most helpful as a
teammate with tuanta at this time. (sgallagh, 16:39:20)
* The Server WG looks forward to working with Michael Wolf in the
Server SIG, but we feel that there was not enough information in his
self-nomination to make a fair determination for a seat on the
Working Group. (sgallagh, 16:41:50)
* The Server WG looks forward to collaborating with Dan Callaghan, but
without a certainty of being able to meet the time-commitment, we
will not give him the open seat at this time. (sgallagh, 16:49:16)
* AGREED: Dan Mossor (danofsatx) will join the Fedora Server Working
Group as a full member (+7, 0, -0) (sgallagh, 17:02:44)
* Open Floor (sgallagh, 17:03:35)
Meeting ended at 17:04:27 UTC.
Action Items, by person
People Present (lines said)
* sgallagh (103)
* simo (39)
* omzim (36)
* junland (27)
* danofsatx-kf (26)
* bvincent (23)
* danofsatx (17)
* tuanta (17)
* zodbot (15)
* adamw (11)
* stefw (9)
* nirik (2)
* masta (2)
* danofsatx-work (1)
* mitr (0)
* mizmo (0)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot