Puppet Does not load class in custom module - module

A beginner environment with Puppet(3.8.4)+Apache(2.2.15)+Passenger on CentOS6.5
An agent run returns with
Error: /File[/var/lib/puppet/lib]: Could not evaluate: Could not retrieve
information from environment production source(s)
puppet://puppetmaster/plugins
Error: Could not retrieve catalog from remote server: Error 400 on SERVER:
Puppet::Parser::AST::Resource failed with error ArgumentError: Could not
find declared class mediawiki at
/etc/puppet/environments/production/manifests/nodes.pp:10 on node wikitest
This is sequence of installing the module:
$>sudo puppet module generate my-mediawiki --environment production
$>sudo mv my-mediawiki mediawiki (just renaming the folder)
$sudo puppet module list
/etc/puppet/modules (no modules installed)
/usr/share/puppet/modules (no modules installed)
I have tried adding $confdir/environments/production/modules to environment.conf of the production environment and
to the basemodulepath in puppet.conf as the first entry, but it doesn't seem to be looking there.
$confdir/environments/production/modules/mediawiki/manifests/init.pp has the empty class declaration. '$confdir/environments/production/nodes.pp`
has the class statements in both nodes and both have the same error.
I've already tried:
1) removing the module and trying again, with all the puppet service stopped/started etc
2) there are no spelling or quotation mark errors
3) I've modified metadata.json in the mediawiki folder to be same as folder name just in case that mattered, but no luck.
4) Certificates are fine, communication is fine. I have another class defined as resource within the nodes.pp file and that runs fine.
Any help appreciated!

Related

How to force OpenAPI Generator CLI to use pre-downloaded .jar file?

I have installed (via npm) openapi-generator-cli on my WSL running Ubuntu 22.04 image, with correctly configured HTTP_PROXY and HTTPS_PROXY environment variables.
The problem is, running any command (including sudo openapi-generator-cli help) results in OAG-CLI attempting to download the .jar file from maven.org, which end with connection getting refused for unknown reason (SSL cert not listed as trusted? WSL-exclusive bug? corporate proxy having an edge case?).
Instead of dealing with all that, I realised I can just download the latest (as per official website) .jar file:
https://repo1.maven.org/maven2/org/openapitools/openapi-generator-cli/6.2.1/openapi-generator-cli-6.2.1.jar
via browser and place it manually for OAG-CLI to use.
I have edited the auto-generated openapitools.json just so:
{
"$schema": "node_modules/#openapitools/openapi-generator-cli/config.schema.json",
"spaces": 2,
"generator-cli": {
"version": "6.2.1",//same version as .jar
"storageDir": "."//see below
}
}
Unfortunately, despite placing two copies of the .jar file (one named openapi-generator-cli-6.2.1.jar, one named openapi-generator-cli.jar) in both the "current" folder and /usr/libs/openapi, and trying the following values for storageDir:
.
./
/usr/libs/openapi
/usr/libs/openapi/
~/usr/libs/openapi
~/usr/libs/openapi/
every single run of sudo openapi-generator-cli help resulted in an immediate Downloading 6.2.1 ... message (followed by connection refused error some time later).
What else do I need to do to make OAG-CLI use the .jar within storageDir instead of trying to download a new copy?
(Answer containing just the structure and contents of a folder created by "storageDir": "~/foo" would allow me to reverse-engineer a working setup.)

CodePipeline ElasticBeanstalk [ERROR] An error occurred during execution of command [app-deploy] - [CheckProcfileForDotNetCoreApplication]

I've built a Code Pipeline (Source > Build > Deploy) and it's failing on the deploy step.
It's a Net Core 3.1 Api project.
I check the elastic beanstalk logs and I see:
2020/07/02 14:14:00.600060 [ERROR] An error occurred during execution of command [app-deploy] - [CheckProcfileForDotNetCoreApplication]. Stop running the command. Error: error stat /var/app/staging/MyApi/MyApi.dll: no such file or directory with file /var/app/staging/MyApi/MyApi.dll
As far as I know I have no control over /var/app/staging/ and this is built in AWS stuff?
The build step is working so I am unsure on this error.
My buildspec.yml is:
version: 0.2
phases:
build:
commands:
- dotnet publish -c release -o ./build_output ./MyApi/MyApi.csproj
artifacts:
files:
- '**/*'
base-directory: 'build_output'
This is the "zipfile/build_output" folder:
This is the zip file root folder:
These are the files in the build artifacts zip file that pipeline is using. The error says it cannot find MyAppName.dll (renamed to MyApi in the pic). It's there so I wonder why the problem.
Perhaps it doesnt like the folder structure in the zip file - see pic.
I had the same problem.
In my case, if the solution name and project name were different, I got the same error when I deployed the code from Visual Studio to Beanstalk, but when I added a project with the same name as the solution name and built it, I didn't get an error.
I suspect that there will be behavior during deployment that assumes the .dll file has the same name as the solution name.
Warning: This is a workaround, not a solution!
On the project that's failing to deploy, change the "Assembly name" in Project Properties / Application tab, to the name of the DLL it's missing (typically the solution name or the first period-separated part of the namespace).
i.e. "SLNNAME"
Then, redeploy your beanstalk app and it should work.
As Marcin correctly noticed, the indentation was incorrect for the "base-directory"
base-directory: 'build_output'
Should be
base-directory: 'build_output'
As others have noted, it is looking for only the first part of your project name .dll. In my case, my project and Assembly name were both UC.Web which yielded the error during deployment:
Error: error stat /var/app/staging/UC.dll: no such file or directory with file /var/app/staging/UC.dll
My solution that worked was I renamed my Assembly name from UC.Web to simply UC and it deployed successfully. While a solution for everyone, it is a workaround for the time being until Amazon fixes this.

