I wonder is there a way to set user in vagrant configuration, so that box will be provisioned from non-root account? The thing is that I want to run chef-client on boxes as specific user (deployer), and not root, but for that I should run provisioner and create this user first, and this provisioner is created under root user.
As I understand, the one solution is to run provisioning for create deployer user, and then change all chef-related files and directories on box to be owned by deployer user, and then run the actual provisioning from chef server.
Is there some better solution?
Forgive me if I'm just restating the second half of your question but it seems like you may want to create a minimal starting provisioner (runs as root) then spawn another provisioner as your intended user.
Here is an example of how I install my dotfiles as my ssh user (vagrant)
# ... in shell provision script...
su -c "cd /home/vagrant/.dotfiles && bash install.bash" vagrant
Similar Vagrant github issue
Related
I'm trying to create a user for ceph dashboard with admin role. Version is Nautilus 14.2.19 and deployed with manuel installation.
I've installed dashboard module, installed all dependencies and enabled it. My dashboard is reachable from the monitor ip and default port of 8443.
When I run te command:
ceph dashboard ac-user-create <user> <pw> administrator
I get the following error:
Please specify the file containing the password/secret with "-i" option.
After digging for information about this it says there must be a file in bcrypt format. Is there a default created file for this? Or if it's needed to create one how can I do it?
Nevermind, it seems you just need to create a text file and write your password in it.
When you run the command like this:
ceph dashboard ac-user-create <user> -i /file/location administrator
It creates the user and applies the password in an encrypted format.
I was not able to build my dockerfile via jenkins until I added 666 permissions to /var/run/docker.sock. Now, I understand that this is more secure than adding the 'jenkins' user to 'sudoers' list. HOWEVER,
Is there still a better way ?
What are the ways in which this extra permission could be used to my disadvantage ?
What are the ways in which this extra permission could be used to my disadvantage ?
You have given permission for any user on the machine to become root without any password.
Is there still a better way ?
For Jenkins, you just need to run the following to give them access to the docker group so they can run docker commands. This will give the Jenkins user access to become root, so you'll want to be sure your Jenkins is secure or you do not care about users becoming root on this system:
sudo usermod -aG docker jenkins
I have a chef cookbook for deploying our webapp, there are some folders and files that need to be created and owned by www-data:www-data. When deploying the application I'm doing it by using the chef's deploy command like this in my deploy.rb recipe:
deploy "#{app_dir}" do
repository tmp_dir
user "root"
group "root"
environment app[:environment]
symlink_before_migrate({})
end
And then the creation and permission set for those files and folders are done in the before_symlink.rb script like this:
execute "ensure correct owner of storage folder" do
command "chown -R www-data:www-data #{release_path}/storage"
end
I've been debugging and I've checked this:
chown is executed, and the user exists, I can see it in the chef logs.
If I execute a sleep command right at the end of the before_symlink and then ssh into the machine I can see in the storage folder that the folder is owned by www-data as I wish.
If I execute a sleep command right after the deploy command on deploy.rb and then ssh to the machine, now the release folder will be linked to the current folder, and every file and folder will be owned by root:root causing permission errors.
So it seems that at the end of the deploy chef seems to overwrite the owner for every deployed file to the user making the deploy. Is this true? Is there any way to keep files and folders with the owner set on before_symlink.rb?
Really really don't use the deploy resource. What you want is probably a git resource, and its user property.
I decided to create my own chef script to install Postgres. The installation works perfectly fine, but postgres doesn't start on boot when I vagrant reload
Here's my recipes/default.rb:
include_recipe "apt"
apt_repository 'apt.postgresql.org' do
uri 'http://apt.postgresql.org/pub/repos/apt'
distribution node["lsb"]["codename"] + '-pgdg'
components ['main', node["postgres"]["version"]]
key 'http://apt.postgresql.org/pub/repos/apt/ACCC4CF8.asc'
action :add
end
package 'postgresql-' + node["postgres"]["version"] do
action :install
end
file "/etc/postgresql/#{node['postgres']['version']}/main/postgresql.conf" do
action :delete
end
link "/etc/postgresql/#{node['postgres']['version']}/main/postgresql.conf" do
to node["postgres"]["conf_path"]
action :create
notifies :reload, "service[postgresql]", :delayed
end
service "postgresql" do
action [:enable, :start]
supports :status=>true, :restart=>true, :start => true, :stop => true, :reload=>true
end
And here's my attributes/default.rb:
default["postgres"]["version"] = "9.3"
default["postgres"]["conf_path"] = "/home/vagrant/postgres/postgresql.conf"
Any help would be greatly appreciated!!
============ EDIT 1 ============
Here is the output when running vagrant up for the first time with chef.log_level = :debug: http://pastebin.com/w8Lp8gzv
Here is /etc/init.d/postgresql: http://pastebin.com/dQ5Zb1yj
Here is /var/log/postgresql/postgresql-9.3-main.log: http://pastebin.com/0Y2RhWvL
============ EDIT 2 ============
I'm now fairly confident that it's my postgresql.conf file, which looks like: http://pastebin.com/rjX89iU0
shared_buffers might be too high...
When you run vagrant reload, is the Chef Client running? I suspect not. Mitchell changed the behavior in a recent version of vagrant to only provision if the machine hasn't already been provisioned. This information is stored in the .vagrant directory in your working directory. In short, since you already provisioned your machine with vagrant up, it is not provisioned when you run vagrant reload.
You run vagrant up - this is actually going to run vagrant up --provision, which executes the Chef Client provisioner on the node, executing your Chef Recipe.
You run vagrant reload - this actually runs vagrant up --no-provision, because the .vagrant. directory indicates the machine has already been provisioned. So your machine is rebooted, but the Chef Client provisioner is not executed.
Solution
Run vagrant reload with the --provision flag
vagrant reload --provision
Notes
This still doesn't explain why upstart (or whatever you're using to ensure the postgres service is running at boot) isn't starting the server for your automatically. In order to answer that question, I'll need to see more information. Can you set the chef.log_level = :debug in your Vagrantfile and update your question with the output? It would also be helpful to see the init.d script this postgres installer creates, and any log output from /var/log related to postgres.
Alright, it looks like Postgresql doesn't play nice with postgresql.conf being a symbolic link. Copying the file instead did the trick.
Turns out the postgresql was starting before the postgersql.conf file was mounted
If you're starting services with Upstart that depend on something in Vagrant's shared folders, have your upstart conf file listen for the vagrant-mounted event.
# /etc/init/start-postgresql.conf
start on vagrant-mounted
script
# commands to start postgresql...
end script
The vagrant-mounted event is emitted after Vagrant is done setting up shared folders, this way you can restart dependent services after vagrant reload without having to run your provisioners again.
I'm trying to setup Capistrano to do our deployments, but I now stumbled upon what seems to be a common assumption of capistrano users: that the user you SSH to the remote host will have permission to write to the directory of deployment.
Here, administrators are common users with a single distinction: they can sudo. At first, I thought that would be enough, since there are some configurations related to sudo, but it seems that's not the case after all.
Is there a way around this? Creating a user shared by everyone doing deployment is not an acceptable solution.
Edit: to make it clear, no deploy action should happen without calling sudo -- that's the gateway point that checks whether the user is allowed to deploy or not, and it should be a mandatory checkpoint.
The presently accepted answer does not fit that criteria. It goes around sudo by granting extra permissions to the user. I'm accepting it anyway because I've come to the conclusion that Capistrano is fundamentally broken in this regard.
I assume you are deploying to a Linux distro. The easiest way to resolve your issue is to create a group, say, deployers, and add each user who should have the permissions to deploy to that group. Once the group is created and the users are in the group, change the ownership and permissions on the deployment path.
Depending on the distro, the syntax will vary slightly. Here it is for ubuntu/debian:
Create the group:
$ sudo groupadd deployers
Add users to group:
$ sudo usermod -a -G deployers daniel
The last argument there is the username.
Next, update the ownership of the deployment path:
$ sudo chown -R root:deployers /deploy/to/path/
The syntax for is :. Here I am assuming that the user that currently owns the path is root. Update to which ever user should own the directory.
Finally, change the permissions on the deployment path:
$ sudo chmod -R 0766 /deploy/to/path/
That will allow users in the deployers group to read and write all files and directories beneath /deploy/to/path