I am trying to source files from local modules in a puppet manifest (using puppet in standalone mode):
file {
'/home/repowt/.crontab':
ensure => present,
source => 'puppet:///modules/site/crontab';
}
but I get:
Could not evaluate: Could not retrieve information from source(s) ...
The file is in:
config/puppet/modules/site/files/crontab
(puppet is called via vagrant provision and the Vagrantfile specifies module_path='config/puppet/modules' and is clearly ok since puppet does load modules with import from there.)
I also tried:
source => 'puppet:///site/crontab'
source => 'site/crontab'
source => 'config/puppet/modules/site/files/crontab'
source => '/modules/site/crontab'
of no avail. I found nothing illuminating on the web, seems like something very simple.
your help is appreciated.
There are a couple of things going on here.
First, as pwan notes, the fileserver.conf needs to be setup correctly.
Keeping in mind that /vagrant contains the directory where Vagrantfile is (and therefore all of it content), that meant for me doing:
vm_config.vm.provision :puppet, :module_path => "modules", :options => ["--fileserverconfig=/vagrant/fileserver.conf", ]
My fileserver.conf specifies that /etc/puppet/files is to be used.
Whilst I could have specified a different fileserver.conf, just for Vagrant, I wanted pretty much everything to be the same as normal.
So, I also mounted /etc/puppet/files too, with
vm_config.vm.share_folder "files", "/etc/puppet/files", "files"
Which got things working for me.
puppet:///modules/my_module/file should match %vagrant_root%/modules/my_module/files/file
I noticed that Vagrant mounted a copy of its dir on the target VM (I'm using base http://dl.dropbox.com/u/15307300/vagrant-0.7-centos-64-base.box); do a "mount" and see if you have this too.
This allows me to create a directory within my Vagrant, parallel to manifests/ that I call "files/". I then put my config source file under there, e.g., .../myvagrantproject/files/slapd.conf. This appears on the VM as /vagrant/files/slapd.conf
Then in the puppet manifest for the file source I list the source as an absolute file path, not a puppet server path, like:
file { 'slapd.conf':
name => '/etc/openldap/slapd.conf',
ensure => present,
source => '/vagrant/files/slapd.conf',
owner => root,
group => ldap,
mode => 0640,
require => Package["ldapservers"],
}
It found it no problemmo from it's own vbox-mounted remote filesystem.
Your original puppet://modules/site/crontab should work.
I suspect the fileserver.conf on your puppetmaster may not have a modules section. Try adding something like below if it's not already present.
[modules]
allow *
Check out the 'Module Lookup' section at http://docs.puppetlabs.com/guides/modules.html
It is not clear from your description if you are using the puppet in standalone mode or in client-server mode.
Assuming that you are using the standalone mode, double check in your /tmp folder in your vm to see if the module folder is actually there and vagrant has mounted it.
The fact that you can load the manifest, doesn't mean that the modules are there as well.
Your original configuration, looks correct.
Related
When I start my development rails server I get this following message first. To my knowledge WSL2 is a virtual environment.
I would have expected it to now reference a Java directory that resides on my Windows host. Is this likely something I carried over in the project from when I was using WSL1? How would I safely correct this?
/home/daveomcd/.rbenv/versions/2.6.1/lib/ruby/gems/2.6.0/gems/railties-6.0.3.2/lib/rails/app_loader.rb:53:
warning: Insecure world writable dir /mnt/c/Program Files (x86)/Common Files/Oracle/Java/javapath
in PATH, mode 040777
I experienced the same problem when trying to fix the slowness of WSL2. The recommended solution was to move the files from the mounted NTFS drive to the root ext4 filesystem (using \\$wsl\<distroname>), so I did that.
I set up /etc/wsl.conf as below:
# Enable extra metadata options by default
[automount]
enabled = true
root = /mnt/
options = "metadata,umask=0033"
mountFsTab = false
[interop]
enabled = true
appendWindowsPath = true
And ran rails bundle to update dependencies.
Also make sure that your file permissions and owner settings are updated. Hope it helps.
Sorry, I'd love to make this more of a comment to see if I'm on the right track before committing to an answer. However, since there's too much info here for that, I'll make an attempt at getting you an answer here.
While it is a virtual environment, by default WSL provides several "Windows Interop" features that allow it to:
automatically mount Windows drives in /mnt/{c,d,...}
append the Windows path to the Linux path
run Windows executables inside Linux
share Windows environment variables with Linux (although this is not something that happens by default)
I can't be sure (long, long time since I've used Rails), but it looks like something in the app_loader.rb is checking permissions on Java directories in the path. It may be using some logic like "check each path entry and look for a java or java.exe there. If found, check permissions." Or something like that. That means that (2) and (3) above may be confusing it.
You can see this in action with which java.exe, which will likely return a Windows path. Or run notepad.exe, which will launch the Windows Notepad executable from within Linux/WSL (magic! 😉).
These are both very useful features, so I hate to disable them completely, but it's the easiest way to figure out if that's the problem. Create a /etc/wsl.conf with the following contents:
[interop]
enabled=false
appendWindowsPath=false
Exit your WSL instance and then:
(from PowerShell, CMD, or Windows Start) Run wsl --list --verbose to see the name of your distribution (most likely Ubuntu)
Likewise, run wsl --terminate <distro> to terminate that distribution.
Restart your WSL instance
Try running /mnt/c/Windows/system32/notepad.exe (assuming a normal C:\Windows installation) (should fail, since interop is disabled)
Try which notepad.exe (should fail, since the Windows path should no longer be appended to the Linux path)
Try to start your Rails dev server again - Might work (might not, I could easily be wrong about the root-cause here)
If it does work, then you can try to correct the situation with several less invasive methods than disabling those features entirely:
If you plan on only using WSL for your development, then you could remove the Windows JDK.
Or at least remove the Windows JDK from the PATH in Windows.
Or, if you want to keep it installed and in the Windows path, you could have a shell startup file (e.g. .bashrc) that removes it from the path only in WSL. I'll point you to this question which contains multiple techniques for doing so.
Or you could keep the appendWindowsPath=false in your /etc/wsl.conf but then add back in the paths you want manually in your startup config.
Suppose I have a Grails application named myCoolApp.
Furthermore, suppose I have defined some basic properties in grails-app/conf/Config.groovy and grails-app/conf/DataSource.groovy under the test and production profiles.
Config.groovy is set to merge with the following .groovy external configuration file, if found at all:
grails.config.locations = ["file:${userHome}/.grails/${appName}-config.groovy"]
Finally, I have also defined, inside an external testing server, such a file, under a local *NIX user path:
/home/appServerTestUser/.grails/myCoolApp-config.groovy
Sadly, I find that for some reason, the external .groovy file's properties are not being merged when a Tomcat instance starts up.
What options do I have to make Grails tell me: "Oh, yes, I found your external config file at: /home/appServerTestUser/.grails/myCoolApp-config.groovy" and these are the properties I merged into Config.groovy?
Thanks!
File-based paths don't make much sense in a deployed app. It could work when deploying on your dev machine for testing, but will likely fail on any other machine. And it'll probably fail locally even if configured with the correct path since the process will like run as a different low-priviledge user.
You can use absolute paths, e.g. /etc/myapp/path/to/file, but this tends to couple deployment to filesystem structure, so if you develop in Windows and deploy on Linux it'd be tricky to get them both working.
So the best bet for Tomcat deployment is to use the classpath syntax. You can specify multiple files and it will load all that it finds, so I usually have one entry for local dev and one for the deployed app:
grails.config.locations = [
"classpath:${appName}-config.groovy",
"file:./${appName}-config.groovy"
]
I delete the entries for .properties files because Groovy syntax is so much more flexible, but use them if you like. I also keep the dev files in the project root (and exclude from source control).
So when deploying, name the file correctly (different apps will have different files, so no clashing there) and put them in Tomcat's lib directory. This is in the classpath, and so the classpath: entry will see it.
We are having an issue with the puppet java modules. They are adding the correct path, but they do not remove the old path:
C:\Windows\system32>path
PATH=C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program
Files (x86)\IBM\RationalSDLC\common;;C:\Program Files
(x86)\NTP\bin;C:\Program Files (x86)\Puppet Labs\Puppet\bin;C:\Program
Files\Java\jdk1.7.0_50\bin;C:\PROGRA~1\apache-maven\bin;C:\Program
Files\Java\jdk1.7.0_55\bin
You can see that it added the correct path at the end, but the original version jdk1.7_50\bin still exists. How can we make sure that it removes the old version every time it installs a newer version?
Edit: More importantly what we need to do is have it search for the JAVA_HOME path variable, compare that against Path variable, delete any java directory that doesnt belong, and copy the JAVA_HOME to Path. Hope that makes sense.
The puppetlabs-java module does not seem to make an effort to update the default environment.
I believe that the behavior you are observing results from actions taken by the Java installer itself.
If you can find out where Java puts the commands to append to the PATH, you may be able to have Puppet remove the obsolete lines using the file_line type from the stdlib module.
Edit after you supplied the manifest that handles the path:
If your paths are managed through this module, you will need to add resources to your manifest to remove each single obsolete entry, such as:
windows_path {
'java7u50':
ensure => absent,
directory => 'C:\Program Files\Java\jdk1.7.0_50\bin';
}
To simplify this for many versions, you can create a defined type:
define obsolete_java {
windows_path {
$name:
ensure => absent,
directory => "C:\Program Files\Java\$name\bin";
}
}
and use it like
obsolete_java { [ 'jdk1.7.0_50', 'jdk1.7.0_42', ... ]: }
I recently installed homebrew-cask and one of the things that I see is that it installs applications by default into the following directories:
Versioned package downloads => /opt/homebrew-cask/Caskroom/
Example : /opt/homebrew-cask/Caskroom/pdftk/2.02
Application binaries/libraries => /opt/
Example : /opt/pdftk/bin/
Instead of using the /opt directory, I would really like to use a directory located in /usr/local which is where my homebrew installation resides.
I can see from the docs that I can set an environment variable for #1, but I can't seem to figure out where to change #2.
I'd like to have the above two settings go to:
/usr/local/Caskroom/packages/pdftk/2.02
/usr/local/Caskroom/pdftk/bin
Any ideas on how I can change both settings or are there good ideas why I wouldn't want to do this?
Thanks.
From the Caskroom manual (specifically the Usage manual) you can change where the actual application will be installed by adding a line like this to your .bash_profile or .zshenv etc.
# Specify your defaults in this environment variable
export HOMEBREW_CASK_OPTS="--appdir=/Applications --caskroom=/usr/local/Caskroom"
I have in my main config something like:
grails.config.locations = ["file:grails-app/config/Jawr.groovy"].
When running the application with grails run-app, everything is OK.
But, on deployment (creating the war archive) this does not work anymore, as the file "Jawr.groovy" is not kept anymore on the filesystem (it should be only in the war).
Do you have a solution for that? Hw do you include external files into the grails main configuration file?
Thanks.
Okay, a few things here.
First, because you don't have a leading slash on your config path, that is a path relative to who knows where. I played with this in Tomcat, and that path ends up being relative to the working directory you were in when starting the Tomcat server. If you start Tomcat, shut it down, change directories, then start it again, you are going to get two different config paths.
Second, the grails-app directory only exists within the source tree of your Grails project. The structure of an unpacked WAR file is more like the web-app folder of your Grails source tree, with folders like WEB-INF, META-INF, js, images, etc.
Third, you probably want to avoid putting your externalized config file inside the folder of your webapp. The next time you deploy your app, that configuration is going to get wiped away with the old version of the app. One of the points of the externalized config is so that you can redeploy without having to reconfigure.
A simple, but less than ideal, solution would be to use a static, fully qualified path, like /etc/yourApp/conf.groovy, then put that in the documentation. There is also a plug-in that handles this.
http://www.grails.org/plugin/external-config
I haven't used it, but the description makes it sound like it does sensible things.
see this: https://stackoverflow.com/questions/6341117/is-it-possible-that-grails-xxconfig-groovy-as-a-script-no-compile
Then I put it into /shared, and
modify:
//Config.groovy
grails.config.locations =
["file:shared/TZLibConfig.groovy"]
//BuildConfig.groovy
grails.war.resources = { stagingDir, args ->
copy(todir: "${stagingDir}/WEB-INF/shared"){
fileset(dir:"shared",includes:"**")
}
}
In my work, our team often use a system properties to save the path to the config file (often in home folder of the user running the app - for privilege sake). Then we manually copy the config file into that path
To identify that it's the production environment, we use the following code in Config.groovy:
if (System.properties["${appName}.config.location"]) {
grails.config.locations = ["file:" + System.properties["${appName}.config.location"]]
}
This article suggests allowing the user to specify the location of the config file as an environment variable or as a java property --- meaning you can simply specify it with -D on the command-line. This can be used in addition to all the other methods.