I'm running Facter 3.6 and trying to add a custom fact. According to the documentation, the folder /etc/puppetlabs/facter/fact.d/ is automatically used for custom facts.
I place the following template into said folder as hello.rb:
Facter.add(:hello) do
setcode do
"Hello, world"
end
end
I then force a puppet run on one of my agents with puppet agent -t.
When I look in PuppetDb I don't see my new custom fact hello. Did I miss a step in adding my external custom fact?
/etc/puppetlabs/facter/fact.d/ is the location for custom facts on the client nodes. If you want a custom fact to appear on only that client, then you can add the custom fact to that location. Pluginsync will also transfer your custom facts for the current catalog to that location automatically.
Therefore, the preferred method for distributing custom facts is to place them inside the corresponding module's lib/facter directory. They will then be distributed to all nodes that have a catalog applied with that module in any of the module paths for its directory environment.
Note specific documentation here: https://docs.puppet.com/facter/latest/custom_facts.html#using-the-ruby-load-path
Also note you are doing a custom fact and not an external fact. If you were doing an external fact, then it would preferably be located in the corresponding module's facts.d directory: https://docs.puppet.com/facter/latest/custom_facts.html#fact-locations.
Related
Using TFS 2013 It is a simple matter to generate debug symbols as part of the build process by entering a location into the ‘Path to publish symbols’ field of the build definition. Unfortunately I can’t use any of the TFS build environment variables to specify the drop location for the symbols in the ‘Path to publish symbols’ field because symbol publishing takes place after the build is done and those variables are apparently no longer in scope. So I specified a Debug folder in a fixed location and was going to move it to the desired location with the PostBuild script. Even that does not work because the symbols are not yet present when the postbuild script runs. The order of events is (roughly):
1. Run prebuild script
2. Build
3. Run postbuild script
4. Tests
5. Generate symbols
It looks like this is typically accomplished with yet another server… a Symbols Server. Is that what everyone does?
I notice that the information to determine the proper location to save the files (for me anyway) can easily be found using information in ..\000Admin\server.txt. Using that info I could have the postbuild script wait (say… up to an hour) for the symbols to appear (they should be there in a minute). Then move the Debug folder from the fixed location to the proper location. Is there a better way?
Thanks.
The symbol server / symbol share is a separate thing from the drop location. It's structured in a specific way the Debugger understands and allows one to debug an application without having to ship the .pdb files with the application.
Since you may want to provide other parties access to your symbol server (similar to how Microsoft allows access to their symbol servers for most of the .NET framework), then you can simply tell them the location and optionally the credentials needed to access them.
The symbol share is not really meant for human consumption, it's all built up with GUIDs and hashes so that the debugger can find its way around easily and quickly. It's also structured so that multiple versions of the same symbol are stored side-by-side.
Especially that last part, storing different assemblies and different versions side by side in the same location, is why you should not try to inject project names or versions into the symbol share location. That's for the debugger to figure out.
Just to be clear, it doesn't have to live on a different server, the only thing required is that you enter a path to a share, it can even be a sub-folder of that share. so sometimes you see configurations like:
\\tfs\symbols\
\\tfs\builds\
Or
\\tfs\artifacts\symbols
\\tfs\artifacts\drops
But indeed, you could drop your symbols to a completely different server altogether:
\\tfs\builds
\\corporate\symbols
Or you could configure multiple distinct computer names for one system (or use multiple DNS records) and actually have the same server listen to:
\\tfs-symbols\share
\\tfs-builds\share
Or even register the shares at the Active Directory level, allowing you to just use
\tfs-symbols\
\tfs-builds\
What you choose is all up to you, but make sure that the two paths of symbols and builds are eventually unique.
I'm trying out a yesod applications which I will eventually put up on github or similar.
I will use oauth2 with google which means I have to provide an email and secret token. Which I obviously do not want up on github.
What is a good place to store these in a yesod scaffolded application? I'm hoping to store it in a seperate, config/secret.yml for example, so I can put that into the ignore file of git/mercurial and never commit it.
But i can't find out how to include such a file. Or if such a file already is provided by yesod. config/settings.yml seemed possible, but there's entries there which I would like in github.
So my question is, in a yesod scaffolded application. Where can I store secret keys in a way I can easily exclude it from version control systems?
There are many approaches to this, mostly depending on what flavor of devops/hosting your prefer. One option is to put a dummy value in the config file and override it with an environment variable at runtime (see: https://github.com/yesodweb/yesod/wiki/Configuration#overriding-configuration-values-with-environment-variables). You can also having an extra settings file for production that overrides the values in the default config file, which is how the test suite works. A completely different approach would be to use a system like vault in production and query it for your secure credentials.
EDIT To spell out one of the approaches:
Create a new YAML file with the settings you won't to override, e.g. in config/production.yml:
copyright: This is a copyright notice for production
When you run the application, pass in a command line argument giving the location of the config file
I want to create a development environment running Movable Type 5.
To create a separate development environment, it is necessary to copy and paste to reflect production.
How would I go about building a good environment?
There are many ways to build a development environment, and an experienced Movable Type developer would need to know more about your goals in order to make a good recommendation.
All of the following guidance assumes that Movable Type has been installed and is ready to run
on the development server.
Here are a few basic tips:
Although some of the key configuration details for a Movable Type instance are kept in mt-config.cgi, there are website-level and blog-level settings that are of equal importance that are kept in the underlying database.
Since most Movable Type 5 instances use MySQL as the database backend, it's possible to dump the entire contents of the Movable Type database using the mysqldump utility or a more visual tool like the Export function of phpMyAdmin. This produces a large text file with MySQL CREATE TABLE and INSERT statements.
Once the database is dumped to a file, the file can be moved to another server, modified, and reconstituted. One of the tasks we commonly perform at that point is to go through the database using an editor, the UNIX sed command, or some similar process, and perform global searches and replacements for the URLs and file system paths that are embedded in the database dump.
This is necessary in many cases because your production website may be http://www.mysite.com/, but your development environment may be http://dev.mysite.com/ or even http://localhost/. Similarly, the file system paths in production may be /var/www/mysite/htdocs/... while development may be /opt/local/apache2/htdocs/mysite/....
Once changes of this nature are made and the modified file is saved, the database is reconstituted on the development server by using a UNIX shell command like:
cat mysite.sql | mysql -u mt_user -p mt_password
Or by importing the database into another copy of phpMyAdmin.
Once all of this is done, the mt-config.cgi file from production needs to be copied into the Movable Type working directory and rewritten so that several important elements are changed:
CGIPath
StaticWebPath
Database
DBUser
DBPassword
DBHost
These Movable Type Configuration Directives are discussed in the online documentation.
All of the non-database assets have to be copied from production to development. Things like files containing jpeg, png, and gif images, files that have been placed in the production file system either manually, or using the Asset Manager. There may be other files that need to be copied from production, depending on how you use Movable Type.
Once all of this is done, and you are able to login to the Movable Type development server successfully, you will probably want to the websites and blogs to ensure that all of the content has been copied into development.
I hope these instructions are somewhat helpful to people needing to setup a development environment. I would be happy to get comments or edits if anyone thinks I left out anything significant.
By saying that you need a development environment for Movable Type, what exactly do you need to develop?
If you are developing a plugin? or theme? a website? content?
It is possible to assign a different mt-config.cgi file to each virtual server, and working on different database, for the same installation.
If you are developing a plugin, you will want to use the PluginSwitch directive so the developed plugin won't be loaded on the real website.
http://www.movabletype.org/documentation/installation/managing-multiple-instances-of.html
Eslar, you may like to consider also this documentation resource:
http://www.movabletype.org/documentation/mt41/rsync.html
Alternatively, you may like to consider:
http://www.cis.upenn.edu/~bcpierce/unison/
If you go with the 'rsync' solution described in the movable type documentation, you may like to check also these configuration directives mentioned there:
http://www.movabletype.org/documentation/appendices/config-directives/rsyncoptions.html
http://www.movabletype.org/documentation/appendices/config-directives/synctarget.html
My Google App Engine application includes privileged credentials (like OAuth and cookie signing keys) that I don't want to check in to source control (i.e. Git).
I've considered storing these as system properties or environment variables in the appengine-web.xml file, however this file includes a number of other things that I do want to version. Where would be a good place to store "secret" application data so that I can easily exclude it from source control?
What I usually do it store the credentials in a secure repository (a file that is only accessibly by a superuser that I can trust) and then have a post-build script. Within source control, I have a dummy password in a properties file and then then post-build script runs after a build and replaces the dummy passwords with the real ones. That way the passwords are not in source control, but show up upon every build. This does depend on an automated build/deployment process, but it is very effective.
Put those things into another file/directory and exclude them with .gitignore.
For Java, I recommend the strategy of spring-boot's externalized configuration. The idea is a stack of configuration sources with the ones toward top override the ones below.
Command-line arguments
System properties
Environment variables
Local configuration files (application.yml or application.properties)
Configuration files at the classpath
No. 4 is usually in a hidden folder in the user's home directory, e.g ~/.myapp/application.yml. Only the user can read that file.
For your question, the non-secret, version-controlled properties are put directly in the source code (No. 5 above). Secrets can be also put in 5 but with dummy values. Real secrets overwrite the dummy values at runtime from 1, 2, 3, or 4.
You can either use spring-boot or write your own code following that same strategy.
I'd like to be able to have either web dashboard logged in administrators or general users depending on which the team prefers be able to see the contents of this file without remoting into the box, is this possible using the webdashboard?
This is not an answer to how it can be seen from the web dashboard...
... but it is possible to store the ccnet.config file in source control and set up a special build on the build server that automatically retrieves the newest config file.
This way you do not even have to remote into the box in order to edit the contents of the file.
See more details in the documentation:
http://confluence.public.thoughtworks.org/display/CCNET/Configure+CruiseControl.Net+to+Automatically+Update+its+Config+File