Rafael Lima » servidor

Rodando scripts binários 32bits em plataformas 64bits com linux baseado em Debian

Rafael Lima — Sun, 03 May 2009 02:39:55 +0000

Atualizado: Pareceu o dia inteiro, quando escrevi isso, mas depois constatei que foram umas 5 horas.

Hoje eu passei o dia inteiro tentando colocar um script binário escrito em C, para rodar no meu servidor novo. Depois de quebrar muito a cabeça entrei no chat do serviço de hospedagem, pois já estava achando que era problema de hardware ou das máquinas virtuais.

O suporte em princípio não ajudou muito mas no final, quando eu citei que conseguia fazer o script rodar em outro servidor, o atendente do suporte me perguntou se eu sabia se o outro servidor era 32bits.

Só neste momento que eu me liguei neste problema. Nem tinha pensando nisso até então. Entrei na página do script e vi que ele era escrito para a plataforma 32bits.

Uma rápida busca me levou para a página The Debian GNU/Linux AMD64 HOW-TO

Como uso Ubuntu na máquina virtual, fiz o primeiro passo que era instalar o pacote ia32-libs e tudo funcionou.

apt-get install ia32-libs

A título de indexação nos sistemas de busca, colocarei abaixo os erros que encontrei durante o processo.

Premature end of script headers:
(2)No such file or directory: exec of /xxx failed
HTTP Error 500 – Internal server error

Como era um script cgi, mais algumas palavras chaves são relevantes: apache apache2 cgi-bin script Options ExecCGI script-alias SetHandler cgi-script

Por hoje chega!

Cuidado ao fazer migração de repositório subversion

Rafael Lima — Wed, 22 Apr 2009 12:22:40 +0000

Este final de semana eu fiz uma migração de um servidor subversion. Como eu esperava, teria algumas dores de cabeça pois o subversion é muito sensível. Fiz muitos testes durane o processo e consegui uma maneira que funcionasse.

No final das contas consegui migrar todo o repositório de um servidor para outro e manter a mesma URL de modo que ficasse transparente para os clients, evitando a necessidade de rodar um “svn switch –relocate” em cada working copy.

O problema é que quando fui usar hoje, dois dias depois, eu consegui acessar o repositório pela web, mas não consegui fazer um checkout.

A Lei de Murphy está aí para isso

Depois de perquisar um pouqinho, descobri que foi uma configuração que fiz por último e que é uma verdadeira pegadinha. No caso eu estou usando o Apache2 com mod_dav.

A pegadinha é que você não pode configurar o DocumentRoot com o mesmo path do SVNParentPath. Tem outros casos que causam o mesmo problema, basicamente o fato de existir um diretório no DocumentRoot com o mesmo nome do repositório controlado pelo DAV gera um conflito e o servidor se perde.

Mais informações sobre isso podem ser encontradas em: http://subversion.tigris.org/faq.html#301-error

Espero que seja útil!

Abraços e até a próxima.

Segurança e Hardening de servidores linux

Rafael Lima — Mon, 06 Oct 2008 04:48:57 +0000

Este final de semana fiquei envolvido com questões de segurança nos servidores da BielSystems. Deixo aqui uma sopinha de letras para quem quiser buscar ler mais sobre o assunto.

Alguns links interessantes:
http://www.puschitz.com/SecuringLinux.shtml
http://www.gentoo.org/doc/en/security/security-handbook.xml

Configurando sistema de backup do banco de dados MySQL no Amazon S3 em 10 minutos

Rafael Lima — Thu, 20 Mar 2008 05:20:11 +0000

Por indicação do William, passei a usar o AutoMySQLBackup em conjunto com um script de sincronização de diretórios no Amazon S3, para realizar backup dos bancos de dados MySQL dos servidores dedicados da BielSystems.

Este script é bem completo e tem tudo que alguém pode precisar para um sistema de backup eficiente e seguro em ambiente de produção.

Abaixo segue o “pacacá” de instalação:

Por motivos de segurança, sugiro que você crie um usuário somente para backup, que tenha permissão apenas de leitura (SELECT). Para fazer isso, conforme sugerido aqui, rode o comando abaixo no servidor que possui o MySQL instalado.

