Keys need to be explicitly generated.
You would use this API call available for ROOT/DOMAIN/USER;


http://cloudstack.apache.org/docs/api/apidocs-4.3/root_admin/registerUserKeys.html

/Ove


On 05/24/2014 01:51 AM, rammohan ganapavarapu wrote:
Also those values are NULL in db, how do i generate them?


select api_key,secret_key from user where username="admin";
+---------+------------+
| api_key | secret_key |
+---------+------------+
| NULL    | NULL       |
+---------+------------+


On Fri, May 23, 2014 at 4:46 PM, rammohan ganapavarapu
<[email protected] <mailto:[email protected]>> wrote:

    Ove,

    Thanks for the quick reply, i have working ACS setup i can login to
    UI and create VMs etc..I also enabled api port to 8096 and my
    management server is listening on that port. But to access
    cloudstack apis do i need api_access_key and api_access_secret? i
    don't see them with admin and any other accounts i have created. I
    am not sure how to get them!!

    Ram


    On Fri, May 23, 2014 at 4:39 PM, Ove Ewerlid <[email protected]
    <mailto:[email protected]>> wrote:

        On 05/24/2014 01:17 AM, rammohan ganapavarapu wrote:

            Hi,

            I am trying to use vagrant to automate my cloudstack virtual
            infrastructure
            but i dont know how to get cloudstack_api_key and secret,
            can some one
            please let me know how to get those?

            Thanks,
            Ram


        A possible way to approach this;

          1) install ACS to the point of a working management head
        (e.g., you can login using webgui.)

          2) use API call authenticated with login/password and the
        default admin credentials setup at first install to generate
        keys and get them

          3) continue using API calls using key based authentication

        CloudMonkey in recent releases was enhanced to support
        login/password based auth.  The Marving test framework in recent
        ACS versions uses an API backend that support login/password
        based auth.

        There is also the integration port with non authenticated API
        calls. This is not enabled by default. A variant is to install
        MGR-head, stop it, modify DB to allow integration port access*,
        start MGR-head and work with the integration port for further
        non authenticated configuration to get authenticated API access
        going.

        /Ove

        * set the global parameter governing which port the integration
        port is on to non NULL.


        --
        Ove Everlid
        System Administrator / Architect / SDN- & Automation- & Linux-hacker
        Mobile: +46706668199 <tel:%2B46706668199> (dedicated work mobile)
        Country: Sweden, timezone; Middle Europan Time (MET or GMT+1)





--
Ove Everlid
System Administrator / Architect / SDN- & Automation- & Linux-hacker
Mobile: +46706668199 (dedicated work mobile)
Country: Sweden, timezone; Middle Europan Time (MET or GMT+1)

Reply via email to