Solution for Bandwidth Management of Resellers

Discussion in 'PSA 2.5 Suggestions and Feedback' started by advantagecom, Apr 12, 2002.

  1. advantagecom

    advantagecom Kilo Poster

    Messages:
    99
    This is more of a feature request than anything.

    We have an external bandwidth manager box (doesn't everybody? :D ) that works great.

    Just one problem. For simplicity's sake, we'd like to be able to bandwidth limit a reseller and all of his domains with one bandwidth limit rule on our bandwidth manager box. We believe that instituting bandwidth management on an external box is the most flexible and scalable method (vs some of the bw limiting modules you can get for Apache and etc.)

    To do this, all domains for that reseller (the "client") would have to point to a single IP and each reseller would have to have their own unique IP. Its not hard to do by hand (just time consuming when dealing with hundreds of domains), but that would defeat the whole reason we bought plesk - automation!

    At present (v2.5), Plesk will only do name based hosting on the main IP of the server. I've checked all the documentation at the Apache site regarding name based hosting and I know it is possible to configure Apache to do name based hosting on any active IP in the system. It's all pretty straightforward.

    A relatively simple interface change of the domain creation pages (or the domain's "hosting" settings page) would allow us to do this. Instead of forcing all name based hosts to point to the main server IP, simply put a text box IP entry field right next to the name based hosting radio button so that we can define what IP is sending and receiving traffic for that domain.

    To encourage our resellers to properly point their domains to something other than the main server IP, we'd institute a restrictive bandwidth rule for the main IP of the server.

    Of course, we'd love it if there was a way to default that field to be the first dedicated IP assigned to a particular client, but that would not be 100% necessary to get our bandwidth management scheme working.

    Anyone else think this is a good idea? If so, forward the URL to this thread to the Plesk support department so that they know that I'm not the only one that wants this functionality.

    Andrew

    PS Another alternative is to just use a wildcard in the NameVirtualHost directive of /usr/local/psa/apache/conf/httpd.conf and let DNS determine which IP gets the traffic for that domain. This still requires that plesk write out the virtualhost directive for name based sites with a wildcard instead of the IP:port format they're currently using.

    I've tried just using
    NameVirtualHost *
    in the httpd.conf, but since PSA insists on writing specific IP and port information in every name based virtualhost directive, it doesn't match properly and the site won't come up on any other IP but the one configured in the VirtualHost directive. If the virtualhost directive format for name based sites (and only name based sites) was changed from:
    <VirtualHost IP:port>
    to
    <VirtualHost *>
    then using the NameVirtualHost wildcard would allow you to use DNS to point name based sites to any valid IP on the server and the site should function, thereby allowing resellers to be bandwidth limited by the dedicated IP assigned to their main site and solving a common problem that PSA users face - bandwidth management.
     
  2. advantagecom

    advantagecom Kilo Poster

    Messages:
    99
    Nothing quite like creating your own new feature :D .

    I think I may have come up with a solution for this. It's a bit kludgy, but I think it could work. Only problem is, I'm not a shell script wiz, so I'm hoping someone will post a reply with a basic shell script (for FreeBSD 4.x please) that will accomplish the following:

    replaces /usr/local/psa/admin/sbin/my_apci_rst
    (the old my_acpi_rst would need to be moved out of the way)

    runs the old my_acpi_rst from its new name to build the initial httpd.include

    then uses "sed" or some other search and replace utility to replace the main server IP with a * character in httpd.include and write out the modified file

    sends a kill -HUP to the root apache process to cause it to re-examine the config file for changes


    Some caveats that I'm unsure about:

    Are the PSA scripts looking for any special exit codes from my_apci_rst? Probably not, but they might.

    What kind of overhead does this add to the already inefficient config rebuild process?


    If anyone has any comments, suggestions, or a better way to do this, please post to this thread with your words of wisdom. :)

    Andrew
     
  3. advantagecom

    advantagecom Kilo Poster

    Messages:
    99
    Since I seem to be the only person interested in this issue, I'll just keep posting things as I think of them.

    After some more thought, the script idea is a bad one. Since my_apci_rst apparently restarts httpd on its own, the script would constantly be running a race to get the "problem" fixed before anyone noticed that their sites were down. Not good at all.

    So, here's two more options:

    1. It's my understading that the VirtualHost directive is superceded by any later directives defining the same VirtualHost. So, one could add an include directive at the bottom of the httpd.conf to include a rewritten version of the httpd.include. Call the rewritten version httpd.include2. Then, create a small script that rewrites httpd.include to httpd.include2 every 15 minutes or so and sends a kill -HUP to the apache root process to tell it to reread the configs. This would mean that only new sites would be down and only until the rewritten config catches up with the regular httpd.include. Of course, changes in existing sites would not be seen for 15 minutes with this method. Your logs might get goobered up with warnings as well, though they can be turned off.

    2. This one is an educated shot in the dark, but assuming that the httpd.include is written using information gathered from the MySQL database that PSA maintains (is that not the case?), one could create a script that modifies the information there once every 15 minutes. This has its own set of unique issues. For instance, I would also assume that PSA resets the information for a domain each time that someone makes a change to the domain. That could present a scenario in which someone creates a password protected directory, and their domain quits functioning until the MySQL info gets rewritten and the httpd.include gets rewritten from the new info.


    If PSA weren't closed source, I'd just go modify the php web interface files to accomplish this. But since it is closed source, I have to push a 500 pound gorilla into making the changes or dance around their software with "helper" scripts to make it do what I want it to.

    Please, does _anyone_ have any input or ideas on this? I can't be the only one with ideas.

    Andrew
     
  4. advantagecom

    advantagecom Kilo Poster

    Messages:
    99
    Ok, maybe I just needed to think this out in writing. When I reread the option about creating a modified httpd.include and including that file from httpd.conf, I had a forehead smacking "oh duh" moment.

    Here's a refined idea that is so obvious, I'm surprised I didn't think of it sooner.

    Write a script that takes httpd.include, writes the modified version to httpd.include2, and sends a kill -HUP to the root apache process.

    Modify the existing config line in httpd.conf that includes httpd.include so that it includes httpd.include2 _instead_

    Then, setup a cron job so that the script runs every 15 minutes (more or less depending on your users' needs).


    Does anyone see any problems with this approach?

    If not, now all I have to do is go learn the sed utility. I was going to have to learn it eventually anyway, I was just hoping to avoid it.

    Andrew
     
  5. HardCoded

    HardCoded Guest

    Well, I've been thinking about your posts since you first posted, and although you win the "Really Long Posts" Award, I've been at a loss for anything intelligent to say. So I'm just going to say this unintelligent thing: instead of peeing around with sed, and kludgy file rewriting stuff (absolutely no offense intended...this is hard stuff), why not do something with mod_perl since it's installed anyway. There's a way with mod_perl to get dynamic config files with embedded perl code right in the conf file. Whether this helps at all I do not know.

    Keep in mind that I am thinking long term and not trying to help you do the end-run around Plesk's way of doing it. I am thinking, that in conjunction with mod_vhost_alias, which'd get new sites up and running without server restart, we'd use dynamic Perl directives to fine-tune the directory permissions and then just reread the config file once a day.

    My apologies for not answering any of your questions :)
     
  6. advantagecom

    advantagecom Kilo Poster

    Messages:
    99
    I've gotten this working so that the httpd.include is rewritten to httpd.include2. Now, each reseller can be assigned one IP and all of that reseller's domains can point to that IP. Apache handles it beautifully.

    The only remaining issue (and this one is a booger) is DNS. We're used to DNS interfaces that allow us to setup records as we see fit, so we didn't anticipate that the PSA DNS management would be problematic in this regard.

    As it turns out, the PSA DNS zone management is directly tied into the "hosting" settings for the associated domain. Try to point a name based site to the IP of a dedicated IP site on the system and it tries to assign that IP to the name based domain. Of course, the IP is already "in use" and so generates an error message. We've tried many variations on this, but there is extensive "sanity" checking done for every DNS record that points to an IP on the PSA box. That "sanity" checking is great and all, but it is preventing us from doing this the way we need to in order to banwidth limit on one IP per reseller.

    So far, the only solution we've found to the DNS issue is to turn of DNS on the PSA box and do DNS on an external box. Not a huge problem, but now we have to find a web based DNS interface that is segmentable by client. Of course, we could put PSA on a second box and just use if for DNS, but that seems like a waste of an $800 PSA license.

    Anyone know of any web based DNS interfaces that you can segment by client so that each client can only manage his/her own domains in the DNS system? It has to be somewhat "idiot proof" so that syntactically incorrect DNS entries are not allowed.

    Andrew
     
  7. jlasman

    jlasman Guest

    The idea is great. In fact, a year ago, when the folk at Ensim tried to get me to look at their product (at that time we were exclusively supporting Cobalt RaQs, which allow name-based hosts on any IP (yeah) but don't have a resller facility (boo), I told them I couldn't look at it until they had the feature.

    They still don't have a reseller model, and we've decided on Plesk.

    I'll pass on the URL to the people who I think are the important folk at Plesk to know about this...

    And don't get discouraged if there aren't a lot of replies... most people don't head for this support group the first thing every morning; I know we don't. Only once or twice a week or so at the most.

    I'd rather see a support mailing list for Plesk rather than use a forum like this one. Simply, if I've got a mailing list the posts come in when they do, they get sorted (by an email filter) into their own folder, and I look at them and answer the ones I want to answer, at my convenience, without having to log into a website.

    I'm so much a believer in a mailing list that I'm ready to start one if Plesk doesn't do it <smile>.

    Jeff
     
  8. advantagecom

    advantagecom Kilo Poster

    Messages:
    99
    Jeff,

    Thanks for the reply. In fact, I think I remember some of your posts on the Cobalt users list. Our company also used Cobalt servers exclusively up until recently and also were turned off by Ensim.

    I like PSA a lot better than ensim, but they still have some work to do on the reseller functionality. Like just today, we had several customers concerned with our logo showing up on the login page. The login page (IMHO) should be able to have a separate logo since customers of resellers see that. It would also be nice if they didn't have to see the name of the server in the PSA admin URL and they could use the reseller's domain name instead.

    Andrew
     
  9. ashley

    ashley Mega Poster

    Messages:
    103
    Hi

    Did you ever find a gui/mysql based bind 9 management tool?? In need for standalone pri/sec ns.

    Regards

    Ashley
     
  10. advantagecom

    advantagecom Kilo Poster

    Messages:
    99
    Yes, we did, but it is a nasty horrible booger to install.

    We had to hack it all to bits and rewrite large portions of it to work like it should have worked to begin with as well.

    http://source.xname.org/
     
  11. ashley

    ashley Mega Poster

    Messages:
    103
    Hmmm ...ive seen a few and visually that kind of appeals...its simple and obvious what to do and where. I looked at some others which were a bit mystifying.

    Can you tell me what the major issues were and or what hacks were essential?

    Regards

    Ashley
     
  12. advantagecom

    advantagecom Kilo Poster

    Messages:
    99
    I'm going from memory here and this was quite some time ago, so it is a bit fuzzy and may have changed with later versions. I delegated the task to one of our technicians, so the information I have is primarily second-hand.

    1. It is database driven and it seems like it required a very special setup of MySQL to function properly.

    2. We didn't like the look of the version we used (too flourescent if I recall correctly), so we edited the interface to be more eye pleasing.

    3. There were some spelling and grammar errors here and there that needed to be corrected.

    4. We had to add a lot more verbose instructions to each entry field so that non-techies could handle using it.

    It seems there were some bugs we had to work around as well, but I don't remember off hand what those were and the technician that did the install no longer works for this company so he was unavailable for comment.

    Andrew
     
  13. ashley

    ashley Mega Poster

    Messages:
    103
    OK

    Many thanks for trawling your memory banks there. I guess i'll download and have a play and see what i break (maybe even read the manual ;-)

    Cheers

    Ashley
     

Share This Page