sebastien / cuisine Goto Github PK

line 580 of cuisine.py

with mode_sudo(), cd('/etc'):

pukes with invalid syntax on python 2.5. nesting the calls fixes it.

Should we add VCS features to cuisine or is that to high level? I was thinkg about:

• vcs_pull or vcs_get (source,target,revision=None) ==> to pull from source to target directory and update target
• vcs_push or vcs_put (source,target,revision=None) ==> to push from source to target and upate target
• vcs_clone (source,target,revision=None) ==> to clone from source and create target and update target
• vcs_ensure (source,target,revision=None) ==> to ensure that target matches source

and I personally would need it for git, and hg

Does this make sense?

I get this error comes up occasionally when I'm deploying to multiple servers. I can't find the pattern that it is occurring yet.

File "/Library/Python/2.6/site-packages/cuisine.py", line 616, in user_check
assert len(d) >= 7, "/etc/passwd entry is expected to have at least 7 fields, got %s in: %s" % (len(d), d.join(":"))
AttributeError: 'list' object has no attribute 'join'

fabfile.py >

def add_ssh_key(username):
mode_sudo()
user_key = file_local_read('user_keys/%s/ssh_key.pub' % username)
ssh_authorize(username, user_key)

Looks like the latest commit (b0d09d4) reverted the "Make system_uuid_alias_add syntax valid for python2.6" fix from 87e7e81 by svetlyak40wt

Not sure if thats intentional or not.

If the user exists I get the following:

Traceback (most recent call last):
File "/Library/Python/2.6/site-packages/fabric/main.py", line 684, in main
_args, *_kwargs
File "/Library/Python/2.6/site-packages/fabric/tasks.py", line 235, in execute
task.run(_args, *_new_kwargs)
File "/Library/Python/2.6/site-packages/fabric/tasks.py", line 105, in run
return self.wrapped(_args, *_kwargs)
File "/Users/myusername/code/fab_manage/fabfile.py", line 144, in add_user
user_ensure('deploy', passwd='123', shell='/bin/bash')
File "/Library/Python/2.6/site-packages/cuisine.py", line 601, in user_ensure
method, salt = d.get('passwd').split('$')[1:3]

Although there is a API folder with .html in repository, I can't find a place where to watch it conveniently - http://cuisine.readthedocs.org/en/latest/index.html docs are greatly outdated and there are no other references. It is possible to host API page on GitHub - https://help.github.com/categories/20/articles

I am currently using and testing Cuisine on CentOS, and have rewritten package commands to use yum instead. Since I'd like to contribute the code back, I was thinking about implementing both for apt-get and yum via some global config and perhaps package abstraction, but then I realized that package_* defs ARE a form of abstraction. So other than if-elif branches, any suggestions how to support more than one package manager?

package_install allows update=True

There should be a way to pass the update param to package_ensure that forwards update to package_install

ssh_authorize fails for various reasons, when the keyfile does not exist yet, i.e. the first key is provided:

1. if /home/user/.ssh/authorized_keys file does not exist, it can be assumed that the folder /home/user/.ssh/ does not exist as well. if this folder does not exist, file_write(keyf, key) will fail. thus the folder must be created first.
2. file and folder permissions are not handled correctly/ignored :
   /home/user/.ssh/authorized_keys needs to get 600
   /home/user/.ssh/ needs to 700

Hello guys, I am using cuisine in my project using celery. When I run the application in development and starting celery from command line ./manage.py celeryd ..... it works pretty well.
But when I daemonize celery cuisine starts to not work.. the tricky part is popen for commands calling. It seems to me that the popen does not return the output and then my scripts fail.

But the most tricky part is that it works daemonized with ubuntu 10.10, python 2.7, supervisord 3 even with initd script .. When I move the same configuration to my production with ScientificLinux 6.2, python 2.6.6, supervisord 2/3, initd script - i tried everything .. popen returns "" instead of proper output..

I also created ticket at celery cause I assume this is more problem of celery running with Python 2.6.6. But I am putting this here to gather as much of people who could help me find the proper solution as possible :) If it was problem in cuisine I will write patch - definitely.
https://github.com/ask/celery/issues/651

Thanks

I have a general problem while running fabric (and cuisine) as an unprovileged user (fabric user).

While working on the remote host, the mode_sudo (or with mode_sudo when it work... I also have troubles) work, so my user can do anything I want.

The problem comes when you want to do a local action that require to sudo.
None of the options actualy implement this.

