Reprise du message précédent :
je pense qu'il faudrait que tu repenses un peu ton concept de sécurité là.

  Si une faille est détectée dans un des logiciels installé. Pour moi ça me semble important que le fix soit installé le plus rapidement possible et donc au jour le jour.
Il est ou mon problème de conception de sécurité?  

Le problème c'est que les mise à jour de sécurité sortent dans l'urgence, et que ca peut mal se passer, necessiter une intervention manuelle.
 
Donc soit tu installes uniquement à la main, soit tu mets en place un delai avant l'application d'une MAJ automatique, le temps d'être assuré que le paquet de sécurité va pas remettre en cause l'accessibilité de ton serveur.

Drôle de manière de faire niveau maj de secu pour du stable?  
Normalement si t'es en stable, c'est que tous les paquets, même maj de sécurité sont sensé être validé avant leur arrivé. Ou alors je ne comprends pas bien l'intérêt d'une version stable si c'est pour qu'une maj de sécurité casse tout. C'était justement ce que je reprochais à Ubuntu.
Sous OpenSuse je n'ai jamais eu ce genre de problème, même sur mon serveur ou je fais toutes les majs les yeux fermés.
Sous debian reputé comme stable, je m'attendais à ce que ça en soit de même comme politique voir que ça soit encore plus stable, surtout avec des versions plus stabilisé de logiciel.
Je comprend qu'il y ait quelques problèmes parfois, car le risque 0 n'existe jamais sur une maj et tester toutes les variantes possibles n'est pas possible, mais ça doit être ultra rare voir n'arriver quasiment jamais.

bon j'ai trouvé tout seul. j'ai remplacé etch par testing dans /etc/apt/sources.list  
 
ps: et pourquoi j'ai pas de fichier /etc/apt/apt.conf moi ?

Le processus de validation des paquets en stable est très très très long (unstable => testing => freeze => stable) après les versions sont censées ne plus bouger, donc y a eu beaucoup de test de la stabilité des paquets.

Les paquets sécurité ont pas la possibilité d'être testée de cette façon, évidemment, donc tu t'exposes à des risques, et la perfection n'étant pas de ce monde, à des possibilités d'avoir un truc qui merde dans un cas précis qui n'a pas pu être testé par les mainteneurs de paquets...

Après tu fais comme tu le sens, mais pour ma part, apticron me prévient par mail des mises à jour disponibles sur mes différents systèmes, et ensuite j'interviens manuellement sur mes machines

A la rigueur c'est pas bête comme idée.
Je pense que c'est ce que j'appliquerais. M'enfin après, si ça foire lors de la maj, le problème reste le même... Faut juste en gros que je fasse des recherches pour voir si ça passe ou pas quoi en gros.
Mais bon quand même le risque qu'une maj de sécurité plante tout au point de ne plus pouvoir y accéder me semble très peu probable. Sur mon serveur ou j'ai de tout qui tourne sur OpenSuse, ça n'est jamais arrivé. Même en update de logiciel.

Ah mais je dis pas que ca arrive souvent, mais perso, tout ce qui du ressort des probabilités => Loi de Murphy => je me méfie

le fait de voir les informations liés au type de mise a jour peut justement te donner une idée des risques encourues.
De sucroit en tardant un peu tu peux probablement avoir déja l'existence d'un rapport de bug, etc etc

Bon ben je ferais ça alors. Mail pour voir les majs et puis je passerais par là voir si y a eu des beta testeurs

Tu n'as pas ce fichier ainsi que le fichier /etc/apt/preferences. On doit les créer si on veut faire du "pinning".
 
Et avant de se lancer là dedans, il faut lire attentivement la doc.
 
man apt_preferences   (le plus important)
 
et http://wiki.debian.org/AptPinning

 
lis le topic j'ai expliqué avant qu'il faut créer les 2 fichiers à la main. C'est pas la en standard, parce que pas nécessaire.

dites voir, quand je fais un mount tout con de mon HDD ntfs, il est seulement accessible par root. Après un chmod, il est accessible par tout le monde mais les sous-rép sont toujours en 0700
 
par contre en montant avec ça :  mount /dev/sdb6 -t ntfs /mnt/ntfs/ -o umask=0022
 tout le monde peut aller lire.
 
j'ai essayé de comprendre mais avec les 160 pages du MAN et leur 2 explications pas clair, ça n'aide pas .
En gros, pourquoi il n'y a pas moyen de monter un foutu HDD NTFS en lecture sous gnome avec un compte user normal ?

 
parce qu'il faut remplir fstab pour ça (avec l'option users, histoire de pouvoir facilement le démonter après). Et que par défaut, tu ne montes que pour l'utilisateur qui invoque la commande de mémoire, d'où l'intérêt d'un umask (ou la combinaison fmask/dmask si tu veux différencier fichier et dossiers) et/ou d'un gid/uid pour définir le proprio.

okay, j'ai encore quelques trucs à voir je pense avant de pouvoir comprendre toute l'histoire merci des infos !

donc si j'ai bien compris je rajoute dans mon fstab
 
/dev/sdb6       /mnt/ntfs            ntfs    ro, users             0       0
 
et du coup ça sera up pour tout le monde ?

il y avait 2 choses dans ta questions :

• qui peut monter la partition ?

ça c'est l'option user/users qui, lorsqu'elle est présente, permet à un utilisateur simple de monter la partition

• Qui peut lire/écrire sur la partition ?

Le fat32 et le ntfs, n'ont pas de droit par fichier sous linux, ce sont des droits qui sont définis par les options de montages.
umask : c'est le masque des droits, l'inverse du chmod, tu pars de 777 et tu soustrais les droits que tu veux enlever (4 = r ; 2 = w ; 1= x), donc 022 ça signifie rwxr-xr-x (7-0=7=4+2+1 7-2=5=4+1 ) pour tout le monde.
tu peux raffiner avec fmask pour les fichiers et dmask pour les dossiers (typiquement dmask=022 et fmask=133).

uid et gid et c'est pour définir un propriétaire et un groupe propriétaire : uid=root gid=root par ex.

sinon, avec le pilote ntfs, tu n'as que la lecture possible, si tu veux l'écriture, il faut utiliser ntfs-3g
c'est pas ultra à jour mais ça explique encore un peu : http://mjules.free.fr/NTFS_et_GNU_linux.htm

ah bah oui, logique en fait, mon mount fonctionne bien mais doit quand même être exec depuis une console root.
Par contre à la modif du fstab tout le monde pourra monter le disque. merci !

Par contre, pourquoi est-ce que je ne peux pas changer les accès d'une partoche déjà montée (sans umask) ? et donner +r à tout le monde ?

tu pourrais le faire avec un fs qui gère les droits par fichier.
Le ntfs sous linux ne le permet pas, j'imagine que ce serait assez complexe vu la différence entre les droits unix et les droits windows. Donc dans ce cas (et idem pour fat), tu es obligé de passer par un truc global, et comme il est défini au montage, le chmod échoue ensuite (mais je connais pas les détails).

Hello,
 
dites moi, c'est jouable d'être sur une sid pour un desktop perso ?  
 
Je cherche une distro plutôt en rolling release, a jour avec les dernier softs, mais qui soit quand même fonctionnelle
Par contre, je peux passer du temps a me configurer ma debian aux petits oignons, mais je n''ai pas envie de la réparer toutes les semaines quoi ....
 

Oui, c'est jouable, c'est mon cas aussi bien @home qu'au boulot, je ne me suis jamais retrouvé au point de ne plus pouvoir bosser

Y a des gens avec :
- serveur samba Etch
- client cifs en Lenny/Sid
?
 
depuis le noyau 2.6.25 (et jusqu'au .27), j'ai un problème avec les applis KDE qui souhaitent écrire sur les partage cifs (comme quoi j'ai pas le droit ou alors le disque est plein)...
En .24 pas de problème
Avec les applis en ligne de commande ou gnome pas de problèmes non plus

Je partage l'expérience de e_esprit : depuis 3 ans j'utilise @home une Sid customisée sur mesure pour mes besoins et celle-ci a été très rarement cassée (pour tout dire ça m'est vraiment arrivé une seule fois à cause d'un utilitaire qui m'a bousillé tous les liens symboliques dans /etc/rc?.d ; et encore j'ai pu récupérer la conf depuis une autre install.    ).
 
Bref, assez peu de maintenance à prévoir à partir du moment où tu feras un minimum gaffe (en utilisant par exemple apt-listbugs qui indiquera les bugs les plus génants lors des maj ; il suffira dans ce cas de figer les versions des softs posant problème en attendant une nouvelle maj fixant les bugs). À part cela, les fichiers de conf dans /etc évoluent plus ou moins régulièrement : ceux d'origine sont automatiquement mis à jour et ceux que tu as customisés sont au choix conservés (par défaut) ou remplacés (via un mécanisme nommé debconf) par la nouvelle conf proposée lors de l'update.
 
 
Sinon il y a aussi testing, assez proche de unstable au niveau des versions des softs tout en étant un peu plus testée (moins de bugs) ; c'est plus ou moins ce que j'utilise @work (un environnement mixte : à base de Lenny avec certains paquets backportés depuis Sid) depuis plusieurs mois et sans le moindre problème.  

Vous gérez comment la fait que VLC gères pas pas Xvid suite à une MAJ de FFMpeg ?
 
Compil' maison de ffmpeg ?

On utilise mplayer    

Solution de facilité, pas intéressant.

Quelles versions de libavcodec libavformat tu as ?

Bah alors rien ne t'empêche de revenir à la version précédente de FFMpeg    ; suffit par exemple de passer par http://snapshot.debian.net/ffmpeg  

LibAvCodec --> 5.1
LibAvFormat --> 5.2

En fait j'utilise le dépôt debain-multimedia (sous sid) et j'ai pas de pb.
J'ai les versions 0.svn20080206-14 pour les 2

Thx pour vos retours THRAK et e_esprit, je vais donc tenter tout ca

Après je ne sais plus quelle manip pour ajouter un paquet je me suis retrouvé à mettre un dépôt ubuntu universe dans mon source.list.

Depuis je n'ai plus le dépôt dans le source.list mais j'ai toujours ce vilain message à chaque update:

Quelqu'un peut m'aider à supprimer ces vilaines lignes ? (apt-get update ne marche pas mieux)

non marche pas Mr la console.

Pourquoi tu mets des dépôts ubuntu sous une debian?
 
Et sinon :  
wget -q adresse_de_la_key/key.gpg  
 
# apt-key add la_key.gpg  

Pour avoir un paquet que j'ai trouvé et qui c'est révélé un peu incompatible, donc poubelle et je me prend des messages d'insultes

Même en enlevant la ligne de ton sources.list ?

Oui, elle n'y est plus
 

 
Comprend pas là

Etrange, la dernière ligne est elle nécessaire ?
Tu n'as pas des paquets d'ubuntu en "cours" d'installation ? (packet dont tu as demandé l'install, installation qui s'est arrêtée en cours ?)

./configure
make
make install

hmmm... pas sûr que ce soit une si excellente idée que ça...
La glibc c'est quand même un peu une des lib les plus importantes sous linux, vaut mieux éviter de l'installer n'importe comment (d'une part sans packaging), d'autre part de voir les intéractions avec la glibc déjà présente.

La dernière ligne est utile oui, mais elle est là depuis l'installation du système.
Je ne vois rien dans les logs