MaterialComplementar V1

GNU/Linux - Conceitos e Comandos
Material de apio para a disciplina Gesão de serviços de redes
Clayton Lobato
Copyright c 2016 Clayton Lobato
P UBLISHED BY P UBLISHER
DMICONSULTING . COM . BR
Este documento é de propriedade de Clayton Lobato, com uso restrito para treinamentos ministrados
pelo Autor. Como parte do Projeto HowIHowTo, este material tem por objetivo introduzir conceitos
e comandos básicos.
Primeira impressão, Fevereiro 2016

Sumário
I Conceitos e comandos
1 Revisão de conceitos e comandos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.1 Estrutura de armazenamento (espaço e inodes) 7
1.2 Estrutura de permissões (stick-bit, set user id, set group id) 11
1.4 Empacotamento e compactação de arquivos (gz tgz) 24
1.5 Compilação e instalação de programas 26
1.6 Configuração do processo e inicialização dos daemons 30
1.7 Estrutura de logs 33
1.8 Definições de segurança da informação e tratamento no SO 40
2 Material Complementar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.1 Estrutura de Diretórios 44
2.2 RPM e DEB 55
2.3 Bootstraping 63
2.4 Control Centre: The systemd Linux init system 69
I
Conceitos e comandos
1 Revisão de conceitos e comandos . . . . . 7

1.1 Estrutura de armazenamento (espaço e inodes)
1.2 Estrutura de permissões (stick-bit, set user id, set group
id)
1.3 Estrutura de permissões (stick-bit, set user id, set group
id)
1.4 Empacotamento e compactação de arquivos (gz tgz)
1.5 Compilação e instalação de programas
1.6 Configuração do processo e inicialização dos daemons
1.7 Estrutura de logs
1.8 Definições de segurança da informação e tratamento
no SO
2 Material Complementar . . . . . . . . . . . . . . 43
2.1 Estrutura de Diretórios
2.2 RPM e DEB
2.3 Bootstraping
2.4 Control Centre: The systemd Linux init system
1. Revisão de conceitos e comandos
1.1 Estrutura de armazenamento (espaço e inodes)

Um dos principais aspectos para todo e qualquer sistema operacional, organizar os arquivos de
forma adequada é sempre uma tarefa árdua para a maioria dos administradores. A estrutura de
armazenamento pode tornar-se o grande vilão para a estabilidade e performance de todo sistema.
De uma forma geral, para os sistemas baseados no padrão POSIX, como é o caso do GNU/Linux,
as estrutura de diretórios funciona e organização dos arquivos no sistema acontece de forma bem
peculiar.
Para construir o entendimento necessário, faremos uma breve revisão de como o sistema lida
com arquivos e seus reflexos para o funcionamento do mesmo. Para o sistema Linux, Tudo no
GNU/Linux é arquivo. Sendo assim, fica claro a grande dependência do sistema em relação a como
estes arquivos estão ou não organizados.
Conforme demonstrado em detalhes no Capítulo. 2, a organização do GNU/Linux está toda
relacionada com o diretório / (root). Independente de qual volume esteja o arquivo, tudo está abaixo
desse diretórios. Sendo assim, uma observação com mais cautela deve ser adotada ao planejamento
dos diretórios e como estes podem estar relacionados aos aspectos de disponibilidade dos serviços
sustentados pelo sistema.
É comum encontrarmos em artigos, livros e demais literaturas que "...devemos separar os
diretórios no linux por uma questão de segurança...". Esta frase é uma das primeiras ditas em aulas
e palestas que tratam desse assunto. Senso comum, sempre relacionam a separação por questões da
disponibilidade do sistema pelo consumo do espaço existente em disco. Mas será que existe uma
outra razão ou outras razões para tal afirmativa?
Para responder à este questionamento, precisamos entender a relação entre os arquivos e sua
organização interna no file system.
Inodes é uma forma de representar um objeto no File System. O termo inode é uma contração
para INDEX NODE comumente usado na literatura sobre o sistema UNIX.- Maurice J. Bach, o
design do sistema operacional Unix, 1986. Dennis Ritchie , ao ser questionado respondeu na lista
de discussão do Kernel que "...Na verdade, eu não sei. Era apenas um termo que começamos a
usar. "Index"é meu melhor palpite, devido à estrutura um pouco incomum do sistema de arquivos
8 Capítulo 1. Revisão de conceitos e comandos
que armazenadas as informações de acesso aos arquivos como uma matriz simples no disco, com
todas as informações de diretório hierárquico, dentre ouras. Assim, o i-número é um índice nesta
matriz, o i-node é elemento selecionado da matriz. (A notação "i-"foi usada no manual 1a edição.)"
Sendo assim, podemos observar que os registros de INODE contém informações como:
a) O tamanho do arquivo em bytes;
b) ID do dispositivo (isso identifica o dispositivo que contém o arquivo);
c) O ID do usuário do proprietário do arquivo;
d) O ID do grupo do arquivo;
e) O modo de acesso do arquivo que determina o tipo de arquivo e como o dono do arquivo, seu
grupo, e outros podem acessá-lo;
f) Flags adicionais do sistema e do usuário para proteger ainda mais o arquivo (limitar o seu
uso e modificação);
g) Timestamps dizendo quando o próprio inode foi modificado pela última vez (ctime , o tempo
de modificação do inode), o conteúdo do arquivo da última modificação (mtime , tempo de
modificação) e do último acesso (atime,tempo de acesso);
h) A contagem da ligação dizendo quantos links físicos apontam para o inode;
i) Ponteiros para os blocos de disco que armazenam o conteúdo do arquivo.
Outra forma de observar o INODE e descrito em algumas literaturas de desenvolvimento do
File System é "a menor unidade de armazenamento dos arquivos no sistema. Cada um terá, por
padrão, cerca de 4K". Sendo assim, o INODE está ligado diretamente ao volume total do disco.
Vamos tentar comparar os sistema de armazenamento com um hotel. Sendo assim, podemos
determinar uma relação entre a capacidade total de hóspedes e o número de quartos existentes.
Complementar ao dito anteriormente, vamos relacionar a capacidade de alocação (número de
hóspedes) a regra geral se em um quarto já existir um hóspede, outro não poderá ocupar a mesma
acomodação.
Dessa maneira, fica fácil entendermos que existem duas formas de causar uma lotação no
hotel. A primeira é feita colocando em cada quarto, o número total de hóspedes ao mesmo tempo.
Assim, teríamos a lotação espacial do hotel. A segunda, é colocar em cada quarto, um hóspede
apenas.Dessa forma teríamos uma lotação por alocação.
Podemos então fazer uma analogia com os INODES ao estudo da volumetria e à capacidade de
funcionamento do sistema.
Mas o quê acontece quando a regra geral que havíamos comentado é aplicada e não alocamos
corretamente a capacidade de cada unidade ?
Se alocarmos um valor menor que 4K em cada INODE, dependendo da quantidade de arquivos
alocados, teremos a utilização total disponível. Mas qual a consequência para o sistema se isso
acontecer ?
Exercise 1.1 Execute o script abaixo e em seguida gere arquivos ocultos de 1K dentro do
diretório ocultos. Por fim, crie um usuário, de forma padrão. Qual o comportamento apresentado
pelo sistema e qual a sua causa ?
#! /bin/bash
echo 1 > arquivo
while read line; do
ls -lahR / » arquivo
done < arquivo

Conforme demonstrado na Fig. 1.1a, em um dado momento a execução do processo de separa-

ção do arquivo é interrompido e uma mensagem de erro é apresentada, Não há espaço disponível no
dispositivo.. Observe que a informação está relacionando à ausência de espaço e não de INODES.
1.1 Estrutura de armazenamento (espaço e inodes) 9
Figura 1.1: Resultado

Lembrem-se dos conceitos que apresentamos anteriormente e que, ao observarmos o comporta-

mento do sistema com tal conceito, a mensagem está correta. Alguns casos de indisponibilidade
em serviços ou do próprio sistema operacional podem estar relacionados aos INODES.
Na imagem 1.1b, ao lado direto, podemos observar o conflito dos conceitos. Ao usar o comando
para demonstrar o uso volumétrico do sistema, notamos que a informação apresentada é de 28%
para a unidade de armazenamento referente ao /home. Já com a utilização do comando para verificar
o uso dos INODES, podemos observar que a informação é de 100% de uso. Ou seja, apesar de
ainda termos espaço livre, não há mais possibilidade de alocação dos arquivos. Dessa forma,
ao tentarmos executar o comando adduser teste para criação de um novo usuário, a resposta é como
apresentada na terceira imagem da Fig. 1.1c.
1.2 Estrutura de permissões (stick-bit, set user id, set group id)
1.3 Estrutura de permissões (stick-bit, set user id, set group id)
Usuários, Grupos, Senhas e NPA.

Em sistemas como o GNU/Linux, entender os mecanismos de administração de usuários, senhas, grupos e
as relações entre usuários, grupos e arquivo é fundamental. Nada se faz no sistema sem um usuário e muito menos
se não soubermos como criar um ambiente onde muitos usuários podem interagir.
Por definição, cada usuário no sistema terá seu próprio ambiente onde poderá armazenar seus dados, o
que chamamos de diretório home, criado normalmente no /home, o qual leva o mesmo nome definido como o
login do usuário, além de possuir um grupo principal e um UID ( User ID – Identificador de usuário ). Mas isso não
é o bastante para um usuário interagir com o sistema. Além de todas as informações descritas acima, para que o
usuário possa interagir com o sistema é preciso que ao mesmo seja relacionado um shell, um interpretador de
comandos. No GNU/Linux temos várias possibilidades de shell, sendo o padrão o bash (Bourne-Again Shell).
Nas próximas páginas deste capítulo, veremos alguns comandos usados para administrar usuários, grupos
e senhas e mais adiante veremos ainda onde todas as informações ficam armazenadas e como podemos alterar o
comportamento padrão do sistema.
Para vermos a chamada do comando em execuções configuraremos o ambiente executando o comando
abaixo.
$set -x
Para desligar a exibição do comando, use o comando
$set +x
Podemos ainda usar o comando strace, este é realmente um comando interessante de ser usado para
conhecermos os detalhes de ação de cada comando do GNU/Linux.
1. useradd
Descrição: Cria usuário no sistema
Mapa 1 – Detalhamento de Opções do comando useradd
Exemplos:
#useradd clayton
#useradd -d /users/clayton clayton
#useradd -d -m /users/clayton clayton
#useradd -c “Clayton Lobato” clayton
2. userdel
Descrição: “Apaga” um usuário do sistema.
Mapa 2. – Detalhamento de Opções do comando userdel
Exemplos:
#userdel -f clayton
#userdel -r clayton #useradd clayton
3. passwd
Descrição: Define ou altera a senha de um usuário.
Mapa 3. – Detalhamento de Opções do comando passwd
Exemplos:
#passwd -x 5 clayton
#passwd -w 3 clayton
#passwd -n 4 clayton
#passwd -d clayton
4. chsh
Descrição: Altera o shell do usuário.
Mapa 4 – Detalhamento de Opções do comando chsh.

Exemplos:
#chsh -s /bin/sh clayton
#chsh -l
5. chage
Descrição: Muda informações de expiração de senha do usuário.
Mapa 5 – Detalhamento de Opções do comando chage.

Exemplos:
#chage -l clayton
#chage -M 20 clayton
#chage -m 10 clayton
6. usermod
Descrição: Altera informações da conta do usuário.
Mapa 6 – Detalhamento de Opções do comando usermod.

Exemplos:
#usermod -g desenvolv clayton
#usermod -c “Clayton Lobato” clayton
#usermod -l c1141478 -c “clayton lobato” clayton
#usermod -L clayton #usermod -U clayton
7. chfn
Descrição: Altera informações de identificação do usuário.
Mapa 7 – Detalhamento de Opções do comando chfn.

Exemplos:
#chfn -f “Clayton Lobato” clayton
8. groupadd
Descrição: Cria grupo no sistema
Mapa 8. – Detalhamento de Opções do comando groupadd.

Exemplos:
#groupadd layer
#groupadd -f layer
#groupadd -g 525 bases
#groupadd -r master
9. groupdel
Descrição: Apaga grupo no sistema Exemplos:
#groupdel layer
10. gpasswd
Descrição: Administra o arquivo /etc/group.
Mapa 10 – Detalhamento de Opções do comando gpasswd.

Exemplos:
#gpasswd -a clayton suporte #gpasswd -d clayton suporte
#gpasswd -M alice,eduardo suporte
Existe uma diferença enorme, muito mais em execução que conceitual das opções -M e -a.
11. groupmod
Descrição: Modifica informações de um grupo.
Tabela 11 – Detalhamento de Opções do comando groupmod.

Exemplos:
#groupmod -g 536 suporte #groupmod -n

suporte redes
12. chpasswd
Descrição: Atualiza a senha de usuários cadastrados no sistema a partir de um arquivo com o formato
usuário:senha.
Opções Descrição
-e Aguarda que as senhas sejam criptografadas.
Mapa 12 – Detalhamento de Opções do comando chpasswd.
13. id
Descrição: Exibe os ids dos usuários.
Mapa 13 – Detalhamento de Opções do comando id Exemplos:

#id -g clayton #id -u clayton
#id -n clayton
#id -G clayton
14. chgrp
Descrição: Define um novo grupo a um arquivo.
Mapa 14 – Detalhamento de Opções do comando chgrp Exemplos:

#chgrp root teste
#chgrp root:teste base_dados

#chgrp -hR root /base/postgres
15. finger
Descrição: Exibe informações de usuários.
Mapa 15 – Detalhamento de Opções do comando finger Exemplos:

#finger clayton
#finger -p clayton
#finger -m clayton
Para que um usuário seja válido no sistema, este precisa obrigatoriamente de um login, uid, gid, home,
shell e senha.
As senhas no GNU/Linux são definidas pelo comando passwd e armazenada em /etc/shadow. No arquivo
/etc/passwd, ao contrário do que se pensa, serão armazenadas apenas as informações da conta do usuário. Veja
na Figura 1.
Fig 1. – Informações da conta do usuário
Observe que temos 7 colunas divididas por : ( dois pontos ). Da esquerda para a direita, temos...
clayton login do usuário;
:x Indicação de senha;
:500 UID – User ID;
:500 gID – Group ID (nesse caso teremos o grupo principal do
usuário);
:Clayton Lobato Comment – Comentário, descrição do usuário;
:/home/clayton Diretório home do usuário;
:/bin/bash Shell do usuário.
Note que as senhas não estão presente no arquivo /etc/passwd. Para visualizarmos as senhas encriptadas,
exibiremos o arquivo /etc/shadow. Veja a figura 2.
Fig. 2. – Visualização de senhas encriptadas
Mas de onde saem todas essas informações ?

Existem alguns arquivos que são fundamentais para administração do sistema. Em se tratando de usuários,
vamos estudar os 4 que acho mais importante.
Começaremos pelo /etc/login.defs. Este é um dos primeiros a ser lido no processo de criação do usuário.
Nele, informações como controles de senhas, UID inicial e final e criação ou não do diretório home são
gerenciados. Veja algumas opções importantes desse arquivo.
Mapa 16 - Detalhamento do arquivo /etc/login.defs

