Symantec Liveupdate

[Margarita Lovvorn]

Theupdates work when I allow all traffic from DMZ -> WAN, so I know the Symantec software is installed fine. However, when I block internet traffic, allow DNS lookup to pass through as LiveUpdate uses FQDNs and follow the Symantec tech article to allow it through the firewall, it fails every time.

I've done some packet tracing when all traffic is allowed and it looks like LiveUpdate has multiple CNAMEs returned from the DNS. Should these CNAMEs be added to the policy as allowed or should the firewall be able to deal with them?

It's getting to the point where I'm considering setting up LiveUpdate to run once a day and to allow all traffic out to the internet for a 10 min widow while it does. However this is obviously not the preferred solution.

Going by that KB article, creating FQDNs for liveupdate.symantecliveupdate.com and liveupdate.symantec.com and creating a firewall policy allowing "unrestricted" access to those FQDNs should do the trick (assuming the firewall rule is moved up in the firewall chain).

The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.

I have a SBS 2008 server and Symantec Endpoint Protection Small Business 12.1 installed for 15 clients. My problem is that all clients are at an other city an we work with vpn. I have noticed that a had a big problem with clients trying to work because a big amount of traffic was used from antivirus trying to get new definitions from management server i suppose, so I am using a program to limit the bandwith antivirus uses. Is there a way to configure clients to update through Symantec liveupdate server and not my management server? (I cannot see many options in Liveupdate policy...)

The manifest contains meta data about the resources. E.g if the resource is compressed or not, as well as the dependencies for that resource. E.g. a collection depends on all the sprites, textures and game objects etc.

I have no experience with protobuf at all, can you please suggest what to do next and how to get understandable information out of it for further use? Or maybe there is a link to an example how to parse liveupdate.game.dmanifest using liveupdate_ddf.proto?

Im hoping that the resident symantec experts can help me solve this odd issue. I have recently installed SMSE 6.5. Im running exchange 2010 with all the roles on one server. The problem im having is when I run liveupdate on the server it connects quickly and tells me everything is up to date. Only problem is the virus defs are from 2-9-11. I have had this issue before and the symantec support people walked me through on changing the connection timeout period and that seemed to fix the issue. Any ideas on where to start?

Not even sure where to begin to look for errors. SMSE was uninstalled from my mail server some weeks for some troubleshooting I needed to do. I have now reinstalled it. There are no other symantec products running on the server besides SMSE.

How do I whitelist liveupdate in our firewall. I have seen from this post -behind-firewall that Symantec does not provide a list of IP addresses for the LiveUpdate. But suggest to whitelist. Is the FQDN always going to be correct and is it liveupdate.symantecliveupdate.com In our firewall logs we had a FTP connection from 77.67.22.169 and file livetri.zip

Note: Symantec does not supply IP addresses for Symantec LiveUpdate servers. The server addresses are not static and, consequently, routing directly to an IP address may cause LiveUpdate to fail.

Thanks for listing the domains Liveupdate connects to, but liveupdate also appears to connect to an ip without associated DNS names, can anyone confirm this? If am seeing our firewall blocking FTP sessions to liveupdate because it does not like the contents of the uploaded file, does it suggest that the HTTP session to liveupdate did not occur (maybe also blocked) as the order of connections is HTTP first then FTP second. Should I follow up why HTTP is not working?

Thanks. it looks to me like the HTTP is not working as it getting to the FTP stage. FYI I was not trying to route to ip directly. Also we would have to disable the firewall antivirus by setting up a firewall rule specifically that matches the domain and FTP.

How do I **** liveupdate in our firewall. I have seen from this post -behind-firewall that Symantec does not provide a list of IP addresses for the LiveUpdate. But suggest to ****. Is the FQDN always going to be correct and is it liveupdate.symantecliveupdate.com In our firewall logs we had a FTP connection from 77.67.22.169 and file livetri.zip

When bundling a game, Defold packs all the game resources into the resulting platform specific package. In most cases this is preferred since the running engine has instant access to all resources and can load them swiftly from storage. However, there are instances where you might want to postpone the loading of resources to a later stage. For instance:

The Live update functionality expands the concept of the collection proxy with a mechanism allowing the runtime to fetch and store resources to the application bundle that were intentionally left out of the bundle at build time.

To have the engine load such a collection dynamically, we can simply add a collection proxy component and point it to monalisa.collection. Now the game can choose when to load the content in the collection from storage into memory by sending a load message to the collection proxy. However, we want to go further and control the loading of the resources contained in the collection ourselves.

When bundling, any excluded resource will be left out of the application bundle. By checking the Publish Live update content checkbox, you tell Defold to either upload the excluded resources to Amazon or to create a Zip archive, depending on how you have set up your Live update settings (see above). The manifest file for the bundle will also be included in the excluded resources.

While our current pipeline only supports creating a single .zip file, it is in fact possible to split that zip file into smaller .zip files. This allows for smaller downloads for a game: level packs, seasonal content etc. Each .zip file also contains a manifest file that describes the meta data for each resource contained within the .zip file.

It is often desireable to split the excluded content into several smaller archives for more granular control over resource usage. One such example is to split a level based game into multiple level packs. Another is to put different holiday themed UI decorations into separate archives and load and mount only the theme currently active in the calendar.

The resource graph is stored in build/default/game.graph.json and it is automatically generated each time the project is bundled. The generated file contains a list of all resources in the project and the dependencies of each resource. Example entry:

Each entry has a path which represents the unique path of the resource within the project. The hexDigest represents the cryptographic fingerprint of the resource and it will be the filename used in the liveupdate .zip archive. Finally the children field is a list of other dependencies which this resource depends on. In the example above the /game/player.goc has a dependency to a sprite and a script component.

You can parse the game.graph.json file and use this information to identify groups of entries in the resource graph and store their corresponding resources in separate archives along with the original manifest file (the manifest file will be pruned at runtime so that it contains only the files in the archive).

The liveupdate.add_mount() default behavior, is to add an engine version check when attaching a mount.This means that both the game base archive and live update archive(s) need to be created at the same time with the same engine version, using the bundle option. This will invalidate any previously downloaded archives by the client, forcing them to redownload the content.

This behavior can be turned off with an options flag.When turned off, the content verification responsibility lies entirely with the developer, to guarantee that each live update archive will work with the running engine.

3a8082e126