upgrade nicht moeglich

[martin@…]

Beim Versuch des DB updates wird dieses mit folgnder Meldung abgebrochen...

• Führe emmvee_background_jobs_2.pl aus: Hintergrundjobs einrichten

Die Datenbankaktualisierung/erstellung schlug fehl. Die Datei sql/Pg-upgrade2/emmvee_background_jobs_2.pl enthielt den folgenden Fehler:
DBI connect('host=localhost;port=5432',,...) failed: FATAL: role "apache" does not exist at SL/DB.pm line 19
Alle Änderungen in dieser Datei wurden rückgängig gemacht.

warum hier der User/Role? apache verwendet werden soll ist mir unklar..

LG

Looks as #1588

Die unstable vereinheitleicht alle Konfigurationsdateien in config/ in einer neuen Datei config/lx_office.conf(.default). Bitte die .default nach .conf kopieren und die .conf entsprechend anpassen.

Die config/authentication.pl wird nicht mehr verwendet.

Existiert config/lx_office.conf nicht, so wird die config/lx_office.conf.default verwendet.

Bitte auch mal Folgendes machen:

grep -r apache config

Wenn das nichts zu Tage fördert, dann bitte in der auth.user_config-Tabelle in der Auth-Datenbank suchen:

SELECT * FROM auth.user_config WHERE cfg_value ILIKE '%apache%';

Looks as #1588

Nicht wirklich:

DBI connect('host=localhost;port=5432',,...)

Das Defaultwertproblem betraf nur den Hostnamen. Für den Benutzer gibt es keinen Defaultwert.

Bitte auch mal Folgendes machen:

grep -r apache config

diese lieft kurz nix:

mordor lx-office-erp # grep -r apache config
mordor lx-office-erp #

Wenn das nichts zu Tage fördert, dann bitte in der auth.user_config-Tabelle in
der Auth-Datenbank suchen:

SELECT * FROM auth.user_config WHERE cfg_value ILIKE '%apache%';

und dies liefert:

lxerp_auth=# SELECT * FROM auth.user_config WHERE cfg_value ILIKE '%apache%';

user_id | cfg_key | cfg_value

---

(0 rows)

die Dateien sind im chown -R apache:apache *, da dies der Webnutzer ist, benoetigen diese evt. einen besonderen Nutzer, so das sie ausfuehrbar sind, wenn ja welche rechte brauch der nutzer, oder sollte es nobody sein?

Nein, die Dateirechte sind bei apache schon gut aufgehoben.

Lies bitte erneut das, was ich über die Konfigurationsdatei geschrieben habe. Meine Vermutung ist Folgende:

Du hast keine config/lx_office.conf. Deshalb nimmt Lx-Office die config/lx_office.conf.default. Dort ist für die Authentifizierungs-DB kein Username eingetragen.

Alternativ: du hast eine config/lx_office.conf, aber in der steht trotzdem kein Username für die Datenbank.

Hat die Postgres-Client-Bibliothek keinen Usernamen vom Programm erhalten, so nutzt sie den Usernamen des aktuellen Prozesses, und der ist "apache".

(In reply to comment #4)

Nein, die Dateirechte sind bei apache schon gut aufgehoben.

Lies bitte erneut das, was ich über die Konfigurationsdatei geschrieben habe.
Meine Vermutung ist Folgende:

Du hast keine config/lx_office.conf. Deshalb nimmt Lx-Office die
config/lx_office.conf.default. Dort ist für die Authentifizierungs-DB kein
Username eingetragen.

doch selbige ist vorhanden:

mordor lx-office-erp # ls config
lx_office.conf

Alternativ: du hast eine config/lx_office.conf, aber in der steht trotzdem kein
Username für die Datenbank.

auch dieser ist unter allen punkten bezueglich Datenbank eingetragen...

Hat die Postgres-Client-Bibliothek keinen Usernamen vom Programm erhalten, so
nutzt sie den Usernamen des aktuellen Prozesses, und der ist "apache".

Und sowie ich die lx_office.conf.default entferne bekomme ich eine Fehlermeldung bezueglich das diese Datei nicht ausgelesen werden kann...

Trage ich alle Zugangsdaten jedoch in lx_office.conf.default ein so klappt der upgrade... Danke so weit fuer die hilfe...

Daraus resultierend ergibt sich folgendes fazit fuer mich:

es fehlt oder is fehlerhaft eine Abfrage ob lx_office.conf existiert und sofern dies TRUE ist soll diese lx_office.conf.default bevorzugt werden...

Danke aber fuer das super produkt

Hmm. Dieser Check existiert und funktioniert eigentlich auch. Zumindest habe ich es eben verifiziert -- wenn ich in config/lx_office.conf einen ungültigen Benutzer als DB-Benutzer eintrage, so wird die Auth-DB nicht gefunden.

Es ist in der Tat so, dass die lx_office.conf.default immer eingelesen wird. Die Einstellungen aus der lx_offie.conf überschreiben dann gleichnamige Einstellungen aus der .default. Hat den Grund, dass neu hinzugekommene Einstellungen aus der .default ohne Änderungen an der .conf übernommen werden können.

Es scheint mir ein userseitiges Problem zu sein; zumindest kann ich es hier auch nicht nachstellen. Deshalb schließe ich den Bug als INVALID.

Falls du noch weitere Erkenntnisse hast, immer her damit.