I'm trying to install external binary inside NixOS, using declarative ways. Inside nix-pkg manual, I found such way of getting external binary inside NixOS
{ pkgs ? import <nixpkgs> {} }:
pkgs.stdenv.mkDerivation {
name = "goss";
src = pkgs.fetchurl {
url = "https://github.com/aelsabbahy/goss/releases/download/v0.3.13/goss-linux-amd64";
sha256 = "1q0kfdbifffszikcl0warzmqvsbx4bg19l9a3vv6yww2jvzj4dgb";
};
phases = ["installPhase"];
installPhase = ''
'';
But I'm wondering, what should I add inside InstallPhase, to make this binary being installed inside the system?
This seems to be an open source Go application, so it's preferable to use Nixpkgs' Go support instead, which may be more straightforward than patching a binary.
That said, installPhase is responsible creating the $out path; typically mkdir -p $out/bin followed by cp, make install or similar commands.
So that's not actually installing it into the system; after all Nix derivations are not supposed to have side effects. "Installing" it into the system is the responsibility of NixOS's derivations, as configured by you.
You could say that 'installation' is the combination of modifying the NixOS configuration + switching to the new NixOS. I tend to think about the modification to the configuration only; the build and switch feel like implementation details, even though nixos-rebuild is usually a manual operation.
Example:
installPhase = ''
install -D $src $out/bin/goss
chmod a+x $out/bin/goss
'';
Normally chmod would be done to a local file by the build phase, but we don't really need that phase here.
I have no idea why this was so hard to figure out. Having robust configuration systems is fine, but at the end of the day sometimes you just need to be able to download and expose a single flipping file on the $PATH.
The result of fetchurl is "the unaltered contents of the URL within the Nix store", which is being used for the src. So in installPhase, $src points to the downloaded data, and you just have to copy/install/link that into $out/…..
pkgs.stdenv.mkDerivation {
name = "hello_static";
src = pkgs.fetchurl {
name = "hello_static";
url = "https://raw.githubusercontent.com/ruanyf/simple-bash-scripts/6e837f949010e0f5e9305e629da946de12cc63e8/scripts/hello-world.sh";
sha256 = "sha256:somE27ajbm0TtWv9tyeqTWDW3gbIs6xvlcFS9QS1ZJ0=";
};
phases = [ "installPhase" ];
installPhase = ''
install -D $src $out/bin/hello_static
'';
};
Related
I am working a Puppet manifest that configures a router in the equipment that I support. The router runs pretty much plain vanilla Debian 8 or 9.
The problem is in the way the SSD on the router is partitioned.I am not able to change the partitioning, so have to work around the fact that the root file system is small. I have found a solution that I am trying to implement in Puppet but my first attempt doesn't feel right to me so I thought I would ask the community.
I have been and am reading the Puppet docs. Unfortunately I don't have my router hand to play with today so I am unable to test my current solution.
My issue is that by df -H the root file system is at 95% capacity and puppet is failing complaining about not enough space. Because of quirky decisions made a long time ago by others, the /opt/ file system is 5 times the size of / and is at 10% usage.
So my solution, tested manually, is to move /var/cache/apt/archives/ to /opt/apt-archives and then create a symlink using:
ln -s /opt/apt-archives /var/cache/apt/archives
That works and allows the puppet run to finish without errors.
My challenge is to implement this operation in a Puppet class
class bh::profiles::move_files {
$source_dir = '/var/cache/apt/archives'
$target_dir = '/opt/apt-cache'
file { $targetDir :
ensure => 'directory',
source => "file://${source_dir}",
recurse => true,
before => File[$source_dir]
}
file { $source_dir :
ensure => 'absent',
purge => true,
resurse => true,
force => true,
ensure => link,
target => "file://${target_dir}"
}
}
It just doesn't feel right to have ensure repeated in one file resource. And based on what I understand of creating links in puppet I would need the same name for the file resource that deletes the archives directory and the one that creates the link.
What am I missing?
Use exec:
exec { 'Link /var/cache/apt/archives':
command => 'mv /var/cache/apt/archives /opt/apt-archives
ln -s /opt/apt-archives /var/cache/apt/archives',
path => '/bin',
unless => 'test -L /var/cache/apt/archives',
}
Note that Puppet was not really designed to solve automation problems like this one, although using Exec it is possible to do most things anyway.
Your solution sounds like a work-around and it is therefore totally ok to implement a work-around using Exec. I would say, just make sure you add some comments explaining why you had to do something like this.
I have a small custom fact in a my php module
Facter.add('php_extension_version') do
setcode do
Facter::Core::Execution.exec("php -i | awk '/^PHP Extension =>/ { print $4}'") || nil
end
end
This obviously requires the php binary to be installed. However, I noticed that all facts are run once before applying the catalog, so this fact is invalid before php installed.
Is there any way of gathering the information after the module is installed? Is there perhaps another way of exposing this information except facter?
Update
I'm using the two facts to determine which of multiple .so files is the right one to install:
if $php_zts_enabled {
$so_name = "newrelic-$php_extension_version.so"
} else {
$so_name = "newrelic-$php_extension_version-zts.so"
}
file {"/usr/lib64/php5/extensions/newrelic.so":
source => "file:///opt/newrelic-php5-$version-linux/agent/x64/$so_name",
owner => root,
group => root,
mode => 0644,
notify => Service['apache'],
require => Exec["extract-php-agent-$version"]
}
The files that are located in the agent/x64 directory can be
newrelic-20060613.so newrelic-20090626-zts.so newrelic-20121212.so newrelic-20131226-zts.so
newrelic-20060613-zts.so newrelic-20100525.so newrelic-20121212-zts.so
newrelic-20090626.so newrelic-20100525-zts.so newrelic-20131226.so
You essentially have only two opportunities to execute code on the node:
As part of a Facter fact. As you are aware, this happens before puppet applies a catalog, so any facts dependent on the results of the puppet run will not be useful until the next run.
As part of a custom provider. You can create a custom type and provider for installing the extensions that checks the node state before deciding what to do. Providers execute on the node, and as long as you know the overall provider lifecycle you can make this happen after the PHP install. However, this is incredibly complex compared to normal puppet modules.
Outside of those options, the normal way of doing this would be to enforce the version and configuration of php within your own manifests, and then pass that information to here. You should already know the version of PHP and its extensions based on what packages you have installed.
I would modify the fact so that it's present only when the binary is present (hence it won't be present at the very first run).
Facter.add('php_extension_version') do
setcode do
if system("which php > /dev/null 2>&1")
Facter::Core::Execution.exec("php -i | awk '/^PHP Extension =>/ { print $4}'") || nil
end
end
end
and then in your manifest you'd wrap the original code in the if
if $php_extension_version {
if $php_zts_enabled {
$so_name = "newrelic-$php_extension_version.so"
} else {
$so_name = "newrelic-$php_extension_version-zts.so"
}
file {"/usr/lib64/php5/extensions/newrelic.so":
source => "file:///opt/newrelic-php5-$version-linux/agent/x64/$so_name",
owner => root,
group => root,
mode => 0644,
notify => Service['apache'],
require => Exec["extract-php-agent-$version"]
}
}
I am facing a issue while trying configuring something with CFENGINE3.5, I have created a policy to install some package from source, which download tar balls from some url and then untar it and further digs it with make and make install, everything working fine except while it download tar balls it keeps at "/etc" location, I want cfengine to put this file at /tmp.
Is there any way to customize this default behavior of cfengine to keep all temporary downloaded files at "/tmp" instead of "/etc".
Here is the Policy snippet:
bundle agent install
{
vars:
"packages" slist => {
"Algorithm-Diff-1.1902",
"Apache-DB-0.13",
"Apache-DBI-1.06",
"Apache-Session-1.83",
"Apache-SessionX-2.01",
"AppConfig-1.65",
"Archive-Tar-1.32",
};
commands:
"/usr/bin/wget http://10.X.X.X/downloads/perl-modules/$(packages).tar.gz;
/usr/bin/gunzip $(packages).tar.gz;
tar -xf $(packages).tar;
cd $(packages);
/usr/bin/perl Makefile.PL;
/usr/bin/make;
/usr/bin/make install;"
contain => standard,
classes => satisfied(canonify("$(packages)-installed"));
}
body contain standard
{
useshell => "true";
exec_owner => "root";
}
Thanks in advance.
You can add the directory in which the commands should be executed to the contain body, like this:
body contain standard
{
useshell => "true";
exec_owner => "root";
chdir => "/tmp";
}
Please note there are already a few contain bodies in the standard library (lib/3.5/commands.cf), maybe one of those can be used so you don't have to write your own. Note that CFEngine already executes as root, so exec_owner => "root" is not strictly necessary.
I have to create one CFENGINE 3 Policy which should take input from defined input list and then want to perform some bunch of commands on that set one by one.
For Eg:
For only one Package here I have the example:
bundle agent test_tester_install
{
commands:
"/usr/bin/wget http://something.example.com/perl-modules/Test-Tester-0.104.tar.gz;
/usr/bin/gunzip Test-Tester-0.104.tar.gz;
tar -xf Test-Tester-0.104.tar;
cd Test-Tester-0.104;
/usr/bin/perl Makefile.PL;
/usr/bin/make;
/usr/bin/make install"
contain => standard,
classes => satisfied("Test-Tester Installed");
}
body contain standard
{
useshell => "true";
exec_owner => "root";
}
body classes satisfied(new_class)
{
promise_repaired => { "$(new_class)" };
}
But I am not sure that how to do it if I want to do the same for 100 packages. I think "slist would do this but how exactly i need to draft that policy i am not sure"
This is very similar to applying "for" loop in bash shell where we iterate input one by one and perform some operations
Experts Please help
The way to do something like this is to use CFEngine's implicit looping. You store the values in a list, and then iterate over them in the promises. For your example, it would be something like this:
bundle agent install
{
vars:
"packages" slist => { "Test-Tester-0.104", "Foo-Bar-1.001" }; # etc.
commands:
"/usr/bin/wget http://something.example.com/perl-modules/$(packages).tar.gz;
/usr/bin/gunzip $(packages).tar.gz;
tar -xf $(packages).tar;
cd $(packages);
/usr/bin/perl Makefile.PL;
/usr/bin/make;
/usr/bin/make install"
contain => standard,
classes => satisfied(canonify("$(packages)-installed"));
}
Note that I'm using $(package) whenever you previously had Test-Tester-0.104. Of course this only works if all the names are consistent in this respect. To add more, you'd only need to add the names to the packages variable. Not also that I used canonify() to make the string that gets passed to the satisfied() body a valid class name.
Now, if you are going to be doing a lot of installs like this, what I would suggest is defining a new package_method definition, which takes care of following the right steps internally, so that in your policy you can have something much cleaner, like this:
vars:
"packages" slist => { "Test-Tester-0.104", "Foo-Bar-1.001" }; # etc.
packages:
"$(packages)"
package_policy => "add",
package_method => perlsrcpkg; # or whatever you call your new package_method
You can find the documentation for packages promises here: http://cfengine.com/docs/3.5/reference-promise-types-packages.html#packages, and a bunch of package_method definition examples in the CFEngine Standard Library: https://github.com/cfengine/masterfiles/blob/master/lib/3.5/packages.cf
Finally, if the packages you are installing are from CPAN, you could just use the Packages::Installed::cpanm sketch from the Design Center: https://cfengine.com/cfengine-design-center/sketches/packages-cpan-cpanm
I have some complex aliases ex.
Alias('build', [ Program(), Install()...])
Alias('test', [Program(), Install(), RunTest()]
Alias('dist', [Install()])
and finally
Alias('all', [ Alias('build'), Alias('test'), Alias('dist')])
Question:
How to depend Alias('dist') on Alias('test') in Alias('all') ?
I've tried Depends() variations but it seems I've done something wrong.
cheers
P.
UPDATE:
I've managed that by myself.
build = Alias('build', [ Program(), Install()...])
test = Alias('test', [Program(), Install(), RunTest()]
dist = Alias('dist', [Install()])
Depends(test, build)
Depends(dist, test)
Default('dist')
I tend to make named targets for everything (with the dependencies) and then Alias the targets that I want to publish to whoever is running SCons.
prog = env.Program(..., libs)
install = env.Install(..., prog)
test = env.RunTest(..., libs)
Alias('build', prog)
Alias('test', test)
Alias('dist', [ test, install, bump_version ])
I don't know that there's a reason to prefer one method over the other. To me, it seems more natural to set up the dependencies internally, then use Alias to publish the targets that need to be user runnable.