Will man einem User bestimmte Verzeichnisse und Drucker fest zuordnen, kann man das mit den Zuordnungen des LAN Server machen, das klappt solange man es mit DOS oder Win-Clients zu tun hat. Ist es ein OS/2 Client Warp 4 mit der LAN Server Verwaltung kann der User jedoch die für ihn geltende Zuordnung ändern.
Auf der Domänensteuereinheit unter \IBMLAN\DCDB\USER\[Anmeldename] kann man eine Datei PROFILE.CMD füe OS/2 und PROFILE.BAT für DOS & Win-Clients erstellen.
Diese Datei kann nur vom Rechner mit dem DC bearbeitet werden. Eine Änderung durch Clients ist nicht möglich. In dieser Datei kann dann z.B mit NET USE .... eine Anmeldezuordnung für den User festgelegt werden. Mit ein wenig Batch-Programmierung kann man auch eine dynamische Zuordnung erreichen.
z.B. durch Abfrage einer SET Umgebungsvariablen.
Ein User hat Rechte auf bestimmten Dateien und Verzeichnissen, die bekommt er immer, egal von welchem Rechner er sich anmeldet. Es gibt jedoch 2 Büros wo jeweils Rechner und Drucker stehen. Wird auf den Rechnern nun z.B eine Ungebungsvariable z.B SET ZUORDNUNG=BUERO_1 gesetzt, könnte man diese Variable in der PROFILE.CMD abfragen und dem User automatisch den passenden Drucker zuordnen.
/* REXX */ parse source . . calledAs HomeDir = filespec( "D", calledAs ) || filespec( "P", calledAs )
LanRoot = "C:\IBMLAN" do queued(); pull .; end "DIR" LanRoot"\DCDB\USERS\* /ad /f | RxQueue" do queued() pull Verz "ATTRIB" Verz"\PROFILE.CMD -r -s -h >nul" "COPY" HomeDir"PROFILE.CMD" Verz ">nul" if rc <> 0 then do say "Fehler beim Kopieren nach" Verz say "RC=" rc end end exit |
Damit wird im LANROOT nach Benutzerverzeichnissen gesucht und dort, wo es
selbst steht, nach einer Profile.CMD, die dann kopiert wird... Könnte
natürlich noch wesentlich aufwendiger sein. Mit ein wenig Umbauen kannst Du statt XCOPY auch NET ACCESS auf die Verzeichnisse loslassen: 1. /DEL zum Löschen der Berechtigungen 2. /ADD USERID:Y zum Setzen (jeder User hat auf sein Verzeichnis alle Rechte) 3. /APPLY zum Vererben an die Unterverzeichnisse Dazu muß allerdings Admin-Berechtigung vorhanden sein. |
---|
Will ich verhindern, dass Netzwerkressourcen im Browser angezeigt werden, so kann man als letztes Zeichen im Ressourcennamen ein »$« setzen.
Wie man bei dem Bild unten sieht kann der gemeinsame Zugriff beim LAN Server auf drei Arten geregelt werden.
|
Durch Administator: |
---|
Sollte wohl klar sein was es damit auf sich hat.
|
Beim Server-Start: |
Das ist die Art wie z.B. auch bei Warp Connect und Warp 4 der Server und
die Ressourcen automatisch gestartet werden. Bei Verzeichnissen und Festplatten
gibt es da keine Probleme. Bei Wechselmedien wie CD-ROMs kann es Ärger
geben.
Ist z.B. in einem freigegebenen CD-ROM keine CD wird 1. eine Fehlermeldung ausgegeben und 2. kein Share dafür freigegeben. Die Freigabe muß manuell nach Einlegen einer CD erfolgen (Gemeinsamer Zugriff starten).
|
Bei Anforderung |
Im Gegensatz zu obiger Methode wird auch ein ALIAS für Shares eingerichtet, die beim Starten nicht funktionsfähig sind. Beim CD-ROM ohne CD erfolgt keine Fehlermeldung. Versucht ein User das CD-ROM anzusprechen erhält er eine Fehlermeldung. Legt man die CD ein und versucht noch mal das CD-ROM anzusprechen (z.B. net use n: CDROM) so ist dies nun erfolgreich. Es bedarf keinem manuellen Eingriff des Administators um den Share zu aktivieren. |
Für dir Freigabe eines CDROM muss das gesamte Laufwerk freigegeben werden, nicht nur das Root des Laufwerks .
NET ACCESS F: /ADD USERS:RWCD ändert den Zugriff entsprechend , wird der LS über einen WARP 4 verwaltet geht es auch über die GUI der LS-Verwaltung.
DOS und Win-Clients haben oft Probleme wenn ein Laufwerk größer als 2GB ist, da die meisten Programme dann eine negative Mediengröße melden. Abhilfe schafft es in der IBMLAN.INI wrkheuristics BIT 35 auf 1 zu setzen. Dann wird an DOS und WIN Clients nur noch eine maximale Mediengröße von 2GB gemeldet.
Seid immer schön brav, löffelt die Suppe immer aus und setzt in der IBMLAN.INI unter dem Abschnitt [LSSERVER] den Wert CLEANUP=YES, sonst könnt ihr unliebsame Überraschungen erleben, wozu das Ding taugt steht in der DOKU, per Default steht es jedoch auf NO.
Simpel, aber wahr, die schnellen Daten über Netz sind die welche gar nicht übertragen werden müssen. Und wie mache ich das jetzt ? Ganz simpel: Datenkompression. Für OS/2 gibt es z.B. LXLITE (LXLT115.ZIP) welches OS/2 EXE und DLL Dateien lauffähig komprimieren kann. Die EXE und die DLL's schrumpfen z.T. um 50%.
|
||
Programm |
Faktor |
umkomprimiert |
---|---|---|
ZOC/2 EXE & DLL's |
ca 50% |
1.4 Mb |
GOLDED/2 EXE |
ca 50% |
730 Kb |
GREQ/2 EXE & DLL |
ca.45% |
3 Mb |
IMPOS v1.2 EXE & DLL |
ca.40% |
2 Mb |
Wer dann noch Schwergewichte wie z.B. die Lotus Smartsuite, die alles andere als smart ist, auf dem Netzwerk hat, sollte doch mal testen was von den Programmen sich alles komprimieren läßt. Erstens sinkt mal der Platzbedarf auf dem Server und 2. sinken auch die Datenmengen die Übertragen werden und es erhöht sich die Ladegeschwindigkeit für die Programme.
Was für OS/2 LXLITE ist für DOS-Anwendungen z.B. DIET, Wenn jemand weis ob es so etwas auch für Win Programme gibt, ist er hiermit aufgefordert, mir zu verraten wie das Programm heißt.
Um den LAN Server 5.0 des Warp Server unter Warp 4 zu betreiben, gehe ich in der folgender Reihenfolge vor:
Vorsicht bei einem Warp Server mit
HPFS386. Die Datei
X:\OS2\BOOT\CONFIG.X wird von Warp verwendet,
wenn das Booten mit ALT+F1 abgebrochen wurde und eine OS/2 VIO Session (F2)
angefordert wird. Ihr müßt den Eintrag von HPFS durch den des
HPFS386 ersetzen, sonst seid ihr im Notfall in den Allerwertesten gekniffen
und könnt nur hoffen das ihr eine BOOTDISK mit HPFS386 oder eine passende
Wartungspartition mit HPFS386 Support habt.
So das war mal meine Kurzfassung eine 1.3MB große etwas länger Fassung ist das IBM Redbook zu dem Thema . Zu haben ist es als WSONW4.ZIP.Das ganze ist auf Englisch und von einigen IBM Mitarbeitern zusammen getragen worden . Es geht damit los das man die OS/2 Startdisks erstellt ..............
PROBLEM von H. Fuchs Mi, 14 Jan 98 09:27
Durch eine Umstrukturierung im Hause sollen neue Ressourcen- und Ressourcennamen geschaffen und alte Ressourcen gelöscht werden. Das hat soweit geklappt. Durch die Zuordnung der neuen Ressourcen und dem Löschen der alten Ressourcen für die jeweiligen Benutzer und die entsprechende Rechtevergabe über die LAN Server Verwaltung dachte ich, ich hätte alles erledigt. Denkste....
Verschiedene Benutzer bekommen immer noch die alten Ressourcen mit Fehlermeldung zugeordnet, obwohl sie in der Benutzerdaten-bank nicht mehr vorhanden sind.folgende Fehlermedlung erscheint bei der Anmeldung über die DOS-Ebene mit den DOS LAN Services...:
|
Über den Server \\SERVER1 wurde die Anmeldung als ZENDER erfolgreich
ausgeführt.
Berechtigungsstufe für die Domäne: USER. Verbinden von O: mit ALLE... O: mit ALLE verbunden. Verbinden von D: mit AMT08.01... D: mit AMT08.01 verbunden. Verbinden von P: mit PUBLIC... P: mit PUBLIC verbunden. Verbinden von F: mit P_F&A... F: mit P_F&A verbunden. Verbinden von LPT2 mit \\SERVER3\HP5VHS... Wiederherstellung der Verbindung zwischen LPT2 und \\SERVER3\HP5VHS nicht möglich (Fehler 67). Verbinden von D: mit \\SERVER1\REF21... Wiederherstellung der Verbindung zwischen D: und \\SERVER1\REF21 nicht möglich (Fehler 85). Verbinden von O: mit \\SERVER1\ALLE... Befehl erfolgreich abgeschlossen.
|
LÖSUNG : In C:\NET\NETWORK.INI den Schalter RECONNECT=YES
auf RECONNECT=NO ändern und es ist wieder alles I.O .
Durch erlegen einen DOS-Lan-Requester und anschießender Autopsie kommt man zur folgender Feststellung .
Wir benoetigen > eine Moeglichkeit zu üeber- pruefen, auf welche Aliase eine bestimme Gruppe oder Person mit welchen Rechten Zugriff hat. Das kann man bestimmt auch mit viel Fleis, aber bei z.B.200 Gruppen, 1000 Usern und 250 Aliasen ist das kein Zuckerschlecken, wenn man alles per Hand nachschaut. Gibt es dafuer eine Moeglichkeit?
Es gibt im Verzeichnis \IBMLAN\NETPROG ein entsprechenden Befehl als REXX-Skript namens "DSPDOMDF.CMD", dier eine komplette Beschreibung deiner Domäne liefert. Wenn Du die nur in eine Textdatei umleitest, hast Du alle Infos wo Du brauchst.
dspdomdf > D:\DOMDEF.TXT
Mit einen Editor oder LIST-Util kan man sich jetz alles schön ansehen oder nach User durchduchen .
Ich habe hier einen Wapr Server im Netz, der auf den etwas phantasielosen
Namen "OS2SERV" hört. Ich möchte ihn lieber umbenennen, so daß
er sich als "Robert" oder "Fritz" oder so meldet.
---------------
1.) Server mit altem Namen starten.
2.) Als Admin anmelden und CHGSRVR <AlterServerName>
<NeuerServerName> aufrufen.
3.) Abmelden und Requester stoppen.
4.) "OS/2 LAN Dienste - Installation und Konfiguration", "Angepaßt"
aufrufen.
5.) Hier dann erst "Datenstation konfigurieren", neuen Servernamen und evtl.
neuen Domänennamen eintragen, "DCDB nicht initialisieren", dann
Änderungen durchführen".
Nach einem Neustart hast Du alle bisherigen Definitionen unter einem neuen
Servernamen.
mfg Thomas Baumann
Zuerst mal an dem unfreiwilligen Domainserver :
- NET STOP SRV
- NET ACCOUNTS /ROLE:STANDLONE
Nun läuft er als Einzelserver , in der IBMLAN.INI die Domäne mit dem Editor ändern , das ist der einzige Platz wo diese festgehalten ist .
Neu Booten kann nicht schaden , könnte aber auch ohne gehen . Der Server ist nun als eigenständiger Server in der gleichen Domäne wie dein DC .
Auf dem DC einen Useraccount SERVER mit Name des neuen Server anlegen .
Falls du neu gebootet hast den Server noch mal Stoppen ( - net stop srv)
Der eigenständige Server hat ja nun einen account auf den DC , nun kannst du ihm in den Verbund mit aufnehmen .
- NET ACCOUNTS /ROLE:MEMBER
- NET START SRV
bingo! DC_neu ist nun Mitglied in der Domaine DC_alt und arbeitet als zusätzlicher Server in der Domäne
Ich hab da auch was für die FAQ bekommen was ich an dich weiterleite da es WARP SERVER betrifft
Nachdem Du ja nun etwas tiefer in die OS/2-Welt vorgestossen bist, mal noch einige Tips eines erfahrenen LAN Admins, speziell hinsichtlich Konfiguration, Architektur und vor allem 'lokaler Sicherheit'.
Zunaechst: Nach der Installation des Systems UNBEDINGT das LAN Fixpack einspielen ( auf CD , ipg8265 ). Spart viel Aerger. Im Falle von Wechselmedien noch den ip_8507 und NewDasd/FP 32 oder gleich FP 35 installieren. Falls Du im Netz bist schadet das MPTS Fixpack nicht, es ist stabil und behebt einige TCPBeui Probleme. Achtung Wechselmedien: Wenn Du normale HPFS Medien verwendest sollte der erste Zugriff via CHKDSK erfolgen, der hpfs386.ifs konvertiert dann das Medium dementsprechend. Dann gehts allerdings glatt ueber die Buehne.
Ich empfehle unbedingt die Addons von der CD noch einzubinden. Wer den Textmodus liebt wird sehr gluecklich damit sein. Das meiste ist direkt via GNU von Unix portiert, Du solltest Dich ja schon damit auskennen. Im uebrigen sind die OS/2 und LINUX Gemeinden nicht miteinander 'verfeindet', da das eine System von anderen echt profitieren kann. Das gilt speziell fuer OS/2 dem ja mit GNU kraeftig auf die Spruenge geholfen wird. Dies erlaubt dann ein echtes 'Remote Admin' via Telnet, eine ungeheuer machtvolle Waffe.
Soweit mal, das sind ja schon fast 2 Tage Arbeit ....
Wenn Du das hinter Dir hast, kannst Du dann die lokale Sicherheit aktivieren und erhaelst so ein fast Linux-artiges System. Allerdings nur fast, es gibt einige Unterschiede. Gute und schlechte wie Du sehen wirst.
1. Benutzer, Gruppen und Rechte
Im Gegensatz zu UNIX kann eine Ressource mehrer Eigentuemer ( Gruppen und User) haben, deren Rechte individuell setzbar sind. Genauer gesagt sind bis zu 64 Eintraege/Ressource moeglich. Unter Unix hat JEDE Ressource einen Eigentuemer, im HPFS386 muss dies nicht so sein, eine Ressource uebenimmt immer die Rechte des uebergeordneten Verzeichnisses wenn keine eigene existiert. Falls auf einem LAufwerk kein ACL existiert gehoert es automatisch 'ROOT' und niemand hat Zugriff. FAT Laufwerke sind nicht geschuetzt und koennen nicht geschuetzt werden.
( Genauer: Lokal ungeschuetzt, im Netz geschuetzt, keine Quota )
Rechte werden im Dateisystem gespeichert, nicht in den EA's!! HPFS386 unterstuetzt 'Quota' der ALLE ausser einen Administrator und, ganz wichtig: keine ROOT-Prozesse selber, unterliegen.
User: Es gibt keine UID's, der Benutzername wird im FS gespeichert. Das ist bei Wechselmedien sehr sinnvoll, da unter 2 Linux-Systemen derselbe User verschiedene UID's haben ( passwd ) kann, was ja bei NFS eine Katastrophe ist. Es muss also kein Abgleichgefummel von passwd erfolgen.
Gruppen: Dito, es gibt keine GID's. Ein User kann zur Laufzeit mehreren Gruppen gleichzeitig angehoeren, chgrp gibts es nicht !! Ein User gehoert niemals 'local' und IMMER 'users' an.
Aministratoren: Sind ALLE die der Gruppe ADMINS angehoeren. Es kann somit mehrere geben und der Admin muss auch nicht 'ROOT' heissen!
Fuer die Rechte eines Benutzers gilt: Er hat immer die SUMME aller Berechtigungen. Also: local+users+alle Gruppen+er selber. Es gibt negative Rechte, aufpassen!! Ein Beispiel:
net access d:\ /add local:rx users:rx clabo:
bewirkt, dass alle User und das System ('local') selber auf D:\ lesend+aufuehrend zugreifen koennen, der User clabo darf dies nicht, da seine individuellen Rechte dem entgegenstehen und vom System hoeher als die Gruppenrechte behandelt werden.
2. Rechte im HPFS386 ( die Bits ), mehr als Linux hat:
Es gibt:
r: lesender Zugriff w: schreiben ( aendern ) aber nicht loeschen, auch EA's
x: ausfuehren ( nicht sinnvoll bei Vezeichnissen )
c: erstellen von Dateien und Ordnern
d: loeschen von Dateien und Ordnern
a: Attribute (AHSR) aendern
p: Permission Bit, wenn gesetzt darf der User das ACL aendern.
Nur Administratoren duerfen ACL's erstellen, User koennen dies nicht. Niemals und unter keinen Umstaenden! Admins haben IMMER alle Rechte, ein 'net access d:\config.sys /add root:' bringt also nix!
Warnung: Im deutschen GUI ( netgui.exe ) hat man die Bit's mit uebersetzt. Typische IBM-Dummheit, im FS stehen sie jedoch original drin!
ein 'net access d:\config.sys /add users:ls' gibt ein error, richtig ist 'net access d:\config.sys /add users:rw' Naja,... IBM halt.
Vielleicht noch: Das HPFS386 wird in \ibm386fs\hpfs386.ini konfiguriert. Lokal braucht dort keine Rechte, nichtmal Leserechte! HPFS386 unterstuetzt jetzt auch Wechselmedien, was sehr interessant ist. HPFS386 ist sehr empfindlich, also take care. Linux liest, glaube ich, das FS auch.
3. Lokale Sicherheit installieren
Lokale Sicherheit schliesst die KONSOLE, also den PM zum FS hin ab. Nicht die Prozesse selbet. OS/2 ist nicht Multiuser. Ein Prozess, der von ROOT gestartet wird kann von einem User abgeschossen werden ( ein Nachteil ), das Ganze gilt also im Speicher nicht! Ein Utility wie Kill und PS ( cd\addons ) sollte Usern also vorenthalten werden.
Die Konsole, also alle PM Prozesse, kann nur einem gehoeren! Eine Ausnahme sind nur die ROOT-Windows selber. Mehr dazu spaeter.
Local security wird durch ein Programm realisiert, welches in der, ja schreibgeschuetzten, config.sys gestartet wird:
- Mit Sicherheit: PROTSHELL=PFAD\SECURESH.EXE PFAD\PMSHELL.EXE
- Ohne waere : PROTSHELL=PFAD\PMSHELL.EXE
'PS' liefert dann auszugsweise:
** mit Sicherheit ** | ** ohne Sicherheit ** |
LANMSGEX.EXE | LANMSGEX.EXE |
SECURESH.EXE | |
PMSHELL.EXE | PMSHELL.EXE |
VDM ( EDIT.COM ) | VDM ( EDIT.COM ) |
NETMSG.EXE | NETMSG.EXE |
CMD.EXE | CMD.EXE |
PS.EXE | PS.EXE |
SSAVER.EXE | SSAVER.EXE |
Weitere ... | Weitere ... |
Also: Auf die config.sys aufpassen. Achtung: DAS Sicherheitsloch sind die BOOToptionen, in denen SECURESH.EXE ja nicht geladen wird. Von Hand nachtragen, damit ein boeser Bube dann auch dort mit einen Login konfrontiert wird. Dort auch hpfs.ifs gegen hpfs386.ifs ersetzen sonst nutzt es nichts!
4. Booten bei lokaler Sicherheit
Da gilt folgendes: Alle Prozesse oberhalb SECRESH.EXE sind 'ROOT'-Prozesse, alle unterhalb laufen auf USER-Level mit Ausnahme der Prog's die mit 'priv Befehl' vom Admin gestartet werden.
Falls niemand eingelogged ( angemeldet ) ist gilt:
Alle Rechte der Gruppe 'local'. Eine Konfiguration des Systems laeuft also auf die Gruppe 'local' hinaus. Bitte dem PM alle notwendigen Rechte via 'local' zuordnen, sonst geht's in die Hose, je nach dem. Beim Shutdown wird zuerst die Abmeldung durchgefuehrt, da die Server-Dienste gestoppt werden. Die OS/2-INI Dateien sollten also fuer local zugaenglich sein. Wenn sie es nicht sind koennen Aenderungen nicht gespeichert werden, auch nicht wenn der Admin selbst am System arbeitet da er ja abgemeldet wird. Ich habe sie nicht freigegeben, so kann eben NIEMAND was aendern ( Bei Anderungen dann Protshell aendern ).
Vorsicht bei Win/OS2: Ich betreibe eine Gruppe winuser, die die INI's schreibend aber nicht loeschend begluecken darf. Ein ganz simples 'net access drive:\os2\mdos /add local: users: winuser:rx' verhindert das die DOS und Windows Emulation von Usern, die nicht 'win-user' zugehoeren ausgefuehrt wird. Local wird also keine DOS Spiele betreiben und das System unnoetig blockieren. ( Aetsch !! ). Auch Netscape und Konsorten kann man so recht gut stoppen.
Ein hypothetischer Befehl auf eine Ressource:
'net access ressource /add local:rx users: data:rx'
macht folgenden Sinn: An der Konsole koennen alle User ('lokal') zugreifen, im Netz keiner ('users:', 'local' hat im Netz keine Rechte,) es sei denn er gehoert der Gruppe 'data' an, ich benutze diese Kombination bei meinem WEB Server mit Erfolg.
Es gilt folgende Hierarchie:
local: Kein User ist Mitglied, lokale Rechte wenn niemand angemeldet ist, hat keine Rechte im Netzwerk. Die Gruppe NIEMALS loeschen. O-Gott-o-Gott ....
users: Alle User sind Mitglied, Rechte gelten lokal UND im Netz
guests: Hab ich rausgeschmissen da unnoetig.
admins: Alle Administratoren. Lokal wie im Netz.
eigene Gruppen und User: Selbstdefiniert, Rechte Lokal und im Netz.
Ein uebles Thema ist: Rechte im FS koennen nur geandert werden, wenn der Requester laeuft ( bis dato keine andere Erkenntnis ), also muss MPTS oder Thinlaps laufen, zu gross fuer eine BOOTFLOPPY. Toll IBM.
Abhilfe: Service-Partition, somit koennen auch User basteln oder einfach vom Wechselmedium booten ( Removable Media FAQ, Kapitel 2 oder 3) User koennen den BOOT-Manager nicht modifizieren.
5. Hint's und Aerger
Je nach dem wer angemeldet ist, hat der PM andere Rechte gegenueber dem HPFS386. Wichtig ist: Sie koennten sich ja zur Laufzeit aendern !! Also alles Notwendige via 'local' vorgeben da das fuer JEDEN gilt. In die startup.cmd MUSS runpriv.exe eingetragen sein. Dieses Programm fuehrt ja dann \privinit.cmd aus.
=> In privinit.cmd werden ALLE Prozesse eingetragen, die ROOT Rechte brauchen, unabhaengig davon WER gerade angemeldet ist.
- folgende Tricks bei privinit.cmd gibts da:
start /N "RootShell" /PGM "cmd" startet z.B. eine ROOT-Shell
detach ftpd Startet den FTP Daemon als Root-Prozess, ein
Beenden geht ja nicht, der ROOT Prozess ist vor Usern also sicher, an das Window kommt keiner ran. Keine Netzbefehle in Runpriv.cmd eintragen, da die ROOT Rechte nur lokal und nicht im Netz gelten!
- Folgendes Beachten:
Das Szenario sei wie folgt: Du bist als Admin angemeldet. Ein 'start cmd' offnet eine Shell, die Admin Rechte hat. Wenn Du Dich abmeldest hat sie die Rechte von LOKAL, da PM seine Rechte aendert.
Soll der Prozess weiterhin privilegiert sein folgendes eingeben:
'priv cmd', dann bleibt er auch nach dem Abmelden privilegiert. Priv kann nur von einem Admin ausgefuehrt werden, bei Usern gibts: NET4910: Privilegierter Zugriff verweigert.
- TCP/IP Dienste wie NFS oder FTP brauchen ROOT-Rechte, da es ja unabhaengig von der Konsole, die ihre Rechte andern kann, bleiben soll. Also in privinit.cmd detachen damit niemand an's Window kommt.
Leider werkeln diese Dienste ausserhalb der Server User Datenbank, es ist also notwendig die Benutzer entsprechend zu konfigurieren.
- Beispiel FTPD.EXE:
Benutzer sind in %etc%trusers eingetragen, bekanntlicherweise auch die Passwoerter im Klartext was aergerlich ist. Wie folgt vorgehen:
FTPD als ROOT-Prozess detachen ( in privinit.cmd ) und trusers schuetzen: 'net access pfad\trusers /add users:' Somit kann niemand ( ausser dem Admin ) diese Datei von der Konsole oeffnen, FTP.EXE jedoch schon, da er ja detached als ROOT-Prozess laeuft. Der Trick funktioniert gut, allerdings gilt dann keine Quota, da FTP ein ROOT Prozess gegenueber dem HPFS386 ist ....
- ETC etc ... viel Trick viel Ehr. Irgendwie geht's immer.
6. Clients, insbesondere Windows
OS/2 braucht IMMER eine gueltige USER/PASSWORT Kombination, nicht wie Windows nur ein 'Passwort auf Freigabeebene'. Beim Start anmelden!
Fuer Win95 gibts einen speziellen IBM Client, ist auf der CD.
Linux Samba geht gut, USER und Passwoerter synchronisieren, TCPBeui installieren.