Bug 121234 - No GUI way for controlling postgresql startup options
Summary: No GUI way for controlling postgresql startup options
Status: CLOSED DEFERRED
Alias: None
Product: Fedora
Classification: Fedora
Component: system-config-services   
(Show other bugs)
Version: rawhide
Hardware: All Linux
medium
medium
Target Milestone: ---
Assignee: Nils Philippsen
QA Contact:
URL:
Whiteboard:
Keywords: FutureFeature
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-04-19 15:39 UTC by Mikael Carneholm
Modified: 2008-08-02 23:40 UTC (History)
0 users

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-09-19 13:33:59 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Mikael Carneholm 2004-04-19 15:39:57 UTC
Description of problem:
I miss a way to set startup options graphically (eg, if the postmaster
process should accept tcp/ip connections) for postgresql.
system-config-services allows to start and stop the service, but
there's no way to edit the options for the service (other than editing
eg /etc/init.d/postgresql).

I'd like to be able to right-click on a service in
system-config-services, choose "Options", and get a control panel
where I can check a "Accept external connections" checkbox (or
something like that). Of course, other options should be controllable
from that panel as well (such as port, logging, allowed hosts, etc)

Oh, and there should be similar control panels for other services as
well, functionality for starting and stopping (only) is a *bit*
sparse.. - maybe some plugin-architecture for s-c-s would be handy?
(eg, each service could provide it's own s-c-s plugin) I don't
understand why the linux community and distro providers start working
on a "system config standard", that specifies:

1. A standard tool / API for controlling services
2. A plugin architecture for that tool
3. A file format (DTD/XML?) that is readable by that tool

Or has this already been discussed? I belive however that much would
be gained from such a standard.

Version-Release number of selected component (if applicable):
7.4.2

Comment 1 Brent Fox 2004-04-27 18:54:19 UTC
Marking as a request for enhancement.

Comment 2 Nils Philippsen 2006-09-19 13:33:59 UTC
I don't think I'll find the time to do it in the FC7 timeframe, deferring.


Note You need to log in before you can comment on or make changes to this bug.