Edomi in Proxmox LXC container.

[starwarsfan]

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

[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.

[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...

[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]

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.

[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]

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...

[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....

[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.

[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]

Wenn du einen priveligierten Container erstellst reicht es sogar vollkommen aus file aufzunehmen. Bei unpriveligierten habe ich aktuell das Problem dass sie sich nicht über systemd starten lassen. Fehlermeldung "Failed at step STDIN spawning /bin/sh: Operation not permitted". Jetzt werd ich aber erstmal ins Wochenende gehen. Prinzipiell ist der Grund ja gefunden und die meisten sind happy

[saegefisch]

Wie in meinem 1. Screenshot zu sehen, habe ich die CT unpriviligiert erstellt. Die starten mit/von Proxmox wunderbar mit, wenn Proxmox aus war. Oder bist Du "pur" unterwegs mit LXC/LXD? Ist ja eigentlich auch mein Ziel gewesen. Ich bin offen gesagt überrascht, wie gut mir Proxmox gefällt - das wollte ich doch nie...

Werde am WE noch mal den puren Weg versuchen auf Ubuntu-Host und LXD für edomi-VM. Wenn ich ankomme, ist mir das lieber, wenn nicht, dann scheint Proxmox eine ordentliche Lösung zu sein. Bei solchen Tools ist für mich immer die Frage nach der langfristigen Verfügbarkeit und halte mich bei Servern gerne fern von derlei.

[Lonie]

Ich habe Proxmox im Einsatz, hab aber auch gerade keine Lust zu schauen warum das Probleme macht. Um Verfügbarkeiten brauchst du dir da wahrscheinlich keine Gedanken zu machen da es DIE Open Source Alternative zu ESXi ist. Es existiert seit 2008 und wird stetig weiter entwickelt. Ich würde nicht versuchen LXC Container nativ zu nutzen. Zu viel Wissen das man sich aneignen muss, diverse Möglichkeiten muss man selbst nachbilden und vermutlich fehlt dann auch die Übersichtlichkeit (ich habe 8 LXC Container im Betrieb und die sollen einfach laufen)

[starwarsfan]

Hi

Das "file" ein Paket sein kann, kam mir irgendwie nicht in den Sinn...

Wenn irgendwo ein Fehler der Art Command not found auftaucht, ist der erste Test immer, ob der entsprechende Befehl bzw. das Paket, welches diesen Befehl enthält, installiert ist. Der erste Check wäre dann bspw. via whereis:

# whereis file
file: /usr/bin/file /usr/share/file /usr/share/man/man1/file.1.gz

Wenn es hier keinen Output gibt, fehlt die Datei resp. das Paket, welches die Datei enthält. Das entsprechende Paket bekommst Du so raus:

# [B]yum whatprovides file[/B]
Loaded plugins: fastestmirror, ovl
Determining fastest mirrors
 * base: mirror.23media.com
 * extras: linuxsoft.cern.ch
 * updates: mirror.netcologne.de
base                                                                | 3.6 kB  00:00:00
extras                                                              | 2.9 kB  00:00:00
updates                                                             | 2.9 kB  00:00:00
(1/4): base/7/x86_64/group_gz                                       | 165 kB  00:00:00
(2/4): extras/7/x86_64/primary_db                                   | 153 kB  00:00:00
(3/4): updates/7/x86_64/primary_db                                  | 5.9 MB  00:00:00
(4/4): base/7/x86_64/primary_db                                     | 6.0 MB  00:00:00
[COLOR=#FF0000]file-5.11-35.el7.x86_64 : A utility for determining file types[/COLOR]
Repo        : base

Für die Paketinstallation ist dann der Teil bis zum ersten Bindestrich relevant, in dem Fall also ganz einfach

# yum install file

Happy Linux'ing

[saegefisch]

Danke, das kannte ich noch nicht, Yves! Und lässt mich Linux einfach immer cooler finden...ich bleibe weiter "stets bemüht"...

Und danke für Deine Einschätzung, Marcel. Das hat natürlich Gewicht, wenn jemand mit Deinem IT-Fundament so entschieden hat. Da ich bisher meine ganzen Server/Docker per Wiki dokumentiert habe und ohne GUI das auch schön einfach war/ist. Damit konnte ich wunderbar alles erforderliche 1:1 oder mit neuen Erfahrungen ergänzt rasch neu aufbauen.

Gibt es irgendwo zentrale conf/yml/?-Dateien, die Proxmox mit wenigen Handgriffen wieder reproduzieren lassen (z.B. wenn HW abgeraucht ist). Oder ist Proxmox nur ein Wrapper, der überall die verteilten Dateien anfasst, aber nichts zentral hinterlegt? Anders: Wie sichert man den Stand des Proxmox-Servers am besten (ohne ein Image der Platte zu ziehen)?