sistema operacional Conhecendo o Sistema Operacional Linux

[Love_Demi_s2 6]

As distribuições Linux sempre vêm de fábrica com suporte a muitos dispositivos, em geral quase tudo é detectado automaticamente. Os maiores problemas em geral são os softmodems que precisam ser instalados manualmente depois da instalação. O mesmo se aplica se você tiver uma placa de vídeo da nVidia ou da ATI ou outros dispositivos 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/. Estes módulos são a coisas 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 "net" contém drivers para placas de rede, a pasta "ieee1394" agrupa os que dão suporte a controladoras e dispositivos firewire e assim por diante.

 

01

 

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. 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 Kernels bem completos 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. Estes módulos geralmente são pequenos, um conjunto completo com os módulos para todo tipo de dispositivos geralmente ocupa de 30 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, 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, criar 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 onde o 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 pra 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, o que é bastante improvável já que o Kernel do Linux é atualizado quase que diariamente.

 

Se você usar uma distribuição popular, Mandrake, Red Hat, SuSe, etc. é provável que você já encontre um driver pré-compilado. Neste casos você só vai precisar instalar um pacote RPM ou executar um arquivo de instalação. Em outros casos você encontrará apenas um arquivo genérico ainda não compilado.

 

Nestes casos o instalador se encarregará de compilar um módulo sob medida para o Kernel que estiver em uso. Como ele não tem como adivinhar qual distribuição ou Kernel você está utilizando você precisará ter instalados dois pacotes que acompanham qualquer distribuição: kernel-source e kernel-headers. No Mandrake por exemplo você pode instalá-los usando os comandos "urpmi kernel-source" e "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.

 

 

 

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 tentar entender o processo de boot do sistema.

Kernel

 

Para compilar o código fonte do Kernel, era necessário usar o Minix, outro sistema baseado em Unix que na época era 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 bootar no próprio Linux e compilar os demais programas a partir dele mesmo. Isso tudo muito antes das primeiras distribuições Linux começarem a surgir no horizonte.

 

Este procedimento e 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, onde 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 podem ser compilados para rodar em várias plataformas diferentes. O código fonte do Kernel, disponível no

É necessário se cadastrar para acessar o conteúdo.

• Entre
• ou
• Cadastre-se

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/" .

 

É um trabalho relativamente complexo e tedioso, muitas coisas precisam ser ajustadas e é preciso 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 Compaq 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:

 

02

 

Você pode entender melhor sobre como isto funciona instalando o "Linux from Scratch", uma distribuição Linux toda compilada manualmente a partir dos pacotes com código fonte:

É necessário se cadastrar para acessar o conteúdo.

• Entre
• ou
• Cadastre-se

 

É 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 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 determinadas 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), o que sai muito mais barato do que investir em um sistema próprio e diferenciar-se das demais investindo nos outros componentes do pacote.

 

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 os demais componentes do micro, dividindo os recursos disponíveis entre os programas. Todos os demais programas, desde os aplicativos de linha de comando, até os aplicativos gráficos rodam sobre o Kernel.

 

Por exemplo, imagine 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 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á-la à placa de som. Quando é preciso ajustar o volume, seu programa acessa o dispositivo "/dev/mixer" e assim por diante.

 

Naturalmente uma SB 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 dispositivos.

 

Driver em inglês significa "motorista". 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.

 

Quando você executa o comando "cat arquivo.txt" por exemplo, 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 módulo responsável pelo suporte ao controlador de memória da placa mãe.

 

No caso de programas grandes, a memória RAM pode ficar lotada, obrigando o Kernel a usar o sub-sistema de memória virtual para gravar as informações 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.

 

04

 

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.

 

 

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 ao arroz com feijão, como HD, placa de vídeo e drive de disquetes.

 

Como tempo foi sendo adicionado suporte a muitos outros dispositivos: placas de som, placas de rede, controladoras SCSI, etc. O fato do Kernel ser monolítico começou a atrapalhar bastante.

 

