Difference between revisions of "Enhance system stability (Português)"

From ArchWiki
Jump to: navigation, search
m
m (Utilize o gerenciador de pacotes para instalar software)
Line 71: Line 71:
 
   make() {
 
   make() {
 
     [ "$1" == 'install' ] &&
 
     [ "$1" == 'install' ] &&
       echo -e "WARNING:\nDON'T INSTALL SOFTWARE MANUALLY\nDON'T USE unset make TO OVERRIDE" &&
+
       echo -e "AVISO:\nNÃO INSTALE SOFTWARE MANUALMENTE\nNÃO USE unset make PARA SOBRESCREVER" &&
       echo "Tip: It's easy to make own custom package see: man PKGBUILD makepkg" &&
+
       echo "Dica: É fácil criar seus próprios pacotes. Veja: man PKGBUILD makepkg" &&
 
       return 1;
 
       return 1;
 
     /usr/bin/make $@;
 
     /usr/bin/make $@;

Revision as of 14:26, 3 September 2013

O objetivo deste artigo é dar dicas de como tornar seu sistema Arch Linux o mais estável possível. Mesmo com os desenvolvedores do Arch e seus usuários confiáveis(Trusted Users) trabalhando para produzir pacotes de grande qualidade, devido a natureza rolling release do Arch Linux e evolução rápida dos pacotes, esta distribuição pode não ser a mais adequada para ambientes de missão crítica e comerciais.

Contudo, o Arch internalizou a estabilidade devido a sua simplicidade de configuração, junto com um ciclo de criação e resolução de bugs bastante rápido e o uso de códigos-fonte sem muita aplicação de patches. E, seguindo as instruções abaixo de configuração e manutenção do Arch, o usuário desfrutará de um sistema bastante estável. Como adicional, também serão passadas dicas que tornarão mais fáceis os reparos futuros devido a um mal funcionamento do sistema.

O quão estável o Arch Linux pode ser? Existem diversos relatórios nos fóruns do Arch de Administradores habilidosos com bastante sucesso ao utilizá-lo em servidores de produção. Archlinux.org é um destes exemplos. No desktop, um sistema bem configurado e mantido pode oferecer excelente estabilidade.

Configurando o Arch

Quando efetuamos a instalação e configuração do Arch Linux, existe uma variedade de opções de configuração que devemos fazer, de software ou drivers. Todas estas escolhas impactam diretamente na estabilidade do sistema.

Dicas específicas do Arch

Mantendo pacotes antigos em uma partição /var grande

O Pacman mantém todos os pacotes previamente instalados no caminho /var/cache/pacman/pkg, que pode crescer para alguns GB em tamanho. Se você irá configurar partições separadas durante a instalação, tenha a certeza de alocar bastante espaço no /var. De 4 a 8 GB poderá ser suficiente, contudo um espaço maior pode ser necessário para servidores. Manter estes pacotes é útil em um caso onde uma atualização pode causar instabilidade, requerendo um downgrade para uma versão antiga do pacote problemático. Veja a seção #Revertendo pacotes que causaram instabilidade

Utilize as configurações recomendadas

O documento de instalação detalhada do Arch Linux geralmente exibe mais de uma forma de configurar uma característica específica do sistema. Sempre utilize a configuração padrão recomendada quando configurar seu sistema. Esta configuração sempre reflete as melhores práticas, escolhidas para um sistema de maior estabilidade e de mais fácil reparo.

Seja cuidadoso com pacotes não-oficiais e menos testados

Evite utilizar qualquer repositório de testes, ou pacotes vindo destes. Estes pacotes experimentais são para tais fins(testes e desenvolvimento) e não são adequados para um sistema estável

Seja precavido ao utilizar pacotes vindos do AUR. A maioria destes pacotes são disponibilizados por usuários e pode não possuir a mesma qualidade de empacotamento dos repositórios oficiais. Sempre verifique o PKGBUILD do AUR buscando qualquer erro ou código malicioso antes de criar e instalar tais pacotes.

Seja também cuidadoso com os AUR helpers que simplificam bastante a instalação de pacotes vindos do AUR e podem induzir a criação e instalação de pacotes mal formatados ou com PKGBUILD de conteúdo malicioso. Sempre verifique a sanidade de um PKGBUILD antes de criar e/ou instalar um pacote.

Por último, é bastante imprudente utilizar um AUR helpers ou o comando makepkg como root.

Apenas utilize repositórios de terceiros se for absolutamente necessário e se você sabe o que está fazendo. Sempre busque fontes confiáveis sobre tais repositórios.

Utilize espelhos atualizados

Utilize espelhos que são atualizados com mais frequência para os pacotes do FTP principal do Arh Linux. Verifique o site status do espelho para verificar se o escolhido por você está atualizado. Utilizando espelhos que possuem um rsync recente garante que seu sistema poderá obter os pacotes mais recentes bem como bancos de dados de pacotes disponíveis mais rapidamente, tendo-os já sincronizados em caso de uma manutenção.

E se você se sentir confortável, edite a lista de espelhos em /etc/pacman.d colocando os locais(que estão na sua região/seu país) no topo da lista. Veja a página habilitando seu espelho favorito para maiores detalhes, incluindo a instalação do script rankmirrors que avaliará os espelhos mais rápidos. Estes passos grantem que você utilizará os espelhos mais rápidos e confiáveis.

Após alterar um repositório, atualize seu sistema através de um pacman -Syu.

Evite pacotes de desenvolvimento

To prevent serious breakage of the system, do not install any development packages, which are usually found in AUR and occasionally in community. These are packages taken directly from upstream development branches, and usually feature one of the following words appended to the package name: dev, devel, svn, cvs, git, hg, bzr, or darcs.

Most especially, avoid installing any development version of crucial system packages such as the kernel or glibc.

If building a custom package using makepkg, be sure that the PKGBUILD follows the Arch Packaging Standards, including a provides array. Use namcap to check the final .tar.gz or PKGBUILD file.

Instale o pacote linux-lts

O pacote linux-lts é uma alternativa de kernel para o Arch baseado no Linux 3.0 e está disponível no repositório [core]. Esta versão do kernel em particular possui a sigla LTS(long-term support) que possui atualizações de códigos-fonte relacionados a segurança, e backports de funcionalidades de kernels mais novos para esta versão, sendo especialmente útil a usuários do Arch buscando por um kernel para servidor, e que não desejam utilizar o fallback caso uma nova versão de kernel dê problemas.

Para disponibilizar esta opção no boot, você necessitará atualizar a configuração do seu bootloader. Por exemplo, se você utiliza o Syslinux, deverá editar o /boot/syslinux/syslinux.cfg e duplicar as entradas exceto pela alteração da imagem em initramfs para vmlinuz-linux-lts e initramfs-linux-lts.img. Para o GRUB, o método recomendado é gerar um novo .cfg automaticamente.

Alguns preferem instalar o pacote linux-lts como um adicional ao pacote linux, e apontar a entrada "Fallback" de bootloader para o kernel LTS.

Melhores práticas genéricas

Utilize o gerenciador de pacotes para instalar software

O gerenciador de pacotes (no Arch: pacman) faz o serviço melhor que você de rastrear e manter arquivos. Se você instalar software manualmente logo você irá esquecer o que fez, e cedo ou tarde instalará mais software que conflitará e desorganizará tudo.

Do ponto de vista da estabilidade, você deve tentar evitar pacotes não suportados e software customizado, mas se você realmente precisa destes softwares o ideal é criar um pacote ao invés de compilar e instalar manualmente.

Desabilite o comando make install(que geralmente é o início dos problemas) dentro de /root/.bashrc

 make() {
   [ "$1" == 'install' ] &&
     echo -e "AVISO:\nNÃO INSTALE SOFTWARE MANUALMENTE\nNÃO USE unset make PARA SOBRESCREVER" &&
     echo "Dica: É fácil criar seus próprios pacotes. Veja: man PKGBUILD makepkg" &&
     return 1;
   /usr/bin/make $@;
 }

Utilize pacotes mainstream e comprovados

Instale softwares mainstream e de maturidade comprovada. Além de evitar softwares cutting edge que tendem a possuir mais bugs, evite as versões "ponto zero", aka x.y.0 de uma determinada versão de software. Por exemplo, ao instalar o software foobar 2.5.0 espere pela versão 2.5.1. Não padronize e utilize software novo sem que comprovada sua estabilidade e confiabilidade através de testes. Por exemplo, as primeiras versões do PulseAudio tendem a ser problemáticas. Usuários interessados em maior estabilidade devem utilizar o sistema de som ALSA. Por último, busque por softwares que possuem uma comunidade ampla e desenvolvimento ativo.

Escolha drivers de código aberto

Sempre que possível, utilize drivers de código aberto(open source). Evite drivers proprietários. Na maioria dos casos, os drivers abertos são mais estáveis e confiáveis que os proprietários. Drivers abertos tem seus bugs corrigidos de forma mais fácil e rápida. Enquanto drivers proprietários pode oferecer mais funcionalidades e capacidades, este pode ser o custo da estabilidade. Para evitar tal dilema, escolha componentes de hardware que possuem drivers abertos maduros e com suporte a maioria ou todas as funcionalidades. Informações sobre hardware com drivers abertos podem ser encontradas em linux-drivers.org.

Dando manutenção ao Arch

Adicionalmente a configuração do Arch focada em estabilidade, estes são alguns passos durante a manutenção que vão aumentar a estabilidade. Preste atenção nas dicas de alguns Administradores de Sistemas que irão ajudar a manter a confiabilidade contínua do sistema.

Dicas específicas do Arch

Atualize todo o sistema com frequência

Muitos usuários do Arch atualizam frequentemente, até mesmo diariamente a atualização de sistemas através do comando pacman -Syu. Enquanto atualizar de forma tão frequente não é necessário, é uma boa forma de obter as últimas atualizações relativas a correção de bugs e segurança. Atualizações semanais e bissemanais são uma boa idéia.

Se seu sistema possui pacotes do AUR, cuidadosamente atualize todos os pacotes do AUR.

Leia antes de atualizar o sistema

Antes de atualizar o Arch, sempre leia as últimas notícias no Arch News para verificar se há alguma grande alteração de software ou de configuração nos últimos pacotes, necessitando até mesmo intervenção manual. Antes de atualizar qualquer software crítico, como o kernel, xorg, glibc, dê uma olhada no fórum apropriado e veja se não há problemas reportados por outros usuários.

Tome ações em alertas durante uma atualização

Quando atualizar o sistema, preste atenção nos alertas providos pelo pacman. Se quaisquer ações adicionais forem necessárias pelo usuário, tome o cuidado de fazê-las da forma certa. Se um alerta do pacman for confuso, busque nos fóruns por postagens recentes de instruções mais detalhadas.

Gerencie antecipatamente arquivos .pacnew, .pacsave e .pacorig

Quando o pacman remove um pacote que possui arquivo de configuração, ele normalmente cria um backup deste arquivo e adiciona o sufixo .pacsave ao nome do original. Da mesma forma, quando o pacman atualiza um pacote que inclui um novo arquivo de configuração criado por um mantenedor, e que possua diferenças do arquivo atual, o sufixo .pacnew é adicionado a um novo arquivo. Ocasionalmente, em circunstâncias especiais, o arquivo .pacorig é criado. O pacman sempre avisa da existência ou escrita destes arquivos.

Users must deal with these files promptly when pacman creates them, in order to ensure optimum system stability. Users are referred to the Pacnew and Pacsave Files wiki page for detailed instructions.

Consider using pacmatic

Pacmatic is a pacman wrapper which automates the process of checking Arch News prior to upgrading. Pacmatic also ensures that the local pacman database is correctly synchronized with online mirrors, thus avoiding potential problems with botched pacman -Sy database updates. Finally, it provides more stringent warnings about updated or obsolete config files. pacman can be aliased to pacmatic, and various AUR helpers can be configured to use it instead of pacman.

Avoid certain pacman commands

Arch being a rolling release distribution, it can be dangerous to refresh pacman databases without doing a full system upgrade immediately after. Avoid using pacman -Sy package to install a package, but always use pacman -S package instead. And upgrade your system regularly with pacman -Syu.

Avoid using the -f option with pacman, especially in commands such as pacman -Syuf involving more than one package. The --force option ignores file conflicts and can even cause file loss when files are relocated between different packages! In a properly maintained system, it should never need to be used.

Do not use pacman -Rdd package. Using the -d flag skips dependency checks during package removal. As a result, a package providing a critical dependency could be removed, resulting in a broken system.

Never run pacman -Scc unless there is a desperate need for the disk space, and little or no need for archived package files. It is safer to keep older packages available in the cache archives in the event a package upgrade causes problems, requiring a package reversion. Instead, just use pacman -Sc to clean out the archived packages in the pacman cache, of packages previously removed from the pacman database.

Make sure to only use this command if there is no intention of re-installing recently removed packages. If such packages are re-installed after this command has been executed, there will be no older, archived versions of the packages in the pacman cache.

In the event that /var disk space becomes scarce, move all archived packages to the home directory using the fduparch.sh script. Use the fduppkg script to move all but the last previously installed package versions in the pacman cache archives, to the home directory.

Revertendo pacotes que causaram instabilidade

In the event that a particular package upgrade results in system instability, install the last known stable version of the package from the local pacman cache using the following command:

pacman -U /var/cache/pacman/pkg/Package-Name.pkg.tar.gz

For more detailed information on reverting to older packages, consult the Arch wikipage, Downgrading Packages.

Once the package is reverted, temporarily add it to the IgnorePkg section of pacman.conf, until the difficulty with the updated package is resolved. Consult the Arch wiki and/or webforums for advice, and file a bug report if necessary.

Regularly backup a list of installed packages

At regular intervals, create a list of installed packages and store a copy on one or more offline media, such as a USB stick, external hard drive, or CD-R. Use the following command to create a pkglist:

pacman -Qqne > /path/to/chosen/directory/pkg.list

In the event of a catastrophic system failure requiring a complete re-installation, these packages can be quickly reinstalled using the command:

pacman -S --needed $(< /path/to/chosen/directory/pkg.list )

Regularly backup the pacman database

The following command can be used to backup the local pacman database, and can be run as a cronjob:

tar -cjf /path/to/chosen/directory/pacman-database.tar.bz2 /var/lib/pacman/local

Store the backup pacman database file on one or more offline media, such as a USB stick, external hard drive, or CD-R.

Restore the backup pacman database file by moving the pacman-database.tar.bz2 file into the / directory and executing the following command:

tar -xjvf pacman-database.tar.bz2

If the pacman database files are corrupted, and there is no backup file available, there exists some hope of rebuilding the pacman database. Consult the Arch wikipage, How To Restore Pacman's Local Database.

Systemd Automation

You can configure systemd to backup the pacman database everytime a new package is installed or updated, save and run the following scripts. See here.

Generic Best Practices

Subscribe to NVD/CVE alerts and only upgrade on a security alert

Subscribe to the Common Vulnerabilities and Exposure Security Alert updates, made available by National Vulnerability Database, and found on the NVD Download webpage. Only update the Arch system when a security alert is issued for a package installed on that particular system.

This is the alternative to upgrading the entire system frequently. It ensures that security problems in various packages are resolved promptly, while keeping all the rest of the packages frozen in a known, stable configuration. However, reviewing the frequent CVE Alerts to see if any apply to installed Arch packages can be tedious and time consuming.

Test updates on a non-critical system

If possible, test changes to configuration files, as well as updates to software packages, on a non-critical duplicate system first. Then, if no problems arise, roll out the changes to the production system.

Always backup config files before editing

Before editing any configuration file, always back up a known working version of that config file. In the event that changes in the config file cause problems, one can revert to the previous stable config file. Do this from a text editor by first saving the file to a backup copy before making any alterations; or execute the following command:

cp config config.bak

Using .bak will ensure there is a readily distinguishable human-made backup conf file if pacman creates a .pacnew, .pacsave, or .pacorig file using the active config file.

etckeeperAUR can help dealing with config files. It keeps the whole /etc directory in a version control.

Regularly backup the /etc, /home, /srv, and /var directories

Since /etc, /home, /srv and /var directories contain important system files and configs, it is advisable to keep backup of these folders on a regular interval. The following is a simple guide line on how to go about it.

  • /etc: Backup the /etc directory by executing the following command as root or as a cronjob:
tar -cjf /path/to/chosen/directory/etc-backup.tar.bz2 /etc

Store the /etc backup file on one or more offline media, such as a USB stick, external hard drive, or CD-R. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.

Restore corrupted /etc files by extracting the etc-backup.tar.bz2 file in a temporary working directory, and copying over individual files and directories as needed. To restore the entire /etc directory with all its contents, move the etc-backup.tar.bz2 files into the / directory. As root, execute the following command:

tar -xvjf etc-backup.tar.bz2
  • /home: At regular intervals, backup the /home directory to an external hard drive, Network Attached Server, or online backup service. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups.
  • /srv: Server installations should have the /srv directory regularly backed up.
  • /var: Additional directories in /var, such a /var/spool/mail or /var/lib, which also require backup and occasional verification.

If you want to backup much faster (using parallel compression, SMP), you should use pbzip2 (Parallel bzip2). The steps are slightly different, but not by much.

First we will backup the files to a plain tarball with no compression:

tar -cvf /path/to/chosen/directory/etc-backup.tar /etc

Then we will use pbzip2 to compress it in parallel (Make sure you install it with pacman -S pbzip2)

pbzip2 /path/to/chosen/directory/etc-backup.tar.bz2

and that's it. Your files should be backing up using all of your cores.