I tried to create a directory in chef using this simple block of code
...
directory "/opt/myfolder" do
owner "abc"
group "abc"
mode "0755"
action :create
end
...
When i execute this using "chef-client" it works. But when i execute this in chef-shell (running in client mode), I get this error
================================================================================
Error executing action `create` on resource 'directory[/opt/myfolder/]'
================================================================================
Chef::Exceptions::InsufficientPermissions
-----------------------------------------
Cannot create directory[/opt/myfolder/] at /opt/myfolder/ due to insufficient permissions
I am using chef-shell to debug my recipes
In chef-shell I am using node.run_chef to run start a client run
Are you running chef-shell with sudo or as root? If not, you need to.
It would be interesting to know the output of `whoami` when run in chef-shell. That would tell you what user it thinks it is running as. You could add that to the recipe and see what the output is when running as chef-client. I'd guess that chef-client is running as root.
Related
I'm trying to execute some chef commands on a Windows server using Jenkins.
When I run the build on Jenkins to execute the chef commands, I get the error below:
ERROR: Failed to authenticate to 172.54.78.989 as demo-user
Response: WinRM::WinRMAuthorizationError
Hint: Make sure to prefix domain usernames with the correct domain name.
Hint: Local user names should be prefixed with computer name or IP address.
EXAMPLE: my_domain\user_namer
ERROR: WinRM::WinRMAuthorizationError: WinRM::WinRMAuthorizationError
Build step 'Execute Windows batch command' marked build as failure
Finished: FAILURE
Trying to figure out how to fix this
I was able to fix the issue
It was caused by my user (demo-user) not belonging to domain name that allowed to connect from Chef to the Windows Server.
All I had to do was to get a user that was part of my organization domain name, replace demo-user with that user in my chef commands, and then run the Jenkins build again.
This time it worked fine.
I am writing a chef recipe to install Oracle EE software (by running setup.exe in silent mode) using chef resource 'execute' as below.
str_command = "<dir>/setup.exe -silent -nowait -noconfig -waitforcompletion ORACLE_HOME=... ORACLE_BASE=... " # other parameters for silent installation
Chef::Log.info("-before-")
execute 'install_oracle_ee' do
command str_command
live_stream true
timeout "#{node['mycookbk']['timeout']['num']}"
not_if {File.exists?("#{node['mycookbk']['oracle']['oracle_home']}/bin")}
end
Chef::Log.info("-after-")
After the software is installed successfully I need to execute resources / recipe which will 'create a db instance' and then 'create the database'.
At the moment the execute resource exists after running the command and directly moves to the next resource / recipe in the run list.
But I need to make sure the set up is completed before doing that. Can anyone please suggest a way to do this?
That means the command is not actually waiting for completion. Chef does wait for the provided executable to finish (in fact it has to, there is no option to not do that). Double check your CLI options for the installer?
I am trying to automate packer commands on gitlab-ci , so basically i am running a docker container ubuntu:latest and trying to build an image using packer. How can i specify the user as root? or how should i solve this error
please help!
when i try to execute this command
packer_log=1 packer build image.json
i am getting the below error:
amazon-ebs output will be in this color.
1 error(s) occurred:
* user: could not determine current user from environment.
ERROR: Job failed: exit code 1
For some reason you don't have the USER environment variable set. You either need to set it correctly or use the user configuration option in the ansible provisioner, see ansible: user in the documentation.
I'm getting permissions errors with the create action on windows servers.
Initially I was doing this in one recipe:
directory "C:/topdir" do
rights :full_control, 'Users'
action :create
end
directory "C:/topdir/subdir" do
action :create
recursive true
end
If I run this in test kitchen or even login to a bootstrapped server and run chef-client it completes with no errors.
But I see these errors on Chef server when it runs automatically:
Description: Error executing action `create` on resource 'directory[C:/topdir/subdir]'
Chef::Exceptions::InsufficientPermissions
Cannot create directory[C:/topdir/subdir] at C:/topdir/subdir due to insufficient permissions
It seems I "fixed" this by replacing rights :fullcontrol, 'Users' with rights :fullcontrol, 'Everyone' but I don't want that and it doesn't make sense to me why that would be necessary.
Why is this happening?
Also, how can I test this if the errors only happen during automated chef runs- I can only see errors in chef server reporting. How can I see what user this is even running in? I assumed local system but I guess not? It works running chef-client locally from an elevated prompt so why would it not work when running on schedule?
My knowledge of Windows is limited, but in general I think services get run as a dedicated SYSTEM user, which is not part of the Users group.
So, struggling with a fairly major problem, i've tried multiple different workarounds to try and get this working but there is something happening between puppet and the actual server that is just boggling my mind.
Basically, I have an init.d script /etc/init.d/rserve which is copied over correctly and when used from the command-line on the server works perfectly (i.e. sudo service rserve start|stop|status), the service returns correct error codes based on testing using echo $? on the different commands.
The puppet service statement is as follows:
service { 'rserve':
ensure => running,
enable => true,
require => [File["/etc/init.d/rserve"], Package['r-base'], Exec['install-r-packages']]
}
When puppet hits this service, it runs it's status method, sees that it isn't running and sets it to running and presumably starts the service, the output from puppet is below:
==> twine: debug: /Schedule[weekly]: Skipping device resources because running on a host
==> twine: debug: /Schedule[puppet]: Skipping device resources because running on a host
==> twine: debug: Service[rserve](provider=upstart): Could not find rserve.conf in /etc/init
==> twine: debug: Service[rserve](provider=upstart): Could not find rserve.conf in /etc/init.d
==> twine: debug: Service[rserve](provider=upstart): Could not find rserve in /etc/init
==> twine: debug: Service[rserve](provider=upstart): Executing '/etc/init.d/rserve status'
==> twine: debug: Service[rserve](provider=upstart): Executing '/etc/init.d/rserve start'
==> twine: notice: /Stage[main]/Etl/Service[rserve]/ensure: ensure changed 'stopped' to 'running'
Now when I actually check for the service using sudo service rserve status or ps aux | grep Rserve the service is in fact NOT running and a quick sudo service rserve start shows the init.d script is working fine and starting rserve as the service starts and is visible with ps aux.
Is there something I'm missing here? I've even tried starting the service by creating a puppet Exec { "sudo service rserve start"} which still reports that it executed successfully but the service is still not running on the server.
tl;dr puppet says a service started when it hasn't and there's seemingly nothing wrong with the init.d script, its exit codes or otherwise.
Update 1
In the comments below you can see I tried isolating the service in it's own test.pp file and running it using puppet apply on the server with the same result.
Update 2
I've now tried creating an .sh file with the command to start Rserve using a separate vagrant provision and can finally see an error. However, the error is confusing as the error does not occur when simply running sudo service rserve start, something in the way that vagrant executes .sh commands, or the user it executes them under is causing an option to be removed from the command inside the init.d script when it's executed.
This error is R and Rserve specific but it is complaining about a missing flag --no-save needing to be passed to R when it is in fact present in the init.d script and being correctly passed when ssh'd into the vagrant box and using the init.d commands.
Update 3
I've managed to get the whole process working at this point, however, it's one of those situations where the steps to get it to work didn't really readily reveal any understanding of why the original problem existed. I'm going to replicate the broken version and see if I can figure out what exactly was going on using one of the methods mentioned in the comments so that I can potentially post an answer up that will help someone out later on. If anyone has insight into why this might have been happening feel free to answer in the meantime however. To clarify the situation a bit, here are some details:
The service's dependencies were installed correctly using puppet
The service used a script in /etc/init.d on ubuntu to start|stop the Rserve service
The software in question is R (r-base) and Rserve (a communication layer between other langs and R)
Running the command sudo service rserve start from the command-line worked as expected
The init.d script returned correct error codes
A service {} block was being used to start the service from puppet
Puppet reported starting the service when the service wasn't started
Adding a provision option to the Vagrantfile for an .sh file containing sudo service rserve start revealed that some arguments in the init.d were being ignored when run by vagrants provisioning but not by a user active on the shell.