puppet understanding parameters class - module

i am new in Puppet. I have a puppet basic infrastructure.
I installed from
puppetforge "example42/lighttpd"
I am able to deploy this class without a problem to a puppet controlled node.
My problem now,.how can i use the parameters in this class? i am not understood where i can activate the parameters.i would like to deploy lighttpd with customized index.html and a different log file path.i hope u can give me a hind :)
In the file params.pp
This class is not intended to be used directly.
It may be imported or inherited by other classes
but how can i imported this??

First off, to get straight started with puppet, you should take a look at the documentation for the module in question (ie. README, README.md, etc.). Next, understand the params pattern. The params class in a puppet module is usually a class that contains NO resources, and is meant to hold default data for a module (data not supplied from outside sources like hiera). most of the time you will see something like this:
inherits lighttpd::param
In the init, or another manifest file in a module. That is because it is inheriting the values from the params class.
Hope this helped at least a little bit.

In short, don't use params.pp directly (by declaring it). This class is part of params design pattern which states that default values for our parameters can be placed in params.pp puppet class which then can be inherited by all classes in which we need to access parameters that are defined in params.pp
I think the best place to start is init.pp class which every Puppet module has. It can be found inside manifest directory in Puppet module you downloaded from Puppet Forge.
/Users/bjusufbe/.puppetlabs/etc/code/modules/lighttpd/manifests
Bakirs-MacBook-Pro:manifests bjusufbe$ ls -la
total 56
drwxr-xr-x 6 bjusufbe staff 204 Oct 23 19:27 .
drwxr-xr-x 10 bjusufbe staff 340 Oct 23 19:27 ..
-rw-r--r-- 1 bjusufbe staff 1705 Oct 23 19:26 dotconf.pp
-rw-r--r-- 1 bjusufbe staff 15763 Oct 23 19:27 init.pp
-rw-r--r-- 1 bjusufbe staff 2633 Jul 17 2013 params.pp
-rw-r--r-- 1 bjusufbe staff 560 Apr 10 2013 spec.pp
If you open init.pp, you will see following class definition:
class lighttpd (
$use_ssl = params_lookup( 'use_ssl' ),
$my_class = params_lookup( 'my_class' ),
$source = params_lookup( 'source' ),
$source_dir = params_lookup( 'source_dir' ),
...
All parameters use params_lookup custom function (not provided by Puppet but part of other modules from example42 namespace). You can check details how this function is used on following link: How to use params_lookup in chapter: PARAMS LOOKUP ORDER
However, to make things easier for you, you can declare this class using following syntax in your site.pp (if you use Puppet master/agent scenario) or in any *.pp file in masterless scenario which can be applied simply by calling:
puppet apply <name_of_pp_file>.pp
Simple declaration goes like this:
class { 'lighttpd':
<anyparameterfromthisclassdefinition> => <value>
}
Example:
class { 'lighttpd':
use_ssl => true,
}
If you don't want to pass any parameter in class declaration, then default values will be used that are calculated by custom function params_lookup for each parameter in this class. In that case, you could simply do this:
include lighttpd
Hope this gives you enough to start. Cheers!

Related

pytest, any way to include a test file or list of test files?

I am looking for best practices advices regarding the following context:
I am using pytest to run integration tests on my IAC deployment
My IAC code base is structured as:
myapp
|
|_roles
| |_role1
| |_role2
|_resources
|_tomcat
|_java
I'd like to use the same kind of structure for my test files.
Tests are currently divided in file matching roles (role1, role2):
tests
|
|_roles
|_test_role1.py
|_test_role2.py
which lead to duplicated code, e.g:
role1 is a tomcat base app,
role2 holds pure java code,
So in both test files (test_role1.py and test_role2.py) there will be a java test function.
If I could add a dir structure as:
tests
|
|_roles
| |_test_role1.py
| |_test_role2.py
|
|_resources
|_test_tomcat.py
|_test_java.py
Then I could just "include / import" the test_java.py functions to use them in test_role1.py and test_role2.py without duplicating code...
What's the best way to achieve this ?
I am already using fixtures (defined in conftest.py), and I feel that the solution to my duplicated code is something along fixture or test modules but my poor python / pytest knowledge is keeping me away from the actual solution.
Thanks
If you don't mind running your tests as a module, you could turn your Python files into packages by placing a file called 'init.py' in the root of the project, in the directory with the code to be tested and in the directory with the testing code.
You can then perform relative imports to access the functions you need:
eg to access "_test_java.py" from "_test_role2.py"
from ../_roles import _test_java
A single dot represent the current directory. Two dots represents the parent directory.
You will need to use the -m flag when calling your code so Python understands you are running a module with relative imports.
In your case you might consider performing the messy relative imports in conftest.py
This post explains the above in more detail:
http://blog.habnab.it/blog/2013/07/21/python-packages-and-you/

How do I find the version and authority of a Perl 6 module?

In Bar.pm, I declare a class with an authority (author) and a version:
class Bar:auth<Camelia>:ver<4.8.12> {
}
If I use it in a program, how do I see which version of a module I'm using, who wrote it, and how the module loader found it? As always, links to documentation are important.
This question was also asked on perl6-users but died before a satisfactory answer (or links to docs) appeared.
Another wrinkle in this problem is that many people aren't adding that information to their class or module definitions. It shows up in the META.json file but not the code.
(Probably not a satisfying answer, because the facts of the matter are not very satisfying, especially regarding the state of the documentation, but here it goes...)
If the module or class was versioned directly in the source code à la class Bar:auth<Camelia>:ver<4.8.12>, then any code that imports it can introspect it:
use Bar;
say Bar.^ver; # v4.8.12
say Bar.^auth; # Camelia
# ...which is short for:
say Bar.HOW.ver(Bar); # v4.8.12
say Bar.HOW.auth(Bar); # Camelia
The ver and auth methods are provided by:
Metamodel::ClassHOW (although that documentation page doesn't mention them yet)
Metamodel::ModuleHOW (although that documentation page doesn't exist at all yet)
Unfortunately, I don't think the meta-object currently provides a way to get at the source path of the module/class.
By manually going through the steps that use and require take to load compilation units, you can at least get at the prefix path (i.e. which location from $PERL6LIB or use lib or -I etc. it was loaded from):
my $comp-spec = CompUnit::DependencySpecification.new: short-name => 'Bar';
my $comp-unit = $*REPO.resolve: $comp-spec;
my $comp-repo = $comp-unit.repo;
say $comp-repo.path-spec; # file#/home/smls/dev/lib
say $comp-repo.prefix; # "/home/smls/dev/lib".IO
$comp-unit is an object of type CompUnit.
$comp-repo is a CompUnit::Repository::FileSystem.
Both documentations pages don't exist yet, and $*REPO is only briefly mentioned in the list of dynamic variables.
If the module is part of a properly set-up distribution, you can get at the meta-info defined in its META6.json (as posted by Lloyd Fournier in the mailing list thread you mentioned):
if try $comp-unit.distribution.meta -> %dist-meta {
say %dist-meta<ver>;
say %dist-meta<auth>;
say %dist-meta<license>;
}

Basic usage of modules in puppet with hiera

I want to use puppet to manage some servers. Even after reading dozens of documentation pages, it is not clear to me how to use modules and how to use them with hiera. As first experiment I wanted a user "admin" to be created on one node and found this module -> https://github.com/camptocamp/puppet-accounts
My /etc/puppet/hiera.yaml looks as simple as this
---
:backends:
- yaml
:hierarchy:
- node/%{::fqdn}
- common
:yaml:
:datadir: /etc/puppet/hieradata
My /etc/puppet/hieradata/node/node1.example.com.yaml contains this
---
accounts::users:
admin:
uid: 1010
comment: admin
accounts::ssh_keys:
admin:
comment: ad
type: ssh-rsa
public: AAAAAAAAAAAAAA
This worked after I put this in my /etc/puppet/manifests/site.pp
hiera_include('classes')
class
{
'accounts':
ssh_keys => hiera_hash('accounts::ssh_keys', {}),
users => hiera_hash('accounts::users', {}),
usergroups => hiera_hash('accounts::usergroups', {}),
}
accounts::account
{
'admin':
}
Is this good practice? To me it feels wrong to put that stuff into site.pp since it gets messed up when I later use more modules. But where else to put it? I also don't understand how this separates data from logic, since I have data in both, node1.example.com.yaml and site.pp (admin). Some help would be great..
To understand what hiera is, you should think simply that Hiera is a DATABASE for puppet, a database of Variables/values and nothing more.
For a beginner I would suggest to focus on other parts of the system, like how to create modules! and how to manage your needs (without complexity) and then slowly build the "smart" recipes or the reusable ones...
Your puppet will first sick for a file called sites.pp (usually is on your main $confdir (puppet.conf variable. I am not going to mention environments it is for later.)
e path is /etc/puppet inside that directory, you have a directory manifests. There is the place for your sites.pp
usually a sites.pp structure is:
node default {
include *module*
include *module2*
}
node /server\.fqdn\.local/ {
include *module2*
include *module3*
}
this means that you have a default Node (if the node name doesn't fit any other node, will use the default, otherwise it will use the regex matching of the node FQDN in this case server.fqdn.local.
The modules (module, module2 and module3) are stored inside the $modulespath set on your puppet.conf. In our case i will use the: /etc/puppet/modules
the tree will look like:
/etc/puppet/modules/
/etc/puppet/modules/module/
/etc/puppet/modules/module/manifests/
/etc/puppet/modules/module/manifests/init.pp
/etc/puppet/modules/module2/
/etc/puppet/modules/module2/manifests/
/etc/puppet/modules/module2/manifests/init.pp
/etc/puppet/modules/module3/
/etc/puppet/modules/module3/manifests/
/etc/puppet/modules/module3/manifests/init.pp
About
classes: https://docs.puppetlabs.com/puppet/latest/reference/lang_classes.html
generally what i explained but from puppet labs: https://docs.puppetlabs.com/puppet/latest/reference/dirs_manifest.html
Please note that the example from the README
class { 'accounts':
ssh_keys => hiera_hash('accounts::ssh_keys', {}),
users => hiera_hash('accounts::users', {}),
usergroups => hiera_hash('accounts::usergroups', {}),
}
is catering to users of Puppet versions before 3.x which had no automatic parameter lookup. With a recent version, you should just use this manifest:
include accounts
Since the Hiera keys have appropriate names, Puppet will look them up implicitly.
This whole thing still makes no sense to me. Since I have to put
accounts::account
{
'admin':
}
in a manifest file to create that user, what for is hiera useful in this case? It doesn't separate data from logic. I have data in both, the .yaml file (ssh keys, other account data) and in a manifest file (the snippet above). By using hiera I expect to be able to create that user inside /etc/puppet/hieradata/node/node1.example.com.yaml but this is not the case. What is the right way to do this? What for is the example hiera file of this module useful? Wouldn't it be easier create an account the old style way in site.pp?

Loading properties of Property file JBOSS-7

I have done my configuration as per https://community.jboss.org/message/750465
I need to load a key from properties-service.xml which has below attributes.
<attribute name="Properties">
project.userName=xxxxx
project.userType=xxxxx
project.userToken=xxxx
My code access these properties as below
Properties globalSystemProperties = System.getProperties();
Enumeration keys = (Enumeration) globalSystemProperties.propertyNames();
I am not seeing my key list when iterate , What Could be the reason?
The reason is that it isn't supported anymore, like the thread you linked says:
jaikiran pai Dec 19, 2011 10:53 PM (in response to David Robison)
It doesn't exist in AS7.
This page tells a way of doing it with modules, but that will not work using System.getProperties(), it will only place them on classpath.
If you want your properties in the System.getProperties() code, I only can think of these options:
use --property or -P startup parameter pointing to your file, like explained here
populate them as <system-property/> in the configuration file
set them to actual system properties on startup or in code
use Spring or similar to add them as system properties
The first option is I guess the closest you can have.

Using Db::getInstance() in a CLI script

I've been wanting to create a add-on cron script that utilises Prestashop's DB class instead of instantiating the database handle directly, but I can't seem to figure out where did the "Db" class commonly referenced by "Db::getInstance()" calls get defined.
classes/Db.php defines an abstract DbCore class. MySQLCore extends Db as you can see, however Db is never defined anywhere:
[/home/xxxx/www/shop/classes]# grep -r "extends Db" ../
../classes/MySQL.php:class MySQLCore extends Db
According to another thread on Prestashop forums, the abstract DbCore class is implemented in a class located in override/classes/db, however that directory does not exist.
[/home/xxxx/www/shop/override]# cd ../override/
[/home/xxxx/www/shop/override]# ls
./ ../ classes/ controllers/
[/home/xxxx/www/shop/override]# cd classes/
[/home/xxxx/www/shop/override/classes]# ls
./ ../ _FrontController.php* _Module.php* _MySQL.php*
Our shop is working, so obviously I am missing something. We are running Prestashop 1.4.1, so perhaps the docs are no longer applicable.
Quite clearly in many places in the code base functions from the Db class are being used, but this last grep through the code found nothing:
grep -rwI "Db" . | grep -v "::"
./modules/productcomments/productcommentscriterion.php:require_once(dirname(__FILE__).'/../../classes/Db.php');
./classes/MySQL.php:class MySQLCore extends Db
./classes/Db.php: * Get Db object instance (Singleton)
./classes/Db.php: * #return object Db instance
./classes/Db.php: * Build a Db object
Is there something I am missing? Where did this magical Db class come from?
To create a CLI script, the easiest way is to include the config file so you will have access to every classes. For example
<?php
require dirname(__FILE__).'/config/config.inc.php'; // assuming your script is in the root folder of your site
// you can then access to everything
$db = Db::getInstance();
You are confused a little bit with this. In PS 1.4.x. in the override directory, no files are palced. The documentation is following PS 1.5.x.
PS is using autoload feature to load classes. Lets take DB class as an example. The file name is Db.php , but class name is DbCore and when we want to get object of Db class, we do it like
Db::getInstance();
means not like
DbCore::getInstance();
How this works ? The thing is the php auto load function. Checkout the config/autoload.php (or a file with a name like that), and you will see that PS checking the class with and without Core at the end of the class name. Means that if the a name has Core or not, it will be loaded.
Starting with PS 1.5.x , PS placed over rided files in override/classes folder. Please note that all those classes are extending their respective classes. For example in override/classes/db the class Db.php is placed and this file has only the following code
<?php
abstract class Db extends DbCore
{
}
So it is clear if we want to use Db class, it will call the override/classes/db/Db.php which is extended from DbCore class.
Similarly for all other classes, the same criteria is used.
I hope those details will help.
Thank you