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

[Fallwrrk]

Ich habe in der fstab relatime und lazytime gesetzt, allerdings weiß ich nicht, ob defaults wirklich benötigt wird.

Defaults wird nur benötigt, wenn du sonst keinerlei Optionen gesetzt hast und die Spalte ansonsten leer wäre. In deinem Fall also nein. Die meisten der Optionen in deiner fstab sind aber redundant.

dev/mapper/VG-root /     ext4 lazytime                       0 1
dev/mapper/VG-home /home ext4 lazytime                       0 2
dev/sda1           /boot vfat lazytime,fmask=0022,dmask=0022 0 2
dev/mapper/VG-swap none  swap defaults                       0 0

"lazytime" macht bei Swap keinen Sinn, da der Swap keine Zeitstempel hat. Die fmask von /boot könntest du noch auf 0133 stellen, damit die Dateien auf der Partition nicht ausführbar sind, das braucht nämlich keine Datei auf der Partition. Ansonsten sind viele Optionen sowieso default und können weggelassen werden.

Wäre so eine Konfiguration für SSDs ok?

Da gibt es heutzutage nichts mehr zu tun. Auch bspw. die "ssd"-Option bei Btrfs wird inzwischen eh autodetected. Die Default-Options passen in 99% der Fälle perfekt.

Weiß also nicht, ob MAC für Standalone-Rechner wirklich Sinn macht. Dann gibts noch linux-hardened Kernel, welches im Gegensatz zum normalen Kernel mehr Quality Bits bietet.

Ich glaube du machst dir für einen stinknormalen Heimrechner zu viele Gedanken. SELinux und andere MACs machen nur im Serverumfeld wirklich Sinn. Der Nutzen einer MAC ist es einzelne Prozesse oder Ordner weiter zu isolieren als es die normalen Unix-Permissions es zulassen. Beispielsweise dass der Webserver ausschließlich Dateien innerhalb "/srv" und seine eigenen Binarys und Libraries lesen kann oder dass ein einzelner Nutzer nicht in "/srv" schauen darf. Für Desktops ist das absolut Overkill und wird dir entweder (A) nichts bringen, weil die Regeln viel zu lasch sind, oder (B) dich in den Monitor schlagen lässt, weil irgendwas bei aktiviertem SELinux wieder nicht geht, du aber nicht herausfindest wieso oder es dir aufn Sack geht regelmäßig wieder SELinux zu konfigurieren. Richte dir ne Firewall ein, damit du nicht versehentlich irgendwelche Dienste von außen erreichbar machst, und dann bist du schon auf der sicheren Seite.

Einfach nur "VG" ist übrigens ein gefährlicher Name für eine VG. Wenn du mal eine Festplatte ansteckst, deren VG ebenfalls "VG" heißt, dann hast du richtig Spaß! Idealerweise heißt die VG...

"$(hostname -s)"-"$(cat /etc/machine-id)"

...also zum Beispiel "localhost-563d4bafff33439cac6eee8bc7ed50de". Dann bist du 100% auf der sicheren Seite.

 

[theoradicus]

Zwischendurch mal ein kleiner Statusbericht über lustige Konsolenfeatures und Schriftarten-Spielereien.

Die erstaunlichen Linux-Weisheiten von

fortune

kennen vermutlich einige.
Nach ein wenig Hochleveln wird oft

fortune|cowsay

genutz, wobei es bei einigen Distributionen inzwischen ein "offensive" package gibt - Link auf Bugreport vorsorglich wegen Forumsregeln und Anstand .

In bunt gibt es dann

fortune|cowsay|lolcat

und Farben bei der Texteingabe sind eine schöne Bereicherung, wenn sie denn immer überall funktionieren.
Viele shells und inzwischen auch essentielle Tools (gcc 4.9 in 2014) bieten Texteinfärbung/Themes als Standard an.

Inzwischen ist auch Unicode relativ verbreitet und zu den immer neueren Unicode-Versionen mit neuen Zeichen gesellen sich auch Emojis. Aktuell Emoji 11.0 zu Unicode 11.0 gehörend und die 12.0 ist in Entwicklung/Abstimmung.

