AW: SSL Encryption for SSVM & Console

[Ismaili, Liridon (SWISS TXT)]

Hi Granwille

I once had this issue and could solve it by deleting the SSL records on the 
keystore DB:
delete from keystore where domain_suffix="console.yourdomain.com"

After that you have to re-upload your certificate.

Good luck & Regards!
Liridon



Von: Granwille Strauss
Gesendet: Montag, 19. September 2022 22:54
Bis: users@cloudstack.apache.org
Betreff: SSL Encryption for SSVM & Console


Hi Guys

I am using 4.17 CM and I am trying to secure SSVM & Console. I have a wildcard 
certificate, that should cover CM, SSVM & Console without any issues. In CM UI, 
I have uploaded my CRT, PKCS8 Key and for the domain suffix I have *.domain.com 
in place.

In global config, I have set the following:

- consoleproxy.url.domain: console.domain.com & I have tested *.domain.com
- consoleproxy.sslEnabled: true
- secstorage.ssl.cert.domain: ssvm.domain.com & I have tested *.domain.com
- secstorage.encrypt.copy: true

Regardless of the domain settings, my console agent fails to connect. SSVM 
works perfectly fine whether I use ssvm.domain.com or *.domain.com in global 
setting. I have destroyed console vm hoping for it to load certificate with no 
luck.

Are there any suggestion on how I can fix this, please?

--
Regards / Groete

[https://www.adsigner.com/v1/s/631091998d4670001fe43ec2/621c9b76c140bb001ed0f818/logo/621b3fa39fb210001f975298/cd2904ba-304d-4a49-bf33-cbe9ac76d929_248x-.png]
 Granwille Strauss  //  Senior Systems Admin

e: granwi...@namhost.com
m: +264 81 323 1260
w: www.namhost.com

[https://www.adsigner.com/v1/s/631091998d4670001fe43ec2/621c9b76c140bb001ed0f818/social_icon_01/621b3fa39fb210001f975298/9151954b-b298-41aa-89c8-1d68af075373_48x48.png]
 
[https://www.adsigner.com/v1/s/631091998d4670001fe43ec2/621c9b76c140bb001ed0f818/social_icon_02/621b3fa39fb210001f975298/85a9dc7c-7bd1-4958-85a9-e6a25baeb028_48x48.png]
   
[https://www.adsigner.com/v1/s/631091998d4670001fe43ec2/621c9b76c140bb001ed0f818/social_icon_03/621b3fa39fb210001f975298/c1c5386c-914c-43cf-9d37-5b4aa8e317ab_48x48.png]
   
[https://www.adsigner.com/v1/s/631091998d4670001fe43ec2/621c9b76c140bb001ed0f818/social_icon_04/621b3fa39fb210001f975298/3aaa7968-130e-48ec-821d-559a332cce47_48x48.png]
   
[https://www.adsigner.com/v1/s/631091998d4670001fe43ec2/621c9b76c140bb001ed0f818/social_icon_05/621b3fa39fb210001f975298/3a8c09e6-588f-43a8-acfd-be4423fd3fb6_48x48.png]
 

[https://www.adsigner.com/v1/i/631091998d4670001fe43ec2/621c9b76c140bb001ed0f818/banner/940x300]

Namhost Internet Services (Pty) Ltd,

24 Black Eagle Rd, Hermanus, 7210, RSA


The content of this message is confidential. If you have received it by 
mistake, please inform us by email reply and then delete the message. It is 
forbidden to copy, forward, or in any way reveal the contents of this message 
to anyone without our explicit consent. The integrity and security of this 
email cannot be guaranteed over the Internet. Therefore, the sender will not be 
held liable for any damage caused by the message. For our full privacy policy 
and disclaimers, please go to https://www.namhost.com/privacy-policy

[Powered by 
AdSigner]

AW: [VOTE] Apache CloudStack 4.14.0.0 RC3

[Ismaili, Liridon (SWISS TXT)]

Hi All
Here is my vote: +1

Environment configuration:

  *   Apache CloudStack: MGMT + DB > CentOS 7
  *   Hosts: VMware ESXi
  *   Primary Storage: VMware VMFS, NFS
  *   Secondary Storage: NFS
  *   Zone Network: Advanced Network

Tests:

  *
Upgrade 4.13.1 to 4.14 (RC1/2/3)
  *
Update VRs
  *
Create new Networks (isolated; shared)
  *
VM lifecycle (starting, stopping, destroy, expunge)
  *   live migration
  *   snapshots
  *   Backups
  *   Created projects
  *   Created VPCs
  *   Check usage data
  *   Check DNS entries (after stopping / expunging)
  *   Check NIC cleanup after expunging VM
  *   Register new Template

Findings:

Since we are using CEST timezone over here we saw that the GUI shows now UTC 
times under Events. Over API I get CEST so I think it's a display issue here. 
DB entries are all in UTC.

Regards
Liridon

Von: Andrija Panic 
Gesendet: Montag, 11. Mai 2020 17:11
An: dev ; users 
Betreff: [VOTE] Apache CloudStack 4.14.0.0 RC3

Hi All,

I've created a 4.14.0.0 release (RC3), with the following artefacts up for
testing and a vote:

Git Branch and Commit SH:
https://gitbox.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.14.0.0-RC20200511T1503
Commit: 6f96b3b2b391a9b7d085f76bcafa3989d9832b4e

Source release (checksums and signatures are available at the same
location):
https://dist.apache.org/repos/dist/dev/cloudstack/4.14.0.0/

PGP release keys (signed using 3DC01AE8):
https://dist.apache.org/repos/dist/release/cloudstack/KEYS

The vote will be open until 14th May 2020, 17.00 CET (72h).

For sanity in tallying the vote, can PMC members please be sure to indicate
"(binding)" with their vote?

[ ] +1 approve
[ ] +0 no opinion
[ ] -1 disapprove (and reason why)

Additional information:

For users' convenience, I've built packages from
6f96b3b2b391a9b7d085f76bcafa3989d9832b4e and published RC3 repository here:
http://packages.shapeblue.com/testing/41400rc3/  (CentOS 7 and
Debian/generic, both with noredist support)
and here
https://download.cloudstack.org/testing/4.14.0.0-RC20200506T2028/ubuntu/bionic/
 (Ubuntu 18.04 specific, no noredist support - thanks to Gabriel):

The release notes are still work-in-progress, but for the upgrade
instructions (including the new systemVM templates) you may refer to the
following URL:
https://acs-www.shapeblue.com/docs/WIP-PROOFING/pr112/upgrading/index.html

4.14.0.0 systemVM templates are available from here:
http://download.cloudstack.org/systemvm/4.14/

NOTES on issues fixed in this RC3 release:

(this one does *NOT* require a full retest if you were testing RC1/RC2
already - just if you were affected this issue):
- https://github.com/apache/cloudstack/pull/4064 - affects hostnames when
attaching a VM to additional networks

Regards,


Andrija Panić

Re: [VOTE] Apache CloudStack 4.14.0.0 RC1

[Ismaili, Liridon (SWISS TXT)]

Hi Andrija & Daan

@Daan I tried that out but without success. However the service seems to be 
recovered and did run successful. The dates inside the DB are in UTC format but 
when I list entries from the usage or cloud DB with CloudMonkey I get CEST 
results.
(the GUI did still show me UTC values in the Events but that's may caused by my 
environment).

@Andrija: I would say that it looks good. I also testet the parameters with 
"Europe/Zurich" but made no difference to me.

Regards
Liridon

-Original Message-
From: Andrija Panic 
mailto:andrija%20panic%20%3candrija.pa...@gmail.com%3e>>
Reply-To: d...@cloudstack.apache.org<mailto:d...@cloudstack.apache.org>
To: users@cloudstack.apache.org 
mailto:%22us...@cloudstack.apache.org%22%20%3cus...@cloudstack.apache.org%3e>>,
 dev mailto:dev%20%3c...@cloudstack.apache.org%3e>>
Subject: Re: [VOTE] Apache CloudStack 4.14.0.0 RC1
Date: Tue, 05 May 2020 19:11:14 +0200


Hi Liridon,


do you have any feedback about the usage records timing/time zone and such?


Thanks

Andrija


On Mon, 4 May 2020 at 14:32, Daan Hoogland <

<mailto:daan.hoogl...@gmail.com>

daan.hoogl...@gmail.com

> wrote:


Liridon,

"Not owner of usage job, skipping" means there is a PID in the record for

this job that isn't the current process. If recognise this and have

remedied by setting the process id to null in the record. I'm sure there is

some underlying issue that you hit though. Just a workaround.


On Mon, May 4, 2020 at 12:56 PM Ismaili, Liridon (SWISS TXT) <

<mailto:liridon.isma...@swisstxt.ch>

liridon.isma...@swisstxt.ch

> wrote:


Hi Rohit


I tried so and did configure the usage to run 12:45 so I can monitor the

behavior. I got the following output:

2020-05-04 12:45:00,002 INFO  [cloud.usage.UsageManagerImpl]

(Usage-Job-1:null) (logid:) starting usage job...

2020-05-04 12:45:00,015 DEBUG [cloud.usage.UsageManagerImpl]

(Usage-Job-1:null) (logid:) Not owner of usage job, skipping...

2020-05-04 12:45:00,015 INFO  [cloud.usage.UsageManagerImpl]

(Usage-Job-1:null) (logid:) usage job complete


So the job did not run for some reason... I'm still looking into this. So

currently I can't confirm but will update you later as soon as the usage

job did run.


Regards

Liridon

-Original Message-

From: Rohit Yadav <

<mailto:rohit.ya...@shapeblue.com>

rohit.ya...@shapeblue.com

mailto:rohit%20yadav%20%3crohit.ya...@shapeblue.com>

rohit%20yadav%20%3crohit.ya...@shapeblue.com

%3e>>

Reply-To:

<mailto:users@cloudstack.apache.org>

users@cloudstack.apache.org

mailto:users@cloudstack.apache.org>

users@cloudstack.apache.org

>

To:

<mailto:d...@cloudstack.apache.org>

d...@cloudstack.apache.org

 <

<mailto:d...@cloudstack.apache.org>

d...@cloudstack.apache.org

mailto:22...@cloudstack.apache.org>

22...@cloudstack.apache.org

<mailto:%22%20%3c...@cloudstack.apache.org>

%22%20%3c...@cloudstack.apache.org

%3e>>,

<mailto:andrija.pa...@gmail.com>

andrija.pa...@gmail.com

 <

<mailto:andrija.pa...@gmail.com>

andrija.pa...@gmail.com

mailto:22andrija.pa...@gmail.com>

22andrija.pa...@gmail.com

<mailto:%22%20%3candrija.pa...@gmail.com>

%22%20%3candrija.pa...@gmail.com

%3e>>,

<mailto:users@cloudstack.apache.org>

users@cloudstack.apache.org

 <

<mailto:users@cloudstack.apache.org>

users@cloudstack.apache.org

mailto:22us...@cloudstack.apache.org>

22us...@cloudstack.apache.org

<mailto:%22%20%3cus...@cloudstack.apache.org>

%22%20%3cus...@cloudstack.apache.org

%3e>>

Subject: Re: [VOTE] Apache CloudStack 4.14.0.0 RC1

Date: Mon, 04 May 2020 10:16:51 +



Thanks for testing and sharing your results Liridon!



Can you also test the case if the usage records have the correct time

according to configured timezone (in global settings) if you're using a

non-UTC timezone?



I'll add the db.usage.url.paramsl as well in the PR.




Regards,



Rohit Yadav



Software Architect, ShapeBlue



<

<https://www.shapeblue.com>

https://www.shapeblue.com

>


<https://www.shapeblue.com>

https://www.shapeblue.com








From: Ismaili, Liridon (SWISS TXT) <


mailto:liridon.isma...@swisstxt.ch>

liridon.isma...@swisstxt.ch

>


<mailto:liridon.isma...@swisstxt.ch>

liridon.isma...@swisstxt.ch





Sent: Monday, May 4, 2020 15:38


To:


mailto:d...@cloudstack.apache.org>

d...@cloudstack.apache.org

>


<mailto:d...@cloudstack.apache.org>

d...@cloudstack.apache.org



 <


mailto:d...@cloudstack.apache.org>

d...@cloudstack.apache.org

>


<mailto:d...@cloudstack.apache.org>

d...@cloudstack.apache.org



;


mailto:andrija.pa...@gmail.com>

andrija.pa...@gmail.com

>


<mailto:andrija.pa...@gmail.com>

andrija.pa...@gm

Re: [VOTE] Apache CloudStack 4.14.0.0 RC1

[Ismaili, Liridon (SWISS TXT)]

Hi Rohit

I tried so and did configure the usage to run 12:45 so I can monitor the 
behavior. I got the following output:
2020-05-04 12:45:00,002 INFO  [cloud.usage.UsageManagerImpl] (Usage-Job-1:null) 
(logid:) starting usage job...
2020-05-04 12:45:00,015 DEBUG [cloud.usage.UsageManagerImpl] (Usage-Job-1:null) 
(logid:) Not owner of usage job, skipping...
2020-05-04 12:45:00,015 INFO  [cloud.usage.UsageManagerImpl] (Usage-Job-1:null) 
(logid:) usage job complete

So the job did not run for some reason... I'm still looking into this. So 
currently I can't confirm but will update you later as soon as the usage job 
did run.

Regards
Liridon
-Original Message-
From: Rohit Yadav 
mailto:rohit%20yadav%20%3crohit.ya...@shapeblue.com%3e>>
Reply-To: users@cloudstack.apache.org<mailto:users@cloudstack.apache.org>
To: d...@cloudstack.apache.org 
mailto:%22...@cloudstack.apache.org%22%20%3c...@cloudstack.apache.org%3e>>,
 andrija.pa...@gmail.com 
mailto:%22andrija.pa...@gmail.com%22%20%3candrija.pa...@gmail.com%3e>>,
 users@cloudstack.apache.org 
mailto:%22us...@cloudstack.apache.org%22%20%3cus...@cloudstack.apache.org%3e>>
Subject: Re: [VOTE] Apache CloudStack 4.14.0.0 RC1
Date: Mon, 04 May 2020 10:16:51 +


Thanks for testing and sharing your results Liridon!


Can you also test the case if the usage records have the correct time according 
to configured timezone (in global settings) if you're using a non-UTC timezone?


I'll add the db.usage.url.paramsl as well in the PR.



Regards,


Rohit Yadav


Software Architect, ShapeBlue


<https://www.shapeblue.com>

https://www.shapeblue.com



________

From: Ismaili, Liridon (SWISS TXT) <

<mailto:liridon.isma...@swisstxt.ch>

liridon.isma...@swisstxt.ch

>

Sent: Monday, May 4, 2020 15:38

To:

<mailto:d...@cloudstack.apache.org>

d...@cloudstack.apache.org

 <

<mailto:d...@cloudstack.apache.org>

d...@cloudstack.apache.org

>;

<mailto:andrija.pa...@gmail.com>

andrija.pa...@gmail.com

 <

<mailto:andrija.pa...@gmail.com>

andrija.pa...@gmail.com

>;

<mailto:users@cloudstack.apache.org>

users@cloudstack.apache.org

 <

<mailto:users@cloudstack.apache.org>

users@cloudstack.apache.org

>

Subject: Re: [VOTE] Apache CloudStack 4.14.0.0 RC1


Hi Rohit


That did the trick! I did remove all the timezone information on my.cnf and 
only added the timezone information on the db.properties file.

So I can confirm it fixes the issue.


If you are using the usage service too you will also need to specify the 
timezone information for the usage DB:

"db.usage.url.params=" in the /etc/cloudstack/management/db.properties file. 
Otherwise the usage service won't be able to start.


This did also fix my issue and all my dates inside the db are now in the 
correct time zone! I'll also update the Github PR so we can track it there.


Many thanks and Regards

Liridon


<mailto:rohit.ya...@shapeblue.com>

rohit.ya...@shapeblue.com



<http://www.shapeblue.com>

www.shapeblue.com


3 London Bridge Street,  3rd floor, News Building, London  SE1 9SGUK

@shapeblue







-Original Message-

From: "Ismaili, Liridon (SWISS TXT)" <

<mailto:liridon.isma...@swisstxt.ch>

liridon.isma...@swisstxt.ch

<mailto:%22Ismaili,

<mailto:%20liridon%20%28swiss%20txt%29%22%20%3cliridon.isma...@swisstxt.ch>

%20liridon%20%28swiss%20txt%29%22%20%3cliridon.isma...@swisstxt.ch

%3e>>

Reply-To:

<mailto:users@cloudstack.apache.org>

users@cloudstack.apache.org

mailto:users@cloudstack.apache.org>

users@cloudstack.apache.org

>

To:

<mailto:d...@cloudstack.apache.org>

d...@cloudstack.apache.org

 <

<mailto:d...@cloudstack.apache.org>

d...@cloudstack.apache.org

mailto:%22...@cloudstack.apache.org>

%22...@cloudstack.apache.org

<mailto:%22%20%3c...@cloudstack.apache.org>

%22%20%3c...@cloudstack.apache.org

%3e>>,

<mailto:andrija.pa...@gmail.com>

andrija.pa...@gmail.com

 <

<mailto:andrija.pa...@gmail.com>

andrija.pa...@gmail.com

mailto:%22andrija.pa...@gmail.com>

%22andrija.pa...@gmail.com

<mailto:%22%20%3candrija.pa...@gmail.com>

%22%20%3candrija.pa...@gmail.com

%3e>>,

<mailto:users@cloudstack.apache.org>

users@cloudstack.apache.org

 <

<mailto:users@cloudstack.apache.org>

users@cloudstack.apache.org

mailto:%22us...@cloudstack.apache.org>

%22us...@cloudstack.apache.org

<mailto:%22%20%3cus...@cloudstack.apache.org>

%22%20%3cus...@cloudstack.apache.org

%3e>>

Subject: Re: [VOTE] Apache CloudStack 4.14.0.0 RC1

Date: Mon, 04 May 2020 09:53:35 +



Hi Rohit



I'll test that and let you know.



Regards


Liridon



-Original Message-


From: Rohit Yadav <


mailto:rohit.ya...@shapeblue.com>

rohit.ya...@shapeblue.com

>

Re: [VOTE] Apache CloudStack 4.14.0.0 RC1

[Ismaili, Liridon (SWISS TXT)]

Hi Rohit

That did the trick! I did remove all the timezone information on my.cnf and 
only added the timezone information on the db.properties file.
So I can confirm it fixes the issue.

If you are using the usage service too you will also need to specify the 
timezone information for the usage DB:
"db.usage.url.params=" in the /etc/cloudstack/management/db.properties file. 
Otherwise the usage service won't be able to start.

This did also fix my issue and all my dates inside the db are now in the 
correct time zone! I'll also update the Github PR so we can track it there.

Many thanks and Regards
Liridon

-Original Message-----
From: "Ismaili, Liridon (SWISS TXT)" 
mailto:%22Ismaili,%20liridon%20%28swiss%20txt%29%22%20%3cliridon.isma...@swisstxt.ch%3e>>
Reply-To: users@cloudstack.apache.org<mailto:users@cloudstack.apache.org>
To: d...@cloudstack.apache.org 
mailto:%22...@cloudstack.apache.org%22%20%3c...@cloudstack.apache.org%3e>>,
 andrija.pa...@gmail.com 
mailto:%22andrija.pa...@gmail.com%22%20%3candrija.pa...@gmail.com%3e>>,
 users@cloudstack.apache.org 
mailto:%22us...@cloudstack.apache.org%22%20%3cus...@cloudstack.apache.org%3e>>
Subject: Re: [VOTE] Apache CloudStack 4.14.0.0 RC1
Date: Mon, 04 May 2020 09:53:35 +


Hi Rohit


I'll test that and let you know.


Regards

Liridon


-Original Message-

From: Rohit Yadav <

<mailto:rohit.ya...@shapeblue.com>

rohit.ya...@shapeblue.com

mailto:rohit%20yadav%20%3crohit.ya...@shapeblue.com>

rohit%20yadav%20%3crohit.ya...@shapeblue.com

%3e>>

Reply-To:

<mailto:d...@cloudstack.apache.org>

d...@cloudstack.apache.org

mailto:d...@cloudstack.apache.org>

d...@cloudstack.apache.org

>

To: Andrija Panic <

<mailto:andrija.pa...@gmail.com>

andrija.pa...@gmail.com

mailto:andrija%20panic%20%3candrija.pa...@gmail.com>

andrija%20panic%20%3candrija.pa...@gmail.com

%3e>>, users <

<mailto:users@cloudstack.apache.org>

users@cloudstack.apache.org

mailto:users%20%3cus...@cloudstack.apache.org>

users%20%3cus...@cloudstack.apache.org

%3e>>,

<mailto:d...@cloudstack.apache.org>

d...@cloudstack.apache.org

 <

<mailto:d...@cloudstack.apache.org>

d...@cloudstack.apache.org

mailto:%22...@cloudstack.apache.org>

%22...@cloudstack.apache.org

<mailto:%22%20%3c...@cloudstack.apache.org>

%22%20%3c...@cloudstack.apache.org

%3e>>

Subject: Re: [VOTE] Apache CloudStack 4.14.0.0 RC1

Date: Mon, 04 May 2020 09:50:10 +



Hi Andrija, all,



While adding support for Java 11, the mysql-connector 8.x java dependency was 
introduced from previous 5.7x version.



According to


<

<https://dev.mysql.com/doc/connector-j/8.0/en/connector-j-usagenotes-known-issues-limitations.html>

https://dev.mysql.com/doc/connector-j/8.0/en/connector-j-usagenotes-known-issues-limitations.html

>


<https://dev.mysql.com/doc/connector-j/8.0/en/connector-j-usagenotes-known-issues-limitations.html>

https://dev.mysql.com/doc/connector-j/8.0/en/connector-j-usagenotes-known-issues-limitations.html



 it seems we can specify the server time in connection parameters. Can any 
users test this workaround and confirm if it fixes their issue in their 
test/upgrade environments by adding  "&serverTimezone=UTC" to the 
"db.cloud.url.params=" in the /etc/cloudstack/management/db.properties file, 
revert changes for mysql server and restart the management server.



Draft PR proposed:


<

<https://github.com/apache/cloudstack/pull/4055/files>

https://github.com/apache/cloudstack/pull/4055/files

>


<https://github.com/apache/cloudstack/pull/4055/files>

https://github.com/apache/cloudstack/pull/4055/files





We may then either discuss to either include the above PR or document this in 
our release/upgrade notes. Thanks.




Regards,



Rohit Yadav



Software Architect, ShapeBlue



<

<https://www.shapeblue.com>

https://www.shapeblue.com

>


<https://www.shapeblue.com>

https://www.shapeblue.com








From: Andrija Panic <


mailto:andrija.pa...@gmail.com>

andrija.pa...@gmail.com

>


<mailto:andrija.pa...@gmail.com>

andrija.pa...@gmail.com





Sent: Friday, May 1, 2020 22:38


To: users <


mailto:users@cloudstack.apache.org>

users@cloudstack.apache.org

>


<mailto:users@cloudstack.apache.org>

users@cloudstack.apache.org



; Rohit Yadav <


mailto:rohit.ya...@shapeblue.com>

rohit.ya...@shapeblue.com

>


<mailto:rohit.ya...@shapeblue.com>

rohit.ya...@shapeblue.com





Subject: Re: [VOTE] Apache CloudStack 4.14.0.0 RC1



@Rohit Yadavmailto:rohit.ya...@shapeblue.com>

rohit.ya...@shapeblue.com

>


<mailto:rohit.ya...@shapeblue.com>

rohit.ya...@shapeblue.com



can you possibly advice on the time zone issue? I've seen this on another ML

Re: [VOTE] Apache CloudStack 4.14.0.0 RC1

[Ismaili, Liridon (SWISS TXT)]

Hi Rohit

I'll test that and let you know.

Regards
Liridon

-Original Message-
From: Rohit Yadav 
mailto:rohit%20yadav%20%3crohit.ya...@shapeblue.com%3e>>
Reply-To: d...@cloudstack.apache.org
To: Andrija Panic 
mailto:andrija%20panic%20%3candrija.pa...@gmail.com%3e>>,
 users 
mailto:users%20%3cus...@cloudstack.apache.org%3e>>,
 d...@cloudstack.apache.org 
mailto:%22...@cloudstack.apache.org%22%20%3c...@cloudstack.apache.org%3e>>
Subject: Re: [VOTE] Apache CloudStack 4.14.0.0 RC1
Date: Mon, 04 May 2020 09:50:10 +


Hi Andrija, all,


While adding support for Java 11, the mysql-connector 8.x java dependency was 
introduced from previous 5.7x version.


According to



https://dev.mysql.com/doc/connector-j/8.0/en/connector-j-usagenotes-known-issues-limitations.html

 it seems we can specify the server time in connection parameters. Can any 
users test this workaround and confirm if it fixes their issue in their 
test/upgrade environments by adding  "&serverTimezone=UTC" to the 
"db.cloud.url.params=" in the /etc/cloudstack/management/db.properties file, 
revert changes for mysql server and restart the management server.


Draft PR proposed:



https://github.com/apache/cloudstack/pull/4055/files



We may then either discuss to either include the above PR or document this in 
our release/upgrade notes. Thanks.



Regards,


Rohit Yadav


Software Architect, ShapeBlue




https://www.shapeblue.com





From: Andrija Panic <



andrija.pa...@gmail.com

>

Sent: Friday, May 1, 2020 22:38

To: users <



users@cloudstack.apache.org

>; Rohit Yadav <



rohit.ya...@shapeblue.com

>

Subject: Re: [VOTE] Apache CloudStack 4.14.0.0 RC1


@Rohit Yadavmailto:rohit.ya...@shapeblue.com>

rohit.ya...@shapeblue.com

> can you possibly advice on the time zone issue? I've seen this on another ML 
> thread as well. We are mostly in UTC (test envs) so this might be the reason 
> we didn't see this...could be just a documentation update that is needed.


@Robert is there any specifics to your NFS server (i.e. a forbidden NFSv3 or 
similar)? Also, can you please open a GitHub issue and provide the same there? 
So we can track it and collaborate - I've not seen this one before.

What packages did you use for the installation? On the issue you'll raise, 
please also include the relevant output from the /var/log/cloud.log from inside 
the SSVM

Also not sure what is the relation between MySQL and JRE at all - they should 
have nothing in common?


Thanks!


Andrija






rohit.ya...@shapeblue.com





www.shapeblue.com


3 London Bridge Street,  3rd floor, News Building, London  SE1 9SGUK

@shapeblue






On Fri, 1 May 2020 at 17:49, Robert Ward <



rww...@gmail.com

mailto:rww...@gmail.com>

rww...@gmail.com

>> wrote:

Hi all,


I too have run into an issues while performing a clean install:

Centos 7, MySQL 5.6, JRE 11


JRE 11 and MySQL 5.6 don't see to play well on two points:


Installing JRE before MySQL causes MYSQL to "lockup" on startup. I have found 
that if I install JRE after MySQL that issue is resolved.


MySQL chokes with timezone error @ cloudstack-setup-management. In my case 
MySQL doesn't like "EDT" as a timezone. Resolved by adding this to etc/my.cnf:


default-time-zone= "-05:00"


On my last point CS has difficulty with mounting secondary storage. I have 
clipped the logs to the point where I think the problem lies:


2020-05-01 10:55:07,871 DEBUG [c.c.h.o.r.Ovm3HypervisorGuru] 
(StatsCollector-5:ctx-35c593ba) (logid:aad9ed2a) getCommandHostDelegation: 
class com.cloud.agent.api.GetStorageStatsCommand

2020-05-01 10:55:07,871 DEBUG [c.c.h.XenServerGuru] 
(StatsCollector-5:ctx-35c593ba) (logid:aad9ed2a) We are returning the default 
host to execute commands because the command is not of Copy type.

2020-05-01 10:55:07,910 DEBUG [c.c.a.t.Request] (AgentManager-Handler-8:null) 
(logid:) Seq 2-4356951164504244991: Processing:  { Ans: , MgmtId: 144345337593, 
via: 2, Ver: v1, Flags: 10, 
[{"com.cloud.agent.api.Answer":{"result":false,"details":"com.cloud.utils.exception.CloudRuntimeException:
 GetRootDir for nfs://192.168.25.1/export/secondary<



http://192.168.25.1/export/secondary

> failed due to com.cloud.utils.exception.CloudRuntimeException: Unable to 
> mount 192.168.25.1:/export/secondary at 
> /mnt/SecStorage/b7e9e158-ed80-3a62-a5d7-1992c991d829 due to mount.nfs: 
> requested NFS version or transport protocol is not supported\n\tat 
> org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.getRootDir(NfsSecondarySto

Re: [VOTE] Apache CloudStack 4.14.0.0 RC1

[Ismaili, Liridon (SWISS TXT)]

Hi Andrija

To answer your question: Yes that's something we hit during testing 4.14 only. 
I also did test 4.13.1 (and other releases) and there it was not required.
With CS 4.14 we have to upgrade Java JRE to version 11. This is used under 
mysql JDBC driver which requires now to set a time zone. If your System has UTC 
configured it can handle it without specifically configured under my.cnf. 
However if you time zone is something like CEST (as it was in my case) or EDT 
(as it was in Roberts case) mysql won't be able to establish a connection and 
will give the error message that "CEST" is not known and requires you to set 
the time zone information inside the my.cnf file.

The upgrade went fine but for some reason my dates are configured as UTC inside 
the database. I'm still looking into this. All time zone related configuration 
I found in the global configurations were related to usage and were already 
correct.
Regards
Liridon

-Original Message-
From: "Riepl, Gregor (SWISS TXT)" 
mailto:%22Riepl,%20gregor%20%28swiss%20txt%29%22%20%3cgregor.ri...@swisstxt.ch%3e>>
Reply-To: users@cloudstack.apache.org<mailto:users@cloudstack.apache.org>
To: users 
mailto:users%20%3cus...@cloudstack.apache.org%3e>>
Subject: Re: [VOTE] Apache CloudStack 4.14.0.0 RC1
Date: Mon, 04 May 2020 09:38:48 +


Hi Andrija,


Ah no, I just had a quick look out the MySQL documentation, because I vaguely 
remembered that SET GLOBAL may not be permanent.

Just wanted to comment on that, so people don't run into nasty surprises later.


Regards,

Gregor



From: Andrija Panic <

<mailto:andrija.pa...@gmail.com>

andrija.pa...@gmail.com

>

Sent: 04 May 2020 11:35

To: users <

<mailto:users@cloudstack.apache.org>

users@cloudstack.apache.org

>

Subject: Re: [VOTE] Apache CloudStack 4.14.0.0 RC1


Gregor,


is this something you've also hit during testing 4.14 only, or are you

aware of the need for setting those values even before (4.11-4.13) ?


Thanks

Andrija


On Mon, 4 May 2020 at 10:49, Riepl, Gregor (SWISS TXT) <

<mailto:gregor.ri...@swisstxt.ch>

gregor.ri...@swisstxt.ch

> wrote:


Hi Liridon,


Note that


SET GLOBAL time_zone = '+2:00';


has the mostly same effect as writing


default-time-zone= "-05:00"


to /etc/my.cnf


The difference is that using SET GLOBAL does not persist the setting

across MySQL starts. You should write this setting into the configuration

file to make it permanent.

See

<https://dev.mysql.com/doc/refman/5.7/en/using-system-variables.html>

https://dev.mysql.com/doc/refman/5.7/en/using-system-variables.html


and

<https://dev.mysql.com/doc/refman/5.7/en/set-variable.html>

https://dev.mysql.com/doc/refman/5.7/en/set-variable.html

 for more

info.


Regards,

Gregor



From: Ismaili, Liridon (SWISS TXT) <

<mailto:liridon.isma...@swisstxt.ch>

liridon.isma...@swisstxt.ch

>

Sent: 01 May 2020 19:52

To:

<mailto:users@cloudstack.apache.org>

users@cloudstack.apache.org

 <

<mailto:users@cloudstack.apache.org>

users@cloudstack.apache.org

>

Subject: Re: [VOTE] Apache CloudStack 4.14.0.0 RC1


@Robert I did add the default-time-zone parameter to the my.cnf file but

the dates inside CloudStack are still in UTC format. select now() however

gives me the correct output:

mysql> select now();

+-+

now()   |

+-+

2020-05-01 19:48:38 |

+-+

1 row in set (0.00 sec)

Does anyone else have such wrong dates? All tables in the cloud DB seems

to be affected.

Regards Liridon


-Original Message-

From: Andrija Panic <

<mailto:andrija.pa...@gmail.com>

andrija.pa...@gmail.com

mailto:andrija%20panic%20%3candrija.pa...@gmail.com>

andrija%20panic%20%3candrija.pa...@gmail.com

%3e>>

Reply-To:

<mailto:users@cloudstack.apache.org>

users@cloudstack.apache.org

mailto:users@cloudstack.apache.org>

users@cloudstack.apache.org

>

To: users <

<mailto:users@cloudstack.apache.org>

users@cloudstack.apache.org

mailto:users%20%3cus...@cloudstack.apache.org>

users%20%3cus...@cloudstack.apache.org

%3e>>, Rohit Yadav <

<mailto:rohit.ya...@shapeblue.com>

rohit.ya...@shapeblue.com

mailto:rohit%20yadav%20%3crohit.ya...@shapeblue.com>

rohit%20yadav%20%3crohit.ya...@shapeblue.com

%3e>>

Subject: Re: [VOTE] Apache CloudStack 4.14.0.0 RC1

Date: Fri, 01 May 2020 19:08:16 +0200



@Rohit Yadav <


mailto:rohit.ya...@shapeblue.com>

rohit.ya...@shapeblue.com

>


<mailto:rohit.ya...@shapeblue.com>

rohit.ya...@shapeblue.com



can you possibly advice on the


time zone issue? I've seen this on another ML thread as well. We are mostly


in UTC (test envs) so this might be the reason we didn't see this

Re: [VOTE] Apache CloudStack 4.14.0.0 RC1

[Ismaili, Liridon (SWISS TXT)]

@Robert I did add the default-time-zone parameter to the my.cnf file but the 
dates inside CloudStack are still in UTC format. select now() however gives me 
the correct output:
mysql> select now();
+-+
| now()   |
+-+
| 2020-05-01 19:48:38 |
+-+
1 row in set (0.00 sec)
Does anyone else have such wrong dates? All tables in the cloud DB seems to be 
affected.
Regards Liridon

-Original Message-
From: Andrija Panic 
mailto:andrija%20panic%20%3candrija.pa...@gmail.com%3e>>
Reply-To: users@cloudstack.apache.org
To: users 
mailto:users%20%3cus...@cloudstack.apache.org%3e>>,
 Rohit Yadav 
mailto:rohit%20yadav%20%3crohit.ya...@shapeblue.com%3e>>
Subject: Re: [VOTE] Apache CloudStack 4.14.0.0 RC1
Date: Fri, 01 May 2020 19:08:16 +0200


@Rohit Yadav <



rohit.ya...@shapeblue.com

> can you possibly advice on the

time zone issue? I've seen this on another ML thread as well. We are mostly

in UTC (test envs) so this might be the reason we didn't see this...could

be just a documentation update that is needed.


@Robert is there any specifics to your NFS server (i.e. a forbidden NFSv3

or similar)? Also, can you please open a GitHub issue and provide the same

there? So we can track it and collaborate - I've not seen this one before.

What packages did you use for the installation? On the issue you'll raise,

please also include the relevant output from the /var/log/cloud.log from

inside the SSVM

Also not sure what is the relation between MySQL and JRE at all - they

should have nothing in common?


Thanks!


Andrija



On Fri, 1 May 2020 at 17:49, Robert Ward <



rww...@gmail.com

> wrote:


Hi all,


I too have run into an issues while performing a clean install:

Centos 7, MySQL 5.6, JRE 11


JRE 11 and MySQL 5.6 don't see to play well on two points:


Installing JRE before MySQL causes MYSQL to "lockup" on startup. I have

found that if I install JRE after MySQL that issue is resolved.


MySQL chokes with timezone error @ cloudstack-setup-management. In my case

MySQL doesn't like "EDT" as a timezone. Resolved by adding this to

etc/my.cnf:


default-time-zone= "-05:00"


On my last point CS has difficulty with mounting secondary storage. I have

clipped the logs to the point where I think the problem lies:


2020-05-01 10:55:07,871 DEBUG [c.c.h.o.r.Ovm3HypervisorGuru]

(StatsCollector-5:ctx-35c593ba) (logid:aad9ed2a) getCommandHostDelegation:

class com.cloud.agent.api.GetStorageStatsCommand

2020-05-01 10:55:07,871 DEBUG [c.c.h.XenServerGuru]

(StatsCollector-5:ctx-35c593ba) (logid:aad9ed2a) We are returning the

default host to execute commands because the command is not of Copy type.

2020-05-01 10:55:07,910 DEBUG [c.c.a.t.Request]

(AgentManager-Handler-8:null) (logid:) Seq 2-4356951164504244991:

Processing:  { Ans: , MgmtId: 144345337593, via: 2, Ver: v1, Flags: 10,

[{"com.cloud.agent.api.Answer":{"result":false,"details":"com.cloud.utils.exception.CloudRuntimeException:

GetRootDir for nfs://192.168.25.1/export/secondary failed due to

com.cloud.utils.exception.CloudRuntimeException: Unable to mount

192.168.25.1:/export/secondary at

/mnt/SecStorage/b7e9e158-ed80-3a62-a5d7-1992c991d829 due to mount.nfs:

requested NFS version or transport protocol is not supported\n\tat

org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.getRootDir(NfsSecondaryStorageResource.java:2458)\n\tat

org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.execute(NfsSecondaryStorageResource.java:2208)\n\tat

org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.executeRequest(NfsSecondaryStorageResource.java:292)\n\tat

com.cloud.storage.resource.PremiumSecondaryStorageResource.defaultAction(PremiumSecondaryStorageResource.java:64)\n\tat

com.cloud.storage.resource.PremiumSecondaryStorageResource.executeRequest(PremiumSecondaryStorageResource.java:60)\n\tat

com.cloud.agent.Agent.processRequest(Agent.java:644)\n\tat

com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:1057)\n\tat

com.cloud.utils.nio.Task.call(Task.java:83)\n\tat

com.cloud.utils.nio.Task.call(Task.java:29)\n\tat

java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)\n\tat

java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)\n\tat

java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)\n\tat

java.base/java.lang.Thread.run(Thread.java:834)\n","wait":0}}] }


My troubleshooting steps:


restart SSVM

restart MS

restart agent

verify I can manually mount secondary storage on agent and navigate

through all directories.

change secondary storage version from null to V4 in CS global settings


Any input is greatly appreciated on how to resolve.


Thanks,


Robert

On 2020/04/29 14:38:44, Andrija Panic <



andrija.pa...@gmai

Re: [VOTE] Apache CloudStack 4.14.0.0 RC1

[Ismaili, Liridon (SWISS TXT)]

Hi Andrija

First of thank you and Gabriel for pre-building the packages!
I did upgrade our test environment to CS 4.14.0.0 but had some issues on the 
first upgrade try. As Java JRE 11 is required under CS 4.14.0.0 I did install 
it on the cs-mgmt server. After that I made the Upgrade and saw the following 
exception:
2020-05-01 11:45:12,116 ERROR [utils.db.Merovingian2] (main:null) Unable to get 
a new db connection
java.sql.SQLNonTransientConnectionException: Could not create connection to 
database server. Attempted reconnect 3 times. Giving up.
at 
com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:110)
at 
com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:97)
at 
com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:89)
at 
com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:63)
at 
com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:73)
at 
com.mysql.cj.jdbc.ConnectionImpl.connectWithRetries(ConnectionImpl.java:906)
at com.mysql.cj.jdbc.ConnectionImpl.createNewIO(ConnectionImpl.java:831)
at com.mysql.cj.jdbc.ConnectionImpl.(ConnectionImpl.java:456)
at com.mysql.cj.jdbc.ConnectionImpl.getInstance(ConnectionImpl.java:246)
at 
com.mysql.cj.jdbc.NonRegisteringDriver.connect(NonRegisteringDriver.java:197)
at java.sql/java.sql.DriverManager.getConnection(DriverManager.java:677)
at java.sql/java.sql.DriverManager.getConnection(DriverManager.java:228)
at 
org.apache.commons.dbcp2.DriverManagerConnectionFactory.createConnection(DriverManagerConnectionFactory.java:121)
at 
org.apache.commons.dbcp2.PoolableConnectionFactory.makeObject(PoolableConnectionFactory.java:355)
at 
org.apache.commons.pool2.impl.GenericObjectPool.create(GenericObjectPool.java:889)
at 
org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:424)
at 
org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:349)
at 
org.apache.commons.dbcp2.PoolingDataSource.getConnection(PoolingDataSource.java:134)
at 
com.cloud.utils.db.TransactionLegacy.getStandaloneConnectionWithException(TransactionLegacy.java:213)
at com.cloud.utils.db.Merovingian2.(Merovingian2.java:68)
at 
com.cloud.utils.db.Merovingian2.createLockMaster(Merovingian2.java:88)
at 
com.cloud.server.LockMasterListener.(LockMasterListener.java:33)
at 
java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
 Method)
at 
java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at 
java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
at 
org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:203)
at 
org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:117)
at 
org.springframework.beans.factory.support.ConstructorResolver.instantiate(ConstructorResolver.java:310)
at 
org.springframework.beans.factory.support.ConstructorResolver.autowireConstructor(ConstructorResolver.java:295)
at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.autowireConstructor(AbstractAutowireCapableBeanFactory.java:1358)
at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:1204)
at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:557)
at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:517)
at 
org.springframework.beans.factory.support.AbstractBeanFactory.lambda$doGetBean$0(AbstractBeanFactory.java:323)
at 
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222)
at 
org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:321)
at 
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:202)
at 
org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:879)
at 
org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:878)
at 
org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:550)
at 
org.apache.cloudstack.spring.module.model.impl.DefaultModul

Re: Creating Windows Server 2019 templates with cloudbase init

[Ismaili, Liridon (SWISS TXT)]

Hi,

@Simon: correct - was a timing issue. I could speed it up by telling 
cloudbase-init to only use the CloudStack metadata. Otherwise it will try a lot 
of other possible cloud providers (like openstack, aws, etc).
You can do that with the following setting, which needs to be set inside the 
cloudbase-init.conf file:
metadata_services=cloudbaseinit.metadata.services.cloudstack.CloudStack

With this setting it does set the new password right after the startup and you 
don't need to wait or reboot the VM anymore.

Regards
Liridon

-Original Message-
From: simon.voel...@zv.fraunhofer.de<mailto:simon.voel...@zv.fraunhofer.de>
Reply-To: users@cloudstack.apache.org<mailto:users@cloudstack.apache.org>
To: users@cloudstack.apache.org<mailto:users@cloudstack.apache.org>
Subject: Re: Creating Windows Server 2019 templates with cloudbase init
Date: Tue, 14 Jan 2020 18:26:46 +


Hi,


Thanks! That’s very helpful.


For resetting the password I had a timing issue, I think. Did you try a reset 
of the password and reboot the VM twice? I believe that worked for me during 
testing.


Regards

Simon


On 14. Jan 2020, at 19:13, Ismaili, Liridon (SWISS TXT) <

