Run Time Argumnets in PCF - pcfdev

In order to run the application in my local, i need to provide some VM arguments(basically file path, where it is located). In similar way in PCF also I have to provide those arguments.
currently I am keeping in application.yml file like below.
jaas:
conf: /home/vcap/app/BOOT-INF/classes/nonprod_jaas.conf
krb5:
conf: /home/vcap/app/BOOT-INF/classes/krb5.conf
trustore:
conf: /home/vcap/app/BOOT-INF/classes/kafka_client_truststore.jks
When I deploy the application in PCF, will these files will be read from that location.
Basically I want to know this is correct way or not to provide the arguments in PCF.
how to check whether the file is present in that location, /home/vcap/app/BOOT-INF/classes/

You need to ssh into the container to check the location of the file.
cf ssh appname
In spring, #Value enables the use of the classpath: prefix to resolve the classpath (see this link) https://www.baeldung.com/spring-classpath-file-accessclasspath: It means you need to set this programmatically not via the variables in yml. Then you don't need to provide the path the way you are doing.
Also classpath: is a Spring specific convention, the JVM doesn't understand it which means you cannot use it directly in application.yml file. If you need to set in yml or as environment variable - you need to give it a full or relative path. On PCF, you can use /app or /home/vcap/app (the former is a symlink to the latter) as the path to the root of your application.

Related

How to use an environment variable in the odoo.conf

I am trying to use an environment variable in the odoo.conf
file to specify the path where the logs are stored.
So far I have tried:
logfile = ${test.rueda}/odoo.log
But it does not work.
Is there any way to achieve this?
The Odoo configuration files do not support access to environment variables.
I can think of 2 possible approaches:
Use relative paths. The file names in the configuration are relative to the working directory of the Odoo server process. Start the Odoo server in different directories, one for every purpose, and keep the same structure relative to that.
Use environment variables in the command line. When starting the Odoo server, any configuration option can be passed using -- (2 dash signs) as a prefix. In the start script, you can then use environment variables as in any other shell script.
See https://www.odoo.com/documentation/11.0/reference/cmdline.html for details.
For referencing files or path:
When i work without external disk (where i can find my datadir):
i use in odoo config file data_dir = my_absolute_path_in_my_local_disk.
This path have a symbolic redirection to where is my local physical location of my local data directory
When my external disk come back, i change the symbolic link:
my_absolute_path_in_my_local_disk -> my_external_disk_..._data

How to transfer a value from one build container to another in drone.io CI pipeline

I know I can write it to the mounted host file system which will be shared amongst the multiple build containers. But how can I make use of that file in a drone plugin container like docker-plugin?
Or, is there any other way to pass arbitrary data between build steps? Maybe through environment variables?
This is drone 0.5
It is only possible to share information between build steps via the filesystem. Environment variable are not an option because there is no clean way to share environment variables between sibling unix processes.
It is the responsibility of the plugin to decide how it wants to accept configuration parameters. Usually parameters are passed to the plugin as environment variables, defined in the yaml configuration file. Some plugins, notably the docker plugin [1], have the ability to read parameters from file. For example, the docker plugin will read docker tags from a .tags file in the root of your repository, which can be generated on the fly.
pipeline:
build:
image: golang
commands:
- go build
- echo ${DRONE_COMMIT:0:8} > .tags
publish:
image: plugins/docker
repo: octocat/hello-world
Not all plugins provide the option to read parameters from file. It is up to the plugin author to include this capability. If the plugin does not have this capability, or it is not something the plugin author is planning to implement, you can always fork and adjust the plugin to meet your exact needs.
[1] https://github.com/drone-plugins/drone-docker

Unable to specify .nsolid-proxyrc for Nsolid Proxy is causing issues

We have a situation where we want to be able to start the Nsolid Proxy/Hub from an arbitrary folder. When we try to do this it fails due to not being able to find .nsolid-proxyrc in one of the parent folders.
We took a look at the source code for Nsolid Proxy and it looks like the library it is using, rc, allows end-users to specify a file location, but Nsolid Proxy doesn't accept a CLI argument that allows us to specify it. It should be functionality that is easy to add, but it appears to be a closed source project.
TL:DR; We need to be able to specify the exact location of .nsolid-proxyrc when starting the hub. Is there a known work-around for this or is there a way we could request this feature gets added to the project?
You can specify the configuration file by using the --config flag (from rc) when starting N|Solid Proxy
$ nsolid proxy.js --config /path/to/config/file
By default it will look at the current working directory and then up the folder tree like node_modules then resort to the following locations:
$HOME/.nsolid-proxyrc
$HOME/.nsolid-proxy/config
$HOME/.config/.nsolid-proxy
$HOME/.config/.nsolid-proxy/config
/etc/nsolid-proxyrc
/etc/nsolid-proxy/config

Pass runtime arguments to grails project on tomcat server

I'm trying to pass in a variable at runtime to my application to configure where my external config files are stored.
I need external config files so that the config can be changed without having to deploy a new release every time the config changes, and want to be able to define the location of these at run time so the applications is more portable and the team deploying the application can follow their existing rules on where to store config.
I have read answers like this:
How to add custom "-Djava" arguments to Grails app? - but I'm not sure how this relates to me from the point of having the war file on my local machine, to deploying this with the param being passed in. I have been using the Tomcat Web Application Manager to simply select the war file to upload, and clicking delpoy - the file is uploaded and automatically exploded out and launched.
https://grails.github.io/grails-doc/latest/ref/Command%20Line/war.html - This suggests that the arguments have to passed in at the point of creating the war file which is not what I'm after.
In my code I have:
grails.config.locations = ["${System.properties['configFolder']}/application-config.properties"]
and I am looking for a way to include arguments when deploying from the Application Manager, or a command something like
deploy myApp.war -DconfigFolder="/usr/share/tomcat5/.grails/myApp/conf/application-config.properties"
EDIT
Turns out you're meant to pass in the runtime parameters when you start the tomcat server (or just after), not when you deploy the application.
The command needed is:
export CATALINA_OPTS="-DconfigLocation=/usr/share/tomcat5/.grails/TAPaS/"
or whatever params/values you want.
This can either be entered manually once the server has been started, or you can create a setenv.sh file containing that command within the CATALINA_HOME directory. This can be found out using the echo $CATALINA_HOME. Another way to find it is to use the start command below, and view the response, e.g.
bash catalina.sh start
Using CATALINA_BASE: /opt/apache-tomcat-7.0.61
Using CATALINA_HOME: /opt/apache-tomcat-7.0.61
Using CATALINA_TMPDIR: /opt/apache-tomcat-7.0.61/temp
Using JRE_HOME: /usr
Using CLASSPATH: /opt/apache-tomcat-7.0.61/bin/bootstrap.jar:/opt/apache-tomcat-7.0.61/bin/tomcat-juli.jar
If you have added the command to the setenv.sh file, use the command bash catalina.sh start to start the server. bash catalina.sh stop is used to stop it. You will need to use the path to .sh file if you're not in the directory of them.
As far as I can work out, this is not possible.
Whenever a .war file is dropped into the appBase
if autoDeploy attribute is "true" then the application will automatically be deployed while the Tomcat server is running
else, the application will be deployed when there Tomcat server is started
bash /opt/apache-tomcat-7.0.61/bin/shutdown.sh
bash /opt/apache-tomcat-7.0.61/bin/startup.sh
will shutdown and the start up the server again and any .war files that are in the appBase will be deployed.
The only instance I can see where an actual command is needed to deploy is when using the Client Deployer Package. More information on Tomcat Deployment found at: https://tomcat.apache.org/tomcat-8.0-doc/deployer-howto.html

Relatively where does solr.data.dir in solrconfig.xml points to?

In all configuration below, a prefix of "solr." for class names
is an alias that causes solr to search appropriate packages,
including org.apache.solr.(search|update|request|core|analysis)
You may also specify a fully qualified Java classname if you
have your own custom plugins.
This is what I found while going through the solrconfig.xml file. But it seems this is defined to point to the respective classes in solr. I know somehow SOLR_HOME is used for solr.data.dir. I have used solr using "start.jar" and also using "solr-**-*.war" on Tomcat. It just works !!! :)
So where does solr.data.dir points to ?
Where exactly is SOLR_HOME is defined ?
So where does solr.data.dir points to?
The dataDir parameter is used to specify the directory for storing all index data. If this directory is not absolute, then it is relative to the directory where you started Solr. If the folder is empty, the new index would be re-created automatically when starting Solr.
Where exactly is SOLR_HOME is defined?
It really depends on operating system and web server used. And it defines the home directory of your Solr.
The most commonly it could be defined either:
in startup files,
using system environment variables, e.g.:
export JAVA_OPTS="$JAVA_OPTS -Dsolr.solr.home=/opt/solr/example"
during runtime as part of JAVA_OPTS (on Debian, in /etc/default/tomcat7 for instance, format: -Dmy.prop=value),
using System property substitution file (core.properties/solrcore.properties),
using Tomcat Context Configuration (e.g. in conf/Catalina/localhost by solr/home),
per Solr instance in solr.xml (instanceDir).
Best is to specify it explicitly.
You can modify tomcat/bin/catalina.sh to add following JVM option:
-Dsolr.solr.home=/home/mdhussain/solr-test/deployment/solr1
Data directory is relative to solr home, you can override this in solrconfig.xml.
If you are running on a MAC it's default installation directory (including data)
- if installed via maven dependency at least - is in the /var/XXX directory.
cd /var
grep --color -iHrn solr .
Example on my machine for the index data location:
/var/folders/1j/z7f1373977s_qlfvv9t71kmh0000gq/T/solr-7.3.1/solr-7.3.1/server/solr/cores/catalog_reindex/data