[ anterior ] [ Conteúdo ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ] [ próximo ]

A FAQ (perguntas freqüentes) do Debian GNU/Linux.
Capítulo 10 - Personalizando sua instalação do Debian GNU/Linux.

10.1 Como posso garantir que todos os programas usem o mesmo tamanho de papel?

O arquivo /etc/papersize contém o nome do tamanho padrão do papel (como carta ou A4). Ele pode ser sobrescrito usando a variável de ambiente PAPERSIZE. Para detalhes, veja a página de manual papersize(5).

10.2 Como posso fornecer acesso aos periféricos sem comprometer a segurança?

Vários arquivos de dispositivo no diretório /dev pertencem a grupos pré-definidos. Por exemplo, /dev/fd0 pertence ao grupo floppy, e o /dev/dsp pertence ao grupo audio.

Se você deseja que um certo usuário tenha acesso a um desses dispositivos, somente adicione o usuário ao grupo ao qual o dispositivo pertence, por exemplo, faça:

     adduser user group

Desse modo, você não terá que usar chmod no arquivo de dispositivo.

10.3 Como carrego uma fonte de console na inicialização à moda Debian?

O pacote kbd e console-tools suportam isso, edite o arquivo /etc/kbd/config ou o arquivo /etc/console-tools/config.

10.4 Como configuro os defaults de um programa para X11?

Os programas X do Debian irão instalar seus dados de recursos para os aplicativos em /etc/X11/app-defaults/. Se quiser personalizar aplicativos do X globalmente, coloque suas personalizações nesses arquivos. Eles são marcados como arquivos de configuração, portanto, seus conteúdos serão preservados durante atualizações.

10.5 Parece que cada distribuição possui um método de inicialização diferente. Fale-me sobre o do Debian.

Como todos os Unices, o Debian é inicializado executando-se o programa init. O arquivo de configuração para o init (que é o /etc/inittab) especifica que o primeiro script a ser executado deve ser o /etc/init.d/rcS. Este script verifica e monta sistemas de arquivos, carrega módulos, inicia os serviços de rede (chamando o script /etc/init.d/network), ajusta o relógio, faz outras inicializações, e daí, executa todos os scripts (exceto os que tiverem '.' no nome-de-arquivo) em /etc/rc.boot/. Qualquer script no diretório anterior é normalmente reservado para uso do administrador do sistema, e o uso deles em pacotes é desaprovado.

Após completar o processo de inicialização, o init executa todos os scripts "start" do diretório especificado pelo runlevel padrão (este runlevel é dado pela entrada id no /etc/inittab). Como a maioria dos Unices compatíveis com o System V, o Linux possui 7 runlevels:

0 (pára o sistema),

1 (modo monousuário),

2 até 5 (vários modos multiusuários), e

6 (reinicializa o sistema).

Sistemas Debian vêm com id=2, que indica que o runlevel padrão será o '2' quando o sistema entrar no modo multiusuário, e os scripts de /etc/rc2.d/ serão executados.

Na verdade, os scripts em quaisquer dos diretórios /etc/rcN.d/ são apenas ligações simbólicas para scripts em /etc/init.d/. Porém, os nomes dos arquivos em cada um dos diretórios /etc/rcN.d/ são escolhidos de modo a indicar a maneira em que os scripts de /etc/init.d/ serão executados. Especificamente, antes de entrar em qualquer runlevel, todos os scripts que começam com a letra 'K' são executados; esses scripts "matam" (terminam) os serviços. Depois, todos os scripts que começam com a letra 'S' são executados; esses scripts iniciam serviços. O número de dois dígitos após o 'K' ou 'S' indica a ordem na qual o script é executado. Os scripts com números menores são executados primeiro.

Esta abordagem funciona porque todos os scripts em /etc/init.d/ aceitam um argumento que pode ser tanto 'start' (iniciar), 'stop' (parar), ou 'reload' (recarregar), 'restart' (reiniciar) ou 'force-reload' (força/obriga a recarga) e fazem a tarefa indicada pelo argumento. Esses scripts podem ser usados mesmo depois que o sistema tiver sido inicializado, para controlar os vários processos.

Por exemplo, com o argumento `reload' o comando

     /etc/init.d/sendmail reload

envia ao daemon do sendmail um sinal para reler seu arquivo de configuração.

10.6 Parece que o Debian não usa o arquivo `rc.local` para personalizar o processo de inicialização; que recursos são fornecidos?

Suponha que um sistema precisa executar o script foo na inicialização, ou uma entrada para um runlevel (System V) específico. Então, o administrador do sistema deve:

Colocar o script foo no diretório /etc/init.d/.

Executar o comando update-rc.d do Debian com os argumentos apropriados, para estabelecer as ligações entre os diretórios rc?.d e /etc/init.d/foo (especificados na linha de comando). Aqui, '?' é um número de 0 a 6 e corresponde a cada um dos runlevels do System V.

Reinicializar o sistema.

O comando update-rc.d estabelecerá as ligações entre os arquivos dos diretórios rc?.d e o script em /etc/init.d/. Cada ligação começará com um 'S' ou um 'K', seguido de um número, seguido do nome do script. Os scripts de /etc/rcN.d/ que começam com a letra 'S' são executados quando se entra no runlevel N. Os scripts que começam com a letra 'K' são executados quando se deixa o runlevel N.

Pode-se, por exemplo, fazer com que o script foo seja executado na inicialização, colocando-o em /etc/init.d/ e instalando as ligações com update-rc.d foo defaults 19. O argumento 'defaults' refere-se aos runlevels padrões, que vão de 2 a 5. O argumento '19' assegura que foo será chamado antes de quaisquer scripts que tenham números iguais ou maiores a 20.

10.7 Como o sistema de gerenciamento de pacotes lida com pacotes que contêm arquivos de configuração para outros pacotes?

Alguns usuários gostariam de criar, por exemplo, um novo servidor instalando um grupo de pacotes Debian e um pacote gerado localmente que consiste em arquivos de configuração. Isso geralmente não é uma boa idéia, porque o dpkg não saberá que esses arquivos de configuração existem se eles estiverem num pacote diferente, e pode escrever configurações conflitantes quando um pacote do "grupo" inicial for atualizado.

Ao invés disso, crie um pacote local que modifica os arquivos de configuração do "grupo" de pacotes Debian em questão. Daí, o dpkg e o resto do sistema de gerenciamento de pacotes verá que os arquivos foram modificados pelo "administrador" local e não tentará sobrescrevê-los quando esses pacotes forem atualizados.

10.8 Como posso anulo um arquivo instalado por um pacote, de modo que uma versão diferente possa ser usada?

Suponha que um administrador ou um usuário local queira usar um programa "login-local" ao invés do programa "login" fornecido pelo pacote Debian login.

Não faça:

Sobrescreva /bin/login com login-local.

O sistema de gerenciamento de pacotes não saberá sobre esta mudança, e simplesmente sobrescreverá seu /bin/login personalizado quando login (ou qualquer pacote que forneça o /bin/login) seja instalado ou atualizado.

Ao invés disso, faça

Execute:
```
     dpkg-divert --divert /bin/login.debian /bin/login
```
para que todas as futuras instalações de pacotes login do Debian escrevam o arquivo /bin/login com o nome /bin/login.debian.

Então execute:
```
     cp login-local /bin/login
```
para mover seu programa construído localmente ao local correto.

Detalhes são dados na página de manual dpkg-divert(8).

10.9 Como posso incluir meu pacote feito localmente, na lista de pacotes disponíveis que o sistema de gerenciamento de pacotes usa?

Execute o comando:

     dpkg-scanpackages BIN_DIR OVERRIDE_FILE [PATHPREFIX] > my_Packages

onde:

BIN-DIR é um diretório onde arquivos de pacotes Debian (que normalmente têm extensão ".deb") são armazenados.

OVERRIDE_FILE é um arquivo que é editado pelos mantenedores da distribuição e é normalmente armazenado num repositório de FTP da Debian, em indices/override.main.gz para os pacotes Debian na distribuição "main". Você pode ignorar isso para arquivos locais.

PATHPREFIX é um texto opcional que pode ser prefixado ao arquivo Packages.new sendo produzido.

Uma vez que você tenha construído o arquivo my_Packages, conte ao sistema de gerenciamento de pacotes sobre ele, usando o comando:

     dpkg --merge-avail my_Packages

Se você está usando o APT, você pode adicionar o repositório local ao seu arquivo sources.list(5) também.

10.10 Alguns usuários gostam do mawk, outros do gawk; alguns gostam do vim, outros do elvis; alguns gostam do trn, outros do tin; como o Debian lida com diversidade?

Existem vários casos onde dois pacotes fornecem duas versões diferentes de um programa, ambos fornecendo a mesma funcionalidade. Usuários podem preferir uma ao invés de outra fora de hábito, ou por causa da interface de usuário de um pacote ser um tanto mais agradável do que a interface de outro. Outros usuários do mesmo sistema podem realizar diferentes escolhas.

O Debian usa um sistema de pacotes "virtual" que permite aos administradores do sistema escolher (ou deixar que os usuários escolham) suas ferramentas favoritas quando houver duas ou mais que forneçam a mesma funcionalidade básica, e ainda satisfazer requerimentos de dependência de pacotes sem especificar um pacote específico.

Por exemplo, podem existir duas versões diferentes de leitores de news num sistema. O pacote do servidor de news pode "recomendar" que haja algum leitor de news no sistema, mas a escolha entre tin ou trn fica a cargo do usuário individual. Isto é satisfeito fazendo com que ambos os pacotes tin e trn forneçam o pacote virtual news-reader. O programa a ser chamado é determinado através de uma ligação que aponta de um arquivo com o nome do pacote virtual /etc/alternatives/news-reader para o arquivo escolhido, por exemplo, /usr/bin/trn.

Uma única ligação é insuficiente para dar suporte ao uso total de um programa alternativo; normalmente, páginas de manual, e possivelmente outros arquivos de suporte devem ser selecionados também. O script em Perl update-alternatives fornece uma maneira de assegurar que todos os arquivos associados a um pacote especificado sejam escolhidos como o padrão do sistema.

Por exemplo, para verificar quais executáveis fornecem o `x-window-manager', rode:

     update-alternatives --display x-window-manager

Se você deseja mudá-lo, rode:

     update-alternatives --config x-window-manager

E siga as instruções na tela (basicamente, pressione o número próximo a entrada que deseja).

Se um pacote não se registrou como um gerenciador de janelas por alguma razão (registre um bug se isso for um erro), ou se você usa um gerenciador de janelas do diretório /usr/local, as seleções na tela não conterão suas entradas preferidas. Você pode atualizar a ligação através das opções de linha de comando, assim:

     update-alternatives --install /usr/bin/x-window-manager \
       x-window-manager /usr/local/bin/wmaker-cvs 50

O primeiro argumento para a opção '--install' é a ligação simbólica que aponta para /etc/alternatives/NAME, onde NAME é o segundo argumento. O terceiro argumento é o programa para o qual /etc/alternatives/NAME deveria apontar, e o quato argumento é a prioridade (grandes valores significam que a alternativa será mais provavelmente escolhida automaticamente).

Para remover uma alternativa que você adicionou, simplesmente rode:

     update-alternatives --remove x-window-manager /usr/local/bin/wmaker-cvs