[GitHub] cloudstack issue #1621: Fix a little issue from PR1610 if the db.properties ...

2016-08-02 Thread milamberspace
Github user milamberspace commented on the issue:

https://github.com/apache/cloudstack/pull/1621
  
Jira ticket done.
CLOUDSTACK-6671


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


[GitHub] cloudstack issue #1621: Fix a little issue from PR1610 if the db.properties ...

2016-08-02 Thread karuturi
Github user karuturi commented on the issue:

https://github.com/apache/cloudstack/pull/1621
  
We dont need a PR for master. It will be forward merged. 
If you can create a jira ticket for this (even better would be to reuse the 
one used in PR1610), it will be useful.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


[GitHub] cloudstack issue #1621: Fix a little issue from PR1610 if the db.properties ...

2016-08-02 Thread wido
Github user wido commented on the issue:

https://github.com/apache/cloudstack/pull/1621
  
LGTM!

Thanks for the fix. Could you also open one for master? It needs to be 
fixed there as well.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


[GitHub] cloudstack issue #1621: Fix a little issue from PR1610 if the db.properties ...

2016-08-02 Thread rhtyd
Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1621
  
LGTM thanks @milamberspace 


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


Re: CloudStack DB Backup Script - Fetching mysql details from db.properties

2015-03-19 Thread Pierre-Luc Dion
That's nice! it would be triggered only when upgrade of DB occur while
upgrading a release, right? not everytime a cloudstack-management server is
restarted?
Where would you dump db files?




On Tue, Mar 17, 2015 at 1:10 PM, ilya ilya.mailing.li...@gmail.com wrote:

 It would be ideal if we can make this or similar script as part of
 cloudstack upgrade procedure i.e. create backups before start!


 CloudStack DB Backup Script - Fetching mysql details from db.properties



 #!/bin/bash
 DBNAMES=cloud cloud_usage cloudbridge
 DATE=$(date +%m%d%y-%H%M%S)
 DBPASS=$(java -classpath /usr/share/cloudstack-common/lib/jasypt-1.9.0.jar
 org.jasypt.intf.cli.JasyptPBEStringDecryptionCLI input=$(cat
 /etc/cloudstack/management/db.properties | grep db.cloud.password | awk
 -F'(' '{print $2}' | sed 's/)//g') password=$(cat
 /etc/cloudstack/management/key) | grep -A2 OUTPUT | tail -1)
 #Assuming that cloud user can access all 3 dbs
 DBHOST=$(cat /etc/cloudstack/management/db.properties | grep
 db.cloud.host | awk -F'=' '{print $2}' | tail -1 )
 DBUSER=$(cat /etc/cloudstack/management/db.properties | grep
 db.cloud.username | awk -F'=' '{print $2}')
 DB=$(cat /etc/cloudstack/management/db.properties | grep db.cloud.name |
 awk -F'=' '{print $2}')
 DBPORT=$(cat /etc/cloudstack/management/db.properties | grep
 db.cloud.port | awk -F'=' '{print $2}')
 #echo $DBPASS $DBHOST $DBUSER $DB $DBPORT
 for DB in $DBNAMES
 do
 printf Backing up DB $DB, please wait  
 mysqldump -h $DBHOST -u $DBUSER -P $DBPORT -p$DBPASS $DB
 $DB.$(hostname -s).$DATE.sql  echo done || echo error!
 done
 echo -e  \nCompressing all files into single tar.gz -
 all-cloud-dbs.$(hostname -s).$DATE.sql.tgz file ...
 tar -zcvf all-cloud-dbs.$(hostname -s).$DATE.sql.tgz *$(hostname
 -s).$DATE.sql  echo -e done\n || echo -e error!\n
 printf Cleaning up  
 rm -rf *$(hostname -s).$DATE.sql  echo -e done\n || echo error!\n



CloudStack DB Backup Script - Fetching mysql details from db.properties

2015-03-17 Thread ilya
It would be ideal if we can make this or similar script as part of 
cloudstack upgrade procedure i.e. create backups before start!



CloudStack DB Backup Script - Fetching mysql details from db.properties



#!/bin/bash
DBNAMES=cloud cloud_usage cloudbridge
DATE=$(date +%m%d%y-%H%M%S)
DBPASS=$(java -classpath 
/usr/share/cloudstack-common/lib/jasypt-1.9.0.jar 
org.jasypt.intf.cli.JasyptPBEStringDecryptionCLI input=$(cat 
/etc/cloudstack/management/db.properties | grep db.cloud.password | awk 
-F'(' '{print $2}' | sed 's/)//g') password=$(cat 
/etc/cloudstack/management/key) | grep -A2 OUTPUT | tail -1)

#Assuming that cloud user can access all 3 dbs
DBHOST=$(cat /etc/cloudstack/management/db.properties | grep 
db.cloud.host | awk -F'=' '{print $2}' | tail -1 )
DBUSER=$(cat /etc/cloudstack/management/db.properties | grep 
db.cloud.username | awk -F'=' '{print $2}')
DB=$(cat /etc/cloudstack/management/db.properties | grep db.cloud.name | 
awk -F'=' '{print $2}')
DBPORT=$(cat /etc/cloudstack/management/db.properties | grep 
db.cloud.port | awk -F'=' '{print $2}')

#echo $DBPASS $DBHOST $DBUSER $DB $DBPORT
for DB in $DBNAMES
do
printf Backing up DB $DB, please wait  
mysqldump -h $DBHOST -u $DBUSER -P $DBPORT -p$DBPASS 
$DB $DB.$(hostname -s).$DATE.sql  echo done || echo error!

done
echo -e  \nCompressing all files into single tar.gz - 
all-cloud-dbs.$(hostname -s).$DATE.sql.tgz file ...
tar -zcvf all-cloud-dbs.$(hostname -s).$DATE.sql.tgz *$(hostname 
-s).$DATE.sql  echo -e done\n || echo -e error!\n

printf Cleaning up  
rm -rf *$(hostname -s).$DATE.sql  echo -e done\n || echo error!\n


Re: db.properties confused

2015-03-07 Thread Daan Hoogland
Laszlo, I didn't think twice about this but we had that in a prior
version as well. It is not specific to 4.6. Did you upgrade this
environment?

On Fri, Mar 6, 2015 at 6:28 AM, Laszlo Hornyak laszlo.horn...@gmail.com wrote:
 Hi,

 After cloudstack-setup (4.6, latest) I looked into the db.properties file
 and I have found that the comment lines got mixed into the actual content.
 Anyone met this problem?

 

 # Licensed to the Apache Software Foundation (ASF) under one
 db.usage.maxActive=100
 # or more contributor license agreements.  See the NOTICE file

 # distributed with this work for additional information


 db.cloud.name=cloud
 # with the License.  You may obtain a copy of the License at
 db.cloud.password=ENC(let's skip this part..., but anyways)
 # software distributed under the License is distributed on an

 #   http://www.apache.org/licenses/LICENSE-2.0
 # to you under the Apache License, Version 2.0 (the



 # Unless required by applicable law or agreed to in writing,
 # specific language governing permissions and limitations

 # License); you may not use this file except in compliance


 # KIND, either express or implied.  See the License for the
 db.usage.maxWait=1
 # High Availability And Cluster Properties
 db.usage.maxIdle=30
 # CloudStack database settings
 db.cloud.autoReconnectForPools=true
 db.cloud.trustStore=
 db.awsapi.host=localhost
 # in which the management server(Tomcat) is running
 db.usage.name=cloud_usage
 # regarding copyright ownership.  The ASF licenses this file
 # usage database tuning parameters
 db.cloud.poolPreparedStatements=false


 --

 EOF



-- 
Daan


Re: db.properties confused

2015-03-07 Thread Laszlo Hornyak
Hi Daan,

No, I installed a clean environment.



On Sat, Mar 7, 2015 at 6:37 PM, Daan Hoogland daan.hoogl...@gmail.com
wrote:

 Laszlo, I didn't think twice about this but we had that in a prior
 version as well. It is not specific to 4.6. Did you upgrade this
 environment?

 On Fri, Mar 6, 2015 at 6:28 AM, Laszlo Hornyak laszlo.horn...@gmail.com
 wrote:
  Hi,
 
  After cloudstack-setup (4.6, latest) I looked into the db.properties file
  and I have found that the comment lines got mixed into the actual
 content.
  Anyone met this problem?
 
  
 
  # Licensed to the Apache Software Foundation (ASF) under one
  db.usage.maxActive=100
  # or more contributor license agreements.  See the NOTICE file
 
  # distributed with this work for additional information
 
 
  db.cloud.name=cloud
  # with the License.  You may obtain a copy of the License at
  db.cloud.password=ENC(let's skip this part..., but anyways)
  # software distributed under the License is distributed on an
 
  #   http://www.apache.org/licenses/LICENSE-2.0
  # to you under the Apache License, Version 2.0 (the
 
 
 
  # Unless required by applicable law or agreed to in writing,
  # specific language governing permissions and limitations
 
  # License); you may not use this file except in compliance
 
 
  # KIND, either express or implied.  See the License for the
  db.usage.maxWait=1
  # High Availability And Cluster Properties
  db.usage.maxIdle=30
  # CloudStack database settings
  db.cloud.autoReconnectForPools=true
  db.cloud.trustStore=
  db.awsapi.host=localhost
  # in which the management server(Tomcat) is running
  db.usage.name=cloud_usage
  # regarding copyright ownership.  The ASF licenses this file
  # usage database tuning parameters
  db.cloud.poolPreparedStatements=false
 
 
  --
 
  EOF



 --
 Daan




-- 

EOF


db.properties confused

2015-03-05 Thread Laszlo Hornyak
Hi,

After cloudstack-setup (4.6, latest) I looked into the db.properties file
and I have found that the comment lines got mixed into the actual content.
Anyone met this problem?



# Licensed to the Apache Software Foundation (ASF) under one
db.usage.maxActive=100
# or more contributor license agreements.  See the NOTICE file

# distributed with this work for additional information


db.cloud.name=cloud
# with the License.  You may obtain a copy of the License at
db.cloud.password=ENC(let's skip this part..., but anyways)
# software distributed under the License is distributed on an

#   http://www.apache.org/licenses/LICENSE-2.0
# to you under the Apache License, Version 2.0 (the



# Unless required by applicable law or agreed to in writing,
# specific language governing permissions and limitations

# License); you may not use this file except in compliance


# KIND, either express or implied.  See the License for the
db.usage.maxWait=1
# High Availability And Cluster Properties
db.usage.maxIdle=30
# CloudStack database settings
db.cloud.autoReconnectForPools=true
db.cloud.trustStore=
db.awsapi.host=localhost
# in which the management server(Tomcat) is running
db.usage.name=cloud_usage
# regarding copyright ownership.  The ASF licenses this file
# usage database tuning parameters
db.cloud.poolPreparedStatements=false


-- 

EOF


setting db.properties files

2014-12-09 Thread Sebastien Goasguen
Hi,

I am dockering with cloudstack.

I need to update the db.properties file to set the db password and host to 
something other than localhost.
the host is actually in a env variable.

I can do it with a dirty hack like this:

sed -i s/db.root.password=/db.root.password=$MYSQL_ENV_MYSQL_ROOT_PASSWORD/ 
utils/conf/db.properties

what's the best practice to change those db properties at runtime ?

thx,

-sebastien

Re: setting db.properties files

2014-12-09 Thread Rohit Yadav

Hi Sebastien,

Create and use a db.properties.override file in the same location (utils/conf), 
this file is by default not included in git (it's in .gitignore).

Hope this helps.

On Tuesday 09 December 2014 06:26 PM, Sebastien Goasguen wrote:

Hi,

I am dockering with cloudstack.

I need to update the db.properties file to set the db password and host to 
something other than localhost.
the host is actually in a env variable.

I can do it with a dirty hack like this:

sed -i s/db.root.password=/db.root.password=$MYSQL_ENV_MYSQL_ROOT_PASSWORD/ 
utils/conf/db.properties

what's the best practice to change those db properties at runtime ?

thx,

-sebastien



--
Regards,
Rohit Yadav
Software Architect, ShapeBlue
M. +91 8826230892 | rohit.ya...@shapeblue.com
Blog: bhaisaab.org | Twitter: @_bhaisaab
PS. If you see any footer below, I did not add it :)

Find out more about ShapeBlue and our range of CloudStack related services

IaaS Cloud Design  Buildhttp://shapeblue.com/iaas-cloud-design-and-build//
CSForge – rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/
CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/
CloudStack Software 
Engineeringhttp://shapeblue.com/cloudstack-software-engineering/
CloudStack Infrastructure 
Supporthttp://shapeblue.com/cloudstack-infrastructure-support/
CloudStack Bootcamp Training Courseshttp://shapeblue.com/cloudstack-training/

This email and any attachments to it may be confidential and are intended solely 
for the use of the individual to whom it is addressed. Any views or opinions 
expressed are solely those of the author and do not necessarily represent those of 
Shape Blue Ltd or related companies. If you are not the intended recipient of this 
email, you must neither take any action based upon its contents, nor copy or show 
it to anyone. Please contact the sender if you believe you have received this email 
in error. Shape Blue Ltd is a company incorporated in England  Wales. 
ShapeBlue Services India LLP is a company incorporated in India and is operated 
under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company 
incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue 
SA Pty Ltd is a company registered by The Republic of South Africa and is traded 
under license from Shape Blue Ltd. ShapeBlue is a registered trademark.


db.properties

2013-08-05 Thread Mike Tutkowski
Hi,

I was looking at my db.properties file and noticed I didn't fill in a value
for the db.root.password key.

Can someone tell me what filling in this value will change behavior wise in
CloudStack?

Thanks!

Mike

# CloudStack database settings

db.cloud.username=cloud

db.cloud.password=cloud

db.root.password=

db.cloud.host=localhost

db.cloud.port=3306

db.cloud.name=cloud

-- 
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkow...@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloudhttp://solidfire.com/solution/overview/?video=play
*™*


RE: db.properties

2013-08-05 Thread Vijayendra Bhamidipati
Hi Mike,

If when installing your mysql server, you set a password for the mysql root 
user, you will need to specify that here. If you haven't encountered errors in 
your deploydb, you probably haven't set the mysql root user password and so you 
don't have to change the db.properties file. Typically, if we set this 
password, we copy over the db.properties file to db.properties.override and 
fill in this field in that file and it will get picked up by the db schema 
creation scripts.

Regards,
Vijay

-Original Message-
From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com] 
Sent: Monday, August 05, 2013 10:49 AM
To: dev@cloudstack.apache.org
Subject: db.properties

Hi,

I was looking at my db.properties file and noticed I didn't fill in a value for 
the db.root.password key.

Can someone tell me what filling in this value will change behavior wise in 
CloudStack?

Thanks!

Mike

# CloudStack database settings

db.cloud.username=cloud

db.cloud.password=cloud

db.root.password=

db.cloud.host=localhost

db.cloud.port=3306

db.cloud.name=cloud

--
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkow...@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloudhttp://solidfire.com/solution/overview/?video=play
*(tm)*


Re: db.properties

2013-08-05 Thread Mike Tutkowski
Ah, OK, thanks.

It has been a long time since I first installed MySQL for CloudStack
development and I don't recall exactly how I set it up back then, but it
must have been without a password.


On Mon, Aug 5, 2013 at 12:01 PM, Vijayendra Bhamidipati 
vijayendra.bhamidip...@citrix.com wrote:

 Hi Mike,

 If when installing your mysql server, you set a password for the mysql
 root user, you will need to specify that here. If you haven't encountered
 errors in your deploydb, you probably haven't set the mysql root user
 password and so you don't have to change the db.properties file. Typically,
 if we set this password, we copy over the db.properties file to
 db.properties.override and fill in this field in that file and it will get
 picked up by the db schema creation scripts.

 Regards,
 Vijay

 -Original Message-
 From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
 Sent: Monday, August 05, 2013 10:49 AM
 To: dev@cloudstack.apache.org
 Subject: db.properties

 Hi,

 I was looking at my db.properties file and noticed I didn't fill in a
 value for the db.root.password key.

 Can someone tell me what filling in this value will change behavior wise
 in CloudStack?

 Thanks!

 Mike

 # CloudStack database settings

 db.cloud.username=cloud

 db.cloud.password=cloud

 db.root.password=

 db.cloud.host=localhost

 db.cloud.port=3306

 db.cloud.name=cloud

 --
 *Mike Tutkowski*
 *Senior CloudStack Developer, SolidFire Inc.*
 e: mike.tutkow...@solidfire.com
 o: 303.746.7302
 Advancing the way the world uses the
 cloudhttp://solidfire.com/solution/overview/?video=play
 *(tm)*




-- 
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkow...@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloudhttp://solidfire.com/solution/overview/?video=play
*™*