Linux - Ferramentas técnicas 2ed.

Linux: Ferramentas técnicas  2ª edição Capa

Este livro é uma coleção de dicas que ensinam a configurar e corrigir problemas "na unha", manipulando diretamente os arquivos de configuração e módulos do sistema, sem depender de nenhum configurador, escrever shell scripts, instalar drivers manualmente e dominar ferramentas de diagnóstico e recuperação do sistema. Por ser escrito em uma linguagem simples e didática e com um nível crescente de dificuldade, este livro é indicado tanto para usuários avançados que querem expandir seus conhecimentos, quanto para iniciantes que desejam compreender mais profundamente o sistema. Autor: Carlos E. Morimoto Páginas: 312 Formato: 23 x 16 cm Editora: GDH Press e Sul Editores ISBN: 85-205-0401-9 Lançado em: Março de 2006

Descrição As distribuições Linux estão de um modo geral se tornando muito fáceis de usar, em algumas áreas até mesmo mais fáceis de usar que o Windows. Mas, isso acaba deixando um gosto amargo na boca. Afinal, onde está o desafio? Em outros casos as coisas não funcionam tão bem assim e o gosto amargo fica por conta do modem, webcam, placa 3D ou placa wireless que não está funcionando ou outro problema qualquer, que não pode ser solucionado usando as ferramentas gráficas. Este livro é uma coleção de dicas que ensinam a configurar e corrigir problemas "na unha", manipulando diretamente os arquivos de configuração e módulos do sistema, sem depender

de nenhum configurador, escrever shell scripts, instalar drivers manualmente e dominar ferramentas de diagnóstico e recuperação do sistema. É ideal para quem gosta de fuçar e quer entender melhor como o sistema funciona internamente, editando arquivos de configuração, compilando módulos e escrevendo scripts. Nesta segunda edição, o livro recebeu uma grande quantidade de atualizações em todos os capítulos e muitas das dicas antigas foram substituídas por novas. O capítulo sobre shell script foi expandido, trazendo mais dicas sobre o desenvolvimento de scripts gráficos e também scripts e regras para o hotplug e udev, que permitem abrir programas e executar outros scripts quando determinados dispositivos são plugados na máquina. Foi incluído também um novo capítulo, que ensina a desenvolver soluções baseadas no Kurumin e outros live-CDs baseados no Knoppix, que permitem colocar em prática as dicas aprendidas no restante do livro. Por ser escrito em uma linguagem simples e didática e com um nível crescente de dificuldade, este livro é indicado tanto para usuários avançados, quanto iniciantes que desejam compreender mais profundamente o sistema. http://www.hardware.com.br,, o maior site técnico do país. Carlos E. Morimoto é o criador do http://www.hardware.com.br 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.

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 mais profundamente o sistema. http://www.hardware.com.br,, o maior site técnico do país. Carlos E. Morimoto é o criador do http://www.hardware.com.br Seu trabalho inclui mais de dois mil artigos, dicas e tutoriais publicados, projetos de desenvolvimento em Linux, cursos, palestras e a publicação de 17 livros técnicos sobre hardware, redes, servidores e Linux, entre eles os livros Hardware, o Guia Definitivo; Redes, Guia Prático; Servidores Linux, Guia Prático; Smartphones, Guia Prático; Linux, Entendendo o Sistema e Linux, Ferramentas Técnicas.

Sumário

Prefácio ............................ ................................ .... ...................... ................................ .......... ...................... ................................ .......... ..................... ................................ ........... ... 7 Capítulo 1: Entendendo a estrutura e strutura do sistema siste ma......... .................... ...................... ............. ...................... ................................ .......... ....... 7

Como Como funciona o suporte a hardware no Linux...................... ................................ .......... ..................... ................................ ........... ..... 8 Os componentes componentes do sistema sistema.................... ................................ ............ .................... ............................... ............. ........................ ............................... ....... 11 Kernel ......................... ................................ ....... ....................... ................................ ......... ..................... ................................ ........... ..................... ............................... ............ 11 Módulos Módulos ................. ........................... ............... ..... ........................ ................................ ........ ..................... ................................ ........... .................... ............................. ......... 16 Os processos processos de boot e os arquivos de inicialização........................... ............. ................... ..... ........................ .............. .............. .... 18 Ativando Ativando e desativando desativando serviços serviços...................... ................................ .......... ..................... ............................... ............ ....................... ......................... .. 22 X ........................... ................................ ..... ........................ ................................ ........ ..................... ............................... ............ ....................... ................................ ......... ........ 25 Gerenciador Gerenciador de login ..................... ................................ ........... .................... ............................... ............. ........................ ................................ ........ .......... 27 Xfree e Xorg ......................... ................................ ....... ...................... ................................ .......... .................... ................................ ............ .................... ....................... ... 27 A árvore árvore genealógica genealógica das distribuições distribuições..................... ................................ ........... .................... ................................ ............ ............... ............... 28 Capítulo 2: Configuração, Confi guração, ferramentas e dicas di cas ..................... ................................ ........... ..................... ................................ ........... ...... 31

Editando o /etc/fstab /etc/fstab .................. ............................ .............. .... ..................... ............................... ............ ....................... ................................ ......... ......... 31 Configuran Configurando do o lilo ............. ........................ ................... ........ .................... .............................. ............ .. ........................ ................................ ........ ............. ............. 38 Dual-Boot Dual-Boot com dois HDs .................. ............................... ............... ..................... ................................ ........... ....................... ................................ ......... . 42 Usando uma imagem imagem de fundo.................... ................................ ............ ..................... ............................... ............ ....................... ....................... 43 Configurando Configurando o grub ..................... ................................ ........... .................... ............................... ............. ........................ ................................ ........ .......... 44 Configurando Configurando o vídeo: vídeo: /etc/X11/xorg.co /etc/X11/xorg.conf nf..................... ............................... ............ .................... ................................ ............ .......... 48 KVM via software software com o Synergy Synergy..................... ............................... ............ .................... .............................. ............ .. ....................... ......................... 59 Usando o hdparm.................... .............................. ............ .. ....................... ................................ ......... .................... ................................ ............ ............... ............... 65 Recompila Recompilando ndo o Kernel Kernel .................... ................................ ............ ..................... ................................ ........... ....................... ................................ ......... ...... 69 Baixando os fontes fontes ................ ........................... ................ ..... ..................... ............................... ............ ....................... ................................ ......... ......... 70 Configurando Configurando.......... ..................... ..................... ............ ...................... ................................ .......... .................... ................................ ............ .................. .................. 71 Compilando Compilando ................ .......................... ................ ...... ....................... ................................ ......... .................... ................................ ............ .................... .................... 77 Instalando ............... ......................... ................. ....... ....................... ................................ ......... ..................... ................................ ........... ..................... ....................... 79 Recompiland Recompilando o o Kernel à moda Debian ........... ....................... ..................... ......... .................... ............................... ............. .......... 80 Aplicando patches ................ .......................... ................ ...... ...................... ................................ .......... ........................ ................................ ........ .......... .......... 81 Criando patches .................... .............................. ............ .. ....................... ................................ ......... .................... ................................ ............ ................. ................. 82 Acelerando Acelerando a compilação compilação com o distcc ..................... ................................ ........... .................... ............................... ............. ............... ............... 83 Criando pacotes a partir dos fontes com o checkinstall........................... ............. ................... ..... ....................... .............. ......... 85

Escrevendo Escrevendo scripts de backup.................... ................................ ............ .................... ............................... ............. ........................ ............................. ..... 87 Usando o autofs/autom autofs/automount ount ............. ........................ ................... ........ .................... .............................. ............ .. ....................... .............................. ....... 92 Acessando Acessando dispositivos dispositivos USB..................... ................................ ........... .................... .............................. ............ .. ....................... ................................ ......... 94 Configurando Configurando manualmente manualmente..................... ................................ ........... .................... .............................. ............ .. ....................... ........................... .... 94 Devs e hotplug.......... hotplug..................... ..................... ............ ...................... ................................ .......... ..................... ................................ ........... ................ ................ 98 Entendendo o udev ..................... ............................... ............ ...................... ................................ .......... ........................ ................................ ........ ...... 100 Renomeando Renomeando interfaces 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 Testdisk ........................ ................................ ........ ...................... ................................ .......... ........................ ................................ ........ ........ 106 Recuperando Recuperando partições partições danificadas danificadas ........................... ................................ ..... ..................... ............................... ............ .................. .................. 109 Gerenciamento de setores defeituosos como o ReiserFS............................. ............... ................. ... .................. .............. .... 114 Monitorando Monitorando a saúde do HD com o SMART SMART..................... ............................... ............ .................... .............................. ............ .. ...... 116 Copiando dados de HDs ou CDs defeituosos defeituosos ..................... ................................ ........... .................... ................................ ............ ..... 120 Aproveitando módulos de memória defeituosos ............................ ............. ................... .... .......................... ............ .............. .... 122 Eliminando Eliminando dados com segurança segurança...................... ................................ .......... .................... ............................... ............. ..................... ..................... 123 Administrando Administrando a memória memória swap.................... ................................ ............ ..................... ............................... ............ ....................... ....................... 127 Ativando o suporte a mair mair de 1GB de memória memória RAM........................... ............. ................... ..... ........................ .............. .......... 129 Clonando partições partições com o Partimage Partimage .................. ............................. .............. ... ..................... ............................... ............ ............... ............... 131 Instalando ............... ......................... ................. ....... ....................... ................................ ......... ..................... ................................ ........... .................... .................... 132 Funções básicas.................... .............................. ............ .. ....................... ................................ ......... .................... ................................ ............ ............ ............ 133 Fazendo uma imagem de todo o HD...................... ................................ .......... ..................... ............................... ............ ............. ............. 138 Gravando imagens imagens num compartilhamento da rede .......................... ............ .................... ...... ..................... .............. ....... 139 Segurança: Segurança: detectando detectando rootkits rootkits.................... ................................ ............ .................... ............................... ............. ........................ ........................ 143 Instalando o Kurumin 7 (e outras distros) num pendrive ou cartão........................... ............ .................... ..... ... 145 Salvando Salvando as configuraçõe configuraçõess ................... ................................ ............. .................... ............................... ............. ........................ ................................ ........ 153 Monitores Monitores de temperatura temperatura e coolers coolers ........... ....................... ..................... ......... .................... ............................... ............. ................ ................ 155 Gerenciament Gerenciamento o de energia energia ................... ............................... .............. ..................... ............................... ............ ....................... ............................... ........ 159 Capítulo 3: Instalando drivers adicionais adici onais .................... ............................... ............. ...................... ................................ .......... ............. ............. 164

Verificando Verificando links, arquivos arquivos e compiladores compiladores...................... ................................ .......... ..................... ................................ ........... ....... 164 Configurando Configurando softmodem softmodemss no Linux...................... ................................ .......... .................... .............................. ............ .. ................. ................. 167 A idéia básica.......... básica..................... ..................... ............ ...................... ................................ .......... .................... ................................ ............ ................ ................ 168 Driver Driver da Smartlink Smartlink.................... ................................ ............ ..................... ............................... ............ ....................... ................................ ......... ....... 169 Intel AC97 e ATI IXP .............. ......................... .................. ....... .................... .............................. ............ .. ........................ ................................ ........ ...... 174

Intel 537 e 536 ............................. ................................ ... ....................... ................................ ......... .................... ................................ ............ ............. ............. 176 Lucent e Agere Agere ........................... ................................ ..... ....................... ................................ ......... .................... ................................ ............ ............. ............. 178 PC-Tel PC-Tel PCI .............. ......................... .................. ....... ....................... ................................ ......... .................... ................................ ............ .................... ...................... 180 Modems Modems com chipset Conexant Conexant..................... ................................ ........... .................... .............................. ............ .. .................... .................... 181 Instalando Instalando placas wireless .............. .......................... .................. ...... .................... ............................... ............. ........................ ................................ ........ 182 Ndiswrapper Ndiswrapper.............. ........................ .................. ........ ........................ ................................ ........ ..................... ................................ ........... ................. ................. 184 ACX100 ACX100 e ACX111 ACX111 ............ ...................... .................... .......... ...................... ................................ .......... ..................... ................................ ........... ......... 187 MadWiFi MadWiFi.................. ............................ .............. .... ....................... ................................ ......... .................... ................................ ............ ..................... ....................... .. 189 ADMteck ADMteck ADM8211 ADM8211 ................ ........................... ................ ..... ...................... ................................ .......... ..................... ................................ ........... ...... 190 Realtek Realtek 8180 ..................... ............................... ............ ...................... ................................ .......... .................... ................................ ............ ................ ................ 191 Orinoco Orinoco USB ............... .......................... ................. ...... ........................ ................................ ........ ..................... ................................ ........... ................. ................. 192 Broadcom Broadcom................ .......................... ................ ...... ....................... ................................ ......... .................... ................................ ............ .................... ...................... 193 IPW2100 IPW2100 e IPW2200 IPW2200.................... ............................... ............. ...................... ................................ .......... ....................... ................................ ......... ..... 193 Ralink 2400 e 2500 .................... ............................... ............. ....................... ................................ ......... ....................... ................................ ......... ....... 197 Linux-wlan-ng Linux-wlan-ng.................. ............................ .............. .... ....................... ................................ ......... .................... ................................ ............ ............... ............... 198 Suporte a webcams webcams.................... .............................. ............ .. ....................... ................................ ......... ....................... ................................ ......... .......... 199 Driver Driver apca5xx..................... ............................... ............ ...................... ................................ .......... ..................... ................................ ........... .............. .............. 201 Logitech Logitech QuickCam QuickCam ............... ......................... ................. ....... ....................... ................................ ......... .................... ................................ ............ ....... 202 Sqcam ....................... ................................ ......... ....................... ................................ ......... .................... .............................. ............ .. .................... .......................... ...... 202 Modems Modems ADSL USB .............. ........................ .................. ........ ...................... ................................ .......... ..................... ................................ ........... ........... 203 Driver Driver da nVidia..................... ............................... ............ ...................... ................................ .......... ........................ ................................ ........ ................ ................ 208 Instalando manualmente manualmente..................... ................................ ........... .................... .............................. ............ .. ........................ .............................. ...... 208 Ativando Ativando os recursos recursos especiais especiais ...................... ................................ .......... .................... ............................... ............. ..................... ..................... 214 FSAA..................... ............................... ............ ....................... ................................ ......... .................... .............................. ............ .. ....................... ............................. ...... 214 Configurador Configurador gráfico..................... ................................ ........... .................... ............................... ............. ........................ ................................ ........ ..... 216 Twin View..................... ............................... ............ ....................... ................................ ......... .................... ................................ ............ .................... ...................... 219 Instalando à moda Debian.................... ................................ ............ .................... .............................. ............ .. ....................... ............................ ..... 221 Driver Driver para placas com chipset nForce........... nForce...................... ..................... .......... .................... .............................. ............ .. .............. .............. 223 Ativando Ativando o driver driver de rede ............. ........................ ................... ........ .................... ............................... ............. ........................ ............................. ..... 224 Ativando Ativando o driver driver de som................ som.......................... ................ ...... .................... .............................. ............ .. ....................... .............................. ....... 225 Driver Driver 3D da ATI ........................... ................................ ..... ....................... ................................ ......... .................... ................................ ............ ............... ............... 225 Instalando ............... ......................... ................. ....... ....................... ................................ ......... ..................... ................................ ........... .................... .................... 227 Configurando Configurando e solucionando solucionando problemas problemas........... ....................... ..................... ......... .................... .............................. ............ .. ...... 228 Tablets Tablets ............................. ................................ ... ...................... ................................ .......... .................... ................................ ............ .................... ............................. ......... 233

Configurando Configurando placas de TV .................. ............................... ............... ..................... ............................... ............ ....................... ............................... ........ 236 Gravando Gravando ................... .............................. ............. .. ....................... ................................ ......... .................... ................................ ............ .................... ...................... 241 Configurando mouses mouses touchpad com funções especiais ........................... ............. ................... ..... ................... ............... .... 242 Bootsplash Bootsplash .............................. ................................ .. ....................... ................................ ......... .................... ................................ ............ ..................... ....................... .. 246 Capítulo 4: Programando em shell script scri pt ...................... ................................ .......... .................... ................................ ............ ............. ............. 250

O básico ........................ ................................ ........ ...................... ................................ .......... ..................... ................................ ........... .................... ........................... ....... 251 Fazendo perguntas .............. ........................ .................. ........ ...................... ................................ .......... ........................ ................................ ........ ........... 255 Mais dicas sobre o kdialog kdialog..................... ................................ ........... .................... ............................... ............. ........................ ................................ ........ 268 Controlando Controlando aplicativos aplicativos via DCOP DCOP..................... ................................ ........... .................... ............................... ............. ..................... ..................... 275 Usando os servicemenus servicemenus do KDE....................... ................................ ......... .................... .............................. ............ .. ...................... ...................... 278 Detectando Detectando hardware .................. ............................ .............. .... .................... .............................. ............ .. ........................ ................................ ........ ...... 284 Alterando Alterando arquivos arquivos de configuração configuração...................... ................................ .......... .................... .............................. ............ .. ................. ................. 288 Corrigindo Corrigindo erros .................... .............................. ............ .. ....................... ................................ ......... .................... ................................ ............ ............... ............... 293 Pacotes Pacotes auto-instalá auto-instaláveis veis ....................... ................................ ......... .................... .............................. ............ .. ........................ ................................ ........ ... 296 Mais exemplos exemplos úteis.................... ................................ ............ .................... .............................. ............ .. ........................ ................................ ........ ......... 297 Criando interfaces no Kommande Kommanderr .......................... ................................ ...... .................... .............................. ............ .. ................... ................... 302 Criando scripts para o hotplug..................... ................................ ........... .................... ............................... ............. ........................ .......................... .. 328 Criando regras para o udev............ udev...................... .................... .......... ..................... ............................... ............ ....................... ............................... ........ 333 Capítulo 5: Remasterizando o Kurumin e outros live-CDs l ive-CDs..................... ................................ ........... .................... .................... 340

O básico ........................ ................................ ........ ...................... ................................ .......... ..................... ................................ ........... .................... ........................... ....... 341 Extraindo..................... ............................... ............ ....................... ................................ ......... .................... ................................ ............ .................... .......................... ...... 344 Fechando Fechando a nova imagem..................... ................................ ........... .................... .............................. ............ .. ....................... ................................ ......... . 348 Personalizando Personalizando o KDE e programas programas......... ..................... ...................... ............ .................... .............................. ............ .. ................... ................... 352 Scripts de inicialização 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 recuperação....................... ................................ ......... .................... .............................. ............ .. ...................... ...................... 360 Criando seus próprios pacotes .deb...................... ................................ .......... .................... ............................... ............. .................. .................. 364

Prefácio As distribuições Linux estão de um modo geral se tornando muito fáceis de usar, até mesmo mais fáceis de usar que o Windows em algumas áreas. Mas isso acaba deixando um gosto amargo na boca. Afinal, onde está o desafio? Em outros casos as coisas não funcionam tão bem assim e o gosto amargo fica por conta do modem, webcam, placa 3D ou placa wireless que não está funcionando ou outro problema qualquer, que não pode ser solucionado usando as ferramentas gráficas. Este livro é uma coleção de dicas que ensinam a configurar e corrigir problemas "na unha", manipulando diretamente os arquivos de configuração e módulos do sistema, sem depender de nenhum configurador, escrever shell scripts, instalar drivers manualmente e dominar ferramentas de diagnóstico e recuperação do sistema. É ideal para quem gosta de fuçar e quer entender melhor como o sistema funciona internamente, editando arquivos de configuração, compilando módulos e escrevendo scripts. Nesta segunda edição, o livro recebeu uma grande quantidade de atualizações em todos os capítulos e muitas das dicas antigas foram substituídas por novas. O capítulo sobre shell script foi expandido, trazendo mais 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ível crescente 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 de 70, com o objetivo de serem robustos, simples e utilizarem pouca memória, de forma a rodarem com um bom desempenho nos computadores limitados da época. Porém, por serem desenvolvidos tendo em mente os administradores de sistema, que sempre possuíam bons conhecimentos, nem sempre a facilidade de uso era uma prioridade.

O Linux pode ser considerado um sistema Unix, que conserva muitas das características dos sistemas originais. Para quem vem do Windows, a organização das pastas, a instalação de novos programas e o uso dos arquivos de configuração parece algo esotérico. Mas no fundo as coisas não são tão complicadas assim. Este capítulo é uma introdução à estrutura do Linux, destinada ao público técnico.

Como funciona o suporte a hardware no Linux As distribuições Linux sempre vêm de fábrica com suporte a muitos dispositivos, em geral quase tudo é detectado automaticamente. Os maiores problemas são, em geral, os softmodems que precisam ser instalados manualmente. O mesmo se aplica se você tiver uma placa de vídeo da nVidia ou da ATI ou outros dispositivos (como várias placas de rede wireless), cujos fabricantes disponibilizam drivers proprietários. Mas, afinal, como é a instalação destes drivers no Linux? Cadê o assistente para a instalação de novo hardware? Onde que eu aponto a pasta onde estão os arquivos? Calma, vamos chegar lá :-). O suporte a dispositivos no Linux é feito através de "módulos" incluídos no Kernel, arquivos que ficam dentro da pasta "/lib/modules/versão_do_kernel_usada/". Estes módulos são a coisa mais parecida com um "driver" dentro da concepção que temos no Windows. Para ativar suporte a um certo dispositivo, você precisa apenas carregar o módulo referente a ele. Veja que os módulos ficam organizados em pastas: a pasta "kernel/drivers/net/" contém drivers para placas de rede, a pasta "kernel/drivers/usb/" agrupa os que dão suporte dispositivos USB e assim por diante. Até o Kernel 2.4, os módulos de Kernel utilizavam a extensão ".o", que é uma extensão genérica para objetos em C. A partir do Kernel 2.6, passou a ser usada a extensão ".ko" (kernel object), que é mais específica. Quase sempre, os módulos possuem nomes que dão uma idéia do dispositivo a que oferecem suporte. O "8139too.ko" dá suporte às placas de rede com o chipset Realtek 8139, o "sis900.ko" dá suporte às placas SiS 900, enquanto o "e100.ko" ativa as placas Intel E100.

Os módulos podem ser carregados e descarregados a qualquer momento usando os comandos "modprobe" e "modprobe -r"; não apenas na inicialização do sistema. Existe também o comando "insmod", mais antigo, que também permite carregar módulos. A diferença entre o "insmod" e o "modprobe" é que o modprobe carrega apenas módulos já instalados, junto com todas as dependências, ou seja, outros módulos de que o primeiro precise para funcionar. Se você tentar carregar o módulo "usb-storage" (que dá suporte a pendrives e HDs USB), vai perceber que serão carregados também os módulos "usbcore" e "ehci-hcd". O "insmod" é muito menos inteligente, carrega apenas o módulo solicitado, retornando um erro caso ele precise de outros. A única vantagem é que ele permite carregar módulos a partir de qualquer pasta, permitindo que você teste um módulo que acabou de compilar, ou que gravou num pendrive, por exemplo. Os módulos são gerados durante a compilação do Kernel. Você não precisa se preocupar com isso se não quiser, pois as distribuições quase sempre incluem versões bem completas do Kernel por padrão. Mas, de qualquer forma, existe sempre a possibilidade de recompilar o Kernel, mexendo nas opções e ativando ou desativando os módulos que quiser.

Você pode incluir módulos para todo tipo de dispositivos, de marcas e modelos diferentes. Eles não atrapalham em nada, pois apenas alguns deles (os que você estiver usando no momento) ficarão carregados na memória. Estes módulos geralmente são pequenos; um conjunto completo com os módulos para todo tipo de dispositivos (que totalizam mais de mil arquivos no Kernel 2.6), normalmente ocupa de 40 a 50 MB no HD. Podemos dividir os drivers de dispositivo para o Linux em dois grupos. O primeiro é o dos drivers de código aberto, que podem tanto ser desenvolvidos pelos próprios fabricantes quanto por voluntários em cantos remotos do mundo. Desenvolver drivers usando engenharia reversa sem ajuda dos fabricantes parece ser um passatempo bastante popular :-). Estes drivers open-source são incluídos diretamente no Kernel, o que faz com que sejam incluídos diretamente nas distribuições e você não precise se preocupar muito com eles. Sua placa funciona e todo mundo fica feliz. A segunda categoria é a dos drivers proprietários, de código fechado, que são desenvolvidos pelos próprios fabricantes. Em alguns casos os drivers são de livre distribuição e também podem ser incluídos diretamente nas distribuições. Em outros, você mesmo precisará baixar e instalar o driver. É aqui que entram os drivers para softmodems, para muitas placas wireless e também os drivers para placas 3D da nVidia e da ATI. A psicologia para lidar com eles é a seguinte: instalar um destes drivers envolve duas tarefas: baixar e instalar o módulo propriamente dito e criar um "dispositivo" (device), um atalho que aponta para o endereço de hardware usado por ele. Ao instalar um modem Lucent, por exemplo, é criado um dispositivo "/dev/ttyLT0" por ondeo modem é acessado. Para facilitar esta tarefa, geralmente os drivers vêm com algum tipo de instalador, geralmente um script simples de modo texto que cuida disso para você. Os módulos são parte integrante do Kernel, por isso os módulos para uma determinada distribuição não funcionam em outra, a menos que por uma grande coincidência as duas

utilizem exatamente a mesma versão do Kernel. Isso é bastante improvável já que o Kernel do Linux é atualizado quase que diariamente. Se você usar uma distribuição popular, Mandriva, Fedora, SuSE, etc., é possível que você encontre um driver pré-compilado para download (que pode ser encontrado com a ajuda do Google ;). Neste caso, você só vai precisar instalar um pacote RPM ou executar um arquivo de instalação. Em outras situações, você encontrará apenas um arquivo genérico ainda não compilado, contendo um instalador que se encarrega de compilar um módulo sob medida para o Kernel em uso. Como ele não tem como adivinhar qual distribuição ou Kernel você está utilizando, é necessário ter instalados dois pacotes que acompanham qualquer distribuição: kernel-source e kernel-headers. No Mandriva, por exemplo, você pode instalá-los usando os comandos: # urpmi kernel-source # urpmi kernel-headers