<mailto:liridon.isma...@swisstxt.ch>

liridon.isma...@swisstxt.ch

> wrote:


Hi,

@Simon:

There is a config (found in <

<https://cloudbase-init.readthedocs.io/en/latest/plugins.html#setting-password-main>

https://cloudbase-init.readthedocs.io/en/latest/plugins.html#setting-password-main

>

<https://cloudbase-init.readthedocs.io/en/latest/plugins.html#setting-password-main>

https://cloudbase-init.readthedocs.io/en/latest/plugins.html#setting-password-main

) called first_logon_behavior which you can set to 'no'. This will allow you to 
setup the password with no need to be reset after the first login.

So this one was indeed a cloudbase-init "feature". I did test that and it works 
fine for me under MS Windows Server 2019.


What I get now is, that cloudbase-init allows me to set the password only once 
- so I can't reset it after the first launch of the instance. I did create an 
issue for this one but I believe that this was by design.


Regards

Liridon


-Original Message-

From:

<mailto:n...@li.nux.ro>

n...@li.nux.ro

mailto:n...@li.nux.ro>

n...@li.nux.ro

>

Reply-To:

<mailto:users@cloudstack.apache.org>

users@cloudstack.apache.org

mailto:users@cloudstack.apache.org>

users@cloudstack.apache.org

