Beiträge von riedlit

    Ich denke dann wäre es schön, wenn da eine Möglichkeit gefunden würde.
    Ggf. könnte ja eine Zwischenmigration auf 5.6 in dem SE-Script eingebaut werden.
    Um MySQL 5.7 nutzen zu können alles neu zu installieren, ist doch ziemlich lästig und ewig bei 5.5 bleiben ist sicher auch keine Lösung.

    Herr Bradler, haben Sie vor, hier einen derartigen Upgrade-Pfad anzubieten in einer der nächsten SE Updates?

    LG & vielen Dank!

    Hallo,


    die Config von QMAIL hat sich ja seit dem Initialpost geändert. Wie würde da die Spamdyke Integration aussehen?


    Würde es so passen?

    Code
    exec /usr/local/bin/softlimit -m 50000000 \
         /usr/local/bin/tcpserver -j -x /etc/tcp.smtp.cdb -h -P -R -u $QMAILDUID \
         -g $NOFILESGID -c $MAXCONN -v 0 smtp \
         /usr/local/bin/spamdyke -f /etc/spamdyke.conf \
         /var/qmail/bin/qmail-smtpd $HOSTNAME \
         /usr/local/pd-admin2/bin/checksmtppasswd /bin/true 2>&1


    Der Grund warum ich frage: mir filtert Spamdyke nichts mehr auf einem neu installierten Host mit dovecot und SSL.


    Danke, LG

    Hallo,


    wie setzt ihr das mit der aktuellen qmail RUN um?


    hat auch jemand von euch erfahrung bei der Verwendung von /var/qmail/control/blacklists ?


    Anscheinend passt hier nämlich die qmail-version nicht da er nicht weiß, was mit der datei gemacht werden soll...


    Wie habt ihr in der aktuellen Version Blocklisten integriert?

    Zitat

    Original von Blueroot
    Achtung: Bei mir geht der Login bei pd-admin 4 nicht mit Debian 9. Es kommt immer ein "internal server error" ohne weitere Infos in der Log.


    Hallo, wie hast du den Fehler gelöst?


    Bei mir erscheint im error_log dieser Fehler:

    Code
    Premature end of script headers: administrator.cgi,
    Zitat

    Original von Eisenherz
    Also ich würde lieber an Herrn Bradler appellieren, mal die neue Version einzubauen, denn wenn man selber Veränderungen macht, hat man später immer Ärger damit beim Update. Squirellmail scheint leider wirklich nicht mehr weiterentwickelt zu werden, ich habe es bei DirectAdmin auch schon abgeschaltet und auch unter pd-admin wüsste ich keinen von meinen Kunden, der das noch benutzt.


    Hallo,


    gibt es hierzu ein Update? es gibt ja eine Version 1.0.1 die mit der SE mit kommt. wie kann man auf diese Umstellen? wird diese gewartet?


    Danke

    Also ich konnte es nun zum laufen bekommen, und es sieht so aus, als würde der Server keine PRobleme mehr haben. Jetzt muss ich auf das nächste PDAdmin Update warten, ob danach wieder etwas auftritt und ob ich evtl Rechte oder so übersehen hatte.


    Roundcube habe ich gelöst:
    Dank der Datei /usr/local/pd-admin2/CONFIGURE/roundcube.pl konnte ich die Rechtevergabe finden udn habe die Datenbank manuell erstellt / mit Hilfe einer Datenbank von einer separatne frischen neuinstallation. Nun funktioniert das auch wieder.


    Die anderen User-Datenbanken musste ich leider alle händisch aus diversen Backup-Files selbst zusammensuchen. !Zum Glück! handelte es sich auf diesem Server nur noch um Alt-Bestände von ca 40 Kunden.


    DAnke für die Hilfe nochmals!

    Zitat

    Original von Eisenherz
    Hast Du vorher Courier benutzt und nicht Dovecot?


    Nein, war ebenfalls Dovecot.


    Ich habe herausgefunden das die roundcubemail DB beschädigt war. Nach einem Webmail-Login - der nun wieder klappt - komm ich zumindest im RoundCube jetzt soweit:


    Code
    [B]DATABASE ERROR: CONNECTION FAILED![/B]
    
    
    Unable to connect to the database!
    Please contact your server-administrator.


    Datenbank User und PAsswort passen aber mit denen ind er Roundcube Config überein.

    Also momentan scheint alles wieder zu laufen.


    Das einzige was mir noch aufgefallen ist: bei bestehenden Mail-Konten ist KEIN roundcubemail Login möglich. Folgende Zeile kommt hier im Mail-Log.


    Bei neuen Accounts ist das jedoch möglich - kann mir jemand sagen, in welcher Datei ich prüfen soll, ob alle Rechte passen?


    Code
    Oct  5 10:55:34 w01 dovecot: auth-worker(9043): Warning: mysql: Query failed, retrying: MySQL server has gone away (idled for 52 secs)
    Oct  5 10:55:34 w01 dovecot: auth-worker(9043): Error: mysql(localhost): Connect failed to database (vadmin): Can't connect to local MySQL server through socket '/usr/local/pd-admin2/var/mysql.run/mysql.sock' (111) - waiting for 1 seconds before retry
    Zitat

    Original von Daniel Bradler
    Wenn Sie ein Backup von /home/mysql haben, dann sollten Sie das zurückspielen. Wenn nur Dumps vorliegen, sollten Sie die am besten in eine frische Installation einspielen und dann /home/mysql kopieren.


    ok. ich werde die dumps einfach auf einem anderen system einspielen und dann das verzeichnis kopieren.
    ich habe auch herausgefunden, dass ich jede tabelle einzeln löschen und dann wieder erstellen kann auf der commandline, und so komme ich dann, wenn ich es mit tabellen machen, immer zu diesem text.



    ich weiß nicht ob das gut oder schlecht ist, oder ob ich dann die datenbank dennoch reparieren sollte...


    Code
    InnoDB: a tablespace 40454 of name '.IMMER-DIE-DB-DIE-ICH-MANUEL-RÜCKSICHERE',
    InnoDB: but a tablespace 10387 of the same name
    InnoDB: already exists in the tablespace memory cache!
    InnoDB: We assume that InnoDB did a crash recovery, and you had
    InnoDB: an .ibd file for which the table did not exist in the
    InnoDB: InnoDB internal data dictionary in the ibdata files.
    InnoDB: We assume that you later removed the .ibd and .frm files,
    InnoDB: and are now trying to recreate the table. We now remove the
    InnoDB: conflicting tablespace object from the memory cache and try
    InnoDB: the init again.

    UPDATE:


    jetzt stehe ich da an...


    Code
    InnoDB: Have you moved InnoDB .ibd files around without using the
    InnoDB: commands DISCARD TABLESPACE and IMPORT TABLESPACE?
    InnoDB: It is also possible that this is a temporary table #sql...,
    InnoDB: and MySQL removed the .ibd file for this.
    InnoDB: Please refer to
    InnoDB: http://dev.mysql.com/doc/refman/5.5/en/innodb-troubleshooting-datadict.html
    InnoDB: for how to resolve the issue.
    161004 12:44:39 [Note] Event Scheduler: Loaded 0 events
    161004 12:44:39 [Note] /usr/local/pd-admin2/bin/mysqld: ready for connections.
    Version: '5.5.52'  socket: '/usr/local/pd-admin2/var/mysql.run/mysql.sock'  port: 0  Source distribution

    Danke für die Info. das habe ich vermutet.


    ich hab ein system backup, ein älteres. ebenso eines von vadmin.


    Wie soll ich nun am besten vorgehen? Die Inhalte von /home/mysql vollständig löschen, dann MySQL starten, und dann die mysql.dum sowie die vadmin.dump einspielen, und dann die jeweiligen User-datenbanken?


    Ich bin mir nur nicht sicher, was ich von /home/mysql alles löschen kann.


    Danke für die Info.


    Danke, das hat nun geklappt.


    nachdem ich nun bei einigen Kunden leere Datenbanken hatte, würde ich den Dump nochmal einspielen und das ganze nochmal von vorne machen..


    jetzt meine frage: welche Datensätze soll ich vorher löschen um den mysql.dump aus dem pdadmin-backup wieder einzuspielen?


    wenn ich nämlich den Dump einfach drüberspiele kommt nach einigen Datensätzen das Ergebnis:


    Code
    --
    -- Dumping data for table `session`
    --
    
    
    mysqldump: Couldn't execute 'SELECT /*!40001 SQL_NO_CACHE */ * FROM `session`': Lost connection to MySQL server during query (2013)

    Vielen Dank für die Antwort.
    Wenn ich ein pd-Admin Update ausführe (also die aktuelle Version nochmal update) dann erhalten ich diesen Fehler:



    der 2. Fehler lag tatsächlich an den IP Adressen - die sich durch die defekte DAtenbankverbindung von der vhost-erzeugung nicht geändert hatten.

    Hallo,


    ich musst einen Server wegen einer defekte VHD zwangs-migrieren. Das Problem war, dass die SE von 4-0266 auf 4-0277 aktualisiert wurde (durch die neuinstallation) und ich den alten Server davor nicht mehr upgraden konnte.


    nun habe ich jedoch alle daten soweit migriert und die backups eingespielt. ich erhalte jedoch beim ausführen von

    Code
    /opt/pdadmin/bin/httpd_vhosts.pl


    folgenden fehler:

    Code
    DBD::mysql::st execute failed: Unknown column 't2.hsts' in 'field list' at /opt/pdadmin/bin/httpd_vhosts.pl line 717. cannot execute query 'select t1.name, t1.vhostroot, t2.name, t2.fp, t3.login, t4.php, t4.cgi, t1.ip, t1.catchall, t2.id, t1.id, t2.target, t4.rlimit_cpu, t4.rlimit_nproc, t4.rlimit_as, t3.email, t2.ssl_enabled, t1.ip_old, t1.ip_changed, t2.ssl_active, t4.rlimit_nofile, t2.ip, t3.suspended, t5.login, t3.php5_version, t3.migrate_to, t1.ipv6, t1.ipv6_old, t2.webdav, t4.dedicated_errorlog, t2.hsts from domains as t1, vhosts as t2, users as t3, accounts as t4, resellers as t5 where t2.domain=t1.id and t1.owner=t3.id and t3.account=t4.id and t3.reseller=t5.id and t5.suspended='0' and t2.http != '0' order by t1.name, (t1.catchall = t2.id), t2.name' at /opt/pdadmin/bin/httpd_vhosts.pl line 717.


    Edit: hier die MySQL ErrorLog Auszüge:


    2.: alle Domains, inkl. der Administratorseite von PD-Admin haben ein "Access Denied".
    REchte habe ich abgeglichen - aber hat jemand einen Tipp, an was das liegen könnte?


    Kann mir dabei jemand helfen?


    Danke, Patrick


    PS: habe alles was ich im Forum dazu gefunden habe natürlich versucht.

    - Welche Version von pd-admin wird eingesetzt? v4.25
    - Welche Version der Serverumgebung wird eingesetzt? 3-0.260


    Hallo,
    eine Frage: Nachdem ich mir bei einem Dist-Upgrade das Perl etwas zerschossen habe und einige weitere Probleme mit apt dadurch auch noch aufgetreten sind strebe ich einen Serverumzug an. (momentan laufen alle PD Admin Dienste stabil - es ist aber nicht das Gelbe vom Ei...!)


    Wie ihr oben lesen könnt, die Versionen sind nicht die neueste. Außerdem würde ich bei einem neuen Server gleich auf Reihe 4 gehen...


    ist es nun überhaupt unter diesen Umständen möglich, einen Serverumzug der Daten durchzuführen? Oder werde ich da definitv Probleme haben?


    Danke im Voraus für ein paar helfende Worte!
    Patrick

    Ich hab da einen Nachtrag:


    bei einem "alten" Server stand heute morgen auch eine Kundenseite. Die PHP Version war auf "5.6.13" eingestellt.


    Serverversion ist: 3-0.260 und pd-Admin Version ist 4.25


    Eine Änderung weg von PHP 5.6 war erfolgreich und die Seite ist wieder offline.


    Selber Fehler wie im Initial-Eintrag von Eisenherz.

    Hallo,


    gibt es dazu schon ein Update? Macht das rausnehmen von --preserver-order Probleme?




    interessanter weise ist seit (ich weiß nicht genau wann, aber laut Backupstand ca 1 Woche) das Backup bei mir fehlerhaft - bisher hat es brav getan - aber vermutlich durch ein Update der SE ist wieder das --preserver-order reingekommen.