Kopie von Kivitendo 3.5.5 auf neuen Debian Server nicht moeglich

Question

Hallo,
wir haben einen neuen Debian Server eingerichtet und wollen Kivitendo komplett uebertragebm bevor wir die Version aktualisieren.

alter Server:
Debian 9 mit PostgreSQL 9.6 und Apache 2.4.X

neuer Server:
Debian 11 mit PostgreSQL 13 und Apache 2.4.Y

/var/www/kivitendo per "rsync -a ..." kopiert, Apache Dateien kopiert und/oder angepasst, DB mit "pg_dumpall --clean ..." und dann "pgsql -f ..." uebertragen.
Ich kann per phppgadmin und dem kivitendo user die DBs kivitendo und kivitendo_auth abfragen, aber der login als admin oder normaler user gehen nicht. Die Zugriffsrechte in der DB und im Dateisystem passen!

Haben wir etwas vergessen? Muss noch ein Script von Kivitendo gestartet werden? -- update_db hatte ich schon probiert.

Wenn ich auf dem neuen Server auf Kivitendo 3.7 update, laufen die Update-Scripte vom Admin und dem ersten User. Der Login geht dann wieder, aber man kann keine neuen Datensaetze erzeugen?! (Kunden, Angebote. Lieferscheine, usw.)

Hier ist ein aelterer LOG vom neuen Server mit Kivitendo 3.5.5 Apache error.log:
[Sat Dec 17 17:48:04.359118 2022] [core:notice] [pid 10742] AH00094: Command line: '/usr/sbin/apache2'

  SELECT a.attname, format_type(a.atttypid, a.atttypmod) AS format_type, d.adsrc, a.attnotnull
  FROM pg_attribute a
  LEFT JOIN pg_attrdef d ON (a.attrelid = d.adrelid) AND (a.attnum = d.adnum)
  WHERE (a.attrelid = 'auth.session'::regclass)
    AND (a.attnum > 0)
    AND NOT a.attisdropped
  ORDER BY a.attnum

: FEHLER: Spalte d.adsrc existiert nicht
LINE 1: ...mat_type(a.atttypid, a.atttypmod) AS format_type, d.adsrc, a...

                                                         ^      SELECT a.attname, format_type(a.atttypid, a.atttypmod) AS format_type, d.adsrc, a.attnotnull
  FROM pg_attribute a
  LEFT JOIN pg_attrdef d ON (a.attrelid = d.adrelid) AND (a.attnum = d.adnum)
  WHERE (a.attrelid = 'auth.session'::regclass)
    AND (a.attnum > 0)
    AND NOT a.attisdropped
  ORDER BY a.attnum

: FEHLER: Spalte d.adsrc existiert nicht
LINE 1: ...mat_type(a.atttypid, a.atttypmod) AS format_type, d.adsrc, a...

                                                         ^[Sat Dec 17 17:48:21.836554 2022] [fcgid:warn] [pid 10746] (104)Connection reset by peer: [client 192.168.178.54:59336] mod_fcgid: error reading data from FastCGI server, referer: http://192.168.178.12/kivitendo-erp/controller.pl?action=LoginScreen/user_login

[Sat Dec 17 17:48:21.836598 2022] [core:error] [pid 10746] [client 192.168.178.54:59336] End of script output before headers: dispatcher.fpl, referer: http://192.168.178.12/kivitendo-erp/controller.pl?action=LoginScreen/user_login

Ich komme da nicht weiter!!! Vor ein paar Jahren ist der Debain 9 Server HW maessig abgeraucht und wir konnten den neuen Debian 9 Server, wie oben beschrieben aus den Backups wieder herstellen,

Answer 1

Hallo Dirk,

Du hast wahrscheinlich alle Datenbanken übernommen, auch die PostgresSystemDBs.

Ich würde Postgres nochmal mit deinstallieren mit dem Schalter purge und dan nochmal neuinstallieren

Dann entweder über kivitendo eine neue kivitendo_auth anlegen oder nur die kivitendo_auth und die Mandanten DBs wieder zurücksichern.

Beste Grüße
Werner kivitendodienstleister

Comments

Hi,

das Problem ist eher, das kivi 3.5.5 nicht mit Postgres-Version >= 12 zurecht kommt:

"FEHLER: Spalte d.adsrc existiert nicht".

Siehe auch

commit dd3f1958ace6996b4db38f1de88aacdb2c660632
Date:   Thu Feb 20 12:55:06 2020 +0100

Unterstützung für PostgreSQL 12

Das Format von `pg_attrdef` wurde in PostgreSQL 12 deutlich geändert;
die Spalte `adsrc` gibt es nicht mehr. Für den Auth-Code ist
allerdings nur interessant, ob es Spalte X in Tabelle Y bereits
gibt. Also auch nur genau diese Informationen auslesen.

Evtl. kannst Du diesen commit cherry-picken, aber es gibt auch noch weitere commtis, die Probleme mit OIDs ab Version 12 angehen.
Besser wäre evtl., auch eine ältere Postgres-Version zu installieren, damit das alte System läuft, bis das neue fertig ist.

Grüße
Bernd

---

Hallo Bernd,

vielend Dank fuer die Tips! Ich werde erst nach Weihnachten weiter machen!

Mein Plan:
- Debian 9 in VM (oder Debian 10)
- nur kivitendo und kivitendo_auth mit Version 3.5.5 vom alten Server kopieren
- wenn das laeuft, die VM Installation auf Version 3.7 updaten
- PG auf echtem Debian 11 Server mit purge platt machen und neu inst
- Kivitendo 3.7 und nur die Kivi-DBs rueber ziehen

Dann an alle: Schoene Weihnachtszeit und einen guten Start ins neue Jahr!!!

lg,

Dirk

---

Hallo Werner und Bernd,

Zu erst: Fohes neues Jahr!!!

Ich hatte Debian 10 auf einer VM installiert und konnte Kivitendo 3.5.5 problemlos vom alten Server auf die VM kopieren! Neue Kunden anlegen, neue Angebote, usw.

Jetzt hatte ich in der VM mit Debian 10 auf Kivitendo 3.7.0 geupdated, die DBs mit sudo -u www-data ./dbupgrade2_tool.pl, dem Admin login und danach dem User-Login geupdatet -- ohne Fehler.
Ich kann alte Berichte von Stammdaten und Verkauf aufrufen, aber keine neuen Eintraege generieren.

Ich bekomme die Fehlermeldung: Fehler: Das Formular ist nicht mehr gültig.

Mir ist beim Anlegen neuer Kunden aufgefallen, das das Dropdown-Menue fuer Anreden nur noch die Nummern "1" und "2" anstatt "Herr" und "Frau" dargestellt wird?! Die Fehlermeldung beim Speichern ist ungefaehr die selsbe wie unten!

Wenn ich ueber den Workaround mit dem Workflow versuche, bekomme ich diese Fehlermelduingen:

Can't locate object method "created_for_user" via package "SL::DB::FollowUp" at /usr/share/perl5/Rose/DB/Object.pm line 1657.
Rose::DB::Object::AUTOLOAD(SL::DB::FollowUp=HASH(0x55d5d83e9c80), 10704) called at /var/www/html/kivitendo-erp_3.7.0/SL/DB/Object.pm line 95
SL::DB::Object::_assign_attributes(SL::DB::FollowUp=HASH(0x55d5d83e9c80), "follow_up_date", "", "created_for_user", 10704) called at /var/www/html/kivitendo-erp_3.7.0/SL/DB/Object.pm line 71
SL::DB::Object::assign_attributes(SL::DB::FollowUp=HASH(0x55d5d83e9c80), "created_for_user", 10704, "follow_up_date", "") called at /var/www/html/kivitendo-erp_3.7.0/SL/Controller/CustomerVendor.pm line 955
SL::Controller::CustomerVendor::_instantiate_args(SL::Controller::CustomerVendor=HASH(0x55d5d91db358), "save_and_quotation") called at /var/www/html/kivitendo-erp_3.7.0/SL/Controller/Base.pm line 240
SL::Controller::Base::_run_hooks(SL::Controller::CustomerVendor=HASH(0x55d5d91db358), "before", "save_and_quotation") called at /var/www/html/kivitendo-erp_3.7.0/SL/Controller/Base.pm line 276
SL::Controller::Base::_run_action(SL::Controller::CustomerVendor=HASH(0x55d5d91db358), "save_and_quotation") called at /var/www/html/kivitendo-erp_3.7.0/SL/Dispatcher.pm line 222
SL::Dispatcher::_run_controller("CustomerVendor", "save_and_quotation") called at /var/www/html/kivitendo-erp_3.7.0/SL/Dispatcher.pm line 315
eval {...} called at /var/www/html/kivitendo-erp_3.7.0/SL/Dispatcher.pm line 322
SL::Dispatcher::handle_request(SL::Dispatcher=HASH(0x55d5ce185278), FCGI=SCALAR(0x55d5d6bda718)) called at /var/www/html/kivitendo-erp_3.7.0/SL/Dispatcher.pm line 230
SL::Dispatcher::handle_all_requests(SL::Dispatcher=HASH(0x55d5ce185278)) called at /var/www/html/kivitendo-erp/dispatcher.fpl line 21

Hat einer von Euch eine Idee?

---

Hallo,
so direkt habe ich jetzt keine Idee. Es sieht so aus als ob nicht alle updatescripts durchgelaufen sind.
Hast du mal den Browsercache gelöscht?
Apache ist neu gestartet?
Beste Grüße
Werner kivitendodienstleister

---

Hallo Wernder,

hatte keine Zeit, aber jetzt das hier probiert:

• VM mit Debian 10
• nur die kivitendo und kivitendo_auth importiert
• kivitendo-erp_3.5.5 vom alten Debian 9 Server kopiert

laeuft!!!

• dann kivitend 3.6.1 drauf gezogen
• dbupgrade2 script ausgefuehrt
• als kivi-admin eingeloggt - updates vom web-ui OK
• als user eingeloggt - updates vom web-ui OK

laeuft!!!

• dann kivitendo 3.7.0 gezogen
• wie oben -- alles OK

auf Debian 10 mit PostgreSQL 11 und Apache2 laeuft alles SUPER!!!

Bei Debian 11 mit PorstgreSQL 13 muss ich ein paar Sachen ausprobieren, aber Danke fuer Eure Hilfe!