Livro Linux-Ferramentas Técnicas

366 visualizações

Publicada em

Livro de dicas de configuração no Linux.

Publicada em: Tecnologia
0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
366
No SlideShare
0
A partir de incorporações
0
Número de incorporações
2
Ações
Compartilhamentos
0
Downloads
20
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Livro Linux-Ferramentas Técnicas

  1. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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.

×