Naturalmente, para que ele possa compilar qualquer coisa, você precisará também de um compilador, o gcc, que também acompanha as distribuições. Se você tiver estas três coisas, vai conseguir instalar qualquer driver sem maiores problemas, basta seguir as instruções na página de download ou no arquivo INSTALL ou README dentro do pacote. Uma grande parte deste livro é justamente dedicada a falar sobre a instalação destes drivers difíceis, abordando também os problemas de instalação mais comuns. Um lembrete importante sobre a nomenclatura adotada neste livro e em outros tipos de documentação é que a cerquilha (#) no início do comando indica que ele deve ser executado como root, o que é necessário ao instalar programas e editar arquivos de configuração. Os comandos com um dólar ($) por sua vez devem ser executados usando uma conta de usuário. Lembre-se de que, em qualquer distribuição, você pode usar o comando "su" (seguido da senha) para virar root. No caso do Ubuntu, além do Kurumin e outras distribuições derivadas do Knoppix, você pode usar também o "sudo".

Os componentes do sistema Todas as coisas grandes começam pequenas e com o Linux não foi diferente. Para entender melhor os componentes que formam o sistema, nada melhor do que falar um pouco sobre a história do Linux, sobre como e por que eles foram introduzidos, e entender o processo de inicialização do sistema.

Kernel Tudo começou em 1991, com a primeira versão do Kernel disponibilizada por Linus Torvalds. O "Freax" (renomeado para "Linux" pelo responsável pelo FTP onde o arquivo foi disponibilizado, uma alma sábia e caridosa :) ainda estava na versão 0.02 e era um sistema monolítico, um grande bloco de código que, além do núcleo do sistema, continha drivers de dispositivos e tudo mais.

Para compilar o código fonte do Kernel, era necessário usar o Minix, outro sistema baseado em Unix que na época era bastante popular entre os estudantes. Você começava compilando o Kernel e em seguida algumas ferramentas básicas como o gerenciador de boot, o bash (o interpretador de comandos) e o gcc (o compilador). A partir de um certo ponto, você podia dar boot no próprio Linux e compilar os demais programas a partir dele mesmo. Os primeiros aplicativos a rodarem sobre o Linux foram justamente ferramentas de desenvolvimento, como o Emacs, e emuladores de terminal, usados para acessar outras máquinas Unix remotamente. Nesta época começaram a surgir as primeiras "distribuições" Linux, na forma de projetos amadores, onde alguém gravava o sistema compilado em um conjunto de disquetes e tirava cópias para os amigos. Este procedimento de usar outro sistema operacional instalado para compilar uma instalação do Linux é de certa forma usada até hoje para gerar versões do sistema destinadas a serem usadas em dispositivos embarcados, como palms e celulares. Neles você usa uma cópia do Linux instalada num PC para "montar" o sistema que vai rodar no dispositivo, compilando primeiro o Kernel e depois os demais aplicativos necessários, deixando para finalmente transferir para o dispositivo no final do processo. Isto é chamado de "cross-compiling". Atualmente o Kernel, junto com vários aplicativos, pode ser compilado para rodar em várias plataformas diferentes. O código fonte do Kernel, disponível no http://kernel.org (e diversos mirrors), inclui o código necessário para gerar um Kernel para qualquer arquitetura suportada. Na verdade, quase 95% do código Kernel é independente da arquitetura, por isso portar o Kernel para uma nova plataforma é um trabalho relativamente simples (pelo menos se levarmos em conta a complexidade do código envolvido). As partes que mudam de uma arquitetura a outra são organizadas na pasta "/usr/src/linux/arch/". Ainda assim, e um trabalho complexo e tedioso, muitas coisas precisam ser ajustadas e é necessário encontrar programas específicos, que se ajustem à configuração de hardware da plataforma alvo. Você pode rodar Linux num celular com 2 MB de memória, mas com certeza não vai conseguir rodar o Firefox nele. Vai precisar encontrar um navegador mais leve, que rode confortavelmente com pouca memória e a tela minúscula do aparelho. Aqui temos um screenshot do Familiar, uma distribuição Linux para o Ipaq, que pode ser instalado em substituição ao Pocket PC Windows, que vem originalmente instalado. Veja que ele é bem diferente das distribuições para micros PC:

Você pode entender melhor sobre como isto funciona instalando o "Linux from Scratch", uma distribuição Linux que pode ser toda compilada manualmente a partir dos pacotes com código fonte, disponível no: http://www.linuxfromscratch.org/. Voltando à história, no início o projeto ainda não tinha muita utilidade prática. O conjunto de aplicativos que rodava no sistema era pequeno. Era muito mais fácil usar o Minix, ou, se você tivesse condições financeiras, uma versão comercial do Unix, como o SunOS, que mais tarde deu origem ao Solaris e ao OpenSolaris. O que fez com que o Linux crescesse até o ponto em que está hoje foi principalmente o fato de não apenas o código fonte do sistema ser aberto e estar disponível, mas também a forma aberta como o sistema foi desenvolvido desde o início. É normal encontrar muitos problemas e deficiências ao tentar usar um software em estágio primário de desenvolvimento. Se você for um programador, vai acabar dando uma olhada no código e fazendo algumas modificações. Se você estiver desenvolvendo algum projeto parecido, é provável que você resolva aproveitar algumas idéias e pedaços de código para implementar alguma nova função e assim por diante. No caso do Linux, estas modificações eram bem-vindas e acabavam sendo incluídas no sistema muito rapidamente. Isto criou uma comunidade bastante ativa, gente usando o sistema nos mais diversos ambientes e ajudando a torná-lo adequado para todo tipo de tarefa. Inicialmente era tudo um grande hobby. Mas logo o sistema começou a ficar maduro o suficiente para concorrer com as várias versões do Unix e, mais tarde, também com o Windows, inicialmente nos servidores, depois nos dispositivos embarcados e finalmente no desktop. Com isso, mesmo grandes empresas como a IBM e a Novell começaram a contribuir

com o desenvolvimento do Kernel, a fim de tornar o sistema mais robusto e adicionar recursos necessários para uso em diversas tarefas. Este modelo é diferente do adotado pela Microsoft, por exemplo, que vende caixinhas do Windows e Office. Estas empresas ganham mais vendendo soluções, onde é fornecido um pacote, com o sistema operacional, aplicativos, suporte e garantias. Neste caso, faz sentido contribuir para a construção de uma base comum (o Kernel) pois, no final, sai muito mais barato do que investir em um sistema próprio. A partir desta base comum, as empresas podem diferenciar-se das demais investindo nos outros componentes do pacote. Usar Linux acaba virando então uma questão de competitividade: outra empresa que resolvesse desenvolver um sistema próprio sairia em desvantagem, pois precisaria investir muito tempo e dinheiro para chegar no mesmo nível dos outros.

Originalmente, o termo "Linux" era usado especificamente com relação ao Kernel desenvolvido por Linus Torvalds. Mas, hoje em dia, é mais comum nos referirmos à plataforma como um todo, incluindo o Kernel, ferramentas e aplicativos. Muitos dos aplicativos que usamos hoje no Linux vieram de outras versões do Unix e este fluxo continua até hoje, nos dois sentidos. O Kernel é a base do sistema. Ele controla o acesso à memória, ao HD e demais componentes do micro, dividindo os recursos disponíveis entre os programas. Todos osdemais programas, desde os aplicativos de linha de comando, até os aplicativos gráficos rodam sobre o Kernel. Imagine, por exemplo, que você está desenvolvendo um aplicativo de edição de áudio. Você precisa incluir no seu programa várias funções de edição, filtros e assim por diante. Mas, você não precisa se preocupar diretamente em oferecer suporte aos diferentes modelos de placas de som que temos no mercado, pois o Kernel cuida disso. Ao tocar um arquivo de áudio qualquer, o seu programa precisa apenas mandar o fluxo de áudio para o device "/dev/dsp". O Kernel recebe o fluxo de áudio e se encarrega de enviá-lo à placa de som. Quando é preciso ajustar o volume, seu programa acessa o dispositivo "/dev/mixer", e assim por diante. Naturalmente, uma Sound Blaster Live e uma placa AC'97 onboard, por exemplo, oferecem conjuntos diferentes de recursos e se comunicam com o sistema de uma forma particular, ou seja, falam línguas diferentes. Por isso o Kernel inclui vários intérpretes, os drivers de dispositivo. Driver em inglês significa "motorista" ou, "controlador". Cada chipset de placa de som, vídeo, rede ou modem possui um driver próprio. Podemos dizer que os módulos são as partes do Kernel mais intimamente ligadas ao hardware. Os módulos são as partes do Kernel que mudam de máquina para máquina. Depois vem o bloco principal, "genérico" do Kernel.

Sobre ele roda o shell, o interpretador de comandos responsável por executar os aplicativos de modo texto e servidores, como o Samba e o Apache. Estes aplicativos são independentes do modo gráfico, você não precisa manter o X aberto para instalar e configurar um servidor Samba, por exemplo, embora as ferramentas gráficas possam ajudar bastante na etapa de configuração. Quando você executa o comando "cat arquivo.txt", porexemplo, o bash entende que deve usar o programa "cat" para ler o "arquivo.txt". O Kernel oferece uma série de serviços e comandos que podem ser usados pelos aplicativos. Neste caso, o bash dá a ordem para que o executável "cat", junto com o arquivo sejam carregados na memória. Para que isso aconteça, o Kernel precisa ler os dois arquivos no HD e carregá-los na memória RAM. No processo são usadas chamadas de vários módulos diferentes, como o responsável pelo acesso à porta IDE onde o HD está conectado, o responsável pelo sistema de arquivos em que o HD está formatado e o módulo responsável pelo suporte ao controlador de memória da placa-mãe. No caso de programas muito grandes, a memória RAM pode ficar lotada, obrigando o Kernel a usar o subsistema de memória virtual para gravar as informações excedentes na partição swap. Só depois de tudo isso que o "cat" pode ser executado e mostrar o conteúdo do arquivo na tela (usando mais um comando do Kernel, que aciona a placa de vídeo). Graças ao trabalho do Kernel, você não precisa se preocupar com nada disso, apenas com os programas que precisa executar. Depois vem o X, o servidor gráfico, responsável por acessar a placa de vídeo e mostrar imagens no monitor. Ele serve como base para os aplicativos gráficos, que podem ser divididos em duas categorias. Primeiro temos os gerenciadores, como o KDE e o Gnome, que são responsáveis por gerenciar as janelas, mostrar a barra de tarefas e assim por diante. Eles servem como uma base para que você possa abrir e controlar os demais aplicativos gráficos.

Mesmo dentro do modo gráfico, você continua tendo acesso aos recursos do modo texto. Programas como o Xterm e o Konsole são usados para rodar uma instância do bash dentro do

modo gráfico, permitindo executar todos os aplicativos de 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 ou desativadas 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 ser desativado ou compilado como módulo, uma modificação que parece besteira num PC, mas que é útil para quem desenvolve versões para roteadores e outros dispositivos que realmente não possuem teclado.

As distribuições passaram então a vir com versões do Kernel cada vez mais completas, incluindo em muitos casos um grande número de patches para adicionar suporte a ainda mais dispositivos, naturalmente quase tudo compilado como módulos. Nas distribuições atuais, o hardware da máquina é detectado durante a instalação e o sistema é configurado para carregar os módulos necessários durante o boot. Isto pode ser feito de duas formas: 1- Os módulos para ativar a placa de som, rede, modem e qualquer outro dispositivo "não essencial" são especificados no arquivo "/etc/modules". Programas de detecção, como o hotplug e o udev ficam de olho nas mensagens do Kernel e carregam módulos adicionais

conforme novos dispositivos (uma câmera digital USB, em modo de transferência, por exemplo) são detectados. Sua placa de som seria ativada durante o boot através de um módulo especificado no "/etc/modules", assim como o suporte genérico a dispositivos USB. Mas, o seu pendrive, que você pluga e despluga toda hora é ativado e desativado dinamicamente através da detecção feita pelo hotplug ou udev. A detecção de novos periféricos (principalmente ao usar o Kernel 2.6) é muito simplificada graças ao próprio Kernel, que gera mensagens sempre que um novo dispositivo é encontrado. Você pode acompanhar este log rodando o comando "dmesg". Por exemplo, ao plugar um pendrive USB, você verá algo como: usb 2-2: new high speed USB device using address scsi1 : SCSI emulation for USB Mass Storage devices Vendor: LG CNS Model: Rev: 1.00 Type: Direct-Access ANSI SCSI revision: 02 SCSI device sda: 249856 512-byte hdwr sectors (128 MB) sda: Write Protect is off  sda: Mode Sense: 03 00 00 00 sda: assuming drive cache: write through sda: sda1

Attached scsi removable disk sda at scsi1, channel 0, id 0, lun 0 Attached scsi generic sg0 at scsi1, channel 0, id 0, lun 0, type 0 USB Mass Storage device found at 5 Veja que aqui estão quase todas as informações referentes a ele. O fabricante (LG), o dispositivo pelo qual ele será acessado pelo sistema (sda), a capacidade (128 MB) e até as partições existentes (neste caso uma única partição, nomeada "sda1"). Um segundo arquivo, o "/etc/modules.conf " (ou "/etc/modprobe.conf", dependendo da distribuição usada), especifica opções e parâmetros para os módulos, quando necessário. Este arquivo normalmente é gerado automaticamente pelas ferramentas de detecção de hardware ou ao rodar o comando "update-modules ", mas pode também ser editado manualmente, caso necessário.

Outra peça importante é o arquivo "/lib/modules/2.6.x/modules.dep", que guarda uma tabela com as dependências dos módulos, ou seja, de quais outros módulos cada um precisa para ser carregado corretamente. Este último arquivo é gerado automaticamente ao rodar o comando "depmod -a". Em geral, este comando é executado de forma automática durante o boot, sempre que necessário. O "2.6.x" neste caso corresponde à versão do Kernel usado na sua máquina. 2- Se o suporte a algo essencial nas etapas iniciais do boot não está incluído no Kernel, é criado um initrd, uma imagem com os módulos necessários, que, diferentemente dos módulos

especificados no "/etc/modules", são carregados logo no início do boot. O initrd é guardado na pasta /boot, junto com o executável principal do Kernel: o arquivo "vmlinuz". Imagine, por exemplo, que você está usando uma distribuição onde o suporte ao sistema de arquivos ReiserFS foi compilado como módulo, mas quer instalar o sistema justamente numa partição ReiserFS. Isso gera um problema do tipo o ovo e a galinha, já que o sistema precisa do módulo para acessar a partição, mas precisa de acesso à partição para poder ler o módulo. Para evitar este tipo de problema, o próprio instalador da distribuição, ao perceber que você formatou a partição raiz em ReiserFS, vai se encarregar de gerar o arquivo initrd que, embora não seja obrigatório (é possível compilar tudo diretamente no Kernel), é bastante usado.

Os processos de boot e os arquivos de inicialização Quando você liga o micro, o primeiro software que é carregado é o BIOS 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 de POST (Power-on self test) Seria bom se a função do BIOS se limitasse a isso, mas na verdade ele continua residente, mesmo depois que o sistema operacional é carregado. Na época do MS-DOS era bem conhecida a divisão entre a memória real (os primeiros 640 KB da memória RAM) e a memória extendida (do primeiro MB em diante, englobando quase toda a memória instalada). O MS-DOS rodava em modo real, onde o processador trabalha simulando um 8088 (o processador usado no XT) que era capaz de acessar apenas 640 KB de memória. Mesmo os processadores modernos conservam este modo de operação, mas os sistemas operacionais atuais rodam inteiramente em modo protegido, onde são usados todos os recursos da máquina. O espaço entre os primeiros 640 KB, onde termina a memória real, e os 1024 KB, onde começa a memória extendida, é justamente reservado para o BIOS da placa-mãe. Ele é originalmente gravado de forma compactada num chip de memória flash instalado na placa-mãe. Durante o processo de boot ele é descompactado e copiado para este espaço reservado (chamado de shadow RAM), onde fica disponível.

O BIOS oferece funções prontas para acessar o HD, acionar recursos de gerenciamento de energia e muitas outras coisas. Mas, os sistemas operacionais quase não utilizam estas funções, pois existem muitas diferenças na forma como BIOS de diferentes placas-mãe trabalham e, em muitos casos, as funções simplesmente não funcionam ou produzem erros inesperados. Os fabricantes de placas-mãe disponibilizam upgrades de BIOS freqüentemente para corrigir estes problemas, mas a maior parte dos usuários nem chega a procurá-los, fazendo com que exista um enorme contingente de placas bugadas por aí, com problemas no ACPI, DMA e outros recursos básicos. Existe até mesmo um projeto para substituir o BIOS da placa-mãe por uma versão compacta do Kernel do Linux, que executa as mesmas funções, mas de uma forma mais confiável e flexível. Você pode obter mais informações sobre ele no: http://www.linuxbios.org/. Outra tecnologia (já em uso) que substitui o BIOS é o EFI (Extensible Firmware Interface), usada em placas-mãe para o Intel Itanium e também nos Macs com processadores Intel. O EFI utiliza uma arquitetura modular, bem mais limpa e eficiente, que permite o uso de módulos personalizados para os dispositivos de cada-placa mãe, mantendo (opcionalmente) compatibilidade com o sistema antigo. No caso dos Macs, esta camada de compatibilidade é desativada (de forma a dificultar a vida de quem pretende instalar Linux ou windows em dual boot com o MacOS) mas, no caso de placas avulsas, o EFI viria com o modo de compatibilidade ativado, permitindo rodar qualquer sistema. De qualquer forma, depois de fazer seu trabalho, o BIOS carrega o sistema operacional, lendo o primeiro setor do disco rígido o "Master Boot Record" (MBR), também conhecido como trilha zero ou trilha MBR. No MBR vai o gerenciador de boot. Os dois mais usados no Linux são o lilo e o grub. Na verdade, no MBR mesmo vai apenas um bootstrap, um pequeno software que instrui o BIOS a carregar o executável do lilo ou grub em um ponto específico do HD. O MBR propriamente dito ocupa um único setor do HD (apenas 512 bytes), de modo que não é possível armazenar muita coisa diretamente nele. O gerenciador de boot utiliza os primeiros 446 bytes do MBR. Os 66 bytes restantes são usados para armazenar a tabela de partições, que guarda informações sobre onde cada partição começa e termina. Alguns vírus, além de acidentes em geral, podem danificar os dados armazenados na tabela de partição, fazendo com que pareça que o HD foi formatado. Mas, na maioria dos casos, os dados continuam lá. Mais adiante, veremos como fazer um backup da tabela de partições e restaurá-la quando necessário. Voltando ao tema inicial, o gerenciador de boot tem a função de carregar o Kernel e, a partir dele, todo o restante do sistema. O lilo e o grub podem ser configurados ainda para carregar o

Windows ou outros sistemas instalados em dual boot. Muitas distribuições configuram isso automaticamente durante a instalação. Inicialmente, o Kernel é um arquivo compactado e somente-leitura, o arquivo "/boot/vmlinuz". Ele é descompactado em uma área reservada da memória RAM e roda a partir daí, aproveitando o fato de que a 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 a necessidade de usar um initrd quando a partição raiz do sistema está formatada num sistema de arquivos que não está compilado diretamente no Kernel, deve ter notado uma contradição aqui. Afinal é o que está sendo feito até agora. Nem o BIOS, nem o lilo possuem suporte a ReiserFS e o Kernel precisa ser carregado antes que ele tenha a chance de carregar o initrd. E, além do mais, para carregar o initrd, o próprio Kernel precisaria ler o arquivo dentro da partição. Isto tudo funciona porque tanto o BIOS quanto o lilo não procuram entender o sistema de arquivos em que o HD está formatado. Pode ser EXT2, ReiserFS, XFS, ou o que seja: para eles não faz diferença. Eles simplesmente lêem os uns e zeros gravados numa área específica do HD e assim carregam o Kernel e o initrd. Eles não fazem alterações nos dados gravados, por isso este "acesso direto" não traz possibilidade de danos às estruturas do sistema de arquivos. Depois de carregado, a primeira coisa que o Kernel faz é montar a partição raiz, onde o sistema está instalado, inicialmente como somente-leitura. Neste estágio ele carrega o init, o software que inicia o boot normal do sistema, lendo os scripts de inicialização e carregando os módulos e softwares especificados neles. O arquivo de configuração do init é o " /etc/inittab". Ele é geralmente o primeiro arquivo de configuração lido durante o boot. A principal tarefa dele é carregar os demais scripts de inicialização, usados para carregar os demais componentes do sistema e fazer todas as operações de checagem, necessárias durante o boot. No /etc/inittab do Debian por exemplo, você verá a linha: # Boot-time system configuration/initialization script. si::sysinit:/etc/init.d/rcS

Esta linha executa o script "/etc/init.d/rcS". Se você examiná-lo também, vai encontrar o seguinte: for i in /etc/rcS.d/S??* do ... $i start .... done

Os "..." indicam partes dos script que removi para deixar apenas as partes que interessam aqui. Estas linhas são um shell script, que vai executar os scripts dentro da pasta " /etc/rcS.d/". Esta pasta contém scripts que devem ser executados sempre, a cada boot, e são responsáveis por etapas fundamentais do boot. Alguns exemplos de scripts e programas executados nesta etapa são: keymap.sh: Carrega o layout do teclado que será usado no modo texto. Você não gostaria de

encontrar seu teclado com as teclas trocadas para o Russo quando precisar arrumar qualquer coisa no modo texto, não é? ;-), O KDE possui um configurador próprio, o kxkb, que é configurado dentro do Painel de Controle. O layout usado pelo kxkb subscreve o configurado pelo keymap.sh dentro do KDE. checkroot.sh: Este script roda o fsck, reiserfsck ou outro programa adequado para verificar a

estrutura da partição raiz (a partição onde o sistema está instalado), corrigindo erros causados por desligamentos incorretos do sistema. Este processo é análogo ao scandisk do Windows. Só depois da verificação é que a partição raiz passa a ser acessada em modo leitura e escrita. modutils: Este é o script que lê os arquivos " /etc/modules" e "/etc/modules.conf ", ativando a

placa de som, rede e todos os outros dispositivos de hardware "não essenciais", para os quais o suporte não foi habilitado diretamente no Kernel. Atualmente, a maioria das distribuições inclui alguma ferramenta de detecção de hardware, que é executada a cada boot, fazendo com que o arquivo "/etc/modules" sirva apenas para especificar manualmente módulos que ativem periféricos que não estejam sendo detectados automaticamente. checkfs.sh: Este script é parecido com o checkroot.sh. Ele se destina a checar as demais

partições do HD. mountall.sh: É aqui que é lido o arquivo "/etc/fstab" e as demais partições, unidades de rede,

e tudo mais que estiver especificado nele é ativado. Se você estiver usando uma partição home separada ou um compartilhamento de rede via NFS para guardar arquivos, por exemplo, é a partir deste ponto que eles ficarão disponíveis. networking: Ativa a rede, carregando a configuração de IP, DNS, gateway, etc., ou obtendo a

configuração via DHCP. A configuração da rede é geralmente armazenada dentro da pasta "/etc/sysconfig/network-scripts/" ou no arquivo "/etc/network/interfaces", variando de acordo com a distribuição usada. De acordo com a distribuição usada, são carregados neste ponto outros serviços, para ativar suporte a placas PCMCIA, placas ISA, ou outros tipos de hardware, ativar o suporte a compartilhamentos de rede e, assim por diante. É possível executar praticamente qualquer tipo de comando ou programa nesta etapa, justamente por isso os passos executados durante o boot mudam de distribuição para distribuição, de acordo com o que os desenvolvedores consideram mais adequado. A idéia aqui é apenas dar uma base, mostrando alguns passos essenciais que são sempre executados. Depois desta rodada inicial, são executados os scripts correspondentes ao runlevel padrão do sistema, que é configurado no "/etc/inittab", na linha:

# The default runlevel. id:5:initdefault: O número (5 no exemplo) indica o runlevel que será usado, que pode ser um número de 1 a 5. Cada runlevel corresponde a uma pasta, com um conjunto diferente de scripts de inicialização. É uma forma de ter vários "profiles", para uso do sistema em diferentes situações. A configuração mais comum é a seguinte: Runlevel 1: Single user. É um modo de recuperação onde nem o modo gráfico, nem o suporte

à rede, nem qualquer outro serviço "não essencial" é carregado, de forma a minimizar a possibilidade de problemas. A idéia é que o sistema "dê boot" para que você possa corrigir o que está errado. Atualmente, uma forma mais prática para corrigir problemas é dar boot com uma distribuição em live-CD (como o Kurumin), onde você tem acesso à internet e vários programas e, a partir dele, montar a partição onde o sistema está instalado e corrigir o problema. Runlevel 3: Boot em modo texto. Neste modo todos os serviços são carregados, com exceção

do gerenciador de boot (KDM ou GDM), que é responsável por carregar o modo gráfico. Este modo é muito usado em servidores. Runlevel 5: É o modo padrão na maioria das distribuições, onde você tem o sistema

"completo", com modo gráfico e todos os demais serviços. Uma exceção importante é o Slackware, onde o modo gráfico é carregado no runlevel 4. Usando o runlevel 5, são carregados os scripts dentro da pasta "/etc/rc5.d/", enquanto que, usando o runlevel 3, são carregados os scripts dentro da pasta "/etc/rc3.d/". Nada impede que você modifique a organização dos arquivos manualmente, de forma a fazer o X carregar também no runlevel 3, ou qualquer outra coisa que quiser. São apenas pastas com scripts e links simbólicos dentro, nenhuma caixa preta.

Ativando e desativando serviços Nas distribuições que seguem o padrão do Debian, os executáveis que iniciam os serviços de sistema ficam todos dentro da pasta "/etc/init.d/". Para parar, iniciar ou reiniciar o serviço ssh, por exemplo, use os comandos: # /etc/init.d/ssh start # /etc/init.d/ssh stop # /etc/init.d/ssh restart

No Kurumin, Mandriva e algumas outras distribuições, existe o comando service, que facilita um pouco as coisas, permitindo que, ao invés de ter de digitar o caminho completo, você possa controlar os serviços através dos comandos:

# service ssh start # service ssh stop # service ssh restart

Os scripts que estão na pasta "/etc/init.d/" servem para "chamar" os executáveis dos servidores. Eles apenas fazem as verificações necessárias e em seguida inicializam ou encerram os executáveis propriamente ditos, que em geral estão na pasta "/usr/bin/" ou "/usr/sbin/". A pasta "/etc/init.d/" contém scripts para quase todos os serviços que estão instalados no sistema. Quando você instala o Samba pelo apt-get, por exemplo, é criado o script "/etc/init.d/samba ", mesmo que ele não exista anteriormente.

O que determina se o Samba será executado ou não durante o boot não é o script na pasta "/etc/init.d/", mas sim um link simbólico criado dentro de uma das pastas de inicialização. Por padrão, são executados primeiro os links que estão dentro da pasta "/etc/rcS.d/" e, em seguida, o que estiver dentro da pasta "/etc/rc5.d/" (caso o sistema esteja configurado para inicializar em runlevel 5, padrão na maioria das distribuições) ou na pasta " /etc/rc3.d/" (runlevel 3).

Os números antes dos nomes dos serviços dentro da pasta "/etc/rc5.d/" determinam a ordem em que eles serão executados. Você vai querer que o firewall seja sempre ativado antes do Samba por exemplo. O "S" (start) indica que o serviço será inicializado no boot. A partir daí, o sistema vai inicializando um por vez, começando com os serviços com número mais baixo. Caso dois estejam com o mesmo número, eles são executados em ordem alfabética. Para que um determinado serviço pare de ser inicializado automaticamente no boot, basta deletar a entrada dentro da pasta, como em: # rm -f /etc/rc5.d/S20samba

Para que o serviço volte a ser inicializado você deve criar novamente o link, apontando para o script na pasta /etc/init.d, como em: # cd /etc/rc5.d/ # ln -s ../init.d/samba S20samba

ou: # ln -s ../init.d/ssh S21ssh

Esta é a forma "correta" de criar os links: acessando primeiro a pasta onde eles são criados e criando os links com as localizações relativas. Se estamos na pasta "/etc/rc5.d" e criamos o link apontando para "../init.d/samba", significa que o sistema vai subir um nível de diretório (vai para o /etc) e em seguida acessa a pasta "init.d/". Nada impede que você crie o link diretamente, como em: # ln -s /etc/init.d/ssh /etc/rc5.d/S21ssh

Ele vai funcionar da mesma forma, mas ferramentas de configuração automática, como o "update-rc.d" (do Debian), vão reclamar do "erro" ao atualizar ou remover o link. Este é, na verdade, um daqueles casos em que precisamos contornar manualmente a falta de recursos da ferramenta.

Existe um utilitário de modo texto, do Debian, que facilita esta tarefa, o rcconf , que pode ser instalado via apt-get. Chamando-o com a opção "--now", os serviços marcados são inicializados imediatamente, caso contrário ele apenas cria os links, de forma que eles fiquem ativos a partir do próximo boot. No Fedora, Mandriva e outras distribuições derivadas do Red Hat, você pode ativar ou desativar a inicialização dos serviços no boot usando o comando "chkconfig", como em: # chkconfig ssh on

(ativa) # chkconfig ssh off 

(desativa)

Você pode também usar o utilitário " ntsysv" ou outro configurador disponível. O Mandriva, por exemplo, inclui um painel de administração de serviços dentro do Mandriva Control Center. Muitas distribuições incluem o "services-admin", outro utilitário gráfico que faz parte do pacote "gnome-system-tools".

X Diferentemente do que temos no Windows, onde a interface gráfica é um componente essencial do sistema, no Linux o modo gráfico é uma camada independente. Temos um "servidor gráfico", o famoso X que provê a infra-estrutura necessária. É ele que controla o acesso à placa de vídeo, lê as teclas digitadas no teclado e os clicks do mouse e oferece todos os recursos necessários para os programas criarem janelas e mostrarem conteúdo na tela. Se você chamar o X sozinho, a partir do modo texto (o que pode ser feito com o comando "X" ou "X :2" caso você queira abrir uma segunda seção do X), você verá apenas uma tela cinza, com um X que representa o cursor do mouse. Ou seja, o X é apenas uma base, ele sozinho não faz muita coisa. Se você chamá-lo com o comando "xinit" ou "xinit -- :2", você já abrirá junto uma janela de terminal, que poderá ser usada para abrir programas. Porém, ao abrir qualquer programa gráfico, você perceberá que algo está estranho. A janela do programa é aberta, mas fica fixa na tela, você não tem como minimizá-la, alternar para outra janela, nem nenhuma outra opção:

Isto acontece porque estas tarefas são controladas pelo gerenciador de janelas, que (em quase todas as distribuições) não é carregado com o comando xinit. Existem vários gerenciadores de  janelas, como o KDE, Gnome, Window Maker, Fluxbox, IceWM e assim por diante. A idéia é que você possa escolher qual lhe agrada mais.

Chamando o X através do comando "startx", ou configurando o sistema para carregar o X automaticamente durante a inicialização, finalmente carregamos o conjunto completo, com o X e algum gerenciador de janelas rodando sobre ele. O Xfree utiliza uma arquitetura cliente-servidor, onde o X em si atua como o servidor e os programas como clientes, que recebem dele os clicks do mouse e as teclas digitadas no teclado e enviam de volta as janelas a serem mostradas na tela. A grande vantagem deste sistema é que além de rodar programas localmente é possível rodar programas instalados em outras máquinas da rede. Existem várias formas de fazer isto. Você pode, por exemplo, abrir uma janela de terminal dentro do X, conectar-se à outra máquina, via SSH e começar a chamar os programas desejados. Para isso, use o comando "ssh -X IP_da_maquina", como em: # ssh -X 192.168.0.1 O parâmetro -X ativa a execução de aplicativos gráficos via SSH, que vem desativado por padrão em algumas distribuições. Para usar o ssh, o serviço "ssh" deve estar ativo na máquina que está sendo acessada. Outra opção é usar o XDMCP, o protocolo nativo do X para obter a tela de login da máquina remota e a partir daí carregar um gerenciador de janelas e rodar todos os programas via rede. Neste caso você precisaria configurar a outra máquina para aceitar as conexões via XDMCP nos arquivos kdmrc e Xaccess, que vão dentro da pasta "/etc/kde3/kdm/" ou "/usr/share/config/kdm/kdmrc" (ao usar o KDM) ou no gdmsetup (ao usar o GDM) e inicializar o X com o comando "X :2 -query IP_da_maquina" no PC cliente, como em: # X :2 -query 192.168.0.1

Muita gente diz que este sistema cliente/servidor do X é uma arquitetura ultrapassada, que é responsável por um desempenho ruim se comparado com outros sistemas operacionais, pois tudo teria que passar pela rede antes de ir para o monitor. Esta idéia é errada, pois, ao rodar localmente, o X se comunica diretamente com a placa de vídeo, usando todos os recursos de aceleração suportados. Entra aí a questão do driver. Se você tentar rodar um game 3D qualquer, antes de instalar os drivers 3D (da nVidia) para sua placa nVidia, por exemplo, ele vai rodar com um desempenho muito baixo, simplesmente porque os recursos 3D da placa não estão ativados. O driver open-source do X para placas nVidia (o driver "nv") oferece apenas suporte 2D. Algumas placas realmente não possuem ainda drivers 3D no X, como, por exemplo, a maior parte das placas onboard da SiS. Isto tem mais a ver com a boa vontade (ou falta desta) do fabricante em desenvolver drivers ou pelo menos disponibilizar as especificações das placas. A SiS é um dos fabricantes mais hostis, o que faz com que suas placas tenham um suporte ruim. Como sempre é questão de pesquisar antes de comprar. Os comandos de atualização das janelas e outros recursos usados são transmitidos pelo X através de uma interface de rede local (a famosa interface de loopback), o que num PC

moderno tem um overhead muito pequeno. Os problemas de desempenho em algumas placas estão mais relacionados à qualidade dos drivers.

Gerenciador de login Antigamente, era muito comum dar boot em modo texto e deixar para abrir o X manualmente rodando o comando "startx" apenas quando necessário, pois os PCs eram lentos e o X demorava para abrir. Atualmente, o mais comum é usar um gerenciador de login, como o KDM (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áfico usando 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, o Xfree e o X.org. O Xfree é o projeto mais antigo e tradicional, o grupo que originalmente portou o X para o Linux, e foi o principal mantenedor do projeto desde então. Com o passar do tempo, começaram a surgir críticas, principalmente direcionadas à demora para incluir correções e atualizações nos drivers existentes. Isto foi se agravando com o tempo, até que uma decisão dos desenvolvedores em fazer uma pequena mudança na licença em

vigor a partir do Xfree 4.4 foi a gota d'água para que um consórcio formado por membros de várias distribuições, desenvolvedores descontentes com o modo de desenvolvimento antigo, se juntassem para criar um fork do Xfree, o X.org. O X.org utilizou como base inicial a última versão de desenvolvimento da série 4.3 do Xfree, disponibilizada antes da mudança da licença. Desde então, foram incluídas muitas atualizações e correções, como novos drivers e vários recursos cosméticos, como, por exemplo, suporte a  janelas transparentes. A página oficial é a http://x.org. Inicialmente, as diferenças eram pequenas, mas depois de um certo tempo o X.org passou a concentrar a maior parte das atualizações e novos 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ção de uma distribuição com o Xfree em outra (instalada na mesma máquina) com o X.org. Aqui vai uma pequena tabela com algumas diferenças: - Arquivo de configuração principal: /etc/X11/XF86Config-4 = /etc/X11/xorg.conf  - Utilitários de configuração: xf86cfg = xorgfg xf86config = xorgconfig É possível também eliminar estas diferenças criando um conjunto de links apontando para os nomes trocados. Assim o XF86Config-4 vira um link para o xorg.conf, por exemplo, fazendo com que usuários desavisados e até utilitários de configuração consigam encontrar os arquivos sem muitos problemas.

A árvore genealógica das distribuições Por causa da filosofia de código aberto e compartilhamento de informações que existe no mundo Linux, é muito raro que uma nova distribuição seja desenvolvida do zero. Quase sempre as distribuições surgem como forks ou personalizações de uma outra distribuição mais antiga e preservam a maior parte das características da distribuição original. Isso faz com que distribuições dentro da mesma linhagem conservem mais semelhanças do que diferenças entre si.

Das primeiras distribuições Linux, que surgiram entre 1991 e 1993, a única que sobrevive até hoje é o Slackware, que deu origem a algumas outras distribuições conhecidas, como o Vector, Slax e o College. O Slax é um live-CD, desenvolvido para caber em um mini-CD; o Vector é uma distribuição enxuta, otimizada para micros antigos, enquanto o College é uma distribuição desenvolvida com foco no público estudantil, com o objetivo de ser fácil de usar. Os três utilizam pacotes .tgz do Slackware e são quase sempre compatíveis com os pacotes do Slackware da versão correspondente. Os utilitários de configuração do Slackware, como o netconfig continuam disponíveis, junto com vários novos scripts que facilitam a configuração do sistema. O Vector, por exemplo, inclui o Vasm, uma ferramenta central de configuração. O Debian apareceu pouco depois e, ao longo dos anos, acabou dando origem a quase metade das distribuições atualmente em uso. Algumas, como o Knoppix e o Kurumin, continuam utilizando os pacotes dos repositórios Debian, apenas acrescentando novos pacotes e ferramentas, enquanto outras, como o Lycoris e o Ubuntu, utilizam repositórios separados, apenas parcialmente compatíveis com os pacotes originais, mas sempre mantendo o uso do apt-get e a estrutura básica do sistema. Embora o Debian não seja exatamente uma distribuição fácil de usar, o apt-get e o gigantesco número de pacotes disponíveis nos repositórios formam uma base muito sólida para o desenvolvimento de personalizações e novas distribuições. Um dos principais destaques é que, nas versões Testing e Unstable, o desenvolvimento do sistema é contínuo e, mesmo no Stable, é possível atualizar de um release para outro sem reinstalar nem fazer muitas modificações no sistema. Você pode manter o sistema atualizado usando indefinidamente o comando "apt-get upgrade". Isso permite que os desenvolvedores de distribuições derivadas deixem o trabalho de atualização dos pacotes para a equipe do Debian e se concentrem em adicionar novos recursos e corrigir problemas. Um dos exemplos de maior sucesso é o Knoppix, que chega a ser um marco. Ele se tornou rapidamente uma das distribuições live-CD mais usadas e deu origem a um universo gigantesco de novas distribuições, incluindo o Kurumin. Uma coisa interessante é que o Knoppix mantém a estrutura Debian quase intacta, o que fez com que instalar o Knoppix no HD acabasse tornando-se uma forma alternativa de instalar o Debian. Outro exemplo de sucesso é o Ubuntu, uma versão do Debian destinada a iniciantes e a empresas, que rapidamente se transformou em umas das distribuições mais usadas no mundo. As distribuições derivadas do Knoppix muitas vezes vão além, incluindo novos componentes que tornam o sistema mais adequado para usos específicos. O Kurumin inclui muitas personalizações e scripts destinados a tornar o sistema mais fácil de usar e mais adequado para uso em desktop. O Kanotix inclui muitos patches no Kernel, com o objetivo de oferecer suporte a mais hardware e novos recursos, enquanto o Morphix usa uma estrutura modular, que acabou servindo de base para o desenvolvimento de mais uma safra de distribuições, já bisnetas do Debian.

Mais adiante, teremos um capítulo dedicado a explicar o processo de personalização do Kurumin e outros live-CDs derivados do Knoppix, permitindo que você desenvolva suas próprias soluções. Tanto o Debian quanto o Slackware são distribuições basicamente não comerciais. Mas isso não impede que distribuições como o Lycoris, Xandros e Linspire sejam desenvolvidas por empresas tradicionais, com fins lucrativos. Elas procuram se diferenciar das distribuições gratuitas, investindo em marketing e no desenvolvimento de ferramentas de configuração e facilidades em geral. Durante o livro, vou sempre citar muitos comandos que se aplicam ao Debian, lembre-se de que eles também se aplicam à outras distribuições derivadas dele, como o Ubuntu, Kurumin e o Knoppix. A terceira distribuição "mãe" é o Red Hat, que deu origem ao Mandrake e Conectiva (que mais tarde se juntaram, formando o atual Mandriva), Fedora e, mais recentemente, a um enorme conjunto de distribuições menores. As distribuições derivadas do Red Hat não utilizam um repositório comum, como no caso do Debian, e nem mesmo um gerenciador de pacotes comum. Temos o yun do Fedora, o urpmi do Mandriva e também o próprio apt-get, portado pela equipe do Conectiva. Temos ainda vários repositórios independentes, que complementam os repositórios oficiais das distribuições. As distribuições derivadas do Red Hat são, junto com o Debian e derivados, as mais usadas em servidores. O Fedora, Red Hat e SuSE possuem também uma penetração relativamente grande nos desktops nas empresas, enquanto o Mandriva tem o maior público entre os usuários domésticos. Embora todas estas distribuições utilizem pacotes rpm, não existe garantia de compatibilidade entre os pacotes de diferentes distribuições. Os pacotes de uma versão recente do SuSE na maioria das vezes funcionam também numa versão equivalente do Mandriva, por exemplo, mas isto não é uma regra. O Gentoo inaugurou uma nova linhagem trazendo uma abordagem diferente das demais distribuições para a questão da instalação de programas e instalação do sistema. Tradicionalmente, novos programas são instalados através de pacotes pré-compilados, que são basicamente arquivos compactados, contendo os executáveis, bibliotecas e arquivos de configuração usados pelo programa. Estes pacotes são gerenciados pelo apt-get, urpmi, yun ou outro gerenciador usado pela distribuição. Compilar programas a partir dos fontes é quase sempre um último recurso para instalar programas recentes, que ainda não possuem pacotes disponíveis. O Gentoo utiliza o Portage, um gerenciador de pacotes que segue a idéia dos ports do FreeBSD. Os pacotes não contém binários, mas sim o código fonte do programa, junto com um arquivo com parâmetros que são usados na compilação. Você pode ativar as otimizações que quiser, mas o processo de compilação e instalação é automático. Você pode instalar todo o KDE, por exemplo, com um "emerge kde". O Portage baixa os pacotes com os fontes (de forma similar ao apt-get), compila e instala.

O ponto positivo desta abordagem é que você pode compilar todo o sistema com otimizações para o processador usado na sua máquina. Isso resulta em ganhos de 2 a5% na maior parte dos programas, mas pode chegar a 30% em alguns aplicativos específicos. A parte ruim é que compilar programas grandes demora um bocado, mesmo em máquinas atuais. Instalar um sistema completo, com o X, KDE e OpenOffice demora um dia inteiro num Athlon 2800+ e pode tomar um final de semana numa máquina um pouco mais antiga. Você pode usar o Portage também para atualizar todo sistema, usando os comandos "emerge sync && emerge -u world" de uma forma similar ao "apt-get upgrade" do Debian. Nas versões atuais do Gentoo, você pode escolher entre diferentes modos de instalação. No stage 1 tudo é compilado a partir dos fontes, incluindo o Kernel e as bibliotecas básicas. No stage 2 é instalado um sistema base pré-compilado e apenas os aplicativos são compilados. No stage 3 o sistema inteiro é instalado a partir de pacotes pré-compilados, de forma similar a outras distribuições. A única exceção fica por conta do Kernel, que sempre precisa ser compilado localmente, mesmo ao usar o stage 2 ou 3. O stage 1 é naturalmente a instalação mais demorada, mas é onde você pode ativar otimizações para todos os componentes do sistema. Já existe um conjunto crescente de distribuições baseadas no Gentoo, como vários live-CDs, com games e versões modificadas do sistema, alguns desenvolvidos pela equipe oficial, outros por colaboradores. Uma das primeiras distribuições a utilizar o Gentoo como base foi o Vidalinux. Embora seja uma das distribuições mais difíceis, cuja instalação envolve mais trabalho manual, o Gentoo consegue ser popular entre os usuários avançados, o que acabou por criar uma grande comunidade de colaboradores em torno do projeto. Isto faz com que o Portage ofereça um conjunto muito grande de pacotes, quase tantos quanto no apt-get do Debian, incluindo drivers para placas nVidia e ATI, entre outros drivers proprietários, e exista uma grande quantidade de documentação disponível, com textos quase sempre atualizados.

Capítulo 2: Configuração, ferramentas e dicas A melhor forma de aprender é sempre praticando, certo? Este capítulo é uma coleção de dicas sobre os arquivos de configuração, ferramentas e utilitários úteis, que tem o objetivo de aprofundar seus conhecimentos sobre o sistema. Os tópicos estão organizados por nível de dificuldade.

Editando o /etc/fstab O arquivo "/etc/fstab" permite configurar o sistema para montar partições, CD-ROMs, disquetes e compartilhamentos de rede durante o boot. Cada linha é responsável por um ponto de montagem. É através do "/etc/fstab" que o sistema é capaz de acessar o seu CDROM, por exemplo. O fstab é um dos arquivos essenciais para o funcionamento do sistema, por isso, antes de editá-lo, faça sempre uma cópia de segurança: # cp /etc/fstab /etc/fstab-original

O fstab é um arquivo de texto simples, assim como a maior parte dos arquivos de configuração do sistema. Você pode abri-lo usando qualquer editor de textos, mas sempre como root: # kedit /etc/fstab

À primeira vista o fstab parece ser mais um daqueles arquivos indecifráveis. Ele possui uma lógica própria que parece um 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 automaticamente durante o boot, sem depender de configuradores automáticos. Vamos começar dando uma olhada no "/etc/fstab" de uma máquina que está com o Kurumin instalado na partição hda2: # /etc/fstab: filesystem table. # filesystem mountpoint type options dump pass /dev/hda2 / reiserfs defaults 0 1 /dev/hda5 none swap sw 0 0 proc /proc proc defaults 0 0 /dev/fd0 /floppy vfat defaults,user,noauto,showexec,umask=022 0 0 /dev/cdrom /mnt/cdrom iso9660 defaults,ro,user,noexec,noauto 0 0 # partições encontradas pelo instalador: /dev/hda1 /mnt/hda1 reiserfs noauto,users,exec 0 0 /dev/hda2 /mnt/hda2 reiserfs noauto,users,exec 0 0 /dev/hda3 /mnt/hda3 reiserfs noauto,users,exec 0 0 /dev/hda6 /mnt/hda6 reiserfs noauto,users,exec 0 0 # Monta a partição /home, adicionado pelo instalador do Kurumin /dev/hda3 /home reiserfs notail 0 2 # Ativa o USB usbdevfs /proc/bus/usb usbdevfs defaults 0 0 Este é o arquivo gerado automaticamente durante a instalação, por isso ele está um pouco sujo. Vamos começar entendo o que cada linha significa. Lembre-se de que as linhas começadas com # não fazem nada, são apenas comentários. /dev/hda2 / reiserfs defaults 0 1

Esta linha monta o diretório raiz do sistema. No exemplo, o Kurumin está instalado na partição /dev/hda2 que está formatada em ReiserFS. O "/" é o ponto de montagem, ou seja, onde esta partição fica acessível. A barra indica que esta é a partição raiz, onde o sistema está instalado. Se, por acaso, a partição estivesse formatada em outro sistema de arquivos, em EXT3, por exemplo, a linha ficaria: "/dev/hda2 / ext3 defaults 0 1". Os dois números depois do "defaults" são instruções para programas externos.

O primeiro número é usado pelo programa dump, 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úmero 0 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 deve usar o número 0. O segundo número (1 no exemplo) é uma instrução para o fsck, 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úmero 1 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 a partição swap não é montada em nenhuma pasta, ela serve apenas para uso interno do sistema. /dev/cdrom /mnt/cdrom iso9660 defaults,user,noauto 0 0

Esta linha habilita o drive de CD-ROM. O /dev/cdrom é o dispositivo do CD-ROM, na verdade um link que é criado durante a configuração inicial do sistema e aponta para a localização correta do CD-ROM. De acordo com a porta em que o CD-ROM estiver instalado, o dispositivo real do CD-ROM pode ser: /dev/hdc: Um CD-ROM instalado como master na segunda porta IDE da placa-mãe. /dev/hdd: CD-ROM instalado como slave na segunda porta IDE /dev/sda ou /dev/sr0: Em distribuições que usam o Kernel 2.4, os gravadores de CD IDE são

detectados pelo sistema como se fossem discos SCSI. Dependendo da distribuição eles podem ser detectados como "/dev/sda" ou "/dev/sr0". Caso você tenha dois gravadores, o segundo é reconhecido como "/dev/sdb" ou "/dev/sr1". No Kernel 2.6, não é mais usada a emulação SCSI, de forma que os gravadores são acessados diretamente através dos dispositivos "/dev/hdc" ou "/dev/hdd". /dev/sr0 ou /dev/sr1: Leitores e gravadores de CD USB também são detectados como CDs

SCSI. Ao plugar um drive externo ligado à porta USB, ele será detectado como "/dev/sr0" (ou "/dev/sr1", caso a primeira posição já esteja ocupada). No caso dos leitores e gravadores USB, não importa se está sendo usado o Kernel 2.4 ou 2.6. Para que os arquivos do CD-ROM fiquem acessíveis, ele precisa ser montado em algum lugar. A próxima entrada da linha é o "/mnt/cdrom", que indica a pasta onde ele fica acessível. O

iso9660 é o sistema de arquivos universalmente usado em CD-ROMs de dados, é graças a ele

que não existem problemas para ler o mesmo CD no Linux ou Windows. Em seguida temos três opções: defaults,user,noauto. Elas fazem o seguinte: user: Permite que você monte e desmonte o CD-ROM mesmo sem estar logado como root. noauto: faz com que o CD-ROM seja montado apenas quando você for acessá-lo e não

automaticamente durante o boot, como no caso da partição raiz, por exemplo. Caso você queira ativar um segundo drive de CD, adicionaria uma linha assim: /dev/hdd /mnt/cdrom1 iso9660 defaults,user,noauto 0 0

Veja que mudaram duas coisas: o dispositivo do CD-ROM (/dev/hdd) e a pasta onde ele fica acessível (/mnt/cdrom1). Para acessar o segundo CD-ROM, você digitaria " mount /mnt/cdrom1" O KDE oferece um recurso muito interessante que é a possibilidade de montar e desmontar as entradas incluídas no /etc/fstab através de ícones no desktop, como os usados para acessar as partições do HD ao rodar o Kurumin do CD. Para criar um destes ícones, clique com o botão direito sobre a área de trabalho e vá em: "Criar novo", escolha "Disco rígido ou CD-ROM" e aponte a entrada do fstab referente a ele nas propriedades:

Para montar e acessar os arquivos, basta clicar sobre o ícone e para desmontar, clique com o botão direito e escolha "desmontar".

A linha seguinte do arquivo serve para montar a partição home, que no exemplo foi colocada em uma partição separada: /dev/hda3 /home reiserfs notail 0 2

Traduzindo para o português, a linha diz: "Monte a partição /dev/hda3 no diretório /home. Esta partição está formatada em reiserfs e você deve usar a opção notail". O notail é uma opção do sistema de arquivos ReiserFS, que melhora um pouco a velocidade de acesso ao trabalhar com arquivos grandes. Cada sistema de arquivos possui algumas opções extras, que podem ser usadas para melhorar o desempenho ou tolerância a falhas em determinadas situações. O parâmetro "noatime", por exemplo, faz com que o sistema não atualize as propriedades dos arquivos conforme eles ao acessados (altera apenas quando eles são modificados). Ela melhora absurdamente o desempenho do sistema em algumas áreas específicas, onde os mesmos arquivos são acessados continuamente, como nos servidores de banco de dados. É muito comum combinar as duas opções, como em: /dev/hda3 /home reiserfs notail,noatime 0 2

Usar uma partição home separada permite que você possa reinstalar o sistema sem perder seus arquivos e configurações, o que é especialmente interessante no caso do Kurumin e outras distribuições atualizadas freqüentemente. Usando um diretório home separado, as reinstalações tornam-se mais transparentes. Você ainda precisa reinstalar os programas, mas todas as configurações dos aplicativos são preservadas. Cada programa armazena suas configurações dentro de uma pasta oculta dentro do seu diretório de usuário, como ".mozilla", ".kde", etc. Mesmo ao reinstalar o sistema, estas pastas são reconhecidas e as configurações antigas preservadas. Basta tomar o cuidado de guardar também todos os seus arquivos dentro do diretório home e você não perderá quase nada ao reinstalar.

Continuando, temos as entradas para outras partições que foram encontradas pelo instalador: # partições encontradas pelo instalador: /dev/hda1 /mnt/hda1 reiserfs noauto,users,exec 0 0 /dev/hda2 /mnt/hda2 reiserfs noauto,users,exec 0 0 /dev/hda3 /mnt/hda3 reiserfs noauto,users,exec 0 0 /dev/hda6 /mnt/hda6 reiserfs noauto,users,exec 0 0 Veja que as partições "/dev/hda2" e "/dev/hda3" já estão sendo usadas, por isso as duas linhas referentes a elas são redundantes e podem ser removidas. As linhas para as outras duas partições, "/dev/hda1" (uma instalação do Mandriva) e "/dev/hda6" (uma partição de arquivos) estão com a opção "noauto", como no caso do CD-ROM, que faz com que elas sejam montadas apenas quando você clica nos ícones do desktop. Se você preferir que elas sejam montadas automaticamente durante o boot, basta eliminar esta opção. Neste caso as linhas ficariam assim: /dev/hda1 /mnt/hda1 reiserfs users,exec 0 0 /dev/hda6 /mnt/hda6 reiserfs users,exec 0 0

Além de montar as partições e CD-ROMs locais, o fstab pode ser configurado para montar também compartilhamentos de rede. Você pode tanto configurar para que os compartilhamentos fiquem acessíveis automaticamente durante o boot (no caso de um servidor que fique sempre ligado) ou montá-los através de ícones no desktop, como no caso do CD-ROM. Para montar um compartilhamento de rede NFS, a linha seria: 192.168.0.1:/home/arquivos /mnt/arquivos nfs noauto,users,exec 0 0

Neste exemplo o "192.168.0.1:/home/arquivos" é o IP do servidor, seguido pela pasta compartilhada e o "/mnt/arquivos" é a pasta local onde este compartilhamento ficará acessível. Você pode incluir várias linhas, caso deseje montar vários compartilhamentos. Caso o servidor fique sempre ligado e você queira que o compartilhamento seja montado automaticamente durante o boot, retire o "noauto", caso contrário você pode acessar o compartilhamento usando o comando: # mount /mnt/arquivos

Para montar um compartilhamento de rede Windows ou de um servidor Linux rodando o Samba, a linha seria: //192.168.0.1/teste /home/teste smb noauto,user,username=maria,password=abcde 0 0

Veja que neste caso a sintaxe já é um pouco mais complicada. Em primeiro lugar, a entrada que fala sobre o compartilhamento usa a sintaxe: "//ip_do_servidor/compartilhamento", por isso você usa "//192.168.0.1/teste" e não "192.168.0.1:/teste" como seria num compartilhamento NFS.

Em seguida vem a pasta onde o compartilhamento ficará acessível, " /home/teste" no exemplo. Não se esqueça de criar a pasta, caso não exista. O smb é o nome do protocolo usado para acessar os compartilhamentos Windows da rede. Outra etapa importante é colocar o usuário e senha que será usado para acessar o compartilhamento, como em: "user,username=maria,password=abcde" . Caso o compartilhamento não use senha (como os compartilhamentos do Windows 95/98), a linha fica mais simples: //192.168.0.1/arquivos /home/arquivos smb noauto,user 0 0

Assim como no caso do NFS, para montar o compartilhamento use o comando: # mount /home/arquivos

Se preferir que ele seja montado durante o boot, basta retirar o "noauto". Neste caso a linha no fstab ficaria: //192.168.0.1/teste /home/teste smb user,username=maria,password=abcde 0 0

Ao colocar as senhas dos compartilhamentos de rede no "/etc/fstab" é necessário tomar uma precaução de segurança. Rode o comando: # chmod 600 /etc/fstab

Isto fará com que apenas o root possa ler o arquivo e conseqüentemente ver as senhas. O default na maioria das distribuições é 644, o que permite que os outros usuários da máquina possam ler o arquivo, uma grande brecha de segurança neste caso. Uma coisa que você deve ter percebido é que o KDE só oferece a opção de criar ícones para montar partições, disquetes e CD-ROMs, mas não para criar ícones para montar compartilhamentos de rede. Mas é possível criar os ícones manualmente. Os ícones do KDE, incluindo os do desktop e do iniciar, são arquivos de texto comuns, cujo nome termina com .desktop. Isto faz com que o KDE os veja como ícones, e não simples arquivos de texto. Naturalmente estes arquivos possuem uma sintaxe especial, mas nada tão exótico. Em primeiro lugar, o desktop no KDE corresponde à pasta Desktop, dentro do seu diretório de usuário, como em "/home/kurumin/Desktop". Para criar um novo ícone no desktop basta criar um arquivo de texto, cujo nome termine com ".desktop": $ kedit /home/carlos/Desktop/compartilhamento.des ktop

Dentro do novo arquivo, vai o seguinte: [Desktop Entry] Type=FSDevice Dev=192.168.1.34:/arquivos MountPoint=/mnt/nfs

FSType=nfs ReadOnly=0 Icon=hdd_mount UnmountIcon=hdd_unmount Name=192.168.1.34:/arquivos O "192.168.1.34:/mnt/hda6" é o endereço do compartilhamento e o "nfs" é o protocolo. O "/mnt/nfs" é a pasta onde ele ficará acessível. O texto que vai na opção "Name" é o nome que aparecerá no desktop, você pode usar qualquer texto. No meu caso simplesmente repeti o endereço do compartilhamento para facilitar a identificação. Para um compartilhamento Windows o texto seria: [Desktop Entry] Type=FSDevice Dev=//192.168.1.34/arquivos MountPoint=/mnt/samba FSType=smb ReadOnly=0 Icon=hdd_mount UnmountIcon=hdd_unmount Name=arquivos Salvando o arquivo, o ícone já aparecerá no desktop e se comportará da mesma forma que o do CD-ROM. Basta clicar para ver os arquivos ou acionar o "desmontar" para desativar:

Configurando o lilo O lilo e o grub disputam o posto de gerenciador de boot default entre as distribuições Linux. O lilo é o mais antigo e mais simples de configurar, enquanto o grub é o que oferece mais opções. Mas, ao invés de ficar discutindo qual é melhor, vamos aprender logo a configurar e resolver problemas nos dois :-). O lilo utiliza um único arquivo de configuração, o "/etc/lilo.conf ". Ao fazer qualquer alteração neste arquivo é preciso chamar (como root) o executável do lilo, o "/sbin/lilo" ou simplesmente "lilo" para que ele leia o arquivo e salve as alterações. Vamos começar entendendo a função das linhas de uma configuração típica. Abra o arquivo "/etc/lilo.conf" da sua máquina e acompanhe opção a opção. boot=/dev/hda

Esta é quase sempre a primeira linha do arquivo. Ela indica onde o lilo será instalado. Indicando um dispositivo, como em " /dev/hda", ele é instalado na trilha MBR do HD. Indicando uma partição, como em "/dev/hda1" ele é instalado no primeiro setor da partição, sem reescrever a MBR. Ao instalar vários sistemas no HD, seja Linux e Windows ou várias distribuições diferentes, apenas um deles deve ter o lilo gravado na MBR. Este terá a função de inicializar todos os outros, cujos gerenciadores foram instalados nas respectivas partições. Ao verificar esta linha, lembre-se de verificar qual é o dispositivo do HD na sua instalação. Um HD serial ATA, por exemplo, será detectado como "/dev/sda" e não como "/dev/hda". Se você tiver dois HDs, e estiver instalando o sistema numa partição do segundo ("/dev/hdb1", por exemplo), e usar a linha "boot=/dev/hdb", o lilo será instalado no MBR do segundo HD, não do primeiro. Durante o boot, o BIOS vai continuar lendo o MBR do primeiro HD, 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 destes modelos, 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.

prompt compact default=Linux timeout=100 A linha "timeout=" indica o tempo de espera antes de entrar no sistema padrão, em décimos de segundo. O valor máximo é 30000 (3.000 segundos). Não use um número maior que isto, ou o lilo acusará o erro e não será gravado corretamente. Ao usar o número "0" ou omitir a opção, o lilo espera indefinidamente. Se, ao contrário, você quiser que ele inicie direto o sistema padrão, sem perguntar, você tem duas opções: usar a timeout=1 (que faz com ele espere só 0.1 segundo, imperceptível), ou remover a linha "prompt". A linha "compact" otimiza a fase inicial do boot (incluindo o carregamento inicial do Kernel), fazendo com que a controladora do HD leia vários setores seqüenciais em cada leitura. Normalmente ela reduz o tempo de boot em cerca de 2 segundos. Não é nada drástico, mas não deixa de ser um pequeno ganho. append = "nomce quiet noapic" A linha "append" contém parâmetros que são repassados ao Kernel, de forma a alterar o comportamento padrão do sistema e corrigir problemas de inicialização. Você pode incluir um número indefinido de opções, separando-as com um espaço. A opção mais relevante e mais usada aqui é o "acpi=off ", que desabilita o uso do ACPI, resolvendo problemas de travamento ou bugs diversos em muitas placas. Note que o ACPI é um recurso cada vez mais importante, sobretudo em notebooks, onde é usado não apenas para monitorar o estado das baterias, mas também para controlar diversas funções e até mesmo fazer o desligamento da máquina. Use o apci=off" apenas quando realmente necessário. Uma variação é o "acpi=ht", que ao invés de desabilitar o ACPI completamente, mantém ativas as funções necessárias para habilitar o suporte a Hyper Treading nos processadores Pentium 4. É útil em máquinas baseadas neles. Outra opção comumente usada para solucionar problemas é a "noapci", que desabilita a realocação dinâmica de endereços por parte do BIOS, deixando que o sistema operacional assuma a função. Inúmeros modelos de placas-mãe possuem problemas relacionados a isso, que podem causar desde problemas menores, como a placa de som ou rede não ser detectada pelo sistema, até travamentos durante o boot. Este problemas são solucionados ao incluir o "noapic". A opção "quiet" faz com que sejam exibidas menos mensagens na fase inicial do boot, quando o Kernel é inicializado; tem uma função puramente estética. A opção "apm=power-off " faz com que sejam usadas as funções do APM para desligar o micro, ao invés do ACPI. Adicionar esta opção resolve problemas de desligamento em muitas máquinas. Outra opção útil é a "reboot=b", que resolve problemas de travamento ao reiniciar em algumas máquinas. As duas podem ser usadas simultaneamente caso necessário.

Todas estas opções, quando usadas, são incluídas dentro da linha append (separadas por espaço), como em: append = "nomce quiet noapic acpi=off apm=power-off reboot=b" Em seguida, vem a seção principal, responsável por inicializar o sistema. Ela contém a localização do executável principal do Kernel e do arquivo initrd, caso seja usado um: image=/boot/vmlinuz-2.6.14 label=Linux root=/dev/hda1 read-only initrd=/boot/initrd.gz A linha "root=" indica a partição onde o sistema está instalado, ou seja, onde o lilo vai procurar os arquivos especificados. O "Label" é o nome do sistema, da forma como você escreve na opção "default=". Uma observação importante é que o nome pode ter no máximo 14 caracteres e não deve conter caracteres especiais. O lilo é bastante chato com relação a erros dentro do arquivo, se recusando a fazer a gravação até que o erro seja corrigido. Esta é a seção que é duplicada ao instalar um segundo Kernel. Caso você instalasse o pacote "kernel-image-2.6.15_i368.deb", por exemplo, que criasse o arquivo "/boot/vmlinuz-2.6.15", você adicionaria as linhas: image=/boot/vmlinuz-2.6.15 label=kernel-2.6.15 root=/dev/hda1 read-only initrd=/boot/initrd.gz Ao reiniciar o micro, você passaria a escolher entre os dois kernels na hora do boot. Se quisesse tornar o 2.6.15 a opção padrão, bastaria fazer a alteração na linha "default=". Ao instalar vários sistemas na mesma máquina, você pode adicionar linhas extras referentes a cada um. Neste caso, fazemos uma coisa chamada "chain load", onde o lilo carrega o gerenciador de boot do outro sistema (instalado na partição) e deixa que ele faça seu trabalho, carregando o respectivo sistema. A configuração para outros sistemas é bem simples, pois você só precisa indicar a partição de instalação e o nome de cada um, como em: other=/dev/hda2 label=Slackware other=/dev/hda3 label=Mandriva other=/dev/hda5 label=Fedora

other=/dev/hda6 label=OpenSuSE Para referenciar as outras instalações deste modo, é necessário que o lilo de cada um esteja instalado no primeiro setor da partição. No lilo.conf do Slackware, por exemplo, haveria a linha "boot=/dev/hda2". No caso do Windows, você não precisa se preocupar, pois ele instala o gerenciador de boot simultaneamente no MBR e na partição. Existe uma receita simples para alterar e reinstalar o lilo de outras distribuições instaladas no HD em caso de problemas. Imagine, por exemplo, que você instalou o Kurumin e acabou instalando o lilo no MBR, subscrevendo o lilo do Mandriva, que agora não dá mais boot. Isso pode ser solucionado facilmente, editando o "/etc/lilo.conf" do Mandriva, para que ele seja reinstalado na partição e adicionando as duas linhas que chamam outros sistemas no lilo do Kurumin. Você pode editar o lilo do Mandriva e regravá-lo rapidamente através do próprio Kurumin (ou outra distribuição instalada), ou dando boot com um CD do Kurumin ou Knoppix. Dê boot pelo CD e abra um terminal. Defina a senha de root usando o comando "sudo passwd" e logue-se como root usando o "su". Monte a partição onde o Mandriva está instalado: # mount -t reiserfs /dev/hda1 /mnt/hda1

Agora usamos o comando chroot para "entrar" na partição montada, a fim de editar o lilo.conf  e gravar o lilo. Todos os comandos dados dentro do chroot são na verdade executados no sistema que está instalado na partição. É preciso Indicar o sistema de arquivos em que a partição está formatada ao montar (como no exemplo acima), caso contrário o chroot vai dar um erro de permissão. # chroot /dev/hda1

Agora use um editor de texto em modo texto, como o mcedit ou o joe para alterar o arquivo "/etc/lilo.conf" e chame o executável do lilo para salvar as alterações. Depois de terminar, pressione Ctrl+D para sair do chroot. # mcedit /etc/lilo.conf  # lilo

É possível também remover o lilo, usando o comando " lilo -u" ("u" de uninstall). Ao ser instalado pela primeira vez, o lilo faz um backup do conteúdo da MBR e ao ser removido este backup é recuperado. Esta opção pode ser útil em casos onde você instala o lilo na MBR (sem querer) e precisa recuperar o sistema anterior. Dual-Boot com dois HDs

Em casos onde você realmente não queira saber do menor risco para seus arquivos de trabalho ao configurar o dual boot, existe ainda a opção de usar dois HDs.

Instale o HD que abrigará as distribuições Linux como master da primeira IDE e o HD com o Windows como slave. Deixe a segunda IDE reservada para o CD-ROM ou gravador, o que garantirá um melhor desempenho a partir dos dois sistemas. Detecte ambos os HDs no Setup e instale as distribuições desejadas no primeiro, configurando o lilo para inicializar todos os sistemas. Depois de terminar, adicione as linhas que iniciarão o Windows. Como ele está instalado no segundo HD, usaremos um pequeno truque que troca a posição dos drivers, fazendo o Windows pensar que o HD onde está instalado continua instalado como primary master: other=/dev/hdb1 label=Windows table=/dev/hdb map-drive = 0x80 to = 0x81 map-drive = 0x81 to = 0x80 Isso funciona com o Windows NT, 2000 e XP. Basicamente as linhas carregam a tabela de partição do segundo HD e a partir daí dão boot a partir do drive C: do Windows. As últimas quatro linhas são responsáveis por trocar a posição dos drives. Usando uma imagem de fundo

Como você pôde ver no exemplo, a configuração necessária para que o lilo exiba um menu de boot gráfico ocupa apenas 4 linhas no início do arquivo. Nem todas as distribuições usam este recurso por padrão (como o Slackware), mas é simples ativar manualmente. Em primeiro lugar, você precisa de uma imagem de 640x480 com 256 cores (indexada), salva em .bmp. No Gimp existe a opção de codificar a imagem usando RLE, o que diminui muito o tamanho, sem quebrar a compatibilidade com o lilo. Você pode baixar algumas imagens prontas no http://www.kde-look.org, basta salvar a imagem escolhida dentro da pasta /boot. A localização do arquivo com a imagem, dentro da partição do sistema, vai na linha "bitmap =", como em: bitmap = /boot/imagem.bmp O próximo passo é definir as cores e coordenadas do menu com a lista dos sistemas disponíveis e da contagem de tempo. A configuração das cores é a parte mais complicada, pois os códigos variam de acordo com a paleta usada na imagem escolhida. Abra a imagem no Gimp e clique em "Diálogos > Mapa de Cores". Isso mostra as cores usadas e o número (índice da cor) de cada uma. As cores usadas no lilo são definidas na opção "bmp-colors", onde você define uma cor para a opção selecionada e outra para as outras opções do menu. Cada uma das duas escolhas tem três cores, uma para as letras, outra para o fundo e uma terceira (opcional) para um efeito de

sombra no texto, como em: "bmp-colors = 255,9,35;9,255,35" . Se não quiser usar a sombra, simplesmente omita o terceiro valor, como em: bmp-colors = 255,9,;9,255, Em seguida vem a parte mais importante, que é definir as coordenadas e o tamanho da caixa de seleção dos sistemas disponíveis, que será exibida sobre a imagem. Os dois primeiros valores indicam as coordenadas (x e y) e os dois valores seguintes indicam o número de colunas (geralmente apenas uma) e o número de linhas, que indica o número máximo de entradas que poderão ser usadas: bmp-table = 61,15,1,12 Finalmente, temos a posição do timer, que mostra o tempo disponível para escolher antes que seja inicializada a entrada padrão. A configuração do timer tem 5 valores, indicando as coordenadas x e y e as cores (texto, fundo e sombra). Novamente, o valor da sombra é opcional: bmp-timer = 73,29,255,9 Ao terminar, não se esqueça de salvar as alterações, regravando o Lilo. Aqui está um exemplo de tela de boot, usando estas configurações:

Configurando o grub Muitas distribuições permitem que você escolha entre usar o lilo ou o grub durante a instalação. Outras simplesmente usam um dos dois por padrão. De uma forma geral, o grub oferece mais opções que o lilo e inclui um utilitário, o update-grub que gera um arquivo de configuração básico automaticamente. Por outro lado, a sintaxe do arquivo de configuração do

grub é mais complexa o que o torna bem mais difícil de editar manualmente que o do lilo. O grub inclui ainda um prompt de comando, novamente nenhum exemplo de amigabilidade. De resto, os dois possuem a mesma e essencial função. Sem o gerenciador de boot o sistema simplesmente não dá boot :-). O grub usa o arquivo de configuração "/boot/grub/menu.lst". Este arquivo é lido a cada boot, por isso não é necessário reinstalar o grub ao fazer alterações, como no caso do lilo. Para entender melhor como o grub funciona, vamos a um exemplo de como instalá-lo no Kurumin, substituindo o lilo que é usado por padrão. Estes mesmos passos podem ser usados em outras distribuições derivadas do Debian, que utilizem o lilo. Em primeiro lugar, você precisa instalar o pacote do grub via apt-get. Ele não possui dependências externas, inclui apenas os executáveis principais. Você pode até mesmo arriscar compilar a versão mais recente, baixada no site do projeto. # apt-get install grub Depois de instalar, crie a pasta "/boot/grub/" e use o "update-grub" para gerar o arquivo "menu.lst". Basta responder "y" na pergunta e o arquivo é gerado automaticamente: # mkdir /boot/grub # update-grub

Testing for an existing GRUB menu.list file... Could not find /boot/grub/menu.lst file. Would you like /boot/grub/menu.lst generated for you? (y/N) y Searching for splash image... none found, skipping... Found kernel: /boot/vmlinuz-2.6.15 Found kernel: /boot/memtest86.bin Updating /boot/grub/menu.lst ... done Agora só falta instalar o grub na MBR usando o comando: # grub-install /dev/hda

Ao gravar o grub, ele naturalmente substitui o lilo ou qualquer outro gerenciador de boot que esteja sendo usado. Se você mudar de idéia mais tarde e quiser regravar o lilo, subscrevendo o grub, basta chamálo novamente: # lilo

Assim como no caso do lilo, o arquivo de configuração do grub inclui uma seção separada para cada sistema que aparece no menu de boot. O update-grub não é muito eficiente em detectar outros sistemas instalados, por isso, depois de gerar o arquivo você ainda precisará adicionar as linhas referentes a eles no final do arquivo "/boot/grub/menu.lst".

Para que o grub inicialize uma cópia do Windows, instalada na primeira partição, /dev/hda1, adicione as linhas: title Windows rootnoverify (hd0,0) chainloader +1 Elas equivalem à opção "other=/dev/hda1" que seria usada no arquivo do lilo. A linha "title" contém apenas a legenda que é mostrada no menu de boot. O que interessa mesmo é a linha rootnoverify (hd0,0), que indica o HD e a partição onde o outro sistema está instalado. O primeiro número indica o HD e o segundo a partição dentro deste. Na nomenclatura adotada pelo grub temos: /dev/hda = 0 /dev/hdb = 1 /dev/hdc = 2 /dev/hdd = 3 As partições dentro de cada HD são também nomeadas a partir do zero: /dev/hda1 = 0,0 /dev/hda2 = 0,1 /dev/hda3 = 0,2 /dev/hda4 = 0,3 /dev/hda5 = 0,4 /dev/hda6 = 0,5 etc... Se você quisesse que o grub iniciasse também uma instalação do Mandriva no /dev/hda3, cujo lilo (ou grub) foi instalado na partição, adicionaria as linhas: title Mandriva rootnoverify (hd0,2) chainloader +1 A linha "chainloader +1" especifica que o grub vai apenas chamar o gerenciador de boot instalado na partição e deixar que ele carregue o outro sistema, assim como fizemos ao editar o arquivo do lilo. No caso de outras distribuições Linux, instaladas no mesmo HD, você pode usar o grub para carregar diretamente o outro sistema, sem precisar passar pelo outro gerenciador de boot. Neste caso você usaria as linhas: title Mandriva root (hd0,2) kernel /boot/vmlinuz-2.6.8 root=/dev/hda3 ro savedefault boot

Veja que neste caso você precisa especificar a localização do executável do Kernel dentro da partição. Você pode especificar também opções para o Kernel e usar um arquivo initrd, se necessário, como neste segundo exemplo: title Mandriva root (hd0,2) kernel /boot/vmlinuz-2.6.8 root=/dev/hda3 ro vga=791 acpi=off splash=verbose initrd /boot/initrd.gz savedefault boot Assim como no caso do lilo, você pode usar um CD do Kurumin ou Knoppix para reinstalar o grub, caso ele seja subscrito por uma instalação do Windows ou outra distribuição Linux. Para isso, depois de dar boot pelo CD, você só precisa montar a partição onde o sistema está instalado, como em: # mount -t reiserfs /dev/hda2 /mnt/hda2 E usar o chroot para obter o prompt de comando do sistema que está recuperando: # chroot /mnt/hda2 No prompt, você precisa editar o arquivo "/boot/grub/menu.lst", ou gerá-lo novamente usando o comando "update-grub" e reinstalar o grub, usando o comando: # grub-install /dev/hda

Você pode também editar as opções básicas do grub usando o grubconf , um utilitário gráfico, disponível em várias distribuições e também via apt-get:

Configurando o vídeo: /etc/X11/xorg.conf  O suporte a vídeo no Linux é provido pelo X, que já vem com drivers para as placas suportadas. Além dos drivers open-source incluídos no X você pode instalar os drivers binários distribuídos pela nVidia e ATI. Como vimos no primeiro capítulo, existem duas versões do X em uso: o Xfree, o mais antigo e tradicional e o X.org, a versão mais usada atualmente. Antigamente, até a versão 3.x, o Xfree possuía várias versões separadas, com drivers para diferentes chipsets de vídeo. Isso complicava a configuração e obrigava as distribuições a manterem instaladas todas as diferentes versões simultaneamente, o que também desperdiçava muito espaço em disco. A partir do Xfree 4.0 e em todas as versões do X.org existe apenas uma única versão unificada, com drivers para todas as placas e recursos suportados. Melhor ainda, cada driver dá suporte a todas as placas de um determinado fabricante, o "sis" dá suporte a todas as placas da SiS, o "trident" dá suporte a todas as placas da Trident e assim por diante. Temos ainda dois drivers genéricos, o "vesa" e o "fbdev", que servem como um mínimo múltiplo comum, uma opção para fazer funcionar placas novas (ou muito antigas), que não sejam suportadas pelos drivers titulares. Outro detalhe interessante é que toda a configuração do vídeo, incluindo omouse e o suporte a 3D, é feita através de um único arquivo de configuração, o "/etc/X11/XF86Config-4" (nas

distribuições que usam o Xfree) ou "/etc/X11/xorg.conf" (nas que usam o X.org), que é relativamente simples de editar e funciona em todas as distribuições que utilizam o Xfree 4.0 em diante ou X.org (ou seja, praticamente todas as usadas atualmente). Isto significa que você pode pegar o arquivo de configuração gerado pelo Kurumin e usar no Slackware, por exemplo. Existem várias ferramentas de configuração que perguntam ou autodetectam a configuração e geram o arquivo, como o "mkxf86config" (do Knoppix) "kxconfig", "xf86cfg" entre outros. Mas, neste tópico vamos ver como configurar manualmente o arquivo, adaptando ou corrigindo as configurações geradas pelos configuradores. O arquivo é dividido em seções. Basicamente, temos (não necessariamente nesta ordem) uma seção "Server", com parâmetros gerais, a seção "Files" com a localização das fontes de tela e bibliotecas, duas seções "InputDevice", uma com a configuração do teclado e outra com a do mouse, uma seção "Monitor" e outra "Device", com a configuração do monitor e placa de vídeo e por último a seção "Screen" onde é dito qual resolução e profundidade de cor usar. A ordem com que estas configurações aparecem no arquivo pode mudar de distribuição para distribuição, mas a ordem não importa muito, desde que estejam todas lá. Como em outros arquivos de configuração, você pode incluir comentários, usando um "#" no início das linhas. Linhas em branco, espaços e tabs também são ignorados e podem ser usadas para melhorar a formatação do arquivo e melhorar a organização das informações. Vamos a uma descrição geral das opções disponíveis, usando como exemplo o modelo de configuração que uso no Kurumin. Abra o arquivo /etc/X11/xorg.conf ou /etc/X11/XF86config4 da sua máquina e acompanhe o exemplo; prestando atenção nas diferenças entre oexemplo e o arquivo da sua máquina e tentando entender a função de cada seção: Section "ServerLayout" Identifier "X.Org do Kurumin" Screen 0 "Screen0" 0 0 InputDevice "Keyboard0" "CoreKeyboard" InputDevice "USB Mouse" "CorePointer" EndSection Nesta seção vai a configuração geral. Ela é uma espécie de "índice" das seções abaixo. O campo "Identifier" pode conter qualquer texto, é apenas uma descrição. O "USB Mouse" indica o nome da seção que será usada. Abaixo deve existir uma seção com este mesmo nome, contendo a configuração do mouse propriamente dita. Esta organização permite que você (ou o utilitário de configuração usado) adicione várias configurações diferentes, onde você pode trocar rapidamente entre elas modificando esta linha. Nas distribuições que usam o Kernel 2.6, é possível usar a mesma configuração para mouses PS/2, mouses USB e também mouses touchpad (notebooks), pois todos utilizam um driver comum. É possível até mesmo usar dois mouses simultaneamente (o touchpad do notebook e um mouse USB externo, por exemplo), sem precisar alterar a configuração. Apenas os antigos mouses seriais ainda precisam de uma configuração própria.

O Kurumin usa um arquivo de configuração que vem com várias configurações de mouse prontas (as opções disponíveis são: "USB Mouse", "PS/2 Mouse" e "Serial Mouse"), mas apenas a informada nesta primeira seção é usada. Como disse, ao usar um mouse PS/2 ou USB, qualquer uma das duas entradas funcionará. Mas, caso você tenha ou pretenda usar um mouse serial, altere a configuração para: InputDevice "Serial Mouse" "CorePointer" Se seu micro tiver mais de um mouse conectado simultaneamente, você pode duplicar a configuração do mouse, como abaixo. Isso faz com que o X tente ativar ambos os mouses na inicialização, ativando apenas os que estiverem realmente presentes: Section "ServerLayout" Identifier "X.Org do Kurumin" Screen 0 "Screen0" 0 0 InputDevice "Keyboard0" "CoreKeyboard" InputDevice "USB Mouse" "CorePointer" InputDevice "Serial Mouse" "CorePointer" EndSection Na seção "ServerFlags" vão opções gerais. É aqui que colocamos, por exemplo, a opção que inicializa o Xinerama, que dá suporte a uma segunda placa de vídeo e monitor. Neste exemplo, está sendo usada apenas a opção "AllowMouseOpenFail" "true" que permite que o modo gráfico abra mesmo que o mouse esteja desconectado. Section "ServerFlags" Option "AllowMouseOpenFail" "true" EndSection Seria estúpido parar toda a abertura do modo gráfico e voltar para o modo texto porque o mouse não foi detectado, pois você ainda pode usar o mouse virtual do KDE como uma solução temporária até que consiga solucionar o problema. Para ativar o mouse virtual, pressione a tecla Shift junto com a tecla NumLock do teclado numérico. A partir daí as teclas 1, 2, 3, 4, 6, 7, 8 e 9 ficam responsáveis pela movimentação do mouse, enquanto a tecla 5 simula o clique do botão esquerdo (pressionando 5 duas vezes você simula um duplo clique). Para arrastar e soltar pressione a tecla 0 para prender e depois a tecla 5 para soltar. Para simular os outros botões você usa as teclas "/" (botão direito), "*" (botão central) e "-" (para voltar ao botão esquerdo), que funcionam como teclas modificadoras. Para desativar o mouse virtual, pressione "Shift + NumLock" novamente. Voltando ao arquivo de configuração, temos a seguir as seções " Files" e "Modules", que indicam respectivamente as pastas com as fontes TrueType, Type 1 e outras que serão usadas pelo sistema e os módulos de extensões do Xfree que serão usados. Section "Files" RgbPath "/usr/X11R6/lib/X11/rgb" ModulePath "/usr/X11R6/lib/modules"

FontPath "/usr/X11R6/lib/X11/fonts/misc:unscaled" FontPath "/usr/X11R6/lib/X11/fonts/misc" FontPath "/usr/X11R6/lib/X11/fonts/75dpi:unscaled" FontPath "/usr/X11R6/lib/X11/fonts/75dpi" FontPath "/usr/X11R6/lib/X11/fonts/100dpi:unscaled" FontPath "/usr/X11R6/lib/X11/fonts/100dpi" FontPath "/usr/X11R6/lib/X11/fonts/PEX" FontPath "/usr/X11R6/lib/X11/fonts/cyrillic" FontPath "/usr/share/fonts/truetype/openoffice" FontPath "/usr/X11R6/lib/X11/fonts/defoma/CID" FontPath "/usr/X11R6/lib/X11/fonts/defoma/TrueType" EndSection Section "Module" Load "ddc" Load "GLcore" Load "dbe" Load "dri" Load "extmod" Load "glx" Load "bitmap" Load "speedo" Load "type1" Load "freetype" Load "record" EndSection Estas duas seções geralmente não precisam ser alteradas, a menos que você instale algum novo conjunto de fontes TrueType e queira habilitá-lo manualmente ou caso instale um novo driver de vídeo (como o driver da nVidia) e o read-me diga para desativar algum dos módulos. Outra possibilidade é que você queira intencionalmente desativar algum recurso, ou tentar solucionar problemas. O módulo "dri", por exemplo, habilita o suporte a 3D para a placa de vídeo. As placas onboard com chipset Intel (i810, MGA 900, etc.), placas ATI Rage e ATI Radeon e as antigas Voodoo 2 e Voodoo 3 possuem suporte 3D nativo no X.org. Mas, ao instalar o driver 3D da nVidia você precisa remover esta opção, pois o driver do Xfree conflita com o que é instalado junto com o driver. Pode ser também que por algum motivo você queira desabilitar o 3D da sua i810 onboard (para evitar que fiquem jogando TuxRacer durante o expediente, por exemplo ;). Em qualquer um dos casos, você poderia comentar a linha "Load "dri". Em seguida vem a configuração do teclado. O "abnt2" indica o layout de teclado que será usado por padrão. No KDE e Gnome, o layout indicado aqui perde o efeito, pois eles possuem ferramentas próprias para configurar o teclado. No caso do KDE é usado o kxkb, que você configura na seção Regional & Acessibilidade do Kcontrol. Mas, esta configuração de teclado do X é útil para quem usa outras interfaces.

Estes são dois exemplos de configuração para (respectivamente) um teclado ABNT2 e um teclado US Internacional. Você só pode incluir uma das duas no arquivo: # Teclado ABNT2 Section "InputDevice" Identifier "Keyboard0" Driver "kbd" Option "CoreKeyboard" Option "XkbRules" "xorg" Option "XkbModel" "abnt2" Option "XkbLayout" "br" Option "XkbVariant" "abnt2" EndSection # Teclado US Internacional Section "InputDevice" Identifier "Keyboard0" Driver "kbd" Option "CoreKeyboard" Option "XkbRules" "xorg" Option "XkbModel" "pc105" Option "XkbLayout" "abnt2" EndSection Você deve lembrar que acima, na seção "ServerLayout" informamos que o X iria usar o "USB Mouse". Este é apenas um nome que indica a seção (com a configuração do mouse propriamente dita) que será usada. Isso permite que você tenha várias seções com configurações de mouses diferentes. Basta indicar a correta na seção de cima e as demais serão ignoradas. Estas são as seções com as configurações usadas no Kurumin. Dentro de cada seção vai a porta e driver usados pelo mouse e outras opções necessárias em cada caso. Você pode usá-las como modelos para configurar o mouse em outras distribuições: Section "InputDevice" Identifier "USB Mouse" Driver "mouse" Option "Protocol" "auto" Option "Device" "/dev/input/mice" Option "SendCoreEvents" "true" Option "ZAxisMapping" "4 5" Option "Buttons" "5" EndSection Section "InputDevice" Identifier "Serial Mouse" Driver "mouse"

Option "Protocol" "Microsoft" Option "Device" "/dev/ttyS0" Option "Emulate3Buttons" "true" Option "Emulate3Timeout" "70" Option "SendCoreEvents" "true" EndSection A linha "Option "ZAxisMapping" "4 5" ativa a rodinha do mouse, quando disponível. Do ponto de vista do sistema operacional, a rodinha é um conjunto de dois botões extras (botões 4 e 5) e os giros da roda correspondem a cliques nos botões extra. É seguro usar esta linha sempre, pois ela é ignorada ao usar um mouse sem a rodinha. O mais importante no caso é o protocolo usado. Com relação a mouses PS/2 e USB no Kernel 2.6, recomendo que use sempre a opção "Option "Protocol" "auto", que detecta corretamente o protocolo do mouse na grande maioria dos casos. Em casos específicos, onde o mouse não funcione corretamente, você pode substituir o "Option "Protocol" "auto" por "Option "Protocol" "IMPS/2", que é o protocolo padrão para mouses de três botões, com roda, ou "Option "Protocol" "PS/2", que é o protocolo para mouses PS/2 antigos, sem roda. No caso de mouses com 5 botões, com uma ou duas rodas, o protocolo usado muda para "ExplorerPS/2 e você precisa especificar a configuração dos botões extras. Para um mouse com 5 botões e uma roda, a seção fica: Section "InputDevice" Identifier "Mouse" Driver "mouse" Option "Protocol" "ExplorerPS/2" Option "ZAxisMapping" "4 5" Option "Buttons" "7" Option "Device" "/dev/input/mice" EndSection Se a função dos dois botões extra e da roda ficarem trocadas, substitua a linha "Option "ZAxisMapping" "4 5" por "Option "ZAxisMapping" "6 7". No caso dos mouses com duas rodas, a configuração fica: Section "InputDevice" Identifier "Mouse" Driver "mouse" Option "Protocol" "ExplorerPS/2" Option "ZAxisMapping" "6 7 8 9" Option "Buttons" "9" Option "Device" "/dev/input/mice" EndSection

Note que, ao usar o Kernel 2.6, não existe necessidade de especificar se o mouse é PS/2 ou USB, pois a porta "/dev/input/mice" é compartilhada por ambos. As versões atuais do Firefox e outros aplicativos atribuem funções para os botões extras automaticamente. Os dois botões laterais assumem as funções dos botões para avançar e voltar no Firefox, por exemplo. Continuando, temos a configuração do monitor e placa de vídeo, que afinal são os componentes mais importantes neste caso. Ela é dividida em três seções, com a configuração do monitor, da placa de vídeo e uma seção "screen" que, com base nas duas anteriores indica qual resolução e profundidade de cores será usada. A configuração do monitor precisa incluir apenas as taxas de varredura horizontal e vertical usadas por ele. Você pode encontrar estes dados no manual do monitor ou no site do fabricante. As opções Identifier, VendorName e ModelName são apenas descritivas, podem conter qualquer texto: Section "Monitor" Identifier "Monitor0" VendorName "GSM" ModelName "GSM3b60" HorizSync 30 - 63 VertRefresh 50 - 75 EndSection Se você não souber as taxas de varredura usadas pelo seu monitor e quiser alguma configuração genérica que funcione em qualquer monitor contemporâneo, experimente usar esta, que permite trabalhar a até 1024x768 com 60 Hz de atualização: Section "Monitor" Identifier "Meu Monitor" HorizSync 31.5 - 50.0 VertRefresh 40-90 EndSection Em geral, os configuradores incluem várias seções "Modeline" dentro da seção "Monitor", com as resoluções e taxas de atualização suportadas pelo monitor. Estes dados são fornecidos pelo próprio monitor, via DDC (uma espécie de plug-and-play para monitores) e não é necessário alterá-los a menos que você esteja escrevendo o arquivo manualmente do zero, o que não é muito aconselhável já que é sempre muito mais fácil usar um arquivo copiado de outro micro como base. Esta configuração dos modelines não é obrigatória no XFree 4.x ou X.org, pois o X é capaz de deduzir a configuração a partir das taxas de varredura do monitor, informadas dentro da seção. Eles são usados atualmente mais como uma forma de corrigir problemas. Este é um exemplo de configuração para um monitor de 17", incluindo modelines para usar 1280x1024, 1024x768 e 800x600. Note que cada seção "Modeline" ocupa uma única linha:

Section "Monitor" Identifier "Monitor0" VendorNam "GSM" ModelName "GSM3b60" HorizSync 30 - 63 VertRefresh 50 - 75 ModeLine "1280x1024" 135.00 1280 1296 1440 1688 1024 1025 1028 1066 +hsync +vsync ModeLine "1024x768" 78.75 1024 1040 1136 1312 768 769 772 800 +hsync +vsync ModeLine "800x600" 49.50 800 816 896 1056 600 601 604 625 +hsync +vsync EndSection Em seguida vem a seção "Device" que indica a configuração da placa de vídeo. As opções Identifier, VendorName e BoardName são apenas descrições, o que interessa mesmo é o Driver usado: Section "Device" Option "sw_cursor" Identifier "Card0" Driver "nv" VendorName "nVidia" BoardName "GeForce4 MX" EndSection Os drivers disponíveis são: - fbdev: Este driver usa o recurso de framebuffer suportado pelo Kernel como driver de vídeo.

Neste modo o Kernel manipula diretamente a memória da placa de vídeo, gravando as imagens que serão mostradas no monitor. O desempenho não é dos melhores e a utilização do processador é maior que nos outros drivers pois não existe aceleração de vídeo Mas, por outro lado, este é um driver que funciona com a maioria das placas de vídeo e é o único onde você não precisa se preocupar com a configuração das taxas de atualização do monitor. As placas usam sempre uma taxa de atualização baixa, de 56 ou 60 Hz, queé fixa. Ao usar o fbdev como driver de vídeo, a configuração da resolução não é feita no arquivo xorg.conf, mas no "/etc/lilo.conf " (pois o parâmetro é passado diretamente ao Kernel durante o boot), como vimos anteriormente. - i740: Usado pelas placas de vídeo (offboard) com chipset Intel i740. Estas placas foram uma

tentativa frustrada da Intel de entrar no ramo de placas 3D. O desempenho era fraco comparado com as placas da nVidia e ATI, mas o projeto acabou sendo usado como base para os chipsets de vídeo onboard que passaram a ser usados nos chipsets Intel. - i810: Este é o driver usado por todas as placas de vídeo onboard com chipset Intel. A lista de

compatibilidade inclui quase todos os chipsets para Pentium III, Pentium 4 e Pentium M, incluindo as placas com o chipset Intel 900 e Intel Extreme.

- nv: É o driver genérico para placas nVidia, que oferece apenas suporte 2D. Para ativar os

recursos 3D você precisa instalar os drivers da nVidia (veja mais detalhes no capítulo 3). - r128: Driver para as placas ATI Rage (a família anterior às ATI Radeon). Este driver oferece um

bom suporte 3D, permitindo que estas placas funcionem usando quase todo seu potencial 3D (que não é grande coisa hoje em dia, mas ainda permite rodar vários jogos). - radeon / ati: Este é o driver open-source para as placas ATI Radeon. Nas versões antigas do

Xfree e do X.org, o driver se chamava "radeon", mas ele passou a se chamar "ati" nas versões recentes do X.org (a partir do 6.8.2). Você pode verificar qual é a versão do X instalada, usando o comando "X -version". Para que a aceleração 3D funcione, é necessário que os módulos do Kernel que cuidam da comunicação de baixo nível com a placa de vídeo estejam carregados. Nem todas as distribuições carregam estes módulos automaticamente, mesmo ao detectar a placa corretamente. Se a aceleração 3D não estiver funcionando, apesar da configuração do X estar correta, adicione as linhas abaixo num dos arquivos de inicialização do sistema: modprobe agpgart modprobe ati-agp modprobe drm modprobe radeon Existe uma certa polêmica sobre utilizar o driver do X, ou utilizar o driver proprietário fornecido pela ATI que, embora não trabalhe em conjunto com algumas placas, oferece um desempenho 3D superior quando funciona. Veja mais detalhes sobre como instalá-lo no capítulo 3. - s3virge: Placas com chipset S3 Virge. Estas placas foram muito usadas por volta da época do

lançamento do Pentium MMX. - sis: Este é o driver que funciona em todas as placas da SiS suportadas. Caso você encontre

algum chipset novo, que não funcione com ele, experimente usar o driver vesa ou fbdev. Uma observação importante é que a SiS não desenvolve drivers 3D para o Linux e não divulga as especificações técnicas que permitiriam o desenvolvimento de drivers 3D por parte da comunidade. Atualmente as placas de vídeo e chipsets da SiS são os com pior suporte no Linux por causa da falta de cooperação do fabricante e devem ser evitadas na hora da compra. O driver oferece apenas suporte 2D, as placas funcionam mas não servem para rodar jogos 3D ou trabalhar com aplicativos 3D profissionais, por exemplo. Até o Xfree 4.0 existia um esforço para desenvolver suporte 3D, mas o fabricante divulgava tão pouca informação e os chipsets possuíam tantos problemas (o que pode ser percebido pela relativainstabilidade dos próprios drivers for Windows) que o projeto acabou sendo levado adiante por um único desenvolvedor. Você pode obter mais informações sobre o status do driver (2D) no: http://www.winischhofer.at/linuxsisvga.shtml

O X.org inclui um driver 3D precário, que oferece suporte limitado às placas com chipset SiS 300, 305, 630 e 730, porém não inclui suporte aos demais modelos. Entre as placas onboard, as com melhor suporte no Linux são as placas Intel, suportadas pelo driver i810. - tdfx: Driver para as placas da 3Dfx, as famosas Voodoo, que fizeram muito sucesso a até meia

década atrás. Este driver oferece suporte 3D para as placas Voodoo 2 e Voodoo 3. - trident: Placas de vídeo da Trident. Ele funciona bem com placas Trident Blade e os novos

chipsets usados em notebooks, mas o suporte às antigas 9440 e 9680 é ruim e em muitos casos elas funcionam a apenas 640x480. Pensando nestas placas, algumas distribuições, como o Mandriva oferecem a opção de usar o driver do antigo Xfree 3.3, que oferecia um suporte mais completo a elas. Apesar de brutalmente ultrapassadas, as Trident 9440 e 9680 foram as mais vendidas durante a maior parte da década de 1990 e por isso ainda são usadas em muitos micros antigos. - vesa: Este é o "curinga", um driver genérico que utiliza apenas as extensões do padrão vesa

que em teoria é suportado por todas as placas de vídeo PCI e também pelas antigas placas VLB. Algumas placas antigas, como as Trident 9680 não funcionam com ele, mas são exceções. Como este driver não suporta aceleração, você notará que o desempenho em algumas tarefas ficará abaixo do normal. É normal também que os vídeos assistidos no Kaffeine ou Xine fiquem granulados ao serem exibidos em tela cheia. Outra limitação é que a resolução, na maioria das placas, fica limitada a 1024x768. - via: Este é o driver que dá suporte ao chipset Via Unicrome, usado como vídeo onboard na

maior parte das placas-mãe atuais com chipset Via. Originalmente, este driver era apenas 2D, como o nv e o sis, mas a partir de abril de 2005 a Via passou a publicar um driver 3D opensource, que pode ser encontrado nas versões recentes do X.org. Para que a aceleração 3D oferecida por ele funcione, é necessário que os módulos "via-agp" e "via" estejam carregados. Adicione as linhas abaixo num dos arquivos de inicialização do sistema: modprobe via-agp modprobe via - savage: Este driver dá suporte às placas S3 Savage e Pro Savage, relativamente populares a

alguns anos atrás. Ele inclui aceleração 3D caso você esteja utilizando uma versão recente do X.org (a partir do 6.8.2), em conjunto com o pacote "libgl1-mesa-dri" (que inclui os drivers 3D desenvolvidos pelo projeto Mesa GL). Outros drivers, pouco usados são: - cirrus: A Cirrus Logic fabricou alguns modelos de placas de vídeo PCI, concorrentes das

Trident 9440 e 9680. Elas são encontradas apenas em micros antigos. - cyrix: Placas com o chipset Cyrix MediaGX, também raros atualmente. - chips: Placas da "Chips and Technologies", um fabricante pouco conhecido.

- glint: Esta é uma família de placas antigas lançada pela 3D Labs.

- neomagic: Placas com chipset Neomagic, usadas em alguns notebooks antigos. - rendition: Placas Rendition Verite, da Micron. - tseng: Placas da Tseng Labs, outro fabricante pouco conhecido. - vga: Este é um driver VGA genérico que trabalha 640x480 com 16 cores. Serve como um "fail

safe" que funciona em todas as placas. Cada um destes drivers oferece algumas opções de configuração que podem ser usadas em casos de problemas ou por quem quiser fuçar na configuração. Você pode encontrar mais informações sobre cada um no: http://www.xfree86.org/4.4.0/. Finalmente, vai a configuração da seção "Screen", que indica a resolução que será usada. As várias seções determinam as resoluções disponíveis para cada configuração de profundidade de cor, enquanto a opção "DefaultColorDepth" determina qual será usada: Section "Screen" Identifier "Screen0" Device "Card0" Monitor "Monitor0" DefaultColorDepth 24

SubSection "Display" Depth 8 Modes "1024x768" "800x600" "640x480" EndSubSection SubSection "Display" Depth 16 Modes "1024x768" "800x600" "640x480" EndSubSection SubSection "Display" Depth 24 Modes "1024x768" "800x600" "640x480"

EndSubSection EndSection Neste exemplo o vídeo está configurado para usar 24 bits de cor. Se você quisesse usar 16 bits, bastaria mudar o número na opção "DefaultColorDepth". Dentro de cada uma das três seções (Depth 8, Depth 16 e Depth 24), vai a resolução que será usada para cada uma. Na linha que começa com "Modes" vão as resoluções de tela. A primeira da lista (1024x768 no exemplo) é a default. As outras duas, 800x600 e 640x480 são usadas apenas se a primeira falhar (se a placa de vídeo ou monitor não a suportarem) ou se você alternar manualmente entre as resoluções, pressionando "Ctrl Alt +" ou "Ctrl Alt -" .

Sempre que você fizer alterações no arquivo e quiser testar a configuração, reinicie o X pressionando "Ctrl+Alt+Backspace". Não é preciso reiniciar o micro.

KVM via software com o Synergy Um KVM é um adaptador que permite ligar dois ou mais micros no mesmo teclado, mouse e monitor. Você pode chavear entre eles pressionando uma combinação de teclas, como "Scroll Lock, Scroll Lock, seta pra cima", o que passa não apenas o controle do mouse e teclado, mas troca também a imagem mostrada no monitor. O Synergy permite fazer algo semelhante via software, "anexando" telas de outros micros, de forma a usar todos simultaneamente, com um único teclado e mouse. Imagine que você tem um desktop e um notebook, onde o notebook fica na mesa bem ao lado do monitor do desktop e você precisa se contorcer todo quando precisa fazer alguma coisa no notebook. Usando o Synergy você pode anexar a tela do notebook ao seu desktop, fazendo com que ao mover o mouse para a direita (ou esquerda, de acordo com a configuração) ele mude automaticamente para a tela do notebook. Junto com o mouse, muda o foco do teclado e até mesmo a área de transferência é unificada, permitindo que você copie texto de um micro para o outro. Tudo é feito via rede, com uma baixa utilização do processador e um excelente desempenho. No Linux, o Synergy pode tanto ser configurado manualmente, através do arquivo ".synergy.conf" (dentro do seu diretório de usuário), ou do arquivo "/etc/synergy.conf" (que vale para todos os usuários do sistema), quanto através do Quicksynergy, um configurador gráfico. Vamos começar aprendendo como fazer a configuração manualmente. O primeiro passo é, naturalmente, instalar o Synergy nas duas máquinas. Ele é um programa comum, incluído em muitas distribuições. Nos derivados do Debian, instale-o via apt-get: # apt-get install synergy

Caso você não encontre um pacote para a sua distribuição, você pode baixar um pacote .rpm genérico, ou mesmo o pacote com o código fonte no: http://synergy2.sourceforge.net/. Imagine que você quer controlar o notebook a partir do desktop e que o desktop está à esquerda e o notebook à direita. O nome do desktop na rede é "semprao" e o nome do notebook é "kurumin", onde o endereço IP do desktop é "192.168.0.10" e o do notebook é "192.168.0.48". Desktop Notebook

nome: semprao kurumin ip: 192.168.0.10 192.168.0.48 posição: à esquerda à direita Estas informações precisam ser especificadas no arquivo de configuração, ".synergy.conf" ou "/etc/synergy.conf". Ele é um arquivo simples com três seções, onde são especificados os nomes das máquinas (conforme definido na configuração da rede, ou no arquivo

"/etc/hostname" e "/etc/hosts"), a posição de cada uma e os respectivos endereços IP. Em caso de dúvida sobre o nome de cada máquina, cheque com o comando "hostname". Este arquivo é criado no PC que controlará os outros, o desktop no nosso caso. No nosso exemplo o arquivo ficaria: section: screens semprao: kurumin: end section: links semprao: right = kurumin kurumin: left = semprao end section: aliases kurumin: 192.168.0.48 end Note que usei tabs para formatar o arquivo de forma que ele ficasse mais organizado, mas elas não influenciam a configuração. Como em outros arquivos, você pode usar tabs, espaços e quebras de linha extras para formatar o arquivo da maneira que quiser. Use este arquivo como exemplo, alterando apenas os nomes e endereços IP dos micros. Na seção "screens", vão os nomes das duas máquinas e na seção "links" é especificado quem fica à direita e quem fica à esquerda. No caso estou dizendo que o kurumin está à direita do semprao e vice-versa. Finalmente, na seção "aliases" você relaciona o nome da máquina que será acessada a seu endereço IP. Com o arquivo criado nas duas máquinas, falta apenas efetuar a conexão. Uma particularidade do Synergy é que o micro principal (o desktop no nosso exemplo) é o servidor, enquanto o micro que vai ser controlado por ele (o notebook) é o cliente. É por isso que a configuração é feita no desktop e não no notebook. Para ativar o "servidor" Synergy no desktop, permitindo que o notebook se conecte a ele, usamos o comando: $ synergys -f 

Para que o notebook se conecte e seja controlado por ele, usamos o comando: $ synergyc -f 192.168.0.10 ...onde o 192.168.0.10 é o endereço IP do desktop. Ambos os comandos devem ser sempre

executados usando seu login de usuário, não como root.

Se o notebook estiver em outra posição, à esquerda, acima ou abaixo da tela principal, use os parâmetros "left =", "up =" e "down =" na configuração. É possível ainda conectar dois ou mais micros simultaneamente, especificando a posição de cada um na configuração. Se, por exemplo, além do notebook à direita, tivermos um segundo desktop chamado "fedora" com o IP "192.168.0.21" à esquerda, o arquivo de configuração ficaria: section: screens semprao: kurumin: fedora: end section: links semprao: right = kurumin left = fedora kurumin: left = semprao fedora: right = semprao end section: aliases kurumin: 192.168.0.48 fedora: 192.168.0.21 end Originalmente, o rastro do mouse muda de uma tela para a outra simplesmente por chegar ao canto da tela. Isso pode ser um pouco desagradável em muitas situações, pois é justamente nos cantos da tela que ficam as barras de rolagem, bordas e botões da janela. A resposta para o problema é a opção "switchDelay", que permite especificar um tempo de espera em milessegundos antes do mouse mudar para outra tela. Ele evita transições involuntárias, pois você precisa realmente manter o mouse no canto da tela por uma fração de segundo para mudá-lo para a outra tela. Para usar a opção inclua-a no final do arquivo, como em: section: options switchDelay = 250 end Como pode ver, ela vai dentro de uma nova seção a "options", que não incluímos antes no arquivo por que não tínhamos nada a declarar. O "250" é o tempo em milessegundos que o synergy espera antes de fazer a transição de telas, em milessegundos. Este é o valor que eu considero mais confortável, mas você pode testar intervalos maiores ou menores até achar o ideal para você.

Outra configuração útil é a heartbeat que faz com que seu micro detecte a desconexão dos outros micros configurados (quando eles forem desligados, por exemplo), desativando o uso das telas virtuais até que eles se reconectem. Ela pode ser incluída dentro da seção "options",  junto com a switchDelay (o 5000 indica o tempo entre as verificações, no caso 5 segundos): section: options switchDelay = 250 heartbeat = 5000 end Mais uma opção útil é a "switchCorners", que faz com que o Synergy trave os cantos da tela, permitindo que você clique no botão iniciar, nos botões de fechar e redimensionar janelas e outras funções sem mudar para as telas adjacentes. Ao usar esta opção, o chaveamento é feito apenas pelo espaço central da tela, o que torna o sistema bem mais confortável. Para usar a opção, adicione as linhas abaixo dentro da seção "options", logo abaixo da linha "heartbeat = 5000": switchCorners = all switchCornerSize = 50 O "50"indica o tamanho (em pixels) da área que será considerada como canto pelo Synergy. No caso estou reservando os 50 pixels superiores e inferiores. Outra opção útil, sobretudo ao usar três telas dispostas horizontalmente, é utilizar teclas de atalho para chavear entre elas. Para isso, você pode utilizar a opção "keystroke", especificando uma sequência de atalho e o nome da tela para a qual irá o cursor, como em: keystroke(Alt+Z) = switchToScreen(hp) keystroke(Alt+X) = switchToScreen(semprao) keystroke(Alt+C) = switchToScreen(m5) Concluindo, ao usar um firewall no "servidor", mantenha aberta a porta "24800", usada pelo Synergy. Se você começar a usar o Synergy regularmente, a melhor forma de simplificar o processo é criar dois ícones no desktop do KDE (um no desktop, outro no notebook), que executam os comandos para estabelescer o link. Outra opção, é colocar o ícone com o comando na pasta ".kde/Autostart" (dentro do seu diretório home) de cada um, assim o Synergy passa a ser ativado automaticamente durante o boot.

Depois de feita a conexão, experimente passear com o mouse entre os dois desktops e abrir programas. Você pode também colar texto e até mesmo imagens de um desktop para o outro, usando o Ctrl+C, Ctrl+V, ou usando o botão do meio do mouse. Para transferir arquivos, você pode usar o SSH, ou criar um compartilhamento de rede, usando o NFS ou o Samba. Uma das vantagens do Synergy é que ele é multiplataforma. Na página de download você encontra também uma versão Windows, que pode ser usada em conjunto com a versão Linux. Você pode controlar uma máquina Windows a partir de um desktop Linux e vice-versa. A versão Windows apresenta inclusive uma vantagem, que é o fato de ser configurada através de uma interface gráfica, ao invés do arquivo de configuração. Uma opção de interface gráfica para a versão Linux é o Q uicksynergy, que você pode baixar no: http://quicksynergy.sourceforge.net/. O principal problema com o Quicksynergy é que, apesar de ser um programa bastante simples, ele está disponível apenas em código fonte e tem uma longa lista de dependências. Isso faz com que você acabe tendo que baixar 30 MB de compiladores e bibliotecas para instalar um programa de 500 KB. Se estiver disposto a encarar a encrenca, use o comando abaixo para baixar tudo via apt-get (Debian Etch). Note que os nomes dos pacotes podem mudar sutilmente em outras distribuições: # apt-get install automake gcc g++ ibglade2-dev libgt k2.0-dev libgnomeui-dev

Com as dependências satisfeitas, você pode compilar e instalar o Quicksynergy descompactando o pacote baixado, acessando a pasta criada e rodando os comandos "./configure", "make" e "make install", este último como root, como em: $ tar -zxvf quic ksynergy_0.1.tar.gz $ cd quic ksynergy-0.1/ $ ./configure $ make

$ su   

¡  

#

k inst ll   

¢

¡  

¡  

O Quic sy e y possui duas abas uma para fazer a configuraç o no servidor e outra para se conectar a e e a partir do c iente £  

¦  

¤  

¥ 

§ 

© 

© 

¨  

§ 

Note que a aba com a configuraç o do servidor permite especificar apenas os nomes dos c ientes não seus endereços IP. Para que e e funcione você deve configurar o arquivo "/etc/hosts" (no servidor), cadastrando os endereços e nomes de cada c iente. Esse arquivo possui uma sintaxe bem simples, contendo o nome e IP de cada máquina, uma por linha, como em: ¨  

 

 

© 

© 

© 

127.0.0.1 semprao localhost 192.168.0.48 kurumin 192.168.0.21 f edora Outra opção é usar o Kurumin-Synergy, a interface que desenvolvi para uso no Kurumin. Ele é um painel desenvolvido no Kommander, por isso pode ser executado diretamente através do "kmdr-executor", sem precisar ser compilado. Ele está incluído no Kurumin, a partir do 5.1 (Iniciar > Redes e acesso remoto > Acesso Remoto) e você pode também baixá-lo no: http://www.hardware.com.br/kurumin/painel/kurumin-synergy.kmdr Para executar, você precisa ter o pacote "kommander" instalado. Execute-o usando o comando: $k d - x   

¢   

 

  

uto ku u in-s n   

  

 

 

¢   

   

 

  

 

k d ¢   

 

A interface é bem similar à do Quicksynergy, com uma aba para ativar o servidor e outra para conectar os clientes. As dif erenças são que ele permite especificar diretamente os endereços

IP dos clientes (sem precisar editar o "/etc/hosts") e que ele oferece a opção de criar um ícone no desktop para reativar a conexão de forma rápida depois. Lembre-se de que ele é apenas a interface. De qualquer forma, você precisa ter o pacote "synergy" instalado. Ao estabelecer a conexão, é aberta uma janela de terminal, onde você pode acompanhar as mensagens. Para fechar a conexão, pressione "Ctrl+C" no terminal.

No capítulo sobre shell script, veremos passo a passo como este script do Kurumin Synergy foi desenvolvido, permitindo que você inclua melhorias ou desenvolva seus próprios scripts.

Usando o hdparm O hdparm é um utilitário muito usado, que permite ativar otimizações para o HD. Não se trata necessariamente de um utilitário para "turbinar" o seu sistema, mas para descobrir e corrigir problemas na configuração do HD, que podem comprometer o desempenho. Logue-se como root e rode o comando: # hdparm -c -d /dev/hda (substituindo o /dev/hda pela localização correta caso o HD esteja em outra posição) Você receberá um relatório como o abaixo:

/dev/hda: IO_support = 0 (default 16-bit) using_dma = 0 (off) Este é o pior caso possível. Veja que tanto o acesso de 32 bits quanto o DMA do HD estão desativados. Você pode atestar isso através do comando: # hdparm -t /dev/hda O relatório mostra a velocidade de leitura do HD. Neste caso temos um HD Fujitsu de 4.3 GB, um HD extremamente antigo. Mesmo assim, a velocidade de leitura está bem abaixo do normal, apenas 2.72 MB/s, o que beira o ridículo: /dev/hda: Timing buffered disk reads: 64 MB in 23.57 seconds = 2.72 MB/sec Podemos melhorar isto ativando os dois recursos, o que pode ser feito através do comando: # hdparm -c 1 -d 1 /dev/hda Algumas placas-mãe antigas, de Pentium 1 ou 486 podem não suportar o modo DMA, mas quase todas suportarão pelo menos o acesso de 32 bits. Naturalmente em qualquer equipamento mais atual ambos os recursos devem estar obrigatoriamente habilitados. Rodando novamente o comando "hdparm -t /dev/hda" vemos que a velocidade de acesso melhorou bastante: /dev/hda: Timing buffered disk reads: 64 MB in 10.76 seconds = 5.96 MB/sec Para que a alteração torne-se definitiva, edite o arquivo "/etc/rc.d/rc.local", adicionando a linha: hdparm -c 1 -d 1 /dev/hda Isto fará com que a configuração seja ativada a cada reboot. Nas distribuições derivadas Debian, você pode adicionar o comando no arquivo "/etc/init.d/bootmisc.sh", já que ele não utiliza o arquivo "rc.local".

Muitos tutoriais adicionam também a opção "-k 1" no comando. Ela faz com que a configuração seja mantida em casos de erros, onde a controladora do HD realiza um soft reset. Isto ocorre em casos de erros de leitura em setores do HD e outros problemas relativamente graves. Sem o "-k 1", estes erros fazem com que o DMA seja desativado. Eu particularmente prefiro esta configuração (sem o -k 1), pois serve como uma espécie de "alarme". Um erro ocorre, o DMA é desativado e, pela lentidão do sistema, você percebe que algo está errado. Usando o comando "dmesg" você pode verificar o que ocorreu e decidir se é o casode atualizar os backups ou trocar de HD.

Naturalmente, os resultados não serão tão animadores nos casos em que a distribuição se encarrega de detectar e ativar os recursos durante a instalação, mas não deixa de valer a pena sempre verificar se está tudo ok. Versões antigas do Red Hat usavam uma configuração bem conservadora, o que fazia com que o ultra DMA ficasse desativado em muitas placas, onde ele funciona perfeitamente ao ser ativado manualmente. Caso o hdparm não esteja instalado, use o comando "urpmi hdparm" (no Mandriva), "apt-get install hdparm" (Debian e derivados) ou procure pelo pacote nos CDs da distribuição em uso. Ele é um utilitário padrão do sistema. Na grande maioria dos casos, simplesmente ativar o DMA e modo de transferência de 32 bits  já fazem com que o HD trabalhe de forma otimizada, pois o hdparm detecta as configurações suportadas pela controladora. Mas, em alguns casos, você pode conseguir pequenos ganhos ajustando o modo Ultra DMA usado pelo HD. Neste caso, use os parâmetros "-X66" (UDMA 33), "-X68" (UDMA 66) ou "-X69" (UDMA 100), como em: # hdparm -X69 /dev/hda

Esta opção deve ser usada apenas em conjunto com HDs IDE, nunca com os HDs serial ATA, que já operam nativamente a 150, 300 ou 600 MB/s. Ao tentar forçar um modo de transferência não suportado pelo seu drive, você recebe uma mensagem de erro, como em: # hdparm -X70 /dev/hda

/dev/hda: setting xfermode to 70 (UltraDMA mode6) HDIO_DRIVE_CMD(setxfermode) failed: Input/output error Nestes casos, o padrão do hdparm é voltar à configuração anterior para evitar perda de dados. Mas, em alguns poucos casos, forçar um modo não suportado pode realmente corromper os dados do HD, por isso uso este recurso com cautela. Você pode verificar os modos suportados pelo seu drive usando o comando "hdparm -i drive ", na linha "UDMA Modes:", como em: # hdparm -i /dev/hda

/dev/hda: Model=IC25N080ATMR04-0, FwRev=MO4OAD4A, SerialNo=MRG40FK4JP27HH Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs } RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4 BuffType=DualPortCache, BuffSize=7884kB, MaxMultSect=16, MultSect=16 CurCHS=17475/15/63, CurSects=16513875, LBA=yes, LBAsects=156301488 IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}

PIO modes: pio0 pio1 pio2 pio3 pio4 DMA modes: mdma0 mdma1 mdma2 UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5

AdvancedPM=yes: mode=0x80 (128) WriteCache=enabled Drive conforms to: ATA/ATAPI-6 T13 1410D revision 3a: * signifies the current active mode Com relação ao gerenciamento de energia, você pode ajustar o tempo de espera, ou seja, o tempo de inatividade que o sistema espera antes de colocar o HD em modo de economia de energia usando a opção "-S" seguida por um número que vai de 1 a 255. Esta opção uma notação peculiar, onde os números de 1 a 240 indicammúltiplos de 5 segundos (1 para 5 segundos, 10 para 50 segundos e 240 para 20 minutos) e os números de 241 em diante indicam múltiplos de 30 minutos (242 indica uma hora, 244 duas horas, e assim por diante). Para um tempo de espera de 10 minutos, por exemplo, use: # hdparm -S 120 /dev/hda

Está disponível também a opção "-y", que faz o drive entrar em modo de economia de energia imediatamente. Uma opção menos conhecida, mas que é bastante útil em alguns HDs é o gerenciamento acústico que, quando suportado pelo HD, permite escolher entre um modo de funcionamento "silencioso", onde o HD gira a uma velocidade mais baixa, produz menos barulho e consome menos energia, ou um modo "barulhento", onde ele simplesmente funciona com o melhor desempenho possível. Esta opção é definida usando o parâmetro "-M", seguido de um número entre 128 e 254, onde 128 é o modo silencioso e o 254 é o modo barulhento. Alguns HDs suportam números intermediários, que permitem escolher a melhor relação performance/barulho. Para descobrir quais os valores suportados pelo seu dive, use o comando "hdparm -I" (i maiúsculo), como em: # hdparm -I /dev/hda | grep acoustic

Recommended acoustic management value: 128, current value: 254 Para alterar a configuração, indique o valor desejado, como em: # hdparm -M128 /dev/hda

Lembre-se de que apenas alguns HDs suportam efetivamente este recurso. Nos demais modelos, a configuração não altera nada. O hdparm pode ser usado também para limitar a velocidade do CD-ROM, o que pode ser útil em drives muito barulhentos, ou em notebooks, onde você queira economizar energia. Para isso, use o parâmetro "-B", seguido da velocidade e o drive, como em: # hdparm -E 8 /dev/hdc

Todas as configurações do hdparm não são persistentes. Por isso, lembre-se de incluir os comandos em algum dos arquivos de inicialização, para que sejam executados durante o boot.

Recompilando o Kernel O Kernel é o coração do sistema, o Linux em si. Todos os demais programas, incluindo até mesmo o bash, o programa que controla o prompt de comando são softwares que rodam sobre o Kernel. É ele quem cria a ponte entre os programas e o hardware. O Kernel inclui todos os drivers de dispositivos suportados pelo sistema e até mesmo alguns programas, como o Iptables, o firewall nativo do Linux a partir do Kernel 2.4. Mesmo alguns programas "externos" como o VMware e o Qemu (com o módulo Kqemu) utilizam um módulo no Kernel para ter acesso direto ao hardware e assim rodar com um melhor desempenho. Para manter a compatibilidade com o maior número possível de dispositivos, as distribuições devem incluir também quase todos os drivers de dispositivos disponíveis para o Linux. Para evitar que isto torne o Kernel muito grande, criam um Kernel básico, com os drivers mais importantes e incluem os demais drivers como módulos. Durante a instalação, ou a rodar algum utilitário de detecção e configuração de hardware, apenas os módulos necessários são carregados. Os módulos oferecem mais uma vantagem: podem ser carregados e descarregados conforme necessário, sem ficarem o tempo todo consumindo memória RAM e recursos do sistema. Uma distribuição típica, com o Kernel 2.6, inclui uma pasta de módulos com cerca de 50 MB, com pouco mais de mil módulos diferentes. Mas, em geral, apenas 15 ou 20 deles ficam carregados durante o uso. Recompilar o Kernel lhe dá a chance de criar um Kernel adaptado às suas necessidades, ao contrário do tamanho único incluído nas distribuições. Você vai precisar recompilar o Kernel caso precise adicionar o suporte a algum dispositivo, cujo driver só está disponível na versão mais recente. USB 2.0? Wireless? Bluetooth? Estas tecnologias já eram suportadas pelo Linux bem antes dos primeiros produtos chegarem ao mercado, mas quem possui uma versão antiga do Kernel precisa atualizá-lo para adicionar o suporte. É possível adicionar também patches com recursos experimentais, ainda não incluídos no Kernel oficial, incluindo novos drivers, suporte a novos sistemas de arquivos (como o suporte ao módulo Cloop ou UnionFS) ou melhorias de desempenho. Felizmente, atualizar ou personalizar o Kernel é uma tarefa relativamente simples, que pode se tornar até corriqueira, já que numa máquina atual, um Athlon de 2.0 GHz por exemplo, a compilação do executável principal de um Kernel da série 2.6 demora por volta de 5 minutos. Em seguida vem a compilação dos módulos, que é bem mais demorada mas não é necessária ao fazer apenas pequenas modificações no Kernel atualmente em uso. O processo todo pode ser dividido nos seguintes passos: 1- Baixar o código fonte da versão escolhida. 2- Aplicar patches (opcional).

3- Configurar as opções desejadas, ativando ou desativando componentes e opções, o que é feito através dos comandos "make xconfig" ou "make menuconfig". 4- Compilar o executável principal do Kernel (o arquivo vmlinuz, que vai na pasta boot). 5- Compilar os módulos. 6- Instalar o novo Kernel, os módulos e configurar o lilo ou grub para utilizá-lo. É possível manter vários Kernels instalados na mesma distribuição e escolher entre eles na hora do boot. Assim você pode manter o Kernel antigo instalado e voltar para ele em caso de problemas com o novo. Você pode encontrar detalhes sobre as atualizações e mudanças incluídas em cada versão do Kernel no: http://wiki.kernelnewbies.org/LinuxChanges. Baixando os fontes

O primeiro passo é naturalmente obter o código fonte do Kernel, que iremos compilar. Se você quer apenas criar um Kernel personalizado, pode usar como base o código fonte do próprio Kernel incluído na sua distribuição. Durante a instalação, quase sempre existe a opção de instalar o código fonte do Kernel (o pacote kernel-source) e os compiladores. Você pode também instalá-los posteriormente. No Mandriva, por exemplo, use o comando: # urpmi kernel-source No Debian, existem várias versões diferentes do Kernel disponíveis no apt-get. Você deve primeiro checar a versão em uso, usando o comando "uname -a", e em seguida instalar o pacote correto, como em: # apt-get install kernel-source-2.6.15

No Kurumin, Kanotix e em algumas outras distribuições, está disponível o script "install-kernelsource-vanilla.sh", desenvolvido pelo Kano, que se encarrega de baixar os fontes do Kernel atual, junto com um conjunto de patches úteis. É sempre muito mais fácil usar como base o fonte e configuração do Kernel que está instalado na sua máquina, com todos os patches e modificações. Assim você começa com uma configuração que está funcionando e faz apenas as alterações desejadas, com uma possibilidade muito menor de surgirem problemas. Depois de pegar um pouco de prática, você pode se aventurar a baixar uma versão "crua" da última versão do Kernel no http://www.kernel.org e fazer uma experiência começando do zero. Salve o arquivo no diretório "/usr/src/" onde por padrão ficam armazenados os fontes do Kernel. Não se assuste, o arquivo com o fonte do Kernel é mesmo grande, quase 50 MB (compactado em .tar.gz) nas versões recentes. Depois de baixar o pacote, você ainda precisará descompactá-lo, usando o comando:

# tar -zxvf linux-2.6.x.tar.gz Se o arquivo tiver a extensão tar.bz2, então o comando fica: # tar -jxvf linux-2.6.x.tar.bz2 Aproveite que está aqui para criar o link "linux", que deve apontar para a localização da pasta com o código fonte do novo Kernel: # ln -sf linux-2.6.x linux Em geral, ao instalar o pacote "kernel-source" incluído na distribuição, será apenas copiado o arquivo compactado para dentro da pasta "/usr/src/". Você ainda precisará descompactar e criar o link "/usr/src/linux", como ao baixar manualmente. Na verdade o link "/usr/src/linux" é apenas uma localização padrão, usada por muitas ferramentas, assim como um discador de internet vai sempre, por padrão, tentar acessar o modem usando o device "/dev/modem". De qualquer forma, todo o trabalho de compilação será feito dentro da pasta com o fonte do Kernel, como em: /usr/src/linux-2.6.15/. Configurando

Acesse o diretório "/usr/src/" e, dentro dele, a pasta onde está a versão do Kernel que será recompilada, como em: # cd /usr/src/2.6.x/ Usado o ls, você vai ver as várias pastas e arquivos que formam o código do Kernel. Se você quer realmente aprender a programar em C, vai aprender bastante examinando o código. Comece pela pasta "Documentation/", que contém muitas informações úteis sobre os componentes e módulos. Um bom livro (em Inglês) para quem quer entender melhor o funcionamento interno do Kernel é o Understanding the Linux Kernel, 3rd Edition , da ed. O'Reilly. Outra boa referência é o Linux Device Drivers, 3rd Edition, também da ed. O'Reilly, voltado para o desenvolvimento de drivers. Com o código em mãos, o próximo passo é definir os componentes que serão incluídos no novo Kernel, usando o xconfig (gráfico) ou menuconfig (texto), duas opções de ferramentas de configuração. O objetivo destas duas ferramentas é apenas ajudar a selecionar as opções disponíveis e gerar um arquivo de texto, o ".config", que será usado durante a compilação. Como todo arquivo de texto, ele pode ser até mesmo editado manualmente, mas isto não é muito prático num arquivo com quase 3.000 linhas :-). Mãos à obra então: # make xconfig

No Kernel 2.6 o "make xconfig" chama o Qconf, um utilitário bem mais amigável, criado usando a biblioteca QT. Para usá-lo, é necessário ter instalada a biblioteca de desenvolvimento do QT. No Debian Etch, instale o pacote "libqt3-mt-dev": # apt-get install libqt3-mt-dev

Caso necessário, instale o pacote a partir do Unstable. É comum que ele fique quebrado durante as atualizações do KDE. Se estiver usando alguma distribuição baseada no antigo Debian Sarge, use o pacote "libqt3-dev". No Kernel 2.4 o mesmo comando chama um utilitário bem mais simples, baseado na biblioteca tk:

Em qualquer um dos casos, ao recompilar o Kernel incluído na distribuição, o primeiro passo é carregar o arquivo .config com a configuração atual do Kernel. Isso evita muitos problemas,

pois você começa com o Kernel configurado com exatamente as mesmas opções atualmente em uso. Fica mais fácil localizar e corrigir problemas assim, pois você precisa se preocupar apenas com as opções que alterou. Por padrão, o arquivo com a configuração do Kernel vai sempre na pasta /boot, como em: "/boot/config-2.6.8.14-kanotix-6" ou "/boot/config-2.6.8.1-12mdk". No Qconf, vá em "File > Load" e aponte o arquivo:

As opções estão divididas em categorias, com uma descrição resumida de cada opção no nível mais baixo. A esmagadora maioria das opções está relacionada justamente com suporte a dispositivos. Para cada módulo existem três opções: compilar no executável principal do Kernel (built-in, representado por um símbolo de "Ok" no no Qconf ou um "Y" no xconfig antigo), compilar como módulo (um ponto no Qconf ou um "M" no antigo) ou desativar. Compilar o componente na forma de um módulo faz com que ele seja carregado apenas quando necessário, sem inchar o Kernel. Esta é a opção ideal para todos os componentes que quiser manter, mas não tem certeza se serão usados freqüentemente. Coisas como o suporte à sua placa de rede, som, suporte a gerenciamento de energia para o seu notebook podem ser compilados diretamente no Kernel. Mas, não exagere, pois um Kernel muito grande vai demorar para ser compilado, aumentará o tempo de boot da máquina e terá um desempenho um pouco inferior. O ideal é compilar tudo o que não for essencial como módulo, como fazem as principais distribuições. Uma ressalva importante é que você SEMPRE deve adicionar o suporte ao sistema de arquivos no qual a partição raiz do sistema está formatada (ReiserFS, EXT3, XFS, etc.) diretamente no Kernel e não como módulo, caso contrário você cria um problema do tipo o ovo e a galinha: o Kernel precisa carregar o módulo reiserfs para acessar a partição, mas precisa acessar a partição para carregar o módulo. No final das contas, você acaba com um Kernel panic.

Os módulos com o suporte aos sistemas de arquivos principais (EXT, ReiserFS, XFS, JFS, etc.) estão logo no diretório principal da seção "File systems" do Qconf. O suporte a sistemas de arquivos menos comuns estão nos subdiretórios. Você deve compilar o suporte a ReiserFS diretamente no Kernel se a partição raiz do sistema está formatada neste sistema de arquivos, mas pode compilar como módulo se a partição raiz está formatada em EXT3 e apenas a partição home está formatada em ReiserFS, por exemplo. O suporte a FAT, NTFS e outros sistemas "não nativos", pode ser sempre compilado como módulo, enquanto o suporte a sistemas menos comuns, que você nunca vai usar (Minix e Amiga, por exemplo) pode ser desabilitado. Como disse, no Qconf um ponto indica que um componente está selecionado como módulo e um "ok" diz que ele será compilado diretamente no Kernel:

Um remendo para este tipo de situação é criar um initrd contendo o módulo necessário. O initrd é carregado diretamente pelo gerenciador de boot, o que permite que o Kernel tenha acesso ao módulo antes de ter acesso à partição. Ele é um arquivo compactado, contendo uma imagem de sistema que vai na pasta /boot. Você pode alterar seu conteúdo descompactando o arquivo e em seguida montando-o com o comando "mount -o loop initrd tmp/" A configuração do initrd a ser usado vai no arquivo de configuração do lilo (/etc/lilo.conf) na linha: initrd=/boot/initrd.gz

Para ativar o suporte a ACPI, por exemplo, acesse a categoria "Power management options" e ative o "ACPI Support", junto com os módulos "AC Adapter" (usado em micros desktop ou

notebooks ligados na tomada) e "Battery" (que monitora o estado da bateria do notebook e ativa os recursos de economia de energia suportados). Os outros módulos adicionam mais funções úteis: a opção "Fan" permite diminuir a rotação dos coolers, o módulo "Processor" permite diminuir a freqüência do processador para economizar energia, e assim por diante.

Quase todas as opções possuem descrições, mas é preciso ter bons conhecimentos de hardware para entender a função da maioria delas. A pasta "Documentation/", dentro da pasta com o fonte, contém descrições bem mais completas sobre a função de cada módulo. Os textos falam mais sobre os componentes e recursos suportados por cada módulo do que sobre programação, por isso os textos também são muito úteis para quem está estudando sobre hardware e suporte a dispositivos no Linux. A opção mais importante com relação ao desempenho é indicar qual processador está sendo utilizado. Isto fará com que o Kernel seja compilado com otimizações para a arquitetura, o que pode resultar em um ganho de desempenho de até 10% em alguns casos. Para isto, acesse a seção "Processador Type and Features" na tela principal do xconfig e clique na opção "Processador family":

A opção 386 gera um código que funciona em qualquer PC, desde um 386 até um Pentium 4 ou Athlon X2. A opção 486 gera algumas otimizações para a arquitetura pipelinizada do 486, mas mantendo a compatibilidade com todos os processadores daí em diante. A opção "586/K5/5x68/6x86/6x86MX" é a mais usada, pois gera um Kernel compatível com todos os processadores a partir do Pentium, com um nível de otimização razoável. Acima desta temos otimizações específicas para cada família de processadores, que garantirão um nível máximo de desempenho, em troca da compatibilidade com os demais. Compilar o Kernel com otimizações para o Pentium 4 irá torná-lo incompatível com máquinas Athlon ou Pentium III, por exemplo. Isto naturalmente não é um problema se você só utilizará estenovo Kernel na sua própria máquina. Na verdade, o nível de otimização do Kernel tem um efeito pequeno sobre o desempenho geral da máquina na maioria dos casos, pois o Kernel em si representa apenas uma pequena parte do sistema. Sobre ele temos pesos pesados com o X, KDE e o OpenOffice. Em geral, otimizar o Kernel para o seu processador, sem mexer nos demais programas, resulta num ganho médio de apenas 2 ou 3%. Outra opção comum é ativar o suporte a dois processadores. Esta opção é necessária caso você esteja usando um micro com dois processadores, ou um Processador Pentium 4 com HT, e queira que o sistema reconheça o segundo processador lógico. Em troca, ativar o suporte a multiprocessamento diminui sutilmente o desempenho do sistema em máquinas com apenas um processador, pois o sistema continua com o código necessário carregado na memória. Para ativar, habilite (ainda dentro da seção "Processador Type and Features") a opção: "Symmetric multi-processing support".

Depois de terminar, clique na opção "Save and Exit" no menu principal para salvar todas as alterações. Além do xconfig, você pode utilizar também o menuconfig , que oferece basicamente as mesmas opções, mas numa interface de modo texto. Ele serve como segunda opção caso o xconfig (que no Kernel 2.6 depende da biblioteca Qt) esteja indisponível. Para chamá-lo, use o comando: # make menuconfig

Tanto faz utilizar o xconfig ou o menuconfig, pois os dois gravam as alterações no mesmo arquivo, o .config, dentro do diretório "/usr/src/linux". Existe ainda uma quarta opção, ainda mais espartana: o "make config", que chama um programa de modo texto que simplesmente vai perguntando um a um quais componentes devem ser incluídos (e exige uma boa dose de paciência..:). Compilando

Depois de configurar o novo Kernel, você pode compilar e instalar usando os quatro comandos abaixo. Lembre-se de que, para compilar qualquer programa no Linux, é necessário ter o compilador gcc instalado. # make clean O "make clean" serve para limpar a casa, removendo restos de compilações anteriores e módulos desnecessários. Ao recompilar um Kernel da série 2.4, é necessário rodar também o comando "make dep", que verifica a cadeia de interdependências do Kernel. Ao executar o "make clean", todos os módulos e componentes anteriormente compilados são removidos, fazendo com que a compilação seja realmente feita a partir do zero. Se você já

compilou o Kernel anteriormente e fez agora apenas uma pequena modificação (como ativar um módulo adicional), pode omitir o "make clean", de forma que os objetos gerados na compilação anterior sejam aproveitados e a compilação seja muito mais rápida. # make bzImage Este é o comando que compila o executável principal do Kernel, o arquivo que vai na pasta /boot. O tempo varia de acordo com a velocidade do processador, mas é sempre relativamente rápido, já que estamos falando de um executável de geralmente 1.5 ou 2 MB. Num PC atual não demora mais do que 4 ou 6 minutos. Em máquinas com dois processadores, você pode reduzir o tempo de compilação usando a opção "-j4", que faz com que o make processe 4 módulos de cada vez, ao invés de apenas um como faria por padrão. Isto faz com que o segundo processador realmente fique ocupado, reduzindo em até 40% o tempo de compilação. Neste caso o comando fica: # make -j4 bzImage

Este comando também pode ser utilizado em máquinas com apenas um processador (ou com um Pentium 4 com HT), mas neste caso o ganho de performance é bem menor. Geralmente você terá melhores resultados usando a opção "-j2" (apenas dois módulos por vez, ao invés de quatro). Em versões antigas do Kernel, era usado o comando "make zImage" mas ele tem uma limitação quanto ao tamanho máximo do Kernel a ser gerado, por isso só funciona em Kernels muito antigos, da série 2.0. O "bzImage" permite gerar Kernels sem limite de tamanho. Uma observação importante, é que, embora tradicional, o comando "make bzImage" só é usado até o Kernel 2.6.15. A partir do 2.6.16, o comando de compilação foi simplificado, já que, por causa do limite de tamanho, não existe mais nenhum motivo para alguém gerar uma "zImage". O comando para compilar o executável do Kernel passou a ser apenas "make", como em outros programas: # make

Ao tirar proveito da compilação paralela do make, use: # make -j4

Em qualquer um dos dois casos, depois de compilar o executável principal, temos o: # make modules ... que conclui o trabalho, compilando todos os componentes marcados como módulos. Numa distribuição típica, esta é a etapa mais demorada, pois quase tudo é compilado como módulo, gerando um total de 40 ou 50 MB de arquivos, o que demora proporcionalmente mais. O tempo de compilação cai bastante se você começar a desativar os módulos que não for usar. Assim como no comando anterior, você pode acrescentar o "-j4" ou "-j2" para reduzir o tempo de compilação.

Instalando

O novo Kernel será gravado no arquivo "/usr/src/linux-2.6.x/arch/i386/boot/bzImage" . O próximo passo é copiá-lo para o diretório /boot e em seguida configurar o lilo para inicializar o novo Kernel ao invés do antigo. Para copiar, use o comando: # cp /usr/src/linux-2.6.x/arch/i386/boot/bzImage /boot/novo_ kernel

Substituindo sempre o "linux-2.6.x" pelo nome correto da pasta onde está o Kernel. Isso também renomeará o arquivo para "novo_kernel", que pode ser alterado para outro nome qualquer. Além do arquivo principal, é necessário instalar também os componentes compilados como módulos, que ficam armazenados num diretório separado, na pasta /lib/modules/. Para isto, basta usar o comando: # make modules_install Concluindo, você deve copiar também o arquivo "System.map", que contém a imagem de sistema inicial, carregada durante o boot: # cp /usr/src/linux-2.xx/System.map /boot/System.map O próximo passo é configurar o lilo. Para isso, abra o arquivo "/etc/lilo.conf": # kedit /etc/lilo.conf 

Aqui estão as opções de inicialização que são dadas durante o boot. O que precisamos é adicionar uma nova opção, que inicializará o novo Kernel. Basta incluir as linhas no final do arquivo e salvá-lo: image = /boot/novo_kernel label = novo_kernel read-only Ao reiniciar o sistema você verá uma nova opção no menu do lilo, justamente o "novo_kernel" que acabamos de adicionar, junto com a entrada para inicializar o Kernel antigo. Teste o novo Kernel e quando tiver certeza de que ele está funcionando adequadamente, edite novamente o /etc/lilo.conf colocando o nome da entrada referente ao novo Kernel na opção "default". Isto fará com que ele passe a ser inicializado por default. Seu lilo.conf ficará parecido com este: boot=/dev/hda timeout=100 message=/boot/message vga=788 default= novo-kernel

image = /boot/novo-kernel label = novo-kernel root=/dev/hda1 append="quiet noapic" read-only image=/boot/vmlinuz label=linux root=/dev/hda1 initrd=/boot/initrd.img append="quiet noapic" read-only Você pode ter quantos Kernels diferentes quiser, basta salvar cada arquivo com um nome diferente e adicionar uma entrada no arquivo. Recompilando o Kernel à moda Debian

O Debian oferece uma ferramenta chamada kernel-package que facilita bastante a recompilação do Kernel. Ele cuida de todo o processo de compilação e no final gera um arquivo .deb com o novo Kernel, que pode ser rapidamente instalado usando o comando "dpkg -i" e, inclusive, instalado em outros micros. Como de praxe, o primeiro passo é acessar a pasta com os fontes do Kernel. O que muda são os comandos executados dentro dela. Ao invés do "make bzImage", "make modules" e "make modules_install", todo o restante do processo é automatizado por dois comandos: # make-kpkg clean # make-kpkg kernel_image

No final do processo será gerado um arquivo "kernel-image" dentro da pasta "/usr/src" com o novo Kernel, como em "/usr/src/kernel-image-2.6.15_10.00.Custom_i386.deb". Este pacote contém a imagem completa, incluindo o arquivo vmlinuz que vai na pasta /boot, módulos e um script de instalação (executado ao instalar o pacote) que automatiza a instalação. O processo de compilação de um Kernel da série 2.6 com uma configuração típica demora em média 45 minutos num Sempron 2200. Por isso, tenha paciência. Você pode ir fazendo outras coisas enquanto isso. Caso a compilação termine em uma mensagem de erro, experimente começar novamente, desativando o módulo que deu problemas. Erros de compilação também podem ser causados por erros de hardware. No Kurumin rode o stress-test (encontrado no Kurumin em Iniciar > Sistema) ou outro teste de hardware para verificar se a sua máquina está estável. Você pode instalar o pacote gerado rodando o dpkg -i, como em: # dpkg -i /usr/src/kernel-image-2.6.15_10.00.Custom_i386.deb

Durante a instalação existe uma pegadinha. O instalador pergunta "Do You Whant to stop Now? (Y/n)". O "Y" é o default, então se você simplesmente pressionar Enter sem ler, a instalação será abortada. Para continuar você precisa digitar "n" e dar Enter. Leia as outras perguntas com atenção. Se você quer que sejam gerados também pacotes com o fonte e os headers do Kernel, use o comando: # make-kpkg kernel_image kernel_source kernel_headers

Neste caso, serão gerados três pacotes no total, contendo o "kit completo" do Kernel gerado. Isto vai ser muito útil se você pretende distribuir o Kernel o instalá-lo em várias máquinas. O pacote com o fonte permite que outras pessoas recompilem o seu Kernel, fazendo alterações, enquanto os headers são necessários para instalar drivers de softmodems, os drivers 3D da nVidia e outros drivers proprietários. Aplicando patches

Os patches são muitas vezes o principal motivo para recompilar o Kernel. Muitos novos recursos demoram a ser incluídos no Kernel oficial e, enquanto isso (muitas vezes durante vários anos), ficam disponíveis apenas através de patches. Como exemplo podemos citar o Xen, o Freeswan (VPN), o Bootsplash (boot gráfico) e o OpenMosix (Cluster) entre muitos outros. Lendo muitos howtos você verá a necessidade de instalar patches diversos no Kernel para utilizar várias soluções. Em muitos casos, recursos incluídos em novas versões do Kernel (o lowlatency e o preempt, adicionados no Kernel 2.6, para melhorar as respostas do sistema) são disponibilizados como backports para versões anteriores do Kernel, novamente primeiro na forma de patches. Para aplicar um patch, comece descompactando o arquivo baixado. Geralmente os patches possuem a extensão ".patch", mas isso não é uma regra. Muitos patches podem ser baixados diretamente pelo apt-get. Digite "apt-get install kernel-patch" e pressione a tecla TAB duas vezes para ver todas as opções disponíveis. Como exemplo, vou mostrar como instalar os patches do xen, bluez e debianlogo numa versão recente do Kernel 2.6. Este último altera o tux que aparece durante o boot pelo logo do Debian, apenas para você ter certeza que o novo Kernel foi realmente compilado com os patches. Para instalar os três pelo apt-get, use os comandos: # apt-get install kernel-patch-xen # apt-get install kernel-patch-2.6-bluez # apt-get install kernel-patch-debianlogo

Todos os patches instalados pelo apt-get vão para a pasta " /usr/src/kernel-paches". Em geral, são instalados vários arquivos compactados, com versões específicas do patch para várias versões do Kernel. Descompacte apenas o arquivo que mais se aproxima da versão do Kernel que você está compilando, como em:

$ cd /usr/src/kernel-patches/diffs/debianlogo # gunzip debian-logo-2.6.2.gz

Para aplicar o patch descompactado, acesse a pasta onde estão os sources do Kernel, como em: $ cd /usr/src/kernel-source-2.6.16/

O próximo passo é aplicar o patch usando o comando patch -p1 < localização_do_patch, como em: # patch -p1 < /usr/src/ kernel-patches/diffs/debianlogo/debian-logo-2.6.2

Note que este comando deve ser usado apenas dentro da pasta com os sources do Kernel. Depois de aplicar todos os patches, siga o procedimento normal para gerar o novo Kernel: # make xconfig # make-kpkg clean # make-kpkg kernel_image

Um bom lugar para se manter informado sobre as novidades relacionadas ao desenvolvimento do Kernel, novos patches, etc. é o http://kerneltrap.org.

Criando patches Os patches são largamente usados não apenas no desenvolvimento do Kernel, mas em praticamente todos os projetos open-source. Um patch nada mais é do que um arquivo de texto contendo as diferenças entre dois arquivos, uma forma prática de enviar correções e modificações para os mantenedores dos projetos. Por serem pequenos, os patches podem ser facilmente enviados via e-mail e são fáceis de auditar, pois permitem verificar as poucas linhas alteradas, ao invés de checar o código fonte completo. Enviar um patch pode ser a única forma de ter sua correção ou melhoria aceita. Vamos a um exemplo rápido de como criar um patch para um shell script simples, que instala o Acrobat Reader no Debian: apt-get install acroread apt-get install mozilla-acroread ln -sf /usr/lib/Adobe/Acrobat7.0/browser/intellinux/nppdf.so \ /usr/lib/firefox/plugins/nppdf.so Imagine que o script faz parte de um programam maior, que está localizado na pasta "programa/", dentro do seu diretório home, junto com outros arquivos. O arquivo do script por coincidência se chama "script". O script original não está funcionando corretamente e você descobriu que o programa são dois erros simples nas localizações das pastas. Depois das modificações, o script ficou:

apt-get install acroread apt-get install mozilla-acroread ln -sf /usr/lib/Adobe/Acrobat7.0/Browser/intellinux/nppdf.so \ /usr/lib/mozilla-firefox/plugins/nppdf.so Você precisa agora gerar um patch e enviá-lo para o mantenedor do programa, para que ele possa aplicar sua correção. Para isso, você vai precisar de duas pastas, uma contendo o código fonte do programa original e outra contendo o código fonte depois de suas alterações. Não importa se você alterou apenas um arquivo ou se fez alterações em vários. O patch conterá todas as diferenças entre as duas pastas. Imagine que a pasta original se chama "programa" e a pasta com as modificações se chama "programa-mod". O comando para gerar o patch seria: $ diff -uNr programa programa-mod/

diff -uNr programa/script programa-mod/script --- programa/script 2005-08-09 11:38:55.000000000 -0300 +++ programa-mod/script 2005-08-09 11:38:47.000000000 -0300 @@ -1,4 +1,4 @@ apt-get install acroread apt-get install mozilla-acroread -ln -sf /usr/lib/Adobe/Acrobat7.0/browser/intellinux/nppdf.so \ -/usr/lib/firefox/plugins/nppdf.so +ln -sf /usr/lib/Adobe/Acrobat7.0/Browser/intellinux/nppdf.so \ +/usr/lib/mozilla-firefox/plugins/nppdf.so

Veja que ele devolve as diferenças diretamente na tela. Para que ele gere o patch, direcione a saída do comando para um arquivo: $ diff -uNr programa programa-mod/ > patch

É isso aí :). Seu primeiro patch está pronto, espero que seja o primeiro de muitos outros. Basta enviá-lo por e-mail para o mantenedor do programa, explicando o que foi feito. Para aplicar seu patch, o mantenedor acessaria a pasta com o fonte do programa (a pasta programa/ no exemplo) e, dentro dela, usaria o comando: $ patch -p1 < /algum_lugar/patch

Neste caso usei como exemplo um shell script, mas os patches podem ser criados a partir de código fonte em qualquer linguagem, ou até mesmo a partir de arquivos binários.

Acelerando a compilação com o distcc Mais uma dica é que você pode utilizar outros micros da rede para reduzir o tempo de compilação utilizando o distcc. Ele permite que os jobs da compilação (criados usando a opção -j) sejam processados por diferentes PCs da rede, reduzindo o tempo de compilação quase que proporcionalmente. Com 5 micros de configuração similar, a compilação é realizada em

aproximadamente 1/4 do tempo. Ele é usado pelos desenvolvedores de muitos projetos para diminuir o tempo perdido com cada compilação e assim acelerar o desenvolvimento, sobretudo nas fases de teste. Para usar o distcc não é necessário que todos os micros possuam configuração similar, nem que estejam rodando a mesma distribuição. É recomendável apenas que sejam sempre utilizadas versões similares do distcc em todos, para evitar problemas inesperados. Ele está disponível na maioria das distribuições. Procure pelo pacote "distcc". Nas distribuições derivadas do Debian ele pode ser instalado através do apt-get: # apt-get install distcc

Naturalmente, você deve instalá-lo em todas as máquinas que serão usadas. Como medida de segurança, mesmo depois de instalado ele fica explicitamente desabilitado no arquivo "/etc/default/distcc ". Para ativar, edite o arquivo e mude a opção "STARTDISTCC="false" para: STARTDISTCC="true" A seguir, na opção "ALLOWEDNETS" você deve especificar quais micros poderão usar o servidor, especificando diretamente o IP ou nome de cada um, ou autorizando diretamente toda a faixa de endereços da rede local, como em: ALLOWEDNETS="192.168.1.0/24" Concluída a configuração, reinicie o serviço, em todas as máquinas: # /etc/init.d/distcc restart

A grosso modo, o distcc trabalha enviando trechos de código para as demais máquinas da rede, juntamente com os parâmetros de compilação necessários e recebe de volta os binários  já compilados. Apenas o seu micro precisa ter o código fonte do que está sendo compilado, mas todas as máquinas que forem usadas precisam ter os compiladores necessários para compilá-lo. Ao instalar o sistema em cada máquina, aproveite para sempre habilitar a categoria de desenvolvimento na seleção dos pacotes. É desejável também que, mesmo que sejam usadas distribuições diferentes, todas as máquinas tenham instaladas versões idênticas ou pelo menos similares do gcc e g++. Na hora de compilar, comece criando a variável "DISTCC_HOSTS" no shell, que especifica quais máquinas da rede serão utilizadas pelo distcc durante a compilação, como em: $ export DISTCC_HOSTS='127.0.0.1 192.168.1.33 192.168.1.100 192.168.1.156'

Se preferir, você pode tornar esta configuração permanente, salvando a lista dentro do arquivo ".distcc/hosts", no diretório home do usuário usado nas compilações. Depois de criar a pasta .distcc, você pode usar o comando: $ echo '127.0.0.1 192.168.1.33 192.168.1.100 192.168.1.156' > ~/.distcc/hosts

Depois de criada a lista com os hosts, você pode compilar da forma usual, adicionando os parâmetros "-jX CC=distcc" depois do "make", onde o X é o número de jobs simultâneos que serão criados. Ao usar o distcc, uma regra geral é usar 3 jobs por processador, por máquina. Com 4 máquinas monoprocessadas, -j12 é um bom número. Em algumas situações, usar um número maior de jobs pode reduzir um pouco o tempo de compilação e em outras vai simplesmente retardar o processo. No caso da compilação do Kernel, os comandos seriam: $ make -j12 CC=distcc bzImage

(make -j12 CC=distcc no Kernel 2.6.16, em diante) $ make -j12 CC=distcc modules # make modules install

Note que não usei o distcc no "make modules install", pois ele não envolve compilação, apenas a instalação dos módulos gerados no comando anterior. O mais correto é sempre fazer compilações usando um login de usuário e usar o root apenas para rodar os comandos de instalação. Para fazer isso, é necessário que a conta de usuário tenha sempre permissão de acesso completa à pasta com o código fonte. Se você está compilando o Kernel, e o fonte está na pasta "/usr/src/linux/2.6.15/" (que originalmente pertence ao root), você pode pode usar o comando: # chown -R joao.joao /usr/src/linux/2.6.15/

... para transferir a posse da pasta para o usuário joao, grupo joao, de forma que ele possa fazer a compilação sem enfrentar problemas de permissão.

Criando pacotes a partir dos fontes com o chec kinstall Todas as distribuições incluem um conjunto generoso de pacotes, seja diretamente nos CDs de instalação, seja em repositórios disponíveis via web. Os repositórios oficiais do Debian, por exemplo, combinados com o repositório non-free e mais alguns repositórios não oficiais, podem facilmente oferecer mais de 22.000 pacotes diferentes. Mesmo assim, muitos drivers e softwares não estão disponíveis nos repositórios e precisam ser instalados manualmente a partir do código fonte. O checkinstall facilita esta tarefa, principalmente se você precisa instalar o mesmo software em várias máquinas ou quer distribuí-lo para amigos, gerando um pacote .deb, .tgz ou .rpm com o software pré-compilado, que pode ser rapidamente instalado usando o gerenciador de pacotes. Para usá-lo, comece instalando o pacote através do gerenciador de pacotes disponível. Ele é um pacote bastante comum, que vem incluído em todas as principais distribuições. No Debian você pode instalá-lo pelo apt-get: # apt-get install chec kinstall

O funcionamento do checkinstall é simples. Ao instalar qualquer pacote a partir do código fonte, substitua o comando "make install" pelo comando apropriado do checkinstall. Onde:

# checkinstall -D

(gera um pacote .deb, para distribuições derivadas do Debian) # checkinstall -R

(gera um pacote .rpm, que pode ser usado em distribuições derivadas do Red Hat) # checkinstall -S

(gera um pacote .tgz, para o Slackware) Por exemplo, para gerar um pacote .deb, contendo os módulos e utilitários do driver para modems 537EP, disponível no http://linmodems.technion.ac.il/packages/, os comandos seriam: $ tar -zxvf intel-537EP-2.60.80.0.tgz $ cd intel-537EP-2.60.80.0/ $ make clean $ make 537 # checkinstall -D

