At the 10th step of the Aegir setup process (Configure your database server) the information on the form is not conform with the install manual. The text on the form proposes to use the same database user as we used before (the "hostmaster"), but it does not work. The correct way is to have the secondary database user here (called aegir in the documentation), but it is not reflected in the help text on the form.

Doka

Comments

jonhattan’s picture

jonhattan
Primary language Spanish
Location Plasencia
commented

doka: are you using INSTALL.txt or install.sh.txt? (install.sh creates a database called hostmaster --that's not the case for INSTALL.txt)

The better way to install Aegir at present is to follow INSTALL.txt and then follow the wizard, avoiding all steps already done by INSTALL.txt instructions. That is, almost do nothing but adding the sudo line.

doka’s picture

doka commented

It does not matter whether manual install via INSTALL.txt or install by install.sh script: there is a point later on, where you continue the Aegir setup in your browser, and there are misleading info at step 10 (Configure your database server).

Users in the database (hostmaster, aegir) are OK, problem is the text on the form.

Anonymous’s picture

Anonymous (not verified) commented

The text on the form proposes to use the same database user as we used before (the "hostmaster"), but it does not work.

Using the 'same database user' for both, works for me just fine.. I use 'aegir' for both. Can we get some more info than 'it does not work'? How does it not work?

Are you referring to the specific GRANT statement that is suggested? There was a ticket about that, #553348: directives to create initial grant have the wrong 'host' part, but the fixes were committed for rc4. Or is this a different issue?

doka’s picture

doka commented

I used these statements from here: http://groups.drupal.org/node/25485 (Configure MySQL)

mysql -uonlyme -p 

mysql> CREATE DATABASE hostmaster 
mysql> GRANT ALL ON hostmaster.* TO 'hostmaster'@'localhost' IDENTIFIED BY 'password'; 
mysql> GRANT ALL PRIVILEGES ON *.* TO 'aegir'@'localhost' IDENTIFIED BY 'password'  WITH GRANT OPTION; 
mysql> exit

Then, during the setup process of Aegir, there are two forms for asking database settings:
- in the first one I used the "hostmaster" db user
- at the second one (Aegir specific, Configure your database server) the text in the form led me to use the "hostmaster" user once again, which broke the setup. Using aegir user here is working fine, but is not in line with the instruction text on the form.

anarcat’s picture

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

Well, the wizard does tell you you need a user capable of creating databases:

$help['title'] = t('Mysql user account capable of creating new databases');

I'm not sure what you want this form to do better here...

steveparks’s picture

steveparks commented
Assigned: Unassigned » steveparks
Status: Postponed (maintainer needs more info) » Active

Hi

I've experienced a similar issue with a recent setup - INSTALL.txt doesn't include the MYSQL command to enable enough priveleges for the 'aegir' user. it just sets up a basic db user for aegir's own DB.

My help page at http://groups.drupal.org/node/25485 that doka references above for how he got it to work in the end does include the GRANT ALL PRIVELEGES statement.

I'll work on and contribute a patch to INSTALL.txt to add this in, and make it all a bit clearer.

The aim will then be to make INSTALL.txt and the g.d.o help the same to reduce confusion. it's on my to-do list!

Steve

Anonymous’s picture

Anonymous (not verified) commented

I've experienced a similar issue with a recent setup - INSTALL.txt doesn't include the MYSQL command to enable enough priveleges for the 'aegir' user. it just sets up a basic db user for aegir's own DB.

That's because at some point, the user has to be 'sent away' from the INSTALL.txt and to complete the install via the tasks in the hostmaster install profile.

The SQL instructions to create the 'superuser' mysql user are given in the install profile tasks, both for the case where the sql server is on localhost, and if it is on a separate machine (the GRANT statement differs slightly depending on this).

I think the problem is almost a backhanded compliment: INSTALL.txt has become so exhaustive in its instructions, that people are starting to not bother to read the instructions in the hostmaster install wizard, because there *is* a bit of overlap. So they don't click on the 'How do I configure this' help section in the mysql superuser stage of the browser-based install, and miss the step.

I really feel the instructions are as good as they can be, and that INSTALL.txt should only do so much up until the 'now point your browser to the aegir site' stage. But there is no such thing as too much documentation, so if you feel you can improve it, please do patch :)

steveparks’s picture

steveparks commented

Hmm - i don't recall seeing the SQL instructions in the install profile frontend? It said a user with all permissions was needed, but i don't remember seeing the suggested MYSQL code. I'll try again.

Question for mig5/adrian/anarcat:
Is it policy to have two DB users:
'hostmaster' for just aegir's own database
'aegir' as a kind of power user with GRANT ALL PRIVILEGES ..... WITH GRANT OPTION

or just to have the 'aegir' user to do both?

Earlier instructions suggested both, but more recent install.txt seems to just suggest the one user.

I'll try bringing all docs in line with prefered policy

Anonymous’s picture

Anonymous (not verified) commented

Hmm - i don't recall seeing the SQL instructions in the install profile frontend? It said a user with all permissions was needed, but i don't remember seeing the suggested MYSQL code. I'll try again.

Click the 'How do I configure this' help link when you come across it. The reason I know it's there is I once had to patch it because it was handing out an incorrect instruction. It's been there as long as I've been using Aegir (which is not that long.. but at least since rc2 it's been there)

