quarta-feira, 29 de dezembro de 2010

Controlando o Autostart do KDE 4

Para quem usa o KDE4 (ou mesmo versões anteriores do KDE), certamente já é claro que existe uma maneira de controlar o que deve ou não ser iniciado diretamente no momento do login (quando a sua seção se inicia). Este recurso é chamado "Autostart". Este artigo mostra de maneira fácil e rápida como gerenciar os programas que devem ser iniciados automaticamente, ou seja, que devem constar no Autostart do KDE.


  • Onde está o Autostart??

O Autostart nada mais é do que um diretório com informações dos programas que devem ser iniciados automaticamente. Existem dois desses diretórios, a saber, um a nível geral do sistema (controlado pelo root) e outro a nível de usuário:

# Autostart do usuário
ls /home/usuario/.kde/share/autostart/
# substitua "usuario" pelo nome de seu usuario!!

# Autostart do sistema
ls /usr/share/autostart/

OBS: em algumas distribuições, o diretório do usuário pode estar em "/home/usuario/.kde/Autostart/".

Assim, remover um programa chato que inicia automaticamente sem ser desejado consiste apenas em verificar o nome dele nestas duas listagens acima e apagar seu(s) respectivo(s) arquivo(s).


  • Controlando o Autostart do KDE Graficamente

Uma outra maneira (a nível de usuário) de controlar graficamente o que inicia com o KDE4 é acessar as Configurações do Sistema (System Settings), aba Avançado (Advanced) e clicar no ícone "Iniciar Automaticamente". Note que este recurso não informa o que é iniciado automaticamente segundo as configurações gerais do sistema, porém apenas segundo as configurações particulares do usuário. Vide a imagem abaixo:



Existem dois botões nesta janela:

Adicionar Programa: Permite que um programa existente no seu menu K seja selecionado e adicionado ao seu Autostart.
Adicionar Script: se você tem um script executável (que, no entanto, não está presente no menu K), ele pode ser adicionado através deste botão.

OBS: aparentemente, esta solução gráfica opera independentemente dos diretórios acima mencionados. Assim, possivelmente o que você adicionar aqui não encontrará correspondente nos diretórios mostrados, mas é bom conhecer as duas maneiras, para saber investigar seu sistema e conhecer o que realmente está acontecendo!


  • O Que Tem Nesses Diretórios do Autostart??

São simplesmente pequenos arquivos texto terminados com ".desktop", contendo informações do programa a que se referem e a maneira como o KDE deverá executá-lo. Vide o exemplo de um deles:

cat /usr/share/autostart/klipper.desktop
[Desktop Entry]
Name=Klipper
GenericName=Clipboard Tool
Exec=klipper
Icon=klipper
Type=Application
X-DocPath=klipper/index.html
Terminal=false
X-KDE-autostart-after=panel
X-KDE-StartupNotify=false
X-DBUS-StartupType=Unique
X-KDE-UniqueApplet=true
X-KDE-autostart-condition=klipperrc:General:AutoStart:true
OnlyShowIn=KDE;
Categories=Qt;KDE;Utility;X-KDE-Utilities-Desktop;
Comment=A cut & paste history utility

X-Ubuntu-Gettext-Domain=desktop_kdebase-workspace

Claro que você não vai tentar escrever um arquivo destes diretamente, pois poderá omitir uma opção importante ou configurar algo erradamente. Procure deixar que estes arquivos se gerem de forma automática pelos próprios programas ou utilize o inicializador gráfico, conforme mostrado acima. O conhecimento destes detalhes é útil mormente no sentido de se verificar a que programa pertence cada arquivo .desktop e a ajudá-lo a apagar o inicializador de algum programa intrometido que o inseriu sem sua permissão.

Bom, espero que este pequeno tutorial tenha lhe ajudado a administrar melhor seu KDE e sua seção!! Boa sorte!!

sexta-feira, 24 de dezembro de 2010

Como Listar os Usuários e Grupos Existentes no Linux?

Os usuários existentes em uma instalação do sistema Linux podem ser listados facilmente se conseguimos listar o arquivo de dados onde eles são catalogados pelo sistema, ao lado de várias outras informações pessoais importantes, como a sua senha (criptografada, naturalmente), seu nome, grupo primário, etc. Este fantástico arquivo é o /etc/passwd. Ver o seu conteúdo pode ser feito pelo comando abaixo (não precisa ser root):

cat /etc/passwd

Em geral, isto lista uma série de informações. Os grupos, analogamente, encontram-se no arquivo /etc/group, associados a algumas informações pertinentes, e podem ser listados da seguinte maneira (não precisa ser root):

cat /etc/group

Dependendo de como o sistema esteja configurado, as senhas dos usuários podem ficar em local específico, no arquivo /etc/shadow, que só pode ser lido ou modificado pelo root:

cat /etc/shadow


  • Entendendo o /etc/passwd

Como este arquivo é usado durante o login, ele é acessível a todos os usuário (para leitura), mas só pode ser modificado pelo administrador do sistema. Cada linha representa um usuário e contém seus dados específicos. Cada campo é separado do outro pelo caracter ":" (dois pontos). Observe a seqüência de dados presentes em cada linha, conforme mostra o trecho do arquivo abaixo:

gdm:x:105:112:Gnome Display Manager:/var/lib/gdm:/bin/false
paje:x:1001:1001:O Paje,,,:/home/gabriel:/bin/bash
1 :2: 3 : 4 : 5 :6 :7

1- nome do usuário: contém o nome da conta do usuário, que pode ter entre 1 e 32 caracteres. Em nosso caso, um usuário se chama "gdm" e o outro "paje";

2- É o local da senha. Se, ao invés disso, houver o caracter "x", então o arquivo indica que as senhas estão encriptadas no arquivo /etc/shadow, que só pode ser lido pelo root.

3- UID (User ID). Número identificador do usuário. Nunca existirão dois usuários com o mesmo número. O UID segue as seguintes regras: 0=root; 1-99=contas pré-definidas (ex: bin, sys, mail, games, irc); 100-999=reservados pelo sistema para contas administrativas e de gerenciamento interno; a partir de 1000=usuários convencionais. No caso acima, "gdm" é um usuário administrativo, mas "paje" é um usuário normal.

4- GID (Group ID). Número identificado do grupo primário do usuário. Um usuário pode estar associado a vários grupos, mas tem apenas um grupo denominado "primário". Quando o usuário cria um arquivo novo, por exemplo, este arquivo fica registrado como pertencente a este usuário seu criador e ao grupo ao qual ele está associado como grupo primário no momento de criação do arquivo.

5- Uma série de informações separadas por vírgulas (que nem sempre são cadastradas!), como o nome real do usuário, telefone, número da sala, etc.

6- O caminho completo (absoluto) do diretório do usuário.

7- O shell que será executado cada vez que este usuário fizer login. Em geral é /bin/bash (para usuários comuns), mas pode ser outro shell ou mesmo /bin/false, caso o usuário não seja autorizado a fazer login.

Não foi tão difĩcil entender estes campos, foi??


  • Várias Maneiras de Listar Usuários

Verificando se um usuário existe mesmo, e sabendo suas informações:

grep gdm /etc/passwd
gdm:x:105:112:Gnome Display Manager:/var/lib/gdm:/bin/false

Verificando todos os usuários convencionais (que, supostamente, possuem um diretório no /home):

grep /home/ /etc/passwd

Mostrando uma listagem simples, contendo somente o nome dos usuários, sem as demais informações da linha:

grep /home/ /etc/passwd | cut -d: -f1

O comando "cut" usado no filtro "|" recorta o resultado do comando grep. Os parâmetros significam: "-d:"=delimitador (indica que será fornecida uma informação para delimitar o resultado), "-f1"=indica que deverá ser mostrado apenas o primeiro campo (field 1).

É claro que este comando todo pode ser armazenado em um shell script ou em uma aliases. Adicionalmente, gostaria de encorajá-lo a modificar o comando acima e personalizá-lo conforme deseje!! Sinta-se à vontade!!


  • Entendendo o /etc/group

Analogamente ao /etc/passwd, o /etc/group contém uma linha para cada grupo, onde as informações específicas do grupo são separadas pelo caracter ":" (dois pontos). Exemplo de trecho do arquivo:

video:x:44:paje,fulano,beltrano
1 :2: 3 :4

1- Nome do grupo;

2- Senha do grupo. Analogamente ao /etc/passwd, a senha é substituída pelo caracter "x" para ser armazenada em local seguro. Em muitos sistemas, a administração de grupos é feita exclusiva e diretamente pelo root, sem necessidades de senhas para os grupos.

3- GID (Group ID);

4- Lista de usuários que estão associados a este grupo, separados por vírgulas. Esta lista pode estar vazia, indicando que não há usuários associados ao grupo.


Bom, pessoal, espero que este artigo tenha ajudado... lembrem-se de que, aconteça o que acontecer, o mais importante é que COMENTEM!!

quinta-feira, 23 de dezembro de 2010

