GERENCIAMENTO DE SISTEMAS LINUX by ARL UFLA

Curso de Pós-Graduação “Lato Sensu” (Especialização) a Distância Administração em Redes Linux

GERENCIAMENTO DE SISTEMAS LINUX

3a Edição

Joaquim Quinteiro Uchôa

Universidade Federal de Lavras – UFLA Fundação de Apoio ao Ensino, Pesquisa e Extensão – FAEPE Lavras – MG

PARCERIA Universidade Federal de Lavras – UFLA Fundação de Apoio ao Ensino, Pesquisa e Extensão – FAEPE REITOR Antônio Nazareno Guimarães Mendes VICE-REITOR Ricardo Pereira Reis DIRETOR DA EDITORA Marco Antônio Rezende Alvarenga PRÓ-REITOR DE PÓS-GRADUAÇÃO Joel Augusto Muniz PRÓ-REITOR ADJUNTO DE PÓS-GRADUAÇÃO “LATO SENSU” Marcelo Silva de Oliveira COORDENADOR DO CURSO Joaquim Quinteiro Uchôa PRESIDENTE DO CONSELHO DELIBERATIVO DA FAEPE Luiz Antônio Lima EDITORAÇÃO Grupo Ginux (http://www.ginux.ufla.br/) IMPRESSÃO Gráfica Universitária/UFLA Ficha Catalográfica preparada pela Divisão de Processos Técnicos da Biblioteca Central da UFLA Uchôa, Joaquim Quinteiro Gerenciamento de Sistemas Linux/ Joaquim Quinteiro Uchôa. - - 3.ed. Lavras: UFLA/FAEPE, 2007. 191 p. : il. - Curso de Pós-Graduação “Lato Sensu” (Especialização) a Distância: Administração em Redes Linux. Bibliografia. 1. Administração de Sistemas. 2. Sistemas Operacionais. 3. Linux. 4. Configuração e Instalação. 5. Gerenciamento de Usuários. I. DCC II. Universidade Federal de Lavras. III. Fundação de Apoio ao Ensino, Pesquisa e Extensão. IV. Título. CDD-005.43 Nenhuma parte desta publicação pode ser reproduzida, por qualquer meio ou forma, sem a prévia autorização da FAEPE.

SUMÁRIO

1 Introdução

2 Visão Geral de um Sistema Linux

2.1 Comentários Iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.2 Breve Histórico do Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.3 O Kernel do Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.4 Aplicações Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.5 Distribuições Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.6 A Questão da Padronização . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.7 Instalação o Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.8 Obtendo Ajuda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.9 Comentários Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3 Configuração de Dispositivos

3.1 Comentários Iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.2 Obtendo Informação sobre Hardware em Linux . . . . . . . . . . . . . . . . .

3.3 Drivers e Módulos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.4 O Arquivo /etc/modules.conf

. . . . . . . . . . . . . . . . . . . . . . . .

3.5 Criação de Arquivos de Dispositivos . . . . . . . . . . . . . . . . . . . . . . .

3.6 Gerenciamento Dinâmico de Dispositivos com udev, D-Bus e HAL . . . . . .

3.7 O Diretório /etc e Configurações Básicas do Sistema . . . . . . . . . . . . .

3.8 Configuração do Locale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.9 Configuração de Rede . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.10 Modems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.11 Interface Gráfica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.11.1 Configuração do X . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.12 Impressoras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.13 Gravadores de CDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.14 Placas de Som . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.15 Outros Dispositivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Sistema de Arquivos

84 87

4.1 Comentários iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.2 Estrutura de Diretórios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.2.1 O diretório /usr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.2.2 O diretório /var . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.2.3 Outros diretórios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.3 Uso de Dispositivos de Armazenamento . . . . . . . . . . . . . . . . . . . . .

4.4 Uso de Memória Virtual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.5 Montagem de dispositivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.6 Partições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 4.7 Tipos de arquivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 4.8 Atributos de Arquivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 4.9 Comentários Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 5 Gerenciamento de Processos

115

5.1 Comentários Iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 5.2 Gerenciamento de memória em Linux . . . . . . . . . . . . . . . . . . . . . . 115 5.2.1 Swap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 5.2.2 Buffer cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 5.3 Componentes de um Processo . . . . . . . . . . . . . . . . . . . . . . . . . . 118 5.4 Sinais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 5.5 Monitoração de Processos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 5.6 Iniciando e Encerrando o Sistema . . . . . . . . . . . . . . . . . . . . . . . . 126 5.6.1 Visão Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 5.6.2 O Processo init . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 5.6.3 O Arquivo /etc/inittab . . . . . . . . . . . . . . . . . . . . . . . . 129 5.6.4 Encerramento e Reinicialização do Sistema . . . . . . . . . . . . . . . 129 5.6.5 Modo Monousuário

. . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

5.7 Gerenciamento de Serviços . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 5.8 Disquetes de Emergência . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

5.9 Gerenciadores de Boot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 5.9.1 LILO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 5.9.2 GRUB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 5.10 Comentários Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 6 Gerenciamento de Usuários

139

6.1 Comentários iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 6.2 Contas de Usuários . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 6.3 O Arquivo /etc/passwd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 6.4 Escolha de Senhas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 6.5 Senhas Sombreadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 6.6 Tipos de Contas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 6.6.1 Pseudo-Usuários . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 6.7 Grupos de Usuários . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 6.8 Variáveis de Ambiente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 6.9 Uso de Quotas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 6.10 Criando e Alterando Contas de Usuários . . . . . . . . . . . . . . . . . . . . . 157 6.11 Remoção e Desabilitação de Usuários . . . . . . . . . . . . . . . . . . . . . . 159 6.12 Tornando-se root . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 6.13 PAM (Pluggable Authentication Modules) . . . . . . . . . . . . . . . . . . . . 162 6.14 Configuração Básica do PAM . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 6.14.1 Usando o Arquivo /etc/pam.conf . . . . . . . . . . . . . . . . . . . 165 6.14.2 Utilizando o Diretório /etc/pam.d

. . . . . . . . . . . . . . . . . . . 166

6.14.3 Configurando o Parâmetro /etc/control-flag . . . . . . . . . . . 167 6.14.4 Exemplo de Configuração de um Serviço via Linux-PAM . . . . . . . . 168 6.15 Comentários Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 7 Configurações Diversas

173

7.1 Arquivos de Registro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 7.2 Gerenciamento de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 7.3 Automatizando tarefas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 7.3.1 O uso do cron . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179

7.3.2 O uso do at . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 7.4 Cópias de Segurança . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 7.5 Configuração de Data e Hora . . . . . . . . . . . . . . . . . . . . . . . . . . . 184 Referências Bibliográficas

187

LISTA DE FIGURAS

2.1 Camadas Típicas de um Sistema Operacional Baseado em UNIX . . . . . .

2.2 Xfce Rodando AbiWord, Gnumeric, GIMP e XMMS . . . . . . . . . . . . . . .

2.3 Processador de Texto do OpenOffice . . . . . . . . . . . . . . . . . . . . . . .

2.4 Navegador Firefox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.5 Editor Vetorial Inkscape . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.6 Player Multimídia Audacious . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.7 Jogo Bzflag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.8 Editores de Código . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.9 Editor Bluefish . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.10 Execução do Comando man . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.11 Execução do pinfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.1 Trechos de Saída do dmesg . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.2 Exemplo de Saída do lspci . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.3 Exemplo de Saída do lsusb . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.4 Trecho de Saída do lshal . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.5 Obtendo Informações de Hardware com o hal-device-manager

. . . . .

3.6 Arquivo /proc/interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.7 Arquivo /proc/cpuinfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.8 Obtendo Informações de Hardware via sysfs . . . . . . . . . . . . . . . . . .

3.9 Exemplo de Uso do systool . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.10 Exemplo de Uso do dmidecode . . . . . . . . . . . . . . . . . . . . . . . . .

3.11 Módulos Carregados e em Uso . . . . . . . . . . . . . . . . . . . . . . . . . .

3.12 Arquivo /etc/modules.conf . . . . . . . . . . . . . . . . . . . . . . . . . .

3.13 Uso do Comando makedev . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.14 Exibindo Informações de um Dispositivo . . . . . . . . . . . . . . . . . . . . .

3.15 Exemplo de Uso do Comando mknod . . . . . . . . . . . . . . . . . . . . . .

3.16 Trecho de listagem do Diretório /dev com uso do udev . . . . . . . . . . . .

3.17 Trechos do Diretório /etc/sysconfig . . . . . . . . . . . . . . . . . . . . .

3.18 Trechos do Diretório /etc/conf.d . . . . . . . . . . . . . . . . . . . . . . .

3.19 Exemplo de Uso dos Comandos loadkeys e setfont . . . . . . . . . . . .

3.20 Uso do comando locale . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.21 Exemplos de Uso dos Comando ifconfig e ip . . . . . . . . . . . . . . . .

3.22 Exemplo de Arquivo resolv.conf . . . . . . . . . . . . . . . . . . . . . . .

3.23 Seção Module do /etc/X11/xorg.conf . . . . . . . . . . . . . . . . . . .

3.24 Seção Files do /etc/X11/xorg.conf . . . . . . . . . . . . . . . . . . . .

3.25 Seção InputDevice do /etc/X11/xorg.conf . . . . . . . . . . . . . . .

3.26 Seções Monitor e Device do /etc/X11/xorg.conf

. . . . . . . . . . .

3.27 Seção Screen do /etc/X11/xorg.conf . . . . . . . . . . . . . . . . . . .

3.28 Exemplo de Comandos de Impressão . . . . . . . . . . . . . . . . . . . . . .

3.29 Um Exemplo de Arquivo /etc/printcap . . . . . . . . . . . . . . . . . . .

3.30 Configurando o CUPS via Navegador . . . . . . . . . . . . . . . . . . . . . .

3.31 Configurando Impressora no CUPS . . . . . . . . . . . . . . . . . . . . . . .

3.32 Arquivo /etc/printers.conf . . . . . . . . . . . . . . . . . . . . . . . . .

3.33 Exemplos de DeviceURI . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.34 Exemplos de Uso do lpoptions

. . . . . . . . . . . . . . . . . . . . . . . .

3.35 Exemplo de Uso do cdrecord . . . . . . . . . . . . . . . . . . . . . . . . . .

4.1 Árvore Raiz de Diretórios . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.2 Árvore de Diretórios em /usr . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.3 Árvore de Diretórios em /var . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.4 Encadeamento de I-nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.5 Hard Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.6 Exemplo de /etc/fstab . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.7 Exemplo de Uso de Sockets . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 4.8 Uso do Comando file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 4.9 Atributos de Permissão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 4.10 Exemplos de uso do chmod . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 4.11 Cálculo de permissões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 4.12 Uso do umask . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

5.1 Script que Cria uma Árvore de Diretórios Extremamente Profunda . . . . . . 126 5.2 Arquivo /etc/inittab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 5.3 Exemplo de /etc/lilo.conf . . . . . . . . . . . . . . . . . . . . . . . . . . 135 5.4 Arquivo /boot/grub/menu.lst . . . . . . . . . . . . . . . . . . . . . . . . 137 6.1 Sistema Multiusuário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 6.2 Trecho do arquivo /etc/passwd . . . . . . . . . . . . . . . . . . . . . . . . . 142 6.3 Codificação de Senhas em Linux . . . . . . . . . . . . . . . . . . . . . . . . . 143 6.4 Codificação de Senhas Usando DES e MD5

. . . . . . . . . . . . . . . . . . 143

6.5 Exemplo de uso Comando passwd . . . . . . . . . . . . . . . . . . . . . . . . 143 6.6 Decodificação de Senhas em Linux

. . . . . . . . . . . . . . . . . . . . . . . 144

6.7 Uso do Campo GECOS pelo finger . . . . . . . . . . . . . . . . . . . . . . 145 6.8 Trecho do Arquivo /etc/shadow . . . . . . . . . . . . . . . . . . . . . . . . 147 6.9 Execução do Comando chage -l jsilva . . . . . . . . . . . . . . . . . . 149 6.10 Execução do Comando chage jsilva . . . . . . . . . . . . . . . . . . . . . 149 6.11 Arquivo /etc/group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 6.12 Usos dos Comandos id e newgrp . . . . . . . . . . . . . . . . . . . . . . . . 152 6.13 Editando a quota de um usuário . . . . . . . . . . . . . . . . . . . . . . . . . 155 6.14 Editando a quota de um usuário . . . . . . . . . . . . . . . . . . . . . . . . . 156 6.15 Execução do Comando repquota -a . . . . . . . . . . . . . . . . . . . . . 161 6.16 Funcionamento do PAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 6.17 O Arquivo /etc/pam.d/system-auth . . . . . . . . . . . . . . . . . . . . . 169 6.18 Exemplo de Configuração do pam_access . . . . . . . . . . . . . . . . . . . 169 7.1 Script para Implementar Rotação de Logs . . . . . . . . . . . . . . . . . . . . 174 7.2 Script para Implementar Rotação de Logs Usando Sinais . . . . . . . . . . . 174 7.3 Exemplo de um Arquivo /etc/syslog.conf . . . . . . . . . . . . . . . . . 175 7.4 Exemplo de crontab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 7.5 Exemplo de /etc/crontab . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 7.6 Exemplos de Uso do Comando at . . . . . . . . . . . . . . . . . . . . . . . . 183 7.7 Configurando Data e Hora . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184

LISTA DE TABELAS

3.1 Divisão do endereço IP e Classes . . . . . . . . . . . . . . . . . . . . . . . .

3.2 Variáveis do Arquivo /etc/printcap . . . . . . . . . . . . . . . . . . . . . .

3.3 Variáveis do Arquivo /etc/cups/printers.conf . . . . . . . . . . . . . .

4.1 Principais Comandos Associados aos Dispositivos de Armazenamento . . .

4.2 Nomenclatura de Dispositivos Usuais . . . . . . . . . . . . . . . . . . . . . .

4.3 Principais Opções Utilizadas no fstab . . . . . . . . . . . . . . . . . . . . . 100 4.4 Símbolos Associados ao Tipo de Arquivo ao Utilizar o “ls -l” . . . . . . . . 110 4.5 Valores Possíveis ao Campo Destinado ao Atributo de Execução . . . . . . . 111 5.1 Sinais Comuns Utilizados em Ambientes UNIX-like . . . . . . . . . . . . . . . 121 5.2 Informações Exibidas na Saída do Comando ‘ps aux’ . . . . . . . . . . . . . 124 5.3 Notações Utilizadas pelo Campo STAT . . . . . . . . . . . . . . . . . . . . . . 124 5.4 Campos da Saída do ‘ps lax’ que Diferem da Execução do ‘ps -aux’ . . . 125 5.5 Arquivos Importantes de Configuração do Kernel Localizados no /proc . . . 127 5.6 Modos de Iniciação de Sistemas Derivados do UNIX . . . . . . . . . . . . . . 128 5.7 Possíveis Ações do Campo Action do inittab

. . . . . . . . . . . . . . . 130

5.8 Principais Comandos a Serem Utilizados em /boot/grub/menu.lst . . . 136 6.1 Alguns Pseudo-Usuários Comuns . . . . . . . . . . . . . . . . . . . . . . . . 151 6.2 Variáveis de Ambiente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 6.3 Opções do Comando useradd . . . . . . . . . . . . . . . . . . . . . . . . . . 158 6.4 Argumentos Padrões do PAM . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 7.1 Recursos do syslog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 7.2 Recursos do syslog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 7.3 Formas de Uso do Comando rpm . . . . . . . . . . . . . . . . . . . . . . . . 177 7.4 Definição dos Campos do crontab . . . . . . . . . . . . . . . . . . . . . . . 180 7.5 Opções Usuais do Comando crontab . . . . . . . . . . . . . . . . . . . . . 180 7.6 Opções do Comando at . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182

7.7 opĂ§Ăľes vĂĄlidas para o campo momento do comando at . . . . . . . . . . . . 183

1 INTRODUÇÃO

Este texto tem por principal objetivo instruir o seu leitor nos passos básicos necessários à configuração e gerenciamento de uma estação Linux. Por estação, em geral, compreende-se qualquer computador que esteja direcionado ao usuário final. Isso implica que, na maioria dos casos, um servidor não é considerado uma estação. A esse processo de gerenciamento de uma estação, também dá-se o nome de administração de sistemas: Administração de sistemas é o conjunto de tarefas necessárias para manter o computador em boas condições de uso. Isso inclui atividades como efetuar cópias de segurança (e restaurá-las, se necessário), instalar novos programas, criar contas de usuários (e apagá-las quando não mais forem necessárias), garantir que os sistemas de arquivos estejam íntegros, e assim por diante. Se um computador fosse, por exemplo, uma casa, a administração de sistemas poderia ser comparada à manutenção, a qual inclui a limpeza, o conserto de vidraças quebradas e outras tarefas do gênero. (WIRZENIUS et al., 2005).

Seguindo essa abordagem, esta obra pretende orientar o usuário nos passos necessários à uma adequada configuração de um computador individual para uso pessoal. Dessa maneira, não será abordado aqui a configuração de nenhum serviço de rede. A única e óbvia excessão será a configuração de acesso a rede, i.e., a configuração dos dispositivos e endereçamento de rede. Mas não será abordado, por exemplo, configuração de servidor de e-mail ou servidor Web. A configuração e o gerenciamento de uma estação Unix envolve várias etapas, envolvendo configuração de dispositivos, gerenciamento de processos e usuários, entre outros. Nesse sentido, o texto foi organizado de forma que o leitor possa abordar cada aspecto de configuração individualmente. Cada capítulo foi pensado de forma que possa ser lido individualmente, mas fazendo parte de um todo organizado e dirigido. Inicialmente, o Capítulo 2 apresenta uma visão geral de um sistema Linux, definindo, entre outros, o que é o Linux e o que é uma distribuição. Além disso, um breve histórico do Linux é apresentado, bem como os seus principais usos e aplicações.

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

A configuração de dispositivos diversos é vista no Capítulo 3. Esse capítulo apresenta os passos básicos para a configuração de dispositivos comuns, como placas de vídeo, dispositivos multimídia e impressoras. Uma atenção especial é dada para interfaces de redes, em especial placas Ethernet, Wireless e modems. O Capítulo 4 apresenta a árvore de diretórios do Linux, sob a perspectiva do Filesystem Hierarchy Standard (FHS) (RUSSELL; QUINLAN, 2001). Além disso, esse capítulo aborda a configuração de partições, sistemas de arquivos e pontos de montagem. Uma atenção extra é dada ao uso de memória virtual (swap). O gerenciamento de processos é visto em detalhes no Capítulo 5. Entre outros itens, abordados nesse capítulo, encontram-se: os componentes de um processo, o uso de sinais e os comandos top, nice, renice, ps e kill. Um assunto bastante explorado é a inicialização e o encerramento do sistema operacional. Esse capítulo foi escrito com o auxílio de Fernando Cortez Sica, bacharel em Ciência da Computação pela Universidade Estadual Paulista (UNESP), campus de Bauru/SP, mestre em Engenharia Elétrica pela UNICAMP e doutorando em Ciência da Computação pela UFMG. Esses capítulos abordam os mecanismos básicos para a configuração de uma estação sob o ponto de vista de uso do equipamento. De nada adianta, entretanto, uma estação totalmente operacional sem um gerenciamento adequado de seus usuários, o que é explanado em profundidade no Capítulo 6. Além do processo de manutenção geral dos usuários (criação, manutenção, etc.), o capítulo também apresenta o Pluggable Authentication Modules (PAM) (MORGAN, 2002), (SAMAR; SCHEMERS, 1995), (MORGAN, 2001), que é o mecanismo de autenticação utilizado por padrão no Linux. Outras configurações da estação, mas não menos importantes, são vistas no Capítulo 7. Esse capítulo aborda, entre outros, como automatizar tarefas ou acertar data e hora. Também são explanados os mecanismos de registros de atividades (logs), bem como maneiras simples de se fazer cópias de segurança de arquivos e diretórios. Este texto foi escrito pensando em um usuário básico do sistema operacional Linux (ou equivalente). Ele foi produzido principalmente a partir da experiência adquirida pelos autores em administração de laboratórios e uso de diversos sistemas operacionais. Essa experiência em administração de sistemas foi enriquecida pela leitura de diversos materiais, destacando-se, principalmente: (NEMETH et al., 1995), (NEMETH et al., 2001), (STANFIELD; SMITH, 2001), (WIRZENIUS et al., 2005), (FRAMPTON, 1999), (MANN; MITCHELL,

Introdução

2000), (ANONYMOUS, 2000), (FRAMPTON, 1999). A essas referências devem ser acrescidos vários Howtos1 disponibilizados pela The Linux Documentation Project 2 . Joaquim Quinteiro Uchôa, autor deste texto, é licenciado em Matemática pela Universidade Federal de Mato Grosso (UFMT), com mestrado em Ciência da Computação pela Universidade Federal de São Carlos (UFSCar). Antes de adotar o Linux, em 1998, já havia trabalhado com Solaris, MS-DOS (lembram-se do CISNE?) e OS/2, passando, obviamente pelos Windows 2.0, Windows 3.1 (e 3.11) e Windows 95. Segundo amigos, ele já superou o trauma do uso desses três últimos SOs(?), apesar de ter desenvolvido aversão a alguns tipos de janelas. Foi o responsável pela instalação do primeiro laboratório baseado em Linux na UFLA e um dos maiores disseminadores desse sistema operacional na universidade, tendo sido o principal responsável pela criação do curso de especialização em Administração em Redes Linux (ARL). Professor da UFLA, desde 1997, atua principalmente nas áreas de Teoria da Computação, Inteligência Artificial, Segurança Computacional e Educação a Distância. O autor sentira realizado com a escrita desta obra se ela contribuir para disseminar ainda mais o uso de Linux no Brasil e deseja um bom aprendizado ao leitor.

1 Um

Howto é um pequeno guia que ensina um usuário a configurar um serviço ou fazer uma dada tarefa. Linux Documentation Project: http://www.tldp.org/. A tradução de parte dos documentos desse projeto podem ser encontrados em http://br.tldp.org/. 2 The

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

2 VISÃO GERAL DE UM SISTEMA LINUX

2.1

COMENTÁRIOS INICIAIS

Linux pode ser definido como um sistema operacional multitarefa e multiusuário que teve o seu desenvolvimento voltado, inicialmente, para plataformas computacionais baseadas nos processadores da linha Intel (computadores pessoais do tipo PC). Entretanto, diversas distribuições atuais incluem outras plataformas tais como SPARC, sistemas embarcados (embedded systems) e dispositivos móveis. Como ponto de partida, o Linux teve sua concepção baseada no padrão UNIX1 quanto ao comportamento de seu kernel, interfaces e modelos de abstração e de acesso aos periféricos. Porém, ao Linux foram adicionadas novas funcionalidades de modo a torná-lo versátil e funcional quanto aos requisitos impostos pelas aplicações e equipamentos de hardware atuais. Dessa forma, o Linux incorpora, como características principais, a flexibilidade, a confiabilidade, a robustez e o alto nível frente ao seu desempenho computacional. Mesmo tendo como ponto de partida o UNIX, o Linux não segue especificamente a um padrão, ou seja, representa uma fusão dos padrões BSD Unix2 e System V3 em função de suas características primordiais. Porém apresenta obediência aos padrões POSIX4 , ANSI5 , IETF6 e W3C7 . Em relação à manipulação de sistemas de arquivos, o Linux suporta vários padrões, tais como: ext3, ext2, ntfs, cdromfs, os/2, fat, fat32, hpfs e vfat. O suporte a vários tipos de sistema de arquivos torna-se altamente atraente quando se trabalha, por exem1 UNIX:

www.unix.org/. A especificação UNIX atual encontra-se descrita em (THE OPEN GROUP,

2004). 2 BSD Unix: www.en.wikipedia.org/wiki/BSD. 3 System V: http://en.wikipedia.org/wiki/SystemV. 4 POSIX: http://www.pasc.org/. 5 ANSI: http://www.ansi.org/. 6 IETF: http://www.ietf.org/. 7 W3C: http://www.w3.org/.

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

plo, com equipamentos dotados de discos rígidos particionados para a carga de diversos sistemas operacionais. Um outro ponto de atratividade do Linux baseia-se no fato de que o seu pacote de distribuição conta com ferramentas para a implementação e teste de aplicativos (compiladores e depuradores C/C++, Fortran, Pascal, Lisp, Perl, Smalltalk e outros), gerenciadores de sistemas de banco de dados (como o PostgreSQL e o MySQL), servidores de HTTP (por exemplo, o Apache), diversos serviços de rede (tais como e-mail, NIS, Samba, DNS, roteamento, impressão, firewall e FTP), interfaces gráficas baseadas no padrão X-Windows (como o GNOME, KDE e Xfce), ferramentas de administração de sistemas (como o edquota e useradd) e diversas outras aplicações que abrangem distintas áreas da informática. Atualmente, uma grande atenção está se dando aos sistemas baseados em Linux devido à facilidade de criação de clusters de processamento, obtendo-se assim, máquinas para processamento paralelo. Estas formadas por computadores pessoais interconectados por intermédio de uma rede de comunicação de dados. Além disso, outro grande interesse é a facilidade de uso do Linux como plataforma de virtualização, para execução de sistemas operacionais hospedeiros.

2.2

BREVE HISTÓRICO DO LINUX

O Linux foi desenvolvido por Linus Torvalds (nascido em dezembro de 1969 em Helsinki - Finlândia) durante sua graduação na Universidade de Helsinki. Interessado no sistema Minix, Linus decidiu desenvolver um sistema para computadores do tipo PC que excedesse a sua funcionalidade (TORVALDS; DIAMOND, 2001). A primeira versão disponível (versão 0.02) foi lançada em 1991 e, em 1994 o kernel versão 1.0 foi finalmente lançado. No momento da edição desta apostila (setembro de 2007), anuncia-se a disponibilidade da versão “beta” 2.6.23-rc6. Linux é desenvolvido sob GNU General Public License8 , permitindo-se o acesso ao seu código (open source). Mesmo baseado em versões do UNIX, o Linux não utiliza código de sistemas UNIX (os sistemas UNIX são comerciais), evitando-se assim a incorporação de taxas e licenças vinculadas a tais sistemas, tendo por conseqüência a sua propagação a custo mínimo. Porém existem distribuições comerciais de Linux, principalmente no caso de incorporação de funcionalidades específicas para, por exemplo, operações críticas. Exemplos de tais distribuições serão ilustrados mais adiante neste capítulo.

8 GPL:

http://www.gnu.org/licenses/gpl.html.

Visão Geral de um Sistema Linux

Parte do sucesso do Linux deve-se à existência de uma oportunidade histórica criada pelas incertezas legais quanto ao copyright de Unix na época de seu lançamento. Por causa dessas pendências, desenvolvimentos do BSD para a arquitetura i386 foram interrompidos por um certo período. Isso fomentou a migração de vários sistemas baseados em BSD para o kernel do Linux nessa época. Outro motivo do sucesso do Linux foi a adoção de uma metodologia de desenvolvimento extremamente livre, como descrito em (RAYMOND, 1999). Isso permitiu que vários desenvolvedores se juntassem ao projeto, o que foi em parte facilitado pela evolução da internet à época. Hoje o Linux ocupa posição de destaque e respeito no mercado de software, sendo apontado como um dos melhores exemplos de possibilidade de sucesso em projetos colaborativos distribuídos, ao lado da Wikipedia9 . Ele tem sido adotado não somente pela comunidade de software livre, mas por várias empresas, como a IBM. Recentemente temse assistido cada vez mais o surgimento de cordos comerciais entre grandes empresas de informática envolvendo o Linux, inclusive empresas que antes tomavam o Linux como um feroz inimigo a ser combatido. Um exemplo são os acordos comerciais entre a Novell e Microsof envolvendo interoperabilidade entre o Linux e o Windows, seu principal compelidor no mercado geral de SOs.

2.3

O KERNEL DO LINUX

O kernel (ou núcleo) de um sistema operacional representa a codificação responsável pelo gerenciamento do processamento em seu mais baixo nível de abstração. Tal processamento ocorre de forma segura e restrita aos usuários. O acesso, pelos usuários, às funções que compõem o kernel se dá por intermédio de interfaces bem definidas (interfaces de chamadas de sistema - system call interface). Para melhor diferenciar o kernel frente aos aplicativos desenvolvidos pelos usuários, a Figura 2.1 ilustra as camadas típicas de um sistema operacional baseado em UNIX (TANENBAUM, 1992). Como funcionalidades típicas de um kernel de um sistema operacional, podem ser citadas as seguintes: • criação e término de processos (instanciação e remoção de estruturas internas e transferência para memória e desalocação de espaços previamente alocados na RAM); • escalonamento e controle de processos; • sincronização de processos e suporte a comunicação inter-processos; 9 Wikipedia:

http://www.wikipedia.org/.

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

Usuários

Interface do Usuário

Aplicativos e Programas dos Usuários

Interface das Bibliotecas Interface de Chamadas de Sistema

Modo Usuário

Funções das bibliotecas padrão (open, close, read, write, fork, etc.)

Modo Kernel

Kernel − gerenciamento de processos, memória sistemas de arquivos, I/O, etc. Hardware − CPU, memória, discos, terminais, etc.

Figura 2.1: Camadas Típicas de um Sistema Operacional Baseado em UNIX

• gerenciamento de blocos de controle de processos (process control blocks - PCB); • alocação de espaço de endereçamento aos processos; • swapping; • gerenciamento de páginas e segmentos; • gerenciamento de buffers de I/O; • alocação de canais de I/O e de devices aos processos; • manipulação de interrupções; • monitoramento do sistema. O kernel do Linux foi desenvolvido, originalmente, para ser executado em modo protegido de um processador Intel 80386. Tal processador era subtilizado pelos sistemas operacionais DOS devido ao fato de que foram projetados com instruções para suporte a multitarefa (multitasking). Dentre as características do kernel do Linux, podem ser destacadas as seguintes: a) permite copy-on-write – tal processo consiste na utilização de códigos executáveis compartilhados, ou seja, caso haja várias instâncias de um certo programa, o seu código é carregado na memória apenas uma única vez, permitindo-se, desta forma, uma utilização mais eficiente da memória; b) utilização de unified memory pool – essa técnica permite que todo o espaço livre da RAM seja utilizado como cache de disco;

Visão Geral de um Sistema Linux

c) suporte a demand paging – isso denota que apenas as seções necessárias de um programa são carregadas na memória RAM, permitindo-se a manipulação mais eficiente de um número maior de processos; d) utilização intensa de dynamically shared libraries (DLLs) – mapeamento das bibliotecas dinâmicas em uma região específica da memória denominada commom library section, implicando na redução do tamanho do código das aplicações uma vez que as funções da biblioteca não são link -editadas ao restante da codificação. Mas, para manter compatibilidade e, em certos casos, conveniência, o Linux também admite a utilização de bibliotecas estáticas. É conveniente citar que a atualização do kernel do Linux pode ser realizada através de sua compilação, nova instalação ou através da aplicação de patches.

2.4

APLICAÇÕES LINUX

Diversos aplicativos podem ser encontrados atualmente para Linux, desde aplicativos de uso residencial e pessoal até aqueles utilizados por empresas de modo geral. Dentre estes aplicativos, podem ser encontradas as seguintes classes: Gerenciadores de Janelas: Gerenciadores de Janela são aplicativos responsáveis por controlar a interface gráfica do usuário. Assim, em uma mesma instalação Linux, é possível haver uma interface gráfica totalmente distinta de um usuário para outro. Os mais conhecidos e usados por usuários iniciantes são com certeza o KDE10 e o GNOME11 . Mas existem várias alternativas, como pode ser verificado em http: //xwinman.org/. Merecem destaques os gerenciadores “leves”, que exigem pouco do equipamento. Esses gerenciadores oferecem, é óbvio, menos recursos que os mais pesados, mas oferecem o suficiente para um uso prazeirozo do ambiente gráfico do Linux, mesmo em máquinas de menor desempenho. Nesse sentido, merecem destaque o Window Maker12 , desenvolvido em sua maior parte por um brasileiro, e o Xfce13 , um gerenciador extremamente leve e funcional, como ilustra a Figura 2.2. Aplicativos de Escritório: Os aplicativos de escritório (editores e processadores de texto, planilhas eletrônicas e software de apresentação) representam uma boa porcentagem em relação à utilização dos computadores. Em alguns casos, esses aplicativos 10 KDE:

http://www.kde.org/. http://www.gnome.org/. 12 Window Maker: http://www.windowmaker.info/. 13 Xfce: http://www.xfce.org/. 11 GNOME:

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

Figura 2.2: Xfce Rodando AbiWord, Gnumeric, GIMP e XMMS

são agrupados, formando suítes. Entre as suítes disponíveis para Linux, merecem destaque o Gnome Office14 , o Koffice15 , e, principalmente o OpenOffice.org16 . Na Figura 2.3, pode ser visualizado o processador de texto do OpenOffice.org, que é bastante poderoso em termos de recursos. Entre os editores de texto distribuídos isoladamente, pode ser citado o AbiWord17 , um editor extremamente leve. Além dos editores, existem também os visualizadores como o Acrobat Reader18 , Xpdf19 e o Evince20 que permitem abrir aquivos PDF. Entre as planilhas eletrônicas, merece destaque o Gnumeric. Ainda nesse item, não pode ser

14 Gnome

Office: http://www.gnome.org/gnome-office/. http://www.koffice.org/. 16 OpenOffice.org: http://www.openoffice.org/. Por questões legais, no Brasil a versão adaptada do OpenOffice ao idioma português chama-se BrOffice.org (http://www.broffice.org/. 17 AbiWord: http://www.abisource.com/ 18 Acrobat Reader: http://www.adobe.com/br/. 19 Xpdf: http://www.foolabs.com/xpdf/. 20 Evince: http://www.gnome.org/projects/evince/. 15 Koffice:

Visão Geral de um Sistema Linux

Figura 2.3: Processador de Texto do OpenOffice

esquecido o LATEX21 , um poderoso sistema de editoração eletrônica utilizado na produção desta apostila. Existem ainda editores de diagramas, como o Dia22 , e aplicativos para controle financeiro, como o KmyMoney223 ou o Gnucash24 . Clientes Internet: É possível valer-se de uma grande diversidade de navegadores internet em Linux, como: SeaMonkey25 , Galeon26 e Firefox27 , mostrado na Figura 2.4. Mas também não podem ser esquecidos o Konqueror28 e o Opera29 , ou mesmo clientes em modo texto, como o Lynx30 , Links31 ou Elinks32 . Exitem também clientes de mensagens instantâneas, como o Pidgin33 . Entre os clientes de e-mail, podem ser destacados o Thunderbird34 e o Evolution35 . Para acesso 21 LAT

EX: http://www.latex-project.org/. http://live.gnome.org/Dia. 23 KmyMoney2: http://kmymoney2.sourceforge.net/index-home.html. 24 Gnucash: http://www.gnucash.org/. 25 SeaMonkey: http://www.mozilla.org/projects/seamonkey/. 26 Galeon: http://galeon.sourceforge.net/. 27 Firefox: http://www.mozilla.com/en-US/firefox/. 28 Konqueror: http://www.konqueror.org/. 29 Opera: http://www.opera.com/. 30 Lynx: http://lynx.isc.org/. 31 Links: http://links.twibright.com/. 32 Elinks: http://elinks.or.cz/. 33 Pidgin: http://www.pidgin.im/. 34 Thunderbird http://www.mozilla.com/en-US/thunderbird/. 35 Evolution: http://www.gnome.org/projects/evolution/. 22 Dia:

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

Figura 2.4: Navegador Firefox

à rede IRC, é possível utilizar-se do Irssi36 ou o XChat37 . Como clientes FTP, podem ser citados o NcFTP38 ou o gFTP39 , que suporta, inclusive, conexão segura via SSL. Editores Gráficos: Para edição gráfica de arquivos bitmap, nos mais variados formatos (como GIF, PNG ou JPEG), é possível valer-se do GIMP40 , um poderoso editor de imagens, comparado freqüentemente ao Adobe Photoshop. Para edição vetorial, a escolha geralmente recai sobre o Inkscape41 , apresentado na Figura 2.5, ou QCad42 . Não se pode esquecer o ImageMagick43 , um conjunto de utilitários para conversão e tratamento de imagens. Entre os visualizadores, podem ser citados o GQview44 e o gThumb45 . 36 Irssi:

http://irssi.org/. http://www.xchat.org/. 38 NcFTP: http://www.ncftp.com/. 39 gFTP: http://gftp.seul.org/. 40 GIMP: http://www.gimp.org/. 41 Inkscape: http://www.inkscape.org/. 42 QCad: http://www.ribbonsoft.com/qcad.html. 43 ImageMagick http://www.imagemagick.org/. 44 GQview: http://gqview.sourceforge.net/. 45 gThumb: http://gthumb.sourceforge.net/. 37 XChat:

Visão Geral de um Sistema Linux

Figura 2.5: Editor Vetorial Inkscape

Aplicativos Multimídia: Existem diversos aplicativos multimídia em Linux, sendo o mais conhecido o XMMS (X Multimedia System), um excelente visualizador multimídia. Ele suporta arquivos de CD de áudio, MP3, Vorbis e inclusive arquivos de vídeo no formato MPEG. Recentemente, seus usuários tem migrado para um de seus forks, o Audacious46 , ilustrado na Figura 2.6. Entre os visualizadores de vídeo, inclusive com suporte a DVD, merecem destaque o Xine47 , o MPlayer48 e o VLC49 . Também existe uma versão do Real Player50 para Linux. Aplicativos de Entretenimento: Atualmente a oferta de jogos para Linux vem aumentando de forma bastante satisfatória, o que pode ser confirmado visitando os site: The Linux Game Tome51 ou Linuxgames52 Jogos comerciais, como Unreal Tournament53 , já possuem versões para Linux. Mas também existem soluções gratuitas de alto nível, 46 Audacious:

http://audacious-media-player.org/Main_Page. http://xinehq.de/. 48 MPlayer http://www.mplayerhq.hu/. 49 Videolan http://www.videolan.org/. 50 Real Player: http://www.real.com/linux/. 51 The Linux Game Tome: http://happypenguin.org/. 52 Linuxgames: http://www.linuxgames.com/. 53 Unreal Tournament: http://www.epicgames.com/. 47 Xine:

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

Figura 2.6: Player Multimídia Audacious

como o Freeciv54 e Glest55 ou mesmo Doom e Quake56 . A Figura 2.7 mostra uma tela extraída de uma partida de Bzflag. Emuladores: O Linux também oferece a possibilidade de executar aplicativos construídos para outras plataformas como o DOS e o Windows. Tal possibilidade é oferecida pelos emuladores, tais como: o DOSEMU57 e Wine58 . Existem também emuladores plataformas de jogos, objetivando entretenimento, como: o Snes9x59 , emulador de Super Nintendo, e Xmame60 , um emulador para vários arcades, como o Atari. Gerenciadores de Banco de Dados: os gerenciadores de banco de dados (SGBDs) permitem a construção e manutenção de bases de dados afim de armazenar diversos tipos de informações. Dentre os SGBDs, os mais comuns utilizados atualmente são aqueles voltados ao modelo relacional e ao modelo orientado a objetos. Como exemplos do primeiro modelo, podem ser destacados os aplicativos PostgreSQL61 , 54 Freeciv:

http://freeciv.wikia.com/. http://www.glest.org/. 56 Doom e Quake são produtos da ID Software: http://www.idsoftware.com/. 57 DOSEMU: http://dosemu.sourceforge.net/. 58 Wine: http://www.winehq.com/. 59 Snes9x: www.snes9x.com. 60 Xmame: http://x.mame.net/. 61 PostgreSQL: http://www.postgresql.org/. 55 Glest:

Visão Geral de um Sistema Linux

Figura 2.7: Jogo Bzflag

MySQL62 , Oracle63 , Sybase64 , Firebird65 e DB266 e, em relação aos orientados a objetos, tem-se Shore67 e Zope68 . Cabe observar ainda que O PostgreSQL implementa, além do modelo relacional padrão, algumas características e recursos de orientação a objeto. Linguagens de programação: para as pessoas que desenvolvem aplicativos, o Linux conta com uma gama muito vasta de compiladores e interpretadores para diversas linguagens de programação, tais como: C/C++, Fortran, Python, Perl, Modula-3, Prolog, TCL/TK, Smalltalk e Pascal. Merece destaque o GCC69 , um conjunto de diversos compiladores. Desenvolvimento de aplicações: associado às linguagens, existem aqueles aplicativos úteis para o desenvolvimento de aplicativos visando, por exemplo, o controle de ver62 MySQL:

http://www.mysql.org/. http://www.oracle.com/. 64 Sybase: http://www.sybase.com/. 65 Firebird: http://www.firebirdsql.org/. 66 IBM DB2: http://www-306.ibm.com/software/data/db2/. 67 Shore: www.cs.wisc.edu/shore. 68 Zope: http://www.zope.org/. 69 GCC (GNU Compiler Collection): http://gcc.gnu.org/. 63 Oracle:

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

sões e o controle de bugs e a depuração dos mesmos. Dentro do campo de controle de versões, existem o CVS70 , o Subversion71 e o Git72 . Em relação ao controle de bugs e à depuração (debug) encontram-se o Bugzilla73 , GNATS74 , GVD75 , DDD76 e o GDB77 . Entre os editores de código, além dos tradicionais Emacs78 , XEmacs79 e vi80 , merecem destaque Anjuta81 , Glimmer82 , Eclipse83 e Code::Blocks84 . A Figura 2.8 mostra os editores XEmacs, Anjuta e Glimmer usados para edição de código C++ ou LATEX. Para desenvolvimento de aplicações Web, é possível valer-se de ferramentas poderosas, como o PHP85 , uma linguagem interpretada no servidor, com facilidades de acesso a Bases de Dados. Para edição de código HTML, é possível valer-se do Nvu86 ou do Seamonkey Composer87 , editores gráficos. Caso se pretenda uma edição pura de código, é possível utilizar os editores de código já comentados, ou utilizar o SCREEM88 ou o Bluefish89 , um editor HTML extremamente funcional, como ilustrado na Figura 2.9. Serviços de Rede: existem diversas sub-classes dentro dos aplicativos de rede, tais como servidores de correio eletrônico (por exemplo, Sendmail90 , Postfix91 e Exim92 ), servidor HTTP (Apache93 ), gerenciadores de listas de discussão (mlmmj94 , Mailman95 ), 70 CVS:

http://www.nongnu.org/cvs/. http://subversion.tigris.org/. 72 Git: http://git.or.cz/. 73 Bugzilla: http://www.bugzilla.org/. 74 GNATS: http://www.gnu.org/software/gnats/. 75 GVD: http://libre.adacore.com/gvd/. 76 DDD: http://www.gnu.org/software/ddd/. 77 GDB: http://sourceware.org/gdb/. 78 Emacs: http://www.gnu.org/software/emacs/. 79 XEmacs: http://www.xemacs.org/. 80 vi: http://www.vim.org/. 81 Anjuta: http://anjuta.sourceforge.net/. 82 Glimmer: http://glimmer.sourceforge.net/. 83 Eclipse:http://anjuta.sourceforge.net/. 84 Code::Blocks: http://www.codeblocks.org/. 85 PHP: http://www.php.net/. 86 Nvu: http://www.nvu.com/. 87 Seamonkey: http://www.mozilla.org/projects/seamonkey/. 88 SCREEM: http://www.screem.org/. 89 Bluefish: http://bluefish.openoffice.nl/. 90 Sendmail: http://www.sendmail.org/. 91 Postfix: http://www.postfix.org/. 92 Exim: http://www.exim.org/. 93 Apache: http://www.apache.org/. 94 mlmmj: http://mlmmj.mmj.dk/. 95 Mailman: http://www.gnu.org/software/mailman/index.html. 71 Subversion:

Visão Geral de um Sistema Linux

Figura 2.8: Editores de Código

monitoramento de rede (tcpdump96 , Cacti97 , Nagios98 e Zabbix99 ) e outros serviços, tais como: Proxy server, DNS server, News Server, Firewall, FTP server, roteador TCP/IP, servidor de arquivo e de impressão, servidor dial-up, etc. Alguns desses serviços são nativos do próprio Linux, alguns deles fazendo parte do próprio kernel. O leitor deve observar que foram listadas apenas algumas classes de aplicativos e também apenas alguns exemplos de cada classe. O Linux apresenta uma gama muito maior de aplicabilidade do que aqui apresentada, gama essa que tende a crescer ainda mais devido à constante popularização do sistema operacional, aumento das empresas que o vêm adotando e aumento da oferta de distribuições Linux no mercado. Um outro motivo para a crescente demanda consiste em que muitos aplicativos implementados para Linux seguem o paradigma de software livre ou similar. 96 tcpdump:

http://www.tcpdump.org/. http://cacti.org/. 98 Nagios: http://www.nagios.org/. 99 Zabbix: http://www.zabbix.org/.

97 Cacti:

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

Figura 2.9: Editor Bluefish

Caso o leitor esteja procurando por um dado aplicativo, existem diversos sites que facilitam essa busca, como o Freshmeat100 e o Linux Online101 . O Freshmeat, além de ser um site de busca, contém notícias de atualizações de aplicativos e artigos diversos, merecendo visitas periódicas. Também não é possível esquecer o Sourceforge102 , um grande repositório para aplicações distribuídas sob licenças de código aberto. Para busca de aplicações científicas, o melhor site é o SAL (Scientific Applications on Linux)103 .

2.5

DISTRIBUIÇÕES LINUX

Raramente o usuário instala o Linux isoladamente, geralmente o Linux é instalado por meio de uma distribuição. Uma distribuição consiste em um conjunto de programas que são acrescidos ao kernel, a configuração básica desses programas e do kernel e uma filosofia de uso e administração. A distribuição Linux mais antiga ainda em desenvolvimento é a Slackware104 , surgida em abril de 1993. Ela foi baseada no SLS, que teve problemas 100 Freshmeat:

http://www.freshmeat.net/. Online: http://www.linux.org/. 102 Sourceforge: http://sourceforge.net/. 103 SAL: http://sal.kachinatech.com/. 104 Slackware http://www.slackware.com/.

101 Linux

Visão Geral de um Sistema Linux

sérios de manutenção, tendo criado frustação não só para Patrick Volkerding, criador do Slackware, como também para Ian Mundock, criador do projeto Debian. A Slackware é uma distribuição de Linux para uso geral e que tenta se aproximar ao máximo de outras versões de UNIX. Vários usuários reclamavam, entretanto, da forma de instalação de aplicativos no formato “tar.gz” ou similar. Em 1994, surge a distribuição RedHat105 . Com essa distribuição, surge o RPP, uma forma de instalação de software via pacotes. A idéia na base desse conceito era que a administração de software poderia ser facilitada se os aplicativos fossem distribuídos em pacotes gerenciáveis e que permitissem fácil instalação, atualização e desinstalação, sem problemas de dependência de biblioteca. Do RPP, utilizando algumas idéias do PM e PMS (outros sistemas de gerenciamento de pacotes da época), surge a primeira versão do RPM (RedHat Package Manager) (BAILEY, 1998). Apesar de ter sido desenvolvido pela RedHat, o RPM foi disponibilizado em GPL e é, certamente, a forma mais usada para manutenção de software no Linux. Por causa disso, o nome do RPM foi modificado para RPM Package Manager. O uso do RPM mostrou-se tão eficiente, que já é possível encontrar versões do RPM para Solaris, IRIX ou AIX. Dessa maneira, várias distribuições atuais inicialmente eram versões modificadas do RedHat. As mais comuns e talvez as mais conhecidas são aquelas de propósito geral, as quais equipam os computadores caseiros. Além de equipar computadores pessoais, elas também podem ser encontradas em diversos segmentos da sociedade (como indústrias, comércio, etc) tendo a função de servidor de diversos serviços, tais como rede, arquivos e aplicações. Dentre essas distribuições, podem ser destacadas as variações regionais, como o TurboLinux106 , uma distribuição enfocada em usuários e empresas da Ásia, especialmente China, Japão e Índia. Esse era também o caso da SUSE107 , uma distribuição Linux recentemente adquirida pela Novell. Apesar de ser uma distribuição geral, com usuários no mundo inteiro, ela era sediada na Alemanha e tinha um foco grande no mercado europeu. Cabe ressaltar que SUSE, apesar de também usar o formato de pacote RPM, foi baseada inicialmente no Slackware. Uma observação a ser feita é que a regionalização é feita geralmente sob a configuração da máquina. Boa parte dos aplicativos Linux são desenvolvidos de forma internacionalizada. Isso significa que eles suportam várias línguas, bastando o usuário informar qual a 105 RedHat:

http://www.redhat.com/. http://www.turbolinux.com/. 107 SUSE: http://www.novell.com/linux/. 106 TurboLinux:

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

linguagem preferida por ele. Dessa maneira, é possível utilizar o RedHat, uma distribuição americana, com aplicativos apresentando menus em português. Algumas distribuições comuns possuem versões empresariais, a exemplo da própria RedHat e da SUSE. Em geral, não é incomum que essas versões tenham custo, mesmo porque em alguns casos elas incluem aplicativos comerciais que não podem ser distribuídos livremente. Mesmo assim, as empresas que possuem versões empresariais geralmente também mantém versões livres de suas distribuições, caso do Fedora108 para a RedHat e do openSUSE109 para a Novell. Isso quando a própria comunidade não provê uma alternativa, caso do CentOS110 , um concorrente direto da distribuição comercial da RedHat. Uma outra distribuição de uso comum que merece destaque é a Debian111 , que utiliza um sistema de pacotes próprio: o DEB. Essa distribuição, que não é ligada a nenhuma empresa comercial, tenta ater-se ao máximo às diretrizes do movimento Software Livre. Dessa maneira, ela raramente inclui em sua distribuição aplicativos que não sejam distribuídos com licença de código aberto. O interesse no Debian tem crescido fortemente nos últimos anos, por causa do surgimento e disseminação do Ubuntu112 . O Ubuntu surgiu como uma iniciativa do milionário Mark Shuttleworth, e seu nome é um conceito sul-africano que significa “humanidade para com os outros”. Sua proposta pauta em ofertar um SO completo que possa ser utilizado sem dificuldades e que seja baseado totalmente em software livre. Há vários meses, ocupa a primeira colocação entre as distribuições mais populares na DistroWatch113 , site especializado em distribuições Linux e BSD. O Ubuntu é baseado no GNOME, possuindo três versões oficiais alternativas: Kubuntu, baseada no KDE; Xubuntu, baseada no XFCE; e Edubuntu, uma versão projetada para uso escolar ou com crianças. Além disso, o Ubuntu possui uma versão para estação e outra para servidores. Ao possuir versões específicas para cada ambiente e/ou preferência do usuário, o Ubuntu consegue ser uma distribuição sem excesso de aplicativos, relativamente simples para instalação e com um bom desempenho, comparado às outras distribuições de uso geral. Outra distribuição popular baseada no Debian é o Knoppix114 , que é um LiveCD. Ou seja, é possível executá-lo diretamente a partir de um CDROM, ou equivalente, sem a ne108 Fedora:

http://fedoraproject.org/. http://www.opensuse.org/. 110 CentOS: http://www.centos.org/. 111 Debian: http://www.debian.org/. 112 Ubuntu: http://www.ubuntu.com/. 113 DistroWatch: http://distrowatch.com/. 114 Knoppix: http://www.knoppix.org/.

109 openSUSE:

Visão Geral de um Sistema Linux

cessidade de instalação. Isso permite o uso do Linux em locais onde ele não possa ser instalado, como laboratório de terceiros, além de facilitar a demostração do Linux em diversos momentos. Essa técnica tem-se mostrado tão bem sucedida, que várias distribuições passaram a adotar um LiveCD como forma de instalação. Dessa maneira, à medida que vai instalando o SO, o usuário já pode ir experimentando-o, mesmo que com algumas limitações. Esse é o caso do Gentoo, Fedora, Ubuntu e suas variantes. No Brasil, uma distribuição derivada do Knoppix é bastante conhecida e utilizada, o Kurumin115 , com um relativo bom suporte ao hardware encontrado no território brasileiro. É uma distribuição mantida por Carlos Morimoto, mantenedor do site Guia do Hardware116 , importante referência na área de tecnologia. Em geral, as distribuições oferecem aos seus usuários pacotes pré-compilados, ou seja: software pronto a ser executado. Na prática, quase nenhuma opção de compilação ou otimização é dada ao usuário. Uma excessão a essa regra é o Gentoo117 , que permite facilmente a sua adaptação a diferentes perfis de hardware e usuários. Isso ocorre porque no Gentoo cada pacote é compilado locamente, antes da instalação. Isso é feito de forma automatizada, atendendo a opções pré-definidas pelo usuário. Além disso, os são compiladas com opções globais ou locais de otimização, o que permite ao usuário extrair o máximo de desempenho das aplicações. A flexibilidade e poder de customização e otimização do Gentoo é conseguido graças ao Portage, um sistema extremamente poderoso de gerenciamento de pacotes, baseado no sistema de pacotes Ports, do FreeBSD. Como resultado de sua flexibilidade e otimização, o Gentoo é muitas vezes denominado de meta-distribuição, pois pode ser configurado para atender a diferentes necessidades. Existem, inclusive, variantes do Gentoo utilizando o kernel do FreeBSD ou do Mac OS X como base. Além disso, o Gentoo pode ser instalado em diversas arquiteturas de hardware, como: SPARC, PowerPC, etc. No que diz respeito ao hardware, várias distribuições são próprias para uma dada arquitetura, como o Yellow Dog118 , uma distribuição para PowerPC (incluíndo o Sony PS3), ou o UltraLinux119 , uma distribuição para processadores SPARC. Dessa maneira, existem distribuições otimizadas para executarem tarefas específicas ou assumirem características compatíveis com o equipamentos nos quais irão ser executados. É o caso das distribuições voltadas para sistemas dedicados (também conhecidos como embarcados, embutidos ou, em inglês, embedded systems). Sistemas embarcados é a denominação genérica de sistemas construídos utilizando, por exemplo, hardware específico ou hardware reconfigurável, 115 Kurumin:

http://www.guiadohardware.net/gdhpress/kurumin/. do Hardware: http://www.guiadohardware.net/. 117 Gentoo: http://www.gentoo.org/. 118 Yellow Dog: http://www.terrasoftsolutions.com/products/ydl/. 119 UltraLinux: http://www.ultralinux.org/.

116 Guia

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

onde as instruções serão executadas diretamente pelo hardware. Muitos dos sistemas embutidos têm a necessidade de executar um sistema operacional para tornar compatível ou flexível as operações a eles destinados. Nesse caso, o sistema operacional deverá caber em uma restrita área de memória da ordem dos kilobytes apenas. Dentre os Linux para sistemas embutidos, existem aqueles genéricos, como o BlueCat Linux120 ou orientados para serem servidores de rede ou executarem serviços específicos de rede de computadores, podendo-se destacar o Coyote Linux121 , voltado para exercer o papel de roteador de rede e firewall. Ainda dentro das distribuições Linux para sistemas embarcados, existem aqueles destinados a operações críticas, como os sistemas de tempo real. Nessa última categoria pode ser encontradas as distribuições RTOS122 e RTLinux123 .

2.6

A QUESTÃO DA PADRONIZAÇÃO

O mercado de distribuições Linux é extremamente dinâmico, com várias delas surgindo e desaparecendo em um dado momento, com a predominância de um pequeno conjunto dominando a maior parte do mercado. A existência de tantas distribuições, e a dinamicidade do mercade fomenta o levantamento de questões sobre a padronização no Linux. Muitos defendem a existência de um único formato de empacotamento e uma maior padronização nos arquivos e diretórios de configuração. Entre os argumentos utilizados pelos que defendem uma maior padronização encontrase o fato que a fragmentação do UNIX contribuiu bastante para evitar a sua disseminação, abrindo espaço para outros SOs no mercado, durante a disputa entre as várias versões de UNIX. Alguns argumentam ainda que a ausência de um maior nível de padronização dificulta a adoção do Linux pelo mercado, uma vez que não há garantias que o software compilado em uma dada distribuição irá rodar em outra. Este autor, entretanto, adota uma posição mais cautelosa quanto à necessidade de imposição de novos padrões em Linux. O mundo da Informática é extremamente dinâmico e nem sempre aceita padrões de forma natural. Um exemplo dessa situação é o fato que o modelo OSI124 (Open Systems Interconnection Basic Reference Model) para redes de computadores perdeu há muito tempo espaço para o TCP/IP, sendo utilizado atualmente mais com finalidades didáticas que práticas. E isso apesar desse padrão ter sido criado com finalidades extremamente bem-intencionadas: 120 BlueCat

Linux: http://www.lynuxworks.com/. Linux: http://www.coyotelinux.com/. 122 RTOS: http://www.lynuxworks.com/. 123 RTLinux: http://midas.psi.ch/rtlinux/. 124 OSI: http://en.wikipedia.org/wiki/OSI_model. 121 Coyote

Visão Geral de um Sistema Linux

O desenvolvimento dos padrões OSI é uma tarefa bastante desafiadora, com resultados que irão impactar todo o futuro do desenvolvimento da comunicação de dados entre computadores. Se os padrões vierem muito tarde ou forem inadequados, a interconexão de sistemas heterogêneos não serão possíveis ou serão muito custosos. (ZIMMERMANN, 1980)

De forma relativamente irônica, o TCP/IP acabou por se estabelecer como um padrão de facto, mesmo tendo contra ele poderosas empresas de informática (a própria Microsoft se manifestou contra o TCP/IP antes da explosão da Web). Note que houve realmente a adoção de um padrão, mas ele não era o previsto ou desejado pelos órgãos que criaram os padrões. É esse fato que este autor faz questão de ressaltar. O Linux suporta muito mais padrões que vários de seus concorrentes, especialmente os padrões abertos. Além disso existe muito menos fragmentação entre as distribuições Linux que entre as versões UNIX no passado. Isso ocorre principalmente por causa do poder do software livre dentro do Linux: uma solução que resolva bem um problema em uma distribuição e que chame a atenção é rapidamente copiada por outras distribuições, sem que seja preciso pedir autorização para isso. E distribuições que não adotam esse padrão acabam sendo vistas como “” pela comunidade. Por outro lado, a inexistência de um padrão de juri faz com que soluções otimizadas e flexíveis possam ser utilizadas sem que haja preocupação com a infração a padrões estabelecidos formalmente. A existência de vários gerenciadores de ambiente, por exemplo, surgiu de necessidades diferentes de seus usuários, sendo que cada um desses ambientes acabou por se especializar em um conjunto de soluções. Assim, mais importante que um padrão no desktop é a garantia de interoperabilidade entre os vários desktops existentes. Indiferente se KDE, GNOME ou Xfce, por exemplo, aplicativos como o Pidgin irão criar um ícone na área de notificação do painel e deve ser possível copiar e colar entre aplicativos usando as bibliotecas gráficas Qt125 ou GTK126 . Assim, ressalta-se mais uma vez a necessidade de cautela para um posicionamento em prol de uma padronização extrema no Linux, o que poderia em muito lhe tirar poder e flexibilidade. Algum nível de padronização é necessário, obviamente, mas esses padrões não podem ser criados apenas para satisfazer desejos pessoais de alguns poucos, em detrimento da comunidade. Nesse contexto, um exemplo extremamente positivo que merece destaque é o surgimento da Freedesktop.org127 , que é um esforço para desenvolvimento de padrões e 125 Qt:

http://trolltech.com/products/qt. http://www.gtk.org/. 127 Freedesktop.org: http://www.freedesktop.org/. 126 GTK:

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

software para garantir a interoperabilidade dos vários gerenciadores de ambiente. É graças aos padrões do Freedesktop.org que desenvolvedores podem implementar entradas no menu de programas, sem se preocupar se o usuário utiliza KDE, GNOME ou Xfce. Também a esse grupo cabe a responsabilidade de software que garanta um grau de interoperabilidade entre esses desktops, como o HAL, D-Bus e GStreamer. Outro esforço que merece ser comentado é a criação, recentemente, da The Linux Foundation128 , a partir da fusão da Open source Development Labs e do Free Standards Group. Na época da criação, essa fundação contava com o apoio de setenta fabricantes, incluindo IBM, HP, Oracle , Novell e Intel, além de Fujitsu, Hitachi e NEC. O principal trabalho dessa fundação é o Linux Standard Base (LSB) (FREE STANDARDS GROUP, 2006), um conjunto de padrões para garantir interoperabilidade de aplicações entre distribuições Linux, definindo uma interface de sistema para aplicações compiladas e um ambiente mínimo para execução de scripts. O LSB é um padrão em franca adoção no mundo Linux e deve ser ampliado cada vez mais em seu alcance. Além do LSB, a Linux Foundation cuida também do FHS (RUSSELL; QUINLAN; YEOH, 2004), um conjunto de padrões para o sistema de arquivos. Também é responsável pela LANANA, uma organização responsável pela atribuição de nomes a dispositivos. Também é responsável pela OpenPrinting, organização responsável por um conjunto de padrões na área de impressão e pelo footmatic, um software para integração de drivers de impressoras com gerenciadores de impressão (como CUPS129 ou LPRng130 ).

2.7

INSTALAÇÃO O LINUX

O processo de instalação de um sistema Linux varia de uma distribuição para outra. A maioria das distribuições atuais de uso geral possuem interface gráfica de instalação, tornando o processo relativamente simples. Mesmo alguns instaladores em modo texto não oferecem dificuldade. De uma forma sintética, uma instalação Linux consiste em três passos:

1. particionamento do disco e formatação dos sistemas de arquivo; 2. seleção, por parte do usuário, de quais aplicativos (pacotes) serão instalados inicialmente; 128 The

Linux Foundation: http://www.linux-foundation.org/. http://www.cups.org/. 130 LPRng: http://www.lprng.org/.

129 CUPS:

Visão Geral de um Sistema Linux

3. estabelecimento de configurações básicas, como senha de root e informações de rede e instalação do gerenciador de boot. Em geral, as distribuições mais conhecidas disponibilizam bons manuais (impressos ou eletrônicos) que orietam o processo de instalação. Dada a existência dessa documentação, aliada às diferenças de instalação entre as distribuições, este texto não se aterá nesse ponto.

2.8

OBTENDO AJUDA

Qualquer usuário que não tenha experiência com um software abrangente, como um processador de texto ou o kernel do Linux, irá precisar de ajuda, cedo ou tarde. Em Linux, essa ajuda pode vir de várias formas. Uma forma muito usual de conseguir ajuda em Linux é através de listas de discussão. Geralmente, as distribuições e os desenvolvedores dos servidores mais utilizados mantém listas próprias, visando facilitar o intercâmbio de informações entre seus usuários. Dependendo do nível de experiência dos participantes, é possível obter soluções rápidas para problemas comuns no uso do Linux. Na maioria das vezes, também é possível obter auxílio através de arquivos de ajuda disponibilizados junto com o software. Em geral, os arquivos de ajuda dos programas UNIX são disponibilizados em páginas de manuais (man pages), acessadas via comando man nome-do-programa. A Figura 2.10 mostra o resultado da execução do comando man route. Algumas páginas man vem sendo acompanhadas ou substituídas por páginas de informações (info pages). Essas páginas acrescentam alguma funcionalidade extra às páginas man, como, por exemplo, links entre seções. As páginas info podem ser acessadas através dos comandos info ou pinfo, ilustrado na Figura 2.11. Além das informações locais, é possível coletar documentação farta sobre Linux em vários sites. Entre esses sites, merece destaque o mantido pelo The Linux Documentation Project – TLDP (http://www.tldp.org/). Esse site possui uma ramificação brasileira em http://br.tldp.org/, que disponibiliza traduções de alguns documentos do projeto. Várias man pages são mantidas pelo TLDP, mas esse não é o único tipo de documento disponibilizado. Também podem ser encontrados guias (na verdade, livros ou manuais, alguns dos quais publicados por vias tradicionais), revistas eletrônicas sobre Linux e pequenos textos sobre problemas específicos (os HOWTOs). Esses HOWTOs ajudam o administrador a resolver um problema particular. Por exemplo, o gerenciamento de Quota é

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

Figura 2.10: Execução do Comando man

muito bem explicado no “Quota mini howto” (DOOREN, 2002). A opinião dos administradores Linux ligados ao ARL é que o melhor material sobre Linux pode ser obtido diretamente do TLDP em formato eletrônico.

2.9

COMENTÁRIOS FINAIS

Dada a fartura de material sobre o Linux é inconcebível a postura de administradores que se negam a consultar HOWTOs e man pages sob a alegação de que a leitura dos mesmos toma-lhe muito tempo. Essa postura reflete uma atitude preguiçosa, de quem espera tudo pronto e não está disposto a procurar as bases de conhecimento para o que intenciona fazer. Na verdade, o uso de recursos como man pages e HOWTOs é tão vivo no mundo Linux, que seu uso não é recomendado só para administradores, mas mesmo pelo usuário final. Isso deve ser feito porque estimula uma postura ativa frente aos recursos da informática.

Visão Geral de um Sistema Linux

Figura 2.11: Execução do pinfo

Afinal esses documentos foram criados para não somente explicar como fazer as coisas em Linux, mas as bases em que elas são feitas.

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

3 CONFIGURAÇÃO DE DISPOSITIVOS

3.1

COMENTÁRIOS INICIAIS

A configuração de dispositivos em Linux em geral não é uma tarefa complexa. E, ao contrário do que é comumente disseminado, o Linux suporta muito mais dispositivos nativamente que outros SOs, como discutido em (KROAH-HARTMAN, 2006). Isso implica que o suporte é feito de forma coerente e integrada, o que garante um alto grau de estabilidade ao sistema computacional como um todo. O real problema com a dificuldade de instalação de alguns dispositivos advém do fato de que esses dispositivos são instalados com software de seus fabricantes, sendo projetado, em sua grande maioria, para funcionarem apenas no WindowsTM . Mais ainda, por motivos os mais diversos, incluindo-se medo de processos legais por quebra de patentes, esses fornecedores também não costumam liberar a especificação desses equipamentos, dificultando o desenvolvimento de um driver para Linux pela comunidade software livre. Além disso, cabe ressaltar que as distribuições em geral possuem diversas ferramentas que facilitam a configuração de hardware, em geral com um grau de reconhecimento bastante poderoso. Com isso, o tempo de configuração da maior parte dos dispositivos instalados em um computador é, em geral, inferior ao de outros SOs. Mais ainda, boa parte dessa configuração é feita de forma automática, sem a necessidade de intervenção direta.

3.2

OBTENDO INFORMAÇÃO SOBRE HARDWARE EM LINUX

Quando um hardware não é configurado de forma automática, existem alguns procedimentos que podem auxiliar o usuário nessa tarefa. Inicialmente recomenda-se verificar se o dispositivo foi reconhecido pelo kernel e, em caso positivo, como isso ocorreu. Nesse sentido, é extremamente útil consultar os logs do kernel, geralmente em /var/log/kern.log ou /var/log/kernel/. Também pode ser útil verificar as mensagens do buffer do kernel, inclusive as geradas durante o processo de inicialização do sistema (boot). Isso pode ser

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

feito por meio do utilitário dmesg. É importante esclarecer que esse utilitário irá imprimir as últimas mensagens no buffer do kernel, podendo já não mais apresentar mensagens do boot, em um sistema já há mais tempo ativo. Como ilustrado na Figura 3.1, o kernel imprime uma série de informações sobre o hardware encontrado, inclusive aqueles não suportados.

eth0: forcedeth.c: subsystem: 01043:8239 bound to 0000:00:08.0 netconsole: not configured, aborting Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx NFORCE-MCP55: IDE controller at PCI slot 0000:00:04.0 NFORCE-MCP55: chipset revision 161 NFORCE-MCP55: not 100% native mode: will probe irqs later NFORCE-MCP55: 0000:00:04.0 (rev a1) UDMA133 controller ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:DMA Probing IDE interface ide0... hda: HL-DT-ST DVDRAM GSA-4167B, ATAPI CD/DVD-ROM drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 Probing IDE interface ide1... hda: ATAPI 48X DVD-ROM DVD-R-RAM CD-R/RW drive, 2048kB Cache, UDMA(33) Uniform CD-ROM driver Revision: 3.20 sata_nv 0000:00:05.0: version 3.4 ACPI: PCI Interrupt Link [APSI] enabled at IRQ 22 ACPI: PCI Interrupt 0000:00:05.0[A] -> Link [APSI] -> GSI 22 (level, low) -> IRQ 22 PCI: Setting latency timer of device 0000:00:05.0 to 64 scsi0 : sata_nv scsi1 : sata_nv

Figura 3.1: Trechos de Saída do dmesg

Assim, em parte dos dispositivos, tem-se a indicação, via dmesg, de como eles foram suportados e como são reconhecidos no sistema. Também pode ser bastante útil o comando lsmod, que lista os módulos carregados pelo kernel. Outros utilitários essenciais são o lspci, lsusb, systool, dmidecode, lshal e hal-device-manager. O lspci lista todos os dispositivos PCl do sistema, incluindo-se dispositivos onboard e placas de vídeo AGP. Essa ferramenta é extremamente útil para se descobrir o chipset de um dado dispositivo, como ilustrado na Figura 3.2.

Configuração de Dispositivos

00:00.0 RAM memory: nVidia Corporation MCP55 Memory Controller (rev a1) 00:01.0 ISA bridge: nVidia Corporation MCP55 LPC Bridge (rev a2) 00:01.1 SMBus: nVidia Corporation MCP55 SMBus (rev a2) 00:01.2 RAM memory: nVidia Corporation MCP55 Memory Controller (rev a2) 00:02.0 USB Controller: nVidia Corporation MCP55 USB Controller (rev a1) 00:02.1 USB Controller: nVidia Corporation MCP55 USB Controller (rev a2) 00:04.0 IDE interface: nVidia Corporation MCP55 IDE (rev a1) 00:05.0 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a2) 00:05.1 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a2) 00:05.2 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a2) 00:06.0 PCI bridge: nVidia Corporation Unknown device 0370 (rev a2) 00:06.1 Audio device: nVidia Corporation MCP55 High Definition Audio (rev a2) 00:08.0 Bridge: nVidia Corporation MCP55 Ethernet (rev a2) 00:0a.0 PCI bridge: nVidia Corporation Unknown device 0376 (rev a2) 00:0b.0 PCI bridge: nVidia Corporation Unknown device 0374 (rev a2) 00:0c.0 PCI bridge: nVidia Corporation Unknown device 0374 (rev a2) 00:0d.0 PCI bridge: nVidia Corporation Unknown device 0378 (rev a2) 00:0e.0 PCI bridge: nVidia Corporation Unknown device 0375 (rev a2) 00:0f.0 PCI bridge: nVidia Corporation Unknown device 0377 (rev a2) 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control 07:00.0 VGA compatible controller: nVidia Corporation GeForce 6200 TurboCache(TM) (rev a1) Figura 3.2: Exemplo de Saída do lspci

A saída do lspci, que pode conter ainda um nível maior de detalhes é útil para configurações em que são necessárias informações extras, tais como: porta I/O e endereço de memória. Além disso, o suporte em Linux a um dispositivo é feito sobre seu chipset. Como várias placas são feitas por um fabricante incorporando-se chipset de terceiros, o usuário pode não conseguir informações sobre o suporte dessa placa em Linux apenas por seu nome/modelo. A informação apresentada pelo lspci, obtida diretamente do hardware, é portanto, em geral, mais confiável para a correta configuração do equipamento.

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

No mesmo caminho, o comando lsusb lista os dispositivos conectados ao barramento USB, como ilustrado na Figura 3.3, que lista um gamepad, dois HDs externos e um mouse USB. A Figura 3.3 apresenta ainda trechos da saída mais detalhada desse comando, destacando o mouse USB. Essa saída foi cortada em suas 20 primeiras linhas, com uso do comando head, por questões de espaço na figura. $ lsusb Bus 002 Bus 002 Bus 002 Bus 001 Bus 001

Device 003: ID 046d:c21a Device 002: ID 0458:0036 Device 001: ID 0000:0000 Device 017: ID 05e3:0702 Device 007: ID 04cf:8818 External Storage Bus 001 Device 001: ID 0000:0000

Logitech, Inc. KYE Systems Corp. (Mouse Systems) Genesys Logic, Inc. USB 2.0 IDE Adapter Myson Century, Inc. Fast 3.5"

$ lsusb -v -d 0458:0036 | head -20 Bus 002 Device 002: ID 0458:0036 KYE Systems Corp. (Mouse Systems) Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x0458 KYE Systems Corp. (Mouse Systems) idProduct 0x0036 bcdDevice 1.07 iManufacturer 2 Genius iProduct 1 NetScroll+Mini Traveler iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 Figura 3.3: Exemplo de Saída do lsusb

Outra forma de se obter informação sobre hardware em Linux é por meio do HAL, do /proc e do sysfs. O HAL (Hardware Abstraction Layer)1 é um software mantido 1 HAL:

http://www.freedesktop.org/wiki/Software/hal.

Configuração de Dispositivos

pela Freedesktop.org, uma organização responsável pelo desenvolvimento de padrões e software para garantir a interoperabilidade dos vários gerenciadores de ambiente sob X Windows. O HAL provê informações sobre os dispositivos aos gerenciadores de ambiente. Assim, ele acessa informação do hardware, enviando-as ao desktop, facilitando a configuração automática do mesmo. Apesar de se destinar aos gerenciadores de ambiente, o pacote de instalação do HAL provê um utilitário de linha de comando, o lshal que lista informações dos dispositivos a que o HAL tem acesso. Na Figura 3.4 é apresentado um trecho de saída desse comando, mostrando a detecção do gamepad listado na Figura 3.2 pelo HAL. Uma alternativa gráfica, com navegação em forma de árvore, é possibilidada pelo hal-device-manager, um utilitário distribuído com o HAL, ilustrado na Figura 3.5. O diretório /proc, por sua vez é obtido pela montagem do procfs um pseudo sistema de arquivos em sistemas UNIX ou Unix-like. Esse pseudo sistema de arquivos é montado durante o processo de inicialização do sistema e não consome espaço de armazenamento, apenas uma quantidade limitada de memória. O diretório montado, /proc disponibiliza uma série de informações do kernel, sendo também utilizado para algumas configurações dinâmicas do sistema. As informações são disponibilizadas por meio de arquivos-textos na árvore de diretório do /proc. A Figura 3.6 mostra a conteúdo do arquivo /proc/interrupts, que pode ser útil na configuração de algum dispositivo. Várias outras informações importantes sobre o hardware são disponibilizadas no /proc, como as instruções suportadas pelo processador (Figura 3.7) e que podem ser determinantes para saber se a máquina suporta ou não uma determinada opção de compilação do kernel. Além disso, é possível obter informações sobre memória (/proc/meminfo), dispositivos (/proc/devices) e dados sobre os processos em execução pelo kernel. O nome procfs advém, inclusive, de Process File System, sistema de arquivos de processos. Sua função principal, portanto, é disponibilizar todas as informações possíveis que o kernel possua sobre os processos gerenciados por ele. Como o diretório /proc começou a ser utilizado para disponibilizar diversas informações do sistema, a partir do kernel 2.6 foi criado o sysfs, descrito com detalhes em (MOCHEL, 2005). O sysfs é um sistema de arquivos virtual que exporta para a camada de usuário informações sobre dispositivos e drivers, também permitindo a configuração de alguns elementos do sistema. Esse sistema de arquivos é montado geralmente no diretório /sys, e ele é formado por arquivos-texto, com geralmente um único valor por cada arquivo. Isso é conseguido mapeando-se objetos do kernel são mapeados em diretórios, atributos em arquivos regulares e relacionamentos em links simbólicos.

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

udi = ’/org/freedesktop/Hal/devices/usb_device_46d_c21a_noserial’ info.bus = ’usb_device’ (string) info.linux.driver = ’usb’ (string) info.parent = ’/org/freedesktop/Hal/devices/usb_device_0_0_0000_00_02_0’ (string) info.product = ’Logitech(R) Precision(TM) Gamepad’ (string) info.subsystem = ’usb_device’ (string) info.udi = ’/org/freedesktop/Hal/devices/usb_device_46d_c21a_noserial’ (string) info.vendor = ’Logitech, Inc.’ (string) linux.device_file = ’/dev/bus/usb/002/003’ (string) linux.hotplug_type = 2 (0x2) (int) linux.subsystem = ’usb’ (string) linux.sysfs_path = ’/sys/devices/pci0000:00/0000:00:02.0/usb2/2-3’ (string) usb_device.bus_number = 2 (0x2) (int) usb_device.can_wake_up = false (bool) usb_device.configuration_value = 1 (0x1) (int) usb_device.device_class = 0 (0x0) (int) usb_device.device_protocol = 0 (0x0) (int) usb_device.device_revision_bcd = 4 (0x4) (int) usb_device.device_subclass = 0 (0x0) (int) usb_device.is_self_powered = false (bool) usb_device.linux.device_number = 3 (0x3) (int) usb_device.linux.sysfs_path = ’/sys/devices/pci0000:00/0000:00:02.0/usb2/2-3’ (string) usb_device.max_power = 50 (0x32) (int) usb_device.num_configurations = 1 (0x1) (int) usb_device.num_interfaces = 1 (0x1) (int) usb_device.num_ports = 0 (0x0) (int) usb_device.product = ’Logitech(R) Precision(TM) Gamepad’ (string) usb_device.product_id = 49690 (0xc21a) (int) usb_device.speed = 1.5 (1.5) (double) usb_device.speed_bcd = 336 (0x150) (int) usb_device.vendor = ’Logitech, Inc.’ (string) usb_device.vendor_id = 1133 (0x46d) (int) usb_device.version = 1.1 (1.1) (double) usb_device.version_bcd = 272 (0x110) (int) Figura 3.4: Trecho de Saída do lshal

Configuração de Dispositivos

Figura 3.5: Obtendo Informações de Hardware com o hal-device-manager

0: 1: 8: 9: 12: 14: 16: 20: 21: 22: 23: 281: NMI: LOC: ERR:

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

CPU0 12668905 46111 1 0 4 111933 800709 0 530421 622481 897 1963707 0 12669618 0

IO-APIC-edge IO-APIC-edge IO-APIC-edge IO-APIC-fasteoi IO-APIC-edge IO-APIC-edge IO-APIC-fasteoi IO-APIC-fasteoi IO-APIC-fasteoi IO-APIC-fasteoi IO-APIC-fasteoi PCI-MSI-edge

timer i8042 rtc acpi i8042 ide0 nvidia sata_nv sata_nv, HDA Intel sata_nv, ohci_hcd:usb2 ehci_hcd:usb1 eth0

Figura 3.6: Arquivo /proc/interrupts processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 95 model name : AMD Athlon(tm) 64 Processor 3500+ stepping : 2 cpu MHz : 2200.000 cache size : 512 KB fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow pni cx16 lahf_lm svm extapic cr8_legacy bogomips : 4842.90 TLB size : 1024 4K pages clflush size : 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts fid vid ttp tm stc Figura 3.7: Arquivo /proc/cpuinfo

Configuração de Dispositivos

A obtenção de informações do sysfs pode ser feita de forma direta, acessando-se o diretório montado com esse sistema de arquivos. Isso é ilustrado na Figura 3.8, em que é mostrado o conteúdo de um arquivo associado a um dado dispositivo. Um utilitário que auxilia nessa tarefa é o systool, integrante do pacote sysfs-utils. Esse utilitário facilita a obtenção de informações do sysfs, agregando entradas, como ilustrado na Figura 3.9. Um utilitários extra também importante na tarefa de obtenção de informações sobre o hardware é o dmidecode, ilustrado na Figura 3.10. Esse utilitário permite o acesso a informações DMI (Desktop Management Interface), parte integrante das BIOS atuais. Com isso, é possível obter uma descrição dos componentes de hardware, bem como outras informações úteis, como números seriais e revisão da BIOS. Como essas informações são obtidas diretamente da BIOS, sem acesso ao hardware em si, elas são acessadas rapidamente, mas podem não ser totalmente confiáveis. Por fim, com o uso dos utilitários apresentados nesta seção, o usuário consegue obter um conjunto muito grande de informações sobre seu hardware. Isso facilitará em muito a tarefa de configuração, e a busca por auxílio na internet, seja em mecanismos de busca, seja em listas ou fóruns de discussão, seja consultando os manuais de configuração da distribuição instalada no sistema.

3.3 DRIVERS E MÓDULOS Em Linux, o driver de um dado dispositivo de hardware é geralmente disponibilizado de quatro maneiras: 1. como parte integrante do próprio kernel; 2. como um módulo carregável distribuído junto com o próprio kernel; 3. como um módulo carregável que precisa ser compilado e instalado; 4. como um código que deve ser adicionado ao código do kernel para recompilação (ou seja: um patch). Essas maneiras estão dispostas em ordem de dificuldade de uso para o administrador de sistemas. Alguns dispositivos podem ter suporte nativo dentro do próprio kernel do Linux. Isso depende das opções de compilação do kernel, o que pode variar de uma distribuição para outra. Em geral, as distribuições costumam customizar a configuração do kernel de acordo com alguma diretriz.

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

$ dir /sys/bus/usb/devices/usb2/2-3/ total 0 drwxr-xr-x 4 root root 0 2007-09-17 08:19 2-3:1.0 -r--r--r-- 1 root root 4096 2007-09-17 05:15 bcdDevice -rw-r--r-- 1 root root 4096 2007-09-17 08:19 bConfigurationValue -r--r--r-- 1 root root 4096 2007-09-17 08:19 bDeviceClass -r--r--r-- 1 root root 4096 2007-09-17 08:19 bDeviceProtocol -r--r--r-- 1 root root 4096 2007-09-17 08:19 bDeviceSubClass -r--r--r-- 1 root root 4096 2007-09-17 08:19 bmAttributes -r--r--r-- 1 root root 4096 2007-09-17 13:23 bMaxPacketSize0 -r--r--r-- 1 root root 4096 2007-09-17 08:19 bMaxPower -r--r--r-- 1 root root 4096 2007-09-17 08:19 bNumConfigurations -r--r--r-- 1 root root 4096 2007-09-17 08:19 bNumInterfaces -r--r--r-- 1 root root 4096 2007-09-17 13:23 busnum -r--r--r-- 1 root root 4096 2007-09-17 08:19 configuration -r--r--r-- 1 root root 4096 2007-09-17 13:23 dev -r--r--r-- 1 root root 4096 2007-09-17 08:19 devnum lrwxrwxrwx 1 root root 0 2007-09-17 05:15 driver -> ../../../../../bus/usb/drivers/usb lrwxrwxrwx 1 root root 0 2007-09-17 13:23 ep_00 -> ../../../../../devices/pci0000:00/0000:00:02.0/ usb2/2-3/usb_endpoint/usbdev2.3_ep00 -r--r--r-- 1 root root 4096 2007-09-17 05:15 idProduct -r--r--r-- 1 root root 4096 2007-09-17 05:15 idVendor -r--r--r-- 1 root root 4096 2007-09-17 05:15 manufacturer -r--r--r-- 1 root root 4096 2007-09-17 08:19 maxchild drwxr-xr-x 2 root root 0 2007-09-17 05:15 power -r--r--r-- 1 root root 4096 2007-09-17 05:15 product -r--r--r-- 1 root root 4096 2007-09-17 13:23 quirks -r--r--r-- 1 root root 4096 2007-09-17 08:19 speed lrwxrwxrwx 1 root root 0 2007-09-17 05:15 subsystem -> ../../../../../bus/usb -rw-r--r-- 1 root root 4096 2007-09-17 05:15 uevent drwxr-xr-x 3 root root 0 2007-09-17 05:15 usb_device drwxr-xr-x 3 root root 0 2007-09-17 05:15 usb_endpoint -r--r--r-- 1 root root 4096 2007-09-17 08:19 version $ cat /sys/bus/usb/devices/usb2/2-3/product Logitech(R) Precision(TM) Gamepad Figura 3.8: Obtendo Informações de Hardware via sysfs

Configuração de Dispositivos

$ systool -b usb -d 2-3 -v Bus = "usb" Device = "2-3" Device path = "/sys/devices/pci0000:00/0000:00:02.0/usb2/2-3" bConfigurationValue = "1" bDeviceClass = "00" bDeviceProtocol = "00" bDeviceSubClass = "00" bMaxPacketSize0 = "8" bMaxPower = " 50mA" bNumConfigurations = "1" bNumInterfaces = " 1" bcdDevice = "0004" bmAttributes = "80" busnum = "2" configuration = devnum = "3" dev = "189:130" idProduct = "c21a" idVendor = "046d" manufacturer = "Logitech" maxchild = "0" product = "Logitech(R) Precision(TM) Gamepad" quirks = "0x0" speed = "1.5" uevent = "MAJOR=189 MINOR=130 DEVTYPE=usb_device DRIVER=usb DEVICE=/proc/bus/usb/002/003 PRODUCT=46d/c21a/4 TYPE=0/0/0 BUSNUM=002 DEVNUM=003" version = " 1.10" Figura 3.9: Exemplo de Uso do systool

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

$ dmidecode -t 2 # dmidecode 2.9 SMBIOS 2.4 present. Handle 0x0002, DMI type 2, 8 bytes Base Board Information Manufacturer: ASUSTeK Computer INC. Product Name: M2N-E Version: 1.XX Serial Number: 123456789000 Figura 3.10: Exemplo de Uso do dmidecode

A forma preferencial, entretanto, é oferecer o suporte a dispositivos através dos módulos carregáveis. O kernel do Linux é um sistema modular. Isso significa que um módulo é uma biblioteca que não é ligada (incluída) diretamente no kernel. Essas bibliotecas podem ser inseridas e removidas dentro do kernel a qualquer momento, dando ao Linux uma flexibilidade muito grande para uso de dispositivos. Tome-se por exemplo o uso de um zipdrive. No Windows 95 ou 98, se o sistema não foi inicializado tendo o zipdrive paralelo ligado ao micro, não adianta, na maioria dos casos, tentar usar o aparelho. Será preciso reiniciar a máquina para que ele funcione. Em Linux, é possível adicionar o zipdrive com o micro funcionando, carregar o módulo associado, usar o equipamento, remover o módulo do kernel e remover o zipdrive do equipamento, sem nenhum transtorno. Assim, para evitar que o kernel fique muito grande, para poder oferecer suporte a vários dispositivos, geralmente esse suporte é oferecido preferencialmente na forma de módulos. Esses módulos são, em geral, armazenados em algum subdiretório de /lib/modules. Uma forma de ver os módulos em uso é visualizar o arquivo /proc/modules ou digitar o comando lsmod. A saída desses dois processos é bastante similar e um exemplo pode ser visualizado na Figura 3.11. Na seqüência da saída apresentada na Figura 3.11, tem-se: o nome do módulo, tamanho dele em memória, quantos dispositivos dependem dele e uma lista dos módulos que dependem do mesmo. Para remover um módulo da memória, basta digitar o comando rmmod modulo. Um módulo só poderá ser removido se não estiver em uso. No caso da Figura 3.11, o módulo usb-uhci poderia ser removido sem problemas. Uma forma interessante de uso do comando rmmod é chamá-lo com a opção “-a”, que faz uma limpeza dos módulos sem uso. Em alguns casos, é preciso rodar rmmod -a duas

Configuração de Dispositivos

nfs nfsd lockd sunrpc eepro100 usb-uhci usbcore ext3 jbd aic7xxx sd_mod scsi_mod

79840 71232 53184 64816 17680 21668 51808 62624 41092 114624 11900 98584

4 8 1 1 2 0 1 8 8 7 7 2

(autoclean) (autoclean) (autoclean) [nfs nfsd] (autoclean) [nfs nfsd lockd] (unused) [usb-uhci] [ext3]

[aic7xxx sd_mod]

Figura 3.11: Módulos Carregados e em Uso

vezes, por causa da referência entre módulos. Assim, um módulo que estivesse carregado somente por causa de outro, poderia ser removido da memória em uma segunda execução do comando. Para carregar um módulo em memória, basta executar o comando insmod modulo. Assim, insmod ppa iria carregar o módulo necessário ao suporte do zipdrive paralelo. Em certos casos, um módulo precisa de outros para poder funcionar corretamente. Por exemplo, o módulo ppa precisa do módulo parport, que oferece suporte à porta paralela do computador. Dessa maneira, a execução do comando insmod ppa iria gerar erro se o módulo parport já não estivesse carregado. Para simplificar esse processo de instalação de módulos, foi disponibilizado o comando modprobe. Esse comando irá utilizar-se do arquivo /lib/modules/xxx/modules.dep, onde xxx é a versão do kernel instalado para carregar os módulos de forma inteligente. O comando modprobe checa as dependências de um módulo antes de instalá-lo. Assim, se o administrador invoca modprobe ppa e o módulo ppa precisa do módulo não-instalado parport, então o módulo parport será carregado antes do módulo ppa. Para saber qual módulo é necessário para suporte de um dado dispositivo, é possível consultar a documentação do kernel, caso ela tenha sido instalada. Em geral, ela é encontrada no diretório /usr/share/doc/kernel-doc-xxx/, onde xxx é a versão do kernel. A maioria dos dispositivos de uso geral são suportados com as versões normais do kernel. Assim, o trabalho do administrador é carregar o módulo associado ao dispositivo e configurá-lo. Em alguns casos, esse módulo não encontra-se integrado ao kernel, por estar

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

em versão inicial ou não ser distribuído sob a GPL. Nesse caso, o administrador precisa efetuar download do arquivo do módulo e, em alguns casos, compilá-lo. Esse era o processo, até pouco tempo atrás, para obter suporte a UDF no Linux. A maioria dos softmodems2 também funcionam dessa forma, o mesmo ocorrendo com algumas placas de vídeo. Tendo o módulo compilado, o próximo passo é instalá-lo com o comando insmod modulo.o, onde modulo.o é o nome do módulo compilado. Em alguns casos, esse módulo não pode ser compilado independente do kernel. Assim, ele é desenvolvido como um patch. Em geral, são módulos em fases extremamente iniciais e que são liberados posteriormente ou integrados ao kernel ou como módulos compiláveis de forma independente. Dessa maneira, não são módulos em fase estável e não são de uso geral recomendável. Dada essa situação, essa apostila não entrará em detalhes de compilação do kernel, uma vez que não é uma medida necessária à maioria das tarefas administrativas. Na maioria dos casos, inclusive, é possível administrar excelentemente bem um sistema, sem precisar sequer pensar nisso. Além disso, a compilação do kernel não é uma tarefa trivial e requer suficiente experiência e conhecimento no uso do Linux, não sendo recomendável a usuários iniciantes ou mesmo intermediários, uma vez que corre-se o risco de deixar o sistema inutilizável ou altamente instável. Ainda assim, caso o leitor queira saber como isso é feito, recomenda-se antes a leitura de (VASUDEVAN, 2003), (HENDERSON, 2002). Também existem bons documentos em português sobre o assunto, mas o processo de compilação exige suficiente domínio da língua inglesa.

3.4

O ARQUIVO /ETC/MODULES.CONF

Em alguns casos, o kernel necessita de informações adicionais a respeito de como carregar um módulo. Para se configurar algumas placas, por exemplo, pode ser importante informar o número de interrupção associado, o endereço físico e o uso de DMA. Para facilitar o uso desses módulos, o kernel utiliza um arquivo de configuração que fica em /etc/modules.conf. A Figura 3.12 mostra um exemplo desse arquivo. O caso mais freqüente de uso do arquivo /etc/modules.conf é informar ao kernel qual é o driver associado a um determinado tipo de dispositivo. Assim, por exemplo, no exemplo da Figura 3.12, é informado ao kernel que a primeira placa de rede é controlada 2 Um

softmodem é um modem com capacidades mínimas em hardware, dependendo em muito do software para seu funcionamento. Também são chamados de winmodems, dado que os primeiros modelos objetivavam unicamente usuários de Windows.

Configuração de Dispositivos

alias alias alias alias alias alias

parport_lowlevel parport_pc scsi_hostadapter aic7xxx usb-controller usb-uhci eth0 eepro100 eth1 8139too sound-slot-0 cmpci

Figura 3.12: Arquivo /etc/modules.conf

pelo driver eepro100 (no caso uma IBM Ethernet Pro 100) e a segunda é controlada pelo driver 8139too (no caso, uma Realtek). Ainda quanto à Figura 3.12, a controladora SCSI é controlada pelo driver aic7xxx (no caso, uma Adaptec) e a placa de som é uma CMI8338, controlada pelo driver cmpci. Por fim, a controlodora USB usa um driver genérico, indicado para a maioria dos casos, que é o usb-uhci. Note que alias é apenas a opção mais usada, mas não é a única. É possível, por exemplo, interrupções e endereços de hardware, bem como informar o que deve ser feito imediatamente após carregar ou descarregar um determinado módulo. Em alguns sistemas, como Debian e Gentoo, esse arquivo é mantido pelo utilitário update-modules, que facilita o gerenciamento dinâmico desse arquivo.

3.5

CRIAÇÃO DE ARQUIVOS DE DISPOSITIVOS

Quase todo dispositivo de hardware interno do computador é mapeado em um arquivo no diretório /dev em Linux. Assim, para grande maioria dos dispositivos, deve haver um arquivo no diretório /dev associado ao dispositivo. Além disso, o kernel, ou as aplicações que utilizam esse dispositivo devem saber como controlar esse item de hardware. A maioria dos arquivos de dispositivos serão criados e estarão disponíveis após a instalação do sistema. Se por algum motivo, o administrador precisar criar algum desses arquivos, a primeira tentativa deve ser a utilização do script MAKEDEV em /dev/. A Figura 3.13 mostra um exemplo de uso desse comando. # /dev/MAKEDEV -v ttyS0 create ttyS0 c 4 64 root:dialout 0660 Figura 3.13:

Uso do Comando makedev

O comando emitido na Figura 3.13 irá criar um arquivo de dispositivo de caracter com número maior 4 e número menor 64. O proprietário desse dispositivo será o usuário root,

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

pelo grupo dialout, com permissões de leitura e escrita pelo usuário e pelo grupo e sem permissão para qualquer outro usuário. Os números (ou nós) maior e menor são utilizados pelo kernel para associar cada dispositivo ao driver correspondente. O número maior identifica o tipo de dispositivo, em outras palavras: a qual driver aquele arquivo está associado. O número menor indica qual o item particular daquele tipo de dispositivo que está sendo endereçado, sendo chamado também de número de unidade. O número maior e menor de um dado dispositivo pode ser verificado com o comando ls -l, como mostra a Figura 3.14. Nessa figura, tem-se /dev/hda e /dev/hda1 como dispositivos de bloco e com o mesmo número maior, sendo controlados, portanto, pelo mesmo driver.

# ls -l /dev/hda /dev/hda1 brw-rw---1 root disk brw-rw---1 root disk

3, 3,

0 Abr 11 1 Abr 11

2002 /dev/hda 2002 /dev/hda1

Figura 3.14: Exibindo Informações de um Dispositivo

Existem dois tipos de arquivos de dispositivos em Linux: arquivos de dispositivos de caracteres e arquivos de dispositivos de bloco. Um dispositivo de bloco é lido ou escrito em blocos de bytes, geralmente 512. Já um dispositivo de caracter precisa ser lido ou escrito um byte por vez. É importante observar que alguns dispositivos, como fitas, podem ser tratados das duas formas. Outros, como a porta de impressão, só podem ser tratados de uma única maneira. O script MAKEDEV é o mecanismo preferido para criação de arquivos de dispositivos ausentes em /dev/. Em alguns casos, entretanto, MAKEDEV pode não sabe como esse arquivo deve ser criado. Nesse caso, o administrador deve utilizar-se do comando mknod. Para tanto, ele precisa saber os números maior e menor do dispositivo que pretente criar. Uma pesquisa no arquivo devices.txt, disponibilizado junto ao código ou à documentação do kernel pode auxiliar na busca dessa informação. A Figura 3.15 mostra o processo de criação do arquivo /dev/ttyS0 com número maior 4 e número menor 64.

# mknod /dev/ttyS0 c 4 64 # ls -l /dev/ttyS0 crw-rw---1 root root

64 Oct 23 18:23 /dev/ttyS0

Figura 3.15: Exemplo de Uso do Comando mknod

Configuração de Dispositivos

Os números maiores e menores de dispositivos, bem como os nomes dos dispositivos mais comuns, são definidos pela LANANA3 (The Linux Assigned Names And Numbers Authority), parte da Linux Foundation4 , uma organização dedicada a promover, proteger e padronizar o Linux. A Linux Foundation mantém o LSB (Linux Standard Base), um conjunto de padrões para aumentar a compatibilidade entre as distribuições Linux (FREE STANDARDS GROUP, 2006). Entre outros itens, o LSB estipula as bibliotecas básicas do sistema (como libncurses e libpam), os comandos básicos (como md5sum, sendmail e uname), usuários básicos do sistema (root, bin e daemon) e a adoção do RPM como formato preferencial de empacotamento.

3.6

GERENCIAMENTO DINÂMICO DE DISPOSITIVOS COM UDEV, D-BUS E HAL

Um problema recente em projetos de sistemas operacionais é o suporte a dispositivos plugáveis e removíveis. No caso do Linux, a criação de uma árvore estática de dispositivos em /dev totalmente estática tornou-se inviável recentemente, dado o número crescente de tipos de dispositivos, bem como as dificuldades do usuário em verificar quais dispositivos no /dev estariam realmente disponíveis no sistema. Assim, surgiram alguns projetos com o objetivo de permitir um gerenciamento dinâmico de dispositivos, como o hotplug e o devfs. Na série 2.6 do kernel, essa tarefa foi repassada ao udev5 , que permite ao Linux ter um /dev dinâmico, refletindo o hardware, e com a habilidade de nomes de dispositivos de forma mais consistente (KROAH-HARTMAN, 2003). O udev permite, por exemplo, a montagem de um dispositivo por ser número de série ou ID, ao invés de sua posição no barramento IDE. A Figura 3.16 ilustra isso apresentando uma relação de dispositivos de armazenamento plugados em um computador, ressaltando-se o fato que só foram criadas entradas /dev/hdX e /dev/sdX para dispositivos realmente disponíveis. O udev reside totalmente em espaço de usuário, o que facilita em muito sua configuração. Ele é executado como um daemon no Linux e fica à “escuta” de eventos enviados pelo kernel quando um dispositivo é conectado ou removido. O udev gera mensagens D-Bus, o que facilita em muito sua integração com gerenciadores de ambiente e outras aplicações no espaço de usuário, como HAL. D-Bus e HAL são duas importantes aplicações mantidas pela Freedesktop.org. D-Bus é um sistema de mensagens entre processos, facilitando a comunicação entre aplicações. 3 LANANA

http://www.lanana.org/. Foundation http://www.linux-foundation.org/. 5 udev: http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev.html.

4 Linux

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

lrwxrwxrwx lrwxrwxrwx crw------lrwxrwxrwx drwxr-xr-x drwxr-xr-x lrwxrwxrwx lrwxrwxrwx lrwxrwxrwx (...) brw-rw---(...) brw-rw---brw-rw---brw-rw---brw-rw---brw-rw---brw-rw---brw-rw---brw-rw---brw-rw---brw-rw----

1 1 1 1 3 5 1 1 1

root root root root root root root root root

root root tty root root root root root root

3 3 5, 1 11 60 100 9 3 3

1 root cdrom

1 1 1 1 1 1 1 1 1 1

8, 8, 8, 8, 8, 8, 8, 8, 8, 8,

root root root root root root root root root root

disk disk disk disk disk disk disk disk disk disk

2007-09-17 2007-09-17 2007-09-17 2007-09-17 2007-09-17 2007-09-17 2007-09-17 2007-09-17 2007-09-17

05:15 05:15 08:20 05:15 05:15 10:39 08:19 05:15 05:15

cdrom -> hda cdrw -> hda console core -> /proc/kcore cpu disk dsp -> sound/dsp dvd -> hda dvdrw -> hda

0 2007-09-17 05:15 hda 0 1 2 3 4 5 6 7 16 17

2007-09-17 2007-09-17 2007-09-17 2007-09-17 2007-09-17 2007-09-17 2007-09-17 2007-09-17 2007-09-17 2007-09-17

05:15 05:19 05:15 05:15 05:15 05:19 05:19 05:19 05:15 05:19

sda sda1 sda2 sda3 sda4 sda5 sda6 sda7 sdb sdb1

Figura 3.16: Trecho de listagem do Diretório /dev com uso do udev

Ele permite que aplicações se registram para ofertar serviços a outras. De maneira similar, permite que aplicações clientes chequem quais serviços estão disponíveis. O HAL, como comentado anteriormente, provê informações sobre os dispositivos aos gerenciadores de ambiente. Assim, ele acessa informação do hardware, tornando seu acesso transparente, permitindo que um dispositivo possa ser utilizado imediatamente, dada a existência de suporte ao mesmo. Dessa maneira, a utilização de dispositivos tem-se tornado cada vez mais uma tarefa transparente ao usuário, graças ao udev, HAL e D-Bus. Note que para que isso ocorra, é necessário que o dispositivo seja suportado em Linux.

3.7

O DIRETÓRIO /ETC E CONFIGURAÇÕES BÁSICAS DO SISTEMA

A maior parte das configurações de uma instalação Linux pode ser encontrada no diretório /etc/. Isso vale também para configurações referentes ao hardware. Entretanto não existe uma padronização para a configuração de vários itens, incluíndo-se, por exemplo, os serviços iniciados automaticamente e a configuração de rede.

Configuração de Dispositivos

Algumas distribuiçoes costumam centralizar essas configurações em um diretório específico. RedHat e Fedora, por exemplo, utilizam o diretório /etc/sysconfig para uma série de configurações. A Figura 3.17 apresenta mostra trechos de uma listagem desse diretório, obtida através do comando ls -lF. Segue-se uma breve descrição da utilidade dos arquivos aí localizados: -rw-r--r--rw-r--r--rw-r--r--rw-r--r--rw-r--r--rw-r--r--rw-------rw-r--r--rw-r--r--rw-r--r-drwxr-xr-x -rw-r--r--

1 1 1 1 1 1 1 1 1 1 2 1

root root root root root root root root root root root root

39 11 1331 3273 139 952 1471 20 104 56 4096 38

Mai Mai Fev Fev Mai Ago Nov Mai Nov Mai Mai Mai

13 2002 clock 13 2002 desktop 22 2002 harddisks 5 14:05 hwconf 13 2002 i18n 27 2001 init 19 10:47 iptables 13 2002 keyboard 27 10:37 mouse 13 2002 network 13 2002 network-scripts/ 13 2002 pcmcia

Figura 3.17: Trechos do Diretório /etc/sysconfig

clock: informações sobre o fuso horário da máquina. desktop: qual o gerenciador de desktop (ex.: KDE, GNOME ou XFCE) padrão utilizado. harddisks: configurações de acesso a discos rígidos (ex.: uso de DMA). hwconf: informações e configurações diversas sobre dispositivos PCI e USB instalados. i18n: informações para a localização (linguagem padrão) do sistema. init: configurações de cor para o script de inicialização do sistema. iptables: configuração de firewall através do iptables. keyboard: configuração do teclado para o modo texto de uso do Linux. mouse: qual o tipo de mouse utilizado. network: habilitação do uso recursos de rede, o nome e o roteador utilizado pela máquina. network-scripts: diretório contendo arquivos de configuração das diversas interfaces de rede da máquina. pcmcia: configuração de cartões PCMCIA, utilizados principalmente em notebooks. Outras distribuições, como o Gentoo, utilizam o diretório /etc/conf.d/, ilustrado na Figura 3.18, aprentando alguns dos principais arquivos de configuração do sistema, por exemplo: clock para configuração do fuso horário; consolefont para a fonte utilizada no modo texto; net para configuração de rede; e xdm para configuração do gerenciador de

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

logins no ambiente gráfico. O Ubuntu não possui, por outro lado, um subdiretório em /etc para configuração dos dispositivos, inserindo as principais diretamente no /etc ou em um subdiretório específico a cada configuração.

-rw-r--r--rw-r--r--rw-r--r--rw-r--r--rw-r--r--rw-r--r--rw-r--r--rw-r--r--rw-r--r--rw-r--r--rw-r--r--rw-r--r--rw-r--r--

1 1 1 1 1 1 1 1 1 1 1 1 1

root root root root root root root root root root root root root

903 808 233 580 410 430 78 715 123 217 336 542 553

2007-06-23 2007-06-23 2007-06-18 2007-03-23 2007-02-10 2007-07-24 2007-06-23 2007-06-23 2007-06-23 2007-06-23 2007-06-23 2007-06-19 2007-09-09

10:49 10:49 22:41 08:09 15:41 22:45 10:49 10:49 10:49 10:49 10:49 20:16 21:38

clock consolefont cpufrequtils gpm hddtemp hdparm hostname keymaps local.start local.stop net ntp-client xdm

Figura 3.18: Trechos do Diretório /etc/conf.d

Esses exemplos servem para destacar um ponto onde existe pouca padronização. Isso ocorre na verdade porque a configuração desses elementos não é feita diretamente nos arquivos, mas por aplicativos ou scripts chamados durante a inicialização do sistema. Assim, este texto irá dar preferência para a configuração via aplicativos de linha de comando que por arquivos de configuração, sempre que houver falta de padronização quanto à localização e, principalmente, quanto ao formato do arquivo de configuração em si. Após instalado o sistema, pode ser necessário configurar uma série de elementos básicos do sistema, como a localização, fuso horário, entre outros. Boa parte dessas configurações é feita em geral pela ferramenta de instalação ou por utilitários da distribuição. O Fedora, por exemplo, possuía uma série de aplicativos denominados system-config-X, em que X representava um serviço ou item a ser configurado. O SUSE é clássico no uso do YaST (Yet another Setup Tool), uma ferramenta de configuração bastante poderosa. O Ubuntu possui uma série de ferramentas gráficas para configurar os elementos essenciais do sistema. O autor deste não é contra o uso dessas ferramentas para configuração do sistema, mas sim contra a dependência do uso das mesmas. O administrador que não puder repetir a configuração sem o auxílio das ferramentas corre o risco de ter seu conhecimento posto à prova quando for efetuar a configuração em um ambiente que não possua a ferramenta instalada ou quando tiver que utilizar uma outra distribuição. Um conhecimento mais sólido

Configuração de Dispositivos

é garantido entendendo onde as configurações efetuadas pelas ferramentas são armazenadas e como elas são chamadas pelo sistema. Algumas configurações dependem de um serviço em específico. Esse é o caso do ambiente gráfico, que depende de um servidor X-Window instalado. Também é o caso de impressoras e scanners, que irão depender de aplicativos específicos, abordados mais à frente neste capítulo. Outras configurações dependem da configuração de variáveis de ambiente ou da utilização de utilitários básicos do sistema. A configuração do teclado em modo texto, por exemplo, é feito por meio do comando loadkeys, ilustrado na Figura 3.19. Esse comando é parte integrante do pacote kbd, que também disponibiliza o comando setfont, também ilustrado na Figura 3.19. Os mapas de teclado e as fontes de console disponíveis podem ser encontrados nos diretórios /usr/share/keymaps e /usr/share/consolefonts, respectivamente. $ loadkeys -u br-abnt2 Loading /usr/share/keymaps/i386/qwerty/br-abnt2.map.gz $ setfont LatArCyrHeb-16+ -v Loading 512-char 8x16 font from file /usr/share/consolefonts/LatArCyrHeb-16+.psfu.gz Loading Unicode mapping table...

Figura 3.19: Exemplo de Uso dos Comandos loadkeys e setfont

Para configuração do mouse no modo texto, é utilizado o comando gpm, disponível no aplicativo de mesmo nome. Esse pacote disponibiliza ainda um serviço e um arquivo de configuração, o que facilita o carregamento automático durante a inicialização. Um exemplo de uso do comando gpm seria: gpm -m /dev/input/mice -t ps2, que carrega o mouse disponível em /dev/input/mice, usando o barramento PS/2. O uso de Cabe destacar que as configurações feitas com loadkeys, setfont e gpm dizem respeito ao modo texto do Linux somente. A configuração do teclado e mouse no X-Window é feita à parte e será vista mais à frente neste capítulo.

3.8

CONFIGURAÇÃO DO LOCALE

Uma configuração essencial é a localização do sistema (locale), especificando a língua padrão e a codificação de caracteres adotadas, se UTF-8, ISO8859-1, por exemplo. As aplicações em Linux geralmene são internacionalizadas, ao invés de traduzidas. Ou seja: ao invés de se obter uma versão de um dado programa em português, obtém-se o programa original com mensagens e configurações para vários idiomas. Obviamente exis-

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

tem aplicativos que ainda não foram internacionalizados e aplicativos que são realmente traduzidos ou adaptados a um idioma ou país, caso do BrOffice.org, uma adaptação do OpenOffice.org ao território nacional. Além das mensagens traduzidas, o BrOffice.org, possui alguns utilitários específicos ao Brasil, como dicionários, ferramentas de correção, etc. Mas, casos como esse são excessões e em geral os aplicativos de uso mais frequente são internacionalizados. O locale do sistema não é configurado por meio de um aplicativo, mas sim por meio de variáveis de ambiente. Isso é feito dessa forma para permitir que em um dado sistema possam ser executadas várias aplicações ao mesmo tempo com variáveis de ambiente diferentes. Ou seja, bastaria o usuário alterar localmente as variáveis de locale em um terminal para ter a possibilidade de iniciar aplicativos com localização diferenciada de sua padrão. Por outro lado, o usuário deve se atentar que essas configurações não são permanentes, ou seja: é necessário redefinir os valores das variáveis a cada sessão. A configuração de locale é feita geralmente configurando-se as variáveis: LC_COLLATE: altera o comportamento de funções utilizadas para comparar strings no alfabeto local. LC_CTYPE: define o comportamento de funções para classificar e manusear caracteres, como conversão para maiúsculas, por exemplo. LC_MONETARY: define o comportamento da função localeconv(), que descreve a maneira como valores monetários são impressos, com detalhes sobre uso de vírgula ou ponto decimal. LC_MESSAGES: altera a localização das mensagens do sistema, informando ainda como frases afirmativas ou negativas devem se parecer. LC_NUMERIC: determina a forma de impressão de valores numéricos, informando sobre o uso de separadores de milhares, por exemplo. LC_TIME: define o comportamento do locale para formatação de horários e datas, especificando, por exemplo, se os horários serão impressas utilizando-se 12 ou 24 horas por padrão. Essas variáveis podem ser configuradas todas de uma única vez, usando-se para isso a variável geral LANG ou LC_ALL. A variável LANG especifica um valor padrão para variáveis de internacionalização que não estão configuradas ou são nulas. Já LC_ALL sobrescreve todos os valores das variáveis de localização e tem precedência sobre as demais. Como especificado em (THE OPEN GROUP, 2004), ao se buscar uma configuração de locale para uma dada categoria, é retornado o valor que satisfaça primeiro uma das seguintes condições:

Configuração de Dispositivos

1. Se a variável LC_ALL estiver configurada, então seu valor é utilizado. 2. Se uma variável de localização (LC_* estiver configurada para a categoria solicitada, então o valor dessa variável é utilizado. 3. Se a variável LANG estiver configurada, então seu valor é utilizado. 4. Se LANG não estiver configurada, ou estiver vazia, então é utilizado o locale padrão do sistema operacional. A Figura 3.20 mostra como obter as localizações disponibilizadas no sistema, como obter a localização atual e como configurar uma determinada localização (utilizando o comando export). É recomendável que a configuração da localização seja chamada por algum script de inicialização, o que geralmente é feito na grande maioria das distribuições. Caso a localização de interesse não esteja disponibilizada no sistema, outras podem ser criadas utilizando-se o comando localedef. Uma observação adicional é que é recomendável, cada vez mais, a adoção do UTF-8 (8-bit Unicode Transformation Format) como padrão de codificação de caracteres. Esse formato, apresentado inicialmente em (PIKE; THOMPSON, 1993) e especificado em (YERGEAU, 2003), tem-se disseminado como padrão para várias aplicações. Isso ocorre porque o UTF-8 consegue representar qualquer caracter universal padrão do Unicode6 , sendo também relativamente compatível com o ASCII. O UTF-8 é requerido como pela IETF (Internet Engineering Task Force)7 para adoção nos protocolos utilizados na internet (ALVESTRAND, 1998) e pelo IMC (Internet Mail Consortium)8 nos aplicativos de e-mail, que devem ser capazers de ler e criar mensagens usando UTF-8 (INTERNET MAIL CONSORTIUM, 1998). Isso acaba por gerar toda uma necessidade pela adoção do UTF-8 como codificação padrão de caracteres, o que é recomendado fortemente por este autor. Outro elemento de localização é a configuração do fuso horário (timezone), facilitando a indicação correta da hora local. Essa configuração é feita atribuindo-se um valor para a variável de ambiente TZ. Por exemplo, para especificar o fuso horário na região sudeste, bastaria se executar o comando TZ=’America/Sao_Paulo’. Para localizar a zona horária da região onde o usuário se encontra, pode-se utilizar o tzselect, um comando interativo que vai refinando o fuso, a partir dos continentes até o Estado ou província em questão. 6 Unicode:

http://www.unicode.org/. http://www.ietf.org/. 8 IMC: http://www.imc.org/.

7 IETF:

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

$ locale -a C en_GB en_GB.utf8 en_US en_US.utf8 POSIX pt_BR pt_BR.utf8 $ export LANG=pt_BR.utf8 LC_ALL=pt_BR.utf8 $ locale LANG=pt_BR.utf8 LC_CTYPE="pt_BR.utf8" LC_NUMERIC="pt_BR.utf8" LC_TIME="pt_BR.utf8" LC_COLLATE="pt_BR.utf8" LC_MONETARY="pt_BR.utf8" LC_MESSAGES="pt_BR.utf8" LC_PAPER="pt_BR.utf8" LC_NAME="pt_BR.utf8" LC_ADDRESS="pt_BR.utf8" LC_TELEPHONE="pt_BR.utf8" LC_MEASUREMENT="pt_BR.utf8" LC_IDENTIFICATION="pt_BR.utf8" LC_ALL=pt_BR.utf8

Figura 3.20: Uso do comando locale

3.9

CONFIGURAÇÃO DE REDE

A configuração de rede envolve, em geral, dois processos. Inicialmente é necessário informar ao kernel qual o módulo associado às placas de rede instaladas, se ele não tiver carregado por padrão. Isso é feito, como já comentado, através do arquivo /etc/modules.conf ou de forma dinâmica pelo udev. O segundo passo é informar a configuração básica de rede associada a esse dispositivo. Entre as informações necessárias, constam: • nome da máquina no ambiente de rede; • o roteador (gateway) utilizado para o acesso à internet; • o endereço IP e a máscara de rede utilizada; • endereço do servidor responsável pela resolução de nomes (DNS).

Configuração de Dispositivos

Observe que, além das interfaces tradicionais, a máquina possui uma interface de loopback, com IP 127.0.0.1. Essa interface é usada para tráfego TCP ou UDP local. Mesmo que a máquina não esteja conectada a uma rede, essa interface é essencial para vários serviços, entre eles o servidor gráfico. Isso ocorre porque a arquitetura do Linux foi montada sobre TCP/IP. Assim, mesmo não estando conectado à internet, se a rede não estiver habilitada, vários serviços deixam de funcionar. Para isso, ao menos a interface de loopback precisa estar habilitada, o que geralmente ocorre por padrão. A configuração de rede pode ser feito pelo uso do comando ifconfig ou ip addr, atribuindo-se um IP a uma interface de rede. Além disso, é necessário a configuração das rotas da rede local, em especial a rota padrão, através do comando route ou ip. A última informação necessária à configuração da rede é o IP do servidor de nomes, utilizando o arquivo /etc/resolv.conf. Um endereço IP, na versão 4, é um conjunto de 4 números de 0 até 255, separados por ponto, ex: 192.168.4.1. Esse endereço é dividido em duas partes: o endereço da rede e o endereço do host, sendo que primeira parte é o endereço da rede, e o restante é o endereço do host. Existe uma versão recente do endereço IP, o IPv6, mas ainda não encontra-se totalmente difundido. De qualquer maneira, a configuração de rede ocorre de forma relativamente similar, apenas com endereços maiores, ou abreviados de acordo com a especificação do IPv6. O tamanho da rede, ou o número de hosts que uma rede pode ter, depende do tamanho do endereço da rede, e do tamanho do endereço do host. E para organizar melhor as redes, elas foram divididas em classes, definidas a partir do endereço da rede. As redes classe ’A’ possuem endereços entre 1.0.0.0 e 127.255.255.255, sendo o endereço da rede o primeiro número. As redes classe ’B’ possuem endereços entre 128.0.0.0 e 191.255.255.255, sendo o endereço da rede os dois primeiros números. As redes classe ’C’ possuem endereços entre 192.0.0.0 e 223.255.255.255, e o endereço da rede são os três primeiros números. Por fim, as redes classes ’D’ possuem endereço entre 224.0.0.0 e 239.255.255.255 e as redes classes ’E’ possuem endereço entre 240.0.0.0 e 255.255.255.255. As duas últimas são experimentais ou tem uso específico, e por isso não definem nenhuma rede. Os números 0 e 255 tem características especiais, e por isso não podem ser usados para definir o endereço de um host. O primeiro define uma rede, e é chamado de endereço de broadcast. Então o IP 192.168.4.1 é um host da rede 192.168.4.0. O segundo número se refere a todos os hosts de uma rede. Portanto o IP 192.168.4.255 significa todos os hosts da rede classe C 192.168.4.0. A Tabela 3.1 ilustra esses conceitos.

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

Tabela 3.1: Divisão do endereço IP e Classes

Endereço Endereço da rede Endereço do host Classe 192.168.4.1 192.168.4.0 1 C 135.33.140.29 135.33.0.0 140.29 B 97.44.150.32 97.0.0.0 44.150.29 A

Para suportar a grande variedade de hardware disponível no mercado, o protocolo TCP/IP define uma interface abstrata através da qual o hardware é acessado. Essa interface oferece um conjunto de funções idênticas para todos os tipos de hardware. Para cada hardware que se deseje utilizar na rede, uma interface correspondente deve estar presente no núcleo do sistema. O nome das interfaces varia de acordo com tipo de hardware a ela associado, como por exemplo as interfaces ethernet chamam-se eth0, eth1 . . . ethn, as interfaces PPP chamam-se ppp0, ppp1 . . . pppn, assim por diante. Além disso, para que uma interface possa ser utilizada em uma rede, a mesma precisa ter um endereço IP associado a ela, o qual serve como sua identificação ao comunicar-se com o resto do mundo. Como comentado anteriormente, a configuração dos dispositivos de rede pode ser feito através do comando ifconfig ou ip, como ilustrado na Figura 3.21, onde # indica comentários e $ indica comandos executados em um terminal. # Atribuíndo o IP 10.100.100.1 para eth0 $ ifconfig eth0 10.200.100.1 netmask 255.0.0.0 # Criando eth0:0 e definindo seu IP como 192.168.50.1 ifconfig eth0:0 192.168.50.1 netmask 255.255.255.0 # Definindo rota padrao route add default gw 10.200.0.1 # Definindo uma rota estática para a rede 10.200.200.0 route add -net 10.200.200.0 netmask 255.255.255.0 gw 10.200.200.1 # $ $ $ $

Repetindo os comandos usando o comando ip apenas ip addr add 10.100.200.1/8 dev eth0 ip addr add 192.168.25.1/24 dev eth0 label eth0:0 ip route add default via 10.100.0.1 dev eth0 ip route add 10.100.100.0/24 via 10.100.100.1 dev eth0

Figura 3.21: Exemplos de Uso dos Comando ifconfig e ip

Configuração de Dispositivos

Como visto na Figura 3.21, o comando ip, parte integrante do pacote iproute2 é extremamente poderoso, substituindo, com grandes vantagens, os comandos ifconfig, route, além de outros. Com ele é possível definir firewall via filtro de pacotes, tunelamento, entre outros controles. Recomenda-se ao leitor a leitura de sua documentação (incluindo sua página de manual) para maiores detalhes. Cabe observar ainda na Figura 3.21 que foi criada uma inteface virtual eth0:0 para atribuição de dois endereços IPs no mesmo dispositivo de hardware. A rota padrão de uma rede é especificada indicando-se o gateway responsável pela ligação da rede local com a internet. Em geral, na maioria dos casos, essa é a única rota que necessita ser especificada. Para se visualizar as rotas atuais, basta digitar o comando route ou ip route show. Para verificar a configuração de rede de uma dada interface xxxn, é possível utilizar o comando ifconfig xxxn ou ip addr show xxxn. Caso esses comandos sejam executados sem especificar a interface, então será listado a configuração de todos os dispositivos de rede detectados pelo sistema. O endereço IP de um host é um número de 32 bits, que muitas vezes não é fácil de ser lembrado. Entretanto, é possivel chamar um host de “superhomem” ou “hamster”. O processo de transformar esses nomes comuns em endereços IP é chamado resolução do nome de um host. Existem formas diferentes de transformar nomes em IP. Uma delas, e a mais simples, é adicionar um IP associado a um nome no arquivo /etc/hosts. Esse processo, entretanto, é pouco eficiente, por ser estático e manual. O mecanismo mais utilizado para resolver nomes é o DNS (Domain Name System), um sistema hierárquico para associação de nomes a endereços IPs. A configuração do servidor DNS da estação é feita editando-se o arquivo resolv.conf, ilustrado na Figura 3.22. # indica os domínios locais para buscas sem ser necessário # digitar todo o domínio (ex.: www, ao invés de www.dominio.com.br) search dominio.com.br # servidor DNS primário nameserver 200.131.101.21 # servidor DNS secundário (caso exista) nameserver 200.131.102.1

Figura 3.22: Exemplo de Arquivo resolv.conf

Em algumas redes, as configurações apresentadas nesta seção são atribuídas de forma dinâmica (endereço IP, gateway, servidor DNS). Isso é feito por meio do DHCP (Dynamic Host Configuration Protocol), um protocolo para configuração dinâmica de estações. Nesse caso, basta que esteja instalado no computador um cliente DHCP e que ele seja iniciado. Em geral, a maior parte das distribuições atuais possui um cliente DHCP e inicializa-o au-

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

tomaticamente caso não seja especificao um endereço de rede fixo para os dispositivos de redes instalados no computador.

3.10

MODEMS

A configuração de um Modem em Linux pode ser uma tarefa trivial ou uma verdadeira batalha, dependendo de qual a marca e modelo do Modem. Isso ocorre porque a maioria dos Modems vendidos atualmente na verdade não são equipamentos baseados em hardware. Em geral, eles dependem de um software específico para funcionar adequadamente. Como a maioria dos fabricantes só no ano passado começaram a abrir os olhos para o mercado de usuários Linux, o suporte a esse tipo de Modem ainda não é o desejado. Os equipamentos que são baseados totalmente em hardware costumam ser chamados de hardmodems. Esses dispositivos não precisam de nenhuma configuração especial, pois o Linux já associa a ele o dispositivo /dev/modem, faltando informar apenas os dados de conexão ao provedor. Os modelos que necessitam de uso de software, por sua vez, são chamados de softmodems ou, como a maioria só funcionava inicialmente em Windows 9x, winmodems. Nesse caso, a primeira coisa a fazer é saber se o dispositivo já é suportado em Linux. Em alguns casos, o fabricante se nega a dar informações sobre o mesmo, o que dificulta imensamente esse suporte. Para saber se um dado softmodem é suportado, basta visitar http: //www.linmodems.org/ ou http://www.idir.net/~gromitkc/winmodem.html. No caso do softmodem ser suportado, em geral é necessário baixar os arquivos, compilálos localmente, instalá-los e carregar os respectivos módulos, conforme processo descrito na Seção 3.3. A partir daí, caso não haja falha, também basta informar os dados de conexão ao provedor. A configuração do provedor pode ser feita de várias maneiras e com o uso de inúmeros aplicativos. Entre os aplicativos mais comuns em modo texto, merece destaque o wvdial. Em modo gráfico, recomenda-se o uso do vppp, KPPP, ou mesmo o linuxconf. Consulte a documentação desses programas para maiores detalhes.

3.11

INTERFACE GRÁFICA

A interface gráfica mais utilizada em ambiente UNIX é denominada X Window, X Window System, ou simplesmente X. O X é responsável, portanto, por oferecer uma GUI (Graphical User Interface) ao usuário, baseada em menus e botões, acessíveis a cliques do mouse.

Configuração de Dispositivos

Em geral, o usuário Linux já possui experiência com outros ambientes gráficos, entretanto o X possui algumas características que o tornam totalmente peculiar. A maior parte dessa peculariedade reside no fato que ele é uma ferramenta orientada à rede. Dessa maneira é extremamente simples redirecionar a saída gráfica de uma aplicação para outras máquinas. Em outras palavras: ferramentas como o Terminal Server da Microsoft existem há muito tempo no mundo UNIX e de uma forma muito melhor. Assim, limitado apenas pela velocidade e largura de banda da rede, é possível iniciar uma seção gráfica na máquina local, acessar um computador remoto, iniciar um programa gráfico nesse computador remoto, mas visualizando-o na máquina local. Uma observação a ser feita é que o servidor X reside na máquina local do usuário. Ele “serve” uma interface gráfica que pode ser usada por clientes remotos. Dada a forma como o X trabalha, algumas de suas características destacam-se: 1. X pode ser configurado para utilizar um servidor de fontes, para controlar a renderização de fontes. Dessa maneira, é possível ter uma única máquina como servidora de fontes em um ambiente de redes, simplificando o processo de instalação e manutenção de fontes. Em ambientes comuns, entretanto, para evitar tráfego de rede, recomenda-se o uso de servidores locais, o que é feito na maioria das distribuições. 2. Por causa da habilidade de executar aplicativos gráficos remotos, pode ser necessário cuidados extras com a segurança. Isso pode ser conseguido com uso simples de firewall. 3. X é extremamente flexível, permitindo combinações ilimitadas de configuração do ambiente de trabalho, aumentando o grau de personalização de uso da máquina. Além disso, é uma ferramenta poderosa para administração gráfica remota, bem como para configuração de terminais. 4. Obviamente, por causa das características de rede, X tende a ser levemente mais lento que outros ambientes GUI, dado que é processado através de um protocolo. Em hardware moderno isso é imperceptível mesmo com ferramentas de análise de desempenho. Como X pode ser usado em rede, uma máquina precisa saber onde ela irá exibir aplicações gráficas. Isso é feito através da variável de ambiente DISPLAY. Em geral, clientes SSH configuram essa variável para o usuário. Caso não esteja configurada basta digitar: # export DISPLAY=host:dispnum

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

Nesse caso host é o nome da máquina onde a aplicação será exibida e dispnum o número do display gráfico. Geralmente displaynum vale 0, mas em máquinas com mais de um servidor X rodando, pode receber valores maiores. Para iniciar um segundo ambiente gráfico, basta digitar: startx - - :1 vt8 Isso iniciará o X no terminal virtual 8. Em Linux, é possível ter vários consoles em uma mesma máquina. Os consoles de 1 a 6 são consoles de modo texto. O console 7, por padrão, é utilizado para o ambiente gráfico primário. Para ir de um console a outro basta digitar Ctrl+Alt+F#, onde # é o número do console. Assim, bastaria digitar Ctrl+Alt+F7 para ir ao primeiro ambiente gráfico e Ctrl+Alt+F8 para ir ao segundo, desde que ele esteja ativado. Observe que, como os gerenciadores de janela suportam múltiplos ambientes de trabalho, não faz muito sentido utilizar dois ambientes gráficos. A única excessão para isso é quando se quer iniciar um segundo ambiente gráfico para outro usuário ou quando se quer iniciar uma nova sessão com outra resolução gráfica que não a padrão. Como será visto no Capítulo 5 é possível configurar a máquina para iniciar automaticamente em ambiente gráfico. Caso isso não tenha ocorrido, entretanto, basta executar startx no prompt. Para controlar o acesso remoto, basta utilizar-se o comando xhost. De uma forma geral “xhost +” permite que qualquer máquina exiba programas gráficos no servidor X local e “xhost -” nega esse acesso a qualquer máquina e usuário que não o que está logado no ambiente gráfico. Note que o comando xhost efetua essas configurações individualmente. Caso pretenda-se uma configuração geral para todos os usuários, o ideal é usar recursos de firewall. 3.11.1

Configuração do X

A implementação do X utilizada preferencialmente no Linux é a X.Org, disponível em http://www.x.org/. Essa implementação foi derivada do XFree869 , por conflito entre os desenvolvedores a respeito da metodologia de desenvolvimento e mudança no licenciamento do XFree86 em versões mais recentes. O desenvolvimento de uma versão própria da Fundação X trouxe um aceleramento ao processo de desenvolvimento, melhorando em muito o uso de interface gráfica no Linux. Com o X.Org, é possível: Múltiplos Displays: o usuário pode instalar várias placas de vídeos no computador usar o X para para criar um único ambiente virtual que transpõe os displays das placas. 9 XFree86:

http://www.xfree86.org/.

Configuração de Dispositivos

Estrutura Modular: O X.Org, como a versão 4 do XFree86, utiliza um único servidor, que carrega um módulo associado à placa. Essa estrutura, similar ao kernel, permite uma maior flexibilidade, pois pode incorporar módulos compilados, desenvolvidos pelos fabricantes das placas gráficas. Suporte ao DDC: O canal de display de dados (DDC – Data Display Channel) é um protocolo para comunicação em máxima velocidade entre placas de vídeos, driver da placa de vídeo e monitores. O suporte ao DDC foi inserido com o XFree86 4 e incorporado ao X.Org. Suporte à Fontes True Type: XFree86 4 adicionou suporte nativo à fontes True Type, recurso também incorporado ao X.Org. Suporte DRI: DRI (Direct Rendering Infraestructure) é um padrão para uso acelerado de hardware de vídeo. O uso de DRI permite que aplicações Linux tirem o máximo de proveito de placas gráficas com aceleração 3D (em especial as que oferecem suporte OpenGL). Para o administrador, além dessas vantagens, a melhor de todas é um arquivo de configuração bastante amigável. Esse arquivo, localizado em /etc/X11/xorg.conf é composto, em geral, das seguintes seções: ServerLayout: Essa seção configura aspectos gerais do servidor, como dispositivos de entrada e saída. Grandes chances existem de nada precisar ser alterado nessa seção a partir de uma configuração padrão. Module: Nessa seção, ilustrada na Figura 3.23, são informados os módulos que o servidor deve carregar, como o suporte DRI ou ao Video4Linux. Também não é preciso modificar muita coisa, exceto se DRI não está habilitado e inseriu-se uma placa com esse suporte DRI: Aqui são definidas as permissões de acesso ao suporte DRI. Uma simples linha nessa seção, com a informação “Mode 0666”, permite acesso a todos os usuários. Files: Essa seção inclui o caminho de diretórios importantes ao X. O mais importante é o caminho das fontes. Caso essa seção esteja como a da Figura 3.24 é porque o X está usando um servidor de fontes local, na porta 7100. InputDevice: Nessa seção, são configuradas as informações sobre teclado e mouse. A Figura 3.25 mostra uma configuração típica para teclado ABNT2 e mouse PS/2. Para teclado internacional, basta remover a linha XkbModel e trocar a linha XkbLayout de br para us-intl. Device: Essa seção informa o driver utilizado pela placa de vídeo. A Figura 3.26 mostra um exemplo dessa seção, configurada para uma ATI Radeon.

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

Section "Module" Load "dbe" # Double-buffering Load "GLcore" # OpenGL support Load "dri" # Direct rendering infrastructure Load "glx" # OpenGL X protocol interface Load "extmod" # Misc. required extensions Load "v4l" # Video4Linux # Load "record" # X event recorder # You only need the following two modules if you do not use xfs. # Load "freetype" # TrueType font handler # Load "type1" # Adobe Type 1 font handler EndSection Figura 3.23: Seção Module do /etc/X11/xorg.conf Section "Files" FontPath "unix/:7100" EndSection

Figura 3.24: Seção Files do /etc/X11/xorg.conf Section "InputDevice" Identifier "Keyboard0" Driver "keyboard" Option "XkbModel" "abnt2" Option "XkbLayout" "br" EndSection Section "InputDevice" Identifier "Mouse0" Driver "mouse" Option "Device" "/dev/mouse" Option "Protocol" "PS/2" Option "Emulate3Buttons" "on" Option EndSection

Figura 3.25: Seção InputDevice do /etc/X11/xorg.conf

Configuração de Dispositivos

Section "Monitor" Identifier "Samsung SyncMaster 753dfx" VendorName "Unknown" ModelName "Unknown" HorizSync 30-70 VertRefresh 50-160 Option "dpms" EndSection Section "Device" Identifier "ATI|Radeon VE QY" Driver "radeon" BoardName "Unknown" EndSection

Figura 3.26: Seções Monitor e Device do /etc/X11/xorg.conf

Monitor: Essa seção, também ilustrada na Figura 3.26, configura as especificações do monitor. As principais especificações são a freqüência horizontal de sincronização e a taxa de atualização vertical. Essas informações são disponibilizadas com os manuais dos monitores. Screen: Na seção Screen é configurada a resolução e o número de cores utilizadas. A Figura 3.27 mostra um exemplo de configuração utilizando a placa de vídeo e o monitor configurados na Figura 3.26.

Section "Screen" Identifier "Screen0" Device "ATI|Radeon VE QY" Monitor "Samsung SyncMaster 753dfx" DefaultDepth 24 Subsection "Display" Depth 24 16 Modes "1400x1050" "1280x1024" "1024x768" "800x600" EndSubSection EndSection Figura 3.27: Seção Screen do /etc/X11/xorg.conf

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

Maiores detalhes sobre a edição do arquivo /etc/X11/xorg.conf podem ser encontradas na respectiva página de manual: man xorg.conf e nas páginas de manuais dos módulos. Usuários de placas SiS, por exemplo, podem obter auxílio usando man sis. Também é possível utilizar o xorgconfig, ou xorgcfg, ferramentas de configuração do X.

3.12

IMPRESSORAS

Por motivos históricos, programas UNIX utilizam impressoras fazendo a consideração que ou a impressora não possui formatação alguma (portanto só imprime caracteres de texto) ou então a impressora disponível é uma impressora PostScript. PostScript é uma linguagem de descrição de página (PDL – Page Description Language), criada pela Adobe e descrita em (ADOBE SYSTEMS INCORPORATED, 1999). A maioria das impressoras PostScript utilizam um interpretador licenciado pela Adobe. Outra PDL bastante conhecida também é PCL (de Printer Command Language), desenvolvida pela HP e utilizada quase que exclusivamente em suas impressoras. Com raríssimas excessões, aplicações UNIX não conseguem gerar saída PCL, portanto é necessário um estágio intermediário de conversão. O leitor talvez se questione: porque PostScript? Inicialmente, a grande maioria das impressoras laser eram caríssimas e suportavam essa PDL. Assim, a linguagem PostScript parecia apontar como uma padronização futura para impressoras, simplificando a tarefa. Isso acabou não acontecendo e os modernos SOs acabam por colocar uma camada intermediária entre impressora e aplicação: a aplicação aciona comandos para imprimir em uma impressora genérica e o SO converte esses comandos em comandos próprios da impressora. No mundo UNIX, essa impressora genérica é uma impressora PostScript. Caso a impressora do usuário seja inclusive PostScript é possível enviar arquivos PS diretamente para impressora. Como a grande maioria das impressoras de início de linha não aceitam essa linguagem, é necesário converter o arquivo PostScript gerado pela aplicação para um formato compreensível pela impressora. Isso é feito utilizando-se um “filtro”. Para ser mais exato, considera-se um filtro qualquer programa que intermedie o processo de impressão, seja entre a aplicação e o gerenciador de impressão, seja entre o gerenciador de impressão e a impressora. Assim, por exemplo, existem filtros para contabilidade de impressão, bem como filtros para converter de um formato para PostScript. Assim, dependendo dos filtros instalados, é possível imprimir diretamente um arquivo PDF. O arquivo PDF é convertido por um filtro, como o apsfilter ou magicfilter, em

Configuração de Dispositivos

um arquivo PS que é enviado ao gerenciador de impressão. Esse gerenciador, também chamado de “spooler”, utiliza-se de outro filtro para converter o arquivo PS em comandos próprios da impressora ou o envia diretamente, no caso de uma impressora PostScript. Um spooler exerce outras funções, obviamente: ele é responsável por armazenar trabalhos de impressão, de forma que é possível mandar um arquivo para impressão, mesmo que a impressora já esteja imprimindo. Assim, o spooler recebe, armazena e prioriza trabalhos de impressão, enviando-os posteriormente para a impressora. Como PostScript é a linguagem nativa do sistema de impressão do UNIX, o administrador irá precisar de um filtro que converta um arquivo nesse formato para a linguagem da impressora. Apesar que atualmente existem inúmeros filtros para isso, a maioria das impressoras irá utilizar um filtro baseado no uso do Ghostscript. Ghostscript é uma aplicação multiplataforma que disponibiliza uma série de ferramentas e bibliotecas para trabalhar com arquivos PostScript. Todas as distribuições Linux direcionadas a um usuário final disponibilizam o Ghostscript em suas mídias de instalação. Para saber se uma impressora é suportada em Linux (e a maioria o é), é recomendável visitar a OpenPrinting10 , antiga Linux Printing. O leitor irá descobrir que essa organização tem um esforço forte de disponibilização de filtro (ou drivers) para a maioria das impressoras em uso atualmente. O esforço de criar uma camada à parte do Ghostscript para a configuração desses filtros recebe o nome de Foomatic. Sabendo da existência do driver, resta agora a escolha do spooler. Apesar de não serem os únicos, havendo inclusive alternativas comerciais, os spoolers mais utilizados são o BSD lpd, o LPRng e o CUPS. O lpd (de Line Print Daemon) é a alternativa tradicional e vem aos poucos sendo substituído pelo LPRng ou pelo CUPS, à escolha das distribuições ou do administrador. Observe que a grande maioria das impressoras de rede ou gerenciadores de impressão utilizam, a bem da verdade, uma implementação do lpd. O lpd consiste, principalmente, dos seguintes aplicativos: o lpd (o servidor), o lprm (para remover impressões da fila), o lpq (para listar a fila de impressões) e o lpc para controlar a fila (reordenando-a, por exemplo) ou impressora. Para enviar arquivos para a impressora, existe ainda o comando lpr. A Figura 3.28 ilustra o exemplo de envio de um trabalho para a impressora, a listagem dos trabalhos pendentes e o cancelamento de uma impressão. A opinião dos autores deste texto é que o administrador não deve fazer uso do BSD lpd por vários motivos, entre eles o fato desse spooler possuir mais brechas de segurança que as alternativas. Essa opinião também é defendida em (STANFIELD; SMITH, 2001) e (NEMETH et al., 2001). Assim, a escolha deve recair sobre o LPRng ou o CUPS.

10 OpenPrinting:

http://www.linux-foundation.org/en/OpenPrinting/.

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

# lpr admsis.ps # lpq hp4l is Rank active 1st

ready and printing Owner Job File(s) joukim 39 admredes.ps joukim 40 admsis.ps

Total Size 1823744 bytes 4931521 bytes

# lprm 40 #lpq hp4l is ready and printing Rank Owner Job File(s) active joukim 39 admredes.ps

Total Size 1823744 bytes

Figura 3.28: Exemplo de Comandos de Impressão

O LPRng é um spooler bastante recente baseado numa reescrita do BSD lpd. Assim, ele é altamente compatível com esse sistema, aceitando os comandos citados anteriormente. Com a reescrita, entretanto, o LPRng (de Line PRinter new generation tornou-se um servidor mais estável e seguro (por poder ser executado sem poderes de root) e seus aplicativos oferecem novos recursos ao administrador e ao usuário. Observe que tanto o lpd quanto o LPRng seguem o Line Printer Daemon Protocol, apresentado em (III, 1990). Uma característica interessante do LPRng é que ele é um servidor mais leve que o BSD lpd e permite redirecionamento de filas de impressão e múltiplas impressoras em uma única fila. O LPRng pode ser obtido em http://www. lprng.com/. Quanto à configuração de impressoras, tanto o LPRng quanto o BSD lpd geralmente utilizam um arquivo denominado /etc/printcap. Obviamente o LPRng suporta mais opções para esse arquivo. A Figura 3.29 mostra um exemplo desse arquivo e a Tabela 3.29 explica as opções mais comuns. Note que o arquivo /etc/printcap usa ‘:’ para separar os campos. Além disso as linhas lp|hp4l|hp e sc|stylus|epson são nomes das impressoras instaladas. Observe que, dessa maneira, uma impressora pode ser ter vários nomes. A impressora de nome lp é assumida como sendo a impressora padrão. Caso não haja uma impressora com esse nome, é utilizada a primeira na fila do /etc/printcap. Uma forma melhor de configurar a impressora é utilizar-se do printtool, disponibilizado com o LPRng.

Configuração de Dispositivos

lp|hp4l|hp:\ :sd=/var/spool/lpd/hp4l:\ :mx#0:\ :sh:\ :lp=/dev/lp0:\ :if=/var/spool/lpd/hp4l/filter: sc|stylus|epson:\ :sd=/var/spool/lpd/stylus:\ :mx#0:\ :sh:\ :rm=server3:\ :rp=printer1:\ :if=/var/spool/lpd/stylus/filter:

Figura 3.29: Um Exemplo de Arquivo /etc/printcap Tabela 3.2: Variáveis do Arquivo /etc/printcap

Nome

Tipo

sd lf lp af rm rp of if mx sh

string string string string string string string string número booleano

Significado diretório de spool arquivo de log nome do dispositivo de impressão arquivo de contabilidade nome da máquina remota onde está a impressora nome da impressora na máquina remota filtro de saída filtro de entrada tamanho máximo do arquivo impresso (0 = infinito) suprimir cabeçalho

Uma alternativa totalmente radical para impressão é o CUPS (Common Unix Printing System). Disponível em http://www.cups.org/, o CUPS não utiliza o /etc/printcap para configuração e usa novos protocolos de rede para impressão. Para impressão em rede, o CUPS implementa e utiliza a versão 1.1 do IPP (Internet Printing Protocol), descritos em (HERRIOT, 2000), (HASTINGS, 2000) e (HASTINGS et al., 2001). Como comentado em (SWEET, 2002), o IPP extende o protocolo HTTP, descrito em (FIELDING et al., 1999), para adicionar suporte à impressão remota. Além disso, o IPP está se tornando bastante aceito pela indústria de impressoras e servidores de impressão. O

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

IPP é protocolo para impressão e gereciamento de impressão sobre IP, podendo ser usado localmente ou via internet. Uma diferença drástica do IPP sobre padrão POSIX, entretanto, é que ele oferece um suporte forte a controle de acesso, autenticação e encriptação (o CUPS já oferece suporte TLS). Uma observação final a ser feita sobre o IPP é que ele foi desenvolvido para se tornar padrão em vários SOs11 . Por esses e outros motivos, a maior parte da equipe técnica do ARL prefere o CUPS em seus sistemas. Pelo fato de usar o HTTP como base, a configuração do CUPS e das impressoras é extremamente semelhante à configuração do servidor Web, o Apache. Uma forma extremamente prática de configurá-lo é apontar um navegador para a porta utilizada pelo CUPS (a padrão é 631). Em algumas instalações é disponibilizado o aplicativo cupsconfig ou cupswebconfig que nada mais faz do que chamar o navegador padrão no endereço http://localhost:631/. A Figura 3.30 apresenta a tela principal de configuração do CUPS. Observe, que se o servidor CUPS permitir isso, é possível, inclusive, fazer configuração remota. É importante observar na Figura 3.30 que é possível criar classes de impressoras. Dessa maneira um trabalho enviado para imprimir numa classe será direcionado para a primeira impressora livre dessa classe. O gerenciamento de impressoras também não é complicado, como mostra a Figura 3.31. Além da configuração por navegador, existem aplicativos que permitem configuração gráfica do CUPS, podendo ser destacados o KUPS (http://kups.sourceforge.net) e o XPP (http://cups.sourceforge.net/xpp/). Entretanto, como já comentado, a configuração básica do CUPS segue o formato do Apache, não sendo complicado editá-la usando apenas um editor de textos. Os arquivos de configuração do CUPS ficam disponibilizados no diretório /etc/cups. Os mais importantes são os arquivos /etc/cups/cupsd.conf, que configura o servidor, e /etc/cups/printers.conf, responsável pela configuração das impressoras. No arquivo /etc/cups/cupsd.conf é possível informar os diretórios utilizados pelo CUPS, bem como impor controle de acesso de forma semelhante ao Apache. Mais detalhes sobre o controle de acesso do Apache (e que podem ser usados no CUPS) serão vistos em (UCHÔA, 2008). Um arquivo de configuração de impressoras no CUPS é mostrado na Figura 3.32. A configuração de uma impressora inicia-se com <Printer nome_da_impressora> e é terminada com </Printer>. No caso de impressora padrão, é possível iniciar essa configuração também com <DefaultPrinter nome_da_impressora>. A Tabela 3.3 explica os principais campos utilizados nessa configuração. 11 O

IPP é suportado, inclusive, em sistemas não-UNIX, como o Windows 2000.

Configuração de Dispositivos

Figura 3.30: Configurando o CUPS via Navegador

Tabela 3.3: Variáveis do Arquivo /etc/cups/printers.conf

Nome

Tipo

Significado

nome descritivo da impressora localização física da impressora localização em URI do dispositivo associado à impressora PageLimit número limite de páginas (0 = infinito) KLimit número limite de tamanho do arquivo (0 = infinito) Info Location DeviceURI

string string string

Uma atenção especial deve ser dada ao campo DeviceURI. É ele que informa a localização da impressora, tanto localmente como em rede, utilizando URIs (Universal Resource

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

Figura 3.31: Configurando Impressora no CUPS

Indentifiers), uma forma geral de URLs. Em rede, o campo DeviceURI especifica não só a localização, mas também o protocolo utilizado na comunicação de dados. Para saber quais os protocolos utilizados, basta executar o comando lpinfo -v. A opção ‘-v’ informa os dispositivos suportados. Os mais comuns são o ipp (para impressoras em rede, nesse caso também poderia ser usado o http), o lpd (para impressoras em servidores UNIX), o paralel (para impressoras paralelas), o usb (para impressoras USB) e o smb (para impressoras em máquinas Windows). A Figura 3.33 mostra exemplos de URIs que poderiam ser usadas nesse campo. Após adicionar a impressora no arquivo /etc/cups/printers.conf é necessário copiar um arquivo PPD associado a essa impressora para o diretório /etc/cups/ppd. Um PPD é um arquivo, proposto pela Adobe, para descrição de impressoras PostScript (PPD: PostScript Printer Description File), descrito em (ADOBE SYSTEMS INCORPORA-

Configuração de Dispositivos

# Printer configuration file for CUPS v1.1.14 # Written by cupsd on Qui 12 Dez 2002 10:43:36 GMT <DefaultPrinter hp4l> Info hp4l a4 Location Impressora Local DeviceURI parallel:/dev/lp0 State Idle Accepting Yes JobSheets none none QuotaPeriod 0 PageLimit 0 KLimit 0 </Printer>

Figura 3.32: Arquivo /etc/printers.conf parallel:/dev/lp1 usb:/dev/usb/lp0 file:/path/to/filename.prn http://hostname:631/ipp/ ipp://hostname/ipp/ lpd://hostname/queue smb://server/sharename smb://user:pass@workgroup/server/sharename Figura 3.33: Exemplos de DeviceURI

TED, 1996). Atualmente, principalmente no caso do CUPS, é utilizado em qualquer impressora. Esse arquivo irá informar ao CUPS a configuração da impressora (a resolução, o filtro utilizado, etc.). O pacote cups-drivers oferece PPDs para a maioria das impressoras em uso atualmente. Além da edição manual, uma opção mais fácil é utilizar o comando lpadmin, com a seguinte sintaxe:

/usr/sbin/lpadmin -p printer -E -v device -m ppd

Nesse caso, printer é o nome da impressora. A opção -E informa que é para habilitála. Com as opções -v e -m são informadas, respectivamente, a URI e o PPD da impressora

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

em questão. Maiores detalhes podem ser obtidos em (EASY SOFTWARE PRODUCTS, 2002a) ou na página de manual desse comando. Outro comando importante no CUPS é o lpoption que mostra ou configura uma dada impressora. A Figura 3.34 apresenta dois exemplos de uso desse comando: um para configurar o tamanho do papel e outro para listar as opções correntes. Maiores detalhes sobre esse comando podem ser obtidos em sua página de comando ou em (EASY SOFTWARE PRODUCTS, 2002c). # lpoptions -php4l -o PageSize=A4 # lpoptions -php4l -l HPLJDensity/Density: 1 2 *3 4 5 Economode/Economy mode: Economy *Standard Dithering/Floyd-Steinberg Dithering: FSDithered *Normal Manualfeed/Manual Feed of Paper: Off On Resolution/Resolution: 75 150 *300 600 REt/REt Setting: Dark Light *Medium Off InputSlot/Media Source: Envelope Manual *Default Tray1 Tray2 Tray3 Tray4 PageSize/Page Size: 11x17 A3 *A4 A5 B5 Env10 EnvISOB5 EnvC5 EnvDL EnvMonarch Executive Legal Letter PageRegion/PageRegion: 11x17 A3 A4 A5 B5 Env10 EnvISOB5 EnvC5 EnvDL EnvMonarch Executive Legal Letter Figura 3.34: Exemplos de Uso do lpoptions

Ainda sobre o CUPS, é importante observar que ele oferece um suporte aos comandos lpd. Assim, o usuário pode continuar utilizando comandos como lpr, lprm e lpq. Para maiores detalhes sobre o CUPS, consulte (SWEET, 2002), (EASY SOFTWARE PRODUCTS, 2002a) e (EASY SOFTWARE PRODUCTS, 2002c).

3.13

GRAVADORES DE CDS

O suporte a gravadores de CDs em Linux é extremamente simples. Caso o gravador seja um dispositivo SCSI, não é necessário fazer nada: o dispositivo já deve estar habilitado. Caso o dispositivo seja IDE, o que é mais comum, pode ser necessário habilitar emulação SCSI para esse dispositivo. Isso é necessário porque o programa de gravação (o cdrecord) utilizava comandos SCSI para fazer a gravação. As versões mais recentes desse software já não possuem essa limitação.

Configuração de Dispositivos

Existem duas maneiras de habilitar a emulação SCSI. Uma é informar ao kernel, na momento do boot, que aquele dispositivo IDE deve ser tratado como se fosse SCSI. Assim, por exemplo, se o gravador de CDs é o dispositivo /dev/hdc, basta acrescentar hdc=ide-scsi na linha de inicialização. A Seção 5.9 apresenta exemplos práticos de como essa linha pode ser inserida na configuração do LILO ou do GRUB. Essa alternativa é feita em sistemas RedHat, desde a versão 7.3. Outra forma é carregar o módulo ide-scsi. Até a versão 8.0 do Conectiva, essa era a única forma de conseguir fazer o dispositivo ser habilitado. A alternativa anterior é preferível, porque corre-se menos riscos de emulação SCSI ser habilitada a drivers de CD-ROM (quando for o caso da máquina ter gravador e leitor de CDs). Para carregar o módulo automaticamente, no momento de inicialização da máquina, basta incluir a linha /sbin/modprobe ide-scsi no arquivo /etc/rc.d/rc.local. Para saber se o gravador já está habilitado basta executar em um terminal o comando cdrecord -scanbus. Caso esteja, ele deverá informar o número do dispositivo e sua descrição, como mostra a Figura 3.35. Caso esteja tudo funcionando, o processo de gravação pode ser feito com o uso dos utilitários mkisofs e cdrecord. Esses utilitários são em modo texto, caso prefira utilitários gráficos, podem ser usados o xcdroast ou o gcombust. Consulte a documentação desses comandos para maioires detalhes.

# cdrecord -scanbus Cdrecord 1.10 (i686-pc-linux-gnu) Copyright (C) 1995-2001 Jörg Schilling Linux sg driver version: 3.1.24 Using libscg version ’schily-0.5’ scsibus0: 0,0,0 0) ’HL-DT-ST’ ’CD-RW GCE-8320B ’ ’1.01’ Removable CD-ROM 0,1,0 1) * 0,2,0 2) * 0,3,0 3) * 0,4,0 4) * 0,5,0 5) * 0,6,0 6) * 0,7,0 7) *

Figura 3.35: Exemplo de Uso do cdrecord

3.14

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

PLACAS DE SOM

A configuração de placas de som é feita no arquivo modules.conf. Nesse arquivo devem ser informados os módulos a serem carregados e quais as opções utilizadas. Uma observação a ser feita é que existem atualmente duas tecnologias gratuitas de som para Linux: a OSS (http://www.opensound.com/) e a ALSA (http://www.alsa-project. org/). Open Sound System(OSS) foi a primeira tentativa em unificar a arquitetura de som em UNIX. A maioria das distribuições vem com suporte nativo à OSS. Já a ALSA (Advanced Linux Sound Architecture) tenta ser uma estrutura avançada de som, mas exclusiva ao Linux. A ALSA proporciona várias vantagens sobre o OSS (como drivers modulares e uma estrutura mais segura contra falhas) e, inclusive, suporta aplicações baseadas em OSS. Assim, caso pretenda-se um melhor desempenho em termos de som, ALSA é uma melhor alternativa. Nesse caso, a configuração por ser feita por meio do utilitário alsaconf, integrante do pacote lsa-utils.

3.15

OUTROS DISPOSITIVOS

A configuração de dispositivos USB depende do tipo de dispositivo em questão. Se é uma impressora, por exemplo, utiliza-se o procedimento normal para configuração de impressoras, informando-se o dispositivo local (no caso, /dev/usb/lp0). Recomendase que o leitor visite http://www.linux-usb.org/ para saber se o seu dispositivo já é suportado. Outra visita recomendada é ao site http://linuxusbguide.sourceforge. net/, que possui informações gerais sobre uso USB em Linux. Os autores desta apostila acreditam que em pouco tempo a maioria dos dispositivos USB devem ser suportados sem problemas em Linux. No caso específico de scanners, a maioria dos dispositivos SCSI é suportado pelo SANE (Scanner Access Now Easy) sem problemas. Na página do SANE, http://www. mostang.com/sane/, pode ser encontrada uma relação dos dispositivos suportados. Caso seja suportado pelo SANE, para verificar se ele pode ser usado, basta utilizar o aplicativo sane-find-scanner. Se ele for informado, pode ser acessado via aplicações gráficas, como o Gimp. Um auxílio extremamente útil na configuração de qualquer equipamento em Linux são os HOWTOs. Esses pequenos manuais, disponíveis em http://www.tldp.org, oferecem ajuda para assuntos específicos. Esses documentos oferecem auxílio valoroso para a resolução de diversos problemas, inclusive o de instalação de dispositivos. A leitura des-

Configuração de Dispositivos

ses manuais, feitos a partir da experiência de vários usuários com o mesmo problema, são essenciais a uma boa administração Linux.

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

4 SISTEMA DE ARQUIVOS

4.1

COMENTÁRIOS INICIAIS

Quando do desenvolvimento do Linux, Linus Torvalds tinha a pretensão de evitar problemas encontrados durante seu uso do Minix. Dessa maneira, o sistema de arquivos adotado no Linux baseia-se numa camada virtual (VFS – Virtual FileSystem), construída para suportar múltiplos sistemas de arquivos. Essa estrutura permitiu ao Linux um gerenciamento poderoso desse recurso. O objetivo principal deste capítulo é apresentar ao leitor a filosofia existente sob o uso de arquivos em Linux, incluíndo-se: estrutura de diretórios, criação uso e manutenção de partições. Além disso, ele apresenta os vários tipos de arquivos usados nos sistemas de arquivos compatíveis com o Linux.

4.2

ESTRUTURA DE DIRETÓRIOS

Um problema prático existente no início do desenvolvimento do Linux era referente ao uso do sistema de arquivos. Dessa maneira, administradores e distribuições nem sempre utilizavam o mesmo diretório para colocar um dado arquivo. Isso gerava um esforço adicional na administração dos sistemas, dada a confusão criada. Em agosto de 1993, Olaf Kirsh, um programador postou uma mensagem em um dos grupos de discussão sobre Linux, discutindo a possibilidade de criação de um padrão para a estrutura de diretórios. Em fevereiro de 1994, a primeira versão desse padrão foi disponibilizada sob o nome de FSSTND (de FileSystem STaNDard). Duas outras versões foram disponibilizadas em 1995, incluíndo-se a FSSTND 1.2, a última versão disponibilizada. A maior limitação desse padrão é que ele aplicava-se somente ao Linux e dificultava o uso em ambientes mistos, com vários sistemas operacionais.

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

Esse problema levou a comunidade a avançar da FSSTND em direção a um novo padrão. Assim, um esforço para criar um padrão hierárquico do sistema de arquivos que pudesse ser aplicada também a outros sistemas baseados em UNIX foi iniciado em 1995,com ajuda de desenvolvedores do BSD. O nome do padrão foi alterado para Filesystem Hierarchy Standard (FHS) (RUSSELL; QUINLAN; YEOH, 2004), que poderia ser aplicado a qualquer sistema de arquivos: • que utilizasse uma estrutura hierárquica (árvores de diretórios); • que controlasse dados de arquivos de forma consistente; • que incluísse mecanismos de proteções de dados. Dessa maneira, o FHS inicialmente estabelece uma distinção entre dados compartilháveis e não-compartilháveis e entre dados estáticos e variáveis: Dados compartilháveis são aqueles que podem ser distribuídos entre diferentes máquinas; não compartilhável são aqueles específicos a um dado sistema. Por exemplo, os diretórios pessoais dos usuários são dados compartilháveis, mas arquivos de dispositivos não o são. Dados estáticos incluem binários, bibliotecas e documentação, e tudo aquilo que não é alterado sem intervenção do administrador; dados variáveis incluem tudo que pode ser modificado sem a intervenção do administrador do sistema (RUSSELL; QUINLAN, 2001).

O objetivo dessa distinção é fazer com que o FHS facilite o compartilhamento de informações em um ambiente distribuído. Dessa maneira, dados não-compartilháveis devem estar em árvores de diretório próprias. Ainda, dados estáticos podem ser montados somente para leitura, aumentando a segurança do sistema e até mesmo o uso de mídia estática (como CD-ROMs) como parte estrutural do sistema de arquivos. A Figura 4.1 apresenta a árvore raiz de diretórios proposta no FHS. Itens em itálico não precisam existir na árvore, mas se existirem devem estar no diretório raiz. Obviamente, cada entrada na árvore de diretórios descrita na Figura 4.1 pode ter sob si uma subárvore própria e, para algumas dessas entradas, freqüentemente isso ocorre. Observe que algumas dessas entradas podem ser links para outros diretórios. Segue-se uma descrição mais detalhada dessas entradas (obs: os diretórios /usr e /var, por serem mais complexos, serão tratados em seções próprias). /bin: O diretório /bin contém aqueles comandos essenciais a qualquer usuário, quando nenhum outro sistema de arquivos encontra-se montado. Assim, é requerido que

Sistema de Arquivos

Diretório Raiz bin boot dev etc lib media mnt opt sbin srv tmp usr var

Comandos binários essenciais Arquivos estáticos para boot do sistema Arquivos de disposistivos Arquivos de configuraçao do sistema Bibliotecas (DLLs) essenciais e módulos do kernel Diretório para Montagem de Mídia Removível Pontos de montagem de sistemas de arquivos temporários Pacotes extras de software Comandos de sistema essenciais Dados de serviços do sistema Arquivos temporários Hierarquia Secundária Dados variáveis

home lib<qual> root

Diretórios pessoais dos usuários Bibliotecas essenciais em formato alternativo Diretório do usuário root Figura 4.1: Árvore Raiz de Diretórios

ele contenha os seguintes comandos: cat, chgrp, chmod, chown, cp, date, dd, df, dmesg, echo, false, hostname, kill, ln, login, ls, mkdir, mknod, more, mount, mv, ps, pwd, rm, rmdir, sed, sh, stty, su, sync, true, umount e uname. Se forem instalados, os seguintes comandos também devem ser colocados em /bin: csh, ed, tar, cpio, gzip, gunzip, zcat, netstat, ping. Dada a importâncias desses comandos, recomenda-se ao leitor que consulte as respectivas páginas de manuais, em busca de mais informações. Os comandos [ e test precisam estar disponíveis ambos em /bin ou /usr/bin. /sbin: Os utilitários essenciais usados na administração do sistema são disponibilizados em /sbin. Assim, nesse diretório devem estar os aplicativos essenciais à inicialização, restauração e reparação do sistema, por exemplo: fdisk, fsck, shutdown, halt, reboot, getty, ifconfig, init, mkfs, mkswap, route, swapon, swapoff e update. Novamente, recomenda-se ao leitor a consulta às páginas de manuais desses comando, em busca de mais informações. /boot: Esse diretório deve conter todos os arquivos essenciais ao processo de boot, com excessão de arquivos de configuração. Opcionalmente, o kernel do sistema operacional deve ser colocado em /boot, estratégia mais adotada, ou no diretório raiz.

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

/dev: O diretório /dev/ contém os arquivos especiais de dispositivos. A maioria dos dispositivos de hardware é mapeado em um arquivo nos sistemas UNIX. Assim, por exemplo, o arquivo /dev/hda representa o disco rígido mestre (master) da primeira controlodora IDE. O arquivo /dev/hda1 representa, portanto, a primeira partição desse disco. O primeiro disco SCSI, por sua vez, é mapeado no arquivo /dev/sda. /lib: Esse diretório contém todas as bibliotecas dinâmicas utilizadas para inicializar o sistemas e executar as aplicações disponíveis em bin e sbin. Os módulos do kernel devem ser dispostos no subdiretório /lib/modules. Em alguns casos, podem haver diretórios específicos de bibliotecas, por exemplo /lib64 para bibliotecas de 64 bits. /etc: É no diretório /etc/ que ficam os arquivos e diretórios utilizados para a configuração do sistema. Vários desses arquivos e diretórios serão abordados em detalhes mais à frente nesta apostila. É um dos diretórios mais importantes ao se pensar em backups do sistema. /home: O diretório /home contém as pastas de trabalho dos usuários. A organização interna desse diretório depende de cada sistema. Alguns administradores, por exemplo, utilizam um subdiretório próprio em /home para cada usuário. Outros, criam um subdiretório para cada grupo, ficando os diretórios dos usuários em terceiro nível. Essa última alternativa é indicada quando há muitos usuários e vários grupos em um sistema. /root: Esse é o diretório pessoal do usuário root. Se ele não existir, o sistema irá assumir o diretório raiz / como sendo o diretório pessoal. /media: Esse diretório é utilizado para montagem de mídia removível, como disquetes (geralmente montados em /media/floppy), CDROMs (geralmente montados em /media/cdrom) e pendrives (geralmente montados em /media/usdisk). /mnt: Diretório utilizado para montagem temporária de sistema de arquivos. Não deve ser utilizado para mídia removível. /srv: Esse diretório é utilizado para armazenar dados específicos dos serviços do sistema, como WWW, CVS ou FTP. Não existe ainda um consenso sobre a forma de criar subdiretórios nesse local, uma metodologia é o uso de subdiretórios associados a protocolos, e.g.: /srv/ftp, /srv/rsync, etc. Em sistemas mais complexos, pode ser útil estruturar /srv por contexto administrativo, por exemplo: /srv/ginux/www, /srv/bazar/rsync, /srv/arl/rsync. O leitor deve observar que diretórios atualmente existentes no /var podem migrar para /srv, a critério do administrador ou da distribuição. /opt: O diretório /opt é reservado para a instalação de pacotes adicionais de software. Esse deve ser o local preferido para a instalação de programas desenvolvidos localmente (facilitando atualizações do sistema). Distribuições podem instalar software em

Sistema de Arquivos

/opt, mas não podem modificar ou apagar arquivos instalados pelo administrador sem o seu consentimento. /tmp: Como o nome sugere, o diretório /tmp é disponibilizado para uso de arquivos temporários. Esses arquivos costumam ser apagados periodicamente, geralmente a cada dez dias. 4.2.1

O diretório /usr

Depois do diretório raiz, o diretório /usr é a maior seção utilizada no sistema de arquivos. Esse diretório contém dados compartilháveis e pode ser montado apenas para leitura. Isso o torna altamente capacitado para compartilhamento em rede com sistemas compatíveis com FHS. A Figura 4.2 apresenta a árvore de diretórios /usr proposta no FHS. Novamente, itens em itálico não precisam existir na árvore, mas se existirem devem estar nesse diretório.

/usr

Hierarquia Secundária bin include lib local sbin share

Comandos binários de usuários Arquivo de cabeçalho C/C++ Bibliotecas (DLLs) de uso comum Hierarquia local do sistema Comandos de sistema não−essenciais Dados independentes de arquitetura

X11R6 games lib<qual> src

Sistema gráfico (X Window System) Jogos e aplicativos educacionais Bibliotecas (DLLs) em formato alternativo Código−fonte (incluindo kernel)

Figura 4.2: Árvore de Diretórios em /usr

Os diretórios /usr/bin e /usr/sbin têm objetivos semelhantes aos diretórios /bin e /sbin, respectivamente. A única diferença é que os comandos disponibilizados em /usr/bin e /usr/sbin são considerados como não essenciais à inicialização, manutenção e recuperação do sistema. Isso ocorre porque, como o diretório /usr pode ser montado via rede, ele não pode conter aplicativos e arquivos desse perfil. O diretório /usr/lib inclui arquivos objetos, bibliotecas e comandos binários que não são disponibilizados para serem executados diretamente por usuários e shell scripts. As DLLs de suporte aos aplicativos existentes em /usr/bin e /usr/sbin, que já não estiverem em /lib, são colocadas em /usr/lib. Os arquivos de cabeçalhos C/C++ são

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

colocados no diretório /usr/include ou um de seus subdiretórios. Código-fonte de aplicativos não-locais utilizam o diretório /usr/src como árvore raiz (incluindo o kernel). Em /usr/X11R6, encontram-se os arquivos relacionados ao sistema gráfico do UNIX, o X Window System, em sua versão 11, release 6. Para facilitar o acesso do usuário, os seguintes links devem existir:

/usr/bin/X11 -> /usr/X11R6/bin /usr/lib/X11 -> /usr/X11R6/lib/X11 /usr/include/X11 -> /usr/X11R6/include/X11

O objetivo da existência desses links é facilitar a transição entre releases do X11. Observe que os arquivos de configuração do X11 devem ficar no diretório /etc/X11. O objetivo do diretório /usr/share é servir como um repositório de dados independentes de arquitetura e que não sejam alterados entre instalações. Assim, nesse diretório ficam as páginas de manuais (em /usr/share/man), as páginas de informações (em /usr/share/info). No subdiretório /usr/share/locale, encontram-se os arquivos de localização (internacionalização do sistema). Alguns ícones podem ser encontrados em /usr/share/pixmaps ou /usr/share/icons. O diretório /usr/share/fonts é um dos preferidos para instalação de fontes em diversos formatos (ex.: TrueType, Type 1 ou Type 3). A intenção do diretório /usr/local é funcionar como uma hierarquia para instalação localizada de software. O objetivo de utilizar /usr/local/bin para instalação de aplicativos locais é evitar substituir ou atualizar, inadvertidamente, aplicativos em /usr/bin. Entre os subdiretórios de /usr/local, encontram-se: /usr/local/bin, /usr/local/sbin, /usr/local/man, /usr/local/share, /usr/local/include e /usr/local/lib. 4.2.2

O diretório /var

O diretório /var contém os dados variáveis do sistema, como cache de aplicações, arquivos de spool e informações de registros (logs). Ele foi pensado dessa maneira para que o diretório /usr pudesse ser montado somente para leitura. Todo arquivo que necessita ser escrito durante operação do sistema, excluíndo-se instalação e manutenção de software. Em servidores de rede, é desejável que /var esteja em uma partição separada. A Figura 4.3 apresenta a árvore de diretórios /var proposta no FHS. Como atividade, é deixado ao leitor a tarefa de descobrir para que servem esses diretórios.

Sistema de Arquivos

/var

Dados Variáveis cache lib local lock log opt run spool tmp

Cache de aplicações Informações variáveis de aplicações Dados variáveis para /usr/local Arquivos de lock de aplicações Arquivos de registros (logs) Dados variáveis para /opt Dados relevantes de processos em execução Spool de aplicações Arquivos temporários preservados entre reboots

account Registros de contabilidades de processos mail Caixas−postais de e−mail Figura 4.3: Árvore de Diretórios em /var

4.2.3

Outros diretórios

Em uma seção específica ao Linux, o FHS apresenta detalhes desse padrão aplicáveis somente a esse sistema operacional. A observação mais pertinente é a existência do diretório /proc. Esse diretório é um sistema de arquivos virtual que armazena informações sobre o kernel os processos em execução e o sistema como um todo. Assim, por exemplo, o arquivo /proc/kcore representa a memória do computador em questão. O arquivo /proc/partitions apresenta detalhes sobre as partições dos discos rígidos disponíveis. As interrupções (IRQs) do sistema podem ser visualizadas em /proc/interrupts e informações sobre os dispositivos PCI ou USB podem ser encontrados, respectivamente, em /proc/pci e /proc/bus/usb/devices. Dessa maneira, uma visita aos arquivos desse diretório podem facilitar, e muito, a instalação de dispositivos de hardware em Linux. Ainda, caso o sistema de arquivos usado seja ext2 ou ext3, então, para cada partição existente, será criado um diretório /lost+found. Esse diretório, “achados e perdidos”, é utilizado pelo fsck, um utilitário de checagem do sistema de arquivos que ali aloca os blocos de arquivos “perdidos”, ou seja, i-nodes sem nomes de arquivos.

4.3

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

USO DE DISPOSITIVOS DE ARMAZENAMENTO

Assim como a maioria dos sistemas operacionais, o Linux tem a possibilidade de manipular diversos dispositivos de armazenamento. Dentre tais dispositivos podem ser destacados: disquetes, discos Zip, CD-R e CD-RW, discos rígidos (removíveis ou não), fitas (por exemplo, 8 mm, DAT, Travan, ADR onStream, DLT, AIT e Mammoth), pendrives e discos externos USB. Cada tipo de mídia tem as suas características de custo, taxa de transferência, capacidade de armazenamento, cuidados de manipulação, etc. Cabe ao administrador verificar as necessidades e possibilidades relativas ao sistema sob administração. Quanto à utilização, pode-se dizer que os dispositivos de armazenamento servem para acondicionar, além do sistema e arquivos relacionados à ele, os arquivos dos usuários na forma corrente de manipulação e na forma de backups Para a manipulação, existem diversos comandos: aqueles para backups (que serão vistos oportunamente), para montagem de dispositivos do tipo discos magnéticos (abordados na Seção 4.5), movimentação da cabeçote em fitas magnéticas (por exemplo, o comando mt) e leitura e gravação em fitas e discos magnéticos (por exemplo, tem-se os comandos: tar, cpio, e dd. A Tabela 4.1 fornece uma descrição sumária dos comandos aqui listados.

4.4

USO DE MEMÓRIA VIRTUAL

Um outro item importante relacionado aos sistemas de arquivos é representado pela memória virtual. Genericamente falando, memória virtual consiste em se utilizar memória secundária afim de descarregar imagens de processos que não estiverem em execução em um certo momento. Desta forma, consegue-me mapear uma região maior de espaço de endereçamento (memória principal em conjunto à memória secundária). Com a finalidade de liberar espaço para a carga de outros processos, aqueles que não estiverem em execução são retirados da memória principal e sua imagem (estado de registradores, código, etc) são gravados em disco em uma região de swap. Quando volta à tona, um processo pode ocupar uma região de memória principal distinta em relação àquela ocupada anteriormente. Sendo assim, o endereço de, por exemplo, uma variável ou uma linha de código de um processo é virtual, ou seja, precisa ser traduzido para o endereço real a fim de ser acessado. Para o gerenciamento da memória virtual, o Linux utiliza, como algoritmos de alocação em memória principal, o buddy e o slab e, para a substituição de páginas, o mecanismo de clock. Conforme mencionado, a região em memória secundária (no hard disk) é denomi-

Sistema de Arquivos

Tabela 4.1: Principais Comandos Associados aos Dispositivos de Armazenamento Comando mt

Descrição

Exemplo de utilização

Movimentar a cabeça magnética de uma fita, verificar e alterar o seu estado

Para ver o status de uma fita: # mt -f/dev/rmt8 status Para retroceder a fita ao início: # mt -f/dev/rmt8 rew

tar

cpio

Permite criar, ler e escrever arquivos que contém uma hierarquia de diretórios e seus conteúdos. Possibilita ainda compactação e descompactação pelo mesmo algoritmo do gzip ou do bzip2.

Para ler um “arquivo” comprimido: # tar -zxvf arquivo.tar.gz

Funcionalidade semelhante ao tar

Para extrair de arq apenas os arquivos “dir1/f1” e “dir1/b*” (opção ‘i’), criando os diretórios necessários (opção ‘d’). A opção ‘c’ é usada quando o arquivo foi gerado com um header portável: # cat arq | cpio -icd \ "dir/f1" "dir1/b*"

Permite cópia de arquivos ou conversão de bits (por exemplo, utilizando-se blocos de tamanhos distintos)

Para copiar de uma fita para arquivo: # dd if=/dev/rmt8 \ of=/tmp/arq cbs=16b

Para escrever o /home em uma fita: # tar -cvf /dev/rmt8 /home

nada como área de swap. Para ambientes que atendem um grande número de processos e de usuários, é conveniente criar vários espaços de swap em discos distintos afim de se aumentar a eficiência computacional do sistema. Para verificar como proceder a criação, consulte a Seção 5.2 desta apostila.

4.5

MONTAGEM DE DISPOSITIVOS

Pode-se falar que a estrutura de diretórios de sistemas derivados do UNIX é bem transparente, sob o ponto de vista de uso, frente aos usuários. Tal transparência é resultante, por exemplo, do não conhecimento, por parte do usuário, da localização real (física) de um diretório específico, ou seja, qual dispositivo está mapeando o diretório. Os dispositivos

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

que fornecem pontos de montagem podem ser locais ou remotos e são representados por discos rígidos e flexíveis, unidades de CD, dentre outros. Para poder ser utilizado, o dispositivo deverá ser “montado”. A montagem corresponde à uma etapa de criação de tabelas e instanciação de i-nodes na memória principal do computador. Para tanto, utiliza-se o comando mount com a seguinte sintaxe: # mount -t sist_de_arquivos dispositivo local_de_montagem opções

O mount suporta diversos tipos de sistemas de arquivos, dentre os quais podem ser destacados: msdos (FAT), vfat (windows9x), ntfs (Windows NT/2K), ext2 (nativo do Linux), ext3 (nativo do Linux nas novas distribuições), iso9660 (para manipulação de CDs) e nfs (Network File System – para dispositivos remotos). Pelo fato de ser nativo, um dos sistemas de arquivos mais importante no mundo Linux é o ext2. O ext2, assim como todos sistemas de arquivos derivados do UNIX, utiliza o conceito básico de que os arquivos são mapeados por i-nodes e diretórios são simplesmente arquivos que contém uma lista de entradas e de dispositivos que poderão ser acessados. I-nodes são estruturas que contém as descrições dos arquivos, tais como: tipo de arquivo, direitos de acessos, proprietário, momento de criação e ponteiros aos blocos de dados. Sob o ponto de vista de implementação, cada i-node armazena uma lista de endereços físicos que representam o posicionamento da informação no disco, por exemplo. Caso o arquivo seja pequeno, todos os endereços físicos poderão estar armazenados no próprio i-node. Caso contrário, o i-node apontará para um bloco que conterá informações adicionais acerca dos outros endereços físicos do arquivo. Esse bloco é denominado como single indirect block. Caso não seja ainda suficiente para abranger todo arquivo um novo bloco é evocado (double indirect block). Esse encadeamento é ilustrado na Figura 4.4. Um dos atributos contidos na estrutura do i-node consiste no número de hard links (campo i_nlink da estrutura inode). Esse campo informa a quantidade de hard-links associados a um i-node específico. Em um hard-link é realizado um mapeamento direto entre os i-nodes (ao contrário do link simbólico onde é feita uma tradução de nome para se achar o i-node associado – conforme descrito na Seção 4.7), ou seja, hard-links são mapeados com o mesmo i-node em relação ao arquivo referenciado, como mostra a Figura 4.5. Como pode ser verificado na Figura 4.5, um hard link pode ser entendido como o “nome” do arquivo. Assim um arquivo com dois hard links pode, a grosso modo, ser enxergado como um arquivo com dois “nomes”. É importante salientar que hard-links somente são possíveis dentro de um mesmo dispositivo e são aplicáveis somente a arquivos para evitar loops. Os hard-links apresentam a vantagem de não consumirem espaços adicionais para o seu mapeamento e podem ser criados com o comando ln e removidos com rm.

Sistema de Arquivos

Direct Blocks Double indirect blocks

Indirect blocks I−node Infos

Figura 4.4: Encadeamento de I-nodes Arquivo: algo.txt I−node: 3429

Arquivo: soma.doc Arquivo: prog1 I−node: 3431 I−node: 3430

Arquivo: prog2 I−node: 3430

I−node: 3429

I−node: 3430

I−node: 3431

etc.

Tamanho: 5674 bytes

Tamanho: 123456 bytes

Tamanho: 74123 bytes

Diretório

I−nodes

Figura 4.5: Hard Link

Um outro sistema de arquivos extremamente importante é representado pelo ext3 (o qual equipa as distribuições de Linux mais atuais). O ext3 é um exemplo de journalling filesystem que apresenta como principal vantagem sobre o ext2 o fato de ser mais consistente em relação à falhas, o que resulta em um tempo de manutenção extremamente

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

menor, não sendo, geralmente, necessário executar aplicativos do tipo fsck. Para migrar de ext2 para ext3 ou para criar novos sistemas de arquivos baseados em ext3, basta executar aplicativos como tune2fs e mke2fs, respectivamente. Outros exemplos de journalling filesystems compatíveis com o Linux são o JFS for Linux (desenvolvido pela IBM), o XFS (desenvolvido pela Silicon Graphics) e o ReiserFS (desenvolvido inicialmente com o apoio da SUSE). A maioria das distribuições atualmente adota o ext3 como padrão. Observe que o limite do tamanho de arquivo do ext3 e do ReiserFS é o mesmo do ext2: 4 GB. Com o JFS e o XFS, esses limites vão para acima de 4 Pb (4 Petabytes – 1 Petabyte = 1024 Terabytes). Para maiores detalhes sobre journalling filesystems e outros sistemas de arquivos suportados pelo Linux, consulte (HINNER, 2000). Cabe ressaltar ainda que encontra-se em processo de testes o ext4, que não será totalmente compatível com ext3 e ext2 e possui como principal inovação o uso de extents, uma área contígua reservada para o arquivo e que reduz a fragmentação, aumentando assim o desempenho do sistema de arquivos. Tabela 4.2: Nomenclatura de Dispositivos Usuais Dispositivo

Descrição

/dev/hda /dev/hdb /dev/hdc /dev/hdd /dev/cdrom

Disco master da primeira interface IDE Disco slave da primeira interface IDE Disco master da segunda interface IDE Disco master da segunda interface IDE Esse dispositivo é muito usado, porém é apenas um link simbólico para um dispositivo real (por exemplo, /dev/hdX, se for ATAPI). Onde X= a, b, c ou d. Primeiro disco SCSI (ou USB) Segundo disco SCSI (ou USB) Primeira unidade de CD SCSI (ou USB) Segunda unidade de CD SCSI (ou USB) Primeira unidade de floppy disk Primeira partição do disco IDE (caso X == h) ou do disco SCSI (caso X == s) Primeira partição lógica (independente do número de partições primárias existentes) – o X segue a mesma notação em relação à linha anterior

/dev/sda /dev/sdb /dev/scd0 /dev/scd1 /dev/fd0 /dev/Xda1 /dev/Xda5

Com relação aos dispositivos, existe uma nomenclatura seguida pelo Linux. A Tabela 4.2 ilustra a nomenclatura de alguns dispositivos mais usuais. A seguir são apresentadas dois exemplos de utilização do comando mount:

Sistema de Arquivos

# mount -t vfat /dev/fd0 /mnt/floppy # mount -t nfs machine.host.com:/usr/local /usr/local/app Nos exemplos anteriores, tem-se, primeiramente, a montagem de um floppy disk cujo ponto de montagem é /mnt/floppy. Já no segundo exemplo, é utilizado um ponto de montagem /usr/local/app cujo conteúdo está sendo coletado do diretório /usr/local da máquina remota machine.host.com (nota-se a utilização, neste caso, do tipo de sistema de arquivos NFS). A montagem de dispositivos pode ser auxiliado pelo arquivo /etc/fstab. Tal arquivo contém as especificações dos pontos a serem montados (tipo de sistema de arquivo, dispositivo, momento de montagem e permissões associados). Um exemplo de arquivo /etc/fstab é mostrado na Figura 4.6. /dev/hda2 /dev/hda5 /dev/hda3 /dev/hdb /dev/fd0 /dev/hda1 none

/ /home /mnt/win /mnt/cdrom /mnt/disquete swap /proc

ext2 ext2 vfat iso9660 auto swap proc

defaults defaults noexec,uid=100,gid=100 defaults, noauto, user defaults, noauto, user defaults defaults

1 1 0 0 0 0 0

1 2 0 0 0 0 0

Figura 4.6: Exemplo de /etc/fstab

No exemplo apresentado na Figura 4.6, tem-se na primeira linha a identificação do ponto de montagem “raiz” (identificado como “/”). Esse ponto está associado à segunda partição primária do disco master da primeira interface IDE (/dev/hda2). A segunda linha referencia o ponto de entrada “/home”. A terceira faz menção à uma partição “windows” (tipo vfat). Como vfat não suporta mecanismos de permissão de acesso, pode-se alterar o proprietário do ponto de montagem com a opção uid (o default é ter o root como proprietário) – opções, tal como uid, serão vistas mais adiante. A seguir, no exemplo da Figura 4.6 encontram-se as definições de montagem do CDROM e do disco flexível. Nota-se a presença das opções noauto que determina que a montagem não deverá ocorrer durante o boot e a opção user, permitindo que os usuários possam montar e desmontar tais pontos de montagem. Desta forma, os usuários poderão manipular tranqüilamente seus CDs e disquetes. As duas últimas linhas do exemplo (swap e /proc) são obrigatórias a todos os sistemas e quase não necessitam ser editadas manualmente. Utilizando-se o fstab, pode-se omitir alguns parâmetros do comando mount. Por exemplo, para montar o CDROM no exemplo anterior, basta:

100

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

# mount /mnt/cdrom A Tabela 4.3 mostra as principais opções utilizadas pelo arquivo fstab. Além das opções acima listadas, pode-se também utilizar as opções usrquota e grpquota com a finalidade de habilitar o controle de quotas na partição associada. Como indica a nomenclatura das opções, usrquota habilita a checagem de quotas para usuários e o grpquota para grupos de usuários. A configuração de quotas e usuários pode ser vista no Capítulo 6 desta apostila. Outras opções podem ser verificadas consultando-se a página de manual do comando mount. Tabela 4.3: Principais Opções Utilizadas no fstab Opção

Descrição

noauto user noexec

evita-se a montagem automática durante o processo de boot permite que qualquer usuário possa montar e desmontar o dispositivo com essa opção, os usuários não poderão executar o conteúdo do ponto de montagem permite definir o proprietário do ponto de montagem (utilizando o UID do usuário) equivalente ao uid, porém aplicável ao grupo (GID) força que um dispositivo seja montado apenas para leitura (read only)

uid gid ro

Caso pretenda-se ativar o uso de quotas, após a modificação no arquivo /etc/fstab adicionando-se as opções referentes às quotas, deve-se executar o comando quotacheck afim de ativar as alterações: # quotacheck -avug Caso o daemon relativo ao monitoramento de quotas não esteja ativo, pode-se iniciá-lo digitando-se: # /usr/sbin/quotaon -avug Para maiores informações sobre uso de quota, pode-se consultar (MOURANI, 2001) e (DOOREN, 2002), além das páginas de manuais dos comandos quotacheck, quotaon, quotaoff e edquota. A desmontagem dos dispositivos ocorre pela utilização do comando umount, que recebe como parâmetro o caminho do ponto de montagem a ser desmontado, ou o dispositivo associado, conforme exemplo a seguir:

Sistema de Arquivos

101

# umount /mnt/cdrom # umount /dev/hda3 Cabe destacar que, com a proliferação dos dispositivos removíveis, como pendrives, câmaras digitais e mp3players, surgiu no Linux a necessidade de se automatizar o acesso a esses recursos. Assim, os principais gerenciadores de ambiente possuem mecanismos que permitem a montagem automática de dispositivos removíveis. No caso do GNOME, isso é conseguido pelo pacote gnome-mount. No KDE, em geral utiliza-se o pmount ou ivman. No Xfce, isso é conseguido com o gerenciador de arquivos Thunar e o pacote thunar-volman.

4.6

PARTIÇÕES

Partições consistem em divisões lógicas do disco rígido de modo que ele possa conter vários sistemas de arquivos distintos (do mesmo tipo ou não). O Linux requer, basicamente, duas partições para o seu funcionamento: uma partição de linux swap (tipo 82) e outra do tipo linux native (tipo 83) ou correlata. Pode ser interessante criar partições de modo a acomodar as contas dos usuários, diretório /tmp e o diretório /var. A criação de tais partições pode facilitar o processo de administração principalmente em relação ao backup. O trabalho de particionar exige cuidados e conhecimento sobre o sistema. Uma das principais dificuldades a ser encontradas é relacionada ao dimensionamento das partições. Apesar de que mídias de armazenamento possuem baixa relação custo/capacidade, é preciso planejamento para um particionamento adequado. Uma das primeiras dúvidas a esse respeito é justamente sobre a necessidade ou não da partição de swap. Com o barateamento de memória RAM, esse item deixou de ser crítico em instalações. Entretanto, dado que o custo do espaço em discos rígidos é muito inferior, ainda é recomendável a utilização de swap, seja sob a forma de partição ou de um arquivo de swap (ver mais detalhes a esse respeito no Capítulo 5). O dimensionamento adequado de uma partição de swap envolve avaliar a utilização de memória, o que não é tarefa simples. Em geral, constuma-se dimensionar o swap com tamanho igual ou em dobro à memória RAM disponível. Além do swap, alguns diretórios merecem especial atenção quando do particionamento. Em uma máquina pessoal, onde o diretório /home esteja armazenado localmente, é altamente desejável que esse diretório esteja em uma partição à parte. Durante uma reinstalação, essa partição pode ser mantida (não formatando-a), evitando a necessidade de restauração do sistema. Além disso, essa separação impõe uma divisão física entre os dados do usuário e os aplicativos, facilitando imensamente o processo de backup, dado que é mais rápido copiar uma partição fisicamente do que um dados dispostos em um diretório.

102

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

O tamanho do diretório /home deve condizer com o espaço em disco disponível. Em geral, recomenda-se que o administrador use parcimônia e sabedoria ao determinar esse tamanho. Caso contrário, o administrador nunca iria imaginar que precisava de 80Gb até passar duas semanas depois de instalado o novo HD de 40Gb. O tamanho do diretório home deve ser calculado tendo-se em vista duas variáveis: número de usuários e espaço de trabalho necessário a cada um. Esse espaço de trabalho é apenas para documentos e arquivos pessoais. Observe que as necessidades de um profissional de área gráfica (que trabalha com arquivos muito grandes) é diferente das de um profissional da área contábil. Além disso, o administrador deve levar em conta que vários programas criam arquivos de configuração e áreas de cache na área do usuário. Com exemplo, em um ambiente onde o usuário utiliza navegador com cache pessoal, recomenda-se ao menos 10 Mb para o uso do navegador. A esse valor deve ser acrescido mais 2 Mb para o OpenOffice e 1 MB para o Gimp. Somando-se mais 3 MB para arquivos diversos de configuração, é recomendável atualmente que as contas de usuário tenham pelo menos 30 MB disponíveis, contando-se aí 10 Mb para arquivos pessoais e e-mail. Caso haja espaço disponível, valores razoáveis nos dias de hoje vão de 50 a 100 MB. Assim, em uma máquina com dez usuários, pode-se reservar 500 Mb para o /home. Em relação ao /var, é útil criar uma partição em separado pois o espaço no raiz é geralmente limitado, não suportando o crescimento, por exemplo, do /var/spool. Isso é especialmente válido em servidores, não havendo necessidade desse diretório estar em partição separada em máquinas pessoais. Observe que no diretório /var ficam, além dos logs do sistema, os arquivos de e-mail e o site local do servidor Web1 . Assim, o tamanho desse diretório deve levar em conta essas informações. Mais ainda: como o tipo de informações armazenadas nos logs é configurável, pode ser necessário deixar mais espaço para esses arquivos. A prática mostra que o tamanho de uma partição para o /var depende dos tipos de serviços oferecidos. Em geral, para um servidor oferecendo serviços Web e serviços de email e SAMBA para 200 usuários, recomenda-se para o /var uma partição de, ao menos, 2GB. Esse valor pode ser diminuído, caso o diretório /var/spool/mail esteja em outra partição ou seja um link para outro diretório. Em muitos casos, para impor uma única quota para arquivos pessoais e e-mail, é interessante que esse diretório seja um link para um diretório em /home. Quanto ao /usr, pode ser interessante que ele esteja em uma partição à parte, para poder ser montada em modo de leitura apenas, aumentando a segurança do sistema. O 1A

localização dos arquivos Web pode ser modificador, a critério do administrador. Além disso, a localização padrão pode mudar para /srv no futuro.

Sistema de Arquivos

103

tamanho dessa partição depende do número e tipo de aplicativos instalados. Em um servidor, 1GB é, em geral, mais do que suficiente. Se não for instalado o servidor gráfico, as necessidades caem para menos de 500 MB. Em uma máquina pessoal, com vários aplicativos gráficos, entretanto, o diretório /usr pode passar, com facilidade de 2 GB. Observe, entretanto, que não é comum criar uma partição separada para o /usr em estações de trabalho. Em servidores que possuam acesso remoto, é importante também que o diretório /tmp esteja em uma partição separada. O motivo é evitar que os usuários utilizem essa partição para armazenamento temporário e acabem comprometendo a partição raiz. Em geral, 300 MB são suficientes para qualquer tipo de máquina, desde que o diretório /tmp não seja utilizado como repositório temporário ou local para se confeccionar imagens físicas de CDROMs. A prática recomenda ater-se a um valor necessário e não resolver ser muito generoso com as partições em se tratando de servidores. É mais fácil criar uma partição em um espaço não alocado e usar essa partição em um diretório “lotado” do que redimensionar partições existentes. Outra observação importante é que recomenda-se que todas as partições mencionadas sejam do tipo linux native (ext2, ext3 ou equivalentes). Para o particionamento, pode-se utilizar os aplicativos fdisk ou sfdisk. A seguir é mostrada uma seqüência para particionar um disco com o fdisk. Suponha que o ambiente tenha dois discos: um para Windows (/dev/hda) e outro destinado ao Linux (/dev/hdb). Então, para particionar /dev/hdb afim de receber a instalação do Linux, basta: a) iniciar o fdisk: # fdisk /dev/hdb b) criar a partição. Neste caso, supõe-se que o disco esteja vazio, caso contrário, pode-se remover as partições que lá estiverem utilizando o comando ‘d’ (delete) dentro do prompt do fdisk. Para criar, utiliza-se a opção ‘n’ (new partition): Command (m for help): n Command action e extended p primary partition (1-4) p Partition number (1-4): 1 First cylinder (1-526): 1 Last cylinder or +size or +sizeM or +sizeK ([1]-526): +950M

104

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

c) Para certificar-se da criação, utiliza-se o comando ‘p’ (print information): Command (m for help): p Disk /dev/hdb: 64 heads, 63 sectors, 526 cylinders Units = cylinders of 4032 * 512 bytes Device Boot /dev/hdb1

Begin 1

Start 1

End 483

Blocks 973696+

Id 83

System Linux native

A primeira partição necessária foi criada. Basta agora criar a partição de swap. Inicialmente, usa-se o comando ‘n’ de forma semelhante à partição recém criada. Porém, é criada uma partição do tipo Linux Native, bastando, portanto, mudá-la para Linux Swap: Command (m for help): n Command action e extended p primary partition (1-4) p Partition number (1-4): 2 First cylinder (484-526): 484 Last cylinder or +size or +sizeM or +sizeK ([484]-526): 526 Command (m for help): t Partition number (1-4): 2 Hex code (type L to list codes): 82 Changed system type of partition 2 to 82 (Linux swap)

d) Uma última verificação pode ser feita: Command (m for help): p Disk /dev/hdb: 64 heads, 63 sectors, 526 cylinders Units = cylinders of 4032 * 512 bytes Device Boot /dev/hdb1 /dev/hdb2

Begin 1 484

Start 1 484

End 483 526

Blocks 973696+ 86688

Id 83 82

System Linux native Linux swap

e) Essas informações estão apenas em memória, o administrador tem a opção de digitar ‘q’ para sair sem salvar ou ‘w’ para salvar e sair do fdisk.

Sistema de Arquivos

105

Um outro utilitário importante para criação de partições é o Parted2 , que faz parte do Projeto GNU. Além de criar e remover partições, o GNU Parted permite redimensionar partições de vários tipos, incluíndo-se FAT e ext2. Após a criação das partições é necessário criar um sistema de arquivos. Para tanto, utiliza-se o mkfs (esse sendo apenas uma interface amigável ao mkfs). Em ambientes de laboratório, freqüentemente é interessante copiar a partição de uma máquina para uma outra (com configuração e tamanho de partição semelhantes). Isso pode ser feito com o comando dd, já comentado neste capítulo. Entretanto o Partimage3 , é uma ferramenta gratuita e de fácil uso que permite cópias de partições de diversos sistemas de arquivos, como ext2, ext3, FAT e NTFS, só para citar alguns. Ele é desenvolvido pela mesma equipe que mantém o SystemRescueCD4 , um LiveCD com vários utilitários úteis para recuperação de sistemas. O autor deste texto é um usuário assíduo dessa distribuição para manutenção em laboratórios. A verificação de consistência dos sistemas de arquivos e possíveis correções poderão ser feitas ativando-se o comando fsck. Um processo de verificação é efetuado automaticamente no momento de inicialização do computador. É interessante mencionar que, caso o fsck encontre algum arquivo sem um diretório pai associado, ele o coloca no diretório “lost+found” no nível superior do sistema de arquivos.

4.7

TIPOS DE ARQUIVOS

Em sistemas derivados do UNIX, os arquivos são utilizados sob várias denotações relacionadas com o armazenarem informações do próprio usuário, código de aplicativos e estruturas utilizadas pelo sistema operacional. Grande parte das distribuições dos sistemas UNIX-like define sete tipos de arquivos, os quais serão detalhados a seguir: Arquivos Regulares: são aqueles representados pela sua forma mais simples de concepção. Estão relacionados aos arquivos de dados dos usuários (formato textual ou binário), código executável, bibliotecas (dinâmicas ou não e compartilhadas ou não) e demais arquivos afins. A manipulação de tais arquivos pode ser realizada de forma sequencial ou aleatória de acordo com a sua construção. Diretórios: representam a estrutura organizacional dos sistemas de arquivo. Assim como os arquivos regulares, os diretórios podem também ser mapeados como links simbólicos conforme será visto a seguir. Em UNIX, existem duas entradas especiais repre2 GNU

Parted: http://www.gnu.org/software/parted/. http://www.partimage.org/. 4 SystemRescueCD: http://www.sysresccd.org/.

3 Partimage:

106

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

sentadas por “.” e “..”. Tais entradas nunca poderão ser apagadas e representam o diretório corrente e o diretório anterior (diretório pai). Arquivos de Dispositivos de Caracteres e de Blocos: os arquivos de dispositivos representam o elo de ligação entre o hardware (incluindo-se os periféricos) e os aplicativos. Tais arquivos são gerenciados pelos drivers dos dispositivos e neles são escritos os dados que serão gerados ou consumidos pelas aplicações. Geralmente tais arquivos são localizados no diretório /dev e podem ser criados através do comando mknod ou por um script disponível em grande parte dos sistemas, denominado MAKEDEV. Por convenção, são associados aos arquivos dois números denominados como números de dispositivos principal e secundário. O principal tem a função de referenciar (ao kernel) o driver associado ao arquivo enquanto que o secundário informa ao driver qual a unidade física que deverá ser manipulada. Desta forma, por exemplo, em sistemas Linux, a primeira porta paralela (/dev/lp0) teria, como números principal e secundário, os valores 6 e 0, respectivamente. Uma maneira prática de verificar tais números consiste em utilizar o comando ls -l. Existem dois tipos de arquivos de dispositivos: o de caracteres e o de blocos. Os arquivos de dispositivos de caracteres (também denominados como dispositivos orientados a fluxo – stream-oriented) manipulam bytes como unidades básicas e têm como exemplo, as interfaces de rede, porta serial e impressoras. Por sua vez, os arquivos associados aos blocos permitem a leitura ou escrita de blocos de informações (apresentando geralmente tamanho fixo) assim como é realizado nas unidades de fita e de disco do sistema. Sockets de Domínio UNIX os sockets de domínio UNIX são mecanismos que habilita a comunicação entre os processos em execução dentro de um computador (inter-process communication – IPC). A comunicação via este tipo de socket tem como vantagem que processos baseados em redes podem se comunicar por intermédio de arquivos. Uma outra característica, é que sockets permitem serviços baseados em conexão. Um cuidado que se tem que tomar na utilização de sockets consiste em se verificar se o usuário tem permissão de escrita no arquivo associado ao socket. Tais arquivos poderão ser removidos através do comando rm ou da chamada de sistema unlink(). A Figura 4.7 ilustra a criação de um servidor usando arquivo socket. Além dos comandos utilizados na Figura 4.7, podem ser utilizados vários outros, como write(), read(), bind(), listen(), accept() e close(). Maiores detalhes e exemplos de uso dessas funções podem ser encontrados em (LOOSEMORE et al., 2001). Pipes Identificados (FIFO) Os pipes identificados são utilizados para a comunicação entre dois processos dentro de um mesmo escopo computacional. Para tanto, a comunicação é realizada através de um arquivo especial de pipe, criado através do comando

Sistema de Arquivos

107

#include <sys/socket.h> #define SERVERFILE "/tmp/server.data" int main() { int sock_fd; struct sockaddr_un unix_addr; if ((sock_fd=socket(AF_UNIX,SOCK_STREAM,0))<0) strcpy(unix_addr.sun_path,SERVERFILE); if(connect(sock_fd,(struct sockaddr*)&unix_addr, sizeof(unix_addr.sun_family)+ strlen(unix_addr.sun_path))<0) }

Figura 4.7: Exemplo de Uso de Sockets

mknod() e podendo ser removido por rm ou unlink(). Maiores detalhes podem ser encontrados em (LOOSEMORE et al., 2001). Links Simbólicos Um link simbólico, ou soft link, faz referência a um arquivo ou diretório através do nome enquanto que o hard link faz uma referência direto ao arquivo ou diretório alvo utilizando, para tal, diretamente as estruturas de i-nodes. Sendo uma referência pelo nome, o kernel, ao encontrar um soft link, apenas faz uma troca do path corrente pelo path apontado pelo link e continua normalmente seu processamento. A criação de um link simbólico é feita através do comando “ln -s”, conforme ilustra o exemplo a seguir: # ln -s /usr/bin/app1ication /home/user01/applink No caso anterior, foi criado, dentro do diretório user01, um link simbólico que aponta para /usr/bin/application. A remoção de links pode ser feita simplesmente pela utilização do comando rm. Uma preocupação que deve ser tomada em relação à criação de links simbólicos é relacionada a evitar o surgimento de loops, ou seja, uma seqüência de links que resulta em uma lista circular.

Além do comando ls, outra ferramenta útil para determinar o tipo de um arquivo é o aplicativo file. Ele determina não só o tipo de arquivo, como também, para arquivos regulares, tenta determinar o formato do arquivo (se imagem, se documento texto, etc.). A Figura 4.8 mostra exemplo de uso desse comando.

108

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

# file admsis.tex /dev/hdb /tmp /home cracha.svg xfce.eps xfce.jpg admsis.tex: LaTeX 2e document text /dev/hdb: block special (3/64) /tmp: sticky directory /home: directory cracha.svg: XML document text xfce.eps: PostScript document text conforming at level 3.0 - type EPS xfce.jpg: JPEG image data, JFIF standard 1.01, resolution (DPI), 72 x 72

Figura 4.8: Uso do Comando file

4.8

ATRIBUTOS DE ARQUIVOS

Cada arquivo apresenta um conjunto de 16 bits que constituem informações acerca de seus atributos. Tais bits representam a permissão de acesso ao arquivo ou diretório (9 bits), o modo de operação (3 bits) e o tipo associado ao arquivo (4 bits). Tais atributos, excetuando-se o tipo, podem ser alterados utilizando-se o comando chmod, assim como a identificação do proprietário e grupo podem ser alterados usando chown e chgrp. Exemplos de utilização do chmod serão vistos ao longo desta seção. Os atributos de permissão denotam a acessibilidade do arquivo ou diretório frente aos usuários do sistema. Entende-se como usuários o proprietário do arquivo, aqueles pertencentes ao mesmo grupo do proprietário e demais usuários sem quaisquer tipo de vínculo com o proprietário. A disposição dos bits é ilustrada na Figura 4.9.

rwx Proprietário

rwx Grupo

rwx Outros

Figura 4.9: Atributos de Permissão

Na Figura 4.9, são vistos os 9 bits divididos em 3 seções: proprietário, grupo e outros. Cada seção apresenta 3 bits indicando permissão de leitura (r – Read), escrita (w – Write) ˙ e execução (x – eXecute). É conveniente associar os bits com numeros octais para facilitar, por exemplo, a sua manipulação. Pode-se observar, portanto, que cada campo de três bits podem ser instanciados com valores que variam na faixa entre 0 e 7, inclusive. Tais valores representam a combinação dos valores dos bits, por exemplo, caso haja necessidade de permitir o acesso de leitura e execução, então o número resultante equivale a 5 (r = 1, w = 0, x = 1, 101(2) = 5(8) ). Sendo assim, a conjunção das seções resulta em uma seqüência de 3 números octais.

Sistema de Arquivos

109

Como exemplo, suponha que se deseja alterar as permissões de um arquivo para: Proprietário: ler, escrever e executar (r = 1, w = 1, x = 1, 111(2) = 7(8) ) Grupo: ler e executar (r = 1, w = 0, x = 1, 101(2) = 5(8) ) Outros: nenhuma permissão associada (r = 0, w = 0, x = 0, 000(2) = 0(8) ) Utilizando-se o comando chmod, tem-se: # chmod 750 nome_arquivo Em relação aos diretórios, o bit de execução permite que o diretório seja entrado ou atravessado durante a etapa de avaliação de caminho, porém o seu conteúdo pode não ser listado quando o bit de leitura estiver desativado. Por outro lado, os atributos de operação podem afetar o modo de operação dos arquivos executáveis. Podem ser classificados como bit setuid, bit setgid e sticky bit. Os bits setuid e setgid (valores octais valendo 4000 e 2000, respectivamente) são utilizados para que o aplicativo seja executado utilizando, respectivamente, o UID (user ID) e o GID (group ID) de seu proprietário mesmo que usuário quem solicitou não o seja. Por exemplo, caso se tenha configurado o setuid de um arquivo como root e o mesmo tenha sido evocado por um usuário normal, ele poderá acessar recursos somente acessíveis ao usuário root uma vez que o processo se comporta como iniciado pelo seu proprietário (root). Tais bits são úteis no compartilhamento de arquivos entre diversos usuários pertencentes ao mesmo grupo. Para instanciar o bit setgid e permitir a leitura e execução a todos os usuários pode-se utilizar o comando chmod conforme ilustrado abaixo: # chmod 2555 nome_arquivo Caso fosse necessário instanciar tanto o setuid quanto o setgid bastaria substituir o valor 2 pelo valor 6. Isso se explica da seguinte forma: 2(8) = 010(2) e4(8) = 100(2) . Fazendose operação OU entre os dois valores obtém-se 110(2) que equivale ao valor 6(8) . Sendo assim, o comando ficaria: # chmod 6555 nome_arquivo Ainda dentro dos atributos de operação, o sticky bit (valor octal 1) tem o significado de forçar a permanência do código executável na memória do computador mesmo após o encerramento de sua execução. Este bit era útil na época em que as memórias eram lentas e tinham um preço relativamente alto, evitando-se o tempo de carga do aplicativo na memória quando este era freqüentemente utilizado pelos usuários. Desta forma, quando

110

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

o sticky bit estava sinalizado, apenas o primeiro usuário esperava pelo tempo de carga do código executável. Atualmente, devido ao aumento da capacidade de armazenamento na memória principal e diminuição no tempo de acesso às memórias principal e secundária, o sticky bit é praticamente desconsiderado pelos sistemas operacionais atuais quando aplicado a arquivos. Quando o sticky bit utilizado em um diretório, entretanto, a maioria das versões de UNIX não permitem que um usuário apague ou renomeie um arquivo se não for o proprietário ou o superusuário. Caso ele seja o proprietário do arquivo, entretanto, poderá apagar sem problemas, mesmo que não seja o proprietário do diretório (desde que o diretório esteja com o sticky bit ativado, obviamente). Essa convenção é feita para que diretórios como /tmp sejam mais privados e seguros. Para instanciar o sticky bit basta (aplicando-se o exemplo de leitura e execução a todos os usuários):

# chmod 1555 nome_diretorio

Por último, os atributos de tipo são responsáveis por informar o tipo de arquivo associado. Conforme mencionado anteriormente, tais bits são instanciados no momento de criação do arquivo ou diretório e não mais poderão ser modificados. A Tabela 4.4 relaciona os tipos possíveis de arquivos aos caracteres que são exibidos quando é utilizado o comando “ls -l”. Tais caracteres são apresentados, na saída do referido comando, na primeira posição de informação, antes dos campos relativos às permissões.

Tabela 4.4: Símbolos Associados ao Tipo de Arquivo ao Utilizar o “ls -l” Tipo de Arquivo Símbolo Arquivo regular Diretório Arquivo de dispositivo de caracter Arquivo de dispositivo de bloco Socket de domínio UNIX Pipe identificado Link simbólico

d c b s p l

Ainda falando da saída do comando “ls -l”, existem as combinações onde o setuid, setgid e o sticky bit estão instanciados. Os três bits modificarão a forma de apresentação do campo relativo à execução (‘x’) do proprietário, grupo ou outros, respectivamente. A Tabela 4.5 ilustra os símbolos exibidos na saída de “ls -l” nos campos destinados ao ‘x’.

Sistema de Arquivos

111

Tabela 4.5: Valores Possíveis ao Campo Destinado ao Atributo de Execução bit operação seção modificada símbolo c/ exec. habilitada símb. c/ exec. não habilitada setuid setgid sticky bit

proprietário grupo outros

s s t

S S T

Por exemplo, caso tivesse um arquivo que resultasse na seguinte saída antes de instanciar o setuid: -r-xr-xr- 1 fulano grpfulano 123456 Oct 10 2000 /home/fulano/arqX

Após a instanciação do setuid ficaria: -r-sr-xr- 1 fulano grpfulano 123456 Oct 10 2000 /home/fulano/arqX

Porém, no caso do arquivo abaixo: -r-r-r- 1 fulano grpfulano 123456 Oct 10 2000 /home/fulano/arqY

A instanciação do setuid resultaria na exibição do ‘S’, pois o campo de execução do proprietário não havia sido ativado. Sendo assim, a saída do “ls -l” exibiria: -r-Sr-r- 1 fulano grpfulano 123456 Oct 10 2000 /home/fulano/arqY

Uma outra observação a ser feita na saída do “ls -l” refere-se ao número de hard links que o arquivo ou diretório apresenta. Essa informação é exibida logo após a seqüência de bits de permissão. No caso do exemplo anterior, o arquivo arqY apresenta apenas uma referência (a dele mesmo). Os diretórios, por sua vez, apresentam dois hard links: o do diretório pai e o do arquivo especial ‘.” dentro do próprio diretório. Para verificar detalhes sobre o número de referências, pode-se utilizar “ls -i” para exibir o número de i-node associado e verificar outros arquivos que apresentam numeração igual. Ainda sobre o comando chmod, esse utilitário permite também a configuração de atributos de uma forma mnemônica. Isso é feito utilizando-se os símbolos ’+’, ’-’ e ’=’ , para adição, remoção e atribuição, respectivamente, de um dado atributo. Nesse caso, são usados os atributos ’u’, ’g’, ’o’ e ’a’ para indicar, respectivamente o usuário, o grupo, outros e todos ("all”). Por fim, utilizam-se os atributos ’r’, ’w’, ’x’, ’s’ e ’t’ para definir, respectivamente as permissões de leitura (“read”), escrita (“write”), execução (“execute”), usuário/grupo de

112

# $ # # $

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

dando permissão de execução para o usuário no arquivo /tmp/teste chmod u+x /tmp/teste dando permissão de escrita para o grupo e de leitura para outros no arquivo /tmp/teste chmod g+w o+r /tmp/teste Figura 4.10: Exemplos de uso do chmod

execução (“setuid”/ “setgid” ) e deleção restrita (“sticky bit”). A Figura 4.10 ilustra alguns exemplos de uso do chmod dessa maneira. A permissão padrão para arquivos recém-criados pode ser definida por meio do comando umask. Esse comando define as permissões de um arquivo ou diretório recémcriado fazendo um AND binário do complemento de seu argumento (NOT binário) com o modo de permissão total (666 para arquivos e 777 para diretórios). Assim por exemplo, o comando “umask 246” iria fazer com que novos arquivos fossem criados com permissão 420, enquanto diretórios seriam criados com permissão 531, como ilustrado nas Figura 4.11 e Figura 4.12

6668 AND NOT 2468 = (110 110 110)2 AND NOT (010 100 110)2 = (110 110 110)2 AND (101 011 001)2 = (100 010 000)2 = 4208 7778 AND NOT 2468 = (111 111 111)2 AND NOT (010 100 110)2 = (111 111 111)2 AND (101 011 001)2 = (101 011 001)2 = 5318 Figura 4.11: Cálculo de permissões

Sistema de Arquivos

113

$ umask 246 $ touch xxx $ mkdir yyy $ ls -l total 4 -r---w---- 1 joukim users 0 2007-09-19 03:33 xxx dr-x-wx--x 2 joukim users 4096 2007-09-19 03:33 yyy Figura 4.12: Uso do umask

4.9

COMENTÁRIOS FINAIS

O sistema de arquivos é a forma de organização de dados nos dispositivos de armazenamento. Ele tem a função de tornar transparente ao usuário o acesso às informações nele contido. O Linux nesse quesito apresenta uma grande maturidade, graças à implementação de um sistema de arquivos virtual no kernel, o VFS. Com isso, o Linux suporta diversos tipos de sistemas de arquivos, inclusive alguns criptografados e alguns que podem ser acessados na camada de usuários, sem a necessidade de intervenção direta do kernel. O uso de sistemas de arquivos na camada de usuário é possível principalmente graças ao FUSE5 (File system in User Space). O Linux suporta ainda o uso de atributos extendidos, através do comando chattr, ver mais detalhes na página de manual desse comando. Além disso, também suporta ACLs (Access Control Lists - Listas de Controle de Acesso), o que permite ajustes finos na definição de permissões, através do comando selfacl. Ao permitir esse nível de flexibilidade, o Linux mostra-se preparado para enfrentar diversos desafios, no que diz respeito ao armazenamento de informações nos dispositivos de armazenamento. Mais ainda, reflete a maturidade do projeto do Linux frente aos concorrentes.

5 FUSE:

http://fuse.sourceforge.net.

114

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

5 GERENCIAMENTO DE PROCESSOS

5.1

COMENTÁRIOS INICIAIS

O objetivo deste capítulo é apresentar ao leitor os aspectos principais do gerenciamento de processos em Linux. Assume-se que o leitor possua conhecimentos básicos sobre processos, sob a ótica de Sistemas Operacionais. Caso o leitor não possua esses conhecimentos, recomenda-se a leitura de (TANENBAUM, 2001), (SILVA, 2002) ou (OLIVEIRA; CARISSIMI; TOSCANI, 2001). Além dos processos básicos necessários ao gerenciamento de processos, o capítulo também dá destaque aos processos de inicialização e encerramento do Linux. Também são abordados os gerenciadores de boot e métodos de confecção de disquetes de emergência (para inicialização do sistema). Outro assunto apresentado no capítulo é o uso e configuração de memória virtual.

5.2

GERENCIAMENTO DE MEMÓRIA EM LINUX

Antes de se iniciar a abordagem propriamente dita acerca de processos, é conveniente falar sobre a manipulação de memória uma vez que os programas necessitam ser carregados na memória principal para serem executados. O primeiro aspecto se refere à manipulação da porção de memória destinada ao sistema de memória virtual (em Linux denominado como swap) e, o segundo aspecto relaciona-se ao buffer cache. 5.2.1 Swap O gerenciamento de memória em Linux envolve vários aspectos, dentre os quais podese destacar aqueles relacionados à memória virtual. O kernel do Linux faz uso de regiões do disco rígido denominadas como áreas de swap para a manipulação da memória virtual.

116

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

O termo swap é empregado de forma errônea em ambientes Linux, uma vez que a sua memória virtual é baseada em paginação e não em sistema de swap propriamente dito. As regiões de swap podem ser implementadas de duas formas: arquivos de swap (utilizando-se o sistema de arquivos corrente) ou a criação de partição (ou partições) específicas para receber dados de swap. A criação de arquivo de swap é útil no momento em que o administrador não tem o conhecimento acerca do tamanho da partição que deverá ser criada. Nesse caso, pode-se criar um arquivo de swap para, após um tempo de análise em relação ao funcionamento do sistema, criar uma partição com o tamanho necessário. É conveniente salientar que a manipulação do swap por intermédio de partição apresenta como vantagem um maior desempenho computacional no que tange à velocidade do sistema. Uma outra flexibilidade apresentada pelo Linux é que é permissível a manipulação de vários arquivos ou partições de swap simultaneamente. Dessa forma, caso o espaço previamente definido torne-se insuficiente, pode-se simplesmente criar arquivos ou partições adicionais. Para se criar um espaço destinado ao swap, pode-se proceder de acordo com a seqüência abaixo: a) Inicialmente, é necessária a criação do espaço de swap propriamente dito. Para tanto, conforme mencionado anteriormente, pode-se criar um arquivo ou uma partição. No caso de arquivo, a criação é realizada pelo seguinte comando: # dd if=/dev/zero of=/arquivo_swap bs=1024 count=1024 O comando dd realiza a cópia e possível conversão de arquivos (quando solicitado). Para tanto, utiliza os parâmetros if que identifica o arquivo de entrada, of que referencia o arquivo de saída, bs que denota o tamanho dos blocos dos arquivos de entrada e de saída e, por último, count que determina a quantidade de blocos que serão lidos. É conveniente a criação de um sistema de arquivo cujo tamanho seja múltiplo de 4 devido à implementação das páginas no Linux, que têm tamanho de 4KB. Por outro lado, a partição é criada como qualquer outra, exceto pelo seu tipo específico para swap (tipo 82 - Linux Swap). Ver detalhes sobre criação de partições na Seção 4.6. b) Após a criação, a próxima etapa consiste em escrever assinatura ao início da área recém criada. Tal assinatura contém informações a serem utilizadas pelo kernel do sistema. Essa etapa é alcançada por intermédio do comando mkswap, conforme ilustra o exemplo a seguir: # mkswap /arquivo_swap 1024

Gerenciamento de Processos

117

c) Finalmente, ativa-se a área de swap criada utilizando-se o comando

# swapon /arquivo_swap

A mesma conseqüência pode ser obtida, porém apenas no momento de iniciação da máquina (boot) caso seja inserida uma linha no arquivo /etc/fstab. Uma região de swap poderá ser removida pela execução do comando swapoff. O cálculo do tamanho de espaço deverá ser destinado ao swap poderá ser realizado de forma empírica. Para tanto, deve-se somar a quantidade de memória requerida pelas aplicações que serão executadas simultaneamente. Tal estimativa tende a não ser exata, principalmente no caso de que o Linux é um ambiente multiusuário, porém dá uma idéia inicial de espaço a ser utilizado (lembrando que o Linux é capaz de compartilhar código caso existam vários usuários executando um mesmo programa). O refinamento poderá ser feito a partir de observações realizadas em relação à demanda do espaço de swap e aos processos em execução, por meio dos comandos free e ps, respectivamente. Uma alternativa ao comando free consiste em utilizar o sistema de arquivos proc, mais especificamente o arquivo /proc/meminfo. 5.2.2 Buffer cache O sistema Linux também implementa uma estrutura cujo objetivo visa proporcionar uma maior eficiência computacional: o buffer cache. O buffer cache segue a mesma filosofia de funcionamento de uma cache de memória principal e apresenta um tamanho típico de 1 KB. Quanto à escrita, o buffer cache também pode, dependendo do sistema operacional, operar no modo write-back ou write-through. Não há muita coisa a se fazer quanto ao uso do buffer cache, apenas evitar desligar o equipamento ou retirar discos flexíveis incorretamente. Ou seja, não se deve desligar sem shutdown (e/ou sync) e retirar o disco sem desmontá-lo. No Linux, a sincronização do buffer cache (flush) ocorre, aproximadamente, a cada 30 segundos onde o kernel executa, em background, o comando sync. Para tanto, o Linux mantém ativo o serviço denominado bdflush para se encarregar de tal sincronização. Caso, por ventura, o serviço venha a ser fechado, o kernel avisará propriamente sobre o fato e o bdflush deverá ser iniciado novamente (de forma manual) pela execução do comando /sbin/update.

118

5.3

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

COMPONENTES DE UM PROCESSO

Um processo pode ser definido como a instanciação de um programa (código executável). Para tanto, além da transferência do código propriamente dito, são criadas diversas outras estruturas que permitem o sistema operacional gerenciar o processo em questão. Tais estruturas estão associadas aos valores dos registradores vinculados ao processo (contador de programa, flags, etc), ao proprietário do processo, aos arquivos e unidades de I/O sob utilização, aos mecanismos de sincronização entre os processos em execução e outras que contém informações importantes, dentre as quais podem ser destacadas as seguintes: • mapeamento do espaço de endereçamento; • estado corrente do processo (em execução, pronto para execução, bloqueado, suspenso, etc); • prioridade de execução; • identificação dos processos filhos e do processo pai. Existem, nos sistemas baseados em UNIX, diversos parâmetros que afetam diretamente a execução dos processos. Tais parâmetros podem interferir, por exemplo, nas questões tangentes ao escalonamento de processo, recursos disponibilizados e atuação dos sinais. A seguir serão explanados alguns parâmetros que podem ser considerados como mais relevantes em relação à visão de administração de sistemas. PID A cada processo é atribuído, pelo kernel do sistema operacional, um identificador numérico (único em um presente momento) denominado PID (process identifier). A atribuição se faz de forma seqüencial e circular, ou seja, a cada novo processo, tenta-se associá-lo a um número crescente em relação ao processo instanciado anteriormente. Porém, caso é chegado ao final da capacidade de representação numérica, o kernel reinicia a contagem em 1, procurando por valores que tiveram seus processos associados já terminados. PPID O atributo PPID identifica o processo pai de um certo processo. Em sistemas baseados em UNIX, para a criação de um processo novo (utilização do fork), algum processo em execução deverá ser clonado e, após, caso necessário, ter o seu código trocado. A este processo que fora clonado é denominado como processo pai. Desta forma, o

Gerenciamento de Processos

119

atributo PPID de um processo consiste no PID do processo do qual foi clonado. Nesse mecanismo, convém destacar o processo init (o qual recebe o valor 1 de PID). O init tem a função de criar inicialmente um shell afim de que os scripts rc possam ser executados. A partir do init todos os processos utilizados pelo kernel são instanciados. Além da criação do processos, o init é responsável pela execução da primitiva _exit() cuja função consiste em notificar o kernel sobre a existência de um processo pronto para ser finalizado. Uma questão interessante é que, na morte de processos pais, os processos filhos "órfãos"passam a ter como pai o init. UID e EUID O UID referencia a identificação (User Identification) do processo, enquanto que EUID representa o UID efetivo. A distinção é útil para mapear os recursos que o processo poderá se apropriar, ou seja, processos com o mesmo EUID (podendo ter UID distintos) terão os mesmos direitos sobre os mesmos recursos. GID e EGID Assim como os usuários possuem identificação real e efetiva (UID e EUID, respectivamente), situação idêntica ocorre com os grupo. Assim um processo também é referenciado pelo GID (group identification) e EGID (effective GID). Os propósitos de se manter duas identificações são análogos em relação aos usuários. Cortesia (Niceness) O atributo cortesia é utilizado pelo kernel para fins de escalonamento de processo. Sendo assim, o kernel manipula a questão de prioridade em função do tempo que o processo consumiu de CPU em sua última fatia de execução, o tempo de espera para execução e o atributo de cortesia. O valor de cortesia varia geralmente em uma escala numérica de amplitude 40, onde um valor mais alto denota um processo com baixa prioridade, ou seja, apresenta um alto grau de cortesia perante os demais processos. Para se instanciar ou alterar o atributo de cortesia, utiliza-se os comandos nice e renice, respectivamente. A diferença básica entre os dois consiste nos argumentos que lhe são passados. Como o nice é utilizado para instanciar a ordem de prioridade de um processo, ele recebe como argumentos o valor da cortesia e o caminho (path) do programa a ser executado, conforme é ilustrado abaixo: # nice +8 /users/someone/task01

120

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

Por sua vez, o comando renice, pelo fato de ser utilizado para modificar o valor de cortesia associado a um processo, aceita como parâmetros o valor da cortesia e o PID do processo (ou às vezes é possível passar a referência de um usuário): # renice +8 12345 O usuário deve ficar atento quanto à utilização dos comandos nice e renice, pelo fato de não haver uma padronização em relação aos seus argumentos. Por exemplo, alguns sistemas utilizam uma faixa de cortesia entre 0 a 39 e outros entre –20 a 20; alguns sistemas solicitam o valor de cortesia como um valor absoluto enquanto outros requerem que o valor seja a variação frente ao atualmente em curso e, também, existem variações em relação à sintaxe dos comandos. Recomenda-se, antes de seu uso, que o administrador verifique as páginas de manuais desses comandos. Terminal de controle (TTY) Terminais de controle representam interfaces entre o processo e as saídas-padrão (canais de entrada, saída e de erro). Um outro objetivo da utilização destes terminais reside no fato de atuarem junto aos pedidos de interrupção do sistema a nível de processos (sinais). Um dos comandos úteis para a manipulação dos terminais é o stty. Por intermédio desse, há a possibilidade de alteração e consulta em relação às configurações dos drivers de terminal. Através do comando stty, pode-se configurar, por exemplo, um terminal e seus caracteres de controle. Por exemplo, no comando abaixo, um terminal de hardware é configurado em uma operação de trabalho a 9600 bps, paridade par e sem tabulação de hardware. Nota-se que o sinal de menos (no caso o campo tabs) desabilita a característica referenciada pelo argumento. # stty 9600 even -tabs Por outro lado, o comando subseqüente configura os caracteres de controle relativos à interrupção, cancelamento e tecla de erase como ^C, ^U e ^H, respectivamente. A diferença entre interrupção e cancelamento de um processo é descrita na Seção 5.4 deste capítulo. # stty intr ^C kill ^U erase ^H Convém mencionar que um terminal também pode ser iniciado por intermédio do comando tset. A este comando pode ser passado como parâmetro a identificação de um tipo de terminal pré-definido ou utilizá-lo sem parâmetros de modo que o comando possa usar a variável de ambiente TERM.

Gerenciamento de Processos

5.4

121

SINAIS

Sinais representam requisições de interrupção a nível de processos, permitindo e objetivando, entre outros: a) comunicação entre processos; b) ações do usuário, do tipo: suspender processos (^Z), finalizar (^C), “congelar” saída (^S), etc. (esses sinais são enviados ao processo por intermédio do driver de terminal); c) ações do administrador por intermédio do comando kill (para reiniciar, finalizar processos, etc.); d) finalização, pelo kernel, de processos quantos estes executarem, por exemplo, alguma operação ilegal, acesso indevido à regiões de memória, etc.

Tabela 5.1: Sinais Comuns Utilizados em Ambientes UNIX-like #

Nome

Descrição

Padrão

Capturado

Bloqueado

Dump mem.

1 2 3 9 * * 15 * * * * * *

HUP INT QUIT KILL BUS SEGV TERM STOP TSTP CONT WINCH USR1 USR2

Hangup Interrupção Fechamento Eliminação Erro de barramento Falha segmentação Terminação de software Parada Parada de teclado Continue após parada Janela alterada Definido pelo usuário Definido pelo usuário

Terminar Terminar Terminar Terminar Terminar Terminar Terminar Parar Parar Ignorar Ignorar Terminar Terminar

Sim Sim Sim Não Sim Sim Sim Não Sim Sim Sim Sim Sim

Sim Sim Sim Não Sim Sim Sim Não Sim Não Sim Sim Sim

Não Não Sim Não Sim Sim Não Não Não Não Não Não Não

A Tabela 5.1 apresenta os sinais mais comuns dentro sistemas derivados do UNIX. Os mesmos poderão ser utilizados diretamente com o comando kill, conforme será descrito mais adiante. Nessa tabela, os itens explicitados nas colunas possuem as seguintes denotações: # → representa o número do sinal. Alguns sinais, como o HUP utilizam numeração padrão em todos os sistemas baseados no UNIX. Porém outros podem variar de sistema para

122

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

sistema (na tabela marcados com um asterisco). Para obter informações acerca da numeração correta no sistema em uso, o arquivo /usr/include/signal.h pode ser consultado ou, ainda, consultar o manual, através de man 7 signal. Nome → nome utilizado por convenção. Em alguns sistemas é comum encontrar o prefixo SIG, como por exemplo, SIGHUP para o caso do HUP. Descrição → descrição da ação associada ao sinal. Padrão → representa a ação que deverá ser tomada frente ao processo: se terminá-lo, interrompê-lo momentaneamente (parar) ou ignorar o sinal (neste caso, o sinal pode ser manipulado por algum módulo tratador associado ao processo). Capturado → indica se o sinal poderá ser capturado e tratado previamente por alguma rotina de tratamento de sinais associada ao processo em questão. Caso a captura não seja possível, a ação do sinal é imediata sobre o processo por ação do kernel do sistema. Bloqueado → os programas poderão solicitar o bloqueio quanto ao recebimento de sinais. Nesse caso, os novos sinais que porventura cheguem ao processo poderão ser enfileirados para futura manipulação. Dump mem. → apenas informa se haverá ou não o descarregamento (dump) de memória na ocorrência do sinal. Uma explicação sumária dos sinais apresentados na Tabela 5.1 é feita a seguir: HUP: utilizado para reiniciar serviços ou terminar processos ordinários. Desta forma, o HUP pode ser utilizado para atualizar a lista de recursos associados a um serviço. No caso em que é desejável tornar processos em background imunes ao sinal HUP, pode-se evocá-los por intermédio do comando nohup. INT: sinal de interrupção, sendo geralmente associado ao caracter de controle ^C. QUIT: denota uma solicitação para o processo terminar completamente a execução. Neste caso, espera-se que o processo receptor limpe o seu estado e se finalize. Como conseqüência do QUIT, um dump de memória é produzido; KILL: finaliza um processo a nível de sistema operacional. Conforme citado na Tabela 5.1, o KILL nunca pode ser bloqueado e capturado pelos processos. BUS: sinal indicativo de erro do sistema referente ao barramento. SEGV: sinal indicativo de erro do sistema no que tange ao controle de memória virtual. TERM: semelhante ao QUIT, porém não produz dump de memória. STOP: suspende a execução de um processo até o recebimento de um sinal CONT. TSTP: igualmente ao STOP, suspende a execução de um processo. Porém os processos antes de serem suspensos, limpam os seus estados e, em seguida, enviam para si próprios um sinal STOP.

Gerenciamento de Processos

123

CONT: continua a execução de um processo interrompido pela utilização do sinal STOP. WINCH: sinal utilizado para que os processos possam modificar suas informações referente às saídas-padrão devido à possíveis reconfigurações de, por exemplo, emuladores de terminais. Como já mencionado, os sinais podem ser manipulados pelo comando kill. Dessa forma, por exemplo, caso haja a necessidade de reiniciar um processo, pode-se utilizá-lo da seguinte forma: # kill -1 <processID> No caso acima, haverá a reiniciação do processo identificado pelo seu ID (processID). Por outro lado, caso haja a necessidade de forçar o término de um processo, basta substituir o argumento ‘-1’ (um) pelo ‘-9’.

5.5

MONITORAÇÃO DE PROCESSOS

A monitoração de sistemas derivados do UNIX pode ser realizada pela execução dos comandos ps e top. O comando ps possui variações em termos de seus parâmetros de entrada e a forma de saída exibida ao usuário. Tais variações são resultantes de implementações distintas entre sistemas derivados do FreeBSD e do System V. As variações do ps, entretanto, fornecem informações semelhantes a serem utilizadas pelos usuários normais e administradores de sistemas UNIX. A utilização mais comum do ps é utilizando-se os argumentos aux como descrito no exemplo abaixo referente a sistemas RedHat: # ps aux No caso acima, o argumento ‘a’ referencia a todos os processos. Já o parâmetro ‘u’ torna ativa a exibição de todos os usernames e, por último, o ‘x’ indica todos os processos não vinculados a um terminal. A saída do ps passando como argumentos o termo aux exibe as informações descritas na Tabela 5.2. Uma outra maneira bem interessante de utilizar o comando ps consiste em utilizar os parâmetros lax (funcionais nas versões de ps disponibilizadas no RedHat e derivados), conforme a linha de comando abaixo: # ps lax

124

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

Tabela 5.2: Informações Exibidas na Saída do Comando ‘ps aux’ Campo

Descrição

USER PID % CPU % MEM VSZ RSS TT STAT STARTED TIME COMMAND

Proprietário do processo na forma de username (login) Identificação do processo Porcentagem de CPU utilizada pelo processo Porcentagem de memória virtual utilizada pelo processo Tamanho virtual do processo (em KB) ˙ Tamanho configurado residente (numero de páginas de 1KB na memória) Identificação do terminal de controle Estado do processo (ver Tabela 5.3) Momento de início de execução do processo Tempo de CPU consumido pelo processo até então Comando de linha e argumentos associados na iniciação do processo

Tabela 5.3: Notações Utilizadas pelo Campo STAT Estado R I T

Descrição Em execução Dormindo (mais do que 20 segundos) Parado

Flags Adicionais > N < A S V

Prioridade mais alta do que o normal Prioridade mais baixa que o normal Excedendo limite soft de memória Solicitou troca aleatória de página Solicitou substituição FIFO de página Processo suspenso durante um vfork

Estado D S Z

Descrição Espera no disco Dormindo (menos que 20 segundos) Zumbi

Flags Adicionais E L X s W +

Processo tentando sair (exit) Páginas bloqueadas na memória Processo sendo ratreado ou depurado Líder de sessão – terminal de controle Processo é descarregado em disco Processo em foreground

Neste caso, a saída exibirá as informações: UID, PID, PPID, CPU, PRI, NI, VSZ, RSS, WCHAN, STAT, TT, TIME e COMMAND. Os campos que diferem em relação à utilização do ps passando como argumento aux é ilustrado na Tabela 5.4. Por outro lado, uma visão não instantânea dos processos pode ser obtida utilizando-se o comando top (utilitário desenvolvido por William Lefebvre). O referido utilitário fornece regularmente um resumo acerca dos processos ativos, exibindo informações atualizadas a cada unidade de tempo (o padrão equivale a cada 10 segundos). Isso é feito eficientemente, pois o utulitário consome apenas uma pequena fração de processamento da CPU.

Gerenciamento de Processos

125

Tabela 5.4: Campos da Saída do ‘ps lax’ que Diferem da Execução do ‘ps -aux’ Campo

Descrição

UID PPID CPU PRI NI WCHAN

Identificação do usuário (sob a forma de UID - User ID) Identificação do processo pai Utilização do processador para processamento Prioridade do processo Valor "nice" Endereço de um evento pelo qual o processo está esperando. Caso o campo esteja em aberto, significa que o processo está como “running”

Além das informações dos processos de forma semelhante à execução do ps, o comando top também disponibiliza as relativas ao sistema como um todo. Como exemplo dessas informações pode-se citar a quantidade de memória total e utilizada do sistema, consumo de CPU frente aos processos dos usuários e do sistema e quantidade de processos em execução e sua distribuição segundo seu estado corrente. Uma outra funcionalidade importante do top é a possibilidade de envio de sinais aos processos e a manipulação do valor de cortesia (prioridade), aceitando para tanto, entradas por intermédio do teclado. Uma utilização importante consiste em monitorar processos suspeitos (por exemplo, aqueles que já derrubaram o sistema). Para tanto, utiliza-se o top com o argumento -q afim de torná-lo um processo com alta prioridade de execução. Alguns processos, naturalmente ou por falha de implementação/execução podem consumir grandes frações de um recurso, como CPU e espaço em disco. Nesse caso, há um desequilíbrio no comportamento do sistema em virtude de atrasos e a falta de sincronização em relação aos componentes do sistema. Tais processos são chamados popularmente como processos fugitivos. Porém o administrador deverá ter bom senso ao se deparar com processos fugitivos pela possibilidade de não conhecer o seu comportamento real, por exemplo, existem processos (como simulações) que realmente têm um alto consumo de processamento de CPU. Nessa situação, tais processos deverão ser examinados afim de que se possa tomar uma decisão acertada. O exame dos processos fugitivos pode ser realizada por intermédio de contato com o proprietário, pesquisa acerca do programa em execução, sondagem no diretório do proprietário para verificar os tipos de arquivos gravados ou examinar o código-fonte do processo fugitivo. Neste meio tempo, caso achar conveniente, o administrador poderá suspender

126

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

temporariamente o processo enviando ao mesmo um sinal STOP e, após a verificação, continuá-lo pelo envio do sinal CONT ou eliminá-lo com o KILL. Por sua vez, os processos que consomem espaço em disco não poderão ser visualizados pelo ps. Nesse caso, a verificação pode ser realizada utilizando-se os comandos fuser e lsof, a fim de verificar informações acerca dos arquivos e diretórios. O comando fuser informa quais os usuários (UID) cujos processos sob suas responsabilidade estão utilizando os arquivos passados como argumento e, o lsof lista os arquivos abertos. Por exemplo, caso algum usuário execute o script apresentado na Figura 5.1, o sistema tenderá a preencher sua tabela de i-nodes, não permitindo, desta forma, que os usuários criem novos arquivos e diretórios. Com a execução desse script, será criada uma árvore extremamente profunda de diretórios, sendo geralmente impraticável ser removida pelo comando “rm -r”. Dessa forma, o administrador deverá criar um script que caminhe pelos níveis dos diretórios removendo-os à medida os mesmos são percorridos até o diretório inicial. While 1 mkdir diretoriosacana cd diretoriosacana touch arquivoigualmentesacana end

Figura 5.1: Script que Cria uma Árvore de Diretórios Extremamente Profunda

5.6 5.6.1

INICIANDO E ENCERRANDO O SISTEMA Visão Geral

Para a etapa de iniciação (bootstraping), é requerida, por parte do administrador, muito conhecimento de modo que ele possa configurar o ambiente da melhor forma possível. Em primeira instância, o administrador configura o processo de boot por intermédio da edição dos arquivos referentes aos scripts de sistema (denominados como rc – run command). Uma visão melhor dos scripts será abordada mais adiante. Uma outra configuração que pode ser realizada consiste em modificar alguns parâmetros do kernel como o número máximo de i-nodes que poderão ser utilizados por um processo. Tal mudança é realizada sobre alguns arquivos localizados no sistema de arquivo /proc. A Tabela 5.5 mostra alguns desses parâmetros, com os valores padrões de ajuste e seus respectivos arquivos.

Gerenciamento de Processos

127

Tabela 5.5: Arquivos Importantes de Configuração do Kernel Localizados no /proc Arquivo /proc/sys/fs/file-max

Default 4096

/proc/sys/fs/inode-max

16384

/proc/sys/net/ipv4/ip_forward

/proc/sys/net/ipv4/icmp_echo_ignore_all

/proc/sys/net/ipv4/icmp_eco_ignore_broadcasts

Descrição ˙ Numero máximo de arquivos abertos por processo ˙ Numero máximo de inodes abertos por processo Permite encaminhamento de IP quando configurado como 1 Ignora pings de ICMP quando configurado como 1 Ignora pings de broadcast quando configurado como 1

Para se alterar o valor de tais arquivos, pode utilizar simplesmente o comando echo, redirecionado sua saída, conforme é ilustrado a seguir:

# echo 512 > > /proc/sys/fs/file-max

No caso acima, o número máximo de arquivos abertos pelo sistema passa a valer 512. Para possibilitar tais mudanças de forma permanente é necessário introduzir as linhas com o comando echo em scripts rc. Isso porque o sistema de arquivo /proc é um sistema virtual montado na memória volátil do computador, como comentado na Seção 4.2.3. Antes que o sistema esteja disponível para a operação normal, acontecem alguns passos: carregamento e inicialização do kernel, detecção e configuração dos dispositivos, criação de processos espontâneos do sistema (não criados com fork) e execução dos scripts. Convém salientar que, com o kernel carregado na memória principal e após realizada a detecção e configuração dos dispositivos, é instanciado o processo init, com PID igual a 1, que tem a função de, por exemplo, desencadear todo o restante do processo de boot, como por exemplo, a execução dos scripts rc. Existem dois modos de iniciação do sistema Linux: a manual e a automática. No modo manual, o administrador participa do processo de boot interagindo com o sistema antes da execução dos scripts de sistema. Este modo é extremamente útil quando algum problema impedir o boot automático, como por exemplo um sistema de arquivos corrompido. Por sua vez, o modo automático realiza o processo de boot completamente sem a intervenção do operador.

128

5.6.2

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

O Processo init

O processo init é a última etapa no procedimento de boot e possui um PID valendo 1. Ele é responsável pela execução dos scripts conforme definido no arquivo /etc/inittab (que será visto na próxima seção). Porém, a execução dos scripts passa a ser responsabilidade de um processo instanciado pelo init representado pelo script localizado em /etc/rc. O script /etc/rc, geralmente um link para /etc/rc.d/rc, executa uma série de outros scripts localizados nos subdiretórios /etc/rc.d/rc0.d/, /etc/rc.d/rc1.d/, /etc/rc.d/rc2.d/, etc. Convém salientar que o número introduzido ao nome do diretório está vinculado ao nível operacional, por exemplo, /etc/rc.d/rc3.d/ refere-se aos scripts de nível 3. Tais níveis serão abordados a seguir. Os scripts mencionados acima são executados em cada etapa do processo de boot e, podem ser classificados como scripts de boot (cujos nomes são iniciados pela letra ‘S’ - startup) e scripts de shutdown (com seus nomes iniciados pela letra ‘K” - kill). Os números que sucedem estas letras denotam a ordem de operação (ordem seqüencial ascendente). Tais arquivos, na verdade, são links simbólicos aos arquivos localizados no diretório init.d, que normalmente está localizado no /etc. O RedHat apresenta, além dos scripts mencionados, o script rc.local que é o último a ser executado. Conforme já citado, existem, em ambientes derivados do UNIX, diversos níveis operacionais (runlevels), listados na Tabela 5.6. Sistemas RedHat suportam até 10 níveis operacionais, porém os numerados de 7 a 9 são indefinidos. Tais níveis poderão ser escolhidos por intermédio do parâmetro ao init (por exemplo “init 3”, caso seja desejado o nível 3) ou utilizar o comando telinit.

Tabela 5.6: Modos de Iniciação de Sistemas Derivados do UNIX

Runlevel

Descrição

0 1 2 3 4 5 6 S ou s M

Shutdown Modo monousuário Multiusuário sem serviços de rede Multiusuário – modo textual Reservado para uso local ou, no caso do Slackware, X-windows XDM X-window (Redhat/System V) Reboot Modo monousuário/manutenção (Slackware) Modo multiusuário (Slackware)

Gerenciamento de Processos

129

Após o processo de boot propriamente dito, o init criará múltiplas instâncias de processos getty que serão responsáveis por esperar pelos logins dos usuários a fim de iniciar seus referidos shells. Além de gerenciar o processo de boot, o init também gerencia as etapas durante o processo de shutdown, também conforme instruções inseridas no arquivo /etc/inittab. 5.6.3

O Arquivo /etc/inittab

Como mencionado anteriormente, o arquivo /etc/inittab tem a função de direcionar o processo de iniciação do sistema, como por exemplo, indicar o runlevel padrão. A linha a seguir indica que o runlevel default é o 5 (os campos serão explicados em seguida). id:5:initdefault: Cada linha do arquivo /etc/inittab é formada pelos campos: id:runlevels:action:process Onde: Id: Apenas um identificador da entrada (linha) contendo de 1 a 4 caracteres. Runlevels: Indica em quais runlevels a ação referida será processada. Action: Ação a ser tomada. A Tabela 5.7 indica quais as possíveis ações que poderão constar no campo action. Process: Caminho ao código executável que será processado. A Figura 5.2 apresenta um exemplo de um arquivo /etc/inittab. A interpretação desse arquivo é relativamente simples e deixada como exercício para o leitor. 5.6.4

Encerramento e Reinicialização do Sistema

As etapas que envolvem encerramento (com ou não reinicialização) são também críticas para o bom funcionamento do sistema, principalmente em relação aos sistemas de arquivo. Praticamente existem três comandos principais para a realização destes eventos: shutdown, halt e reboot. O comando shutdown é forma mais segura e completa para se encerrar, reiniciar ou tornar o ambiente monousuário. A escolha da ação é feita em função dos argumentos

130

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

Tabela 5.7: Possíveis Ações do Campo Action do inittab Nome da ação

Descrição

respawn

O processo será executado, independente do runlevel, durante o processamento dos scripts pelo init Nada a ser realizado Processos marcados como ondemand, irão ser executados apenas no runlevel especificado Indicativo do runlevel default. O campo referente ao processo é ignorado O processo será executado no processo de boot antes de qualquer outra etapa, desprezando-se, assim, o runlevel Em sistemas dotados de UPS, o processo referenciado pela linha será executado durante uma queda de energia (na espera do retorno da energia) Semelhante ao powerwait, exceto pelo fato de que o init não completará a ação em curso O evento será processado tão logo a energia seja restaurada (sistemas com UPS) Em sistemas com UPS, esse evento será executado quando na ausência de energia principal e a bateria também debilitada Evento será executado quando o init recebe um sinal provocado pelo pressionamento de CRTL-ALT-DEL

off ondemand initdefault sysinit powerwait

powerfail powerokwait powerfailnow ctrlaltdel

passados como parâmetro). Com o comando consegue-se, por exemplo, além dos eventos mencionados: determinar o momento do evento, avisar os usuários da ocorrência do evento afim de que eles possam encerrar seus aplicativos e manipular os dados gravados em disco antes do encerramento e executar o fsck após a reinicialização. Por outro lado, o comando halt representa uma maneira mais simples de se encerrar o sistema, realizando apenas as ações essenciais no processo de desligamento: realiza um log da operação, elimina processos não essenciais, evoca o sync, espera as gravações nos sistemas de arquivos serem concluídas e, finalmente, suspende o kernel. Existe a opção ‘-n’ que não evoca o sync (fazendo com que não haja a sobrescrita de versões antigas dos superblocos após a execução de um fsck) e a opção ‘-q’ que representa uma parada quase imediata (não escrevendo log, realizando sys e derrubando processos). Finalmente, o reboot é semelhante ao halt, porém causa a reiniciação da máquina. A mesma ação pode ser realizada com “shutdown -r”.

Gerenciamento de Processos

131

# Level to run in id:2:initdefault: # System initialization before anything else. si::sysinit:/etc/rc.d/bcheckrc # Runlevel 0,6 is halt and reboot, 1 is maintenance mode. l0:0:wait:/etc/rc.d/rc.halt l1:1:wait:/etc/rc.d/rc.single l2:2345:wait:/etc/rc.d/rc.multi l6:6:wait:/etc/rc.d/rc.reboot # What to do at the "3 finger salute". ca::ctrlaltdel:/sbin/shutdown -t5 --rf now # Runlevel 2{&}3: getty on console, level 3 also getty on modem port. 1:23:respawn:/sbin/getty tty1 VC linux 2:23:respawn:/sbin/getty tty2 VC linux 3:23:respawn:/sbin/getty tty3 VC linux 4:23:respawn:/sbin/getty tty4 VC linux S2:3:respawn:/sbin/uugetty ttyS2 M19200

Figura 5.2: Arquivo /etc/inittab

5.6.5

Modo Monousuário

O modo monousuário é extremamente útil para a realização de manutenção em ambientes Linux. Caso o administrador esteja utilizando o GRUB ou o LILO como gerenciador de boot1 , e possível iniciar o ambiente em modo monousuário da seguinte forma: Com LILO: no prompt do LILO, digite “linux single”. Caso o LILO não tenha entrada para uma imagem antiga e for necessário realizar o boot pelo disquete porém deixando como partição raiz aquela localizada no hd, pode-se proceder da seguinte forma: boot:

linux single root=/dev/hdXX initrd=

Nesse caso, o XX deverá ser substituído pela identificação da partição que se tornará a root e, deixando-se em aberto o initrd faz com que seja desprezada a imagem 1 Mais

detalhes sobre LILO e GRUB na Seção 5.9

132

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

do diskette de boot, entrando em modo monousuário imediatamente. Um outro parâmetro importante que poderá ser utilizado consiste no init=path onde o path especifica o caminho para um programa init que será executado no momento do boot. Com GRUB: os argumentos são idênticos ao LILO modificando-se apenas a forma de introduzí-los ao prompt. Neste caso, basta selecionar a linha relativa ao Linux e editála, retornando, em seguida, à tela principal do GRUB afim de finalizar o processo da escolha da imagem.

5.7

GERENCIAMENTO DE SERVIÇOS

Um tipo especial de processo a que o administrador deve estar atento são os serviços. Serviços podem ser entendidos como recursos oferecidos a aplicativos clientes por programas servidores (daemons). Esses daemons geralmente ficam residente em memória, executando com permissões especiais. Exemplos clássicos de servidores são o httpd, o sendmail e vários outros. Em geral, esses serviços oferecem quatro tipos básicos de ações para seu controle: status, start, stop e restart. A ação status informa se o servidor está rodando e com qual PID. Para iniciar um serviço, usa-se a ação start. Esse serviço pode ser parado com a ação stop. Para reiniciliazar um servidor, por motivos de reconfiguração ou outros, usa-se a ação restart. Na maioria das distribuições Linux, os arquivos de serviço ficam geralmente no diretório /etc/rc.d/init.d. Assim, para reiniciar o serviço Web, bastaria executar o comando # /etc/rc.d/init.d/httpd restart Uma forma mais adequada e interessante é utilizar-se do comando service. Nesse caso, bastaria executar: # service httpd restart Como pode ser percebido, a sintaxe desse comando é bem simples, exigindo que se passe apenas o nome do serviço e a ação a ser tomada. Uma última observação a ser feita com relação a serviços é que outras ações podem estar disponibilizadas. Para saber quais as ações disponibilizadas por um servidor, basta executar o comando service nome_do_servico. Como não foi informada nenhuma ação, ele irá informar as ações disponíveis.

Gerenciamento de Processos

5.8

133

DISQUETES DE EMERGÊNCIA

Discos de emergência são sempre úteis para poder iniciar sistemas com problemas que impedem realizar o boot com sucesso. A partir do boot via disquete, pode-se realizar a etapa de manutenção do sistema. Existem duas maneiras de se criar um disco de boot. A primeira consiste simplesmente na utilização do aplicativo mkbootdisk, conforme ilustra a seguir: # mkbootdisk -device /dev/fd0 2.2.14 O comando mkbootdisk, nesse caso, recebeu como parâmetro o dispositivo utilizado pelo disquete e a versão do kernel. Porém, o comando mkbootdisk apenas pode ser executado pelo usuário root e em kernels modularizados (não monolíticos). Caso não seja possível utilizar esse comando, a seqüência a seguir ilustra uma segunda maneira: a) formatar o disco: # fdformat /dev/fd0H1440 b) copiar a imagem vmlinuz de /boot ao disquete: # cp /boot/vmlinuz /dev/fd0 c) determinar o dispositivo raiz do kernel: # rdev d) instanciar o dispositivo raiz no disquete utilizando a saída do comando anterior – suponha, por exemplo, /dev/sda10: # rdev /dev/fd0 /dev/sda10 e) marcar o dispositive raiz como read-only: # rdev -R /dev/fd0 1 f) reiniciar o sistema para teste (inserindo o disquete no driver): # reboot Apenas uma dica: caso o problema de não conseguir iniciar o sistema normalmente pelo hd foi gerado pela adição de um novo device ou pelo upgrade do kernel, talvez seja necessário atualizar as entradas localizadas no /dev. Para tanto, basta utilizar os seguintes comandos: # cd /dev # ./MAKEDEV update

134

5.9

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

GERENCIADORES DE BOOT

Existem vários gerenciadores de boot disponíveis no mercado capazes de inicializar o Linux. É possível, inclusive, usar gerenciadores de boot comerciais (como o gerenciador disponível no Windows NT ou Windows 2000). Os mais conhecidos e utilizados no mundo Linux são, com certeza, o LILO2 e o GRUB3 . Mas não podem ser esquecidos também o GAG4 e o XOSL5 , esse último totalmente em interface gráfica e bastante promissor. Nesta seção serão abordados apenas o LILO e o GRUB. 5.9.1

LILO

LILO é a abreviação de LInux boot LOader, ou seja, é um aplicativo responsável pela carga do sistema operacional na máquina. O LILO apresenta a flexibilidade de poder fazer a carga a partir de qualquer sistema de arquivo, além de possibilitar ao usuário escolher o sistema operacional que será carregado. Os arquivos pertencentes ao LILO poderão ser encontrados no diretório /etc/lilo ou, nas versões mais novas, no /sbin e /boot. Quando do upgrade do LILO, há a necessidade de realizar um update do setor de boot a fim de adicionar as novas localizações e formatos utilizados. Para tanto, basta executar o aplicativo lilo (geralmente em /sbin/lilo). As modificações também poderão ser realizadas manualmente, atuando diretamente no arquivo /etc/lilo.conf (ou /etc/lilo/config para as versões mais antigas do LILO). A Figura 5.3 apresenta um exemplo de configuração do LILO devidamente comentado. Mais detalhes podem ser conseguidos via man lilo e man lilo.conf. 5.9.2

GRUB

O GRUB (GRand Unified Bootloader), foi originalmente projetado e implementado por Erich Stefan Boleyn e hoje é distribuído como software livre por intermédio do projeto GNU. Como características principais, podem ser destacadas as seguintes: • utiliza um arquivo de configuração textual; • a interface por meio de menus; • possui flexibilidade mediante linha de comando; • suporta múltiplos tipos de sistemas de arquivos; 2 LILO:

http://brun.dyndns.org/pub/linux/lilo/ http://www.gnu.org/software/grub/grub.html 4 GAG: http://gag.sourceforge.net/ 5 XOSL: http://www.xosl.org/ ou http://xosl.sourceforge.net. 3 GRUB:

Gerenciamento de Processos

135

# mostra menu do lilo prompt # espera 20 segundos antes de bootar o SO default timeout=20 # sistema default é linux default=linux # onde fica o setor de boot (geralmente o primeiro disco) boot=/dev/hda # primeiro SO: Linux image=/boot/vmlinuz-2.4.18-3 label=linux initrd=/boot/initrd read-only root=/dev/hda5 #hdc e’ gravador de CDs, habilitando emulacao SCSI append="hdc=ide-scsi" # segundo SO: Windows other=/dev/hda1 optional label=Windows

Figura 5.3: Exemplo de /etc/lilo.conf

• suporta descompressão automática; • acessa dados em qualquer dispositivo instalado; • faz tradução de geometria independente; • suporta modo LBA (Logical Block Address); • pode realizar downloads de imagens pela rede; • suporta sistemas diskless (sem unidades de disco); • suporta terminais remotos. A configuração manual pode ser realizada mediante a edição em um dos arquivos /boot/grub/menu.lst ou /etc/grub.conf (em sistemas RedHat, esses dois arquivos são links simbólicos para /etc/boot/grub.conf). Para tanto, pode-se utilizar um dos comandos listados na Tabela 5.8. Para se ter uma melhor idéia do arquivo de configuração do GRUB, a Figura 5.4 apresenta um exemplo comentado. Além desses apresentados, o GRUB admite diversos outros comandos aqui não citados. Maiores detalhes sobre o GRUB podem ser obtidos através de info grub.

136

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

Tabela 5.8: Principais Comandos a Serem Utilizados em /boot/grub/menu.lst Comando

Descrição

default num

Configura entrada default (referenciada por num – sendo a numeração iniciada em zero). Caso o comando não seja especificado, a entrada default ˙ será a de numero 0 (zero) Caso a iniciação mediante a entrada default falhe, o GRUB esperará um momento pela interação do usuário. Caso esta não venha a acontecer, será realizada uma tentativa de iniciar a máquina por usando a entrada apontada pelo comando fallback Utilizando-se este comando, o menu não será exibido e a entrada default será iniciada após o término do tempo especificado por timeout. O usuário pode solicitar o aparecimento do menu pressionando <ESC> antes do timeout Desabilita todos os controle de edição interativa e entradas protegidas pelo comando lock. Caso passwd seja entrada, será lido o new-configfile como novo arquivo de configuração. Caso o new-config-file não seja especificado, o GRUB simplesmente irá liberar as instruções privilegiadas Instancia o tempo máximo para a escolha da imagem pelo usuário (em segundos). Caso o usuário não intervenha neste período, a entrada default será iniciada Inicia uma entrada de boot (veja exemplo de arquivo a seguir)

fallback num

hiddenmenu

password passwd [new-config-file]

timeout sec

title name

Gerenciamento de Processos

#/boot/grub/menu.lst # Boota a primeira entrada, por default default=0 # Boota automaticamente após 30 segundos timeout=30 # Se der falha boote a segunda entrada fallback 1 # Configura uma tela para o boot # (hd0,1) indica primeiro disco (hd0), segunda partição (1) # arquivo está em /boot/grub/splash.xpm.gz splashimage=(hd0,1)/grub/splash.xpm.gz # Agora vem as opções do menu # Configurando o Linux com /boot em /dev/hda2 title Linux Grafico (2.4.18-10) # /boot em /dev/hda2 root (hd0,1) # 5 - inicia em modo gráfico multiusuário # hdc é gravador de CD, precisa de emulação SCSI kernel /vmlinuz-2.4.18-10 ro root=/dev/hda5 hdc=ide-scsi 5 initrd /initrd-2.4.18-10.img title Linux Texto (2.4.18-10) root (hd0,1) # 3 - inicia em modo texto multiusuário kernel /vmlinuz-2.4.18-10 ro root=/dev/hda5 hdc=ide-scsi 3 initrd /initrd-2.4.18-10.img # Configura o Windows em /dev/hda1 title Windows [TM] rootnoverify (hd0,0) chainloader +1 # Instala o GRUB no disco rígido title Install GRUB into the hard disk root (hd0,0) setup (hd0) # Permite trocar as cores do menu title Trocar Cores color light-green/brown blink-red/blue

Figura 5.4: Arquivo /boot/grub/menu.lst

137

138

5.10

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

COMENTÁRIOS FINAIS

O gerenciamento de tarefas em Linux é relativamente simples e, em geral, requer apenas o uso dos comandos ps e kill. Existem várias interfaces gráficas para esses comandos, mas é importante que o administrador conheça suas peculariedades no modo texto. Além disso, o Linux é altamente configurável no que se diz respeito ao processo de inicialização e encerramento. O poder de escolha é alto, inclusive no que se diz respeito ao gerenciamento do processo de boot. Este capítulo não abrange tudo a esse respeito, mas apresenta os aspectos principais necessários à uma boa administração. Espera-se, como sua leitura, que o administrador Linux tenha uma melhor visão de como são executados os programas em Linux, bem como se dá o processo de inicialização do kernel.

6 GERENCIAMENTO DE USUÁRIOS

6.1

COMENTÁRIOS INICIAIS

Linux, como qualquer Unix, é um sistema multiusuário. Isso implica que podem existir vários usuários para uma mesma estação, como ilustra a Figura 6.1. Quando isso acontece, uma preocupação para os administradores dessa estação é o gerenciamento dos recursos de cada usuário em particular. Afinal, como garantir uma configuração individualizada de acesso a essa estação? Outra questão importante é a de como garantir a privacidade dos dados de cada usuário.

Figura 6.1: Sistema Multiusuário

140

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

Em sistemas monousuários, fazer esse gerenciamento é uma tarefa extremamente complicada. Um usuário de um computador com Windows 98, por exemplo, pode ter seus documentos alterados ou apagados sem dificuldade alguma por qualquer pessoa que tenha acesso ao computador. A menos, é claro, que se esteja utilizando programas comerciais de terceiros com essa finalidade. Em sistemas Unix, a solução encontrada para esse tipo de problema foi o uso de contas de usuários. Essa filosofia permitem que vários usuários acessem a mesma máquina, inclusive ao mesmo tempo em ambiente de rede, sem interferir diretamente no ambiente de outro usuário. O objetivo deste capítulo é, portanto, definir o que é uma “conta” e apresentar os principais procedimentos e conceitos ligados à administração de usuários em Linux.

6.2

CONTAS DE USUÁRIOS

Uma conta pode ser vista como uma entidade a nível do sistema operacional que armazena informações do tipo: • nome do usuário; • identificador do usuário no sistema; • grupo (ou equipe) do usuário; • diretório pessoal do usuário (onde ele armazena suas informações); • interpretador de comandos que o usuário utiliza; • credenciais ou senhas do usuário; • permissões do usuário. Essas informações vão indicar ao sistema operacional como o usuário deve ser tratado durante o uso da estação. Obviamente, cada sistema operacional irá tratar esses dados de uma forma particular. Ainda: alguns sistemas operacionais (como o Linux) irão permitir que esses dados possam ser armazenados e obtidos de diversas maneiras. Assim, uma conta é a maneira com a qual o usuário é reconhecido pelo sistema. Em um banco, por exemplo, o cliente é identificado pelo número de sua conta corrente (seu identificador no sistema) e sua senha (sua credencial no sistema). Em um sistema multiusuário, é óbvio que uma estratégia parecida tem que ser adotada. Em Unix, o usuário é identificado pelos seguintes dados: Username ou Login: armazena o nome associado ao usuário no sistema. Apesar de não haver limites a nível de sistema operacional para isso, geralmente o login possui no máximo oito caracteres e é escrito todo em minúsculo.

Gerenciamento de Usuários

141

Senha (Password): a credencial usada pelo usuário para poder utilizar o sistema. Existem várias formas de se armazenar a senha do usuário e mesmo a possibilidade de utilizar senhas não-textuais. ID ou UID (User Identification): um número de identicação exclusivo associado ao usuário. A nível de implementação o sistema operacional associa ao login o respectivo UID. Os arquivos e processos do usuários são, então, identificados por esse UID. Esse número, na maioria das implementações, vai de 0 a 65634. O arquivo include/linux/highuid.h, parte do código de versões mais recentes do kernel utiliza a definição “#define DEFAULT_OVERFLOWUID 65534”, considerando portanto que qualquer UID acima desse valor é disponível apenas em sistemas com suporte a UIDs de 32 bits (highuid). Ou seja, em versões mais recentes do kernel e nos sistemas de arquivos atuais, é possível utilizar 232 UIDs distintos (0 a 4294967295). Veja detalhes no arquivo Documentation/highuid.txt da documentação do kernel (geralmente disponível no pacote kernel-doc). GID (Group Identification): grupo ao qual o usuário pertence. Em Unix, o usuário pode pertencer a vários grupos. Nesse caso o GID refere-se a seu grupo nativo. Um grupo é basicamente um conjunto de usuários. Geralmente ele é criado quando se deseja que vários usuários tenham permissão restrita a arquivos em comum. Dados do Usuário: a maioria dos sistemas de armazenamento dos dados do usuários em Unix possuem um campo denominado GECOS (General Eletric Comprehensive Operating System field). Esse nome se dá por razões históricas. Esse campo é utilizado para relatórios de informações do usuários (ex: resposta ao comando finger). Em geral, contém o nome completo do usuário, mas não se limita a isso, podendo armazenar número de telefone, endereço, etc. Diretório Pessoal: informa a localização do diretório pessoal do usuário, onde são armazenados seus arquivos e configurações individuais. Geralmente é um subdiretório do diretório /home. Interpretador de Comandos (Shell): informa ao sistema operacional qual o interpretador de comandos do usuário. Um interpretador de comandos é um programa que recebe comandos do usuário e executa-os internamente ou repassa-os ao sistema operacional ou a outros aplicativos instalados.

6.3

O ARQUIVO /ETC/PASSWD

A maioria dos sistemas Unix armazena os dados do usuário no arquivo /etc/passwd. A Figura 6.2 mostra uma linha desse arquivo. Pode ser verificado, nessa figura, que os dados do usuário são separados por ‘:’.

142

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

jpsilva:x:1111:100:Joao Pedro da Silva, , , ,:/home/jpsilva:/bin/bash Figura 6.2: Trecho do arquivo /etc/passwd

O primeiro campo do arquivo /etc/passwd é o login do usuário. Esse login está associado diretamente à sua caixa postal eletrônica. Considerando-se, por exemplo, que a estação de trabalho possuidora do arquivo apresentado na Figura 6.2 esteja ligada à internet, tenha por nome host.domain.com e seja servidora de e-mail, então é de se esperar que o usuário jpsilva possua uma conta de e-mail dada por jpsilva@host.domain.com ou por jpsilva@domain.com, dependendo da configuração utilizada na máquina. Essa ligação do login ao e-mail chama a atenção do administrador e do próprio usuário para a escolha de logins significativos. Assim, geralmente o login é construído a partir do nome do usuário. Devem ser evitados apelidos ou termos que criem constrangimento quando o usuário, por exemplo, for enviar um currículo ou um documento da empresa. Recomenda-se que o login tenha no máximo oito caracteres e seja composto apenas de letras minúsculas, principalmente para usuários que terão acesso direto à máquina. Caso o usuário vá usar apenas os serviços de e-mail da máquina, a restrição de tamanho pode ser afrouxada. A maioria das distribuições Linux permitem logins com até 32 caracteres e até mesmo o uso de caracteres especiais. Caso um usuário insista em ter uma conta de e-mail com mais de oito caracteres, a melhor solução é usar apelidos de sistema (aliases). Assim o usuário jsilva poderia ter uma conta de e-mail jose.silva adicionando-se ao arquivo /etc/aliases uma linha com o texto jose.silva: jsilva. Maiores informações sobre o arquivo /etc/aliases e serviços de e-mail serão vistos em (UCHÔA, 2008). O segundo campo do arquivo /etc/passwd é a senha do usuário. Apesar do que se diz comumente, a senha do usuário não é criptografada, e sim codificada (hashed). O algoritmo utilizado pelo Linux para codificar as senhas é um algoritmo de hash, implementado na função crypt( )1 . Esse algoritmo, em geral, implementa uma modificação do algoritmo DES ou o algoritmo MD5. Um apresentação detalhada de algoritmos hash pode ser encontrada em (SCHNEIER, 1996). Uma visão mais sintética pode ser encontrada em (UCHÔA, 2005). A Figura 6.3 ilustra o processo de codificação. A vantagem desse processo é que isso praticamente inviabiliza qualquer tentativa de descriptografar a senha de qualquer usuário. Durante o processo de codificação, se utiliza uma seqüência de caracteres aleatória para aumentar a segurança do processo. Essa seqüência de caracteres é geralmente chamada de “sal”, pois melhora (“tempera”) o processo de codificação das senhas. A Figura 6.4 apresenta uma comparação entre duas senhas codificadas por DES e MD5. 1 Para

maiores detalhes sobre a função crypt( ):

man 3 crypt.

Gerenciamento de Usuários

143

Sal Senha Codificada

Algoritmo de Hash Senha

Figura 6.3: Codificação de Senhas em Linux

Sal

Senha Codificada

DES: KGNrZT0S1D7UE MD5: $1$XUxvSe6g$TnD07sHt69Q6NAv5kdbAv. Tag MD5

Sal

Senha Codificada

Figura 6.4: Codificação de Senhas Usando DES e MD5

É possível verificar na Figura 6.4, que no DES a senha é armazenada com 13 caracteres, sendo que os dois primeiro representam o “sal” e o restante a senha codificada. Já no MD5, a senha ocupa 34 caracteres e sempre inícia com “$1$”. Os oito caracteres entre o segundo e o terceiro “$” armazenam o sal utilizado na codificação e os 22 caracteres restantes são usados para a senha codificada. Existem vários aplicativos para trocar a senha, mas o mais usado é o comando passwd. Chamado em sua forma tradicional, sem nenhuma opção, ele irá permitir a troca da senha do usuário que invocou o comando. Para isso, ele pedirá a senha atual do usuário. Caso a senha confira, ele pedirá que o usuário digite duas vezes a senha pretendida. Ele só alterará a senha, caso a senha pretendida seja digitada da mesma forma nas duas tentativas. Além disso, é possível configurar o comando passwd para verificar se o usuário não está escolhendo uma senha demasiado fraca. Ele pode checar senhas demasiadamente curtas ou de fácil descoberta por terceiros. Para verificar sobre o que caracteriza uma boa senha, verifique a Seção 6.4. Para maiores detalhes de configuração do comando passwd, verifique as Seção 6.13 e Seção 6.14. Uma forma de uso do comando passwd é mostrada na Figura 6.5, que permite ao administrador do sistema (o usuário root) verificar se uma dada conta possui senha e qual o tipo de codificação usado. $ passwd -S jsilva Password set, MD5 crypt. Figura 6.5: Exemplo de uso Comando passwd

144

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

O processo de decodificação da senha, apresentado na Figura 6.6 consiste basicamente em: 1) obter a senha do usuário; 2) codificar a senha do usuário usando o “sal” armazenado no arquivo de senhas; 3) comparar a senha codificada nesse processo com a que está armazenada no arquivo de senhas. Se essas senhas conferem, o usuário é autenticado pelo sistema. /etc/passwd ou /etc/shadow

/etc/passwd ou /etc/shadow Senha Armazenada

Sal Senha Codificada

Algoritmo de Hash

Comparação

Senha Codificada

Senha fornecida pelo usuário

Figura 6.6: Decodificação de Senhas em Linux

O terceiro e o quarto campos do arquivo /etc/passwd são, respectivamente, o UID (número de usuário – User ID) e o GID (número de grupo – Group ID). São usados, principalmente, para identificar o usuário no sistema e controlar as permissões individuais e grupais desse usuário. O quinto campo do /etc/passwd é o campo GECOS, comentado anteriormente na Seção 6.2. Em várias situações, contém apenas o nome do usuário. Quando contém outras informações, essas entradas são separadas por vírgulas. Apesar de poder armazenar qualquer coisa, o aplicativo finger espera que as informações do usuário estejam na seguinte ordem: • nome completo; • localização do escritório; • telefone do escritório; • número de telefone residencial. A Figura 6.7 mostra um usuário com o campo GECOS completo (Figura 6.7.a) e a execução do comando finger para esse usuário (Figura 6.7.b), confirmando a informação anterior. Os dois últimos campos informam, respectivamente, o diretório pessoal e o interpretador de comandos do usuário. Em geral, o diretório pessoal encontra-se em algum ponto na ár-

Gerenciamento de Usuários

145

aARL:x:1111:1111:Aluno ARL,DCC - 8,1123,2811-1111:/home/aARL:/bin/bash (a) Trecho do Arquivo /etc/passwd

$ finger aARL Login: aARL Directory: /home/aARL Office: DCC - 8, x1123 Never logged in. No mail. No Plan.

Name: Aluno ARL Shell: /bin/bash Home Phone: 2811-1111

(b) Execução do comando finger

Figura 6.7: Uso do Campo GECOS pelo finger

vore do /home. Os interpretadores de comandos mais utilizados são o bash (/bin/bash) e o tcsh (/bin/tcsh). Para maiores detalhes sobre esses interpretadores, ver (SCHNEIDER, 2002).

6.4

ESCOLHA DE SENHAS

Uma grande preocupação que um administrador de sistemas deve ter para com seus usuários é quanto a forma que esses escolhem suas senhas. Uma senha má escolhida por um usuário pode facilitar processos de invasão, dado que o cracker poderá utilizar a conta desse usuário para obter maiores informações sobre o sistema. Assim, é imprescindível que o administrador oriente os usuários em um bom processo de escolha de senhas. Uma boa senha é aquela que o usuário consegue se lembrar com facilidade, mas que nenhuma outra pessoa consiga descobrir. Assim, devem ser evitados, a qualquer custo o uso de datas significativas para o usuário, números de contas, nomes e sobrenomes de pessoas próximas, entre outros. Além disso, para dificultar o processo de alguém tentar descobrir a senha, é importante que a senha tenha ao menos dois dos seguintes itens: • mistura de letras maiúsculas e minúsculas; • uso de caracteres especiais (como espaço, ‘@’, ‘%’, ‘#’, etc.); • uso de numerais.

A mistura desses itens dificulta imensamente qualquer tentativa de quebra de senha e permite a construção de senhas fáceis de se lembrar. A importância de uma senha de fácil memorização é evitar o imenso perigo de se anotar as senhas em papéis, agendas, etc.

146

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

Nesse sentido, uma das grandes vantagens do MD5 sobre o DES na codificação de senhas é que ele permite, a princípio, que o usuário escolha uma senha de qualquer tamanho. O uso do DES na codificação das senhas limita o tamanho dessa senha a oito caracteres. Dessa forma, o uso do MD5 deve ser preferido, por permitir senhas mais fáceis de memorizar e com maior dificuldade para a quebra das mesmas. Uma regra utilizada e sugerida pelos autores deste texto é a utilização de frases sem sentido aparente (nonsense), mas que seja de fácil memorização pelo usuário. Essa estratégia também é defendida em (NEMETH et al., 2001). Um exemplo de frase nonsense que inspira uma boa senha é: “O macaco do Tibet no telhado”. Troca-se algumas letras por caracteres especiais ou números (ex.: ‘a’ por ‘@’, ‘o’ por ‘0’, etc.) e tem-se uma frase que poderia ser excelente senha, se já não tivesse sido escrita nesta apostila: “O mac@c0 do Tibet no t&lhad0”. Caso se utilize DES, estando limitado a oito caractes, pode-se tentar resumir a frase imaginada, usando partes da frase nonsense. Assim, a frase acima poderia gerar as seguintes senhas, por exemplo: “Om@nTnt&” e “m@n0Tnt&”. São senhas que, se não estivessem aqui escritas, poderiam ser consideradas perfeitas. A melhor regra para se escolher uma boa senha portanto é: usar a imaginação para construir senhas inimagináveis por terceiros.

6.5

SENHAS SOMBREADAS

Considerando-se que as senhas não são criptografadas, existem quatro formas de um invasor descobrir a senha de um dado usuário: 1. obter a senha do usuário no tráfego da rede, através de técnicas de sniffing; 2. obter a senha através de tentativas simples baseadas em informações do usuário; 3. obter a senha através de um ataque de dicionário; 4. usar a força bruta, fazendo várias tentativas – essa alternativa é improvável, dado o grande número de combinações possíveis, mas é possível. A obtenção de senhas através do tráfego na rede pode ser evitada através do uso de conexões criptografadas. Maiores informações sobre sniffing, bem como estratégias para evitar problemas causados por ele poderão ser encontradas em (UCHÔA, 2005). Neste texto, não haverá preocupação quanto à esse aspecto de proteção das senhas.

Gerenciamento de Usuários

147

O invasor também pode tentar logar-se como um usuário utilizando senhas potencialmente inseguras. Assim, para um usuário chamado João da Silva Pereira, nascido em 22/11/1960, com RG 353.223, esse invasor tentaria, entre outras, as seguintes senhas: “jsilva”, “jpereira”, “silva”, “pereira”, “22-11-60”, “22.11.1960”, “353223”. Daí a importância de uma boa escolha da senha, como já comentado na Seção 6.4. O “ataque de dicionário”, por sua vez, consiste em comparar palavras de um dicionário com a senha do usuário. Para isso, o invasor utiliza um programa que pega palavras em um dicionário de palavras2 , codifica cada uma das palavras utilizando vários tipos possíveis de “sal”3 e compara com a senha armazenada no arquivo de senhas. Assim, esse invasor precisa, em um momento inicial desse processo, conseguir as senhas dos usuários pretendidos para o ataque de dicionário. Inicialmente o ataque de dicionário não era um problema grave, devido ao limitado poder computacional dos equipamentos. Entretanto, isso hoje é um sério risco à segurança dos sistemas. Um primeira solução seria negar a leitura do arquivo /etc/passwd por outros usuários do sistema que não o administrador. O problema é que, como inicialmente ataque de dicionário não era enxergado como risco sério, o arquivo /etc/passwd precisa ter permissão de leitura para todos os usuários do sistema. Caso essa permissão seja retirada, vários serviços, como o finger ou o e-mail, deixarão de funcionar em suas configurações padrões. A alternativa encontrada para esse problema foi a de manter o arquivo /etc/passwd apenas para os dados de acesso e esconder a senha. Assim, em sistemas mais recentes, geralmente se utiliza o recurso de senhas “sombreadas” (shadowed passwords). Nesse caso a senha é armazenada em um arquivo à parte, geralmente o /etc/shadow. Esse arquivo só pode ser lido pelo usuário root, que detém os poderes administrativos sobre o sistema4 . Assim, o campo destinado à senha no arquivo /etc/passwd é marcado com um “x”, como ilustrado nas Figura 6.2 e Figura 6.7. Essa senha é mantida no arquivo /etc/shadow, apresentado na Figura 6.8. Como o arquivo /etc/passwd, esse arquivo possui campos separados por “:”. jsilva:$1$IeC1G.D7$mC/h(g7TYHh12jGÇ8VáDU0:11850:0:99999:7::: Figura 6.8:

Trecho do Arquivo /etc/shadow

O primeiro campo é o login do usuário, tal qual como no arquivo /etc/passwd. Na realidade essa é a única ligação entre os dois arquivos. O segundo campo é a senha 2 Para

ser mais exato, o termo mais correto seria “lista de palavras” e não “dicionário de palavras”. Seção 6.3 para maiores detalhes sobre “sal” e o processo de codificação de senhas utilizado no Linux. 4 Maiores detalhes sobre o usuário root podem ser vistas na Seção 6.6 3 Ver

148

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

codificada. No caso da Figura 6.8, a senha foi codificada usando MD5. Maiores detalhes sobre o processo de codificação da senha podem ser obtidos na Seção 6.3. O terceiro campo é usado para calcular o dia em que a senha foi alterada pela última vez. Para ser mais exato, ele informa quantos dias se passaram entre 1o de Janeiro de 1970 e a data da última alteração da senha. Essa é, na verdade, uma forma padrão de se indicar datas absolutas em UNIX. No caso da Figura 6.8, o usuário alterou a senha pela última vez em 12 de Junho de 2002. O quarto campo é, sob o ponto de vista da segurança, praticamente inútil: ele indica o número mínimo de dias para que um usuário altere sua senha. Isso pode ser altamente perigoso, caso o usuário tenha sua senha alterada por terceiros. Esse campo só faz sentido em contas com as quais não se quer mudança de senha antes de um dado prazo, ex.: contas administrativas e de sistemas. Caso contrário, deve ser deixado em branco ou com o valor ‘0’. O quinto campo é exatamente o inverso do anterior: indica o número máximo de dias que o usuário pode ficar sem alterar a senha. Apesar de que as regras para uma boa segurança apontam para a necessidade de se trocar as senhas após um dado período, essa técnica não é, em geral, recomendada. Isso porque obrigar o usuário a alterar sua senha constantemente pode forçá-lo a reaproveitar senhas antigas ou anotar a nova senha e isso retiraria toda a vantagem do processo. O uso de “99999” nesse campo indica que as senhas nunca “caducam”. Ainda assim, caso o administrador resolva fazer uso desse recurso de “caducidade de senhas”, ele irá fazer uso do sexto campo. Esse campo indica quantos dias antes do prazo fatal para a alteração da senha o usuário deva começar a ser avisado pelo programa de login. Outra alternativa é utilizar o sétimo campo. Esse campo informa quantos dias após a expiração da senha o sistema deva considerar a conta desabilitada. Caso se pretenda utilizar o quinto campo para desabilitar um usuário, esse uso é incorreto. O oitavo campo indica justamente quando o usuário deve ser desabilitado. Da mesma forma que no terceiro campo, ele informa o número de dias entre 1o de Janeiro de 1970 e a data da desabilitação da conta. Para contas normais, esse campo é deixado em branco. O nono campo existe, mas ainda não é usado. É reservado para usos futuros. Para simplificar o processo de alteração das informações do terceiro ao oitavo campo do arquivo /etc/shadow, geralmente se faz uso do comando chage. Quando chamado com a opção ‘-l’, informa os dados do usuário. A Figura 6.9 mostra a execução do comando chage -l jsilva.

Gerenciamento de Usuários

149

$ chage -l jsilva Minimum: 0 Maximum: 99999 Warning: 7 Inactive: -1 Last Change: Password Expires: Password Inactive: Account Expires:

Jun 12, 2002 Never Never Never

Figura 6.9: Execução do Comando chage -l jsilva

O comando chage pode ser usado de forma interativa, quando chamado na forma chage jsilva. Nesse caso, ele irá pedir que o administrador informe os novos valores dos campos ou confirme os anteriores, como mostra a Figura 6.10. Entretanto, ele pode ser chamado de forma não interativa. Por exemplo, chage -E 2003-08-01 jsilva faria com que a conta do usuário jsilva expirasse em 1o de Agosto de 2003. Para maiores informações, consulte a página de manual desse comando: man chage. $ chage jsilva Changing the aging information for jsilva Enter the new value, or press return for the default Minimum Password Age [0]: Maximum Password Age [99999]: Last Password Change (YYYY-MM-DD) [2002-06-12]: Password Expiration Warning [7]: Password Inactive [-1]: Account Expiration Date (YYYY-MM-DD) [1969-12-31]: Figura 6.10: Execução do Comando chage jsilva

6.6

TIPOS DE CONTAS

Basicamente, existem três tipos de contas: a conta do usuário comum, que utiliza o sistema e suas ferramentas, contas de serviços (ou pseudo-usuários) e a conta de superusuário ou conta de root. Dentre os tipos de contas, a conta de root é a mais importante,

150

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

dado que é essencial para o funcionamento do sistema. Algumas configurações só são possíveis se efetuadas através dessa conta. Dado seu extremo poder, a conta de root só deve ser usada em configurações e manutenções no sistema. Dessa maneira, seu uso deve ser o menor possível. Para uso comum, devem ser criadas contas de usuário. Essas contas possuem permissão restrita. Em geral, só conseguem alterar dados em seu próprio diretório ou no diretório tmp. Dessa maneira, se esse usuário executa um programa com vírus, por exemplo, esse vírus não conseguirá infectar arquivos de propriedade de outro usuário. Como os arquivos de sistema pertencem, em geral, ao usuário root, eles permanecem intocáveis. Além disso, o uso de contas de usuários diminui o risco desastres, como apagar todo um diretório importante por acaso. Evita também que qualquer usuário do sistema faça alterações na configuração estabelecida para a estação. Em resumo: a conta de root jamais deve ser usada para tarefas comuns, como edição de textos, navegar na internet, etc. O administrador deve criar contas comuns (inclusive para si mesmo) para as tarefas cotidianas, deixando a conta de root unicamente para tarefas de gerenciamento, manutenção e configuração do sistema. 6.6.1

Pseudo-Usuários

Para impor mais segurança ao sistema, vários servidores não são executados com poderes de root. Assim, para diminuir a permissão desses servidores, foram criadas contas específicas para eles: os pseudo-usuários. Algumas dessas contas são essenciais ao sistema, outras existem por razões históricas e podem ser removidas sem problemas. A Tabela 6.1 apresenta algumas contas comuns de pseudo-usuários e sua utilidade. Note que o UID e mesma a existência dessas contas varia de distribuição para distribuição. Em geral, entretanto, essas contas utilizam UID inferior a 500. Dessa maneira, considera-se que contas com UID inferior a 500 são contas de sistema, não devendo-se usar um valor inferior a 500 para contas de usuários.

6.7

GRUPOS DE USUÁRIOS

Suponha a seguinte situação: uma empresa possui três departamentos. Cada departamento possui arquivos que precisam ser compartilhados entre os seus funcionários, mas que não podem ser acessados por pessoas externas ao departamento em questão. A solução natural de qualquer sistema UNIX é o uso de grupos de usuários. Nesse caso seria criado três grupos (ex.: depto1, depto2 e depto3) e os funcionários pertenceriam ao grupo

Gerenciamento de Usuários

151

Tabela 6.1: Alguns Pseudo-Usuários Comuns

Usuário

Finalidade

bin

Em alguns sistemas, essa conta é proprietária dos arquivos e diretórios dos aplicativos. Em sistemas mais modernos, utiliza-se diretamente a conta root Conta utilizada para processos e arquivos em geral que não precisam ser de posse de root Conta administrativa, é proprietária dos arquivos de contabilidade de uso do sistema Conta para serviços de impressão Conta para serviços de e-mail Conta para serviços de news Conta utilizada pelos serviços de NFS Conta utilizada pelo serviço de shutdown Conta proprietária de jogos e aplicativos similares

daemon adm lp mail news nobody shutdown games

ligado ao seu departamento específico. Em seguida, bastaria fazer com que os arquivos tivessem permissões adequadas às necessidades. Cada usuário UNIX pertence ao menos a um grupo, associado a ele no momento do login. Mas é possível que um mesmo usuário pertença a vários grupos. Em alguns casos, é criado um grupo distinto para cada usuário. Isso é interessante em ambientes onde a privacidade deva ser mantida ao máximo. Em outros casos, como ambientes acadêmicos, colocam-se usuários com um mesmo perfil (ex.: alunos de uma mesma turma) em um único grupo. O número do grupo (GID) padrão do usuário é definido pelo quarto campo da informação do usuário no arquivo /etc/passwd (ver Seção 6.3). As informações completas do grupo são apresentadas no arquivo /etc/group. A Figura 6.11 apresenta um trecho desse arquivo.

whell:x:10:root daemon:x:2:root,bin,daemon users:x:100:tarzan,batman monitor:x:101:jsilva Figura 6.11: Arquivo /etc/group

152

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

Pode ser verificado na Figura 6.11 que cada entrada no arquivo /etc/group é composto de quatro campos. O primeiro campo é o nome do grupo. Esse nome deve ser criado de acordo com a mesma filosofia de escolha do login do usuário. O segundo campo é a senha do grupo, raramente utilizada com finalidades práticas. O terceiro campo é o GID do grupo. O quarto e último campo são os usuários extras do grupo. Assim, o usuário jsilva pertence aos grupos users e monitor, de acordo com a Figura 6.2 e a Figura 6.11. Nesse caso o grupo users é o grupo associado a esse usuário no momento do login, sendo que todos os arquivos e processos criados por ele são criados como pertencendo a esse grupo. Ou seja: o grupo padrão do usuário é aquele informado no arquivo /etc/passwd. Caso o usuário jsilva queira criar arquivos com as permissões do grupo monitor, ele deverá usar o comando newgrp monitor. Se ele quiser informações sobre qual o grupo associado a ele no momento, bem como os grupos a que ele pertence, ele poderá usar o comando id. Esses dois comandos são ilustrados na Figura 6.12.

$ id uid=1111(jsilva) gid=100(users) grupos=100(users),101(monitor) $ newgrp monitor $ id uid=1111(jsilva) gid=101(monitor) grupos=100(users),101(monitor) Figura 6.12: Usos dos Comandos id e newgrp

Obviamente, para acessar um arquivo com a permissão de um dado grupo, o usuário não precisar usar o comando newgroup. Dessa maneira, o usuário jsilva poderia editar qualquer arquivo que tivesse permissão de escrita para o grupo users ou o grupo monitor. Esse comando só é necessário para a criação de arquivos associados a outro grupo que não o associado pelo arquivo /etc/passwd. Para retornar ao grupo anterior, basta usar o comando exit. Maiores informações sobre permissões de arquivos podem ser obtidas na Seção 4.8. Da mesma forma que ocorre com o UID, grupos com GID inferiores a 500 são considerados grupos de sistemas. Alguns dos usuários apresentados na Tabela 6.1 possuem grupos equivalentes. Um dos grupos mais importantes é o wheel, geralmente composto pelo root e outros usuários administradores do sistema. Dependendo da configuração do sistema, somente usuários desse grupo podem se tornar root com a execução do comando su.

Gerenciamento de Usuários

6.8

153

VARIÁVEIS DE AMBIENTE

Uma variável de ambiente é um valor armazenado em memória e que pode ser utilizada por qualquer aplicação. Em ambientes UNIX, algumas variáveis de ambiente são usadas com muita freqüência. Exemplo dessas variáveis são listadas na Tabela 6.2. Tabela 6.2: Variáveis de Ambiente

Variável

Utilidade

PATH

configura o caminho padrão onde são procurados os comandos, externos ao shell, executados pelo usuário informa qual o servidor gráfico utilizado informa o login do usuário configura o editor padrão configura o prompt de comando no bash informa o diretório corrente informa o shell utilizado informa a língua padrão do usuário informa o diretório pessoal do usuário informa o arquivo de e-mail do usuário informa qual o terminal gráfico utilizado

DISPLAY USER EDITOR PS1 PWD SHELL LANG HOME MAIL TERM

As variáveis apresentadas na Tabela 6.2 são extremamente úteis em construção de scripts. Algumas delas, entretanto, devem ser configuradas adequadamente para propiciar um melhor ambiente ao usuário. Algumas dessas configurações (como o LANG) são configurados em arquivos no diretório /etc/sysconfig. Outras, como o PATH, são configuradas em arquivos específicos no diretório /etc/. Essa configuração depende do shell padrão do usuário. Usando bash a configuração de uma variável de ambiente pode ser feita de duas formas. A primeira forma é ilustrada a seguir: # VARIAVEL=meuvalor # export VARIAVEL A primeira linha cria, no terminal, uma variável de nome VARIAVEL com o valor atribuído meuvalor. Essa variável pode ser usada por esse terminal enquanto a sessão estiver disponível. Para fazer a variável ser válida em todas as sessões, o que é feito com o comando export. O comando interno export é responsável por exportar uma variável,

154

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

no bash a outras sessões. Isso poderia ser feito em uma única linha, envolvendo atribuição e exportação, da seguinte maneira: # export VARIAVEL=meuvalor Caso esteja-se utilizando csh ou tcsh, a configuração de variáveis é feita com os comandos set e setenv. O comando set cria a variável localmente naquele terminal e setenv cria uma variável global. Os dois comandos possuem sintaxes diferentes, como ilustrados a seguir: $ setenv VARIAVEL meuvalor # set VARIAVEL=meuvalor Quando um usuário loga-se no sistema ou inicia um novo terminal, alguns arquivos costumam ser lidos para configurar variáveis de ambiente mais utilizadas. No csh, essas variáveis são lidas a partir do arquivo geral /etc/csh.cshrc e /etc/csh.login. No caso do bash, essa configuração é feita nos arquivos /etc/profile e /etc/bashrc. Em geral, o arquivo /etc/profile é lido no login do usuário e o /etc/bashrc sempre que um novo terminal usando bash é iniciado. Dependendo do gerenciador de janelas, entretanto, esse comportamento pode não ser o esperado. Independente disso, o shell lerá os arquivos .bashrc no diretório do usuário, ou o .cshrc, no caso do tcsh. Observe que, na maioria dos casos, a distribuição usada pelo usuário deverá criar arquivos /etc/profile e outros com configurações padrões. Recomenda-se que o administrador não altere as configurações aí disponibilizadas e sim faça suas alterações ao final desse arquivo. O mesmo vale para os outros arquivos de configuração de variáveis já comentados nesta seção. Além das variáveis de ambiente, é possível mudar o comportamento de comandos existentes, ou mesmo adicionar novos comandos. Isso é feito com o comando alias, exemplificado a seguir: # alias mv=’mv -iv’ Esse comando fará que quando executado em sua forma normal, o comando mv funcione automaticamente como se a ele tivesse sido passada as opções -iv. A geração de novos comandos é feita da mesma forma. Assim “alias move=mv” faria com que o usuário, ao chamar move, estivesse utilizando o mv.

Gerenciamento de Usuários

155

Para remover um alias, basta usar o comando unalias comando. Já a remoção de uma variável é feita atribuindo a ela nenhum valor, como por exemplo: export VARIAVEL=. Como essas variáveis e os alias utilizados dependem do shell em uso, recomenda-se a consulta à documentação desses interpretadores para uma configuração adequada.

6.9

USO DE QUOTAS

Em ambientes com recursos limitados de hardware, pode ser importante limitar os recursos a que o usuário tem acesso. Mesmo quando a oferta de recursos é satisfatória, isso também pode ser necessário. Em se tratando de espaço em disco, essa é uma verdade histórica. Afinal, o administrador nunca imaginava que precisava tanto de um disco de 40 Mb, antes de instalá-lo e começar a “devorar” cada mínimo espaço livre do mesmo. Dessa maneira, apesar da desrecomendação feita em (NEMETH et al., 2001), os autores desse texto acreditam que o uso de quotas de discos pode ajudar a manter os usuários menos “vorazes” que o normal e indicam seu uso em qualquer ambiente com mais de vinte usuários. Para que se configure quotas para usuários ou grupos, é importante que o sistema de arquivos associado esteja montado com as opções de quota habilitadas. Maiores informações sobre isso podem ser encontradas na Seção 4.5. Uma vez que o sistema de arquivos esteja configurado adequadamente, a atribuição de quotas a um usuário ou a um grupo pode ser feito através do comando edquota. Caso pretenda-se configurar a quota de um único usuário, basta chamar o comando seguido do nome do usuário. Nesse caso, o edquota irá abrir o editor padrão do usuário, configurado na variável de ambiente EDITOR, com um arquivo temporário de configuração de quota. Salvando as alterações, tem-se que as novas configurações são postas imediatamente em prática. A Figura 6.13 apresenta, a título de exemplo, a edição de quota do usuário neworder.

Disk quotas for user neworder (uid 1234): Filesystem blocks soft hard inodes /dev/sda3 131536 150000 175000 3641 /dev/sda5 35132 100000 120000 2416

soft 0 0

Figura 6.13: Editando a quota de um usuário

hard 0 0

156

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

Na Figura 6.13, é possível perceber que a quota de um dado usuário é configurada em sete colunas. A primeira coluna, que não deve ser alterada, informa o sistema de arquivos onde a quota está sendo aplicada. A segunda coluna informa quanto em disco o usuário está atualmente usando em unidades de blocos, tipicamente 1Kb nas instalações comuns. Essa coluna pode ser utilizada para corrigir, por exemplo, incoerências no sistama de quota, evitando que o sistema informe uma quantidade maior de espaço do que a realmente utilizada pelo usuário. A terceira coluna informa quanto um usuário pode utilizar de espaço no sistema de arquivos especificado. No exemplo da Figura 6.13, o usuário neworder pode utilizar 150Mb em /dev/sda3 e 100Mb em /dev/sda5. Caso tenha sido estabelecido um período de “graça”, o usuário ainda conseguirá autenticar-se no sistema5 . Nesse caso, a quota do usuário não poderá exceder, de forma alguma, o valor especificado na quarta coluna. É recomendável, inclusive, que esse valor “hard” seja maior que o especificado na terceira coluna para permitir, por exemplo, que o usuário continue recebendo seus e-mails mesmo usando mais recursos que o especificado na quota “soft”. As três últimas colunas tem funcionamento idêntico às segunda, terceira e quarta coluna, só que se aplicam não ao espaço utilizado e sim ao número de arquivos que o usuário pode possuir. Em casos normais, a configuração dessas colunas deve ser evitada, devendo o administrador não alterar os valores informados (“0” significa quota infinita). O período de graça é configurando invocando-se o comando edquota -t. Nesse caso, o edquota irá abrir o editor padrão com o arquivo temporário mostrado na Figura 6.14. Como deixado claro na figura, o período pode ser especificado em dias, horas, minutos ou mesmo segundos. Recomenda-se que a escolha desse período varie entre três e quinze dias, mas isso dependerá do contexto onde a quota está sendo aplicada. Grace period before enforcing soft limits for users: Time units may be: days, hours, minutes, or seconds Filesystem Block grace period Inode grace period /dev/sda3 7days 7days /dev/sda5 7days 7days

Figura 6.14: Editando a quota de um usuário 5É

possível que o usuário não consiga autenticar-se em modo gráfico, pois durante a inicialização do ambiente gráfico, vários arquivos temporários são criados. Como a quota do usuário está estourada, ele não conseguirá fazer esse tipo de login. Entanto, se a “graça” não estiver expirada, ele conseguirár efetuar login em modo texto, incluíndo-se os remotos, como telnet ou SSH.

Gerenciamento de Usuários

157

Caso não se pretenda atribuir quota a um único usuário, mas sim ao grupo que ele pertence, deve-se invocar edquota -g nome_grupo. Nesse caso, o espaço ocupado pelo grupo é que será limitado, não importando se um usuário desse grupo irá ocupar mais espaço que um outro. Ou seja, essa opção não irá atribuir quota aos membros do grupo e sim ao grupo como um todo. Infelizmente o edquota não possui, ainda, opção para editar a quota individual dos membros de um grupo. Entretanto, apesar do comando edquota não possuir opção de atribuir automaticamente uma dada configuração de quota a membros de um grupo, é possível copiar com facilidade a configuração de quota de um usuário para outros. Para copiar a configuração de quota do usuário neworder para os usuários blondie, elastica e smashing, basta invocar o comando edquota -p neworder blondie elastica smashing. Dessa maneira, não é complicado confeccionar um programa ou um script que copie uma dada quota a todo os membros de um grupo de usuários. O gerenciamento das quotas pode ser feito com o uso do comando quota. Assim, caso o administrador invoque o comando quota neworder, obterá como resultado um relatório da situação de quota do usuário neworder em todos os sistemas de arquivo, mesmo aqueles sob NFS, em que a quota esteja habilitada. Outra ferramenta de gerenciamento extremamente útil é o comando repquota. Esse comando pode ser usado de duas formas. Na primeira forma, como em repquota /dev/sda3, irá obter um relatório completo, incluíndo todos os usuários e grupos com quota configurada, sobre a situação de quota no sistema de arquivos especificado. A segunda forma é invocá-lo da forma repquota -a que irá fazer isso para todos os sistemas de arquivo que tenham quota habilitada. Mais detalhes sobre quota podem ser encontrados em (MOURANI, 2001) e (DOOREN, 2002).

6.10

CRIANDO E ALTERANDO CONTAS DE USUÁRIOS

O processo de criação de uma conta de usuário em Linux é relativamente simples e pode ser resumido nos seguintes passos:

1. editar os arquivos /etc/passwd e /etc/shadow com as informações básicas do usuário; 2. se for necessário, criar um grupo em /etc/group para o usuário e colocar o usuário nos grupos adequados; 3. atribuir uma senha inicial para o usuário com o comando passwd login-do-usuario;

158

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

4. criar o diretório pessoal do usuário; 5. copiar arquivos padrões de configuração (ex.: .bashrc) para o diretório do usuário; 6. configurar adequadamente as permissões do diretório pessoal do usuário e os arquivos desse diretório; 7. se for o caso, configurar a quota do usuário usando o comando edquota login-do-usuario; 8. se for o caso, configurar os “apelidos de sistema” (aliases) do usuário no arquivo /etc/aliases. Sobre o passo 5, em geral se usa o diretório /etc/skel para manter e configurar arquivos que se pretenda copiar para o diretório pessoal de um usuário recém-criado. Existem vários programas que simplificam o processo de criação de um usuário, como por exemplo o useradd, que copiam automaticamente o conteúdo desse diretório para a pasta do usuário. O comando useradd6 é com certeza o mais interessante entre os programas disponíveis para a criação de usuários. Sua maior vantagem é obter todos os dados necessários à criação do usuário através de parâmetros. Isso facilita imensamente a criação de usuários em scripts. A Tabela 6.3 apresenta as principais opções desse comando e um exemplo de uso. Tabela 6.3: Opções do Comando useradd

Opção -c -d -e -g -G -s -u

Significado campo GECOS do usuário diretório pessoal do usuário data em que a conta irá expirar, no formato YYYY-MM-DD grupo padrão do usuário lista de outros grupos, separados por vírgula, ao que o usuário pertence shell do usuário UID do usuário

Exemplo de Uso: useradd -u 532 -g users nitewish

comando useradd também pode ser chamado como adduser. Na verdade, adduser é um link simbólico para useradd

Gerenciamento de Usuários

159

O comando equivalente para criação de grupos é o groupadd. Esse comando possui a sintaxe groupadd -g GID nome-do-grupo. Se a opção -g não for passada, o comando irá usar um GID maior que o de qualquer GID existente no arquivo /etc/group e que seja maior que 500. Caso se queira um GID menor que 500 sem informar o número do GID, deve-se usar a opção -r. Esses dois programas fazem parte do pacote shadow-utils, ao qual também pertence o comando chage, descrito na Seção 6.5. Um outro comando disponibilizado com o pacote shadow-utils é o usermod. Esse comando tem a finalidade de alterar os dados de um usuário já existente. Esse comando utiliza basicamente as mesmas opções do comando useradd. À essas opções, acrescentase o parâmetro ‘-l’, que permite alterar o login do usuário. Uma observação importante a fazer sobre o processo de criação de usuários é que, em ambientes onde o usuário precise ter contas em várias máquinas, com arquivos compartilhados por NFS, é importante fazer com que o GID o UID desse usuário seja o mesmo em todas as máquinas. Caso contrário, corre-se o risco dos arquivos desse usuário serem abertos por terceiros. Maiores informações sobre NFS serão vistas em (UCHÔA, 2008). Uma solução melhor para esse tipo de problema é utilizar um sistema de autenticação distribuído. Nesse sistema alternativo, as contas poderiam ser cadastradas em um único servidor e as estações ao invés de autenticar os usuários em seus próprios arquivos, autenticaria de acordo com as informações do servidor. Exemplos de estratégias para isso é o uso de NIS7 , LDAP8 ou Servidores SQL, que serão abordados em (UCHÔA, 2008). Para colocar esses servidores para autenticação em Linux, é necessário informar ao sistema a forma como ele deve autenticar um usuário. Isso é feito através do PAM (Pluggable Authentication Modules), abordado na Seção 6.13.

6.11

REMOÇÃO E DESABILITAÇÃO DE USUÁRIOS

Caso o administrador queira desabilitar o acesso de um dado usuário, sem excluir sua conta, uma forma bastante utilizada é editar o arquivo /etc/shadow e acrescentar um ‘!’ ou um ‘*’ à frente da senha do usuário. Na verdade o comando passwd -l usuario irá fazer exatamente isso9 . Uma outra opção é alterar o interpretador de comandos do usuário para um que invalide o acesso, como, por exemplo, /bin/false. Um problema, entretanto, que pode surgir é que, por default o servidor de e-mails sendmail não irá entregar e-mails para contas 7 NIS:

Network Information Services Lightweight Directory Access Protocol 9 A opção -l do comando passwd serve para desabilitar o acesso de um dado usuário. 8 LDAP:

160

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

cujo shell não esteja informado no arquivo /etc/shells. Uma solução é acrescentar /bin/false nesse arquivo. Caso o interesse seja realmente remover o usuário, então os passos a seguir podem servir de guia para o administrador: 1. remover qualquer referência ao usuário no arquivo /etc/aliases ou adicionar um endereço externo do usuário para reenvio; 2. remover qualquer processo pendente do usuário em sua tabela pessoal do cron – ver Seção 7.3.1 para maiores detalhes; 3. remover qualquer processo agendado pelo usuário via comando at – ver Seção 7.3.2 para maiores detalhes; 4. matar qualquer processo do usuário que ainda esteja rodando usando os comandos ps e kill – ver Capítulo 5 para maiores detalhes; 5. remover arquivos temporários do usuário nos diretórios /var/tmp /tmp; 6. remover qualquer referência ao usuário nos arquivos /etc/passwd, /etc/shadow e /etc/group; 7. remover o diretório pessoal do usuário; 8. remover o arquivo de e-mail do usuário, geralmente em /var/mail. Na maioria das vezes, os administradores apressados executam apenas os últimos três passos, mas em determinados ambientes os passos iniciais são importantes para manter a segurança do sistema. Além disso, é altamente recomendável que se faça backup do diretório pessoal do usuário e seu arquivo de e-mail, antes de apagá-lo, evitando surpresas indesejáveis, como o fato do usuário querer recuperar algum de seus arquivos. O tempo de armazenamento desse backup variará de um contexto para outro. A remoção das informações do usuário nos arquivos /etc/passwd, /etc/shadow e /etc/group pode ser feita com o comando userdel. Esse comando possui uma única opção: ‘-r’. Quando utilizado com essa opção, ele irá efetuar exatamente os três últimos passos da listagem anterior. Um grupo pode ser removido com a edição direta do arquivo /etc/group ou através do comando groupdel. Essa última opção é preferida, pois impedirá o administrador de remover um grupo que ainda possua usuários tendo esse grupo como padrão (o definido no arquivo /etc/passwd). Um passo extra a ser feito após a remoção de um usuário do sistema é verificar se não sobraram arquivos em outros diretórios que não o diretório pessoal. Se quota estiver

Gerenciamento de Usuários

161

habilitada, uma forma rápida de verificar se isso ocorre é utilizar o comando repquota -a. A Figura 6.15 mostra um exemplo disso. #474 tutora todez

----

12 157588 59712

0 180000 65000

0 185000 75000

1 791 2002

0 0 0

Figura 6.15: Execução do Comando repquota -a

Nesse caso, algum usuário de UID 474 foi removido do sistema, mas sobraram arquivos de sua propriedade. Para encontrar arquivos “sem dono”, uma opção mais demorada, mas altamente funcional é utilizar o comando find. Assim o comando find /home -nouser iria informar quais são os arquivos no diretório /home sem usuário associado no /etc/passwd para o ID do proprietário do arquivo. Outra opção seria utilizar find /home -user 474. A opção -user permite encontrar os arquivos de um dado usuário, podendo ser informado tanto seu UID, como seu login. À parte do que possa parecer, deve-se evitar ao máximo a reutilização de UIDs e GIDs de usuários e grupos removidos de um sistema. Isso evita confusão, caso arquivos precisem ser restaurados de backups. Em alguns formatos de backup, os proprietários dos arquivos são identificados pelo UID, ao invés do login.

6.12

TORNANDO-SE ROOT

Dependendo da configuração do sistema, qualquer usuário pode tornar-se root, bastando para isso executar o comando su. Se chamado sem nenhuma opção, ira pedir a senha de root ao usuário e, caso autenticado, iniciar um interpretador de comandos com poderes de administrador. Nesse caso, entretanto, as variáveis de ambiente (como o PATH10 ) serão as mesmas do usuário que invocou o comando. Caso isso não seja o pretendido, então deve-se invocar o comando su com a opção ‘-l’ ou apenas ‘-’. Esses parâmetros informam ao su para iniciar um interpretador de comandos tal qual se o usuário root tivesse efetuado um login naquele terminal. Caso se pretenda apenas executar um comando com os poderes de root, pode-se usar su -c. Nesse caso, o comando su irá pedir a senha de root e, se autenticado, irá rodar o programa especificado com poder de superusuário. Uma opção melhor para isso é 10 A

variável de ambiente PATH informa em quais diretórios o interpretador de comandos deve buscar executáveis chamados pelos usuário

162

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

usar o comando sudo. Esse comando permite, inclusive dividir o poder do superusuário, sem compartilhar a senha de root. O sudo recebe como parâmetro um comando a ser executado com poderes de root ou um usuário especial do sistema. Então o sudo checa o arquivo /etc/sudoers para: 1) verificar quem são as pessoas autorizadas a executar o sudo, 2) verificar com quais poderes essas pessoas podem com quais poderes podem executar comandos, 3) quais comandos autorizados e 4) em quais máquinas podem ser executados esses comandos. Se o comando invocado atende as permissões concedidas, então o sudo irá solicitar a senha do próprio usuário e executar o comando. Maiores informações sobre o sudo podem ser encontradas em (MILLER, 2002) e (UCHÔA, 2005).

6.13

PAM (PLUGGABLE AUTHENTICATION MODULES)

Originalmente a autenticação em sistemas Unix era apenas via comparação de senhas criptografadas no arquivo /etc/passwd. Qualquer programa que precisasse fazer uma autenticação, solicitava o login do usuário e sua senha, criptografava a senha e comparava o resultado com a armazenada naquele arquivo. Se fossem iguais, era garantido o acesso aos recursos oferecidos pelo programa. Caso contrário, o programa retornava erro de autenticação. Suponha agora, que o administrador queira fazer autenticação remota. Ou seja, a base de usuários não está mais na mesma máquina, mas sim em alguma outra máquina da rede, o chamado servidor de autenticação. O administrador seria obrigado então, por exemplo, a mudar o programa login para que ele também suportasse esse tipo de autenticação remota. Surgiu um novo algoritmo de criptografia, muito mais avançado, mais rápido, e o administrador quer usar esse novo algoritmo na autenticação de seus usuários. Novamente ele teria que mudar o programa login para que ele suporte esse novo algoritmo também. No Linux, muitos programas utilizam algum tipo de autenticação de usuários. Não é difícil imaginar o problema se todos eles tivessem que ser reescritos cada vez que se mudasse algum dos critérios de autenticação. Para evitar esse tipo de problema, a autenticação em modernos sistemas Linux é efetuada via PAM (Pluggable Authentication Modules), descrito em (SAMAR; SCHEMERS, 1995). O PAM é um conjunto de bibliotecas que controlam as tarefas de autenticação do sistema e suas aplicações. Assim, o administrador do sistema pode escolher, com relativa facilidade, como aplicações do sistema irão autenticar usuários. Como comentado em (MORGAN, 2002):

Gerenciamento de Usuários

163

(...) sem (reescrever e) recompilar uma aplicação com suporte a PAM, é possível modificar o mecanismo de autenticação que ela usa. Alguém pode, de fato, modificar todo o sistema de autenticação local sem mexer nas aplicações que irão fazer uso disso.

Observe que o PAM permite controlar todos os aspectos ligados à autenticação de um usuário. Assim, como pode ser verificado em (MANN; MITCHELL, 2000), o PAM pode ser utilizado, entre outros, para: • controlar a quantidade de recursos disponíveis a cada usuário; • permitir que o usuário faça sua autenticação apenas a partir de determinados horários e estações; • manter registros (logs) de todas as autenticações efetuadas.

Esses tipos de usos do PAM fogem ao objetivo deste capítulo e serão tema de (UCHÔA, 2005). O que é importante vislumbrar nesta seção é a possibilidade de modificar o sistema de autenticação de uma estação usando o PAM, garantindo que todas as aplicações de sistema utilizem-se do novo sistema para autenticar as contas dos usuários. O PAM foi criado em 1995 pela Sunr, que liberou suas especificações na forma de uma RFC (Request for Comment), disponível em (SAMAR; SCHEMERS, 1995). O Linux derivou sua implementação do PAM a partir deste documento. A Figura 6.16 apresenta uma visão geral da interação do Linux-PAM com uma aplicação utilizando-o durante uma autenticação. Aplicações

/etc/pam.d/

1 Linux−PAM

2 Disk

4 3

Arquivos de Configuração Módulos PAM Figura 6.16: Funcionamento do PAM

164

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

Como comentado em (MANN; MITCHELL, 2000) e (MORGAN, 2002), o fluxo de execução do Linux-PAM, ilustrado na Figura 6.16, geralmente segue a seguinte seqüência de execução: 1. A aplicação – por exemplo login – faz uma chamada ao Linux-PAM. 2. Linux-PAM localiza a configuração apropriada no diretório /etc/pam.d (ou, alternativamente, no arquivo /etc/pam.conf) para obter a lista dos módulos necessários para o serviço requerido. 3. Linux-PAM então carrega cada módulo na ordem dada pelo arquivo de configuração para processar. Dependendo da configuração dos parâmetros, nem todos os módulos listados no arquivo de configuração serão necessariamente executados. 4. Alguns, ou todos os módulos devem conversar com o usuário através da aplicação. Esta conversação normalmente inclui algumas informações que estão presentes no login do usuário, como a solicitação de senha. Se a resposta do usuário satisfizer um módulo PAM em particular, ou se este módulo for satisfeito por alguma maneira, o controle é passado de volta ao Linux-PAM para que este processe o próximo módulo. Assim, os passos 3 e 4 são repetidos para cada módulo relatado no arquivo de configuração, que esteja associado à aplicação em questão. Ao término dos passos acima, o processo termina com um sucesso ou falha. No caso de falha, normalmente a mensagem apresentada ao usuário não indica a causa da falha. Essa mensagem geral é uma forma de garantir a segurança do sistema. Porém, a maioria dos módulos PAM, dispõem diversos níveis de registros de informações, permitindo ao administrador do sistema rastrear os problemas e identificar as violações de segurança. Nesse processo, o Linux-PAM envolve quatro tipos separados de tarefas: gerenciamento de autenticação, gerenciamento de conta, gerenciamento de sessão e gerenciamento de senha. Como informado em (MORGAN, 2002), isso está relacionado aos tipos de módulos existentes no Linux-PAM: Auth: O módulo auth provê dois aspectos relacionados à autenticação do usuário. Primeiro, ele verifica se o usuário é quem ele realmente diz ser, solicitando a ele uma senha ou outros mecaniscmos de identificação. Além disso ele pode configurar credenciais ou privilégios do usuário, como estabelecer a quais grupos o usuário pertence. Account: O módulo account providencia gerenciamento não-autenticado de contas. Pode ser usado para limitar o acesso de um usuário a uma data ou máquina específica, além de permitir controles diversos, como expiração de senha.

Gerenciamento de Usuários

165

Session: O módulo session providencia controle do que fazer antes e depois da conexão do usuário ao serviço disponibilizado pela aplicação PAM. Isso inclui configuração das variáveis de ambiente, registro de atividades, etc. Password: O módulo password é utilizado para alterar a senha (ou outro mecanismo de autenticação do usuário). Em geral é utilizado após o módulo auth, para exigir a senha antiga antes da nova. De uma forma geral, a configuração do Linux-PAM para uma dada aplicação consiste em estabelecer a forma como as tarefas do PAM serão efetuadas para essa aplicação específica. Assim, além de informar os tipos de tarefas necessárias àquela aplicação, também são especificadas as bibliotecas que implementam essas tarefas e como elas devem ser consultadas, o que é melhor descrito na próxima seção.

6.14

CONFIGURAÇÃO BÁSICA DO PAM

6.14.1

Usando o Arquivo /etc/pam.conf

Como comentado na seção anterior, existem duas formas de configurar uma aplicação Linux-PAM. É possível utilizar um único arquivo, o /etc/pam.conf. Nesse caso as configurações devem obedecer o seguinte formato: service-name

module-type

control-flag

module-path

args

Esses parâmetros servem para indicar ao Linux-PAM como implementar as tarefas de autenticação para a aplicação: service-name Esse parâmetro indica o nome do serviço associado à configuração. Geralmente é o nome da aplicação que a utiliza, como login, ftpd, su, etc. module-type Esse parâmetro informa ao Linux-PAM qual o tipo de módulo utilizado, havendo um módulo para cada tipo de tarefa. Pode ser: auth, account, session e password, descritos na seção anterior. control-flag A control-flag indica à biblioteca PAM como reagir em caso de sucesso ou falha. Os módulos PAM podem ser empilhados. Assim, para uma mesma tarefa, módulos do mesmo tipo podem ser executados em série, um após o outro, garantindo que todas as restrições para uma dada autenticação sejam satisfeitas. Dessa maneira, o parâmetro

166

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

control-flag informa ao PAM a importância relativa de cada módulo. Existem duas maneiras básicas de efetuar esse parâmetro e serão vistas mais à frente. module-path Esse parâmetro indica o caminho da biblioteca PAM a ser utilizada, o arquivo de módulo a ser usado. Se o parâmetro iniciar-se com uma barra, ‘/’, então o LinuxPAM irá esperar que seja informado o caminho absoluto do arquivo. Caso isso não aconteça, então Linux-PAM irá esperar o caminho relativo do arquivo ao diretório /lib/security. args Pode ser importante passar alguma informação ao módulo PAM durante o processo de negociação com a aplicação. Nesse caso, o parâmetro args, que é opcional, atende essa necessidade: ele consiste em uma lista de argumentos a ser enviada ao módulo, quando esse for invocado. A Tabela 6.4 apresenta alguns argumentos padrões disponíveis. Entretanto, cada módulo em si poderá possuir uma configuração própria através dos argumentos que utiliza.

Tabela 6.4: Argumentos Padrões do PAM

Argumento debug no_warn use_first_pass

try_first_pass

6.14.2

Descrição gera informação extra nos arquivos de registo do sistema, via syslog instrui ao módulo para não enviar mensagens de aviso (warnings) à aplicação informa ao módulo para utilizar a senha do módulo anterior – se há falha, o módulo não deve tentar solicitar a senha novamente ao usuário também informa ao módulo para solicitar a senha do módulo anterior – entretanto, solicita a senha novamente ao usuário em caso de falha

Utilizando o Diretório /etc/pam.d

A partir da versão 0.56, é possível configurar o Linux-PAM de uma maneira mais flexível, através de arquivos dispostos no diretório /etc/pam.d. Nesse caso, o diretório conterá vários arquivos, um para cada tipo de serviço. Para ser mais exato, cada serviço possuirá um arquivo de mesmo nome nesse diretório. Assim, o serviço sudo será configurado via arquivo /etc/pam.d/sudo.

Gerenciamento de Usuários

167

Em sua compilação normal, não é possível utilizar as duas formas de configuração do Linux-PAM. Dessa maneira, o administrador poderá usar o arquivo /etc/pam.conf ou o diretório /etc/pam.d, não os dois ao mesmo tempo. Assim, na presença de qualquer arquivo de configuração no diretório /etc/pam.d, o Linux-PAM simplesmente ignora a existência do arquivo /etc/pam.conf. Os arquivos no diretório /etc/pam.d são configurados de forma similar à configuração do /etc/pam.conf. Entretanto, como o nome do serviço já é o nome do arquivo, o parâmetro não é utilizado. Dessa forma, cada entrada em um arquivo no /etc/pam.d possui a forma module-type

control-flag

module-path

args

Dessa maneira, a configuração de aplicações no PAM é simplificada. De uma forma geral, a configuração via /etc/pam.d possui as seguintes vantagens (MORGAN, 2002): • há um parâmetro a menos para especificar, o que diminui as chances de erro durante a configuração; • é mais fácil de manter, dado que uma aplicação pode ser reconfigurada sem riscos de interferir nas demais; • é possível fazer links simbólicos de um arquivo a outro, facilitando a cópia da configuração PAM de uma aplicação para outra; • é possível restringir a leitura do arquivo de configuração de uma dada aplicação, ao invés de restringir a todas; • gerenciamento de instalações é facilitado, dado que para uma nova aplicação é suficiente acrescentar um novo arquivo no diretório /etc/pam.d. Por esses e outros motivos, essa forma de configurar o Linux-PAM é preferível e tem sido adotada pela maioria das distribuições modernas. 6.14.3

Configurando o Parâmetro /etc/control-flag

Desde a versão 0.60 do Linux-PAM, a configuração do parâmetro control-flag pode ser feita de duas maneiras. A maneira tradicional é a mais simples e consiste no uso de quatro palavras-chave utilizadas para indicar a severidade associada ao sucesso ou falha de um módulo específico. A nova maneira permite um controle mais preciso, e é descrita em (MORGAN, 2002). Neste texto, só será abordada a forma tradicional, que consiste no uso das seguites palavras-chave:

168

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

required: Essa opção indica que o sucesso do módulo é necessário ao sucesso da tarefa especificada pelo parâmetro module-type. Note que a falha desse módulo não interromperá a checagem dos outros módulos de mesmo tipo. Isso é feito para que uma autenticação errada tome o mesmo tempo que uma autenticação correta, evitando que um hacker fique tentando descobrir, por exemplo, contas válidas no sistema. requisite: O funcionamento dessa opção é similar à opção required. Entretanto, em caso de falha, o controle é retornado automaticamente à aplicação, sem a verificação dos outros módulos de mesmo tipo. Esse parâmetro pode ser usado para evitar que o usário digite sua senha em um ambiente inseguro. Entretanto, pode ser usado por hackers para descobrir contas válidas. Em geral, não deve ser usado. sufficient: O sucesso de um módulo com a opção sufficient é suficiente para satisfazer a pilha de módulos destinada ao tipo de módulo onde é usado. Nesse caso, nenhum outro módulo da pilha é executado. A falha nesse módulo, entretanto, não implica em falha da pilha, a menos que seja o único. optional: Como o nome sugere, essa opção informa que o módulo é opcional ao processo. Em geral, Linux-PAM ignora o resultado desse tipo de módulo para informar se a pilha retornou sucesso ou falha. É utilizado em módulos que oferecem algum serviço ao usuário, mas que não são críticos ao processo de autenticação como um todo. Dessa maneira, empilhando vários módulos de mesmo tipo com as opções de controle, é possível ter um controle razoavelmente preciso do processo de autenticação do usuário. A seção a seguir apresenta um exemplo de configuração de um serviço via Linux-PAM. 6.14.4

Exemplo de Configuração de um Serviço via Linux-PAM

A Figura 6.17 apresenta o conteúdo de um arquivo de configuração de um serviço PAM. Nessa figura, pode ser percebido que o caracter ‘#’ pode ser utilizado para comentários. Além disso, é possível separar os tipos de serviços por linhas em branco, mas isso não é obrigatório. Como se vê, uma mesma tarefa pode ser feita com o empilhamento de vários módulos. No caso do auth, por exemplo, a autenticação é feita com os módulos pam_env, pam_unix e pam_deny. Para entender o funcionamento da autenticação do serviço system-auth, é importante compreender o funcionamento dos módulos que ele usa. Dessa maneira, segue-se uma rápida descrição, em ordem alfabética, dos módulos utilizados nessa configuração:

Gerenciamento de Usuários

169

# system-auth auth required auth sufficient auth required

/lib/security/pam_env.so /lib/security/pam_unix.so likeauth /lib/security/pam_deny.so

account account

required required

/lib/security/pam_unix.so /lib/security/pam_access.so

password password password

required sufficient required

/lib/security/pam_cracklib.so retry=3 type= /lib/security/pam_unix.so use_authtok md5 shadow /lib/security/pam_deny.so

session session

required required

/lib/security/pam_limits.so /lib/security/pam_unix.so

Figura 6.17: O Arquivo /etc/pam.d/system-auth

pam_access Esse módulo é do tipo account e providencia controle de acesso ao login do usuário. A Figura 6.18 apresenta um exemplo auto-instrutivo de configuração desse módulo. Geralmente, esse arquivo de configuração é o /etc/security/access.conf, mas isso pode ser modificado via argumento accessfile. # # # # # # # + # + # + # -

arquivo access.conf formato da configuração permissão : usuários : origens não queremos ninguém acessando de evil.com ou spam.org : ALL : .evil.com .spam.org não queremos login no terminal, exceto do usuário root : ALL EXCEPT root : tty1 permitimos acesso a todos da rede interna, exceto do root : ALL EXCEPT root: 192.168. paul pode acessar da máquina home.nohome.com : paul : home.nohome.com membros do grupo powers podem acessar de qualquer local : powers : ALL ninguém mais pode acessar : ALL : ALL Figura 6.18: Exemplo de Configuração do pam_access

170

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

pam_cracklib Caso o administrador queira evitar senhas fracas, esse módulo de password pode ser utilizado para garantir um mínimo de segurança na escolha de senhas pelos usuários. É possível, por exemplo, configurar o tamanho mínimo da senha e estimular o uso de símbolos especiais. pam_deny Esse módulo nega o acesso ao usuário, sendo utilizado para garantir que o usuário não consiga autenticar-se em caso de falha nos módulos anteriores. Dessa maneira, ele imprime uma segurança extra no esquema de autenticação. pam_env Com esse módulo, o administrador pode configurar adequadamente as variáveis de ambiente do usuário. Para isso, o arquivo /etc/security/pam_env.conf é utilizado. pam_limits Esse módulo, de sessão permite a configuração de limite de recursos que pode ser utilizado por cada sessão do usuário. Nesse caso, o arquivo utilizado para a configuração é o /etc/security/limits.conf. É possível configurar, entre outros, o tempo máximo que o usuário pode utilizar por sessão, bem como a quantidade de memória disponibilizada. pam_unix Esse é o módulo padrão de autenticação Unix. Usualmente irá obter as informações dos arquivos /etc/passwd e /etc/shadow, descritos anteriormente neste capítulo. O leitor interessado em uma descrição mais precisa desses e outros módulos, pode consultar (MORGAN, 2002) ou (MANN; MITCHELL, 2000). Em (MORGAN, 2002) é ainda possível encontrar a descrição dos módulos que são distribuídos oficialmente com o LinuxPAM. Em (MORGAN, 2003) é possível encontrar uma relação relativamente completa dos módulos PAM distribuídos na internet. Voltando ao exemplo apresentado na Figura 6.17, inicialmente as variáveis de ambiente do usuário são configuradas, usando pam_env. Em seguida, o Linux-PAM irá autenticar o usuário através do pam_unix, checando antes se o usuário pode acessar aquele serviço, via pam_access. Antes de abrir a sessão, entretanto, serão configurados os limites de recursos, através do pam_limits. Caso o usuário queira torcar a senha, a segurança da mesma será checada pelo pam_cracklib. Se o usuário não tiver acesso permitido, ou errar sua senha, ele terá acesso negado, graças ao pam_deny. Utilizando o PAM, é possível modificar todo o sistema de autenticação de um sistema. Assim, por exemplo, é possível utilizar informações armazenadas em SGBDs (Sistemas

Gerenciamento de Usuários

171

Gerenciadores de Bancos de Dados), em bases LDAP, ou mesmo utilizar autenticação por leitura de digitais ou da íris. Em (MANN; MITCHELL, 2000), por exemplo, são apresentados alternativas de uso do PAM para autenticação com senhas que funcionam uma única vez.

6.15

COMENTÁRIOS FINAIS

Uma piada freqüente entre administradores de sistemas computacionais é que o gerenciamento desses recursos seria extremamente fácil não fosse um enorme problema: o “usuário”. Não fosse as necessidades do usuário, o processo de configuração de uma máquina seria extremamente fácil. O Linux, por ser um sistema multiusuário e com autenticação altamente configurável, permite ao administrador um sossego maior no gerenciamento desses recurso.

172

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

7 CONFIGURAÇÕES DIVERSAS

7.1

ARQUIVOS DE REGISTRO

Arquivos de registro ou de logs são extremamente úteis para o gerenciamento do sistema. Com eles é possível verificar e acompanhar falhas em certos componentes, tentativas de invasões, estado de processamento, ações dos usuários, dentre outras coisas. Desta forma, o administrador pode tomar conhecimento acerca do funcionamento do sistema como um todo. É de extrema importância saber utilizar os logs, assim como saber como administrá-los em função do espaço em disco que eles ocupam. Dentre as operações de administração destacam-se: a compactação e a gravação em, por exemplo, fitas magnéticas ou mídias de CDs, rotação dos logs, os mantendo dentro de um período de tempo, redefinição dos arquivos de logs a intervalos periódicos afim de abranger outros componentes do sistema que porventura podem ser tornar vitais e descarte dos logs segundo critérios específicos do ambiente. Não é aconselhável o descarte puramente dos logs uma vez que esses podem fornecer informações sobre a evolução de um problema, como por exemplo o histórico dos mecanismos adotados por hackers na tentativa de invadir o sistema. É conveniente mesclar a rotação dos logs, mantendo disponíveis de forma imediata (para pesquisar com, por exemplo, grep) ao administrador os logs mais recentes (dentro de um período de tempo especificado) e a gravação sob a forma de backup. A Figura 7.1 ilustra um pequeno script que trata de rotação de logs, descartando-se o mais antigo e empurrando-se os restantes em um mecanismos de fila. Porém o script da Figura 7.1 não funciona perfeitamente com aplicativos que deixam os seus arquivos de logs permanentemente abertos pois, neste caso, a simples criação de um novo arquivo faz com que o aplicativo perca a referência do arquivo previamente em uso. Para sanar este problema, sugere-se o script ilustrado na Figura 7.2.

174

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

#! bin/sh cd /var/log mv logfile2 logfile3 mv logfile1 logfile2 mv logfile logfile1 cat /dev/null > logfile chmod 600 logfile

Figura 7.1: Script para Implementar Rotação de Logs #! bin/sh cd /var/log mv logfile2.gz logfile3.gz mv logfile1.gz logfile2.gz mv logfile logfile1 cat /dev/null > logfile kill -1 pid gzip logfile1

Figura 7.2: Script para Implementar Rotação de Logs Usando Sinais

O exemplo da Figura 7.2 utiliza sinais afim de reiniciar o aplicativo e fazer com que este referencie de forma correta o arquivo recém-construído pelo cat. Uma outra diferença apresentada é que esse pequeno script comprime os arquivos de log gerados. Para a realização da rotação, existe um script em Perl escrita por Matt Segur e Michael Bernstein que poderá ser encontrada em http://www.admin.com/. Ainda sobre rotação e gerenciamento de logs, o RedHat apresenta uma ferramenta chamada logrotate para esses propósitos. Existem alguns arquivos de logs que não podem ser gerenciados: /var/run/utmp e /var/log/lastlog. O lastlog armazena os últimos logins dos usuários e é estruturado na forma de arquivo esparso, indexado pelo UID. Por sua vez, o utmp é responsável por manter um registro de todos os usuários conectados no momento. Tal registro pode estar errado em virtude de eliminação de shells com sinais inapropriados ou devido às alterações feitas pelos próprios usuários, uma vez que ele está freqüentemente aberto à escrita. Os arquivos de log podem ser encontrados em diretórios distintos (porém mais usualmente são encontrados em /var/log e /var/adm) e usando nomenclaturas também distintas. Para localizá-los pode-se verificar os arquivos /etc/rc.d/init.d/*, /etc/rc.d*

Configurações Diversas

175

ou /etc/init.d/* afim de verificar quais os daemons estão ativando registros em logs e suas localizações específicas ou, ainda, verificar o arquivo /etc/syslog.conf para visualizar os daemons que geram seus logs via syslog. O syslog é uma ferramenta para auxiliar os daemons no tangente à geração dos logs assim como também auxiliar o administrador do sistema em manipulá-los. Para tanto, ele pode ser dividido em três partes: o daemon do syslog (syslogd e seu arquivo de configuração – /etc/syslog.conf), openlog (que constitui a biblioteca de funções do syslog afim de enviar mensagens ao syslogd) e o logger (shell do syslog). Os daemons se comunicam com o syslogd através de pipes ou sockets representado pelo arquivo especial /dev/log ou /var/run/log. Cada linha do arquivo de configuração do syslog utiliza basicamente o formato ilustrado a seguir: seletor

ação

É conveniente expressar que a separação entre os campos seletor e ação deve ser feita com caracteres de tabulação (TAB) e não com espaços em branco. O campo seletor é formado por um ou mais binômios constituídos pela identificação do recurso e pelo nível de severidade do log. Essa formatação será alvo de um exemplo de arquivo syslog.conf. Antes do exemplo, a Tabela 7.1 identifica os possíveis recursos pertinentes ao syslog e os níveis de severidade podem ser encontrados na Tabela 7.2. Observe que os recursos syslog, authpriv e ftp não estão disponíveis em todas as versões do syslog. Em relação às ações, o syslog pode gravar os logs em arquivos locais, encaminhar para máquinas remotas ou enviar mensagens para usuários (ou todos ou aqueles pertencentes a uma lista). A Figura 7.3 ilustra um exemplo de um arquivo syslog.conf. *.emerg local2.info *.warning; auth.info lpr.debug local0.notice auth.notice

* root /var/adm/logmessages /var/adm/lpd-errs @gimux.ufla.br (ifdef ’LOGHOST’,’/var/log/authlog’,’@loghost’)

Figura 7.3: Exemplo de um Arquivo /etc/syslog.conf

No exemplo da Figura 7.3, a primeira linha é responsável pelo envio de mensagens a todos os usuários conectados na ocorrência de eventos de "pânico", tais mensagens podem ser restritas a um ou mais usuários como ocorre na segunda linha. Em tal linha há a comunicação ao root caso haja algum evento informativo relacionado ao local2.

176

Recurso kern user mail daemon auth lpr news uucp cron mark local0-7 syslog authpriv ftp *

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

Tabela 7.1: Recursos do syslog Daemons Associados (Alguns Exemplos) kernel processos dos usuários (ntpd) softwares relacionados com o correio eletrônico (sendmail) daemons do sistema (gated, inetd, named, ntpd) comandos relacionados à autorização e segurança (login, rlogin, su, passwd) spool de impressão (lpd) sistema de notícias da usenet (nnrpd) destinado ao uucp relacionado ao daemon cron registros de data/hora gerados a intervalos regulares (syslogd) 8 tipos de mensagens locais (tcpd - local7, sudo - local2, popper - local0) mensagens internas ao syslog mensagens privadas de autorização associado ao ftpd (daemon do ftp) todos os recursos com exceção do mark

Tabela 7.2: Recursos do syslog Nível emerg alert crit err warning notice info debug

Descrição Situações de pânico Situações urgentes Condições críticas Condições gerais de erros Mensagens de avisos Eventos merecedores de investigação Mensagens puramente informativas Mensagens somente para depuração

O syslog também pode efetuar gravações em arquivos de log conforme tratam as linhas 3 e 4 ou o envio a uma máquina responsável pela manipulação de logs dentro de um ambiente de rede (linha 5). Por último, a linha 6 faz a gravação ou o envio à uma máquina. A seleção é realizada caso a variável de ambiente LOGHOST esteja ou não instanciada. Porém esse tratamento condicional é restrito a apenas algumas versões de syslog que contém préprocessador de macro m4 (o administrador deverá consultar os manuais do syslog para verificar a possibilidade de manipulação de macros).

Configurações Diversas

177

Para testar o correto funcionamento do syslog, o administrador pode utilizar o comando logger. Tal comando permite o envio de mensagens de eventos ao syslogd como ilustrado a seguir: # logger -p local5.warning "mensagem de teste" Nesse caso, uma linha contendo a frase "mensagem de teste"deverá ser gravada (ou enviada) ao dispositivo assinalado no arquivo de configuração do syslogd. Caso isso não ocorra, o administrador deverá rever a configuração do syslog.

7.2

GERENCIAMENTO DE SOFTWARE

Freqüentemente, o administrador se verá obrigado a instalar novos programas em sua máquina. Esse procedimento poderá ser feito de várias formas, dependendo da distribuição Linux utilizada e da forma como o aplicativo foi disponibilizado. Apesar de não serem as únicas formas, as distribuições atuais utilizam-se de aplicativos em tar.gz ou tgz, arquivos rpm ou arquivos deb. Distribuições baseadas no RedHat utilizam-se principalmente do formato rpm para instalação de aplicativos. Esse pacote, cujo histórico foi apresentado na Seção 2.5, simplifica muito o trabalho do administrador. A Tabela 7.3 apresenta algumas formas de uso desse comando. Tabela 7.3: Formas de Uso do Comando rpm Opção

Descrição

-qa -Uvh pacote.rpm -Fvh pacote.rpm -ev pacote -rebuild pacote.src.rpm -qi pacote -ql pacote -qf arquivo

lista todos os pacotes instalados atualiza ou instala um pacote atualiza um pacote (somente se ele já estiver instalado) remove um pacote gera uma rpm binário a partir de um rpm fonte lista a descrição do pacote lista os arquivos do pacote informa qual o pacote associado ao arquivo

Algumas opções da Tabela 7.3 podem ser combinadas. Por exemplo o comando “rpm -qilf arquivo” informaria qual o pacote associado ao arquivo, dando ainda sua descrição e relação de arquivos. A opção “-F” é útil quando se tem um diretório de atualizações

178

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

e não se quer ficar checando quais os pacotes instalados e que precisam ser atualizados. Assim, caso o administrador tenha baixado atualizações de pacotes em um diretório /usr/updates e queira atualizar os pacotes instalados na máquina, mas não instalar novos pacotes, ele pode emitir o comando # rpm -Fvh /usr/updates/*rpm O comando rpm é muito versátil e flexível. É possível, por exemplo, verificar se não há arquivos modificados após uma instalação, ou mesmo checar assinaturas (para garantir que o pacote foi realmente feito por quem deveria). A checagem de assinaturas garante que o pacote não foi alterado por hackers. Isso é feito com a opção “-checksig”. Mais detalhes sobre o rpm podem ser obtidas na página de manual do comando, em (BARNES, 1999) ou em (BAILEY, 1998). Pacotes da distribuição Debian também são facilmente gerenciáveis através do comando dpkg. A opção “-i” instala um pacote e a opção “-r” é usada para remover. Consulte a documentação desse comando para maiores detalhes. Um comando muito utilizado na distribuição Debian e que foi portada para distribuições que utilizam rpm é o apt-get. Esse aplicativo é utilizado para baixar pacotes e suas dependências (assim ele faz download não só do aplicativo informado, mas das bibliotecas que ele usa. Uma observação importante é que a versão para arquivos rpm foi desenvolvida inicialmente pela Conectiva. A instalação de programas no formato tar.gz é geralmente mais complicada. Em geral, o administrador precisará buscar informações junto ao distribuidor do programa (em arquivos INSTALL ou README, por exemplo), sobre como fazer essa instalação. Caso o programa siga formas padrões de distribuição, entretanto, essa tarefa não precisa ser árdua. Em geral, a instalação envolve os seguintes passos (será utilizado o programa superprog, versão 3.1, disponibilizado no arquivo superprog-3.1.tar.gz):

1. Descompactar o arquivo superprog-3.1.tar.gz em algum diretório para compilação (recomenda-se o tmp): # tar -zxvf superprog-3.1.tar.gz 2. Entra-se no diretório descompactado: # cd superprog-3.1 3. Executa-se o programa de configuração (pode ser o caso de se passar opções, nesse caso deve-se verificar as opções disponíveis):

Configurações Diversas

179

# ./configure 4. Se o passo anterior deu erro, deve-se verificar o motivo do erro e corrigi-lo (consultando a documentação do programa). Caso contrário, deve-se iniciar a compilação: # make 5. O passo anterior não deve dar erros, mas se houver também será necessário corrigilo. Caso não haja erros o próximo passo é instalar o programa: # make install

Maiores detalhes sobre esse processo podem ser encontrados em (SCHNEIDER, 2002), que orienta sobre o uso dos autotools e do comando make.

7.3

AUTOMATIZANDO TAREFAS

A utilização de comandos que possam agendar o processamento é extremamente útil ao administrador de sistemas. Com tais comandos pode-se, dentre outras coisas: fazer rotação automática dos logs, limpar e fazer backup dos sistemas de arquivos em um momento mais apropriado e fazer a atualização de bases de informações caso utilize algum sistema de armazenamento “espelhado”. Dentre os comandos que existem, serão vistos nesta seção os comandos vinculados ao cron e o comando at. 7.3.1

O uso do cron

O cron tem a função de iniciar a execução de tarefas agendadas pelos usuários. O sistema de cron é basicamente representado pelo daemon do cron e pelos seus arquivos de configuração crontab associados aos usuários. Os arquivos crontab são nomeados com o login dos usuários (daqueles que fazem uso deste serviço) afim de associar os processos ao UID específico. Esses arquivos costumam ser armazenados em /var/spool/cron. As linhas do crontab seguem o formato a seguir: minuto hora dia mês dia-da-semana comando Os campos seguem as especificações referenciadas na Tabela 7.4. Caso algum campo seja marcado com ‘*’ (asterisco), o cron interpretará como qualquer valor, por exemplo,

180

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

Tabela 7.4: Definição dos Campos do crontab

Campo

Intervalo

minuto hora dia mês dia-da-semana

0 a 59 0 a 23 1 a 31 1 a 12 0 a 6, onde 0 corresponde ao Domingo

30 2 * * 1 20 1 * * * 40 22 * * 0-3,6

(cd /home/fulano; make server) find /tmp -atime +3 -exec rm -f {} ’;’ /home/fulano/programa01

Figura 7.4: Exemplo de crontab

caso o asterisco esteja no campo dia, então a ação será executada todos os dias. O crontab também aceita intervalos (valores separados por um hífen) ou um conjunto de valores separados por vírgulas. A Figura 7.4 ilustra um exemplo de crontab. No exemplo da Figura 7.4, pode ser encontrada, na primeira linha, a definição de execução do make às 02:30 de toda segunda-feira. Já na segunda linha, ocorrerá a remoção de todos arquivos cujo último acesso ocorreu a mais de 3 dias em relação à data corrente. Essa remoção será realizada diariamente às 01:20. Por último, a terceira linha indica a execução do programa01, que deverá ocorrer às 22:40 de todos os dias exceto nas quintas e sextas (dias 4 e 5, respectivamente). O registro do arquivo crontab é feito por intermédio do comando “crontab [opções] [nome_do_arquivo]”. Alguns parâmetros associados a esse comando são apresentados na Tabela 7.5. Tabela 7.5: Opções Usuais do Comando crontab

Opção

Descrição

-e -l -r

ativa o editor padrão para modificações no arquivo crontab lista o conteúdo do arquivo crontab remove o arquivo crontab

Dessa forma, o registro de um arquivo crontab chamado, por exemplo, ctab é realizado como se segue:

Configurações Diversas

181

# crontab ctab Esse comando registra o arquivo ctab substituindo o arquivo crontab previamente registrado (caso exista) do usuário específico. O root pode passar como parâmetros um nome de usuário ou de um crontab afim de poder manipular, a seu gosto, o subsistema cron. O controle de acesso ao cron é feito mediante uso dos arquivos cron.allow e cron.deny. Tais arquivos podem estar localizados, dependendo do sistema, nos diretórios /etc/cron.d, /etc/, /var/spool/cron ou /var/cron (consulte o manual do crontab para obter essa informação em seu sistema). Caso o arquivo allow exista, apenas os usuários nele listados poderão registrar crontabs. Porém, caso o allow não exista e sim exista o arquivo deny, todos os usuários exceto aqueles listados no deny poderão registrar os seus crontabs. Porém o administrador tem a função de verificar o acesso do diretório no qual os arquivos de crontab são armazenados. Tal verificação objetiva impedir que usuários gravem arquivos em tal diretório sem a utilização do comando crontab (burlando, assim, a autorização contida nos arquivos allow e deny). Em geral, para separar a configuração de agenda do sistema da do usuário root e mesmo de outros usuários, existe um arquivo /etc/crontab com a agenda do sistema. Em alguns casos, como na Figura 7.5, esse arquivo apenas chama comandos localizados em um dado diretório. O comando run-parts, usado nessa figura, é responsável por entrar no diretório associado e executar todos os comandos ali depositados. Isso facilita o trabalho do administrador, que precisa apenas inserir o seu script em um dos diretórios, de acordo com a periodicidade desejada. Observe que o início desse arquivo contém configurações de ambiente para a execução dos scripts. SHELL=/bin/bash PATH=/sbin:/bin:/usr/sbin:/usr/bin MAILTO=root HOME=/ # run-parts 01 * * * * root 02 4 * * * root 22 4 * * 0 root 42 4 1 * * root

run-parts run-parts run-parts run-parts

/etc/cron.hourly /etc/cron.daily /etc/cron.weekly /etc/cron.monthly

Figura 7.5: Exemplo de /etc/crontab

182

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

7.3.2

O uso do at

O comando at é também utilizado para agendar processamentos. Porém, o comando at é menos flexível em relação ao cron uma vez que não se é permitido programar os processamentos para ocorrerem em diversos momentos (como, por exemplo, todos os dias). A permissão de utilização do at é semelhante ao crontab, ou seja, utiliza os arquivos/etc/at.allow e /etc/at.deny de forma idêntica aos arquivos allow e deny do crontab. A sintaxe do at é exibida a seguir: # at [opções] momento Por default, o at coleta os comandos a serem executados através da entrada-padrão onde a finalização da edição é feita pelo EOF (ctrl-D). A tabela 7.6 mostra as principais opções associadas ao comando at. Em relação ao campo momento, o comando at aceita os parâmetros listados na Tabela 7.7. Tabela 7.6: Opções do Comando at Opção

Descrição

-c -d -f

exibe os jobs registrados remove um job específico permite que os comandos sejam lidos a partir de um arquivo (não pela entradapadrão) lista todos os jobs associados a um usuário envia um e-mail ao usuário quando o job for finalizado

-l -m

A Figura 7.6 mostra alguns exemplos de utilização do comando at. Nessa figura, notase que as duas primeiras linhas são equivalentes, ou seja, ambas iniciarão o relativo processamento às 19:45h do dia 9 de dezembro. Na linha seguinte, o início está configurado para as 03:00h de sábado. O uso da palavra-chave now pode ser visto na penúltima linha. Nesse caso, o início se dará após 5 horas do uso do at. Na última linha, o horário configurado é o meio-dia do dia seguinte ao atual. Nota-se, a utilização do next em substituição ao incremento ‘+1’.

7.4

CÓPIAS DE SEGURANÇA

Cópias de segurança no Linux podem ser feitas de várias formas, sendo possível utilizarse vários mecanismos para isso. Por exemplo: cópias em fitas DAT podem ser feitas

Configurações Diversas

183

Tabela 7.7: opções válidas para o campo momento do comando at Momento

Descrição

hh:mm [modifiers]

Identificação do dia no formato de 00:00 a 23:59. Caso haja introdução dos modificadores am e pm, o formato do momento passa a ser de 12 horas. Pode-se, ainda, introduzir a palavra-chave zulu, o que corresponde ao horário GMT.

midnight | noon | teatime | now

Esses parâmetros substituem o formato numérico do momento para representar meia-noite, meio-dia, 16:00 ou um momento relativo a partir do momento corrente (now). O uso do now deverá ser sucedido de um incremento. O incremento consiste em uma expressão formada pelo sinal de mais (+), seguido de um valor numérico e, finalmente, uma das palavras-chave: minute, hour, day, week, month ou year. Caso o incremento seja +1, pode-se utilizar a palavra next em substituição.

month num[, year]

O mês pode ser escrito por completo ou utilizando-se as três primeiras letras. O campo num representa o dia do mês (1 a 31) e o ano deverá ser formado por quatro algarismos.

day

Denota o dia da semana, escrito por completo ou pelas suas três primeiras letras.

today | tomorrow

Representa o início do processamento no mesmo dia da utilização do comando at ou no dia seguinte.

at at at at at

19:45 December 9 7:45pm Dec 9 3 am Saturday now + 5 hours noon next day

Figura 7.6: Exemplos de Uso do Comando at

utilizando-se os comandos tar, dump ou dd, só para comentar os mais usados. Cópias em CDs podem ser feitas com o uso do mkisofs e do cdrecord. Ainda, o comando tar pode ser usado para compactar diretórios, permitindo backups em diversas mídias. Também não se pode esquecer que, em um ambiente de rede, é possível utilizar de NFS ou SAMBA para fazer backups remotos em máquinas UNIX ou Windows, respectivamente. O administrador deverá escolher a forma mais prática e adequada à sua realidade. Os diretórios mais importantes para um backup são: o /home, com os arquivos pessoais dos

184

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

usuários; o /etc com a configuração da máquina e o /var com arquivos de logs ou arquivos utilizados por servidores (como as páginas de um site em um servidor WWW).

7.5

CONFIGURAÇÃO DE DATA E HORA

A configuração de data e hora no Linux é relativamente simples. A primeira configuração diz respeito ao fuso horário adotado. Essa configuração é efetuada no arquivo /etc/sysconfig/clock. Uma forma mais prática e rápida é utilizar-se do comando timeconfig, disponível em várias distribuições. Para se configurar o data e a hora local, são utilizados dois comandos: o date e o hwclock (em alguns sistemas, simplesmente clock). O comando date, mais fácil de utilizar, configura a data e a hora local, mas somente a nível de kernel. Caso queira-se atribuir essa data a BIOS do sistema, deve-se usar o comando hwclock. A Figura 7.7 mostra um exemplo de uso desses comandos. # date Seg Fev 10 12:08:02 BRST 2003 # date -s "02/11/2003 15:00:00" Ter Fev 11 15:00:00 BRST 2003 # hwclock --systohc # hwclock Ter 11 Fev 2003 15:00:02 BRST

0.138947 segundos

Figura 7.7: Configurando Data e Hora

No caso da Figura 7.7, a primeira linha informa a data atual, utilizando-se de informações de localização do sistema. Nesse caso, é informado, por exemplo, o fuso horário (BRST – Brazil East). Ao se acrescentar o parâmetro “-s”, exemplo do segundo comando, date recebe uma string para atribuir ao relógio lógico do sistema (kernel e aplicativos). Observe que, nesse caso, a data deve ser informada no padrão mês/dia/ano. Com o comando hwclock -systohc, esse valor é copiado para a BIOS do sistema, o que pode ser confirmado depois com uma execução simples do comando hwclock. Uma observação a ser feita é que configuração de data e hora no sistema deve ser feita com extrema cautela. O motivo é que vários servidores fazem tarefas periódicas e podem

Configurações Diversas

185

ficar meio “malucos” com uma atualização desse tipo. Pode acontecer de alguns serviços precisarem ser reiniciados para voltarem ao comportamento normal. Sempre que possível, recomenda-se a alteração via BIOS.

186

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

REFERÊNCIAS BIBLIOGRÁFICAS

ADOBE SYSTEMS INCORPORATED. PostScript Printer Description File Format Specification, Version 4.3. San Jose: Adobe Developer Technologies, 1996. ADOBE SYSTEMS INCORPORATED. PostScript Language Reference. 3. ed. Reading: Addison-Wesley, 1999. ALVESTRAND, H. IETF Policy on Character Sets and Languages. Internet Engineering Task Force (IETF), Jan. 1998. (Request for Comments: 2277; Best Currenct Practice: 18). URL: http://www.ietf.org/. ANONYMOUS. Maximum Linux Security: A Hacker’s Guide to Protecting Your Linux Server and Workstation. Indianapolis: Sams, 2000. BAILEY, E. C. Maximum RPM: Taking the Red Hat Package Manager to the Limit. Raileigh: Red Hat Software Inc., 1998. Disponível em: <http://www.rpm.org/>. BARNES, D. RPM HOWTO, Revision 3.0. The Linux Documentation Project, 3 November 1999. Disponível em: <http://www.ibiblio.org/pub/Linux/docs/HOWTO/RPM-HOWTO>. DOOREN, R. van. Quota mini-HOWTO, v.03 April 2002. 2002. The Linux Documentation Project [WWW]. URL: http://www.ibiblio.org/pub/Linux/docs/HOWTO/mini/ Quota. EASY SOFTWARE PRODUCTS. CUPS Software Administrators Manual. Hollywood, 2002. URL: http://www.cups.org/. EASY SOFTWARE PRODUCTS. CUPS Software Programmers Manual. Hollywood, 2002. URL: http://www.cups.org/. EASY SOFTWARE PRODUCTS. CUPS Software Users Manual. Hollywood, 2002. URL: http://www.cups.org/.

188

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

FIELDING, R. et al. Hypertext Transfer Protocol – HTTP/1.1. Internet Engineering Task Force (IETF), June 1999. (Request for Comments: 2616). Disponível em: <http://www.ietf.org/>. FRAMPTON, S. Linux Administration Made Easy. [S.l.]: The Linux Documentation Project, 1999. URL: http://www.tldp.org/guides.html. FREE STANDARDS GROUP. Linux Standard Base Core Specification 3.1. Free Standards Group, 2006. Disponível em: <http://www.linux-foundation.org/en/Specifications>. HASTINGS, T. (Ed.). Internet Printing Protocol/1.1: Model and Semantics. Internet Engineering Task Force (IETF), Setembro 2000. (Request for Comments: 2911). URL: http://www.ietf.org/. HASTINGS, T. et al. Internet Printing Protocol/1.1: Implementor’s Guide. Internet Engineering Task Force (IETF), Novembro 2001. (Request for Comments: 3196). URL: http://www.ietf.org/. HENDERSON, B. Linux Loadable Kernel Module HOWTO, Revision v1.02 2002-05-21. 2002. The Linux Documentation Project [WWW]. URL: http://www.ibiblio.org/ pub/Linux/docs/HOWTO/Module-HOWTO. HERRIOT, R. (Ed.). Internet Printing Protocol/1.1: Encoding and Transport. Internet Engineering Task Force (IETF), Setembro 2000. (Request for Comments: 2910). URL: http://www.ietf.org/. HINNER, M. Filesystems HOWTO, v. 0.7.5, 22 Ago 2000. 2000. The Linux Documentation Project [WWW]. URL: http://www.ibiblio.org/pub/Linux/docs/HOWTO/ Filesystems-HOWTO. III, L. M. (Ed.). Line Printer Daemon Protocol. Internet Engineering Task Force (IETF), Agosto 1990. (Request for Comments: 1179). URL: http://www.ietf.org/. INTERNET MAIL CONSORTIUM. Using International Characters in Internet Mail. Internet Mail Consortium, Ago. 1998. (IMCR-010). Disponível em: <http://www.imc.org/mail-i18n.html>. KROAH-HARTMAN, G. udev – a Userspace Implementation of devfs. In: Proceedings of The Linux Symposium 2003. Ottawa, Ontario (Canada): [s.n.], 2003. Disponível em: <http://www.kroah.com/linux/talks/ols 2003 udev paper/Reprint-Kroah-Hartman-OLS2003.pdf>. KROAH-HARTMAN, G. Myths, Lies, and Truths about the Linux Kernel. 2006. End Talk At Linux Symposium 2006. Disponível em: <http://www.kroah.com/log/linux/ols 2006 keynote.html>.

Referências Bibliográficas

189

LOOSEMORE, S. et al. The GNU C Library Reference Manual. 0.10. ed. [S.l.: s.n.], 2001. MANN, S.; MITCHELL, E. L. Linux System Security: An Administrator’s Guide to Open Source Security Tools. New Jersey: Prentice-Hall, 2000. MILLER, T. C. Sudo Main Page. 2002. [WWW]. URL: http://www.sudo.ws/sudo/. MOCHEL, P. The sysfs filesystem. In: Proceedings of The Linux Symposium 2005. Ottawa, Ontario (Canada): [s.n.], 2005. v. 1, p. 313–326. Disponível em: <http://www.kernel.org/pub/linux/kernel/people/mochel/doc/papers/ols-2005/mochel.pdf>. MORGAN, A. G. Pluggable Authentication Modules (PAM). Open-PAM working group, December 2001. (Internet Draft). URL: http://gandalf.neark.org/pub/linux/ libs/pam/pre/doc/current-draft.txt. MORGAN, A. G. The Linux PAM System Administrators’ Guide; Draft v0.76. [S.l.]: Linux-PAM, 2002. URL: http://www.us.kernel.org/pub/linux/libs/pam/. MORGAN, A. G. 2003. URL: http://www.kernel.org/pub/linux/libs/pam/. MOURANI, G. Securing and Optmizing Linux: The Ultimate Solution. Montreal: Open Network Architecture, 2001. NEMETH, E. et al. UNIX System Administration Handbook. 2. ed. New Jersey: Prentice-Hall, 1995. NEMETH, E. et al. UNIX System Administration Handbook. 3. ed. New Jersey: Prentice-Hall, 2001. OLIVEIRA, R. S. de; CARISSIMI, A. da S.; TOSCANI, S. S. Sistemas Operacionais. 2. ed. Porto Alegre: Sagra-Luzzato, 2001. PIKE, R.; THOMPSON, K. Hello world. In: USENIX Winter. [s.n.], 1993. p. 43–50. Disponível em: <http://plan9.bell-labs.com/sys/doc/utf.pdf>. RAYMOND, E. S. The cathedral and the bazar. Sebastopol-CA: O’Reilly, 1999. RUSSELL, R.; QUINLAN, D. (Ed.). Filesystem Hierarchy Standard - Version 2.2 final. Filesystem Hierarchy Standard Group: Filesystem Hierarchy Standard Group, 2001. Disponível em: <http://www.pathname.com/fhs/>. RUSSELL, R.; QUINLAN, D.; YEOH, C. (Ed.). Filesystem Hierarchy Standard. Version 2.3. Filesystem Hierarchy Standard Group: Filesystem Hierarchy Standard Group, 2004. Disponível em: <http://www.pathname.com/fhs/>.

190

EDITORA - UFLA/FAEPE - Gerenciamento de Sistemas Linux

SAMAR, V.; SCHEMERS, R. Unified login with Pluggable Authentication Modules (PAM). Open Software Foundation, October 1995. (Request For Comments: 86.0). URL: http://gandalf.neark.org/pub/linux/libs/pam/pre/doc/rfc86.0.txt.gz. SCHNEIDER, B. O. Linguagens de Programação II. Lavras: UFLA/FAEPE, 2002. (Curso de Pós Graduação “Lato Sensu” (Especialização) a Distância em Administração em Redes Linux). SCHNEIER, B. Applied Cryptography. New York: John Wisley, Inc., 1996. SILVA, R. M. de A. Sistemas operacionais. Lavras: UFLA/FAEPE, 2002. (Curso de Pós Graduação “Lato Sensu” (Especialização) a Distância em Administração em Redes Linux). STANFIELD, V.; SMITH, R. W. Linux System Administration. San Francisco: Sybex, 2001. (Craig Hunt Linux Library). SWEET, M. An Overview of the Common UNIX Printing System, Version 1.1. Hollywood, 2002. URL: http://www.cups.org/. TANENBAUM, A. S. Modern Operating Systems. London: Prentice-Hall, 1992. TANENBAUM, A. S. Modern Operating Systems. 2. ed. New Jersey: Prentice-Hall, 2001. THE OPEN GROUP. The Single UNIX Specification, Version 3. IEEE, 2004. Disponível em: <http://www.unix.org/version3/online.html>. TORVALDS, L.; DIAMOND, D. Só por prazer: Linux, os bastidores de sua criação. Rio de Janeiro: Campus, 2001. UCHÔA, J. Q. Segurança Computacional. 2. ed. Lavras: UFLA/FAEPE, 2005. (Curso de Pós Graduação “Lato Sensu” (Especialização) a Distância em Administração em Redes Linux). UCHÔA, J. Q. Serviços de Redes em Linux. 3. ed. Lavras: UFLA/FAEPE, 2008. (Curso de Pós Graduação “Lato Sensu” (Especialização) a Distância em Administração em Redes Linux). (em fase de revisão). VASUDEVAN, A. The Linux Kernel HOWTO, v4.2, 26 Jan 2003. 2003. The Linux Documentation Project [WWW]. URL: http://www.ibiblio.org/pub/Linux/docs/ HOWTO/Kernel-HOWTO. WIRZENIUS, L. et al. The Linux System Administrator’s Guide. Version 0.9. Chapel Hill (North Carolina): The Linux Documentation Project, 2005. Disponível em: <http://www.tldp.org/guides.html>.

Referências Bibliográficas

YERGEAU, F. UTF-8, a transformation format of ISO 10646. Internet Engineering Task Force (IETF), Nov. 2003. (Request for Comments: 3629; Standard: 63). URL: http://www.ietf.org/. ZIMMERMANN, H. OSI Reference Model – The ISO Model of architecture for open systems interconnection. IEEE Transactions On Communications, IEEE, v. 28, n. 4, p. 425–432, 4 1980. Disponível em: <http://www.comsoc.org/livepubs/50 journals/pdf/RightsManagement eid=136833.pdf>.

191