V12 (unlimited Multi-Server) - remote Retro consoles can't log into Server

[henry-in-florida 14]

Recently installed upgrade. Unlimited Version 12 (Multi-Server). Worked fine for a day. After I got three clients up and running on one Server, (two had Console running on them just fine) for no apparent reason the next day two remote consoles couldn't log into the remote server (on local network). One user connects on Wi-Fi, the other on wired LAN.

 

Both remote consoles, on each of two clients, have the same issues logging in. Neither IP, nor Server name appear to resolve - spinning wheel all the time on each remote client (they worked the previous day). Yet, the local machine's Retrospect console opens just fine, it backs up to the clients just fine (the clients see the server, back up, show the status, etc.).

 

Tried reinstalling one console on the client, without change. I have not yet tried adding the Engine to another machine to see if I can replicate the issue there, that seems the obvious next choice. Anything else to try?

[Don Lee 72]

I'm not clear on exactly now this is all set up. It sounds like you have the engine on a machine on the local network, and (at least) 3 clients (as in client machines intended to be backed up). Some of these "client" machines also have the Retro console running on them, and the retro client can "see" the engine (server), but the retro consoles running on these same machines cannot see/resolve the server.

 

Right?

 

I would not try moving the engine. That will likely produce far more confusion than clarity.

 

The engine initiates the connection to the clients to do its work. The Console initiates the connection to the engine to do its work.

It sounds like there is something wrong in the DNS and/or networking in your installation.

 

Is the engine on a machine that gets its IP from DHCP? The engine really needs a static IP. Is the DNS OK? Are you using "local" DNS on a 10.x.x.x or 192.168.x.x network? Sometimes this gets things confused.

 

I would check to see if the backups are working. If so, then moving the engine is unlikely to solve anything.

 

Next, I would recommend  to delete and re-add the *engine* from one of the misbehaving consoles, and see if the console can "find" the engine. If not, there may be a firewall on the server/engine machine. (or on the client, for that matter) Try adding the engine by IP rather than DNS name. If the IP works, and the DNS does not, the DNS is your problem.

 

Judging from what is written above, this feels like a netorking environment issue, but it's hard to tell.

[henry-in-florida 14]

If not, there may be a firewall on the server/engine machine. (or on the client, for that matter) Try adding the engine by IP rather than DNS name. If the IP works, and the DNS does not, the DNS is your problem.

Thank you, sir. You had the last part correct. It is a firewall problem, but a curious one. For some reason, in Yosemite based machines the firewall algorithm doesn't work so well. This was particularly a concern after some kind of update (which may explain why Retro was fine at installation but after a day the console remote connection failed). The steps to reproduce this issue on a Server & Clients all running OS X Yosemite, release version 10.10.2 (14C1514):

 

1. Open the client side application, console… And confirm the application window has the spinning icon, not connecting.
2. Then choose one these:

   A. On the Server side, open the Firewall Settings (System Preferences>Security&Privacy>Firewall) unlock and turn OFF Firewall. 

   B. Set the “RetrospectEngine.bundle” to “Allow all incoming connections.” N.B., on the Client side, the app connects and operates the server. 

3. In the case of the first method (2. A.), the client will continue to connect as long as the firewall remains off. In the second method (2. B.), the client connects, but when the remote server is closed and re-opened without changing the firewall settings, it can no longer connect. 
4. I will try to reinstall the Engine on the Server machine to see if the same conditions continue to affect remote console access, Client discovery with the Firewall settings correctly set. This seems to be a software Engine issue or possibly an installation issue.

To accomplish the above, it would be helpful to log into the server remotely to observe and control it and observe the remote machine settings simultaneously.

 

Another consequence of this failure is that client machines do not auto-discover. 

 

In answer to your other question about IP assignment, the router has permanent assignment of the back up machines' IP (the machines live in DHCP mode, which in the case of laptops is important when they travel). 

 

