There have been may that have indeed expressed their need for a Control
Server. You have brought up some great ideas! I've had this project on my
todo list or quite sometime, but have been overloaded with various other
projects. I am behind the idea of a Control Server, but would like to as
well see a portable win32 application which could be used to manage remoted
m0n0wall units by fetching current config.xml, making changes, and then
uploading back to m0n0wall server. Their would then be a initialization of
the config.xml file on the remote m0n0wall box, and a check to determine
whether a reboot is needed or not.
If you or anyone else would be interested in contributing to the projects, I
can open up a Projects page on my server, and we can get to work on the
features, design, and development of these solutions. I can setup a BB and
mailing list for these projects, and I imagine Manuel would list it as a
link at m0n0.ch/wall if we wanted him too.
On 5/11/06, Ole Barnkob Kaas <obk at tet dot dk> wrote:
> Hi all,
> With 20+ m0n0wall boxes in the field, central management is slowly
> moving to the top of the wish list. Others have had similar wishes and
> others again have even offered to build a win32 app. I would fancy a
> server solution instead where the management suite is running 24/7. Why?
> Some of my m0n0s are on dynamic ip, others are behind other nat-boxes
> and keeping track of ip addresses for the rest is... well.. not fun. So
> why not let all the m0n0s contact the central management server instead
> and download a new config if one has been updated. The time between the
> contacts could be specified in a TTL value (not in the config.xml) which
> is read each time a contact is made. And now we are at it - why not make
> deplayment easier too. Example:
> - admin: Boot a fresh m0n0 with default config
> - Fetch WAN ip and management server ip from dhcp (or login and specify
> them manually).
> - Request a unique name from the management server
> - admin: Login to the management server and specify a unique name.
> - fetch unique name and ca.crt from management server. Create key and
> csr and send it to the management server.
> - admin: Sign the csr on the management server.
> - Pull crt and encrypted config.xml from management server.
> - Decrypt config.xml, store it and reboot.
> - On bootup check for new config.xml and TTL value.
> - When TTL expires, check for config.xml and read TTL value.
> - If unable to contact management server within 5 mins after rebooting
> with a new config - revert to previous config.
> - Local changes to the m0n0 is uploaded to the management server once a
> day - and when requested.
> - A dead m0n0? Boot up a fresh one and specify the name of the dead one
> instead of a unique name.
> Maybe the management server could be run on a "fat" m0n0. The entire
> admin interface could be done in php and the encrypted configs and TTL
> values could be served by the http server. More advanced features like
> versioning and auditing would most likely require a "real" server.
> Sounds nice? But is it easy to build. I don't know much about BSD (I
> work mostly with Debian) and I'm not sure how much of the SSL stuff is
> already in m0n0 for the certificate stuff. And all the fool proof stuff
> migth not be so easy to implement as well. Maybe the certificate stuff
> should be skipped and configs should be fetched with https instead.
> Anyway - fetching and installing a config.xml from a http server would
> be a good start :-) Suggestions how to do this are welcome. I could
> ofcourse go ahead with wget, but maybe there are better alternatives
> (smaller size) I'm all ears :-)
> Ole Kaas
> To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
> For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch