Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Aegir forces the Drupal superuser (uid 1) to be called 'admin' in it's install engine. We prefer to call this user 'root' as it more accurately depicts that users privileges.
Because of the ordering of the install engine, even if we change this in our install profiles it's still changed by Aegir to be 'admin'.
It should be really easy to pass some option from the frontend to the backend on install so that this can be configured. The client email is passed in this way.
| Comment | File | Size | Author |
|---|---|---|---|
| #9 | provision-admin_username_override-1201174-9.patch | 2.84 KB | ergonlogic |
| #4 | provision-admin_username_override-1201174-4.patch | 2.59 KB | ergonlogic |
Comments
Comment #1
Anonymous (not verified) commentedhehehe...
So I once co-wrote with aaronbauman, and committed, a patch to allow this to be configurable from the frontend. It was veto'd as being excessive for Aegir's purposes, so it was reverted
See #699250: Support for admin_user option in order to set user 1 name other than "admin" and #697954: user 1 name is hardcoded. allow provisioners to specify name for admin user.
I still think it's worthwhile: but perhaps the original approach (adding a field to the site node form) was too much. Maybe there is a more elegant way to achieve this from an API-perspective: e.g allowing the ability for a contrib or custom addon at least to the backend to override it. Not sure.
Comment #2
steven jones commentedSo, I've got a working contrib solution for this, with the only drawback that the email about a new site being created always has the 'admin' username.
Would be good to get #697954: user 1 name is hardcoded. allow provisioners to specify name for admin user. back in, and then we can play in contrib :)
Comment #3
steven jones commentedComment #4
ergonlogicPatch attached along the lines of #697954: user 1 name is hardcoded. allow provisioners to specify name for admin user..
This allow an override as simply as creating a /var/aegir/.drushrc.php that includes:
Comment #5
anarcat commentedCouldn't we factor this out of the version-specific engines?
Comment #6
ergonlogicYou mean move the define to includes/install.inc?
Comment #7
anarcat commentedyes.
Comment #8
ergonlogicActually, the 'includes/install.inc' in question is the one on the site. Moving it up to install.provision.inc didn't work...
Comment #9
ergonlogicAlright, so this is weird. I created an install.inc wherein I put our define. Then I included it like so in install_6.inc:
What I find strange here is that the first require_once, is including the file from the platform, whereas the second one is including it from /var/aegir/.drush/provision/platform/drupal/. Is this expected behaviour?
Comment #10
anarcat commentedi have no idea how this works. the engine code is weird. this is why i was so vague. :)
Comment #11
ergonlogicFixed in d0623c3.
I documented the weirdness with a @todo to figure it out :)
I also added validation of the UID1 name in Drupal 7 install.
Comment #12
ergonlogicI documented how to override UID1 username in example.drushrc.php
Also, similar treatment of email addresses during install was addressed in #2038279: Verify "valid email address" during the hostmaster-install script?