Fast so schön wie die 2GB Dateigrößengrenze bzw. Large File Support kommt jetzt die Limitierung der Fontformate TTF,OTF auf 64k verschiedene "Glyphen" ins Spiel - die eben nicht für alle möglichen Zeichen oder Emojis ausreichen. Eine Glyphe ist ein "Zeichen" zB in einer TTF Schriftart - also Zahl, Ligatur, Emoji

Da nicht jeder japanische Schriftarten, technische Symbole oder Emojis benötigt und damit Schriftarten klein bleiben und nicht jeder Typograph / Schriftartenersteller mal eben >100k Glyphen designt, werden die Texte aus verschiedenen Schriftarten zusammengesetzt: zB Windings, MdSymbol für Symbole , Arial für Text

Oder es werden nach bestimmten Regeln aus anderen Schriftarten die fehlenden Glyphen herausgesucht.
Bei Linux ist dafür Fontconfig verantwortlich.

ls /etc/fonts/conf.d  #aktuelle Regeln
ls /etc/fonts/conf.avail #verfügbare Regeln

Außerdem kann in quasi jedem beliebigen Pfad - je nach Konfiguration oder Umgebungsvariablen - oft .fonts .fontconfig .config/.fontconfig weiter konfiguriert werden

Dank übergreifender 4K Monitore und genereller LCD Technik gab es auch ein paar Aufhübschungen, die nun vermutlich immer aktiv sind.

Allerdings versagt Fontconfig bisher noch bei den neuen hippen Farb-Emojis und sowieso farbigen Schriftarten - also Schriften mit integrierter Farbdarstellung - im Terminal ist die Farbe über die Umgebung/Escape-Codes geregelt. Die Features sind oft nicht ausreichend implementiert.

Google hat die Noto Fontreihe mit verschiedenen Schriftarten für Unicode-Teilbereiche, die dann sinnvoll zusammengesetzt werden sollen.
Einige Bugs gibt es da schon noch
Microsoft hat Symbola.

Je nach eingesetzter Fontkonfiguration können dann Zeichen farbig sein oder eben schwarz/weiß. Oder unterschiedlich groß. Oder eben eine weiße/schwarze Box mit der Unicodenummer. gucharmap zeigt ersetzungen und enthaltene Glyphen von installierten Schriftarten an.

Während unter Xorg / graphischer Oberfläche und den Terminals dort alles noch funktioniert, gilt für die Kernelkonsole/TTY (STRG+ALT+F<1..7>) trotzdem noch ein iirc ~256 Zeichenlimit.

kmscon schafft zwar Unicode und normale Schriftersetzung als Ersatz für normale Kernelkonsole, hat aber bei bestimmten Emojis dann Probleme.

Früher war jedenfalls alles einfacher. 8.3 Dateinamen, ASCII Zeichensatz-Strings ohne Sonderzeichen oder Leerzeichen !

Es folgt die geheime Botschaft - eigentlich könnte die nur Farbig sein...:
♉♊♋♌♍♎♏♐♑♒

Am besten damit in Verbund mit normaler Schrift auf Fehlersuche gehen ^^

PS: Interessant - ein paar Emojis überstehen das Editieren nicht.

- - - Updated - - -

Das waren die Emojis ursprünglich:

😵😰😀😂🙀😈😇😤🙌🙈🙏♉♊♋♌♍♎♏♐♑♒🦖🏠

 

[Gelöschtes Mitglied 144635]

Quotes zerstückeln ist mir zu aufwändig...

Defaults wird nur benötigt, wenn du sonst keinerlei Optionen gesetzt hast und die Spalte ansonsten leer wäre. In deinem Fall also nein. Die meisten der Optionen in deiner fstab sind aber redundant.

dev/mapper/VG-root /     ext4 lazytime                       0 1
dev/mapper/VG-home /home ext4 lazytime                       0 2
dev/sda1           /boot vfat lazytime,fmask=0022,dmask=0022 0 2
dev/mapper/VG-swap none  swap defaults                       0 0

Also ist relatime auch standardmäßig drinn, wenn es ich es nicht extra reinschreibe. Gut zu wissen.



Richte dir ne Firewall ein, damit du nicht versehentlich irgendwelche Dienste von außen erreichbar machst, und dann bist du schon auf der sicheren Seite.

Habe dank archwiki schon nftables einrichten können. Ausgehende Verbindungen erlaubt und eingehende blockiert (Whitelist-Methode). Vielleicht kann ich noch Whitelisting für ausgehende Verbindungen machen, aber dazu müsste ich erst alle nötigen Ports aufschreiben.

Einfach nur "VG" ist übrigens ein gefährlicher Name für eine VG. Wenn du mal eine Festplatte ansteckst, deren VG ebenfalls "VG" heißt, dann hast du richtig Spaß! Idealerweise heißt die VG...

"$(hostname -s)"-"$(cat /etc/machine-id)"

...also zum Beispiel "localhost-563d4bafff33439cac6eee8bc7ed50de". Dann bist du 100% auf der sicheren Seite.

Das sieht zwar nicht mehr so schön aus, aber auch eine Lösung. "VG" war nur ein Beispiel von mir; selber nutze ich andere Namen.

Bezüglich AUR und auracle:
Kann das Paket auch erkennen, wenn Dependencies eines AUR-Pakets durch "pacman -Syu" aktualisiert wurden? In dem Fall müsste man laut archwiki jeweilige AUR-Pakete neu konstruieren, damit die ordnungsgemäß funktionieren.

Übrigens habe ich letztens ein AUR-Paket installiert, wo ich zunächst

gpg --recv-keys [PGPkey]

ausführen musste, da der key noch nicht im Keyring war.
In /etc/makepkg.conf muss man zuvor auch weitere Checksums wie sha256 setzen, da in einer Zeile standardmäßig nur md5 aufgeführt war.


Beim Thema Sicherheit frage ich mich noch, ob in Linux standardmäßig Schutz gegen Brute-Force Attacken vorhanden ist? Für ssh kann man entsprechendes einrichten, aber ssh nutzt man sowieso nur für Server und nicht für Normalrechner.

siehe z. B. diese Meldung:
Xbash: Malware greift Linux und Windows an und agiert extrem vielseitig - Notebookcheck.com News

ältere (SSH betreffend): Python-Botnet rekrutiert Linux-Rechner

 

[theoradicus]

standardmäßig Schutz gegen Brute-Force Attacken

Brute-Force-Attacken auf verschiedenste Dienste

Alles via google:
Fail2Ban reagiert nicht nur auf sshd , siehe Dokumentation

Ansonsten auch Knockd und verschiedene whitelist/blacklist Methoden für ganze IP-Ranges/AS Bereiche Bsp: Telekom.
Bei knockd gibt es keine Brute Force. Bei IPv6 ist Brute Force auch etwas schwerer.
Eventuell Konfiguration in Jails/Containern, network namespaces, binden an bestimmte Interfaces ...
Falls libpam verwendet wird gibt es da auch einige Mechanismen siehe alles auch Debian Reference

An localhost/hostname gebundene Dienste können sicher sein, wenn das Umfeld stimmt also DNS Rebind Angriffe/schädliche Seiten im Browser per Plugins verhindert / gefiltert werden.
siehe Transmission CVE-2018-5702

Hadoop-, ActiveMQ- und Redis-Servern, zudem werden Brute-Force-Attacken auf verschiedenste Dienste ausgeführt.

Standard-Passwörter in Datenbank die offen im Internet hängen oder eben Standard-Passwörter von Linux-VM-Images bei denen kein Nutzer die Dokumentation liest, sondern erst probiert ob es überhaupt läuft.
Im IPv4 Raum ist ein einfacher Scan des kompletten Internets kein Problem mehr. siehe 30C3 Vortrag

 

[Elmario]

