Anfängerfragen - Linux Neuling? Hier ist der richtige Platz für deine Fragen (2)

  • Ersteller Gelöschtes Mitglied 45455
  • Erstellt am
Wie kann ich eine Anwendung zu einem bestimmten Zeitpunkt starten, so das das auch Reboot/Sleep übersteht?
Hintergrund ist: Ich wecke das System per rtcwake zu einer bestimmten Zeit auf und würde dann gerne schedulen, das 5 oder 10 Minuten später ein Kommando ausgeführt wird. Einmalig. Also Cronjob oder das Kommando direkt nach dem Boot auszuführen ist keine Alternative.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Code:
# /etc/systemd/system/foobar.service
[Unit]
Description=Run foobar

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/bin/foobar

[Install]
WantedBy=multi-user.target
Code:
# /etc/systemd/system/foobar.timer
[Unit]
Description=Run foobar 15 min after boot

[Timer]
OnBootSec=15min

[Install]
WantedBy=timers.target
Code:
systemctl daemon-reload
systemctl enable foobar.timer
 
[Timer]
OnBootSec=15min
Wie kann ich eine Anwendung zu einem bestimmten Zeitpunkt starten, so das das auch Reboot/Sleep übersteht?
Hintergrund ist: Ich wecke das System per rtcwake zu einer bestimmten Zeit auf und würde dann gerne schedulen, das 5 oder 10 Minuten später ein Kommando ausgeführt wird. Einmalig. Also Cronjob oder das Kommando direkt nach dem Boot auszuführen ist keine Alternative.
Mit "direkt" nach dem Boot meinte ich via Timer oder wie auch immer. Das Kommando soll NICHT bei jedem Boot ausgeführt werden.
Ich will heute einstellen, das der Rechner morgen früh um 6 Uhr aufwacht und dann um 6:10 das Kommando ausführen. Wenn ich den Rechner um 14 Uhr neustarte, sollte das Kommando NICHT ausgeführt werden, auch nicht um 14:10. Das Kommando soll nur ausgeführt werden, wenn ich vor dem Shutdown/Sleep explizit gesagt habe, das es beim nächsten Boot passieren soll.

Theoretisch kann das Kommando auch sofort nach dem Boot ausgeführt werden. Die Verzögerung kam nur daher, weil ich mir dachte, man "scheduled" dass und weil ich den Rechner mit rtcwake nach Uhrzeit aufwecke, wäre es ungünstig wenn der Schedule-Zeitpunkt früher läge, als bevor der Rechner vollständig hochgefahren ist.

Hmm, man könnte sich wohl ein Initscript bauen (ginge womöglich auch mit den Services?), das checkt ob eine Datei vorhanden ist, z.B. /root/runIt. Wenn vorhanden wird das Kommando ausgeführt und die Datei gelöscht. Dann kann ich einen touch auf die Datei machen, wenn ich will das es beim nächsten Boot läuft.
Wird init auch durchlaufen, wenn man aus dem Sleep aufwacht?
 
Zuletzt bearbeitet:
Okay? Dann entferne den Timer, aktiviere die Service-Unit direkt und lass die Unit n Script ausführen. Das Script prüft die von dir gewünschten Bedingungen, bspw. ob eine Datei existiert, und wenn ja, dann startet es dein Programm.
Bash:
#!/usr/bin/env sh

set -eu

if [ -f /home/liesel/.run-foobar-on-next-boot ]; then
    exec foobar
fi

exit 0
 
Kennt hier jemand ein Tool / eine Lösung um suspend zu verhindern, solange bestimmte Systemressourcen ausgelastet sind?

Also z.B. „Verhindere suspend, solange die durchschnittliche Auslastung einer CPU in der letzten Minute über 10% lag oder ein Netzwerkinterface oder Datenträger einen durchschnittlichen Durchsatz von min. 500 kB/s hatte.“

Am besten auch beschränkbar auf bestimmte Prozesse und User.

Das ließe sich sicherlich mit einem Skript lösen, aber irgendwie werde ich das Gefühl nicht los, dass es da bereits eine effizientere, robustere und vor allem fertige kleine Lösung gibt. Gefunden hab ich bisher aber noch nichts. (Außer ggf. komplette Monitoring Frameworks.)

Hintergrund ist das temporäre Verhindern von auto suspend während länger laufenden Aufgaben, deren Dauer nicht vorher bekannt und Fortschritt / Abschluss nicht direkt nachvollziehbar ist; z.B. Downloads oder andere länger laufende Vorgänge in GUI Anwendungen. Wäre natürlich besser wenn die Anwendungen das direkt unterstützen würden…
 
Was willst du denn machen? Willst du einfach nicht, dass der PC sleept, wenn ein bestimmtes Programm läuft? Dann ist "systemd-inhibit" für dich richtig:
Bash:
systemd-inhibit --what=sleep --mode=block my-program --foobar
Weißt du nicht welches Programm da läuft bzw. willst generell bei Last ein Sleep verhindern? Dann pingst du "org.freedesktop.ScreenSaver.SimulateUserActivity":
Bash:
if [[ "$(cut -d ' ' -f3 /proc/loadavg)" > 0.5 ]]; then
  dbus-send --session --dest=org.freedesktop.ScreenSaver --type=method_call /ScreenSaver org.freedesktop.ScreenSaver.SimulateUserActivity
  sleep 1m
fi
 
Willst du einfach nicht, dass der PC sleept, wenn ein bestimmtes Programm läuft?
Anwendungszweck wären wie beschrieben GUI Anwendungen, die typischerweise nach getaner Arbeit weiterlaufen.
Dann pingst du "org.freedesktop.ScreenSaver.SimulateUserActivity":
Bash:
if [[ "$(cut -d ' ' -f3 /proc/loadavg)" > 0.5 ]]; then
dbus-send --session --dest=org.freedesktop.ScreenSaver --type=method_call /ScreenSaver org.freedesktop.ScreenSaver.SimulateUserActivity
fi
Mal davon abgesehen, dass es mir explizit um suspend (nicht idle) inhibit geht und /proc/loadavg nicht so funktioniert wie du hier implizierst (normalisiert würde es für diesen Zweck wohl trotzdem ausreichen) ist das genau der Grund, warum ich gefragt hatte:
Das ließe sich sicherlich mit einem Skript lösen, aber irgendwie werde ich das Gefühl nicht los, dass es da bereits eine effizientere, robustere und vor allem fertige kleine Lösung gibt.
Spätestens wenn ich Netzwerk (über /proc/net/dev oder den Output von ss -tip iterieren?) und I/O (???) miteinbeziehen will habe ich am Ende vermutlich dutzende Grenzfälle die mir um die Ohren fliegen können / werden. Jedenfalls zu viele, als dass ich das permanent im Hintergrund laufen lassen würde.

Aber vielleicht verkompliziere ich mir das im Kopf nur unnötig. Trotzdem schon mal danke für den Input.
 
Aber vielleicht verkompliziere ich mir das im Kopf nur unnötig.
Das glaube ich nicht. Ich verstehe aber auch langsam worauf du hinaus willst. Wenn ich persönlich Anwendungen laufen habe, die gerade irgendwas in meiner Abwesenheit machen, dann klemme ich mein Notebook in der Regel an die Steckdose an. Und unter AC habe ich GNOME konfiguriert, dass es dann nicht in den Sleep geht. Und so wie ich dich verstehe willst du einfach "generell" Last erkennen und dann Suspend verhindern. Macht Sinn, aber da fällt mir nichts Fertiges ein. Ich kenne nur Tools, die du manuell aktivierst und dann einen Suspend verhindern.
 
Hallo zusammen,
Zunächst mal ein bisschen einleitendes Bla-bla vor der eigentlichen Frage :)

Ich habe hier einen RasPi 4 rumliegen und bin schon mal ein bisschen in die Linux-Welt "eingetaucht". Ich habe viel rumgespielt mit verschiedenen Sachen (Pi-Hole, adguard, Nextcloud, usw.) aber immer nur ein paar Tage am Laufen gehabt und dann den RPI wieder platt gemacht.
Bin jetzt bei OMV mit Docker angekommen und habe auch hier ein bisschen gebastelt (Heimdall, Portainer, Yacht, Docker Compose...). Ich bekomme es auch meistens zum Laufen aber nur mit YT "Klick-nach-Klick" Anleitungen und ich habe das Problem, dass ich Docker irgendwie nicht wirklich verstehe. Ich würde gerne auch in Themen Absteigen wie Bitwarden oder Nextcloud (auch mit Zugriff von Außerhalb und nicht nur lokal oder via VPN) und das dann "produktiv" nutzen und nicht immer nur ein paar Tage laufen haben. Aber so Sachen wie "Zugriff von Außerhalb" will ich nicht einfach angehen ohne ein gewisses Maß an Grundverständnis.

Wer hier immer noch ließt, hier die eigentliche Frage :d
Gibt es eine gute Adresse um Docker richtig zu Verstehen?
Mit dem Wiki bin ich nicht wirklich warm geworden.
 
Was genau möchtest du den wissen? Die Funktionsweise? Oder die Bedienung?
 
Hmmm ich sag mal stumpf beides :d
Also, dass man in Docker seine einzelnen Container erstellt und die unabhängig voneinander laufen können, bekomm ich noch zusammen.
Aber z.b. einen Container erstellen und starten, da wird es schon dünn.
Portainer macht das ganze ja einfacher, aber außer irgendwelche vorkonfigurierten Container starten ist auch nicht viel drin.
Und wenn es dann anfängt, dass verschiedene Container miteinander kommunizieren sollen ist ganz schnell vorbei.

Also es darf schon gerne sehr Basic sein
 
Nun, im Grunde genommen ist ein laufender Container nichts anderes als ein Prozess in einem chroot. Wenn du Docker das erste Mal benutzt, musst du dir entweder ein Image bauen oder eins herunterladen. Herunterladen kannst du die mit:
Bash:
docker image pull nginx:latest
Gibst du keine Domain an, wird "docker.io" genommen. Gibst du kein Tag an, wird "latest" genommen. Nach dem Download liegt das Image dann irgendwo in "/var/lib/docker", allerdings nicht direkt in einem Verzeichnis, sondern eventuell über mehrere Verzeichnisse verteilt, die dann übereinander gelegt werden, wenn du aus dem Image einen Container starten willst. Docker layert halt die verschiedenen Images, damit sie wiederverwendbar sind. Das "nginx"-Image basiert z.B. auf Debian. Der Debian-Layer kann dann über mehrere Images wiederverwendet werden.

Wenn du jetzt eben aus diesem nginx-Image einen Container erzeugen willst, machst du das entweder mit "docker container create" oder "docker container run". Der "create"-Befehl erstellt den Container, aber startet ihn nicht. Du musst ihn dann nachträglich mit "docker container start" starten. Der "run"-Befehl erstellt ihn und startet ihn auch sofort. Das ist meistens das, was du willst:
Bash:
docker container run --name my-nginx nginx:latest
Idealerweise gibst du den Containern immer mit "--name" einen Namen. Ansonsten generiert dir Docker einen Namen, den man sich logischerweise schlechter merken kann. Was da am Ende wirklich in dem Container ausgeführt wird, bestimmt das Image. Docker hat einen Entrypoint und einen CMD. Der Entrypoint ist nicht selten stumpf "/bin/sh -c", der CMD im Falle des nginx-Containers "nginx". Heißt wenn du den Container startest, führt Docker "/bin/sh -c nginx" im chroot des Containers aus, wodurch du einen sandboxed nginx erhältst. Für eine Übersicht über alle deine Container, nutzt du:
Bash:
docker container ls
Um auch gestoppte Container zu sehen, musst du noch ein "-a" anhängen. Stoppen kannst du dann einen Container mit "docker container stop" und daraufhin dann "docker container rm", damit er nicht nur gestoppt ist, sondern auch entfernt wird:
Bash:
docker container stop my-nginx
docker container rm my-nginx

Wenn du versuchst hast im Browser "localhost" aufzurufen, wirst du bemerken, dass du nicht auf den nginx zugreifen konntest. Das liegt daran, dass du jeden Port eines Containers explizit freigeben musst. Tust du das nicht, kann der Container nur mit anderen Containern im virtuellen Netzwerk kommunizieren:
Bash:
docker container run --name my-nginx -p 8080:80 nginx:latest
Jetzt kannst du auf den nginx unter "localhost:8080" zugreifen.

Es besteht auch die Möglichkeit in einem bereits laufenden Container einen weiteren Prozess auszuführen. Das geht mit "docker container exec". Möchtest du zum Beispiel in deinem nginx-Container eine Bash starten, kannst du das hier machen:
Bash:
docker container exec -it my-nginx bash
Das "-i" steht für "--interactive", das "-t" für "--tty". Das Interactive-Flag brauchst du, wenn der Befehl Daten via stdin erhalten soll, im Falle der Bash die Tastatureingaben. Das TTY-Flag ist dafür gedacht eine Pseudo-TTY anzuhängen.

Möchtest du jetzt zwei Container miteinander kommunizieren lassen, müssen sie im selben Netzwerk sein. Wir stoppen also erstmal unseren "my-nginx"-Container und erstellen ein Netzwerk:
Bash:
docker container stop my-nginx
docker container rm my-nginx
docker network create my-network
An dieses Netzwerk können wir jetzt neue Container anschließen, zum Beispiel:
Bash:
docker container run --name my-nginx --network my-network nginx:latest
Wir können jetzt einen weiteren Container starten, z.B. einen Debian-Container, diesen in das gleiche Netzwerk einbinden und dann z.B. via curl auf den nginx-Container zugreifen:
Bash:
docker container run --rm debian:latest curl http://my-nginx/
Der Hostname ist immer der Name des Containers. Wenn du einen alternativen Namen willst, kannst du mit "--network-alias" einen beim Starten des nginx-Containers festlegen. Wir benutzen hier in dem Befehl auch ein "--rm". Damit wird der Container automatisch gelöscht sobald er gestoppt wird. Da der Container nur so lange läuft wie das "curl" ist er also sofort wieder weg und wir müssen ihm nicht mit "docker container rm" hinterher räumen.

Das letzte wichtige Konzept von Docker sind Bind-Mounts und Volumes. Bind-Mounts sind nichts Anderes als in den Container reingemountete Dateien. Sagen wir einfach mal du hast im aktuellen Verzeichnis deines Hosts eine eigene "nginx.conf" liegen und außerdem deine Webapplikation in einem Verzeichnis "app". Du möchtest du die "nginx.conf" im Container damit überschreiben und außerdem deine App in den Container nach "/var/www" mounten. Dann machst du das z.B. so:
Bash:
docker container run \
  --name my-nginx \
  --rm \
  -p 80:80 \
  -v "${PWD}"/nginx.conf:/etc/nginx/nginx.conf:ro \
  -v "${PWD}"/app:/var/www:ro \
  nginx:latest
Das "-v" besteht aus dein Blöcken, per ":" getrennt. Der erste Block ist die Quelle. Docker ist hier leider etwas... scheiße und will zwingend absolute Pfade. Wir müssen hier also mit der Umgebungsvariable "$PWD" das aktuelle Verzeichnis voranstellen. Der zweite Block ist dann das Ziel im Container. Besteht dieses Ziel bereits, wird es überschrieben. Der dritte Block ist optional und beinhaltet Optionen für den Mount, z.B. "ro" für read-only. Denn der Container muss auf die "nginx.conf" oder in dein "app"-Verzeichnisses nicht schreiben können. "rw" ist nämlich der Default.

Ein Volume mag zwar auf den ersten Blick identisch zu einem Bind-Mount sein, ist es aber nicht. Ein Bind-Mount nimmt eine lokale Datei und loop-mounted sie über eine Datei im Container. Die Datei hat dann im Container den gleichen Owner wie auf dem lokalen Host, also höchstwahrscheinlich den im Container nicht existenten "1000:1000". Ein Volume weist Docker jedoch an ein bestimmtes Verzeichnis im Container zu persistieren. Ist diese Verzeichnis nicht leer, kopiert Docker den Inhalt des Verzeichnisses in das Volume. Ein Container ist per default immutable. Egal was du darin machst, es ist weg sobald der Container beendet wird. Sagen wir einfach mal du hast eine Applikation in einem Container laufen, mit der ein User Bilder hochladen kann. Diese Bilder speichert deine Applikation in "/media". Du möchtest natürlich nicht, dass bei einem Server-Neustart (und damit natürlich auch Container-Neustart) die Bilder weg sind. Also erstellst du ein Volume für dein Verzeichnis:
Bash:
docker volume create my-nginx-media

docker container run \
  --name my-nginx \
  --rm \
  -p 80:80 \
  -v "${PWD}"/nginx.conf:/etc/nginx/nginx.conf:ro \
  -v "${PWD}"/app:/var/www:ro \
  -v my-nginx-media:/media \
  nginx:latest
Damit Docker weiß, ob ein Volume oder ein Bind-Mount gemeint ist, prüft er, ob ein Slash in der Quelle vorkommt. "my-nginx-media" enthält kein Slash, also wird ein Volume benutzt. Docker speichert diese Volumes dann in "/var/lib/docker/volumes". Es ist aber nicht gedacht, dass man manuell in diesen Verzeichnissen rumspielt, auch wenn man könnte. Volumes behandelt Docker als wichtig. Befehle in Docker löschen dir niemals ein Volume zusammen mit einem Container, es sei denn du willst es so. So ist es also auch Best Practive eine MySQL-Datenbank in einem Volume speichern, z.B. mit "-v mysql-data:/var/lib/mysql".

Cooler wäre es bei einer echten Produktivanwendung jetzt natürlich wenn deine Applikation und deine "nginx.conf" nicht immer gebindmounted sein müssen, sondern ebenfalls mit im Image drin sind. Dafür erstellst du dir eine "Dockerfile" mit folgendem Inhalt:
Code:
FROM nginx:latest

COPY ./nginx.conf /etc/nginx/nginx.conf
COPY ./app /var/www
Das "FROM" sagt Docker auf welchem Image unser Image basieren soll. "FROM scratch" ist zwar auch möglich, macht aber selten Sinn, da wir dann selber für unser Dateisystem sorgen müssen, z.B. mit "debootstrap" (Debian) oder "pacstrap" (Arch Linux). Das "COPY" kopiert dann Dateien vom Host in das Image. Wenn du Befehle im Container ausführen möchtest, kannst du das mit "RUN", z.B.:
Code:
FROM nginx:latest

RUN apt-get update && apt-get install -y foobar
Mit dieser "Dockerfile" kannst du dann ein Image bauen:
Bash:
docker image build -t my-nginx:v1 .
Der Punkt am Ende ist der Kontext, in diesem Falle also das aktuelle Verzeichnis. Im Kontext wird nach einer Dockerfile gesucht und auf den Kontext beziehen sich auch alle relativen Host-Pfade in der "Dockerfile". Das "-t" gibt den Tag an, den das fertige Image erhalten soll. Mit diesem Tag können wir das Image dann nachher als Container benutzen, z.B.:
Bash:
docker container run \
  --name my-nginx \
  --rm \
  -p 80:80 \
  -v my-nginx-media:/media \
  my-nginx:v1
Unsere Bind-Mounts müssen wir nun nicht mehr angeben. Immerhin liegen die Dateien jetzt mit im Container.

Noch als Ergänzung:
  • In einem Container sollte immer nur ein Prozess laufen. Manche Leute installieren einen MySQL und PHP im nginx-Container und lassen dann alle drei zusammen mit supervisord oder systemd laufen. Ist scheiße, lass das. Erstell lieber ein Netzwerk und starte drei dedizierte Container für nginx, PHP und MySQL, die alle im gleichen Netzwerk sind. Bonuspunkte für ein Netzwerk für nginx <-> PHP und eins für PHP <-> MySQL. Aber man kann auch overengineeren...
  • Speichere keine Secrets im Container. Wenn du Passwörter übergeben willst, kannst du auch einfach Umgebungsvariablen benutzen z.B. mit "docker container run -e FOO=bar".
  • Benutze am Besten nie "latest", sondern immer Versionen, z.B. "1.24.0", sonst weißt du nie was für ne Version von nginx/PHP/MySQL du bekommst, und das kann uncool werden.
  • Nutze Docker Compose. Compose ist große Liebe. Kubernetes ist für 99% der Anwendungen absolut overkill. Docker Compose aber baut dir aus seiner YAML-Datei die entsprechenden Docker-Befehle zusammen und fährt dir z.B. auch Container runter, die deine Applikation nicht mehr braucht. Docker Compose ist genauso einfach. Wenn du willst, kann ich dir da auch eine Beispieldatei mal schicken.
 
IMHO solltest du vor allem lernen, wie man Dienste korrekt und sicher auf Linux/Unix installiert. Das ganze nach Docker zu übertragen, ist dann die leichteste Übung.
 
@fax668 das wird auf auch Thema, bevor ich anfange mit irgendwelchen Clouds, Passwortspeichern oder Freigaben nach Außen :)
Wenn du irgendwelches hilfreiches Lesematerial hast, sehr gerne schicken.
 
Das zielt zwar in erster Linie auf Desktops, aber wenn du alle vier Teile durchgearbeitet hast inklusive der verlinkten Dokus, dann kannst du mehr als die meisten: 8-)
 
Ich hab hier ne Ubuntu 22.04 LTS VM laufen, die einfach ein SMB-Share bereitstellt. Da ich ja jetzt mittlerweile auch hauptsächlich unter Linux unterwegs bin, wollte ich das auch noch als NFS-Share mit dazu packen. Allerdings bekomme ich den Service dazu nicht gestartet

Bash:
root@files:~# sudo systemctl start nfs-kernel-server.service
A dependency job for nfs-server.service failed. See 'journalctl -xe' for details.
root@files:~# journalctl -xe
-- The process' exit code is 'exited' and its exit status is 32.
May 08 16:27:09 files systemd[1]: proc-fs-nfsd.mount: Failed with result 'exit-code'.
-- Subject: Unit failed
-- Defined-By: systemd
-- Support: http://www.ubuntu.com/support
--
-- The unit proc-fs-nfsd.mount has entered the 'failed' state with result 'exit-code'.
May 08 16:27:09 files systemd[1]: Failed to mount NFSD configuration filesystem.
-- Subject: A start job for unit proc-fs-nfsd.mount has failed
-- Defined-By: systemd
-- Support: http://www.ubuntu.com/support
--
-- A start job for unit proc-fs-nfsd.mount has finished with a failure.
--
-- The job identifier is 335 and the job result is failed.
May 08 16:27:09 files systemd[1]: Dependency failed for NFS server and services.
-- Subject: A start job for unit nfs-server.service has failed
-- Defined-By: systemd
-- Support: http://www.ubuntu.com/support
--
-- A start job for unit nfs-server.service has finished with a failure.
--
-- The job identifier is 333 and the job result is dependency.
May 08 16:27:09 files systemd[1]: Dependency failed for NFS Mount Daemon.
-- Subject: A start job for unit nfs-mountd.service has failed
-- Defined-By: systemd
-- Support: http://www.ubuntu.com/support
--
-- A start job for unit nfs-mountd.service has finished with a failure.

Hat da jemand ne Idee was da los ist?
 
May 08 16:27:09 files systemd[1]: Failed to mount NFSD configuration filesystem.
Wenn man danach googled, heisst es meistens, du musst nfsd installieren, falls du das nicht hast.... und da das ein Kernelmodul ist, musst du auch dafür sorgen, das es erstmal geladen wird... oder einfach nen Neustart machen, wenns richtig installiert wurde, wirds mit einem Neustart ebenso geladen.
 
Ja installiert hab ichs davor extra, bei nem Reboot versucht er auch den Dienst zu starten, dann mit dem Output
 
Code:
The job identifier is 333 and the job result is dependency. 
[/QUOTE]

[QUOTE="KurantRubys, post: 29901504, member: 178919"]
May 08 16:27:09 files systemd[1]: Dependency failed for NFS Mount Daemon. -- 
[/QUOTE]

[QUOTE="KurantRubys, post: 29901504, member: 178919"]
Subject: A start job for unit nfs-mountd.service has failed

Du hast zwar nfsd installiert, aber die Abhängigkeiten dazu nicht.
Warum auch immer ...
Zumindest lese ich das aus der Fehlermeldung heraus.
 
Ich hasse Ubuntu :fresse:
 
Quelle:


Installation​

Sollte NFS noch nicht vorhanden sein, lässt es sich sehr schnell installieren. Folgende Pakete und deren Abhängigkeiten müssen über die Paketverwaltung [1] installiert werden:

Wenn der Rechner als Server dienen soll, der Dateien bereitstellt:

  • nfs-kernel-server
Befehl zum Installieren der Pakete:

Code:
sudo apt-get install nfs-kernel-server
Oder mit apturl installieren, Link: apt://nfs-kernel-server

Wenn der Rechner nur als Client agieren soll, der auf andere Freigaben zugreift:

  • nfs-common
Befehl zum Installieren der Pakete:

Code:
sudo apt-get install nfs-common
Oder mit apturl installieren, Link: apt://nfs-common
 
Genau damit hab ich den Kram tatsächlich installiert, ich bin jetzt auch davon ausgegangen das sich apt die Abhängigkeiten dann schon zieht. Anscheinend falsch gedacht.

Edit: Paket entfernen und neu installieren ändert auch nix daran...
 
Zuletzt bearbeitet:
Gibt es so etwas wie die Software und Paketverwaltung in Mint? dort werden die Abhängigkeiten gleich mit Installiert. Sollte aber eigentlich auch per Konsole gehen. Dafür bin ich aber selber zu unbewandert in solchen Themen.
Code:
sudo apt-get
sollte eigentlich gegenüber
Code:
sudo apt install
alles an Abhängigkeiten mitnehmen, afaik, oder verwechsel ich da etwas?
 
Ne, das ganze ist eh Headless. Aber ich glaub ich hab das Thema schon gefunden. Das Teil läuft als LXC in Proxmox, bei nem reboot ohne installiertes NFS-Paket bekomme ich auch folgende Meldung:

Code:
May 08 21:36:07 files mount[96]: mount: /run/rpc_pipefs: permission denied.
May 08 21:36:07 files systemd[1]: run-rpc_pipefs.mount: Mount process exited, code=exited, status=32/n/a
May 08 21:36:07 files systemd[1]: run-rpc_pipefs.mount: Failed with result 'exit-code'.
May 08 21:36:07 files systemd[1]: Failed to mount RPC Pipe File System.
May 08 21:36:07 files systemd[1]: Dependency failed for rpc_pipefs.target.
May 08 21:36:07 files systemd[1]: Dependency failed for RPC security service for NFS client and server.

MIt etwas rumsuchen hab ich jetzt das gefunden https://discuss.linuxcontainers.org/t/cant-start-nfs-server/7811/6 Dann schaue ich mir das nochmal mit ner VM Umgebung an, da jetzt alles umzubauen weiß ich jetzt schon das ich da mehr Probleme generiere als löse :fresse:

Edit: ja das ist definitiv das Thema, mal schauen ob ich mir das dann so antue oder anders löse...
 
Ich möchte mich gerne an Linux auf meinem Hauptsystem mit einem Dualboot versuchen.

Wichtig ist mir dabei die Unterstützung von Spielen & Windows Programmen ohne großartiges Gebastel.

Habe mit Ubuntu auf meinem Daily Laptop schon Erfahrung gesammelt, nun stellt sich mir die Frage ob ich eher zu Mint oder Manjaro greifen sollte.

Desktopumgebung bei beiden vorzugsweise KDE oder Cinnamon
 
So doof es klingt, da wirst du ausprobieren müssen.

Ich fand Manjoro echt gut, konnte mir aber letztens bei Problemen nicht direkt helfen und habe erstmal wieder die Kubuntu SSD angeschlossen.
Mint ist grundsätzlich "gut", ABER ich habe es nicht geschafft diesen unsagbar dämlichen Keyring abzuschalten.
Du willst irgendwas starten? Gib dein Passwort ein.
Letzten Endes war ich da aber auch zu ungeduldig und habe auf meinem Notebook dann Arch installiert.
(Und muss das irgendwann mal weiter verfolgen, ich bekomme es nicht gescheit ans laufen wie es jetzt ist ohne Netzwerk, eventuell hau ich da mal Manjoro drauf als Übergang).

Dabei habe ich das Testen an meinem Hauptsystem so gelöst, das ich eine alte SSD angeschlossen habe und alles andere abgezogen habe.
So wurde mir mein bestehendes Multiboot nicht zerlegt und ich konnte nach Herzenslust partitionieren und formatieren ohne Gefahr zu laufen irgendwo irgendwas zu vernichten.

Hauptproblem hier:
Die 10 Mbit Dorfleitung.
"Mal eben schnell was installieren" geht von Nachmittags bist Nachts. Da habe ich dann auch nur beschränkt Lust drauf.

Edit:
Meine zwei Displays gehen in den Standby und ALLES was auf meinem WQHD Display läuft wird auf den kleinen 8" Monitor mit 800*600er Auflösung verschoben beim aufwecken.
Der kleine Bildschirm ist so konfiguriert, das er sich mit der Maus unterhalb meines großen Monitors befindet. Ziehe ich die Maus im unteren rechten Drittel nach unten bin ich drauf.
Funktioniert einwandfrei, aber meine Taskleisten sind oben und in dieser Konfiguration -die unter 20.04 LTS einwandfrei lief- lässt sich mit 22.04 LTS die obere Taskleiste zwar auf autohide stellen, sie verschwindet aber nicht. Hängt mit der Position des Bildschirms zusammen, ist dieser nicht unterhalb des Hauptbildschirms konfiguriert kein Problem.
Unter Manjoro war das kein Problem.
 
Zuletzt bearbeitet:
Ich möchte mich gerne an Linux auf meinem Hauptsystem mit einem Dualboot versuchen.

Wichtig ist mir dabei die Unterstützung von Spielen & Windows Programmen ohne großartiges Gebastel.

Habe mit Ubuntu auf meinem Daily Laptop schon Erfahrung gesammelt, nun stellt sich mir die Frage ob ich eher zu Mint oder Manjaro greifen sollte.

Desktopumgebung bei beiden vorzugsweise KDE oder Cinnamon


Manjaro hat schon den Vorteil, dass man schnell Aktualisierungen bekommen, fall irgendwas Neues inkompatibel oder fehlerhaft ist.
Bei den auf Ubunu basierenden Distributionen kann es ja nachdem worum es sich handelt leider schon Mal Jahre dauern, bis von Debia eine neue Hardware die man hat unterstützt wird, oder ein neues Features das man gerne verwenden will, und noch etwas länger, bis es dann zu Mint, Ubuntu usw. durchgesickert ist, wenn man Pech hat.
In Kombination mit z.B. Lutris bekommt man so fast alle Spiele schnell und gut zum Laufen. Leider hat Manjaro aber die letzten ca. zwei Jahre mit massenweise vermurksten Updates "geglänzt", die je nach Konfiguraion teilweise sogar das System boot-unfähig zurücklassen konnten. Ich bin deshalb am Überlegen auf Arch umzusteigen, aber für Einsteiger ist das ja wiederum weniger empfehlenswert ...
Wie Zyxx schon sagte: Ausprobieren.
Natürlich ist auch dies schon ein gewisser Grad von "Gebastel".

Es gibt nun noch einige alternative Distributionen die auf Arch basieren, wo man vielleicht besser fährt, aber da müsste man erst mal nach Erfahrungen suchen ..
So oder so:
Wenn man wirklich null Bock auf Gebastel hat, und obendrein keine Ahnung von Computern, was fast alle reinen Windows-User fälschlicher Weise mit ihren vorhandenen Windows-Kenntnissen (selbst Umfangreichen) gleichsetzen, kann wird man ohne Bereitschaft zu einer längeren Einarbeitungszeit keinen Spaß haben. Denn auch, wenn deutliche Fortschritte gemacht wurde, gibt es doch praktisch immer hier und da etwas Kleines zu schrauben, und in einigen Fällen benötigt es richtigen Aufwand um zu erreichen was man will.
Hinzu kommt natürlich noch der Bias, also die Sammlung von angewöhnten Vorurteilen, die man sich durch ewige Benutzung nur eines Betriebssystems angeeignet hat: Also, dass man nur die Nachteile des Neuen sieht, weil man ja insgeheim eigentlich Alles möglichst so wie zuvor machen will, auch wenn es nun andres funktioniert. Und so wird jeder Unterschied schnell als Nachteil empfunden, und die vorhandenen Vorteile des Neuen werden nicht wahrgenommen, weil man eine Arbeitsweise gewöhnt ist, die aus den existierenden Vorteilen der Andersartigkeit keinen Vorteil ziehen können.

Siehe dazu z.B. die Linus-Challenge. Als Jemand, der seit Kindheit verschiedenste Systeme von z.B. Commodore, Apple, IBM, Atari usw. verwendet hat, hatte ich keine großen Probleme in Linxu reinzukommen. Aber selbst Jemand, der sich sicher selbst für einen Computerexperten hält, und auch von vielen dafür gehalten wird (Linus) kann große Schwierigkeiten haben und große Fehler machen, wenn seine Vorenntnisse sich praktisch ausschließlich auf Windows beschränken, weil man in diesem Fall eben nicht unterscheiden kann zwischen "Dieses Verhalten und dies Bedienung sind typisch für Computer" und "Jenes Verhalten und jene Bedienung sind typisch für Windows", und so ständig auf falsche Fährten gerät. Dieses Phänomen lässt sich in der Linus-Challenge praktisch durchgehend sehen.
Da werden also Dinge als nachteilig udn problematisch dargestellt, die es eben objektiv gar nicht sind, sondern nur dann nachteilig wirken, wenn man nicht weiß, welche Eigenschaften der Bedienungn von Computern wirklich grundlegend für alle Systeme gelten, und welche nur "Windowsgewohnheiten" sind, die aber eben je nach System anderts und häufig auch viel besser gelöst werden.

Aus diesem Bias entstehen dann z.B. unsinnige Ansichten die man gelegentlich sieht, wie z.B: Linux sei daran schuld, wenn Windows zu doof ist, sich selbst auf eine Festplatte/SSD zu installieren auf der zuvor Linux installiert war., Selbstverständlich richtet Linux gar nichts Besonderes oder gar Schädliches mit dem Dateträger an, nur ist Windows derart programmiert, dass es (wie viele seiner Nutzer) einfach prinzipiell davon ausgeht, das einzige Betriebssystem der Welt zu sein, und wenn es dann nichts Bekanntes (bzw. von Microsoft so Vorgesehenes) findet, kommt es damit halt nicht klar, obwohl es technisch nicht das geringste Problem wäre, wenn Microsoft nicht so arrogant programmieren würde.
Zum Vergleich: Ich empfinde es zum Bespiel als extreme Belästigung und Nötigung und überflüssiges Gebastel, was man bei der Installation moderner Windows-Versionen für Verrenkungen treiben muss, um ein lokales Nutzerkonto zu erstellend und zu verwenden. Und das ist ja nicht mal eine technische Notwendigkeit, sondern Microsofts legal fragwürdiger Trick, um mehr und mehr Konsumviercher in ihre Onlineaccounts zu treiben, und sie dort einerseits lukativ um ihre Daten auszuschlachten und anderseits die Nutzer zu verführen, mehr und mehr Cloud-Funktionen tatsächlich zu nutzen und als festen Bestandteil in ihren Alltag einzubauen, bis sie gar nicht mehr davon weg können (Ein Account, sie zu knechten, sie alle zu finden, ins Dunkel zu treiben und ewig zu binden).
So eine dummdreisten Scheißdreck z.B. gibts bei Linux eben nicht, und es gibt genügend Möglichkeiten praktisch alle angeblichen Komfortfunktionen auch ohne persönlichen Ausverkauf zur Verfügung zu haben.

Mehr Aufwand als man als Kind in den 80ern mit Heimcomputern usw. hatte, wo man aus Spaß herumgebastelt hat, hat man heute mit Linux auch nicht. Es ist also nach meiner Definition im "ganz normalen Rahmen".
Und: Als User, der immer dafür gesorgt hat, dass ihn Windows nicht ausspioniert, dass keine ungewollten Updates installiert werden, dass keine Werbung aufpoppt, dass gern genutze Funktionen (z.B: Windows 2000 Starmenü, Quick Launch,"Aufwärts Button" im Explorer, usw.) zur Verfügung stehen, obwohl Microsoft einfach dreist entschieden hatte diese funktionen ohne für den User sinnvollen Grund zu entfernen, und sich dann noch zu ärgern zu müssen, dass Einiges, wie z.b. die individuellen Ordneroptionen für jeden Pfad, aber auch die Audio-Hardwarebeschleunigung unersetzbar entfernt wurden, habe ich mit Windows zuletzt (das war zu Windows 8-Zeiten) so viel Aufwand und Ärger gehabt, dass der Konfigurationsaufwand den ich heute mit Linux nach einer Neuinstallaton habe, dagegen eine Kleinigkeit ist.

Leider haben aber zu Viele die (ebenfalls falsche Vorstellung), dass immer alles sofort gehen müsste, was aber eben nur unter bestimmten Bedingungen mögich ist; vor Allem dann, wenn ein System den Nutzern Entscheindungen zwar abnimmt, aber somit auch die Wahlfreiheit.

Es gibt keine "Einfachheit" ohne Verluste. Und für mich ist das komplexest-mögiche System mit maximaler Freiheit eine absolute Selbstverständichkeit, weil ich Computer so kennenlernte, und dadurch auch schon immer Vorteile genoss, die Jenen die Computer immer nur in Verbindung mit ihnen gar nicht bekannten, mitgelieferten Einschränkungen verwendet haben immer verschlossen blieben.
Wenn man diese Vorteile nicht versteht, kennt, oder wirklich für irrelevant hält - dann wird man sich über Linux, wie über jedes andere richtige(*) Betriebssystem auch, nur ärgern.

(*) "richtige", weil Windows meiner Meinung nach inzwischen nur noch ein gebloateter Application-Launcher mit Spyware ist
 
Zuletzt bearbeitet:
Ich möchte mich gerne an Linux auf meinem Hauptsystem mit einem Dualboot versuchen.

Wichtig ist mir dabei die Unterstützung von Spielen & Windows Programmen ohne großartiges Gebastel.

Habe mit Ubuntu auf meinem Daily Laptop schon Erfahrung gesammelt, nun stellt sich mir die Frage ob ich eher zu Mint oder Manjaro greifen sollte.

Desktopumgebung bei beiden vorzugsweise KDE oder Cinnamon

Im Endeffekt sind die Unterschiede zwischen den Distributionen geringer als vielen Lieb ist :-) Mal abgesehen von der Kernelversion und der Häufigkeit des Updates sind es eher Kleinigkeiten wie Paketmanager oder Updateprozeduren die sich unterscheiden. Und das ist dann sehr subjektiv.

Zu Manjaro vs Mint

Mint - Out of the box ohne viel zu lesen und gebsatel ist vermutlich Mint zu Bevorzugen. Du müsstest feststellen ob der Kernel (da sind die Treiber drin) neu genug ist. Laut https://de.wikipedia.org/wiki/Linux_Mint benutzt Mint aktuell 5.15 LTS. Der Kernel ist von 2021 und hinkt somit fast 2 Jahre hinterher, Das System in deinem Profil (mit der 6900XT) sollte etwa seit Kernel 5.9 oder 5.10 gut Unterstütz sein. D.h. du könntest Mint vermutlich bedenkenlos einsetzen.
Mint major upgrades habe ich noch nie gemacht und kann somit nicht einschätzen wie distruptiv diese sind.

Manjaro - Default ist auch hier immer der letzte LTS Kernel. Hier kannst du den Kernel einfach über ein UI auf eine neuere Version wechseln. Dazu sind die Pakete in der Regel etwas aktueller als in Mint. Da Manjaro jeodch ein Rolling-Release ist solltest du hier auch wesentlich häufiger updates machen. Imho 1 x pro Woche mindestens und regelmäßig. Zudem solltest du damit rechnen etwas mehr Hand anlegen zu müssen als bei Mint. Wichtig: auch wenn das System nahe an Arch ist, soltest du immer die Tools von Manjaro für Wartung und Updates verwenden. Benutzt du z.B. pacman direkt kann das meiner Erfahrung nach zu Problemen führen.

Wenn du mit Ubuntu mit PPAs, Snaps, deb Paketen etc. vertraut bist und nicht gerne experimentierst wirst du vermutlich mit Mint glücklicher sein. Du musst dann aber damit leben, dass es durchaus mal 1-2 Jahre dauern kann, bis die neuste Hardware (CPUs, AMD Grafikkarten) wirklich voll unterstützt ist. Gaming ohne viel "Gebastel" beschränkt sich für dich dann weitestgehen auf Steam und Proton was erstaunlich gut funktioniert aber nicht perfekt ist.

KDE vs Cinnamon: Einfach beides ausprobieren, das ist sehr subjektiv. Ich persönlich mag KDE lieber da flexibler und mittlerweile auch mehr Cutting Edge in Richtung Wayland etc.

Wenn deine Erwartung ist, du möchtest ein Linux das wie Windows ist, solltest vielleicht eher bei Windows bleiben.
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh