Имеется следующая проблема: необходимо организовать автоматический сброс бэкапов постгресовой базы куда-нибудь, короче, повесить на хрон. В самом постгресе все пароли шифруются, md5, как положено. Так вот, при pg_dump эта зараза требует ввести пароль, даже если команда запущена от имени админа БД. Т.е. на хрон повесить не могу, т.к. каждый раз требуется личное участие в виде ввода пароля.
Перерыта куча доки, везде одно и тоже: pg_dump или копирование каталога. Каталог копировать не хочу, ибо чревато. Так и базу грохнуть недалеко, и вообще не рекомендуется. Я уже просто в трансе, что я не так делаю? Помогите, пожалуйста, кто сталкивался с подобной проблемой.
В /usr/local/share/postgresql есть файл 502.pgsql. Копируешь его в /etc/periodic/daily например, ну и правишь его,если надо, под свои нужды. У меня, по крайней мере, так организованно.
>В /usr/local/share/postgresql есть файл 502.pgsql. Копируешь его в /etc/periodic/daily например, ну и
>правишь его,если надо, под свои нужды. У меня, по крайней мере,
>так организованно.Все это, конечно, очень здорово, но дело в том, что этот файл представляет собой всего лишь более удобную форму использования того же самого pg_dump, т.е. проблема никуда не девается. Система точно также добросовестно запрашивает пароль.
Вот мои конфы:
pg_hba.conf
local all all md5
host all all 127.0.0.1 255.255.255.255 md5Остальное без изменения.
Еще раз повторюсь, пароли в базе шифрованые, т.е. create user with encrypted password... т.е. использование md5 оправдано (собственно и выбора-то нет). Хотя все мои мучения, скорей всего, именно из-за этого. Возможно ли решить проблему в таком виде или придется ослаблять шифрование?
>>V /usr/local/share/postgresql est' fajl 502.pgsql. Kopiruesh' ego v /etc/periodic/daily naprimer, nu i
>>pravish' ego,esli nado, pod svoi nuzhdy. U menya, po krajnej mere,
>>tak organizovanno.
>
>Vse `eto, konechno, ochen' zdorovo, no delo v tom, chto `etot fajl
>predstavlyaet soboj vsego lish' bolee udobnuyu formu ispol'zovaniya togo zhe samogo
>pg_dump, t.e. problema nikuda ne devaetsya. Sistema tochno takzhe dobrosovestno zaprashivaet
>parol'.
>
>Vot moi konfy:
>pg_hba.conf
>local all
>all
>
>
>
> md5
>host all
> all 127.0.0.1
> 255.255.255.255
>md5
>
>Ostal'noe bez izmeneniya.
>
>Esche raz povtoryus', paroli v baze shifrovanye, t.e. create user with encrypted
>password... t.e. ispol'zovanie md5 opravdano (sobstvenno i vybora-to net). Hotya vse
>moi mucheniya, skorej vsego, imenno iz-za `etogo. Vozmozhno li reshit' problemu
>v takom vide ili pridetsya oslablyat' shifrovanie?
A pri4em tut tvoje 6ifrovanije. Togda po4itaj dokumentaciju po povodu togo za 4to otve4ajut pola dannogo faila.
Poslednij variant boolee elegantnij s ispolzovanijem ident. No mozhesh vpisat trust i vse.
>A pri4em tut tvoje 6ifrovanije. Togda po4itaj dokumentaciju po povodu togo za
>4to otve4ajut pola dannogo faila.
>Poslednij variant boolee elegantnij s ispolzovanijem ident. No mozhesh vpisat trust i
>vse.О, боже. Послушайте, не надо думать, что я лезу с вопросами, предварительно ничего не прочитав. Если вы не знаете, причем здесь шифрование, я скажу. При том, что, шифруя пароли в базе, у меня нет другого выхода, кроме как использовать md5.
И за что отвечают поля данного файла я прекрасно знаю. Не въехали в вопрос - лучше переспросите, чем кидаться такими выражениями. Я помощи прошу а не отповеди. К тому же не в тему.
Мне не хотелось использовать ни crypt, ни ident именно из-за слабой их защищенности. Об этом, кстати, сказано в документации и спецификации к ident.
А траст можете использовать сами, если вам совершенно наплевать на безопасность вашей базы.
>Imeetsya sleduyuschaya problema: neobhodimo organizovat' avtomaticheskij sbros b`ekapov postgresovoj bazy kuda-nibud', koroche,
>povesit' na hron. V samom postgrese vse paroli shifruyutsya, md5, kak
>polozheno. Tak vot, pri pg_dump `eta zaraza trebuet vvesti parol', dazhe
>esli komanda zapuschena ot imeni admina BD. T.e. na hron povesit'
>ne mogu, t.k. kazhdyj raz trebuetsya lichnoe uchastie v vide vvoda
>parolya.
>Pereryta kucha doki, vezde odno i tozhe: pg_dump ili kopirovanie kataloga. Katalog
>kopirovat' ne hochu, ibo chrevato. Tak i bazu grohnut' nedaleko, i
>voobsche ne rekomenduetsya. YA uzhe prosto v transe, chto ya ne
>tak delayu? Pomogite, pozhalujsta, kto stalkivalsya s podobnoj problemoj.Pokazhi komandu kotoruju zapuskajesh. U menaj naprimer vse normalno iz cron'a rabotajet pri parolah i vse takoje. Skorej vsego mu tebja v faile pg_hba.conf stoit prinuditelno ispolzovat parol.
>Имеется следующая проблема: необходимо организовать автоматический сброс бэкапов постгресовой базы куда-нибудь, короче,
>повесить на хрон. В самом постгресе все пароли шифруются, md5, как
>положено. Так вот, при pg_dump эта зараза требует ввести пароль, даже
>если команда запущена от имени админа БД. Т.е. на хрон повесить
>не могу, т.к. каждый раз требуется личное участие в виде ввода
>пароля.
>Перерыта куча доки, везде одно и тоже: pg_dump или копирование каталога. Каталог
>копировать не хочу, ибо чревато. Так и базу грохнуть недалеко, и
>вообще не рекомендуется. Я уже просто в трансе, что я не
>так делаю? Помогите, пожалуйста, кто сталкивался с подобной проблемой.вот это пример тебя спасет
#!/bin/sh
PGPASSWORD=pass
export PGPASSWORD
/usr/local/bupk/postgresql-7.3.2/bin/pg_dump -U postgres -o base1 > base1.dump
>вот это пример тебя спасет
>#!/bin/sh
>PGPASSWORD=pass
>export PGPASSWORD
>/usr/local/bupk/postgresql-7.3.2/bin/pg_dump -U postgres -o base1 > base1.dump
Да, все получилось! Спасибо большое.Вот только одно "но" буквально отравляет мне существование. Получается, безопасность моей базы зависит от того, не доберется ли кто-нибудь каким-нибудь образом до содержимого этого скрипта... Конечно, разрешения я установлю правильно, чтоб запускать мог только рут и никто не читал, но... что-то не дает покоя...
Еще раз спасибо за помощь. Знали бы вы, от какой беготни меня избавили :).
>
>Вот только одно "но" буквально отравляет мне существование. Получается, безопасность моей базы
>зависит от того, не доберется ли кто-нибудь каким-нибудь образом до содержимого
>этого скрипта... Конечно, разрешения я установлю правильно, чтоб запускать мог только
>рут и никто не читал, но... что-то не дает покоя...Верные сомнения :)
Есть более красивый способ (если бекапишь базу с локального компа).== ~pgsql/data/pg_hba.conf ==
local all pgsql ident superusers
==== ~pgsql/data/pg_ident.conf ==
superusers root pgsql
==Т.е. разрешить бд-юзеру pgsql локальный доступ ко всем базам. И юникс-юзера root идентифицировать с бд-юзером pgsql. Теперь:
dump_all -U pgsql ...
и пароль не спросят.
Заодно и просто работать с базой из командной строки удобно. Вместо psql и root можно подставить имена по вкусу, т.е. не обязательно запускать бекап от рута.
>Есть более красивый способ (если бекапишь базу с локального компа).
>
>== ~pgsql/data/pg_hba.conf ==
>local all pgsql
>ident superusers
>==
>
>== ~pgsql/data/pg_ident.conf ==
>superusers root pgsql
>==
>
>Т.е. разрешить бд-юзеру pgsql локальный доступ ко всем базам. И юникс-юзера root
>идентифицировать с бд-юзером pgsql. Теперь:
>
>dump_all -U pgsql ...
>
>и пароль не спросят.
>Заодно и просто работать с базой из командной строки удобно. Вместо psql
>и root можно подставить имена по вкусу, т.е. не обязательно запускать
>бекап от рута.
Мда... т.е. получается, наилучший выход - это идент. Мне вообще-то не хотелось. Хотя бы потому, что в будущем возможно потребуется добавлять возможность работы с базой с удаленого клиента (сейчас все делается через веб, т.е. все равно, что локально). А чем это грозит при использовании идента, сами знаете. Стоит кому-то у себя пройти идентификацию под этим именем - и все, добро пожаловать в базу.Разве что сделать так в качестве временного решения, порт сейчас один фиг закрыт, а для удаленных клиентов уже тр*хаться с идентификацией через керберос...
>>local all pgsql ident superusers>А чем это грозит при использовании идента,
>сами знаете. Стоит кому-то у себя пройти идентификацию под этим именем
>- и все, добро пожаловать в базу.Ну так я же и пишу - local :)
Цитата из доки: "In this case (при использовании локальных сокетов), no security risk is added by using ident authentication; indeed it is a preferable choice for local connections on such systems">
>Разве что сделать так в качестве временного решения, порт сейчас один фиг
>закрыт, а для удаленных клиентов уже тр*хаться с идентификацией через керберос...
>А удаленных все же проще по паролю
>Ну так я же и пишу - local :)
>Цитата из доки: "In this case (при использовании локальных сокетов), no security
>risk is added by using ident authentication; indeed it is a
>preferable choice for local connections on such systems"
>
>>
>>Разве что сделать так в качестве временного решения, порт сейчас один фиг
>>закрыт, а для удаленных клиентов уже тр*хаться с идентификацией через керберос...
>>
>
>А удаленных все же проще по паролю
Так и сделаю. Спасибо за помощь.