I'm pleased to announce release 0.10.0 of Oz. Oz is a program for
doing automated installation of guest operating systems with limited input
from the user. Release 0.10.0 is a bugfix and feature release for Oz.
Some of the highlights between Oz 0.9.0 and 0.10.0 are:
* Support for installing OpenSUSE 12.1 and 12.2
* Support for python3
* Support for Ubuntu 12.04.1, 12.04.2, and 12.10
* Fix up <command> ordering so that commands are run in the order they
are specified in the XML
* Updates and fixes to the documentation
* Increase the shutdown timeout to support slower qemu guests
* Add a default screenshot directory as /var/lib/oz/screenshots
* Support for RHEL 5.9
* Support for Fedora 18
* Switch over to pycurl for header information; this allows http
authentication to work
* Switch to using the libvirt built-in screenshot mechanism. This
removes the gvnc dependency and makes screenshots more reliable, but
requires libvirt 0.9.7 or newer
* Delete auto-generated ssh keys after customization
A tarball of this release is available, as well as packages for Fedora-17.
Instructions on how to get and use Oz are available at
If you have questions or comments about Oz, please feel free to contact me
at clalancette(a)gmail.com, or open up an issue on the github page:
Thanks to everyone who contributed to this release through bug reports,
patches, and suggestions for improvement.
Okay, so, with all of the individual parts going through review, what
exactly is needed to enable growing the root partition on F18 (or upcoming
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
I've just made a new install with the latest version of the < RedHat getting started guide with Openstack Folsom > Revision 1.0-2.
I'm using CentOS 6.3 for this install.
After installing Openstack-keystone, I'm unable to perform "keystone user-list" and "keystone token-get". I have sourced the keystonerc_username file but the system says "Expecting an endpoint provided via either --endpoint or env[SERVICE_ENDPOINT]". When I'm explicitly given the endpoint in the command line, the output is "Configuration error: Client configured to run without a service catalog. Run the client using --os-auth-url or OS_AUTH_URL, instead of --os-endpoint or OS_SERVICE_ENDPOINT, for example."
But the OS_AUTH_URL is configured in my keystonerc_username file so I don't understand why the system asks for it.
I can then all the installation steps without problems, but after I given my credentials in the dashboard login page (admin/secret or username/secret), I got "Internal Server Error".
Is that linked with the first problem from Keystone?
I'm searching for more information in logs but currently I found no answer to my questions.
Thanks for help,
cloud-utils can be pushed to stable but it has 0 karma. What's the
process? Should I wait until dracut-modules-growroot is in testing and
then ask people to test the two (since they kind of belong together)
hoping for some karma or should I go ahead and push cloud-utils
already (and how would I do that)?
It looks like the access model for MySQL has changed between F17 and F18.
I tried the recent fedora-updates-testing version of Keystone on F18.
Here's what I found:
Running Packstack with minimal services enabled seems to fail. I need a
sterilized machine to determine what exactly failed, but I was looking
to install just Keystone, so I moved on to doing a manual install.
1. OpenSSL not installed means the pki setup is broken. That needs to
be an RPM dependency. Filed a bug for that:
Once that is in , run as root
And change perms on the directory so Keystone can read it.
So far so good.
2. openstack-db fails with a permission on the root user. However, the
A. su - keystone (I suspect the openstack-db call made the
keystone user, or maybe that is done by the RPM install?)
B. mysql (no params, using the default identification, which I
assume is PAM based?)
C. create user named keystone:
create user 'keystone'@'localhost' identified by 'keystone';
grant that user perms to create a db
grant all PRIVILEGES on *.* to 'keystone'@'localhost';
exit mysql and log in as that user:
mysql --user=keystone --password=keystone
Create the keystone database:
create database keystone;
Log out and run the dbsync
Obviously, this leaves the DB User with too many permissions, but it is
If I now try to run the command
openstack-db --service glance --init
Please enter the password for the 'root' MySQL user:
Even setting the password in MySQL doesn;t work
UPDATE mysql.user SET Password=PASSWORD('keystone') WHERE User='root'
[root@f18-keystone mysql]# openstack-db --service glance --init
Please enter the password for the 'root' MySQL user:
ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using
Failed to connect to the MySQL server. Please check your root user
I tried it with the unix password as well.
Note that I can connect using the following SQL Alchemy URL:
I think this is preferable to exposing TCP sockets around in the case
that the Keystone server and MySQL server are co-located.
Figure I'd send around an update regarding tdl-tools . I have some
content to demo at our next sprint recap, and plan to make a short
screencast which I will format into a blog post w/ some content:
As you may recall, tdl-tools is a set of tools to make building,
testing, and deploying tdls (as used by imagefactory/oz) quick and easy.
All in all the current tools are comprised of:
- tdl-create: create a new tdl/etdl from scratch, includes an
- tdl-verify: verify the accuracy of your tdl on the command line
- tdl-convert: convert an tdl/etdl and vice versa
- tdl-launch: start a new instance w/ deltacloud and process the tdl on
it, great for quickly testing tdl's
- tdl-apply : simple command to proxy tdl's between cloud instance and
image services, specify tdl via cmd line w/ flag indicating whether to
use tdl-launch/deltacloud or imagefactory to handle the tdl.
- tdl-config: creates a new config file in the user's home dir
containing cloud credentials (which the user will be prompted for) to be
used by tdl-apply to pass onto deltacloud/imagefactory
I also would like to incorporate a '--server' flag in tdl-apply to
provide a simple sinatra based web-service which to also serve this
proxy over http.
These commands are all currently available via the 'tdl' gem on
rubygems.org , simply 'gem install tdl' and invoke them on the