Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comm.software.mailserver > #6158 > unrolled thread

hMailServer: Umzug und gleichzeitig Update?

Back to article view | Back to de.comm.software.mailserver

Contents

  hMailServer: Umzug und gleichzeitig Update? Tilmann Reh <usenet2007nospam@autometer.de> - 2020-03-17 11:32 +0100
    Re: hMailServer: Umzug und gleichzeitig Update? Arno Welzel <usenet@arnowelzel.de> - 2020-03-17 11:40 +0100
      Re: hMailServer: Umzug und gleichzeitig Update? Tilmann Reh <usenet2007nospam@autometer.de> - 2020-03-17 11:53 +0100
        Re: hMailServer: Umzug und gleichzeitig Update? Arno Welzel <usenet@arnowelzel.de> - 2020-03-17 12:05 +0100
    Re: hMailServer: Umzug und gleichzeitig Update? Tilmann Reh <usenet2007nospam@autometer.de> - 2020-03-28 10:18 +0100
      Re: hMailServer: Umzug und gleichzeitig Update? Arno Welzel <usenet@arnowelzel.de> - 2020-03-28 15:31 +0100
        Re: hMailServer: Umzug und gleichzeitig Update? Tilmann Reh <usenet2007nospam@autometer.de> - 2020-03-28 23:16 +0100
          Re: hMailServer: Umzug und gleichzeitig Update? Arno Welzel <usenet@arnowelzel.de> - 2020-03-29 05:56 +0200
            Re: hMailServer: Umzug und gleichzeitig Update? "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2020-03-29 22:48 +0200
              Re: hMailServer: Umzug und gleichzeitig Update? Marcus Jodorf <trap@killfile.de> - 2020-03-30 00:50 +0200
              Re: hMailServer: Umzug und gleichzeitig Update? Arno Welzel <usenet@arnowelzel.de> - 2020-03-30 18:25 +0200
                Re: hMailServer: Umzug und gleichzeitig Update? "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2020-04-01 08:26 +0200
                  Re: hMailServer: Umzug und gleichzeitig Update? Arno Welzel <usenet@arnowelzel.de> - 2020-04-01 16:56 +0200
                    Re: hMailServer: Umzug und gleichzeitig Update? "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2020-04-02 10:12 +0200
                      Re: hMailServer: Umzug und gleichzeitig Update? Arno Welzel <usenet@arnowelzel.de> - 2020-04-02 12:58 +0200

#6158 — hMailServer: Umzug und gleichzeitig Update?

Guten Morgen,

wir ersetzen gerade einen alten Server durch einen neuen (neue Hardware,
aktuelles OS).

Der in einer eigenen VM laufende hMailServer (bisher Version 5.5.1) soll
dabei auch das Update auf die aktuelle Version 5.6.7 bekommen, ebenso
MySQL das fällige Update von 5.6.15 auf 8.0.19.

Ich werde aus den gefundenen Hinweisen nicht ganz schlau, ob man nun
tatsächlich (immer noch?) die Portierung auf den neuen Server zunächst
"absolut 1:1" durchführen sollte und dann später das Update machen -
oder ob es doch möglich ist, auf dem alten Server die Daten zu
sichern/exportieren und dann in der (aktuellen) Neuinstallation einfach
wieder einzulesen...

Hat hier jemand vielleicht praktische Erfahrungen damit und kann
berichten, was evtl. zu beachten ist?

Hinweis: der Umfang der zu portierenden Daten ist sehr klein, das dürfte
auf jeden Fall mit dem eingebauten Export/Import gehen. Falls nicht doch
irgendetwas dagegen spricht...

Danke und viele Grüße
Tilmann

[toc] | [next] | [standalone]

#6159

Tilmann Reh:

> Guten Morgen,
> 
> wir ersetzen gerade einen alten Server durch einen neuen (neue Hardware,
> aktuelles OS).
> 
> Der in einer eigenen VM laufende hMailServer (bisher Version 5.5.1) soll
> dabei auch das Update auf die aktuelle Version 5.6.7 bekommen, ebenso
> MySQL das fällige Update von 5.6.15 auf 8.0.19.
> 
> Ich werde aus den gefundenen Hinweisen nicht ganz schlau, ob man nun
> tatsächlich (immer noch?) die Portierung auf den neuen Server zunächst
> "absolut 1:1" durchführen sollte und dann später das Update machen -
> oder ob es doch möglich ist, auf dem alten Server die Daten zu
> sichern/exportieren und dann in der (aktuellen) Neuinstallation einfach
> wieder einzulesen...

<https://www.hmailserver.com/documentation/v5.6/?page=upgrading_recommendations>

Ansonsten wenn ein Export/Import vorhanden ist, würde ich den nutzen.


-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#6160

Arno Welzel schrieb:

> Tilmann Reh:
>> wir ersetzen gerade einen alten Server durch einen neuen (neue Hardware,
>> aktuelles OS).
>> 
>> Der in einer eigenen VM laufende hMailServer (bisher Version 5.5.1) soll
>> dabei auch das Update auf die aktuelle Version 5.6.7 bekommen, ebenso
>> MySQL das fällige Update von 5.6.15 auf 8.0.19.
>> 
>> Ich werde aus den gefundenen Hinweisen nicht ganz schlau, ob man nun
>> tatsächlich (immer noch?) die Portierung auf den neuen Server zunächst
>> "absolut 1:1" durchführen sollte und dann später das Update machen -
>> oder ob es doch möglich ist, auf dem alten Server die Daten zu
>> sichern/exportieren und dann in der (aktuellen) Neuinstallation einfach
>> wieder einzulesen...
> 
> <https://www.hmailserver.com/documentation/v5.6/?page=upgrading_recommendations>

Da war ich natürlich schon...
Dort geht es allerdings nur um das Update, nicht um den Umzug.

Es gibt Beschreibungen im Netz, in denen für einen Umzug ausdrücklich
darauf hingewiesen wird, daß man den unbedingt immer mit exakt denselben
Versionen durchführen soll. Aber auch andere, die das verneinen. Deshalb
meine Frage nach praktischen Erfahrungen.

Es gibt auch noch:
<https://www.hmailserver.com/documentation/v5.1/?page=maintenance_newserver>

Diese Seite bezieht sich aber auf V5.1, und anderswo wird beschrieben,
daß hMailServer (erst) ab V5.4 mit relativen Pfaden arbeitet, die beim
Umzug weniger problematisch sind.

Grüße
Tilmann

[toc] | [prev] | [next] | [standalone]

#6161

Tilmann Reh:

> Arno Welzel schrieb:
[...]
> Es gibt Beschreibungen im Netz, in denen für einen Umzug ausdrücklich
> darauf hingewiesen wird, daß man den unbedingt immer mit exakt denselben
> Versionen durchführen soll. Aber auch andere, die das verneinen. Deshalb
> meine Frage nach praktischen Erfahrungen.

Praktische Erfahrungen mit hMailServer kann ich nicht vorweisen.

Aber der Rat, erstmal mit der identischen Version umzuziehen, ist nicht
ganz verkehrt, da man sich so nicht gleich zwei potentielle Probleme auf
einmal schafft.

> Es gibt auch noch:
> <https://www.hmailserver.com/documentation/v5.1/?page=maintenance_newserver>
> 
> Diese Seite bezieht sich aber auf V5.1, und anderswo wird beschrieben,
> daß hMailServer (erst) ab V5.4 mit relativen Pfaden arbeitet, die beim
> Umzug weniger problematisch sind.

Die Pfade stehen laut Beschreibung in der Datenbank. Ich würde da wohl
einfach einen Dump in MySQL erstellen und dann mit einem Texteditor per
Suchen&Ersetzen die Pfade anpassen, wenn nötig, bevor ich die Datenbank
dann auf dem neuen Server wieder zurückspiele.



-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#6170

Ich schrieb:

> wir ersetzen gerade einen alten Server durch einen neuen (neue Hardware,
> aktuelles OS).
> 
> Der in einer eigenen VM laufende hMailServer (bisher Version 5.5.1) soll
> dabei auch das Update auf die aktuelle Version 5.6.7 bekommen, ebenso
> MySQL das fällige Update von 5.6.15 auf 8.0.19.
> 
> Ich werde aus den gefundenen Hinweisen nicht ganz schlau, ob man nun
> tatsächlich (immer noch?) die Portierung auf den neuen Server zunächst
> "absolut 1:1" durchführen sollte und dann später das Update machen -
> oder ob es doch möglich ist, auf dem alten Server die Daten zu
> sichern/exportieren und dann in der (aktuellen) Neuinstallation einfach
> wieder einzulesen...
> 
> Hat hier jemand vielleicht praktische Erfahrungen damit und kann
> berichten, was evtl. zu beachten ist?

Für die Nachwelt:

Der Umzug unter Beibehaltung von MySQL gestaltet sich extrem schwierig:
bei MySQL hat man vor einiger Zeit einen radikalen Schnitt zu x64
vollzogen, es gibt keine 32-Bit Versionen mehr. Selbst die originale
alte Installationsdatei, die auf dem alten Server verwendet wurde,
erkennt das zugrundeliegende 64-Bit OS und zieht sich bei der
Installation neue Komponenten, die dann von hMailServer nicht verwendet
werden können (denn den gibt es bislang nur in 32 Bit).

Der Versuch, das alte 32-Bit MySQL aus dem zip zu installieren,
scheiterte an irgendwelchen fehlenden DLLs - insgesamt ist das eine
mühsame Angelegenheit, irgendwann war ich die (Fehl-) Versuche mit MySQL
einfach leid (ständig neue/andere Dinge, an denen es klemmte...).

Es scheint nicht ohne weiteres möglich zu sein, MySQL /überhaupt/ in der
32-Bit Version unter einem 64-Bit OS ans Laufen zu kriegen. Damit hatte
ich nicht gerechnet, die frühere Installation unter 32 Bit lief
problemlos "nach Lehrbuch"...

Finales Vorgehen also:
- auf dem alten Server Update auf den aktuellen hMailServer 5.6.7
  (das ist schmerzfrei und man hat beim Import keinen Versionssprung)
- dann dort ein Datenexport
- auf dem neuen Server Neuinstallation von hMailServer 5.6.7 unter
  Verwendung der integrierten MSSQLCE Datenbank
- Import der Daten vom alten Server
- Firewall-Freigaben nicht vergessen... :-)
- läuft!


Ingrid

[toc] | [prev] | [next] | [standalone]

#6171

Tilmann Reh:

> Ich schrieb:
> 
>> wir ersetzen gerade einen alten Server durch einen neuen (neue Hardware,
>> aktuelles OS).
>>
>> Der in einer eigenen VM laufende hMailServer (bisher Version 5.5.1) soll
>> dabei auch das Update auf die aktuelle Version 5.6.7 bekommen, ebenso
>> MySQL das fällige Update von 5.6.15 auf 8.0.19.
>>
>> Ich werde aus den gefundenen Hinweisen nicht ganz schlau, ob man nun
>> tatsächlich (immer noch?) die Portierung auf den neuen Server zunächst
>> "absolut 1:1" durchführen sollte und dann später das Update machen -
>> oder ob es doch möglich ist, auf dem alten Server die Daten zu
>> sichern/exportieren und dann in der (aktuellen) Neuinstallation einfach
>> wieder einzulesen...
>>
>> Hat hier jemand vielleicht praktische Erfahrungen damit und kann
>> berichten, was evtl. zu beachten ist?
> 
> Für die Nachwelt:
> 
> Der Umzug unter Beibehaltung von MySQL gestaltet sich extrem schwierig:
> bei MySQL hat man vor einiger Zeit einen radikalen Schnitt zu x64
> vollzogen, es gibt keine 32-Bit Versionen mehr. Selbst die originale
> alte Installationsdatei, die auf dem alten Server verwendet wurde,
> erkennt das zugrundeliegende 64-Bit OS und zieht sich bei der
> Installation neue Komponenten, die dann von hMailServer nicht verwendet
> werden können (denn den gibt es bislang nur in 32 Bit).
> 
> Der Versuch, das alte 32-Bit MySQL aus dem zip zu installieren,
> scheiterte an irgendwelchen fehlenden DLLs - insgesamt ist das eine
> mühsame Angelegenheit, irgendwann war ich die (Fehl-) Versuche mit MySQL
> einfach leid (ständig neue/andere Dinge, an denen es klemmte...).
> 
> Es scheint nicht ohne weiteres möglich zu sein, MySQL /überhaupt/ in der
> 32-Bit Version unter einem 64-Bit OS ans Laufen zu kriegen. Damit hatte
> ich nicht gerechnet, die frühere Installation unter 32 Bit lief
> problemlos "nach Lehrbuch"...

Und wieso muss es unbedingt eine 32-Bit-Version unter einem 64-Bit-OS
sein? Für die Nutzung durch andere Programme ist es völlig egal, ob die
Datenbank selbst als 32- oder 64-Bit-Version installiert ist. Die
Kommunikation findet über TCP Port 3306 statt.

Aber wenn es unbedingt 32 Bit sein soll:

MariaDB gibt es auch noch als 32-Bit-Version für Windwos und das kann
als direkter Ersatz zu MySQL verwendet werden, was ich auch empfehle, da
MariaDB als faktischer Nachfolger zu MySQL angesehen werden kann:

<https://downloads.mariadb.org/mariadb/10.5.2/>

> Finales Vorgehen also:
> - auf dem alten Server Update auf den aktuellen hMailServer 5.6.7
>   (das ist schmerzfrei und man hat beim Import keinen Versionssprung)
> - dann dort ein Datenexport
> - auf dem neuen Server Neuinstallation von hMailServer 5.6.7 unter
>   Verwendung der integrierten MSSQLCE Datenbank

Microsoft SQL CE ist aber auch schon *sehr* abgehangen und ist schon
seit 7 Jahren offiziell abgekündigt. Für ein produktives System würde
ich das nicht mehr nutzen.

-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#6172

Am 28.03.2020 um 15:31 schrieb Arno Welzel:

> Tilmann Reh:
>> Es scheint nicht ohne weiteres möglich zu sein, MySQL /überhaupt/ in der
>> 32-Bit Version unter einem 64-Bit OS ans Laufen zu kriegen. Damit hatte
>> ich nicht gerechnet, die frühere Installation unter 32 Bit lief
>> problemlos "nach Lehrbuch"...
> 
> Und wieso muss es unbedingt eine 32-Bit-Version unter einem 64-Bit-OS
> sein? Für die Nutzung durch andere Programme ist es völlig egal, ob die
> Datenbank selbst als 32- oder 64-Bit-Version installiert ist. Die
> Kommunikation findet über TCP Port 3306 statt.

hMailServer braucht als (derzeit noch) 32-Bit Programm zwingend die
32-Bit DLL von MySQL für den Datenbankzugriff.

>> - auf dem neuen Server Neuinstallation von hMailServer 5.6.7 unter
>>   Verwendung der integrierten MSSQLCE Datenbank
> 
> Microsoft SQL CE ist aber auch schon *sehr* abgehangen und ist schon
> seit 7 Jahren offiziell abgekündigt. Für ein produktives System würde
> ich das nicht mehr nutzen.

Diese Datenbank ist (wie erwähnt) in hMailServer integriert und wird
daher nicht separat installiert. Solange sie nur von diesem verwendet
wird (was hier gegeben ist) und da das ein "eingespieltes Team" ist,
sehe ich hierin derzeit keinen gravierenden Nachteil.

Tilmann

[toc] | [prev] | [next] | [standalone]

#6173

Tilmann Reh:

> Am 28.03.2020 um 15:31 schrieb Arno Welzel:
> 
>> Tilmann Reh:
>>> Es scheint nicht ohne weiteres möglich zu sein, MySQL /überhaupt/ in der
>>> 32-Bit Version unter einem 64-Bit OS ans Laufen zu kriegen. Damit hatte
>>> ich nicht gerechnet, die frühere Installation unter 32 Bit lief
>>> problemlos "nach Lehrbuch"...
>>
>> Und wieso muss es unbedingt eine 32-Bit-Version unter einem 64-Bit-OS
>> sein? Für die Nutzung durch andere Programme ist es völlig egal, ob die
>> Datenbank selbst als 32- oder 64-Bit-Version installiert ist. Die
>> Kommunikation findet über TCP Port 3306 statt.
> 
> hMailServer braucht als (derzeit noch) 32-Bit Programm zwingend die
> 32-Bit DLL von MySQL für den Datenbankzugriff.

Ich hätte erwartet, dass ein Programm, was MySQL benutzt, einfach nur
auf Port 3306 mit dem MySQL-Server kommuniziert. Eine DLL sollte dafür
nicht erforderlich sein. Auch ODBC wurde schon vor über 20 Jahren
eingeführt.

>>> - auf dem neuen Server Neuinstallation von hMailServer 5.6.7 unter
>>>   Verwendung der integrierten MSSQLCE Datenbank
>>
>> Microsoft SQL CE ist aber auch schon *sehr* abgehangen und ist schon
>> seit 7 Jahren offiziell abgekündigt. Für ein produktives System würde
>> ich das nicht mehr nutzen.
> 
> Diese Datenbank ist (wie erwähnt) in hMailServer integriert und wird
> daher nicht separat installiert. Solange sie nur von diesem verwendet
> wird (was hier gegeben ist) und da das ein "eingespieltes Team" ist,
> sehe ich hierin derzeit keinen gravierenden Nachteil.

Ich habe es nur erwähnt, weil die Wahrscheinlichkeit hoch ist, dass das
es irgendwann so gar nicht mehr läuft.



-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#6174

On 2020-03-29 03:56, Arno Welzel <usenet@arnowelzel.de> wrote:
> Tilmann Reh:
>> hMailServer braucht als (derzeit noch) 32-Bit Programm zwingend die
>> 32-Bit DLL von MySQL für den Datenbankzugriff.
>
> Ich hätte erwartet, dass ein Programm, was MySQL benutzt, einfach nur
> auf Port 3306 mit dem MySQL-Server kommuniziert.

Und das MySQL-Protokoll selbst implementiert?

> Eine DLL sollte dafür nicht erforderlich sein.

Kein Anwendungsentwickler implementiert ein Datenbank-Netzwerkprotoll
selbst. Der verwendet die vom Datenbankhersteller mitgelieferte Library.

> Auch ODBC wurde schon vor über 20 Jahren eingeführt.

ODBC ist nur ein API-Layer, der die entsprechende Datenbank-abhängige
DLL lädt und deren Funktionen aufruft. Was zur Folge hat, dass eine
32-Bit-Windows-Applikation nur 32-Bit-ODBC und damit nur
32-Bit-Datenbank-Treiber verwenden kann (und ebenso für 64 Bit;
netterweise sind auch die Konfigurationsprogramme getrennt, was zu
lustigen Anrufen beim Support führt).

Ähnliches gilt übrigens auch in der Linux-Welt: Wenn Du da in Perl,
Python oder PHP eine Connection zu MySQL aufmachst, ist zwar kein ODBC
dazwischen, aber es wird auch einfach die shared library geladen und
verwendet.

Java ist ein bisschen anders: Da gibt es üblicherweise für jedes
Datenbankprotokoll eine Implementation in Java. Aber auch die gibt es
einmal vom Hersteller und der Anwendungsentwickler implementiert das
nicht neu.

        hp

[toc] | [prev] | [next] | [standalone]

#6175

Peter J. Holzer <hjp-usenet3@hjp.at> schrieb:

> Ähnliches gilt übrigens auch in der Linux-Welt: Wenn Du da in Perl,
> Python oder PHP eine Connection zu MySQL aufmachst, ist zwar kein ODBC
> dazwischen, aber es wird auch einfach die shared library geladen und
> verwendet.

Was so kategorisch nicht stimmt. Für Python gibt es z.B. diverse
Treiberimplementierungen in pure python, die die Datenbank client
libraries nicht verwenden und benötigen.

Bestes Beispiel ist mysql-connector direkt von Oracle/mysql - das
beinhaltet beide Varianten.

Bei anderen Datenbanken wie postgres genauso. Manche Python Treiber
setzen auf den nativen Datenbank client libraries auf (z.b. psycopg2) -
andere dagegen nicht.

Schnellster Python Treiber für postgres ist z.B. augenblicklich
vermutlich asyncpg und das implementiert das Protokoll selber und
benötigt keinerlei client library für postgres (libpq).

Ähnlich sieht es bei go aus. Die pgx Treiber für postgres implementieren
auch alles selber (in diversen Modulen - pgconn entspricht dabei etwa
libpq).

Zu php kann ich nichts sagen.

> Java ist ein bisschen anders: Da gibt es üblicherweise für jedes
> Datenbankprotokoll eine Implementation in Java. Aber auch die gibt es
> einmal vom Hersteller und der Anwendungsentwickler implementiert das
> nicht neu.

Sag das mal nicht. NIH (not invented here) Syndrom ist nicht zu
unterschätzen.

Deine (hier rausgekürzte) Beschreibung von ODBC war allerdings
korrekt. ODBC ist die Seuche.


Gruß,

Marcus
⚂⚃

[toc] | [prev] | [next] | [standalone]

#6176

Peter J. Holzer:

> On 2020-03-29 03:56, Arno Welzel <usenet@arnowelzel.de> wrote:
>> Tilmann Reh:
>>> hMailServer braucht als (derzeit noch) 32-Bit Programm zwingend die
>>> 32-Bit DLL von MySQL für den Datenbankzugriff.
>>
>> Ich hätte erwartet, dass ein Programm, was MySQL benutzt, einfach nur
>> auf Port 3306 mit dem MySQL-Server kommuniziert.
> 
> Und das MySQL-Protokoll selbst implementiert?

Nein, wieso?

>> Eine DLL sollte dafür nicht erforderlich sein.
> 
> Kein Anwendungsentwickler implementiert ein Datenbank-Netzwerkprotoll
> selbst. Der verwendet die vom Datenbankhersteller mitgelieferte Library.

Die man auch mit der Anwendung mitliefern kann oder die unabhängig vom
Server bereitgestellt werden kann. Wie gesagt: die Kommunikation erfolgt
über einen TCP-Port. Ob der von einer 32- oder 64-Bit-DLL bedient wird,
ist dem Server egal.

>> Auch ODBC wurde schon vor über 20 Jahren eingeführt.
> 
> ODBC ist nur ein API-Layer, der die entsprechende Datenbank-abhängige
> DLL lädt und deren Funktionen aufruft. Was zur Folge hat, dass eine
> 32-Bit-Windows-Applikation nur 32-Bit-ODBC und damit nur
> 32-Bit-Datenbank-Treiber verwenden kann (und ebenso für 64 Bit;
> netterweise sind auch die Konfigurationsprogramme getrennt, was zu
> lustigen Anrufen beim Support führt).

Aber auch da ist es nicht nötig, den *Server* als 32-Bit-Version zu
haben, nur weil man den *Client* als 32-Bit nutzt. Die DLL des *Client*
hat mit dem *Server nichts zu tun.

Und wie ich ja erwähnt habe, gibt es MariaDB auch weiterhin als
32-Bit-Version.


-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#6182

On 2020-03-30 16:25, Arno Welzel <usenet@arnowelzel.de> wrote:
> Peter J. Holzer:
>
>> On 2020-03-29 03:56, Arno Welzel <usenet@arnowelzel.de> wrote:
>>> Tilmann Reh:
>>>> hMailServer braucht als (derzeit noch) 32-Bit Programm zwingend die
>>>> 32-Bit DLL von MySQL für den Datenbankzugriff.
>>>
>>> Ich hätte erwartet, dass ein Programm, was MySQL benutzt, einfach nur
>>> auf Port 3306 mit dem MySQL-Server kommuniziert.
>> 
>> Und das MySQL-Protokoll selbst implementiert?
>
> Nein, wieso?

Weil das Connecten auf den richtigen Port nur der Anfang der
Kommunikation ist ...

>
>>> Eine DLL sollte dafür nicht erforderlich sein.

... und wenn Du den Code, der das implementiert, nicht von jemandem
anderen beziehst (muss nicht unbedingt als DLL sein, wird unter Windows
aber normalerweise der Fall sein), dann musst Du ihn selber schreiben.


>> Kein Anwendungsentwickler implementiert ein Datenbank-Netzwerkprotoll
>> selbst. Der verwendet die vom Datenbankhersteller mitgelieferte Library.
>
> Die man auch mit der Anwendung mitliefern kann oder die unabhängig vom
> Server bereitgestellt werden kann. Wie gesagt: die Kommunikation erfolgt
> über einen TCP-Port. Ob der von einer 32- oder 64-Bit-DLL bedient wird,
> ist dem Server egal.

Natürlich ist das dem Server egal. Aber der Client braucht die DLL (oder
äquivalenten Code).


> Aber auch da ist es nicht nötig, den *Server* als 32-Bit-Version zu
> haben, nur weil man den *Client* als 32-Bit nutzt. Die DLL des *Client*
> hat mit dem *Server nichts zu tun.

Hat ja auch niemand behauptet. Du hast geschrieben, dass "ein Programm,
was MySQL benutzt" (also der Client) keine DLL braucht.

        hp

[toc] | [prev] | [next] | [standalone]

#6185

Peter J. Holzer:

> On 2020-03-30 16:25, Arno Welzel <usenet@arnowelzel.de> wrote:
[...]
>> Aber auch da ist es nicht nötig, den *Server* als 32-Bit-Version zu
>> haben, nur weil man den *Client* als 32-Bit nutzt. Die DLL des *Client*
>> hat mit dem *Server nichts zu tun.
> 
> Hat ja auch niemand behauptet. Du hast geschrieben, dass "ein Programm,

Doch, genau *das* wurde behauptet auf die Frage, wieso der
MySQL-Server(!) als 32-Bit-Version vorliegen muss:

"hMailServer braucht als (derzeit noch) 32-Bit Programm zwingend die
32-Bit DLL von MySQL für den Datenbankzugriff."

> was MySQL benutzt" (also der Client) keine DLL braucht.

Ich meinte damit keine DLL des *Servers*. Eine MySQL-DLL für den
*Client* kann man unabhängig vom Server bereitstellen.


-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#6188

On 2020-04-01 14:56, Arno Welzel <usenet@arnowelzel.de> wrote:
> Peter J. Holzer:
>> On 2020-03-30 16:25, Arno Welzel <usenet@arnowelzel.de> wrote:
>>> Aber auch da ist es nicht nötig, den *Server* als 32-Bit-Version zu
>>> haben, nur weil man den *Client* als 32-Bit nutzt. Die DLL des *Client*
>>> hat mit dem *Server nichts zu tun.
>> 
>> Hat ja auch niemand behauptet. Du hast geschrieben, dass "ein Programm,
>
> Doch, genau *das* wurde behauptet auf die Frage, wieso der
> MySQL-Server(!) als 32-Bit-Version vorliegen muss:
>
> "hMailServer braucht als (derzeit noch) 32-Bit Programm zwingend die
> 32-Bit DLL von MySQL für den Datenbankzugriff."

Eben: "die 32-Bit DLL von MySQL". Nicht "den 32-Bit Server".

>> was MySQL benutzt" (also der Client) keine DLL braucht.
>
> Ich meinte damit keine DLL des *Servers*.

Was soll das sein? (Nein, ich erwarte keine Antwort darauf)

        hp

[toc] | [prev] | [next] | [standalone]

#6189

Peter J. Holzer:

> On 2020-04-01 14:56, Arno Welzel <usenet@arnowelzel.de> wrote:
>> Peter J. Holzer:
>>> On 2020-03-30 16:25, Arno Welzel <usenet@arnowelzel.de> wrote:
>>>> Aber auch da ist es nicht nötig, den *Server* als 32-Bit-Version zu
>>>> haben, nur weil man den *Client* als 32-Bit nutzt. Die DLL des *Client*
>>>> hat mit dem *Server nichts zu tun.
>>>
>>> Hat ja auch niemand behauptet. Du hast geschrieben, dass "ein Programm,
>>
>> Doch, genau *das* wurde behauptet auf die Frage, wieso der
>> MySQL-Server(!) als 32-Bit-Version vorliegen muss:
>>
>> "hMailServer braucht als (derzeit noch) 32-Bit Programm zwingend die
>> 32-Bit DLL von MySQL für den Datenbankzugriff."
> 
> Eben: "die 32-Bit DLL von MySQL". Nicht "den 32-Bit Server".

Und dafür wollte der OP aber den *Server* als 32-Bit haben.

>>> was MySQL benutzt" (also der Client) keine DLL braucht.
>>
>> Ich meinte damit keine DLL des *Servers*.
> 
> Was soll das sein? (Nein, ich erwarte keine Antwort darauf)

Siehe oben.


-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [standalone]

Back to top | Article view | de.comm.software.mailserver

csiph-web