For example, I want to sync the /home folders of my users :

userfiles = ['.bashrc', '.bash_profile', '.vimrc', '.ssh/id_rsa.pub']
user = 'foobar'
mode_sudo()
for userfile in userfiles:
file_upload('/home/'+user+'/'+userfile, '/home/'+user+'/'+userfile)

file_upload('/home/'+user+'/'+userfile, '/home/'+user+'/'+userfile)

File "/opt/fabric/.virtualenvs/fabric/lib/python2.6/site-packages/cuisine.py", line 414, in file_upload
f = file(local, 'rb')
IOError: [Errno 13] Permission denied: '/home/foobar/.bashrc'

I'm no python expert and I can't see the right way to do a such thing...
I had a similar problem whil trying to sync the users accounts... I finaly did a shadow = local('sudo cat /etc/shadow', capture = true) which is not really ellegant...

This may be more a feature request than a bug, but still...

The underlying program being executed, add-apt-repository is not idempotent and also, is not available by default, so it should be checked for as well before being executed.

What do you think about splitting cuisine into a bunch of modules for each specific task? for example:

file_read("/foo/bar")  >>>  file.read("/foo/bar")
dir_ensure("/foo")      >>> dir.ensure("/foo")

This crosses out "a single-file API" in the README but make the overall code more maintanable (in my opinion). Alternatively, we can switch to object-based approach and use context managers:

with remote_file("/foo") as f:
    content = f.read()
    # ... do something with content
    f.write(content)
    f.flush()  # is called automatically on __exit__()

Same API can be useful for directories:

with remote_dir("/foo", ensure=True) as d:
   d.attrs("755")

remote_dir("/foo").ensure()

Great work on this saved me doing something similar. I don't have time right now to provide fixes but wanted to give some feedback on bits that didn't work as I expected.

Installing via pip/easy_install installed 0.0.1 rather than 0.0.4 not sure if this matters as it also didn't work when I tried

from cuisine import *

So I just included the cuisine.py file in the same dir as my fabfile.py and that works great.

As the api docs are a bit lacking I started by using the presentation which is great btw. But then I found that there was a oh-my-zsh plugin at https://github.com/santiycr/oh-my-zsh/ which is a fork of the main oh-my-zsh and there is a pull request to bring the fab plugin into the main repo. I just added https://github.com/santiycr/oh-my-zsh/ as another git remote and merged the changes manually. This makes using cuisine really easy as the tab completion on fab command line now lists all the cuisine tasks and they are named well so its pretty easy to work out which one you want for something.

Anyways great job.

in the file_write function, if the following put operations fails
fabric.operations.put(local_path, location, use_sudo=(mode == MODE_SUDO))

the following code to remove temp file
# Remove the local temp file
os.close(fd)
os.unlink(local_path)

will never be executed and the temp file will stay forever.
can the error be catched and ensured that the removal code is executed?

Hi Sebastien

I've noticed you pushed Sphinx-generated docs to the repo, would you consider hosting it at ReadTheDocs instead? I like this approach for two reasons:

1. It's easy to access from the browser -- Github doesn't preview HTML pages, afaik
2. One can allways build a local copy with sphinx-build

What do you think?

I think, if package isn't installed, both should produce the same result:

• package_install_apt('nginx', update=True)
• package_ensure_apt('nginx', update=True)

>>> import cuisine
>>> cuisine.mode_local()
True
>>> cuisine.command_check("ack-grep")
sh: Syntax error: Bad fd number
False

$ echo $SHELL
/bin/bash

cuisine==0.2.4

Python 2.6.5

Ubuntu 10.04.4 LTS

https://github.com/sebastien/cuisine/blob/master/src/cuisine.py#L286

The user data is being parsed as follows:

{'shell': '/home/ubuntu', 'uid': 'x', 'passwd': '!$6$ewuA3/RZ$TQX3d5Rpusb/xIeCJ7SJ9KeNsdfsafafe qzkM.4BkCm5uIWigP.1wFei0mzovOP6lEPZ2eUx/0/', 'gid': '1000', 'home': 'Ubuntu,,,', 'name': 'sudo'}

the user is ubuntu and its home directory is /home/ubuntu

the line from /etc/password is:

ubuntu:x:1000:1000:Ubuntu,,,:/home/ubuntu:/bin/bash

Hi,

The tgz is not present on pypi so easy_install cuisine install 0.0.1

