Running chef-solo (Installing Chef Omnibus (12.3)) on centos6.6
My recipe has the following simple code:
package 'cloud-init' do
action :install
end
log 'rpm-qi' do
message `rpm -qi cloud-init`
level :warn
end
log 'yum list' do
message `yum list cloud-init`
level :warn
end
But it outputs the following:
- install version 0.7.5-10.el6.centos.2 of package cloud-init
* log[rpm-qi] action write[2015-07-16T16:46:35+00:00] WARN: package cloud-init is not installed
[2015-07-16T16:46:35+00:00] WARN: Loaded plugins: fastestmirror, presto
Available Packages
cloud-init.x86_64 0.7.5-10.el6.centos.2 extras
I am at a loss as to why rpm/yum and actually rpmquery don't see the package as installed.
EDIT: To clarify I am specifically looking for the following string post package install to then apply a change to the file (I understand this is not a very chef way to do something I am happy to accept suggestions):
rpmquery -l cloud-init | grep 'distros/__init__.py$'
I have found that by using the following:
install_report = shell_out('yum install -y cloud-init').stdout
cloudinit_source = shell_out("rpmquery -l cloud-init | grep 'distros/__init__.py$'").stdout
I can then get the file I am looking for and perform
Chef::Util::FileEdit.new(cloudinit_source.chomp(''))
The file moves based on the distribution but I need to edit that file specifically with in place changes.
Untested code, just to give the idea:
package 'cloud-init' do
action :install
notifies :run,"ruby_block[update_cloud_init]"
end
ruby_block 'update_cloud_init' do
block do
cloudinit_source = shell_out("rpmquery -l cloud-init | grep 'distros/__init__.py$'").stdout
rc = Chef::Util::FileEdit.new(cloudinit_source.chomp(''))
rc.search_file_replace_line(/^what to find$/,
"replacement datas for the line")
rc.write_file
end
end
ruby_block example taken and adapted from here
I would better go using a template to manage the whole file, what I don't understand is why you don't know where it will be at first...
Previous answer
I assume it's a compile vs converge problem. at the time the message is stored (and so your command is executed) the package is not already installed.
Chef run in two phase, compile then converge.
At compile time it build a collection of resources and at converge time it execute code for the resource to get them in the described state.
When your log resource is compiled, the ugly back-ticks are evaluated, at this time there's a package resource in the collection but the resource has not been executed, so the output is correct.
I don't understand what you want to achieve with those log resources at all.
If you want to test your node state after chef-run use a handler maybe calling ServerSpec as in Test-Kitchen.
Related
After booting SWUpdate yocto-generated image for the first time, executing swupdate results in error message:
Error parsing configuration file: 'globals' section missing, exiting.
I tried to strictly follow SWUpdate's documentation, but it gets short when it comes to yocto integration. I'm using meta-swupdate, meta-swupdate-boards, and meta-openembedded layers together with poky example repository all at Kirkstone tag, building via bitbake update-image and having modyfied local.conf as:
MACHINE ??= "raspberrypi4-64"
ENABLE_UART = "1"
RPI_USE_U_BOOT = "1"
IMAGE_FSTYPES = "wic ext4.gz"
PREFERRED_PROVIDER_u-boot-fw-utils = "libubootenv"
IMAGE_INSTALL:append = " swupdate"
Is there anything else I need to modify to generate the configuration file and be able to run SWUpdate binary properly?
Side question: In the documentation, it's recommended to append swupdate-www to achieve a better web server. However, if I append it, there is no swupdate-www binary inside the `/usr/bin' directory.
As with other recipes folders the recipes-support/swupdate/swupdate/raspberrypi4-64 folder was missing inside the meta-swupdate-boards layer. Therefore, an empty config file was always generated. After adding this folder and all related files, strongly inspired by raspberrypi3 folder, the error was gone and swupdate -h provided the expected output.
There was also one new error during build process thrown by yocto. It was related to missing systemd requirement and was solved by adding:
DISTRO_FEATURES_append = " systemd"
to local.conf
gitolite info didn't work, adding keys turned them into a no access key and did NOT create a corresponding entry in auth-keys file.
To fix this run gitolite setup on gitolite server
Question: what could have landed me in that mess?
And what does gitolite setup do when invoked for the n-th time (it's no longer setting things up, according to the docs it fixes hooks, but I wonder what the use case would be and which was mine)?
More details on gitolite info
gitolite info command is invoked like so:
> ssh git-user#ser-git
PTY allocation request failed on channel 0
hello git-admin, this is ...#... running gitolite3 3.6.7-2 (Debian) on git 2.17.1
R W some-repository
R W gitolite-admin
R W testing
Connection to ser-git closed.
Bad output is: FATAL: unknown git/gitolite command: 'info'
More details: keys without access.
gitolite sshkeys-lint was showing keys with (no access), now those keys have access as I set them (now meaning after gitolite setup).
ssh-keygen -lf /home/repo/.ssh/authorized_keys | wc -l (or without piped part, regardless) number of keys and their names indicated I didn't have the newest one added.
Similar question that did not work for me: keydir entries not propagating to authorized_keys
Docs pretty much had the answer once I dug deeper, I guess. Which is fairly nice of #sitaramc.
Without options, 'gitolite setup' is a general "fix up everything" command
(for example, if you brought in repos from outside, or someone messed
around with the hooks, or you made an rc file change that affects access
rules, etc.)
Symptoms keys stopped propagating and error FATAL: unknown git/gitolite command: 'info' on ssh git-user#ser-git. Fix was to run gitolite setup. So onto first question, the title one:
what does gitolite setup fix?
gitolite setup is implemented here
my Perl is rather weak, but there's a setup function in line 56. It calls args (which parses options, so here it had nothing to parse), then unless h_only (hooks only arg for setup), which wasn't used, so we skip compile and POST_COMPILE trigger and go for the hooks.
sub setup {
my ( $admin, $pubkey, $h_only, $message ) = args();
unless ($h_only) {
setup_glrc();
setup_gladmin( $admin, $pubkey, $message );
_system("gitolite compile");
_system("gitolite trigger POST_COMPILE");
}
hook_repos(); # all of them, just to be sure
}
package Gitolite::conf::store has hook_repos(), line 228: we change the dir to repo base dir (as per config file), and for each phy_repo we do hook_1(phy_repo). What is a phy_repo? a physical one.
same package, different method and line: hook_1($repo) in line 354.
Method hook_1($repo)
It's quite literally about fixing all the hooks.
Recreates dirs for common and admin hooks.
Rewrites update_hook (common) and post_update_hook (admin).
Sets 755 permissions for both common and admin hooks.
Then using ln_sf it symlinks the folders for common/admin hooks.
ln_sf is in common module, in line 162
When I try to install multiples packages with a wildcard naming I got the following error:
* yum_package[mysql-server] action install (up to date)
* yum_package[mysql*] action install
* No candidate version available for mysql*
============================================================================ ====
Error executing action `install` on resource 'yum_package[mysql*]'
============================================================================ ====
Recipe code is:
package 'mysql-server' do
action :install
end
package 'mysql*' do
action :install
end
You have to use the exact package name. The chef package resource does no magic to find matching packages.
The name of the resource (the part just after package) is used as the package name and given to the underlying system (yum on RH like systems, apt on debian like systems)
If you have multiples packages to install and a common configuration you can loop over them in your recipe instead:
['mysql-server','mysql-common','mysql-client'].each do |p|
package p do
action :install
end
end
The array creation could be simplified with some ruby syntax as the words builder %w:
%w(mysql-server mysql-common mysql-client).each [...]
Since chef 12.1 the package resource accept an array of packages directly like this:
package %w(mysql-server mysql-common mysql-client)
This can be resolved using chef cases. Please see below
add the following to your attributes file:
packages = []
case node[:platform_family]
when 'rhel' #based on your OS
packages = [
"package1",
"package2",
"package3",
"package4",
"package5",
"package6",
"package7" ## Last line without comma
]
end
default[:cookbookname][:packages] = packages
Then, add the following to your recipe file (recipes/default.rb):
node[:cookbookname][:packages].each do |pkg|
package pkg do
action :install
retries 3
retry_delay 5
end
end
I have configured a private APT repository (using resources on internet like http://inodes.org/2009/09/14/building-a-private-ppa-on-ubuntu/) and I'm uploading for the first time my package containing the sources of my C++ application.
So reprepro repository is empty.
I use the following command in order to start the build:
sudo reprepro -V -b /srv/reprepro processincoming incoming
Then the build start, a lot of output is genearated and I can see that pbuilder is compiling the project source code and everything is fine. I can even find in the result/ folder debian packages etc...
But the build failed with a POST_BUILD_FAILED because it seems that pbuilder has changed the douane-testing_0.8.1-apt1.debian.tar.gz file and the md5 sum is now different as shown here:
File "pool/main/d/douane-testing/douane-testing_0.8.1-apt1.debian.tar.gz" is already registered with different checksums!
md5 expected: 97257ae2c5790b84ed7bb1b412f1d518, got: df78f88b97cadc10bc0a73bf86442838
sha1 expected: ae93c44593e821696f72bee4d91ce4b6f261e529, got: d6f910ca5707ec92cb71601a4f4c72db0e5f18d9
sha256 expected: c3fac5ed112f89a8ed8d4137b34f173990d8a4b82b6212d1e0ada1cddc869b0e, got: ebdcc9ead44ea0dd99f2dc87decffcc5e3efaee64a8f62f54aec556ac19d579c
size expected: 2334, got: 2344
There have been errors!
I don't understand why it is failing as when I compare the 2 packages (having those md5 sums) the content is strictly the same (I used a diff tool but no differences and no new or removed files).
The only thing I can see is that the archive from pbuild is bigger of 10 Bytes than the orginal one I have uploaded:
On my development machine, the file with the md5 97257ae2c5790b84ed7bb1b412f1d518 :
-rw-r--r-- 1 zedtux zedtux 2334 Feb 3 23:38 douane-testing_0.8.1-apt1.debian.tar.gz
On my server, the file with the md5 df78f88b97cadc10bc0a73bf86442838 :
-rw-r--r-- 1 root root 2344 Feb 5 00:58 douane-testing_0.8.1-apt1.debian.tar.gz
I have pbuild version 0.213 on my server.
What could be the reason of this behavior and how can I fix it ?
Edit
I'm suspecting an issue with the GPG key which looks missing and then files aren't signed so md5sum is different.
During the build process I have the following lines:
I: Extracting source
gpgv: Signature made Wed Feb 5 22:04:37 2014 UTC using RSA key ID 9474CF36
gpgv: Can't check signature: public key not found
dpkg-source: warning: failed to verify signature on ./douane-testing_0.8.1-apt1.dsc
Edit 2
I have tried to find the command to create manually the .debian.tar.gz file.
The best I've found is the following:
tar cv debian | gzip --no-name --rsyncable -9 > douane-testing_0.8.1-apt1.debian.tar.gz
I don't get the same result than dpkg-source but I tried the same command on my server (I should at least have the same size) but it's not matching...
Could it be that Debian and Ubuntu aren't compressing the same way ?
Finally after some evenings of research I found the solution on launchpad.net !
Found the solution. By default pbuilder calls dpkg-buildpackage like so:
DEBBUILDOPTS="$DEBBUILDOPTS -rfakeroot"
dpkg-buildpackage -us -uc $DEBBUILDOPTS
That causes dpkg-buildpackage to rebuild the diff.gz and .dsc files. Add a -b in there, and it won't. It also means the resulting .changes file will only reference the .deb file. Which is what you want, I think.
The easy solution is to add a line to your .pbuilderrc:
DEBBUILDOPTS="-b"
My previous answer is alright but is not complete.
Then I had the issue that reprepro complains about the source tarball (.orig.tar.xz).
But it was normal as I wasn't doing the packages correctly.
I have written a bash script which I'm executing in VM for each Ubuntu series.
This script was always doing everything from scratch, and was using dh_make --createorig argument and here is the issue.
The correct way is to generate once (for example on Ubuntu precise) and then re-use the .orig.tar.xz file and no more use the --createorig argument of dh_make.
I hope this could help someone :-)
After successfully installation of Apache2(2.4.4) i tried to start https server but i am getting below error
bimlesh#server:/usr/local/apache2/bin$ ./apachectl start
httpd: Syntax error on line 71 of /usr/local/apache2/conf/httpd.conf: Cannot load modules/mod_authn_core.so into server: /usr/local/apache2/modules/mod_authn_core.so: cannot open shared object file: No such file or directory
bimlesh#server:/usr/local/apache2/bin$
I looked at /usr/local/apache2/modules/ and really those .so files are not available.
Can anyone please help that how to get rid off.
if i look at /usr/local/apache2/modules/ folder then i see:(no .so files available)
bimlesh#server:/usr/local/apache2/bin$ ls ../modules/
httpd.exp mod_authn_file.a mod_cache_disk.a mod_file_cache.a mod_logio.la mod_ratelimit.a mod_socache_dbm.la
mod_access_compat.a mod_authn_file.la mod_cache_disk.la mod_file_cache.la mod_mime.a mod_ratelimit.la mod_socache_memcache.a
mod_access_compat.la mod_authn_socache.a mod_cache.la mod_filter.a mod_mime.la mod_remoteip.a mod_socache_memcache.la
mod_actions.a mod_authn_socache.la mod_cgid.a mod_filter.la mod_negotiation.a mod_remoteip.la mod_socache_shmcb.a
mod_actions.la mod_authz_core.a mod_cgid.la mod_headers.a mod_negotiation.la mod_reqtimeout.a mod_socache_shmcb.la
mod_alias.a mod_authz_core.la mod_dav.a mod_headers.la mod_proxy.a mod_reqtimeout.la mod_speling.a
mod_alias.la mod_authz_dbd.a mod_dav_fs.a mod_include.a mod_proxy_ajp.a mod_request.a mod_speling.la
mod_allowmethods.a mod_authz_dbd.la mod_dav_fs.la mod_include.la mod_proxy_ajp.la mod_request.la mod_status.a
mod_allowmethods.la mod_authz_dbm.a mod_dav.la mod_info.a mod_proxy_balancer.a mod_rewrite.a mod_status.la
mod_auth_basic.a mod_authz_dbm.la mod_dbd.a mod_info.la mod_proxy_balancer.la mod_rewrite.la mod_substitute.a
mod_auth_basic.la mod_authz_groupfile.a mod_dbd.la mod_lbmethod_bybusyness.a mod_proxy_connect.a mod_sed.a mod_substitute.la
mod_auth_digest.a mod_authz_groupfile.la mod_deflate.a mod_lbmethod_bybusyness.la mod_proxy_connect.la mod_sed.la mod_unique_id.a
mod_auth_digest.la mod_authz_host.a mod_deflate.la mod_lbmethod_byrequests.a mod_proxy_express.a mod_session.a mod_unique_id.la
mod_auth_form.a mod_authz_host.la mod_dir.a mod_lbmethod_byrequests.la mod_proxy_express.la mod_session_cookie.a mod_unixd.a
mod_auth_form.la mod_authz_owner.a mod_dir.la mod_lbmethod_bytraffic.a mod_proxy_fcgi.a mod_session_cookie.la mod_unixd.la
mod_authn_anon.a mod_authz_owner.la mod_dumpio.a mod_lbmethod_bytraffic.la mod_proxy_fcgi.la mod_session_dbd.a mod_userdir.a
mod_authn_anon.la mod_authz_user.a mod_dumpio.la mod_lbmethod_heartbeat.a mod_proxy_ftp.a mod_session_dbd.la mod_userdir.la
mod_authn_core.a mod_authz_user.la mod_env.a mod_lbmethod_heartbeat.la mod_proxy_ftp.la mod_session.la mod_version.a
mod_authn_core.la mod_autoindex.a mod_env.la mod_log_config.a mod_proxy_http.a mod_setenvif.a mod_version.la
mod_authn_dbd.a mod_autoindex.la mod_expires.a mod_log_config.la mod_proxy_http.la mod_setenvif.la mod_vhost_alias.a
mod_authn_dbd.la mod_buffer.a mod_expires.la mod_log_debug.a mod_proxy.la mod_slotmem_shm.a mod_vhost_alias.la
mod_authn_dbm.a mod_buffer.la mod_ext_filter.a mod_log_debug.la mod_proxy_scgi.a mod_slotmem_shm.la
mod_authn_dbm.la mod_cache.a mod_ext_filter.la mod_logio.a mod_proxy_scgi.la mod_socache_dbm.a
bimlesh#server:/usr/local/apache2/bin$
Run
find / -type f -name mod_authn_core.so
or install updatedb ( mlocate, slocate, findutils or sth ) if needed and run
updatedb
and then ( or before )
locate mod_authn_core.so
To find out if these files are somewere else than they should be, and possibly fix location with symbolic link or moving files where they're expected to be.
If there is no file you need, you may need to comment it in httpd.conf ( if it's specific module ), or (re)install apache package(s). I believe mod_authn_core should be in basic package, not in separate module though. Possibly someone removed it blindly or accidentally, or some intruder messed up with system, or disk got broken or whatever else.
PS. Modules usually are under "lib" e.g. /usr/local/lib/apache2 or /usr/lib/apache2, or /usr/lib/apache2/modules or similar, not in /usr/local/apache2/modules, though it usually depends on compilation of package..
You might also run
apache2ctl -t -D DUMP_VHOSTS
to find out what modules were compiled as shared or static. You should also include information about distribution, and note you're building/installing from source.
Also, have look here: http://httpd.apache.org/docs/2.4/install.html#configure