archrenov8 Posted January 30, 2003 Report Share Posted January 30, 2003 I have just upgraded to my OS X Server to Retrospect 5.038 as I migrated the server from OS 9.1 to OSX on a beige G3/233, with a variety of OS 9 and OS X clients. All of the OS 9 clients are 5.0.238, and all of my OS X Clients are 5.0.540. I successfully logged on to everyone on the first day, although the first time I had trouble with a two of my three OS X clients. I had to trick it into logging in by "Adding by address". Well, the first attempt at backing up did not go well. I had error -102 trouble communicating with an OS 9 client, followed by error -519 communication failed, and several error -1028 not visible on network on two of my OS X clients, and on two OS 9 clients. Basically, my first OS 9 client was the only one to back up successfully. Today, I went back to the Configure panel, and this time had to log in to all three of my OS X clients by Adding by address". However, with one of them, I couldn't even do that. It said "Activator code ... is used for multiple clients: HGA Powerbook at 192.168.1.109 HGA Powerbook at 192.168.1.122" It instructed me to go the the Log, which confirmed this. We have a cable modem and router, so we are set to DHCP, so the TCP/IP addresses are changing daily. This seems to be preventing the OS X server from communicating with or logging on to the OS X Client. I also do not want to have to log in by "Adding by address" each day. This would entail opening up the System Preferences >Network panel and copying the assigned TCP/IP number each day for each OS X machine. I do not want to migrate the remaining macs to OS X until I resolve this backup issue. Link to comment Share on other sites More sharing options...
AmyJ Posted February 7, 2003 Report Share Posted February 7, 2003 Quote: Activator code ... is used for multiple clients: Activator codes were used by Retrospect clients many years ago. Are you sure these are OS X clients, and not OS 9? Try a new installation of the client software on these machines (in OS 9, throw away the client control panel, reboot and reinstall). Quote: We have a cable modem and router, so we are set to DHCP, so the TCP/IP addresses are changing daily. This seems to be preventing the OS X server from communicating with or logging on to the OS X Client. Do you see the clients listed if you go to Configure > Clients > Network? If the clients are in a different subnet, you'll need to set up Retrospect to look in other subnets through TCP/IP menu (Configure > Clients > Network). Retrospect will only look for clients in the local subnet unless otherwise configured. Once you can add the clients through broadcast, Retrospect will find them when they change IP addresses within the subnet. Link to comment Share on other sites More sharing options...
archrenov8 Posted February 11, 2003 Author Report Share Posted February 11, 2003 Yes, I do see the three OS X Clients when I go to Configure>Clients>Network. It indicates that they are Not Connected. When I click on Connect, it tries to connect and then comes back with "Client not visible on Network-error 1028." It is only connecting with one of the three OS X clients, which happens to have the same IP address as when we backed up last. When I try to Connect using Add by Address..., I plug in the current IP address and then comes back with: "Activator Code conflict found. See log window for details. Different computers may become confused with one another, causing backups to fail." Link to comment Share on other sites More sharing options...
mcswgn Posted February 11, 2003 Report Share Posted February 11, 2003 If you add by address, retrospect will expect to see that client at the same address next time. You said your addresses are changing, so this is going to create an onging problem. Also, if you have a client with the same name as an old client, the newer one will not show up in Configure->Clients->Network. For example, if a client has a clean install of the OS, is named the same as before, and has a new copy of the backup client installed, you won't see it (and so can't log into it) until its old incarnation is forgotten. The symptoms here are that on trying to connect to the client that you see in Configure->Clients you will be told that the client isn't visible on the network. Indeed it's not, as you are trying to connect to the old copy of the backup client, not the new one. In your case, if you try to add a client that has already been logged in, you will get a conflict--with itself! Retrospect sees that same client software at both the old (in the client database) and new (actually present on the network) IP numbers. You need to forget the client at its old IP number before you can add it at its new one. There appears to be more than one problem going on here, one of which is being obscured by the problem of adding the clients by IP number in an environment where IP numbers change. The question is, why were you unable to add the clients "normally" in the first place, and why did you have trouble the next day with clients that hadn't been added by IP number? What exactly is it that you are seeing in the client database the next day? That is, what was it that made you go "back to the Configure panel, and this time had to log in to all three of my OS X clients"? Did they not show up in the Configure->Client window? Did you see them as "source" in the Backup server window? Did you try to configure them and were told that "client not visible on network"? That might help figure out what's going on. Link to comment Share on other sites More sharing options...
mcswgn Posted February 12, 2003 Report Share Posted February 12, 2003 Interesting--Even though your last post was before my reply, it wasn't there when I was writing mine. Still it verifies that one of the problems is that you shouldn't be adding by IP number here. So, start by going to Configure->Clients and "Forget" all of the troublesome clients. Then go on to Configure->Clients->Network and try to log them in again. That will get to the crux of the real problem. What exactly do you see/not see? If my memory serves me well (which is probably a long shot :-) the "normal" behavior is that you should see the forgotten clients in the network window (in a lighter shade?) with "Not logged in". On selecting you are prompted for a password, get configuration window, etc, and then the client is listed as "Responding" How does your sequence differ? What problem crops up that prompted you to add by IP before? Also, make sure the clients are awake when you are doing this. Link to comment Share on other sites More sharing options...
archrenov8 Posted February 12, 2003 Author Report Share Posted February 12, 2003 When I did my first and only OS X backup, on January 30, (OS X on the server and on three out of eight clients), the size of the backups grew so significantly that it would not fit on one tape. So we weeded out what we were backing up to get them to manageable sizes. A week later, I tried to do another backup, and before doing so, I figured I would check to make sure everyone was still logged in. That is when I noticed the problem with two of the OS X clients. When I was originally configuring the three OS X clients, I had difficulty, and the only way I could get them to be logged in was to "Add by address". My personal computer is one of the three OS X clients, and since I am usually in first in the morning, I think our cable carrier assigns me to the first available address, so RS Server seems to have no problem finding me again. However, my other two OS X clients had different addresses, and that caused the problem. Now that I have read more RS documentation, I realize that I should not have added them that way. So, this morning, I tiried to follow your advice, and I "Forgot" the two troublesome clients. Then, when I went back to try to log in again, they simply did not show up at all. The only option I had was to add them by address again, and I wasn't about to do that. BTW, all of the OS X Clients are set not to sleep. I checked for pitond on the OS X Clients, and that was there. Is "pitond" something that RS Client uses but not RS Server, because it does not show up on the server? I also pinged one of the clients successfully (I didn't bother with the second one). As for seeing "forgotten" clients showing up greyed out, yes, that is the way it has been in the past (at least under OS 9). I don't know what to do to make it see the clients. From the server, I am able to connect to the two missing OS X clients across the network, so I know the network is OK. I was going to try to reinstall the client software this morning, but ran out of time. I don't know what to do next. Link to comment Share on other sites More sharing options...
mcswgn Posted February 13, 2003 Report Share Posted February 13, 2003 Quote: So, this morning, I tiried to follow your advice, and I "Forgot" the two troublesome clients. Then, when I went back to try to log in again, they simply did not show up at all. OK, now we're at the heart of it, and unfortunately there have been quite a few posts with the same problem in this forum--and I don't know that all have been resolved :-P. (Just to start with a little optimism :-) Start by checking that the MacOS X clients either have the firewall turned off in the Sharing pane of System Preferences or, if turned on, that port 497 is enabled. (I don't think these symptomes are consistent with this, though. I've made most of these mistakes, but I don't make them every day :-), so I tend to forget what they look like. I think in that case you can see the client, but can't log in--with some strange error. But it's worth checking anyway.) Frankly, it sounds like a subnet issue. The fact that it works when you add by address (until the address changes) says that the client and server are working fine. The server just can't see the client via its default multicast method. Multicast only goes (at most) to the local subnet. Go to System Preferences->Network on both Retrospect server and client and check what is listed under subnet mask and IP address. If the two IP numbers differ by more than where the zeros are in the subnet mask, then they are on different subnets. (This is easy if the subnet mask is 255.255.255.0--the IP numbers can differ in only the last quad. If, however, it is something like my DSL provider gives to my house, 255.255.255.252, you need to express the last number in binary: 252 = 11111100, which would say the two IP numbers could only differ in the last two bits of their binary representation. Sorry if this is too patronizing.) That would tell you whether the two machines are on the same subnet, but I think that can be misleading. The local subnet is supposed to be a "party line" where everyone hears what everyone else is saying--and certainly was the case in the "old days" with 10base-5 ethernet where everyone was connected literally by a single, uninterupted cable run. Now with current network topology, there can be lots of hubs, switches, "tunnels", even on a single subnet. Each intervening piece of hardware needs to actively forward on packets. So I think it is worth at least a little thought to what the hardware is that separates these two machines. Is it possible that something is filtering out multicast packets? Routers are supposed to do this, other things aren't, but there are devices capable of working on multiple levels, that could possibly be misconfigured. E.g. depending on how it's set up, an AirPort Base Station can work as either a bridge or a router. A bridge is supposed to forward everything, a router isn't. The standard advice (which I hate!) is to try connecting the two machines with a crossover cable and see if the client is now visible. Of course it's a royal pain to lug one machine down to the other! You also necessarily need to change the network settings since there's no DHCP server anymore, so you aren't really comparing apples to apples. (No pun intended.) Still, it's a good diagnostic. You could also try connecting them, to each other and the rest of the network, with a dumb minihub. (The dumber the better!) That would leave the network configuration alone, but you would be assured that the multicast traffic would get through, because minihubs forward everything. Another thing you could try would be to plug one of the MacOS 9 clients that can be seen by multicast into the jack of one of the clients that are invisible and then see if you can still connect to the MacOS 9 client. (E.g. see what happens if you try to get info on it.) Something else, which is not a solution, but possibly a work around, is that when adding by "Direct Access" this does not have to be by IP number. You can also use the DNS name. If your DHCP server pays attention to the DHCP Client ID field and places entries for clients in the DNS system, then you may have a fixed name even though your IP number changes, so you could add by DNS name. I haven't tried it, but it sounds like in that case Retrospect stores the name of the machine added, not the IP number and so could handle having the number change. The manual also says you can add by WINS name. I don't know if this would apply to a Mac client, although if you turn on Windows File Sharing in the Sharing pane you would certainly have a WINS name (which wouldn't depend on the what the local DNS server was doing). However, like I said, these are all just work arounds; they aren't solutions. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.