Este capítulo apresenta uma visão geral do Conectiva Red Hat Linux, apresentando características especiais e pequenas diferenças de outros sistemas Unix. Observe que a maioria das funções de administração são executadas através do Painel de Controle, o qual é apresentado no capítulo 6.

12.1 Estrutura do Sistema de Arquivos

O Conectiva Red Hat Linux é totalmente compatível com o Padrão Linux de Sistema de arquivos, um documento que define o nome e a localização de muitos arquivos e diretórios.

As duas características mais importantes em relação ao padrão Linux são a compatibilidade com outros sistemas e a habilidade de montar a partição /usr somente para leitura. A partição /usr contém os executáveis mais comuns e não devem ser alterados pelos usuários. Graças a isso ela pode ser montada de uma unidade de CD-ROM ou a partir de outra máquina através do NFS. O padrão atual (FSSTND – Linux Filesystem Standard) é a referência utilizada na definição dos padrões.

12.1.1 Visão geral do FSSTND

Os diretórios e arquivos listados aqui são uma parte daqueles especificados pelo documento FSSTND.

12.1.1.1 O diretório /etc

O diretório /etc é reservado para arquivos de configuração que estão localizados no sistema local. Nenhum binário deve residir no /etc. O X11 e diretórios skel podem ser subdiretório do /etc:

O diretório X11 é utilizado para arquivos de configuração como o XF86Config. Os diretórios skel são destinados à criação de arquivos de "esqueletos" de arquivos de usuários, ou seja árvores ou arquivos que são criados nos diretórios home dos usuários.

12.1.1.2 O diretório /lib

O diretório /lib deve conter somente as bibliotecas necessárias a execução dos binários residentes nos diretórios /bin e /sbin.

12.1.1.3 O diretório /sbin

O diretório /sbin é destinado aos executáveis utilizados somente pelo superusuário root e aos executáveis necessários para a inicialização do sistema e montagem do /usr e execução das tarefas de recuperação do sistema. O FSSTND diz:

No mínimo os seguintes programas devem estar presentes no /sbin:

12.1.1.4 O diretório /usr

O diretório /usr é destinado aos arquivos que são compartilhados por todos os usuários ou pela rede. O /usr normalmente tem a sua própria partição e é montado somente para leitura. Os seguintes subdiretórios podem estar presentes:

O diretório X11R6 é utilizado pelo sistema X Window (Xfree86 no Conectiva Red Hat Linux), bin é para executáveis, doc para documentações diversas, que não páginas de manual, etc para arquivos de configuração para todo o site, inclusive arquivos headers em C, info para arquivos GNU, lib para bibliotecas, man para páginas de manual, sbin para executáveis de administração do sistema que não residam no /sbin e src para códigos fonte.

12.1.1.5 O diretório /usr/local

O diretório /usr/local é utilizado pelo administrador do sistema para a instalação de softwares localmente, podendo ser usado por programas e arquivos que devem ser compartilhados entre um grupo de usuários ou máquinas e não estejam localizados no /usr.

O diretório /usr/local é similar à estrutura do diretório /usr. Possui vários subdiretório, que são similares aos do /usr:

12.1.1.6 O diretório /var

Todo o programa que necessite gravar logs ou spool ou bloquear arquivos ou diretórios, pode utilizar o diretório /var. Os seguintes subdiretórios podem ser localizados no /var:

Arquivos de logs do sistema como o wtmp e lastlog ficam no /var/log. O diretório /var/lib contém ainda as bases de dados RPM. Páginas de manual estão em /var/catman e arquivos bloqueados (locked) estão em /var/lock. O diretório /var/spool tem subdiretórios destinados aos vários sistemas que necessitem criar arquivos.

12.1.2 /usr/local no Conectiva Red Hat Linux

No Conectiva Red Hat Linux o uso do /usr/local é um pouco diferente daquelas especificadas no FSSTND, que especifica que o /usr/local é o local onde softwares devem residir para garantir a segurança na atualização. Uma vez que no Conectiva Red Hat Linux são utilizados o RPM ou o Glint, não é necessário protegê-los colocando-os no /usr/local. Ao invés disso recomendamos a utilização do /usr/local no armazenamento local de software.

12.2 Localização dos arquivos especiais do CRHL

Além dos arquivos do RPM que estão localizados no /var/lib/rpm (conforme capítulo 5), temos as áreas /usr/lib/rhs, destinado ao painel de controle e ferramentas relacionadas e /etc/sysconfig, destinada ao armazenamento de arquivos de configuração.

12.3 Usuários, Grupos e Grupos privados

O Conectiva Red Hat Linux tem algumas ferramentas e regras que facilitam o gerenciamento de usuários e grupos.

A primeira delas é o módulo Usuários e Grupos do painel de controle (vide capítulo 6), podendo ainda ser utilizado o programa adduser.

12.3.1 Usuários Padrão

A tabela 72 apresenta os padrões no processo de instalação (basicamente o conteúdo do arquivo /etc/passwd). O grupo (GID) na tabela é o grupo primário do usuário. Veja na seção 11.3.3 como grupos são utilizados.

Tabela 72:Usuários padrão

12.3.2 Grupos Padrão

A tabela 73 apresenta uma lista dos grupos padrão que são criados durante o processo de instalação (basicamente o conteúdo do arquivo /etc/group).

Tabela 73: Grupos Padrão

12.3.3 Grupos de usuários privativos

Conectiva Red Hat Linux utiliza um sistema de grupo privado de usuários (UPG), tornando a administração muito mais simples. O sistema UPG não altera nada do padrão UNIX. Simplesmente oferece uma nova convenção no gerenciamento de grupos. Toda vez que um novo usuário for criado, automaticamente é criado um novo grupo. O sistema funciona da seguinte forma:

Grupo de Usuário Privativo: Cada usuário tem o seu próprio grupo, do qual ele é o único membro.

umask = 002: A tradicional máscara de usuário do UNIX é 022, o que evita que outros usuários e outros membros do grupo de modificarem os arquivos do usuário primário. Como cada usuário tem o seu próprio grupo, uma umask igual a 002 evita que os usuários modifiquem os arquivo privativos do usuário primário. A umask reside em /etc/profile.

Bit SGID em Diretórios: caso o bit SGID esteja ativo em um diretório (com o comando chmod g+s diretório), os arquivos criados no diretório terão o grupo idêntico ao do diretório.

Muitos administradores preferem criar um grupo para cada projeto e atribuem o GID a cada usuário integrado ao projeto. Gerenciar arquivos da maneira tradicional pode ser bastante cansativo, pois os arquivos quando criados pelos usuários pertencem ao grupo primário do usuário. Quando a mesma pessoa está alocada em diversos projetos cria-se uma dificuldade para o compartilhamento e administração dos arquivos. Com o sistema UPG esta tarefa torna-se mais simples.

Digamos que um projeto chamado CRHL tem várias pessoas trabalhando nele e os arquivos criados são colocados no diretório /desenvolvimento. Pode-se criar um grupo chamado desenv, alterar o grupo do diretório para desenv (chgrp) e adicionar todos os usuários ao grupo desenv. Agora todos os membros do grupo desenv poderão criar arquivos no diretório /desenvolvimento que poderão ser editados pelos demais.

Caso haja usuários que participem de vários projetos, basta criar um diretório para o projeto, alterar seu sgid e incluir o usuário no grupo, sem necessidade de alterar o umask de cada usuário.

É aconselhável alterar o sgid do diretório home do usuário para o seu grupo.

12.3.3.1 Utilização de Grupo de Usuário Privativo

Apresentamos a seguir um roteiro de utilização do esquema UPG:

• Digamos que se queira ter um grupo de pessoas trabalhando em um conjunto de arquivos residentes em /usr/lib/emacs/site-lisp. Muda-se o dono e grupo do diretório (dono root, grupo emacs) da seguinte forma:

  chown -R root.emacs /usr/lib/emacs/site-lisp

• Adicionam-se os usuários ao grupo emacs através do painel de controle;
• Para permitir que os usuários criem arquivos no diretório deve-se informar:

  chmod 775 /usr/lib/emacs/site-lisp

• Quando um usuário cria um arquivo ele é criado com o seu grupo primário. Para evitar isso basta informar o comando abaixo, o que fará que todos os arquivos criados no diretório site-lisp pertençam ao grupo emacs.

  chmod 2775 /usr/lib/emacs/site-lisp

• Os novos arquivos devem ter permissões 664, para que outros usuários do grupo emacs possam editá-los. Para tanto há que alterar a umask padrão para 002.
• Para evitar que todos os usuários do grupo users possam acessar os diretório home dos demais deve ser criado um grupo privativo para cada novo usuário que seja adicionado ao sistema.

12.4 Autenticação de usuário com PAM

Programas que dão algum tipo de acesso aos usuários devem primeiramente autenticá-los. Ao logar-se no sistema um usuário deve fornecer a identificação e a senha, porém existem outras formas de validação de usuários.

PAM, que significa Módulos Anexáveis de Autenticação ("Pluggable Authentication Modules"), é uma forma de permitir que o administrador do sistema defina uma política de autenticação sem ter que recompilar programas. Para tanto basta editar alguns arquivos de configuração.

Ao utilizar-se RPM para instalar programas que necessitem de autenticação, as alterações necessárias serão efetuadas automaticamente, porém é importante conhecer os arquivos de configuração.

12.4.1 Módulos

Há quatro tipo de módulos definidos pelo PAM: módulos de autenticação que validam os usuários, provavelmente solicitando a senha e liberando acessos a grupos; módulos de controle que garantem a autenticação (verificam se a conta não expirou, se o usuário pode acessar o sistema em determinados horários, etc...); módulo de senhas utilizado para a criação de senhas e módulos de sessão que são utilizados para liberar para o usuário válido os recursos necessários, como a montagem do diretório home, disponibilidade de correio, etc...

Estes módulos podem estar separados, podendo ser utilizados de várias maneiras. Como por exemplo o rlogin que normalmente utiliza no mínimo dois métodos de autenticação: caso o rhosts autorize o acesso, a conexão é estabelecida, caso contrário o módulo de autenticação de senhas é utilizado.

Novos módulos podem ser adicionados a qualquer tempo e novas aplicações podem utilizar o PAM.

12.4.2 Serviços

Cada programa que utiliza o PAM define o seu próprio nome de serviço. O programa de login define um serviço chamado login, ftpd possui o serviço ftp, etc... Em geral os nomes de serviços levam o nome dos programas a que estão associados.

12.4.3 Arquivos de configuração

O diretório /etc/pam.d é utilizado por todas as aplicações que utilizem PAM. Cada aplicação tem seu próprio arquivo de configuração. Um arquivo similar ao seguinte:

#%PAM-1.0

auth required /lib/security/pam_securetty.so

auth required /lib/security/pam_pwdb.so shadow nullok

auth required /lib/security/pam_nologin.so

account required /lib/security/pam_pwdb.so

password required /lib/security/pam_cracklib.so

password required /lib/security/pam_pwdb.so shadow nullok use_authtok

session required /lib/security/pam_pwdb.so

A primeira linha é um comentário (começando por #). As próximas três linhas definem os três módulos que serão usados na autenticação. A primeira linha garante que o usuário que tentar entrar no sistema como superusuário root, o terminal ao qual ele esteja conectado deve estar listado em /etc/securetty. A segunda linha cria a exigência de informação de senha e sua validação no acesso ao sistema e a terceira verifica se o arquivo /etc/nologin existe, e caso isso ocorra, mostra o conteúdo do arquivo e se o usuário não for o superusuário root não permitirá o acesso ao sistema. Todos os três módulos serão executados, mesmo que o módulo anterior forneça acesso ao sistema.

Como trata-se de um sistema de segurança, ele não avisa ao usuário porque sua autenticação não foi válida, gerando uma maior dificuldade na tentativa de quebra de segurança.

A quinta linha define que os módulos de controle sejam ativados. Por exemplo caso o sistema de shadow passwords esteja ativado, o módulo pam_pwdb.so verificará se a conta ou a senha não estão expiradas.

A sexta linha especifica que caso o login deva alterar a senha do usuário, isso seja efetuado pelo programa pam_pwd.so. Isso somente acontecerá caso a troca seja necessária, como por exemplo pela sua expiração.

A última linha define que o módulo pam_pwdb.so deve ser utilizado no gerenciamento da sessão. Como este módulo atualmente não execute nenhuma função importante, pode ser substituído por qualquer módulo julgado conveniente.

É muito importante a ordem das linhas no arquivo de configuração e a sua mudança pode gerar resultados diferentes dos previstos.

O arquivo de configuração do rlogin tem o seguinte conteúdo:

auth required /lib/security/pam_securetty.so

auth required /lib/security/pam_nologin.so

auth sufficient /lib/security/pam_rhosts_auth.so

auth required /lib/security/pam_pwdb.so shadow nullok

É muito similar ao arquivo de login porém há uma linha adicional que especifica um módulo extra e a ordem dos módulos é diferente.

Inicialmente pam_securetty mantém a proibição de login do superusuário root de terminais sem segurança, o que inibe o rlogin para root. Caso isso seja necessário (apesar de não recomendado) basta remover esta linha.

Após o módulo pam_nologin checa a existência do arquivo /etc/nologin conforme descrito acima.

Na terceira linha temos o módulo pam_rhosts_auth.so que autentica o usuário e imediatamente apresenta um retorno positivo ao rlogin sem que a senha seja fornecida. Caso este módulo não autorize o usuário a próxima linha será executada.

Finalmente o módulo pam.pwdb.so executará uma autenticação normal desde que o módulo anterior não tenha autorizado o usuário.

É possível não solicitar a senha caso o módulo pam_securetty.so não autorize o acesso. Para tanto basta alterar o parâmetro required para que requisite.

12.4.4 Shadow passwords

O módulo padrão pam_pwdb.so pode suportar o sistema de shadow passwords. Para converter o sistema local para o sistema de shadow password basta executar os seguintes comandos:

O módulo pam_pwdb.so automaticamente detectará que o sistema de shadow password está sendo utilizado e fará os ajustes necessários.

12.4.5 Mais Informações

Esta é apenas uma introdução ao PAM. Maiores informações podem ser encontradas em /usr/doc/pam*, incluindo o Guia do Administrador do Sistema, um Manual de Desenvolvimento e os padrões para o PAM.

12.5 Os processos Boot, Init, and Shutdown

12.5.1 System V

Esta seção apresenta uma breve descrição do processo de boot (inicialização).

Init é o programa ativado pelo kernel durante a inicialização do sistema e que administra a ativação dos processos necessários, incluindo o gettys, que viabiliza o login, daemons NFS, FTP e tudo o mais que seja necessário.

SysV Init é o padrão para o mundo Linux no controle da inicialização do sistema, devido a simplicidade, maior número de recursos e maior flexibilidade que o tradicional init BSD. Os arquivos de configuração residem no diretório /etc/rc.d. Nele podem ser encontrados o rc.sysinit e os seguintes diretórios: init.d, rc0.d, rc1.d, rc2.d, rc3.d, rc4.d, rc5.d e rc6.d

init.d contém uma série de scripts. Um script é necessário para cada serviço que seja ativado na ativação do sistema ou na mudança de nível de execução (runlevel). Serviços incluem processos como rede, nfs, sendmail, httpd, etc... Serviços não incluem atividades que devem ser executadas uma única vez como por exemplo setserial. Essas atividades são atendidas pelo rc.local ou rc.serial.

Os arquivos rc.local e rc.serial estão localizado em /etc/rc.d.

O processo de boot segue o seguinte roteiro:

• kernel procura em diferentes locais pelos init e executa o primeiro encontrado;
• init executa o /etc/rc.d/rc.sysinit
• rc.sysinit executa uma série de passos necessários e o rc.serial (caso este exista)
• init executa todos os scripts padrões para o nível de execução
• init executa o rc.local

O padrão do nível de execução é definido pelo /etc/inittab, onde deve existir uma linha como essa:

Para alterar o nível de execução basta editar o arquivo /etc/inittab e alterar o número de 3 para outro desejado. Caso ocorra algum problema com a execução será necessário reinicializar o sistema da seguinte forma:

Isso permite inicializar o sistema em modo monousuário e corrigir o inittab.

Como o sistema executa todos os scripts? Ao visualizar-se o conteúdo do rc3.d pode visualizar o seguinte:

lrwxrwxrwx 1 root root 17 13:11 S10network -> ../init.d/network

lrwxrwxrwx 1 root root 16 13:11 S30syslog -> ../init.d/syslog

lrwxrwxrwx 1 root root 14 13:32 S40cron -> ../init.d/cron

lrwxrwxrwx 1 root root 14 13:11 S50inet -> ../init.d/inet

lrwxrwxrwx 1 root root 13 13:11 S60nfs -> ../init.d/nfs

lrwxrwxrwx 1 root root 15 13:11 S70nfsfs -> ../init.d/nfsfs

lrwxrwxrwx 1 root root 18 13:11 S90lpd -> ../init.d/lpd.init

lrwxrwxrwx 1 root root 11 13:11 S99local -> ../rc.local

Pode-se verificar que não há arquivos no diretório, somente links para os scripts residentes no diretório init.d. Os links têm ainda um "S" no início do número, o que significa que devem ser incializados e um "K" significa que devem ser interrompidos. O número é utilizado para fins de ordenação. O init inicializará todos os serviços baseado na ordem em que estes apareçam. É possível duplicar números, porém isso pode ser um pouco confuso de administrar. Tudo o que é necessário são dois dígitos, acompanhados de S ou K.

Cada script é escrito para aceitar argumentos como start ou stop e podem ser executados manualmente se necessário. Por exemplo, para parar o servidor httpd digita-se:

O init simplesmente lê o nome e caso haja um K, chama o script com o argumento stop, caso tenha um S chama-o com o argumento start.

Alguns sistemas podem ter diferentes níveis de execução, o que significa que em determinado nível pode estar executando httpd, sendmail, networking, etc enquanto em outros somente xdm, networking, etc viabilizando diferentes configurações e usos para o mesmo equipamento.

12.5.2 Níveis de inicialização

Normalmente o Conectiva Red Hat Linux é inicializado no nível 3 – modo multiusuário. Os seguintes níveis são utilizados:

Caso o sistema tenha problemas no /etc/inittab, ou o passwd esteja corrompido ou ainda não se sabe a password, pode-se reinicializar o sistema em modo monousuário digitando-se linux 1 no LILO prompt.

12.5.3 Desligando

Para desligar o Conectiva Red Hat Linux deve-se utilizar o comando shutdown. As formas mais comuns são:

O primeiro desativará todos os processos e serviços e desligará a máquina, o segundo reinicializará o sistema.

12.6 Modos de resgate

Quando existem problemas sérios no sistema deve-se utilizar as técnicas de resgate, descritas a seguir:

12.6.1 Através do LILO

Caso o sistema inicialize, mas não permita o login de nenhum usuário é possível utilizar-se da inicialização como monousuário ou de emergência. No LILO boot prompt digite linux single. Neste nível de execução todos os sistemas de arquivos estarão montados, mas a rede estará inativa. No modo de emergência somente o sistema de arquivos root será montado e somente em modo de leitura.

12.6.2 Discos de emergência

Os discos de instalação podem ser usados como discos de resgate. Na inicialização via disquete digite rescue no prompt de boot e o processo de instalação fará algumas perguntas solicitando o segundo disco e criará as sessões VC1 e VC2. Estas sessões rodarão o shell ash, um shell mínimo sem history ou comandos de edição.

A variável PATH é ajustada para o /mnt e os comandos serão executados a partir daí. Pode ser necessário adicionar os caminho /mnt/bin e /mnt/usr/bin enquanto são feitos os reparos no sistema.

Estarão disponíveis versões limitadas dos seguintes comandos antes de se montar o /mnt:

mount: não requer que o dispositivo a ser montado exista e não solicita o nome completo do dispositivo, assumindo o sistema de arquivos ext2:

mount /dev/sda1 /mnt -t ext2 o que é equivalente a mount sda1 /mnt

ash: versão completa

cat: sem opções

chmod: não aceita nomes simbólicos.

cpio: versão completa.

e2fsck: versão completa

fdisk: versão completa

gzip: versão completa

gunzip: versão completa

insmod: versão completa

ls: versão completa

lsmod: sem opções

mkdir: sem opções longas

mke2fs: versão completa

mknod: somente em formato octal

open: versão completa

rm: sem nomes longos

rmmod: versão completa

sh: links simbólicos para ash

12.6.3 Dicas Úteis

Alguma vez o kernel foi recompilado e na ânsia de verificar o resultado, o sistema foi reinicializado antes da execução do LILO? E o kernel antigo não tinha uma entrada no lilo.conf?

Bem, este é um erro comum e para solucioná-lo, na maioria das vezes, é possível usar o disquete de inicialização do Conectiva Red Hat Linux com o sistema de arquivos root montado e pronto para execução.

linux single root=/dev/hdXX initrd=