Dang! You’ll make a boy blush! Thanks Ryan - it’s a great concept and I’d pay for this as well. Everybody I mention the idea to would as well. Melih, that might be a way to make money off the free products. Sell this as a controlling mechanism for all the Desktop Security Products range. Adding parental control would only enhance the sellability of it.
Great idea Ryan and very logical.
Re. assuming mastership if your daughters PC is switched on first - why would you need to (at the update and distribution level, anyway)? Whether her PC downloads and distributes the updates or yours does, what does it matter? They are only downloaded once, so bandwidth is preserved. The unwritten bit about config and ruleset changes may address some of your issues. I haven’t outlined this bit yet, so you have pre-empted some things I’ve been mulling over.
My idea is to have the Comodo Management Component (CMC) operate at two distinct levels. One for downloading and distribution of all Comodo updates. The other for controlled access to the configuration of each of the apps. You should be able to log into this level of the CMC regardless of who the update/distribution master is.
What could be done is if your daughter tripped a parental control (Amazing how we can just assume something will be done, isn’t it? Geeze we’ve got some faith in you, Melih! ;)), it would be blocked and recorded in a log. When you logged in on your PC and connected to CMC, it would send a request for alerts to the other PCs on the LAN. This would then be sent back to the config “master” and then you can kick her in the bum. LOL.
I had envisaged that all sorts of stuff could be requested by the config master from the other PCs, examined, adjusted and then forwarded to the other stations. The main idea was to enforce uniform firewall rulesets and AV settings, where you could make a firewall ruleset change on PC “A”, login to CMC and forward the adjusted ruleset to PC “B”. But the idea of other data being collected and disseminated merely extends the usefulness of the concept.
You said “into the mix of tasks it could perform”. OK wise guy, what other tasks do YOU think it should perform?
Add!
Extend!
Refine!
This is, IMHO, a real opportunity to help create a product that can deliver REAL benefits to real people in the real world. The more I think about this idea, the more I truly think it has merit for the home market/small LAN segment. Even if it never sees light of day, I’m getting a real buzz out of thinking this through. If it does see light of day, I’m going to be proud to hang my hat on a small corner of this. It’s ages since creativity and passion got so lit up! I’m having an absolute ball with this.
Jump on in!
Thanks for your kind words, Ryan - truly appreciated.
Ewen
hmmm… Is it just network control rules that are being propegated here? or are Application Rules also going to be distributed? If so, how will the importing the distributed rules handle the applications not being installed in the same path, or being of the same version / Service pack?
(I’ll be thinking about this as I am typing, so be prepared for some evolution throughout this post)
I’m also not so sure the first version of this tool needs to be so complex right away. Depending of course on your target audience.
I’m here to offer my perspective, a home user of CPF who currently has CPF installed on his PC. There are 4 other PC’s waiting for CPF in my household (one’s actually going to get reloaded with Win2K3 Server when I get motivated), and after learning that the rules can be exported from the registry, I’m one step closer to a full scale distribution. So my less complex offering stems from this.
In my house, on my workgroup, my PC is King… I share some drive space with my wife’s and kid’s PCs, manage printer shares, etc… So if I were to think of a Central Management solution, my PC would be the center of it. And it would begin with something simple like an export of my current settings stored in a file, that file would be available over the LAN, and other satellite CPF installations looked to and sync’d with it. If you wanted, the satellites could even take a copy of the file in case one needed to make an emergency new “master”.
Now, it can be an application outside of CPF that acts as either the client “sniffer” or server “publisher”. This tool would handle updating the config file from my PC, propegating my rules. This tool would be loaded on the client PC’s in slave mode, polling the rules and importing where required.
You could even control which rules get pushed out by using an msconfig.exe style of checkboxes that is used on it’s “startup” tab. Display all the rules that were exported from the master, and check off the ones you actually want the clients to import… no sense importing rules for software that they don’t have loaded.
And there is no rule that says the “central file” (whether replicated between the clients or not) only has rules in it. Configuration by PC, showing who the master is, whether satellite created rules get pushed around as well, etc… could be included.
Maybe I am oversimplifying, but boot time arbitration of who the master is… is too complex in the first phase (if needed at all); from the perspective of my little LAN. And if targetting larger fish like corporations… you know they are going to want the “middle” to be their server. It just makes sense to me to start that way.
Good point. Given we want to allow freedom across the LAN for normal operations, it probably should be restricted to NM rules, with several NMs rules specific to each PC to cater for application specific access requirements.
I'm also not so sure the first version of this tool needs to be so complex right away. Depending of course on your target audience.
The problem is that if you don’t build in the structure from the beginning, it makes it much, much harder to add functionality later without having to re-engineer the whole thing. Make sure all the bones of the skeleton are there to start with (or are easily extensible) and hang the muscles on later, as needed. If the bones aren’t there, what would we hang the muscles off?
It makes it harder initially, but easier in the long run.
I'm here to offer my perspective, a home user of CPF who currently has CPF installed on his PC. There are 4 other PC's waiting for CPF in my household (one's actually going to get reloaded with Win2K3 Server when I get motivated), and after learning that the rules can be exported from the registry, I'm one step closer to a full scale distribution. So my less complex offering stems from this.
This is exactly the scenario I was thinking of - home LAN and not enough time to make sure you’re secure inside and out. Update distribution should be a relatively simple matter. Pushing FW config changes is going to get a bit trickier, but it should be achievable.
[qoute]
In my house, on my workgroup, my PC is King… I share some drive space with my wife’s and kid’s PCs, manage printer shares, etc… So if I were to think of a Central Management solution, my PC would be the center of it. And it would begin with something simple like an export of my current settings stored in a file, that file would be available over the LAN, and other satellite CPF installations looked to and sync’d with it. If you wanted, the satellites could even take a copy of the file in case one needed to make an emergency new “master”.
Being king is an onerous job. LOL. My take on this is based on non-reliance of a central or fixed master, given the ad hoc nature of home/small business peer networks. What would happen if your PC died? Wouldn't your network suffer? One of the underlying principle is that the "master" db of both updates and FW/AV config would be pushed to all PCs on the LAN, so any one PC could become the update master, and you would be able to log into the CMC from any PC, make a change and have it pushed to all the others.
Try and look at it from the perspective of “my LAN”, rather than “my PC”. It’s a big shift in peer network thinking.
Now, it can be an application outside of CPF that acts as either the client "sniffer" or server "publisher". This tool would handle updating the config file from my PC, propegating my rules. This tool would be loaded on the client PC's in slave mode, polling the rules and importing where required.
I envisaged it as being the same application on all PCs, not a server bit and a client bit. Have the one app capable of acting in both modes depending upon whether there is or isn’t an existing master.
You could even control which rules get pushed out by using an msconfig.exe style of checkboxes that is used on it's "startup" tab. Display all the rules that were exported from the master, and check off the ones you actually want the clients to import... no sense importing rules for software that they don't have loaded.
Good idea for the CMC config GUI. Feel like roughing one out?
And there is no rule that says the "central file" (whether replicated between the clients or not) only has rules in it. Configuration by PC, showing who the master is, whether satellite created rules get pushed around as well, etc... could be included.
One small point - who the update master is doesn’t really matter, does it? As long as one exists and is working - who cares? Re. whether a satellite created the rules - in the case of making a FW change and pushing it to the other PCs, try and think of CMC being two applications in one - one is an update module that can acts as a master or a slave, the second being a config module. If you know the config master password, you can access the config module on any PC and that PC then becomes the config master, even if another PC is currently acting as the update master. The two functional streams are different.
Maybe I am oversimplifying, but boot time arbitration of who the master is... is too complex in the first phase (if needed at all); from the perspective of my little LAN. And if targetting larger fish like corporations... you know they are going to want the "middle" to be their server. It just makes sense to me to start that way.
The boot time arbirtation could be as simple as 2 packets times however many PCs are on the LAN.
The subsequent heartbeart for master detect could be 2 packets again. Not a great deal of overhead.
Give the Central Management tool a [u]center[/u]! ;D
I was thinking along the lines of letting it run free across the LAN, rather than a fixed location. My aim was to minimize reliance, increase redundancy and enhance reliability.
Ok… if we are boiling this down to NM rules only, I don’t think that we’d need to worry about massaging the rules. If I look at the rules I created, any time i was referring to my PC, it was either Any or My ZONE… which would work great anywhere else on the LAN.
So if we are talking about pushing out 5 NM rules, let’s make it easier…
Either define a “Management Zone” (or let it be a “property” to set on the current Zones) or allow the ability to create a list of PC’s to sync with from within CPF
Extend the NM rule Add/edit/delete “events” to prompt the user “Do you want to propegate your change?” and if “yes”, propegate it to the “management zone” or PC List
To better handle “no” responses completely, add a “Propegate Selected Rule” to the context menu (right click) of the rules. In this way, I can say “no” until i feel i’ve got the rule right, then push it manually
When the recipient of the pushed updates receives the rule(s), it can check them against it’s curent list and only apply the changes (if we want to be fancy/safe), or if we always make sure the complete rule list is always sent then just let the received update overwrite what was there before.
No muss, no fuss, no worries about who is master, or who can change the rules… somehow define “who should get updates I make to NM” and allow the changes/additions/deletions to be pushed to that list.
So much food for thought! No wonder I’ve got a fat head! Good stuff Dan.
My first thought about the Management Zone was “Great!”, but how do we define this zone? By static IP, by whoever is logged on at the time, by subnet? The logical way would be by subnet and if its by subnet, do we need to define anything? Couldn’t it just read the ZONE tag from CPF, since we’ve already defined it?
Correct me if I’m wrong, but are you viewing the CMC as an integral part of CPF? I envisioned it as a separate management console for all Comodo products. If its going to be integrated into CPF, could this be considered “bloat” on standalone PCs running CPF?
How about this for an example
You log onto machine “A” and make an AV or FW change.
On machine “A” you log in to CMC and it reads the current rules set or AV config and displays it on the appropriate tab (or aggregates the latest changes into a single list).
It also displays a list of the current PCs on the same subnet as machine “A”.
A series of tick boxes to select what we want passed around
Another series of tick boxes to select which PCs to pass them to.
Click SEND to propogate changes.
Any exceptions for a specific PC would be passed around all the other PCs so they are cognizant of the exception, along with the current revision of the FW or AV config, in case you log into CMC on another PC next time you want to make changes.
This way, you can tinker with a rule until it’s right and only authorise it to be propogated when you log into CMC. Rule changes should NEVER be automatically propogated. They should only be able to be authorised when you have logged into CMC using the master password (you know, the master password that doesn’t exist yet ;))
We could also have an “Enforced Block All” setting to shut down all comms on all PCs, excluding CMC comms, in the case of an infection running amok.
What about the idea of being able to view the logs of any PC from the CMC console? That thought just struck me, but it sounds pretty good.
This is what I was aiming for, where CMC could send all sorts of stuff to the zone AND read all sorts of stuff from the zone. The more I think of that idea the more I like it - I’m lazy by nature sothis would help keep me in my comfy chair. LOL
Please understand, Daniel, I’m not shooting your ideas down, or saying mine are better. The whole idea is to bounce things around and see what sticks and what makes us all think a bit more or a bit harder.
Just had another thought about rules and exceptions.
What if we were able to split the rulesets into "standard"rules for all PCs and “specific” rules for specific PCs? If we had machines A, B, C, and D, where D was primarily used for online gaming and C was used for VOIP/Skype and D and C had specific port requirements, CMC could display the standard rules for A,B, C and D in one table and then separate subtables for the rule exceptions/additions on C and D.
Rule changes to “standard” rules could be propogated across all PCs (or not as you so select), and if you wanted to run Skype temporarily on PC “B”, you could pick up the skype rule from “C” and pass it to “B”, and revoke it once you were done.
These standard rules and exception rules would be passed around to all CMCs on the LAN to ensure accuracy and consistency.
I was still thinking a bit too “big” on this, but you’ve nailed some really good fine detail points.
The current “zones” can either be recycled or extended. If extended, it would simply be a property (check box) on the zone to set it to be a “management zone” as well.
I’m saying CMC doesn’t exist, little extentions to CPF can handle rule propegation; therefore, no bloat… let CMC be something else… maybe the enterprise tool. (or if you liked my previously idea about a central file, than ley CMC be the rules/config editor of the central file.)
The Rules could also be extended by adding a property (check box) on the Rule to set it to be a machine specific rule or one that the propegates throughout the “management zone”.
To indicate that this rule is administered by CMC only and cannot be editted locally? Good idea - this would prevent anyone but the holder of the master password being able to modify any of the global rules.
Very, very good thinking!
I'm saying CMC doesn't exist, little extentions to CPF can handle rule propegation; therefore, [b]no bloat[/b]... let CMC be something else.... maybe the enterprise tool. (or if you liked my previously idea about a central file, than ley CMC be the rules/config editor of the central file.)
If you think about it a little deeper, I think you’ll begin to see that there will be a fair amount of code involved in doing all this. All this code would then be in the firewall regardless of it was installed on a standalone PC and served no function on a standalone other than to occupy RAM. If CMC is built as a discrete application, its memory usage is transient and the only real modification to the firewall is to allow two dedicated channels that are preserved for CMC communications, even in emergency mode, and the ability to accept ruleset changes from CMC.
If you’re thinking I’m trying to stay away from modifying the firewall, you’re right. I believe the developers are on the right track with this, and I don’t want to intrude on their projected dev path too much. That’s why I have been trying to restrict CMC influencing the design of CPF too much.
The Rules could also be extended by adding a property (check box) on the Rule to set it to be a machine specific rule or one that the propegates throughout the “management zone”.
Is your main concern impact on memory footprint? While I agree that the code additions would be > 0, if a user opts to not enable the “management zone propegation of rules” function/feature, the code is never hit, and it’s business as usual, as optimal as ever.
But when I enable it, change my rules, the popup opens asking if i want to push my changes out, I click yes, client machines accept the “broadcast” and update… I just saved myself minutes.
… and then when a month goes by without the need to change/add/delete a NM rule, and the code was never hit, never broadcasted anything, no client ever had to receive or import a broadcast… and then compare that to your CMC heartbeat, master negation, replication, etc… usage of my network, which solution will be a leaner smaller footprint? :
No, my main concern is consistency, continuity and co-ordination.
While I agree that the code additions would be > 0, if a user opts to not enable the "management zone propegation of rules" function/feature, the code is never hit, and it's business as usual, as optimal as ever.
But the code still exists and memory is still occupied - even worse, its occupied doing nothing.
But when I enable it, change my rules, the popup opens asking if i want to push my changes out, I click yes, client machines accept the "broadcast" and update... I just saved myself minutes. ;)
and if you didn’t want to push the rule there and then, like if you wanted to fiddle around with it and test it, how do you store the fact that the rule had changed since the last authorised push?
.. and then when a month goes by without the need to change/add/delete a NM rule, and the code was never hit, never broadcasted anything, no client ever had to receive or import a broadcast... and then compare that to your CMC heartbeat, master negation, replication, etc... usage of my network, which solution will be a leaner smaller footprint? ::)
Agreed, but CMC is also acting as master/subordinate to send/receive updates in a co-ordinated manner for all Comodo apps, isn’t it?
What about if we wanted to use the CMC to co-ordinate antivirus or backup config/schedule changes?
Is it more efficient to create a single application that can be called from several others, or is it better to modify several applications to include the same functionality?
I can see where you’re coming from - making each app more powerful. But if the underlying principle is co-ordination and consistency, is it better to have the co-ordination and consistency handled by one independant application which can inter-communicate with all other apps across a LAN, or could it be done simpler by upgrading each application to handle this functionality?
You’ve got me thinking, now.
Which way, Dan - beef up all apps, or create a separate module inbetween all of them? What are your thoughts, Melih?
I think a rescoping is needed. A few posts ago, all we needed was a way to propegate CPF Rules because including application rules has its quirks… with such a “seemingly” narrow scope, putting the functionality in the app makes sense.
I haven’t read your Word doc’s Ewen, so I might be missing something… your mention of CMC dealing with antivirus now is new to me.
Give me the high level of what CMC should be? I feel like I’m only having half the info, or less…
I was getting the feeling one of us was firing a couple of cylinders short of a full block ;).
The original concept was that CMC would be one separate application operating on two distinct levels - 1) the first “level” would be the layer that arbitrated and became a master/slave for the purpose of collecting all updates for all Comodo apps and distributed them across the LAN and 2) the second “level” would be the one you could log into and push any firewall and/or virus changes around the LAN. This is why I’ve been pushing the de-centralised, distributed, non-reliance, redundancy, continuity and consistency barrow so hard.
Download the word doc (it’s attached) - it’s some of the best, most exciting stuff I’ve been involved in in 20+ years in the industry. There’s NOTHING like this for the home/small business LAN segment and THAT is where this type of stuff is most needed. I think Comodo could realy sweep the market with this concept and force a name for themselves, riding on CMC’s back, rather than on the excellence of CPF.
I think you’ll find if you go through this doc, then go back and re-read our posts and replies, you’ll see where the confusion has crept in. Mind you, your posts and replies have bought several things to light that will need to be considered.
Many thanks in advance. I really look forward to your comments and future suggestions Dan. This is a really cool project!!
Ok, but as long as their aren’t any aussie macro payloads in there that hunt down canucks… I mean if you need to pick on a canadian, start at the top and Whack The PM [url]http://www.whackthepm.ca/[/url]
Every effort should be made that the Server (Master) does not require a reboot when it pulls down updates and applies them to itself. I still like the idea of the Master being a Server, and IT people don’t like rebooting their servers. I’ve read posts that indicate that (for CPF for example) a service can be stopped, registries updated, and the services restarted to force rule imports. (It’s interesting how none of the clients needed to reboot after updates before reporting their version updates)
Is it implied that the Server (Master) not only houses CMC (and downloaded updates), but also has all the applications deployed on itself? Will CMC fail if the Server/Master does not have all aplication deployed on it that CMC is serving?
Are we eliminating the need for CMC to be aware of “what applications are installed where?” by having the client CMC’s report their version numbers of application deployed? Would CMC not become more intelligent if the Server (Master) recorder who all it’s clients were, what applications they had installed, and prepared a update “bundle” for each PC on it’s own?
I disagree with the master/subordinant negotiation channel, the master is the master. If it is not found, there are no updates to distribute and the client waits until the master arrived, or new master is promoted manually; at wich point it will broadcast itself without negotiation. I assume applications like CAV will still be allowed to download their own definition updates if the server goes AWAL? This would also depricate the requirement for all PC’s to know the status of all other PC’s updates.
Are the updates CMC manages restricted to application updates, or will it be controlling things like CAVS definition updates?
Interesting how CPF NM rules weren’t even in the original spec… no wonder I was out of sync… but hopefully it added some food for thought.
Sorry to jump in the middle of the current discussion, but I just wanted to get back to Ewen on his reply to me and comment on one other thing.
My idea is to have the Comodo Management Component (CMC) operate at two distinct levels. One for downloading and distribution of all Comodo updates. The other for controlled access to the configuration of each of the apps. You should be able to log into this level of the CMC regardless of who the update/distribution master is.
OK, that makes perfect sense to me. No matter what desktop and/or laptop you are using, you will have the ability to login to CMC. Excellent!!!
You said "into the mix of tasks it could perform". OK wise guy, what other tasks do YOU think it should perform?
Add!
Extend!
Refine!
OK so maybe I should have rephrased that. If the CMC works with the entire COMODO Security Suite, it will, IMO, place COMODO above all competition in the desktop security market.
This is, IMHO, a real opportunity to help create a product that can deliver REAL benefits to real people in the real world. The more I think about this idea, the more I truly think it has merit for the home market/small LAN segment.
I agree 100%, the more I think about it the more I would love to see this put into development. Now to jump ahead a little…
I can see where you're coming from - making each app more powerful. But if the underlying principle is co-ordination and consistency, is it better to have the co-ordination and consistency handled by one independant application which can inter-communicate with all other apps across a LAN, or could it be done simpler by upgrading each application to handle this functionality?
IMO, I do not think that beefing up the apps is the way to go. This brings back nightmares of running N*rton on a mid-level gaming PC. The resources it would consume made gaming virtually impossible unless you enjoyed moving in 2 to 3 second intervals.
Thanks for taking the time to go through the doc. The detail of your reply clearly shows the effort you’ve put in. v.v.v.v. much appreciated.
As an IT guy, I hate rebooting servers too. Our in house record is, so far, 7 years, 4 months, three days, 2 hours and 36 minutes, and still ticking over - an old 286 we ran up as a constant network sniffer that reports into your centralised security module. Its running a modified DOS and IP stack and you just cant kill it!
Having said that, let’s take our IT guys hat off for a second. When I first came up with the idea, I was thinking about ways to eliminate zombies and bots. They don’t, as a rule exist on corporate PCs, the bot armies are living in our neighbours loungerooms - not ours, because we’re IT guys ;). I started thinking of how we could introduce some means of ensuring that the teenagers/kids in these households were running a stable, secure, consistent environment. Most teenagers I know, turn off whatever they can to get the most speed so they can download as many songs (that they’ll probably never listen to) as possible. These unsecured machines are the barracks that the bot armies lurk in.
As such, most home networks dont have the advantage of a tech guy to get things running right. Most parents either don’t know, or turn a blind eye so they aren’t shown as being it-ignorant. This was where the concept of a centralised master password that applied to all PCs on a LAN came from. The root idea was that this password was propogated across the lan, you could log in make a change and logout and other users couldn’t alter the config.
The nature of home networks (think of the guy down the road - try and think outside of what you run in your house) is very, very ad-hoc. PCs get turned on and turned off in no regulated manner. This is why I was thinking of making the “server” dynamic, rather than a fixed location. Redundancy can also be the ability to offer identical services from an alternate location, as well as the more conventional definition of offering identical services from a replica of the original location.
Whether any of the PCs on the LAN need to be rebooted depends totally on the nature of what was updated. CAVS definitions and FW rules don’t require a reboot, services can be stoped, updated and restarted but if a .SYS level component was updated, it must be rebooted to take effect.
Point taken about the slaves not rebooting. If the downlooaded update mandated a reboot, they could send a flag to the master of reboot pending and sit and wait for the user to acknowledge the reboot request. For safety the FW could block all traffic until the reboot was done.
- Is it implied that the Server (Master) not only houses CMC (and downloaded updates), but also has all the applications deployed on itself? Will CMC fail if the Server/Master does not have all aplication deployed on it that CMC is serving?
When the slaves send their version levels, this would indicate to the current master what apps were on what PCs. This would be stored in a table and distributed to all PCs. If PC A has apps 1 and 3, and PC B has apps 2 and 3, the current master would download the updates for apps 1, 2 and 3. Only the appropriate updates would be pushed to the respective PCs. Even if the current master only has app 1 on it, it would still download and distribute the updates for apps 1, 2 and 3.
- Are we eliminating the need for CMC to be aware of "what applications are installed where?" by having the client CMC's report their version numbers of application deployed? Would CMC not become more intelligent if the Server (Master) recorder who all it's clients were, what applications they had installed, and prepared a update "bundle" for each PC on it's own?
See above
- I disagree with the master/subordinant negotiation channel, the master is the master. If it is not found, there are no updates to distribute and the client waits until the master arrived, or new master is promoted manually; at wich point it will broadcast itself without negotiation. I assume applications like CAV will still be allowed to download their own definition updates if the server goes AWAL? This would also depricate the requirement for all PC's to know the status of all other PC's updates.
“I disagree with the master/subordinant negotiation channel, the master is the master. If it is not found, there are no updates to distribute and the client waits until the master arrived, or new master is promoted manually”.
With due respect, isn’t the idea of manually promoting a slave to master status reducing what should be an automated action done by software to a process that requires manual human intervention? A home LAN usually doesn’t have someone with the time and/or knowledge to do this - this is the crux of the concept of CMC - don’t rely on owners of the home lan - trust the intelligence built into the product, so it extends the trust the owners can apply to the rest of the security layer.
Individual apps will still be able to download updates if CMC isnt installed, of course, but CMC means that only one internet access is required to obtain all relevant Comodo updates to satisfy the requirements of the LAN.
If all PCs on the LAN know the status of all the other PCs on the LAN, why is this a bad thing? All we’re doing is storing the data in multiple locations, instead of in our heads and eliminating the reliance on us finding the time to update everything on all PCs.
- Are the updates CMC manages restricted to application updates, or will it be controlling things like CAVS definition updates?
Ideally it would handle updates for all Comodo apps. I just assumed that this would include definitions, behaviour rules and allow db/disallow db’s as well, but these should be clearly laid out in the doc, when the next revision is done (hopefully in the next few days, after some other ideas are rolled around).
Interesting how CPF NM rules weren't even in the original spec... no wonder I was out of sync... but hopefully it added some food for thought.
The original doc was focussed on the master/slave update cycle. The config management layer is going to be developed in the next rev.
Given that not all PCs on a LAN run the same software, how do you think we could handle the application rules and NM rules? Should we have a core library that exists for all PCs (standard rules and apps for inter lan and basic internet comms) and an exception table, specific to each PC on the LAN? What do you think? Or is there a better way?
How’d you like to take on a chunk of this for your very own?
I need someone to sit down and work out the details on what data is passed between each of hte PCs in a CMC cycle.
Stuff like,
on receiving a master broadcast, PC1 stores the current IP of the current master
master needs to have a table that stores the current application update levels when sent by PC1
2a. what update levels do we need to pass? av engine, definition version, firewall version?
(the guys at comodo may be able to assist with these details)
what flags need to be passed between the master and the slaves based on current idea of CMC
(like "Update pending - suspend all IP except to CMC until update completed)
At the end we should end up with a series of tables showing what is passed around. Not necessarily in what order or when, just what get passed. This is needed so we can try and work out how much data is going to flow as a result of using the master/slave method and work out if this would adversely affect a typical home lan. Theres no good going too much further down the road if its the wrong road.
If you can’t (or don’t want to) that’s cool - I’m just trying to save myself some time, and I don’t want to be the one driving this - there’s better minds than mine around - trust me, my wife tells me this daily!
I’ve got to agree with you on keeping this management layer separate form the apps. Leave the apps to perform their core function in as streamlined a manner as possible, and reduce the amount of replicated code in the apps to keep their size down and performance up (another thing my wife keeps going on about - who’d have thought she was worried about code optimization??? ;))
I believe that CMC is a separate application layer to the AV and the firewall and the backup. Leave them alone to do their job, and just add sufficient hooks to allow intercommunications between them. Let CMC worry about the nuts and bolts.
How'd you like to take on a chunk of this for your very own?
I need someone to sit down and work out the details on what data is passed between each of hte PCs in a CMC cycle.
Stuff like,
on receiving a master broadcast, PC1 stores the current IP of the current master
master needs to have a table that stores the current application update levels when sent by PC1
2a. what update levels do we need to pass? av engine, definition version, firewall version?
(the guys at comodo may be able to assist with these details)
what flags need to be passed between the master and the slaves based on current idea of CMC
(like "Update pending - suspend all IP except to CMC until update completed)
At the end we should end up with a series of tables showing what is passed around. Not necessarily in what order or when, just what get passed. This is needed so we can try and work out how much data is going to flow as a result of using the master/slave method and work out if this would adversely affect a typical home lan. Theres no good going too much further down the road if its the wrong road.
If you can’t (or don’t want to) that’s cool - I’m just trying to save myself some time, and I don’t want to be the one driving this - there’s better minds than mine around - trust me, my wife tells me this daily!
Well not sure if you want to look at me for a better mind… but I would love to take a ■■■■■ at it. I will see how much I can get done in the next few days as after this weekend I will be AWOL for a while (Daughter is having surgery) and my free time varies day to day.
I also thought about playing around with the flow in Visio, but I haven’t got around to re-installing it on my PC since my hal.dll incident. Something else I will look at.
Thanks a bunch Ryan - anything you can squeeze in will be appreciated.
Regardless of how interesting you find this - your daughter takes priority. I hope its nothing too serious and that all goes well. Our fingers are crossed for her.