Habe mal eine ganz allgemeine Frage:
Wie handhabt ihr das mit den Build-Tools auf eurem Linux-System?
Bei mir ist es so, dass ich so viele verschiedene Programme ausprobiere, dass das System nach wenigen Monaten schon völlig zugemüllt ist.
Nun kann ich zwar dann immer noch einigermaßen nachvollziehen, welche Tools ich gebaut habe und nicht mehr brauche, und diese dann deinstalliere/löschen.
Aber wie ist es mit den teilweise massenhaften Requirements, dich ich davor installiert habe um das jeweilige Tool bauen zu können?
Da sammeln sich ja immer mehr Frameworks, APIs und Gedönse, bis es irgendwann auch noch zu Paketproblemen kommt, häufig wahrscheinlich wegen Entwicklungstools die ich längst nicht mehr brauche.
Was wäre die Lösung das System dauerhaft (oder wenigstens längerfristig( sauber zu halten?
Klar könnte man eine VM aufmachen und dort Alles bauen, aber das wäre ja auch ziemlich aufwendig und nervig, dann jedes Mal wenn man dort etwas gebaut hat danach noch den Build selbst und die für die Runtime nötigen Abhängigkeiten rüber kopieren zu müssen.
Gibt's da etwas Besseres. Vielleicht so in der Art wie diverse (Un)install-Recorde runter Windows, oder Sandboxie?

 

[Dani2070]

Ich hab das ne zeitlang mit chroot gemacht.

 

[Fallwrrk]

Naja, am Besten genau das machen, was einem jede Distri vorschlägt: Ausschließlich den Systempaketmanager für Systemprogramme benutzen. Wenn du wirklich mal selber was kompilieren musst, dann immer nach /usr/local installieren, dafür ist das Verzeichnis gedacht. So kannst du einfach alles in /usr/local löschen und gut is.

 

[flxmmr]

Scheinbar verstehst du was Anderes unter Skalierung als ich. Bei mir haben sich, ich habe es ausprobiert, manche Elemente nicht mitskaliert, sondern blieben auf der Originalgröße. Besonders non-Xfce-Programme, die noch GTK+2 nutzen, wie GIMP, verändern ausschließlich die Schriftgröße und Icons. Und wenn du einfach mal nach "Xfce Scaling" googelst, wirst du merken, dass das kein Einzelfall ist.

Hmm, was soll denn in GIMP noch skalieren? Und inwiefern hilft da ein GTK3-Desktop?

- - - Updated - - -

Da sammeln sich ja immer mehr Frameworks, APIs und Gedönse, bis es irgendwann auch noch zu Paketproblemen kommt, häufig wahrscheinlich wegen Entwicklungstools die ich längst nicht mehr brauche.
Was wäre die Lösung das System dauerhaft (oder wenigstens längerfristig( sauber zu halten?
Klar könnte man eine VM aufmachen und dort Alles bauen, aber das wäre ja auch ziemlich aufwendig und nervig, dann jedes Mal wenn man dort etwas gebaut hat danach noch den Build selbst und die für die Runtime nötigen Abhängigkeiten rüber kopieren zu müssen.
Gibt's da etwas Besseres. Vielleicht so in der Art wie diverse (Un)install-Recorde runter Windows, oder Sandboxie?

Einfach alles, was nicht beim Paketmanager der Distro dabei ist, in selbstdefinierte Verzeichnisse kompilieren/packen. Ansonsten Docker, wenn du Lust an den Dockerfiles hast. Oder ein chroot. Oder ein extra-Nutzer. Oder spack/easybuild, falls du wissenschaftliche Applikationen willst. Sonst vllt. mal nix-pkg anschauen.

Der Ansatz in der VM ist richtigerweise, die Software zu paketieren, dann braucht dein System bspw. nicht die Headerfiles. Was du damit sparst, weiß ich nicht?

 

[Elmario]

Danke schon Mal für eure Vorschläge.
Einfach nur das machen was die Distri vorschlägt; damit komme ich leider nicht aus. Ich muss eigentlich ständig irgendetwas selbst bauen, weil ich häufig spezielle Features benötige, die z.B. im Repo-VLC nicht enthalten sind, oder um z.B. ein XUM1541 für den Datentransfer zu einer Commodore 1541 Floppy zu erreichen, oder spezielle Codecs zu komprimieren usw.

Es geht mir bei dem entstehenden Chaos aber nicht um die Builds die am Ende heraus kommen, denn die habe ich ja an einem Ort (/opt), wo ich sie leicht entfernen kann. Aber für die jeweiligen Builds benötigen Vorbereitungen machen den "Müll" aus.
Damit meine ich den Buildvorgang, wie ihn wohl jeder Linuxnutzer schon oft genug erlebt hat:

-Sources herunterladen, dann z.B. configure ausführen und es werden diverse Tools abgefragt und beim Fehlen der selben der configure Vorgang abgebrochen.
-Also einige Pakete installiert, nur um dieses configure Skript zufrieden zu stellen.
-aber configure will immer noch nicht, denn es gibt noch Abhängigkeiten, die nicht mal in den Repos vorhanden sind.
-also werden diese Abhängigkeiten so nebenbei noch herunter geladen und schnell gebaut. Wenn das endlich soweit klappt kommt der make..
-und auch der make meckert wieder, über irgendwelche fehlenden Header Files. Also noch schnell einige *-dev Pakete installiert

Und schon ist eine ganze Menge Gedönse auf dem System, das ich danach vielleicht nie wieder brauche. Am besten fände ich es ein komfortables Tool wie Timeshift dafür nutzen zu können, aber das würde ja auch Alles was in der Zwischenzeit auf dem System geändert wurde rückabwickeln.

Ich werde mir die Option mit chroot mal durch den Kopf gehen lassen. Könnt wohl die schlankeste Option sein um das Problem zu umgehen. Nur bleibt dann natürlich wieder die Frage, wie man die zur Laufzeit nötigen Abhängigkeiten möglichst einfach auf den Host bekommt.
Was haltet ihr von der Idee in einer chroot Folder zu bauen und die darin installierten Abhängigkeiten per symlink auf dem Host verfügbar zu machen? Dann könnte man pro Build quasi eine chroot Folder haben, und bei "Nichtmehrbedarf" einfach die jeweilige Folger löschen. Ich denke das liefe dann in etwa auf die Funktionsweise von Sandboxie unter Windows hinaus.


Pakete paketieren in einer VM wäre mir, fürchte ich, auf Dauer ich leider zu aufwendig.

 

[Fallwrrk]

Klingt so n bisschen nach einem Fall für Arch Linux.

 

[fax668]

Bisher habe ich für die extremen Problemfälle extra Benutzer angelegt und die Software nur in das Benutzerverzeichnis installiert. So wird man die wenigstens problemlos wieder los und hat nicht allzu viel Arbeit. Sauberer wäre es allerdings, sich z.B. ein Flatpak zu bauen: Flatpak—the future of application distribution. Je nach Distro gibt es auch noch konkurrierende Ansätze, z.B. Snaps bei Ubuntu. Bei diesen Tools werden auch alle Abhängigkeiten mitgebaut und eingepackt. Falls es ein Service statt einem Desktopprogramm sein soll, dann bietet sich eher LXC/LXD/Docker an.

 

[Fallwrrk]

Docker ist da wirklich der mit Abstand einfachste Ansatz, inkl. Garantie nichts auf dem System liegen zulassen.

FROM ubuntu:18.04
WORKDIR /root
RUN apt-get update && apt-get install -y build-essentials git
RUN git clone https://github.com/foo/bar.git
WORKDIR bar
RUN ./configure && make && make install
ENTRYPOINT ["/usr/local/bin/bar"]

docker build -t foo/bar:latest .
docker run --rm -it foo/bar:latest

 

[Elmario]

Und können diese Docker-Container auch auf Hardwareresourcen (z.B. VDPAU) zugreifen, gibt es da Einschränkungen oder CPU-Overhead?

 

[Fallwrrk]

CPU-Overhead praktisch Null, Hardwareressourcen musst du den Container freigeben. Docker ist, vereinfacht gesagt, nur ein Wrapper um Chroot und Linux Cgroups. Alles, was nativ geht, geht auch in Docker. Schau dir mal RancherOS an. Das benutzt Docker als Init-System. Jede Systemkomponente (bzw. eine Gruppierung aus Systemkomponenten) läuft in einem Docker-Container.

 

[flxmmr]

-Sources herunterladen, dann z.B. configure ausführen und es werden diverse Tools abgefragt und beim Fehlen der selben der configure Vorgang abgebrochen.
-Also einige Pakete installiert, nur um dieses configure Skript zufrieden zu stellen.

So ist das halt? Was stört dich denn an den Paketen (außer der Tatsache, dass es Schadsoftware u.U. leichter hat)?

-aber configure will immer noch nicht, denn es gibt noch Abhängigkeiten, die nicht mal in den Repos vorhanden sind.

Ist doch kein Problem, die meisten autobuild-configure-Skripte bieten doch für diese Fälle meist die Option, den Pfad zu verlinken. Und wenn man die ganzen libs als extra-User/in User-Verzeichnisse kompiliert, geht dabei das System nicht kaputt.

-also werden diese Abhängigkeiten so nebenbei noch herunter geladen und schnell gebaut. Wenn das endlich soweit klappt kommt der make..
-und auch der make meckert wieder, über irgendwelche fehlenden Header Files. Also noch schnell einige *-dev Pakete installiert

Nochmal, du willst Software aus der Quelle installieren, da ist das nunmal so...

Und schon ist eine ganze Menge Gedönse auf dem System, das ich danach vielleicht nie wieder brauche. Am besten fände ich es ein komfortables Tool wie Timeshift dafür nutzen zu können, aber das würde ja auch Alles was in der Zwischenzeit auf dem System geändert wurde rückabwickeln.

Wenn du die Software immer aktuell brauchst, wirst du das regelmäßig wieder brauchen? Und selbst wenn nicht: wieviel Speicherplatz braucht das denn?

Ich werde mir die Option mit chroot mal durch den Kopf gehen lassen. Könnt wohl die schlankeste Option sein um das Problem zu umgehen. Nur bleibt dann natürlich wieder die Frage, wie man die zur Laufzeit nötigen Abhängigkeiten möglichst einfach auf den Host bekommt.

Solange die Abhängigkeiten im Paketmanager sind, musst du da ja nur die entsprechenden Pakete installieren. Das ist allerdings warum auch immer ein Problem für dich, allerdings kommst du da auch nicht drum rum, wenn du dir das Programm aus der Distribution installierst. Oder du baust statische Binaries (die laufen dann ewig).

Was haltet ihr von der Idee in einer chroot Folder zu bauen und die darin installierten Abhängigkeiten per symlink auf dem Host verfügbar zu machen? Dann könnte man pro Build quasi eine chroot Folder haben, und bei "Nichtmehrbedarf" einfach die jeweilige Folger löschen. Ich denke das liefe dann in etwa auf die Funktionsweise von Sandboxie unter Windows hinaus.

Sehr wenig. Mit solchen Dingen macht man sich sein System kaputt.

Pakete paketieren in einer VM wäre mir, fürchte ich, auf Dauer ich leider zu aufwendig.

Ja. Ist aber die einzige wirklich saubere Lösung. die ganze Zeit den chroot platt zu machen und dort alles reinzuinstallieren ist auch etwas Bananen. Ich würde mir nochmal sehr genau Nix: The Purely Functional Package Manager und GNU's advanced distro and transactional package manager — GuixSD anschauen (oder spack.io). Praktisch ist das jeweils ein Tool, das du installieren musst, dann musst du noch 2,3 Umgebungsvariablen setzen und du kannst jederzeit einen Reset machen. Vmtl. musst du aber die Build-Konfigurationen anpassen (und dich etwas einlesen).

Klingt so n bisschen nach einem Fall für Arch Linux.

Da er aus irgendwelchen Gründen keine Support-Software installieren will, ändert sich da nix .

Bisher habe ich für die extremen Problemfälle extra Benutzer angelegt und die Software nur in das Benutzerverzeichnis installiert. So wird man die wenigstens problemlos wieder los und hat nicht allzu viel Arbeit. Sauberer wäre es allerdings, sich z.B. ein Flatpak zu bauen: Flatpak—the future of application distribution. Je nach Distro gibt es auch noch konkurrierende Ansätze, z.B. Snaps bei Ubuntu. Bei diesen Tools werden auch alle Abhängigkeiten mitgebaut und eingepackt. Falls es ein Service statt einem Desktopprogramm sein soll, dann bietet sich eher LXC/LXD/Docker an.

Aber da muss man überall soviel installieren, um die Software zu kompilieren...

 

[Elmario]

Ich weiß nicht was du damit meinst, dass ich keine Support-Software installieren möchte.
Weshalb ich nicht alles aus Paketen installiere? Weil ich andauernd Dinge brauche die nicht in den Repos vorhanden sind und auch nicht als Pakete existieren.
Wie viel dieser ganze Kram zusammen ausmacht weiß ich ja eben deshalb nicht, weil es schon nach ein paar Monaten völlig außer Kontrolle gerät und gefühlt tausende von überflüssigen Files wild auf dem System verteilt sind; vor Allem in root. Irgendwann gibt es dann noch Probleme mit der Paketverwaltung, wie "XXX Kann nicht installiert werden weil...","XXX soll nicht installiert werden","XXX ist schon installiert, aber ...","XXX ist installiert in der falschen Version" usw.

 

[Gelöschtes Mitglied 144635]

@Elmario
Nutzt du Arch? Wenn etwas exotischeres nicht in offiziellen Repos ist, ist es wahrscheinlich im AUR. Ansonsten könnte vielleicht noch Frequently Asked Questions | Qubes OS eine Möglichkeit sein. Oder Docker wie Fallwrk nannte.

 

[flxmmr]

Naja, die -dev Paket stören dich ja auch . Und prinzipiell sollten die meisten autotools-Packages eigentlich auch eine "--prefix"-configure-Option anbieten. Da gibst du dann einfach beispielsweise "--prefix /home/deinuser/customsoftware" an und mit "make install" installierst du dann die Software/Bibliotheken dort in die typische "/usr, /lib, /bin, /share, /man"-Hierarchie. Und ein "make install" woanders hin, als nach /opt oder ins Homeverzeichnis wird über kurz oder lang zu Problemen führen, das macht man einfach nicht mehr. Damit deine anderen configure-Skripte dann die include-files und eigentlichen Bibliotheken finden: LIBDIR=/home/deinuser/customsoftware/lib,INCLUDEDIR ebenso oder den pkg-config-Pfad anpassen. Theoretisch kannst du das dann noch für Anwendungen mit div. Versionen in den Foldern customsoftware1/customsoftware2 machen und hast schön alles getrennt. Einziger Nachteil: meist mögen die Anwendungen das Umziehen deines Homeverzeichnisses nicht (kann man aber imho mit rpath auch lösen).

 

[Dani2070]

Kurz zu Nix: Die Grundidee ist genial. Es funktioniert tatsächlich in den allermeisten Fällen, aber Nix ist recht einsteigerunfreundlich und benötigt Einarbeitungszeit bis man da durchgestiegen ist.

 

[Elmario]

Nein, bisher bin ich noch bei Xubuntu 18.04. Arch wollte ich mir irgendwann mal anschauen, vielleicht aber vorher auch Gentoo. NixOS werde ich mir mal anschauen.

Also kann man Alles was mit make gebaut wird in ein beliebiges Verzeichnis installieren? Und die entsprechenden libs sind dann im selben Verzeichnis, Unterordner lib?
Oder geht das nur bei jenen Sources die automake unterstützen?

 

[flxmmr]

Die Prefix-Option ist so ähnlich auch bei anderen Autobuild-Tools vorhanden (z.B. cMake). Die GNU-Autotools-configure-scripts, die mir bisher untergekommen sind, unterstützen es jedenfalls fast alle. Und welche Software, die du so brauchst, nutzt kein solches Tool :?

 

[Elmario]

Von den Autotools stammen doch die Sources, wo dann ein configure.ac dabei ist usw. oder?

Die meisten Sources dir mir bisher unter kamen haben nur ein configure und ein make File dabei.

Ich mache dann bisher einfach nur :
./configure
make
sudo make install

Bei manchen kann man im configure File oder über einen Parameter für configure angeben, wo sie hin installiert werden sollen...

 

[theoradicus]

Von den Autotools stammen doch die Sources, wo dann ein configure.ac dabei ist usw. oder?

Ja.

Gentoo kompiliert immer alle Software-Pakete.

Bei Arch-Linux gibt es normale Pakete und ein Community-Projekt: AUR welches für Pakete aus Quellen kompilieren kann.

Bei Linux hat sich für die Benutzerfreundlichkeit und den Speicherverbrauch eben eingebürgert, dass die Distributionen modulare Pakete haben: Binäre Pakete -- Quellcode (-src) + Header (-dev) + Debug (-dbgsym) Pakete brauchen Nutzer normalerweise nicht. Genauso werden nicht alle Sprachvarianten oder Schriftarten installiert.

Der "Müll" im System kann zunehmen, weil die Flatpack/AppImage ... Verwaltung nicht zaubert und eigene Versionen installiert. Anstelle die "System" Lib zu nutzen, werden ganz andere Versionen benutzt, die vlt. Sicherheitslücken haben. Das Einrichten von handbrake als FlatpackApp brauchte bei Arch auch erstmal ~300MB irgendwelcher Abhängigkeiten.
Docker kann sich irgendwoher die Abhängigkeiten besorgen und es gab genug Sicherheitslücken in dem Bereich.

 

[Elmario]

Wie kann ich denn erkennen ob und bei welchen Sourcen ich wie von flxmmr beschrieben vorgehen kann?

 

[flxmmr]

du schaust, im zugehörigen README/Installationsanleitung nach. Ansonsten: configure --help

 

[Gelöschtes Mitglied 144635]

Um den Administrationsaufwand für Linux-Rechner zu minimieren, möchte ich Unattended Upgrades ermöglichen. Die Schritte habe ich wie in diesem guide befolgt: Konfiguration › Aktualisierungen › Wiki › ubuntuusers.de
Auch einfache Nutzer können Updates ohne Admin-PW installieren, außer z. B. Kernel-Updates. Problem ist aber, dass unattended Upgrades nicht funktionieren (1-Tages Intervalle eingestellt) und man nach wie vor manuell updaten muss. Die Nutzer arbeiten natürlich auf Standard-Benutzerkonten (nicht in wheel/sudo-Gruppe).

Führt jemand von euch automatische Updates aus? Könnte vielleicht Manjaro besser bei automatischen Updates funktionieren oder ist da auch immer "sudo pacman -Syu" wie unter Arch nötig?

 

[Dani2070]

Ich habe mit den automatischen Updates unter Ubuntu noch keine Probleme gehabt. Einfach das Paket installiert und das wars. Aber ich habe mich auch nicht darum gekümmert das andere Nutzer selber Updates installieren können.

 

[Gelöschtes Mitglied 144635]

Ich habe mit den automatischen Updates unter Ubuntu noch keine Probleme gehabt. Einfach das Paket installiert und das wars. Aber ich habe mich auch nicht darum gekümmert das andere Nutzer selber Updates installieren können.

Bist du als sudo-User nur aktiv oder mit normalo?

 

[Dani2070]

Nee ganz normaler User.
Die Updates laufen unabhängig vom gerade angemeldeten Nutzer über systemd im Hintergrund.

 

[jdl]

Nachdem meine T2 Tastatur angekommen ist, habe ich das Problem wie ich auf die höheren Ebenen der Tastaturbelegung mit der T3 Keymap von Linux zugreifen kann. AltGr+^ oder AltGr+d funktioniert nicht, sondern liefert die dort belegten Symbole direkt. Weiß jemand wie man auf höheren Ebenenen (T3 definiert bis zu acht Belegungen pro Taste) zugreifen kann?