Recently I started taking an interest in Salt and begun doing a tutorial on it.I am currently working on a Mac and I having a hard time trying to start the vm[the minion] from my laptop[I am using Vagrant as an application to start the process]
The vagrant file for the vm contains these lines:
# salt-vagrant config
config.vm.provision :salt do |salt|
salt.run_highstate = true
salt.minion_config = "/etc/salt/minion"
salt.minion_key = "./minion1.pem"
salt.minion_pub = "./minion1.pub"
end
even though I wrote this it gets stuck at:
Calling state.highstate... (this may take a while)
Any ideas why?
One more thing.I seem to need to modify the top.sls file at the next step which is located in /srv/salt.Unfortunately I can not find the /srv file anywhere,why is that?is there a way to tell the master that the top file is somewhere else?
If you don't have a top.sls created, then you won't be able to run a hightstate like you have configured with the salt.run_highstate = true line.
If you don't have a /srv/salt/ directory created, then you can just create it yourself. Just make sure the user the salt-master is running as can read it.
The /srv/salt/ directory is the default location of what is known as the file_root. You can modify its location in the master config file /etc/salt/master and modify the file_roots config option.
Related
I'm trying to get GrumPHP to work with a small Laravel 9 project but php-cs-fixer is being pulled from the wrong location and I can't seem to find how to change this.
Error from GrumPHP:
phpcsfixer
==========
PHP needs to be a minimum version of PHP 7.1.0 and maximum version of PHP 7.4.*.
You can fix errors by running the following command:
'/windir/f/wamp64/vendor/bin//php-cs-fixer' '--config=./home/testuser/php-cs-config.php_cs' '--verbose' 'fix'
Seems like an easy fix, so I updated php-cs-fixer and followed the upgrade guide to get to v3. (currently sitting on 3.10). But I can also see that '/windir/f/wamp64/vendor/bin//php-cs-fixer' is not the correct directory for php-cs-fixer, the actual bin folder is located in WSL not the windows directory so I included a GRUMPHP_BIN_DIR in the grumphp yaml but still no luck.
grumphp.yml
grumphp:
environment:
variables:
GRUMPHP_PROJECT_DIR: "."
GRUMPHP_BIN_DIR: "./home/testuser/tools/vendor/bin/"
paths:
- './home/plustime/tools'
tasks:
phpcsfixer:
config: "./home/testuser/php-cs-config.php_cs"
allow_risky: ~
cache_file: ~
rules: []
using_cache: ~
config_contains_finder: true
verbose: true
diff: false
triggered_by: ['php']
I can't seem to find much about this or anything in the docs, so any help would be appreciated.
This ended up coming down to altering how WSL constructs the environment. To get around WSL building windows paths into the Linux distribution.
The answer was found here:
How to remove the Win10's PATH from WSL
Quick run down:
On the WSL instance open the file /etc/wsl.conf with something like
sudo nano /etc/wsl.conf
Add the following lines to the bottom of the file,
[interop]
appendWindowsPath = false
Mine looked like this when it was finished:
# Enable extra metadata options by default
[automount]
enabled = true
root = /windir/
options = "metadata,umask=22,fmask=11"
mountFsTab = false
# Enable DNS – even though these are turned on by default, we'll specify here just to be explicit.
[network]
generateHosts = true
generateResolvConf = true
[interop]
appendWindowsPath = false
Then restart the WSL instance from your windows terminal and restart it.
wsl --shutdown
GrumPHP now using the correct php-cs-fixer.
I'm running an Nginx server on a Vagrant Homestead box and I would like to add this piece of code to the server part of the Nginx config file for my site (in '/etc/ngnix/sites-available'):
location /storage/ {
add_header "Access-Control-Allow-Origin" "*";
}
I can type it in manually, but then it's gone every time I run vagrant provision.
What would be the best way to add this code during or after the provisioning?
Update 1
I found this article: https://medium.com/#maxxscho/laravel-homestead-with-custom-nginx-configurations-2e0fda4ba7dc
which brings me a step closer but now I have to figure out a way to place the custom serve-###.sh file outside the vendor folder. If anyone has thoughts on this, they are welcome as well!
Update 2
After fiddling some more I came up with a fairly decent solution:
Copy the vendor/laravel/homestead/scripts/serve-laravel.sh to a folder outside the vendor folder (e.g. ./scripts).
Edit the file to your needs.
Place some additional code in the Vagrant file to copy the script to the vendor folder before provisioning.
Add this to the Vegrantfile:
....
Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
config.trigger.before :provision do |trigger|
trigger.info = "Copy custom scripts to vendor folder"
trigger.run = {
inline: "cp -r /scripts/* vendor/laravel/homestead/scripts/"
}
end
....
Any other solutions are still welcome!
I have a projekt with a setup for a multi machine environment for Vagrant. I had to fix some problems, which were initially caused by the redirect issue to https, but solving these lead into other errors, which I fixed in all projects except this one now, which uses the multi machine feature of Vagrant.
So I have this folder structure:
/Vagrantfile
/puppet/box_1/puppetfile
/puppet/box_1/manifests/site.pp
This is my code snippet, where I define my provision directories:
config.vm.provision :puppet do |puppet|
puppet.manifests_path = "puppet/box_1/manifests"
puppet.manifest_file = "site.pp"
end
My puppetfile looks like this:
forge "https://forgeapi.puppetlabs.com"
mod 'tPl0ch/composer'
mod 'puppetlabs/apt'
mod 'puppetlabs/apache'
mod 'puppetlabs/firewall'
In my site.pp I try to include apt, but I get this error message:
Error: Evaluation Error: Error while evaluating a Function Call, Could not find class ::apt for project.local at /tmp/vagrant-puppet/manifests-f2b1fd0ac42b51938ed6ae7e6917367e/site.pp:1:1 on node project.local
When I rearange my puppet files like this:
/Vagrantfile
/puppet/puppetfile
/puppet/manifests/site.pp
like this is the common way of setting this up, it works without that problem, but as I mentioned, there are other boxes, which use different puppetfiles and site.pp files, so this folder structure makes some kinda sense. It seems, that it doesn'even matter, if I delete the config for the other boxes, and setup my Vagrantfile, as if it would be only one box, so I am just confused, how the location, of these files influence the scope of certain classes.
So my questions is here: Is there a way, to keep this folder structure and still have these modules defined in puppetfile available in my site.pp? Or is this generally some kinda bad practice to organize it this way? I was searching for some examples for this, but couldn't find any for some reason...
EDIT: It seems, on provision the puppetfile isnt even used anymore, when its not located in /puppet/ So maybe I just have to tell Vagrant how to use it?
define where librarian should find the puppet file
Vagrant.configure("2") do |config|
config.librarian_puppet.puppetfile_dir = "puppet/box1"
config.vm.provision :puppet do |puppet|
puppet.manifests_path = "puppet/box_1/manifests"
puppet.manifest_file = "site.pp"
end
I need to see the GUI when I do "vagrant up --provision" because I believe the box was shutdown improperly and now simply time-outs when I try to start it. I see from the [documentation] that I can add a block to my Vagrantfile to enable me to debug the startup process. This post says if the system was shutdown improperly it will ask me if I want to boot up in safe mode (only visible from the GUI). So I am trying to modify the Vagrantfile and have tried two ways (I'm not very familiar with Ruby or modifying config files). When I try this:
VAGRANTFILE_API_VERSION = "2"
path = "#{File.dirname(__FILE__)}"
require 'yaml'
require path + '/scripts/homestead.rb'
Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
Homestead.configure(config, YAML::load(File.read(path + '/Homestead.yaml')))
config.vm.provider "virtualbox" do |v|
vb.gui = true
end
end
I get the following error message:
Path: <provider config: virtualbox>
Message: undefined local variable or method `vb' for main:Object
Could anyone please tell me what I am doing wrong? How do I modify the file properly so that I can get the vagrant box up and running again. I am trying to use Homestead for Laravel, by the way. Thank you very much!
I have inherited a python app that uses Puppet, Vagrant and VirtualBox to provision a local Centos test machine.
This app was written on Mac and I'm developing on Windows.
When I run vagrant up I see a large list of command line errors, the most relevant of which is:
Running Puppet with site.pp..
Warning: Config file /home/vagrant/hiera.yaml not found, using Hiera defaults
WARN: Fri Apr 25 16:32:24 +0100 2014: Not using Hiera::Puppet_logger. It does not report itself to b
e suitable.
I know what Hiera is, and why it's important, but I'm not sure how to fix this.
The file hiera.yaml is present in the repo but it's not found at home/vagrant/hiera.yaml, instead it's found at ./puppet/manifests/hiera.yaml.... Similarly if I ssh into the box, there is absolutely nothing whatsoever inside home/vagrant but I can find this file when I look in /tmp
So I'm confused, is vagrant looking inside the Virtual box and expecting this file to be found at home/vagrant/hiera.yaml? Or have I inherited an app that did not work properly in the first place? I'm really stuck here and I can't get in touch with the original dev.
Here are some details from my Vagrantfile:
Vagrant.configure("2") do |config|
# Base box configuration ommitted
# Forwarded ports ommitted
# Statically set hostname and internal network to match puppet env ommitted
# Enable provisioning with Puppet standalone
config.vm.provision :puppet do |puppet|
# Tell Puppet where to find the hiera config
puppet.options = "--hiera_config hiera.yaml --manifestdir /tmp/vagrant-puppet/manifests"
# Boilerplate Vagrant/Puppet configuration
puppet.module_path = "puppet/modules"
puppet.manifests_path = "puppet/manifests"
puppet.manifest_file = "site.pp"
# Custom facts provided to Puppet
puppet.facter = {
# Tells Puppet that we're running in Vagrant
"is_vagrant" => true,
}
end
# Make the client accessible
config.vm.synced_folder "marflar_client/", "/opt/marflar_client"
end
It's really strange.
There's this puppet.options line that tells Puppet where to look for hiera.yaml and currently it simply specifies the file name. Now, when you run vagrant up, it mounts the current directory (the one that has the Vagrantfile in it) into /vagrant on the guest machine. Since you're saying hiera.yaml is actually found in ./puppet/manifests/hiera.yaml, I believe you want to change the puppet.options line as follows:
puppet.options = "--hiera_config /vagrant/puppet/manifests/hiera.yaml --manifestdir /tmp/vagrant-puppet/manifests"
To solve this warning, you may first try to check from where this file is referenced, i.e.:
$ grep -Rn hiera.yaml /etc/puppet
/etc/puppet/modules/stdlib/spec/spec_helper_acceptance.rb:13: on hosts, '/bin/touch /etc/puppet/hiera.yaml'
/etc/puppet/modules/mysql/spec/spec_helper_acceptance.rb:34: shell("/bin/touch #{default['puppetpath']}/hiera.yaml")
In this case it's your vagrant file.
You may also try to find the right path to it via:
sudo updatedb && locate hiera.yaml
And either follow the #EvgenyChernyavskiy suggestion, create a symbolic link if you found the file:
sudo ln -vs /etc/hiera.yaml /etc/puppet/hiera.yaml
or create the empty file (touch /etc/puppet/hiera.yaml).
In your case you should use the absolute path to your hiera.yaml file, instead of relative.
The warning should be gone.