Real problem... :)

Actually, cuisine import the 'crypt' wich is not available on windows.
But crypt does't seems to be used in cuisine.py.

I've removed the import locally and it works.

Commit 3eb43d5 and 96e7300 Introduce code that sets sudo to a string then tries to call it.

MODE_SUDO = "CUISINE_MODE_SUDO"
...
if MODE_SUDO: sudo = MODE_SUDO
    if MODE_LOCAL:
        if sudo:
            sudo('cp "%s" "%s"'%(local,remote))


line 428, in file_upload
sudo('cp "%s" "%s"'%(local,remote))
TypeError: 'str' object is not callable

i have a list of over 5 servers and on one of them i get this error:

[server.url.com] sudo: cat /etc/shadow | egrep '^username:' | awk -F':' '{print $2}'
Traceback (most recent call last):
File "/Library/Python/2.6/site-packages/fabric/main.py", line 684, in main
_args, *_kwargs
File "/Library/Python/2.6/site-packages/fabric/tasks.py", line 235, in execute
task.run(_args, *_new_kwargs)
File "/Library/Python/2.6/site-packages/fabric/tasks.py", line 105, in run
return self.wrapped(_args, *_kwargs)
File "/Users/jmcwilliams/code/fab_manage/fabfile.py", line 148, in add_user
if not user_check(username):
File "/Library/Python/2.6/site-packages/cuisine.py", line 572, in user_check
results = dict(name=d[0], uid=d[2], gid=d[3], home=d[5], shell=d[6])
IndexError: list index out of range

Here is my function

def add_user(username,password):
if not user_check(username):
mode_sudo()
redhat_release = '/etc/redhat-release'
if file_exists(redhat_release):
group = 'wheel'
else:
group = 'sudo'
print('#' *60)
print("Creating user %s" % username)
print('#' *60)
user_create(username, shell='/bin/bash')

    print('#' *60)
    print("Adding %s to sudo group" % username)
    print('#' *60)
    group_user_add(group, username)

    print('#' *60)
    print("Setting password to " + password)
    print('#' *60)
    sudo('echo "{username}:{password}" | chpasswd'.format(username=username, password=password))

    try:
        file_local_read('user_keys/%s/ssh_key.pub' % username)
        key_file = '/home/%s/.ssh/authorized_keys' % username
        user_key = file_local_read('user_keys/%s/ssh_key.pub' % username)
        if not fabric.contrib.files.contains(key_file, user_key):
            dir_ensure('/home/%s/.ssh' % username)
            fabric.contrib.files.append(key_file, user_key, use_sudo=True)
            file_ensure(key_file, mode=600, owner='%s' % username)
    except:
        print("User does not have a public key in user_keys")
else:
    print("User already exists.")

If the env.user of fabric is not root, changing the permission will fail

Once I started using the passwd arguement in user_create, I got a TypeError::

sudo("echo %s | base64 --decode | chpasswd%s" % encoded_password, encryption)
TypeError: not enough arguments for format string

So I changed the line as below and it was running perfectly.

line 666 of cuisine.py::

sudo("echo %s | base64 --decode | chpasswd%s" % encoded_password, encryption)

changed to::

sudo("echo %s | base64 --decode | chpasswd%s" % (encoded_password, encryption))

Can someone please confirm that this is a 'bug'?

All the best, Edvinas

I propose we add functionality similar to http://pypi.python.org/pypi/publickeymanager This would allow one to manage who has access to which servers or even different accounts per server, things like provide/revoke access as needed, all based on peoples public SSH keys. It enables to manage any combination of of users, groups of users and roles from env.roledefs, hosts from env.hosts...

What do you think? Initially I've been thinking of using something like http://web.monkeysphere.info in order to manage access to machines but that requires people to install client-side software and wouldn't be integrated with the fabric/cuisine stack. Something like publickeymanager seems a lot more suitable if integrated with cuisine/fabric.

Hello!

I noticed that user_create is uses useradd command with option -p to set a password for a user, but it should be an encrypted password. From man useradd:

-p, --password PASSWORD
The encrypted password, as returned by crypt(3). The default is to disable the password.

also user_create and user_check uses run, instead of using sudo.
Check the line 259, there is missing % name statement
All of above I fixed in the my fork

Thanks!

Given the following fabfile:

from cuisine import mode_local, run

def always_local():
    with mode_local():
        print run('uname -a')

def local_or_remote():
    print run('uname -a')

