Results 1 to 9 of 9
  1. #1

    Thumbs up New Control Panel in Development Needs Help

    Hi Guys,

    I'm currently building a control panel and now at the point to begin integrating system level functions and deciding what are the best software/applications to support. There are 4 levels of users at the moment, maybe 5 later on if I decide to have a cluster admin, dedicated user admin, reseller, customer, and ticket user.

    A dedicated user admin would be created solely for resellers who need a dedicated box and would like to have the power to view system resources, monitor via MRTG graphs any spikes, etc. That's something I'm thinking later in the future.

    For now, there is an admin level, reseller, customer, and ticket user.

    Some features of setting/managing users are completed and very basic support system is in place but my plans are to create a full blown ticket system that is comparable to RT and performs mime decoding for attachments in case a user wants to submit a screenshot of his problem.

    It's alot of work but I'm committed and below are links to screenshots I've taken of work in progress in case you have any doubts.

    What I'm in dire need for are enthusiastic administrators who would like to give some feedback as the development is in progress, perhaps beta tests the software during various stages, provide commands/procedures to perform a system level operations for LINUX and scale to other service providers like .NET or NT platforms if anyone has any experience in that area.

    I expect that it would take a few hours of your time as an experience command line administrator to let me know of the commands I need to execute that would make the system light up. Alot of the commands I already know such as procedures to setup a hosting account and removing, setting up emaila accounts, but I'm not sure of setting quota, monitoring services up/down, suspension, etc.

    Pretty much I want to compile a list of actions and the best possible settup of a LINUX box that incorporates all the necessary features the CP has to offer.

    Perhaps find a few guys with knowledge in NT platforms as well so that I can perhaps construct an architecture to scale not only with LINUX platforms, but to other platforms.

    Let me know what you can offer and I'll be in contact with you shortly, provide you some materials on my vision, ideas, and what I would need from you.

    In the end, based on what you provided during the development, I will give the final copy of the control panel to those who contributed.

    Here's a few screenshots of work in progress:

    Reseller area: http://www.blazeboard.com/cpmax_ss/ss1.png
    Administrator area: http://www.blazeboard.com/cpmax_ss/ss2.png
    Trouble ticket user area: http://www.blazeboard.com/cpmax_ss/ss3.png
    Customer area: http://www.blazeboard.com/cpmax_ss/ss4.png

    BTW, CPMax is likely not going to be the final name of this CP as the domain name is already taken.

  2. #2
    KDE3 icons - I like it

    Good luck with new cp.
    Powered by AMD & FreeBSD.
    "Documentation is like sex:
    when it is good, it is very, very good;
    and when it is bad, it is better than nothing."

  3. #3
    Yea,

    I had to find something to fill in the layout so it does not look so dull

    The final skin will likely be redone once everything is completed and we have an idea what sort of skinning is possible. Right now, skinning is pretty easy though there's no header/footer you slap into place. Each function is it's own template so you gotta go through each file and make the adjustments.

    Slower, but more customizable I'll say

    Those graphs you see are actually little SWF charts that animates. Pretty cool until you see it acutally running and scales the little graphs.

    I'm also incorporating MRTG graphcs for administrator area. I'm still working on getting a couple of command line scripts to properly parse and return values that works on FreeBSD too.

  4. #4
    I really don't agree it's a good idea to use PHP for any part of a control panel. Looks nice, but I'd change it to some other implementation for the front end and especially if you have it commit any functions as a privileged user. PHP has bugs and security issues frequently enough (as well as Apache), while other solutions like a custom daemon will provide better control and security, as well as stability. You should really loose the PHP. I'd personally not use any control panel that used PHP in any manner that's not strictly cosmetic (and doesn't rely on the PHP language, it's functions or interface to do any of the real work, checks or the like).
    Robert McGregor
    URL: http://www.2host.com
    Email: robertm@(nospam)2host.com

  5. #5
    I haven't seen any major flaws with PHP and I believe Plesk as well as WebCP are using PHP.

    The front end will be built in PHP which will perform most operations such as automated billing, invoices created via PDF, trouble ticket system, etc.

    The main API will be also be built via PHP using the command line. If there are any issues with security, the API could be developed in PERL to execute the commands as root.

    I haven't seen any clear examples of security issues with command line PHP or issues that PHP is not able to perform agressive argument checking that PERL or any other language can do.

    Most problems lies on the developer's part which sometimes would be forgetting to scrub down an argument before it executes, revealing too much of why an error occured (helps hackers find another way around), not properly handling encrypting data (man in middle attacks), etc.

    I've worked with PHP for 3 years now and never once did I ever have any issues with security flaws that would compromise the system.
    Last edited by Xanthis; 09-05-2002 at 09:07 AM.

  6. #6
    Hi,

    I would be more then happy to help with the Windows version, if you decide to go ahead.

    Best Regards
    Adam Heavens
    Server Centre Limited (www.servercentre.net)
    Exchange 2007 Hosting, Windows/Linux Hosting

  7. #7
    Originally posted by Xanthis
    I haven't seen any major flaws with PHP and I believe Plesk as well as WebCP are using PHP.
    Who uses it doesn't matter. Sure it depends on how you use it and what for.

    The front end will be built in PHP which will perform most operations such as automated billing, invoices created via PDF, trouble ticket system, etc.
    Sounds to likely be harmless.

    The main API will be also be built via PHP using the command line. If there are any issues with security, the API could be developed in PERL to execute the commands as root.
    To have PHP run as root is a bad idea.

    I haven't seen any clear examples of security issues with command line PHP or issues that PHP is not able to perform agressive argument checking that PERL or any other language can do.
    I guess that depends on what you want to do. I don't want to offend you, but calling it PERL leads me to believe that you're not really experience with Perl, which is fine. I won't go into any details here. You control panel looks nice, I'm sure it'll turn out okay.

    Most problems lies on the developer's part which sometimes would be forgetting to scrub down an argument before it executes, revealing too much of why an error occured (helps hackers find another way around), not properly handling encrypting data (man in middle attacks), etc.
    True, that is often the cause. However, PHP has it's own functions and you are limited to them to work well, be flexible enough to do what you want and also to be secure in how they are implemented. There have been plenty of documented exploits up to very recently. These issues do not lie in the programmers' hands, but the way PHP is built and interfaces. You're right though, you can always change it later to another language. I just don't know that I'd suggest going live with anything that uses a web server with PHP involved for tasks like this, because I think it's a risk and it's been proven to be in other areas as well. But again, it will probably turn out fine, I just don't think it's a good idea for many reasons, but it's your product and project.

    I've worked with PHP for 3 years now and never once did I ever have any issues with security flaws that would compromise the system.
    You're also talking about using PHP to either interface with or process data to pass to a process (or do it itself) and run as root at some point. The nature of PHP makes this a bad idea, but I'm sure you've probably taken measures to ensure it runs in a reasonably secure way and I wish you luck with your project. I was simply trying to make a suggestion, not take a shot at fine your product. Good luck.
    Robert McGregor
    URL: http://www.2host.com
    Email: robertm@(nospam)2host.com

  8. #8
    Well, your comments has made me realize a few things I had not consider. I agree on some points that were made such as running PHP as root, more rather have it setup with the proper group to make modifications to a particular conf file or restart certain services sure.

    There are few things I've put in place already and considering once it begins to manage across a cluster of machines such as using SSL encryption so that CURL can POST securely across to other machines the necessary data to execute commands.

    All variables are referenced with $_POST, $_GET, $_COOKIE, etc fashion and I've begun turning on all notices while developing this so that I can see all variables that aren't defined so that they are properly defined so it can't be spoofed from the browser.

    Errors aren't spitted out to the screen so hackers won't know why a request did not go through, just incase they want to try and be sneaky and figure a way around.

    They will be all logged. Though most of these precautions only protects from someone breaking through the CP code. If PHP goofs and there is a hole, well, that's a risk and likely it will be patched.

    I've dealt with Perl in the past for about a year or so, and they make releases very slowly. Maybe just too slow, but perhaps it's more stable than PHP.

    So yea, maybe Perl would be a better maybe, better as the API, but I was contemplating about using JSP also, but I find it that most hosting companies don't offer JSP and might be a bit difficult to install J2EE as it also puts more overhead on a machine, use a bit more memory, etc.

    The last control panel the company I worked for chopped together was written with J2EE. Took a while to get everything work, deployed properly, etc. There's more security restrictions with JAVA, but I think it's a bit of an overkill for a control panel in which just needs to manage just one or a few machines.

    Probably better doing a CP in JAVA for a corporate or managing a cluster of servers.
    Last edited by Xanthis; 09-05-2002 at 05:55 PM.

  9. #9
    Join Date
    May 2001
    Posts
    1,513
    If you're willing to pay a decent amount, I'd be willing to help with Perl and shell commands, etc. I've written many perl programs.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •