Capítulo 11. Personalizar o seu sistema Debian GNU/Linux

# Capítulo 11. Personalizar o seu sistema Debian GNU/Linux

## 11.1. Como posso certificar-me que todos os programas usam o mesmo tamanho de papel?

Instale o pacote `libpaper1`, e ele vai-lhe perguntar por um tamanho de papel predefinido para todo os sistema. A definição será guardada no ficheiro `/etc/papersize`.

Utilizadores podem sobrepor a definição de tamanho de papel usando a variável de ambiente `PAPERSIZE`. Para detalhes, veja o manual papersize(5).

## 11.2. Como posso Eu fornecer acesso a periféricos de hardware, sem comprometer a segurança?

Muitos ficheiros de dispositivo no directório `/dev` pertencem a alguns grupos predefinidos. Por exemplo, `/dev/sr0` pertence ao grupo `cdrom`.

Se desejar que um certo utilizador tenha acesso a um destes dispositivos, basta adicionar o utilizador ao grupo a que o dispositivo pertence, isto é, faça:

    adduser utilizador grupo

Deste modo você não tem de alterar as permissões de ficheiros no dispositivo.

Se você fizer isto de dentro de uma shell de utilizador ou num ambiente GUI, você tem de sair e iniciar sessão de novo para se tornar num membro efectivo desse grupo. Para verificar a que grupos pertence corra `groups`.

Note que, desde a introdução do `udev` se você mudar as permissões de um hardware periférico, elas podem ser ajustadas para alguns dispositivos quando o sistema arranca; se isto acontecer com o hardware periférico que lhe interessa, você terá que ajustar as regras em `/etc/udev`.

## 11.3. Como é que Eu carrego no arranque um tipo de letra na consola à maneira Debian?

O pacote `kbd` suporta isto, edite o ficheiro `/etc/kbd/config`.

## 11.4. Como posso Eu configurar as predefinições de aplicações de programas do X11?

Os programas X de Debian irão instalar os seus dados de recurso de aplicação no directório `/etc/X11/app-defaults/`. Se deseja personalizar as aplicações X, ponha a sua personalização nesses ficheiros. Eles são marcados como ficheiros de configuração, assim o seu conteúdo será preservado durante as actualizações.

## 11.5. Como é que o sistema Debian arranca?

Como todos os Unices, Debian arranca ao executar o programa `init`. Como a maioria das distribuições Linux, um sistema Debian predefinido usa `systemd` como a implementação de `init`. O init estilo System-V tradicional e outros métodos são também suportados. [6]

Para controlar a ordem pela qual os serviços são arrancados, os sistemas Unix estilo System-V tradicional usam runlevels. Estes foram substituídos por targets sob systemd. Para mostrar o target (alvo) predefinido no qual o systemd trará o sistema, corra o comando:

    systemctl get-default

Durante p arranque, o systemd arranca os serviços ou outros alvos listados no ficheiro alvo predefinido `/lib/systemd/system/default.target`. Os ficheiros para estes serviços e alvos estão instalados e o serviço é activado durante a instalação do pacote Debian. Se você especificamente desejar não arrancar um serviço durante o arranque da máquina, em vez de remover o pacote correspondente, pode correr o comando

    systemctl disable serviço.service

usando o nome do ficheiro de serviço instalado em `/lib/systemd/system` (geralmente baseado no nome do pacote).

O ficheiro de serviço `/lib/systemd/system/rc-local.service` fornece um modo fácil de correr scripts personalizados no ficheiro `/etc/rc.local` após o arranque do sistema, semelhante ao que é oferecido em sistemas Debian que correm init estilo System-V. Tenha atenção: este script irá falhar se tentar interagir com a consola como ao pedir uma palavra passe de utilizador ou tentar limpar o ecrã..

Você pode verificar o estado de qualquer serviço com o comando

    service pacote status

. Para arrancar ou parar um serviço, corra

    service pacote start

e

    service pacote stop

. O comando `service` funciona com qualquer sistema de init suportado num sistema Debian, não apenas com systemd. Se por acaso você preferir usar o mesmo comando em qualquer sistema Linux com suporte de systemd, para verificar o estado corra

    systemctl status pacote.service

para obter a mesma informação.

Para mais informação sobre systemd para Debian, veja https://wiki.debian.org/systemd.

## 11.6. E então acerca de Debian e o init System V tradicional?

Debian suporta arrancar usando init System V tradicional, via pacote sysvinit-core. O ficheiro de configuração para System V `init` (o qual é `/etc/inittab`) especifica que o primeiro script a ser executado deve ser `/etc/init.d/rcS`. Este script corre todos os scripts em `/etc/rcS.d/` ao bi-forcar sub-processos para executar a inicialização tais como verificar e montar sistemas de ficheiro, carregar módulos, arrancar os serviços de rede, definir o relógio, e executar outras inicializações.

