The documentation for Chef attribute precedence is here: https://docs.getchef.com/chef_overview_attributes.html
However, the docs don't really explain what level is applied to attributes that are passed in via the -j flag for the knife bootstrap command.
The reason why I'm asking is because I'm passing in attributes and some of those attributes aren't being applied correctly to my run.
Stuff passed in via -j are set as the node data, which are the normal/set level.
As #coderanger pointed out, they should be at the set level if you are formatting your json correctly. If your Json isn't formatted correctly, it won't set the values at all, but may not give you an error.
For troubleshooting, you can use node.debug_value to see the whole attribute tree.
Or if you want a shortcut, use the spicerack cookbook's print_attribute_debug recipe to grab it and print it. The cookbook as a whole is still really immature, but the README gives the usage details and it's plenty good for debugging purposes.
Related
When Pylint warns me about something, how can I know what settings it's applying? And what section of .pylintrc this setting goes in?
For example:
Used builtin function 'map'. Using a list comprehension can be clearer. (bad-builtin) is because bad-functions in [BASIC] contains map.
Missing function docstring (missing-docstring) is conditional on docstring-min-length in [BASIC].
invalid-name obeys several [BASIC] settings: variable-rgx, method-rgx, module-rgx, etc.
I expected to find this information in the Pylint documentation but it generally doesn't provide this information. For example, there's no link from the documentation of missing-docstring or invalid-names to the applicable options. With bad-builtin, the information is easy to find, but only because it's from a specific extension. The Pylint message wiki has explanations about what the message means, but not what brought it up. The comments in pylint --generate-rcfile don't relate the settings to warning codenames either (nothing there explains that e.g. bad-functions influences the bad-builtin message).
The reason I'm asking this is that in many cases, Pylint's conventions don't match my project's needs and conventions, and I want to tune it rather than ignore specific instances or ignore messages wholesale (so I'm not looking for disable=!). So how do I find what to tune?
How do I find what to tune?
So it seems like you're asking about how you can determine the combination of factors that lead to a pylint message being raised. Using the bad-builtin example, a warning message that is not listed at all in the .pylintrc, a helpful verbose message would be:
bad-builtin: Used builtin function 'map'. Using a list comprehension can be clearer.
---> (Hypothetical) VERBOSE OUTPUT:
bad-builtin was raised because the bad-functions setting in your .pylintrc under the [BASIC] section contains the function map. If you want to "tune" this behavior look here.
Short answer: I am not sure this exists.
When you run pylint my_file.py the first thing it should tell you is the configuration file it is using. From there, you want to find the .pylintrc in use or else you want to create it. Otherwise it will be using the default configuration. If pylint does not tell you what config you are using you can figure out your current pylintrc configuration by running something like:
pylint --generate-rcfile &> output.txt
When you inspect output.txt it should look like this example pylintrc. It is organized into different categories. You can get more info on this without generating an rcfile by running pylint --long-help. The sections include:
[MASTER]
[MESSAGES CONTROL]
[REPORTS]
[BASIC]
[ELIF]
[TYPECHECK]
[FORMAT]
[MISCELLANEOUS]
[VARIABLES]
[LOGGING]
[SIMILARITIES]
[SPELLING]
[IMPORTS]
[DESIGN]
[CLASSES]
[EXCEPTIONS]
I am not sure what you mean by, "The Pylint message wiki has explanations about what the message means, but not what brought it up." When I run pylint on a file or in a code base it tells me exactly where the offending line is.
Then I usually either:
Fix the warning
Disable the warning
Modify the .pylintrc to meet my needs
If you want to tune a specific message type but you are not sure how to do so, then I think you are right that is something that could be better documented. The question: Is XYZ warning message 'tunable'? Or is the only option to fix OR disable? This page lists the pylint features but I do not see anything about bad built-in, for example, let alone the options that are available to apply to a message type.
UPDATE: I am not sure what version of pylint you are on, but it looks like the bad-builtin was specifically addressed in pylint version 1.6. I was going to say we should look at what is going on in the actual source code to generate this message, but I think that requires figuring out what version of pylint you are on first, then digging into the code, then figuring out how to tune it? I agree that the docs can be more clear on how to tune specific warnings:
The bad-builtin check was moved into an extension.
The check was complaining about used builtin functions which were
supposed to not be used. For instance, map and filter were falling
into this category, since better alternatives can be used, such as
list comprehensions. But the check was annoying, since using map or
filter can have its use cases and as such, we decided to move it to an
extension check instead. It can now be enabled through
--load-plugins=pylint.extensions.bad_builtin.
In WebSphere Application Server 8.5.5 I'm having problems setting the native_stdout and native_stderr log paths from wsadmin jython script.
Everytime I set one path, the other is blanked out. i.e. set to null.
I presume I need to form a line of code that sets both paths simultaneously but have been unable to create the correct syntax, if this is at all possible.
The code to produce one path change looks like:
srv = AdminConfig.getid('/Cell:mycell/Node:mynode/Server:server1/')
processDef = AdminConfig.list('JavaProcessDef', srv)
AdminConfig.modify(processDef, [['ioRedirect', [['stderrFilename', '${LOG_ROOT}/server1/new_stderr.log']]]])
AdminConfig.save()
This works fine but when I then use the same script to set the stdoutFilename, it blanks the stderrFilename previously set.
It seems to make no difference at which point I commit the changes using save.
Any help with this issue would be greatly received!
You're right, even though the manual elsewhere warns that AdminConfig.modify() might append to lists when you don't expect it to. I observed the same thing.
Here's the pattern you want to be safe, clear it out and set both properties at the same time:
AdminConfig.modify(processDef, [['ioRedirect', []]])
AdminConfig.modify(processDef, [['ioRedirect', [['stderrFilename', '${SERVER_LOG_ROOT}/my_stderr.log'], ['stdoutFilename', '${SERVER_LOG_ROOT}/my_stdout.log']]]])
After this, you can do this for a simple verification:
print AdminConfig.showall(processDef)
But watch the output closely as it is not pretty-printed
I am using the latest version of TeamCity and I am trying to make a parameter specification that refers to parameters.
I tried making a select (combobox), where the options of the checkbox are referring to variables. This should be possible, as there is a "parameter" icon to the right of the box suggesting me that I can use parameters here.
The full setup is shown below.
However, when I want to run the build, the only options are literally %foo% and %bar% as if the parameters have not even been evaluated.
Instead I had expected the options to contain the values of the variables that they are pointing to.
What am I doing wrong here?
Might be a bit late, but this is how I did it:
I have a few parameters for holding passwords, e.g. 'mfgpwd'
And I refer to these in another parameter using the syntax:
mfgpwd=%system.mfgpwd%
(I'm using TeamCity 8.1.5)
Seems like once you set the Testers field on a Test Case in MTM, it will not allow you to clear it. You are only allowed to change it to a different value. Has anyone found a way to clear this field?
It is important to not get the "Assigned" Tester field confused with the Assigned To field. They are distinct fields on a Test Case work item. One reason why someone might want the Tester field to be blank is if a team all pitches in to help with testing during an iteration and leaving the assigned tester blank allows the team to know that no one has "picked up" this test to execute. The team member could then assign the test to his or herself and execute it.
The template pulls the Assigned Tester Values from a list using the 'AllowedValues' tag. Instead, simply change this to 'SuggestedValues'. That will allow for empty values - easy as that.
If you'd rather not allow free entry, you can also add a default value such as 'None' and use that rather than blank.
Unless you've customized your work item type, this field should never be blank after being saved. It defaults to the person who created the bug in all Microsoft supported process templates, and a value is required by default.
That being said, why would you want to change it to blank?
If you really, really want to be able to blank it out (which I don't think is a good idea at all), you'll need to customize your template. See the below guidance:
http://msdn.microsoft.com/en-us/library/ms243849(v=vs.110).aspx
Am wondering if the combination of trim(), strip_tags() and addslashes() is enough to filter values of variables from $_GET and $_POST
That depends what kind of validation you are wanting to perform.
Here are some basic examples:
If the data is going to be used in MySQL queries make sure to use mysql_real_escape_query() on the data instead of addslashes().
If it contains file paths be sure to remove the "../" parts and block access to sensitive filename.
If you are going to display the data on a web page, make sure to use htmlspecialchars() on it.
But the most important validation is only accepting the values you are expecting, in other words: only allow numeric values when you are expecting numbers, etc.
Short answer: no.
Long answer: it depends.
Basically you can't say that a certain amount of filtering is or isn't sufficient without considering what you want to do with it. For example, the above will allow through "javascript:dostuff();", which might be OK or it might not if you happen to use one of those GET or POST values in the href attribute of a link.
Likewise you might have a rich text area where users can edit so stripping tags out of that doesn't exactly make sense.
I guess what I'm trying to say is that there is simple set of steps to sanitizing your data such that you can cross it off and say "done". You always have to consider what that data is doing.
It highly depends where you are going to use it for.
If you are going to display things as HTML, make absolutely sure you are properly specifying the encoding (e.g.: UTF-8). As long as you strip all tags, you should be fine.
For use in SQL queries, addslashes is not enough! If you use the mysqli library for example, you want to look at mysql::real_escape_string. For other DB libraries, use the designated escape function!
If you are going to use the string in javascript, addslashes will not be enough.
If you are paranoid about browser bugs, check out the OWASP Reform library
If you use the data in another context than HTML, other escaping techniques apply.