Re: Thoughts on the location of configuration files
От | Lamar Owen |
---|---|
Тема | Re: Thoughts on the location of configuration files |
Дата | |
Msg-id | 200112190347.WAA28447@www.wgcr.org обсуждение исходный текст |
Ответ на | Thoughts on the location of configuration files (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: Thoughts on the location of configuration files
|
Список | pgsql-hackers |
On Tuesday 18 December 2001 05:24 pm, Peter Eisentraut wrote: > After reading through the strong opinions about the location of the > configuration files in the current and in previous threads, I must concede > that despite the best intentions, the current "everything in one place" > system is obviously not addressing the needs of the user. So while we're > at it we might as well consider more sweeping changes to bring the > system in line with the "expected" or "standard" behaviour. > Surely we can also add a -C option to override the sysconfdir just as -D > overrides localstatedir. Those that refuse to convert can also set -C > equal to -D and have the old setup. Or the user can only specify -C to > point to the former -D and use the proposed 'datadir' parameter to find > the data area. While having config files named differently from 'postgresql.conf' would be a nice thing, I can live with your proposal without being able to specify arbitrary conf file names. A subdirectory under sysconfdir for each 'virtual' database would be sufficient. As to the security points that Tom brings up, you don't put anything in /etc directly -- you put it under /etc/pgsql, and lock it down the same as$PGDATA. Of course, the logic to do this sort of thing already exists in the configure script.... Also on the topic of security, 'encouraging' the use of separate subdirs for each server would also provide more isolation for the users of those servers. Oh, and BTW: when this is implemented, the dream of multiple servers running under the RPMset install will be realizable... :-) -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
В списке pgsql-hackers по дате отправления: