Netware - Ubuntu/samba - slp-delay?
Matthias Kahlert
Ich habe ein Netz mit Netware 6.5, das an sich gut funktioniert,
Clients sind WinXP SP2 Client 4.9SP2.
Jetzt gibt es auch noch 2 kleine Server mit Ubuntu/Samba mit
untergeordneten Daten, auf die einfach mittels SMB zugegriffen werden soll.
Hier tritt jetzt das Problem auf: Clickt man auf ein Netzlaufwerk mit so
einer Freigabe, tritt eine Wartezeit von ca. 10 s auf, bis der Inhalt
erscheint. Danach geht es flott weiter. Nach einigen Minuten Inaktivit�t
tritt wieder das Delay auf.
Nun habe ich wireshark auf dem Linux-Server laufen lassen und da zeigt
sich, dass der Client w�hrend der Wartezeit einige "srvloc"-Pakete an
224.0.1.22:427 sendet, mit denen der Linux-server offenbar nichts
anfangen kann.
Auf einem Rechner ohne Netware-Client passiert das nicht.
Daher meine Fragen:
Kann man dem Client irgendwie abgew�hnen, diese slp-Pakete zu senden?
Kann man sonst irgendwie daf�r sorgen, dass sie zeitnah beantwortet
werden, so dass kein timeout abgewartet werden muss? Nachher
funktioniert die Verbindung ja einwandfrei.
Sonst irgendwelche Ideen?
--
Matthias
Thorsten Kampe
> Ich habe ein Netz mit Netware 6.5, das an sich gut funktioniert,
> Clients sind WinXP SP2 Client 4.9SP2.
> Jetzt gibt es auch noch 2 kleine Server mit Ubuntu/Samba mit
> untergeordneten Daten, auf die einfach mittels SMB zugegriffen werden soll.
>
> Hier tritt jetzt das Problem auf: Clickt man auf ein Netzlaufwerk mit so
> einer Freigabe, tritt eine Wartezeit von ca. 10 s auf, bis der Inhalt
> erscheint. Danach geht es flott weiter. Nach einigen Minuten Inaktivität
> tritt wieder das Delay auf.
>
> Nun habe ich wireshark auf dem Linux-Server laufen lassen und da zeigt
> sich, dass der Client während der Wartezeit einige "srvloc"-Pakete an
> 224.0.1.22:427 sendet, mit denen der Linux-server offenbar nichts
> anfangen kann.
>
> Auf einem Rechner ohne Netware-Client passiert das nicht.
>
> Daher meine Fragen:
>
> Kann man dem Client irgendwie abgewöhnen, diese slp-Pakete zu senden?
>
> Kann man sonst irgendwie dafür sorgen, dass sie zeitnah beantwortet
> werden, so dass kein timeout abgewartet werden muss? Nachher
> funktioniert die Verbindung ja einwandfrei.
>
> Sonst irgendwelche Ideen?
Aktuellen Client installieren, SLP installieren (Ubuntu), Firewall
richtig konfigurieren und http://forums.novell.com/showthread.php?t=
388062 lesen.
Thorsten
Massimo Rosen
Matthias Kahlert wrote:
> Nun habe ich wireshark auf dem Linux-Server laufen lassen und da zeigt
> sich, dass der Client w�hrend der Wartezeit einige "srvloc"-Pakete an
> 224.0.1.22:427 sendet, mit denen der Linux-server offenbar nichts
> anfangen kann.
Der Linux Server hat damit nicht wirklich was zu tun. Der Novell Client
versucht den Namen des Servers aufzul�sen, und da eure Namensaufl�sung
ungeschickt bzw. gar nicht konfiguriert ist, kann er ohne "rumbr�llen
und warten" nicht rausfinden ob das ein Novell Server ist oder nicht.
> Auf einem Rechner ohne Netware-Client passiert das nicht.
Logisch.
> Daher meine Fragen:
>
> Kann man dem Client irgendwie abgew�hnen, diese slp-Pakete zu senden?
Ja. In dem man Ihm einen richtigen SLPDA gibt. Dann h�rt er auch auf zu
schreien, und wei� innerhalb des Bruchteils einer Sekunde, dass der Name
nix mit ihm zu tun hat.
> Kann man sonst irgendwie daf�r sorgen, dass sie zeitnah beantwortet
> werden, so dass kein timeout abgewartet werden muss?
�h ja, mit einen SLPDA.
CU,
--
Massimo Rosen
Novell Product Support Forum Sysop
No emails please!
http://www.cfc-it.de
Matthias Kahlert
>> Kann man dem Client irgendwie abgew�hnen, diese slp-Pakete zu senden?
>
> Ja. In dem man Ihm einen richtigen SLPDA gibt. Dann h�rt er auch auf zu
> schreien, und wei� innerhalb des Bruchteils einer Sekunde, dass der Name
> nix mit ihm zu tun hat.
>
>> Kann man sonst irgendwie daf�r sorgen, dass sie zeitnah beantwortet
>> werden, so dass kein timeout abgewartet werden muss?
>
> �h ja, mit einen SLPDA.
So was hab ich vermutet. Da unsere slp-Konfiguration aber "out-of
the-box" ist, hab ich leider keine Ahnung, was ich da wo eintragen muss.
Gibts da irgendein Dokument, das mir da weiterhelfen k�nnte?
("Basics of SLP on Netware" oder so?)
Danke,
--
Matthias
Massimo Rosen
Matthias Kahlert wrote:
>
> So was hab ich vermutet. Da unsere slp-Konfiguration aber "out-of
> the-box" ist, hab ich leider keine Ahnung, was ich da wo eintragen muss.
> Gibts da irgendein Dokument, das mir da weiterhelfen k�nnte?
> ("Basics of SLP on Netware" oder so?)
Da bin ich sicher. ;)
Kurzform: auf dem Netware Server einmal "load slpda /a" ausf�hren. sldpa
in die Autoexec eintragen. Auf dem Client entweder statisch oder per
DHCP den SLPDA im Novell CLient eintragen.
Wenn es mehrere Novell Server gibt, auf allen Servern, *au�er* dem
SLPDA, den DA in der sys:\etc\slp.cfg eintragen.
Matthias Kahlert
> Hallo,
>
> Matthias Kahlert wrote:
>>
>> So was hab ich vermutet. Da unsere slp-Konfiguration aber "out-of
>> the-box" ist, hab ich leider keine Ahnung, was ich da wo eintragen muss.
>> Gibts da irgendein Dokument, das mir da weiterhelfen k�nnte?
>> ("Basics of SLP on Netware" oder so?)
>
> Da bin ich sicher. ;)
>
> Kurzform: auf dem Netware Server einmal "load slpda /a" ausf�hren. sldpa
> in die Autoexec eintragen. Auf dem Client entweder statisch oder per
> DHCP den SLPDA im Novell CLient eintragen.
Danke, "works like a charm"!
Ich wu�te, dass mir hier geholfen werden kann.... ;-)
--
Matthias
Christoph Maercker
Massimo Rosen wrote:
> Der Linux Server hat damit nicht wirklich was zu tun. Der Novell Client
> versucht den Namen des Servers aufzul�sen, und da eure Namensaufl�sung
> ungeschickt bzw. gar nicht konfiguriert ist, kann er ohne "rumbr�llen
> und warten" nicht rausfinden ob das ein Novell Server ist oder nicht.
...
> In dem man Ihm einen richtigen SLPDA gibt. Dann h�rt er auch auf zu
> schreien, und wei� innerhalb des Bruchteils einer Sekunde, dass der
> Name nix mit ihm zu tun hat.
Hm, ich habe hier zwei DAs laufen, die werden von den Clients lt.
slpinfo auch erkannt und stehen beide in den Configs derselbigen.
Trotzdem sehe ich, dass die Clients wiederholt SLP-Anfragen per
Multicast verschicken. Gibt es bekannte Gr�nde daf�r?
--
CU Christoph Maercker.
Christoph Maercker
> Kurzform: auf dem Netware Server einmal "load slpda /a" ausf�hren. sldpa
> in die Autoexec eintragen. Auf dem Client entweder statisch oder per
> DHCP den SLPDA im Novell CLient eintragen.
Muss der DA nicht mehr vorher in die NDS eingetragen werden? WIMRE war
das mind. bei NW5 noch so.
> Wenn es mehrere Novell Server gibt, auf allen Servern, *au�er* dem
> SLPDA, den DA in der sys:\etc\slp.cfg eintragen.
Erg�nzend zu meiner Anfrage wegen Multicasts: Habe ich so in die slp.cfg
eingetragen.
--
CU Christoph Maercker.
Massimo Rosen
Christoph Maercker wrote:
>
> Muss der DA nicht mehr vorher in die NDS eingetragen werden? WIMRE war
> das mind. bei NW5 noch so.
Nein und nein. Das ist genau das was SLPDA /a macht.
Massimo Rosen
Christoph Maercker wrote:
>
> Hallo,
>
> Massimo Rosen wrote:
> > Der Linux Server hat damit nicht wirklich was zu tun. Der Novell Client
> > versucht den Namen des Servers aufzulīŋŊsen, und da eure NamensauflīŋŊsung
> > ungeschickt bzw. gar nicht konfiguriert ist, kann er ohne "rumbrīŋŊllen
> > und warten" nicht rausfinden ob das ein Novell Server ist oder nicht.
> ...
> > In dem man Ihm einen richtigen SLPDA gibt. Dann hīŋŊrt er auch auf zu
> > schreien, und weiīŋŊ innerhalb des Bruchteils einer Sekunde, dass der
> > Name nix mit ihm zu tun hat.
>
> Hm, ich habe hier zwei DAs laufen, die werden von den Clients lt.
> slpinfo auch erkannt und stehen beide in den Configs derselbigen.
> Trotzdem sehe ich, dass die Clients wiederholt SLP-Anfragen per
> Multicast verschicken. Gibt es bekannte GrīŋŊnde dafīŋŊr?
Ja, das ist WAD (works as designed). Deswegen gehīŋŊrt der DA in den
Client fest eingetragen (dazu gehīŋŊrt auch DHCP), und nicht per Multicast
gefunden. Wen nder DA nur per Multicast gefunden wird, macht der client
auch sonst weiter multicast, wenn der DA den gesuchten service nciht
kennt. Wenn der DA fest eingetragen wird, dann gibt der client nachdem
der DA "kenn ich nicht" gesagt hat, auf. Das macht auch absolut Sinn so.
Christoph Maercker
Massimo Rosen wrote:
> Ja, das ist WAD (works as designed). Deswegen geh�rt der DA in den
> Client fest eingetragen (dazu geh�rt auch DHCP),
Ist er bzw. sind sie (wir haben zwei). Seit Jahren. Bei allen Clients.
> und nicht per Multicast
> gefunden. Wen nder DA nur per Multicast gefunden wird, macht der client
> auch sonst weiter multicast, wenn der DA den gesuchten service nciht
> kennt. Wenn der DA fest eingetragen wird, dann gibt der client nachdem
> der DA "kenn ich nicht" gesagt hat, auf. Das macht auch absolut Sinn so.
"Kenn ich nicht" passiert nat�rlich ganz schnell, wenn die NDS nach
Namen gefragt wird, die im Windows-Netzwerk nicht gefunden wurden. Der
Filterdriver des Clients sollte so was zwar verhindern, aber vermutlich
nicht in jedem Fall. Bleibt er f�r alle Zeiten bei Multicast, wenn auch
nur ein Name nicht gefunden wird? Das f�nde ich so sinnvoll wiederum nicht.
--
CU Christoph Maercker.
Massimo Rosen
Christoph Maercker wrote:
>
> Hallo,
>
> Massimo Rosen wrote:
> > Ja, das ist WAD (works as designed). Deswegen geh�rt der DA in den
> > Client fest eingetragen (dazu geh�rt auch DHCP),
>
> Ist er bzw. sind sie (wir haben zwei). Seit Jahren. Bei allen Clients.
Dan ist der Novell Client falsch (und nicht-standard) konfiguriert. Oder
irgendwas anderes macht SLP, was unwahrscheinlich ist. Wenn der Novell
CLient einen funktionierenden DA *fest* eingetragen hat, sollte er kein
Multicast mehr machen. Eine M�glichkeit w�re, das der DA tempor�r nicht
antwortet, also der CLient in auf "No Response" setzt. *Dann* macht der
CLient auch wieder Multicast.
> "Kenn ich nicht" passiert nat�rlich ganz schnell, wenn die NDS nach
> Namen gefragt wird,
Slp wird nach Diensten gefragt, nicht die NDS nach Namen. NUr mal so.
> die im Windows-Netzwerk nicht gefunden wurden. Der
> Filterdriver des Clients sollte so was zwar verhindern,
�h, nein. Der Filterdriver macht das Gegenteil. Der Verhindert, dass
Novell Dienste bzw Namen, vom Microsoft Client augel�st werden, bzw
versucht werden.
> Bleibt er f�r alle Zeiten bei Multicast, wenn auch
> nur ein Name nicht gefunden wird?
Nein, und wenn ein Name nicht gefunden wird, macht er keinen Multicast.
Du hast mich v�llig falsch verstanden. Er macht nur Multicast, wenn kein
DA gefunden wird.
Christoph Maercker
Massimo Rosen wrote:
> Dan ist der Novell Client falsch (und nicht-standard) konfiguriert. Oder
> irgendwas anderes macht SLP, was unwahrscheinlich ist. Wenn der Novell
> CLient einen funktionierenden DA *fest* eingetragen hat, sollte er kein
> Multicast mehr machen. Eine M�glichkeit w�re, das der DA tempor�r nicht
> antwortet, also der CLient in auf "No Response" setzt. *Dann* macht der
> CLient auch wieder Multicast.
Vermutlich Letzteres.
>> "Kenn ich nicht" passiert nat�rlich ganz schnell, wenn die NDS nach
>> Namen gefragt wird,
>
> Slp wird nach Diensten gefragt, nicht die NDS nach Namen. NUr mal so.
Was M$ nicht daran hindert, umgekehrt einen DNS nach Diensten zu fragen,
Stichwort Service-Records. Sowas schwirrt in Netzen mit ADS haufenweise
rum. Wonach die Clients konkret per SLP fragen, dazu muss ich direkt
nochmal meine Packet-Traces durchsehen.
> �h, nein. Der Filterdriver macht das Gegenteil. Der Verhindert, dass
> Novell Dienste bzw Namen, vom Microsoft Client augel�st werden, bzw
> versucht werden.
Er filtert also nur eine Richtung. Damit ist es sehr leicht m�glich,
dass M$-Services per SLP versucht werden, wenn vom DNS sie nicht
aufl�sen kann. Wie abenteuerlich diese Namen aussehen, brauche ich Dir
sicher nicht erz�hlen.
> Nein, und wenn ein Name nicht gefunden wird, macht er keinen Multicast.
> Du hast mich v�llig falsch verstanden. Er macht nur Multicast, wenn kein
> DA gefunden wird.
Ach so, ich dachte es wird Multicast versucht, wenn der DA zu oft
Negativantworten sendet. Derlei Verhalten ist von Windoof ja bekannt.
WINS wird z.B. trotz Nodetype=2 (Peer-Peer-Knoten) per Broadcast
versucht, wenn von den WINS-Servern wiederholt nix bzw. nicht die
erwarteten Antworten kommen.
Warum der DA auf beiden Servern nicht erreichbar sein soll, obwohl NCP
mit ihnen problemlos funktioniert, bliebe noch zu kl�ren. Sieht mir
nicht wie elementares Netzwerkproblem aus, eher wie zu kurze Timeouts
bei SLP.
--
CU Christoph Maercker.
Massimo Rosen
Christoph Maercker wrote:
>
> Hallo,
>
> Massimo Rosen wrote:
> > Dan ist der Novell Client falsch (und nicht-standard) konfiguriert. Oder
> > irgendwas anderes macht SLP, was unwahrscheinlich ist. Wenn der Novell
> > CLient einen funktionierenden DA *fest* eingetragen hat, sollte er kein
> > Multicast mehr machen. Eine M�glichkeit w�re, das der DA tempor�r nicht
> > antwortet, also der CLient in auf "No Response" setzt. *Dann* macht der
> > CLient auch wieder Multicast.
>
> Vermutlich Letzteres.
M�sste man pr�fen.
> >> "Kenn ich nicht" passiert nat�rlich ganz schnell, wenn die NDS nach
> >> Namen gefragt wird,
> >
> > Slp wird nach Diensten gefragt, nicht die NDS nach Namen. NUr mal so.
>
> Was M$ nicht daran hindert, umgekehrt einen DNS nach Diensten zu fragen,
> Stichwort Service-Records. Sowas schwirrt in Netzen mit ADS haufenweise
> rum. Wonach die Clients konkret per SLP fragen, dazu muss ich direkt
> nochmal meine Packet-Traces durchsehen.
Ja, aber ich hab' nicht von Microsoft gesprochen. ;)
> > �h, nein. Der Filterdriver macht das Gegenteil. Der Verhindert, dass
> > Novell Dienste bzw Namen, vom Microsoft Client augel�st werden, bzw
> > versucht werden.
>
> Er filtert also nur eine Richtung.
Yep.
> Damit ist es sehr leicht m�glich,
> dass M$-Services per SLP versucht werden, wenn vom DNS sie nicht
> aufl�sen kann.
Bedingt, aber ja. Nur bei Servernamen, also UNC. Wenn irgendwas versucht
\\servergibtsnicht\volume\verz\datei.txt sucht, dann versuchen je nach
Reihenfolge alle lokalen clients, einen Server namens "servergibtsnicht"
zu finden. Und *dann* kommt es daruf an, wie lange es dauert, dass die
clients endlich meinen das es "servergibtsnicht" *wirklich* nicht gibt.
Das h�ngt von vielen Faktoren ab, unter anderem welche der dutzenden
Methoden einen Namen zu finden alle versucht werden, und wie die
einzelnen Timeouts sind.
> > Nein, und wenn ein Name nicht gefunden wird, macht er keinen Multicast.
> > Du hast mich v�llig falsch verstanden. Er macht nur Multicast, wenn kein
> > DA gefunden wird.
>
> Ach so, ich dachte es wird Multicast versucht, wenn der DA zu oft
> Negativantworten sendet.
Nein. Solnage der DA �berhaupt antwortet, wird kein Multicast gemacht.
Wenn der DA "nein" sagt, ist das endg�ltig, und gut. Wenn der DA gar nix
sagt, *dann* wird per Multicast geschrieen, *und* der Timeout
abgewartet. Da f�ngt das an wehzutun.
Christoph Maercker
> M�sste man pr�fen.
Gut, dass Du dran erinnerst. ;-)
Einer der beiden DAs war tats�chlich down, seit wann und warum ist aus
dem Syslog nicht ersichtlich. War aber der, den die Clients nur als
Secondary eingetragen haben. SLPInfo meldet ihn jetzt wieder als "UP".
Womit l�sst sich die Funktion der DAs einklich pr�fen, au�er mit
SLPInfo? Die Multicasts habe ich eher zuf�llig in Packet-Traces
entdeckt. Dort finden sich gelegentlich auch sinnvolle Anfragen an die
DAs und die werden stets sinnvoll beantwortet. Ob und wer auf die
Multicasts antworten, sehe ich mir gelegentlich mal an.
>> Damit ist es sehr leicht m�glich,
>> dass M$-Services per SLP versucht werden, wenn vom DNS sie nicht
>> aufl�sen kann.
> Bedingt, aber ja. Nur bei Servernamen, also UNC. Wenn irgendwas versucht
> \\servergibtsnicht\volume\verz\datei.txt sucht, dann versuchen je nach
> Reihenfolge alle lokalen clients, einen Server namens "servergibtsnicht"
> zu finden. Und *dann* kommt es daruf an, wie lange es dauert, dass die
> clients endlich meinen das es "servergibtsnicht" *wirklich* nicht gibt.
> Das h�ngt von vielen Faktoren ab, unter anderem welche der dutzenden
> Methoden einen Namen zu finden alle versucht werden, und wie die
> einzelnen Timeouts sind.
Also nicht bei solchen grausigen Anfragen wie z.B.
_ldap._tcp.dc._msdcs.<servername>, oder?
Das sind diese Servicerecords von M$, die ich meine, also Dienste, die
eigentlich per SLP geregelt geh�ren und nicht per DNS.
> Nein. Solnage der DA �berhaupt antwortet, wird kein Multicast gemacht.
> Wenn der DA "nein" sagt, ist das endg�ltig, und gut. Wenn der DA gar nix
> sagt, *dann* wird per Multicast geschrieen, *und* der Timeout
> abgewartet. Da f�ngt das an wehzutun.
Seit ca. einer Woche lahmte mein PC wirklich im Netzwerk. Mal sehen, ob
das aufh�rt, nachdem der zweite DA wieder l�uft. Das w�rde aber
bedeuten, die Traces wurden lange vor dem Ausfall des 2. DAs erstellt
und die Multicasts h�tten damit nichts zu tun.
--
CU Christoph Maercker.
Christoph Maercker
> M�sste man pr�fen.
Momentan zeigt slpinfo beide DAs als "UP", trotzdem
Operational State: UP
Operating Mode(s): MCAST
SA/UA Scopes: <unscoped>
Scopes habe ich keine eingerichtet, die werden ja wohl nur f�r gr��ere
Netzwerke n�tig.
In alten Packettraces habe ich auf die Schnelle leider nichts gefunden.
--
CU Christoph Maercker.
Rudolf Thilo
>Momentan zeigt slpinfo beide DAs als "UP", trotzdem
>Scopes habe ich keine eingerichtet, die werden ja wohl nur f�r gr��ere Netzwerke
>n�tig.
Schaden allerdings auch f�r kleinere Netze nicht :)
Die erforderlichen Settings lassen sich mit Abstand am einfachsten �ber DHCP
verteilen (options 78 und 79) bzw. �ber Monitor.nlm (Server, Service Location...,
dort insbes. der Scope Name) und sys:/etc/slp.cfg
Damit ist alles h�bsch zentral gemanaged...
Sch�nen Gru�, Rudi.
Massimo Rosen
Christoph Maercker wrote:
>
> Massimo Rosen wrote:
> > M�sste man pr�fen.
>
> Momentan zeigt slpinfo beide DAs als "UP", trotzdem
> Operational State: UP
> Operating Mode(s): MCAST
> SA/UA Scopes: <unscoped>
Au.
> Scopes habe ich keine eingerichtet, die werden ja wohl nur f�r gr��ere
> Netzwerke n�tig.
Quark. "Unscoped" gibt's eigentlich gar nicht mehr. Das ist SLPV1, was
man wirklich nicht mehr benutzen sollte.
Richtig ist, dass man in normalen netzen nicht mehr als den ebenso
genannten "default" scope braucht.
Den Operating Mode muss ich mir gleich mal ansehen, ich glaube aber,
dass der anzeigt wie der DA gefunden wurde.
Massimo Rosen
Christoph Maercker wrote:
>
> Massimo Rosen wrote:
> > M�sste man pr�fen.
>
> Momentan zeigt slpinfo beide DAs als "UP", trotzdem
> Operational State: UP
> Operating Mode(s): MCAST
> SA/UA Scopes: <unscoped>
Ich seh' gerade, dass das genau das ist, was slpinfo ausgibt, wenn der
client gar keinen DA hat.
Was sagt denn slpinfo /d?
Mirko Guldner
> Hm, ich habe hier zwei DAs laufen, die werden von den Clients lt.
> slpinfo auch erkannt und stehen beide in den Configs derselbigen.
> Trotzdem sehe ich, dass die Clients wiederholt SLP-Anfragen per
> Multicast verschicken. Gibt es bekannte Gr�nde daf�r?
Ist es eigentlich irgendwie problematisch, zwei DAs am laufen zu haben?
Ich meine, bei Novell mal irgendwo gelesen zu haben, dass man das nicht
empfiehlt. Aber unser einer DA ist ein echter single point of failure...
zum Gl�ck nur selten relevant, deshalb habe ich das Thema immer wieder
rausgeschoben.
Gru�,
Mirko
Massimo Rosen
Mirko Guldner wrote:
>
> Ist es eigentlich irgendwie problematisch, zwei DAs am laufen zu haben?
Nicht wenn man es richtig konfiguriert.
> Ich meine, bei Novell mal irgendwo gelesen zu haben, dass man das nicht
> empfiehlt.
Eher weil die Erfahrung zeigt, dass die meisten Anwender nicht wissen
was sie tun, und ohne SLP zu verstehen, einfach irgendwo zwei DAs
starten, am besten noch mit unterschiedlichen, aber gleichnamigen
scopes, und sich hinterher �ber das verursachte Chaos wundern.
Rudolf Thilo
>Momentan zeigt slpinfo beide DAs als "UP", trotzdem
>Operational State: UP
>Operating Mode(s): MCAST
>SA/UA Scopes: <unscoped>
Auf Win Kisten ist das Tool slpsnoop.exe eine sehr praktische Hilfe.
Google: Coolsolutions, slpsnoop.exe
Christoph Maercker
> Quark. "Unscoped" gibt's eigentlich gar nicht mehr. Das ist SLPV1, was
> man wirklich nicht mehr benutzen sollte.
Habe ich bei NW5.0 diese Wahl? Vermutlich nicht, jedenfalls habe ich
noch nirgends entsprechende Optionen gesehen.
--
CU Christoph Maercker.
Christoph Maercker
> Ich seh' gerade, dass das genau das ist, was slpinfo ausgibt, wenn der
> client gar keinen DA hat.
> Was sagt denn slpinfo /d?
SLP Version: 1.0
SLP Start Time: 10:42:21am 11/2/2009
Last I/O: 4:14:22pm 11/2/2009
Total Packets: Out: 712 In: 93
Total Bytes: Out: 39142 In: 8222
DA IP Address Source(s) State Local Interface Scope(s)
--------------- --------- ----- --------------- ----------
<DA1> CNFG UP 149.203.17.70 <unscoped>
<DA2> CNFG NORSP 149.203.17.70 <unknown>
DA2 habe ich eben erst wieder eingeschaltet, der Server wurde heute neu
gestartet. Normalerweise meldet slpinfo beide DAs als "UP".
Die Scopes namens "Unscoped" werden automatisch eingerichtet, jeweils in
dem Context, wo ein DA konfiguriert und gestartet wurde. Habe ich nicht
angefasst, getreu dem Motto "Novell wird schon wissen, was er da tut".
SLP wird ingesamt ziemlich stiefm�tterlich behandelt, angefangen von der
mageren Dokumentation bis hin zu seiner Verwendung. Da M$ es zum Finden
von Diensten nicht nutzt, sondern das sinnfreierweise mittels DNS macht,
wundert mich das nicht.
--
CU Christoph Maercker.
Christoph Maercker
> Google: Coolsolutions, slpsnoop.exe
Hab ich vor ein paar Jahren entdeckt, nicht �bel. Es zeigt hier:
Scopes \ Unscoped, darunter finden sich alle 5 Dienste, die auch
DISPLAY SLP SERVICES auf einer Server-Console auflistet.
--
CU Christoph Maercker.
Massimo Rosen
Christoph Maercker wrote:
>
> Massimo Rosen wrote:
> > Ich seh' gerade, dass das genau das ist, was slpinfo ausgibt, wenn der
> > client gar keinen DA hat.
>
> > Was sagt denn slpinfo /d?
>
> SLP Version: 1.0
> SLP Start Time: 10:42:21am 11/2/2009
> Last I/O: 4:14:22pm 11/2/2009
> Total Packets: Out: 712 In: 93
> Total Bytes: Out: 39142 In: 8222
>
> DA IP Address Source(s) State Local Interface Scope(s)
> --------------- --------- ----- --------------- ----------
> <DA1> CNFG UP 149.203.17.70 <unscoped>
> <DA2> CNFG NORSP 149.203.17.70 <unknown>
>
> DA2 habe ich eben erst wieder eingeschaltet, der Server wurde heute neu
> gestartet. Normalerweise meldet slpinfo beide DAs als "UP".
>
> Die Scopes namens "Unscoped" werden automatisch eingerichtet, jeweils in
> dem Context, wo ein DA konfiguriert und gestartet wurde.
AU! Du hast zwei *getrennte* Scopes mit eigenem DA mit dem gleichen
"Namen"? AU! AU! AU!
> Habe ich nicht
> angefasst, getreu dem Motto "Novell wird schon wissen, was er da tut".
Nein, das hat Novell so ganz sicher nie vorgesehen, und SLP richtet sich
auch nicht von alleine ein.
> SLP wird ingesamt ziemlich stiefm�tterlich behandelt,
Das merk' ich wohl. Aber nicht bei Novell, sondern bei euch.
> angefangen von der
> mageren Dokumentation bis hin zu seiner Verwendung.
H�?
> Da M$ es zum Finden
> von Diensten nicht nutzt, sondern das sinnfreierweise mittels DNS macht,
Was eine extreme Qu�lerei sondergleichen ist.
> wundert mich das nicht.
Ich sehe den Zusammenhang nicht. Wen interessiert was Microsoft oder
sonstwer macht?
Christoph Maercker
> AU! Du hast zwei *getrennte* Scopes mit eigenem DA mit dem gleichen
> "Namen"? AU! AU! AU!
> auch nicht von alleine ein.
Dann bleibt die Frage, woher insgesamt drei Container mit dem
"Unscoped"-Inhalt kommen, wohl ungekl�rt. Sie stehen im NDS-Tree in
genau den Contexten, wo ich DAs eingerichtet habe und ich habe sie
definitiv nicht h�ndisch eingetragen. Das Einzige, was ich gemacht habe,
ist, die SLPDA.NLM auf den jeweiligen Servern zu laden. Allenfalls
SYS:ETC/SLP.CFG habe ich nachtr�glich konfiguriert und dort jeweils die
IPs von DAs eingetragen, die NICHT auf dem jeweiligen Server laufen. Was
mache ich also mit diesen "Unscoped" unbekannter Herkunft? (Mind.?) Zwei
davon l�schen? Das dritte Objekt (welches?) umbenennen in "default"?
> Das merk' ich wohl. Aber nicht bei Novell, sondern bei euch.
ACK, Novell ist einer der wenigen, die SLP nutzen. Ansonsten beobachte
ich aktives SLP nur bei einigen Druckern, ab und zu eine Linux-Kiste
oder ein Mac, wohl wegen des BSD-Unix.
>> angefangen von der
>> mageren Dokumentation bis hin zu seiner Verwendung.
> H�?
Hab noch nie eine Netzwerker-Veranstaltung erlebt, auf der SLP auch nur
genannt wurde. Da war immer nur von DNS, DCHP und sonstwas f�r
Protokollen die Rede.
> Ich sehe den Zusammenhang nicht. Wen interessiert was Microsoft oder
> sonstwer macht?
Es scheint verdammt viele zu interessieren, sonst g�be es mehr Leute,
die mit SLP Bescheid w�ssten. In meinem Umfeld kennt sich keiner damit aus.
--
CU Christoph Maercker.
Massimo Rosen
Christoph Maercker wrote:
>
> Massimo Rosen wrote:
> > AU! Du hast zwei *getrennte* Scopes mit eigenem DA mit dem gleichen
> > "Namen"? AU! AU! AU!
> > Nein, das hat Novell so ganz sicher nie vorgesehen, und SLP richtet sich
> > auch nicht von alleine ein.
>
> Dann bleibt die Frage, woher insgesamt drei Container mit dem
> "Unscoped"-Inhalt kommen, wohl ungekl�rt.
Weil jemand dreimal auf drei verschiedenen Servern einen DA in seiner
default configuration gestartet hat, und geglaubt hat das w�rs jetzt.
> Das Einzige, was ich gemacht habe,
> ist, die SLPDA.NLM auf den jeweiligen Servern zu laden.
Ja, eben. Wenn Du einfach einen DNS Server irgendwo startest, meinst Du
dann auch der w�re vern�nftig konfiguriert?
> Allenfalls
> SYS:ETC/SLP.CFG habe ich nachtr�glich konfiguriert und dort jeweils die
> IPs von DAs eingetragen, die NICHT auf dem jeweiligen Server laufen. Was
> mache ich also mit diesen "Unscoped" unbekannter Herkunft? (Mind.?) Zwei
> davon l�schen? Das dritte Objekt (welches?) umbenennen in "default"?
Du musst dich entscheiden welche Konfiguration Du haben willst, und die
so einrichten. Wenn Du nur einen SCOPE, aber mehrere DAs m�chtest, dann
musst Du die beiden DAs auch f�r den *selben* Scope konfigurieren. Wie
das geht steht in der Doku. ;)
> ACK, Novell ist einer der wenigen, die SLP nutzen.
Och n�. Linux and Apple auch.
> Ansonsten beobachte
> ich aktives SLP nur bei einigen Druckern, ab und zu eine Linux-Kiste
> oder ein Mac, wohl wegen des BSD-Unix.
Aha. Also alle ausser Microsoft. Macht "einer der wenigen". ;)
>
> Hab noch nie eine Netzwerker-Veranstaltung erlebt, auf der SLP auch nur
> genannt wurde. Da war immer nur von DNS, DCHP und sonstwas f�r
> Protokollen die Rede.
Ja und?
> Es scheint verdammt viele zu interessieren, sonst g�be es mehr Leute,
> die mit SLP Bescheid w�ssten. In meinem Umfeld kennt sich keiner damit aus.
Und wieviele kennen sich damit aus, wie Microsoft genau DNS verwendet,
bzw. vergewaltigt? Ich wette auch keiner.
Rudolf Thilo
Ja, die Doku zu SLP(DA) von Novell k�nnte �bersichtlicher und anschaulicher sein.
mit C1 kann man, wenn ich das richtig sehe, nur die korrekten Icons bewundern.
F�r iManager gibt's einige TIDs, wie man die SLP Admin Punkte reinfrickelt, z.B.
http://tinyurl.com/imgr-slp
im Remote Manager kann man AFAIK auch blo� gucken.
Auch wenn Massimo da sicher die Nase r�mpft, da der NWAdmin obsolet ist:
Nach wie vor nehme ich *den* f�r SLP Pflege...
Du k�nntest folgendes machen:
1.) Alles neu macht der November:
- an allen deinen DAs SLPDA.NLM entladen
- Alle SLP Objekte, die Du findest, platt machen.
- neue Scope Unit anlegen in einem Container,
z.B. ou=slp.o=firma
Scope Unit Name="MyScopeUnit"
Scope Name = Campus1
- Neuen SLPDA anlegen:
Name=FSalpha-DA
- Details des DAs:
Scope eintragen
Host Server eintragen
2 DAs sollten gen�gen.
Dann auf *ALLEN* Servern:
2.) Eintragungen auf den Servern:
- Server Console: Monitor.NLM laden
> Server
> Service Location ...
- SLP Scope List: CAMPUS1
- SLP include IP address: falls der Server mehr als 1 IP hat.
(letzteres evtl. nur auf DAs n�tig, schadet IMHO aber nicht)
- SLP DA Discovery Options: 4 (statisch, nur sys:etc\slp.cfg)
Anmerkung:
Der Eintrag in "Scope List" ist mir schon einige male nach ABENDs fl�ten gegangen,
auf verschiedenen Servern: z.B. statt nur hier (Server Registry) zus�tzlich in die
Autoexec.ncf eintragen.
Editieren der Datei: sys:\etc\slp.cfg
Wenn DA1 = 10.10.10.1
und DA2 = 10.10.10.2
dann auf allen Servern eintragen:
DA IPV4, 10.10.10.1
DA IPV4, 10.10.10.2
Wichtig: Auf den DAs selbst die *EIGENE* IP *NICHT* eintragen, sondern nur den / die
IP Adressen der *ANDEREN* SLPDA Server.
3.) Eintragungen f�r die Clients:
Client seite: Am einfachsten per DHCP.
Option 78: dort die beiden IPs der DAs eintragen: 10.10.10.1 + 10.10.10.2
Obligatorisch
Option 79: dort den Scope Namen eintragen : Campus1
Obligatorisch
DHCPSRVR.NLM neu laden.
(Alternativ an den Clients selbst. DHCP ist IMHO wesetnlich etspannter.)
3.) alle SLPDA Server:
- SLPDA laden.
- Console: set slp reset = on
4.) �brige Server:
- Console: set slp reset = on
5.) auf allen Servern:
- display slpda
- display slp services
6.) auf den Clients:
- DHCP release / renew (evtl. auch reboot n�tig, bitte selbst testen)
- slpsnoop.exe + slpinfo
Damit bin ich bisher ganz passabel gefahren. Ob das wirklich "best practice" ist:
Massimo wird's ggf. richtig stellen ;)
Und abschliessend nochmal: Das ist so weder in der Doku noch in den TIDs beschieben,
die ich zu SLP bisher gefunden hatte. Ich stimme Dir voll zu, dass dieser absolute
Dreh- und Angelpunkt f�r OES Netze recht stiefm�tterlich dokumentiert ist.
So, mein blauer "Wartebalken" hier ist durch, ab nach Hause.
Sch�nen Gru�, Rudi.
SLP SLPDA Scope Directory Agent
NWClient
setup einrichten konfigurieren
scoped unscoped default
NetWare 6.5 NW6.5 NW6.5.8 NW658
OES OES2 OES2SP2