Edomi in Proxmox LXC container.

[saegefisch]

Ach, ist es nicht schön, wenn die Dinge sich nachvollziehbar auflösen...danke für die Erklärung. Habe mir nach Deinem Hinweis offenbar erstmals mal das Script mit Sinn und Verstand angeschaut - das meiste der von mir erwähnten Pakete wird dort ohnehin von sich aus schon installiert...

Mit Deiner Interpretation war das viel Rauch um wenig, es würde reichen wenn Christian "file" im Script aufnimmt (und vielleicht die 3 localectl-Umstellungen?) und das Umlaute-Thema wäre allumfänglich gelöst... gaert ... was denkst Du, wäre das was für edomi 2.01?

Bei Verwendung mit LXC/Proxmox bliebe für den Einzelnen nur die erforderliche Anpassung (SELINUX + grub auskommentieren, edomi-service um 2 Zeilen ergänzen) - das wäre dann ja schön einfach und sehr elegant

[Lonie]

Ich würde jetzt einmal ins blaue raten:

• Ohne file kann schlecht rausgefunden werden in welchem Zeichensatz eine Datei vorliegt
• Die initiale Datenbankbefüllung, wenn die Schemas noch nicht vorhanden sind, erfolgt durch /usr/local/edomi/www/shared/php/incl_dbinit.php
• Diese Datei ist UTF-8 codiert
• ist file nicht vorhanden wird es als latin1 geschrieben was dazu führt dass 2Byte Zeichen falsch in der Datenbank landen
• Stellt man ein funktionierendes Backup her werden die Tabellen aus diesem hergenommen und nicht aus dem lokalen Filesystem => keine Zeichensatzfehler

Ich habe jetzt CentOS7 mit dem originalen Edomi 2 Installationsscript eingerichtet und konnte ein Projekt ohne Umlautprobleme erstellen. Es genügt also im Installationsscript in der Funktion install_onCentos7() file ebenfalls als Abhängigkeit mit anzugeben.

[vento66]

So wenn man "file" vor EDOMI installiert, läuft es jetzt auf einem Raspi4 nativ und so ganz ohne Fehlern bei den Umlauten. Jetzt geht es ans testen, und dann mithilfe eines REG Gehäuses in den Verteiler....

[saegefisch]

Lonie : Naja, kausal scheint es mir schon, dass "irgendwas" vom Host durchschlägt oder fehlt oder nicht vorbelegt ist und damit für edomi "irgendwie" unerwartet ist - was ja auch Deine Schlussfolgerung ist mit einem Defaultwert.

Aber was es ist? Keine Ahnung. Die Spracheinstellungen waren es offensichtlich nicht alleine. Aber in Kombination der Spracheinstellungen mit PHP 7 und beheben des "file"-Fehlers beim Aktivieren und vielleicht eines anderen Pakets, dass ich nun mehr vorinstalliere scheint es jetzt behoben.

Lieben Dank für Deine kontinuierliche und fachlich (für mich unfassbar) tiefe/fundierte Unterstützung zum Thema! Es war ganz sicher Teil der Lösung - nun hoffe ich, dass auch andere auf diesem Weg erfolgreich sind und das Vorgehen tatsächlich tragfähig ist. Dann können wir uns endlich wieder mit edomi-Inhalten beschäftigen und nicht mit Admin-Krams...

[saegefisch]

Langfassung bebildert:

• Container erstellen

proxmox01.PNGproxmox02.PNGproxmox03.PNG

• Projekt erstellen -> LBS mit Umlauten

proxmox04.PNGproxmox05.PNG

• Projekt aktivieren und aktivieren und aktivieren... -> kein file-Fehler mehr und VSE mit Umlauten

proxmox06.PNGproxmox07.PNG

[saegefisch]

Yippie! Keine Umlaut-Fehler mehr mit Proxmox/LXC!

In der Kombination der Spracheinstellungen mit Paket "file" und PHP 7.2 (und mit der guten Magie von Marcel, BEN, Micha, Yves und André: Danke!) haben wir eine Lösung für edomi 2.00 auf CentOS 7.x in LXC/Proxmox:

Vorgehen:

• Proxmox "Erstelle CT": unpriviligiert, ohne Firewall, gerne mit DHCP und fester MAC-Adresse - und geht auch mit VLAN (wenn man vorher entsprechende "eno1.xx" (Linux VLAN) und Bridges vmbrxx erstellt hat)
• In Konsole folgende Pakete installieren inkl. PHP 7.2
  • yum install -y nano ntp openssh-server tar unzip vsftpd wget yum-utils net-tools
  • yum install -y ca-certificates epel-release file git httpd mariadb-server mod_ssl
  • yum install -y http://rpms.remirepo.net/enterprise/remi-release-7.rpm
  • yum-config-manager --enable remi-php72
  • yum install -y php php-gd php-mbstring php-mysql php-process php-soap php-xml
  • yum -y update
• Nicht nötig, aber sinnvoll:
  • systemctl start sshd
  • systemctl enable sshd
• In Konsole Spracheinstellungen anpassen ( Lonie : Hier steht vorher "POSIX", beim Host "en_US.UTF8")
  • localectl set-locale LANG=de_DE.utf8
  • localectl set-x11-keymap de
  • localectl set-keymap de-nodeadkeys
  • timedatectl set-timezone Europe/Berlin
• Reboot
• Proxmox Container-Optionen anpassen: Beim Booten starten: JA | Konsolenmodus: console
• In Konsole edomi-install.sh-Script anpassen
  • cd /tmp
  • wget edomi.de/download/install/EDOMI_200.tar
  • tar -xf EDOMI_200.tar
  • cp install.sh install.sh.backup
  • nano install.sh (3x Änderung: 2x auskommentieren, 1x 2 Zeilen einfügen -> siehe oben für Details bzw. das fertige Script von BEN)
  • cp install.sh install.sh.proxmox
• Reboot

Danach: Kein Umlaut-Thema mehr bei Erstellung Projekt (LBS) oder auch nach Aktivierung (Visuelemente). Ebenso kein file-Fehler mehr bei Aktivierung. Auf diese Weise soeben 3x erfolgreich getestet mit frischem Container, sollte also verlässlich funktionieren.

Jetzt kann ich selber endlich mal mit edomi 2 herum spielen und meine LBS auf PHP7 heben...

Viel Spaß damit!


UPDATE:
Der ganze PHP-Krams ist gar nicht nötig, weil edomi den ja im install.sh mitbringt. Ebenso viele der Pakete. Nach dem wir nun wissen, dass es wohl am Paket "file" lag, geht es schlanker mit der VM in Proxmox; vermutlich kann man den ganzen localectl-Teil auch weglassen - aber es stört ja auch nicht und eine VM ist in 5min fertig: "CT erstellen", dann in der Konsole...

yum install -y nano openssh-server tar unzip wget file ca-certificates mod_ssl
yum -y update
systemctl start sshd
systemctl enable sshd
localectl set-locale LANG=de_DE.utf8
localectl set-x11-keymap de
localectl set-keymap de-nodeadkeys
localectl status
timedatectl set-timezone Europe/Berlin
cd /tmp
wget edomi.de/download/install/EDOMI_200.tar
tar -xf EDOMI_200.tar
cp install.sh install.sh.backup
nano install.sh    (3x Änderung)
...
        # --- auskommentieren
        ###echo -e "\033[32m>>> SELinux deaktivieren\033[39m"
        ###sed -i -e '/SELINUX=/ s/=.*/=disabled/' /etc/selinux/config
        # ---
...
        # --- auskommentieren
        ###echo -e "\033[32m>>> Bootvorgang konfigurieren\033[39m"
        ###sed -i -e '/GRUB_TIMEOUT=/ s/=.*/=1/' /etc/default/grub
        ###sed -i -e 's/quiet//g' /etc/default/grub
        ###sed -i -e 's/rhgb//g' /etc/default/grub
        ###grub2-mkconfig -o /boot/grub2/grub.cfg
...
        # +++ einfügen (VOR: 'echo "[Install]"  >> /etc/systemd/system/edomi.service')
    echo "Restart=on-success"         >> /etc/systemd/system/edomi.service
    echo "SuccessExitStatus=SIGHUP"        >> /etc/systemd/system/edomi.service
        # +++
 
cp install.sh install.sh.proxmox
reboot

dann Container-Optionen auf "Beim Booten starten: JA | Konsolenmodus: console" und

locale    (hier sollte de_DE.UTF8 stehen)
cd /tmp
sh install.sh     (-> Option "7")
reboot

Fertig! Edomi läuft in der VM - zumindest bei mir bislang stabil und fehlerfrei - gerade hinsichtlich des Umlaute-Themas. Zugriff per SSH und Filezilla und eclipse funktionieren für erforderliche LBS-(Vor)arbeiten.

