I've have a Rails app that loads a number of RSA certificates before a transaction is made with Paypal. On my development machine, these certificates are read from files in the file system but because Heroku (which I'm using for delpoyment) is largely read-only, I can't upload these files so I'm guessing I'll have to read the certificates from config variables (see Heroku Config Vars).
Because the certificates consist of multiple lines of data, I'm not sure how to set them as variables or even if this is possible. Does anyone know how I could do this or be able to suggest an alternative approach?
Many thanks,
Eddie
I found that a easy way to add multi-line configs is to double quote them and then echo them from my local environment
heroku config:add EC2_PRIVATE_KEY="$EC2_PRIVATE_KEY"
If you want to set Heroku config values from your file contents, you can use the following shell trick:
$ heroku config:set SECRET_KEY="$(cat path/to/secret.key)"
Multi-line values can be set directly by putting quotes around the value:
$ heroku config:set SECRET_KEY='first line
> second line'
If you're using Foreman to run locally (now heroku local), it doesn't support multi-line variables. You must use something to inject them into the environment first, such as envdir:
$ envdir my-env-dir heroku local
Or you can just go to the Settings tab of the Heroku dashboard, open Config Vars and paste it in.
Easy peasy.
We needed to do the same thing.
You can wrap the variable value in double quotes:
bobvila#bobuntu:~/svnroot/app/myapp$ heroku config:add woodchuck="How much wood
> could a woodchuck chuck
> if a woodchuck could chuck wood"
Adding config vars and restarting myapp... done, v25
woodchuck: How much wood
could a woodchuck chuck
if a woodchuck could chuck wood
bobvila#bobuntu:~/svnroot/app/myapp$ heroku config
=== Config Vars for myapp
woodchuck: How much wood
could a woodchuck chuck
if a woodchuck could chuck wood
bobvila#bobuntu:~/svnroot/app/myapp$
If you're using Foreman for localhost development, the .env file doesn't support multi-line variables so you'll need to export it to the shell before launching Foreman
My answer comes a bit late but I had the same issue recently with multi-line env. variables on Heroku.
My solution was to use strict_encode64:
encoded_secret = Base64.strict_encode64("my_multi_line_secret")
add the key:
$ heroku config:set SECRET_KEY='the encoded_secret string here'
In the code, you then decode it using Base64.strict_decode64(ENV['SECRET_KEY'])
An example of how to deal with this problem using NodeJS. Sanitize the value by replacing \\n characters with \n:
process.env.FIREBASE_PRIVATE_KEY.replace(/\\n/g, '\n')
Taken from:
Escaping issue with firebase privateKey as a Heroku config variable
I know this is a very manual way of doing it, but what worked for me is to paste the private key into a text editor, find and replace \n with an actual line break and paste that as the value for the env var in Heroku.
Related
Running the Config Wizard via the start menu (Windows 7) simply fails. Running it from the command prompt shows the infamous
'C:\Program' is not recognized as an internal or external command, operable program or batch file
I know this is due to the space in "Program Files" (dir C:\pro* /x doesn't show C:\Progra~1).
The solution I've found for this is to replace C:\Program Files\... with "C:\Program Files\...".
My question is this:
Since the WebLogic config wizard runs from config.cmd, which is loaded with variables for path names, do I have to update Windows system environment variable PATH and put quotes around all path names that have a space (since I don't know what WebLogic is looking for)?
Update:
I tried this and received Files was unexpected at this time. Which made me think I was off with the quotes, but they are paired properly around every path with C:\Program Files. A search on this error resulted with this advice...basically the double quotes are the cause.
If the lack of quotes causes the first problem, and the presence of quotes causes the second problem, what to do? It's a loop...
I installed another JDK in a location with no spaces (still got the error because I didn't change any environment variables because work site will change them back, breaking things).
The install docs in chapter 4 say:
To begin domain configuration, navigate to the
ORACLE_HOME/oracle_common/common/bin directory and start the
Configuration Wizard.
On UNIX operating systems:
./config.sh
On Microsoft Windows operating systems:
.\config.cmd
Which implied at a command prompt (to me anyways). I was reading another site for help and the guy said to update config.cmd to point it to new JDK location instead of JAVA_HOME.
Instead of right clicking on config.cmd to edit it I double clicked it and lo and behold...this nice domain creator GUI opened up where I could specify which JDK to use. Done! No errors...
If that little tidbit were in the docs it would've save me a lot of time and frustration. And no, I'm not a server admin type, just a dev who needed a local web server for testing purposes.
I hope this helps someone.
I have several EB applications that I would like to convert from a classic to an application load balancer. In the documentation it seems that the default way is to create a new environment from scratch with the proper load balancer. Considering that I have many environment variables and several environments, I would prefer not to have to rebuild applications. Is there a way to switch out the load balancer on an already running application?
It is not possible to set a a load balancer type except at creation time. You can use elastic beanstalk cli and aws cli to clone the application with the same config and version. To get the deployed application version run:
aws elasticbeanstalk describe-environments --application-name ${APPLICATION_NAME} --environment-names ${SRC_ENV_NAME} | jq -r '.Environments | .[] | .VersionLabel'
The jq pipe filters out the rest of the json blob.
After that, you can save the config of the curent appication using:
eb config save $SRC_ENV_NAME --cfg "${SRC_ENV_NAME}_save"
Then create an application clone using:
eb create $NEW_ENV_NAME --elb-type application --cfg "${SRC_ENV_NAME}_save" --version $APP_VERSION
Where APP_VERSION is the string extracted in step one.
It is not simple, but it can be done.
If the Envivornment name is important to you, it gets a little trickier.
Here is it how it should go, step by step (using the web console):
Save the configuration of the Environment you want to change
From the Saved config, generate a new Env (select Customize settings)
2.1) Change the LB type to Application and fill out all the necessary info for this
Swap the URLs from the original env to the new one (check if everything is working with the new env, if not swap back)
[STEPS ONLY NECESSARY IF ENV NAME IS IMPORTANT]
Delete the original env (which now is not receiving traffic and has a Classic LB)
Wait until the original name disappears from the console (it make take a couple of hours)
Clone the production env, and give the new env the original env name
Swap URLs
Done!
I'm going through the "Getting Started with Openshift" guide trying to learn this stuff. I have successfully added and configured a postgres db in my python gear.
If I run an env on the gear itself, I see the database environment variables:
[]\> env |grep POSTGRESQL_DB
OPENSHIFT_POSTGRESQL_DB_HOST=x.x.x.x
OPENSHIFT_POSTGRESQL_DB_USERNAME=admindb
OPENSHIFT_POSTGRESQL_DB_PORT=5432
But in my deployed code, I dump all the env variables with logging.error(os.environ) and none of the POSTGRESQL_DB variables are set. All the python ones seem to load properly.
I know I could set these vars manually, but since these vars are controlled by the gear they could become stale. The documentation implies that these variables should be set (they are used in the sample code).
Found the problem.
In the instructions we set a hot_deploy marker (so the application doesn't bounce when code changes are committed). The next step in the instructions is to add the postgres cartridge, but the environment variables won't load until the cartridge is restarted. So bounce the application and all is well.
Thanks,
Ryan
Is your deployed code running through the same logged-in shell environment as you log in with?
A common solution to making code see shell environment variables that are launched via some non-shell method is to launch them through a login shell.
For example:
/bin/bash -lc "/whatever/you/are/launching --args stuff"
I have an application in Openshift free plan with only one gear. I want to change it to scalabe and take usage of all of 3 free gears.
I read this blog post from openshift and I found that there is a way to do it. I should clone my current application to a new one as a scalable which will use the 2 remaining gears and then I will delete the original application. Thus, the new one will have 3 free gears.
The way that blog suggest is: rhc create-app <clone> --from-app <existing> --scaling
I have the following error: invalid option --from-app
Update
After running the command gem update rhc, I don't have the error above but...A new application with the given name has created with the same starting package (Python 2.7) just like the existing one, but all the files are missing. It actually create a blank application and not a clone of the existing.
Update 2
Here is the structure of the folder:
-.git
-.openshift
-wsgi
---static
---views
---application
---main.py
-requirements.txt
-setup.py
From what we've talked on IRC, your problem was around missing SSH configuration on Windows machine:
Creating application xxx ... done
Waiting for your DNS name to be available ...done
Setting deployment configuration ... done
No system SSH available. Please use the --ssh option to specify the path to your SSH executable, or install SSH.
I've double checked it, and it appears to be working without any problem.
The only requirement is to have the latest rhc client and putty or any other
SSH client. I'd recommend going through this tutorial once again and double-check everything to make sure everything is working properly.
Make sure you are using the newest version of the rhc gem with "gem update rhc" to make sure that you have access to that feature from the command line.
The --from-app will essentially do a 'rhc snapshot save & snapshot restore` (amoung other things) as you can see here from the source:
if from_app
say "Setting deployment configuration ... "
rest_app.configure({:auto_deploy => from_app.auto_deploy, :keep_deployments => from_app.keep_deployments , :deployment_branch => from_app.deployment_branch, :deployment_type => from_app.deployment_type})
success 'done'
snapshot_filename = temporary_snapshot_filename(from_app.name)
save_snapshot(from_app, snapshot_filename)
restore_snapshot(rest_app, snapshot_filename)
File.delete(snapshot_filename) if File.exist?(snapshot_filename)
paragraph { warn "The application '#{from_app.name}' has aliases set which were not copied. Please configure the aliases of your new application manually." } unless from_app.aliases.empty?
end
However this will not copy over anything in your $OPENSHIFT_DATA_DIR directory so if you're storing files there, you'll need to copy them over manually.
I've created a few different "environments" for my app that is hosted on heroku so I have:
appName-staging.heroku.com
appName-production.heroku.com
I want to use different google api keys for these applications, how do I do this?
i've created a google.yml file that looks like:
development:
api_key: 'ABCXYZ'
production:
api_key: 'DEFXYZ'
so I use ABCSZY when developing locally, and DEFXYZ for appName-production.heroku.com
question is, how do i get appName-staging.heroku.com to use a different key?
since every application deployed to Heroku is considered to be in "production", both
appName-staging.heroku.com and appName-production.heroku.com use the same key.
You could add a heroku config variable to each environment, allowing you to identify each one from within the app.
Something along the lines of:
$ heroku config:add APP_NAME_ENV=production --app appName-production
$ heroku config:add APP_NAME_ENV=staging --app appName-staging
Then you could grab the current environment from within your app using:
ENV['APP_NAME_ENV']
And if you've got your YAML file as a hash called something like GOOGLE_KEYS, the following would return the correct key for a given environment:
GOOGLE_KEYS[ENV['APP_NAME_ENV']]
The previous answer definitely works but doesn't account for the potential security threats which come with checking files which include private keys into source control. Having your google.yml file in source control will allow anyone with access to your repo to see your private API keys.
A more secure solution would be to delete the google.yml file and create different environment variables on your staging and production servers with the same key:
$ heroku config:add GOOGLE_API_KEY=<production key> --app appName-production
$ heroku config:add GOOGLE_API_KEY=<development key> --app appName-staging
Then, when this is needed you can refer to it in code via
ENV['GOOGLE_API_KEY']
This will allow you to share code without sharing your private API keys.
Some more information on using environment variables on Heroku can be found at https://devcenter.heroku.com/articles/config-vars