>

To:

<mailto:users@cloudstack.apache.org>

users@cloudstack.apache.org

mailto:users@cloudstack.apache.org>

users@cloudstack.apache.org

>

Subject: Re: Creating Windows Server 2019 templates with cloudbase init

Date: Tue, 14 Jan 2020 13:43:04 +

Mailer: Roundcube Webmail/1.4-rc1



It's quite possible. I try to do the minimum where Windows is concerned,


so I stopped at using the old CloudInstanceManager when I saw it's


working.




On 2020-01-14 13:28,


mailto:simon.voel...@zv.fraunhofer.de>

simon.voel...@zv.fraunhofer.de

>


<mailto:simon.voel...@zv.fraunhofer.de>

simon.voel...@zv.fraunhofer.de



wrote:


Hi,



I believe that having to set a new password after it has been reset is


supposed to be a feature from Microsoft’s side. I’ve also noticed that


login through RDP is disabled until a new password has been set. So


far I haven’t been able to get it to work completely. (mainly due to


time constraints)



Regards



Simon Völker



Fraunhofer-Gesellschaft e.V.


Schloss Birlinghoven


53754 Sankt Augustin


Telefon: +49 2241 14-2311


E-mail:


mailto:simon.voel...@zv.fraunhofer.de>

simon.voel...@zv.fraunhofer.de

>


<mailto:simon.voel...@zv.fraunhofer.de>

simon.voel...@zv.fraunhofer.de



mailto:simon.voel...@zv.fraunhofer.de>

simon.voel...@zv.fraunhofer.de

>


<mailto:simon.voel...@zv.fraunhofer.de>

simon.voel...@zv.fraunhofer.de








Am 14.01.2020 um 14:20 schrieb


mailto:n...@li.nux.ro>

n...@li.nux.ro

>


<mailto:n...@li.nux.ro>

n...@li.nux.ro



mailto:n...@li.nux.ro>

n...@li.nux.ro

>


<mailto:n...@li.nux.ro>

n...@li.nux.ro



:



Hi,



This could be a bug (or undocumented feature, ahem) with


cloudbase-init.


Despite efforts I never got it to work reliably in the past, not sure


about now.


Have you tried using CloudInstanceManager.msi for setting the


password? It still works for me.



What I do is set up the template with a sysprep and unattend.xml where


I also set a default password (perhaps this is what stops it from


asking for new user pass), then on first boots CloudInstanceManager


sets up the password without problems and resets work, too. SG zone


btw.



Lucian



On 2020-01-14 12:53, Ismaili, Liridon (SWISS TXT) wrote:


Hi Simon


We are also building some new windows templates and would like to use


cloudbase-init as you do.


I get the same behavior as you did describe (a

Re: Creating Windows Server 2019 templates with cloudbase init

[Ismaili, Liridon (SWISS TXT)]

Hi,
@Simon:
There is a config (found in 
<https://cloudbase-init.readthedocs.io/en/latest/plugins.html#setting-password-main>
 
https://cloudbase-init.readthedocs.io/en/latest/plugins.html#setting-password-main)
 called first_logon_behavior which you can set to 'no'. This will allow you to 
setup the password with no need to be reset after the first login.
So this one was indeed a cloudbase-init "feature". I did test that and it works 
fine for me under MS Windows Server 2019.

What I get now is, that cloudbase-init allows me to set the password only once 
- so I can't reset it after the first launch of the instance. I did create an 
issue for this one but I believe that this was by design.

Regards
Liridon

-Original Message-
From: n...@li.nux.ro<mailto:n...@li.nux.ro>
Reply-To: users@cloudstack.apache.org<mailto:users@cloudstack.apache.org>
To: users@cloudstack.apache.org<mailto:users@cloudstack.apache.org>
Subject: Re: Creating Windows Server 2019 templates with cloudbase init
Date: Tue, 14 Jan 2020 13:43:04 +
Mailer: Roundcube Webmail/1.4-rc1


It's quite possible. I try to do the minimum where Windows is concerned,

so I stopped at using the old CloudInstanceManager when I saw it's

working.



On 2020-01-14 13:28,

<mailto:simon.voel...@zv.fraunhofer.de>

simon.voel...@zv.fraunhofer.de

 wrote:

Hi,


I believe that having to set a new password after it has been reset is

supposed to be a feature from Microsoft’s side. I’ve also noticed that

login through RDP is disabled until a new password has been set. So

far I haven’t been able to get it to work completely. (mainly due to

time constraints)


Regards


Simon Völker


Fraunhofer-Gesellschaft e.V.

Schloss Birlinghoven

53754 Sankt Augustin

Telefon: +49 2241 14-2311

E-mail:

<mailto:simon.voel...@zv.fraunhofer.de>

simon.voel...@zv.fraunhofer.de

mailto:simon.voel...@zv.fraunhofer.de>

simon.voel...@zv.fraunhofer.de

>




Am 14.01.2020 um 14:20 schrieb

<mailto:n...@li.nux.ro>

n...@li.nux.ro

mailto:n...@li.nux.ro>

n...@li.nux.ro

>:


Hi,


This could be a bug (or undocumented feature, ahem) with

cloudbase-init.

Despite efforts I never got it to work reliably in the past, not sure

about now.

Have you tried using CloudInstanceManager.msi for setting the

password? It still works for me.


What I do is set up the template with a sysprep and unattend.xml where

I also set a default password (perhaps this is what stops it from

asking for new user pass), then on first boots CloudInstanceManager

sets up the password without problems and resets work, too. SG zone

btw.


Lucian


On 2020-01-14 12:53, Ismaili, Liridon (SWISS TXT) wrote:

Hi Simon

We are also building some new windows templates and would like to use

cloudbase-init as you do.

I get the same behavior as you did describe (after password reset it

requires to setup a new password). How did you workaround this? I

expect this to be a policy issue but would like to ask before I search

to long as you had the same issue.

Regards

Liridon

-Original Message-

From:

<mailto:simon.voel...@zv.fraunhofer.de>

simon.voel...@zv.fraunhofer.de

mailto:simon.voel...@zv.fraunhofer.de>

simon.voel...@zv.fraunhofer.de

>mailto:simon.voel...@zv.fraunhofer.de>

simon.voel...@zv.fraunhofer.de

>

Reply-To:

<mailto:users@cloudstack.apache.org>

users@cloudstack.apache.org

mailto:users@cloudstack.apache.org>

users@cloudstack.apache.org

>mailto:users@cloudstack.apache.org>

users@cloudstack.apache.org

>

To:

<mailto:users@cloudstack.apache.org>

users@cloudstack.apache.org

mailto:users@cloudstack.apache.org>

users@cloudstack.apache.org

>mailto:users@cloudstack.apache.org>

users@cloudstack.apache.org

>

Subject: Re: Creating Windows Server 2019 templates with cloudbase init

Date: Mon, 09 Sep 2019 07:54:02 +

Hi,

we are using cloudplatform 4.11 which is based on cloudstack 4.10.

Regards

Simon Völker

Fraunhofer-Gesellschaft e.V.

Schloss Birlinghoven

53754 Sankt Augustin

Telefon: +49 2241 14-2311

E-mail:

mailto:simon.voel...@zv.fraunhofer.de>

simon.voel...@zv.fraunhofer.de

>

<mailto:simon.voel...@zv.fraunhofer.de>

simon.voel...@zv.fraunhofer.de

mailto:simon.voel...@zv.fraunhofer.de>

simon.voel...@zv.fraunhofer.de

>

mailto:simon.voel...@zv.fraunhofer.de>

simon.voel...@zv.fraunhofer.de

>

<mailto:simon.voel...@zv.fraunhofer.de>

simon.voel...@zv.fraunhofer.de


Am 06.09.2019 um 15:34 schrieb Andrija Panic <

mailto:andrija.pa...@gmail.com>

andrija.pa...@gmail.com

>

<mailto:andrija.pa...@gmail.com>

andrija.pa...@gmail.com


mailto:andrija.pa...@gmail.com>

andrija.pa...@gmail.com

>

<mailto:andrija.pa...@gmail.com>

andrija.pa...@gmail.com


:

That sounds like something that was happening on ACS 4.8.

Which version are you running?

Andrija

Re: Creating Windows Server 2019 templates with cloudbase init

[Ismaili, Liridon (SWISS TXT)]

Hi

Thanks for the fast response.
@Lucian: It did work right after installation for me (did setup hostname etc. 
correctly) only this PW stuff is causing issues.
@Simon: I also believe that it's caused by MS Windows. I'll check the policies 
and ask the Cloudbase-init community. If I find something I will post it here.

The template itself is build by packer (and the module from jetbrains-infra 
called packer-builder-vsphere).

Regards
Liridon

-Original Message-
From: simon.voel...@zv.fraunhofer.de<mailto:simon.voel...@zv.fraunhofer.de>
Reply-To: users@cloudstack.apache.org<mailto:users@cloudstack.apache.org>
To: users@cloudstack.apache.org<mailto:users@cloudstack.apache.org>
Subject: Re: Creating Windows Server 2019 templates with cloudbase init
Date: Tue, 14 Jan 2020 13:28:33 +


Hi,


I believe that having to set a new password after it has been reset is supposed 
to be a feature from Microsoft’s side. I’ve also noticed that login through RDP 
is disabled until a new password has been set. So far I haven’t been able to 
get it to work completely. (mainly due to time constraints)


Regards


Simon Völker


Fraunhofer-Gesellschaft e.V.

Schloss Birlinghoven

53754 Sankt Augustin

Telefon: +49 2241 14-2311

E-mail:

<mailto:simon.voel...@zv.fraunhofer.de>

simon.voel...@zv.fraunhofer.de

mailto:simon.voel...@zv.fraunhofer.de>

simon.voel...@zv.fraunhofer.de

>




Am 14.01.2020 um 14:20 schrieb

<mailto:n...@li.nux.ro>

n...@li.nux.ro

mailto:n...@li.nux.ro>

n...@li.nux.ro

>:


Hi,


This could be a bug (or undocumented feature, ahem) with cloudbase-init.

Despite efforts I never got it to work reliably in the past, not sure about now.

Have you tried using CloudInstanceManager.msi for setting the password? It 
still works for me.


What I do is set up the template with a sysprep and unattend.xml where I also 
set a default password (perhaps this is what stops it from asking for new user 
pass), then on first boots CloudInstanceManager sets up the password without 
problems and resets work, too. SG zone btw.


Lucian


On 2020-01-14 12:53, Ismaili, Liridon (SWISS TXT) wrote:

Hi Simon

We are also building some new windows templates and would like to use

cloudbase-init as you do.

I get the same behavior as you did describe (after password reset it

requires to setup a new password). How did you workaround this? I

expect this to be a policy issue but would like to ask before I search

to long as you had the same issue.

Regards

Liridon

-Original Message-

From:

<mailto:simon.voel...@zv.fraunhofer.de>

simon.voel...@zv.fraunhofer.de

mailto:simon.voel...@zv.fraunhofer.de>

simon.voel...@zv.fraunhofer.de

>mailto:simon.voel...@zv.fraunhofer.de>

simon.voel...@zv.fraunhofer.de

>

Reply-To:

<mailto:users@cloudstack.apache.org>

users@cloudstack.apache.org

mailto:users@cloudstack.apache.org>

users@cloudstack.apache.org

>mailto:users@cloudstack.apache.org>

users@cloudstack.apache.org

>

To:

<mailto:users@cloudstack.apache.org>

users@cloudstack.apache.org

mailto:users@cloudstack.apache.org>

users@cloudstack.apache.org

>mailto:users@cloudstack.apache.org>

users@cloudstack.apache.org

>

Subject: Re: Creating Windows Server 2019 templates with cloudbase init

Date: Mon, 09 Sep 2019 07:54:02 +

Hi,

we are using cloudplatform 4.11 which is based on cloudstack 4.10.

Regards

Simon Völker

Fraunhofer-Gesellschaft e.V.

Schloss Birlinghoven

53754 Sankt Augustin

Telefon: +49 2241 14-2311

E-mail:

mailto:simon.voel...@zv.fraunhofer.de>

simon.voel...@zv.fraunhofer.de

>

<mailto:simon.voel...@zv.fraunhofer.de>

simon.voel...@zv.fraunhofer.de

mailto:simon.voel...@zv.fraunhofer.de>

simon.voel...@zv.fraunhofer.de

>

mailto:simon.voel...@zv.fraunhofer.de>

simon.voel...@zv.fraunhofer.de

>

<mailto:simon.voel...@zv.fraunhofer.de>

simon.voel...@zv.fraunhofer.de


Am 06.09.2019 um 15:34 schrieb Andrija Panic <

mailto:andrija.pa...@gmail.com>

andrija.pa...@gmail.com

>

<mailto:andrija.pa...@gmail.com>

andrija.pa...@gmail.com


mailto:andrija.pa...@gmail.com>

andrija.pa...@gmail.com

>

<mailto:andrija.pa...@gmail.com>

andrija.pa...@gmail.com


:

That sounds like something that was happening on ACS 4.8.

Which version are you running?

Andrija

On Fri, 6 Sep 2019 at 14:50, <

mailto:simon.voel...@zv.fraunhofer.de>

simon.voel...@zv.fraunhofer.de

>

<mailto:simon.voel...@zv.fraunhofer.de>

simon.voel...@zv.fraunhofer.de


mailto:simon.voel...@zv.fraunhofer.de>

simon.voel...@zv.fraunhofer.de

>

<mailto:simon.voel...@zv.fraunhofer.de>

simon.voel...@zv.fraunhofer.de


wrote:

Hi,

I’ve checked that and found something peculiar: The password is retrieved

from the VPR if I do a password reset, reboot and reboot again. However,

upon first login with the password generated by the re

Re: Creating Windows Server 2019 templates with cloudbase init

[Ismaili, Liridon (SWISS TXT)]

Hi Simon

We are also building some new windows templates and would like to use 
cloudbase-init as you do.
I get the same behavior as you did describe (after password reset it requires 
to setup a new password). How did you workaround this? I expect this to be a 
policy issue but would like to ask before I search to long as you had the same 
issue.

Regards
Liridon

-Original Message-
From: simon.voel...@zv.fraunhofer.de
Reply-To: users@cloudstack.apache.org
To: users@cloudstack.apache.org
Subject: Re: Creating Windows Server 2019 templates with cloudbase init
Date: Mon, 09 Sep 2019 07:54:02 +


Hi,


we are using cloudplatform 4.11 which is based on cloudstack 4.10.


Regards


Simon Völker


Fraunhofer-Gesellschaft e.V.

Schloss Birlinghoven

53754 Sankt Augustin

Telefon: +49 2241 14-2311

E-mail:



simon.voel...@zv.fraunhofer.de

mailto:simon.voel...@zv.fraunhofer.de>

simon.voel...@zv.fraunhofer.de

>




Am 06.09.2019 um 15:34 schrieb Andrija Panic <



andrija.pa...@gmail.com

mailto:andrija.pa...@gmail.com>

andrija.pa...@gmail.com

>>:


That sounds like something that was happening on ACS 4.8.

Which version are you running?


Andrija


On Fri, 6 Sep 2019 at 14:50, <



simon.voel...@zv.fraunhofer.de

mailto:simon.voel...@zv.fraunhofer.de>

simon.voel...@zv.fraunhofer.de

>> wrote:


Hi,


I’ve checked that and found something peculiar: The password is retrieved

from the VPR if I do a password reset, reboot and reboot again. However,

upon first login with the password generated by the reset, Windows requires

a new password to be set. The password shows up in the passwords file on

the vpr, but isn’t replaced by password=saved, it simply disappears when

retrieved.


Regards


Simon Völker


Fraunhofer-Gesellschaft e.V.

Schloss Birlinghoven

53754 Sankt Augustin

Telefon: +49 2241 14-2311

E-mail:



simon.voel...@zv.fraunhofer.de

mailto:simon.voel...@zv.fraunhofer.de>

simon.voel...@zv.fraunhofer.de

>mailto:simon.voel...@zv.fraunhofer.de>

simon.voel...@zv.fraunhofer.de

mailto:simon.voel...@zv.fraunhofer.de>

simon.voel...@zv.fraunhofer.de

>>




Am 06.09.2019 um 11:23 schrieb Andrija Panic <



andrija.pa...@gmail.com

mailto:andrija.pa...@gmail.com>

andrija.pa...@gmail.com

>

mailto:andrija.pa...@gmail.com>

andrija.pa...@gmail.com

>>:


Hi Simon,


I assume that the cloudbased-init runs BEFORE the user has to set pass via

Windows, thus overwriting the pass that ACS has previously set?

Does rebooting the VM actually sets the new pass (from ACS), that was

generated previously? You can actually check inside the VR

/var/cache/cloud/password- file - this file will contain

the actual pass if it has NOT been fetched by the VM - or if it says

"password=saved" - this means it was already fetched by the VM.


Andrija


On Fri, 6 Sep 2019 at 10:47, <



simon.voel...@zv.fraunhofer.de

mailto:simon.voel...@zv.fraunhofer.de>

simon.voel...@zv.fraunhofer.de

>mailto:simon.voel...@zv.fraunhofer.de>

simon.voel...@zv.fraunhofer.de

mailto:simon.voel...@zv.fraunhofer.de>

simon.voel...@zv.fraunhofer.de

>>> wrote:


Hi,


I am currently doing a new batch of our templates. So far we’ve been using

Cloudbase-init for our Microsoft Server 2016 templates. Now with the 2019

version, instead of setting the password that cloudstack provides, the user

has to set a password on first startup. Does someone have experience with

Cloudbase-init and Windows Server 2019 or has faced the same issue?


Regards


Simon Völker


Fraunhofer-Gesellschaft e.V.

Schloss Birlinghoven

53754 Sankt Augustin

Telefon: +49 2241 14-2311

E-mail:



simon.voel...@zv.fraunhofer.de

mailto:simon.voel...@zv.fraunhofer.de>

simon.voel...@zv.fraunhofer.de

>mailto:simon.voel...@zv.fraunhofer.de>

simon.voel...@zv.fraunhofer.de

mailto:simon.voel...@zv.fraunhofer.de>

simon.voel...@zv.fraunhofer.de

>>mailto:simon.voel...@zv.fraunhofer.de>

simon.voel...@zv.fraunhofer.de

mailto:simon.voel...@zv.fraunhofer.de>

simon.voel...@zv.fraunhofer.de

>mailto:simon.voel...@zv.fraunhofer.de>

simon.voel...@zv.fraunhofer.de

>>






--


Andrija Panić




--


Andrija Panić

Re: [VOTE] Apache CloudStack 4.13.0.0 RC2

[Ismaili, Liridon (SWISS TXT)]

Hi Guys,

+1 from our side

Following upgrade was done:
from 4.11.3 to 4.13 RC2
- VMWare 6.5
- Advanced network setup

Post upgrade steps:
- redeployed systemVMs
- redeployed vRouters

Tests done:
- create / started / stopped / destroyed VMs which were created before and 
after the upgrade
- create / restart / cleanup / redundant vRouters
- upload / delete templates and multi disk templates
- create / delete projects / accounts / users

Regards
Liridon

-Original Message-
From: Paul Angus 
mailto:paul%20angus%20%3cpaul.an...@shapeblue.com%3e>>
Reply-To: users@cloudstack.apache.org
To: d...@cloudstack.apache.org 
mailto:%22...@cloudstack.apache.org%22%20%3c...@cloudstack.apache.org%3e>>,
 users@cloudstack.apache.org 
mailto:%22us...@cloudstack.apache.org%22%20%3cus...@cloudstack.apache.org%3e>>
Subject: [VOTE] Apache CloudStack 4.13.0.0 RC2
Date: Wed, 28 Aug 2019 22:02:32 +


Hi All,


We had an excellently low number of bugs in RC1, so here's RC2 with just 3 
fixes...


I've created a 4.13.0.0 release (RC2), with the following artefacts up for 
testing and a vote:


Git Branch and Commit SH:



https://gitbox.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.13.0.0-RC20190820T1535


Commit: 7c7efe76013675b476d8aa14c36a353cd5d429fc


Source release (checksums and signatures are available at the same location):



https://dist.apache.org/repos/dist/dev/cloudstack/4.13.0.0/



PGP release keys (signed using 51EE0BC8):



https://dist.apache.org/repos/dist/release/cloudstack/KEYS



The vote will be open until 31st August.


For sanity in tallying the vote, can PMC members please be sure to indicate 
"(binding)" with their vote?


[ ] +1 approve

[ ] +0 no opinion

[ ] -1 disapprove (and reason why)


Additional information:


For users' convenience, I've built packages from 
7c7efe76013675b476d8aa14c36a353cd5d429fc and published RC1 repository here:



http://packages.shapeblue.com/testing/41300rc2/



The systemvm templates are unchanged from 4.11.3/4.12.0:



http://download.cloudstack.org/systemvm/4.11/



Fixes in RC2


#3566   server: fix NPE for the case where volume is not attached to a VM

#3567   fix xenserver 7.1.0 os mapping typo

#3571   Unable to deploy VMs via UI in advanced networks with SG and IPv6 cidr







paul.an...@shapeblue.com





www.shapeblue.com


Amadeus House, Floral Street, London  WC2E 9DPUK

@shapeblue

AW: Unable to log in to the cloudstack management page (Web UI)

[Ismaili, Liridon (SWISS TXT)]

Hi Eiji

the JSON inside the body tells the same as the error you posted already. May 
you check the DB if there is something misconfigured with the accounts or roles?
Please run this query and post the results:
select * from cloud.account where id = 2;
and
select * from roles where id in (select role_id from account where id = 2);

As it seems that your user Admin can log in but maybe your account or role is 
inactive or not properly configured. Can you check if you are able to log in 
with another account / user which is not under the admin account?

Regards
Liridon

Von: sagawa_e...@fujitsu.com 
Gesendet: Freitag, 5. Juli 2019 10:31
An: users@cloudstack.apache.org
Cc: shigemoto.ya...@fujitsu.com; t-hoshik...@fujitsu.com
Betreff: RE: Unable to log in to the cloudstack management page (Web UI)

Hi Gregor,

Thank you very much for answering my questions.


> > 192.168.122.1 - - [01/Jul/2019:06:13:10 +0900] "GET
> >
> /client/api?command=listCapabilities&response=json&sessionkey=h1Lwsk
> 9
> > dqVwZxGAwk0owzFDtmi4%3D&_=1561961591972 HTTP/1.1" 432 151
>
> This happens just after login and indicates something is wrong.
> It might not help much, but can you post the JSON body of the response?

  This JSON body was returned.
  ---
  { "errorresponse" : 
{"uuidList":[],"errorcode":432,"cserrorcode":,"errortext":"The given 
command does not exist or it is not available for user"} }
  ---

  Do you know anything from this JSON body?


Best regards,
Eiji Sagawa


> -Original Message-
> From: Riepl, Gregor (SWISS TXT) [mailto:gregor.ri...@swisstxt.ch]
> Sent: Wednesday, July 3, 2019 10:00 PM
> To: users@cloudstack.apache.org
> Cc: Shigemoto, Yasumasa/重元 康昌 ;
> Hoshikawa, Toyohiko/星川 豊彦 
> Subject: Re: Unable to log in to the cloudstack management page (Web UI)
>
> Hi Eiji,
>
> > 192.168.122.1 - - [01/Jul/2019:06:09:22 +0900] "GET
> >
> /client/api?command=listCapabilities&response=json&sessionkey=null&_
> =
> > 1561961364158 HTTP/1.1" 401 101
>
> This happens before login and is ok.
> I see that too when I open the login page without an active session.
>
> > ==> /var/log/cloudstack/management/access_log.2019-07-01.txt
> <==
> > 192.168.122.1 - - [01/Jul/2019:06:13:10 +0900] "POST /client/api
> > HTTP/1.1" 200 321
>
> This is the actual login call, and returns status 200 (success).
>
> > 192.168.122.1 - - [01/Jul/2019:06:13:10 +0900] "GET
> >
> /client/api?command=listCapabilities&response=json&sessionkey=h1Lwsk
> 9
> > dqVwZxGAwk0owzFDtmi4%3D&_=1561961591972 HTTP/1.1" 432 151
>
> This happens just after login and indicates something is wrong.
> It might not help much, but can you post the JSON body of the response?
>
> > 2019-07-01 06:13:10,963 DEBUG [cloud.api.ApiServlet] (catalina-
> > exec-22:null) ===START===  192.168.122.1 -- GET
> > command=listCapabilities&response=json&sessionkey=h1Lwsk9dqVwZxG
> > Awk0owzFDtmi4%3D&_=1561961591972
> > 2019-07-01 06:13:10,976 DEBUG [cloud.api.ApiServer] (catalina-
> > exec-22:null) The given command:listCapabilities does not exist or it
> > is not available for user with id:2
> >
> > ==> /var/log/cloudstack/management/apilog.log <==
> > 2019-07-01 06:13:10,979 INFO  [cloud.api.ApiServer] (catalina-
> > exec-22:null)  192.168.122.1 -- GET
> >
> command=listCapabilities&response=json&sessionkey=h1Lwsk9dqVwZxGAwk0
> o
> > wzFDtmi4%3D&_=1561961591972 432 The given command does not exist or
> it
> > is not available for user
>
> These log messages relate to the failing listCapabilities call after login.
> I think you should focus on these.
>
> Regards,
> Gregor