It seems that running either of the following commands should not prompt for a host, since everything will be running locally and shouldn't call fabric.api.run at all:

> fab always_local
> fab mode_local local_or_remote

However, both commands prompt for a host and try to execute uname remotely. By slightly changing the code to call cuisine.run in both functions, both tasks can be made to work as expected:

import cuisine
from cuisine import mode_local, run

def always_local():
    with mode_local():
        print cuisine.run('uname -a')  # updated

def local_or_remote():
    print cuisine.run('uname -a')   # updated

The cause of this issue is that, by importing run directly (or indirectly, via from cuisine import *), client code no longer has to refer to the cuisine module and doesn't see the function that gets swapped in by mode_local.

group_check, group_user_check and user_check functions shouldn't access /etc/passwd and /etc/group directly.

Instead they should rely on tools which honor /etc/nsswitch.conf such as getent passwd, getent groups, groups. This way these function will also pick users defined in e.g. LDAP or whatever backends admin configured in /etc/nsswitch.conf.

As far as I know useradd, usermod, groupadd and groupmod function honor /etc/nsswitch.conf if configured properly, so the rest of group_* and user_* functions can be left intact.

Also see #40 for discussion.

tcsh appears to handle escaped chars differently than bash, which results in commands failing with a syntax error.

tcsh --version
tcsh 6.14.00 (Astron) 2005-03-25 (x86_64-unknown-linux) options wide,nls,dl,al,kan,sm,rh,color,filec

e.g.
def test():
file_write('/afile', 'data')

Results in:
[myserver01] Executing task 'test'
[myserver01] run: test -e '/afile' && echo OK ; true
[myserver01] Passphrase for private key:
[myserver01] out: OK

[myserver01] run: sha256sum "/afile" | cut -d" " -f1
[myserver01] out: Unmatched ".

Fatal error: run() received nonzero return code 1 while executing!

Requested: sha256sum "/afile" | cut -d" " -f1
Executed: /bin/bash -l -c "sha256sum "/afile" | cut -d" " -f1"

Aborting.
Disconnecting from myserver01... done.

In using file_update in concert with text_ensure_lines, I find that my remote files are being converted from unix-style \n to windows-style \r\n. I see nothing obviously wrong with the code of any of the involved functions, and yet this is the behavior I'm consistently observing (using emacs to detect the EOL-style).

Of course, you can imagine the havoc this creates when encountered by BASH (and its rather fragile grasp on the reality). :)

This one frankly makes absolutely no sense to me. I hope it makes sense to you.

some_text = "foo"
some_text = text_ensure_line(some_text, "bar")
some_text
'foo\nbar'
some_text = text_ensure_line(some_text, "bar")
some_text
'foo\nbar\nbar'

Am I misusing it? Shouldn't it stop appending "bar" to the end of the text when it finds "bar"?

Maybe this isn't something anybody wants to have automated but I implemented a system upgrade into a def package_upgrade_apt():
sudo("apt-get --yes upgrade")

It works but I'm sure there is a better way. Any ideas? I don't particularly like the idea of putting it in package_update_apt because the word use is horribly confusing.

There are currently 4 mode functions(=mode_local, mode_remote, mode_sudo, mode_user)  and 4 global mode variables (=MODE_USER,MODE_LOCAL, MODE_SUDO, MODE) , 3 cuisine execution functions (run, sudo, run_local) and the 3 native fabric execution functions (run, sudo, local).

Some of these have different APIs, but similar functionality. E.g. model_local and mode_sudo both influence the very basic behaviour of the run function. But mode_sudo uses/implements the "with" API and manipulates a global variable to control the behavior, while mode_local manipulates the module itself.

Some of these just overwrite and wrap the fabric native functions without changing the functionality like sudo, while others change the functionality significantly like run.

One global variable is boolean (mode_local), while others are strings(mode_sudo).

At the moment I do not get my head around it, why these complexities are necessary and why we cannot standardize all that and make it more simple. I am aware that I currently might not fully understand this complete beast and that whatever kind of changes we possibly apply here, this has a major effect.

So let me sketch some preliminary ideas here, to make my thoughts clearer, but also hopefully as a basis for further discussions around this topic:

1. Standardize on exactly 1 execution function
   Implement ONE cuisine run function. This run function checks fabric.api.env for certain variables. Based on the results of fabric.api.env, a certain excecution behavior will be enforced (e.g. run local with sudo, or run remote as current user, etc). And this is the only place where this complete set of behaviors is controlled.
2. Control User/Sudo
   a) 1 boolean env variable env.MODE_SUDO=True|False will determine, if sudo is used in the run function or not.
   b) The current mode_sudo and mode_user classes are used to controll env.MODE_SUDO
3. Controll Local/Remote
   a) 1 boolean env variable env.MODE_LOCAL=True|False will determine, if statements are executed on the local ore remote machine.
   b) 2 new classes mode_local and model_remote including the enter/exit API are used to controll env.MODE_LOCAL
4. I personally would set env.MODE_LOCAL=False and env.MODE_SUDO=False as defaults.

Looking forward to your feedback. I am happy to contribute any code along those lines.
Juergen

$ python setup.py install
/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/distutils/dist.py:266: UserWarning: Unknown distribution option: 'install_requires'
warnings.warn(msg)
running install
running build
running build_py
error: package directory 'cuisine' does not exist

This happened on ubuntu and macos.

In cuisine.py, line 135,

if l == res should be if l == line.

The current check is, of course, never True, so the line is always appended.

The current user_passwd function takes an unencrypted password as an argument. This is unfortunate for users who want to check their provisioning scripts into a repo, as now their password is visible. Wouldn't it be wiser to pass in an encrypted password as an argument, either using the -p option with useradd or the -e option with chpasswd?

Hi,
I am wondering about original point of cuisine. I like this library and I am using it in my project. In my project I need to restart some system daemons (apache,bind,..). It is quite easy with cuisine and commands run/sudo but I am thinking make it more easier with functions daemond_test daemon_stop and so on.. But make it more distribution independent it needs some infrastructure to call proper functions like dispatch does for package. It is quite a lot of work so I am considering whether it is not against direction of cuisine..

Guys do you think is this functionality needed in cuisine? I am going to implement something like this anyways but I am just considering make it more cuisine-like in cuisine :D

But there is just one problem and it is naming of daemons. Also it seems to me stupid have package and distribution descriptor as separate variables..

It seems a nice piece of code but sadly it do not follow very closely common Python style (PEP 8), if needed I can do it, should take 5mn or less.

Rather than doing this:

mode_sudo()
# ... do stuff as superuser...
mode_user()
# ... do normal stuff...

It would instead be nice to do this:

with mode_sudo():
    # ... do stuff as superuser...
# ... do normal stuff...

This is more in line with how Fabric does similar things. It would probably be really easy with contextlib.

Traceback (most recent call last):
  File "/home/vagrant/.virtualenvs/msapi/lib/python2.6/site-packages/fabric/main.py", line 712, in main
    *args, **kwargs
  File "/home/vagrant/.virtualenvs/msapi/lib/python2.6/site-packages/fabric/tasks.py", line 298, in execute
    multiprocessing
  File "/home/vagrant/.virtualenvs/msapi/lib/python2.6/site-packages/fabric/tasks.py", line 197, in _execute
    return task.run(*args, **kwargs)
  File "/home/vagrant/.virtualenvs/msapi/lib/python2.6/site-packages/fabric/tasks.py", line 112, in run
    return self.wrapped(*args, **kwargs)
  File "<string>", line 2, in bootstrap
  File "/vagrant/recipes/test.py", line 37, in timed
    r = func(*args, **kwargs)
  File "/vagrant/recipes/test.py", line 184, in bootstrap
    setup_users_and_groups()
  File "/vagrant/recipes/test.py", line 144, in setup_users_and_groups
    setup_users()
  File "/vagrant/recipes/test.py", line 124, in setup_users
    user_ensure(user)
  File "/home/vagrant/.virtualenvs/msapi/lib/python2.6/site-packages/cuisine.py", line 700, in user_ensure
    d = user_check(name)
  File "/home/vagrant/.virtualenvs/msapi/lib/python2.6/site-packages/cuisine.py", line 688, in user_check
    assert len(d) >= 7, "/etc/passwd entry is expected to have at least 7 fields, got %s in: %s" % (len(d), ":".join(d))
AssertionError: /etc/passwd entry is expected to have at least 7 fields, got 1 in: set +

It seems as though stdout is corrupted, so d is prepended with the string "set", possibly from fabric.operations. _AttributeString. A simple sudo("echo '' > /dev/null") fixes the problem, as well as setting pty=False as in:

d = sudo("cat /etc/passwd | egrep '^%s:' ; true" % (name), pty=False)

This problem manifests when I have anything going on in my wrapper script after I'm calling fab

fab -i $VAGRANT_SHARED_DIR/ssh/id_rsa.pub -f $VAGRANT_SHARED_DIR/recipes/test.py local bootstrap

set +x # This causes the problem, as well as something like echo "Hello" > /dev/null

Can anyone recommend a way to manually install the latest package?

I have this in my fabfile.py:

def locale():
    ## To prevent http://stackoverflow.com/a/2527192 error
    cuisine.file_write("/etc/default/locale", content='''
LC_ALL="en_US.UTF-8"
LANG="en_US.UTF-8"
LANGUAGE="en_US.UTF-8"
        '''.strip(), mode=cuisine.MODE_SUDO)

I ran fab -H blah locale and got this:

[blah] Executing task 'locale'
[blah] run: test -e "/etc/default/locale" && echo OK ; true
[blah] out: OK

[blah] run: sha256sum "/etc/default/locale" | cut -d" " -f1
[blah] out: b4e86a4b1f37b4dc73efc0dbef28656c8ebca5a503c41010c806b9cf997a53b7

[blah] run: sha256sum "/etc/default/locale" | cut -d" " -f1
[blah] out: b4e86a4b1f37b4dc73efc0dbef28656c8ebca5a503c41010c806b9cf997a53b7

[blah] run: chmod  sudo "/etc/default/locale"
[blah] out: chmod: invalid mode: `sudo'
[blah] out: Try `chmod --help' for more information.


Fatal error: run() encountered an error (return code 1) while executing 'chmod  sudo "/etc/default/locale"'
Aborting.
Disconnecting from blah... done.

I'm assuming this has to do with file_write calling file_attribs()? Deleting that line makes it work again.

Hi!
Seems package_ensure(package_name) doesn't work on Ubuntu 10.04:
Code:

from cuisine.cuisine import *
def setup():
    package_ensure('nginx')

Output:

unit@unit:~/PROJECTS/test$ fab -H 10.7.1.5 --user=unit setup
[10.7.1.5] Executing task 'setup'
[10.7.1.5] run: dpkg -s nginx | grep 'Status: install ok installed' ; true
[10.7.1.5] Passphrase for private key: 
[10.7.1.5] Login password: 
[10.7.1.5] out: Package `nginx' is not installed and no info is available.
[10.7.1.5] out: Use dpkg --info (= dpkg-deb --info) to examine archive files,
[10.7.1.5] out: and dpkg --contents (= dpkg-deb --contents) to list their contents.
[10.7.1.5] out: 

Done.
Disconnecting from 10.7.1.5... done.

I'm using Cuisine to deploy an app using both PIP for python packages and NPM for node packages and I'm wondering what your thoughts are on the plan regarding these. Do you write your own methods to ensure these packages in Fabric and use them alongside Cuisine or is this something that should be integrated into Cuisine?

User ensure crashes with the following error message:

TypeError: not all arguments converted during string formatting

The problem comes from line 639 in cuisine.py:
sudo("echo %s | base64 --decode | chpasswd" % (encoded_password,name, passwd))

We have one slot, and 3 candidates.

Source: http://www.python.org/dev/peps/pep-0008/#tabs-or-spaces

Tabs or Spaces?

Never mix tabs and spaces.

The most popular way of indenting Python is with spaces only. The second-most popular way is with tabs only. Code indented with a mixture of tabs and spaces should be converted to using spaces exclusively. When invoking the Python command line interpreter with the -t option, it issues warnings about code that illegally mixes tabs and spaces. When using -tt these warnings become errors. These options are highly recommended!

For new projects, spaces-only are strongly recommended over tabs. Most editors have features that make this easy to do.

the file_write and file_upload method should support big (10M+) files. I had consistent failures with a 47Mb file.

The idea would be to split the file in chunks, and make sure that the chunks are transferred (using bz2 to compress the content, base64 to transfer as string and SHA256 as checksum).

This is true not just for file_update() but others too. They use run() instead of sudo() which of course doesn't allow us to fiddle a file owned by root or another user other than the current one used.

U p d a t e:

ok sorry for the noise... with mode_sudo(): ... closing now :)

I would expect ssh_authorize to be idempotent, but running it repeatedly results in duplicate keys in .ssh/authorized_keys.

I attempted to rewrite it using something like file_update(keyf, lambda _: text_ensure_line(_, key)) but this produces duplicate lines as well.