Linux Server 6.1.450.0: Instability with various components

[bbraunstein 27]

So this is mainly meant to be a rant/compiled list of issues from a Linux Server standpoint. I did not use the OVA template to configure my server. I manually installed each component I wanted from hand. My server is installed on a CentOS 6.5 VM.

 

• Upgrade: Encountered difficulties during the upgrade process. Error: DbPrepareUpgrade: Statement execution failed. Error: [MySQL][ODBC 5.2(w) Driver][mysqld-5.6.22]Access denied; you need (at least one of) the SUPER privilege(s) for this operation. File: /tmp/tmp.RVIn5691tQ/setup/Database/MySQL/SetupScripts/1_prepare_setup.sql
  • Resolved by logging into the MySQL server as root and entering: grant SUPER on *.* to era@'localhost' identified by 'some_pass';
• ESET Remote Administrator Components Upgrade task cannot find the Server in the Reference Settings.
  • I only have one server and it is the localhost.
• Server Tasks are broken, although Client tasks are fine.
  • Agent Deploy, Static Group Sync, & Generate Report are grayed out/locked out with only the following error: Failed to load trigger types compatible with task types.
  • Resolved: By upgrading the Web Console. Copy the new era.war file to /var/lib/tomcat6/webapps/ and overwrite the existing one.

If there are more issues, and I would not be surprised if there are, I just haven't discovered it them yet. So as of now, the only remaining issue is the ESET RA Components Upgrade task not being able to reference itself in the settings pane.

Edited March 2, 2015 by bbraunstein

[Lesley F. 5]

Thank you for the feedback bbraunstein. I have passed your observations along to our product and development teams.

[bbraunstein 27]

Okay, so big discovery incoming:

 

Backstory:

My company has three locations: I work in the HQ in one location, and there are two more located in two separate countries in the world. I was able to successfully deploy the Agent and AV upgrade to Windows clients in my location. Any local Linux or OSX computer failed during the deploy. Any computer, regardless of OS type, located in my two satellite location failed outright. Whenever a new computer without a FQDN, the hostname is just listed as its IP Address in the Web Console. I manually modify the name to something more descriptive, instead of its IP Address

 

 

The logs were showing that the hostname could not be resolved for any of those problematic clients. I soon figured out that the reason the local Windows computers passed was because they were all registered in my domain. Local Linux & OSX, and remote computers failed because they are not added to the domain. . 
 

 

Examining how I could resolve this, I changed the name of the computers from *hostname* to whatever their IP Address is in the Web Console. I clicked on the device in the Web Console, selected Details, and simply modified the name. After this,  the Agent Deploy worked successfully on all of the problematic computers.

 

 

So I'm piecing together that in the backend, the Server is taking whatever value that is in the 'Name' field of the computer details and using that as its variable? Even if I manually modify the name of the computer, this value will be taken and parsed as the target.

 

In other words, some psuedo-code of me trying to deploy to a Windows Computer:

$_computer_name = potato
$_target_host = $_computer_name
mount -t cifs -o /tmp/some_random_string "\\$_target_host\$IPC" 

STDERR > Error: unable to resolve "target_host"

And obviously it fails because 'potato' isn't a valid name. Now imagine this scenario with Linux and OSX computers that are not added to the domain. Now you can see why I need to manually change the names of each new device.

 

 

I was able to resolve this by modifying the names of the computer from their descriptive names to their IP address in the Web Console. After doing this, all Agent Deploy tasks passed successfully.

Edited March 4, 2015 by bbraunstein