Starting work on an open-source control panel

definitelyliam

@mpkossen said:
If Virtualmin is confusing for you, you should not run your own VPS.

If you like VestaCP's code you should stop being a developer.

"...or confusing to use for beginners (Virtualmin)((. I **really like VestaCP, but it confuses people that aren't used to non-icon layouts like how cPanel/Kloxo does it (like me), but I personally like it."

Seriously, do people here just wake up in the morning and do some selective reading just so they could bash an OP? I see this happening to a lot of threads here.

@raindog308 said:

I apologize for me calling you inappopriate things, it was 12:35 in the morning and I was struggling to get some sleep. Anyway, GCat also mentioned to me to consider Python, so I will. I really didn't like your choice of words (and your sarcasm) so I had to say something to at least keep the discussion related to the topic, and not some sort of a magnet for personal attacks (which I admittedly just did when I replied earlier).

mpkossen

definitelyliam said: Seriously, do people here just wake up in the morning and do some selective reading just so they could bash an OP? I see this happening to a lot of threads here.

I think you did some selective reading yourself :-)

linuxglobe

Good luck @definitelyliam!
I wait it for testing... If contain some back-up functions,some Filemanager for easy up/download, both Apache+NginX ,will be better..

definitelyliam

Well, I wouldn't set a ton of expectations. The project is still in its infancy, so it's still a very long way to go.

Again, everyone, thanks for the support and feedback. Now, if mods could close this thread I'd be thankful. Time to go to work, and possibly start ignoring personal attacks that could be accumulated in this thread.

mustafaramadhan

Interesting with website say: 'OpenCP's front-end uses a solid framework for security...'.

Are you sure about it?.

rincewind

As a design suggestion, use a RESTful service at the backend. Why?

• Separates your front-end and back-end with a clean interface. A few months down the road if you want to change your front-end, then you can do so without any changes to the backend. Alternately, if you want to switch your backend from Python to PHP or some other language, you can always do so without changing the front-end as long as you maintain the same REST interface. If someone wants to create their own custom frontend, or just send some cURL/wget commands they can skip your Web-interface and use the REST interface directly.
• Adds pluggability for free A plugin can register for a subtree within your REST tree. For example a webserver config plugin can register for the subtree /services/web and all URLs with that prefix will get sent to that plugin. Adding new services is just a simple matter of registering for a subtree. Individual modules may need to publish capabilities through a JSON file. For instance, if you do GET /services/web you might get a JSON file providing a list of webservers installed (Nginx/Apache), and on probing further (/services/web/nginx/domains) you would get a list of domains in JSON format, and so on. Use POST to create a new service, and PUT to modify config.

At the most abstract level, you can think of your application providing service discovery and message-broking between the front-end and a bunch of backend plugins.

The broad framework maybe too abstract for your needs, but you can pick and choose some useful patterns.

For implementation, Python is a decent choice for the backend: it has all the system stuff easily available. The os module lets you change permissions, move and delete files etc. For installing software you can use the os.exec*
commands to call apt/yum.

For the frontend, I would suggest Javascript. You dont want the browser contacting the server each time the user clicks on something. Deliver your JS bundles to the browser which then constructs the page, and render on the browser. Minimize communication between server and browser.

Some references:

The Twelve Factor App

The REST cookbook

deadbeef

@definitelyliam said:
Perhaps instead of being such an asshole for putting all your efforts into writing such sarcastic comments

Pointing out the facts doesn't make him an asshole, it makes him wise. You are the one being the asshole for attacking him because ...your feelings... got hurt.

you actually give useful input, like giving me insights on why you think a certain way of doing things is better.

Actually he did exactly that. You were too butthurt to notice but that's not his fault.

You really need to stop being a total douche.

mpkossen

OK, so here's some real feedback @definitelyliam:

• Start small! And with small, I mean a lot smaller than you're probably thinking. Creating a roadmap is fine, but focusing on very frequently delivering working software is more important. The reason Flarum (forum, google it) is not yet used by anybody, despite everybody mentioning it, is because they've made an enormous list for their "1.0 release" and they're only going to make it production ready by the time all of that list has been finished. That's going to take months or even years. Start small, delivery frequently, and keep a focus on quality. A finished product with only one button is always better than a product in the making with 1000 buttons. The former can be used by people, the latter cannot and will not. If this sounds to vague to you, let me know and I'll write an essay on this easy!
• Get feedback early and often! The sooner your release something production-ready, the sooner people will start using it, the sooner you will get some actual (and very valuable) feedback!
• I would not leave out Apache for compatibility reasons. A lot of software still assumes Apache plus it's a more versatile application server than NGINX. NGINX is great for speed and things like that, so if you ask me do the combination. It's also a USP.
• Make is simple to use (another argument to start small). Many of these control panels have a shitload of options and menus and they all have a learning curve of what to find where.

Fritz

Hey, welcome to LET.

Could you use some features of ISPConfig3?

Brad

First learn to differentiate personal attacks and criticism. You're not always going to get positive feedbacks.

Criticism may not be agreeable, but it is necessary. It fulfils the same function as pain in the human body. It calls attention to an unhealthy state of things.

definitelyliam

@mustafaramadhan said:
Interesting with website say: 'OpenCP's front-end uses a solid framework for security...'.

Are you sure about it?.

For the front-end, yes. There's no exact guarantee to it, but the project will use a solid and tested framework.

@mpkossen said:
OK, so here's some real feedback definitelyliam:

• Start small! And with small, I mean a lot smaller than you're probably thinking. Creating a roadmap is fine, but focusing on very frequently delivering working software is more important. The reason Flarum (forum, google it) is not yet used by anybody, despite everybody mentioning it, is because they've made an enormous list for their "1.0 release" and they're only going to make it production ready by the time all of that list has been finished. That's going to take months or even years. Start small, delivery frequently, and keep a focus on quality. A finished product with only one button is always better than a product in the making with 1000 buttons. The former can be used by people, the latter cannot and will not. If this sounds to vague to you, let me know and I'll write an essay on this easy!
• Get feedback early and often! The sooner your release something production-ready, the sooner people will start using it, the sooner you will get some actual (and very valuable) feedback!
• I would not leave out Apache for compatibility reasons. A lot of software still assumes Apache plus it's a more versatile application server than NGINX. NGINX is great for speed and things like that, so if you ask me do the combination. It's also a USP.
• Make is simple to use (another argument to start small). Many of these control panels have a shitload of options and menus and they all have a learning curve of what to find where.

Thanks. Will show this to GCat.

As for the personal attack thing, there's a way to put things into perspective. Doing them rudely will not help.

ChairHosting

Hello

I'd love to see an open source control panel. Just make sure you don't miss anything or take shortcuts because it's opensource . I've seen many other project where development just stops after awhile, don't be one of those developers and just throw the project away.

HostingSpecialists

Sounds good to me. You seem to know what you want to do! I'll be interested to see how this turns out.

SwellJoe

Howdy all,

I work on Virtualmin.

I don't want to distract from the conversation here, but if there are specific areas where anyone feels Virtualmin could be easier to use (whether for administrators or customers), please do let me know directly or in the Virtualmin forums. We're overhauling the UI lately, and welcome feedback, especially specific feedback (like, "Domain owners should not see X menu option" or whatever, or "This menu item should be located in another subcategory", or "This feature should be deprecated").

Please don't post Virtualmin requests on this thread, as I don't want to take away from the ongoing conversation about what definitelyliam is working on; just let me know via email or over on the Virtualmin forums. (I dropped in to this thread because I got a Google alert about folks discussing Virtualmin, and then got interested in the conversation.)

Also, I wish someone were working on a nice Open Source web hosting billing system, as well! It's a big job, and the best options (WHMCS, probably) aren't free.

Best of luck with your project, definitelyliam! It's a fun challenge, and there's always room for new ideas. Feel free to hit me up if you have questions about handling some of the trickier bits of shared hosting deployments (stuff like suexec with fcgid or PHP-FPM can be tricky to get right, especially in a safe way for many users on the system, and mail handling with spam and AV scanning, etc. are big jobs with huge and complicated dependency chains).

Cheers,
Joe

raindog308

definitelyliam said: I apologize for me calling you inappopriate things

Aw, that's OK. I was kind of an ass.