Versionando Seus Dados: Boas Práticas e Dicas

Existe inúmeros servidores de controle de versão, como o CVS e o Subversion (SVN). Este artigo visa sugerir boas práticas para que estes servidores sejam utilizados da melhor e mais confiável maneira. É um artigo abrangente, direcionado tanto para desenvolvedores de programas quanto para usuários domésticos que nada sabem de programação.


  • Por Que Versionar Meus Dados??

O versionamento foi criado inicialmente para que equipes de programadores pudessem compartilhar de maneira segura e flexível códigos elaborados na construção de componentes de um mesmo programa. Com o versionamento, tornou-se possível e seguro não só o compartilhamento, como também a recuperação de versões anteriores dos arquivos versionados, ou mesmo a comparação entre as versões de um mesmo arquivo (o chamado diff).
Hoje em dia, com a evolução das tecnologias, como o aumento dos discos rígidos e a facilidade de criação de repositórios na rede (online), tornou-se viável e realmente útil realizar versionamento de qualquer coisa, desde documentos do Open Office, como textos e planilhas eletrônicas, até figuras e códigos de programas. Assim, realmente vale a pena (e recomendo!!) que você versione sua planilha com os endereços e telefones de seus contatos, seus dados de controle de gastos domésticos, sua tese de doutorado, suas fotos da câmera, suas músicas, seus históricos de programas de mensagens instantâneas, os documentos do trabalho, seu livro que vai sair um dia, suas poesias, etc, etc...
O versionamento é capaz de te lhe trazer muitos benefícios, dos quais destaco os seguintes:

1- Cópia de segurança de seus dados (o chamado backup);
2- Organização de seus dados: criação apropriada da estrutura de pastas e melhor escolha dos nomes de arquivos;
3- Armazenamento das versões anteriores dos arquivos, permitindo a recuperação das mesmas ou de parte destas;
4- Comparação entre duas ou mais versões diferentes dos arquivos a partir de programas de diff, presentes hoje na maioria dos grandes aplicativos, como a suíte do Open Office;
5- Edição e manutenção coletiva dos arquivos: várias pessoas mexendo neles ao mesmo tempo não será mais sinônimo de bagunça e perda de dados!!
6- Ferramentas para mesclar dados;
7- Fácil sincronização entre os dados que você produziu e mantém em seus diversos computadores: laptop, máquina do trabalho, máquina de casa, celular, etc..., evitando perdas de arquivos ou perigosas regressões de seus trabalhos devido à acidental sobrescrita de uma versão mais nova por uma mais antiga (que lance a primeira pedra quem nunca cometeu esse equívoco...).


  • Como Versionar Tudo Isso??

Existem milhares de controladores de versão. Eu recomendo o Subversion (abreviadamente denominado de SVN), que é bem mais seguro e inteligente que o CVS, além de existir para a grande maioria as plataformas, ser gratuito e livre, extremamente leve, vastamente testado e retestado e ter plugins e clientes das mais diferentes formas e condições.
Existem tutoriais que ensinam como fazer a sua pasta home do Linux ficar automaticamente versionada pelo SVN, de forma que qualquer coisa que você simplesmente salve ali irá automaticamente ser enviada para o servidor. Apesar de ser imensamente prático, eu não recomendo que você faça isto... mas, por quê?? Porque este procedimento gera muitos commits (efetivações) desnecessários no banco de dados do seu repositório versionado, além de tender a que todos eles sejam feitos sem qualquer mensagem descritiva, o que torna difícil a identificação da versão que você quer recuperar, caso seja necessária.
Este tutorial não ensina a instalar o servidor de controle de versão nem a criar repositórios (se é isso que você quer, navegue aqui mesmo, nesse meu ao lado direito, e veja os outros artigos do Pajé que ensinam detalhadamente muitos dos rudimentos destas técnicas, voltados para o SVN), mas sim ensina boas práticas e como explorar melhor o "poder" do versionamento.


  • Dicas Para um Bom Versionamento

Seguem abaixo várias dicas que podem ser utilizadas tanto por desenvolvedores de softwares quanto por usuários domésticos, em busca de proteção e compartilhamento de seus dados.

1- Sempre faça commits (efetivações) com mensagens. Embora muitos controladores de versões permitam subir dados sem dizer qualquer coisa a respeito, não se furte ao comentário. Somente assim será possível identificar o conteúdo novo de cada revisão criada. Nem preciso dizer que isto é essencial nas buscas e pesquisas, como comparações, das versões antigas.
1.1- Se seu repositório é compartilhado por pessoas de vários países, somente escreva as mensagens em inglês.

