Re: [Pgsqlrpms-hackers] [HACKERS] Safer auto-initdb for RPM init
On Sat, 9 Sep 2006 at 15:57, Lamar Owen wrote: > [...] or annoying the small number of people who NFS mount their > datadirs? This problem is not limited to NFS. It can happen with any FS just by reversing (for whatever reason) the order of mounting the FS and starting the PostgreSQL server. But the SUSE RPMs have the auto-initdb feature since the PostgreSQL 7.0 days (almost six years), and AFAIR I never got a single complaint about this sort of problem. cu Reinhard ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [Pgsqlrpms-hackers] [HACKERS] Safer auto-initdb for RPM init
On Saturday 26 August 2006 22:08, Matthew T. O'Connor wrote: > Joshua D. Drake wrote: > > Matthew T. O'Connor wrote: > >> script. If we installed the datadir during the RPM install, it would > >> still be newbie friendly and would removed initdb from start script > >> solving that problem. > > initdb will not overwrite an existing installation. > Poorly chosen words. I meant, the problem where the start script will > create a new data dir when it doesn't see that one exists even though > one actually does exist it's just not available at the moment. Either > way, if the start scripts never created a data dir, then there is no > problem. If a prebuilt datadir tree were available, it would make it even easier for people to overwrite their existing data, as RPM does not check non-RPM-managed files prior to overwriting them. This was in fact done several years ago by Red Hat, and was speedily removed. I understand the needs from both angles; so I'll ask just a simple question: which is worse, annoying all the newbies who just want to get started quickly, or annoying the small number of people who NFS mount their datadirs? (I personally wouldn't in a million years trust NFS for ACID compliance; maybe iSCSI, but NFS?!?!). The behavior, in my opinion, should be configurable and ON by default. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [Pgsqlrpms-hackers] [HACKERS] Safer auto-initdb for RPM init
Hello, On Sat, 2006-08-26 at 19:16 -0400, Andrew Dunstan wrote: > Well, in the case of RPMS built with the pgfoundry pgsqlrpms project > init script, it looks to me like it is already disabled: see > http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgsqlrpms/patches/8.2/postgresql.init?rev=1.2&content-type=text/x-cvsweb-markup This is a pre-pre-alpha; and may be reverted in stable release. I'm just trying to find a better way for initdb troubles. Regards, -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/ signature.asc Description: This is a digitally signed message part
Re: [Pgsqlrpms-hackers] [HACKERS] Safer auto-initdb for RPM init
> > Am Freitag, 25. August 2006 16:31 schrieb Reinhard Max: > > But shouldn't mountpoints always have 000 permissions to prevent > > writing into the directory as long as nothing is mounted to it? > > That's an interesting point, but in practice nobody does > that. And we're > trying to defend exactly against the case where someone has > set up a mount > point manually. > It had never occurred to me, but I'm definitely going to start doing it now. So it will be in practice, at least around here. Regards, Paul Bort ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [Pgsqlrpms-hackers] [HACKERS] Safer auto-initdb for RPM init script
Reinhard Max writes: > Another flaw of the flag-file method is, that PGDATA might have been > changed by the sysadmin between installing the RPM and calling the > init script for the first time. What problem do you see there? With either of these methods, a manual change in PGDATA would require a manual initdb before the postmaster would start. That seems like a good conservative thing to me. (Actually, with the flag-file method you could get the initscript to run initdb for you by hand-creating the flag file, but it seems unlikely people would do that in practice.) > But shouldn't mountpoints always have 000 permissions to prevent > writing into the directory as long as nothing is mounted to it? Not sure that that helps much given that the initscript runs as root. And in any case the point here is to protect against human error, not to assume that the installation is managed according to very best practices. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [Pgsqlrpms-hackers] [HACKERS] Safer auto-initdb for RPM init
Am Freitag, 25. August 2006 16:31 schrieb Reinhard Max: > But shouldn't mountpoints always have 000 permissions to prevent > writing into the directory as long as nothing is mounted to it? That's an interesting point, but in practice nobody does that. And we're trying to defend exactly against the case where someone has set up a mount point manually. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [Pgsqlrpms-hackers] [HACKERS] Safer auto-initdb for RPM init
On Fri, 25 Aug 2006 at 10:20, Tom Lane wrote: > If this were a bulletproof solution then I'd consider it anyway, but > AFAICS it's got the very same vulnerabilities as the flag-file > method, ie, if you RPM install or upgrade while your mountable data > directory is offline, you can still get screwed. Another flaw of the flag-file method is, that PGDATA might have been changed by the sysadmin between installing the RPM and calling the init script for the first time. But shouldn't mountpoints always have 000 permissions to prevent writing into the directory as long as nothing is mounted to it? cu Reinhard ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
