Added a new platform (Acquia Drupal) and all of a sudden, all my sites included the hosting system itself redirect to the "It works!" page. The only files are platform_228.conf which is the beginning of the new platform and aegir.chrisridenour.com.server which just has NameVirtualHost declaration.

I'd rather have Aegir recreate these files again, any idea how (or why it happened?)

Thanks.

Comments

cridenour’s picture

cridenour commented

Little update:

I tried verifying from the command line, nothing happened. Copied a VirtualHost file from someone else's Aegir install (with edited servernames) and it obviously loaded. Verified all sites from Aegir itself (same ones I tried from command line) and it regenerated all of the virtualhost files. Still doesn't explain why a platform verify was the last thing in any of my logs and then all the files except the last verify disappeared.

Considering I didn't have SSH open when this happened, something on the server (which is only hosting aegir) deleted those files. This is a huge deal....

Anonymous’s picture

Anonymous (not verified) commented
Status: Active » Postponed (maintainer needs more info)

This is quite strange: not only is there no way I can think of that 'provision delete' would occur in this case, but we don't even *have* the functionality to go and delete other platform configs, because we aren't even implementing platform management yet for it to even accidentally occur: see #373062: 0.4 - automate platform creation

Can we get some more info about your system per the bug reporting guidelines? i.e i'd be interested to see a simple ls -al of your /var/aegir/ and the subdirs inside, including config/vhost.d

What OS you using, etc etc.

And I know this probably isn't an ideal thing for you: but how about trying to reproduce it? If you add another platform of type Acquia, does it happen again?

Can we get the full task output of the Verify task of the platform that apparently caused all this. And any other info you think might be of use.

cridenour’s picture

cridenour commented

Well I'll try reproducing tomorrow - in the middle of debugging some Ubercart issue on one of the sites.

But I am running Ubuntu 8.04 with updated Apache2, PHP, MySQL.

/var/aegir:
total 80
drwxr-xr-x 14 aegir nogroup 4096 2009-10-06 05:59 .
drwxr-xr-x 15 root root 4096 2009-09-30 20:21 ..
drwxr-xr-x 11 aegir nogroup 4096 2009-10-06 05:59 acquia-drupal-6.14
drwxr-xr-x 9 aegir nogroup 4096 2009-10-01 02:57 atrium-beta-1
drwxr-xr-x 9 aegir nogroup 4096 2009-10-01 03:18 atrium-beta-3.1
drwx------ 2 aegir nogroup 4096 2009-10-01 03:22 backups
-rw------- 1 aegir nogroup 745 2009-10-06 06:14 .bash_history
drwx------ 3 aegir nogroup 4096 2009-10-03 12:48 config
-rw------- 1 aegir nogroup 72 2009-09-30 20:23 .cvspass
drwxr-xr-x 9 aegir nogroup 4096 2009-09-30 20:49 drupal-6.14
drwxr-xr-x 5 aegir nogroup 4096 2009-09-30 20:23 drush
drwxr-xr-x 3 aegir nogroup 4096 2009-09-30 20:24 .drush
-rw-r--r-- 1 aegir nogroup 3837 2009-10-03 12:36 .htaccess
drwxrwxr-x 3 aegir www-data 4096 2009-10-06 03:07 keys
-rw------- 1 aegir nogroup 847 2009-10-03 13:35 .mysql_history
drwxr-xr-x 2 aegir nogroup 4096 2009-10-01 02:53 sql
drwxr-xr-x 3 aegir nogroup 4096 2009-10-03 12:35 .subversion
drwxr-xr-x 6 aegir nogroup 4096 2009-10-03 12:36 .svn
-rw------- 1 aegir nogroup 7974 2009-10-06 05:59 .viminfo

(Folders not described below):
Acquia-Drupal-6.14: SVN download.
Atrium sites are direct tars.
Backups holds two backups with same owner:group as all other files.
Keys is recent and holds some SSL certs. These weren't around at the time of the deletion.

/var/aegir/drush:
total 52
drwxr-xr-x 5 aegir nogroup 4096 2009-09-30 20:23 .
drwxr-xr-x 14 aegir nogroup 4096 2009-10-06 05:59 ..
drwxr-xr-x 7 aegir nogroup 4096 2009-09-30 20:23 commands
drwxr-xr-x 2 aegir nogroup 4096 2009-09-30 20:23 CVS
-rwxr-xr-x 1 aegir nogroup 1508 2009-05-24 16:10 drush
-rw-r--r-- 1 aegir nogroup 46 2007-06-11 13:56 drush.bat
-rwxr-xr-x 1 aegir nogroup 6481 2009-06-04 19:48 drush.php
-rw-r--r-- 1 aegir nogroup 2174 2009-04-15 01:13 example.drush.inc
-rw-r--r-- 1 aegir nogroup 2895 2009-04-19 03:13 example.drushrc.php
drwxr-xr-x 3 aegir nogroup 4096 2009-09-30 20:24 includes
-rw-r--r-- 1 aegir nogroup 5196 2009-06-04 03:10 README.txt

/var/aegir/config/vhost.d:
total 44
drwx------ 2 aegir nogroup 4096 2009-10-06 03:30 .
drwx------ 3 aegir nogroup 4096 2009-10-03 12:48 ..
-rw-r--r-- 1 aegir nogroup 350 2009-10-04 14:25 aegir.mysite.com_80
-rw-rw-r-- 1 aegir nogroup 101 2009-10-04 14:31 aegir.mysite.com.server
-rw-rw-r-- 1 aegir nogroup 512 2009-10-06 03:00 myothersite.com_80
-rw-rw-r-- 1 aegir nogroup 2788 2009-10-04 14:31 platform_211.conf
-rw-rw-r-- 1 aegir nogroup 2791 2009-10-04 14:31 platform_228.conf
-rw-rw-r-- 1 aegir nogroup 2784 2009-10-04 14:31 platform_5.conf
-rw-rw-r-- 1 aegir nogroup 2786 2009-10-04 14:31 platform_69.conf
-rw-rw-r-- 1 aegir nogroup 381 2009-10-04 15:33 sub.domain.mysite.com_80
-rw-r--r-- 1 aegir nogroup 705 2009-10-06 03:30 sub.domain.mysite.com-ssl

