Max

There is also a pure PHP implementation that does not require installing a serverwide PHP extension. Makes things easier if you plan to share your module with others, who may not have the extension installed. http://phpseclib.sourceforge.net/

>Hmmm. Any way to modify it to show based on permission levels, ie support staff can see root password based on -requirementhere- and admins can see root password based on -requirementshere-? Personally, I think storing root passwords permanently in a central database is NOT a good idea. If you are selling unmanaged servers, there is no need for you to have root access on the customer's server. Granting yourself more access than you strictly should have for the type of service you are offering can generate interesting liability problems, if your central database is ever compromised. If you do provide server management, there are more secure options like SSH public key authentication to access the server, with the added benefit that it still works if the user ever changes the password... >I think for the most part, the UM module set up for Dedicated Servers are pretty much set. I just need to eventually link it to something else, such as maybe NOC-PS's server management plugin that they released for Blesta... >so that the order once completed and approved, sends it all to NOC-PS. Or maybe I'm just duplicating NOC-PS's efforts. :U Nah, we are not working on order forms and such. Think that's more a task for the Blesta team, as that's not something specific to our software.

Power management yes (start, stop, reboot) You need to own a L3 router supporting netflow/sflow if you want data traffic graphs for VPSes. A normal managed L2 switch is sufficient to account traffic for dedicated servers, but that will NOT work for VPSes as it accounts per switch port instead of per IP.

Correct. VPSes are treated like dedicated servers (we only support hardware virtualization, not Xen PV nor OpenVZ) and require a PXE network boot infrastructure which NOC-PS provides.

Looking at the intro page ( http://www.php.net/manual/en/phar.using.intro.php ) it seems you can set bootstrap code with setStub()

Download link for the module: http://www2.noc-ps.com/docs/blesta-module-installation/ (only useful if you already have a NOC-PS server to manage your racks)

If you want the module to do something useful it costs money. The NOC-PS management server costs money The module that is needed to connect Blesta to the NOC-PS server is free. But having the Blesta module without the server, is like having the Blesta cPanel module, but no cPanel server.

Yes, we also have a module for Blesta v2 v3 is more powerful, but v2 is easier to work with if you have a simple tiny module that doesn't need anything special. E.g. as I mentioned in another thread, you currently need to implement 9 methods and 3 template files to get a screen to edit the servers ("module rows") and server groups. It is great that it is possible to customize that just the way you want it (more power), but it would also be convenient if for common cases (each server having a hostname, username and password) there was a standard default implementation to inherit from.

The provisioning software used by the module is commercial, and costs start at 100 EUR / year. See http://www.noc-ps.com/ The Blesta module itself will be available at no extra cost, once we cleaned it up.

First go at creating a Blesta v3 module for interfacing with our (commercial) server provisioning software. Once the server order has been approved the customer can login to the client area and choose which operating system profile to install on the server, and specify root passwords. For security reasons the passwords entered are only used during installation, and not stored in Blesta. That's also the reason the customer has to wait until the order has been approved before provisioning the server, instead of entering the details during the order process. The installation progress can be monitored Data traffic can be viewed provided the server is connected to a managed Ethernet switch The customer can power up/down/reset his server provided it has a IPMI/BMC/iLO/DRAC/AMT management chip or is connected to a remote power switch such as those made by APC. In addition to provisioning dedicated servers, VPSes are supported as well. Can automatically let it create Citrix Xenserver, Proxmox VE 3, oVirt and Vmware vSphere VPSes, using the specifications configured in the package settings. Dedicated servers can be assigned manually by staff approving the order, or assigned automatically from a predefined pool of available servers. For Xenserver, Proxmox and oVirt we offer a HTML 5 console that only requires a recent browser, and not any additional plug-ins. Still have to clean up the templates a bit, and give them a more Blesta look & feel, as they are based on the module we offer for another billing panel. Also the data traffic feature currently only shows pretty graphs, but doesn't actually bill overage.

It would nice if Blesta was able to bill overage usage. Preferably in a standardized way that could be used by multiple modules, and where Blesta would provide a common user interface to set limits and pricing for overage, rather than each module designing there own. E.g. modules could provide: a method that returns a list of things they can measure (e.g. bandwidth, power, disk space usage), and the unit used (e.g. GB or Mbit). a method that takes a begin timestamp and end timestamp and returns the raw numbers measured during that period.

Trying to write my own module. Noticed that I can use the convenience class ModuleFields to programmatically build a form for the interface to edit the package properties, without having to bother with .pdt templates. Which is great. However that does not seems to be the case for the interface to manage servers and server groups. It seems that currently each module independently has its own add_row.pdt, edit_row.pdt, manage.pdt templates and has to implement manageModule(), manageAddRow(), manageEditRow(), addModuleRow(), editModuleRow(), moduleRowName(), moduleRowNamePlural(), moduleGroupName() and moduleRowMetaKey() methods. Was wondering if that couldn't be simplified a bit in a future release. It would be nice if for the common case of a module row consisting of a "server hostname/IP" "username" and "password" a module could inherit from a common base class, and only had to provide a function to test the connection details entered.