Je te conseille ce rpm car les modules ne devaient pas s'installer du fait que le paquet était prévu pour une RHEL 4 update 4, kernel 2.6.9-42 .
Hors tu es manifestement dans une RHEL 4 de niveau inférieur, avec un kernel 2.6.9-22.
Donc tu regardes ta version exacte dans :
/etc/redhat-release
et tu installes le rpm approprié pour l'architecture x86 ou x86_64.
Je n'ai jamais installé de lecteur de bande sous Linux, il faudra que tu regardes sur le Net s'il est nécessaire de lui installer un driver..
Les erreurs que tu as eu à l'installation de ton rpm me paraissent inquiétantes.
Redémarre sur ton noyau antérieur à l'installation du rpm, assures toi que les entrées dans le modprobe.conf concernant la carte sont enlevées, et réinstalles le driver.
Tu as essayé de "réactiver" tes 2 autres interfaces dans /etc/modprobe.conf ? Et tu crées un fichier ifcfg-eth1 et un autre ifcfg-eth3, en mettant seulement les lignes ONBOOT=yes et leur adresse MAC (HWADDR) ?
Essaies peut-être aussi d'enlever la directive HWADDR= de tous les fichiers ifcfg-eth* .
-> Le but étant que ip link list te nomme correctement toutes tes interfaces.
* Regarde aussi si tes interfaces sont au moins en 100 Mbits, avec ethtool <nom_interface> .
* Pour dissocier les problèmes de perfs réseau d'avec un problème de configuration du bonding, désactive le
->
Tu déplaces tous tes fichiers ifcfg-eth* et ifcfg-bond0 dans un répertoire séparé, puis tu arrêtes le réseau : ifdown -a.
Puis tu copies le fichier sauvegardé ifcfg-bond0 dans ifcfg-eth0, renommes le DEVICE en eth0 puis , tu relances : ifup -a
Si tu observes toujours des problèmes de déconnexions réseau, regarde au niveau de la configuration de la carte (vitesse, autonégociation, ...). Essaie de changer de driver ...
Si tu n'as pas de problèmes de déconnexions sans le bonding, le problème vient de lui. Penses à te mettre au dernier niveau du kernel de Red Hat (de plus, ils en sont à la RHEL 5.1 en ce moment).
...
Et pour les RHEL, yum est bien pratique.
Soit tu enregistres chacun de tes serveurs chez Red Hat, soit tu t'installes un serveur yam, qui contient l'ensemble de tes patchs de sécurité, par release de RHEL = un canal pour RHEL3, un autre pour RHEL5.
Dans tous les cas, c'est pas bien pratique, Red Hat doit vouloir faire payer une solution de chez eux afin de pouvoir monter pas trop difficilement un miroir (synchronisé sur demande des admins) de leur canal de sécurité.
Sinon, avec Debian, *BSD ou même fedora/centos, c'est plus simple, aucun enregistrement n'est nécessaire, et les mises à jour en sont facilitées :-)
Mais je sais bien qu'entre les softs validés sur RHEL/Suse (Oracle, Weblogic, ...), et les politiques des boites, on se retrouve souvent à gérer des RHEL. Ca reste du Linux, mais on se sent bridés :-(
Bon je n'administre pas de Sun, je te donne le résultat de recherches dans google !
Au dela de "tracker" les mises à jour, Sun pousse à utiliser les clusters de patch, ce qui n'est pas un mal à l'usage.
Bon sous Tru64 et HP/UX, on a l'équivalent depuis un moment :-)
Bon après si tu veux gérer connaitre les security updates manquants sur un ensemble de serveurs, à partir d'un seul, c'est censé se faire avec smpatch. Mais ça ne semble pas évident, pas mal de galères en perspectives d'après google et smpatch ne gèrerait pas le mode remote en Solaris 8.
ok.
Ta carte semble être vue.
Il faudrait savoir si ta livebox est configurée avec WPA.
Si c'est le cas, il faudra peut-etre installer wpa_supplicant (urpmi wpa_supplicant ?).
Et regarde si tu peux scanner les réseaux wifi depuis une interface graphique Mandriva, rentrer un mot de passe si tu utilises du WEP ou du WPA.
Bon sinon, après quelques recherches, j'ai remarqué que tu n'étais pas tout seul à galérer avec ces cartes wifi.
D'après le résultat de iwconfig que tu as posté, ta carte a un chipset ralink RT61.
Comme l'indique ce thread, la commande lspci devrait te donner un résultat de ce genre :
...
00:0a.0 Network controller: RaLink RT2561/RT61 rev B 802.11g
...
J'ai pas mal cherché, et il faut dire que bcp de monde a des problèmes avec ces cartes sous linux. Il n'y a pas de solution miracle. Il faut trouver celle qui marche pour toi !
Je n'utilise pas le wifi (ni Mandriva -> Debian).
Cependant, je peux tenter de t'aider.
Que donne le résultat de la commande iwconfig ?
Es tu certain que le WPA est activé ?
Après quelques recherches sur google, j'ai pu trouvé ce tutoriel, qui permet de configurer ndiswrapper (=utilisation des drivers wifi windows sous linux).
Je ne sais pas si ça correspond à ta version de Mandriva, et au dongle wifi livré avec la livebox : http://lea-linux.org/cached/index/Trucs:Oldid=657.html
J'ai majoritairement dormi cette nuit, et n'ai pas bu hier, ce qui m'a permi de faire un petit tour sur les forums de linuxfr avec quelques neurones de connectés :-)
Cette page donne une série de solutions au problème de lancement de process en tâche de fond :
http://www.cyberciti.biz/tips/nohup-execute-commands-after-you-exit-from-a-shell-prompt.html
. Si tu veux lancer un process en tâche de fond, sans qu'il te soit nécessaire d'interagir avec par la suite, utilise nohup <cmd> & ou echo <cmd> | at now .
. Si tu veux avoir la main sur ce process ultérieurement, utilise screen.
J'ai répondu un peu trop rapidement.
Si tu souhaites que lors d'un apt-get upgrade, un nouveau kernel soit compilé automatiquement, ça n'est pas possible de base à mon avis, à moins de configurer apt pour cela, ce qui me semble dangereux.
Dans tous les cas, utilise make-kpkg . Le paquet debian l'incluant est : kernel-package
Commence par jeter un coup d'oeil dans /var/log/messages.
Il se peut que le kernel panic "s'annonce", du genre panic filesystem au hasard :-(
Si tu ne voies rien, et rien de plus dans d'autres fichiers de /var/log, des tests mémoire et vérifs filesystem (fsck) sont à envisager, effectivement.
L'utilisation de memtest86 est décrite ici : http://netah25.developpez.com/Tutoriels/TutoMemtest86/
Concernant Samba, smbclient -U user%motdepasse ip_du_serveur marche ? testparm ne renvoie pas d'erreur ?
Pas de problème DNS ? Les ports sont ils ouverts et accessibles depuis un client comme le suggère zx81 ?
Depuis un client, //serveur/partage marche ?
Par ailleurs, le mode debug de samba peut aider si tu ne trouves pas le problème :
debug level dans smb.conf .
Cette page en parle : http://www.oreilly.com/catalog/samba/chapter/book/ch09_01.html
Mais bon si la config marchait avant et que rien n'a changé ...
Sympa le mozilla turbo !!!
Bon ca bouffe quand meme pas mal de ram sous windows ! Mais vu le prix de la RAM ...
Mozilla 0.9.2 est-il de bonne qualite sous Linux ?
[^] # Re: driver ?
Posté par stillbsd . En réponse au message Info sur carte SCSI. Évalué à 1.
Si tu fais cette recherche dans google :
"Ultra320 SCSI" Drivers rhel site:adaptec.com
-> le 2e lien de résultat est celui-ci :
http://www.adaptec.com/en-US/downloads/rh/rhel_4?productId=A(...)
Et tu aboutis à ce lien :
http://www.adaptec.com/en-US/speed/scsi/linux/a320raid-3_00_(...)
Je te conseille ce rpm car les modules ne devaient pas s'installer du fait que le paquet était prévu pour une RHEL 4 update 4, kernel 2.6.9-42 .
Hors tu es manifestement dans une RHEL 4 de niveau inférieur, avec un kernel 2.6.9-22.
Donc tu regardes ta version exacte dans :
/etc/redhat-release
et tu installes le rpm approprié pour l'architecture x86 ou x86_64.
[^] # driver ?
Posté par stillbsd . En réponse au message Info sur carte SCSI. Évalué à 1.
Cette ligne dans /proc/scsi/scsi laisse penser que la carte est reconnue :
Vendor: IBM Model: 02R0962a S320 1 Rev: 1
Par ailleurs, tu n'as pas utilisé ce driver ?
http://www.adaptec.com/fr-FR/speed/scsi/linux/aic79xx_2-0-25(...)
Je n'ai jamais installé de lecteur de bande sous Linux, il faudra que tu regardes sur le Net s'il est nécessaire de lui installer un driver..
Les erreurs que tu as eu à l'installation de ton rpm me paraissent inquiétantes.
Redémarre sur ton noyau antérieur à l'installation du rpm, assures toi que les entrées dans le modprobe.conf concernant la carte sont enlevées, et réinstalles le driver.
[^] # Re: lshw aussi
Posté par stillbsd . En réponse au message Info sur carte SCSI. Évalué à 1.
et :
mt -f /dev/st0 status
renvoient-elles des informations ?
# lspci
Posté par stillbsd . En réponse au message Info sur carte SCSI. Évalué à 1.
lspci doit te donner cette information.
dmesg|grep -i scsi
te dira quelles cartes SCSI sont vues par ton kernel.
Tu n'as peut-être même pas besoin d'installer ton RPM, qui renvoie des erreurs à l'installation, si cette carte est vue après installation.
[^] # Re: kudzu
Posté par stillbsd . En réponse au message Truc bizarre réseau. Évalué à 1.
Essaies peut-être aussi d'enlever la directive HWADDR= de tous les fichiers ifcfg-eth* .
-> Le but étant que ip link list te nomme correctement toutes tes interfaces.
* Si tu as un serveur Dell PowerEdge 2950 server ou un HP ProLiant BL480c G1 server, regarde cette page qui parle de problèmes de nommage de cartes sur ces serveurs :
http://www.cyberciti.biz/tips/howto-fix-rhel-centos-nic-orde(...)
* Regarde aussi si tes interfaces sont au moins en 100 Mbits, avec ethtool <nom_interface> .
* Pour dissocier les problèmes de perfs réseau d'avec un problème de configuration du bonding, désactive le
->
Tu déplaces tous tes fichiers ifcfg-eth* et ifcfg-bond0 dans un répertoire séparé, puis tu arrêtes le réseau : ifdown -a.
Puis tu copies le fichier sauvegardé ifcfg-bond0 dans ifcfg-eth0, renommes le DEVICE en eth0 puis , tu relances : ifup -a
Si tu observes toujours des problèmes de déconnexions réseau, regarde au niveau de la configuration de la carte (vitesse, autonégociation, ...). Essaie de changer de driver ...
Si tu n'as pas de problèmes de déconnexions sans le bonding, le problème vient de lui. Penses à te mettre au dernier niveau du kernel de Red Hat (de plus, ils en sont à la RHEL 5.1 en ce moment).
[^] # Re: kudzu
Posté par stillbsd . En réponse au message Truc bizarre réseau. Évalué à 1.
Regarde ce thread, pour "stabiliser" ton bonding :
http://forums11.itrc.hp.com/service/forums/questionanswer.do(...)
[^] # bonding ?
Posté par stillbsd . En réponse au message Truc bizarre réseau. Évalué à 1.
As-tu essayé de virer le bonding temporairement, afin de savoir si c'est lui qui est la cause du problème de freeze réseeau ?
[^] # Re: Update tracker
Posté par stillbsd . En réponse au message Update tracker. Évalué à 1.
Et pour les RHEL, yum est bien pratique.
Soit tu enregistres chacun de tes serveurs chez Red Hat, soit tu t'installes un serveur yam, qui contient l'ensemble de tes patchs de sécurité, par release de RHEL = un canal pour RHEL3, un autre pour RHEL5.
Dans tous les cas, c'est pas bien pratique, Red Hat doit vouloir faire payer une solution de chez eux afin de pouvoir monter pas trop difficilement un miroir (synchronisé sur demande des admins) de leur canal de sécurité.
Sinon, avec Debian, *BSD ou même fedora/centos, c'est plus simple, aucun enregistrement n'est nécessaire, et les mises à jour en sont facilitées :-)
Mais je sais bien qu'entre les softs validés sur RHEL/Suse (Oracle, Weblogic, ...), et les politiques des boites, on se retrouve souvent à gérer des RHEL. Ca reste du Linux, mais on se sent bridés :-(
[^] # Re: Update tracker
Posté par stillbsd . En réponse au message Update tracker. Évalué à 1.
D'après ces 2 docs trouvées via google :
http://mathrice.org/rencontres/octobre.2003/spi.pdf
et :
http://www.stmental.net/admin_info/
utiliser smpatch est une bonne idée sous Solaris.
Un soft alternatif pour la mise à jour (un script perl): pca -> http://www.par.univie.ac.at/solaris/pca/intro.html
Cet admin semble pousser à utiliser pca :
https://filer.case.edu/wiki/notes/solaris
Bon je n'administre pas de Sun, je te donne le résultat de recherches dans google !
Au dela de "tracker" les mises à jour, Sun pousse à utiliser les clusters de patch, ce qui n'est pas un mal à l'usage.
Bon sous Tru64 et HP/UX, on a l'équivalent depuis un moment :-)
Bon après si tu veux gérer connaitre les security updates manquants sur un ensemble de serveurs, à partir d'un seul, c'est censé se faire avec smpatch. Mais ça ne semble pas évident, pas mal de galères en perspectives d'après google et smpatch ne gèrerait pas le mode remote en Solaris 8.
Tentakel + pca serait à tenter :-)
[^] # Re: filtrage mac
Posté par stillbsd . En réponse au message Pb de connexion livebox. Évalué à 1.
Ta carte semble être vue.
Il faudrait savoir si ta livebox est configurée avec WPA.
Si c'est le cas, il faudra peut-etre installer wpa_supplicant (urpmi wpa_supplicant ?).
Et regarde si tu peux scanner les réseaux wifi depuis une interface graphique Mandriva, rentrer un mot de passe si tu utilises du WEP ou du WPA.
Bon sinon, après quelques recherches, j'ai remarqué que tu n'étais pas tout seul à galérer avec ces cartes wifi.
D'après le résultat de iwconfig que tu as posté, ta carte a un chipset ralink RT61.
Comme l'indique ce thread, la commande lspci devrait te donner un résultat de ce genre :
...
00:0a.0 Network controller: RaLink RT2561/RT61 rev B 802.11g
...
Thread : http://lea-linux.org/pho/read/4/316566
La dernière page du thread résume 2 solutions :
. installer puis configurer madwifi, qui serait intégré dans les dernières versions de mandriva d'après :
http://www.netgear-forum.com/forum/index.php?showtopic=31301
. ou compiler un autre driver pour RT61.
Il faut récupérer les sources à cette adresse :
http://rt2x00.serialmonkey.com/wiki/index.php?title=Download(...)
Et suivre un résumé donné par 'ultrarep' en page 3 de ce thread :
http://lea-linux.org/pho/read/4/316566/page-3#debut
J'ai pas mal cherché, et il faut dire que bcp de monde a des problèmes avec ces cartes sous linux. Il n'y a pas de solution miracle. Il faut trouver celle qui marche pour toi !
# wpa/ndiswrapper/...
Posté par stillbsd . En réponse au message Pb de connexion livebox. Évalué à 1.
Cependant, je peux tenter de t'aider.
Que donne le résultat de la commande iwconfig ?
Es tu certain que le WPA est activé ?
Après quelques recherches sur google, j'ai pu trouvé ce tutoriel, qui permet de configurer ndiswrapper (=utilisation des drivers wifi windows sous linux).
Je ne sais pas si ça correspond à ta version de Mandriva, et au dongle wifi livré avec la livebox :
http://lea-linux.org/cached/index/Trucs:Oldid=657.html
[^] # Re: Lancement en tache de fonds?
Posté par stillbsd . En réponse au message Lancement en tache de fonds?. Évalué à 1.
J'ai majoritairement dormi cette nuit, et n'ai pas bu hier, ce qui m'a permi de faire un petit tour sur les forums de linuxfr avec quelques neurones de connectés :-)
# rsync et rsnapshot
Posté par stillbsd . En réponse au message aide cron crontab pour une sauvegarde de logs. Évalué à 1.
Jette un coup d'oeil à rsync et rsnapshot :
http://alexdfr.wordpress.com/2007/10/27/sauvegardes-sous-linux-la-vraie-solution-avec-rsync-et-rsnapshot
# Update tracker
Posté par stillbsd . En réponse au message Update tracker. Évalué à 1.
Est-ce-que tes serveurs utilisent un seul type de distribs linux ?
Car une mise à jour est souvent relative au type de paquets : rpm, deb, ...
Par exemple, sur une Redhat like, yum check-update est censé marcher pas trop mal, si tu utilises yum.
Après, pour obtenir un résultat serveur par serveur, tentakel est assez efficace d'après un collègue (=ssh sur un ensemble de serveurs).
Cette page explique comment le paramètrer :
http://www.cyberciti.biz/tips/execute-commands-on-multiple-linux-or-unix-servers-part-ii.html
# Lancement en tache de fonds?
Posté par stillbsd . En réponse au message Lancement en tache de fonds?. Évalué à 1.
Cette page donne une série de solutions au problème de lancement de process en tâche de fond :
http://www.cyberciti.biz/tips/nohup-execute-commands-after-you-exit-from-a-shell-prompt.html
. Si tu veux lancer un process en tâche de fond, sans qu'il te soit nécessaire d'interagir avec par la suite, utilise nohup <cmd> & ou echo <cmd> | at now .
. Si tu veux avoir la main sur ce process ultérieurement, utilise screen.
[^] # Re: Re : mise à jour de noyau compilé
Posté par stillbsd . En réponse au message Mise à jour de noyau compilé. Évalué à 3.
J'ai répondu un peu trop rapidement.
Si tu souhaites que lors d'un apt-get upgrade, un nouveau kernel soit compilé automatiquement, ça n'est pas possible de base à mon avis, à moins de configurer apt pour cela, ce qui me semble dangereux.
Dans tous les cas, utilise make-kpkg . Le paquet debian l'incluant est : kernel-package
Un exemple de l'utilisation de make-kpkg ici : http://nicolaxx.free.fr/docs/noyau/noyau-2.html
Apparemment tu peut passer une option --initrd pour générer un nouveau initrd.
# Re : mise à jour de noyau compilé
Posté par stillbsd . En réponse au message Mise à jour de noyau compilé. Évalué à 1.
C'est indiqué ici : http://www.debian.org/doc/manuals/reference/ch-kernel.fr.htm(...)
cp fichier_de_config dans la home des sources du kernel
puis make-kpkg.
[^] # Re: problème hardware ?
Posté par stillbsd . En réponse au message Kernel Panic sur un Controleur de Domaine Samba (sur Debian). Évalué à 1.
Il se peut que le kernel panic "s'annonce", du genre panic filesystem au hasard :-(
Si tu ne voies rien, et rien de plus dans d'autres fichiers de /var/log, des tests mémoire et vérifs filesystem (fsck) sont à envisager, effectivement.
L'utilisation de memtest86 est décrite ici : http://netah25.developpez.com/Tutoriels/TutoMemtest86/
Concernant Samba, smbclient -U user%motdepasse ip_du_serveur marche ? testparm ne renvoie pas d'erreur ?
Pas de problème DNS ? Les ports sont ils ouverts et accessibles depuis un client comme le suggère zx81 ?
Depuis un client, //serveur/partage marche ?
Par ailleurs, le mode debug de samba peut aider si tu ne trouves pas le problème :
debug level dans smb.conf .
Cette page en parle : http://www.oreilly.com/catalog/samba/chapter/book/ch09_01.html
Mais bon si la config marchait avant et que rien n'a changé ...
[^] # Re: le message sur le site de phpnuke..;
Posté par stillbsd . En réponse à la dépêche PostNuke. Évalué à -1.
# Mozilla 0.9.2
Posté par stillbsd . En réponse à la dépêche Mozilla 0.9.2. Évalué à 1.
Bon ca bouffe quand meme pas mal de ram sous windows ! Mais vu le prix de la RAM ...
Mozilla 0.9.2 est-il de bonne qualite sous Linux ?