Gentoo Linux 2006.0 x86 HandbookContent:
A. Installing Gentoo1. About the Gentoo Linux InstallationFirst of all, welcome to Gentoo. You are about to enter the world of customization and performance. When installing Gentoo, this is made clear to you several times -- you can choose how much you want to compile yourself, how to install Gentoo, what system logger you want, etc. Gentoo is a fast, modern meta-distribution with a clean and flexible design. Gentoo is built around free software and doesn't hide from its users what is beneath the hood. Portage, the package maintenance system which Gentoo uses, is written in Python, meaning you can easily view and modify the source code. Gentoo's packaging system uses source code (although support for precompiled packages is included too) and configuring Gentoo happens through regular text files. In other words, openness everywhere. It is very important that you understand that empowerment is what makes Gentoo run. We try not to force anything on our users and try our best to empower you to make the choices you wish. If you feel a change should be made, please file a bug report about it. How do I go about Installing Gentoo? Gentoo Linux comes with two versions of an easy to use Installer. A GTK+ based installer (for use with an X based environment) and a Dialog based installer for use on the console. Chapter 3 of the handbook deals with the GTK+ based installer while Chapter 4 is for the Dialog based one. Sometimes, you are given a certain choice in the handbook. We try our best to explain what the pros and cons are. We will continue then with a default choice, identified by "Default: " in the title. The other possibilities are marked by "Alternative: ". Do not think that the default is what we recommend. It is however what we believe most users will use. Sometimes you can pursue an optional step. Such steps are marked as "Optional: " and are therefore not needed to install Gentoo. However, some optional steps are dependant on a previous decision you made. We will inform you when this happens, both when you make the decision, and right before the optional step is described. You can install Gentoo in many different ways. You can download and install from one of our Installation CDs, from an existing distribution, from a bootable CD (such as Knoppix), from a netbooted environment, from a rescue floppy, etc. This document covers the installation using a Gentoo Linux Installation CD, a bootable CD that contains everything you need to get Gentoo Linux up and running. There are two types of Installation CDs, the InstallCD and the Installer LiveCD. The InstallCD is a minimal environment which contains only those packages necessary for installing Gentoo Linux. The LiveCD is a complete Gentoo Linux environment and can be used for multiple tasks, one of which is installing Gentoo Linux. The LiveCD is not available on all architectures at this time. If your architecture does not have a LiveCD, then this document will refer to the Universal InstallCD for you. This installation approach however does not immediately use the latest version of the available packages; if you want this you should check out the Installation Instructions inside our Gentoo Linux Handbooks. For help on the other installation approaches, please read our Alternative Installation Guide. We also provide a Gentoo Installation Tips & Tricks document that might be useful to read as well. If you feel that the current installation instructions are too elaborate, feel free to use our Quick Installation Guide available from our Documentation Resources if your architecture has such a document available. If you find a problem in the installation (or in the installation documentation), please check the errata from our Gentoo Release Engineering Project, visit our bug tracking system and check if the bug is known. If not, please create a bug report for it so we can take care of it. Do not be afraid of the developers who are assigned to (your) bugs -- they generally don't eat people. Note though that, although the document you are now reading is architecture-specific, it will contain references to other architectures as well. This is due to the fact that large parts of the Gentoo Handbook use source code that is common for all architectures (to avoid duplication of efforts and starvation of development resources). We will try to keep this to a minimum to avoid confusion. If you are uncertain if the problem is a user-problem (some error you made despite having read the documentation carefully) or a software-problem (some error we made despite having tested the installation/documentation carefully) you are free to join #gentoo on irc.freenode.net. Of course, you are welcome otherwise too :) If you have a question regarding Gentoo, check out our Frequently Asked Questions, available from the Gentoo Documentation. You can also view the FAQs on our forums. If you can't find the answer there ask on #gentoo, our IRC-channel on irc.freenode.net. Yes, several of us are freaks who sit on IRC :-) 1.b. Fast Installation using the Gentoo Reference Platform What is the Gentoo Reference Platform? The Gentoo Reference Platform, from now on abbreviated to GRP, is a snapshot of prebuilt packages users (that means you!) can install during the installation of Gentoo to speed up the installation process. The GRP consists of all packages required to have a fully functional Gentoo installation. They are not just the ones you need to have a base installation up to speed in no time, but all lengthier builds (such as xorg-x11, GNOME, OpenOffice, Mozilla, ...) are available as GRP packages too. However, these prebuilt packages aren't maintained during the lifetime of the Gentoo distribution. They are snapshots released at every Gentoo release and make it possible to have a functional environment in a short amount of time. You can then upgrade your system in the background while working in your Gentoo environment. How Portage Handles GRP Packages Your Portage tree - the collection of ebuilds (files that contain all information about a package, such as its description, homepage, sourcecode URLs, compilation instructions, dependencies, etc.) - must be synchronised with the GRP set: the versions of the available ebuilds and their accompanying GRP packages must match. For this reason you can only benefit from the GRP packages Gentoo provides while performing the current installation approach. GRP is not available for those interested in performing an installation using the latest versions of all available packages. Not all architectures provide GRP packages. That doesn't mean GRP isn't supported on the other architectures, but it means that we don't have the resources to build and test the GRP packages. At present we provide GRP packages for the following architectures:
If your architecture (or subarchitecture) isn't on this list, you are not able to opt for a GRP installation. Now that this introduction is over, let's continue with Booting the Universal InstallCD/Installer LiveCD. 2. Booting the Installer LiveCDBefore we start, we first list what hardware requirements you need to successfully install Gentoo on your box using the Installer LiveCD.
2.b. The Gentoo Linux Installer LiveCD Gentoo Linux can be installed using a stage3 tarball file. Such a tarball is an archive that contains a minimal environment from which you can successfully install Gentoo Linux onto your system. Installations using a stage1 or stage2 tarball file are not documented in the Gentoo Handbook - please read the Gentoo FAQ on these matters. A LiveCD is a bootable medium which contains a self-sustained Gentoo environment. It allows you to boot Linux from the CD. During the boot process your hardware is detected and the appropriate drivers are loaded. The Gentoo Installation CDs are maintained by Gentoo developers. There currently are two Installation CDs available:
2.c. Download, Burn and Boot the Gentoo Linux Installer LiveCD Downloading and Burning the Installer LiveCD You can download the Installer LiveCDs from one of our mirrors. They are located in the releases/x86/2006.0/livecd directory. Inside that directory you'll find an ISO-file. That is a full CD image which you can write on a CD-R. After downloading the file, you can verify its integrity to see if it is corrupted or not:
To fetch our public key using the GnuPG application, run the following command:
Now verify the signature:
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.
Once you have burned your LiveCD, it is time to boot it. Remove all CDs from your CD drives, reboot your system and enter the BIOS. This is usually done by hitting DEL, F1 or ESC, depending on your BIOS. Inside the BIOS, change the boot order so that the CD-ROM is tried before the hard disk. This is often found under "CMOS Setup". If you don't do this, your system will just reboot from the hard disk, ignoring the CD-ROM. Now place the LiveCD in the CD-ROM drive and reboot. You should see a boot prompt. At this screen, you can hit Enter to begin the boot process with the default boot options, or boot the LiveCD with custom boot options by specifying a kernel followed by boot options and then hitting Enter. Specifying a kernel? Yes, we provide several kernels on our LiveCD. The default one is gentoo. Other kernels are for specific hardware needs and the -nofb variants which disable framebuffer. Below you'll find a short overview on the available kernels:
You can also provide kernel options. They represent optional settings you can (de)activate at will. The following list is the same as the one you receive when you press F2 through F7 at the bootscreen.
Now boot your CD, select a kernel (if you are not happy with the default gentoo kernel) and boot options. As an example, we show you how to boot the gentoo kernel, with dopcmcia as kernel parameters:
You will then be greeted with a boot screen and progress bar. If you are installing Gentoo on a system with a non-US keyboard, make sure you immediately press Alt-F1 to switch to verbose mode and follow the prompt. If no selection is made in 10 seconds the default (US keyboard) will be accepted and the boot process will continue. Once the boot process completes, Gnome will start up and you will be automatically logged in to the "Live" Gentoo Linux system as "gentoo" in graphical mode. You will be logged in as "root", the superuser on the other consoles and should have a root ("#") prompt there. You can switch to those consoles by pressing Alt-F2, Alt-F3, Alt-F4 Alt-F5, Alt-F6. Get back to the graphical desktop you started on by pressing Alt-F7. To switch to other consoles from within X, you must prefix the above with Ctrl. You are able to run commands as root from any terminal within the graphical environment by using the sudo application. You can even become root within a terminal to perform multiple tasks.
When the LiveCD boots, it tries to detect all your hardware devices and loads the appropriate kernel modules to support your hardware. In the vast majority of cases, it does a very good job. However, in some cases, it may not auto-load the kernel modules you need. If the PCI auto-detection missed some of your system's hardware, you will have to load the appropriate kernel modules manually. These tasks require root access. In the next example we try to load the 8139too module (support for certain kinds of network interfaces):
If you need PCMCIA support, you should start the pcmcia init script:
Optional: Tweaking Hard Disk Performance If you are an advanced user, you might want to tweak the IDE hard disk performance using hdparm. You will need root access to use hdparm. With the -tT options you can test the performance of your disk (execute it several times to get a more precise impression):
To tweak, you can use any of the following examples (or experiment yourself) which use /dev/hda as disk (substitute with your disk):
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. You need root access to change the root password and add new users. To change the root password, use the passwd utility:
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".
You can change your user id from root to the newly created user by using su:
You can also change the password for the "gentoo" user in the graphical environment. This account is already suitable for use on the Internet.
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 links to read it:
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 links 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):
You can go back to your original window by pressing Alt-F7. You can now choose to proceed by using the GTK+ based installer (which needs X) or the Dialog based installer that can be run on a console. 3. Using the GTK+ based Gentoo Linux InstallerOnce the Gentoo Linux Installer (GLI) has finished loading, you will be greeted by the welcome screen. It provides a friendly introduction to the process of installing Gentoo on your computer. Remember to read each option carefully. There is detailed help available for each step of installation; just click Help in the lower left corner of the installer. We recommend that you always read the help pages before making your choices. Note that at any time during the installation process, you can save your configuration progress in case you need to resume your installation at a later time. 3.b. Pre-installation Configuration Optional: Manual Network Configuration In the next section, you are required to configure your network. The Installer should have already detected and set up your network for you, but if it didn't, you can manually configure your network. On the Misc. tab, you can specify a location of your choice or keep the default of /var/log/installer.log where the Installer will store its logs. If you wish to enable SSH access to the machine, you can start sshd and specify a root password. Optional: Load Additional Kernel Modules If you need to load more kernel modules to support your hardware, enter their names into the appropriate line, each separated by a space.
In order to install Gentoo on your machine, you will need to prepare your disks. The Partitioning screen will show you a list of detected disks and allow you to specify the filesystems you would like to have on your partitions. Clicking Clear partitions will erase all previous partitions on your disk, so be careful with this option! It is also possible to resize certain partition types. If you choose to go with the Recommended layout, the installer will create three partitions: 100MB for /boot, a /swap partition up to 512MB in size, and the rest of the available space on the disk is used for /, the root partition. If you have more than 4GB of unpartitioned space, using the "Recommended layout" will automatically configure your partitions without destroying any data on any existing partitions. Optional: Define network mounts This screen lets you set up and use any existing network mounts during and after installation. Click New to begin configuration. At this time, only NFS is supported. Since you are performing an installation without an internet connection, you must check GRP Install as well as Dynamic from the options present. Everything you need to build your system will then be generated from the files on the LiveCD.
You must choose Snapshot on this screen. The installer will automatically install a Portage tree from the LiveCD once you select Snapshot; you do not need to specify a snapshot URI. Since you are performing a GRP/networkless install, you will not be allowed to select USE flags before installation. However, you are free to set your own USE flags in /etc/make.conf after you have rebooted into your finished system. You should, however, select your processor type in the CFLAGS section along with any custom optimizations you may want, such as -O2 and -pipe. Any other options you wish to set for future use should be selected now. Use unstable (~arch) will allow you to use packages from the unstable branch of the Portage tree. Build binary packages creates ready-to-install binary tarballs of all packages you compile on your system. DistCC allows you to share the burden of compiling with another computer via your network connection. ccache saves compiled code for later use, and thus can greatly speed up compilation time if you re-install the same package. You will not be allowed to change your CHOST, as this can seriously damage your installation. In MAKEOPTS you define how many parallel compilations should occur when you install a package. A good choice is the number of CPUs in your system plus one, but this guideline isn't always perfect. On a uniprocessor system, -j2 might be used. You must use the kernel present on the LiveCD for the GRP/networkless install. This is merely a gentoo-sources kernel compiled by genkernel, Gentoo's automated kernel compilation utility and will give you a kernel that automatically detects and configures your hardware upon boot. If you want to have a nifty background image during system boot, select the Enable bootsplash option. This screen allows to you choose your bootloader and, optionally, specify additional kernel parameters that will be used at bootup. You may specify which disk to boot from by choosing the appropriate option from Boot Drive. In Linux, the first IDE disk in your system is called hda, the second IDE disk is hdb, and so on. If you have SATA or SCSI disks, they will be called sda, sdb, etc. Please make the correct selection for your system. If you need to pass any additional options to the kernel, such as video and/or VGA statements, simply add them to the "Extra kernel parameters" section. If you jumpered your harddrive because the BIOS can't handle large harddrives you'll need to append hdx=stroke. If you have SCSI devices, you should add doscsi as a kernel option. Study the map and select the region closest to your actual location. Later, you will be asked to select if you want your clock to be set to UTC or local time. On this screen, you will be able to configure the various network interface devices on your computer. Read the available options carefully. On the Hostname/Proxy Information/Other tab, you will need to choose a hostname for your machine. You may also specify proxy server and DNS settings if needed. Cron daemons are helpful programs that run tasks at scheduled times. While you do not need to install one, they can be quite useful. A system logger is a necessity for any Linux operating system. Make your selection from the available choices. Optional: installing extra packages The LiveCD contains a number of available pre-built packages. If you wish to install any of them, check the appropriate box.
This screen allows you to choose various services to load at system boot. Study the available options and their descriptions carefully, and then select your desired services. For example, if you have chosen to install xorg-x11 and want to boot straight into a graphical desktop, then you would select "xdm" from the list. Now you will be able to change various settings, including keyboard layout, graphical display manager, the default editor, and whether to set your hardware clock to UTC or local time. First set the root password for the system administrator (the root user). We strongly recommend that you create a regular user for daily work. Working as root all the time is dangerous and should be avoided! Create your users, add them to the appropriate groups, and set their passwords. You can optionally change their home directories, select their login shell, and set helpful comments. Please take the time to double-check each step of the installation process, ensuring that your system is properly configured. When you have finished reviewing, you may save your progress and exit, or click Install to begin automatically installing Gentoo. You are free to browse around on the LiveCD while the installation proceeds. The installer window will alert you when it has finished. At that point, can close the window by clicking the x in the top right corner. When you are ready, you may log out and reboot. Make sure you remove the LiveCD during the reboot. Congratulations, your system is now fully equipped! Continue with Where to go from here? to learn more about Gentoo. 4. Using the Dialog based Gentoo Linux InstallerAfter you boot the Gentoo Linux Installer LiveCD, it will attempt to load a graphical desktop. If it is unable to do so, it will instead display a command line prompt. To launch the installer, simply type:
Once the installer has finished loading, you will be greeted by the welcome screen. It provides a friendly introduction to the process of installing Gentoo on your computer. Remember to read each option carefully. There is detailed help available for each step of installation at the top of the screen. We recommend that you always read the help provided before making your choices. Note that at any time during the installation process, you can save your configuration progress in case you need to resume your installation at a later time. Use the Tab key (on your keyboard) to move around the menus within a screen and the Enter key to confirm an action. In order to install Gentoo on your machine, you will need to prepare your disks. The Partitioning screen will show you a list of detected disks and allow you to specify the filesystems you would like to have on your partitions. Selecting Clear partitions will erase all previous partitions on your disk, so be careful with this option! It is also possible to resize certain partition types. If you choose to go with the Recommended layout, the installer will create three partitions: 100MB for /boot, a /swap partition up to 512MB in size, and the rest of the available space on the disk is used for /, the root partition. If you have more than 4GB of unpartitioned space, using the "Recommended layout" will automatically configure your partitions without destroying any data on any existing partitions. Optional: Define network mounts This screen lets you set up and use any existing network mounts during and after installation. Select New to begin configuration. At this time, only NFS is supported. Since you are performing an installation without an internet connection, you must select GRP from the stage options present. Then, on the next screen, select Create from CD. Everything you need to build your system will then be generated from the files on the LiveCD.
You must use the kernel present on the LiveCD for the GRP/networkless install. This is merely a gentoo-sources kernel compiled by genkernel, Gentoo's automated compilation utility, and will give you a kernel that automatically detects and configures your hardware upon boot. Select LiveCD kernel and continue to the next screen. This screen allows to you choose your bootloader. The installer will automatically configure your choice. Study the list and select the region closest to your actual location. On this screen, you will be able to configure the various network interface devices detected on your computer. Read the available options carefully. The next screen gives you a choice between DHCP and manual IP address configuration. Once your network interface is properly configured, you will need to create a hostname for your system. Optionally, you may specify a domainname and any DNS server information needed. Optional: installing extra packages The LiveCD contains a number of available pre-built packages. If you wish to install any of them, check the appropriate box.
First set the root password for the system administrator (the root user). We strongly recommend that you create a regular user for daily work. Working as root all the time is dangerous and should be avoided! Create your users, set their passwords, and add them to the appropriate groups. You can optionally change their home directories, select their login shell, and set helpful comments. Please take the time to double-check each step of the installation process, ensuring that your system is properly configured. When you have finished reviewing, you may save your progress and exit, or select Install to begin automatically installing Gentoo. The installer will alert you when it has finished. It will then return you to the command prompt. All you need to do to reboot is type:
Congratulations, your system is now fully equipped! Continue with Where to go from here? to learn more about Gentoo. 5. Where to go from here?Congratulations! You now have a working Gentoo system. But where to go from here? What are your options now? What to explore first? Gentoo provides its users with lots of possibilities, and therefore lots of documented (and less documented) features. You should definitely take a look at the next part of the Gentoo Handbook entitled Working with Gentoo which explains how to keep your software up to date, how to install more software, what USE flags are, how the Gentoo Init system works, etc. If you are interested in optimizing your system for desktop use, or you want to learn how to configure your system to be a full working desktop system, consult our extensive Gentoo Desktop Documentation Resources. Besides, you might want to use our localization guide to make your system feel more at home. We also have a Gentoo Security Handbook which is worth reading. For a full listing of all our available documentation check out our Documentation Resources page. You are of course always welcome on our Gentoo Forums or on one of our many Gentoo IRC channels. We also have several mailinglists open to all our users. Information on how to join is contained in that page. We'll shut up now and let you enjoy your installation :) 5.c. Gentoo Changes since 2006.0 Gentoo is a fast-moving target. The following sections describe important changes that affect a Gentoo installation. We only list those that have anything in common with the installation, not with package changes that did not occur during the installation. There have been no significant changes since. B. Working with Gentoo1. A Portage IntroductionPortage is probably Gentoo's most notable innovation in software management. With its high flexibility and enormous amount of features it is frequently seen as the best software management tool available for Linux. Portage is completely written in Python and Bash and therefore fully visible to the users as both are scripting languages. Most users will work with Portage through the emerge tool. This chapter is not meant to duplicate the information available from the emerge man page. For a complete rundown of emerge's options, please consult the man page:
When we talk about packages, we often mean software titles that are available to the Gentoo users through the Portage tree. The Portage tree is a collection of ebuilds, files that contain all information Portage needs to maintain software (install, search, query, ...). These ebuilds reside in /usr/portage by default. Whenever you ask Portage to perform some action regarding software titles, it will use the ebuilds on your system as a base. It is therefore important that you regularly update the ebuilds on your system so Portage knows about new software, security updates, etc. The Portage tree is usually updated with rsync, a fast incremental file transfer utility. Updating is fairly simple as the emerge command provides a front-end for rsync:
If you are unable to rsync due to firewall restrictions you can still update your Portage tree by using our daily generated Portage tree snapshots. The emerge-webrsync tool automatically fetches and installs the latest snapshot on your system:
An additional advantage of using emerge-webrsync is that it allows the administrator to only pull in portage tree snapshots that are signed by the Gentoo release engineering GPG key. More information on this can be found in the Portage Features section on Fetching Validated Portage Tree Snapshots. To search through the Portage tree after software titles, you can use emerge built-in search capabilities. By default, emerge --search returns the names of packages whose title matches (either fully or partially) the given search term. For instance, to search for all packages who have "pdf" in their name:
If you want to search through the descriptions as well you can use the --searchdesc (or -S) switch:
When you take a look at the output, you'll notice that it gives you a lot of information. The fields are clearly labelled so we won't go further into their meanings:
Once you've found a software title to your liking, you can easily install it with emerge: just add the package name. For instance, to install gnumeric:
Since many applications depend on each other, any attempt to install a certain software package might result in the installation of several dependencies as well. Don't worry, Portage handles dependencies well. If you want to find out what Portage would install when you ask it to install a certain package, add the --pretend switch. For instance:
When you ask Portage to install a package, it will download the necessary source code from the internet (if necessary) and store it by default in /usr/portage/distfiles. After this it will unpack, compile and install the package. If you want Portage to only download the sources without installing them, add the --fetchonly option to the emerge command:
Finding Installed Package Documentation Many packages come with their own documentation. Sometimes, the doc USE flag determines whether the package documentation should be installed or not. You can check the existence of a doc USE flag with the emerge -vp <package name> command.
The best way of enabling the doc USE flag is doing it on a per-package basis via /etc/portage/package.use, so that you get documentation only for packages that you are interested in. Enabling this flag globally is known to cause problems with circular dependencies. For more information, please read the USE Flags chapter. Once the package installed, its documentation is generally found in a subdirectory named after the package under the /usr/share/doc directory. You can also list all installed files with the equery tool which is part of the app-portage/gentoolkit package.
When you want to remove a software package from your system, use emerge --unmerge. This will tell Portage to remove all files installed by that package from your system except the configuration files of that application if you have altered those after the installation. Leaving the configuration files allows you to continue working with the package if you ever decide to install it again. However, a big warning applies: Portage will not check if the package you want to remove is required by another package. It will however warn you when you want to remove an important package that breaks your system if you unmerge it.
When you remove a package from your system, the dependencies of that package that were installed automatically when you installed the software are left. To have Portage locate all dependencies that can now be removed, use emerge's --depclean functionality. We will talk about this later on. To keep your system in perfect shape (and not to mention install the latest security updates) you need to update your system regularly. Since Portage only checks the ebuilds in your Portage tree you first have to update your Portage tree. When your Portage tree is updated, you can update your system with emerge --update world. In the next example, we'll also use the --ask switch which will tell Portage to display the list of packages it wants to upgrade and ask you if you want to continue:
Portage will then search for newer version of the applications you have installed. However, it will only verify the versions for the applications you have explicitly installed (the applications listed in /var/lib/portage/world) - it does not thoroughly check their dependencies. If you want to update the dependencies of those packages as well, add the --deep argument:
Still, this doesn't mean all packages: some packages on your system are needed during the compile and build process of packages, but once that package is installed, these dependencies are no longer required. Portage calls those build dependencies. To include those in an update cycle, add --with-bdeps=y:
Since security updates also happen in packages you have not explicitly installed on your system (but that are pulled in as dependencies of other programs), it is recommended to run this command once in a while. If you have altered any of your USE flags lately you might want to add --newuse as well. Portage will then verify if the change requires the installation of new packages or recompilation of existing ones:
Some packages in the Portage tree don't have any real content but are used to install a collection of packages. For instance, the kde-meta package will install a complete KDE environment on your system by pulling in various KDE-related packages as dependencies. If you ever want to remove such a package from your system, running emerge --unmerge on the package won't have much effect as the dependencies remain on the system. Portage has the functionality to remove orphaned dependencies as well, but since the availability of software is dynamically dependent you first need to update your entire system fully, including the new changes you applied when changing USE flags. After this you can run emerge --depclean to remove the orphaned dependencies. When this is done, you need to rebuild the applications that were dynamically linked to the now-removed software titles but don't require them anymore. All this is handled with the following three commands:
revdep-rebuild is provided by the gentoolkit package; don't forget to emerge it first:
Beginning with Portage version 2.1.7, you can accept or reject software installation based on its license. All packages in the tree contain a LICENSE entry in their ebuilds. Running emerge --search packagename will tell you the package's license. By default, Portage permits all licenses, except End User License Agreements (EULAs) that require reading and signing an acceptance agreement. The variable that controls permitted licenses is ACCEPT_LICENSE, which can be set in /etc/portage/make.conf:
With this configuration, packages that require interaction during installation to approve their EULA will not be installed. Packages without an EULA will be installed. You can set ACCEPT_LICENSE globally in /etc/portage/make.conf , or you can specify it on a per-package basis in /etc/portage/package.license. For example, if you want to allow the truecrypt-2.7 license for app-crypt/truecrypt, add the following to /etc/portage/package.license:
This permits installation of truecrypt versions that have the truecrypt-2.7 license, but not versions with the truecrypt-2.8 license.
License groups defined in ACCEPT_LICENSE are prefixed with an @ sign. Here's an example of a system that globally permits the GPL-compatible license group, as well as a few other groups and individual licenses:
If you want only free software and documentation on your system, you might use the following setup:
In this case, "free" is mostly defined by the FSF and OSI. Any package whose license does not meet these requirements will not be installed on your system. 1.e. When Portage is Complaining... About SLOTs, Virtuals, Branches, Architectures and Profiles As we stated before, Portage is extremely powerful and supports many features that other software management tools lack. To understand this, we explain a few aspects of Portage without going into too much detail. With Portage different versions of a single package can coexist on a system. While other distributions tend to name their package to those versions (like freetype and freetype2) Portage uses a technology called SLOTs. An ebuild declares a certain SLOT for its version. Ebuilds with different SLOTs can coexist on the same system. For instance, the freetype package has ebuilds with SLOT="1" and SLOT="2". There are also packages that provide the same functionality but are implemented differently. For instance, metalogd, sysklogd and syslog-ng are all system loggers. Applications that rely on the availability of "a system logger" cannot depend on, for instance, metalogd, as the other system loggers are as good a choice as any. Portage allows for virtuals: each system logger is listed as an "exclusive" dependency of the logging service in the logger virtual package of the virtual category, so that applications can depend on the virtual/logger package. When installed, the package will pull in the first logging package mentioned in the package, unless a logging package was already installed (in which case the virtual is satisfied). Software in the Portage tree can reside in different branches. By default your system only accepts packages that Gentoo deems stable. Most new software titles, when committed, are added to the testing branch, meaning more testing needs to be done before it is marked as stable. Although you will see the ebuilds for those software in the Portage tree, Portage will not update them before they are placed in the stable branch. Some software is only available for a few architectures. Or the software doesn't work on the other architectures, or it needs more testing, or the developer that committed the software to the Portage tree is unable to verify if the package works on different architectures. Each Gentoo installation adheres to a certain profile which contains, amongst other information, the list of packages that are required for a system to function normally.
Ebuilds contain specific fields that inform Portage about its dependencies. There are two possible dependencies: build dependencies, declared in DEPEND and run-time dependencies, declared in RDEPEND. When one of these dependencies explicitly marks a package or virtual as being not compatible, it triggers a blockage. While recent versions of Portage are smart enough to work around minor blockages without user intervention, occasionally you will need to fix it yourself, as explained below. To fix a blockage, you can choose to not install the package or unmerge the conflicting package first. In the given example, you can opt not to install postfix or to remove ssmtp first. You may also see blocking packages with specific atoms, such as <media-video/mplayer-1.0_rc1-r2. In this case, updating to a more recent version of the blocking package would remove the block. It is also possible that two packages that are yet to be installed are blocking each other. In this rare case, you should find out why you need to install both. In most cases you can do with one of the packages alone. If not, please file a bug on Gentoo's bugtracking system.
When you want to install a package that isn't available for your system, you will receive this masking error. You should try installing a different application that is available for your system or wait until the package is put available. There is always a reason why a package is masked:
The error message might also be displayed as follows, if --autounmask isn't set:
Such warning or error occurs when you want to install a package which not only depends on another package, but also requires that that package is built with a particular USE flag (or set of USE flags). In the given example, the package app-text/feelings needs to be built with USE="test", but this USE flag is not set on the system. To resolve this, either add the requested USE flag to your global USE flags in /etc/portage/make.conf, or set it for the specific package in /etc/portage/package.use.
The application you are trying to install depends on another package that is not available for your system. Please check bugzilla if the issue is known and if not, please report it. Unless you are mixing branches this should not occur and is therefore a bug.
The application you want to install has a name that corresponds with more than one package. You need to supply the category name as well. Portage will inform you of possible matches to choose from.
Two (or more) packages you want to install depend on each other and can therefore not be installed. This is most likely a bug in the Portage tree. Please resync after a while and try again. You can also check bugzilla if the issue is known and if not, report it.
Portage was unable to download the sources for the given application and will try to continue installing the other applications (if applicable). This failure can be due to a mirror that has not synchronised correctly or because the ebuild points to an incorrect location. The server where the sources reside can also be down for some reason. Retry after one hour to see if the issue still persists.
You have asked to remove a package that is part of your system's core packages. It is listed in your profile as required and should therefore not be removed from the system. Sometimes, when you attempt to emerge a package, it will fail with the message:
This is a sign that something is wrong with the Portage tree -- often, it is because a developer may have made a mistake when committing a package to the tree. When the digest verification fails, do not try to re-digest the package yourself. Running ebuild foo manifest will not fix the problem; it will almost certainly make it worse! Instead, wait an hour or two for the tree to settle down. It's likely that the error was noticed right away, but it can take a little time for the fix to trickle down the Portage tree. While you're waiting, check Bugzilla and see if anyone has reported the problem yet. If not, go ahead and file a bug for the broken package. Once you see that the bug has been fixed, you may want to re-sync to pick up the fixed digest.
2. USE flagsWhen you are installing Gentoo (or any other distribution, or even operating system for that matter) you make choices depending on the environment you are working with. A setup for a server differs from a setup for a workstation. A gaming workstation differs from a 3D rendering workstation. This is not only true for choosing what packages you want to install, but also what features a certain package should support. If you don't need OpenGL, why would you bother installing OpenGL and build OpenGL support in most of your packages? If you don't want to use KDE, why would you bother compiling packages with KDE support if those packages work flawlessly without? To help users in deciding what to install/activate and what not, we wanted the user to specify his/her environment in an easy way. This forces the user into deciding what they really want and eases the process for Portage, our package management system, to make useful decisions. Enter the USE flags. Such a flag is a keyword that embodies support and dependency-information for a certain concept. If you define a certain USE flag, Portage will know that you want support for the chosen keyword. Of course this also alters the dependency information for a package. Let us take a look at a specific example: the kde keyword. If you do not have this keyword in your USE variable, all packages that have optional KDE support will be compiled without KDE support. All packages that have an optional KDE dependency will be installed without installing the KDE libraries (as dependency). If you have defined the kde keyword, then those packages will be compiled with KDE support, and the KDE libraries will be installed as dependency. By correctly defining the keywords you will receive a system tailored specifically to your needs. There are two types of USE flags: global and local USE flags.
A list of available global USE flags can be found online or locally in /usr/portage/profiles/use.desc. A list of available local USE flags can be found locally in /usr/portage/profiles/use.local.desc. In the hope you are convinced of the importance of USE flags we will now inform you how to declare USE flags. As previously mentioned, all USE flags are declared inside the USE variable. To make it easy for users to search and pick USE flags, we already provide a default USE setting. This setting is a collection of USE flags we think are commonly used by the Gentoo users. This default setting is declared in the make.defaults files part of your profile. The profile your system listens to is pointed to by the /etc/portage/make.profile symlink. Each profile works on top of another, larger profile, the end result is therefore the sum of all profiles. The top profile is the base profile (/usr/portage/profiles/base). Let us take a look at this default setting for the 13.0 profile:
As you can see, this variable already contains quite a lot of keywords. Do not alter any make.defaults file to tailor the USE variable to your needs: changes in this file will be undone when you update Portage! To change this default setting, you need to add or remove keywords to the USE variable. This is done globally by defining the USE variable in /etc/portage/make.conf. In this variable you add the extra USE flags you require, or remove the USE flags you don't want. This latter is done by prefixing the keyword with the minus-sign ("-"). For instance, to remove support for KDE and QT but add support for ldap, the following USE can be defined in /etc/portage/make.conf:
Declaring USE flags for individual packages Sometimes you want to declare a certain USE flag for one (or a couple) of applications but not system-wide. To accomplish this, you will need to create the /etc/portage directory (if it doesn't exist yet) and edit /etc/portage/package.use. This is usually a single file, but can also be a directory; see man portage for more information. The following examples assume package.use is a single file. For instance, if you don't want berkdb support globally but you do want it for mysql, you would add:
You can of course also explicitly disable USE flags for a certain application. For instance, if you don't want java support in PHP:
Sometimes you want to set a certain USE setting only once. Instead of editing /etc/portage/make.conf twice (to do and undo the USE changes) you can just declare the USE variable as environment variable. Remember that, when you re-emerge or update this application (either explicitly or as part of a system update) your changes will be lost! As an example we will temporarily remove java from the USE setting during the installation of seamonkey.
Of course there is a certain precedence on what setting has priority over the USE setting. You don't want to declare USE="-java" only to see that java is still used due to a setting that has a higher priority. The precedence for the USE setting is, ordered by priority (first has lowest priority):
To view the final USE setting as seen by Portage, run emerge --info. This will list all relevant variables (including the USE variable) with the content used by Portage.
Adapting your Entire System to New USE Flags If you have altered your USE flags and you wish to update your entire system to use the new USE flags, use emerge's --newuse option:
Next, run Portage's depclean to remove the conditional dependencies that were emerged on your "old" system but that have been obsoleted by the new USE flags.
When depclean has finished, run revdep-rebuild to rebuild the applications that are dynamically linked against shared objects provided by possibly removed packages. revdep-rebuild is part of the gentoolkit package; don't forget to emerge it first.
When all this is accomplished, your system is using the new USE flag settings. 2.c. Package specific USE flags Let us take the example of seamonkey: what USE flags does it listen to? To find out, we use emerge with the --pretend and --verbose options:
emerge isn't the only tool for this job. In fact, we have a tool dedicated to package information called equery which resides in the gentoolkit package. First, install gentoolkit:
Now run equery with the uses argument to view the USE flags of a certain package. For instance, for the gnumeric package:
3. Portage FeaturesPortage has several additional features that makes your Gentoo experience even better. Many of these features rely on certain software tools that improve performance, reliability, security, ... To enable or disable certain Portage features you need to edit /etc/portage/make.conf's FEATURES variable which contains the various feature keywords, separated by white space. In several cases you will also need to install the additional tool on which the feature relies. Not all features that Portage supports are listed here. For a full overview, please consult the make.conf man page:
To find out what FEATURES are default set, run emerge --info and search for the FEATURES variable or grep it out:
distcc is a program to distribute compilations across several, not necessarily identical, machines on a network. The distcc client sends all necessary information to the available distcc servers (running distccd) so they can compile pieces of source code for the client. The net result is a faster compilation time. You can find more information about distcc (and how to have it work with Gentoo) in our Gentoo Distcc Documentation. Distcc ships with a graphical monitor to monitor tasks that your computer is sending away for compilation. If you use Gnome then put 'gnome' in your USE variable. However, if you don't use Gnome and would still like to have the monitor then you should put 'gtk' in your USE variable.
Add distcc to the FEATURES variable inside /etc/portage/make.conf. Next, edit the MAKEOPTS variable to your liking. A known guideline is to fill in "-jX" with X the number of CPUs that run distccd (including the current host) plus one, but you might have better results with other numbers. Now run distcc-config and enter the list of available distcc servers. For a simple example we assume that the available DistCC servers are 192.168.1.102 (the current host), 192.168.1.103 and 192.168.1.104 (two "remote" hosts):
Don't forget to run the distccd daemon as well:
ccache is a fast compiler cache. When you compile a program, it will cache intermediate results so that, whenever you recompile the same program, the compilation time is greatly reduced. The first time you run ccache, it will be much slower than a normal compilation. Subsequent recompiles should be faster. ccache is only helpful if you will be recompiling the same application many times; thus it's mostly only useful for software developers. If you are interested in the ins and outs of ccache, please visit the ccache homepage.
To install ccache, run emerge ccache:
Open /etc/portage/make.conf and add ccache to the FEATURES variable. Next, add a new variable called CCACHE_SIZE and set it to "2G":
To check if ccache functions, ask ccache to provide you with its statistics. Because Portage uses a different ccache home directory, you need to set the CCACHE_DIR variable as well:
The /var/tmp/ccache location is Portage' default ccache home directory; if you want to alter this setting you can set the CCACHE_DIR variable in /etc/portage/make.conf. However, if you would run ccache, it would use the default location of ${HOME}/.ccache, which is why you needed to set the CCACHE_DIR variable when asking for the (Portage) ccache statistics. Using ccache for non-Portage C Compiling If you would like to use ccache for non-Portage compilations, add /usr/lib/ccache/bin to the beginning of your PATH variable (before /usr/bin). This can be accomplished by editing .bash_profile in your user's home directory. Using .bash_profile is one way to define PATH variables.
Portage supports the installation of prebuilt packages. Even though Gentoo does not provide prebuilt packages by itself (except for the GRP snapshots) Portage can be made fully aware of prebuilt packages. To create a prebuilt package you can use quickpkg if the package is already installed on your system, or emerge with the --buildpkg or --buildpkgonly options. If you want Portage to create prebuilt packages of every single package you install, add buildpkg to the FEATURES variable. More extended support for creating prebuilt package sets can be obtained with catalyst. For more information on catalyst please read the Catalyst Frequently Asked Questions. Although Gentoo doesn't provide one, you can create a central repository where you store prebuilt packages. If you want to use this repository, you need to make Portage aware of it by having the PORTAGE_BINHOST variable point to it. For instance, if the prebuilt packages are on ftp://buildhost/gentoo:
When you want to install a prebuilt package, add the --getbinpkg option to the emerge command alongside of the --usepkg option. The former tells emerge to download the prebuilt package from the previously defined server while the latter asks emerge to try to install the prebuilt package first before fetching the sources and compiling it. For instance, to install gnumeric with prebuilt packages:
More information about emerge's prebuilt package options can be found in the emerge man page:
When you are emerging a series of packages, Portage can fetch the source files for the next package in the list even while it is compiling another package, thus shortening compile times. To make use of this capability, add "parallel-fetch" to your FEATURES. Note that this is on by default, so you shouldn't need to specifically enable it. When Portage is run as root, FEATURES="userfetch" will allow Portage to drop root privileges while fetching package sources. This is a small security improvement. 3.f. Pulling Validated Portage Tree Snapshots As an administrator, you can opt to only update your local Portage tree with a cryptographically validated Portage tree snapshot as released by the Gentoo infrastructure. This ensures that no rogue rsync mirror is adding unwanted code or packages in the tree you are downloading. To configure Portage, first create a truststore in which you download and accept the keys of the Gentoo Infrastructure responsible for signing the Portage tree snapshots. Of course, if you want to, you can validate this GPG key as per the proper guidelines (like checking the key fingerprint). You can find the list of GPG keys used by the release engineering team on their project page.
Next, edit /etc/portage/make.conf and enable support for validating the signed Portage tree snapshots (using FEATURES="webrsync-gpg") and disabling updating the Portage tree using the regular emerge --sync method.
That's it. Next time you run emerge-webrsync, only the snapshots with a valid signature will be expanded on your file system. 4. InitscriptsWhen you boot your system, you will notice lots of text floating by. If you pay close attention, you will notice this text is the same every time you reboot your system. The sequence of all these actions is called the boot sequence and is (more or less) statically defined. First, your boot loader will load the kernel image you have defined in the boot loader configuration into memory after which it tells the CPU to run the kernel. When the kernel is loaded and run, it initializes all kernel-specific structures and tasks and starts the init process. This process then makes sure that all filesystems (defined in /etc/fstab) are mounted and ready to be used. Then it executes several scripts located in /etc/init.d, which will start the services you need in order to have a successfully booted system. Finally, when all scripts are executed, init activates the terminals (in most cases just the virtual consoles which are hidden beneath Alt-F1, Alt-F2, etc.) attaching a special process called agetty to it. This process will then make sure you are able to log on through these terminals by running login. Now init doesn't just execute the scripts in /etc/init.d randomly. Even more, it doesn't run all scripts in /etc/init.d, only the scripts it is told to execute. It decides which scripts to execute by looking into /etc/runlevels. First, init runs all scripts from /etc/init.d that have symbolic links inside /etc/runlevels/boot. Usually, it will start the scripts in alphabetical order, but some scripts have dependency information in them, telling the system that another script must be run before they can be started. When all /etc/runlevels/boot referenced scripts are executed, init continues with running the scripts that have a symbolic link to them in /etc/runlevels/default. Again, it will use the alphabetical order to decide what script to run first, unless a script has dependency information in it, in which case the order is changed to provide a valid start-up sequence. Of course init doesn't decide all that by itself. It needs a configuration file that specifies what actions need to be taken. This configuration file is /etc/inittab. If you remember the boot sequence we have just described, you will remember that init's first action is to mount all filesystems. This is defined in the following line from /etc/inittab:
This line tells init that it must run /sbin/rc sysinit to initialize the system. The /sbin/rc script takes care of the initialisation, so you might say that init doesn't do much -- it delegates the task of initialising the system to another process. Second, init executed all scripts that had symbolic links in /etc/runlevels/boot. This is defined in the following line:
Again the rc script performs the necessary tasks. Note that the option given to rc (boot) is the same as the subdirectory of /etc/runlevels that is used. Now init checks its configuration file to see what runlevel it should run. To decide this, it reads the following line from /etc/inittab:
In this case (which the majority of Gentoo users will use), the runlevel id is 3. Using this information, init checks what it must run to start runlevel 3:
The line that defines level 3, again, uses the rc script to start the services (now with argument default). Again note that the argument of rc is the same as the subdirectory from /etc/runlevels. When rc has finished, init decides what virtual consoles it should activate and what commands need to be run at each console:
You have seen that init uses a numbering scheme to decide what runlevel it should activate. A runlevel is a state in which your system is running and contains a collection of scripts (runlevel scripts or initscripts) that must be executed when you enter or leave a runlevel. In Gentoo, there are seven runlevels defined: three internal runlevels, and four user-defined runlevels. The internal runlevels are called sysinit, shutdown and reboot and do exactly what their names imply: initialize the system, powering off the system and rebooting the system. The user-defined runlevels are those with an accompanying /etc/runlevels subdirectory: boot, default, nonetwork and single. The boot runlevel starts all system-necessary services which all other runlevels use. The remaining three runlevels differ in what services they start: default is used for day-to-day operations, nonetwork is used in case no network connectivity is required, and single is used when you need to fix the system. The scripts that the rc process starts are called init scripts. Each script in /etc/init.d can be executed with the arguments start, stop, restart, pause, zap, status, ineed, iuse, needsme, usesme or broken. To start, stop or restart a service (and all depending services), start, stop and restart should be used:
If you want to stop a service, but not the services that depend on it, you can use the pause argument:
If you want to see what status a service has (started, stopped, paused, ...) you can use the status argument:
If the status information tells you that the service is running, but you know that it is not, then you can reset the status information to "stopped" with the zap argument:
To also ask what dependencies the service has, you can use iuse or ineed. With ineed you can see the services that are really necessary for the correct functioning of the service. iuse on the other hand shows the services that can be used by the service, but are not necessary for the correct functioning.
Similarly, you can ask what services require the service (needsme) or can use it (usesme):
Finally, you can ask what dependencies the service requires that are missing:
Gentoo's init system uses a dependency-tree to decide what service needs to be started first. As this is a tedious task that we wouldn't want our users to have to do manually, we have created tools that ease the administration of the runlevels and init scripts. With rc-update you can add and remove init scripts to a runlevel. The rc-update tool will then automatically ask the depscan.sh script to rebuild the dependency tree. You have already added init scripts to the "default" runlevel during the installation of Gentoo. At that time you might not have had a clue what the "default" is for, but now you should. The rc-update script requires a second argument that defines the action: add, del or show. To add or remove an init script, just give rc-update the add or del argument, followed by the init script and the runlevel. For instance:
The rc-update -v show command will show all the available init scripts and list at which runlevels they will execute:
You can also run rc-update show (without -v) to just view enabled init scripts and their runlevels. Why the Need for Extra Configuration? Init scripts can be quite complex. It is therefore not really desirable to have the users edit the init script directly, as it would make it more error-prone. It is however important to be able to configure such a service. For instance, you might want to give more options to the service itself. A second reason to have this configuration outside the init script is to be able to update the init scripts without the fear that your configuration changes will be undone. Gentoo provides an easy way to configure such a service: every init script that can be configured has a file in /etc/conf.d. For instance, the apache2 initscript (called /etc/init.d/apache2) has a configuration file called /etc/conf.d/apache2, which can contain the options you want to give to the Apache 2 server when it is started:
Such a configuration file contains variables and variables alone (just like /etc/portage/make.conf), making it very easy to configure services. It also allows us to provide more information about the variables (as comments). No, writing an init script is usually not necessary as Gentoo provides ready-to-use init scripts for all provided services. However, you might have installed a service without using Portage, in which case you will most likely have to create an init script. Do not use the init script provided by the service if it isn't explicitly written for Gentoo: Gentoo's init scripts are not compatible with the init scripts used by other distributions! The basic layout of an init script is shown below.
Any init script requires the start() function to be defined. All other sections are optional. There are two dependency-alike settings you can define that influence the start-up or sequencing of init scripts: use and need. Next to these two, there are also two order-influencing methods called before and after. These last two are no dependencies per se - they do not make the original init script fail if the selected one isn't scheduled to start (or fails to start).
It should be clear from the above that need is the only "true" dependency setting as it affects if the script will be started or not. All the others are merely pointers towards the init system to clarify in which order scripts can be (or should be) launched. Now, if you look at many of Gentoo's available init scripts, you will notice that some have dependencies on things that are no init scripts. These "things" we call virtuals. A virtual dependency is a dependency that a service provides, but that is not provided solely by that service. Your init script can depend on a system logger, but there are many system loggers available (metalogd, syslog-ng, sysklogd, ...). As you cannot need every single one of them (no sensible system has all these system loggers installed and running) we made sure that all these services provide a virtual dependency. Let us take a look at the dependency information for the postfix service.
As you can see, the postfix service:
As we described in the previous section, you can tell the init system what order it should use for starting (or stopping) scripts. This ordering is handled both through the dependency settings use and need, but also through the order settings before and after. As we have described these earlier already, let's take a look at the Portmap service as an example of such init script.
You can also use the "*" glob to catch all services in the same runlevel, although this isn't advisable.
If your service must write to local disks, it should need localmount. If it places anything in /var/run such as a pidfile, then it should start after bootmisc:
Next to the depend() functionality, you also need to define the start() function. This one contains all the commands necessary to initialize your service. It is advisable to use the ebegin and eend functions to inform the user about what is happening:
Both --exec and --pidfile should be used in start and stop functions. If the service does not create a pidfile, then use --make-pidfile if possible, though you should test this to be sure. Otherwise, don't use pidfiles. You can also add --quiet to the start-stop-daemon options, but this is not recommended unless the service is extremely verbose. Using --quiet may hinder debugging if the service fails to start. Another notable setting used in the above example is to check the contents of the RC_CMD variable. Unlike the previous init script system, the newer openrc system does not support script-specific restart functionality. Instead, the script needs to check the contents of the RC_CMD variable to see if a function (be it start() or stop()) is called as part of a restart or not.
If you need more examples of the start() function, please read the source code of the available init scripts in your /etc/init.d directory. Another function you can define is stop(). You are not obliged to define this function though! Our init system is intelligent enough to fill in this function by itself if you use start-stop-daemon. Here is an example of a stop() function:
If your service runs some other script (for example, bash, python, or perl), and this script later changes names (for example, foo.py to foo), then you will need to add --name to start-stop-daemon. You must specify the name that your script will be changed to. In this example, a service starts foo.py, which changes names to foo:
start-stop-daemon has an excellent man page available if you need more information:
Gentoo's init script syntax is based on the POSIX Shell so you are free to use sh-compatible constructs inside your init script. Keep other constructs, like bash-specific ones, out of the init scripts to ensure that the scripts remain functional regardless of the change Gentoo might do on its init system. If you want your init script to support more options than the ones we have already encountered, you should add the option to the extra_commands variable, and create a function with the same name as the option. For instance, to support an option called restartdelay:
Service Configuration Variables You don't have to do anything to support a configuration file in /etc/conf.d: if your init script is executed, the following files are automatically sourced (i.e. the variables are available to use):
Also, if your init script provides a virtual dependency (such as net), the file associated with that dependency (such as /etc/conf.d/net) will be sourced too. 4.e. Changing the Runlevel Behaviour Many laptop users know the situation: at home you need to start net.eth0 while you don't want to start net.eth0 while you're on the road (as there is no network available). With Gentoo you can alter the runlevel behaviour to your own will. For instance you can create a second "default" runlevel which you can boot that has other init scripts assigned to it. You can then select at boottime what default runlevel you want to use. First of all, create the runlevel directory for your second "default" runlevel. As an example we create the offline runlevel:
Add the necessary init scripts to the newly created runlevels. For instance, if you want to have an exact copy of your current default runlevel but without net.eth0:
Even though net.eth0 has been removed from the offline runlevel, udev might want to attempt to start any devices it detects and launch the appropriate services, a functionality that is called hotplugging. By default, Gentoo does not enable hotplugging. If you do want to enable hotplugging, but only for a selected set of scripts, use the rc_hotplug variable in /etc/rc.conf:
Now edit your bootloader configuration and add a new entry for the offline runlevel. For instance, in /boot/grub/grub.conf:
Voilà, you're all set now. If you boot your system and select the newly added entry at boot, the offline runlevel will be used instead of the default one. Using bootlevel is completely analogous to softlevel. The only difference here is that you define a second "boot" runlevel instead of a second "default" runlevel. 5. Environment VariablesAn environment variable is a named object that contains information used by one or more applications. Many users (and especially those new to Linux) find this a bit weird or unmanageable. However, this is a mistake: by using environment variables one can easily change a configuration setting for one or more applications. The following table lists a number of variables used by a Linux system and describes their use. Example values are presented after the table.
Below you will find an example definition of all these variables:
5.b. Defining Variables Globally To centralise the definitions of these variables, Gentoo introduced the /etc/env.d directory. Inside this directory you will find a number of files, such as 00basic, 05gcc, etc. which contain the variables needed by the application mentioned in their name. For instance, when you installed gcc, a file called 05gcc was created by the ebuild which contains the definitions of the following variables:
Other distributions tell you to change or add such environment variable definitions in /etc/profile or other locations. Gentoo on the other hand makes it easy for you (and for Portage) to maintain and manage the environment variables without having to pay attention to the numerous files that can contain environment variables. For instance, when gcc is updated, the /etc/env.d/05gcc file is updated too without requesting any user-interaction. This not only benefits Portage, but also you, as user. Occasionally you might be asked to set a certain environment variable system-wide. As an example we take the http_proxy variable. Instead of messing about with /etc/profile, you can now just create a file (/etc/env.d/99local) and enter your definition(s) in it:
By using the same file for all your variables, you have a quick overview on the variables you have defined yourself. Several files in /etc/env.d define the PATH variable. This is not a mistake: when you run env-update, it will append the several definitions before it updates the environment variables, thereby making it easy for packages (or users) to add their own environment variable settings without interfering with the already existing values. The env-update script will append the values in the alphabetical order of the /etc/env.d files. The file names must begin with two decimal digits.
The concatenation of variables does not always happen, only with the following variables: ADA_INCLUDE_PATH, ADA_OBJECTS_PATH, CLASSPATH, KDEDIRS, PATH, LDPATH, MANPATH, INFODIR, INFOPATH, ROOTPATH, CONFIG_PROTECT, CONFIG_PROTECT_MASK, PRELINK_PATH, PRELINK_PATH_MASK, PKG_CONFIG_PATH and PYTHONPATH. For all other variables the latest defined value (in alphabetical order of the files in /etc/env.d) is used. You can add more variables into this list of concatenate-variables by adding the variable name to either COLON_SEPARATED or SPACE_SEPARATED variables (also inside an env.d file). When you run env-update, the script will create all environment variables and place them in /etc/profile.env (which is used by /etc/profile). It will also extract the information from the LDPATH variable and use that to create /etc/ld.so.conf. After this, it will run ldconfig to recreate the /etc/ld.so.cache file used by the dynamical linker. If you want to notice the effect of env-update immediately after you run it, execute the following command to update your environment. Users who have installed Gentoo themselves will probably remember this from the installation instructions:
5.c. Defining Variables Locally You do not always want to define an environment variable globally. For instance, you might want to add /home/my_user/bin and the current working directory (the directory you are in) to the PATH variable but don't want all other users on your system to have that in their PATH too. If you want to define an environment variable locally, you should use ~/.bashrc or ~/.bash_profile:
When you relogin, your PATH variable will be updated. Sometimes even stricter definitions are requested. You might want to be able to use binaries from a temporary directory you created without using the path to the binaries themselves or editing ~/.bashrc for the short time you need it. In this case, you can just define the PATH variable in your current session by using the export command. As long as you don't log out, the PATH variable will be using the temporary settings.
C. Working with Portage1. Files and DirectoriesPortage 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 default configuration files which are part of your profile. Your profile is pointed to by the /etc/portage/make.profile symlink; Portage' configurations are set in the make.defaults files of your profile and all parent profiles. We'll explain more about profiles and the /etc/portage/make.profile directory later on. If you're planning on changing a configuration variable, don't alter /etc/make.globals or make.defaults. Instead use /etc/portage/make.conf which has precedence over the previous files. You'll also find a /usr/share/portage/config/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. We've already encountered the /etc/portage/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. 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:
These don't have to be files; they can also be directories that contain one file per package. 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:
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/portage/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:
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/portage/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. 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. Application source code is stored in /usr/portage/distfiles by default. This location is defined by the DISTDIR variable. Portage stores the state of your system (what packages are installed, what files belong to which package, ...) in /var/db/pkg. Do not alter these files manually! It might break Portage's knowledge of your system. The Portage cache (with modification times, virtuals, dependency tree information, ...) is stored in /var/cache/edb. This location really is a cache: you can clean it if you are not running any portage-related application at that moment. 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. Portage creates specific build directories for each package it emerges inside /var/tmp/portage. This location is defined by the BUILD_PREFIX variable. 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. 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. If you don't set PORT_LOGDIR, then you won't receive any build logs with the current logging system, though you may receive some logs from the new elog. If you do have PORT_LOGDIR defined and you use elog, you will receive build logs and any logs saved by elog, as explained below. Portage offers fine-grained control over logging through the use of elog:
2. Configuring through VariablesAs noted previously, Portage is configurable through many variables which you should define in /etc/portage/make.conf. Please refer to the make.conf man page for more and complete information:
Configure and Compiler Options When Portage builds applications, it passes the contents of the following variables to the compiler and configure script:
The USE variable is also used during configure and compilations but has been explained in great detail in previous chapters. 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. You can tell emerge to use certain options every time it is run by setting EMERGE_DEFAULT_OPTS. Some useful options would be --ask, --verbose, --tree, and so on. 2.c. Configuration File Protection 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:
More information about Portage's Configuration File Protection is available in the CONFIGURATION FILES section of the emerge manpage:
To 'unprotect' certain subdirectories of protected locations you can use the CONFIG_PROTECT_MASK variable. 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:
A third setting involves the location of the rsync server which you use when you update your Portage tree:
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:
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. 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. 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:
For more information on these options and others, please read man rsync. 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. You can activate certain Portage features through the FEATURES variable. The Portage Features have been discussed in previous chapters, such as Portage Features. 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:
The NOCOLOR, which defaults to "false", defines if Portage should disable the use of coloured output. 3. Mixing Software BranchesThe 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. 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. The testing branch is exactly what it says - Testing. If a package is in testing, it means that the developers feel that it is functional but has not been thoroughly tested. You could very well be the first to discover a bug in the package in which case you could file a bugreport to let the developers know about it. Beware though, you might notice stability issues, imperfect package handling (for instance wrong/missing dependencies), too frequent updates (resulting in lots of building) or broken packages. If you do not know how Gentoo works and how to solve problems, we recommend that you stick with the stable and tested branch. For example, to select the testing branch for the x86 architecture, edit /etc/portage/make.conf and set:
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.accept_keywords location 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.accept_keywords. You can also create a directory (with the same name) and list the package in the files under that directory. For instance, to use the testing branch for gnumeric:
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.accept_keywords location. 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:
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 desired version (usually this will be the exact same line from profiles) in the /etc/portage/package.unmask file (or in a file in that directory if it is a directory). For instance, if =net-mail/hotwayd-0.8 is masked, you can unmask it by adding the exact same line in the package.unmask location:
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 the /etc/portage/package.mask location (either in that file or in a file in this directory). For instance, if you don't want Portage to install newer kernel sources than gentoo-sources-2.6.8.1, you add the following line at the package.mask location:
4. Additional Portage Toolsdispatch-conf is a tool that aids in merging the ._cfg0000_<name> files. ._cfg0000_<name> files are generated by Portage when it wants to overwrite a file in a directory protected by the CONFIG_PROTECT variable. With 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. This means that if you make a mistake when updating a config file, you can revert to the previous version of your config file at any time. When using dispatch-conf, you can ask to keep the configuration file as-is, use the new configuration file, edit the current one or merge the changes interactively. dispatch-conf also has some nice additional features:
Make certain you edit /etc/dispatch-conf.conf first and create the directory referenced by the archive-dir variable.
When running dispatch-conf, you'll be taken through each changed config file, one at a time. Press u to update (replace) the current config file with the new one and continue to the next file. Press z to zap (delete) the new config file and continue to the next file. Once all config files have been taken care of, dispatch-conf will exit. You can also press q to exit any time. For more information, check out the dispatch-conf man page. It tells you how to interactively merge current and new config files, edit new config files, examine differences between files, and more.
You can also use etc-update to merge config files. It's not as simple to use as dispatch-conf, nor as featureful, but it does provide an interactive merging setup and can also auto-merge trivial changes. However, unlike dispatch-conf, etc-update does not preserve the old versions of your config files. Once you update the file, the old version is gone forever! So be very careful, as using etc-update is significantly less safe than using dispatch-conf.
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:
If you enter -1, etc-update will exit and discontinue any further 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:
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:
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. 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, orage, and procps:
The prebuilt packages will be stored in $PKGDIR (/usr/portage/packages/ by default). These packages are placed in $PKGDIR/<category>. 5. Diverting from the Official Tree5.a. Using a Portage Tree Subset 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. You need to define the name of the file that contains the exclude patterns in the PORTAGE_RSYNC_EXTRA_OPTS variable in your /etc/portage/make.conf.
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/portage/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. For the powerusers who develop on several overlays, test packages before they hit the Portage tree or just want to use unofficial ebuilds from various sources, the app-portage/layman package brings you layman, a tool to help you keep the overlay repositories up to date. First install and configure layman as shown in the Overlays Users' Guide, and add your desired repositories with layman -a <overlay-name>. Suppose you have two repositories called java (for the in-development java ebuilds) and entapps (for the applications developed in-house for your enterprise). You can update those repositories with the following command:
For more information on working with overlays, please read man layman and the layman/overlay users' guide. 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 gentoo-sources-2.6.11.6 which you've installed manually, add the following line to /etc/portage/profile/package.provided:
D. Gentoo Network Configuration1. Getting Started
To get started configuring your network card, you need to tell the Gentoo RC system about it. This is done by creating a symbolic link from net.lo to net.eth0 (or whatever the network interface name is on your system) in /etc/init.d.
Gentoo's RC system now knows about that interface. It also needs to know how to configure the new interface. All the network interfaces are configured in /etc/conf.d/net. Below is a sample configuration for DHCP and static addresses.
Now that we have configured our interface, we can start and stop it using the following commands:
Now that you have successfully started and stopped your network interface, you may wish to get it to start when Gentoo boots. Here's how to do this. The last "rc" command instructs Gentoo to start any scripts in the current runlevel that have not yet been started.
2. Advanced ConfigurationThe config_eth0 variable is the heart of an interface configuration. It's a high level instruction list for configuring the interface (eth0 in this case). Each command in the instruction list is performed sequentially. The interface is deemed OK if at least one command works. Here's a list of built-in instructions.
If a command fails, you can specify a fallback command. The fallback has to match the config structure exactly. You can chain these commands together. Here are some real world examples.
Init scripts in /etc/init.d can depend on a specific network interface or just net. All network interfaces in Gentoo's init system provide what is called net. If, in /etc/rc.conf, rc_depend_strict="YES" is set, then all network interfaces that provide net must be active before a dependency on "net" is assumed to be met. In other words, if you have a net.eth0 and net.eth1 and an init script depends on "net", then both must be enabled. On the other hand, if rc_depend_strict="NO" is set, then the "net" dependency is marked as resolved the moment at least one network interface is brought up. But what about net.br0 depending on net.eth0 and net.eth1? net.eth1 may be a wireless or PPP device that needs configuration before it can be added to the bridge. This cannot be done in /etc/init.d/net.br0 as that's a symbolic link to net.lo. The answer is defining an rc_need_ setting in /etc/conf.d/net.
That alone, however, is not sufficient. Gentoo's networking init scripts use a virtual dependency called net to inform the system when networking is available. Clearly, in the above case, networking should only be marked as available when net.br0 is up, not when the others are. So we need to tell that in /etc/conf.d/net as well:
For a more detailed discussion about dependency, consult the section Writing Init Scripts in the Gentoo Handbook. More information about /etc/rc.conf is available as comments within that file. 2.c. Variable names and values Variable names are dynamic. They normally follow the structure of variable_${interface|mac|essid|apmac}. For example, the variable dhcpcd_eth0 holds the value for dhcpcd options for eth0 and dhcpcd_essid holds the value for dhcpcd options when any interface connects to the ESSID "essid". However, there is no hard and fast rule that states interface names must be ethx. In fact, many wireless interfaces have names like wlanx, rax as well as ethx. Also, some user defined interfaces such as bridges can be given any name, such as foo. To make life more interesting, wireless Access Points can have names with non alpha-numeric characters in them - this is important because you can configure networking parameters per ESSID. The downside of all this is that Gentoo uses bash variables for networking - and bash cannot use anything outside of English alpha-numerics. To get around this limitation we change every character that is not an English alpha-numeric into a _ character. Another downside of bash is the content of variables - some characters need to be escaped. This can be achived by placing the \ character in front of the character that needs to be escaped. The following list of characters needs to be escaped in this way: ", ' and \. In this example we use wireless ESSID as they can contain the widest scope of characters. We shall use the ESSID My "\ NET:
Network interface names are not chosen arbitrarily: the Linux kernel and the device manager (most sytems have udev as their device manager although others are available as well) choose the interface name through a fixed set of rules. When an interface card is detected on a system, the Linux kernel gathers the necessary data about this card. This includes:
Based on this information, the device manager decides how to name the interface on the system. By default, it uses the first hit of the above three parameters. For instance, if ID_NET_NAME_ONBOARD is found and set to eno1, then the interface will be called eno1. If you know your interface name, you can see the values of the provided parameters using udevadm:
As the first (and actually only) hit of the top three parameters is the ID_NET_NAME_PATH one, its value is used as the interface name. If none of the parameters is found, then the system reverts back to the kernel-provided naming (eth0, eth1, etc.) Using the Old-style Kernel Naming Before this change, network interface cards were named by the Linux kernel itself, depending on the order that drivers are loaded (amongst other, possibly more obscure reasons). This behavior can still be enabled by setting the net.ifnames=0 boot option in the boot loader. Another way of disabling this behavior (and thus reverting back to the kernel-provided naming) is to create an empty udev rule named 80-net-name-slot.rules which will then override the default provided one (with the same name) that is responsible for taking care of network interface naming.
The entire idea behind the change in naming is not to confuse people, but to make changing the names easier. Suppose you have two interfaces that are otherwise called eth0 and eth1. One is meant to access the network through a wire, the other one is for wireless access. With the support for interface naming, you can have these called lan0 (wired) and wifi0 (wireless - it is best to avoid using the previously well-known names like eth* and wlan* as those can still collide with your suggested names). All you need to do is to find out what the parameters are for the cards and then use this information to set up your own naming rule:
Because the rules are triggered before the default one (rules are triggered in alphanumerical order, so 70 comes before 80) the names provided in the rule file will be used instead of the default ones. The number granted to the file should be between 76 and 79 (the environment variables are defined by a rule start starts with 75 and the fallback naming is done in a rule numbered 80). 3. Modular NetworkingWe now support modular networking scripts, which means we can easily add support for new interface types and configuration modules while keeping compatibility with existing ones. Modules load by default if the package they need is installed. If you specify a module here that doesn't have its package installed then you get an error stating which package you need to install. Ideally, you only use the modules setting when you have two or more packages installed that supply the same service and you need to prefer one over the other.
We provide two interface handlers presently: ifconfig and iproute2. You need one of these to do any kind of network configuration. ifconfig is installed by default (the net-tools package is part of the system profile). iproute2 is a more powerful and flexible package, but it's not included by default.
As both ifconfig and iproute2 do very similar things we allow their basic configuration to work with each other. For example both the below code snippet work regardless of which module you are using.
DHCP is a means of obtaining network information (IP address, DNS servers, Gateway, etc) from a DHCP server. This means that if there is a DHCP server running on the network, you just have to tell each client to use DHCP and it sets up the network all by itself. Of course, you will have to configure for other things like wireless, PPP or other things if required before you can use DHCP. DHCP can be provided by dhclient, dhcpcd, or pump. Each DHCP module has its pros and cons - here's a quick run down.
If you have more than one DHCP client installed, you need to specify which one to use - otherwise we default to dhcpcd if available. To send specific options to the DHCP module, use module_eth0="..." (change module to the DHCP module you're using - i.e. dhcpcd_eth0). We try and make DHCP relatively agnostic - as such we support the following commands using the dhcp_eth0 variable. The default is not to set any of them:
First we need to install the ADSL software.
Second, create the PPP net script and the net script for the ethernet interface to be used by PPP:
Be sure to set rc_depend_strict to "YES" in /etc/rc.conf. Now we need to configure /etc/conf.d/net.
You can also set your password in /etc/ppp/pap-secrets.
If you use PPPoE with a USB modem you'll need to emerge br2684ctl. Please read /usr/portage/net-dialup/speedtouch-usb/files/README for information on how to properly configure it.
4.e. APIPA (Automatic Private IP Addressing) APIPA tries to find a free address in the range 169.254.0.0-169.254.255.255 by arping a random address in that range on the interface. If no reply is found then we assign that address to the interface. This is only useful for LANs where there is no DHCP server and you don't connect directly to the internet and all other computers use APIPA. For APIPA support, emerge net-misc/iputils or net-analyzer/arping.
For link bonding/trunking emerge net-misc/ifenslave. Bonding is used to increase network bandwidth. If you have two network cards going to the same network, you can bond them together so your applications see just one interface but they really use both network cards.
3.g. Bridging (802.1d support) For bridging support emerge net-misc/bridge-utils. Bridging is used to join networks together. For example, you may have a server that connects to the internet via an ADSL modem and a wireless access card to enable other computers to connect to the internet via the ADSL modem. You could create a bridge to join the two interfaces together.
If you need to, you can change the MAC address of your interfaces through the network configuration file too.
You don't need to emerge anything for tunnelling as the interface handler can do it for you.
For VLAN support, emerge net-misc/vconfig. Virtual LAN is a group of network devices that behave as if they were connected to a single network segment - even though they may not be. VLAN members can only see members of the same VLAN even though they may share the same physical network.
4. Wireless NetworkingWireless networking on Linux is usually pretty straightforward. There are two ways of configuring wifi: graphical clients, or the command line. The easiest way is to use a graphical client once you've installed a desktop environment. Most graphical clients, such as wicd and NetworkManager, are pretty self-explanatory. They offer a handy point-and-click interface that gets you on a network in just a few seconds.
However, if you don't want to use a graphical client, then you can configure wifi on the command line by editing a few configuration files. This takes a bit more time to setup, but it also requires the fewest packages to download and install. Since the graphical clients are mostly self-explanatory (with helpful screenshots at their homepages), we'll focus on the command line alternatives. You can setup wireless networking on the command line by installing wireless-tools or wpa_supplicant. The important thing to remember is that you configure wireless networks on a global basis and not an interface basis. wpa_supplicant is the best choice. For a list of supported drivers, read the wpa_supplicant site. wireless-tools supports nearly all cards and drivers, but it cannot connect to WPA-only Access Points. If your networks only offer WEP encryption or are completely open, you may prefer the simplicity of wireless-tools.
WPA Supplicant is a package that allows you to connect to WPA enabled access points.
Now we have to configure /etc/conf.d/net to so that we prefer wpa_supplicant over wireless-tools (if both are installed, wireless-tools is the default).
That was simple, wasn't it? However, we still have to configure wpa_supplicant itself which is a bit more tricky depending on how secure the Access Points are that you are trying to connect to. The below example is taken and simplified from /usr/share/doc/wpa_supplicant-<version>/wpa_supplicant.conf.gz which ships with wpa_supplicant.
Initial setup and Managed Mode Wireless Tools provide a generic way to configure basic wireless interfaces up to the WEP security level. While WEP is a weak security method it's also the most prevalent. Wireless Tools configuration is controlled by a few main variables. The sample configuration file below should describe all you need. One thing to bear in mind is that no configuration means "connect to the strongest unencrypted Access Point" - we will always try and connect you to something.
Fine tune Access Point Selection You can add some extra options to fine-tune your Access Point selection, but these are not normally required. You can decide whether we only connect to preferred Access Points or not. By default if everything configured has failed and we can connect to an unencrypted Access Point then we will. This can be controlled by the associate_order variable. Here's a table of values and how they control this.
Finally we have some blacklist_aps and unique_ap selection. blacklist_aps works in a similar way to preferred_aps. unique_ap is a yes or no value that says if a second wireless interface can connect to the same Access Point as the first interface.
If you want to set yourself up as an Ad-Hoc node if you fail to connect to any Access Point in managed mode, you can do that too.
What about connecting to Ad-Hoc networks or running in Master mode to become an Access Point? Here's a configuration just for that! You may need to specify WEP keys as shown above.
Troubleshooting Wireless Tools There are some more variables you can use to help get your wireless up and running due to driver or environment problems. Here's a table of other things you can try.
4.d. Defining network configuration per ESSID Sometimes, you need a static IP when you connect to ESSID1 and you need DHCP when you connect to ESSID2. In fact, most module variables can be defined per ESSID. Here's how we do this.
5. Adding FunctionalityFour functions can be defined in /etc/conf.d/net which will be called surrounding the start/stop operations. The functions are called with the interface name first so that one function can control multiple adapters. The return values for the preup() and predown() functions should be 0 (success) to indicate that configuration or deconfiguration of the interface can continue. If preup() returns a non-zero value, then interface configuration will be aborted. If predown() returns a non-zero value, then the interface will not be allowed to continue deconfiguration. The return values for the postup() and postdown() functions are ignored since there's nothing to do if they indicate failure. ${IFACE} is set to the interface being brought up/down. ${IFVAR} is ${IFACE} converted to variable name bash allows.
5.b. Wireless Tools function hooks
Two functions can be defined in /etc/conf.d/net which will be called surrounding the associate function. The functions are called with the interface name first so that one function can control multiple adapters. The return values for the preassociate() function should be 0 (success) to indicate that configuration or deconfiguration of the interface can continue. If preassociate() returns a non-zero value, then interface configuration will be aborted. The return value for the postassociate() function is ignored since there's nothing to do if it indicates failure. ${ESSID} is set to the exact ESSID of the AP you're connecting to. ${ESSIDVAR} is ${ESSID} converted to a variable name bash allows.
6. Network ManagementIf you and your computer are always on the move, you may not always have an ethernet cable or plugged in or an access point available. Also, you may want networking to automatically work when an ethernet cable is plugged in or an access point is found. Here you can find some tools that help you manage this.
ifplugd is a daemon that starts and stops interfaces when an ethernet cable is inserted or removed. It can also manage detecting association to Access Points or when new ones come in range.
Configuration for ifplugd is fairly straightforward too. The configuration file is held in /etc/conf.d/net. Run man ifplugd for details on the available variables. Also, see /usr/share/doc/openrc-*/net.example.bz2 for more examples.
In addition to managing multiple network connections, you may want to add a tool that makes it easy to work with multiple DNS servers and configurations. This is very handy when you receive your IP address via DHCP. Simply emerge openresolv.
See man resolvconf to learn more about its features. The contents of this document, unless otherwise expressly stated, are licensed under the CC-BY-SA-2.5 license. The Gentoo Name and Logo Usage Guidelines apply. |
|