Is there a (recommended) way to determine within nginx.conf.erb the app_type that Phusion Passenger (in standalone mode) has autodetected, per its autodetection algorithm? In Passenger 5.1.8, we'd been relying on AppFinder.looks_like_app_directory?, but it looks like that's been made private in 5.1.11.
We could simply look for any of ["config.ru", "passenger_wsgi.py", "app.js", ".meteor"] ourselves but would prefer to rely on the app_type already detected, particularly if it was manually specified with --app-type at the command line.
Assuming you are in a server block, then <%= nginx_option(app, :app_type) %> should work for you.
If you just need it for conditional stuff, not output then app[:app_type] is what you want.
Related
I need to create a resource (a SCOM agent management group) only if a specific registry setting is not present.
The statement itself is simple but the class doesn't contain any built-in conditional checks (similar to "unless =>" in exec class). The statement fails on SCOM management server because there is no SCOM agent installed. I want to prevent execution of the statement on such servers.
SCOM management server can be identified by presence of specific registry settings. If there any way to check that presence in "if", "unless" or other conditional statements? I know it's possible to write a custom fact and use it along with "if" but I don't know anything about Rubi and have no time to dive in. I need something simpler. Any hints would be highly appreciated.
I need to create a resource (a SCOM agent management group) only if a
specific registry setting is not present.
Well that's part of the problem right there. You ought to know what machine is supposed to host a SCOM management server, and avoid declaring the agent management group based on that machine's identity. You especially ought to know that if you have Puppet managing the management server, too, but even if you don't, this oughtn't to be something that you're figuring out dynamically at runtime.
But since you are ...
The statement itself is simple but the class doesn't contain any
built-in conditional checks (similar to "unless =>" in exec class).
If the resource that you want to apply conditionally does not have any built-in conditional checks that serve the purpose, then Puppet conditional statements such as if and case are the most likely options.
SCOM management server can be identified by presence of specific
registry settings. If there any way to check that presence in "if",
"unless" or other conditional statements?
Puppet conditional statements are evaluated during catalog building, on the Puppet server. What it knows about client nodes is limited to what your node classification, external (Hiera) data, and node facts convey to it.
I know it's possible to write a custom fact and use it along with "if"
but I don't know anything about Rubi and have no time to dive in. I
need something simpler.
Custom facts are not hard to write, but for this purpose, you might find it easier to use an external fact, which on Windows can be implemented via a PowerShell script or batch file. If that's not simple enough for you, then we're back to Puppet needing to know based on node identity. That would manifest as having a different node block for the SCOM server or having different node-specific Hiera data for that node.
Can't comment this due to rep, but writing custom facts is easy, here is a an example. You will obv need to update the registry key to the correct path.
osfamily = Facter.value('osfamily')
case osfamily
when 'windows'
Facter.add('custom_fact') do
setcode do
begin
value = nil
Win32::Registry::HKEY_LOCAL_MACHINE.open('SOFTWARE\ServerInfo') do |regkey|
value = regkey['value_name'].downcase
end
value
rescue
nil
end
end
end
end
Then in your puppet code you can include or exclude resources based on the value.
if $facts['custom_fact'] {
# Do something
}
do you do how the syntax config is? I find a lot opswork 's document but still not see it concern that.
You need to modify the Nginx recipe attributes. Unicorn recipe attributes don't have what you're looking for.
{"nginx":{"proxy_read_timeout":"900", "proxy_send_timeout":"500"}}
This is entirely dependent on what cookbooks you are using which you didn't mention. Additionally 11.x is no longer supported and is likely unsafe to use.
I don't know if this is possible I have only been using chef for about a week and a half now, I can't seem to find anything on the internet about doing this. But basically we have the chef client installed on a image. Each image has a configuration script that is run when the image is setup for the first time to set up the computer name and other settings specific to its setup.
So what I need to have happen once the config script finishes is to have a node created with the node name as the name of the computer that was entered automatically, along with aslo adding it to a role so that these nodes can later be sorted and have the correct roles added. So that going forward each new node will be created as soon as the server is setup without human interaction.
The way you do this is with the validator key system. Basically in the image have Chef installed, and have the /etc/chef/client.rb configuration created and pointed at your Chef Server, but don't create the client.pem key. If that key doesn't exist, chef-client will look for a validation key and use that to self-register with the Chef Server (by default it uses the FQDN of the server as the node name, but you can have your last-mile script append node_name "whatever" to the client.rb if you want to use something else). The difficult bit of validator-based bootstraps is how to store, access, and manage that validator key. The lazy way would be to just include it in the image, but this raises some troubling security issues. Unfortunately the best approach will depend entirely on what kind of systems you are running on and what security infrastructure is available. Also don't forget to remove the validator key after the initial bootstrap, there is a recipe in the chef-client cookbook for this.
I wrote simple function for my puppet module. It makes some requests using puppetdb API and I need IP address of puppetdb server. Is there correct way to get settings of connection PuppetMaster to puppetdb to get address of puppetdb server or I should parse puppet.conf by hand?
Parsing puppetdb.conf by hand would be the least desirable way to go about it.
Looking at the code that loads the config, it should be possible to access it using
settings_value = Puppet::Util::Puppetdb.config['main'][setting_name]
for configuration options from the [main] section.
Looking at even more code, you should even be able to use
Puppet::Util::Puppetdb.server
Puppet::Util::Puppetdb.port
I'm not entirely sure whether those APIs are available from parser functions, but it's worth a shot.
I have ruby file which im running in my mac with OSX 10.9 that is a combination of sinatra and geography which i have both installed. when i use require 'sinatra' on the file everything is fine, but when i insert require 'neography' it gives me this error when trying to run the file.
/Users/AJ/.rvm/gems/ruby-2.1-head/gems/sinatra-1.4.4/lib/sinatra/base.rb:1488:in `start_server': undefined method `run' for HTTP:Module (NoMethodError)
from /Users/AJ/.rvm/gems/ruby-2.1-head/gems/sinatra-1.4.4/lib/sinatra/base.rb:1426:in `run!'
from /Users/AJ/.rvm/gems/ruby-2.1-head/gems/sinatra-1.4.4/lib/sinatra/main.rb:25:in `block in <module:Sinatra>'
What could be a possible reason for this error? Thanks in advance
Neography depends on httpclient, which in turn defines a module named HTTP.
When Sinatra tries to determine which server to use one of the options it tries is the net-http-server, whose Rack handler class is also named HTTP. This causes a name collision where Sinatra thinks the HTTP module in httpclient is the net-http-server and tries to run it as such, causing the error you see.
If you have another server installed, e.g. Thin, it will likely be detected before HTTP so you won’t see this error, but you are probably better explicitly setting the server to use. You can add something like
set :server, thin
to your application file to specify Thin as your server (you’ll need to install the thin gem first – you could also use Webrick). You could also specify this on the command line if you wanted: ruby my_app.rb -s thin, but I think you’d be better of adding it to your code to avoid problems in the future.