Outro arquivo que devemos conhecer é o /etc/default/useradd. Vamos ao conteúdo deste...
Mapa 17 - Detalhamento do arquivo /etc/default/useradd
Fechando o conjunto de informações, para todo usuário criado, será criado um diretório home e nele
teremos os arquivos responsáveis pelo ambiente de interação dos usuários.
Durante o processo de criação do usuário foi dito que um grupo principal para o usuário foi criado. Mas...
Como funciona essa relação ?
Bem, no mundo GNU/Linux cada usuário, arquivo, processo tem relação com um grupo. Digite o comando
ls -l em sua console, veja o que aparece. . .
drwxr-xr-x 2 root root 4096 Jan 1 2000 bin
Para cada arquivo apresentado existe uma relação com um usuário e um grupo.
Para que se tenha acesso a um arquivo, é necessário ter permissão. Vamos entender essa relação analisando
umas das linhas exibidas acima.
drwxr-xr-x 2 root root 4096 Jan 1 2000 bin
d Indicação de que o arquivo é um diretório;

rwx Indica o nível de permissão de acesso do DONO do arquivo;
r-x Indica o nível de permissão de acesso do GRUPO do arquivo;
r-x Indica o nível de permissão de acesso para usuários que não se enquadram nos
parâmetros anteriores, ou seja, não é o dono e nem faz parte do grupo do arquivo; root Indica o usuário DONO
do arquivo; root Indica o GRUPO do arquivo;
4096 Tamanho do arquivo, em bytes.;
Jan 1 2000 14:01 Data e hora do ultimo acesso ao arquivo;
bin Nome do arquivo.
Mas onde ficam armazenadas as informações dos grupos, membros dos grupos e como gerenciar os grupos
no GNU/Linux ?
Vamos por partes!
O arquivo no qual as informações de grupos são armazenados é o /etc/group. Como acontece com os
usuários, os grupos também possuem uma senha, só que no caso dos grupos o uso é opcional. As senhas dos
grupos ficam armazenadas no arquivo /etc/gshadow.
Veja o conteúdo do arquivo /etc/group. Nele encontraremos informações dos grupos como o nome, group
id e membros. Para entendermos, vamos olhar o conteúdo do arquivo citado.
mailnull:x:47: smmsp:x:51:
rpcuser:x:29:
nfsnobody:x:65534:
apache:x:48: squid:x:23:
webalizer:x:67:
tomcat:x:91: xfs:x:43:
ntp:x:38: mysql:x:27:
screen:x:84:
postdrop:x:90:
postfix:x:89:
eduardo:x:501:
notifiles:x:502:
qmail:x:503:clayton
Observe o grupo eduardo. Nele temos a descrição do grupo e o gid do mesmo, neste caso o número 501.
Já o grupo qmail, possui um membro chamado clayton, este um usuário. Trocando em miúdos...
A estrutura base do arquivo /etc/group é grupo:x:gid:membros
Entendido como gerenciar usuários e grupos, o próximo passo será o gerenciamento de permissões de
acesso aos arquivos.
Tudo no GNU/Linux é um arquivo, e para cada arquivo definimos um nível de acesso, nível esse dividido em
leitura (read), escrita (write) e execução (execute), além das informações de dono e grupo. Alguns comandos são
usados para determinar um nível de permissão de acesso, o que chamo de NPA, além de determinar o dono e o
grupo do arquivo. Quando novos arquivos são criados no sistema, entra em ação o umask, o qual garante que que
determinados NPAs sejam usados como padrão, no processo de criação desses arquivos. No GNU/Linux teremos
dois padrões, 755 será usado como padrão para criação de diretórios e 644 para criação de arquivos.
Para alterarmos o valor do umask, usamos o seguinte mecanismo.
777 - 027 = 750 ( estes serão os níveis de permissão )
Detalhando a informação....
777 é o valor total permitido para os níveis de permissão de acesso. 027 será o decremento umask. O
resultado desse cálculo será o valor do NPA usado pelo sistema, nesse caso, 750 (Dono com permissão total, grupo
podendo ler e executar e outros sem nenhum tipo de acesso). Vejamos os comandos que nos permitem definir os
níveis de acesso, dono e grupo dos arquivos. Não usaremos os mapas aqui por conta da quantidade de informações
dos comandos.
16. chmod
Descrição: Gerencia os níveis de permissão de acesso dos arquivos.
-c Modo verbose, mostrando apenas as alterações feitas.
-R Aplica a recursividade na execução do comando.
u Usuário.
g Grupo.
o Outros.
a Todas as camadas.
Tabela 16 – Detalhamento de Opções do comando chmod

Modo Decimal Descrição
4 Leitura
2 Escrita
1 Execução
6 Leitura e Escrita
5 Leitura e Execução
3 Escrita e Execução
7 Leitura, Escrita e Execução
Tabela 16. – Comando chmod, níveis de permissão modo decimal

Modo Simbólico Descrição
r Leitura
w Escrita
x Execução
rw Leitura e Escrita
rx Leitura e Execução
wx Escrita e Execução
rwx Leitura, Escrita e Execução
Tabela 16 – Comando chmod, níveis de permissão modo simbólico

Modos Especiais Descrição
1 Stick Bit
2 Set group ID
4 Set User ID
Tabela 16 – Comando chmod, níveis de permissão modos especiais Exemplos:

#chmod 777 texto.txt
#chmod u+x texto.txt
#chmod u=rw,g-x texto.txt
#chmod 2777 texto.txt
17. chown
Descrição: Define dono e grupo do arquivo.
-c Modo verbose, mostrando apenas as alterações feitas.
-R Aplica a recursividade na execução do comando.
-f Não exibe mensagem caso haja erro na execução do comando.
--preserve-root Não aplica a recursividade no diretório /
-v Exibe detalhes da execução do comando. Modo verbose.

Tabela 17 – Detalhamento de Opções do comando chown Exemplos:
#chown root teste
#chown root:teste base_dados
#chown -R root /base/postgres
1.4 Empacotamento e compactação de arquivos (gz tgz)
tar
Descrição: Empacota arquivos em um arquivo tarball.
-A, --catenate, --concatenate Insere novo arquivo em um pacote.
-c, --create Cria um novo pacote.
-d, --diff, --compare Verifica diferenças entre arquivos.
-r, --append Insere arquivo ao final de um arquivo tarball.
-t, --list Lista o conteúdo de um arquivo tarball.
-u, --update Apenda arquivos que foram alterados e fazem

parte do pacote tarball.
-x, --extract, --get Extrai arquivos do um pacote tarball.
--delete Deleta um arquivo de um pacote tarball.
COMMON OPTIONS
-C, --directory DIR Muda o diretório.
-f, --file [HOSTNAME:]F Define o arquivo de saído do comando.
-j, --bzip2 Usa o bzip2 para compactar um arquivo tarball e o

bunzip2 para descompactá-lo.
-p, --preserve-permissions Preserva os níveis de permissão de acesso.
-v, --verbose Executa em modo verbose. Detalhes de execução

do sistema.
-z, --gzip, --ungzip Usa o gzip para compactar um arquivo tarball e o
gunzip para descompactá-lo.
ALL OPTIONS
--owner USER Define o usuário na extração do arquivo.
-p, --same-permissions, --preserve-permissions Mantém os níveis de acesso dos arquivos
Tabela 29 – Detalhamento de Opções do comando tar Exemplos:

#tar -xzf cadastro.tar.gz nomes.txt
gzip
Descrição: Comprime ou expande arquivos.
-d --decompress --uncompress Descompacta o arquivo.
-r --recursive Preserva a estrutura de diretório, usando a recursividade.

1.4 Empacotamento e compactação de arquivos (gz tgz) 25
-t --test Verifica a integridade do arquivo compactado.
-v –verbose Detalha a execução do comando
-# --fast –best Determina o nível de compressão. -1 ou - - fast executa com uma taxa de
compressão menor, determinando uma ação mais rápida do comando e -9 ou
- - best determina ação mais demorada, com taxa de compressão maior.
Tabela 30 – Detalhamento do comando gzip Exemplos:

#gzip -c teste > base.gz
Para descomprimir um arquivo gz, usamos o comando gunzip.
bzip2
Descrição: a block-sorting file compressor, v1.0.3.
-c --stdout Comprime e descomprime para saída padrão.
-d --decompress Força a descompressão de arquivos bz2.
-t --test Checa a integridade dos arquivos bz2.
-f --force Força a gravação de arquivos caso existam.

Normalmente, se um arquivo bz2 existir, não
poderá ser reescrito.
-1 (or --fast) to -9 (or --best) Determina a taxa de compressão para a execução
do comando. -1 ou - -fast com uma taxa de
compressão menor e ação mais rápida e -9 ou - -
best com ação mais lenta e taxa mais alta.
Tabela 31 – Detalhamento de Opções do comando crontab Exemplos:

#bzip2 base.tar
Para descomprimir um arquivo bz2, usamos o comando bunzip2.
1.5 Compilação e instalação de programas
Processo de compilação de programas.

Dentre todas as formas de instalação, a compilação é a que mais trás transtornos para grande parte dos
usuários do sistema. Pensando em facilitar o entendimento desse processo, seguiremos os passos demonstrados
abaixo.
Para compilarmos um programa, é necessário termos algumas ferramentas instaladas no GNU/Linux,
preparando assim o ambiente de trabalho. O primeiro passo para pensarmos em compilar um programa no
GNU/Linux é termos os fontes do kernel no diretório /usr/src. Feito isso, certifique-se que todos os tópicos da
listagem abaixo estejam cumpridos.
1. gcc
2. glibc
3. make 4. tar
5. bzip2
6. bunzip2
7. kernel-source
Após termos criado o ambiente necessário para a compilação, passamos então para o tratamento do
arquivo fonte. Aqui demonstraremos a instalação do SQUID com algumas particularidades.
Primeiro vamos desempacotar e descompactar o código fonte.
[root@clayton ~]# ls squid-2.6.STABLE3-20060916.tar.gz
squid-2.6.STABLE3-20060916.tar.gz
Observe o que o nosso pacote é do tipo tar.gz o que nos obriga a utilizar a linha de comando abaixo.
[root@clayton ~]# tar -zxvf squid-2.6.STABLE3-20060916.tar.gz
É importante observarmos esses detalhes para que não façamos confusão no hora de trabalhar. Existe a
possibilidade de termos códigos fonte do tipo tar.bz2, nesse caso usaríamos os parâmetros -jxvf junto ao comando
tar.
Após desempacotar e descompactar o arquivo fonte, precisamos compilar o programa. Veja abaixo:
[root@clayton]squid-2.6.STABLE3-20060916]#./configure --prefix=/usr --sysconfdir=/etc/squid --
libexecdir=/usr/lib/squid --infodir=/usr/share/info --mandir=/usr/share/man –enable-delay-pools -enable-useragent-
log --enable-cachemgr-hostname=clayton –enable-arp-acl --enable-default-errlanguage="Portuguese" --enable-
underscores --disable-htcp –disable-internal-dns --enable-cachedigests
checking for a BSD-compatible install... /usr/bin/install -c checking
whether build environment is sane... yes checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether to enable maintainer-specific portions of Makefiles... no checking for

gcc... gcc checking for C compiler default output file name... a.out checking whether the C
compiler works... yes checking whether we are cross compiling... no checking for suffix of
executables... checking for suffix of object files... o checking whether we are using the GNU
C compiler... yes checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking whether gcc and cc understand -c and -o together... yes
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking for pkg-config... /usr/bin/pkg-config
Store modules built: ufs
Removal policies built: lru
Delay pools enabled
User-Agent logging enabled
Cachemgr default hostname set to clayton
.
.
.
config.status: creating helpers/ntlm_auth/fakeauth/Makefile config.status: creating
helpers/ntlm_auth/mswin_sspi/Makefile10 config.status: creating
helpers/ntlm_auth/no_check/Makefile config.status: creating
helpers/ntlm_auth/SMB/Makefile config.status: creating
helpers/ntlm_auth/SMB/smbval/Makefile config.status: creating
helpers/negotiate_auth/Makefile config.status: creating
helpers/negotiate_auth/mswin_sspi/Makefile config.status: creating
helpers/external_acl/Makefile config.status: creating
helpers/external_acl/ip_user/Makefile config.status: creating
helpers/external_acl/ldap_group/Makefile config.status: creating
helpers/external_acl/mswin_lm_group/Makefile config.status: creating
helpers/external_acl/session/Makefile config.status: creating
helpers/external_acl/unix_group/Makefile config.status: creating
helpers/external_acl/wbinfo_group/Makefile config.status: creating tools/Makefile
config.status: creating include/autoconf.h config.status: executing depfiles
commands
[root@clayton squid-2.6.STABLE3-20060916]# make

Making all in lib make[1]: Entering directory `/root/squid-2.6.STABLE3-20060916/lib'
if gcc -DHAVE_CONFIG_H -I. -I. -I../include -I../include -I../include -Wall -g -O2 -MT
Array.o -MD -MP -MF ".deps/Array.Tpo" -c -o Array.o Array.c; \ then mv -f ".deps/Array.Tpo" ".deps/Array.Po";
else rm -f ".deps/Array.Tpo"; exit 1; fi if gcc -DHAVE_CONFIG_H -I. -I. -I../include -I../include -I../include -
Wall -g -O2 -MT
base64.o -MD -MP -MF ".deps/base64.Tpo" -c -o base64.o base64.c; \ then mv -f ".deps/base64.Tpo"
".deps/base64.Po"; else rm -f ".deps/base64.Tpo"; exit
1; fi if gcc -DHAVE_CONFIG_H -I. -I. -I../include -I../include -I../include -Wall -g -O2 -MT getfullhostname.o -MD -
MP -MF ".deps/getfullhostname.Tpo" -c -o getfullhostname.o getfullhostname.c; \ then mv -f
".deps/getfullhostname.Tpo" ".deps/getfullhostname.Po"; else rm -f
".deps/getfullhostname.Tpo"; exit 1; fi if gcc -DHAVE_CONFIG_H -I. -I. -I../include -I../include -I../include -Wall -g
-O2 -MT
hash.o -MD -MP -MF ".deps/hash.Tpo" -c -o hash.o hash.c; \ then mv -f ".deps/hash.Tpo" ".deps/hash.Po"; else
rm -f ".deps/hash.Tpo"; exit 1; fi if gcc -DHAVE_CONFIG_H -I. -I. -I../include -I../include -I../include -Wall -
g -O2 -MT
heap.o -MD -MP -MF ".deps/heap.Tpo" -c -o heap.o heap.c; \ then mv -f ".deps/heap.Tpo" ".deps/heap.Po"; else
rm -f ".deps/heap.Tpo"; exit 1; fi if gcc -DHAVE_CONFIG_H -I. -I. -I../include -I../include -I../include -Wall -
g -O2 -MT
html_quote.o -MD -MP -MF ".deps/html_quote.Tpo" -c -o html_quote.o html_quote.c; \ then mv -f
".deps/html_quote.Tpo" ".deps/html_quote.Po"; else rm -f
".deps/html_quote.Tpo"; exit 1; fi if gcc -DHAVE_CONFIG_H -I. -I. -I../include -I../include -I../include -Wall -g -O2
-MT
iso3307.o -MD -MP -MF ".deps/iso3307.Tpo" -c -o iso3307.o iso3307.c; \ then mv -f ".deps/iso3307.Tpo"
".deps/iso3307.Po"; else rm -f ".deps/iso3307.Tpo";
exit 1; fi if gcc -DHAVE_CONFIG_H -I. -I. -I../include -I../include -I../include -Wall -g -O2 -MT
md5.o -MD -MP -MF ".deps/md5.Tpo" -c -o md5.o md5.c; \
.
.
.
gcc -Wall -g -O2 -g -o cachemgr.cgi cachemgr__CGIEXT_-cachemgr.o -L../lib
-lmiscutil -lm -lbsd -lnsl make[2]: Leaving directory `/root/squid-2.6.STABLE3-
20060916/tools' make[1]: Leaving directory `/root/squid-2.6.STABLE3-
20060916/tools' make[1]: Entering directory `/root/squid-2.6.STABLE3-20060916'
make[1]: Nada a ser feito para àll-am'. make[1]: Leaving directory `/root/squid-
2.6.STABLE3-20060916'
[root@clayton squid-2.6.STABLE3-20060916]# make install

/usr/bin/install -c 'cachemgr.cgi' '/usr/lib/squid/cachemgr.cgi' /usr/bin/install -c -m

644 ./cachemgr.conf /etc/squid/cachemgr.conf make[3]: Leaving directory
`/root/squid-2.6.STABLE3-20060916/tools' make[2]: Leaving directory `/root/squid-
2.6.STABLE3-20060916/tools' make[1]: Leaving directory `/root/squid-2.6.STABLE3-
20060916/tools' make[1]: Entering directory `/root/squid-2.6.STABLE3-20060916'
make[2]: Entering directory `/root/squid-2.6.STABLE3-20060916' make[2]: Nada a ser
feito para ìnstall-exec-am'. make[2]: Nada a ser feito para ìnstall-data-am'.
make[2]: Leaving directory `/root/squid-2.6.STABLE3-20060916' make[1]: Leaving
directory `/root/squid-2.6.STABLE3-20060916'
[root@clayton squid-2.6.STABLE3-20060916]#
Caso todos os passos acima tenham sido executados com sucesso, parabéns, você acaba de compilar o
squid. Agora basta configurar o serviço e colocá-lo em ação!
Basicamente o processo de compilação se faz em três etapas. O ./configure, caso haja junto ao fonte, o
make e o make install. Nunca devemos esquecer das bibliotecas e requisitos necessários, a ausência delas te
tomará um bom tempo de trabalho e alguns erros.
Algo importante é lembrar da necessidade de informar ao ./configure o local onde serão colocados os
arquivos, caso contrário, será criada uma estrutura no /usr/local com o nome do pacote em uso. No caso de nosso
exemplo o squid.
1.6 Configuração do processo e inicialização dos daemons

TODOS OS PROCESSOS ESTÃO ABAIXO DO INIT!!!. Outra das frases mais ditas em cursos,
ela representa bem como os processos estão organizados e são interdependentes. Mas afinal, o que
são os processos, como eles são criados e quais relações com a inicialização do sistema ?
Durante o processo de boot do sistema, init é ativado dando início ao que chamo de explosão
dos processos filhos do init, ou seja, todo e qualquer processo startado no sistema. Esses processos
estão ligados diretamente ao nível de execução do sistema, o qual está referenciado no arquivo
/etc/inittab. É necessário entendermos algumas informações desse arquivo, então vamos a elas.
No processo de carga do init, o arquivo /etc/inittab será lido para que o sistema saiba qual nível
de execução padrão. Através do nível de execução, o sistema saberá quais serviços deverão ser
carregados sempre que a máquina for ligada. Em um sistema padrão, temos 7 níveis de execução
para o Linux, indo do nível 0 ao nível 6, cada um com uma característica, conforme Fig. 1.2. Para
Figura 1.2: Níveis de Execução
determinarmos o nível padrão de execução, edite a linha id:NE:initdefault:, onde NE é o nível de

execução do sistema. Por exemplo, id:3:initdefault: determina que o nível de execução será o nível
3.
Para cada nível de execução existirá um diretório /etc/rc.d/rcNE.d, onde encontraremos os
scripts de start e stop dos serviços relacionados com este nível. Os arquivos estão descritos de duas
formas S45autofs e K85autofs, vamos entendê-los.
O S indica que o serviço relacionado ao arquivo será inicializado durante o start do nível, o
número 45 indica a ordem de prioridade desse serviço em relação aos outros que também serão
carregados o nome é apenas uma descrição, aqui colocamos o nome de serviço para facilitar a
identificação do mesmo. No outro arquivo teremos o K indicando que o serviço será “morto”,
desligado, o número como no primeiro caso indica a ordem em relação aos outros serviços que
serão mortos e o nome. Para cada nível existirá um conjunto de aplicações que serão mortos e
outras que serão carregadas. Para saber mais sobre esses serviços, veja o conteúdo dos diretórios
/etc/rc.d/rcNE.d.
Isso ainda é um padrão e ainda é usado como conceito para todos os sistemas. Porém, con-
forme demonstrados na Fig. 1.3, em algumas distribuições do GNU/Linux, está sendo usado o
systemd como gatilho principal de carga dos processos. Mas qual o motivo de tal mudança ? Ao
contrário do que acontecia com o Sysvinit, que era um processo seriado, justificado pelas caracte-
rísticas do processadores daquela época, o SYSTEMD explora as características dos processadores
1.6 Configuração do processo e inicialização dos daemons 31
Figura 1.3: Árvore de processos do Systemd
multinucleados.
Em http://www.diolinux.com.br/2014/02/a-diferenca-entre-systemd-e-upstart.
html#sthash.mXaeIrZk.dpuf, o autor descreve que "o Systemd abandona o uso de scripts
para a inicialização mesmo que possa chamar scripts para iniciar serviços e tenta retirar dos
scripts a "inteligência"de verificação de dependências, transferindo-a para outras instâncias, como
o barramento D-Bus, o autofs e os sockets de rede. O paralelismo, portanto, alcança seu maior
grau possível, muitas vezes deixando a cargo de subsistemas do kernel o encaminhamento de sinais
que farão cada serviço ser iniciado.O systemd lança mão do recurso de cgroups para catalogar
de forma automática e inescapável os PIDs dos processos iniciados por cada serviço, e assim
consegue garantir que, ao parar determinado serviço, todos os processos que tenham sido iniciados
por ele sejam terminados."
Em https://www.freedesktop.org/wiki/Software/systemd/, o systemd é
descrito como "um conjunto de blocos de construção básicos para um sistema Linux. Ele fornece
um gerente de sistema e serviço que é executado como PID 1 e começa o resto do sistema. systemd
fornece capacidades de paralelização agressivos, usa soquete e ativação de D-Bus para os serviços
de partida, oferece partida sob demanda de daemons, mantém o controle de processos usando
grupos de controle, suporta snapshotting e restauração do estado do sistema, mantém pontos
e implementos de montagem e automount uma lógica baseada em dependência transacional
elaborada controle de serviço. systemd suporta SysV e LSB scripts de inicialização e funciona
como um substituto para sysvinit. Outras partes incluem um daemon de registro, utilitários para
controlar a configuração básica do sistema, como o nome da máquina, data, local, mantém uma
lista de usuários conectados e recipientes em execução e máquinas virtuais, contas do sistema,
diretórios de tempo de execução e definições, e daemons para gerenciar rede simples configuração,
sincronização de tempo de rede, encaminhamento e resolução de nomes de log."
De forma geral, o systemd cria containers de administração dos daemons. Dessa forma,
podemos observar bem o conceito aplicado quando exibimos o status de execução do sytemd, o
qual apresentará a cadeia de processos em execução através de uma árvore. Observe topo da árvore,
qual o primeiro processo apresentado ?
Veja na lista apresentada no Cap. 2 - página 60, o init é o primeiro processo e continua sendo o
pai de todos os demais processos. Fica claro também o uso dos containers para carga dos demais
processos.
Sendo assim, o uso do systemctl torna-se de extrema importância para administração do

sistema. Dessa forma, segue abaixo um conjunto de possibilidade de uso do systemctl com os quais
a administração dos daemons poderá ser feito.
$systemctl status Para verificar o status

$systemctl Para listar o units que estão em execução
$systemctl list-units Para listar o units que estão em execução
$systemctl –failed Para listar os units que falharam
$systemctl list-unit-files Os arquivos de units em /usr/lib/systemd/system/
e /etc/systemd/system/, sendo este prioritário
#systemctl start unit Inicia uma unit imediatamente
#systemctl stop unit Para um unit imediatamente
#systemctl restart unit Reinicia um unit
#systemctl reload unit Faz um reload no arquivo de configuração
$ystemctl status unit Exibir o status de um unit, incluindo
se ele está sendo executado ou não
$systemctl is-enabled unit Verifica se o unit está habilitada ou não
#systemctl enable unit Habitia um unit para iniciar no bootstrap
#systemctl disable unit Desabilita um unit para iniciar no bootstrap
#systemctl mask unit Mascara um unit tornando possível iniciá-lo
#systemctl unmask unit Desmascara um unit
$systemctl help unit Exibe a manpage do unit
#systemctl daemon-reload Executa Reload no systemd procurando
por novas units ou mudanças em unit
$systemctl reboot Reinicia o sistema operacional
$systemctl poweroff Desliga o sistema operacional
$ systemctl suspend Suspende o sistema operacional
Entendidos as sintaxes iniciais para o uso do systemctl, entender como escrever os arquivos
units será o próximo passo. A sintaxe de arquivos unit do Systemd é inspirada por arquivos XDG
Desktop Entry Specification .desktop, que são por sua vez inspirado por arquivos do Microsoft
Windows ini. Os arquivos unit são carregados a partir de dois locais, sendo, de menor para o maior
/usr/lib/systemd/system/ : unidades fornecidas pelos pacotes instalados e /etc/systemd/system/ :
unidades instaladas pelo administrador do sistema. Abaxio temos um exemplo de arquivo de
configuração.
[Unit]
Description=MyApp
After=docker.service
Requires=docker.service
[Service]
TimeoutStartSec=0
ExecStartPre=-/usr/bin/docker kill busybox1
ExecStartPre=-/usr/bin/docker rm busybox1
ExecStartPre=/usr/bin/docker pull busybox
ExecStart=/usr/bin/docker run --name busybox1 busybox /bin/sh -c "while
true; do echo Hello World; sleep 1; done"
[Install]
WantedBy=multi-user.target
Agora podemos ver como é o arquivo service do rsyslog.

[Unit]
Description=System Logging Service
#After=docker.service
Requires=syslog.socket
Documentation=man:rsyslogd(8)
Documentation=http://rsyslog.com/doc/
[Service]
Type=notify
#TimeoutStartSec=0
#ExecStartPre=-/usr/bin/docker kill busybox1
#ExecStartPre=-/usr/bin/docker rm busybox1
#ExecStartPre=/usr/bin/docker pull busybox
ExecStart=/usr/sbin/rsyslogd -n
StandardOutput=null
Restart=on-failure
[Install]
WantedBy=multi-user.target
Alias=syslog.service
1.7 Estrutura de logs

Aspecto de extrema importância para qualquer processo de administração, os logs podem ser
melhores e piores amigos dos administradores.
O sistema GNU/Linux, existem várias formas de tratar logs, desde o mais comum o qual tratará
basicamente do comportamento de inicialização, logins e demais serviços correlatos, aos mais
complexos que trazem uma série de informações as quais podem tornar a interação um fardo.
Por definição, os logs possuem um local específico no sistema. O diretório /var/log é o
repositório onde a maioria (não falarei todos pq uma ou outra aplicação pode não guardar os logs
nele) dos aplicativos, incluindo kernel gravam seus registros. Dessa forma, devemos então atentar
para tais registros quando formos fazer as instalações dos aplicativos.
Conforme demonstrado abaixo, uma gama de aplicativos estão disponíveis.No Debian, distribui-
ção que usaremos nesse curso, o sistema padrão usado é o THE ROCKET-FAST SYSTEM FOR
LOG PROCESSING - RSYSLOG, sendo assim, vamos conhecer um pouco de seu funcionamento
e de como podemos usá-lo.
Programa Descrição
logwatch Analisador de log com saída bonita escrito em Perl
analog Analisador de log do servidor web
awstats Analisador de logs de servidor web poderoso e cheio de funcionalidades
sarg Gerador de relatórios de análises do squid
pflogsumm Resumidor de entradas do relatório do Postfix
squidview monitoriza e analisa ficheiros access.log do squid
rsyslogd considerados por muitos como servidor de alta performance para tratamento de logs
O primeiro passo é entender como o serviço funciona, objetivando a facilidade para o processo
de gerenciamento do mesmo. Existem várias formas de se instalar o pacote do rsyslog e apesar de
já estar instalado por padrão no na versão adotada para este treinamento, vamos fazer uma breve
revisão para instalação do mesmo. Para isso adotaremos observaremos a documentação oficial do
projeto. Sendo assim, primeiro passo devemos instalar os pacotes de dependência e para isso, baixe
os arquivos abaixo.
Libestr: http://libestr.adiscon.com/download/
Libee: http://www.libee.org/download/
Rsyslog: http://http://www.rsyslog.com/download/
Configure os pacotes para instalação correta. Use o configure com os parâmetros –libdir=/usr/lib
–includedir=/usr/include. Após a configuração do pacote a instalação segue conforme demonstrado
no Item ?? Compilação e instalação de programas.
Assim como foi feito para os demais pacotes, apresentados anteriormente, precisamos configurar
o MAKEFILE. Para o RSYSLOG, vamos definir o prefixo usado para a instalação com o /usr;
Dessa maneira, teremos –prefix=/usr. As próximas etapas siga a instalação normal pelo processo
de compilação.
O arquivo de configuração padrão do serviço é o rsyslog.conf. Auxiliar a este arquivo, te-
remos o diretório rsyslog.d, o qual será chamado para complementação da configuração. Ao
analisarmos o arquivo de log, apresentado abaixo, as primeiras linhas configuram as instâncias de
módulos.
# /etc/rsyslog.conf Configuration file for rsyslog.

#
# For more information see
# /usr/share/doc/rsyslog-doc/html/rsyslog_conf.html
#################
#### MODULES ####
#################
$ModLoad imuxsock # provides support for local system logging

$ModLoad imklog # provides kernel logging support
#$ModLoad immark # provides --MARK-- message capability
# provides UDP syslog reception

#$ModLoad imudp
#$UDPServerRun 514
# provides TCP syslog reception

#$ModLoad imtcp
#$InputTCPServerRun 514
###########################
#### GLOBAL DIRECTIVES ####
###########################
#
# Use traditional timestamp format.
# To enable high precision timestamps, comment out the following line.
#
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat
#
# Set the default permissions for all log files.
#
$FileOwner root
$FileGroup adm
$FileCreateMode 0640
$DirCreateMode 0755
$Umask 0022
#
# Where to place spool and state files
#
$WorkDirectory /var/spool/rsyslog
#
# Include all config files in /etc/rsyslog.d/
#
$IncludeConfig /etc/rsyslog.d/*.conf
###############
#### RULES ####
###############
#
# First some standard log files. Log by facility.
#
auth,authpriv.* /var/log/auth.log
*.*;auth,authpriv.none -/var/log/syslog
#cron.* /var/log/cron.log
daemon.* -/var/log/daemon.log
kern.* -/var/log/kern.log
lpr.* -/var/log/lpr.log
mail.* -/var/log/mail.log
user.* -/var/log/user.log
#
# Logging for the mail system. Split it up so that
# it is easy to write scripts to parse these files.
#
mail.info -/var/log/mail.info
mail.warn -/var/log/mail.warn
mail.err /var/log/mail.err
#
# Logging for INN news system.
#
news.crit /var/log/news/news.crit
news.err /var/log/news/news.err
news.notice -/var/log/news/news.notice
#
# Some "catch-all" log files.
#
*.=debug;\
auth,authpriv.none;\
news.none;mail.none -/var/log/debug
*.=info;*.=notice;*.=warn;\
auth,authpriv.none;\
cron,daemon.none;\
mail,news.none -/var/log/messages
#
# Emergencies are sent to everybody logged in.
#
*.emerg :omusrmsg:*
#
# I like to have messages displayed on the console, but only on a virtual
# console I usually leave idle.
#
#daemon,mail.*;\
# news.=crit;news.=err;news.=notice;\
# *.=debug;*.=info;\
# *.=notice;*.=warn /dev/tty8
# The named pipe /dev/xconsole is for the `xconsole' utility. To use it,
# you must invoke `xconsole' with the `-file' option:
#
# $ xconsole -file /dev/xconsole [...]
#
# NOTE: adjust the list below, or you'll go crazy if you have a reasonably
# busy site..
#
daemon.*;mail.*;\
news.err;\
*.=debug;*.=info;\
*.=notice;*.=warn |/dev/xconsole
O arquivo está configurado para uso suportar o sistema local, para suporte ao kernel. Observe
que os módulos imudp e imtcp estão desabilitados, assim como as referências de portas usadas
para conexão, o caso InputTCPServerRun 514.
Estas duas linhas descrevem qual protocolo e porta será usado pelo servidor para receber os
logs dos clientes. Dessa forma, podemos habilitar uma das opções para que as conexões sejam
possíveis. Normalmente, os servidores estarão usando o protocolo tcp.
Depois dessa configuração, os diretórios e arquivos são criado, seus níveis de permissão e a
definição do diretório padrão do sistema.
$IncludeConfig /etc/rsyslog.d/*.conf inclui o diretório complementar e todos os arquivos nele
contidos. Resumidamente podemos então definir os parâmetros de configuração da seguinte forma:
Facilidades
auth : Mensagens de segurança/autorização
authpriv : Mensagens de segurança/autorização (privativas)
cron : Serviços de agendamento (cron e at)
daemon : Outros serviços do sistema que não possuem facilidades
ftp : Serviço de ftp do sistema
kern : Mensagens do kernel
lpr : Subsistema de impressão
local0-7 : Reservados para uso local
mail : Subsistema de e-mail
news : Subsistema de notícias da USENET
security : Sinônimo para a facilidade auth
rsyslog : Mensagens internas geradas pelo syslog
user : Mensagens genéricas de nível do usuário
uucp : Subsistema de UUCP
*: Confere com todas as facilidades
De forma complementar, há ainda a parametrização dos níveis, sendo eles:
Níveis
emerg : O sistema está inutilizável
alert : Uma ação deve ser tomada imediatamente para resolver o problema
crit : Condições críticas
err : Condições de erro
warning : Condições de alerta
notice : Condição normal, mas significante
info : Mensagens informativas
debug : Mensagens de depuração
*: Confere com todos os níveis
none : Nenhuma prioridade
error : Sinônimo para o nível err
panic : Sinônimo para o nível emerg
warn : Sinônimo para o nível warning
Há duas formas básicas de armazenamento dos logs. A primeira, registrar tudo em arquivos
dentro do diretório /va/log e a segunda gravar em bancos de dados. Como trataremos da primeira
opção, é importante que possamos entender o mecanismo de logrotate.
=========================================logrotate.conf
# see "man logrotate" for details

# rotate log files weekly # no packages own wtmp, or btmp -- we'll rotate
weekly them here
/var/log/wtmp {
# keep 4 weeks worth of backlogs missingok
rotate 4 monthly
create 0664 root utmp
# create new (empty) log files after rotating old rotate 1
ones }
create
/var/log/btmp {
# uncomment this if you want your log files missingok
compressed monthly
#compress create 0660 root utmp
rotate 1
# packages drop log rotation information into this }
directory
include /etc/logrotate.d # system-specific logs may be configured here
=========================================logrotate.d/rsyslog
/var/log/syslog /var/log/auth.log
{ /var/log/user.log
rotate 7 /var/log/lpr.log
daily /var/log/cron.log
missingok /var/log/debug
notifempty /var/log/messages
delaycompress {
compress rotate 4
postrotate weekly
invoke-rc.d rsyslog rotate > missingok
/dev/null notifempty
endscript compress
} delaycompress
sharedscripts
/var/log/mail.info postrotate
/var/log/mail.warn invoke-rc.d rsyslog rotate >
/var/log/mail.err /dev/null
/var/log/mail.log endscript
/var/log/daemon.log }
/var/log/kern.log
De forma bem direta, esta é a configuração que trata da volaticidade dos arquivos de log. Nela
é possível definir quanto tempo os arquivos serão mantidos.
1.8 Definições de segurança da informação e tratamento no SO

Vários aspectos de segurança são tratados em diversos livros e manuais. É uma grande quantidade
de possibilidades que podem ser tratados quando o assunto é segurança, porém, nesse capítulo
trataremos de alguns aspectos pouco convencionais.
O primeiro ponto é um conceito que aplico em diversos servidores que administro... Vamos
pensar em firewall como um mecanismo de fortalecimento do sistema e não simplesmente como
uma ferramenta ou conjunto de ferramentas. Dessa forma, iniciaremos com o tratamento da tabela
de roteamento e nos aspectos funcionais do arp e na comunicação de dados.
O comando route é um dos mais conhecidos por administradores de sistema. Através dele
é possível configurar rotas de comunicação, sem as quais será impossível prover a comunicação
entre dispositivos. Porém, uma das características mais interessantes (ao menos pra mim), é a
possibilidade de bloquear rotas de comunicação, impedindo que certas origens se comuniquem com
o servidor. Da mesma forma que a tabela de roteamento pode auxiliar no tratamento de segurança
do sistema, a tabela arp pode ser um grande auxílio na hora de se pensar em segurança.
Exercise 1.2 Juntem-se em duplas e crie redes distintas paca cada uma das duplas. Em seguida,
crie rotas que proporcione a comunicação entre as máquinas. Usando dos conceitos do protocolo
ARP, execute a restrição de acesso de um determinado ip.
Em seguida, crie uma rota restritiva para uma das redes existentes na sala. Debata o motivo
e quais as consequências, vantagens e desvantagens das ações executadas.
Outro aspecto muito comentado sobre segurança em sistema operacional GNU/Linux é o uso
do SUDO. A grande parte das distribuições possuem o SUDO instalado nativamente. Porém, nem
todas estão com o serviço está habilitado. Mas qual o motivo de usar o SUDO ?
Usamos para que um usuário comum possa ter privilégio de outros usuários. Interessante não ?
Pode ser que sim, mas há grandes chances de haver problemas. Por usarmos a senha do usuário
corrente para escalonar os privilégios. Então, se estiver logado com o usuário scooby e quiser
escalonar privilégio para root, basta que seja executado o comando sudo su. Pronto, privilégio
escalonado. Não há muito o que ser feito, já que poucos administradores possuem conhecimento
e mesmo disposição para configurar um bom arquivo sudoers. Vamos focar então em algumas
possibilidades para contornar essa situação e fortalecer (hardenizar) o sistema.
Dentre várias possibilidades existentes, tenho observado o desenvolvimento e o amadurecimento
do GRSECURITY.
Grsecurity R é uma extensa melhoria de segurança para o kernel do Linux que o defende
contra uma ampla gama de ameaças de segurança através de controle de acesso inteligente, previne
contra explorações baseadas em corrupção de memória, e uma série de outros mecanismos de
hardening do sistema que geralmente não requerem nenhuma configuração. Pouco pretensioso em
falar mas, segundo o site oficial do projeto, "Apenas grsecurity fornece proteção contra zero-day e
outras ameaças avançadas que toma um tempo valioso dos administradores enquanto correções
de vulnerabilidade fazem o seu caminho para fora em distribuições e testes de produção. Isto é
possível por nosso foco na eliminação de classes de bugs inteiros e explorar vetores, em vez de a
eliminação de status-quo das vulnerabilidades individuais.". Trocando em miúdos, grsecurity é um
conjunto de correções para o kernel do Linux , com ênfase ao reforço da segurança. Sua aplicação
típica é em servidores e sistemas que aceitam conexões remotas de locais não confiáveis, tais como
sistemas que oferecem web acesso shell para seus usuários.
Um ponto interessante do grsecurity é que ele fornece um completo controle de acesso baseado
1.8 Definições de segurança da informação e tratamento no SO 41
em função do sistema (RBAC). RBAC se destina a restringir o acesso ao sistema além do que
normalmente é fornecido pelo listas de controle de acesso do Unix, com o objetivo de criar um
sistema totalmente com menos privilégios, onde os usuários e processos têm os privilégios mínimos
absolutos para trabalhar corretamente e nada mais. Desta forma, se o sistema for comprometida,
a capacidade de o intruso danificar ou o ganho de informação sensível sobre o sistema pode ser
drasticamente reduzida. RBAC funciona através de uma coleção de "regras". Cada regra pode ter
restrições individuais sobre o que pode ou não pode fazer, e essas regras e restrições formam uma
"política"que pode ser alterado conforme necessário.
Outro ponto é o tratamento do chroot. O grsecurity restringe chroot em uma variedade de
maneiras de prevenir uma variedade de vulnerabilidades, ataques de elevação de privilégios, e para
adicionar checagens adicionais. Dentre as modificações, podemos citar o não anexar memória
compartilhada fora do chroot e a negação do ptrace fora do chroot (independente de arquitetura).
Além disso, também reforçada a auditoria para o kernel Linux. Ele pode ser configurado para
auditar um grupo específico de usuários, auditoria montagens e desmontagens de dispositivos,
muda a hora e a data do sistema, chdir logging, entre outras coisas. Algumas dessas outras coisas
permite que o administrador também registre tentativas de recurso negadas, tentativas falhas de
fork e exec login com argumentos. Falando um pouco de fork, algo pouco conhecido pela maioria
dos administradores do sistema, faça o exercício abaixo e vamos debater um pouco.
Exercise 1.3 Execute a linha abaixo e debata sobre o resultado.
$ :(){ :|:& };:
Caminho confiável de execução é outra característica opcional que pode ser usado para impedir
que os usuários executam binários que não são de propriedade da raiz do usuário, ou que são
graváveis. Isso é útil para evitar que os usuários executem seus próprios binários maliciosos ou
acidentalmente executar binários do sistema que poderiam ter sido modificados por um utilizador
mal intencionado (sendo graváveis). Outro ponto é o hardening do caminho chroot trabalhando
com prisões. A jaula pode ser utilizada para isolar um processo em particular a partir do resto do
sistema, podendo minimizar o dano potencial para o serviço comprometido. No entanto, existem
maneiras de "romper"uma jaula. Dessa forma, grsecurity tenta evitar isso.
Caminho confiável ou canal confiável - é um mecanismo que fornece confiança de que o usuário
está se comunicando com o que destina-se a comunicar, garantindo que os atacantes não podem
interceptar ou modificar qualquer informação que está sendo comunicado.
Há também outros recursos que aumentam a segurança e impedem que os usuários adquiram
conhecimentos desnecessária sobre o sistema, como restringir os comandos dmesg e netstat para o
usuário root. Por fim, podemos listar alguns recursos adicionais, sendo:
a) Restrilções ao /proc para previnir vazamento de informações sobre proprietários de processos
b) Restrições aos links simbólicos e hardlink do / para prevenir execuções no /tmp
c) Restrições à hardlink para impedir que usuários acessem aos links físicos para arquivos que
não possuem
d) Restrições para nomeado ao FIFO / pipe
e) Restrições ao dmesg
f) Implementação aprimorada de Execução Caminho Confiável
g) Restrições de soquete com base em grupos
Para demonstrar um pouco de como as regras são criadas, veja o exemplo abaixo.
define objset1 {
/root/blah rw
/root/blah2 r
/root/blah3 x
define somename2 {
/root/test1 rw
/root/blah2 rw
/root/test3 h
}
Por fim, para que possamos entender o que está escrito acima, seguem as flags que podem ser
usadas para criação das políticas do grsecurity.
a: Este objeto pode ser aberto para acrescentar

c: Permitir a criação do arquivo /diretório
d: Permitir exclusão do arquivo /diretório
f: Necessária para marcar o PIPE utilizado para comunicação com init na transferência do
privilégio na persistência de regras; só é válida dentro de uma ação persistente e a
transferência só ocorre quando o arquivo é aberto para escrita
h: Este objeto está escondido
i: Este modo só se aplica aos binários. Quando o objeto é executado, ele herda a ACL
em que foi definido.
l: Permitir que um hardlink neste caminho. Links físicos requer um mínimo de modos C e L, e o link
de destino não pode ter qualquer permissão maior do que o arquivo de origem.
m: Permite a criação de setuid / setgid arquivos e /diretórios e modificação dos
arquivos /diretórios para ser setuid / setgid.
p: Rejeita todos os ptraces a este objeto
r: Este objeto pode ser aberto para leitura
t: Este objeto pode ser ptraced, mas não pode modificar a tarefa em execução.
Isto é referido como um "read-only ptrace"
w: Este objeto pode ser aberto para gravação ou anexar
x: Este objeto pode ser executado
=========================================================
u: Esta é uma regra para usuário. Ela deverá ter o nome de um usuário do sistema
g: Esta é uma regra para grupos. Ela deverá ter o nome de um grupo do sistema
s: Esta é uma regra especial. Ela não pertence a um usuário ou grupo e não requer uma
base de segurança imposta para ser usada em um conjunto de regras
A: Esta é uma base administrativa. Ela possui privilégio especial que as demais regras não tem
e ignora as restrições PTRACE e carregamento de bibliotecas adicionais
G: Esta regra é usada com o gradm para autenticar no kernel. A política gradm será automaticamente
adicionada à função
N: Usado pelo gradm não requer autenticação. Use o gradm -n
P: Regra que usa módulos de autenticação com o PAM
T: Habilita o TPE (Truste Execution Path)
R: Basicamente usada para encerrar os processos quando uma sessão de shell for encerrada.
Usada para desligamento do sistema.
—————————————————————————————-
2. Material Complementar
44 Capítulo 2. Material Complementar
2.1 Estrutura de Diretórios

21
Capítulo 2 - Dispositivos de
armazenamento e estrutura de diretórios.
Antes de pensarmos em fazer qualquer tipo de interação junto ao sistema,
precisamos nos localizar. Duas informações são imprescindíveis:
1. Onde ficam armazenados os arquivos do sistema e para que serve cada
diretório do sistema;
2. Como podemos usar os dispositivos de armazenamento.
É muito comum que já se comece um material sobre sistema, instalando o mesmo.
Porém, vamos primeiro abordar a organização dos dados e dispositivos de
armazenamentos, haja vista que para instalarmos precisamos saber onde e como colocar
as informações no sistema.
Analisando de outra forma, como poderemos projetar nosso sistema para que os
serviços nele instalado sejam estáveis e confiáveis se não soubermos onde e como
organizar os arquivos ?
Imagine instalar um servidor DHCP, um servidor SAMBA e uma estação de
trabalho. Você seria capaz de descrever como seria organizado o sistema para que todas
as instalações fossem bem sucedidas ?
Não podemos pensar em ter a mesma organização para os três exemplos citados
anteriormente, haja visto que cada perfil terá características próprias.
Em grande parte dos materiais, encontraremos descrito que precisamos apenas de
duas partições para instalarmos o sistema. Uma seria descrita como swap e outra como /.
Não deixa de ser verdade. Para instalações menos criteriosas termos apenas duas
partições bastam. Mas se pensarmos em sistemas de produção, realmente teremos
problemas com essa estrutura.
Para cada instalação, o que determinará toda a estrutura do sistema será o conjunto
de aplicações que serão instalados. Não podemos pensar, por exemplo, em estruturas
iguais para uma instalação voltada de uma estação de trabalho e uma máquina que
iremos usar como servidor SAMBA. Cada perfil irá requerer uma organização própria dos
dispositivos de armazenamento.
Nesse capítulo, abordaremos aspectos relacionados a estrutura de diretórios,
organização dos dispositivos de armazenamento, suas limitações e como projetar a
instalação do GNU/Linux.
Então.. café e uma boa poltrona e bom estudo...
Guia Linux Professional – Clayton Lobato

2.1 Estrutura
22 de Diretórios 45

23
Estrutura de diretórios.
Algo que intriga a muitos iniciantes no GNU/Linux é a organização dos arquivos. O
fato de todo e qualquer arquivo estar submetido a um único ponto, o diretório /
(root), torna o entendimento da organização de arquivos um tanto confusa para muitos.
Em primeiro lugar, não devemos confundir o diretório / (root) com o diretório do usuário
root, o qual está localizado em /root (observe que ele é um sub-diretório do
diretório principal /), é comum esse tipo de confusão.
Outro detalhe que devemos observar aqui, é que cada diretório do sistema
GNU/Linux tem um papel específico. Conhecer a função de cada diretório é fundamental
para as tarefas administrativas.
É comum ouvirmos iniciantes reclamando que não sabem para onde foram as
aplicações instaladas no sistema e perderem um bom tempo para achar e identificar qual
o arquivo deverá ser usado. O primeiro passo para se ter uma vida mais tranqüila
no sistema é conhecer a estrutura a estrutura de diretórios. Dado o primeiro
passo, os outros serão bem mais simples.
Vamos ver um pouco da organização dos diretórios, veja o Mapa 3.1
Mapa 3.1 – Detalhamento da estrutura de diretórios.

2.1 Estrutura
Outro fato que chama a atenção e provoca sérios transtornos de entendimento para
novos administradores é a ausência de estruturas independentes de diretórios. Todos os
discos estarão “montados” em um diretório, abaixo do /. Em sistemas como o Windows,
cada partição terá uma estrutura de diretórios própria e será apresentada de forma
independente. No GNU/Linux isso não acontece.
Estudo dos dispositivos de armazenamento

Nas páginas anteriores vimos que toda a estrutura de arquivos do sistema estaria
submetida ao diretório /, o que nos faz crer que todo e qualquer dispositivo de
armazenamento estará ligado a um ponto, um sub-diretório do /, chamado de ponto de
montagem.
No GNU/Linux, todas as informações contidas em dispositivos de armazenamento
serão dispostas em diretórios. Esse processo é descrito como montagem de
dispositivos, ou seja, dispor das informações de um volume em um sub-diretório do /,
para que o usuário possa ter acesso. Todo o processo será detalhado mais adianta quando
estudarmos o comando mount e o arquivo /etc/fstab.
Mas uma pergunta permanece... Como posso organizar meus dispositivos de
armazenamento, quais suas limitações e como serão identificados no GNU/Linux ?
Encontraremos uma forma muito peculiar de identificação dos discos rígidos. Cada
dispositivo terá um nome próprio de acordo com a “porta” à qual está instalada. Em um
padrão IDE, todos os discos estarão identificados pelo prefixo hd, seguido do endereço da
porta (a, b, c , d) e o número da partição. Em discos SATA e SCSI teremos a identificação
com o prefixo sd. Trocando em miúdos...
Se um disco estiver conectado a uma porta IDE 0, sendo o mesmo um primeiro
master, teremos o disco identificado como hda. Se este mesmo disco for dividido em 4
partições, teremos então hda1, hda2, hda3, hda4. Se tivermos a mesma configuração
em um disco SCSI ou SATA, teremos sda1, sda2, sda3, sda4.
Para cada dispositivo, teremos no máximo 4 partições primárias e 12 partições
lógicas. Não é necessário que sejam esgotadas as partições primárias para termos as
partições lógicas, porém, independente de como esteja a configuração do disco, sempre
que uma partição for identificada com os valores numéricos de 5 – 16, essas serão
partições lógicas e de 1 – 4, primárias.
Os limites descritos acima são para cada disco instalado no sistema, independente
da razão de sua existência. Não devemos confundir com as limitações impostas para o tipo
de partição SWAP, a qual veremos mais adiante.
No mapa abaixo, coloquei algumas situações bem comuns para discos instalados no
GNU/Linux, observe os detalhes da organização dos discos.

25
Mapa 3.2 – Detalhamento das partições de discos no GNU/Linux.
No exemplo acima, temos um sistema IDE padrão sendo usado. Os dispositivos hda e
hdb têm partições primárias e lógicas, sendo que no primeiro, esgotamos as possibilidades
de partições primárias para iniciarmos as lógicas. No segundo, temos 3 partições primárias
e cinco partições lógicas.
Importante notar a nomenclatura das partições, observe que as partições lógicas
sempre iniciam com o identificador numérico 5. Os demais discos tem apenas partições
primárias.
Falamos em partes de discos, em organização “física” dos dispositivos. Além de
definir em quantas partes estará dividido o dispositivo é importante entender os tipos de
file-system, afinal é ele quem organizará os dados para que possamos acessar.

2.1 Estrutura
Tipos de File – System e Particionamento de

Discos.
Após dividirmos um disco em pedaços, o que chamamos de particionamento, é

necessário definirmos um sistema de arquivo que será responsável pelo controle das
informações. Isso é feito pelo processo de formatação das partições.
O sistema de arquivos irá dividir o espaço da partição em:
1. Uma parte para armazenar os dados relativos ao sistema de arquivos
em si;
2. Com o espaço restante, segmentará em pequenos espaços de
tamanhos bem definidos, conhecidos como inodes.
Não existem regras que definam um sistema de arquivos como o universal. Podemos
ter um disco, dividido em 5 partições e mais de um sistema de arquivos, um para cada
partição, porém, sistemas de arquivos podem ser incompatíveis entre si. Por isso, cuidado
ao manuseá-los.
Um sistema operacional pode ser totalmente compatível com um determinado
sistema de arquivo, mesmo não sendo o sistema de arquivo padrão. Esse é um aspecto
bem positivo de se trabalhar com o GNU/Linux, temos “suporte” para quase todas os
sistemas de arquivos existentes hoje, para não falarmos todos. Na abaixo, encontraremos
os sistemas de arquivos suportados pelo GNU/Linux.
Fig. 3.3 – Detalhamento de File - System.

27
Dentre todos os sistemas de arquivos, um que devemos ter o cuidado em entender é

o SWAP. No processo de instalação do sistema, precisamos apenas de duas partições, uma
partição que será usada para o / (local onde o sistema será estruturado) e outra para
ser usada como SWAP, onde serão colocados processos que não estejam em estado de
processando, liberando espaço em memória para processos “ativos”.
Existem limitações que devemos respeitar. Por sistema, note que não falei disco e
sim sistema, podemos ter no máximo 16 gigas de SWAP total e 2 gigas por partição. Em
uma visão mais prática...
Limitação por partição 2 Gigas

Número máximo de partições SWAP 8
Limitação por sistema 8 Partições x 2Gigas = 16 Gigas
De uma forma geral, o tamanho da partição SWAP estava relacionado com a

quantidade de RAM existente no computador. Definíamos a quantidade de SWAP da
seguinte maneira.
SWAP = 2 x RAM (SWAP será 2 vezes a quantidade de RAM)
Considerando que memória RAM era mais valiosa que ouro, esse cálculo foi meio
abandonado quando o volume de memória RAM chegou aos patamares de 512 Megas.
Em sistemas normais, mais que 512 Megas de Swap é realmente desnecessário. Hoje
em dia, algumas literaturas indicam valores entre 256 a 512 MB, para sistemas com mais
de 512 de RAM, porém, na prática, o que determinará o quanto de SWAP deverá ser
instalado no sistema são as aplicações e necessidades impostas pelo cenário a ser
desenvolvido. Por isso, entendermos os motivos que nos levará a instalação de uma
máquina com o sistema GNU/Linux é fundamental.
Particionamento de discos – Comandofdisk

Antes mesmo de instalarmos, vamos verificar como preparar os disco através do
comando fdisk. Considerado um comando com certa dificuldade, faremos um exercício
prático para tentar facilitar o entendimento.
Nunca devemos esquecer que o comando fdisk é um particionador destrutivo, ou
seja, uma vez usado, todos os dados contidos no dispositivo serão perdidos.
O primeiro passo aqui seria a chamada para o fdisk. Para isso digite o comando
abaixo.
# fdisk /dev/sda
Com uma sintaxe simples, o fdisk requer que seja informado qual disco será usado
no processo. Em nosso caso, teremos o sda como alvo do processo de particionamento. A
tela inicial do fdisk será apresentada como na Fig. 3.4.

2.1 Estrutura
Fig. 3.4 – Tela incial do fdisk
Observe que no topo da tela exibida teremos informações da volumetria do

dispositivo. Com a comando “p“, listaremos a tabela de partições do disco. O mesmo
podemos obter sem a necessidade de entrarmos no prompt de execução do fdisk
digitando na shell do sistema o comando #fdisk -l. Veja a Fig. 3.5
Fig. 3.5 – Listagem da organização do disco.
Observe na figura acima que a partição estendida aparece destacada, veja ao lado
direito a descrição Extended e logo abaixo dela está a partição lógica.
Com a comando “m” teremos o help do fdisk, aqui encontraremos as opções para
uso do fdisk. Algumas opção serão apresentadas apenas no menu de uso avançado do
fdisk. Para acesso aos recursos avançados digite o comando “x” e em seguida o comando
“m”.
Muito cuidado ao usar o fdisk, para garantias de que o que foi feito realmente era a
ação desejada, sempre use o comando “p”, assim você acompanhará todo o processo.
Caso tenha dúvidas do que fazer, o comando “q” sempre será bem-vindo. Com ele
sairemos do prompt do fdisk sem salvar as alterações. Veja um exemplo na Fig 3.6

29
Fig. 3.6 – Detalhamento da opção m do fdisk.

Antes de criarmos novas partições, vamos apagar todas as existentes no sistema,
use o comando “d“. O número da partição será solicitado. Informe-o de acordo com a
partição que deseja apagar. Farei com uma partição para demonstrar, veja abaixo.
Fig. 3.7 – Detalhamento da opção d do fdisk.
Faça o mesmo com as outras partições que deseja apagar, uma a uma.
Criaremos agora a nova partição. Para isso, usaremos o comando “n“. Algumas
informações serão solicitadas. Veja que no exemplo abaixo. O primeiro passo é definirmos
se a partição será ou não primária.
Em seguida, informamos o número da partição, defina o bloco inicial da partição.
Caso não saiba qual será o bloco inicial, use o valor definido pelo sistema. Por fim, informe
o tamanho da partição, exatamente como demonstrado no exemplo. Note que existe um
sinal + antes do tamanho e a letra M para determinarmos que o tamanho será em Megas.
Fig. 3.8 – Detalhamento da opção n.

Repita esta etapa para criar as outras partições do sistema.
Após definirmos o tamanho, definiremos o tipo de file system da partição, usando

2.1 Estrutura
comando “t “.
Será solicitado o número de uma partição, e em seguida o código do tipo do file
system. Com a opção “L“ teremos a lista de todos os file system suportados. Identifique o
file system que irá usar na partição e digite o código hexadecimal que está descrito ao
lado esquerdo da descrição na tabela apresentada.
Tendo uma visão geral do processo teremos. . .
Fig. 3.10 – Detalhamento de todo o processo de escolha do File System.
Repita essa etapa para cada partição criada, assim, não teremos surpresas
desagradáveis nas próximas etapas do processo. Usando o comando “w“, salve e saia do
fdisk.
Para que todas as alterações sejam válidas, é interessante reiniciar o sistema.
Sistema reiniciado, vamos ao processo de formatação das partições criadas.
Formatação do disco – Comando mkfs

O fato de se criar uma partição e definir um file system não nos dá a condição de uso
da partição. Para que possamos usá-la precisamos formatá – la de forma que o sistema
possa entender a organização dos dados.
Não esqueça que o fdisk é apenas um particionador, para formatarmos um partição
no GNU/Linux, usaremos o comando mkfs.
Imagine que seja necessário formatar uma partição, usando o ext3 como file system.
Veja como é simples...
#mkfs.ext3 /dev/sda5
Interessante nesse momento buscarmos por blocos defeituosos. Para isso, use o

31
comando fsck, como no exemplo abaixo

#fsck.ext3 -pc /dev/sda5
No comando acima, duas ações foram efetuadas. O -p define que será feito a
reparação do sistema automaticamente. Já o -c busca por bad blocks e os adiciona a uma
lista.
Para partições SWAP, o conceito é basicamente o mesmo, o que muda são os
comandos que usaremos. Veja como a mesma ação seria feita para a SWAP.
#mkswap -c /dev/sda6
Formatação feita, vamos ativar a partição SWAP com o comando swapon
#swapon -a
Podemos verificar as partições SWAP lendo o conteúdo do arquivo /proc/swaps.
#cat /proc/swaps
Muito bem, partições criadas, formatadas e checadas. Podemos seguir com nosso
processo.
Instalação do GNU/LINUX
Partiremos agora para instalação do GNU/Linux. Usaremos o padrão de instalação
gráfica, por questões didáticas. Não usarei aqui nenhuma instrução avançada para a
instalação apesar de criar as partições e formatar os discos usando o fdisk para dar uma
base de como seria o preparo para instalação no slackware, por exemplo.
Detalhar cada processo de forma muito minuciosa, seria realmente complicado haja
vista que venho dizendo desde o início que para determinarmos uma organização para a
instalação precisamos entender as necessidades do ambiente a ser configurado. Por isso,
resolvi usar minhas aulas para discutirmos um pouco mais sobre o assunto, e acredite,
falamos muito sobre isso.
Para demonstrar a instalação, usaremos o Fedora como modelo. Respeitando as
características de cada distribuição, o processo é basicamente o mesmo. Vamos ao
processo de instalação.
Creio que seja interessante conhecer o equipamento que será usado, para poder
determinar características mais específicas ao sistema.

2.2 RPM e DEB 55
2.2 RPM e DEB

101
Pacotes RPM
Criado pela Red Hat, o Red Hat Package Manager (rpm) é o mais popular de todos os
gerenciadores de pacotes. Usá-lo é bem simples e um grande número de distribuições
adotou – o como sendo o gerenciador de pacotes. Dentre outras informações, temos nos
pacotes rpm:
1. Arquivos da aplicação compactados

2. Nome e versão do pacote
3. Data de criação
4. Descrição do pacote e da aplicação
5. Informações de quem criou o pacote
6. MD5 checksum para verificação de integridade do pacote
7. Outros pacotes requeridos (dependências)
Entendendo o nome de pacote rpm, termos

ethereal-0.8.9-1.i386.rpm
ethereal = Nome do pacote
-0.8.9 = Versão
-1 = Patch
.i386 = Arquitetura
.rpm = Extensão rpm
Trocando em miúdos ... O pacote acima está na versão 0.8.9 e este é a primeira
compilação do mesmo, sendo que foi compilado para a arquitetura i386, padrão intel.
Vantagens e desvantagens do formato
As vantagens de utilizar os pacotes RPM em com relação a outro métodos de adquirir
e instalar software são:
• Um método uniforme para o usuário instalar programas.
• Maior simplicidade para desinstalar os programas.
• Popularidade: muitos pacotes disponíveis, mesmo que eles comumente
precisem de uma recompilação para funcionarem em uma outra distribuição.
• Instalação não-interativa: facilita uma instalação automática.
• Código-fonte original incluído (.tar.gz, .tar.bz2): fácil de verificar.
• Verificação criptográfica com o GPG e o md5.
As desvantagens citadas incluem:
• Comumente tem mudanças no formato de pacote incompatíveis com versões
anteriores.
• Documentação incomplete e desatualizada.
• Pouca aprendizagem sobre os pacotes.

56 102 Capítulo 2. Material Complementar
O RPM também vem sendo criticado pela falta de consistência no nome e conteúdo
dos pacotes, o que pode dificultar o manejo automático de dependências. Entretanto, este
problema não ocorre apenas no formato RPM, mas é um problema na maioria das
distribuições que usam os pacotes RPM tais como o Red Hat, SuSE e Mandrake (Mandriva)
Linux.
Base de dados RPM
Atrás do gerenciador de pacotes está o banco de dados rpm. Ele consiste de uma
lista duplamente ligada que contêm todas as informações de todos os rpm instalados. O
banco da dados lista todos os arquivos que são criados ou modificados quando um usuário
instala um programa e facilita a remoção destes mesmos arquivos. Se o banco de dados
fica corrompido (o que acontece facilmente se o cliente de rpm é fechado subitamente), as
ligações duplas garantem que eles possa ser reconstruído sem nenhum problema. No
computadores com o sistema operacional RedHat instalado, este banco da dados se
encontra em /var/lib/rpm.
Agora que fomos apresentados aos pacotes rpm, vamos entender o comando rpm.
RPM
Descrição: RPM Gerenciador de Pacotes .rpm
Opções Gerais
--quiet Normalmente somente as mensagens de erro
serão apresentadas.
-v Mostra o detalhamento da execução do
comando.
-vv Imprime informações de debug da execução do
comando.
--rcfile FILELIST Informações de configuração de instalação do
pacote RPM. O padrão é ter as informações
separadas por dois pontos como no exemplo.
/usr/lib/rpm/rpmrc:/usr/lib/rpm/redhat/rpmrc:/etc/r
pmrc:~/.rpmrc.
--dbpath DIRECTORY Informa o caminho para a base RPM,
normalmente em /var/lib/rpm
--root DIRECTORY Informa o diretório usado, no qual encontraremos
a base para verificação de dependências dos
pacotes.
Opções de Instalação e upgrade
--aid Adiciona pacotes ajustando as necessidades de
operação.
--allfiles Instala ou atualiza todos os arquivos do pacote
mesmo que existam.
--excludedocs Não instala arquivo de manuais.
--force O mesmo que --replacepkgs, --replacefiles, e –
oldpackage.

2.2 RPM e DEB 103 57
-h, --hash Imprime o hash durante o processo de
instalação. Usado pelo modo verbose para
acompanhamento do processo.
--ignoresize Não checa se há espaços para instalação do
pacote.
--ignorearch Permite a instalação de pacotes mesmo se a
arquitetura dos binários e da máquina não sejam
combinantes.
--ignoreos Permite a instalação ou atualização de pacotes
mesmo que o sistema operacional dos binários e
do pacote não forem combinantes.
--includedocs Instala a documentação do pacote.
--justdb Atualiza o banco de pacotes mas não o sistema.
--nodigest Não verifica cabeçalhos do pacote ao ler.
--nosignature Não verifica assinaturas de cabeçalhos de
pacotes.
--nodeps Não verifica dependências após instalação ou
atualização de pacotes.
--noorder Não reordena os pacotes para a instalação. A
lista de pacotes normalmente será reordenada
para satisfazer dependências.
--prefix NEWPATH Redefine o caminho caminha dos pacotes no
processo de instalação.
--test Não instala os pacotes, apenas checa o nível de
conflito do mesmo.
ERASE OPTIONS
--allmatches Remove todas as versões de um pacote. Em caso
de múltiplos pacotes, uma mensagem de erro é
exibida.
--nodeps Não checa dependências na desinstalação de um
pacote.
QUERY OPTIONS
--qf|--queryformat QUERYFMT
-a, --all Pesquisa por todos os pacotes instalados.
-f, --file FILE Pesquisa pelos arquivos de um pacote instalado.
PACKAGE QUERY OPTIONS:
-c, --configfiles Lista somente os arquivos de configuração de um
pacote.
-d, --docfiles Lista somente os arquivo de manuais de um
pacote.
--filesbypkg Lista todos os arquivos relacionados a um
pacote.
-i, --info Lista informações do pacote.

--last Ordena a exibição dos pacotes, mostrando quais
foram os últimos instalados aos primeiros.
-l, --list Lista todos os arquivo de um pacote.
-R, --requires Lista as dependências de um pacote.
--scripts Lista os scripts usados na instalação e
desinstalação de um pacote.
-s, --state Mostra informações dos arquivos de um pacote,
informando se o mesmo está instalado,
desinstalado ou reinstalado.
Tabela 1– Detalhamento de Opções do comando rpm
Exemplos:
#rpm -qial samba
#rpm -ivh samba-3.0.9-1.i386.rpm
#rpm -e samba*.rpm
Pacotes DEB
Um outro padrão de pacotes existente no mundo linux é o desenvolvido pela
distribuição DEBIAN, os famosos pacotes .deb. Estudaremos nesse capítulo o comando
dpkg .
O primeiro passo que daremos será a localização das informações dos pacotes. O
dpkg mantém as informações basicamente em dois arquivos, /var/lib/dpkg/avliable e
/usr/lib/dpkg/status. O primeiro possui a lista de pacotes disponíveis e o segundo o status
dos pacotes.
DPKG
Descrição: Debian Gerenciador de Pacotes .deb
-E Não substitui um pacote de mesma
versão.
-G Sobrescreve um pacote existente, mesmo
de versões antigas.
-R Processa um conjunto de pacotes dentro
de um diretório.
-i Instala um pacote
-l Usa a chave de busca para lista os
pacotes que contenham referência a essa
chave.
-L Lista os arquivos instalados por um pacote
--print-avail nomepacote Lista um conjunto de informações
relacionadas ao pacote

2.2 RPM e DEB 105 59
--purge Remove todo o pacote
-r Remove todos os arquivos do pacote
menos os de configuração
-s Mostra o status do pacote
-S Procura por um arquivo nos pacotes
instalados.
--unpack Desempacota um pacote, porém não
instala
--configure Configura um pacote não instalado.
Tabela 5.1 – Detalhamento de Opções do comando dpkg
Exemplos:
#dpkg -s samba
#dpkg -i samba*.deb
#dpkg –purge samba
#dpkg -r samba

● linux2
State: running
Jobs: 0 queued
Failed: 0 units
Since: Dom 2016-03-27 02:57:18 BRT; 7h ago
CGroup: /
├─1 /sbin/init
├─system.slice
│ ├─avahi-daemon.service
│ │ ├─431 avahi-daemon: running [linux2.local
│ │ └─507 avahi-daemon: chroot helpe
│ ├─dbus.service
│ │ └─432 /usr/bin/dbus-daemon --system --address=systemd: --nofork
--nopidfile --systemd-activation
│ ├─ModemManager.service
│ │ └─420 /usr/sbin/ModemManager
│ ├─cron.service
│ │ └─415 /usr/sbin/cron -f
│ ├─nfs-common.service
│ │ ├─398 /sbin/rpc.statd
│ │ └─412 /usr/sbin/rpc.idmapd
│ ├─exim4.service
│ │ └─751 /usr/sbin/exim4 -bd -q30m
│ ├─wpa_supplicant.service
│ │ └─1339 /sbin/wpa_supplicant -u -s -O /run/wpa_supplicant
│ ├─aolserver4.service
│ │ └─508 /usr/sbin/aolserver4-nsd -u www-data -g www-data -b
127.0.0.1:80 -s main -t /etc/aolserver4/aolserver4.tcl
│ ├─accounts-daemon.service
│ │ └─1329 /usr/lib/accountsservice/accounts-daemon
│ ├─colord.service
│ │ └─1284 /usr/lib/colord/colord
│ ├─atd.service
│ │ └─418 /usr/sbin/atd -f
│ ├─systemd-journald.service
│ │ └─135 /lib/systemd/systemd-journald
│ ├─minissdpd.service
│ │ └─464 /usr/sbin/minissdpd -i 0.0.0.0
│ ├─udisks2.service
│ │ └─1249 /usr/lib/udisks2/udisksd --no-debug
│ ├─upower.service
│ │ └─1220 /usr/lib/upower/upowerd
│ ├─systemd-timesyncd.service
│ │ └─389 /lib/systemd/systemd-timesyncd
│ ├─packagekit.service
│ │ └─1288 /usr/lib/packagekit/packagekitd
│ ├─ssh.service
│ │ └─416 /usr/sbin/sshd -D
│ ├─systemd-logind.service
│ │ └─430 /lib/systemd/systemd-logind
│ ├─system-getty.slice
│ │ └─getty@tty2.service
│ │ └─1385 /sbin/agetty --noclear tty2 linux
│ ├─systemd-udevd.service
│ │ └─147 /lib/systemd/systemd-udevd
│ ├─polkitd.service
│ │ └─727 /usr/lib/policykit-1/polkitd --no-debug
│ ├─rpcbind.service
│ │ └─383 /sbin/rpcbind -w
│ ├─NetworkManager.service
│ │ ├─419 /usr/sbin/NetworkManager --no-daemon
│ │ └─921 /sbin/dhclient -d -q -sf /usr/lib/NetworkManager/nm-dhcp-
helper -pf /var/run/dhclient-eth0.pid -lf /var/lib/NetworkManager/dhclient-
3136dc59-0d3c-4713-ae09-f120fb79112a-eth0.lease -cf
2.2 RPM e DEB 61
/var/lib/NetworkManager/dhclient-eth0.conf eth0
│ ├─rsyslog.service
│ │ └─713 /usr/sbin/rsyslogd -n
│ └─acpid.service
│ └─716 /usr/sbin/acpid
└─user.slice
└─user-0.slice
├─session-1.scope
│ ├─ 723 /bin/login --
│ ├─ 843 -bash
│ ├─1114 /bin/sh /usr/bin/startx
│ ├─1136 xinit /etc/X11/xinit/xinitrc -- /etc/X11/xinit/xserverrc
:0 vt1 -auth /tmp/serverauth.QQRjMK0DS3
│ ├─1137 /usr/bin/X -nolisten tcp :0 vt1 -auth
/tmp/serverauth.QQRjMK0DS3
│ ├─1144 x-session-manager
│ ├─1175 /usr/bin/ssh-agent /usr/bin/dbus-launch --exit-with-
session x-session-manager
│ ├─1178 /usr/bin/dbus-launch --exit-with-session x-session-
manager
│ ├─1180 /usr/bin/dbus-daemon --fork --print-pid 5 --print-
address 7 --session
│ ├─1183 /usr/lib/at-spi2-core/at-spi-bus-launcher
│ ├─1187 /usr/bin/dbus-daemon --config-file=/etc/at-
spi2/accessibility.conf --nofork --print-address 3
│ ├─1190 /usr/lib/at-spi2-core/at-spi2-registryd --use-gnome-
session
│ ├─1201 /usr/lib/gnome-settings-daemon/gnome-settings-daemon
│ ├─1206 /usr/bin/gnome-keyring-daemon --start --components=ssh
│ ├─1219 /usr/bin/pulseaudio --start
│ ├─1232 /usr/lib/gvfs/gvfsd
│ ├─1234 /bin/sh /usr/bin/start-pulseaudio-x11
│ ├─1236 /usr/bin/xprop -root -spy
│ ├─1240 /usr/lib/gvfs/gvfsd-fuse /run/user/0/gvfs -f -o
big_writes
│ ├─1247 /usr/lib/gvfs/gvfs-udisks2-volume-monitor
│ ├─1258 /usr/lib/gvfs/gvfs-gphoto2-volume-monitor
│ ├─1262 /usr/lib/gvfs/gvfs-mtp-volume-monitor
│ ├─1266 /usr/lib/gvfs/gvfs-goa-volume-monitor
│ ├─1269 /usr/lib/gnome-online-accounts/goa-daemon
│ ├─1276 /usr/lib/telepathy/mission-control-5
│ ├─1278 /usr/lib/gvfs/gvfs-afc-volume-monitor
│ ├─1283 /usr/bin/gnome-shell
│ ├─1301 /usr/lib/gnome-settings-daemon/gsd-printer
│ ├─1317 /usr/lib/gnome-shell/gnome-shell-calendar-server
│ ├─1321 /usr/lib/evolution/evolution-source-registry
│ ├─1340 zeitgeist-datahub
│ ├─1343 nm-applet
│ ├─1346 /usr/lib/tracker/tracker-store
│ ├─1350 /usr/bin/zeitgeist-daemon
│ ├─1351 /usr/lib/tracker/tracker-miner-fs
│ ├─1352 /usr/lib/tracker/tracker-miner-apps
│ ├─1358 /usr/lib/evolution/3.12/evolution-alarm-notify
│ ├─1364 /usr/lib/evolution/evolution-calendar-factory
│ ├─1365 /usr/lib/tracker/tracker-miner-user-guides
│ ├─1367 /usr/lib/tracker/tracker-extract
│ ├─1371 /usr/lib/i386-linux-gnu/gconf/gconfd-2
│ ├─1372 /usr/bin/python /usr/share/system-config-
printer/applet.py
│ ├─1377 /usr/lib/i386-linux-gnu/zeitgeist-fts
│ ├─1399 /bin/cat
│ ├─1488 /usr/bin/nautilus --gapplication-service
│ ├─1494 /usr/lib/gvfs/gvfsd-trash --spawner :1.11
/org/gtk/gvfs/exec_spaw/0
│ ├─1503 /usr/lib/gvfs/gvfsd-burn --spawner :1.11

/org/gtk/gvfs/exec_spaw/1
│ ├─1517 /usr/lib/dconf/dconf-service
│ ├─1525 /usr/lib/gvfs/gvfsd-metadata
│ ├─1624 /usr/lib/gnome-terminal/gnome-terminal-server
│ ├─1627 gnome-pty-helper
│ ├─1628 bash
│ └─1633 systemctl status
└─user@0.service
├─839 /lib/systemd/systemd --user
└─841 (sd-pam)
2.3 Bootstraping 63
2.3 Bootstraping
43
Bootstrapping – Inicialização do Computador.

Muitas pessoas me questionam se o mais importante é saber o maior número de
comandos possíveis e imagináveis ou saber como colocar um super servidor no ar. Para
mim, é o entendimento do sistema e conhecer as relações entre os processos e os
arquivos.
Saber como se comporta o sistema durante o processo de inicialização é o foco deste
capítulo. Estudaremos as etapas de bootstrapping desde os testes da bios ao processo de
login do usuário. Vamos direto ao ponto então.
Veja a seqüência de boot no diagrama 4.1
Diagrama 4.1 – Detalhamento do Processo de inicialização do Sistema.
Durante o processo de inicialização, nada está em funcionamento e o sistema tem

que se virar para criar o ambiente necessário para que possamos interagir com o mesmo.
Durante o processo de bootstrapping, o kernel é carregado em memória e inicia um
conjunto de execuções para tornar o sistema disponível.
No gráfico acima, tentei resumir todo o processo para tornar mais simples a
visualização do mesmo, porém, acho importante detalhar um pouco demonstrando os
arquivos que serão lidos durante esta etapa.
Iniciado o sistema, a primeira etapa do processo é iniciado pelo código de boot
encontrado em memória ROM. Durante essa etapa, o sistema faz um reconhecimento do
hardware, em seguida, tenta localizar uma chamada para carga do kernel em memória.
Essa etapa eu chamo de boot de bios.
Em seguida o kernel é chamado, carregado em memória e entra em ação. Vamos

estudar essa etapa do boot, que chamo de boot de kernel.

Durante o processo de bootstrapping, sua primeira tarefa é garantir o kernel em
execução em memória. Para isso, é feito uma chamada ao arquivo /boot/vmlinuz.
Após carregar e garantir a execução do kernel em memória, este executa testes de
memória para tentar descobrir quanto poderá ser usado. Algumas informações são
dimensionadas de forma estatística, assim, pode-se determinar quanto de memória será
usada para si e quanto poderá ser inicializada. Esta memória é reservada para o kernel, o
que impede o uso para aplicações em camadas de usuário.
Uma das primeiras etapas aqui é a checagem do hardware, para poder determinar
que dispositivos estão presentes. As informações dos dispositivos nem sempre são
fornecidas completamente. Para resolver isso, o kernel sonda o barramento em busca dos
dispositivos para determinar informações nos drivers apropriados. Para os dispositivos com
drivers que estão faltando ou que não respondem a sondagem serão desabilitados. Em
compensação, dispositivos conectados posteriormente podem ter seus drivers carregados
ou habilitados durante a execução.
Terminado o processo do kernel, vários processos são criados. O primeiro processo a
ser criado é o init, considerado o processo pai de todos os outros processos. Sua
identificação será sempre com o PID 1 (Identificador do processo).
Junto ao processo init vários outros processos são carregados. Todos esses processos
estão ligados ao nível de execução do sistema, o que veremos em mais detalhes em
capítulos posteriores.
Mas uma pergunta ainda permanece. Quem é responsável pela chamada do kernel ?
Bem, o responsável por essa chamada é o BOOT LOADER. No GNU/Linux temos dois
BOOT LOADERS padrão, o GRUB e o LILO.
Vamos ver em detalhes ambos na etapa seguinte.
Gerenciadores de boot (bootloaders)
Após a etapa de boot da máquina, que é iniciado pela BIOS, o primeiro mecanismo
de interação que teremos junto ao sistema é o Boot Loader. No GNU/Linux temos dois Boot
Loaders, o GRUB ( GRand Unifying Bootloader ) e o LILO ( LInux LOader ). É de
responsabilidade dele fazer a chamada do kernel do sistema, por isso, se faz necessário o
entendimento do Boot Loader para um administrador de sistema.
Partiremos do GRUB.
GRUB ( GRand Unified Bootloader)
A primeira informação que devemos ter do GRUB é sobre a localização do seu

arquivo de configuração e como personalizá-lo.
Os arquivos de configuração do grub estão em /boot/grub. Alguns livros informam–
no como sendo o arquivo menu.lst, porém, vejam que menu.lst é um link do arquivo
grub.conf, como demonstrado abaixo.
#ls /boot/grub
lrwxrwxrwx 1 root root 11 Ago 31 11:45 menu.lst -> ./grub.conf

2.3 Bootstraping 45 65
Vamos entender o arquivo grub.conf.
#vim /boot/grub/grub.conf
# grub.conf generated by anaconda

#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE: You do not have a /boot partition. This means that
# all kernel and initrd paths are relative to /, eg.
# root (hd0,5)
# kernel /boot/vmlinuz-version ro root=/dev/hda6
# initrd /boot/initrd-version.img
#boot=/dev/hda
default=1 (Indicação de qual sistema operacional será inicializado por padrão)
timeout=15 (Indicação do tempo de espera, em segundos, para carregar o
sistema operacional, caso não haja interação de teclado)
splashimage=(hd0,5)/boot/grub/splash.xpm.gz (Arquivo que será usado como
papel de parede do GRUB)
hiddenmenu (Inibe a exibição de opções no menu do grub, durante o boot. Garante
que a imagem especificada pela linha default seja carregada)
title Fedora Core (2.6.15-1.2054_FC5) (Nome do Sistema. Apenas em
caráter informativo. Podemos colocar qualquer nome nessa área)
root (hd0,5) (Indica a partição onde o sistema foi instalado. Um detalhe importante
é observar a forma como os endereços do disco são informados, hd0 corresponde à hda e
5 à sexta partição do disco. Trocando em miúdos, hd0,5 é correspondente à hda6)
kernel /boot/vmlinuz-2.6.15-1.2054_FC5 ro root=LABEL=/ rhgb quiet
(Imagem do kernel que será chamada para o Boot)
initrd /boot/initrd-2.6.15-1.2054_FC5.img (Aqui teremos a chamada do arquivo
que contém informações dos módulos que serão carregados. Cada compilação do kernel
terá seu arquivo de imagens)
title Other
rootnoverify (hd0,0) (Essa opção tem a mesma função de root, porém, não
tenta montar a partição raiz. É muito usada para chamadas de sistemas como MS-DOS e
Windows)
chainloader +1 (Alguns sistemas operacionais armazenam seus bootloaders no
início da partição onde estão instalados. O chainloader informa o local onde o Bootloader
foi instalado)
Além de entendermos as configurações do GRUB, precisamos conhecer ainda o

utilitário grub-install. O grub-install instala o GRUB na MBR do primeiro disco, criando o

diretório /boot/grub.
As opções mais usadas com o grub-install são :
--root-directory=DIR (Instala a imagem do GRUB em diretório que não seja o
raiz)
--recheck (Checa o arquivo /boot/grub/device.map. Útil quando retiramos ou
acrescentamos um novo disco no sistema)
LILO ( LInux LOader )
O LILO foi o primeiro Bootloader usado pelas distribuições GNU/Linux. Por ser grande
para caber no setor de boot ou na MBR, o LILO foi dividido em duas partes.
A primeira é o motor de arranque e está na MBR ou setor de boot, sendo que a
segunda é a responsável pela interação com o usuário. Um dos aspectos mais
importantes do lilo é a configuração do mesmo. Vamos analisar o arquivo /etc/lilo.conf
boot=/dev/hda (Aqui definimos de qual disco será usado o setor de boot
do sistema)
map=/boot/map (Arquivos de mapas. Por padrão /boot/map)
install=/boot/boot.b (Arquivo de setor de boot)
prompt (Disponibiliza ao usuário um prompt de interação com o
LILO)
timeout=50 (Define o tempo de espera antes de iniciar o sistema)
image=/boot/vmlinuz (Caminho completo para a imagem que será carregada)
label=Linux (Nome de identificação da imagem)
root=/dev/hdb1 (Partição que deverá ser montada como root)
read−only (Apenas Leitura)
Para que possamos ter as alterações disponíveis no próximo boot do sistema, é
necessário usar a aplicação /sbin/lilo.
Níveis de execução do Sistema.

Durante o processo de boot do sistema, init é ativado dando início ao que chamo de
explosão dos processos filhos do init, ou seja, todo e qualquer processo startado no
sistema.
Esses processos estão ligados diretamente ao nível de execução do sistema, o qual
está referenciado no arquivo /etc/inittab. É necessário entendermos algumas
informações desse arquivo, então vamos a elas.
No processo de carga do init, o arquivo /etc/inittab será lido para que o sistema
saiba qual nível de execução padrão. Através do nível de execução, o sistema saberá
quais serviços deverão ser carregados sempre que a máquina for ligada. Em um sistema
padrão, temos 7 níveis de execução para o Linux, indo do nível 0 ao nível 6, cada um
com uma característica. Veja o padrão de funcionamento dessas características,
analisando Mapa 4.2.1. Importante ressaltar que algumas distribuições alteram o
comportamento de alguns níveis.

2.3 Bootstraping 47 67
Mapa 4.2.1 – Detalhamento dos níveis de execução.
Para determinarmos o nível padrão de execução, edite a linha id:NE:initdefault:,

onde NE é o nível de execução do sistema. Por exemplo, id:3:initdefault: determina que
o nível de execução será o nível 3.
Para cada nível de execução existirá um diretório /etc/rc.d/rcNE.d, onde
encontraremos os scripts de start e stop dos serviços relacionados com este nível. Os
arquivos estão descritos de duas formas S45autofs e K85autofs, vamos entendê-los.
O S indica que o serviço relacionado ao arquivo será inicializado durante o start do
nível, o número 45 indica a ordem de prioridade desse serviço em relação aos outros que
também serão carregados o nome é apenas uma descrição, aqui colocamos o nome de
serviço para facilitar a identificação do mesmo.
No outro arquivo teremos o K indicando que o serviço será “morto”, desligado, o
número como no primeiro caso indica a ordem em relação aos outros serviços que serão
mortos e o nome.
Para cada nível existirá um conjunto de aplicações que serão mortos e outras que
serão carregadas. Para saber mais sobre esses serviços, veja o conteúdo dos diretórios
/etc/rc.d/rcNE.d.
Após os processos terem sido inicializado, a próxima etapa é a execução do getty,
aguardando o login do usuário. Essa etapa é descrita como boot de usuário.
Durante o processo de login do usuários, alguns arquivos são lidos para que seja
criado o ambiente de interação do mesmo, junto ao sistema. Seria quase impossível criar
um ambiente para cada usuário, tendo que copiar cada arquivo necessário para os homes,
manualmente. Para isso, o sistema lerá a “variável” skel no arquivo
/etc/default/useradd, ele informará onde estão os arquivos necessários para a criação
do ambiente do usuário (.bashrc, .bash_profile e .bash_logout), no nosso caso em
/etc/skel.
O arquivo .bash_profile é responsável pelos programas que devem ser executados
na abertura da sessão do usuário, pela configuração do ambiente e pelos caminhos
(PATH). Nele também há uma chamada para o .bashrc.
O arquivo .bashrc é executado por uma chamada do .bash_profile. Podemos editar
o arquivo para personalizar o ambiente. Nele é muito comum que sejam criados alias para

comando, facilitando a vida do usuário. Importante lembrar que estamos falando de um

arquivo que estará no diretório home do usuário, assim, tudo o que for alterado nele, será
valido apenas para o usuário. Veja como poderíamos editar este arquivo.
$vim .bashrc
# .bashrc
# Source global definitions

if [ -f /etc/bashrc ]; then
. /etc/bashrc
fi
alias l='ls -aF --color=auto'
alias montacd='eject; sleep 5; eject -t; mount /media/cdrom; cd
/media/cdrom; ls'
Ainda existem dois arquivos que fazem parte do processo de criação de ambiente do
usuário com o sistema, sendo estes o /etc/bashrc (responsável por variáveis globais, lido
sempre que o uma nova sessão da bash for executada) e o /etc/profile (executado
sempre que um usuário logar. Responsáveis pelas variáveis do sistema dentre outras
informações usadas pelo usuário junto as consoles). Para determinar comportamentos
“globais”, comuns a todos os usuários, podemos editar o arquivo /etc/profile. Para
criarmos aliases globais, podemos usar o /etc/bashrc.
Algumas variáveis devem ser conhecidas, para que possamos ajustar o sistema para
necessidades mais específicas.
Variável Definição
BASH shell usada pelo usuário
PS1 Formato de apresentação do prompt
PATH Caminhos de localização de comandos e
aplicações do sistema.
HOSTNAME Nome da máquina
HOME Diretório home do usuário logado
LOGNAME Login do usuário
UID Identificador numérico do usuário
Alterar qualquer valor das variáveis do sistema pode acarretar no funcionamento

pouco eficiente do mesmo, por isso, cuidado ao tratar dessas informações. Veremos mais
sobre shell, variáveis de sistemas e customização de ambiente mais adiante.

2.4 Control Centre: The systemd Linux init system
Uma variedade de distribuições agora passará usar o systemd, ao invés de sysvinit. O último dos
três grandes sistemas de inicialização promete acelerar a inicialização e não requer configuração
de dependência entre serviço de sistema explícito; como um efeito secundário, também elimina
algumas particularidades específicas da distribuição.
A seguinte descrição das ideias por trás da abordagem systemd foi publicado na revista alemã
c't 13/11e foi replicado em vários lugares antes de aparecer em The H Abrir.
Em distribuições Linux, o kernel passa responsabilidades tradicionalmente em seu sistema de

set-up para o componente SysV-init. Dois anos atrás, Systemd é estabelecido para assumir esse
legado difícil. Uma das suas características particulares é que inicia background services em
paralelo sem a necessidade de dependências entre esses serviços serem especificados
antecipadamente; usa recursos de hardware de forma mais eficiente e permite que o sistema
inicie rapidamente.
Systemd também lida com várias tarefas que antes eram realizadas usando scripts específicos
de distribuição; como um efeito colateral, isso elimina várias diferenças de interface de usuário
e de configuração entre distribuições. Várias distribuições já usam systemd: Fedora (desde a
versão 15), o openSUSE 12.1 e Mandriva 2011; Mageia irá mudar com a versão 2. Systemd
também está incluído como uma opção no Arch Linux, Gentoo e Debian Testing; os
desenvolvedores de várias outras distribuições estão discutindo se a oferecê-lo como uma
opção ou mudar completamente.
Tarefas
Desde os primeiros dias do Unix, o processo init tem desempenhado um papel especial dentro
do sistema operacional porque ele é o primeiro processo a ser gerado pelo kernel. Todos os
outros processos são processos filhos do processo de inicialização, o que, por causa de sua
posição especial, é responsável pela configuração do userland. Isso inclui implementar os
sistemas de arquivos que são necessários para a operação do sistema e configurar a rede, bem
como o lançamento dos serviços e programas que são executados em segundo plano - incluindo
aqueles que permitem aos usuários fazer login no sistema.
Uma vez que o sistema está configurado, o processo init permanece no fundo, principalmente
em um estado ocioso. Ele se comunica com o kernel e serão informados de eventos como um
usuário pressionar Ctrl + Alt + Del. Assim como quando os usuários chamam comandos como
shutdown -r agora ou reinicialização, o número do processo 1 vai então iniciar tudo o que é
necessário para desligar corretamente o sistema.
Em Unix System V na década de 1980, essas tarefas foram tratadas pelo "sistema de inicialização
System V" simples, mas flexível. Na década de 1990, os desenvolvedores criaram uma nova
implementação deste sistema de inicialização e chamou-lhe sysvinit. A nova implementação
opera com lógica muito semelhantes e ainda é utilizado na maioria das distribuições hoje. No
entanto, o aumento do uso de Linux em dispositivos móveis, em PCs desktop, em TVs e em
muitos outros domínios mudou os requisitos para o processo init.
Abordagens
Por um longo tempo, parecia que o sistema Upstart, um projeto que foi iniciado por um
desenvolvedor Canonical em 2006, seria o sucessor designado ao sysvinit de envelhecimento.
Inicialmente, ele só foi utilizado no Ubuntu, mas mais tarde também se tornou parte do Fedora
(versões 9 a 14) e Red Hat Enterprise Linux (família RHEL6). OpenSUSE experimentou com
Upstart ao desenvolver a versão 11.3, mas decidiu ficar com sysvinit naquela época. Upstart é
um sistema de inicialização orientada para o evento - que pode começar serviços em caso de
eventos como "rede está configurada" ou "dispositivo de rede está montada". A sua abordagem
é muito diferente da de SysV-init, e configurações existentes pode, portanto, só pode ser
migrado para modelo orientado a eventos do Upstart com grande dificuldade, se em tudo.
Systemd foi lançado em Abril de 2010; adota várias ideias de sistemas de inicialização anteriores
e combina-los com uma configuração uniforme e interface de administração. Systemd opera
como um serviço de fundo (daemon) e controla as tarefas de configuração do sistema
importantes, incluindo a inicialização do hardware e o início de processos do servidor. Os
desenvolvedores pensaram que seu nome é, adequadamente, uma reminiscência do termo
francês "système D", uma expressão que se refere a "pensar em seus pés" e descreve as
habilidades de resolução de problemas técnicos de alta velocidade, tais como aqueles indicados
pela ação TV herói MacGyver.
O caminho de volta
Uma característica do systemd é a sua ativação soquete, o que lhe permite iniciar serviços de
fundo em paralelo sem especificar explicitamente as dependências assim que o sistema básico
está configurado e os sistemas de arquivos locais foram montados. O aspecto inteligente é que
systemd própria cria as bases que são usados como vias de comunicação para os serviços que
estão a ser lançado, e depois entrega as tomadas ao longo dos serviços, enquanto o lançamento.
Os serviços de syslog e D-Bus são bons exemplos para ilustrar este conceito. Quando é iniciado,
D-Bus conecta à tomada de /dev/log eo usa para se comunicar com o daemon de log para que
este daemon pode escrever de status e mensagens de erro para o log do sistema, se necessário.
Portanto, as distribuições SysV-init única lançar D-Bus uma vez que o serviço de syslog é
totalmente funcional.
Systemd, por outro lado, cria /dev/log e, em seguida, lança Syslog e D-Bus, ao mesmo tempo;
todos os dados enviados para /dev/log por D-Bus antes Syslog está pronto será enviado a um
buffer. Originalmente, Systemd deixar o buffer alça do kernel; em versões Systemd atuais, o
"Journal" incluído log recurso cuida dessa tarefa.
Isso permite que systemd para iniciar Bluetooth, Avahi e outros serviços que se comunicam com
o daemon de log ou D-Bus, ao mesmo tempo que Syslog e D-Bus. Quando Avahi espera uma
resposta D-Bus, o processo para automaticamente naquele ponto e prontamente retomado
assim que a resposta chega da tomada. Deve D-Bus falhar ao iniciar, por qualquer motivo,
systemd aborta o início de Bluetooth e Avahi depois de algum tempo.
Apple usa o mesmo princípio no launchd, que foi introduzido com o Mac OS X 10.4 e também
faz parte do iOS; o sistema de inicialização é pensado para ser a principal razão para os tempos
de partida significativamente mais rápidos das últimas versões do Mac OS, por causa do
lançamento de serviços em paralelo faz uso mais eficiente da CPU disponível e E / S recursos.
Em distribuições típicas SysV-init, por outro lado, os serviços são lançados em uma ordem fixa -
Bluetooth e Avahi só são lançados uma vez D-Bus, que é iniciado após Syslog, está instalado e
funcionando. Mesmo o Bluetooth co-dependente e Avahi só começam em paralelo em poucas
distribuições SysV-init, por exemplo, em algumas versões do Debian e SUSE. Os distribuidores
especificar as informações de dependência exigida nos cabeçalhos dos scripts de inicialização.
Sob demanda
Desde systemd cria e mantém o soquete, pode relançar um serviço caiu sem causar os
programas que estão conectados à tomada de perder suas conexões. Isto torna mais fácil para
atualizar os componentes do sistema, porque o kernel vai tamponar o cliente solicita que recebe
da tomada durante a reinicialização, que simplesmente permite que o novo serviço para
assumir, onde o antigo parou.
Sockets também pode ser submetido a vários programas. Systemd usa esta opção para registrar
mensagens de status, mesmo antes do sistema de arquivos raiz foi montado como gravável.
Para este efeito, ele começa um serviço de log mínimo no início do processo de inicialização;
este serviço, em seguida, simplesmente grava todas as mensagens para o buffer de log do
kernel. O serviço mínimo é necessário porque os programas só podem enviar mensagens, se
algo está escutando em /dev/log; o mini serviço será encerrado assim que o servidor Syslog real
está pronto para arrancar. O servidor Syslog assume o soquete e escreve todas previamente
submetidas mensagens do buffer de log do kernel para o disco rígido; nenhuma mensagem será
perdida, o que permite que os sistemas para registrar eventos desde o primeiro momento eles
começam a arrancar.
Unidades
As várias tarefas durante a inicialização do sistema - a criação de bases, a configuração de

hardware, montagem de dispositivos de armazenamento, começando serviços de fundo - são
organizados em "unidades". Cada tarefa que executa systemd requer um arquivo de
configuração para a unidade apropriada que só precisa conter a informação que é necessário
para esta unidade - em uma unidade de montagem, por exemplo, contém arquivo de dispositivo
do suporte de armazenamento e o diretório de destino. Esses arquivos de configuração são
significativamente mais curto do que os scripts de inicialização tradicionais. Sua sintaxe é
semelhante ao de arquivos do Windows ini.
Systemd reconhece o tipo de unidade pelo nome do arquivo da unidade. Arquivos que terminam
em .serviço criar unidades de serviço; eles lidam com serviços que as distribuições SysV baseada-
init normalmente iniciar ou terminar usando scripts de inicialização. Unidades para montar e
desmontar sistemas de arquivos terminam em .mount; o sufixo será .automount se o montador,
um componente que se monta automaticamente sistemas de ficheiros em resposta a operações
de acesso, está envolvido. Unidades que terminam em .Path permitir systemd para monitorar
os arquivos e diretórios que são especificados no arquivo unidade através inotify; quando um
acesso acontece nesse caminho, systemd começará a unidade apropriada.
Arquivos de unidade que terminam em .socket criar um ou mais soquetes para ativação do
soquete. No entanto, eles realmente não iniciar os serviços relacionados; isto irá ser feito por
uma unidade de serviço que está associado com a unidade de suportes fêmea. Quando um
pedido de ligação é recebido, systemd inicia o serviço que é definido lá, submetendo os sockets
abertos - de uma forma semelhante ao que veteranos Unix / Linux sabe de inetd.
Os arquivos da unidade que estão associados com systemd e os serviços estão localizados no /
lib / systemd / system / diretório; se um arquivo de nome idêntico existe no / etc / systemd /
system /, systemd irá ignorar o no diretório lib. Isto permite aos administradores para copiar e
personalizar um arquivo de unidade systemd sem correr o risco de que ele poderia ser
substituído durante a próxima atualização - isso pode acontecer em distribuições sysvinit se um
dos scripts de inicialização armazenada em /etc/rc.d/init.d/ foi modificado.
Systemd gera dinamicamente ele próprio certas unidades; Como resultado, essas unidades não
aparecem no sistema de arquivos, mas eles não aparecem na lista de unidade que pode ser
recuperada através systemctl. Por exemplo, uma unidade de dispositivo é gerada
automaticamente juntamente com o udev para determinados dispositivos (tais como mídia de
armazenamento, dispositivos PCI e ttys) que são marcados como TAG + = "systemd" nas regras
do udev. Semelhante ao soquete e unidade de serviço de combinação, outras unidades também
podem depender dessas unidades do dispositivo e iniciar automaticamente quando os
dispositivos que exigem que eles estão conectados. Este sistema também é usado para as
unidades .swap que são gerados automaticamente usando as informações no arquivo /etc/fstab
para configurar o espaço de troca, assim que o volume de permuta especificado aparece.
Systemd também gera unidades automáticas de montagem para vários outros dispositivos de
armazenamento que estão listados no arquivo /etc/fstab; portanto, a lista systemctl contém
mais unidades de montagem do que há arquivos da unidade de montagem.
Alvos
Arquivos que terminam em.TARGET definem grupos de unidades. Servem para chamar outras
unidades que são responsáveis por serviços, sistemas de arquivos ou outros componentes. Estas
funções permitem alvos de inicialização a serem definidos, que são equivalentes aos níveis de
execução SysV clássico. Por exemplo, a unidade multi-user.target inicia todos os serviços que
versões mais antigas do Fedora e openSUSE chamaria no nível de execução 3 - em outras
palavras, ele inicia completamente o sistema, mas sem lançar um gerenciador de login gráfico.
Este último aparece com a unidade graphical.target, tornando esta unidade o equivalente a nível
de execução 5 e o alvo padrão típico.
Quando o sistema é inicializado, systemd ativa uma unidade alvo default.target especial.
Normalmente, default.target só é usado como um alias para diferentes alvos, como
graphical.target ou multi-user.target. Alvos também pode construir ou dependem uns dos
outros; por exemplo, graphical.target vai esperar por multi-user.target para começar antes de
ser lançado a interface gráfica do usuário.
Sempre que necessário, a adição de "desejos" para os arquivos da unidade permite aos usuários
definir manualmente as dependências entre as unidades. Isso pode ser relevante para serviços
como o servidor web Apache, que espera um ambiente de rede totalmente configurada quando
é iniciado. Estes serviços devem depender do network.target. No entanto, serviços como o Avahi
ou Bind não exigem a dependência porque eles podem lidar corretamente com interfaces de
rede que aparecem ou desaparecem durante a execução.
Peças tradicionais
Por razões de compatibilidade, systemd também pode ser usado com System-V e LSB scripts de
inicialização. Esses scripts não são usados apenas para iniciar e parar serviços em distribuições
Linux com SysVinit; eles também trabalham com Upstart. Esses scripts de inicialização são
interpretados por um escudo e requerem parâmetros, tais como "start", "stop" ou "restart";
uma abordagem que tem existido desde os primeiros dias do sistema de inicialização System-V.
Os desenvolvedores de software comercial normalmente também incluem Sys-V e LSB scripts

de inicialização com seus serviços em segundo plano. Systemd gera automaticamente uma
unidade de serviço a partir deles para que possa tratá-los internamente como unidades de
serviços adequados; no entanto, a ferramenta de inicialização irá ignorar Sys-V e LSB scripts de
inicialização se ele detectar um arquivo de unidade de nome idêntico.
Grupos
Ao iniciar-los, systemd varas todos os serviços em um grupo de controle dedicado (cgroup), que
tem o nome do serviço. kernels modernos suportam esta tecnologia que isola os processos e
oferece controladores opcionais para refinar ainda mais a alocação de recursos de hardware.
Processos filhos herdam as propriedades do grupo. Isso permite que systemd para gerenciar
grupos de processos como unidades coerentes, por exemplo, para garantir que todos os
processos relacionados são interrompidos quando um serviço é desligado. Os administradores
também podem usar as interfaces cgroup normais para controlar a gama de recursos que está
disponível para um serviço; alocar manualmente processos não é mais necessário.
Abordagem ampla
Systemd inclui uma série de unidades que executam várias tarefas fundamentais durante a
inicialização do sistema. Algumas delas são dadas o mesmo formato de um serviço de fundo.
Por exemplo, quando necessário, a unidade de serviço fsck-root.service aciona uma verificação
do sistema de arquivos raiz antes de um sistema de arquivos gravável é montado por remount-
rootfs.service; hwclock-carga e hwclock-salvar ajustar o tempo para que a do relógio do sistema.
Em distribuições sysvinit e Upstart, estas e dezenas de tarefas semelhantes foram tratadas pelo
shell scripts, como /etc/rc.sysinit ou por um conjunto de pequenos scripts armazenados no
/etc/rcS.d/*. Esses scripts são altamente personalizada para cada família de distribuição e,
portanto, se comportam de forma muito diferente em Debian do que no Fedora ou openSUSE;
esta é a razão pela qual os usuários do Fedora e RHEL pode definir seus teclados em
/etc/sysconfig/keyboard, mas irá procurar em vão por este directório no Debian.
Muitas unidades Systemd iniciar programas em C que são pensados para ser mais rápido e mais
robusto do que os scripts shell que anteriormente desempenhadas essas tarefas. Ao integrar
estes serviços, systemd está tentando eliminar muitas das diferenças entre as distribuições. Isto
torna mais fácil para os desenvolvedores a fazer o seu trabalho, porque eles podem fornecer
arquivos de unidade para os seus serviços e saber que as coisas que esperar para ser incluído no
systemd. Incorporando scripts de inicialização Sys-V é muito mais difícil porque esses scripts
devem acomodar características específicas de distribuição.
Detalhes
Outras informações básicas sobre as ideias por trás systemd, bem como o seu funcionamento e
utilização, podem ser encontradas nas páginas man Systemd - systemd e systemd.conf. Tais
páginas também existem para cada um dos tipos de unidades - por exemplo para systemd.unit
ou systemd.service. Homepage do Lennart Poettering oferece links para vários artigos que
explicam o plano de fundo do sistema de inicialização, por exemplo, a série "systemd para
desenvolvedores".

MaterialComplementar V1

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

MaterialComplementar V1

Enviado por

Direitos autorais:

Formatos disponíveis

GNU/Linux - Conceitos e Comandos

Material de apio para a disciplina Gesão de serviços de redes

Primeira impressão, Fevereiro 2016

1 Revisão de conceitos e comandos . . . . . 7

1.1 Estrutura de armazenamento (espaço e inodes)

Conforme demonstrado na Fig. 1.1a, em um dado momento a execução do processo de separa-

Figura 1.1: Resultado

Lembrem-se dos conceitos que apresentamos anteriormente e que, ao observarmos o comporta-

Usuários, Grupos, Senhas e NPA.

Mapa 1 – Detalhamento de Opções do comando useradd

Mapa 2. – Detalhamento de Opções do comando userdel

Mapa 3. – Detalhamento de Opções do comando passwd

Mapa 4 – Detalhamento de Opções do comando chsh.

Mapa 5 – Detalhamento de Opções do comando chage.

Mapa 6 – Detalhamento de Opções do comando usermod.

Mapa 7 – Detalhamento de Opções do comando chfn.

Mapa 8. – Detalhamento de Opções do comando groupadd.

Mapa 10 – Detalhamento de Opções do comando gpasswd.

Tabela 11 – Detalhamento de Opções do comando groupmod.

#groupmod -g 536 suporte #groupmod -n

Mapa 13 – Detalhamento de Opções do comando id Exemplos:

Mapa 14 – Detalhamento de Opções do comando chgrp Exemplos:

#chgrp root:teste base_dados

Mapa 15 – Detalhamento de Opções do comando finger Exemplos:

Fig. 2. – Visualização de senhas encriptadas

Mas de onde saem todas essas informações ?

Mapa 16 - Detalhamento do arquivo /etc/login.defs

Mapa 17 - Detalhamento do arquivo /etc/default/useradd

drwxr-xr-x 2 root root 4096 Jan 1 2000 bin

d Indicação de que o arquivo é um diretório;

777 - 027 = 750 ( estes serão os níveis de permissão )

-R Aplica a recursividade na execução do comando.

Tabela 16 – Detalhamento de Opções do comando chmod

7 Leitura, Escrita e Execução

Tabela 16. – Comando chmod, níveis de permissão modo decimal

rwx Leitura, Escrita e Execução

Tabela 16 – Comando chmod, níveis de permissão modo simbólico

Tabela 16 – Comando chmod, níveis de permissão modos especiais Exemplos:

-R Aplica a recursividade na execução do comando.

--preserve-root Não aplica a recursividade no diretório /

-v Exibe detalhes da execução do comando. Modo verbose.

1.4 Empacotamento e compactação de arquivos (gz tgz)

-A, --catenate, --concatenate Insere novo arquivo em um pacote.

-c, --create Cria um novo pacote.

-d, --diff, --compare Verifica diferenças entre arquivos.

-r, --append Insere arquivo ao final de um arquivo tarball.

-t, --list Lista o conteúdo de um arquivo tarball.

-u, --update Apenda arquivos que foram alterados e fazem

--delete Deleta um arquivo de um pacote tarball.

-C, --directory DIR Muda o diretório.

-f, --file [HOSTNAME:]F Define o arquivo de saído do comando.

-j, --bzip2 Usa o bzip2 para compactar um arquivo tarball e o

-v, --verbose Executa em modo verbose. Detalhes de execução

--owner USER Define o usuário na extração do arquivo.

-p, --same-permissions, --preserve-permissions Mantém os níveis de acesso dos arquivos

Tabela 29 – Detalhamento de Opções do comando tar Exemplos:

-d --decompress --uncompress Descompacta o arquivo.

-r --recursive Preserva a estrutura de diretório, usando a recursividade.

-t --test Verifica a integridade do arquivo compactado.

-v –verbose Detalha a execução do comando

Tabela 30 – Detalhamento do comando gzip Exemplos:

-c --stdout Comprime e descomprime para saída padrão.

-d --decompress Força a descompressão de arquivos bz2.