Re: [pgbr-geral] Erro ao fazer backup - PQgetCopyData() falhou
Não funcionou ainda. Apaguei todas as libpq que haviam no computador, deixei somente ao do postgre 8.4 (Que é a versão do servidor), e o mesmo erro continua. Também tenho todas as DLL's da pasta bin do postgre 8.4 em uma pasta separada lá no cliente e o erro também ocorre executando desta pasta a parte (Funciona em todos os clientes exceto 2, independente do PGAdmin instalado ou não). Os 2 clientes que ocorrem este erro, não sei se é coincidência, mas um dá o erro em entrada, e o outro em entrada_item. A tabela não esta corrompida, consigo fazer select e buscar todos os dados da mesma, vacuum full analyze e reindex em toda base já foram feitos sem apresentar problemas. Não acredito que possa ser influência se outras dll's antigas na máquina porque tenho uma cópia da pasta bin do postgre lá no cliente pra executar o backup e o mesmo erro ocorre executando em outras máquinas. Quando faço o backup somente da tabela que aponta o erro, é feito normalmente sem nenhum erro. Coloquei pra fazer backup de duas tabelas e o mesmo erro aconteceu, porem agora apontando para a outra tabela. Em ultimo caso só me restou tentar atualizar o postgre. Essas duas tabela que aconteceram o mesmo erro, uma possui cerca de 139.000 registro com 75 campos e a outra 758.000 registro com 150 campos, algum tempo atras lembro que o backup funcionava corretamente. A única coisa que consigo pensar agora é na versão 8.4 possa ter bug no servidor ou no dump que possa dar erro com muitos registro e muitos campos. Em 31 de outubro de 2011 18:22, Flavio Henrique Araque Gurgel fha...@gmail.com escreveu: Nota: Acontece erro somente quando é tentado fazer backup a partir de uma estação windows, realizando o backup a partir do servidor linux funciona corretamente (Não tenho nenhuma estação linux no cliente). Tentei com os mais diversos parâmetro do pg_dump, e também utlizando os dump das versões 8.4, 9.0 e 9.1. O servidor é postgre 8.4 rodando em linux. A versão do pg_dump não é a questão, é a versão da libpq. Verifique sua instalação no Windows, desinstale as versões anteriores, reinstale a versão mais recente, cuidado com instalação de versões antigas do PgAdmin. Cuidado com o nome do banco de dados. Ele pode ficar invocado com você. []s Flavio ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Segurança de dados no SGBD
Em 31/10/2011 18:46, Dickson S. Guedes escreveu: Em 31 de outubro de 2011 17:21, Flávio Alves Granato flavio.gran...@gmail.com escreveu: Senhores, estou em um dilema pessoal. Como proceder para evitar que dados sensíveis sejam lidos por invasores em uma máquina? Penso que posso fazer mil voltas na aplicação, colocar GRANT em todas as tabelas, mas se houver alguém com acesso à máquina onde estão os dados e isso ocorre não só por meios ilícitos, como vocês costumam proteger os dados deste tipo de acesso não autorizado? Se elas ocorrem por problemas ilícitos o problema em si é outro. Todas as camadas precisam estar bem protegidas, inclusive o sistema operacional. Este deve proporcionar uma infraestrutura confiável para que você defina permissões para o usuário que executa o serviço do banco. Se alguém que tem acesso burlar isso, seus problemas são outros na realidade. Penso em criptografar os dados sensíveis, seria uma boa idéia? É um custo elevado para o banco e consequentemente para a aplicação. Criptografar o backup até vai, mas chegar ao ponto de utilizar um sistema de arquivos criptografado pode ser um tiro no pé. Como ficaria a auditoria dos dados se pela elevação do nível de segurança forçar a troca das chaves criptográficas? Pois assim teria que re-criptografar os dados novamente. Ou teria que ter uma aplicação de visualização dos dados descriptografados. Qual a experiência de vocês com este tipo de questão? É um ponto delicado, trate as demais camadas primeiramente. Monitore logs, gere alertas com ferramentas de segurança como snort por exemplo, crie proteções robustas com regras de firewall bem definidas. Acho que o começo é por ai... a partir disso você vai começar a ouvir seu ambiente e provavelmente ele vai te dizer o quão profundo na segurança você terá que ir. Entendo, mas a solução que você deu não resolve o problema pois por mais que algum funcionário assine um termo de confidencialidade, por mais que você selecione a pessoa, faça testes e muitos outros requisitos de confiabilidade, o que importa são a consistência dos dados e a inviolabilidade do acesso a eles. E encher o kernel de patchs, o firewall de regras e snort + portsentry + ossec ou qualquer outra solução não vai mitigar o risco que levantei. Se por questões de desempenho eu não tomo medidas para manter os dados inacessíveis, por questões de performance também é justo não mantê-los consistentes. Eu gostaria de saber como mitigar este risco absurdo mas que é plausível quando os valores das informações compensarem para alguém quebrar toda a sua ética profissional e roubá-la. Só para não ficar vago, já participei de um projeto em que houve tal situação, antes de eu chegar, mas houve. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Iniciando Aprendizado
Em 31 de outubro de 2011 20:18, angelo neto neto...@gmail.com escreveu: Ola Meus Caros. Estou Começando no SGDB Postgres e gostaria da ajuda de alguns de vcs, se nao for pedir muito. se poderiam me endicar alguns sites, apostilas e livros relacionado ao SGDB. Logo quero estar mais presente na comunidade contribuindo tirando duvidas entre outras coisas. Olá! Seja bem vindo a lista! Bom, além da dica do pessoal para você participar do PGBR 2011 (o maior evento sobre PostgreSQL das Américas [1]) você tem algumas referências nacionais e internacionais. Você poderia começar acompanhando o Planeta PostgreSQL Brasil [2] bem como o internacional [3], a comunidade brasileira mantém também um site [4] com informações, enquanto que no site internacional [5] você vai encontrar tanto informações gerais sobre o PostgreSQL bem como uma documentação completa [6]. Você ainda pode visitar o PGCasts [7] que contém screencasts sobre PostgreSQL, até o momento todos são em português e são sobre assuntos diversos, não possuem uma ordem lógica. Por fim, tem os livros [8] sobre assunto dos quais eu recomendaria: PostgreSQL 9.0 High Performance e PostgreSQL 9 Administration Cookbook. [1] http://pgbr.postgresql.org.br/2011/noticias.php [2] http://planeta.postgresql.org.br [3] http://planet.postgresql.org [4] http://www.postgresql.org.br/ [5] http://www.postgresql.org/ [6] http://www.postgresql.org/docs/manuals/ [7] http://pgcasts.com [8] http://www.postgresql.org/docs/books/ Um abraço e bom aprendizado. -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Revoke
Bom dia Pessoal Esta me ocorrendo o seguinte problema de revoke na versao 9.0, postgres : REVOKE ALL ON ALL TABLES IN SCHEMA.TABELA FROM GROUP GROUP_NAME Executo o comando acima, e não consigo dropar o grupo, não tenho mais usuários no grupo.As permissões do grupo estão para o nível de coluna.Sendo justamente estas que ele reclama a dependência na hora do drop. Alguma ideia de como poderia dar o revoke das permissões deste group e depois drop? Obrigado ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Segurança de dados no SGBD
Em 01/11/2011 11:02, Dickson S. Guedes escreveu: E encher o kernel de patchs, o firewall de regras e snort + portsentry + ossec ou qualquer outra solução não vai mitigar o risco que levantei. Se forem bem aplicadas vão mitigar, mas provavelmente não o suficiente para o cenário que você está propondo. vão mesmo e acabei esquecendo de um zabbix que pode vigiar também quando há acesso à máquina fora de horário e mesmo no horário de trabalho. Vai mitigar mais o risco, assim aumentando um 9 nos 99,... do projeto. Se por questões de desempenho eu não tomo medidas para manter os dados inacessíveis, por questões de performance também é justo não mantê-los consistentes. Por isso que eu disse que utilizar um sistema de arquivos criptografado *pode ser* um tiro no pé. Você *tem* que tomar medidas para manter os dados inacessíveis sim! Concordo com você, mas IMHO existe um limiar que você tem que definir: até que ponto você vai para manter esses dados assegurados durante o transporte? Concordo e realmente tem que ser levado em conta este limiar. O PostgreSQL nativamente não possui suporte para manipular dados criptografados, no nível de coluna por exemplo, como você encontra num SQL Server por exemplo. Você até consegue alguns cenários com granularidade bem configurada utilizando SE/PostgreSQL mas não diz respeito à criptografia e si mas sim contextos de acesso. Não conheço SQL Server e nem outro qualquer a um nível deste. Mas seria interessante uma feature destas no PostgreSQL, mas a idéia é impedir o acesso deixando apenas um usuário com token, senha, autenticação 2 ou 3 fatores, sei lá... Você pode ter um sistema de arquivos criptografado como um EFS por exemplo, comunicação inter-processos criptografadas, cache de controladora criptografado e pode até tentar fazer o swap criptografado também, entretanto o PostgreSQL tem suporte a SSL entre o banco e a aplicação. Essas medidas vão mitigar a maior parte dos riscos. concordo e já ajuda muito! Só para não ficar vago, já participei de um projeto em que houve tal situação, antes de eu chegar, mas houve. E foi um caso de sucesso? Que dificuldades foram encontradas? Quais os pontos fortes e fracos? na realidade eles partiram para o ditado gato escaldado tem medo de água fria, ou seja, passaram a dúvidar do programador e o programador ficava 1 ano sem acesso a internet e nunca poderia ser admin de sua máquina, depois disso ele passaria a acessar a internet, ou seja depois de provado sua confiabilidade. Apesar de ser um ótimo caso de sucesso de postgres ainda faltava muita coisa no datacenter, eles só tinham uma máquina com o banco e escalavam muito bem a aplicação. Esta aplicação dava conta sorrindo de 2 milhões de transações diárias, envolvia outros sistemas legados e o SGBD deles nunca reclamou de nada, mesmo não tendo um dba na equipe... quando deixei o projeto eles já estavam pensando em melhorar a infra de persistência das informações e já estava havendo brainstorms para isso. Enfim, é um assunto vasto e interessante, vamos ver com o quê os outros colegas com mais experiência podem contribuir. É um assunto muito inressante mesmo e envolve várias áreas da computação. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Segurança de dados no SGBD
On 01-11-2011 08:36, Flávio Alves Granato wrote: Entendo, mas a solução que você deu não resolve o problema pois por mais que algum funcionário assine um termo de confidencialidade, por mais que você selecione a pessoa, faça testes e muitos outros requisitos de confiabilidade, o que importa são a consistência dos dados e a inviolabilidade do acesso a eles. E encher o kernel de patchs, o firewall de regras e snort + portsentry + ossec ou qualquer outra solução não vai mitigar o risco que levantei. Reveja os seus conceitos sobre segurança de dados. Não existe 100% de segurança. Quanto a uma solução que possa proteger alguns dos seus dados talvez o sepgsql [1] possa te atender. Ele é um módulo carregável que suporta MAC (controle de acesso mandatório) baseado em rótulos. A sua implementação está atrelada ao SELinux. Vale lembrar que há limitações na implementação; sendo assim, ele ainda não controla todas as ações de acesso do PostgreSQL. No wiki há algumas páginas [2] apresentando os conceitos, funcionamento, administração e limitações. [1] http://www.postgresql.org/docs/current/static/sepgsql.html [2] http://wiki.postgresql.org/wiki/SEPostgreSQL -- Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Segurança de dados no SGBD
Em 01/11/2011 12:01, Euler Taveira de Oliveira escreveu: On 01-11-2011 08:36, Flávio Alves Granato wrote: Entendo, mas a solução que você deu não resolve o problema pois por mais que algum funcionário assine um termo de confidencialidade, por mais que você selecione a pessoa, faça testes e muitos outros requisitos de confiabilidade, o que importa são a consistência dos dados e a inviolabilidade do acesso a eles. E encher o kernel de patchs, o firewall de regras e snort + portsentry + ossec ou qualquer outra solução não vai mitigar o risco que levantei. Reveja os seus conceitos sobre segurança de dados. Não existe 100% de segurança. São só indagamentos, claro que sei que não existe 100%. Quem não chora não mama, não é! Na realidade esta thread para mim é mais um exercício, pois como disse em outro email respondido para o Dickson, não faço parte da equipe onde ocorreu algo parecido. Quanto a uma solução que possa proteger alguns dos seus dados talvez o sepgsql [1] possa te atender. Ele é um módulo carregável que suporta MAC (controle de acesso mandatório) baseado em rótulos. A sua implementação está atrelada ao SELinux. Vale lembrar que há limitações na implementação; sendo assim, ele ainda não controla todas as ações de acesso do PostgreSQL. No wiki há algumas páginas [2] apresentando os conceitos, funcionamento, administração e limitações. Ótimo, vou dar uma lida e depois posto minhas considerações. Muito obrigado pela resposta. [1] http://www.postgresql.org/docs/current/static/sepgsql.html [2] http://wiki.postgresql.org/wiki/SEPostgreSQL ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Desculpem, mais uma vez sobre acentos (LATIN1)
No caso do Latin1 uso o pt_BR.ISO-8859-1, mas no caso do LATIN9 o postgres diz não ter o ISO-8859-15. Como devo fazer? Bruno E. A. Silva. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Desculpem, mais uma vez sobre acentos (LATIN1)
2011/11/1 Bruno Silva bemanuel...@gmail.com: No caso do Latin1 uso o pt_BR.ISO-8859-1, mas no caso do LATIN9 o postgres diz não ter o ISO-8859-15. Como exatamente diz, em resposta a exatamente que operação e em que ambiente? No caso do GNU/Linux, por exemplo, o PostgreSQL herda as configurações do sistema operacional. Se o pacote locales estiver incompleto ou não tiver sido configurado de acordo, eu esperaria (em princípio) algum problema. Agora, mesmo o ISO 8859‐15, embora suceda com vantagens o 8859‐1, já deveria ser substituído pelo UTF‐8 (ISO 10 646, se não me falha a memória), sempre que for possível planejar a migração. É o padrão das novas instalações das distribuições GNU/Linux, por exemplo, e com ótimos motivos para isso: cobrir toda e qualquer língua com suporte já formalizado. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Desculpem, mais uma vez sobre acentos (LATIN1)
Agora, mesmo o ISO 8859‐15, embora suceda com vantagens o 8859‐1, já deveria ser substituído pelo UTF‐8 (ISO 10 646, se não me falha a memória), sempre que for possível planejar a migração. É o padrão das novas instalações das distribuições GNU/Linux, por exemplo, e com ótimos motivos para isso: cobrir toda e qualquer língua com suporte já formalizado. As vezes o sistema legado mata a gente... Bruno E. A. Silva. Analista de Sistemas. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Indicados para o Prêmio PGBR
É com imensa satisfação que a comunidade PostgreSQL Brasil apresenta os indicados para concorrer ao Prêmio PGBR do ano de 2011. O prêmio tem por objetivo homenagear as pessoas que mais se destacaram na comunidade brasileira de PostgreSQL nos últimos dois anos e será entregue durante o evento PGBR2011 (http://pgbr.postgresql.org.br). Será escolhido *apenas um ganhador* por categoria, totalizando 5 (cinco) premiados. 1) Contribuição com código no PostgreSQL nos últimos 5 anos; - Euler Taveira - Dickson Guedes - Fernando Ike 2) Contribuição com código em ferramentas livres relacionadas ao PostgreSQL nos últimos 2 anos; - Dickson Guedes (pgxn) - Francisco Figueiredo (nPg) - Euler Taveira (pgSimilarity) - Leonardo Cezar (ora2pg) 3) Pessoa que melhor contribuiu na lista pgbr-geral nos últimos 12 meses; - Osvaldo Kussama - Leandro Guimarães Faria Corcete - João Paulo Muller - Flávio Amaral Gurgel 4) Melhor contribuição na organização da comunidade brasileira nos últimos 2 anos; - Fábio Telles - Luis Fernando Bueno - Euler Taveira - Charly Batista - Diogo Biazus 5) Melhor artigo técnico publicado nos últimos 2 anos. - Euler Taveira - Fábio Telles - Rodrigo Hjort - Cláudio Bezerra Leopoldino - Dickson Guedes (PGCasts) Seu nome não está aqui e vc tem contribuido arduamente em projetos relacionados ao PostgreSQL? Não se preocupe e continue fazendo seu excelente trabalho porque a análise dos indicados será realizada todos os anos. Ainda não contribuiu? Está esperando o quê? Participe de projetos relacionados e ajude a continuar fazendo do PostgreSQL o banco de dados de código aberto mais avançado do mundo. Forte abraço e boa sorte!!! -Leo ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