Após completar o processo de arranque, `init` executa todos os scripts de arranque num directório especificado pelo runlevel predefinido (este runlevel é dado pela entrada para `id` em `/etc/inittab`). Como a maioria dos Unices compatíveis com System V, Linux tem 7 runlevels:

- 0 (pára o sistema),

- 1 (modo de único-utilizador),

- 2 até 5 (vários modos de multi-utilizador), e

- 6 (reinicia o sistema).

Os sistemas Debian vêm com id=2, o que indica que o runlevel predefinido será '2' quando se entra no estado de multi-utilizador, e os scripts em `/etc/rc2.d/` serão corridos.

Debian usa ordem de arranque baseada-em-dependências através de insserv, usando os cabeçalhos LSB em cada script sob `/etc/init.d/`, assim como arranque concorrente paralelo através do uso de startpar para acelerar o processo de arranque da máquina.

Os scripts em qualquer dos directórios, `/etc/rcN.d/` são apenas links simbólicos que apontam para scripts em `/etc/init.d/`. No entanto, os nomes dos ficheiros em cada um dos directórios `/etc/rcN.d/` são selecionados para indicar o modo em que os scripts em `/etc/init.d/` irão correr. Especificamente, antes de entrar em qualquer runlevel, são corridos todos os scripts começados com 'K'; estes scripts matam serviços. Depois são corridos todos os scripts começados por 'S'; estes scripts arrancam serviços. O número de dois-dígitos que se seguem ao 'K' ou 'S' indicam a ordem na qual o script corre. Os scripts com números inferiores são executados primeiro.

Este método funciona porque os scripts em `/etc/init.d/` todos recebem um argumento que pode ser um de "start", "stop", "reload", "restart" ou "force-reload" e irão então fazer a tarefa indicada pelo argumento. Estes scripts podem ser usados mesmo depois de um sistema ter arrancado, para controlar vários processos.

Por exemplo, com o argumento "reload" o comando

    /etc/init.d/sendmail reload

envia ao daemon do sendmail um sinal para re-ler o seu ficheiro de configuração.

Note que invoke-rc.d não deve ser usado para chamar os scripts `/etc/init.d/`, em vez disto deve ser usado service.

## 11.7. E ainda existem outras maneiras de arrancar um sistema Debian?

