Transactionale Dateien sperren, ist das so weit ok?


#1

Hallo Zusammen,

nach dem ich jetzt einen neuen Server UBUNTU 18.04 habe und ich meine OC Instanz am laufen bekommen habe, habe ich mich auch endlich mit dem Thema: " Transactionale Dateien sperren" beschäftigt!

Hierbei bin ich folgender Anleitung gefolgt: Redis in Ubuntu 18.04 für PHP

Meine config.php sieht jetzt so aus:

vorformatierten Text mit 4 Leerzeichen einrücken <?php

$CONFIG = array (
‘memcache.distributed’ => ‘\OC\Memcache\Redis’,
‘memcache.locking’ => ‘\OC\Memcache\Redis’,
‘redis’ =>
array (
‘host’ => ‘localhost’,
‘port’ => 6379,
‘timeout’ => 0,
‘dbindex’ => 0,
),

‘memcache.local’ => ‘\OC\Memcache\APC’,
‘activity_expire_days’ => 30,
/‘memcache.locking’ => ‘\OC\Memcache\Redis’,/
‘filelocking.enabled’ => true,
‘instanceid’ => ‘hfhtttrutrurtutur’,
‘passwordsalt’ => ‘turtrurutruutruuruuurtu’,
‘secret’ => ‘trutruutruutruurtuurtuuruu’,
‘datadirectory’ => ‘/var/www/owncloud/data’,
‘overwrite.cli.url’ => ‘http://localhost/owncloud’,
‘dbtype’ => ‘mysql’,
‘version’ => ‘10.0.10.4’,
‘installed’ => true,
‘mail_from_address’ => ‘cloud’,
‘mail_smtpmode’ => ‘smtp’,
‘mail_domain’ => ‘meine DOM.eu’,
‘theme’ => ‘Mein Name’,
‘maintenance’ => false,
‘trusted_domains’ =>
array (
0 => ‘192.168.178.245’,
1 => ‘meine DOM.eu’,
),
‘mail_smtpauthtype’ => ‘LOGIN’,
‘mail_smtpauth’ => 1,
‘mail_smtphost’ => ‘SMTP.Strato.de’,
‘mail_smtpport’ => ‘465’,
‘mail_smtpname’ => ‘cloud@meine DOM.eu’,
‘mail_smtppassword’ => ‘Passwort’,
‘loglevel’ => 0,
‘appstore.experimental.enabled’ => true,
‘trashbin_retention_obligation’ => ‘auto’,
‘dbname’ => ‘OwnCloud’,
‘dbhost’ => ‘127.0.0.1’,
‘dbuser’ => ‘AdminBenutzername’,
‘dbpassword’ => ‘passwort’,
‘mail_smtpsecure’ => ‘ssl’,
);

Meine Frage ist nun, müsste nicht unter Serverstatus stehen, dass Transactionale Dateien sperre aktiv ist? Zu mindest habe ich keine Fehlermeldungen mehr unter Einstellungen/Allgemein!

Kurz Antwort wäre lieb danke :slight_smile:


#2

Einträge über das transactional file locking werden nur dann angezeigt, wenn es nicht aktiv ist (und dies auch nur in Sicherheits- & Einrichtungswarnungen). Im Systemstatus selbst wird immer nur eine Grundinformation angezeigt, unabhänging von erfolgreichen bzw. fehlerhaften Einstellungen.

Wenn also in den Administrator-Einstellungen keine Anzeige über einen Fehler mehr erscheint und auch die Logs leer sind, dann passt alles :slight_smile:


#3

Danke :slight_smile:


#4

Mist Mist Mist… jetzt habe ich es wohl zu Gut gemeint, habe im Testlauf den neuen Server so gut angepasst, dass mir jetzt, wenn ich dass entgültig data rüber kopiere und die aktuelle DB vom alten Server importiere, OC meldet, dass er ein occ Upgrade machen will.

Ich also diese Ausgeführt und erst mal die Apps via OCC deak. Dann legt er los und nach einer Stunde steht er immer noch bei Integration Check. Kann das sein?

Die Maschine ist zum Glück eine VM so kann ich immer wieder zurück!

Die Version ist die gleiche, Apps alle deaktiviert, wie bekomme ich das Ding wieder ans laufen?

Hätte ich vieleicht Redis für Transaktionales Sperren nicht vorher konfigurieren sollen?

Hätte ich vieleicht Der “Strict-Transport-Security” HTTP-Header nicht konfigurieren sollen?

Hätte ich vieleicht Antivirus App nicht vorher installieren sollen?

Was habe ich vorher geamcht, vieleicht liegt hier der Fehler? Wobei das geklappt hat…

  • Apache2.4 (War vorher 2.2, MariaSQL, PHP 7.2 (War vorher 5.6) installiert und Konfiguriert!
  • Pfade exact die gleichen auf den neuen Server, wie auf dem alten
  • OC Dir ohne data einfach rüber kopiert
  • data Dir neu angelegt manuell und Admin Account und einen TestUser rüber kopiert inkl. Systemordner und Dateien aus data.
  • Rechte neue vergeben für ww-data

Ja was soll man sagen, das ging sofort! Cloud lief sofort und 5 x so schnell wie vorher. Aber jetzt klappt das Ganze nicht mehr wenn ich die OC DB lösche und neu erstell und importiere. Restlichen data Ordner der User habe ich auch rüber gezogen und rechte vergeben.

Jetzt will er aber nicht mehr… bin frustiert…

Hat jemand eine Idee? Wäre super!


#5

Redis und HTTP-Header empfinde ich als unbedenklich.
files_antivirus kurzfristig zu deaktivieren kann auf jeden Fall nicht schaden. Die Dokumentation spricht sogar davon, vor einem Upgrade alle 3rd party apps zu deaktivieren: https://doc.owncloud.com/server/admin_manual/maintenance/upgrade.html#prerequisites

Ich würde auf der neuen Installation auch gleich das aktuelle OC 10.1.1 nehmen.

Die spannendste Frage: was steht im owncloud.log beim Upgrade? Das würde uns sicher auf die Sprünge helfen.


#6

Hallo Cortho,

ich habe das Problem gerade vor 10 Min. gelöst bekommen! Mein Vorgehen war einfach falsch!

Ich habe immer erst die OC Daten inkl. Konfig auf den aktuellen Stand gebracht, dann die data auch und immer wieder versucht, vom alten Server die aktualisierte DB und Daten zu übernehmen. Grund ist, dass dies jetzt nur ein Testlauf war und der Umzug schnell gehen muss. Bei 500 GB an Daten dauert das Ganze ja etwas. Daher wollte ich die Zeit verkürzen, mit einem angepassen Sync. der Daten der Benutzer, so dass der eigentlich Umzug schnell geht, da nur die aktualisierten Daten rüber müssen!

Die Lösung ist…

  1. Alten Server im Wartungsmodus
  2. DB und Data ab auf den neuen rüber kopieren bzw. Import DB
  3. die OC Konfig und alle anderen Daten, damit meine ich alles im Root-Dir von OC ausser data übernehmen, also den ganzen alten Mist
  4. www-data Rechte auf OC Root-Dir geben
  5. Als Admin anmelden in GUI und Anpassungen und optimierung vornehmen

Man will es nicht glauben aber dann läuft es…

Danke für deine Hilfe :slight_smile:


#7

Freut mich, dass es letztlich geklappt hat. Die exakte Vorgangsweise für Migrationen ist btw unter https://doc.owncloud.org/server/admin_manual/maintenance/migrating.html bestens dokumentiert.