Jetzt könnte man nur noch über ein unattended-upgrade nachdenken, um CentOS7 immer aktuell zu halten. Ja, es ist nicht Christians Ansatz, aber zumindest meines Erachtens gehört es zum guten Ton eines Servers, stets aktuell zu sein in seiner Release-Schiene. In Bezug auf ein Haus-System gibt es allerdings auch sehr gute Gründe, dies nicht (automatisch) zu tun, um die Stabilität nicht ohne Regressionstests zu gefährden. Genau dafür ist eine VM (eines Prod-Backup) wunderbar geeignet - aber vermutlich eher nicht automatisch.

[Lonie]

Ich denke nicht dass das Problem vom Host her kommt. Ich habe mir mal den Spass gemacht und die MySQL Variablen unter CentOS6 und CentOS7 einer frischen Edomi Installation anzusehen.

CentOS 6:

mysql> SHOW VARIABLES LIKE  'char%';
+--------------------------+----------------------------+
| Variable_name            | Value                      |
+--------------------------+----------------------------+
| character_set_client     | latin1                     |
| character_set_connection | latin1                     |
| character_set_database   | latin1                     |
| character_set_filesystem | binary                     |
| character_set_results    | latin1                     |
| character_set_server     | latin1                     |
| character_set_system     | utf8                       |
| character_sets_dir       | /usr/share/mysql/charsets/ |
+--------------------------+----------------------------+

CentOS 7:

MariaDB [edomiAdmin]> SHOW VARIABLES LIKE  'char%';
+--------------------------+----------------------------+
| Variable_name            | Value                      |
+--------------------------+----------------------------+
| character_set_client     | utf8                       |
| character_set_connection | utf8                       |
| character_set_database   | latin1                     |
| character_set_filesystem | binary                     |
| character_set_results    | utf8                       |
| character_set_server     | latin1                     |
| character_set_system     | utf8                       |
| character_sets_dir       | /usr/share/mysql/charsets/ |
+--------------------------+----------------------------+
8 rows in set (0.00 sec)

Nach einem Import übernimmt er die Tabellen natürlich mit dem richtigen Charset weswegen die Zeichensätze danach auch passen. Erstellt man allerdings ein jungfräuliches Projekt so wird dabei vermutlich das Charset nicht explizit angegeben und er nimmt die Defaultwerte.

gaert könnte das das Problem sein? Ich mag ungern den Code durchsuchen nach den Create Table Statements

[saegefisch]

okay, danke, gut zu wissen. Wegen der LBS ist klar, aber bei edomi war ich mir nicht sicher. Will ja selber alle meine LBS auf PHP 7.x heben. Werde die Installation unter LXC dann mal mit 7.2 testen... und das Paket "file" installieren. Damit sollte der Fehler bei der Aktivierung weg zu bekommen sein.

Aber die Sache mit den Umlauten, die offenbar vom Host bei LXC "durchschlagen" bleiben mir ein Rätsel und übersteigen leider meine Linux-Kenntnisse... dabei wäre LXC/LXD eine wirklich elegante Lösung...

[jonofe]

Ich kann nur für meine LBS sprechen, die sollten grundsätzlich mit PHP 7.x laufen (wenn nicht explizit anderweitig angegeben). Edomi selbst sollte auch mit PHP 7.x klarkommen, zumindest habe ich bislang noch nicht festgestellt, dass die PHP Minor Version relevant ist.

[starwarsfan]

Ich meine, Edomi stellt keine besonderen Anforderungen an die PHP Version. Soviel ich weiss aber diverse LBS. jonofe ?

[saegefisch]

Danke Micha, danke Yves, für Eure Antworten. Werd' mal einen neuen Anlauf damit machen...
Das "file" ein Paket sein kann, kam mir irgendwie nicht in den Sinn...

Aber anderes gefragt: Kann es dann überhaupt an der PHP-Version liegen? Welche PHP erwartet edomi eigentlich. Habe dazu in der Doku nicht direkt was gefunden - oder falsch geschaut...

[starwarsfan]

Hi

bei jedem Aktivieren gibt es einen ganzen Sack (~25) sh file not found bzw. sh: file: Kommando nicht gefunden

Siehe mein Codeschnipsel oben drüber, Du musst eben auch noch "file" installieren.

[starwarsfan]

Hallo miteinander,

hinsichtlich php 7.x wird eigentlich immer auf das sog. "Remi-Repo" verwiesen. Daher setze ich das i.d.R. wie folgt auf und habe damit auch php7.2 unter CentOS 7:

yum install -y \
    ca-certificates \
    epel-release \
    file \
    git \
    httpd \
    mariadb-server \
    mod_ssl \
    nano \
    ntp \
    openssh-server \
    tar \
    unzip \
    vsftpd \
    wget \
    yum-utils \
yum install -y \
    http://rpms.remirepo.net/enterprise/remi-release-7.rpm \
yum-config-manager \
    --enable remi-php72 \
yum install -y \
    php \
    php-gd \
    php-mbstring \
    php-mysql \
    php-process \
    php-soap \
    php-xml \
yum clean all

[vento66]

Wie hast Du damals bei Deinem Bastelprojekt die Fehler weg bekommen? War es das PHP-Update?

Noch gar nicht, da es für diese Plattform noch kein php7 gibt. Daher steht das im Moment erst mal hinten an.

[saegefisch]

vento66 : Zu Deinem Hinweis zum Thema in dem anderen Threat...

• Das CentOS7-template von Proxmox kommt mit PHP 5.x
• Ja, bei jedem Aktivieren gibt es einen ganzen Sack (~25) sh file not found bzw. sh: file: Kommando nicht gefunden

...
03.01.2020 01:53:44 Datenbank: edomiLive erstellen
03.01.2020 01:53:44 Projektaktivierung...
sh: file: Kommando nicht gefunden.
sh: file: Kommando nicht gefunden.
sh: file: Kommando nicht gefunden.
sh: file: Kommando nicht gefunden.
sh: file: Kommando nicht gefunden.
sh: file: Kommando nicht gefunden.
sh: file: Kommando nicht gefunden.
sh: file: Kommando nicht gefunden.
sh: file: Kommando nicht gefunden.
sh: file: Kommando nicht gefunden.
sh: file: Kommando nicht gefunden.
sh: file: Kommando nicht gefunden.
sh: file: Kommando nicht gefunden.
sh: file: Kommando nicht gefunden.
sh: file: Kommando nicht gefunden.
sh: file: Kommando nicht gefunden.
sh: file: Kommando nicht gefunden.
sh: file: Kommando nicht gefunden.
sh: file: Kommando nicht gefunden.
sh: file: Kommando nicht gefunden.
sh: file: Kommando nicht gefunden.
sh: file: Kommando nicht gefunden.
sh: file: Kommando nicht gefunden.
sh: file: Kommando nicht gefunden.
sh: file: Kommando nicht gefunden.
sh: file: Kommando nicht gefunden.
sh: file: Kommando nicht gefunden.

03.01.2020 01:53:44 Projektaktivierung: Arbeitsprojekt (1) aktiviert
03.01.2020 01:53:44 Datenbank: edomiLive.RAMcmdQueue löschen
...

• Was macht die Aktivierung zwischen "Aktivierung..." und "aktiviert"?
• Update auf 7.2 oder auch 7.3 half leider nicht, die Fehler kommen weiterhin beim Aktivieren

ABER: Vielleicht liegt die Ursache des Umlaut-Themas aber dennoch in diesen Fehlern. Wie hast Du damals bei Deinem Bastelprojekt die Fehler weg bekommen? War es das PHP-Update?Falls ja: Mit welchem Vorgehen - ich habe dafür diverse unterschiedliche gefunden, um CentOS 7 auf PHP 7.x zu heben... keine Ahnung, ob das Vorgehen entscheidend ist.

Nachtrag:

• Da das Thema offenbar ausschließlich mit LXC/Proxmox auftritt und eben nicht bei Voll-virtualisierung oder direkt auf der HW (unabhängig von der CentOs-Version), kann es eigentlich nur etwas sein, was vom Host auf den Container "durchschlägt", richtig?
• Die Analysen im anderen Threat haben gezeigt, dass ein Backup selbst ein "sauberes" edomi auf echter HW "infizieren kann, nicht aber ein Projekt-export.
  --> Es muss also etwas sein, dass vom Host durchschlägt, Teil des Backups ist, nicht aber des Exports.
• Zumindest bei Proxmox 6.1-3 lieferte "locale" auf dem Host "en_US.UTF8".
• Michael wintermute , Du hattest mal die Vermutung, dass es der Zeichnsatz am WebServer sein könnte. Hast Du eine Idee, wie man das verifizieren kann?

Sorry, dass ich das Thema so vehement verfolge, aber in meinen Augen ist es der schönste/eleganteste Weg, um sich Entwicklungs- und Testumgebungen und ggf. Prod-Backup bereit zu stellen. Für mein echtes Produktivsystem geht bei mir nichts an echter HW vorbei. Doch für diese Nebenzwecke erscheint mir Docker (wegen des BS-nahen Designs von edomi) nicht die richtige Wahl und "echte" VM unnötig dick.Daher wäre eine Lösung wirklich hilfreich - sicher nicht nur für eine handvoll Leser hier.