cloudstack-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "sagawa_eiji@fujitsu.com" <sagawa_e...@fujitsu.com>
Subject RE: Unable to log in to the cloudstack management page (Web UI)
Date Tue, 06 Aug 2019 00:55:52 GMT
Hi Gregor,

I am sorry for my late response regarding the email that you sent me last time.

I checked commands.properties but it doesn't seem to be a problem.
I can't upgrade my cloudstack immediately.
If I upgrade cloudstack in the future, I will use your advice.

Best regards,
Eiji Sagawa


> -----Original Message-----
> From: Riepl, Gregor (SWISS TXT) [mailto:Gregor.Riepl@swisstxt.ch]
> Sent: Thursday, July 25, 2019 9:59 PM
> To: users@cloudstack.apache.org; Sagawa, Eiji/佐川 英司
> <sagawa_eiji@fujitsu.com>
> Cc: Shigemoto, Yasumasa/重元 康昌 <shigemoto.yasum@fujitsu.com>;
> Hoshikawa, Toyohiko/星川 豊彦 <t-hoshikawa@fujitsu.com>
> Subject: Re: Unable to log in to the cloudstack management page (Web UI)
> 
> Hi Eiji,
> 
> I did some more digging.
> The default commands.properties in 4.2.1 is generated from this
> template:
> https://github.com/apache/cloudstack/blob/4.2/client/tomcatconf/comm
> ands.properties.in
> 
> You should check the .rpm/.deb or other package you had used to install
> CloudStack for the generated file, or build it yourself with
> https://github.com/apache/cloudstack/blob/4.2/client/pom.xml
> 
> In CloudStack 4.9, commands.properties was deprecated.
> To retain the previous roles, there is a migration script, documented
> here:
> http://docs.cloudstack.apache.org/en/4.11.1.0/adminguide/accounts.ht
> ml
> and here:
> https://www.shapeblue.com/dynamic-roles-in-cloudstack/
> more fun facts:
> http://events17.linuxfoundation.org/sites/events/files/slides/CCCNA1
> 7%20CS%20Dynamic%20Roles%20in%20Cloudstack.pdf
> 
> Hope this helps!
> 
> Regards,
> Gregor
> 
> On Wed, 2019-07-17 at 11:48 +0000, Riepl, Gregor (SWISS TXT) wrote:
> > Hi Eiji,
> >
> > >   mysql> select * from cloud.account where id = 2;
> > >
> +----+--------------+--------------------------------------+----
> > >
> --+-----------+---------+---------+----------------+--------------
> > > --+-----------------+---------+
> > >   | id | account_name | uuid                                 | type
> > > |
> > > domain_id | state   | removed | cleanup_needed | network_domain |
> > > default_zone_id | default |
> > >
> +----+--------------+--------------------------------------+----
> > >
> --+-----------+---------+---------+----------------+--------------
> > > --+-----------------+---------+
> > >   |  2 | admin        | 483d0fcf-da63-11e3-8ea9-24be05a86042 |    1
> > > >         1 | enabled | NULL    |              0 |
> > > NULL           |            NULL |       1 |
> > >
> +----+--------------+--------------------------------------+----
> > >
> --+-----------+---------+---------+----------------+--------------
> > > --+-----------------+---------+
> > >   1 row in set (0.00 sec)
> > >
> > >
> > > "type", "state" and "removed" seem to be good.
> > > Should I check records in other tables?
> >
> > Hmm... This looks good to me.
> >
> > Checking further... Do you have a commands.properties that has the
> > correct mappings from role to API calls?
> >
> > This is the only other place I can find that could be relevant -
> > according to:
> >
> https://github.com/apache/cloudstack/blob/4.2/plugins/acl/static-rol
> e-
> >
> based/src/org/apache/cloudstack/acl/StaticRoleBasedAPIAccessChecker.
> ja
> > va
> >
> > Regards,
> > Gregor
Mime
View raw message