Configure SLP Properly for Server to Server name resolution across WAN

okay - each site has it's own scope.  No, I haven't touched the SLP.CFG.  Don't care about the users seeing services across the WAN because some of them roam.  They can resolve via NDS anyways.  There is a firewall but it's not filtering private stuff (only DMZ and Public).

Each office has at least one server.  That server (at least one) has a DA.  The DA's are default installs from NetWare 6.5 - I believe they are scoped.

My problem is this:

unless I use the IP address of the Primary Time Server (x.x.x.x:123) the servers cannot resolve.  They don't see the server names (I get the 11001 error about unable to resolve).

In addition, I just tried to do something in which a POA had to access the file system of another server in another segment.  I discovered thru trial and error the POA couldn't resolve the shortname of the server (because all I can do is enter it in a UNC format) and thus the POA couldn't access the server (8912 error I think) to get to the file system.

Since this is not a problem with servers still running IPX/SAP I realized that my IP/SLP configuration is not addressing the issue of being able to resolve server names across the WAN.  Which also explains the 11001 errors I get in DSREPAIR when I do a Full Repair (in which the servers can't resolve names there either).

So basically, I need to reconfig SLP so the servers see each other.  I'm not too thrilled about having to modify an SLP.CFG file - that sounds so LMHOSTS too me ;)

I am assuming there is a way to do it via NDS/eDir without doing file modifications.

(I'm just assuming you're in Syracuse, of course. You might want to use Sacramento instead...)

"Is each location's scope in the other location's scope list on the DA servers?"

No.

"If not, maybe as a test you could add Seattle's scope to Syracuse's scope list and vice versa..."

Okay - how do I add the scope of Seattle to Sacramento (or Syracuse in your case) and vice versa

btw:  Happy Inauguration Day!

I don't know if you'd want to totally redesign your SLP configuration, but another possible way around it is to have a single, global SLP scope, which is the Novell-recommended way.  I'm thinking Novell recommends that because it would let all of the servers in the scope know where all the other servers in the scope are, through eDirectory.   There's a TID somewhere that I remember reading when I was doing this a year or 2 ago.  I think this might be it: http://support.novell.com/cgi-bin/search/searchtid.cgi?/10062474.htm

Do a KB search for "SLP design."  Maybe something more suited to your situation will catch your eye.

In monitor, server parameters, service location protocol, slp scope list.  You can put more than one scope there.

"In monitor, server parameters, service location protocol, slp scope list.  You can put more than one scope there."

.default.slpdefault.sacramento.acme

?

"but another possible way around it is to have a single, global SLP scope, which is the Novell-recommended way."

Finding info on it...

that TID looks good!

?

comma-delimited list.  

If your scope for sacramento is what you listed, assuming it's the same naming for Seattle's scope object, then the scope list would be:

.default.slpdefault.sacramento.acme,.default.slpdefault.seattle.acme

Mine is just the common name, but that doesn't mean the scopes can't be full context, I 'spose.

how do you have the common names in place?  If ALL the common names are the same (as configured by default by NetWare installation) then how could it tell one scope from another without the full context?

I actually created scopes and gave them their names...

ok - I am going to work on that - the global scope (once I figure how in the heck to do that) and then will post results once I have an answer.  If I vape on this question for a week or so, don't freak - just very busy.

NP.  

I've got lotsa stuff going now, too..  Testing OES beta on SLES9.  Fixing our private DNS (previous admin had multiple authoritative primary SOA's - 2 on NT4 and one on NetWare. Leaving NT DNS for zone on Exchange alone for now, but NT DNS for zone on NT4 PDC also is primary SOA for other zones in the corp so I can't just blow it away - the "gotcha" to straightening it out is that NT4 DNS won't take zone xfers from BIND 9.x servers.  Big srprise there, hey?), Worrying about the push to migrate to "ADS" (which isn't even installed yet - just more vaporware... "if we had ADS we could do x."), and how to "executive summarize" reasons not to....

Has your org experimented with OES on SLES yet?  I could use some insights... 'specially on Linux user mgmt support for non-NDS-aware stuff. (will post a separate Q of course.)

haven't touched OES yet - not too impressed with it - it's just NetWare 6.5SP3 and/or SLES 9.1

I'll wait until:

1)  it's out of beta
2)  it's in production for 3 months
3)  the first Support Pack is released

Then I'll consider it.

The thing about bleeding edge technology is finding out you are a hemopheliac

Wee..ee..elll... it's not "just" SLES 9.1, from what I've seen so far. "Just" SLES 9.1 doesn't host NSS volumes, or act as an NCP server, to name just a couple...

I don't care much about the enhancements to NW6.5, like the BASH shell, for instance, but the enhancements to Linux have definite promise, especially in an environment that uses Linux/Unix to run core business systems like ERP.

""Just" SLES 9.1 doesn't host NSS volumes, or act as an NCP server, to name just a couple... "


it does with Nterprise Linux Services

http://www.novell.com/linux/nterprise_linux_services.html

and look - you don't need SuSE SLES 9.x to run it...

http://www.novell.com/products/linuxservices/sysreqs.html

Sorry, dude, but NSS wasn't part of Nterprise Linux Services.  It's new with OES.  
Acting as an NCP server wasn't part of it either - you couldn't map drives from a Novell client to a Linux box with Nterprise Linux Services.  You can with OES.


The only "file services" Nterprise Linux Services provides is iFolder.

my bad.

BrainShare 2005 is budgeted.

It's supposed to be for me, too, but that is now in question, because they're buying a big punch-press, dammit!

here's what I did:

1)  I have a DA running on a server that holds the master replica's of all my partitions - don't freak, it's a backup server that doesn't do anything until the backups launch at night when everyone is gone - so basically it's running around doing nothing most of the time except eDir sync.

2) I modified the SLP.CFG on the backup server to reflect it's IP address:
    DA IPV4, 10.100.140.7

3)  Then I ran SLP RESET from Server Parameters > Service Location Protocol

4)  I have multiple DA's in my tree, every partition that contains a server, at least ONE of those servers has a DA

5)  For servers that have their own DA, I added their IP address to their SLP.CFG along with the IP address of the backup server:
    DA IPV4, 10.100.xxx.7
    DA IPV4, 10.100.140.7

So, no server has more than two DA entries in the SLP.CFG file

6)  Then I did the SLP RESET

7)  For servers that don't have a DA, I simply modified their SLP.CFG file and added the backup server IP address as in Step 2) above

8)  did the SLP RESET on that server

9)  I ended up rebooting the backup server to get the SCOPE modifications I made in Monitor to kick in (I think I don't need those now)

10)  ran a DSREPAIR > Advanced Options > Servers known to this database > Repair All Server's Address

In which all the 11001 errors disappeared except on ONE server - it's a NetWare 4.2 box running IPX and IP.  However, since it only does NCP over IPX, I am not too worried.

11)  Changed the TIMESYNC Time Sources from the IP address of my Primary Time Server to it's NCP name and did a TIMESYNC Restart Flag - TIMESYNC now resolves the name/service properly instead of the 11001 error I used to get.

So, I'm happy...

however, after doing a DISPLAY SLP SERVICES at the console, I may go back into the SLP.CFG files and set up some sort of service filtering...

but I am still happy!

Groovy.  Glad it's workin'.