Обсуждение: config files in /data
Seems we should have pg_hba.conf and other files in a separate directory, not /data. Comments? -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On Tue, 30 May 2000, Bruce Momjian wrote: > Seems we should have pg_hba.conf and other files in a separate > directory, not /data. > > Comments? I still say that pg_hba.conf should be eliminated altogether, in favor of something that is modifiable by anyone that the supeuser gives permissions to create databases too ... what's the point of having that ability if you can't access the database after its created? Seems kinda anti-friendly to the DBA to be able to have "sub-ordinates" that can create users and databases, but has to be bug'd in order to allow them to be accessed ... pg_hba should become another system table that can be modified with simple SQL queries, and is modifiable (readable?) only by those with createdb privileges ...
> On Tue, 30 May 2000, Bruce Momjian wrote: > > > Seems we should have pg_hba.conf and other files in a separate > > directory, not /data. > > > > Comments? > > I still say that pg_hba.conf should be eliminated altogether, in favor of > something that is modifiable by anyone that the supeuser gives permissions > to create databases too ... what's the point of having that ability if you > can't access the database after its created? > > Seems kinda anti-friendly to the DBA to be able to have > "sub-ordinates" that can create users and databases, but has to be bug'd > in order to allow them to be accessed ... > > pg_hba should become another system table that can be modified with simple > SQL queries, and is modifiable (readable?) only by those with createdb > privileges ... And have it dump like pg_shadow. Yea, I guess we could do that. -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Seems we should have pg_hba.conf and other files in a separate
> directory, not /data.
Why?
I don't see enough advantage in it to justify breaking people's
existing administrative procedures. You can bet there are folks
out there whose scripts know where pg_hba.conf lives, for example.
regards, tom lane
>> pg_hba should become another system table that can be modified with simple
>> SQL queries, and is modifiable (readable?) only by those with createdb
>> privileges ...
> And have it dump like pg_shadow. Yea, I guess we could do that.
Yeah, the postmaster needs to see it as a flat file, but we could have
an update trigger like for pg_shadow.
I'm not convinced that it's cool to grant read rights on the table even
to those with createdb privileges. ("Wow, Joe Blow is running his
database with no connection security...") If we had a setup such that
one could only see the rows for databases one owns, it'd work. This
could be enforced by a view, perhaps, like we do for pg_user.
regards, tom lane
> Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Seems we should have pg_hba.conf and other files in a separate > > directory, not /data. > > Why? > > I don't see enough advantage in it to justify breaking people's > existing administrative procedures. You can bet there are folks > out there whose scripts know where pg_hba.conf lives, for example. > In describing how to do a backup, people have to backup data/pg_hba.conf, but none of the others. Seems strange that it is mixed in with actual tables. -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Bruce Momjian writes: > Seems we should have pg_hba.conf and other files in a separate > directory, not /data. I think the internal files, such as pg_control should be in data/base/ instead, so as to not mix them up with user-editable files such as pg_hba.conf, `configuration' (as of 3 min ago), ident, and password files. -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
Peter Eisentraut <peter_e@gmx.net> writes:
> Bruce Momjian writes:
>> Seems we should have pg_hba.conf and other files in a separate
>> directory, not /data.
> I think the internal files, such as pg_control should be in data/base/
> instead, so as to not mix them up with user-editable files such as
> pg_hba.conf, `configuration' (as of 3 min ago), ident, and password files.
Doesn't that pose a risk of collision with user-chosen database names?
Rather than restricting database names, we should keep these files in
a different subdirectory. I agree that it's a good idea to separate
them from the directly-editable config files, just not to put them in
data/base/ ...
regards, tom lane
> Peter Eisentraut <peter_e@gmx.net> writes: > > Bruce Momjian writes: > >> Seems we should have pg_hba.conf and other files in a separate > >> directory, not /data. > > > I think the internal files, such as pg_control should be in data/base/ > > instead, so as to not mix them up with user-editable files such as > > pg_hba.conf, `configuration' (as of 3 min ago), ident, and password files. > > Doesn't that pose a risk of collision with user-chosen database names? > Rather than restricting database names, we should keep these files in > a different subdirectory. I agree that it's a good idea to separate > them from the directly-editable config files, just not to put them in > data/base/ ... Yes, seems user-editable files should go in pgsql/etc or pgsql/config. -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Yes, seems user-editable files should go in pgsql/etc or pgsql/config.
What? That'd mean you couldn't have different files for different
installations, which'd be a severe handicap (at least for developers
who are pretty likely to have multiple installations on one machine).
Putting the active copies under the data/ directory is good.
Or did you really mean a new subdirectory like data/config/ ?
I could live with that for new or reformatted config files. As long as
pg_hba.conf (for example) doesn't change meaning/layout I'd rather leave
it where it is.
regards, tom lane
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Yes, seems user-editable files should go in pgsql/etc or pgsql/config.
>
> What? That'd mean you couldn't have different files for different
> installations, which'd be a severe handicap (at least for developers
> who are pretty likely to have multiple installations on one machine).
> Putting the active copies under the data/ directory is good.
I didn't think of that. Yes, I can see pgsql/data/config is better.
>
> Or did you really mean a new subdirectory like data/config/ ?
> I could live with that for new or reformatted config files. As long as
> pg_hba.conf (for example) doesn't change meaning/layout I'd rather leave
> it where it is.
Seems we can just move it. I really don't like people in /data, but
/data/config is OK. Of course, this is just my opinion. It just scares
me to have people doing edits in a directory with real tables.
I remember someone deleted pg_log last week because they thought it was
a log file. It just seems we have a mess in /data with too many
different types of files:
PG_VERSION pg_logbase/ pg_pwdpg_control
pg_pwd.reloadpg_database pg_shadowpg_geqo.sample pg_variablepg_group
pg_xlog/pg_group_name_index postmaster.optspg_group_sysid_index
postmaster.opts.defaultpg_hba.conf postmaster.pid
I myself am not totally sure of the use of all these.
-- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026
Tom Lane writes: > Rather than restricting database names, we should keep these files in > a different subdirectory. I agree that it's a good idea to separate > them from the directly-editable config files, just not to put them in > data/base/ ... Right. How about `$PGDATA/internal'? Can't be more obvious. Perhaps with that we could also have initdb clean up a little more respectfully. -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
[ Charset ISO-8859-1 unsupported, converting... ] > Tom Lane writes: > > > Rather than restricting database names, we should keep these files in > > a different subdirectory. I agree that it's a good idea to separate > > them from the directly-editable config files, just not to put them in > > data/base/ ... > > Right. How about `$PGDATA/internal'? Can't be more obvious. Perhaps with > that we could also have initdb clean up a little more respectfully. Are we talking about moveing pg_log and pg_shadow? Maybe call it /global because the tables are global to all databases. -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> Right. How about `$PGDATA/internal'? Can't be more obvious. Perhaps with
>> that we could also have initdb clean up a little more respectfully.
> Are we talking about moveing pg_log and pg_shadow? Maybe call it
> /global because the tables are global to all databases.
We weren't, but it seems like a good idea now that you mention it.
So it sounds like we are converging on:
$PGDATA itself contains only directly-editable config files
$PGDATA/base/ contains database subdirectories (same as now)
$PGDATA/global/ contains installation-wide tables (pg_database,pg_shadow, their indices, etc)
$PGDATA/internal/ contains anything else that is installation-widebut is not a table.
The distinction between /global and /internal is a little bit artificial
(which one does pg_log belong in? It's only sort of a table...), so
maybe we'd be better off just putting those two together. Don't have
a strong opinion either way.
regards, tom lane
> Bruce Momjian <pgman@candle.pha.pa.us> writes: > >> Right. How about `$PGDATA/internal'? Can't be more obvious. Perhaps with > >> that we could also have initdb clean up a little more respectfully. > > > Are we talking about moveing pg_log and pg_shadow? Maybe call it > > /global because the tables are global to all databases. > > We weren't, but it seems like a good idea now that you mention it. > So it sounds like we are converging on: > > $PGDATA itself contains only directly-editable config files > > $PGDATA/base/ contains database subdirectories (same as now) > > $PGDATA/global/ contains installation-wide tables (pg_database, > pg_shadow, their indices, etc) > > $PGDATA/internal/ contains anything else that is installation-wide > but is not a table. > > The distinction between /global and /internal is a little bit artificial > (which one does pg_log belong in? It's only sort of a table...), so > maybe we'd be better off just putting those two together. Don't have > a strong opinion either way. This sounds good, and it keeps pg_hba.conf in the same place. Seems /internal is just going to be confusing. Not sure. -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Tom Lane writes: > The distinction between /global and /internal is a little bit artificial > (which one does pg_log belong in? It's only sort of a table...), Is there any reason these special tables are catalogued? Also, with the catalog version number, is there any more use for the PG_VERSION file? -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane writes:
>> The distinction between /global and /internal is a little bit artificial
>> (which one does pg_log belong in? It's only sort of a table...),
> Is there any reason these special tables are catalogued?
I can't think of a reason to catalog pg_log offhand, but maybe Vadim
knows one...
> Also, with the catalog version number, is there any more use for the
> PG_VERSION file?
Sure. The catalog number is just for internal purposes; you can't use
it (easily) to tell which release you have. PG_VERSION is more
appropriate for user interface purposes. Also, consider pg_upgrade:
it wouldn't have any simple way of checking for compatibility without
PG_VERSION.
regards, tom lane
Bruce Momjian wrote: > > Seems we should have pg_hba.conf and other files in a separate > directory, not /data. > > Comments? config or etc, perhaps? But, make the location configuratable (so that the RPM's can finally do away with config data in /var, and put it in /etc/pgsql, where it belongs in the RPM distribution. -- Lamar Owen WGCR Internet Radio 1 PEter 4:11
> Bruce Momjian wrote: > > > > Seems we should have pg_hba.conf and other files in a separate > > directory, not /data. > > > > Comments? > > config or etc, perhaps? But, make the location configuratable (so that > the RPM's can finally do away with config data in /var, and put it in > /etc/pgsql, where it belongs in the RPM distribution. Current idea is to leave pg_hba.conf in /data, and move pg_log and pg_shadow to a /global directory. -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Bruce Momjian <pgman@candle.pha.pa.us> writes: > Current idea is to leave pg_hba.conf in /data, and move pg_log and > pg_shadow to a /global directory. It is a configuration, and separation of data and configuration would be nice. -- Trond Eivind Glomsrød Red Hat, Inc.
Bruce Momjian wrote: > > config or etc, perhaps? But, make the location configuratable (so that > > the RPM's can finally do away with config data in /var, and put it in > > /etc/pgsql, where it belongs in the RPM distribution. > Current idea is to leave pg_hba.conf in /data, and move pg_log and > pg_shadow to a /global directory. That certainly is better than now. I would still like to see the location configurable in some way. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Trond Eivind Glomsrød writes: > It is a configuration, and separation of data and configuration would > be nice. But then it's just going to be more confusing to tell which configuration goes with which data. -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
Lamar Owen writes: > config or etc, perhaps? But, make the location configuratable (so that > the RPM's can finally do away with config data in /var, and put it in > /etc/pgsql, where it belongs in the RPM distribution. The Linux FHS or GNU standards or whatever are really only good for programs that act on one piece of data per system. But you can run many postmasters per system so you can't fix the location of the configuration files independently of that of the data. -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
Peter Eisentraut wrote: > Lamar Owen writes: > > config or etc, perhaps? But, make the location configuratable (so that > > the RPM's can finally do away with config data in /var, and put it in > > /etc/pgsql, where it belongs in the RPM distribution. > The Linux FHS or GNU standards or whatever are really only good for > programs that act on one piece of data per system. But you can run many > postmasters per system so you can't fix the location of the configuration > files independently of that of the data. Yes, you can. If it is important enough to do it, I'll build the RPM's with ease of multiple postmasters in mind. With that, I can go with a tree such as: /etc/pgsql/$name_1/* /var/lib/pgsql/$name_1/data /etc/pgsql/$name_2/* /var/lib/pgsql/$name_1/data etc. In /etc/pgsql/$name_[12], I'd have a few files: configuration pg_hba.conf I haven't looked at your new configuration file as yet, but I am very interested. Then, the initscript would iterate over the /etc/pgsql/$name_ directories, and start a postmaster for each. This, incidentally, is planned for 7.1, as I don't want to mess with people's minds too much with too many changes inside the 7.0.x series. I would also have a couple of RPM-specific commands: createdbhost and dropdbhost (or some other, yet-to-be-determined program names) that would create and drop the extra postmaster configs and data dirs. I could even, for backwards compatibility, support an un-named postmaster that would feed from /etc/pgsql and /var/lib/pgsql/data...... All of which would be FHS-compliant. Thoughts? -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Lamar Owen writes: > /etc/pgsql/$name_1/* > /var/lib/pgsql/$name_1/data > /etc/pgsql/$name_2/* > /var/lib/pgsql/$name_1/data > etc. I can see how that would make sense in some standard layout. But you could easily make symlinks from /etc/ to the respective /var. Yes, that may look ugly to some, but the alternative might look just as ugly to some others. I mean users in a manual setup would actually have to go out of their way to put the configuration files somewhere else during initdb and then pick them up from there when they start the postmaster. If you want to do that behind the scenes in a prepackaged deal, okay, but I don't think exposing the users to these kinds of things will make things easier. > I haven't looked at your new configuration file as yet, but I am very > interested. New initdb runs now install a sample. > Thoughts? Well my overall thought is that the FHS and PostgreSQL are not necessarily a match made in heaven but I understand that you have some implicit commitments so I won't try to make it harder for you. :) -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
Peter Eisentraut wrote: > Lamar Owen writes: > > /etc/pgsql/$name_1/* > > /var/lib/pgsql/$name_1/data > > etc. > I can see how that would make sense in some standard layout. But you could > easily make symlinks from /etc/ to the respective /var. Yes, that may look > ugly to some, but the alternative might look just as ugly to some others. The symlinks idea is not the greatest, but it _would_ serve in a pinch. > I mean users in a manual setup would actually have to go out of their way > to put the configuration files somewhere else during initdb and then pick > them up from there when they start the postmaster. If you want to do that > behind the scenes in a prepackaged deal, okay, but I don't think exposing > the users to these kinds of things will make things easier. That's why a configure option to place configuration files in whatever location would be nice for those who want to do this sort of thing. No forcing of anyone to do anything -- for that matter, a RedHat user is perfectly free to install the source tarball and make the system look however -- after all, Thomas does this already (although it is Mandrake instead of RedHat -- cousins, really.). Of course, I can always patch....not ideal, however. > > I haven't looked at your new configuration file as yet, but I am very > > interested. > New initdb runs now install a sample. Good. I'm going to actually try to package the pre-7.1 stuff up in RPM form for those most intrepid RedHat users who want to maintain a consistency between versions. We shall see how easily that is accomplished in an automated manner. > > Thoughts? > Well my overall thought is that the FHS and PostgreSQL are not necessarily > a match made in heaven but I understand that you have some implicit > commitments so I won't try to make it harder for you. :) That is appreciated. The biggest difference between most platforms and RedHat relative to PostgreSQL is that PostgreSQL is considered an integral part of RedHat's distribution (which complicates things, as you are aware). It is my job to make RedHat and PostgreSQL get along smoothly. Debian is in the same position, as PostgreSQL is also integral to it -- and Oliver does an excellent job shepherding that facet. (PS: Bruce, don't you think it's about time Peter got mention on the developers' globe?) -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
> > Well my overall thought is that the FHS and PostgreSQL are not necessarily > > a match made in heaven but I understand that you have some implicit > > commitments so I won't try to make it harder for you. :) > > That is appreciated. The biggest difference between most platforms and > RedHat relative to PostgreSQL is that PostgreSQL is considered an > integral part of RedHat's distribution (which complicates things, as you > are aware). It is my job to make RedHat and PostgreSQL get along > smoothly. Debian is in the same position, as PostgreSQL is also > integral to it -- and Oliver does an excellent job shepherding that > facet. > > (PS: Bruce, don't you think it's about time Peter got mention on the > developers' globe?) Yikes, yes. Let me add him. Vince will have to redo the actual globe. Vadim is moved now anyway, so it has to be regenerated. Peter, can you give me your geographical location (Major city?). -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026