Jump to content
Sign in to follow this  
mmcleary

Retrospect 5.1 and Linux Clients

Recommended Posts

on 15/7/03 3:10 PM, Robin Mayoff wrote:

 

> This exciting new version adds many new features including a bootable

> Disaster Recovery CD and support for Red Hat "Linux" versions 6.2, 7.1,

> 7.2, 7.3, and 8.

 

I've been using the Windows version to backup my Linux machines (Cobalt

Qube3s to be precise) and its been working great. Now that the Mac version

supports the Linux client I've downloaded an evaluation version to give it a

bash.

 

Installation of 5.1 went well, but it will not see my Linux machines

although my Windows (Backup Server) can see them. Currently my Linux

machines are running client 6.0.143 and 6.5.105. As I requested a Desktop

licence I can't add the client by IP. Not to be defeated I obtained a

Server evaluation key but it still can't "see" my Linux machines on the

network. At least now I can add them by IP.

 

Any suggestions as to what the problem is?

 

Having added them my Linux clients by IP I've upgraded by Qube3s to client version 6.5.108 but they still don't "appear" when I attempt to add clients.

 

I was using Retrospect 5.0, but I've been able to reproduce the same situation on a clean machine.

 

Cheers, Malcolm

 

Share this post


Link to post
Share on other sites

Hi,

 

If the Linux Retrospect client is not seen in the client database automatically, it is surely because the UDP broadcast doesn't go through.

You should try to install Retrospect Client on an other machine, like a Mac OS machine and check if you can see it automatically in the Client Database. If so, then it means that the Backup Server machine accepts Broadcast and that your issue is due to your Linux machine.

Then check on the Linux machine if the firewall doesn't stop UDP packets. If so, set up your Firewall to accept UDP packets.

 

Regards,

 

David

Share this post


Link to post
Share on other sites

Hi,

 

Perhaps I should outline the environment I was testing in.

 

Currently I'm running a W2K box as a "Backup Server". It backs up 2 Linux machines, a MacOS X Server, a MacOS 9.2 iBook, a MacOS X iBook and 3 older MacOS desktops. All is well.

 

I installed Retrospect 5.1 on the MacOS X iBook and it could "discover" everything except the Linux machines, but it could see them once they were added to the client database by entering their IP addresses.

 

This afternoon I installed Retrospect 5.1 at two client sites. The first site produced the same experience as I have in my LAN. The second site worked as advertised. The question is what is different.

 

I've had a think about what is different between my environments and I've reconfigured one of my Linux machines to replicate the working configuration I encountered.

 

What I've found is that the working machine had one active NIC ... the machines I can't "discover" have both NICs active and are acting as network gateways.

 

When I set up my Windows Backup Server my Linux machines were just on the LAN and used only one of their NICs ... hence they could be "discovered". I dare say that if I instructed Retrospect for Windows to forget these Linux clients it wouldn't discover them either.

 

So whats the deal with the Linux client and 2 NICs?

 

I have FileMaker Server running on these machines and FileMaker Pro can "discover" the server and list the served files. Without doing anything special, FileMaker Server is only available on the primary NIC. This would indicate that the problem is the client or at least how it deals with responding to the discover process when the machine has two NICs.

 

I do have ipchains active on these Linux machines, but all the restrictive rules are for the secondary "exposed" NIC ... the only rule for the primary NIC allows all traffic.

 

Cheers, Malcolm

 

Share this post


Link to post
Share on other sites

Hi,

 

From additional trials it appears that the Retrospect Linux client does not respond to multicast when the Linux machine has two NICs with the client bound to one interface while the gateway is on the second interface.

 

Hence the scenario which does not work (for multicast discovery) is when the Linux machine is the network gateway for the LAN with Retrospect bound to the primary NIC and the "internet" is connected to the second NIC.

 

Cheers, Malcolm

Share this post


Link to post
Share on other sites

I seem to have experienced the same problem and wonder if anyone has found a solution.

I am using Debian 3.0r2. I setup a test box with a minimal debian install, and a single NIC on a 192.168.x.x

LAN. It worked fine using Robin's Debian .deb file (although I had to use --force-depends). When installed on

the Debian box with 2 NICs (my LAN/WAN interface) it doesn't seem to work, the Mac 5.1 Retrospect server doesn't see it. I ran nmap and netstat and it appears that the client is listening. I even tried setting the IP to the LAN interface only.

 

Any suggestions?

 

Also any chance of getting a Debian version that uses the "stable" version libraries so we don't have to force-depends (Debian doesn't like that).

 

Thanks.

Share this post


Link to post
Share on other sites

Hi All,

 

The Multicast how-to mentions that the Kernel decides which interface to route multicast to. That said I can't say I know how to change it...Sorry

 

nate

Share this post


Link to post
Share on other sites

Help me out here.

 

1. Are you saying that the retroclient uses some form of multicast (via udp??) to annouce itself to the network?

And that it is the kernel that determines on which interface (eth0 or eth1) that broadcast shows up?

 

So are you saying that on my dual NIC system the kernel is using eth0 and that is why I don't see it on eth1? If

this is true I should be able to detect this on the eth0 side of my system?

 

2. I did an /sbin/ifconfig on my system and BOTH eth0 and eth1 show the line:

UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

 

3. I'm really confused. What does the binding of the client to a particular IP then accomplish?

 

4. I may take my test system on my lan, on which the retroclient works fine, add another nic and see if I can

see the client on either nic. I should be able to give both of them 192.168.x.x addresses and see what's up.

 

thanks.

 

 

Share this post


Link to post
Share on other sites

Hi

 

The client listens for multicast (UDP) on port 497. The Retrospect server sends out packets on the multicast address and listening clients respond accordingly.

 

In a dual nic setup there are cases where one nic will pick up the multicast pacets and the other will respond to those packets. In that scenario it would mean that the multicast replies are being sent to your wan connection.

 

Binding Retrospect client to one IP address should fix this (it works in my dual nic RH box). However the mulitcast how to implies that the Kernel makes the final decision about where multicast packets get routed. This is a total guess but The kernel may be over-riding Retrospect clients attempts to send multicast to the internal nic.

 

The thing to keep in mind is that Multicast is only used for client discovery. If you have a workgroup or server version of Retrospect you can connect to the client by direct IP, bybassing multicast completely.

 

Nate

Share this post


Link to post
Share on other sites

Quote:

natew said:

 

The thing to keep in mind is that Multicast is only used for client discovery. If you have a workgroup or server version of Retrospect you can connect to the client by direct IP, bybassing multicast completely.

 

 


 

How do I check which version I have. I recently upgraded from 4.3 (which had a 'server' mode) to 5.1 on my Mac. I haven't run it in any server mode, but I do have scripts that backup the different clients on my lan to DAT tape.

 

I also think that I could use the route command to force the broadcast to the LAN nic.... maybe...

Share this post


Link to post
Share on other sites

Hi

 

The easiest way to check is to look at the configure->clients window in Retrospect. If you have an "add by address" button. You have Retrospect workgroup edition or higher.

 

This feature should get around any problems with multicast.

 

Nate

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
Sign in to follow this  

×