Se você compilasse um Kernel enxuto e esquecesse de habilitar o suporte à 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 sí é 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ódulo.

 

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

 

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

 

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 como sda1)

 

Um segundo arquivo, o /etc/modules.conf (ou /etc/conf.modules>, 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.x.xx/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 automaticamente durante o boot, quando necessário.

 

2- Se o suporte a algo essencial nas etapas iniciais do boot não está carregado 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 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.

 

 

 

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, CDROM, disquete, rede, ou o 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 memória real (os primeiros 640 KB da memória RAM) e 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 modernos 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 e fica descompactado neste espaço reservado (chamado de shadow RAM) durante o uso.

 

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 procura-los. Fazendo com que exista um enorme contingente de placas bugadas por aí, com problemas no ACPI, DMA e outros 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:

É necessário se cadastrar para acessar o conteúdo.

• Entre
• ou
• Cadastre-se

 

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. Lembre-se que o MBR propriamente dito ocupa um único setor do HD, apenas 512 bytes. 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 e 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á.

 

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 sistema 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 dalí, 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.

 

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 precisa ler o arquivo dentro da partição.

 

Isto tudo funciona por que 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 leêm 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 que são executados nesta etapa são:

 

keymap.sh: Carrega o layout do teclado que será usado no modo texto. Você não gostaria que seu teclado estivesse 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

 

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.

 

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.

 

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 a rede, nem nenhum 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, montar a partição onde o sistema está instalado e corrigir o problema a partir daí.

 

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.

 

Por exemplo, 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.

 

 

 

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, Mandrake 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 comandar 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.

 

A pasta /etc/init.d contém scripts para quase todos os servidores 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.

 

05

 

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 o que está 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 no Kurumin) ou na pasta /etc/rc3.d (runlevel 3)

 

06

 

Os números antes dos nomes dos serviços dentro da pasta /etc/rc5.d determinam a ordem com que eles vão ser executados. Você vai querer que o firewall seja sempre ativado antes do Samba por exemplo.

 

O "S" (start) indica que o serviço vai ser inicializado. A partir daí o sistema vai inicializando um por vez, começando com 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:

 

 

# ln -s /etc/init.d/samba /etc/rc5.d/S20samba

 

 

 

ou

 

 

# ln -s /etc/init.d/ssh /etc/rc5.d/S21ssh

 

 

 

Existe um utilitário de modo texto, do Debian, que facilita esta tarefa, o rcconf:

 

07

 

No Fedora, Mandrake 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

 

# chkconfig ssh off (desativa)

 

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 infraestrutura 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ê chama-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, etc.

 

08

Isto acontece por que 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, WindowMaker, 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 já abrir o X durante a inicialização, finalmente carregamos o conjunto completo, com o X e algum gerenciador de janelas rodando sobre ele. Finalmente podemos usar o PC ;-)

 

O Xfree utiliza uma arquitetura cliente-servidor, onde o X em sí 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 (com o comando "ssh -X IP_da_maquina") e começar a chamar os programas desejados ou mesmo 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 e inicializar o X com o comando "X -query IP_da_maquina" no PC cliente.

[renne20 0]

bom topico mas acho que voce podia ter lido e resumido que muitas pessoas e claro nao vao ler tudo isso

[kitneguin 0]

Acho que voce poderia melhor formatalo

variando as cores

essa fonte tambem nao curto muito...

muito grande poderia resumir

 

Vc tem uma sign

pedindo para vc ser Geek mais comete estes erros basicos

=D

Melhore ai manolo

[Zaphey 2]

Interessante o conteúdo, mas a formatação está horrível!

Tente arrumar um pouco, não precisa deixar nada Restart, mas não tudo em negrito e de uma cor só.

Fora isso o conteúdo é bom.

 

Abraços!

[Love_Demi_s2 6]

Obg Pelas Dicas e como o Post ja esta feito e nao tenho tempo nao poderei resumir eu pelo menos vou alternar as cores e a fontes obg

 

Love_Demi_s2 For Geek