Re: [Fab-user] question about sudo executed

[Jeff Forcier]

Hi Robert,

Yea, right now, *neither* execution mode is going to give you that
granular control, unfortunately. They're both oriented towards a "run
these directives on all servers" workflow.

I'm more than halfway done with a massive rewrite of Fabric which, if
it works out, should make it a lot easier to leverage as a library.
While I may not have your needed level of atomicity available when it
first comes out, it's definitely something on my radar.

Best,
Jeff


On Tue, Apr 7, 2009 at 1:17 PM, Robert Ramírez Vique
<address@hidden> wrote:
> sorry, I sent the mail just to Christian...
>
> ---------- response email ------
>
> hello,
>
> sorry, I don't understand exactly your solution. With fab_mode = 'deep',
> what is exactly the difference ?
>
> If I got you right what you propose is to execute first everything for one
> server and then for the other one, but my problem is that I have to control
> exactly what is happening, I mean, I have to deploy the first server, once
> is deployed this one, switch the loadbalancer to this and deploy the second
> one. So, I think I cannot use this mode in this case, don't you think ?
>
> regards,
>       Robert Ramírez Vique
>       Computer Science Engineer
> Emo Philips  - "A computer once beat me at chess, but it was no match for me
> at kick boxing."
>
> On Tue, Apr 7, 2009 at 19:16, Robert Ramírez Vique <address@hidden>
> wrote:
>>
>> hello,
>>
>> sorry, I don't understand exactly your solution. With fab_mode = 'deep',
>> what is exactly the difference ?
>>
>> If I got you right what you propose is to execute first everything for one
>> server and then for the other one, but my problem is that I have to control
>> exactly what is happening, I mean, I have to deploy the first server, once
>> is deployed this one, switch the loadbalancer to this and deploy the second
>> one. So, I think I cannot use this mode in this case, don't you think ?
>>
>> regards,
>>       Robert Ramírez Vique
>>       Computer Science Engineer
>> George Burns  - "I spent a year in that town, one Sunday."
>>
>> On Tue, Apr 7, 2009 at 19:01, Christian Vest Hansen <address@hidden>
>> wrote:
>>>
>>> What if you set config.fab_mode = 'deep' - is that closer to home?
>>>
>>> rowe:~$ fab twice
>>> Fabric v. 0.1.1.
>>> Running twice...
>>> Logging into the following hosts as vest:
>>>    localhost
>>>    127.0.0.1
>>> Password for address@hidden:
>>> [localhost] run: uptime
>>> [localhost] out: 18:59  up 6 days, 23:20, 4 users, load averages: 0.32
>>> 0.23 0.25
>>> [127.0.0.1] run: uptime
>>> [127.0.0.1] out: 18:59  up 6 days, 23:20, 4 users, load averages: 0.32
>>> 0.23 0.25
>>> [localhost] run: uptime
>>> [localhost] out: 18:59  up 6 days, 23:20, 4 users, load averages: 0.32
>>> 0.23 0.25
>>> [127.0.0.1] run: uptime
>>> [127.0.0.1] out: 18:59  up 6 days, 23:20, 4 users, load averages: 0.32
>>> 0.23 0.25
>>> Done.
>>> rowe:~$ fab let:fab_mode=deep twice
>>> Fabric v. 0.1.1.
>>> Running let...
>>> Running twice...
>>> Logging into the following hosts as vest:
>>>    localhost
>>>    127.0.0.1
>>> Password for address@hidden:
>>> [localhost] run: uptime
>>> [localhost] out: 19:00  up 6 days, 23:20, 4 users, load averages: 0.34
>>> 0.24 0.25
>>> [localhost] run: uptime
>>> [localhost] out: 19:00  up 6 days, 23:20, 4 users, load averages: 0.34
>>> 0.24 0.25
>>> [127.0.0.1] run: uptime
>>> [127.0.0.1] out: 19:00  up 6 days, 23:20, 4 users, load averages: 0.34
>>> 0.24 0.25
>>> [127.0.0.1] run: uptime
>>> [127.0.0.1] out: 19:00  up 6 days, 23:20, 4 users, load averages: 0.34
>>> 0.24 0.25
>>> Done.
>>> rowe:~$
>>>
>>>
>>> On Tue, Apr 7, 2009 at 6:44 PM, Robert Ramírez Vique
>>> <address@hidden> wrote:
>>> > hello !
>>> >
>>> > yes, you are right, but my problem is that I have to use invoke.
>>> >
>>> > The reason is that I don't know any other way to deploy first on one
>>> > server
>>> > and then on another server, during the same fabric execution. I have to
>>> > change the fab_hosts to execute commands on different servers, and the
>>> > only
>>> > way to do it is by this:
>>> >
>>> >     use_as(0) # change to the correct host
>>> >     invoke(deploy_as) # deploys on the server
>>> >
>>> >     use_as(1) # change to the correct host
>>> >     invoke(deploy_as) # deploys on the server
>>> >
>>> > In the future I will have 0,1,2,... until 'n' servers, but right now
>>> > are
>>> > just 2.
>>> >
>>> > probably there is a better solution, but noone has worked for me :(
>>> >
>>> > thanks in advanced,
>>> >       Robert Ramírez Vique
>>> >       Computer Science Engineer
>>> > Fred Allen  - "Washington is no place for a good actor. The competition
>>> > from
>>> > bad actors is too great."
>>> >
>>> > On Tue, Apr 7, 2009 at 18:37, Christian Vest Hansen
>>> > <address@hidden>
>>> > wrote:
>>> >>
>>> >> Yes:
>>> >>
>>> >> def once():
>>> >>    run('uptime')
>>> >>
>>> >> def twice():
>>> >>    once()
>>> >>    once()
>>> >>
>>> >> The skip_executed part only affects commands called through invoke().
>>> >>
>>> >> def once_invoke():
>>> >>    "same as calling once() once"
>>> >>    invoke(once)
>>> >>    invoke(once)
>>> >>
>>> >> As demonstrated:
>>> >>
>>> >> rowe:~$ fab once once
>>> >> Fabric v. 0.1.1.
>>> >> Running once...
>>> >> Logging into the following hosts as vest:
>>> >>    localhost
>>> >> Password for address@hidden:
>>> >> [localhost] run: uptime
>>> >> [localhost] out: 18:35  up 6 days, 22:55, 4 users, load averages: 0.61
>>> >> 0.33 0.22
>>> >> Running once...
>>> >> Logging into the following hosts as vest:
>>> >>    localhost
>>> >> Password for address@hidden:
>>> >> [localhost] run: uptime
>>> >> [localhost] out: 18:35  up 6 days, 22:55, 4 users, load averages: 0.64
>>> >> 0.34 0.23
>>> >> Done.
>>> >> rowe:~$ fab twice
>>> >> Fabric v. 0.1.1.
>>> >> Running twice...
>>> >> Logging into the following hosts as vest:
>>> >>    localhost
>>> >> Password for address@hidden:
>>> >> [localhost] run: uptime
>>> >> [localhost] out: 18:35  up 6 days, 22:56, 4 users, load averages: 0.61
>>> >> 0.35 0.23
>>> >> [localhost] run: uptime
>>> >> [localhost] out: 18:35  up 6 days, 22:56, 4 users, load averages: 0.61
>>> >> 0.35 0.23
>>> >> Done.
>>> >> rowe:~$ fab once_invoke
>>> >> Fabric v. 0.1.1.
>>> >> Running once_invoke...
>>> >> Chaining once...
>>> >> Logging into the following hosts as vest:
>>> >>    localhost
>>> >> Password for address@hidden:
>>> >> [localhost] run: uptime
>>> >> Skipping once (already invoked).
>>> >> Done.
>>> >> rowe:~$
>>> >>
>>> >> On Tue, Apr 7, 2009 at 6:00 PM, Robert Ramírez Vique
>>> >> <address@hidden> wrote:
>>> >> > hi,
>>> >> >
>>> >> > is there any way to execute again a command which is already
>>> >> > executed ?
>>> >> > I
>>> >> > saw the parameter skip_executed=True , but don't know how to set it.
>>> >> >
>>> >> > regards,
>>> >> >       Robert Ramírez Vique
>>> >> >       Computer Science Engineer
>>> >> > Emo Philips  - "A computer once beat me at chess, but it was no
>>> >> > match
>>> >> > for me
>>> >> > at kick boxing."
>>> >> >
>>> >> > On Fri, Apr 3, 2009 at 10:00, Robert Ramírez Vique
>>> >> > <address@hidden> wrote:
>>> >> >>
>>> >> >> thanks Christian, for the really fast response and solution, this
>>> >> >> works
>>> >> >> perfectly
>>> >> >>
>>> >> >>       Robert Ramírez Vique
>>> >> >>       Computer Science Engineer
>>> >> >> Samuel Goldwyn  - "I don't think anyone should write their
>>> >> >> autobiography
>>> >> >> until after they're dead."
>>> >> >>
>>> >> >> On Thu, Apr 2, 2009 at 22:16, Christian Vest Hansen
>>> >> >> <address@hidden>
>>> >> >> wrote:
>>> >> >>>
>>> >> >>> As you have learned, sudo() actually constructs a sudo command
>>> >> >>> that
>>> >> >>> calls bash (or whatever fab_shell is) which then calls your real
>>> >> >>> command.
>>> >> >>>
>>> >> >>> The reason for this round-about way of sudo'ing can be illustrated
>>> >> >>> thus:
>>> >> >>>
>>> >> >>> $ sudo echo poke && whoami
>>> >> >>> poke
>>> >> >>> vest
>>> >> >>> $ sudo bash -c "echo poke && whoami"
>>> >> >>> poke
>>> >> >>> root
>>> >> >>>
>>> >> >>> So we introduce a limitation to what can be expressed in a command
>>> >> >>> by
>>> >> >>> not going through a shell.
>>> >> >>>
>>> >> >>> But, I have pushed a change that will allow you to avoid the shell
>>> >> >>> for
>>> >> >>> a single sudo command by setting a noshell keyword argument to
>>> >> >>> True:
>>> >> >>>
>>> >> >>> sudo('uptime', noshell=True)
>>> >> >>>
>>> >> >>> Or, you can turn the shell off for all subsequent calls to sudo by
>>> >> >>> setting the fab_sudo_noshell variable on config to True:
>>> >> >>>
>>> >> >>> config.fab_sudo_noshell=True
>>> >> >>> sudo('uptime')
>>> >> >>>
>>> >> >>> But of these approaches are subject to the limitation described
>>> >> >>> above,
>>> >> >>> but you can try them out if you fetch the code from the git
>>> >> >>> repositories. In fact, please do and tell me if you encounter any
>>> >> >>> other problems.
>>> >> >>>
>>> >> >>> 2009/4/2 Robert Ramírez Vique <address@hidden>:
>>> >> >>> > Hello,
>>> >> >>> >
>>> >> >>> > I am trying to execute a sudo command on one server, my problem
>>> >> >>> > is
>>> >> >>> > that
>>> >> >>> > in
>>> >> >>> > the remote server I got this error:
>>> >> >>> >
>>> >> >>> > [bronx] sudo: sudo -S -p 'sudo password:'  /bin/bash -l -c
>>> >> >>> > "uptime"
>>> >> >>> > [bronx] err: Sorry, user devel is not allowed to execute
>>> >> >>> > '/bin/bash
>>> >> >>> > -l
>>> >> >>> > -c
>>> >> >>> > uptime' as root on bronx.
>>> >> >>> > Error: The sudo operation failed on bronx.
>>> >> >>> >
>>> >> >>> > here is the code of my fabfil:
>>> >> >>> >
>>> >> >>> > def test():
>>> >> >>> >     sudo('uptime')
>>> >> >>> >
>>> >> >>> > The problem probably is something I've something badly
>>> >> >>> > configured
>>> >> >>> > because
>>> >> >>> > the system is trying to execute "/bin/bash -l -c uptime", and I
>>> >> >>> > have
>>> >> >>> > to
>>> >> >>> > give
>>> >> >>> > sudo access (in the sudoers file) to the user devel on this
>>> >> >>> > command,
>>> >> >>> > to
>>> >> >>> > every command I want to execute, including things like
>>> >> >>> > "/bin/bash -l
>>> >> >>> > -c
>>> >> >>> > /etc/init.d/nginx start", "/bin/bash -l -c /etc/init.d/nginx
>>> >> >>> > stop",
>>> >> >>> > "/bin/bash -l -c /etc/init.d/nginx reload" ... The other option
>>> >> >>> > is
>>> >> >>> > to
>>> >> >>> > give
>>> >> >>> > access to /bin/bash, but this is clearly not the correct
>>> >> >>> > solution,
>>> >> >>> > due
>>> >> >>> > security issues.
>>> >> >>> >
>>> >> >>> > I tried to changing the fab_shell to nothing (''), but then the
>>> >> >>> > run
>>> >> >>> > methods
>>> >> >>> > don't work. Don't know any other option
>>> >> >>> >
>>> >> >>> > I am using the last Fabric 0.1.0 installed with easy_install, on
>>> >> >>> > an
>>> >> >>> > ubuntu
>>> >> >>> > 8.04
>>> >> >>> >
>>> >> >>> > Do you have any idea? any configuration I am missing ?
>>> >> >>> >
>>> >> >>> > cheers,
>>> >> >>> >
>>> >> >>> >       Robert Ramírez Vique
>>> >> >>> >
>>> >> >>> >       Computer Science Engineer
>>> >> >>> > Bob Hope  - "You know you are getting old when the candles cost
>>> >> >>> > more
>>> >> >>> > than
>>> >> >>> > the cake."
>>> >> >>> > _______________________________________________
>>> >> >>> > Fab-user mailing list
>>> >> >>> > address@hidden
>>> >> >>> > http://lists.nongnu.org/mailman/listinfo/fab-user
>>> >> >>> >
>>> >> >>> >
>>> >> >>>
>>> >> >>>
>>> >> >>>
>>> >> >>> --
>>> >> >>> Venlig hilsen / Kind regards,
>>> >> >>> Christian Vest Hansen.
>>> >> >>
>>> >> >
>>> >> >
>>> >> > _______________________________________________
>>> >> > Fab-user mailing list
>>> >> > address@hidden
>>> >> > http://lists.nongnu.org/mailman/listinfo/fab-user
>>> >> >
>>> >> >
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Venlig hilsen / Kind regards,
>>> >> Christian Vest Hansen.
>>> >
>>> >
>>>
>>>
>>>
>>> --
>>> Venlig hilsen / Kind regards,
>>> Christian Vest Hansen.
>>
>
>
> _______________________________________________
> Fab-user mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/fab-user
>
>