Newer
Older
The @code{label} and @code{uuid} options offer a way to refer to disk
partitions without having to hard-code their actual device name.
Ludovic Courtès
committed
However, when a file system's source is a mapped device (@pxref{Mapped
Devices}), its @code{device} field @emph{must} refer to the mapped
device name---e.g., @file{/dev/mapper/root-partition}---and consequently
@code{title} must be set to @code{'device}. This is required so that
the system knows that mounting the file system depends on having the
corresponding device mapping established.
@item @code{flags} (default: @code{'()})
This is a list of symbols denoting mount flags. Recognized flags
include @code{read-only}, @code{bind-mount}, @code{no-dev} (disallow
access to special files), @code{no-suid} (ignore setuid and setgid
bits), and @code{no-exec} (disallow program execution.)
@item @code{options} (default: @code{#f})
This is either @code{#f}, or a string denoting mount options.
@item @code{needed-for-boot?} (default: @code{#f})
This Boolean value indicates whether the file system is needed when
booting. If that is true, then the file system is mounted when the
initial RAM disk (initrd) is loaded. This is always the case, for
instance, for the root file system.
@item @code{check?} (default: @code{#t})
This Boolean indicates whether the file system needs to be checked for
errors before being mounted.
@item @code{create-mount-point?} (default: @code{#f})
When true, the mount point is created if it does not exist yet.
The @code{(gnu system file-systems)} exports the following useful
variables.
@defvr {Scheme Variable} %base-file-systems
These are essential file systems that are required on normal systems,
such as @var{%devtmpfs-file-system} (see below.) Operating system
declarations should always contain at least these.
@end defvr
@defvr {Scheme Variable} %devtmpfs-file-system
The @code{devtmpfs} file system to be mounted on @file{/dev}. This is a
requirement for udev (@pxref{Base Services, @code{udev-service}}).
@end defvr
@defvr {Scheme Variable} %pseudo-terminal-file-system
This is the file system to be mounted as @file{/dev/pts}. It supports
@dfn{pseudo-terminals} created @i{via} @code{openpty} and similar
functions (@pxref{Pseudo-Terminals,,, libc, The GNU C Library Reference
Manual}). Pseudo-terminals are used by terminal emulators such as
@command{xterm}.
@end defvr
@defvr {Scheme Variable} %shared-memory-file-system
This file system is mounted as @file{/dev/shm} and is used to support
memory sharing across processes (@pxref{Memory-mapped I/O,
@code{shm_open},, libc, The GNU C Library Reference Manual}).
@end defvr
@defvr {Scheme Variable} %binary-format-file-system
The @code{binfmt_misc} file system, which allows handling of arbitrary
executable file types to be delegated to user space. This requires the
@code{binfmt.ko} kernel module to be loaded.
@end defvr
@defvr {Scheme Variable} %fuse-control-file-system
The @code{fusectl} file system, which allows unprivileged users to mount
and unmount user-space FUSE file systems. This requires the
@code{fuse.ko} kernel module to be loaded.
@end defvr
4076
4077
4078
4079
4080
4081
4082
4083
4084
4085
4086
4087
4088
4089
4090
4091
4092
4093
4094
4095
4096
4097
4098
4099
4100
4101
4102
4103
4104
4105
4106
4107
4108
4109
4110
4111
4112
4113
4114
4115
4116
@node Mapped Devices
@subsection Mapped Devices
@cindex device mapping
@cindex mapped devices
The Linux kernel has a notion of @dfn{device mapping}: a block device,
such as a hard disk partition, can be @dfn{mapped} into another device,
with additional processing over the data that flows through
it@footnote{Note that the GNU@tie{}Hurd makes no difference between the
concept of a ``mapped device'' and that of a file system: both boil down
to @emph{translating} input/output operations made on a file to
operations on its backing store. Thus, the Hurd implements mapped
devices, like file systems, using the generic @dfn{translator} mechanism
(@pxref{Translators,,, hurd, The GNU Hurd Reference Manual}).}. A
typical example is encryption device mapping: all writes to the mapped
device are encrypted, and all reads are deciphered, transparently.
Mapped devices are declared using the @code{mapped-device} form:
@example
(mapped-device
(source "/dev/sda3")
(target "home")
(type luks-device-mapping))
@end example
@noindent
@cindex disk encryption
@cindex LUKS
This example specifies a mapping from @file{/dev/sda3} to
@file{/dev/mapper/home} using LUKS---the
@url{http://code.google.com/p/cryptsetup,Linux Unified Key Setup}, a
standard mechanism for disk encryption. The @file{/dev/mapper/home}
device can then be used as the @code{device} of a @code{file-system}
declaration (@pxref{File Systems}). The @code{mapped-device} form is
detailed below.
@deftp {Data Type} mapped-device
Objects of this type represent device mappings that will be made when
the system boots up.
@table @code
@item source
This string specifies the name of the block device to be mapped, such as
@code{"/dev/sda3"}.
@item target
This string specifies the name of the mapping to be established. For
example, specifying @code{"my-partition"} will lead to the creation of
the @code{"/dev/mapper/my-partition"} device.
@item type
This must be a @code{mapped-device-kind} object, which specifies how
@var{source} is mapped to @var{target}.
@end table
@end deftp
@defvr {Scheme Variable} luks-device-mapping
This defines LUKS block device encryption using the @command{cryptsetup}
command, from the same-named package. This relies on the
@code{dm-crypt} Linux kernel module.
@end defvr
@node User Accounts
@subsection User Accounts
User accounts are specified with the @code{user-account} form:
@example
(user-account
(name "alice")
(group "users")
(supplementary-groups '("wheel" ;allow use of sudo, etc.
"audio" ;sound card
"video" ;video devices such as webcams
"cdrom")) ;the good ol' CD-ROM
(comment "Bob's sister")
(home-directory "/home/alice"))
@end example
@deftp {Data Type} user-account
Objects of this type represent user accounts. The following members may
be specified:
@table @asis
@item @code{name}
The name of the user account.
@item @code{group}
This is the name (a string) or identifier (a number) of the user group
this account belongs to.
@item @code{supplementary-groups} (default: @code{'()})
Optionally, this can be defined as a list of group names that this
account belongs to.
@item @code{uid} (default: @code{#f})
This is the user ID for this account (a number), or @code{#f}. In the
latter case, a number is automatically chosen by the system when the
account is created.
@item @code{comment} (default: @code{""})
A comment about the account, such as the account's owner full name.
@item @code{home-directory}
This is the name of the home directory for the account.
@item @code{shell} (default: Bash)
This is a G-expression denoting the file name of a program to be used as
the shell (@pxref{G-Expressions}).
@item @code{system?} (default: @code{#f})
This Boolean value indicates whether the account is a ``system''
account. System accounts are sometimes treated specially; for instance,
graphical login managers do not list them.
@item @code{password} (default: @code{#f})
You would normally leave this field to @code{#f}, initialize user
passwords as @code{root} with the @command{passwd} command, and then let
users change it with @command{passwd}.
If you @emph{do} want to have a preset password for an account, then
this field must contain the encrypted password, as a string.
@xref{crypt,,, libc, The GNU C Library Reference Manual}, for more information
on password encryption, and @ref{Encryption,,, guile, GNU Guile Reference
Manual}, for information on Guile's @code{crypt} procedure.
User group declarations are even simpler:
@example
(user-group (name "students"))
@end example
@deftp {Data Type} user-group
This type is for, well, user groups. There are just a few fields:
@table @asis
@item @code{name}
The group's name.
@item @code{id} (default: @code{#f})
The group identifier (a number). If @code{#f}, a new number is
automatically allocated when the group is created.
@item @code{system?} (default: @code{#f})
This Boolean value indicates whether the group is a ``system'' group.
System groups have low numerical IDs.
@item @code{password} (default: @code{#f})
What, user groups can have a password? Well, apparently yes. Unless
@code{#f}, this field specifies the group's password.
For convenience, a variable lists all the basic user groups one may
expect:
@defvr {Scheme Variable} %base-groups
This is the list of basic user groups that users and/or packages expect
to be present on the system. This includes groups such as ``root'',
``wheel'', and ``users'', as well as groups used to control access to
specific devices such as ``audio'', ``disk'', and ``cdrom''.
@end defvr
4244
4245
4246
4247
4248
4249
4250
4251
4252
4253
4254
4255
4256
4257
4258
4259
4260
4261
4262
4263
4264
4265
4266
4267
4268
4269
4270
4271
4272
4273
4274
4275
4276
4277
4278
4279
4280
4281
4282
4283
4284
4285
4286
4287
4288
4289
4290
4291
4292
4293
4294
4295
4296
4297
4298
4299
4300
4301
4302
4303
4304
4305
4306
4307
4308
4309
4310
4311
4312
4313
4314
4315
@node Locales
@subsection Locales
@cindex locale
A @dfn{locale} defines cultural conventions for a particular language
and region of the world (@pxref{Locales,,, libc, The GNU C Library
Reference Manual}). Each locale has a name that typically has the form
@code{@var{language}_@var{territory}.@var{charset}}---e.g.,
@code{fr_LU.utf8} designates the locale for the French language, with
cultural conventions from Luxembourg, and using the UTF-8 encoding.
@cindex locale definition
Usually, you will want to specify the default locale for the machine
using the @code{locale} field of the @code{operating-system} declaration
(@pxref{operating-system Reference, @code{locale}}).
That locale must be among the @dfn{locale definitions} that are known to
the system---and these are specified in the @code{locale-definitions}
slot of @code{operating-system}. The default value includes locale
definition for some widely used locales, but not for all the available
locales, in order to save space.
If the locale specified in the @code{locale} field is not among the
definitions listed in @code{locale-definitions}, @command{guix system}
raises an error. In that case, you should add the locale definition to
the @code{locale-definitions} field. For instance, to add the North
Frisian locale for Germany, the value of that field may be:
@example
(cons (locale-definition
(name "fy_DE.utf8") (source "fy_DE"))
%default-locale-definitions)
@end example
Likewise, to save space, one might want @code{locale-definitions} to
list only the locales that are actually used, as in:
@example
(list (locale-definition
(name "ja_JP.eucjp") (source "ja_JP")
(charset "EUC-JP")))
@end example
The @code{locale-definition} form is provided by the @code{(gnu system
locale)} module. Details are given below.
@deftp {Data Type} locale-definition
This is the data type of a locale definition.
@table @asis
@item @code{name}
The name of the locale. @xref{Locale Names,,, libc, The GNU C Library
Reference Manual}, for more information on locale names.
@item @code{source}
The name of the source for that locale. This is typically the
@code{@var{language}_@var{territory}} part of the locale name.
@item @code{charset} (default: @code{"UTF-8"})
The ``character set'' or ``code set'' for that locale,
@uref{http://www.iana.org/assignments/character-sets, as defined by
IANA}.
@end table
@end deftp
@defvr {Scheme Variable} %default-locale-definitions
An arbitrary list of commonly used locales, used as the default value of
the @code{locale-definitions} field of @code{operating-system}
declarations.
@end defvr
@node Services
@subsection Services
@cindex system services
An important part of preparing an @code{operating-system} declaration is
listing @dfn{system services} and their configuration (@pxref{Using the
Configuration System}). System services are typically daemons launched
when the system boots, or other actions needed at that time---e.g.,
4325
4326
4327
4328
4329
4330
4331
4332
4333
4334
4335
4336
4337
4338
4339
4340
4341
4342
4343
4344
4345
4346
4347
4348
4349
4350
4351
4352
4353
4354
4355
4356
configuring network access.
Services are managed by GNU@tie{}dmd (@pxref{Introduction,,, dmd, GNU
dmd Manual}). On a running system, the @command{deco} command allows
you to list the available services, show their status, start and stop
them, or do other specific operations (@pxref{Jump Start,,, dmd, GNU dmd
Manual}). For example:
@example
# deco status dmd
@end example
The above command, run as @code{root}, lists the currently defined
services. The @command{deco doc} command shows a synopsis of the given
service:
@example
# deco doc nscd
Run libc's name service cache daemon (nscd).
@end example
The @command{start}, @command{stop}, and @command{restart} sub-commands
have the effect you would expect. For instance, the commands below stop
the nscd service and restart the Xorg display server:
@example
# deco stop nscd
Service nscd has been stopped.
# deco restart xorg-server
Service xorg-server has been stopped.
Service xorg-server has been started.
@end example
The following sections document the available services, starting with
the core services, that may be used in an @code{operating-system}
declaration.
@menu
* Base Services:: Essential system services.
* Networking Services:: Network setup, SSH daemon, etc.
* X Window:: Graphical display.
@node Base Services
@subsubsection Base Services
The @code{(gnu services base)} module provides definitions for the basic
services that one expects from the system. The services exported by
this module are listed below.
@defvr {Scheme Variable} %base-services
This variable contains a list of basic services@footnote{Technically,
this is a list of monadic services. @xref{The Store Monad}.} one would
expect from the system: a login service (mingetty) on each tty, syslogd,
libc's name service cache daemon (nscd), the udev device manager, and
more.
This is the default value of the @code{services} field of
@code{operating-system} declarations. Usually, when customizing a
system, you will want to append services to @var{%base-services}, like
this:
@end example
@end defvr
@deffn {Monadic Procedure} host-name-service @var{name}
Return a service that sets the host name to @var{name}.
@end deffn
@deffn {Monadic Procedure} mingetty-service @var{tty} [#:motd] @
[#:auto-login #f] [#:login-program] [#:login-pause? #f] @
[#:allow-empty-passwords? #f]
Return a service to run mingetty on @var{tty}.
When @var{allow-empty-passwords?} is true, allow empty log-in password. When
@var{auto-login} is true, it must be a user name under which to log-in
automatically. @var{login-pause?} can be set to @code{#t} in conjunction with
@var{auto-login}, in which case the user will have to press a key before the
login shell is launched.
When true, @var{login-program} is a gexp or a monadic gexp denoting the name
of the log-in program (the default is the @code{login} program from the Shadow
tool suite.)
@var{motd} is a monadic value containing a text file to use as
the ``message of the day''.
@end deffn
Ludovic Courtès
committed
@cindex name service cache daemon
@cindex nscd
@deffn {Monadic Procedure} nscd-service [@var{config}] [#:glibc glibc] @
[#:name-services '()]
Return a service that runs libc's name service cache daemon (nscd) with
the given @var{config}---an @code{<nscd-configuration>} object.
Optionally, @code{#:name-services} is a list of packages that provide
name service switch (NSS) modules needed by nscd.
Ludovic Courtès
committed
4426
4427
4428
4429
4430
4431
4432
4433
4434
4435
4436
4437
4438
4439
4440
4441
4442
4443
4444
4445
4446
4447
4448
4449
4450
4451
4452
4453
4454
4455
4456
4457
4458
4459
4460
4461
4462
4463
4464
4465
4466
4467
4468
4469
4470
4471
4472
4473
4474
4475
4476
4477
4478
4479
4480
4481
4482
4483
4484
4485
4486
4487
4488
4489
4490
4491
4492
4493
4494
4495
4496
4497
4498
4499
4500
4501
4502
4503
@defvr {Scheme Variable} %nscd-default-configuration
This is the default @code{<nscd-configuration>} value (see below) used
by @code{nscd-service}. This uses the caches defined by
@var{%nscd-default-caches}; see below.
@end defvr
@deftp {Data Type} nscd-configuration
This is the type representing the name service cache daemon (nscd)
configuration.
@table @asis
@item @code{log-file} (default: @code{"/var/log/nscd.log"})
Name of nscd's log file. This is where debugging output goes when
@code{debug-level} is strictly positive.
@item @code{debug-level} (default: @code{0})
Integer denoting the debugging levels. Higher numbers mean more
debugging output is logged.
@item @code{caches} (default: @var{%nscd-default-caches})
List of @code{<nscd-cache>} objects denoting things to be cached; see
below.
@end table
@end deftp
@deftp {Data Type} nscd-cache
Data type representing a cache database of nscd and its parameters.
@table @asis
@item @code{database}
This is a symbol representing the name of the database to be cached.
Valid values are @code{passwd}, @code{group}, @code{hosts}, and
@code{services}, which designate the corresponding NSS database
(@pxref{NSS Basics,,, libc, The GNU C Library Reference Manual}).
@item @code{positive-time-to-live}
@itemx @code{negative-time-to-live} (default: @code{20})
A number representing the number of seconds during which a positive or
negative lookup result remains in cache.
@item @code{check-files?} (default: @code{#t})
Whether to check for updates of the files corresponding to
@var{database}.
For instance, when @var{database} is @code{hosts}, setting this flag
instructs nscd to check for updates in @file{/etc/hosts} and to take
them into account.
@item @code{persistent?} (default: @code{#t})
Whether the cache should be stored persistently on disk.
@item @code{shared?} (default: @code{#t})
Whether the cache should be shared among users.
@item @code{max-database-size} (default: 32@tie{}MiB)
Maximum size in bytes of the database cache.
@c XXX: 'suggested-size' and 'auto-propagate?' seem to be expert
@c settings, so leave them out.
@end table
@end deftp
@defvr {Scheme Variable} %nscd-default-caches
List of @code{<nscd-cache>} objects used by default by
@code{nscd-configuration} (see above.)
It enables persistent and aggressive caching of service and host name
lookups. The latter provides better host name lookup performance,
resilience in the face of unreliable name servers, and also better
privacy---often the result of host name lookups is in local cache, so
external name servers do not even need to be queried.
@end defvr
@deffn {Monadic Procedure} syslog-service [#:config-file #f]
Return a service that runs @code{syslogd}. If configuration file name
@var{config-file} is not specified, use some reasonable default
@deffn {Monadic Procedure} guix-service [#:guix guix] @
[#:builder-group "guixbuild"] [#:build-accounts 10] @
[#:authorize-hydra-key? #t] [#:use-substitutes? #t] @
[#:extra-options '()]
Return a service that runs the build daemon from @var{guix}, and has
@var{build-accounts} user accounts available under @var{builder-group}.
When @var{authorize-hydra-key?} is true, the @code{hydra.gnu.org} public key
provided by @var{guix} is authorized upon activation, meaning that substitutes
from @code{hydra.gnu.org} are used by default.
If @var{use-substitutes?} is false, the daemon is run with
@option{--no-substitutes} (@pxref{Invoking guix-daemon,
@option{--no-substitutes}}).
Finally, @var{extra-options} is a list of additional command-line options
passed to @command{guix-daemon}.
@end deffn
@deffn {Monadic Procedure} udev-service [#:udev udev]
Run @var{udev}, which populates the @file{/dev} directory dynamically.
@end deffn
@node Networking Services
@subsubsection Networking Services
The @code{(gnu services networking)} module provides services to configure
@cindex DHCP, networking service
@deffn {Monadic Procedure} dhcp-client-service [#:dhcp @var{isc-dhcp}]
Return a service that runs @var{dhcp}, a Dynamic Host Configuration
Protocol (DHCP) client, on all the non-loopback network interfaces.
@end deffn
@deffn {Monadic Procedure} static-networking-service @var{interface} @var{ip} @
[#:gateway #f] [#:name-services @code{'()}]
Return a service that starts @var{interface} with address @var{ip}. If
@var{gateway} is true, it must be a string specifying the default network
gateway.
@end deffn
@cindex wicd
@deffn {Monadic Procedure} wicd-service [#:wicd @var{wicd}]
Return a service that runs @url{https://launchpad.net/wicd,Wicd}, a
network manager that aims to simplify wired and wireless networking.
@end deffn
@deffn {Monadic Procedure} ntp-service [#:ntp @var{ntp}] @
[#:name-service @var{%ntp-servers}]
Return a service that runs the daemon from @var{ntp}, the
@uref{http://www.ntp.org, Network Time Protocol package}. The daemon will
keep the system clock synchronized with that of @var{servers}.
@end deffn
@defvr {Scheme Variable} %ntp-servers
List of host names used as the default NTP servers.
@end defvr
@deffn {Monadic Procedure} tor-service [#:tor tor]
Return a service to run the @uref{https://torproject.org,Tor} daemon.
The daemon runs with the default settings (in particular the default exit
policy) as the @code{tor} unprivileged user.
@end deffn
@deffn {Monadic Procedure} bitlbee-service [#:bitlbee bitlbee] @
[#:interface "127.0.0.1"] [#:port 6667] @
[#:extra-settings ""]
Return a service that runs @url{http://bitlbee.org,BitlBee}, a daemon that
acts as a gateway between IRC and chat networks.
The daemon will listen to the interface corresponding to the IP address
specified in @var{interface}, on @var{port}. @code{127.0.0.1} means that only
local clients can connect, whereas @code{0.0.0.0} means that connections can
come from any networking interface.
In addition, @var{extra-settings} specifies a string to append to the
configuration file.
@end deffn
Furthermore, @code{(gnu services ssh)} provides the following service.
@deffn {Monadic Procedure} lsh-service [#:host-key "/etc/lsh/host-key"] @
[#:daemonic? #t] [#:interfaces '()] [#:port-number 22] @
[#:allow-empty-passwords? #f] [#:root-login? #f] @
[#:syslog-output? #t] [#:x11-forwarding? #t] @
[#:tcp/ip-forwarding? #t] [#:password-authentication? #t] @
[#:public-key-authentication? #t] [#:initialize? #f]
Run the @command{lshd} program from @var{lsh} to listen on port @var{port-number}.
@var{host-key} must designate a file containing the host key, and readable
only by root.
When @var{daemonic?} is true, @command{lshd} will detach from the
controlling terminal and log its output to syslogd, unless one sets
@var{syslog-output?} to false. Obviously, it also makes lsh-service
depend on existence of syslogd service. When @var{pid-file?} is true,
@command{lshd} writes its PID to the file called @var{pid-file}.
When @var{initialize?} is true, automatically create the seed and host key
upon service activation if they do not exist yet. This may take long and
require interaction.
When @var{initialize?} is false, it is up to the user to initialize the
randomness generator (@pxref{lsh-make-seed,,, lsh, LSH Manual}), and to create
a key pair with the private key stored in file @var{host-key} (@pxref{lshd
basics,,, lsh, LSH Manual}).
When @var{interfaces} is empty, lshd listens for connections on all the
network interfaces; otherwise, @var{interfaces} must be a list of host names
or addresses.
@var{allow-empty-passwords?} specifies whether to accept log-ins with empty
passwords, and @var{root-login?} specifies whether to accept log-ins as
The other options should be self-descriptive.
@end deffn
@defvr {Scheme Variable} %facebook-host-aliases
This variable contains a string for use in @file{/etc/hosts}
(@pxref{Host Names,,, libc, The GNU C Library Reference Manual}). Each
line contains a entry that maps a known server name of the Facebook
on-line service---e.g., @code{www.facebook.com}---to the local
host---@code{127.0.0.1} or its IPv6 equivalent, @code{::1}.
This variable is typically used in the @code{hosts-file} field of an
@code{operating-system} declaration (@pxref{operating-system Reference,
@file{/etc/hosts}}):
@example
(use-modules (gnu) (guix))
(operating-system
(host-name "mymachine")
;; ...
(hosts-file
;; Create a /etc/hosts file with aliases for "localhost"
;; and "mymachine", as well as for Facebook servers.
(text-file "hosts"
(string-append (local-host-aliases host-name)
%facebook-host-aliases))))
@end example
This mechanism can prevent programs running locally, such as Web
browsers, from accessing Facebook.
@end defvr
@node X Window
@subsubsection X Window
Support for the X Window graphical display system---specifically
Xorg---is provided by the @code{(gnu services xorg)} module. Note that
there is no @code{xorg-service} procedure. Instead, the X server is
started by the @dfn{login manager}, currently SLiM.
@deffn {Monadic Procedure} slim-service [#:allow-empty-passwords? #f] @
[#:auto-login? #f] [#:default-user ""] [#:startx] @
[#:theme @var{%default-slim-theme}] @
Sou Bunnbu (宋文武)
committed
[#:theme-name @var{%default-slim-theme-name}]
Return a service that spawns the SLiM graphical login manager, which in
turn starts the X display server with @var{startx}, a command as returned by
@code{xorg-start-command}.
When @var{allow-empty-passwords?} is true, allow logins with an empty
password. When @var{auto-login?} is true, log in automatically as
@var{default-user}.
If @var{theme} is @code{#f}, the use the default log-in theme; otherwise
@var{theme} must be a gexp denoting the name of a directory containing the
theme to use. In that case, @var{theme-name} specifies the name of the
theme.
@defvr {Scheme Variable} %default-theme
@defvrx {Scheme Variable} %default-theme-name
The G-Expression denoting the default SLiM theme and its name.
@end defvr
@deffn {Monadic Procedure} xorg-start-command [#:guile] @
[#:drivers '()] [#:resolutions '()] [#:xorg-server @var{xorg-server}]
Return a derivation that builds a @var{guile} script to start the X server
from @var{xorg-server}. Usually the X server is started by a login manager.
@var{drivers} must be either the empty list, in which case Xorg chooses a
graphics driver automatically, or a list of driver names that will be tried in
this order---e.g., @code{("modesetting" "vesa")}.
Likewise, when @var{resolutions} is the empty list, Xorg chooses an
appropriate screen resolution; otherwise, it must be a list of
resolutions---e.g., @code{((1024 768) (640 480))}.
@end deffn
@node Various Services
@subsubsection Various Services
The @code{(gnu services lirc)} module provides the following service.
@deffn {Monadic Procedure} lirc-service [#:lirc lirc] @
[#:device #f] [#:driver #f] [#:config-file #f] @
[#:extra-options '()]
Return a service that runs @url{http://www.lirc.org,LIRC}, a daemon that
decodes infrared signals from remote controls.
Optionally, @var{device}, @var{driver} and @var{config-file}
(configuration file name) may be specified. See @command{lircd} manual
for details.
Finally, @var{extra-options} is a list of additional command-line options
passed to @command{lircd}.
@end deffn
4723
4724
4725
4726
4727
4728
4729
4730
4731
4732
4733
4734
4735
4736
4737
4738
4739
4740
4741
4742
4743
4744
4745
4746
4747
4748
4749
4750
4751
4752
4753
4754
4755
4756
4757
4758
4759
4760
4761
4762
4763
4764
4765
4766
4767
4768
@node Setuid Programs
@subsection Setuid Programs
@cindex setuid programs
Some programs need to run with ``root'' privileges, even when they are
launched by unprivileged users. A notorious example is the
@command{passwd} programs, which can users can run to change their
password, and which requires write access to the @file{/etc/passwd} and
@file{/etc/shadow} files---something normally restricted to root, for
obvious security reasons. To address that, these executables are
@dfn{setuid-root}, meaning that they always run with root privileges
(@pxref{How Change Persona,,, libc, The GNU C Library Reference Manual},
for more info about the setuid mechanisms.)
The store itself @emph{cannot} contain setuid programs: that would be a
security issue since any user on the system can write derivations that
populate the store (@pxref{The Store}). Thus, a different mechanism is
used: instead of changing the setuid bit directly on files that are in
the store, we let the system administrator @emph{declare} which programs
should be setuid root.
The @code{setuid-programs} field of an @code{operating-system}
declaration contains a list of G-expressions denoting the names of
programs to be setuid-root (@pxref{Using the Configuration System}).
For instance, the @command{passwd} program, which is part of the Shadow
package, can be designated by this G-expression (@pxref{G-Expressions}):
@example
#~(string-append #$shadow "/bin/passwd")
@end example
A default set of setuid programs is defined by the
@code{%setuid-programs} variable of the @code{(gnu system)} module.
@defvr {Scheme Variable} %setuid-programs
A list of G-expressions denoting common programs that are setuid-root.
The list includes commands such as @command{passwd}, @command{ping},
@command{su}, and @command{sudo}.
@end defvr
Under the hood, the actual setuid programs are created in the
@file{/run/setuid-programs} directory at system activation time. The
files in this directory refer to the ``real'' binaries, which are in the
store.
4769
4770
4771
4772
4773
4774
4775
4776
4777
4778
4779
4780
4781
4782
4783
4784
4785
4786
4787
4788
4789
4790
4791
4792
4793
4794
4795
4796
4797
4798
4799
4800
4801
4802
4803
4804
4805
4806
4807
4808
4809
4810
4811
4812
4813
4814
4815
4816
4817
4818
4819
4820
4821
4822
4823
4824
4825
4826
4827
4828
4829
4830
4831
4832
4833
4834
4835
4836
4837
4838
4839
4840
4841
4842
4843
4844
4845
4846
4847
4848
4849
4850
4851
4852
4853
4854
4855
4856
4857
4858
4859
4860
4861
4862
4863
4864
4865
4866
@node Name Service Switch
@subsection Name Service Switch
@cindex name service switch
@cindex NSS
The @code{(gnu system nss)} module provides bindings to the
configuration file of libc's @dfn{name service switch} or @dfn{NSS}
(@pxref{NSS Configuration File,,, libc, The GNU C Library Reference
Manual}). In a nutshell, the NSS is a mechanism that allows libc to be
extended with new ``name'' lookup methods for system databases, which
includes host names, service names, user accounts, and more (@pxref{Name
Service Switch, System Databases and Name Service Switch,, libc, The GNU
C Library Reference Manual}).
The NSS configuration specifies, for each system database, which lookup
method is to be used, and how the various methods are chained
together---for instance, under which circumstances NSS should try the
next method in the list. The NSS configuration is given in the
@code{name-service-switch} field of @code{operating-system} declarations
(@pxref{operating-system Reference, @code{name-service-switch}}).
@c See <http://0pointer.de/lennart/projects/nss-mdns/>.
As an example, the declaration below configures the NSS to use the
@code{nss-mdns} back-end for host name lookups:
@example
(name-service-switch
(hosts (list %files ;first, check /etc/hosts
;; If the above did not succeed, try
;; with 'mdns_minimal'.
(name-service
(name "mdns_minimal")
;; 'mdns_minimal' is authoritative for
;; '.local'. When it returns "not found",
;; no need to try the next methods.
(reaction (lookup-specification
(not-found => return))))
;; Then fall back to DNS.
(name-service
(name "dns"))
;; Finally, try with the "full" 'mdns'.
(name-service
(name "mdns")))))
@end example
The reference for name service switch configuration is given below. It
is a direct mapping of the C library's configuration file format, so
please refer to the C library manual for more information (@pxref{NSS
Configuration File,,, libc, The GNU C Library Reference Manual}).
Compared to libc's NSS configuration file format, it has the advantage
not only of adding this warm parenthetic feel that we like, but also
static checks: you'll know about syntax errors and typos as soon as you
run @command{guix system}.
@defvr {Scheme Variable} %default-nss
This is the default name service switch configuration, a
@code{name-service-switch} object.
@end defvr
@deftp {Data Type} name-service-switch
This is the data type representation the configuration of libc's name
service switch (NSS). Each field below represents one of the supported
system databases.
@table @code
@item aliases
@itemx ethers
@itemx group
@itemx gshadow
@itemx hosts
@itemx initgroups
@itemx netgroup
@itemx networks
@itemx password
@itemx public-key
@itemx rpc
@itemx services
@itemx shadow
The system databases handled by the NSS. Each of these fields must be a
list of @code{<name-service>} objects (see below.)
@end table
@end deftp
@deftp {Data Type} name-service
This is the data type representing an actual name service and the
associated lookup action.
@table @code
@item name
A string denoting the name service (@pxref{Services in the NSS
configuration,,, libc, The GNU C Library Reference Manual}).
Note that name services listed here must be visible to nscd. This is
achieved by passing the @code{#:name-services} argument to
@code{nscd-service} the list of packages providing the needed name
services (@pxref{Base Services, @code{nscd-service}}).
@item reaction
An action specified using the @code{lookup-specification} macro
(@pxref{Actions in the NSS configuration,,, libc, The GNU C Library
Reference Manual}). For example:
@example
(lookup-specification (unavailable => continue)
(success => return))
@end example
@end table
@end deftp
4884
4885
4886
4887
4888
4889
4890
4891
4892
4893
4894
4895
4896
4897
4898
4899
4900
4901
4902
4903
4904
4905
4906
@node Initial RAM Disk
@subsection Initial RAM Disk
@cindex initial RAM disk (initrd)
@cindex initrd (initial RAM disk)
For bootstrapping purposes, the Linux-Libre kernel is passed an
@dfn{initial RAM disk}, or @dfn{initrd}. An initrd contains a temporary
root file system, as well as an initialization script. The latter is
responsible for mounting the real root file system, and for loading any
kernel modules that may be needed to achieve that.
The @code{initrd} field of an @code{operating-system} declaration allows
you to specify which initrd you would like to use. The @code{(gnu
system linux-initrd)} module provides two ways to build an initrd: the
high-level @code{base-initrd} procedure, and the low-level
@code{expression->initrd} procedure.
The @code{base-initrd} procedure is intended to cover most common uses.
For example, if you want to add a bunch of kernel modules to be loaded
at boot time, you can define the @code{initrd} field of the operating
system declaration like this:
@example
(initrd (lambda (file-systems . rest)
;; Create a standard initrd that has modules "foo.ko"
;; and "bar.ko", as well as their dependencies, in
;; addition to the modules available by default.
(apply base-initrd file-systems
#:extra-modules '("foo" "bar")
rest)))
The @code{base-initrd} procedure also handles common use cases that
involves using the system as a QEMU guest, or as a ``live'' system whose
root file system is volatile.
@deffn {Monadic Procedure} base-initrd @var{file-systems} @
[#:qemu-networking? #f] [#:virtio? #f] [#:volatile-root? #f] @
[#:extra-modules '()] [#:mapped-devices '()]
Return a monadic derivation that builds a generic initrd. @var{file-systems} is
a list of file-systems to be mounted by the initrd, possibly in addition to
the root file system specified on the kernel command line via @code{--root}.
@var{mapped-devices} is a list of device mappings to realize before
@var{file-systems} are mounted (@pxref{Mapped Devices}).
4928
4929
4930
4931
4932
4933
4934
4935
4936
4937
4938
4939
4940
4941
4942
4943
4944
4945
4946
4947
4948
4949
When @var{qemu-networking?} is true, set up networking with the standard QEMU
parameters. When @var{virtio?} is true, load additional modules so the initrd can
be used as a QEMU guest with para-virtualized I/O drivers.
When @var{volatile-root?} is true, the root file system is writable but any changes
to it are lost.
The initrd is automatically populated with all the kernel modules necessary
for @var{file-systems} and for the given options. However, additional kernel
modules can be listed in @var{extra-modules}. They will be added to the initrd, and
loaded at boot time in the order in which they appear.
@end deffn
Needless to say, the initrds we produce and use embed a
statically-linked Guile, and the initialization program is a Guile
program. That gives a lot of flexibility. The
@code{expression->initrd} procedure builds such an initrd, given the
program to run in that initrd.
@deffn {Monadic Procedure} expression->initrd @var{exp} @
[#:guile %guile-static-stripped] [#:name "guile-initrd"] @
[#:modules '()]
Return a derivation that builds a Linux initrd (a gzipped cpio archive)
containing @var{guile} and that evaluates @var{exp}, a G-expression,
upon booting. All the derivations referenced by @var{exp} are
automatically copied to the initrd.
@var{modules} is a list of Guile module names to be embedded in the
initrd.
4960
4961
4962
4963
4964
4965
4966
4967
4968
4969
4970
4971
4972
4973
4974
4975
4976
4977
4978
4979
4980
4981
4982
4983
4984
4985
4986
4987
4988
4989
4990
4991
4992
4993
4994
4995
4996
4997
4998
4999
5000
@node GRUB Configuration
@subsection GRUB Configuration
@cindex GRUB
@cindex boot loader
The operating system uses GNU@tie{}GRUB as its boot loader
(@pxref{Overview, overview of GRUB,, grub, GNU GRUB Manual}). It is
configured using @code{grub-configuration} declarations. This data type
is exported by the @code{(gnu system grub)} module, and described below.
@deftp {Data Type} grub-configuration
The type of a GRUB configuration declaration.
@table @asis
@item @code{device}
This is a string denoting the boot device. It must be a device name
understood by the @command{grub-install} command, such as
@code{/dev/sda} or @code{(hd0)} (@pxref{Invoking grub-install,,, grub,
GNU GRUB Manual}).
@item @code{menu-entries} (default: @code{()})
A possibly empty list of @code{menu-entry} objects (see below), denoting
entries to appear in the GRUB boot menu, in addition to the current
system entry and the entry pointing to previous system generations.
@item @code{default-entry} (default: @code{0})
The index of the default boot menu entry. Index 0 is for the current
system's entry.
@item @code{timeout} (default: @code{5})
The number of seconds to wait for keyboard input before booting. Set to
0 to boot immediately, and to -1 to wait indefinitely.
@item @code{theme} (default: @var{%default-theme})
The @code{grub-theme} object describing the theme to use.
@end table
@end deftp