Opened 8 years ago

Last modified 6 years ago

#3658 assigned Bug/Something is broken

control panel webapp setup for drupal seems one step too short

Reported by: https://id.mayfirst.org/dkg Owned by: https://id.mayfirst.org/jamie
Priority: Low Component: Tech
Keywords: red drupal Cc:
Sensitive: no

Description

Doing the control panel setup of the drupal webapp leaves me needing to manually copy/paste the database credentials into the initial drupal configuration.

it would be nice to have this step itself be automated, so users wouldn't need to do it directly.

Change History (12)

comment:1 Changed 8 years ago by https://id.mayfirst.org/jamie

Yes - that would be useful, but it would require a fundamental change in the way the control panel works, and I'm not sure if it's worth it or not.

When you create a MySQL username, the web-interface for the control panel stores the MySQL encrypted version of the password in the Red Control panel database. The node interface (on the target server) accesses the Red control panel database and copies that encrypted password directly into the node's MySQL database user table. This elegantly prevents the node from every having access to the plain text password. In fact, the plain text password is never stored anywhere by Red.

I'm not sure how to automate the remaining step of the Drupal installation without given the node access to the plain text password.

Otherwise, I think there are some drush tools that could be used to complete the installation in a more automated fashion.

Thoughts?

jamie

comment:2 Changed 8 years ago by https://id.mayfirst.org/dkg

well, the node does eventually get full access to the plaintext password, because the user stores it in settings.php.

so if the concern is "i don't want the node to have access to the plaintext password", then something is amiss already.

we're just making the user take extra steps to get there.

otoh, since this is all on the same machine, we could avoid passwprds entirely by using a real RDBMS capable of using SO_PEERCRED for connections over a UNIX-domain socket (e.g. postgres)

comment:3 follow-up: Changed 8 years ago by https://id.mayfirst.org/jamie

The node gets access to the password one way or another if the user is making a web application. I'm not sure if there's a common use case of MySQL in which this is not the case, but for the record not all databases are used by Drupal.

I think the concern is more accurately described as: I don't want to store the password in plain text in any more locations than I have to.

We'd have to store the password in plain text in the Red database, at least long enough for the node to read it and do something with it. If we permanently stored the password in plain text in the mysql user record when the MySQL user was created, that would be the most flexible, but least secure.

Alternatively, the Web App process could capture the password being used for the MySLQ user and store it in the web app record, which could later be deleted (there's no system for deleting or modifying user data in place right now...).

Not sure how else this could be done...

jamie

comment:4 in reply to: ↑ 3 Changed 8 years ago by https://id.mayfirst.org/dkg

Replying to https://id.mayfirst.org/jamie:

The node gets access to the password one way or another if the user is making a web application. I'm not sure if there's a common use case of MySQL in which this is not the case, but for the record not all databases are used by Drupal.

right, which is why this ticket is just about webapp (drupal) setup.

Alternatively, the Web App process could capture the password being used for the MySQL user and store it in the web app record, which could later be deleted (there's no system for deleting or modifying user data in place right now...).

I note that we're no longer storing a ~/.my.cnf on db creation. is there a way to do that, and then get drupal config to rely on that somehow?

Not sure how else this could be done...

see my note above about postgres not needing passwords at all for local connections...

comment:5 follow-up: Changed 8 years ago by https://id.mayfirst.org/jamie

I purposefully named the MySQL user and database services with MySQL so a postgres version could exist side by side - allowing us to offer both postgres and MySQL :). However, I'm not sure if this will solve the problem because in most cases even I would recommend that people use MySQL with Drupal to avoid a lifetime of bug reports for 3rd party modules.

We could try to automate the creation of ~/.my.cnf files but then we'd have to ask the user in which user account's home directory to create the file (or we could simply store it in a pre-defined hidden directory, like in the .red directory).

jamie

comment:6 in reply to: ↑ 5 Changed 8 years ago by https://id.mayfirst.org/dkg

Replying to https://id.mayfirst.org/jamie:

I purposefully named the MySQL user and database services with MySQL so a postgres version could exist side by side - allowing us to offer both postgres and MySQL :). However, I'm not sure if this will solve the problem because in most cases even I would recommend that people use MySQL with Drupal to avoid a lifetime of bug reports for 3rd party modules.

i'd be happy to guinea-pig my way through a postgres drupal installation (maybe even a postgres civicrm installation, if someone holds my hand for the civi bits and can actually tell me when things are breaking unusually) for mfpl.

We could try to automate the creation of ~/.my.cnf files but then we'd have to ask the user in which user account's home directory to create the file (or we could simply store it in a pre-defined hidden directory, like in the .red directory).

would this solve your concern? would drupal be able to take advantage of it?

comment:7 Changed 8 years ago by https://id.mayfirst.org/josue

hey dkg,

there is someone working on civi and postgres. check out http://civicrm.org/blogs/dhruvahuja/attempt-postgresql-made

happy to help with the civi bits...

comment:8 Changed 8 years ago by https://id.mayfirst.org/jamie

Here are the changes that I think we'd need in order to complete the last step of the Drupal installation:

  • Change control panel to store the MySQL password in clear text
  • Develop a new mechanism to obscure this password after the node has accessed it
  • Store the MySQL user/password in clear text on the node in a hidden .my.cnf file (named uniquely - maybe .my.username.cnf)
  • Add a new field to the Web App control panel asking which email address should be assigned to the first user. Is this field appropriate? What if we add a new web app that doesn't require an email address?
  • Figure out how we are going to communicate the Drupal user's password to the Control panel user. Rely on email? Do we have to store another password in clear text for the control panel web app record?
  • Stay on top of Drush/Drupal developments to ensure that our installation method continues to work as these two programs develop.

I agree with the end goal... but as you can see, for the initial release I chose the simpler path of dumping the user into the Drupal installation screen to avoid making mistakes with any of these fairly tough decisions.

As for postgres - I think adding postgres support to the control panel would be great. I imagine it would be even simpler than the MySQL code since you'd just need to create a Postgres Database service (no need for a Postgres User service).

If this were stable, then we could add another field to the Web App service - pick either MySQL or Postgres as the database backend (or none in the event we add a web app that doesn't require a database - or Sqlite?).

jamie

comment:9 Changed 8 years ago by https://id.mayfirst.org/dkg

I've opened #3667 to divert the postgres discussion to its own topic -- let's keep this one about the drupal setup.

Jamie, i entirely understand your implementation decision, and i think you did the right thing. i'm just following up on the next steps for improvement, because no good deed goes unpunished ;)

It sounds to me like any given webapp is likely to have some slightly different fields required for setup. drupal wants an e-mail address, password, and username for the first user; other webapps might want a choice of authentication regime or other piece of configuration. it seems clear to me that we'd want this to be an extensible choice for different webapps.

As for the initial authentication for drupal initially, what about these default choices:

  • we choose the name admin for user 1 by default
  • we set their e-mail address to the e-mail address of the control panel user instantiating the site by default (so they don't need to edit it)
  • we enabled OpenID login on the drupal install by default
  • if the control panel is being operated by user foo, we bind https://id.mayfirst.org/foo to the admin account

Users who want something different can make changes after the initial setup, and we wouldn't need to propagate any additional shared secrets this way.

comment:10 Changed 8 years ago by https://id.mayfirst.org/jamie

Hm - OpenID is a really great and elegant idea that I hadn't thought of.

The email is still a problem - since a user account for the control panel is not always linked to an email address. We could take the contact address for the member though. And, with the OpenID trick, the email address is less important and could be changed later...

jamie

comment:11 Changed 6 years ago by https://id.mayfirst.org/ross

  • Status changed from new to assigned

comment:12 Changed 6 years ago by https://id.mayfirst.org/jamie

  • Priority changed from Medium to Low

Please login to add comments to this ticket.

Note: See TracTickets for help on using tickets.