Feature: get() with sudo #700

Closed
jaraco opened this Issue Aug 3, 2012 · 25 comments

Projects

None yet
@jaraco
Contributor
jaraco commented Aug 3, 2012

It seems api.get() doesn't accept the use_sudo parameter like most other operations. It probably should. Not all files are world-readable.

@bitprophet
Member

This would require an inverse version of what's done now to support sudo-capable puts, aka roughly sudo cp /real/file/path /tmp/temp_file_name + SFTP get() call to that temp file name + sudo rm /tmp/temp_file_name.

I agree that it would be nice to have, though given I can't find any prior requests for it it's clearly not a huge deal for most users, so I doubt it'll float to the top of my personal list anytime soon.

However a well rounded pull request (meaning: follows the put implementation closely re: temp file names and handling edge cases; includes documentation + changelog updates; etc) might get merged :)

@nkeilar
nkeilar commented Jun 2, 2013

+1

@rhfung
rhfung commented Jun 18, 2013

+1

@dwagon
dwagon commented Jun 19, 2013

+1 but "sudo cat" would probably be a workaround

@hannes-ucsc

+1

@isegal
isegal commented Sep 18, 2013

+1
this is very useful for system administration i.e. when you want to pull one of the /etc config file from multiple systems.

@nkeilar
nkeilar commented Sep 18, 2013

my work around was to copy said file to /tmp then download it

On 18 September 2013 10:39, Ivgeni Segal notifications@github.com wrote:

+1
this is very useful for system administration i.e. when you want to pull
one of the /etc config file from multiple systems.


Reply to this email directly or view it on GitHubhttps://github.com/fabric/fabric/issues/700#issuecomment-24684126
.

Nathan Keilar
Hunted Hive Web Studio ~ Innovative Solutions For Real World Problems
Technical Director and Business Manager

EMAIL: nathank@huntedhive.com
PHONE: +61 (0) 7 3040 3065 (AUS)
SKYPE/TWITTER: HuntedHive / https://twitter.com/HuntedHive
FACEBOOK: https://www.facebook.com/HuntedHive
LINKEDIN: http://au.linkedin.com/in/nathankeilar
WEB: http://huntedhive.com

This email (including any attachments) is confidential and may be
privileged. If you have received it in error, please notify the sender by
return email and delete this message from your system. Any unauthorised use
or dissemination of this message in whole or in part is strictly
prohibited. Please note that emails are susceptible to change and we will
not be liable for the improper or incomplete transmission of the
information contained in this communication nor for any delay in its
receipt or damage to your system. We do not guarantee that the integrity of
this communication has been maintained nor that this communication is free
of viruses, interceptions or interference.

@isegal
isegal commented Sep 18, 2013

I just use fab -u root -i rootKey.pem for now, essentially operating as root. A bit risky but it works for now.

@dwagon
dwagon commented Sep 19, 2013

I know there are workarounds; I use them currently. However it is still a feature that would make everyone's life easier in the future and also gives feature symmetry: everything you can do with a put() you should be able to do with a get()

@baconalot

+1
Please uniform all these operations. Maybe even drop the "sudo()" operation and let "run()" eat "as_sudo". This would make the api for these functions much more pythonesk and easy to use.
Now my code is cluttered with stuff like:

def foo(payload, as_sudo):
if as_sudo:
return sudo(payload)
else:
return run(payload)

@tshepang

@baconalot +1 on the consistency argument

@jberkus
jberkus commented Oct 29, 2013

I'm looking at adding a sudo user/group argument to put(), just FYI.

@vain vain referenced this issue in bundlewrap/bundlewrap Nov 3, 2013
Closed

operations.download() doesn't have all privileges #39

@MilOo
MilOo commented Dec 12, 2013

+1

@willejs
willejs commented Jan 8, 2014

+1

@wengole
wengole commented Feb 4, 2014

+1

@marcesher

+1

@tonnydourado

+1

@adamcharnock

+1

@russellvt

Definitely +1 ... should be done for consistency, alone. And, it would be nice to not have to work around it (which then becomes a "set and forget").

@brimo
brimo commented May 5, 2014

+1

@bnikolaus

+1

@bitprophet bitprophet closed this in 305f2a6 Sep 4, 2014
@srimandarbha

+1

@bitprophet
Member

Why are people still plussing this when #1121 is merged and released? 😢 @srimandarbha ;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment