Turbomed auf Linux Server

Egal, ob Sie nur von "Windows 7" auf eine aktuelle Windows-Version umstellen wollen, einen neuen Arbeitsplatz brauchen oder sich Ihr Praxis-Netzwerk selber einrichten wollen: Es ist viel leichter als Sie denken! - - - Hier finden Sie viele Tips zum "Do it yourself" !

Moderator: Forum Moderatoren

Antworten
Benutzeravatar
wahnfried
PowerUser
Beiträge: 3180
Registriert: Freitag 13. Januar 2006, 23:46
18
Wohnort: Braunschweig

Re: Turbomed auf Linux Server

Beitrag von wahnfried »

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.
Meckelein
Beiträge: 164
Registriert: Samstag 2. August 2014, 09:14
9
Bedankt: 1 time

Re: Turbomed auf Linux Server

Beitrag von Meckelein »

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
Benutzeravatar
wahnfried
PowerUser
Beiträge: 3180
Registriert: Freitag 13. Januar 2006, 23:46
18
Wohnort: Braunschweig

Re: Server, "Server" und FOS

Beitrag von wahnfried »

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.
elvito
Beiträge: 157
Registriert: Dienstag 22. April 2014, 09:48
9

Re: Turbomed auf Linux Server

Beitrag von elvito »

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.
elvito
Beiträge: 157
Registriert: Dienstag 22. April 2014, 09:48
9

Re: Turbomed auf Linux Server

Beitrag von elvito »

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
Benutzeravatar
Geigenberger
PowerUser
Beiträge: 1302
Registriert: Dienstag 9. Dezember 2003, 22:26
20
Bedankt: 3 times

Re: Turbomed auf Linux Server

Beitrag von Geigenberger »

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
Sapias, vina liques et spatio brevi spem longam reseces... carpe diem, quam minimum credula postero [Horaz]
"Sei klug, gönn dir noch ein Glas Wein ein und hoffe auf nichts weiter. ... Genieße den Tag, und vertraue möglichst wenig auf den folgenden!"
leo.pernes
Beiträge: 19
Registriert: Donnerstag 9. Oktober 2014, 21:10
9

Re: Turbomed auf Linux Server

Beitrag von leo.pernes »

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
elvito
Beiträge: 157
Registriert: Dienstag 22. April 2014, 09:48
9

Re: Turbomed auf Linux Server

Beitrag von elvito »

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
leo.pernes
Beiträge: 19
Registriert: Donnerstag 9. Oktober 2014, 21:10
9

Re: Turbomed auf Linux Server

Beitrag von leo.pernes »

danke für den TAB-tipp 8)
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
elvito
Beiträge: 157
Registriert: Dienstag 22. April 2014, 09:48
9

Re: Turbomed auf Linux Server

Beitrag von elvito »

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
mmoellinger
Beiträge: 91
Registriert: Mittwoch 31. August 2005, 20:30
18
Wohnort: Bayern

Re: Turbomed auf Linux Server

Beitrag von mmoellinger »

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
Benutzeravatar
Geigenberger
PowerUser
Beiträge: 1302
Registriert: Dienstag 9. Dezember 2003, 22:26
20
Bedankt: 3 times

Re: Turbomed auf Linux Server

Beitrag von Geigenberger »

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
Sapias, vina liques et spatio brevi spem longam reseces... carpe diem, quam minimum credula postero [Horaz]
"Sei klug, gönn dir noch ein Glas Wein ein und hoffe auf nichts weiter. ... Genieße den Tag, und vertraue möglichst wenig auf den folgenden!"
elvito
Beiträge: 157
Registriert: Dienstag 22. April 2014, 09:48
9

Re: Turbomed auf Linux Server

Beitrag von elvito »

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
mmoellinger
Beiträge: 91
Registriert: Mittwoch 31. August 2005, 20:30
18
Wohnort: Bayern

Re: Turbomed auf Linux Server

Beitrag von mmoellinger »

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
elvito
Beiträge: 157
Registriert: Dienstag 22. April 2014, 09:48
9

Re: Turbomed auf Linux Server

Beitrag von elvito »

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
Meckelein
Beiträge: 164
Registriert: Samstag 2. August 2014, 09:14
9
Bedankt: 1 time

Re: Turbomed auf Linux Server

Beitrag von Meckelein »

Also, da ich die letzten Tage viel mitgelesen, aber nix geschrieben habe, melde ich mich mal wieder :)
@Meckelein: Was muss konkret bezgl des Zeichensatzes bei der Installation unternommen werden?
Soweit ich weiss, nix. Habe alle meine Installationen bislang ohne Änderung des Zeichensatzes im System, ohne Anpassung der Dateien in den TM Archiven und ohne Einstellung zum Zeichensatz im Apache vorgenommen. Bislang sind mir keine Probleme ala, Datei nicht gefunden oder Zugriff verweigert zu Ohren gekommen. Hab mir jetzt auch die Ordner nochmal angeschaut und verglichen. Ich finde nur im Ordner "Formulare" den Unterordner "Geräte" und auch einige Dateien die Umlaute in den Dateinamen besitzen. Diese Umlaute werden nicht korrekt angezeigt, weder auf der Linux Konsole, noch im Windows Explorer. Dies liegt natürlich an nicht ordentlich durchgereichtem Zeichensatz. Da ich mich mit dem Turbomed mal leider garnicht auskenne, würde ich darum bitten, mal die entsprechenden Funktionen im TM aufzurufen und hierüber die Dateien zu öffnen. Sollte es dabei zu Problemen kommen, werde ich meine Scripte entsprechend anpassen, damit die Dateinamen, vor dem kopieren, in einen ordentlichen Zeichensatz übersetzt werden.

Für alle Dateien, die nach der Installation in den Turbomed Ordner kopiert werden, ist der Zeichensatz nicht mehr von belang, da diese, während des Kopiervorgangs durch den Samba Daemon entsprechend verändert werden. Dies gilt sowohl für die Dateien die von "Alten" Server auf den "Neuen" kopiert werden, als auch für alle eingescannten Dokumente in der Karteikarte des Patienten und für alle Dateien, die durch ein Clientupdate auf dem Server erstellt werden.
WICHTIG: Hierunter fallen nicht die Dateien die in den Zip Archiven von TM drinnen stecken.

Code: Alles auswählen

Bitte niemals den Zeichensatz im Samba ändern, nachdem Dateien in die Freigabe kopiert wurden, das ist absolut tödlich :)
Nochmal etwas zu den Scripten von mir. Ich habe mir diese gebaut, da ich mit dennen von TM nicht zufrieden bin. Ich mag Scripte nicht, für die ich mein System anpassen muss, damit diese laufen. Es muss umgekehrt funktionieren, man muss das Script an das System anpassen können. Daher habe ich mir den kompletten Ablauf angeschaut und nachgebildet, mit ein paar zusätzlichen Funktionen. Die Scripte wie sie momentan im Git Repo unter installerscripts/meckelein liegen, funktionieren komplett, sowohl Install auf einem frisch installiertem Ubuntu 14.04.1 Server als auch Update. Alles was zusätzlich noch gemacht werden muss steht in der beiliegenden README. Und ja, es sind Scripte, daher keine Oberfläche für Auswahl und Bedinung, sondern direktes ausführen auf der Kommandozeile :)
Für Suse sind die Scripte nicht angepasst, einfach da ich kein Suse verwende und das wird auch nicht so schnell passieren, ich bitte dies zu entschuldigen :)

Eine CHROOT Umgebung ist m.M.n. unnötig, da diese alles nur verkompliziert. CHROOT ist nur dafür da um Teile des Systems gegeneinander abzusichern, d.h. wenn ein Daemon übernommen wurde, kann er nicht auf die anderen zugreifen, so zumindest die Grundidee. Da wir hier aber keinen Server produzieren der im Internet steht, ist diese Massnahme unnötig. Viel wichtiger sind ordentliche Türen, Fenster und Schlösser an den Praxisräumen :)
Ein unerlaubter Zugriff übers Internet auf einen Rechner der im internen LAN steht ist nur etwas für Profis und wenn so jemand ins System will, können wir dagegen relativ wenig unternehmen. Viel wichtiger ist es die "Möchtegerns" oder auch "Script Kiddies" genannt draussen zu halten. Damit sind Leute gemeint, die auf irgend einer "Hacker"-Seite irgend ein Programm finden, dass sie mit einem Doppelklick ausführen können um dann iwas böses damit anstellen. Hierfür langt die Verwendung eines Routers bei dem das WLAN mit einem ordentlich langen PW abgesichert ist und das keine Anfragen von aussen zulässt, was heutzutage der Normalfall ist, vollkommen aus. Die viel grössere Gefahr besteht in Personen die persönlichen Zugriff auf die Praxisräume und die darin befindliche Hardware haben.

Zu dem Punkt mit den ACLs. Ich arbeite komplett ohne ACLs im ganzen System. Meine Zugriffsberechtigungen sind einfach nicht hinreichend komplex als das sich ACLs lohnen würden. Die Dateien in der Samba-Freigabe gehören zwingend der Gruppe "users" durch den Eintrag "force group = users" in der smb.conf, dazu arbeite ich mit den Rechten "0770" für alle Dateien in der Freigabe. Die Benutzer mit Zugriff wurden dem Samba mittels "smbpasswd" beigebracht und der Samba selber ist nochmal Mitglied der Gruppe users wobei das komplett unnötig ist, ka wieso das noch so ist :)
Eine spezielle Benutzerverwaltung über einen PDC ist nicht notwendig, es verkompliziert die Arbeit sowohl für Arzt als auch Helfer, wenn er/sie sich jedesmal am PC neu anmelden muss und jedesmal daran denken muss sich erst abzumelden. Ausserdem wäre dann ein PC gesperrt, wenn das jemand vergisst, der Bildschirmschoner geht nach 1 Min an und verlangt zwingend ein Passwort. Ich bin der Meinung, gerade in kleinen Praxen sollte der Umgang mit dem Computer so stressfrei wir möglich ablaufen. Erst ab mehreren Ärzten, zweistellige Anzahl an Helfern und Arbeitsplätzen fängt es an interessant zu werden mit Benutzerverwaltung. Für diese Systeme sehe ich aber Grundsätzlich einen Admin vor Ort vor, da hier auch noch ganz andere Sachen zu beachten sind.
Grundsätzlich ist es aber auch kein Problem einen PDC mit Benutzerverwaltung aufzusetzen, ohne ACLs zu verwenden. Wichtig ist hierbei, dass alle User in der gleichen Gruppe sind und die Gruppe volle Zugriffsrechte auf die TM Freigabe hat. Die Nutzung von ACLs wird erst interessant, wenn man verschiedene Benutzergruppen mit verschiedenen Rechten hat, da denke ich als erstes mal an Krankenhäuser und da sind Admins vor Ort und ich glaube die verwenden ganz andere Systeme als TM :)

So, jetzt hab ich mal wieder viel Senf gegeben, hoffe ich habe niemandem den Apettit verdorben :)
mmoellinger
Beiträge: 91
Registriert: Mittwoch 31. August 2005, 20:30
18
Wohnort: Bayern

Re: Turbomed auf Linux Server

Beitrag von mmoellinger »

Hallo Elvito
Ausgabe "file" auf /turbomed/Vorlagen/Präoperativer Untersuchungsergebnisse :
>> Präoperative Untersuchungsergebnisse.dot: setgid Composite Document File V2 Document, Little Endian, Os: Windows, Version 6.1, Code page: 1252, Title: #12, Author: Olaf Greve, Template: Praoperative Untersuchungsergebnisse, Last Saved By: Rohwer, Britta, Revision Number: 20, Name of Creating Application: Microsoft Office Word, Create Time/Date: Sun Feb 23 17:44:00 1997, Last Saved Time/Date: Mon May 30 13:00:00 2011, Number of Pages: 1, Number of Words: 62, Number of Characters: 395, Security: 0<<
>>Ausgabe file -i -> Präoperative Untersuchungsergebnisse.dot: application/msword; charset=unknown<<

Interessant "charset0 unknown". Ergibt für mich noch kein Sinn, im Verzeichnis /Turbomed/Programm/update.cfg liefert charset=us-ascii.

verunsicherte Grüße
mölli
mmoellinger
Beiträge: 91
Registriert: Mittwoch 31. August 2005, 20:30
18
Wohnort: Bayern

Re: Turbomed auf Linux Server

Beitrag von mmoellinger »

Hallo Meckelein,
mit einer Gruppe ohne ACLs mit 770 hatte es unter Samba3 sowohl als Arbeitsgruppen-Server als auch als PDC geklappt, beim Umstieg von Suse 12.2 auf 12.3 bin ich dann ziemlich ahnungslos in Samba4 reingerutscht (never change a running system), aber der Spieltrieb hatte gesiegt, Problem ist nur, daß Suse die Samba-Tools bei Samba 4 (wohl wegen kerberos) nicht integriert hat, d.h. ich kann nicht einfach auf einen AD migrieren und unter Samba4 funktionierte dann alles mögliche plötzlich nicht mehr (Einlesen der eGK zb) wegen fehlender Zugriffsrechte.
Klar Domaincontroller ist overkill, aber wie gesagt Spieltrieb.
gruß Mölli
elvito
Beiträge: 157
Registriert: Dienstag 22. April 2014, 09:48
9

Re: Turbomed auf Linux Server

Beitrag von elvito »

Hallo,
Meckelein hat geschrieben:Also, da ich die letzten Tage viel mitgelesen, aber nix geschrieben habe, melde ich mich mal wieder :)
@Meckelein: Was muss konkret bezgl des Zeichensatzes bei der Installation unternommen werden?
Soweit ich weiss, nix. Habe alle meine Installationen bislang ohne Änderung des Zeichensatzes im System, ohne Anpassung der Dateien in den TM Archiven und ohne Einstellung zum Zeichensatz im Apache vorgenommen.
Ok dann scheint Kollege Möllinger aus "historischen" Gründen noch die iso-8859-1 Problematik mitzuschleifen. Das PDF im Wiki --> http://vondoczudoc-wiki.oblomov.de/lib/ ... x_V1.3.pdf ist also nicht mehr ganz up to date. Insbesondere der Eintrag in der smb.conf wo es heißt:

Code: Alles auswählen

character set = ISO8859-1

sollte nicht mehr gesetzt werden.

@mmoellinger Sie könnten ja mal eine Testumgebung aufsetzen und Ihr Backup von einem Windowsclient! via Samba dort einspielen. Dann sollte sich Ihre Zeichensatzproblematik erledigt haben und Sie müssen nicht mehr jedes Quartal solche Verrenkungen machen.

@Meckelein: sehe ich wegen der Sambakonfiguration ganz genau so.

Code: Alles auswählen

security = user
sollte reichen. Man sollte vielleicht noch konkretisieren, dass es notwendig ist mittels smbpasswd die Benutzer mit exakt den selben Namen und Passwörtern wie sie bei den Windowsclients angelegt sind beim Sambaserver anzulegen. Wie das geht steht hier --> http://wiki.ubuntuusers.de/Samba_Server (Benutzerverwaltung).


schönen Gruß
elvito
elvito
Beiträge: 157
Registriert: Dienstag 22. April 2014, 09:48
9

Re: Turbomed auf Linux Server

Beitrag von elvito »

Hallo,
mmoellinger hat geschrieben:Hallo Elvito
Ausgabe "file" auf /turbomed/Vorlagen/Präoperativer Untersuchungsergebnisse :
>> Präoperative Untersuchungsergebnisse.dot: setgid Composite Document File V2 Document, Little Endian, Os: Windows, Version 6.1,Code page: 1252, Title: #12, Author: Olaf Greve, Template: Praoperative Untersuchungsergebnisse, Last Saved By: Rohwer, Britta, Revision Number: 20, Name of Creating Application: Microsoft Office Word, Create Time/Date: Sun Feb 23 17:44:00 1997, Last Saved Time/Date: Mon May 30 13:00:00 2011, Number of Pages: 1, Number of Words: 62, Number of Characters: 395, Security: 0<<
>>Ausgabe file -i -> Präoperative Untersuchungsergebnisse.dot: application/msword; charset=unknown<<

Interessant "charset0 unknown". Ergibt für mich noch kein Sinn, im Verzeichnis /Turbomed/Programm/update.cfg liefert charset=us-ascii.

verunsicherte Grüße
mölli
Der eine Befehl gibt Ihnen die Kodierung des Inhalts. Da haben Sie Code page: 1252. Leider muss ich Ihnen damit mitteilen, dass dieser Zeichensatz ebenfalls von iso-8859-1 abweicht :( --> http://de.wikipedia.org/wiki/ISO_8859-1#Windows-1252


Sie haben also möglicherweise ein Mischmasch aus 3 verschiedenen Zeichensätzen. convmv ändert übrigens nicht die Kodierung des Dateiinhalts sondern nur die Kodierung der Dateinamen. Da haben Sie jetzt charset=unknown. Der Befehl "file" liefert keine absoluten Wahrheiten sondern versucht nur zu erraten welcher charset verwendet wird. Bei mir steht da nach einer frischen Installation "binary" was nach Aussage von Herrn Meckelein zwar unter Linux unschön dargestellt wird (bei mir übrigens auch) aber scheinbar den Clients egal ist. Evtl würde es sich lohnen wenn Sie ihren Server nochmal sauber aufsetzen und das Backup von einem Windowsclient zurückspielen. Dann sollten auch die CGM Updates sauber durchlaufen.

schönen Gruß
elvito
Antworten

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 16 Gäste