Database Server Role Design Considerations

Stephen Gallagher sgallagh at redhat.com
Thu Dec 11 16:05:48 UTC 2014




On Thu, 2014-12-11 at 13:33 +0100, Jozef Mlich wrote:
> On Wed, 2014-12-10 at 20:53 +0700, Truong Anh. Tuan wrote:
> 
> > >> 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.
> > > 
> > > 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
> > > role.
> > > 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.
> > 
> > +1 Simo.
> > 
> > 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
> > >> https://wiki.postgresql.org/wiki/Community_Guide_to_PostgreSQL_GUI_Tools
> > >> 
> > >> 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.
> > 
> > +1 too.
> > If it is still mandatory, we should consider another tool,because of not
> > only usability, but also security.
> 
> 
> Dear server list members,
> 
> I am not sure what are general requirements for those server roles and
> whether I can help in this discussion. I will try to follow whole
> discussion more carefully. 
> 
> In my opinion the phpPgAdmin is most frequently used web tool for
> PostgreSQL Databases management. 
> 
> However, the phpPgAdmin is focused on database content, but not its
> basic configuration. It is possible to manage large portion of its
> configuration via SQL queries. In Cocpit, I would expect configuration
> of port number, authentication method (pg_hba.conf), multiple instances,
> and other features described in our wiki[1]. As far as I know, there
> similar tool currently doesn't exists.
> 

Yes, I was unclear in my original email. Basically, I expect rolekit
(and Cockpit, through integration with rolekit) to manage the core setup
features of PostgreSQL. My intent here was to open a dialog about how to
manage content after the fact.

To use the example we already have, the Domain Controller role sets up
and deploys the FreeIPA system, but we expect users to use the FreeIPA
web UI to create users, manage hosts, etc.

> I would like to point out also to Open PostgreSQL Monitoring Tool [2]
> which could provide some of required functionality.
> 

Hmm, interesting (and certainly more modern-looking). I guess I probably
should have asked in the first place: What sort of configuration tools
do people use on PostgreSQL? To solve what problems?

> Don't hesitate to contact me or my colleagues from databases team (in
> cc) for further discussions. Personally, I had to plan vacation near to
> end of the year, but I will try to read the email.

Thank you, we will certainly do so.


> 
> [1] http://fedoraproject.org/wiki/PostgreSQL
> [2] http://opm.io/
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://lists.fedoraproject.org/pipermail/server/attachments/20141211/202cc18e/attachment.sig>


More information about the server mailing list