IRM's and MySQL - is this allowed?

[LeafWind]

Hey FQuesties,

I'm considering a couple of smallish website projects to begin over the next few months, and am considering using a little bit of MySQL for each of them.

I know from earlier posts that FQ frowns on using the same MySQL database from different full domain accounts, how does this apply to IRM's?[nbsp][nbsp]If I wanted each of these projects to have its own domain name, would I need to get multiple gold accounts, or would one gold account with IRM's be okay?

Thanks!

Bekariso
------------------
http://LeafWind.com[nbsp][nbsp]
Growing web sites that thrive in the winds of change.

[Terra]

It's 6 MySQL Databases per 1 Full domain/package...

The IRM(s)/IRO(s) are not included in that...

I have started watching the MySQL server very closely in efforts to enforce the MySQL usage guidelines...

At present, MySQL only utilizes 'User/Password' authentication allowing multiple (unauthorized) use... :([nbsp][nbsp]Part of the ZenForce project is embedding my own customizations into the MySQL server to do backtrace authentication...

Bit of logic:
if unathorized access:
[nbsp][nbsp]backtrace and trap offending domain
[nbsp][nbsp]set timeout of 86400 sec on domain
[nbsp][nbsp]if 5 accesses within 86400 sec:
[nbsp][nbsp][nbsp][nbsp]email warning to siteowner
[nbsp][nbsp][nbsp][nbsp]pull trigger
[nbsp][nbsp]fi
fi
::check timeouts::
if site owner complies:
[nbsp][nbsp]release timeout warning
[nbsp][nbsp]release trigger
else
[nbsp][nbsp]disable MySQL account
fi
::suspends::
if domain == 2 disables:
[nbsp][nbsp]disable domain account
elif domain == 3 disables:
[nbsp][nbsp]terminate domain account
fi

We have to clamp down tightly on server resource abuse as I now have to justify the building of multiple DAS::MySQL servers, which is pretty expensive...

--
Terra
--Now going from the Pseudo code to something that actually works right is another story--
FutureQuest

[Charles Capps]

Er, would this impact subdomains?[nbsp][nbsp](Such as flare.solareclipse.net is solareclipse.net/flare)[nbsp][nbsp]If so, can there be exceptions made?[nbsp][nbsp](At additional cost or not.)

[Stephen]

Hmmm. How would you enforce that?

Obviously, if an FQ subdomain owner wanted to, they could recode all their subdomain pages (except the top one) to appear on their primary account, and thereby have 'legitimate' access to their database.

Although I doubt many of us would actually want to do that, I guess the determining factor will be the forthcoming extra cost associated with MySQL usage and subdomains.

Stephen
--not a subdomain MySQL user. so far.

[Terra]

Probably at additional cost, but that is yet to be determined...

I am monitoring the MySQL usage closely watching for trends in resources used and will guage our pricing from that...

--
Terra
--The numbers live within history--
FutureQuest

[LeafWind]

Thanks for the reply. It helps with the mental budgeting!

I too would be interested in knowing the price for MySQL access from subdomains, as Charles posted. Please keep us up to date.

Bekariso


------------------
http://LeafWind.com[nbsp][nbsp]
Growing web sites that thrive in the winds of change.

[Storm Shadow]

I searched and ran across this topic but am still unclear as to what the exact rules are...

Can IROs added onto a Gold account use the same MySQL database as the main account is using?[nbsp][nbsp]For example, I want mydomain.com and mydomain.net to be completely seamless and use the same PHP interface/database backend.[nbsp][nbsp]Is this legal?

Second scenario: can a Gold account's IRM use one of the other 5 databases available on the full account?[nbsp][nbsp]Or how about the same db?

Finally, I'm not sure about the language of:
"It's 1 MySQL Database per 1 Full domain/package...
The IRM(s)/IRO(s) are not included in that..."

Does this mean that one or more of the 6 databases assigned with a Gold account can be used from your other full accounts as long as there is not more than one account using each database?

Thanks in advance,
SS

[Terra]

To answer your specific question: IRM accounts are not allowed to access the primary domains databases...

6 Databases are provided for organizational ability only, and not for sharing with other domains except in a special situation explained below...

acme.com == Gold
binford.com == IRM of acme.com

acme.com is allowed Database Access
binford.com is not allowed, and will need to be upgraded to a Gold package...

We are having to enforce this tightly as we are seeing more accounts sign up, set up 5 IRM domains and running heavy vBulletin forums that is cutting the operational capacity of our DAS::MySQL engines by half...[nbsp][nbsp]Now we have the resources of 6 Gold packages with the paid resources of 1 Gold package and doubling the number of engines to satisfy the voracious appetite that these new resource hungry programs demand...

I am also having an issue with *creative* usage of cross domain PHP calls that use another domain as a sort of proxy, but does not access the MySQL server directly...[nbsp][nbsp]This is also considered in violation...

Obviously this does not make good survival sense...[nbsp][nbsp]It cuts the revenues required to purchase more equipment and the salaries of FutureQuest personnel required to provide quality support to the site owners...

I monitor the MySQL usage and will scan IRM/Basic/Silver domains for MySQL directives...[nbsp][nbsp]If a domain is found in violation, the following escalation takes place...
1) Warning email is sent to Cease and Desist unauthorized access
2) MySQL access will be terminated permanently with no recourse
3) All FutureQuest accounts by the domain holder in violation will be terminated from our service...

