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@gmail.com 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@gmail.com 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@gmail.com wrote:
On Fri, Mar 30, 2012 at 5:35 PM, Tim Flink tflink@redhat.com wrote:
On Fri, 30 Mar 2012 16:54:47 -0400 Andy Grimm agrimm@gmail.com 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-fre...
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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud