Aegir 0.4 alpha 11 released

i got these errors when I installed:

Dummy connection failed to fail: ERROR 2003 [error]
(HY000): Can't connect to MySQL server on
'ubuntu' (111)
Dummy connection failed to fail: ERROR 2003 [error]
(HY000): Can't connect to MySQL server on
'ubuntu' (111)
Created devhostsocialnic database [success]
An error occurred at function : [error]
drush_db_pre_provision_deploy
Dummy connection failed to fail: ERROR 2003 [error]
(HY000): Can't connect to MySQL server on
'ubuntu' (111)
Dummy connection failed to fail: ERROR 2003 [error]
(HY000): Can't connect to MySQL server on
'ubuntu' (111)
An error occurred at function : [error]
drush_provision_drupal_provision_migrate
An error occurred at function : [error]
drush_provision_hostmaster_migrate

I am not quite sure if it all has worked. any suggestions?

Hey guys, thanks for all the hard work on this! We have been sitting on the sidelines since alpha6 with a stable environment hosing about 30 clients. I think we are ready to jump in at the alpha11 level and wanted to know the best path.

Should we upgrade sequentially (alpha7 -> alpha8 -> etc...) or is it safe to upgrade straight to alpha 11 from alpha6?

Hi, I am trying to upgrade Aegir from alpha8 to alpha11.

Following the instructions in UPGRADE.txt I get the following error when trying to upgrade the front end:

I don't know why drush need a settings.php file for the default site, as it is not used by Aegir.
Trying to copy the default.settings.php and running migrate again outputs this:

Trying instead to copy the settings.php file from the Aegir installation to the default site folder and running migrate outputs:

Furthermore the migrate command changes the config/apache.conf file to include config/server_master/apache/conf.d, platform.d and vhost.d instead of the config/apache.d, platform.d and vhost.d folders where the actual platform and site configuration files are located. Thus the Aegir installation and all the sites become unavailable, unless I manually edit the apache.conf file or move the platform and site configuration files to the folder structure in server_master.

Any suggestions to what I am doing wrong?

Ulrik

i am a new aegir user, trial and error has been my life the past few weeks.
As was searching through all posts i could find when i encountered something wrong.

This has helped me in installing the aegir site, using platforms and creating sites from within the hostmaster.

Now i am experimennting with clone and migrate
this gives me some errors.

the next messages i get with cloning:

Undefined index: profiles deploy.provision.inc:79
array_keys(): The first argument should be an array deploy.provision.inc:79
Undefined index: deploy.provision.inc:83
array_merge(): Argument #2 is not an array deploy.provision.inc:83
Undefined index: modules deploy.provision.inc:84
Invalid argument supplied for foreach() deploy.provision.inc:84

-cut-

Successfully connected to the Drupal database.
Drush command could not be completed.
Undefined index: driver environment.inc:939
Undefined index: driver environment.inc:939
PDO support available, but the driver has not been installed. Assuming success.
An error occurred at function : drush_provision_drupal_post_provision_deploy

-cut-
An error occurred at function : drush_provision_drupal_provision_clone
Removed unused clone site package
Changes for drush_provision_drupal_pre_provision_clone module have been rolled back.
Command dispatch complete
Peak memory usage was 20.09 MB
An error occurred at function : drush_hosting_task

The same errors appears when using migrate.

I just see in the 3rd line an extra error.
Running: /var/aegir/drush/drush.php @aegir.domain.com provision-migrate '@platform_drupalxxx' --backend
The external command could not be executed due to an application error.

thats it (for now),

I hope anyone can help. I have been installing and uninstalling aegir for many times now. And i get a bit tired from it(for the most part because of the lack of sleep.)

The easy install script now always assumes that apache and mysql are accessible on the same ip address. For security reasons, one may not want to do this if one has aegir on a single remote server. I for one don't want mysql accessible to the world. So I leave mysql bound to 127.0.0.1.

I want to use the install script which sets up aegir to talk to mysql on the IP specified for hostname in /etc/hosts, which I leave at 127.0.0.1 so everything is fine with the database and things install properly.

However, at the end, you will find you cannot go to the aegir web interface, as apache does not respond there.

The command apache2ctl -S (or httpdctl -S on redhat) will reveal that aegir has told apache that the sites are on 127.0.0.1. cause it doesn't know any better.

So go into the aegir related config files revealed in the above command, change 127.0.0.1 to the public IP that you want aegir to respond on. Restart apache.

Now aegir works great... however, you need to change the ip address in your server node to allow future sites created by aegir to not have 127.0.0.1 as the default IP. Go into the server node, change the ip address to your public ip and save it. Everything will now reverify now that the server they are based on has been changed. Let all the new config files be written.

Everything should work. Too much work for a secure single server install, but I think it is good that aegir is getting the capability to work over more servers.

I am working up a dev server with alpha 11 and realized that neither the Aegir site nor the dev site had any kind of encryption on it and that logins were being passed in the clear. I installed using the INSTALL.TXT and it never occurred to me that there was no mention of installing certs let alone an SSL enabled Apache2 server. I should have planned better, I know.

Anyway, the site being developed will eventually do e-commerce so I have to harden it. I've been banging my head for a few days and I think I am just plain missing some elemental piece of information. Obviously this version of Aegir is set up for encryption and as great as Aegir works with everything else, I am certain that this is my error and not Aegir's error.

When I enable apache-ssl in Aegir, the platform will verify. The server will not verify (fails at "provision-verify --backend" with an application error and then later in the View it shows an "access denied" for the aiger_root user). The main aegir site verifies but the dev site will not verify - yet everything seems to work.

Every SSL call goes to the main aegir site (because of the single ip and the server settings) and I expect that until I add IPs. I suspect I will have to blow the install away and start again to get everything verifying again. I have already tried disabling and re-enabling the module.

Anyone have other thoughts on stuff I can try? Thanks in advance.

Note to my future self - when setting up a remote AWS EC2 database server - you must use the Amazon given Public DNS in order for Aegir to work properly (or setup proper reverse DNS mapping - see options below). For example - the Aegir Server Hostname should be ec2-50-xx-xxx-xxx.compute-1.amazonaws.com, NOT remote1.example.com. This is due to AWS reverse DNS issues.

Even if you setup your server to be accessible from the outside for example as "remote1.example.com" - mysql will happily work from the Aegir master outside - try it from myworkstation.somewhere-outside-aws.com mysql -h remote1.example.com -u root -p the connection will work, but trying to connect from the command line of the EC2 instance itself will fail. Try for yourself - login via ssh to remote1.example.com and mysql -h remote1.example.com -u root -p this will fail with ERROR 2003 (HY000): Can't connect to MySQL server on 'remote1.example.com' (110) because reverse DNS is not setup.

Now you could request a reverse DNS mapping from Amazon at this form - https://aws-portal.amazon.com/gp/aws/html-forms-controller/contactus/ec2..., but that's more for e-mail functionality. I believe also that Amazon Route 53 will allow you to manage your own reverse DNS mapping. And yeah, that would suck if your instance is rebooted with a different public DNS. But so far I've had the same reserved IP for 18 months now and have retained the same Public DNS Hostname all this time. That is all, see you soon future self!

--Tony