Enterprise style Central Management Interface - {Now $1900}
-
I am happy to hear more support on this. Since there is support for having it be based on m0n0wall-cmi….PHP.....etc then I am for having this bounty be based on that solution also...or at least my contribution..$$$. I have implemented several pfsenses at several customer sites but would like to introduce a managed services solution similar to what Iomega is doing with Juniper Firewalls. This solution would finally allow me to build a business solution which would be able to generate revenue for my business. Once the money starts to flow I will have more to contribute...but I am starting at ground level right now...Still struggling with ways to standardize the boxes and keep them under $150...Dell boxes work for now but looking for something more professional.
The more contributors the better especially if they are willing to help out beyond the life of the bounty
As I mentioned before, I don't see this bounty as simple as adding a new feature with does not change much after building it. I do believe this type of solution will need constant maintenance with every build so I accept that even after the inital product is created it will need continued financial support. Once I can get this type of solution in place, I can begin to sell it to my customers as a managed service and will continue to contribute to this solution…
I have a mixed enviroment which I support...Cisco, Juniper, Sonicwall..pfSense....etc and have been on the fence on finding a solution to standardize on because of the issue of cost and managing all solutions. When I saw the m0n0wall-cmi it was the turning point for me where I realized that this could really be a final answer to my desire to provide managed firewall services without having to either charge or spend tremendous amounts of money to either support or provide as a service.
Anyways...my initial bounty is not final and I do plan to add more as this progresses...ie more money comes in to the coffers.
This might be part of another bounty but I did hear mention about SQL connectivity..I really like the idea about being able to generate reports which could be presented to my my customers as part of the provided service.
Mark
-
You could use java based if you wanted it os independant.
:( the bounty is for a management interface not a memory consuming good for nothing application
-
Agree with a lot of things, mostly the one that Java should not be used.
-
god no NOT JAVA….. as i said it will be designed to work in appliance mode, it does use the base of monoCMI but also is being extended to
meet other needs and requirements I also have. such as secure communications to firewalls/appliances and additional monitoring functionalities
enbedded. My overall goal honestly is to functionally be capable of monitoring and management of pfsense, m0n0wall, askoiza, FreeNAS and
potentially other m0no/pfsense based derivitives. as they all have some commonalities. I plan to develop this to meet the needs of not just pfSense,
but other BSD based appliances. We have a common framework BSD, PHP, XML that is central to all these. I have additional functionality I require
from a design and architecture standpoint. as I also plan to use a standard (REST) while developing this application. -
Fair enough only a suggestion just incase PHP wasn't an option, but yes memory hog it is.
-
I have been doing some research on solutions that might be able to be used for this solution. My thinking is rather than reinvent the wheel that there might be the possibility to incorporate solutions that have already been developed into this solution. In doing my search I made sure that any information I found did not involve Java since that seems to be an undesired application. All the links either are built for BSD or are compatible. Some use XML and as far as I could see all use PHP. All look to have the same licensing ie..GNU General Public License (GPL). Some of the links are more geared towards a network monitoring solutions…ie servers and applications which may or may not be something that could be part of the solution or as plugins requested via new bounties. Either way I hope that the information can help with the project.
Thanks,
Mark
http://sourceforge.net/projects/node-runner/
http://snm.sourceforge.net/
http://sourceforge.net/projects/ntm/
http://sourceforge.net/projects/hexsys/
http://sourceforge.net/projects/netsaint/
http://sourceforge.net/projects/nav/
-
Another requirement for my bounty. Sorry this thread keeps throwing suprises that I didn't realize would even be considered.
1. Must not be GPL.If I wanted to use GPL I would use Linux and a Linux firewall.
The license is one major reason I like PFSense. That is also why I want PHP PDO support in this so that there is a non GPL database option.
If this management system does find itself with a GPL license then I believe you will find that development will get split so that there will be a central management system that will harmonize closely with PFSense's license.
-
I will not touch anything that is GPL. Do your own homework on GPL vs BSD. This is not the place to open that can of worms since its been hashed to death on various lists such as FreeBSD's own lists.
-
Removed my post that Sullrich responded to. Found my answer and would prefer not to " open a can of worms" ;D with my questions and or comments. I will only look for solutions which have the BSD license. End of story.
Mark
-
The Dingo ate the GPL…. Dingo doesnt do anything GPL.....
-
I was thinking about the design of such a management software. Don't you think that it would be nice if the "pfsense side" module was a package ? I mean, the central controller using php/mysql under freeBSD, communicating with the pfsense boxes through a package installed on each boxes we want to be centraly managed.
This package would be a simple collection of useful php functions in distributed/centraly managed environments (like a proxy to pfsense core system), using XML-RPC or simple get/post queries(I heard someone talking about REST…).I'm just talking about the design, not saying it's the way it should be done. What do you think about that ?
-
IMO that has the advantage that it's not tied in to the base, which means that it's easier to upgrade the management interface functionality without worrying about keeping the base in step.
-
I don't mind it being a package as long as it doesn't make it more difficult to apply and configure. I do have a concern regarding the involvement of SQL and would prefer some clarification on how that might be implemented. My idea of an appliance is a single box which can perform specific functions but have all of those functions built in since it would not be a firewall by definition. SQL connectivity which I would assume would be another package which would install and be able to automatically configured. By this I mean one would install the mySQL package or other BSD Licensed SQL product. When installing the CMI package it would auto-configure the SQL package or via the CMI gui one could configure it. Any feedback or insight on how this would be implemented would be appreciated. I like the idea of packages because after this is completed I will probably look for a network monitoring solution as a package which would allow me to monitor other products…ie services, applications or devices. Any solution which would be implemented should be easily configurable and not require advanced knowledge of SQL for example.
Mark
-
I am curious what would be the best way to have the CMI communicate bi-directionally with the firewalls? One of the reasons I ask this is this solution opens the device to potentially allow other packages to interact with the firewalls..ie Network monitor. Considering that this is a possibilty I would think VPN connections between the appliance and the remote networks would allow any and all packages access to the remote locations. The only problem I have seen in the past with this is when either a customer is using the same internal subnet as I am using or 2 customers are using the same subnet. In the past I have used Cisco VPN Concentrators which would translate say my network of 192.168.1.0 to 172.20.10.0 to the customers 192.168.1.0 so the customer communicated via the 172 subnet and the concentrator receiving the packets would then convert them back to the 192 subnet. Small enviroments may not experience this but larger would. Sometimes asking a customer to use an entirely differnet subnet for there network is ok and sometimes not okay. Is there another way to allow other packages or services to communicate withremote firewalls with the same subnets? Maybe create vpn with an virtual interface on the remote loaction with a different subnet and then reroute that traffic back to the real internal subnet? Just an idea…maybe completely impossible? Better off buying a cisco vpn concentrator?
Mark
-
I will put $50 to this bounty
-
i have been looking at how Vmware Virtual Center manages their ESX servers, and they seem to use the following configurations:
the management server with vcenter and SQL (sql can be on a separate server if wanted)
the esx servers has OpenPegasus, a WBEM server, the Virtual Center Client pushes configurations to the ESX server OpenPegasus via CIM-XML over a SSL session (https?)Maybe OpenPegasus can be used for pfsense too?
http://www.openpegasus.org/page.tpl?ggid=799
"Pegasus is an open-source implementation of the DMTF CIM and WBEM standards. It is designed to be portable and highly modular. It is coded in C++ so that it effectively translates the object concepts of the CIM objects into a programming model but still retains the speed and efficiency of a compiled language. Pegasus is designed to be inherently portable and builds and runs today on most versionsof UNIX(R), Linux, OpenVMS, and Microsoft Windows."i'm really impressed on how Vmware's Virtual Center Client is managing multiple ESX servers, and would really like to see something similar for pfsense. (but thumbs down to vmware for not making it a multi-platform client :( )
-
And in case someone wants to know about the licensing it uses the MIT license. ;D
http://www.openpegasus.org/license.tpl?CALLER=license.tpl
-
I work a lot with ESX and Virtual Center and sure it is impressive. VI client is built with .NET and uses smart and cool controls built by vmware themselves. VI client uses SOAP to communicate to virtual center server which then uses CIM-XML to contact ESX hosts (service console is a redhat based vm).
That's why their "SDK" is very simple, it's nothing but the documentation of the SOAP webservice :-D. They also provide a pre built proxy for faster access (.net XML serialization/deserialization is damn too slow), so managing VC by code is easy.Their design is not so bad… perhaps too plateform dependant on the administrative side.
-
Hi,
I'm fairly new to pfsense however I really like the idea of the CMI. I'd be more than willing to help with any PHP development of said application, I have quite alot of time to spare at the moment and can dedicate other resources to the project, hosting, test platforms etc.
If someone wants to go about the project then let me know.
-
If someone wants to go about the project then let me know.
That is a good question. Dingo and several others have voiced interest in working on this bounty. Everyone seems to have posted their requirements. I do not know if one person will be taking this bounty or if it will be split between multiple devs. Mcrane, Juve and Dingo have expressed interest in this. Please correct me if I am wrong but Dingo asked for our final reqs which one might assume he is working on this. Some clarification would be nice. If someone could officially claim the bounty so I know that the money I budgeted isn't just sitting there.
As to helping you might want to ask Dingo, mcrane or Juve.
Mark
