Linux Professional Institute Learning Logo.
Ir para o conteúdo principal
  • Home
    • Todos os recursos
    • LPI Materiais Didáticos
    • Colabore Conosco
    • Publishing Partners
    • Seja um Publishing Partner
    • Quem Somos
    • FAQ
    • Colaboradores
    • Contato
  • LPI.org
101.3 Lição 1
Tópico 101: Arquitetura de Sistema
101.1 Identificar e editar configurações de hardware
  • 101.1 Lição 1
101.2 Início (boot) do sistema
  • 101.2 Lição 1
101.3 Alternar runlevels/boot targets, desligar e reiniciar o sistema
  • 101.3 Lição 1
Tópico 102: Instalação do Linux e administração de Pacotes
102.1 Dimensionar partições de disco
  • 102.1 Lição 1
102.2 Instalar o gerenciador de inicialização
  • 102.2 Lição 1
102.3 Controle de bibliotecas compartilhadas
  • 102.3 Lição 1
102.4 Utilização do sistema de pacotes Debian
  • 102.4 Lição 1
102.5 Utilização do sistema de pacotes RPM e YUM
  • 102.5 Lição 1
102.6 Linux virtualizado
  • 102.6 Lição 1
Tópico 103: Comandos GNU e Unix
103.1 Trabalhar na linha de comando
  • 103.1 Lição 1
  • 103.1 Lição 2
103.2 Processar fluxos de texto usando filtros
  • 103.2 Lição 1
103.3 Gerenciamento básico de arquivos
  • 103.3 Lição 1
  • 103.3 Lição 2
103.4 Fluxos, pipes (canalização) e redirecionamentos de saída
  • 103.4 Lição 1
  • 103.4 Lição 2
103.5 Criar, monitorar e finalizar processos
  • 103.5 Lição 1
  • 103.5 Lição 2
103.6 Modificar a prioridade de execução de um processo
  • 103.6 Lição 1
103.7 Procurar em arquivos de texto usando expressões regulares
  • 103.7 Lição 1
  • 103.7 Lição 2
103.8 Edição básica de arquivos com o vi
  • 103.8 Lição 1
Tópico 104: Dispositivos, sistemas de arquivos Linux e padrão FHS
104.1 Criar partições e sistemas de arquivos
  • 104.1 Lição 1
104.2 Manutenção da integridade de sistemas de arquivos
  • 104.2 Lição 1
104.3 Controle da montagem e desmontagem dos sistemas de arquivos
  • 104.3 Lição 1
104.5 Controlar permissões e propriedades de arquivos
  • 104.5 Lição 1
104.6 Criar e alterar links simbólicos e hardlinks
  • 104.6 Lição 1
104.7 Encontrar arquivos de sistema e conhecer sua localização correta
  • 104.7 Lição 1
How to get certified
  1. Tópico 101: Arquitetura de Sistema
  2. 101.3 Alternar runlevels/boot targets, desligar e reiniciar o sistema
  3. 101.3 Lição 1

101.3 Lição 1

Certificação:

LPIC-1

Versão:

5.0

Tópico:

101 Arquitetura do sistema

Objetivo:

101.3 Alterar níveis de execução/destinos de inicialização e desligar ou reiniciar o sistema

Lição:

1 de 1

Introdução

Uma característica comum entre os sistemas operacionais que seguem os princípios de design do Unix é o emprego de processos separados para controlar funções distintas do sistema. Esses processos, chamados daemons (ou, mais geralmente, serviços), também são responsáveis pelos recursos estendidos subjacentes ao sistema operacional, como serviços de aplicativos de rede (servidor HTTP, compartilhamento de arquivos, email…​), bancos de dados, configuração sob demanda etc. Embora o Linux utilize um kernel monolítico, muitos aspectos de baixo nível do sistema operacional são afetados por daemons, como o balanceamento de carga e a configuração do firewall.

Os daemons que devem estar ativos dependem da finalidade do sistema. O conjunto de daemons ativos também deve ser modificável em tempo de execução, para que os serviços possam ser iniciados e interrompidos sem a necessidade de se reiniciar o sistema inteiro. Para resolver esse problema, todas as principais distribuições Linux oferecem algum tipo de utilitário de gerenciamento de serviços para controlar o sistema.

Os serviços podem ser controlados por scripts do shell ou por um programa e seus arquivos de configuração. O primeiro método é implementado pelo padrão SysVinit, também conhecido como System V ou apenas SysV. O segundo método é implementado por systemd e Upstart. Historicamente, os gerenciadores de serviços baseados em SysV eram os mais utilizados pelas distribuições Linux. Hoje, os gerenciadores de serviços baseados no systemd são os mais frequentes na maioria das distribuições Linux. O gerenciador de serviços é o primeiro programa lançado pelo kernel durante o processo de inicialização, portanto seu PID (número de identificação do processo) é sempre 1.

SysVinit

Um gerenciador de serviços baseado no padrão SysVinit fornece conjuntos predefinidos de estados do sistema, chamados níveis de execução, além dos arquivos correspondentes de script dos serviços a serem executados. Os níveis de execução são numerados de 0 a 6, geralmente atribuídos às seguintes finalidades:

Nível de execução 0

Encerramento do sistema.

Nível de execução 1, s ou single

Modo de usuário único, sem rede e outros recursos não-essenciais (modo de manutenção).

Nível de execução 2, 3 ou 4

Modo multiusuário. Os usuários podem se logar via console ou pela rede. Os níveis de execução 2 e 4 não são usados com frequência.

Nível de execução 5

Modo multiusuário. Equivale ao nível 3, mais o login em modo gráfico.

Nível de execução 6

Reinicialização do sistema.

O programa responsável pelo gerenciamento de níveis de execução e daemons/recursos associados é /sbin/init. Durante a inicialização do sistema, o programa init identifica o nível de execução solicitado, definido por um parâmetro do kernel ou no arquivo /etc/inittab, e carrega os scripts associados listados ali para o nível de execução especificado. Cada nível de execução pode ter diversos arquivos de serviço associados, geralmente scripts no diretório /etc/init.d/. Como nem todos os níveis de execução se equivalem nas diferentes distribuições Linux, uma breve descrição do objetivo do nível de execução também pode ser encontrada nas distribuições baseadas em SysV.

A sintaxe do arquivo /etc/inittab usa o seguinte formato:

id:runlevels:action:process

id é um nome genérico de até quatro caracteres usado para identificar a entrada. O item runlevels é uma lista de números dos níveis de execução nos quais uma ação especificada deve ser executada. O termo action define como init executará o processo indicado pelo termo process. As ações disponíveis são:

boot

O processo será executado durante a inicialização do sistema. O campo runlevels é ignorado.

bootwait

O processo será ignorado durante a inicialização do sistema e o init aguardará sua conclusão para continuar. O campo runlevels é ignorado.

sysinit

O processo será executado após a inicialização do sistema, qualquer que seja o nível de execução. O campo runlevels é ignorado.

wait

O processo será executado nos níveis de execução dados e init aguardará sua conclusão para continuar.

respawn

O processo será reiniciado caso seja encerrado.

ctrlaltdel

O processo será executado quando o processo init receber o sinal SIGINT, disparado quando o atalho de teclado Ctrl+Alt+Del for pressionado.

O nível de execução padrão — que será escolhido se nenhum outro for fornecido como parâmetro do kernel — também é definido em /etc/inittab, na entrada id:x:initdefault. x é o número do nível de execução padrão. Esse número nunca deve ser 0 ou 6, pois isso faria com que o sistema desligasse ou reiniciasse ao final do processo de inicialização. Um arquivo /etc/inittab típico é mostrado abaixo:

# Default runlevel
id:3:initdefault:

