Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


VPS Control Panel Feature Set
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

VPS Control Panel Feature Set

Hello all,

We all know SolusVM v2 is coming never and sadly the other options do not really live up to expectations (except for Stallion!), what are you looking for in a VPS control panel?

I am currently in the process of coding a modular based VPS control panel, primarily coded in Golang using gRPC for communications, directly communicating with libvirt locally.

Here are the current feature sets I have planned:

Control panel built using Golang, closed source with possible options for open source.
Slave agent built using Golang, planned nodejs and python alternatives, planned open source.
Fair licensing

KVM and OVZ7 out of the box, LXC XEN planned.

TLS/SSL authenticated gRPC for master<->slave communications

Slave agent gRPC API for local libvirt operations/VM control (no remote ssh/libvirt)

Separated API layers, gRPC API for Slave separate from Control Panel backend API separate from web frontend, use all or build your own solution on top of either API set

Separated gRPC stubs/protocols for each supported domain type

Template system for libvirt domain XML, full domain XML customisation possible on global and per-domain scale

Full support for basic VM control, start/stop/reboot/reinstall/networking/migrate/stats/vnc console

Built in snapshot support for supported disk file types (QCOW2 etc)

Automatic SSH key deployment to supported container types

Billing system integration (WHMCS with blesta/hostbill planned)

These are the feature sets I have in consideration:

Managed VM template files, templates will be updated with latest packages on a daily basis (no more deploying VM's with insecure outdated packages!!)

Firewall support, allow white-listing of IP's for ssh for supported container types on deployment (using either IPTables directly or fail2ban)

Deploy random ssh port on deployment of supported container types

Built in monitoring, monitor VM's and their services/processes, send email alerts etc

Email policies, block port 25 or automatically deploy SMTP relay settings for supported container types

Community driven feature sets:

These are just a few of the features that have come to my mind that I would like to implement,
but I also understand it needs to implement features the VPS community would like so here is where your input is critical.

What are your thoughts on the current planned feature sets?

What are your thoughts on the feature sets I have planned for consideration?

And most importantly, what features would you like to see implemented?

What is the current state of development?

This is already in development, the Slave agent is currently being actively developed. The control panel API will then wrap around the feature set the Slave agent provides and then the web frontend will wrap around the Control Panel API. This is being built from the bottom up, as it's most important to have as much as the feature set implemented at the slave level to minimise master<-> slave communications as well as offloading operations as soon as possible to the slaves to free up resources for the control panel. Your input and feedback is proactively required to shape the control panel from the bottom up.

Thanks for reading and I look forward to your feedback (No need to be nice, I'm open to any constructive critism too)!

Many regards,

Chris.

Comments

  • doghouchdoghouch Member
    edited January 2017

    A lot of control panels (most notably Virtkick) tried this approach, and failed. I hope that it won't be the same with you, but there's a good market out there if you charge less than OnApp, and have a more feature-rich control panel.

    Good luck with the panel! :)

    EDIT: Hopefully, it won't take as long as SolusVM 2's dev progress to implement a reseller API

  • AnthonySmithAnthonySmith Member, Patron Provider

    As an absolute minimum, it needs to have every single feature that SolusVM has without exception and needs to have an importer for SolusVM and a module converter for WHMCS.

    If you can get to that stage by the end of the year I will eat my hat, your hat and any other hat of your choice.

    Thanked by 1Junkless
  • @doghouch I always thought VirtKick was a mess from the start. I've always aimed to start right at the bottom whereas I always thought VirtKick was aiming at the top from the start and just failed miserably with their approach.

    @AnthonySmith I'm not going to lie but I do not have much experience with WHMCS's module system, my aim will be to focus on the core feature set and then get someone outside with the knowledge to do the billing implementation. I believe in not touching anything you have no clue about so if anyone has any experience in that area I'd love to hear from you.

    The biggest issue I can currently foresee is getting imported SolusVM domains to work inline with the domain xml template system.

  • niknik Member, Host Rep

    Virtkick has a low quality code base and is full of bugs. We have finished developing our own panel over the last few days (since virtkick is not working more than 12h per day we finally were pressured to do so).

    We are using a Rails app with a Golang agent on each hypervisor. Our panel will go live soon™ with the bare minimum of features (node management and billing) but we are actually able to expand it and have actually the chance to fix bugs and extend it.

    We are not sure yet if we want to open source it but this might be an option down the road.

  • AnthonySmithAnthonySmith Member, Patron Provider

    r0t3n said: @AnthonySmith I'm not going to lie but I do not have much experience with WHMCS's module system.

    Its pretty well documented and example'd, the solusvm v4 module is open source, grab it and take a look :)

    r0t3n said: The biggest issue I can currently foresee is getting imported SolusVM domains to work inline with the domain xml template system.

    There is nothing specific in solusvm that requires that, if you import the domains you can simply re-write the config files.

    You just need to take certain static variables from the existing config files CTID.conf for openvz, vm1234.cfg for xenpv+hvm, and kvm1234.xml for KVM

    Sounds like you need to have yourself a live solusvm environment running with real customers for a while to me in order to truly understand what you need to do.

  • @AnythonySmith You've dealt with this shit for far too long, lol.

    Thanked by 1AnthonySmith
  • @r0t3n Like I tried to build one too, but simply didn't have the time to finish it:

Sign In or Register to comment.