By bryansd on
As most of you are aware, there are issues with installing Drupal 4.6.x on hosts that have not granted users with the ability to LOCK TABLES in MySQL ( http://drupal.org/node/1190 ). There was some talk that this issue may be addressed in a future release of Drupal (at the very least giving you alternatives to using LOCK TABLES). Does anyone know if Drupal 4.7 might provide some work arounds? I'm of course aware of "unofficial" work arounds by changing the code, but I'd rather not have to do this in future builds.
Thanks,
Bryan
Comments
No, I don't think this has
No, I don't think this has caught enough support among developers yet and I don't know if the proposed solution is really a solution. You should check if your host allows you to create temporary tables, the 4.7 search module will require this.
--
Drupal services
My Drupal services
--
Drupal services
My Drupal services
I suppose this would be a
I suppose this would be a good time to test a CVS of Drupal and see how well it works with my current host. Is the ability to create temporary tables also tied in with the ability to lock tables? Or are these two separate permissions that must be granted through MySQL?
A test would be very
A test would be very welcome, but wait a few days, there is a bug in the temporary table code. I think both are separate permissions but chances are that you won't get the temp table permission if you don't have the lock table one. The onle thing I can recommend in this case is to switch hosters.
--
Drupal services
My Drupal services
--
Drupal services
My Drupal services
Wow, it looks by the time
Wow, it looks by the time 4.7 is out...the requirements of LOCK TABLES and CREATE TEMPORARY TABLES is really going to cause some headaches. I really wish the developers weren't so eager to use MySQL server admin privileges as the only solution. Below is a reply my host provider sent basically saying such privileges will not be granted. While I'm arguing that everything will be fine with Drupal, I have to admit from a sys admin perspective, it's hard to really argue "no harm done" on shared hosting servers. Anyway, I'm always open for workarounds.
Well, the developers are
Well, the developers are eager to fix problems. Current Drupal search has problems as many threads here on drupal.org can testify for. The solution to those problems involves using temporary tables. As long as you don't want to use search, you'll be fine without the priviledge. You can always use the trip_search module.
In any case, the mentioned bug has been fixed, so we'd appreciate some testing.
--
Drupal services
My Drupal services
--
Drupal services
My Drupal services
I'm not questioning the
I'm not questioning the intentions of the developers. However, I am maybe questioning the judgement of applying the use of database functions that are known to cause problems with a number of host providers. Let's be certain here, I'm not trying to bait and flame here...I'm just trying to express my perspective here in hopes of improving Drupal.
Most IT people that are worth their salt in security do practice the policy of "least privilege". You only give users the minimum of what they need. For example, at my place of work I am "the" guy that decides who gets what user rights. While I may have super user/root/administrative rights, when I log into the system with my own account...I have no more rights into the network than are youngest intern. I don't need the admin privileges for day to day operations, it's that simple. Only when I need the admin privileges do I ever log into the network with an account that has super user rights.
Now while I have the ability to grant Drupal access to server admin privileges to MySQL databases at work, I don't have that authority when I'm using someone elses servers (for my own side business/hobbies). To be honest, I really think the host providers are doing their job correctly and not granting these rights to shared hosting accounts. Whether the programmers know it or not, they're pushing Drupal more toward dedicated servers and less toward the "average joe" with hosting providers may or may not grant their users server level privileges to MySQL.
Once again, I am in awe of the developers and the talents the developers of Drupal have shown. This is an amazing piece of software. I just think that Drupal would be a much friendly, if this LOCK TABLES issue wasn't an issue.
-Bryan
Developers don't usually
Developers don't usually think "how do I make my software friendly" they think "how can I make software that gets stuff done". We did not introduce the locking requirement without discussion and the result of the discussion was that it was the most stable solution.
This happened at a time when most people ran mysql 3 and where locking was not a special permission. The problem - for some people - only became apparent when people started moving to mysql 4. Apparently some hosters did not read the instructions and decided to take this feature away from their users by not explicitly granting it.
I think we should rather make a list of cluefull hosters that are known to provide the neccessary priviledges for running Drupal. It is not like we'd require any special plugins after all.
--
Drupal services
My Drupal services
--
Drupal services
My Drupal services
Yea...but doesn't that sound
Yea...but doesn't that sound like a "they're wrong, we're right" response. I'm telling you...some of the hosters that you imply are "clueless" are not granting those priviledges for very cluefull reasons. Why do you think the MySQL folks don't grant this right in the first place? Are they clueless too? This is an issue for MySQL 5 too...
http://dev.mysql.com/doc/refman/5.0/en/privileges-provided.html
Maybe if we can convince the folks at MySQL to grant the rights to the "more common user"...things would be different.
The clueless part was about
The clueless part was about taking something away from their users which they previously had. I have no idea why not allowing table locking would be a good idea. Your link does not provide any info on that.
--
Drupal services
My Drupal services
--
Drupal services
My Drupal services
Now, defending the hosts is
Now, defending the hosts is nice.
How about defending the customers?
KnowProSE.com is presently offline because MySQL errors cropped up and slammed the CPU on their server, or so they claim. They demanded that I remove 'offending code' (Drupal), and gave me a dump of some insertion of data into the EVENTs table.
I have a strong feeling that the database blew up because of the lack of LOCK and UNLOCK. The Events table isn't an addon, it's STABLE and works quite well with LOCK and UNLOCK.
Meanwhile, my site has been down for going on 3 days, and they won't allow me to login to my database. About 10,000 nodes.
I've suggested to them to do a full backup of the database and toss it on FTP for me, but they keep telling me that the advanced team is doing some 'investigation'.
LOCK and UNLOCK of tables is a function which is necessary to avoid multiple writes to the same table concurrently. GoDaddy's answer has been a Virtual server from them, but with their track record right now...
Here's the thing. GoDaddy.com hasn't been open about what ability the economy hosting has - everything I have learned I have learned the hard way with them -- including the present situation. Can you, in good conscience, tell me that not being able to access a database at all is good? There is NO code on my site right now - all removed by their demand - and MySQL is still not letting me log in through their control panel.
Sure, defend the hosts. But defending customers seems somewhat important to me.
KnowProSE.com
Tired of Host Providers
Hey Taran, I wasn't so much defending the host as much as understanding the host's point of view. A couple weeks ago, after my posts, I had a long discussion with GoDaddy. As a reseller of their services I thought I would be able to make some headway and get past their first level of technical support. No such luck...they're system administrators are pretty well protected from callers like you and me. Luckily the support person I did get ahold of didn't mind "bothering" the database admin. Basically, what he was told is that they're not worried so much about granting LOCK TABLES to use with Drupal, but concerned how granting the priviledge may impact other software that may also be used. Whatever.
As I mentioned in a similar post ( http://drupal.org/node/39169 ), I've decided to go virtual dedicated. I'm tired of going to various host providers and find certain Web server features not available. Drupal 4.7's search module will require the right to create temporary tables (another non-default that some host-providers may or may not grant). To me, the writing is on the wall...either find someone you completely trust to give you the access you need or manage your own server.
In the end, I do think this may be just as much of an issue with MySQL. I've heard from a number of SQL database purists that argue MySQL has a different take on how things should be done. They argue that PostGreSQL may be a better database than MySQL to support a CMS such as Drupal. I really don't know. I have seen some talk that MySQL 5 may offer some new methods for not needing LOCK/UNLOCK. Does anyone from the Drupal community know if that is true?
-Bryan
Well, be careful what you resell.
I had it out with GoDaddy after they accused a standard install of Drupal of overloading their server... Then locked out my account so that I couldn't access the MySQL database, saying that they would not give me access unless the 'offending code' was removed.
The offending code was Drupal. 3 days later... I got access to my database.
That and the Lock and Unlock of tables caused me to move to BlueHost, where I don't have any of the problems I had with GoDaddy. I lost money on GoDaddy for the hosting I had paid up for the year with GoDaddy on OpenDepth.com, but I saw that as an acceptable loss for the poor service, and the disinterest in the customer.
LOCK and UNLOCK of tables can be managed quite well - other hosts allow it.
I don't know you, but if you're reselling GoDaddy, I don't like your product because of the above and a bit more. I demand quality. GoDaddy failed the litmus test. But that's just my experience... maybe you're lucky.
KnowProSE.com
eAsylum.net
Wow, it looks by the time
Hm. I think you are right. I don't know any of the cheap shared hosts in Denmark that grants these rights.. Long time ago, I pursuaded my host to grant me LOCK TABLES, and I've asked support for CREATE TEMPORARY TABLES rights as well, but havent got any reply yet.
These requirements, along with the SAFE_MODE = OFF requirements during language file import (http://drupal.org/node/41515) - denies many potential users of giving drupal a try. I've been evaluating drupal for years now, and I love what I might do with it - if I'll ever be able to use it ;-)
I really hope, that there eventually will be a "limitedhost" option for the rest of us. A way to configure drupal to use alternate but more compatible ways of these few tasks that has these special requirements.
Kind regards
Bjarne
---
Testing drupal 4.7 beta 2 at http://oldrup.dk/drupaltest/
Gallery needs PHP safe_mode off
Just to make a little comparison, Drupal requirements may not be so strong as this. I join Killes in wondering how harmfull is it for host to disallow creation of temporary tables and locks ? Just because it's not in default profile ?
I remember a bunch of years ago, trying to set up a Gallery powered website and find no solution because it definitively needs to have php safe_mode off. This is also very hard to find hosters with such rights. I can imagine the security feeling such an option "safe_mode" can give to hoster admin ;)
Despite such restrictions, it became a world acclaiming script to manage your pictures (and it now runs Drupal).
So I totally agree that this is a big issue that can lead to an hosting change and that's a big deal...