anarcat authored Jan 25, 2010 and anarcat committed Jan 25, 2010

this fixes a regression introduced in d8554cf433ddb0b665e05b143a28fac429196535

mig5 authored Jan 25, 2010 and mig5 committed Jan 25, 2010

create d7's private dirs even on non d7 sites, as well as set appropriate permissions on them, to account for the future potential of upgrading d6 > d7 sites

before this patch, redirection virtual hosts were created with a duplicate ServerName, which seems to be working, but is needlessly confusing

after this patch, the redirection vhosts are created only based on the aliases provided and not the site_url

this implies that to do generic redirections (e.g. for SSL) you may need to push your site_url in the aliases array. that has been done in SSL so that all hosts (ie. aliases and the site_url) are redirected to the site_url, which is not appropriate for regular vhosts (because it would mean a infinite redirection loop)

overwrite the port 80 config if redirection + ssl is enabled, regardless of whether or not the file already exists

if we don't do that, the file is never re-written once it's been written once: bad.

was missing the install_mail function, and the format of body was changed from string to array.

this is to avoid the possibility of Denial of Service attacks from the drupal admins: if someone were to create a symlink in files/ that would point to the parent sites/ directory, the recursive chmod that happen on verify would loop inifinitely (i saw one running for 1h)

do not flush privileges: it's not required when you use GRANT/REVOKE, and requires unnecessary permissions

Mathieu Petit-Clair authored Jan 19, 2010 and anarcat committed Jan 19, 2010

Signed-off-by: anarcat <anarcat@koumbit.org>

this was failing because provision_path_unlink was checking the file existence (file_exists) before removing the symlink. in this case, the file really *didn't* exist because the link target was already removed.

instead of checking, we just try to delete the file, if it fails, it will return false anyways.

we do the same with rmdir while we're here.

also make sure we work on the trimmed file path

anarcat authored Jan 18, 2010 and anarcat committed Jan 18, 2010

this was failing because provision_path_unlink was checking the file existence (file_exists) before removing the symlink. in this case, the file really *didn't* exist because the link target was already removed.

instead of checking, we just try to delete the file, if it fails, it will return false anyways.

we do the same with rmdir while we're here.

also make sure we work on the trimmed file path

this is pre-populated for the standard install profile in drupal 7, which is the upgrade path of the default install profile.

The init and exit hooks were expecting to only be running on "provision *" commands, i modified them to run on "provision-*" commands instead.

changed all instances of drush_backend_invoke and drush_invoke to match
the new command names.

anarcat authored Jan 07, 2010 and anarcat committed Jan 07, 2010

valid

first, it's not necessarily available. second, we have proper failure
modes anyways, so this check isn't useful

anarcat authored Jan 07, 2010 and anarcat committed Jan 07, 2010

this way we can have the "aegir mysql root" user to be a bit more
restricted in his actions