O checkinstall deve ser sempre executado como root. Ele vai gerar o pacote, salvando-o no diretório a partir de onde foi chamado (/home/kurumin/intel-537EP-2.60.80.0/intel-537ep2.60.80.0_2.60.80.0-1_i386.deb no meu caso) e em seguida instalá-lo na sua máquina. Durante a geração do pacote, ele fará algumas perguntas, a fim de gerar o arquivo de controle que contém informações como o mantenedor do pacote (você no caso), uma descrição do pacote (um texto de poucas linhas explicando o que ele faz) e a versão. Ao gerar seus próprios pacotes, você pode ter problemas de instalação, caso seu pacote inclua algum arquivo que também exista em outro pacote já instalado no sistema, gerando erros como: (Lendo banco de dados ... 68608 arquivos e diretórios atualmente instalados.) Descompactando intel-537ep-2.60.80.0 (de .../intel-537ep-2.60.80.0_2.60.80.0-1_i386.deb) ... dpkg: erro processando /home/kurumin/intel-537EP-2.60.80.0/intel-537ep2.60.80.0_2.60.80.0-1_i386.deb (--install): tentando sobrescrever `/lib/modules/2.6.8.1-kanotix-10/modules.usbmap', que também está no pacote qemu dpkg-deb: subprocesso paste morto por sinal (Broken pipe) Erros foram encontrados durante processamento de: /home/kurumin/intel-537EP-2.60.80.0/intel-537ep-2.60.80.0_2.60.80.0-1_i386.deb Nestes casos você pode modificar o pacote, para não incluir o arquivo, desinstalar o outro pacote com quem ele conflita (o qemu no caso) ou, caso perceba que é um problema benigno, que não trará maiores conseqüências, forçar a instalação do seu pacote, para que ele subscreva o arquivo usado por outro. No caso de um pacote .deb, o comando para forçar a instalação seria:

# dpkg -i --force-all pacote.deb

No caso de um pacote do .rpm, o comando seria: # rpm -iv --replacefiles pacote.rpm

ou: # rpm -iv --force pacote.rpm No Slackware não existe a necessidade de forçar a instalação de pacotes, pois o gerenciador não checa dependências ou arquivos duplicados, deixando que você faça o que bem entender. Isto é ao mesmo tempo uma vantagem (você pode fazer o que quiser) e uma grande desvantagem (você pode destruir o sistema se não souber o que está fazendo). Existem ainda algumas limitações gerais com pacotes pré-compilados, que você deve levar em consideração: Em primeiro lugar, o pacote gerado foi compilado para a sua máquina e para a distribuição atualmente em uso. Não existe garantia que o mesmo pacote vai funcionar para distribuições diferentes, mesmo que elas utilizem o mesmo padrão de pacotes. No caso de pacotes contendo drivers, como o driver para modems 537EP que usei no exemplo, é gerado um módulo pré-compilado, que vai funcionar apenas em distribuições que utilizem a mesma versão do Kernel. Ou seja, basicamente apenas na mesma versão da mesma distribuição que você está usando. Não adianta compilar um pacote no Mandriva 2006 e esperar que ele funcione no Slackware 10.2, por exemplo. Você pode ver mais detalhes sobre a instalação de drivers no Linux no capítulo 3 deste livro.

Escrevendo scripts de bac kup Durante a década de 70, vários utilitários foram desenvolvidos para fazer backup de arquivos armazenados em servidores Linux. Os computadores da época eram muito limitados, por isso os utilitários precisavam ser simples e eficientes, e deveriam existir meios de agendar os backups para horários de pouco uso das máquinas. Sugiram então utilitários como o tar e o gzip e mais tarde ferramentas como o rsync. Estes utilitários eram tão eficientes que continuaram sendo usados ao longo do tempo. Por incrível que possa parecer, são usados sem grandes modificações até os dias hoje. Naturalmente, existem muitos utilitários amigáveis de backup, como o Amanda (para servidores) e o Konserve (um utilitário mais simples, voltado para usuários domésticos). Mas, internamente, eles continuam utilizando como base o o dump, tar, gzip e outros trigenários. Mais incrível ainda, é que estes utilitários possuem uma penetração relativamente pequena. A maior parte dos backups ainda é feita através de scripts personalizados, escritos pelo próprio administrador. E, novamente, estes scripts utilizam o tar, gzip, rsync e outros. É justamente sobre estes scripts personalizados que vou falar aqui. Vamos começar com alguns exemplos simples:

Para compactar o conteúdo de uma pasta, usamos o tar combinado com o gzip ou bzip2. O tar agrupa os arquivos e o gzip os compacta. Os arquivos compactados com o gzip usam por padrão a extensão "tar.gz", enquanto os compactados com o bzip2 usam a extensão "tar.bz2". O bzip2 é mais eficiente, chega a obter 10% ou mais de compressão adicional, mas em compensação é bem mais pesado: demora cerca de 3 vezes mais para compactar os mesmos arquivos. Você escolhe entre um e outro de acordo com a tarefa. O comando para compactar uma parta é similar ao "tar -zxvf" que usamos para descompactar arquivos. Para compactar a pasta "arquivos/", criando o arquivo "arquivos.tar.gz", o comando seria: $ tar -zcvf arquivos.tar.gz arquivos/

O "c" indica que o tar deve criar um novo arquivo e o "v" faz com que exiba informações na tela enquanto trabalha. Se preferir comprimir em bz2, muda apenas a primeira letra; ao invés de "z" usamos "j": $ tar -jcvf arquivos.tar.bz2 arquivos/

Estes comandos seriam ideais para fazer um backup completo, de uma ou várias pastas do sistema, gerando um arquivo compactado que poderia ser armazenado num HD externo, gravado num DVD ou mesmo transferido via rede para outro servidor. Imagine agora um outro cenário, onde você precisa fazer backup dos arquivos de uma pasta de trabalho diariamente. Os arquivos gerados não são muito grandes e você tem muito espaço disponível, mas é necessário que os backups diários feitos em arquivos separados e sejam guardados por um certo período, de forma que seja possível recuperar um arquivo qualquer a partir da data. Ao invés de ficar renomeando os arquivos, você poderia usar um pequeno script para que os arquivos fossem gerados já com a data e hora incluída no nome do arquivo: DATA=`date +%Y-%m-%d-%H.%M.%S` cd /mnt/backup tar -zcvf trabalho-"$DATA".tar.gz /mnt/hda6/trabalho/ A primeira linha do script cria uma variável "DATA", contendo o resultado do comando "date +%Y-%m-%d-%H.%M.%S". O comando date retorna a data e hora atual, como em "Sex Set 16 12:36:06 BRST 2005". A saída padrão dele não é muito adequada para usar em nomes de arquivos, por isso usamos as opções para alterar o formato de saída, de modo que o resultado seja "2005-09-16-12.37" (ano, mês, dia, hora, minuto, segundo). Usamos este valor no nome do arquivo com o backup, de forma que, cada vez que você chame o script, seja gerado um arquivo com a data e hora em que foi gerado, sem a possibilidade de dois arquivos saírem com o mesmo nome. O próximo passo é fazer com que este script de backup seja executado diariamente de forma automática, o que pode ser feito usando o cron.

Em primeiro lugar, salve os comandos num arquivo de texto, que vamos chamar de "backup.sh" e transforme-o num executável usando o comando "chmod +x backup.sh". Para que ele seja executado automaticamente todos os dias, copie-o para dentro da pasta "/etc/cron.daily " e certifique-se de que o serviço "cron" esteja ativo: # cp -a bac kup-sh /etc/cron.daily # /etc/init.d/cron start

Se preferir que o script seja executado apenas uma vez por semana, ou mesmo uma vez por hora, use as pastas "/etc/cron.weekly" ou a "/etc/cron.hourly". Por padrão, os scripts dentro da pasta "/etc/cron.daily" são executados pouco depois das 6 da manhã (o horário exato varia de acordo com a distribuição). Para alterar o horário, edite o arquivo "/etc/crontab", alterando a linha: 25 6 * * * root test -x /usr/sbin/anacron || run-parts --report /etc/cron.daily O "25 6" indica o minuto e a hora. Se quiser que o script seja executado às 11 da noite, por exemplo, mude para "00 23". Neste exemplo usei a pasta "/mnt/backup" para salvar os arquivos. Esta pasta pode ser o ponto de montagem de um HD externo ou de um compartilhamento de rede por exemplo. O seu script pode conter os comandos necessários para montar e desmontar a pasta automaticamente. Imagine, por exemplo, que o backup é sempre feito na primeira partição de um HD externo, ligado na porta USB, que é sempre detectada pelo sistema como "/dev/sda1". O script deve ser capaz de montar a partição, gravar o arquivo de backup e depois desmontá-la. Se por acaso o HD não estiver plugado, o script deve abortar o procedimento. Para isso precisamos verificar se o HD realmente foi montado depois de executar o comando "mount /dev/sda1 /mnt/sda1". Existem muitas formas de fazer isso, uma simples é simplesmente filtrar a saída do comando "mount" (que mostra todos os dispositivos montados) usando o grep para ver se o "/mnt/sda1" aparece na lista. Se não estiver, o script termina, caso esteja, ele continua, executando os comandos de backup: mount /dev/sda1 /mnt/sda1 montado=`mount | grep /mnt/sda1` if [ -z "$montado" ]; then exit 1 else DATA=`date +%Y-%m-%d-%H.%M` cd /mnt/backup tar -zcvf trabalho-"$DATA".tar.gz /mnt/hda6/trabalho/ umount /mnt/sda1 fi

A partir daí, sempre que você deixar o HD externo plugado no final do expediente, o backup é feito e estará pronto no outro dia. Se esquecer de plugar o HD num dia, o script percebe e não faz nada. Se preferir que o script grave o backup num DVD, ao invés de simplesmente salvar numa pasta, você pode usar o "growisofs" para gravá-lo no DVD. Neste caso, vamos gerar o arquivo numa pasta temporária e deletá-lo depois da gravação: DATA=`date +%Y-%m-%d-%H.%M` rm -rf /tmp/backup; mkdir /tmp/backup; cd /tmp/backup tar -zcvf trabalho-"$DATA".tar.gz /mnt/hda6/trabalho/ growisofs -speed=2 -Z /dev/dvd -R -J /tmp/bac kup/trabalho-"$DATA".tar.gz

rm -rf /tmp/backup O "-speed=2" permite que você especifique a velocidade de gravação do DVD, enquanto o "-Z" cria uma nova seção. É possível usar o mesmo disco para gravar vários backups (se o espaço permitir) usando a opção "-M" a partir da segunda gravação, que adiciona novas seções no DVD, até que o espaço se acabe. O "/dev/dvd" indica o dispositivo do drive de DVD. A maioria das distribuições cria o link /dev/dvd apontando para o dispositivo correto, mas, em caso de problemas, você pode indicar diretamente o dispositivo correto, como, por exemplo, "/dev/hdc". As opções "-R -J" adicionam suporte às extensões RockRidge e Joilet. Se o cron for configurado para executar o script todos os dias, você só precisará se preocupar em deixar o DVD no drive antes de sair. Se preferir fazer os backups em CDR ("em que século você vive?" ;), crie uma imagem ISO usando o mkisofs e em seguida grave-a no CD usando o cdrecord, como em: mkisofs -r -J -o trabalho.iso /tmp/backup/trabalho-"$DATA".tar.gz cdrecord dev=/dev/hdc trabalho.iso Este comando do cdrecord funciona em distribuições recentes, que utilizam o Kernel 2.6 em diante (com o módulo ide-cd). No Kernel 2.4, era usada emulação SCSI para acessar o gravador de CD, fazendo com que ele fosse visto e acessado pelo sistema como se fosse um gravador SCSI. Neste caso, o comando de gravação seria "cdrecord dev=0,0,0 -data trabalho.iso", onde o "0,0,0" é o dispositivo do gravador, que você descobre através do comando "cdrecord scanbus". Outro grande aliado na hora de programar backups é o rsync. Ele permite sincronizar o conteúdo de duas pastas, transferindo apenas as modificações. Ele não trabalha apenas comparando arquivo por arquivo, mas também comparando o conteúdo de cada um. Se apenas uma pequena parte do arquivo foi alterada, o rsync transferirá apenas ela, sem copiar novamente todo o arquivo. Ele é uma forma simples de fazer backups incrementais, de grandes quantidades de arquivos, ou mesmo partições inteiras, mantendo uma única cópia atualizada de tudo num HD externo

ou num servidor remoto. Este backup incremental pode ser atualizado todo dia e complementado por um backup completo (para o caso de um desastre acontecer), feito uma vez por semana ou uma vez por mês. Para instalar o rsync, procure pelo pacote "rsync" no gerenciador de pacotes. No Debian instale com um "apt-get install rsync" e no Mandriva com um "urpmi rsync". Para fazer um backup local, basta informar a pasta de origem e a pasta de destino, para onde os arquivos serão copiados: $ rsync -av /mnt/hda6/trabalho /mnt/bac kup/

A opção "-a" (archive) faz com que todas as permissões e atributos dos arquivos sejam mantidos, da mesma forma que ao criar os arquivos com o tar e o "v" (verbose) mostra o progresso na tela. A cópia inicial vai demorar um pouco, mais do que demoraria uma cópia simples dos arquivos. Mas, a partir da segunda vez, a operação será muito mais rápida. Note que neste comando estamos copiando a pasta "trabalho" recursivamente para dentro da "/mnt/backup", de forma que seja criada a pasta "/mnt/backup/trabalho". Adicionando uma barra, como em "/mnt/hda6/trabalho/", o rsync copiaria o conteúdo interno da pasta diretamente para dentro da "/mnt/backup". Se algum desastre acontecer e você precisar recuperar os dados, basta inverter a ordem das pastas no comando, como em: $ rsync -av /mnt/backup/trabalho /mnt/hda6/trabalho/

O rsync pode ser também usado remotamente. Originalmente ele não utiliza nenhum tipo de criptografia, o que faz com que ele não seja muito adequado para backups via internet. Mas este problema pode ser resolvido com a ajuda do SSH, que pode ser utilizado como meio de transporte. Não é à toa que o SSH é chamado de canivete suíço, ele realmente faz de tudo. Neste caso o comando ficaria um pouco mais complexo: $ rsync -av --rsh="ssh -C -l tux" /mnt/hda6/trabalho \ [email protected]:/mnt/bac kup/

Veja que foi adicionado um parâmetro adicional, o --rsh="ssh -C -l tux", que orienta o rsync a utilizar o SSH como meio de transporte. O "-C" orienta o SSH a comprimir todos os dados (economizando banda da rede) e a se conectar ao servidor remoto usando o login tux (-l tux). Naturalmente, para que o comando funcione, é preciso que o servidor esteja com o SSH habilitado, e você tenha um login de acesso. Em seguida vem a pasta local com os arquivos, o endereço IP (ou domínio) do servidor e a pasta (do servidor) para onde vão os arquivos. Uma observação é que usando apenas os parâmetros "-av", o rsync apenas atualiza e grava novos arquivos na pasta do servidor, sem remover arquivos que tenham sido deletados na

pasta local. Por um lado isto é bom, pois permite recuperar arquivos deletados acidentalmente, mas por outro pode causar confusão. Se você preferir que os arquivos que não existem mais sejam deletados, adicione o parâmetro "--delete", como em: $ rsync -av --delete --rsh="ssh -C -l tux" /mnt/hda6/trabalho \ [email protected]:/mnt/bac kup/

Para recuperar o backup, basta novamente inverter a ordem do comando, como em: $ rsync -av --rsh="ssh -C -l tux" [email protected]:/mnt/bac kup/ \ /mnt/hda6/trabalho

Originalmente, você vai precisar fornecer a senha de acesso ao servidor cada vez que executar o comando. Ao usar o comando dentro do script de backup, você pode gerar uma chave de autenticação, tornando o login automático. Esta opção é menos segura, pois caso alguém consiga copiar a chave (o arquivo .ssh/id_rsa dentro no home do usuário), poderá ganhar acesso ao servidor. De qualquer forma, para usar este recurso, rode o comando "ssh-keygen -t rsa " (que gera a chave de autenticação) usando o login do usuário que executará o script de backup, deixando a passprase em branco. Em seguida, copie-o para o servidor, usando o comando: $ ssh-copy-id -i ~/.ssh/id_rsa.pub [email protected]

A partir daí, o script de backup pode ser executado diretamente, através do cron, pois não será mais solicitada a senha.

Usando o autofs/automount O suporte à montagem automática do drive de CD-ROM e disquete é usado a tempos em várias distribuições Linux. Apesar disso, muitas distribuições não trazem este recurso habilitado por default, pois automount não é o sistema mais estável do mundo. Ele trava ou se confunde com uma certa freqüência, fazendo com que seja necessário ficar forçando a montagem ou ejeção do CD manualmente. O Kurumin é um exemplo de distribuição que não usa o automount por padrão. Nele você encontra dois ícones no Desktop para acessar o CD e ejetá-lo. Este ícone para ejetar o CD, encontrado no Kurumin é uma solução para um problema comum. No Linux você não consegue desmontar, muito menos ejetar o CD-ROM enquanto existe algum programa acessando os arquivos. Se você esquecer uma janela do Konqueror ou uma instância do OpenOffice acessando algum arquivo do CD, você vai ficar com ele preso até se fechá-la ou reiniciar a máquina. Isto é irritante às vezes. Em muitos casos você quer simplesmente uma forma rápida de ejetar o CD, custe o que custar. O ícone para ejetar o CD roda os comandos: "fuser -k /mnt/cdrom; umount /mnt/cdrom; eject /mnt/cdrom".

O "fuser" fecha qualquer programa que esteja acessando a pasta /mnt/cdrom, para que o CDROM possa ser desmontado e ejetado. É um sistema manual, mas que pelo menos funciona sempre, de uma forma previsível. Mesmo assim, você pode ativar o suporte à montagem automática de uma forma simples na maioria dos casos. O autofs/automount é a combinação de um módulo de Kernel e um conjunto de utilitários e arquivos de configuração, que são instalados com o pacote autofs. Em primeiro lugar, certifique-se que o módulo "autofs" ou "autofs4" está carregado. Rode o comando "lsmod" e verifique se ele aparece na lista. Caso não esteja carregado, habilite-o com o comando "modprobe autofs4" (ou "modprobe autofs", dependendo da distribuição) e adicione a linha "autofs4" no final do arquivo "/etc/modules", para que ele seja carregado automaticamente durante o boot. Se este módulo não estiver presente, as coisas se complicam, pois você precisaria recompilar o Kernel, instalando o patch e ativando o suporte a ele. O próximo passo é instalar o pacote "autofs" usando o gerenciador de pacotes incluído na sua distribuição. Nas derivadas do Debian instale usando o comando: # apt-get install autofs No Slackware o pacote está disponível dentro da pasta "extras", disponível no segundo CD. O autofs é configurado através do arquivo /etc/auto.master. Um exemplo de configuração para este arquivo é: # /etc/auto.master # Linha que ativa o automount para o CD-ROM: /mnt/auto /etc/auto.misc --timeout=5

A pasta "/mnt/auto" é a pasta que será usada como ponto de montagem quando um CD-ROM for inserido. Você pode usar qualquer pasta, como "/autofs" ou "/auto", por exemplo. Porém, lembre-se de sempre usar uma pasta exclusiva, pois ao configurar o autofs para usar uma pasta com outros arquivos ou pastas dentro, eles ficarão inacessíveis até que ele seja desativado. A opção seguinte, "/etc/auto.misc" indica um segundo arquivo, onde vão mais opções, incluindo os drives que serão monitorados. Você pode alterar o nome do arquivo, o importante é seu conteúdo. A última opção, "--timeout=5" especifica que depois de 5 segundos de inatividade o CD-ROM ou disquete é automaticamente desmontado, permitindo que você use o botão de ejetar do drive. Como disse, ele não conseguirá ejetar o CD-ROM se houver algum aplicativo acessando o CD (uma janela do gerenciador de arquivos acessando a pasta /mnt/auto/cdrom, por exemplo). Você primeiro terá que fechar tudo para depois conseguir ejetar o CD. O arquivo "/etc/auto.misc" que estou usando no exemplo contem:

# /etc/auto.misc # Estas linhas contém as instruções necessárias para ativar o # autofs para o CD-ROM e floppy. cdrom -fstype=iso9660,ro,nosuid,nodev :/dev/cdrom floppy -fstype=auto,noatime,sync,umask=0 :/dev/fd0 Agora falta apenas iniciar o serviço do autofs: # /etc/init.d/autofs start O CD-ROM ficará acessível através da pasta "/mnt/auto/cdrom" e o disquete na pasta "/mnt/auto/floppy", indicadas no segundo arquivo. Lembre-se de criar a pasta "/mnt/auto" caso ela não exista. Ao simplesmente acessar a pasta "/mnt/auto/" você não verá o "cdrom". Para acessar o CD é preciso ir direto ao ponto, acessando a pasta "/mnt/auto/cdrom" diretamente. Para facilitar isso, você pode criar um link "cdrom" dentro do diretório home, ou no desktop. Assim você clica sobre o "cdrom" e já vai direto à pasta. Para isso, use o comando: $ ln -s /mnt/auto/cdrom ~/cdrom

Acessando dispositivos USB Graças a todas as melhorias nas funções de detecção no próprio Kernel, além do udev, hotplug e outras ferramentas de configuração, acessar um pendrive ou instalar uma impressora ou qualquer outro periférico USB suportado é uma tarefa simples, muitas vezes automatizada por scripts incluídos nas distribuições. Mesmo assim, é importante entender como funciona o processo de detecção e aprender como configurar dispositivos manualmente, a fim de corrigir problemas e personalizar o sistema. Vamos em seguida ver como estes passos são automatizados através do hotplug e do udev. Configurando manualmente

O primeiro passo para ativar qualquer dispositivo USB no Linux, é carregar o suporte à própria controladora USB da placa-mãe. No Kernel 2.6 existem três módulos diferentes destinados a esta função. O módulo "ehci-hcd" é o mais recente, que dá suporte a controladores e dispositivos USB 2.0 em geral. Ele é o módulo usado na grande maioria dos casos. No caso de micros antigos, que ainda utilizam controladoras USB 1.1, entram em ação os módulos "ohci-hcd" e "uhci-hcd". A diferença entre os dois é que o ohci-hcd dá suporte aos controladores usados pela Via e outros fabricantes, enquanto o uhci-hcd dá suporte aos controladores USB usados pela Intel. Em distribuições antigas, baseadas no Kernel 2.4, os módulos mudam de nome, passam a ser "usb-ohci" e "usb-uhci". A diferença entre o USB 1.1 e o 2.0 é o brutal aumento na capacidade de transmissão. O padrão USB original foi desenvolvido como um substituto para as portas seriais, com o objetivo de conectar impressoras, teclados, mouses e similares. Com o tempo, o USB começou a ser

usado para pendrives, HDs externos, placas de rede, câmeras e outros periféricos "rápidos", capazes de transmitir dados a muito mais que 12 megabits por segundo. O USB 2.0 surgiu como um padrão "definitivo", que opera a 480 megabits (cerca de 50 MB/s reais, descontando o overhead do gerado protocolo de comunicação e pacotes de controle). Os periféricos USB 2.0 são compatíveis com placas antigas e vice-versa, mas sempre nivelando por baixo. Seu pendrive USB 1.1 vai continuar trabalhando a 12 megabits seconectado numa controladora USB 2.0. Os três módulos são capazes de detectar os controladores a que dão suporte e por isso convivem muito bem entre si. Você pode tentar simplesmente carregar os três em seqüência, começando pelo "ehci-hcd". Ao encontrar uma controladora antiga, ou que não seja compatível, ele vai automaticamente passar o controle a um dos outros dois. # modprobe ehci-hcd # modprobe ohci-hcd # modprobe uhci-hcd

Em seguida entra em ação o módulo "usbcore" que oferece funções genéricas, usadas por todos os dispositivos USB, incluindo chamadas de sistema para conectar ou desconectar um dispositivo, reservar banda de transmissão e outras funções. O módulo usbcore se encarrega de detectar novos dispositivos USB conforme ele são conectados, criando uma lista dentro da pasta "/proc/bus/usb", que é utilizada por programas de detecção, como o hotplug e o udev. Caso necessário, monte-a manualmente, usando o comando: # mount -t usbfs /proc/bus/usb /proc/bus/usb

A partir daí, você pode carregar os drivers para os dispositivos conectados: Os módulos "usbmouse" e "usbkbd" ativam o suporte genérico a mouses e teclados USB. Existe também um módulo mais antigo, o " usbhid", que além de prover comunicação com nobreaks e alguns outros periféricos, oferece as funções básicas usadas por mouses e teclados. Completando, temos o módulo " joydev", que dá suporte a joysticks. Caso você tenha um conversor serial/USB, use o módulo "serial". Os adaptadores USB para teclados e mouses PS/2 não precisam de drivers adicionais, mas alguns mouses PS/2 não funcionam em conjunto com eles, pois é necessário a inclusão de um circuito adicional. Em caso de problemas com o teclado ou mouse, verifique também se a opção "USB LEGACY SUPPORT" está desativada no setup. Esta opção ativa uma camada de compatibilidade, destinada a fazer o teclado e mouse funcionarem no MS-DOS e Windows 9x, que em algumas placas faz com que o sistema deixe de detectar os dispositivos e ativar os drivers necessários durante o boot. O módulo usbserial habilita suporte à comunicação com Palms, Pocket PCs (com o Windows CE) e outros dispositivos que transfiram dados através da porta USB, usando-a como se fosse uma porta serial. A comunicação com estes dispositivos (do ponto de vista do sistema) é feita

de uma forma diferente que seria com um dispositivo de armazenamento, como um pendrive, por exemplo. O cartão de memória é visto como se fosse um HD externo, enquanto no caso do Palm a porta USB é usada como substituta para uma porta serial. Complementando o usbserial, é geralmente necessário um segundo módulo, que habilita o dispositivo. Para fazer sincronismo com um Palm, ative o módulo "visor" e, para um Pocket PC, o módulo "ipaq". Com o módulo carregado, você pode usar um programa de sincronismo, como o Kpilot, ou o SynCE. Os outros drivers disponíveis vão na pasta "/lib/modules/2.6.x/kernel/drivers/usb/serial". O primeiro dispositivo serial conectado aparece como o dispositivo "/dev/ttyUSB0", o segundo como "/dev/ttyUSB1" e assim por diante. Configure o programa de sincronismo para utilizar uma destas portas e tente abrir a conexão. Uma dica é que, no caso dos Palms você precisa primeiro pressionar o botão de hotsync no Palm (o que faz com que ele seja detectado), para só depois conseguir estabelecer a conexão dentro do programa de sincronismo. Um módulo similar é o " usblp", que ativa o suporte genérico a impressoras USB, que ficam acessíveis através dos devices "/dev/usb/lp0", "/dev/usb/lp1", etc. Para o suporte a scanners, existe o módulo "scanner", que ativa o device "/dev/usbscanner". Um problema comum é que os dispositivos ficam por padrão disponíveis apenas para o root. Para imprimir ou usar o scanner usando um login de usuário, é preciso abrir as permissões do dispositivo, como em "chmod 666 /dev/usbscanner". No caso das webcams, são usados os módulos "spca5xx", "stv680", "ultracam", "quickcam", "ibmcam", "konicawc", "sqcam" ou "vicam", de acordo com o modelo. O módulo "spca5xx" é o que dá suporte a maior parte dos modelos, mas ele não vem instalado por padrão em muitas distribuições. Veja como instalá-lo manualmente no capítulo sobre drivers. Existem no mercado algumas caixas de som e headsets USB que, ao contrário das caixas e microfones ligados na placa de som, são detectados como dispositivos de áudio independentes, como se fossem uma segunda placa de som. Estes dispositivos são, de uma forma geral, bem suportados no Linux, através do módulo "snd-usb-audio", que faz parte do Alsa. Alguns drivers mais incomuns são o "aiptek", que dá suporte a vários tablets USB, o "rt2570", que dá suporte às placas wireless USB com chipset RT2500 (Ralink) e o rtl8150, que dá suporte aos adaptadores de rede USB com o chipset de mesmo nome. Você pode encontrar uma lista com vários outros drivers incomuns no: http://www.qbik.ch/usb/devices/drivers.php. Para acessar pendrives, HDs USB e também câmeras e outros dispositivos compatíveis com o protocolo storage, usamos o módulo "usb-storage". Ele trabalha em conjunto com o módulo "sg" (SCSI Generic), que permite que os dispositivos sejam acessados usando o driver de acesso a dispositivos SCSI. Você pode pensar no módulo usb-storage como uma espécie de adaptador, que faz com que dispositivos de armazenamento USB sejam vistos pelo sistema como HDs SCSI.

O primeiro dispositivo fica acessível como "/dev/sda", o segundo como "/dev/sdb" e assim por diante. No caso de adaptadores para cartões de diversos formatos, cada conector é visto pelo sistema como um dispositivo independente. O cartão sd pode ficar acessível através do "/dev/sdc" e o memory stick através do "/dev/sdd", por exemplo, mesmo que nenhum dos outros encaixes esteja sendo usado. Para acessar, basta montar o dispositivo correto, como em: # mount /dev/sda1 /mnt/sda1

Uma dica é que, no Kernel 2.6, sempre que um pendrive ou cartão é detectado, é criada automaticamente uma pasta dentro do diretório "/sys/block", como em "/sys/block/sda". Dentro da pasta você encontra o arquivo "size", que contém a capacidade do dispositivo (em blocos de 512 bytes) e uma sub-pasta para cada partição, como "/sys/block/sda/sda1". No capítulo sobre shell script, veremos um exemplo de script que cria um ícone no desktop automaticamente, sempre que um pendrive é conectado, baseado justamente nestas informações. Voltando à explicação inicial, o pendrive ou cartão pode ser particionado normalmente, através do cfdisk, gparted ou qualquer outro particionador, como se fosse realmente um HD externo. O mais comum é que seja usada uma única partição, formatada em FAT32, o que permite que ele seja acessado tanto no Linux quanto no Windows. Mas nada impede que você formate seu pendrive em ReiserFS ou qualquer outro sistema de arquivos. Lembre-se de que você pode formatar partição usando os comandos "mkfs.ext3", "mkfs.reiserfs" ou "mkfs.vfat" (para FAT32). Uma desvantagem é que o ReiserFS, EXT3, XFS e JFS consomem uma quantidade de espaço relativamente grande para armazenar a estrutura do sistema de arquivos, deixando menos espaço útil disponível. Eles são mais apropriados para formatar HDs e unidades de maior capacidade. Alguns mp3players baratos utilizam um padrão de formatação chamado "superfloppy", onde o dispositivo é formatado diretamente em FAT32 (como se fosse um disquete gigante), ao invés de ser criada uma partição. Nestes casos, você acessa os arquivos diretamente pelo "/dev/sda", ao invés do "/dev/sda1". Se você tiver a curiosidade de particionar o mp3player, criando uma partição e formatando, vai perceber que embora consiga montar e acessar os dados normalmente, o mp3player não vai mais conseguir achar os arquivos das músicas. Para voltar à formatação padrão, use o comando "mkfs.vfat -I /dev/sda" onde o "-I" (i maiúsculo) especifica o tipo de formatação. Outra dica é que, a partir do Kernel 2.6.12 houve uma mudança importante no modo padrão de acesso a pendrives, mp3players e outros dispositivos de armazenamento USB. Para aumentar a segurança da gravação de dados, muitas distribuições montam os drives usando a opção "sync", que sincroniza a gravação dos dados, diminuindo a probabilidade de perder arquivos ao remover o pendrive sem desmontar.

O problema é que na nova versão do driver usb-storage, a opção passou à ser seguida a risca, fazendo com que a cada setor gravado, seja feita uma atualização na tabela de alocação de arquivos da partição. Isto faz com que a velocidade de gravação fique assustadoramente baixa, algo em torno de 40 kb/s nos pendrives USB 1.1 e de 200 a 300 kb/s nos 2.0. A solução é passar a montar os pendrives usando a opção "async", se necessário via terminal, usando o comando: # mount -o async /dev/sda1 /mnt/sda1

Além do problema da lentidão, montar os drives com a opção "sync" pode causar danos depois de algum tempo de uso, pois as freqüentes gravações aos primeiros setores (onde está a tabela de alocação) podem rapidamente exceder o limite de gravações das memórias flash mais baratas, inutilizando o pendrive, como reportado aqui: http://readlist.com/lists/vger.kernel.org/linux-kernel/22/111748.html Note que este "problema" só afeta os Kernels recentes, a partir do 2.6.12. Você só precisa se preocupar com isso se está usando uma versão recente e está tendo o problema de lentidão ao gravar dados no pendrive que citei. Devs e hotplug

Podemos dividir o processo de ativação de um dispositivo no Linux em três passos: em primeiro lugar é carregado o módulo que dá suporte a ele, em seguida é criado um device (como "/dev/sda"), um arquivo especial através do qual ele é acessado e, opcionalmente, é executado algum script ou ação adicional. Ao plugar uma webcam, seria carregado (por exemplo) o módulo "spca5xx" e criado o device "/dev/video0", através do qual os programas podem acessar a câmera. Ao plugar um pendrive seria carregado o módulo "usb-storage" e, assim por diante. Em muitos casos, é preciso carregar mais de um módulo. Para sincronizar o Kpilot com um Palm USB, por exemplo, é preciso carregar os módulos usbserial e visor. Um device é a combinação de dois endereços de Kernel: um major number e um minor number. O major number é usado para indicar uma categoria de dispositivos, enquanto o minor number identifica o dispositivo em si. Por exemplo, o major number "180" é usado em relação a impressoras USB. A primeira impressora conectada recebe o device "/dev/usb/lp0", que é formado pela combinação do major number "180" e o minor number "1". A segunda impressora conectada recebe o device "/dev/usb/lp1", que é formado pelo major number "180" e pelo minor number "2" e assim por diante. Tradicionalmente, o responsável por criar e manter os devices correspondentes a cada dispositivo era o devfs. Ele cumpre a função usando uma abordagem bem simples: o diretório "/dev" contém devices prontos para todos os dispositivos suportados, mesmo que poucos deles estejam realmente em uso. Os devices vão sendo atribuídos conforme novos dispositivos são ativados.

O hotplug entra em cena com a função de detectar novos dispositivos. É ele o responsável por carregar os módulos apropriados, ajustar permissões e executar tarefas diversas sempre que um novo dispositivo é conectado. Sem o hotplug, seu pendrive ainda funciona normalmente, mas você passa a ter o trabalho de ter que carregar os módulos e montar o dispositivo sempre que quiser acessá-lo; sua impressora passa a aparecer no gerenciador de impressão apenas depois que você carrega os módulos apropriados e a configura manualmente através do kaddprinterwizard (ou outro gerenciador), e assim por diante. O hotplug surgiu originalmente como um script responsável por detectar e ativar dispositivos USB conforme eram plugados no micro. Embora tenha um funcionamento interno relativamente simples, o hotplug se mostrou bastante eficiente e passou a ser expandido para assumir a configuração de outros dispositivos. Atualmente, o hotplug não se limita a apenas pendrives, impressoras e câmeras, mas dá suporte a todo tipo de dispositivo firewire, PCMCIA, PCI e SCSI. A partir do Kernel 2.6, o hotplug se tornou um componente padrão do sistema. Ele vem préinstalado em qualquer distribuição que se preze. Mesmo o Slackware que é espartano em termos de ferramentas automáticas de detecção passou a incluí-lo a partir da versão 9.2. Verifique apenas se o serviço "hotplug" está ativo e, se necessário, ative-o com o comando: # /etc/init.d/hotplug start

ou # /etc/rc.d/rc.hotplug start

(no Slackware) Os arquivos de configuração do hotplug estão concentrados dentro da pasta "/etc/hotplug". O hotplug trabalha com os códigos de identificação dos dispositivos, carregando módulos ou executando scripts com funções diversas sempre que dispositivos conhecidos são conectados. Na maioria das distribuições, é incluído o arquivo "/etc/hotplug/usb.distmap", que contém uma grande quantidade de regras pré-configuradas. Você pode incluir regras adicionais usando o arquivo "/etc/hotplug/usb.usermap". A possibilidade mais interessante é executar scripts personalizados quando determinados dispositivos são plugados. Isto permite fazer desde coisas simples, como tocar um som, ou abrir um determinado programa, até incluir scripts mais complexos, que fazem backups automáticos ou outras operações complicadas. Veremos isso com mais detalhes no capítulo sobre shell script. Outro arquivo útil dentro da configuração do hotplug é o "/etc/hotplug/blac klist", onde são especificados módulos que não devem ser carregados automaticamente pelo hotplug. Este arquivo permite solucionar problemas causados por módulos "mal comportados", que causam travamentos ou problemas diversos ao serem carregados. Isto é relativamente comum com relação a módulos proprietários, como os drivers para softmodems e para algumas placas wireless, que em muitas situações chegam a congelar o sistema caso o dispositivo a que dão suporte não esteja presente, ou ao tentarem (incorretamente) ativar um dispositivo similar, mas que não é inteiramente compatível com ele.

Um exemplo é o módulo "Intel537", que dá suporte a modems Intel Ambient. Os modems Intel Ambient "legítimos" possuem um chip DSP grande, com a marca "Ambient" decalcada. Existem muitos modems com chips Intel537AA ou 537EA (fáceis de reconhecer, pois possuem chips bem menores) que não são compatíveis com o driver. Ao tentar carregar o módulo Intel537 com um destes modems instalado, o sistema em muitos casos simplesmente trava, mesmo que o modem nem esteja em uso. Em geral, as distribuições já vêm com o arquivo populado com vários drivers que reconhecidamente possuem problemas. No Kurumin, por exemplo, incluo os módulos dos softmodems, que podem ser carregados manualmente através dos ícones no menu: ltmodem Intel537 pctel slamr Além dos periféricos USB, o hotplug é capaz de detectar outros tipos de dispositivos, que são configurados através de arquivos como o pci.agent, scsi.agent, tape.agent, ieee1394.agent, net.agent e wlan.agent. Todos estes arquivos são na verdade scripts, que são executados durante o boot e conforme o hotplug encontra novos dispositivos. Individualmente, os scripts são rápidos, mas executá-los em massa faz com que a inicialização das versões recentes do hotplug seja relativamente demorada, aumentando o tempo de boot da máquina. Conforme o hotplug cresce em complexidade e incorpora mais scripts, a tendência é que o tempo se torne cada vez maior. Isso é apontado como um dos pontos negativos do hotplug em relação ao udev, que vem ganhando espaço e substituindo-o em muitas distribuições. Entendendo o udev

Recentemente, surgiu um terceiro componente, o udev, que substitui o devfs e assume parte das funções do hotplug, com a opção de se integrar a ele, oferecendo suporte aos scripts e outras personalizações, ou substituí-lo completamente, opção adotada por muitas distribuições. A principal vantagem do udev é que nele é possível definir devices "fixos" para cada periférico. Sua impressora pode passar a receber sempre o device "/dev/printer/epson" e seu pendrive o "/dev/pendrive", mesmo que você tenha outros dispositivos instalados. É possível também executar scripts quando eles são conectados ou removidos, criando um leque muito grande de opções. Os devices são criados conforme os periféricos são conectados, fazendo com que o /dev contenha entrada apenas para os periféricos detectados. No devfs, o diretório "/dev" contém devices para todo tipo de componente que é suportado pelo Kernel, resultando num número absurdo de pastas e devices dentro do diretório. Outra limitação é que os periféricos podem ser associados a devices diferentes, de acordo com a ordem em que são plugados. Digamos que você tenha um pendrive e um HD externo, ambos

USB. Se você plugar o pendrive primeiro, ele será o "/dev/sda", enquanto o HD será o "/dev/sdb". Mas, se você inverter a ordem, o HD é que será o "/dev/sda". Se você tiver um HD serial ATA, então o HD será o "/dev/sda", o pendrive será o "/dev/sdb" e o HD externo será o "/dev/sdc" e, assim por diante. Essa confusão toda torna complicado fazer um script de backup ou qualquer outra coisa que dependa do pendrive estar disponível sempre no mesmo lugar. Outra vantagem do udev é que, por ser escrito em C e ter um funcionamento interno muito mais simples, ele é também mais rápido que o hotplug, o que faz diferença em muitas situações. A parte em que o udev e o hotplug se sobrepõem é com relação a automatização de tarefas. O hotplug suporta o uso de scripts, que são executados sempre que um dispositivo em particular, ou algum dispositivo dentro de uma categoria definida, é plugado. Estes scripts permitem fazer com que seja criado um ícone no desktop ao plugar um pendrive, fazer com que o configurador de impressoras seja aberto quando uma nova impressora USBé conectada, entre inúmeras outras possibilidades. O udev suporta o uso de "regras", que, entre outras coisas, também permitem o uso de scripts. Ele oferece compatibilidade com os scripts do hotplug, mas esta funcionalidade não vem ativada em todas as distribuições. De uma forma geral, o udev está sendo adotado rapidamente em todas as principais distribuições e, em distribuições que o utilizam, é mais recomendado trabalhar com regras do udev do que com scripts do hotplug. Mais adiante, no capítulo sobre shell script, veremos com mais detalhes como escrever tanto scripts para o hotplug quanto regras para o udev. Em algumas distribuições, o udev é configurado de forma a substituir o hotplug completamente, enquanto outras optam por integrar os dois. Nestes casos, o hotplug deixa de ser um serviço separado e passa a ser iniciado juntamente com o serviço "udev": # /etc/init.d/udev start

Uma observação é, que ao contrário do devfs e mesmo do hotplug, o udev é independente do Kernel, ele pode ser instalado, removido e atualizado rapidamente, como qualquer outro programa. Se algum periférico não estiver sendo detectado ou você estiver tendo problemas gerais, experimente atualizar o pacote "udev" a partir do repositório com atualizações para a distribuição em uso. Nas distribuições derivadas do Debian, você pode atualizá-lo via apt-get: # apt-get install udev

Na maior parte das distribuições, você encontrará vários arquivos com regras pré-configuradas dentro do diretório "/etc/udev", destinados a executar funções previamente executadas pelo devfs, hotplug e scripts diversos. O arquivo "/etc/udev/devfs.rules", por exemplo, tem a função de criar os devices de acesso a diversos dispositivos, incluindo as portas seriais e paralelas, mouses PS/2, joysticks e muitos outros periféricos não plug-and-play. O arquivo "/etc/udev/links.conf " permite definir devices adicionais manualmente, de forma que eles sejam recriados a cada boot. Isto é necessário pois no udev o diretório /dev é dinâmico, fazendo que dispositivos não utilizados sejam perdidos a cada reboot.

Uma configuração comum, é adicionar regras que criam os devices utilizados pelo VMware, de forma que eles não se percam ao reiniciar, como em: M vmmon --mode 666 c 10 165 M vmnet0 --mode 666 c 119 0 M vmnet1 --mode 666 c 119 1 M vmnet8 --mode 666 c 119 8 As regras permitem também criar links. Se você quer que seja criado o link "/dev/modem", apontando para o modem que está na porta "/dev/ttyS3", adicione: L modem /dev/ttyS3 A as letras "L" e "M" no início das linhas indicam o tipo de dispositivo que será criado. O "L" indica que estamos falando de um dispositivo de caracteres (que incluem modems, palms e tudo que é visto pelo sistema como um dispositivo serial) e o "M" indica um dispositivo de bloco, como uma partição num HD ou pendrive, ou ainda uma interface de rede virtual, como no caso do VMware. O "--mode" indica as permissões de acesso, enquanto os dois números depois do "c" indicam o major e minor number, os mesmos endereços que são fornecidos ao criar o dispositivo manualmente usando o comando "mknod". Renomeando interfaces de rede com o udev

Os nomes atribuídos às placas de rede no Linux sempre causarem uma certa dose de transtornos para quem utiliza duas ou mais placas, sobretudo se forem duas placas com o mesmo chipset. Tradicionalmente, as placas de rede recebem nomes como "eth0" e "eth1", que são atribuídos conforme o sistema detecta as placas durante o boot. Isso significa que, de acordo com a distribuição usada, as placas podem trocar de posição, sem falar que é comum que os nomes troquem ao reiniciar a máquina, fazendo com que a placa eth1 passe a ser vista como eth0 e vice-versa, quebrando toda a configuração da rede. Com a introdução do udev, as trocar de nomes ao reiniciar se tornaram ainda mais comuns. Cheguei a ver a placa wireless de um notebook Centrino trocar de nome três vezes em três reboots: primeiro eth2, depois eth1, em seguida eth0 e novamente eth1. Antigamente, a solução para o problema era criar aliases para as placas de rede no arquivo "/etc/modules.conf", relacionando cada interface ao driver usado, como em: alias eth0 via-rhine alias eth1 8139too Entretanto, os aliases não ajudavam muito em casos em que eram utilizadas duas placas iguais, sem falar que esta configuração não funciona mais em distribuições recentes, que utilizam o udev. Nelas, podemos atribuir os nomes de forma muito mais confiável adicionando regras do udev.

As regras podem ser criadas com base no endereço MAC de cada placa de rede (a forma mais confiável, já que o MAC só muda ao trocar de placa), ou através do módulo usado por ela. Você pode descobrir o endereço MAC das placas rapidamente através do comando "ifconfig". Para descobrir o módulo, você pode fazer uma pesquisa no Google, ou usar o comando "ethtool -i ", como em: # ethtool -i eth1

driver: ipw2200 version: git-1.1.1 firmware-version: ABG:9.0.2.6 (Mar 22 2005) bus-info: 0000:01:05.0 O ethtool não vem instalado por padrão em todas as distribuições, mas normalmente está disponível como pacote extra nos repositórios. Nas distribuições derivadas do Debian você pode instala-lo via apt-get: apt-get install ethtool. Agora que já sabe o MAC e o driver de cada uma das placas, crie o arquivo "/etc/udev/rules.d/z99-networ k.rules", onde vão as regras. Para relacionar com base no endereço MAC, adicione linhas como: SUBSYSTEM=="net", SYSFS{address}=="00:15:00:4b:68:db", NAME="ipw0" Para relacionar com base no módulo usado (o que só funciona ao usar duas placas diferentes), use regras como: SUBSYSTEM=="net", DRIVER=="ipw2200", NAME="ipw0" O udev lê todos os arquivos dentro da pasta "/etc/udev/rules.d" e processa todas as regras contidas neles. A opção SUBSYSTEM=="net" especifica que a regra só se aplica a placas de rede. Usamos em seguida a opção "SYSFS{address}==" ou "DRIVER==" para especificar a informação que permite ao sistema diferenciar a placa desejada das demais instaladas no sistema. Finalmente, a opção "NAME=" especifica o nome que passará a ser usado pela placa. Imagine que você tem uma placa Realtek e uma SiS900. Para atribuir osnomes baseado no endereço MAC, você usaria as regras: SUBSYSTEM=="net", SYSFS{address}=="00:E0:7D:9B:F9:04", NAME="rtl0" SUBSYSTEM=="net", SYSFS{address}=="00:11:D8:41:52:78", NAME="sis0" Ao atribuir com base no módulo, você usaria as regras: SUBSYSTEM=="net", DRIVER=="8139too", NAME="rtl0" SUBSYSTEM=="net", DRIVER=="sis900", NAME="sis0" Nos exemplos, usei "ipw0", "rtl0" e "sis0" como nomes para as placas, mas você pode atribuir qualquer nome. O único porém é que algumas ferramentas de configuração de rede não encontram as placas caso elas usem nomes fora do padrão. Neste caso, você pode usar nomes

mais comuns, como "eth2" e "eth3", desde que diferentes dos que as placas usavam anteriormente, para evitar situações onde o udev possa tentar atribuir o mesmo nome às duas placas. Para que a alteração entre em vigor, é necessário recarregar os módulos das placas, ou simplesmente reiniciar o micro. Naturalmente, você precisará reconfigurar a rede, mas em compensação, só precisará fazer isso uma vez ;).

Fazendo backup e recuperando a MBR e tabela de partições Ao comprar um novo HD, você precisa primeiro formatá-lo antes de poder instalar qualquer sistema operacional. Existem vários programas de particionamento, como o qtparted, gparted, cfdisk e outros. Os programas de particionamento salvam o particionamento na tabela de partição, gravada no início do HD. Esta tabela contém informações sobre o tipo, endereço de início e final de cada partição. Depois do particionamento, vem a formatação de cada partição, onde você pode escolher o sistema de arquivos que será usado em cada uma (ReiserFS, EXT3, FAT, etc.). Ao instalar o sistema operacional, é gravado mais um componente: o gerenciador de boot, responsável por carregar o sistema durante o boot. Tanto o gerenciador de boot quanto a tabela de particionamento do HD são salvos no primeiro setor do HD, a famosa trilha MBR, que contém apenas 512 bytes. Destes, 446 bytes são reservados para o setor de boot, enquanto os outros 66 bytes guardam a tabela de partição. Ao trocar de sistema operacional, você geralmente subscreve a MBR com um novo gerenciador de boot, mas a tabela de particionamento só é modificada ao criar ou deletar partições. Caso por qualquer motivo, os 66 bytes da tabela de particionamento sejam subscritos ou danificados, você perde acesso a todas as partições do HD. O HD fica parecendo vazio, como se tivesse sido completamente apagado. Para evitar isso, você pode fazer um backup da trilha MBR do HD. Assim, você pode recuperar tudo caso ocorra qualquer eventualidade. Para fazer o backup, use o comando: # dd if=/dev/hda of=bac kup.mbr bs=512 count=1 O comando vai fazer uma cópia dos primeiros 512 bytes do "/dev/hda" no arquivo "backup.mbr". Se o seu HD estivesse instalado na IDE secundária (como master), ele seria visto pelo sistema como "/dev/hdc". Basta indicar a localização correta no comando. Você pode salvar o arquivo num disquete ou pendrive, mandar para a sua conta do gmail, etc. Caso no futuro, depois da enésima reinstalação do Windows XP, vírus, falha de hardware ou de um comando errado a tabela de particionamento for pro espaço, você pode dar boot com o CD do Kurumin e regravar o backup com o comando: # dd if=backup.mbr of=/dev/hda

Lembre-se de que o backup vai armazenar a tabela de particionamento atual. Sempre que você reparticionar o HD, não se esqueça de atualizar o backup. Usando o Gpart

Caso o pior aconteça, a tabela de particionamento seja perdida e você não tenha backup, ainda existe uma esperança. O Gpart é capaz de recuperar a tabela de partição e salvá-la de volta no HD na maioria dos casos. Você pode executá-lo dando boot pelo CD do Kurumin, ou baixá-lo no: http://www.stud.uni-hannover.de/user/76201/gpart/#download. Baixe o "gpart.linux " que é o programa já compilado. Basta marcar a permissão de execução para ele: # chmod +x gpart.linux Nas distribuições derivadas do Debian, você pode instalá-lo pelo apt-get: # apt-get install gpart

Execute o programa indicando o HD que deve ser analisado: # ./gpart.linux /dev/hda (ou simplesmente "gpart /dev/hda" se você tiver instalado pelo apt-get) O teste demora um pouco, pois ele precisará ler o HD inteiro para determinar onde começa e termina cada partição. No final, ele exibe um relatório com o que encontrou: Primary partition(1) type: 007(0x07)(OS/2 HPFS, NTFS, QNX or Advanced UNIX) size: 3145mb #s(6442000) s(63-6442062) chs: (0/1/1)-(1023/15/63)d (0/1/1)-(6390/14/61)r Primary partition(2) type: 131(0x83)(Linux ext2 filesystem) size: 478mb #s(979964) s(16739730-17719693) chs: (1023/15/63)-(1023/15/63)d (16606/14/1)-(17579/0/62)r Primary partition(3) type: 130(0x82)(Linux swap or Solaris/x86) size: 478mb #s(979896) s(17719758-18699653) chs: (1023/15/63)-(1023/15/63)d (17579/2/1)-(18551/3/57)r Se as informações estiverem corretas, você pode salvar a tabela no HD usando o parâmetro "W": # gpart -W /dev/hda /dev/hda Veja que é preciso indicar o HD duas vezes. Na primeira você indica o HD que será vasculhado e em seguida em qual HD o resultado será salvo. Em casos especiais, onde você tenha dois HDs

iguais, por exemplo, você pode gravar num segundo HD, com em: "gpart -W /dev/hda /dev/hdc". O gpart não é muito eficiente em localizar partições extendidas (hda5, hda6, etc.). Em boa parte dos casos ele só vai conseguir identificar as partições primárias (hda1, hda2, hda3 e hda4). Nestas situações, você pode usar o cfdisk ou outro programa de particionamento para criar manualmente as demais partições (apenas crie as partições e salve, não formate!). Se você souber indicar os tamanhos aproximados, principalmente onde cada uma começa, você conseguirá acessar os dados depois. Usando o Testdisk

Outra ferramenta "sem preço" para recuperação de partições é o Testdisk. Embora a função seja a mesma, ele utiliza um algoritmo bastante diferente para detectar partições, o que faz com que ele funcione em algumas situações em que o Gpart não detecta as partições corretamente e vice-versa. Por isso vale a pena ter ambos na caixa de ferramentas. Lembre-se que ambos são capazes de recuperar partições apenas enquanto as informações não são subscritas. Se você acabou de apagar a sua partição de trabalho, é bem provável que consiga recuperá-la, mas se o HD já tiver sido reparticionado e formatado depois do acidente, as coisas ficam muito mais complicadas. Sempre que um acidente acontecer, pare tudo e volte a usar o HD só depois de recuperar os dados. O Testdisk permite recuperar desde partições isoladas (incluindo as extendidas), até toda a tabela de partição, caso o HD tenha sido zerado. Ele suporta todos os principais sistemas de arquivos, incluindo FAT16, FAT32, NTFS, EXT2, EXT3, ReiserFS, XFS, LVM e Linux Raid. A página oficial é a http://www.cgsecurity.org/testdisk.html onde, além da versão Linux, você encontra versões para Windows, DOS e até para o Solaris. Embora não seja exatamente um utilitário famoso, o Testdisk é incluído em muitas distribuições. Nos derivados do Debian, você pode instalá-lo via apt-get: # apt-get install testdisk

Para instalar a versão em código fonte, além dos compiladores básicos (veja mais detalhes no capítulo 3), é necessário ter instalado o pacote "ncurses-dev" ou "libncurses-dev". A instalação propriamente dita é feita usando a receita tradicional: descompactar o arquivo, acessar a pasta criada e rodar os comandos "./configure", "make" e "make install". Vamos a um exemplo prático de como recuperar duas partições deletadas "acidentalmente". Onde o cfdisk está mostrando "Free Space" existem na verdade as partições "/dev/hda2" e "/dev/hda3", que removi previamente:

Comece chamando o Testdisk como root: # testdisk

Na tele inicial, selecione o HD que será analisado, acesse a opção "Analyse" e em seguida "Proceed", para iniciar a varredura do disco. O Testdisk verifica a tabela de partições atual e em seguida pesquisa em todos os setores onde podem existir informações sobre outras partições que não constem na tabela principal. Veja que, apenas com o teste rápido, ele já conseguiu localizar as duas partições que haviam sido deletadas:

Pressionando a tecla "P" você pode ver os dados dentro da partição, para ter certeza que os arquivos estão lá (a versão disponível no apt-get não consegue mostrar arquivos dentro de partições ReiserFS, mas a recuperação funciona normalmente).

Nos raros casos onde ele localize a partição, mas identifique incorretamente o sistema de arquivos, use a opção "T" para indicar o correto. Depois de checar se o particionamento detectado está correto, pressione "Enter" mais uma vez e você chega à tela final, onde você pode salvar as alterações, usando a opção "Write". Reinicie o micro e monte a partição para checar os dados. Caso a lista não exiba a partição que você está procurando, use a opção " Search" no lugar do Write. Isto ativa o teste mais longo, onde ele vasculha todos os setores do HD em busca de partições deletadas. Este segundo teste demora alguns minutos e, num HD com bastante uso, pode retornar uma longa lista de partições que foram criadas e deletadas durante a vida útil do HD. Neste caso, preste atenção para recuperar a partição correta.

Todas as partições listadas aqui parecem com o atributo "D", que significa que a partição foi deletada. Para recuperar uma partição, selecione-a usando as setas para cima/baixo e use a seta para a direita para mudar o atributo para "*" (se ele for uma partição primária e bootável, como o drive C: no Windows), "P" se ela for uma partição primária ou "L" se ela for uma partição lógica. Lembre-se de que. no Linux, as partições de 1 a 4 são primárias e de 5 em diante são extendidas. É possível também adicionar uma partição manualmente, caso você saiba os setores de início e final, mas isso raramente é necessário.

Pressione "Enter" mais uma vez e ele mostra uma tela de confirmação, com a tabela de particionamento alterada que será salva no disco. Use o "Write" para salvar ou volte à tela inicial para começar novamente em caso de erros. Tenha em mente que o tamanha da partição é reportado de acordo com o número de setores de 512 bytes. Uma partição de 5 GB tem pouco mais de 10 milhões de setores. O ideal é que você faça todo o processo usando um live-CD. O Kurumin vem com o Testdisk pré-instalado a partir da versão 6.0 e ele pode ser encontrado também nas versões recentes do Knoppix, PLD e Ultimate Boot CD. Depois de recuperar qualquer partição, é importante checá-la usando o utilitário apropriado, para que qualquer problema dentro da estrutura do sistema de arquivos seja corrigido.

Recuperando partições danificadas Durante a década de 70, vários utilitários foram desenvolvidos para fazer backup de arquivos armazenados em servidores Linux. Os computadores da época eram muito limitados, por isso os utilitários precisavam ser simples e eficientes, e deveriam existir meios de agendar os backups para horários de pouco uso das máquinas. Sugiram então utilitários como o tar e o gzip e mais tarde ferramentas como o rsync. Estes utilitários eram tão eficientes que continuaram sendo usados ao longo do tempo. Por incrível que possa parecer, são usados sem grandes modificações até os dias hoje. Naturalmente, existem muitos utilitários amigáveis de backup, como o Amanda (para servidores) e o Konserve (um utilitário mais simples, voltado para usuários domésticos). Mas, internamente, eles continuam utilizando como base o o dump, tar, gzip e outros trigenários. Mais incrível ainda, é que estes utilitários possuem uma penetração relativamente pequena. A maior parte dos backups ainda é feita através de scripts personalizados, escritos pelo próprio administrador. E, novamente, estes scripts utilizam o tar, gzip, rsync e outros.