Claim Award!!!
Claim Award!!! We are informing you that your email address has won ?750,000Euros in the email electronic lotto on 27-05-2008. For details and validation,contact Mr Peter Hines. E-mail: [EMAIL PROTECTED] a)Lucky nr:5-9-19-21-38/1/7 b)Serial nr:9047HDFER C)Batch nr:3GH874HR d)Ref nr:709146423 Congratulations in advance. Regards, Mrs Deborah Byron. Reply email: [EMAIL PROTECTED] === Benvenuto in Maxi Mail di Virgilio e Tin.it! [EMAIL PROTECTED] tramite il servizio Maxi Mail ha messo a tua disposizione i seguenti allegati : * lltt.txt (0 byte) per prelevarli, fai click sul seguente link che ti porterà su una pagina dove troverai i comandi per visualizzare o scaricare gli allegati sul tuo PC: http://communicator.maximail.alice.it/r.jsp?d=virgilio.it&wr=_unreg_4rcvymfu&ws=31z9f541&e=virgilio.it&c=gwWwMKNV9HfnwWTcaIEsF2z7VIYDr3Bq397545 Ti ricordiamo che questi allegati saranno a tua disposizione fino al 05/06/2008 alle ore 19:54 e che il mittente potrebbe ricevere le informazioni relative alla tua apertura della Maxi Mail e all'avvenuto download degli allegati. Maxi Mail è il nuovo servizio gratuito, di Virgilio e Tin.it che ti permette di inviare a chi vuoi, allegati di grandi dimensioni, in modo semplice e veloce, senza occupare spazio utile nella tua casella di posta. Per saperne di più visita il sito www.tin.it -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/DebFrFrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:" To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NVidia Geforce, ACPI et Ventilo
s4mdf0o1 a écrit : Le mardi 03 juin 2008, Jean-Michel Caricand a écrit : Je pense qu'il vous faut le driver NVidia officiel pour que votre ventilateur ne fonctionne que lorsque cela est nécessaire. Faites l'essai. Si je suis dans le vrai, l'information sera utile pour tous. J'ai déjà le driver proprio... Je pense que la régulation du ventilateur se fait par la détection par ACPI du "sensor" de température du GPU. Le système se fige au chargement du kernel : *Menu Grub Loading... =Freeze Ne fonctionnant alors qu'avec l'option acpi=off Le système démarre correctement, avec le ventilateur à vitesse réduite, donc bruit minimum. Arrive le démarrage de l'interface graphique. Là le ventilateur se met à plein régime. Donc, Driver Proprio NVidia, ou pas, le mal est fait : Le chargement du driver nvidia -et le manque ACPI-, entraîne le fonctionnement du ventilo à plein régime. Il me semble donc clair qu'il s'agit d'un bug ACPI, tel qu'expliqué ici : http://www.lesswatts.org/projects/acpi/overridingDSDT.php Qui est le même problême pour des portables avec chipsets nvidia, tel qu'expliqué ici : http://www.nvnews.net/vbulletin/showthread.php?t=75995&page=2 Ma question réside donc surtout sur un moyen d'obtenir un ACPI "débuggé", par (par exemple), l'installation d'un kernel customizé en backports, par exemple, contenant donc ce fameux DSDT, bien que : Note that overriding the DSDT is a debugging technique only. Sinon, si c'est juste pour monitorer la vitesse du ventilo de ta CG, il existe nvclock qui le permet. Il est dispo sous forme de paquet .deb. Si ca peut aider :-) -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/DebFrFrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:" To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: nouvelle CM et détection disques durs IDE
mahashakti89 a écrit : > Bonjour, > > Je viens de changer de carte-mère, et de faire l'acquisition d'une > ASUS P5E, mais je rencontre un problème à la détection des disques > durs IDE, le disque branché en maitre sur l'ancienne carte-mère > n'est pas reconnu dans le bios au chapitre IDE, seuls sont reconnus > un disque et un graveur SATA. > Je reçois le message "no primary IDE master detected" > Par contre si je laisse les choses suivre leur cours, j'arrive à > l'écran de GRUB, je démarre > > root (hd0,0) > vmlinuz=/dev/hda6 ... > > mais ça stoppe à "mounting root file system" > > et je remarque que le disque dur IDE de 320Gb est détecté comme /dev/hdc > > donc reboot en single , changement du fstab de hda en hdc et ça roule à > peu près. > > Mais j'aimerais bien y comprendre quelque chose un disque IDE qui > n'apparaît pas dans le BIOS, mais que je retrouve au boot.. > Et plus de Primary IDE master de détecté > > Bref quelle piste suivre ? brancher le HD en question sur l'autre connecteur IDE -- There is no fear in love; but perfect love casts out fear. -- 1 John 4:18 -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/DebFrFrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:" To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
nouvelle carte mère
Bonjour, Je viens de changer de carte-mère, et de faire l'acquisition d'une ASUS P5E, mais je rencontre un problème à la détection des disques durs IDE, le disque branché en maitre sur l'ancienne carte-mère n'est pas reconnu dans le bios au chapitre IDE, seuls sont reconnus un disque et un graveur SATA. Je reçois le message "no primary IDE master detected" Par contre si je laisse les choses suivre leur cours, j'arrive à l'écran de GRUB, je démarre root (hd0,0) vmlinuz=/dev/hda6 ... mais ça stoppe à "mounting root file system" et je remarque que le disque dur IDE de 320Gb est détecté comme /dev/hdc donc reboot en single , changement du fstab de hda en hdc et ça roule à peu près. Mais j'aimerais bien y comprendre quelque chose un disque IDE qui n'apparaît pas dans le BIOS, mais que je retrouve au boot.. Et plus de Primary IDE master de détecté Bref quelle piste suivre ? Merci mahashakti89 -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/DebFrFrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:" To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
nouvelle CM et détection disques durs IDE
Bonjour, Je viens de changer de carte-mère, et de faire l'acquisition d'une ASUS P5E, mais je rencontre un problème à la détection des disques durs IDE, le disque branché en maitre sur l'ancienne carte-mère n'est pas reconnu dans le bios au chapitre IDE, seuls sont reconnus un disque et un graveur SATA. Je reçois le message "no primary IDE master detected" Par contre si je laisse les choses suivre leur cours, j'arrive à l'écran de GRUB, je démarre root (hd0,0) vmlinuz=/dev/hda6 ... mais ça stoppe à "mounting root file system" et je remarque que le disque dur IDE de 320Gb est détecté comme /dev/hdc donc reboot en single , changement du fstab de hda en hdc et ça roule à peu près. Mais j'aimerais bien y comprendre quelque chose un disque IDE qui n'apparaît pas dans le BIOS, mais que je retrouve au boot.. Et plus de Primary IDE master de détecté Bref quelle piste suivre ? Merci mahashakti89 -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/DebFrFrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:" To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: awstats, sarge
Bon, il semble qu'il y ait un souci très net avec le awstats version
6.5+dfsg-1. Sur la machine refaite et surveillée, lorsque que awstats.pl était
sans droit de lecture, tout se passait bien. Dès que j'ai remis le script en
lecture (script vérifié par le md5sum), 12h plus tard, un script était de
nouveau éxécuté via perl et apache. Le seul script perl sur cette machine est
awstats.pl. J'ai modifié awstats. awstats est la version de etch. Peut être il
y a un souci sur une version etch tournant sous sarge mais je m'interroge tout
de même. Il peut y avoir un doute sur la machine, cependant j'ai fait tourner
le script suivant
#!/bin/sh
MDORG=$1
MDEFF=`md5sum-static /$2 | awk '{print $1}'`
# echo $MDORG
# echo $MDEFF
if [ ! $MDORG = $MDEFF ] ; then
echo $2 compromis
sur tous les fichiers décrits dans /var/lib/dpkg/info/*.md5sum:
# cat *.md5sums | awk '{print ".verifie "$1 " "$2}' | sh
et rien d'inquiétant n'était apparu.
Ceci pour info pour ceux qui utilise awstats
François Boisson
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Postfix: ordre des vérifications (greylist ing, RBL)?
Julien Valroff wrote:
[snip]
C'est un petit serveur avec seulement 3 ou 4 utilisateurs réguliers, je
suis de loin celui qui reçoit le plus de mail, donc mon approche est la
bonne.
dans une config "normale", l'approche 1 est la plus commune (lancer le
GL à la fin).
postgrey a comme configuration par défaut de whitelister automatiquement
tous les serveurs ayant passé cette barrière avec succès 5 fois
(configurable bien entendu), en plus d'une whitelist maintenue
manuellement par les développeurs (listant les plus gros serveurs ayant
des problèmes avec le greylisting ou ceux qui sont bien connus de tous).
Le paquet Debian a par ailleurs ajouté les serveurs debian.org ("and
related") sur lesquels tournent de vrai serveurs smtp.
J'ai de mon coté ajouté certains serveurs de mailing-lists afin d'éviter
le problème dont tu parles plus haut.
tu peux utiliser dnswl comme liste blanche. Pour cela, il faut la
telecharger avec rsync
http://www.dnswl.org/tech#rsync
et l'utiliser avec un
check_client_access cidr:/chemin/vers/postfix-dnswl-permit
comme ça, pas de risque de bloquer un "bon" client, et ça évite de
devoir gérer ça en interne. Par exemple:
$ grep -i debian
/usr/local/etc/postfix/maps/cidr/dnswl.org/postfix-dnswl-permit
217.196.43.134/32 permit_auth_destination low debian.org DNSWLId 1791
202.134.73.140/32 permit_auth_destination low debian.org.hk
DNSWLId 8772
202.134.73.139/32 permit_auth_destination low debian.org.hk
DNSWLId 8772
194.109.137.218/32 permit_auth_destination low debian.org DNSWLId 1791
192.25.206.59/32permit_auth_destination low debian.org DNSWLId 1791
192.25.206.57/32permit_auth_destination low debian.org DNSWLId 1791
192.25.206.33/32permit_auth_destination low debian.org DNSWLId 1791
192.25.206.28/32permit_auth_destination low debian.org DNSWLId 1791
192.25.206.16/32permit_auth_destination low debian.org DNSWLId 1791
192.25.206.10/32permit_auth_destination low debian.org DNSWLId 1791
146.82.138.6/32 permit_auth_destination low debian.org DNSWLId 1791
140.211.166.43/32 permit_auth_destination low debian.org DNSWLId 1791
87.106.4.56/32 permit_auth_destination low debian.org DNSWLId 1791
86.59.118.152/32permit_auth_destination med debian.or.at DNSWLId
11329
86.59.21.34/32 permit_auth_destination low debian.or.at DNSWLId 6694
82.195.75.100/32permit_auth_destination low debian.org DNSWLId 1791
80.68.80.176/32 permit_auth_destination none debian-administration.org
DNSWLId 3368
78.47.201.134/32permit_auth_destination low debianforum.de
DNSWLId 11631
70.103.162.31/32permit_auth_destination low debian.org DNSWLId 1791
70.103.162.29/32permit_auth_destination low debian.org DNSWLId 1791
Pour moi, les résultats ne sont pas vraiment probants, les RBL sont de
loin la technique me permettant d'éliminer le plus de spam,
ici, reject_non_fqdn_helo_hostname vire plus de 30% des transactions
(par transaction, je veux dire un RCPT TO. donc un client qui tente
d'envoyer à plusieurs destinataires sera compté plusieurs fois).
mais comme
je n'ai pas leur contrôle, je n'ai pas vraiment confiance (certaines des
plus connues ont déjà blacklisté les serveurs Debian ou ceux d'Orange
notamment).
tu parles de sorbs? il y a eu une "bataille" entre sorbs et orange. le
tort est partagé. Orange n'ont pas été très fins: ils ont demandé aux
hebergeurs de sorbs de virer sorbs...
zen.spamhaus.org a la réputation d'etre "safe" et suffit par rapport aux
autres.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Postfix: ordre des vérifications (greylisting, RBL)?
Le mercredi 04 juin 2008 à 19:15 +0200, mouss a écrit :
> Julien Valroff wrote:
> > Bonjour,
> >
> > J'utilise depuis peu le greylisting sous Debian Etch, avec Postfix (et
> > donc Postgrey).
> >
> > En parallèle, j'utilise également des RBL qui se sont montrées efficaces
> > jusque maintenant.
> >
> > Tout fonctionne correctement, mais je me pose la question de l'ordre
> > dans les quel les contrôles doivent être effectués : greylisting avant
> > RBL ou l'inverse ?
> >
> > J'ai pour le moment laissé les RBL faire leur travail, en me disant
> > qu'il vaut mieux rejeter le plus tôt possible plutôt que d'attendre,
> > mais l'accès aux RBL n'est-il pas plus consommateur en ressources qu'un
> > rejet temporaire de la part de postgrey ?
> >
>
>
> Il y a deux écoles:
>
> 1- on fait le greylisting à la fin. l'idée est qu'il n'y a pas de raison
> de polluer la base de greylisting avec des entrées qui ne serviront
> jamais puisque le client se fera jeter par d'autres tests.
>
> 2- on fait le greylisting et si une transaction est "greylistée", on
> s'arrête et on ne fait pas les tests suivants. pour cela, il faut que le
> serveur de GL renvoie "defer" et non "defer_if_permit" (en général,
> c'est cette dernière action qui est renvoyée). L'idée ici est d'éviter
> de faire des requêtes couteuses si le client ne réessaye pas.
>
> si tu ne reçois pas trop de mail, les deux approches se valent plus ou
> moins. si tu reçois beaucoup de mails, la 2 est mieux car sinon il
> faudra payer un "feed" de spamhaus (et comme zen.spamhaus.org est la
> mailleure liste, ...).
C'est un petit serveur avec seulement 3 ou 4 utilisateurs réguliers, je
suis de loin celui qui reçoit le plus de mail, donc mon approche est la
bonne.
> Si tu veux "juger", il faut savoir que
> - il y a des "ratware" qui réessayent (probablement à l'aveugle dans la
> majorité des cas)
> - il y a des clients "légitimes" qui réessayent même quand il se font
> jeter (avec un 5xx).
>
> Pendant que j'y suis, il faut savoir que le greylisting "aveugle" n'est
> pas très désirable. quand il y a une discussion entre N personnes, celui
> qui greyliste l'un des message ne le recevra pas de suite, et verra des
> fils de discussion où il a l'impression d'avoir raté quelques messages
> (qui arriveront plus tard)... et de toute façon, ce n'est pas gentil de
> faire travailer des serveurs "honnêtes". Par contre, on peut faire du
> greylisting selectif: greylister si quelque chose est louche (un helo
> pas super top, un reverse dns "générique", ... etc). Et idéalement, il
> faut whitelister (du greylisting seulement) tout client qui a déjà passé
> l'épreuve (si on sait qu'il réessaye, pas la peine de le retester). [on
> peut aussi ne whitelister (du greylisting toujours, pas des autres
> vérifications) que les clients qui ont envoyé au moins un message
> "innocent"].
postgrey a comme configuration par défaut de whitelister automatiquement
tous les serveurs ayant passé cette barrière avec succès 5 fois
(configurable bien entendu), en plus d'une whitelist maintenue
manuellement par les développeurs (listant les plus gros serveurs ayant
des problèmes avec le greylisting ou ceux qui sont bien connus de tous).
Le paquet Debian a par ailleurs ajouté les serveurs debian.org ("and
related") sur lesquels tournent de vrai serveurs smtp.
J'ai de mon coté ajouté certains serveurs de mailing-lists afin d'éviter
le problème dont tu parles plus haut.
Pour moi, les résultats ne sont pas vraiment probants, les RBL sont de
loin la technique me permettant d'éliminer le plus de spam, mais comme
je n'ai pas leur contrôle, je n'ai pas vraiment confiance (certaines des
plus connues ont déjà blacklisté les serveurs Debian ou ceux d'Orange
notamment).
Merci pour ta réponse
Julien
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Déclaration d'impôts problème (Lenny)
Le Tuesday 03 June 2008 15:46:18 Yannick Fouquet, vous avez écrit : > Bonjour, > > Nicolas Salles a écrit : > > Le mardi 03 juin 2008 à 14:40 +0200, Philippe Merlin a écrit : > >> Bonjour, > >> Je suis en train de faire ma déclaration d'impôt et j'ai un certificat > >> qui date de l'année dernière. Tout se passe bien sauf au moment de la > >> signature ou j'obtiens actuellement chaque fois une erreur. Je cherche > >> une solution : > > [SNIP] > > > Nombre d'utilisateurs ont rencontré ton problème. Le problème se résoud > > apparemment en installant le package libnss3-dev et si ce n'est pas > > suffisant en utilisant la jvm 1.5 de sun. > > Personnellement, avec une Lenny, j'ai résolu le problème grâce à la > methode de Gaetan Perrier. > J'ai le paquet libnss3-1d > et j'ai fait un lien symbolique dans /usr/lib/ vers > /usr/lib/nss/libnssdbm3.so > > Yannick. idem et ça a bien marché hormis qu'après l'envoi de la signature on se trouve sur une page html vide. pmd -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/DebFrFrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:" To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Postfix: ordre des vérifications (greylist ing, RBL)?
Julien Valroff wrote: Bonjour, J'utilise depuis peu le greylisting sous Debian Etch, avec Postfix (et donc Postgrey). En parallèle, j'utilise également des RBL qui se sont montrées efficaces jusque maintenant. Tout fonctionne correctement, mais je me pose la question de l'ordre dans les quel les contrôles doivent être effectués : greylisting avant RBL ou l'inverse ? J'ai pour le moment laissé les RBL faire leur travail, en me disant qu'il vaut mieux rejeter le plus tôt possible plutôt que d'attendre, mais l'accès aux RBL n'est-il pas plus consommateur en ressources qu'un rejet temporaire de la part de postgrey ? Il y a deux écoles: 1- on fait le greylisting à la fin. l'idée est qu'il n'y a pas de raison de polluer la base de greylisting avec des entrées qui ne serviront jamais puisque le client se fera jeter par d'autres tests. 2- on fait le greylisting et si une transaction est "greylistée", on s'arrête et on ne fait pas les tests suivants. pour cela, il faut que le serveur de GL renvoie "defer" et non "defer_if_permit" (en général, c'est cette dernière action qui est renvoyée). L'idée ici est d'éviter de faire des requêtes couteuses si le client ne réessaye pas. si tu ne reçois pas trop de mail, les deux approches se valent plus ou moins. si tu reçois beaucoup de mails, la 2 est mieux car sinon il faudra payer un "feed" de spamhaus (et comme zen.spamhaus.org est la mailleure liste, ...). Si tu veux "juger", il faut savoir que - il y a des "ratware" qui réessayent (probablement à l'aveugle dans la majorité des cas) - il y a des clients "légitimes" qui réessayent même quand il se font jeter (avec un 5xx). Pendant que j'y suis, il faut savoir que le greylisting "aveugle" n'est pas très désirable. quand il y a une discussion entre N personnes, celui qui greyliste l'un des message ne le recevra pas de suite, et verra des fils de discussion où il a l'impression d'avoir raté quelques messages (qui arriveront plus tard)... et de toute façon, ce n'est pas gentil de faire travailer des serveurs "honnêtes". Par contre, on peut faire du greylisting selectif: greylister si quelque chose est louche (un helo pas super top, un reverse dns "générique", ... etc). Et idéalement, il faut whitelister (du greylisting seulement) tout client qui a déjà passé l'épreuve (si on sait qu'il réessaye, pas la peine de le retester). [on peut aussi ne whitelister (du greylisting toujours, pas des autres vérifications) que les clients qui ont envoyé au moins un message "innocent"]. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/DebFrFrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:" To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Postfix: ordre des vérifications (greylisting, RBL)?
Bonjour, J'utilise depuis peu le greylisting sous Debian Etch, avec Postfix (et donc Postgrey). En parallèle, j'utilise également des RBL qui se sont montrées efficaces jusque maintenant. Tout fonctionne correctement, mais je me pose la question de l'ordre dans les quel les contrôles doivent être effectués : greylisting avant RBL ou l'inverse ? J'ai pour le moment laissé les RBL faire leur travail, en me disant qu'il vaut mieux rejeter le plus tôt possible plutôt que d'attendre, mais l'accès aux RBL n'est-il pas plus consommateur en ressources qu'un rejet temporaire de la part de postgrey ? Merci par avance pour vos commentaires/retours d'expérience. @++ Julien -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/DebFrFrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:" To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [bind9] deux domaines
meric pour ton aide :)
ping domain2.com
PING system-linux.eu (91.121.12.xx) 56(84) bytes of data.
64 bytes from www.domain1.com (91.121.12.xx): icmp_seq=1 ttl=56
time=21.9 ms
64 bytes from www.domain1 (91.121.12.xx): icmp_seq=2 ttl=56
time=22.0 ms
64 bytes from www.domain1.com (91.121.12.xx): icmp_seq=3 ttl=56
time=22.0 ms
j'ai fais ca depuis l'exterieur c'est normal ??
On Mon, 02 Jun 2008 08:10:25 +0200, Frédéric HUET
wrote: Samuel SALSON a écrit :
oui j'ai fini par trouver :)
merci quand meme
par contre si je veux faire un zone inverse ?
je n'ai qu'une seule ip publique
j'ai mis :
zone "92.11.xx.in-addr.arpa" {
type master;
file "/etc/bind/db.domain2.com.inv";
forwarders{};
named-checkconf
/etc/bind/named.conf:76: zone '92.11.xx.in-addr.arpa': already
exists
previous
On Mon, 02 Jun 2008 00:18:33 +0200, Frédéric HUET
wrote:
GanGan a écrit :
bonsoir les gens, Voici mon soucis, je viens de prendre
un deuxieme
domaine pour faire mumuse j\'ai rajouté dans mon named.conf
ceci : zone "domain2.com" { type master; notify yes; file
"/etc/bind/db.domain2.com"; forwarders{}; j\'ai créé le
fichier db.domain2.com comme ceci : domain2.com. 3600 @ IN SOA
srv.domain2.com. root.domain2.eu. ( 2008050101 ; Serial 3600 ; Refresh
(1 heure) 900 ; Retry (15 minutes) 1209600 ; Expire (2 weeks) 43200 ;
Minimum cache (12 heures) ) NS srv.domain2.com. @ IN NS
srv.domain2.com. srv A 91.121.92.67 j\'ai pas fais de zone inverse.
quand je fais un : named-checkconf J\'obtiens /etc/bind/named.conf:68:
unknown option \'zone\' /etc/bind/named.conf:73: \'}\' expected near
end of file une idée ? -
alors la ponpon sur la garonne ! - GanGan -
Bonsoir
Il semble qu\'il manque un } à la fin de la définition
de votre zone
après sauf erreur ça devrait rouler ;-)
Bonne soirée
Fred
--
Lisez la FAQ de la liste
avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists [1] Vous pouvez aussi
ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:" To
UNSUBSCRIBE, email to [EMAIL PROTECTED] [2]
with a subject of "unsubscribe". Trouble? Contact
[EMAIL PROTECTED] [3]
-- Samuel SALSON. Bonjour
La zone inverse ne sert que dans le cas ou tu es toi même dns
inverse chez RIPE
Or tu es chez ovh et ovh le fait déjà donc ça
n'a aucun intérêt a moins qu'ovh te propose de mettre tes
DNS pour ton ip mais j'en doute.
De plus si ton IP a déjà un reverse, un 2ème ne
porterai qu'a confusion vu que le reverse est sensé
représenter le nom de la machine qui se présente et non
le nom de domaine sur lequel tourne l'application et se
récupère avec un "nslookup 91.121.92.67" par exemple. Un
seul nom sera visible même si tu en mets 10.
Voila comment ce
définie une zone
dans named.conf
zone "92.121.91.in-addr.arpa" {
type master;
file "/etc/bind/db.91.121.92";
};
et dans le fichier /etc/bind/db.91.121.92
$TTL604800
@ IN SOA srv.domain2.com. root.domain2.eu. (
1 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS srv.domain2.com.
67 IN PTRsrv.domain2.com.
Bonne journée
Fred
--
Samuel SALSON.
Links:
--
[1] mailto:[EMAIL PROTECTED]
[2] mailto:[EMAIL PROTECTED]
[3] mailto:[EMAIL PROTECTED]
Re: probleme de langue
Salut Luc, Am 2008-06-02 20:09:23, schrieb luc schimpf: et le résultat d'un locale -a : locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_MESSAGES to default locale: No such file or directory locale: Cannot set LC_COLLATE to default locale: No such file or directory C POSIX fr_FR.utf8 > Si j'en crois Michelle Konsack (j'espère ne pas écorché son nom), locale ^ z ;-) > est "case sensitive" et donc fr_FR.utf8 n'est pas bon et devrais être > fr_FR.UTF-8... mais où et comment modifier cela ? C'est exact, pour les UTILISATEURES, MAIS "locale -a" est correct aussi parce que il y un chose avec "glibc" (il etait sur le BTS et quelque temps passée) Thanks, Greetings and nice Day Michelle Konzack Systemadministrator 24V Electronic Engineer Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 +49/177/935194750, rue de Soultz MSN LinuxMichi +33/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: probleme de langue
alut Denis, Am 2008-06-02 21:13:31, schrieb Denis Barbier: > PS1: dans un autre message, votre fichier /etc/locale.gen laisse penser > que le paquet localeconf est installé, il faudrait le supprimer avec --purge > si c'est le cas. ??? > PS2: installez le paquet locales-all, vous aurez accès à toutes les locales. Tu croix, il veux installer plus de 100 Mo des locales? Thanks, Greetings and nice Day Michelle Konzack Systemadministrator 24V Electronic Engineer Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 +49/177/935194750, rue de Soultz MSN LinuxMichi +33/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: probleme de langue
Am 2008-06-02 19:02:39, schrieb [EMAIL PROTECTED]: > Je n'ai aucune mention de langues dans mon > "/home/antoine/.bash_profile" Moi aussi, mais dans le ~/.bashrc Thanks, Greetings and nice Day Michelle Konzack Systemadministrator 24V Electronic Engineer Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 +49/177/935194750, rue de Soultz MSN LinuxMichi +33/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: Démarrage illisible
Le mardi 03 juin 2008, Michel Grentzinger a écrit : > Le mardi 3 juin 2008, Sylvain Sauvage a écrit : > > Michel Grentzinger, lundi 2 juin 2008, 08:12:26 CEST > > [...] > > Ça semble bien venir d’un framebuffer. > > Tu as bien relancé lilo après avoir modifié lilo.conf ? > Oui, c'est fait ! > > Sinon, essaie avec vga=ask, il te permettra de choisir et de > > tester différents modes au démarrage. Tu pourras le fixer une > > fois le bon trouvé. > > J'ai trouvé que le paquet uplash était installé... Je vais le désinstaller > et je tiens la liste au courant. Comme pour grub, j'ai trouvé plusieurs configurations qui supportaient mal le vga=791, j'ai du les passer en vga=771 mes 2cents... si ça peut aider !?... ++ ;) -- "La connaissance s'acquiert par l'expérience, tout le reste n'est que de l'information." Albert Einstein -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/DebFrFrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:" To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Gagner de la place...
Le mercredi 04 juin 08 à 11:05, Xadawa a écrit : | Je suis en tarin de finaliser mon système sur carte CF de 512 Mo et je | viens de voir un joli répertoire /var/lib/apt/lists dans lequel sont | stockées toutes les listes de paquets... Puis-je le supprimer sans | aucune autre incidence que de ravoir a faire un aptitude update ? Bonjour, Aucun problème pour en supprimer le contenu. Quand j'avais mon système sur clé USB, j'avais même créé un montage (dans /etc/fstab) de type tmpfs, comme ça c'est stocké en RAM et ça évite d'utiliser les blocs mémoire du périphérique amovible pour stocker des données qui vont être supprimées. Seb -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/DebFrFrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:" To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Gagner de la place...
Je suis en tarin de finaliser mon système sur carte CF de 512 Mo et je viens de voir un joli répertoire /var/lib/apt/lists dans lequel sont stockées toutes les listes de paquets... Puis-je le supprimer sans aucune autre incidence que de ravoir a faire un aptitude update ? -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/DebFrFrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:" To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SSH derrière un pare-feu
Xadawa wrote: [snip] Ben l'uPnP est activé sur la plupart des routeurs, au pire je me vois mieux mettre dans la doc de la borne de cocher une case avec marqué uPnP en face dans l'interface du routeur plutot que de leurs faire ajouter des règles de NAT. sauf que uPnP n'a pas une super réputation question sécurité. un petit poste infecté et le routeur est reconfiguré à volonté. > J'ai bien tout compris ?? Si ce n'est pas le cas, on en revient à la solution tunnel. Il faut que la borne se connecte au serveur avec un port particulier (que tu peux éventuellement passer au serveur par la page php) : regardes du côté du tunnelling ssh avec ssh -R ... Et quand tu veux accéder à la borne, tu fais un ssh de ce port sur localhost. Yannick. L'inconvénient c'est que je ne veux pas laisser de tunnel ouvert 24/7. Ma véritable question été : J'ai bien tout compris ? quel paquet installer et quelle commande taper pour que l'uPnP se fasse automatiquement ? tu peux avoir un cron sur la borne qui tape sur une page de ton serveur et en fonction du résultat, ouvre le tunnel ou non. La borne sera inaccessible entre deux crons, mais c'est peut-être suffisant? Cela dit, en quoi est-ce genant d'avoir un tunnel constamment ouvert? sinon, la NAT est peut-être la meilleure solution. Inutile de compliquer une situation qui l'est déjà assez ;-p -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/DebFrFrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:" To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
