9:44 a.m.
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.)
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
10:59 a.m.
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?
--
Giulio Fidente
IRC: giulivo
12:21 p.m.
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.
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
5:24 p.m.
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?
--
Giulio Fidente
IRC: giulivo
6:25 p.m.
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?
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
1:55 a.m.
On Fri, Jun 21, 2013 at 1:25 AM, Matthew Miller
<mattdm(a)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(a)fedoraproject.org>
_______________________________________________
cloud mailing list
cloud(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
2:11 a.m.
On 06/21/2013 12:25 PM, Juerg Haefliger wrote:
On Fri, Jun 21, 2013 at 1:25 AM, Matthew Miller
<mattdm(a)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.
--
/kashyap
2:25 a.m.
On Fri, Jun 21, 2013 at 8:55 AM, Juerg Haefliger <juergh(a)gmail.com> wrote:
On Fri, Jun 21, 2013 at 1:25 AM, Matthew Miller
<mattdm(a)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.
8:12 a.m.
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".
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
8:40 a.m.
On Fri, Jun 21, 2013 at 3:12 PM, Matthew Miller <mattdm(a)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.
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
9:11 a.m.
On Fri, Jun 21, 2013 at 3:12 PM, Matthew Miller
<mattdm(a)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(a)fedoraproject.org>
_______________________________________________
cloud mailing list
cloud(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
9:14 a.m.
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?
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
9:21 a.m.
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?
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
6:33 a.m.
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
--
Giulio Fidente
IRC: giulivo
6:53 a.m.
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*
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
7 a.m.
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 ?
--
Giulio Fidente
IRC: giulivo
8:14 a.m.
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.
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
3955
days inactive
3956
days old
16 comments
5 participants
participants (5)
-
Giulio Fidente -
Juerg Haefliger -
Kashyap Chamarthy -
Matthew Miller -
Sandro "red" Mathys