Mirror Tool

[kingoftheworld 10]

Can any ESET representatives comment as to if a real mirror tool will be included in a future ESET Remote Admin release?  When I say real mirror tool, I am wanting something to behave in the same manner and ease as the function did with ESET 4/5 console.  I do not want a command line based that I have to create a scheduled task for and run Apache with.  I do not want to run it from a endpoint.  I want to check a box, enter the credentials I want, and a port number. 

[bbahes 29]

Can any ESET representatives comment as to if a real mirror tool will be included in a future ESET Remote Admin release?  When I say real mirror tool, I am wanting something to behave in the same manner and ease as the function did with ESET 4/5 console.  I do not want a command line based ###### that I have to create a scheduled task for and run Apache with.  I do not want to run it from a endpoint.  I want to check a box, enter the credentials I want, and a port number. 

 

+1

[Marcos 5,071]

In previous versions of ERA, only a light HTTP client was incorporated. For instance, it used to cause issues when a lot of users were attempting to update from it. We've always recommended to use Apache, IIS or other true http server to prevent issues in large networks.

[mahiralkhoir 4]

I think mirror tools for now its good enough. I have create some script ( bat or bash ) for setup mirror tool for our client, and our customer looks happy with that.

 

 

But for the future, maybe ESET should included wizard/check box for automation setup mirror tool when install ERA using All in One installers. For http server just put in webapps tomcat directory.

Edited February 11, 2016 by mahiralkhoir

[bbahes 29]

I think mirror tools for now its good enough. I have create some script ( bat or bash ) for setup mirror tool for our client, and our customer looks happy with that.

 

 

But for the future, maybe ESET should included wizard/check box for automation setup mirror tool when install ERA using All in One installers. For http server just put in webapps tomcat directory.

 

+1

[MichalJ 434]

As Marek stated, old HTTP Server was not optimal for large-scale deployments. Also, with the introduction of nano-updates, there is practically no reason to utilize mirror, for customer below 100 seats (size of nano updates for 100 computers is approximately the same, as size of one level update, which is downloaded by update mirror).

Also, for customers that want to use the old mirror with integrated http server, they can do it, by enabling the functionality on any of the installed products (EEA / EES / EFSW), which is basically as simple, as setting a policy (which equals to configuring server settings for mirror).

For customers that have their own web server (IIS for example), they can easily deploy the offline mirror tool, and execute it simply by running a task via ERA agent (instructions are provided in the ERA documentation).

What is important to state, is that the primary replacement for the mirror is the apache http proxy (or actually any web proxy with caching enabled) which could now cache the update files and installers.

 

We do understand, that migration from V5 to V6 is not an "in place upgrade" as it was in case of previous 4 versions. Mirror concept was simply replaced by the proxy, as after internal analysis this concept was showing as more suitable compared to the old fashioned mirror which was included in V5 & older versions of ERA.

 

However, as we want to listen to your feedback, I would like to ask you, what are the main issues / reasons, why you would prefer using the old fashioned mirror in comparison to the proxy caching? What problems are you solving by using mirror, that proxy is not able to solve?

[mahiralkhoir 4]

Apache HTTP Proxy is a good solution for customer who have internet connection ( in all computer have access to the internet ). But for some customer with limited internet connection, its very difficult. I do some test with Apache HTTP Proxy and Mirror Tools for client with very very limited internet access. Let me explain my experience using Apache HTTP Proxy :

1. Apache HTTP Proxy act like proxies server, when there are no request no cache. Even if there are request, some client just downloaded directly to the internet via Apache HTTP Proxy, not from cache. I am very happy, if ESET can prove or showing some log which Apache HTTP Proxy 100% delivering cached file to endpoint. Mirror Tool downloaded once from local or internet, 100% deliver it to endpoint.
2. Proxy good for caching installer file ( mirror tool can't), but you must maintain cache from Apache HTTP Proxy, directory cache always grow up. So you must run htcache clean tools for resolved some issue ( manually or you can set up cron/scheduler ). You dont need clean up temp mirror tools.
3. Cache directory from Squid or Apache HTTP Proxy very difficult to copy or migration. Mirror tools just copy.
4. You must update some version Apache HTTP Proxy manually for solving some problem. So far Mirror tools nope.

I am not hate Apache HTTP Proxy, i am still using it for activation client who are not have internet connection. It exception because connection for activation not much as update signature. Because there are no way you can activated endpoint from ERA without internet connection.

[bbahes 29]

As Marek stated, old HTTP Server was not optimal for large-scale deployments. Also, with the introduction of nano-updates, there is practically no reason to utilize mirror, for customer below 100 seats (size of nano updates for 100 computers is approximately the same, as size of one level update, which is downloaded by update mirror).

Also, for customers that want to use the old mirror with integrated http server, they can do it, by enabling the functionality on any of the installed products (EEA / EES / EFSW), which is basically as simple, as setting a policy (which equals to configuring server settings for mirror).

For customers that have their own web server (IIS for example), they can easily deploy the offline mirror tool, and execute it simply by running a task via ERA agent (instructions are provided in the ERA documentation).

What is important to state, is that the primary replacement for the mirror is the apache http proxy (or actually any web proxy with caching enabled) which could now cache the update files and installers.

 

We do understand, that migration from V5 to V6 is not an "in place upgrade" as it was in case of previous 4 versions. Mirror concept was simply replaced by the proxy, as after internal analysis this concept was showing as more suitable compared to the old fashioned mirror which was included in V5 & older versions of ERA.

 

However, as we want to listen to your feedback, I would like to ask you, what are the main issues / reasons, why you would prefer using the old fashioned mirror in comparison to the proxy caching? What problems are you solving by using mirror, that proxy is not able to solve?

 

We have 30% internal notebook workstations that don't have any access to internet, so they don't hit proxy at all. This is why we need mirror tool in LAN.

In future we will be implementing network access control and will isolate clients to part of network with antivirus update server that won't have access to internet.

Also having single point where updates are downloaded is really handy for troubleshooting.

[Gonzalo Alvarez 66]

Hi @bbahes,

 

How about to create a mirror like @MichalJ mention and the group taking updates from there:

 

Also, for customers that want to use the old mirror with integrated http server, they can do it, by enabling the functionality on any of the installed products (EEA / EES / EFSW), which is basically as simple, as setting a policy (which equals to configuring server settings for mirror).

the update files and installers.

 

in 1 PC, and every 1 or 2 days connect that PC to internet to download ESET Updates.

Note: is you use a Firewall like ESET Endpoint Security has, you can select only ESET product connect

to internet, in order to keep safe the connection and computers.

[bbahes 29]

Hi @bbahes,

 

How about to create a mirror like @MichalJ mention and the group taking updates from there:

 

Also, for customers that want to use the old mirror with integrated http server, they can do it, by enabling the functionality on any of the installed products (EEA / EES / EFSW), which is basically as simple, as setting a policy (which equals to configuring server settings for mirror).

the update files and installers.

 

in 1 PC, and every 1 or 2 days connect that PC to internet to download ESET Updates.

Note: is you use a Firewall like ESET Endpoint Security has, you can select only ESET product connect

to internet, in order to keep safe the connection and computers.

 

This was one of the first suggestions from ESET in general after people asked mirror back.

However this is still workaround, not a server side solution. I have often asked ESET to make update feature similar to Microsoft WSUS. One simple interface integrated in ERA that handles definition/product updates.

[Gonzalo Alvarez 66]

Yes, is a workaround.

[MichalJ 434]

 

As Marek stated, old HTTP Server was not optimal for large-scale deployments. Also, with the introduction of nano-updates, there is practically no reason to utilize mirror, for customer below 100 seats (size of nano updates for 100 computers is approximately the same, as size of one level update, which is downloaded by update mirror).

Also, for customers that want to use the old mirror with integrated http server, they can do it, by enabling the functionality on any of the installed products (EEA / EES / EFSW), which is basically as simple, as setting a policy (which equals to configuring server settings for mirror).

For customers that have their own web server (IIS for example), they can easily deploy the offline mirror tool, and execute it simply by running a task via ERA agent (instructions are provided in the ERA documentation).

What is important to state, is that the primary replacement for the mirror is the apache http proxy (or actually any web proxy with caching enabled) which could now cache the update files and installers.

 

We do understand, that migration from V5 to V6 is not an "in place upgrade" as it was in case of previous 4 versions. Mirror concept was simply replaced by the proxy, as after internal analysis this concept was showing as more suitable compared to the old fashioned mirror which was included in V5 & older versions of ERA.

 

However, as we want to listen to your feedback, I would like to ask you, what are the main issues / reasons, why you would prefer using the old fashioned mirror in comparison to the proxy caching? What problems are you solving by using mirror, that proxy is not able to solve?

 

We have 30% internal notebook workstations that don't have any access to internet, so they don't hit proxy at all. This is why we need mirror tool in LAN.

In future we will be implementing network access control and will isolate clients to part of network with antivirus update server that won't have access to internet.

Also having single point where updates are downloaded is really handy for troubleshooting.

 

 

@bbahes => Basically, you want to distribute the updates from the ERA server (machine on which you have your ERA V6 installed), which will act as the mirror, which basically means, that ERA server will have access to the internet (will be able to download update). Is this assumption correct?

 

Exactly for this reason, we have added the option to install the Apache HTTP Proxy, on the same machine as ERA server, to act as the updates cache.

But it does not work only for updates (and installers), it also allows Endpoints to utilize ESET LiveGrid, our cloud-based reputation system, which drastically improves the security (as it significantly minimizes response time to new threats and thus improves the detection). LiveGrid does not work in case Endpoints does not have connection to the internet. If you will divert Endpoint communication inside your LAN via the proxy, it will cache the updates, and also allows LiveGrid requests to go through.

 

The same is valid for the new licensing system, via proxy, it will be able to communicate to EDF, and utilize the "transparent license update functionality". I assume, that you are currently using offline license file for activation, which you will need to manually replace after the license renewal.

 

Thank you for your feedback.

[bbahes 29]

 

 

As Marek stated, old HTTP Server was not optimal for large-scale deployments. Also, with the introduction of nano-updates, there is practically no reason to utilize mirror, for customer below 100 seats (size of nano updates for 100 computers is approximately the same, as size of one level update, which is downloaded by update mirror).

Also, for customers that want to use the old mirror with integrated http server, they can do it, by enabling the functionality on any of the installed products (EEA / EES / EFSW), which is basically as simple, as setting a policy (which equals to configuring server settings for mirror).

For customers that have their own web server (IIS for example), they can easily deploy the offline mirror tool, and execute it simply by running a task via ERA agent (instructions are provided in the ERA documentation).

What is important to state, is that the primary replacement for the mirror is the apache http proxy (or actually any web proxy with caching enabled) which could now cache the update files and installers.

 

We do understand, that migration from V5 to V6 is not an "in place upgrade" as it was in case of previous 4 versions. Mirror concept was simply replaced by the proxy, as after internal analysis this concept was showing as more suitable compared to the old fashioned mirror which was included in V5 & older versions of ERA.

 

However, as we want to listen to your feedback, I would like to ask you, what are the main issues / reasons, why you would prefer using the old fashioned mirror in comparison to the proxy caching? What problems are you solving by using mirror, that proxy is not able to solve?

 

We have 30% internal notebook workstations that don't have any access to internet, so they don't hit proxy at all. This is why we need mirror tool in LAN.

In future we will be implementing network access control and will isolate clients to part of network with antivirus update server that won't have access to internet.

Also having single point where updates are downloaded is really handy for troubleshooting.

 

 

@bbahes => Basically, you want to distribute the updates from the ERA server (machine on which you have your ERA V6 installed), which will act as the mirror, which basically means, that ERA server will have access to the internet (will be able to download update). Is this assumption correct?

 

Exactly for this reason, we have added the option to install the Apache HTTP Proxy, on the same machine as ERA server, to act as the updates cache.

But it does not work only for updates (and installers), it also allows Endpoints to utilize ESET Live Grid, our cloud-based reputation system, which drastically improves the security (as it increases the response times, and improves the detection). Live Grid does not work, in case Endpoints does not have connection to the internet. If you will divert Endpoint communication inside your LAN via the proxy, it will cache the updates, and also allows Live Grid requests to go through.

 

The same is valid for the new licensing system, via proxy, it will be able to communicate to EDF, and utilize the "transparent license update functionality". I assume, that you are currently using offline license file for activation, which you will need to manually replace after the license renewal.

 

Thank you for your feedback.

 

 

It's proxy. And clients have to be able to resolve dns names or access internet in order to benefit proxy. Can you configure proxy in different way then for clients?

Also, is there a way to see from ERA what proxy is downloading and for which client?

Edited February 11, 2016 by bbahes

[Marcos 5,071]

Also note that with the former mirror system, my estimation is that more than 100 MB of update files would have to be downloaded with each new update for the mirror to be able to function properly. With the proxy-based system, only files that are really needed by clients are downloaded which can reduce the traffic from more than 100 MB to a few MB.

[bbahes 29]

Also note that with the former mirror system, my estimation is that more than 100 MB of update files would have to be downloaded with each new update for the mirror to be able to function properly. With the proxy-based system, only files that are really needed by clients are downloaded which can reduce the traffic from more than 100 MB to a few MB.

 

But why not improve this inside ERA? Why complicate things with proxy configuration and maintenance of third party product?

Edited February 11, 2016 by bbahes

[Marcos 5,071]

But why not improve this inside ERA? Why complicate things with proxy configuration and maintenance of third party product?

It's not possible to improve it. Apache HTTP Proxy would have to be replaced with an ESET Http proxy that would need to developed from scratch. There's no reason to reinvent the wheel once there is already an efficient and reliable proxy servers from other companies that specialize in this area.

[bbahes 29]

 

But why not improve this inside ERA? Why complicate things with proxy configuration and maintenance of third party product?

It's not possible to improve it. Apache HTTP Proxy would have to be replaced with an ESET Http proxy that would need to developed from scratch. There's no reason to reinvent the wheel once there is already an efficient and reliable proxy servers from other companies that specialize in this area.

 

 

Do you have KB article that explains how to setup apache proxy on your virtual appliance?

[Gonzalo Alvarez 66]

Perhaps this one?

 

hxxp://help.eset.com/era_deploy_va/63/en-US/index.html?va_faq.htm

[bbahes 29]

Perhaps this one?

 

hxxp://help.eset.com/era_deploy_va/63/en-US/index.html?va_faq.htm

 

No, but it helps me understand how ESET utilizes firewall in their virtual appliance

 

By the way. In your "Apache HTTP Proxy installation - Linux" - hxxp://help.eset.com/era_install/63/en-US/index.html?http_proxy_installation_linux.htmyou say "at least version 2.4.10" but you never say that CentOS 6.7 (which is OS of your virtual appliance) does not support by default version 2.4 only 2.2

 

Why "at least version 2.4.10"?

[MartinK 378]

 

Perhaps this one?

 

hxxp://help.eset.com/era_deploy_va/63/en-US/index.html?va_faq.htm

 

No, but it helps me understand how ESET utilizes firewall in their virtual appliance

 

By the way. In your "Apache HTTP Proxy installation - Linux" - hxxp://help.eset.com/era_install/63/en-US/index.html?http_proxy_installation_linux.htmyou say "at least version 2.4.10" but you never say that CentOS 6.7 (which is OS of your virtual appliance) does not support by default version 2.4 only 2.2

 

Why "at least version 2.4.10"?

 

 

In short: each appliance contains Apache HTTP Proxy of supported version and with prepared configuration (/opt/apache/). In case you have not deployed appliance with enabled proxy, it is not started automatically and you have to enable it manually by steps described in mentioned article (section "How do I enable Apache HTTP proxy on my ERA Virtual Appliance after initial configuration?".)

[bbahes 29]

 

 

Perhaps this one?

 

hxxp://help.eset.com/era_deploy_va/63/en-US/index.html?va_faq.htm

 

No, but it helps me understand how ESET utilizes firewall in their virtual appliance

 

By the way. In your "Apache HTTP Proxy installation - Linux" - hxxp://help.eset.com/era_install/63/en-US/index.html?http_proxy_installation_linux.htmyou say "at least version 2.4.10" but you never say that CentOS 6.7 (which is OS of your virtual appliance) does not support by default version 2.4 only 2.2

 

Why "at least version 2.4.10"?

 

 

In short: each appliance contains Apache HTTP Proxy of supported version and with prepared configuration (/opt/apache/). In case you have not deployed appliance with enabled proxy, it is not started automatically and you have to enable it manually by steps described in mentioned article (section "How do I enable Apache HTTP proxy on my ERA Virtual Appliance after initial configuration?".)

 

 

OK. I will give it a try right now and report results.

[bbahes 29]

 

 

 

Perhaps this one?

 

hxxp://help.eset.com/era_deploy_va/63/en-US/index.html?va_faq.htm

 

No, but it helps me understand how ESET utilizes firewall in their virtual appliance

 

By the way. In your "Apache HTTP Proxy installation - Linux" - hxxp://help.eset.com/era_install/63/en-US/index.html?http_proxy_installation_linux.htmyou say "at least version 2.4.10" but you never say that CentOS 6.7 (which is OS of your virtual appliance) does not support by default version 2.4 only 2.2

 

Why "at least version 2.4.10"?

 

 

In short: each appliance contains Apache HTTP Proxy of supported version and with prepared configuration (/opt/apache/). In case you have not deployed appliance with enabled proxy, it is not started automatically and you have to enable it manually by steps described in mentioned article (section "How do I enable Apache HTTP proxy on my ERA Virtual Appliance after initial configuration?".)

 

 

OK. I will give it a try right now and report results.

 

 

So I did clean install and followed instructions to activate Apache HTTP Proxy and tested client that has access to internet blocked.

The update passed ok and as I look at log file in appliance I see client hits proxy with requests.

Is it possible to see this log (or list of client requests) in ERA rather to view log file in appliance?

 

This could mean that we might consider to upgrade to v6 in future. We want to stay on v5 because of better GUI for administration.

[MichalJ 434]

As Apache HTTP Proxy is an external component, we do not have the report integrated in ESET Remote Administrator Web-console. We are evaluating options, if this can be done somehow, but no promises yet.

More details about how to enable better logging for the Cache itself is listed here: https://forum.eset.com/topic/6751-era-6-not-pushing-updates-via-apache-http-proxy/?hl=apache.org#entry39576

 

Concerning your other point, about the reasons to stay with V5. We are constantly improving the user experience of V6 and are interested to hear any feedback, about what was working better for you, or what use-cases are problematic within the new product. Is there any particular thing, that you consider problematic, or any use-case that is absent in ERA 6, that was available in ERA 5? What was better in the V5 GUI compared to the V6 web-console?