How do you deal with basic images that doesn't have sudo/python

[Fernando Rocha]

Hi,
I have a issue with some images that are so basic, that doesn't have
the basic requirements for provy/fabric to run correctly.

What I have done is a PreSetupRole, which install sudo, python and
setup a non-root user. But i find it ugly, because I need config
settings just for that, run it from cmd, etc

What I would like is something I could use inside another role, like:
with self.using(PreRole) as role:
role.ensure_basic_config()

And then, if we can't login with regular user, try root and run this
role.

What do you think? Is this (login with other user in runtime) possible
without changing provy core?

[Diogo Baeder]

This is an interesting question, and I think it's important we extend this discussion and raise some more clarity on this subject. I'll try to split my answer into different aspects.

Fallback from regular user to root

Linux distributions can be strongly different one to each other; Some distributions can be made available even without being capable of networking - like ArchLinux, which lets yourself take care of installing the very basic packages until setting up a regular user -.

So we have to take some assumptions in order to make it feasible that provy can provision servers without sacrificing usability for users who use it with vanilla distros; In this sense, both Debian, Ubuntu and CentOS require you to add a regular user account at install time, so it makes sense to assume that at least one regular user is available. However, if you still need to run something as root (if a regular user is either not available or is not a sudoer), you can setup your context to "root", and later on change it to the user you want.

From another point of view, I don't like this fallback from regular user to root, because it makes a very important change in behaviour (operating the environment as root instead of regular user) implicit, instead of explicit. This is really bad, as it can present our users with pretty unpleasant surprises (like creating a file which should be accessible by a certain user, but which ends up being accessible only by root).

Sudo and Python

Following the assumptions of being dealing with vanilla distributions, sudo and Python should be already installed with them, as they're part of the default linux programs (I didn't find the official list yet, but can post it here as soon as I find it). So if you don't have them installed, nothing stops you from doing so with the tools provided by provy - like you've been doing so far -. For example, a similar issue would be if we were provisioning a Debian server without APT being available - it wouldn't make sense to download the source and install it, since it's part of the basic distribution packages -.

But this is just my opinion. I'd like to see others, though.

Cheers,

__________________________
Diogo Baeder
http://diogobaeder.com.br

--
You received this message because you are subscribed to the Google Groups "provy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to provy+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Fernando]

On 13 February 2013 00:59, Diogo Baeder <diogo...@gmail.com> wrote:

This is an interesting question, and I think it's important we extend this discussion and raise some more clarity on this subject. I'll try to split my answer into different aspects.

Fallback from regular user to root

Linux distributions can be strongly different one to each other; Some distributions can be made available even without being capable of networking - like ArchLinux, which lets yourself take care of installing the very basic packages until setting up a regular user -.

So we have to take some assumptions in order to make it feasible that provy can provision servers without sacrificing usability for users who use it with vanilla distros; In this sense, both Debian, Ubuntu and CentOS require you to add a regular user account at install time, so it makes sense to assume that at least one regular user is available. However, if you still need to run something as root (if a regular user is either not available or is not a sudoer), you can setup your context to "root", and later on change it to the user you want.

Interesting, I had not thought about doing the inverse, seems nice, althouth, I haven't tested, but it will still fail, right?, because I usually disable root login thought ssh, so it would fail in the first login try.
 

From another point of view, I don't like this fallback from regular user to root, because it makes a very important change in behaviour (operating the environment as root instead of regular user) implicit, instead of explicit. This is really bad, as it can present our users with pretty unpleasant surprises (like creating a file which should be accessible by a certain user, but which ends up being accessible only by root).

I do agree, maybe a config in options dict? I don't know if there are other use cases, but it could be nice to have some power to customize login behavior, or even others aspects of provy runner. Maybe the possibility of changing runner function.
 

Sudo and Python

Following the assumptions of being dealing with vanilla distributions, sudo and Python should be already installed with them, as they're part of the default linux programs (I didn't find the official list yet, but can post it here as soon as I find it). So if you don't have them installed, nothing stops you from doing so with the tools provided by provy - like you've been doing so far -. For example, a similar issue would be if we were provisioning a Debian server without APT being available - it wouldn't make sense to download the source and install it, since it's part of the basic distribution packages -.

Yes, I think not having sudo/python weird, but it happens, as I remember I used some centos and debian images that way from amazon (community ami). I think some image I used from vagrant also had not sudo or python.

Also, in amazon amis, is common to have debian and centos amis with only root user.

But this is just my opinion. I'd like to see others, though.

Thanks!

--
http://about.me/fernandogrd

[Diogo Baeder]

Hi,

__________________________
Diogo Baeder
http://diogobaeder.com.br

On Wed, Feb 13, 2013 at 9:56 AM, Fernando <ferna...@gmail.com> wrote:

Interesting, I had not thought about doing the inverse, seems nice, althouth, I haven't tested, but it will still fail, right?, because I usually disable root login thought ssh, so it would fail in the first login try.

Well, you need to have at least one way of gaining root access through SSH, otherwise it doesn't make sense to try to provision stuff to that machine remotely. It's up to you, though, if you want to access through root or through a sudoer user.

    

I do agree, maybe a config in options dict? I don't know if there are other use cases, but it could be nice to have some power to customize login behavior, or even others aspects of provy runner. Maybe the possibility of changing runner function.

If we implement the ability to customize the login behaviour, it will still have a deep impact on how the whole provisioning works as a whole, and would invite other bugs to come in. So, my opinion is that this special case isn't special enough to justify its implementation in the project itself, as I don't see other cases for it to be a core feature.

On the other hand, we could implement something like changing the context user inside a "with" block, to avoid having to pass the user as argument in too many places. If you think this is would be enough to help you, please fill an issue in GitHub so that we can implement it. (Or go on if you want to do this yourself and send a pull request.)

 

   

Yes, I think not having sudo/python weird, but it happens, as I remember I used some centos and debian images that way from amazon (community ami). I think some image I used from vagrant also had not sudo or python.

Also, in amazon amis, is common to have debian and centos amis with only root user.

Even if they don't have a regular user, the root one should be remotely accessible. So with it you can create a user and use it further in your provyfile.

Not having Python installed is a distro problem, as it should contain all official basic Linux programs. I'd rather not getting into the situation where we have to inspect each server for basic environment conditions and try to bring them to a usable state. On the other hand, you can still install Python with your distro role, if the package manager is not implemented with Python itself.

[Fernando]

On 13 February 2013 13:07, Diogo Baeder <diogo...@gmail.com> wrote:

Hi,

__________________________
Diogo Baeder
http://diogobaeder.com.br

On Wed, Feb 13, 2013 at 9:56 AM, Fernando <ferna...@gmail.com> wrote:

Interesting, I had not thought about doing the inverse, seems nice, althouth, I haven't tested, but it will still fail, right?, because I usually disable root login thought ssh, so it would fail in the first login try.

Well, you need to have at least one way of gaining root access through SSH, otherwise it doesn't make sense to try to provision stuff to that machine remotely. It's up to you, though, if you want to access through root or through a sudoer user.

I mean, the second time running provy script, the idea is disable root ssh login after creating a new user

    

I do agree, maybe a config in options dict? I don't know if there are other use cases, but it could be nice to have some power to customize login behavior, or even others aspects of provy runner. Maybe the possibility of changing runner function.

If we implement the ability to customize the login behaviour, it will still have a deep impact on how the whole provisioning works as a whole, and would invite other bugs to come in. So, my opinion is that this special case isn't special enough to justify its implementation in the project itself, as I don't see other cases for it to be a core feature.

On the other hand, we could implement something like changing the context user inside a "with" block, to avoid having to pass the user as argument in too many places. If you think this is would be enough to help you, please fill an issue in GitHub so that we can implement it. (Or go on if you want to do this yourself and send a pull request.)

 

   

Yes, I think not having sudo/python weird, but it happens, as I remember I used some centos and debian images that way from amazon (community ami). I think some image I used from vagrant also had not sudo or python.

Also, in amazon amis, is common to have debian and centos amis with only root user.

Even if they don't have a regular user, the root one should be remotely accessible. So with it you can create a user and use it further in your provyfile.

Not having Python installed is a distro problem, as it should contain all official basic Linux programs. I'd rather not getting into the situation where we have to inspect each server for basic environment conditions and try to bring them to a usable state. On the other hand, you can still install Python with your distro role, if the package manager is not implemented with Python itself.

--

You received this message because you are subscribed to the Google Groups "provy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to provy+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
http://about.me/fernandogrd

[Diogo Baeder]

Hi,

__________________________
Diogo Baeder
http://diogobaeder.com.br

On Thu, Feb 14, 2013 at 8:57 AM, Fernando <ferna...@gmail.com> wrote:

I mean, the second time running provy script, the idea is disable root ssh login after creating a new user

Ah, now I got it. Well, I'd suggest you to disable root login as the last step of provisioning, then - this way you can provision the server normally, but still keep it safer when the provyfile finishes provisioning -.

Cheers,

Diogo

[Bernardo Heynemann]

I don't think that'll work. Later when you need to change the provision script and run it again, it won't be able to connect to the server.

What I'd say is that this isn't inherently a provy issue. What I would do if I required everything to be provisioned through a script is have two scripts: bootstrap and provision.

Bootstrap script would create the user, assign an ssh key to him and add that key to allow access. Then it would disable remote access from anyone not in possesion of said key.

Provision script would use the same key to connect to said server through SSH. Then it would provision the rest of the server's resources.

Does that make sense?

Cheers,

Bernardo Heynemann
Developer @ globo.com

[Diogo Baeder]

Yeah, indeed, you're right; If he locks root out in the end of the provision script, it will break provy's idempotency. So your approach makes sense to me, yes.

Cheers!

__________________________
Diogo Baeder
http://diogobaeder.com.br