Docker Samba mit Loginmaske

[blurrrr]

Da beim "docker run" kein "-d" (--detach) angeführt ist, solltest Du doch eigentlich auch die Container-Logs live sehen können, wenn der Befehl ausgeführt wird? Wenn der Container "garnicht" startet, sollte doch auch eine entsprechende Fehlermeldung zu sehen sein bzw. in den Logs zu finden sein?

Dazu die Frage: Was macht die "samba.sh" da? Wenn ich nach dem Dateinamen suche, stolper ich ganz schnell über https://github.com/crops/samba/blob/master/samba.sh, was aber wohl anscheinend als entrypoint-Script gedacht ist?

Ich würde das erstmal so machen, wie es sein "sollte" (mit dem entrypoint-Script), einmal versuchen zu starten (was - wie Du ja sagtest - erstmal nicht funktionieren wird) und dann mal in die Logs schauen, was die dazu so sagen

 

[tester]

Wo genau in welchem Log steht etwas über das Startverhalten des Containers drin? Ich verwende immer docker logs <ID>

Was die samba.sh macht steht im Dockerfile. Sie legt einen Sambauser und eine Freigabe an und setzt die entsprechenden Berechtigungen. Das ist nicht das von die erwähnte Entrypoint Script sondern ein einfaches Shellscript.

 

[blurrrr]

An dieser Stelle möchte ich mal vorsichtig anmerken, dass ich den Link zur Log-Doku nicht umsetzt im letzten Post hatte Dort steht u.a. auch beschrieben, wo man z.B. unter Linux nachschauen kann:

1) journalctl -xu docker.service
2) /var/log/syslog
3) /var/log/messages

Ich persönlich bin - bei akuten Problemen - ein Freund von "tail" in Kombi mit "grep" (muss man aber ein wenig aufpassen, was man so rausfiltert). Das könnte dann z.B. mit 3 offenen Shells (zwecks Logs betrachten) so aussehen:

1. Shell: journalctl -xu docker.service
2. Shell: tail -f /var/log/syslog
3. Shell: tail -f /var/log/messages

Falls das zuviel wird mit syslog und messages, kannste halt noch filtern, indem Du einfach z.B. | grep -i docker hinter die Befehle von Shell 2+3 hängst, damit Du nicht alles um die Ohren geschmissen bekommst, sondern nur die Teile, wo auch von "Docker" (-i ignoriert die Groß-/Kleinschreibung) die Rede ist, also z.B. tail -f /var/log/syslog | grep -i docker.

Wenn ansonsten nicht viel auf der Kiste läuft, sollte das aber auch ohne Filter funktionieren... Dann solltest Du auch instant sehen, was genau passiert, wenn Du versuchst den Container zu starten

 

[Confluencer]

# RUN /bin/bash /usr/bin/init.sh -> Container startet aber Dienst startet nicht
# RUN /usr/sbin/smbd -> Container startet aber Dienst startet nicht

RUN Anweisungen erzeugen Image-Layer... Jeder Prozess(!) der in einer RUN Anweisung gestartet wurde, ist mit Beenden der RUN Anweisung ebenfalls beendet. Jede Anweisung startet mit einem neuen temporären Container.

Kleiner Hinweis: Ein Image enthält exakt 0 laufen Prozesse. Lediglich ENTRYPOINT und/oder CMD definieren was gestartet werden soll. Dieses was muss ein Vordergrundprozess sein. Ein Hintergrundprozess ist hier nicht ausreichend und sorgt dafür das der Container sofort wieder beendet wird.

Hier ist noch eine kräftige Portion Rumgerate dabei. Da hilft nur tiefer in Docker einarbeiten, bspw. mit diesem hervorragenden kostenlosen Foliensatz zum Selbststudium https://container.training/intro-selfpaced.yml.html, oder ein fertiges Image von jemand anderem verwenden (ich hatte weiter oben schon eins geteilt).

 

[the other]

Moinsen @Confluencer,
Habe gerade mal in deinen link geschaut und bin begeistert.
Ich hab mit docker bisher nur wenig und dann nur so "Augen zu und durch"-mäßig zu tun.
Das Tutorial macht auf jeden Fall Laune, da endlich mal etwas tiefer einzusteigen. Werd ich beizeiten mal in einer VM anlegen und die Praxissachen ausprobieren. Der praktische Teil geht erst los, die ersten 100 Seiten waren trotzdem als Intro gut zu lesen.
Danke fürs Teilen!

 

[Confluencer]

Gerne!

Der Foliensatz ist besser als jede Docker 3 Tage Schulung. Ich hatte vor 8 und 6 Jahren welche und beide sind nicht so in die Tiefe gegangen und ich wusste mehr als die Trainer Wenn Du Verständnisfragen zu irgendwelchen Folien hast: mach einfach einen Topic auf, dann können wir die Sachen klären.

Das mit den Hands-on Beispielen ist wichtig: nur so bleibt wirklich langfristig etwas hängen.