Avahi für Windows Server?
Hermann Schaefer
Server? Da 10.5 M$-Server nu prinzipiell nur noch als smb-Server anbietet und
auch das mounten per afp meist scheitert (nur per mount_afp mit 10.5.0 und
10.5.2, ziemlich nervig), möchte ich zumindest verhindern, daß User sich ständig
per smb statt afp anmelden. Da Win2k3s aber sich nicht per Bonjour melden, ist
das ziemlich aussichtslos, User sind da ja bekanntlich merkbefreit. Lösung wäre
ein ZeroConf-Server für Windows, den man den afp-Dienst anbieten läßt (auch wenn
die Anmeldung dann scheitert, Hauptsache die User gehen nicht ständig per smb
drauf und rufen dann wegen Schriftproblemen an.. *seufz*). Für Linuxe hat sich
ja Avahi etabliert, für Windows finde ich nur den Apple-Client und diverse
Projekte wie eine Mono-API - aber nichts fertiges. Hat da jemand schon mal was
gesehen und getestet?
Eigentlich müßte man doch iTunes mißbrauchen können, denn iTunes propagiert sich
ja - hab nur noch nicht rausgefunden wie. So richtig sinnvolle Ansätze in der
Registry finde ich nicht...
Und @Thomas: Ja, es gibt noch Leute, die kein Helios oder netatalk haben
(können/dürfen/wollen).. ;P
Thomas Kaiser
> Kennt jemand ein Avahi (Bonjour-Client und Server für Linuxe) für
> Windows Server?
Tut's Bonjour für Windows denn nicht? Keine Chance, da statische mDNS-
Einträge damit publizieren zu lassen? Und wenn nicht unter Windows, es
reicht doch, wenn $irgendwas im LAN die mDNS-Einträge publiziert, oder?
> Da 10.5 M$-Server nu prinzipiell nur noch als smb-Server anbietet und
> auch das mounten per afp meist scheitert (nur per mount_afp mit 10.5.0
> und 10.5.2, ziemlich nervig),
Verstehe ich nicht (was das mit "M$-Server" per se zu tun haben soll --
es gibt schließlich neben Microsofts eigenen Services for Macintosh auch
noch MacServerIP und ExtremeZ-IP).
Hier (Client 10.5.2, Server Win2003, Microsoftsche SFM als AFP-Server)
klappt das prima. Mounten per [apfel]-[k] und nur Angabe der IP-Adresse
klappt wunderbar per AFP (inkl. verschlüsselten Logon Credentials Dank
"NTLM v2" [1]). Ein forsches "df" meint jedenfalls anschließend:
afp_422m141Kz9mM4s9xjo0N5tvF-1.2d000006 [...] /Volumes/Microsoft UAM Volume
> möchte ich zumindest verhindern, daß User sich ständig per smb statt
> afp anmelden.
Schmeiß die Macs halt alle in einen gewissen IP-Address-Range und blocke
den Zugriff per SMB/CIFS (sollte man IMO *immer* machen, denn das
Mischen von SMB und AFP-Zugriffen innerhalb derselben Shares führt nur
zu (Meta-)Datenverlusten bzw. wie bei Dir zu ernsthaften Irritationen,
wenn Dateiformate im Spiel sind, die alles Relevante in der Resource-
fork herumschleppen.
<http://support.microsoft.com/?scid=kb%3Ben-us%3B813878&x=14&y=11>
> Da Win2k3s aber sich nicht per Bonjour melden, ist das
> ziemlich aussichtslos, User sind da ja bekanntlich merkbefreit.
Ich hab mal aus der Not heraus einem UB+ unter Windows (Helios Base, also
den ganzen Grundlagen-Schraddel einer produktiven Helios-Installation,
kann man seit paar Jahren auch unter Windows einsetzen -- seit UB+ und
dem Toolserver [2] auch aus gutem Grund "einfach so" -- nur braucht's
dafür wohl eine gültige Lizenz) per telnet statische mDNS-Einträge
untergeschoben, die das dann auch brav im LAN publiziert hat. Ist aber
wohl ein wenig Overkill bei Dir?
<http://www.helios.de/support/manuals/BASEUBplus-e/base-html/Output/Kap14a.html>
> Und @Thomas: Ja, es gibt noch Leute, die kein Helios oder netatalk haben
> (können/dürfen/wollen).. ;P
Ach, ExtremeZ-IP ist ehrlich gesagt gar nicht so schlecht. Nur das OS
drunter ist halt ein bisserl ungewohnt (bzw. die "Philosophie" hinter
dies & das auf Windows). BTW: Bonjour ist mit ExtremeZ-IP natürlich auch
kein Thema, insofern weiß ich nicht wirklich, was Du eigentlich hast? *g*
Gruss,
Thomas, leicht irritiert, daß Du anscheinend die SFM im produktiven
Einsatz hast...
[1] Aus /var/log/system.log:
DNSAddressResolver::DNSAddressResolver - _CFNetServiceCreateFromURL failed (maybe its a DNS name?)
DNSAddressResolver: Dotted Decimal IPv4 address 192.168.83.26
GetStatus: afp_socket worked
GetStatus: Connecting to IPv4 port 548, on c0a8531a
GetStatus worked: afpResult 0x0
TUAMHandler::TUAMHandler (1) TUAMHandler = 86ee00 fCurrentHandler = 86ee00 flags = 0
Creating a SharedVolumeEnumerator with TUAMHandler
TUAMHandler::Initalize flags are 0 username is 13:Administrator
TUAMHandler Username is 13:Administrator
TUAMHandler::BuildUAMList noPrefs = 0 low level only = 1
GetPascalCFString: Using the default string
BuildUAMList: Cleartext is not enabled
GetPascalCFString: Using the default string
GetUAMsInDir: cannot find /Library/Filesystems/AppleShare
Looking at ^MClient Krb v2
Looking at ^DDHX2
Looking at DHCAST128
Looking at ^V2-Way Randnum exchange
Looking at ^EMS3.0
Adding ^EMS3.0
Looking at ^EMS2.0
Adding ^EMS2.0
Looking at ^ONo User Authent
^EMS3.0
^EMS2.0
TUAMHandler::ChooseBestUAM
Choosing ^EMS3.0
SharedVolumeEnumerator::Count
SharedVolumeEnumerator::FetchVolumeList Fetching the volume list fSessionRef = 0
SharedVolumeEnumerator::FetchVolumeList checking to see if we can upgrade
SharedVolumeEnumerator::FetchVolumeList automounted is false
SharedVolumeEnumerator::FetchVolumeList uam type is 12
SharedVolumeEnumerator::FetchVolumeList server supports Kerberos is false
KerberosTGTPresent: UpdateCredentialsCache returns 17235968
SharedVolumeEnumerator::FetchVolumeList TGT present is false
SharedVolumeEnumerator::FetchVolumeList Username/Password present is True
SharedVolumeEnumerator::FetchVolumeList HI Allowed = 0 UAM says 0
TUAMHandler::Login
TUAMProxy::OpenUAMCode: ^EMS3.0
UAMGetClientInfo theHandler = 86ee00
TUAMProxy::DoUAMLogin: ^EMS3.0
SetupLoginPacket: inAFPVersion = 4
SetupLoginPacket: using std login
UAMOpenSession: theHandler = 86ee00
OpenSession worked: afpResult 0x0
Option Type: 0x0
Option Length: 0x4
Option Value: 0xffff0000
DoMSUAMLogin: using NTLM V2
TUAMProxy::CloseUAMCode: ^EMS3.0
FetchVolumeList: 4 volumes total
IsVolMounted: inMaxPath = 0 outMounPath = (null) mntFlags = 0000
IsVolMounted: error = 2
FetchVolumeList: Checking Access on Microsoft UAM Volume volflags = 00
Privs are user=07 owner=03 group=00 world=07
FetchVolumeList: User has access
IsVolMounted: inMaxPath = 0 outMounPath = (null) mntFlags = 0000
IsVolMounted: error = 2
Hermann Schaefer
> Tut's Bonjour für Windows denn nicht? Keine Chance, da statische mDNS-
> Einträge damit publizieren zu lassen?
Avahi hat dazu eine config in /etc, der Apple-Client hat.. tjo.. nichts zu
finden. Die Registry-Einträge sind nichtssagend und auch sonst ist die Doku
(höhö.. welche?) recht schweigsam.
> Und wenn nicht unter Windows, es
> reicht doch, wenn $irgendwas im LAN die mDNS-Einträge publiziert, oder?
In dem Netz dort gibt es nichts (an dauernd laufenden Servern), was den Job
machen könnte. Stichwort: Monokultur.. ^^
> Verstehe ich nicht (was das mit "M$-Server" per se zu tun haben soll --
> es gibt schließlich neben Microsofts eigenen Services for Macintosh auch
> noch MacServerIP und ExtremeZ-IP).
Die kosten bekanntlich Geld..
> Hier (Client 10.5.2, Server Win2003, Microsoftsche SFM als AFP-Server)
> klappt das prima. Mounten per [apfel]-[k] und nur Angabe der IP-Adresse
> klappt wunderbar per AFP (inkl. verschlüsselten Logon Credentials Dank
> "NTLM v2" [1]). Ein forsches "df" meint jedenfalls anschließend:
>
> afp_422m141Kz9mM4s9xjo0N5tvF-1.2d000006 [...] /Volumes/Microsoft UAM Volume
Keine Chance, zigmal probiert von verschiedenen Macs (neue MacPro, neue
MacBooks), ewig rumgespielt. Fehler 5tausendirgendwas (führt aber zu nix und in
der console herrscht totales Schweigen). In den üblichen Foren findet man massig
Leidensgenossen, überall das gleiche: Mouten über die GUI schlägt fehlt, mounten
per shell geht. Auf den Kisten läuft nu ein kleines Script:
do shell script "mkdir /Volumes/Server"
do shell script "mount_afp afp://user:password@server-ip/share /Volumes/Server"
Geht auf allen Kisten ohne Fehler und ohne sonstige Probleme.
Damit sieht man den Server zwar nicht auf dem Schreibtisch und kommt nur über
den Computerlink links oben in der Seitenleiste hin, aber das klappt wenigstens.
Es ist dabei auch egal, ob Klartext erlaubt oder nicht (kann man ja in
com.apple.appleshareclient.plist ändern) oder sonstigen Einstellungen an den SFM
(Win2k3 und die SBE).
> Schmeiß die Macs halt alle in einen gewissen IP-Address-Range und blocke
> den Zugriff per SMB/CIFS (sollte man IMO *immer* machen, denn das
> Mischen von SMB und AFP-Zugriffen innerhalb derselben Shares führt nur
> zu (Meta-)Datenverlusten bzw. wie bei Dir zu ernsthaften Irritationen,
> wenn Dateiformate im Spiel sind, die alles Relevante in der Resource-
> fork herumschleppen.
Wäre entweder sehr umständlich oder nicht gewollt. Und nein, da hilft gutes
Zureden manchmal auch nicht.. ^^ Wenn man auf Windos-Admins trifft, die MCSE mit
einem Adelstitel verwechseln, hilft rein gar nichts mehr.
Bis 10.4 war das ja auch kein Problem, da wurden die Server einfach mit einem
Startscript gemountet. Jetzt zwar auch, nur halt nicht auf den Schreibtisch:
"Der Server ist nicht da!!!" .. "Guggst du links oben, Computername, Server.."
.. "Hmm.. ach da!... Kann ich den nicht auf den Schreibtisch haben???" ..
"*seufz*"..
Alles auf smb umstellen funktioniert auch (noch) nicht, da noch *hust*
OS9-Rechner im Netz mitspielen.
> Ist aber wohl ein wenig Overkill bei Dir?
Da, wo es kein Overkill wäre, werkeln zum Glück 440Rs oder Xserve oder.. ^^
> Thomas, leicht irritiert, daß Du anscheinend die SFM im produktiven
> Einsatz hast...
In den Fällen geht/ging nichts anderes. Entweder wegen Budget oder Firmenpolitik
(Hunderte Dells und ein paar Macs.. ^^). Lange stehen die Dell/FSC nicht mehr
und werden wohl doch durch Xserve ersetzt, aber das dauert noch. *seufz* Bis
dahin muß ich es halt irgendwie.. hinfrickeln. Naja, Kollege schaut sich grade
die Javabeispiele bei Apple an, mal sehen, ob er da was draus bastelt.
mfg Hermann, der vor rund einem Jahr einen Mac SE mit 6.07 aus dem produktiven
Einsatz durch einen LC475 mit 7.1 ersetzt hat (Analogplatine vom SE war
durchgebrannt). Installationsdatum des Systems: vermutlich Sommer '89 oder
früher, Einsatzzweck des SE: mehrere Labeldrucker von Fargo, Software namens
Barrage (sogar mit ADB-Dongle.. :D).
Thomas Kaiser
> Thomas Kaiser schrieb:
>
>> Hier (Client 10.5.2, Server Win2003, Microsoftsche SFM als AFP-Server)
>> klappt das prima. Mounten per [apfel]-[k] und nur Angabe der IP-Adresse
>> klappt wunderbar per AFP (inkl. verschlüsselten Logon Credentials Dank
>> "NTLM v2" [1]). Ein forsches "df" meint jedenfalls anschließend:
>>
>> afp_422m141Kz9mM4s9xjo0N5tvF-1.2d000006 [...] /Volumes/Microsoft UAM Volume
>
> Keine Chance, zigmal probiert von verschiedenen Macs (neue MacPro,
> neue MacBooks), ewig rumgespielt. Fehler 5tausendirgendwas (führt aber
> zu nix und in der console herrscht totales Schweigen). In den üblichen
> Foren findet man massig Leidensgenossen, überall das gleiche: Mouten
> über die GUI schlägt fehlt, mounten per shell geht.
Magst da mal 'nen Trace anfertigen, packen und mir schicken?
tcpdump -i ${if} -s 0 -U -w ${tracefile} host ${ip-adresse}
Und die Geschwätzigkeit in der syslogd.conf hochsetzen [1] und das auch
gleich dazupacken?
> Auf den Kisten läuft nu ein kleines Script:
>
> do shell script "mkdir /Volumes/Server"
touch /Volumes/Server/.autodiskmounted
> do shell script "mount_afp afp://user:password@server-ip/share /Volumes/Server"
Auch häßlich wegen Paßwort in Klartext. Da finden sich aber seitens
Ralph Skriptschnipsel im Archiv bzgl. Keychain Scripting.
> Geht auf allen Kisten ohne Fehler und ohne sonstige Probleme.
Bis halt auf die "Sichtbarkeit" :-)
Funktioniert der "disktool -r"-Trick -- vorher und nachher ausgeführt --
denn nicht?
Gruss,
Thomas
[1] <http://kaiser-edv.de/news/MacOS/afp-sessions-debuggen.html>
Hermann Schaefer
> Magst da mal 'nen Trace anfertigen, packen und mir schicken?
Frühstens nächste Woche irgendwann.
> touch /Volumes/Server/.autodiskmounted
hmm.. stimmt, da war was..
> Auch häßlich wegen Paßwort in Klartext. Da finden sich aber seitens
> Ralph Skriptschnipsel im Archiv bzgl. Keychain Scripting.
Spielt dort zum Glück keine Rolle, aber hätte das PW ja auch per Applescript
abfragen können.
Hatte mir eh vorgenommen, daß noch mal anzuschauen und auch mit den SFM noch
etwas rumzuspielen, hatte nicht so wirklich die Zeit zum weiter debuggen.
Seltsam ist halt, daß es per mount-afp ohne Probleme immer geht, aber weder
mounten per Doppelklick noch verbinden mit funktioniert aber smb auch keine
Probleme macht.
Thomas Kaiser
> Seltsam ist halt, daß es per mount-afp ohne Probleme immer geht, aber
> weder mounten per Doppelklick noch verbinden mit funktioniert
Naja, ich kann's halt überhaupt nicht nachvollziehen, weil das hier
völlig problemlos klappt. Wobei "hier" eben exakt ein MacBook mit 10.5.2
ist, das sich mit den SFM eines Win2003 Servers verbinden soll, der via
VMWare auf derselben Kiste läuft (Bridged Networking). Sonst hab ich
weit und breit weder aktuelle SFM (alle Windows-Kunden auf MacServer IP
oder ExtremeZ-IP) im Zugriff noch aktuelle MacOS X Versionen (10.5 ist
bei Androhung von Support-Verweigerung weiterhin verboten -- basta)
> aber smb auch keine Probleme macht.
SMB verschiebt die Probleme bloß auf andere Ebenen ;-)
Gruss,
Thomas