I added a second node to an Ootbi cluster in the lab this week. The flow is short and mostly gets out of your way, but a firewall rule or a certificate will decide whether it goes smoothly, so here it is with the screens in front of you.
The node came up on 1.7.82.12645. I gave it an IP, a netmask, and a gateway with a route out. Within a minute, it reached Object First, found 1.7.93.14382, and offered to install it.
That check is normal behavior, not a surprise. Once the appliance has network connectivity and a path to the internet, it looks for updates as part of the initial configuration and prompts you if it finds any. If nothing is newer, the screen never appears, and you go straight to the cluster steps.
The ports, before anything else
Most of the problems people hit in this flow are firewall problems, so here is what needs to be open.
Outbound 443, from the appliance to the internet. This is how the appliance pulls software updates and sends telemetry. Without it you get no update check and no automatic notification of new versions, and you are into the offline update method instead.
Inbound 443, to the cluster IP. The S3 endpoint. This is the one Veeam talks to, and it is the data path.
Inbound 8443, to the cluster IP. The Web UI, also called the Cluster Web Console. Management and monitoring.
Management network for IPMI, on its own interface, if you are using it. Remember that IPMI is disabled by default, and Object First recommends leaving it that way.
NTP outbound, since the appliance asks for time servers during setup and can use NTS if your environment supports it.
SMTP outbound, only if you want email notifications, which is where update availability alerts arrive.
One gotcha to know about that outbound 443 rule. Opening the port is not always enough. If your firewall does SSL inspection, it can break the update channel even though the port is open, and the fix is an exception for repo.objectfirst.com so the appliance’s connection to the update repository is not intercepted. If your appliance insists it is up to date when you know it is not, that is worth checking before you assume nothing newer exists.
My lab has everything open, which is why the update check worked immediately. In a properly segmented network, this is the first thing to plan.
The update runs before the join completes
The node updated itself during initial configuration, and only after that did I put it into the cluster.
The log is more open than most appliance installers. You get the REST call to install_updates with its parameters, the task ID, the async polling, the completion payload, and a progress percentage with an estimated time. When an update stalls, that is the difference between raising a support ticket and knowing what stalled.
It also shows the update being driven through the management REST API by an account named objectfirst, which is the same account the TUI references for privileged actions later.
Once a cluster exists, updates are applied at the cluster level rather than node by node. You trigger it once, and it pushes to every node, keeping versions aligned without you tracking them individually.
Joining the cluster
New cluster, or join an existing one.
Then enter the management IP of the existing cluster and the objectfirst password. The account name is fixed and shown to you rather than typed.
Then you verify the cluster UUID and fingerprint. This is the screen to read rather than press Enter through, because you are about to attach a storage node to a cluster, and this is where you confirm it is the right one.
The certificate changes, and you have to tell Veeam
Expanding the cluster changes the cluster certificate, and any S3 client with an existing connection needs to accept the new one. This is known behavior, and people have written about hitting it: the usual symptom is a repository rescan failing after you add a node, with the certificate as the cause.
What the appliance does here is tell you at the moment it happens, with the four steps to fix it in Veeam. Open Backup Infrastructure, select Backup Repositories, right-click the repository and open Properties, then step through the wizard and accept the updated certificate.
This is a lab, and I had not been careful with certificates, so I was exactly the person that screen is written for. Being told at the point of change is considerably better than working it out from a failed backup job the next morning.
The final screen gives you the serial, the model, the S3 endpoint on 443, and the Web UI on 8443.
What the TUI menu tells you
Two things worth noticing in that list.
The option descriptions name the account a privileged action requires: “Setup new cluster. This command is not available for users other than objectfirst. Log in with the objectfirst account to execute this operation.” Being told which identity you need, rather than having the action fail and working it out, is a small thing that saves time.
And Command shell sits in the menu alongside Reboot and Shutdown. Reaching it requires a temporary authorization code from Object First support, so the entry exists but nothing you hold opens it. I wrote about that access model separately, and seeing it as a greyed-out possibility in a menu makes the design more concrete than the documentation does.
Both nodes in the cluster
Obi-03 and Obi-04, both healthy, both 1.1 TB. From network configuration to a joined node that is already current, with no separate update step to remember.
Conclusion
The whole process took a few minutes, and most of that was the update running on its own. Give the node an address and a route out, and it arrives current without you tracking versions or hunting for the right build. Once the cluster is formed, updates apply across every node at once, so the appliances stay aligned without becoming another thing on your maintenance list.
The parts that need attention are the ones outside the appliance. Get the ports right before you start, and expect to re-accept the certificate in Veeam after the cluster changes. Neither takes long when you know they are coming.
Share this article if you think it is worth sharing. If you have any questions or comments, leave them here or contact me on Twitter (yes, for me it’s not X, but still Twitter) or LinkedIn, since I am getting off Twitter.
