I'm developing a custom recipe using the package packages from chef.
I created a file under the recipes folder called apache.rb.
Then I uploaded the cookbook through berks and I edited the recipes list on one node with recipe["packages::apache"].
When i run the chef-client I got the following error:
could not find recipe apache for cookbook packages
This is the apache.rb located under recipes/ folder:
package 'Install Apache' do
case node[:platform]
when 'redhat', 'centos'
package_name 'httpd'
version '2.2.0'
when 'ubuntu', 'debian'
package_name 'apache2'
end
action :install
end
Can you try knife upload . --force, to make sure the cookbook is really up-to-date on the chef server?
There might be an older version of the cookbook already uploaded (i.e. before you created the apache recipe), and because you've kept the version number in metadata.rb the same, knife (or berks, depending on what you use for the upload) might be skipping the upload, thinking nothing's changed.
UPDATE:
It should be noted that the above should really only be used if you are really sure you want to update the existing version on the Chef Server (e.g. if you are still in development).
Bumping the version number on the cookbook's metadata would be a much better way to solve this problem for production environments, as pointed out by #Tensibai in the comments below.
Related
I am trying to use Composer to update a Drupal module. After reading a lot, I am presuming that proc_open is disabled in my shared hosting env. If that is the case, can it be enabled for just one hostname or is it server-wide?
"The Process class relies on proc_open, which is not available on your PHP installation."
From the host: Cpanel states the shell php is system wide so we cannot edit it for just this site. (this comes directly from a ticket they used at cPanel)
The module I was trying to update is for Drupal, Webform latest stable version. Not recommended to update with GUI or Manually....
I understand that proc_open is a potential security risk to other hosts but is there ANY workaround short of a dedicated server? Upping the co$t of doing business by a LOT :)
$ composer require 'drupal/webform:^6.2#beta'
./composer.json has been updated
Running composer update drupal/webform
Loading composer repositories with package information
Updating dependencies
Lock file op#drupal/webform (6.2.0-beta1)
Writing lock file
Installing dependencies from lock file (including require-dev)
Nothing to install, update or remove
2 package suggestions were added by new dependencies, use `composer suggest` to see details.
Package doctrine/reflection is abandoned, you should avoid using it. Use roave/better-reflection instead.
Generating autoload files
Hardening vendor directory with .htaccess and web.config files.
41 packages you are using are looking for funding.
Use the `composer fund` command to find out more!
Scaffolding files for drupal/core:
- Copy [web-root]/sites/default/default.services.yml from assets/scaffold/files/default.services.yml
- Copy [web-root]/sites/default/default.settings.php from assets/scaffold/files/default.settings.php
Installation failed, reverting ./composer.json and ./composer.lock to their original content.
[Symfony\Component\Process\Exception\RuntimeException]
The Process class relies on proc_open, which is not available on your PHP installation.
Have a basic doubt about puppet package resource.If I have a package resource declared in the the manifest file for eg:to install apache using apt-get.
1.During the first run of puppet agent,apache will get installed.
2.If I run the agent(using the existing code for package resource) again after ubuntu repo is refreshed with latest version of apache.
Will puppet update/refresh the apache in agent server?
The Package's ensure attribute determines the state.
What state the package should be in. On packaging systems that can retrieve new packages on their own, you can choose which package to retrieve by specifying a version number or latest as the ensure value. On packaging systems that manage configuration files separately from “normal” system files, you can uninstall config files by specifying purged as the ensure value. This defaults to installed.
Version numbers must match the full version to install, including release if the provider uses a release moniker. Ranges or semver patterns are not accepted except for the gem package provider. For example, to install the bash package from the rpm bash-4.1.2-29.el6.x86_64.rpm, use the string '4.1.2-29.el6'.
Valid values are present (also called installed), absent, purged, held, latest. Values can match /./.
Source: https://puppet.com/docs/puppet/5.3/types/package.html#package-attribute-ensure
I'm used to deploy code depending on Composer (PHP's NPM cousing), that sports .json and .lock files. The first one describes the package and your version constraints, and the second one lists exactly what was installed. Always there's a lock file and you run composer install you're sure to receive the same set of packages; running composer update will re-read the json file, install new versions, and update the lock file.
That's awesome for production deployment, since you don't need to checkout your dependencies to your versioning system and you're sure to have the exact same set of dependencies in production as you have in development.
My question is: how to best automate deployment of NPM-dependent code? Is it possible to achieve a method similar to Composer? I've noticed that npm install only installs what's first available in the package.json file. After the first run, i.e. if you change a version constraint you must manually npm update that package - and that would render automate deployment useless, as there's no way to check in to versioning "update this package here to a new version"...
npm shrinkwrap is a analog of composer.lock file. It will generate a npm-shrinkwrap.json, that have all deps with version in it, so you can use it to deploy to production env. Also you can try a various libs from npm to lock versions or search for updates of it without changing packages.json.
I am struggling around a wrong usage of composer, for sure.
I set up this repository: https://github.com/alle/assets-merger
I forked the project and was just trying to make it a kohana-module, including all the dependencies.
As for it would need the YUI comporess JAR, I was trying to make just that JARfile as a dependency, and I ended to declare it in the composer.json file (please, look at this).
Once I need to add my new package to a project I add it in the require section as follows:
...
"alle/assets-merger": "dev-master",
...
But the (latest) composer update command says:
Loading composer repositories with package information
Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.
Problem 1
- Installation request for alle/assets-merger dev-develop -> satisfiable by alle/assets-merger[dev-develop].
- alle/assets-merger dev-develop requires yui/yuicompressor 2.4.8 -> no matching package found.
Potential causes:
- A typo in the package name
- The package is not available in a stable-enough version according to your minimum-stability setting see <https://groups.google.com/d/topic/composer-dev/_g3ASeIFlrc/discussion> for more details.
And my story ends here.
How should I configure my composer.json in the https://github.com/alle/assets-merger repository, in order to include it as a fully satisfied kohana-module in other projects?
Some things I notice in your composer.json.
There is a version of that CSS minify available on Packagist which says it is just a copy of the original Goole-Code hosted files, but with Composer: natxet/cssmin. It is version 3.0.2, but I think that shouldn't make a difference.
mrclay/minify is included twice in the packages with the same version. It also is available on Packagist. You will probably already use that (version 2.2.0 is registered, and because you didn't turn of Packagist access, it will be generally available for install unless a version requirement or conflict prevents it).
You are trying to download a JAR file (which is a java executable without and PHP), but try to get PHP classmaps out of it. That will fail for sure.
You did miss the big note in the Composer documentation saying that Composer cannot resolve repositories mentioned in sub packages, only in the root package. That means that whatever you mention in your alle/asset-merger package will not be used if you use that package anywhere else. You'd have to duplicate these repositories in every package in addition to adding the package name itself as "required".
What this means is that you probably avoided missing mrclay/minify because it is available on Packagist, you might as well have added the cssmin by accident, but you definitly did not add YUICompressor.
But you shouldn't add this in the first place, because it is no PHP software. You can however add post-install commands to your projects. All your Composer integration does is download the JAR file. You can do that with a post-install or post-update command. See the documentation here.
Is there a way to view the documentation of any package I installed in a cabal sandbox? Currently I have a script that places the documentation in a common path so I can view it with a simple server script, but I imagine there's a better or more accepted way of doing this.
To be clear, I do not mean cabal-dev, but the sandboxing tools in the latest cabal.
If you install packages into sandbox with documentation enabled (cabal install --enable-documentation or documentation: True in ./cabal.config), the generated documentation will be put under ./.cabal-sandbox/share/doc/$arch-$os-$compiler/$pkigid. In other words, this works in the same way as with the user package DB (one exception is that a local documentation index is not created in the sandbox case - this is a known issue).