[jira] [Updated] (CLOUDSTACK-9369) Security issue! Local login open with SAML implementation

[John Kinsella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Kinsella updated CLOUDSTACK-9369:
--
Cloudstack-CVSS: 7.5

> Security issue! Local login open with SAML implementation
> -
>
> Key: CLOUDSTACK-9369
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9369
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: SAML
>Affects Versions: 4.5.2, 4.6.2, 4.7.1, 4.8.0
> Environment: ACS 4.5.2
> XS 6.2/6.5
>Reporter: Cyrano Rizzo
>Assignee: Rohit Yadav
>Priority: Critical
>  Labels: login, loginmodule, saml
> Attachments: 
> 4.5-CLOUDSTACK-9369-Restrict-default-login-to-ldap-nativ.patch, 
> 4.7plus-CLOUDSTACK-9369-Restrict-default-login-to-ldap-nativ.patch, 
> master-CLOUDSTACK-9369-Restrict-default-login-to-ldap-nativ.patch
>
>   Original Estimate: 8h
>  Remaining Estimate: 8h
>
> All SAML enabled accounts can login localy with any password



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (CLOUDSTACK-9369) Security issue! Local login open with SAML implementation

[John Kinsella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Kinsella updated CLOUDSTACK-9369:
--
Security: Public  (was: Non-Public)

> Security issue! Local login open with SAML implementation
> -
>
> Key: CLOUDSTACK-9369
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9369
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: SAML
>Affects Versions: 4.5.2, 4.6.2, 4.7.1, 4.8.0
> Environment: ACS 4.5.2
> XS 6.2/6.5
>Reporter: Cyrano Rizzo
>Assignee: Rohit Yadav
>Priority: Critical
>  Labels: login, loginmodule, saml
> Attachments: 
> 4.5-CLOUDSTACK-9369-Restrict-default-login-to-ldap-nativ.patch, 
> 4.7plus-CLOUDSTACK-9369-Restrict-default-login-to-ldap-nativ.patch, 
> master-CLOUDSTACK-9369-Restrict-default-login-to-ldap-nativ.patch
>
>   Original Estimate: 8h
>  Remaining Estimate: 8h
>
> All SAML enabled accounts can login localy with any password



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (CLOUDSTACK-9544) Account API keys vulnerability in Cloudstack with possible privileges escalation

[John Kinsella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Kinsella resolved CLOUDSTACK-9544.
---
   Resolution: Fixed
Fix Version/s: 4.9.0.1
   4.8.1.1

ACS versions 4.8.1.1 and 4.9.0.1 with fixes for this issue were released this 
week.

> Account API keys vulnerability in Cloudstack with possible privileges 
> escalation
> 
>
> Key: CLOUDSTACK-9544
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9544
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API
>Reporter: John Kinsella
>Assignee: Rohit Yadav
> Fix For: 4.8.1.1, 4.9.0.1
>
> Attachments: fix_api_keys.patch
>
>
> Reported by Marc-Aurèle Brothier to security@:
> Hello,
> I don't know if you would consider this as a vulnerabilities but I think it 
> is one. Currently in all Cloudstack version, any user having access to the 
> API can regenerate API keys for all user except the system one with ID=1, 
> with the assumptions that he knows the UUID of the user. With the 
> consideration that user knows another user UUID from a privilege domain, the 
> attacker can change the api key of that user and then get the same access 
> since he will receive the new key and secret in the API response for that 
> privileged user. Therefore he can create a privilege account for himself 
> after that call. From there, it's open bar ;-) It's the description of the 
> worst case scenario.
> Other cases would be to access to other accounts data/vm and invalidate api 
> keys.
> I think it is a vulnerability since the user UUID is not something supposed 
> to be kept secret, and having the knowledge of this single uuid let you 
> access to the ROOT domain pretty easily.
> Human description to reproduce the case:
> Search for a user in the ROOT domain and admin account of your cloudstack 
> installation, and get the ID of a user, but not the admin one, or create a 
> new user in this account.
> Create or use another user from a different account/domain that does not have 
> any privileged access, a normal account. Then using the secretkey and apikey 
> from the normal user, issue a registerUserKeys id= and 
> see that you're getting a new pair of api & secret key.
> The patch is pretty simple and attached to this email, 3 lines to change in 
> one class to check the access of the account caller on the account associated 
> to the user uuid in the request. The patch has been done on the file version 
> on the master branch, and should be very easily back ported to all version 
> since the code hasn't changed much in this method.
> I haven't open any PR or bug of course to relate this finding. We will patch 
> our own cloudstack version (the repo having this fix is private) today, 
> that's all.
> Let me know if you have any questions or for the follow up.
> Kind regards,



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-9544) Account API keys vulnerability in Cloudstack with possible privileges escalation

[John Kinsella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Kinsella updated CLOUDSTACK-9544:
--
Security: Public  (was: Non-Public)

> Account API keys vulnerability in Cloudstack with possible privileges 
> escalation
> 
>
> Key: CLOUDSTACK-9544
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9544
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API
>Reporter: John Kinsella
>Assignee: Rohit Yadav
> Attachments: fix_api_keys.patch
>
>
> Reported by Marc-Aurèle Brothier to security@:
> Hello,
> I don't know if you would consider this as a vulnerabilities but I think it 
> is one. Currently in all Cloudstack version, any user having access to the 
> API can regenerate API keys for all user except the system one with ID=1, 
> with the assumptions that he knows the UUID of the user. With the 
> consideration that user knows another user UUID from a privilege domain, the 
> attacker can change the api key of that user and then get the same access 
> since he will receive the new key and secret in the API response for that 
> privileged user. Therefore he can create a privilege account for himself 
> after that call. From there, it's open bar ;-) It's the description of the 
> worst case scenario.
> Other cases would be to access to other accounts data/vm and invalidate api 
> keys.
> I think it is a vulnerability since the user UUID is not something supposed 
> to be kept secret, and having the knowledge of this single uuid let you 
> access to the ROOT domain pretty easily.
> Human description to reproduce the case:
> Search for a user in the ROOT domain and admin account of your cloudstack 
> installation, and get the ID of a user, but not the admin one, or create a 
> new user in this account.
> Create or use another user from a different account/domain that does not have 
> any privileged access, a normal account. Then using the secretkey and apikey 
> from the normal user, issue a registerUserKeys id= and 
> see that you're getting a new pair of api & secret key.
> The patch is pretty simple and attached to this email, 3 lines to change in 
> one class to check the access of the account caller on the account associated 
> to the user uuid in the request. The patch has been done on the file version 
> on the master branch, and should be very easily back ported to all version 
> since the code hasn't changed much in this method.
> I haven't open any PR or bug of course to relate this finding. We will patch 
> our own cloudstack version (the repo having this fix is private) today, 
> that's all.
> Let me know if you have any questions or for the follow up.
> Kind regards,



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-9376) Using the listTemplates API with the "templatefilter=all" parameter lists all the templates that are available with all domains in the system.

[John Kinsella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Kinsella updated CLOUDSTACK-9376:
--
Security: Public  (was: Non-Public)

> Using the listTemplates API with the "templatefilter=all" parameter lists all 
> the templates that are available with all domains in the system.
> --
>
> Key: CLOUDSTACK-9376
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9376
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.5.1
>Reporter: Abhinandan Prateek
>Assignee: Abhinandan Prateek
> Fix For: 4.9.0
>
> Attachments: 
> 0001-CLOUDSTACK-9376-Restrict-listTemplates-API-with-filt.patch
>
>
> The "templatefilter=all" filter is not implemented properly for domain 
> administrators.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CLOUDSTACK-9023) private keys get logged when UpdateCustomCertificate gets called

[John Kinsella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Kinsella resolved CLOUDSTACK-9023.
---
Resolution: Fixed

This was mitigated while working on CLOUDSTACK-8485. Resolved in commit 
https://github.com/apache/cloudstack/commit/e13df96348c60694849f91d0c025cb349aea124e

> private keys get logged when UpdateCustomCertificate gets called
> 
>
> Key: CLOUDSTACK-9023
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9023
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0
>Reporter: Daan Hoogland
>
> Not verified with older versions but found during testing



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CLOUDSTACK-9023) private keys get logged when UpdateCustomCertificate gets called

[John Kinsella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Kinsella closed CLOUDSTACK-9023.
-

> private keys get logged when UpdateCustomCertificate gets called
> 
>
> Key: CLOUDSTACK-9023
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9023
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0
>Reporter: Daan Hoogland
>
> Not verified with older versions but found during testing



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9124) GPG Key published on cloudstack.apt-get.eu is outdated

[John Kinsella (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15094872#comment-15094872
 ] 

John Kinsella commented on CLOUDSTACK-9124:
---

Confirmed this is an issue.

[~htrippaers], I think you run cloudstack.apt-get.eu?

> GPG Key published on cloudstack.apt-get.eu is outdated
> --
>
> Key: CLOUDSTACK-9124
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9124
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Doc, Management Server
>Reporter: lmwangi
>
> The key published on http://cloudstack.apt-get.eu/release.asc is outdated. 
> Consequently, trying to install cloudstack on ubuntu fails with a signature 
> mismatch error. 
> The incorrect key is:
> ```
> pub   2048R/86C278E3 2012-09-07
> uid  Apache CloudStack 
> sub   2048R/B7C7765A 2012-09-07
> ```
> Correct  key:
> ```
> pub   4096R/CC56CEA8 2012-08-06 [expires: 2016-08-06]
> uid  Chip Childers 
> uid  Chip Childers (Personal email address) 
> 
> uid  Chip Childers (SunGard work address) 
> 
> sub   4096R/A99A5D58 2012-08-06 [expires: 2016-08-06]
> ```
> Cheers,
> Laban



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CLOUDSTACK-9070) 4.5.x source downloads from apache.org fail gpg integrity test

[John Kinsella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Kinsella resolved CLOUDSTACK-9070.
---
Resolution: Fixed
  Assignee: John Kinsella  (was: Rohit Yadav)

Rohit added his key into the KEYS file...after importing that, I'm able to 
verify the release now:

$ gpg --verify apache-cloudstack-4.5.2-src.tar.bz2.asc
gpg: Signature made Wed Aug 19 02:13:04 2015 PDT using RSA key ID 0EE3D884
gpg: Good signature from "Rohit Yadav (CODE SIGNING KEY) ”

Closing ticket.

> 4.5.x source downloads from apache.org fail gpg integrity test
> --
>
> Key: CLOUDSTACK-9070
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9070
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Install and Setup
>Affects Versions: 4.5.1, 4.5.2
>Reporter: Udo Rader
>Assignee: John Kinsella
>
> as described in 
> http://markmail.org/message/37udf7djizul5xuf 
> the currently available source downloads fail the gpg integrity check because 
> the key used to sign the packages is missing from 
> http://www.apache.org/dist/cloudstack/KEYS
> ---CUT-
> [udo@artio Downloads]$ gpg --verify apache-cloudstack-4.5.2-src.tar.bz2.asc
> gpg: assuming signed data in `apache-cloudstack-4.5.2-src.tar.bz2'
> gpg: Signature made Wed 19 Aug 2015 11:13:04 AM CEST using RSA key ID
> 0EE3D884
> gpg: Can't check signature: public key not found
> ---CUT-
> applies to 4.5.1 and 4.5.2 at least. 
> At least to me this makes the integrity of the source downloads dubious ...



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-9053) CloudStack is dependent upon a vulnerable version of Commons Collections

[John Kinsella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Kinsella updated CLOUDSTACK-9053:
--
Security: Public  (was: Non-Public)

> CloudStack is dependent upon a vulnerable version of Commons Collections
> 
>
> Key: CLOUDSTACK-9053
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9053
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: John Kinsella
>
> COLLECTIONS-580 was brought to our attention today. Current versions of 
> Apache Commons Collections contain a serialization/unserialization 
> vulnerability which may result in remote code execution.
> CloudStack does not seem to use the specific vulnerable class 
> InvokerTransformer, so in theory we could recommend pulling that class from 
> the jars/wars, but still looking to see what else we can do...



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9070) 4.5.x source downloads from apache.org fail gpg integrity test

[John Kinsella (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15009119#comment-15009119
 ] 

John Kinsella commented on CLOUDSTACK-9070:
---

Udo - thanks for pointing this out. The release was signed by Rohit Yadiv, but 
it looks like his public key is not in 
http://www.apache.org/dist/cloudstack/KEYS.

I think it's just a simple mistake, not that there's a security risk.

Will see if we can get this straightened out fairly soon. Assigning over to 
Rohit...

> 4.5.x source downloads from apache.org fail gpg integrity test
> --
>
> Key: CLOUDSTACK-9070
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9070
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Install and Setup
>Affects Versions: 4.5.1, 4.5.2
>Reporter: Udo Rader
>
> as described in 
> http://markmail.org/message/37udf7djizul5xuf 
> the currently available source downloads fail the gpg integrity check because 
> the key used to sign the packages is missing from 
> http://www.apache.org/dist/cloudstack/KEYS
> ---CUT-
> [udo@artio Downloads]$ gpg --verify apache-cloudstack-4.5.2-src.tar.bz2.asc
> gpg: assuming signed data in `apache-cloudstack-4.5.2-src.tar.bz2'
> gpg: Signature made Wed 19 Aug 2015 11:13:04 AM CEST using RSA key ID
> 0EE3D884
> gpg: Can't check signature: public key not found
> ---CUT-
> applies to 4.5.1 and 4.5.2 at least. 
> At least to me this makes the integrity of the source downloads dubious ...



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-9070) 4.5.x source downloads from apache.org fail gpg integrity test

[John Kinsella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Kinsella updated CLOUDSTACK-9070:
--
Assignee: Rohit Yadav

> 4.5.x source downloads from apache.org fail gpg integrity test
> --
>
> Key: CLOUDSTACK-9070
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9070
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Install and Setup
>Affects Versions: 4.5.1, 4.5.2
>Reporter: Udo Rader
>Assignee: Rohit Yadav
>
> as described in 
> http://markmail.org/message/37udf7djizul5xuf 
> the currently available source downloads fail the gpg integrity check because 
> the key used to sign the packages is missing from 
> http://www.apache.org/dist/cloudstack/KEYS
> ---CUT-
> [udo@artio Downloads]$ gpg --verify apache-cloudstack-4.5.2-src.tar.bz2.asc
> gpg: assuming signed data in `apache-cloudstack-4.5.2-src.tar.bz2'
> gpg: Signature made Wed 19 Aug 2015 11:13:04 AM CEST using RSA key ID
> 0EE3D884
> gpg: Can't check signature: public key not found
> ---CUT-
> applies to 4.5.1 and 4.5.2 at least. 
> At least to me this makes the integrity of the source downloads dubious ...



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-8158) After the host reboots, the system will run out vm management IP, no matter how much.

[John Kinsella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Kinsella updated CLOUDSTACK-8158:
--
Cloudstack-CVSS:   (was: 92)

 After the host reboots, the system will run out vm management IP, no matter 
 how much.
 -

 Key: CLOUDSTACK-8158
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8158
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: KVM
Affects Versions: 4.4.0, 4.4.1, 4.4.2
 Environment: All nodes in the system OS: Centos 6.5 x64 are
 Cloudstack Version: 4.4.1 / 4.4.2 / 4.4.0
 All nodes are installed on a single host, use the basic network, installation 
 documentation is installed in accordance with the documentation provided by 
 the official.
Reporter: liliang
  Labels: patch
 Fix For: 4.5.0

   Original Estimate: 12h
  Remaining Estimate: 12h

 cloudstack all nodes installed on a host, all nodes in the system OS are 
 centos6.5 x64. After using basic network build regional success, reboot the 
 host, the system will manage IP vm exhausted. Every restart a host system vm 
 will occupy the new management IP address, the old IP address can not be 
 released. According to the analysis system BUG logs, restart once every host 
 system vm will automatically rebuild destroyed repeatedly, until the system 
 vm system up or manage IP exhausted, the system can start vm, the premise is 
 under the management of IP abundant, management IP consumption when you do 
 not start the system vm, database tables need to manually release the 
 management IP. And under normal circumstances, reboot the system into the 
 production environment is not su, senior network has not been detected this 
 problem,
 cloudstack 所有节点安装在一台资源充沛的宿主机，所有节点系统OS均为 centos6.5 
 x64。安装成功后，使用基本网络搭建区域成功后，重启宿主机后，系统vm会把管理IP耗尽。每重启一次宿主机，系统vm都会占用新的管理IP地址，旧的IP地址无法释放。根据系统BUG日志的分析，每重启一次宿主机，系统vm会自动反复重建销毁，直到系统vm系统起来或管理IP耗尽，系统vm可以正常启动，前提是管理IP充裕的情况下，管理IP耗尽时则无法启动系统vm
  
 ，需要到数据库表中手动释放管理IP。都未运行任何实例。而在正常的情况下，重启系统宿主机，系统vm不会自动销毁重建，或占用大量IP。而在4.3.1或4.3.0以下，包括（4.3.0/4.3.1）不会出现上述问题，安装方式是按照官方提供的文档进行的安装，安装文档是：http://cloudstack-installation.readthedocs.org/en/latest/qig.html
 未投入生产环境中，高级网络中尚未检测到这种问题。



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8158) After the host reboots, the system will run out vm management IP, no matter how much.

[John Kinsella (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14279917#comment-14279917
 ] 

John Kinsella commented on CLOUDSTACK-8158:
---

(I removed the CVSS score 92 as that doesn't really make sense and this isn't a 
security-related issue)

 After the host reboots, the system will run out vm management IP, no matter 
 how much.
 -

 Key: CLOUDSTACK-8158
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8158
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: KVM
Affects Versions: 4.4.0, 4.4.1, 4.4.2
 Environment: All nodes in the system OS: Centos 6.5 x64 are
 Cloudstack Version: 4.4.1 / 4.4.2 / 4.4.0
 All nodes are installed on a single host, use the basic network, installation 
 documentation is installed in accordance with the documentation provided by 
 the official.
Reporter: liliang
  Labels: patch
 Fix For: 4.5.0

   Original Estimate: 12h
  Remaining Estimate: 12h

 cloudstack all nodes installed on a host, all nodes in the system OS are 
 centos6.5 x64. After using basic network build regional success, reboot the 
 host, the system will manage IP vm exhausted. Every restart a host system vm 
 will occupy the new management IP address, the old IP address can not be 
 released. According to the analysis system BUG logs, restart once every host 
 system vm will automatically rebuild destroyed repeatedly, until the system 
 vm system up or manage IP exhausted, the system can start vm, the premise is 
 under the management of IP abundant, management IP consumption when you do 
 not start the system vm, database tables need to manually release the 
 management IP. And under normal circumstances, reboot the system into the 
 production environment is not su, senior network has not been detected this 
 problem,
 cloudstack 所有节点安装在一台资源充沛的宿主机，所有节点系统OS均为 centos6.5 
 x64。安装成功后，使用基本网络搭建区域成功后，重启宿主机后，系统vm会把管理IP耗尽。每重启一次宿主机，系统vm都会占用新的管理IP地址，旧的IP地址无法释放。根据系统BUG日志的分析，每重启一次宿主机，系统vm会自动反复重建销毁，直到系统vm系统起来或管理IP耗尽，系统vm可以正常启动，前提是管理IP充裕的情况下，管理IP耗尽时则无法启动系统vm
  
 ，需要到数据库表中手动释放管理IP。都未运行任何实例。而在正常的情况下，重启系统宿主机，系统vm不会自动销毁重建，或占用大量IP。而在4.3.1或4.3.0以下，包括（4.3.0/4.3.1）不会出现上述问题，安装方式是按照官方提供的文档进行的安装，安装文档是：http://cloudstack-installation.readthedocs.org/en/latest/qig.html
 未投入生产环境中，高级网络中尚未检测到这种问题。



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-7937) CloudStack accepts unauthenticated LDAP binds

[John Kinsella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Kinsella updated CLOUDSTACK-7937:
--
Security: Public  (was: Non-Public)

 CloudStack accepts unauthenticated LDAP binds
 -

 Key: CLOUDSTACK-7937
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7937
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Reporter: John Kinsella
Assignee: Rajani Karuturi
Priority: Critical
  Labels: security
 Attachments: 
 43-0001-Fixed-CLOUDSTACK-7937-CloudStack-accepts-unauthentic.patch, 
 44-0001-Fixed-CLOUDSTACK-7937-CloudStack-accepts-unauthentic.patch


 Description:
 Apache CloudStack may be configured to authenticate LDAP users.  When so 
 configured, it performs a simple LDAP bind with the name and password 
 provided by a user.  Simple LDAP binds are defined with three mechanisms (RFC 
 4513): 1) username and password; 2) unauthenticated if only a username is 
 specified; and 3) anonymous if neither username or password is specified.  
 Currently, Apache CloudStack does not check if the password was provided 
 which could allow an attacker to bind as an unauthenticated user.
 Mitigation:
 This issue has been fixed in CloudStack versions 4.3.2 and 4.4.2. Please 
 upgrade to the latest version.
 By default, many LDAP servers are not configured to allow unauthenticated 
 binds.  If the LDAP server in use allow this behaviour, a potential interim 
 solution would be to consider disabling unauthenticated binds.
 Credit:
 This issue was identified by the Citrix Security Team.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-7923) RabbitMQ integration, make SSL protocol configurable rather than hard coded

[John Kinsella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Kinsella updated CLOUDSTACK-7923:
--
Status: Reviewable  (was: In Progress)

 RabbitMQ integration, make SSL protocol configurable rather than hard coded
 ---

 Key: CLOUDSTACK-7923
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7923
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.4.0, 4.5.0
Reporter: Damodar Reddy T
Assignee: Damodar Reddy T
 Fix For: 4.5.0


 In the current RabbitMQ integration implementation we are using default SSL 
 Context which uses SSLv3 by default.
 Make it configurable so that let the users decide which protocol to be used.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-7923) RabbitMQ integration, make SSL protocol configurable rather than hard coded

[John Kinsella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Kinsella updated CLOUDSTACK-7923:
--
Status: Open  (was: Reviewable)

Apologies - just accidently set the status to reviewable 

 RabbitMQ integration, make SSL protocol configurable rather than hard coded
 ---

 Key: CLOUDSTACK-7923
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7923
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.4.0, 4.5.0
Reporter: Damodar Reddy T
Assignee: Damodar Reddy T
 Fix For: 4.5.0


 In the current RabbitMQ integration implementation we are using default SSL 
 Context which uses SSLv3 by default.
 Make it configurable so that let the users decide which protocol to be used.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-3367) When one primary storage fails, all XenServer hosts get rebooted, killing all VMs, even those not on this primary storage.

[John Kinsella (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-3367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14233185#comment-14233185
 ] 

John Kinsella commented on CLOUDSTACK-3367:
---

Folks - you'll have better success by finding one or more developers who are 
familiar with the XenServer integration code and asking for their help than 
just griping in a jira ticket that isn't assigned to anybody.

Search the dev list or commits for folks who have worked on the appropriate 
code in the past, or just start a thread on dev@ with a subject to attract the 
appropriate folks.

Griping, while it might be justified, doesn't tend to gain favor in open source 
projects where people are volunteering their time.

 When one primary storage fails, all XenServer hosts get rebooted, killing all 
 VMs, even those not on this primary storage.
 --

 Key: CLOUDSTACK-3367
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3367
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server, XenServer
Affects Versions: 4.1.0, 4.2.0, 4.5.0, 4.3.1
 Environment: CentOS 6.3, XenServer 6.0.2 + all hotfixes, CloudStack 
 4.1.0
Reporter: France
 Fix For: Future


 As the title says: if only one of the primary storages fails, all XenServer 
 hosts get rebooted one by one. Because i have many primary storages, which 
 are/were running fine with other VMs, rebooting XenServer Hipervisor is an 
 overkill. Please disable this or implement just stopping/killing the VMs 
 running on that storage and try to re-attach that storage only.
 Problem was reported on the mailing list, as well as a workaround for 
 XenServer. So i'm not the only one hit by this bug/feature. Workaround for 
 now is as follows:
 1. Modify /opt/xensource/bin/xenheartbeat.sh on all your Hosts, commenting 
 out the two entries which have reboot -f
 2. Identify the PID of the script  - pidof -x xenheartbeat.sh
 3. Restart the Script  - kill pid
 4. Force reconnect Host from the UI,  the script will then re-launch on 
 reconnect



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-7184) HA should wait for at least 'xen.heartbeat.interval' sec before starting HA on vm's when host is marked down

[John Kinsella (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14127569#comment-14127569
 ] 

John Kinsella commented on CLOUDSTACK-7184:
---

No, KVM uses kvmheartbeat.sh, which unfortunately looks a lot different than 
xenheartbeat.sh.

Looks like the issue I've seen is different, will try to track it 
down/replicate and file a separate bug.

Patch looks clean, but I'm not in position to test it at the moment.


 HA should wait for at least 'xen.heartbeat.interval' sec before starting HA 
 on vm's when host is marked down
 

 Key: CLOUDSTACK-7184
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7184
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Hypervisor Controller, Management Server, XenServer
Affects Versions: 4.3.0, 4.4.0, 4.5.0
 Environment: CloudStack 4.3 with XenServer 6.2 hypervisors
Reporter: Remi Bergsma
Assignee: Daan Hoogland
Priority: Blocker

 Hypervisor got isolated for 30 seconds due to a network issue. CloudStack did 
 discover this and marked the host as down, and immediately started HA. Just 
 18 seconds later the hypervisor returned and we ended up with 5 vm's that 
 were running on two hypervisors at the same time. 
 This, of course, resulted in file system corruption and the loss of the vm's. 
 One side of the story is why XenServer allowed this to happen (will not 
 bother you with this one). The CloudStack side of the story: HA should only 
 start after at least xen.heartbeat.interval seconds. If the host is down long 
 enough, the Xen heartbeat script will fence the hypervisor and prevent 
 corruption. If it is not down long enough, nothing should happen.
 Logs (short):
 2014-07-25 05:03:28,596 WARN  [c.c.a.m.DirectAgentAttache] 
 (DirectAgent-122:ctx-690badc5) Unable to get current status on 505(mccpvmXX)
 .
 2014-07-25 05:03:31,920 ERROR [c.c.a.m.AgentManagerImpl] 
 (AgentTaskPool-10:ctx-11b9af3e) Host is down: 505-mccpvmXX.  Starting HA on 
 the VMs
 .
 2014-07-25 05:03:49,655 DEBUG [c.c.h.Status] (ClusteredAgentManager 
 Timer:ctx-0e00979c) Transition:[Resource state = Enabled, Agent event = 
 AgentDisconnected, Host id = 505, name = mccpvmXX]
 cs marks host down: 2014-07-25  05:03:31,920
 cs marks host up: 2014-07-25  05:03:49,655



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-7184) HA should wait for at least 'xen.heartbeat.interval' sec before starting HA on vm's when host is marked down

[John Kinsella (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14105710#comment-14105710
 ] 

John Kinsella commented on CLOUDSTACK-7184:
---

I've seen similar with KVM - I'm not sure this is necessarily tied to Xen? I'd 
suggest that possibly CS be a little more thorough before deciding a VM is 
down...maybe via channels other than the agent/VR?

 HA should wait for at least 'xen.heartbeat.interval' sec before starting HA 
 on vm's when host is marked down
 

 Key: CLOUDSTACK-7184
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7184
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Hypervisor Controller, Management Server, XenServer
Affects Versions: 4.3.0, 4.4.0, 4.5.0
 Environment: CloudStack 4.3 with XenServer 6.2 hypervisors
Reporter: Remi Bergsma
Priority: Blocker

 Hypervisor got isolated for 30 seconds due to a network issue. CloudStack did 
 discover this and marked the host as down, and immediately started HA. Just 
 18 seconds later the hypervisor returned and we ended up with 5 vm's that 
 were running on two hypervisors at the same time. 
 This, of course, resulted in file system corruption and the loss of the vm's. 
 One side of the story is why XenServer allowed this to happen (will not 
 bother you with this one). The CloudStack side of the story: HA should only 
 start after at least xen.heartbeat.interval seconds. If the host is down long 
 enough, the Xen heartbeat script will fence the hypervisor and prevent 
 corruption. If it is not down long enough, nothing should happen.
 Logs (short):
 2014-07-25 05:03:28,596 WARN  [c.c.a.m.DirectAgentAttache] 
 (DirectAgent-122:ctx-690badc5) Unable to get current status on 505(mccpvmXX)
 .
 2014-07-25 05:03:31,920 ERROR [c.c.a.m.AgentManagerImpl] 
 (AgentTaskPool-10:ctx-11b9af3e) Host is down: 505-mccpvmXX.  Starting HA on 
 the VMs
 .
 2014-07-25 05:03:49,655 DEBUG [c.c.h.Status] (ClusteredAgentManager 
 Timer:ctx-0e00979c) Transition:[Resource state = Enabled, Agent event = 
 AgentDisconnected, Host id = 505, name = mccpvmXX]
 cs marks host down: 2014-07-25  05:03:31,920
 cs marks host up: 2014-07-25  05:03:49,655



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (CLOUDSTACK-6156) Retired maven repo breaking awsapi build and RPM packaging

[John Kinsella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Kinsella resolved CLOUDSTACK-6156.
---

Resolution: Fixed

Haven't seen any complaints so considering this resolved.

 Retired maven repo breaking awsapi build and RPM packaging
 --

 Key: CLOUDSTACK-6156
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6156
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: AWSAPI
Affects Versions: 4.2.0, 4.3.0
Reporter: John Kinsella
Assignee: John Kinsella
Priority: Blocker

 The awsapi sub-project depends on several jars from Apache Axis-Rampart. 
 The Rampart poms have a broken maven repo hard-coded into them:
 urlhttp://shibboleth.internet2.edu/downloads/maven2//url
 Which does not return a 404 when maven attempts to fetch a jar, but HTTP 200. 
 *golf clap*
 Rampart is aware of this (see RAMPART-393) but the fix won't be released 
 until version 1.7, whenever that is.
 CLOUDSTACK-744 shows we hit this before for opensaml, although I'm not sure 
 when the rampart jars started erroring out.
 From my research so far, looks like rampart isn't being used and the rampart 
 dependencies can be removed from the pom...
 Steps to reproduce (On a clean system with no cached maven repo, and not 
 using a maven repo mirror):
 mvn -P awsapi
 Expected results:
 Happily built awsapi package
 Actual results:
 ...
 Downloaded: 
 http://repo.maven.apache.org/maven2/org/apache/rampart/rampart-policy/1.5.1/rampart-policy-1.5.1.pom
  (3 KB at 116.1 KB/sec)
 Downloading: 
 http://shibboleth.internet2.edu/downloads/maven2/org/apache/rampart/rampart-policy/1.5.1/rampart-policy-1.5.1.pom
 Feb 21, 2014 12:18:31 PM 
 org.apache.maven.wagon.providers.http.httpclient.client.protocol.ResponseProcessCookies
  processCookies
 WARNING: Invalid cookie header: Set-Cookie:  django_language=en-us; 
 expires=time.struct_time(tm_year=2015, tm_mon=2, tm_mday=21, tm_hour=15, 
 tm_min=18, tm_sec=33, tm_wday=5, tm_yday=52, tm_isdst=0); Max-Age=31536000; 
 Path=/. Unable to parse expires attribute: time.struct_time(tm_year=2015, 
 tm_mon=2, tm_mday=21, tm_hour=15, tm_min=18, tm_sec=33, tm_wday=5, 
 tm_yday=52, tm_isdst=0)
 Feb 21, 2014 12:18:32 PM 
 org.apache.maven.wagon.providers.http.httpclient.client.protocol.ResponseProcessCookies
  processCookies
 WARNING: Invalid cookie header: Set-Cookie:  django_language=en-us; 
 expires=time.struct_time(tm_year=2015, tm_mon=2, tm_mday=21, tm_hour=15, 
 tm_min=18, tm_sec=33, tm_wday=5, tm_yday=52, tm_isdst=0); Max-Age=31536000; 
 Path=/. Unable to parse expires attribute: time.struct_time(tm_year=2015, 
 tm_mon=2, tm_mday=21, tm_hour=15, tm_min=18, tm_sec=33, tm_wday=5, 
 tm_yday=52, tm_isdst=0)
 Feb 21, 2014 12:18:32 PM 
 org.apache.maven.wagon.providers.http.httpclient.client.protocol.ResponseProcessCookies
  processCookies
 ...
 [WARNING] Invalid POM for org.apache.rampart:rampart-policy:jar:1.5.1, 
 transitive dependencies (if any) will not be available, enable debug logging 
 for more details
 etc, etc



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Closed] (CLOUDSTACK-6156) Retired maven repo breaking awsapi build and RPM packaging

[John Kinsella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Kinsella closed CLOUDSTACK-6156.
-


 Retired maven repo breaking awsapi build and RPM packaging
 --

 Key: CLOUDSTACK-6156
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6156
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: AWSAPI
Affects Versions: 4.2.0, 4.3.0
Reporter: John Kinsella
Assignee: John Kinsella
Priority: Blocker

 The awsapi sub-project depends on several jars from Apache Axis-Rampart. 
 The Rampart poms have a broken maven repo hard-coded into them:
 urlhttp://shibboleth.internet2.edu/downloads/maven2//url
 Which does not return a 404 when maven attempts to fetch a jar, but HTTP 200. 
 *golf clap*
 Rampart is aware of this (see RAMPART-393) but the fix won't be released 
 until version 1.7, whenever that is.
 CLOUDSTACK-744 shows we hit this before for opensaml, although I'm not sure 
 when the rampart jars started erroring out.
 From my research so far, looks like rampart isn't being used and the rampart 
 dependencies can be removed from the pom...
 Steps to reproduce (On a clean system with no cached maven repo, and not 
 using a maven repo mirror):
 mvn -P awsapi
 Expected results:
 Happily built awsapi package
 Actual results:
 ...
 Downloaded: 
 http://repo.maven.apache.org/maven2/org/apache/rampart/rampart-policy/1.5.1/rampart-policy-1.5.1.pom
  (3 KB at 116.1 KB/sec)
 Downloading: 
 http://shibboleth.internet2.edu/downloads/maven2/org/apache/rampart/rampart-policy/1.5.1/rampart-policy-1.5.1.pom
 Feb 21, 2014 12:18:31 PM 
 org.apache.maven.wagon.providers.http.httpclient.client.protocol.ResponseProcessCookies
  processCookies
 WARNING: Invalid cookie header: Set-Cookie:  django_language=en-us; 
 expires=time.struct_time(tm_year=2015, tm_mon=2, tm_mday=21, tm_hour=15, 
 tm_min=18, tm_sec=33, tm_wday=5, tm_yday=52, tm_isdst=0); Max-Age=31536000; 
 Path=/. Unable to parse expires attribute: time.struct_time(tm_year=2015, 
 tm_mon=2, tm_mday=21, tm_hour=15, tm_min=18, tm_sec=33, tm_wday=5, 
 tm_yday=52, tm_isdst=0)
 Feb 21, 2014 12:18:32 PM 
 org.apache.maven.wagon.providers.http.httpclient.client.protocol.ResponseProcessCookies
  processCookies
 WARNING: Invalid cookie header: Set-Cookie:  django_language=en-us; 
 expires=time.struct_time(tm_year=2015, tm_mon=2, tm_mday=21, tm_hour=15, 
 tm_min=18, tm_sec=33, tm_wday=5, tm_yday=52, tm_isdst=0); Max-Age=31536000; 
 Path=/. Unable to parse expires attribute: time.struct_time(tm_year=2015, 
 tm_mon=2, tm_mday=21, tm_hour=15, tm_min=18, tm_sec=33, tm_wday=5, 
 tm_yday=52, tm_isdst=0)
 Feb 21, 2014 12:18:32 PM 
 org.apache.maven.wagon.providers.http.httpclient.client.protocol.ResponseProcessCookies
  processCookies
 ...
 [WARNING] Invalid POM for org.apache.rampart:rampart-policy:jar:1.5.1, 
 transitive dependencies (if any) will not be available, enable debug logging 
 for more details
 etc, etc



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-6820) VPC router ICMP acl

[John Kinsella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Kinsella updated CLOUDSTACK-6820:
--

Security: Public  (was: Non-Public)

 VPC router ICMP acl
 ---

 Key: CLOUDSTACK-6820
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6820
 Project: CloudStack
  Issue Type: Improvement
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Virtual Router
Affects Versions: 4.3.0
Reporter: Thijs Houtenbos
Priority: Minor
  Labels: security

 There is a default allow icmp any any on the VPC router vm which cannot be 
 controlled with the network ACLs. This makes it impossible to block certain 
 icmp traffic.
 root@r-4135-VM:~# iptables -L -v | grep icmp
 10784  901K ACCEPT icmp --  anyany anywhere anywhere



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-6820) VPC router ICMP acl

[John Kinsella (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14016569#comment-14016569
 ] 

John Kinsella commented on CLOUDSTACK-6820:
---

Chatted with Daan about this on security@ - doesn't look like this affects the 
security of ACS, so I'm leaving it public.

So - the firewall setup on the SSVMs in general is sort of annoying, in that 
without 
building a new image there’s not currently a way to update those rulesets 
without
manual tweaking. Seems like there should be a default ruleset, with the ability 
to
override the ruleset either per-VM or in general.

Now that I think about it - what seems ideal would be to have an “advanced” 
option 
to instruct a SSVM to connect to a puppet/chef/whatever server to get it’s 
configuration data.

Also - just a reminder to not block all ICMP as a whole. Block echo/reply and
the time-realted messages if you wish, but you want things like MTU negotiation 
to go through.

 VPC router ICMP acl
 ---

 Key: CLOUDSTACK-6820
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6820
 Project: CloudStack
  Issue Type: Improvement
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Virtual Router
Affects Versions: 4.3.0
Reporter: Thijs Houtenbos
Priority: Minor
  Labels: security

 There is a default allow icmp any any on the VPC router vm which cannot be 
 controlled with the network ACLs. This makes it impossible to block certain 
 icmp traffic.
 root@r-4135-VM:~# iptables -L -v | grep icmp
 10784  901K ACCEPT icmp --  anyany anywhere anywhere



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-6301) kvm : vnc password is disabled when rebooted

[John Kinsella (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13950930#comment-13950930
 ] 

John Kinsella commented on CLOUDSTACK-6301:
---

I'm unable to reproduce this. If you are using dumpxml, make sure you pass 
--security-info or password will not be displayed.

On a rebooted KVM VM on an ACS 4.2 agent:

# virsh dumpxml 23 |grep pass
# virsh dumpxml 23 --security-info|grep pass
graphics type='vnc' port='5909' autoport='yes' listen='0.0.0.0' 
passwd='bb28f84e09a1'



 kvm : vnc password is disabled when rebooted
 

 Key: CLOUDSTACK-6301
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6301
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: KVM
Affects Versions: 4.2.0
Reporter: Francois Scala
Assignee: John Kinsella
  Labels: security

 When a VM is rebooted from the cloudstack GUI, the xml recreated without the 
 vnc password.
 Here is the libvirt vnc configuration from a running vm :
 graphics type='vnc' port='-1' autoport='yes' listen='0.0.0.0' 
 passwd='a671096d9ecda37e'
   listen type='address' address='0.0.0.0'/
 /graphics
 The same configuration afger a reboot :
 graphics type='vnc' port='-1' autoport='yes' listen='0.0.0.0'
   listen type='address' address='0.0.0.0'/
 /graphics



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-6301) kvm : vnc password is disabled when rebooted

[John Kinsella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Kinsella updated CLOUDSTACK-6301:
--

Security: Public  (was: Non-Public)

 kvm : vnc password is disabled when rebooted
 

 Key: CLOUDSTACK-6301
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6301
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: KVM
Affects Versions: 4.2.0
Reporter: Francois Scala
  Labels: security

 When a VM is rebooted from the cloudstack GUI, the xml recreated without the 
 vnc password.
 Here is the libvirt vnc configuration from a running vm :
 graphics type='vnc' port='-1' autoport='yes' listen='0.0.0.0' 
 passwd='a671096d9ecda37e'
   listen type='address' address='0.0.0.0'/
 /graphics
 The same configuration afger a reboot :
 graphics type='vnc' port='-1' autoport='yes' listen='0.0.0.0'
   listen type='address' address='0.0.0.0'/
 /graphics



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Assigned] (CLOUDSTACK-6301) kvm : vnc password is disabled when rebooted

[John Kinsella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Kinsella reassigned CLOUDSTACK-6301:
-

Assignee: John Kinsella

 kvm : vnc password is disabled when rebooted
 

 Key: CLOUDSTACK-6301
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6301
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: KVM
Affects Versions: 4.2.0
Reporter: Francois Scala
Assignee: John Kinsella
  Labels: security

 When a VM is rebooted from the cloudstack GUI, the xml recreated without the 
 vnc password.
 Here is the libvirt vnc configuration from a running vm :
 graphics type='vnc' port='-1' autoport='yes' listen='0.0.0.0' 
 passwd='a671096d9ecda37e'
   listen type='address' address='0.0.0.0'/
 /graphics
 The same configuration afger a reboot :
 graphics type='vnc' port='-1' autoport='yes' listen='0.0.0.0'
   listen type='address' address='0.0.0.0'/
 /graphics



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-6024) template copy to primary storage uses a random source secstorage from any zone

[John Kinsella (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13947050#comment-13947050
 ] 

John Kinsella commented on CLOUDSTACK-6024:
---

Any update on this? It didn't block release, so guessing it shouldn't have 
Blocker status...

 template copy to primary storage uses a random source secstorage from any zone
 --

 Key: CLOUDSTACK-6024
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6024
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Affects Versions: 4.2.1, 4.1.2, 4.4.0
 Environment: Multiple zones where the secstorage of a zone is not 
 accessible to hosts from the other zone.
Reporter: Joris van Lieshout
Assignee: Daan Hoogland
Priority: Blocker
 Fix For: 4.3.0


 2014-02-04 15:19:07,674 DEBUG [cloud.storage.VolumeManagerImpl] 
 (Job-Executor-92:job-221857 = [ 6f2d5dbb-575e-49b9-89dd-d7567869849e ]) 
 Checking if we need to prepare 1 volumes for VM[User|xx-app01]
 2014-02-04 15:19:07,693 DEBUG [storage.image.TemplateDataFactoryImpl] 
 (Job-Executor-92:job-221857 = [ 6f2d5dbb-575e-49b9-89dd-d7567869849e ]) 
 template 467 is already in store:117, type:Image
 // store 117 is not accessible from the zone where this hypervisor lives
 2014-02-04 15:19:07,705 DEBUG [storage.datastore.PrimaryDataStoreImpl] 
 (Job-Executor-92:job-221857 = [ 6f2d5dbb-575e-49b9-89dd-d7567869849e ]) Not 
 found (templateId:467poolId:208) in template_spool_ref, persisting it
 2014-02-04 15:19:07,718 DEBUG [storage.image.TemplateDataFactoryImpl] 
 (Job-Executor-92:job-221857 = [ 6f2d5dbb-575e-49b9-89dd-d7567869849e ]) 
 template 467 is already in store:208, type:Primary
 2014-02-04 15:19:07,722 DEBUG [storage.volume.VolumeServiceImpl] 
 (Job-Executor-92:job-221857 = [ 6f2d5dbb-575e-49b9-89dd-d7567869849e ]) Found 
 template 467-2-6c05b599-95ed-34c3-b8f0-fd9c30bac938 in storage pool 208 with 
 VMTemplateStoragePool id: 36433
 2014-02-04 15:19:07,732 DEBUG [storage.volume.VolumeServiceImpl] 
 (Job-Executor-92:job-221857 = [ 6f2d5dbb-575e-49b9-89dd-d7567869849e ]) 
 Acquire lock on VMTemplateStoragePool 36433 with timeout 3600 seconds
 2014-02-04 15:19:07,737 INFO  [storage.volume.VolumeServiceImpl] 
 (Job-Executor-92:job-221857 = [ 6f2d5dbb-575e-49b9-89dd-d7567869849e ]) lock 
 is acquired for VMTemplateStoragePool 36433
 2014-02-04 15:19:07,748 DEBUG [storage.motion.AncientDataMotionStrategy] 
 (Job-Executor-92:job-221857 = [ 6f2d5dbb-575e-49b9-89dd-d7567869849e ]) 
 copyAsync inspecting src type TEMPLATE copyAsync inspecting dest type TEMPLATE
 2014-02-04 15:19:07,775 DEBUG [agent.manager.ClusteredAgentAttache] 
 (Job-Executor-92:job-221857 = [ 6f2d5dbb-575e-49b9-89dd-d7567869849e ]) Seq 
 93-1862347354: Forwarding Seq 93-1862347354:  { Cmd , MgmtId: 345052370018, 
 via: 93, Ver: v1, Flags: 100111, 
 [{org.apache.cloudstack.storage.command.CopyCommand:{srcTO:{org.apache.cloudstack.storage.to.TemplateObjectTO:{path:template/tmpl/2/467/c263eb76-3d72-3732-8cc6-42b0dad55c4d.vhd,origUrl:http://x.x.com/image/centos64x64-daily-v1b104.vhd,uuid:ca5e3f26-e9b6-41c8-a85b-df900be5673c,id:467,format:VHD,accountId:2,checksum:604a8327bd83850ed621ace2ea84402a,hvm:true,displayText:centos
  template created by hans.pl from machine name 
 centos-daily-b104,imageDataStore:{com.cloud.agent.api.to.NfsTO:{_url:nfs://.storage..xx.xxx/volumes/pool0/--1-1,_role:Image}},name:467-2-6c05b599-95ed-34c3-b8f0-fd9c30bac938,hypervisorType:XenServer}},destTO:{org.apache.cloudstack.storage.to.TemplateObjectTO:{origUrl:http://xx.xx.com/image/centos64x64-daily-v1b104.vhd,uuid:ca5e3f26-e9b6-41c8-a85b-df900be5673c,id:467,format:VHD,accountId:2,checksum:604a8327bd83850ed621ace2ea84402a,hvm:true,displayText:centos
  template created by hans.pl from machine name 
 centos-daily-b104,imageDataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:b290385b-466d-3243-a939-3d242164e034,id:208,poolType:NetworkFilesystem,host:..x.net,path:/volumes/pool0/xx-XEN-1,port:2049}},name:467-2-6c05b599-95ed-34c3-b8f0-fd9c30bac938,hypervisorType:XenServer}},executeInSequence:true,wait:10800}}]
  } to 345052370017
 ===FILE: server/src/com/cloud/storage/VolumeManagerImpl.java
 public void prepare(VirtualMachineProfile? extends VirtualMachine vm,
 DeployDestination dest) throws StorageUnavailableException,
 InsufficientStorageCapacityException, 
 ConcurrentOperationException {
 if (dest == null) {
 if (s_logger.isDebugEnabled()) {
 s_logger.debug(DeployDestination cannot be null, cannot 
 prepare Volumes for the vm: 
 + vm);
 }
   

[jira] [Commented] (CLOUDSTACK-5498) [Atomation] Marvin - Logs are not storing to folder with suite name

[John Kinsella (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-5498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13947051#comment-13947051
 ] 

John Kinsella commented on CLOUDSTACK-5498:
---

Has this been resolved?

 [Atomation] Marvin - Logs are not storing to folder with suite name
 ---

 Key: CLOUDSTACK-5498
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5498
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation, marvin
Affects Versions: 4.3.0
 Environment: Automation
Reporter: Rayees Namathponnan
Assignee: Santhosh Kumar Edukulla
Priority: Blocker
 Fix For: 4.3.0


 Configure .cfg file with below data and run automation eg test_ssvm
 },
 logger:
 {
   LogFolderPath: /Repo_30X/ipcl/cloudstack/test/logs/
 },
 globalConfig: [
 {
 name: network.gc.wait,
 value: 60
 },
 {
 
 Expected result 
 Folder test_ssvm_+timestamp should be created under 
 /Repo_30X/ipcl/cloudstack/test/logs/, and   below 3 files should be under 
 that 
 failed_plus_exceptions.txt
 results.txt
 runinfo.txt
 Actual Result 
 Folder timestamp created instead of test_ssvm_+timestamp, and i can see 
 other 3 text files; 
 Its very hard to find corresponding folder for test_ssvm, with current 
 implementation 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-6245) Security group rules on hypervisor host are lagging behind rules in DB

[John Kinsella (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13947049#comment-13947049
 ] 

John Kinsella commented on CLOUDSTACK-6245:
---

Can somebody confirm this is working and close?

 Security group rules on hypervisor host are lagging behind rules in DB
 --

 Key: CLOUDSTACK-6245
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6245
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.3.0
Reporter: edison su
Assignee: edison su
Priority: Blocker
 Fix For: 4.3.0


 Maybe due to the change in DB transaction code, we accidentally start a 
 worker thread to program security group rule on hypervisor host, inside a DB 
 transaction during add/revoke security group rule. So there is a chance that, 
 the work thread is started before the transaction is committed, thus the 
 worker thread can't find the newly added rules.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-6252) Host password is stored in the database in the clear

[John Kinsella (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13946054#comment-13946054
 ] 

John Kinsella commented on CLOUDSTACK-6252:
---

Wilder - any chance you've been able to confirm this?

 Host password is stored in the database in the clear
 

 Key: CLOUDSTACK-6252
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6252
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: Future
 Environment: Management Server running on Debian 7
 DevCloud running on XenServer 6.2
Reporter: Wilder Rodrigues

 Via the Management Server UI, when creating an advanced Zone and adding a 
 host to it, the host password is stored in the database in the clear.
 All passwords should be encrypted before stored.
 Check details below:
 mysql select * from host_details;
 ++-+++
 | id | host_id | name   | value   
|
 ++-+++
 |  1 |   1 | product_version| 6.2.0   
| 
 |  2 |   1 | com.cloud.network.Networks.RouterPrivateIpStrategy | 
 DcGlobal   | 
 |  3 |   1 | private.network.device | 
 Pool-wide network associated with eth0 | 
 |  4 |   1 | Hypervisor.Version | 4.1.5   
| 
 |  5 |   1 | Host.OS| 
 XenServer  | 
 |  6 |   1 | Host.OS.Kernel.Version | 
 2.6.32.43-0.4.1.xs1.8.0.835.170778xen  | 
 |  7 |   1 | wait   | 600 
| 
 |  8 |   1 | password   | 
 changeme   | 
 |  9 |   1 | url| 
 10.1.1.203 | 
 | 10 |   1 | username   | root
| 
 | 11 |   1 | xs620_snapshot_hotfix  | false   
| 
 | 12 |   1 | product_brand  | 
 XenServer  | 
 | 13 |   1 | product_version_text_short | 6.2 
| 
 | 14 |   1 | Host.OS.Version| 6.2.0   
| 
 | 15 |   1 | instance.name  | VM  
| 
 ++-+++



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-6252) Host password is stored in the database in the clear

[John Kinsella (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13940199#comment-13940199
 ] 

John Kinsella commented on CLOUDSTACK-6252:
---

Strange - I glanced at a 4.2 database and the values are encrypted.

Looking at the code (com.cloud.host.dao.HostDetailsDaoImpl.persist()) it should 
be getting encrypted:

if (password.equals(detail.getKey())) {
value = DBEncryptionUtil.encrypt(value);
}

Do you have a db encryption key at /etc/cloudstack/management/key, or do you 
see errors mentioning secret key in your management logs?


 Host password is stored in the database in the clear
 

 Key: CLOUDSTACK-6252
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6252
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: Future
 Environment: Management Server running on Debian 7
 DevCloud running on XenServer 6.2
Reporter: Wilder Rodrigues

 Via the Management Server UI, when creating an advanced Zone and adding a 
 host to it, the host password is stored in the database in the clear.
 All passwords should be encrypted before stored.
 Check details below:
 mysql select * from host_details;
 ++-+++
 | id | host_id | name   | value   
|
 ++-+++
 |  1 |   1 | product_version| 6.2.0   
| 
 |  2 |   1 | com.cloud.network.Networks.RouterPrivateIpStrategy | 
 DcGlobal   | 
 |  3 |   1 | private.network.device | 
 Pool-wide network associated with eth0 | 
 |  4 |   1 | Hypervisor.Version | 4.1.5   
| 
 |  5 |   1 | Host.OS| 
 XenServer  | 
 |  6 |   1 | Host.OS.Kernel.Version | 
 2.6.32.43-0.4.1.xs1.8.0.835.170778xen  | 
 |  7 |   1 | wait   | 600 
| 
 |  8 |   1 | password   | 
 changeme   | 
 |  9 |   1 | url| 
 10.1.1.203 | 
 | 10 |   1 | username   | root
| 
 | 11 |   1 | xs620_snapshot_hotfix  | false   
| 
 | 12 |   1 | product_brand  | 
 XenServer  | 
 | 13 |   1 | product_version_text_short | 6.2 
| 
 | 14 |   1 | Host.OS.Version| 6.2.0   
| 
 | 15 |   1 | instance.name  | VM  
| 
 ++-+++



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Closed] (CLOUDSTACK-6157) devcloud setup db functionality broken by mysql dependency cleanup

[John Kinsella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Kinsella closed CLOUDSTACK-6157.
-


 devcloud setup db functionality broken by mysql dependency cleanup
 --

 Key: CLOUDSTACK-6157
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6157
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: DevCloud
Reporter: John Kinsella
Priority: Blocker
 Fix For: 4.3.0


 With the removal of mysql compile-time dependencies, maven is no longer able 
 to manipulate the devcloud database without developer supplying the mysql 
 JDBC connector and configuring classpath appropriately.
 Need to either update documentation, or come up with a legally acceptable 
 technical solution.
 Expected result:
 Successfully deployed devcloud db
 Actual result:
 mvn -P developer -pl developer,tools/devcloud -Ddeploydb
 ...
  Running query: drop database if exists `cloud`
 SQL exception in trying initDB: java.sql.SQLException: No suitable driver 
 found for jdbc:mysql://localhost:3306/



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Resolved] (CLOUDSTACK-6157) devcloud setup db functionality broken by mysql dependency cleanup

[John Kinsella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Kinsella resolved CLOUDSTACK-6157.
---

Resolution: Fixed

Hugo fixed this in the following commits on master:

e883877c7a6f9df04b572afd4ee5f10d265bcc3a
afc188cb5c72e316975799c95529e8692ddcb94b


 devcloud setup db functionality broken by mysql dependency cleanup
 --

 Key: CLOUDSTACK-6157
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6157
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: DevCloud
Reporter: John Kinsella
Priority: Blocker
 Fix For: 4.3.0


 With the removal of mysql compile-time dependencies, maven is no longer able 
 to manipulate the devcloud database without developer supplying the mysql 
 JDBC connector and configuring classpath appropriately.
 Need to either update documentation, or come up with a legally acceptable 
 technical solution.
 Expected result:
 Successfully deployed devcloud db
 Actual result:
 mvn -P developer -pl developer,tools/devcloud -Ddeploydb
 ...
  Running query: drop database if exists `cloud`
 SQL exception in trying initDB: java.sql.SQLException: No suitable driver 
 found for jdbc:mysql://localhost:3306/



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Created] (CLOUDSTACK-6166) Should we be recommending ASYNC NFS in documentation?

[John Kinsella (JIRA)]

John Kinsella created CLOUDSTACK-6166:
-

 Summary: Should we be recommending ASYNC NFS in documentation?
 Key: CLOUDSTACK-6166
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6166
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Doc
Reporter: John Kinsella
Priority: Minor


Looking at current and past installation, we recommend users export secondary 
storage with async NFS:

/export  *(rw,async,no_root_squash,no_subtree_check)

Generally async mode is considered risky from a data reliability point of view 
(eg 
http://serverfault.com/questions/328931/how-dangerous-is-nfs-async-when-raid-bbu-and-ups-are-present
 ).

While advanced users will see this and ignore it, we probably shouldn't be 
guiding new ACS users towards async NFS...




--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (CLOUDSTACK-6166) Should we be recommending ASYNC NFS in documentation?

[John Kinsella (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13910675#comment-13910675
 ] 

John Kinsella commented on CLOUDSTACK-6166:
---

Would be helpful if you could add some example logs...

 Should we be recommending ASYNC NFS in documentation?
 -

 Key: CLOUDSTACK-6166
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6166
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Doc
Reporter: John Kinsella
Priority: Minor

 Looking at current and past installation, we recommend users export secondary 
 storage with async NFS:
 /export  *(rw,async,no_root_squash,no_subtree_check)
 Generally async mode is considered risky from a data reliability point of 
 view (eg 
 http://serverfault.com/questions/328931/how-dangerous-is-nfs-async-when-raid-bbu-and-ups-are-present
  ).
 While advanced users will see this and ignore it, we probably shouldn't be 
 guiding new ACS users towards async NFS...



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Updated] (CLOUDSTACK-6157) devcloud setup db functionality broken by mysql dependency cleanup

[John Kinsella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Kinsella updated CLOUDSTACK-6157:
--

Priority: Blocker  (was: Major)

 devcloud setup db functionality broken by mysql dependency cleanup
 --

 Key: CLOUDSTACK-6157
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6157
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: DevCloud
Reporter: John Kinsella
Priority: Blocker
 Fix For: 4.3.0


 With the removal of mysql compile-time dependencies (CLOUDSTACK-6152), maven 
 is no longer able to manipulate the devcloud database without developer 
 supplying the mysql JDBC connector and configuring classpath appropriately.
 Need to either update documentation, or come up with a legally acceptable 
 technical solution.
 Expected result:
 Successfully deployed devcloud db
 Actual result:
 mvn -P developer -pl developer,tools/devcloud -Ddeploydb
 ...
  Running query: drop database if exists `cloud`
 SQL exception in trying initDB: java.sql.SQLException: No suitable driver 
 found for jdbc:mysql://localhost:3306/



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Created] (CLOUDSTACK-6157) devcloud setup db functionality broken by mysql dependency cleanup

[John Kinsella (JIRA)]

John Kinsella created CLOUDSTACK-6157:
-

 Summary: devcloud setup db functionality broken by mysql 
dependency cleanup
 Key: CLOUDSTACK-6157
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6157
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: DevCloud
Reporter: John Kinsella
 Fix For: 4.3.0


With the removal of mysql compile-time dependencies (CLOUDSTACK-6152), maven is 
no longer able to manipulate the devcloud database without developer supplying 
the mysql JDBC connector and configuring classpath appropriately.

Need to either update documentation, or come up with a legally acceptable 
technical solution.

Expected result:
Successfully deployed devcloud db

Actual result:
mvn -P developer -pl developer,tools/devcloud -Ddeploydb
...
 Running query: drop database if exists `cloud`
SQL exception in trying initDB: java.sql.SQLException: No suitable driver found 
for jdbc:mysql://localhost:3306/



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Updated] (CLOUDSTACK-6157) devcloud setup db functionality broken by mysql dependency cleanup

[John Kinsella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Kinsella updated CLOUDSTACK-6157:
--

Description: 
With the removal of mysql compile-time dependencies, maven is no longer able to 
manipulate the devcloud database without developer supplying the mysql JDBC 
connector and configuring classpath appropriately.

Need to either update documentation, or come up with a legally acceptable 
technical solution.

Expected result:
Successfully deployed devcloud db

Actual result:
mvn -P developer -pl developer,tools/devcloud -Ddeploydb
...
 Running query: drop database if exists `cloud`
SQL exception in trying initDB: java.sql.SQLException: No suitable driver found 
for jdbc:mysql://localhost:3306/

  was:
With the removal of mysql compile-time dependencies (CLOUDSTACK-6152), maven is 
no longer able to manipulate the devcloud database without developer supplying 
the mysql JDBC connector and configuring classpath appropriately.

Need to either update documentation, or come up with a legally acceptable 
technical solution.

Expected result:
Successfully deployed devcloud db

Actual result:
mvn -P developer -pl developer,tools/devcloud -Ddeploydb
...
 Running query: drop database if exists `cloud`
SQL exception in trying initDB: java.sql.SQLException: No suitable driver found 
for jdbc:mysql://localhost:3306/


 devcloud setup db functionality broken by mysql dependency cleanup
 --

 Key: CLOUDSTACK-6157
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6157
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: DevCloud
Reporter: John Kinsella
Priority: Blocker
 Fix For: 4.3.0


 With the removal of mysql compile-time dependencies, maven is no longer able 
 to manipulate the devcloud database without developer supplying the mysql 
 JDBC connector and configuring classpath appropriately.
 Need to either update documentation, or come up with a legally acceptable 
 technical solution.
 Expected result:
 Successfully deployed devcloud db
 Actual result:
 mvn -P developer -pl developer,tools/devcloud -Ddeploydb
 ...
  Running query: drop database if exists `cloud`
 SQL exception in trying initDB: java.sql.SQLException: No suitable driver 
 found for jdbc:mysql://localhost:3306/



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Created] (CLOUDSTACK-6156) Retired maven repo breaking awsapi build and RPM packaging

[John Kinsella (JIRA)]

John Kinsella created CLOUDSTACK-6156:
-

 Summary: Retired maven repo breaking awsapi build and RPM packaging
 Key: CLOUDSTACK-6156
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6156
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: AWSAPI
Affects Versions: 4.2.0, 4.3.0
Reporter: John Kinsella
Assignee: John Kinsella
Priority: Critical


The awsapi sub-project depends on several jars from Apache Axis-Rampart. 

The Rampart poms have a broken maven repo hard-coded into them:

urlhttp://shibboleth.internet2.edu/downloads/maven2//url

Which does not return a 404 when maven attempts to fetch a jar, but HTTP 200. 
*golf clap*

Rampart is aware of this (see RAMPART-393) but the fix won't be released until 
version 1.7, whenever that is.

CLOUDSTACK-744 shows we hit this before for opensaml, although I'm not sure 
when the rampart jars started erroring out.

From my research so far, looks like rampart isn't being used and the rampart 
dependencies can be removed from the pom...

Steps to reproduce:
mvn -P awsapi

Expected results:
Happily built awsapi package

Actual results:
...
Downloaded: 
http://repo.maven.apache.org/maven2/org/apache/rampart/rampart-policy/1.5.1/rampart-policy-1.5.1.pom
 (3 KB at 116.1 KB/sec)
Downloading: 
http://shibboleth.internet2.edu/downloads/maven2/org/apache/rampart/rampart-policy/1.5.1/rampart-policy-1.5.1.pom
Feb 21, 2014 12:18:31 PM 
org.apache.maven.wagon.providers.http.httpclient.client.protocol.ResponseProcessCookies
 processCookies
WARNING: Invalid cookie header: Set-Cookie:  django_language=en-us; 
expires=time.struct_time(tm_year=2015, tm_mon=2, tm_mday=21, tm_hour=15, 
tm_min=18, tm_sec=33, tm_wday=5, tm_yday=52, tm_isdst=0); Max-Age=31536000; 
Path=/. Unable to parse expires attribute: time.struct_time(tm_year=2015, 
tm_mon=2, tm_mday=21, tm_hour=15, tm_min=18, tm_sec=33, tm_wday=5, tm_yday=52, 
tm_isdst=0)
Feb 21, 2014 12:18:32 PM 
org.apache.maven.wagon.providers.http.httpclient.client.protocol.ResponseProcessCookies
 processCookies
WARNING: Invalid cookie header: Set-Cookie:  django_language=en-us; 
expires=time.struct_time(tm_year=2015, tm_mon=2, tm_mday=21, tm_hour=15, 
tm_min=18, tm_sec=33, tm_wday=5, tm_yday=52, tm_isdst=0); Max-Age=31536000; 
Path=/. Unable to parse expires attribute: time.struct_time(tm_year=2015, 
tm_mon=2, tm_mday=21, tm_hour=15, tm_min=18, tm_sec=33, tm_wday=5, tm_yday=52, 
tm_isdst=0)
Feb 21, 2014 12:18:32 PM 
org.apache.maven.wagon.providers.http.httpclient.client.protocol.ResponseProcessCookies
 processCookies
...
[WARNING] Invalid POM for org.apache.rampart:rampart-policy:jar:1.5.1, 
transitive dependencies (if any) will not be available, enable debug logging 
for more details
etc, etc



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Updated] (CLOUDSTACK-6156) Retired maven repo breaking awsapi build and RPM packaging

[John Kinsella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Kinsella updated CLOUDSTACK-6156:
--

Description: 
The awsapi sub-project depends on several jars from Apache Axis-Rampart. 

The Rampart poms have a broken maven repo hard-coded into them:

urlhttp://shibboleth.internet2.edu/downloads/maven2//url

Which does not return a 404 when maven attempts to fetch a jar, but HTTP 200. 
*golf clap*

Rampart is aware of this (see RAMPART-393) but the fix won't be released until 
version 1.7, whenever that is.

CLOUDSTACK-744 shows we hit this before for opensaml, although I'm not sure 
when the rampart jars started erroring out.

From my research so far, looks like rampart isn't being used and the rampart 
dependencies can be removed from the pom...

Steps to reproduce (On a clean system with no cached maven repo, and not using 
a maven repo mirror):
mvn -P awsapi

Expected results:
Happily built awsapi package

Actual results:
...
Downloaded: 
http://repo.maven.apache.org/maven2/org/apache/rampart/rampart-policy/1.5.1/rampart-policy-1.5.1.pom
 (3 KB at 116.1 KB/sec)
Downloading: 
http://shibboleth.internet2.edu/downloads/maven2/org/apache/rampart/rampart-policy/1.5.1/rampart-policy-1.5.1.pom
Feb 21, 2014 12:18:31 PM 
org.apache.maven.wagon.providers.http.httpclient.client.protocol.ResponseProcessCookies
 processCookies
WARNING: Invalid cookie header: Set-Cookie:  django_language=en-us; 
expires=time.struct_time(tm_year=2015, tm_mon=2, tm_mday=21, tm_hour=15, 
tm_min=18, tm_sec=33, tm_wday=5, tm_yday=52, tm_isdst=0); Max-Age=31536000; 
Path=/. Unable to parse expires attribute: time.struct_time(tm_year=2015, 
tm_mon=2, tm_mday=21, tm_hour=15, tm_min=18, tm_sec=33, tm_wday=5, tm_yday=52, 
tm_isdst=0)
Feb 21, 2014 12:18:32 PM 
org.apache.maven.wagon.providers.http.httpclient.client.protocol.ResponseProcessCookies
 processCookies
WARNING: Invalid cookie header: Set-Cookie:  django_language=en-us; 
expires=time.struct_time(tm_year=2015, tm_mon=2, tm_mday=21, tm_hour=15, 
tm_min=18, tm_sec=33, tm_wday=5, tm_yday=52, tm_isdst=0); Max-Age=31536000; 
Path=/. Unable to parse expires attribute: time.struct_time(tm_year=2015, 
tm_mon=2, tm_mday=21, tm_hour=15, tm_min=18, tm_sec=33, tm_wday=5, tm_yday=52, 
tm_isdst=0)
Feb 21, 2014 12:18:32 PM 
org.apache.maven.wagon.providers.http.httpclient.client.protocol.ResponseProcessCookies
 processCookies
...
[WARNING] Invalid POM for org.apache.rampart:rampart-policy:jar:1.5.1, 
transitive dependencies (if any) will not be available, enable debug logging 
for more details
etc, etc

  was:
The awsapi sub-project depends on several jars from Apache Axis-Rampart. 

The Rampart poms have a broken maven repo hard-coded into them:

urlhttp://shibboleth.internet2.edu/downloads/maven2//url

Which does not return a 404 when maven attempts to fetch a jar, but HTTP 200. 
*golf clap*

Rampart is aware of this (see RAMPART-393) but the fix won't be released until 
version 1.7, whenever that is.

CLOUDSTACK-744 shows we hit this before for opensaml, although I'm not sure 
when the rampart jars started erroring out.

From my research so far, looks like rampart isn't being used and the rampart 
dependencies can be removed from the pom...

Steps to reproduce:
mvn -P awsapi

Expected results:
Happily built awsapi package

Actual results:
...
Downloaded: 
http://repo.maven.apache.org/maven2/org/apache/rampart/rampart-policy/1.5.1/rampart-policy-1.5.1.pom
 (3 KB at 116.1 KB/sec)
Downloading: 
http://shibboleth.internet2.edu/downloads/maven2/org/apache/rampart/rampart-policy/1.5.1/rampart-policy-1.5.1.pom
Feb 21, 2014 12:18:31 PM 
org.apache.maven.wagon.providers.http.httpclient.client.protocol.ResponseProcessCookies
 processCookies
WARNING: Invalid cookie header: Set-Cookie:  django_language=en-us; 
expires=time.struct_time(tm_year=2015, tm_mon=2, tm_mday=21, tm_hour=15, 
tm_min=18, tm_sec=33, tm_wday=5, tm_yday=52, tm_isdst=0); Max-Age=31536000; 
Path=/. Unable to parse expires attribute: time.struct_time(tm_year=2015, 
tm_mon=2, tm_mday=21, tm_hour=15, tm_min=18, tm_sec=33, tm_wday=5, tm_yday=52, 
tm_isdst=0)
Feb 21, 2014 12:18:32 PM 
org.apache.maven.wagon.providers.http.httpclient.client.protocol.ResponseProcessCookies
 processCookies
WARNING: Invalid cookie header: Set-Cookie:  django_language=en-us; 
expires=time.struct_time(tm_year=2015, tm_mon=2, tm_mday=21, tm_hour=15, 
tm_min=18, tm_sec=33, tm_wday=5, tm_yday=52, tm_isdst=0); Max-Age=31536000; 
Path=/. Unable to parse expires attribute: time.struct_time(tm_year=2015, 
tm_mon=2, tm_mday=21, tm_hour=15, tm_min=18, tm_sec=33, tm_wday=5, tm_yday=52, 
tm_isdst=0)
Feb 21, 2014 12:18:32 PM 
org.apache.maven.wagon.providers.http.httpclient.client.protocol.ResponseProcessCookies
 processCookies
...
[WARNING] Invalid POM for org.apache.rampart:rampart-policy:jar:1.5.1, 
transitive dependencies (if any) will not be available, enable 

[jira] [Commented] (CLOUDSTACK-6128) Clean up over-permissive filesystem grants in Cloudstack

[John Kinsella (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13906582#comment-13906582
 ] 

John Kinsella commented on CLOUDSTACK-6128:
---

Just noticed snapshots and volumes directories on secondary storage are also 
777. Making a note here in case it's not spotted in the code.


 Clean up over-permissive filesystem grants in Cloudstack
 

 Key: CLOUDSTACK-6128
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6128
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Reporter: John Kinsella
  Labels: security
 Fix For: 4.4.0


 It's not uncommon to find Java code and scripts in ACS that are 
 over-permissive in their attempts to grant UNIX filesystem permissions. The 
 following is an example from 
 com.cloud.hypervisor.vmware.manager.VmwareManagerImpl.prepareSecondaryStorage:
 script.add(-R, 777, mountPoint);
 We should understand and document the UNIX user, group, and filesystem 
 ownership requirements. If we truely need wide-open filesystem permissions, 
 that too should be documented.
 Also, the code should not be blindly attempting to change filesystem 
 permissions and ignoring the result of the attempts. Code should first check 
 to see if a change is necessary, then make the necessary change, and then 
 inspect the results, not display an error that may or may not impact proper 
 execution of the system.
 /soapbox ;)



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Created] (CLOUDSTACK-6128) Clean up over-permissive filesystem grants in Cloudstack

[John Kinsella (JIRA)]

John Kinsella created CLOUDSTACK-6128:
-

 Summary: Clean up over-permissive filesystem grants in Cloudstack
 Key: CLOUDSTACK-6128
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6128
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Reporter: John Kinsella
 Fix For: 4.4.0


It's not uncommon to find Java code and scripts in ACS that are over-permissive 
in their attempts to grant UNIX filesystem permissions. The following is an 
example from 
com.cloud.hypervisor.vmware.manager.VmwareManagerImpl.prepareSecondaryStorage:

script.add(-R, 777, mountPoint);

We should understand and document the UNIX user, group, and filesystem 
ownership requirements. If we truely need wide-open filesystem permissions, 
that too should be documented.

Also, the code should not be blindly attempting to change filesystem 
permissions and ignoring the result of the attempts. Code should first check to 
see if a change is necessary, then make the necessary change, and then inspect 
the results, not display an error that may or may not impact proper execution 
of the system.

/soapbox ;)




--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Created] (CLOUDSTACK-6129) Script names are hard-coded into some init scripts

[John Kinsella (JIRA)]

John Kinsella created CLOUDSTACK-6129:
-

 Summary: Script names are hard-coded into some init scripts
 Key: CLOUDSTACK-6129
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6129
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Install and Setup
Reporter: John Kinsella
 Fix For: 4.4.0


Some of the init scripts which ACS installs have the script name hard-coded 
into it. An example from 
python/distro/sles/SYSCONFDIR/init.d/cloud-ipallocator.in:

whatami=cloud-external-ipallocator
...
echo $Usage: $whatami {start|stop|restart|status|help}

This is bad practice, $0 should be used to get a script's name, otherwise - as 
shown in this example - things will fail or folks will be confused.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Assigned] (CLOUDSTACK-6129) Script names are hard-coded into some init scripts

[John Kinsella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Kinsella reassigned CLOUDSTACK-6129:
-

Assignee: John Kinsella

 Script names are hard-coded into some init scripts
 --

 Key: CLOUDSTACK-6129
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6129
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Install and Setup
Reporter: John Kinsella
Assignee: John Kinsella
 Fix For: 4.4.0


 Some of the init scripts which ACS installs have the script name hard-coded 
 into it. An example from 
 python/distro/sles/SYSCONFDIR/init.d/cloud-ipallocator.in:
 whatami=cloud-external-ipallocator
 ...
 echo $Usage: $whatami {start|stop|restart|status|help}
 This is bad practice, $0 should be used to get a script's name, otherwise - 
 as shown in this example - things will fail or folks will be confused.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Resolved] (CLOUDSTACK-6129) Script names are hard-coded into some init scripts

[John Kinsella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Kinsella resolved CLOUDSTACK-6129.
---

Resolution: Fixed

There I fixed it.

 Script names are hard-coded into some init scripts
 --

 Key: CLOUDSTACK-6129
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6129
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Install and Setup
Reporter: John Kinsella
Assignee: John Kinsella
 Fix For: 4.4.0


 Some of the init scripts which ACS installs have the script name hard-coded 
 into it. An example from 
 python/distro/sles/SYSCONFDIR/init.d/cloud-ipallocator.in:
 whatami=cloud-external-ipallocator
 ...
 echo $Usage: $whatami {start|stop|restart|status|help}
 This is bad practice, $0 should be used to get a script's name, otherwise - 
 as shown in this example - things will fail or folks will be confused.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Closed] (CLOUDSTACK-6129) Script names are hard-coded into some init scripts

[John Kinsella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Kinsella closed CLOUDSTACK-6129.
-


 Script names are hard-coded into some init scripts
 --

 Key: CLOUDSTACK-6129
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6129
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Install and Setup
Reporter: John Kinsella
Assignee: John Kinsella
 Fix For: 4.4.0


 Some of the init scripts which ACS installs have the script name hard-coded 
 into it. An example from 
 python/distro/sles/SYSCONFDIR/init.d/cloud-ipallocator.in:
 whatami=cloud-external-ipallocator
 ...
 echo $Usage: $whatami {start|stop|restart|status|help}
 This is bad practice, $0 should be used to get a script's name, otherwise - 
 as shown in this example - things will fail or folks will be confused.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Resolved] (CLOUDSTACK-6123) package.sh fails when env var GREP=--color=always

[John Kinsella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Kinsella resolved CLOUDSTACK-6123.
---

Resolution: Fixed

Fixed with commit. Tested builds on master and 4.2 branches.

 package.sh fails when env var GREP=--color=always
 -

 Key: CLOUDSTACK-6123
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6123
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Packaging
Affects Versions: 4.2.1, 4.3.0, 4.4.0
 Environment: CentOS 6.4
 Shell environment variable GREP=--color=always
Reporter: John Kinsella
Assignee: John Kinsella
Priority: Minor

 When attempting to build CloudStack RPMs on a system where the user's shell 
 environment is setting grep's colors to always on via the GREP environment 
 variable, 
 $ ./package.sh
 4.2.1-SNAPSHOT
 error: line 37: Illegal char in: Version:   4.2.1
 Looking at the source directory and tarball built for the RPM build process, 
 the issue becomes more clear:
 $ ls -l dist/rpmbuild/SOURCES/
 total 533172
 drwx--. 32 build build  4096 Feb 15 17:54 
 cloudstack-?[01;31m?[K4.?[m?[K2.1-SNAPSHOT
 -rw---.  1 build build 545959884 Feb 15 18:45 
 cloudstack-?[01;31m?[K4.?[m?[K2.1-SNAPSHOT.tgz



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Created] (CLOUDSTACK-6123) package.sh fails when env var GREP=--color=always

[John Kinsella (JIRA)]

John Kinsella created CLOUDSTACK-6123:
-

 Summary: package.sh fails when env var GREP=--color=always
 Key: CLOUDSTACK-6123
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6123
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Packaging
Affects Versions: 4.2.1, 4.3.0, 4.4.0
 Environment: CentOS 6.4
Shell environment variable GREP=--color=always
Reporter: John Kinsella
Assignee: John Kinsella
Priority: Minor


When attempting to build CloudStack RPMs on a system where the user's shell 
environment is setting grep's colors to always on via the GREP environment 
variable, 

$ ./package.sh
4.2.1-SNAPSHOT
error: line 37: Illegal char in: Version:   4.2.1

Looking at the source directory and tarball built for the RPM build process, 
the issue becomes more clear:

$ ls -l dist/rpmbuild/SOURCES/
total 533172
drwx--. 32 build build  4096 Feb 15 17:54 
cloudstack-?[01;31m?[K4.?[m?[K2.1-SNAPSHOT
-rw---.  1 build build 545959884 Feb 15 18:45 
cloudstack-?[01;31m?[K4.?[m?[K2.1-SNAPSHOT.tgz




--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (CLOUDSTACK-6123) package.sh fails when env var GREP=--color=always

[John Kinsella (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13902620#comment-13902620
 ] 

John Kinsella commented on CLOUDSTACK-6123:
---

The fix for this is a one-liner so I'll commit it, but I suspect this probably 
not the only place in the code where grep could break like this. So larger 
question is if this is a ACS problem, or just user problem...

 package.sh fails when env var GREP=--color=always
 -

 Key: CLOUDSTACK-6123
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6123
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Packaging
Affects Versions: 4.2.1, 4.3.0, 4.4.0
 Environment: CentOS 6.4
 Shell environment variable GREP=--color=always
Reporter: John Kinsella
Assignee: John Kinsella
Priority: Minor

 When attempting to build CloudStack RPMs on a system where the user's shell 
 environment is setting grep's colors to always on via the GREP environment 
 variable, 
 $ ./package.sh
 4.2.1-SNAPSHOT
 error: line 37: Illegal char in: Version:   4.2.1
 Looking at the source directory and tarball built for the RPM build process, 
 the issue becomes more clear:
 $ ls -l dist/rpmbuild/SOURCES/
 total 533172
 drwx--. 32 build build  4096 Feb 15 17:54 
 cloudstack-?[01;31m?[K4.?[m?[K2.1-SNAPSHOT
 -rw---.  1 build build 545959884 Feb 15 18:45 
 cloudstack-?[01;31m?[K4.?[m?[K2.1-SNAPSHOT.tgz



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Updated] (CLOUDSTACK-6123) package.sh fails when env var GREP=--color=always

[John Kinsella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Kinsella updated CLOUDSTACK-6123:
--

Description: 
When attempting to build CloudStack RPMs on a system where the user's shell 
environment is setting grep's colors to always on via the GREP environment 
variable, 

$ ./package.sh
4.2.1-SNAPSHOT
error: line 37: Illegal char in: Version:   4.2.1

Looking at the source directory and tarball built for the RPM build process, 
the issue becomes more clear:

$ ls -l dist/rpmbuild/SOURCES/
total 533172
drwx--. 32 build build  4096 Feb 15 17:54 
cloudstack-?[01;31m?[K4.?[m?[K2.1-SNAPSHOT
-rw---.  1 build build 545959884 Feb 15 18:45 
cloudstack-?[01;31m?[K4.?[m?[K2.1-SNAPSHOT.tgz

  was:
When attempting to build CloudStack RPMs on a system where the user's shell 
environment is setting grep's colors to always on via the GREP environment 
variable, 

$ ./package.sh
4.2.1-SNAPSHOT
error: line 37: Illegal char in: Version:   4.2.1

Looking at the source directory and tarball built for the RPM build process, 
the issue becomes more clear:

{noformat}
$ ls -l dist/rpmbuild/SOURCES/
total 533172
drwx--. 32 build build  4096 Feb 15 17:54 
cloudstack-?[01;31m?[K4.?[m?[K2.1-SNAPSHOT
-rw---.  1 build build 545959884 Feb 15 18:45 
cloudstack-?[01;31m?[K4.?[m?[K2.1-SNAPSHOT.tgz
{noformat}



 package.sh fails when env var GREP=--color=always
 -

 Key: CLOUDSTACK-6123
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6123
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Packaging
Affects Versions: 4.2.1, 4.3.0, 4.4.0
 Environment: CentOS 6.4
 Shell environment variable GREP=--color=always
Reporter: John Kinsella
Assignee: John Kinsella
Priority: Minor

 When attempting to build CloudStack RPMs on a system where the user's shell 
 environment is setting grep's colors to always on via the GREP environment 
 variable, 
 $ ./package.sh
 4.2.1-SNAPSHOT
 error: line 37: Illegal char in: Version:   4.2.1
 Looking at the source directory and tarball built for the RPM build process, 
 the issue becomes more clear:
 $ ls -l dist/rpmbuild/SOURCES/
 total 533172
 drwx--. 32 build build  4096 Feb 15 17:54 
 cloudstack-?[01;31m?[K4.?[m?[K2.1-SNAPSHOT
 -rw---.  1 build build 545959884 Feb 15 18:45 
 cloudstack-?[01;31m?[K4.?[m?[K2.1-SNAPSHOT.tgz



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Updated] (CLOUDSTACK-6123) package.sh fails when env var GREP=--color=always

[John Kinsella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Kinsella updated CLOUDSTACK-6123:
--

Description: 
When attempting to build CloudStack RPMs on a system where the user's shell 
environment is setting grep's colors to always on via the GREP environment 
variable, 

$ ./package.sh
4.2.1-SNAPSHOT
error: line 37: Illegal char in: Version:   4.2.1

Looking at the source directory and tarball built for the RPM build process, 
the issue becomes more clear:

{noformat}
$ ls -l dist/rpmbuild/SOURCES/
total 533172
drwx--. 32 build build  4096 Feb 15 17:54 
cloudstack-?[01;31m?[K4.?[m?[K2.1-SNAPSHOT
-rw---.  1 build build 545959884 Feb 15 18:45 
cloudstack-?[01;31m?[K4.?[m?[K2.1-SNAPSHOT.tgz
{noformat}


  was:
When attempting to build CloudStack RPMs on a system where the user's shell 
environment is setting grep's colors to always on via the GREP environment 
variable, 

$ ./package.sh
4.2.1-SNAPSHOT
error: line 37: Illegal char in: Version:   4.2.1

Looking at the source directory and tarball built for the RPM build process, 
the issue becomes more clear:

$ ls -l dist/rpmbuild/SOURCES/
total 533172
drwx--. 32 build build  4096 Feb 15 17:54 
cloudstack-?[01;31m?[K4.?[m?[K2.1-SNAPSHOT
-rw---.  1 build build 545959884 Feb 15 18:45 
cloudstack-?[01;31m?[K4.?[m?[K2.1-SNAPSHOT.tgz



 package.sh fails when env var GREP=--color=always
 -

 Key: CLOUDSTACK-6123
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6123
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Packaging
Affects Versions: 4.2.1, 4.3.0, 4.4.0
 Environment: CentOS 6.4
 Shell environment variable GREP=--color=always
Reporter: John Kinsella
Assignee: John Kinsella
Priority: Minor

 When attempting to build CloudStack RPMs on a system where the user's shell 
 environment is setting grep's colors to always on via the GREP environment 
 variable, 
 $ ./package.sh
 4.2.1-SNAPSHOT
 error: line 37: Illegal char in: Version:   4.2.1
 Looking at the source directory and tarball built for the RPM build process, 
 the issue becomes more clear:
 {noformat}
 $ ls -l dist/rpmbuild/SOURCES/
 total 533172
 drwx--. 32 build build  4096 Feb 15 17:54 
 cloudstack-?[01;31m?[K4.?[m?[K2.1-SNAPSHOT
 -rw---.  1 build build 545959884 Feb 15 18:45 
 cloudstack-?[01;31m?[K4.?[m?[K2.1-SNAPSHOT.tgz
 {noformat}



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Created] (CLOUDSTACK-5243) SSVM responds with timestamp

[John Kinsella (JIRA)]

John Kinsella created CLOUDSTACK-5243:
-

 Summary: SSVM responds with timestamp
 Key: CLOUDSTACK-5243
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5243
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Affects Versions: 4.2.0
Reporter: John Kinsella
 Fix For: 4.3.0


Scanners report SSVM responded with a TCP timestamp and that “the TCP timestamp 
response can be used to approximate the remote host's uptime, potentially 
aiding in further attacks. Additionally, some operating systems can be 
fingerprinted based on the behavior of their TCP timestamps.”  The fix is 
straightforward:

Identified by: Demetrius Tsitrelis from Citrix 



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (CLOUDSTACK-5243) SSVM responds with timestamp

[John Kinsella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-5243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Kinsella updated CLOUDSTACK-5243:
--

Description: 
Scanners report SSVM responded with a TCP timestamp and that “the TCP timestamp 
response can be used to approximate the remote host's uptime, potentially 
aiding in further attacks. Additionally, some operating systems can be 
fingerprinted based on the behavior of their TCP timestamps.”  The fix is 
straightforward:

Set the value of net.ipv4.tcp_timestamps to 0 by running the following command:
sysctl -w net.ipv4.tcp_timestamps=0
Additionally, put the following value in the default sysctl configuration file, 
generally sysctl.conf:
net.ipv4.tcp_timestamps=0


Identified by: Demetrius Tsitrelis from Citrix 

  was:
Scanners report SSVM responded with a TCP timestamp and that “the TCP timestamp 
response can be used to approximate the remote host's uptime, potentially 
aiding in further attacks. Additionally, some operating systems can be 
fingerprinted based on the behavior of their TCP timestamps.”  The fix is 
straightforward:

Identified by: Demetrius Tsitrelis from Citrix 


 SSVM responds with timestamp
 

 Key: CLOUDSTACK-5243
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5243
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Affects Versions: 4.2.0
Reporter: John Kinsella
  Labels: security
 Fix For: 4.3.0


 Scanners report SSVM responded with a TCP timestamp and that “the TCP 
 timestamp response can be used to approximate the remote host's uptime, 
 potentially aiding in further attacks. Additionally, some operating systems 
 can be fingerprinted based on the behavior of their TCP timestamps.”  The fix 
 is straightforward:
 Set the value of net.ipv4.tcp_timestamps to 0 by running the following 
 command:
 sysctl -w net.ipv4.tcp_timestamps=0
 Additionally, put the following value in the default sysctl configuration 
 file, generally sysctl.conf:
 net.ipv4.tcp_timestamps=0
 Identified by: Demetrius Tsitrelis from Citrix 



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Created] (CLOUDSTACK-5064) Add a user preferences link to ACS UI

[John Kinsella (JIRA)]

John Kinsella created CLOUDSTACK-5064:
-

 Summary: Add a user preferences link to ACS UI 
 Key: CLOUDSTACK-5064
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5064
 Project: CloudStack
  Issue Type: Improvement
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: UI
Affects Versions: 4.2.0
Reporter: John Kinsella


Users sometimes are confused on how to change their user/password info within 
the ACS UI. A user preferences link near the top of the page that links to 
the current user's details page would be useful.

Example thread on subject: 
http://mail-archives.apache.org/mod_mbox/cloudstack-users/201311.mbox/browser



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Created] (CLOUDSTACK-5026) VPN Creation dialog doesn't expand for larger pre-shared keys

[John Kinsella (JIRA)]

John Kinsella created CLOUDSTACK-5026:
-

 Summary: VPN Creation dialog doesn't expand for larger pre-shared 
keys
 Key: CLOUDSTACK-5026
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5026
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Affects Versions: 4.2.0
 Environment: Advanced networking
Reporter: John Kinsella


Steps to reproduce :
1) Set up zone with advanced networking, get hypervisor up, etc.
2) Under Global Settings, modify remote.access.vpn.psk.length to something like 
48. Save, restart mgmt server.
2) Under Network, select a guest network, View IP addresses, select an IP that 
does not yet have a VPN assigned to it.
3) Click the Enable VPN icon, confirm you wish to create a VPN.
4) Upon success of creating the VPN setup, the ACS UI will display a status 
popup with the VPN IP and PSK. After about 30 characters, it will overrun the 
edge of the dialog box (see screenshot)




--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (CLOUDSTACK-5026) VPN Creation dialog doesn't expand for larger pre-shared keys

[John Kinsella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-5026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Kinsella updated CLOUDSTACK-5026:
--

Attachment: vpn-key-overruns-dialog.png

 VPN Creation dialog doesn't expand for larger pre-shared keys
 -

 Key: CLOUDSTACK-5026
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5026
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Affects Versions: 4.2.0
 Environment: Advanced networking
Reporter: John Kinsella
 Attachments: vpn-key-overruns-dialog.png


 Steps to reproduce :
 1) Set up zone with advanced networking, get hypervisor up, etc.
 2) Under Global Settings, modify remote.access.vpn.psk.length to something 
 like 48. Save, restart mgmt server.
 2) Under Network, select a guest network, View IP addresses, select an IP 
 that does not yet have a VPN assigned to it.
 3) Click the Enable VPN icon, confirm you wish to create a VPN.
 4) Upon success of creating the VPN setup, the ACS UI will display a status 
 popup with the VPN IP and PSK. After about 30 characters, it will overrun the 
 edge of the dialog box (see screenshot)



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Created] (CLOUDSTACK-5018) Creation of VM using template from snapshot of RBD volume fails

[John Kinsella (JIRA)]

John Kinsella created CLOUDSTACK-5018:
-

 Summary: Creation of VM using template from snapshot of RBD volume 
fails
 Key: CLOUDSTACK-5018
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5018
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: KVM
Affects Versions: 4.2.0
 Environment: NFS secondary storage
Ceph primary storage
Reporter: John Kinsella
Assignee: John Kinsella
 Fix For: 4.2.1


Steps to reproduce:
1) Take snapshot of root disk of VM running on RBD primary storage
2) Create template from that snapshot
3) Attempt to create new VM from that template

Agent logs during step 3:
2013-10-31 18:42:58,958 DEBUG [cloud.agent.Agent] (agentRequest-Handler-1:null) 
Request:Seq 1-1365246108:  { Cmd , MgmtId: 23384517833
9448, via: 1, Ver: v1, Flags: 100111, 
[{org.apache.cloudstack.storage.command.CopyCommand:{srcTO:{org.apache.cloudstack.storage.t
o.TemplateObjectTO:{path:template/tmpl/2/220/dab70ab3-0eef-44ac-bb8b-bb6a3e28cde0.raw,uuid:1149ec70-c436-43d5-b78e-b3cde22a7ba
4,id:220,format:RAW,accountId:2,hvm:true,displayText:jk32template,imageDataStore:{com.cloud.agent.api.to.NfsTO:{_u
rl:nfs://10.200.80.10/exports/secondary,_role:Image}},name:3642a6c90-2b43-39c6-8e83-2733f91a6d96,hypervisorType:KVM}},
destTO:{org.apache.cloudstack.storage.to.TemplateObjectTO:{uuid:1149ec70-c436-43d5-b78e-b3cde22a7ba4,id:220,format:RAW,a
ccountId:2,hvm:true,displayText:jk32template,imageDataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:c
09eee9f-8191-398b-aea2-726f05a43943,id:2,poolType:RBD,host:10.10.51.10,path:libvirt-pool,port:6789}},name:3642a6c
90-2b43-39c6-8e83-2733f91a6d96,hypervisorType:KVM}},executeInSequence:true,wait:10800}}]
 }
2013-10-31 18:42:58,958 DEBUG [cloud.agent.Agent] (agentRequest-Handler-1:null) 
Processing command: org.apache.cloudstack.storage.comm
and.CopyCommand
2013-10-31 18:42:58,960 DEBUG [kvm.storage.LibvirtStorageAdaptor] 
(agentRequest-Handler-1:null) createStoragePool didn't find existing
 running pool: org.libvirt.LibvirtException: Storage pool not found: no pool 
with matching uuid, need to create it
2013-10-31 18:42:58,960 DEBUG [kvm.storage.LibvirtStorageAdaptor] 
(agentRequest-Handler-1:null) Didn't find an existing storage pool 1
4c0760e-762b-335d-b3e4-4f6a7b5a140c by UUID, checking for pools with duplicate 
paths
2013-10-31 18:42:58,962 DEBUG [kvm.storage.LibvirtStorageAdaptor] 
(agentRequest-Handler-1:null) Checking path of existing pool dc461b1
f-96e9-4f74-a81e-adc8db3585cb against pool we want to create
2013-10-31 18:42:58,965 DEBUG [kvm.storage.LibvirtStorageAdaptor] 
(agentRequest-Handler-1:null) Checking path of existing pool c09eee9
f-8191-398b-aea2-726f05a43943 against pool we want to create
2013-10-31 18:42:58,967 DEBUG [kvm.storage.LibvirtStorageAdaptor] 
(agentRequest-Handler-1:null) Attempting to create storage pool 14c0
760e-762b-335d-b3e4-4f6a7b5a140c
2013-10-31 18:42:58,967 DEBUG [kvm.storage.LibvirtStorageAdaptor] 
(agentRequest-Handler-1:null) pool type='netfs'
name14c0760e-762b-335d-b3e4-4f6a7b5a140c/name
uuid14c0760e-762b-335d-b3e4-4f6a7b5a140c/uuid
source
host name='10.200.80.10'/
dir path='/exports/secondary/template/tmpl/2/220'/
/source
target
path/mnt/14c0760e-762b-335d-b3e4-4f6a7b5a140c/path
/target
/pool

2013-10-31 18:42:59,205 DEBUG [kvm.storage.LibvirtStorageAdaptor] 
(agentRequest-Handler-1:null) The source image is not RBD, but the destination 
is. We will convert into RBD format 2
2013-10-31 18:42:59,205 DEBUG [kvm.storage.LibvirtStorageAdaptor] 
(agentRequest-Handler-1:null) Converting 
/mnt/14c0760e-762b-335d-b3e4-4f6a7b5a140c/dab70ab3-0eef-44ac-bb8b-bb6a3e28cde0.raw
 to /tmp/ec1c030b-7899-4a76-9f70-aaca8269b875 as a temporary file for RBD 
conversion
2013-10-31 18:42:59,205 DEBUG [utils.script.Script] 
(agentRequest-Handler-1:null) Executing: qemu-img convert -f qcow2 -O raw 
/mnt/14c0760e-762b-335d-b3e4-4f6a7b5a140c/dab70ab3-0eef-44ac-bb8b-bb6a3e28cde0.raw
 /tmp/ec1c030b-7899-4a76-9f70-aaca8269b875
2013-10-31 18:42:59,216 DEBUG [utils.script.Script] 
(agentRequest-Handler-1:null) Exit value is 1
2013-10-31 18:42:59,216 DEBUG [utils.script.Script] 
(agentRequest-Handler-1:null) qemu-img: Could not open 
'/mnt/14c0760e-762b-335d-b3e4-4f6a7b5a140c/dab70ab3-0eef-44ac-bb8b-bb6a3e28cde0.raw':
 Invalid argumentqemu-img: Could not open 
'/mnt/14c0760e-762b-335d-b3e4-4f6a7b5a140c/dab70ab3-0eef-44ac-bb8b-bb6a3e28cde0.raw'
2013-10-31 18:42:59,216 ERROR [kvm.storage.LibvirtStorageAdaptor] 
(agentRequest-Handler-1:null) Failed to do a temp convert from 
/mnt/14c0760e-762b-335d-b3e4-4f6a7b5a140c/dab70ab3-0eef-44ac-bb8b-bb6a3e28cde0.raw
 to /tmp/ec1c030b-7899-4a76-9f70-aaca8269b875 the error was: qemu-img: Could 
not open 

[jira] [Commented] (CLOUDSTACK-5018) Creation of VM using template from snapshot of RBD volume fails

[John Kinsella (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-5018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13811077#comment-13811077
 ] 

John Kinsella commented on CLOUDSTACK-5018:
---

Looks like what's going on is during the copy of the snapshot back into Ceph, 
com.cloud.hypervisor.kvm.storageLibvirtStorageAdaptor.getPhysicalDisk() is 
unable to figure out the snapshot's image format, so it incorrectly sets it to 
qcow2 instead of raw.

 Creation of VM using template from snapshot of RBD volume fails
 ---

 Key: CLOUDSTACK-5018
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5018
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: KVM
Affects Versions: 4.2.0
 Environment: NFS secondary storage
 Ceph primary storage
Reporter: John Kinsella
Assignee: John Kinsella
  Labels: kvm, rbd, snapshot
 Fix For: 4.2.1


 Steps to reproduce:
 1) Take snapshot of root disk of VM running on RBD primary storage
 2) Create template from that snapshot
 3) Attempt to create new VM from that template
 Agent logs during step 3:
 2013-10-31 18:42:58,958 DEBUG [cloud.agent.Agent] 
 (agentRequest-Handler-1:null) Request:Seq 1-1365246108:  { Cmd , MgmtId: 
 23384517833
 9448, via: 1, Ver: v1, Flags: 100111, 
 [{org.apache.cloudstack.storage.command.CopyCommand:{srcTO:{org.apache.cloudstack.storage.t
 o.TemplateObjectTO:{path:template/tmpl/2/220/dab70ab3-0eef-44ac-bb8b-bb6a3e28cde0.raw,uuid:1149ec70-c436-43d5-b78e-b3cde22a7ba
 4,id:220,format:RAW,accountId:2,hvm:true,displayText:jk32template,imageDataStore:{com.cloud.agent.api.to.NfsTO:{_u
 rl:nfs://10.200.80.10/exports/secondary,_role:Image}},name:3642a6c90-2b43-39c6-8e83-2733f91a6d96,hypervisorType:KVM}},
 destTO:{org.apache.cloudstack.storage.to.TemplateObjectTO:{uuid:1149ec70-c436-43d5-b78e-b3cde22a7ba4,id:220,format:RAW,a
 ccountId:2,hvm:true,displayText:jk32template,imageDataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:c
 09eee9f-8191-398b-aea2-726f05a43943,id:2,poolType:RBD,host:10.10.51.10,path:libvirt-pool,port:6789}},name:3642a6c
 90-2b43-39c6-8e83-2733f91a6d96,hypervisorType:KVM}},executeInSequence:true,wait:10800}}]
  }
 2013-10-31 18:42:58,958 DEBUG [cloud.agent.Agent] 
 (agentRequest-Handler-1:null) Processing command: 
 org.apache.cloudstack.storage.comm
 and.CopyCommand
 2013-10-31 18:42:58,960 DEBUG [kvm.storage.LibvirtStorageAdaptor] 
 (agentRequest-Handler-1:null) createStoragePool didn't find existing
  running pool: org.libvirt.LibvirtException: Storage pool not found: no pool 
 with matching uuid, need to create it
 2013-10-31 18:42:58,960 DEBUG [kvm.storage.LibvirtStorageAdaptor] 
 (agentRequest-Handler-1:null) Didn't find an existing storage pool 1
 4c0760e-762b-335d-b3e4-4f6a7b5a140c by UUID, checking for pools with 
 duplicate paths
 2013-10-31 18:42:58,962 DEBUG [kvm.storage.LibvirtStorageAdaptor] 
 (agentRequest-Handler-1:null) Checking path of existing pool dc461b1
 f-96e9-4f74-a81e-adc8db3585cb against pool we want to create
 2013-10-31 18:42:58,965 DEBUG [kvm.storage.LibvirtStorageAdaptor] 
 (agentRequest-Handler-1:null) Checking path of existing pool c09eee9
 f-8191-398b-aea2-726f05a43943 against pool we want to create
 2013-10-31 18:42:58,967 DEBUG [kvm.storage.LibvirtStorageAdaptor] 
 (agentRequest-Handler-1:null) Attempting to create storage pool 14c0
 760e-762b-335d-b3e4-4f6a7b5a140c
 2013-10-31 18:42:58,967 DEBUG [kvm.storage.LibvirtStorageAdaptor] 
 (agentRequest-Handler-1:null) pool type='netfs'
 name14c0760e-762b-335d-b3e4-4f6a7b5a140c/name
 uuid14c0760e-762b-335d-b3e4-4f6a7b5a140c/uuid
 source
 host name='10.200.80.10'/
 dir path='/exports/secondary/template/tmpl/2/220'/
 /source
 target
 path/mnt/14c0760e-762b-335d-b3e4-4f6a7b5a140c/path
 /target
 /pool
 2013-10-31 18:42:59,205 DEBUG [kvm.storage.LibvirtStorageAdaptor] 
 (agentRequest-Handler-1:null) The source image is not RBD, but the 
 destination is. We will convert into RBD format 2
 2013-10-31 18:42:59,205 DEBUG [kvm.storage.LibvirtStorageAdaptor] 
 (agentRequest-Handler-1:null) Converting 
 /mnt/14c0760e-762b-335d-b3e4-4f6a7b5a140c/dab70ab3-0eef-44ac-bb8b-bb6a3e28cde0.raw
  to /tmp/ec1c030b-7899-4a76-9f70-aaca8269b875 as a temporary file for RBD 
 conversion
 2013-10-31 18:42:59,205 DEBUG [utils.script.Script] 
 (agentRequest-Handler-1:null) Executing: qemu-img convert -f qcow2 -O raw 
 /mnt/14c0760e-762b-335d-b3e4-4f6a7b5a140c/dab70ab3-0eef-44ac-bb8b-bb6a3e28cde0.raw
  /tmp/ec1c030b-7899-4a76-9f70-aaca8269b875
 2013-10-31 18:42:59,216 DEBUG [utils.script.Script] 
 (agentRequest-Handler-1:null) Exit value is 1
 2013-10-31 18:42:59,216 DEBUG [utils.script.Script] 
 (agentRequest-Handler-1:null) qemu-img: Could not 

[jira] [Resolved] (CLOUDSTACK-5018) Creation of VM using template from snapshot of RBD volume fails

[John Kinsella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-5018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Kinsella resolved CLOUDSTACK-5018.
---

Resolution: Fixed

Fixed issue in my environment, but needs further testing.


 Creation of VM using template from snapshot of RBD volume fails
 ---

 Key: CLOUDSTACK-5018
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5018
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: KVM
Affects Versions: 4.2.0
 Environment: NFS secondary storage
 Ceph primary storage
Reporter: John Kinsella
Assignee: John Kinsella
  Labels: kvm, rbd, snapshot
 Fix For: 4.2.1


 Steps to reproduce:
 1) Take snapshot of root disk of VM running on RBD primary storage
 2) Create template from that snapshot
 3) Attempt to create new VM from that template
 Agent logs during step 3:
 2013-10-31 18:42:58,958 DEBUG [cloud.agent.Agent] 
 (agentRequest-Handler-1:null) Request:Seq 1-1365246108:  { Cmd , MgmtId: 
 23384517833
 9448, via: 1, Ver: v1, Flags: 100111, 
 [{org.apache.cloudstack.storage.command.CopyCommand:{srcTO:{org.apache.cloudstack.storage.t
 o.TemplateObjectTO:{path:template/tmpl/2/220/dab70ab3-0eef-44ac-bb8b-bb6a3e28cde0.raw,uuid:1149ec70-c436-43d5-b78e-b3cde22a7ba
 4,id:220,format:RAW,accountId:2,hvm:true,displayText:jk32template,imageDataStore:{com.cloud.agent.api.to.NfsTO:{_u
 rl:nfs://10.200.80.10/exports/secondary,_role:Image}},name:3642a6c90-2b43-39c6-8e83-2733f91a6d96,hypervisorType:KVM}},
 destTO:{org.apache.cloudstack.storage.to.TemplateObjectTO:{uuid:1149ec70-c436-43d5-b78e-b3cde22a7ba4,id:220,format:RAW,a
 ccountId:2,hvm:true,displayText:jk32template,imageDataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:c
 09eee9f-8191-398b-aea2-726f05a43943,id:2,poolType:RBD,host:10.10.51.10,path:libvirt-pool,port:6789}},name:3642a6c
 90-2b43-39c6-8e83-2733f91a6d96,hypervisorType:KVM}},executeInSequence:true,wait:10800}}]
  }
 2013-10-31 18:42:58,958 DEBUG [cloud.agent.Agent] 
 (agentRequest-Handler-1:null) Processing command: 
 org.apache.cloudstack.storage.comm
 and.CopyCommand
 2013-10-31 18:42:58,960 DEBUG [kvm.storage.LibvirtStorageAdaptor] 
 (agentRequest-Handler-1:null) createStoragePool didn't find existing
  running pool: org.libvirt.LibvirtException: Storage pool not found: no pool 
 with matching uuid, need to create it
 2013-10-31 18:42:58,960 DEBUG [kvm.storage.LibvirtStorageAdaptor] 
 (agentRequest-Handler-1:null) Didn't find an existing storage pool 1
 4c0760e-762b-335d-b3e4-4f6a7b5a140c by UUID, checking for pools with 
 duplicate paths
 2013-10-31 18:42:58,962 DEBUG [kvm.storage.LibvirtStorageAdaptor] 
 (agentRequest-Handler-1:null) Checking path of existing pool dc461b1
 f-96e9-4f74-a81e-adc8db3585cb against pool we want to create
 2013-10-31 18:42:58,965 DEBUG [kvm.storage.LibvirtStorageAdaptor] 
 (agentRequest-Handler-1:null) Checking path of existing pool c09eee9
 f-8191-398b-aea2-726f05a43943 against pool we want to create
 2013-10-31 18:42:58,967 DEBUG [kvm.storage.LibvirtStorageAdaptor] 
 (agentRequest-Handler-1:null) Attempting to create storage pool 14c0
 760e-762b-335d-b3e4-4f6a7b5a140c
 2013-10-31 18:42:58,967 DEBUG [kvm.storage.LibvirtStorageAdaptor] 
 (agentRequest-Handler-1:null) pool type='netfs'
 name14c0760e-762b-335d-b3e4-4f6a7b5a140c/name
 uuid14c0760e-762b-335d-b3e4-4f6a7b5a140c/uuid
 source
 host name='10.200.80.10'/
 dir path='/exports/secondary/template/tmpl/2/220'/
 /source
 target
 path/mnt/14c0760e-762b-335d-b3e4-4f6a7b5a140c/path
 /target
 /pool
 2013-10-31 18:42:59,205 DEBUG [kvm.storage.LibvirtStorageAdaptor] 
 (agentRequest-Handler-1:null) The source image is not RBD, but the 
 destination is. We will convert into RBD format 2
 2013-10-31 18:42:59,205 DEBUG [kvm.storage.LibvirtStorageAdaptor] 
 (agentRequest-Handler-1:null) Converting 
 /mnt/14c0760e-762b-335d-b3e4-4f6a7b5a140c/dab70ab3-0eef-44ac-bb8b-bb6a3e28cde0.raw
  to /tmp/ec1c030b-7899-4a76-9f70-aaca8269b875 as a temporary file for RBD 
 conversion
 2013-10-31 18:42:59,205 DEBUG [utils.script.Script] 
 (agentRequest-Handler-1:null) Executing: qemu-img convert -f qcow2 -O raw 
 /mnt/14c0760e-762b-335d-b3e4-4f6a7b5a140c/dab70ab3-0eef-44ac-bb8b-bb6a3e28cde0.raw
  /tmp/ec1c030b-7899-4a76-9f70-aaca8269b875
 2013-10-31 18:42:59,216 DEBUG [utils.script.Script] 
 (agentRequest-Handler-1:null) Exit value is 1
 2013-10-31 18:42:59,216 DEBUG [utils.script.Script] 
 (agentRequest-Handler-1:null) qemu-img: Could not open 
 '/mnt/14c0760e-762b-335d-b3e4-4f6a7b5a140c/dab70ab3-0eef-44ac-bb8b-bb6a3e28cde0.raw':
  Invalid argumentqemu-img: Could not open 
 '/mnt/14c0760e-762b-335d-b3e4-4f6a7b5a140c/dab70ab3-0eef-44ac-bb8b-bb6a3e28cde0.raw'
 

[jira] [Resolved] (CLOUDSTACK-79) CloudStack 3.0.4: firewall rules not restored on KVM host

[John Kinsella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Kinsella resolved CLOUDSTACK-79.
-

Resolution: Fixed

I think this can be called resolved - if there's further issues, re-open and 
we'll look further.

 CloudStack 3.0.4: firewall rules not restored on KVM host
 -

 Key: CLOUDSTACK-79
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-79
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: KVM, Network Controller
Affects Versions: pre-4.0.0
Reporter: Vladimir Ostrovsky
Assignee: John Kinsella
 Fix For: 4.3.0


 I have CloudStack 3.0.4 with a Basic Zone defined. The Zone includes several 
 KVM hosts and uses Security Groups (in other words, IPtables on the hosts) to 
 isolate traffic between VMs.
 The problem: if, for some reason, IPtables on the host are flushed or the 
 iptables service is restarted, the cloud-agent doesn't pull the correct rules 
 from the management server and doesn't synchronize the host with Security 
 Groups definitions in CloudStack. Restart of the cloud-agent service doesn't 
 help as well.
 Shouldn't the agent do it?



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (CLOUDSTACK-1633) Why do ACS security groups only support TCP, UDP, ICMP?

[John Kinsella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-1633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Kinsella updated CLOUDSTACK-1633:
--

Fix Version/s: 4.3.0

 Why do ACS security groups only support TCP, UDP, ICMP?
 ---

 Key: CLOUDSTACK-1633
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1633
 Project: CloudStack
  Issue Type: Improvement
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Affects Versions: 4.0.0
Reporter: John Kinsella
Assignee: John Kinsella
 Fix For: 4.3.0


 If I attempt to make an API call to authorizeSecurityGroupIngress specifying 
 a protocol of 41, I get an error of Invalid protocol 41.
 Real-world use for this - Windows AD servers attempt to establish an 
 ISATAP[1] connection between servers. Without opening the firewall, packets 
 will be dropped as shown in the log below:
 Mar 11 19:07:27 c10 kernel: DROP:i-2-1711-VM-eg:IN=cloudbr0 OUT=cloudbr0 
 PHYSIN=vnet2 PHYSOUT=bond1 MAC=00:04:e9:ff:f3:90:06:c5:36:00:00:1a:0f:00 
 SRC=192.168.1.10 DST=192.168.1.20 LEN=68 TOS=0x00 PREC=0x00 TTL=128 ID=2898 
 PROTO=41
 1:http://en.wikipedia.org/wiki/ISATAP



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Created] (CLOUDSTACK-4884) LibvirtComputingResource incorrectly parses p1p1 style interfaces

[John Kinsella (JIRA)]

John Kinsella created CLOUDSTACK-4884:
-

 Summary: LibvirtComputingResource incorrectly parses p1p1 style 
interfaces
 Key: CLOUDSTACK-4884
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4884
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
 Environment: Dell PowerEdge C6220 with Broadcomm 10Gbit Ethernet
Reporter: John Kinsella


In CLOUDSTACK-3959, code was added to support Ethernet interfaces with a naming 
convention like p1p1. The regexes added, though, do not take vlan-tagged 
interfaces into account. This results in ACS generating errors such as the 
following when attempting to add a host:



2013-10-16 17:23:57,882 WARN  [apache.cloudstack.alerts] 
(AgentConnectTaskPool-96:null)  alertType:: 7 // dataCenterId:: 3 // podId:: 3 
// clusterId:: null // message:: Incorrect Network setup on agent, Reinitialize 
agent after network names are setup, details : Can not find network: cloudbr0




--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Assigned] (CLOUDSTACK-4884) LibvirtComputingResource incorrectly parses p1p1 style interfaces

[John Kinsella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-4884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Kinsella reassigned CLOUDSTACK-4884:
-

Assignee: John Kinsella

 LibvirtComputingResource incorrectly parses p1p1 style interfaces
 -

 Key: CLOUDSTACK-4884
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4884
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
 Environment: Dell PowerEdge C6220 with Broadcomm 10Gbit Ethernet
Reporter: John Kinsella
Assignee: John Kinsella
   Original Estimate: 0.5h
  Remaining Estimate: 0.5h

 In CLOUDSTACK-3959, code was added to support Ethernet interfaces with a 
 naming convention like p1p1. The regexes added, though, do not take 
 vlan-tagged interfaces into account. This results in ACS generating errors 
 such as the following when attempting to add a host:
   
 2013-10-16 17:23:57,882 WARN  [apache.cloudstack.alerts] 
 (AgentConnectTaskPool-96:null)  alertType:: 7 // dataCenterId:: 3 // podId:: 
 3 // clusterId:: null // message:: Incorrect Network setup on agent, 
 Reinitialize agent after network names are setup, details : Can not find 
 network: cloudbr0



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Created] (CLOUDSTACK-4886) cloud-setup-databases not escaping password in shell commands

[John Kinsella (JIRA)]

John Kinsella created CLOUDSTACK-4886:
-

 Summary: cloud-setup-databases not escaping password in shell 
commands
 Key: CLOUDSTACK-4886
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4886
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Affects Versions: 4.2.0
Reporter: John Kinsella
 Fix For: 4.2.1


When initializing a new ACS database, the database key is not being properly 
escaped when passed back to shell commands. I haven't tested the other keys 
passed into this command, yet.

(Passwords below are not real, but the  character and resulting error is what 
was encountered)

root@acsmgmt01 ACS# cloudstack-setup-databases 
cloud:jpiasfadf324234jcW@localhost --deploy-as=root:lkjeroiuwer -e file -m 
'asdflkjasdflkjwer' -k 'sfsdCugasdfsdf' -i 10.100.10.10
Mysql user name:cloud [ OK ]
Mysql user password:jpiasfadf324234jcW [ OK ]
Mysql server ip:localhost [ OK ]
Mysql server port:3306 [ OK ]
Mysql root user name:root [ OK ]
Mysql root user password:lkjeroiuwer [ OK ]
Using specified cluster management server node IP 10.100.10.10 [ OK ]
Checking Cloud database files ... [ OK ]
Checking local machine hostname ... [ OK ]
Checking SELinux setup ... WARNING: We detected that your SELinux is not 
configured in permissive. to make sure cloudstack won't block by SELinux after 
system reboot, we strongly suggest you setting it in permissive in 
/etc/selinux/config, then reboot the machine.
[ OK ]
Preparing /etc/cloudstack/management/db.properties [ OK ]
Applying /usr/share/cloudstack-management/setup/create-database.sql [ OK ]
Applying /usr/share/cloudstack-management/setup/create-schema.sql [ OK ]
Applying /usr/share/cloudstack-management/setup/create-database-premium.sql [ 
OK ]
Applying /usr/share/cloudstack-management/setup/create-schema-premium.sql [ OK ]
Applying /usr/share/cloudstack-management/setup/server-setup.sql [ OK ]
Applying /usr/share/cloudstack-management/setup/templates.sql [ OK ]
Applying /usr/share/cloudstack-bridge/setup/cloudbridge_db.sql [ OK ]
Applying /usr/share/cloudstack-bridge/setup/cloudbridge_schema.sql [ OK ]
Applying /usr/share/cloudstack-bridge/setup/cloudbridge_multipart.sql [ OK ]
Applying /usr/share/cloudstack-bridge/setup/cloudbridge_index.sql [ OK ]
Applying /usr/share/cloudstack-bridge/setup/cloudbridge_multipart_alter.sql [ 
OK ]
Applying /usr/share/cloudstack-bridge/setup/cloudbridge_bucketpolicy.sql [ OK ]
Applying /usr/share/cloudstack-bridge/setup/cloudbridge_policy_alter.sql [ OK ]
Applying /usr/share/cloudstack-bridge/setup/cloudbridge_offering.sql [ OK ]
Applying /usr/share/cloudstack-bridge/setup/cloudbridge_offering_alter.sql [ OK 
]
Processing encryption ... Traceback (most recent call last):
File /usr/bin/cloudstack-setup-databases, line 607, in module
o.run()
File /usr/bin/cloudstack-setup-databases, line 596, in run
self.processEncryptionStuff()
File /usr/bin/cloudstack-setup-databases, line 433, in processEncryptionStuff
encryptDBSecretKey()
File /usr/bin/cloudstack-setup-databases, line 417, in encryptDBSecretKey
self.putDbProperty('db.cloud.encrypt.secret', 
formatEncryptResult(encrypt(self.dbsecretkey)))
File /usr/bin/cloudstack-setup-databases, line 407, in encrypt
return runCmd(cmd).strip('\n')
File /usr/bin/cloudstack-setup-databases, line 51, in runCmd
raise Exception(stderr)
Exception: /bin/sh: Cugasdfsdf: No such file or directory

Looks like this is caused by no escaping at line 406 in 
cloudstack-setup-databases.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (CLOUDSTACK-4886) cloud-setup-databases not escaping password in shell commands

[John Kinsella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-4886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Kinsella updated CLOUDSTACK-4886:
--

Security: Public  (was: Non-Public)

 cloud-setup-databases not escaping password in shell commands
 -

 Key: CLOUDSTACK-4886
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4886
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Affects Versions: 4.2.0
Reporter: John Kinsella
 Fix For: 4.2.1


 When initializing a new ACS database, the database key is not being properly 
 escaped when passed back to shell commands. I haven't tested the other keys 
 passed into this command, yet.
 (Passwords below are not real, but the  character and resulting error is 
 what was encountered)
 root@acsmgmt01 ACS# cloudstack-setup-databases 
 cloud:jpiasfadf324234jcW@localhost --deploy-as=root:lkjeroiuwer -e file -m 
 'asdflkjasdflkjwer' -k 'sfsdCugasdfsdf' -i 10.100.10.10
 Mysql user name:cloud [ OK ]
 Mysql user password:jpiasfadf324234jcW [ OK ]
 Mysql server ip:localhost [ OK ]
 Mysql server port:3306 [ OK ]
 Mysql root user name:root [ OK ]
 Mysql root user password:lkjeroiuwer [ OK ]
 Using specified cluster management server node IP 10.100.10.10 [ OK ]
 Checking Cloud database files ... [ OK ]
 Checking local machine hostname ... [ OK ]
 Checking SELinux setup ... WARNING: We detected that your SELinux is not 
 configured in permissive. to make sure cloudstack won't block by SELinux 
 after system reboot, we strongly suggest you setting it in permissive in 
 /etc/selinux/config, then reboot the machine.
 [ OK ]
 Preparing /etc/cloudstack/management/db.properties [ OK ]
 Applying /usr/share/cloudstack-management/setup/create-database.sql [ OK ]
 Applying /usr/share/cloudstack-management/setup/create-schema.sql [ OK ]
 Applying /usr/share/cloudstack-management/setup/create-database-premium.sql [ 
 OK ]
 Applying /usr/share/cloudstack-management/setup/create-schema-premium.sql [ 
 OK ]
 Applying /usr/share/cloudstack-management/setup/server-setup.sql [ OK ]
 Applying /usr/share/cloudstack-management/setup/templates.sql [ OK ]
 Applying /usr/share/cloudstack-bridge/setup/cloudbridge_db.sql [ OK ]
 Applying /usr/share/cloudstack-bridge/setup/cloudbridge_schema.sql [ OK ]
 Applying /usr/share/cloudstack-bridge/setup/cloudbridge_multipart.sql [ OK ]
 Applying /usr/share/cloudstack-bridge/setup/cloudbridge_index.sql [ OK ]
 Applying /usr/share/cloudstack-bridge/setup/cloudbridge_multipart_alter.sql [ 
 OK ]
 Applying /usr/share/cloudstack-bridge/setup/cloudbridge_bucketpolicy.sql [ OK 
 ]
 Applying /usr/share/cloudstack-bridge/setup/cloudbridge_policy_alter.sql [ OK 
 ]
 Applying /usr/share/cloudstack-bridge/setup/cloudbridge_offering.sql [ OK ]
 Applying /usr/share/cloudstack-bridge/setup/cloudbridge_offering_alter.sql [ 
 OK ]
 Processing encryption ... Traceback (most recent call last):
 File /usr/bin/cloudstack-setup-databases, line 607, in module
 o.run()
 File /usr/bin/cloudstack-setup-databases, line 596, in run
 self.processEncryptionStuff()
 File /usr/bin/cloudstack-setup-databases, line 433, in 
 processEncryptionStuff
 encryptDBSecretKey()
 File /usr/bin/cloudstack-setup-databases, line 417, in encryptDBSecretKey
 self.putDbProperty('db.cloud.encrypt.secret', 
 formatEncryptResult(encrypt(self.dbsecretkey)))
 File /usr/bin/cloudstack-setup-databases, line 407, in encrypt
 return runCmd(cmd).strip('\n')
 File /usr/bin/cloudstack-setup-databases, line 51, in runCmd
 raise Exception(stderr)
 Exception: /bin/sh: Cugasdfsdf: No such file or directory
 Looks like this is caused by no escaping at line 406 in 
 cloudstack-setup-databases.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (CLOUDSTACK-2534) Packaging puts SSH private keys as public readable on management server

[John Kinsella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-2534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Kinsella updated CLOUDSTACK-2534:
--

Fix Version/s: Future

Talked to Animesh, we're pushing this to after 4.2

 Packaging puts SSH private keys as public readable on management server
 ---

 Key: CLOUDSTACK-2534
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2534
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Packaging
Reporter: Girish Shilamkar
Assignee: Rayees Namathponnan
Priority: Critical
  Labels: security
 Fix For: Future


 SSH public key is group readable which is security threat.
  ls -la /usr/share/cloudstack-common/scripts/vm/systemvm/id_rsa.cloud
 -rw-r--r--. 1 root root 1670 May 15 22:54 
 /usr/share/cloudstack-common/scripts/vm/systemvm/id_rsa.cloud

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CLOUDSTACK-3131) Unblock IGMP packets by security group rules

[John Kinsella (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-3131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13691551#comment-13691551
 ] 

John Kinsella commented on CLOUDSTACK-3131:
---

I'm going to mark this as a duplicate of CLOUDSTACK-1633 and add IGMP in with 
that issue.

Been too busy lately - got the code written, will test and commit within the 
next few days.


 Unblock IGMP packets by security group rules
 

 Key: CLOUDSTACK-3131
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3131
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Controller
Affects Versions: 4.0.0, 4.0.1, 4.0.2, 4.1.0, 4.1.1, 4.2.0
Reporter: Prasanna Santhanam
 Fix For: Future


 From: Kenneth Warren kwar...@orbistechnologies.com
 To: us...@cloudstack.apache.org us...@cloudstack.apache.org
 Subject: Security Groups and IGMP
 Good Afternoon!
 We are working with multicast and IGMP groups on our CloudStack 
 infrastructure, and I have a question regarding security groups.
 To create an ingress rule, one must navigate to the security groups panel 
 then add a new rule based on protocol. The values allowed are ICMP, TCP, and 
 UDP. I am concerned that the IGMP member query messages on the network are 
 being
 +blocked by the security group settings, as our VMs continually act as if 
 they have been kicked out of the membership group.
 Are IGMP packets blocked by security groups by default? If so, how do we 
 enable them?
 Thanks!
 Full thread @ http://cloudstack.markmail.org/thread/ur4hzotraq3azmtz

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CLOUDSTACK-1633) Why do ACS security groups only support TCP, UDP, ICMP?

[John Kinsella (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-1633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13691553#comment-13691553
 ] 

John Kinsella commented on CLOUDSTACK-1633:
---

CLOUDSTACK-3131 showed a request from a user to have IGMP support as 
well...will add that feature as part of this issue.

 Why do ACS security groups only support TCP, UDP, ICMP?
 ---

 Key: CLOUDSTACK-1633
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1633
 Project: CloudStack
  Issue Type: Improvement
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Affects Versions: 4.0.0
Reporter: John Kinsella
Assignee: John Kinsella

 If I attempt to make an API call to authorizeSecurityGroupIngress specifying 
 a protocol of 41, I get an error of Invalid protocol 41.
 Real-world use for this - Windows AD servers attempt to establish an 
 ISATAP[1] connection between servers. Without opening the firewall, packets 
 will be dropped as shown in the log below:
 Mar 11 19:07:27 c10 kernel: DROP:i-2-1711-VM-eg:IN=cloudbr0 OUT=cloudbr0 
 PHYSIN=vnet2 PHYSOUT=bond1 MAC=00:04:e9:ff:f3:90:06:c5:36:00:00:1a:0f:00 
 SRC=192.168.1.10 DST=192.168.1.20 LEN=68 TOS=0x00 PREC=0x00 TTL=128 ID=2898 
 PROTO=41
 1:http://en.wikipedia.org/wiki/ISATAP

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (CLOUDSTACK-3131) Unblock IGMP packets by security group rules

[John Kinsella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-3131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Kinsella resolved CLOUDSTACK-3131.
---

Resolution: Duplicate

Duplicate of CLOUDSTACK-1633

 Unblock IGMP packets by security group rules
 

 Key: CLOUDSTACK-3131
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3131
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Controller
Affects Versions: 4.0.0, 4.0.1, 4.0.2, 4.1.0, 4.1.1, 4.2.0
Reporter: Prasanna Santhanam
 Fix For: Future


 From: Kenneth Warren kwar...@orbistechnologies.com
 To: us...@cloudstack.apache.org us...@cloudstack.apache.org
 Subject: Security Groups and IGMP
 Good Afternoon!
 We are working with multicast and IGMP groups on our CloudStack 
 infrastructure, and I have a question regarding security groups.
 To create an ingress rule, one must navigate to the security groups panel 
 then add a new rule based on protocol. The values allowed are ICMP, TCP, and 
 UDP. I am concerned that the IGMP member query messages on the network are 
 being
 +blocked by the security group settings, as our VMs continually act as if 
 they have been kicked out of the membership group.
 Are IGMP packets blocked by security groups by default? If so, how do we 
 enable them?
 Thanks!
 Full thread @ http://cloudstack.markmail.org/thread/ur4hzotraq3azmtz

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (CLOUDSTACK-2679) Install docs could point to more accurate XenServer download page

[John Kinsella (JIRA)]

John Kinsella created CLOUDSTACK-2679:
-

 Summary: Install docs could point to more accurate XenServer 
download page
 Key: CLOUDSTACK-2679
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2679
 Project: CloudStack
  Issue Type: Improvement
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Doc
Affects Versions: 4.0.2
Reporter: John Kinsella
 Fix For: 4.2.0


Somebody on twitter raised to my attention that the installation docs (eg 
Section 8.2.2 on 
http://cloudstack.apache.org/docs/en-US/Apache_CloudStack/4.0.2/html/Installation_Guide/citrix-xenserver-installation.html#system-requirements-xenserver-hosts
 ) point to a Citrix page that allows downloading of XenServer 6.1.  Apparently 
to download 6.0.2 (The version ACS officially supports) requires creating an 
account and looking in download archives. Would be good if we could make this a 
little more clear in the docs.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CLOUDSTACK-1734) Make SHA256Salt default password encoding mechanism

[John Kinsella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-1734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Kinsella updated CLOUDSTACK-1734:
--

Summary: Make SHA256Salt default password encoding mechanism  (was: Make 
SHA1 default password encoding mechanism)

 Make SHA256Salt default password encoding mechanism
 ---

 Key: CLOUDSTACK-1734
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1734
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.1.0
 Environment: Cloudstack generic
Reporter: Venkata Siva Vijayendra Bhamidipati
Assignee: Venkata Siva Vijayendra Bhamidipati
 Fix For: 4.2.0


 Currently MD5 is the default password encoding mechanism during user creation 
 and updation. Make SHA1 the default, using the recently added 
 SHA256SALTUserAuthenticator.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira