Re: mariadb client server conflict

From: Harold Gutch <logix(at)foobar.franken.de>
Date: Fri, 26 Jan 2018 10:09:26 +0100

Hi,

On Fri, Jan 26, 2018 at 08:59:54AM +0100, Matthias Fechner wrote:
> Hallo Sascha,
>
> Am 25.01.2018 10:06, schrieb Sascha Hüdepohl:
> >* Harold Gutch (logix(at)foobar.franken.de) schrieb:
> >
> >> # portsnap fetch update
> >> # portmaster mariadb102-server
> >> # portmaster mariadb102-client
> >> # portmaster -a
> >
> >Meine Sorge ist hauptsächlich, was ich mache wenn das auf einem
> >produktiven System passiert.
>
> ganz ehrlich, ich würde niemals portmaster oder sonst ein Tool auf einem
> Produktionsserver verwenden.
> Bau dir einen Buildserver mit poudriere und bau dort alle Ports die Du
> brauchst.
>
> Dann mach die Updates mit `pkg upgrade` auf einem Testsystem und wenn
> dort alles klappt, ein `pkg upgrade` auf dem Produktionssystem.

Naja, das hat jetzt aber weniger was mit Portmaster zu tun, dein
Argument ist ja eher "bevor man auf einem Produktivsystem einfach
'portmaster -a' ausführt sollte man das erst auf einem Testsystem
testen". Wenn "portmaster X" im Testsystem funktioniert gibt es keinen
Grund wieso das im Produktivsystem schief gehen sollte - zumindest
wenn man überall gleiche Versionen voraussetzt. Und falls doch dann
eher schon beim Compilieren (und dann ist noch nichts passiert) und
nicht erst bei der Installation.

Wichtiger als das alles ist meiner Meinung nach das Behalten von
Backup-Paketen (ob die jetzt mit "portmaster -b" oder sonstwie
erstellt wurden ist eher egal), um im Zweifelsfall ein kaputtes Update
wieder rückgängig zu machen. Dass Version X eines Ports die auf
FreeBSD Version Y gebaut wurde auch heute noch auf FreeBSD Version Z
compiliert ist nämlich schon nicht mehr ganz so klar. Und ohne
Backup-Paket hat man dann ein kleines Problem (selbst wenn man den
Inhalt des Ports aus einem "normalen" Backup noch extrahieren kann,
muss man sich dann noch um die jetzt inkonsistente Ports-Datenbank
kümmern). Und es muss ja nicht mal etwas bei der Installation des
Ports als solches schief gehen, das kann alles klappen, aber die neue
Version ist in irgendeinem Sinn schlechter als die alte, sei es dass
irgendein Feature nicht mehr unterstützt wird, die neuere Version
deutlich langsamer ist oder sonstwas.

Aber wenn man das Paket schon mal im Testsystem (oder in einem
Buildsystem) gebaut hat, dann kann man natürlich wie du schon sagst
auch gleich das Paket im Produktivsystem installieren und muss es
nicht dort *nochmal* compilieren. Im Prinzip sind separate Systeme
(und sei es nur in Jails) für Build, Test und Produktion auf jeden
Fall eine gute Idee.

Gruß,
  Harold

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Fri 26 Jan 2018 - 10:09:35 CET

search this site