GUI/Flow Help for creating easiest to use Central management for CPF

[Guest]

[panic]

Hey pengbo,

Great post - good synopsis.

Re. your proposed Corporate model, how about if the console was on a dedicated server and pushed the updates out to the workstations AND to a second server? This second server would act as a fail-safe when the main server was down. When the main server came back up, the secondary server could relinquish "master" status, and also pass any updates to the main server that had occured in the interim. Constancy and consistency are critical, which is why I keep pushing the concept of distributed masters.

I take your point about Home LANs being the most difficult, but I genuinely believe that this is where the most advantage can be gained, particularly using the distributed master model. You have a Linux server up 24/7 - but how many average households have that? The vast majority of networked houses rely on Windows simple networking for internet sharing, file sharing and print sharing and, as such, have a typically ad-hoc nature with no one PC guaranteed to be on at any one time. Yes, it's be hard to get it right, but that makes the reward more truly earned. 

SME - right on the money - most small businesses don't even know they have a need for this, but the consistency and constancy it would provide (not to mention the cost savings by having a single download) are fantastic. I hoipe Comdoo screw their marketing caps on, cause this could be a real money spinner for them.

Parental - I've read the "my PC is king" line and my immediate thought was "my LAN is king". I say this because if PC is not right, I don't want that fault propogated to the other PCs on the LAN. If the "king" is down, are the other PCs left to defend for themselves? Just MHO, but I still think the distributed model is valid wherever MS peer-to-peer networking is used.

Re. who would be in charge of the console, the original intent was that the CMC would operate simultaneously in two modes. One mode (master/slave updates distribution etc) would be transparent to the users and the other mode would allow a user to login to the console from any PC on the LAN by means of a master password common to all PCs running CMC, temporarily acquiring "config master" status, and allow them to check logs, modify rules, permissions etc. and push the changes across the LAN. This, combined with the distributed master model, remove the reliance on any one PC or any one location.

It's been an interesting idea watching this develop. It'll be fun to see how closely the users ideas are reflected in whatever Comodo release.

Cheers,
Ewen :-)

[pengbo]

Thanks for the reply panic.

I see exactly where you are coming from about consistancy etc but I just don't see the need for 100% uptime on this.

If I was running this in a corporate environement I wouldn't be that bothered about it being available every second of the day.  In work we have an admin server for this type of medium to low risk applictions.  It's responsible for coordinating the AV definitions and keeping logs with a syslog server.  It could easily do this function as well.  You might be slightly agast that I might be lumping AV in medium risk but I am not just the service that keeps all the AV definitions uptodate is medium risk having upto date AV is very very high risk.  However if we get one or two av def updates a day we consider ourseleves blessed (another reason for not liking McAfee) so any service keeping things on an even keel doesn't need th highest availability.

Combine that with an image of the server taken with True Image and you could have it up and running again in not time with any virtual server.  So I really don't see the need to have a backup and for all the servers to need to knwo what each other are upto.  One server for this is enough.  I certainly wouldn't want the CMC to be on every server.

For very similar reasons I wouldn't be installing CMC on every PC on a workgroup network.  It really doesn't require it as it's not high availability, nothing it's doing is high availability.  It's not like group policies or user profiles in a domain.  If your PDC or BDC are not available then yes things wont work and you are in deep doo doo.  CMC would not need to be in the same category, I just think it's asking for it to make it that complicated.

You ask what the clients should do if they can't find the server. Well if they are firewalls then not a lot.  The rules are working and will continue to work until you change them.  If they detect an intrusion attempt then they block it and store up logs until the server can take them off them at best it depends how critical you want the logs.  It would probably be better to store them until the server asks for them along with a status update anyway.  AV would be a bit trickier but not massively so as I am sure some acceptable scenario could be arrived at.

The more I think about it the more I am coming to realise a distributed system would probably cause mor hassel than I would be prepared to put up with.

[jharris1993]

We're BAAAACK!

(and, I'm still trying to get my body to crawl back from GMT +3 to -5)

Totally un-related to anything else comment:  Avoid Heathrow Airport like the Plague that it is.

Here is my two Centavos, kopeks, Lira, pence, or whatever...

In essence, this is my "wish list" for something like this.

1.  Ideally the CMC should be an "optional, added extra" attraction - not a required piece.

i.e.
If Comodo offers a AV product, a firewall product, a spyware product, a universal time sync product, a registry or group policy product, ad nausium, each of these products should exist, and be useful as a seperate, stand-alone, product.

However, the CMC product should be able to detect what is available on each machine it's adminstering, provide some kind of reporting or status of what's there and what condition its in, and provide options to do things with it.

In other words, the products the CMC administers should NOT depend on the CMC to function, but the CMC should depend on the products - like a remote administrative wrapper.

2.  The CMC should allow the "central operator" to push modifications, or pull information, from the various programs it's connecting to.

For example, the CMC operator should be able to say "go to this computer, and install the following missing items - or go to that computer and update AV information - or go to all computers and make the following policy change, etc.

3.  The CMC should allow the operator to categorize the comptuers into "groups" - wherein each "group" can have a default profile, etc.

Example:  My wife's computer (and certain test computers I use) may be within one group, my own computer - including the O/S packs that I do the majority of my testing on - might be within another group, my server(s) within another, and so on.

4.  Assuming that the operator has sufficient priveleges within his local subnet, the CMC should be able to initiate a "push" to a computer that has never touched a Comodo product before.

5.  Assuming that:
(a)  the operator has sufficient priveleges
(b)  there is a corresponding "CMC" unit at both ends
(c)  the operator has adequate credentials to access the CMC unit at the other end
The CMC operator should be able to connect outside his local subnet, to a CMC unit that he has access to in a remote location.

Example:  My brother, and my mom, are both fairly savvy, but are not the sharpest tools in the shed.  I would like to (in some way) establish both my brother's computer, and my mom's computer - many states away - as additional nodes that I can administer.  This way I can insure that they're up-to-date for virus protection, etc. etc. etc.

6.  Any credential sharing should use (at the very least) a fairly strong encryption. minimum 128 bit, more if possible.

I may come up with more ideas later on...

Jim

[jharris1993]

My two centavos on where this product should go:

I would target this product for the SOHO / power-user segment.

1.  The typical, plain vanilla "home user" would probably find this way, WAY over the top for his personal use.

2.  Any business with any kind of REAL conjones, will likely have a more advanced system (like a Baracuda, or some such) - and IT staff to keep it working.

However - there is a "market segment" - the SOHO and/or power user market (like myself) where I have a fairly sophisticated network - a few machines or so, (maybe even a dozen or so), and dealing with individual copies of pieces of software can be a pain.  Also, makeing sure that everyone has their spyware/AV up to date is a pain, etc.

Like a previous writer, I tried messing with the McAfee Total Protection SMB product - shelled out some hefty coin for it too - and it was a pice of GAGH!  Tossed it back & got a refund.

I, myself, would like a centralized management solution that is not unlike the McAfee offering, but without all the grief.

I could see the smaller businesses - I have a friend who is a general contractor for home improvements, buildings etc. - his wife is an Architect - and they run a business together using several computers.  The ability to centrally manage the protection on all these computers could well be valuable for them.

Even larger businesses - Real Estate offices with seventy to a hundered desks, or more, might well want to try something like this before shelling out the huge coin for a more "server based" system.


With regard to the "multiple master" paradigm, I would like to offer a suggestion:

KEEP IT SIMPLE, STUPID!

That's what my first semester Calculus prof wrote on the blackboard on our first day of class.  Has done me a world of good ever since.

My ideas on a topography:

1.  Take a line from The Gambler by Kenny Rodgers - "Every hand's a winner and every hand's a looser..."

Make it possible that any machine within the CMC network can be the "console" machine.  For example, if I'm at my "normal" machine here in my basement, I should be able to open a CMC window and see the condition of my entire network.  Likewise (based on credential) if I am on my wife's machine, or my brother's machine, or wherever.

2.  Allow the operator to choose one of two modes of operation:
(a)  Totally ad-hoc  (each computer gets updates from Comodo for itself - but can respond to the CMC)
(b)  Centralized update - failing back to totally ad-hoc.  (I can nominate one machine - my DC for example - to be the "central update server" for my network, but if (for whatever reason) that machine is not available or is busy, it can get information on its own.

3.  Allow that mode to be selectable on a "per-group" basis.  For example, all the computers here in my basement may use my DC as the update server, but the remote computers in Virginia where my brother and my mom live, would get updates on their own.

4.  Make each node of the CMC structure essentially autonomous.  CMC will retrieve information, but the nodes don't depend on it.  Also, I would store information on the individual nodes, not on the "central server" (maybe that should be configurable too?)

Just rambling.

Jim

[panic]

Thanks for the reply panic.

I see exactly where you are coming from about consistancy etc but I just don't see the need for 100% uptime on this.

Bots don't sleep. 

If I was running this in a corporate environement I wouldn't be that bothered about it being available every second of the day.  In work we have an admin server for this type of medium to low risk applictions.  It's responsible for coordinating the AV definitions and keeping logs with a syslog server.  It could easily do this function as well.  You might be slightly agast that I might be lumping AV in medium risk but I am not just the service that keeps all the AV definitions uptodate is medium risk having upto date AV is very very high risk.  However if we get one or two av def updates a day we consider ourseleves blessed (another reason for not liking McAfee) so any service keeping things on an even keel doesn't need th highest availability.

Combine that with an image of the server taken with True Image and you could have it up and running again in not time with any virtual server.  So I really don't see the need to have a backup and for all the servers to need to knwo what each other are upto.  One server for this is enough.  I certainly wouldn't want the CMC to be on every server.

The main LAN I work has 3500 nodes, 130+ servers and 3000 *****s. We have to provide a guaranteed uptime of >99% to ensure availability of services. We rely heavily on redundancy and failover servers. Each LAN and its requirements (legislated or commercial) is different. Maybe the distribution model should be optional.

For very similar reasons I wouldn't be installing CMC on every PC on a workgroup network.  It really doesn't require it as it's not high availability, nothing it's doing is high availability.  It's not like group policies or user profiles in a domain.  If your PDC or BDC are not available then yes things wont work and you are in deep doo doo.  CMC would not need to be in the same category, I just think it's asking for it to make it that complicated.

Bit confused here - a workgroup LAN wouldn't have a PDC or BDC - that's what makes them a workgroup LAN. The fact that they don't have a single dedicated server is why I thought a nomadic server module would best suyit this environment.

You ask what the clients should do if they can't find the server. Well if they are firewalls then not a lot.  The rules are working and will continue to work until you change them.  If they detect an intrusion attempt then they block it and store up logs until the server can take them off them at best it depends how critical you want the logs.  It would probably be better to store them until the server asks for them along with a status update anyway.  AV would be a bit trickier but not massively so as I am sure some acceptable scenario could be arrived at.

True enough, the world wouldn't end if the CMC server wasn't available, but if the distributed model was used, unavailabilitiy wouldn't be a question unless every PC was turned off, and then there's no problem at all.

The more I think about it the more I am coming to realise a distributed system would probably cause mor hassel than I would be prepared to put up with.

We're not all one person, so there's not just one opinion out there. It's interesting to see the differing opinions here and even more interesting to talk to other LAN operators and see what they think. What I've found is that over 80% of people who don't understand how the distributed model work really seem to just "get" the concept of it always being available, regardless of the status of their servers/LAN.

As always, your input and opinions are welcomed and appreciated.

Cheers,
Ewen :-)

[panic]

1.  Take a line from The Gambler by Kenny Rodgers - "Every hand's a winner and every hand's a looser..."

Make it possible that any machine within the CMC network can be the "console" machine.  For example, if I'm at my "normal" machine here in my basement, I should be able to open a CMC window and see the condition of my entire network.  Likewise (based on credential) if I am on my wife's machine, or my brother's machine, or wherever.

You're getting warmer!  My original concept was that CMC would operate simultaneously on two levels - one layer is the updating master/subordinate layer that operates without human intervention and the second layer is the management console. If CMC is installed on all nodes, the master/subordinate stuff just happens, but you should be able to login to the CMC user console on ANY PC on the LAN using a master password.

2.  Allow the operator to choose one of two modes of operation:
(a)  Totally ad-hoc  (each computer gets updates from Comodo for itself - but can respond to the CMC)
(b)  Centralized update - failing back to totally ad-hoc.  (I can nominate one machine - my DC for example - to be the "central update server" for my network, but if (for whatever reason) that machine is not available or is busy, it can get information on its own.

If (a), are we losing the bandwidth advantage of having just a single download for updates?
If (b) what is wrong with the concept of PC "A" being the designated server and if it goes off the air, PC "B" jumps up and says "I'll get the updates from now on" and assume the role of the centralised distribution server. All we have done is changed the location of the server, not the nature of it or the work it is supposed to do. Maybe we should have the option of reverting back to PC "A" when it comes back on line and have PC "B" forward any changes made in the interim to "A".

3.  Allow that mode to be selectable on a "per-group" basis.  For example, all the computers here in my basement may use my DC as the update server, but the remote computers in Virginia where my brother and my mom live, would get updates on their own.

Great idea, but isn't the remote connection and authentication getting away from the KISS principle?

4.  Make each node of the CMC structure essentially autonomous.  CMC will retrieve information, but the nodes don't depend on it.  Also, I would store information on the individual nodes, not on the "central server" (maybe that should be configurable too?)

If the localized info is stored on each PC, would it be better to have it passed between nodes and merged into multiple, identical copies of a unifed databse. This could happen under low load times on the LAN, whereas having disparate copies would require live polling and retireval when logged into the console. Some consoles should be able to opt-out of the CMC model, though, of course.

Good to see you back on board, Jim.

Cheers,
Ewen :-)

[jharris1993]

You're getting warmer!  My original concept was that CMC would operate simultaneously on two levels - one layer is the updating master/subordinate layer that operates without human intervention and the second layer is the management console. If CMC is installed on all nodes, the master/subordinate stuff just happens, but you should be able to login to the CMC user console on ANY PC on the LAN using a master password.

Panic,

Quoting a famous Garfield cartoon of many years ago:  "What we have here is a lack of communication..."

You seem to have a particular operating model in-mind - a multiple-master administration system.  My point is that - even at the "power user" level or SOHO level, this kind of multiple-master implementation could well be way, way overkill.  Why should we have a browser election every time someone breaks wind?

Using the CAV product as an example, I am presuming that it is perfectly capable of going out and getting it's own updates w/o CMC.

IMHO, the value of CMC is that it lets me "administer" (change settings on, view status of) the CAV installation on other machines, elsewhere in my network, without having to physically go to them.  (I can update a CAV setting on my wife's machine w/o having to physically go to it - or kick her off the box if she's using it herself.)

I really could care less if the boxes all got their own updates or got them from a central source.

You seem to be looking at this from the "thirty gazillion *****s" scope of implementation, I am looking at it from the "I have anywhere from 6 to 12 machines scattered around that I am responsible for" scope of implementation.


On another topic - let's look at the "multiple master" implementation on a "thirty gazillion *****s" scale - AND - we have the potential of multiple masters distributed over multiple subnets in a huge networked arrangement.

Wouldn't the need for consistancy - "99.9999% uptime" type consistancy - require a LOT of network traffic?  Even if all they do is poll for heartbeat every so often, the network polling frequency is something like 2ⁿ, or maybe even n! - (whatever...) - in any event, it's a geometric, not arithemetic progression - the more nodes you have needing to poll, the more "noise" your network is going to have just to accomodate the polling.


As a suggeston:  I would like to suggest that we start with a SOHO scoped idea - get THAT working, and then work on expanding it when the kinks are out of the SOHO version.

Comodo could release several versions - increasing complexity - based on the user's needs and the size of their network universe.

If (a), are we losing the bandwidth advantage of having just a single download for updates?
If (b) what is wrong with the concept of PC "A" being the designated server and if it goes off the air, PC "B" jumps up and says "I'll get the updates from now on" and assume the role of the centralised distribution server. All we have done is changed the location of the server, not the nature of it or the work it is supposed to do. Maybe we should have the option of reverting back to PC "A" when it comes back on line and have PC "B" forward any changes made in the interim to "A".

Using my paradigm - the SOHO paradigm - the network load for a dozen or so machines is not going to be that great, not unless the Comodo products are so abysmally designed that they're going down the "Commode-oh!"

Since I'm looking at a much smaller network universe than you are - I am willing to create a single point of contact on my network - but allow it to be bypassed if it's un-responsive for any reason.

Additionally, in the SOHO model, the only machines guaranteed to be up all the time (hopefully!) are the system's server for authentication.  In a workgroup model, it's anyone's guess who's on first.

It appears to me that your paradigm is designed with the idea of "can we make this work well enough so that we can get companies the size of M$ to use it?"  (that is, an "enterprise" model)

I think a more constructive and useful paradigm is the SOHO model - these are the people who may need and want a more central admin type feature, but not be in a position to shell-out the huge bux that most companies want for their "centralized management systems" - they start at somethign like $.5K and go up into the thousands of smackers, real fast.

Companies the size of GM, Toyota, M$, et. al., can afford armies of experts and expensive software to crawl all over their systems.  The SOHO sized business often cannot.  If we could serve this smaller-sized business segment - (especially considering how ABYSMALLY the other AV/Security companies are doing it - GAAAAK!  BARF!!) - Comodo could have a real coup on their hands!

Great idea, but isn't the remote connection and authentication getting away from the KISS principle?

Not any faster than the multiple master, enterprise paradigm is...

Good to see you back on board, Jim.

Cheers,
Ewen :-)

Glad to be back, all that sun, sea, exotic Med ports of call, good lookin' dames, excellent food, was beginning to wear thin.... (laughing!)  The part getting worn thin was my WALLET!!

Jim

[jharris1993]

What is wrong with the concept of PC "A" being the designated server and if it goes off the air, PC "B" jumps up and says "I'll get the updates from now on" and assume the role of the centralised distribution server. All we have done is changed the location of the server, not the nature of it or the work it is supposed to do. Maybe we should have the option of reverting back to PC "A" when it comes back on line and have PC "B" forward any changes made in the interim to "A".

One last comment based on the above quote:

Let's assume:  (an Enterprise scaled question)

1.  I have a network that has "n" CMC nodes (computers)
2.  My network is divided into "x" subnets - and not every subnet can reach every other subnet. (not uncommon)
3.  Within the "n" nodes distributed over "x" subnets, assume that there are "q" potential master computers, with a subset - q' - being available to a particular node located at some random point within the network architecture.

Assume that computer "Z" is the main master, and that the set of computers "q" are the sub-masters.

Assume that all computers everywhere can see "Z"

Assume that all computers everywhere can see at least a subset of "q" (q'), and that any computer within "q" can see every other computer within "q" - as well as "Z"

Assume that any node can reach the Internet.

If "Z" goes off-line for whatever reason - and a particular node decides to phone home - how does it know which of q' is going to be the "new" master it is supposed to use - especially since it may not necessarily see every computer within "q"?

In scalable web systems, there is usually a sophisticated load-balancing server located at the "head" point (www.taxcut.com on the last day to file taxes, for example) - that leads to a whole forest of humongeous servers (0001.taxcut.com, 0002.taxcut.com, ..... , 1974.taxcut,com, .... etc.)  With this - if any one server is down, busy, "in the can", "taking a smoke", or whatever, the load balancer simply sends the e-filed tax return to one of a whole host of others.  To the outside world, everything looks like "www.taxcut.com" - even though internally it could be something completely different.

Surely you're not suggesting implementing a load-balancing server as a part of your paradigm?

Again, I would like to most humbly suggest that we start with a considerably smaller-scale version before we try to take on something the size of the US DOD. (grin!!)

What say ye?

Jim

[panic]

The only real hiccup is that the points you have raised are only applicable to the segmented enterprise market.

Don't just think outside of the box. Think of all the other types of boxes. 

In the sub-netted example you've quoted, would it feasible to have a CMC master within each subnet?

Alternatively, have a "master of the masters" server that can communicate with each CMC server with each subnet.

Ewen :-)

[jharris1993]

The only real hiccup is that the points you have raised are only applicable to the segmented enterprise market.

Don't just think outside of the box. Think of all the other types of boxes. 

In the sub-netted example you've quoted, would it feasible to have a CMC master within each subnet?

Alternatively, have a "master of the masters" server that can communicate with each CMC server with each subnet.

Ewen :-)

Ewen,

Apparently, I was not communicating efficiently - let me try again.

My example was intended to show a potential weakness in the "enterprise" type scale system that you and your companyeros seem to be advocating - while draining the swamp, you may become rapidly overwhelmed by the alligators that might object to the swamp being drained... 

What I am trying to advocate for is - initially - create a CMC that is scaled to a much smaller audience, since that is where I think Comodo will get the most bang for the buck.

Re:  "Think of all the other kinds of boxes."

This is exactly my point.  The entire structure you - and others - have been advocating is one that would be especially effective at the HRB world headquarters IT center scale, but would drive the "smaller scale" users - like me - absolutely out of our minds.

I, for one, don't particulary care if "100% up-time" is a requirement for the entire CMC system, because it won't be up 100% of the time.

All I need is the ability to administer the Comodo products on my system, and (for those that depend on regular updates), have that available somehow - though a central update master, individual updates, trancendant miracles from above, buring brown rice, or whatever.

The point I am trying to make here is this:

1.  I can divide potential users into four broad (and overlapping) categories:
(a)  Home users - who have one, or very few, computers to manage
(b)  Power-users (like me), and the SOHO/small business user - who has enough computers to manage that, though he can do it on a machine-by-machine basis, centralized control is desirable.  However, the usual "centralized control" products are way expensive and/or complex.
(c)  Corporate users - who have the budget to have dedicated staff and software for this task - they usually already have a "payware" solution in place.
(d)  Enterprise users (with several and/or many corporate segments) - here the budget and staff becomes a dedicated department - and they have some outrageous system implemented.

2.  IMHO, user types 1, 3, and 4 represent user types that are already being adequately served by existing products.

3.  User type #2 is the one who "falls thru the cracks" - this user is big enough that individual, computer-by-computer management is now a pain, but isn't big enough to afford a "corporate" system with the $$$ per-seat licenses.

At the risk of beating a dead horse yet again - please let me urge everyone to try (at least initially) to scale for the user type #2 user - this is where you will have the greatest impact.

Respectfully submitted

Jim

[gibran]

Ye Ha!!!
Hola companyeros!

I let the brainstorming session develop a little. Just to have an overall idea of what was going on...

In order to get a more profitable session I would advise to switch to a functional approach and to specify the max number of nodes and the network topology suited in each approach.

It is true that in order to maximize development/value efforts some choices are needed, but in order to have a real possibility of extending the 1st implementation we need to have an overall idea of the largest possible set of features needed.

One more thing, I don't know Comodo position on this, but if the architecture will be highly customizable it would be possible to make it a de-facto standard and then let certified developers or companies extend it generating revenues from royalties.

Hasta la vista...

[gibran]

On another topic - let's look at the "multiple master" implementation on a "thirty gazillion *****s" scale - AND - we have the potential of multiple masters distributed over multiple subnets in a huge networked arrangement.

Wouldn't the need for consistancy - "99.9999% uptime" type consistancy - require a LOT of network traffic?  Even if all they do is poll for heartbeat every so often, the network polling frequency is something like 2ⁿ, or maybe even n! - (whatever...) - in any event, it's a geometric, not arithemetic progression - the more nodes you have needing to poll, the more "noise" your network is going to have just to accomodate the polling.

Regarding Network traffic it would be a better solution to consider IP Multicasting rather than broadcasting.

My original concept was that CMC would operate simultaneously on two levels - one layer is the updating master/subordinate layer that operates without human intervention and the second layer is the management console. If CMC is installed on all nodes, the master/subordinate stuff just happens, but you should be able to login to the CMC user console on ANY PC on the LAN using a master password

Regarding the update function it would be useful to consider it separate from CMC and the master-subordinate mechanism would be one way of accomplishing deployment. The CMC should be used to set priority among various deployment strategies (among other  things...)

The CMC operator should be able to connect outside his local subnet, to a CMC unit that he has access to in a remote location.

Example:  My brother, and my mom, are both fairly savvy, but are not the sharpest tools in the shed.  I would like to (in some way) establish both my brother's computer, and my mom's computer - many states away - as additional nodes that I can administer.  This way I can insure that they're up-to-date for virus protection, etc. etc. etc.

Something like this would be possible using Hamachi

[Tags:]