Can you confirm the machines used, and check your firewall settings on a working installation of V12? This is a case that's pending at Retrospect Support. They have forwarded it to engineering based on the console logs I submitted (which appear to Retrospect's engine behavior with Firewall turned on and setting it to allow incoming connections). 

 

PS, my machine version/configs are in my signature line.

[henry-in-florida 14]

I'm not clear on exactly now this is all set up. It sounds like you have the engine on a machine on the local network, and (at least) 3 clients (as in client machines intended to be backed up). Some of these "client" machines also have the Retro console running on them, and the retro client can "see" the engine (server), but the retro consoles running on these same machines cannot see/resolve the server.

See signature line... You have it right. All local network, 3 client machines, 2 clients have Retro consoles that attempt a remote connect. The backups can be seen on (and were previously working in Retro v11) the server machine. 

[henry-in-florida 14]

Completely removed and re-installed the console & Engine (saving ALL the settings), using the uninstall tool. The Engine installed properly and Firewall setting was restored in the installation to pass incoming requests through the firewall.

 

So far, so good! Multi-cast even works better! It would have helped if Retro was certified so as to make manual firewall setting un-necessary. Perhaps this deactivation is what occurred during a recent system software security update between the first installation and the failed operation. 

 

Thanks for the advice iCompute. 

[henry-in-florida 14]

And then... After a shutdown and a cold restart of the Server machine where the Engine was resident- found that the problem recurs. So far as I can tell the issue is one of the Engine being mis-identified in the OS as one that doesn't seem to be an "accredited developer". Don't know if Retrospect has such a title or if this version is simply the offender as it hasn't happened with V11, ever. 

 

Now though if the (with latest Security Update) machine is RESTARTED from a shutdown the firewall enabled and the OS Preferences settings set to "Allow..." after restarting here is what happens (see screenshot). Hello Retro... You guys really need to fix this!!! 

[bdunagan 70]

Thanks for reporting this. We see this issue (#5363) as well, and we'll have a fix ready shortly.

[Don Lee 72]

Remind me not to upgrade to 10.10. :-(

[henry-in-florida 14]

Thanks for reporting this. We see this issue (#5363) as well, and we'll have a fix ready shortly.

On other matters different but related to the original problem, I found that:

1. The latest 12.0.0 Client is not accepted for installation into current MacOS X Yosemite. There is a security warning generated, “From an Unidentified Developer.” It can be gotten around, but...
2. The removal script, likewise is not accepted. 
3. The updater software when used from the Retrospect Server will not install on the client completely. The Multicast port comes up unavailable when updated in this way on an iMac Client. It is therefore required to do a uninstall and re-install on the client machine in order to get Multicast to work (suspected because of the above issue). 
4. Because of one or more of the above issues, operation of Retrospect with above client began being flaky suddenly (after limping along and working when client was located manually). It stopping working entirely 31 March 2015, and caused the server machine to drop it’s security connection when attempting to backup this client. And so started my cycle of pain (PIA) all over again at the server (click the server allow button to get the engine to run, et al) as previously described. Wow! 

You may want more troubleshooting information about these issues, if you wish to pursue it will await further instructions. I believe that the central issue to these and possibly other problems is the acceptance of security registration of ALL Retro products on the current MacOS platform. 

 

[henry-in-florida 14]

Remind me not to upgrade to 10.10. :-(

Remind me to look for a note on Retro, "Not for use on OS 10.10.x"

[henry-in-florida 14]

Thanks for reporting this. We see this issue (#5363) as well, and we'll have a fix ready shortly.

Thanks, Mr. Dunagan. If you want to dial me into the progress on #5363, feel free to do so. 

[henry-in-florida 14]

More on Client flakiness... 

Seems that there is a correlation between the Retro app, Engine, and Client in this version such that when the Engine is installed (perhaps inadvertently), the Client turns itself off. I don’t know if this is a bug or intentional. Don’t remember it as an issue from previous versions. 

 

However, I had this issue on another client, and fixed it by removing everything and re-installing the app (only), then the Client directly on the client, since the Updater has been flaky. There seems to be an underlying issue plus the one- one or both that seem to somehow impede the client from running. The client this time was a MacPro also running OS X 10.10.2 (Yosemite). My full system config is in my signature line and should be current. 

[henry-in-florida 14]

Thanks for reporting this. We see this issue (#5363) as well, and we'll have a fix ready shortly.

As of the current update to Engine & Console 12.0.1(104), it is NOT FIXED. Just for fun I tried, after using the workarounds previously discussed (manually allowing Retro in the Mac OS Firewall on each machine- client, server) to do the update from the client to the server in Retrospect new version after the update from an updated remote console. 

 

In order to do that, the Server permission MUST be accepted again. I think this is part of the same issue. The issue number you mentioned #5363 is NOT listed as being fixed. So I was simply taking a shot. Just thought you'd like an update. Any idea when it will be done? 

[pbartoli 2]

As of the current update to Engine & Console 12.0.1(104), it is NOT FIXED. Just for fun I tried, after using the workarounds previously discussed (manually allowing Retro in the Mac OS Firewall on each machine- client, server) to do the update from the client to the server in Retrospect new version after the update from an updated remote console. 

 

In order to do that, the Server permission MUST be accepted again. I think this is part of the same issue. The issue number you mentioned #5363 is NOT listed as being fixed. So I was simply taking a shot. Just thought you'd like an update. Any idea when it will be done? 

 

Exactly same problem here. Any update ?

[bdunagan 70]

Yes, unfortunately, the 12.0.1.104 release does not include this fix for the server. We are currently working on a second update to v12, which will include it. We have not been able to reproduce the firewall issue with the client however.

 

@henry-in-florida If you still see the security warning when installing the client or a firewall alert for running the client, could you post a screenshot here or to your support ticket? Thanks!

[henry-in-florida 14]

Yes, unfortunately, the 12.0.1.104 release does not include this fix for the server. We are currently working on a second update to v12, which will include it. We have not been able to reproduce the firewall issue with the client however.

 

@henry-in-florida If you still see the security warning when installing the client or a firewall alert for running the client, could you post a screenshot here or to your support ticket? Thanks!

Have a look at my post in this thread on 23 Mar 2015. The attachment is there. 

[bdunagan 70]

@henry-in-florida I see the screenshot for RetrospectEngine.bundle, and we will have that fixed. You said you had the same experience with Retrospect client. When you have a moment, could you post a screenshot of that as well?

[henry-in-florida 14]

Sorry, cannot do. I reinstalled the Client. So far it hasn't recurred. I shut most (two of three) clients off and do a cold start on them weekly. You'd think that a failure of this kind would recur but so far it hasn't, only the Server running the Engine has been an issue. 

 

While I have you and speaking of clients, noticed that on my iMac client it is losing it's connection to Retro - when asleep, going to sleep while a backup is in progress - in the default power setting (System Preferences>Energy Saver>Power). The only work around I've found is pictured below (set CPU to never sleep).

 

Therefore, I conclude that the Wake for Network Access feature, while it works for other functions (shared connections via smb or afp, other backup programs, Time Machine) does not in Retro. Below workaround works because it does not allow the CPU to sleep. I have had several failures of backups as a result of this issue. 

1. Can you confirm this sleep setting is not a 'workaround' but a required client setting for Retrospect?
2. Do you have any other method to allow the computer to be backed up when asleep (or going to sleep) without running the CPU 100%, instead of these settings? This has been a problem in previous versions of Retro and from the forums, I see that I'm not the only one.
3. If it isn't fixable, please correct or notate this requirement to not sleep the CPU to perform client backup in the User Manual.

 

On a positive note, Client automatic discovery or manual discovery (Locate) do match up for the first time in V12 in their ability to 'see' the client machine's log-in state. As an aside, you may wish to note that the Mac Energy Saver settings differ on some newer machines.