You know how Laravel allows for environment based configurations? Where config files in "app/config/local" override those in "app/config". All my config files in the "local" directory override as expected, except the config file: "database.php"
I want to be able to specify different database connections for local and production environment. But when I do, and run "artisan migrate --env=local" it still attempts to use the configuration in the production folder, not the "local" folder.
This sometimes get a bit confusing on local environements. I normally use the hostname in bootstrap/start.php as opposed to the IP.
For example my Virtual Box Localhost's hostname is "debian"... just type hostname in your terminal to get the hostname.
This should work. However, since you're using environment config folders (which I always do) then I would remove the settings in the app/congig/* as you should never need them since your other servers will have their own settings in app/config/yourenv
Hope this helps
Related
im new in CI4 i would like to create setup database by CI4 it is possible write db connection data to .env file by controller or some services CI4?
Also want when complete setup change environment in .env that user cant access setup.
If its not correct solution can some one tell how to do it best way?
im using CI 4.0.2
In app/Config/Database.php you can set up multiple possible databases and from there you can depend them on specific environment.
By default you have 2 set up databases - default and tests. If env is set to tests it will load tests database settings, else will load default. You can expand it by adding more possible environments.
As in env file, there is section DATABASE, you can edit them there.
I have 2 buckets prod and dev.
Inside .env I have S3_PROD and S3_DEV.
I want my system to point to S3_DEV when I am in my dev environment.
Taking consideration that I could have 10 variables to be pointed to a specific endpoint based on our environment what should be the best approach
to set that?
You're .env file should not be tracked by whatever deployment/versioning system you have. Ideally your dev environment file would contain the keys appropriate and in your config you would simply call env('S3_REGION') for example.
But for the sake of bad ideas lets say you have almost identical .env files in your dev environment and your production, change the APP_ENV=local to dev or prod and then an if statement in your config.
I would highly recommend you follow the documentation on this.
Your .env file should not be committed to your application's source
control, since each developer / server using your application could
require a different environment configuration. Furthermore, this would
be a security risk in the event an intruder gains access to your
source control repository, since any sensitive credentials would get
exposed.
If you are developing with a team, you may wish to continue including
a .env.example file with your application. By putting placeholder
values in the example configuration file, other developers on your
team can clearly see which environment variables are needed to run
your application. You may also create a .env.testing file. This file
will override the .env file when running PHPUnit tests or executing
Artisan commands with the --env=testing option.
Heroku provides its own database name and other credentials, but my local database name is different.How can I change the database name according to the database credentials provided by heroku during production?
Use a package like dotenv. dotenv and variants of it likely exist for whatever language you're using.
Basically, you want to use environment variables instead of hard coding values into your code. So, instead of writing something like this:
my_database_connect('my_username', 'abc123')
You'd write:
my_database_connect(process.env.DB_USERNAME, process.env.DB_PASSWORD)
Heroku will already have these environment variables set on the "config" tab of your app. Then for local development, you'll create a file called .env and have this text in it:
DB_USERNAME=my_username
DB_PASSWORD=abc123
Don't commit .env to your git repository – it should only live on your machine where you develop. Now your code will run locally as well as on Heroku, and connect to the proper database depending on the environment it's running in.
Here's an article that explains this more thoroughly for node.js, although this is basically the best practice for general development: https://medium.com/#rafaelvidaurre/managing-environment-variables-in-node-js-2cb45a55195f
First I created an application name on Heroku. Then I deployed my app to heroku by connecting to github.
Heroku provides the database credentials after we deploy our applications. Then I redeployed the app through github by changing the configuration in application.properties file as follows:
#localhost configuration
SPRING_DATASOURCE_DRIVER_CLASS_NAME=org.postgresql.Driver
SPRING_DATASOURCE_URL=jdbc:postgresql://localhost/transactions?useSSL=false
SPRING_DATASOURCE_USER=postgres
SPRING_DATASOURCE_PASSWORD=some_pass
#server database configuration
SPRING_DATASOURCE_DRIVER_CLASS_NAME=org.postgresql.Driver
SPRING_DATASOURCE_URL=jdbc:postgresql://ec2-23-23-247-222.compute-1.amazonaws.com/d6kk9c4s7onnu?useSSL=false
SPRING_DATASOURCE_USER=rimjvlxrdswwou
SPRING_DATASOURCE_PASSWORD=dd903753bc0adffb96ce541b1d55fb043472e32e28031ddc334175066aa42f69
Then you have to edit the config vars according to your application.properties files as shown in the figure below
config_var.png
I am confused about how Laravel protects keys using environment variables. It seems to me that a hacker could just look through the environment variables or at the hidden file. How is this better than storing it in the default array. Does Laravel do something with the environment variable to make this more secure? Or is it just a way to separate keys for different configurations.
I tried searching for an answer but I only found a non-Laravel question of the same nature that didn't seem to have a good answer either.
The configuration file is not meant to be stored in source control. This means the sensitive data is never stored anywhere it does not need to be. If a hacker were to gain access to your repository, they wouldn't be able to access for example; your database password.
This configuration file will placed upon deployment or once manually (eg ssh) into the project for the application to access.
Web server rewrites (apache .htaccess) or NGINX config will ensure that this configuration file can never be directly accessed.
If a hacker gets access to your server via an exploit or another method, they will still be able to access the configuration file.
Security is about having multiple layers, and removing this sensitive data from source control is one of many.
At the bottom of the configuration section in the laravel docs it mentions this very briefly:
Be sure to add the .env.local.php file to your .gitignore file. This
will allow other developers on your team to create their own local
environment configuration, as well as hide your sensitive
configuration items from source control.
Now, on your production server, create a .env.php file in your project
root that contains the corresponding values for your production
environment. Like the .env.local.php file, the production .env.php
file should never be included in source control.
I'm trying to do some clustering testing and I am setting up multiple RabbitMQ services on a single Windows machine. I am able to set the environment variables RABBITMQ_NODENAME, RABBITMQ_SERVICENAME, and RABBITMQ_NODE_PORT then run RabbitMQ-Service Install to have a new RabbitMQ service installed under a different name.
My question is regarding the configuration file. Based on what I read on the RabbitMQ site, the configuration file defaults to the %AppData%\RabbitMQ directory.
I'm just having trouble trying to understand how it should be setup so I can have 3 instances of the service running with their own configuration.
Do I run the installation under a different local or domain account so it gets placed under a different %AppData%\RabbitMQ directory or can I add a directive to the service to look in a particular directory for the configuration file for that particular service?
Also, how does RABBITMQ_BASE come into play? Is that only for data and log files or does that also apply to the configuration file? I'm not sure if once I have the service setup with BASE defined as a specific path I can place a new rabbitmq.config under the root of that path.
Please confirm and provide any additional assistance. Thank you in advance!
For now I'm testing on Windows but I plan on converting to linux once I have this all working correctly and understood. Unfortunately, I've inherited the current environment and it's already installed and running using Windows servers. They just wanted me to setup clustering for it so I'm trying to simulate the cluster on my workstation.
Nevermind, I found out what I needed. The environment variable RABBITMQ_CONFIG_FILE can be used to override the location of the default config file.
http://www.rabbitmq.com/relocate.html
You can run multiple RabbitMQ instances on 1 machine without clustering. You just need to change the ports and the node name in rabbitmq-defaults, rabbitmq-env and config files. If you want them as a service you can just create them from the already configured instances.
HERE is a detailed guide on how to do that. It's pretty easy and straightforward.