Access Puppet Module variables from custom provider - ruby

I'm writing a custom provider and I'm only going to use it in the context of the module it's attached to. The module will already define things for the resource which I need to act on (e.g. username, password, IP Address). What I'm trying to do is access a variable in scope in the puppet manifest from the custom provider.
Is this possible?
init.pp:
class mymodule(
$username = 'admin',
-- snip --
}
provider.rb:
class Puppet::Provider::MyProvider < Puppet::Provider
def self.configure
#can I get to $mymodule::username here?
Some context:
I'm writing a set of types that will configure a server via an API. I want to have a type like:
mymodule_mail_settings { 'current':
server => 'mail.server.com'
mailuser => 'mail'
}
What I'm trying to avoid is having to pass the username/password/ip to access the server's API passed into all of these different types.

The variables are only meaningful in the context of evaluating the manifest code and creating a catalog. They don't become part of the catalog. This is why your type/provider code cannot work with them directly.
To avoid passing redundant info to lots of resources that share it, you can use some "clever" tricks. In a patch I wrote some time ago, I added this kind of meta-information to Puppet's resources type. You cannot do this in a module, but you can add your own meta-type to carry such hints.

Related

Oracle ORDS REST modules - optional parameters in handler

To create a handler, it seems that I would need to create a template with a URI template to create bindings.
However, the bindings seem to me only possible as a path structure (e.g. /:id/:records/:department) instead of being searchParams (?id=1&department=IT)
How could I allow optional parameters in the URL for handlers?
You can access search params variables just as you would access it in the URL template. There's no need to strictly define all possible input parameters in the URL template.
You can use binds or parameters, or even a mix.
I have full code examples here.
Run the sql's...
Confirm your APIs have been created, and call the API...
In this case a
GET http://localhost:8080/ords/hr/parameters/headers-classic?id=4

How do I pass admin module data to Smarty in WHMCS?

I would like to pass some data from a WHMCS admin module to the client summary admin template. In order to get the data from our admin module to the Smarty template, we have been attempting to use an action hook called "AdminAreaPage". This action hook is supposed to take an array of variables (returned in the action hook) and make them accessible as Smarty variables.
The issue I am having is that none of the variables we return in that action hook seem to be accessible to the template (clientssummary.tpl). I have tried listing all available Smarty variables with {debug} as well as several other methods, but none of our custom variables are displayed (the other template variables are successfully listed). The basis for our action hook is taken directly from the WHMCS documentation example:
http://docs.whmcs.com/Hooks:AdminAreaPage
The action hook is running on each page load, as we are able to echo text directly to the page. We are not able to access any data passed to Smarty, however, or we are not passing it correctly. Here is some example code similar to what we are using in our action hook, (nearly unmodified from the WHMCS example code):
function module_hook_test($vars) {
$return = array();
$return = array("field1" => "value1", "field2" => "value2");
return $return;
}
add_hook("AdminAreaPage",1,"module_hook_test");
(with "module" being replaced with our actual module name)
Any assistance with this action hook, or an alternate recommended method of passing the data, would be greatly appreciated. Thank you.
I submitted a ticket to WHMCS support. They have believe the issue may be due to a bug in WHMCS and said that the developers will address the issue in a future release. In the mean time, they suggested querying the data directly from the template using {php}{/php} tags. This will work fine for us as a temporary workaround.

Set up filters inside a package

I'm developing a package that registers some filters which the user can add to their routes if they wish.
eg.
\Route::filter('myPackage.hasSomething', 'Panthro\MyPackage\MyPackage#hasSomethingFilter');
I'm just concerned where I should place these in my package.
At the minute they are in my service provider class under register. Is this a good place for them? Is there a common practice where these should go?
I've read some blogs which places custom filters inside a filters folder, the only issue with this is that this is for the actually filter method and not for the code that registers the filter with the router.
You should not place that code into your package as end user should be able to assign a custom name to your filter. Think the may have already another existing filter with a conflicting name.
Just create your package as normal, with the only particulariry being you must make sure you class MyPackage has a method filter. The end user then could install the package with:
composer require "panthro/mypackage:dev-master"
Then edit app/config/app.php and add the service provider within the providers array:
'providers' => array(
'Panthro\MyPackage\ServiceProvider',
And finally add the filter to the bottom of the app/filters.php file:
Route::filter('hasSomething', 'Panthro\MyPackage\MyPackage');
For more info read the official docs Registering A Class Based Filter.

Best way of using Ruby module for configuration data

I am somewhat new to Ruby, especially the more advanced concepts like modules and mixins, so I might be using module totally out of context..
I am currently writing an internal test framework using Capybara and I am trying to figure out the best/easiest way of handling configuration data. I file a file called config.rb and within it I want to store configuration settings per environment. For example:
module QAConfiguration
config data goes here
end
module DevConfiguration
config data goes here
end
The simplest example of configuration data is usernames and password. QA and Dev of course use different users. I am thinking of two different ways of going about this but I want to make sure I am following at least a decent practice and not going into the weeds.
module QAConfiguration
USERNAME = 'test'
PASSWORD = 'test'
end
or..
module QAConfiguration
def username
'test'
end
end
And so on. Which is the best way of approaching this?
A module probably isn't the best way to implement this. Generally when testing (I use rspec) we use helper files that contain reusable code.
Object attributes like usernames and passwords are usually handled by Factories. A great gem for factories is FactoryGirl.
A common way to store configuration in ruby/rails is in a yaml file. You could for example create a file called config/test_conf.yml with yaml format:
username: 'your_user'
password: 'somepass'
Then where you need the config data:
config = YAML.load(File.read("#{Rails.root}/config/test_conf.yml"))
puts config['username']
And finally, you will usually only put a test_config.yml.example on git/svn and in your app setup readme note that they need to cp config/test_config.yml.example config/test_config.yml and edit the file.

How to change scope/permissions with Microsoft.Web.WebPages.OAuth

Is there a way to change the scope/permission when using Microsoft.Web.WebPages.OAuth? The most logical place is when registering the client with OAuthWebSecurity.RegisterClient. I thought that the adding scope to the extraData parameter would possibly work, but I didn't have success with that.
Microsoft.Web.WebPages.OAuth does not expose the scope when authorizing with a client. I ended up adding custom DotNetOpenAuth clients to include my necessary scope.
The extradata is something you can pass about the provider and use it in tehe UI layer. For eg. extra data could be the icon to display when listing the provider to use for login.
Following post shows how you can write your own provider and plug it into your site
http://blogs.msdn.com/b/webdev/archive/2012/08/23/plugging-custom-oauth-openid-providers.aspx

Resources