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
> >> 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. 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
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
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.