If you run
euca_conf --get-credentials on eucalyptus 4.2 you will see the following warning:
warning: euca_conf is deprecated; use ``eval `clcadmin-assume-system-credentials`'' or ``euare-useraddkey''`
There are numerous reasons for that command’s deprecation, but what causes confusion is the fact that it has two replacements. Setting up a new cloud now involves more than just one set of credentials, and if you’re used to having fully-functional credentials immediately this is likely to trip you up.
One of the most common complaints about
euca_conf is that it tries to be everything to everybody. It combines multiple types of functionality that need to run in different places, adding excess dependencies and requiring one to log into systems that one normally shouldn’t have to. Eucalyptus 4.2 introduces new administration tools that break
euca_conf’s functionality down into three groups with more specific purposes:
- Whole-cloud administration tools
- Cloud controller (CLC) support scripts
- Cluster controller (CC) support scripts
Cloud controller and cluster controller support scripts can run only on those specific systems, and thus are only installed alongside them. The rest of the administration tools are web service clients, similar to euca2ools, that can run from anywhere. All they need are access keys.
But where do those access keys come from?
Out with the Old
In the old regime, access keys and other credentials come in the form of a zip file containing a bunch of certificates as well as
eucarc, a shell script that sets a bunch of environment variables that include service URLs and the access keys themselves. The first zip file it creates is missing several service URLs because those services have yet to be set up, and it doesn’t use DNS either because that has yet to be set up as well.
Once DNS and all of the services are ready, we then have the cloud generate a new zip file. Everything seems fine until something changes for whatever reason and we need to obtain a third one. Since we can only have two certificates at a time, though, this third zip file will not include one. This causes countless problems for automation that relies on them, including eucalyptus’s own QA scripts.
That said, the zip file still has some particularly useful properties:
- It’s a single file for the administrator to e-mail to new users
- It contains both access keys and service URLs
- It (usually) contains all of the certificates needed to bundle images
euca2ools.ini file also has the first two of those properties, while also managing to be more flexible. Any euca2ools commands that can create access keys, such as euare-useraddkey and euare-usercreate, can generate euca2ools.ini files automatically. That leaves just certificates, which we dealt with by making them all optional or possible to obtain automatically.
In with the New
In isolation, euca2ools commands alone have a chicken-and-egg problem: they require access keys to run, but a new cloud doesn’t have any access keys. We break this loop by splitting eucalyptus installation into two phases, each with different credentials.
A cloud controller support script,
clcadmin-assume-system-credentials, provides temporary setup credentials. This script works similarly to
euare-assumerole, but it is much more limited and it only works on a cloud controller. Setup credentials cannot be used for normal system operation; they provide access only to service registration, service configuration, and IAM services – the minimum necessary to get up and running with euca2ools.
# eval `clcadmin-assume-system-credentials` # euserv-register-service -t user-api -h 198.51.100.2 ufs-1 # euctl system.dns.dnsdomain=mycloud.example.com
Once DNS and an IAM service are set up, you can use euca2ools to create long-lived admin credentials that let you access the cloud’s full functionality. It is these credentials that are the replacements for the zip file. Once you create them, you are unlikely to ever need setup credentials again.
# euare-usercreate -wld mycloud.example.com gholms > ~gholms/.euca/mycloud.ini
Here is an explanation of the various parts of that command:
gholms: Create a user named gholms
-w: Write out a euca2ools.ini file
-l: In that file, make that user the default for this cloud
-d mycloud.example.com: Use the domain
mycloud.example.comas the cloud’s DNS domain
Normally, when this command writes a configuration file it will pull the DNS domain from the IAM service’s URL, but since this is the very first user we have to supply it by hand because it has not yet been set.
If you are interested in using eucalyptus’s administration roles instead of full-blown admin credentials, you would create a new account here and add it to whatever roles you need.
Once you have a set of admin credentials you can use this for day-to-day cloud administration the same way you would with a classic
$ export AWS_DEFAULT_REGION=mycloud.example.com $ euare-accountcreate -wl alice > alice.ini $ mail -s "Try out this shiny, new cloud" -a alice.ini ...
You can change the name of the region in the configuration file if you want. The domain name is simply the default.