# Configuration script executed during boot
si::sysinit:/etc/init.d/rcS

# Action taken on runlevel S (single user)
~:S:wait:/sbin/sulogin

# Configuration for each execution level
l0:0:wait:/etc/init.d/rc 0
l1:1:wait:/etc/init.d/rc 1
l2:2:wait:/etc/init.d/rc 2
l3:3:wait:/etc/init.d/rc 3
l4:4:wait:/etc/init.d/rc 4
l5:5:wait:/etc/init.d/rc 5
l6:6:wait:/etc/init.d/rc 6

# Action taken upon ctrl+alt+del keystroke
ca::ctrlaltdel:/sbin/shutdown -r now

# Enable consoles for runlevels 2 and 3
1:23:respawn:/sbin/getty tty1 VC linux
2:23:respawn:/sbin/getty tty2 VC linux
3:23:respawn:/sbin/getty tty3 VC linux
4:23:respawn:/sbin/getty tty4 VC linux

# For runlevel 3, also enable serial
# terminals ttyS0 and ttyS1 (modem) consoles
S0:3:respawn:/sbin/getty -L 9600 ttyS0 vt320
S1:3:respawn:/sbin/mgetty -x0 -D ttyS1

O comando telinit q deve ser executado a cada vez que o arquivo /etc/inittab é modificado. O argumento q (ou Q) pede que o init recarregue sua configuração. Essa etapa é importante para evitar uma parada do sistema devido a uma configuração incorreta em /etc/inittab.

Os scripts usados pelo init para configurar cada nível de execução ficam armazenados no diretório /etc/init.d/. Cada nível de execução tem um diretório associado em /etc/, chamado /etc/rc0.d/, /etc/rc1.d/, /etc/rc2.d/, etc., com os scripts que devem ser executados quando cada nível de execução é iniciado. Como o mesmo script pode ser usado por diferentes níveis de execução, os arquivos nesses diretórios são apenas links simbólicos para os scripts reais em /etc/init.d/. Além disso, a primeira letra do nome do arquivo do link no diretório do nível de execução indica se o serviço deve ser iniciado ou encerrado no nível de execução correspondente. Um nome de arquivo iniciado com a letra K determina que o serviço será encerrado ao entrar no nível de execução (kill). Se começar com a letra S, o serviço será iniciado ao ingressar no nível de execução (start). O diretório /etc/rc1.d/, por exemplo, terá muitos links para scripts de rede iniciados com a letra K, considerando que o nível de execução 1 é o nível do usuário único, sem conectividade de rede.

O comando runlevel mostra o atual nível de execução do sistema. Esse comando exibe dois valores: o primeiro é o nível de execução anterior, o segundo o atual:

$ runlevel
N 3

A letra N na saída mostra que o nível de execução não mudou desde a última inicialização. No exemplo, runlevel 3 é o nível de execução atual do sistema.

O mesmo programa init pode ser usado para alternar entre níveis de execução em um sistema em execução sem a necessidade de reiniciar. O comando telinit também permite alternar entre níveis de execução. Por exemplo, os comandos telinit 1, telinit s ou telinit S mudarão o sistema para o nível de execução 1.

systemd

Atualmente, o systemd é o conjunto de ferramentas mais usado para gerenciar recursos e serviços do sistema, chamados de unidades (units) pelo systemd. Uma unidade consiste em um nome, um tipo e um arquivo de configuração correspondente. Por exemplo, a unidade para um processo de servidor httpd (como o servidor web Apache) será httpd.service nas distribuições baseadas no Red Hat e seu arquivo de configuração também será chamado httpd.service (nas distribuições baseadas em Debian, essa unidade é chamada apache2.service).

Existem sete tipos distintos de unidades systemd:

service

O tipo de unidade mais comum, para recursos ativos do sistema que podem ser iniciados, interrompidos e recarregados.

socket

O tipo de unidade socket pode ser um socket de sistema de arquivos ou um socket de rede. Todas as unidades socket possuem uma unidade de serviço correspondente, carregada quando o socket recebe uma solicitação.

device

Uma unidade de dispositivo está associada a um dispositivo de hardware identificado pelo kernel. Um dispositivo só será considerado como uma unidade systemd se existir uma regra udev para isso. Uma unidade de dispositivo pode ser usada para resolver dependências de configuração quando determinado hardware é detectado, uma vez que as propriedades da regra udev podem ser usadas como parâmetros para a unidade de dispositivo.

mount

Uma unidade de montagem é uma definição de ponto de montagem no sistema de arquivos, semelhante a uma entrada em /etc/fstab.

automount

Uma unidade de montagem automática também é uma definição de ponto de montagem no sistema de arquivos, mas nesse caso montada automaticamente. Cada unidade de montagem automática possui uma unidade de montagem correspondente, que é iniciada quando o ponto de montagem automática é acessado.

target

Uma unidade de destino é um agrupamento de outras unidades, gerenciadas como uma única unidade.

snapshot

Uma unidade snapshot é um estado salvo do gerenciador do systemd (não disponível em todas as distribuições Linux).

O principal comando para controlar as unidades do systemd é systemctl. O comando systemctl é usado para executar todas as tarefas relacionadas à ativação, desativação, execução, interrupção e monitoramento da unidade, entre outras. Para uma unidade ficcional chamada unit.service, por exemplo, as ações mais comuns do systemctl serão:

systemctl start unit.service

Inicia unit.

systemctl stop unit.service

Interrompe unit.

systemctl restart unit.service

Reinicia unit.

systemctl status unit.service

Mostra o estado de unit, incluindo se está ou não em execução.

systemctl is-active unit.service

Exibe active se unit estiver rodando, ou inactive se não estiver.

systemctl enable unit.service

Habilita unit, ou seja, unit será carregado durante a inicialização do sistema.

systemctl disable unit.service

unit não será iniciado com o sistema.

systemctl is-enabled unit.service

Verifica se unit é iniciado com o sistema. A resposta é armazenada na variável $?. O valor 0 indica que unit inicia com o sistema e o valor 1 indica que não.

Note

As instalações mais recentes do systemd listam, na verdade, a configuração de uma unidade para o tempo de inicialização. Por exemplo:

$ systemctl is-enabled apparmor.service
enabled

Se não houver outras unidades com o mesmo nome no sistema, o sufixo após o ponto poderá ser descartado. Se, por exemplo, houver apenas uma unidade httpd do tipo service, somente httpd bastará como parâmetro de unidade para systemctl.

O comando systemctl também pode controlar os destinos do sistema. A unidade multi-user.target, por exemplo, combina todas as unidades exigidas pelo ambiente do sistema multiusuário. É semelhante ao nível de execução número 3 em um sistema que utiliza o SysV.

O comando systemctl isolate alterna entre diferentes destinos. Assim, para alternar manualmente para o destino multi-user:

# systemctl isolate multi-user.target

Existem destinos correspondentes aos níveis de execução do SysV, desde runlevelO.target até runlevel6.target. Todavia, o systemd não usa o arquivo /etc/inittab. Para alterar o destino padrão do sistema, a opção systemd.unit pode ser adicionada à lista de parâmetros do kernel. Por exemplo, para usar multi-user.target como destino padrão, o parâmetro do kernel deve ser systemd.unit=multi-user.target. Todos os parâmetros do kernel podem ser tornados persistentes alterando-se a configuração do gerenciador de inicialização.

Outra maneira de alterar o destino padrão é modificar o link simbólico /etc/systemd/system/default.target para que ele aponte para o destino desejado. A redefinição do link pode ser feita com o próprio comando systemctl:

# systemctl set-default multi-user.target

Da mesma forma, podemos determinar o destino de inicialização padrão do sistema com o seguinte comando:

$ systemctl get-default
graphical.target

