Vielleicht ist das Thema schon oft behandelt worden. Aber ich finde nichts.

Frage: Immer nach Neustart verbinde ich den Hausserver über das Menü "Gehe zu..." und dann "Mit Server verbinden...".
Geht das auch automatisch mit Passwort ?

Gruss Helmut

Hallo,

"eigentlich" reicht es, die Servervolumes einfach in die "Login Items" aufzunehmen. Ab 10.3 zu finden unter Systemeinstellungen --> Benutzer.

Allerdings gibt es zwei Schönheitsfehler: Volumes mit Umlauten im Namen bleiben auf der Strecke (hier steckt irgendwo noch ein Bug seitens Apple drin) und auf der anderen Seite wird für jeden auf diese Weise verbundenen Server auch gleich ein Finder-Fenster geöffnet, was ein wenig unübersichtlich werden kann.

Abhilfe ist ein simpler Nachbau des Mechanismus, wie er mit MacOS 9 (genauer AppleShare Client 3.9) Einzug hielt: Man legt sich Aliase der Server-Volumes in einen Ordner und läßt diese durch ein den Login Items hinzugefügtes AppleSkript beim Neustart "öffnen". In einem zweiten Schritt werden dann noch alle Fenster von Server-Volumes geschlossen.

Keine Sorge -- Das alles gibt es auch schon fertig zum Runterladen:

http://www.cocoa-co.de/.../wiki.pl?MountOMatic

Gruss,

Thomas Kaiser

Du kannst auch selber ein AppleScript erstellen.
ich mache das so..

für den Windows Mailserver Mount nutze ich:
mount volume "cifs://benutzername:passwort@192.168.2.4/merkur"

für den Mac OSX-Server Muunt benutze ich:
mount volume "afp://benutzername:passwort@192.168.1.10/Server-HD"

Diese Zeile jeweils in AppleScript einfügen und als ausführbare .app
speichern. Danach nur noch in Startobjekte einfügen...fertig.

gruess
GöGG
Mac OS X Server 10.3.4
**************************
http://www.goegg-art.ch
**************************

Hi,

solche Skriptfragmente sind der Albtraum jedes verantwortungsvollen Netzwerk-Admins! Liegen doch Benutzername und Paßwort für den Server auf einmal irgendwo im Klartext in der Gegend herum.

Wenn dann schon auf Apples "Schlüsselbund" setzen. Dort sind die Paßwörter wenigstens mit relativ starker Kryptographie geschützt.

Den Schlüsselbund benutzt man automatisch auch beim Automatischen Mounten per Login Items, wenn man im "Mit Server verbinden"-Dialog unter "Optionen" das Hakerl an der passenden Stelle setzt. Ein Alias eines auf diese Weise gemounteten Volumes "erbt" diese Eigenschaft. Wird es später per "open" geöffnet (sei es aus AppleScript heraus, per open(1) aus der Shell oder mit einem generischen "Open" AppleEvent) so erfolgt der Zugriff auf den Schlüsselbund automatisch.

Also bitte solche Horrorszenarien, bei denen Benutzeraccounts schutzlos in der Gegend herumliegen, vermeiden :-)

Gruss,

Thomas Kaiser

Hallo,
der Tip mit den Servervolumes in die "Login Items" aufzunehmen hat wunderbar funktioniert.

Ich habe den manuell aktivierten Server einfach auf das leere Feld von "Startobjekte" gezogen.

Danke

Hallo zusammen
dazu möchte ich anmerken, dass ich mit dem automatischen Mounten von Servervolumes immer nur Aerger hatte. Bei jedem Server- oder Netzwerkproblem hingen die Clients minutenlang in der Warteschlaufe. Ich habe diese Funktion intern schlicht verboten und zwischenzeitlich sind wir alle zufrieden damit (14 User).
Gruss und Dank
Urs
http://www.designersfactory.com

@Thomas Kaiser
:( das stimmt natürlich was Du sagst....
da ich mein Eigenes kleines Netzwerk habe und alleiniger benutzer davon bin, habe ich der Sicherheit zuwenig beachtung geschenkt...

denoch liegen die ja nicht einfach irgendwo herum
es sei denn man hat zugriff auf den Administrator-Ordner (denk ich)

für Netzwerke mit mehreren Benutzern empfehle ich natürlich
die Version von Thomas Kaiser anzuwenden.

gruess
GöGG
**************************
http://www.goegg-art.ch
**************************

Hallo GöGG,

> da ich mein Eigenes kleines Netzwerk habe und alleiniger benutzer
> davon bin, habe ich der Sicherheit zuwenig beachtung geschenkt...

Sowas kann aber regelmäßig nach hinten losgehen...

> denoch liegen die ja nicht einfach irgendwo herum es sei denn man
> hat zugriff auf den Administrator-Ordner (denk ich)

Den Zugriff kriegt man leichter, als man denkt. Nicht nur Microsoft hat Sicherheitsfehler per Design in ihre Betriebsysteme eingebaut, auch Apple. /Library/StartupItems bspw. ist ein offenes Einfallstor, das immer noch nicht seitens Apple geschlossen wurde. (vergleiche mit http://www.heise.de/...ticker/meldung/46409 -- insbesondere der Link am Ende auf die Diskussion in den Newsgroups)

Aber nochmal zum Thema zurück: Solche Skripte in den Login Items müssen irgendwo liegen, wo sie mit den Berechtigungen des aktuell eingeloggten Benutzers auch ausgeführt werden können. Es reichen also die Privilegien des Benutzers, der gerade aktiv ist.

Wenn Du von "Administrator-Ordner" schreibst, dann macht mich das ein wenig stutzig. Loggst Du Dich etwa mit einem Administrator-Account ein? Falls ja, das bitte ebenfalls *sehr* schnell überdenken, da das einerseits nicht nötig und andererseits nur unnötig gefährlich ist. Diskussion des Ganzen sicherlich auch in der oben verlinkten Newsgroup-Diskussion zu finden.

Gruss,

Thomas

Hallo zusammen

Das AppleScript ist sicher keine Lösung, wenn es um eine sichere Umgebung geht, in der jeder seinen eigenen Account auf einem Server hat. Also wenn z.B. sensible Daten sicher sein sollen.

Ansonsten haben wir in der Druckvorstufe eh die Situation, dass jeder das Passwort vom Server kennt. Und wenn einer durch die Firewall ins Netzwerk kommt, dann ist der Fehler in der Konfiguration ganz woandes passiert.

Ich hänge dem Applescript jeweils ein "try" vornedran und schliesse es mit "end try" wieder ab. So muss ich nicht warten und habe keine Fehlermeldungen, wenn die Servervolumen nicht verfügbar sind.

Aber eben: Von mir aus gesehen nur wirklich brauchbar, wenn die Kennwörter eh "generisch" sind...


// david uhlmann

mac os x & datahandling
http://www.wissen-wie.ch

Hallo David,

> Das AppleScript ist sicher keine Lösung, wenn es um eine sichere
> Umgebung geht, in der jeder seinen eigenen Account auf einem
> Server hat.

*Welches* AppleScript? Jenes, das den "Server-Alias"-Mechanismus von MacOS 9 nachbaut oder das andere mit direkter Verdrahtung von Benutzername/Paßwort?

> Ansonsten haben wir in der Druckvorstufe eh die Situation, dass
> jeder das Passwort vom Server kennt.

Das sind dann aber Betriebe, die wohl auch arge Produktivitätsdefizite haben?

> Und wenn einer durch die Firewall ins Netzwerk kommt, dann ist der
> Fehler in der Konfiguration ganz woandes passiert.

Ach, bei den meisten größeren Druckvorstufenfirmen braucht man nicht die Firewall großartig überwinden. Man nimmt einfach einen der Nebeneingänge, die sich meist zahllos tummeln :-)

> Ich hänge dem Applescript jeweils ein "try" vornedran und
> schliesse es mit "end try" wieder ab.

Dieses "try" Konstrukt gilt nur für die Fehlerbehandlung *innerhalb* von Skripten. Es kann gar nicht dazu geeignet sein, Fehlerzustände außerhalb abzufangen...

> So muss ich nicht warten und habe keine Fehlermeldungen, wenn die
> Servervolumen nicht verfügbar sind.

Ernsthaft? Das Problem zumindest bei der Variante mit Aliasen ist, daß ein simpler Open Event dazu führt, daß das Alias aufgelöst werden soll, damit sofort ein Zugriff auf den VFS-Layer [1] stattfindet und je nach MacOS X Version dann dies und das passiert (MacOS X 10.3 ist in der Hinsicht aber schon wirklich deutlich robuster -- älteren Varianten steckten zum Teil in solchen Situationen schon in einem deadlock, d.h. es half meist nur noch, den Finder abzuschießen. Davor *kann* ein simples try Konstrukt aber nicht schützen, da es in dem Moment auf Kernel-Ebene klemmt. Und soweit kommt AppleScript nun zum Glück nicht hinunter :-)

> Aber eben: Von mir aus gesehen nur wirklich brauchbar, wenn die
> Kennwörter eh "generisch" sind...

Wie jetzt? Was spricht gegen die Verwendung des Schlüsselbund für die Speicherung individueller Paßwörter?

Gruss,

Thomas

[1] VFS --> Virtual File System -- eine Abstraktionsebene, um auf diversen physischen Dateisystemen gewisse logische Eigenheiten abzubilden

Hallo Thomas

>*Welches* AppleScript? Jenes, das den "Server-Alias"-Mechanismus >von MacOS 9 nachbaut oder das andere mit direkter Verdrahtung von >Benutzername/Paßwort?

Die zweite Variante...

>Das sind dann aber Betriebe, die wohl auch arge >Produktivitätsdefizite haben?

Nicht zwingend. Du hast einen User und ein Kennwort und bist auf dem Fileserver - fertig. Ich weiss nicht, was daran unproduktiv sein soll. Und alle melden sich mit diesem Account an. Wohlgemerkt, es geht da um einen reinen Fileserver, bei dem es darum geht, Daten zu sichern und zu holen...

>Ach, bei den meisten größeren Druckvorstufenfirmen braucht man >nicht die Firewall großartig überwinden. Man nimmt einfach einen >der Nebeneingänge, die sich meist zahllos tummeln :-)

z.B.?? Ich kenne leider viel zu viele Betriebe, die haben noch nicht mal einen Firewall (natürlich versuche ich sie zu überzeugen von der Notwendigkeit einer solchen, aber eben...). Und dann kommt bei vielen die Vorstellung, auf dem Fileserver eine Portsperrung sei die endgültige Lösung...

>Dieses "try" Konstrukt gilt nur für die Fehlerbehandlung >*innerhalb* von Skripten. Es kann gar nicht dazu geeignet sein, >Fehlerzustände außerhalb abzufangen...

Hab ich auch nicht gemeint. Es geht nur darum, dass bei einem Nicht-Erreichen des Servers nicht gleich die Fehlermeldung von wegen "Edit" usw. kommt...



>Wie jetzt? Was spricht gegen die Verwendung des Schlüsselbund für >die Speicherung individueller Paßwörter?

Bei kleinen Druckvorstufen hats halt meistens keinen Vollzeitadmin. Und da werden häufig einfache Accounts eingesetzt, die im Workflow aus meiner Sicht auch Sinn machen können. Denn: In einem Produktionsprozess kann es durchaus hinderlich sein, wenn Benutzer A seine Daten auf seinem Rechner hat und dann in die Ferien geht.

Gruss, Dave

Hallo

Ich dachte anfangs auch, dass ich das autom. Verbinden benötige, aber weit gefehlt. In OS-X habe ich den "guten alten Favoriten Ordner" im linken Teil des Finderfensters hineingezogen und lege dort einmal gemountet Netzwerkvolumes ab.

Diese Favoriten stehen mir nun im Öffnen/Sichern Dialog zur Verfügung und ich kann bequem zu jedem Servervolume, ohne dass ich diese alle im Vorhinein gemounted haben muss.

Oder gibt es einen dringenden Grund alles gemoutet zu haben?

Peter

Hallo David,

> Du hast einen User und ein Kennwort und bist auf dem Fileserver -
> fertig. Ich weiss nicht, was daran unproduktiv sein soll. Und alle
> melden sich mit diesem Account an. Wohlgemerkt, es geht da um
> einen reinen Fileserver, bei dem es darum geht, Daten zu sichern
> und zu holen...

Für mich kommt die Frage Produktivität folgendermaßen ins Spiel (und ich rede nicht davon, daß die Benutzer von den Rechten her irgendwie voreinander abgeschottet werden sollen -- ganz im Gegenteil, Dein Beispiel mit dem Kollegen, der in Urlaub entschwindet, ist sicherlich nicht verkehrt):

Wenn alle Leute auf dem Server einen individuellen Account haben, kann man mit gewissen Workflow-Features recht simpel andocken. Bspw. Bilddaten on-the-fly auf dem Server prüfen und dem Benutzer eine Rückmeldung zukommen lassen. Dito mit PDFs, die per Warteschlange oder Hotfolder erzeugt werden. Die können direkt wieder beim Benutzer landen und man spart sich das permanente Durchsuchen eines größeren Datenpools, in dem der Kram landet.

Aber auch, wenn gar keine Automatismen im Einsatz sind, hilft das doch oftmals schon, um rauszufinden, wer wann welchen Ordner angelegt oder welches Dokument erzeugt hat...

Oder auch AFP-Messages oder WinPopUps für die Windows-User.

Bietet meines Erachtens eine Menge Vorteile, die man natürlich erst dann so richtig ausspielen kann, wenn man ein bisserl anfängt, mit Automatismen zu spielen.

Gruss,

Thomas

Hallo,

man muss da einfach unterscheiden, ob alle sich mit einem Account am Server anmelden und von daher zwangsläufig kein oder alle das gleiche Passwort haben, oder ob, wie Thomas schon schrieb, der Account auch als Ordnungskriterium gebraucht wird.
Dann hat jeder seinen Account.
Das heißt ja nicht, das die nicht alle das selbe Passwort verwenden.

MfG

Thomas

Hallo
genau so haben wir das gelöst (Account für jeden, Standardpasswort) und fahren bestens damit!
Gruss und Dank
Urs
http://www.designersfactory.com