Jump to content
emulator

Mac OS Universal Client keeps shutting off

Recommended Posts

I just upgraded three of our Mac servers to the new Universal Mac OS Retro client, and every time I reboot these systems, the Retrospect client's state is turned to "Off". Is there anyway to keep the client turned to "on" after the system is rebooted?

 

We are running client version 6.2.229.

Edited by Guest

Share this post


Link to post
Share on other sites

It should not be turning off. This could be a sign of a problem with the permissions in the Retrospect Client package, which a few users have reported.

 

Try to uninstall and reinstall the client on one of these systems. Does it fix the problem?

Share this post


Link to post
Share on other sites

What are the permissions on each file within the Retrospect Client package resource folder?

Share this post


Link to post
Share on other sites

I don't know if this has anything to do with it, but I did not install the client by using the installer itself. I instead ran the update package from the Retrospect MultiServer itself. Do you think that this might have been the cause?

Share this post


Link to post
Share on other sites

Here's the permissions:

 

ls -ale /Applications/Retrospect\ Client.app/Contents/Resources/

total 9616

drwxrwxr-x 18 root wheel 612 Jun 30 19:38 .

drwxrwxr-x 7 root wheel 238 Jun 30 19:37 ..

-rwxrwxrwx 1 root admin 15648 Jun 17 18:26 EMC_client_logo.tiff

drwxrwxr-x 7 root wheel 238 Jun 30 19:37 English.lproj

drwxrwxr-x 7 root wheel 238 Jun 30 19:37 French.lproj

drwxrwxr-x 7 root wheel 238 Jun 30 19:37 German.lproj

drwxrwxr-x 7 root wheel 238 Jun 30 19:37 Japanese.lproj

-rwxrwxrwx 1 root admin 47436 Jun 17 18:26 RetroClient.icns

drwxrwxr-x 3 root wheel 102 May 8 09:22 busco.app

drwxrwxr-x 3 root wheel 102 May 8 09:22 defer.app

-rwxrwxrwx 1 root admin 22084 Jun 17 18:26 firewallcon

-rwxrwxrwx 1 root admin 27872 Jun 17 18:26 firewallcon2

-rwxrwxrwx 1 root admin 22740 Jun 17 18:26 icon.tiff

-rwsrwxr-x 1 root wheel 490336 Apr 6 2006 pitond

-rwsrwxrwx 1 root admin 1845400 Jun 17 18:26 retroclient

-rwxrwxrwx 1 root admin 632196 Jun 17 18:26 retropds.22

-rwxr-xr-x 1 root wheel 1789636 Jun 19 08:52 retropds.24

-rwxrwxrwx 1 root admin 1011 Jun 17 18:26 universe.png

 

Share this post


Link to post
Share on other sites

Did you have the beta version installed before running the RCU? The RCU can not correctly update the beta.

Share this post


Link to post
Share on other sites

No...I never installed the beta at all.

 

I'm also noticing that on all three Mac Servers, the Retro client is spontaneously switching itself off. Two backups *just* failed in the middle of scanning the disks.

 

I'm going to try a force regression to the older client.

Share this post


Link to post
Share on other sites

I just tried downgrading one of the clients, and now Retrospect Server does not recognize it (...wrong client found at that address... error). I had to forget the client and re-add it for things to function correctly.

Share this post


Link to post
Share on other sites

There is one way around the forgetting and re-adding (I have a bunch of custom "Volumes" that need to get backed up, and I didn't want to re-add them). I used the following to keep those mappings:

 

1. Downgrade the client by using the Retro server.

2. Once the downgrade is completed, the client defaults to the "off" state. Go to the backup client and turn the Retro client back on. Retro client prompts to enter a password for security access. Enter the password twice.

3. On the Retro server, double-click the client.

4. Under the "Access" tab, click the "Change" button.

5. Enter the IP address of the client (this is going to be the same IP as what Retro Server originally had stored in its database). Click OK.

6. Retrospect Server warns that we are replacing the existing client with the new one in the backup server database. Confirm this change.

 

This retained all but four custom-mapped volumes for me. Also, I didn't have to re-map my scripts to my custom mapped folders.

 

I hope that this helps.

Edited by Guest

Share this post


Link to post
Share on other sites

6.2.229 client turns off after restart

 

------------------------------------------------

Discussion

 

 

If you update to Retrospect 6.2.229 client using the .rcu (Retrospect Client Update) file, a bug in the update process may cause the Retrospect Client for Macintosh to fail to turn on after restarting the computer. EMC Insignia is working to publish a new .rcu file to correct this problem.

If your Macintosh client is turned off after running the .rcu file, you can fix the problem several ways:

 

1) Go to the client computer. Download the 6.2.229 client installer from http://www.emcinsignia.com/updates and uninstall and then reinstall the Retrospect Client. You will then need to forget and relogin the client in the Retrospect Client database.

 

2) If you need to correct the problem from a central computer you can download Retrospect 6.1.138 for Macintosh at http://download.dantz.com/archives/Retro-EN-6_1_138.dmg

 

Install 6.1.138 to a new directory. In Retrospect go to Configure>Clients and select Update All from the client menu. Select the Mac_X_Client_Update_6_1.rcu file from the OS X Client Updater folder. This process will downgrade the client to the prior version. Retrospect 7.6 and 6.1.230 is fully compatible with this older client.

 

Contact technical support if you need help with any of these steps.

 

 

 

Share this post


Link to post
Share on other sites

What I don't understand is this feature has most likely been requested since restrospect 2.0, we are now at restrospect 7.6 and it's still not there.

 

And now with the Mac 6.2.229 RCU screw up, and the fact that 19 of the 19 mac clients I updated via the RCU will have to be re-installed with 6.1.130 since 6.2.229 always turns off spontaneously, even after a "re-install, forget re-add" and re-added to the Retrospect Client Database.

Which after the backup cycle runs will create 19x3 orphaned duplicate snapshopts x2 backup sets = 114 orphaned duplicate snapshots.

Because Retrospect isn't smart enough to groom orphaned snapshots caused by clients re-adds, even though they have the exact same name, same IP and same password.

 

And since you can only do 1 at a time, that means 114 x 15minutes = 1710minutes, that's 28.5hours of time wasted, with me having to sit there and do each of them manually, 1 by 1.

 

Imagine if we had thousands of broken 6.2.229 clients. What hell this would?

 

>If you need to correct the problem from a central computer you can download Retrospect 6.1.138 for Macintosh at http://download.dantz.com/archives/Retro-EN-6_1_138.dmg

 

>Install 6.1.138 to a new directory. In Retrospect go to Configure>Clients and select Update All from the client menu. Select the Mac_X_Client_Update_6_1.rcu file from the OS X Client Updater folder. This process will downgrade the client to the prior version.

 

The previous suggestion is useless, as the clients have to be on and functional for the downgrade to work. The fact that 6.2.229 spontaneously turns off doesn't help at all.

 

Retrospect is supposed to be a good product. And it's not like the Retrospect Multi-Server with Open-Backup License is cheap. This should not happen

Is there any testing and quality control done in the development process at all?

 

I will be vary weary of mac client upgrades in the future. And I may even completely forget about the mac support and find another backup solution. Retrospect 7.5 now 7.6 might just be the last version of Retrospect we purchase.

Share this post


Link to post
Share on other sites

Even though the client is "off", a downgrade is possible. The client is actually running, the UI just doesn't know it.

 

1) Install/Launch the prior version of Retrospect

2) Go to Configure Clients

3) Use the Update all command and point Retrospect to the 6.1 RCU files.

4) The clients will revert to the older version.

Share this post


Link to post
Share on other sites

I just did that, and it started quickly going through the 19 clients, and it said : 0 updated sucessfully, 19 not updated.

 

They are still running 6.2.229. I check the operation logs and get a bunch of update failures related to "error -523 (service transaction error)" and "error -541 (backup client not installed or not running)"

 

Share this post


Link to post
Share on other sites

When I tried the steps, they worked for me. Not sure why they are failing in your situation.

 

What version of the Application and client did you try downgrading to?

Share this post


Link to post
Share on other sites

To do the client downgrade, you must be running the 7.5 version of the server application, not 7.6. So you would need to uninstall 7.6 and install 7.5

Share this post


Link to post
Share on other sites

Are you guy serious?

 

This was a major screwup, and there isn't a fixed RCU to fix the clients from 7.6?

 

We already purchased and implemented Exchange 2007 backup support, which isn't supported under Retrospect 7.5. Therefore reverting to 7.5 isn't possible.

Share this post


Link to post
Share on other sites

Once you use the 7.5 application and the older .rcu file to revert the clients back to 6.1, you can then uninstall 7.5 and install 7.6.

 

7.6 will work fine with the 6.1 client.

 

You only need 7.5 temporarily to do the version downgrade of the client, you can then return to 7.6.

 

 

 

Share this post


Link to post
Share on other sites

A new RCU will be released that will prevent this from happening in future updates, but once the "bad" RCU is applied, the 7.6 version can no longer talk to the client while the 7.5 can.

Share this post


Link to post
Share on other sites

Hi,

 

I just did what you suggested, shutdown restrospect, uninstalled 7.6. Installed 7.5.508, went to clients, chose update clients, chose the 6.1 Mac OS X RCU.

It goes through the process and none of the clients have reverted. In the Operation logs I see update errors related to error -541 (backup client not installed or not running) with ncmxOpenDLFile: can't open "retropds_macosx_uni.pdu", error -1101 (file/directory not found) following that.

 

And quite a few error -1101 (file/directory not found) aswell.

 

I also tried installing the latest hotfix after that, and tried again, no change.

Sounds alot like I'm going to have to manually uninstall and re-install all clients with the 6.1 version.

Edited by Guest

Share this post


Link to post
Share on other sites
Here's the permissions:

 

ls -ale /Applications/Retrospect\ Client.app/Contents/Resources/

total 9616

drwxrwxr-x 18 root wheel 612 Jun 30 19:38 .

drwxrwxr-x 7 root wheel 238 Jun 30 19:37 ..

-rwxrwxrwx 1 root admin 15648 Jun 17 18:26 EMC_client_logo.tiff

drwxrwxr-x 7 root wheel 238 Jun 30 19:37 English.lproj

drwxrwxr-x 7 root wheel 238 Jun 30 19:37 French.lproj

drwxrwxr-x 7 root wheel 238 Jun 30 19:37 German.lproj

drwxrwxr-x 7 root wheel 238 Jun 30 19:37 Japanese.lproj

-rwxrwxrwx 1 root admin 47436 Jun 17 18:26 RetroClient.icns

drwxrwxr-x 3 root wheel 102 May 8 09:22 busco.app

drwxrwxr-x 3 root wheel 102 May 8 09:22 defer.app

-rwxrwxrwx 1 root admin 22084 Jun 17 18:26 firewallcon

-rwxrwxrwx 1 root admin 27872 Jun 17 18:26 firewallcon2

-rwxrwxrwx 1 root admin 22740 Jun 17 18:26 icon.tiff

-rwsrwxr-x 1 root wheel 490336 Apr 6 2006 pitond

-rwsrwxrwx 1 root admin 1845400 Jun 17 18:26 retroclient

-rwxrwxrwx 1 root admin 632196 Jun 17 18:26 retropds.22

-rwxr-xr-x 1 root wheel 1789636 Jun 19 08:52 retropds.24

-rwxrwxrwx 1 root admin 1011 Jun 17 18:26 universe.png

 

You should ABSOLUTELY NOT run a client, or any other software, with these permissions, your computer will be made UTTERLY INSECURE!

 

Several of the files above are writable either by anybody, or, maybe a tad better, anyone in the admin group.

 

NEVER NEVER NEVER do this!

 

These programs are ran as root, and some of them even setuid to root if they are run by somebody else (the "s" flag above).

 

This means, for example, that any program you run could overwrite one of the programs above and replace it with anything it would like to be made, such as opening a back door or anything else. It could also easily clean up after itself and you would never see it has happened.

 

It is most remarkable that the client could ever be installed with these permissions. If EMC/Dantz software has installed it like this one wonder how much they know and care about the customer's security at all, and if any of their software could be trusted at all.

 

/ragge

Share this post


Link to post
Share on other sites

Ragge,

 

Your feedback is appreciated. As you probably know by reading this and other threads, a problem existed with how the client was updated on some computers. This is why the user posted the permissions, so that we could diagnose the problem.

 

Have you looked at the permissions on your working configuration?

Share this post


Link to post
Share on other sites

ragge,

 

I'm as critical as you are when world-writable setuid root programs are installed, but I believe that this was fixed back in 2005. The poster may have an old install. See this old thread, in which I was as critical as you on this point, and the problem was shown to have been corrected by a newer installer:

Mac client pitond installed world-writable setuid root

 

Personally, I think that a post-install script should check this and fix, if necessary, from a prior improper install. If the RCU push cannot handle this, at minimum a dialog should be presented.

 

Russ

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×