MartinK

Please try password you used to configure appliance (the same as for Administrator user if you have not changed it).

Is this still problem? It is most probably caused by interval checking, or possibly missed notification of changed software. Does restarting system/AGENT fix this issue?

This is error I mentioned previously -> AGENT seems to be configured to connect to "204.186.2.60" BUT this IP/hostname is not present in SERVER's certificate which contains only dmi1-eset.corp.lehighgas.local,10.10.10.179 and 127.0.0.1. This means password for CA certificate you provided during SERVER's certificate signing is not correct. What type of SERVER installation you used? I am currently not sure what password is actually used in case of all-in-one or appliance installations. it indicates unsupported certificate type. All certificates (also CA certificates) were created in ERA? Last error/warning is caused by fact that you are using two different CA certificates for SERVER and AGENT certificate. You are able to provide only one CA certificate during AGENT installation and obviously it must be CA certificate used to sign SERVER's peer certificate -> therefore until AGENT successfully connects to SERVER, it will be missing second CA certificate (certificate used to sign AGENT's peer certificate) and until that it won't be able to verify it's own peer certificate. This error has no impact on AGENT->SERVER connection, therefore I would focus on creating new SERVER certificate signed by original CA certificate, as that would be simplest solution. In case you create new CA certificate and use it to sign new SERVER's certificate, be careful as you may cut-off all other AGENT's -> you should give them enough time to connect and fetch newly created CA certificates before you actually start using it.

Error you mentioned contains lboth: hostnames that is AGENT configured to connect to list of hostnames that are in SERVER's certificate and most probably AGENT is configured to connect to hostname (or IP) that is not in list of SERVER's certificate. Names must match exactly. After changing SERVER's certificate, restart will be required (not sure about this). New AGENT certificate should not be required in case it was created with default settings (i.e. * as hostname).

Could you be more specific what does not work? In case you meant that only one of computer is matching group, could you verify that both computers are connecting to SERVER (at least one successful connection after last modification of dynamic group template is required)

ERA is using UTC (GMT) internally and timestamps visible in Webconsole are calculated to local time based on timezone configuration sent by browser. This means there may be wrong UTC time on SERVER, or maybe wrong timezone set on client machine? Could you be more specific where exactly you see -1 time? What is your UTC time offset (your current timezone)?

Total limit of file descriptors should be sufficient even for much larger networks. There is most probably something wrong, but hard to tell where exactly without further analysis. What version of appliance and ERA products are you using? I would suggest to install lsof tool (yum install lsof) and try to find out which process is taking so many file descriptors. For example, command: lsof | wc -l should print total number of opened file descriptors. Alternatively you could print descriptors for specific process by: lsof -p `pgrep ERAProxy` lsof -p `pgrep ERAProxy` | wc -l should print list and count of file descriptors being held by ERAProxy process. This can be repeated for ERAAgent and httpd processes, until we know where the problem is. You may also analyze number of opened connections using: netstat -tp which will print list of all opened connection with process that is responsible for them.

Access root console and provide us with content of firewall.sh file. This line should have no impact on other ports configuration. you may also try to restart firewall using service iptables restart and check whether it helped. Have you tried to restore original firewall.sh file and restarting machine? What is your appliance version?

Ok but we have issues that people often closes their PC, if i program a client task for exemple 11PM and the PC is closed, what will happen when he opens the PC, will the task sends the task to the PC and start it or wait at the next time? There is parameter called Invoke ASAP If Event Missed in trigger (repeated) configuration used to enable/disable what you are asking for. If checked, task will be triggered just after next AGENT startup in case planed execution was missed.

Appliance uses iptables firewall and its configuration is loaded from file /root/firewall.sh. Use text editor from root console to edit this file, i.e.: nano /root/firewall.sh and add this line: iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT just before firewall-port.sh is called. After changes are saved, either run script /root/firewall.sh or restart whole system.

You may follow one of many tutorials for MySQL, for example: hxxp://www.howtogeek.com/howto/programming/mysql-give-root-user-logon-permission-from-any-host/ It is simplest to use some kind of MySQL managing GUI if available.

There is strange error in installation log: [unixODBC][MySQL][ODBC 5.1 Driver]Host 'Eset.suse' is not allowed to connect to this MySQL server which indicates, that there are some permissions issues. I guess root user you provided to installation script is not configured to be connecting from current host. See MySQL server management.

This should happen only in Lost&Found group and it is caused by pre-installed "Automatic computer renaming" task. You can either disable this task, or move computers to different group, where this wont' be happening.

Unfortunately there is not. Windows 2000 Server is not supported by ERA 6.

On most linux distributions, tomcat process is executed under non-root user (most probably called tomcat). You must ensure that this user has access to mentioned files.

You have two possibilities: when creating AGENT remote installation task you can override SERVER's hostname in task parameters manually change default SERVER name in ERA database, it is table tbl_servers.server_identificator

