I'm using the SaltStack mysql-formula and the defaults work just fine except for the root password.
Rather than try the pillar I thought this should work:
sudo salt 'ip-172-31-20-106.ec2.internal' state.sls mysql pillar="{'mysql:server:root_password':'Password'}" >
But no joy. I hacked on debconfmod.py to display the password but no luck there.
Should this work and if so how?
Thanks.
Turns out I screwed-up the yml conversion into json.
The pillar yml is
mysql:
server:
root_password: 'somepass'
So the pillar json should be
pillar="{'mysql':{'server':{'root_password':'somepass'}}}"
Now everything works as it should.
Related
All of our salt scripts are located in /srv/salt/ and /srv/pillar/ directories and they are synced with SVN.
In salt configuration file (/etc/salt/master) I have defined the file_roots and pillar_roots as below so once any salt command is executed, it uses these paths.
file_roots:
base:
- /srv/salt/
pillar_roots:
base:
- /srv/pillar/
I want to create a new directory and duplicate all the scripts there (/srv/salt_test/salt/ and /srv/salt_test/pillar/) for test.
Is there any way that I can pass parameters to salt command to force it to use these test path? Something like:
$salt file_roots=/srv/salt_test/salt/ pillar_roots=/srv/salt_test/pillar/ servername.domain.com state.sls weblogic.install
Thanks a lot in advance.
I found the solution and would like to share it here:
I've updated /etc/salt/master as below:
file_roots:
base:
- /srv/salt/
test:
- /srv/salt_test/
pillar_roots:
base:
- /srv/pillar/
test:
- /srv/pillar_test/
Then restarted salt on master and minions. Now I can use saltEnv=test pillarEnv=test options to force salt master to read scripts from /srv/pillar_test/ and /srv/salt_test/
Sample:
$salt minion.domain.com state.sls weblogic.install saltEnv=test pillarEnv=test
Hope it will be useful for someone else.
I'm trying to create a win repo within my isolated environment.
At the /etc/salt/master I added the lines:
winrepo_dir_ng: repo
winrepo_insecure_auth: True
winrepo_cachefile: winrepo.p
On the minion configuration file (a windows minion):
winrepo: salt-master://win/repo
winrepo_cachefile: 'c:/salt/repo/cache'
Of course after that I used the following commands:
salt-run winrepo.genrepo
returns the sls content
salt '*' pkg.refresh_db
returns empty line (should be 'true').
When I try "salt '*' pkg.install notepad" it returns "unable to locate package notepad".
Where am I wrong?
comment out all those lines you've configured in your master and minion configs. The defaults should all work fine.
I get this error when I create a new module:
"Please upgrade your database: Run "bin/magento setup:upgrade" from the Magento root directory.
The following modules are outdated:
Sangeeta_Octan data: current version - none, required version - 0.0.1";i:1;s:1781:"#0
I searched on google and found no solution other than reinstalling Magento. Such as:
version has been changed from "2.0.0.0" to "2.0.0" during development,
so update tool can't recognize that "2.0.0.0" <= "2.0.0". Please,
re-install your application from scratch to get latest version. `
Do I have any options apart from reinstalling?
Change the setup_version of your module (Sangeeta_Octan) in
app/code/Sangeeta/Octan/etc/module.xml. Try a different version
name like setup_version="2.0.1" or setup_version="3.0.0"
Run bin/magento setup:upgrade
If that doesn't work, disable your module by changing your module name in app/etc/config.phpfrom Sangeeta_Octan => 1 to Sangeeta_Octan => 0. Then run bin/magento setup:upgrade
I hope below solution also solve your problem.
https://magento.stackexchange.com/questions/112293/mysql-error-and-possible-duplicates-running-bin-magento-setupupgrade-after-rena/112299#112299
in mysql find the table setup_module It will have 3 fields. Find the NULL values in data_version & have them match the schema_version
As an alternative, you can access your magento database and look at the table setup_module
You will see a list of all installed modules and you can manually set the schema/data version numbers here.
Delete the offending rows from the setup_module table (if they are there) and run the command bin/magento setup:upgrade from your Magento 2 root directory.
This is happens because of something wrong while running "bin/magento setup:upgrade" and the data_version in Module versions registry is null. It is loaded from DB, We can just proceed by manually changing it in db.
Go db via php myadmin and check "setup_module" table, the
data_version which are mentioned "null".
Login to Mysql database => then update table setup_module of the "data_version" column same as "schema_version"
I would like to set the configuration of my symfony2 project using environment variables.
In the server I have defined:
SYMFONY__DATABASE__USER
SYMFONY__DATABASE__PASSWORD
SYMFONY__DATABASE__NAME
SYMFONY__DATABASE__HOST
SYMFONY__DATABASE__DRIVER
My parameters.yml.dist looks like this:
#app/config/parameters.yml.dist
parameters:
database_host: "%database.host%"
database_port: ~
database_name: "%database.name%"
database_user: "%database.user%"
database_password: "%database.password%"
database_driver: "%database.driver%"
when I run composer I get an exception
composer install --dev --no-interaction --prefer-source
[Symfony\Component\DependencyInjection\Exception\ParameterNotFoundException]
You have requested a non-existent parameter "database.driver". Did you mean one of these: "database_user", "database_driver"?
These variables are defined in the server so I can modify the parameters.yml.dist to define these values. But this does not seams the right way, because wat I really want to use are the environment variables.
Note: I want to read this environment variables in travis, heroku and my vagrant machine. I only want to have in the repository the vagrant machine variables.
Which is the proper way to do this?
How should look my parameters.yml.dist?
Looks you are doing everything okay.
Here is the complete documentation for Setting Environment Variables which I believe you already read.
What is important to note is this:
Also, in order for your console to work (which does not use Apache),
you must export these as shell variables. On a Unix system, you can
run the following:
$ export SYMFONY__DATABASE__USER=user
$ export SYMFONY__DATABASE__PASSWORD=secret
I remember once I have a similar issue, I was setting everything on APACHE, but when running commands it wasn't working because I forgot to EXPORT the variables on the system.
Be aware that using export is a temp solution, if you reset your server those values will be lost, you will need to setup in a permanent way according to your OS.
I think you solved this long time ago, but the problem is actually that you have 2 _ between DATABASE and USER and the parser for this have a string replace function that replaces every __ with a . .
For your example to work you should have written like this:
SYMFONY__DATABASE_USER -> database_user
SYMFONY__DATABASE__USER -> database.user
You can try this bundle if your system version is >= 2.6.2:
This bundle provides a way to read parameters from environment
variables at runtime. The value defined in the container parameter is
used as fallback when the environment variable is not available.
New to salt,and i add first server(wx-1),it works ,but when i add a differnt server, test.ping is ok,but when execute salt 'qing' state.highstate, it fails,the error info is:
No Top file or external nodes data matches found
Here is my top.sls:
base:
'wx-1':
- bin.nginx
- git
- web
- mongo
- redis
'qing':
- bin.nginx
qing is a new server and it's config is different to wx-1,don't know if this is ok,thanks for your help:)
If you make changes to your sls files. Make sure that you restart the master in order for it to update. This solved my problem when receiving the same error...
You didn't give much information. But here are a few things to check:
test if salt qing state.sls bin.nginx works, if not continue reading
make sure file_roots:base in master config points to /srv/salt
use salt-master/minion --version to check salt versions, make sure they are the same. Because different versions might diff
Give further info if you tried all the above.