Jump to content

Ubuntu18.04 | ERA installation error


avielc
 Share

Recommended Posts

Somehow I don't understand how no one mentioned it. 

I've run into an old post about that issue, couldn't find proper solution though, Can anyone direct me to an answer?
 

Quote

Initialized log file: /var/log/eset/RemoteAdministrator/EraAgentInstaller.log

ESET Management Agent Installer (version: 7.0.471.0), Copyright © 1992-2018 ESET, spol. s r.o. - All rights reserved.

Creating directories...
Creating 'install' directory path: /opt/eset/RemoteAdministrator/Agent
Creating 'config' directory path: /etc/opt/eset/RemoteAdministrator/Agent
Creating 'data' directory path: /var/opt/eset/RemoteAdministrator/Agent
Creating 'Pki Cache' directory path: /var/opt/eset/RemoteAdministrator/Agent/pki.eset.com/
Creating 'logs' directory path: /var/log/eset/RemoteAdministrator/Agent
Creating 'libs' directory path: /opt/eset/RemoteAdministrator/Agent
Directories created
The archive will be extracted to: /opt/eset/RemoteAdministrator/Agent
Extracting, please wait...
Checking OpenSSL ... failure
: Error occurred while checking OpenSSL
Cleaning up setup directories

This is the log of installing the new ERA agent on an Ubuntu 18.04 which still keeps failing. 

I did run into a post like that, but can't figure out what's the solution or path for solution: 
Previous Archived post from the forum.

From what I understand OpenSSL 1.1.0 won't be acceptable, but Ubuntu 1804 comes out of the box with that. 
Hoping someone can assist as this is an issue. 

Link to comment
Share on other sites

So Someone posted an apt-get command that helped. 
I have to say it was a swift and somewhat made me feel "safe" running it. 

Command is : 

apt-get remove libssl-dev:amd64

Thread where solution was found Here

 

It was for Debian, it works on Ubuntu1804

while removing libssl-dev it installed a different older version (which is a good thing I guess)
So it seemed good enough for now,
I would still like to hear from any Dev, or anyone else that can enlighten the topic a little more, possibly offer a better solution in order to avoid such removal on every U1804 computer.

 

Link to comment
Share on other sites

  • Most Valued Members
59 minutes ago, avielc said:

So Someone posted an apt-get command that helped. 
I have to say it was a swift and somewhat made me feel "safe" running it. 

Command is : 


apt-get remove libssl-dev:amd64

Thread where solution was found Here

 

It was for Debian, it works on Ubuntu1804

while removing libssl-dev it installed a different older version (which is a good thing I guess)
So it seemed good enough for now,
I would still like to hear from any Dev, or anyone else that can enlighten the topic a little more, possibly offer a better solution in order to avoid such removal on every U1804 computer.

 

So what you have done is removing the libssl and you did replace it with something else?

Link to comment
Share on other sites

5 minutes ago, Rami said:

So what you have done is removing the libssl and you did replace it with something else?

I think it'll be best to answer with the quote of what the apt-get remove does: 
 

Quote

The following package was automatically installed and is no longer required:
  libssl-doc
Use 'sudo apt autoremove' to remove it.
The following additional packages will be installed:
  libssl1.0-dev nodejs nodejs-dev
Suggested packages:
  debhelper
The following packages will be REMOVED:
  libssl-dev
The following NEW packages will be installed:
  libssl1.0-dev
The following packages will be upgraded:
  nodejs nodejs-dev
2 upgraded, 1 newly installed, 1 to remove and 181 not upgraded.
Need to get 6,512 kB of archives.
After this operation, 380 kB of additional disk space will be used.
Do you want to continue? [Y/n] y

