Programme installieren: Anwendungsmanager vs. Setup-Datei

[Cinematic]

Hi miteinander,

ich bin frisch von Win10 auf Linux Mint umgestiegen.

Meiner Recherche nach wird empfohlen immer aus dem Anwendungsmanager (AM) zu installieren, weil:

1. Sicherheit: die Pakete aus dem AM stammen aus verizifierten Quellen
2. Automatische Updates: der Update-Manager regelt alles
3. Dependency-Management: der AM lädt automatisch die notwendigen Abhängigkeiten
4. Kompatibilität: man bekommt immer eine zu seiner Linux-Distro kompatible Programminstallation
   • Ist dies für Linux Mint überhaupt relevant? Kann es überhaupt passieren, dass eine Deb- oder AppImage-Installationsdatei mit Linux Mint nicht kompatibel ist? ..Oder gibt es andere Setup-Dateiformate, wo man nicht sicher sein kann, ob das mit Linux Mint funktioniert (.tar.gz oder Ähnliches)?

Bei dem Programm Freefilesync ist es jedenfalls so, dass es auf der offiziellen Downloadseite die Version 13.9 gibt,
im AM jedoch nur Version 13.3-2
-> das Programm wird scheinbar über den AM nicht aktuell gehalten.
Sollte ich also bei jedem Programm einzeln prüfen, ob es im AM aktuell gehalten wird, und falls nicht, lieber über die offizielle Downloadseite installieren?
Und kann ich bei Programmen aus dem AM eigentlich irgendwie herausfinden, ob diese vom offiziellen Entwickler dort zur Verfügung gestellt wurden?

 

[ghecko]

-> das Programm wird scheinbar über den AM nicht aktuell gehalten.

Das ist falsch. In den Quellen sind nur nicht die neuesten Versionen von allen Programmen, sondern stabile Versionen.
Wenn die 13.9 sich als stabil genug beweist, landet sie irgendwann schon in den Quellen. Wenn auch vllt in denen der nächsten Mint-Version. Bei Sicherheitsupdates, also wenn Fehler in einer Version gefunden werden, werden die jedoch sofort ausgerollt.

Willst du bleeding edge, ist das unter Mint mit Aufwand verbunden. Da ist es einfacher, du benutzt eine Distri mit Rolling Release.

Ich würde mir also die Frage stellen, ob du das spezifische Programm in der aktuellsten Version brauchst.
Wenn es nur um wenige Programme geht, kann man die Manuell verwalten oder über externe Repositories, falls existent, einbinden.
Wenn das mehrere Programme betrifft, dann überlege dir, ob du bei Arch und seinen Abkömmlingen nicht vielleicht besser aufgehoben bist als bei Debian.

Ist dies für Linux Mint überhaupt relevant? Kann es überhaupt passieren, dass eine Deb- oder AppImage-Installationsdatei mit Linux Mint nicht kompatibel ist? ..Oder gibt es andere Setup-Dateiformate, wo man nicht sicher sein kann, ob das mit Linux Mint funktioniert (.tar.gz oder Ähnliches)?

.deb ist grundsätzlich mit allen Distributionen kompatibel, die apt als Paketverwaltung verwenden (Debian). Zu Konflikten kann es kommen, wenn Abhängigkeiten nicht aufgelöst werden können, weil zb. die Paketquellen der Distribution sehr konservativ sind, das zu installierende .deb aber Abhängigkeiten in einer Version fordert, die über die distributionseigenen Quellen nicht gelöst werden können.

AppImage kann man sich vorstellen wie ein Container, in dem alles drin ist was das Programm zum laufen braucht. Diese sollten auf jeder Distribution laufen.

 

[Teuti]

Moin, neuere Programm-Versionen gibt es meistens auch über Appimage oder Flatpak. Der AM hinkt doch manchmal sehr lange hinterher.

 

[Cinematic]

@ghecko Ok verstehe, also wenn ich Wert darauf lege, dass Freefilesync stabil läuft, dann sollte ich stets nur die Version installieren, die auch im Mint-AM angeboten wird?
Und wie gehe ich mit Programm um, die nicht im Mint-AM existieren? Würde es sich da ggf. empfehlen die neue Versionen nicht sofort zu installieren, sondern z.B. mit 3 Monaten Verzögerung? Oder ist das Risiko von Instabilitäten so gering, dass ich einfach immer die neuste Version von allem installieren kann?

 

[Rossie]

Sollte ich also bei jedem Programm einzeln prüfen, ob es im AM aktuell gehalten wird, und falls nicht, lieber über die offizielle Downloadseite installieren?

Nein. Man sollte sich als Anfänger an den Paketmanager halten. Ansonsten kann es zu Problemen kommen. Mal abgesehen von dem Aufwand. Wie oben geschrieben: der Paketmanager regelt alles. Betreibst Du bei iOS oder Android auch Recherche, ob es eine neuere Version gibt?

Je nach Distro gibt es im Repo neuere Versionen mit mehr oder weniger zeitlichem Verzug. Das ist normal und in den meisten Fällen kein Grund zur Sorge. Distro Updates regelmäßig einspielen und Distro Upgrades mitnehmen. Daran hängt es wegen der Abhängigkeiten auch mitunter, dass ein Programm nicht in der neuesten Version im Repo vorhanden ist. Wie bereits angesprochen, gibt es hier unterschiedliche Ansätze - rolling vs fixed release. Beides hat Vor- und Nachteile.

 

[garfield121]

In der Anwendungsverwaltung von Linux Mint findet man Debs aus Ubuntu-Repos und Mint-Repos plus Flatpaks von Flathub. Die Flatpaks werden überwiegend gut gepflegt, oft neueste Versionen.

 

[ghecko]

Ok verstehe, also wenn ich Wert darauf lege, dass Freefilesync stabil läuft, dann sollte ich stets nur die Version installieren, die auch im Mint-AM angeboten wird?

Das bedeutet nicht, das die neueste Version nicht stabil ist. Eher ist die Philosophie der Distribution, erst mal abzuwarten, ob es mit der Softwareversion irgendwelche Probleme gibt. Erst dann landet sie in den Paketquellen.
Es ist aber am sichersten und komfortabelsten, den Paketmanager und die dort enthaltenen Pakete zu nutzen.

Oder ist das Risiko von Instabilitäten so gering, dass ich einfach immer die neuste Version von allem installieren kann?

Wenn ein spezifisches Programm nicht in den Paketquellen existiert oder du die neueste Version brauchst, dann installier einfach die Version die du brauchst an der Paketverwaltung vorbei, soweit das konfliktfrei geht. Du musst dich dann halt um die Aktualisierung bemühen.
Oder solche Programme generell nur als Flatpak nutzen. Damit hast du dann eine separate Paketverwaltung, die deine Flatpaks aktuell hält.

Oder eben eine Distribution nehmen, die Software gleich an alle ausrollt, wenn sie aktualisiert wird.

 

[Teuti]

Moin, dass die Programm- Versionen die noch nicht in Mint-AM eingepflegt worden sind, generell nicht stabil laufen halte ich für ein Gerücht. Es ist m.E. nach fehlt bei den Distros oft die Manpower alles zu testen. Und ja, ich betreibe auch bei Android und IOS Recherche, für Programme die mir wichtig sind.

 

[honky-tonk]

lso wenn ich Wert darauf lege, dass Freefilesync stabil läuft, dann sollte ich stets nur die Version installieren, die auch im Mint-AM angeboten wird?

bei einem mint "release" werden immer bestimmte pakete auf eine version festgepinnt und es wird geschaut dass alle programme gut zusammenarbeiten bspw export von daten von einem in ein anderes programm. daher wird an dieser version festgehalten, sicherheitspatches werden teilweise rückportiert etc. es kann aber vorkommen, dass irgendwann die alte festgepinnte version inkompatibilitäten hat die bspw in der neusten version schon behoben sind und es sinnvoll sein kann die manuell zu installieren, andersrum kann es auch sein dass die neuste version nicht mit dem rest des systems zusammenarbeitet. Generell würde ich so lange an der version des paketmanagers festhalten bis es probleme gibt.

 

[Lotsenbruder]

Für dich, als Einsteiger bei Linux, empfehle ich dir erstmal nicht so viele Gedanken über die Programme und deren Aktualität zu machen, sondern dich eher mit dem System und seinen Eigenheiten vertraut zu machen.
Da zu kannst Du erstmal den passenden Link in meiner Signatur lesen und ansonsten empfehle ich noch die Videos von Linux Guides zu schauen. Da ist für Einsteiger viel dabei .

 

[gimmix]

Der "Anwendungs-Manager" ist bei Mint nur eine grafische Benutzeroberfläche für die Befehlsschnitstellen apt bzw. flatpak. Als solche macht er die Installation von Programmen zwar bequem, verwischt aber die technischen Hintergründe, weshalb du solche Fragen stellst wie in deinem Eröffnungspost.

Tipp: Informier dich über die Befehlsstruktur von apt. Dazu gibst du im Terminal ein:
man apt
Genauso kannst du es auch mit flatpak machen. Und wenn du dich dann mit den Grundlagen der Paketverwaltung von Mint ein wenig auskennst, darfst du anschließend das Risiko der Installation von externen .deb-Paketen und "unconfirmed" Flatpaks selbst einschätzen.

Oder, wenn dir das alles zu kompliziert ist: Verwende einfach den "Anwendungs-Manager" und lass alles, was es da nicht gibt, weg.
Oder, wenn du immer die neuesten Softwareversionen haben willst: Benutze EndeavourOS.

 

[Teuti]

Moin @Cinematic, ich an deiner Stelle würde mich 1-2 Monate mit LM beschäftigen, regelmäßig Backups machen, und dann, da Linux auch keine Raketenwissenschaft ist, die Sachen ausprobieren die du meinst.

 

[kim88]

Um das ganze etwas aufzuspalten.

Es gibt im Grunde zwei Arten von Distributionen: Es gibt Point-Release Distributionen und Rolling-Release Distributionen.

Linux Mint ist eine Point Release Distribution. Sprich mit der Veröffentlichung von Linux Mint 22, wurde alle Programm-Versionen (gibt einige Ausnahmen z.b. Browser) festgefroren. Und wärend der Lebenszeit von Linux Mint 22 bekommen die keine Funktion- bzw Versions Updates.

Was es geben kann sind Sicherheits- und Bugfixupdates. "Stabil" bedeutet im Linux Umfeld nicht, dass die Software "stabil" läuft oder nie abstürzt. Stabil bedeutet, dass die Versionsnummer "stabil" bleibt.

Das kommt aus der "Geschichte" von Linux. Bzw aus dem Ort wo Linux meistens eingesetzt sind, dass sind Server.
Als Beispiel auf einem Server willst du zwingend ein "stabiles" System - im Sinne von Versionsnummern die sich nicht ändern.

Als Beispiel auf dem Computerbase Server läuft Linux, und dort ist PHP in der Version 7.4 installiert (nur ein Beispiel). Das Forum und alles rundherum funktioniert damit problemlos. Also willst du das das so bleibt. Wenn nun plötzlich über die Updates ein PHP 8.3 eingespielt wird, kann es sein dass das Forum damit gar nicht mehr funktioniert und du dann ein riesenproblem hast.

Deswegen haben alle kommerziellen Linux Distributionen Support-Zyklen von 10 und mehr Jahren - sprich du installierst dort einen Service (z.b. dieses Forum) und weisst das du 10 Jahre Sicherheitsupdates bekommst aber sonst ruhe hast und es zu keinen Version-Kompatibilitätsprobleme kommt. Das ist die Linux Definition von "stabil".

Beim nächsten Release z.b. Linux Mint 23, weiss man frühzeitig welche Versionen dort an Software kommt und man hat dann ein paar Monate Zeit das Upgrade vorzubereiten und seine Services entsprechend anzupassen, damit sie mit den neuen Versionen wieder funktionieren.

Das Gegenmodell dazu sind Rolling-Release Distributionen

Rolling Release sind per se "nicht stabil" - wollen das auch nicht sein. Das bedeutet nicht das Rolling Release Distirbutionen ständig abstürzen - sondern das sie Versionsupgrades immer direkt einspielen. Also wenn morgen PHP 8.5 veröffentlicht wird, wird das direkt als Update zur Verfügung gestellt.

 

[Cinematic]

Sehr interessant, vielen Dank für Eure Erklärungen!

Ich habe nach dem Ratschlag aus einem Linux-Security-Video (ca. bei 5:25min) einen nicht-root-user erstellt, auf dem ich nun immer angemeldet bin, und mich auf dem root-user nur noch anmelde, wenn unbedingt notwendig.

Ist das so nun korrekt konfiguriert wie unten auf den Screenshots zu sehen?
Bei meinem User "tymo" stand anfangs "Kontotyp: Standard", jedoch hat sich der Kontotyp automatisch auf Systemverwalter geändert, als ich mit meinem root-user sudo usermod -aG sudo tymo ausführte.
Ist das so in Ordnung? Wenn ja, dann schließe ich daraus, dass die beiden Aussagen "Mein Konto ist vom Typ Systemverwalter" und "Mein Konto hat Root-Rechte" nicht äquivalent sind?
Denn das Ziel war es ja mit einem User angemeldet zu sein, der nicht Root-Rechte hat, also nicht alles machen kann, was er möchte.

 

[ghecko]

Also den klassischen "Admin" gibt es unter Linux als Benutzer normalerweise nicht. Jede Aktion, die solche Berechtigungen erfordert, fragt dich nach dem root Passwort und nur diese Aktion wird dann mit entsprechenden Rechten ausgeführt. Es sei denn du agierst aus einem Terminal oder einem Programm heraus, dem du durch su solche Rechte vorher gewährt hast. Dann ist jede Aktion innerhalb dieser Umgebung mit root-Rechten ausgestattet.

als ich mit meinem root-user sudo usermod -aG sudo tymo ausführte.
Ist das so in Ordnung?

Sicher ist es, einen normalen User zu haben, unter dem du für spezifische Aktionen, unter Nutzung deines Root-Passworts, diese Aktionen mit den entsprechenden Rechten ausstattest (sudo).
Genau genommen ist es wichtig, das du ein Account benutzt, der keine Root-Rechte hat. Und dein Root-Passwort muss sich von deinem User-Passwort unterscheiden.
Du brauchst also keinen Admin-Account. Du brauchst nur das root-Passwort.
Der Zustand nach der Installation war schon sicher. Es ist nur wichtig, das man ein separates User und Root-Passwort verwendet. Bei vielen Distributionen hat man diese Möglichkeit bereits beim Installieren der Distribution. Und ich kenne keine Distribution die dir ein Adminkonto erzeugt und dich da als User drin agieren lässt.

 

[Cinematic]

Sicherer ist es, einen normalen User zu haben, unter dem du für spezifische Aktionen, unter Nutzung deines Root-Passworts, diese Aktionen mit den entsprechenden Rechten ausstattest.
Genau genommen ist es wichtig, das du ein Account benutzt, der keine Root-Rechte hat.

Wie genau erstelle ich so einen Nutzer (oder ändere meinen Nutzer "tymo")?

Und dein Root-Passwort muss sich von deinem User-Passwort unterscheiden.

Warum ist das wichtig? Falls ich mir Malware wie einen Keylogger einfange, werden früher oder später ja alle meine Passwörter abgefangen.

Du brauchst keinen Admin-Account. Du brauchst nur das Passwort.

Meinst du das wiefolgt? ->
Es muss ein Admin-Account existieren, jedoch brauche ich mich nie mit dem Admin-Account anmelden, sondern nur das Passwort davon benutzen.

Falls du das nicht so meintest: wie kann ich denn ein Root-Passwort festlegen, ohne dass dazu ein Account existiert?

 

[gimmix]

Wenn du den user "tymo" in die Gruppe sudo aufgenommen hast, hast du uneingeschränkte Rechte (root-Rechte), wenn du einem Befehl ein sudo voranstellst (sudo=SuperUserDo).

Es gibt Distributionen, wo du während der Installation entscheiden kannst, ob du neben einem normalen Useraccount noch einen Root-Account einrichtest (Debian, Arch, ...) - und es gibt andere Distros, die auf einen Root-Account verzichten und den User-Account direkt in die Sudo-Gruppe aufnehmen (Fedora, Ubuntu, ...).

Da Mint im Wesentlichen so funktioniert wie Ubuntu, ist der ursprünglich angelegte Account, den du "admin" genannt hast, ein User-Account mit Root-Rechten mittels sudo. Also genauso wie der zweite User-Account mit Namen "tymo". Du kannst "tymo" löschen und den "admin"-Account in "tymo" umbenennen - das käme aufs selbe hinaus.

 

[ghecko]

Falls ich mir Malware wie einen Keylogger einfange, werden früher oder später ja alle meine Passwörter abgefangen.

Ja, aber was soll ein Adminkonto daran ändern? Dort könntest du dir ja auch einen Keylogger einfangen.

Warum ist das wichtig?

Weil zwei Passwörter sicherer sind als eins für alles. Eins ist bei vielen Distris leider der Standard.

Es muss ein Admin-Account existieren, jedoch brauche ich mich nie mit dem Admin-Account anmelden, sondern nur das Passwort davon benutzen.

So in etwa. Du kannst mit Sudo und dem root-Passwort spezifischen Aktionen unter deinem normalen Benutzer root-Rechte geben, wenn das nötig ist und dein User teil der Sudo-Gruppe ist, die diesen Befehl benutzen dürfen.

wie kann ich denn ein Root-Passwort festlegen, ohne dass dazu ein Account existiert?

root existiert immer unter Linux. Je nach Umgang der Distribution damit wird er als separater User angezeigt (Admin-Konto) oder eben nicht.

 

[gimmix]

Vielleicht ist dieser Grundlagenartikel ganz hilfreich.

Ergänzung (10. Dezember 2024)

Ich habe nach dem Ratschlag aus einem Linux-Security-Video (ca. bei 5:25min) einen nicht-root-user erstellt, auf dem ich nun immer angemeldet bin, und mich auf dem root-user nur noch anmelde, wenn unbedingt notwendig.

Der Typ in dem Video benutzt Debian und ist eingeloggt als root. Du hingegen benutzt einen Fork von Ubuntu, wo man sich gar nicht als root einloggen kann. Deswegen hast du jetzt unsinnigerweise zwei User, beide in der sudoer-Gruppe.

Und generell: Informier dich erstmal über die Basics, bevor du irgendwelche Befehle, die du nicht verstehst, aus irgendeinem Youtube-Video abtippst!

Gute Informationsqellen sind: Ubuntuusers und Arch-Wiki.

 

[foofoobar]

Wenn du den user "tymo" in die Gruppe sudo aufgenommen hast, hast du uneingeschränkte Rechte (root-Rechte), wenn du einem Befehl ein sudo voranstellst (sudo=SuperUserDo).

Du denkt noch zu Windows-mässig, das ist die sudoers-policy die da zieht.

https://linux.die.net/man/5/sudoers

sudo ist ein stinknormales suid-root Binary welches aufgrund einer Policy Programme mit anderen Usern laufen lässt. Zack, Bumm, Aus. Kein Voodoo-Foo wie bei Windows.

Beispiel:

~/Trala$ cat print-uid.c
#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>


void main()
{
    printf("ruid: %d\n", getuid());
    printf("euid: %d\n", geteuid());
    setuid(0);
    printf("ruid: %d\n", getuid());
    printf("euid: %d\n", geteuid());
    exit(0);
}
~/Trala$ make print-uid
cc     print-uid.c   -o print-uid
~/Trala$ ls -l print-uid
-rwxrwxr-x 1 XXX XXX 16136 Dec 10 18:16 print-uid
~/Trala$ ./print-uid
ruid: 1000
euid: 1000
ruid: 1000
euid: 1000
~/Trala$ sudo chown root.root ./print-uid
~/Trala$ sudo chmod u+s ./print-uid
~/Trala$ ls -l print-uid
-rwsrwxr-x 1 root root 16136 Dec 10 18:16 print-uid
~/Trala$ ./print-uid
ruid: 1000
euid: 0
ruid: 0
euid: 0
~/Trala$

Oder auch ein sudo für Arme: (Nur echt mit Warnings :-)

~/Trala$ cat sh-super.c
#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>


void main()
{
    printf("ruid: %d\n", getuid());
    printf("euid: %d\n", geteuid());
    setuid(0);
    execl("/bin/bash", NULL);
    exit(0);
}
~/Trala$ make sh-super
cc     sh-super.c   -o sh-super
sh-super.c: In function ‘main’:
sh-super.c:12:9: warning: argument 2 null where non-null expected [-Wnonnull]
   12 |         execl("/bin/bash", NULL);
      |         ^~~~~
In file included from sh-super.c:3:
/usr/include/unistd.h:594:12: note: in a call to function ‘execl’ declared ‘nonnull’
  594 | extern int execl (const char *__path, const char *__arg, ...)
      |            ^~~~~
sh-super.c:12:9: warning: not enough variable arguments to fit a sentinel [-Wformat=]
   12 |         execl("/bin/bash", NULL);
      |         ^~~~~
~/Trala$ ./sh-super
ruid: 1000
euid: 1000
~/Trala$ id -u
1000
~/Trala$
exit
~/Trala$ sudo chown root.root ./sh-super
~/Trala$ sudo chmod u+s ./sh-super
~/Trala$ ./sh-super
ruid: 1000
euid: 0
~/Trala# id -u
0
~/Trala#
exit
~/Trala$