I'm working on extending the puppetlabs-mongodb module to allow for user authentication. The challenge is that mongo changed its mechanism for enabling user authentication between version 2.2 and version 2.4 and so distinct code must be run in order to give a user authentication credentials to a database.
My initial thought was to create a custom facter fact that basically captured the output of mongod --version, but it appears that facter facts are loaded before the puppet manifest is executed. Is there a way to execute arbitrary code at run time during puppet execution so that I can access mongod --version and decide which method to use to enable user authentication?
Note: One approach would be to have puppet run a single script to create user credentials and have the script detect the mongod --version at runtime. This doesn't seem like a very puppet-y way of doing things, but perhaps I am off base on that. What is the best way to handle the need for accessing variables dynamically in puppet/facter?
The word from #puppetlabs is that you can not run ruby code (or any other code) dynamically during a puppet run. The "right" way to do this is in the note above with an exec statement that dynamically checks for the mongodb version. For details on the implementation, see manifests/add_user.pp and the associated templates/add_user*.erb.
If anyone has a more "puppety" method for accomplishing this, I'd love to learn about it!
Just put your Ruby code in a ERB template and use template("${module_name}/templ.erb") to return your version string.
Related
i am making a CLI to automate the installation process of a software. I install it in a directory like $HOME/.software-name/. Now i would like to know about a platfrom agnostic way to update the system PATH environment variable so that in the future the user can run the command easily.
I am not looking for a os specific way like setx on windows or writing to the ~/.bashrc. I would prefer a library to do the task or a builtin function.
i know that i can retrieve the env variable using process.env.variableName but setting it would not work outside the child process (ie, NodeJS). It does work inside the NodeJS process but that is obviously not what is wanted here.
Thanks :)
I am developing opensouce project with a huge pile of dependencies, and I find Puppet a perfect tool for my requirements.
However, my target audience is not necessarily experienced with Puppet. To the point they may not be even know how web servers work. So I would like to ask the user to “run this in terminal” for the simplest case, but if the user also wants to configure some parts of my software, he would have to learn puppet. And educating them Puppet defeats the “servers for dummies” purpose of my project.
Basically, dare I say, I need Unity from the deployment world.
The thing I came up with, is to use ‘json’ as a backend for Puppet, and then write some GUI tool that would generate/modify that json using JSON Schema. Of couse, this thing will be optional and experient Puppet usets could still just use my module as is.
The questiond is, am I doing it right? Is there a solution for my problem?
Thanks in advance.
You can use Hieradata to give the ability to users to configure some parts for your "Software". you can put your hiera configuration in a git repository or build a tool to edit & update this hiera configuration.
There is some tools that you can use in order to make more easier for your users like Foreman and Puppetboard
But I think it's mandatory for your users to have a basic knowledge of Puppet so they can debug or manipulate the software.
These are some things that you can use.
Have a look at these:-
https://puphpet.com/
https://github.com/voxpupuli/puppetboard
I'm trying out custom functions in puppet for the first time to write some simple helper functions for my manifests. I put the code in {my_module}/lib/parser/functions/myhelper.rb, but if I understand correctly you need to enable pluginsync and it doesn't look like vagrant supports that (I tried passing --pluginsync to puppet.options, but it didn't work).
Is there any way to use custom functions in Vagrant?
EDIT: My vagrant box is using puppet 2.7.18
Custom functions should "just" work under vagrant, no need to enable any pluginsync,
I think your problem is the function path, it should be:
{my_module}/lib/puppet/parser/functions/myhelper.rb
I have packaged my application into an RPM package, say, myapp.rpm. While installing this application, I would like to receive some inputs from the user (an example for input could be - environment where the app is getting installed - "dev", "qa", "uat", "prod"). Based on the input, the application will install the appropriate files. Is there a way to pass parameters while installing the application?
P.S.: A possible solution could be to create an RPM package for each environment. However, in our scenario, this is not a viable option since we have around 20 environments and we do not wish to have 20 different packages for the same application.
In general, RPM packages should not require user interaction. Time and time again, the RPM folks have stated that it is an explicit design goal of RPM to not have interactive installs. For packages that need some sort of input before first use, you typically ask for this information on first use, our you put it all in config files with macros or something and tell your users that they will have to configure the application before it is usable.
Even passing a parameter of some sort counts as end-user interaction. I think what you want is to have your pre or install scripts auto detect the environment somehow, maybe by having a file somewhere they can examine. I'll also point out that from an RPM user's perspective, having a package named *-qa.rpm is a lot more intuitive than passing some random parameter.
For your exact problem, if you are installing different content, you should create different packages. If you try to do things differently, you're going to end up fighting the RPM system more and more.
It isn't hard to create a build system that can spit out 20+ packages that are all mostly similar. I've done it with a template-ish spec file and some scripts run by make that will create the various spec files and build the RPMs. Without knowing the specifics, it sounds like you might even have a core package that all 20+ environment packages depend on, then the environment specific packages install whatever is specific to their target environment.
You could use the relocate option, e.g.
rpm -i --relocate /env=/uat somepkg.rpm
and have your script look up the variable data from a file located in the "env" directory
I think this is a very valid question, specially as soon as you are moving into the application development realm. There he configuration of the application for different target systems is your daily bread: you need to configure for Development, Integration Test, Acceptance Test, Production etc. I sure don't think building a seperate package for each enviroment is the solution. Basically it should be the same code running in different enviroments.
I know that this requirement is not supported by rpm. But what you can do as a work around is to use a simple config file, that the %pre script knows
to look for. The config file could be a simple shell script that for example sets environment variables, and then the different und pre and post scripts can use those.
I would like to version control my server's configuration, in case something happens to my server.
I think crontab files themselves are not intended to be edited directly (only through crontab commands), so how would I go about versioning them? Should I version the files anyway? Is there something else I should be looking for?
I guess you're trying to automate something on a web application. It clearly goes beyond the simple fact of your server crashing. What if you want to add another front-end server for example ?
People in the ruby community came out with a pretty nice tool, "whenever" (https://github.com/javan/whenever) to solve this issue.
Namely, the proper way is not to version control the crontab. It's rather up to each app to be able to properly configure itself.
In the case of Rails applications for example, you would use a tool like Capistrano to automate your deployment. And one of the capistrano task would be to setup the correct cron jobs, thanks to whenvever. Hope this helps !