However, we do have a happy medium to where 2 or more Gold accounts can use the same MySQL database via Cross-Connects...[nbsp][nbsp]The cost of setting this up is $25.00 per Cross-Connect...

In Summation:
Gold and Platinum packages are authorized for MySQL access.
**IRO(s) of Gold Packages are authorized.
All other packages are not authorized.

**Exclusion: IRO's must show the same content as the Primary domain...[nbsp][nbsp]Specifically, you cannot have a dynamic site where a front end PHP/CGI/etc program retrieves different content from the database depending on Domain Name...

I hope this clears the confusion...

--
Terra
--I really do believe that static html pages are nearing extinction which dawns a new age of strict resource management--
FutureQuest

<Edit: Added authorization for IRO accounts, with an exclusion>

[This message has been edited by ccTech (edited 10-28-00@06:53 am)]

[Storm Shadow]

Thanks for the clarification.[nbsp][nbsp]All the above makes sense, especially in the case of 5 IRMs running like they're full Gold packages, bogging down the MySQL server.

I guess my only quibble is on the question of an IRO which is used clearly only to solidify domain name recognition.[nbsp][nbsp]FQ's IRO description has something to that extent talking about how you can use an IRO so your audience can type either mydomain.com, mydomain.net, or mydomain.org and go the same website seamlessly.[nbsp][nbsp]In a case like this, where it's clearly just one set of coded PHP pages that serve up exactly the same content, it'd be difficult to run a PHP/MySQL based site without violating the rules, yet it seems like there's no intended abuse here--just covering your bases as far as audience recognition of your name.

I guess you could have the .net and .org domain names redirect to the .com domain, but this is a solution that sort of kills the seamless aspect of having an IRO.

Anyone out there have any more elegant solutions?

Again, thanks for the info.
-SS

[Terra]

After consideration of your feedback, we have decided to allow Gold and Platinum IRO's to have database access privileges of the primary domain they overlay...

What I have done is edit the message, posted 10-27-00 06:29 AM, above to include IRO authorization, but with an exception to the rule...

We had originally denied IRO authorization because of that particular exception...[nbsp][nbsp]We have reconsidered our position by not letting a few bad apples spoil clear legitimate uses that others will have...

--
Terra
--Sometimes, democracy really does work--
FutureQuest

<Edit: added exact message edit clarification>
[This message has been edited by ccTech (edited 10-28-00@07:03 am)]

[Storm Shadow]

You guys are great![nbsp][nbsp]That small modification to the rule manages to be reasonable and also solves my major development obstacle.

Wow, I don't think I've ever been involved in a case where a webhost actually considered an issue a user brought up and resolved it in such a logical and thoughtful manner.

This is a thread I'll point friends and associates to when they are considering webhosting.

Thanks again,
SS

[spiderbutt]

[nbsp] Wait a minute here.[nbsp][nbsp]So IRMs can't use any of the databases of the parent package.[nbsp][nbsp]Then what is the point of having six databases AND a limit on 5 IRMs?[nbsp][nbsp]I didnt know there was a limit on number of IRMs until I signed up, nor until a few minutes ago that there a restriction on using the databases in IRMs - I thought the extra dbs were for the IRMs.[nbsp][nbsp]

[nbsp][nbsp]I can appreciate your not wanting to allow huge resource usage by single accounts.[nbsp][nbsp]That is the real issue.[nbsp][nbsp]So, why not restrict resources just like bandwidth?[nbsp][nbsp]I have MANY domains that I was originally hoping to host as IRMs in a Platinum account.[nbsp][nbsp]Considering that most of them for now would barely be more than parked domains (very few pages, and all static), you would have made money off of me with the $25 setup fees for these essentially painless IRMs.[nbsp][nbsp]
[nbsp][nbsp]Similarly, if I had 5 IRMs that all used MySQL, but of all the account IROs and IRMs, only ONE used major resources, then it wouldnt be much more resource intensive than just one account and one database.[nbsp][nbsp]This means that low powered users like myself could host many low-powered domains at a reasonably low cost.[nbsp][nbsp]The moment more than one domain became a big resource user, I would transfer the hog to a new reseller account.[nbsp][nbsp]I would _have_to_ if it used too much HD space or bandwidth.[nbsp][nbsp]If you metered jobs in the same way, it would be another criterion for pricing.
[nbsp][nbsp]Rather than incur a whole new pricing guidline, though, all you have to do is meter job cycles and warn the user if they are real usage hogs.[nbsp][nbsp]Include daily summaries of job-usage for each IRM, even if they're just a ballpark number.[nbsp][nbsp]If they have more than one domain using databases in the resource-hungry account, just tell them to move the most offending hog into an individual account or have All The Others deleted. ;)[nbsp][nbsp][nbsp][nbsp]That would get anyone's attention.
[nbsp][nbsp]If, instead, the user had 5 IRMs that all use databases, yet, netted together, they use less resources than one serious bulletin board user, then there should be No Problem.[nbsp][nbsp]The fairness issue has to do with everyone getting what they paid for, no more, no less.[nbsp][nbsp]If you pay for a power-user account, it should be able to cover a lot of tiny subdomains.

-----

On further reflection:

[nbsp][nbsp]I think you should have the job metering in place for users to see, and if they want database usage in an IRM, they have to pay an extra setup fee - but not an extra monthly fee.[nbsp][nbsp]What the fee should cover is setting up not only the database permissions (to allow that IRM access to the server), but also a user-configurable autoupgrade path, and perhaps serve as a deposit on potential billing options of the upgrade path.
[nbsp][nbsp]For example, the following could be setup as user-configurable options:

A: If an IRM w/ database goes over a certain usage quota AND the net usage by the account as a whole is over a larger usage quota, then the IRM will automatically be transferred to a new gold account.[nbsp][nbsp]If the IRM is over a certain usage quota but the net usage of total account is not over its quota, then there is no problem and nothing is done.

B: If the net account goes over a usage quota but none of the main or IRM domains go over a lesser quota, then (user selects)

[nbsp]i) the domain with the largest usage is autotransferred to a new gold account

OR
ii) the user will be subject to an extra $15 dollar charge and have five business days to move things around to other accounts as they see fit.[nbsp][nbsp]If the autotransfer conditions of a) are met during the five business days, the autotransfer will occur and the $15 fee will not be refunded.[nbsp][nbsp]If no changes are made and the conditions of b) are still exceeded at the end of five business days, then (user selects),
[nbsp][nbsp] alpha) highest job usage domains are autotransferred to their own gold account, one per day, until conditions of b) are no longer met on the basis of a daily, pro-rated quota.
[nbsp][nbsp][nbsp][nbsp] or
[nbsp][nbsp][nbsp][nbsp]beta) autobackup and deletion of lowest-usage database-using IRMs begin, one per day, until conditions of b) are no longer met on basis of a daily, pro-rated quota, or until there are no database-using IRMs left.[nbsp][nbsp]

OR
iii) monthly price of account package is doubled for the month in question.[nbsp][nbsp]If the conditions of a) are ever met during this month as well, the actions defined there will also occur, with no refund.[nbsp][nbsp]If double the net account quota is exceeded yet the conditions of a) are still not met, then the bill for that month will be tripled.[nbsp][nbsp]If triple account quota exceeded but autotransfer conditions of a) not still not met, then monthly bill quadrupled, and so on....

---
[nbsp][nbsp]Also, if an account has no database-using IRMs, it will still have its own monthly resource quota which, if exceeded, will incur extra billing just as exceeding bandwidth would.[nbsp][nbsp]There is no reason to make this quota higher than for accounts with database-using IRMs (no penalizing of people with those IRMs), UNLESS you have significant managerial overhead for setting up database-using IRMs.[nbsp][nbsp]By referring to managerial overhead, I'm not referring to the process required to create the preference system described above, I'm referring to the managerial overhead for running things once you have it in place.[nbsp][nbsp]Considering that it will all be automated by a user-selectable configuration, it should require no extra overhead once it place.[nbsp][nbsp]There will be a period of smoothing out lumps, but that's temporary.

[nbsp][nbsp]You could, however, if an account has no IRMs at all, allow perhaps double the normal job quota in resources.[nbsp][nbsp]This is fair, since, if someone had an account with non-database-using IRMs and went over their job quota, and they then moved their IRMs to some other account, they will still end up paying for more job resources in the server since the new account being paid for the IRMs will include its own job quota within the server.[nbsp][nbsp]Anway, $40 - $60/month for the amount of MB and bandwith provided is a bit pricey, if there are no IRMs, so rewarding such an account for not having IRMs is fair.[nbsp][nbsp]Of course, I cant know as much about this as you, the webhost, to do the final resource and profit analysis on this.

[nbsp][nbsp]If you meter job usage this way, you could also allow the use of bots (pre-approved ones) or other job-hog programs, but they would have their own setup fees, quotas, and billing trees for exceeding quotas.[nbsp][nbsp]If they are more of a thread-hog than a mere job-hog, then even threads may be metered and given their own billing quota.[nbsp][nbsp]Find a fair price and someone will pay it, fair meaning: you (the webhost) can afford to buy resources necessary to provide service to all your customers at your chosen threshold of quality, and I (the customer) am not profit-gouged.[nbsp][nbsp]Those who can't afford the fair price will just have to live without, but if any can afford it, you will improve your business model as a whole.

----
[nbsp][nbsp]Ah, the consequences of being bored on a Sunday night.

[nbsp][nbsp]my 2 cents
[This message has been edited by spiderbutt (edited 11-05-00@9:43 pm)]

[Deb]

The ideas presented here are intriguing however not completely realistic at this time.[nbsp][nbsp]IF the system could be setup as suggested it would be extremely difficult to enforce, explain, and operate.[nbsp][nbsp]It would generate &quot;surprise&quot; bills for end users as well as requiring some magically automated way of moving their files to another area to be setup as full accounts leaving the site owner bewildered as to where their account magically disappeared to.[nbsp][nbsp]Include paths etc would be broken in the process.[nbsp][nbsp]Moving an account is not a simple task for the host or the site owner so an &quot;automated upgrade&quot; is just not an option.[nbsp][nbsp] By referring to managerial overhead, I'm not referring to the process required to create the preference system described above Creating this process would certainly be an enormous amount of overhead.[nbsp][nbsp]The astronomical fees involved would indeed need to be considered, and the cost certainly would need to be recovered from the end users via the account fees.

FutureQuest does not explain what all does not come with each account but rather what does come with each account.[nbsp][nbsp]As an example we do not state that the Basic Package does not include MySQL but rather that the Gold Package does include MySQL.[nbsp][nbsp]I can see how one could be confused with the IRMs and for that reason will be adding a notation to the IR page (http://www.FutureQuest.net/ir.php) stating that MySQL is not a feature of these one-time $25 setup fee accounts.[nbsp][nbsp]

To have MySQL, as is noted in the FAQs etc, the account holder must have a Gold Package or above. I would transfer the hog to a new reseller account Just to be sure there isn't confusion here as we have had quite a few who thought that Resold accounts had to be in the form of IRs.... ANY package can be resold.[nbsp][nbsp]The full packages, including Gold and above are discounted via the points program explained at http://www.FutureQuest.net/Resellers/[nbsp][nbsp]At the 50% off rate, Gold packages are available for only $19.98/month which is an extremely good deal for 15GBs of bandwidth, 75MBs of space, MySQL etc etc etc...

Though I agree it would be nice to have a system in place that would automatically handle all resources the task is a bit more difficult than one may assume and virtually impossible on community servers.[nbsp][nbsp]Another example:

* Accounts come with X amount of space.[nbsp][nbsp]At this level xx accounts can fit onto a server.[nbsp][nbsp]Accounts may purchase extra space and just have the over usage added to their bill automatically.[nbsp][nbsp]Suddenly many accounts are purchasing a great amount of disk space and the server can no longer house them.[nbsp][nbsp]Here we have a situation where server enhancements and/or account moves must occur. The same type of situation, only with much more severe consequences, would happen with the system described above.

Another item to note is why Community Hosting is so much cheaper than dedicated hosting.[nbsp][nbsp]The idea of some small accounts sharing a server with some larger accounts and having each of them share the costs is what makes the system available for the low monthly fees.[nbsp][nbsp]It is common knowledge that if ALL accounts used ALL of the resources that are included with their packages a LARGE MAJORITY of hosts would quickly be out of business.[nbsp][nbsp]By even offering the IRM option we are helping each site owner to use ALL of the resources that come with their account.[nbsp][nbsp]FutureQuest in no way, shape, or form is making a profit from the IRMs.[nbsp][nbsp]On the books, we lose revenue with each one that is setup.[nbsp][nbsp]We offer them because we do gain client satisfaction and offer each site owner the opportunity to gain more for their money which is by far worth its weight in gold.[nbsp][nbsp]At the same time we cannot forget the fact that they do require resources that take away from the servers as a whole and from the financial requirements to keep things running.[nbsp][nbsp]For this reason we must restrict them a bit and the MySQL issue is one of those restrictions.[nbsp][nbsp]If we were to setup all of this &quot;resource monitoring&quot; remember that full Gold Packages would end up monitored right along with the IRMs and this would only generate more restrictions rather than less.[nbsp][nbsp]It's important to again remember what makes community hosting available for the low costs.[nbsp][nbsp]The monitoring of these packages would require as much in the resource department as the packages themselves remembering that the costs are already slashed due to competition and site owner demand who would cover these costs?[nbsp][nbsp] A grand idea it is in concept however I couldn't possibly promise a system like this any time soon.

Deb
[nbsp]-
[nbsp][nbsp] The goal is for all (host/site owner) to remain on-line.