SlideShare ist ein Scribd-Unternehmen logo
1 von 367
Downloaden Sie, um offline zu lesen
Linux: Ferramentas técnicas ʹ 2ª edição
Capa
Este livro é uma coleção de dicas que ensinam a configurar e corrigir problemas "na unha",
manipulando diretamente os arquivos de configuração e módulos do sistema, sem depender
de nenhum configurador, escrever shell scripts, instalar drivers manualmente e dominar
ferramentas de diagnóstico e recuperação do sistema.
Por ser escrito em uma linguagem simples e didática e com um nível crescente de dificuldade,
este livro é indicado tanto para usuários avançados que querem expandir seus conhecimentos,
quanto para iniciantes que desejam compreender mais profundamente o sistema.
Autor: Carlos E. Morimoto
Páginas: 312
Formato: 23 x 16 cm
Editora: GDH Press e Sul Editores
ISBN: 85-205-0401-9
Lançado em: Março de 2006
Descrição
As distribuições Linux estão de um modo geral se tornando muito fáceis de usar, em algumas
áreas até mesmo mais fáceis de usar que o Windows. Mas, isso acaba deixando um gosto
amargo na boca. Afinal, onde está o desafio?
Em outros casos as coisas não funcionam tão bem assim e o gosto amargo fica por conta do
modem, webcam, placa 3D ou placa wireless que não está funcionando ou outro problema
qualquer, que não pode ser solucionado usando as ferramentas gráficas.
Este livro é uma coleção de dicas que ensinam a configurar e corrigir problemas "na unha",
manipulando diretamente os arquivos de configuração e módulos do sistema, sem depender
de nenhum configurador, escrever shell scripts, instalar drivers manualmente e dominar
ferramentas de diagnóstico e recuperação do sistema. É ideal para quem gosta de fuçar e quer
entender melhor como o sistema funciona internamente, editando arquivos de configuração,
compilando módulos e escrevendo scripts. Nesta segunda edição, o livro recebeu uma grande
quantidade de atualizações em todos os capítulos e muitas das dicas antigas foram
substituídas por novas.
O capítulo sobre shell script foi expandido, trazendo mais dicas sobre o desenvolvimento de
scripts gráficos e também scripts e regras para o hotplug e udev, que permitem abrir
programas e executar outros scripts quando determinados dispositivos são plugados na
máquina.
Foi incluído também um novo capítulo, que ensina a desenvolver soluções baseadas no
Kurumin e outros live-CDs baseados no Knoppix, que permitem colocar em prática as dicas
aprendidas no restante do livro. Por ser escrito em uma linguagem simples e didática e com
um nível crescente de dificuldade, este livro é indicado tanto para usuários avançados, quanto
iniciantes que desejam compreender maisprofundamente o sistema.
Carlos E. Morimoto é o criador do http://www.hardware.com.br, o maior site técnico do país.
Seu trabalho inclui mais de dois mil artigos, dicas e tutoriais publicados, projetos de
desenvolvimento em Linux, cursos, palestras e a publicação de 17 livros técnicos sobre
hardware, redes, servidores e Linux, entre eles os livros Hardware, o Guia Definitivo; Redes,
Guia Prático; Servidores Linux, Guia Prático; Smartphones, Guia Prático; Linux, Entendendo o
Sistema e Linux, Ferramentas Técnicas.
Sumário
Prefácio ................................ ................................ ................................ ................................ ... 7
Capítulo 1: Entendendo a estrutura do sistema................................ ................................ ....... 7
Como funciona o suporte a hardware no Linux................................ ................................ ..... 8
Os componentes do sistema................................ ................................ ............................... 11
Kernel ................................ ................................ ................................ ................................ 11
Módulos................................ ................................ ................................ ............................. 16
Os processos de boot e os arquivos de inicialização................................ ............................ 18
Ativando e desativando serviços................................ ................................ ......................... 22
X ................................ ................................ ................................ ................................ ........ 25
Gerenciador de login................................ ................................ ................................ .......... 27
Xfree e Xorg ................................ ................................ ................................ ....................... 27
A árvore genealógica das distribuições................................ ................................ ............... 28
Capítulo 2: Configuração, ferramentas e dicas................................ ................................ ...... 31
Editando o /etc/fstab ................................ ................................ ................................ ......... 31
Configurando o lilo................................ ................................ ................................ ............. 38
Dual-Boot com dois HDs................................ ................................ ................................ . 42
Usando uma imagem de fundo................................ ................................ ....................... 43
Configurando o grub ................................ ................................ ................................ .......... 44
Configurando o vídeo: /etc/X11/xorg.conf................................ ................................ .......... 48
KVM via software com o Synergy................................ ................................ ........................ 59
Usando o hdparm................................ ................................ ................................ ............... 65
Recompilando o Kernel ................................ ................................ ................................ ...... 69
Baixando os fontes................................ ................................ ................................ ......... 70
Configurando................................ ................................ ................................ .................. 71
Compilando................................ ................................ ................................ .................... 77
Instalando................................ ................................ ................................ ...................... 79
Recompilando o Kernel à moda Debian................................ ................................ .......... 80
Aplicando patches................................ ................................ ................................ .......... 81
Criando patches ................................ ................................ ................................ ................. 82
Acelerando a compilação com o distcc................................ ................................ ............... 83
Criando pacotes a partir dos fontes com o checkinstall................................ ....................... 85
Escrevendo scripts de backup................................ ................................ ............................. 87
Usando o autofs/automount................................ ................................ .............................. 92
Acessando dispositivos USB................................ ................................ ................................ 94
Configurando manualmente................................ ................................ ........................... 94
Devs e hotplug................................ ................................ ................................ ................ 98
Entendendo o udev................................ ................................ ................................ ...... 100
Renomeando interfaces de rede com o udev................................ ................................ 102
Fazendo backup e recuperando a MBR e tabela de partições................................ ........... 104
Usando o Gpart................................ ................................ ................................ ............ 105
Usando o Testdisk ................................ ................................ ................................ ........ 106
Recuperando partições danificadas................................ ................................ .................. 109
Gerenciamento de setores defeituosos como o ReiserFS................................ .................. 114
Monitorando a saúde do HD com o SMART................................ ................................ ...... 116
Copiando dados de HDs ou CDs defeituosos................................ ................................ ..... 120
Aproveitando módulos de memória defeituosos................................ .............................. 122
Eliminando dados com segurança................................ ................................ ..................... 123
Administrando a memória swap................................ ................................ ....................... 127
Ativando o suporte a mair de 1GB de memória RAM................................ ........................ 129
Clonando partições com o Partimage................................ ................................ ............... 131
Instalando................................ ................................ ................................ .................... 132
Funções básicas................................ ................................ ................................ ............ 133
Fazendo uma imagem de todo o HD................................ ................................ ............. 138
Gravando imagens num compartilhamento darede................................ ..................... 139
Segurança: detectando rootkits................................ ................................ ........................ 143
Instalando o Kurumin 7 (e outras distros) num pendrive ou cartão................................ ... 145
Salvando as configurações................................ ................................ ................................ 153
Monitores de temperatura e coolers................................ ................................ ................ 155
Gerenciamento de energia................................ ................................ ............................... 159
Capítulo 3: Instalando drivers adicionais................................ ................................ ............. 164
Verificando links, arquivos e compiladores................................ ................................ ....... 164
Configurando softmodems no Linux................................ ................................ ................. 167
A idéia básica................................ ................................ ................................ ................ 168
Driver da Smartlink................................ ................................ ................................ ....... 169
Intel AC97 e ATI IXP................................ ................................ ................................ ...... 174
Intel 537 e 536 ................................ ................................ ................................ ............. 176
Lucent e Agere ................................ ................................ ................................ ............. 178
PC-Tel PCI................................ ................................ ................................ ..................... 180
Modems com chipset Conexant................................ ................................ .................... 181
Instalando placas wireless................................ ................................ ................................ 182
Ndiswrapper................................ ................................ ................................ ................. 184
ACX100 e ACX111................................ ................................ ................................ ......... 187
MadWiFi................................ ................................ ................................ ....................... 189
ADMteck ADM8211................................ ................................ ................................ ...... 190
Realtek 8180 ................................ ................................ ................................ ................ 191
Orinoco USB................................ ................................ ................................ ................. 192
Broadcom................................ ................................ ................................ ..................... 193
IPW2100 e IPW2200................................ ................................ ................................ ..... 193
Ralink 2400 e 2500................................ ................................ ................................ ....... 197
Linux-wlan-ng................................ ................................ ................................ ............... 198
Suporte a webcams................................ ................................ ................................ .......... 199
Driver apca5xx................................ ................................ ................................ .............. 201
Logitech QuickCam................................ ................................ ................................ ....... 202
Sqcam ................................ ................................ ................................ .......................... 202
Modems ADSL USB................................ ................................ ................................ ........... 203
Driver da nVidia................................ ................................ ................................ ................ 208
Instalando manualmente................................ ................................ .............................. 208
Ativando os recursos especiais................................ ................................ ..................... 214
FSAA................................ ................................ ................................ ............................. 214
Configurador gráfico................................ ................................ ................................ ..... 216
Twin View................................ ................................ ................................ ..................... 219
Instalando à moda Debian................................ ................................ ............................ 221
Driver para placas com chipset nForce................................ ................................ .............. 223
Ativando o driver de rede................................ ................................ ............................. 224
Ativando o driver de som................................ ................................ .............................. 225
Driver 3D da ATI ................................ ................................ ................................ ............... 225
Instalando................................ ................................ ................................ .................... 227
Configurando e solucionando problemas................................ ................................ ...... 228
Tablets ................................ ................................ ................................ ............................. 233
Configurando placas de TV ................................ ................................ ............................... 236
Gravando ................................ ................................ ................................ ..................... 241
Configurando mouses touchpad com funções especiais................................ ................... 242
Bootsplash ................................ ................................ ................................ ....................... 246
Capítulo 4: Programando em shell script................................ ................................ ............. 250
O básico ................................ ................................ ................................ ........................... 251
Fazendo perguntas................................ ................................ ................................ ........... 255
Mais dicas sobre o kdialog................................ ................................ ................................ 268
Controlando aplicativos via DCOP................................ ................................ ..................... 275
Usando os servicemenus do KDE................................ ................................ ...................... 278
Detectando hardware ................................ ................................ ................................ ...... 284
Alterando arquivos de configuração................................ ................................ ................. 288
Corrigindo erros ................................ ................................ ................................ ............... 293
Pacotes auto-instaláveis................................ ................................ ................................ ... 296
Mais exemplos úteis................................ ................................ ................................ ......... 297
Criando interfaces no Kommander................................ ................................ ................... 302
Criando scripts para o hotplug................................ ................................ .......................... 328
Criando regras para o udev................................ ................................ ............................... 333
Capítulo 5: Remasterizando o Kurumin e outros live-CDs................................ .................... 340
O básico ................................ ................................ ................................ ........................... 341
Extraindo................................ ................................ ................................ .......................... 344
Fechando a nova imagem................................ ................................ ................................ . 348
Personalizando o KDE e programas................................ ................................ ................... 352
Scripts de inicialização................................ ................................ ................................ ...... 355
Mudando a lingua padrão e traduzindo as mensagens de boot................................ ......... 359
Mudando o usuário padrão................................ ................................ .............................. 360
Criando um DVD de recuperação................................ ................................ ...................... 360
Criando seus próprios pacotes .deb................................ ................................ .................. 364
Prefácio
As distribuições Linux estão de um modo geral se tornando muito fáceis de usar, até mesmo
mais fáceis de usar que o Windows em algumas áreas. Mas isso acaba deixando umgosto
amargo na boca. Afinal, onde está o desafio?
Em outros casos as coisas não funcionam tão bem assim e o gosto amargo fica por conta do
modem, webcam, placa 3D ou placa wireless que não está funcionando ou outro problema
qualquer, que não pode ser solucionado usando as ferramentas gráficas.
Este livro é uma coleção de dicas que ensinam a configurar e corrigir problemas "na unha",
manipulando diretamente os arquivos de configuração e módulos do sistema, sem depender
de nenhum configurador, escrever shell scripts, instalar drivers manualmente e dominar
ferramentas de diagnóstico e recuperação do sistema.
É ideal para quem gosta de fuçar e quer entender melhor como o sistema funciona
internamente, editando arquivos de configuração, compilando módulos e escrevendo scripts.
Nesta segunda edição, o livro recebeu uma grande quantidade de atualizações em todos os
capítulos e muitas das dicas antigas foram substituídas por novas.
O capítulo sobre shell script foi expandido, trazendo mais informações sobre o
desenvolvimento de scripts gráficos, ferramentas de configuração e também scripts e regras
para o hotplug e udev, que permitem abrir programas e executar tarefas diversas quando
novos dispositivos são plugados na máquina.
Foi incluído também um novo capítulo, que ensina a desenvolver novas distribuições ou
soluções baseadas no Kurumin e outros live-CDs derivados do Knoppix, que permitem colocar
em prática as dicas aprendidas no restante do livro.
Por ser escrito em uma linguagem simples e didática e com um nívelcrescente de dificuldade,
este livro é indicado tanto para usuários avançados, quanto iniciantes que desejam
compreender mais profundamente o sistema.
Capítulo 1: Entendendo a estrutura do sistema
Os primeiros sistemas Unix foram desenvolvidos na década de70, com o objetivo de serem
robustos, simples e utilizarem pouca memória, de forma a rodarem com um bom desempenho
nos computadores limitados da época.
Porém, por serem desenvolvidos tendo em mente os administradores de sistema, que sempre
possuíam bons conhecimentos, nem sempre a facilidade de uso era uma prioridade.
O Linux pode ser considerado um sistema Unix, que conserva muitas das características dos
sistemas originais. Para quem vem do Windows, a organização das pastas, a instalação de
novos programas e o uso dos arquivos de configuração parece algo esotérico. Mas no fundo as
coisas não são tão complicadas assim.
Este capítulo é uma introdução à estrutura do Linux, destinada ao público técnico.
Como funciona o suporte a hardware no Linux
As distribuições Linux sempre vêm de fábrica com suporte a muitos dispositivos, em geral
quase tudo é detectado automaticamente. Os maiores problemas são, em geral, os
softmodems que precisam ser instalados manualmente. O mesmo se aplica se você tiver uma
placa de vídeo da nVidia ou da ATI ou outros dispositivos (como várias placas de rede wireless),
cujos fabricantes disponibilizam drivers proprietários.
Mas, afinal, como é a instalação destes drivers no Linux? Cadê o assistente para a instalação de
novo hardware? Onde que eu aponto a pasta onde estão os arquivos? Calma, vamos chegar lá
:-).
O suporte a dispositivos no Linux é feito através de "módulos" incluídos no Kernel, arquivos
que ficam dentro da pasta "/lib/modules/versão_do_kernel_usada/". Estes módulos são a
coisa mais parecida com um "driver" dentro da concepção que temos no Windows. Para ativar
suporte a um certo dispositivo, você precisa apenas carregar o módulo referente a ele.
Veja que os módulos ficam organizados em pastas: a pasta "kernel/drivers/net/" contém
drivers para placas de rede, a pasta "kernel/drivers/usb/" agrupa os que dão suporte
dispositivos USB e assim por diante.
Até o Kernel 2.4, os módulos de Kernel utilizavam a extensão ".o", que é uma extensão
genérica para objetos em C. A partir do Kernel 2.6, passou a ser usada a extensão ".ko" (kernel
object), que é mais específica.
Quase sempre, os módulos possuem nomes que dão uma idéia do dispositivo a que oferecem
suporte. O "8139too.ko" dá suporte às placas de rede com o chipset Realtek 8139, o
"sis900.ko" dá suporte às placas SiS 900, enquanto o "e100.ko" ativa as placas Intel E100.
Os módulos podem ser carregados e descarregados a qualquer momento usando os comandos
"modprobe" e "modprobe -r"; não apenas na inicialização do sistema.
Existe também o comando "insmod", mais antigo, que também permite carregar módulos. A
diferença entre o "insmod" e o "modprobe" é que o modprobe carrega apenas módulos já
instalados, junto com todas as dependências, ou seja, outros módulos de que o primeiro
precise para funcionar. Se você tentar carregar o módulo "usb-storage" (que dá suporte a
pendrives e HDs USB), vai perceber que serão carregados também os módulos "usbcore" e
"ehci-hcd".
O "insmod" é muito menos inteligente, carrega apenas o módulo solicitado, retornando um
erro caso ele precise de outros. A única vantagem é que ele permite carregar módulos a partir
de qualquer pasta, permitindo que você teste um módulo que acabou de compilar, ou que
gravou num pendrive, por exemplo.
Os módulos são gerados durantea compilação do Kernel. Você não precisa se preocupar com
isso se não quiser, pois as distribuições quase sempre incluem versões bem completas do
Kernel por padrão. Mas, de qualquer forma, existe sempre a possibilidade de recompilar o
Kernel, mexendo nas opções e ativando ou desativando os módulos que quiser.
Você pode incluir módulos para todo tipo de dispositivos, de marcas e modelos diferentes. Eles
não atrapalham em nada, pois apenas alguns deles (os que você estiver usando no momento)
ficarão carregados na memória. Estes módulos geralmente são pequenos; um conjunto
completo com os módulos para todo tipo de dispositivos (que totalizam mais de mil arquivos
no Kernel 2.6), normalmente ocupa de 40 a 50 MB no HD.
Podemos dividir os drivers de dispositivo para o Linux em dois grupos. O primeiro é o dos
drivers de código aberto, que podem tanto ser desenvolvidos pelos próprios fabricantes
quanto por voluntários em cantos remotos do mundo. Desenvolver drivers usando engenharia
reversa sem ajuda dos fabricantes parece ser um passatempo bastante popular :-).
Estes drivers open-source são incluídos diretamente no Kernel, o que faz com que sejam
incluídos diretamente nas distribuições e você não precise se preocupar muito com eles. Sua
placa funciona e todo mundo fica feliz.
A segunda categoria é a dos drivers proprietários, de código fechado, que são desenvolvidos
pelos próprios fabricantes. Em alguns casos os drivers são de livre distribuição e também
podem ser incluídos diretamente nas distribuições. Em outros, você mesmo precisará baixar e
instalar o driver. É aqui que entram os drivers para softmodems, para muitas placas wireless e
também os drivers para placas 3D da nVidia e da ATI.
A psicologia para lidar com eles é a seguinte: instalar um destes drivers envolve duas tarefas:
baixar e instalar o módulo propriamente dito e criar um "dispositivo" (device), um atalho que
aponta para o endereço de hardware usado por ele.
Ao instalar um modem Lucent, por exemplo, é criado um dispositivo "/dev/ttyLT0" por ondeo
modem é acessado. Para facilitar esta tarefa, geralmente os drivers vêm com algum tipo de
instalador, geralmente um script simples de modo texto que cuida disso para você.
Os módulos são parte integrante do Kernel, por isso os módulos para uma determinada
distribuição não funcionam em outra, a menos que por uma grande coincidência as duas
utilizem exatamente a mesma versão do Kernel. Isso é bastante improvável já que o Kernel do
Linux é atualizado quase que diariamente.
Se você usar uma distribuição popular, Mandriva, Fedora, SuSE, etc., é possível que você
encontre um driver pré-compilado para download (que pode ser encontrado com a ajuda do
Google ;). Neste caso, você só vai precisar instalar um pacote RPM ou executar um arquivo de
instalação. Em outras situações, você encontrará apenas um arquivo genérico ainda não
compilado, contendo um instalador que se encarrega de compilar um módulo sob medida para
o Kernel em uso.
Como ele não tem como adivinhar qual distribuição ou Kernel você está utilizando, é
necessário ter instalados dois pacotes que acompanham qualquer distribuição:kernel-source
e kernel-headers. No Mandriva, por exemplo, você pode instalá-los usando os comandos:
# urpmi kernel-source
# urpmi kernel-headers
Naturalmente, para que ele possa compilar qualquer coisa, você precisará também de um
compilador, o gcc, que também acompanha as distribuições. Se você tiver estas três coisas, vai
conseguir instalar qualquer driver sem maiores problemas, basta seguir as instruções na
página de download ou no arquivo INSTALL ou README dentro do pacote.
Uma grande parte deste livro é justamente dedicada a falar sobre a instalação destes drivers
difíceis, abordando também os problemas de instalação mais comuns.
Um lembrete importante sobre a nomenclatura adotada neste livro e em outros tipos de
documentação é que a cerquilha (#) no início do comando indica que ele deve ser executado
como root, o que é necessário ao instalar programas e editar arquivos de configuração. Os
comandos com um dólar ($) por sua vez devem ser executados usando uma conta de usuário.
Lembre-se de que, em qualquer distribuição, você pode usar o comando "su" (seguido da
senha) para virar root. No caso do Ubuntu, além do Kurumin e outras distribuições derivadas
do Knoppix, você pode usar também o "sudo".
Os componentes do sistema
Todas as coisas grandes começam pequenas e com o Linux não foi diferente. Para entender
melhor os componentes que formam o sistema, nada melhor do que falar um pouco sobre a
história do Linux, sobre como e por que eles foram introduzidos, e entender o processo de
inicialização do sistema.
Kernel
Tudo começou em 1991, com a primeira versão do Kernel disponibilizada por Linus Torvalds. O
"Freax" (renomeado para "Linux" pelo responsávelpelo FTP onde o arquivo foi disponibilizado,
uma alma sábia e caridosa :) ainda estava na versão 0.02 e era um sistema monolítico, um
grande bloco de código que, além do núcleo do sistema, continha drivers de dispositivos e
tudo mais.
Para compilar o código fonte do Kernel, era necessário usar o Minix, outro sistema baseado em
Unix que na época era bastante popular entre os estudantes. Você começava compilando o
Kernel e em seguida algumas ferramentas básicas como o gerenciador de boot, o bash (o
interpretador de comandos) e o gcc (o compilador). A partir de um certo ponto, você podia dar
boot no próprio Linux e compilar os demais programas a partir dele mesmo.
Os primeiros aplicativos a rodarem sobre o Linux foram justamente ferramentas de
desenvolvimento, como o Emacs, e emuladores de terminal, usados para acessar outras
máquinas Unix remotamente.
Nesta época começaram a surgir as primeiras "distribuições" Linux, na forma de projetos
amadores, onde alguém gravava o sistema compilado em um conjunto de disquetes e tirava
cópias para os amigos.
Este procedimento de usar outro sistema operacional instalado para compilar uma instalação
do Linux é de certa forma usada até hoje para gerar versões do sistema destinadas a serem
usadas em dispositivos embarcados, como palms e celulares. Neles você usa uma cópia do
Linux instalada num PC para "montar" o sistema que vai rodar no dispositivo, compilando
primeiro o Kernel e depois os demais aplicativos necessários, deixando para finalmente
transferir para o dispositivo no final do processo. Isto é chamado de "cross-compiling".
Atualmente o Kernel, junto com vários aplicativos, pode ser compilado para rodar em várias
plataformas diferentes. O código fonte do Kernel, disponível nohttp://kernel.org (e diversos
mirrors), inclui o código necessário para gerar um Kernel para qualquer arquitetura suportada.
Na verdade, quase 95% do código Kernel é independente da arquitetura, por isso portar o
Kernel para uma nova plataforma é um trabalho relativamente simples (pelo menos se
levarmos em conta a complexidade do código envolvido). As partes que mudam de uma
arquitetura a outra são organizadas na pasta "/usr/src/linux/arch/".
Ainda assim, e um trabalho complexo e tedioso, muitas coisas precisam ser ajustadas e é
necessário encontrar programas específicos, que se ajustem à configuração de hardware da
plataforma alvo. Você pode rodar Linux num celular com 2 MB de memória, mas com certeza
não vai conseguir rodar o Firefox nele. Vai precisar encontrar um navegador mais leve, que
rode confortavelmente com pouca memória e a tela minúscula do aparelho.
Aqui temos um screenshot do Familiar, uma distribuição Linux para o Ipaq, que pode ser
instalado em substituição ao Pocket PC Windows, que vem originalmente instalado. Veja que
ele é bem diferente das distribuições para micros PC:
Você pode entender melhor sobre como isto funciona instalando o "Linux from Scratch", uma
distribuição Linux que pode ser toda compilada manualmente a partir dos pacotes com código
fonte, disponível no: http://www.linuxfromscratch.org/.
Voltando à história, no início o projeto ainda não tinha muita utilidade prática. O conjunto de
aplicativos que rodava no sistema era pequeno. Era muitomais fácil usar o Minix, ou, se você
tivesse condições financeiras, uma versão comercial do Unix, como o SunOS, que mais tarde
deu origem ao Solaris e ao OpenSolaris.
O que fez com que o Linux crescesse até o ponto em que está hoje foi principalmente o fato de
não apenas o código fonte do sistema ser aberto e estar disponível, mas também a forma
aberta como o sistema foi desenvolvido desde o início.
É normal encontrar muitos problemas e deficiências ao tentar usar um software em estágio
primário de desenvolvimento. Se você for um programador, vai acabar dando uma olhada no
código e fazendo algumas modificações. Se você estiver desenvolvendo algum projeto
parecido, é provável que você resolva aproveitar algumas idéias e pedaços de código para
implementar alguma nova função e assim por diante.
No caso do Linux, estas modificações eram bem-vindas e acabavam sendo incluídas no sistema
muito rapidamente. Isto criou uma comunidade bastante ativa, gente usando o sistema nos
mais diversos ambientes e ajudando a torná-lo adequado para todo tipo de tarefa.
Inicialmente era tudo um grande hobby. Mas logo o sistema começou a ficar maduro o
suficiente para concorrer com as várias versões do Unix e, mais tarde, também com o
Windows, inicialmente nos servidores, depois nos dispositivos embarcados e finalmente no
desktop. Com isso, mesmo grandes empresas como a IBM e a Novell começaram a contribuir
com o desenvolvimento do Kernel, a fim de tornar o sistema mais robusto e adicionar recursos
necessários para uso em diversas tarefas.
Este modelo é diferente do adotado pela Microsoft, por exemplo, que vende caixinhas do
Windows e Office. Estas empresas ganham mais vendendo soluções, onde é fornecido um
pacote, com o sistema operacional, aplicativos, suporte e garantias.
Neste caso, faz sentido contribuir para a construção de uma base comum (o Kernel) pois, no
final, sai muito mais barato do que investir em um sistema próprio. A partir desta base
comum, as empresas podem diferenciar-se das demais investindo nos outros componentes do
pacote. Usar Linux acaba virando então uma questão de competitividade: outra empresa que
resolvesse desenvolver um sistema próprio sairia em desvantagem, pois precisaria investir
muito tempo e dinheiro para chegar no mesmo nível dos outros.
Originalmente, o termo "Linux" era usado especificamente com relação ao Kernel
desenvolvido por Linus Torvalds. Mas, hoje em dia, é mais comum nos referirmos à plataforma
como um todo, incluindo o Kernel, ferramentas e aplicativos. Muitos dos aplicativos que
usamos hoje no Linux vieram de outras versões do Unix e este fluxo continua até hoje, nos dois
sentidos.
O Kernel é a base do sistema. Ele controla o acesso à memória, ao HD e demais componentes
do micro, dividindo os recursos disponíveis entre os programas. Todos osdemais programas,
desde os aplicativos de linha de comando, até os aplicativos gráficos rodam sobre o Kernel.
Imagine, por exemplo, que você está desenvolvendo um aplicativo de edição de áudio. Você
precisa incluir no seu programa várias funções de edição, filtros e assim por diante. Mas, você
não precisa se preocupar diretamente em oferecer suporte aos diferentes modelos de placas
de som que temos no mercado, pois o Kernel cuida disso.
Ao tocar um arquivo de áudio qualquer, o seu programa precisa apenas mandar o fluxo de
áudio para o device "/dev/dsp". O Kernel recebe o fluxo de áudio e se encarrega de enviá-lo à
placa de som. Quando é preciso ajustar o volume, seu programa acessa o dispositivo
"/dev/mixer", e assim por diante.
Naturalmente, uma Sound Blaster Live e uma placa AC'97 onboard, por exemplo, oferecem
conjuntos diferentes de recursos e se comunicam com o sistema de uma forma particular, ou
seja, falam línguas diferentes. Por isso o Kernel inclui vários intérpretes, os drivers de
dispositivo.
Driver em inglês significa "motorista" ou, "controlador". Cada chipset de placa de som, vídeo,
rede ou modem possui um driver próprio.
Podemos dizer que os módulos são as partes do Kernel mais intimamente ligadas ao hardware.
Os módulos são as partes do Kernel que mudam de máquina para máquina. Depois vem o
bloco principal, "genérico" do Kernel.
Sobre ele roda o shell, o interpretador de comandos responsável por executar os aplicativos de
modo texto e servidores, como o Samba e o Apache. Estes aplicativos são independentes do
modo gráfico, você não precisa manter o X aberto para instalar e configurar um servidor
Samba, por exemplo, embora as ferramentas gráficas possam ajudar bastante na etapa de
configuração.
Quando você executa o comando "cat arquivo.txt", porexemplo, o bash entende que deve
usar o programa "cat" para ler o "arquivo.txt". O Kernel oferece uma série de serviços e
comandos que podem ser usados pelos aplicativos. Neste caso, o bash dá a ordem para que o
executável "cat", junto com o arquivo sejamcarregados na memória.
Para que isso aconteça, o Kernel precisa ler os dois arquivos no HD e carregá-los na memória
RAM. No processo são usadas chamadas de vários módulos diferentes, como o responsável
pelo acesso à porta IDE onde o HD está conectado, o responsável pelo sistema de arquivos em
que o HD está formatado e o módulo responsável pelo suporte ao controlador de memória da
placa-mãe.
No caso de programas muito grandes, a memória RAM pode ficar lotada, obrigando o Kernel a
usar o subsistema de memória virtual para gravar as informações excedentes na partição
swap.
Só depois de tudo isso que o "cat" pode ser executado e mostrar o conteúdo do arquivo na
tela (usando mais um comando do Kernel, que aciona a placa de vídeo). Graças ao trabalho do
Kernel, você não precisa se preocupar com nada disso, apenas com os programas que precisa
executar.
Depois vem o X, o servidor gráfico, responsável por acessar a placa de vídeo e mostrar imagens
no monitor. Ele serve como base para os aplicativos gráficos, que podem ser divididos em duas
categorias. Primeiro temos os gerenciadores, como o KDE e o Gnome, que são responsáveis
por gerenciar as janelas, mostrar a barra de tarefas e assim por diante. Eles servem como uma
base para que você possa abrir e controlar os demais aplicativos gráficos.
Mesmo dentro do modo gráfico, você continua tendo acesso aos recursos do modo texto.
Programas como o Xterm e o Konsole são usados para rodar uma instância do bash dentro do
modo gráfico, permitindo executar todos os aplicativosde linha de comando e scripts. Ou seja,
o X roda com uma perna no Kernel e outra no interpretador de comandos.
Módulos
Como vimos, uma das tarefas mais importantes do Kernel é oferecer suporte ao hardware da
máquina.
No começo, a questão era mais simples, pois não existiam periféricos USB, softmodems e
muito menos placas wireless. O Kernel oferecia suporte apenas aos dispositivos mais
essenciais, como HD, placa de vídeo e drive de disquetes.
Com o tempo, foi sendo adicionado suporte a muitos outros dispositivos: placas de som, placas
de rede, controladoras SCSI, e assim por diante. O fato do Kernel ser monolítico começou a
atrapalhar bastante.
Você podia escolher os componentes a ativar na hora de compilar o Kernel. Se você habilitasse
tudo, não teria problemas com nenhum dispositivo suportado, tudo iria funcionar facilmente.
Mas, por outro lado, você teria um Kernel gigantesco, que rodaria muito devagar no seu 486
com 8 MB de RAM.
Se, por outro lado, você compilasse um Kernel enxuto e esquecesse de habilitaro suporte a
algum recurso necessário, teria que recompilar tudo de novo para ativá-lo.
Este problema foi resolvido durante o desenvolvimento do Kernel 2.0, através do suporte a
módulos. Os módulos são peças independentes que podem ser ativadas oudesativadas com o
sistema em uso. Do Kernel 2.2 em diante, quase tudo pode ser compilado como módulo.
Isso tornou as coisas muito mais práticas, pois passou ser possível compilar um Kernel com
suporte a quase tudo, com todas as partes não essenciais compiladas como módulos. O Kernel
em si é um executável pequeno, que consome pouca RAM e roda rápido, enquanto os
módulos ficam guardados numa pasta do HD até que você precise deles.
Você podia carregar o módulo para a SoundBlaster 16 (do 486 que você usava na época ;-) por
exemplo, com um:
# modprobe sb
E descarregá-lo com um:
# modprobe -r sb
Esta idéia dos módulos deu tão certo que é usada até hoje e num nível cada vez mais extremo.
Para você ter uma idéia, no Kernel 2.6 até mesmo o suporte a teclado pode serdesativado ou
compilado como módulo, uma modificação que parece besteira num PC, mas que é útil para
quem desenvolve versões para roteadores e outros dispositivos que realmente não possuem
teclado.
As distribuições passaram então a vir com versões do Kernel cada vez mais completas,
incluindo em muitos casos um grande número de patches para adicionar suporte a ainda mais
dispositivos, naturalmente quase tudo compilado como módulos.
Nas distribuições atuais, o hardware da máquina é detectado durante a instalação e o sistema
é configurado para carregar os módulos necessários durante o boot. Isto pode ser feito de
duas formas:
1- Os módulos para ativar a placa de som, rede, modem e qualquer outro dispositivo "não
essencial" são especificados no arquivo "/etc/modules". Programas de detecção, como o
hotplug e o udev ficam de olho nas mensagens do Kernel e carregam módulos adicionais
conforme novos dispositivos (uma câmera digital USB, em modo de transferência, por
exemplo) são detectados.
Sua placa de som seria ativada durante o boot através de um módulo especificado no
"/etc/modules", assim como o suporte genérico a dispositivos USB. Mas, o seu pendrive, que
você pluga e despluga toda hora é ativado e desativado dinamicamente através da detecção
feita pelo hotplug ou udev.
A detecção de novos periféricos (principalmente ao usar o Kernel 2.6) é muito simplificada
graças ao próprio Kernel, que gera mensagens sempre que um novo dispositivo é encontrado.
Você pode acompanhar este log rodando o comando "dmesg". Por exemplo, ao plugar um
pendrive USB, você verá algo como:
usb 2-2: new high speed USB device using address
scsi1 : SCSI emulation for USB Mass Storage devices
Vendor: LG CNS Model: Rev: 1.00
Type: Direct-Access ANSI SCSI revision: 02
SCSI device sda: 249856 512-byte hdwr sectors (128 MB)
sda: Write Protect is off
sda: Mode Sense: 03 00 00 00
sda: assuming drive cache: write through
sda: sda1
Attached scsi removable disk sda at scsi1, channel 0, id 0, lun 0
Attached scsi generic sg0 at scsi1, channel 0, id 0, lun 0, type 0
USB Mass Storage device found at 5
Veja que aqui estão quase todas as informações referentes a ele. O fabricante (LG), o
dispositivo pelo qual ele será acessado pelo sistema (sda), a capacidade (128 MB) e até as
partições existentes (neste caso uma única partição, nomeada "sda1").
Um segundo arquivo, o "/etc/modules.conf" (ou "/etc/modprobe.conf", dependendo da
distribuição usada), especifica opções e parâmetros para os módulos, quando necessário. Este
arquivo normalmente é gerado automaticamentepelas ferramentas de detecção de hardware
ou ao rodar o comando "update-modules", mas pode também ser editado manualmente, caso
necessário.
Outra peça importante é o arquivo "/lib/modules/2.6.x/modules.dep", que guarda uma tabela
com as dependências dos módulos, ou seja, de quais outros módulos cada um precisa para ser
carregado corretamente. Este último arquivo é gerado automaticamente ao rodar o comando
"depmod -a". Em geral, este comando é executado de forma automática durante o boot,
sempre que necessário. O "2.6.x" neste caso corresponde à versão do Kernel usado na sua
máquina.
2- Se o suporte a algo essencial nas etapas iniciais do boot não está incluído no Kernel, é criado
um initrd, uma imagem com os módulos necessários, que, diferentemente dos módulos
especificados no "/etc/modules", são carregados logo no início do boot. O initrd é guardado na
pasta /boot, junto com o executável principal do Kernel: o arquivo "vmlinuz".
Imagine, por exemplo, que você está usando uma distribuição onde o suporte ao sistema de
arquivos ReiserFS foi compilado como módulo, mas quer instalar o sistema justamente numa
partição ReiserFS.
Isso gera um problema do tipo o ovo e a galinha, já que o sistema precisa do módulo para
acessar a partição, mas precisa de acesso à partição para poder ler o módulo.
Para evitar este tipo de problema, o próprio instalador da distribuição, ao perceber que você
formatou a partição raiz em ReiserFS, vai se encarregar de gerar o arquivo initrd que, embora
não seja obrigatório (é possível compilar tudo diretamente no Kernel), é bastante usado.
Os processos de boot e os arquivos de inicialização
Quando você liga o micro, o primeiro software que é carregado é oBIOS da placa-mãe, que faz
a contagem da memória RAM, uma detecção rápida dos dispositivos instalados e por fim
carrega o sistema operacional principal a partir do HD, CD-ROM, disquete, rede, ou o que quer
que seja. Este procedimento inicial é chamado dePOST (Power-on self test)
Seria bom se a função do BIOS se limitasse a isso, mas na verdade ele continua residente,
mesmo depois que o sistema operacional é carregado.
Na época do MS-DOS era bem conhecida a divisão entre a memória real (os primeiros 640 KB
da memória RAM) e a memória extendida (do primeiro MB em diante, englobando quase toda
a memória instalada). O MS-DOS rodava em modo real, onde o processador trabalha
simulando um 8088 (o processador usado no XT) que era capaz de acessar apenas 640 KB de
memória. Mesmo os processadores modernos conservam este modo de operação, mas os
sistemas operacionais atuais rodam inteiramente em modo protegido, onde são usados todos
os recursos da máquina.
O espaço entre os primeiros 640 KB, onde termina a memória real, e os 1024 KB, onde começa
a memória extendida, é justamente reservado para o BIOS da placa-mãe.
Ele é originalmente gravado de forma compactada num chip de memória flash instalado na
placa-mãe. Durante o processo de boot ele é descompactado e copiado para este espaço
reservado (chamado de shadow RAM), onde fica disponível.
O BIOS oferece funções prontas para acessar o HD, acionar recursos de gerenciamento de
energia e muitas outras coisas. Mas, os sistemas operacionais quase não utilizam estas
funções, pois existem muitas diferenças na forma como BIOS de diferentes placas-mãe
trabalham e, em muitos casos, as funções simplesmente não funcionam ou produzem erros
inesperados.
Os fabricantes de placas-mãe disponibilizam upgrades de BIOS freqüentemente para corrigir
estes problemas, mas a maior parte dos usuários nem chega a procurá-los, fazendo com que
exista um enorme contingente de placas bugadas por aí, com problemas no ACPI, DMA e
outros recursos básicos.
Existe até mesmo um projeto para substituir o BIOS da placa-mãe por uma versão compacta
do Kernel do Linux, que executa as mesmas funções, mas de uma forma mais confiável e
flexível. Você pode obter mais informações sobre ele no: http://www.linuxbios.org/.
Outra tecnologia (já em uso) que substitui o BIOS é o EFI (Extensible Firmware Interface),
usada em placas-mãe para o Intel Itanium e também nos Macs com processadores Intel. O EFI
utiliza uma arquitetura modular, bem mais limpa e eficiente, que permite o uso de módulos
personalizados para os dispositivos de cada-placa mãe, mantendo (opcionalmente)
compatibilidade com o sistema antigo.
No caso dos Macs, esta camada de compatibilidade é desativada (de forma a dificultar a vida
de quem pretende instalar Linux ou windows em dual boot com o MacOS) mas, no caso de
placas avulsas, o EFI viria com o modo de compatibilidade ativado, permitindo rodar qualquer
sistema.
De qualquer forma, depois de fazer seu trabalho, o BIOS carrega o sistema operacional, lendo
o primeiro setor do disco rígido o "Master Boot Record" (MBR), também conhecido como
trilha zero ou trilha MBR.
No MBR vai o gerenciador de boot. Os dois mais usados no Linux são o lilo e o grub.
Na verdade, no MBR mesmo vai apenas um bootstrap, um pequeno software que instrui o
BIOS a carregar o executável do lilo ou grub em um ponto específico do HD. O MBR
propriamente dito ocupa um único setor do HD (apenas 512 bytes), de modo que não é
possível armazenar muita coisa diretamente nele.
O gerenciador de boot utiliza os primeiros 446 bytes do MBR. Os 66 bytes restantes são usados
para armazenar a tabela de partições, que guarda informações sobre onde cada partição
começa e termina. Alguns vírus, além de acidentes em geral, podem danificar os dados
armazenados na tabela de partição, fazendo com que pareça que o HD foi formatado. Mas, na
maioria dos casos, os dados continuam lá.
Mais adiante, veremos como fazer um backup da tabela de partições e restaurá-la quando
necessário.
Voltando ao tema inicial, o gerenciador de boot tem a função de carregar o Kernel e, a partir
dele, todo o restante do sistema. O lilo e o grub podem ser configurados ainda para carregar o
Windows ou outros sistemas instalados em dual boot. Muitas distribuições configuram isso
automaticamente durante a instalação.
Inicialmente, o Kernel é um arquivo compactado e somente-leitura, o arquivo
"/boot/vmlinuz". Ele é descompactado em uma área reservada da memória RAM e roda a
partir daí, aproveitando o fato de quea memória RAM é muito mais rápida que o HD.
Este executável principal do Kernel nunca é alterado durante o uso normal do sistema, ele
muda apenas quando você recompila o Kernel manualmente ou instala uma nova versão.
Se você prestou atenção quando citei anecessidade de usar uminitrd quando a partição raiz
do sistema está formatada num sistema de arquivos que não está compilado diretamente no
Kernel, deve ter notado uma contradição aqui. Afinal é o que está sendo feito até agora.
Nem o BIOS, nem o lilo possuem suporte a ReiserFS e o Kernel precisa ser carregado antes que
ele tenha a chance de carregar o initrd. E, além do mais, para carregar o initrd, o próprio
Kernel precisaria ler o arquivo dentro da partição.
Isto tudo funciona porque tanto o BIOS quanto o lilo não procuram entender o sistema de
arquivos em que o HD está formatado. Pode ser EXT2, ReiserFS, XFS, ou o que seja: para eles
não faz diferença. Eles simplesmente lêem os uns e zeros gravados numa área específica do HD
e assim carregam o Kernel e o initrd. Eles não fazem alterações nos dados gravados, por isso
este "acesso direto" não traz possibilidade de danos às estruturas do sistema de arquivos.
Depois de carregado, a primeira coisa que o Kernel faz é montar a partição raiz, onde o sistema
está instalado, inicialmente como somente-leitura. Neste estágio ele carrega o init, o software
que inicia o boot normal do sistema, lendo os scripts de inicialização e carregando os módulos
e softwares especificados neles.
O arquivo de configuração do init éo "/etc/inittab". Ele é geralmente o primeiro arquivo de
configuração lido durante o boot. A principal tarefa dele é carregar os demais scripts de
inicialização, usados para carregar os demais componentes do sistema e fazer todas as
operações de checagem, necessárias durante o boot.
No /etc/inittab do Debian por exemplo, você verá a linha:
# Boot-time system configuration/initialization script.
si::sysinit:/etc/init.d/rcS
Esta linha executa o script "/etc/init.d/rcS". Se você examiná-lo também, vai encontrar o
seguinte:
for i in /etc/rcS.d/S??*
do
...
$i start
....
done
Os "..." indicam partes dos script que removi para deixar apenas as partes que interessam aqui.
Estas linhas são um shell script, que vai executar os scripts dentro da pasta "/etc/rcS.d/". Esta
pasta contém scripts que devem ser executados sempre, a cada boot, e são responsáveis por
etapas fundamentais do boot.
Alguns exemplos de scripts e programas executados nesta etapa são:
keymap.sh: Carrega o layout do teclado que será usado no modotexto. Você não gostaria de
encontrar seu teclado com as teclas trocadas para o Russo quando precisar arrumar qualquer
coisa no modo texto, não é? ;-), O KDE possui um configurador próprio, o kxkb, que é
configurado dentro do Painel de Controle. O layout usado pelo kxkb subscreve o configurado
pelo keymap.sh dentro do KDE.
checkroot.sh: Este script roda o fsck, reiserfsck ou outro programa adequado para verificar a
estrutura da partição raiz (a partição onde o sistema está instalado), corrigindo erros causados
por desligamentos incorretos do sistema. Este processo é análogo ao scandisk do Windows. Só
depois da verificação é que a partição raiz passa a ser acessada em modo leitura e escrita.
modutils: Este é o script que lê os arquivos "/etc/modules" e "/etc/modules.conf", ativando a
placa de som, rede e todos os outros dispositivos de hardware "não essenciais", para os quais
o suporte não foi habilitado diretamente no Kernel. Atualmente, a maioria das distribuições
inclui alguma ferramenta de detecção de hardware, que é executada a cada boot, fazendo com
que o arquivo "/etc/modules" sirva apenas para especificar manualmente módulos que ativem
periféricos que não estejam sendo detectados automaticamente.
checkfs.sh: Este script é parecido com o checkroot.sh. Ele se destina a checar as demais
partições do HD.
mountall.sh: É aqui que é lido o arquivo "/etc/fstab" e as demais partições, unidades de rede,
e tudo mais que estiver especificado nele é ativado. Se você estiver usando uma partição
home separada ou um compartilhamento de rede via NFS para guardar arquivos, por exemplo,
é a partir deste ponto que eles ficarão disponíveis.
networking: Ativa a rede, carregando a configuração de IP, DNS, gateway, etc., ou obtendo a
configuração via DHCP. A configuração da redeé geralmente armazenada dentro da pasta
"/etc/sysconfig/network-scripts/" ou no arquivo "/etc/network/interfaces", variando de
acordo com a distribuição usada.
De acordo com a distribuição usada, são carregados neste ponto outros serviços, para ativar
suporte a placas PCMCIA, placas ISA, ou outros tipos de hardware, ativar o suporte a
compartilhamentos de rede e, assim por diante. É possível executar praticamente qualquer
tipo de comando ou programa nesta etapa, justamente por isso os passos executados durante
o boot mudam de distribuição para distribuição, de acordo com o que os desenvolvedores
consideram mais adequado. A idéia aqui é apenas dar uma base, mostrando alguns passos
essenciais que são sempre executados.
Depois desta rodada inicial, são executados os scripts correspondentes ao runlevel padrão do
sistema, que é configurado no "/etc/inittab", na linha:
# The default runlevel.
id:5:initdefault:
O número (5 no exemplo) indica o runlevel que será usado, que pode ser um número de 1 a 5.
Cada runlevel corresponde a uma pasta, com um conjunto diferente de scripts de inicialização.
É uma forma de ter vários "profiles", para uso do sistema em diferentes situações.
A configuração mais comum é a seguinte:
Runlevel 1: Single user. É um modo de recuperação onde nem o modo gráfico, nem o suporte
à rede, nem qualquer outro serviço "não essencial" é carregado, de forma a minimizar a
possibilidade de problemas. A idéia é que o sistema "dê boot" para que você possa corrigir o
que está errado. Atualmente, uma forma mais prática para corrigir problemas é dar boot com
uma distribuição em live-CD (como o Kurumin), onde você tem acesso à internet e vários
programas e, a partir dele, montar a partição onde o sistema está instalado e corrigir o
problema.
Runlevel 3: Boot em modo texto. Neste modo todos os serviços são carregados, com exceção
do gerenciador de boot (KDM ou GDM), que é responsável por carregar o modo gráfico. Este
modo é muito usado em servidores.
Runlevel 5: É o modo padrão na maioria das distribuições, onde você tem o sistema
"completo", com modo gráfico e todos os demais serviços. Uma exceção importante é o
Slackware, onde o modo gráfico é carregado no runlevel 4.
Usando o runlevel 5, são carregados os scripts dentro da pasta "/etc/rc5.d/", enquanto que,
usando o runlevel 3, são carregados os scripts dentro da pasta "/etc/rc3.d/". Nada impede que
você modifique a organização dos arquivos manualmente, de forma a fazer o X carregar
também no runlevel 3, ou qualquer outra coisa que quiser. São apenas pastas com scripts e
links simbólicos dentro, nenhuma caixa preta.
Ativando e desativando serviços
Nas distribuições que seguem o padrão do Debian, os executáveis que iniciam os serviços de
sistema ficam todos dentro da pasta "/etc/init.d/". Para parar, iniciar ou reiniciar o serviço ssh,
por exemplo, use os comandos:
# /etc/init.d/ssh start
# /etc/init.d/ssh stop
# /etc/init.d/ssh restart
No Kurumin, Mandriva e algumas outras distribuições, existe o comandoservice, que facilita
um pouco as coisas, permitindo que, ao invés de ter de digitar o caminho completo, você
possa controlar os serviços através dos comandos:
# service ssh start
# service ssh stop
# service ssh restart
Os scripts que estão na pasta "/etc/init.d/" servem para "chamar" os executáveis dos
servidores. Eles apenas fazem as verificações necessárias e em seguida inicializam ou encerram
os executáveis propriamente ditos, que em geral estão na pasta "/usr/bin/" ou "/usr/sbin/".
A pasta "/etc/init.d/" contém scripts para quase todos os serviços queestão instalados no
sistema. Quando você instala o Samba pelo apt-get, por exemplo, é criado o script
"/etc/init.d/samba", mesmo que ele não exista anteriormente.
O que determina se o Samba será executado ou não durante o boot não é o script na pasta
"/etc/init.d/", mas sim um link simbólico criado dentro de uma das pastas de inicialização.
Por padrão, são executados primeiro os links que estão dentro da pasta"/etc/rcS.d/" e, em
seguida, o que estiver dentro da pasta "/etc/rc5.d/" (caso o sistema esteja configurado para
inicializar em runlevel 5, padrão na maioria das distribuições) ou na pasta "/etc/rc3.d/"
(runlevel 3).
Os números antes dos nomes dos serviços dentro da pasta "/etc/rc5.d/" determinam a ordem
em que eles serão executados. Você vai querer que o firewall seja sempre ativado antes do
Samba por exemplo.
O "S" (start) indica que o serviço será inicializado no boot. A partir daí, o sistema vai
inicializando um por vez, começando com os serviços com número mais baixo. Caso dois
estejam com o mesmo número, eles são executados em ordem alfabética.
Para que um determinado serviço pare de ser inicializado automaticamente no boot, basta
deletar a entrada dentro da pasta, como em:
# rm -f /etc/rc5.d/S20samba
Para que o serviço volte a ser inicializado você deve criar novamente o link, apontando para o
script na pasta /etc/init.d, como em:
# cd /etc/rc5.d/
# ln -s ../init.d/samba S20samba
ou:
# ln -s ../init.d/ssh S21ssh
Esta é a forma "correta" de criar os links: acessando primeiro a pastaonde eles são criados e
criando os links com as localizações relativas. Se estamos na pasta "/etc/rc5.d" e criamos o link
apontando para "../init.d/samba", significa que o sistema vai subir um nível de diretório (vai
para o /etc) e em seguida acessa a pasta "init.d/".
Nada impede que você crie o link diretamente, como em:
# ln -s /etc/init.d/ssh /etc/rc5.d/S21ssh
Ele vai funcionar da mesma forma, mas ferramentas de configuração automática, como o
"update-rc.d" (do Debian), vão reclamar do "erro" ao atualizar ou remover o link. Este é, na
verdade, um daqueles casos em que precisamos contornar manualmente a falta de recursos
da ferramenta.
Existe um utilitário de modo texto, do Debian, que facilita esta tarefa, o rcconf, que pode ser
instalado via apt-get. Chamando-o com a opção "--now", os serviços marcados são inicializados
imediatamente, caso contrário ele apenas cria os links, de forma que eles fiquem ativos a
partir do próximo boot.
No Fedora, Mandriva e outras distribuições derivadas do Red Hat, você pode ativar ou
desativar a inicialização dos serviços no boot usando o comando "chkconfig", como em:
# chkconfig ssh on
(ativa)
# chkconfig ssh off
(desativa)
Você pode também usar o utilitário "ntsysv" ou outro configurador disponível. O Mandriva,
por exemplo, inclui um painel de administração de serviços dentro do Mandriva Control
Center. Muitas distribuições incluem o "services-admin", outro utilitário gráfico que faz parte
do pacote "gnome-system-tools".
X
Diferentemente do que temos no Windows, onde a interface gráfica é um componente
essencial do sistema, no Linux o modo gráfico é uma camada independente. Temos um
"servidor gráfico", o famoso X que provê a infra-estrutura necessária. É ele que controla o
acesso à placa de vídeo, lê as teclas digitadas noteclado e os clicks do mouse e oferece todos
os recursos necessários para os programas criarem janelas e mostrarem conteúdo na tela.
Se você chamar o X sozinho, a partir do modo texto (o que pode ser feito com o comando "X"
ou "X :2" caso você queira abrir uma segunda seção do X), você verá apenas uma tela cinza,
com um X que representa o cursor do mouse. Ou seja, o X é apenas uma base, ele sozinho não
faz muita coisa.
Se você chamá-lo com o comando "xinit" ou "xinit -- :2", você já abrirá junto uma janela de
terminal, que poderá ser usada para abrir programas. Porém, ao abrir qualquer programa
gráfico, você perceberá que algo está estranho. A janela do programa é aberta, mas fica fixa na
tela, você não tem como minimizá-la, alternar para outra janela, nem nenhuma outra opção:
Isto acontece porque estas tarefas são controladas pelo gerenciador de janelas, que (em quase
todas as distribuições) não é carregado com o comando xinit. Existem vários gerenciadores de
janelas, como o KDE, Gnome, Window Maker, Fluxbox, IceWM e assim por diante. A idéia é
que você possa escolher qual lhe agrada mais.
Chamando o X através do comando "startx", ou configurando o sistema para carregar o X
automaticamente durante a inicialização, finalmente carregamos o conjunto completo,com o
X e algum gerenciador de janelas rodando sobre ele.
O Xfree utiliza uma arquitetura cliente-servidor, onde o X em si atua como o servidor e os
programas como clientes, que recebem dele os clicks do mouse e as teclas digitadas no teclado
e enviam de volta as janelas a serem mostradas na tela.
A grande vantagem deste sistema é que além de rodar programas localmente é possível rodar
programas instalados em outras máquinas da rede. Existem várias formas de fazer isto. Você
pode, por exemplo, abrir uma janela de terminal dentro do X, conectar-se à outra máquina, via
SSH e começar a chamar os programas desejados. Para isso, use o comando "ssh-X
IP_da_maquina", como em:
# ssh -X 192.168.0.1
O parâmetro -X ativa a execução de aplicativos gráficos via SSH, que vem desativado por
padrão em algumas distribuições. Para usar o ssh, o serviço "ssh" deve estar ativo na máquina
que está sendo acessada.
Outra opção é usar o XDMCP, o protocolo nativo do X para obter a tela de login da máquina
remota e a partir daí carregar um gerenciador de janelas e rodar todos os programas via rede.
Neste caso você precisaria configurar a outra máquina para aceitar as conexões via XDMCP nos
arquivos kdmrc e Xaccess, que vão dentro da pasta "/etc/kde3/kdm/" ou
"/usr/share/config/kdm/kdmrc" (ao usar o KDM) ou no gdmsetup (ao usar o GDM) e inicializar
o X com o comando "X :2 -query IP_da_maquina" no PC cliente, como em:
# X :2 -query 192.168.0.1
Muita gente diz que este sistema cliente/servidor do X é uma arquitetura ultrapassada, que é
responsável por um desempenho ruim se comparado com outros sistemas operacionais, pois
tudo teria que passar pela rede antes de ir para o monitor.
Esta idéia é errada, pois, ao rodar localmente, o X se comunica diretamente com a placa de
vídeo, usando todos os recursos de aceleração suportados. Entra aí a questão do driver. Se
você tentar rodar um game 3D qualquer, antes de instalar os drivers 3D (da nVidia) para sua
placa nVidia, por exemplo, ele vai rodar com um desempenho muito baixo, simplesmente
porque os recursos 3D da placa não estão ativados. O driver open-source do X para placas
nVidia (o driver "nv") oferece apenas suporte 2D.
Algumas placas realmente não possuem ainda drivers 3D no X, como, por exemplo, a maior
parte das placas onboard da SiS. Isto tem mais a ver com a boa vontade (ou falta desta) do
fabricante em desenvolver drivers ou pelo menos disponibilizar as especificações das placas. A
SiS é um dos fabricantes mais hostis, o que faz com que suas placas tenham um suporte ruim.
Como sempre é questão de pesquisar antes de comprar.
Os comandos de atualização das janelas e outros recursos usados são transmitidos pelo X
através de uma interface de rede local (a famosa interface de loopback), o que num PC
moderno tem um overhead muito pequeno. Os problemas de desempenho em algumas placas
estão mais relacionados à qualidade dos drivers.
Gerenciador de login
Antigamente, era muito comum dar boot em modo texto e deixar para abrir o X manualmente
rodando o comando "startx" apenas quando necessário, pois os PCs eram lentos e o X
demorava para abrir.
Atualmente, o mais comum é usar um gerenciador de login, como oKDM (do KDE) ou o GDM
(do Gnome). A função do gerenciador de login é carregar o X, mostrar uma tela de login gráfica
e, a partir dela, carregar o KDE, Gnome ou outro gerenciador de janelas escolhido.
Em geral, as distribuições que usam o KDE como interface padrão usam o KDM, enquanto as
que usam o Gnome preferem o GDM. Isto tem a ver com o problema das bibliotecas: ao
carregar apenas um programa baseado nas bibliotecas do KDE dentro do Gnome ou vice-versa,
são carregadas todas as bibliotecas correspondentes, não há o que fazer.O programa demora
mais para abrir, e no final, o sistema acaba consumindo muito mais memória.
O gerenciador de login é aberto como um serviço de sistema, da mesma forma que o Apache e
outros servidores. Você pode parar o KDM e assim fechar o modo gráficousando o comando
"/etc/init.d/kdm stop" e reabri-lo a partir do modo texto com o comando "/etc/init.d/kdm
start".
Como sempre, tudo é aberto através de um conjunto de scripts. O KDM guarda a base das
configurações no arquivo "/etc/kde3/kdm/kdmrc" (ou "/usr/share/config/kdm/kdmrc",
dependendo da distribuição) e coloca um conjunto de scripts de inicialização, um para cada
interface instalada, dentro da pasta "/usr/share/apps/kdm/sessions/".
A configuração do kdmrc serve para configurar as opções da tela de login, que vão desde
opções cosméticas, até a opção de aceitar que outras máquinas da rede rodem aplicativos
remotamente via XDMCP. Ao fazer login, é executado o script correspondente à interface
escolhida. Ao usar o Fluxbox, por exemplo, é executado o script
"/usr/share/apps/kdm/sessions/fluxbox".
Até mesmo o comando startx é um script, que geralmente vai na pasta "/usr/X11R6/bin/".
Você pode alterá-lo para carregar o que quiser, mas normalmente ele carrega o gerenciador
especificado no arquivo .xinitrc, dentro da pasta home do usuário.
Xfree e Xorg
Atualmente estão em uso no mundo Linux duas versões diferentes do X, oXfree e o X.org. O
Xfree é o projeto mais antigo e tradicional, o grupo que originalmente portou o X para o Linux,
e foi o principal mantenedor do projeto desde então.
Com o passar do tempo, começaram a surgir críticas, principalmente direcionadas à demora
para incluir correções e atualizações nos drivers existentes. Isto foi se agravando com o tempo,
até que uma decisão dos desenvolvedores em fazer uma pequena mudança na licença em
vigor a partir do Xfree 4.4 foi a gota d'água para que um consórcio formado por membros de
várias distribuições, desenvolvedores descontentes com o modo de desenvolvimento antigo,
se juntassem para criar um fork do Xfree, o X.org.
O X.org utilizou como base inicial a última versão de desenvolvimento da série 4.3 do Xfree,
disponibilizada antes da mudança da licença. Desde então, foram incluídas muitas atualizações
e correções, como novos drivers e vários recursos cosméticos, como, por exemplo, suporte a
janelas transparentes. A página oficial é a http://x.org.
Inicialmente, as diferenças eram pequenas, mas depois de um certo tempo o X.org passou a
concentrar a maior parte das atualizações enovos drivers, sendo desenvolvido num ritmo
muito mais rápido. A tendência é que ele substitua completamente o Xfree num futuro
próximo.
A partir da versão 7.0, o X.org passou a utilizar uma arquitetura modular, que visa facilitar o
desenvolvimento de novos recursos, que podem ser integrados ao sistema na forma de
módulos, sem depender do aval prévio dos desenvolvedores do X.org. Esta mudança, que à
primeira vista parece simples, tem potencial para intensificar o desenvolvimento de forma
radical.
Para quem configura, a principal diferença está nos nomes do arquivo de configuração e
utilitários. As opções dentro do arquivo continuam as mesmas, incluindo os nomes dos drivers
(radeon, nv, intel, sis, etc.) e é possível inclusive usar um arquivo de configuraçãode uma
distribuição com o Xfree em outra (instalada na mesma máquina) com o X.org. Aqui vai uma
pequena tabela com algumas diferenças:
- Arquivo de configuração principal:
/etc/X11/XF86Config-4 = /etc/X11/xorg.conf
- Utilitários de configuração:
xf86cfg = xorgfg
xf86config = xorgconfig
É possível também eliminar estas diferenças criando um conjunto de links apontando para os
nomes trocados. Assim o XF86Config-4 vira um link para o xorg.conf, por exemplo, fazendo
com que usuários desavisados e até utilitários de configuração consigam encontrar os arquivos
sem muitos problemas.
A árvore genealógica das distribuições
Por causa da filosofia de código aberto e compartilhamento de informações que existe no
mundo Linux, é muito raro que uma nova distribuição seja desenvolvida do zero. Quase
sempre as distribuições surgem como forks ou personalizações de uma outra distribuição mais
antiga e preservam a maior parte das características da distribuição original. Isso faz com que
distribuições dentro da mesma linhagem conservem mais semelhanças do que diferenças
entre si.
Das primeiras distribuições Linux, que surgiram entre 1991 e 1993, a única que sobrevive até
hoje é o Slackware, que deu origem a algumas outras distribuições conhecidas, como o Vector,
Slax e o College.
O Slax é um live-CD, desenvolvido para caber em um mini-CD; o Vector é uma distribuição
enxuta, otimizada para micros antigos, enquanto o College é uma distribuição desenvolvida
com foco no público estudantil, com o objetivo de ser fácil de usar.
Os três utilizam pacotes .tgz do Slackware e são quase sempre compatíveis com os pacotes do
Slackware da versão correspondente. Os utilitários de configuração do Slackware, como o
netconfig continuam disponíveis, junto com vários novos scripts que facilitam a configuração
do sistema. O Vector, por exemplo, inclui o Vasm, uma ferramenta central de configuração.
O Debian apareceu pouco depois e, ao longo dos anos, acabou dando origem a quase metade
das distribuições atualmente em uso. Algumas, como o Knoppix e o Kurumin, continuam
utilizando os pacotes dos repositórios Debian, apenas acrescentando novos pacotes e
ferramentas, enquanto outras, como o Lycoris e o Ubuntu, utilizam repositórios separados,
apenas parcialmente compatíveis com os pacotes originais, mas sempre mantendo o uso do
apt-get e a estrutura básica do sistema.
Embora o Debian não seja exatamente uma distribuição fácil de usar, o apt-get e o gigantesco
número de pacotes disponíveis nos repositórios formam uma base muito sólida para o
desenvolvimento de personalizações e novas distribuições.
Um dos principais destaques é que, nas versões Testing e Unstable, o desenvolvimento do
sistema é contínuo e, mesmo no Stable, é possível atualizar de um release para outro sem
reinstalar nem fazer muitas modificações no sistema. Você pode manter o sistema atualizado
usando indefinidamente o comando "apt-get upgrade". Isso permite que os desenvolvedores
de distribuições derivadas deixem o trabalho de atualização dos pacotes para a equipe do
Debian e se concentrem em adicionar novos recursos e corrigir problemas.
Um dos exemplos de maior sucesso é o Knoppix, que chega a ser um marco. Ele se tornou
rapidamente uma das distribuições live-CD mais usadas e deu origem a um universo
gigantesco de novas distribuições, incluindo o Kurumin. Uma coisa interessante é que o
Knoppix mantém a estrutura Debian quase intacta, o que fez com que instalar o Knoppix no HD
acabasse tornando-se uma forma alternativa de instalar o Debian. Outro exemplo de sucesso é
o Ubuntu, uma versão do Debian destinada a iniciantes e a empresas, que rapidamente se
transformou em umas das distribuições mais usadas no mundo.
As distribuições derivadas do Knoppix muitas vezes vão além, incluindo novos componentes
que tornam o sistema mais adequado para usos específicos. O Kurumin inclui muitas
personalizações e scripts destinados a tornar o sistema mais fácil de usar e mais adequado
para uso em desktop. O Kanotix inclui muitos patches no Kernel, com o objetivo de oferecer
suporte a mais hardware e novos recursos,enquanto o Morphix usa uma estrutura modular,
que acabou servindo de base para o desenvolvimento de mais uma safra de distribuições, já
bisnetas do Debian.
Mais adiante, teremos um capítulo dedicado a explicar o processo de personalização do
Kurumin e outros live-CDs derivados do Knoppix, permitindo que você desenvolva suas
próprias soluções.
Tanto o Debian quanto o Slackware são distribuições basicamente não comerciais. Mas isso
não impede que distribuições como o Lycoris, Xandros e Linspire sejam desenvolvidas por
empresas tradicionais, com fins lucrativos. Elas procuram se diferenciar das distribuições
gratuitas, investindo em marketing e no desenvolvimento de ferramentas de configuração e
facilidades em geral.
Durante o livro, vou sempre citar muitos comandos que se aplicam ao Debian, lembre-se de
que eles também se aplicam à outras distribuições derivadas dele, como o Ubuntu, Kurumin e
o Knoppix.
A terceira distribuição "mãe" é o Red Hat, que deu origem ao Mandrake e Conectiva (que mais
tarde se juntaram, formando o atual Mandriva), Fedora e, mais recentemente, a um enorme
conjunto de distribuições menores. As distribuições derivadas do Red Hat não utilizam um
repositório comum, como no caso do Debian, e nem mesmo um gerenciador de pacotes
comum. Temos o yun do Fedora, o urpmi do Mandriva e também o próprio apt-get, portado
pela equipe do Conectiva. Temos ainda vários repositórios independentes, que
complementam os repositórios oficiais das distribuições.
As distribuições derivadas do Red Hat são, junto com o Debian e derivados, as mais usadas em
servidores. O Fedora, Red Hat e SuSE possuem também uma penetração relativamente grande
nos desktops nas empresas, enquanto o Mandriva tem o maior público entre os usuários
domésticos.
Embora todas estas distribuições utilizem pacotes rpm, não existe garantia de compatibilidade
entre os pacotes de diferentes distribuições. Os pacotes de uma versão recente do SuSE na
maioria das vezes funcionam também numa versão equivalente do Mandriva, por exemplo,
mas isto não é uma regra.
O Gentoo inaugurou uma nova linhagem trazendo uma abordagem diferente das demais
distribuições para a questão da instalação de programas e instalação do sistema.
Tradicionalmente, novos programas são instalados através de pacotes pré-compilados, que
são basicamente arquivos compactados, contendo os executáveis, bibliotecas e arquivos de
configuração usados pelo programa. Estes pacotes são gerenciados pelo apt-get, urpmi, yun ou
outro gerenciador usado pela distribuição. Compilar programas a partir dos fontes é quase
sempre um último recurso para instalar programas recentes, que ainda não possuem pacotes
disponíveis.
O Gentoo utiliza o Portage, um gerenciador de pacotes que segue a idéia dos ports do
FreeBSD. Os pacotes não contém binários, mas sim o código fonte do programa, junto com um
arquivo com parâmetros que são usados na compilação. Você pode ativar as otimizações que
quiser, mas o processo de compilação e instalação é automático. Você pode instalar todo o
KDE, por exemplo, com um "emergekde". O Portage baixa os pacotes com os fontes (de forma
similar ao apt-get), compila e instala.
O ponto positivo desta abordagem é que você pode compilar todo o sistema com otimizações
para o processador usado na sua máquina. Isso resulta em ganhos de 2 a5% na maior parte
dos programas, mas pode chegar a 30% em alguns aplicativos específicos.
A parte ruim é que compilar programas grandes demora um bocado, mesmo em máquinas
atuais. Instalar um sistema completo, com o X, KDE e OpenOffice demora um dia inteiro num
Athlon 2800+ e pode tomar um final de semana numa máquina um pouco mais antiga. Você
pode usar o Portage também para atualizar todo sistema, usando os comandos "emerge sync
&& emerge -u world" de uma forma similar ao "apt-get upgrade" do Debian.
Nas versões atuais do Gentoo, você pode escolher entre diferentes modos de instalação. No
stage 1 tudo é compilado a partir dos fontes, incluindo o Kernel e as bibliotecas básicas. No
stage 2 é instalado um sistema base pré-compilado e apenas os aplicativos são compilados. No
stage 3 o sistema inteiro é instalado a partir de pacotes pré-compilados, de forma similar a
outras distribuições. A única exceção fica por conta do Kernel, que sempre precisa ser
compilado localmente, mesmo ao usar o stage 2 ou 3.
O stage 1 é naturalmente a instalação mais demorada, mas é onde você pode ativar
otimizações para todos os componentes do sistema.
Já existe um conjunto crescente de distribuições baseadas no Gentoo, como vários live-CDs,
com games e versões modificadas do sistema, alguns desenvolvidos pela equipe oficial, outros
por colaboradores. Uma das primeiras distribuições a utilizar o Gentoo como base foi o
Vidalinux.
Embora seja uma das distribuições mais difíceis, cuja instalação envolve mais trabalho manual,
o Gentoo consegue ser popular entre os usuários avançados, o que acabou por criar uma
grande comunidade de colaboradores em torno do projeto. Isto faz com que o Portage ofereça
um conjunto muito grande de pacotes, quase tantos quanto no apt-get do Debian, incluindo
drivers para placas nVidia e ATI, entre outros drivers proprietários, e exista uma grande
quantidade de documentação disponível, com textos quase sempre atualizados.
Capítulo 2: Configuração, ferramentas e dicas
A melhor forma de aprender é sempre praticando, certo? Este capítulo é uma coleção de dicas
sobre os arquivos de configuração, ferramentas e utilitários úteis, que tem o objetivo de
aprofundar seus conhecimentos sobre o sistema. Os tópicos estão organizados por nível de
dificuldade.
Editando o /etc/fstab
O arquivo "/etc/fstab" permite configurar o sistema para montar partições, CD-ROMs,
disquetes e compartilhamentos de rede durante o boot. Cada linha é responsável por um
ponto de montagem. É através do "/etc/fstab" que o sistema é capaz de acessar oseu CD-
ROM, por exemplo. O fstab é um dos arquivos essenciais para o funcionamento do sistema,
por isso, antes de editá-lo, faça sempre uma cópia de segurança:
# cp /etc/fstab /etc/fstab-original
O fstab é um arquivo de texto simples, assim como a maior parte dos arquivos de configuração
do sistema. Você pode abri-lo usando qualquer editor de textos, mas sempre como root:
# kedit /etc/fstab
À primeira vista o fstab parece ser mais um daqueles arquivos indecifráveis. Ele possui uma
lógica própria que pareceum pouco complicada no início, mas é relativamente fácil de
entender. Uma vez que você entenda a sintaxe das opções, você poderá editar o fstab para
adicionar um segundo drive de CD ou fazer com que um compartilhamento de rede seja
montado automaticamentedurante o boot, sem depender de configuradores automáticos.
Vamos começar dando uma olhada no "/etc/fstab" de uma máquina que está com o Kurumin
instalado na partição hda2:
# /etc/fstab: filesystem table.
# filesystem mountpoint type options dump pass
/dev/hda2 / reiserfs defaults 0 1
/dev/hda5 none swap sw 0 0
proc /proc proc defaults 0 0
/dev/fd0 /floppy vfat defaults,user,noauto,showexec,umask=022 0 0
/dev/cdrom /mnt/cdrom iso9660 defaults,ro,user,noexec,noauto 0 0
# partições encontradas pelo instalador:
/dev/hda1 /mnt/hda1 reiserfs noauto,users,exec 0 0
/dev/hda2 /mnt/hda2 reiserfs noauto,users,exec 0 0
/dev/hda3 /mnt/hda3 reiserfs noauto,users,exec 0 0
/dev/hda6 /mnt/hda6 reiserfs noauto,users,exec 0 0
# Monta a partição /home, adicionado pelo instalador do Kurumin
/dev/hda3 /home reiserfs notail 0 2
# Ativa o USB
usbdevfs /proc/bus/usb usbdevfs defaults 0 0
Este é o arquivo gerado automaticamente durante a instalação, por isso ele está um pouco
sujo. Vamos começar entendo o que cada linha significa.Lembre-se de que as linhas
começadas com # não fazem nada, são apenas comentários.
/dev/hda2 / reiserfs defaults 0 1
Esta linha monta o diretório raiz do sistema. No exemplo, o Kurumin está instalado na partição
/dev/hda2 que está formatada em ReiserFS. O"/" é o ponto de montagem, ou seja, onde esta
partição fica acessível. A barra indica que esta é a partição raiz, onde o sistema está instalado.
Se, por acaso, a partição estivesse formatada em outro sistema de arquivos, em EXT3, por
exemplo, a linha ficaria: "/dev/hda2 / ext3 defaults 0 1".
Os dois números depois do "defaults" são instruções para programas externos.
O primeiro número é usado pelo programadump, que examina a partição em busca de
arquivos modificados. Esta informação é usada por alguns programas de backup, para decidir
quais arquivos devem ser incluídos num backup incremental. O número0 desativa e o número
1 ativa a checagem.
O dump só trabalha em partições EXT2 ou EXT3, de forma que ao usar uma partição em
ReiserFS ou XFS você sempre deveusar o número 0.
O segundo número (1 no exemplo) é uma instrução para ofsck, encarregado de examinar os
arquivos dentro da partição quando o sistema é desligado incorretamente. Temos três opções
aqui: o número 0 desativa a checagem a cada boot (torna o boot um pouco mais rápido, mas
não é recomendável), enquanto o número1 faz com que a partição seja checada antes das
demais.
Usamos o número 1 apenas para a partição raiz, onde o sistema está instalado. Para as demais
partições usamos o número 2 que indica que a partição deve ser checada, porém só depois da
partição raiz.
/dev/hda5 none swap sw 0 0
Esta segunda linha é responsável por ativar a memória swap, que no meu caso é a partição
/dev/hda5. Veja que o ponto de montagem para ela é "none", pois apartição swap não é
montada em nenhuma pasta, ela serve apenas para uso interno do sistema.
/dev/cdrom /mnt/cdrom iso9660 defaults,user,noauto 0 0
Esta linha habilita o drive de CD-ROM. O /dev/cdrom é o dispositivo do CD-ROM, na verdade
um link que é criado durante a configuração inicial do sistema e aponta para a localização
correta do CD-ROM. De acordo com a porta em que o CD-ROM estiver instalado, o dispositivo
real do CD-ROM pode ser:
/dev/hdc: Um CD-ROM instalado como master na segunda porta IDE da placa-mãe.
/dev/hdd: CD-ROM instalado como slave na segunda porta IDE
/dev/sda ou /dev/sr0: Em distribuições que usam o Kernel 2.4, os gravadores de CD IDE são
detectados pelo sistema como se fossem discos SCSI. Dependendo da distribuição eles podem
ser detectados como "/dev/sda" ou "/dev/sr0". Caso você tenha dois gravadores, o segundo é
reconhecido como "/dev/sdb" ou "/dev/sr1". No Kernel 2.6, não é mais usada a emulação SCSI,
de forma que os gravadores são acessados diretamente através dos dispositivos "/dev/hdc" ou
"/dev/hdd".
/dev/sr0 ou /dev/sr1: Leitores e gravadores de CD USB também são detectados como CDs
SCSI. Ao plugar um drive externo ligado à porta USB, ele será detectado como "/dev/sr0" (ou
"/dev/sr1", caso a primeira posição já esteja ocupada). No caso dos leitores e gravadores USB,
não importa se está sendo usado o Kernel 2.4 ou 2.6.
Para que os arquivos do CD-ROM fiquem acessíveis, ele precisa ser montado em algum lugar. A
próxima entrada da linha é o "/mnt/cdrom", que indica a pasta onde ele fica acessível. O
iso9660 é o sistema de arquivos universalmente usado em CD-ROMs de dados, é graças a ele
que não existem problemas para ler o mesmo CD no Linux ou Windows.
Em seguida temos três opções: defaults,user,noauto. Elas fazem o seguinte:
user: Permite que você monte e desmonte o CD-ROM mesmo sem estar logado como root.
noauto: faz com que o CD-ROM seja montado apenas quando você for acessá-lo e não
automaticamente durante o boot, como no caso da partição raiz, por exemplo.
Caso você queira ativar um segundo drive de CD, adicionaria uma linha assim:
/dev/hdd /mnt/cdrom1 iso9660 defaults,user,noauto 0 0
Veja que mudaram duas coisas: o dispositivo do CD-ROM (/dev/hdd) e a pasta onde ele fica
acessível (/mnt/cdrom1). Para acessar o segundo CD-ROM, você digitaria "mount
/mnt/cdrom1"
O KDE oferece um recurso muito interessante que é a possibilidade de montar e desmontar as
entradas incluídas no /etc/fstab através de ícones no desktop, como os usados para acessar as
partições do HD ao rodar o Kurumin do CD.
Para criar um destes ícones, clique com o botão direito sobre a área de trabalho e vá em:
"Criar novo", escolha "Disco rígido ou CD-ROM" e aponte a entrada do fstab referente a ele
nas propriedades:
Para montar e acessar os arquivos, basta clicar sobreo ícone e para desmontar, clique com o
botão direito e escolha "desmontar".
A linha seguinte do arquivo serve para montar a partição home, que no exemplo foi colocada
em uma partição separada:
/dev/hda3 /home reiserfs notail 0 2
Traduzindo para o português, a linha diz: "Monte a partição /dev/hda3 no diretório /home.
Esta partição está formatada em reiserfs e você deve usar a opção notail".
O notail é uma opção do sistema de arquivos ReiserFS, que melhora um pouco a velocidade de
acesso ao trabalhar com arquivos grandes. Cada sistema de arquivos possui algumas opções
extras, que podem ser usadas para melhorar o desempenho ou tolerância a falhas em
determinadas situações. O parâmetro "noatime", por exemplo, faz com que o sistema não
atualize as propriedades dos arquivos conforme eles ao acessados (altera apenas quando eles
são modificados). Ela melhora absurdamente o desempenho do sistema em algumas áreas
específicas, onde os mesmos arquivos são acessados continuamente, como nos servidores de
banco de dados. É muito comum combinar as duas opções, como em:
/dev/hda3 /home reiserfs notail,noatime 0 2
Usar uma partição home separada permite que você possa reinstalar o sistema sem perder
seus arquivos e configurações, o que é especialmente interessante nocaso do Kurumin e
outras distribuições atualizadas freqüentemente.
Usando um diretório home separado, as reinstalações tornam-se mais transparentes. Você
ainda precisa reinstalar os programas, mas todas as configurações dos aplicativos são
preservadas.
Cada programa armazena suas configurações dentro de uma pasta oculta dentro do seu
diretório de usuário, como ".mozilla", ".kde", etc. Mesmo ao reinstalar o sistema, estas pastas
são reconhecidas e as configurações antigas preservadas. Basta tomar o cuidado de guardar
também todos os seus arquivos dentro do diretório home e você não perderá quase nada ao
reinstalar.
Continuando, temos as entradas para outras partições que foram encontradas pelo instalador:
# partições encontradas pelo instalador:
/dev/hda1 /mnt/hda1 reiserfs noauto,users,exec 0 0
/dev/hda2 /mnt/hda2 reiserfs noauto,users,exec 0 0
/dev/hda3 /mnt/hda3 reiserfs noauto,users,exec 0 0
/dev/hda6 /mnt/hda6 reiserfs noauto,users,exec 0 0
Veja que as partições "/dev/hda2" e "/dev/hda3" já estão sendo usadas, por isso as duas linhas
referentes a elas são redundantes e podem ser removidas. As linhas para as outras duas
partições, "/dev/hda1" (uma instalação do Mandriva) e "/dev/hda6" (uma partição de
arquivos) estão com a opção "noauto", como no caso do CD-ROM, que faz com que elas sejam
montadas apenas quando você clica nos ícones do desktop. Se você preferir que elas sejam
montadas automaticamente durante o boot, basta eliminar esta opção. Neste caso as linhas
ficariam assim:
/dev/hda1 /mnt/hda1 reiserfs users,exec 0 0
/dev/hda6 /mnt/hda6 reiserfs users,exec 0 0
Além de montar as partições e CD-ROMs locais, o fstab pode ser configurado para montar
também compartilhamentos de rede. Você pode tanto configurar para que os
compartilhamentos fiquem acessíveis automaticamente durante o boot (no caso de um
servidor que fique sempre ligado) ou montá-los através de ícones no desktop, como no caso
do CD-ROM.
Para montar um compartilhamento de rede NFS, a linha seria:
192.168.0.1:/home/arquivos /mnt/arquivos nfs noauto,users,exec 0 0
Neste exemplo o "192.168.0.1:/home/arquivos" é o IP do servidor, seguido pela pasta
compartilhada e o "/mnt/arquivos" é a pasta local onde este compartilhamento ficará
acessível.
Você pode incluir várias linhas, caso deseje montar vários compartilhamentos. Caso o servidor
fique sempre ligado e você queira que o compartilhamento seja montado automaticamente
durante o boot, retire o "noauto", caso contrário você pode acessar o compartilhamento
usando o comando:
# mount /mnt/arquivos
Para montar um compartilhamento de rede Windows ou de um servidor Linux rodando o
Samba, a linha seria:
//192.168.0.1/teste /home/teste smb noauto,user,username=maria,password=abcde 0 0
Veja que neste caso a sintaxe já é um pouco mais complicada. Em primeiro lugar,a entrada
que fala sobre o compartilhamento usa a sintaxe: "//ip_do_servidor/compartilhamento", por
isso você usa "//192.168.0.1/teste" e não "192.168.0.1:/teste" como seria num
compartilhamento NFS.
Em seguida vem a pasta onde o compartilhamento ficará acessível, "/home/teste" no
exemplo. Não se esqueça de criar a pasta, caso não exista.
O smb é o nome do protocolo usado para acessar os compartilhamentos Windows da rede.
Outra etapa importante é colocar o usuário e senha que será usado para acessar o
compartilhamento, como em: "user,username=maria,password=abcde". Caso o
compartilhamento não use senha (como os compartilhamentos do Windows 95/98), a linha
fica mais simples:
//192.168.0.1/arquivos /home/arquivos smb noauto,user 0 0
Assim como no caso do NFS, para montar o compartilhamento use o comando:
# mount /home/arquivos
Se preferir que ele seja montado durante o boot, basta retirar o "noauto". Neste caso a linha
no fstab ficaria:
//192.168.0.1/teste /home/teste smb user,username=maria,password=abcde 0 0
Ao colocar as senhas dos compartilhamentos de rede no "/etc/fstab" é necessário tomar uma
precaução de segurança. Rode o comando:
# chmod 600 /etc/fstab
Isto fará com que apenas o root possa ler o arquivo e conseqüentemente ver as senhas. O
default na maioria das distribuições é 644, o que permite que os outros usuários da máquina
possam ler o arquivo, uma grande brecha de segurança neste caso.
Uma coisa que você deve ter percebido é que o KDE só oferece a opção de criar ícones para
montar partições, disquetes e CD-ROMs, mas não para criar ícones para montar
compartilhamentos de rede. Mas é possível criar os ícones manualmente.
Os ícones do KDE, incluindo os do desktop e do iniciar, são arquivos de texto comuns, cujo
nome termina com .desktop. Isto faz com que o KDE os veja como ícones, e não simples
arquivos de texto. Naturalmente estes arquivos possuem uma sintaxe especial, mas nada tão
exótico.
Em primeiro lugar, o desktop no KDE corresponde à pasta Desktop, dentro do seu diretório de
usuário, como em "/home/kurumin/Desktop". Para criar um novo ícone no desktop basta criar
um arquivo de texto, cujo nome termine com ".desktop":
$ kedit /home/carlos/Desktop/compartilhamento.desktop
Dentro do novo arquivo, vai o seguinte:
[Desktop Entry]
Type=FSDevice
Dev=192.168.1.34:/arquivos
MountPoint=/mnt/nfs
FSType=nfs
ReadOnly=0
Icon=hdd_mount
UnmountIcon=hdd_unmount
Name=192.168.1.34:/arquivos
O "192.168.1.34:/mnt/hda6" é o endereço do compartilhamento e o "nfs" é o protocolo. O
"/mnt/nfs" é a pasta onde ele ficará acessível. O texto que vai na opção "Name" é o nome que
aparecerá no desktop, você pode usar qualquer texto. No meu caso simplesmente repeti o
endereço do compartilhamento para facilitar a identificação.
Para um compartilhamento Windows o texto seria:
[Desktop Entry]
Type=FSDevice
Dev=//192.168.1.34/arquivos
MountPoint=/mnt/samba
FSType=smb
ReadOnly=0
Icon=hdd_mount
UnmountIcon=hdd_unmount
Name=arquivos
Salvando o arquivo, o ícone já aparecerá no desktop e se comportará da mesma forma que o
do CD-ROM. Basta clicar para ver os arquivos ou acionar o "desmontar" para desativar:
Configurando o lilo
O lilo e o grub disputam o posto de gerenciador de boot default entre as distribuições Linux. O
lilo é o mais antigo e mais simples de configurar, enquanto o grub éo que oferece mais
opções. Mas, ao invés de ficar discutindo qual é melhor, vamos aprender logo a configurar e
resolver problemas nos dois :-).
O lilo utiliza um único arquivo de configuração, o "/etc/lilo.conf". Ao fazer qualquer alteração
neste arquivo é preciso chamar (como root) o executável do lilo, o "/sbin/lilo" ou
simplesmente "lilo" para que ele leia o arquivo e salve as alterações.
Vamos começar entendendo a função das linhas de uma configuração típica. Abra o arquivo
"/etc/lilo.conf" da sua máquina e acompanhe opção a opção.
boot=/dev/hda
Esta é quase sempre a primeira linha do arquivo. Ela indica onde o lilo será instalado.
Indicando um dispositivo, como em "/dev/hda", ele é instalado na trilha MBR do HD.
Indicando uma partição, como em "/dev/hda1" ele é instalado no primeiro setor da partição,
sem reescrever a MBR.
Ao instalar vários sistemas no HD, seja Linux e Windows ou várias distribuições diferentes,
apenas um deles deve ter o lilo gravado na MBR. Este terá a função de inicializar todos os
outros, cujos gerenciadores foram instalados nas respectivas partições.
Ao verificar esta linha, lembre-se de verificar qual é o dispositivo do HD na sua instalação. Um
HD serial ATA, por exemplo, será detectado como "/dev/sda" e não como "/dev/hda".
Se você tiver dois HDs, e estiver instalando o sistema numa partição do segundo ("/dev/hdb1",
por exemplo), e usar a linha "boot=/dev/hdb", o lilo será instalado no MBR do segundo HD,
não do primeiro. Durante o boot, o BIOS vai continuar lendo o MBR do primeiroHD, fazendo
com que continue sendo carregado o sistema antigo. Se você quiser que o sistema instalado
no segundo HD passe a ser o principal, use a linha "boot=/dev/hda", que gravará no MBR do
primeiro HD.
bitmap = /boot/kurumin.bmp
bmp-colors = 255,9,;9,255,
bmp-table = 61,15,1,12
bmp-timer = 73,29,255,9
Estas linhas ativam o uso de uma imagem como pano de fundo da tela de boot, ao invés do
feio menu em texto, ainda usado em algumas distribuições. Veremos mais detalhes sobre este
recurso logo a seguir.
vga=788
Esta é uma das linhas mais importantes do arquivo, que ajusta a resolução de vídeo em modo
texto (usando frame-buffer). Use "vga=785" para 640x480, "vga=788" para 800x600,
"vga=791" para 1024x768 ou "vga=normal" para desabilitar o frame-buffer e usar o modo
texto padrão.
Quase todas as placas de vídeo suportam frame-buffer, pois ele utiliza resoluções e recursos
previstos pelo padrão VESA. Apesar disso, algumas placas, mesmo modelos recentes,
suportam apenas 800x600. Ao tentar usar 1024x768 num destesmodelos, o sistema exibe
uma mensagem no início do boot, avisando que o modo não é suportado e o boot continua em
texto puro. O "vga=788" é um valor "seguro", que funciona em praticamente todas as placas e
monitores.
O lilo pode ser configurado para inicializar vários sistemas operacionais diferentes. A linha
"prompt" faz com que ele mostre um menu com as opções disponíveis na hora do boot. Ela é
quase sempre usada por padrão. A linha "default=" diz qual é o sistema padrão, o que fica pré-
selecionado na tela de boot.
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição
Ferramentas Técnicas - 2° edição

