Reprise du message précédent :

Ah comme chez moi quoi

Mon super serveur sous debian wheezy tout neuf plante si je veux le rebooter après qu'il mette l'affichage en veille sous X.  
 
Pratique
 
Plus qu'a prier qu'en disablant le démarrage du service et en restant en CLI j'ai pas ce problème.

Idem chez moi c'est du PTT 299 voire pire, ya même pas moyen de balancer du 100mb/s dedans, c'est tout pourri. j'ai donc acheté 40m de Cat 6a et mis des goulottes plastique le long des plaintes en mode rien à battre

Tout pareil

et l'operateur qui te propose la TV uniquement sur la fibre, il a pas une offre internet? il est pas censé etre en obligation legale de laisser passer les operateurs avec la politique de fibrage verticale en france ?

pourquoi est-ce que les lusers, dès qu'ils ont un problème vaguement réseau, suspectent toujours en premier un problème de DNS, même si aucun élément ne va dans ce sens ?

Les luers ne savent pas ce qu'est un DNS ici.
 
Ici les lusers répondent au tel et font des mails

 
ah mais ici non plus (pour la plupart), justement  

Je vois mal mes susers qui sont principalement des opérateurs aux téléphones me parler de DNS

Ils ont sans doute du entendre un jour le terme en liaison avec un problème vaguement similaire (au moins dans leur esprit), ils l'ont retenu, et le ressortent en pensant se rendre utile et/ou intéressant : c'est pas un grand mystère
 
Y'a une époque chez moi ou un mec avec eu des soucis d'accès à un site à cause d'un certificat expiré, dans les mois qui suivent à son étage t'avais souvent droit à un "c'est peut-être un problème de certificat comme Berthier" a chaque problème touchant vaguement un site ou une appli web

ouais c'est ce que je suppose aussi... j'espère que je suis pas comme ça à mon insu quand j'ai un problème dans un domaine que je connais pas  

Parce que ça doit être un trucs mit en avant dans les navigateurs quand ça marche pas
Genre : "la résolution du nom de domaine n'a pas pu être effectué : vérifiez votre serveur DNS." Un truc du genre

edit:
(bon la c'est un peu naze comme exemple vu le ndd )

XaT

tu parles, les navigateurs c'est de pire en pire j'ai l'impression, c'est de plus en plus "ça marche pas, un problème est survenu mais on vous dira pas lequel, t'façon vous êtes trop neuneu pour comprendre"

ah ben toi tu as encore un truc assez explicite, mais alors sous IE les dernières version j'ai l'impression que c'est la catastrophe...

Bah la je suis étonné du commentaire (Chrome v40)
 
XaT

Sinon en simulant un cable mal branché :

Pas très probant

XaT

 
ouais exactement comme a la grande epoque du virus, on avait droit à "ca doit etre un virus" au moindre probleme informatique

la grande epoque,
 
pour certains (voir bcp de) users, c'est encore d'actualité hein!
 

question exchange 2010/outlook2013.
 
 
On peut tjrs pas afficher la liste d'adresse globale dans l’arborescence d'Outlook??

RF Overlay. Dans cette architecture, tu as 2 fibres qui arrivent chez toi :
- Une pour l'internet, data (ethernet ou tout ce que tu veux), du signal numérique classique en full duplex sur 2 longueurs d'onde distinctes.
- Une dédiée pour le broadcast TV, où les chaînes sont diffusées en analogique sur la fibre.
C'est exactement comme du cable-TV, sauf que le media de base c'est de la fibre, pas du cable coax. Le module RF-Overlay fait simplement la conversion Fibre vers coax. Tu branches un récepteur DVB-C derrière et ça roule. Du coup, ya pas de channel upstream sur cette fibre, donc pas d'internet possible dessus

Enfin une explication claire qu'on ne trouve pas sur le net dans les première pages    
 
Pour la fibre data (monobrin je suppose), les 2 longueurs distinctes, c'est bien une pour le down et une pour le up ?

Oui exactement Tu mets un SFP "D" (downlink) d'un côté de la fibre (par exemple le SFP intégré d'un modem fibre), et un SFP "U" (uplink) de l'autre côté, dans le switch.  
Par exemple un GLC-FE-100BX-D et un GLC-FE-100BX-U, l'un émet à 1310nm et reçoit à 1550nm, et l'autre fait l'inverse, il émet à 1550nm et reçoit à 1310nm.

Ok, j'ai toujours cru jusqu'à présent que c'était du half pour le monobrin  

même en utilisant une seule fréquence on peut faire du full duplex dans un seul brin, mais je crois que c'est peu utilisé comme technique.

Tu parles de multiplexage "OAM" ?
http://en.wikipedia.org/wiki/Orbit [...] ber_system

oulà non plutôt d'un bête circulateur. Donc ça permet d'avoir juste un canal full duplex sur un brin et une longueur d'onde, pas de multiplexage de n canaux.  
 
Je connaissais pas l'OAM, avec la description du wiki on dirait un truc sorti de l'USS Enterprise

Multiplexage On A Merdé?
A+,

 
Tu ne sais même plus si c'est du 4xx ou du 5xx, c'est bien pratique  

est-ce que déjà ça fait même encore la différence entre erreur client et erreur serveur ? je suis même pas sûr  

Putain ça marche un peu quand ça veut en fait duplicity. Le process bloquait après un court début de fonctionnement, avant de commencer à bosser pour de vrai. Un reboot et c'est reparti. Et les nsa310s, ptain la merde.
 
Et macos X pour avoir un pauvre raccourci des montages "propres" des shares, que ça soit du 10.6.x que du 10.8.5, ptain la misère cette OS...    
 
j'ai même pas trouvé pour avoir les shares sur le bureau sous 10.6.x. sous 10.8.5, ça génère des doublons d'entrées dans le finder si on mappe monte le share au démarrage mais qu'on le démonte/remonte accidentellement après, très joli. Sur certains postes suffit que je clique sur le share pour qu'il le monte sur le bureau, sur d'autres en 10.8.5 pareil, non ça veut rien savoir, ça se comporte comme une 10.6.x
 
OS à la con...

Quels opérateurs font ça?

remplacement de firewall d'un cluster aujourd'hui, on en a reçu un neuf de remplacement, je l'ai configuré d'après la procédure donnée par le fournisseur, hier il m'appelle pour savoir pour quand le remplacement est prévu et dire qu'on n'hésite pas à l'appeler en cas de problème, aujourd'hui je mets le nouveau en prod mais ça bloque sur une erreur à la con, j'appelle le fournisseur... le mec est en formation toute la journée. Ce foutage de gueule  

Je connaissais pas

Ceux qui viennent historiquement du câble et migrent progressivement vers la fibre par exemple, ou ceux qui peuvent s'appuyer sur un réseau câblé existant (et performant) pour broadcaster ces chaines.
S'appuyer sur le câble (ou une fibre dédiée TV) pour diffuser tes chaines en broadcast ça te permet de t'affranchir de faire du multicast sur ton réseau IP "internet" (le réseau data sur fibre, ou même DSL si t'as envie), donc d'économiser de la bande passante. En parallèle, la configuration de tes équipements IP chez le client (son modem ou son routeur) est la même, avec ou sans les chaines TV.
Ça te permet une transition plus douce avant de passer en tout-IP pour la diffusion, et donc d'acheter progressivement le matos FTTH dimensionné correctement pour passer à la fois tes flux data internet/voip et tes flux multicast.

Imagine un réseau qui vend des abonnements fibre à 100Mbit/s. 20 clients sur le même POP, ça te fait 2Gbps en pointe, ce qui n'arrivera jamais en réalité à moins de faire un benchmark internet avec tous tes copains du même quartier , mais t'as quand même largement de quoi remplir un tuyau à 1Gbps. Le switch du POP en question, il a intérêt à avoir un uplink costaud vers le backbone donc, si tu veux tenir ta parole de fournir à tes clients du "vrai" 100Mbps et pas seulement à 4h du matin quand tout le monde dort
Maintenant, rajoute des chaines TV envoyées en multicast :
1 chaine en SD c'est environ 2-3Mbps. 1 chaine en HD c'est dans les 10-13Mbps. On part du principe que tu fais de l'IGMP hein, tu bourres pas tes 200 chaines dans chaque switch de quartier sinon t'es mort avant même de faire de l'accès Internet L'avantage du multicast c'est que si 2 clients sur le même switch demandent la même chaine, tu n'enverras qu'une seule fois la chaine vers le switch, et le switch se chargera de dupliquer la chaine sur les ports => économie de débit depuis le backbone.
Avec un bouquet TV sympa, la probabilité que tu aies plusieurs clients qui regardent des chaines différentes en même temps est quand même assez grande, disons encore tes 10 clients qui regardent des chaines HD différentes : 100-130Mbps priorisés en QoS qui vont te bouffer de la bande passante sur ton lien backbone-POP. Idem s'il y en a un qui fait du replay ou de la VOD, ça te fait un flux unicast en download, de la même taille qu'une chaine TV, et priorisé en QoS. Ca veut dire que plus tu as de clients TV, moins t'as de BP internet car la TV/VOD/replay ça passe devant. La téléphonie VoIP j'en parle pas car ça se compte en Kbps.

Mais bref, lancer une offre FTTH qui tient la route avec des abonnements sympa pour rivaliser avec la concurrence, ça nécessite d'investir pas mal, que ce soit les switches, les SFP, les fibres, et le génie civil pour faire passer tout ça. S'appuyer sur un réseau de broadcast (fibre ou câble) pour décharger ton réseau IP, ça te permet d'étaler tes coûts et te laisser respirer (ou agrandir ta couverture ! ) en attendant d'investir encore plus dans ton réseau IP pur. Ça te permet aussi de séparer les services et de péter l'internet sans faire sauter la TV ou vice-versa
Tout ça sans changer ton récepteur TV DVB côté client / laisser la compatibilité avec les tuners embarqués dans les TV (pour les chaines diffusées en clair, pas cryptées), donc encore des coûts économisés, avant de déployer une nouvelle box TV ethernet sans tuner DVB.

Une autre approche c'est pour la transition Câble vers FTTH :
Avec les abonnements Internet qui augmentent toujours + en débit, côté câble on arrive en limite de bande passante pour DOCSIS. Du coup, si tu veux libérer plus de fréquences sur ton câble pour rajouter des canaux DOCSIS, tu peux vouloir supprimer tes chaînes du câble et les balancer sur de la fibre que tu viens de tirer dans un quartier. Ce quartier dispose alors de + de vitesse sur le câble. Et quand ton client il veut quitter le câble et passer sur un abonnement fibre (quand toi t'es prêt dans ton infra, et que t'as lancé le produit commercialement), il a juste à changer son modem, le connecter sur la fibre Internet déjà tirée en même temps que la TV (quitte à faire des trous dans les murs, autant en passer quelques-unes ), et roule poussin. Dans ce cas tu investis simultanément dans ta diffusion de chaines et dans ton infra FTTH, mais tu gardes les flux TV broadcast séparés de tes flux data, ce qui te permet de décharger le réseau data.

Une dernière approche, c'est que balancer du signal sur fibre ça va vachement loin sans perturbation, beaucoup plus loin et de meilleure qualité qu'un réseau DVB câble réamplifié régulièrement en chemin. C'est déjà ce qui se passe pour les centraux DOCSIS de quartier, les amplis HF de quartier communiquent sur des liens fibre (analogiques, pas ethernet/IP) avec le CMTS central, c'est pas du câble de bout en bout depuis le CMTS jusqu'à ta maison. Du coup ya peut-être moyen d'atteindre quelques bleds isolés avec ce genre de signaux, quand tu tires la fibre jusque là bas, sans forcément investir dans le réseau IP qui va avec pour le moment, ou ne jamais investir dedans si c'est pas rentable, mais au moins tu t'affranchis te plein de contraintes liées au câble que t'as pas sur de la fibre.

Oala, ce sont des use-cases, c'est pas exhaustif, mais ça peut illustrer quelques scénarios mettant ça en oeuvre

Merci msieur pour ces précisions, ça se voit que t'es du métier toi

 
D'où le Gpon avec un taux de mutu à 200%.

Quelqu'un a déjà vécu une valeur de DNS qui n'arrive pas à se propager ?
En gros : site d'un client sur hébergeur A (IP : xxx.xxx.xxx.xxx)
entrée DNS : @ A xxx.xxx.xxx.xxx
Nouveau site, hébergeur B (différent de A), IP : yyy.yyy.yyy.yyy)
je modifie chez enom.com (le client a acheté son domaine chez Google), je modifie la table @ A yyy.yyy.yyy.yyy
J'attends quelques minutes/heures, et je vois bien le nouveau site
48h plus tard, je retombe sur l'ancien site
je fais un check de la propagation, je vois que les FAI français ont remis l'ancienne IP
Le reste du monde est avec la nouvelle.
Puis 2 heures plus tard, je revois le nouveau site
24h on passé, et rebelotte, je vois l'ancien site.
 
Bref, des avis avant que je dise au client de jarter enom.com et de racheter son domaine pour le gérer directement chez son hébergeur B ?

Le transfère d'un .com est gratos. fait ça.

regarde régulièrement sur le serveur faisant autorité sur ton nom (chez enom.com) si la valeur du champs A change ou reste stable (et quel est son TTL), ça te donnera peut-être déjà une idée de sur qui taper en premier.

dig +short NS <ton_domaine>
puis tu prends le resultat et tu fais :
dig @<resultat> +norecurse <le_nom_de_ton_site>

sous windows je sais pas comment on fait

Je suis sur Mac, donc terminal Unix
 
Le problème d'Enom, c'est que le client a acheté ça via Google Apps, et que donc on a un truc "très limité"
 
Je n'ai que "ça".

 
Un dig +short NS domain.tld me rends : dns2.name-services.com. (TTL 1800s)
(enfin yen a 5 :  
dns2.name-services.com.
dns5.name-services.com.
dns3.name-services.com.
dns1.name-services.com.
dns4.name-services.com.
)
 
 
Et un dig @res +norecurse domain.tld me renvoie la bonne IP
 
Là, j'ai ça dans mon suivi :

 
Mais genre cet aprem, j'avais les serveur Fr sur la vieille IP
pourtant samedi, tout était OK

quand tu dis les serveurs fr c'est quoi, les résolveurs des principaux FAI ? si c'est ça faut pas chercher plus loin, ils prennent souvent certaines libertés avec les TTL.

Ah oui les Fai français c'est 72H mini

Dans ton truc pour vérifier ya pas les root ?