Are you AGENT's configured to collect list of all applications, not only ESET as is default? You can go to client details view of specific client and check what contains list of installed application. In case it does not contain specified product, you have to change AGENT's configuration to collect ESET application using configuration policy.

Thanks, we will look at it - seems like a bug.

There is no documentation, nor example code. Technically it is only wrapper over c++ libraries for which you could use few alternatives, we used for testing purposes ctypes module

Seems like certificate you selected for remote installation has different password as you provided. There are multiple AGENT certificates as you wrote, are you sure you are selecting proper one? I guess one of them was created during installation, and remaining later (maybe also created by "Server assisted" installation). I would also suggest to test empty password, as that is used for certificates generated by live installer.

I meant copying already installed AGENT, which includes duplicating virtual machines, but also cloning HDD and possibly also running remote installation task multiple times on different machines but using the same entry in Webconsole. Wrong usage of remote installation task: Imagine you have only one computer entry in console named Computer1.domain with identifier ID1. Once you run remote installation task on this computer, AGENT gets installed and is assigned ID1. Next day, hostname "Computer1.domain" will be pointing to different computer in your network and once you re-run installation task, you will end with two computers with installed AGENT using the same unique identifier ID1. This will cause problems, especially data received from client(s) may be mixed -> there will be still only one entry in computers list, even when two different computers will be connecting. Therefore we recommend to use remote installation task only for initial installation, and not for further repairs ...

Every time you install AGENT, it gets unique identifier, which will pair with computer record in Webconsole. There are two basic scenarios how this identifier is generated: Identifier is generated during manual AGENT installation (manual & live installer) - and upon first connection to SERVER, respective entry is created with the same identifier and from now, this is what pairs AGENT with it's entry in computers list. Identifier is generated once you manually create computer in Webconsole (and also using synchronization). When you use remote installation task to install AGENT, it is installed on remote machine with the same identifier so that upcoming connections are pair with computer. Duplicate entries are mostly created when you: manually reinstall (uninstall + install) AGENT on client machine. In this case AGENT uses new identifier -> new computer is created in Lost & Found group. run "reset cloned agent" task on specific client. Result is almost the same as AGENT was manually reinstalled, except not all data are purged (task as example) synchronize computers (AD,LDAP) and install AGENT's manually. In this case, there are two identifiers for the same computer. Currently merging computers as you mentioned is not supported. You can only "merge' multiple entries in case only one of them is "managed", which technically means removing dummy entries of computers, that had never an AGENT installed - and this merging is based on their name, which is mostly their hostname. You mentioned renaming tasks: name of computer is not used to pair it with AGENT installation and once AGENT is connection, you can rename it to what ever you want. Computer name is currently used only in two scenarios: name is used as target to remote installation task, therefore for this task it has to be either IP or hostname so that ERA can connect to it name is used to "merge" multiple computers with the same name, but only in case no more than one of them is managed. Summary: identification of computers is significantly different. ERAv5 identified computers by their HW fingerprint, which may have changed even in case you did not wanted it (i.e. you changed MAC address, or replaced some hardware). Contrary to that, ERAv6 identifies clients not by HW, but by installation which has its own disadvantages, namely problems with duplicating virtual machines, which results in two AGENT's with the same identifier

There is currently no other authentication method available. Communication between ServerApi and ERA Server itself uses TLS so it should be safe in case ServerApi methods are called in safe manner. Regardless of previous I would strongly recommend to create specific ERA user (with limited permissions, i.e. only for reading specific data) for ServerApi connection. We are not aware of any documentation for PHP. We only come across tools using c++ or python to handle API calls.

hi: forgot to mention. I install ERA 6.3 under rhel 7.2 and MariaDB 5.5 about 10 times. every time it is success. so the installer didn't block installation on MariaDB database. but I really hope Eset can consider make MariaDB work. every major linux distribution ship with MariaDB now. MariaDB is much faster than mysql 5.6 under rhel 7.2. I saw Eset use many store procedures. it seems the trigger of store procedures under MariaDB cause problem. Seems I made mistake in assumption that detection made it into 6.3 release -> it will be available in upcoming release ... Main problems with MariaDB seems that many of our stored procedures (especially those focused on data processing performance) are using MySQL internals that does not work on MariaDB. Unfortunately there are currently no plans for support of this type of database, as even in case MariaDB is shipped as default on most of Linux distributions, it is not difficult to install MySQL. Upcoming major release (not 6.3) may introduce changes in DB layer which may be also place for us to evaluate how difficult it would be to support both MySQL and MariaDB with the same set on database layer with focus to performance.

Were there any incidents between January and February involving either crash of SERVER's machine or reverting ERA database? Could you please send me privately SERVER trace.logs and also AGENT's trace.log from machine you tried to install. Attached logs seems to be from AGENT installed on SERVER's machine, but I guess it is not client you tried to deploy EES?