there are lots of blank tests in test_execute, write them.

Operations such as checkouts or backups may require significant disk space and running out of disk space during operation would be problematic.

We need to be able to check available disk space somehow before executing certain operations.

Seems that the group provider is not actually creating groups

we've not written one yet.

A switch to yaybu to take the configuration file as input and to spit out, in yaml, the entire expanded configuration.

This is a useful pre-execution check, and a nice way of testing macro expansion during recipe authoring.

Files and users and groups sometimes seem to do stuff but do not produce output.

DEBIAN_FRONTEND=noninteractive environment variable

When package sources change we want to be able to upgrade all packages we depend on.

Every run of a command like this, will do this:

/-------------------------- Execute[reconfigure-exim] --------------------------
| /usr/sbin/dpkg-reconfigure -f noninteractive exim4-config

How do we not do that every time?

We support templates, but they arent enough for files which we might not want to diff or are binary.

encrypted: foo

will find foo on the yaybu path and decrypt it by running:

gpg -d

A special resource /log to which POSTs can be sent as:

/log/FACILITY/SEVERITY

The body of the POST should be formatted as UTF-8 encoded text, and the Content-Type: header should be of type text/plain; charset=UTF-8

Currently if 2 apache configs change and need an apache restart its treated as an error condition...

There are a bunch of tests for files, finish them.

In yaybu.core.argument.File this should represent a stream and not a string, to provide complete flexibility in file handling.

Particularly so we can return a random valid file.

This is made more challenging because the file needs access to the run context. Globals may not work because they limit testability.

• Implement group and groups properties on User object
• Add a remove provider (don't remove home dir)

Using the preexec_fn argument to Popen, use setuid and seteuid to drop privileges in the core shell implementation, instead of calling sudo.

Yay gives us ints and unicode. Review interaction with yaybu.

We need to define whether providers get called with unicode or UTF-8 strings, so the providers can do the right thing.

Policies are enabled, disabled, reconfig and restart

Write tests.

This needs to add some stuff to the test environment when it's run:

• a passwordless gpg key
• a running gpg-agent that has had this key added to it
• a file encrypted with the specified key

this has not been implemented yet.

For some reason some files that we write are showing as different due to having/not-having trailing newlines.

This is also showing as different in the diffs.

Review the use of templating.

For example:

/------------------------------ Link[£££££] ------------------------------
| ln -s / £££££
\-------------------------------------------------------------------------------

Execute should touch the file specified in its 'creates' attribute after execution.

Invoked like this:

yaybu

So two args = remote, one arg = local

Will refuse to invoke when run as root with only one argument.

The user will need to be able to invoke yaybu-remote using sudo. The invocation on the remote side will need to use a trampoline like:

yaybu-remote --trampoline

This inspects the environment and take ssh agent details to pass as parameters:

sudo yaybu-remote --ssh-auth-sock /tmp/foo/bar

The process then has root privileges and a secure channel to the local process.

A switch to yaybu which requests approval before running each command, allowing the user to step through application and verify correctness at each step.

We need to support the following methods:

GET
POST

For a url of the format python://foo.bar/baz we will request:

GET /baz

The server will respond with 200, 404 or 401 or other codes as appropriate. The response headers will be exactly as for HTTP.

POST similarly will work exactly as per HTTP spec.

So we can run a configuration without it starting every site, for example.

Must have the following resource attributes:
name - username
fullname
uid
gid
groups - list of string group names
homedir. Default is /home/$name.
password - in an hashed form
type: 'user' or 'system'. '-r' option on useradd. Warning if wrong type?. Default is user.

The following policies can be applied:
apply
lock
unlock
delete

(Check existing code and sync up on the name of the create and delete policies... apply vs create vs managed, delete vs missing vs none etc)

This is especially true in simulate mode.

Check to see if package is installed before trying to install it

Must have:

name
gid

Must have a create and delete policy. See existing code for how to name the policies. I.e. create vs apply vis managed.

create and write tests

There is a special resource, but no provider for it. Create one. It's just a call to mknod...

This resource type is for scenarios where yaybu is used like a system level Buildout. There maybe actions where we still need administrators to perform manual steps. The Prompt resource and provider simply halt execution of yaybu until admin hits the continue button (enter :P)

Fix and write tests.

Needs tests too.

it is declared on the base resource and also on all other resources.

• tests

Will probably need changes to yaybu.core.shell.

The yaybu top level configuration directive should gain config sections, for example:
yaybu:
standard-binaries:
ln: /bin/ln
rm: /bin/rm
userspace: bsd

If transient condition interrupts a build, any pending events shouldn't be forgotten.