axian Posted January 7, 2004 Report Share Posted January 7, 2004 We have a Mac OS 9.2.2 as our backup server with Windows, Macs, and one Linux client. Everything has been working and the Linux (RH 8) was seen in Retrospect. We recently changed our internal IP addresses to a different range. After the change was successful, Linux was no longer seen in Retrospect on the Mac. Both computers can ping each other as they are in the same subnet. The Linux box has one NIC with an internal address and a public address as an alias. I have tried reinstalling retrospect on Linux and I have tried /usr/local/dantz/client/retroclient -ip x.x.x.x to bind it to the internal address. I have also turned off iptables to make sure it wasn't a firewall issue. I've had no success. I cannot add the client by address as we do not have the license for that feature. Any help would be much appreciated. Link to comment Share on other sites More sharing options...
natew Posted January 8, 2004 Report Share Posted January 8, 2004 Hi Does the client run on the actual adapter or the alias? Is it possible to add a second NIC to this machine? I would try uninstalling the client again and making sure that the retroclient.state file was deleted. Nate Link to comment Share on other sites More sharing options...
axian Posted January 8, 2004 Author Report Share Posted January 8, 2004 I have tried reinstalling the client several times while making sure all retrospect files are deleted. The client runs on the adapter (eth0) -- not the alias (eth0:0). Installing another adapter would be the same logical setup so I don't see how that would solve the problem. Link to comment Share on other sites More sharing options...
natew Posted January 9, 2004 Report Share Posted January 9, 2004 Hi Do the problems continue if you temporarly bring down the alias and then restart the Retrospect service? Is the service stopped when you run the retroclient -IP command? Try it that way. Thanks nate Link to comment Share on other sites More sharing options...
axian Posted January 9, 2004 Author Report Share Posted January 9, 2004 The problem continues even if I bring down the alias, restart the service, and if I use retroclient -ip. I'm out of ideas except to call retrospect's tech support. Link to comment Share on other sites More sharing options...
natew Posted January 14, 2004 Report Share Posted January 14, 2004 Hi Do you have an OSX machine that you could run the network utility to portscan the linux client to make sure it is listening on port 497? Just to be sure, you have removed the linux client from the client database on the backup server right? Thanks Nate Link to comment Share on other sites More sharing options...
axian Posted January 14, 2004 Author Report Share Posted January 14, 2004 Nate, You gave me the fix. I had to remove the client from the server and add it again. I didn't think it was necessary, but thank you for the help. Link to comment Share on other sites More sharing options...
jg167 Posted May 27, 2004 Report Share Posted May 27, 2004 I have a simialr issue that I have been unable to resolve. Mac OS X 10.3.3 (now actually 10.3.4 but this happed with 10.3.3 as well) backup server with Retrospect 6 client (one of 4) is redhat 9 All was fine until I changed the linux system to have a static IP instead of using DHCP. Now it is not seen by the backup server. I have uninstalled/reinstalled on linux, removed the old entry from the backup servers client db, still no joy. If I use Retrospects volumes/confugre/test feature and type in the IP it finds it fine yet does not when searching. It is in the same subnet. Suggestions? Link to comment Share on other sites More sharing options...
jg167 Posted May 28, 2004 Report Share Posted May 28, 2004 Well I give up. If I set the IP on my linux box manually retrospect can test the cleint and sees it fine, but can not find it when searching. But if I use dhcp to get an IP for hte linux box it works. It must be something i am not setting up manaully quite the same way, but the annoying part is that the retrospect "test" feature works, (i.e. this is not an effective test in this case as it passes when, according to the serach results, it shold not). Oh well, to get around the problmes of DHCP with a small server, I just set the least time to 10 days so its very unlikely the IPs will ever change. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.