Renuncia de responsabilidad:
Este manual ha sido sustituido por una versión más reciente y no tendrá
soporte de aquí en adelante.
|
Gentoo Linux/HPPA Handbook
Contenido:
-
Installing Gentoo
In this part you learn how to install Gentoo on your system.
-
About the Gentoo Linux Installation
Users not familiar with Gentoo do not always know that choice is what
Gentoo is all about.
-
Choosing the Right Installation Medium
You can install Gentoo in many ways. You can use our LiveCD, an existing
distribution etc.
-
Configuring your Network
If you want to install Gentoo using the Internet, you need to set up
networking.
-
Preparing the Disks
To be able to install Gentoo, you must create the necessary partitions.
This chapter describes how to partition a disk for future usage.
-
Installing the Gentoo Installation Files
Gentoo installs work through so-called stage-files. In this chapter we
describe how you extract a stage-file and configure Portage.
-
Installing the Gentoo Base System
Independent of what stage you chose, the eventual result is that you
have a Gentoo base system at your disposal. This chapter describes how
to progress to that stadium.
-
Configuring the Kernel
The Linux kernel is the core of every distribution. This chapter
explains how to configure your kernel.
-
Configuring your System
You need to edit some important configuration files. In this chapter
you receive an overview of these files and an explanation on how to
proceed.
-
Installing Necessary System Tools
As mentioned before, Gentoo is about choices. In this chapter we help you
choose and install some important tools.
-
Configuring the Bootloader
In this chapter we'll describe the PALO bootloader
and step you through the process of configuring PALO to your
needs.
-
Finalizing your Gentoo Installation
You're almost done. We'll just create one (or more) users for your
system and (optionally) install prebuilt packages.
-
Where to go from here?
Now you have your Gentoo system, but what's next?
-
Working with Gentoo
Learn how to work with Gentoo: installing software, altering variables, changing
Portage behaviour etc.
-
A Portage Introduction
This chapter explains the "simple" steps a user definitely needs to know to
maintain the software on his system.
-
USE flags
USE-flags are a very important aspect of Gentoo. In this chapter, you learn to
work with USE-flags and understand how USE-flags interact with your system.
-
Portage Features
Discover the features Portage has, such as support for distributed compiling,
ccache and more.
-
Initscripts
Gentoo uses a special initscript format which, amongst other features, allows
dependency-driven decisions and virtual initscripts. This chapter explains all
these aspects and explains how to deal with these scripts.
-
Environment Variables
With Gentoo you can easily manage the environment variables for your system.
This chapter explains how you do that, and also describes frequently used
variables.
-
Working with Portage
"Working with Portage" provides an in-depth coverage of Portage, Gentoo's
Software Management Tool.
-
Files and Directories
Once you want to know Portage in-depth you need to know where it stores its
files and data.
-
Configuring through Variables
Portage is completely configurable through various variables you can set in the
configuration file or as environment variable.
-
Mixing Software Branches
Gentoo provides software separated in several branches, depending on stability
and architectural support. "Mixing Software Branches" inform you how these
branches can be configured and how you can override this separation
individually.
-
Additional Portage Tools
Portage comes with a few extra tools that might make your Gentoo experience even
better. Read on to discover how to use dispatch-conf and other tools.
-
Diverting from the Official Tree
"Diverting from the Official Tree" gives you some tips and tricks on how to use
your own Portage tree, how to synchronise only the categories you want, inject
packages and more.
-
The Ebuild Application
In "The Ebuild Application" you are informed about the steps Portage takes while
installing software and how you can do this yourself using the ebuild
application.
A. Installing Gentoo
1. About the Gentoo Linux Installation
1.a. Introducción
¡Bienvenido!
Primero de todo, bienvenido/a a Gentoo. Está a punto de entrar en
un mundo de flexibilidad y rendimiento. Gentoo es la flexibilidad en sí. Cuando
instalas Gentoo, esto queda claro varias veces, puedes elegir cuánto quieres
compilar tu mismo, cómo instalar Gentoo, que gestor de registro prefieres, etc.
Gentoo es una metadistribución moderna, rápida, con un diseño limpio y
flexible. Gentoo está hecha alrededor del software libre y no oculta a sus
usuarios qué hay bajo la alfombra. Portage, el sistema de mantenimiento
de paquetes que usa Gentoo, está escrito en Python, por lo que el código
fuente es fácil de visualizar y modificar. El sistema de paquetes de Gentoo
se basa en el código fuente (aunque también soporta paquetes precompilados)
y para configurar Gentoo se utilizan archivos de texto plano. En otras palabras,
abierto a cualquiera.
Es muy importante que entienda que la flexibilidad es lo que
hace que Gentoo funcione. Intentamos no forzarle a entrar en algo que
no le guste. Si cree en algún momento que lo estamos haciendo, por favor,
envíe su opinión.
¿Cómo está estructurada la instalación?
La instalación de Gentoo puede verse como un procedimiento de 10 pasos,
los correspondientes a los capítulos 2 a 11. Cada paso da como resultado
un cierto estado:
-
Tras el paso 1, te encontrarás en un entorno funcional preparado para
instalar Gentoo
-
Después del paso 2, la conexión a Internet estará funcionando y lista para
instalar Gentoo (esto puede ser opcional en ciertas situaciones)
-
Tras el paso 3, sus discos duros estarán preparados para alojar tu instalación
de Gentoo
-
Tras el paso 4, el entorno de instalación estará preparado y se encontrará
dentro de un entorno chroot.
-
Después del paso 5, los paquetes principales, que son los mismos en toda
instalación de Gentoo, estarán instalados
-
Tras el paso 6, el kernel Linux estará compilado.
-
Después del paso 7, la mayoría de los archivos de configuración de tu
sistema Gentoo estarán preparados
-
Tras el paso 8, las herramientas de sistema necesarios (podrá elegirlas
de una hermosa lista) están instaladas.
-
Al finalizar el paso 9, el gestor de arranque elegido estará instalado y
configurado y usted está dentro de su nueva instalación de Gentoo.
-
Tras el paso 10, se encontrará dentro de su nueva Gentoo.
Cuando se le pide una elección especial, intentamos explicar lo mejor posible
los pros y contras. También propondremos una opción por defecto,
identificada con "Por defecto: " en el título. Las otras
posibilidades se titulan "Alternativa: ". Pero no
crea que la opción por defecto es la que recomendamos. Es la que pensamos
que la mayoría de usuarios van ha utilizar.
Algunas veces puedes seguir un paso opcional. Estos pasos son marcados como
"Opcional: " y no son necesarios para instalar Gentoo.
Sin embargo, algunos pasos opcionales dependen de una decisión tomada
previamente. Le informaremos cuando se dé el caso, tanto cuando tome la
decisión, como cuando se describa el paso opcional.
¿De qué opciones dispongo?
Puedes instalar Gentoo de diferentes formas. Puedes descargar e instalar
desde un LiveCD de Gentoo (CDs de instalación), desde otra distribución,
desde un CD de arranque (como Knoppix), desde un arranque por red, desde
un disquete de arranque,etc. Este documento cubre la instalación
utilizando uno de nuestros LiveCds o, en algunos casos, desde arranque
por red.
Si necesita ayuda para otros tipos de instalación, por favor lea nuestra
Guía de Instalación Alternativa.
También tenemos el documento
Trucos y consejos de Instalación de Gentoo (en inglés) que podría
resultar útil. Si nota que las instrucciones de instalación son demasiado
detalladas, no dude en utilizar nuestra Referencia Rápida para Instalación
la cual se encuentra entre nuestros Recursos
de Documentación si su arquitectura tiene este documento disponible.
También existen otras posibilidades: puede compilar el sistema completo
desde el principio o instalar paquetes precompilados para tener el sistema
listo en poco tiempo. Y, por supuesto, también hay soluciones intermedias
con las cuales no se compila todo el sistema pero se empieza desde un
sistema bastante completo.
¿Problemas?
Si tienes algún problema con la instalación (o con el documento
de instalación), por favor compruebe el error en nuestro
Proyecto de Ingeniería de
Versiones de Gentoo (en inglés), visite nuestro
Sistema de seguimiento
de errores y compruebe si el error es conocido. Si no lo es, por favor
cree un informe sobre él para que podamos encargarnos de él. No
tenga miedo de los desarrolladores que están asignados a sus
informes, normalmente no se comen a nadie.
Acuérdese que, a pesar de que el documento que está leyendo es
específico de la arquitectura, esté también contiene referencias a
otras arquitecturas. Esto es así porque el manual de Gentoo tiene
partes extensas de código que es común para todas las arquitecturas
(para evitar duplicar esfuerzos y el desgaste de los recursos de
desarrollo). Intentaremos reducir esto al mínimo para evitar la
confusión.
Si no estás seguro que el problema es de usuario (algún error que ha cometido al
despistarte y no leer la documentación cuidadosamente) o un problema de software
(algún error que hemos cometido despistándonos al probar la instalación y/o
documentación) eres libre de entrar en #gentoo-es en irc.freenode.net. Por supuesto,
eres bienvenido de todas formas :)
Si tiene cualquier pregunta concerniente a Gentoo, eche un vistazo a las Preguntas de Uso Frecuente, disponibles
en la Documentación de Gentoo. También puede
mirar los FAQs en nuestros
foros. Si no encuentras la respuesta
aquí, pregunta en #gentoo-es, nuestro canal IRC en irc.freenode.net. Sí, algunos de
nosotros somos frikis que aún usan el IRC :-)
1.b. ¿Precompilados o Compilar todo?
¿Qué es la Plataforma de Referencia de Gentoo?
La Plataforma de Referencia de Gentoo, de ahora en adelante la conoceremos
por su abreviatura inglesa GRP (Gentoo Reference Platform), es una imagen de
los paquetes precompilados que los usuarios (esto le implica a usted) pueden
instalar durante la instalación de Gentoo para acelerar el proceso
de instalación. La GRP contiene todos los paquetes necesarios para tener una
instalación de Gentoo completamente funcional. No son todos los necesarios
que hacen falta para tener una instalación base preparada en nada de tiempo,
pero todas las compilaciones grandes (como puedan ser KDE, xorg-x11, GNOME,
OpenOffice, Mozilla, ...) están disponibles como paquetes GRP.
Sin embargo, estos paquetes precompilados no son mantenidos durante la toda
la vida de la distribución de Gentoo. Son simplemente imágenes creadas con
cada distribución de Gentoo y hacen posible tener un sistema funcional en poco
tiempo. Puede actualizar el sistema en segundo plano mientras trabaja con su
entorno Gentoo.
Como maneja Portage los Paquetes GRP
Su árbol de Portage - la colección de ebuilds (los archivos que
contienen toda la información sobre un paquete, como es su descripción,
página oficial, las URLs de código fuente, instrucciones de compilación,
dependencias, etc.) - debe sincronizarse con los GRP: las versiones de
los ebuilds disponibles y su correspondiente paquete GRP deben coincidir.
Por esta razón necesita instalar una imagen de Portage en lugar de sincronizar
Portage con la última versión disponible si quiere utilizar el método de
instalación GRP.
¿Puedo utilizar GRP?
No se proporcionan paquetes GRP para todas las arquitecturas. Esto no
significa que GRP no esté soportado por el resto de arquitecturas, pero
significa que no disponemos de todos los recursos necesarios para
compilar y probar los paquetes GRP..
Por el momento proporcionamos paquetes GRP para las siguientes arquitecturas:
-
La arquitectura x86 (x86, pentium3, pentium4, athlon-xp)
Nota: Los paquetes GRP de x86 (por ejemplo packages-x86-2004.3.iso)
están disponibles en nuestros servidores espejo, mientras que pentium3,
pentium4, athlon-xp están sólo disponibles a través de bittorrent.
-
La arquitectura amd64 (amd64)
-
La arquitectura sparc (sparc32, sparc64)
-
La arquitectura ppc (G3. G4, G5)
Si su arquitectura (o subarquitectura) no está en la lista, no podrá
utilizar la opción GRP durante la instalación.
Ahora que ha terminado la introducción, continuemos con Escogiendo el medio apropiado.
2. Choosing the Right Installation Medium
2.a. Hardware Requirements
Introduction
Before we start, we first list what hardware requirements you need to
successfully install Gentoo on your box. This of course depends on your
architecture.
The HPPA Architecture
Check the following requirements before you
continue with the Gentoo installation:
2.b. Make your Choice
Introduction
Still interested in trying out Gentoo? Well, then it is now time to
choose the installation medium you want to use. Yes, you have the
choice, no, they are not all equal, and yes, the result is always the same: a
Gentoo base system.
The installation media we will describe are:
Before we continue, let's explain our three-stage installation.
The Three Stages
Gentoo Linux can be installed using one of three stage tarball files.
The one you choose depends on how much of the system you want to compile
yourself. The stage1 tarball is used when you want to bootstrap and
build the entire system from scratch. The stage2 tarball is used for
building the entire system from a bootstrapped "semi-compiled" state.
The stage3 tarball already contains a basic Gentoo Linux system that has
been built for you. As we will explain later, you can also install
Gentoo without compiling anything (except your kernel and some optional
packages). If you want this, you have to use a stage3 tarball.
Now what stage do you have to choose?
Starting from a stage1 allows you to have total control over the
optimization settings and optional build-time functionality that is
initially enabled on your system. This makes stage1 installs good for
power users who know what they are doing. It is also a great
installation method for those who would like to know more about the
inner workings of Gentoo Linux.
A stage1 installation can only be performed when you have a working
Internet connection.
| Stage1 |
Pros and Cons |
| + |
Allows you to have total control over the optimization settings and optional
build-time functionality that is initially enabled on your system
|
| + |
Suitable for powerusers that know what they are doing |
| + |
Allows you to learn more about the inner workings of Gentoo |
| - |
Takes a long time to finish the installation |
| - |
If you don't intend to tweak the settings, it is probably a waste of time
|
| - |
Not suitable for networkless installations
|
Stage2 installs allow you to skip the bootstrap process and doing this
is fine if you are happy with the optimization settings that we chose
for your particular stage2 tarball.
A stage2 installation can only be performed when you have a working
Internet connection.
| Stage2 |
Pros and Cons |
| + |
You don't need to bootstrap |
| + |
Faster than starting with stage1 |
| + |
You can still tweak your settings |
| - |
You cannot tweak as much as with a stage1 |
| - |
It's not the fastest way to install Gentoo |
| - |
You have to accept the optimizations we chose for the bootstrap |
| - |
Not suitable for networkless installations
|
Choosing to go with a stage3 allows for the fastest install of Gentoo
Linux, but also means that your base system will have the optimization
settings that we chose for you (which to be honest, are good settings
and were carefully chosen to enhance performance while maintaining
stability). stage3 is also required if you want to install Gentoo using
prebuilt packages or without a network connection.
| Stage3 |
Pros and Cons |
| + |
Fastest way to get a Gentoo base system |
| + |
Suitable for networkless installations |
| - |
You cannot tweak the base system - it's built already |
| - |
You cannot brag about having used stage1 or stage2 |
Write down (or remember) what stage you want to use. You need this later when
you decide what LiveCD (or other installation medium) you want to use. You might
be interested to know that, if you decide to use different optimization settings
after having installed Gentoo, you will be able to recompile your entire system
with the new optimization settings.
Now take a look at the available installation media.
Gentoo LiveCDs
The Gentoo LiveCDs are bootable CDs which contain a
self-sustained Gentoo environment. They allow you to boot Linux from the CD.
During the boot process your hardware is detected and the appropriate drivers
are loaded. They are maintained by Gentoo developers.
All LiveCDs allow you to boot, set up networking, initialize your
partitions and start installing Gentoo from the Internet. However, some
LiveCDs also contain all necessary source code so you are able to install
Gentoo without a working network configuration.
Now what does this LiveCD contain?
The Gentoo HPPA LiveCD
This is a small, no-nonsense, bootable CD which sole purpose is to boot the
system, prepare the networking and continue with the Gentoo installation. It
does not contain any stages (or, in some cases, a single stage1 file),
source code or precompiled packages.
2.c. Download, Burn and Boot a Gentoo LiveCD
Downloading and Burning the LiveCDs
You have chosen to use a Gentoo LiveCD (if not, then you are reading the
wrong section). We'll first start by downloading and burning the chosen
LiveCD. We previously discussed the several available LiveCDs, but where can you
find them?
Visit one of our mirrors and go to
experimental/hppa/livecd which is
the path where the LiveCD(s) of your choice are located. Inside that
directory you'll find so-called ISO-files. Those are full CD images
which you can write on a CD-R.
In case you wonder if your downloaded file is corrupted or not, you can
check its MD5 checksum and compare it with the MD5 checksum we provide (such as
install-hppa-minimal-2004.2.iso.md5). You can check the MD5 checksum
with the md5sum tool under Linux/Unix or md5sum for Windows.
Another way to check the validity of the downloaded file is to use GnuPG to
verify the cryptographic signature that we provide (the file ending with
.asc). Download the signature file and obtain the public key:
Listado de Código 3.1: Obtaining the public key |
$ gpg --keyserver pgp.mit.edu --recv-keys 17072058
|
Now verify the signature:
Listado de Código 3.2: Verify the cryptographic signature |
$ gpg --verify <signature file> <downloaded iso>
|
To burn the downloaded ISO(s), you have to select raw-burning. How you
do this is highly program-dependent. We will discuss cdrecord and
K3B here; more information can be found in our Gentoo FAQ.
-
With cdrecord, you simply type cdrecord dev=/dev/hdc (replace
/dev/hdc with your CD-RW drive's device path) followed
by the path to the ISO file :)
-
With K3B, select Tools > CD > Burn Image. Then
you can locate your ISO file within the 'Image to Burn' area. Finally click
Start.
Booting the HPPA LiveCD(s)
Nota:
If you have problems booting the LiveCD or any other media, please read the
PA-RISC Linux Boot HOWTO.
|
Boot your HPPA system. During the boot process, you will see a message similar
to the following:
Listado de Código 3.3: HPPA boot message |
Searching for Potential Boot Devices.
To terminate search, press and hold the ESCAPE key.
|
When this message appears, press and hold the Esc-key until an option menu
appears. This can take a while, be patient. By default, you should enter the
BOOT_ADMIN console. If you receive an option menu, choose Enter Boot
Administration mode to enter the BOOT_ADMIN console. You should now have an
'>' prompt.
Put the Gentoo LiveCD in the CD-ROM. If you do not know the SCSI ID of your
CD-ROM drive, your PA-RISC station will search for it when you issue the
search command.
Listado de Código 3.4: Searching for SCSI ID |
> search
Searching for Devices with Bootable Media.
To terminate search, please press and hold the ESCAPE key.
|
Your PA-RISC station will now display all the available boot media. This is an
example result of this command:
Listado de Código 3.5: Available boot media |
Device Selection Device Path Device Type and Utilities
---------------------------------------------------------------------------
P0 scsi.5.0 TOSHIBA CD-ROM XM-3301TA
IPL
P1 scsi.2.0 COMPAQ ST32550N
IPL
P2 lan.0010a7-06d1b6.3.6 server
IPL
|
To boot from a CD-ROM you need the accompanying Device Path. For instance, if we
want to boot from the TOSHIBA CD-ROM in the above example, we would need to type
the following command:
Listado de Código 3.6: Booting from a CD-ROM |
> boot scsi.5.0 ipl
Trying scsi.5.0
|
The ipl keyword (Initial Program Loader) tells palo (the PA-RISC boot
LOader) to enter interactive mode. This will allow you to change, for example,
the kernel boot parameters.
When the boot is successful, palo will start in interactive mode:
Listado de Código 3.7: PALO Interactive Mode |
Boot path initialized.
Attempting to load IPL.
Hard booted.
palo ipl 1.2 root@b180l.da-kot Tue Apr 8 12:43:07 CEST 2003
Boot image contains:
0/vmlinux32 4028015 bytes @ 0x1520000
0/ramdisk 834748 bytes @ 0xf800
Current command line:
0/vmlinux initrd=initrd.gz TERM=linux console=tty root=/dev/ram0 init=/linuxrc
0: 0/vmlinux
1: initrd=initrd.gz
2: TERM=linux
3: console=tty
4: root=/dev/ram0
5: init=/linuxrc
Edit which field?
(or 'b' to boot with this command line)?
|
These parameters are suitable for most situations.
If you need extra features you must add the appropriate keyword(s) to the end of
the command line. To add a keyword, edit the last field, add a space and type
your keyword. The only implemented keyword as of now is cdcache which
tells the LiveCD to load itself into RAM, allowing you to unmount the CD.
Listado de Código 3.8: Adding cdcache as boot option |
(or 'b' to boot with this command line)? 5
init=/linuxrc cdcache
|
Now that you have tweaked your kernel boot params, boot it.
Listado de Código 3.9: Booting the kernel |
(or 'b' to boot with this command line)? b
|
You should have a root ("#") prompt on the current console and can also switch
to other consoles by pressing Alt-F2, Alt-F3 and Alt-F4. Get back to the one you
started on by pressing Alt-F1.
Now continue with Extra Hardware
Configuration.
Extra Hardware Configuration
Most hppa machines have an onboard ethernet card. Old ones use use the lasi
driver which is compiled in the kernel. Newer ones need the tulip driver which
is compiled as a module. To use the latter, you need to load its driver.
In the next example, we try to load the tulip module (support for
certain kinds of network interfaces):
Listado de Código 3.10: Loading kernel modules |
# modprobe tulip
|
Optional: User Accounts
If you plan on giving other people access to your installation
environment or you want to chat using irssi without root privileges (for
security reasons), you need to create the necessary user accounts and change
the root password.
To change the root password, use the passwd utility:
Listado de Código 3.11: Changing the root password |
# passwd
New password:
Re-enter password:
|
To create a user account, we first enter their credentials, followed by
its password. We use useradd and passwd for these tasks.
In the next example, we create a user called "john".
Listado de Código 3.12: Creating a user account |
# useradd -m -G users john
# passwd john
New password:
Re-enter password:
|
You can change your user id from root to the newly created user by using
su:
Listado de Código 3.13: Changing user id |
# su - john
|
Optional: Viewing Documentation while Installing
If you want to view the Gentoo Handbook (either from-CD or online) during the
installation, make sure you have created a user account (see Optional: User Accounts). Then press Alt-F2 to
go to a new terminal and log in.
If you want to view the documentation on the CD you can immediately run
links2 to read it:
Listado de Código 3.14: Viewing the on-CD documentation |
# links2 /mnt/cdrom/docs/html/index.html
|
However, it is preferred that you use the online Gentoo Handbook as it will be
more recent than the one provided on the CD. You can view it using links2
as well, but only after having completed the Configuring your Network
chapter (otherwise you won't be able to go on the Internet to view the
document):
Listado de Código 3.15: Viewing the Online Documentation |
# links2 http://www.gentoo.org/doc/en/handbook/handbook-hppa.xml
|
You can go back to your original terminal by pressing Alt-F1.
Optional: Starting the SSH Daemon
If you want to allow other users to access your computer during the
Gentoo installation (perhaps because those users are going to help you
install Gentoo, or even do it for you), you need to create a user
account for them and perhaps even provide them with your root password
(only do that if you fully trust that user).
To fire up the SSH daemon, execute the following command:
Listado de Código 3.16: Starting the SSH daemon |
# /etc/init.d/sshd start
|
To be able to use sshd, you first need to set up your networking. Continue with
the chapter on Configuring your Network.
3. Configuring your Network
3.a. Puedes hacerlo sin red, pero...
¿Quién puede?
Dependiendo del medio que hayas elegido para instalar Gentoo, es posible o no
continuar sin red (e Internet). No, no estamos jugando contigo =).
Normalmente, necesitarás configurar la red (e Internet).
No obstante, Gentoo también te brinda la posibilidad de instalarse sin una
conexión de red. Esta excepción es sólo posible con los LiveCds Universales
de Gentoo.
¿Porqué necesito conexión de red?
Una instalación desde Internet desemboca en una Instalación de Gentoo
totalmente actualizada. Dispondrás de una instalación basada en el árbol
del portage (que es una colección de de paquetes que te ofrecemos junto a
las herramientas para mantener tu software) más actual. Esta es también la
razón por la cual se prefiere la instalación por red. No obstante, alguien
puede no disponer de ella o querer instalar Gentoo en un sistema sin conexión a
Internet.
Si se encuentra en esta situación necesitará utilizar el LiveCD Universal de
Gentoo. Este LiveCD incluye código fuente, una imagen instantánea del árbol
del portage y las herramientas para instalar un sistema base Gentoo y mucho
más. Este método tiene un precio: usted nunca dispondrá del software más
actual, aunque las diferencias serán mínimas.
Si desea continuar con la instalación sin conexión a la red tendrá que utilizar
el LiveCD Universal, sáltese el resto de este capítulo y continué con Preparando los Discos.
De lo contrario, continúe con las secciones de configuración de red más
abajo.
Opcional: Configure el Proxy
Si accede a Internet a través de un proxy, podría necesitar configurar la
información del proxy durante la instalación. Es muy sencillo definir un
proxy: tan solo necesita definir la variable que contiene la información
del mismo.
En la mayoría de los casos, usted puede definir las variables usando
simplemente el host del servidor. Por ejemplo, asumimos que el proxy se llama
proxy.gentoo.org y el puerto es el 8080.
Listado de Código 1.1: Definiendo los servidores proxy |
# export http_proxy="http://proxy.gentoo.org:8080"
# export ftp_proxy="ftp://proxy.gentoo.org:8080"
# export rsync_proxy="rsync://proxy.gentoo.org:8080"
|
Si su proxy requiere un nombre de usuario y una contraseña, debería usar
la siguiente sintaxis para la variable:
Listado de Código 1.2: Añadiendo usuario/contraseña a la variable del proxy |
http://usuario:contraseña@servidor
|
Por ejemplo, para un proxy HTTP con nuestro servidor de antes y el usuario
"juan" con la contraseña "f00b_r" se debería usar:
Listado de Código 1.3: Proxy autenticado |
# export http_proxy="http://juan:f00b_r@proxy.gentoo.org:8080"
|
3.b. Auto Detección de Red
¿Es posible que simplemente funcione?
Si su sistema está conectado a una red Ethernet con un servidor DHCP, es muy
probable que la configuración de red se haya detectado automáticamente. En
ese caso, debería ser capaz de trabajar con los con los comandos que hacen uso
de la red y que están en el LiveCD como ssh, scp,
ping, irssi, wget y links, entre otros.
Si la red ya ha sido configurada el comando /sbin/ifconfig
debería listar algunas interfaces de red además de lo, como eth0:
Listado de Código 2.1: /sbin/ifconfig para una tarjeta de red funcionando |
# /sbin/ifconfig
eth0 Link encap:Ethernet HWaddr 00:50:BA:8F:61:7A
inet addr:192.168.0.2 Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr: fe80::50:ba8f:617a/10 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1498792 errors:0 dropped:0 overruns:0 frame:0
TX packets:1284980 errors:0 dropped:0 overruns:0 carrier:0
collisions:1984 txqueuelen:100
RX bytes:485691215 (463.1 Mb) TX bytes:123951388 (118.2 Mb)
Interrupt:11 Base address:0xe800
|
Probando la red
Usted podría intentar hacer ping hacia el servidor DNS de su ISP, (que se
encuentra en /etc/resolv.conf) y un sitio web a su elección,
con la intención de asegurarse que sus paquetes llegan a la red, la
resolución de nombres DNS esta funcionando correctamente, etc ...
Listado de Código 2.2: Más testeo de red |
# ping -c 3 www.yahoo.com
|
¿Está su conexión funcionando? En ese caso, puede saltarse el resto de
esta sección y continuar con Preparando los
discos. De lo contrario, mala suerte, tendrá que perseverar un poco
más :)
3.c. Configuración Automática de Red
Si la red no funciona inmediatamente, algunos medios de instalación le
permitirán usar net-setup (para redes estándar o sin cables), adsl-setup
(para usuarios de ADSL) o pptp (para usuarios de PPTP solamenteme
disponible para x86).
Si su medio de instalación no contiene ninguna de estas herramientas,
continúe con Configuración Manual de la Red.
Por defecto: Usando net-setup
El sistema más simple de configurar una red, si no se consiguió hacerlo
automáticamente, es ejecutar el script net-setup:
Listado de Código 3.1: Ejecutando el script net-setup |
# net-setup eth0
|
net-setup le hará algunas preguntas sobre su entorno de red
Cuando lo haya completado, debería disponer de una conexión de red
funcionando. Pruebe su conexión de red como se especificó anteriormente
Si los resultados son positivos, ¡felicidades! Ahora está listo para instalar
Gentoo. Sáltese el resto de esta sección y continúe con Preparando los discos.
Si su conexión de red sigue sin funcionar, continúe con Configuración Manual de la Red.
Alternativa: Usando RP-PPPoE
Asumiendo que requiere PPPoE para conectar a Internet, el LiveCD (cualquier
versión) ha sido pensado para facilitarle el trabajo incluyendo
rp-pppoe. Use el script adsl-setup proporcionado para
configurar su conexión. Se le pedirá el dispositivo de red que esta
conectado a su módem adsl, su nombre de usuario y su contraseña, las IPs
de sus servidores DNS y si requiere un firewall básico o no.
Listado de Código 3.2: Usando rp-pppoe |
# adsl-setup
# adsl-start
|
Si algo va mal, asegúrese que ha tecleado correctamente su nombre de usuario
y su contraseña mirando /etc/ppp/pap-secrets o
/etc/ppp/chap-secrets y asegúrese que esta haciendo uso del
dispositivo de red correcto. Si su dispositivo de red no existe, deberá cargar
los módulos de red apropiados. En ese caso, debería continuar con Configuración manual de la Red dónde explicaremos
como cargar los módulos de red apropiados.
Si todo funcionó, continúe con Preparando los
Discos.
Alternativa: Usando PPTP
Si requiere soporte PPTP, puede usar pptpclient que se incluye en
nuestros LiveCDs. Pero primero debe asegurarse que su configuración es correcta
Edite /etc/ppp/pap-secrets o /etc/ppp/chap-secrets ya
que contiene la combinación correcta de usuario/contraseña:
Listado de Código 3.3: Editando /etc/ppp/chap-secrets |
# nano -w /etc/ppp/chap-secrets
|
Ajuste ahora /etc/ppp/options.pptp si es necesario:
Listado de Código 3.4: Editando /etc/ppp/options.pptp |
# nano -w /etc/ppp/options.pptp
|
Cuando todo esté listo, tan sólo ejecute pptp (junto con las opciones
que podría haber configurado en options.pptp) para conectar al
servidor:
Listado de Código 3.5: Conectando a un servidor por línea telefónica |
# pptp <server ip>
|
Ahora continúe con Preparando los discos.
3.d. Configuración Manual de la Red
Cargando los módulos de red apropiados
Cuando el Live CD arranca, intenta detectar todos sus dispositivos hardware y
carga los módulos del kernel (controladores) apropiados para darles soporte.
En la gran mayoría de los casos, hace un muy buen trabajo. No obstante, en
algunos casos, puede no cargar automáticamente los módulos del kernel que
necesita.
Si net-setup o adsl-setup fallaron, entonces puede asumir sin
ningún riesgo que su tarjeta de red no se encontró en el acto. Esto significa
que tendrá que cargar los módulos del kernel apropiados manualmente.
Para descubrir que módulos del kernel le proporcionamos para la red, use
ls:
Listado de Código 4.1: Buscando los módulos apropiados |
# ls /lib/modules/`uname -r`/kernel/drivers/net
|
Si encuentra un driver para su tarjeta de red, use modprobe para cargar
el módulo del kernel:
Listado de Código 4.2: Usando modprobe para cargar el módulo kernel |
# modprobe pcnet32
|
Para confirmar si su tarjeta de red se detecta ahora, use ifconfig. Una
red detectada debería desembocar en algo como esto:
Listado de Código 4.3: Comprobando la disponibilidad de su tarjeta de red, éxito |
# ifconfig eth0
eth0 Link encap:Ethernet HWaddr FE:FD:00:00:00:00
BROADCAST NOARP MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
|
Si de todas formas recibe el siguiente error, la tarjeta de red no está
detectada:
Listado de Código 4.4: Comprobando si la disponibilidad de su tarjeta de red fracasó |
# ifconfig eth0
eth0: error fetching interface information: Device not found
|
Si tiene múltiples tarjetas de red en su sistema éstas recibirán el nombre
eth0, eth1, etc. Asegúrese que la tarjeta de red que quiere
utilizar funciona correctamente y recuerde emplear el nombre correcto a lo
largo de este documento. Asumiremos que la tarjeta de red eth0 va
a ser la utilizada.
Asumiendo que usted dispone ahora de una tarjeta de red red detectada, puede
reintentar net-setup o adsl-setup otra vez (que deberían
funcionar ahora), pero para los duros de entre ustedes, les explicaremos como
configurar su red manualmente.
Seleccione una de las siguientes secciones basándose en su configuración
de red.
Usando DHCP
DHCP (Protocolo de Configuración Dinámica de Host) hace posible recibir
automáticamente su información de red (Dirección IP, máscara de red, dirección
de broadcast, pasarela, servidores de nombres etc.). Esto sólo funciona si usted
dispone de un servidor DHCP en su red (o si su proveedor le ofrece servicio
DHCP). Para conseguir que su interfaz de red reciba esta información
automáticamente use dhcpcd:
Listado de Código 4.5: Usando dhcpcd |
# dhcpcd eth0
# dhcpcd -HD eth0
|
Si esto funciona (pruebe hacer ping a algún servidor en Internet, como Google), entonces lo tiene todo configurado
y listo para continuar. Sáltese el resto de esta sección y continúe con Preparando los Discos.
Preparando el Acceso Inalámbrico (Wireless)
Nota:
No todos los LiveCDs tiene el comando iwconfig. Si el suyo no lo tiene,
todavía puede conseguir que sus extensiones funcionen siguiendo las
instrucciones del proyecto
linux-wlan-ng.
|
Si está empleando una tarjeta inalámbrica (802.11), quizá necesite configurar
sus opciones antes de ir más allá. Para revisar la configuración inalámbrica
actual de su tarjeta, puede utilizar iwconfig. Ejecutando
iwconfig debería mostrar algo como esto:
Listado de Código 4.6: Mostrando la configuración inalámbrica actual |
# iwconfig eth0
eth0 IEEE 802.11-DS ESSID:"GentooNode"
Mode:Managed Frequency:2.442GHz Access Point: 00:09:5B:11:CC:F2
Bit Rate:11Mb/s Tx-Power=20 dBm Sensitivity=0/65535
Retry limit:16 RTS thr:off Fragment thr:off
Power Management:off
Link Quality:25/10 Signal level:-51 dBm Noise level:-102 dBm
Rx invalid nwid:5901 Rx invalid crypt:0 Rx invalid frag:0 Tx
excessive retries:237 Invalid misc:350282 Missed beacon:84
|
Nota:
El nombre de dispositivo de algunas tarjetas de red inalámbricas es
wlan0 en lugar de eth0.
|
La mayoría de usuarios, solamente tendrá que modificar dos configuraciones,
el ESSID (Nombre de red inalámbrica) o la clave WEP. Si el ESSID y la
dirección del Punto de Acceso mostradas son correctas y el Punto de Acceso
y usted mismo no están utilizando WEP, su red inalámbrica está funcionando.
Si necesita cambiar su ESSID, o añadir una clave WEP, puede utilizar los
siguientes comandos:
Listado de Código 4.7: Cambiando ESSID y/o añadiendo una clave WEP |
# iwconfig eth0 essid GentooNode
# iwconfig eth0 key 1234123412341234abcd
# iwconfig eth0 key s:some-password
|
Puede volver a comprobar la configuración inalámbrica utilizando
iwconfig. Una vez que tenga la conexión funcionando, puede
continuar configurando las opciones de red de nivel IP como se describe
en la siguiente sección (Entendiendo la terminología de red) o
utilizar la herramienta net-setup como hemos descrito anteriormente.
Entendiendo la terminología de red
Nota:
Si conoce su dirección IP, dirección de broadcast, máscara de red y los
servidores de nombres, entonces puede saltarse esta subsección y continuar
con Usando ifconfig y route.
|
Si todo lo anterior falla, tendrá que configurar su red manualmente. No tenga
miedo, está lejos de ser difícil. Pero vamos a explicarle ciertos conceptos
de red que necesitará para ser capaz de configurar su red satisfactoriamente.
Cuando haya leído esto, conocerá que es una pasarela, para que sirve
una máscara de red, como se forma una dirección de broadcast
y porqué necesita servidores de nombres.
En una red los hosts están están identificados por su dirección IP
(dirección del Protocolo de Internet). Tal dirección es una combinación de
cuatro números entre 0 y 255. Bien, como mínimo así es como las percibimos. En
realidad, tal dirección IP consiste de 32 bits (unos y ceros). Vamos a ver un
ejemplo:
Listado de Código 4.8: Ejemplo de una dirección IP |
IP Address (numbers): 192.168.0.2
IP Address (bits): 11000000 10101000 00000000 00000010
-------- -------- -------- --------
192 168 0 2
|
Cada dirección IP es única para ese host, tan lejos como redes accesibles
estén a su disposición (por ejemplo, todos los hosts que usted es capaz de
conectar, deben tener direcciones IP únicas). Para ser capaz de hacer la
distinción entre hosts dentro de una red, y hosts fuera de una red, la
dirección IP está dividida en dos partes: la parte de red y la parte de
host.
La separación esta anotada en la máscara de red, una conjunto de unos
seguidos de un conjunto de ceros. La parte de la IP que quedan enmascarados
sobre los unos es la parte de red, la otra es la parte de host. Como es normal,
la máscara de red, puede ser anotada como una dirección IP.
Listado de Código 4.9: Ejemplo de una separación red/host |
IP-address: 192 168 0 2
11000000 10101000 00000000 00000010
Netmask: 11111111 11111111 11111111 00000000
255 255 255 0
+--------------------------+--------+
Network Host
|
En otras palabras, 192.168.0.14 es parte de nuestra red de ejemplo, pero
192.168.1.2 no lo es.
La dirección de broadcast es una dirección IP con la misma parte de red
que su red, pero con solo unos como parte de host. Cada host en su red escucha
esta dirección IP. Esto verdaderamente sirve para la transmisión de paquetes.
Listado de Código 4.10: Dirección de Broadcast |
IP-address: 192 168 0 2
11000000 10101000 00000000 00000010
Broadcast: 11000000 10101000 00000000 11111111
192 168 0 255
+--------------------------+--------+
Network Host
|
Para ser capaz de navegar por Internet, debería conocer qué host comparte la
conexión a Internet. Este host se llama la pasarela. Puesto que es un
host estándar, tiene direcciones IP estándar (por ejemplo 192.168.0.1).
Anteriormente afirmamos que cada host tiene su propia dirección IP. Para ser
capaz de alcanzar este host por un nombre (en vez de la dirección IP)
necesitara un servicio que traduzca un nombre (como dev.gentoo.org) a
una dirección IP (como 64.5.62.82). Tal servicio se le conoce como
servicio de nombres. Para usar tal servicio, debe definir los
servidores de nombres necesarios en /etc/resolv.conf.
En algunos casos, su pasarela también sirve como servidor de nombres. De otro
modo, tendrá que introducir los servidores de nombres facilitados por su ISP.
Para resumir, necesitará la siguiente información antes de continuar:
| Elemento de Red |
Ejemplo |
| Su dirección IP |
192.168.0.2 |
| Máscara de Red |
255.255.255.0 |
| Broadcast |
192.168.0.255 |
| Pasarela |
192.168.0.1 |
| Servidor(es) de nombres |
195.130.130.5, 195.130.130.133 |
Usando ifconfig y route
Configurar su red consiste en tres pasos. Primero, nos asignamos una dirección
IP usando ifconfig. Entonces configuraremos el ruteo hacia la pasarela
usando route. Por último, acabaremos situando las IPs de los servidores de
nombres en /etc/resolv.conf.
Para asignar una dirección IP, necesitara su dirección IP, la dirección de
broadcast y la mascara de red. Entonces ejecute el siguiente comando,
substituyendo ${IP_ADDR} con su dirección IP, ${BROADCAST} con
su dirección de broadcast y ${NETMASK} con su máscara de red:
Listado de Código 4.11: Usando ifconfig |
# ifconfig eth0 ${IP_ADDR} broadcast ${BROADCAST} netmask ${NETMASK} up
|
Ahora configure la ruta usando route. Substituya ${GATEWAY} con
la dirección IP de su pasarela:
Listado de Código 4.12: Usando route |
# route add default gw ${GATEWAY}
|
Ahora abra /etc/resolv.conf con su editor favorito (en nuestro
ejemplo, usaremos nano):
Listado de Código 8.15: Creando /etc/resolv.conf |
# nano -w /etc/resolv.conf
|
Ahora complete con su(s) servidor(es) de nombres usando la siguiente plantilla.
Asegúrese que substituye ${NAMESERVER1} y ${NAMESERVER2} con las
direcciones apropiadas de servidor de nombres:
Listado de Código 4.14: Plantilla /etc/resolv.conf |
nameserver ${NAMESERVER1}
nameserver ${NAMESERVER2}
|
Eso es. Ahora compruebe su red haciendo ping a algún servidor de Internet (como
Google). Si funciona, felicitaciones
entonces. Ahora está listo para instalar Gentoo. Continúe con Preparando los Discos.
4. Preparing the Disks
4.a. Introduction to Block Devices
Block Devices
We'll take a good look at disk-oriented aspects of Gentoo Linux
and Linux in general, including Linux filesystems, partitions and block devices.
Then, once you're familiar with the ins and outs of disks and filesystems,
you'll be guided through the process of setting up partitions and filesystems
for your Gentoo Linux installation.
To begin, we'll introduce block devices. The most famous block device is
probably the one that represents the first SCSI HD in a Linux system, namely
/dev/sda.
The block devices above represent an abstract interface to the disk. User
programs can use these block devices to interact with your disk without worrying
about whether your drives are IDE, SCSI or something else. The program can
simply address the storage on the disk as a bunch of contiguous,
randomly-accessible 512-byte blocks.
Partitions and Slices
Although it is theoretically possible to use a full disk to house your Linux
system, this is almost never done in practice. Instead, full disk block devices
are split up in smaller, more manageable block devices. On most systems,
these are called partitions. Other architectures use a similar technique,
called slices.
4.b. Designing a Partitioning Scheme
How Many and How Big?
The number of partitions is highly dependent on your environment. For instance,
if you have lots of users, you will most likely want to have your
/home separate as it increases security and makes backups easier.
If you are installing Gentoo to perform as a mailserver, your
/var should be separate as all mails are stored inside
/var. A good choice of filesystem will then maximise your
performance. Gameservers will have a separate /opt as most gaming
servers are installed there. The reason is similar for /home:
security and backups.
As you can see, it very much depends on what you want to achieve. Separate
partitions or volumes have the following advantages:
-
You can choose the best performing filesystem for each partition or volume
-
Your entire system cannot run out of free space if one defunct tool is
continuously writing files to a partition or volume
-
If necessary, file system checks are reduced in time, as multiple checks can
be done in parallel (although this advantage is more with multiple disks than
it is with multiple partitions)
-
Security can be enhanced by mounting some partitions or volumes read-only,
nosuid (setuid bits are ignored), noexec (executable bits are ignored) etc.
However, multiple partitions have one big disadvantage: if not configured
properly, you might result in having a system with lots
of free space on one partition and none on another. There is also a 15-partition
limit for SCSI and SATA.
4.c. Using fdisk on HPPA to Partition your Disk
Use fdisk to create the partitions you want:
Listado de Código 3.1: Partitioning the disk |
# fdisk /dev/sda
|
HPPA machines use the PC standard DOS partition tables. To create a new
DOS partition table, simply use the o command.
Listado de Código 3.2: Creating a DOS partition table |
# fdisk /dev/sda
Command (m for help): o
Building a new DOS disklabel.
|
PALO (the HPPA bootloader) needs a special partition to work. You have
to create a partition of at least 16Mb at the beginning of your disk.
The partition type must be of type f0 (Linux/PA-RISC boot).
Importante:
If you ignore this and continue without a special PALO partition, your system
will stop loving you and fail to start. Also, if your disk is larger than 2Gb,
make sure that the boot partition is in the first 2Gb of your disk. PALO is
unable to read a kernel after the 2Gb limit.
|
Listado de Código 3.3: A simple default partition schema |
# cat /etc/fstab
/dev/sda2 /boot ext3 noauto,noatime 1 1
/dev/sda3 none swap sw 0 0
/dev/sda4 / ext3 noatime 0 0
# fdisk /dev/sda
Command (m for help): p
Disk /dev/sda: 4294 MB, 4294816768 bytes
133 heads, 62 sectors/track, 1017 cylinders
Units = cylinders of 8246 * 512 = 4221952 bytes
Device Boot Start End Blocks Id System
/dev/sda1 1 8 32953 f0 Linux/PA-RISC boot
/dev/sda2 9 20 49476 83 Linux
/dev/sda3 21 70 206150 82 Linux swap
/dev/sda4 71 1017 3904481 83 Linux
|
Now that your partitions are created, you can now continue with Creating Filesystems.
4.d. Creating Filesystems
Introduction
Now that your partitions are created, it is time to place a filesystem on them.
If you don't care about what filesystem to choose and are happy with what we use
as default in this handbook, continue with Applying a Filesystem to a Partition.
Otherwise read on to learn about the available filesystems...
Filesystems?
Several filesystems are available. Ext2, ext3, XFS and reiserfs are found stable on
the HPPA architecture. The others are very experimental.
ext2 is the tried and true Linux filesystem but doesn't have metadata
journaling, which means that routine ext2 filesystem checks at startup time can
be quite time-consuming. There is now quite a selection of newer-generation
journaled filesystems that can be checked for consistency very quickly and are
thus generally preferred over their non-journaled counterparts. Journaled
filesystems prevent long delays when you boot your system and your filesystem
happens to be in an inconsistent state.
ext3 is the journaled version of the ext2 filesystem, providing metadata
journaling for fast recovery in addition to other enhanced journaling modes like
full data and ordered data journaling. ext3 is a very good and reliable
filesystem. It has an additional hashed b-tree indexing option that enables
high performance in almost all situations. In short, ext3 is an excellent
filesystem.
ReiserFS is a B*-tree based filesystem that has very good overall
performance and greatly outperforms both ext2 and ext3 when dealing with small
files (files less than 4k), often by a factor of 10x-15x. ReiserFS also scales
extremely well and has metadata journaling. As of kernel 2.4.18+, ReiserFS is
solid and usable as both general-purpose filesystem and for extreme cases such
as the creation of large filesystems, the use of many small files, very large
files and directories containing tens of thousands of files.
XFS is a filesystem with metadata journaling which comes with a robust
feature-set and is optimized for scalability. We only recommend using this
filesystem on Linux systems with high-end SCSI and/or fibre channel storage and
an uninterruptible power supply. Because XFS aggressively caches in-transit data
in RAM, improperly designed programs (those that don't take proper precautions
when writing files to disk and there are quite a few of them) can lose a good
deal of data if the system goes down unexpectedly.
JFS is IBM's high-performance journaling filesystem. It has recently
become production-ready and there hasn't been a sufficient track record to
comment positively nor negatively on its general stability at this point.
Applying a Filesystem to a Partition
To create a filesystem on a partition or volume, there are tools available for
each possible filesystem:
| Filesystem |
Creation Command |
| ext2 |
mke2fs |
| ext3 |
mke2fs -j |
| reiserfs |
mkreiserfs |
| xfs |
mkfs.xfs |
| jfs |
mkfs.jfs |
For instance, to have the boot partition (/dev/sda2 in our
example) in ext2 and the root partition (/dev/sda4 in our example)
in ext3 (as in our example), you would use:
Listado de Código 4.1: Applying a filesystem on a partition |
# mke2fs /dev/sda2
# mke2fs -j /dev/sda4
|
Now create the filesystems on your newly created partitions (or logical
volumes).
Activating the Swap Partition
mkswap is the command that is used to initialize swap partitions:
Listado de Código 4.2: Creating a Swap signature |
# mkswap /dev/sda3
|
To activate the swap partition, use swapon:
Listado de Código 4.3: Activating the swap partition |
# swapon /dev/sda3
|
Create and activate the swap now.
4.e. Mounting
Now that your partitions are initialized and are housing a filesystem, it is
time to mount those partitions. Use the mount command. Don't forget to
create the necessary mount directories for every partition you created. As an
example we mount the root and boot partition:
Listado de Código 5.1: Mounting partitions |
# mount /dev/sda4 /mnt/gentoo
# mkdir /mnt/gentoo/boot
# mount /dev/sda2 /mnt/gentoo/boot
|
Nota:
If you want your /tmp to reside on a separate partition, be sure to
change its permissions after mounting: chmod 1777 /mnt/gentoo/tmp. This
also holds for /var/tmp.
|
We will also have to mount the proc filesystem (a virtual interface with the
kernel) on /proc. But first we will need to place our files on the partitions.
Continue with Installing the Gentoo
Installation Files.
5. Installing the Gentoo Installation Files
4.a. Instalando el Stage comprimido (tarball)
Ajustando la Fecha/Hora correcta
Antes de continuar debes revisar la fecha y la hora y
actualizarlos. ¡Un reloj mal configurado puede traer
resultados extraños a futuro!
Para comprobar la fecha/hora actual, ejecute el comando date:
Listado de Código 1.1: Verificando la fecha/hora |
# date
Fri Oct 29 16:21:18 CEST 2004
|
Si la fecha/hora está equivocada, actualícela con el comando date
MMDDhhmmCCYY, con la siguiente sintaxis (Mes, Día,
hora, minuto, siglo (C) y año (Y)). Por
ejemplo, para colocar la fecha y hora a las 16:21 horas del 29 de
Octubre del 2004:
Listado de Código 1.2: Ajustando la fecha/hora |
# date 102916212004
|
Localizando el archivo Stage3
Si ha configurado su red porque necesita descargar un archivo stage3 correpondiente
a su arquitectura, continue con Alternativa: utilizando un
stage3 procedente de Internet. De lo contrario lea Por defecto:
utilizar un stage3 del LiveCD.
5.b. Por defecto: utilizar un stage3 del LiveCD
Extrayendo el Stage comprimido (tarball)
Los stages del CD se encuentran en el directorio /mnt/cdrom/stages.
Para ver una lista completa de los stages, utilice ls:
Listado de Código 2.1: Comprobando los stages disponibles |
# ls /mnt/cdrom/stages
|
Si el sistema le devuelve un error, quizá necesite montar el CD-ROM:
Listado de Código 2.2: Montando the CD-ROM |
# ls /mnt/cdrom/stages
ls: /mnt/cdrom/stages: No such file or directory
# mount /dev/cdroms/cdrom0 /mnt/cdrom
# ls /mnt/cdrom/stages
|
Ahora situese en el punto de montaje de Gentoo (normalmente /mnt/gentoo):
Listado de Código 2.3: Cambiando de directorio a /mnt/gentoo |
# cd /mnt/gentoo
|
Ahora vamos a descomprimir el stage que haya elegido. Esto lo haremos con la
herrramienta GNU tar. ¡Asegúrese de utilizar las mismas opciones
(-xvjpf)! En el siguiente ejemplo, descomprimimos el stage
stage3-<subarch>-2004.3.tar.bz2. Asegúrese de sustituir
el nombre del tarball por su propio stage.
Listado de Código 2.4: Descomprimiendo el stage |
# tar -xvjpf /mnt/cdrom/stages/stage3-<subarch>-2004.3.tar.bz2
|
Ahora que el stage está instalado, continué con Instalando Portage.
5.c. Alternativa: utilizando utilizando un stage procedente de Internet
Descargando el stage
Vaya al punto de montaje de Gentoo en donde haya montado los sistemas
de archivo (probablemente /mnt/gentoo):
Listado de Código 3.1: Ir al punto de montaje de Gentoo |
# cd /mnt/gentoo
|
Dependiendo del medio de instalación, tendremos un par de herramientas
disponibles para descargar el stage. Si disponemos de links2,
podremos navegar por la lista de
servidores réplica de Gentoo y escoger el más cercano a
nosotros.
Si no tiene links2, debería disponer de lynks. Si necesita
pasar a través de un proxy, exporte las variables http_proxy y
ftp_proxy:
Listado de Código 3.2: Configurando la información del proxy para lynx |
# export http_proxy="http://proxy.server.com:port"
# export ftp_proxy="http://proxy.server.com:port"
|
A partir de ahora asumiremos que tiene links2 a su disposición.
Luego entre en el directorio releases/ seguido
de tu arquitectura (por ejemplo x86/ y la versión de
Gentoo (2004.3/) para finalizar con el directorio de los
stages stages/. Allí deberías ver todos los archivos de
las stages disponibles para tu arquitectura. Selecciona uno y presiona
D para descargarlo. Cuando se haya descargado, presiona
Q para cerrar el navegador.
Listado de Código 3.3: Navegando por la lista de servidores réplica con links2 |
# links2 http://www.gentoo.org/main/en/mirrors.xml
# links2 -http-proxy proxy.server.com:8080 http://www.gentoo.org/main/en/mirrors.xml
|
Si quiere comprobar la integridad del tarball de stage que ha descargado,
utilice md5sum y compare la salida con la suma de comprobación
MD5 que proporciona el servidor réplica. Por ejemplo, para comprobar
la validez del tarball de stage de x86:
Listado de Código 3.4: Ejemplo de comprobación de integridad del tarball de stage |
# md5sum -c stage1-x86-2004.3.tar.bz2.md5
stage1-x86-2004.3.tar.bz2: OK
|
Extraer el Stage comprimido
Ahora desempaquetamos el stage descargado en sistema. Usaremos el
tar de GNU para dicha labor y este es el método más fácil.
Listado de Código 3.5: Descomprimiendo el Stage |
# tar -xvjpf stage?-*.tar.bz2
|
Asegúrese de usar las mismas opciones -xvjpf). La x se usa para
Desempaquetar, la v para ver que pasa durante el proceso de
extracción (Ok, sí, es opcional), el j para Descomprimir con bzip2,
el p para Preservar los permisos y el f para decir que
extraemos un archivo, no la entrada estándar.
Ahora que el stage está instalado sigamos con Instalando Portage.
5.d. Instalando Portage
Instalando una imagen de Portage
Ahora tiene que instalar una imagen de Portage, es un conjunto de archivos
que informan a Portage sobre los programas que puede instalar, que perfiles
están disponibles, etc.
Descomprimiendo la imagen del LiveCD
Para instalar la imagen, eche un vistazo a /mnt/cdrom/snapshots/
para comprobar que imagen está disponible:
Listado de Código 4.1: Comprobando el contenido de /mnt/cdrom/snapshots |
# ls /mnt/cdrom/snapshots
|
Ahora extraeremos la imagen siguiendo el siguiente método. De nuevo, asegúrese
de usar las opciones correctas para tar. También, la -C que es
mayúscula C, no c. En el siguiente ejemplo usaremos
portage-20041022.tar.bz2 como el nombre de la imagen.
Asegúrese de sustituirlo por el nombre de la imagen que tiene en su LiveCD.
Listado de Código 4.2: Extrayendo la imagen de Portage |
# tar -xvjf /mnt/cdrom/snapshots/portage-20041022.tar.bz2 -C /mnt/gentoo/usr
|
Copiando los archivos de código fuente
También necesita copiar todo el código fuente desde el LiveCD Universal.
Listado de Código 4.3: Copiando el código fuente |
# mkdir /mnt/gentoo/usr/portage/distfiles
# cp /mnt/cdrom/distfiles/* /mnt/gentoo/usr/portage/distfiles/
|
5.e. Configurando las opciones de compilación
Introducción
Para optimizar Gentoo, tendrás que ajustar un par de variables que
afectarán el comportamiento de Portage. Todas estas variables se
pueden fijar como variables de entorno (usando export) pero eso
no es permanente. Para mantener tu configuración, Portage dispone de
/etc/make.conf, un fichero de configuración para
Portage. Este es el fichero que editaremos ahora.
Nota:
Una lista comentada de todas las posibles variables puede
encontrarse en /mnt/gentoo/etc/make.conf.example. Para
una instalación de Gentoo correcta lo único que necesita es configurar
las variables que se mencionan en las siguientes líneas.
|
Usa tu editor favorito (en esta guía nosotros usaremos nano. Así que
empezamos con la modificación de las variables.
Listado de Código 5.1: Abriendo /etc/make.conf |
# nano -w /mnt/gentoo/etc/make.conf
|
Como probablemente te darás cuenta, el fichero make.conf
está estructurado de una manera genérica: Las líneas comentadas
empiezan con "#", otras líneas definen variables usando la sintaxis
VARIABLE="contenido". Discutiremos muchas de esas variables más
adelante.
Aviso:
No haga ninguna modificación en la variable USE si va a ejecutar un instalación
stage3 con GRP. Puede modificar la variable USE después de tener instalados
los paquetes que desee.¡Los Gremlins serán avisados para asaltar su sistema
si ignora este aviso!.
|
CHOST
Aviso: Aunque puede ser interesante para los usuarios que no iniciaron
la instalación con el Stage 1, no deberían cambiar el parámetro
CHOST en el make.conf ya que pueden volver el
sistema inutilizable. De nuevo, sólo cambie esta variable si usa una
instalación desde el stage1.
|
La variable CHOST define la arquitectura para la cual
gcc ha de compilar los programas. Las posibilidades son:
| Arquitectura |
Subarquitectura |
Valor del CHOST |
| x86 |
i386 |
i386-pc-linux-gnu |
| x86 |
i486 |
i486-pc-linux-gnu |
| x86 |
i586 |
i586-pc-linux-gnu |
| x86 |
i686 y superior (incl. athlon) |
i686-pc-linux-gnu |
| alpha |
|
alpha-unknown-linux-gnu |
| ppc |
|
powerpc-unknown-linux-gnu |
| ppc64 |
|
powerpc64-unknown-linux-gnu |
| sparc |
|
sparc-unknown-linux-gnu |
| sparc64 |
|
sparc-unknown-linux-gnu |
| hppa |
(genérico) |
hppa-unknown-linux-gnu |
| hppa |
pa7000 |
hppa1.1-unknown-linux-gnu |
| hppa |
pa8000 y superior |
hppa2.0-unknown-linux-gnu |
| mips |
|
mips-unknown-linux-gnu |
| amd64 |
|
x86_64-pc-linux-gnu |
Por favor, asegúrese de utilizar la configuración correcta para CHOST.
Por ejemplo, la configuración de CHOST para sparc64 continua siendo
sparc-unknown-linux-gnu y no ¡sparc64-unknown-linux-gnu!
CFLAGS y CXXFLAGS
Las variables CFLAGS y CXXFLAGS, definen los parámetros
de optimización para el compilador de C y C++ de gcc
respectivamente. Aunque generalmente se definen aquí, tendrás el
máximo rendimiento si optimizas estos parámetros para cada programa
por separado. La razón es que cada programa es diferente.
En el fichero make.conf deberás definir los parámetros de
optimización que pienses que vayan a hacer tu sistema el mejor en
todas las situaciones. No coloques parámetros experimentales en
esta variable; un nivel demasiado alto de optimización puede hacer que los programas se comporten mal (cuelgues, o incluso peor, funcionamientos erróneos).
No explicaremos todas las opciones posibles para la optimización. Pero
si quieres conocerlas todas, léete El manual en línea
de GNU o la página información de gcc (info gcc -- Solo
en un sistema Linux funcional). El fichero make.conf
también contiene una gran cantidad de ejemplos e información; no
olvides leerlo también.
La primera variable es el parámetro -march=, que especifica el nombre
de la arquitectura seleccionada. Las posibles opciones están descritas en el
fichero make.conf (como comentarios). Por ejemplo, para la
arquitectura x86 Athlon XP:
Listado de Código 5.2: El parámetro march de GCC |
-march=athlon-xp
|
Seguida de esta, está el parámetro -O, que especifica la clase
optimización de gcc. Las clases posibles son s (para
tamaño optimizado), 0 (para no optimizar), 1, 2
or 3 para la optimización de velocidad (cada clase tiene los
mismos parámetros que la primera, más algunos extras). Por ejemplo
para una optimización de clase 2:
Listado de Código 5.3: El parámetro O de GCC |
-O2
|
Otros parámetros de optimización bastante populares son los
-pipe (usando tuberías en lugar de ficheros temporales para la
comunicación entre las diferentes etapas de compilación).
Cuidado con utilizar -fomit-frame-pointer (el cual no mantiene
el puntero de macro en un registro para las funciones que no lo necesiten)
pues podría tener graves repercusiones en la depuración de errores en
aplicaciones.
Cuando definimos las variables CFLAGS y CXXFLAGS,
deberías combinar algunos parámetros de optimización, como en el
ejemplo siguiente:
Listado de Código 5.4: Definiendo las variables CFLAGS y CXXFLAGS |
CFLAGS="-march=athlon-xp -pipe -O2"
CXXFLAGS="${CFLAGS}" |
MAKEOPTS
Con la variable MAKEOPTS definimos cuantas compilaciones
paralelas pueden hacerse al mismo tiempo cuando instalamos un
paquete. El número sugerido es la cantidad de CPUs de tu sistema, más uno
Listado de Código 5.5: MAKEOPTS para un sistema normal de 1-CPU |
MAKEOPTS="-j2"
|
¡Preparados, listos, ya!
Actualiza tu /mnt/gentoo/etc/make.conf con tus propios
parámetros y guarda los cambios. Ahora estamos listos para continuar
con Instalando el sistema base de Gentoo.
6. Installing the Gentoo Base System
6.a. Chrooting
Montando el sistema de archivos proc
Monte el sistema de ficheros /proc en
/mnt/gentoo/proc para permitir a la instalación
utilizar la información proporcionada por el kernel incluso dentro
del entorno chroot.
Listado de Código 1.1: Montando /proc |
# mount -t proc none /mnt/gentoo/proc
|
Opcional: Copiar la información DNS
Si ha configurado su red para descargar posteriormente el stage
correspondiente desde Internet, necesita copiar la información DNS
guardada en /etc/resolv.conf a
/mnt/gentoo/etc/resolv.conf. Este archivo contiene los nombres
de los servidores que su sistema utiliza para resolver los nombres y las
direcciones IP.
Listado de Código 1.2: Copiando los DNS |
# cp -L /etc/resolv.conf /mnt/gentoo/etc/resolv.conf
|
Entrando al nuevo entorno
Ahora que todas las particiones están inicializadas y el sistema base
instalado, es hora de entrar en nuestro nuevo entorno de instalación
chrooting. Esto significa pasar desde el actual
entorno de instalación (LiveCD o otro medio de instalación) hacia tu
entorno de instalación (o sea, las particiones inicializadas).
El cambio de raíz se hace en tres pasos. Primero cambiamos la raíz
desde / (en el medio de instalación) a /mnt/gentoo
(en tus particiones) usando chroot. Después crearemos un nuevo entorno
usando env-update, el cual, en esencia crea las variables de entorno.
Finalmente, cargamos esas variables en memoria tecleando source.
Listado de Código 1.3: Entrando al nuevo entorno |
# chroot /mnt/gentoo /bin/bash
# env-update
* Caching service dependencies...
# source /etc/profile
|
¡Enhorabuena! Estás dentro de tu nuevo entorno Gentoo Linux.
Por supuesto aún no hemos terminado, todavía quedan unas cuantas
secciones ;)
6.b. Configurando la variable USE
¿Qué es la variable USE?
USE es una de las variables más importantes que Gentoo proporciona a
sus usuarios. Muchos programas pueden ser compilados con o sin soporte
opcional para ciertas cosas. Por ejemplo, algunos programas pueden ser
compilados con soporte gtk,o con soporte qt. Otros programas pueden ser
compilados con o sin soporte SSL. Algunos programas pueden ser compilados
con soporte framebuffer en lugar de soporte X11 (servidor X).
Muchas distribuciones compilan sus paquetes con el mayor soporte posible,
aumentando el tamaño de los programas y su tiempo de carga, sin mencionar
una cantidad enorme de dependencias. Con Gentoo puedes definir con que
opciones debe ser compilado un paquete. Ahí es donde actúa la variable
USE.
En la variable USE definimos palabras clave que son mapeadas a
opciones de compilación. Por ejemplo ssl compilará los programas
que lo requieran con soporte ssl.-X quitara el soporte para el servidor
X (nótese el signo menos delante). gnome gtk -kde -qt compilará tus
programas con soporte para gnome y gtk, pero sin soporte para kde (y qt),
haciendo tu sistema completamente compatible con GNOME.
Modificando la variable USE
Aviso:
No haga ninguna modificación en la variable USE si va a ejecutar un instalación
stage3 con GRP. Puede modificar la variable USE después de tener instalados
los paquetes que desee.¡Los Gremlins serán avisados para asaltar su sistema
si ignora este aviso!.
|
Los valores por defecto de la variable USE se encuentran en
make.defaults, archivos de su perfil. Encontrará los archivos
make.defaults en el directorio al cual apunte
/etc/make.profile y todos sus directorios padres. El valor
predeterminado de configuración de la variable USE es la suma de
todas las configuraciones de USE en todos los archivos
make.defaults. Lo que modifique en /etc/make.conf
se calcula contra estos valores. Si pone algún valor en su USE, es
añadido a la lista por defecto. Si elimina algo en su variable USE,
poniéndole un signo menos delante, es eliminado de la lista por defecto
(si estaba en ella claro). Nunca cambie nada en
/etc/make.profile ya que se sobreescribirá cuando actualice Portage!
Puede encontrar una descripción más amplia sobre la variable USE
en la segunda parte del Manual de Gentoo Capítulo 1: Variables USE. Encontrará
una descripción más extensa sobre las opciones de la variable USE en su sistema,
en /usr/portage/profiles/use.desc.
Listado de Código 2.1: Viendo las opciones disponibles |
# less /usr/portage/profiles/use.desc
|
Como ejemplo, te mostramos unas opciones USE para un sistema basado
en KDE con DVD, ALSA y soporte para grabar CD's.
Listado de Código 2.2: Abriendo /etc/make.conf |
# nano -w /etc/make.conf
|
Listado de Código 2.3: Configurando la variable USE |
USE="-gtk -gnome qt kde dvd alsa cdr"
|
7. Configuring the Kernel
7.a. Timezone
You first need to select your timezone so that your system knows where it is
located. Look for your timezone in /usr/share/zoneinfo, then make a
symlink to /etc/localtime using ln:
Listado de Código 1.1: Setting the timezone information |
# ls /usr/share/zoneinfo
# ln -sf /usr/share/zoneinfo/GMT /etc/localtime
|
7.b. Installing the Sources
Choosing a Kernel
The core around which all distributions are built is the Linux kernel. It is the
layer between the user programs and your system hardware. Gentoo provides its
users several possible kernel sources. A full listing with description is
available at the Gentoo Kernel
Guide.
For HPPA we have hppa-sources for 2.4 series and hppa-dev-sources
for 2.6 series. Continue by installing the kernel source:
Listado de Código 2.1: Installing a kernel source |
# emerge hppa-sources
|
When you take a look in /usr/src you should see a symlink called
linux pointing to your kernel source:
Listado de Código 2.2: Viewing the kernel source symlink |
# ls -l /usr/src/linux
lrwxrwxrwx 1 root root 12 Oct 13 11:04 /usr/src/linux -> linux-2.4.24
|
If this isn't the case (i.e. the symlink points to a different kernel source)
change the symlink before you continue:
Listado de Código 2.3: Changing the kernel source symlink |
# rm /usr/src/linux
# cd /usr/src
# ln -s linux-2.4.24 linux
|
Now it is time to configure and compile your kernel source. All architectures
can use genkernel for this, which will build a generic kernel as used
by the LiveCD. We explain the "manual" configuration first though, as it is
the best way to optimize your environment.
If you want to manually configure your kernel, continue now with Default: Manual Configuration. If you want to use
genkernel you should read Alternative: Using
genkernel instead.
3.c. Default: Manual Configuration
Introduction
Manually configuring a kernel is often seen as the most difficult procedure a
Linux user ever has to perform. Nothing is less true -- after configuring a
couple of kernels you don't even remember that it was difficult ;)
However, one thing is true: you must know your system when you start
configuring a kernel manually. Most information can be gathered by viewing the
contents of /proc/pci (or by using lspci if available). You
can also run lsmod to see what kernel modules the LiveCD uses (it might
provide you with a nice hint on what to enable).
Now go to your kernel source directory and execute make menuconfig. This
will fire up an ncurses-based configuration menu.
Listado de Código 3.1: Invoking menuconfig |
# cd /usr/src/linux
# make menuconfig
|
You will be greeted with several configuration sections. We'll first list some
options you must activate (otherwise Gentoo will not function, or not function
properly without additional tweaks).
Activating Required Options
First of all, activate the use of development and experimental code/drivers.
You need this, otherwise some very important code/drivers won't show up:
Listado de Código 3.2: Selecting experimental code/drivers |
Code maturity level options --->
[*] Prompt for development and/or incomplete code/drivers
|
Now go to File Systems and select support for the filesystems you use.
Don't compile them as modules, otherwise your Gentoo system will not be
able to mount your partitions. Also select Virtual memory, /proc
file system, /dev file system + Automatically mount at boot:
Listado de Código 3.3: Selecting necessary file systems |
File systems --->
[*] Virtual memory file system support (former shm fs)
[*] /proc file system support
[*] /dev file system support (EXPERIMENTAL)
[*] Automatically mount at boot
[ ] /dev/pts file system for Unix98 PTYs
File systems --->
Pseudo Filesystems --->
[*] /proc file system support
[*] /dev file system support (OBSOLETE)
[*] Automatically mount at boot
[*] Virtual memory file system support (former shm fs)
<*> Reiserfs support
<*> Ext3 journalling file system support
<*> JFS filesystem support
<*> Second extended fs support
<*> XFS filesystem support
|
If you are using PPPoE to connect to the Internet or you are using a dial-up
modem, you will need the following options in the kernel:
Listado de Código 3.4: Selecting PPPoE necessary drivers |
Network device support --->
<*> PPP (point-to-point protocol) support
<*> PPP support for async serial ports
<*> PPP support for sync tty ports
Device Drivers --->
Networking support --->
<*> PPP (point-to-point protocol) support
<*> PPP support for async serial ports
<*> PPP support for sync tty ports
|
The two compression options won't harm but are not definitely needed, neither
does the PPP over Ethernet option, that might only be used by
rp-pppoe when configured to do kernel mode PPPoE.
If you require it, don't forget to include support in the kernel for your
ethernet card.
If you have a HIL mouse or keyboard, do not forget to compile in support for
them.
Listado de Código 3.5: Activating HIL support |
Input core support --->
[*] Keyboard support
[*] Mouse support
[*] Event interface support
|
If you have no mouse on your HIL port, only use the basic support:
Listado de Código 3.6: Basic HIL support |
HIL support --->
[*] HIL Keyboard (basic) support
|
If you however want full HIL support, select the following options:
Listado de Código 3.7: Full HIL support |
HIL support --->
[*] HP System Device Controller i8042 Support
[*] HIL MLC Support
[*] HIL Keyboard (full) support
[*] HIL Mouse & Pointer support
|
Also include display driver support:
Listado de Código 3.8: Display Driver support |
Graphics support --->
[*] Support for frame buffer devices
[*] HP STI frame buffer device support
Console display driver support --->
[*] STI text console
|
When you're done configuring your kernel, continue with Compiling and Installing.
Compiling and Installing
Now that your kernel is configured, it is time to compile and install it. Exit
the configuration and run make dep && make vmlinux modules
modules_install:
Listado de Código 3.9: Compiling the kernel |
# make dep && make vmlinux modules modules_install
# make && make modules_install
|
When the kernel has finished compiling, copy the kernel image to
/boot. In the next example we assume you have configured and
compiled vanilla-sources-2.4.24 (which may not be the right kernel for
your architecture!):
Listado de Código 3.10: Installing the kernel |
# cp vmlinux /boot/kernel-2.4.24
# cp System.map /boot/System.map-2.4.24
|
It is also wise to copy over your kernel configuration file to
/boot, just in case :)
Listado de Código 3.11: Backing up your kernel configuration |
# cp .config /boot/config-2.4.24
|
Now continue with Configuring Kernel
Modules.
7.d. Alternative: Using genkernel
If you are reading this section, you have chosen to use our genkernel
script to configure your kernel for you.
Now that your kernel source tree is installed, it's now time to compile your
kernel by using our genkernel script to automatically build a kernel for
you. genkernel works by configuring a kernel nearly identically to the
way our LiveCD kernel is configured. This means that when you use
genkernel to build your kernel, your system will generally detect all
your hardware at boot-time, just like our Live CD does. Because genkernel
doesn't require any manual kernel configuration, it is an ideal solution for
those users who may not be comfortable compiling their own kernels.
Now, let's see how to use genkernel. First, emerge the genkernel ebuild:
Listado de Código 4.1: Emerging genkernel |
# emerge genkernel
|
Now, compile your kernel sources by running genkernel all.
Be aware though, as genkernel compiles a kernel that supports almost all
hardware, this compilation will take quite a while to finish!
Note that, if your boot partition doesn't use ext2 or ext3 as filesystem you
need to manually configure your kernel using genkernel --menuconfig all
and add support for your filesystem in the kernel (i.e. not as a
module).
Listado de Código 4.2: Running genkernel |
# genkernel all
GenKernel v3.0.1_beta10
* ARCH: HPPA
* KERNEL VER: 2.4.24
* kernel: configuring source
* kernel: running mrproper
* Kernel compiled successfully!
* Required Kernel Params:
* : root=/dev/ram0 init=/linuxrc real_root=/dev/$ROOT
* where $ROOT is the devicenode for your root partition as
* you should have specified in /etc/fstab
*
* You MUST tell your bootloader to use the generated initrd
*
* Recommended Kernel Params:
* : vga=0x317 splash=verbose
*
* Do NOT report kernel bugs (configs included) as genkernel bugs.
* Make sure you have the latest genkernel before reporting bugs
*
* For more info see /usr/share/genkernel/README
|
Once genkernel completes, a kernel, full set of modules and
initial root disk (initrd) will be created. We will use the kernel
and initrd when configuring a boot loader later in this document. Write
down the names of the kernel and initrd as you will need it when writing
the bootloader configuration file. The initrd will be started immediately after
booting to perform hardware autodetection (just like on the Live CD) before
your "real" system starts up.
Listado de Código 4.3: Checking the created kernel image name and initrd |
# ls /boot/kernel* /boot/initrd*
|
Now, let's perform one more step to get our system to be more like the Live
CD -- let's emerge hotplug. While the initrd autodetects hardware that
is needed to boot your system, hotplug autodetects everything else.
To emerge and enable hotplug, type the following:
Listado de Código 4.4: Emerging and enabling hotplug |
# emerge hotplug
# rc-update add hotplug default
|
3.e. Configuring Kernel Modules
Configuring the Modules
You should list the modules you want automatically loaded in
/etc/modules.autoload.d/kernel-2.4 (or kernel-2.6).
You can add extra options to the modules too if you want.
To view all available modules, run the following find command. Don't
forget to substitute "<kernel version>" with the version of the kernel you
just compiled:
Listado de Código 5.1: Viewing all available modules |
# find /lib/modules/<kernel version>/ -type f -iname '*.o' -or -iname '*.ko'
|
For instance, to automatically load the 3c59x.o module, edit the
kernel-2.4 or kernel-2.6 file and enter the module
name in it.
Listado de Código 5.2: Editing /etc/modules.autoload.d/kernel-2.4 |
# nano -w /etc/modules.autoload.d/kernel-2.4
|
Listado de Código 5.3: /etc/modules.autoload.d/kernel-2.4 or kernel-2.6 |
3c59x
|
Now run modules-update to commit your changes to the
/etc/modules.conf file:
Listado de Código 5.4: Running modules-update |
# modules-update
|
Continue the installation with Configuring
your System.
8. Configuring your System
8.a. Información del Sistema de Ficheros
¿Qué es el fstab?
En linux, todas las particiones usadas por el sistema deben estar reflejadas en
/etc/fstab. Este fichero contiene los puntos de montaje de esas
particiones (donde se encuentran en la estructura del sistema de ficheros),
cómo deben ser montadas y con que opciones especiales (automáticamente o no,
si los usuarios pueden montarlas o no, etc.).
Creando el /etc/fstab
/etc/fstab usa una sintaxis especial. Cada línea está formada por
seis campos, separados por espacios en blanco (espacio(s), tabuladores o una
combinación). Cada campo tiene su propio significado:
-
El primer campo muestra la partición descrita (la ruta al fichero de
dispositivo)
-
El segundo campo muestra el punto de montaje donde la partición debe
montarse
-
El tercer campo muestra el sistema de ficheros usado por la partición
-
El cuarto campo muestra las opciones de montaje usadas por
mount cuando trata de montar la partición. Como cada sistema de
ficheros tiene sus propias opciones de montaje, le animamos a leer la página
man de mount (man mount) para un listado completo. Cuando existen
múltiples opciones se separan por comas.
-
El quinto campo es usado por dump para determinar si la partición
requiere ser volcada o no. En general puede dejar esto como 0 (cero).
-
El sexto campo es usado por fsck para determinar el orden en que los
sistemas de ficheros deben ser comprobados si el sistema no se apagó
correctamente. La partición raíz debe tener un 1 mientras que el resto
puede tener 2 (o 0 en el caso en que la comprobación del
sistema de ficheros no sea necesaria).
El archivo /etc/fstab que proporciona Gentoo de manera predeterminada no es un archivo fstab válido, así que ejecute nano (o su editor favorito) para crear su propio /etc/fstab:
Listado de Código 1.1: Abriendo /etc/fstab |
# nano -w /etc/fstab
|
Vamos a ver como anotaremos las opciones para la partición /boot
. Esto es solo un ejemplo, así que si su arquitectura no requiere una partición
/boot (como por ejemplo PPC), no lo copie al pie de la letra.
En nuestro ejemplo de particionamiento estándar para x86, /boot
es la partición /dev/hda1, con un sistema de ficheros ext2.
Esta necesita ser comprobada durante el arranque. Entonces escribiríamos:
Listado de Código 1.2: Un ejemplo de línea /boot para /etc/fstab |
/dev/hda1 /boot ext2 defaults 1 2
|
Algunos usuarios no quieren que su partición /boot sea montada
automáticamente para mejorar la seguridad de su sistema. Estos usuarios
deberían sustituir defaults por noauto. Esto implica la
necesidad de montar manualmente la partición cada vez que se quiera usarla.
Para aumentar el rendimiento, la mayoría de usuarios podrían querer agregar la
opción noatime como opción de montaje, que desemboca en un sistema más
rápido, puesto que los tiempos de acceso no son registrados (de todas formas,
no necesitará esto en general):
Listado de Código 1.3: Una línea /boot mejorada para /etc/fstab |
/dev/hda1 /boot ext2 defaults,noatime 1 2
|
Si seguimos estos pasos, acabaríamos con las siguientes tres líneas (para
/boot, / y la partición de swap):
Listado de Código 1.4: Tres líneas del /etc/fstab |
/dev/hda1 /boot ext2 defaults,noatime 1 2
/dev/hda2 none swap sw 0 0
/dev/hda3 / ext3 noatime 0 1
|
Para finalizar, debería agregar una línea para /proc, tmpfs
(requerido) y sus dispositivos CD-ROM (y por supuesto, si tiene otras
particiones o dispositivos, para ellos también):
Listado de Código 1.5: Un ejemplo de /etc/fstab completo |
/dev/hda1 /boot ext2 defaults,noatime 1 2
/dev/hda2 none swap sw 0 0
/dev/hda3 / ext3 noatime 0 1
none /proc proc defaults 0 0
none /dev/shm tmpfs nodev,nosuid,noexec 0 0
/dev/cdroms/cdrom0 /mnt/cdrom auto noauto,user 0 0
|
auto provoca que mount intente adivinar el sistema de archivos
(se recomienda para los dispositivos extraíbles ya que pueden ser creados con
distintos sistemas de ficheros) y user hace posible a los usuarios que
no pertenezcan a root monten el CD.
Ahora haga uso del ejemplo anterior, para crear su /etc/fstab.
Si es un usuario de SPARC, además debería añadir la siguiente línea a su
/etc/fstab:
Listado de Código 1.6: Añadiendo el sistema de ficheros openprom al /etc/fstab |
none /proc/openprom openpromfs defaults 0 0
|
Si necesita usbfs, Añada la siguiente línea al /etc/fstab:
Listado de Código 1.7: Añadiendo el sistema de ficheros usbfs al /etc/fstab |
none /proc/bus/usb usbfs defaults 0 0
|
Repase su /etc/fstab, guarde los cambios y salga para continuar.
8.b. Información de red
Nombre de Host, Nombre de Dominio, etc.
Una de las elecciones que un usuario ha de hacer es el nombre de su PC. Esto
parece muy fácil, pero muchos usuarios tienen dificultades eligiendo el
nombre apropiado para su PC-Linux. Para acelerar las cosas, sepa que el nombre
que elija puede cambiarlo mas tarde. Para el caso que nos preocupa, usted puede
llamar su sistema simplemente tux y su dominio redcasera.
Usaremos esos nombres en los siguientes ejemplos. Primero ajustaremos el nombre
de host:
Listado de Código 2.1: Ajustando el nombre de Host |
# echo tux > /etc/hostname
|
En segundo lugar ajustaremos el nombre del dominio:
Listado de Código 2.2: Ajustando el nombre de Host |
# echo homenetwork > /etc/dnsdomainname
|
Si dispone de un dominio NIS (si no sabe lo que es, entonces no lo tiene),
necesita definirlo también:
Listado de Código 2.3: Ajustando el nombre del dominio NIS |
# echo nis.homenetwork > /etc/nisdomainname
|
Ahora añada el script domainname al nivel de arranque por defecto:
Listado de Código 2.4: Agregando domainname al nivel de arranque por defecto |
# rc-update add domainname default
|
Configurando su Red
Antes de llegar a experimentar esa sensación "Hey, ya lo tengo todo", debes
recordar que la red que configuraste en el inicio de la instalación de Gentoo
fue tan solo para la instalación. A partir de ahora vamos a configurar la red
permanentemente para su sistema Gentoo.
Toda la información de red esta reunida en /etc/conf.d/net. Este
fichero usa una directa, aunque no intuitiva sintaxis si no se sabe como
configurar una red manualmente. Pero no se asuste, se lo explicaremos todo :)
Primero abra /etc/conf.d/net con su editor favorito (Se usará
nano en este ejemplo):
Listado de Código 2.5: Abriendo /etc/conf.d/net para su edición |
# nano -w /etc/conf.d/net
|
La primera variable que encontrará es iface_eth0. Utilice la siguiente
sintaxis:
Listado de Código 2.6: Sintaxis de la variable iface_eth0 |
iface_eth0="<su dirección ip> broadcast <su dirección broadcast> netmask <su máscara de red>"
|
Si usa DHCP (obtención automática de IP), debe asignar la variable
iface_eth0 a dhcp. No obstante, si necesita configurar su red
manualmente y no está familiarizado con los términos usados, por favor lea la
sección Entendiendo la
terminología de red si no lo ha hecho ya.
Déjenos darle tres ejemplos; el primero usa DHCP, el segundo IP estática
(192.168.0.2) con la máscara de red 255.255.255.0, broadcast 192.168.0.255 y
la pasarela 192.168.0.1, mientras el tercero únicamente activa la interfaz
para utilizar rp-pppoe:
Listado de Código 2.7: Ejemplos de /etc/conf.d/net |
iface_eth0="dhcp"
dhcpcd_eth0="-HD"
dhcpcd_eth0="-N"
iface_eth0="192.168.0.2 broadcast 192.168.0.255 netmask 255.255.255.0"
gateway="eth0/192.168.0.1"
iface_eth0="up"
|
Si posee distintas interfaces de red, cree variables iface_eth adicionales,
como iface_eth1, iface_eth2 etc. La variable gateway
no debe ser redefinida ya que solo puede asignar una pasarela por computadora.
Ahora guarde la configuración y salga para continuar.
Inicio automático de red en el arranque
Para disponer de su interfaz de red activada en el arranque, necesita agregarla
al nivel de ejecución por defecto (default). Si dispone de interfaces PCMCIA
debe saltarse este paso puesto que las interfaces PCMCIA son iniciadas por el
script de inicialización PCMCIA
Listado de Código 2.8: Agregando net.eth0 al nivel de ejecución default |
# rc-update add net.eth0 default
|
Si tiene distintas interfaces de red, necesitara crear los apropiados
net.eth1, net.eth2 etc. scripts de inicio. Puede
usar ln para hacer esto:
Listado de Código 2.9: Creando scripts de inicio adicionales |
# cd /etc/init.d
# ln -s net.eth0 net.eth1
# rc-update add net.eth1 default
|
Anotando la Información de la Red
Necesita informar a Linux sobre su red. Esto se define en
/etc/hosts y ayuda a transformar los nombres de host a
direcciones IP para aquellas máquinas que no se resuelven a través de su
servidor de nombres (DNS). Por ejemplo, si su red interna consiste en tres
PCs llamados jenny (192.168.0.5), benny (192.168.0.6) y
tux (192.168.0.7 - este sistema) abra /etc/hosts y
complete los valores:
Listado de Código 2.10: Abriendo /etc/hosts |
# nano -w /etc/hosts
|
Listado de Código 2.11: Completando la información de red |
127.0.0.1 localhost
192.168.0.5 jenny.redlocal jenny
192.168.0.6 benny.redlocal benny
192.168.0.7 tux.redlocal tux
|
Si su sistema es el único presente (o los servidores de nombres se encargan
de todas las resoluciones) una única línea es suficiente. Por ejemplo, si quiere
llamar a su sistema tux:
Listado de Código 2.12: /etc/hosts para un solo PC o varios plenamente integrados |
127.0.0.1 localhost tux
|
Guarde y salga del editor para continuar.
Si no tiene PCMCIA, puede continuar con Información del Sistema. Los usuarios de PCMCIA
deberían leer el siguiente apartado sobre PCMCIA.
Opcional: Hacer funcionar el PCMCIA
Nota:
pcmcia-cs está solamente disponible para plataformas x86, amd64 y ppc.
|
Los usuarios de PCMCIA deben instalar primero el paquete pcmcia-cs.
Esto también incluye a los usuarios que estén trabajando con un kernel 2.6
(incluso aunque no quieran utilizar los controladores PCMCIA de este paquete).
El empleo de USE="-X" es necesario para evitar la instalación de
xorg-x11 en este momento.
Listado de Código 2.13: Instalando pcmcia-cs |
# USE="-X" emerge pcmcia-cs
|
Cuando pcmcia-cs esté instalado, agregue pcmcia al nivel de
arranque default:
Listado de Código 2.14: Agregando pcmcia al nivel de arranque por defecto |
# rc-update add pcmcia default
|
8.c. Información del sistema
Contraseña de administrador (Root)
Primero fijamos la contraseña de administrador escribiendo:
Listado de Código 3.1: Configurando la contraseña de administrador |
# passwd
|
Si desea que el administrador sea capaz de entrar en el sistema a través de
un consola de serie (tts), añada tts/0 al fichero /etc/securetty:
Listado de Código 3.2: Añadiendo tts/0 a /etc/securetty |
# echo "tts/0" >> /etc/securetty
|
Información del sistema
Gentoo usa el fichero /etc/rc.conf para una configuración general
del sistema. Abra el /etc/rc.conf y disfrute de todos los
comentarios que hay en él :)
Listado de Código 3.3: Abriendo el fichero /etc/rc.conf |
# nano -w /etc/rc.conf
|
Como puede ver, este fichero está bien comentado para ayudarle a ajustar las
variables de configuración necesarias. Tenga especial cuidad con KEYMAP:
si selecciona un KEYMAP incorrecto, conseguirá extraños resultados
escribiendo en su teclado.
Nota:
Los usuarios de sistemas SPARC basados en USB y los clones de SPARC podrían
necesitar seleccionar un mapeo del teclado i386 (como "su") en vez de utilizar
"sunkeymap".
|
PPC utiliza mapeos de teclado x86 en la mayoría de sus sistemas. Los usuarios
que quieren disponer de mapeos ADB en el arranque, necesitan activar "ADB keycode
sendings" en su kernel y tener configurado un mapeo de teclado mac/ppc en
rc.conf.
Cuando haya acabado de configurar el /etc/rc.conf, guarde y salga,
entonces puede continuar con Instalando las
herramientas de sistema necesarias .
9. Installing Necessary System Tools
9.a. Bitácora del Sistema
Cuando mencionamos que era la stage3, dijimos que contenía todas las
herramientas del sistema necesarias para las cuales no podíamos proporcionar
una opción para nuestro usuarios. También dijimos que instalaríamos otras
herramientas mas tarde. Bueno, aquí están :)
La primera herramienta por la que tiene que decidirse es la que proporciona el
registro y las bitácoras para su sistema. Unix y Linux tienen una excelente
historia en sus capacidades de registros -- si lo quisiera podría registrar todo
lo que pasa en su sistema en bitácoras. Esto sucede con el registro del
sistema.
Gentoo ofrece varios sistemas de registro para elegir. Están sysklogd,
que es el conjunto tradicional de demonios de bitácoras, sysklogd, un
sistema de bitácora avanzado, y metalog que es una bitácora de sistemas
altamente configurable. También puede haber otros en el Portage - el número de
paquetes disponbles crece día a día.
Si está pensando utilizar sysklogd o syslog-ng quizá quiera
instalar posteriormente logrotate ya que esos logeadores no
proporcionan ningún mecanismo de rotación para los archivos de log.
Si no puede decidirse, use metalog que además de ser muy poderos, viene
con una gran configuración predeterminada.
Para instalar la bitácora del sistema de su elección, use emerge y agrégelo
al nivel de arrenque predeterminado usando rc-update. El siguiente ejemplo
instala metalog. Desde luego, sustitúyalo por el sistema de bitácora de
su elección:
Listado de Código 1.1: Instalar un sistema de bitácoras |
# emerge metalog
# rc-update add metalog default
|
9.b. Opcional: Demonio Cron
El siguiente es el demonio cron. Aunque es opcional y no lo requiere su sistema
es recomendable instalar uno. ¿Pero que es un demonio cron? Un demonio cron
ejecuta comandos en horarios planificados. Es muy cómodo si necesita ejecutar
comandos regularmente (por ejemplo diario, cada semana o mensualmente).
Gentoo ofrece tres posibles demonios cron: dcron, fcron y
vixie-cron. Instalar cualquiera es similar a instalar un sistema de
bitácoras. Sin embargo dcron y fcron requieren un comando extra
de configuración, que es crontab /etc/crontab. Si no sabe cuál escoger,
use vixie-cron.
Solo poroporcionamos vixie-cron para instalaciones sin red. Si quiere
otro demonio cron puede esperar e instalarlo más tarde.
Listado de Código 2.1: Instalar un demonio cron |
# emerge vixie-cron
# rc-update add vixie-cron default
# crontab /etc/crontab
|
9.c. Opcional: Indexar Archivos
Si quiere crear un índice de su sistema de archivos para habilitar su rápida
localización usando la herramienta locate, necesita instalar
sys-apps/slocate.
Listado de Código 3.1: Instalar slocate |
# emerge slocate
|
9.d. Herramientas del Sistema de Archivos
Dependiendo en que sistema de archivos este usando, necesita instalar las
utilerías necesarias (para verificar la integridad del sistema de archivos,
crear adicionales, etc.).
La siguiente table enlista las herramientas que necesita instalar según un
sistema de archivos determinado:
| Sistema de Archivos |
Herramienta |
Comando para Instalar |
| XFS |
xfsprogs |
emerge xfsprogs |
| ReiserFS |
reiserfsprogs |
emerge reiserfsprogs |
| JFS |
jfsutils |
emerge jfsutils |
Si no necesita ninguna herramienta adicional relacionada con la red (como
rp-pppoe o un cliente dhcp) continue con
Configuración del Cargador de Arranque.
9.e. Herramientas de Red
Opcional: Instalar un Cliente DHCP
Si necesita que Gentoo obtenga automáticamente una dirección IP para sus
interfaces de red, necesita instalar en su sistema dhcpcd (o cualquier
otro cliente DHCP) . Si no lo hace, ¡tal vez no sea capz de conectarse a
Internet después de la instalación!
Listado de Código 5.1: Instalar dhcpcd |
# emerge dhcpcd
|
Opcional: Instalar un Cliente PPPoE
Si necesita rp-pppoe para conectarse a la red, necesita instalarlo.
Listado de Código 5.2: Instalar rp-pppoe |
# USE="-X" emerge rp-pppoe
|
El USE="-X" le prohibe a xorg-x11 instalarse como una dependencia
(rp-pppoe tiene herramientas gráficas; si quiere habilitarlas, puede
recompilar rp-pppoe más tarde o cuando xorg-x11 ya esté instalado --
porque toma mucho tiempo en compilarse).
Ahora continúe con Configurar el Cargado de
Arranque.
10. Configuring the Bootloader
10.a. Installing PALO
On the PA-RISC platform, the boot loader is called palo. You can find
the configuration file in /etc/palo.conf. Here is a sample
configuration:
Listado de Código 1.1: /etc/palo.conf example |
--commandline=2/vmlinux root=/dev/sdb2 HOME=/
--recoverykernel=/vmlinux.old
--init-partitioned=/dev/sdb
|
The first line tells palo the location of the kernel and which boot
parameters it must use. 2/vmlinux means the kernel named /vmlinux
resides on the second partition. Beware, the path to the kernel is
relative to the partition, not to the root of your filesystem.
The second line indicates which recovery kernel to use. If it is your
first install and you do not have a recovery kernel, please comment this
out. The third line indicates on which disk palo will reside.
When configuration is done, just run palo.
Listado de Código 1.2: Applying the PALO configuration |
# palo
|
Now continue with Rebooting the System.
10.b. Rebooting the System
Exit the chrooted environment and unmount all mounted partitions. Then type in
that one magical command you have been waiting for: reboot.
Listado de Código 2.1: Exiting the chroot, unmounting all partitions and rebooting |
# exit
cdimage ~# cd
cdimage ~# umount /mnt/gentoo/boot /mnt/gentoo/proc /mnt/gentoo
cdimage ~# reboot
|
Of course, don't forget to remove the bootable CD, otherwise the CD will be
booted again instead of your new Gentoo system.
Once rebooted in your Gentoo installation, finish up with Finalizing your Gentoo Installation.
11. Finalizing your Gentoo Installation
11.a. Administración del Usuario
Añadir un Usuario para uso cotidiano
Trabajar como root en un sistema Unix/Linux es peligroso y su uso
debería evitarse tanto como sea posible. Es por ello que se recomienda
encarecidamente añadir un usuario para el uso cotidiano del sistema.
Los grupos a los que pertenece el usuario definen que actividades puede
realizar. La siguiente tabla muestra una lista de los grupos más importantes
que podría querer utilizar.
| Grupo |
Descripción |
| audio |
para ser capaz de acceder a los dispositivos de audio |
| cdrom |
para poder acceder directamente a dispositivos ópticos |
| floppy |
para poder acceder directamente a los dispositivos de disquete |
| games |
para poder utilizar los juegos |
| usb |
para poder acceder a los dispositivos USB |
| video |
para acceder al hardware capturador de video y a la aceleración
por hardware
|
| wheel |
para poder utilizar su
|
Por ejemplo, para crear un usuario llamado juan que pertenezca a los
grupos wheel, users y audio, entre en el sistema como
root (sólo root puede crear usuarios) y ejecute useradd:
Listado de Código 1.1: Añadiendo un usuario de uso cotidiano |
Login: root
Password:
# useradd -m -G users,wheel,audio -s /bin/bash juan
# passwd juan
Password:
Re-enter password:
|
Si alguna vez este usuario necesita realizar alguna tarea como root, puede
utilizar su - para obtener temporalmente privilegios de root. Otra
forma es utilizar el paquete sudo el cual, correctamente configurado,
es muy seguro.
11.b. Opcional: Instalar Paquetes PRG
Importante:
Esta parte es solo para los usuarios de PRG. El resto deberían saltarse esta
parte y continuar con ¿A dónde ir
desde aquí?.
|
Ahora que su sistema está iniciado, entre con el usuario que creó
anteriormente (por ejemplo, juan) y utilice su - para
obtener privilegios de root:
Listado de Código 2.1: Obteniendo privilegios de root |
$ su -
Password:
|
Ahora necesitamos cambiar la configuración de Portage para buscar
los binarios pre-compilados del segundo CD (CD de Paquetes de Gentoo).
Primero monte éste CD:
Listado de Código 2.2: Monte el CD de Paquetes |
# mount /mnt/cdrom
|
Ahora configure Portage para usar /mnt/cdrom para sus paquetes
pre-compilados:
Listado de Código 2.3: Configurando Portage para usar /mnt/cdrom |
# ls /mnt/cdrom
# export PKGDIR="/mnt/cdrom/packages"
# export PKGDIR="/mnt/cdrom"
|
Ahora instale los paquetes que quiera. El CD de Paquetes contiene varios
binarios pre-compilados, como por ejemplo KDE:
Listado de Código 2.4: Instalando KDE |
# emerge --usepkg kde
|
Asegúrese de instalar los binarios ahora. Cuando haga un emerge --sync
para actualizar Portage (como aprenderá más adelante), los binarios
pre-compilados quizá no correspondan con los ebuilds de su Portage actualizado.
Puede tratar de solventar este problema utilizando emerge --usepkgonly
en lugar de emerge --usepkg.
Enhorabuena, ¡Su sistema está ahora completamente equipado! Continué con ¿A dónde ir desde aquí? para aprender algo
más sobre Gentoo.
12. Where to go from here?
12.a. Documentación
¡Enhorabuena! Ya tiene funcionando un sistema Gentoo. Pero ¿A donde ir desde
aquí? ¿Cuáles son ahora sus opciones? ¿Qué explorar primero? Gentoo ofrece a sus
usuarios muchas posibilidades y, por lo tanto, muchas características documentadas
(y menos documentadas).
Definitivamente usted debería ojear la siguiente parte del Manual de Gentoo
titulada Trabajando con Gentoo la cual
explica cómo mantener su software al día, cómo instalar más software, qué
parámetros USE hay, cómo funciona el sistema de inicialización de Gentoo
(Gentoo Init system), etc.
Si está interesado en la optimización de su sistema para uso de escritorio, o quiere
aprender cómo configurarlo para que sea un completo sistema de escritorio,
consulte nuestra extensa Guía de
Configuración del Escritorio.
También disponemos de un documento extenso sobre seguridad, llamado
Guía de seguridad de Gentoo
Linux Gentoo Security el cual es conveniente leer.
Para obtener un completo listado de toda nuestra documentación disponible,
revise nuestra página de Recursos de
Documentación.
12.b. Gentoo en línea
Por supuesto, usted es siempre bienvenido a nuestros Foros de Gentoo o a alguno de nuestros
canales de IRC.
También tenemos varias listas de correo
abiertas para todos nuestros usuarios. La información de cómo entrar en las
mismas está disponible en esa página.
Ahora nos callaremos y le dejaremos que disfrute de su instalación :)
12.c. Cambios en Gentoo desde 2004.3
¿Cambios?
Gentoo está en continuo movimiento. Las siguientes secciones describen
importantes cambios que afectan a la instalación de Gentoo. Solamente
se recogen aquellos comunes a la instalación, no los cambios de paquetes
que no ocurren durante la instalación.
Los siguientes cambios necesitan aplicarse justo después de actualizar su
sistema (y antes de reiniciarlo).
Hotplug y Coldplug
La funcionalidad hotplug, empleada por los usuarios de
genkernel, ha sido dividida en dos paquetes: coldplug y
hotplug. Los usuarios de hotplug necesitan instalar también
coldplug , quitar hotplug del nivel de ejecución
predeterminado y reemplazarlo por coldplug:
Listado de Código 3.1: Cambios en Coldplug/Hotplug |
# emerge coldplug
# rc-update del hotplug default
# rc-update add coldplug default
|
Para más información , por favor lea el Anuncio de cambio en Hotplug.
Arboles de Kernel eliminados
Con el objetivo de mantener nuestros paquetes de kernel manejables, hemos
eliminado algunos paquetes que no disponían de mantenimiento del árbol.
Toda la información sobre los cambios está disponible en el Anuncio de cambio de Kernel.
B. Working with Gentoo
1. A Portage Introduction
1.a. Bienvenido a Portage
Portage es probablemente la más importante innovación de Gentoo en la
gestión de software. Con su gran flexibilidad y una gran cantidad de
características es frecuentemente apreciado como la mejor herramienta de
gestión de software disponible para Linux.
Portage esta completamente escrito en
Python y
Bash y, por tanto,
completamente a la vista de los usuarios al ser ambos lenguajes de script.
La mayoría de usuarios trabajarán con Portage a través de la herramienta
emerge. Este capítulo no pretende duplicar la información disponible
en la página de man sobre emerge. Para una completa información sobre
las opciones de emerge, por favor, consulte la página del manual:
Listado de Código 1.1: Leyendo la página del manual sobre emerge |
$ man emerge
|
1.b. El Árbol Portage
Ebuilds
Cuando hablamos sobre paquetes, nos referimos normalmente a programas
software disponible para los usuarios de Gentoo a través del árbol Portage.
El árbol Portage es una colección de ebuilds, archivos que contienen
toda la información que Portage necesita para mantener el software
(instalar, buscar, ...). Estos ebuilds residen por defecto en
/usr/portage.
Cuando le pida a Portage que ejecute alguna acción relacionada con los
programas software, éste utilizará los ebuilds de su sistema como base. Por
tanto, es importante que actualice los ebuilds de su sistema para que Portage
conozca el nuevo software, actualizaciones de seguridad, etc.
Actualizando el árbol Portage
El árbol Portage se actualiza normalmente con rsync, una utilidad rápida de
transferencia de archivos incremental. La actualización es muy sencilla, ya que
el comando emerge proporciona una interfaz para rsync:
Listado de Código 2.1: Actualizando el árbol Portage |
# emerge --sync
|
Si no es capaz de realizar rsync debido a restricciones de cortafuegos puede
actualizar su árbol Portage a través de nuestras tres imágenes de Portage
generadas diariamente. La herramienta emerge-webrsync
automáticamente comprueba e instala la última en su sistema.
Listado de Código 2.2: Ejecutando emerge-webrsync |
# emerge-webrsync
|
1.c. Mantenimiento de Software
Buscando software
Para buscar software utilizando el árbol de Portage , puede utilizar
las características de búsquedas propias de emerge. Por defecto,
emerge search devuelve el nombre de los paquetes cuyo nombre
coincide (tanto total como parcialmente) con el término de búsqueda
introducido.
Por ejemplo, para buscar todos los paquetes que tengan "pdf" en su nombre:
Listado de Código 3.1: Buscando paquetes cuyo nombre tenga pdf |
$ emerge search pdf
|
Si quiere buscar también en las descripciones puede utilizar el
parámetro --searchdesc (o -S).
Listado de Código 3.2: Buscando paquetes relacionados con pdf |
$ emerge --searchdesc pdf
|
Cuando eche un vistazo al resultado, notará que le proporciona mucha
información. Los campos son etiquetados claramente con lo cual
no entraremos en explicar sus significados.
Listado de Código 3.3: Ejemplo de salida 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
|
Instalando Software
Una vez que haya encontrado el nombre del software que necesite, puede
fácilmente instalarlo con emerge: simplemente añada el nombre
del paquete. Por ejemplo, para instalar gnumeric:
Listado de Código 3.4: Instalando gnumeric |
# emerge gnumeric
|
Muchas aplicaciones depende unas de otras, esto implica que cualquier intento
de instalar un cierto paquete de software podría derivar en la instalación de
varias dependencias. No se preocupe. Portage maneja también las dependencias.
Si quiere conocer que instalará Portage cuando le pida que instale un
cierto paquete, añada el parámetro --pretend. Por ejemplo:
Listado de Código 3.5: Simulando instalar gnumeric |
# emerge --pretend gnumeric
|
Cuando le pida a Portage que instale un paquete, descargará las fuentes
necesarias desde Internet (si fuera necesario) y las guardará por defecto
en /usr/portage/distfiles. Después de esto, el paquete será
descomprimido, compilado e instalado. Si quiere que portage únicamente
descargue las fuentes sin instalarlas, añada la opción --fetchonly al
comando emerge:
Listado de Código 3.6: Descargar el código fuente de gnumeric |
# emerge --fetchonly gnumeric
|
Desinstalando Software
Cuando quiera desinstalar un paquete software de su sistema, utilice
emerge unmerge. Esto le indicará a Portage que desinstale
todos los archivos instalados por el paquete en su sistema excepto
los archivos de configuración de esa aplicación si la había modificado
después de la instalación. Esto le permite continuar trabajando con
los mismo archivos de configuración si alguna vez decide volver a
instalar la aplicación.
Sin embargo, hemos de tener algo muy en cuenta: Portage
no comprueba si el paquete que está intentando desinstalar es necesario
para algún otro. A pesar de esto, le avisará cuando quiera eliminar un paquete
importante que pueda romper su sistema si lo desinstala.
Listado de Código 3.7: Desinstalando gnumeric del sistema |
# emerge unmerge gnumeric
|
Cuando desinstala un paquete de su sistema, las dependencias de ese paquete
que se instalaron automáticamente cuando instaló el software, permanecerán.
Para hacer que Portage localice todas las dependencias que puede ser
eliminadas actualmente, utilice la utilidad de emerge depclean.
Hablaremos de esto un poco más adelante.
Actualizando su Sistema
Para mantener su sistema en perfecto estado (sin mencionar la instalación
de los últimas actualizaciones de seguridad) necesita actualizarlo
frecuentemente. Partiendo de que Portage solamente comprueba los ebuilds
en su árbol Portage, lo primero sería actualizar el propio árbol. Cuando tenga
el árbol Portage actualizado, puede actualizar su sistema con
emerge --update world:
Listado de Código 3.8: Actualizando su sistema |
# emerge --update world
|
Portage buscará entonces las nuevas versiones de las aplicaciones que tenga
instaladas. Sin embargo, solamente comprobará las versiones de las
aplicaciones que tenga instaladas, no de las dependencias. Si quiere actualizar
cada paquete existente en su sistema, añada la opción --deep:
Listado de Código 3.9: Actualizando completamente su sistema |
# emerge --update --deep world
|
Si ha cambiado últimamente alguno de sus
parámetros USE quizá quiera
añadir también --newuse. Portage comprobará si los cambios
requieren la instalación de nuevos paquetes o la recompilación de los
existentes:
Listado de Código 3.10: Llevando a cabo una actualización completa |
# emerge --update --deep --newuse world
|
Paquetes colectivos
Algunos paquetes del árbol Portage no tienen contenido real pero son
utilizados para instalar un conjunto de paquetes. Por ejemplo, el paquete
kde dejará un completo entorno KDE en su sistema a través de
instalar varios paquetes relacionados con KDE y sus dependencias.
Si quiere desinstalar dicho paquete de su sistema, ejecutando emerge
unmerge sobre el paquete no tendrá efecto total ya que las dependencias
permanecerán en su sistema.
Portage tiene la funcionalidad de eliminar las dependencias huérfanas, pero
la disponibilidad de software necesita que primero actualice completamente
su sistema, incluyendo los nuevos cambios que ha aplicado si actualizó
los parámetros USE. Después de esto, puede ejecutar emerge depclean
para eliminar las dependencias huérfanas. Cuando haya terminado, necesitará
reconstruir las aplicaciones que estuvieran enlazadas dinámicamente a las que
acaban de ser eliminadas pero no son necesarias.
Todo esto se lleva a cabo a través de tres comandos:
Listado de Código 3.11: Desinstalando dependencias huérfanas |
# emerge --update --deep --newuse world
# emerge depclean
# revdep-rebuild
|
revdep-rebuild es parte del paquete gentoolkit; no olvide
instalarlo primero:
Listado de Código 3.12: Instalando el paquete gentoolkit |
# emerge gentoolkit
|
1.d. Cuando Portage se queja...
Sobre SLOTs, Paquetes Virtuales, Ramas, Arquitecturas y Perfiles
Como mencionamos anteriormente, Portage es muy potente y soporta muchas
características que de las que carecen otros herramientas de gestión de
software. Para comprender esto, explicaremos unos cuantos aspectos de
Portage sin profundizar demasiado en los detalles.
Con Portage diferentes versiones de un mismo paquete pueden coexistir en
un sistema. Mientras otras distribuciones tienden a renombre el paquete con
sus versiones (por ejemplo freetype and freetype2). Portage
usa una tecnología llamada SLOTs (ranuras). Un ebuild declara un
cierto SLOT para su versión. Ebuilds con diferentes SLOTs pueden coexistir
en el mismo sistema. Por ejemplo, el paquete freetype tiene ebuilds
con SLOT="1" y SLOT="2".
También existen paquetes que proporcionan la misma funcionalidad pero están
implementados de maneras distintas. Por ejemplo, metalogd, sysklogd
y syslog-ng son todos logeadores del sistema. Aplicaciones que necesitan
la disponibilidad de un "logeador del sistema" no pueden depender, por ejemplo, de
metalogd, ya que el resto de logeadores del sistema son igualmente
válidos. Portage permite virtuals: cada logeador del sistema proporciona
virtual/syslog de tal manera que las aplicaciones puede depender de
virtual/syslog.
Los programas en el árbol Portage puede residir en diferentes ramas. Por defecto,
su sistema solamente acepta paquetes que Gentoo considera estables. La
mayoría de los paquetes nuevos, cuando son aceptados, ingresan en la rama
inestable. Esto implica que necesitan hacerse más pruebas antes de marcarlo
como estable. Aunque puede ver los ebuilds de ese software en su árbol de
Portage, Portage no los actualizará hasta que sean marcados como estables.
Algunos programas sólo están disponibles para unas pocas arquitecturas. O los
programas no funcionan en otras arquitecturas, o necesitan más pruebas, o el
desarrollador que añade el programa a Portage no es capaz de verificar si el
paquete funciona en diferentes arquitecturas.
Cada instalación de Gentoo adhiere un cierto perfil el cual contiene, entre
otra información, la lista de paquetes necesarios para que el sistema
funcione normalmente.
Paquetes Bloqueados
Listado de Código 4.1: Portage avisa sobre paquete bloqueados (con --pretend) |
[blocks B ] gnome-base/bonobo-activation (from pkg gnome-base/libbonobo-2.4.0)
|
Listado de Código 4.2: Portage avisa sobre paquete bloqueados (sin --pretend) |
!!! Error: the gnome-base/bonobo-activation package conflicts with another package.
!!! both can't be installed on the same system together.
!!! Please use 'emerge --pretend' to determine blockers.
|
Los Ebuilds contienen campos específicos que informan a Portage sobre sus
dependencias. Hay dos posibles dependencias: dependencias de compilación,
declaradas en DEPEND y dependencias en tiempo de ejecución,
declaradas en RDEPEND. Cuando una de estas dependencias
marca explícitamente un paquete o paquete virtual como no compatible,
se dispara un bloqueo.
Para solucionar un bloqueo, puede elegir no instalar el paquete o desinstalar
primero el paquete conflictivo. En el ejemplo anterior, puedes optar por no
instalar libbonobo o eliminar primero bonobo-activation.
Paquetes enmascarados (masked)
Listado de Código 4.3: Portage avisa sobre paquetes enmascarados |
!!! all ebuilds that could satisfy "bootsplash" have been masked.
|
Listado de Código 4.4: Portage avisa sobre paquetes enmascarados - razón |
!!! 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)
|
Cuando quiera instalar un paquete que no está disponible para su sistema,
recibirá un error de enmascaramiento. Debería probar a instalar una aplicación
distinta que este disponible para su sistema o esperar hasta que el paquete
este disponible. Siempre hay una razón para que un paquete esté enmascarado.
-
~arch keyword implica que la aplicación no esta probada lo
suficiente para ser parte de la rama estable. Espere unos cuantos días
o semanas y vuelva a intentarlo.
-
-arch keyword o -* keyword implica que la aplicación
no funciona en su arquitectura. Si cree que el paquete funcionará, cree
un bug en nuestro sitio web
bugzilla.
-
missing keyword implica que la aplicación aún no ha sido probada
en su arquitectura. Pida al equipo encargado de portar arquitecturas que
pruebe el paquete o pruébelo por ellos y informe de su experiencia en
nuestro sitio web bugzilla.
-
package.mask implica que el paquete se ha encontrado corrupto,
inestable o peor y ha sido marcada deliberadamente para que no se use.
-
profile implica que el paquete no está disponible para su perfil.
La aplicación podría romper su sistema si la instala o no es compatible
con el perfil que está usando.
Dependencias perdidas
Listado de Código 4.5: Portage avisa sobre dependencias perdidas |
emerge: there are no ebuilds to satisfy ">=sys-devel/gcc-4.2-r4".
!!! Problem with ebuild sys-devel/gcc-3.4.2-r2
!!! Possibly a DEPEND/*DEPEND problem.
|
La aplicación que está tratando instalar depende de otro paquete que no
esta disponible para su sistema. Por favor, compruebe bugzilla para ver si el problema
se conoce o no, en este caso informe de ello. A menos que este mezclando
ramas esto no debería ocurrir y lo consideraremos un error.
Nombre ambiguo del Ebuild
Listado de Código 4.6: Portage avisa sobre nombre ambiguos en ebuild |
!!! The short ebuild name "aterm" is ambiguous. Please specify
!!! one of the following fully-qualified ebuild names instead:
dev-libs/aterm
x11-terms/aterm
|
La aplicación que quiere instalar tiene un nombre que corresponde con más de
un paquete. Necesita aportar también el nombre de la categoría. Portage le
informará de los posibles casos entre los que puede elegir.
Dependencias Circulares
Listado de Código 4.7: Portage avisa sobre dependencias 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
|
Dos (o más) paquetes que quiere instalar dependen uno de otro y, por tanto,
no pueden instalarse. Esto casi siempre se considera un error en el árbol
Portage. Por favor, vuelva a sincronizar después de un tiempo e inténtelo de
nuevo. También puede comprobar bugzilla para saber si se tiene
conocimiento sobre el tema o si no, en cuyo caso informe sobre ello.
Fallo en la descarga
Listado de Código 4.8: Portage avisa sobre un fallo en la descarga |
!!! Fetch failed for sys-libs/ncurses-5.4-r5, continuing...
!!! Some fetch errors were encountered. Please see above for details.
|
Portage no es capaz de descargar las fuentes para una aplicación específica y
tratará de continuar instalando el resto de aplicaciones (si es posible). Este
fallo puede deberse a que un servidor réplica no esta bien sincronizado o a que
el ebuild apunta a una localización incorrecta. El servidor donde reside las
fuentes podría estar caído por alguna razón.
Pruebe después de una hora y vea si el problema persiste.
Protección del Pérfil de Sistema
Listado de Código 4.9: Portage avisa sobre un paquete protegido por perfil |
!!! Trying to unmerge package(s) in system profile. 'sys-apps/portage'
!!! This could be damaging to your system.
|
Está intentando eliminar un paquete que es parte del fundamental de su sistema.
Éste se haya en su perfil y es necesario y, por tanto, no debería ser eliminado
del sistema.
2. USE flags
2.a. ¿Qué son los parámetros USE?
Las ideas que hay detrás de los parámetros USE
Mientras esté instalando Gentoo (o cualquier otra distribución, incluso
otro sistema operativo), tomará varias decisiones dependiendo del entorno en el
que esté trabajando. Una instalación para un servidor es distinta a
una para una estación de trabajo. También una estación de trabajo dedicada a
juegos es diferente a una estación de trabajo que se use para renderizados
en 3D.
Estas diferencias no solo dependen de los paquetes instalados, si no también
de las características para las que ciertos paquetes tienen soporte. Si no
necesita OpenGL, ¿para qué molestarse en instalar OpenGL y construir la
mayoría de sus aplicaciones con soporte OpenGL? Si no quiere usar KDE, ¿para
qué molestarte en compilar paquetes con soporte para KDE si podrían funcionar
perfectamente sin él?
Para ayudar a los usuarios a decidir qué instalar/activar o no, necesitamos
que el usuario especifique su entorno de una manera sencilla. Esto obliga al
usuario a decidir que es lo que realmente quiere; además de facilitar a Portage,
nuestro sistema de gestión de paquetes, la tarea de tomar decisiones útiles.
Definición de un parámetro USE
Comencemos por definir qué son los parámetros USE. Un parámetro USE es una
palabra clave que incorpora información de soporte y dependencias para
un concepto en concreto. Si define un determinado parámetro USE, Portage
sabrá que el usuario desea soporte para la palabra clave escogida. Por supuesto,
también altera las dependencias de un paquete.
Veamos un ejemplo específico: la palabra clave kde. Si no la tiene
en su variable USE, todos los paquetes que tengan soporte opcional
para KDE se construirán sin él. Los que tengan una dependencia opcional
con KDE se instalarán sin instalar las librerías de KDE (como dependencia).
Si ha definido la palabra clave kde, entonces dichos paquetes sí se
construirán con soporte para KDE, y las librería de KDE serán instaladas
Definiendo correctamente las palabras clave, conseguirá un sistema
confeccionado específicamente para sus necesidades.
¿Qué parámetros USE existen?
Hay dos tipos de parámetros USE: globales y locales.
-
Un parámetro USE global lo usan varios paquetes, en todo
el sistema. Es lo que la mayoría de la gente entiende como parámetros USE.
-
Un parámetro USE local lo utiliza un sólo paquete para tomar
decisiones específicas para dicho paquete.
Puede encontrar una lista de los parámetros USE globales en línea o localmente en
/usr/portage/profiles/use.desc. Un pequeño (realmente pequeño)
extracto:
Listado de Código 1.1: Un pequeño extracto de los parámetros USE disposibles |
gtk - Adds support for x11-libs/gtk+ (The GIMP Toolkit)
gtk2 - Use gtk+-2.0.0 over gtk+-1.2 in cases where a program supports both.
gtkhtml - Adds support for gnome-extra/gtkhtml
guile - Adds support for dev-util/guile (interpreter for Scheme)
icc - Use the Intel C++ Compiler if the package supports it
icc-pgo - Enable PGO data generation or use when use icc.
imap - Adds support for IMAP
|
Se puede encontrar una lista de los parámetros USE locales
en /usr/portage/profiles/use.local.desc.
2.b. Usando los parámetros USE
Declarar parámetros USE permanentes
Esperamos que se haya convencido de la importancia de los parámetros USE.
Ahora pasaremos a explicar como se declaran estos parámetros.
Como ya se ha dicho anteriormente, todos los parámetros del USE
se declaran dentro de la variable USE. Para simplificar al usuario
la tarea de buscar y escoger parámetros USE, ya proporcionamos
una configuración predeterminada. Esta configuración es un compendio
de parámetros que creemos se utilizan frecuentemente por los usuarios de Gentoo.
Dicha configuración predeterminada se declara en los ficheros
make.defaults que forman parte de su perfil. Echémosle un vistazo
a la configuración predeterminada:
Listado de Código 2.1: La variable USE /usr/portage/profiles/default-linux/x86/2004.3/make.defaults |
USE="x86 oss apm arts avi berkdb crypt cups encode foomaticdb gdbm gif gpm
gtk gtk2 imlib jpeg kde gnome libg++ libwww mad mikmod motif mpeg ncurses
nls oggvorbis opengl pam pdflib png python qt quicktime readline sdl
slang spell ssl svga tcpd truetype X xml2 xmms xv zlib"
|
Como puede ver, esta variable contiene bastantes palabras clave. No
modifique el fichero make.defaults
para ajustar la variable USE a sus necesidades: ¡los cambios se perderán
al actualizar el árbol del Portage!
Para modificar esta configuración predeterminada, necesita añadir o eliminar
palabras clave a la variable USE. Para llevarlo a cabo, se define
la variable USE en /etc/make.conf. En esta variable añada
los parámetros USE que necesite o elimine los que no quiera. Para eliminarlos
coloque el símbolo menos ("-") delante.
Por ejemplo, para eliminar el soporte para KDE y QT además de añadir
soporte para ldap, puede definirse el siguiente parámetro USE en
/etc/make.conf:
Listado de Código 2.2: Un ejemplo de confirmación USE en /etc/make.conf |
USE="-kde -qt ldap"
|
Declarar parámetros USE para paquetes específicos
A veces le interesará establecer un cierto parámetro USE tan sólo para una o
dos aplicaciones, pero no para todo el sistema. Para solventar esto, necesitará
crear el directorio /etc/portage (si no existiera) y editar
/etc/portage/package.use.
Por ejemplo, si no le interesa soporte global para berkdb pero lo quiere
para mysql, necesita añadir:
Listado de Código 2.3: Ejemplo de /etc/portage/package.use |
dev-db/mysql berkdb
|
Por supuesto también puede desactivar el empleo específico de
un parámetro USE para una aplicación en concreto.
Por ejemplo si no quiere soporte para java en PHP:
Listado de Código 2.4: Segundo ejemplo de /etc/portage/package.use |
dev-php/php -java
|
Declarar parámetros USE temporales
A veces necesitará utilizar una cierta configuración de USE tan sólo una vez.
En lugar de editar /etc/make.conf dos veces (una para hacer y
otra para deshacer los cambios) puede declarar la variable USE como una
variable de entorno. Recuerde que, si utiliza este método, cuando vuelva a
emerger o actualice este aplicación (tanto si es particular como si forma
parte de una actualización del sistema) perderá los cambios.
Como ejemplo, vamos a eliminar temporalmente el parámetro java USE
durante la instalación de mozilla.
Listado de Código 2.5: Utilizando USE como una variable de entorno |
# USE="-java" emerge mozilla
|
Heredando parámetros USE
Algunos paquetes no sólo tienen en cuenta los parámetros USE, si no que
además las proporcionan. Cuando instale alguno de esos paquetes, los
parámetros USE proporcionados se añadirán a su configuración. Para ver una lista
de los paquetes que proporcionan parámetros USE, revise
/etc/make.profile/use.defaults:
Listado de Código 2.6: Un extracto 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
|
Precedencia
Por supuesto, hay una determinada precedencia respecto a qué configuración
tiene prioridad sobre la configuración del USE. No es necesario declarar
USE="-java" sólo para ver si java está declarado.
La precedencia para la configuración del USE es (el primero tiene la
mínima prioridad):
-
Configuración predeterminada del USE declarada en los archivos
make.defaults de su perfil de su perfil.
-
Configuración del USE heredada si un paquete de
/etc/make.profile/use.defaults está instalado
-
Configuración definida por el usuario en /etc/make.conf
-
Configuración definida por el usuario en /etc/portage/package.use
-
Configuración definida por el usuario como variable de entorno
Para observar el valor final del USE tal y como lo verá Portage, ejecute
emerge info. Se listarán una serie de variables importantes (incluyendo
la variable USE) con sus valores correspondientes.
Listado de Código 2.7: Ejecutando emerge info |
# emerge info
|
Adaptando su Sistema Completamente a los Nuevos Parámetros USE
Si ha cambiado sus parámetros USE y desea actualizar todo su sistema para
que utilice el nuevo parámetro, utilice la opción de emerge llamada
--newuse:
Listado de Código 2.8: Recompilando todo su sistema |
# emerge --update --deep --newuse world
|
A continuación, ejecute una limpieza completa de Portage para eliminar las
dependencias que habían sido instaladas en su "antiguo" sistema pero que
han quedado obsoletas por los nuevos parámetros de USE.
Aviso:
Ejecutar emerge depclean es una operación peligrosa y debería tratarse
con cuidado. Revise en profundidad la lista de paquetes "obsoletos" y asegúrese
de que no elimina ningún paquete que necesite. En el siguiente ejemplo hemos
añadido -p para mostrar la lista de paquetes que serían eliminados
pero sin eliminarlos físicamente.
|
Listado de Código 2.9: Desinstalando los paquetes obsoletos |
# emerge -p depclean
|
Cuando haya finalizado la limpieza, ejecute revdep-rebuild para
recompilar las aplicaciones que están enlazadas dinámicamente con los
objetos que proporcionaban los paquetes eliminados. revdep-rebuild
forma parte del paquete gentoolkit; no olvide emergerlo primero.
Listado de Código 2.10: Ejecutando revdep-rebuild |
# revdep-rebuild
|
Cuando todo esto haya terminado, su sistema estará utilizando la nueva
configuración de los parámetros USE.
2.c. Parámetros USE específicos de un paquete
Viendo los parámetros USE disponibles
Veamos el ejemplo de mozilla: ¿Qué parámetros USE influyen sobre él?
Para averiguarlo, usamos emerge con las opciones --pretend
(simula llevar a cabo la acción) y --verbose (obtener una salida más
detallada):
Listado de Código 3.1: Viendo los parámetros USE usados |
# emerge --pretend --verbose mozilla
These are the packages that I would merge, in order:
Calculating dependencies ...done!
[ebuild N ] net-www/mozilla-1.5-r1 +java +crypt -ipv6 -gtk2 +ssl +ldap
+gnome -debug +mozcalendar -mozaccess -mozxmlterm -moznoirc -moznomail
-moznocompose -moznoxft
|
emerge no es la única herramienta disponible para esta labor.
De hecho, tenemos una herramienta llamada etcat
dedicada a obtener información sobre los paquetes; la cual se encuentra
en el paquete gentoolkit. En primer lugar, instale gentoolkit:
Listado de Código 3.2: Instalando gentoolkit |
# emerge gentoolkit
|
Ahora ejecute etcat con el argumento uses para ver los parámetros del
USE de un paquete en concreto. Por ejemplo, en el caso del paquete gnumeric:
Listado de Código 3.3: Usando etcat para ver los parámetros USE usados |
# etcat uses gnumeric
[ Colour Code : set ]
[ 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 ]
- - : Adds GNU Data Access (CORBA wrapper) support for gnumeric
- - : unknown
+ + python : Adds support/bindings for the Python language
+ + bonobo : Adds support for gnome-base/bonobo (Gnome CORBA interfaces)
|
3. Portage Features
3.a. Características del Portage
Portage tiene varias características adicionales que hacen de su experiencia
con Gentoo algo mucho mejor. Muchas de estas características residen en
ciertas herramientas software que mejoran el rendimiento, la estabilidad, la
seguridad, ...
Para activar o desactivar ciertas características de Portage necesita editar
la variable FEATURES del archivo /etc/make.conf.
En algunos casos necesita además instalar la herramienta que implementa
la característica.
No todas las características que soporta Portage están aquí reflejadas.
Para una consulta completa por favor revise la página de la ayuda referente
a make.conf
Listado de Código 1.1: Consultando la página de ayuda sobre make.conf |
$ man make.conf
|
Para conocer que características están siendo utilizadas por defecto, ejecute
emerge info y busque la variable FEATURES o utilice grep:
Listado de Código 1.2: Conociendo que características están configuradas |
$ emerge info | grep FEATURES
|
3.b. Compilación Distribuida
Usando distcc
distcc es un programa para distribuir un trabajo de compilación a través
de muchas, no necesariamente idénticas, máquinas en una red. Los clientes de
distcc envían toda la información necesaria a los servidores DistCC
disponibles (corriendo distccd) así pueden compilar trozos de código
fuente para el cliente. El resultado final, es un tiempo de compilación más
rápido.
Puede encontrar información mas detallada sobre distcc (e información de
como tenerlo funcionando sobre Gentoo) en nuestra Documentación Gentoo de Distcc.
Instalando distcc
Distcc se distribuye con un monitor gráfico para monitorizar las tareas que su
computador está enviando para compilar. Si usa Gnome entonces ponga 'gnome' en
su configuración USE. De todas formas, si no usa Gnome pero sigue
deseando disponer de un monitor, entonces debería poner 'gtk' en su
configuración USE.
Listado de Código 2.1: Instalando distcc |
# emerge distcc
|
Activando el soporte en el Portage
Añada distcc a la variable FEATURES dentro de
/etc/make.conf. Hecho esto, edite la variable MAKEOPTS
a sus necesidades. Una pauta conocida para configurarla es poner -jX con
X representando el número de CPUs que ejecutan distccd
(incluyendo el host local) más uno, pero quizá obtenga mejores resultados
con otros números.
Ahora ejecute distcc-config y cree una lista de los servidores distcc
disponibles. Para un ejemplo simple, supondremos que los servidores DistCC son
192.168.1.102 (el host local), 192.168.1.103 y 192.168.1.104
(los dos hosts "remotos"):
Listado de Código 2.2: Configurando distcc para usar los tres servidores DistCC disponibles |
# distcc-config --set-hosts "192.168.1.102 192.168.1.103 192.168.1.104"
|
Por supuesto, no se olvide de ejecutar también el demonio distccd:
Listado de Código 2.3: Arrancando el demonio distcc |
# rc-update add distccd default
# /etc/init.d/distccd start
|
3.c. Compilación utiliizando caché
A cerca de ccache
ccache es un caché de compilación rápida. Cuando compila un programa,
puede cachear resultados intermedios, de forma que, si usted recompilara el
mismo programa, el tiempo de compilación se reduciría ampliamente. En las
aplicaciones comunes, esto puede significar un aumento de velocidad entre 5 y
10 veces.
Si esta interesado en los pros y contras de ccache, por favor visite la
página web de ccache.
Instalando ccache
Para instalar ccache, ejecute emerge ccache:
Listado de Código 3.1: Instalando ccache |
# emerge ccache
|
Activando el Soporte en el Portage
Primero, edite el /etc/make.conf y añada a la variable
FEATURES la palabra clave ccache. A continuación,
añada una nueva variable llamada CCACHE_SIZE y dele el valor de "2G":
Listado de Código 3.2: Editando CCACHE_SIZE en /etc/make.conf |
CCACHE_SIZE="2G"
|
Para comprobar si ccache funciona, pídale a ccache que te muestre
las estadísticas:
Listado de Código 3.3: Viendo las estadísticas de ccache |
# ccache -s
|
Utilizando ccache para compilaciones de C sin relación con Portage
Si quiere utilizar ccache para compilaciones que no tengan que ver con Portage,
añada /usr/lib/ccache/bin al principio de su variable PATH
(antes de /usr/bin). Esto puede llevarse a cabo editando
/etc/profile:
Listado de Código 3.4: Editando /etc/profile |
PATH="/usr/lib/ccache/bin:${PATH}"
|
3.d. Soporte para Paquetes Binarios
Creando paquetes binarios
Portage soporta la instalación de paquetes precompilados. A pesar de que
Gentoo no proporciona paquetes precompilados por sí mismo (excepto para
las imágenes GRP) Portage puede estar funcionando perfectamente con paquetes
precompilados.
Para crear un paquete precompilado puede utilizar quickpkg si el paquete
está instado en su sistema, o emerge con las opciones --buildpkg o
--buildpkgonly.
Si quiere que Portage cree paquetes precompilados de cada paquete individual
que instale, añada buildpkg a la variable FEATURES.
Puede encontrar mayor soporte para la creación de conjuntos de paquetes
precompilados concatalyst. Para más información sobre catalyst, por
favor lea Manual de Referencia
de Catalyst y la
Guía de Catalyst (en inglés ambos documentos).
Instalando Paquetes Precompilados
A pesar de que Gentoo no proporciona uno, puede crear un repositorio central
donde almacene paquetes precompilados. Si quiere utilizar este repositorio,
necesita que Portage lo conozca a través de la variable PORTAGE_BINHOST
que debe apuntar al repositorio. Por ejemplo, si los paquetes precompilados
están en ftp://buildhost/gentoo:
Listado de Código 4.1: Configurando PORTAGE_BINHOST en /etc/make.conf |
PORTAGE_BINHOST="ftp://buildhost/gentoo"
|
Cuando quiera instalar un paquete precompilado, añada la opción
--getbinpkg al comando emerge junto a la opción --usepkg.
La primera le indica a emerge que descargue el paquete precompilado
del servidor definido previamente, mientras que el segundo indica a emerge
que intente instalar el paquete precompilado antes de buscar el código fuente
y compilarlo.
Por ejemplo, para instalar gnumeric a través de paquetes precompilados:
Listado de Código 4.2: Instalando el paquete precompilado gnumeric |
# emerge --usepkg --getbinpkg gnumeric
|
Más información sobre las opciones para utilizar paquetes precompilados con
emerge puede consultarse en la página de la ayuda:
Listado de Código 4.3: Leyendo la página de ayuda sobre emerge |
$ man emerge
|
4. Initscripts
4.a. Niveles de ejecución
Iniciando su sistema
Al iniciar, notará que pasará al frente suyo una gran cantidad de
texto. Si pone atención, notará que estos textos son iguales cada vez
que reinicie su sistema. La secuencia de todas estas acciones se llama
la secuencia de inicio y es (más o menos) definido
estáticamente.
Primero, su gestor de arranque cargará a la memoria la imagen del
kernel que definido en la configuración del gestor de arranque, después
de lo cual, se indica a la CPU que debe ejecutar el kernel. Al ser
cargado y luego ejecutado inicializa todas las estructuras y tareas
específicas del kernel e inicia el proceso init.
Este proceso asegura que todos los sistemas de archivo (definidos en
/etc/fstab) estén montados y listos para usar. Luego
ejecuta varios scripts en /etc/init.d, correspondientes a
los servicios requeridos para tener un sistema correctamente iniciado.
Finalmente, al concluir la ejecución de los scripts, init
activa los terminales (generalmente solo las consolas virtuales
accesibles con Alt-F1, Alt-F2, etc.) fijándoles un proceso
especial denominado agetty. Este proceso hará posible que pueda
ingresar al sistema a través de uno de estos terminales ejecutando
login.
Scripts de inicio (init scripts)
Ahora bien, init no solamente ejecuta los scripts contenidos en
/etc/init.d de manera aleatoria. Aún más, no ejecuta
todos los scripts del /etc/init.d, solamente los que han
sido seleccionados para ejecutar. Los scripts seleccionados para
ejecutar se encuentran dentro del directorio
/etc/runlevels.
Primero, init ejecuta todos los scripts de
/etc/init.d cuyos vínculos simbólicos se encuentran
dentro de /etc/runlevels/boot. Usualmente los iniciará en
orden alfabético, pero algunos scripts tienen información relativa a
dependencias, para lo cual otros scripts deben ser iniciados anteriormente.
Cuando todos los scripts referenciados en
/etc/runlevels/boot sean ejecutados, init continua
su trabajo con los scripts en /etc/runlevels/default. Una
vez más, usará el orden alfabético, salvo cuando hay dependencias, en
cuyo caso es alterado el orden de inicio para realizar una secuencia
válida de arranque.
¿Cómo funciona Init?
Por supuesto que init no decide todo eso por su
cuenta. Requiere un archivo de configuración que especifica las
acciones a tomar. Este archivo es /etc/inittab.
Si recuerda al secuencia de inicio recién explicada, recordará que la
primera acción de init es montar todos los sistemas de
archivo. Esto está definido en la siguiente línea de /etc/inittab:
Listado de Código 1.1: La línea de inicialización del sistema en /etc/inittab |
si::sysinit:/sbin/rc sysinit
|
Es línea dice a init que debe ejecutar /sbin/rc sysinit al
iniciar el sistema. Los scripts /sbin/rc se encargan de la
inicialización, con lo que podríamos decir que init no hace mucho,
delega la tarea de inicialización del sistema a otro proceso.
En segundo lugar, init ejecutó los scripts con vínculos
simbólicos en /etc/runlevels/boot. Esto se define en la
siguiente línea:
Listado de Código 1.2: Inicialización del sistema, continuada |
rc::bootwait:/sbin/rc boot
|
Una vez más, el script rc lleva a cabo las tareas
necesarias. Note que la opción de rc (boot) corresponde
al subdirectorio usado bajo /etc/runlevels.
Ahora init revisa su archivo de configuración para ver que
nivel de ejecución debe ejecutar. Para decidirlo, lee la
siguiente línea de /etc/inittab:
Listado de Código 1.3: La línea init por defecto (default) |
id:3:initdefault:
|
En este caso (para la mayoría de usuarios Gentoo), el identificador
del nivel de ejecución será el 3. Con esta información
init revisa qué debe ejecutar para iniciar el nivel de
ejecución 3:
Listado de Código 1.4: Definiciones de niveles de ejecución |
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
|
La línea que define el nivel 3, de nuevo usa el script rc para
iniciar los servicios (ahora con el parámetro por defecto
default). Note una vez más que el parámetro pasado al script
rc corresponde al subdirectorio de /etc/runlevels.
Al terminar rc, init decide cuáles consolas virtuales
debe activar y qué comandos deben ser ejecutados para cada una:
Listado de Código 1.5: Definición de las consolas virtuales |
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
|
¿Qué es un nivel de ejecución?
Ha visto que init utiliza un esquema de numeración para decidir
cual nivel de ejecución debe activar. Un nivel de
ejecución es un estado en el cual su sistema está corriendo y
contiene scripts (del nivel de ejecución o initscripts)
que serán ejecutados al ingresar o salir del nivel de ejecución.
En Gentoo, hay siete niveles de ejecución definidos: tres internos y
cuatro definidos por el usuario. Los internos se llaman
sysinit, shutdown y reboot y hacen exactamente lo
que implican sus nombres, inicialización, apagado y reinicio del
sistema.
Los niveles de ejecución definidos por el usuario están acompañados de
un subdirectorio bajo /etc/runlevels: boot,
default, nonetwork y single. El
nivel de ejecución boot inicia los servicios necesarios
que requieren los demás niveles de ejecución. Los tres niveles de
ejecución restantes difieren respecto a los servicios que inician:
default es para uso diario, nonetwork en
caso de no requerirse la red y single es utilizado en
caso de necesitar arreglar el sistema.
Trabajando con los scripts de inicio
Los scripts iniciados por el proceso rc son llamados scripts de
inicio o init scripts. Cada script en
/etc/init.d puede ser ejecutado con los parámetros
start, stop, restart, pause, zap,
status, ineed, iuse, needsme,
usesme o broken.
Para iniciar, parar o reiniciar un servicio (y sus respectivas
dependencias), deben usarse start, stop y
restart:
Listado de Código 1.6: Iniciando postfix |
# /etc/init.d/postfix start
|
Nota:
Sólo los servicios que necesiten (need) del servicio nombrado
serán parados o reiniciados. Los demás servicios, aquellos que usen
(use) el servicio nombrado, pero que no lo necesiten
(need) continuarán sin ser tocados.
|
Si desea parar un servicio, pero no los que dependan de el, puede usar
el parámetro para pausarlo pause:
Listado de Código 1.7: Parando postfix, manteniendo ejecución de los demás servicios |
# /etc/init.d/postfix pause
|
Si desea ver el estado de un servicio (iniciado, parado, pausado, ...)
puede usar el parámetro status:
Listado de Código 1.8: Estado del servicio postfix |
# /etc/init.d/postfix status
|
Si la respuesta a status indica que el servicio está corriendo, pero
realmente no es así, puede reajustarlo manualmente con el
parámetro zap:
Listado de Código 1.9: Reajustando la información del estado del servicio postfix |
# /etc/init.d/postfix zap
|
Para preguntar por las dependencias que tiene un servicio, puede usar
iuse o ineed. Con ineed puede ver cuales
servicios son realmente necesarios para el correcto funcionamiento del
servicio nombrado. Por otra parte, el parámetro iuse muestra
los servicios que pueden ser usados por el servicio nombrado, pero que
no son requeridos para su correcto funcionamiento.
Listado de Código 1.10: Solicitando una lista de servicios de los cuales depende postfix |
# /etc/init.d/postfix ineed
|
De igual manera, puede indagar que servicios requieren el servicio
nombrado (needsme) o cuáles pueden usarlo (usesme):
Listado de Código 1.11: Solicitando una lista de todos los servicios que requieren postfix |
# /etc/init.d/postfix needsme
|
Finalmente, puede indagar cuales dependencias son requeridas y están faltando:
Listado de Código 1.12: Solicitando una lista de dependencias faltantes para postfix |
# /etc/init.d/postfix broken
|
2.b. Trabajando con rc-update
¿Qué es rc-update?
El sistema de inicio (init) de Gentoo usa un árbol de dependencias para
decidir qué servicios deben iniciarse primero. Como ésta es una tarea
tediosa, que no deseamos que nuestros usuarios tengan que hacer
manualmente, hemos creado unas herramientas para facilitar la
administración de los niveles de ejecución y los scripts de inicio.
Con rc-update puede añadir o quitar scripts de inicio a un
nivel de ejecución. La herramienta rc-update automáticamente
usará el script depscan.sh para reconstruir el árbol de dependencias.
Añadiendo y removiendo servicios
Ya hemos agregado scripts de inicio al nivel de ejecución por
defecto durante la instalación de Gentoo. En ese instante tal vez no
haya tenido una idea clara acerca del uso de un nivel de ejecución
"por defecto", aunque ahora sí. El script rc-update requiere un
segundo parámetro que define la acción a llevar a cabo: add,
del o show para agregar, borrar o mostrar.
Para añadir o quitar un script de inicio, use rc-update con el
parámetro add o del, seguido por el nombre del script de
inicio y el nivel de ejecución, por ejemplo:
Listado de Código 2.1: Quitar postfix del nivel de ejecución por defecto |
# rc-update del postfix default
|
El comando rc-update show mostrará todos los scripts de inicio
con los niveles de ejecución donde ejecutarán:
Listado de Código 2.2: Recibiendo información de los scripts de inicio |
# rc-update show
|
4.c. Configuración de servicios
¿Porqué requerimos configuración adicional?
Los scripts de inicio pueden ser bastante complejos, por lo cual no
es interesante que los usuarios modifiquen directamente el script de
inicio, ya que esto puede ser propenso a errores. Sin embargo es
importante poder configurar estos servicios, en caso que se
quieren dar más opciones al servicio.
Una segunda razón para mantener esta información fuera del script de
inicio es para poder actualizar estos scripts sin que los cambios de
configuración sean perdidos.
El directorio /etc/conf.d
Gentoo provee una manera fácil de configurar estos servicios: cada
script de inicio configurable tiene un archivo dispuesto en
/etc/conf.d. Por ejemplo, el script de inicio apache2
(llamado /etc/init.d/apache2) tiene un archivo de
configuración de nombre /etc/conf.d/apache2, el cual
contiene las opciones a pasar al servidor web Apache 2 en el momento
de inicio:
Listado de Código 3.1: Variables definidas en /etc/conf.d/apache2 |
APACHE2_OPTS="-D PHP4"
|
Este tipo de archivo de configuración contiene solamente variables
(como /etc/make.conf), lo que facilita la configuración
de servicios. También nos permite suministrar información adicional
acerca de las variables (en forma de comentarios).
4.d. Escribiendo scripts de inicio
¿Realmente tengo que hacerlo?
Realmente, no. Escribir un script de inicio usualmente no hace falta,
ya que Gentoo provee scripts listos para usar para todos los
servicios suministrados. Sin embargo, puede haber instalado un
servicio sin usar Portage, en cuyo caso probablemente tenga que crear
un script de inicio.
No use el script de inicio suministrado por el servicio si no está
explícitamente escrito para Gentoo: los scripts de inicio de Gentoo ¡no
son compatibles con los de las demás distribuciones!
Disposición
La disposición básica de un script de inicio se muestra a continuación.
Listado de Código 4.1: Disposición básica de un script de inicio |
#!/sbin/runscript
depend() {
}
start() {
}
stop() {
}
restart() {
}
|
Cualquier script de inicio requiere la definición de la función
start(). Todas las demás son opcionales.
Dependencias
Hay dos dependencias que puede definir: use y need. Tal
como hemos mencionado anteriormente, la dependencia need es más
estricta que la dependencia use. Siguiendo este esquema, se
declaran los servicios que dependen de éste o la dependencia virtual.
Una dependencia virtual es una suministrada por un servicio,
pero no solo por ese servicio. Su script de inicio puede depender de un
gestor de registro de sistema, habiendo disponibilidad de varios (metalogd, syslog-ng,
sysklogd, ...). Como no se necesitan todos (ningún
sistema normal tiene todos estos gestores de registro instalados y
corriendo) nos aseguramos que todos estos servicios provean una
dependencia virtual.
Examinemos la información de dependencia del servicio postfix.
Listado de Código 4.2: Información de dependencias de postfix |
depend() {
need net
use logger dns
provide mta
}
|
Como podemos ver, el servicio postfix:
-
requiere la dependencia (virtual) net (suministrada por, en
este caso, /etc/init.d/net.eth0)
-
usa la dependencia (virtual) logger (suministrada por, en
este caso, /etc/init.d/syslog-ng)
-
usa la dependencia virtual (virtual) dns (suministrada por,
en este caso, /etc/init.d/named)
-
provee la dependencia (virtual) mta (común a todos los
servidores de correo electrónico)
Controlando el orden
En algunos casos, tal vez no requiera un servicio determinado, pero
desea que inicie antes (o después) de otro servicio
si está disponible en el sistema (note la condicionalidad,
esto ya no es una dependencia) y en el mismo nivel de ejecución
(note la condicionalidad, solo involucra servicios del mismo nivel de
ejecución). Puede suministrar esta información usando los parámetros
before o after.
Como ejemplo, podemos ver la disposición del servicio portmap:
Listado de Código 4.3: La función depend() en el servicio portmap |
depend() {
need net
before inetd
before xinetd
}
|
También puede usar el carácter cque engloba "*" para todos los servicios,
aunque no es aconsejable.
Listado de Código 4.4: Ejecutando un script de inicio como el primer script del nivel de ejecución |
depend() {
before *
}
|
Funciones estándar
Junto con la función depend(), hará falta definir la función
start(), que contiene los comandos necesarios para inicializar
su servicio. Es aconsejable usar las funciones ebegin y
eend para informarle al usuario acerca de lo que está
ocurriendo:
Listado de Código 4.5: Ejemplo de función start() |
start() {
ebegin "Starting my_service"
start-stop-daemon --start --quiet --exec /path/to/my_service
eend $?
}
|
Si requiere más ejemplos de funciones start(), favor leer
directamente las fuentes de los scripts de inicio en su directorio
/etc/init.d. En lo que respecta el
start-stop-daemon, hay un excelente página man disponible en
caso de requerir mayor información:
Listado de Código 4.6: Buscando página man para el start-stop-daemon |
# man start-stop-daemon
|
Otras funciones que puede definir son: stop() y
restart(). ¡No es obligatorio definirlas! Nuestro sistema de
inicio es suficientemente inteligente para llevar a cabo esta
funciones solo, si usa el start-stop-daemon.
Añadiendo opciones personalizadas
Si desea que su script de inicio soporte un mayor número de opciones de
las que hemos encontrado hasta ahora, debe agregar la opción a la
variable opts y crear una función con el mismo nombre de la
opción. Por ejemplo, para soportar una opción de nombre restartdelay:
Listado de Código 4.7: Soporte para la opción restartdelay |
opts="${opts} restartdelay"
restartdelay() {
stop()
sleep 3
start()
}
|
Variables para la configuración de servicios
No hay que hacer nada para soportar un archivo de configuración en
/etc/conf.d: si su script de inicio se ejecuta, los
siguientes archivos serán automáticamente leídos (sourced) y las
variables estarán disponibles para usar.
- /etc/conf.d/<your init script>
- /etc/conf.d/basic
- /etc/rc.conf
También, si su script de inicio provee una dependencia virtual (como
net), el archivo asociado a esa dependencia (el
/etc/conf.d/net) será leído también.
4.e. Cambiando el comportamiento del nivel de ejecución
¿Quién puede beneficiarse de esto?
Muchos usuarios de equipos portátiles conocen la situación: en casa necesita
iniciar net.eth0 mientras que puede no querer iniciar net.eth0
mientras está de viaja (cuando no hay una red disponible). Con Gentoo puede
modificar el comportamiento del nivel de ejecución para sus propios propósitos.
Por ejemplo puede crear un segundo nivel de ejecución "default" con el cual
puede arrancar y que utiliza otros scripts de inicio que le han sido asignados.
Puede seleccionar al arrancar que nivel de ejecución quiere utilizar.
Utilizando SOFTLEVEL
Antes de nada, cree el directorio para su segundo nivel de ejecución "default".
Como ejemplo vamos a crear el nivel de ejecución offline:
Listado de Código 8.15: Creando el directorio para el nivel de ejecución |
# mkdir /etc/runlevels/offline
|
Añada los scripts de inicio necesarios para el nuevo nivel de ejecución.
Por ejemplo, si quiere una copia exacta de su actual "default" pero sin
net.eth0:
Listado de Código 5.2: Añadiendo los scripts de inicio necesarios |
# ls /etc/runlevels/default
acpid domainname local net.eth0 netmount postfix syslog-ng vixie-cron
# rc-update add acpid offline
# rc-update add domainname offline
# rc-update add local offline
# rc-update add syslog-ng offline
# rc-update add vixie-cron offline
|
Ahora edite la configuración de su gestor de arranca y añada una nueva
entrada para el nivel de ejecución offline. Por ejemplo, en
/boot/grub/grub.conf:
Listado de Código 5.3: Añadiendo una entrada para el nivel de ejecución offline |
title Gentoo Linux Offline Usage
root (hd0,0)
kernel (hd0,0)/kernel-2.4.25 root=/dev/hda3 softlevel=offline
|
Listo, ha terminado de configurarlo. Si arranca su sistema y selecciona la
nueva entrada al inicio, el nivel de ejecución offline será el utilizado
en lugar del default.
Utilizando BOOTLEVEL
Utilizar bootlevel es completamente análogo a softlevel. La
única diferencia es que se define un segundo nivel de ejecución "boot" en lugar
de un segundo "default".
5. Environment Variables
5.a. ¿Variables de Entorno?
¿Qué son?
Una variable de entorno es un objeto designado para contener información usada
por una o más aplicaciones. Algunos usuarios (especialmente aquellos nuevos
en Linux) encuentran esto un poco extraño o inmanejable. Sin embargo esto no
es cierto: usando variables de entorno hace que cualquiera pueda cambiar una
opción de configuración para una o más aplicaciones fácilmente.
Ejemplos Importantes
La siguiente tabla muestra un listado de variables de entorno usado por un sistema Linux y
describe su uso. Los valores de ejemplo se encuentran después de la tabla.
| Variable |
Descripción |
| PATH |
Esta variable contiene una lista de directorios separados por ":" en la
cual el sistema buscará los archivos ejecutables. Al introducir el nombre
de un ejecutable (como ls, rc-update o emerge)
que no se encuentre en un de los directorios listados, el sistema no lo
encontrará, (a menos que se introduzca la ruta completa, por ejemplo:
/bin/ls).
|
| ROOTPATH |
Esta variable tiene la misma función que PATH, pero únicamente contiene
los directorios que el sistema debe revisar cuando el usuario root introduce un comando.
|
| LDPATH |
Esta variable contiene una lista de directorios separados por ":" en la cual
el enlazador dinámico busca para encontrar una librería.
|
| MANPATH |
Esta variable contiene una lista de directorios separados por ":" en la cual
el comando man busca las páginas de manual.
|
| INFODIR |
Esta variable contiene una lista de directorios separados por ":" en la cual
el comando info busca las páginas info.
|
| PAGER |
Esta variable contiene la ruta hacia el programa utilizado para mostrar el
contenido de los ficheros (como less o more).
|
| EDITOR |
Esta variable contiene la ruta hacia el programa utilizado para modificar el
contenido de los archivos (como nano o vi).
|
| KDEDIRS |
Esta variable contiene una lista de directorios separados por ":"
los cuales contienen material específico de KDE.
|
| CLASSPATH |
Esta variable contiene una lista de directorios separados por ":" los cuales
contienen las clases de Java.
|
| CONFIG_PROTECT |
Esta variable una lista de directorios separados por espacio los cuales
deben ser protegidos por Portage durante las actualizaciones..
|
| CONFIG_PROTECT_MASK |
Esta variable una lista de directorios separados por espacio los cuales
no deben ser protegidos por Portage durante las actualizaciones.
|
A continuación puedes encontrar ejemplos de definiciones para todas estas variables:
Listado de Código 1.1: Definiciones de ejemplo |
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. Definiendo variables globalmente
El directorio /etc/env.d
Para centralizar la definición de estas variables, Gentoo introduce el directorio
/etc/env.d. Dentro de este directorio se encuentran varios
ficheros como por ejemplo 00basic, 05gcc, etc.
los cuales contienen las variables necesarias para la aplicación de la cual llevan
el nombre.
Por ejemplo, al instalar gcc, un fichero llamado 05gcc
que contiene la definición de las siguientes variables, fue creado por
el ebuild:
Listado 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"
|
Otras distribuciones le piden modificar o añadir definiciones de variables
de entorno semejantes en /etc/profile o en otros sitios. Por
otro lado, Gentoo nos hace (y a Portage) más fácil mantener y manejar las
variables de entorno sin tener que prestar atención a los numerosos ficheros
que pueden contenerlas.
Por ejemplo, cuando gcc es actualizado, también es actualizado
el fichero /etc/env.d/05gcc sin ser necesaria ninguna interacción
por parte del usuario.
Esto no solo beneficia a Portage, sino también al usuario. En ocasiones se podrá
pedir establecer cierta variable de entorno para todo el sistema. Como ejemplo,
tomamos la variable http_proxy. En lugar de perder el tiempo con
/etc/profile, puedes crear el fichero (/etc/env.d/99local)
y introducir la(s) definición(es) en él:
Listado de Código 2.2: /etc/env.d/99local |
http_proxy="proxy.server.com:8080"
|
Usando el mismo fichero para todas las variables, se obtiene una visión rápida
de las variables que definidas por uno mismo.
El script env-update
Varios archivos de /etc/env.d definen la variable PATH. esto
no es un error: cuando ejecute env-update, este concatenará las múltiples
definiciones antes de actualizar las variables de entorno, haciendo más fácil a
los paquetes (o usuarios) añadir sus propias opciones en las variables de entorno
sin interferir con los valores ya existentes.
El script env-update concatenará los valores alfabéticamente ordenados
por el nombre de los ficheros de /etc/env.d. Esto es así porque
muchos de los ficheros de /etc/env.d empiezan por un número.
Listado de Código 2.3: Update order used by env-update |
00basic 99kde-env 99local
+-------------+----------------+-------------+
PATH="/bin:/usr/bin:/usr/kde/3.2/bin:/usr/local/bin"
|
Cuando ejecute env-update, el script creará todas las variables de entorno
y las colocará en /etc/profile.env (el cual es usado por
/etc/profile). Además, también extraerá la información de la
variable LDPATH y la usará para crear /etc/ld.so.conf.
Después de esto, ejecutará ldconfig para recrear el archivo usado por el
enlazador dinámico: /etc/ld.so.cache.
Si quiere observar el efecto de env-update inmediatamente después de
ejecutarlo, ejecute el siguiente comando para actualizar su entorno.
Posiblemente, los usuarios que instalaron Gentoo ellos mismos, recordarán
estas instrucciones de la instalación:
Listado de Código 2.4: Actualizando el entorno |
# env-update && source /etc/profile
|
5.c. Definiendo variables locales
Específicas de usuario
No siempre queremos definir variables de entorno globales. Por ejemplo,
podríamos querer añadir /home/my_user/bin a la variable
PATH, pero no queremos que todos los usuarios de nuestro sistema
lo tengan en su PATH. Si queremos definir una variable localmente,
debemos usar ~/.bashrc o ~/.bash_profile:
Listado de Código 3.1: Extendiendo el PATH para uso local en: ~/.bashrc |
PATH="${PATH}:/home/my_user/bin"
|
Cuando vuelva a iniciar la sesión, su variable PATH será actualizada.
Específicas de sesión
En ocasiones, se requieren definiciones aún más estrictas. Puede querer usar
binarios de un directorio temporal que ha creado sin tener que usar la trayectoria
completa a los binarios o sin editar ~/.bashrc. Para estos
momentos necesitará esto.
En este caso, puede definir la variable PATH en su sesión activa
usando el comando export. Mientra no cierre la sesión, la variable
PATH usará los valores temporales.
Listado de Código 3.2: Definiendo una variable específica a la sesión |
# export PATH="${PATH}:/home/my_user/tmp/usr/bin"
|
C. Working with Portage
1. Files and Directories
1.a. Portage Files
Configuration Directives
Portage comes with a default configuration stored in
/etc/make.globals. When you take a look at it, you'll notice that
all Portage configuration is handled through variables. What variables Portage
listens to and what they mean are described later.
Since many configuration directives differ between architectures, Portage also
has a default configuration file inside your profile:
/etc/make.profile/make.defaults. We'll explain more about profiles
and the /etc/make.profile directory later on.
If you're planning on changing a configuration variable, don't alter
/etc/make.globals or /etc/make.profile/make.defaults.
Instead use /etc/make.conf which has precedence over
the previous files. You'll also find a /etc/make.conf.example. As
the name implies, this is merely an example file - Portage does not read in
this file.
You can also define a Portage configuration variable as an environment variable,
but we don't recommend this.
Profile-Specific Information
We've already encountered the /etc/make.profile directory. Well,
this isn't exactly a directory but a symbolic link to a profile, by default one
inside /usr/portage/profiles although you can create your own
profiles elsewhere and point to them. The profile this symlink points to is the
profile to which your system adheres.
A profile contains architecture-specific information for Portage, such as a
list of packages that belong to the system corresponding with that profile,
a list of packages that don't work (or are masked-out) for that profile, etc.
User-Specific Configuration
When you need to override Portage's behaviour regarding the installation of
software, you will end up editing files within /etc/portage. You
are highly recommended to use files within /etc/portage and
highly discouraged to override the behaviour through environment
variables!
Within /etc/portage you can create the following files:
-
package.mask which lists the packages you never want Portage to
install
-
package.unmask which lists the packages you want to be able to
install even though the Gentoo developers highly discourage you from
emerging them
-
package.keywords which lists the packages you want to be able
to install even though the package hasn't been found suitable for your
system or architecture (yet)
-
package.use which lists the USE flags you want to use for
certain packages without having the entire system use those USE flags
More information about the /etc/portage directory and a full list
of possible files you can create can be found in the Portage man page:
Listado de Código 1.1: Reading the Portage man page |
$ man portage
|
Changing Portage File & Directory Locations
The previously mentioned configuration files cannot be stored elsewhere -
Portage will always look for those configuration files at those exact locations.
However, Portage uses many other locations for various purposes: build
directory, source code storage, Portage tree location, ...
All these purposes have well-known default locations but can be altered to your
own taste through /etc/make.conf. The rest of this chapter explains
what special-purpose locations Portage uses and how to alter their placement on
your filesystem.
This document isn't meant to be used as a reference though. If you need 100%
coverage, please consult the Portage and make.conf man pages:
Listado de Código 1.2: Reading the Portage and make.conf man pages |
$ man portage
$ man make.conf
|
1.b. Storing Files
The Portage Tree
The Portage tree default location is /usr/portage. This is defined
by the PORTDIR variable. When you store the Portage tree elsewhere (by altering
this variable), don't forget to change the /etc/make.profile
symbolic link accordingly.
If you alter the PORTDIR variable, you might want to alter the following
variables as well since they will not notice the PORTDIR change. This is due to
how Portage handles variables: PKGDIR, DISTDIR, RPMDIR.
Prebuilt Binaries
Even though Portage doesn't use prebuilt binaries by default, it has extensive
support for them. When you ask Portage to work with prebuilt packages, it will
look for them in /usr/portage/packages. This location is defined by
the PKGDIR variable.
Source Code
Application source code is stored in /usr/portage/distfiles by
default. This location is defined by the DISTDIR variable.
RPM Files
Even though Portage cannot use RPM files, it is able to generate them using the
ebuild command (see The Ebuild
Application). The default location where Portage stores RPM files is
/usr/portage/rpm and is defined by the RPMDIR variable.
1.c. Building Software
Temporary Portage Files
Portage's temporary files are stored in /var/tmp by default. This
is defined by the PORTAGE_TMPDIR variable.
If you alter the PORTAGE_TMPDIR variable, you might want to alter the following
variables as well since they will not notice the PORTAGE_TMPDIR change. This
is due to how Portage handles variables: BUILD_PREFIX.
Building Directory
Portage creates specific build directories for each package it emerges inside
/var/tmp/portage. This location is defined by the BUILD_PREFIX
variable.
Live Filesystem Location
By default Portage installs all files on the current filesystem
(/), but you can change this by setting the ROOT environment
variable. This is useful when you want to create new build images.
1.d. Logging Features
Ebuild Logging
Portage can create per-ebuild logfiles, but only when the PORT_LOGDIR variable
is set to a location that is writable by Portage (the portage user). By default
this variable is unset.
2. Configuring through Variables
2.a. Portage Configuration
As noted previously, Portage is configurable through many variables which
you should define in /etc/make.conf. Please refer to the
make.conf man page for more and complete information:
Listado de Código 1.1: Reading the make.conf man page |
$ man make.conf
|
2.b. Build-specific Options
Configure and Compiler Options
When Portage builds applications, it passes the contents of the following
variables to the compiler and configure script:
-
CFLAGS & CXXFLAGS define the desired compiler flags for C and C++
compiling.
-
CHOST defines the build host information for the application's configure
script
-
MAKEOPTS is passed to the make command and is usually set to define
the amount of parallelism used during the compilation. More information
about the make options can be found in the make man page.
The USE variable is also used during configure and compilations but has been
explained in great detail in previous chapters.
Merge Options
When Portage has merged a newer version of a certain software title, it will
remove the obsoleted files of the older version from your system. Portage gives
the user a 5 second delay before unmerging the older version. These 5 seconds
are defined by the CLEAN_DELAY variable.
2.c. Configuration File Protection
Portage's Protected Locations
Portage overwrites files provided by newer versions of a software title if the
files aren't stored in a protected location. These protected locations
are defined by the CONFIG_PROTECT variable and are generally configuration file
locations. The directory listing is space-delimited.
A file that would be written in such a protected location is renamed and the
user is warned about the presence of a newer version of the (presumable)
configuration file.
You can find out about the current CONFIG_PROTECT setting from the emerge
info output:
Listado de Código 3.1: Getting the CONFIG_PROTECT setting |
$ emerge info | grep 'CONFIG_PROTECT='
|
More information about Portage's Configuration File Protection is available
through emerge:
Listado de Código 3.2: More information about Configuration File Protection |
$ emerge --help config
|
Excluding Directories
To 'unprotect' certain subdirectories of protected locations you can use the
CONFIG_PROTECT_MASK variable.
2.d. Download Options
Server Locations
When the requested information or data is not available on your system, Portage
will retrieve it from the Internet. The server locations for the various
information and data channels are defined by the following variables:
-
GENTOO_MIRRORS defines a list of server locations which
contain source code (distfiles)
-
PORTAGE_BINHOST defines a particular server location containing prebuilt
packages for your system
A third setting involves the location of the rsync server which you use when you
update your Portage tree:
-
SYNC defines a particular server which Portage uses to fetch the
Portage tree from
The GENTOO_MIRRORS and SYNC variables can be set automatically through the
mirrorselect application. You need to emerge mirrorselect first
before you can use it. For more information, see mirrorselect's online
help:
Listado de Código 4.1: More information about mirrorselect |
# mirrorselect --help
|
If your environment requires you to use a proxy server, you can use the
HTTP_PROXY, FTP_PROXY and RSYNC_PROXY variables to declare a proxy server.
Fetch Commands
When Portage needs to fetch source code, it uses wget by default. You
can change this through the FETCHCOMMAND variable.
Portage is able to resume partially downloaded source code. It uses wget
by default, but this can be altered through the RESUMECOMMAND variable.
Make sure that your FETCHCOMMAND and RESUMECOMMAND stores the source code in the
correct location. Inside the variables you should use \${URI} and \${DISTDIR} to
point to the source code location and distfiles location respectively.
You can also define protocol-specific handlers with FETCHCOMMAND_HTTP,
FETCHCOMMAND_FTP, RESUMECOMMAND_HTTP, RESUMECOMMAND_FTP, and so on.
Rsync Settings
You cannot alter the rsync command used by Portage to update the Portage tree,
but you can set some variables related to the rsync command:
-
RSYNC_EXCLUDEFROM points to a file listing the packages and/or categories
rsync should ignore during the update process
-
RSYNC_RETRIES defines how many times rsync should try connecting to the
mirror pointed to by the SYNC variable before bailing out. This variable
defaults to 3.
-
RSYNC_TIMEOUT defines the amount of seconds an rsync connection can idle
before rsync sees the connection as timed-out. This variable defaults to 180
but dialup users probably want to set this to 300 or higher.
2.e. Gentoo Configuration
Branch Selection
You can change your default branch with the ACCEPT_KEYWORDS variable. It
defaults to your architecture's stable branch. More information on Gentoo's
branches can be found in the next chapter.
Portage Features
You can activate certain Portage features through the FEATURES variable. The
Portage Features have been discussed in previous chapters, such as Portage Features.
2.f. Portage Behaviour
Resource Management
With the PORTAGE_NICENESS variable you can augment or reduce the nice value
Portage runs with. The PORTAGE_NICENESS value is added to the current
nice value.
For more information about nice values, see the nice man page:
Listado de Código 6.1: More information about nice |
$ man nice
|
Output Behaviour
The NOCOLOR, which defaults to "false", defines if Portage should disable the
use of coloured output.
3. Mixing Software Branches
3.a. Using One Branch
The Stable Branch
The ACCEPT_KEYWORDS variable defines what software branch you use on your
system. It defaults to the stable software branch for your architecture, for
instance x86.
We recommend that you only use the stable branch. However, if you don't care
about stability this much and you want to help out Gentoo by submitting
bugreports to http://bugs.gentoo.org, read on.
The Testing Branch
If you want to use more recent software you can consider using the testing
branch instead. To have Portage use the testing branch, add a ~ in front of your
architecture.
For instance, to select the testing branch for the x86 architecture, edit
/etc/make.conf and set:
Listado de Código 1.1: Setting the ACCEPT_KEYWORDS variable |
ACCEPT_KEYWORDS="~x86"
|
If you update your system now, you will find out that lots of packages
will be updated. Mind you though: when you have updated your system to use the
testing branch there is usually no easy way back to the stable, official branch
(except for using backups of course).
3.b. Mixing Stable with Testing
The package.keywords file
You can ask Portage to allow the testing branch for particular packages but use
the stable branch for the rest of the system. To achieve this, add the package
category and name you want to use the testing branch of in
/etc/portage/package.keywords. For instance, to use the testing
branch for gnumeric:
Listado de Código 2.1: /etc/portage/package.keywords setting for gnumeric |
app-office/gnumeric
|
The same can be achieved when you add the correct keyword at the end of the
line, for instance for the x86 architecture:
Listado de Código 2.2: /etc/portage/package.keywords setting for gnumeric, full line |
app-office/gnumeric ~x86
|
Test Particular Versions
If you want to use a specific software version from the testing branch but you
don't want Portage to use the testing branch for subsequent versions, you can
add in the version in the package.keywords file. In this case you
must use the = operator. You can also enter a version range
using the <=, <, > or >= operators.
In any case, if you add version information, you must use an operator. If
you leave out version information, you cannot use an operator.
In the following example we ask Portage to accept gnumeric-1.2.13:
Listado de Código 2.3: Using a particular gnumeric version |
=app-office/gnumeric-1.2.13
|
3.c. Using Masked Packages
The package.unmask file
When a package has been masked by the Gentoo developers and you still want to
use it despite the reason mentioned in the package.mask file
(situated in /usr/portage/profiles by default), add the
exact same line in /etc/portage/package.unmask.
For instance, if =net-mail/hotwayd-0.8 is masked, you can unmask it by
adding the exact same line in the package.unmask file:
Listado de Código 3.1: /etc/portage/package.unmask |
=net-mail/hotwayd-0.8
|
The package.mask file
When you don't want Portage to take a certain package or a specific version of a
package into account you can mask it yourself by adding an appropriate line to
/etc/portage/package.mask.
For instance, if you don't want Portage to install newer kernel sources than
development-sources-2.6.8.1, you add the following line to
package.mask:
Listado de Código 3.2: /etc/portage/package.mask example |
>sys-kernel/development-sources-2.6.8.1
|
4. Additional Portage Tools
4.a. etc-update
etc-update is a tool that aids in merging the
._cfg0000_<name> files. It provides an interactive merging
setup and can also auto-merge trivial changes.
._cfg0000_<name> files are generated by Portage when it wants
to store a file in a directory protected by the CONFIG_PROTECT variable.
Running etc-update is pretty straight-forward:
Listado de Código 1.1: Running etc-update |
# etc-update
|
After merging the straightforward changes, you will be prompted with a list of
protected files that have an update waiting. At the bottom you are greeted by
the possible options:
Listado de Código 1.2: etc-update options |
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'):
|
If you enter -1, etc-update will exit without performing any
changes. If you enter -3 or -5, all listed configuration
files will be overwritten with the newer versions. It is therefore very
important to first select the configuration files that should not be
automatically updated. This is simply a matter of entering the number listed to
the left of that configuration file.
As an example, we select the configuration file /etc/pear.conf:
Listado de Código 1.3: Updating a specific configuration file |
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
|
You can now see the differences between the two files. If you believe that the
updated configuration file can be used without problems, enter 1. If you
believe that the updated configuration file isn't necessary, or doesn't provide
any new or useful information, enter 2. If you want to interactively
update your current configuration file, enter 3.
There is no point in further elaborating the interactive merging here. For
completeness sake, we will list the possible commands you can use while you are
interactively merging the two files. You are greeted with two lines (the
original one, and the proposed new one) and a prompt at which you can enter one
of the following commands:
Listado de Código 1.4: Commands available for the interactive merging |
ed: Edit then use both versions, each decorated with a header.
eb: Edit then use both versions.
el: Edit then use the left version.
er: Edit then use the right version.
e: Edit a new version.
l: Use the left version.
r: Use the right version.
s: Silently include common lines.
v: Verbosely include common lines.
q: Quit.
|
When you have finished updating the important configuration files, you can now
automatically update all the other configuration files. etc-update will
exit if it doesn't find any more updateable configuration files.
4.b. dispatch-conf
Using dispatch-conf you are able to merge updates to your configuration
files while keeping track of all changes. dispatch-conf stores the
differences between the configuration files as patches or by using the RCS
revision system.
Like etc-update, you can ask to keep the configuration file as-is, use
the new configuration file, edit the current one or merge the changes
interactively. However, dispatch-conf also has some nice additional
features:
-
Automatically merge configuration file updates that only contain updates to
comments
-
Automatically merge configuration files which only differ in the amount of
whitespace
Make certain you edit /etc/dispatch-conf.conf first and create the
directory referenced by the archive-dir variable.
For more information, check out the dispatch-conf man page:
Listado de Código 2.1: Reading the dispatch-conf man page |
$ man dispatch-conf
|
4.c. quickpkg
With quickpkg you can create archives of the packages that are already
merged on your system. These archives can be used as prebuilt packages. Running
quickpkg is straightforward: just add the names of the packages you want
to archive.
For instance, to archive curl, arts and procps:
Listado de Código 3.1: Example quickpkg usage |
# quickpkg curl arts procps
|
The prebuilt packages will be stored in /usr/portage/packages/All.
Symbolic links pointing to these packages are placed in
/usr/portage/packages/<category>.
5. Diverting from the Official Tree
5.a. Using a Portage Tree Subset
Excluding Packages/Categories
You can selectively update certain categories/packages and ignore the other
categories/packages. We achieve this by having rsync exclude
categories/packages during the emerge --sync step.
By default, rsync will check the contents of
/etc/portage/rsync_excludes (if it exists) which contains the
categories or packages that you don't want rsync to update.
Note however that this may lead to dependency issues since new, allowed packages
might depend on new but excluded packages.
5.b. Adding Unofficial Ebuilds
Defining a Portage Overlay Directory
You can ask Portage to use ebuilds that are not officially available through the
Portage tree. Create a new directory (for instance
/usr/local/portage) in which you store the 3rd-party ebuilds. Use
the same directory structure as the official Portage tree!
Then define PORTDIR_OVERLAY in /etc/make.conf and have it point to
the previously defined directory. When you use Portage now, it will take those
ebuilds into account as well without removing/overwriting those ebuilds the next
time you run emerge --sync.
5.c. Non-Portage Maintained Software
Using Portage with Self-Maintained Software
In some cases you want to configure, install and maintain software yourself
without having Portage automate the process for you, even though Portage
can provide the software titles. Known cases are kernel sources and nvidia
drivers. You can configure Portage so it knows that a certain package is
manually installed on your system. This process is called injecting and
supported by Portage through the
/etc/portage/profile/package.provided file.
For instance, if you want to inform Portage about
development-sources-2.6.8.1 which you've installed manually, add the
following line to /etc/portage/profile/package.provided:
Listado de Código 3.1: Example line for package.provided |
sys-kernel/development-sources-2.6.8.1
|
6. The Ebuild Application
6.a. Emerge and Ebuild
The ebuild application is a lower level interface to the Portage system.
Using this application you can execute specific actions against a given ebuild.
For instance, you can perform the individual merging steps by yourself.
Using ebuild is more for development purposes; more information about
ebuild can therefore be found in the Developers Handbook. However,
we will explain what ebuild instances are invoked by Portage during the merge
process of a certain software title, and how to invoke the post-configuration
steps some ebuilds allow you to perform.
4.b. Manually Installing Software
Fetching the Sources & Checksumming
Whenever you invoke ebuild against a given ebuild file, it will verify if
the checksums of all involved files are equal to those given in the
accompanying Manifest or
files/digest-<name>-<version> file. This
happens after the sources have been fetched.
To fetch the sources using ebuild, run:
Listado de Código 2.1: Fetching the sources |
# ebuild path/to/ebuild fetch
|
If the ebuild's md5sum does not match the one listed in the
Manifest file, or one of the downloaded sources don't match those
listed in the files/digest-<package> file, you will receive
an error similar to this:
Listado de Código 2.2: Ebuild checksum failure |
!!! File is corrupt or incomplete. (Digests do not match)
>>> our recorded digest: db20421ce35e8e54346e3ef19e60e4ee
>>> your file's digest: f10392b7c0b2bbc463ad09642606a7d6
|
The subsequent line will mention the erroneous file.
If you are certain that the sources you've fetched and the ebuild itself are
valid, you can regenerate the Manifest and
digest-<package> file using ebuild's digest
functionality:
Listado de Código 2.3: Regenerate Manifest and digest |
# ebuild path/to/ebuild digest
|
Unpacking the Sources
To unpack the sources in /var/tmp/portage (or any other directory
location you have specified in /etc/make.conf), run ebuild's
unpack functionality:
Listado de Código 2.4: Unpacking the sources |
# ebuild path/to/ebuild unpack
|
This will execute the ebuild's src_unpack() function (which defaults to plain
extraction if no src_unpack() function is defined). It is also in this step that
all necessary patches are applied.
Compiling the Sources
The next step in the merge process is to compile the sources. The
ebuild's compile functionality takes care of this step by executing the
src_compile() function in the ebuild. This also includes the configure steps if
appropriate.
Listado de Código 2.5: Compiling the sources |
# ebuild path/to/ebuild compile
|
You are advised to edit the ebuild's src_compile() function if you want to
change the compilation instructions. However, you can also trick Portage into
believing that the ebuild application has finished the compile steps. Run
all necessary commands yourself and create an empty file called
.compiled in the working directory:
Listado de Código 2.6: Informing Portage about the finished compilation jobs |
# touch .compiled
|
Installing the Files in a Temporary Location
In the next step Portage will install all necessary files in a temporary
location. This directory will then contain all files that are to be merged on
the live filesystem. You can accomplish this by running ebuild's install
functionality, which executes the ebuild's src_install() function:
Listado de Código 2.7: Installing the files |
# ebuild path/to/ebuild install
|
Merging the Files onto the Live Filesystem
The final step is to merge all files onto the live filesystem and register those
in the Portage backend. ebuild calls this step "qmerge" and involves the
following steps:
- Execute the pkg_preinst() function if specified
- Copy over all files to the live filesystem
- Register the files in the Portage backend
- Execute the pkg_postinst() function if specified
Run ebuild's qmerge functionality to accomplish these steps:
Listado de Código 2.8: Merging the files on the live filesystem |
# ebuild path/to/ebuild qmerge
|
Cleaning the Temporary Directory
Finally you can clean the temporary directory using ebuild's clean
functionality:
Listado de Código 2.9: Cleaning the temporary directory |
# ebuild path/to/ebuild clean
|
6.c. Additional Ebuild Features
Running all Merge-related Commands
Using ebuild's merge functionality you can run the fetch, unpack,
compile, install and qmerge commands in one go:
Listado de Código 3.1: Installing software |
# ebuild path/to/ebuild merge
|
Performing Configuration Actions
Some applications include instructions that configure the package further on
your system. These instructions can be interactive and are therefore not
automatically executed. To run these configuration steps, which are enlisted in
the ebuild's (optional) config() function, use ebuild's config
functionality:
Listado de Código 3.2: Configuring a package |
# ebuild path/to/ebuild config
|
Building an (RPM) Package
You can instruct Portage to create a binary package of an ebuild or even an RPM
file. Use ebuild's package or rpm functionality to create these archives.
There are a few differences between those functionalities though:
-
The package functionality is a lot like the merge functionality, executing
all necessary steps (fetch, unpack, compile, install) before creating the
package
-
The rpm functionality builds an RPM package from the files created
after having run ebuild's install functionality
Listado de Código 3.3: Creating packages |
# ebuild path/to/ebuild package
# ebuild path/to/ebuild rpm
|
The created RPM file however does not contain the ebuild's dependency
information.
6.d. More Information
Please consult the following man pages for more information about Portage, the
ebuild application and the ebuild files:
Listado de Código 4.1: Man pages |
$ man portage
$ man emerge
$ man ebuild
$ man 5 ebuild
|
You will also find more development-related information in the Developers Handbook.
El contenido de este documento, a no ser que se especifique
expresamente, está registrado bajo los términos de la licencia
CC-BY-SA-2.5. Se aplican las
Pautas de
Utilización del logotipo y nombre de Gentoo.
|