libc.so.6 nodig: teveel werk?

[MisterData]

Ik heb bij een hostingbedrijf een RedHat 6.2 webserver staan. Ik wil er Tomcat opzetten (een webserver voor Java-servlets die in Java is geschreven), waarvoor dus ook een Java VM nodig is. Die probeerde ik te installeren, maar ik kreeg de volgende melding:

Error loading: /lib/libc.so.6: version `GLIBC_2.2' not found (required by /opt/IBMJava2-142/jre/bin/classic/libjvm.so)

(hier gebruik ik toevallig de IBM-variant, maar ook 1.4 en 1.5 van Sun geven een dergelijk probleem)

Kan kloppen, RH6.2 is redelijk oud natuurlijk. Ik mailde mijn hoster dus met de vraag of ze voor mij libc.so.6 en de daarbij horende onderdelen erop zouden kunnen installeren of dat ik dat zelf zou kunnen doen. Nu geeft mijn hostingbedrijf echter het volgende antwoord:

Dit is niet zomaar mogelijk.
Dit heeft inpack op het gehele systeem.
Er moet zeer veel gerecompiled worden.
Ik kan u niet aanraden dit te gaan doen.
U kunt het best opzoek gaan naar java die gecompiled is voor een iets oudere versie van libc libc.so.5

en

er zijn wel een aantal dingen die opnieuw moeten worden gecompiled
alsin postfix, database server , webserver.

Los van dat de laatste Java versie die ik heb gezien die geen libc.so.6 nodig had ergens in de 1.3 zit (veel te oud dus), klinkt het voor mij een beetje ongeloofwaardig. Is het écht zoveel werk? Is het niet op een andere manier mogelijk om het werkend te krijgen met een recente versie van Java?

Voorzover ik weet is het zelf compilen van Java overigens niet echt mogelijk (geen open-source)?

[dajappie]

MisterData schreef op maandag 21 februari 2005 @ 17:36:
[...]
Los van dat de laatste Java versie die ik heb gezien die geen libc.so.6 nodig had ergens in de 1.3 zit (veel te oud dus), klinkt het voor mij een beetje ongeloofwaardig. Is het écht zoveel werk? Is het niet op een andere manier mogelijk om het werkend te krijgen met een recente versie van Java?

Libc is de C-library waar het overgrote deel van de programmatuur op de webserver draait. Overstappen naar een nieuwere GLIBC kan aardig wat voeten in de aarde hebben, zeker als er handmatige gecompileerde programma's draaien die 'breken' omdat de nieuwere versie net iets anders werkt. Dus zeker niet ongeloofwaardig en waarschijnlijk pech als je geen JRE kan vinden voor libc.so.5.

[Wilke]

Ja dat is echt zoveel werk, degene die dit schrijft heeft gelijk en ook zijn suggestie is het enige wat ik in zo'n geval zou zeggen (afgezien van 'upgrade die bak uberhaupt eens een keer in zijn geheel').

RH6.2 release date is 8 maart 2000. Tsja, dat is bijna 5 jaar geleden.

[Sendy]

Toch lijkt 't me mogelijk om met de dynamische linker voor alleen Tomcat een andere libc te gebruiken. Misschien moet je dan de jre patchen dat-ie een andere naam (voor de libc) gebruikt (en libc6 installeren onder die andere naam) maar dat is allicht minder werk dan upgraden/de hele boel hercompileren.

Ik kan me niet voorstellen dat je hoster dit voor jou wil doen, maar als je root bent op die bak dan kan je dit zelf eens proberen.

[MisterData]

Sendy schreef op maandag 21 februari 2005 @ 18:12:
Toch lijkt 't me mogelijk om met de dynamische linker voor alleen Tomcat een andere libc te gebruiken. Misschien moet je dan de jre patchen dat-ie een andere naam (voor de libc) gebruikt (en libc6 installeren onder die andere naam) maar dat is allicht minder werk dan upgraden/de hele boel hercompileren.

Ik kan me niet voorstellen dat je hoster dit voor jou wil doen, maar als je root bent op die bak dan kan je dit zelf eens proberen.

Ja, aan zoiets zat ik ook te denken... en ik ben root, dus in principe zou het kunnen (zij het dat ik geen idee heb hoe, suggesties?) maar waarom blijven de andere programma's niet gewoon libc.so.5 gebruiken als ik .6 erbij zet? Dat lijkt me toch iets van een versienummer ofzo...

[Bananenplant]

Als je root hebt... waarom dan niet upgraden? Naar wat ik weet gaat Tomcat er ook niet blij mee zijn, je applicaties gedwongen oude java laten gebruiken lijkt me ook niet ideaal.

Als je 'm kunt rooten is een chroot misschien een idee kun je 'm verkloten zonder dat de rest van het systeem eronder lijdt .

[MisterData]

ucchan schreef op maandag 21 februari 2005 @ 19:36:
Als je root hebt... waarom dan niet upgraden? Naar wat ik weet gaat Tomcat er ook niet blij mee zijn, je applicaties gedwongen oude java laten gebruiken lijkt me ook niet ideaal.

Als je 'm kunt rooten is een chroot misschien een idee kun je 'm verkloten zonder dat de rest van het systeem eronder lijdt .

Kun je me misschien kort uitleggen wat ik met chroot kan? Naar wat ik er van heb gehoord is het een soort manier om de 'root' van een applicatie in te stellen, waar hij beslist niet buiten kan komen (zodat je zegmaar een map 'Tomcat' hebt waarin je gewoon de gebruikelijke /etc mappen enzo hebt) Dan zou je dus libc6 in die chroot-omgeving kunnen zetten ofzo (moet ik het wel zelf gaan compileren zeker?)

[Sfynx]

inpack

anyway, mijn ervaring is dat een glibc update bij niet al te grote versieverschillen wel te doen is. Welke versie heb je nu? Om dat te zien gewoon even libc.so.6 zelf uitvoeren op de shell:

code:

/lib/libc.so.6

In theorie moet glibc backwards compatible zijn met vorige versies (sowieso in t geval van minor versies). Alle processen herstarten die van een geupdate library gebruik maken is wel handig... dit om te voorkomen dat eventuele nieuwe child processen van de nieuwe lib gebruik maken terwijl hun parent nog de oude gebruiken (heeft me al eens een falende FTP en webserver opgeleverd wegens adresconflicten in libdns, onderdeel van glibc). In het geval van glibc is een reboot dan wel het makkelijkst

Mochten de versies echt veel van elkaar verschillen, dan zou ik persoonlijk overwegen gewoon naar een wat nieuwerwetsere RH (of andere Linux, of BSD, etc ) over te stappen... het houdt een keertje op.

[ Voor 17% gewijzigd door Sfynx op 21-02-2005 20:09 ]

[MisterData]

Ik heb nu de volgende versie:

GNU C Library stable release version 2.1.3, by Roland McGrath et al.

En ik snap inderdaad ook niet waarom ze daar nog RedHat 6.2 draaien... zelf updaten van die bak kan volgens mij niet, het is een gehuurde dedicated server En daarnaast brengt dat weer zoveel ongein met zich mee waar ik helemaal geen zin in heb (dingen als mailserver een dag uit, alle dingen weer opnieuw configureren, etcetera) dus het liefst laat ik het ook gewoon zoals het is verder...

[Sfynx]

Hm tja... Iedereen gaat nu wel van versie 2.2.5 uit (deze wordt in debian stable (woody) nog steeds gebruikt). Je zou kunnen proberen die nieuwe glibc uit een rpm package teinstalleren als red hat die beschikbaar heeft, maar ik zal eerlijk gezegd niet weten of daarna alles nog werkt... ik ben niet erg bekend met de manier waarop software-installatie met het red hat package management precies gaat en of 2.2.5 100% backwards compatible is met 2.1.3.

Van de GNU-pagina:

If you are upgrading from libc5, you need to recompile every shared library on your system against the new library for the sake of new code, but keep the old libraries around for old binaries to use. This is complicated and difficult.

Je hebt al libc6, dus in theorie zou t niet hoeven...

[ Voor 27% gewijzigd door Sfynx op 21-02-2005 21:10 ]

[_JGC_]

Sfynx schreef op maandag 21 februari 2005 @ 21:05:
Hm tja... Iedereen gaat nu wel van versie 2.2.5 uit (deze wordt in debian stable (woody) nog steeds gebruikt). Je zou kunnen proberen die nieuwe glibc uit een rpm package teinstalleren als red hat die beschikbaar heeft, maar ik zal eerlijk gezegd niet weten of daarna alles nog werkt... ik ben niet erg bekend met de manier waarop software-installatie met het red hat package management precies gaat en of 2.2.5 100% backwards compatible is met 2.1.3.

Van de GNU-pagina:

[...]


Je hebt al libc6, dus in theorie zou t niet hoeven...

je .soname verandert, dus je mag sowieso recompilen in de meeste gevallen

Verder vraag ik me nog af wat je met Redhat 6.2 moet, zsm upgraden naar iets actuelers, 6.2 wordt al jaren niet meer ondersteund en is zo lek als een mandje.

[Bananenplant]

Een chroot is een alternatieve / . Ik weet niet hoe het met Redhat zit, maar bij debian kun je een hele installatie (exclusief kernel alleen ) bootstrappen in zo'n chroot en als je met chroot (commando: chroot /var/chroot/blaat als dat de root van je nieuwe directorystructuur is) naar die alternatieve / gaat voer je commando's uit alsof je een geheel nieuwe installatie draait. Als het kan met Redhat (of je stapt over op debian ) zou je dus alles alvast kunnen uitproberen (je kunt /var /home en /tmp enzo mounten, zijn wel howto's voor) in je nieuwe installatie terwijl de oude gewoon draait, kun je de services alvast configureren (op andere poorten tijdelijk) en zodra alles naar wens is kachel je naar je colo met een knoppix-cd en gebruik je die om de inhoud van je oude / weg te keilen en de inhoud van /var/chroot/blaat naar / te verplaatsen, net alsof je een linuxinstallatie naar een andere hd zou migreren. Daar zijn ook weer howto's voor .

Misschien is dit een wat lompe oplossing, maar zo kun je alles alvast gaan draaien terwijl je het oude systeem behoudt tot je tevreden bent met het nieuwe.

[ Voor 5% gewijzigd door Bananenplant op 22-02-2005 01:27 ]

[Sendy]

Zo'n chroot is inderdaad ook een idee. Maar als je mijn voorstel wil volgen dan moet je van alle libraries die de jre gebruikt een (nieuwe) versie in /lib kopieren met een nieuwe naam (neem de naam dan in ieder geval van de dezelfde lengte zodat je de naam makkelijk in de binary kan wijzigen).

Do dus als volgt:

code:

ldd jre-<iets>

Je krijg zoiets als uitvoer (maar dan met unresolved verwijzigen)

code:

sgr@jfr115:~$ ldd /bin/ls
        librt.so.1 => /lib/librt.so.1 (0x4001d000)
        libacl.so.1 => /lib/libacl.so.1 (0x4002f000)
        libc.so.6 => /lib/libc.so.6 (0x40036000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x40169000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
        libattr.so.1 => /lib/libattr.so.1 (0x401bb000)

Installeer dan de missende libraries (gecompileerd met de libraries op je huidige systeem). Als je conflicten krijgt (je moet een lib overschrijven) dan installeer je hem onder een andere naam. Pak dan vi in hex mode, en wijzig de gewijzigde naam keihard in de binary.

Als je compileerd op je huidige systeem dan hoef je niet alle afhankelijke libraries (ldd op een library) mee te compileren (althans, dat verwacht ik). Als dit niet werkt dan kan je nog proberen libc6 te bootstrappen(?) door eerst libc6 op een libc5 systeem te compileren, daarna die libc6 te installeren en opnieuw libc6 te compileren. Misschien moet je dit nog eenmaal herhalen, zodat alle libc5 code werkelijk uit de binary libc6 is.

Dit is ook best veel werk, maar als het moet dan moet het. Schroom niet door te vragen als dit niet lukt.

Wellicht is zo'n chroot makkelijker, misschien is een UML makkelijker. Dit ligt er allemaal maar aan waar de data vandaan komt.

[igmar]

MisterData schreef op maandag 21 februari 2005 @ 20:55:
En ik snap inderdaad ook niet waarom ze daar nog RedHat 6.2 draaien... zelf updaten van die bak kan volgens mij niet, het is een gehuurde dedicated server En daarnaast brengt dat weer zoveel ongein met zich mee waar ik helemaal geen zin in heb (dingen als mailserver een dag uit, alle dingen weer opnieuw configureren, etcetera) dus het liefst laat ik het ook gewoon zoals het is verder...

Van 2.1.3 -> 2.2 is geen probleem, aangezien ook de .so name niet veranderd in dat geval. Het *kan* echter ook fout gaan, maar ik heb inmiddels op 3 machines 2.1.3 -> 2.2 geupgrade zonder problemen.

[MisterData]

Nou als ik het zo hoor zijn het allemaal vrij lompe oplossingen (in een binair bestand met de hand dingen aanpassen...tsja ) en niet zonder risico. De chroot oplossing daarnaast is nogal veel werk als ik dat zo zie...

Oh, en ldd geeft het volgende:

/opt/IBMJava2-142/jre/bin>ldd java
libpthread.so.0 => /lib/libpthread.so.0 (0x40019000)
libnsl.so.1 => /lib/libnsl.so.1 (0x4002c000)
libdl.so.2 => /lib/libdl.so.2 (0x40042000)
libc.so.6 => /lib/libc.so.6 (0x40046000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

Als alleen libc.so.6 het probleem is dan moet dat redelijk aan de gang te krijgen zijn middels de 'binaire' oplossing hierboven. Het enige probleem is dat ik om libc te compileren ook nog eens nieuwe make en binutils moet installeren ouwe meuk allemaal hoor....

[Sfynx]

Een binary upgrade uit een package is niet mogelijk? Dat zou het snelste zijn en dan heb je geen development spullen nodig.

[igmar]

MisterData schreef op dinsdag 22 februari 2005 @ 18:03:
Als alleen libc.so.6 het probleem is dan moet dat redelijk aan de gang te krijgen zijn middels de 'binaire' oplossing hierboven. Het enige probleem is dat ik om libc te compileren ook nog eens nieuwe make en binutils moet installeren ouwe meuk allemaal hoor....

De functies in glibc zijn versioned, hetgeen betekend dat hacks met editors ed niet gaan werken. Ik zou eens overwegen om de libc van RedHat 7.1 er overheen te zetten, dat was een upgrade die hier vrij simpel ging.

[Sendy]

Als je de library onder een andere naam installeerd (i.p.v. libc.so.6 bijvoorbeel MDlc.so.6) dan kan er niets echt fout gaan (andere programma's gebruiken die library dan nooit). En een beetje hex-editing gaat niemand dood van Je sloopt hoogstens je java, maar goed die werkt toch al niet.

Ik weet alleen niet of je je Java-binary mag editten. De licentie voorwaarden sucken nogal; dat is ook Java's grote probleem.

Ingmar >
Waarom zouden hacks met een editor (want dat is het zeer zeker) niet gaan werken? Ik kan me hier niets bij voorstellen.

[ Voor 15% gewijzigd door Sendy op 23-02-2005 12:35 ]