It has never happened before, but all of a sudden my server keeps running out of space because of these puppet reports.
Can reports=none inside the puppet.conf file, auto disable the generation of .yaml report files? Or is there a better way of doing it?
Will we ever need these .yaml files and do they affect anything if I delete them all?
Puppet has fairly good online documentation, including for historic versions of the software. You can find a good overview of the reporting feature here: https://docs.puppetlabs.com/guides/reporting.html. A bit more detail is provided in the relevant section of the manual proper, and the configuration reference provides some detail on the relevant configuration settings.
Some of the configurable aspects of reporting are:
whether agents send reports [the report parameter in the [agent] section of the config file]. This is configured on a per-agent basis. By default, they do send reports.
what the master does with the reports it receives [the reports parameter in the [master] section of the config file]. The default is to use (only) the store report handler, which dumps them to YAML files in the configured report directory.
Can reports=none inside the puppet.conf file, auto disable the generation of .yaml report files?
No 'none' handler is documented, but you can write and plug in custom report handlers, as described in the docs. A none handler ought to be trivial to write, but see below.
Or is there a better way of doing it?
I'd recommend configuring your agents to not send reports in the first place. That should be less work for all involved, human and machine. Do that by setting report = false (note: singlular "report") in the [agent] section of each agent's Puppet configuration file. You may need to restart the agents after.
Will we ever need these .yaml files and do they affect anything if I delete all of them?
They are for your benefit. If you have no use for them, then you can safely delete them.
Related
I've started working on an Azure project. In terms of config, I currently have three files: ServiceConfiguration.Cloud.cscfg, ServiceConfiguration.Local.cscfg and ServiceDefinition.csdef.
ServiceDefinition.csdef is the template file for the csfg files. ServiceConfiguration.Cloud.cscfg contains all the actual Azure configuration, including DB passwords, SAS keys etc.
Should ServiceConfiguration.Cloud.cscfg be checked into source control? I wouldn't have thought so but a quick search on github for the file shows that it is.
If it should be checked in, how should the sensitive password data be managed?
I typically check in the configurations. The reason is that the behavior of your application will change dramatically depending on these configurations. For example -> number of roles for a distributed application directly affects how you process incoming messages and the vmsize directly affects how much memory you have. You may encounter issues debugging problems if each developer is using a different configuration. This standardizes your deployment.
Anything with plain-text password information shouldn't be checked into a public repo unless you want people to have access to that information.
You can add this file to the .gitignore file and prevent it from being checked in.
Provide a different ServiceConfiguration.Cloud.cscfg named something like ServiceConfiguration.Cloud.cscfg.template with all the config info of your cloud service minus the password values. If someone forks your project they need to use that and fill in the appropriate values and rename the file.
Do this and change all your passwords to something else. Even if you delete this file from the repo, it still exists in the history and anyone can view it.
The majority of our C# projects configuration is kept in *.ini files. Mainly these files hold
many sections affecting all aspects of programs behaviour. But besides of regular configuration data some of sections are vulnerable like db connection string or server password. We try to keep this sections in following forms:
[Database]
user=testuser
database=testdb
password=
But when developer is testing application he must fill the config in order to start application. It is quite common that some of the passwords are commited into version control.
Because these files are indispensable for application they cannot be included in .svnignore.
Probably what I'm looking for is some kind of script (maybe in powershell). That would scan all *.ini files and erase all passwords. The most interesting solution would be adding some external password storage that can be used both to encode and decode passwords in *.ini files.
I always push to store configuration template files in subversion, but not actual configuration files. So if the configuration file is "config.ini" then I'll check in a "config.ini.template" populated with non-working sample data.
Then to prevent multiple developers from checking in their individual "config.ini" files, I'll add the actual configation file name to the svn:ignore properties list.
This forces the developer to copy the file and modify it appropriately for their environment, but eases the work of that task by not forcing them to find out which fields need to be present. If you have the time, you can even embed comments into the template file to simplify the meanings of some of the configuration options.
At the top of the file, include the directions of how to configure the system using the template, which should read something like:
# *** CONFIGURATION TEMPLATE --- DO NOT MODIFY THIS FILE ***
# 1. Make a copy of this file in the same directory with the command "copy config.ini.template config.ini"
# 2. Edit the new copy and follow the rest of the instructions
#
# Change "this.system.hostname" to the hostname of this system
Hostname = this.system.hostname
# Set the answer "23" to "42"
Answer = 23
You get the idea....
If you have problems (or think you might have problems) with people checking in their configuration options over the config.ini.template file, then I'd recommend using "svn lock" on the template file. However, with the appropriate warning, I've never found it necessary.
I'll not answer your question and instead recommend a different approach, assuming it's not too late to change the relevant design.
You should not store passwords in the same files as the rest. Have the application read a dedicated password file (or retrieve the password from a password storage service) in addition to the regular configuration file. This is not just about not storing passwords in svn, but also about not having passwords exposed to shoulder surfing, accidentally mailed or posted when someone asks for help with a non-working configuration, etc.
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
Our product consists of client, server and agents. Each deployed on different machines. The QA is having a hard time to manipulate the log4net sections in the respective config files. Right now, they have to have remote desktops to all the relevant machines and open notepad in each of them and then edit the files one at a time switching between different machines as they proceed. A real pain in the ass.
Can anyone suggest a better solution to this problem?
Thanks.
You could store the log4net configuration in a database (you could then even consider to create a web interface that allows your QA team to modify the configuration). You have to figure out how your applications pick up the new configuration (e.g. you have some remote Admin interface that allows you to tell your applications to use the new configuration).
On start-up you load the configuration from there. Maybe it is advisable to have some backup configuration in a file that is loaded first in case loading from the database fails. The default configuration would be for instance so that the QA team gets an email if loading the configuration from the database fails.
Another option would be to store all log4net configuration files on a network share... create an application setting that tells your application where to find the log4net configuration and call the Configure() method accordingly. Again the question is how your applications pick up the new configuration.
Not sure if ConfigureAndWatch() would behave as expected if the configuration files is on a network share. If so that would be quite an easy option to implement.
I am looking at the cruisecontrol web dashboard. I can see one farm and one server. However, I don't see any way to add a project?
Is this something I can do with the UI or do I need to edit the config file by hand?
You'll need to edit the ccnet.config file by hand (located within the CruiseControl directory) to add projects. There are some graphical tools to help you do this however you do get used to doing it by hand fairly quickly - just have the documentation near by!
Update: An example of one such tool is http://www.codeplex.com/ccnetconfig
You can use CCNETConfig to edit the config file through an UI although it doesn't support higher version > CruiseControl.NET 1.4.
You have to basically edit the configuration file by hand, however I have it setup so that the raw config file is split into different include files, each of which is setup in my source control system. Then I created a project for the configuration, and then for the whole config. So when something changes in the config, CC.NET itself pulls out the changes, recreates it's config files and the refreshes the system configuration.
This means that anyone can edit the config (if they can access the files in sourcecontrol), and no-one has to go into the program files directory of the CC.NET machine itself.
Not sure whether this answers the question you asked, but this is how our setup works