2- Não saia fazendo muitos commits alopradamente!!!! Suba apenas aquilo que está funcionando (ou seja, um código completo, sem erros, ou um documento com uma seção inteira adicionada ou revisada). Faça valer o gesto da criação de uma nova revisão do arquivo!!

3- Se algo ficou pendente no arquivo e você considera que possa ser feito mais tarde, não interferindo diretamente na seção onde você está trabalhando, inclua comentários sobre o mesmo. Em código de programa, normalmente se inclui blocos "TODO", para clamar por código extra (que normalmente serão providenciados em outras seções do programa) ou "FIXME" (normalmente indicando trechos hard coded). Em documentos do Open Office, coloque comentários mesmo (menu Inserir, opção Anotação), aquelas caixas de texto amarelas que guardam uma informação extra sobre um trecho do documento, sem interferir no conteúdo (não inclua os comentários como se fossem parte do documento, por favor!!! Eles usualmente lhe escapam e vão acabar sobrando no texto final, o que fica muito feio para o autor!!).

4- Nunca, mas nunca nunquinha da Silva, comece diretamente a trabalhar em seus arquivos locais!!! Antes de fazer qualquer coisa, sincronize sua base de dados local com o repositório, buscando comparar o que você tem com as versões mais novas dos arquivos e atualizando tudo o que você tem.

5- Evite armazenar o seu repositório no mesmo local onde você sempre trabalha!!!! Se ele está na mesma partição de seu disco rígido (ou até se o repositório fica no mesmo disco rígido onde você trabalha), num momento em que o disco entre em pane ou queime, você perderá tudo do mesmo jeito, seus dados locais e o precioso repositório. Vide soluções para este caso, em ordem de segurança, do menos seguro para o mais seguro:
5.1- Você pode armazenar seu repositório em um outro disco rígido de sua máquina, voltado só para isso (ainda assim, pouco seguro);
5.2- Você pode armazenar seu repositório em um dispositivo externo, como um disco externo ou pendrive (segurança média);
5.3- Você pode armazenar seu repositório em uma área de rede, que fica em um servidor de arquivos, ou seja, uma máquina na sua empresa ou na sua casa com um bom espaço ligada 24 horas por dia e com acesso compartilhado (segurança média);
5.4- Você pode armazenar seu repositório em uma área acessível via SSH (ou outro protocolo qualquer) de um storage, com vários discos rígidos compartilhados com alguma técnica de redundância e/ou espelhamento (altamente seguro, porém é mais uma solução corporativa do que doméstica!!);
5.5- Você pode armazenar seu repositório em uma área virtual fornecida por algum compartilhador, como o Dropbox, que mantém severas rotinas de backup e sela o compromisso de altíssima disponibilidade (altamente seguro, porém é mais uma solução doméstica do que corporativa!!);

6- Evidentemente, faça backups freqüentes de seu repositório!!! Nada adiantará ter toda essa tecnologia e um dia acontecer uma fatalidade... faça backups em meios seguros, como CD, DVD, outros Discos Rígidos, etc, conforme o volume e fluxo de seus dados. Agende seu backup em períodos razoáveis, de acordo com a sua produção.
6.1- PELAMORDEDEUS: teste seus backups com freqüência!!! Mais uma vez insisto: de nada adiantará ter toda essa tecnologia, inclusive o backup, se uma fatalidade ocorrer, você perder tudo, ter de voltar ao backup, e justamente aí descobrir que, por algum motivo, você não consegue recuperar o backup, pois: ou ele foi feito de maneira incorreta, ou ele estava acontecendo de maneira parcial e você nunca notou, ou qualquer outra péssima eventualidade.... teste, e teste periodicamente!!

7- Sempre que terminar ou concluir uma parte completa de seu trabalho, envie para o servidor. Programe sua rotina de trabalho para que, no final do expediente (ou de uma seção de trabalho), você tenha concluído o que você iniciou e esteja apto a subir para o servidor. Como não recomendo que suba nada com erros, com código incompleto, com seções de documento incompletas ou inconclusas e sem anotações, então programe direitinho sua seção de trabalho. Claro que imprevistos acontecem, mas tente minimizar isto e deixar o mínimo possível de novidades locais, para garantir a segurança de seus dados e evitar conflitos nas próximas sincronizações, caso ou outros membros da sua equipe trabalhem nos mesmos arquivos que você durante o intervalo entre uma seção e outra de seu trabalho.

8- Por questões de zelo e cuidado, sempre suba documentos e códigos bem formatados e ajustados. Melhora a compreensão, especialmente se você não trabalha sozinho...


Bom, pessoal... em linhas gerais, é isto que quero dizer. Espero ter ajudado!! Qualquer coisa: COMENTEM!!!

terça-feira, 21 de dezembro de 2010

Como Acessar o SVN via HTTP

Este artigo apresenta, de forma resumida, como configurar seu repositório do Subversion para ser acessado usando o protocolo HTTP. Esta configuração é apenas um dos três modos de operação do SVN (mais sobre os outros modos e uma ampla discussão sobre as características, vantagens e desvantagens de cada um encontra-se em nosso outro artigo, aqui. Se o seu caso for aprender a instalar o SVN tunelado por SSH, então veja também este outro artigo aqui). Supõe-se, neste artigo, que o SVN já esteja propriamente instalado e configurado na máquina servidora. Supõe-se que você já tenha um cliente instalado em máquina local, para fins de testes. Caso não saiba instalar um, sugiro consultar nosso outro artigo, aqui.


  • Instalação do Apache

Fazer o SVN ser acessado por HTTP necessita de um servidor Web, já que este protocolo não é o padrão para o SVN. A sua função é colocar-se como intermediário entre o usuário e o repositório versionado, executando, em linhas gerais, as seguintes tarefas:

- Receber as requisições HTTP do cliente;
- Validar o usuário do cliente com base de dados de usuário própria;
- Traduzí-las para o SVN, usando usuário próprio do sistema operacional;
- Coletar as respostas do SVN;
- Traduzí-las de volta para o protocolo HTTP;
- Enviá-las para o cliente.

O servidor web utilizado para tunelar o SVN através do protocolo HTTP é o Apache Web Server 2; o diálogo entre o Apache 2 e o SVN é possível graças a um módulo especial do Apache, o WebDAV. O comando a seguir instala o servidor HTTP e o módulo do webDAV:

apt-get install apache2 libapache2-svn

Após este comando, o Apache 2 será instalado e inicializado, bem como todos os módulos padrão. Após a instalação do módulo do webDAV, ele será automaticamente inicializado. Caso queira se certificar a respeito desta instalação, verifique se surgem as seguintes linhas:

Módulos padrão:
Enabling site default.
Enabling module alias.
Enabling module autoindex.
Enabling module dir.
Enabling module env.
Enabling module mime.
Enabling module negotiation.
Enabling module setenvif.
Enabling module status.
Enabling module auth_basic.
Enabling module deflate.
Enabling module authz_default.
Enabling module authz_user.
Enabling module authz_groupfile.
Enabling module authn_file.
Enabling module authz_host.
Enabling module reqtimeout.

Módulos do webDAV:
Enabling module dav.
Enabling module dav_svn.

Para confirmar quais os módulos estão ativos, basta ler o diretório onde os links simbólicos para os módulos ativos ficam:

# links para os módulos ativos
ls /etc/apache2/mods-enabled/

# todos os módulos instalados
ls /etc/apache2/mods-available/

# onde os arquivos executáveis realmente ficam...
ls /usr/lib/apache2/modules/


  • Configuração do Apache 2

Criação do Arquivo de Senhas

Para que o seu repositório seja acessado com validação de usuário, é preciso que os usuários sejam previamente criados com suas senhas. Caso o seu repositório seja sempre público, este passo se tornará desnecessário.
Os usuários aqui referidos são usuários HTTP, e não usuários do sistema da sua máquina. Estes usuários ficam em um arquivo específico, onde se encontram com suas senhas. Felizmente, o Apache nos fornece uma ferramenta para a criação (e inserção) destes usuários, o htpasswd.
A criação de um arquivo novo, contendo seu primeiro usuário e senha, pode ser feita com o seguinte comando:

htpasswd -c /opt/svnrepos/repo1passwd admin
ou
htpasswd -c /opt/svnrepos/repo1passwd admin [senha]

Onde "admin" pode ser qualquer nome de usuário, e [senha] pode ser qualquer senha. Caso a primeira opção seja digitada, o comando perguntará a senha e pedirá que a repita antes de concluir a execução. Note que a segunda opção armazena a senha no histórico de comandos do shell, então tome cuidado ao usá-la!!
A opção “-c” cria o arquivo de senhas. Sem esta opção, o usuário informado é adicionado ao arquivo referenciado, que já deve existir.
A opção “-d” remove um usuário.

Após o comando, o arquivo passa a existir, com uma linha, onde o nome e a senha do usuário “admin” são separados com o caracter “:”, exatamente como o Linux faz em /etc/passwd. Observe:

