cabriofahrer
Well-Known Member
Linux-Anwendungen verlangen immer nach glibc. Doch wie kann ich checken, welche Version der Linuxulator hat? Und wie heißt das betreffende Package überhaupt, oder ist das im Basissystem?
Wie kann ich die glibc-Version des Linuxulators checken?
- Ersteller cabriofahrer
- Erstellt am
Das Paket ist in deiner Linuxumgebung und heißt... glibc! Musst aber gucken ob in deiner Linuxumgebung ein Paketmanager dabei ist, normal ist das nicht der Fall. Die Datei heißt aber auch glibc*.
Also aus dem Basissystem ein find in den Pfad der Linuxumgebung nach "glibc*"
Oder wenn du in der Linuxumgebung bist geht auch ein ldd --version
Alternativ hilft auch die Suche nach Distribution + glibc + Version in google, wenn du das z.b. für rhel 7 machst (centos7 ist die default linux_base die du über pkg installieren kannst) ist dass der zweite Treffer.
Also aus dem Basissystem ein find in den Pfad der Linuxumgebung nach "glibc*"
Oder wenn du in der Linuxumgebung bist geht auch ein ldd --version
Alternativ hilft auch die Suche nach Distribution + glibc + Version in google, wenn du das z.b. für rhel 7 machst (centos7 ist die default linux_base die du über pkg installieren kannst) ist dass der zweite Treffer.
cabriofahrer
Well-Known Member
Wie komme ich denn in die Linuxumgebung?
1. Schritt: Handbuch lesen https://docs.freebsd.org/en/books/handbook/linuxemu/
cabriofahrer
Well-Known Member
So, hier:
Also haben wir Version 2.17.
Zum Hintergrund meiner Frage: Ich wollte auf gut Glück mal ein Linux-Spiel (Unvanquished) ausprobieren. Nach Entpacken der Datei bin ich dann in das betreffende Verzeichnis navigiert und habe versucht auszuführen:
Offenbar wird hier zunächst glibc 2.27 verlangt, also eine höhere Version. Dann sogar 3.4.22?
Die im defaultmäßigen Linuxulator vorhandene Version scheint also sehr veraltet zu sein.
Code:
$ su
Password:
# chroot /compat/linux/ /bin/bash
bash-4.2# uname -a
Linux amd64ex.local 4.4.0 FreeBSD 13.2-RELEASE releng/13.2-n254617-525ecfdad597 GENERIC x86_64 x86_64 x86_64 GNU/Linux
bash-4.2# ldd --version
ldd (GNU libc) 2.17
Copyright © 2012 Free Software Foundation, Inc.
Dies ist freie Software; in den Quellen befinden sich die Lizenzbedingungen.
Es gibt KEINERLEI Garantie; nicht einmal für die TAUGLICHKEIT oder
VERWENDBARKEIT FÜR EINEN ANGEGEBENEN ZWECK.
Implementiert von Roland McGrath und Ulrich Drepper.
bash-4.2#Also haben wir Version 2.17.
Zum Hintergrund meiner Frage: Ich wollte auf gut Glück mal ein Linux-Spiel (Unvanquished) ausprobieren. Nach Entpacken der Datei bin ich dann in das betreffende Verzeichnis navigiert und habe versucht auszuführen:
Code:
$ ./daemon
./daemon: /lib64/libm.so.6: version `GLIBC_2.27' not found (required by ./daemon)
./daemon: /lib64/libstdc++.so.6: version `CXXABI_1.3.8' not found (required by ./daemon)
./daemon: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.22' not found (required by ./daemon)
./daemon: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by ./daemon)
./daemon: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by ./daemon)
./daemon: /lib64/libstdc++.so.6: version `CXXABI_1.3.9' not found (required by ./daemon)Offenbar wird hier zunächst glibc 2.27 verlangt, also eine höhere Version. Dann sogar 3.4.22?
Die im defaultmäßigen Linuxulator vorhandene Version scheint also sehr veraltet zu sein.
In dem von @stadtkind verlinkten Handbuch Eintrag wird ja u.a. beschrieben wie du z.b. ein aktuelles Debian oder Ubuntu als Basis debootstrappen kannst. Im Internet findest du sicher auch noch einige andere Howtos. Es sei aber gesagt dass es hier wirklich um fortgeschrittenes geht wo du auch verstehen solltest wieso du was und wie tust, damit du zum Erfolg kommst.
GLIBCXX ist die Lib für c++
Es kann auch sein, dass das Spiel gar keine glibc>2.17 braucht, das Binary nur gegen eine solche compiliert wurde. Dann könntest du das Spiel aus dem Source bauen, aber auch das ist nichts für Anfänger
GLIBCXX ist die Lib für c++
Es kann auch sein, dass das Spiel gar keine glibc>2.17 braucht, das Binary nur gegen eine solche compiliert wurde. Dann könntest du das Spiel aus dem Source bauen, aber auch das ist nichts für Anfänger
cabriofahrer
Well-Known Member
Ist mir auch aufgefallen. Und da stellt sich mir gleich die Frage, ob das dann kompatibel mit dem linux-steam-utils ist und anderen Sachen, die mit dem Linuxulator gut laufen.
Interessant. Hier ist die Anleitung:
Compiling the source - Unvanquished
Wäre es also möglich, innerhalb der Linuxumgebung das Spiel zu kompilieren? Auffällig ist ja schon mal, dass CentOS nicht erwähnt ist...
BTW: Wenn Du kompilierst, dann versuch mal mit und ohne die Option "-U_FORTIFY_SOURCE" oder "-D_FORTIFY_SOURCE=0".
So auffällig ist das nicht, CentOS ist halt eher ein Server OS und nicht das woran man denkt wenn man unter Linux zocken möchte.
Auf deren Seite steht aber:
Code:
If you need to build the game to run it on an unsupported system (like a very old Linux distribution) or to distribute it in a software distribution, you only need to build the Dæmon engine. You may also want to build the Unvanquished game code if you want to make a mod.
You'll find more details about how to build the game or the engine on the wiki.Also möglich ist es vielleicht, aber ich hab sowas auch keine Erfahrung.
cabriofahrer
Well-Known Member
Was bewirkt diese Option und warum wäre es interessant, es mit, bzw. ohne diese auszuprobieren?
Mal eine andere Sache: In dem Handbook steht zur Ubuntu-Umgebung folgendes: "Once inside the chroot, the system behaves as per a normal Ubuntu installation." Was genau heißt das? Hat man da X oder nicht? Funktioniert der Paketmanager apt?
Ich frage, weil mit der CentOS Installation funktionieren zumindest die 3D-Anwendungen, wenn man die Pakete "linux-c7-dri" und "linux-c7-libdrm" installiert hat.
Hat hier jemand entsprechende Erfahrungen mit der Ubuntu-Umgebung?
Die Option bewirkt, dass bestimmte compile-time- und run-time-Checks nicht mehr gemacht werden.
Ich hatte Probleme mit binaries, auf Systemen mit unterschiedlicher glibc-Version.
Andy_m4
Well-Known Member
btw. weiß zufällig einer, ob da irgendwie mal was kommt in Richtung "CentOS 8" (oder wie auch immer dann der entsprechende Redhat-Klon heißt)?
Das käme auf einen Versuch an.
Generell gibts ja zwei Vorgehensweisen.
1.: man spricht das Xorg an, das auf FreeBSD läuft.
2.: man lässt einen Xorg innerhalb des Linux-Chroot laufen, der dann aber auch Zugriff auf devfs braucht (das laut Anleitung ja auch dort reinge"fstab"t wird)
apt wird ganz normal funktionieren. Das ist ja auch der Sinn bei einer full ubuntu-chroot.
Zuletzt bearbeitet:
cabriofahrer
Well-Known Member
Also das Problem mit der veralteten glibc-Version wird hier diskutiert und es wird u.a. Rocky Linux genannt, was wahrscheinlich das ist, was Du meinst:
Da es wohl offensichtlich ist, dass CentOS 7.x total veraltet ist, glaube ich, es wird wohl wenig Sinn machen, irgendwelche Linux-Spiele dafür speziell kompilieren zu wollen.
Vielleicht mache ich mal einen Versuch mit einer virtuellen FreeBSD-Maschine und der Ubuntu-Umgebung.
Andy_m4
Well-Known Member
Mich hatte es nur so allgemein interessiert ob da was angedacht ist. Außerhalb Deiner Fragestellung. Weil halt CentOS 7 schon arg alt ist. Kann ja sein, das jemand was gehört hat von den c7-Portmaintainern.
Auf der anderen Seite ist es ja im Grunde auch nicht allzu kompliziert ne Linux-Distribution zum laufen zu kriegen. Insofern ist da jetzt nicht unbedingt eine zwingende Notwendigkeit.
CentOS 7 ist nicht "total veraltet", es wird immer noch von Redhat, bzw. auch CentOS unterstützt und bekommt kritische Updates und Fixes. Nur mal zur Klarstellung...
CentOS 8 bzw. 9 gibt es so nicht mehr, das ist in CentOS Stream aufgegangen. Alternativen wären Rocky oder Alma OS. Denke letzteres wird sich eher als Standard etablieren.
CentOS 8 bzw. 9 gibt es so nicht mehr, das ist in CentOS Stream aufgegangen. Alternativen wären Rocky oder Alma OS. Denke letzteres wird sich eher als Standard etablieren.
Andy_m4
Well-Known Member
Ja. Mal gucken, ob das früher oder später dann auch noch für die Linux-Umgebung in die Ports wandert. Denn das ist ja ne recht unkomplizierte Möglichkeit Linux-Programme zum laufen zu kriegen.
Sorry, aber "es wird noch unterstützt" und "es bekommt noch Security-Updates" ist sehr genau meine definition von "Hoffnungslos veraltet" insb. im Linuxkontext.
Es ist maximal das "wohlgefühl" das die alte scheisse die man noch laufen lässt durch angeblich gutes zurückpatchen angeblich keine security-lücken hat und man sich entspannt zurück lehnen kann.
Es ist maximal das "wohlgefühl" das die alte scheisse die man noch laufen lässt durch angeblich gutes zurückpatchen angeblich keine security-lücken hat und man sich entspannt zurück lehnen kann.
Andy_m4
Well-Known Member
Wäre mal interessant zu wissen, ob die c7-Ports/Packages überhaupt im größeren Stil eingesetzt werden. Vereinzelt sicher schon, aber sonst könnte ich mir vorstellen das man häufiger auf ne ganze Linux-Jail (oder auch "chrooted" in /compat/) trifft.
Ja. Wobei es manchmal ganz angenehm ist, etwas Langzeitstabiles zu haben. Neues ist ja leider nicht immer automatisch besser und man tauscht alte (aber bekannte) Probleme durch Neue (vorwiegend noch unbekannte).
Wenn ein System die Anforderungen erfüllt, wieso sollte ich dann etwas daran ändern? Solange es Sicherheitsupdates gibt wird es eben nicht schlecht. Dein "angeblich" versteh ich auch nicht ganz, willst du in den Raum stellen, Firmen wie RedHat/IBM belügen ihre ganzen Kunden und erfüllen die Verträge nicht? Bei RedHat gibt es z.b. zu jedem CVE einen Bugzilla Eintrag, wo man sieht wann der auch für alte Versionen gefixed wurde.
Derzeit brauche ich die Linuxumgebung nicht, hatte früher aber durchaus bei ner Handvoll Systemen das im Einsatz, immer mit CentOS_Base6 oder 7. Lief auch immer, war halt immer auch Serverzeugs, da sind die Systeme ja gut unterstützt.
Weißt dus? Also ich meine wirklich im sinne "kontrolliert das jemand der den kompletten code kennt, den alten und den neuen, ob der backport des bugfixes wirklich effektiv ist?"
Bei den vielen hundert patches pro monat und teilweise viele viele jahre alte versionen von komplexer software?
Kann ich mir wirklich sicher sein das ein programmierer bei red hat irgend eine 4 Jahre alte Apache-Version, an deren entwicklung er "ursprünglich" vermutlich nicht beteiligt war, so gut kennt, das er weiß wen jetzt für den aktuellen eine Code-Änderung kommt er das sauber in den 4 Jahre alten, vom Projekt nicht mehr gepflegten Code einspielt? Und das für XXX komplexe Projekte.
Sorry, ich glaube das ist absolut okay für "Ich will meinen Chef zeigen das wir uns um security kümmern" - aber als "Ich bin mir persönlich sicher das dies immer perfekt umgesetzt ist" taugt es für mich als jemand der da zugegeben sehr fern ist, eher nicht.
In "meiner" Praxis bin ich immer fan davon "aktuelle" oder "mittelaktuelle" software zu verwenden, regelmäßig zu patchen und wenn etwas dabei "bricht" halt zu schauen woran es liegt. Das ist wenn ich zb nur den Apache oder samba oder whatever aktualisiere und da gibt es dann ein Problem eher unproblematisch.
Stehe ich aber nach 5 Jahren LTS oder sogar noch länger an XXX verschiede gleichzeitige Mega-Updates, wird es wahnsinnig schwer da die details noch rauszufinden.
Deshalb bedeutet aus meiner (kleineren) Praxis auch "LTS" oft "wir lassen selbst wenns keine updates mehr gibt weiterlaufen" weil
man nach 5 oder noch mehr jahren einfach nicht mehr updaten kann, ohne komplett von vorne zu beginnen, und im schlimmsten fall fehlt doku oder gar mitarbeiter die noch wissen was vor 5 jahren oder mehr mal gemacht worde.
Das umgehe ich auch mit "ich halte alles halbwegs aktuell" - weil dann muss man sich zwangsweise mit kleineren evolutionen beschäftigen und immer mal wieder schauen was das System eigentlich macht, wer verantwortlich ist etc.
Nein, natürlich weiß ich das nicht zu 100%. Das ist aber bei absolut jedem Packet das ist installiere so. Selbst wenn ich ein Script selbst geschrieben habe kann ich nicht davon ausgehen, dass es 100% Fehlerfrei ist (sollte ich definitiv nicht!).
Wie bei überall in der OS muss man etwas vertrauen haben. Die Leute bei RedHat sind jetzt nicht die unfähigsten, gerade bei großen Projekten wie Apache und Co haben die überalle ihre eigenen Maintainer drinnen.
Und ich bin auch nicht der einzige der das einsetzt. Man denke z.b. an die unzähligen US Behörden oder auch einfach Großkonzerne, ich denke da wird bei geschäftskritischen Dingen schon noch jemand drüber gucken.
Habe ich leider auch schon gesehen, aber ist nicht dass Problem von LTS sondern von den Leuten die es falsch nutzen
Ja privat bin ich da ganz bei dir, da gehe ich auch immer hurtig auf die neueste Hauptversion eines LTS, beruflich, mit 100 Servern ist das halt schon etwas anderes, erst recht, wenn Downtimes geplant, mit Kunden besprochen und abgenommen werden müssen.
Wie bei überall in der OS muss man etwas vertrauen haben. Die Leute bei RedHat sind jetzt nicht die unfähigsten, gerade bei großen Projekten wie Apache und Co haben die überalle ihre eigenen Maintainer drinnen.
Und ich bin auch nicht der einzige der das einsetzt. Man denke z.b. an die unzähligen US Behörden oder auch einfach Großkonzerne, ich denke da wird bei geschäftskritischen Dingen schon noch jemand drüber gucken.
Habe ich leider auch schon gesehen, aber ist nicht dass Problem von LTS sondern von den Leuten die es falsch nutzen
Ja privat bin ich da ganz bei dir, da gehe ich auch immer hurtig auf die neueste Hauptversion eines LTS, beruflich, mit 100 Servern ist das halt schon etwas anderes, erst recht, wenn Downtimes geplant, mit Kunden besprochen und abgenommen werden müssen.
Andy_m4
Well-Known Member
Ja. Wobei einige Projekte ja von sich aus schon Longterm-Releases anbieten, auf die man aufsetzen kann.
Um mal bei Apache zu bleiben: Da gabs ja auch lange nach dem erscheinen des 2er noch Updates für den 1.3
Oder beim 2.2er gabs noch Updates für den 2.0er.
Wie es aktuell ist, weiß ich nicht. Hab keinen Apache mehr im Einsatz. Gefühlt nimmt den ja keiner mehr, weil alle irgendwie sowas wie nginx gewechselt sind (wobei ich vermute, das Apache immer ca. ein Viertel aller Websites zum Einsatz kommt.
Finde es auch irgendwie witzig das wenn Du einerseits von aktueller Software sprichst dann andererseits für Deine Beispiele ein ein Urgestein wie Apache herhalten muss. :-)
Ansonsten zum Thema Backports schließe ich mich weitgehend meinem Vorredner an. Die Frage "wie gut wird etwas gemacht" ist halt wie alles eine Vertrauensfrage. Aber was die Komplexität angeht: Ja. Es finden auch Aufräumarbeiten statt und manchmal fliegen sogar Sachen raus, aber so mal über die Gesamtheit der Software geschaut nimmt die Komplexität von Software zu. Und DER Nährboden für Bugs ist nunmal Komplexität. Insofern haben ja Longterm-Versionen ja auch einen bewahrenden Charakter.
Sprich: Ich geb Dir das mal, das die Backports vielleicht nicht so gut sind. Aber im Gegenzug bekommst Du wenigstens kein signifikanten Komplexitätszuwachs. Es gibt also so für alles Pro und Contra Argumente.
Oder der Maintainer sogar selbst patcht. So wie Debian seinerzeit bei OpenSSL. Wo uninitialisierte Variablen gefunden wurden und dann vorsorglich die mal initialisiert haben, weil uninitialisierte Variablen sind ja grundsätzlich schlechter Stil und dabei übersehend, das das ein wesentlicher Teil der Entropie für die Krypto war. :-)
Solche Dinge passieren. Aber insgesamt funktioniert (auch das mit den Backports) i.d.R. gut. Zumindest ist mir noch nicht aufgefallen, das Software mit backported Krams überproportional von Sicherheitslücken und/oder Bugs betroffen ist.
Das ist halt immer die Frage. Macht man die kleinen Schritte so im Rolling-Release-Stil mit und hat dafür auch höchstens bei jedem Update kleine Probleme oder fährt man eher ein längeren Releasezyklus. Aber man muss sich ja nicht fest für eines Entscheiden und das gnadenlos durchziehen. Man kann ja auch nach den Anforderungen entsprechend agieren. Wenn man irgendeine alte Hardware (Drucker, whatever) hat die eh kein ultralanges Leben mehr vor sich hat und wo es mit Treibern Probleme mit neueren Kernels gibt, da wird man eher auf Longterm setzen. Man wird das voraussichtlich eh nie majorupgraden müssen und neuere Versionen bergen ein enormes Risiko, das es nicht mehr funktioniert. Da werde ich also vermutlich eher nicht immer den neusten Versionen "nachrollen".
Ja. Das ist ne Todsünde. Dagegen ist alles andere so ziemlich irrelevant. Dann ist DAS dein Problem. Und nicht ob jemand Longterm oder nen follow-mainline-upstream macht.
Die werden vor allem darauf achten, das ihre eigenen "Sicherheits"-patches nicht rausfliegen. :-)