Jump to content
Network communication blocked after upgrade to macOS 15 (Sequoia) ×

Centos VA to Rocky VA migration fails with "it is not possible to authorize to ESET PROTECT Server" with provided credentials

carmik
 Share
Go to solution Solved by carmik,

Recommended Posts

carmik

carmik 0

Posted
Posted (edited)

I've followed to the best of my knowledge the information in https://help.eset.com/protect_deploy_va/11.0/en-US/va_upgrade_migrate.html#recommended in order to migrate from a CentOS 7-based VA to the new Rocky Linux-based one. On my old VA, and IIRC a couple of years ago we switched to extended security by creating custom certificate authorities and switching to SHA-256 communication.

After pulling the database from the old VA, I've powered down the old VA and visited the (temporary) ip of the new server. I've entered my credentials there and the networking info (essentially the setup of the old server). Pressing submit does a VA reboot. After the boot process I'm greeted with an error in the console, stating that first time appliance configuration failed. Further below the following are mentioned:

The log file /opt/appliance/log/appliance-configuration-log.txt: 

Setting issue ...
Reading configuration ...
Setting issue ...
Configuring operating system password ...
Configuring static IP for network adapter ...
Connection 'lan0' successfully deactivated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/2)
Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/3)
Configuring hostname ...
Performing initial NTP synchronisation and configuration ...
200 OK
Starting database server ...
Created symlink /etc/systemd/system/multi-user.target.wants/mysqld.service → /usr/lib/systemd/system/mysqld.service.
mysqladmin: [Warning] Using a password on the command line interface can be insecure.
Warning: Since password will be sent to server in plain text, use ssl connection to ensure password safety.
Configuring database password ...
mysqladmin: [Warning] Using a password on the command line interface can be insecure.
Warning: Since password will be sent to server in plain text, use ssl connection to ensure password safety.
Installing Server ...
stty: 'standard input': Inappropriate ioctl for device

ESET PROTECT on-prem Server Installer (version: 11.0.215.0), Copyright © 1992-2024 ESET, spol. s r.o. - All rights reserved.

Extracting archive, please wait...
Archive extracted to /tmp/tmp.iMArQdf9mL.
Checking OpenSSL ... done [OpenSSL 3.0.7 1 Nov 2022]
Reading previous installation settings ... failure
Checking installed version... done
Status of current installation is: NEW
Checking database connection ... done
Checking database user ... done
Loading GUID ... done [GUID = c70c4a64-b7d1-41d0-bea1-6e60c55a08d2]
Inserting root password ... done
Skipping certificates generation.
Skipping static groups synchronization scheduling.
Stopping service... Preparing database upgrade ... done
Upgrading database ... done
Storing ports into configuration ... done
Moving scripts from '/tmp/tmp.iMArQdf9mL/setup/Scripts' to /var/opt/eset/RemoteAdministrator/Server/Scripts/... done
Moving ESET Modules from '/tmp/tmp.iMArQdf9mL/setup/Modules' to /var/opt/eset/RemoteAdministrator/Server/Modules/... done
Creating 'config' directory path: /etc/opt/eset/RemoteAdministrator/Server
Creating 'libs' directory path: /opt/eset/RemoteAdministrator/Server
Creating 'data' directory path: /var/opt/eset/RemoteAdministrator/Server
Creating 'Pki Cache' directory path: /var/opt/eset/RemoteAdministrator/Server/pki.eset.com/
Creating 'logs' directory path: /var/log/eset/RemoteAdministrator/Server
Moving ReportTemplates from '/tmp/tmp.iMArQdf9mL/setup/ReportTemplates' to /var/opt/eset/RemoteAdministrator/Server/ReportTemplates/... done
Moving LangData.dat to /var/opt/eset/RemoteAdministrator/Server/Localization/LangData.dat... done
Extracting ReportPrinter files... done
Creating startup configuration file /etc/opt/eset/RemoteAdministrator/Server/StartupConfiguration.ini ... done
Creating config file /etc/opt/eset/RemoteAdministrator/Server/config.cfg ... done
Backing up contents of /opt/eset/RemoteAdministrator/Server
Copying files to target destination: /opt/eset/RemoteAdministrator/Server
Copying installer to target destination: /opt/eset/RemoteAdministrator/Server/setup/installer_backup.sh
File ownership set to: root:root
Setting auto-start service...
Generating Xauthority token... done
Created symlink /etc/systemd/system/multi-user.target.wants/eraserver.service → /etc/systemd/system/eraserver.service.
Installing SELinux policy... done
Removed backup directory: /opt/eset/RemoteAdministrator/.Server-052709045
Product installed.
Enabling port 2222 in firewall ...
success
success

Enabling port 2223 in firewall ...
success
success
Installing RDSensor ...

ESET Rogue Detection Sensor Installer (version: 1.1.615.2), Copyright © 1992-2020 ESET, spol. s r.o.

Extracting archive, please wait...
Archive extracted to /tmp/tmp.vNuMNoKuP2.
Generating GUID ... done [GUID = c05a4863-bdd3-4399-831c-19c5e36ae215]
Checking installed version... done
Status of current installation is: NEW
Creating 'config' directory path: /etc/opt/eset/RogueDetectionSensor
Creating 'libs' directory path: /opt/eset/RogueDetectionSensor
Creating 'data' directory path: /var/opt/eset/RogueDetectionSensor
Creating 'logs' directory path: /var/log/eset/RogueDetectionSensor
Backing up contents of '/opt/eset/RogueDetectionSensor'
Copying files to target destination: '/opt/eset/RogueDetectionSensor'
Removed backup directory: '/opt/eset/.RogueDetectionSensor-315434814'
Moving ESET Modules to /var/opt/eset/RogueDetectionSensor/Modules... done
Moving nmap-os-db file to /etc/opt/eset/RogueDetectionSensor/nmap-os-db
Moving vendors.txt file to /etc/opt/eset/RogueDetectionSensor/vendors.txt
Creating config file /etc/opt/eset/RogueDetectionSensor/config.cfg ... done
Setting auto-start service...
Failed to get unit file state for rdsensor.service: No such file or directory
Created symlink /etc/systemd/system/multi-user.target.wants/rdsensor.service → /etc/systemd/system/rdsensor.service.
Installing SELinux policy... done
Product installed.
Installing managing agent ...
stty: 'standard input': Inappropriate ioctl for device
Initialized log file: /var/log/eset/RemoteAdministrator/EraAgentInstaller.log

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

Creating directories...
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/AgentInstallerData
Extracting, please wait...
The unpacked installer data will be moved to: /opt/eset/RemoteAdministrator/Agent
Checking OpenSSL ... done [OpenSSL 3.0.7 1 Nov 2022]
Checking installed version ...
Status of current installation is: NEW
New connection settings are 'hostname': '127.0.0.1', 'port': 2222
Checking server connection...
Connection checked successfully.
Getting certificate from server...
It is not possible to authorize to ESET PROTECT Server with provided credentials.
Cleaning up setup directories

 

I can see some possible issues:

1) "Reading previous installation settings ... failure" <- why

2) "Status of current installation is: NEW" <- this is an upgrade, should it be stated here as new?

3) And of course the final lines: 

New connection settings are 'hostname': '127.0.0.1', 'port': 2222
Checking server connection...
Connection checked successfully.
Getting certificate from server...
It is not possible to authorize to ESET PROTECT Server with provided credentials.
Cleaning up setup directories
'/opt/appliance/installers/Agent.sh --skip-license --cert-auto-confirm --export-fingerprint=/tmp/server_fingerprint_agent.txt --hostname='127.0.0.1' --port='2222' --replication-interval 'R/20 * * * * ? *' --create-ca  --webconsole-hostname='127.0.0.1'  --webconsole-port='2223'  --webconsole-user='Administrator'  --webconsole-password=*****' command failed with 1.

Could the custom certificates of the old VA somehow be the cause of this?

In my notes, I can see that I had kept a second password (key possibly) that was made during creation of the certificate authority a couple of years ago. The web page wizard did not provide any place to store that information as well.

 

 

Edited by carmik
Title edit
Link to comment
Share on other sites
  • carmik changed the title to Centos VA to Rocky VA migration fails with "it is not possible to authorize to ESET PROTECT Server" with provided credentials
  • Administrators
Marcos

Marcos 5,272

Posted
  • Administrators
Posted

Please raise a support ticket for help with troubleshooting the errors.

Link to comment
Share on other sites
carmik

carmik 0

Posted
  • Author
Posted
21 minutes ago, Marcos said:

Please raise a support ticket for help with troubleshooting the errors.

Are you referring to the local eset support in my country, or something else altogether?

Link to comment
Share on other sites
  • Administrators
Marcos

Marcos 5,272

Posted
  • Administrators
Posted

Yes, I mean the technical support in your country provided by a distributor or resellers.

Link to comment
Share on other sites
  • 1 month later...
carmik

carmik 0

Posted
  • Author
Posted (edited)

@Marcos  I've opened a case a month ago regarding this issue. I got an explanation that the Rocky Linux-based VA was not ready for prime time, experiencing a number of issues, and it will be unknown when it will be ready. I tend to concur with this assessment, considering that I'm still unable to switch to Rocky from CentOS, as well as taking into account the number of problems cited for the new platform.

I understand that ESET is shiftiing its focus to cloud-based solutions, but up to this point it did not feel that on-premise installations would be threatened. Now, however, it feels like we are pushed (shoved?) to cloud solutions.

I'm writing this not expecting to find a prompt resolution to my issue, but rather as a complaint to the statements elsewhere that the VA is fully supported. Really wish I have known that I was served a beta-quality product, before trying to make it work over a couple of days.

Edited by carmik
Link to comment
Share on other sites
  • Administrators
Marcos

Marcos 5,272

Posted
  • Administrators
Posted

Are you having issues with the latest VA 11.0.19.1?

Changelog:

  • FIXED: Server crash during periods of high load, related to a crash in the MySQL ODBC driver
  • FIXED: Issues with upgrading ESET PROTECT On-Prem Virtual Appliance caused by SELinux rules
Link to comment
Share on other sites
carmik

carmik 0

Posted
  • Author
Posted

I have not tried installing the the latest VA, due to the feedback I've received from the local distributors. We have 2000+ users in total and I'd like to avoid having to handle critical issues that should have already been ironed out from a release-quality-level product.

Like I said, I'll most likely still use our CentOS-based platform for the next 2-3 months. After that I'll query the quality of the new VA platform  in the forums and from the local ESET distributors to make sure that I'm actually stepping into a steady environment.

Link to comment
Share on other sites
  • Administrators
Marcos

Marcos 5,272

Posted
  • Administrators
Posted

Most of the initially reported issues where caused by bug in the MySQL ODBC driver which is officially tracked in their bug tracking system. The issue manifested only in bigger networks which is why we could not reproduce it internally and why they could not be discovered during the pre-release QA tests.

We have not received any reports of issues with the latest version of VA.

Link to comment
Share on other sites
carmik

carmik 0

Posted
  • Author
Posted

I'm not sure if we are talking about the same issue: the one posted here, got case number #83153. Is this one solved or does a solution for it exist?

Link to comment
Share on other sites
  • 2 weeks later...
Slasoft

Slasoft 0

Posted
Posted

I'll add to the topic. I had the same problem, only a smaller environment - only 70 users.

Link to comment
Share on other sites
Garnek

Garnek 0

Posted
Posted
On 5/22/2024 at 10:19 AM, carmik said:

I'm not sure if we are talking about the same issue: the one posted here, got case number #83153. Is this one solved or does a solution for it exist?

I had the same problem. what helped me was restoring Rocky to factory settings and then Pull database from other server
https://help.eset.com/protect_deploy_va/11.0/en-US/pull_db_from_other_server.html

It works for me.
 

Link to comment
Share on other sites
carmik

