Newsgroup: it.comp.os.linux.sys
Titolo: Aggiornare Openssh

ciao,
ho un server redhat 7.2 con openssh 3.1
se tento di upgradare openssh con RPM mi dice che servono glibc piů
recenti:
rpm -Uvh --test openssh-3.7.1p1-1.i386.rpm 
error: failed dependencies:
        libc.so.6(GLIBC_2.3)   is needed by openssh-3.7.1p1-1
        libcrypto.so.4   is needed by openssh-3.7.1p1-1
        openssh = 3.1p1-14 is needed by openssh-clients-3.1p1-14
        openssh = 3.1p1-14 is needed by openssh-server-3.1p1-14
qual'č la procedura migliore per aggiornare su un server cosě vecchio?
Non potendo attualmente rifare da zero la macchina, cosa fareste per
aggiornarla ora che la red-hat non da piů aggiornamenti?
Grazie
Paolo
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it



scusate il doppio post, mi è scappato un refresh...


 
Se ti fidi puoi usare la versione  legacy degli update :
http://download.fedoralegacy.org/redhat/7.2/
Luca
-- 
<<>><<>><<>><<>><<>><<>><<<>><<>><<>><<
Luca Paredi
Computing technical supporter              
Universita' degli Studi dell'Insubria  
<<>><<>><<>><<>><<>><<>><<<>><<>><<>><<

 
http://download.fedoralegacy.org/redhat/7.2/
Grazie della risposta,
1) tu ti fideresti?
2) forse non ho capito in cosa consiste , di openssh c'è la stessa
versione che ho io :
http://download.fedoralegacy.org/redhat/7.2/updates/i386/openssh-3.1p1-14.i386.rpm
grazie
ciao


 
Ciao


 un paio di trucchetti.
ehh ragazzi !
Per quanto detto sopra, io uso debian!!
(scusate ma non è una guerra di religione, ma una constatazione che certe
distribuzioni per fare da server sono proprio poco adatte !!)
Max

 distribuzioni per fare da server sono proprio poco adatte !!)
ti riferisci al fatto che RH a smesso gli update o che se avessi una
debian vecchia non avrei problemi ad aggiornare le glibc?
Ciao


 Scaricare rpm sorgenti e modificare eventualmente il .spec, direi.
e così posso aggirare il problema glibc? 
che tipo di modifiche al .spec sono necessarie, tanto per avere un'idea
della difficoltà.
grazie


 critiche come glibc.
Ho sempre visto che viene sconsigliato di aggiornare le glibc (almeno su
RH / MDK) perchč molti software installati possono non andare piů.
Questo sistema evita tutto ciň ?
grazie molte per il suggerimento.


 debian vecchia non avrei problemi ad aggiornare le glibc?
non esistono debian vecchie.
Quando esce una nuova versione la puoi upgradare online direttamente alla
nuova.
Se escono vulnerabilità aggiornano il pacchetto in automatico e ti basta un
comando per installare la versione nuova.
max

 
Se sono linkati staticamente e cambi la versione della glibc gli fai una
cippa al programma il problema sono gli eseguibile dinamici e t'assicuro
che fanno dei grossi casini, fa casini ad esempio anche cambiare  la
semplice ottimizzazione (da i686 a i386).


 comando per installare la versione nuova.
io in una Mandrake ho provato a upgradare le glibc via rpm , ha funzionato
quasi tutto ma per esempio lo stesso rpm mi andava in segmentation fault e
chissà cos'altro che non ho notato.
tra le varie distribuzioni varia il modo in cui sono linkate le librerie
nei pacchetti per cui Debian non da problemi in major upgrades quali le
glibc?
in questo post per esempio dicono che su RH pure con apt-get hanno avuto
gli stessi problemi e che alla fine hanno dovuto reinstallare le vecchie
glibc:
http://www.linuxquestions.org/questions/archive/5/2003/05/4/57607
Dicono di upgradare le glibc solo per problemi di sicurezza delle stesse,
ma se un software necessita di una versione più recente come nel mio caso?


 
Puoi installare due versioni delle glibc o meglio una ( qeella di sistema) e
la versione che ti occorre ( tipo in /usr/local/lib) e usara le variabile
LD_LIBRARY_PAT per indircare al sistema di prendere o la prima o la
seconda. Se invece linki statici in fase di link dai il corretto
-L/usr/local/lib -lc.


 variabile LD_LIBRARY_PAT per indircare al sistema di prendere o la prima o
                   ^^^^^^^^^^^^^^^^
        LD_LIBRARY_PATH :)


         LD_LIBRARY_PATH :)
grazie ancora.
Ma se provo il SRPM o direttamente il tgz sorgente ho bisogno lo stesso
delle glib nuove?
Grazie


 
Essi' magari compila anche ma potrebbero esserci delle funzioni vulnerabili.


> Ma se provo il SRPM o direttamente il tgz sorgente
                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
secondo me usare il tgz sorgente (non il srpm) e' la cosa piu' banale;
magari per sicurezza e per non rovinare il pacchetto esistente, installalo
in un'altra directory (lanciando configure specificando --prefix). Se poi ti
sembra tutto a posto e ne hai voglia puoi reinstallarlo nelle directory di
default. Magari prima di fare questa operazione e' preferibile disinstallare
la vecchia versione.
PS
Non sono propriamente un sistemista... ma c'e' qualche motivo perche' questa
opzione e' uscita solo dopo numerosi post ? In fondo mi sembra la piu'
logica... forse e' scontato che su un server di produzione non ci sia un
compilatore ?
saluti
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 compilatore ?
il fatto č che non sapevo se il tgz mi avrebbe richiesto le glibc
aggiornate.
poi siccome opero da remoto in ssh dovrei fare partire il nuovo su
un'altra porta e poi fermare il vecchio ssh ... etc mi sembrava piů
macchinoso.
saluti.


 
Puoi sempre far partire sshd con -p 5678, così non rompe alla vecchia 
(ma funzionante) installazione
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
	Prima di parlare collegare la spina del cervello,
	 leggere e in caso di schermata blu riavviare.