[RESOLVED] Several problems following update 2.2.3 => 2.3

[flipflip]

As things stand, apart from intervention from the Wapt team, I think I've exhausted all the options available to us.

What's somewhat reassuring is that at least two of us are experiencing the problem, albeit with different server configurations. So, for me, that rules out an infrastructure-related issue.

[fcomte]

I agree with this conclusion .

[flipflip]

Good morning,

Quick test results from this morning.

By some kind of magic, it works perfectly o_O.

I successfully deployed the agent to my workstations; they all registered on the server without any problems and are all logged in to the console. The only difference compared to usual is that I ran a task on all the workstations to force the time to be set (normally it does this automatically, but sometimes some of them seem to be out of sync). So I have a small package that I push, which just runs a little .bat file:

Code: Select all

@echo off
cls
net time \\monServerDeTemps /set /yes
exit

For the moment I haven't deployed wapt packages across my entire network, but just on a test machine, and it's working well with small packages (7-zip, PuTTY, WinSCP, FileZilla, Firefox, WinMerge... yes, it's a development machine) ).

[fcomte]

Good morning,

Encouraged by flipflip's experience, I tried manually uninstalling the WAPT agent on a test machine. After reinstalling the agent and several attempts to reinstall the console by deleting the folders indicated by flipflip, I still get this error message:

2023-02-21 12_17_17.png (6.89 KB) Viewed 7955 times

(I notice that the string at the end of the error message has changed since my last attempts)

What should I do to fix this problem?

[flipflip]

In hindsight, and I believe this has already been discussed, the problem stems from certificates following a change in how the installer (innosetup) handled them when upgrading to version 2.3 (to be confirmed by the Tranquil-IT team).

Without being an expert, it seems to me that at some point there was a problem distributing the certificates used to sign packages and communicate with the server. As a result, a stable situation became impossible. It's probably possible to redeploy the server's certificates to the agents, but that's beyond my expertise.

Perhaps a possible solution:

On a machine with a correctly functioning agent, compare the contents of the directory c:\program files (x86)\wapt\ssl and c:\program files (x86)\wapt\private and copy everything into the directory of a machine where the agent is malfunctioning. Restart the wapt service and run another test... This comes with no guarantee of success or a clean installation.

For me, uninstalling and reinstalling the agent wasn't enough; I also removed the entire server component (programs, configuration, certificates, database). It's fairly simple because my server only offers wapt; you just need to know the correct commands on Debian and where the files and databases are located to perform the final cleanup.

But you must follow the order carefully:
- Delete the machines via the console;
- Uninstall the agents;
- Verify that none of them have re-registered;
- On the server, stop all wapt processes;
- Uninstall wapt on the server;
- Uninstall PostgreSQL and nginx (for Linux; I don't know if it's the same on Windows).
- On the server, go through the system directories to delete everything related to wapt, postgresql, and nginx.

When in doubt, reboot (although it's completely unnecessary on Linux).

As it stands, you're almost on a freshly installed server, and all that's left is to install the server layer and then deploy the agent.

Unfortunately, since we're using the Discovery version, there's little to no support from the Tranquil-IT team, which is normal (and don't take this as a criticism) since it's the free version. They generate revenue and funding through the Enterprise version.

In practice, the machines in my network that gave me trouble during my tests were often VMs. Whether they were managed by VMware on a hypervisor or on my PC managed by VirtualBox. Is that the cause? I don't know. Perhaps it's a clue for future development of Wapt.

[fcomte]

Thank you so much for your feedback!

I think I'll go ahead with a complete reinstall, following the order you described. This will avoid any risky tinkering and allow me to take advantage of the situation to upgrade from CentOS 7 to Debian 11.

As for uninstalling the agents, I think I'll do it using a PowerShell or batch script deployed via GPO, based on your information. I'll test it first before proceeding.

I'll keep you posted. In any case, thank you again for your input! With your experience, I can approach the complete wipe with a bit more confidence .

[htouvet]

The directory " The agent's directory contains the agent's own keys (the certificate's CN corresponds to the machine's UUID) as well as private data for the installed packages. These keys allow the agent to authenticate with the server.
Therefore, this content should not be copied to another machine. The certificate in this directory is named after the machine's UUID. When opened in Windows, it can be verified that it was issued (signed) by a Certificate Authority (CA) named after the WAPT server.
If the keys in "

The directory " This directory must contain the certificate(s) (named with a .crt extension in WAPT) of the administrator who signs packages and actions (in the console, this is the certificate listed in the "Personal Certificate Path" field in the Tools/Preferences menu).
It must be exactly the same. The agent uses the certificates from this directory.

[flipflip]

Thank you for these explanations.

[dcardon]

Hello everyone,

I'm marking this thread as resolved. It's already far too long and no longer very useful for someone looking for answers to their questions.

If you have any new questions, please start a new thread.

Regards,

Denis