Error uploading artifacts to coordinator - gitlab

I’ve been having some fun setting up GitLab and after spending quite a while hacking away at it, I’ve become relatively used to setting it up, now having done that on two machines, the second time around with much more ease than originally…
However, I am faced with a rather large problem, on both machines: My CI pipeline is broken. Somehow, somewhere, my setup is providing a 403 to artifacts once builds are completed, meaning that each and every job that ever technically succeeds will only be doomed to fail…
I've been scavenging the interwebs for answers but I haven't found much that has been useful.
I upgraded GitLab CE to 10.1.4 minutes ago, as well as GitLab-runner to 10.1.0, the latest packages available to me through apt on the more important of the two machines, running a newer version of Ubuntu than the other - 17.04 zesty on the “beast” compared to 16.10 yakkety on “q2”.
Both gitlab-runner registrations use shell for execution.
The relevant output of the CI job is as follows:
Cloning repository...
Cloning into '/[clonepath]'...
Checking out 8319d586 as master...
Skipping Git submodules setup
mesg: ttyname failed: Inappropriate ioctl for device
mesg: ttyname failed: Inappropriate ioctl for device
mesg: ttyname failed: Inappropriate ioctl for device
$ mvn -B install
[INFO] Scanning for projects...
...
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 11.204 s
[INFO] Finished at: 2017-11-18T05:45:08+01:00
[INFO] Final Memory: 27M/640M
[INFO] ------------------------------------------------------------------------
mesg: ttyname failed: Inappropriate ioctl for device
mesg: ttyname failed: Inappropriate ioctl for device
mesg: ttyname failed: Inappropriate ioctl for device
Uploading artifacts...
target/*.jar: found 1 matching files
ERROR: Uploading artifacts to coordinator... forbidden id=35 responseStatus=403
Forbidden status=403 Forbidden token=sP9oHykF
FATAL: permission denied
ERROR: Job failed: exit status 1
I run GitLab under an Apache2 Vhost subdomain, mostly for aesthetic and omitting of the port following the host, i.e. 8080 for unicorn, since there are other sites running on Apache.
These are the configured options within my gitlab.rb:
gitlab_rails['trusted_proxies'] = [ '127.0.0.1' ]
gitlab_workhorse['listen_network'] = "tcp"
gitlab_workhorse['listen_addr'] = "127.0.0.1:8181"
nginx['enable'] = false
Setting the values in either of the following options/values as such
web_server['username'] = 'www-data'
web_server['group'] = 'www-data'
produces an error on reconfiguration:
Starting Chef Client, version 12.12.15
resolving cookbooks for run list: ["gitlab"]
Synchronizing Cookbooks:
- package (0.1.0)
- registry (0.1.0)
- consul (0.0.0)
- gitlab (0.0.1)
- runit (0.14.2)
Installing Cookbook Gems:
Compiling Cookbooks...
Recipe: gitlab::default
* directory[/etc/gitlab] action create (up to date)
Converging 408 resources
* directory[/etc/gitlab] action create (up to date)
* directory[Create /var/opt/gitlab] action create (up to date)
* directory[/opt/gitlab/embedded/etc] action create (up to date)
* template[/opt/gitlab/embedded/etc/gitconfig] action create (up to date)
Recipe: gitlab::web-server
* group[Webserver user and group] action create (up to date)
* user[Webserver user and group] action create
================================================================================
Error executing action `create` on resource 'user[Webserver user and group]'
================================================================================
Mixlib::ShellOut::ShellCommandFailed
------------------------------------
Expected process to exit with [0], but received '8'
---- Begin output of ["usermod", "-s", "/bin/false", "-d", "/var/opt/gitlab/nginx", "www-data"] ----
STDOUT:
STDERR: usermod: user www-data is currently used by process 2656
---- End output of ["usermod", "-s", "/bin/false", "-d", "/var/opt/gitlab/nginx", "www-data"] ----
Ran ["usermod", "-s", "/bin/false", "-d", "/var/opt/gitlab/nginx", "www-data"] returned 8
Resource Declaration:
---------------------
# In /opt/gitlab/embedded/cookbooks/cache/cookbooks/package/definitions/account.rb
38: user params[:name] do
39: username username
40: shell params[:shell]
41: home params[:home]
42: uid params[:uid]
43: gid params[:ugid]
44: system params[:system]
45: supports params[:user_supports]
46: action params[:action]
47: end
48: end
Compiled Resource:
------------------
# Declared in /opt/gitlab/embedded/cookbooks/cache/cookbooks/package/definitions/account.rb:38 :in `block in from_file'
user("Webserver user and group") do
params {:action=>nil, :username=>"www-data", :uid=>nil, :ugid=>"www-data", :groupname=>"www-data", :gid=>nil, :shell=>"/bin/false", :home=>"/var/opt/gitlab/nginx", :system=>true, :append_to_group=>true, :group_members=>["www-data"], :user_supports=>{:manage_home=>false}, :manage=>true, :name=>"Webserver user and group"}
action [:create]
supports {:manage_home=>false}
retries 0
retry_delay 2
default_guard_interpreter :default
username "www-data"
gid 33
home "/var/opt/gitlab/nginx"
shell "/bin/false"
system true
iterations 27855
declared_type :user
cookbook_name "gitlab"
recipe_name "web-server"
end
Platform:
---------
x86_64-linux
Running handlers:
Running handlers complete
Chef Client failed. 0 resources updated in 04 seconds
And as for Apache, here’s the SSL-enabled Vhost:
<IfModule mod_ssl.c>
<VirtualHost *:443>
ServerName [host]
ServerAdmin [email]
DocumentRoot /opt/gitlab/embedded/service/gitlab-rails/public
ServerSignature Off
ProxyPreserveHost On
AllowEncodedSlashes NoDecode
<Location />
Order deny,allow
Allow from all
Require all granted
ProxyPassReverse http://127.0.0.1:8181/
ProxyPassReverse http://[host]/
RequestHeader set X-Forwarded-Ssl 'on'
</Location>
RewriteEngine on
RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f [OR]
RewriteCond %{REQUEST_URI} ^/uploads/.*
RewriteRule .* http://127.0.0.1:8181%{REQUEST_URI} [P,QSA,NE]
SSLCertificateFile /etc/letsencrypt/live/[host]/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/[host]/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
</VirtualHost>
</IfModule>
Any idea what’s going on? I haven’t dug the Apache log information yet since it probably won’t be Apache as the request goes straight to gitlab-worker (8181). What logs should I check for that, if necessary?
Thankyou for your time.

This isn't a particularly helpful answer, as the solution has little explanation for its workings.
The configurations I had have remained the same as per above, but the runner I had installed, I removed the config of, rm /etc/gitlab-runner/config.toml, and then proceeded to remove the package from the machine, apt purge gitlab-runner. (gitlab-ci-multi-runner is another package that is available but does not appear to be up to date with GitLab 10 - returns a 404 rather than connecting to the node).
I reinstalled the runner, apt install gitlab-runner, and then registered it - gitlab-runner register. The key thing to note here is that during registration, I used my FQDN, as in https://git.example.com rather than any local address such as http://localhost:8080 or http://localhost:8181 (unicorn, gitlab-workhorse, respectively). And yes, I am running my runners on my local machine. Hazardous, but I have too much trust in my team. That may be our downfall, ignorant systems administration is key to success.

Related

Getting error in Chef-ERROR: shard_seed: Failed to get dmi property serial_number: is dmidecode installed?

I am getting error while running a code in chef
chef-client -zr "recipe[test-cookbook::test-recipe1]"
[2020-08-05T16:01:06+00:00] WARN: No config file found or specified on command line. Using command line options instead.
Starting Chef Infra Client, version 16.3.45
[2020-08-05T16:01:08+00:00] ERROR: shard_seed: Failed to get dmi property serial_number: is dmidecode installed?
resolving cookbooks for run list: ["test-cookbook::test-recipe1"]
Synchronizing Cookbooks:
test-cookbook (0.1.0)
Installing Cookbook Gems:
Compiling Cookbooks...
Converging 0 resources
Running handlers:
Running handlers complete
Chef Infra Client finished, 0/0 resources updated in 01 seconds

Firebase Web Init Error File Already Exists

I've installed Node.js, npm, and firebase-tools. I want to deploy a web app using Firebase hosting. I follow the documentation and do the commands as shown, but I get an unexpected error. I've posted the firebase debug log. How do I fix this?
[debug] [2019-04-20T21:08:12.230Z] ----------------------------------------------------------------------
[debug] [2019-04-20T21:08:12.233Z] Command: C:\Program Files\nodejs\node.exe C:\Users\Cameron\AppData\Roaming\npm\node_modules\firebase-tools\lib\bin\firebase.js init
[debug] [2019-04-20T21:08:12.233Z] CLI Version: 6.7.0
[debug] [2019-04-20T21:08:12.233Z] Platform: win32
[debug] [2019-04-20T21:08:12.233Z] Node Version: v11.14.0
[debug] [2019-04-20T21:08:12.234Z] Time: Sat Apr 20 2019 17:08:12 GMT-0400 (Eastern Daylight Time)
[debug] [2019-04-20T21:08:12.234Z] ----------------------------------------------------------------------
[debug]
[debug] [2019-04-20T21:08:12.241Z] > command requires scopes: ["email","openid","https://www.googleapis.com/auth/cloudplatformprojects.readonly","https://www.googleapis.com/auth/firebase","https://www.googleapis.com/auth/cloud-platform"]
[debug] [2019-04-20T21:08:12.242Z] > authorizing via signed-in user
[info]
######## #### ######## ######## ######## ### ###### ########
## ## ## ## ## ## ## ## ## ## ##
###### ## ######## ###### ######## ######### ###### ######
## ## ## ## ## ## ## ## ## ## ##
## #### ## ## ######## ######## ## ## ###### ########
You're about to initialize a Firebase project in this directory:
C:\Users\Cameron
Before we get started, keep in mind:
* You are initializing your home directory as a Firebase project
[info]
=== Project Setup
[info]
[info] First, let's associate this project directory with a Firebase project.
[info] You can create multiple project aliases by running firebase use --add,
[info] but for now we'll just set up a default project.
[info]
[debug] [2019-04-20T21:08:16.637Z] > refreshing access token with scopes: ["email","https://www.googleapis.com/auth/cloud-platform","https://www.googleapis.com/auth/cloudplatformprojects.readonly","https://www.googleapis.com/auth/firebase","openid"]
[debug] [2019-04-20T21:08:16.638Z] >>> HTTP REQUEST POST https://www.googleapis.com/oauth2/v3/token
<request body omitted>
[debug] [2019-04-20T21:08:16.846Z] <<< HTTP RESPONSE 200
[debug] [2019-04-20T21:08:16.878Z] >>> HTTP REQUEST GET https://firebase.googleapis.com/v1beta1/projects?page_size=100
[debug] [2019-04-20T21:08:17.215Z] <<< HTTP RESPONSE 200
[info] i Using project autoretarb (autoretarb)
[info]
=== Hosting Setup
[info]
[info] Your public directory is the folder (relative to your project directory) that
[info] will contain Hosting assets to be uploaded with firebase deploy. If you
[info] have a build process for your assets, use your build's output directory.
[info]
[debug] [2019-04-20T21:08:33.318Z] Error: EEXIST: file already exists, mkdir 'C:\Users\Cameron'
at Object.mkdirSync (fs.js:773:3)
at mkdirsSync (C:\Users\Cameron\AppData\Roaming\npm\node_modules\firebase-tools\node_modules\fs-extra\lib\mkdirs\mkdirs-sync.js:22:9)
at mkdirsSync (C:\Users\Cameron\AppData\Roaming\npm\node_modules\firebase-tools\node_modules\fs-extra\lib\mkdirs\mkdirs-sync.js:27:16)
at mkdirsSync (C:\Users\Cameron\AppData\Roaming\npm\node_modules\firebase-tools\node_modules\fs-extra\lib\mkdirs\mkdirs-sync.js:28:9)
at mkdirsSync (C:\Users\Cameron\AppData\Roaming\npm\node_modules\firebase-tools\node_modules\fs-extra\lib\mkdirs\mkdirs-sync.js:28:9)
at mkdirsSync (C:\Users\Cameron\AppData\Roaming\npm\node_modules\firebase-tools\node_modules\fs-extra\lib\mkdirs\mkdirs-sync.js:28:9)
at mkdirsSync (C:\Users\Cameron\AppData\Roaming\npm\node_modules\firebase-tools\node_modules\fs-extra\lib\mkdirs\mkdirs-sync.js:28:9)
at mkdirsSync (C:\Users\Cameron\AppData\Roaming\npm\node_modules\firebase-tools\node_modules\fs-extra\lib\mkdirs\mkdirs-sync.js:28:9)
at mkdirsSync (C:\Users\Cameron\AppData\Roaming\npm\node_modules\firebase-tools\node_modules\fs-extra\lib\mkdirs\mkdirs-sync.js:28:9)
at mkdirsSync (C:\Users\Cameron\AppData\Roaming\npm\node_modules\firebase-tools\node_modules\fs-extra\lib\mkdirs\mkdirs-sync.js:28:9)
[error]
[error] Error: An unexpected error has occurred.
First of all notice the warning near the top:
Before we get started, keep in mind:
You are initializing your home directory as a Firebase project
Please be certain that you want to use your home directory as a project root. This generally is not a really good idea. It will definitely cause problems later if you want to create other projects in your home directory. Instead, I suggest you create a new directory and run firebase init from there. The CLI will want to create bunch of other files and dirs there.
Now, notice the prompt where you got the error:
Your public directory is the folder (relative to your project
directory) that will contain Hosting assets to be uploaded with
firebase deploy. If you have a build process for your assets,
use your build's output directory.
It specifically says relative to your project directory, but you gave it an absolute path "C:\Biz Drive\admin_public".
It's better to allow the Firebase CLI to create the public folder at its default location within the project folder, unless you know you have a very specific need otherwise. In order to get started, I suggest just taking the defaults, then modifying them later in firebase.json afterward.
If you are using Windows
I faced same error then I just run command prompt as admin then problem solved.

Anchore Engine - Jenkins CI plugin

We are trying to scan our docker images using Anchore Engine Jenkins plugin.
Currently we create our application docker images, push it in our own private local registry and then deploy it in our test environments.
Now, we want to setup docker image scanning in our CI/CD process to check for any vulnerabilities.
We have installed Anchore Engine using the recommended Docker-Compose yaml method given in the Documentation link:
https://anchore.freshdesk.com/support/solutions/articles/36000020729-install-on-docker-swarm
Post installation, we installed the
Anchore Container Image Scanner Plugin in Jenkins.
We configured the plugin as mentioned in the document link:
https://wiki.jenkins.io/display/JENKINS/Anchore+Container+Image+Scanner+Plugin
However, the scanning fails. Error Message as follows:
2018-10-11T07:01:44.647 INFO AnchoreWorker Analysis request accepted, received image digest sha256:7d6fb7e5e7a74a4309cc436f6d11c29a96cbf27a4a8cb45a50cb0a326dc32fe8
2018-10-11T07:01:44.647 INFO AnchoreWorker Waiting for analysis of 10.180.25.2:5000/hello-world:latest, polling status periodically
2018-10-11T07:01:44.647 DEBUG AnchoreWorker anchore-engine get policy evaluation URL: http://10.180.25.2:8228/v1/images/sha256:7d6fb7e5e7a74a4309cc436f6d11c29a96cbf27a4a8cb45a50cb0a326dc32fe8/check?tag=10.180.25.2:5000/hello-world:latest&detail=true
2018-10-11T07:01:44.648 DEBUG AnchoreWorker Attempting anchore-engine get policy evaluation (1/300)
2018-10-11T07:01:44.675 DEBUG AnchoreWorker anchore-engine get policy evaluation failed. URL: http://10.180.25.2:8228/v1/images/sha256:7d6fb7e5e7a74a4309cc436f6d11c29a96cbf27a4a8cb45a50cb0a326dc32fe8/check?tag=10.180.25.2:5000/hello-world:latest&detail=true, status: HTTP/1.1 404 NOT FOUND, error: {
"detail": {},
"httpcode": 404,
"message": "image is not analyzed - analysis_status: not_analyzed"
}
NOTE:
In Image TAG 10.180.25.2:5000/hello-world:latest, 10.180.25.2:5000 is our local private registry and hello-world:latest is latest hello-world image available in docker hub which we pulled and pushed in our registry to try out image scanning using Anchore-Engine.
Unfortunately we are not able to find much resource online to try and resolve the above mentioned issue.
Anyone who might have worked on Anchore-Engine, please may I request to have a look and help us resolve this issue.
Also, any suggestions or alternatives to anchore-engine or detailed steps in case we might have missed anything would be really appreciated.
End of the output is as follows:
2018-10-15T00:48:43.880 WARN AnchoreWorker anchore-engine get policy evaluation failed. HTTP method: GET, URL: http://10.180.25.2:8228/v1/images/sha256:7d6fb7e5e7a74a4309cc436f6d11c29a96cbf27a4a8cb45a50cb0a326dc32fe8/check?tag=10.180.25.2:5000/hello-world:latest&detail=true, status: 404, error: {
"detail": {},
"httpcode": 404,
"message": "image is not analyzed - analysis_status: not_analyzed"
}
2018-10-15T00:48:43.880 WARN AnchoreWorker Exhausted all attempts polling anchore-engine. Analysis is incomplete for sha256:7d6fb7e5e7a74a4309cc436f6d11c29a96cbf27a4a8cb45a50cb0a326dc32fe8
2018-10-15T00:48:43.880 ERROR AnchorePlugin Failing Anchore Container Image Scanner Plugin step due to errors in plugin execution
hudson.AbortException: Timed out waiting for anchore-engine analysis to complete (increasing engineRetries might help). Check above logs for errors from anchore-engine
at com.anchore.jenkins.plugins.anchore.BuildWorker.runGatesEngine(BuildWorker.java:480)
at com.anchore.jenkins.plugins.anchore.BuildWorker.runGates(BuildWorker.java:343)
at com.anchore.jenkins.plugins.anchore.AnchoreBuilder.perform(AnchoreBuilder.java:338)
at hudson.tasks.BuildStepCompatibilityLayer.perform(BuildStepCompatibilityLayer.java:81)
at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)
at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:744)
at hudson.model.Build$BuildExecution.build(Build.java:206)
at hudson.model.Build$BuildExecution.doRun(Build.java:163)
at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:504)
at hudson.model.Run.execute(Run.java:1724)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:97)
at hudson.model.Executor.run(Executor.java:421)
I also checked status and found below:
docker run anchore/engine-cli:latest anchore-cli --u admin --p admin123 --url http://172.18.0.1:8228/v1 system status
Service analyzer (dockerhostid-anchore-engine, http://anchore-engine:8084): up
Service catalog (dockerhostid-anchore-engine, http://anchore-engine:8082): up
Service policy_engine (dockerhostid-anchore-engine, http://anchore-engine:8087): down (unavailable)
Service simplequeue (dockerhostid-anchore-engine, http://anchore-engine:8083): up
Service apiext (dockerhostid-anchore-engine, http://anchore-engine:8228): up
Service kubernetes_webhook (dockerhostid-anchore-engine, http://anchore-engine:8338): up
Engine DB Version: 0.0.7
Engine Code Version: 0.2.4
It seems service policy engine is down
Service policy_engine (dockerhostid-anchore-engine, http://anchore-engine:8087): down (unavailable)
I also checked the docker logs . I found below error:
[service:policy_engine] 2018-10-15 09:37:46+0000 [-] [bootstrap] [DEBUG] service (policy_engine) starting in: 4
[service:policy_engine] 2018-10-15 09:37:46+0000 [-] [bootstrap] [INFO] Registration complete.
[service:policy_engine] 2018-10-15 09:37:46+0000 [-] [bootstrap] [INFO] Checking feeds client credentials
[service:policy_engine] 2018-10-15 09:37:46+0000 [-] [bootstrap] [DEBUG] Initializing a feeds client
[service:policy_engine] 2018-10-15 09:37:47+0000 [-] [bootstrap] [DEBUG] init values: [None, None, None, (), None, None]
[service:policy_engine] 2018-10-15 09:37:47+0000 [-] [bootstrap] [DEBUG] using values: ['https://ancho.re/v1/service/feeds', 'https://ancho.re/oauth/token', 'https://ancho.re/v1/account/users', 'anon#ancho.re', 3, 60]
[service:policy_engine] 2018-10-15 09:37:47+0000 [-] [urllib3.connectionpool] [DEBUG] Starting new HTTPS connection (1): ancho.re
[service:policy_engine] 2018-10-15 09:37:50+0000 [-] [bootstrap] [ERROR] Preflight checks failed with error: HTTPSConnectionPool(host='ancho.re', port=443): Max retries exceeded with url: /v1/account/users/anon#ancho.re (Caused by NewConnectionError('<urllib3.connection.VerifiedHTTPSConnection object at 0x7ffa905f0b90>: Failed to establish a new connection: [Errno 113] No route to host',)). Aborting service startup
Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/anchore_manager/cli/service.py", line 158, in startup_service
raise Exception("process exited: " + str(rc))
Exception: process exited: 1
[anchore-policy-engine] [anchore_manager.cli.service/startup_service()] [INFO] service process exited at (Mon Oct 15 09:37:50 2018): process exited: 1
[anchore-policy-engine] [anchore_manager.cli.service/startup_service()] [INFO] exiting service thread
Thanks and Regards,
Rohan Shetty
When images are added to anchore-engine, they are queued for analysis which moves them through a simple state machine that starts with ‘not_analyzed’, goes to ‘analyzing’ and finally ends in either ‘analyzed’ or ‘analysis_failed’. Only when an image has reached ‘analyzed’ will a policy evaluation be possible.
The anchore Jenkins plugin will add an image, then poll the engine for image status/evaluation for the configured number of tries (default 300). Once the image goes to ‘analyzed’ (where policy evaluation is possible), the plugin will then receive a policy evaluation result from the engine.
The plugin will fail the build (by default) if the max retries has been performed and the image has not reached ‘analyzed’, if the image does reach ‘analyzed’ but the policy evaluation is producing a ‘fail’ result (meaning the image didn’t pass your configured policy checks). Note that all build failure behavior can be controlled in the plugin (I.e. there are options to allow the plugin to succeed even if the analysis or image eval fails).
You’ll need to look at the end of the output from your build run (instead of just the beginning from your post), and combined with the information above, it should be clear which scenario is causing the plugin to fail the build.
We have resolved the issue.
Root Cause:
We were not able to establish a successful https connection to URL : https://ancho.re from within the anchore-engine docker container.
As a result the service:policy_engine was not able to start.
https://ancho.re is required to download policy feeds and sync-up periodically. Without these policy anchore-engine won't be able to analyse the docker images.
Solution:
1) We passed a HTTPS_PROXY URL as an environment variable in the docker-compose.yaml of anchore-engine.
We used this proxy URL to bypass restrictions in our environment and establish a connection with https://ancho.re url.
2) Restarted the docker containers.
Finally we got all services up and running including Anchore policy-engine.
FYI:
It takes a while to download all the required Feeds depending on your internet speed.
Lastly, Thanks to the Anchore community for quick responses and support over slack.
Hope this helps.
Warm Regards,
Rohan Shetty

Chef issue with local rpm package installation on oracle linux (oel)

I'm struggling with installation of packages available in form of locally downloaded rpm file - just on Oracle Linux (OEL). Is there a bug? Has anyone observed this? It would be a huge bug, so I'm bit surprised.
Chef recipe is quite simple:
pkg_src_location = 'https://s3.amazonaws.com/solution-automation-folder/qualys'
pkg = 'qualys-cloud-agent.x86_64.rpm'
local_image = "#{Chef::Config['file_cache_path']}/#{pkg}"
remote_file 'qualys-cloud-agent-image' do
path local_image
source "#{pkg_src_location}/#{pkg}"
end
package 'qualys-cloud-agent' do
source local_image
end
It's available from https://github.com/r2oro/oel_pkg_test.git.
I have observed that on Oracle Linux (OEL) it results with following python script being triggered:
/usr/bin/python /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.16.42/lib/chef/provider/package/yum/yum-dump.py --options --installed-provides --yum-lock-timeout 30
It runs for quite a while (downloading several hundreds of megabytes of data - as far I can see - yum repo metadata) and eventually fails (kitchen in debug mode dumps all this to stdout...). Anyway the result is:
* yum_package[qualys-cloud-agent] action install[2016-12-01T12:35:32+00:00] ERROR: /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.16.42/lib/chef/provider/package/yum/yum-dump.py exceeded timeout 900
================================================================================
Error executing action `install` on resource 'yum_package[qualys-cloud-agent]'
================================================================================
Mixlib::ShellOut::CommandTimeout
--------------------------------
Command timed out after 900s:
Command exceeded allowed execution time, process terminated
---- Begin output of /usr/bin/python /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.16.42/lib/chef/provider/package/yum/yum-dump.py --options --installed-provides --yum-lock-timeout 30 ----
STDOUT:
STDERR:
---- End output of /usr/bin/python /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.16.42/lib/chef/provider/package/yum/yum-dump.py --options --installed-provides --yum-lock-timeout 30 ----
Ran /usr/bin/python /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.16.42/lib/chef/provider/package/yum/yum-dump.py --options --installed-provides --yum-lock-timeout 30 returned
Resource Declaration:
---------------------
# In /tmp/kitchen/cache/cookbooks/oel_pkg_test/recipes/default.rb
16: package 'qualys-cloud-agent' do
17: source local_image
18: end
Compiled Resource:
------------------
# Declared in /tmp/kitchen/cache/cookbooks/oel_pkg_test/recipes/default.rb:16:in `from_file'
yum_package("qualys-cloud-agent") do
package_name "qualys-cloud-agent"
action [:install]
retries 0
retry_delay 2
default_guard_interpreter :default
declared_type :package
cookbook_name "oel_pkg_test"
recipe_name "default"
source "/tmp/kitchen/cache/qualys-cloud-agent.x86_64.rpm"
flush_cache {:before=>false, :after=>false}
end
Did you note that yum flush_cache should not happen, but it still does? It's frustrating. This always fails so in my local kitchen (with vagrant/virtualbox) or even in AWS cloud kitchen... Real instances sometimes fail sometimes converge... But it's a lottery. Anyway why this cache update happens at all for single local rpm image!?
I did try to use rpm_package but this leads to problems with yum_package beings used in other recipes...
Any thoughts?
You probably do want to use rpm_package in this case, but as for why the cache is reloading, it might just be the first time it is getting hit and so has to do the initial reload, or it's after something else modified the package set.

puppet: Not authorized to call find

I'm running puppet 2.7.26 because that's what the redhat package provides.
I'm trying to serve files that are NOT stored within any puppet modules. The files are maintained in another location on the puppet server, and that is where I need to serve them from.
I have this in my /etc/puppet/fileserver.conf
[files]
path /var/www/cobbler/pub
allow *
And then I have a class file like this:
class etchostfile
(
$hostfile /* declare that this class has one parameter */
)
{
File
{
owner => 'root',
group => 'root',
mode => '0644',
}
file { $hostfile :
ensure => file,
source => "puppet:///files/hosts-${hostfile}.txt",
path => '/root/hosts',
}
}
But when my node calls
class { 'etchostfile' :
hostfile => foo,
}
I get this error
err: /Stage[main]/Etchostfile/File[foo]: Could not evaluate: Error 400
on SERVER: Not authorized to call find on
/file_metadata/files/hosts-foo.txt with {:links=>"manage"} Could not
retrieve file metadata for puppet:///files/hosts-foo.txt: Error 400 on
SERVER: Not authorized to call find on
/file_metadata/files/hosts-foo.txt with {:links=>"manage"} at
/etc/puppet/modules/etchostfile/manifests/init.pp:27
This post
https://viewsby.wordpress.com/2013/04/05/puppet-error-400-on-server-not-authorized-to-call-find/
indicates that this is all I need to do. But I must be missing something.
UPDATE
When I run the master in debug mode, I get no error.
The master responds thusly:
info: access[^/catalog/([^/]+)$]: allowing 'method' find
info: access[^/catalog/([^/]+)$]: allowing $1 access
info: access[^/node/([^/]+)$]: allowing 'method' find
info: access[^/node/([^/]+)$]: allowing $1 access
info: access[/certificate_revocation_list/ca]: allowing 'method' find
info: access[/certificate_revocation_list/ca]: allowing * access
info: access[^/report/([^/]+)$]: allowing 'method' save
info: access[^/report/([^/]+)$]: allowing $1 access
info: access[/file]: allowing * access
info: access[/certificate/ca]: adding authentication any
info: access[/certificate/ca]: allowing 'method' find
info: access[/certificate/ca]: allowing * access
info: access[/certificate/]: adding authentication any
info: access[/certificate/]: allowing 'method' find
info: access[/certificate/]: allowing * access
info: access[/certificate_request]: adding authentication any
info: access[/certificate_request]: allowing 'method' find
info: access[/certificate_request]: allowing 'method' save
info: access[/certificate_request]: allowing * access
info: access[/]: adding authentication any
info: Inserting default '/status' (auth true) ACL because none were found in '/etc/puppet/auth.conf'
info: Expiring the node cache of agent.redacted.com
info: Not using expired node for agent.redacted.com from cache; expired at Thu Aug 13 14:18:48 +0000 2015
info: Caching node for agent.redacted.com
debug: importing '/etc/puppet/modules/etchostfile/manifests/init.pp' in environment production
debug: Automatically imported etchostfile from etchostfile into production
debug: File[foo]: Adding default for selrange
debug: File[foo]: Adding default for group
debug: File[foo]: Adding default for seluser
debug: File[foo]: Adding default for selrole
debug: File[foo]: Adding default for owner
debug: File[foo]: Adding default for mode
debug: File[foo]: Adding default for seltype
notice: Compiled catalog for agent.redacted.com in environment production in 0.11 seconds
info: mount[files]: allowing * access
debug: Received report to process from agent.redacted.com
debug: Processing report from agent.redacted.com with processor Puppet::Reports::Store
and the agent responds thusly:
info: Caching catalog for agent.redacted.com
info: Applying configuration version '1439475588'
notice: /Stage[main]/Etchostfile/File[foo]/ensure: defined content as '{md5}75125a96a68a0ff0d42f91f10dca8336'
notice: Finished catalog run in 0.42 seconds
and the file is properly installed/updated.
So it works when the master is in debug mode, but it errors when the master is in standard (?) mode. I can go back and forth, in and out of debug mode at will, and it works every time in debug mode, and it fails every time in standard mode.
UPDATE 2
Running puppetmasterd from the command line, and everything works.
Running service puppetmaster start or /etc/init.d/puppetmaster start from the command line, and it fails. So at least I'm getting closer.
/etc/sysconfig/puppetmaster is entirely commented out. So as of now, I do not see any difference between just starting puppetmasterd and using the service script.
UPDATE 3
I think it's an SELinux problem.
With SELinux "enforcing" on the master, service puppetmaster restart, and I get the error.
I change SELinux to "Permissive" on the master, and I still get the error.
But now that SELinux is set to Permissive, if I service puppetmaster restart, my files get served properly.
But now that it's working, I set SELinux to Enforcing, and I get a different error:
err: /Stage[main]/Etchostfile/File[foo]: Could not evaluate: Could not
retrieve information from environment production source(s)
puppet:///files/hosts-foo.txt at
/etc/puppet/modules/etchostfile/manifests/init.pp:27
Then I do a service puppetmaster restart and I'm back to the original error.
So the situation changes depending on
how I started the service (puppetmasterd or service)
what SELinux was set to when I started the service
what SELinux is set to when the agent runs.
The closer I get, the more confused I get.
UPDATE 4
I think I found it. Once I started looking at SELinux, I found the policy changes I needed to make (allowing ruby/puppet to access cobbler files) and now it appears to be working...
This turned out to be an SELinux problem. I eventually found this error message
SELinux is preventing /usr/bin/ruby from read access
on the file /var/www/cobbler/pub/hosts-foo.txt .
which led me to the audit2allow rules I needed to apply to allow puppet to access my cobbler files.
I was getting this error with puppet server on ubuntu 20.
Error: /Stage[main]/Dvod_tocr/File[/install/wine-data.tar.gz]: Could not evaluate: Could not retrieve file metadata for puppet:///extra_files/wine-data.tar.gz: Error 500 on SERVER: Server Error: Not authorized to call find on /file_metadata/extra_files/wine-data.tar.gz with {:rest=>"extra_files/wine-data.tar.gz", :links=>"manage", :checksum_type=>"sha256", :source_permissions=>"ignore"}
My fileserver.conf file was in the wrong location. The correct location for this puppet version and on ubuntu 20 is /etc/puppetlabs/puppet/fileserver.conf

Resources