Conteúdo:
Primeiro de tudo, bem-vindo ao Gentoo. Você está prestes a entrar no mundo da personalização e da performance. Na instalação do Gentoo, isto torna-se claro várias vezes -- você pode escolher o quanto você quer compilar pessoalmente, como instalar o Gentoo, qual gerenciador de registros de sistema você quer, etc.
O Gentoo é uma meta-distribuição moderna e veloz com um desenho limpo e flexível. O Gentoo foi construído com software livre e não esconde de seus usuários o que está sob o capô. O Portage, sistema de gerenciamento de pacotes usado pelo Gentoo, é escrito em Python, o que significa que você pode facilmente ver e modificar o código-fonte. O sistema de gerenciamento de pacotes do Gentoo usa código-fonte (embora também ofereça suporte a pacotes pré-compilados) e a configuração do Gentoo é toda feita com arquivos de texto normais. Em outras palavras, abertura em todos os pontos.
É muito importante que você entenda que poder é o que movimenta o Gentoo. Nós tentamos não forçar nossos usuários a fazer nada e dar o poder a você para fazer as escolhas que deseja. Se você acha que uma mudança deve ser feita, por favor relate um bug.
Como é a estrutura da instalação?
O Gentoo Linux vem com duas versões de um instalador fácil de usar. Um instalador baseado em GTK+ (para uso em um ambiente de X) e um instalador baseado em Dialog para uso no console. O Capítulo 3 do manual lida com o instalador baseado em GTK+ e o 4 é para o baseado em Dialog.
Quando você tem uma certa escolha, tentamos da melhor forma possível explicar os prós e contras de cada opção. Continuaremos então com uma escolha padrão, identificada por "Padrão: " no título. As outras possibilidades são identificadas por "Alternativa: ". Não pense que o padrão é o que recomendamos. É simplesmente a que acreditamos que a maioria dos usuários vai usar.
Eventualmente será oferecido um passo opcional. Esses passos são marcados como "Opcional: " e portanto não são necessários para instalar o Gentoo. No entanto, alguns passos opcionais dependem de decisões anteriores que você fez. Vamos informá-lo quando isso acontecer, tanto quando você fizer a decisão, quanto logo antes de descrevermos o passo opcional.
Você pode instalar o Gentoo de muitas formas diferentes. Você pode baixar e instalar a partir dos nossos CDs de instalação, a partir de uma distribuição já existente em seu disco, a partir de um CD inicializável (como o Knoppix), inicializando pela rede, a partir de um disquete de recuperação, etc...
Este documento cobre a instalação usando um CD de instalação do Gentoo Linux, um CD carregável que contém tudo que você precisa para configurar e ter o Gentoo Linux funcionando. Existem dois tipos de CDs de instalação, o CD de instalação e o LiveCD do instalador. O CD de instalação é um ambiente mínimo que contém apenas os pacotes necessários para a instalação do Gentoo Linux. O LiveCD é um ambiente Gentoo Linux completo e pode ser usado para múltiplas tarefas, uma delas sendo instalar o Gentoo Linux. O LiveCD ainda não está disponível para todas arquiteturas. Se sua arquitetura não tiver um LiveCD, este documento irá fazer referência o CD de instalação universal para você.
Este método de instalação, todavia, não faz uso imediato das últimas versões disponíveis dos pacotes; se você quer isso, você deve ver as instruções de instalação dentro de nossos Manuais do Gentoo Linux.
Para ajuda com outros métodos de instalação, por favor leia nosso Guia de instalação alternativa. Nós também oferecemos um documento de Dicas & Truques de instalação do Gentoo que também pode ser uma leitura útil. Se você acha que as instruções de instalação atuais são muito elaboradas, sinta-se livre para usar nosso Guia de instalação rápida disponível em nossos Recursos de documentação se sua arquitetura tiver tal documento disponível.
Se você encontrar algum problema na instalação (ou na documentação de instalação), por favor verifique a errata de nosso Projeto de Engenharia de Lançamentos do Gentoo, visite nosso sistema de rastreamento de bugs e verifique se o bug é conhecido. Se não existir, crie um novo registro de bug para que possamos cuidar dele. Não tenha medo dos desenvolvedores que receberem os (seus) bugs -- normalmente eles não comem pessoas.
Note também que, apesar de a documentação que você está lendo agora seja específica por arquitetura, conterá referências para outras arquiteturas também. Isto deve-se ao fato de que grandes partes do Manual do Gentoo usam comandos e códigos que são comuns para todas as arquiteturas (para evitar duplicação de esforços e desgastes dos esforços de desenvolvimento). Nós tentamos manter isso ao mínimo para evitar confusões.
Se você estiver em dúvida com um problema de usuário (algum erro que você cometeu apesar de ter lido atenciosamente a documentação) ou um problema de software (algum erro que nós cometemos apesar de ter testado atenciosamente a instalação e a documentação), sinta-se à vontade para juntar-se ao #gentoo ou #gentoobr em irc.freenode.net. Obviamente você não precisa dessas dúvidas para ser bem-vindo lá :)
Se você tiver uma questão sobre o Gentoo, verifique nossas Perguntas mais freqüentes, disponíveis na Documentação do Gentoo. Você também pode ver as FAQs (Perguntas mais freqüentes) nos nossos fóruns. Se não conseguir encontrar a resposta lá, pergunte no #gentoo (inglês), ou no #gentoobr, nosso canal IRC na irc.freenode.net. Sim, muitos de nós são loucos que entram no IRC :-)
1.b. Instalação rápida usando a Gentoo Reference Platform
O que é a Gentoo Reference Platform?
A Gentoo Reference Platform (plataforma de referência do Gentoo), doravante GRP, é um snapshot de pacotes pré-construídos que usuários (isto significa você!) podem usar durante a instalação do Gentoo para acelerar o processo de instalação. O GRP consiste de todos pacotes necessários para ter uma instalação do Gentoo totalmente funcional. Eles não são apenas os que você precisa para ter uma instalação de base rapidamente, mas também construções mais longas (como xorg-x11, GNOME, OpenOffice, Mozilla, ...) estão disponíveis como pacotes GRP.
No entanto, esses pacotes pré-construídos não são mantidos durante o ciclo de vida da distribuição do Gentoo. São snapshots lançados em cada lançamento do Gentoo e tornam possível ter um ambiente funcional em pouco tempo. Você pode então atualizar seu sistema no background enquanto trabalha em seu ambiente Gentoo.
Como o Portage lida com pacotes GRP
Sua árvore do Portage - a coleção de ebuilds (arquivos que contêm todas instruções de compilação, dependências, etc...) - devem ser sincronizadas com o conjunto de GRP: as versões das ebuilds disponíveis e seus pacotes de GRP acompanhantes devem bater.
Por este motivo, você só pode tirar proveito de pacotes GRP que o Gentoo fornece durante o método de instalação atual. O GRP não está disponível para aqueles interessados em fazer uma instalação usando as últimas versões de todos pacotes disponíveis.
Nem todas arquiteturas oferecem pacotes GRP. Isto não significa que GRP não é suportado em outras arquiteturas, mas que não temos os recursos para construir e testar os pacotes GRP.
No momento nós oferecemos pacotes GRP para as seguintes arquiteturas:
Se sua arquitetura (ou sub-arquitetura) não estiver na lista, você não pode optar por uma instalação GRP.
Agora que a introdução terminou, vamos continuar com Carregando o CD de instalação universal/LiveCD de instalação..
Antes de começar, primeiro iremos listar que requisitos de hardware você precisa para instalar o Gentoo com sucesso em sua máquina.
| CPU | i686 ou mais novo |
| Memória | 128 MB |
| Espaço em disco | 1.5 GB (menos o espaço de swap) |
| Espaço de swap | No mínimo 256 MB |
2.b. O LiveCD do instalador do Gentoo Linux
O Gentoo Linux pode ser instalado usando um arquivo de tarball de stage3. Esta tarball é um arquivo que contém um ambiente mínimo, a partir do qual você pode instalar o Gentoo Linux em seu sistema.
Instalações usando um arquivo de tarball de stage1 ou stage2 não são documentadas no Manual do Gentoo - por favor leia as Perguntas freqüentes sobre o Gentoo para mais informações.
O LiveCD do instalador do Gentoo Linux
Um LiveCD é um CD carregável que contém um ambiente Gentoo auto-suficiente. Eles permitem que você carregue o Linux a partir do CD. Durante o processo de inicialização seu hardware é detectado e os módulos apropriados são carregados. Eles são mantidos pelos desenvolvedores do Gentoo.
Os dois CDs de instalação que nós fornecemos atualmente são:
2.c. Baixe, grave e carregue o LiveCD do instalador do Gentoo Linux
Baixando e gravando o LiveCD do instalador do Gentoo Linux
Você pode baixar os LiveCDs do isntalador de um de nossos servidores. Eles estão localizados no diretório releases/x86/2006.0/livecd.
Dentro deste diretório você irá encontrar um arquivo ISO. Ele é uma imagem completa de CD que você pode gravar em CD-R.
Depois de baixar o arquivo, você pode verificar sua integridade para ver se está corrupto ou não:
Para obter nossa chave pública usando a aplicação GnuPG, rode o seguinte comando:
Listagem de código 3.1: Obtendo a chave pública |
$ gpg --keyserver subkeys.pgp.net --recv-keys 17072058
|
Agora verifique a assinatura:
Listagem de código 3.2: Verifique a assinatura criptográfica |
$ gpg --verify <arquivo de assinatura> <iso baixada>
|
Para gravar ISO(s) baixada(s), você deve selecionar raw-burning. Como fazer isto depende do programa. Iremos discutir o cdrecord e o K3B aqui; mais informações podem ser encontradas em nosso Guia de perguntas freqüentes do Gentoo.
Carregando o LiveCD do instalador
Importante: Leia esta subseção inteira antes de continuar, já que você provavelmente não terá a oportunidade lê-la antes de fazer as coisas depois. |
Uma vez que você gravou seu LiveCD, está na hora de carregá-lo. Tire todos CDs de suas bandejas, reinicie seu sistema e entre na BIOS. Isto normalmente se faz apertando DEL, F1 ou ESC, dependendo da sua BIOS. Dentro da BIOS, mude a ordem de inicialização para que seu CD-ROM seja lido antes do disco-rígido. Isto normalmente é encontrado em "CMOS Setup". Se você não fizer isso, seu sistema irá simplesmente reiniciar a partir do disco-rígido, ignorando o CD-ROM.
Agora coloque o LiveCD do dispositivo de CD-ROM e reinicie. Você deve ver um prompt de inicialização. Nesta tela, você pode apertar Enter para começar o processo de inicialização com as opções de inicialização padrão, ou carregar o CD de instalação com opções de inicialização personalizadas, especificando um kernel seguido das opções de inicialização e apertando Enter.
Especificando um kernel? Sim, nós fornecemos alguns kernéis em nosso LiveCD. O padrão é o gentoo. Outros kernéis são para necessidades específicas de hardware e os variantes de -nofb que não usam framebuffer.
Abaixo você irá encontrar uma breve lista de kernéis disponíveis:
| Kernel | Descrição |
| gentoo | kernel 2.6 padrão com suporte para CPUs múltiplas |
| gentoo-nofb | Igual ao gentoo, mas sem framebuffer |
| memtest86 | Teste erros na sua memória RAM local |
Você pode também fornecer opções de kernel. Elas representam ajustes opcionais que você pode (des)ativar conforme quiser. A lista seguinte é a mesma que você recebe quando você aperta de F2 até F7 na tela de início.
Listagem de código 3.3: Opções disponíveis para passar ao kernel de sua escolha |
Opções de hardware: acpi=on This loads support for ACPI and also causes the acpid daemon to be started by the CD on boot. This is only needed if your system requires ACPI to function properly. This is not required for Hyperthreading support. acpi=off Completely disables ACPI. This is useful on some older systems, and is also a requirement for using APM. This will disable any Hyperthreading support of your processor. console=X This sets up serial console access for the CD. The first option is the device, usually ttyS0 on x86, followed by any connection options, which are comma separated. The default options are 9600,8,n,1. dmraid=X This allows for passing options to the device-mapper RAID subsystem. Options should be encapsulated in quotes. doapm This loads APM driver support. This requires you to also use acpi=off. dobladecenter This adds some extra pauses into the boot process for the slow USB CDROM of the IBM BladeCenter. dopcmcia This loads support for PCMCIA and Cardbus hardware and also causes the pcmcia cardmgr to be started by the CD on boot. This is only required when booting from a PCMCIA/Cardbus device. doscsi This loads support for most SCSI controllers. This is also a requirement for booting most USB devices, as they use the SCSI subsystem of the kernel. hda=stroke This allows you to partition the whole hard disk even when your BIOS is unable to handle large disks. This option is only used on machines with an older BIOS. Replace hda with the device that is requiring this option. ide=nodma This forces the disabling of DMA in the kernel and is required by some IDE chipsets and also by some CDROM drives. If your system is having trouble reading from your IDE CDROM, try this option. This also disables the default hdparm settings from being executed. noapic This disables the Advanced Programmable Interrupt Controller that is present on newer motherboards. It has been known to cause some problems on older hardware. nodetect This disables all of the autodetection done by the CD, including device autodetection and DHCP probing. This is useful for doing debugging of a failing CD or driver. nodhcp This disables DHCP probing on detected network cards. This is useful on networks with only static addresses. nodmraid Disables support for device-mapper RAID, such as that used for on-board IDE/SATA RAID controllers. nofirewire This disables the loading of Firewire modules. This should only be necessary if your Firewire hardware is causing a problem with booting the CD. nogpm This disables gpm console mouse support. nohotplug This disables the loading of the hotplug and coldplug init scripts at boot. This is useful for doing debugging of a failing CD or driver. nokeymap This disables the keymap selection used to select non-US keyboard layouts. nolapic This disables the local APIC on Uniprocessor kernels. nosata This disables the loading of Serial ATA modules. This is useful if your system is having problems with the SATA subsystem. nosmp This disables SMP, or Symmetric Multiprocessing, on SMP-enabled kernels. This is useful for debugging SMP-related issues with certain drivers and motherboards. nosound This disables sound support and volume setting. This is useful for systems where sound support causes problems. nousb This disables the autoloading of USB modules. This is useful for debugging USB issues. Volume/Device Management: dodevfs This enables the deprecated device filesystem on 2.6 systems. You will also need to use noudev for this to take effect. Since devfs is the only option with a 2.4 kernel, this option has no effect if booting a 2.4 kernel. doevms2 This enables support for IBM's pluggable EVMS, or Enterprise Volume Management System. This is not safe to use with lvm2. dolvm2 This enables support for Linux's Logical Volume Management. This is not safe to use with evms2. noudev This disables udev support on 2.6 kernels. This option requires that dodevfs is used. Since udev is not an option for 2.4 kernels, this options has no effect if booting a 2.4 kernel. unionfs Enables support for Unionfs on supported CD images. This will create a writable Unionfs overlay in a tmpfs, allowing you to change any file on the CD. unionfs=X Enables support for Unionfs on supported CD images. This will create a writable Unionfs overlay on the device you specify. The device must be formatted with a filesystem recognized and writable by the kernel. Other options: debug Enables debugging code. This might get messy, as it displays a lot of data to the screen. docache This caches the entire runtime portion of the CD into RAM, which allows you to umount /mnt/cdrom and mount another CDROM. This option requires that you have at least twice as much available RAM as the size of the CD. doload=X This causes the initial ramdisk to load any module listed, as well as dependencies. Replace X with the module name. Multiple modules can be specified by a comma-separated list. noload=X This causes the initial ramdisk to skip the loading of a specific module that may be causing a problem. Syntax matches that of doload. nox This causes an X-enabled LiveCD to not automatically start X, but rather, to drop to the command line instead. scandelay This causes the CD to pause for 10 seconds during certain portions the boot process to allow for devices that are slow to initialize to be ready for use. scandelay=X This allows you to specify a given delay, in seconds, to be added to certain portions of the boot process to allow for devices that are slow to initialize to be ready for use. Replace X with the number of seconds to pause. |
Agora faça a inicialização de seu CD, selecione um kernel (se você não estiver contente com o kernel padrão gentoo) e opções de inicialização. Como um exemplo, nós iremos mostrar como carregar o kernel gentoo, com dopcmcia como um parâmetro de kernel:
Listagem de código 3.4: Carregando um CD de instalação |
boot: gentoo dopcmcia
|
Você verá uma tela de inicialização e uma barra de progresso. Se você estiver instalando o Gentoo em um sistema com um teclado diferente do modelo americano, certifique-se de apertar Alt-F1 para trocar para modo verbal e siga o prompt. Se nenhuma seleção for feita em 10 segundos, o padrão (teclado americano) será aceito e o processo de inicialização irá continuar. Uma vez que o processo de inicialização terminar, o Gnome irá iniciar e você será automaticamente logado no sistema Gentoo Linux "Live" como "gentoo" em modo gráfico. Você será logado como "root", o superusuário, nos outros consoles e deve ter um prompt de administrador ("#") neles. Você pode mudar para estes consoles apertando Alt-F2, Alt-F3, Alt-F4 Alt-F5, Alt-F6. Volte para o desktop gráfico de onde você começou apertando Alt-F7. Para mudar para os outros consoles de dentro do X, você deve usar Crtl como prefixo. Você pode rodar comandos como administrador (root) de dentro do ambiente gráfico usando o comando sudo. Você pode até se tornar root em um terminal para fazer tarefas múltiplas.
Listagem de código 3.5: Usando sudo para rodar aplicações |
(Só exemplo) (Editando o arquivo group) # sudo vi /etc/group (Tornando-se root por uma sessão) # sudo su - |
Configuração de hardware adicional
Quando o LiveCD carrega, ele tenta detectar todos seus dispositivos de hardware e carregar os módulos de kernel apropriados para suportar seu hardware. Na vasta maioria dos casos, ele faz um bom trabalho. Todavia, em alguns casos, ele pode não carregar automaticamente os módulos de kernel que você precisa. Se a auto-detecção de PCI pulou algum hardware de seu sistema, você terá de carregar o driver apropriado manualmente. Estas tarefas precisam de acesso de administrador (root).
No próximo exemplo nós tentamos carregar o módulo 8139too (suporte para alguns tipos de interface de rede):
Listagem de código 3.6: Carregando módulos de kernel |
# modprobe 8139too
|
Se você precisa de suporte a PCMCIA, você deve rodar o script de init pcmcia:
Listagem de código 3.7: Rodando o script de init de PCMCIA |
# /etc/init.d/pcmcia start
|
Opcional: Ajustando performance de disco rígido
Se você é um usuário avançado, você pode querer ajustar a performance do disco rígido IDE usando o comando hdparm. Você precisará de acesso de administrador (root) para usar hdparm. Com as opções -tT, você pode testar a performance de seu disco (execute várias vezes para ter uma idéia mais precisa):
Listagem de código 3.8: Testando performance de disco |
# hdparm -tT /dev/hda
|
Para ajustar, você pode usar qualquer um dos seguintes exemplos (ou experimentar por contra própria) que usam /dev/hda como o disco (substitua com seu disco):
Listagem de código 3.9: Ajustando performance de disco rígido |
Ativando DMA: # hdparm -d 1 /dev/hda Ativando opções de performance seguras: # hdparm -d 1 -A 1 -m 16 -u 1 -a 64 /dev/hda |
Se você planeja que outras pessoas tenham acesso a seu ambiente de instalação ou você deseja conversar usando o irssi sem privilégios de administrador (root) (por razões de segurança), você precisa criar as contas de usuário necessárias e mudar a senha de administrador (root). Você precisa de acesso de administrador para mudar a senha de root e adicionar novos usuários.
Para mudar a senha de administrador (root), use o comando passwd:
Listagem de código 3.10: Mudando a senha de administrador (root) |
$ sudo su - # passwd New password: (Entre sua senha) Re-enter password: (Entre sua senha novamente) |
Para criar uma conta de usuário, primeiro entramos suas credenciais, seguido da senha. Podemos usar useradd e passwd para essas tarefas. No próximo exemplo, iremos criar um usuário chamado "joao".
Listagem de código 3.11: Criando uma conta de usuário |
# useradd -m -G users joao # passwd joao New password: (Entre a senha do joao) Re-enter password: (Entre a senha do joao novamente) |
Você pode mudar sua id de usuário de administrador (root) para a conta recém criada usando o comando su:
Listagem de código 3.12: Mudando id de usuário |
# su - joao
|
Você também pode mudar a senha para o usuário "gentoo" no ambiente gráfico. Esta conta já serve para uso na Internet.
Listagem de código 3.13: Mudando a senha do gentoo |
$ passwd New password: (Enter your new password) Re-enter password: (Re-enter your password) |
Opcional: Vendo documentação durante a instalação
Se você quiser ler o Manual do Gentoo (tanto do CD como online) durante a instalação, certifique-se que você criou uma conta de usuário (veja Opcional: Contas de usuário). Então aperte Alt-F2 para ir para um novo terminal e fazer log-in.
Se você quiser ver a documentação no CD você pode imediatamente rodar links para lê-la:
Listagem de código 3.14: Vendo a documentação do CD |
# links /mnt/cdrom/docs/html/index.html
|
No entanto, é recomendável que você use o Manual do Gentoo online, uma vez que ele será mais recente que a versão disponível no CD. Você também pode lê-lo usando o comando links, mas somente após terminar o capítulo Configurando sua rede (senão, você não conseguirá acessar a Internet para ver o documento):
Listagem de código 3.15: Vendo a documentação online |
# links http://www.gentoo.org/doc/pt_br/handbook/handbook-x86.xml
|
Você pode voltar para sua janela original apertando Alt-F7.
Você pode agora continuar usando o instalador baseado em GTK+ (que precisa de X) ou o instalador baseado em Dialog que pode ser rodado em um console.
Uma vez que o instalador terminar de carregar, você verá a tela de boas vindas. Ela dá uma introdução amigável ao processo de instalação do Gentoo em seu computador. Lembre-se de ler cada opção cuidadosamente. Há ajuda detalhada disponível para cada passo da instalação na parte de cima da tela. Nós recomendamos que você sempre leia a ajuda fornecida antes fazer suas escolhas. Note que a qualquer hora durante o processo de instalação, você pode salvar seu progresso de configuração, caso você precise continuar sua instalação depois.
3.b. Configuração de pré-instalação
Opcional: Configuração de rede manual
Na próxima seção, você precisa configurar sua rede. O instalador deve ter detectado e configurado a sua rede para você, mas caso contrário, você pode configurar sua rede manualmente. Na orelha Misc., você pode especificar um local de sua escolha ou manter o padrão de /var/log/installer.log, onde o instalador irá gravar seus registros.
Se você deseja ativar acesso de SSH para a máquina, você precisa iniciar o sshd e especificar uma senha de administrador (root).
Opcional: Carregue módulos de kernel adicionais
Se você precisa carregar mais módulos de kernel para suportar seu hardware, coloque seus nomes na linha apropriada, cada um separado por um espaço.
Aviso: Não mude a seleção de Install mode para qualquer outra fora Normal. Esta função ainda é experimental e mudá-la pode deixá-lo com um sistema que não funciona! |
Para poder instalar o Gentoo em sua máquina, você precisará preparar seus discos. A tela Partitioning irá mostrá-lo uma lista de discos detectados e permiti-lo especificar os sistemas de arquivos que você quer ter em suas partições. Clicar em Clear partitions irá apagar todas partições já existentes em seu disco, portanto tenha cuidado com ela! Também é possível redimensionar certos tipos de partição.
Se você escolher usar o Recommended layout, o instalador irá criar três partições: 100MB para /boot, uma partição /swap de até 512MB, e o resto do espaço disponível em disco é usado para /, a partição raiz. Se você tiver mais de 4GB de espaço, usar a opção "Recommended layout" irá configurar automaticamente suas partições sem destruir dados nas partições já existentes.
Opcional: Definir montagens de rede
Esta tela permite que você configure e use montagens de rede já existentes durante e após a instalação. Selecione New para começar a configuração. Neste ponto, só NFS é suportado.
Já que você está fazendo uma instalação sem uma conexão de internet, você deve selecionar GRP Install bem como Dynamic das opções presentes. Tudo que você precisa para construir seu sistema irá ser gerado a partir dos arquivos no LiveCD.
Aviso: Não selecione nenhuma opção fora as especificadas acima quando você estiver instalando sem uma conexão de Internet. |
Você deve escolher Snapshot nesta tela. O instalador irá instalar uma árvore do Portage automaticamente do LiveCD uma vez que você selecionar Snapshot; você não precisa especificar uma URI de snapshot.
Já que você está fazendo uma instalação GRP/sem rede, você não poderá selecionar opções de USE antes da instalação. No entanto, você pode configurar suas próprias opções de USE em /etc/make.conf depois de ter reiniciado em seu sistema pronto.
Você deve, no entanto, selecionar seu tipo de processador na seção CFLAGS junto com qualquer otimização personalizada que você quiser, como -O2 e -pipe.
Quaisquer outras opções que você deseja configurar para uso futuro devem ser selecionadas agora. Use unstable (~arch) irá permitir usar pacotes do ramo instável da árvore do Portage. Build binary packages cria tarballs prontas-para-inistalação de todos pacotes que você compila em seu sistema. DistCC permite que você divida o peso da compilação com outro computador via sua conexão de rede. ccache salva código compilado para uso posterior, e pode acelerar muito o tempo de compilação se você reinstalar o mesmo pacote.
Você não poderá mudar seu CHOST, já que isto pode danificar seriamente sua instalação. Em MAKEOPTS você define quantas compilações paralelas devem ocorrer quando você instala um pacote. Uma boa escolha é o número de CPUs em seu sistema mais uma, mas esta guia não é sempre perfeita. Em um sistema de um processador, -j2 deve ser usado.
Você precisa usar o kernel presente no LiveCD para uma instalação GRP/sem rede. Ele é meramente um kernel gentoo-sources compilado pelo genkernel, o utilitário de compilação automática do Gentoo, e dará a você um kernel que detecta e configura seu hardware automaticamente durante a inicialização.
Se você quiser ter uma imagem de fundo interessante durante a inicialização, selecione Enable bootsplash.
3.i. Gerenciador de inicialização
Esta tela permite escolher seu gerenciador de inicialização e, opcionalmente, especificar parâmetros adicionais de kernel que serão usados durante a inicialização.
Você pode especificar que disco carregar escolhendo a opção apropriada de Boot Drive. No Linux, o primeiro disco IDE em seu sistema é chamado hda, o segundo disco IDE é chamado hdb, e assim em diante. Se você tiver discos SATA ou SCSI, eles serão chamados sda, sdb, etc. Por favor, certifique-se de fazer a seleção correta para seu sistema.
Se você precisar passar opções adicionais ao kernel, como entradas de video e/ou VGA, simplesmente adicione-as à seção "Extra kernel parameters".
Se você colocou jumpers em seu disco rígido porque o BIOS não consegue lidar com discos rígidos grandes, você deve colocar hdx=stroke. Se você tiver dispositivos SCSI, você deve adicionar doscsi como uma opção de kernel.
Este o mapa e selecione a região mais próxima de sua localização real. Mais tarde, será perguntado se você quer seu relógio configurado em horário UTC ou local.
Nesta tela, você poderá configurar os vários dispositivos de interface de rede detectados em seu computador. Leia as opções disponíveis com cuidado.
Na orelha Hostname/Proxy Information/Other, você precisará escolher um nome de host para sua máquina. Você também precisa especificar um servidor de proxy e ajustes de DNS se necessário.
Daemons de cron são programas úteis que rodam tarefas em horários agendados. Embora você não precise instalar um, eles podem ser muito úteis.
Um logger de sistema é uma necessidade para qualquer sistema operacional Linux. Faça sua seleção da lista de escolhas disponíveis.
Opcional: instalando pacotes adicionais
O LiveCD contém alguns pacotes pré-construídos disponíveis. Se você quiser instalá-los, marque a caixa apropriada.
Importante: Como você está instalando o Gentoo sem uma conexão de Internet, você não pode marcar pacotes adicionais além dos mostrados pelo instalador. |
3.n. Serviços de inicialização
Esta tela permite escolher os vários serviços a serem carregados durante a inicialização do sistema. Estude as opções disponíveis e suas descrições com cuidado, e então selecione seus serviços desejados. Por exemplo, se você escolheu instalar xorg-x11 e quer carregar direto no desktop gráfico, você deve selecionar a opção "xdm" da lista.
Agora você poderá mudar vários ajustes, incluindo mapa de teclado, gerenciador de display gráfico, editor padrão, e configurar seu relógio em horário UTC ou local.
Primeiro configure a senha de root para o administrador do sistema (o usuário root).
Nós recomendamos enfaticamente que você crie um usuário comum para trabalho de rotina. Trabalhar como root o tempo todo é perigoso e deve ser evitado! Crie seus usuários, configure suas senhas, e adicione-os aos grupos apropriados. Você pode opcionalmente mudar seus diretórios de home, selecionar sua shell de login e configurar comentários úteis.
Por favor, verifique cada passado do processo de instalação, certificando-se que seu sistema está configurado devidamente. Quando você terminar a revisão, você pode salvar seu progresso e sair, ou clicar Install para começar a instalar o Gentoo automaticamente.
Você pode navegar livremente no LiveCD enquanto a instalação avança. A janela do instalador irá alertá-lo quando terminar. Neste ponto, você pode fechar a janela clicando no x no canto superior direito. Quando você estiver pronto, você pode fazer log-out e reiniciar. Certifique-se de remover o LiveCD durante a reinicialização.
Parabéns, seu sistema está agora completamente equipado! Continue com E agora, para onde ir? para aprender mais sobre o Gentoo.
Depois de você carregar o LiveCD de instalação do Gentoo Linux, ele irá tentar carregar um desktop gráfico. Se não conseguir fazê-lo, ao invés disso irá mostrar um prompt de linha de comando. Para lançar o instalador, simplesmente rode:
Listagem de código 1.1: Inicie o instalador |
# installer
|
Uma vez que o instalador terminar de carregar, você verá a tela de boas vindas. Ela dá uma introdução amigável ao processo de instalação do Gentoo em seu computador. Lembre-se de ler cada opção cuidadosamente. Há ajuda detalhada disponível para cada passo da instalação na parte de cima da tela. Nós recomendamos que você sempre leia a ajuda fornecida antes fazer suas escolhas. Note que a qualquer hora durante o processo de instalação, você pode salvar seu progresso de configuração, caso você precise continuar sua instalação depois. Use a tecla Tab (em seu teclado) para trocar entre menus dentro de uma tela e a tecla Enter para confirmar uma ação.
Para instalar o Gentoo em sua máquina, você irá precisar preparar seus discos. A tela Partitioning irá mostrar uma lista de discos detectados e permitir que você especifique os sistemas de arquivos que você gostaria de ter em suas partições. Selecionar Clear partitions irá apagar todas partições existentes em seu disco, portanto tenha cuidado com esta opção! Também é possível redimensionar certos tipos de partição.
Se você escolher usar o Recommended layout, o instalador irá criar três partições: 100MB para /boot, uma partição /swap de até 512MB, e o resto do espaço disponível em disco é usado para /, a partição raiz. Se você tiver mais que 4GB de espaço sem particionamento, usar o "Recommended layout" irá configurar suas partições automaticamente sem destruir dados nas partições já existentes.
Opcional: Definir montagens de rede
Esta tela permite que você configure e use montagens de rede já existentes durante e após a instalação. Selecione New para começar a configuração. Neste ponto, só NFS é suportado.
Já que você está fazendo uma instalação sem uma conexão de internet, você deve selecionar GRP das opções de stage presentes. Na próxima janela, selecione Create from CD. Tudo que você precisa para construir seu sistema irá ser gerado a partir dos arquivos no LiveCD.
Aviso: Não selecione nenhuma opção fora as especificadas acima quando você estiver instalando sem uma conexão de Internet. |
Você precisa usar o kernel presente no LiveCD para uma instalação GRP/sem rede. Ele é meramente um kernel gentoo-sources compilado pelo genkernel, o utilitário de compilação automática do Gentoo, e dará a você um kernel que detecta e configura seu hardware automaticamente durante a inicialização.
Selecione LiveCD kernel e continue com a próxima tela.
4.f. Gerenciador de inicialização
Esta tela permite que você escolha seu gerenciador de inicialização. O instalador irá configurar sua escolha automaticamente.
Estude a lista e selecione a região mais próxima de sua localização real.
Nesta tela, você poderá configurar os vários dispositivos de interface de rede detectados em seu computador. Leia as opções disponíveis com cuidado.
A próxima tela permite escolher entre configuração DHCP e manual de endereço IP. Uma vez que a interface de rede estiver devidamente configurada, você precisará criar um nome de host para seu sistema. Opcionalmente, você pode especificar um nome de domínio e quaisquer informações de servidor de DNS necessárias.
Opcional: instalando pacotes adicionais
O LiveCD contém alguns pacotes pré-construídos disponíveis. Se você quiser instalá-los, marque a caixa apropriada.
Importante: Como você está instalando o Gentoo sem uma conexão de Internet, você não pode marcar pacotes adicionais além dos mostrados pelo instalador. |
Primeiro configure a senha de root para o administrador do sistema (o usuário root).
Nós recomendamos enfaticamente que você crie um usuário comum para trabalho de rotina. Trabalhar como root o tempo todo é perigoso e deve ser evitado! Crie seus usuários, configure suas senhas, e adicione-os aos grupos apropriados. Você pode opcionalmente mudar seus diretórios de home, selecionar sua shell de login e configurar comentários úteis.
Por favor, verifique cada passado do processo de instalação, certificando-se que seu sistema está configurado devidamente. Quando você terminar a revisão, você pode salvar seu progresso e sair, ou clicar Install para começar a instalar o Gentoo automaticamente.
O instalador irá alertá-lo quando terminar. Ele irá retorná-lo para o prompt de comando. Tudo que você precisa fazer para reiniciar é digitar:
Listagem de código 11.1: Reiniciando |
# shutdown -r now
|
Parabéns, seu sistema está agora completamente equipado! Continue com E agora, para onde ir? para aprender mais sobre o Gentoo.
Parabéns! Você tem um sistema funcionando com o Gentoo. Mas para onde ir depois disto? Quais são suas opções agora? O que explorar primeiro? O Gentoo oferece a seus usuários várias possibilidades, e portanto muitas características documentadas (ou menos documentadas).
Certamente você deve olhar a próxima parte do Manual do Gentoo intitulada Trabalhando com o Gentoo, que explica como manter os programas atualizados, como instalar mais programas, o que são as variáveis de USE, como o sistema de inicialização do Gentoo funciona, etc...
Se você estiver interessado na otimização do sistema para desktop, ou quiser aprender como configurar seu sistema para se ter um desktop completo e funcional, consulte nossos extensos Recursos relacionados ao Desktop do Gentoo. Além disso, você pode usar nosso guia de localização para adequar seu sistema ao seu país.
Também temos o Manual de segurança do Gentoo, que vale ser lido.
Para uma listagem completa da documentação disponível verifique nossa página de Recursos de documentação.
Você, é claro, sempre bem-vindo em nossos Fóruns do Gentoo ou em um de nossos vários canais de IRC do Gentoo.
Nós também temos várias listas de e-mail abertas a todos nossos usuários. Informações de como cadastrar-se estão contidas naquela página.
Iremos calar-nos agora e deixar você aproveitar sua instalação :)
5.c. Mudanças no Gentoo desde a versão 2006.0
Ainda não houve mudanças significantes.
O Portage é provavelmente a inovação mais notável do Gentoo no gerenciamento de software. Com sua alta flexibilidade e enorme quantidade de funções, é freqüentemente visto como a melhor ferramenta de gerenciamento de software disponível para Linux.
O Portage é completamente escrito em Python e Bash e portanto totalmente visíveis a seus usuários já que as duas são linguagens de scripting.
A maior parte dos usuários usa o Portage através da ferramenta emerge. Este capítulo não é feito para duplicar a informação disponível na página de man do emerge. Para uma listagem completa das opções do emerge, por favor consulte sua página de man:
Listagem de código 1.1: Lendo a página de man do emerge |
$ man emerge
|
Quando nós falamos de pacotes, nós queremos dizer títulos de software que estão disponíveis para os usuários do Gentoo através da árvore do Portage. A árvore do Portage é uma coleção de ebuilds, arquivos que contêm toda informação que o Portage precisa para manter o software (instalar, procurar, ...). As ebuilds residem em /usr/portage por padrão.
Quando você pedir ao Portage tomar alguma ação com relação a títulos de software, ele usará as ebuilds em seu sistema como base. Logo, é importante que você atualize as ebuilds em seu sistema regularmente para que o Portage saiba sobre novo software, atualizações de segurança, etc...
Atualizando a árvore do Portage
A árvore do Portage é normalmente atualizada com o rsync, um programa rápido de transferência de arquivos incremental. Atualizar é simples, já que o comando emerge tem um front-end para o rsync:
Listagem de código 2.1: Atualizando a árvore do Portage |
# emerge --sync
|
Se você não consegue fazer rsync devido a restrições de firewall, você ainda pode atualizar sua árvore do Portage usando nossos snapshots diários da árvore do Portage. A ferramenta emerge-webrsync baixa e instala o último snapshot em seu sistema automaticamente:
Listagem de código 2.2: Rodando emerge-webrsync |
# emerge-webrsync
|
Para procurar títulos de software na árvore do Portage, você pode usar as funções de procura incluídas no emerge. Por padrão, emerge --search retorna os nomes dos pacotes cujos títulos coincidem (inteiramente ou parcialmente) com o termo de procura.
Por exemplo, para procurar por todos pacotes que tenham "pdf" em seu nome:
Listagem de código 3.1: Procurando todos pacotes com nome contendo pdf |
$ emerge --search pdf
|
Se você deseja pesquisar também as descrições você pode usar a opção --searchdesc (ou -S):
Listagem de código 3.2: Procurando pacotes relacionados a pdf |
$ emerge --searchdesc pdf
|
Quando você vir a saída, você perceberá que ela dá muita informação a você. Os campos são claramente marcados para que nós não termos que adivinhar seus significados:
Listagem de código 3.3: Exemplo de saída de emerge --search |
* net-print/cups-pdf
Latest version available: 1.5.2
Latest version installed: [ Not Installed ]
Size of downloaded files: 15 kB
Homepage: http://cip.physik.uni-wuerzburg.de/~vrbehr/cups-pdf/
Description: Provides a virtual printer for CUPS to produce PDF files.
License: GPL-2
|
Quando você encontrar um título de software de que você gosta, você pode instalá-lo facilmente com o emerge: simplesmente adicione o nome do pacote. Por exemplo, para instalar o gnumeric:
Listagem de código 3.4: Instalando o gnumeric |
# emerge gnumeric
|
Já que muitas aplicações dependem uma da outra, qualquer tentativa de instalar um certo pacote pode resultar na instalação de várias dependências também. Não se preocupe, o Portage lida bem com dependências. Se você quiser descobrir o que o Portage instalaria quando você pedir para ele instalar um certo pacote, adicione a opção --pretend. Por exemplo:
Listagem de código 3.5: Fingir instalar o gnumeric |
# emerge --pretend gnumeric
|
Quando você pede ao Portage para instalar um pacote, ele irá baixar o código fonte necessário da Internet (se necessário) e gravá-lo por padrão em /usr/portage/distfiles. Depois disso irá descompactar, compilar e instalar o pacote. Se você quiser que o Portage só baixe as fontes sem instalá-las, adicione a opção --fetchonly ao comando emerge:
Listagem de código 3.6: Baixando o código-fonte do gnumeric |
# emerge --fetchonly gnumeric
|
Encontrando documentação instalada por pacotes
Muitos pacotes vêm com sua própria documentação. Às vezes, a opções de USE doc determina se documentação do pacote deve ser instalada ou não. Você pode verificar a existência de uma opção de USE doc com o comando emerge -vp <nome do pacote>.
Listagem de código 3.7: Verificando a existência de uma opção de USE doc |
(alsa-lib é só um exemplo, claro.) # emerge -vp alsa-lib [ebuild N ] media-libs/alsa-lib-1.0.9_rc3 +doc -jack 674 kB |
Você pode ativar ou desativar a opção de USE doc tanto globalmente no arquivo /etc/make.conf como por pacote no arquivo /etc/portage/package.use. O capítulo Variáveis de USE cobre este aspecto com detalhe.
Uma vez o pacote instalado, sua documentação geralmente é encontrada em um subdiretório com o nome do pacote no diretório /usr/share/doc. Você também pode listar todos arquivos instalados com a ferramenta equery, que é parte do pacote app-portage/gentoolkit.
Listagem de código 3.8: Localizando documentação de pacote |
# ls -l /usr/share/doc/alsa-lib-1.0.9_rc3 total 28 -rw-r--r-- 1 root root 669 May 17 21:54 ChangeLog.gz -rw-r--r-- 1 root root 9373 May 17 21:54 COPYING.gz drwxr-xr-x 2 root root 8560 May 17 21:54 html -rw-r--r-- 1 root root 196 May 17 21:54 TODO.gz (Alternativamente, use equery para localizar arquivos interessantes:) # equery files alsa-lib | less media-libs/alsa-lib-1.0.9_rc3 * Contents of media-libs/alsa-lib-1.0.9_rc3: /usr /usr/bin /usr/bin/alsalisp (Saída trancada) |
Quando você quiser remover um pacote de software de seu sistema, use emerge --unmerge. Isto dirá para o Portage remover todas arquivos instalados por aquele pacote de seu sistema exceto os arquivos de configuração da aplicação se você os alterou depois da instalação. Deixar os arquivos de configuração permite que você continue trabalhando com o pacote se você decidir que quer instalá-lo novamente.
Todavia, um grande aviso é aplicável: o Portage não irá verificar se o pacote que você quer remover é necessário para outro pacote. Ele irá, no entanto, avisar quando você quiser remover um pacote importante que quebraria seu sistema se você desinstalasse-lo.
Listagem de código 3.9: Removendo o gnumeric do sistema |
# emerge --unmerge gnumeric
|
Quando você remove um pacote de seu sistema, as dependências do pacote que foram instaladas automaticamente são deixadas. Para que o Portage localize todas dependências que podem ser removidas agora, use a função --depclean do emerge. Nós iremos falar mais disso adiante.
Para manter seu sistema em perfeita forma (e sem mencionar instalar as últimas atualizações de segurança) você precisa atualizar seu sistema regularmente. Uma vez que o Portage só verifica as ebuilds em sua árvore do Portage, você primeiro tem que atualizar sua árvore do Portage. Quando sua árvore do Portage é atualizada, você pode atualizar seu sistema com emerge --update world. No próximo exemplo, também usaremos a opção ask para dizer ao Portage para mostrar a lista de pacotes que ele quer atualizar e perguntar para você se você quer continuar:
Listagem de código 3.10: Atualizando seu sistema |
# emerge --update --ask world
|
O Portage irá procurar novas versões das aplicações que você tem instaladas. Todavia, ele só irá verificar as versões das aplicações que você instalou explicitamente - não as dependências. Se você quiser atualizar todos pacotes em seu sistema, adicione o argumento --deep:
Listagem de código 3.11: Atualizando o sistema inteiro |
# emerge --update --deep world
|
Já que atualizações de segurança também acontecem em pacotes que você não instalou explicitamente em seu sistema (mas que são puxados como dependências de outros programas), também é recomendado que você rode isto de vez em quando.
Se você alterou qualquer uma das suas variáveis de USE, você deve adicionar --newuse também. O Portage irá então verificar se a mudança necessita a instalação de novos pacotes ou recompilação dos instalados:
Listagem de código 3.12: Fazendo um update completo |
# emerge --update --deep --newuse world
|
Alguns pacotes na árvore do Portage não têm nenhum conteúdo real, mas são usados para instalar uma coleção de pacotes. Por exemplo, o pacote kde irá instalar um ambiente KDE completo em seu sistema ao instalar os vários pacotes relacionados ao KDE como dependências.
Se você quiser remover um pacote desses de seu sistema, rodar emerge --unmerge neste pacote não terá muito efeito já que as dependências permanecem no sistema.
O Portage tem a funcionalidade de remover dependências órfãs também, mas já que a disponibilidade do software é dinamicamente dependente, você primeiro precisar atualizar seu sistema completamente, incluindo as novas mudanças que você fez quando mudou as opções de USE. Depois disso você pode rodar emerge --depclean para remover as dependências órfãs. Quando isso é feito, você precisa reconstruir as aplicações que foram linkadas dinamicamente aos títulos de software a que foram linkados dinamicamente mas que não são mais necessários.
Tudo isso é feito com os três seguintes comandos:
Listagem de código 3.13: Removendo dependências órfãs |
# emerge --update --deep --newuse world # emerge --depclean # revdep-rebuild |
O revdep-rebuild é fornecido pelo pacote gentoolkit; não se esqueça de instalá-lo primeiro:
Listagem de código 3.14: Instalando o pacote |
# emerge gentoolkit
|
1.d. Quando o Portage estiver reclamando...
Sobre SLOTs, virtuals, branches, arquiteturas e profiles
Como dissemos antes, o Portage é extremamente poderoso e suporta muitas funções que outras ferramentas de gerenciamento de software não têm. Para entender isso, nós explicamos alguns dos aspectos do Portage sem entrar em muitos detalhes.
Com o Portage, as diferentes versões de um único pacote podem coexistir em um sistema. Enquanto outras distribuições costumam nomear os pacotes com as versões (como freetype e freetype2), o Portage usa uma tecnologia chamada SLOTs. Uma ebuild declara um certo SLOT para sua versão. Ebuilds com SLOTs diferentes podem coexistir em um mesmo sistema. Por exemplo, o pacote freetype tem ebuilds com SLOT="1" e SLOT="2".
Também existem pacotes que fornecem a mesma funcionalidade, mas que são implementados de maneira diferente. Por exemplo, metalogd, sysklogd e syslog-ng são todos loggers de sistema. Aplicações que dependem da disponibilidade de um "logger de sistema" não podem depender, por exemplo, do metalogd, já que outros loggers de sistema são tão bons quanto. O Portage permite o uso de virtuals: cada logger de sistema fornece a dependência virtual/syslog para que as aplicações possam depender de virtual/syslog.
O software na árvore do Portage pode residir em diferentes ramos. Por padrão seu sistema só aceita pacotes que o Gentoo considera estável. A maior parte dos títulos de software novos, quando colocados na árvore, são adicionados no ramo de testes, significando que mais testes devem ser feitos antes de serem marcados estáveis. Embora você veja as ebuilds deste software na árvore do Portage, o Portage não irá atualizá-los antes de serem colocados no ramo estável.
Alguns softwares só estão disponíveis para algumas arquiteturas. Ou o software não funciona em outras arquiteturas, ou precisa de mais testes, ou o desenvolvedor que colocou o software na árvore do Portage não pôde verificar se o pacote funciona em arquiteturas diferentes.
Cada instalação do Gentoo adere a um certo profile (perfil) que contém, entre outras informações, a lista de pacotes que são necessários para que um sistema funcione normalmente.
Listagem de código 4.1: Aviso do Portage sobre pacotes bloqueados (com --pretend) |
[blocks B ] mail-mta/ssmtp (is blocking mail-mta/postfix-2.2.2-r1) |
Listagem de código 4.2: Aviso do Portage sobre pacotes bloqueados (sem --pretend) |
!!! Error: the mail-mta/postfix package conflicts with another package. !!! both can't be installed on the same system together. !!! Please use 'emerge --pretend' to determine blockers. |
As ebuilds contêm certos campos específicos que informam ao Portage sobre suas dependências. Existem duas dependências possíveis: dependências de construção, declaradas em DEPEND e dependências de execução, declaradas em RDEPEND. Quando uma dessas dependências marca um pacote ou virtual como sendo explicitamente não compatível, ele faz um bloqueio.
Para consertar um bloqueio, você pode escolher não instalar o pacote ou desinstalar o pacote conflituoso primeiro. No exemplo dado, você pode não instalar o postfix ou remover o ssmtp primeiro.
Também é possível que dois pacotes que ainda não foram instalados bloqueiem um ao outro. Neste caso raro, você deve descobrir por que você precisa instalar os dois. Na maior parte dos casos, você pode se satisfazer com um pacote. Se não, por favor relate um bug no Sistema de rastreamento de bugs do Gentoo.
Listagem de código 4.3: Aviso do Portage sobre pacotes mascarados |
!!! all ebuilds that could satisfy "bootsplash" have been masked. |
Listagem de código 4.4: Aviso do Portage sobre pacotes mascarados - motivo |
!!! possible candidates are: - gnome-base/gnome-2.8.0_pre1 (masked by: ~x86 keyword) - lm-sensors/lm-sensors-2.8.7 (masked by: -sparc keyword) - sys-libs/glibc-2.3.4.20040808 (masked by: -* keyword) - dev-util/cvsd-1.0.2 (masked by: missing keyword) - media-video/ati-gatos-4.3.0 (masked by: package.mask) - sys-libs/glibc-2.3.2-r11 (masked by: profile) |
Quando você quiser instalar um pacote que não está disponível em seu sistema, você receberá este erro de máscara. Você pode tentar instalar uma aplicação diferente que está disponível para seu sistema ou esperar até que o pacote fique disponível. Sempre existe um motivo para um pacote estar mascarado:
Listagem de código 4.5: Aviso do Portage sobre dependências faltando |
emerge: there are no ebuilds to satisfy ">=sys-devel/gcc-3.4.2-r4". !!! Problem with ebuild sys-devel/gcc-3.4.2-r2 !!! Possibly a DEPEND/*DEPEND problem. |
A aplicação que você está tentando instalar depende em um outro pacote que não está disponível para seu sistema. Veja no bugzilla se o problema é conhecido, e se não for, por favor relate-o. A menos que você esteja misturando ramos isso não deve acontecer e logo é um bug.
Listagem de código 4.6: Aviso do Portage sobre nomes de ebuild ambíguos |
!!! The short ebuild name "aterm" is ambiguous. Please specify
!!! one of the following fully-qualified ebuild names instead:
dev-libs/aterm
x11-terms/aterm
|
A aplicação que você quer instalar tem um nome que corresponde a mais de um pacote. Você precisa dar a categoria também. O Portage irá informar você sobre as possíveis alternativas a se escolher.
Listagem de código 4.7: Aviso do Portage sobre dependências circulares |
!!! Error: circular dependencies: ebuild / net-print/cups-1.1.15-r2 depends on ebuild / app-text/ghostscript-7.05.3-r1 ebuild / app-text/ghostscript-7.05.3-r1 depends on ebuild / net-print/cups-1.1.15-r2 |
Dois (ou mais) pacotes que você quer instalar dependem um do outro e logo não podem ser instalados. Isto é provavelmente um bug na árvore do Portage. Por favor sincronize depois de um tempo e tente novamente. Você também pode ver no bugzilla se o problema é conhecido, e se não for, relatá-lo.
Listagem de código 4.8: Aviso do Portage sobre problema ao baixar arquivos |
!!! Fetch failed for sys-libs/ncurses-5.4-r5, continuing...
(...)
!!! Some fetch errors were encountered. Please see above for details.
|
O Portage não conseguiu baixar as fontes para a aplicação dada e tentará continuar com as outras aplicações (se aplicável). Este problema pode ser devido a um servidor que não sincronizou corretamente ou porque a ebuild aponta para um local incorreto. O servidor onde residem as fontes também pode estar desligado por algum motivo.
Tente de novo uma hora depois para ver se o problema ainda persiste.
Proteção de sistema pelo profile
Listagem de código 4.9: Aviso do Portage sobre pacotes protegidos pelo profile |
!!! Trying to unmerge package(s) in system profile. 'sys-apps/portage' !!! This could be damaging to your system. |
Você pediu para remover um pacote que é central para o seu sistema. Ele está listado em seu profile como necessário e não deve ser removido de seu sistema.
2.a. O que são as opções de USE?
As idéias por trás das opções de USE
Quando você está instalando o Gentoo (ou qualquer outra distribuição, até mesmo sistema operacional) você faz escolhas que dependem do ambiente com que você está trabalhando. Uma configuração para servidores difere de uma configuração de uma estação de trabalho. Uma estação de jogos difere de uma estação de gráficos 3D.
Isso não somente é verdade para os pacotes que você quer instalar, mas também que funções um pacote deve suportar. Se você não precisa de OpenGL, por que se preocupar em instalar o OpenGL e construir suporte para OpenGL na maior parte de seus pacotes? Se você não quer usar o KDE, por que compilar pacotes com suporte a KDE se eles irão funcionar perfeitamente sem suporte a KDE?
Para ajudar os usuários na decisão sobre o que instalar/ativar e o que não, nós quisemos que o usuário especificasse seu ambiente de uma maneira fácil. Isto força o usuário a decidir sobre o que eles realmente querem e facilita o processo para o Portage, nosso sistema de gerenciamento de pacotes, tornando as decisões úteis.
Entre com as opções de USE. Tal opção é uma palavra-chave que junta suporte e informações de dependências com um certo conceito. Se você define uma certa opção de USE, o Portage saberá que você quer suporte para a palavra-chave escolhida. Claro que isso também altera as informações de dependências de um pacote.
Vamos ver um exemplo específico: a palavra-chave kde. Se você não tiver esta palavra-chave na sua variável de USE, todos pacotes que tem suporte opcional ao KDE serão compilados sem suporte ao KDE. Todos pacotes que tem uma dependência opcional do KDE serão instalados sem instalar as bibliotecas do KDE (como dependência). Se você definiu a palavra-chave kde, então estes pacotes serão compilados com suporte a KDE, e as bibliotecas do KDE serão instaladas como dependência.
Ao definir as palavras-chave corretamente você recebe um sistema feito especificamente para suas necessidades.
Existem dois tipos de opções de USE: variáveis globais e locais.
Uma lista das opções de USE disponíveis globalmente pode ser encontrada online ou localmente em /usr/portage/profiles/use.desc.
Uma lista de opções de USE locais pode ser encontrada localmente em /usr/portage/profiles/use.local.desc.
Declarando opções de USE permanentes
Esperando ter convencido você da importância das opções de USE, nós iremos informá-lo sobre como declarar as opções de USE.
Como mencionado anteriormente, todas opções de USE são declaradas dentro da variável de USE. Para facilitar ao usuários a busca e escolha de opções de USE, nós já fornecemos uma configuração de USE padrão. Esta configuração é uma coleção de opções de USE que achamos ser usada comumente pelos usuários do Gentoo. A configuração padrão é declarada na parte dos arquivos make.defaults de seu profile (perfil).
O profile que seu sistema escuta é apontado pelo link simbólico /etc/make.profile. Cada profile funciona em cima de outro profile maior, e o resultado final é a soma de todos profiles. O profile de topo é o profile base (/usr/portage/profiles/base).
Vamos ver a configuração padrão para o profile 2004.3:
Listagem de código 2.1: Variável de USE cumulativa para o profile 2004.3 |
(Este exemplo é a soma de todos ajustes em base, default-linux,
default-linux/x86 e default-linux/x86/2004.3)
USE="x86 oss apm arts avi berkdb bitmap-fonts crypt cups encode fortran f77
foomaticdb gdbm gif gpm gtk imlib jpeg kde gnome libg++ libwww mad
mikmod motif mpeg ncurses nls oggvorbis opengl pam pdflib png python qt
quicktime readline sdl spell ssl svga tcpd truetype X xml2 xmms xv zlib"
|
Como você pode ver, esta variável já contém várias palavras-chave. Não altere nada no arquivo make.defaults para ajustar as variáveis de USE às suas necessidades: mudanças nesse arquivo serão desfeitas quando você atualizar o Portage!
Para mudar este ajuste padrão, você precisa adicionar ou remover palavras-chave à variável USE. Isto é feito globalmente ao definir a variável USE no arquivo /etc/make.conf. Nesta variável você pode adicionar opções de USE adicionais de que você precisa, ou remover as opções de USE que você não quer. Para remover opções, coloque a palavra-chave prefixada do sinal de menos ("-").
Por exemplo, para remover suporte para KDE e QT e adicionar suporte para ldap, as seguintes opções de USE podem ser definidas no /etc/make.conf:
Listagem de código 2.2: Um exemplo de configuração de USE no /etc/make.conf |
USE="-kde -qt ldap" |
Declarando opções de USE para pacotes individuais
Às vezes você quer declarar uma opção de USE para umas (ou algumas) aplicações, mas não para todo o sistema. Para fazê-lo, você precisará criar o diretório /etc/portage (se ainda não existir) e editar o arquivo /etc/portage/package.use.
Por exemplo, se você não quiser suporte de berkdb global, mas você quer ele para o mysql, você deve adicionar:
Listagem de código 2.3: exemplo de /etc/portage/package.use |
dev-db/mysql berkdb |
Você pode, lógico, também desligar opções de USE para uma certa aplicação. Por exemplo, se você não quer suporte de java no PHP:
Listagem de código 2.4: segundo exemplo de /etc/portage/package.use |
dev-php/php -java |
Declarando opções de USE temporárias
Às vezes você quer que um certa opção de USE só uma vez. Ao invés de editar o /etc/make.conf duas vezes (para fazer e desfazer mudanças à variável de USE) você pode simplesmente declarar a variável de USE como uma variável de ambiente. Lembre-se disso, quando você fizer emerge novamente ou atualizar a aplicação (tanto explicitamente como parte de uma atualização de sistema) suas mudanças serão perdidas!
Como um exemplo nós iremos remover o java temporariamente das opções de USE durante a instalação do mozilla.
Listagem de código 2.5: Usando a USE como variável de ambiente |
# USE="-java" emerge mozilla
|
Depois de certos pacotes terem sido instalados, opções adicionais de USE serão automaticamente ativadas para você se você não desativá-las explicitamente. Para ver a lista de pacotes que ligam opções de USE automáticas, por favor veja os arquivos /etc/make.profile/use.defaults e use.defaults dos profiles pais.
Listagem de código 2.6: Um trecho de /etc/make.profile/use.defaults |
gnome gnome-base/gnome gtk x11-libs/gtk+ qt x11-libs/qt kde kde-base/kdebase motif x11-libs/openmotif |
Lógico que há uma certa precedência sobre qual configuração tem prioridade sobre a variável de USE. Você não deve querer declarar USE="-java" só para descobrir que java é ainda usado devido a um ajuste que tem maior prioridade. A precedência para o ajuste de USE é, em ordem de prioridade (o primeiro tem menor prioridade):
Para ver a configuração de USE final como o Portage enxerga ela, rode emerge --info. Isto irá listar todas variáveis relevantes (incluindo a variável de USE) com o conteúdo usado pelo Portage.
Listagem de código 2.7: Rodando emerge --info |
# emerge info
|
Adaptando seu sistema inteiro a novas opções de USE
Se você alterou suas opções de USE e quiser atualizar seu sistema inteiro para que ele use as novas flags de USE, use a opção --newuse do emerge:
Listagem de código 2.8: Reconstruindo seu sistema inteiro |
# emerge --update --deep --newuse world
|
A seguir, rode o depclean do Portage para remover quaisquer dependências condicionais que foram instaladas em seu sistema "antigo", mas que viraram obsoletas com as novas opções de USE.
Aviso: Rodar emerge --depclean é uma operação perigosa e deve ser feita com cuidado. Verifique a lista de pacotes "obsoletos" dada para ter certeza que nenhum pacote de que você precisa seja removido. No exemplo seguinte nós adicionamos a opção -p para que o depclean só liste os pacotes sem removê-los. |
Listagem de código 2.9: Removendo pacotes obsoletos |
# emerge -p --depclean
|
Quando o depclean terminar, rode revdep-rebuild para reconstruir as aplicações que são linkadas dinamicamente contra objetos compartilhados fornecidos por pacotes possivelmente removidos. O revdep-rebuild é parte do pacote gentoolkit; não se esqueça de fazer emerge dele primeiro:
Listagem de código 2.10: Rodando revdep-rebuild |
# revdep-rebuild
|
Quando tudo isso for feito, seu sistema estará usando as novas opções de USE.
2.c. Opções de USE específicas a pacotes
Vendo opções de USE disponíveis
Vamos tomar o exemplo do mozilla: que opções de USE ele escuta? Para descobrir, nós usamos o emerge com as opções --pretend e --verbose:
Listagem de código 3.1: Vendo todas opções de USE |
# emerge --pretend --verbose mozilla
These are the packages that I would merge, in order:
Calculating dependencies ...done!
[ebuild R ] www-client/mozilla-1.7.12-r2 USE="crypt gnome java mozsvg ssl
truetype xprint -debug -ipv6 -ldap -mozcalendar -mozdevelop -moznocompose
-moznoirc -moznomail -moznoxft -postgres -xinerama" 0 kB
|
O emerge não é a única ferramenta para esta tarefa. Na verdade, temos uma ferramenta dedicada a informações de pacotes chamada equery que reside no pacote gentoolkit. Primeiro, instale o gentoolkit:
Listagem de código 3.2: Instalando o gentoolkit |
# emerge gentoolkit
|
Agora rode equery com o argumento uses para ver as opções de USE de um certo pacote. Por exemplo, para o pacote gnumeric:
Listagem de código 3.3: Usando o equery para ver opções de USE |
# equery uses gnumeric [ Colour Code : set unset ] [ Legend : (U) Col 1 - Current USE flags ] [ : (I) Col 2 - Installed With USE flags ] U I [ Found these USE variables in : app-office/gnumeric-1.2.0 ] - - libgda : Adds GNU Data Access (CORBA wrapper) support for gnumeric - - gnomedb : unknown + + python : Adds support/bindings for the Python language + + bonobo : Adds support for gnome-base/bonobo (Gnome CORBA interfaces) |
3.a. Funcionalidades do Portage
O Portage tem várias funções adicionais que tornam sua experiência com o Gentoo ainda melhor. Várias dessas funcionalidades dependem de algumas ferramentas de software que melhoram performance, confiabilidade, segurança ...
Para ligar ou desligar algumas funcionalidades do Portage você precisa editar a variável FEATURES do arquivo /etc/make.conf, que contém as várias palavras-chave de funcionalidades, separadas por espaços em branco. Em vários casos você também precisará instalar uma ferramenta adicional de qual a funcionalidade depende.
Nem todas as funções que o Portage suporta estão listadas aqui. Para uma lista completa, consulte a página de manual do make.conf:
Listagem de código 1.1: Consultando a página de manual do make.conf |
$ man make.conf
|
Para descobrir o que está ajustado por padrão em FEATURES, rode emerge --info e procure pela variável FEATURES ou pegue-a com o grep:
Listagem de código 1.2: Descobrindo o que já está na variável FEATURES |
$ emerge --info | grep FEATURES
|
O distcc é um programa usado para distribuir compilações através de várias máquinas, não necessariamente idênticas, em uma rede. O cliente de distcc envia toda informação necessária para os servidores de distcc (rodando distccd) para que eles possam compilar pedaços de código fonte para o cliente. O resultado final é um tempo de compilação menor.
Você pode encontrar mais informações sobre o distcc (e como fazer com que funcione com o Gentoo em nossa Documentação de distcc do Gentoo.
O distcc vem com um monitor gráfico para controlar tarefas que o seu computador está enviando para compilação. Se você usa Gnome, coloque 'gnome' em sua variável de USE. Senão, se você não usa gnome e ainda quiser ter o monitor, você deve colocar 'gtk' na variável de USE.
Listagem de código 2.1: Instalando o distcc |
# emerge distcc
|
Adicione distcc à variável FEATURES dentro de /etc/make.conf. A seguir, edite a variável MAKEOPTS de acordo com sua preferência. Um guia padrão é colocar "-jX" onde X é o número de CPUs rodando distccd (incluindo o host atual) mais um, mas você pode ter resultados melhores com outros números.
Agora rode distcc-config e digite a lista de servidores de distcc disponíveis. Por simples exemplo, presumimos que os servidores de DistCC disponíveis são 192.168.1.102 (o host atual), 192.168.1.103 e 192.168.1.104 (dois hosts remotos):
Listagem de código 2.2: Configurando o distcc para usar os três servidores de distcc disponíveis |
# distcc-config --set-hosts "192.168.1.102 192.168.1.103 192.168.1.104"
|
Não se esqueça de rodar o daemon de distccd também:
Listagem de código 2.3: Iniciando os daemons de distccd |
# rc-update add distccd default # /etc/init.d/distccd start |
3.c. Fazendo cachê da compilação
O ccache é um cachê para compilações rápidas. Quando você compila um programa, ele fará cachê de resultados intermediários para que, quando quer que você recompilar o mesmo programa, o tempo de compilação seja drasticamente reduzido. Em compilações comuns isso pode resultar em compilações de 5 a 10 vezes mais rápidas.
Se você estiver interessado no funcionamento do ccache, por favor visite a homepage do ccache.
Para instalar o ccache, rode emerge ccache:
Listagem de código 3.1: Instalando o ccache |
# emerge ccache
|
Abra o /etc/make.conf e coloque ccache na variável FEATURES. A seguir, adicione a variável chamada CCACHE_SIZE e ajuste-a para "2G":
Listagem de código 3.2: Editando o CCACHE_SIZE no /etc/make.conf |
CCACHE_SIZE="2G" |
Para ver se o ccache está funcionando, peça ao ccache que dê suas estatísticas. Já que o Portage usa um diretório de home de ccache diferente, você também precisa configurar a variável CCACHE_DIR:
Listagem de código 3.3: Vendo estatísticas do ccache |
# CCACHE_DIR="/var/tmp/ccache" ccache -s
|
O local /var/tmp/ccache é o diretório home de ccache padrão do Portage; se você quiser alterar este ajuste, você pode configurar a variável CCACHE_DIR no /etc/make.conf.
No entanto, se você rodar ccache, ele irá usar o local padrão ${HOME}/.ccache, motivo pelo qual você precisou configurar a variável CCACHE_DIR na hora de pedir as estatísticas de ccache (do Portage).
Usando o ccache em compilações alheias ao Portage
Se você quiser usar o ccache para compilações alheias ao Portage, adicione /usr/lib/ccache/bin ao começo de sua variável PATH (antes de /usr/bin). Isto pode ser feito editando /etc/env.d/00basic, que é o primeiro arquivo ambiental que define a variável PATH:
Listagem de código 3.4: Editando /etc/env.d/00basic |
PATH="/usr/lib/ccache/bin:/opt/bin"
|
3.d. Suporte a pacotes binários
Criando pacotes pré-construídos
O Portage suporta a instalação de pacotes pré-construídos. Embora o Gentoo não forneça pacotes construídos (fora os snapshots de GRP), pode-se tornar o Portage totalmente ciente de pacotes pré-construídos.
Para criar um pacote pré-construído você pode usar o comando quickpkg se o pacote já estiver instalado em seu sistema, ou emerge com as opções --buildpkg ou --buildpkgonly.
Se você quiser que o Portage crie pacotes pré-construídos de cada pacote que você instalar, adicione buildpkg à variável FEATURES.
Suporte estendido para criar estágios de pacotes pré-construídos pode ser obtido com o catalyst. Para mais informações sobre o catalyst por favor leia o Manual de Referência do Catalyst e o Guia de perguntas freqüentes do Catalyst.
Instalando pacotes pré-construídos
Embora o Gentoo não forneça um, você pode criar um repositório central onde você grava pacotes pré-construídos. Se você quiser usar este repositório, você precisa tornar o Portage ciente dele fazendo com que a variável PORTAGE_BINHOST aponte para ele. Por exemplo, se os pacotes pré-construídos estiverem em ftp://buildhost/gentoo:
Listagem de código 4.1: Configurando PORTAGE_BINHOST no /etc/make.conf |
PORTAGE_BINHOST="ftp://buildhost/gentoo" |
Quando você quiser instalar um pacote pré-construído, adicione a opção --getbinpkg ao comando emerge junto com a opção --usepkg. A primeira opção diz ao emerge para baixar os pacotes pré-construídos do servidor definido anteriormente, enquanto a segunda pede ao emerge que tente instalar o pacote pré-construído primeiro antes de baixar as fontes e compilá-las.
Por exemplo, para instalar o gnumeric com pacotes pré-construídos:
Listagem de código 4.2: Instalando um pacote pré-construído do gnumeric |
# emerge --usepkg --getbinpkg gnumeric
|
Mais informações sobre as opções dos pacotes pré-construídos do emerge podem ser encontradas na página de manual do emerge:
Listagem de código 4.3: Lendo a página de manual do emerge |
$ man emerge
|
Quando você carregar seu sistema, você perceberá textos passarem. Se você prestar atenção, você verá que o texto é o mesmo toda vez que você reinicia seu sistema. A seqüência dessas ações é chamada de seqüência de início e é (mais ou menos) definida estaticamente.
Primeiro, seu gerenciador de inicialização irá carregar a imagem de kernel que você tem definida na configuração do gerenciador na memória, depois falando para a CPU rodar o kernel. Quando o kernel é carregado e rodado, ele inicializa todas estruturas e tarefas específicas do kernel e roda o processo de init.
O processo então verifica que todos sistemas de arquivos (definidos em /etc/fstab) estão montados e prontos para serem usados. Então ele executa vários scripts localizados em /etc/init.d, o que inicia os serviços que você precisa para ter um sistema carregado com sucesso.
Finalmente, quando todos scripts são executados, o init ativa os terminais (na maior parte só os consoles virtuais que estão escondidos através de Alt-F1, Alt-F2, etc.) chamando um processo especial chamado agetty. Este processo irá então certificar-se que você poder se logar nos terminais rodando login.
O init não roda os scripts em /etc/init.d aleatoriamente. Mais ainda, ele não roda todos scripts em /etc/init.d, só os que são ditos para ele executar. Ele decide que scripts executar olhando em /etc/runlevels.
Primeiro, o init roda todos scripts de /etc/init.d que têm links simbólicos dentro de /etc/runlevels/boot. Normalmente, ele irá iniciar os scripts em ordem alfabética, mas alguns scripts tem informações sobre dependências neles, avisando o sistema de que outro script deve ser rodado antes dele poder ser iniciado.
Quando todos scripts de referência de /etc/runlevels/boot são executados, o init continua carregando os scripts que têm um link simbólico para eles em /etc/runlevels/default. Novamente, ele usa a ordem alfabética para decidir que script rodar primeiro, a menos que um script tenha informações de dependências nele, caso em que a ordem é mudada para a fornecer uma seqüência de inicialização válida.
Claro que o init decide tudo sozinho. Ele precisa de um arquivo de configuração que especifica que ações devem ser tomadas. Este arquivo de configuração chama-se /etc/inittab.
Se você lembra da seqüência de inicialização que acabamos de descrever, você irá lembrar-se que a primeira ação do init é montar os sistemas de arquivos. Isto é definido na seguinte linha do /etc/inittab:
Listagem de código 1.1: A linha de inicialização de sistema em /etc/inittab |
si::sysinit:/sbin/rc sysinit |
A linha diz para o init que ele deve rodar /sbin/rc sysinit para inicializar o sistema. O script /sbin/rc toma conta da inicialização, o que permite que você diga que o init não faz tanto -- ele delega tarefas de inicialização do sistema para outro processo.
Segundo, o init executou todos scripts que tinham links simbólicos em /etc/runlevels/boot. Isto é definido na seguinte linha:
Listagem de código 1.2: A inicialização do sistema, continuado |
rc::bootwait:/sbin/rc boot |
Novamente o script rc faz as tarefas necessárias. Note que a opção dada para o rc (boot) é a mesma que o subdiretório de /etc/runlevels que é usado.
Neste ponto o init verifica seu arquivo de configuração para ver que runlevel ele deve rodar. Para decidir isso, ele lê a seguinte linha do /etc/inittab:
Listagem de código 1.3: A linha initdefault |
id:3:initdefault: |
Neste caso (que é o que a maioria dos usuários do Gentoo usam), o id do runlevel é 3. Usando essa informação, o init verifica o que ele deverodar para iniciar o runlevel 3:
Listagem de código 1.4: As definições de runlevel |
l0:0:wait:/sbin/rc shutdown l1:S1:wait:/sbin/rc single l2:2:wait:/sbin/rc nonetwork l3:3:wait:/sbin/rc default l4:4:wait:/sbin/rc default l5:5:wait:/sbin/rc default l6:6:wait:/sbin/rc reboot |
A linha que define o level 3, novamente, usa o script rc para iniciar os serviços (agora com o argumento default). Novamente note que o argumento do rc é o mesmo que o subdiretório de /etc/runlevels.
Quando o rc termina, o init decide que consoles virtuais ele deve ativar e que comandos precisam ser rodados em cada console:
Listagem de código 1.5: A definição de consoles virtuais |
c1:12345:respawn:/sbin/agetty 38400 tty1 linux c2:12345:respawn:/sbin/agetty 38400 tty2 linux c3:12345:respawn:/sbin/agetty 38400 tty3 linux c4:12345:respawn:/sbin/agetty 38400 tty4 linux c5:12345:respawn:/sbin/agetty 38400 tty5 linux c6:12345:respawn:/sbin/agetty 38400 tty6 linux |
Você viu que o init usa um esquema de numeração para decidir que runlevel ele deve ativar. Um runlevel é um estado em que seu sistema está rodando e contém uma coleção de scripts (scripts de runlevel ou initscripts) que devem ser executados quando você entra ou sai de um runlevel.
No Gentoo, existem sete runlevels definidos: três runlevels internos, e quatro definidos pelo usuário. Os runlevels internos são chamados de sysinit, shutdown e reboot e fazem exatamente o que seus nomes implicam: iniciar o sistema, desligar o sistema e reiniciar o sistema.
Os runlevels definidos por usuário são aqueles com um subdiretório /etc/runlevels acompanhante: boot, default, nonetwork e single. O runlevel boot inicia todos serviços necessários ao sistema que os outros runlevels usam. Os três runlevels restantes diferem em que serviços eles iniciam: O default é usado para operações rotineiras, nonetwork é usado em caso nenhuma conexão de rede é necessária, e single é usado para quando você necessita consertar o sistema.
Trabalhando com scripts de init
Os scripts que o processo rc chama podem ser executados com os argumentos start, stop, restart, pause, zap, status, ineed, iuse, needsme, usesme ou broken.
Para iniciar, parar ou reiniciar um serviço (e todos serviços dependentes), start, stop e restart devem ser usados:
Listagem de código 1.6: Iniciando o postfix |
# /etc/init.d/postfix start
|
Nota: Só os serviços que precisam (need) do serviço são parados ou reiniciados. Os outros serviços dependentes (aqueles que usam (use) o serviço mas não precisam dele) não são tocados. |
Se você quiser parar um serviço, mas não os serviços que dependem dele, você pode usar o argumento pause:
Listagem de código 1.7: Parando o postfix mas mantendo os serviços dependentes rodando |
# /etc/init.d/postfix pause
|
Se você quiser ver que status um serviço tem (iniciado, parado, pausado, ...) você pode usar o argumento status:
Listagem de código 1.8: Informações de status do postfix |
# /etc/init.d/postfix status
|
Se as informações de status disserem que o serviço está rodando, mas você sabe que não, você pode voltar o status da informação para "parado" com o argumento zap:
Listagem de código 1.9: Voltando as informações de status para o postfix |
# /etc/init.d/postfix zap
|
Para também pedir que dependências um serviço tem, você pode usar iuse ou ineed. Com ineed você pode ver que serviços são realmente necessários para o funcionamento correto do serviço. iuse por outro lado mostra que serviços são usados pelo serviço, mas não são necessários para o funcionamento correto.
Listagem de código 1.10: Pedindo uma lista de todos serviços necessários do qual o postfix depende |
# /etc/init.d/postfix ineed
|
De maneira parecida, você pode perguntar que serviços necessitam do serviço (needsme) ou podem usá-lo (usesme):
Listagem de código 1.11: Pedindo uma lista de todos serviços que precisam do postfix |
# /etc/init.d/postfix needsme
|
Finalmente, você pode perguntar que dependências o serviço precisa que estão faltando:
Listagem de código 1.12: Pedindo uma lista de dependências que estão faltando para o postfix |
# /etc/init.d/postfix broken
|
4.b. Trabalhando com o rc-update
O sistema de inicialização do Gentoo usa uma árvore de dependências para decidir que serviço precisa ser iniciado primeiro. Como isso é uma tarefa tediosa e não poderíamos esperar que nossos usuários tivessem de fazê-lo manualmente, nós criamos ferramentas que facilitam a administração dos runlevels e scripts de init.
Com o rc-update você pode adicionar ou remover scripts de init de um runlevel. A ferramenta rc-update irá então pedir automaticamente para o script depscan.sh reconstruir a árvore de dependências.
Adicionando e removendo serviços
Você já adicionou os scripts de init ao runlevel "default" durante a instalação do Gentoo. Naquela hora você talvez não tinha idéia do que "default" era, mas agora você deve ter. O script rc-update necessita de um segundo argumento que define a ação: add (adicionar), del (remover) ou show (mostrar).
Para adicionar ou remover um script de init, apenas dê ao rc-update o argumento add (adicionar) ou del (remover), seguido pelo script de init e runlevel. Por exemplo:
Listagem de código 2.1: Removendo o postfix do runlevel default |
# rc-update del postfix default
|
O comando rc-update show irá mostrar todos scripts de init disponíveis e listar em que runlevels eles executam:
Listagem de código 2.2: Recebendo informações dos scripts de init |
# rc-update show
|
Por que a necessidade de configuração adicional?
Os scripts de init podem ser bem complexos. Portanto, não é realmente desejável fazer com que os usuários editem o script de init diretamente, o que faria a tarefa mais capaz de erros. No entanto, é importante poder configurar tal serviço. Por exemplo, você pode querer dar mais opções ao serviço.
Um segundo motivo para ter a configuração fora do script de init é poder atualizar os scripts de init sem medo de que mudanças na configuração sejam desfeitas.
O Gentoo fornece um jeito fácil de configurar um serviço: cada script de init que pode ser configurado em um arquivo em /etc/conf.d. Por exemplo, o script de init do apache2 (chamado de /etc/init.d/apache2) tem um arquivo de configuração chamado de /etc/conf.d/apache2, que pode conter as opções que você quer dar ao servidor do Apache 2 quando ele é iniciado:
Listagem de código 3.1: Variável definida em /etc/conf.d/apache2 |
APACHE2_OPTS="-D PHP4" |
Um arquivo de configuração contém variáveis e somente variáveis (como o /etc/make.conf), tornando fácil a configuração de serviços. Também permite a nos dar mais informações sobre as variáveis (como comentários).
4.d. Escrevendo scripts de init
Não, escrever um script de init não é normalmente necessário já que o Gentoo fornece scripts de init prontos para todos os serviços fornecidos. No entanto, talvez você queira instalar um serviço sem usar o Portage, casto tal em que você provavelmente vai ter que criar um script de init.
Não use o script de init fornecido pelo serviço se ele não for explicitamente escrito para o Gentoo: os scripts de init do Gentoo não são compatíveis com os scripts de init usados por outras distribuições!
O arranjo básico de um script de init é mostrado abaixo.
Listagem de código 4.1: Arranjo básico de um script de init |
#!/sbin/runscript
depend() {
(Informações de dependências)
}
start() {
(Comandos necessários para iniciar o serviço)
}
stop() {
(Comandos necessários para parar o serviço)
}
restart() {
(Comandos necessários para reiniciar o serviço)
}
|
Qualquer script de init precisa de uma função start() definida. Todas outras seções são opcionais.
Existem duas dependências que você pode definir: use e need. Como nós já mencionamos, a dependência need é mais rígida que a dependência use. Após o tipo de dependência você digitar o serviço de que você depende, ou a dependência virtual.
Uma dependência virtual é uma dependência que um serviço fornece, mas não é somente fornecido por aquele serviço. Seu script de init pode depender de um logger de sistema, mas existem muitos loggers de sistema disponíveis (metalogd, syslog-ng, sysklogd, ...). Como você não pode precisar (need) de cada um deles (nenhum sistema normal tem todos esses loggers de sistemas instalados e rodando) nós nos certificamos que todos esses serviços fornecem (provide) uma dependência virtual.
Vamos ver as informações de dependência do serviço do postfix.
Listagem de código 4.2: Informações de dependência do postfix |
depend() {
need net
use logger dns
provide mta
}
|
Como você pode ver, o serviço do postfix:
Em alguns casos você pode não precisar de um serviço, mas que querer que seu serviço seja iniciado antes (before) (ou depois, after) de outro serviço se ele estiver disponível no sistema (note a condição - não é mais uma dependência) e rodar no mesmo runlevel (note a condição - só serviços do mesmo runlevel estão envolvidos). Você pode fornecer esta informação usando os ajustes before e after.
Como um exemplo nós vemos as configurações do serviço portmap:
Listagem de código 4.3: A função depend() no serviço portmap |
depend() {
need net
before inetd
before xinetd
}
|
Você também pode usar "*" para englobar todos serviços do mesmo runlevel, embora isso não seja recomendável.
Listagem de código 4.4: Rodando um script de init como o primeiro script do runlevel |
depend() {
before *
}
|
Próximo da função do depend(),você também precisa definir a função start(). Esta contém todos comandos necessários para iniciar seu serviço. É recomendável usar as funções ebegin e eend para informar o usuário sobre o que está acontecendo:
Listagem de código 4.5: Exemplo de função start() |
start() {
ebegin "Iniciando meu_serviço"
start-stop-daemon --start --quiet --exec /caminho/para/meu_serviço
eend $?
}
|
Se você precisa de mais exemplos da função start(), por favor leia o código fonte de scritps de init disponíveis no diretório /etc/init.d. Para o start-stop-daemon, existe uma excelente página de man disponível se você precisar de mais informações:
Listagem de código 4.6: Lendo a página de man para o start-stop-daemon |
# man start-stop-daemon
|
Outras funções que você pode definir são: stop() e restart(). Você não é obrigado a definir essas funções! Nosso sistema de init é inteligente o suficiente para preencher essas funções sozinho se você usar o start-stop-daemon.
A sintaxe do script de init do Gentoo é baseada em Bourne Again Shell (bash), então você é livre para usar construções compatíveis com bash dentro de seu script de init.
Adicionando opções personalizadas
Se você quiser que seu script de init suporte mais opções que as que você já encontrou, você deve adicionar a opção à variável opts variable, e criar uma função com o mesmo nome da opção. Por exemplo, para suportar uma opção chamada restartdelay:
Listagem de código 4.7: Suportando a opção restartdelay |
opts="${opts} restartdelay"
restartdelay() {
stop
sleep 3 # Esperar 3 segundos antes de começar de novo
start
}
|
Variáveis de configuração de serviço
Você não precisa fazer nada para suportar um arquivo de configuração em /etc/conf.d: se seu script de init é executado, os seguintes arquivos são automaticamente lidos (isto é, as variáveis estão disponíveis para uso):
Também, se seu script de init fornece uma dependência virtual (como net), o arquivo associado com aquela dependência (como /etc/conf.d/net) será lido também.
4.e. Mudando o comportamento do runlevel
Quem pode tirar proveito disso?
Muitos usuários de laptop conhecem a situação: em casa precisam iniciar o net.eth0, enquanto você não quer iniciar o net.eth0 quando você está fora (já que não há rede disponível). Como o Gentoo você pode mudar o comportamento do runlevel de acordo com sua vontade.
Por exemplo você pode criar um segundo runlevel "default" que você pode iniciar que tem scripts de init associados. Você pode então selecionar na hora da inicialização que runlevel default você quer usar.
Antes de tudo, criamos o diretório runlevel para o segundo runlevel "default". Como um exemplo, nós criamos o runlevel offline:
Listagem de código 5.1: Criando um diretório de runlevel |
# mkdir /etc/runlevels/offline
|
Adicione os scripts de init aos runlevels recentemente criados. Por exemplo, se você quer ter uma cópia exata de seu runlevel default atual sem o net.eth0:
Listagem de código 5.2: Adicionando os scripts de init necessários |
(Copie todos serviços do runlevel default para o runlevel offline) # cd /etc/runlevels/default # for service in *; do rc-update add $service offline; done (Remova serviços não desejados do runlevel offline) # rc-update del net.eth0 offline (Mostrar serviços ativos para o runlevel offline) # rc-update show offline (Exemplo parcial de saída) acpid | offline domainname | offline local | offline net.eth0 | |
Agora edite sua configuração de gerenciador de inicialização e adicione uma entrada para o runlevel offline. Por exemplo, no /boot/grub/grub.conf:
Listagem de código 5.3: Adicionando uma entrada para o runlevel offline |
title Gentoo Linux uso offline
root (hd0,0)
kernel (hd0,0)/kernel-2.4.25 root=/dev/hda3 softlevel=offline
|
Pronto, está tudo configurado. Se você iniciar seu sistema e selecionar a nova entrada na inicialização, o runlevel offline será usado no lugar do default.
Usar o bootlevel é completamente análogo ao softlevel. A única diferença aqui é que você define um segundo runlevel de "boot" ao invés de um segundo runlevel "default".
Uma variável de ambiente é um objeto nomeado que contém informações usadas por um ou mais aplicativos. Muitos usuários (especialmente os novos no Linux) acham isso um pouco estranho e inútil. Mas isso é errado: as variáveis de ambiente permitem modificar a configuração de um ou mais aplicativos facilmente.
A tabela a seguir lista diversas variáveis usadas por um sistema Linux e descreve seu uso. Valores de exemplo são apresentados após a tabela.
| Variável | Descrição |
| PATH | Esta variável contém uma lista de diretórios separados por dois-pontos nos quais o seu sistema procurará arquivos executáveis. Se você entrar com o nome de um executável (como por exemplo ls, rc-update ou emerge), mas esse executável não estiver localizado num diretório listado, o seu sistema não o executará (a menos que você entre o caminho completo no comando, como /bin/ls). |
| ROOTPATH | Esta variável tem a mesma função de PATH, porém só lista os diretórios que devem ser verificados quando o superusuário digitar um comando. |
| LDPATH | Esta variável contém uma lista de diretórios separados por dois-pontos nos quais o linkador dinâmico procura bibliotecas. |
| MANPATH | Esta variável contém uma lista de diretórios separados por dois-pontos nos quais o comando man deve procurar as páginas de manual. |
| INFODIR | Esta variável contém uma lista de diretórios separados por dois-pontos nos quais o comando info procura as páginas de info. |
| PAGER | Esta variável contém o caminho para o programa usado para listar os conteúdos dos arquivos (como less ou more, por exemplo). |
| EDITOR | Esta variável contém o caminho para o programa usado para modificar o conteúdo de arquivos (como nano ou vi). |
| KDEDIRS | Esta variável contém uma lista de diretórios separados por dois-pontos que contém material específico do KDE. |
| CLASSPATH | Esta variável contém uma lista de diretórios separados por dois-pontos que contêm as classes de Java. |
| CONFIG_PROTECT | Esta variável contém uma lista delimitada por espaçosde diretórios que devem ser protegidos pelo Portage durante atualizações. |
| CONFIG_PROTECT_MASK | Esta variável contém uma lista de diretórios separados por espaços que devem ser protegidos pelo Portage durante as atualizações. |
Abaixo você encontra um exemplo de definição de todas essas variáveis:
Listagem de código 1.1: Exemplos de definições |
PATH="/bin:/usr/bin:/usr/local/bin:/opt/bin:/usr/games/bin"
ROOTPATH="/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin"
LDPATH="/lib:/usr/lib:/usr/local/lib:/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3"
MANPATH="/usr/share/man:/usr/local/share/man"
INFODIR="/usr/share/info:/usr/local/share/info"
PAGER="/usr/bin/less"
EDITOR="/usr/bin/vim"
KDEDIRS="/usr"
CLASSPATH="/opt/blackdown-jre-1.4.1/lib/rt.jar:."
CONFIG_PROTECT="/usr/X11R6/lib/X11/xkb /opt/tomcat/conf \
/usr/kde/3.1/share/config /usr/share/texmf/tex/generic/config/ \
/usr/share/texmf/tex/platex/config/ /usr/share/config"
CONFIG_PROTECT_MASK="/etc/gconf
|
5.b. Definindo variáveis globalmente
Para centralizar as definições dessas variáveis, o Gentoo introduziu o diretório /etc/env.d. Dentro deste diretório você encontrará diversos arquivos, como por exemplo 00basic, 05gcc, etc... que contêm as variáveis necessárias para o aplicativo mencionado no nome.
Por exemplo, quando você instalou o gcc, um arquivo chamado 05gcc foi criado pelo ebuild, contendo as definições das seguintes variáveis:
Listagem de código 2.1: /etc/env.d/05gcc |
PATH="/usr/i686-pc-linux-gnu/gcc-bin/3.2" ROOTPATH="/usr/i686-pc-linux-gnu/gcc-bin/3.2" MANPATH="/usr/share/gcc-data/i686-pc-linux-gnu/3.2/man" INFOPATH="/usr/share/gcc-data/i686-pc-linux-gnu/3.2/info" CC="gcc" CXX="g++" LDPATH="/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3" |
Outras distribuições dizem para você alterar ou adicionar essas variáveis de ambiente em /etc/profile ou outros locais. O Gentoo, por outro lado, torna fácil para você (e para o Portage) manter e gerenciar as variáveis de ambiente sem ter que prestar atenção aos inúmeros arquivos que podem contê-las.
Por exemplo, quando o gcc é atualizado, o arquivo /etc/env.d/05gcc também é atualizado sem precisar de interação com o usuário.
Isto beneficia não só o Portage, mas você também, como usuário. Eventualmente pode ser pedido a você que determine uma certa variável de ambiente de sistema. Como exemplo, vejamos a variável http_proxy. Em vez de mexer em /etc/profile, você agora pode simplesmente criar um arquivo (/etc/env.d/99local) e entrar as suas definições nele:
Listagem de código 2.2: /etc/env.d/99local |
http_proxy="proxy.server.com:8080" |
Usar o mesmo arquivo para todas as suas variáveis é uma forma de ter uma rápida visão das variáveis que você definiu pessoalmente.
Vários arquivos em /etc/env.d definem a variável PATH. Isto não está errado: quando você executa env-update, as várias definições são adicionadas antes de atualizar as variáveis de ambiente, desta forma tornando fácil para os pacotes (ou usuários) adicionarem suas próprias definições de variáveis de ambiente sem interferir com os valores já existentes.
O script env-update acrescentará os valores em ordem alfabética dos arquivos em /etc/env.d. Os nomes de arquivos devem começar com dois dígitos decimais.
Listagem de código 2.3: Ordem de atualização usada pelo env-update |
00basic 99kde-env 99local
+-------------+----------------+-------------+
PATH="/bin:/usr/bin:/usr/kde/3.2/bin:/usr/local/bin"
|
A concatenação de variáveis nem sempre acontece, só com as seguintes variáveis: KDEDIRS, PATH, CLASSPATH, LDPATH, MANPATH, INFODIR, INFOPATH, ROOTPATH, CONFIG_PROTECT, CONFIG_PROTECT_MASK, PRELINK_PATH e PRELINK_PATH_MASK. Para todas outras variáveis, o último valor definido (em ordem alfabética dos arquivos em /etc/env.d) é usado.
Quando você executa env-update, o script cria todas as variáveis de ambiente e as coloca em /etc/profile.env (que é usado pelo /etc/profile). Ele também extrai as informações da variável LDPATH e as usa para criar o /etc/ld.so.conf. Em seguida, ele roda o ldconfig para recriar o arquivo /etc/ld.so.cache usado pelo linkador dinâmico.
Se você quiser ter uma idéia do efeito do env-update, imediatamente após rodá-lo execute o seguinte comando para atualizar seu ambiente. Os usuários que instalaram eles próprios o Gentoo provavelmente se lembrarão disso das instruções de instalação:
Listagem de código 2.4: Atualizando o ambiente |
# env-update && source /etc/profile
|
Nota: O comando acima só atualiza as variáveis em seu terminal atual, novos consoles e seus derivados. Portanto, se você estiver trabalhando no X11, você precisará ou digitar source /etc/profile em cada novo terminal que você abrir ou reiniciar o X para que todos novos terminais herdem as novas variáveis. Se você usar um gerenciador de log-in, torne-se administrador (root) e digite /etc/init.d/xdm restart. Se não, você precisará fazer log-out e log-in para que o X abra novos terminais com os novos valores de variáveis. |
5.c. Definindo variáveis localmente
Nem sempre você deve definir uma variável de ambiente globalmente. Por exemplo, você pode querer adicionar o diretório /home/usuario/bin e o diretório de trabalho atual (o diretório em que você está) à variável PATH, sem que todos os outros usuários do sistema a tenham em seus PATHs. Se você quiser definir uma variável de ambiente localmente, deve usar o ~/.bashrc ou o ~/.bash_profile:
Listagem de código 3.1: Estendendo o PATH para uso local no ~/.bashrc |
PATH="${PATH}:/home/usuario/bin"
|
Quando você re-logar, a sua variável PATH será atualizada.
Às vezes definições ainda mais estritas são necessárias. Você pode querer usar binários de um diretório temporário que você criou sem usar o caminho até os binários nem editar o ~/.bashrc para o pouco tempo que você precisará dele.
Neste caso, você pode simplesmente definir a variável PATH na sua sessão atual usando o comando export. Enquanto você não se deslogar, a variável PATH usará as definições temporárias.
Listagem de código 3.2: Definindo uma variável de ambiente específica a uma sessão |
# export PATH="${PATH}:/home/meu_usuário/tmp/usr/bin"
|
O Portage vem com um arquivo de configuração padrão gravado em /etc/make.globals. Quando você olhar, perceberá que toda configuração do Portage é feita através de variáveis. Quais variáveis o Portage escuta e para que servem é descrito mais adiante.
Já que muitas diretivas de configuração diferem entre arquiteturas, o Portage também tem o arquivos de configuração padrão como parte de seu profile (perfil). Seu profile é apontado pelo link simbólico /etc/make.profile; As configurações do Portage estão gravadas nos arquivos make.defaults de seu profile e todos outros profiles. Nós iremos explicar mais sobre os profiles e o diretório /etc/make.profile mais adiante.
Se você estiver planejando mudar uma variável de configuração, não altere /etc/make.globals ou make.defaults. Ao invés disso, use o arquivo /etc/make.conf que tem precedência sobre os arquivos anteriores. Você também irá encontrar um /etc/make.conf.example. Como o nome indica, é meramente um arquivo de exemplo - que o Portage não lê.
Você também pode definir uma variável de configuração do Portage como uma variável de ambiente, mas não recomendamos fazer isso.
Informações específicas de profiles (perfis)
Nós já encontramos o diretório /etc/make.profile Bem, esse não é exatamente um diretório, mas um link simbólico para um profile, por padrão um dentro de /usr/portage/profiles, embora você possa criar seu próprio profile em outro lugar e apontar para ele. O profile para o qual esse link simbólico aponta é o profile a que seu sistema adere.
Um profile contém informações de específicas de cada arquitetura para o Portage, como uma lista de pacotes que pertencem ao sistema correspondendo àquele profile, uma lista de pacotes que não funcionam (ou estão mascarados) para aquele profile, etc...
Configurações específicas de usuário
Quando você precisar sobre-escrever o comportamento do Portage em relação à instalação de software, você deverá editar arquivos dentro de /etc/portage. É muito recomendável que você use os arquivos dentro de /etc/portage e muito desencorajado a sobre-escrita através de variáveis de ambiente!
Dentro de /etc/portage você pode criar os seguintes arquivos:
Mais informações sobre o diretório /etc/portage e uma lista completa de arquivos possíveis que você pode criar podem ser encontrados na página de man do Portage:
Listagem de código 1.1: Lendo a página de man do Portage |
$ man portage
|
Mudando locais de arquivos & diretórios do Portage
Os arquivos de configuração mencionados anteriormente não podem ser guardados em outros locais - o Portage sempre irá buscar os arquivos de configuração nesses locais exatos. Todavia, o Portage usa outros locais para vários outros propósitos: diretório de construção, armazenamento de código-fonte, local da árvore do Portage, ...
Todos os propósitos tem locais padrões bem conhecidos, mas que podem ser alterados para seu próprio gosto através do /etc/make.conf. O resto deste capítulo explica que locais de propósito especial o Portage usa e como alterar sua colocação em seu sistema de arquivos.
Este documento não é para ser tomado como referência, no entanto. Se você precisa de cobertura 100% completa, por favor consulte as páginas de man do Portage e do make.conf:
Listagem de código 1.2: Lendo as páginas de man do Portage e do make.conf |
$ man portage $ man make.conf |
O local padrão da árvore do Portage é /usr/portage. Isto é definido pela variável PORTDIR. Quando você grava a árvore do Portage em outro lugar (ao alterar esta variável), não se esqueça de mudar o link simbólico /etc/make.profile de acordo.
Se você alterar a variável PORTDIR, você deve alterar as seguintes variáveis já que elas não irão notar a mudança do PORTDIR. Isto é devido a como o Portage lida com as variáveis: PKGDIR, DISTDIR, RPMDIR.
Embora o Portage não use pacotes binários pré-construídos por padrão, ele tem suporte extensivo para eles. Quando você pede para o Portage trabalhar com pacotes pré-construídos, ele irá procurá-los em /usr/portage/packages. Este local é definido pela variável PKGDIR.
O código-fonte das aplicações é gravado em /usr/portage/distfiles por padrão. Este local é definido pela variável DISTDIR.
Embora o Portage não possa usar arquivos RPM, é possível gerá-los usando o comando ebuild (veja A aplicação ebuild). O local padrão onde o Portage armazena arquivos RMP é /usr/portage/rpm e é definido pela variável RPMDIR.
O Portage guarda o estado de seu sistema (que pacotes são instalados, que arquivos pertencem a cada pacote, ...) em /var/db/pkg. Não altere estes arquivos manualmente! Pode causar problemas no conhecido do Portage sobre seu sistema.
O cachê do Portage (com horas de modificação, virtuals, informações da árvore de dependência, ...) é guardado em /var/cache/edb. Este local é realmente um cachê: você pode limpá-lo senão estiver rodando nenhuma aplicação relacionada ao Portage no momento.
Arquivos temporários do Portage
Os arquivos temporários do Portage são gravados em /var/tmp por padrão. Isto é definido pela variável PORTAGE_TMPDIR.
Se você alterar a variável PORTAGE_TMPDIR, você deve alterar as seguintes variáveis já que elas não irão perceber a mudança da PORTAGE_TMPDIR. Isto é devido ao modo com que o Portage lida com variáveis: BUILD_PREFIX.
O Portage cria diretórios específicos para cada pacote que eles instalada dentro de /var/tmp/portage. Este local é definido pela variável BUILD_PREFIX.
Local de sistema de arquivos em uso
Por padrão o Portage instala todos arquivos no sistema de arquivos atual (/), mas você pode mudar este ajuste usando a variável de ambiente ROOT. Isto é útil quando você quer criar imagens de construção.
O Portage pode criar arquivos de registro por ebuild, mas só quando a variável PORT_LOGDIR está configurada para algum lugar onde o Portage pode escrever (o usuário portage). Por padrão a variável está em branco.
Como notamos anteriormente, o Portage é configurado através de muitas variáveis que você deve definir em /etc/make.conf. Por favor verifique o manual do make.conf para informações mais completas:
Listagem de código 1.1: Lendo a página de man do make.conf |
$ man make.conf
|
2.b. Opções específicas de construção
Opções de configuração e compilação
Quando o Portage constrói aplicações, ele passa os conteúdos das seguintes variáveis aos scripts de compilador e configuração:
A variável de USE também é usada durante configuração e compilação, mas já foi explicada com grande detalhe em capítulos anteriores.
Quando o Portage instalou uma nova versão de um certo título de software, ele irá remover os arquivos obsoletos de uma versão mais antiga de seu sistema. O Portage dá ao usuário 5 segundos de espera antes de desinstalar a versão antiga. Esses 5 segundos são definidos pela variável CLEAN_DELAY.
2.c. Proteção de arquivos de configuração
O Portage sobre-escreve arquivos fornecidos por novas versões de um título se os arquivos não estão gravados em um local protegido. Estes locais protegidos são definidos pela variável CONFIG_PROTECT e são geralmente locais de arquivos de configuração. A lista de diretórios é delimitada por espaços.
Um arquivo que seria escrito em um local protegido é renomeado e o usuário é avisado sobre uma nova versão do arquivo (presumivelmente) de configuração.
Você pode saber o ajuste atual do CONFIG_PROTECT usando a saída do comando emerge --info:
Listagem de código 3.1: Obtendo o ajuste de CONFIG_PROTECT |
$ emerge --info | grep 'CONFIG_PROTECT='
|
Mais informações sobre a proteção de arquivos de configuração do Portage está disponível através do emerge:
Listagem de código 3.2: Mais informações sobre a proteção de arquivos de configuração do Portage |
$ emerge --help config
|
Para 'desproteger' certos sub-diretórios de locais protegidos você pode usar a variável CONFIG_PROTECT_MASK.
2.d. Opções para baixar arquivos
Quando a informação ou dado pedido não está disponível em seu sistema, o Portage irá baixar da Internet. As localizações de servidores para os vários canais de informações e dados são definidos pelas seguintes variáveis:
Um terceiro ajuste envolve a localização do servidor de rsync que você pode usar quando atualizar sua árvore do Portage:
As variáveis GENTOO_MIRRORS e SYNC podem ser configuradas automaticamente através da aplicação mirrorselect. Você precisa fazer emerge mirrorselect primeiro antes de poder usá-la. Para mais informações, veja a informação online do mirrorselect:
Listagem de código 4.1: Mais informações sobre o mirrorselect |
# mirrorselect --help
|
Se seu ambiente necessita que você use um servidor de proxy, você pode usar as variáveis HTTP_PROXY, FTP_PROXY e RSYNC_PROXY para declarar um servidor de proxy.
Quando o Portage precisa baixar código-fonte, ele usa o comando wget por padrão. Você pode usar isso através da variável FETCHCOMMAND.
O Portage pode continuar a baixar arquivos de código-fonte parcilamente baixado. Ele usa o wget por padrão, mas isso pode ser alterado através da variável RESUMECOMMAND.
Certifique-se de que seu FETCHCOMMAND e RESUMECOMMAND gravem o código-fonte no local correto. Dentro das variáveis você deve usar \${URI} e \${DISTDIR} para apontar o local de código-fonte e de distfiles respectivamente.
Você também pode definir ajustes específicos de protocolo com FETCHCOMMAND_HTTP, FETCHCOMMAND_FTP, RESUMECOMMAND_HTTP, RESUMECOMMAND_FTP, e assim em diante.
Você não pode alterar o comando de rsync usado pelo Portage para atualizar a ávore do Portage, mas você pode ajustar algumas variáveis relacionadas ao comando rsync:
Você pode mudar seu ramo padrão com a variável ACCEPT_KEYWORDS. Como padrão ela aponta para o ramo estável de seu arquitetura. Mais informações sobre os ramos do Gentoo pode ser encontrada no próximo capítulo.
Você pode ativar certas funções do Portage através da variável FEATURES. As funções do Portage foram discutidas nos capítulos anteriores, como em Funções do Portage.
Com a variável PORTAGE_NICENESS você pode augmentar ou reduzir o valor de nice com que o Portage roda. O valor PORTAGE_NICENESS é adicionado ao valor de nice atual.
Para mais informações sobre valores de nice, veja as páginas de man do nice:
Listagem de código 6.1: Mais informações sobre o nice |
$ man nice
|
A variável NOCOLOR, que tem como padrão "false", define se o Portage deve desligar o uso de saídas coloridas.
A variável ACCEPT_KEYWORDS define que ramo de software você usa em seu sistema. Por padrão ela é o ramo de software estável para sua arquitetura, por exemplo, x86.
Nós recomendados que você só uso o ramo estável. No entanto, se você não se importa muito com estabilidade e quer ajudar o Gentoo enviando relatos para o http://bugs.gentoo.org, leia mais.
Se você quiser usar o software mais recente disponível, você pode considerar usar o ramo de testes. Para que o Portage use o ramo de testes, adicione um ~ na frente de sua arquitetura.
O ramo de testes é exatamente o que diz ser - de testes Se um pacote estiver em testes, significa que os desenvolvedores acham que funciona, mas não foi testado completamente. Você pode muito bem ser o primeiro a descobrir um bug no pacote, caso em que você pode fazer um relato de bug para que os desenvolvedores saibam sobre ele.
Esteja alerta, no entanto, de que você pode perceber problemas de estabilidade, manuseio incorreto de pacotes (como dependências erradas/faltando), atualizações muito freqüentes (resultando em muita construção) ou pacotes quebrados. Se você não sabe como o Gentoo funciona e como resolver problemas, nós recomendamos que você fique com o ramo estável e testado.
Por exemplo, para selecionar o ramo de testes da arquitetura x86, edite o /etc/make.conf e coloque:
Listagem de código 1.1: Configurando a variável ACCEPT_KEYWORDS |
ACCEPT_KEYWORDS="~x86" |
Se você atualizar seu sistema agora, você verá que muitos pacotes serão atualizados. Esteja avisado, no entanto: quando você tiver atualizado seu sistema para usar o ramo de testes, normalmente não há jeito fácil de voltar ao ramo estável oficial (exceto com o uso de backups, claro).
3.b. Misturando ramo estável com de testes
Você pode pedir ao Portage para permitir o ramo de testes para um pacote em especial, mas usar o ramo estável para o resto do sistema. Para fazer isso, adicione a categoria do pacote e nome que você quer usar ao ramo de testes no arquivo /etc/portage/package.keywords. Por exemplo, para usar o ramo de testes para o gnumeric:
Listagem de código 2.1: configuração do /etc/portage/package.keywords para gnumerica, linha completa |
app-office/gnumeric ~x86 |
Se você quiser usar uma versão específica de um software do ramo de testes, mas você não quiser que o Portage use o ramo de testes para versões subseqüentes, você deve adicionar a versão no arquivo package.keywords. Neste caso você deve usar o operador =. Você também pode colocar uma amplitude de versões usando os operadores <=, <, > ou >=.
De qualquer forma, se você colocar informações de versão, você deve usar um operador. Se você deixar informações de versão de fora, você não pode usar um operador.
No exemplo seguinte nós pedimos que o Portage aceite o gnumeric-1.2.13:
Listagem de código 2.2: Ativando uma versão de testes em particular do gnumeric |
=app-office/gnumeric-1.2.13 ~x86 |
3.c. Usando pacotes mascarados
Os desenvolvedores do Gentoo não suportam o uso destes arquivos. Por favor tome o cuidado necessário na hora de usá-los. Pedidos de suporte relacionados a package.unmask e/ou package.mask não serão respondidos. Você foi avisado.
Quando um pacote foi mascarado pelos desenvolvedores do Gentoo e você ainda quer usá-lo, mesmo depois de ler o motivo mencionado no arquivo package.mask (localizado em /usr/portage/profiles por padrão), adicione a exata mesma linha em /etc/portage/package.unmask.
Por exemplo, se o =net-mail/hotwayd-0.8 estiver mascarado, você pode tirar a máscara adicionando a mesma exata linha no arquivo package.unmask:
Listagem de código 3.1: /etc/portage/package.unmask |
=net-mail/hotwayd-0.8 |
Quando você não quer que o Portage leve um certo pacote ou versão específica em consideração, você pode mascará-la você mesmo colocando uma linha apropriada em /etc/portage/package.mask.
Por exemplo se você não quer que o Portage instale novas fontes de kernel acima da gentoo-sources-2.6.8.1, você adiciona a seguinte linha ao package.mask:
Listagem de código 3.2: exemplo de /etc/portage/package.mask |
>sys-kernel/gentoo-sources-2.6.8.1 |
O etc-update é uma ferramenta que ajuda na instalação de arquivos ._cfg0000_<nome>. Ele fornece um ambiente de instalação interativo e também pode instalar automaticamente mudanças triviais. Arquivos ._cfg0000_<nome> são gerados pelo Portage quando ele quer sobre-escrever um arquivo em um diretório protegido pela variável CONFIG_PROTECT.
Rodar o etc-update é bem simples:
Listagem de código 1.1: Rodando o etc-update |
# etc-update
|
Depois de instalar as mudanças simples, você verá uma lista com arquivos protegidos que tem uma atualização pendente. No final você verá as opções possíveis:
Listagem de código 1.2: opções de etc-update |
Please select a file to edit by entering the corresponding number.
(-1 to exit) (-3 to auto merge all remaining files)
(-5 to auto-merge AND not use 'mv -i'):
|
Se você digitar -1, o etc-update irá sair sem fazer mais alterações. Se você apertar -3 ou -5, todos arquivos de configuração listados serão sobre-escritos com novas versões. É, portanto, muito importante selecionar primeiro os arquivos de configuração que não devem ser atualizados automaticamente. Isto é feito digitando o número listado à esquerda do arquivo de configuração.
Como um exemplo, nós selecionamos o arquivo de configuração /etc/pear.conf:
Listagem de código 1.3: Atualizando um arquivo de configuração específico |
Beginning of differences between /etc/pear.conf and /etc/._cfg0000_pear.conf
[...]
End of differences between /etc/pear.conf and /etc/._cfg0000_pear.conf
1) Replace original with update
2) Delete update, keeping original as is
3) Interactively merge original with update
4) Show differences again
|
Você pode ver agora as diferenças entre os dois arquivos. Se você acredita que o arquivo de configuração atualizado pode ser usado sem problemas, digite 1. Se você acredita que o arquivo de configuração atualizado não é necessário, ou não dá nenhuma informação nova ou útil, digite 2. Se você quiser atualizar o arquivo de configuração atual interativamente, digite 3.
Não existe motivo para elaborar o processo de atualização interativo aqui. Para sermos mais completos, nós listaremos os comando possíveis que você pode usar quando você está juntando dois arquivos interativamente. Você verá duas linhas (a original e a proposta) e um prompt no qual você pode digitar um dos seguintes comandos:
Listagem de código 1.4: Comandos disponíveis para atualização interativa |
ed: Editar e usar as duas versões, cada uma decorada com um cabeçalho. eb: Editar e usar as duas versões. el: Editar e usar a versão da esquerda. er: Editar e usar a versão da direita. e: Editar uma versão nova. l: Usar a versão da esquerda. r: Usar a versão da direita. s: Incluir silenciosamente linhas comuns. v: Incluir linhas comuns de maneira verbal. q: Sair. |
Quando você terminar de atualizar os arquivos de configuração importantes, você pode atualizar automaticamente todos outros arquivos de configuração. O etc-update irá sair se não encontrar mais arquivos de configuração que podem ser atualizados.
Ao usar o dispatch-conf você pode juntar atualizações a seus arquivos de configuração, monitorando todas mudanças. O dispatch-conf grava as diferenças entre os arquivos de configuração como patches ou usando o sistema de revisão RCS.
Como com o etc-update, você pode pedir para manter o arquivo de configuração como está, usar o novo arquivo de configuração, editar o atual ou juntar as mudanças interativamente. No entanto, o dispatch-conf também tem funções adicionais úteis:
Certifique-se de editar o /etc/dispatch-conf.conf primeiro e crie o diretório referenciado pela variável archive-dir.
Para mais informações, veja a página de manual do dispatch-conf:
Listagem de código 2.1: Lendo a página de manual do dispatch-conf |
$ man dispatch-conf
|
Com o quickpkg você pode criar arquivos dos pacotes que já estão instalados em seu sistema. Esses arquivos podem ser usados como pacotes pré-construídos. Rodar quickpkg é simples: só adicione os nomes dos pacotes que você quer arquivar.
Por exemplo, para arquivar curl, arts e procps:
Listagem de código 3.1: Exemplo de uso do quickpkg |
# quickpkg curl arts procps
|
Os pacotes pré-construídos serão gravados em $PKGDIR/All (/usr/portage/packages/All por padrão). Links simbólicos que apontam para esses pacotes são colocados em $PKGDIR/<categoria>.
5.a. Usando um sub-conjunto da árvore do Portage
Você pode fazer atualizações seletivas de certas categorias/pacotes e ignorar as outras categorias/pacotes. Nós podemos fazer isso ao dizer para o rsync excluir categorias/pacotes durante o passo emerge --sync.
Você precisa definir o nome do arquivo que contém os padrões de exclusão na variável RSYNC_EXCLUDEFROM em seu /etc/make.conf.
Listagem de código 1.1: Definindo o arquivo de exclusão em /etc/make.conf |
RSYNC_EXCLUDEFROM=/etc/portage/rsync_excludes |
Listagem de código 1.2: Excluindo todos tipos de games em /etc/portage/rsync_excludes |
games-*/* |
Note, no entanto, que isso pode levar a problemas de dependência, já que novos pacotes permitidos podem dependender de novos pacotes que foram excluídos na atualização.
5.b. Adicionando ebuilds não-oficiais
Definindo um diretório de overlay para o Portage
Você pode pedir para o Portage usar ebuilds que não estão disponíveis oficialmente através da árvore do Portage. Crie um novo diretório (por exemplo /usr/local/portage) em que você grava ebuilds de terceiros. Use a mesma estrutura de diretórios da árvore oficial do Portage!
Defina PORTDIR_OVERLAY no /etc/make.conf e faça com que aponte para o diretório definido anteriormente. Quando você usar o Portage agora, ele irá considerar essas ebuilds também sem removê-las/sobre-escrevê-las da próxima vez que você rodar emerge --sync.
Trabalhando com vários overlays
Para os usuários avançados que desenvolvem usando vários overlays, testam pacotes antes de chegar na árvore do Portage ou só querem usar ebuilds não-oficiais de várias fontes, o pacote app-portage/gentoolkit-dev traz gensync, uma ferramenta para ajudá-lo a manter os repositórios de overlay atualizados.
Com gensync você pode atualizar todos repositórios de uma vez, ou selecionar apenas alguns deles. Cada repositório deve ter um arquivo chamado .syncsource no diretório de configuração /etc/gensync/, contendo local do repositório, nome, identificação, etc...
Suponha que você tem dois repositórios adicionais chamados java (para ebuilds de java em desenvolvimento) e entapps (para aplicativos desenvolvidos em casa para seu negócio). Você pode atualizar estes repositórios da seguinte maneira:
Listagem de código 2.1: Usando gensync para atualizar repositórios |
# gensync java entapps
|
5.c. Software não-gerenciado pelo Portage
Usando o Portage com software gerenciado manualmente
Em alguns casos você quer configurar, instalar e manter software você mesmo, sem que o Portage automatize o processo para você, mesmo se o Portage puder fornecer os títulos de software. Casos comuns são fontes de kernel e drivers da nvidia. Você pode configurar o Portage para que ele saiba que certo pacote está instalado manualmente em seu sistema. Este processo é chamado de injeção e é suportado pelo Portage através do arquivo /etc/portage/profile/package.provided.
Por exemplo, se você quer informar o Portage sobre o vanilla-sources-2.6.11.6 que você instalou manualmente, adicione a seguinte linha ao /etc/portage/profile/package.provided:
Listagem de código 3.1: Linha de exemplo para o package.provided |
sys-kernel/vanilla-sources-2.6.11.6 |
A aplicação ebuild é uma interface de baixo nível com o sistema do Portage. Usando a aplicação você pode executar ações específicas em uma dada ebuild. Por exemplo, você pode fazer passos de instalação individuais você mesmo.
Usar ebuild serve mais para propósitos de desenvolvimento; mais informações sobre ebuild pode, logo, ser encontrado no Manual dos Desenvolvedores, em inglês. No entanto, iremos explicar que instâncias do ebuild são invocados pelo Portage durante o processo de instalação de um certo título de software, e como invocar os passos de pós-configuração que algumas ebuilds pedem que você faça.
6.b. Instalando software manualmente
Baixando as fontes & fazendo checksum delas
Quando você invoca ebuild em um dado arquivo de ebuild, ele verifica se as checksums de todos arquivos envolvidos são iguais às do Manifest acompanhante ou arquivo files/digest-<nome>-<versão>. Isso só acontece depois das fontes terem sido baixadas.
Para baixar as fontes usando ebuild, rode:
Listagem de código 2.1: Baixando as fontes |
# ebuild path/to/ebuild fetch
|
Se o md5sum da ebuild não bater com o listado no arquivo Manifest, ou uma das fontes baixadas não bater com as litadas no arquivo files/digest-<pacote>, você irá receber um erro parecido com o seguinte:
Listagem de código 2.2: Erro no checksum de um ebuild |
!!! File is corrupt or incomplete. (Digests do not match) >>> our recorded digest: db20421ce35e8e54346e3ef19e60e4ee >>> your file's digest: f10392b7c0b2bbc463ad09642606a7d6 |
A linha subseqüente irá mencionar o arquivo com erro.
Se você tiver certeza que as fontes que você baixou e o ebuild em si são válidos, você pode gerar manualmente o Manifest e o arquivo digest-<pacote> usando a função digest do ebuild:
Listagem de código 2.3: Gerando novo Manifest e digest |
# ebuild caminho/para/ebuild digest
|
Para desempacotar as fontes em /var/tmp/portage (ou qualquer outro local que você especificou em /etc/make.conf), rode a função unpack da ebuild:
Listagem de código 2.4: Desempacotando as fontes |
# ebuild caminho/para/ebuild unpack
|
Isto irá executar a função src_unpack() da ebuild (que tem como padrão a extração normal se nenhuma função src_unpack() é definida). É também nesse passo que todos patches necessários são aplicados.
O próximo passo no processo de instalação é compilar as fontes. A função compile da ebuild faz esse passo ao executar a função src_compile() da ebuild. Isto também faz os passos de configuração se necessários.
Listagem de código 2.5: Compilando as fontes |
# ebuild caminho/para/ebuild compile
|
É recomendado que você edite a função src_compile() da ebuild se você quiser mudar as instruções de compilação. No entanto, você também pode enganar o Portage a acreditar que a aplicação ebuild terminou os passos de compilação. Rode todos comandos necessários você mesmo e crie um arquivo vazio chamado .compiled no diretório de trabalho:
Listagem de código 2.6: Informando o Portage sobre trabalhos de compilação terminados |
# touch .compiled
|
Instalando os arquivos em um local temporário
No próximo passo o Portage irá instalar todos arquivos necessários em um local temporário. Este diretório irá conter todos arquivos que serão instalados no sistema de arquivos de uso. Você pode fazer isso rodando a função install da ebuild, que executa a função src_install() da ebuild:
Listagem de código 2.7: Instalando os arquivos |
# ebuild caminho/para/ebuild install
|
Instalando os arquivos em um sistema de arquivos de uso
O passo final é instalar todos arquivos no sistema de arquivos de uso e registrá-los no backend do Portage. O ebuild chama o passo de "qmerge" e envolve os seguintes passos:
Rode a função qmerge do ebuild para fazer esses passos:
Listagem de código 2.8: Instalando so arquivos no sistema de arquivos de uso |
# ebuild caminho/para/ebuild qmerge
|
Limpando o diretório temporário
Finalmente, você pode limpar o diretório temporário usando a função clean do ebuild:
Listagem de código 2.9: Limpando o diretório temporário |
# ebuild caminho/para/ebuild clean
|
6.c. Funções adicionais do ebuild
Rodando todos comandos relacionados ao merge
Usando a função merge do ebuild você pode rodar os comando fetch, unpack, compile, install e qmerge de uma só vez:
Listagem de código 3.1: Instalando software |
# ebuild caminho/para/ebuild merge
|
Algumas aplicações incluem instruções que configuram o pacote para uso em seu sistema. As instruções podem ser interativa e portanto não são executadas automaticamente. Para rodar os passos de configuração, que estão listadas na função opcional config() da ebuild, use a função config do ebuild:
Listagem de código 3.2: Configurando um pacote |
# ebuild caminho/para/ebuild config
|
Você pode instruir o Portage para criar um pacote binário de uma ebuild ou até mesmo um arquivo RPM. Use a função package ou rpm do ebuild para criar os arquivos. Existem algumas diferenças entre as duas funções, todavia:
Listagem de código 3.3: Criando pacotes |
(Para um pacote binário compatível com o Portage) # ebuild caminho/para/ebuild package (Para um pacote RPM) # ebuild caminho/para/ebuild rpm |
O arquivo RPM criado, no entanto, não tem a informação de dependências da ebuild.
Por favor, consulte as seguintes páginas de man para mais informações sobre o Portage, a aplicação ebuild e os arquivos do ebuild:
Listagem de código 4.1: Página de man |
$ man portage (O próprio Portage) $ man emerge (O comando emerge) $ man ebuild (O comando ebuild) $ man 5 ebuild (sintaxe de arquivos ebuild) |
Você também pode encontrar mais informações relacionadas a desenvolvimento no Manual dos Desenvolvedores, em inglês.
Nota: Este documento presume que você configurou seu kernel corretamente, seus módulos para seu hardware e que você conhece o nome de interface de seu hardware. Também presumimos que você está configurando eth0, mas também pode ser eth1, wlan0, etc. |
Nota: Este documento precisa de que você esteja rodando baselayout-1.11.11 ou superior. |
Para iniciar a configuração de sua placa de rede, você precisa contar ao sistema de RC do Gentoo sobre ela. Isto é feito criando um link simbólico de net.lo para net.eth0 em /etc/init.d
Listagem de código 1.1: Fazendo link simbólico de net.eth0 para net.lo |
# cd /etc/init.d # ln -s net.lo net.eth0 |
O sistema de RC do Gentoo agora conhece a intercace. Ele também precisa saber como configurá-la. Todas interfaces de rede são configuradas em /etc/conf.d/net. Abaixo está um exemplo de configuração para DHCP e endereços estáticos.
Listagem de código 1.2: Exemplos para /etc/conf.d/net |
# Para DHCP config_eth0=( "dhcp" ) # Para IP estático usando notação CIDR config_eth0=( "192.168.0.7/24" ) routes_eth0=( "default via 192.168.0.1" ) # Para IP estático usando notação netmask config_eth0=( "192.168.0.7 netmask 255.255.255.0" ) routes_eth0=( "default gw 192.168.0.1" ) |
Nota: Se você não especificar uma configuração para sua interface, DHCP é presumido. |
Nota: CIDR significa Classless InterDomain Routing. Originalmente, endereços de IPv4 eram classificados como A, B, ou C. O sistema de classificação inicial não englobou a popularidade massiva da Internet e está em perigo de não ter endereços singulares novos. CIDR é um esquema de endereçamento que permite que um endereço IP designe muitos endereços IP. Um endereço IP CIDR parece igual ao um endereço IP normal, exceto por terminar com uma barra seguida de um número; por exemplo, 192.168.0.0/16. CIDR é descrito no RFC 1519. |
Agora que nós configuramos nossa interface, nós podemos iniciá-la e pará-la usando os comandos abaixo.
Listagem de código 1.3: Iniciando e parando scripts de rede |
# /etc/init.d/net.eth0 start # /etc/init.d/net.eth0 stop |
Importante: Durante a resolução de problemas de rede, é recomendável configurar RC_VERBOSE="yes" no /etc/conf.d/rc para que você obtenha mais informações sobre o que está acontecendo. |
Agora que você iniciou e parou sua interface de rede, você pode querer iniciá-la automaticamente quando o Gentoo iniciar. Aqui está como fazê-lo. O último comando "rc" instrui o Gentoo a iniciar quaisquer scripts no runlevel atual que não foram iniciados ainda.
Listagem de código 1.4: Configurando uma interface de rede para carregar durante a inicialização |
# rc-update add net.eth0 default # rc |
A variável config_eth0 é o coração da configuração de uma interface. É uma lista de instruções de alto nível para configurar a interface (eth0 neste caso). Cada comando na lista de instruções é feito seqüencialmente. A interface é considerada OK se pelo menos um comando funcionar.
Aqui está uma lista de instruções internas.
| Comando | Descrição |
| null | Não fazer nada |
| noop | Se a interface estiver levantada e houver um endereço, abortar a configuração com sucesso |
| um endereço IPv4 ou IPv6 | Adicionar o endereço à interfaceAdicionar o endereço à interface |
| dhcp, adsl ou apipa (ou comando personalizado de um módulo de terceiros) | Rodar o módulo que fornece o comando. Por exemplo, dhcp irá rodar um módulo que fornece DHCP, que pode ser tanto dhcpcd, udhcpc, dhclient ou pump. |
Se um comando falhar, você pode especificar uma alternativa. A alternativa tem que bater com a estrutura de configuração exatamente.
Você pode encadear estes comandos juntamente. Aqui estão alguns exemplos do mundo real.
Listagem de código 1.1: Exemplos de configuração |
# Adicionando três endereços IPv4 config_eth0=( "192.168.0.2/24" "192.168.0.3/24" "192.168.0.4/24" ) # Adicionando um endereço IPv4 e dois endereços IPv6 config_eth0=( "192.168.0.2/24" "4321:0:1:2:3:4:567:89ab" "4321:0:1:2:3:4:567:89ac" ) # Manter nosso endereço designado pelo kernel, a menos que a interface # caia, neste caso obter outro via DHCP. Se DHCP falhar, então adicionar um # endereço estático determinado por APIPA config_eth0=( "noop" "dhcp" ) fallback_eth0=( "null" "apipa" ) |
Nota: Quando usar o módulo ifconfig e adicionar mais que um endereço, aliases de interface são criados para cada endereço adicional. Com os dois exemplos acima, você obterá as interfaces eth0, eth0:1 e eth0:2. Você não pode fazer nada especial com essas interfaces, já que o kernel e outros programas irão simplesmente tratar eth0:1 e eth0:2 como eth0. |
Importante: A ordem da alternativa é importante! Se você não especificar a opção null, o comando apipa só será rodado se o comando noop falhar. |
Scripts de init em /etc/init.d podem depender de uma interface de rede específica ou só net. net pode ser definido em /etc/conf.d/rc para significar diferentes coisas usando a variável RC_NET_STRICT_CHECKING.
| Valor | Descrição |
| none | O serviço net é considerado como sempre funcionando |
| no | Basicamente significa que pelo menos um serviço net.* fora net.lo deve estar funcionando. Isto pode ser usado por usuários de notebooks que têm wifi e um nic estático, e só precisam de um funcionando para que o serviço net seja visto como funcionando. |
| lo | É igual a opção no, mas net.lo também é contado. Deve ser útil para pessoas que não se importam se alguma interface específica está funcionando durante o carregamento. |
| yes | TODAS interfaces de rede DEVEM estar funcionando para o serviço net ser considerado como funcionando. |
Mas e o net.br0 dependendo de net.eth0 e net.eth1? net.eth1 pode ser um dispositivo wireless ou ppp que precisa de configuração antes de ser adicionado à ponte. Isto não pode ser feito em /etc/init.d/net.br0 já que é um link simbólico para net.lo.
É resposta é criar sua própria função depend() em /etc/conf.d/net.
Listagem de código 2.1: dependência net.br0 em /etc/conf.d/net |
# Você pode usar qualquer dependência (use, after, before) como encontradas em scripts atuais
depend_br0() {
need net.eth0 net.eth1
}
|
Para uma discussão mais detalhada sobre dependência, consulte a seção Escrevendo scripts de init no Manual do Gentoo.
2.c. Nomes de variáveis e valores
Nomes de variáveis são dinâmicos. Normalmente seguem a estrutura variable_${interface|mac|essid|apmac}. Por exemplo, a variável dhcpcd_eth0 tem os valores das opções de dhcpcd para eth0 e dhcpcd_essid tem o valor das opções de dhcpcd quando qualquer interface conecta-se ao ESSID "essid".
No entanto, não existe nenhuma regra rígida e pronta que diz que nomes de interface devem ser ethx. Na verdade, muitas interfaces wireless têm nomes como wlanx, rax bem como ethx. Também, algumas intercaces definidas por usuários como pontes podem receber qualquer nome, como foo. Para tornar a vida mais interessante, pontos de acesso (AP) de wireless podem ter nomes com caracteres não alfa-numéricos neles - isto é importante porque você pode configurar parâmetros de rede por ESSID.
O ponto negativo disto é que o Gentoo usa variáveis de bash para rede - e o bash não pode usar nada fora caracteres ingleses alfa-numéricos. Para contornar esta limitação nós trocamos cada caractere que não é inglês alfa-numérico em um caractere _.
Outro ponto negativo do bash é o conteúdo das variáveis - alguns caracteres precisam de escape. Isto pode ser feito colocando o caractere \ na frente do caractere que precisa ser escapado. A seguinte lista de caracteres precisa ser escapada do seguinte jeito: ", ' e \.
Neste exemplo nós usados ESSID de wireless já que contêm o maior escopo de caracteres. Nós usaremos a ESSID My "\ NET:
Listagem de código 3.1: exemplo de nome de variável |
# Isto funciona, mas o domínio é inválido dns_domain_My____NET="My \"\\ NET" # A parte acima configura o domínio de dns para My "\ NET quando um cartão de wireless # conecta-se a um AP cujo ESSID é My "\ NET |
Nós agora suportamos scripts de rede modulares, o que significa que nós podemos facilmente adicionar suporte para novos tipos de interface e módulos de configuração, mantendo compatibilidade com os existentes.
Os módulos carregam por padrão se o pacote de que eles precisam está instalado. Se você especificar um módulo aqui que não tem seu pacote instalado, você obtém um erro dizendo que pacote você precisa instalar. Idealmente, você só usa o ajuste de módulos quando você tem dois ou mais pacotes instalados que fornecem o mesmo serviço e você precisa escolher um no lugar do outro.
Listagem de código 1.1: Preferência de módulo |
# Preferir iproute2 ao invés de ifconfig modules=( "iproute2" ) # Você também pode especificar outros módulos para uma interface # Neste caso nós preferimos udhcpc ao invés de dhcpcd modules_eth0=( "udhcpc" ) # Você também pode especificar que módulos não usar - por exemplo, você pode estar # usando um suplicante ou linux-wlan-ng para controlar a configuração wireless, mas # você ainda quer configurar ajustes de rede por cada ESSID associado. modules=( "!iwconfig" ) |
3.b. Gerenciadores de interface
Nós atualmente oferecemos dois gerenciadores de interface: ifconfig e iproute2. Você precisa de um deles para qualquer tipo de configuração de rede.
ifconfig é o padrão do Gentoo e é incluído no profile (perfil) de sistema. iproute2 é um pacote mais poderoso e flexível, mas não é incluído por padrão.
Listagem de código 2.1: Para instalar iproute2 |
# emerge sys-apps/iproute2 # Para preferir iproute2 ao invés de ifconfig se ambos estiverem instalados modules=( "iproute2" ) |
Já que ambos ifconfig e iproute2 fazem coisas parecidas, nós precisamos que sua configuração básica funcione com os dois. Por exemplo, os dois trechos de código abaixo funcionam com qualquer módulo que você estiver usando.
Listagem de código 2.2: exemplos de ifconfig e iproute2 |
config_eth0=( "192.168.0.2/24" )
config_eth0=( "192.168.0.2 netmask 255.255.255.0" )
# Também podemos especificar broadcast
config_eth0=( "192.168.0.2/24 brd 192.168.0.255" )
config_eth0=( "192.168.0.2 netmask 255.255.255.0 broadcast 192.168.0.255" )
|
DHCP é um meio de obter informação de rede (endereço de IP, servidores de DNS, roteador, etc) de um servidor de DHCP. Isto significa que se há um servidor de DHCP rodando na rede, você só tem que dizer a cada cliente para usar DHCP e ele irá configurar a rede sozinho. Claro, você terá que configurar outras coisas como wireless, PPP ou outras coisas se forem necessárias antes de poder usar DHCP.
DHCP pode ser fornecido por dhclient, dhcpcd, pump ou udhcpc. Cada módulo de DHCP tem seus prós e contras - aqui está uma rápida lista.
| Módulo de DHCP | Pacote | Prós | Contras |
| dhclient | net-misc/dhcp | Feito pela ISC, as mesmas pessoas por trás do software BIND DNS. Muito configurável | Configuração demasiadamente complexa, software é bem inflado, não pode obter servidores de NTP do DHCP, não envia nome de host por padrão |
| dhcpcd | net-misc/dhcpcd | Padrão do Gentoo por muito tempo, não precisa de ferramentas exteriores | Não é mais mantido pelos desenvolvedores, pode ser lento às vezes, não vira daemon quando o lease é infinito |
| pump | net-misc/pump | Peso leve, não precisa de ferramentas exteriores | Não é mais mantido pelos desenvolvedores, não confiável, em especial com modems, não pode obter servidores de NIS do DHCP |
| udhcpc | net-misc/udhcp | Peso leve - menor cliente de DHCP existente, feito para sistemas embedded | Não testado - nenhuma distribuição usa por padrão, não pode definir um timeout maior que 3 segundos |
Se você tiver mais de um cliente de DHCP instalado, você precisa especificar qual usar - caso contrário o padrão é dhcpcd se disponível.
Para enviar opções específicas para o módulo de DHCP, use module_eth0="..." (troque module pelo módulo de DHCP que você está usando - por exemplo dhcpcd_eth0)
Nós tentamos e tornamos o DHCP relativamente agnóstico - assim nós suportamos os seguintes comandos usando a variável dhcp_eth0. O padrão é não usar nenhum deles.
Listagem de código 3.1: Exemplo de configuração de DHCP em /etc/conf.d/net |
# Só necessário se você tiver mais que um módulo de DHCP instalado modules=( "dhcpcd" ) config_eth0=( "dhcp" ) dhcpcd_eth0="-t 10" # Desistir após 10 segundos dhcp_eth0="release nodns nontp nonis" # Só obter um endereço |
Nota: dhcpcd, udhcpc e pump enviam o nome de host atual para o servidor de DHCP por padrão, então você não precisa mais especificá-lo. |
Primeiro nós precisamos instalar o software ADSL.
Listagem de código 4.1: Install the rp-pppoe package |
# emerge net-dialup/rp-pppoe
|
Aviso:
baselayout-1.11.x só suporta PPPoE |
Agora nós precisamos instruir configure eth0 para ser uma interface de ADSL e digitar nosso nome de usuário.
Listagem de código 4.2: Configure eth0 para ADSL |
config_eth0=( "adsl" ) adsl_user_eth0="nomedeusuario" |
Finalmente você precisa definir seu nome de usuário e senha em /etc/ppp/pap-secrets.
Listagem de código 4.3: exemplo de /etc/ppp/pap-secrets |
# O * é importante
"usuario" * "senha"
|
3.e. APIPA (Automatic Private IP Addressing)
APIPA tenta encontrar um endereço livre no alcance 169.254.0.0-169.254.255.255 enviando arps de endereços aleatórios no alcance da interface. Se nenhuma resposta é ouvida, nós designamos o endereço à interface.
Isto só é útil para LANs onde não há servidor de DHCP e você não conecta-se diretamente à Internet e todos outros computadores usam APIPA.
Para suporte a APIPA, faça emerge net-misc/iputils ou net-analyzer/arping.
Listagem de código 5.1: Configuração de APIPA em /etc/conf.d/net |
# Tentar DHCP primeiro - se falhar, usar como alternativa APIPA config_eth0=( "dhcp" ) fallback_eth0=( "apipa" ) # Simplesmente usar APIPA config_eth0=( "apipa" ) |
Para bonding/trunking de links, faça emerge net-misc/ifenslave
Bonding é usado para aumentar a banda da rede. Se você tem duas placas de rede usando a mesma rede, você pode fazer bond delas para que suas aplicações vejam só uma interface, mas na verdade usem as duas.
Listagem de código 6.1: configuração de bonding em /etc/conf.d/net |
#Juntando interfaces slaves_bond0="eth0 eth1 eth2" # Você pode não querer designar um IP à interface juntada config_bond0=( "null" ) # Depende em eth0, eth1 e eth2 já que elas podem precisar de configuração adicional depend_bond0() { need net.eth0 net.eth1 net.eth2 } |
3.g. Bridging (ponte) (suporte a 802.1d)
Para suporte a bridging, faça emerge net-misc/bridge-utils
Bridging é usado para unir duas redes. Por exemplo, você pode ter um servidor que conecta-se à Internet via um modem ADSL e uma placa de acesso wireless para permitir que outros computadores conectem-se à rede via o modem ADSL. Você pode criar uma ponte para unir as duas interfaces.
Listagem de código 7.1: Configuração de ponte em /etc/conf.d/net |
# Configure a ponte - "man btctl" para mais detalhes brctl_br0=( "setfd 0" "sethello 0" "stp off" ) # Para adicionar portas à ponte br0 bridge_br0="eth0 eth1" # Você precisa configurar todas portas com valores nulos para que o dhcp não seja iniciado config_eth0=( "null" ) config_eth1=( "null" ) # Finalmente, dê um endereço para a ponte - você pode usar DHCP também config_br0=( "192.168.0.1/24" ) # Depender de eth0 e eth1 já que podem necessitar de configuração adicional depend_br0() { need net.eth0 net.eth1 } |
Importante: Para usar algumas configurações de ponte, você pode consultar a documentação de nome de variável. |
Você não precisa instalar nada para mudar o endereço MAC de sua interface se você tiver sys-apps/baselayout-1.11.14 ou mais novo e quiser mudar para um endereço de MAC específico. No entanto, se você precisa mudar para um endereço de MAC aleatório ou tem um baselayout mais antigo que a versão mencionada acima, você precisa fazer emerge de net-analyzer/macchanger para poder fazer uso desta funcionalidade.
Listagem de código 8.1: Exemplo de mudança de endereço de MAC |
# Para configurar o endereço de MAC de uma interface mac_eth0="00:11:22:33:44:55" # Para tornar apenas os últimos 3 bytes aleatórios mac_eth0="random-ending" # Para tornar aleatório dentro do mesmo tipo físico de conexão (como fibra, # cobre, wireless) , todos fabricantes mac_eth0="random-samekind" # Para tornar aleatório dentro de qualquer tipo físico de conexão (como fibra, # cobre, wireless) , todos fabricantes mac_eth0="random-anykind" # Aleatório completo - AVISO: alguns endereços de MAC gerados assim podem # NÃO funcionar como esperado mac_eth0="random-full" |
Você não precisa instalar nada para fazer túneis já que o gerenciador de interfaces pode fazê-lo para você.
Listagem de código 9.1: Configuração de túneis em /etc/conf.d/net |
# Para túneis GRE iptunnel_vpn0="mode gre remote 207.170.82.1 key 0xffffffff ttl 255" # Para túneis IPIP iptunnel_vpn0="mode ipip remote 207.170.82.2 ttl 255" # Para configurar a interface config_vpn0=( "192.168.0.2 peer 192.168.1.1" ) |
Para suporte a VLAN, faça emerge net-misc/vconfig.
Virtual LAN é um grupo de dispositivos de rede que agem como se estivessem conectados a um único segmento de rede - embora possam não estar. Membros de VLAN só podem ser membros da mesma VLAN, mesmo que estejam dentro da mesma rede física.
Listagem de código 10.1: configuração de VLAN em /etc/conf.d/net |
# Especifique os números de VLAN para interface como abaixo # Por favor certifique-se que as IDs de VLAN NÃO sejam com zeros vlans_eth0="1 2" # Você também pode configurar a VLAN # veja a página de man de vconfig para mais detalhes vconfig_eth0=( "set_name_type VLAN_PLUS_VID_NO_PAD" ) vconfig_vlan1=( "set_flag 1" "set_egress_map 2 6" ) # Configure a interface como normalmente config_vlan1=( "172.16.3.1 netmask 255.255.254.0" ) config_vlan2=( "172.16.2.1 netmask 255.255.254.0" ) |
Importante: Para usar algumas configurações de VLAN, você pode precisar consultar a documentação de nomes de variáveis. |
Atualmente nós suportamos configurações wireless tanto através de wireless-tools ou wpa_supplicant. É importante lembrar que você deve configurar para redes wireless com base global e não com base em interface.
wpa_suppliant é a melhor escolha, mas não suporta todos drivers. Para uma lista de drivers suportados, leia o site do wpa_supplicant. Também, o wpa_supplicant só pode conectar atualmente a um SSID que você tenha configurado.
wireless-tools suporta quase todos cartões e drivers, mas não pode conectar a pontos de acesso (APs) só de WPA.
Aviso: O driver linux-wlan-ng não é suportado pelo baselayout neste momento. Isto ocorre porque o linux-wlan-ng tem seus próprios ajustes e configuração que são completamente diferentes do resto. Existe um boato de que os desenvolvedores do linux-wlan-ng estejam mudando sua configuração para a do wireless-tools - quando isto acontecer, você poderá usar o linux-wlan-ng com o baselayout. |
4.b. WPA Supplicant (suplicante)
WPA Supplicant é um pacote que permite que você se conecte a pontos de acesso com WPA. Sua configuração é bagunçada já que ainda está em beta - no entanto, funciona bem na maior parte.
Listagem de código 2.1: Instale o wpa_supplicant |
# emerge net-wireless/wpa_supplicant
|
Importante: Você deve ter CONFIG_PACKET ativado em seu kernel para que o wpa_supplicant funcione. |
Agora nós configuramos o /etc/conf.d/net para que prefiramos wpa_supplicant ao invés de wireless-tools (se ambos estiverem instalados, o wireless-tools é o padrão).
Listagem de código 2.2: configure /etc/conf.d/net para wpa_supplicant |
# Preferir wpa_supplicant ao invés de wireless-tools modules=( "wpa_supplicant" ) # É importante dizer ao wpa_supplicant que driver nós devemos # usar já que ele ainda não é bom em adivinhar wpa_supplicant_eth0="-Dmadwifi" |
Nota: Se você estiver usando o driver host-ap, você precisará colocar o cartão em modo gerenciado antes de poder ser usado com wpa_supplicant corretamente. Você pode usar iwconfig_eth0="mode managed" para fazer isto no /etc/conf.d/net. |
Foi simples, não foi? Todavia, ainda precisamos configurar o próprio wpa_supplicant, o que é um pouco complicado dependendo da segurança dos pontos de acesso a que você está tentando conectar. O exemplo abaixo é tirado e simplificado do /etc/wpa_supplicant.conf.example que vem com o wpa_supplicant.
Listagem de código 2.3: um exemplo de /etc/wpa_supplicant.conf |
# A linha abaixo não pode ser mudada, senão não funcionamos ctrl_interface=/var/run/wpa_supplicant # Certificar que só o administrador (root) pode ler a configuração de WPA ctrl_interface_group=0 # Permitir que o wpa_supplicant tome conta do escaneamento e seleção de AP ap_scan=1 # Caso simples: WPA-PSK, PSK como uma senha ASCII, permitir todas cifras válidas network={ ssid="simples" psk="senha super secreta" # Quanto maior a prioridade, mais rápido somos encontrados priority=5 } # Igual ao anterior, mas pedir escaneamento específico de SSID (para APs que rejeitam # broadcast SSID) network={ ssid="segundo ssid" scan_ssid=1 psk="senha super secreta" priority=2 } # Só WPA-PSK é usado. QUalquer combinação válida de cifras é usada network={ ssid="exemplo" proto=WPA key_mgmt=WPA-PSK pairwise=CCMP TKIP group=CCMP TKIP WEP104 WEP40 psk=06b4be19da289f475aa46a33cb793029d4ab3db7a23ee92382eb0106c72ac7bb priority=2 } # Conexão de texto simples (sem WPA, sem IEEE 802.1X) network={ ssid="textosimples-teste" key_mgmt=NONE } # Conexão de chave WEP compartilhada (sem WPA, sem IEEE 802.1X) network={ ssid="static-wep-test" key_mgmt=NONE wep_key0="abcde" wep_key1=0102030405 wep_key2="1234567890123" wep_tx_keyidx=0 priority=5 } # Conexão de chave WEP compartilhada (sem WPA, sem IEEE 802.1X) usando chave compartilhada # com autenticação IEEE 802.11 network={ ssid="static-wep-test2" key_mgmt=NONE wep_key0="abcde" wep_key1=0102030405 wep_key2="1234567890123" wep_tx_keyidx=0 priority=5 auth_alg=SHARED } # rede IBSS/ad-hoc com WPA-None/TKIP network={ ssid="test adhoc" mode=1 proto=WPA key_mgmt=WPA-NONE pairwise=NONE group=TKIP psk="senha secreta" } |
4.c. Wireless Tools (ferramentas de wireless)
Configuração inicial e modo gerenciado
Wireless Tools fornecem um modo genérico de configurar interfaces de wireless básicas até o nível de segurança WEP. Embora o WEP seja um método de segurança fraco, também é o predominante.
A configuração do Wireless Tools é controlada por algumas variáveis principais. O arquivo de configuração abaixo deve descrever tudo de que você precisa. Uma coisa para ter em mente é que nenhuma configuração significa "conectar ao ponto de acesso sem criptografia mais forte" - nós sempre iremos tentar e conectar você com alguma coisa.
Listagem de código 3.1: Instale o wireless-tools |
# emerge net-wireless/wireless-tools
|
Nota: Embora você possa gravar seus ajustes de wireless em /etc/conf.d/wireless este guia recomenda que você guarde-os em /etc/conf.d/net. |
Importante: Você irá precisar consultar a documentação de nomes de variáveis. |
Listagem de código 3.2: exemplo de ajuste de iwconfig em /etc/conf.d/net |
# Preferir iwconfig ao invés de wpa_supplicant modules=( "iwconfig" ) # Configurar chaves de WEP para pontos de acesso chamados ESSID1 e ESSID2 # Você pode configurar até 4 chaves WEP, mas só 1 pode estar ativa # durante qualquer hora, então damos um índice padrão [1] para configurar a chave [1] e então # novamente depois para mudar a chave ativa para [1] # Fazemos isto caso você defina outros ESSID's para usar as chaves WEP fora 1 # # Prefixar a chave com s: significa que é uma chave ASCII, caso contrário é uma chave HEX # # enc open specified open security (mais seguro) # enc restricted specified restricted security (menos seguro) key_ESSID1="[1] s:suachaveaqui key [1] enc open" key_ESSID2="[1] aaaa-bbbb-cccc-dd key [1] enc restricted" # O abaixo só funciona quando escaneamos pontos de acesso disponíveis # Às vezes mais de um ponto de acesso está visível, então precisamos # definir um preferido para conectar preferred_aps=( "ESSID1" "ESSID2" ) |
Ajustes finos de seleção de pontos de acesso
Você pode encontrar algumas opções adicionais para fazer ajustes finos a sua seleção de pontos de acesso, mas não são normalmente necessários.
Você pode decidir se apenas conectamos aos pontos de acesso preferidos ou não. Por padrão, se tudo configurado falhar e pudermos conectar a um ponto de acesso sem criptografia, faremos isso. Isto pode ser controlado pela variável associate_order. Aqui está uma tabela de valores e como eles controlam isso.
| Valor | Descrição |
| any | Comportamento padrão |
| preferredonly | Só iremos conectar a pontos de acesso visíveis na lista de preferência |
| forcepreferred | Nós iremos forçar a conexão a pontos de acesso na ordem preferida se não forem encontrados em um escaneamento |
| forcepreferredonly | Não escanear pontos de acesso - ao invés disso, conectar-se a cada um em ordem |
| forceany | Igual a forcepreferred + conectar a qualquer outro ponto de acesso disponível |
Finalmente nós temos algumas seleções de blacklist_aps e unique_ap. blacklist_aps funciona de uma forma parecida a preferred_aps. unique_ap é um valor yes ou no que diz se uma segunda interface de wireless pode conectar-se ao mesmo ponto de acesso que a primeira interface.
Listagem de código 3.3: exemplo de blacklist_aps e unique_ap |
# Às vezes você não deseja conectar-se a certos pontos de acesso blacklist_aps=( "ESSID3" "ESSID4" ) # Se você tiver mais que um cartão wireless, você pode dizer se você quer # permitir que cada cartão se associe com o mesmo ponto de acesso ou não # Valores são "yes" e "no" # O padrão é "yes" unique_ap="yes" |
Se você quiser configurar-se como um node de Ad-Hoc se você não conseguir se conectar a nenhum ponto de acesso em modo gerenciado, você também pode fazê-lo.
Listagem de código 3.4: alternativa de modo ad-hoc |
adhoc_essid_eth0="Este node de Adhoc" |
E conectar-se a redes Ad-Hoc ou rodar em modo Master para tornar-se um ponto de acesso? Aqui está uma configuração para isto! Você pode precisar especificar chaves de WEP como mostrado acima.
Listagem de código 3.5: exemplo de configuração de ad-hoc/master |
# Configurar o modo - pode ser gerenciado (padrão), ad-hoc ou master # Nem todos drivers suportam todos modos mode_eth0="ad-hoc" # Configure o ESSID da interface # Em modo gerenciado, isto força a interface a tentar e conectar-se ao # ESSID especificado e nada mais essid_eth0="Este node de Adhoc" # Nós usamos o canal 3 se você não especificar um channel_eth0="9" |
Importante: O abaixo é tirado diretamente da documentação de wavelan do BSD encontrada na documentação do NetBSD. Existem 14 canais possíveis; É dito a nós que os canais 1-11 são legais para a América do Norte, canais 1-13 para a maior parte da Europa, canais 10-13 para a França, e só canal 14 para o Japão. Se em dúvida, por favor faça referência à documentação que veio junto com seu cartão ou ponto de acesso. Certifique-se de que o canal que você selecionar é o mesmo canal de seu ponto acesso (ou o mesmo cartão na rede ad-hoc). O padrão para cartões vendidos na América do Norte e a maior parte da Europa é 3; o padrão para cartões vendidos na França é 11, e o padrão para cartões vendidos no Japão é 14. |
Resolvendo problemas com o Wireless Tools
Existem mais algumas variáveis que você pode usar para colocar sua conexão wireless para funcionar devido a problemas de driver ou ambiente. Aqui está uma tabela com outras coisas que você pode tentar.
| Variável | Valor padrão | Descrição |
| iwconfig_eth0 | Veja a página de manual do iwconfig para detalhes sobre o que enviar ao iwconfig | |
| iwpriv_eth0 | Ver a página de manual do iwpriv para detalhes sobre o que enviar ao iwpriv | |
| sleep_scan_eth0 | 0 | O número de segundos para dormir antes de tentar escanear. Isto é necessário quando o driver/firmware precisa de mais tempo para ser ativado antes de ser usado. |
| sleep_associate_eth0 | 5 | O número de segundos para esperar que a interface se associe com um ponto de acesso antes de tentar o próximo |
| associate_test_eth0 | MAC | Alguns drivers não resetam o endereço de MAC associado com um inválido quando perdem ou tentam associação. Alguns drivers não resetam o nível de qualidade quando perdem ou tentam associação. Valores válidos são MAC, quality e all. |
| scan_mode_eth0 | Alguns drivers aqui tem que escanear em modo ad-hoc, então se o escaneamento falhar, tentar configurar ad-hoc aqui | |
| iwpriv_scan_pre_eth0 | Envia alguns comandos de iwpriv para a interface antes de escanear. Ver a página de manual do iwpriv para mais detalhes | |
| iwpriv_scan_post_eth0 | Envia alguns comandos de iwpriv para a interface após escanear. Ver a página de manual do iwpriv para mais detalhes |
4.d. Definindo configuração de rede por ESSID
Às vezes, você precisa de um IP estático quando você se conecta ao ESSID1 e você precisa de DHCP quando você se conecta ao ESSID2. Na verdade, a maior parte das variáveis de módulos podem ser definidas por ESSID. Aqui está como fazemos isto.
Nota: O seguinte funciona se você estiver usando WPA Supplicant ou Wireless Tools. |
Importante: Você irá precisar consultar a documentação de nomes de variáveis. |
Listagem de código 4.1: sobrepor ajustes de rede por ESSID |
config_ESSID1=( "192.168.0.3/24 brd 192.168.0.255" ) routes_ESSID1=( "default via 192.168.0.1" ) config_ESSID2=( "dhcp" ) fallback_ESSID2=( "192.168.3.4/24" ) fallback_route_ESSID2=( "default via 192.168.3.1" ) # Nós também podemos definir servidores de nome e outras coisas # NOTA: O DHCP irá sobrepor o seguinte a menos que seja dito o contrário dns_servers_ESSID1=( "192.168.0.1" "192.168.0.2" ) dns_domain_ESSID1="algum.domínio" dns_search_domains_ESSID1="procurar.este.domínio. procurar.aquele.domínio" # Você sobrepõe por endereço de MAC do ponto de acesso # É útil se você vai para diferentes lugares que tem o mesmo ESSID config_001122334455=( "dhcp" ) dhcpcd_001122334455="-t 10" dns_servers_001122334455=( "192.168.0.1" "192.168.0.2" ) |
Quatro funções podem ser definidas que serão chamadas em torno das operações start/stop. As funções são chamadas com o nome da interface primeiro para que uma função possa controlar múltiplos adaptadores.
Os valores de retorno para as funções preup() e predown devem ser 0 (sucesso) para indicar que a configuração ou desconfiguração da interface pode continuar. Se preup() retornar um valor não-nulo, então a configuração de interface será abortada. Se o predown() retornar um valor não-nulo, então a interface não poderá continuar a desconfiguração.
Os valores de retorno para as funções postup() e postdown são ignorados, já que não há nada a fazer se eles indicarem falhas.
${IFACE} é configurado para a interface ser levantada/abaixada. ${IFVAR} é ${IFACE} convertido para um nome de variável permitido pelo bash
Listagem de código 1.1: exemplos de função pre/post up/down |
preup() {
# Testar link na interface antes de levantá-la. Isto
# só funciona com alguns adaptadores de rede e precisa de que o pacote
# mii-diag esteja instalado.
if mii-tool ${IFACE} 2> /dev/null | grep -q 'no link'; then
ewarn "No link on ${IFACE}, aborting configuration"
return 1
fi
Testar link na interface antes de levantá-la. Isto
# só funciona com alguns adaptadores de rede e precisa de que o pacote
# ethtool esteja instalado.
if ethtool ${IFACE} | grep -q 'Link detected: no'; then
ewarn "No link on ${IFACE}, aborting configuration"
return 1
fi
# Lembre-se de retornar 0 em caso de sucesso
return 0
}
predown() {
# O padrão no script é testar por raiz de NFS e proibir
# abaixar interfaces no caso. Note que se você especificar uma
# função predown() você irá sobrepor a lógica. Aqui está, em
# caso que você ainda queira...
if is_net_fs /; then
eerror "sistema de arquivos raiz está montado em rede -- ${IFACE} não pode ser parada"
return 1
fi
# Lembre-se de retornar 0 em caso de sucesso
return 0
}
postup() {
# Esta função pode ser usada, por exemplo, para registrar com
# um serviço de DNS dinâmico. Outra possibilidade seria
# enviar/receber correio uma vez que a interface for configurada.
return 0
}
postdown() {
# Esta função está aqui para ser completo... Não
# pensei de nada interessante para fazer com ela ainda ;-)
return 0
}
|
5.b. Ganchos de função para ferramentas wireless
Nota: Isto não irá funcionar com WPA suplicante - mas as variáveis ${ESSID} e ${ESSIDVAR} estão disponíveis na função postup(). |
Duas funções podem ser definidas que irão ser chamadas em torno da função associada. As funções são chamadas com o nome da interface primeiro para que uma função possa controlar múltiplos adaptadores.
Os valores de retorno para uma função preassociate() devem ser 0 (sucesso) para indicar que a configuração ou desconfiguração da interface pode continuar. Se preassociate() retornar um valor não-nulo, então a configuração de interface será abortada.
O valor de retorno para a função postassociate() é ignorado já que não há nada a fazer se indicar falha.
${ESSID} é configurado como o ESSID exato do AP a que você está se conectando. ${ESSIDVAR} é ${ESSID} convertido para um nome de variável permitido pelo bash
Listagem de código 2.1: funções pre/post association |
preassociate() {
# Abaixo são adicionadas duas variáveis de configuração leap_user_ESSID
# e leap_pass_ESSID. Quando as duas são configuradas para o ESSID
# sendo conectado, então nós rodamos o script CISCO LEAP
local user pass
eval user=\"\$\{leap_user_${ESSIDVAR}\}\"
eval pass=\"\$\{leap_pass_${ESSIDVAR}\}\"
if [[ -n ${user} && -n ${pass} ]]; then
if [[ ! -x /opt/cisco/bin/leapscript ]]; then
eend "Para suporte a LEAP support, por favor faça emerge net-misc/cisco-aironet-client-utils"
return 1
fi
einfo "Esperando autenticação de LEAP em \"${ESSID//\\\\//}\""
if /opt/cisco/bin/leapscript ${user} ${pass} | grep -q 'Login incorrect'; then
ewarn "Login falhou para ${user}"
return 1
fi
fi
return 0
}
postassociate() {
# Esta função está aqui para ser completo... Não
# pensei de nada interessante para fazer com ela ainda ;-)
return 0
}
|
Nota: ${ESSID} e ${ESSIDVAR} não estão disponíveis nas funções predown() e postdown(). |
Se você e seu computador estiverem sempre em tráfego, você pode nem sempre ter um cabo de ethernet plugado ou um ponto de acesso (AP) disponível. Também, nós podemos desejar que a rede funcione automaticamente se um cabo de ethernet for plugado ou um ponto de acesso encontrado.
Aqui você encontra algumas ferramentas que ajudam a gerenciar isto.
Nota: Este documento só fala sobre o ifplugd, mas existem alternativas que você pode considerar, como quickswitch. |
ifplugd é um daemon que iniciar e pára interfaces quando um cabo de ethernet é inserido ou removido. Também pode gerenciar a detecção de associação a pontos de acesso ou quando novos entram em alcance.
Listagem de código 2.1: Instalando o ifplugd |
# emerge sys-apps/ifplugd
|
A configuração do ifplugd é bem simples também. O arquivo de configuração fica em /etc/conf.d/ifplugd. Rode man ifplugd para detalhes sobre o que fazem as variáveis.
Listagem de código 2.2: exemplo de configuração de ifplug |
# Definir que interfaces monitorar INTERFACES="eth0" AUTO="no" BEEP="yes" IGNORE_FAIL="yes" IGNORE_FAIL_POSITIVE="no" IGNORE_RETVAL="yes" POLL_TIME="1" DELAY_UP="0" DELAY_DOWN="0" API_MODE="auto" SHUTDOWN="no" WAIT_ON_FORK="no" MONITOR="no" ARGS="" # Parâmetros adicionais para ifplugd para a interface especificada. Note que # a variael global é ignorada quando uma variável com esta é ajustada para uma # interface MONITOR_wlan0="yes" DELAY_UP_wlan0="5" DELAY_DOWN_wlan0="5" |
O conteúdo deste documento está licenciado pela licença Creative Commons - Attribution / Share Alike.