carmik 0

Posted
  • Author
Posted

Garnek, do you mean that the restoring Rocky to factory settings did the trick?

Link to comment
Share on other sites
Garnek

Garnek 0

Posted
Posted 
Yes, restore Rocky to factory settings and then pull the database. I migrated from CentOS to Rocky
Link to comment
Share on other sites
carmik

carmik 0

Posted
  • Author
Posted

I'll redownload the VA and give it a try again then, thanks.

Link to comment
Share on other sites
  • 3 weeks later...
uhorisko

uhorisko 0

Posted
Posted

Hello, did you figured out this ? I have problem with migration from CentOs to Rocky VA : 

New connection settings are 'hostname': '127.0.0.1', 'port': 2222
Checking server connection...
Connection checked successfully.
Getting certificate from server...
Received server certificate is not valid. Please check whether server contains valid peer certificate from provided hostname.
Cleaning up setup directories
'/opt/appliance/installers/Agent.sh --skip-license --cert-auto-confirm --export-fingerprint=/tmp/server_fingerprint_agent.txt --hostname='127.0.0.1' --port='2222' --replication-interval 'R/20 * * * * ? *' --create-ca  --webconsole-hostname='127.0.0.1'  --webconsole-port='2223'  --webconsole-user='Administrator'  --webconsole-password=*****' command failed with 1.
Link to comment
Share on other sites
carmik

carmik 0

Posted
  • Author
Posted (edited)

Just reporting that redeployed with VA 11.0.19.1 seems to have fixed the issue.

Seems I spoke too soon.

There's something not working. My original install was with a en-US locale. When I now tried to install with el-GR everything seemed to work. VA booted ok and I was able to login to the normal web environment.

However menus etc in Greek did not help me navigate around the web functionality, so I pulled up a VA snapshot before VA configuration and re-initiated the web wizard, this time specifiying en-US as the language.

After boot I received the same error as in the OP: 

Checking server connection...
Connection checked successfully.
Getting certificate from server...
It is not possible to authorize to ESET PROTECT Server with provided credentials.
Cleaning up setup directories
Edited by carmik
Link to comment
Share on other sites
uhorisko

uhorisko 0

Posted
Posted

Hello,
I tried your procedure but without success.
Steps I did:
1. Boot clean Rocky VA
2. entering the command: update-crypto-policies --set DEFAULT:SHA1
3. Pull database - passed OK
4. Config of the new VA - filled in (hostname, pass, IP address)
5. Restart and same error

Link to comment
Share on other sites
carmik

carmik 0

Posted
  • Author
Posted (edited)

@uhorisko perhaps it would be better to open a separate thread for your issue, since it seems to be similar to mine but not exactly the same.

@Marcos not an expert here, but my issue feels like a locale-related one. My old VA was created with a en-US locale, but the certificates I generated in order to switch to SHA-256 a couple of years ago were made with a PROTECT user account that uses Greek and not English. I have a hunch that the certs have some sort of Greek information in them, resulting issues when trying to start up the new VA after completing the web wizard form of the new appliance and specifying something different to el-GR at wizard time.

Can someone from ESET HQ help me finally resolve this 2-month-old issue?

For the time being I'm switching back to my old VA; using the Greek VA interface is actually Greek to me.

Edited by carmik
Link to comment
Share on other sites
carmik

carmik 0

Posted
  • Author
Posted

Ok, I believe I'm closer now to what happened. My old VA server was configured with a el-GR locale. Advanced security was set up with that locale on the old VA.

Trying to migrate to the new VA, specifying a different locale (en-US in this case) throws the error described in the OP. That solved my issue.

Pretty disappointed by ESET support on this one.

Link to comment
Share on other sites
  • Solution
carmik

carmik 0

Posted
  • Author
  • Solution
Posted

Solution summary: make sure that on the new VA the same locale as the one specified during the old VA creation, is used.

Link to comment
Share on other sites
Guest
This topic is now closed to further replies.
 Share
Go to topic listing

  • Recently Browsing   0 members

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