Como instalar o PostgreSQL 9.3 no Red Hat?!?
Siga os passos abaixo!
Repositório do PostgreSQL para o YUM do Red Hat !
http://yum.postgresql.org/9.3/redhat/rhel-6-x86_64/
Para instalar o PostgreSQL 9.3.5, por exemplo:
yum install http://yum.postgresql.org/9.3/redhat/rhel-6-x86_64/postgresql93-9.3.5-1PGDG.rhel6.x86_64.rpm
yum install http://yum.postgresql.org/9.3/redhat/rhel-6-x86_64/postgresql93-server-9.3.5-1PGDG.rhel6.x86_64.rpm
yum install http://yum.postgresql.org/9.3/redhat/rhel-6-x86_64/postgresql93-server-9.3.5-1PGDG.rhel6.x86_64.rpm
segunda-feira, 8 de setembro de 2014
terça-feira, 26 de agosto de 2014
Configurando o Proxy para o WGET
Editar as linhas abaixo no arquivo /etc/wgetrc
# You can set the default proxies for Wget to use for http, https, and ftp.
# They will override the value in the environment.
https_proxy = http://usuario:senha@proxy.com:porta/
http_proxy = http://usuario:senha@proxy.com:porta/
ftp_proxy = http://usuario:senha@proxy.com:porta/
# If you do not want to use proxy at all, set this to off.
use_proxy = on
# You can set the default proxies for Wget to use for http, https, and ftp.
# They will override the value in the environment.
https_proxy = http://usuario:senha@proxy.com:porta/
http_proxy = http://usuario:senha@proxy.com:porta/
ftp_proxy = http://usuario:senha@proxy.com:porta/
# If you do not want to use proxy at all, set this to off.
use_proxy = on
Solução para os problemas na instalação do PostgreSQL 9.3 no RedHat EL 6
O PROBLEMA:
yum install postgresql93
...
Error: Package: postgresql93-9.3.5-1PGDG.rhel6.x86_64 (pgdg93)
Requires: libssl.so.10(libssl.so.10)(64bit)
Error: Package: postgresql93-server-9.3.5-1PGDG.rhel6.x86_64 (pgdg93)
Requires: libcrypto.so.10(libcrypto.so.10)(64bit)
Error: Package: postgresql93-libs-9.3.5-1PGDG.rhel6.x86_64 (pgdg93)
Requires: libssl.so.10(libssl.so.10)(64bit)
Error: Package: postgresql93-server-9.3.5-1PGDG.rhel6.x86_64 (pgdg93)
Requires: libssl.so.10(libssl.so.10)(64bit)
Error: Package: postgresql93-libs-9.3.5-1PGDG.rhel6.x86_64 (pgdg93)
Requires: libcrypto.so.10(libcrypto.so.10)(64bit)
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles --nodigest
A SOLUCAO:
Baixei uma versão mais nova do OpenSSL
wget http://mirror.centos.org/centos/6/updates/x86_64/Packages/openssl-1.0.1e-16.el6_5.x86_64.rpm
Removi o openssl instalado usando o parâmetro --nodeps para evitar verificações de dependências.
rpm -e --nodeps openssl
E instalei o OpenSSL mais novo que foi baixado.
rpm -ivh openssl-1.0.1e-16.el6_5.x86_64.rpm
yum install postgresql93
...
Error: Package: postgresql93-9.3.5-1PGDG.rhel6.x86_64 (pgdg93)
Requires: libssl.so.10(libssl.so.10)(64bit)
Error: Package: postgresql93-server-9.3.5-1PGDG.rhel6.x86_64 (pgdg93)
Requires: libcrypto.so.10(libcrypto.so.10)(64bit)
Error: Package: postgresql93-libs-9.3.5-1PGDG.rhel6.x86_64 (pgdg93)
Requires: libssl.so.10(libssl.so.10)(64bit)
Error: Package: postgresql93-server-9.3.5-1PGDG.rhel6.x86_64 (pgdg93)
Requires: libssl.so.10(libssl.so.10)(64bit)
Error: Package: postgresql93-libs-9.3.5-1PGDG.rhel6.x86_64 (pgdg93)
Requires: libcrypto.so.10(libcrypto.so.10)(64bit)
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles --nodigest
A SOLUCAO:
Baixei uma versão mais nova do OpenSSL
wget http://mirror.centos.org/centos/6/updates/x86_64/Packages/openssl-1.0.1e-16.el6_5.x86_64.rpm
Removi o openssl instalado usando o parâmetro --nodeps para evitar verificações de dependências.
rpm -e --nodeps openssl
E instalei o OpenSSL mais novo que foi baixado.
rpm -ivh openssl-1.0.1e-16.el6_5.x86_64.rpm
segunda-feira, 16 de junho de 2014
Shell command FIND + CUT + REV - Como recuperar o último campo usando o comando CUT !
O comando CUT possui argumentos como o -d (delemitador) e o -f que indica qual campo recuperar.
Por exemplo
/pasta/arquivo1.ini
/pasta/pasta2/arquivo2.ini
Para recuperar apenas os nomes dos arquivos teríamos que indicar o delimitador "/" e o número do campo no comando CUT. Porém o número do campo iria varia pois no primeiro exemplo seria 2 e no segundo seria 3.
Como então recuperar o último campo?
Segue o comando:
find / -iname *.ini | rev | cut -d/ -f1 | rev
Recomando testarem da seguinte forma para entender o que o comando REV faz...
find / -iname *.ini | rev
find / -iname *.ini | rev | cut -d/ -f1
find / -iname *.ini | rev | cut -d/ -f1 | rev
Como eu queria apenas saber que nomes de arquivos .ini eu teria ainda adicionei um sort -u ao final para trazer apenas nomes de arquivos distintos!
find / -iname *.ini | rev | cut -d/ -f1 | rev | sort -u
=)
Por exemplo
/pasta/arquivo1.ini
/pasta/pasta2/arquivo2.ini
Para recuperar apenas os nomes dos arquivos teríamos que indicar o delimitador "/" e o número do campo no comando CUT. Porém o número do campo iria varia pois no primeiro exemplo seria 2 e no segundo seria 3.
Como então recuperar o último campo?
Segue o comando:
find / -iname *.ini | rev | cut -d/ -f1 | rev
Recomando testarem da seguinte forma para entender o que o comando REV faz...
find / -iname *.ini | rev
find / -iname *.ini | rev | cut -d/ -f1
find / -iname *.ini | rev | cut -d/ -f1 | rev
Como eu queria apenas saber que nomes de arquivos .ini eu teria ainda adicionei um sort -u ao final para trazer apenas nomes de arquivos distintos!
find / -iname *.ini | rev | cut -d/ -f1 | rev | sort -u
=)
quinta-feira, 15 de maio de 2014
Comprando a árvore de diretórios com o comando diff
$ diff -Naur website website-new diff -Naur website/index.shtml website-new/index.shtml --- website/index.shtml 2008-05-22 20:16:12.000000000 -0400 +++ website-new/index.shtml 2008-06-04 12:10:50.000000000 -0400 @@ -14,6 +14,7 @@+Welcome!
About: This subject is aimed at students with little or no diff -Naur website/style.css website-new/style.css --- website/style.css 2008-04-11 01:25:12.000000000 -0400 +++ website-new/style.css 2008-06-04 12:11:01.000000000 -0400 @@ -24,7 +24,7 @@ color: white; text-decoration: none; font-weight: bold; padding: 0 0.25em; } -div#body { padding: 0.1em 55px 2em 55px; font-size: small } +div#body { padding: 0.1em 55px 2em 55px; font-size: medium } dd { margin-bottom: 1em }
Agora se você quer ver apenas rapidamente os arquivos diferentes:
$ diff -qr website website-new Files website/index.shtml and website-new/index.shtml differ Files website/style.css and website-new/style.css differ
O rsync faz algo similar quando a máquina é remota. A opção -n faz com que o comando seja executado apenas como teste apenas e não faz mudança alguma na máquina remota. A última barra ao especificar os diretório é muito importante nesse caso.
$ rsync -rvnc --delete website/ laptop:projects/website/ deleting schedule.shtml style.css
Como mover os índices para uma nova tablespace (postgres)
create tablespace 'fastspace' owner 'owner' location 'directory'
select 'ALTER INDEX '||schemaname||'.'||indexname||' SET TABLESPACE fastspace ;' from
pg_catalog.pg_indexes where schemaname = 'public' order by tablename;
Agora é só executar os comandos gerados pelo select!
Fonte: http://codingandmore.blogspot.com.br/2010/05/moving-indexes-in-postgres-to-new.html
Configurando o Proxy no Ubuntu para o apt-get
Configurando o apt-get para usar proxy com autenticação
Edite o arquivo /etc/apt/apt.conf colocando as seguintes linhas (substituindo o linux.juice pelo seu usuário e o 123456 pela usa senha, o ip 192.168.179.222 e a porta 80 pela seu IP do seu servidor proxy e sua PORTA).# nano -w /etc/apt/apt.conf
Dentro deste arquivo deve-se colocar o seguinte:
Acquire{
HTTP::proxy "http://linux.juice:123456@192.168.179.222:80";
FTP::proxy "http://linux.juice:123456@192.168.179.222:80";
}
HTTP::proxy "http://linux.juice:123456@192.168.179.222:80";
FTP::proxy "http://linux.juice:123456@192.168.179.222:80";
}
Fonte: http://www.vivaolinux.com.br/dica/Configurar-o-APTGET-com-proxy-com-e-sem-autenticacao
segunda-feira, 14 de abril de 2014
Atualizando o OpenSuse usando o zypper
Acesse o link e veja os links para vários repositórios do OpenSuSe
https://en.opensuse.org/Package_repositories
Para adicioná-los de modo rápido e fácil use o comando
zypper ar -f url alias
Ou seja para versão 13.1:
zypper ar -f http://download.opensuse.org/update/13.1/ update-13.1
zypper ar -f http://download.opensuse.org/distribution/13.1/repo/oss/ repo-oss-13.1
zypper ar -f http://download.opensuse.org/distribution/13.1/repo/non-oss/ repo-non-oss-13.1
zypper ar -f http://download.opensuse.org/update/13.1-non-oss/ update-non-oss-13.1
Ah aprenda a usar o Zypper e dê Adeus ao Yast!
O zypper é muito melhor!
:)
https://en.opensuse.org/Package_repositories
Para adicioná-los de modo rápido e fácil use o comando
zypper ar -f url alias
Ou seja para versão 13.1:
zypper ar -f http://download.opensuse.org/update/13.1/ update-13.1
zypper ar -f http://download.opensuse.org/distribution/13.1/repo/oss/ repo-oss-13.1
zypper ar -f http://download.opensuse.org/distribution/13.1/repo/non-oss/ repo-non-oss-13.1
zypper ar -f http://download.opensuse.org/update/13.1-non-oss/ update-non-oss-13.1
Ah aprenda a usar o Zypper e dê Adeus ao Yast!
O zypper é muito melhor!
:)
Problemas com o Proxy no OpenSuSe
Após várias tentativas de configuração do proxy via Yast e via variáveis de ambiente... Achei a solução!
Editar manualmente o arquivo
Editar manualmente o arquivo
vi /etc/sysconfig/proxy
Se o seu proxy necessitar de usuário e senha usar o seguinte padrão na configuração
HTTP_PROXY="http://user:password@proxyhost:port"
:)
sexta-feira, 28 de março de 2014
Como contornar os badblocks do seu HD!!!
Antes de fazer qualquer coisa garanta um backup da partição que você vai realizar os procedimentos de manutenção!
Primeiramente desmonte a partição onde você precisa mapear os badblocks.
No meu caso era a partição /dev/sdb1 e ela estava montada na pasta /dados
# umount /dados
Em seguida, efetue o comando e2fsck -c
# e2fsck -c /dev/sdb1
ou
# e2fsck -cc /dev/sdb1
O parâmetro -c usa o programa badblocks para realizar um escaneamento de leitura no dispositivo para encontrar os bad blocks. Se houver bad blocks, eles serão adicionados ao bad block inode para prevenir que eles sejam alocados a um arquivo ou diretório.
Quando esse parâmetro é usado de forma duplicada (-cc), o escaneamento dos badblocks serão realizados usando um teste de leitura e escrita não destrutivos.
Fonte: http://linux.die.net/man/8/e2fsck
Primeiramente desmonte a partição onde você precisa mapear os badblocks.
No meu caso era a partição /dev/sdb1 e ela estava montada na pasta /dados
# umount /dados
Em seguida, efetue o comando e2fsck -c
# e2fsck -c /dev/sdb1
ou
# e2fsck -cc /dev/sdb1
O parâmetro -c usa o programa badblocks para realizar um escaneamento de leitura no dispositivo para encontrar os bad blocks. Se houver bad blocks, eles serão adicionados ao bad block inode para prevenir que eles sejam alocados a um arquivo ou diretório.
Quando esse parâmetro é usado de forma duplicada (-cc), o escaneamento dos badblocks serão realizados usando um teste de leitura e escrita não destrutivos.
Fonte: http://linux.die.net/man/8/e2fsck
quinta-feira, 27 de março de 2014
Login via ssh demorando muito para conectar
Se o login via ssh está tomando muito tempo.
Você efetua o comando e leva um bom tempo até que ele solicite a senha...
Isso pode ser um problema de DNS.
É necessário configurar o aruqivo /etc/hosts adicionado as seguinte linhas
127.0.0.1 localhost, nomedamaquin
192.168.0.1 nomedamaquina
Onde o ip 192.168.0.1 é um ip que a máquina tem para se conectar a rede.
Outra alteração que deve ser feita para sanar o problema é editar o arquivo sshd_config do serivdor.
vi /etc/ssh/sshd_config
Mudar a linha de
UseDNS yes
para
UseDNS no
Muitas vezes essa linha está comentada, então descomente e sete o UseDNS para no .
Reinicie o serviço de ssh
no SuSe:
rcsshd restart
no CentOS/RedHat
service sshd restart
Agora teste novamente!
É pra estar uma bala!
Você efetua o comando e leva um bom tempo até que ele solicite a senha...
Isso pode ser um problema de DNS.
É necessário configurar o aruqivo /etc/hosts adicionado as seguinte linhas
127.0.0.1 localhost, nomedamaquin
192.168.0.1 nomedamaquina
Onde o ip 192.168.0.1 é um ip que a máquina tem para se conectar a rede.
Outra alteração que deve ser feita para sanar o problema é editar o arquivo sshd_config do serivdor.
vi /etc/ssh/sshd_config
Mudar a linha de
UseDNS yes
para
UseDNS no
Muitas vezes essa linha está comentada, então descomente e sete o UseDNS para no .
Reinicie o serviço de ssh
no SuSe:
rcsshd restart
no CentOS/RedHat
service sshd restart
Agora teste novamente!
É pra estar uma bala!
Correção do Dicas de Tunning
A melhor consulta para descobrir as piores tabelas é essa!
SELECT relname AS table_name,
seq_scan, seq_tup_read, idx_tup_fetch
FROM pg_stat_user_tables
WHERE (seq_tup_read + idx_tup_fetch) > 0
ORDER BY seq_tup_read desc, seq_scan desc;
Alterei apenas a ordem do order by
DE
seq_scan desc, seq_tup_read desc;
PARA
seq_tup_read desc, seq_scan desc;
Na consulta do post passado eu tinha ordenador primeiro pelo número de table scans e depois pelo número de tuplas lidas por meio de table scans.
A melhor forma é justamente o contrário, pois teremos de cara as piores tabelas do nosso banco de dados que serão aquelas tabelas gigantes que tem muitas tuplas lidas por table scan.
SELECT relname AS table_name,
seq_scan, seq_tup_read, idx_tup_fetch
FROM pg_stat_user_tables
WHERE (seq_tup_read + idx_tup_fetch) > 0
ORDER BY seq_tup_read desc, seq_scan desc;
Alterei apenas a ordem do order by
DE
seq_scan desc, seq_tup_read desc;
PARA
seq_tup_read desc, seq_scan desc;
Na consulta do post passado eu tinha ordenador primeiro pelo número de table scans e depois pelo número de tuplas lidas por meio de table scans.
A melhor forma é justamente o contrário, pois teremos de cara as piores tabelas do nosso banco de dados que serão aquelas tabelas gigantes que tem muitas tuplas lidas por table scan.
Configurar o YUM para usar um proxy no CentOS
vi /etc/yum.conf
Adicione as seguintes linhas
# The proxy server - proxy server:port number
proxy=http:/ip_do_servidor:porta
# The account details for yum connections
proxy_username=usuario
proxy_password=senha
Adicione as seguintes linhas
# The proxy server - proxy server:port number
proxy=http:/ip_do_servidor
# The account details for yum connections
proxy_username=usuario
proxy_password=senha
Dicas de Tunning no Postgres
--Verificar quais tabelas possuem mais table scans/sequential scans (coluna seq_scan)
SELECT relname AS table_name,
seq_scan, seq_tup_read, idx_tup_fetch
FROM pg_stat_user_tables
WHERE (seq_tup_read + idx_tup_fetch) > 0
ORDER BY seq_scan desc, seq_tup_read desc;
Dentre as tabelas com mais table scans verifique as que maiores em quantidades de linhas, pois muitas vezes o tablescan não é tão pesado se a tabela possuir poucos registros. Uma tabela com 10 linhas não causa tanto problema se forem realizados muitos table scans, porém uma tabela com 2milhoões de linhas já causa um estrago grande!
Vendo isso encontrei uma tabela de log que estava entre as dez com maior número de consulta que efetuaram table scans. Busquei no sistema quais select que estavam causando esse problema, criei um índica para a coluna id_usuario e daí a consulta que demorava 2 segundos para executar passou para 12ms!
Para analisar a atividade no banco no momento da consulta.
SELECT *
FROM pg_catalog.pg_stat_activity
Se houver uma consulta demorada, você vai ver ela aparecer com frequência nessa consulta.
Copie a consulta que aparecerá na coluna current_query e verifique quanto tempo demora para executá-la. Analise as cláusulas WHERE e crie índices para as principais colunas.
SELECT relname AS table_name,
seq_scan, seq_tup_read, idx_tup_fetch
FROM pg_stat_user_tables
WHERE (seq_tup_read + idx_tup_fetch) > 0
ORDER BY seq_scan desc, seq_tup_read desc;
Dentre as tabelas com mais table scans verifique as que maiores em quantidades de linhas, pois muitas vezes o tablescan não é tão pesado se a tabela possuir poucos registros. Uma tabela com 10 linhas não causa tanto problema se forem realizados muitos table scans, porém uma tabela com 2milhoões de linhas já causa um estrago grande!
Vendo isso encontrei uma tabela de log que estava entre as dez com maior número de consulta que efetuaram table scans. Busquei no sistema quais select que estavam causando esse problema, criei um índica para a coluna id_usuario e daí a consulta que demorava 2 segundos para executar passou para 12ms!
Para analisar a atividade no banco no momento da consulta.
SELECT *
FROM pg_catalog.pg_stat_activity
Se houver uma consulta demorada, você vai ver ela aparecer com frequência nessa consulta.
Copie a consulta que aparecerá na coluna current_query e verifique quanto tempo demora para executá-la. Analise as cláusulas WHERE e crie índices para as principais colunas.
Assinar:
Postagens (Atom)