about summary refs log tree commit diff
path: root/src/libstore/build.cc (follow)
AgeCommit message (Collapse)AuthorFilesLines
2012-07-30 Refactor settings processingEelco Dolstra1-99/+77
Put all Nix configuration flags in a Settings object.
2012-07-30 Pass configuration settings to the substitutersEelco Dolstra1-0/+4
Previously substituters could read nix.conf themselves, but this didn't take --option flags into account.
2012-07-27 Let build.cc verify the expected hash of a substituter's outputEelco Dolstra1-6/+33
Since SubstitutionGoal::finished() in build.cc computes the hash anyway, we can prevent the inefficiency of computing the hash twice by letting the substituter tell Nix about the expected hash, which can then verify it.
2012-07-27 Remove more tabsEelco Dolstra1-9/+9
2012-07-27 Remove trailing whitespace / tabsEelco Dolstra1-130/+130
2012-07-26 Merge branch 'master' into no-manifestsEelco Dolstra1-1/+6
2012-07-26 Set permissions on temporary build directories to 0700Eelco Dolstra1-1/+2
Fixes #39.
2012-07-23 Automatically optimise the Nix store when a new path is addedEelco Dolstra1-0/+4
Auto-optimisation is enabled by default. It can be turned off by setting auto-optimise-store to false in nix.conf.
2012-07-18 Merge branch 'master' into no-manifestsEelco Dolstra1-12/+29
2012-07-17 Return an exit code of 100 for cached failed buildsEelco Dolstra1-0/+1
Exit code 100 should be returned for all permanent failures. This includes cached failures. Fixes #34.
2012-07-17 Update Nix 1.1 release notesEelco Dolstra1-0/+3
2012-07-17 Allow disabling log compressionEelco Dolstra1-12/+25
2012-07-08 build.cc: Don't use hasSubstitute()Eelco Dolstra1-11/+25
Instead make a single call to querySubstitutablePathInfo() per derivation output. This is faster and prevents having to implement the "have" function in the binary cache substituter.
2012-07-06 download-from-binary-cache: parallelise fetching of NAR info filesEelco Dolstra1-4/+6
Getting substitute information using the binary cache substituter has non-trivial latency overhead. A package or NixOS system configuration can have hundreds of dependencies, and in the worst case (when the local info cache is empty) we have to do a separate HTTP request for each of these. If the ping time to the server is t, getting N info files will take tN seconds; e.g., with a ping time of 0.1s to nixos.org, sequentially downloading 1000 info files (a typical NixOS config) will take at least 100 seconds. To fix this problem, the binary cache substituter can now perform requests in parallel. This required changing the substituter interface to support a function querySubstitutablePathInfos() that queries multiple paths at the same time, and rewriting queryMissing() to take advantage of parallelism. (Due to local caching, parallelising queryMissing() is sufficient for most use cases, since it's almost always called before building a derivation and thus fills the local info cache.) For example, parallelism speeds up querying all 1056 paths in a particular NixOS system configuration from 116s to 2.6s. It works so well because the eccentricity of the top-level derivation in the dependency graph is only 9. So we only need 10 round-trips (when using an unlimited number of parallel connections) to get everything. Currently we do a maximum of 150 parallel connections to the server. Thus it's important that the binary cache server (e.g. nixos.org) has a high connection limit. Alternatively we could use HTTP pipelining, but WWW::Curl doesn't support it and libcurl has a hard-coded limit of 5 requests per pipeline.
2012-06-27 nix-store -r: do substitutions in parallelEelco Dolstra1-4/+9
I.e. when multiple non-derivation arguments are passed to ‘nix-store -r’ to be substituted, do them in parallel.
2012-06-27 Mount an empty /dev/shm tmpfs in the chrootEelco Dolstra1-0/+6
This ensures that whatever the builder writes in /dev/shm is automatically cleaned up.
2012-06-27 Check the return code of the clone() callEelco Dolstra1-1/+2
2012-06-25 When using chroots, use a private PID namespaceEelco Dolstra1-154/+181
In a private PID namespace, processes have PIDs that are separate from the rest of the system. The initial child gets PID 1. Processes in the chroot cannot see processes outside of the chroot. This improves isolation between builds. However, processes on the outside can see processes in the chroot and send signals to them (if they have appropriate rights). Since the builder gets PID 1, it serves as the reaper for zombies in the chroot. This might turn out to be a problem. In that case we'll need to have a small PID 1 process that sits in a loop calling wait().
2012-06-25 Use a private UTS namespace to provide a deterministic host/domain name to ↵Eelco Dolstra1-1/+7
builders In chroot builds, set the host name to "localhost" and the domain name to "(none)" (the latter being the kernel's default). This improves determinism a bit further. P.S. I have to idea what UTS stands for.
2012-06-23 Improve error messageEelco Dolstra1-1/+1
2012-06-23 In chroot builds, use a private SysV IPC namespaceEelco Dolstra1-12/+19
This improves isolation a bit further, and it's just one extra flag in the unshare() call. P.S. It would be very cool to use CLONE_NEWPID (to put the builder in a private PID namespace) as well, but that's slightly more risky since having a builder start as PID 1 may cause problems.
2012-06-23 In chroot builds, use a private network namespaceEelco Dolstra1-6/+31
On Linux it's possible to run a process in its own network namespace, meaning that it gets its own set of network interfaces, disjunct from the rest of the system. We use this to completely remove network access to chroot builds, except that they get a private loopback interface. This means that: - Builders cannot connect to the outside network or to other processes on the same machine, except processes within the same build. - Vice versa, other processes cannot connect to processes in a chroot build, and open ports/connections do not show up in "netstat". - If two concurrent builders try to listen on the same port (e.g. as part of a test), they no longer conflict with each other. This was inspired by the "PrivateNetwork" flag in systemd.
2012-05-30 Compress build logs on the fly using bzip2Eelco Dolstra1-10/+44
2012-05-29 Add option ‘build-keep-log’ to enable/disable writing of build logsEelco Dolstra1-1/+4
Fixes #26.
2012-04-30 * Add an option ‘build-use-substitutes’, which can be set to ‘false’Eelco Dolstra1-1/+1
to disable use of substitutes; i.e., force building from source. Fixes Nix/221.
2012-04-30 Handle EPERM when creating a hard link for the chrootEelco Dolstra1-2/+5
There is a race condition when doing parallel builds with chroots and the immutable bit enabled. One process may call makeImmutable() before the other has called link(), in which case link() will fail with EPERM. We could retry or wrap the operation in a lock, but since this condition is rare and I'm lazy, we just use the existing copy fallback. Fixes #9.
2012-04-15 Close almost all file descriptors in the builderEelco Dolstra1-0/+3
This regression was accidentally introduced in 35355fc1fcffbe859395e360c0a6a1463f137d63.
2012-04-05 On Linux, pretend we're building on Linux 2.6Eelco Dolstra1-0/+11
Setting the UNAME26 personality causes "uname" to return "2.6.x", regardless of the kernel version. This improves determinism in a few misbehaved packages.
2012-03-05 Set the close-on-exec flag on file descriptorsEelco Dolstra1-3/+2
2012-03-05 Don't leak a file descriptor in commonChildInit()Eelco Dolstra1-0/+1
2012-03-01 Fix an uninitialised variableEelco Dolstra1-0/+1
The variable ‘useChroot’ was not initialised properly. This caused random failures if using the build hook. Seen on Mac OS X 10.7 with Clang. Thanks to KolibriFX for finding this :-)
2012-02-18 Fix chroots buildsEelco Dolstra1-0/+16
Chroots are initialised by hard-linking inputs from the Nix store to the chroot. This doesn't work if the input has its immutable bit set, because it's forbidden to create hard links to immutable files. So temporarily clear the immutable bit when creating and destroying the chroot. Note that making regular files in the Nix store immutable isn't very reliable, since the bit can easily become cleared: for instance, if we run the garbage collector after running ‘nix-store --optimise’. So maybe we should only make directories immutable.
2012-02-09 Use data() instead of c_str() where appropriateEelco Dolstra1-5/+5
2011-12-30 * Reject a build if there is a cycle among the outputs. This isEelco Dolstra1-5/+2
necessary because existing code assumes that the references graph is acyclic.
2011-12-25 * Make sure that lock files are cleaned up properly when buildingEelco Dolstra1-7/+7
through the build hook.
2011-11-29 * Get rid of some superfluous error messages if a substituter fails.Eelco Dolstra1-15/+6
* Say "fetch" instead of "substitute".
2011-11-21 nix: add /etc/hosts with localhost entry to chroot builds.Rob Vermaas1-0/+3
2011-08-31 * Eliminate all uses of the global variable ‘store’ from libstore.Eelco Dolstra1-8/+8
This should also fix: nix-instantiate: ./../boost/shared_ptr.hpp:254: T* boost::shared_ptr<T>::operator->() const [with T = nix::StoreAPI]: Assertion `px != 0' failed. which was caused by hashDerivationModulo() calling the ‘store’ object (during store upgrades) before openStore() assigned it.
2011-07-20 * Fix a huuuuge security hole in the Nix daemon. It didn't check thatEelco Dolstra1-12/+3
derivations added to the store by clients have "correct" output paths (meaning that the output paths are computed by hashing the derivation according to a certain algorithm). This means that a malicious user could craft a special .drv file to build *any* desired path in the store with any desired contents (so long as the path doesn't already exist). Then the attacker just needs to wait for a victim to come along and install the compromised path. For instance, if Alice (the attacker) knows that the latest Firefox derivation in Nixpkgs produces the path /nix/store/1a5nyfd4ajxbyy97r1fslhgrv70gj8a7-firefox-5.0.1 then (provided this path doesn't already exist) she can craft a .drv file that creates that path (i.e., has it as one of its outputs), add it to the store using "nix-store --add", and build it with "nix-store -r". So the fake .drv could write a Trojan to the Firefox path. Then, if user Bob (the victim) comes along and does $ nix-env -i firefox $ firefox he executes the Trojan injected by Alice. The fix is to have the Nix daemon verify that derivation outputs are correct (in addValidPath()). This required some refactoring to move the hash computation code to libstore.
2011-06-30 Add support for the `build-timeout' and `--timeout' options.Ludovic Courtès1-4/+30
2010-12-13 * nix-instantiate: return exit status 100 to denote a permanent buildEelco Dolstra1-3/+16
failure. The build hook can use this to distinguish between transient and permanent failures on the remote side.
2010-12-13 * Update some comments.Eelco Dolstra1-1/+1
2010-11-16 * Store the size of a store path in the database (to be precise, theEelco Dolstra1-16/+25
size of the NAR serialisation of the path, i.e., `nix-store --dump PATH'). This is useful for Hydra.
2010-08-31 * Always print hook output on stderr, even if --no-build-output isEelco Dolstra1-4/+12
set. * In the build hook, print a trace message to allow Hydra to pick up the name of the remote machine used for the build.
2010-08-30 * When using the build hook, distinguish between the stderr of theEelco Dolstra1-11/+29
hook script proper, and the stdout/stderr of the builder. Only the latter should be saved in /nix/var/log/nix/drvs. * Allow the verbosity to be set through an option. * Added a flag --quiet to lower the verbosity level.
2010-08-27 * Experimental feature: allow a derivation to tell the build hook thatEelco Dolstra1-2/+10
it requires a certain feature on the build machine, e.g. requiredSystemFeatures = [ "kvm" ]; We need this in Hydra to make sure that builds that require KVM support are forwarded to machines that have KVM support. Probably this should also be enforced for local builds.
2010-08-25 * Made the build hook mechanism more efficient. Rather than startingEelco Dolstra1-203/+187
the hook every time we want to ask whether we can run a remote build (which can be very often), we now reuse a hook process for answering those queries until it accepts a build. So if there are N derivations to be built, at most N hooks will be started.
2010-08-24 * Handle the unlikely case where a derivation has no dependencies atEelco Dolstra1-1/+4
all.
2010-08-04 * Sync with the trunk.Eelco Dolstra1-0/+5
2010-08-04 * Allow derivations to hint that they should not be built remotelyEelco Dolstra1-23/+39
using the build hook mechanism, by setting the derivation attribute "preferLocalBuild" to true. This has a few use cases: - The user environment builder. Since it just creates a bunch of symlinks without much computation, there is no reason to do it remotely. In fact, doing it remotely requires the entire closure of the user environment to be copied to the remote machine, which is extremely wasteful. - `fetchurl'. Performing the download on a remote machine and then copying it to the local machine involves twice as much network traffic as performing the download locally, and doesn't save any CPU cycles on the local machine.