Fedora 19 Test Candidate 6 cloud images are now available from:
https://dl.fedoraproject.org/pub/alt/stage/19-TC6/Images/
in either qcow2 or raw.xz form. You should be able to use Glance in OpenStack to just import the qcow2 images directly and go.
They're also in Amazon EC2 in the US East region;
ami-93c3b2fa for x86_64 ami-17c2b37e for i386
Thanks to Dennis Gilmore in Fedora Release Engineering for the extra work to make this happen.
The images are configured with "fedora" as the default user with sudo. You can change this behavior by passing different configuration data via the user-data in either OpenStack or EC2. For example, to allow direct root login and to suppress the creation of the 'fedora' user, use
#cloud-config users: disable_root: 0
(The first line is identifying the userdata type, not a comment.)
On 06/20/2013 04:44 PM, Matthew Miller wrote:
Fedora 19 Test Candidate 6 cloud images are now available from:
https://dl.fedoraproject.org/pub/alt/stage/19-TC6/Images/
in either qcow2 or raw.xz form. You should be able to use Glance in OpenStack to just import the qcow2 images directly and go.
basic stuff seems to be doing fine, nice work
anything in particular we may want to test around cloud-init ?
The images are configured with "fedora" as the default user with sudo. You can change this behavior by passing different configuration data via the user-data in either OpenStack or EC2. For example, to allow direct root login and to suppress the creation of the 'fedora' user, use
#cloud-config users: disable_root: 0
also, by injecting the ssh key I was able to login as root
what is the default fedora user password btw?
On Thu, Jun 20, 2013 at 05:59:03PM +0200, Giulio Fidente wrote:
in either qcow2 or raw.xz form. You should be able to use Glance in OpenStack to just import the qcow2 images directly and go.
basic stuff seems to be doing fine, nice work
Thanks.
anything in particular we may want to test around cloud-init ?
We need to start building up things to test. I've tested various cloud-config options and a really simple #! script.
what is the default fedora user password btw?
There isn't one -- the account is created with a locked password, so you can log in via key only.
On 06/20/2013 07:21 PM, Matthew Miller wrote:
On Thu, Jun 20, 2013 at 05:59:03PM +0200, Giulio Fidente wrote:
what is the default fedora user password btw?
There isn't one -- the account is created with a locked password, so you can log in via key only.
yeah so I was expecting that but key injection works for root not for fedora
how am I supposed to pass the public key for the fedora user?
On Fri, Jun 21, 2013 at 12:24:40AM +0200, Giulio Fidente wrote:
On Thu, Jun 20, 2013 at 05:59:03PM +0200, Giulio Fidente wrote:
what is the default fedora user password btw?
There isn't one -- the account is created with a locked password, so you can log in via key only.
yeah so I was expecting that but key injection works for root not for fedora how am I supposed to pass the public key for the fedora user?
Cloud-init should take care of it. Is it not? What environment?
On Fri, Jun 21, 2013 at 1:25 AM, Matthew Miller mattdm@fedoraproject.org wrote:
On Fri, Jun 21, 2013 at 12:24:40AM +0200, Giulio Fidente wrote:
On Thu, Jun 20, 2013 at 05:59:03PM +0200, Giulio Fidente wrote:
what is the default fedora user password btw?
There isn't one -- the account is created with a locked password, so you can log in via key only.
yeah so I was expecting that but key injection works for root not for fedora how am I supposed to pass the public key for the fedora user?
Cloud-init should take care of it. Is it not? What environment?
Works for me in OpenStack. Good job Matt! Just one question, can you explain the rational behind the console crazyness?
serial=tty0 console=ttyS0,115200n8 console=hvc0 console=tty1
For OpenStack, I'd like to see something like the following so that I get console messages on the serial port which can be retrieved via a Nova call. Helps with identifying boot issues in the absence of a 'real' virtual console.
console=tty1 console=ttyS0
Thanks ...Juerg
-- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mattdm@fedoraproject.org _______________________________________________ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud
On 06/21/2013 12:25 PM, Juerg Haefliger wrote:
On Fri, Jun 21, 2013 at 1:25 AM, Matthew Miller mattdm@fedoraproject.org wrote:
On Fri, Jun 21, 2013 at 12:24:40AM +0200, Giulio Fidente wrote:
On Thu, Jun 20, 2013 at 05:59:03PM +0200, Giulio Fidente wrote:
what is the default fedora user password btw?
There isn't one -- the account is created with a locked password, so you can log in via key only.
yeah so I was expecting that but key injection works for root not for fedora how am I supposed to pass the public key for the fedora user?
Cloud-init should take care of it. Is it not? What environment?
Works for me in OpenStack. Good job Matt! Just one question, can you explain the rational behind the console crazyness?
serial=tty0 console=ttyS0,115200n8 console=hvc0 console=tty1
For OpenStack, I'd like to see something like the following so that I get console messages on the serial port which can be retrieved via a Nova call. Helps with identifying boot issues in the absence of a 'real' virtual console.
console=tty1 console=ttyS0
Indeed. This was discussed previously on this list. See the thread
"Logging boot/networking info to serial console for fedora cloud images"
I wonder if there's an already existing bugzilla for it.
On Fri, Jun 21, 2013 at 8:55 AM, Juerg Haefliger juergh@gmail.com wrote:
On Fri, Jun 21, 2013 at 1:25 AM, Matthew Miller mattdm@fedoraproject.org wrote:
On Fri, Jun 21, 2013 at 12:24:40AM +0200, Giulio Fidente wrote:
On Thu, Jun 20, 2013 at 05:59:03PM +0200, Giulio Fidente wrote:
what is the default fedora user password btw?
There isn't one -- the account is created with a locked password, so
you can
log in via key only.
yeah so I was expecting that but key injection works for root not for
fedora
how am I supposed to pass the public key for the fedora user?
Cloud-init should take care of it. Is it not? What environment?
Works for me in OpenStack. Good job Matt!
Same here, works just fine and as expected in my OpenStack environment. Thanks to everyone who helped with this effort!
The only issue is that updates-testing is active, but that's a well known (release blocking) bug for F19 in general.
On Fri, Jun 21, 2013 at 08:55:50AM +0200, Juerg Haefliger wrote:
Works for me in OpenStack. Good job Matt! Just one question, can you explain the rational behind the console crazyness?
serial=tty0 console=ttyS0,115200n8 console=hvc0 console=tty1
For OpenStack, I'd like to see something like the following so that I get console messages on the serial port which can be retrieved via a Nova call. Helps with identifying boot issues in the absence of a 'real' virtual console.
console=tty1 console=ttyS0
Does the crazy line above _not_ work for you in OpenStack? It does for me.
I posted about this a few days ago, but to recap, the simple line causes cloud-init (which wants to write directly to the console) to freak out in EC2, where ttyS0 isn't a device. Putting the hvc0 console line first causes it to _not_ freak out, and in my quick testing console output still worked in OpenStack too.
The alternative is to write different things to menu.lst for pvgrub and extlinux.conf for KVM (or other HVM) use. But that seemed a little too "magical".
On Fri, Jun 21, 2013 at 3:12 PM, Matthew Miller mattdm@fedoraproject.orgwrote:
On Fri, Jun 21, 2013 at 08:55:50AM +0200, Juerg Haefliger wrote:
Works for me in OpenStack. Good job Matt! Just one question, can you explain the rational behind the console crazyness?
serial=tty0 console=ttyS0,115200n8 console=hvc0 console=tty1
For OpenStack, I'd like to see something like the following so that I get console messages on the serial port which can be retrieved via a Nova call. Helps with identifying boot issues in the absence of a 'real' virtual console.
console=tty1 console=ttyS0
Does the crazy line above _not_ work for you in OpenStack? It does for me.
Looks good for me, except a few things (all systemd? or at least cloud-init and some more) only go to tty1 but not ttyS0 (i.e. console log). Not sure why, though. -- Sandro
On Fri, Jun 21, 2013 at 3:12 PM, Matthew Miller mattdm@fedoraproject.org wrote:
On Fri, Jun 21, 2013 at 08:55:50AM +0200, Juerg Haefliger wrote:
Works for me in OpenStack. Good job Matt! Just one question, can you explain the rational behind the console crazyness?
serial=tty0 console=ttyS0,115200n8 console=hvc0 console=tty1
For OpenStack, I'd like to see something like the following so that I get console messages on the serial port which can be retrieved via a Nova call. Helps with identifying boot issues in the absence of a 'real' virtual console.
console=tty1 console=ttyS0
Does the crazy line above _not_ work for you in OpenStack? It does for me.
Only partially. In only get the kernel messages in the console log but none of the other console messages, i.e., init script outputs.
...Juerg
I posted about this a few days ago, but to recap, the simple line causes cloud-init (which wants to write directly to the console) to freak out in EC2, where ttyS0 isn't a device. Putting the hvc0 console line first causes it to _not_ freak out, and in my quick testing console output still worked in OpenStack too.
The alternative is to write different things to menu.lst for pvgrub and extlinux.conf for KVM (or other HVM) use. But that seemed a little too "magical".
-- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mattdm@fedoraproject.org _______________________________________________ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud
On Fri, Jun 21, 2013 at 04:11:33PM +0200, Juerg Haefliger wrote:
Does the crazy line above _not_ work for you in OpenStack? It does for me.
Only partially. In only get the kernel messages in the console log but none of the other console messages, i.e., init script outputs.
Which explains why cloud-init stops breaking. :)
Any suggestions for a clean, general fix?
On Fri, Jun 21, 2013 at 10:14:34AM -0400, Matthew Miller wrote:
Does the crazy line above _not_ work for you in OpenStack? It does for me.
Only partially. In only get the kernel messages in the console log but none of the other console messages, i.e., init script outputs.
Which explains why cloud-init stops breaking. :) Any suggestions for a clean, general fix?
Maybe the fix is to stop cloud-init from writing to the console directly at all (which is ugly anyway), and configure systemd to forward all log info to the console?
On 06/21/2013 01:25 AM, Matthew Miller wrote:
On Fri, Jun 21, 2013 at 12:24:40AM +0200, Giulio Fidente wrote:
On Thu, Jun 20, 2013 at 05:59:03PM +0200, Giulio Fidente wrote:
what is the default fedora user password btw?
There isn't one -- the account is created with a locked password, so you can log in via key only.
yeah so I was expecting that but key injection works for root not for fedora how am I supposed to pass the public key for the fedora user?
Cloud-init should take care of it. Is it not? What environment?
indeed that is working as expected, when passing userdata
the openstack injection facility I referred to appends data into the authorized_keys file by loopmounting the image before it starts, it's not something achieved via cloud-init
I see that the fedora account has a the password locked anyway so there is nothing to worry about if one is taking the route of key injection
On Fri, Jun 21, 2013 at 01:33:11PM +0200, Giulio Fidente wrote:
Cloud-init should take care of it. Is it not? What environment?
indeed that is working as expected, when passing userdata
Cloud-init is also set to default to getting the key from the metadata service even if you haven't provided a specific userdata script. I've tested this in Fedora's internal OpenStack environment and it works for me.
the openstack injection facility I referred to appends data into the authorized_keys file by loopmounting the image before it starts, it's not something achieved via cloud-init
Right, that facility is hard-coded for root.
I see that the fedora account has a the password locked anyway so there is nothing to worry about if one is taking the route of key injection
*nod*
On 06/21/2013 01:53 PM, Matthew Miller wrote:
On Fri, Jun 21, 2013 at 01:33:11PM +0200, Giulio Fidente wrote:
Cloud-init should take care of it. Is it not? What environment?
indeed that is working as expected, when passing userdata
Cloud-init is also set to default to getting the key from the metadata service even if you haven't provided a specific userdata script. I've tested this in Fedora's internal OpenStack environment and it works for me.
yeah again sorry for the bad wording
when I said "passing userdata" I meant via the metadata-api service
are there other options to pass the userdata ?
On Fri, Jun 21, 2013 at 02:00:13PM +0200, Giulio Fidente wrote:
yeah again sorry for the bad wording when I said "passing userdata" I meant via the metadata-api service are there other options to pass the userdata ?
There are, actually. Here's the upstream docs: https://cloudinit.readthedocs.org/en/latest/topics/datasources.html. For example, there is RHEVm data source that puts the data on a fake floppy drive.
cloud@lists.stg.fedoraproject.org
-
Giulio Fidente -
Juerg Haefliger -
Kashyap Chamarthy -
Matthew Miller -
Sandro "red" Mathys