Se você gosta do init System V, mas não gosta dos links /etc/rc?.d/*, você pode instalar o pacote `file-rc`. Isso irá converter os links num único ficheiro de configuração em /etc/runlevel.conf.

Se você não gosta de System V nem systemd, pode gostar de `openrc` ou `runit` ou `daemontools`.

## 11.8. Como é que o sistema de gestão de pacotes lida com pacotes que contêm ficheiros de configuração para outros pacotes?

Alguns utilizadores desejam criar, por exemplo, um novo servidor ao instalarem um grupo de pacotes Debian e um pacote gerado localmente consistindo de ficheiros de configuração. Geralmente isto não é uma boa ideia, porque o dpkg não irá saber acerca desses ficheiros de configuração se eles estiverem num pacote diferente, e pode escrever configurações em conflito quando um do "grupo" inicial de pacotes é actualizado.

Em vez disso, crie um pacote local que modifica os ficheiros de configuração do "grupo" de pacotes Debian que interessa. Então o dpkg e o resto do sistema de gestão de pacotes irá ver que os ficheiros foram modificados pelo "sysadmin" local e não os irá tentar sobrescrever quando esses pacotes forem actualizados.

## 11.9. Como é que Eu sobreponho um ficheiro instalado por um pacote, para que possa ser usada uma versão diferente?

Supondo que um administrador de sistema ou um utilizador local deseja usar um programa "login-local" em vez do programa "login" fornecido pelo pacote Debian `login`.

Não faça:

- Sobrepor `/bin/login` com `login-local`.

O sistema de gestão de pacotes não irá saber desta alteração, e irá simplesmente sobrescrever o seu `/bin/login` personalizado sempre que `login` (ou qualquer pacote que forneça `/bin/login`) seja instalado ou actualizado.

Em vez disso, faça

- Execute:

      dpkg-divert --divert /bin/login.debian /bin/login

  De modo a fazer com que todas as instalações futuras do pacote Debian `login` escreva o ficheiro `/bin/login.debian` em vez de `/bin/login`.

- Depois execute:

      cp login-local /bin/login

  para mover o seu programa compilado localmente para o seu lugar.

Corra `dpkg-divert --list` para ver quais desvios estão actualmente activos no seu sistema.

Detalhes são fornecidos no manual dpkg-divert(8).

## 11.10. Como é que Eu posso ter o meu pacote localmente compilado na lista de pacotes disponíveis que o sistema de gestão de pacotes conhece?

Execute o comando:

    dpkg-scanpackages BIN_DIR OVERRIDE_FILE [PATHPREFIX] > my_Packages

onde:

- BIN-DIR é um directório onde ficheiros de arquivo Debian (que geralmente têm a extensão ".deb") são armazenados.

- OVERRIDE_FILE é um ficheiro que é editado pelos responsáveis da distribuição e é geralmente armazenado num arquivo Debian em `indices/override.main.gz` para os pacotes Debian na distribuição main". Você pode ignorar isto para pacotes locais.

- PATHPREFIX é uma string opcional que pode prefixada no ficheiro `my_Packages` a ser produzido.

Após você ter compilado o ficheiro `my_Packages`, diga ao sistema de gestão de pacotes que ele existe usando o comando:

    dpkg --merge-avail my_Packages

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

## 11.11. Alguns utilizadores gostam de mawk, outros gostam de gawk; alguns gostam de vim, outros gostam de elvis; alguns gostam de trn, outros de tin; como é que Debian suporta diversidade?

Há vários casos onde dois pacotes fornecem duas versões diferentes de um programa, que dos quais ambos fornecem a mesma funcionalidade central. Os utilizadores podem preferir um sobre o outro por hábito, ou porque a interface e utilizador de um é mais agradável que a do outro. Outros utilizadores no mesmo sistema podem fazer uma escolha diferente.

Debian usa um sistema de pacotes "virtuais" que permitem aos administradores de sistemas escolher (ou deixar os utilizadores escolher) as suas ferramentas favoritas quando existem duas ou mais que fornecem a mesma funcionalidade básica, no entanto satisfazendo os requisitos de dependências de pacotes sem especificar um pacote específico.

Por exemplo, podem existir duas versões diferentes de leitor-de-notícias num sistema. O pacote de servidor de notícias pode 'recomendar' que existe algum leitor de noticias no sistema, mas a escolha de `tin` ou `trn` é deixada ao utilizador individual. Isto é satisfeito ao ter ambos pacotes `tin` e `trn` a fornecer o pacote virtual `news-reader`. Qual programa é invocado é determinado por um link que aponta parta um ficheiro com o nome do pacote virtual `/etc/alternatives/news-reader` para o ficheiro selecionado, ex. `/usr/bin/trn`.

Um link único é insuficiente para suportar a utilização total de um programa alternativo, normalmente, os manuais, e possivelmente outros ficheiros de suporte têm também de ser selecionados. O script Perl `update-alternatives` fornece um modo de assegurar que todos os ficheiros associados a um pacote específico são selecionados como uma predefinição de sistema.

Por exemplo, para verificar que executáveis fornecem "x-window-manager", corra:

    update-alternatives --display x-window-manager

Se desejar alterar, corra:

    update-alternatives --config x-window-manager

E siga as instruções no ecrã (basicamente, pressione o número próximo da entrada que você mais gosta).

Se um pacote não se auto-registar como um gestor de janelas por alguma razão (reporte um bug se for um erro), ou se você usar um gestor de janelas do directório /usr/local, as seleções no ecrã não irão conter a sua entrada preferida. Você pode actualizar o link através de opções de linha de comandos, 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" é o link simbólico que aponta para /etc/alternatives/NOME, onde NOME é o segundo argumento. O terceiro argumento é o programa para o qual /etc/alternatives/NOME deve apontar, e o quarto argumento é a prioridade (uma valor maior significa que a alternativa terá maior probabilidade de ser escolhida automaticamente.

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

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

[6] Em 2014, Debian mudou o seu sistema init predefinido de System V init para systemd. Debian 8 "jessie" em April 2015 foi o primeiro lançamento a vir com systemd como init predefinido. Quatro decisões do Debian Technical Committee estiveram envolvidas: Bug #727708 2014-02-11: "The committee decided that the default init system for Linux architectures in jessie should be systemd." Bug #746715 2014-08-01: "The technical committee expects maintainers to continue to support the multiple available init systems", e fundir as contribuições razoáveis. Bug #746578 2014-11-15: "The committee decided that systemd-shim should be the first listed alternative dependency of libpam-systemd instead of systemd-sysv." Esta decisão facilitou o manter a funcionar um sistema Debian não-systemd, Bug #7621942017-11-04: "On automatic init system switching on upgrade"

Capítulo 10. Debian e o kernel. |  | Capítulo 12. Obtendo suporte para Debian GNU/Linux