VonDoczuDoc.de

Hallo Meckelein,

nur zu, ich lerne gerne dazu...

Meckelein hat geschrieben:Der TM Client sieht einzig und allein einen FOS Server, mit dem er Programintern kommuniziert, also nur intern von Turbomed. Und zusätzlich sieht er eine Dateiablage, mit der er im SMB Protokoll redet. Dafür ist ja der Samba Server auf dem Linux System zuständig.

Das wäre wohl eine Kommunikation, die bei einem Linux-Server anders abläuft als bei einem Windows-"Server"?

Meckelein hat geschrieben:Was für die Arbeitsweise angepasst werden muss, dies aber nur auf Seiten der Programmierer und Admins, sind die Pfadangaben in der ptserver.cfg die sich im Ordner linux\config in der Netzwerkfreigabe befindet. Hierin müssen die Pfadangaben für den FOS als absoluter Pfad, also vom Wurzelverzeichniss aus gesehen, eingetragen werden und zwar wo genau sich die Datenstämme befinden. Da dies die Einstellungen für den FOS sind, müssen diese natürlich in der Notation erfolgen, wie der FOS diese sieht, also bei einem Linux System als Linux Pfadangaben. Aufgrund dieser Datei, also der ptserver.cfg, ist ganz genau definiert, wie der FOS an die benötigten Dateien und Datensätze heran kommt, die seinem NoSQL Datenmodel zugrunde liegen.

Diese "ptserver.cfg" liegt ja außerhalb des TurboMed-Ordners und würde durch den "Umzug" eines Solchen vom Windows-Server auf einen Linux-Server nicht tangiert. Haben Herrn Geigenbergers Schwierigkeiten der Client-Server-Kommunikation mit dieser Datei zu tun? Haben Sie gemeint, dass "Serverbetriebssystem ist Linux" nur auf den Clients auf "Ja" gesetzt werden muss (habe aber Ihren Beitrag von 14:26 anders verstanden)? Denn die Zugriffsmöglichkeit auf die Grundeinstellungen via Startmenü kenne ich nicht von Linux - insofern können Sie darüber doch nur Einstellungen an den Clientrechnern ändern.

Meckelein hat geschrieben:Mal so als kleines Beispiel ein Auszug aus der ptserver.cfg:
Code: Alles auswählen
[schemata\PraxisDict]
name=/opt/samba-freigabe/intern/turbomed/Dictionary
[databases\PraxisDB]
name=/opt/samba-freigabe/intern/turbomed/PraxisDB
[databases\PraxisBackup]
name=/opt/samba-freigabe/intern/turbomed/PraxisDB/Backup
Hiermit wird der Weg der Übersetzung wie folgt beschrieben. Wenn der Client Informationen aus dem Bereich der PraxisDict benötigt, dann findet der FOS das dazugehörige Inhaltsverzeichniss unter name=/opt/samba-freigabe/intern/turbomed/Dictionary. Zusätzlich muss er, um die Anfrage komplett ausführen zu können, noch die Datenbank PraxisDB unter name=/opt/samba-freigabe/intern/turbomed/PraxisDB befragen. Ein Pfad zu den Backups der Datenbank ist auch noch angegeben.

Diese Angaben sind aber aus der Sicht des FOS zu sehen und haben hierdurch nichts mit dem Client zu tun. Die local.ini beinhaltet nur Informationen für den Betrieb des Clients also Fenstereinstellungen und Datenpfade, sowie als wichtigstes die Informationen wo der Server zu finden ist. Da der Client aber Ausnahmslos unter Windows läuft, sind hierin auch nur Windows Pfade anzugeben. Man muss hier nichts automatisiert per Script einstellen. In der global.ini befinden sich hingegen nicht mal Pfadangaben, wenn man mal die Backup Pfade erstmal aussen vor lässt. Daher muss auch hier absolut und rein garnichts an ein etwaiges Linux System angepasst werden.

Mein Bericht über die Umgangsformen von TurboMed mit den Lokal.ini und Global.ini bezog sich ja auf Windows-Systeme bzw. auf das Updaten von TurboMed auf diesen...

Meckelein hat geschrieben:So, bleiben noch die Pfadangaben für Spiegelung und Backup.

Diese wirken sich nur auf den lokalen Rechner aus, Sie können also an jedem Client eine eigene Sicherungs-Art erstellen. An einem Client auf die Festplatte und alle Sicherungen behalten, an einem anderen auf USB–Stick und nur die Sicherungen von x Tagen behalten, Dokumente-Sicherung an einem Client komplett, am anderen definierter oder frei wählbarer Zeitraum...

Meckelein hat geschrieben:Man sieht also, ausserhalb des Linux Systems sind keine automatisierten oder geskripteten Anpassungen der Einstellungen vonnöten. Besser gesagt, man muss nichts einstellen, bis auf das, was man auch mit einem Windows Server einstellt, nämlich die IP des Servers und den absoluten Pfad zur Freigabe, vom Client aus gesehen, also in Windows Notation.

Also bleibt noch offen, was der ominöse Schalter bewirkt...

Gespannt auf Weiteres: Wahnfried

Hallo wahnfried,

nunden, dann noch einige zusätzliche Infos

Ich weisse vorsorglich nochmal darauf hin, alle Infos habe ich mir selber zusammen gearbeitet, daher kann es zu Ungenauigkeiten kommen. Leider war es mir bislang nicht möglich, klare Aussagen sowohl von CGM zu bekommen.

wahnfried hat geschrieben:Das wäre wohl eine Kommunikation, die bei einem Linux-Server anders abläuft als bei einem Windows-"Server"?

Die Kommunikation zwischen dem TM Client, der immer unter Windows arbeitet, und dem FOS, in diesem Fall immer auf einer Linux Maschine, unterscheidet sich in keinster Weise von der Kommunikation die zwischen einem TM Client und einem Server unter Windows stattfindet. Der Client "redet" immer in der Sprache die das TM selbst beinhaltet, diese wurde von den Mitarbeitern von CGM entwickelt und programmiert. Der Datenaustausch findet immer über das SMB Protokoll statt, siehe Wikipedia. Einzig die Kommunikationspartner wechseln einseitig. Bei einem Windows Server kümmert sich das Windows Betriebssystem selber um die SMB Kommunikation. Bei einem Linux Server wird hierfür das zusätzliche Programpacket Samba benötigt. Dieses Übersetzt das SMB Protokoll in einer Form, dass der zugrunde liegende Linux Kernel etwas damit anfangen kann.

wahnfried hat geschrieben:Diese "ptserver.cfg" liegt ja außerhalb des TurboMed-Ordners und würde durch den "Umzug" eines Solchen vom Windows-Server auf einen Linux-Server nicht tangiert.

Die "ptserver.cfg" liegt nicht zwingend ausserhalb des TurboMed-Ordners, der eigentliche Speicherplatz auf dem Linux Server ist beliebig. Der genaue Pfad muss aber dem FOS auf dem Linux Server bekannt gegeben werden, dies geschieht in der Datei "poetd" mit welcher der FOS gestartet und gestoppt werden kann mittels "pt_cfg="/opt/turbomed/linux/config/ptserver.cfg". Der hier angegebene Speicherort ist die Einstellung die CGM in seinen eigenen Scripten verwendet. Man sieht also, dass hierdurch die "ptserver.cfg" im Pfad der Samba Freigabe angegeben wurde. Dieser Pfad wird aber durch ein kopieren der vorhandenen Daten in einer Freigabe eines vorhandenen Windows Server auf einen neuen Linux Server nicht überschrieben. Durch die Installation wird nämlich u.a. ein Ordner "linux" im TM Freigabe Verzeichniss angelegt, worin alle benötigten Dateien liegen.

wahnfried hat geschrieben:Haben Herrn Geigenbergers Schwierigkeiten der Client-Server-Kommunikation mit dieser Datei zu tun?

Dies ist nicht zu beantworten, da ich leider nicht weiss wie das System von Hr. Geigenberger komplett aussieht. Hierzu müsste man alle Dateipfade in allen Konfigurationsdateien vom TM sowie das zugrunde liegende System überprüfen. Dafür fehlt mir aber leider die Zeit

wahnfried hat geschrieben:Haben Sie gemeint, dass "Serverbetriebssystem ist Linux" nur auf den Clients auf "Ja" gesetzt werden muss (habe aber Ihren Beitrag von 14:26 anders verstanden)? Denn die Zugriffsmöglichkeit auf die Grundeinstellungen via Startmenü kenne ich nicht von Linux - insofern können Sie darüber doch nur Einstellungen an den Clientrechnern ändern.

Man kann mittels des Startmenüeintrags Grundeinstellungen auf den Clients die Einstellungen von TM komplett ändern. Das darauf folgende Fenster beinhält sowohl Einträge aus der lokal.ini als auch der global.ini. Diese Dateien werden bei der Installation des TM Client selber angelegt und mit den benötigten Grundeinstellungen geschrieben. Anders als gedacht, sind diese Dateien nicht Inhalt der TM Server Installation auf einem Linux System. Auch Änderungen an den global.ini und local.ini die sich in der Freigabe des Servers befinden, werden nicht bei Programmstart von TM an die Clients selber übertragen. Diese Dateien haben also nur für den TM Client selber eine Bedeutung und nicht für den Server. Da bei Installation des TM Servers auf einer Windows Maschine auch die Software für den Client automatisch mit installiert wird, sind diese Dateien hier also zu finden.
Dies bringt die auch für mich neue Erkenntniss, dass Änderungen an der local.ini sowie an der global.ini nur Auswirkungen auf den TM Client haben auf dem diese Änderungen durchgeführt wurden. Hieraus folgt auch wieder, dass diese Dateien nur durch die TM Eigene Setup Routine für den Client erzeugt werden sollten und Änderungen hieran nur durch die Tools von TM selber durch zu führen sind. Ansonsten kann es u.U. zu Problemen bei Updates o.ä. kommen, wenn CGM meint etwas wichtiges darin zu verändern.

Noch ein Wort zur "ptserver.cfg". Diese Datei ist einzig und alleine wichtig für den FOS, damit dieser, auf dem Server, seine Ordner und Pfade findet in welchen die Datenbanken liegen.

Und um das Grundätzlich nochmals zu verdeutlichen. Der TM Client läuft nur unter Windows. Dieser kommuniziert mit dem FOS über das Netzwerk. Der FOS läuft sowohl unter Windows als auch unter Linux. Wenn der FOS auf einem Windows System installiert wird, wird zusätzlich der TM Client mit installiert. Bei einem Linux System nicht da, wie wir ja wissen, der TM Client nur unter Windows läuft. Die Kommunikation zwischen Client und FOS läuft über die Sprache die CGM Extra für den TM programmiert hat. Die Übertragung von grösseren Datensätzen, also z.B. eingescannte Dokumente, läuft über das SMB Protokoll. Dies gilt natürlich auch, wenn man mit dem TM Client arbeitet der auf einem Windows Gerät installiert ist, das gleichzeitig auch den FOS beinhält. Auch hier muss man abstrahiert den Client als eigenständiges System sehen, auch wenn sowohl Client und FOS auf dem gleichen physikalisch vorhandenen Gerät ausgeführt wird.
Über die Vor- und Nachteile dieser vorgehensweise brauchen wir bitte in keinster Weise anfangen zu diskutieren. Wir können daran nichts ändern und die Diskussion wurde vor etlichen Jahren von den Programmierern übernommen, die sich schon was dabei gedacht haben. Wir müssen dies also als gegeben hinnehmen.

So, das war jetzt wieder mal eine Menge an schwer verdaulichen Informationen, hoffe es hat jeder Spass daran

Grüsse

Alexander Meckelein

Hallo Herr Meckelein,

ich habe nun gelernt, dass das SMB-Protokoll nicht spezifisch für Samba ist, danke.
Ansonsten beschreiben wir beide die Angelegenheiten der Grundeinstellungen zwar mit anderen Worten, aber m.E. von der Sache her gleich.

Allerdings ist die Veränderungsmöglichkeit der Grundeinstellungen via Menüaufruf (egal ob über Windows-Startmenü oder über das TurboMed-Hauptmenü) nur eine schöne GUI zur Veränderung der beiden lokalen Dateien Local.ini und Global.ini, die in dem Verzeichnis stehen, das in der Windows-Startverknüpfung unter "Ausführen in:" angegeben ist. Diese sorgt im Wesentlichen dafür, dass man nichts Unsinniges in Local.ini/Global.ini einträgt.

Diese beiden Dateien per Editor am Client-Rechner zu verändern (wenn man weiß, wie die veränderten Begriffe in den geschweiften Klammern heißen müssen) ist von der Auswirkung identisch. "ja"/"nein" und "j"/"n" scheint beides zu gehen. Im Zweifel kann man nach Veränderung via Grundeinstellungs-Menüpunkt ja nachschauen, wie der Begriff dann heißt, oft sind es Zahlen-Codes. Nicht verändert werden dürfen die Begriffe außerhalb der geschweiften Klammern (außer "theoretisch" Löschen ganzer Zeilen). Insofern ist eine Anpassung der Grundeinstellungen per Editor oder Script nicht gefährlich. Wenn man etwas Falsches oder Unsinniges eintragen würde, nimmt TurboMed wieder die Default-Einstellung (außer, wenn der falsch eingetragene Begriff wirklich als erwartete Auswahl existiert) - und bei einer ganz frischen DEMO-Installation steht recht wenig in den Dateien drin (daher meine Vorstellung, dass TurboMed dann einfach eine Default-Einstellung benutzt). Die meisten Veränderungen sind sofort durch Aufrufen der Grundeinstellungen überprüfbar - manchmal habe ich aber den Eindruck, dass TurboMed das via "Grundeinstellungen" Veränderte intern protokolliert und erst bei Benutzerwechsel oder Abmeldung zurückschreibt.

Da aber die Local.ini und Global.ini sich wirklich nur lokal auswirken (warum nur der Begriff "Global"?) kann man diese Dateien auf einem Linux-Server NUR per Editor oder Script verändern. Aber vielleicht ist dort eine Anpassung gar nicht erforderlich, weil a) das TurboMed-Installationsscript die passenden EInträge erzeugt (dann gäbe es aber evtl. Probleme mit "herüberkopierten" Dateien Local.ini/Global.ini bei komplett übernommenem TurboMed-Ordner vom WIndows-Server) - oder b) unter Linux würden diese Dateien in "opt/turbomed/programm" ignoriert...?

Das ist allerdings eher eine Frage an die altgedienten Linux-TurboMed-ler wie mölli usw.: Ist es egal, was in "opt/turbomed/programm" in den Local.ini/Global.ini drin steht oder muss man sich darum kümmern, wenn man den TurboMed-Ordner vom Windows-Server nach Linux umzieht?

Grüsse, Wahnfried

p.s.: wenn ich hier mehr Laien-Sprachgebrauch auftische, ist das nicht als Hindernis gedacht, sondern ggfs als "Schnittstelle" zu den anderen Lesern, die sich vermutlich auch nicht IT-mäßig mit Linux auseinandergesetzt haben...

Hallo,

ich hab vor dem Wochenende mal die Scripte, die smb.conf und das Readme überarbeitet. Den "testing" Zweig bei github habe ich heute mit dem "master" Zweig zusammengeführt da die Scripte nun "stable" sind

Zusätzlich habe ich noch ein neues Virtualboximage erstellt, das grade auf meinen GDrive Account hochgeladen wird. Es handelt sich hierbei um ein "untouched" Ubuntu Server Image lediglich mit dem Zusatzpaket "unzip" und den Updaterscripten für den Installer. Es hat nur schlanke 520MB und ist natürlich noch einen guten Ticken schneller als das wesentlich größere Desktopimage

.

Damit sollte es jeder hinkriegen in ca. 15 Minuten einen laufenden TM Linux Server einschließlich funktionierendem Samba zu installieren. In dem Readme das man bei github einsehen kann werden die notwendigen Schritte erklärt --> https://github.com/elvito/tm-linux-server-installhelper

leider habe ich nicht genug Platz auf meiner SSD dass ich unser komplettes Praxisbackup dort einspiele, deswegen wäre es nett wenn jemand mal den TM Server mit seinem Backup testen könnte.

schönen Gruß
elvito

Hallo wahnfried,

ja ich glaube wir reden gerade komplett aneinander vorbei. Ich Versuchs daher nochmal. Sowohl die local.ini als auch die global.ini haben nur bewandtniss für den TM Client der lokal auf dem PC unter Windows ausgeführt wird. Alle Einstellungen in diesen Dateien sind nur für den Client von interesse. Der Client holt sich diese Einstellungen auch nicht vom Server, sondern Ausnahmslos aus seinem eigenen Installations Ort unter dem Ordner Programme.

Es gibt überhaupt keine Notwendigkeit von Seiten des Servers an diesen Dateien etwas zu machen oder per Script die Einträge in den Dateien zu ändern. Egal wie einfach das sein mag

Man muss nur folgendes befolgen:

- Bei Installation des TM Clients dies auch im Setup entsprechend auswählen und die IP des Servers eintragen
- Nach Abschluss der Installation, das Häckchen raus bei "Einführung starten" und erstmal den Startmenüeintrag "Turbomed Grundeinstellungen" ausführen
- hier unter "Verzeichnisse", Untermenüpunkt "Turbomed" unter "Server" die IP nochmal kontrollieren
- das Häckchen setzen für "Serverbetriebssystem ist Linux" wenn es so ist
- und bei "Serverpfad" sich zur Freigabe auf dem Server durchklicken oder den kompletten Netzwerkpfad von Hand eintragen

Und schon ist die Installation fertig.

Ja ich gebe Ihnen Recht, man könnte diese Einstellungen in angepassten local.ini und global.ini Dateien auf dem Server schon erstellen. Dann müsste man aber von Hand diese beiden Dateien bei jeder Client Installation vom Server an die richtige Stelle am Client kopieren. Das Turbomed macht das nämlich nicht automatisch, so schlau isses einfach nicht.

Und nochmal zur Verdeutlichung, die Dateien local.ini und global.ini existieren schlicht und erfreifend nicht auf einem Turbomed Server unter Linux. Ich habe das komplette Archiv für Linux von CGM durchsucht, inklusive der darin enthaltenen Unterarchive und mir jedes Script angeschaut, das laut CGM für die Installation des TM Servers unter Linux ausgeführt werden muss. Nirgendwo ist ein Hinweis auf die local.ini und global.ini zu finden. Zusätzlich habe ich geschaut, welche Dateien sich auf dem Server ändern, nachdem mehrere TM Clients installiert und ausgeführt wurden. Es wurde durch keinen dieser Vorgänge eine local.ini oder eine global.ini auf dem Server selber erzeugt. Diese Dateien haben absolut keine Auswirkungen auf den Server und zwar weder auf den Linux noch auf den Windows Server. Sie werden nur vom Client benötigt und da auch nur lokal.

Ich bitte hiermit jeden der das liesst und sich das zutraut, ich übernehme natürlich keine Haftung wenn etwas schief geht

Gehen Sie in Ihre Serverfreigabe egal ob Windows oder Linux, durchsuchen Sie alle Unterordner vom turbomed nach der local.ini und global.ini und bennen diese um. Ich selber hänge immer ein .org für Original mit hinten dran. Und jetzt starten Sie das Turbomed an einem beliebigen Client im Netzwerk und teilen mir mit was sich alles nicht verändert hat

Einzig das arbeiten mit dem Turbomed auf dem Server selber wird nicht mehr ohne Fehlermeldung möglich sein. Ach ja, Leute mit Terminalserver sollten hier bitte unter allen Umständen erst Ihren Admin Fragen bevor Sie etwas machen.

Meckelein hat geschrieben:ja ich glaube wir reden gerade komplett aneinander vorbei.

...und ich finde das schade

(ich habe nämlich versucht, mich klar auszudrücken (im Sinne von Verständlichkeit auch für PC-Laien), bin aber vielleicht noch grippal eingeschränkt?

Meckelein hat geschrieben:Sowohl die local.ini als auch die global.ini haben nur bewandtniss für den TM Client der lokal auf dem PC unter Windows ausgeführt wird. Alle Einstellungen in diesen Dateien sind nur für den Client von interesse.

Das stimmt nicht ganz, denn beim Update einer TurboMed-Serverinstallation unter Windows sind bestimmte Einstellungen in der Local.ini erforderlich, damit das nächste Update auf diesem Windows-PC mit TurboMed-Serverfunktion problemlos läuft (siehe weiter unten).

Worum es mir aber eigentlich ging:
Am WIndows-Server kann ja auch TurboMed als Arbeitsplatz laufen - und deswegen hat JEDER Windows-Server auch seine Local.ini/Global.ini. Und wer mit seinem Windows-Server zu Linux per Kopieren umzieht (was ja hier bereits mehrfach als Methode vorgeschlagen wurde) kopiert dann ja auch die auf dem Windows-Server existierende Local.ini/Global.ini mit. Und meine Grundfrage war ja, ob diese dann dort "auf Linux" Schwierigkeiten machen (weil darin ja vermutlich noch ein anderer PC-Name/IP/Serverpfad drin steht und insbesondere - das dann allerdings in der Global.ini verankert - daß das Server-Betriebssystem KEIN Linux sei...)

Meckelein hat geschrieben:Der Client holt sich diese Einstellungen auch nicht vom Server, sondern Ausnahmslos aus seinem eigenen Installations Ort unter dem Ordner Programme.

Ich erinnere mich nicht, dies (erster Halbsatz) postuliert zu haben - Ihr zweiter Halbsatz ist dagegen falsch, was das "Ausnahmslos" betrifft. TurboMed-"Standard" macht es generell so - aber es geht auch ganz anders! Das geniale JRR-Moduswechselsystem basiert genau darauf, dass die Lokal.ini/Global.ini von jedem anderen Speicherort verwendet werden können - man muss nur den Aufruf der "Turbomed.exe" von diesem "anderen Speicherort" aus organisieren, indem man in der zugehörigen Startverknüpfung unter "Eigenschaften: Verknüpfung" und dort "Ausführen in:" diesen abweichenden Speicherort eingibt. Das ist natürlich wieder WIndows-spezifisch, da der Client ja nur auf WIndows läuft. Dass sich Client-Rechner die Local.ini/Global.ini vom Server holen würden, hatte hier noch keiner behauptet.

Meckelein hat geschrieben:Es gibt überhaupt keine Notwendigkeit von Seiten des Servers an diesen Dateien etwas zu machen oder per Script die Einträge in den Dateien zu ändern. Egal wie einfach das sein mag

Gut, das würde meine eigentliche und insbesondere an mölli gerichtete Frage beantworten, ob ggfs TurboMed diese Dateien auf einem Linux-Server ignoriert (egal welcher Inhalt).
Mein VM-geeigneter PC hat mich vor einiger Zeit versetzt und wartet noch auf Restaurierung (in dem Fall Installation von Ubuntu 64bit und dann VBox... wenn s¢hon, denn schon), daher kann ich die Serverinstallation in den von Ihnen und elvito angegebenen Varianten bisher leider nicht praktisch nachvollziehen. Kommt aber bald... ;–) zur Zeit noch kein Drive für Nachtarbeit...

Meckelein hat geschrieben:Ja ich gebe Ihnen Recht, man könnte diese Einstellungen in angepassten local.ini und global.ini Dateien auf dem Server schon erstellen. Dann müsste man aber von Hand diese beiden Dateien bei jeder Client Installation vom Server an die richtige Stelle am Client kopieren. Das Turbomed macht das nämlich nicht automatisch, so schlau isses einfach nicht.

Es geht mir überhaupt nicht darum, auf dem Server irgendwelche Dateien für Client-Rechner vorzubereiten - das ist jetzt ein Anteil Ihrerseits zum "aneinander vorbeireden".

Meckelein hat geschrieben:Und nochmal zur Verdeutlichung, die Dateien local.ini und global.ini existieren schlicht und erfreifend nicht auf einem Turbomed Server unter Linux. Ich habe das komplette Archiv für Linux von CGM durchsucht, inklusive der darin enthaltenen Unterarchive und mir jedes Script angeschaut, das laut CGM für die Installation des TM Servers unter Linux ausgeführt werden muss. Nirgendwo ist ein Hinweis auf die local.ini und global.ini zu finden.

Das ist eine wichtige Aussage

Meckelein hat geschrieben:Zusätzlich habe ich geschaut, welche Dateien sich auf dem Server ändern, nachdem mehrere TM Clients installiert und ausgeführt wurden. Es wurde durch keinen dieser Vorgänge eine local.ini oder eine global.ini auf dem Server selber erzeugt.

Das hatte ich auch nie erwartet.

Meckelein hat geschrieben:Diese Dateien haben absolut keine Auswirkungen auf den Server und zwar weder auf den Linux noch auf den Windows Server. Sie werden nur vom Client benötigt und da auch nur lokal.

Was den WIndows-Server betrifft, ist Ihre Aussage falsch, ausgenommen die reine laufende Server-Funktion. Ohne die Angabe in der Lokal.ini "Mehrplatzbetrieb = ja" und "Server = <lokaler PC-Name oder lokale IP>" gilt eine TurboMed-Installation unter Windows eben nicht als Server für TurboMed - beim Update würde es dann gehörig Schwierigkeiten geben. Nur bei dieser Einstellung wird der FOS auf einem Windows-PC beim TurboMed-Start zu starten angemahnt, falls er noch nicht läuft, und beim Update automatisch beendet und nach dem Update wieder gestartet - und nur mit dieser Einstellung werden die Daten der Update-DVD während des Updates ins Verzeichnis "netsetup" des "Servers" kopiert - und nur mit dieser Einstellung werden die Ordnerfreigaben beim Update neu zu erzeugen angeboten, falls verlorengegangen (z.B. durch Kopieren des TurboMed-Ordners und Weiterarbeiten mit der umbenannten Kopie).

Meckelein hat geschrieben:Ich bitte hiermit jeden der das liesst und sich das zutraut, ich übernehme natürlich keine Haftung wenn etwas schief geht
Gehen Sie in Ihre Serverfreigabe egal ob Windows oder Linux, durchsuchen Sie alle Unterordner vom turbomed nach der local.ini und global.ini und bennen diese um. Ich selber hänge immer ein .org für Original mit hinten dran. Und jetzt starten Sie das Turbomed an einem beliebigen Client im Netzwerk und teilen mir mit was sich alles nicht verändert hat Einzig das arbeiten mit dem Turbomed auf dem Server selber wird nicht mehr ohne Fehlermeldung möglich sein. Ach ja, Leute mit Terminalserver sollten hier bitte unter allen Umständen erst Ihren Admin Fragen bevor Sie etwas machen.

Da haben Sie recht: der FOS, sofern als Dienst eingerichtet, läuft sogar schon vor einer Benutzeranmeldung am Windows-"Server", so dass Client-Rechner darauf zugreifen können. Sie können die lokale TurboMed-Installation jedoch ohne die vorhin angegebenen Einstellungen in der Local.ini nicht als Serverinstallation updaten - müssen dann das Beenden und Neustarten des FOS-Dienstes für das Update auf andere Art sicherstellen und beim Update jeden einzelnen PC vom lokalen opt.Laufwerk per DVD updaten, weil das "netsetup"-Verzeichnis nicht mit den frischen Update-Daten gefüllt wird - ggfs stattdessen sogar noch die Daten einer Vorversion konserviert (und dann sogar zur Installation auf den Client-Rechnern anbieten würde!).

Man kann ja sogar an einem als Client des Hauptservers arbeitenden PC bei laufendem FOS eine differierende PraxisDB zur Verfügung stellen und die anderen Client-Rechner incl. den lokalen Arbeitsplatz auf dem Windows-"Server" für TurboMed per Moduswechsel auf die beiden unterschiedlichen PraxisDB's zugreifen lassen, (Hier zeitweise so realisiert zum Blick auf den alten Datenstand zum Ende einer Gemeinschaftspraxis-Phase). Da musste ich dann aber auch vor einem Update an diesem Rechner den FOS manuell beenden und nach dem Update wieder manuell starten....

ZUSAMMENFASSUNG:

- Local.ini und Global.ini würden originär per TurboMed-Script auf einem Linux-Server für TurboMed gar ni¢ht erst erzeugt.
- Wer eine Local.ini und eine Global.ini beim Kopieren des TurboMed-Ordners von einem Windows-Server auf einen Linux-Server mit-kopiert, hat deswegen keine Schwierigkeiten - diese Dateien sollten von TurboMed ignoriert werden. Ein Verändern oder Löschen dieser Dateien sollte keine bei der Client-Kommunikation mit dem Linux-Server bestehenden Probleme ausräumen - da müssen die Ursachen anderswo gesucht werden.
- Die Kommunikation zwischen den TurboMed-Client-Insŧałlationen und dem FOS wie auch den Dateifreigaben per SMB–Protokoll unterscheidet sich nicht zwischen Server auf Windows bzw. Server auf Linux
- Die Funktion des Schalters in der Global.ini "Serverbetriebssystem ist Linux" bleibt daher weiter unklar.

Grüsse, Wahnfried

p.s.: Mit dem Bereich Local.ini/Global.ini und Umstellen von TurboMed als Einzelplatz-/Client-/Server-Installation auf Windows-PC kenne ich mich so gut aus, da ich vor etwa 7 Jahren hier weitgehend das erste praktikable Moduswechselsystem entwickelt habe. Das ging damals aber erst nur als Wechsel zwischen zwei definierten Modi (Client-Einzelplatz, Umstellen zum Server bei EInzelplatz-Funktion aber dann "per Hand" kein Problem meħr). JRR's Erkenntnis in Form des "allereinfachsten Moduswechselsystems" per Start-Ausführung je Modus in einem modusspezifischen Ordner hat mich dann rasch überzeugt, so dass ich das alte System nur nochmal für den Verordnungs-Modus-Umschalter umgebaut habe.

Die Leute hier im Forum verstehen mich sonst eigentłich ganz gut, vermutlich schreibe ich nicht genug IT-konform?

W.

Ja, jetzt ist bei mir der Groschen gefallen. Wir reden aneinander vorbei wenn es um den Server geht. Ich unterteile das komplette System in andere Komponenten als Sie, da kommt bei mir einfach der ITler durch

Um das zu verdeutlichen, wenn ich vom Server rede, dann meine ich damit in erster Linie den FOS und nichts anderes. Und wenn ich vom Client rede, dann meine ich den TM Client, also die Oberfläche. Ich abstrahiere die Systeme mehr als alle anderen hier. Für mich existieren folgende Systeme, ausgehende von einem physikalisch vorhandenen Computer:

Computer 1 - Serversystem mit Windows Server Betriebssystem
- FOS, also Fast Objects Server
- TM Client, also die Oberfläche mit der gearbeitet wird
- Netzwerk-Kommunikation, in diesem Fall Windows intern über das SMB Protokoll

Computer 2 - Serversystem mit Linux Betriebssystem
- FOS
- Samba, für Kommunikation über das SMB Protokoll

Computer 3 - Windows Einzelplatz System mit z.B. Windows 7 Home Premium oder Windows 7 Professional
- TM Client, also Oberfläche zum Arbeiten
- Netzwerk-Kommunikation, in diesem Fall Windows intern über das SMB Protokoll

Ich muss das so weit abstrahieren, da für mich noch eine ganze Reihe weiterer Teile zu einem kompletten System gehören, z.B. DHCP, AntiVir, E-Mail, FTP, SSH usw. usf. Ich würde einfach darum bitten, die Systeme in Zukunft klar zu benennen, natürlich gilt das auch für mich selber, muss mich ja auch immer wieder verbessern

Wir hätten da also den FOS (unabhängig vom Betriebssystem), dann den TM Client (läuft nur unter Windows), den Samba (SMB Protokoll Dienst unter Linux) und dann natürlich noch so Begriffe wie Computer und Server

Als Endeffekt davon muss man sagen, die global.ini und local.ini haben für den FOS keine Bewandtniss auch nicht im Bereich des Updates. ABER bei jedem Update eines Linux Systems, wird, zumindest von meinen Scripten, das Client Update in den NetSetup Ordner auf dem Linux Server extrahiert und muss von dort auf jedem Client ausgeführt werden, bei einem Windows Server wird das automatisch vom Update erledigt, wie Sie ja schon sagten. Hierdurch werden die lokalen TM Installationen geupdates (oh wie ich dieses Wort hasse

. Im Anschluss muss an einem Client das TM gestartet werden und in diesem der Update der Datenbank auf dem Linux Server durchgeführt werden. Der Client meckert zwar jedes mal, dass das nicht über eine Netzwerkverbindung gemacht werden soll, weil es sonst länger dauert, aber bei einem GBit Netzwerk interessiert mich das nicht. Bislang war jedes Update der Datenbank in wenigen Minuten erledigt. Dies muss natürlich nur einmal an einem beliebigen Client durchgeführt werden. Damit das funktioniert, muss natürlich in den, auf dem Client vorhandenen, local.ini und global.ini die Pfade zum Server drinnen stehen. Diese Einstellungen werden aber auf dem Client durch das vorher durchgeführte Update nicht überschrieben.

Mit den Moduswechseln hab ich mich selber noch nicht beschäftigt, da ich es bislang nicht gebraucht habe. Ich habe es nur mal überflogen um zu wissen was möglich ist und dann wieder vergessen, muss ich zu meiner Schande gestehen. Ich freue mich auch in diesem Bereich wieder mehr gelernt zu haben. Das ist so ein innerer Drang von mir, immer alles verstehen zu wollen und noch mehr zu lernen. Muss mich aber auch immer wieder zusammen reissen, sonst mach ich zu viele Sachen parallel und dann gehts in die Hose

Ich freue mich sehr darauf, weitere Informationen von Ihnen zu erhalten um mein eigenes Bild über Turbomed zu erweitern

Danke für alles bisher.

Grüsse, Alex

Meckelein hat geschrieben:Ja, jetzt ist bei mir der Groschen gefallen. Wir reden aneinander vorbei wenn es um den Server geht. Ich unterteile das komplette System in andere Komponenten als Sie, da kommt bei mir einfach der ITler durch

...toll, dass wir das nun herausgefunden haben.

für uns DAU's ist ein Server eben doch etwas Physisches - beim DIenst-Personal würden wir es ja auch nicht akzeptieren, wenn diese nur virtuell saubermachen würden

Wobei ich mich bereits bemüht habe, durch Setzen von Anführungszeichen beim Begriff "Server" zu signalisieren, dass damit ein "Normal-PC" mit Serverfunktion für TurboMed gemeint sei und kein "dedizierter" Server.

Insofern würde ich meine Zusammanfassung umformulieren:

- Local.ini und Global.ini würden originär per TurboMed-Script auf einem Linux-Betriebssystem mit FOS als Server für TurboMed während der Erst-Installation und Updates von TurboMed gar nicht erst erzeugt.
- Wer eine Local.ini und eine Global.ini beim Kopieren des TurboMed-Ordners von einem Windows-PC mit Serverfunktion für TurboMed auf einen Linux-PC mit-kopiert, hat deswegen keine Schwierigkeiten - diese Dateien sollten von TurboMed auf der Linux-Maschine ignoriert werden. Ein Verändern oder Löschen dieser Dateien sollte keine bei der Client-Kommunikation mit dem Linux/FOS-Server bestehenden Probleme ausräumen - da müssen die Ursachen anderswo gesucht werden.
- Die Kommunikation zwischen den TurboMed-Client-Insŧałlationen und dem FOS wie auch den Dateifreigaben per SMB–Protokoll unterscheidet sich nicht zwischen Server unter Windows bzw. Server unter Linux
- Die Funktion des Schalters in der Global.ini "Serverbetriebssystem ist Linux" bleibt daher weiter unklar.

Kann man das so als "sehr wahrscheinlich korrekt" als Basis für weitere Klärungen nehmen?

Habe nun aber mal (da das Wochenende begonnen hat) einen TurboMed-Client im reinen WIndows-XP-peer2peer-Netzwerk manipuliert und in den Grundeinstellungen "Serverbetriebssystem ist Linux" bejaht.

Die Netzwerk-Kommunikation mit dem FOS auf meinem Windows-PC mit Server-Funktion für TurboMed wird dadurch nicht beeinträchtigt. Lediglich beim ersten Neustart von TurboMed kam auffällig häufig nacheinander - mindestens 5 mal - die Mitteilung, dass TurboMed auf diesem PC noch laufen würde und insofern das zuletzt gestartete TurboMed beendet würde (also einer der dafür sensiblen Prozesse betr. TurboMed/Ifap noch nicht beendet, natürlich lief TurboMed nicht mehr...), was ich bisher (seit Jahren...) immer nur maximal 1x gesehen habe. Dann startete TurboMed aber normal durch - m.E. selbst bei wiederholtem Start etwas langsamer als gewohnt. Das "...läuft bereits" ließ sich aber bei folgenden Neustarts von TurboMed nicht nochmals provozieren. Habe auch den Eindruck, dass einige Aufruf-Funktionen durch diese Manipulation geringfügig langsamer ablaufen - nach Zurückstellen auf "...ist Linux: NEIN" ist der TurboMed-Start wieder deutlich weniger langsam, evtl. auch wieder geringe Beschleunigung beim Aufrufen der F3 usw.

Insofern noch für die Zusammenfassung:

- Der Schalter "Serverbetriebssystem ist Linux" scheint im reinen WIndows-Netzwerk keine wirkliche Störung der Kommunikation zwischen TurboMed-Client und FOS zu bewirken, falls hier fälschlich "ja" eingetragen wird.

Grüsse, Wahnfried

p.s.: war das besser/klarer?? W.

Hallo,

kann mir jemand sagen ob das Turbomed in der VM funktioniert wenn man das eigene Backup dort einspielt? Ich würde mich dann als nächstes iptables und einem Backupkonzept widmen. Das Image Ubuntu Server ist übrigens mit LVM aufgesetzt, d.h. hier sind auch Snapshots der TM Datenbank im laufenden Betrieb möglich (http://www.thomas-krenn.com/de/wiki/LVM_Snapshots)

vielen Dank im voraus

@meckelein
wegen dem Thema der local.ini und global.ini... ich denke schon das es sinnvoll ist die beiden Dateien dynamisch zu verändern und für die Clients via samba anzubieten. Das Einspielen der beiden Dateien auf den Clients kann man ganz leicht mit einer Batchdatei realisieren, die dann ebenfalls auf dem Sambashare liegt und vom entsprechenden Client nur angeklickt werden muss. Damit kann jeder seinen Server benennen wie man will und auch die Sambashares individuell benennen (auch ein nachträgliche Änderungen würden sich so machen lassen). Ich sehe sonst keine andere Möglichkeit das für einen unbedarften Anwender benutzerfreundlich zu realisieren. Dadurch hat man auch die Möglichkeit den Server später wieder relativ simpel auf ein Windowssystem umzuziehen (wenn man das möchte). Wer eine bessere Idee hat darf sie gerne sagen, ich denke manchmal vielleicht auch zu kompliziert.

schönen Gruß
elvito

p.s. Im readme bei github ist nicht erwähnt, dass man vor dem Kopieren der CGM Datei natürlich erst Samba aktivieren muss. Ich geh zwar davon aus, dass das klar ist, wollte es aber der Vollständigkeit halber nochmal erwähnen.

Hallo,

die Einrichtung und Konfiguration von iptables wurde im "testing" branch integriert. Wer das mal ausprobieren will muss den updater für den "testing" branch ausführen.-->

Code: Alles auswählen

~/update_tm-installer-testing.sh

das geht natürlich auch wenn TM bereits installiert ist. Ich habe mich dafür einfach eines anderen github Projekts bedient, man muss ja das Rad nicht neu erfinden. --> https://github.com/arno-iptables-firewall/aif

Hier eine rudimentäre deutsche Anleitung --> http://www.martin-specht.com/2011/01/14 ... er-debian/ bei dieser Anleitung muss man nur den Teil der die Konfiguration behandelt beachten, installiert wird das Paket über den Installer.

Ich bräuchte nun die Information welche Ports (jeweils TCP und UDP) für Turbomed geöffnet werden müssen. Dann kann ich eine Anleitung für das Firewallscript erstellen.

ich werde mich nun noch dem Backupkonzept widmen. Hier wäre interessant zu wissen wie und wohin gesichert werden soll, bzw. was die Anwender gerne für Sicherungsmöglichkeiten hätten. Ich denke eine versionierte Sicherung mit rsnapshot auf einen externen Datenträger wäre mal ein guter Anfang. Vorschläge und Wünsche sind sehr willkommen.

schönen Gruß
elvito

Hallo,

die Diskussion des Themas "local.ini" und "global.ini" im Zusammenhang mit dem FOS-Server (egal ob windows oder Linux) hat mich recht irritiert, da ich ebenfalls nicht nachvollziehen konnte, was das mit dem Server zu tun haben könnte. Mit meinem nichtmal Halbwissen wollte ich nicht "gscheid daherreden", ohne mich wirklich auszukennen. Deshalb habe ich mich hier ein wenig zurück genommen.
Aber zum Glück gibt's jetzt den wieder genesenen und erstarkenden "Wahnfried"

Offenbar ist es so: Wenn auf der Konsole die Meldung kommt, dass der "ptserver" läuft, dann ist das wohl auch so! Ganz einfach!

---> http://www.vondoczudoc.de/viewtopic.php ... =45#p29324

Und diesen "Erfolg" hatten wir hier ja schon ziemlich am Anfang dieser Diskussion hier.

Von entscheidender Wichtigkeit scheinen die Einträge in der "poet.cfg" und in der "ptserver.cfg" zu sein. Die im obigen Eintrag "ausge-x-ten" Lizenzschlüssel werden ja mit der Demo-Version von TurboMed mitgeliefert, sind also kein Geheimnis und dienen vielleicht dazu, dass der "FOS"-Server eben nur mit TurboMed zusammenarbeitet, was ja verständlich ist und was andererseits dann Lizenzprobleme ausschließt: Der "FOS" "kann dann nur" mit TurboMed. Die Demo-Version von TurboMed darf mit dem "FOS" zusammenarbeiten - es gibt ja keinen Nutzen für den, der diese Datenbank anderweitig nutzen möchte, und für lizenzierte TurboMed Nutzer ist die Frage des "Nutzungsrechts" des FOS-Servers ja sicherlich geklärt.

Und - wie gesagt - der FOS Server läuft ja!! Was bleibt sind vielleicht "nur" die bekannten Lizenzschlüsselprobleme, die man mit TurboMed auch hat und die hier schon oft jenseits vom Thema "Linux" ausgiebig diskutiert worden sind: Stichwort "Zeitstempel".

Ich denke also, dass die Lösung sehr nah ist!

Wie gesagt: Die "local.ini" und "global.ini" spielen wohl keine wesentliche Rolle (darum kümmern sich die Clients). Die Einträge in der "poet.cfg" und in der "ptserver.cfg" (Pfade, BackSlashes usw ) müssen richtig sein und es muss weiterhin unbedingt passen: Die TurboMed-Lizenz und die DAZU PASSENDE (!) "PraxisDB" . In diesem Zusammenhang wohl auch noch wichtig, dass das "Versionsproblem" "Lizenzordner" mit XML-Datei und die "bintab.dat" passt - ein sehr gut bekanntes und "Linux-unabhängiges" Thema: Wahnfried kennt sich hier wahrscheinlich am besten aus!

Meine Beobachtung: Das Zeitstempelproblem kann man reproduzierbar erscheinen und verschwinden lassen: Nur wenn die Lizenz (bintab.dat) mit der PraxisDB zusammenarbeitet, zu der diese PraxisDB erstmals "erstellt" worden ist (erster Programmstart), dann gibt's kein Zeitstempelproblem, kopiert man eine PraxisDB, die zu einem anderen Zeitpunkt aber mit derselben Lizenz(!) erstellt wurde in das Programm ein, dann erscheint das Zeitstempelproblem.

Und mit einem "Dateiserver" (nicht Datenbankserver) haben die hier beschiebenen Schwierigkeiten mit dem "FOS" auch gar nichts zu tun! Das ist wirklich - wie das "local.ini"-Thema - aus meiner Sicht ein "Nebenkriegsschauplatz" und betrifft nur die Freigabeoptionen unter Samba - wäre also ein eigener Thread und bringt hier ein wenig Durcheinander.

Ich denke, es wäre hilfreich, wenn man die drei "Problemfelder": "local.ini" , "Dateiserver" (Samba) und "FOS" sorgfältig trennt. Das "Gemisch" dieser drei Themen verwirrt ein wenig.

Eigentlich wäre es ja schön, wenn die Leute von "TurboMed" auch ein Interesse an der Lösung dieses Problems hätten und ein wenig helfen würden:
Wäre es nicht ein grandioser "Marketing-Clou", wenn sie sagen könnten:

"Liebe Doktors, wir haben da jetzt was ganz Tolles: Einen TurboMed Server könnt ihr nun ganz einfach erstellen: Installiert (K)Ubuntu (nur ein Mausklick!), lasst unser Skript laufen - auch dast nur ein Mausklick. Das War's!
Die Einstellungen in der "local.ini" (2 Zeilen!) sagen wir Euch und schon habt ihr einen wunderbaren Server für euer Praxis-TurboMed.
Und wenn ihr das nicht selber machen wollt, dann kann euch unser TurboMed-Vertriebspartner einen vollständig fertig konfigurierten Rechner liefern."

Eine schöne Woche!
A. Geigenberger

Hallo elvito,

habe ihr Serverimage mit der portablen Version von VirtualBox "entpackt" und die .vmdk in meiner VMWare Installation in eine neue Maschine integriert (die .ova wollte VMWare nicht annehmen).

Dies und Ihre Scripte haben alle bestens funktioniert, ich hätte allerdings noch 2 Vorschläge:

1. Da Linux nicht den kleinsten Tippfleher verzeiht, fände ich kürzere Ordner- und Scriptnamen sehr angenehm.
2. Für's nächste Quartal fehlt noch die Funktion "Update" (~/Downloads/TMWin/linux/bin/TM_setup -u)

Was die geöffneten Ports angeht, so sind es (unter Windows jedenfalls):
FOS: TCP 6001 6002
CGMApacheDerby: TCP 1530

Vielen Dank für Ihre Arbeit!
leo.pernes

Hallo,

zunächst mal vielen Dank für die Rückmeldung.

zu 1) Es reicht wenn Sie die ersten paar Buchstaben eintippen, den Rest können Sie durch Druck auf Tab bzw. mehrmaligem drücken auf Tab bei Doppeldeutigkeit automatisch ergänzen lassen. Ein sehr praktisches Feature der Shell, was z.B. auch bei "apt-get install" funktionert wenn man den genauen Paketnamen nicht weiß usw.

zu 2) Kann ich morgen machen, werde das zunächst in den testing Zweig einpflegen. Damit Sie das überarbeitete Script auf Ihren Server bekommen, müssen Sie nur den updater mit der Endung testing einmal als normaler Benutzer ausführen. Ich gebe hier bescheid wenn diese Änderungen in den master Zweig übernommen wurden. --> https://github.com/elvito/tm-linux-server-installhelper

Die Scripte im testing Zweig sind übrigens jetzt schon etwas weiter als das Scripte im master Zweig. Sie können es gerne einmal ausprobieren. Je nachdem welchen Updater Sie zuletzt ausgeführt haben können Sie in ein paar Sekunden zwischen "master" und "testing" hin und her wechseln.

Danke für die Rückmeldung, dass das Image auch in VMWare funktioniert. Welche VMWare Software haben Sie verwendet? VMPlayer? Wegen dem nicht Annehmen in der VMWare hier ein Link --> http://www.howtogeek.com/125640/how-to- ... nd-vmware/ scheint ein bekanntes Problem zu sein.

Das mit den Ports und der Firewall werde ich mir am Woe mal anschauen. Danke für den Hinweis.

schönen Gruß
elvito

danke für den TAB-tipp

elvito hat geschrieben:...Welche VMWare Software haben Sie verwendet? VMPlayer?...

Richtig, den kostenlosen Player. Da ich noch keine Lust hatte, meine ganzen VMs upzudaten, benutze ich immer noch Version 5.0.2.b.1031769, wahrscheinlich liegt's daran - "Retry" half jedenfalls nicht.

leo.pernes

Hallo,

Updatefunktion im testing Zweig wurde hinzugefügt und scheint zu funktionieren. Wer das ausprobieren will muss als normaler Benutzer (ohne sudo) die Scripte aktualisieren -->

Code: Alles auswählen

~/update_tm-installer-testing.sh

danach wie gewohnt den Installer aufrufen -->

Code: Alles auswählen

sudo ~/tm-linux-server-installhelper/install_tmlinuxserver.sh

schönen Gruß
elvito

Hallo Leute,
hatte das Thema ein bischen aus den Augen verloren: a) da ich auf Opensuse aufbaue, b) da ich den absoluten overkill gerade betreibe (Samba4 als PDC), das ganze als Server in eine VM verpackt und dann auf einem esxi5.5 Gerät (und ich da meine Festplatten wechseln sollte).
Habe die letzten Beiträge nur grob überflogen:
hört auf Meckeleins Ausführungen:
global/local.ini haben auf dem reinen Linuxserver eigentlich keinerlei Bedeutung. Man sollte den Linux(=Samba-)Server nur unter zwei Gesichtspunkten sehen: Bereitstellung des FOS(poet) Server als handling-agent (eigentlich Server i.S. client-server beziehung) für die TM-Datenbanken (daher von TM im eigenen Verzeichnis /opt/Fastobj... abgelegt,Speicherort wahrscheinlich ziemlich wurscht, vorausgesetzt die Pfade (poet.cfg, init.d ..., oder systemd zum starten stimmen) und eine beliebige Freigabe (von TM als Turbomed vorgegeben), in der die Datenbanken (/opt/turbomed/praxisdb/...) liegen -> hier kommen die ini Dateien der Windows-clients (Verzeichnis der Praxisdb etc) zum tragen. M.E. benötigt man minimalistischst nur die PraxisDB mit ihren Sicherungen auf dem server, Formularverzeichnis etc entspricht (sollte!) den jeweiligen Verzeichnissen der Windowclients, wobei natürlich Sinn und Zweck des Servers die zentrale Verwaltung unter der Turbomed-Freigabe ist.
Zum Thema Lizenz Zeitstempel: kein Problem -> Lizenzen vom alten System umziehen (ich kann nur von Bintab reden, in /opt/Turbomed einkopieren, mit dem Lizenzverzeichnis müßte es ähnlich gehen), Datensicherung der Praxisdaten auf einem WIN Client über Start-> Turbomed-> Praxisdatenrücksichern einspielen, hat bei mir diverse Male funktioniert.

Warum wollt Ihr das Rad mit dden Scripten neu erfinden: seit 10 Jahren fahre ich meine Updates über die Orginal TM-Scripte (funktioniert bei mir bis auf die blöde Zeichensatzproblematik, auch zwei Lösungen: kompliziert entpacken der Update-Archive, Zeichensatzumwandlung, Packen, neubrennen, installieren; oder Dampfhammer (umbenennen der Unterverzeichnisse auf dem linuxserver: Menues, Formulare und Vorlagen, Linuxinstallation, Rückumbennung, unter Windows vom Clienten aus dann einkopieren der Verzeichnisse Formulare, Menues und Vorlagen auf den server).
Zum Thema Sicherheit: hatte unter Samba 3 eine Gruppe "Praxis" die volle Zugriffsrechte auf /Turbomed/ hatte und gid gesetzt, nobody und other hatten keinerlei Zugriff, hatte funktioniert. Jetzt unter Samba4 kommen leider (zumindestens in der Domaine) noch die ACLs hinzu, bin da noch gewaltig am basteln (brauche leider chmod 2777). Wäre auch zu überlegen, was es brächte den FOS in einer CHROOT Umgebung laufen zu lassen (Meckelein?), da fehlen mir leider doch die Feinheiten...

Als hilfreich würde ich es empfinden, eine smb.conf (stelle gerne meine zur Verfügung, aber Samba4 als PDC, nicht als AD) zu basteln, die mit eingeschränkten Zugriffsrechten arbeitet, ggf. mit Anpassung der TM Scripte an andere Verzeichnisstrukturen und Kiel zu überzeugen, den Zeichensatz der Linux-updates auf UTF-8 umzustellen.
noch nen schönen Abend
M. Möllinger

Hallo mmoellinger,

"Quick and Dirty"

Und schnörkellos! Gefällt mir sehr!! So etwa stelle ich mir das auch vor.
Probiere ich die nächsten Tage auch bald mal aus. Einen (sogar mehrere) alten PC habe ich auch noch.
Kubuntu drauf - bin schon sehr gespannt!

Danke für die klaren Infos!!!!

A. Geigenberger

Hallo,

mmoellinger hat geschrieben: Warum wollt Ihr das Rad mit dden Scripten neu erfinden: seit 10 Jahren fahre ich meine Updates über die Orginal TM-Scripte (funktioniert bei mir bis auf die blöde Zeichensatzproblematik, auch zwei Lösungen: kompliziert entpacken der Update-Archive, Zeichensatzumwandlung, Packen, neubrennen, installieren; oder Dampfhammer (umbenennen der Unterverzeichnisse auf dem linuxserver: Menues, Formulare und Vorlagen, Linuxinstallation, Rückumbennung, unter Windows vom Clienten aus dann einkopieren der Verzeichnisse Formulare, Menues und Vorlagen auf den server).

Ich verstehe das Problem das Sie mit den Zeichensätzen haben leider immer noch nicht. Ich kann aber aus Mangel an Hardware bzw. Festplattenkapazität das auch leider bei mir Zuhause nicht nachvollziehen, da unser Backup zu groß ist um es in meiner VM einzuspielen. @Meckelein: Was muss konkret bezgl des Zeichensatzes bei der Installation unternommen werden?

@mmoellinger: Welcher Zeichensatz wird denn global auf Ihrem Server verwendet?

Um das rauszufinden posten Sie doch bitte mal, wenn Sie mit dem Benutzer unter dem der FOS läuft angemeldet sind, in der shell die Ausgabe von

Code: Alles auswählen

locale

und sicherheitshalber auch von

Code: Alles auswählen

cat /etc/fstab

Wenn die TM Updates in iso was auch immer kodiert sind, machen Sie doch einfach diesen Zeichensatz zu Ihrem globalen Zeichensatz. Samba dolmetscht dann je nach entsprechenden smb.conf Einträgen automatisch für die Clients und vice versa.

mmoellinger hat geschrieben: Zum Thema Sicherheit: hatte unter Samba 3 eine Gruppe "Praxis" die volle Zugriffsrechte auf /Turbomed/ hatte und gid gesetzt, nobody und other hatten keinerlei Zugriff, hatte funktioniert. Jetzt unter Samba4 kommen leider (zumindestens in der Domaine) noch die ACLs hinzu, bin da noch gewaltig am basteln (brauche leider chmod 2777). Wäre auch zu überlegen, was es brächte den FOS in einer CHROOT Umgebung laufen zu lassen (Meckelein?), da fehlen mir leider doch die Feinheiten...

Eine chroot Umgebung bietet keine große Sicherheit, denn man kann Sie relativ einfach verlassen --> http://manpages.debian.org/cgi-bin/man. ... &locale=de , besser wäre es vermutlich den FOS nicht mit höheren Rechten laufen zu lassen.

schönen Gruß
elvito

Hallo elvito

Zeichensatz locale: LANG=de_DE.UTF-8
LC_CTYPE="de_DE.UTF-8"
LC_NUMERIC="de_DE.UTF-8"
LC_TIME="de_DE.UTF-8"
LC_COLLATE="de_DE.UTF-8"
LC_MONETARY="de_DE.UTF-8"
LC_MESSAGES="de_DE.UTF-8"
LC_PAPER="de_DE.UTF-8"
LC_NAME="de_DE.UTF-8"
LC_ADDRESS="de_DE.UTF-8"
LC_TELEPHONE="de_DE.UTF-8"
LC_MEASUREMENT="de_DE.UTF-8"
LC_IDENTIFICATION="de_DE.UTF-8"
LC_ALL=

also stinknormal UTF-8.
Problem sind irgendwo mehrfach in den Unterordnern enthaltenbe Dateien (zB Formulare zB irgendwelche AOK-Programme = pdfs, sind im ISO Zeichensatz kodiert, werden so vom TM_update auf die Freigabe unter direktem Linux entpackt mit ISO Zeichensatz gespeichert), greift man dann von einem Windows-Client drauf zu, gibt es Zeichensatzsalat, bzw Turbomed findet die Datei nicht (zB Sicherung der externen Datenbanken..), noch schlimmer, korrigiert man das falsche Zeichen dann unter Windows, gibt es auf Linuxsystemebene (zB chmod..) den Fehler "Datei nicht gefunden". Im WIKI ist ein Linux Update script enthalten, das auf diese Problematik eingeht, aber leider nicht tief genug (s. frühere Mail von mir -> in einem Archiv ist ein weiteres Archiv mit diesen PDFS und ISO Zeichensatz enthalten). D.h. folgt man dem Orginal TM-Linuxupdate, müßte der Zeichensatz wenigstens unter Samba auf ISO-9... umgestellt werden, kann ich aber in meinem System nicht mehr.
PS: fstab ->
/dev/md/swap swap swap defaults 0 0
/dev/disk/by-id/md-uuid-a4a8c851:a96bb4d2:18091d1b:fd2d0a59 / ext4 acl,user_xattr 1 1

/dev/disk/by-id/md-uuid-e697a1b4:eedb4d23:40d9e325:3ce56198 swap swap defaults 0 0

(nicht wundern habe auf swap im RAID1)
Gruß
M. Möllinger

Hallo,

mmoellinger hat geschrieben:Hallo elvito
Problem sind irgendwo mehrfach in den Unterordnern enthaltenbe Dateien (zB Formulare zB irgendwelche AOK-Programme = pdfs, sind im ISO Zeichensatz kodiert, werden so vom TM_update auf die Freigabe unter direktem Linux entpackt mit ISO Zeichensatz gespeichert)

Hab das mal eben nachvollzogen. Also file -i einer beliebigen Datei beim frisch installierten TM Server liefert folgendes

Code: Alles auswählen

charset=binary

file alleine liefert

Code: Alles auswählen

Code page: 1252

Können Sie bitte mal auf Ihrem Produktivsystem im Turbomedordner z.B. im Unterverzeichnis Vorlagen die Informationen einer Datei jeweils mit

Code: Alles auswählen

file <Dateiname>

und mit

Code: Alles auswählen

file -i <Dateiname>

abrufen und das Ergebnis hier posten.

gruß
elvito

VonDoczuDoc.de

Turbomed auf Linux Server

Re: Turbomed auf Linux Server

Re: Turbomed auf Linux Server

Re: Grundeinstellungen...

Re: Turbomed auf Linux Server

Re: Turbomed auf Linux Server

Re: Turbomed auf Linux Server

Re: Turbomed auf Linux Server

Re: Server, "Server" und FOS

Re: Turbomed auf Linux Server

Re: Turbomed auf Linux Server

Re: Turbomed auf Linux Server

Re: Turbomed auf Linux Server

Re: Turbomed auf Linux Server

Re: Turbomed auf Linux Server

Re: Turbomed auf Linux Server

Re: Turbomed auf Linux Server

Re: Turbomed auf Linux Server

Re: Turbomed auf Linux Server

Re: Turbomed auf Linux Server

Re: Turbomed auf Linux Server