Más contenido relacionado

Was ist angesagt?

Drivers de Dispositivos Linux
Drivers de Dispositivos LinuxDrivers de Dispositivos Linux
Drivers de Dispositivos LinuxHudson Augusto
 
Um Modelo de Segurança de Redes para Ambientes Cooperativo
Um Modelo de Segurança de Redes para Ambientes CooperativoUm Modelo de Segurança de Redes para Ambientes Cooperativo
Um Modelo de Segurança de Redes para Ambientes CooperativoSoftD Abreu
 
Manipulando pacotes
Manipulando pacotesManipulando pacotes
Manipulando pacotesTiago
 
Inst configdebian
Inst configdebianInst configdebian
Inst configdebianTiago
 
Cópia de apostila nova curso idosos
Cópia de apostila nova curso idososCópia de apostila nova curso idosos
Cópia de apostila nova curso idososPaulo Rosa
 
Shell script
Shell scriptShell script
Shell scriptTiago
 
Javascript
JavascriptJavascript
JavascriptTiago
 
Lpi 101
Lpi 101Lpi 101
Lpi 101Tiago
 
Foca linux 1
Foca linux 1Foca linux 1
Foca linux 1pelincha
 

Was ist angesagt? (13)

Drivers de Dispositivos Linux
Drivers de Dispositivos LinuxDrivers de Dispositivos Linux
Drivers de Dispositivos Linux
 
Enviando linux
Enviando linuxEnviando linux
Enviando linux
 
Um Modelo de Segurança de Redes para Ambientes Cooperativo
Um Modelo de Segurança de Redes para Ambientes CooperativoUm Modelo de Segurança de Redes para Ambientes Cooperativo
Um Modelo de Segurança de Redes para Ambientes Cooperativo
 
Manipulando pacotes
Manipulando pacotesManipulando pacotes
Manipulando pacotes
 
Inst configdebian
Inst configdebianInst configdebian
Inst configdebian
 
Manual do Kile
Manual do KileManual do Kile
Manual do Kile
 
Abc do linux
Abc do linuxAbc do linux
Abc do linux
 
Introdução ao SciLab
Introdução ao SciLabIntrodução ao SciLab
Introdução ao SciLab
 
Cópia de apostila nova curso idosos
Cópia de apostila nova curso idososCópia de apostila nova curso idosos
Cópia de apostila nova curso idosos
 
Shell script
Shell scriptShell script
Shell script
 
Javascript
JavascriptJavascript
Javascript
 
Lpi 101
Lpi 101Lpi 101
Lpi 101
 
Foca linux 1
Foca linux 1Foca linux 1
Foca linux 1
 

Ähnlich wie Ferramentas Técnicas - 2° edição

Cópia de apostila nova curso idosos
Cópia de apostila nova curso idososCópia de apostila nova curso idosos
Cópia de apostila nova curso idososPaulo Rosa
 
Entendendo e dominando o linux 6ª edição
Entendendo e dominando o linux 6ª ediçãoEntendendo e dominando o linux 6ª edição
Entendendo e dominando o linux 6ª ediçãoBeba Gatosa
 
Linux kurumin - carlos e. morimoto - entendendo e dominando o linux - 7a
Linux   kurumin - carlos e. morimoto - entendendo e dominando o linux - 7aLinux   kurumin - carlos e. morimoto - entendendo e dominando o linux - 7a
Linux kurumin - carlos e. morimoto - entendendo e dominando o linux - 7aJácimo Junior
 
Instalei o Ubuntu e agora? (18.04)
Instalei o Ubuntu e agora? (18.04)Instalei o Ubuntu e agora? (18.04)
Instalei o Ubuntu e agora? (18.04)Fernando Anselmo
 
Apostila linux francisco-araruna
Apostila linux francisco-ararunaApostila linux francisco-araruna
Apostila linux francisco-ararunaWilkerson Santos
 
Apostila Linux.Sxw
Apostila Linux.SxwApostila Linux.Sxw
Apostila Linux.SxwOdair Sousa
 
Slackbookptbr 1.0.2
Slackbookptbr 1.0.2Slackbookptbr 1.0.2
Slackbookptbr 1.0.2SoftD Abreu
 
Guia Foca - Linux - Iniciante + Avançado
Guia Foca - Linux - Iniciante + AvançadoGuia Foca - Linux - Iniciante + Avançado
Guia Foca - Linux - Iniciante + AvançadoEliel Prado
 
Foca intermediario
Foca intermediarioFoca intermediario
Foca intermediarioTiago
 
1 manual componentes informáticos
1 manual componentes informáticos1 manual componentes informáticos
1 manual componentes informáticosNorberto Gomes
 

Ähnlich wie Ferramentas Técnicas - 2° edição (20)

Começando com o Linux.pdf
Começando com o Linux.pdfComeçando com o Linux.pdf
Começando com o Linux.pdf
 
Entendendo e dominando_o_linux
Entendendo e dominando_o_linuxEntendendo e dominando_o_linux
Entendendo e dominando_o_linux
 
Arquitetura de-computadores-apostila-avançada completa
Arquitetura de-computadores-apostila-avançada completaArquitetura de-computadores-apostila-avançada completa
Arquitetura de-computadores-apostila-avançada completa
 
Cópia de apostila nova curso idosos
Cópia de apostila nova curso idososCópia de apostila nova curso idosos
Cópia de apostila nova curso idosos
 
Entendendo e dominando o linux 6ª edição
Entendendo e dominando o linux 6ª ediçãoEntendendo e dominando o linux 6ª edição
Entendendo e dominando o linux 6ª edição
 
Linux kurumin - carlos e. morimoto - entendendo e dominando o linux - 7a
Linux   kurumin - carlos e. morimoto - entendendo e dominando o linux - 7aLinux   kurumin - carlos e. morimoto - entendendo e dominando o linux - 7a
Linux kurumin - carlos e. morimoto - entendendo e dominando o linux - 7a
 
Comandos
ComandosComandos
Comandos
 
Instalei o Ubuntu e agora? (18.04)
Instalei o Ubuntu e agora? (18.04)Instalei o Ubuntu e agora? (18.04)
Instalei o Ubuntu e agora? (18.04)
 
Curso delphi 7
Curso delphi 7 Curso delphi 7
Curso delphi 7
 
Apostila linux francisco-araruna
Apostila linux francisco-ararunaApostila linux francisco-araruna
Apostila linux francisco-araruna
 
20220093 scilab-manual
20220093 scilab-manual20220093 scilab-manual
20220093 scilab-manual
 
Apostila Linux.Sxw
Apostila Linux.SxwApostila Linux.Sxw
Apostila Linux.Sxw
 
Slackbookptbr 1.0.2
Slackbookptbr 1.0.2Slackbookptbr 1.0.2
Slackbookptbr 1.0.2
 
Guia Foca - Linux - Iniciante + Avançado
Guia Foca - Linux - Iniciante + AvançadoGuia Foca - Linux - Iniciante + Avançado
Guia Foca - Linux - Iniciante + Avançado
 
Foca Linux 2
Foca Linux 2Foca Linux 2
Foca Linux 2
 
Foca intermediario
Foca intermediarioFoca intermediario
Foca intermediario
 
fdyrjdhgd xff
fdyrjdhgd xfffdyrjdhgd xff
fdyrjdhgd xff
 
Foca 1e2
Foca 1e2Foca 1e2
Foca 1e2
 
1 manual componentes informáticos
1 manual componentes informáticos1 manual componentes informáticos
1 manual componentes informáticos
 
Focalinux iniciante
Focalinux inicianteFocalinux iniciante
Focalinux iniciante
 

Mehr von linuxInfo

Arch linux - Como instalar
Arch linux - Como instalarArch linux - Como instalar
Arch linux - Como instalarlinuxInfo
 
Instalando o Debian GNU/Linux 5.0
Instalando o Debian GNU/Linux 5.0Instalando o Debian GNU/Linux 5.0
Instalando o Debian GNU/Linux 5.0linuxInfo
 
Instalando o elementary os 0.2 luna
Instalando o elementary os 0.2 lunaInstalando o elementary os 0.2 luna
Instalando o elementary os 0.2 lunalinuxInfo
 
Instalando o pear linux 7
Instalando o pear linux 7Instalando o pear linux 7
Instalando o pear linux 7linuxInfo
 
Como instalar e o que é Debian
Como instalar e o que é DebianComo instalar e o que é Debian
Como instalar e o que é DebianlinuxInfo
 
Ubuntu – Configurando gerenciador de atualizações
Ubuntu – Configurando gerenciador de atualizaçõesUbuntu – Configurando gerenciador de atualizações
Ubuntu – Configurando gerenciador de atualizaçõeslinuxInfo
 
Configurando o suporte a idioma
Configurando o suporte a idiomaConfigurando o suporte a idioma
Configurando o suporte a idiomalinuxInfo
 

Mehr von linuxInfo (8)

Arch linux - Como instalar
Arch linux - Como instalarArch linux - Como instalar
Arch linux - Como instalar
 
Instalando o Debian GNU/Linux 5.0
Instalando o Debian GNU/Linux 5.0Instalando o Debian GNU/Linux 5.0
Instalando o Debian GNU/Linux 5.0
 
Instalando o elementary os 0.2 luna
Instalando o elementary os 0.2 lunaInstalando o elementary os 0.2 luna
Instalando o elementary os 0.2 luna
 
Instalando o pear linux 7
Instalando o pear linux 7Instalando o pear linux 7
Instalando o pear linux 7
 
Como instalar e o que é Debian
Como instalar e o que é DebianComo instalar e o que é Debian
Como instalar e o que é Debian
 
Ubuntu – Configurando gerenciador de atualizações
Ubuntu – Configurando gerenciador de atualizaçõesUbuntu – Configurando gerenciador de atualizações
Ubuntu – Configurando gerenciador de atualizações
 
Configurando o suporte a idioma
Configurando o suporte a idiomaConfigurando o suporte a idioma
Configurando o suporte a idioma
 
Open suse
Open suseOpen suse
Open suse
 

Último

Os impactos ambientais e suas consequências
Os impactos ambientais e suas consequênciasOs impactos ambientais e suas consequências
Os impactos ambientais e suas consequênciasLaianaLessaTeixeiraP
 
CADERNO_DE_CULTURA_ESPANHOLA_E_HISPANO-AMERICANA.pdf
CADERNO_DE_CULTURA_ESPANHOLA_E_HISPANO-AMERICANA.pdfCADERNO_DE_CULTURA_ESPANHOLA_E_HISPANO-AMERICANA.pdf
CADERNO_DE_CULTURA_ESPANHOLA_E_HISPANO-AMERICANA.pdfPaulissandraCoelho1
 
Jean Piaget - Trajetória, teoria e contribuições para educação.
Jean Piaget - Trajetória, teoria e contribuições para educação.Jean Piaget - Trajetória, teoria e contribuições para educação.
Jean Piaget - Trajetória, teoria e contribuições para educação.marianedesouzapadua
 
Antologia Literária NATAL em Versos 2023
Antologia Literária NATAL em Versos 2023Antologia Literária NATAL em Versos 2023
Antologia Literária NATAL em Versos 2023Nome Sobrenome
 
Dengue - Atividades números naturais.docx
Dengue - Atividades números naturais.docxDengue - Atividades números naturais.docx
Dengue - Atividades números naturais.docxAndré Morária
 
Exercícios_Figuras_de_Linguagem para fundamental e medio
Exercícios_Figuras_de_Linguagem  para fundamental e medioExercícios_Figuras_de_Linguagem  para fundamental e medio
Exercícios_Figuras_de_Linguagem para fundamental e medioFernanda Mota
 
Slides Lição 13, CPAD, O Poder de Deus na Missão da Igreja.pptx
Slides Lição 13, CPAD, O Poder de Deus na Missão da Igreja.pptxSlides Lição 13, CPAD, O Poder de Deus na Missão da Igreja.pptx
Slides Lição 13, CPAD, O Poder de Deus na Missão da Igreja.pptxLuizHenriquedeAlmeid6
 
Texto sobre dengue, com atividades e caça palavras
Texto sobre dengue, com atividades e caça palavrasTexto sobre dengue, com atividades e caça palavras
Texto sobre dengue, com atividades e caça palavrasEdileneAlves18
 
Introdução à Cartografia e Geoprocessamento - Conceitos Básicos
Introdução à Cartografia e Geoprocessamento - Conceitos  BásicosIntrodução à Cartografia e Geoprocessamento - Conceitos  Básicos
Introdução à Cartografia e Geoprocessamento - Conceitos BásicosVitor Vieira Vasconcelos
 
Aula 2 - Beauty standards (Part 1) ula de inglês
Aula 2 - Beauty standards (Part 1) ula de inglêsAula 2 - Beauty standards (Part 1) ula de inglês
Aula 2 - Beauty standards (Part 1) ula de inglêsAldoBlfia1
 
Introducao-sobre-Libâneo.pptx_20240308_212613_0000.pptx
Introducao-sobre-Libâneo.pptx_20240308_212613_0000.pptxIntroducao-sobre-Libâneo.pptx_20240308_212613_0000.pptx
Introducao-sobre-Libâneo.pptx_20240308_212613_0000.pptxgabrieladesousa54
 
Densidade e solubilidade 5 ano, aula 1 - 1° bimestre
Densidade e solubilidade 5 ano, aula 1 - 1° bimestreDensidade e solubilidade 5 ano, aula 1 - 1° bimestre
Densidade e solubilidade 5 ano, aula 1 - 1° bimestreAnaPaulaAmaral44
 
morfologia_formacaodepalavras_aula1.pptx
morfologia_formacaodepalavras_aula1.pptxmorfologia_formacaodepalavras_aula1.pptx
morfologia_formacaodepalavras_aula1.pptxCindiaAianaFLDantas
 
2. É possível a denúncia do Estado agressor junto ao Tribunal Penal Internaci...
2. É possível a denúncia do Estado agressor junto ao Tribunal Penal Internaci...2. É possível a denúncia do Estado agressor junto ao Tribunal Penal Internaci...
2. É possível a denúncia do Estado agressor junto ao Tribunal Penal Internaci...Unicesumar
 
1) De posse do conhecimento da sequência molde do DNA (gene), necessária para...
1) De posse do conhecimento da sequência molde do DNA (gene), necessária para...1) De posse do conhecimento da sequência molde do DNA (gene), necessária para...
1) De posse do conhecimento da sequência molde do DNA (gene), necessária para...excellenceeducaciona
 

Último (20)

NBR 10520.2023. Citações. 1s24 (revisão em 09mar24).pdf
NBR 10520.2023. Citações. 1s24 (revisão em 09mar24).pdfNBR 10520.2023. Citações. 1s24 (revisão em 09mar24).pdf
NBR 10520.2023. Citações. 1s24 (revisão em 09mar24).pdf
 
Os impactos ambientais e suas consequências
Os impactos ambientais e suas consequênciasOs impactos ambientais e suas consequências
Os impactos ambientais e suas consequências
 
Os textos contemporâneos na construção da opinião.
Os textos contemporâneos na construção  da opinião.Os textos contemporâneos na construção  da opinião.
Os textos contemporâneos na construção da opinião.
 
CADERNO_DE_CULTURA_ESPANHOLA_E_HISPANO-AMERICANA.pdf
CADERNO_DE_CULTURA_ESPANHOLA_E_HISPANO-AMERICANA.pdfCADERNO_DE_CULTURA_ESPANHOLA_E_HISPANO-AMERICANA.pdf
CADERNO_DE_CULTURA_ESPANHOLA_E_HISPANO-AMERICANA.pdf
 
Jean Piaget - Trajetória, teoria e contribuições para educação.
Jean Piaget - Trajetória, teoria e contribuições para educação.Jean Piaget - Trajetória, teoria e contribuições para educação.
Jean Piaget - Trajetória, teoria e contribuições para educação.
 
NBR 6023/2018 (Corrigida em 2020). Referências. 1s24.pdf
NBR 6023/2018 (Corrigida em 2020). Referências. 1s24.pdfNBR 6023/2018 (Corrigida em 2020). Referências. 1s24.pdf
NBR 6023/2018 (Corrigida em 2020). Referências. 1s24.pdf
 
Jogo dos Materiais - final Domínio Materiais.pdf
Jogo dos Materiais - final Domínio Materiais.pdfJogo dos Materiais - final Domínio Materiais.pdf
Jogo dos Materiais - final Domínio Materiais.pdf
 
Complementação: Aplicando as Normas da ABNT. 1s24.pdf
Complementação: Aplicando as Normas da ABNT. 1s24.pdfComplementação: Aplicando as Normas da ABNT. 1s24.pdf
Complementação: Aplicando as Normas da ABNT. 1s24.pdf
 
Antologia Literária NATAL em Versos 2023
Antologia Literária NATAL em Versos 2023Antologia Literária NATAL em Versos 2023
Antologia Literária NATAL em Versos 2023
 
Dengue - Atividades números naturais.docx
Dengue - Atividades números naturais.docxDengue - Atividades números naturais.docx
Dengue - Atividades números naturais.docx
 
Exercícios_Figuras_de_Linguagem para fundamental e medio
Exercícios_Figuras_de_Linguagem  para fundamental e medioExercícios_Figuras_de_Linguagem  para fundamental e medio
Exercícios_Figuras_de_Linguagem para fundamental e medio
 
Slides Lição 13, CPAD, O Poder de Deus na Missão da Igreja.pptx
Slides Lição 13, CPAD, O Poder de Deus na Missão da Igreja.pptxSlides Lição 13, CPAD, O Poder de Deus na Missão da Igreja.pptx
Slides Lição 13, CPAD, O Poder de Deus na Missão da Igreja.pptx
 
Texto sobre dengue, com atividades e caça palavras
Texto sobre dengue, com atividades e caça palavrasTexto sobre dengue, com atividades e caça palavras
Texto sobre dengue, com atividades e caça palavras
 
Introdução à Cartografia e Geoprocessamento - Conceitos Básicos
Introdução à Cartografia e Geoprocessamento - Conceitos  BásicosIntrodução à Cartografia e Geoprocessamento - Conceitos  Básicos
Introdução à Cartografia e Geoprocessamento - Conceitos Básicos
 
Aula 2 - Beauty standards (Part 1) ula de inglês
Aula 2 - Beauty standards (Part 1) ula de inglêsAula 2 - Beauty standards (Part 1) ula de inglês
Aula 2 - Beauty standards (Part 1) ula de inglês
 
Introducao-sobre-Libâneo.pptx_20240308_212613_0000.pptx
Introducao-sobre-Libâneo.pptx_20240308_212613_0000.pptxIntroducao-sobre-Libâneo.pptx_20240308_212613_0000.pptx
Introducao-sobre-Libâneo.pptx_20240308_212613_0000.pptx
 
Densidade e solubilidade 5 ano, aula 1 - 1° bimestre
Densidade e solubilidade 5 ano, aula 1 - 1° bimestreDensidade e solubilidade 5 ano, aula 1 - 1° bimestre
Densidade e solubilidade 5 ano, aula 1 - 1° bimestre
 
morfologia_formacaodepalavras_aula1.pptx
morfologia_formacaodepalavras_aula1.pptxmorfologia_formacaodepalavras_aula1.pptx
morfologia_formacaodepalavras_aula1.pptx
 
2. É possível a denúncia do Estado agressor junto ao Tribunal Penal Internaci...
2. É possível a denúncia do Estado agressor junto ao Tribunal Penal Internaci...2. É possível a denúncia do Estado agressor junto ao Tribunal Penal Internaci...
2. É possível a denúncia do Estado agressor junto ao Tribunal Penal Internaci...
 
1) De posse do conhecimento da sequência molde do DNA (gene), necessária para...
1) De posse do conhecimento da sequência molde do DNA (gene), necessária para...1) De posse do conhecimento da sequência molde do DNA (gene), necessária para...
1) De posse do conhecimento da sequência molde do DNA (gene), necessária para...
 

Ferramentas Técnicas - 2° edição

  • 1. Linux: Ferramentas técnicas ʹ 2ª edição Capa Este livro é uma coleção de dicas que ensinam a configurar e corrigir problemas "na unha", manipulando diretamente os arquivos de configuração e módulos do sistema, sem depender de nenhum configurador, escrever shell scripts, instalar drivers manualmente e dominar ferramentas de diagnóstico e recuperação do sistema. Por ser escrito em uma linguagem simples e didática e com um nível crescente de dificuldade, este livro é indicado tanto para usuários avançados que querem expandir seus conhecimentos, quanto para iniciantes que desejam compreender mais profundamente o sistema. Autor: Carlos E. Morimoto Páginas: 312 Formato: 23 x 16 cm Editora: GDH Press e Sul Editores ISBN: 85-205-0401-9 Lançado em: Março de 2006 Descrição As distribuições Linux estão de um modo geral se tornando muito fáceis de usar, em algumas áreas até mesmo mais fáceis de usar que o Windows. Mas, isso acaba deixando um gosto amargo na boca. Afinal, onde está o desafio? Em outros casos as coisas não funcionam tão bem assim e o gosto amargo fica por conta do modem, webcam, placa 3D ou placa wireless que não está funcionando ou outro problema qualquer, que não pode ser solucionado usando as ferramentas gráficas. Este livro é uma coleção de dicas que ensinam a configurar e corrigir problemas "na unha", manipulando diretamente os arquivos de configuração e módulos do sistema, sem depender
  • 2. de nenhum configurador, escrever shell scripts, instalar drivers manualmente e dominar ferramentas de diagnóstico e recuperação do sistema. É ideal para quem gosta de fuçar e quer entender melhor como o sistema funciona internamente, editando arquivos de configuração, compilando módulos e escrevendo scripts. Nesta segunda edição, o livro recebeu uma grande quantidade de atualizações em todos os capítulos e muitas das dicas antigas foram substituídas por novas. O capítulo sobre shell script foi expandido, trazendo mais dicas sobre o desenvolvimento de scripts gráficos e também scripts e regras para o hotplug e udev, que permitem abrir programas e executar outros scripts quando determinados dispositivos são plugados na máquina. Foi incluído também um novo capítulo, que ensina a desenvolver soluções baseadas no Kurumin e outros live-CDs baseados no Knoppix, que permitem colocar em prática as dicas aprendidas no restante do livro. Por ser escrito em uma linguagem simples e didática e com um nível crescente de dificuldade, este livro é indicado tanto para usuários avançados, quanto iniciantes que desejam compreender maisprofundamente o sistema. Carlos E. Morimoto é o criador do http://www.hardware.com.br, o maior site técnico do país. Seu trabalho inclui mais de dois mil artigos, dicas e tutoriais publicados, projetos de desenvolvimento em Linux, cursos, palestras e a publicação de 17 livros técnicos sobre hardware, redes, servidores e Linux, entre eles os livros Hardware, o Guia Definitivo; Redes, Guia Prático; Servidores Linux, Guia Prático; Smartphones, Guia Prático; Linux, Entendendo o Sistema e Linux, Ferramentas Técnicas.
  • 3. Sumário Prefácio ................................ ................................ ................................ ................................ ... 7 Capítulo 1: Entendendo a estrutura do sistema................................ ................................ ....... 7 Como funciona o suporte a hardware no Linux................................ ................................ ..... 8 Os componentes do sistema................................ ................................ ............................... 11 Kernel ................................ ................................ ................................ ................................ 11 Módulos................................ ................................ ................................ ............................. 16 Os processos de boot e os arquivos de inicialização................................ ............................ 18 Ativando e desativando serviços................................ ................................ ......................... 22 X ................................ ................................ ................................ ................................ ........ 25 Gerenciador de login................................ ................................ ................................ .......... 27 Xfree e Xorg ................................ ................................ ................................ ....................... 27 A árvore genealógica das distribuições................................ ................................ ............... 28 Capítulo 2: Configuração, ferramentas e dicas................................ ................................ ...... 31 Editando o /etc/fstab ................................ ................................ ................................ ......... 31 Configurando o lilo................................ ................................ ................................ ............. 38 Dual-Boot com dois HDs................................ ................................ ................................ . 42 Usando uma imagem de fundo................................ ................................ ....................... 43 Configurando o grub ................................ ................................ ................................ .......... 44 Configurando o vídeo: /etc/X11/xorg.conf................................ ................................ .......... 48 KVM via software com o Synergy................................ ................................ ........................ 59 Usando o hdparm................................ ................................ ................................ ............... 65 Recompilando o Kernel ................................ ................................ ................................ ...... 69 Baixando os fontes................................ ................................ ................................ ......... 70 Configurando................................ ................................ ................................ .................. 71 Compilando................................ ................................ ................................ .................... 77 Instalando................................ ................................ ................................ ...................... 79 Recompilando o Kernel à moda Debian................................ ................................ .......... 80 Aplicando patches................................ ................................ ................................ .......... 81 Criando patches ................................ ................................ ................................ ................. 82 Acelerando a compilação com o distcc................................ ................................ ............... 83 Criando pacotes a partir dos fontes com o checkinstall................................ ....................... 85
  • 4. Escrevendo scripts de backup................................ ................................ ............................. 87 Usando o autofs/automount................................ ................................ .............................. 92 Acessando dispositivos USB................................ ................................ ................................ 94 Configurando manualmente................................ ................................ ........................... 94 Devs e hotplug................................ ................................ ................................ ................ 98 Entendendo o udev................................ ................................ ................................ ...... 100 Renomeando interfaces de rede com o udev................................ ................................ 102 Fazendo backup e recuperando a MBR e tabela de partições................................ ........... 104 Usando o Gpart................................ ................................ ................................ ............ 105 Usando o Testdisk ................................ ................................ ................................ ........ 106 Recuperando partições danificadas................................ ................................ .................. 109 Gerenciamento de setores defeituosos como o ReiserFS................................ .................. 114 Monitorando a saúde do HD com o SMART................................ ................................ ...... 116 Copiando dados de HDs ou CDs defeituosos................................ ................................ ..... 120 Aproveitando módulos de memória defeituosos................................ .............................. 122 Eliminando dados com segurança................................ ................................ ..................... 123 Administrando a memória swap................................ ................................ ....................... 127 Ativando o suporte a mair de 1GB de memória RAM................................ ........................ 129 Clonando partições com o Partimage................................ ................................ ............... 131 Instalando................................ ................................ ................................ .................... 132 Funções básicas................................ ................................ ................................ ............ 133 Fazendo uma imagem de todo o HD................................ ................................ ............. 138 Gravando imagens num compartilhamento darede................................ ..................... 139 Segurança: detectando rootkits................................ ................................ ........................ 143 Instalando o Kurumin 7 (e outras distros) num pendrive ou cartão................................ ... 145 Salvando as configurações................................ ................................ ................................ 153 Monitores de temperatura e coolers................................ ................................ ................ 155 Gerenciamento de energia................................ ................................ ............................... 159 Capítulo 3: Instalando drivers adicionais................................ ................................ ............. 164 Verificando links, arquivos e compiladores................................ ................................ ....... 164 Configurando softmodems no Linux................................ ................................ ................. 167 A idéia básica................................ ................................ ................................ ................ 168 Driver da Smartlink................................ ................................ ................................ ....... 169 Intel AC97 e ATI IXP................................ ................................ ................................ ...... 174
  • 5. Intel 537 e 536 ................................ ................................ ................................ ............. 176 Lucent e Agere ................................ ................................ ................................ ............. 178 PC-Tel PCI................................ ................................ ................................ ..................... 180 Modems com chipset Conexant................................ ................................ .................... 181 Instalando placas wireless................................ ................................ ................................ 182 Ndiswrapper................................ ................................ ................................ ................. 184 ACX100 e ACX111................................ ................................ ................................ ......... 187 MadWiFi................................ ................................ ................................ ....................... 189 ADMteck ADM8211................................ ................................ ................................ ...... 190 Realtek 8180 ................................ ................................ ................................ ................ 191 Orinoco USB................................ ................................ ................................ ................. 192 Broadcom................................ ................................ ................................ ..................... 193 IPW2100 e IPW2200................................ ................................ ................................ ..... 193 Ralink 2400 e 2500................................ ................................ ................................ ....... 197 Linux-wlan-ng................................ ................................ ................................ ............... 198 Suporte a webcams................................ ................................ ................................ .......... 199 Driver apca5xx................................ ................................ ................................ .............. 201 Logitech QuickCam................................ ................................ ................................ ....... 202 Sqcam ................................ ................................ ................................ .......................... 202 Modems ADSL USB................................ ................................ ................................ ........... 203 Driver da nVidia................................ ................................ ................................ ................ 208 Instalando manualmente................................ ................................ .............................. 208 Ativando os recursos especiais................................ ................................ ..................... 214 FSAA................................ ................................ ................................ ............................. 214 Configurador gráfico................................ ................................ ................................ ..... 216 Twin View................................ ................................ ................................ ..................... 219 Instalando à moda Debian................................ ................................ ............................ 221 Driver para placas com chipset nForce................................ ................................ .............. 223 Ativando o driver de rede................................ ................................ ............................. 224 Ativando o driver de som................................ ................................ .............................. 225 Driver 3D da ATI ................................ ................................ ................................ ............... 225 Instalando................................ ................................ ................................ .................... 227 Configurando e solucionando problemas................................ ................................ ...... 228 Tablets ................................ ................................ ................................ ............................. 233
  • 6. Configurando placas de TV ................................ ................................ ............................... 236 Gravando ................................ ................................ ................................ ..................... 241 Configurando mouses touchpad com funções especiais................................ ................... 242 Bootsplash ................................ ................................ ................................ ....................... 246 Capítulo 4: Programando em shell script................................ ................................ ............. 250 O básico ................................ ................................ ................................ ........................... 251 Fazendo perguntas................................ ................................ ................................ ........... 255 Mais dicas sobre o kdialog................................ ................................ ................................ 268 Controlando aplicativos via DCOP................................ ................................ ..................... 275 Usando os servicemenus do KDE................................ ................................ ...................... 278 Detectando hardware ................................ ................................ ................................ ...... 284 Alterando arquivos de configuração................................ ................................ ................. 288 Corrigindo erros ................................ ................................ ................................ ............... 293 Pacotes auto-instaláveis................................ ................................ ................................ ... 296 Mais exemplos úteis................................ ................................ ................................ ......... 297 Criando interfaces no Kommander................................ ................................ ................... 302 Criando scripts para o hotplug................................ ................................ .......................... 328 Criando regras para o udev................................ ................................ ............................... 333 Capítulo 5: Remasterizando o Kurumin e outros live-CDs................................ .................... 340 O básico ................................ ................................ ................................ ........................... 341 Extraindo................................ ................................ ................................ .......................... 344 Fechando a nova imagem................................ ................................ ................................ . 348 Personalizando o KDE e programas................................ ................................ ................... 352 Scripts de inicialização................................ ................................ ................................ ...... 355 Mudando a lingua padrão e traduzindo as mensagens de boot................................ ......... 359 Mudando o usuário padrão................................ ................................ .............................. 360 Criando um DVD de recuperação................................ ................................ ...................... 360 Criando seus próprios pacotes .deb................................ ................................ .................. 364
  • 7. Prefácio As distribuições Linux estão de um modo geral se tornando muito fáceis de usar, até mesmo mais fáceis de usar que o Windows em algumas áreas. Mas isso acaba deixando umgosto amargo na boca. Afinal, onde está o desafio? Em outros casos as coisas não funcionam tão bem assim e o gosto amargo fica por conta do modem, webcam, placa 3D ou placa wireless que não está funcionando ou outro problema qualquer, que não pode ser solucionado usando as ferramentas gráficas. Este livro é uma coleção de dicas que ensinam a configurar e corrigir problemas "na unha", manipulando diretamente os arquivos de configuração e módulos do sistema, sem depender de nenhum configurador, escrever shell scripts, instalar drivers manualmente e dominar ferramentas de diagnóstico e recuperação do sistema. É ideal para quem gosta de fuçar e quer entender melhor como o sistema funciona internamente, editando arquivos de configuração, compilando módulos e escrevendo scripts. Nesta segunda edição, o livro recebeu uma grande quantidade de atualizações em todos os capítulos e muitas das dicas antigas foram substituídas por novas. O capítulo sobre shell script foi expandido, trazendo mais informações sobre o desenvolvimento de scripts gráficos, ferramentas de configuração e também scripts e regras para o hotplug e udev, que permitem abrir programas e executar tarefas diversas quando novos dispositivos são plugados na máquina. Foi incluído também um novo capítulo, que ensina a desenvolver novas distribuições ou soluções baseadas no Kurumin e outros live-CDs derivados do Knoppix, que permitem colocar em prática as dicas aprendidas no restante do livro. Por ser escrito em uma linguagem simples e didática e com um nívelcrescente de dificuldade, este livro é indicado tanto para usuários avançados, quanto iniciantes que desejam compreender mais profundamente o sistema. Capítulo 1: Entendendo a estrutura do sistema Os primeiros sistemas Unix foram desenvolvidos na década de70, com o objetivo de serem robustos, simples e utilizarem pouca memória, de forma a rodarem com um bom desempenho nos computadores limitados da época. Porém, por serem desenvolvidos tendo em mente os administradores de sistema, que sempre possuíam bons conhecimentos, nem sempre a facilidade de uso era uma prioridade.
  • 8. O Linux pode ser considerado um sistema Unix, que conserva muitas das características dos sistemas originais. Para quem vem do Windows, a organização das pastas, a instalação de novos programas e o uso dos arquivos de configuração parece algo esotérico. Mas no fundo as coisas não são tão complicadas assim. Este capítulo é uma introdução à estrutura do Linux, destinada ao público técnico. Como funciona o suporte a hardware no Linux As distribuições Linux sempre vêm de fábrica com suporte a muitos dispositivos, em geral quase tudo é detectado automaticamente. Os maiores problemas são, em geral, os softmodems que precisam ser instalados manualmente. O mesmo se aplica se você tiver uma placa de vídeo da nVidia ou da ATI ou outros dispositivos (como várias placas de rede wireless), cujos fabricantes disponibilizam drivers proprietários. Mas, afinal, como é a instalação destes drivers no Linux? Cadê o assistente para a instalação de novo hardware? Onde que eu aponto a pasta onde estão os arquivos? Calma, vamos chegar lá :-). O suporte a dispositivos no Linux é feito através de "módulos" incluídos no Kernel, arquivos que ficam dentro da pasta "/lib/modules/versão_do_kernel_usada/". Estes módulos são a coisa mais parecida com um "driver" dentro da concepção que temos no Windows. Para ativar suporte a um certo dispositivo, você precisa apenas carregar o módulo referente a ele. Veja que os módulos ficam organizados em pastas: a pasta "kernel/drivers/net/" contém drivers para placas de rede, a pasta "kernel/drivers/usb/" agrupa os que dão suporte dispositivos USB e assim por diante. Até o Kernel 2.4, os módulos de Kernel utilizavam a extensão ".o", que é uma extensão genérica para objetos em C. A partir do Kernel 2.6, passou a ser usada a extensão ".ko" (kernel object), que é mais específica. Quase sempre, os módulos possuem nomes que dão uma idéia do dispositivo a que oferecem suporte. O "8139too.ko" dá suporte às placas de rede com o chipset Realtek 8139, o "sis900.ko" dá suporte às placas SiS 900, enquanto o "e100.ko" ativa as placas Intel E100.
  • 9. Os módulos podem ser carregados e descarregados a qualquer momento usando os comandos "modprobe" e "modprobe -r"; não apenas na inicialização do sistema. Existe também o comando "insmod", mais antigo, que também permite carregar módulos. A diferença entre o "insmod" e o "modprobe" é que o modprobe carrega apenas módulos já instalados, junto com todas as dependências, ou seja, outros módulos de que o primeiro precise para funcionar. Se você tentar carregar o módulo "usb-storage" (que dá suporte a pendrives e HDs USB), vai perceber que serão carregados também os módulos "usbcore" e "ehci-hcd". O "insmod" é muito menos inteligente, carrega apenas o módulo solicitado, retornando um erro caso ele precise de outros. A única vantagem é que ele permite carregar módulos a partir de qualquer pasta, permitindo que você teste um módulo que acabou de compilar, ou que gravou num pendrive, por exemplo. Os módulos são gerados durantea compilação do Kernel. Você não precisa se preocupar com isso se não quiser, pois as distribuições quase sempre incluem versões bem completas do Kernel por padrão. Mas, de qualquer forma, existe sempre a possibilidade de recompilar o Kernel, mexendo nas opções e ativando ou desativando os módulos que quiser.
  • 10. Você pode incluir módulos para todo tipo de dispositivos, de marcas e modelos diferentes. Eles não atrapalham em nada, pois apenas alguns deles (os que você estiver usando no momento) ficarão carregados na memória. Estes módulos geralmente são pequenos; um conjunto completo com os módulos para todo tipo de dispositivos (que totalizam mais de mil arquivos no Kernel 2.6), normalmente ocupa de 40 a 50 MB no HD. Podemos dividir os drivers de dispositivo para o Linux em dois grupos. O primeiro é o dos drivers de código aberto, que podem tanto ser desenvolvidos pelos próprios fabricantes quanto por voluntários em cantos remotos do mundo. Desenvolver drivers usando engenharia reversa sem ajuda dos fabricantes parece ser um passatempo bastante popular :-). Estes drivers open-source são incluídos diretamente no Kernel, o que faz com que sejam incluídos diretamente nas distribuições e você não precise se preocupar muito com eles. Sua placa funciona e todo mundo fica feliz. A segunda categoria é a dos drivers proprietários, de código fechado, que são desenvolvidos pelos próprios fabricantes. Em alguns casos os drivers são de livre distribuição e também podem ser incluídos diretamente nas distribuições. Em outros, você mesmo precisará baixar e instalar o driver. É aqui que entram os drivers para softmodems, para muitas placas wireless e também os drivers para placas 3D da nVidia e da ATI. A psicologia para lidar com eles é a seguinte: instalar um destes drivers envolve duas tarefas: baixar e instalar o módulo propriamente dito e criar um "dispositivo" (device), um atalho que aponta para o endereço de hardware usado por ele. Ao instalar um modem Lucent, por exemplo, é criado um dispositivo "/dev/ttyLT0" por ondeo modem é acessado. Para facilitar esta tarefa, geralmente os drivers vêm com algum tipo de instalador, geralmente um script simples de modo texto que cuida disso para você. Os módulos são parte integrante do Kernel, por isso os módulos para uma determinada distribuição não funcionam em outra, a menos que por uma grande coincidência as duas
  • 11. utilizem exatamente a mesma versão do Kernel. Isso é bastante improvável já que o Kernel do Linux é atualizado quase que diariamente. Se você usar uma distribuição popular, Mandriva, Fedora, SuSE, etc., é possível que você encontre um driver pré-compilado para download (que pode ser encontrado com a ajuda do Google ;). Neste caso, você só vai precisar instalar um pacote RPM ou executar um arquivo de instalação. Em outras situações, você encontrará apenas um arquivo genérico ainda não compilado, contendo um instalador que se encarrega de compilar um módulo sob medida para o Kernel em uso. Como ele não tem como adivinhar qual distribuição ou Kernel você está utilizando, é necessário ter instalados dois pacotes que acompanham qualquer distribuição:kernel-source e kernel-headers. No Mandriva, por exemplo, você pode instalá-los usando os comandos: # urpmi kernel-source # urpmi kernel-headers Naturalmente, para que ele possa compilar qualquer coisa, você precisará também de um compilador, o gcc, que também acompanha as distribuições. Se você tiver estas três coisas, vai conseguir instalar qualquer driver sem maiores problemas, basta seguir as instruções na página de download ou no arquivo INSTALL ou README dentro do pacote. Uma grande parte deste livro é justamente dedicada a falar sobre a instalação destes drivers difíceis, abordando também os problemas de instalação mais comuns. Um lembrete importante sobre a nomenclatura adotada neste livro e em outros tipos de documentação é que a cerquilha (#) no início do comando indica que ele deve ser executado como root, o que é necessário ao instalar programas e editar arquivos de configuração. Os comandos com um dólar ($) por sua vez devem ser executados usando uma conta de usuário. Lembre-se de que, em qualquer distribuição, você pode usar o comando "su" (seguido da senha) para virar root. No caso do Ubuntu, além do Kurumin e outras distribuições derivadas do Knoppix, você pode usar também o "sudo". Os componentes do sistema Todas as coisas grandes começam pequenas e com o Linux não foi diferente. Para entender melhor os componentes que formam o sistema, nada melhor do que falar um pouco sobre a história do Linux, sobre como e por que eles foram introduzidos, e entender o processo de inicialização do sistema. Kernel Tudo começou em 1991, com a primeira versão do Kernel disponibilizada por Linus Torvalds. O "Freax" (renomeado para "Linux" pelo responsávelpelo FTP onde o arquivo foi disponibilizado, uma alma sábia e caridosa :) ainda estava na versão 0.02 e era um sistema monolítico, um grande bloco de código que, além do núcleo do sistema, continha drivers de dispositivos e tudo mais.
  • 12. Para compilar o código fonte do Kernel, era necessário usar o Minix, outro sistema baseado em Unix que na época era bastante popular entre os estudantes. Você começava compilando o Kernel e em seguida algumas ferramentas básicas como o gerenciador de boot, o bash (o interpretador de comandos) e o gcc (o compilador). A partir de um certo ponto, você podia dar boot no próprio Linux e compilar os demais programas a partir dele mesmo. Os primeiros aplicativos a rodarem sobre o Linux foram justamente ferramentas de desenvolvimento, como o Emacs, e emuladores de terminal, usados para acessar outras máquinas Unix remotamente. Nesta época começaram a surgir as primeiras "distribuições" Linux, na forma de projetos amadores, onde alguém gravava o sistema compilado em um conjunto de disquetes e tirava cópias para os amigos. Este procedimento de usar outro sistema operacional instalado para compilar uma instalação do Linux é de certa forma usada até hoje para gerar versões do sistema destinadas a serem usadas em dispositivos embarcados, como palms e celulares. Neles você usa uma cópia do Linux instalada num PC para "montar" o sistema que vai rodar no dispositivo, compilando primeiro o Kernel e depois os demais aplicativos necessários, deixando para finalmente transferir para o dispositivo no final do processo. Isto é chamado de "cross-compiling". Atualmente o Kernel, junto com vários aplicativos, pode ser compilado para rodar em várias plataformas diferentes. O código fonte do Kernel, disponível nohttp://kernel.org (e diversos mirrors), inclui o código necessário para gerar um Kernel para qualquer arquitetura suportada. Na verdade, quase 95% do código Kernel é independente da arquitetura, por isso portar o Kernel para uma nova plataforma é um trabalho relativamente simples (pelo menos se levarmos em conta a complexidade do código envolvido). As partes que mudam de uma arquitetura a outra são organizadas na pasta "/usr/src/linux/arch/". Ainda assim, e um trabalho complexo e tedioso, muitas coisas precisam ser ajustadas e é necessário encontrar programas específicos, que se ajustem à configuração de hardware da plataforma alvo. Você pode rodar Linux num celular com 2 MB de memória, mas com certeza não vai conseguir rodar o Firefox nele. Vai precisar encontrar um navegador mais leve, que rode confortavelmente com pouca memória e a tela minúscula do aparelho. Aqui temos um screenshot do Familiar, uma distribuição Linux para o Ipaq, que pode ser instalado em substituição ao Pocket PC Windows, que vem originalmente instalado. Veja que ele é bem diferente das distribuições para micros PC:
  • 13. Você pode entender melhor sobre como isto funciona instalando o "Linux from Scratch", uma distribuição Linux que pode ser toda compilada manualmente a partir dos pacotes com código fonte, disponível no: http://www.linuxfromscratch.org/. Voltando à história, no início o projeto ainda não tinha muita utilidade prática. O conjunto de aplicativos que rodava no sistema era pequeno. Era muitomais fácil usar o Minix, ou, se você tivesse condições financeiras, uma versão comercial do Unix, como o SunOS, que mais tarde deu origem ao Solaris e ao OpenSolaris. O que fez com que o Linux crescesse até o ponto em que está hoje foi principalmente o fato de não apenas o código fonte do sistema ser aberto e estar disponível, mas também a forma aberta como o sistema foi desenvolvido desde o início. É normal encontrar muitos problemas e deficiências ao tentar usar um software em estágio primário de desenvolvimento. Se você for um programador, vai acabar dando uma olhada no código e fazendo algumas modificações. Se você estiver desenvolvendo algum projeto parecido, é provável que você resolva aproveitar algumas idéias e pedaços de código para implementar alguma nova função e assim por diante. No caso do Linux, estas modificações eram bem-vindas e acabavam sendo incluídas no sistema muito rapidamente. Isto criou uma comunidade bastante ativa, gente usando o sistema nos mais diversos ambientes e ajudando a torná-lo adequado para todo tipo de tarefa. Inicialmente era tudo um grande hobby. Mas logo o sistema começou a ficar maduro o suficiente para concorrer com as várias versões do Unix e, mais tarde, também com o Windows, inicialmente nos servidores, depois nos dispositivos embarcados e finalmente no desktop. Com isso, mesmo grandes empresas como a IBM e a Novell começaram a contribuir
  • 14. com o desenvolvimento do Kernel, a fim de tornar o sistema mais robusto e adicionar recursos necessários para uso em diversas tarefas. Este modelo é diferente do adotado pela Microsoft, por exemplo, que vende caixinhas do Windows e Office. Estas empresas ganham mais vendendo soluções, onde é fornecido um pacote, com o sistema operacional, aplicativos, suporte e garantias. Neste caso, faz sentido contribuir para a construção de uma base comum (o Kernel) pois, no final, sai muito mais barato do que investir em um sistema próprio. A partir desta base comum, as empresas podem diferenciar-se das demais investindo nos outros componentes do pacote. Usar Linux acaba virando então uma questão de competitividade: outra empresa que resolvesse desenvolver um sistema próprio sairia em desvantagem, pois precisaria investir muito tempo e dinheiro para chegar no mesmo nível dos outros. Originalmente, o termo "Linux" era usado especificamente com relação ao Kernel desenvolvido por Linus Torvalds. Mas, hoje em dia, é mais comum nos referirmos à plataforma como um todo, incluindo o Kernel, ferramentas e aplicativos. Muitos dos aplicativos que usamos hoje no Linux vieram de outras versões do Unix e este fluxo continua até hoje, nos dois sentidos. O Kernel é a base do sistema. Ele controla o acesso à memória, ao HD e demais componentes do micro, dividindo os recursos disponíveis entre os programas. Todos osdemais programas, desde os aplicativos de linha de comando, até os aplicativos gráficos rodam sobre o Kernel. Imagine, por exemplo, que você está desenvolvendo um aplicativo de edição de áudio. Você precisa incluir no seu programa várias funções de edição, filtros e assim por diante. Mas, você não precisa se preocupar diretamente em oferecer suporte aos diferentes modelos de placas de som que temos no mercado, pois o Kernel cuida disso. Ao tocar um arquivo de áudio qualquer, o seu programa precisa apenas mandar o fluxo de áudio para o device "/dev/dsp". O Kernel recebe o fluxo de áudio e se encarrega de enviá-lo à placa de som. Quando é preciso ajustar o volume, seu programa acessa o dispositivo "/dev/mixer", e assim por diante. Naturalmente, uma Sound Blaster Live e uma placa AC'97 onboard, por exemplo, oferecem conjuntos diferentes de recursos e se comunicam com o sistema de uma forma particular, ou seja, falam línguas diferentes. Por isso o Kernel inclui vários intérpretes, os drivers de dispositivo. Driver em inglês significa "motorista" ou, "controlador". Cada chipset de placa de som, vídeo, rede ou modem possui um driver próprio. Podemos dizer que os módulos são as partes do Kernel mais intimamente ligadas ao hardware. Os módulos são as partes do Kernel que mudam de máquina para máquina. Depois vem o bloco principal, "genérico" do Kernel.
  • 15. Sobre ele roda o shell, o interpretador de comandos responsável por executar os aplicativos de modo texto e servidores, como o Samba e o Apache. Estes aplicativos são independentes do modo gráfico, você não precisa manter o X aberto para instalar e configurar um servidor Samba, por exemplo, embora as ferramentas gráficas possam ajudar bastante na etapa de configuração. Quando você executa o comando "cat arquivo.txt", porexemplo, o bash entende que deve usar o programa "cat" para ler o "arquivo.txt". O Kernel oferece uma série de serviços e comandos que podem ser usados pelos aplicativos. Neste caso, o bash dá a ordem para que o executável "cat", junto com o arquivo sejamcarregados na memória. Para que isso aconteça, o Kernel precisa ler os dois arquivos no HD e carregá-los na memória RAM. No processo são usadas chamadas de vários módulos diferentes, como o responsável pelo acesso à porta IDE onde o HD está conectado, o responsável pelo sistema de arquivos em que o HD está formatado e o módulo responsável pelo suporte ao controlador de memória da placa-mãe. No caso de programas muito grandes, a memória RAM pode ficar lotada, obrigando o Kernel a usar o subsistema de memória virtual para gravar as informações excedentes na partição swap. Só depois de tudo isso que o "cat" pode ser executado e mostrar o conteúdo do arquivo na tela (usando mais um comando do Kernel, que aciona a placa de vídeo). Graças ao trabalho do Kernel, você não precisa se preocupar com nada disso, apenas com os programas que precisa executar. Depois vem o X, o servidor gráfico, responsável por acessar a placa de vídeo e mostrar imagens no monitor. Ele serve como base para os aplicativos gráficos, que podem ser divididos em duas categorias. Primeiro temos os gerenciadores, como o KDE e o Gnome, que são responsáveis por gerenciar as janelas, mostrar a barra de tarefas e assim por diante. Eles servem como uma base para que você possa abrir e controlar os demais aplicativos gráficos. Mesmo dentro do modo gráfico, você continua tendo acesso aos recursos do modo texto. Programas como o Xterm e o Konsole são usados para rodar uma instância do bash dentro do
  • 16. modo gráfico, permitindo executar todos os aplicativosde linha de comando e scripts. Ou seja, o X roda com uma perna no Kernel e outra no interpretador de comandos. Módulos Como vimos, uma das tarefas mais importantes do Kernel é oferecer suporte ao hardware da máquina. No começo, a questão era mais simples, pois não existiam periféricos USB, softmodems e muito menos placas wireless. O Kernel oferecia suporte apenas aos dispositivos mais essenciais, como HD, placa de vídeo e drive de disquetes. Com o tempo, foi sendo adicionado suporte a muitos outros dispositivos: placas de som, placas de rede, controladoras SCSI, e assim por diante. O fato do Kernel ser monolítico começou a atrapalhar bastante. Você podia escolher os componentes a ativar na hora de compilar o Kernel. Se você habilitasse tudo, não teria problemas com nenhum dispositivo suportado, tudo iria funcionar facilmente. Mas, por outro lado, você teria um Kernel gigantesco, que rodaria muito devagar no seu 486 com 8 MB de RAM. Se, por outro lado, você compilasse um Kernel enxuto e esquecesse de habilitaro suporte a algum recurso necessário, teria que recompilar tudo de novo para ativá-lo. Este problema foi resolvido durante o desenvolvimento do Kernel 2.0, através do suporte a módulos. Os módulos são peças independentes que podem ser ativadas oudesativadas com o sistema em uso. Do Kernel 2.2 em diante, quase tudo pode ser compilado como módulo. Isso tornou as coisas muito mais práticas, pois passou ser possível compilar um Kernel com suporte a quase tudo, com todas as partes não essenciais compiladas como módulos. O Kernel em si é um executável pequeno, que consome pouca RAM e roda rápido, enquanto os módulos ficam guardados numa pasta do HD até que você precise deles. Você podia carregar o módulo para a SoundBlaster 16 (do 486 que você usava na época ;-) por exemplo, com um: # modprobe sb E descarregá-lo com um: # modprobe -r sb Esta idéia dos módulos deu tão certo que é usada até hoje e num nível cada vez mais extremo. Para você ter uma idéia, no Kernel 2.6 até mesmo o suporte a teclado pode serdesativado ou compilado como módulo, uma modificação que parece besteira num PC, mas que é útil para quem desenvolve versões para roteadores e outros dispositivos que realmente não possuem teclado.
  • 17. As distribuições passaram então a vir com versões do Kernel cada vez mais completas, incluindo em muitos casos um grande número de patches para adicionar suporte a ainda mais dispositivos, naturalmente quase tudo compilado como módulos. Nas distribuições atuais, o hardware da máquina é detectado durante a instalação e o sistema é configurado para carregar os módulos necessários durante o boot. Isto pode ser feito de duas formas: 1- Os módulos para ativar a placa de som, rede, modem e qualquer outro dispositivo "não essencial" são especificados no arquivo "/etc/modules". Programas de detecção, como o hotplug e o udev ficam de olho nas mensagens do Kernel e carregam módulos adicionais conforme novos dispositivos (uma câmera digital USB, em modo de transferência, por exemplo) são detectados. Sua placa de som seria ativada durante o boot através de um módulo especificado no "/etc/modules", assim como o suporte genérico a dispositivos USB. Mas, o seu pendrive, que você pluga e despluga toda hora é ativado e desativado dinamicamente através da detecção feita pelo hotplug ou udev. A detecção de novos periféricos (principalmente ao usar o Kernel 2.6) é muito simplificada graças ao próprio Kernel, que gera mensagens sempre que um novo dispositivo é encontrado. Você pode acompanhar este log rodando o comando "dmesg". Por exemplo, ao plugar um pendrive USB, você verá algo como: usb 2-2: new high speed USB device using address scsi1 : SCSI emulation for USB Mass Storage devices Vendor: LG CNS Model: Rev: 1.00 Type: Direct-Access ANSI SCSI revision: 02 SCSI device sda: 249856 512-byte hdwr sectors (128 MB) sda: Write Protect is off sda: Mode Sense: 03 00 00 00 sda: assuming drive cache: write through sda: sda1 Attached scsi removable disk sda at scsi1, channel 0, id 0, lun 0 Attached scsi generic sg0 at scsi1, channel 0, id 0, lun 0, type 0 USB Mass Storage device found at 5 Veja que aqui estão quase todas as informações referentes a ele. O fabricante (LG), o dispositivo pelo qual ele será acessado pelo sistema (sda), a capacidade (128 MB) e até as partições existentes (neste caso uma única partição, nomeada "sda1"). Um segundo arquivo, o "/etc/modules.conf" (ou "/etc/modprobe.conf", dependendo da distribuição usada), especifica opções e parâmetros para os módulos, quando necessário. Este arquivo normalmente é gerado automaticamentepelas ferramentas de detecção de hardware ou ao rodar o comando "update-modules", mas pode também ser editado manualmente, caso necessário.
  • 18. Outra peça importante é o arquivo "/lib/modules/2.6.x/modules.dep", que guarda uma tabela com as dependências dos módulos, ou seja, de quais outros módulos cada um precisa para ser carregado corretamente. Este último arquivo é gerado automaticamente ao rodar o comando "depmod -a". Em geral, este comando é executado de forma automática durante o boot, sempre que necessário. O "2.6.x" neste caso corresponde à versão do Kernel usado na sua máquina. 2- Se o suporte a algo essencial nas etapas iniciais do boot não está incluído no Kernel, é criado um initrd, uma imagem com os módulos necessários, que, diferentemente dos módulos especificados no "/etc/modules", são carregados logo no início do boot. O initrd é guardado na pasta /boot, junto com o executável principal do Kernel: o arquivo "vmlinuz". Imagine, por exemplo, que você está usando uma distribuição onde o suporte ao sistema de arquivos ReiserFS foi compilado como módulo, mas quer instalar o sistema justamente numa partição ReiserFS. Isso gera um problema do tipo o ovo e a galinha, já que o sistema precisa do módulo para acessar a partição, mas precisa de acesso à partição para poder ler o módulo. Para evitar este tipo de problema, o próprio instalador da distribuição, ao perceber que você formatou a partição raiz em ReiserFS, vai se encarregar de gerar o arquivo initrd que, embora não seja obrigatório (é possível compilar tudo diretamente no Kernel), é bastante usado. Os processos de boot e os arquivos de inicialização Quando você liga o micro, o primeiro software que é carregado é oBIOS da placa-mãe, que faz a contagem da memória RAM, uma detecção rápida dos dispositivos instalados e por fim carrega o sistema operacional principal a partir do HD, CD-ROM, disquete, rede, ou o que quer que seja. Este procedimento inicial é chamado dePOST (Power-on self test) Seria bom se a função do BIOS se limitasse a isso, mas na verdade ele continua residente, mesmo depois que o sistema operacional é carregado. Na época do MS-DOS era bem conhecida a divisão entre a memória real (os primeiros 640 KB da memória RAM) e a memória extendida (do primeiro MB em diante, englobando quase toda a memória instalada). O MS-DOS rodava em modo real, onde o processador trabalha simulando um 8088 (o processador usado no XT) que era capaz de acessar apenas 640 KB de memória. Mesmo os processadores modernos conservam este modo de operação, mas os sistemas operacionais atuais rodam inteiramente em modo protegido, onde são usados todos os recursos da máquina. O espaço entre os primeiros 640 KB, onde termina a memória real, e os 1024 KB, onde começa a memória extendida, é justamente reservado para o BIOS da placa-mãe. Ele é originalmente gravado de forma compactada num chip de memória flash instalado na placa-mãe. Durante o processo de boot ele é descompactado e copiado para este espaço reservado (chamado de shadow RAM), onde fica disponível.
  • 19. O BIOS oferece funções prontas para acessar o HD, acionar recursos de gerenciamento de energia e muitas outras coisas. Mas, os sistemas operacionais quase não utilizam estas funções, pois existem muitas diferenças na forma como BIOS de diferentes placas-mãe trabalham e, em muitos casos, as funções simplesmente não funcionam ou produzem erros inesperados. Os fabricantes de placas-mãe disponibilizam upgrades de BIOS freqüentemente para corrigir estes problemas, mas a maior parte dos usuários nem chega a procurá-los, fazendo com que exista um enorme contingente de placas bugadas por aí, com problemas no ACPI, DMA e outros recursos básicos. Existe até mesmo um projeto para substituir o BIOS da placa-mãe por uma versão compacta do Kernel do Linux, que executa as mesmas funções, mas de uma forma mais confiável e flexível. Você pode obter mais informações sobre ele no: http://www.linuxbios.org/. Outra tecnologia (já em uso) que substitui o BIOS é o EFI (Extensible Firmware Interface), usada em placas-mãe para o Intel Itanium e também nos Macs com processadores Intel. O EFI utiliza uma arquitetura modular, bem mais limpa e eficiente, que permite o uso de módulos personalizados para os dispositivos de cada-placa mãe, mantendo (opcionalmente) compatibilidade com o sistema antigo. No caso dos Macs, esta camada de compatibilidade é desativada (de forma a dificultar a vida de quem pretende instalar Linux ou windows em dual boot com o MacOS) mas, no caso de placas avulsas, o EFI viria com o modo de compatibilidade ativado, permitindo rodar qualquer sistema. De qualquer forma, depois de fazer seu trabalho, o BIOS carrega o sistema operacional, lendo o primeiro setor do disco rígido o "Master Boot Record" (MBR), também conhecido como trilha zero ou trilha MBR. No MBR vai o gerenciador de boot. Os dois mais usados no Linux são o lilo e o grub. Na verdade, no MBR mesmo vai apenas um bootstrap, um pequeno software que instrui o BIOS a carregar o executável do lilo ou grub em um ponto específico do HD. O MBR propriamente dito ocupa um único setor do HD (apenas 512 bytes), de modo que não é possível armazenar muita coisa diretamente nele. O gerenciador de boot utiliza os primeiros 446 bytes do MBR. Os 66 bytes restantes são usados para armazenar a tabela de partições, que guarda informações sobre onde cada partição começa e termina. Alguns vírus, além de acidentes em geral, podem danificar os dados armazenados na tabela de partição, fazendo com que pareça que o HD foi formatado. Mas, na maioria dos casos, os dados continuam lá. Mais adiante, veremos como fazer um backup da tabela de partições e restaurá-la quando necessário. Voltando ao tema inicial, o gerenciador de boot tem a função de carregar o Kernel e, a partir dele, todo o restante do sistema. O lilo e o grub podem ser configurados ainda para carregar o
  • 20. Windows ou outros sistemas instalados em dual boot. Muitas distribuições configuram isso automaticamente durante a instalação. Inicialmente, o Kernel é um arquivo compactado e somente-leitura, o arquivo "/boot/vmlinuz". Ele é descompactado em uma área reservada da memória RAM e roda a partir daí, aproveitando o fato de quea memória RAM é muito mais rápida que o HD. Este executável principal do Kernel nunca é alterado durante o uso normal do sistema, ele muda apenas quando você recompila o Kernel manualmente ou instala uma nova versão. Se você prestou atenção quando citei anecessidade de usar uminitrd quando a partição raiz do sistema está formatada num sistema de arquivos que não está compilado diretamente no Kernel, deve ter notado uma contradição aqui. Afinal é o que está sendo feito até agora. Nem o BIOS, nem o lilo possuem suporte a ReiserFS e o Kernel precisa ser carregado antes que ele tenha a chance de carregar o initrd. E, além do mais, para carregar o initrd, o próprio Kernel precisaria ler o arquivo dentro da partição. Isto tudo funciona porque tanto o BIOS quanto o lilo não procuram entender o sistema de arquivos em que o HD está formatado. Pode ser EXT2, ReiserFS, XFS, ou o que seja: para eles não faz diferença. Eles simplesmente lêem os uns e zeros gravados numa área específica do HD e assim carregam o Kernel e o initrd. Eles não fazem alterações nos dados gravados, por isso este "acesso direto" não traz possibilidade de danos às estruturas do sistema de arquivos. Depois de carregado, a primeira coisa que o Kernel faz é montar a partição raiz, onde o sistema está instalado, inicialmente como somente-leitura. Neste estágio ele carrega o init, o software que inicia o boot normal do sistema, lendo os scripts de inicialização e carregando os módulos e softwares especificados neles. O arquivo de configuração do init éo "/etc/inittab". Ele é geralmente o primeiro arquivo de configuração lido durante o boot. A principal tarefa dele é carregar os demais scripts de inicialização, usados para carregar os demais componentes do sistema e fazer todas as operações de checagem, necessárias durante o boot. No /etc/inittab do Debian por exemplo, você verá a linha: # Boot-time system configuration/initialization script. si::sysinit:/etc/init.d/rcS Esta linha executa o script "/etc/init.d/rcS". Se você examiná-lo também, vai encontrar o seguinte: for i in /etc/rcS.d/S??* do ... $i start .... done
  • 21. Os "..." indicam partes dos script que removi para deixar apenas as partes que interessam aqui. Estas linhas são um shell script, que vai executar os scripts dentro da pasta "/etc/rcS.d/". Esta pasta contém scripts que devem ser executados sempre, a cada boot, e são responsáveis por etapas fundamentais do boot. Alguns exemplos de scripts e programas executados nesta etapa são: keymap.sh: Carrega o layout do teclado que será usado no modotexto. Você não gostaria de encontrar seu teclado com as teclas trocadas para o Russo quando precisar arrumar qualquer coisa no modo texto, não é? ;-), O KDE possui um configurador próprio, o kxkb, que é configurado dentro do Painel de Controle. O layout usado pelo kxkb subscreve o configurado pelo keymap.sh dentro do KDE. checkroot.sh: Este script roda o fsck, reiserfsck ou outro programa adequado para verificar a estrutura da partição raiz (a partição onde o sistema está instalado), corrigindo erros causados por desligamentos incorretos do sistema. Este processo é análogo ao scandisk do Windows. Só depois da verificação é que a partição raiz passa a ser acessada em modo leitura e escrita. modutils: Este é o script que lê os arquivos "/etc/modules" e "/etc/modules.conf", ativando a placa de som, rede e todos os outros dispositivos de hardware "não essenciais", para os quais o suporte não foi habilitado diretamente no Kernel. Atualmente, a maioria das distribuições inclui alguma ferramenta de detecção de hardware, que é executada a cada boot, fazendo com que o arquivo "/etc/modules" sirva apenas para especificar manualmente módulos que ativem periféricos que não estejam sendo detectados automaticamente. checkfs.sh: Este script é parecido com o checkroot.sh. Ele se destina a checar as demais partições do HD. mountall.sh: É aqui que é lido o arquivo "/etc/fstab" e as demais partições, unidades de rede, e tudo mais que estiver especificado nele é ativado. Se você estiver usando uma partição home separada ou um compartilhamento de rede via NFS para guardar arquivos, por exemplo, é a partir deste ponto que eles ficarão disponíveis. networking: Ativa a rede, carregando a configuração de IP, DNS, gateway, etc., ou obtendo a configuração via DHCP. A configuração da redeé geralmente armazenada dentro da pasta "/etc/sysconfig/network-scripts/" ou no arquivo "/etc/network/interfaces", variando de acordo com a distribuição usada. De acordo com a distribuição usada, são carregados neste ponto outros serviços, para ativar suporte a placas PCMCIA, placas ISA, ou outros tipos de hardware, ativar o suporte a compartilhamentos de rede e, assim por diante. É possível executar praticamente qualquer tipo de comando ou programa nesta etapa, justamente por isso os passos executados durante o boot mudam de distribuição para distribuição, de acordo com o que os desenvolvedores consideram mais adequado. A idéia aqui é apenas dar uma base, mostrando alguns passos essenciais que são sempre executados. Depois desta rodada inicial, são executados os scripts correspondentes ao runlevel padrão do sistema, que é configurado no "/etc/inittab", na linha:
  • 22. # The default runlevel. id:5:initdefault: O número (5 no exemplo) indica o runlevel que será usado, que pode ser um número de 1 a 5. Cada runlevel corresponde a uma pasta, com um conjunto diferente de scripts de inicialização. É uma forma de ter vários "profiles", para uso do sistema em diferentes situações. A configuração mais comum é a seguinte: Runlevel 1: Single user. É um modo de recuperação onde nem o modo gráfico, nem o suporte à rede, nem qualquer outro serviço "não essencial" é carregado, de forma a minimizar a possibilidade de problemas. A idéia é que o sistema "dê boot" para que você possa corrigir o que está errado. Atualmente, uma forma mais prática para corrigir problemas é dar boot com uma distribuição em live-CD (como o Kurumin), onde você tem acesso à internet e vários programas e, a partir dele, montar a partição onde o sistema está instalado e corrigir o problema. Runlevel 3: Boot em modo texto. Neste modo todos os serviços são carregados, com exceção do gerenciador de boot (KDM ou GDM), que é responsável por carregar o modo gráfico. Este modo é muito usado em servidores. Runlevel 5: É o modo padrão na maioria das distribuições, onde você tem o sistema "completo", com modo gráfico e todos os demais serviços. Uma exceção importante é o Slackware, onde o modo gráfico é carregado no runlevel 4. Usando o runlevel 5, são carregados os scripts dentro da pasta "/etc/rc5.d/", enquanto que, usando o runlevel 3, são carregados os scripts dentro da pasta "/etc/rc3.d/". Nada impede que você modifique a organização dos arquivos manualmente, de forma a fazer o X carregar também no runlevel 3, ou qualquer outra coisa que quiser. São apenas pastas com scripts e links simbólicos dentro, nenhuma caixa preta. Ativando e desativando serviços Nas distribuições que seguem o padrão do Debian, os executáveis que iniciam os serviços de sistema ficam todos dentro da pasta "/etc/init.d/". Para parar, iniciar ou reiniciar o serviço ssh, por exemplo, use os comandos: # /etc/init.d/ssh start # /etc/init.d/ssh stop # /etc/init.d/ssh restart No Kurumin, Mandriva e algumas outras distribuições, existe o comandoservice, que facilita um pouco as coisas, permitindo que, ao invés de ter de digitar o caminho completo, você possa controlar os serviços através dos comandos:
  • 23. # service ssh start # service ssh stop # service ssh restart Os scripts que estão na pasta "/etc/init.d/" servem para "chamar" os executáveis dos servidores. Eles apenas fazem as verificações necessárias e em seguida inicializam ou encerram os executáveis propriamente ditos, que em geral estão na pasta "/usr/bin/" ou "/usr/sbin/". A pasta "/etc/init.d/" contém scripts para quase todos os serviços queestão instalados no sistema. Quando você instala o Samba pelo apt-get, por exemplo, é criado o script "/etc/init.d/samba", mesmo que ele não exista anteriormente. O que determina se o Samba será executado ou não durante o boot não é o script na pasta "/etc/init.d/", mas sim um link simbólico criado dentro de uma das pastas de inicialização. Por padrão, são executados primeiro os links que estão dentro da pasta"/etc/rcS.d/" e, em seguida, o que estiver dentro da pasta "/etc/rc5.d/" (caso o sistema esteja configurado para inicializar em runlevel 5, padrão na maioria das distribuições) ou na pasta "/etc/rc3.d/" (runlevel 3).
  • 24. Os números antes dos nomes dos serviços dentro da pasta "/etc/rc5.d/" determinam a ordem em que eles serão executados. Você vai querer que o firewall seja sempre ativado antes do Samba por exemplo. O "S" (start) indica que o serviço será inicializado no boot. A partir daí, o sistema vai inicializando um por vez, começando com os serviços com número mais baixo. Caso dois estejam com o mesmo número, eles são executados em ordem alfabética. Para que um determinado serviço pare de ser inicializado automaticamente no boot, basta deletar a entrada dentro da pasta, como em: # rm -f /etc/rc5.d/S20samba Para que o serviço volte a ser inicializado você deve criar novamente o link, apontando para o script na pasta /etc/init.d, como em: # cd /etc/rc5.d/ # ln -s ../init.d/samba S20samba ou: # ln -s ../init.d/ssh S21ssh Esta é a forma "correta" de criar os links: acessando primeiro a pastaonde eles são criados e criando os links com as localizações relativas. Se estamos na pasta "/etc/rc5.d" e criamos o link apontando para "../init.d/samba", significa que o sistema vai subir um nível de diretório (vai para o /etc) e em seguida acessa a pasta "init.d/". Nada impede que você crie o link diretamente, como em: # ln -s /etc/init.d/ssh /etc/rc5.d/S21ssh Ele vai funcionar da mesma forma, mas ferramentas de configuração automática, como o "update-rc.d" (do Debian), vão reclamar do "erro" ao atualizar ou remover o link. Este é, na verdade, um daqueles casos em que precisamos contornar manualmente a falta de recursos da ferramenta. Existe um utilitário de modo texto, do Debian, que facilita esta tarefa, o rcconf, que pode ser instalado via apt-get. Chamando-o com a opção "--now", os serviços marcados são inicializados imediatamente, caso contrário ele apenas cria os links, de forma que eles fiquem ativos a partir do próximo boot. No Fedora, Mandriva e outras distribuições derivadas do Red Hat, você pode ativar ou desativar a inicialização dos serviços no boot usando o comando "chkconfig", como em: # chkconfig ssh on (ativa) # chkconfig ssh off (desativa)
  • 25. Você pode também usar o utilitário "ntsysv" ou outro configurador disponível. O Mandriva, por exemplo, inclui um painel de administração de serviços dentro do Mandriva Control Center. Muitas distribuições incluem o "services-admin", outro utilitário gráfico que faz parte do pacote "gnome-system-tools". X Diferentemente do que temos no Windows, onde a interface gráfica é um componente essencial do sistema, no Linux o modo gráfico é uma camada independente. Temos um "servidor gráfico", o famoso X que provê a infra-estrutura necessária. É ele que controla o acesso à placa de vídeo, lê as teclas digitadas noteclado e os clicks do mouse e oferece todos os recursos necessários para os programas criarem janelas e mostrarem conteúdo na tela. Se você chamar o X sozinho, a partir do modo texto (o que pode ser feito com o comando "X" ou "X :2" caso você queira abrir uma segunda seção do X), você verá apenas uma tela cinza, com um X que representa o cursor do mouse. Ou seja, o X é apenas uma base, ele sozinho não faz muita coisa. Se você chamá-lo com o comando "xinit" ou "xinit -- :2", você já abrirá junto uma janela de terminal, que poderá ser usada para abrir programas. Porém, ao abrir qualquer programa gráfico, você perceberá que algo está estranho. A janela do programa é aberta, mas fica fixa na tela, você não tem como minimizá-la, alternar para outra janela, nem nenhuma outra opção: Isto acontece porque estas tarefas são controladas pelo gerenciador de janelas, que (em quase todas as distribuições) não é carregado com o comando xinit. Existem vários gerenciadores de janelas, como o KDE, Gnome, Window Maker, Fluxbox, IceWM e assim por diante. A idéia é que você possa escolher qual lhe agrada mais.
  • 26. Chamando o X através do comando "startx", ou configurando o sistema para carregar o X automaticamente durante a inicialização, finalmente carregamos o conjunto completo,com o X e algum gerenciador de janelas rodando sobre ele. O Xfree utiliza uma arquitetura cliente-servidor, onde o X em si atua como o servidor e os programas como clientes, que recebem dele os clicks do mouse e as teclas digitadas no teclado e enviam de volta as janelas a serem mostradas na tela. A grande vantagem deste sistema é que além de rodar programas localmente é possível rodar programas instalados em outras máquinas da rede. Existem várias formas de fazer isto. Você pode, por exemplo, abrir uma janela de terminal dentro do X, conectar-se à outra máquina, via SSH e começar a chamar os programas desejados. Para isso, use o comando "ssh-X IP_da_maquina", como em: # ssh -X 192.168.0.1 O parâmetro -X ativa a execução de aplicativos gráficos via SSH, que vem desativado por padrão em algumas distribuições. Para usar o ssh, o serviço "ssh" deve estar ativo na máquina que está sendo acessada. Outra opção é usar o XDMCP, o protocolo nativo do X para obter a tela de login da máquina remota e a partir daí carregar um gerenciador de janelas e rodar todos os programas via rede. Neste caso você precisaria configurar a outra máquina para aceitar as conexões via XDMCP nos arquivos kdmrc e Xaccess, que vão dentro da pasta "/etc/kde3/kdm/" ou "/usr/share/config/kdm/kdmrc" (ao usar o KDM) ou no gdmsetup (ao usar o GDM) e inicializar o X com o comando "X :2 -query IP_da_maquina" no PC cliente, como em: # X :2 -query 192.168.0.1 Muita gente diz que este sistema cliente/servidor do X é uma arquitetura ultrapassada, que é responsável por um desempenho ruim se comparado com outros sistemas operacionais, pois tudo teria que passar pela rede antes de ir para o monitor. Esta idéia é errada, pois, ao rodar localmente, o X se comunica diretamente com a placa de vídeo, usando todos os recursos de aceleração suportados. Entra aí a questão do driver. Se você tentar rodar um game 3D qualquer, antes de instalar os drivers 3D (da nVidia) para sua placa nVidia, por exemplo, ele vai rodar com um desempenho muito baixo, simplesmente porque os recursos 3D da placa não estão ativados. O driver open-source do X para placas nVidia (o driver "nv") oferece apenas suporte 2D. Algumas placas realmente não possuem ainda drivers 3D no X, como, por exemplo, a maior parte das placas onboard da SiS. Isto tem mais a ver com a boa vontade (ou falta desta) do fabricante em desenvolver drivers ou pelo menos disponibilizar as especificações das placas. A SiS é um dos fabricantes mais hostis, o que faz com que suas placas tenham um suporte ruim. Como sempre é questão de pesquisar antes de comprar. Os comandos de atualização das janelas e outros recursos usados são transmitidos pelo X através de uma interface de rede local (a famosa interface de loopback), o que num PC
  • 27. moderno tem um overhead muito pequeno. Os problemas de desempenho em algumas placas estão mais relacionados à qualidade dos drivers. Gerenciador de login Antigamente, era muito comum dar boot em modo texto e deixar para abrir o X manualmente rodando o comando "startx" apenas quando necessário, pois os PCs eram lentos e o X demorava para abrir. Atualmente, o mais comum é usar um gerenciador de login, como oKDM (do KDE) ou o GDM (do Gnome). A função do gerenciador de login é carregar o X, mostrar uma tela de login gráfica e, a partir dela, carregar o KDE, Gnome ou outro gerenciador de janelas escolhido. Em geral, as distribuições que usam o KDE como interface padrão usam o KDM, enquanto as que usam o Gnome preferem o GDM. Isto tem a ver com o problema das bibliotecas: ao carregar apenas um programa baseado nas bibliotecas do KDE dentro do Gnome ou vice-versa, são carregadas todas as bibliotecas correspondentes, não há o que fazer.O programa demora mais para abrir, e no final, o sistema acaba consumindo muito mais memória. O gerenciador de login é aberto como um serviço de sistema, da mesma forma que o Apache e outros servidores. Você pode parar o KDM e assim fechar o modo gráficousando o comando "/etc/init.d/kdm stop" e reabri-lo a partir do modo texto com o comando "/etc/init.d/kdm start". Como sempre, tudo é aberto através de um conjunto de scripts. O KDM guarda a base das configurações no arquivo "/etc/kde3/kdm/kdmrc" (ou "/usr/share/config/kdm/kdmrc", dependendo da distribuição) e coloca um conjunto de scripts de inicialização, um para cada interface instalada, dentro da pasta "/usr/share/apps/kdm/sessions/". A configuração do kdmrc serve para configurar as opções da tela de login, que vão desde opções cosméticas, até a opção de aceitar que outras máquinas da rede rodem aplicativos remotamente via XDMCP. Ao fazer login, é executado o script correspondente à interface escolhida. Ao usar o Fluxbox, por exemplo, é executado o script "/usr/share/apps/kdm/sessions/fluxbox". Até mesmo o comando startx é um script, que geralmente vai na pasta "/usr/X11R6/bin/". Você pode alterá-lo para carregar o que quiser, mas normalmente ele carrega o gerenciador especificado no arquivo .xinitrc, dentro da pasta home do usuário. Xfree e Xorg Atualmente estão em uso no mundo Linux duas versões diferentes do X, oXfree e o X.org. O Xfree é o projeto mais antigo e tradicional, o grupo que originalmente portou o X para o Linux, e foi o principal mantenedor do projeto desde então. Com o passar do tempo, começaram a surgir críticas, principalmente direcionadas à demora para incluir correções e atualizações nos drivers existentes. Isto foi se agravando com o tempo, até que uma decisão dos desenvolvedores em fazer uma pequena mudança na licença em
  • 28. vigor a partir do Xfree 4.4 foi a gota d'água para que um consórcio formado por membros de várias distribuições, desenvolvedores descontentes com o modo de desenvolvimento antigo, se juntassem para criar um fork do Xfree, o X.org. O X.org utilizou como base inicial a última versão de desenvolvimento da série 4.3 do Xfree, disponibilizada antes da mudança da licença. Desde então, foram incluídas muitas atualizações e correções, como novos drivers e vários recursos cosméticos, como, por exemplo, suporte a janelas transparentes. A página oficial é a http://x.org. Inicialmente, as diferenças eram pequenas, mas depois de um certo tempo o X.org passou a concentrar a maior parte das atualizações enovos drivers, sendo desenvolvido num ritmo muito mais rápido. A tendência é que ele substitua completamente o Xfree num futuro próximo. A partir da versão 7.0, o X.org passou a utilizar uma arquitetura modular, que visa facilitar o desenvolvimento de novos recursos, que podem ser integrados ao sistema na forma de módulos, sem depender do aval prévio dos desenvolvedores do X.org. Esta mudança, que à primeira vista parece simples, tem potencial para intensificar o desenvolvimento de forma radical. Para quem configura, a principal diferença está nos nomes do arquivo de configuração e utilitários. As opções dentro do arquivo continuam as mesmas, incluindo os nomes dos drivers (radeon, nv, intel, sis, etc.) e é possível inclusive usar um arquivo de configuraçãode uma distribuição com o Xfree em outra (instalada na mesma máquina) com o X.org. Aqui vai uma pequena tabela com algumas diferenças: - Arquivo de configuração principal: /etc/X11/XF86Config-4 = /etc/X11/xorg.conf - Utilitários de configuração: xf86cfg = xorgfg xf86config = xorgconfig É possível também eliminar estas diferenças criando um conjunto de links apontando para os nomes trocados. Assim o XF86Config-4 vira um link para o xorg.conf, por exemplo, fazendo com que usuários desavisados e até utilitários de configuração consigam encontrar os arquivos sem muitos problemas. A árvore genealógica das distribuições Por causa da filosofia de código aberto e compartilhamento de informações que existe no mundo Linux, é muito raro que uma nova distribuição seja desenvolvida do zero. Quase sempre as distribuições surgem como forks ou personalizações de uma outra distribuição mais antiga e preservam a maior parte das características da distribuição original. Isso faz com que distribuições dentro da mesma linhagem conservem mais semelhanças do que diferenças entre si.
  • 29. Das primeiras distribuições Linux, que surgiram entre 1991 e 1993, a única que sobrevive até hoje é o Slackware, que deu origem a algumas outras distribuições conhecidas, como o Vector, Slax e o College. O Slax é um live-CD, desenvolvido para caber em um mini-CD; o Vector é uma distribuição enxuta, otimizada para micros antigos, enquanto o College é uma distribuição desenvolvida com foco no público estudantil, com o objetivo de ser fácil de usar. Os três utilizam pacotes .tgz do Slackware e são quase sempre compatíveis com os pacotes do Slackware da versão correspondente. Os utilitários de configuração do Slackware, como o netconfig continuam disponíveis, junto com vários novos scripts que facilitam a configuração do sistema. O Vector, por exemplo, inclui o Vasm, uma ferramenta central de configuração. O Debian apareceu pouco depois e, ao longo dos anos, acabou dando origem a quase metade das distribuições atualmente em uso. Algumas, como o Knoppix e o Kurumin, continuam utilizando os pacotes dos repositórios Debian, apenas acrescentando novos pacotes e ferramentas, enquanto outras, como o Lycoris e o Ubuntu, utilizam repositórios separados, apenas parcialmente compatíveis com os pacotes originais, mas sempre mantendo o uso do apt-get e a estrutura básica do sistema. Embora o Debian não seja exatamente uma distribuição fácil de usar, o apt-get e o gigantesco número de pacotes disponíveis nos repositórios formam uma base muito sólida para o desenvolvimento de personalizações e novas distribuições. Um dos principais destaques é que, nas versões Testing e Unstable, o desenvolvimento do sistema é contínuo e, mesmo no Stable, é possível atualizar de um release para outro sem reinstalar nem fazer muitas modificações no sistema. Você pode manter o sistema atualizado usando indefinidamente o comando "apt-get upgrade". Isso permite que os desenvolvedores de distribuições derivadas deixem o trabalho de atualização dos pacotes para a equipe do Debian e se concentrem em adicionar novos recursos e corrigir problemas. Um dos exemplos de maior sucesso é o Knoppix, que chega a ser um marco. Ele se tornou rapidamente uma das distribuições live-CD mais usadas e deu origem a um universo gigantesco de novas distribuições, incluindo o Kurumin. Uma coisa interessante é que o Knoppix mantém a estrutura Debian quase intacta, o que fez com que instalar o Knoppix no HD acabasse tornando-se uma forma alternativa de instalar o Debian. Outro exemplo de sucesso é o Ubuntu, uma versão do Debian destinada a iniciantes e a empresas, que rapidamente se transformou em umas das distribuições mais usadas no mundo. As distribuições derivadas do Knoppix muitas vezes vão além, incluindo novos componentes que tornam o sistema mais adequado para usos específicos. O Kurumin inclui muitas personalizações e scripts destinados a tornar o sistema mais fácil de usar e mais adequado para uso em desktop. O Kanotix inclui muitos patches no Kernel, com o objetivo de oferecer suporte a mais hardware e novos recursos,enquanto o Morphix usa uma estrutura modular, que acabou servindo de base para o desenvolvimento de mais uma safra de distribuições, já bisnetas do Debian.
  • 30. Mais adiante, teremos um capítulo dedicado a explicar o processo de personalização do Kurumin e outros live-CDs derivados do Knoppix, permitindo que você desenvolva suas próprias soluções. Tanto o Debian quanto o Slackware são distribuições basicamente não comerciais. Mas isso não impede que distribuições como o Lycoris, Xandros e Linspire sejam desenvolvidas por empresas tradicionais, com fins lucrativos. Elas procuram se diferenciar das distribuições gratuitas, investindo em marketing e no desenvolvimento de ferramentas de configuração e facilidades em geral. Durante o livro, vou sempre citar muitos comandos que se aplicam ao Debian, lembre-se de que eles também se aplicam à outras distribuições derivadas dele, como o Ubuntu, Kurumin e o Knoppix. A terceira distribuição "mãe" é o Red Hat, que deu origem ao Mandrake e Conectiva (que mais tarde se juntaram, formando o atual Mandriva), Fedora e, mais recentemente, a um enorme conjunto de distribuições menores. As distribuições derivadas do Red Hat não utilizam um repositório comum, como no caso do Debian, e nem mesmo um gerenciador de pacotes comum. Temos o yun do Fedora, o urpmi do Mandriva e também o próprio apt-get, portado pela equipe do Conectiva. Temos ainda vários repositórios independentes, que complementam os repositórios oficiais das distribuições. As distribuições derivadas do Red Hat são, junto com o Debian e derivados, as mais usadas em servidores. O Fedora, Red Hat e SuSE possuem também uma penetração relativamente grande nos desktops nas empresas, enquanto o Mandriva tem o maior público entre os usuários domésticos. Embora todas estas distribuições utilizem pacotes rpm, não existe garantia de compatibilidade entre os pacotes de diferentes distribuições. Os pacotes de uma versão recente do SuSE na maioria das vezes funcionam também numa versão equivalente do Mandriva, por exemplo, mas isto não é uma regra. O Gentoo inaugurou uma nova linhagem trazendo uma abordagem diferente das demais distribuições para a questão da instalação de programas e instalação do sistema. Tradicionalmente, novos programas são instalados através de pacotes pré-compilados, que são basicamente arquivos compactados, contendo os executáveis, bibliotecas e arquivos de configuração usados pelo programa. Estes pacotes são gerenciados pelo apt-get, urpmi, yun ou outro gerenciador usado pela distribuição. Compilar programas a partir dos fontes é quase sempre um último recurso para instalar programas recentes, que ainda não possuem pacotes disponíveis. O Gentoo utiliza o Portage, um gerenciador de pacotes que segue a idéia dos ports do FreeBSD. Os pacotes não contém binários, mas sim o código fonte do programa, junto com um arquivo com parâmetros que são usados na compilação. Você pode ativar as otimizações que quiser, mas o processo de compilação e instalação é automático. Você pode instalar todo o KDE, por exemplo, com um "emergekde". O Portage baixa os pacotes com os fontes (de forma similar ao apt-get), compila e instala.
  • 31. O ponto positivo desta abordagem é que você pode compilar todo o sistema com otimizações para o processador usado na sua máquina. Isso resulta em ganhos de 2 a5% na maior parte dos programas, mas pode chegar a 30% em alguns aplicativos específicos. A parte ruim é que compilar programas grandes demora um bocado, mesmo em máquinas atuais. Instalar um sistema completo, com o X, KDE e OpenOffice demora um dia inteiro num Athlon 2800+ e pode tomar um final de semana numa máquina um pouco mais antiga. Você pode usar o Portage também para atualizar todo sistema, usando os comandos "emerge sync && emerge -u world" de uma forma similar ao "apt-get upgrade" do Debian. Nas versões atuais do Gentoo, você pode escolher entre diferentes modos de instalação. No stage 1 tudo é compilado a partir dos fontes, incluindo o Kernel e as bibliotecas básicas. No stage 2 é instalado um sistema base pré-compilado e apenas os aplicativos são compilados. No stage 3 o sistema inteiro é instalado a partir de pacotes pré-compilados, de forma similar a outras distribuições. A única exceção fica por conta do Kernel, que sempre precisa ser compilado localmente, mesmo ao usar o stage 2 ou 3. O stage 1 é naturalmente a instalação mais demorada, mas é onde você pode ativar otimizações para todos os componentes do sistema. Já existe um conjunto crescente de distribuições baseadas no Gentoo, como vários live-CDs, com games e versões modificadas do sistema, alguns desenvolvidos pela equipe oficial, outros por colaboradores. Uma das primeiras distribuições a utilizar o Gentoo como base foi o Vidalinux. Embora seja uma das distribuições mais difíceis, cuja instalação envolve mais trabalho manual, o Gentoo consegue ser popular entre os usuários avançados, o que acabou por criar uma grande comunidade de colaboradores em torno do projeto. Isto faz com que o Portage ofereça um conjunto muito grande de pacotes, quase tantos quanto no apt-get do Debian, incluindo drivers para placas nVidia e ATI, entre outros drivers proprietários, e exista uma grande quantidade de documentação disponível, com textos quase sempre atualizados. Capítulo 2: Configuração, ferramentas e dicas A melhor forma de aprender é sempre praticando, certo? Este capítulo é uma coleção de dicas sobre os arquivos de configuração, ferramentas e utilitários úteis, que tem o objetivo de aprofundar seus conhecimentos sobre o sistema. Os tópicos estão organizados por nível de dificuldade. Editando o /etc/fstab O arquivo "/etc/fstab" permite configurar o sistema para montar partições, CD-ROMs, disquetes e compartilhamentos de rede durante o boot. Cada linha é responsável por um ponto de montagem. É através do "/etc/fstab" que o sistema é capaz de acessar oseu CD- ROM, por exemplo. O fstab é um dos arquivos essenciais para o funcionamento do sistema, por isso, antes de editá-lo, faça sempre uma cópia de segurança: # cp /etc/fstab /etc/fstab-original
  • 32. O fstab é um arquivo de texto simples, assim como a maior parte dos arquivos de configuração do sistema. Você pode abri-lo usando qualquer editor de textos, mas sempre como root: # kedit /etc/fstab À primeira vista o fstab parece ser mais um daqueles arquivos indecifráveis. Ele possui uma lógica própria que pareceum pouco complicada no início, mas é relativamente fácil de entender. Uma vez que você entenda a sintaxe das opções, você poderá editar o fstab para adicionar um segundo drive de CD ou fazer com que um compartilhamento de rede seja montado automaticamentedurante o boot, sem depender de configuradores automáticos. Vamos começar dando uma olhada no "/etc/fstab" de uma máquina que está com o Kurumin instalado na partição hda2: # /etc/fstab: filesystem table. # filesystem mountpoint type options dump pass /dev/hda2 / reiserfs defaults 0 1 /dev/hda5 none swap sw 0 0 proc /proc proc defaults 0 0 /dev/fd0 /floppy vfat defaults,user,noauto,showexec,umask=022 0 0 /dev/cdrom /mnt/cdrom iso9660 defaults,ro,user,noexec,noauto 0 0 # partições encontradas pelo instalador: /dev/hda1 /mnt/hda1 reiserfs noauto,users,exec 0 0 /dev/hda2 /mnt/hda2 reiserfs noauto,users,exec 0 0 /dev/hda3 /mnt/hda3 reiserfs noauto,users,exec 0 0 /dev/hda6 /mnt/hda6 reiserfs noauto,users,exec 0 0 # Monta a partição /home, adicionado pelo instalador do Kurumin /dev/hda3 /home reiserfs notail 0 2 # Ativa o USB usbdevfs /proc/bus/usb usbdevfs defaults 0 0 Este é o arquivo gerado automaticamente durante a instalação, por isso ele está um pouco sujo. Vamos começar entendo o que cada linha significa.Lembre-se de que as linhas começadas com # não fazem nada, são apenas comentários. /dev/hda2 / reiserfs defaults 0 1 Esta linha monta o diretório raiz do sistema. No exemplo, o Kurumin está instalado na partição /dev/hda2 que está formatada em ReiserFS. O"/" é o ponto de montagem, ou seja, onde esta partição fica acessível. A barra indica que esta é a partição raiz, onde o sistema está instalado. Se, por acaso, a partição estivesse formatada em outro sistema de arquivos, em EXT3, por exemplo, a linha ficaria: "/dev/hda2 / ext3 defaults 0 1". Os dois números depois do "defaults" são instruções para programas externos.
  • 33. O primeiro número é usado pelo programadump, que examina a partição em busca de arquivos modificados. Esta informação é usada por alguns programas de backup, para decidir quais arquivos devem ser incluídos num backup incremental. O número0 desativa e o número 1 ativa a checagem. O dump só trabalha em partições EXT2 ou EXT3, de forma que ao usar uma partição em ReiserFS ou XFS você sempre deveusar o número 0. O segundo número (1 no exemplo) é uma instrução para ofsck, encarregado de examinar os arquivos dentro da partição quando o sistema é desligado incorretamente. Temos três opções aqui: o número 0 desativa a checagem a cada boot (torna o boot um pouco mais rápido, mas não é recomendável), enquanto o número1 faz com que a partição seja checada antes das demais. Usamos o número 1 apenas para a partição raiz, onde o sistema está instalado. Para as demais partições usamos o número 2 que indica que a partição deve ser checada, porém só depois da partição raiz. /dev/hda5 none swap sw 0 0 Esta segunda linha é responsável por ativar a memória swap, que no meu caso é a partição /dev/hda5. Veja que o ponto de montagem para ela é "none", pois apartição swap não é montada em nenhuma pasta, ela serve apenas para uso interno do sistema. /dev/cdrom /mnt/cdrom iso9660 defaults,user,noauto 0 0 Esta linha habilita o drive de CD-ROM. O /dev/cdrom é o dispositivo do CD-ROM, na verdade um link que é criado durante a configuração inicial do sistema e aponta para a localização correta do CD-ROM. De acordo com a porta em que o CD-ROM estiver instalado, o dispositivo real do CD-ROM pode ser: /dev/hdc: Um CD-ROM instalado como master na segunda porta IDE da placa-mãe. /dev/hdd: CD-ROM instalado como slave na segunda porta IDE /dev/sda ou /dev/sr0: Em distribuições que usam o Kernel 2.4, os gravadores de CD IDE são detectados pelo sistema como se fossem discos SCSI. Dependendo da distribuição eles podem ser detectados como "/dev/sda" ou "/dev/sr0". Caso você tenha dois gravadores, o segundo é reconhecido como "/dev/sdb" ou "/dev/sr1". No Kernel 2.6, não é mais usada a emulação SCSI, de forma que os gravadores são acessados diretamente através dos dispositivos "/dev/hdc" ou "/dev/hdd". /dev/sr0 ou /dev/sr1: Leitores e gravadores de CD USB também são detectados como CDs SCSI. Ao plugar um drive externo ligado à porta USB, ele será detectado como "/dev/sr0" (ou "/dev/sr1", caso a primeira posição já esteja ocupada). No caso dos leitores e gravadores USB, não importa se está sendo usado o Kernel 2.4 ou 2.6. Para que os arquivos do CD-ROM fiquem acessíveis, ele precisa ser montado em algum lugar. A próxima entrada da linha é o "/mnt/cdrom", que indica a pasta onde ele fica acessível. O
  • 34. iso9660 é o sistema de arquivos universalmente usado em CD-ROMs de dados, é graças a ele que não existem problemas para ler o mesmo CD no Linux ou Windows. Em seguida temos três opções: defaults,user,noauto. Elas fazem o seguinte: user: Permite que você monte e desmonte o CD-ROM mesmo sem estar logado como root. noauto: faz com que o CD-ROM seja montado apenas quando você for acessá-lo e não automaticamente durante o boot, como no caso da partição raiz, por exemplo. Caso você queira ativar um segundo drive de CD, adicionaria uma linha assim: /dev/hdd /mnt/cdrom1 iso9660 defaults,user,noauto 0 0 Veja que mudaram duas coisas: o dispositivo do CD-ROM (/dev/hdd) e a pasta onde ele fica acessível (/mnt/cdrom1). Para acessar o segundo CD-ROM, você digitaria "mount /mnt/cdrom1" O KDE oferece um recurso muito interessante que é a possibilidade de montar e desmontar as entradas incluídas no /etc/fstab através de ícones no desktop, como os usados para acessar as partições do HD ao rodar o Kurumin do CD. Para criar um destes ícones, clique com o botão direito sobre a área de trabalho e vá em: "Criar novo", escolha "Disco rígido ou CD-ROM" e aponte a entrada do fstab referente a ele nas propriedades: Para montar e acessar os arquivos, basta clicar sobreo ícone e para desmontar, clique com o botão direito e escolha "desmontar".
  • 35. A linha seguinte do arquivo serve para montar a partição home, que no exemplo foi colocada em uma partição separada: /dev/hda3 /home reiserfs notail 0 2 Traduzindo para o português, a linha diz: "Monte a partição /dev/hda3 no diretório /home. Esta partição está formatada em reiserfs e você deve usar a opção notail". O notail é uma opção do sistema de arquivos ReiserFS, que melhora um pouco a velocidade de acesso ao trabalhar com arquivos grandes. Cada sistema de arquivos possui algumas opções extras, que podem ser usadas para melhorar o desempenho ou tolerância a falhas em determinadas situações. O parâmetro "noatime", por exemplo, faz com que o sistema não atualize as propriedades dos arquivos conforme eles ao acessados (altera apenas quando eles são modificados). Ela melhora absurdamente o desempenho do sistema em algumas áreas específicas, onde os mesmos arquivos são acessados continuamente, como nos servidores de banco de dados. É muito comum combinar as duas opções, como em: /dev/hda3 /home reiserfs notail,noatime 0 2 Usar uma partição home separada permite que você possa reinstalar o sistema sem perder seus arquivos e configurações, o que é especialmente interessante nocaso do Kurumin e outras distribuições atualizadas freqüentemente. Usando um diretório home separado, as reinstalações tornam-se mais transparentes. Você ainda precisa reinstalar os programas, mas todas as configurações dos aplicativos são preservadas. Cada programa armazena suas configurações dentro de uma pasta oculta dentro do seu diretório de usuário, como ".mozilla", ".kde", etc. Mesmo ao reinstalar o sistema, estas pastas são reconhecidas e as configurações antigas preservadas. Basta tomar o cuidado de guardar também todos os seus arquivos dentro do diretório home e você não perderá quase nada ao reinstalar.
  • 36. Continuando, temos as entradas para outras partições que foram encontradas pelo instalador: # partições encontradas pelo instalador: /dev/hda1 /mnt/hda1 reiserfs noauto,users,exec 0 0 /dev/hda2 /mnt/hda2 reiserfs noauto,users,exec 0 0 /dev/hda3 /mnt/hda3 reiserfs noauto,users,exec 0 0 /dev/hda6 /mnt/hda6 reiserfs noauto,users,exec 0 0 Veja que as partições "/dev/hda2" e "/dev/hda3" já estão sendo usadas, por isso as duas linhas referentes a elas são redundantes e podem ser removidas. As linhas para as outras duas partições, "/dev/hda1" (uma instalação do Mandriva) e "/dev/hda6" (uma partição de arquivos) estão com a opção "noauto", como no caso do CD-ROM, que faz com que elas sejam montadas apenas quando você clica nos ícones do desktop. Se você preferir que elas sejam montadas automaticamente durante o boot, basta eliminar esta opção. Neste caso as linhas ficariam assim: /dev/hda1 /mnt/hda1 reiserfs users,exec 0 0 /dev/hda6 /mnt/hda6 reiserfs users,exec 0 0 Além de montar as partições e CD-ROMs locais, o fstab pode ser configurado para montar também compartilhamentos de rede. Você pode tanto configurar para que os compartilhamentos fiquem acessíveis automaticamente durante o boot (no caso de um servidor que fique sempre ligado) ou montá-los através de ícones no desktop, como no caso do CD-ROM. Para montar um compartilhamento de rede NFS, a linha seria: 192.168.0.1:/home/arquivos /mnt/arquivos nfs noauto,users,exec 0 0 Neste exemplo o "192.168.0.1:/home/arquivos" é o IP do servidor, seguido pela pasta compartilhada e o "/mnt/arquivos" é a pasta local onde este compartilhamento ficará acessível. Você pode incluir várias linhas, caso deseje montar vários compartilhamentos. Caso o servidor fique sempre ligado e você queira que o compartilhamento seja montado automaticamente durante o boot, retire o "noauto", caso contrário você pode acessar o compartilhamento usando o comando: # mount /mnt/arquivos Para montar um compartilhamento de rede Windows ou de um servidor Linux rodando o Samba, a linha seria: //192.168.0.1/teste /home/teste smb noauto,user,username=maria,password=abcde 0 0 Veja que neste caso a sintaxe já é um pouco mais complicada. Em primeiro lugar,a entrada que fala sobre o compartilhamento usa a sintaxe: "//ip_do_servidor/compartilhamento", por isso você usa "//192.168.0.1/teste" e não "192.168.0.1:/teste" como seria num compartilhamento NFS.
  • 37. Em seguida vem a pasta onde o compartilhamento ficará acessível, "/home/teste" no exemplo. Não se esqueça de criar a pasta, caso não exista. O smb é o nome do protocolo usado para acessar os compartilhamentos Windows da rede. Outra etapa importante é colocar o usuário e senha que será usado para acessar o compartilhamento, como em: "user,username=maria,password=abcde". Caso o compartilhamento não use senha (como os compartilhamentos do Windows 95/98), a linha fica mais simples: //192.168.0.1/arquivos /home/arquivos smb noauto,user 0 0 Assim como no caso do NFS, para montar o compartilhamento use o comando: # mount /home/arquivos Se preferir que ele seja montado durante o boot, basta retirar o "noauto". Neste caso a linha no fstab ficaria: //192.168.0.1/teste /home/teste smb user,username=maria,password=abcde 0 0 Ao colocar as senhas dos compartilhamentos de rede no "/etc/fstab" é necessário tomar uma precaução de segurança. Rode o comando: # chmod 600 /etc/fstab Isto fará com que apenas o root possa ler o arquivo e conseqüentemente ver as senhas. O default na maioria das distribuições é 644, o que permite que os outros usuários da máquina possam ler o arquivo, uma grande brecha de segurança neste caso. Uma coisa que você deve ter percebido é que o KDE só oferece a opção de criar ícones para montar partições, disquetes e CD-ROMs, mas não para criar ícones para montar compartilhamentos de rede. Mas é possível criar os ícones manualmente. Os ícones do KDE, incluindo os do desktop e do iniciar, são arquivos de texto comuns, cujo nome termina com .desktop. Isto faz com que o KDE os veja como ícones, e não simples arquivos de texto. Naturalmente estes arquivos possuem uma sintaxe especial, mas nada tão exótico. Em primeiro lugar, o desktop no KDE corresponde à pasta Desktop, dentro do seu diretório de usuário, como em "/home/kurumin/Desktop". Para criar um novo ícone no desktop basta criar um arquivo de texto, cujo nome termine com ".desktop": $ kedit /home/carlos/Desktop/compartilhamento.desktop Dentro do novo arquivo, vai o seguinte: [Desktop Entry] Type=FSDevice Dev=192.168.1.34:/arquivos MountPoint=/mnt/nfs
  • 38. FSType=nfs ReadOnly=0 Icon=hdd_mount UnmountIcon=hdd_unmount Name=192.168.1.34:/arquivos O "192.168.1.34:/mnt/hda6" é o endereço do compartilhamento e o "nfs" é o protocolo. O "/mnt/nfs" é a pasta onde ele ficará acessível. O texto que vai na opção "Name" é o nome que aparecerá no desktop, você pode usar qualquer texto. No meu caso simplesmente repeti o endereço do compartilhamento para facilitar a identificação. Para um compartilhamento Windows o texto seria: [Desktop Entry] Type=FSDevice Dev=//192.168.1.34/arquivos MountPoint=/mnt/samba FSType=smb ReadOnly=0 Icon=hdd_mount UnmountIcon=hdd_unmount Name=arquivos Salvando o arquivo, o ícone já aparecerá no desktop e se comportará da mesma forma que o do CD-ROM. Basta clicar para ver os arquivos ou acionar o "desmontar" para desativar: Configurando o lilo O lilo e o grub disputam o posto de gerenciador de boot default entre as distribuições Linux. O lilo é o mais antigo e mais simples de configurar, enquanto o grub éo que oferece mais opções. Mas, ao invés de ficar discutindo qual é melhor, vamos aprender logo a configurar e resolver problemas nos dois :-). O lilo utiliza um único arquivo de configuração, o "/etc/lilo.conf". Ao fazer qualquer alteração neste arquivo é preciso chamar (como root) o executável do lilo, o "/sbin/lilo" ou simplesmente "lilo" para que ele leia o arquivo e salve as alterações. Vamos começar entendendo a função das linhas de uma configuração típica. Abra o arquivo "/etc/lilo.conf" da sua máquina e acompanhe opção a opção. boot=/dev/hda
  • 39. Esta é quase sempre a primeira linha do arquivo. Ela indica onde o lilo será instalado. Indicando um dispositivo, como em "/dev/hda", ele é instalado na trilha MBR do HD. Indicando uma partição, como em "/dev/hda1" ele é instalado no primeiro setor da partição, sem reescrever a MBR. Ao instalar vários sistemas no HD, seja Linux e Windows ou várias distribuições diferentes, apenas um deles deve ter o lilo gravado na MBR. Este terá a função de inicializar todos os outros, cujos gerenciadores foram instalados nas respectivas partições. Ao verificar esta linha, lembre-se de verificar qual é o dispositivo do HD na sua instalação. Um HD serial ATA, por exemplo, será detectado como "/dev/sda" e não como "/dev/hda". Se você tiver dois HDs, e estiver instalando o sistema numa partição do segundo ("/dev/hdb1", por exemplo), e usar a linha "boot=/dev/hdb", o lilo será instalado no MBR do segundo HD, não do primeiro. Durante o boot, o BIOS vai continuar lendo o MBR do primeiroHD, fazendo com que continue sendo carregado o sistema antigo. Se você quiser que o sistema instalado no segundo HD passe a ser o principal, use a linha "boot=/dev/hda", que gravará no MBR do primeiro HD. bitmap = /boot/kurumin.bmp bmp-colors = 255,9,;9,255, bmp-table = 61,15,1,12 bmp-timer = 73,29,255,9 Estas linhas ativam o uso de uma imagem como pano de fundo da tela de boot, ao invés do feio menu em texto, ainda usado em algumas distribuições. Veremos mais detalhes sobre este recurso logo a seguir. vga=788 Esta é uma das linhas mais importantes do arquivo, que ajusta a resolução de vídeo em modo texto (usando frame-buffer). Use "vga=785" para 640x480, "vga=788" para 800x600, "vga=791" para 1024x768 ou "vga=normal" para desabilitar o frame-buffer e usar o modo texto padrão. Quase todas as placas de vídeo suportam frame-buffer, pois ele utiliza resoluções e recursos previstos pelo padrão VESA. Apesar disso, algumas placas, mesmo modelos recentes, suportam apenas 800x600. Ao tentar usar 1024x768 num destesmodelos, o sistema exibe uma mensagem no início do boot, avisando que o modo não é suportado e o boot continua em texto puro. O "vga=788" é um valor "seguro", que funciona em praticamente todas as placas e monitores. O lilo pode ser configurado para inicializar vários sistemas operacionais diferentes. A linha "prompt" faz com que ele mostre um menu com as opções disponíveis na hora do boot. Ela é quase sempre usada por padrão. A linha "default=" diz qual é o sistema padrão, o que fica pré- selecionado na tela de boot.