Culprit verify task (last thing to happen before missing conf's):
Task starts processing
Running: php /var/aegir/drush/drush.php --root='/var/aegir/acquia-drupal-6.14' 'provision' 'verify' --backend
Drush bootstrap phase : _drush_bootstrap_drush()
Drush bootstrap phase : _drush_bootstrap_drupal_root()
Initialized Drupal 6.14 root directory at /var/aegir/acquia-drupal-6.14
Found command: provision verify
Initializing drush commandfile: provision_apache
Undefined index: base_url
Initializing drush commandfile: provision_drupal
Initializing drush commandfile: provision_mysql
Undefined index: db_url
Including /var/aegir/.drush/provision/web_server/verify.provision.inc
Including /var/aegir/.drush/provision/platform/verify.provision.inc
Including /var/aegir/.drush/provision/db_server/verify.provision.inc
Including /var/aegir/.drush/provision/ssl/verify.provision.inc
(highlighted) Virtual host configuration path does not exist.
Virtual host configuration path has been created.
Virtual host configuration ownership of path has been changed to aegir.
Virtual host configuration permissions of path have been changed to 0700.
Virtual host configuration path is writable.
Generating apache host configuration file platform_228.conf.
Generating apache host configuration file aegir.mysite.com.server. #comment - Shouldn't this have already been there?
Apache has been restarted
Provision configuration path exists.
Provision configuration ownership of path has been changed to aegir.
Provision configuration permissions of path have been changed to 0700.
Provision configuration path is writable.
Backup path exists.
Backup ownership of path has been changed to aegir.
Backup permissions of path have been changed to 0700.
Backup path is writable.
Drupal sites directory is writable by the provisioning script
Undefined variable: sites
This platform is running drupal 6.14
Including non-version specific file : /var/aegir/.drush/provision/platform/drupal/packages.inc
Found 131 modules in base
Found 8 themes in base
Undefined property: stdClass::$info
Found install profile uberdrupal
Undefined property: stdClass::$info
Found install profile acquia
Undefined index: project
Undefined index: project
Mysql can create new databases.
Generating drushrc.php file
Drushrc file (/var/aegir/acquia-drupal-6.14/drushrc.php) was written successfully
Changed permissions of drushrc.php to 0400
Command dispatch complete
Removing task from hosting queue
Command dispatch complete

I'm curious if I can reproduce this as well :) After all I have read and talked with everyone, the assumption is this could not have happened. But it did!

Will update tomorrow evening with results.

Anonymous’s picture

Anonymous (not verified) commented

(highlighted) Virtual host configuration path does not exist.
Virtual host configuration path has been created.
Virtual host configuration ownership of path has been changed to aegir.
Virtual host configuration permissions of path have been changed to 0700.
Virtual host configuration path is writable.

Thats odd on just a verify of a platform. Why did it think the config dir didn't exist and create it? It should already have existed - the very fact you were operating on the aegir site means a vhost config in existence at /var/aegir/config/vhost.d unless there's a difference in your configuration.

i.e, a verify of a platform on my system:

Virtual host configuration path exists.
Virtual host configuration ownership of path has been changed to miguel.
Virtual host configuration permissions of path have been changed to 0700.
Virtual host configuration path is writable.

It gets the path to the config dir from the information in the web server node. Sure you didn't change this as well? And you would've created the config dir during the install, either while reading the INSTALL.txt, using install.sh, or following the instructions in the install profile stage.

It begs the question: if it had to *create* the config directory, how could the vhost configs have existed already? Obviously they did, so why did it need to create a directory, and where did it create it, as it would have to be a different directory somewhere else. I don't think it could've created a config directory *over the top* of the existing one, losing the files - as you can see by my example, it changes the log message to acknowledge it's found the existing dir. Very strange.

What about find /var/aegir -type d -name config ? In case it created a new subdirectory somewhere.. I can't wrap my head around how it could think it didn't exist already, unless it didn't!

Anyway do let us know if you can reproduce it. It's certainly nothing I've ever seen nor ever reported before, so it's a bit of a mystery.

Anonymous’s picture

Anonymous (not verified) commented
Priority: Critical » Normal

Downgrading this from critical til we can actually determine a bug exists

cridenour’s picture

cridenour commented

Well oh my.

find /var/aegir -type d -name config
/var/aegir/config
/var/aegir/acquia-drupal-6.14/config
aegir@aegir:~$ cd acquia-drupal-6.14/
aegir@aegir:~/acquia-drupal-6.14$ cd config
aegir@aegir:~/acquia-drupal-6.14/config$ ls
vhost.d
aegir@aegir:~/acquia-drupal-6.14/config$ cd vhost.d
aegir@aegir:~/acquia-drupal-6.14/config/vhost.d$ ls
aegir.mysite.com_80 othersite.com_80 platform_5.conf
aegir.mysite.com.server platform_211.conf platform_69.conf

I can find no evidence that this folder was moved INTO acquia-drupal-6.14 but it's even less likely that the code moved the config folder into the folder it was verifying...isn't it? But like you said, the very fact that I was doing this on Aegir means those files were there...

Wasn't able to reproduce when I added PressFlow.

Anonymous’s picture

Anonymous (not verified) commented

I have seen this reported by another user in the past (about a month and a half ago), not necessarily with the Acquia platform but it *was* a non-standard platform like this I think.

I was never able to reproduce or trace how it happens.

I do wonder if you add another Acquia platform, whether you experience the same issue, or whether this is some sort of random bug :(

cridenour’s picture

cridenour commented

When I installed this Acquia, it was with SVN - not sure if that could have any affect on all of this.

An additional Acquia install worked without a hitch, even with Make this default checked (as it was with the original).

If there has been a similar problem in the past, maybe there's something going on we're missing. If the problem was only kindof similar, I may have dragged config to the acquia-drupal-6.14 directory accidentally and when it reloaded Apache after the verify, it went to hell.

If you believe this is the case, feel free to close. Thanks for the troubleshooting steps.

adrian’s picture

adrian commented
Status: Postponed (maintainer needs more info) » Closed (fixed)

closing