In case somebody wants to do other testing, I applied the patch to
cloud-init and made this AMI public:
ami-ab4698c2
On Sat, Mar 31, 2012 at 9:44 AM, Andy Grimm <agrimm@xxxxxxxxx> wrote:
> SOLVED!
>
> From /usr/share/doc/cloud-init-0.6.3/ChangeLog :
>
> "read /etc/ssh/sshd_config for AuthorizedKeysFile rather than assuming
> ~/.ssh/authorized_keys (LP: #731849)"
>
> The problem is that this change in cloud-init does not properly handle
> relative paths, which are documented in the sshd_config manpage as
> being relative to the user's home directory. So the quick fix was to
> change /etc/ssh/sshd_config from:
>
> AuthorizedKeysFile .ssh/authorized_keys
>
> to:
>
> AuthorizedKeysFile %h/.ssh/authorized_keys
>
> The more correct fix is in cloud-init, probably something like:
>
> --- a/cloudinit/SshUtil.py 2012-03-31 09:28:42.598996936 -0400
> +++ b/cloudinit/SshUtil.py 2012-03-31 09:40:47.758829938 -0400
> @@ -155,6 +155,8 @@
> akeys = ssh_cfg.get("AuthorizedKeysFile", "%h/.ssh/authorized_keys")
> akeys = akeys.replace("%h", pwent.pw_dir)
> akeys = akeys.replace("%u", user)
> + if not akeys.startswith('/'):
> + akeys = os.path.join(pwent.pw_dir, akeys)
> authorized_keys = akeys
> except Exception:
> authorized_keys = '%s/.ssh/authorized_keys' % pwent.pw_dir
>
>
> How do you want to handle this? Should I go ahead and file both RHBZ
> and LP issues for it?
>
> --Andy
>
> On Fri, Mar 30, 2012 at 7:39 PM, Andy Grimm <agrimm@xxxxxxxxx> wrote:
>> Further attempting to localize the problem, I found a pickled form of
>> the metadata in /var/lib/cloud/instances/i-325d4c56/obj.pkl which
>> included the public ssh key, so it's definitely getting the data from
>> the metadata service.
>>
>> On Fri, Mar 30, 2012 at 5:45 PM, Andy Grimm <agrimm@xxxxxxxxx> wrote:
>>> On Fri, Mar 30, 2012 at 5:35 PM, Tim Flink <tflink@xxxxxxxxxx> wrote:
>>>> On Fri, 30 Mar 2012 16:54:47 -0400
>>>> Andy Grimm <agrimm@xxxxxxxxx> wrote:
>>>>
>>>>> Of those differences, I suspect that lack of a zeroconf route
>>>>> (169.254.0.0/16) is probably preventing access to the metadata
>>>>> service. Further, I believe the reason is related to the addition of
>>>>> NetworkManager in the F17 AMI (because the zeroconf route is typically
>>>>> added via the ifcfg-eth script, which NM does not run). Before I go
>>>>> hacking further, is there a particular reason that we switched to
>>>>> using NetworkManager in the F17 AMI?
>>>>
>>>> NM was added to core as a fix for a F17 bug where the network wouldn't
>>>> come up by default in a minimal install:
>>>> - https://bugzilla.redhat.com/show_bug.cgi?id=693602
>>>>
>>>> The decision was made to add NM to core because it doesn't add many
>>>> extra packages and as NM adds more and more features, it doesn't make
>>>> much sense to keep hacking the old network service in for minimal
>>>> installs. The full details of "why" are in the bug, if you're
>>>> interested.
>>>
>>> Ok, I've been on the CC list for that bug for a long time, but I
>>> missed that they actually made a decision. I'll just bite my tongue
>>> on that one; at least it's not completely broken anymore.
>>>
>>>> maxamillion did a good job of summing up some of the you can do about
>>>> removing/replacing NM for a regular system in his blog post:
>>>> http://pseudogen.blogspot.com/2012/03/networkmanager-is-in-core-but-dont-fret.html
>>>
>>> Thanks for that link!
>>>
>>>>> Would removing it be the wrong solution, and if so, is there a quick
>>>>> way to ensure that NM initializes a zeroconf route?
>>>>
>>>> That is certainly possible, the network service still works. It just
>>>> made more sense to use NM for non-cloud minimal installs.
>>>>
>>>> I'll leave the discussion of the best way to deal with NM/network to
>>>> people who are far more qualified than I am. Just figured I would add
>>>> in the answer to "why did this change?"
>>>
>>> As it turns out, I just booted an Ubuntu Oneiric instance, and it does
>>> not have a zeroconf route, but is still able to access the metadata
>>> service, so it looks like this was a red herring. Back to the drawing
>>> board.
>>>
>>> --Andy
>>>
>>>> Tim
>>>>
>>>> _______________________________________________
>>>> cloud mailing list
>>>> cloud@xxxxxxxxxxxxxxxxxxxxxxx
>>>> https://admin.fedoraproject.org/mailman/listinfo/cloud
>>>>
_______________________________________________
cloud mailing list
cloud@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/cloud
