It's been ages since I've really had to mess with our Tivoli instance(s), and even back then, I was never the pro at it out of everyone in our group. Anyway, here's my situation. We're sadly still running TPMfOSd 18.104.22.168 (build 054.84), we had plans to move to 7.x last year, but, well... I won't get into that story.
As I was saying, TPMfOSd 22.214.171.124 (build 054.84)... We used to have several servers running this version. One parent and three children. Then slowly over the last couple of years the children have all died. They are still listed on our parent box in the "Server parameters" section under "Servers replication." They are listed as synchronized servers, but of course, they no longer exist. I was fortunate to just come across this article: http://www-01.ibm.com/support/docview.wss?uid=swg21619356 -- but it seems to only apply to version 7.1.1. Is there a way other than the method laid out here for telling our parent Tivoli server that its children no longer exist?
Next up, and really the more important question for me. When I stood up the only child server I ever installed, I seem to remember it automatically showed up in the listing of "Servers replication" as a standalone server. Some co-worker of mine (who is no longer with us) did something to make it get listed as a Synchronized server. I have no idea what he did. But that's not my problem this time around. This time, I've setup three child servers and NONE OF THEM show up in standalone! headscratch They are all synchronized from the commandline and seemingly match our parent server. I've deployed to a client PC successfully from one of these new children. But just how do I get my parent server to recognize these children??? I'm scared that the answer is I have to add them by hand in a MySQL console. I'm fairly well-versed in MySQL mind you, but that just seems like a scary approach.
Since it might get asked, these are all a mixture of SLES 10 and SLES 11 x86_64 boxes, running MySQL 4.1.22.
Too Long; Didn't Read Version:
1) How do I tell a parent server that its children no longer exist?
2) More importantly, how do I tell a parent server that it has new children that it just flat out doesn't see??
P.S. - When I sync a child server on the commandline (using this command: ./netclnt -f radsync.nc 192.168.0.1 password) I receive the following error when it gets to the database section of the script, "SQL local info query has failed : dbgw: did not receive a banner" - Is this something I need to worry about?
Pinned topic setting up new child servers and getting rid of orphaned/deprecated ones
Answered question This question has been answered.
Unanswered question This question has not been answered yet.
Updated on 2012-12-11T02:54:37Z at 2012-12-11T02:54:37Z by SystemAdmin
SystemAdmin 110000D4XK2750 Posts
Re: setting up new child servers & getting rid of orphaned/deprecated ones2012-12-11T02:54:37ZThis is the accepted answer. This is the accepted answer.Quick update: I discovered part of my problem and am working through resolving the rest of it (save for the SQL dbgw error I get at the end of the radsync.nc script). It turns out my issue was thus: at the time I started setting up new child servers, I did not have the original tarball of Tivoli 126.96.36.199. Instead, what I did was tar up my /tivoli directory minus /tivoli/files. Took them over to a new server, extracted them, and then ran setup. Now, when I'd go to the web interface of the new server I just setup, on every page where it'd report what the hostname was, it would come up as the correct hostname. But on that darn "Servers replication" screen, the host that I copied my files from was the default (and incorrect) selection. But it didn't present me with any other options.
After digging around on an old server, I found the original (clean?) tarball. I wiped one of my new servers I had just setup and started from scratch. Once I got everything installed, then, and only then did things start to show up properly. On that new instance, the correct host came up in "standalone servers." I have yet to "Make this server a slave server." But I will shortly, and I'll keep this updated in the off-chance that someone somewhere runs into this problem while maintaining such an old instance of TPMFOSD.
But if anyone has a handle on that "SQL local info query has failed : dbgw: did not receive a banner" problem I briefly mentioned... I'd greatly appreciate knowing whether I should do something more to resolve that. At this point it doesn't seem like a show-stopper.