Como acessar os bancos postgre com outros usuarios
Oraculum
no capitulo 5 ele pede para testarmos nossa conexão com o banco:
>>> from django.db import connection
>>> cursor = connection.cursor()
Depois de consultar o seguinte artigo:
http://www.aprendendodjango.com/preparando-um-servidor-com-linux/
vi que precisava de mudar uma restrição do postgre quanto ao usuario
do unix ser diferente do admin (postgres) bem fiz a alteração abaixo
no arquivo "/etc/postgresql/8.3/main/pg_hba.conf":
# Database administrative login by UNIX sockets
local all postgres password
A questão é que quando criei meu banco no postgresql eu coloquei o
usuario "userdb" como dono do banco e agora eu não consigo fazer o
teste de conexão pois ele retorna a seguinte mensagem de erro:
Traceback (most recent call last):
File "<console>", line 1, in <module>
File "/usr/lib/python2.5/site-packages/django/db/backends/
__init__.py", line 56, in cursor
cursor = self._cursor(settings)
File "/usr/lib/python2.5/site-packages/django/db/backends/
postgresql_psycopg2/base.py", line 84, in _cursor
self.connection = Database.connect(conn_string, **self.options)
OperationalError: FATAL: autenticação do tipo Ident falhou para
usuário "userdb"
Lembando que isso só ocorre com esse banco atribuído ao "userdb" fiz
um novo banco atribuido ao "postegres" e funcionou, gostaria de saber
se tem como configurar da mesma forma que fiz com o postgres o acesso
do userdb?
ps. pelo pgAdmin III eu acesso o banco do "userdb" normalmente.
Arthur Furlan
Hash: SHA1
Oraculum wrote:
[...]
> Depois de consultar o seguinte artigo:
> http://www.aprendendodjango.com/preparando-um-servidor-com-linux/
>
> vi que precisava de mudar uma restrição do postgre quanto ao usuario
> do unix ser diferente do admin (postgres) bem fiz a alteração abaixo
> no arquivo "/etc/postgresql/8.3/main/pg_hba.conf":
>
> # Database administrative login by UNIX sockets
> local all postgres password
Essa linha quer dizer que o usuário "postgres", tem acesso a todas as
databases ("all"), quando se conecta a partir do localhost ("local") e
se autentica com senha ("password").
Particularmente, prefiro manter o usuário "postgres" com configuração
padrão e geralmente também não defino senha para ele. Sempre que quero
adicionar uma aplicação, crio um banco de dados e usuários novos.
> A questão é que quando criei meu banco no postgresql eu coloquei o
> usuario "userdb" como dono do banco e agora eu não consigo fazer o
> teste de conexão pois ele retorna a seguinte mensagem de erro:
Ok, então nesse caso você vai precisar adicionar mais uma linha como
aquela logo acima dizendo que agora, você permite que o usuário "userdb"
(antes era o usuário postgres) se conecte no banco de dados que você
criou a partir do host local e se autenticando por senha.
Por exemplo, se o nome do seu banco for "testdb", seu pg_hba.conf deve
conter *mais uma linha* (não precisa remover a configuração anterior)
como a mostrada abaixo:
local testdb userdb password
> Lembando que isso só ocorre com esse banco atribuído ao "userdb" fiz
> um novo banco atribuido ao "postegres" e funcionou, gostaria de saber
> se tem como configurar da mesma forma que fiz com o postgres o acesso
> do userdb?
Correto, isso acontece porque o usuáro "userdb" não tem permissão para
acessar esse seu banco de dados. Faça as configurações indicadas acima e
tente novamente.
Vale a pena dar uma lida na documentação do PostgreSQL sobre o assunto:
http://developer.postgresql.org/pgdocs/postgres/auth-pg-hba-conf.html
> ps. pelo pgAdmin III eu acesso o banco do "userdb" normalmente.
Porque provavelmente você acessa utilizando o usuário "postgres".
- --
Atenciosamente,
Arthur Furlan
arthur...@gmail.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAklx5BcACgkQHiIxAB175NxyDQCeIppOCsIR7sT6S1Cd7sX+p7B6
r08AoMuViekAqc5R919f+23XDRGAiWsN
=ByzK
-----END PGP SIGNATURE-----
Felipe Luis (TIO)
Particularmente, prefiro manter o usuário "postgres" com configuração
padrão e geralmente também não defino senha para ele. Sempre que quero
adicionar uma aplicação, crio um banco de dados e usuários novos.
Ou será que neste caso é melhor usar outro metodo de autenticação(md5 ao invés de ident)?
Particulamente prefiro o método ident pois não é necessario deixar a senha no settings.py.
Forte Abraço
Felipe Luis de Souza Vieira
Arthur Furlan
Hash: SHA1
Felipe Luis (TIO) wrote:
> Arthur, você mencionou...
>
>
> Particularmente, prefiro manter o usuário "postgres" com configuração
> padrão e geralmente também não defino senha para ele. Sempre que quero
> adicionar uma aplicação, crio um banco de dados e usuários novos.
>
>
> Se você roda o seu projeto no apache ele executa com o usuario www-data.
Não necessariamente... Eu geralmente crio um usuário "específico" para
cada um dos meus sites do apache.
> Tudo bem podemos, modificar o usuario para o usuário do projeto,
> entretanto, se eu tenho mais de um projeto no mesmo servidor posso
> configurar o apache para rodar diferentes projetos com usuarios distintos?
Não sei se eu entendi direito o que você colocou acima, mas se a sua
pertgunta era se é possível configurar o apache para rodar com usuários
distintos, a resposta é: sim, você pode. No mod-wsgi[1] você consegue
especificar o usuário que o Apache irá utilizar para rodar os scripts.
[1]. http://code.google.com/p/modwsgi/wiki/IntegrationWithDjango
> Ou será que neste caso é melhor usar outro metodo de autenticação(md5 ao
> invés de ident)?
Ainda assim, eu não faço a autenticação via "ident". Sempre utilizo
autenticação via "password" e configuro cada usuário e cada database
manualmente no meu pg_hba.conf
> Particulamente prefiro o método ident pois não é necessario deixar a
> senha no settings.py.
Se o seu site roda com um usuário específico, você pode fechar o acesso
a leitura do seu settings.py para esse usuário. :)
- --
Atenciosamente,
Arthur Furlan
arthur...@gmail.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAklx9nQACgkQHiIxAB175Nx1rwCgzcQChciF+DkmSDT+avCT5uIu
OiAAoN3I+pzFbLSEKl1FF1q7veVeZycZ
=4FTJ
-----END PGP SIGNATURE-----
Felipe Luis (TIO)
> Tudo bem podemos, modificar o usuario para o usuário do projeto,Não sei se eu entendi direito o que você colocou acima, mas se a sua
> entretanto, se eu tenho mais de um projeto no mesmo servidor posso
> configurar o apache para rodar diferentes projetos com usuarios distintos?
pertgunta era se é possível configurar o apache para rodar com usuários
distintos, a resposta é: sim, você pode. No mod-wsgi[1] você consegue
especificar o usuário que o Apache irá utilizar para rodar os scripts.
[1]. http://code.google.com/p/modwsgi/wiki/IntegrationWithDjango
Sim você entendeu :D realmente com o wsgi é possível. Mas estive configurando alguns sites com mod_python e não vi uma opção para isso, porem posso mudar o usuario sim dei uma pesquisada e encontrei [2]
http://rob.sun3.org/misc/multiple-user-apache-setups/
Ainda assim, eu não faço a autenticação via "ident". Sempre utilizo
> Ou será que neste caso é melhor usar outro metodo de autenticação(md5 ao
> invés de ident)?
autenticação via "password" e configuro cada usuário e cada database
manualmente no meu pg_hba.conf
Se o seu site roda com um usuário específico, você pode fechar o acesso
> Particulamente prefiro o método ident pois não é necessario deixar a
> senha no settings.py.
a leitura do seu settings.py para esse usuário. :)
Verdade. Mas o password as vezes acaba ficando no subversion que em alguns caso não temos o controle de quem acessa. Nada que não de para contornar também.
Abraço!
Luciano Ramalho
> Verdade. Mas o password as vezes acaba ficando no subversion que em alguns
> caso não temos o controle de quem acessa. Nada que não de para contornar
> também.
Se as senhas ficam no repositório, aí é uma falha grave de segurança mesmo.
Para evitar isso, é legal dividir o seu settings.py em duas partes. Na
verdade, fazer o settings.py importar um arquivo adicional (eu costumo
chamar de settings_local.py) onde você coloca a senha e outras coisas
que não devem ir para o repositório. Em meus projetos, tenho feito
assim o settings.py:
####################################
import os
PROJECT_PATH = os.path.abspath(os.path.split(__file__)[0])
# aqui vai o resto do seu settings.py normal
# [...] um monte de linhas omitidas
# e o final do settings.py fica assim:
try:
execfile(PROJECT_PATH+'/settings_local.py')
except IOError:
pass
####################################
E o no arquivo settings_local.py eu coloco qualquer coisa que eu
queira sobrescrever no settings:
####################################
# coding: utf-8
DATABASE_USER = 'extranet'
DATABASE_PASSWORD = '@d$h%j@K('
DATABASE_HOST = 'db.exemplo.com.br'
SECRET_KEY = 'C1uHDbgHlqdfGkhKhuyTyg7BC62d6JkFdhDCMJIGs4mXG9E86F07fISR'
INSTALLED_APPS += (
'django.contrib.admindocs',
'django.contrib.databrowse',
)
MIDDLEWARE_CLASSES += (
'debug_middleware.DebugFooter',
)
####################################
Então o settings.py é colocado no svn, e o settings_local.py nunca.
Quando o Django executa o settings.py, as configurações do
settings_local.py são usadas, se este arquivo existir. Se não existir,
nada acontece.
Por sinal, é importante proteger não apenas a senha do banco de dados,
mas também a SECRET_KEY que o Django usa para gerar o hash das senhas
de usuários e dos cookies.
Existem outras receitas semelhantes que usam import em vez do
execfile, mas o execfile tem a vantagem de permitir alterar
configurações do settings.py aproveitando os valores que já estão lá,
fazendo esta a concatenação com operador += das tuplas como
INSTALLED_APPS ou MIDDLEWARE_CLASSES, coisa que não funcionaria num
import.
Outra vantagem é que o execfile não gera um settings_local.pyc (que é
gerado automaticamente pelo comando import) assim temos um arquivo
para a menos administrar (e se vc apaga ou renomeia o
settings_local.py, ao executar o import o Python usa o .pyc sem te
avisar, o que gera outras confusões neste contexto de gestão de
settings).
Então é por isso que adotei para este caso específico a solução via
execfile em vez de import.
[ ]s
Luciano
Arthur Furlan
Hash: SHA1
Luciano Ramalho wrote:
[...]
> Existem outras receitas semelhantes que usam import em vez do
> execfile, mas o execfile tem a vantagem de permitir alterar
> configurações do settings.py aproveitando os valores que já estão lá,
> fazendo esta a concatenação com operador += das tuplas como
> INSTALLED_APPS ou MIDDLEWARE_CLASSES, coisa que não funcionaria num
> import.
>
> Outra vantagem é que o execfile não gera um settings_local.pyc (que é
> gerado automaticamente pelo comando import) assim temos um arquivo
> para a menos administrar (e se vc apaga ou renomeia o
> settings_local.py, ao executar o import o Python usa o .pyc sem te
> avisar, o que gera outras confusões neste contexto de gestão de
> settings).
>
> Então é por isso que adotei para este caso específico a solução via
> execfile em vez de import.
Nossa, muito legal essa idéia do execfile! Sempre usei import, mas com o
execfile fica bem melhor realmente. :)
- --
Atenciosamente,
Arthur Furlan
arthur...@gmail.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAklztnEACgkQHiIxAB175NwRKgCg2tPirUWR3fi0JnGS2NvSjMzi
/5oAnivohGczMmJYOIcQe+9iNfP3cfDP
=ELK+
-----END PGP SIGNATURE-----
Felipe Luis (TIO)
Felipe Luis de Souza Vieira