Re: [development] install should optionally create the database
(Changed the topic to match the other because that one is better -- hope that doesn't screw up threading ) On 10/12/2006 1:03:20 AM, Kamal Mustafa (kamal.mustafa@gmail.com) wrote:
what I'm thinking about. it's does not worth the effort. everyone that need to set up a website should at least know how to create the db, either through the console or their admin cp. For those who don't know, we can just direct them to their control panel documentation or the rdbms documentation.
In another post, Dries said he thought it was worth it, so I guess we're outvoted. ;) I guess he's right that it would be nice to have the choice. If it would work on my system, I wouldn't mind having the db created just to make test sites easier. I'm curious, though, is there anyone out there on shared hosting that this would work for? Both A Small Orange and Site5 that I've been on have a special interface for creating databases. I can't even create a new one through SQLYog. Michelle
On Thu, October 12, 2006 8:02 am, Michelle Cox said:
(Changed the topic to match the other because that one is better -- hope that doesn't screw up threading )
On 10/12/2006 1:03:20 AM, Kamal Mustafa (kamal.mustafa@gmail.com) wrote:
what I'm thinking about. it's does not worth the effort. everyone that need to set up a website should at least know how to create the db, either through the console or their admin cp. For those who don't know, we can just direct them to their control panel documentation or the rdbms documentation.
In another post, Dries said he thought it was worth it, so I guess we're outvoted. ;)
I guess he's right that it would be nice to have the choice. If it would work on my system, I wouldn't mind having the db created just to make test sites easier. I'm curious, though, is there anyone out there on shared hosting that this would work for? Both A Small Orange and Site5 that I've been on have a special interface for creating databases. I can't even create a new one through SQLYog.
Michelle
While I agree that it would be nice, the use case for it is fairly small. If you're on most shared hosts, you don't have access to create databases from SQL. If you're on a host where you have access to create databases from SQL, then you should already be comfortable doing so in under 30 seconds (otherwise you shouldn't have that sort of access in the first place). Really, auto-database (and user!) creation is a convenience feature for power-admins. It sounds like a nice convenience, but it's a convenience aimed at the group that is in least need of it to start with. Also, that means that for the majority of users, it's an extra install step that they cannot complete. "Why does this database creation step fail? It's the first step, but now it's telling me to do some other thing? The first step of the installer doesn't work! Drupal sucks!" That's my main concern with adding a db-creation attempt. :-) --Larry Garfield
Also, that means that for the majority of users, it's an extra install step that they cannot complete. "Why does this database creation step fail? It's the first step, but now it's telling me to do some other thing? The first step of the installer doesn't work! Drupal sucks!"
That's my main concern with adding a db-creation attempt. :-)
well, your initial concern was with password submission. but anyway ... indeed, none of us wants to annoy a majority of users. so about "30 seconds" of further thought suggests that the wizard can stay the way it is for now, but we add a link under the database name field that says "don't have a database yet? click here and we'll try to create one for you." if we are to take drupal to the next level of popularity, we are going to have to put a priority on this sort of easy experience.
My thoughts on this thread: 1. Sending a DBA username and password over a cleartext channel is bad. Users would do it without reading warnings if the feature is available, and their passwords would get out. -1 to requiring a DBA password via Web form. 2. Once a user is created and given rights, MySQL will allow that user to create the database the user has rights to. Yes, you can grant rights to a non-existent database. If you GRANT ALL PRIVILEGES ON db_name.* to the user, those privileges include {CREATE,DROP} DATABASE on that database: ===== Session transcript ===== $ mysql -u root -p mysql> grant all privileges on drupal_db.* to drupal@localhost identified by 'super-secret password'; Query OK, 0 rows affected (0.16 sec) mysql> quit Bye $ mysql -u drupal -p mysql> show databases; Empty set (0.00 sec) mysql> create database drupal_db; Query OK, 1 row affected (0.00 sec) mysql> show databases; +-----------+ | Database | +-----------+ | drupal_db | +-----------+ 1 row in set (0.00 sec) ===== End transcript ===== 3. All that aside, WordPress' "Famous 5-Minute Install" involves manually creating a database and a user with rights to it; I however still think it'd be nice to give Drupal the (optional) ability to create its own database. -- pacem in terris / mir / shanti / salaam / heiwa Kevin R. Bullock
Kevin Bullock wrote:
My thoughts on this thread:
1. Sending a DBA username and password over a cleartext channel is bad. Users would do it without reading warnings if the feature is available, and their passwords would get out. -1 to requiring a DBA password via Web form.
Let's avoid submitting -1 or +1 on things that haven't even been proposed. Thats just going to attract more mindless votes and discussion and lead the conversation to nowhereland. You are the first person to mention *requiring* a DBA password. Later in this post you approve of optionally letting the installer create a DB. Would be more productive to start the post with this opinion. Why start so negative? I think this is just the urge to debate, but IMO is not so helpful on a 1000 person mailing list such as this. I will mellow out now.
Replies below, somewhat re-ordered. Moshe Weitzman wrote:
Later in this post you approve of optionally letting the installer create a DB. Would be more productive to start the post with this opinion. Why start so negative?
Perhaps I've overemphasized this; I apologize. I did however start with this point deliberately, because it was the most important one I was trying to make, and here's why: Even allowing the *option* of the DB-root-at-localhost password to fly across a plaintext channel is, in my estimation, a security breach. I.e., if Drupal implemented the create-db-in-install feature that way, I wouldn't allow my users to install Drupal without first patching that feature out.</rant> Now, I also hoped to point out that there is a way of letting the installer create the database *without* using a DBA password, at least on MySQL. Does this also extend to PostgreSQL? Would it work on (at least some) shared-host providers?
Let's avoid submitting -1 or +1 on things that haven't even been proposed.
Sorry, consider that '-1' stricken from the record.
You are the first person to mention *requiring* a DBA password.
Well, by that I was referring to a previous poster's suggestion that seemed to require a DBA password to optionally create the database from the installer. I didn't mean to say that the *installer* would *require* a DBA password to work. -- pacem in terris / mir / shanti / salaam / heiwa Kevin R. Bullock
My two bits.... I've installed various website systems (BBS, blogs, CMSs) over the years, and while a lot of them have been easier than installing Drupal, none that I recall had an on-screen database creation feature. If we're talking making Drupal friendlier to the average n00b user with limited dev exp, my own feeling is that having the user first create a db using CPanel (which is VERY easy) or other web administration interface (even Webmin isn't rocket science) does not seem to be too much to ask. The downside of a major site compromise due to an install by an ignorant user seems to be just too great a risk. An alternative approach might be to offer the on-screen db creation feature only if there's a secure web connection detected OR (2) the user comments out or edits the easy-to-find line in the installer code (thus demonstrating some knowledge and responsibility for doing it), which might be useful for local installs where such in-the-clear password concerns are not an issue. What would be even better, in addition, would be the ability to designate the db user to actually USE the database, and prompt for sql superuser username/pw only for the purposes of db creation (and thus setting up the site using a db user with more secure, appropriate permissions from then on out). (I.e., the db user used to create the database is not saved in settings.php.) Laura
On 10/12/06, Laura Scott <laura@pingv.com> wrote:
I've installed various website systems (BBS, blogs, CMSs) over the years, and while a lot of them have been easier than installing Drupal, none that I recall had an on-screen database creation feature.
Xaraya does;)
On 10/12/06, John Cox <john.cox@wyome.com> wrote:
On 10/12/06, Laura Scott <laura@pingv.com> wrote:
I've installed various website systems (BBS, blogs, CMSs) over the years, and while a lot of them have been easier than installing Drupal, none that I recall had an on-screen database creation feature.
Xaraya does;)
There are actually lots, so let's not go down this route. I suspect that having security as a priority goal would narrow the list down considerably. e.g. SugarCRM has the *option* to put in a user/pass with create rights. As others have said, this is not something that is going to get in for 5.0, so it's a long way away AND nothing that debate alone is going to help get in. Let's remember as well that many of these threads are started by relative newcomers who often times don't look at the past or are unaware of it (Kieran's posting / info about CS is one example). Getting dragged into these long mudpits of discussion threads isn't useful. Let's try and give useful pointers to why or why not that decision was made, mention that it a) should be in the issue tracker and b) isn't going to get into core until the 6.0 branch. -- Boris Mann
----- Original Message ----- From: "Boris Mann" <boris@bryght.com> To: <development@drupal.org> Sent: Friday, October 13, 2006 5:39 AM Subject: Re: [development] install should optionally create the database
On 10/12/06, John Cox <john.cox@wyome.com> wrote:
On 10/12/06, Laura Scott <laura@pingv.com> wrote:
I've installed various website systems (BBS, blogs, CMSs) over the years, and while a lot of them have been easier than installing Drupal, none that I recall had an on-screen database creation feature.
Xaraya does;)
There are actually lots, so let's not go down this route. I suspect that having security as a priority goal would narrow the list down considerably. e.g. SugarCRM has the *option* to put in a user/pass with create rights.
As others have said, this is not something that is going to get in for 5.0, so it's a long way away AND nothing that debate alone is going to help get in.
Let's remember as well that many of these threads are started by relative newcomers who often times don't look at the past or are unaware of it (Kieran's posting / info about CS is one example).
Getting dragged into these long mudpits of discussion threads isn't useful.
Let's try and give useful pointers to why or why not that decision was made, mention that it a) should be in the issue tracker and b) isn't going to get into core until the 6.0 branch.
-- Boris Mann
Agree. The core dev must understand that many repeating thread come from their self! why not give us a clear view of: 1. roadmap, and 2. what drupal will support, and 3. what drupal won't support i.e: I come from PHPNuke, Mambo and Joomla. Most of my clients agree that Drupal is better and powefull but more difficult to install and administer. so, as new dev we only can give suggestion while we try to learn Drupal as deep as possible (and take longer time because there is no comprehensive handbook for creating complex module, the example in the handbook is too simple, I need a handbook like VB .Net Manual Book). now, when core dev tell us (as a new developer) what is Drupal: roadmap, what will support and what won't support??? if Drupal official site say: Drupal will not support creating database during installation, please read this discussion. Then, no one will ask this again over and over. This will save our time (as new dev), save core dev time and save much email space.
Op donderdag 12 oktober 2006 23:39, schreef Boris Mann:
Let's remember as well that many of these threads are started by relative newcomers who often times don't look at the past or are unaware of it (Kieran's posting / info about CS is one example).
I think we, The bearded Drupalleers should value such input much more. «There are reasons that it is like it is» is exactly that: a "reason". The "reason" that something behaves like crap, or a good "reason" that some bug is not fixed, does not mean it doesn't behave like crap or is not a bug. Lets welcome input lke this. Value people who don't wear Drupal-eyeflaps yet. People whom are not pre-occupied. People who can give feedback without the pollution of knowing the history or reasons. People who touch problematic areas in Drupal without being afraid of being told 'then go and fix it'. Bèr -- | Bèr Kessels | webschuur.com | Drupal, Joomla and Ruby on Rails web development | | Jabber & Google Talk: ber@jabber.webschuur.com | | http://bler.webschuur.com | http://www.webschuur.com |
Lets welcome input lke this. Value people who don't wear Drupal- eyeflaps yet. People whom are not pre-occupied. People who can give feedback without the pollution of knowing the history or reasons. People who touch problematic areas in Drupal without being afraid of being told 'then go and fix it'.
You are absolutely right. Now that I think of the time when I began with Drupal. I said things like "the menu system is crap" because I didn't know how it worked and used taxonomy_menu instead. Because I thought "categories" is Drupal's menu system. If you read things like "installation is bad" or "administration sucks" or "foo is overly complicated", it's mostly not because it is really bad but that it is not so easy that it can be understood at the first glance. And there we need to improve. We can do this either by writing *very* clear documentation (or by providing other help in the form of wizards, agents or task oriented menus like we have partially now) or we can really try to make the workflow simpler by figuring out what a user would expect how it should work when he has absolutely no idea of the actual/current workflow. Konstantin
On 10/13/06, Bèr Kessels <ber@webschuur.com> wrote:
Op donderdag 12 oktober 2006 23:39, schreef Boris Mann:
Let's remember as well that many of these threads are started by relative newcomers who often times don't look at the past or are unaware of it (Kieran's posting / info about CS is one example).
I think we, The bearded Drupalleers should value such input much more.
My point was to not get drawn into long back and forths when many of these issues have been discussed before -- point to existing areas of discussion and clarification, and start with that context in mind, not re-hashing stuff that has gone through before. AND It's not getting in until Drupal 6, so go work on bug fixing a great 5.0 release, and maybe get a few more usability fixes in. -- Boris Mann
On Oct 13, 2006, at 9:25 AM, Boris Mann wrote:
My point was to not get drawn into long back and forths when many of these issues have been discussed before -- point to existing areas of discussion and clarification, and start with that context in mind, not re-hashing stuff that has gone through before.
I offer this as an observation, not an invitation to debate.... It would seem to me that part of valuing newer folks' input would involve some new discussion of old-yet-as-yet-unresolved topics. This is because new insights, ideas and suggestions are always possible. Also, inviting newer developers to engage in old ideas might lead to yet new ideas approaches by anyone in the community. I would add that norms change, markets change, things change. Any community values the past, but lives in the present. That's all the more true in email lists. Yes, there's an archive of this list that's searchable, but that doesn't mean that such discussions are easily findable. If a subject has been resolved, that's one thing. But if it's unresolved, then quashing new rounds of discussion tells the newer folks (and some of the older ones, too) that their input has no value. For my part, I find it quite easy to skip messages that don't interest me. Also, for my part, on this particular thread, I was simply offering some comparative experiences, since what other systems do will most definitely affect people's expectations of what an "easy installation" system will do. I was not trying to suggest that it's the way things MUST be done, or get into any "back and forth" about it. And the same is true for this post here. ;) Laura
1. Sending a DBA username and password over a cleartext channel is bad. Users would do it without reading warnings if the feature is available, and their passwords would get out. -1 to requiring a DBA password via Web form.
I'm still in favor of providing a DB-rights escalation feature. Truly secure hosting services provide at least 2 DB usernames, one for web service usage without database creation (and often without table creation) privileges, and another for administration with full rights. I really don't want my Drupal website creating tables with the normal user rights it has -- which means I cannot install any modules which create tables without defeating my provider's security arrangements. Escalated privs at module install time would be the perfect solution. While some users would no doubt ignore even the most obtrusive of warnings, it *is* after all their choice to make such a mistake. We can do a number of things to mitigate the problem. If protocol is HTTPS (i.e. encrypted), we can display no warnings. We can also use some sort of Javascript-based encryption to send the username and password over the wire as ciphertext. Still, even if some mad cracker managed to sniff the DBA username and password off the wire, they would still have to find their way to the database itself. After all, I can destroy your non-SSL Drupal website by sniffing your admin username and password, without needing access to the database directly. Thus, just because some few people will foolishly ignore the warnings (and probably still be just fine because the likelihood of their packets being sniffed is exceedingly low anyway), does not mean we should avoid implementing features that many people would make good use of in a more secure fashion. ..chrisxj
As clarification for those not involved in past DB priv escalation discussions, such a feature might, for example, store the DBA credentials in settings.php as well, and only use them at module install time. Or it might prompt the admin for the account and/or password, or both -- depending on implementation.
participants (11)
-
Boris Mann -
Bèr Kessels -
Chris Johnson -
Drupal Indonesia -
John Cox -
Kevin Bullock -
Konstantin Käfer -
Larry Garfield -
Laura Scott -
Michelle Cox -
Moshe Weitzman