put it simply - 
the apt-get detects the removal and installs a new package of the same kind but I guess older version which works with the agent (so you don't need to mess with the openssl main library)
Now if only ESET were to add such ability into their package, that would've been grand.

Link to comment
Share on other sites

  • ESET Staff
1 hour ago, avielc said:

From what I understand OpenSSL 1.1.0 won't be acceptable, but Ubuntu 1804 comes out of the box with that. 

Hoping someone can assist as this is an issue. 

Problem is that ESMC components for Linux require OpenSSL 1.0.*, which is considered as LTS and still supported. Solution in this case is to install also older OpenSSL, but there is no need to remove/uninstall newer openssl, as most distributions will enable you to use both versions side-by-side. In case of ubuntu, installing package openssl1.0 should resolve this issue.

Link to comment
Share on other sites

5 minutes ago, MartinK said:

Problem is that ESMC components for Linux require OpenSSL 1.0.*, which is considered as LTS and still supported. Solution in this case is to install also older OpenSSL, but there is no need to remove/uninstall newer openssl, as most distributions will enable you to use both versions side-by-side. In case of ubuntu, installing package openssl1.0 should resolve this issue.

Thats what i'm saying @MartinK - it's not an option on Ubuntu18.04 as there is no old package called OpenSSL 1.0.X  - so you can't install "old openssl 1.0.X version"
However this solution mentioned actually helped, it removed only the library responsible for dev-ssl usage, while installing an old variation of it automatically.
Which I believe that libssl-dev is relevant for ESET. 
Perhaps you can use it and add it to the agent package? 
 

Link to comment
Share on other sites

  • Most Valued Members
15 hours ago, avielc said:

I think it'll be best to answer with the quote of what the apt-get remove does: 
 

put it simply - 
the apt-get detects the removal and installs a new package of the same kind but I guess older version which works with the agent (so you don't need to mess with the openssl main library)
Now if only ESET were to add such ability into their package, that would've been grand.

Yes I understand what apt-get remove/purge does  , but I wanted to know how did you fix it , I understand now that you did install an earlier version of libssl

Link to comment
Share on other sites

1 hour ago, Rami said:

Yes I understand what apt-get remove/purge does  , but I wanted to know how did you fix it , I understand now that you did install an earlier version of libssl

You're missing the point @Rami - the quote of apt-get remove was to show what is being done by removing that libssl 
My main concern in removing \ downgrading \ installing earlier version of openssl (what is being actually reported by ERA) is that it would cause conflicts with the Ubuntu18.04

Now, In U1804 it seems there is no "earlier version" for openssl, BUT! for that libssl-dev library there seems there is, and that's why it "feels" safer and less "dangerous" to actually remove it.

 

Again, Hoping for a proper fix from ESET in the matter.

 

Link to comment
Share on other sites

  • ESET Staff
17 hours ago, avielc said:

Thats what i'm saying @MartinK - it's not an option on Ubuntu18.04 as there is no old package called OpenSSL 1.0.X  - so you can't install "old openssl 1.0.X version"

Actually there is package names openssl1.0 in universe repositories, which should work.

17 hours ago, avielc said:

Thats what i'm saying @MartinK - it's not an option on Ubuntu18.04 as there is no old package called OpenSSL 1.0.X  - so you can't install "old openssl 1.0.X version"
However this solution mentioned actually helped, it removed only the library responsible for dev-ssl usage, while installing an old variation of it automatically.
Which I believe that libssl-dev is relevant for ESET. 
Perhaps you can use it and add it to the agent package? 
 

Actually there is official package that contains older libssl library, named libssl1.0.0 (or openssl1.0). In case you are using desktop OS, this package is most probably already installed.

What is actually problem in this case is conflict with libssl-dev: once this package is installed, it changes order in which SSL libraries are loaded - wrong library is loaded first, and that is why installation fails. This does not happen in case there is no libssl-dev package for openssl, or there is dev pakage for libssl1.0.0 package, which is your workaround.

Link to comment
Share on other sites

4 minutes ago, MartinK said:

What is actually problem in this case is conflict with libssl-dev: once this package is installed, it changes order in which SSL libraries are loaded - wrong library is loaded first, and that is why installation fails. This does not happen in case there is no libssl-dev package for openssl, or there is dev pakage for libssl1.0.0 package, which is your workaround.

Ok, great!
But still, I will need to do an apt-get remove run for every machine I install in the organization, that's a great workaround but not a proper solution, can everyone have a proper,valid,official solution in the form of a new installation package? 

 

Thanks for pointing it out by the way.

Link to comment
Share on other sites

  • ESET Staff

@avielc We will work on addressing this issue towards the next major release, which means 7.1 that is targeted towards the mid-2019 time-frame (however, tie time is without guarantee at the moment).

Link to comment
Share on other sites

1 minute ago, MichalJ said:

@avielc We will work on addressing this issue towards the next major release, which means 7.1 that is targeted towards the mid-2019 time-frame (however, tie time is without guarantee at the moment).

Maybe I don't understand well enough how packaging and creating an agent works. 
But Ubuntu was released back on April 2018. You're saying You would (and without guarantee) try to get it patched by mid-2019??
Michal, I'm sorry, but this is most displeasing and appalling to hear. All you need to do is add a simple check for a libssl-dev package and correct it if needed. That's it.  - I know this is barely scratching the surface and there may be more to it than just

apt-get remove libssl-dev:amd64

 and maybe there would be major concerns on other unix operating systems that weren't reported yet.

But I would expect a quick solution for such an issue that is reflected on all latest (and LTS based) Operating system of a major distribution as Ubuntu.

Can't you ask to prioritize\promote  a quick hotfix for the Linux agent? 

 

Thanks again for all the help over time here, and replies, I appreciate it, even if current request comes from a displeased position as a customer and as a low level experienced in Linux, IT engineer.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...