$ mysql -u root -p -e "GRANT SELECT, LOCK TABLES ON *.* TO ‘backup’@'localhost’ IDENTIFIED BY ‘escolha-uma-senha’;"

Depois disso baixe o script AutoMySQLBackup no seu diretório de scripts, por exemplo, /usr/local/scripts

$ mkdir -p /usr/local/scripts
$ cd /usr/local/scripts
$ wget -c http://ufpr.dl.sourceforge.net/sourceforge/automysqlbackup/automysqlbackup.sh.2.5

Edite o arquivo com seu editor preferido (ex: nano -w automysqlbackup.sh.2.5) e configure os parâmetros. Fora os parâmetros de acesso ao banco de dados (lembre-se de usar o usuário backup que foi criado no passo anterior), sugiro a alteração destes parâmetros:

# Mail setup
# What would you like to be mailed to you?
# – log : send only log file
# – files : send log file and sql files as attachments (see docs)
# – stdout : will simply output the log to the screen if run manually.
# – quiet : Only send logs if an error occurs to the MAILADDR.
MAILCONTENT="log"

# Separate backup directory and file for each DB? (yes or no)
SEPDIR=yes

# Additionally keep a copy of the most recent backup in a seperate directory.
LATEST=yes

Coloque o script para rodar no cron diariamente.

$ cd /etc/cron.daily
$ ln -s /usr/local/scripts/automysqlbackup.sh.2.5 automysqlbackup

Enviando os arquivos de backup para uma conta no Amazon S3

Para enviar o backup realizado para um conta no Amazon S3, que é o web service de storage da Amazon, siga as instruções abaixo que foram retiradas deste link.

Antes de mais nada, instale o ruby 1.8.4 ou mais novo e a biblioteca de ssl para o ruby.

$ sudo apt-get install ruby libopenssl-ruby

Confirme a versão do ruby

$ ruby -v
ruby 1.8.6 (2008-03-03 patchlevel 114) [i686-linux]

Agora vamos instalar o s3sync que é um script de sincronização de diretórios locais com diretórios no S3.

Vá para o diretório que você deseja instalar o s3sync, como por exemplo /usr/local/scripts

$ cd /usr/local/scripts

Faça o download e descompacte:

$ wget http://s3.amazonaws.com/ServEdge_pub/s3sync/s3sync.tar.gz
$ tar xvzf s3sync.tar.gz

Remova o arquivo compactado:

$ rm s3sync.tar.gz

Crie um diretório para os certificados e baixe alguns:

$ cd s3sync
$ mkdir certs
$ cd certs
$ wget http://mirbsd.mirsolutions.de/cvs.cgi/~checkout~/src/etc/ssl.certs.shar

rode o instalador dos certificados

$ sh ssl.certs.shar

Pronto, s3sync instalado!

Vamos agora criar um script que pega os últimos arquivos de backup e envia para a sua conta do S3.

Crie o arquivo de script com o conteúdo abaixo. Exemplo: /usr/local/scripts/automysqlbackup-upload-to-s3.sh

#!/bin/bash
cd /usr/local/scripts/s3sync
export AWS_ACCESS_KEY_ID=yourS3accesskey
export AWS_SECRET_ACCESS_KEY=yourS3secretkey
export SSL_CERT_DIR=/usr/local/scripts/s3sync/certs
ruby s3sync.rb -r –ssl –delete /backups/latest nomedobucket:backup/mysql

Observações:

O comando –delete diz para o s3sync excluir os arquivos que existem no S3 mas não existem mais na pasta local.
Para enviar somente os últimos backups (diretório latest), é necessário que o parâmetro LATEST seja igual a yes no AutoMySQLBackup
Atenção para o nome do bucket, para os paths e principalmente para o path /backups/latest que deve conter o diretório que está configurado no parâmetro BACKUPDIR do AutoMySQLBackup concatenado com “/latest”.

O último passo é configurar o AutoMySQLBackup para rodar o script de envio dos arquivos para o S3 logo após cada backup.

Para isso altere o parâmetro POSTBACKUP como o exemplo abaixo:

# Command run after backups (uncomment to use)
POSTBACKUP="/usr/local/scripts/automysqlbackup-upload-to-s3.sh"

Parabéns, você já está com um backup seguro e eficiente!

Abraços e até a próxima.