How to have apt-get update'd in the ubuntu_1204 container?

[jaypipes]

Hi Chris,

We're trying to work around the following problem that has been an annoyance. When initially provisioning a container with our runlist, we run into this error:

https://github.com/retr0h/cookbook-lldpd/issues/1

If I immediately ssh into the vagabond container, run apt-get update, and then log out again, I can vagabond provision the node again and it works fine...

Now, Dewey had said that the issue is that the base container's apt cache is either non-existent or very old, and that I should be able to get rid of this pesky annoyance by lxc-start'ing the ubuntu_1204 container, running apt-get update, and then lxc-stop'ing the container.

Only issue is, when I try to lxc-start the ubuntu_1204 container, I cannot login. The default ubuntu/ubuntu login/pass does not work, nor does my local jpipes user.

Any ideas? Is the ubuntu_1204 container special in this regard? Or is there some other solution to the issue you might know of?

Best, -jay

[alff]

I confirm this issue. At this moment I'm using workaround with 'apt-get update' in compile time. But I believe that we can update apt db when template is built.

[chrisroberts]

Hey guys. So, my first take on this is that if the recipe is using apt and needs an up-to-date database to properly converge (basically if it's installing any packages) then it should be part of the recipe itself. One easy way to do this is to add the default recipe from the apt cookbook in the container's run list.

Now, on the other side of this I get why you may not want to add dependencies in and you may have certain assumptions you are allowed to make about the new node you are receiving to bootstrap on, etc. ,etc.. Happily, I have just gotten some things around this working the develop branch.

{
  :nodes => {
    ...
  },
  :callbacks => {
    :create => [
      "vagabond ssh ${NAME} apt-get update"
    ]
  }
}

That will get fired off after the create action completes. If you are spinning up the nodes using up, it will call create, then provision which means you will get the create callbacks run between, and should get the behavior you're looking for. And for reference, the ${NAME} in that command will be replaced when the command is run with the node name in question.

[chrisroberts]

Oh, and @jaypipes, to the point of connecting to the base containers. The lxc cookbook will scrub out the default passwords on the containers. It uses a key for connecting, so you can do:

$ ssh root@$CONTAINER_IP -i /opt/hw-lxc-config/id_rsa

[jaypipes]

"One easy way to do this is to add the default recipe from the apt cookbook in the container's run list."

Yeah, recipe[apt] is in the node's runlist, right at the top, under recipe[ohai]... which is why we were wondering why that doesn't seem to make any difference...

[jaypipes]

Unfortunately, the SSH'ing to the container keeps asking for a password...

jpipes@uberbox:~/repos/att-cloud/chef-repo$ sudo lxc-ls --fancy
NAME               STATE    IPV4       IPV6  AUTOSTART  
------------------------------------------------------
server-RBdzI54wuD  STOPPED  -          -     NO         
server-w6hhp31YsB  STOPPED  -          -     NO         
ubuntu_1204        RUNNING  10.0.3.35  -     NO         
jpipes@uberbox:~/repos/att-cloud/chef-repo$ ssh root@10.0.3.35 -i /opt/hw-lxc-config/id_rsa
The authenticity of host '10.0.3.35 (10.0.3.35)' can't be established.
ECDSA key fingerprint is 86:3c:93:e2:7e:7f:a7:29:2c:33:33:b0:1e:09:14:ab.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.0.3.35' (ECDSA) to the list of known hosts.
root@10.0.3.35's password: 
Permission denied, please try again.

[chrisroberts]

Try throwing a sudo in front

[jaypipes]

LOL, that was fast... and worked :) thx again.

[chrisroberts]

Well, that's interesting about apt. It's not a compile time install or anything so I'm curious what's going on there. Do you see the apt-get update being executed on provision?

[jaypipes]

No, it doesn't... it's really odd. In any case, apt-get update'ing in the base container, lxc-stop'ing it, and re-provisioning from a brand new container is working great now.