Como nos sistemas que adotam o SysV, o destino padrão nunca deve apontar para shutdown.target, pois ele corresponde ao nível de execução 0 (encerramento).

Os arquivos de configuração associados a cada unidade ficam no diretório /lib/systemd/system/. O comando systemctl list-unit-files lista todas as unidades disponíveis e mostra se elas estão habilitadas para iniciar quando o sistema é inicializado. A opção --type seleciona apenas as unidades para um tipo determinado, como em systemctl list-unit-files --type=service e systemctl list-unit-files --type=target.

As unidades ativas ou as que estiveram ativas durante a sessão atual do sistema podem ser listadas com o comando systemctl list-units. Como no caso da opção list-unit-files, o comando systemctl list-units --type=service seleciona somente as unidades de tipo service e o comando systemctl list-units --type=target seleciona somente as unidades do tipo target.

O systemd também é responsável por acionar e responder a eventos relacionados ao consumo de energia. O comando systemctl suspend coloca o sistema no modo de baixo consumo de energia, mantendo os dados atuais na memória. O comando systemctl hibernate copia todos os dados da memória no disco, para que o estado atual do sistema possa ser recuperado após o desligamento. As ações associadas a esses eventos são definidas no arquivo /etc/systemd/logind.conf ou em arquivos separados dentro do diretório /etc/systemd/logind.conf.d/. No entanto, esse recurso do systemd pode ser usado apenas quando não houver outro gerenciador de energia em execução no sistema, como o daemon acpid. O daemon acpid é o principal gerenciador de energia do Linux e permite ajustes mais refinados das ações após eventos relacionados ao consumo de energia, como fechar a tampa do laptop, bateria fraca ou níveis de carga da bateria.

Upstart

Os scripts de inicialização usados pelo Upstart estão localizados no diretório /etc/init/. Os serviços do sistema podem ser listados com o comando initctl list, que também mostra o estado atual dos serviços e, se disponível, seu número PID.

# initctl list
avahi-cups-reload stop/waiting
avahi-daemon start/running, process 1123
mountall-net stop/waiting
mountnfs-bootclean.sh start/running
nmbd start/running, process 3085
passwd stop/waiting
rc stop/waiting
rsyslog start/running, process 1095
tty4 start/running, process 1761
udev start/running, process 1073
upstart-udev-bridge start/running, process 1066
console-setup stop/waiting
irqbalance start/running, process 1842
plymouth-log stop/waiting
smbd start/running, process 1457
tty5 start/running, process 1764
failsafe stop/waiting

Cada uma das ações do Upstart tem seu próprio comando independente. Por exemplo, o comando start pode ser usado para iniciar um sexto terminal virtual:

# start tty6

O estado atual de um recurso pode ser verificado com o comando status:

# status tty6
tty6 start/running, process 3282

E a interrupção de um serviço é feita com o comando stop:

# stop tty6

O Upstart não usa o arquivo /etc/inittab para definir os níveis de execução, mas os comandos legados runlevel e telinit ainda podem ser usados para verificar e alternar entre níveis de execução.

Note

O Upstart foi desenvolvido para a distribuição Ubuntu Linux para facilitar a inicialização paralela dos processos. O Ubuntu parou de usar o Upstart em 2015, quando migrou do Upstart para o systemd.

Desligar e reiniciar

Um comando muito tradicional usado para desligar ou reiniciar o sistema é o shutdown. O comando shutdown adiciona funções extras ao processo de desligamento: ele notifica automaticamente todos os usuários conectados com uma mensagem em suas sessões do shell e impede novos logins. O comando shutdown atua como intermediário nos procedimentos do SysV ou do systemd, ou seja, executa a ação solicitada chamando a ação correspondente no gerenciador de serviços adotado pelo sistema.

Após o shutdown ser executado, todos os processos recebem o sinal SIGTERM, seguido pelo sinal SIGKILL, e o sistema é encerrado ou muda seu nível de execução. Por padrão, quando as opções -h ou -r não são usadas, o sistema alterna para o nível de execução 1, ou seja, o modo de usuário único. Para alterar as opções padrão de shutdown, o comando deve ser executado com a seguinte sintaxe:

$ shutdown [option] time [message]

Somente o parâmetro time é obrigatório. Esse parâmetro define quando a ação solicitada será executada, aceitando os seguintes formatos:

hh:mm

Este formato especifica o tempo de execução em horas e minutos.

+m

Este formato especifica quantos minutos esperar antes da execução.

now ou +0

Este formato determina a execução imediata.

O parâmetro message é o texto de aviso enviado a todas as sessões de terminal dos usuários logados.

A implementação do SysV permite limitar os usuários que poderão reiniciar a máquina pressionando Ctrl+Alt+Del. Para isso, incluímos a opção -a no comando shutdown presente na linha referente a ctrlaltdel no arquivo /etc/inittab. Ao fazer isso, somente usuários cujos nomes de usuário constem do arquivo /etc/shutdown.allow poderão reiniciar o sistema com o atalho de teclado Ctrl+Alt+Del.

O comando systemctl também pode ser usado para desligar ou reiniciar a máquina em sistemas que empregam o systemd. Para reiniciar o sistema, usamos o comando systemctl reboot. Para desligar o sistema, o comando é systemctl poweroff. Ambos os comandos requerem privilégios de root para serem executados, pois usuários comuns não podem realizar esses procedimentos.

Note

Algumas distribuições Linux vinculam poweroff e reboot a systemctl como comandos individuais. Por exemplo:

$ sudo which poweroff
/usr/sbin/poweroff
$ sudo ls -l /usr/sbin/poweroff
lrwxrwxrwx 1 root root 14 Aug 20 07:50 /usr/sbin/poweroff -> /bin/systemctl

Nem todas as atividades de manutenção exigem que o sistema seja desligado ou reiniciado. No entanto, quando é necessário alterar o estado do sistema para o modo de usuário único, é importante avisar os usuários conectados para que não sejam prejudicados pelo encerramento abrupto de suas atividades.

Como no caso do comando shutdown ao desligar ou reiniciar o sistema, o comando wall pode enviar uma mensagem para as sessões de terminal de todos os usuários logados. Para isso, o administrador do sistema só precisa fornecer um arquivo ou escrever diretamente a mensagem como um parâmetro para o comando wall.

Exercícios Guiados

  1. Como o comando telinit pode ser usado para reiniciar o sistema?

  2. O que acontece com os serviços relacionados ao arquivo /etc/rc1.d/K90network quando o sistema entra no nível de execução 1?

  3. Usando o comando systemctl, como um usuário pode verificar se a unidade sshd.service está em execução?

  4. Em um sistema baseado em systemd, qual comando deve ser executado para ativar a unidade sshd.service durante a inicialização do sistema?

Exercícios Exploratórios

  1. Em um sistema baseado em SysV, suponha que o nível de execução padrão definido em /etc/inittab seja 3, mas o sistema sempre inicia no nível de execução 1. Qual é a causa provável disso?

  2. Embora o arquivo /sbin/init possa ser encontrado nos sistemas baseados em systemd, ele é apenas um link simbólico para outro arquivo executável. Nesses sistemas, qual o arquivo apontado por /sbin/init?

  3. Como se verifica o destino padrão do sistema em um sistema baseado em systemd?

  4. Como poderíamos cancelar uma reinicialização do sistema programada com o comando shutdown?

Resumo

Esta lição aborda os principais utilitários usados como gerenciadores de serviços pelas distribuições Linux. Os utilitários SysVinit, systemd e Upstart têm sua abordagem própria para controlar serviços e estados do sistema. A lição inclui os seguintes tópicos:

  • O que são os serviços do sistema e qual seu papel no sistema operacional.

  • Conceitos e utilização básica dos comandos do SysVinit, systemd e Upstart commands.

  • Como iniciar, interromper e reiniciar apropriadamente os serviços do sistema e o próprio sistema.

Os comandos e procedimentos abordados foram:

  • Comandos e arquivos relacionados ao SysVinit, como init, /etc/inittab e telinit.

  • O comando principal do systemd: systemctl.

  • Comandos do Upstart: initctl, status, start, stop.

  • Comandos tradicionais de gerenciamento do sistema, como shutdown e o comando wall.

Respostas aos Exercícios Guiados

  1. Como o comando telinit pode ser usado para reiniciar o sistema?

    O comando telinit 6 alterna para o nível de execução 6, ou seja, reinicia o sistema.

  2. O que acontece com os serviços relacionados ao arquivo /etc/rc1.d/K90network quando o sistema entra no nível de execução 1?

    Como mostra a letra K no início do nome do arquivo, os serviços relacionados serão interrompidos.

  3. Usando o comando systemctl, como um usuário pode verificar se a unidade sshd.service está em execução?

    Com o comando systemctl status sshd.service ou systemctl is-active sshd.service.

  4. Em um sistema baseado em systemd, qual comando deve ser executado para ativar a unidade sshd.service durante a inicialização do sistema?

    O comando systemctl enable sshd.service, executado pelo root.

Respostas aos Exercícios Exploratórios

  1. Em um sistema baseado em SysV, suponha que o nível de execução padrão definido em /etc/inittab seja 3, mas o sistema sempre inicia no nível de execução 1. Qual é a causa provável disso?

    Os parâmetros 1 ou S podem estar presentes na lista de parâmetros do kernel.

  2. Embora o arquivo /sbin/init possa ser encontrado nos sistemas baseados em systemd, ele é apenas um link simbólico para outro arquivo executável. Nesses sistemas, qual o arquivo apontado por /sbin/init?

    O binário principal do systemd: /lib/systemd/systemd.

  3. Como se verifica o destino padrão do sistema em um sistema baseado em systemd?

    O link simbólico /etc/systemd/system/default.target aponta para o arquivo da unidade definido como destino padrão. Também é possível usar o comando systemctl get-default.

  4. Como poderíamos cancelar uma reinicialização do sistema programada com o comando shutdown?

    Usaríamos o comando shutdown -c.

Linux Professional Insitute Inc. Todos os direitos reservados. Visite o site dos Materiais Didáticos: https://learning.lpi.org
31/5000 Este trabalho está licenciado sob a Licença Creative Commons Atribuição-Uso Não-Comercial-NãoDerivativos 4.0 Internacional.

Próxima Lição

102.1 Dimensionar partições de disco (102.1 Lição 1)

Ir para a próxima lição

Linux Professional Insitute Inc. Todos os direitos reservados. Visite o site dos Materiais Didáticos: https://learning.lpi.org
31/5000 Este trabalho está licenciado sob a Licença Creative Commons Atribuição-Uso Não-Comercial-NãoDerivativos 4.0 Internacional.

A LPI é uma organização sem fins lucrativos.

© 2023 O Linux Professional Institute (LPI) é um organismo de apoio aos profissionais de Open Source e referência mundial em certificação. Com mais de 200.000 pessoas certificadas, somos o principal organismo de certificação independente para Linux e Open Source do mundo. O LPI certificou profissionais de mais de 180 países, oferece exames em diversos idiomas e tem centenas de parcerias de formação em todo o globo.

Nossa missão é proporcionar oportunidades econômicas e criativas para todos, tornando universalmente acessível a certificação de conhecimentos e competências em matéria de Open Source.

  • LinkedIn
  • flogo-RGB-HEX-Blk-58 Facebook
  • Twitter
  • Entre em Contato
  • Política de Privacidade e Cookies

Encontrou um erro ou quer ajudar a aprimorar esta página? Escreva pra nós.

© 1999–2023 The Linux Professional Institute Inc. Todos os direitos reservados.