guix.texi

@node Porting
@section Porting to a New Platform

As discussed above, the GNU distribution is self-contained, and
self-containment is achieved by relying on pre-built ``bootstrap
binaries'' (@pxref{Bootstrapping}).  These binaries are specific to an
operating system kernel, CPU architecture, and application binary
interface (ABI).  Thus, to port the distribution to a platform that is
not yet supported, one must build those bootstrap binaries, and update
the @code{(gnu packages bootstrap)} module to use them on that platform.

Fortunately, Guix can @emph{cross compile} those bootstrap binaries.
When everything goes well, and assuming the GNU tool chain supports the
target platform, this can be as simple as running a command like this
one:

@example
guix build --target=armv5tel-linux-gnueabi bootstrap-tarballs
@end example

Once these are built, the @code{(gnu packages bootstrap)} module needs
to be updated to refer to these binaries on the target platform.  In
addition, the @code{glibc-dynamic-linker} procedure in that module must
be augmented to return the right file name for libc's dynamic linker on
that platform; likewise, @code{system->linux-architecture} in @code{(gnu
packages linux)} must be taught about the new platform.

In practice, there may be some complications.  First, it may be that the
extended GNU triplet that specifies an ABI (like the @code{eabi} suffix
above) is not recognized by all the GNU tools.  Typically, glibc
recognizes some of these, whereas GCC uses an extra @code{--with-abi}
configure flag (see @code{gcc.scm} for examples of how to handle this).
Second, some of the required packages could fail to build for that
platform.  Lastly, the generated binaries could be broken for some
reason.


@node System Configuration
@section System Configuration

@emph{This section documents work-in-progress.  As such it may be
incomplete, outdated, or open to discussions.  Please discuss it on
@email{guix-devel@@gnu.org}.}

@cindex system configuration
The GNU system supports a consistent whole-system configuration
mechanism.  By that we mean that all aspects of the global system
configuration---such as the available system services, timezone and
locale settings, user accounts---are declared in a single place.  Such
a @dfn{system configuration} can be @dfn{instantiated}---i.e., effected.

One of the advantages of putting all the system configuration under the
control of Guix is that it supports transactional system upgrades, and
makes it possible to roll-back to a previous system instantiation,
should something go wrong with the new one (@pxref{Features}).  Another
one is that it makes it easy to replicate the exact same configuration
across different machines, or at different points in time, without
having to resort to additional administration tools layered on top of
the system's own tools.
@c Yes, we're talking of Puppet, Chef, & co. here.  ↑

This section describes this mechanism.  First we focus on the system
administrator's viewpoint---explaining how the system is configured and
instantiated.  Then we show how this mechanism can be extended, for
instance to support new system services.

@menu
* Using the Configuration System::  Customizing your GNU system.
* Invoking guix system::        Instantiating a system configuration.
* Defining Services::           Adding new service definitions.
@end menu

@node Using the Configuration System
@subsection Using the Configuration System

The operating system is configured by filling in an
@code{operating-system} structure, as defined by the @code{(gnu system)}
module.  A simple setup, with the default system services, the default
Linux-Libre kernel, initial RAM disk, and boot loader looks like this:

@findex operating-system
@lisp
(use-modules (gnu services base)   ; for '%base-services'
             (gnu services ssh)    ; for 'lsh-service'
             (gnu system shadow)   ; for 'user-account'
             (gnu packages base)   ; Coreutils, grep, etc.
             (gnu packages bash)   ; Bash
             (gnu packages admin)  ; dmd, Inetutils
             (gnu packages zile)   ; Zile
             (gnu packages less)   ; less
             (gnu packages guile)  ; Guile
             (gnu packages linux)) ; procps, psmisc

(define komputilo
  (operating-system
   (host-name "komputilo")
   (timezone "Europe/Paris")
   (locale "fr_FR.UTF-8")
   (users (list (user-account
                 (name "alice")
                 (password "")
                 (uid 1000) (gid 100)
                 (comment "Bob's sister")
                 (home-directory "/home/alice"))))
   (packages (list coreutils bash guile-2.0
                   guix dmd
                   inetutils
                   findutils grep sed
                   procps psmisc
                   zile less))
   (services (cons (lsh-service #:port 2222 #:allow-root-login? #t)
                   %base-services))))
@end lisp

This example should be self-describing.  The @code{packages} field lists
packages provided by the various @code{(gnu packages ...)} modules above
(@pxref{Package Modules}).  These are the packages that will be globally
visible on the system, for all user accounts---i.e., in every user's
@code{PATH} environment variable---in addition to the per-user profiles
(@pxref{Invoking guix package}).

@vindex %base-services
The @code{services} field lists @dfn{system services} to be made
available when the system starts.  The @var{%base-services} list,
from the @code{(gnu services base)} module, provides the basic services one
would expect from a GNU system: a login service (mingetty) on each tty,
syslogd, libc's name service cache daemon (nscd), etc.

The @code{operating-system} declaration above specifies that, in
addition to those services, we want the @command{lshd} secure shell
daemon listening on port 2222, and allowing remote @code{root} logins
(@pxref{Invoking lshd,,, lsh, GNU lsh Manual}).  Under the hood,
@code{lsh-service} arranges so that @code{lshd} is started with the
right command-line options, possibly with supporting configuration files
generated as needed (@pxref{Defining Services}).

Assuming the above snippet is stored in the @file{my-system-config.scm}
file, the @command{guix system boot my-system-config.scm} command
instantiates that configuration, and makes it the default GRUB boot
entry (@pxref{Invoking guix system}).  The normal way to change the
system's configuration is by updating this file and re-running the
@command{guix system} command.

At the Scheme level, the bulk of an @code{operating-system} declaration
is instantiated with the following monadic procedure (@pxref{The Store
Monad}):

@deffn {Monadic Procedure} operating-system-derivation os
Return a derivation that builds @var{os}, an @code{operating-system}
object (@pxref{Derivations}).

The output of the derivation is a single directory that refers to all
the packages, configuration files, and other supporting files needed to
instantiate @var{os}.
@end deffn

@node Invoking guix system
@subsection Invoking @code{guix system}

Once you have written an operating system declaration, as seen in the
previous section, it can be @dfn{instantiated} using the @command{guix
system} command.  The synopsis is:

@example
guix system @var{options}@dots{} @var{action} @var{file}
@end example

@var{file} must be the name of a file containing an
@code{operating-system} declaration.  @var{action} specifies how the
operating system is instantiate.  Currently the following values are
supported:

@table @code
@item vm
@cindex virtual machine
Build a virtual machine that contain the operating system declared in
@var{file}, and return a script to run that virtual machine (VM).

The VM shares its store with the host system.

@item vm-image
Return a virtual machine image of the operating system declared in
@var{file} that stands alone.  Use the @option{--image-size} option to
specify the size of the image.
@end table

@var{options} can contain any of the common build options provided by
@command{guix build} (@pxref{Invoking guix build}).


@node Defining Services
@subsection Defining Services

The @code{(gnu services @dots{})} modules define several procedures that allow
users to declare the operating system's services (@pxref{Using the
Configuration System}).  These procedures are @emph{monadic
procedures}---i.e., procedures that return a monadic value in the store
monad (@pxref{The Store Monad}).  Examples of such procedures include:

@table @code
@item mingetty-service
return the definition of a service that runs @command{mingetty} to
offer a login service on the given console tty;

@item nscd-service
return a definition for libc's name service cache daemon (nscd);

@item guix-service
return a definition for a service that runs @command{guix-daemon}
(@pxref{Invoking guix-daemon}).
@end table

@cindex service definition
The monadic value returned by those procedures is a @dfn{service
definition}---a structure as returned by the @code{service} form.
Service definitions specifies the inputs the service depends on, and an
expression to start and stop the service.  Behind the scenes, service
definitions are ``translated'' into the form suitable for the
configuration file of dmd, the init system (@pxref{Services,,, dmd, GNU
dmd Manual}).

As an example, here is what the @code{nscd-service} procedure looks
like:

@lisp
(define (nscd-service)
  (mlet %store-monad ((nscd (package-file glibc "sbin/nscd")))
    (return (service
             (documentation "Run libc's name service cache daemon.")
             (provision '(nscd))
             (start `(make-forkexec-constructor ,nscd "-f" "/dev/null"
                                                "--foreground"))
             (stop  `(make-kill-destructor))

             (respawn? #f)
             (inputs `(("glibc" ,glibc)))))))
@end lisp

@noindent
The @code{inputs} field specifies that this service depends on the
@var{glibc} package---the package that contains the @command{nscd}
program.  The @code{start} and @code{stop} fields are expressions that
make use of dmd's facilities to start and stop processes (@pxref{Service
De- and Constructors,,, dmd, GNU dmd Manual}).  The @code{provision}
field specifies the name under which this service is known to dmd, and
@code{documentation} specifies on-line documentation.  Thus, the
commands @command{deco start ncsd}, @command{deco stop nscd}, and
@command{deco doc nscd} will do what you would expect (@pxref{Invoking
deco,,, dmd, GNU dmd Manual}).


@c *********************************************************************
@node Contributing
@chapter Contributing

This project is a cooperative effort, and we need your help to make it
grow!  Please get in touch with us on @email{guix-devel@@gnu.org} and
@code{#guix} on the Freenode IRC network.  We welcome ideas, bug
reports, patches, and anything that may be helpful to the project.  We
particularly welcome help on packaging (@pxref{Packaging Guidelines}).

Please see the
@url{http://git.savannah.gnu.org/cgit/guix.git/tree/HACKING,
@file{HACKING} file} that comes with the Guix source code for practical
details about contributions.


@c *********************************************************************
@node Acknowledgments
@chapter Acknowledgments

Guix is based on the Nix package manager, which was designed and
implemented by Eelco Dolstra.  Nix pioneered functional package
management, and promoted unprecedented features, such as transactional
package upgrades and rollbacks, per-user profiles, and referentially
transparent build processes.  Without this work, Guix would not exist.

The Nix-based software distributions, Nixpkgs and NixOS, have also been
an inspiration for Guix.

@c *********************************************************************
@node GNU Free Documentation License
@appendix GNU Free Documentation License

@include fdl-1.3.texi

@c *********************************************************************
@node Concept Index
@unnumbered Concept Index
@printindex cp

@node Function Index
@unnumbered Function Index
@printindex fn

@bye

@c Local Variables:
@c ispell-local-dictionary: "american";
@c End: