Question

Rename worker host in Distributed Computing Cluster fix?

Laserfiche Self-Hosted Distributed Computing Cluster

Updated January 26, 2024

asked on January 23, 2024

I had a DCC consisting of 1 scheduler and 4 workers. I had to rename 2 of the workers. After doing this, both of those workers disappeared from the DCC settings.

For context, let's say the old hostname of one of the affected workers was "lfproddcc01" and I renamed it to "lfdcc01".

When I try to readd "lfdcc01", it shows the error:

The hostname lfproddcc01 could not be resolved.

Oddly, the error still displays the old hostname, even though I am trying to add it to the cluster using the new hostname. I've already tried reinstalling DCC on the affected workers. I've cleared the DNS cache on the scheduler and on the workers. I'm not sure what else to try. Any ideas?

0 0

Answer

SELECTED ANSWER

replied on January 26, 2024 • Show version history

I actually just found the solution myself. I had to do the following:

On the scheduler, modify C:\ProgramData\Laserfiche\Distributed Computing Cluster\Config\SchedulerConfig.xml to remove the old worker hostnames.
On each worker, modify C:\ProgramData\Laserfiche\Distributed Computing Cluster\Config\ServiceConfig.xml to use the correct worker hostname.
Restart the DCC services on the scheduler and affected workers.
Verify the settings in DCC Web Administration, readding the workers if necessary and verifying that "Allow machine to perform tasks" is configured correctly.

Thank you for getting me to the right folder! it really helped.

I would like to inform Laserfiche that I previously already tried repairing and reinstalling DCC on each of these workers, but apparently the ServiceConfig.xml file was never updated with the current hostname during these steps. This seems to me like it is an oversight that should be addressed to prevent this from happening any time someone changes the hostname on a DCC worker.

1 0

Replies

replied on January 26, 2024 • Show version history

Hi Kevin,

With limited info, we cannot be sure what the issue is. But one thing we can check is the Scheduler machine config ("c:\ProgramData\Laserfiche\Distributed Computing Cluster\Config\SchedulerConfig.xml") and see if there are old worker node names in it.

For example, you should remove the NodeAddress section of "Legacy Worker name" it they still exists:

<NodeAddressesOfOtherNodes>
    <NodeAddress>
      <NodeId>
        <HostName>Legacy Worker name</HostName>
      </NodeId>
      <BufferedPortNum>8107</BufferedPortNum>
      <MetaDataPortNum>8108</MetaDataPortNum>
      <PrivacySecurityMode>None</PrivacySecurityMode>
      <SslConfig />
    </NodeAddress>
    <NodeAddress>
      <NodeId>
        <HostName>New Worker Name</HostName>
      </NodeId>
      <BufferedPortNum>8107</BufferedPortNum>
      <MetaDataPortNum>8108</MetaDataPortNum>
      <PrivacySecurityMode>None</PrivacySecurityMode>
      <SslConfig />
    </NodeAddress>
  </NodeAddressesOfOtherNodes>

1 0

SELECTED ANSWER

replied on January 26, 2024 • Show version history

I actually just found the solution myself. I had to do the following:

On the scheduler, modify C:\ProgramData\Laserfiche\Distributed Computing Cluster\Config\SchedulerConfig.xml to remove the old worker hostnames.
On each worker, modify C:\ProgramData\Laserfiche\Distributed Computing Cluster\Config\ServiceConfig.xml to use the correct worker hostname.
Restart the DCC services on the scheduler and affected workers.
Verify the settings in DCC Web Administration, readding the workers if necessary and verifying that "Allow machine to perform tasks" is configured correctly.

Thank you for getting me to the right folder! it really helped.

1 0

replied on January 26, 2024

In general, repair/reinstalls of Laserfiche applications do not modify or remove any configuration files in .\ProgramData\ (and sometimes .\Program Files\. This is by design so if there are issues with the installation itself (binaries got corrupted, missing dlls, etc.) you can fix those without losing your configurations. Registry keys are similarly often preserved through those operations. This behavior is also important for making upgrades easier as those are sometimes "uninstall old, install new" and the new install loads and updates the old config files if present. Underpins a whole lot of "it just works" functionality most people don't give a second thought to.

If you want to completely clear out a config for a fresh start, uninstall the application, then manually delete any of its files that remain in .\ProgramData\ and/or .\Program Files\, then delete any corresponding registry keys (after taking a backup of them).

I realize this isn't necessarily intuitive; it's an area where we had to make an opinioned design decision on uninstall/repair behavior across the suite rather than an oversight. No plans to change it any time soon. Once you know the behavior you can act accordingly.

2 0

replied on January 23, 2024

Have you tried using fully-qualified hostnames?

Run this in PowerShell:

[System.Net.DNS]::GetHostByName($Null).HostName

And copy the output exactly.

0 0

replied on January 24, 2024

Yes, I have used both the host name and the FQDN. Both exhibit this same error message.

0 0

You are not allowed to follow up in this post.

Question

Question

Rename worker host in Distributed Computing Cluster fix?

Answer

Replies

Sign in to reply to this post.