Redhat with httpd24 connecting to Informix using DBI

I'm at my wits' end on this. I have 2 RH7 boxes that I just installed httpd24 (v2.4.34) on. They were running httpd (v2.4.6) without any connection problems. Now when I try and run Perl scripts from the browser, they fail with...
install_driver(Informix) failed: Can't load '/usr/local/lib64/perl5/auto/DBD/Informix/Informix.so' for module DBD::Informix: libifsql.so: cannot open shared object file: No such file or directory at /usr/lib64/perl5/DynaLoader.pm line 190.
at (eval 5) line 3.
Compilation failed in require at (eval 5) line 3.
Perhaps a required shared library or dll isn't installed where expected
at /var/www/html/app/cgi-bin/test_informix_odbc.cgi line 35.
But when I run the same script from the command line, as 'apache', it runs just fine. All the ENV vars are set correctly.
Anyone run into anything similar before?
It would no longer use the LD_LIBRARY_PATH environment variable I was setting in httpd.conf.
Services are started in a fresh environment without any influence of user's environment (like environment variable values). As a consequence, information of all enabled collections will be lost during service start up.
Newer versions of httpd have stopped bringing the user environment in when the service is started. I found this little blurb in /opt/rh/httpd24/service-environment.
grep -r "LD_LIBRARY_PATH" /opt/rh/httpd24/
/opt/rh/httpd24/enable:export LD_LIBRARY_PATH=/opt/rh/httpd24/root/usr/lib64${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}}
I prepended the standard informix paths in /opt/rh/httpd24/enable.
export LD_LIBRARY_PATH=/opt/IBM/informix/lib:/opt/IBM/informix/lib/esql:/opt/rh/httpd24/root/usr/lib64${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}}
And everything is back to normal. Woohoo!

Installing Google Adwords Api Library (using docker)

Googles documentation on installing the library, found here: https://github.com/googleads/googleads-php-lib/blob/master/README.md#getting-started, instructs us to copy adsapi_php.ini, as constructed here: https://github.com/googleads/googleads-php-lib/blob/master/examples/AdWords/adsapi_php.ini, to your home directory.
I filled out the necessary variables in the .ini, and I am using docker so I have placed this file inside my container at /var/www/home/node/ and when I run the command composer require googleads/googleads-php-lib I am given the following error in the command prompt:
Your requirements could not be resolved to an installable set of packages.
Problem 1
- Installation request for googleads/googleads-php-lib ^37.1 -> satisfiable by googleads/googleads-php-lib[37.1.0].
- googleads/googleads-php-lib 37.1.0 requires ext-soap * -> the requested PHP extension soap is missing from your system.
To enable extensions, verify that they are enabled in your .ini files:
- /usr/local/etc/php/php.ini
- /usr/local/etc/php/conf.d/adsapi_php.ini
- /usr/local/etc/php/conf.d/docker-php-ext-pdo_pgsql.ini
- /usr/local/etc/php/conf.d/docker-php-ext-sodium.ini
- /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini
You can also run `php --ini` inside terminal to see which files are used by PHP in CLI mode.
Installation failed, reverting ./composer.json to its original content.
I assumed the issue was my adsapi_php.ini was simply in the wrong location as it contains what I believe is necessary to avoid the above issue, but I have tried placing it in several different places and yet I always get the same error.
Any help would be appreciated!
Just try to edit php.ini inside docker (docker exec -t {container} bashand enable there the extenstion soap

Cannot load /modules/mod_dav_svn.so into server

I'm getting a wired error when loading Apache (Win 2016 STD, Apache/2.4.29 x86, OpenSSL/1.0.2n SVN/1.9.2)
i.e.
"Syntax error on line ... of .../conf/httpd.conf:
Cannot load ...modules/mod_dav_svn.so into server: (...) The specified module could not be found:"
The file is in the conf file properly: "LoadModule dav_svn_module modules/mod_dav_svn.so"
The file exists in the "modules" folder.
Although Apache reports a syntax error, it is not because other modules are loaded just fine with the same syntax.
Other file also has this problem: "mod_authz_svn.so".
Prerequisites are loaded before this module successfully (mod_dav.so, mod_dav_fs.so).
The best part: in my lab it is working just fine but in the customer's machine (same OS mentioned), something is not working properly.
I really need any help you can give me here...
mod_dav_svn.so is from subversion server - so it does not come with apache and has to be added. If you have - then to problem might be that a visual c++ runtime of another version is required. To find out you could try a tool like dependecy walker.
When all missing dependencies are installed on the system your apache should start.