Is it policy to have two DB users:
'hostmaster' for just aegir's own database
'aegir' as a kind of power user with GRANT ALL PRIVILEGES ..... WITH GRANT OPTION

I tend to use just the one user. On the other hand it might be seen as best practice to have a less-privileged user on a potentially 'public facing' site like the aegir site... generally I have bigger security issues than mysql user privileges to be concerned about, or am working in closed environments. So I welcome anarcat or adrian's opinions here.

The install wizard also makes a point of saying 'if you re-use the same user as the aegir database user, you don't need to enter a password here', which touches on this issue (i.e you can create a different user for a superuser but you are free to re-use the existing aegir user).

I welcome a 'best policy' to be mentioned, as I've been musing on the idea of doing a new screencast (so people stop following that flaming 0.2 release and coming to IRC with a mess of a system :) ) and I would want to set a good example, as opposed to a traditional mig5 example :)

Anonymous’s picture

Anonymous (not verified) commented

Edit: steveparks, you were wondering where the mysql instructions are.. I just re-read the original ticket in this issue and it's the same problem: it's on step #10, but doka didn't click the 'how do I configure this' link and thus didn't see the example SQL statements.

Just in case it wasn't clear.

Also, here is the ticket where I fixed the GRANT statement instructions that are contained therein, for reference. #553348: directives to create initial grant have the wrong 'host' part

Anonymous’s picture

Anonymous (not verified) commented
Status: Active » Fixed

I have committed two fixes that make it much more clear that there is a requirement for a database superuser capable of creating more databases, and that we recommend creating a separate user to the db user of the 'main' aegir site. We also now suggest a standard naming convention:

Main aegir site: database name 'aegir', database user 'aegir'
Superuser: database user 'aegir_root'.

The examples given in the "How do I configure this" section now use 'aegir_root' by default. There is also a nice big bold statement on that configuration page in the install saying

'If the user you specified when first configuring the Drupal can create databases, you probably do not need to change anything here. Otherwise, create an "aegir_root" superuser per the example offered below.'

So the actual instructions are a lot more verbose, blatant, and most of all consistent now in INSTALL.txt, the actual browser-based instructions, and also the docs on g.d.o which I updated.

There's an outstanding issue about the superuser form being populated with the username of the 'main' non-superuser database user on the Database configuration task in the install profile, that's been mentioned in #19 in #553348: directives to create initial grant have the wrong 'host' part.

But I think these new additions to the instructions warrant this ticket to be closed, so I'm doing so.

Status: Fixed » Closed (fixed)

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

  • Commit fa6e870 on 599758_edit_main_site, 640952_client_preview, dev-dns, dev-features, dev-headless_install, dev-log_directory, dev-migrate_aliases, dev-multiserver-install, dev-newsiteform, dev-nginx, dev-platform_management, dev-ports, dev-purgebackup, dev-relationships, dev-restore, dev-server_nodetype, dev-services, dev-site_rename, dev-ssl, dev_dns, prod-koumbit, ssl, dev-ssl-ip-allocation-refactor, dev-1205458-move_sites_out_of_platforms, 7.x-3.x, dev-588728-views-integration, dev-1403208-new_roles, dev-helmo-3.x authored by mig5: 
    #553348 #556548 - make it blindingly obvious that a separate db...
  • Commit 009a254 on 599758_edit_main_site, 640952_client_preview, dev-dns, dev-features, dev-headless_install, dev-log_directory, dev-migrate_aliases, dev-multiserver-install, dev-newsiteform, dev-nginx, dev-platform_management, dev-ports, dev-purgebackup, dev-relationships, dev-restore, dev-server_nodetype, dev-services, dev-site_rename, dev-ssl, dev_dns, prod-koumbit, ssl, dev-ssl-ip-allocation-refactor, dev-1205458-move_sites_out_of_platforms, 7.x-3.x, dev-588728-views-integration, dev-1403208-new_roles, dev-helmo-3.x authored by mig5:
    #553348 #556548 - make it blindingly obvious that a separate db...

  • Commit fa6e870 on 599758_edit_main_site, 640952_client_preview, dev-dns, dev-features, dev-headless_install, dev-log_directory, dev-migrate_aliases, dev-multiserver-install, dev-newsiteform, dev-nginx, dev-platform_management, dev-ports, dev-purgebackup, dev-relationships, dev-restore, dev-server_nodetype, dev-services, dev-site_rename, dev-ssl, dev_dns, prod-koumbit, ssl, dev-ssl-ip-allocation-refactor, dev-1205458-move_sites_out_of_platforms, 7.x-3.x, dev-588728-views-integration, dev-1403208-new_roles, dev-helmo-3.x authored by mig5: 
    #553348 #556548 - make it blindingly obvious that a separate db...
  • Commit 009a254 on 599758_edit_main_site, 640952_client_preview, dev-dns, dev-features, dev-headless_install, dev-log_directory, dev-migrate_aliases, dev-multiserver-install, dev-newsiteform, dev-nginx, dev-platform_management, dev-ports, dev-purgebackup, dev-relationships, dev-restore, dev-server_nodetype, dev-services, dev-site_rename, dev-ssl, dev_dns, prod-koumbit, ssl, dev-ssl-ip-allocation-refactor, dev-1205458-move_sites_out_of_platforms, 7.x-3.x, dev-588728-views-integration, dev-1403208-new_roles, dev-helmo-3.x authored by mig5:
    #553348 #556548 - make it blindingly obvious that a separate db...