I'm new to using the Aegir system, I've jumped straight in and set up an Aegir install on my Debian Etch VM with the 6X modules.

While I'm still getting used-to/learning Aegir I've noticed that when creating a new site on a new platform no activation email or sign-in url are created. If I look in the users table of the DB the user name and email are

SELECT uid, name, mail FROM base01.users u;

1, 'placeholder-for-uid-1', 'placeholder-for-uid-1'

Also when selecting a platform an Ajax loading gif displays quickly then vanishes, I believe it should be offering me a choice of install profiles but none are shown for any platform; I have made available a couple.

To use the new install I have dropped the tables for the DB and ran install.php

It works OK (except for said install profile issue) when using the initial Aegir platform.

Here is the log (I've done this three times on two platforms):

Task starts processing
Running: php /var/aegir/drush/drush.php --root='/var/aegir/platforms/platform02/drupal' 'provision' 'install' 'base03.dev' --backend
Drush bootstrap phase : _drush_bootstrap_drush()
Drush bootstrap phase : _drush_bootstrap_drupal_root()
Loading drushrc "/home/aegir/platforms/platform02/drupal/drushrc.php" into "drupal" scope.
Initialized Drupal 6.13 root directory at /var/aegir/platforms/platform02/drupal
Found command: provision install
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/install.provision.inc
Including /var/aegir/.drush/provision/platform/install.provision.inc
Including /var/aegir/.drush/provision/db_server/install.provision.inc
Generating apache host configuration file base03.dev.
Created sites/base03.dev
Changed permissions of sites/base03.dev to 0755
Created sites/base03.dev/files
Changed permissions of sites/base03.dev/files to 2770
Created sites/base03.dev/files/tmp
Changed permissions of sites/base03.dev/files/tmp to 2770
Created sites/base03.dev/files/images
Changed permissions of sites/base03.dev/files/images to 2770
Created sites/base03.dev/files/pictures
Changed permissions of sites/base03.dev/files/pictures to 2770
Created sites/base03.dev/themes
Changed permissions of sites/base03.dev/themes to 0755
Created sites/base03.dev/modules
Changed permissions of sites/base03.dev/modules to 0755
Changed ownership of sites/base03.dev/files
Changed group ownership of sites/base03.dev/files
Changed ownership of sites/base03.dev/files/tmp
Changed group ownership of sites/base03.dev/files/tmp
Changed ownership of sites/base03.dev/files/images
Changed group ownership of sites/base03.dev/files/images
Changed ownership of sites/base03.dev/files/pictures
Changed group ownership of sites/base03.dev/files/pictures
Created base03rdevcouk database
Generate settings.php file
Changed permissions of settings.php to 0440
Change group ownership of settings.php to www-data
Drush bootstrap phase : _drush_bootstrap_drupal_site()
Initialized Drupal site base03.dev at sites/base03.dev
Including version specific file : /var/aegir/.drush/provision/platform/drupal/install_6.inc
Drush bootstrap phase : _drush_bootstrap_drupal_configuration()
Drush bootstrap phase : _drush_bootstrap_drupal_database()
Successfully connected to the Drupal database.
Installing Drupal schema
Loading default install profile
Installing translation : en
Undefined variable: missing_requirement
Undefined variable: language
Drush bootstrap phase : _drush_bootstrap_drupal_full()
Installed Block module.
Installed Filter module.
Installed Node module.
Installed User module.
Installed Color module.
Installed Comment module.
Installed Help module.
Installed Menu module.
Installed Taxonomy module.
Installed Database logging module.
Initial locale import
Running profile specific task : profile
Apache has been restarted
Secured settings.php with safe permissions
Including non-version specific file : /var/aegir/.drush/provision/platform/drupal/clear.inc
Cleared all caches
Rebuild node type cache
Rebuild module cache
Rebuild theme cache
Rebuild node access cache
Rebuild menu cache
Including non-version specific file : /var/aegir/.drush/provision/platform/drupal/packages.inc
Found install profile default
Found 33 modules
Found 6 themes
Drushrc file (sites/base03.dev/drushrc.php) was written successfully
Command dispatch complete
Removing task from hosting queue
Command dispatch complete

Here is log for a successful install on the initial Aegir platform.

Task starts processing
Running: php /var/aegir/drush/drush.php --root='/var/aegir/drupal/' 'provision' 'install' 'base02.dev' --backend
Drush bootstrap phase : _drush_bootstrap_drush()
Drush bootstrap phase : _drush_bootstrap_drupal_root()
Loading drushrc "/var/aegir/drupal/drushrc.php" into "drupal" scope.
Initialized Drupal 6.13 root directory at /var/aegir/drupal/
Found command: provision install
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/install.provision.inc
Including /var/aegir/.drush/provision/platform/install.provision.inc
Including /var/aegir/.drush/provision/db_server/install.provision.inc
Generating apache host configuration file base02.dev.
Created sites/base02.dev
Changed permissions of sites/base02.dev to 0755
Created sites/base02.dev/files
Changed permissions of sites/base02.dev/files to 2770
Created sites/base02.dev/files/tmp
Changed permissions of sites/base02.dev/files/tmp to 2770
Created sites/base02.dev/files/images
Changed permissions of sites/base02.dev/files/images to 2770
Created sites/base02.dev/files/pictures
Changed permissions of sites/base02.dev/files/pictures to 2770
Created sites/base02.dev/themes
Changed permissions of sites/base02.dev/themes to 0755
Created sites/base02.dev/modules
Changed permissions of sites/base02.dev/modules to 0755
Changed ownership of sites/base02.dev/files
Changed group ownership of sites/base02.dev/files
Changed ownership of sites/base02.dev/files/tmp
Changed group ownership of sites/base02.dev/files/tmp
Changed ownership of sites/base02.dev/files/images
Changed group ownership of sites/base02.dev/files/images
Changed ownership of sites/base02.dev/files/pictures
Changed group ownership of sites/base02.dev/files/pictures
Created site_176 database
Generate settings.php file
Changed permissions of settings.php to 0440
Change group ownership of settings.php to www-data
Drush bootstrap phase : _drush_bootstrap_drupal_site()
Initialized Drupal site base02.dev at sites/base02.dev
Including version specific file : /var/aegir/.drush/provision/platform/drupal/install_6.inc
Drush bootstrap phase : _drush_bootstrap_drupal_configuration()
Drush bootstrap phase : _drush_bootstrap_drupal_database()
Successfully connected to the Drupal database.
Installing Drupal schema
Loading default install profile
Installing translation : en
Undefined variable: missing_requirement
Undefined variable: language
Drush bootstrap phase : _drush_bootstrap_drupal_full()
Installed Block module.
Installed Filter module.
Installed Node module.
Installed User module.
Installed Color module.
Installed Comment module.
Installed Help module.
Installed Menu module.
Installed Taxonomy module.
Installed Database logging module.
Initial locale import
Running profile specific task : profile
Sent welcome mail to aegir@mydomain.com
Login url: http://base02.dev/user/reset/1/1248059584/7af668c43cec11fa0743ac4542792736
Apache has been restarted
Secured settings.php with safe permissions
Including non-version specific file : /var/aegir/.drush/provision/platform/drupal/clear.inc
Cleared all caches
Rebuild node type cache
Rebuild module cache
Rebuild theme cache
Rebuild node access cache
Rebuild menu cache
Including non-version specific file : /var/aegir/.drush/provision/platform/drupal/packages.inc
Found install profile hostmaster
Found install profile default
Found 34 modules
Found 6 themes
Drushrc file (sites/base02.dev/drushrc.php) was written successfully
Command dispatch complete
Removing task from hosting queue
Command dispatch complete

Comments

redpuma’s picture

redpuma commented

Here are some more observations:

I encountered the above issue with all Hosting features enabled, so I disabled all experimental and Platform. Created another site on the second platform, this time the site was created successfully with a user and activation email. The DB was named "site_183" similarly to the ones created on the initial Aegir platform.

Re-enabled the Platform option and created another site. This time the problem re-occurred. I noticed also that the DB was named like the site's name (domain).

I hope this information is useful, if I can do any more or clarify things please let me know.

anarcat’s picture

anarcat commented
Priority: Normal » Critical

This definitely looks like the #486934: broken IPC communication on Drupal 6 (AKA "welcome email not being sent") issue rearing its ugly head, so I'm bumping this to critical. The workaround I found was to create a new platform, can you try that? (I know you tried with disabling platform support first, but just try to create a new platform).

redpuma’s picture

redpuma commented

Just tried adding a new platform but I'm afraid my Aegir setup is now broken, I tried to add a Drupal 5 version alongside my D6 version and neither cron runs for verifying platforms.
I'll see if I can fix it, just removed the D5 install of Aegir, still not verifying. Not the best situation now for verifying issues sorry.

redpuma’s picture

redpuma commented
Priority: Critical » Minor

Hi, I've fixed my aegir install (part of the problem was Apache not restarting due to trying to load non-existent vhost.d I'd left in apache2.conf) I deleted the DB and reinstalled (might not have been necessary).

