Re: pg_dumpall and pg_dumps
От | Simone Tellini |
---|---|
Тема | Re: pg_dumpall and pg_dumps |
Дата | |
Msg-id | 20020221195552.71C1.TELLINI@areabusiness.it обсуждение исходный текст |
Ответ на | Re: pg_dumpall and pg_dumps (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-admin |
On Thu, 21 Feb 2002 13:44:03 -0500 Tom Lane <tgl@sss.pgh.pa.us> wrote: TL> > 2. you can't specify username and password on the command line: this TL> > makes it impossible to backup automatically all the databases from a TL> > cron script if you use password authentication, for instance. TL> TL> I see no good way around that, except to not use password actually, there's a way to patch pg_dumpall to allow for that: it's just not practical to have to modify it each time a new version is released. TL> authentication. (Even if it worked, it'd be a bad idea to embed the TL> password in the backup script.) Why? My backup script is readable/executable only from the postgres user. If you could read the password from the script, you would also be able to copy the whole postgres setup, modify it's config files, etc... I don't see any real problem in writing the postgres superuser password in the script, do you? TL> This is more practical than it used to be given the availability of TL> ident-style auth for Unix-socket connections (on many platforms) in 7.2. TL> Even if you don't have a platform with support for it, ident auth on TL> localhost TCP connections isn't an unreasonable way to go. if you're using postgres as a backend for a web server you might want to give your users access only to their database. You cannot use ident as the user will always be the same (ie. nobody, www, apache, whatever...) The only way I see is to use password authentication. -- Simone Tellini E-mail: tellini@areabusiness.it http://www.areabusiness.it
В списке pgsql-admin по дате отправления: