Fehlermeldung beim Löschen von Webseiten

Dieses Thema im Forum "Installation und Konfiguration" wurde erstellt von ramsys, 3. Nov. 2014.

  1. ramsys

    ramsys Member

    Wenn ich in ISPConfig (Multiserver-Setup) eine Webseite lösche, wird im System-Protokoll folgendes eingetragen:
    Auf dem Server wird die Domain ordnungsgemäß in "/var/www" und auch die Datenbank in "/var/lib/mysql" gelöscht. Ebenso in den Tabellen "web_database", "web_database_user" und "web_domain", sowohl im Master als auch auf dem Slave.

    Nur im Verzeichnis "/var/backup" bleiben die Backups erhalten.

    Die Spalten der vor genannten Tabellen entsprechen der ispconfig3.sql aus dem Git stable-3.0.5-Branch. Hat jemand eine Idee, wo ich noch suchen könnte?
     
  2. Till

    Till Administrator

    Hmm, gute Frage. Mach doch mal eine Volltextsuche nach "DELETE FROM `web_database_user` WHERE" um quelltext, es kann ja nicht allzu viele stellen geben, an der das steht. Und dann mal sehen waraus der where teil besteht und warum er leer sein könnte.
     
  3. ramsys

    ramsys Member

    ...gute Idee :)

    Es gibt im gesamten Code nur eine einzige Stelle, und zwar in in Zeile 58 von "interface/web/sites/database_user_del.php" ($index_field):
    PHP:
    class page_action extends tform_actions {
        function 
    onBeforeDelete() {
            global 
    $app$conf;
            if(
    $app->tform->checkPerm($this->id'd') == false$app->error($app->lng('error_no_delete_permission'));

            
    $old_record $app->tform->getDataRecord($this->id);

            
    /* we cannot use datalogDelete here, as we need to set server_id to 0 */
            
    $app->db->query("DELETE FROM `web_database_user` WHERE $index_field = '$index_value'");
            
    $new_rec = array();
            
    $old_record['server_id'] = 0;
            
    $app->db->datalogSave('web_database_user''DELETE''database_user_id'$this->id$old_record$new_rec);
        }
     
  4. Till

    Till Administrator

    Hmm, da passt doch was nicht. Ich habe es mal in den Bugtracker gschoben. Ich glaube wir haben das als event listener neu programmiert, möglicherweise ist das alter code. das würde auch erklären warum es trotzdem geht.
     
  5. ramsys

    ramsys Member

  6. ramsys

    ramsys Member

    Noch eine ergänzende Frage:

    Dass die Backups nicht gelöscht werden, hat das mit dem hier genannten Problem zu tun oder ist das ein Standardverhalten von ISPConfig und das Backup-Verzeichnis muss generell manuell gelöscht werden?
     
  7. Till

    Till Administrator

    Mit dem Problem hier hat das nichts zu tun. Wenn ich mich recht entsinne hatten wir die absichtlich nicht gelöscht, da es ab und zu mal vorkommt dass jemand eine seite aus versehen löscht und wenn die Backups dann auch gleich mit weg sind, wäre das schon schlecht.
     
  8. ramsys

    ramsys Member

    Und die Tabelle web_backup wird dann nicht durch Aktionen in ISPConfig geschrieben, sondern holt sich die Einträge durch einen Check des Filesystems? Soll heißen, wenn ein Backup bzw. das komplette Backup-Verzeichnis also manuell gelöscht werden muss, wird die Tabelle web_backup automatisch beim nächsten Dailycron aktualisiert?
     
  9. florian030

    florian030 Member

    In der nächsten Version ist, wenn ich mich nicht gerade extrem täusche, eine Option vorhanden, die dem Admin erlaubt, die Backups zusammen mit einer Domain automatisch zu löschen. Kann man machen, ich finde das aber eher riskant.
     
  10. ramsys

    ramsys Member

    Grundsätzlich hat es natürlich Vorteile, das Backup-Verzeichnis zunächst zu erhalten. Allerdings kann ein Endkunde ja im Rahmen seiner Limits beliebig Webseiten anlegen und löschen sowie bis zu zehn Backups erstellen lassen - ohne Kenntnis des Admin. Irgendwann läuft der Server dann voll und es ist ziemlich aufwändig und vor allem fehleranfällig manuell zu prüfen, welches Backup denn nun gelöscht werden könnte.

    Das löst aber nicht das Problem, verwaiste Backups auf dem Server zu löschen. Und eine Umstellung auf "Backups gleich löschen" (sofern man das tatsächlich möchte) greift auch nur für die Zukunft und berührt keine vorhandenen Backups.

    Sinnvoller als eine reine Ja/Nein-Lösung wäre die automatische Löschung nach einer bestimmten (einstellbaren) Anzahl von Tagen.
     
  11. florian030

    florian030 Member

    Du kannst doch mit einem Script problemlos testen, ob die zum Backup gehörenden Domains noch existieren. Jedes Backup liegt in einem eigenen Verzeichnis und die haben "zufällig" den Namen web$parent_domain_id.
    Du musst nur /var/backup/web* mit bspw. "ls /var/backup|grep web" einlesen und dann nachsehen, ob eine entsprechende Domain existiert. Mit "find -P /var/www -maxdepth 1 -type l -exec echo -n "{} -> " \; -exec readlink {} \;" bekommst Du alle symlinks aus /var/www aufgelistet. In der Liste kannst Du dan nach $parent_domain_id suchen.
    Das sollte per bash in ein paar Minuten zu schaffen sein.
     
  12. ramsys

    ramsys Member

    Korrekt - und wenn man das gleich in die cron_daily.php packt und noch den Timestamp berücksichtigt wäre es perfekt. Wenn gerade sowieso an dieser Funktion gearbeitet wird, vielleicht kann man ja etwas derartiges noch integrieren :)
     
  13. florian030

    florian030 Member

    Ich denke, dass ist etwas überzogen. Dann müsstest Du zusätzlich noch ein Interval im Interface definieren. Das kann auch ein shell-script mit ein paar Zeilen. Sinnvoller wäre es wohl, eine Art clean-up-script in das Archiv zu packen, dass dann per Hand angepasst werden kann. Ich persönlich bin aber mehr an einem wrapper-script interessiert, um die einzelnen Cron-Jobs von ISPConfig manuell ausführen zu können (bspw. zwischendurch das Backup anstossen).
     
  14. ramsys

    ramsys Member

    Ein zusätzlicher Tab "Wartung" im Interface unter Serverkonfiguration des jeweiligen Servers, wo die einzelnen Scripte (de)aktiviert werden können. Außerdem wird ein custom-Verzeichnis nach individuellen Scripten durchsucht. Für den Start kann eine Uhrzeit angegeben werden sowie die Möglichkeit der manuellen Ausführung.
     

Diese Seite empfehlen