Following various unsuccessful installs with same problem as above and some experimenting with adding and verifying platforms it is now all working.

Regarding the ajax install profile loading flash: I've now learned that will happen when setting a platform radio button and if their are any choices for install profiles they will show. But only if they were there when the platform was verified so reverification is necessary when adding new install profiles to platforms.

Another observation: Deleting sites does not result in the site or vhost entry being deleted/cleaned up.

Priority minor as it seemed to be user error at some point in the process. I'll be checking to see if it was an error or some inconsistency.

redpuma’s picture

redpuma commented
Priority: Minor » Critical

After adding another platform and encountering the original problem all over again I did some testing to see if I could find out what was the cause.

Having spent a considerable bit of time creating 9 new platforms and about 16 new sites I was about to conclude the one thing that needed to be done after preparing a new platform was to give write permission to the group on "/sites"; this fixed the problem. Or so I thought because it fixed it in 3 cases, I then decided to remove the group write permissions on one expecting to encounter the no email issue again, but it continued to work.

I then created a 10th platform and left the group write permission off created a site and it worked. I've checked through my install and compared it to the instructions on the screen cast twice so I'm fairly sure its not the install at fault

Conclusion: Not user error but random bug. So I've put the priority back up to critical.

Anything else I can do to help here?

anarcat’s picture

anarcat commented

Oh boy... what a mess. So it seems this is a random bug we're hitting, and I have really no idea where to start. Could you try the patch to drush I mention in this comment see if you can reproduce again? http://drupal.org/node/486934#comment-1735808

redpuma’s picture

redpuma commented

I can do, but 50% of the platforms were created with drush the other I did a CVS checkout as I was suspecting the drush download (just a hunch) but it really made no difference.

Has anyone else experienced this?
*edit: (after reading other thread) Ah I see, so is not likely the actual platform or permissions on it but what DRUSH is doing with Provisioning. I'm running the DRUSH Official release (9th June 09) so maybe... by the way I have my PHP CLI ini set with 128M memory.

anarcat’s picture

anarcat commented

I have also experienced this, but as you, I was able to workaround by creating a new platform... That's not enough for me if others are regularly experiencing it...

redpuma’s picture

redpuma commented

I commented out the line in the drush file referred to in the other post. So everything else is the same, so far everything seems to work, I get the emails now. I've created 3 platforms and as many sites to test this, perhaps not enough for a true test but it seems positive.

I'll let you know if the problem reappears.

Macronomicus’s picture

Macronomicus commented

I seem to be experiencing one of the above issues.. Emails are not sent on site creation. My contact form is working so I know drupal has access too my servers mail. Exim4 with smarthost

Its really not stopping me though as there is always the login url that spits out in the install task info. Absolutely everything else is working perfectly.

Which line did you comment out to get the emails? Im running drush head from jul 8th that post above is from June.

redpuma’s picture

redpuma commented

The problem I encountered resulted in not getting the URL in the install task info as well as the lack of email; it didn't create a proper user. Sounds like a mail issue.

Details of the line commented out are in the patch attached to this comment http://drupal.org/node/486934#comment-1735832 .

Macronomicus’s picture

Macronomicus commented

hmm ... perhaps its something else all together that's causing my issue, ill have to dig some more... im guessing that patch is already in my drush though since im using the latest head. I'll create a new issue if necessary... I was hoping this was the same thing & would be easy! At least im getting the onetime logon url in the output, thats easy enough & no bother really.

anarcat’s picture

anarcat commented

More precisely, here's the actual patch I am suggesting:

http://drupal.org/files/issues/486934_drush_quiet_hotfix.patch

It's *not* in drush (yet?). I also do not think it's the right fix for this issue, so I would appreciate further testing.

redpuma’s picture

redpuma commented

Update: I'm now using the system, incorporated it into my work flow, initially to help me with consistency when creating new projects.

I have five new projects I'm kicking off. I created three of them all the same (platform, install profile) just different domain names. One of the three didn't create an email or one time login link. Only noticable difference was that domain had hypen.

So I created another two using the same domain name, one with the hyphen moved within name text, the other without any hythen. Both installed without any problems.

Next I removed these three sites (deleted the site node in Aegir/Drupal, ran drush provision delete sitename*) and re-created the site which caused problems; this time it installed perfectly.

I'll keep reporting back, see if any pattern emerges.

*drush provision delete which worked fine another day but seemed inconsistent today

anarcat’s picture

anarcat commented

Please clarify if you are running with the drush patch mentionned above or not.

Macronomicus’s picture

Macronomicus commented

This is random or very specific ... I have another testbed vm here locally and the emails are sent instantly.. Its only on my online server where the temporary login emails aren't sent. Email does function fine on my server though otherwise.

I've yet to apply that patch though .. so ill give that a go here in a bit, & report back.

redpuma’s picture

redpuma commented

This is with the drush patch applied to the "All-Versions-2.0 2009-Jun-09" release. (When I say patch I lazily commented out that line "$data['quiet'] = TRUE;" ).

I have kept everything else the same.

anarcat’s picture

anarcat commented

So you're saying the patch *doesn't* help, that's interesting.

Are you always letting the cronjob finish or are you running the task manually sometimes?

I'm trying to find a correlation with *something* to reproduce reliably (and therefore fix) this bug...

redpuma’s picture

redpuma commented

That's right I experienced the problem with the patch.

I'm always letting the cron do its job.

Macronomicus’s picture

Macronomicus commented

Was just over @ irc ... and md5 said its possible theres something mucked up with my cli php .... just checked and both php.ini files have the sendmail path configured properly. Im going to have to dig around to find out if the cli is the problem and what to do about it.

Strange stuff ... im also not able to send mail from my open Atrium install ... its just weird that the contact form is working but not these auto emails or anything from open atrium. I hope it is the cli ... at least I have something to dig into for a bit!

Macronomicus’s picture

Macronomicus commented

ok well maybe not .. testing a php file from cli does send mail so most likely thats not it.... oh well more digging to go I guess.

Anonymous’s picture

Anonymous (not verified) commented

For what it's worth, at Vertice's suggestion I've tried to reproduce this but have been unsuccessful.. I provisioned a fresh Xen instance, Debian Etch, even set my platforms etc to the same paths etc as represented by redpuma's initial debug info in this ticket. Everything is Just Working for me.

Having observed macrocosm's issues on IRC, I believe his case was different to redpuma's.

If there's anything else I can do to try and reproduce this let me know.. plenty of infrastructure at my disposal to fire up test servers etc.

redpuma did the issue only ever occur on the second platform you created? And what was that platform exactly, standard Drupal 6.13 like the first or something different? It didn't contain any modifications to the default install profile?

adrian’s picture

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

I'm marking this as postponed and rolling a new RC

Macronomicus’s picture

Macronomicus commented

Yeah .. mig5 is correct .. it was a different issue with a similar result. Sorry!

redpuma’s picture

redpuma commented

@25 Mig5

This did happen on various platforms I had created (note this is my first set-up and experiment with Aegir, so it might be an anomaly with install/set up but I have been over that a few times).
Was using standard 6.13. Not always default install profile (I'm afraid haven't access to my system right now but think it was http://drupal.org/project/the_base ).

Haven't made any new installs recently probably won't get a chance to for another two weeks.

anarcat’s picture

anarcat commented

I must say I also witnessed this problems numerous times, but I have no way to reproduce reliably. Debian etch + rc2.

anarcat’s picture

anarcat commented
Status: Postponed (maintainer needs more info) » Fixed

I'm going to mark this one as fixed. There has been numerous tests performed by mig5 in the recent times and I haven't been able to reproduce reliably anyways. I think this is fixed, and to reopen I would like to have a solid test case. But if you see this bug in rc4, please do reopen, even if you don't have too strong of a test case (worst thing would be to ship 0.3 with the bug but without an errata). I can live with that bug in the release if we have a clear documentation on it with a workaround for people (errata...)

steveparks’s picture

steveparks commented
Version: 6.x-0.3-rc2 » 6.x-0.3
Priority: Critical » Normal
Status: Fixed » Active

I'm seeing this again - aegir HEAD (as of day of 0.3 release, so effectively 0.3) installing default profile of vanilla drupal-6.13.

(This is the only platform I have had an issue with. The problem doesn't happen when installing sites on acquia 1.2.14.)

The install task completes successfully with no errors, but does not list the onetime login for the admin. The admin is not emailed with this login either.

In the DB the user name and mail for uid 1 are both: 'placeholder-for-uid-1'

---
Steve Parks
Pilot

Anonymous’s picture

Anonymous (not verified) commented

Hi Steve, you had pastebin the errors once, and there was a 'Permission denied' clue. Still got the link?

I'll dig around and see if I have it in IRC logs or something.

steveparks’s picture

steveparks commented

Hi Mig5
Yeah, there were no errors shown on the log of the install task of this site - so no clues there I'm afraid. :(

However, I updated to the latest HEAD code last night, and am seeing if I can still reproduce the problem after that - so far it hasn't happened again, but it may just be very intermittent.

I'll post back here if I can reproduce it again.

steve

anarcat’s picture

anarcat commented
Title: No activation email sent - user not defined on new platform » User not defined on new platform
Status: Active » Fixed

So here's the deal: there *is* a problem with IPC communications that is intermittent. That this bug here was reproduced again just shows that issue (#486934: broken IPC communication on Drupal 6 (AKA "welcome email not being sent")) is still there and should be reopened.

The issue here (that the admin user is not created) can be worked around, however. In Drupal 5, the admin user is created whether or not an email is provided to the backend. I have commited a patch that ports that fix to Drupal 5.

Of course it doesn't solve the underlying, more general issue and the user will not be able to log in, but at least that pesky "placeholder-for-user-1" thing will go away.

Anonymous’s picture

Anonymous (not verified) commented

The last commit had a syntax error: if anyone updated HEAD for that backported user create / login email fix, please update again to get the latest copy of platform/drupal/install_6.inc :)

Cheers

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.