cat /opt/svnrepos/repo1passwd
admin:k3ir2JUfTSAr6

Note que a senha está segura e criptografada. Existem opções no htpasswd para que ela não seja criptografada ou para selecionar qual algoritmo dentre os disponíveis deve ser usado em sua criptografia. Mais detalhes sobre o htpasswd pode ser acessado em sua página man ou com o parâmetro “-h”.


  • Configuração do Repositório no Apache

Neste momento, supõe-se que você já tenha um repositório criado no seu sistema de arquivos (tarefa normalmente feita com a ferramenta svnadmin).
Para informar o seu repositório para o Apache, é preciso editar o seguinte arquivo:

vi /etc/apache2/apache2.conf

Neste arquivo, deve-se incluir (em especial, para o bem do administrador de sistemas, no final do arquivo, com um comentário indicando a que veio o bloco de linhas!!), para cada repositório, um conjunto de linhas como este aí embaixo, capaz de informar a localização do repositório e a configuração de acesso ao mesmo:

[Location /repo1]
DAV svn
SVNPath /opt/svnrepos/repo1
AuthType Basic
AuthName "repo1"
AuthUserFile /opt/svnrepos/repo1passwd
Require valid-user
[/Location]

OBS: Substitua os colchetes por sinais de maior e menor, formando a tag corretamente!!

Bom, o que significa isto?? Bem fácil, acompanhe-me:

- Location: É a localização virtual do repositório (no formato de tag, que, para o Apache, recebe o nome de "Contêiner"). No caso acima, ele será acessível pelo endereço "http://[servidor]/repo1";
- DAV svn: Usar o módulo dav, direcionado para o SVN;
- SVNPath: Caminho real do repositório no sistema de arquivos;
- AuthType Basic: Tipo de autenticação. Sendo Basic, o acesso é permitido apenas a usuário devidamente autenticados. Note que esta autenticação não garante encriptação na hora de fornecer os dados sensíveis de usuário e senha pela rede. Dentro de uma rede local, isto pode não ter o menor problema. Porém, não faça assim se o seu repositório é visível pela internet!! Se este for o caso, então cogite usar uma chave de encriptação e proteger a conexão inteira por SSL, utilizando, na verdade, o protocolo HTTPS. Verifique os links de nossos artigos sobre o assunto deixados na conclusão deste artigo...
- AuthName: Nome de identificação do repositório, que aparecerá na janela de login do usuário e no nome do repositório, após o projeto ser baixado via checkout;
- AuthUserFile: Define qual o arquivo de senhas de usuários HTTP, criado pela ferramenta htpasswd, do Apache, conforme mostrado mais acima.
- Require valid-user: Exige login e senha de um usuário válido, independente da ação requerida.

Concluída a configuração, podemos finalmente reiniciar o Apache:

/etc/init.d/apache2 restart

Note que o Apache faz todo o acesso a disco a partir de seu usuário próprio (em geral, o www-data). Assim, é preciso que o seu repositório do SVN, assim como o diretório “db” e todo o conteúdo deste estejam acessíveis a este usuário. Normalmente, basta digitar os seguintes comandos:

Trocando o usuário nos arquivos e diretórios necessários:
chown www-data /opt/svnrepos/repo1
chown -R www-data /opt/svnrepos/repo1/db

Trocando o grupo nos arquivos e diretórios necessários:
chgrp www-data /opt/svnrepos/repo1
chgrp -R www-data /opt/svnrepos/repo1/db


  • WebDAV: Configurando Diferentes Permissões de Acesso (ou: Como acessar anonimamente o repositório?)

O exemplo acima é apenas um exemplo simples. Em alguns casos, porém, é interessante que seu repositório trabalhe com diferentes políticas de permissão de acesso, dependendo da ação (requisição) sendo solicitada. Exemplo: se o seu projeto é de código livre, talvez interesse manter o repositório aberto para leitura (update ou checkout) por toda a comunidade, sem exigir login de usuário e senha, mas, por segurança, manter a exigência de autenticação (usuário e senha) se a ação implicar alguma modificação no repositório (alterar aquivos, modificar propriedades, apagar ou adicionar arquivos, etc.). Assim, você tem seu repositório protegido, ou seja, somente a equipe autorizada é capaz de mexer nele, porém qualquer pessoa, de qualquer lugar do mundo, poderá baixar, a qualquer momento, o último estado (snapshot) do seu sistema.
Para realizar esta proeza, é bem simples. Primeiramente, devemos retirar a linha "Require valid-user", que exige autenticação irrestritamente, sem considerar o tipo de ação. Depois disso, devemos acrescentar as tags "Limit" ou "LimitExcept". A tag "Limit" contendo uma linha "Require valid-user" informa as ações que devem exigir autenticação. A tag "LimitExcept" contendo a mesma linha informa as ações que devem ser excetuadas desta regra, ou seja, que não exigirão autenticação. As duas tags podem ser adicionadas, mas isto será redundante. Em geral, prefira uma das duas. É comum se trabalhar apenas com a LimitExcept, para a configuração ficar menos verbosa.
Em resumo, para a situação proposta, a configuração ficaria:

[Location /repo1]
DAV svn
SVNPath /opt/svnrepos/repo1
AuthType Basic
AuthName "repo1"
AuthUserFile /opt/svnrepos/repo1passwd
# Require valid-user # Retirada esta linha!!
[Limit PUT POST DELETE PROPFIND PROPPATCH MKCOL COPY MOVE LOCK UNLOCK]
Require valid-user
[/Limit]
# Ou então, em lugar do Limit:
[LimitExcept GET PROPFIND, OPTIONS, REPORT]
Require valid-user
[/LimitExcept]

[/Location]

OBS1: Substitua os colchetes por sinais de maior e menor, formando a tag corretamente!!
OBS2: As ações incluídas dentro das tags Limit e LimitExcept são, muitas vezes, métodos HTTP. A listagem completa deles pode ser obtida aqui.
OBS3: Se você incluir no LimitExcept apenas o método GET, seu repositório será acessível anonimamente via HTTP, ou seja, do navegador, mas não poderá ser baixado de um cliente SVN sem nome de usuário e respectiva senha.



  • Conclusões

O acesso via webDAV é muito mais interessante para grandes equipes, pois protege mais o servidor, criando, através do Apache 2, uma camada de abstração entre o usuário e o repositório. Também esconde onde é o local exato em que o repositório está e quem realmente pode acessar a máquina servidora.
Existem, no entanto, muitas outras maneiras de configurar o webDAV, como:

- Forçá-lo a ser acessado apenas por HTTPS (imprescindível se seu repositório está aberto à internet). Se é isto que procura, visite nossos artigos Criando Certificações SSL com OpenSSL e Configurando o Apache com SSL;
- Abandonar o arquivo de senhas do Apache e configurá-lo para usar autenticação a partir de dados de uma tabela do MySQL;
- Dentre muitas outras coisas...

Todos estes tópicos fogem ao escopo deste pequeno artigo, mas espero ter fôlego para abordá-los tão logo, aguardem!!
Claro, como sempre, não devemos nunca nos esquecer do quanto é importante que COMENTEM!! ;-)

quinta-feira, 16 de dezembro de 2010

Verificando as Dependências (Bibliotecas) de um Programa

Quando instalamos um programa no Linux através de repositórios (usando o apt-get, yum, ou outro gerenciador qualquer), não nos damos conta da gama de operações que estes gerenciadores fazem para garantir a integridade do programa, ou seja, garantir que seja instalado o programa correto, com a compilação para a sua arquitetura, que seja a versão mais nova apontada e que faça instalar, concomitantemente, todas as dependências deste programa. É simplesmente uma maravilha não nos preocuparmos com isto!
Contudo, algumas vezes somos forçados a baixar aplicativos que não estão no repositório... daí toda esta magestosa praticidade cai por terra... como verificar se o programa que você acabou de baixar vai rodar?? Como saber se você realmente tem instaladas, em sua máquina, todas as bibliotecas, nas versões corretas, de que ele precisa?? Como achar e instalar as bibliotecas que estão faltando?? Se você se encontra perdido entre estas cruéis indagações, então neste artigo lhe apresentaremos duas soluções interessantes que vão dar uma luz a sua vida!!


  • Usando o comando ldd

É possível que em sua máquina já exista instalado este comando. Ele é muito simples: basta que se digite "ldd [arquivo]", e você terá a lista de todas as dependências do arquivo informado. Lembre-se de que o arquivo deve ser um binário executável, e não um script de texto, como muitos programas em Shell Script ou Python (caso seu programa seja em Python, a própria máquina virtual vai informar o trace do programa, mostrando as bibliotecas de import que não foram encontradas). Exemplo do ldd:

ldd /opt/eclipse/eclipse
linux-gate.so.1 => (0x00310000)
libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0x0061e000)
libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0x0020c000)
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0x00311000)
/lib/ld-linux.so.2 (0x00a99000)

Veja que são informadas as bibliotecas e o caminho onde elas devem estar!! Se você quiser obter ainda mais detalhes, utilize o parâmetro "-v". Desta forma, você poderá descobrir não só as dependências do arquivo, como também as dependências das dependências, tornando bem fácil a instalação e resolução de grande parte dos problemas. Exemplo:

ldd -v /opt/eclipse/eclipse
linux-gate.so.1 => (0x0069d000)
libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0x009e7000)
libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0x00f0c000)
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0x00a50000)
/lib/ld-linux.so.2 (0x00f31000)

Version information:
/opt/eclipse/eclipse:
libpthread.so.0 (GLIBC_2.0) => /lib/tls/i686/cmov/libpthread.so.0
libdl.so.2 (GLIBC_2.1) => /lib/tls/i686/cmov/libdl.so.2
libdl.so.2 (GLIBC_2.0) => /lib/tls/i686/cmov/libdl.so.2
libc.so.6 (GLIBC_2.3) => /lib/tls/i686/cmov/libc.so.6
libc.so.6 (GLIBC_2.1) => /lib/tls/i686/cmov/libc.so.6
libc.so.6 (GLIBC_2.0) => /lib/tls/i686/cmov/libc.so.6
/lib/tls/i686/cmov/libpthread.so.0:
ld-linux.so.2 (GLIBC_2.3) => /lib/ld-linux.so.2
ld-linux.so.2 (GLIBC_2.1) => /lib/ld-linux.so.2
ld-linux.so.2 (GLIBC_PRIVATE) => /lib/ld-linux.so.2
libc.so.6 (GLIBC_2.1.3) => /lib/tls/i686/cmov/libc.so.6
libc.so.6 (GLIBC_2.1) => /lib/tls/i686/cmov/libc.so.6
libc.so.6 (GLIBC_2.3.2) => /lib/tls/i686/cmov/libc.so.6
libc.so.6 (GLIBC_2.2) => /lib/tls/i686/cmov/libc.so.6
libc.so.6 (GLIBC_PRIVATE) => /lib/tls/i686/cmov/libc.so.6
libc.so.6 (GLIBC_2.0) => /lib/tls/i686/cmov/libc.so.6
/lib/tls/i686/cmov/libdl.so.2:
ld-linux.so.2 (GLIBC_PRIVATE) => /lib/ld-linux.so.2
libc.so.6 (GLIBC_2.1.3) => /lib/tls/i686/cmov/libc.so.6
libc.so.6 (GLIBC_2.1) => /lib/tls/i686/cmov/libc.so.6
libc.so.6 (GLIBC_2.0) => /lib/tls/i686/cmov/libc.so.6
libc.so.6 (GLIBC_PRIVATE) => /lib/tls/i686/cmov/libc.so.6
/lib/tls/i686/cmov/libc.so.6:
ld-linux.so.2 (GLIBC_PRIVATE) => /lib/ld-linux.so.2
ld-linux.so.2 (GLIBC_2.3) => /lib/ld-linux.so.2
ld-linux.so.2 (GLIBC_2.1) => /lib/ld-linux.so.2

Mais opções e alguma ajuda podem ser obtidas com o help:

man ldd
ou: ldd --help


  • Usando o comando getlibs

O comando getlibs dá um passo a frente do ldd! Com ele, não só você conseguirá verificar se existem bibliotecas faltando para seu programa rodar, como também poderá baixar e instalar automaticamente as bibliotecas omissas. De fato, um programinha de ouro para qualquer usuário, desde um administrador de sistemas até o usuário doméstico!!
Provavelmente o getlibs não estará instalado em seu sistema, e talvez não exista no repositório. No entanto, ele poderá ser baixado gratuitamente do site:

http://frozenfox.freehostia.com/cappy/

Se seu sistema é baseado em Debian, baixe o arquivo .deb e instale com o seguinte comando (como superusuário!!):

dpkg -i getlibs-all.deb

Agora é só verificar as dependências:

getlibs /opt/eclipse/eclipse
This application isn't missing any dependencies

A mensagem acima indica que não há dependências faltando. Caso haja, o getlibs vai indicar quais sejam elas e tentar baixá-las e instalá-las para você.
Mais detalhes sobre as opções e parâmetros do getlibs podem ser encontradas neste link.
Aí está: outro programa extremamente útil, que pode lhe salvar dos últimos desesperos da alta madrugada, quando nada mais parecer ter vida...

Bom, claro, muito mais importante do que tudo isso: COMENTEM!!!!