apt-puppetlabs do repos first - puppet

on my puppetserver i use the puppetlabs-apt module to configure the repos. And i use hiera to get the data for the repos. If i run it i get the message that dirmngr cant be installed cause it cant be found in the repos.
That error comes because puppet is trying to install dirmngr before hes doing the repos. And dirmngr is required in the module.
Is there a way to force the the module to do the repos first and then let it install dirmngr?
my code is like this
class {'apt':
purge =>{
"/etc/apt/sources.list =>true",
},
}

If I understand the problem, you should be able to do something like this:
$dirmngr_apt_source = ...
class { 'apt':
purge => {
"/etc/apt/sources.list" => true
}
}
Apt::Source[$dirmngr_apt_source] -> Package['dirmngr']
Further explanation:
The variable $dirmngr_apt_source is for you to fill in with the Apt source that the dirmngr package lives in. (Full disclaimer: I don't know much about Ubuntu.)
Although the Apt class declares the resources Apt::Source[$dirmngr_apt_source] and Package['dirmngr'], you can still declare relationships between those resources from outside the class, as I did there.
Also, this is a bit of a hack in my opinion, and it sounds like this is possibly a bug or a design flaw in the Apt module.
That is to say, considering that the Apt module manages a Linux node's Apt sources, and the dirmngr package depends on Apt sources, there shouldn't be an assumption in the module that the dirmngr package can be found prior to configuration of the Apt sources. (Or if it's a valid assumption, then perhaps it needs better documentation?)
So, you might consider raising a bug or checking if there's already a bug.

Related

How do I install package from amazon-linux-extras using Puppet?

I am trying to set up a Puppet module to install PHP 7.3 on Amazon Linux 2. It is available as a amazon-linux-extras package.
I could simply install it using CLI:
amazon-linux-extras install php7.3
But I would like to define it as a package and ensure it is installed, like this:
package { "php7.3":
ensure => installed,
provider => 'amazon-linux-extras'
}
Unfortunately I cannot set package provider to amazon-linux-extras as such provider doesn't exist.
What would be the correct way to install this package?
At this time, it appears that Puppet does not support the amazon-linux-extras utility.
Arguably, a new type/provider should be created to support amazon-linux-extras. It could live in Puppet Core, if you raised a feature request that is accepted. Or, you could write your own and release it as a module on the Puppet Forge, if you know how write custom types and providers.
In the mean time, it is easy to write a defined type to solve this problem using exec.
define al::amazon_linux_extras(
Enum['present'] $ensure = present,
) {
$pkg = $name
exec { "amazon-linux-extras install -y $pkg":
unless => "amazon-linux-extras list | grep -q '${pkg}=.*enabled'",
path => '/usr/bin',
}
}
Usage:
al::amazon_linux_extras { 'php7.3':
ensure => present,
}
Further explanation:
I assumed you would place your defined type in a module al. But it could be a profile etc. E.g. profile::amazon_linux_extras is another possibility.
I implemented ensure => present for readability only, i.e. it doesn't actually do anything, and also in case you decide to later implement ensure => absent or ensure => latest etc.

Diffrences between "apt-get install openjdk-8-jdk" and downloading *.tar.gz

I want to install openjdk on ubuntu.
I found two ways to install it.
The first is typing "sudo apt-get install openjdk-8-jdk" on terminal.
The second is downloading the binary file such as *.tar.gz and then unpack the file and set environment variables JAVA_HOME&PATH.
So, is there any difference between this two methods?
I mean, will it cause different results?
Thanks a lot.
With the first approach, the installation is controlled by Debians Apt package manager and will receive updates, with the second one you will have to do that manually.
It will probably not end with different result.
On linux distributions you have what is called a packet manager : Yours (and on almost every ubuntu) is APT.
So the main difference is that when you use apt, you can "trust more" what you are downloading, because hopefully, content in apt are check.
However, because of this checking, apt isn't every time up-to-date, and it may induce some difference in version.
However, in my opinion if you doesn't want to duplicate file or pollute your system, you may want to choose either one option and stay with it : if you use apt, use apt to update, if you download it manually keep updating it manually.
I personally prefer to use apt when possible.

NixOS and ghc-mod - Module not found

I'm experimenting a problem with the interaction between the ghc-mod plugin in emacs, and NixOS 14.04. Basically, once packages are installed via nix-env -i, they are visible from ghc and ghci, recognised by haskell-mode, but not found by ghc-mod.
To avoid information duplication, you can find all details, and the exact replication of the problem in a VM, in the bug ticket https://github.com/kazu-yamamoto/ghc-mod/issues/269
The current, default, package management set up for Haskell on NixOS does work will with packages that use the ghc-api, or similar (ghc-mod, hint, plugins, hell, ...) run time resources. It takes a little more work to create a Nix expression that integrates them well into the rest of the environment. It is called making a wrapper expression for the package, for an example look at how GHC is installed an operates on NixOS.
It is reasonable that this is difficult since you are trying to make a install procedure that is atomic, but interacts with an unknown number of other system packages with their own atomic installs and updates. It is doable, but there is a quicker work around.
Look at this example on the install page on the wiki. Instead of trying to create a ghc-mod package that works atomically you weld it on to ghc so ghc+ghc-mod is an atomic update.
I installed ghc+ghc-mod with the below install script added to my ~/.nixpkgs/nixpkgs.nix file.
hsEnv = haskellPackages.ghcWithPackages (self : [
self.ghc
self.ghcMod
# add more packages here
]);
Install package with something like:
nix-env -i hsEnv
or better most of the time:
nix-env -iA nixpkgs.haskellPackages.hsEnv
I have an alias for the above so I do not have to type it out every time. It is just:
nixh hsEnv
The down side of this method is that other Haskell packages installed with nix-env -i[A] will not work with the above installation. If I wanted to get everything working with the lens package then I would have to alter the install script to include lens like:
hsEnv = haskellPackages.ghcWithPackages (self : [
self.ghc
self.ghcMod
self.lens
# add more packages here
]);
and re-install. Nix does not seem to use a different installation for lens or ghc-mod in hsEnv and with the ghc from nix-env -i ghc so apparently only a little more needs to happen behind the scenes most of the time to combine existing packages in the above fashion.
ghc-mod installed fine with the above script but I have not tested out its integration with Emacs as of yet.
Additional notes added to the github thread
DanielG:
I'm having a bit of trouble working with this environment, I can't even get cabal install to behave properly :/ I'm just getting lots of errors like:
With Nix and NixOS you pretty much never use Cabal to install at the global level
Make sure to use sandboxes, if you are going to use cabal-install. You probably do not need it but its there and it works.
Use ghcWithPackages when installing packages like ghc-mod, hint, or anything needs heavy runtime awareness of existing package (They are hard to make atomic and ghcWithPackages gets around this for GHC).
If you are developing install the standard suite of posix tools with nix-env -i stdenv. NixOS does not force you to have your command line and PATH cultured with tools you do not necessarily need.
cabal assumes the existence a few standard tools such as ar, patch(I think), and a few others as well if memory services me right.
If you use the standard install method and/or ghcWithPackages when needed then NixOS will dedup, on a package level (If you plot a dependency tree they will point to the same package in /nix/store, nix-store --optimise can always dedup the store at a file level.), many packages automatically unlike cabal sandboxes.
Response to comment
[carlo#nixos:~]$ nix-env -iA nixos.pkgs.hsEnv
installing `haskell-env-ghc-7.6.3'
these derivations will be built:
/nix/store/39dn9h2gnp1pyv2zwwcq3bvck2ydyg28-haskell-env-ghc-7.6.3.drv
building path(s) `/nix/store/minf4s4libap8i02yhci83b54fvi1l2r-haskell-env-ghc-7.6.3'
building /nix/store/minf4s4libap8i02yhci83b54fvi1l2r-haskell-env-ghc-7.6.3
collision between `/nix/store/1jp3vsjcl8ydiy92lzyjclwr943vh5lx-ghc-7.6.3/bin/haddock' and `/nix/store/2dfv2pd0i5kcbbc3hb0ywdbik925c8p9-haskell-haddock-ghc7.6.3-2.13.2/bin/haddock' at /nix/store/9z6d76pz8rr7gci2n3igh5dqi7ac5xqj-builder.pl line 72.
builder for `/nix/store/39dn9h2gnp1pyv2zwwcq3bvck2ydyg28-haskell-env-ghc-7.6.3.drv' failed with exit code 2
error: build of `/nix/store/39dn9h2gnp1pyv2zwwcq3bvck2ydyg28-haskell-env-ghc-7.6.3.drv' failed
It is the line that starts with collision that tells you what is going wrong:
collision between `/nix/store/1jp3vsjcl8ydiy92lzyjclwr943vh5lx-ghc-7.6.3/bin/haddock' and `/nix/store/2dfv2pd0i5kcbbc3hb0ywdbik925c8p9-haskell-haddock-ghc7.6.3-2.13.2/bin/haddock' at /nix/store/9z6d76pz8rr7gci2n3igh5dqi7ac5xqj-builder.pl line 72.
It is a conflict between two different haddocks. Switch to a new profile and try again. Since this is a welding together ghc+packages it should not be installed in a profile with other Haskell packages. That does not stop you from running binaries and interrupters from both packages at once, they just need to be in their own name space so when you call haddock, cabal, ghc, there is only one choice per profile.
If you are not familiar with profiles yet you can use:
nix-env -S /nix/var/nix/profiles/per-user/<user>/<New profile name>
The default profile is either default or channels do not which one it will be for your set up. But check for it so you can switch back to it later. There are some tricks so that you do not have to use the /nix/var/nix/profiles/ directory to store you profiles to cut down on typing but that is the default location.

Installing several RPMs with custom install flags

I'm trying to do the initial work to get our dev shop to start using vagrant + puppet during development. At this stage in my puppet manifest development, I need to install several RPMs that are available via an internal http server (not a repo) with very specific flags ('--nodeps').
So, here's an example of what I need to install:
http://1.2.3.4/bar/package1.rpm
http://1.2.3.4/bar/package2.rpm
http://1.2.3.4/bar/package3.rpm
I would normally install them in this way:
rpm --install --nodeps ${rpm_uri}
I would like to be able to do something like this
$custom_rpms = [
'http://1.2.3.4/bar/package1.rpm',
'http://1.2.3.4/bar/package2.rpm',
'http://1.2.3.4/bar/package3.rpm',
]
# edit: just realized I was instantiating the parameterized
# class wrong. :)
class { 'custom_package': package_file => $custom_rpms }
With this module
# modules/company_packages/manifests/init.pp
define company_package($package_file) {
exec { "/bin/rpm --install --nodeps ${package_file} --nodeps" }
}
But, I'm not sure if that's right. Can some of you puppet masters (no pun intended) school me on how this should be done?
You may have already worked around this by now, but if not.
Using a repository is the preferred method as it will autoresolve all the dependancies, but it that's not available you can try the following. (I'm using epel as an example rpm)
package {"epel-release":
provider=>rpm,
ensure=>installed,
install_options => ['--nodeps'],
source=>"http://download.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm",
}
It used to be that 'install_options ' was only supported in windows.
It appears that it is now supported in linux.
If there is sequence that would be helpful, add "require=Package["package3.rpm"]," to sequence.
Answered by Randm over irc.freenode.net#puppet
Create or use an existing repo and install them with yum so that it resolves the dependencies for you.

rpm installation using puppet

I am new to Puppet - I have been playing around learning the basics. Most of the examples ( except the very basic ones ) that are on the puppet page do not work for me - either some dependency is missing or package is not found. I do not see the logs explaining what went wrong ( even if I run the --test or --verbose option)
Can anyone clarify
1 What is the simplest process ( set of simple steps ) for installing a rpm package on a single Linux box ?
2 In general - how does one go about using the modules on the forge.puppetlabs ? Are the providers for these packages installed automatically or they have to be manually installed first ?
To install a package named pacman from command line:
puppet resource package pacman ensure=present
Corresponding puppet code will look like:
package { 'pacman':
ensure => '4.0.3-5',
}
Explore for more options about the package resource here
Regarding the question of installing puppet modules, have a look here. Official doc is your friend :)
Personally, I just copy-paste the module directory manually in a git repo which I use to maintain my puppet code.

Resources