I know that can add set of docroot in yaws.conf but this not always convenient. Is exist way to start of server from current directory with yaws without modifying configuration file?
Two options:
Keep a template of your yaws.conf file somewhere and invoke yaws through a script that first uses the template to create a conf file with the current working directory filled in as docroot, and then runs yaws using its --conf command-line option to specify the newly-created conf file as its configuration file.
Run yaws in embedded mode, which allows you to programmatically specify the configuration. You can use file:get_cwd/0 to obtain the pathname of the current working directory, then use it as the value for docroot in the configuration details you pass to yaws_api:embedded_start_conf/1,2,3,4.
Related
My goal is to put my telegraf config into source control. To do so, I have a repo in my user's home directory with the appropriate config file which has already been tested and proven working.
I have added the path to the new config file in the "default" environment variables file:
/etc/default/telegraf
like this:
TELEGRAF_CONFIG_PATH="/home/ubuntu/some_repo/telegraf.conf"
... as well as other required variables such as passwords.
However, when I attempt to run
telegraf --test
It says No config file specified, and could not find one in $TELEGRAF_CONFIG_PATH etc.
Further, if I force it by
telegraf --test --config /home/ubuntu/some_repo/telegraf.conf
Then the process fails because it is missing the other required variables.
Questions:
What am I doing wrong?
Is there not also a way of specifying a config directory too (I would like to break my file down into separate input files)?
Perhaps as an alternative to all of this... is there not a way of specifying additional configuration files to be included from within the default /etc/telegraf/telegraf.conf file? (I've been unable to find any mention of this in documentation).
What am I doing wrong?
See what user:group owns /etc/default/telegraf. This file is better used when running telegraf as a service via systemd. Additionally, if you run env do you see the TELEGRAF_CONFIG_PATH variable? What about your other variables? If not, then you probably need to source the file first.
Is there not also a way of specifying a config directory too (I would like to break my file down into separate input files)?
Yes! Take a look at all the options of telegraf with telegraf --help and you will find:
--config-directory <directory> directory containing additional *.conf files
Perhaps as an alternative to all of this... is there not a way of specifying additional configuration files to be included from within the default /etc/telegraf/telegraf.conf file? (I've been unable to find any mention of this in documentation).
That is not the method I would suggest going down. Check out the config directory option above I mentioned.
Ok, after a LOT of trial and error, I figured everything out. For those facing similar issues, here is your shortcut to the answer:
Firstly, remember that when adding variables to the /etc/default/telegraf file, it must effectively be reloaded. So for example using ubuntu systemctl, that requires a restart.
You can verify that the variables have been loaded successfully using this:
$ sudo strings /proc/<pid>/environ
where <pid> is the "Main PID" from the telegraf status output
Secondly, when testing (eg telegraf --test) then (this is the part that is not necessarily intuitive and isn't documented) you will have to ALSO load the same environmental variables into the current user (eg: SET var=value) such that running
$ env
shows the same results as the previous command.
Hint: This is a good method for loading the current env file directly rather than doing it manually.
I've setup a data pipeline using divolte.io to stream click data from website to a server. I'm not sure how can I do this for multiple websites because all the streams can get mixed up. Any ideas on how to do this?
On the same server, you need to bind to different ports
Create more than one config file, setting divolte.global.server.port to different values, then run the application with those configs.
In order to set a new config file, it actually needs to be in it's own directory
Divolte Collector will try to find configuration files at startup in the configuration directory. Typically this is the conf/ directory nested under the Divolte Collector installation. Divolte Collector will try to locate the configuration directory at ../conf relative to the startup script. The configuration directory can be overridden by setting the DIVOLTE_CONF_DIR environment variable. If set, the value will be used as configuration directory
Alternatively, you could run the exact same config within many containers/VMs, then use port mappings around that
I tried to run grailsw, but the wrapper cannot connect to download grails-2.2.1-download.zip (creates a 0 byte file instead).
I need to use a proxy server to connect to the internet, where do I configure proxy settings for the Grails Wrapper?
After running grails wrapper, your project directory has a new subdirectory called wrapper, with a file grails-wrapper.properties. You can configure your proxy settings in there, with the following properties:
systemProp.http.proxyHost=
systemProp.http.proxyPort=
systemProp.http.proxyUser=
systemProp.http.proxyPassword=
systemProp.http.nonProxyHosts=
I solved this problem for myself.
It is a two step process
1.a) Back up your JRE_HOME\lib\security folder. This is essential because the below steps might corrupt cacerts file under jre.
1.b) You need to install the ssl public key of Github.com to your local file system. To do that you have to use the InstallCert.java program( Link to InstallCert.java )
It is supposed to be run as java InstallCert github.com
and when it asks to enter cert number you need to enter 1
It will create a file with name "jssecacerts" in the current directory
1.c) But this program will not work because it does not know about how to authenticate with proxy. For this you need the code from SSLSocketClientWithTunneling page
Use the above two and create a program that tunnels through the proxy retrieves the ssl key and writes a file called jssecerts
2) Update your grails.bat with addtional options. Add these options to the %JAVA_EXE% command line. Paste them after %DEFAULT_JVM_OPTS%
-Dhttp.proxyHost=YourproxyURL -Dhttp.proxyPort=YourproxyPort -Dhttps.proxyHost=YourproxyURL -Dhttps.proxyPort=YourproxyPort -Dhttp.proxyUser=YourProxyUserID -Dhttp.proxyPassword=YourProxyPassword -Dhttps.proxyUser=YourProxyUserID -Dhttps.proxyPassword=YourProxyPassword -Djavax.net.ssl.trustStore=path-to-your-jssecacerts-created-in-step-1
I have an application running at a URL like this:
http://myapp.mydomain.com/myapp
I don’t want the /myapp part in the URL. So how can I get rid of the application name? I want just
http://myapp.mydomain.com
to be the URL. How can I do this?
bit detailed approach
First Method:
first shutdown your tomcat [from the bin directory (sh shutdown.sh)] then you
must delete all the content of your tomcat webapps folder (rm -fr *) then
rename your WAR file to ROOT.war finally start your tomcat
[from the bin directory (sh startup.sh)]
Second Method:
leave your war file in CATALINA_BASE/webapps, under its original name - turn off
autoDeploy and deployOnStartup in your Host element in the server.xml file.
explicitly define all application Contexts in server.xml, specifying both path
and docBase. You must do this, because you have disabled all the Tomcat
auto-deploy mechanisms, and Tomcat will not deploy your applications anymore
unless it finds their Context in the server.xml.
Note:
that this last method also implies that in order to make any change to any
application, you will have to stop and restart Tomcat.
Third Method:
Place your war file outside of CATALINA_BASE/webapps (it must be outside
to prevent double deployment). - Place a context file named ROOT.xml in
CATALINA_BASE/conf//. The single element in this context file MUST have a
docBase attribute pointing to the location of your war file. The path element
should not be set - it is derived from the name of the .xml file, in this
case ROOT.xml. See the Context Container above for details.
1) Your app server needs to be configured to have your grails application as ROOT application
2) your grails application context path should be "/" or app.context=/
You can make Tomcat serve a webapp as the root context by simply naming it ROOT.war, i.e. take the myapp-0.1.war generated by Grails and copy it to TOMCAT_DIR/webapps/ROOT.war.
If you have a setting for grails.serverURL in your Config.groovy you will need to override this for your production environment to ensure that any absolute links generated by Grails are correct
environments {
production {
grails.serverURL = 'http://myapp.mydomain.com'
}
}
But in Grails 2 it is usually safe to omit grails.serverURL entirely and let the app deduce the right value at runtime. You only need it if you're running behind a reverse proxy that doesn't pass through the correct Host header.
I've seen questions and answers about how to specify external .groovy and .properties files for Grails config that are outside of the WAR file using grails.config.locations, but we need external config that isn't on the server on which the container (Tomcat) is running.
(It does have a local FS, but it is not persistient and is identical for all deployment environments - hence the need to override it external to the WAR, container and server).
So, can I use http: URLs for grails.config.locations ?
Yes. The following works:
Add this in Config.groovy and pass PARAM1 using -D to the JVM to specify the external URL for the config file.
grails.config.locations = ["url:" + System.properties["PARAM1"]]
I am not aware of any built in functionality that would allow you to specify URL for grails.config. However, it seems like something that you could implement yourself:
define your URL(s) that you want to use to d/l the Congif.groovy file that is included in your WAR
in that same Config.groovy script, write code to download the file to a specific location on your server's file system (see this article)
set your grails.config.locations to point to the file system location that you wrote the Config.groovy file to.
I haven't tried it but seems like it would work.