Depois de muito procurar, acabei encontrando este tutorial bem legal que explica como fazer para recompilar códigos-fonte de uma distribuição. Tá, mas qual a diferença disso e de compilar um código-fonte baixado? Não é tão óbvio, mas em algumas situações, um pacote tem algumas dependências não diretas, isto é, que o pacote não as carrega consigo explicitamente, sendo que o gerenciador de pacotes não as identifica, portanto. Isso implica em compilar um código-fonte que, de repente, não funciona com o resto da distribuição ou precisa de OUTRAS compilações de OUTROS códigos-fonte para funcionar. Dá pra imaginar onde isso pode (ou não) acabar né?
Bom, indo direto ao assunto: precisamos de alguns pacotes instalados para viabilizar as compilações. Isto pode ser feito através de
$sudo apt-get install build-essential fakeroot dpkg-dev
Depois, para organizar o processo, criamos uma pasta:
$mkdir [nome do programa]
$cd [nome do programa]
Agora podemos fazer a instalação do código-fonte e, em seguida, resolver as dependências:
$sudo apt-get source [nome do programa]
$sudo apt-get build-dep [nome do programa]
Descompactamos com a ferramenta de manipulação o arquivo Debian source package (.dsc):
$sudo dpkg-source -x [nome do programa_versão-revisão].dsc
Finalmente, para compilar o código-fonte:
$cd [nome do programa_versão-revisão]
$sudo dpkg-buildpackage -rfakeroot -b
Se for necessário adicionar parâmetros à compilação; por exemplo --enable-qqcoisa --disable-umtrem; ANTES de compilar, sete os valores na variável DEB_BUILD_OPTIONS. Explicitando o exemplo:
$DEB_BUILD_OPTIONS="--enable-qqcoisa --disable-umtrem"
Os pacotes gerados serão criados no diretório imediatamente acima do que estamos, isto é [nome do programa_versão-revisão] e podem ser instalados, se forem mais de um, em lote ou um por vez através dos comandos:
$cd .. $dpkg -i [nome do programa]*
Com certeza, muita coisa pode acontecer nesse meio tempo e, ao final, não funcionar ou funcionar parcialmente. Claro, estamos lidando com muitos comandos e não gosto de "atropelar" com tanta informações mas não faz muito sentido fazer o processo parcialmente ou explicar só alguns dos comandos pois eles trabalham em conjunto para um resultado final. Caso encontre dificuldade em algum momento do processo, reveja os passos, divida para conquistar, google na cabeça e boa sorte!
21 de maio de 2009
ssh e segurança
Existem situações onde o ssh aberto pode ser prejudicial à máquina. Por "aberto", definimos quando é possível logar através de usuário root, login com senha em branco e, bem especialmente, login de uma base de dados de usuário externa.
Vou explicar cada um dos casos e como garantir a segurança neles. Todas elas são configuradas no arquivo /etc/ssh/sshd_config.
Quanto temos login através do usuário root, o problema consiste na possibilidade de tentarem, através de força bruta, um login bem sucedido. Para impedir isto, somente precisamos configurar o openssh. Fica assim:
$vi /etc/ssh/sshd_config
acrescentar "PermitRootLogin no" ou mudar o parâmetro, se existir, de "yes" para "no".
O segundo caso, senha em branco, é mais raro porque o próprio arquivo de configuração desaconselha este procedimento. Mas, caso esteja assim configurado, no mesmo arquivo, devemos mudar a opção "PermitEmptyPasswords" para "no", garantindo assim que usuários com senha em branco não possam logar.
O terceiro caso trata da possibilidade de autenticarmos em um servidor externo, isto é, não são necessariamente usuários do próprio sistema e quem garante a autenticação é um agente externo. Ocorre quando estamos fazendo uso de samba, ldap ou qualquer outro mecanismo de gerenciamento de autenticação que permite login. Para corrigirmos isto, acrescentamos o parâmetro "AllowUsers" seguida da lista de usuários permitidos, separados por espaços em branco, sendo estes pertencentes ao sistema ou não, considerando que a autenticação não é garantida pela própria máquina. Independente da autenticação externa, esta configuração também se aplica a restrição de usuários no caso de querermos que somente alguns tenham permissão de uso de ssh.
Obs: não esqueça de reiniciar o serviço ($/etc/init.d/ssh restart) após salvar o arquivo, para aplicar as alterações. Note que esta reinicialização não afeta usuários já conectados.
Vou explicar cada um dos casos e como garantir a segurança neles. Todas elas são configuradas no arquivo /etc/ssh/sshd_config.
Quanto temos login através do usuário root, o problema consiste na possibilidade de tentarem, através de força bruta, um login bem sucedido. Para impedir isto, somente precisamos configurar o openssh. Fica assim:
$vi /etc/ssh/sshd_config
acrescentar "PermitRootLogin no" ou mudar o parâmetro, se existir, de "yes" para "no".
O segundo caso, senha em branco, é mais raro porque o próprio arquivo de configuração desaconselha este procedimento. Mas, caso esteja assim configurado, no mesmo arquivo, devemos mudar a opção "PermitEmptyPasswords" para "no", garantindo assim que usuários com senha em branco não possam logar.
O terceiro caso trata da possibilidade de autenticarmos em um servidor externo, isto é, não são necessariamente usuários do próprio sistema e quem garante a autenticação é um agente externo. Ocorre quando estamos fazendo uso de samba, ldap ou qualquer outro mecanismo de gerenciamento de autenticação que permite login. Para corrigirmos isto, acrescentamos o parâmetro "AllowUsers" seguida da lista de usuários permitidos, separados por espaços em branco, sendo estes pertencentes ao sistema ou não, considerando que a autenticação não é garantida pela própria máquina. Independente da autenticação externa, esta configuração também se aplica a restrição de usuários no caso de querermos que somente alguns tenham permissão de uso de ssh.
Obs: não esqueça de reiniciar o serviço ($/etc/init.d/ssh restart) após salvar o arquivo, para aplicar as alterações. Note que esta reinicialização não afeta usuários já conectados.
19 de maio de 2009
vi - comandos avançados
O vi ou vim, para quem não conhece, é um editor de shell muito poderoso e bem fácil de usar. Um colega meu (Diógenes!!!), adora emacs, mas eu conheço muito pouco pra falar deles e, por enquanto, o vi me resolve a vida.
Hoje me deparei com uma situação bem inusitada: precisava abrir um arquivo e ver seu conteúdo... na linha 50000!!!! É um arquivo de dump de uma base de dados do postgres, ou seja, todo o conteúdo da base foi portado para o modo texto, por isso a imensidão de linhas. De qualquer forma, o comando é bem útil para qualquer situação onde não queremos abrir o arquivo no início, mas em uma outra posição.
$vi + [número da linha]
Só para constar: não precisa dos [] no comando ok? É bom falar, sempre tem um louco o outro que acha que faz parte da sintaxe...
Hoje me deparei com uma situação bem inusitada: precisava abrir um arquivo e ver seu conteúdo... na linha 50000!!!! É um arquivo de dump de uma base de dados do postgres, ou seja, todo o conteúdo da base foi portado para o modo texto, por isso a imensidão de linhas. De qualquer forma, o comando é bem útil para qualquer situação onde não queremos abrir o arquivo no início, mas em uma outra posição.
$vi + [número da linha]
Só para constar: não precisa dos [] no comando ok? É bom falar, sempre tem um louco o outro que acha que faz parte da sintaxe...
diff e patch remoto
Uma coisa bem chata de resolver é a comparação entre arquivos de configuração entre uma máquina local e remota, ou ainda, entre duas remotas. A grande dificuldade consiste na falta de identificação de quais linhas são diferentes realmente e quais são configurações locais, isto é, aplicadas àquele servidor em especial.
Afortunados como eu ( :D ) , que tem dois monitores, que podem colocar dois terminais lado a lado e compará-los também acabam encontrando dificuldade quando falamos de 100 ou mais linhas, ou mesmo quando a ordem entre os parâmetros dentro do arquivo foram alteradas.
Uma forma bem interessante de resolver o problema seria recorrer a cópias dos arquivos para máquina local e compará-los através do $diff. Mas, eu encontrei uma ainda mais completa e direta, que consiste na aplicação de três comandos para gerar um patch, que pode ser facilmente aplicado sobre o arquivo que estamos configurando.
O comando seria:
$ssh [user]@[host] cat [arquivo alvo remoto] | diff [arquivo alvo local] - > [arquivo].patch
Explicando o comando: Fazemos uma conexão ($ssh), damos um echo ($cat) do arquivo remoto. Aqui vale uma explicação: nosso echo fica armazenado para ser aplicado a seguir, quando usaremos o $-, repassando-o. Prosseguindo: continuamos o comando através de um pipe-line ($|), aplicamos o programa de comparação ($diff) no arquivo local (agora sim, nosso $-) e, finalmente, gravamos esta comparação em um arquivo, ($> arquivo.patch).
Com este patch em mãos, podemos simplesmente utilizar o comando $patch [arquivo a ser modificado] [arquivo de patch] para aplicá-lo no arquivo local que queremos tornar igual ao arquivo remoto. Vale uma observação aqui também: devemos revisar o arquivo, seja ele na forma de patch, antes de aplicá-lo, seja depois, o arquivo local corrigido, pois as configurações locais devem condizer com nossos parâmetros locais.
Afortunados como eu ( :D ) , que tem dois monitores, que podem colocar dois terminais lado a lado e compará-los também acabam encontrando dificuldade quando falamos de 100 ou mais linhas, ou mesmo quando a ordem entre os parâmetros dentro do arquivo foram alteradas.
Uma forma bem interessante de resolver o problema seria recorrer a cópias dos arquivos para máquina local e compará-los através do $diff. Mas, eu encontrei uma ainda mais completa e direta, que consiste na aplicação de três comandos para gerar um patch, que pode ser facilmente aplicado sobre o arquivo que estamos configurando.
O comando seria:
$ssh [user]@[host] cat [arquivo alvo remoto] | diff [arquivo alvo local] - > [arquivo].patch
Explicando o comando: Fazemos uma conexão ($ssh), damos um echo ($cat) do arquivo remoto. Aqui vale uma explicação: nosso echo fica armazenado para ser aplicado a seguir, quando usaremos o $-, repassando-o. Prosseguindo: continuamos o comando através de um pipe-line ($|), aplicamos o programa de comparação ($diff) no arquivo local (agora sim, nosso $-) e, finalmente, gravamos esta comparação em um arquivo, ($> arquivo.patch).
Com este patch em mãos, podemos simplesmente utilizar o comando $patch [arquivo a ser modificado] [arquivo de patch] para aplicá-lo no arquivo local que queremos tornar igual ao arquivo remoto. Vale uma observação aqui também: devemos revisar o arquivo, seja ele na forma de patch, antes de aplicá-lo, seja depois, o arquivo local corrigido, pois as configurações locais devem condizer com nossos parâmetros locais.
senha do postgres
Volta e meia preciso trocar ou recuperar esta senha. É fácil e bastante familiar para quem tem conhecimento em sql, apesar de não tão fácil assim chegar no ponto exato onde o sql pode ser executado.
Basicamente, uma vez logado como root, em ubuntu: $sudo -s, simplesmente trocamos o usuário através de $su postgres. Acessamos o programa postgres em modo shell, $psql.
A partir dai, qualquer comando em sql será entendido, pois estamos no ambiente do postgres e seus comandos nativos são, na grande maioria, sqls.
Nesse modo, aplicamos
$alter user postgres with password 'sua senha';
e pronto, senha de superuser postgres redefinida.
Basicamente, uma vez logado como root, em ubuntu: $sudo -s, simplesmente trocamos o usuário através de $su postgres. Acessamos o programa postgres em modo shell, $psql.
A partir dai, qualquer comando em sql será entendido, pois estamos no ambiente do postgres e seus comandos nativos são, na grande maioria, sqls.
Nesse modo, aplicamos
$alter user postgres with password 'sua senha';
e pronto, senha de superuser postgres redefinida.
7 de maio de 2009
Alterando o editor do crontab
Na maioria das distribuições, o padrão é o nano, que eu pessoalmente não gosto.
Vi algumas formas de alterar o editor do crontab e as soluções indicam formas de alterar variáveis de sistema ou editar arquivos source do bash pessoal; enfim, soluções que considero obscuras para um usuário leigo e que, se mal feitas, ocasionar danos no sistema ou deixam "lixo" perdido nos arquivos de configuração.
Se quiser mudar para o vim ou para o vi, encontrei uma solução que considero mais elegante. Para executá-la, podemos utilizar o seguinte comando:
$ update-alternatives --config editor
Este comando vai, de maneira ampla, alterar o editor padrão para todo o sistema, não só para o crontab. De qualquer forma, as outras soluções encontradas também agem assim, mas sempre é bom avisar de efeitos não necessariamente esperados.
Vi algumas formas de alterar o editor do crontab e as soluções indicam formas de alterar variáveis de sistema ou editar arquivos source do bash pessoal; enfim, soluções que considero obscuras para um usuário leigo e que, se mal feitas, ocasionar danos no sistema ou deixam "lixo" perdido nos arquivos de configuração.
Se quiser mudar para o vim ou para o vi, encontrei uma solução que considero mais elegante. Para executá-la, podemos utilizar o seguinte comando:
$ update-alternatives --config editor
Este comando vai, de maneira ampla, alterar o editor padrão para todo o sistema, não só para o crontab. De qualquer forma, as outras soluções encontradas também agem assim, mas sempre é bom avisar de efeitos não necessariamente esperados.
6 de maio de 2009
SSH com login automático
Várias vezes eu utilizo esta informação para fazer a configuração de do ssh para login automático em servidores que administro. Vou duplicar a informação porque links bons constumam ser apagados ou podem cair no desuso. Vai saber né...
Sem maiores explicações técnicas, basicamente o que podemos fazer é gerar chaves pública-privada que permitem identificar um computador que está sendo contatado por outro, sem a necessidade de digitação de senha.
Vou passar a lista de comandos necessários para realizar esta automação.
No cliente, para gerar par de chaves:
$ ssh-keygen -b 2048 -t rsa
Serão pedidos alguns parâmetros, mas somente digite enter para todos, uma vez que não queremos nada além das configurações padrão e não queremos digitar senha no momento do login.
O próximo passo é transferir a chave pública para o servidor que queremos ter login direto. Para isso usamos o seguinte comando:
$ scp ~/.ssh/id_rsa.pub:~/.ssh/authorized_keys
Assim, transferimos a chave e a renomeamos para que o sistema entenda que deve usá-la para identificar a máquina do usuário.
Sem maiores explicações técnicas, basicamente o que podemos fazer é gerar chaves pública-privada que permitem identificar um computador que está sendo contatado por outro, sem a necessidade de digitação de senha.
Vou passar a lista de comandos necessários para realizar esta automação.
No cliente, para gerar par de chaves:
$ ssh-keygen -b 2048 -t rsa
Serão pedidos alguns parâmetros, mas somente digite enter para todos, uma vez que não queremos nada além das configurações padrão e não queremos digitar senha no momento do login.
O próximo passo é transferir a chave pública para o servidor que queremos ter login direto. Para isso usamos o seguinte comando:
$ scp ~/.ssh/id_rsa.pub
Assim, transferimos a chave e a renomeamos para que o sistema entenda que deve usá-la para identificar a máquina do usuário.
Assinar:
Postagens (Atom)
