Guten Morgen,
hier ist meine Lösung: mrbs, so wie es Frank sich gedacht hat: Das neue Image ist hier, weil ich keinen Zugriff auf die Docker + githubs habe:
bin grad am Einrichten des lmn7 mrbs.
dehydrated hat der cert geholt: erstmal alles sahne.
Dann habich die mrbs.ini angepaßt und turnkey laufen lassen: auch alles
super.
Sag mal: der nimmt schon auch Port 636, oder?
Ich hab mal 636 in der opnsense frei geschaufelt.
Nach dem docker-compose up -d kommt aber beim Aufruf der Seite
502 Bad Gateway
In der /etc/nginx/sites-enabled und sites-availible finde ich auch nur
die default und keine für mrbs…
Sollte der turnkey die anlegen?
Kannst du mir die config für nginx mal posten?
…phew, ich war schon am suchen, denn : ich hab den nginx auf dem dockerhost immer noch nicht. Ich bin immernoch bei meinem nginx-IM-docker-container geblieben, weil es beim ersten VErsuch außerhalb eben nicht klappte.
D.h. ich hab das mrbs paket so weit angepasst und hab einfach gehofft, dass die reverse proxy geschichte sich halt noch nicht geändert hat
Super, freut mich, dass es klappt.
Tobias
p.s." Lass auch andere die Konversation mitgestalten
Dieses Thema ist dir eindeutig wichtig – du hast mehr als 25% aller Antworten verfasst.
Es könnte noch besser sein, wenn du anderen Leuten ebenfalls Raum lässt, ihre Sichtweisen darzulegen. Bitte lade sie dazu ein."
sach mal: hast du da auch einen lokalen Nutzer als Admin eingetragen?
Das sollte ja eigentlich mittels.
$auth[„user“][
„username1“] = „password1“;
und
$auth[„admin“] = „username1“;
in der raumbuchung.inc.php passieren.
Er scheint aber immer den LDAP ab zu fragen (was noch ciht geht, weil
ich gerade erst bemerkt habe, dass die externe IP des lmn7 noch nicht
den Port 636 frei hat: mail an BelWü ist raus).
p.s." Lass auch andere die Konversation mitgestalten
Dieses Thema ist dir eindeutig wichtig – du hast mehr als 25% aller
Antworten verfasst.
Es könnte noch besser sein, wenn du anderen Leuten ebenfalls Raum lässt,
ihre Sichtweisen darzulegen. Bitte lade sie dazu ein."
… wo hast du den die Aussage her?
Hat dir das discourse geschickt?
Ich hab da eigentlich nix verändert. In der auth_linuxmuster62.inc bzw. in der raumbuchung.inc.php stand bei mir vorher schon:
unset($auth["admin"]); // Include this when copying to config.inc.php
$auth["admin"][] = "global-admin";
#$auth["admin"][] = "andererbenutzer";
#$auth["admin"][] = "andererbenutzer";
#$auth["admin"][] = "andererbenutzer";
wo bei statt global-admin eben administrator stand.
DAs „unset“ macht ja alle lokal definierten Nutzer zunichte.
Die könnte man danach ja wieder einführen.
Aber da muss man die auth_linuxmsuter7.inc patchen.
Ich weiß gar nicht, warum das vorher scheinbar mit LDAP + lokalen Benutzern funktioniert haben soll/kann.
Hattest du vorher an LDAP der 62 das mrbs von frank angeschlossen, oder war das noch ein älteres?
VG, Tobias
Ich hab da eigentlich nix verändert. In der auth_linuxmuster62.inc bzw.
in der raumbuchung.inc.php stand bei mir vorher schon:
unset($auth[„admin“]); // Include this when copying to config.inc.php
$auth[„admin“] = „global-admin“; #$auth[„admin“] =
„andererbenutzer“; #$auth[„admin“] = „andererbenutzer“;
#$auth[„admin“] = „andererbenutzer“;|
wo bei statt global-admin eben administrator stand.
DAs „unset“ macht ja alle lokal definierten Nutzer zunichte.
Die könnte man danach ja wieder einführen.
Aber da muss man die auth_linuxmsuter7.inc patchen.
Ich weiß gar nicht, warum das vorher scheinbar mit LDAP + lokalen
Benutzern funktioniert haben soll/kann.
Hattest du vorher an LDAP der 62 das mrbs von frank angeschlossen, oder
war das noch ein älteres?
ich hatte das von Frank mit dem auth typ mlbw
Dazu hatte ich aber in der inc.php noch einen lokalen admin drin: das
hat funktioniert.
Hier funktioniert es wohl nicht: oder muss ich den Dock neustarten,
damit Änderungen übernommen werden?
Ist auch garnicht so wichtig…
Wenn morgen die ANmeldung geht, dann tut es ja auch der global admin …
Hi, ich hab mir nur den typ linuxmuster62 und linuxmuster7 angeschaut und die können das vermutlich nicht.
Die auth_mlbw auf meinem 62er Server ist von 2004 von G. Wilke geschrieben. Das macht gar nicht LDAP, sondern ein POP-Login. Haarsträubend aus heutiger Sicht…
In 15 Jahren werden sich entwickler denken: der code ist ja ohne KI-Hilfe geschrieben, Haarsträubend…
Hallo,
der Link zur Datenschutzerklärung steht. Und da ich mal davon ausgehe, dass das noch mehr Admins beschäftigen könnte, skizziere ich mal kurz, wie ich das gemacht habe. Da ich, was Docker angeht, ein absolutes Greenhorn bin wird meine Lösung nicht die eleganteste sein…
Die Datei /var/www/html/Themes/default/header.inc in unserem Docker-Container raumbuchung baut die Menüzeile des mrbs auf.
Diese Datei und die Datei site_dse.html, in der die Datenschutzerklärung steht, reiche ich aus dem Dockercontainer heraus:
Am Ende der Datei /srv/docker/linuxmuster-mrbs/docker-compose.yml muss folgendes eingefügt werden:
- ./Themes/default/header.inc:/var/www/html/Themes/default/header.inc
- ./Themes/default/site_dse.html:/var/www/html/Themes/default/site_dse.html
Dadurch werden die Dateien header.inc und site_dse.html in den Ordner /srv/docker/linuxmuster-mrbs/Themes/default/ gelegt.
Mit docker stop raumbuchung und docker stop mariadb werden die Container gestoppt.
Mit docker-compose up -d werden die Veränderungen übernommen und die Dockercontainer gestartet.
So jetzt muss nur noch die Datei /srv/docker/linuxmuster-mrbs/Themes/default/header.incauf dem Dockerhost und nicht im Dockercontainer raumbuchung, bearbeitet werden:
In Zeile 146 habe ich die Funktion print_dse eingefügt:
function print_dse($query_string)
{
echo „<a href=„Themes\default\site_dse.html?$query_string“>Datenschutzerklärung\n“;
}
Jetzt kann in Zeile 227 der Datenschutz-Menüeintrag eingefügt werden:
Wenn jetzt in site_dse.html die Datenschutzerklärung im HTML-Format steht, ist die Datenschutzerklärung auch im neuen mrbs.
Wenn man für einen mrbs-Server, der aus dem Internet aus erreichbar ist keine Datenschutzerklärung braucht, vergesst einfach diese kleine Anleitung und gebt mir kurz Bescheid.
ankündigung: Ich hab das docker image zu mrbs aktualisiert und somit ist meine v7 Anpassung jetzt im Repo, sowie im Docker-image bei docker hub.
D.h. für alle, die schon den linuxmuster/mrbs:latest verwenden, weil sie den docker-host von Frank installiert haben und so weiter:
Das aktuelle Docker-image enthält zwar weiterhin mrbs-1.7.3, weil es kein neueres gibt, aber ich habe ständig die php-versionen aktualisiert, bis hin zur aktuellen 7.4.0. @baumhof: Sicher mal deinen dockerhost mit
docker tag linuxmuster/mrbs:latest linuxmuster/mrbs:working-old
und aktualisiere mal mit
docker pull linuxmuster/mrbs:latest
dann den docker-container bzw. die Umgebung neu starten mit
docker-compose up -d
Wenn danach noch alles mit mrbs tut, wie es vorher war, dann ist alles gut und du hast ein aktuelles php mit weniger bekannten Sicherheitslücken im mrbs-image
Wenn mrbs nicht tut, dann passe in deiner docker-compose.yml die Zeile an, und verwende linuxmuster/mrbs:working-old statt :latest und restarte mit up -d.
Berichte mal, ob das bei dir klappt.
Wenn das klappt, solltest du auch mal die mariadb updaten mit docker pull mariadb:latest. Das ist allerdings ein Schritt, der nicht immer rückgängig zu machen ist, weil man den Datenbankunterbau ändert. Bisher gab es bei mir keine Probleme und habe regelmäßig mariadb upgedatet.
docker tag linuxmuster/mrbs:latest linuxmuster/mrbs:working-old |
Das tat so nicht, weil das wohl bei mir anders heißt.
Ich hab dieses gemacht:
docker tag hgkvplan/linuxmuster-mrbs:latest
hgkvplan/linuxmuster-mrbs:working-old
ich glaube, ich hätte den Container vorher stoppen sollen…
und aktualisiere mal mit
docker pull linuxmuster/mrbs:latest |
done
dann den docker-container bzw. die Umgebung neu starten mit
docker-compose up -d |
das wirft fehler, weil er sich weigert eine mariadb container zu
erschaffen, der schon existiert.
docker ps -a
zeigt, dass noch Überreste von mrbs und mariadb da sind.
Die habe ich mittels:
docker ps -qa | xargs docker rm
entfernt und dnan den container mittels
docker-compose up -d
gestartet.
Raumbuchung ist wieder da, Daten sind drin und ich konnte als Lehrer
einen Testeintrag machen.
ah, schau aber mal, ob du jetzt wirklich den „linuxmuster/mrbs:latest“ container verwendest oder noch meinen „hgkvplan/linuxmuster-mrbs“. Letztendlich ist es momentan egal, aber zukünftig werde ich ersteren aktuell halten.
ah, schau aber mal, ob du jetzt wirklich den „linuxmuster/mrbs:latest“
container verwendest oder noch meinen „hgkvplan/linuxmuster-mrbs“.
Letztendlich ist es momentan egal, aber zukünftig werde ich ersteren
aktuell halten.
CONTAINER ID IMAGE COMMAND
CREATED STATUS PORTS
NAMES
8dddd0427c5d hgkvplan/linuxmuster-mrbs:latest „/bin/sh -c
/usr/loc…“ 29 minutes ago Up 29 minutes
127.0.0.1:7777->80/tcp raumbuchung
15878ebb6796 mariadb:latest
„docker-entrypoint.s…“ 29 minutes ago Up 29 minutes
3306/tcp mariadb
ah ja.
ändere das mal in deiner docker-compose.yml auf „linuxmuster/mrbs:latest“.
und dann ein docker-compose pull
und dann ein docker images
Momentan sind hgkvplan/linuxmuster-mrbs:latest und linuxmuster/mrbs:latest identisch.
ändere das mal in deiner docker-compose.yml auf „linuxmuster/mrbs:latest“.
und dann ein |docker-compose pull|
und dann ein |docker images|
Momentan sind hgkvplan/linuxmuster-mrbs:latest und
linuxmuster/mrbs:latest identisch.
hab ich gemacht.
Jetzt bin ich auf linuxmuster/mrbs:latest
CONTAINER ID IMAGE COMMAND
CREATED STATUS PORTS NAMES
7c77098b17d9 linuxmuster/mrbs:latest „/bin/sh -c /usr/loc…“
About a minute ago Up About a minute 127.0.0.1:7777->80/tcp
raumbuchung
b40bb6c24393 mariadb:latest „docker-entrypoint.s…“
About a minute ago Up About a minute 3306/tcp mariadb