Mardi 12 mars à partir de 23h, nous avons lancé un passage à la version suivante de la distribution GNU/Linux (une Ubuntu pour l'hôte, des Debian pour les invités LXC) du serveur principal de LinuxFr.org, baptisé gruik. Tout s'est bien passé jusqu'au redémarrage.
Loi de Murphy
Après un certain temps, il a bien fallu en déduire que ce n'était pas juste un fsck qui s'éternisait mais bien un souci plus sérieux au démarrage. La console d'administration distante (carte DRAC (*)) ne nous a servi à rien non plus. Pas plus que le redémarrage électrique. Bref pas de ping, pas de réseau, rien, ni de l'extérieur, ni depuis le second serveur. Conclusion : perte des sites web de production et de test, et perte des listes de diffusion et du courriel @linuxfr.org en général.
(*) DRAC pas cher (intégré à la carte-mère), qui ne marche que quand le serveur va bien. Si le réseau tombe ou que GRUB boude, plus rien. En plus, sa redirection BIOS est mauvaise au possible…
Un problème n'arrivant jamais seul, la neige en Île de France a perturbé une intervention au datacenter hébergeant gruik.
« Protéger, Alerter, Secourir » : diffuser l'info donc
Nous avons utilisé les réseaux sociaux pour diffuser l'info sur G+, Twitter ou le salon xmpp ; malheureusement pas sur identi.ca qui a demandé une validation de l'adresse @linuxfr.org utilisée au moment où le serveur n'était pas disponible.
Grub, staying a larva
Hier soir, notre hébergeur (la fondation Free, merci à eux) a constaté un problème de grub au démarrage (dommage qu'Ubuntu masque la phase de démarrage ce qui nous aurait donné plus de détails…) et a pu remettre en ligne le serveur.
Quelques petites réflexions pour la suite
- nous allons mettre en place une solution de courriel sur le serveur secondaire pour les cas de panne qui comme chacun sait n'arrivent jamais.
- penser à redémarrer avec grub-reboot (choisir le noyau de démarrage pour le prochain redémarrage uniquement) lors d'une mise à jour, au cas où…
- ne pas faire planifier des mises à jour en cas de neige autour du datacenter
- trouver pourquoi/comment un noyau peut corrompre ses logs en mélangeant plusieurs lignes et en ajoutant/supprimant des caractères (genre kernel: 7377 t7r:oP urpst4he2icesdmndlan o70 sc<> 18150]C:he2icesdmndlan o120ncat 50ne)
- revoir la gestion des DNS
- etc.
# Logs
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10.
Votre problème avec les logs, c'est parce qu'avec LXC, il n'y a pas de séparation des logs du noyau. Si les syslogd de l'hôte et d'un ou plusieurs invités essaient d'accéder au log noyau, chacun en récupère un bout au petit bonheur, ce qui est très foireux.
Solution : dans les systèmes invités, désactivez le plugin klog de rsyslogd.
[^] # Re: Logs
Posté par ZeroHeure . Évalué à 2.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Logs
Posté par vazco . Évalué à 3.
Problème connu en effet :
https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1003888
[^] # Re: Logs
Posté par Maclag . Évalué à 10.
C'est malin de donner des explications techniques correctes comme ça d'entrée de jeu!
On est encore vendredi et j'espérais caser un troll avec systemd/journald!
---------------->[ ]
[^] # Re: Logs
Posté par Misc (site web personnel) . Évalué à 7.
Il est possible que journald corrige ce genre de souci avec les containers, quand ils sont démarrés avec systemd. Mais j'ai juste utilisé les containers pour faire joujou, pas pour des trucs en prod pour le moment.
Donc tu peux quand même lancer le troll, avec en plus une ouverture vers Ubuntu, ça pue, etc, etc.
[^] # Re: Logs
Posté par Krunch (site web personnel) . Évalué à 4.
Ça peut aussi arriver sans LXC quand le ring buffer dmesg se rempli plus vite qu'il ne se vide. Mais dans ce cas les corruptions sont généralement plus « propre » que l'exemple présenté.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# "corruption"
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
"7377 t7r:oP urpst4he2icesdmndlan o70 sc<> 18150]C:he2icesdmndlan o120ncat 50ne)"
La corruption de log est en théorie possible en cas de coupure de courant, le contenu mémoire peut se corrompre avant que l’électronique logique se rend compte du problème de chute de tension, et écrit n'importe quoi dans intervalle.
"La première sécurité est la liberté"
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
# Ubun.... QUOI ????
Posté par homer242 (site web personnel) . Évalué à 10.
Je rajouterais:
* ne pas utiliser Ubuntu
[^] # Re: Ubun.... QUOI ????
Posté par hitmanu . Évalué à 5.
Je rajouterais:
Merci aux personnes qui mon aidé a trouvé des solutions pour essayer d’écrire sans faute d’orthographe.
[^] # Re: Ubun.... QUOI ????
Posté par William Steve Applegate (site web personnel) . Évalué à 10. Dernière modification le 15 mars 2013 à 19:46.
Oui, enfin, la solution n'est jamais très loin. Après, je suis entièrement d'accord que masquer les messages d'amorçage (chargeur et noyau) est d'une stupidité sidérante, et encore plus sur un serveur, mais bon, changer les paramètres par défaut foireux, ça devrait être sur la checklist de l'admin.
Ce que je trouve plus inquiétant, c'est la carte DRAC « qui ne marche que quand le serveur va bien ». La carte DRAC, c'est justement censé être pour les cas vraiment casse-pieds où le soft est planté. Mon expérience se limite aux iDRAC 6 Enterprise de Dell (qui n'est pas le constructeur le plus flambant de la planète, pour faire un petit euphémisme) et elles permettent l'accès au BIOS/GRUB sans aucun problème (on peut même y coller une image disque et une ISO de Clonezilla pour la remonter), alors il n'y a aucune raison que les autres fassent moins bien. Rappelez-vous : la carte de supervision distante, comme le hot-spare dans votre RAID, c'est votre garantie de conserver au maximum votre capital-loutre© même en cas de panne au DC. Ne la négligez pas (c'était un message du Comité pour la Loutrification des Admins Système).
Envoyé depuis mon PDP 11/70
[^] # Re: Ubun.... QUOI ????
Posté par Nico C. . Évalué à 4.
Ben si justement…
Les "vraies" cartes DRAC (ou iLO, RSA, etc) sont des options pas données (plusieurs centaines d'€) alors il a ete developpé depuis qq annees des especes de peripheriques d'administration a distance integrés aux CM beaucoup moins chers (et souvent livrés de serie maintenant) mais qui ne sont quasiment d'aucune utilité en cas d'incident serieux. Ce genre de periph est fait pour l'admin au quotidien et c'est tout.
Donc si, c'est vachement moins moins mais c'est vachement moins cher aussi…
[^] # Re: Ubun.... QUOI ????
Posté par William Steve Applegate (site web personnel) . Évalué à 5.
Dans le prix d'un serveur, ça se discute : 300 brouzoufs de plus sur une machine qui en coûte 2000 au bas mot, ça n'explose pas le budget.
Ah oui, les cartes IPMI. J'ai vu ces trucs (sur des serveurs bas de gamme), j'ai pas non plus compris l'intérêt.
Seulement en apparence. Parce que le temps que l'admin perd à courir rafistoler les serveurs en vrac, ça se paie aussi…
Envoyé depuis mon PDP 11/70
[^] # Re: Ubun.... QUOI ????
Posté par Zenitram (site web personnel) . Évalué à 5.
J'es profite pour poser une question qui me taraude : des carte genre ça, avec "IPMI 2.0 with virtual media over LAN and KVM-over-LAN support", c'est pareillement foireux? Ou est-ce le truc "en pub", accéder à un serveur vierge, planté etc… Parce que la, clairement, j'ai du mal à suivre l'interêt d'un DRAC inaccessible si on a planté GRUB.
Après, je me demande si c'est plus mieux bien qu'un DRAC software pour accéder au BIOS avec un boot réseau par défaut genre le rescue d'OVH ou Dedibox, pour moins cher peut-être.
Le problème avec les bénévoles, c'est que le prix, si ils sont dispos, est de 0€ de l'heure. Et tant qu'il y aura des bénévoles, cette phrase n'est pas forcément vraie. Moralité : les bénévoles font chuter les prix (troll inside)
[^] # Re: Ubun.... QUOI ????
Posté par Anonyme . Évalué à 4.
Moi aussi tiens : c’est quoi cette bouteille de lait ?
Plus sérieusement, où peut-on trouver un état de l’art, une explication clair de ce que sont IPMI, DRAC, ILO, etc. et comment ils se comportent les uns vis à vis des autres ?
Parce que, bien qu’étant admin sys, je n’ai jamais eu à toucher à ces choses là et j’aimerai bien qu’un pan entier de mon travail ne m’échappe pas trop.
[^] # Re: Ubun.... QUOI ????
Posté par Nicolas Ecarnot (site web personnel) . Évalué à 3.
En tant que sysadmin qui utilise des DRAC et des iLO à longueur de journée, je n'avais même pas conscience qu'il existait des solutions au rabais.
Perso, j'utilise entre autre mes DRAC pour ALLUMER ÉLECTRIQUEMENT mes serveurs.
Donc leur état logiciel, planté ou non, ou grub en carafe, ou même s'il n'ont pas de disque dur, vous savez, je m'en bats les coudes.
J'utilise aussi mes DRAC pour upgrader les BIOS. Donc idem, lorsque je les utilise, l'OS n'est même pas encore installé.
Tout l'intérêt de ce genre de matos est précisément de déporter écran+clavier+souris via le réseau, majoritairement en mode web. Comme il a été dit, on peut également monter des périphériques genre usb, boot cdrom, flash drive, etc… et ainsi installer/réparer un OS.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 9.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Ubun.... QUOI ????
Posté par SalvadorDalek . Évalué à 1.
Tu as oublié le principal pour les admins linux: le port série virtuel, le mode texte via ssh, le RIBCL, …
Les iLo, c'est sympa avec des zimages qui bougent dans le navigateur dans un applet java ou .Net, mais là où ça devient vraiment intéressant, c'est quand on peut les manipuler en mode texte… fini les accidents de mapping clavier (plus de risque d'avoir un mdp complexe qui ne passe pas), le copier/coller devient possible si le logiciel terminal ssh le supporte, … Et pour l'automatisation, il y a le RIBCL qui permet de manipuler programmatiquement, via une sorte de webservice, la configuration de la carte ilo et du serveur lui étant lié. Au taf, on a par exemple développé des plugins nagios qui interagissent avec les iLO en RIBCL pour collecter les alertes hardware et des métriques, et on a également un système qui permet de déployer des serveurs sans avoir besoin de DHCP ou de PXE, en utilisant le virtual cdrom et des isos générée à la volée, toujours basé sur RIBCL.
[^] # Re: Ubun.... QUOI ????
Posté par Nico C. . Évalué à 4.
Les DRAC, iLO et autres RSA sont peu ou prou des denominations commerciales pour designer la meme chose : un peripherique autonome integré au serveur pour le piloter a distance comme si tu etais devant l'ecran avec un vrai clavier physique.
Quand c'est un "vrai" DRAC, tu peux meme demarrer electriquement ton serveur a distance et observer les tout premiers messages de la console. Tant qu'une alim est branchee a l'electricité, tu as acces a la "carte" DRAC et tu peux faire tout ce que tu veux a distance.
Apres, y'a d'autres fonctionnalités comme l'inventaire materiel, le monitoring hardware d'assez bas niveau, la virtualisation du lecteur optique, des ports USB, MAJ de firmwares, etc
Tu as une console web sur laquelle tu te connectes via le reseau et tu y fais tout directement.
A ma connaissance, IPMI est un protocole pour se connecter a ces "cartes" via une grosse console centralisée. Perso, j'utilise pas.
Concretement, c'est pas un truc qu'on utilise quotidiennement. Enfin ca depend de ton job et ta specialisation, en fait.
Perso, j'utilise ca juste pour demarrer des serveurs ou quand y'a un prob hard. Et ca arrive pas tous les 4 matins.
[^] # Re: Ubun.... QUOI ????
Posté par jolitorax . Évalué à 9.
Le DRAC, comme précisé dans les commentaires, c'est la dénomination commerciale d'une carte de contrôle à distance chez Dell. Comprendre ce que l'on peut ou ne peut pas faire avec une carte DRAC chez Dell relève un peu du parcours du combattant, puisque ça varie avec les modèles de serveurs. Sous la dénomination commerciale DRAC, la carte utilise IPMI.
Les cartes DRAC Express livrés avec les serveurs Dell (gratuitement désormais) permettent de remonter l'état du matériel et de faire un on/off. Utile pour un plantage simple, qu'un reboot (violent) peut dépanner, mais très limité dans les actions. Il n'y a pas de console VNC.
Les cartes DRAC payantes Entreprise, permettent d'avoir une console VNC sur le serveur et pas mal d'autres choses comme l'a détaillé vsin https://linuxfr.org/nodes/97686/comments/1437183. Elles peuvent remplacer dans l'usage un KVM IP.
Pour voir ce que fait IPMI, il suffit d'installer sur votre pingouin favori le paquet ipmitool. C'est assez simple d'utilisation et étant donné que c'est standardisé, il n'y a pas que les serveurs Dell qui répondent aux commandes ipmi.
Je ne suis pas allé bien loin dans l'utilisation d'ipmitool. Je l'ai juste utilisé pour remonter des valeurs sur le matériel, comme le ferait lm-sensors, en particulier les valeurs de température d'entrée d'air en façade sur un serveur et un bilan de sa consommation électrique grâce aux options ipmitool delloem.
Il est possible d'aller beaucoup plus loin, comme faire rebooter le serveur en PXE ou sur un media alternatif, directement au niveau de l'interface DRAC, donc sans OS fonctionnel. Sous réserve que la carte DRAC ou autre comprenne ces commandes IPMI.
[^] # Re: Ubun.... QUOI ????
Posté par Anonyme . Évalué à 3.
Ok, je commence à comprendre un peu mieux. Merci pour vos explications (le commentaire du dessus aussi).
Concernant IPMI, c’est une norme respectée où il y a toujours une part de proprio chez chaque constructeur ?
[^] # Re: Ubun.... QUOI ????
Posté par Hobgoblins Master (Mastodon) . Évalué à 5.
À savoir qu’il est quand même possible de prendre la main sur un serveur Dell avec une carte DRAC Express intégrée grâce au Serial Over LAN (SOL faisant partie de la norme IPMI).
Il faut :
Ensuite, on peut se connecter avec ipmiconsole (paquet freeipmi). Certaines cartes plus récentes sont aussi accessibles en ssh ou https et permettent l’accès au SOL via ces interfaces.
C’est minimal, mais ça permet de bosser sur le RAID, d’accéder à un Unix dont le réseau est planté (ou au moins de voir les messages consoles) et de booter en PXE.
[^] # Re: Ubun.... QUOI ????
Posté par ashgan . Évalué à 10.
En meme temps, selon l'adage bien connu: "a serveur donne, on ne regarde pas la carte DRAC"
:-)
[^] # Re: Ubun.... QUOI ????
Posté par zx81 . Évalué à 2.
J'ai acheté en 2007 puis en 2009 des serveurs Transtec (avec une carte mère Supermicro), la carte IPMI coutait moins de 100€ ht
et se comportait comme convenu càd bête accès en https (on/off distant, infos capteurs température, log du bios, et bien sur
KVM (via applet java)). Faut juste la jvm de sun (pour le kvm), ça marche pas avec openjdk sous debian…
Voir par exemple (serveur pris au pif dans leur liste…):
http://shop.transtec.fr/F/F/products/server/infrastructure_server.html?mod=prod&name=SI1167T302S&disp=config
rubrique "system management"
ps: je n'ai pas de lien avec transtec ;-)
[^] # Re: Ubun.... QUOI ????
Posté par Zenitram (site web personnel) . Évalué à 2. Dernière modification le 16 mars 2013 à 17:25.
Merci pour le retour.
Les cartes IPMI ont l'air d'être intégrées de plus en plus aux carte-mères Supermicro, faudra un jour que je m'amuse à ça à mon temps perdu, l'idée (dans mes 36 projets à faire dans les 36 prochaines années, j'ai le temps :) ) étant d'envoyer la chose à 20 000 km de distance, planter logiciellement un serveur (ça arrive souvent quand même) et intervenir pour autre chose que du HW n'est pas des plus fun (les personnes sur places étant des techs de base, ils font généralement du remplacement HW et rien d'autre), et ILO c'est cher :).
[^] # Re: Ubun.... QUOI ????
Posté par MTux . Évalué à 0.
Il y a du bon et du pas bon dans ubuntu server.
Mais ça reste la solution la plus simple pour faire tourner des containers LXC.
[^] # Re: Ubun.... QUOI ????
Posté par GeneralZod . Évalué à 10.
C'est tout aussi simple sous Debian et c'est eux qui ont fait le gros du boulot (rendons à César ce qui est à César) et c'est un poil plus léger et stable qu'Ubuntu Server.
Pour être honnête, openSUSE a fait un très bon boulot d'intégration également de LXC qui vaut largement Debian/Ubuntu (avec intégration dans YAST), sous Fedora le userland LXC est régulièrement pété (d'une part à cause des lennarteries - systemd et LXC reposent fortement sur cgroups, quelques interactions foireuses-, d'autre part, le paquet est pas à jour)
[^] # Re: Ubun.... QUOI ????
Posté par MTux . Évalué à 2.
Leurs templates ne marchent pas sous Wheezy (rapport de bug déposé).
Et sous Squeeze je me suis laissé dire qu'il fallait taper dans les backports.
[^] # Re: Ubun.... QUOI ????
Posté par Misc (site web personnel) . Évalué à 2.
Sur Fedora, j'aurais tendance à plutot prendre les containers avec systemd : https://fedoraproject.org/wiki/Features/Securecontainers
C'est encore jeune mais parfaitement utilisable.
Ensuite, je pense que Ubuntu propose quand même pas mal de trucs autour de LXC ( https://www.stgraber.org/2012/05/04/lxc-in-ubuntu-12-04-lts/ ).
[^] # Re: Ubun.... QUOI ????
Posté par MTux . Évalué à 1.
Mon point aussi c'est de savoir s'il y a un argument solide pour dénigrer ubuntu server, ou si c'est juste une mode.
[^] # Re: Ubun.... QUOI ????
Posté par Kerro . Évalué à 3.
Ubuntu fonctionne très bien. En serveur ou pas.
… jusqu'à ce que tu décides de faire un upgrade.
Donc clairement c'est une mauvaise idée pour les serveurs que tu ne souhaites pas réinstaller tous les 3 ans.
[^] # Re: Ubun.... QUOI ????
Posté par MTux . Évalué à 2.
Encore une fois aucun élément technique n'est apporté.
Je l'utilise depuis 1 an, et mis à part le fait qu'il y a trop de mises à jour du kernel à mon goût, ça tourne plutôt bien.
[^] # Re: Ubun.... QUOI ????
Posté par Kerro . Évalué à 2.
En un an tu n'as fais que des updates, pas des upgrades.
En gros tu es bloqué avec une version donnée. Sauf si tu n'utilises presque rien dessus, dans ce cas n'importe quelle distribution convient.
[^] # Re: Ubun.... QUOI ????
Posté par MTux . Évalué à 0.
C'est un point intéressant.
[^] # Re: Ubun.... QUOI ????
Posté par xcomcmdr . Évalué à 1.
C'est 5 ans depuis la 12.04.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Ubun.... QUOI ????
Posté par GeneralZod . Évalué à 2.
où tu as vu que je dénigrais Ubuntu Server ? Je mettais en valeur le fait que Debian gérait aussi très bien LXC (au passage, la plupart des personnes qui utilisent Ubuntu Server serait tout aussi bien servi par Debian, voire mieux).
Et tu noteras que j'ai aussi pointé du doigt le support foireux dans Fedora.
[^] # Re: Ubun.... QUOI ????
Posté par claudex . Évalué à 3.
Il y a plusieurs réponses à pourquoi Ubuntu et pas Debian pour l'hôte https://linuxfr.org/news/migration-linuxfrorg-termin%C3%A9e#comment-1253143
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# Idées en vrac
Posté par Kioob (site web personnel) . Évalué à 10.
Hello,
quelques autres idées, en vrac :
- y avait pas moyen d'avoir recours à un système de «rescue» que Free utilise justement sur des dédibox/online ? (c'est à dire reboot électrique en PXE sur une image live)
- puisque vous avez deux machines, pourquoi ne pas coller du DRBD entre les deux, afin de ne plus dépendre qu'une seule machine ?
Évidemment, ça semble toujours facile après coup, mais je suis quand même surpris qu'en l'état tout repose sur une unique machine.
En tous cas, content de revoir le site, j'ai failli me faire un claquage à devoir me mettre à bosser si brutalement !
alf.life
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
# tribune
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
La plupart des grands fans de linuxfr étant dans la moulosphère, pourquoi ne pas avoir fait une communication officielle sur la tribune de http://euromussels.eu/ (par exemple) plutôt que sur des bases de données sociales privatrices ?
En tout cas bravo pour ce rétablissement rapide malgré la neige!
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
# Savoir si un site est inaccessible.
Posté par Sylvain Blandel . Évalué à 1.
Je n'arrive pas à accéder à un site internet !
Est-ce ma connexion qui est défaillante, ou bien le site est-il inaccessible ?
Pour le savoir : Down for everyone or just me ?
[^] # Re: Savoir si un site est inaccessible.
Posté par ariasuni . Évalué à 1.
Sinon, je suppose que ça doit être facile à faire en PHP, faudrait que j'étudie ça plus en détails.
Solution alternative: accès SSH sur une autre machine.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Savoir si un site est inaccessible.
Posté par bobble bubble . Évalué à -1.
[^] # Re: Savoir si un site est inaccessible.
Posté par ariasuni . Évalué à -2. Dernière modification le 17 mars 2013 à 13:24.
La métonymie c'est bien beau, mais après on ne sait pas faire la différence entre l'internet et le web. Tu me diras c'est pas super important. Ou peut-être que si.
Je veux pouvoir envoyer des courriels en dehors du web, clavarder en dehors du web, etc, mais via internet.
Sinon, systemd fonctionne chez moi™ (histoire vraie). Il fait même le café (mais j'aime pas le café).
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Savoir si un site est inaccessible.
Posté par barmic . Évalué à 2.
La question c'est qu'est ce qu'un site qui ne serait pas web ? L'aurais-tu repris s'il avait juste écrit « site » ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Savoir si un site est inaccessible.
Posté par ariasuni . Évalué à -1.
ftp.truc.fr est un site FTP, non? Et un site internet serait un site web/ftp/imap etc.
Et puis bon, flemme d'attendre vendredi hein! ;)
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Savoir si un site est inaccessible.
Posté par barmic . Évalué à -2. Dernière modification le 17 mars 2013 à 16:56.
Jamais entendu parler de site FTP, je sais pas si ça viens de mon entourage ou pas.
Ouai tu fais comment la liste ? Tu prend tout ceux défini par l'IETF en retirant les obsolètes ? Quel intérêt ?
Personnellement je différencie surtout un site internet d'un site intranet.
Mais si la question t'intéresse, je te conseil d'aller prêcher la bonne parole sur wikipedia où Site Internet redirige vers site web. Si comme tu le dis c'est important c'est d'autant plus important sur wikipedia que dans un commentaire ici.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Savoir si un site est inaccessible.
Posté par ariasuni . Évalué à 0.
Disons que ça pourrait s'appeler un site FTP.
Sinon on pourrait définir un site internet par un nom de domaine et accessible depuis internet, un site web par un nom de domaine et accessible depuis le web.
Après, dire «aller sur internet» est plus «grave», puisque l'on confond littéralement internet et le web. Mais si on assimile «site internet» à «site web», pas étonnant que l'on fasse la confusion. CQFD.
Tout ça pour dire que confondre internet et web, on peut penser que c'est pas si grave, mais en fait si. Combien d'opérateurs mobiles fournissent du web (sans P2P et Usenet par exemple) en clamant haut et fort que c'est de l'«internet illimité» (qui n'est d'ailleurs pas un accès illimité, mais bon ToS;DR…)
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Savoir si un site est inaccessible.
Posté par bobble bubble . Évalué à -1.
On peut dire que ça s'appelle un site ftp, et, par métonymie, un site internet, même si ça choque parce qu'on a moins l'habitude
:D de la théorie des ensembles…
Par contre, des opérateurs qui vendent du "web" en l'appelant de l'"internet", là ce n'est plus une figure de style poétique, c'est de l'escroquerie
[^] # Re: Savoir si un site est inaccessible.
Posté par ariasuni . Évalué à -1. Dernière modification le 17 mars 2013 à 22:32.
Enfin bref, mon propos c'est: confondre. web et internet ça peut nous porter préjudice dans le futur (si ça n'est pas déjà le cas).
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Savoir si un site est inaccessible.
Posté par barmic . Évalué à 2.
J'ai bien compris, mais vouloir jouer au plus malin en reprenant quelqu'un qui dit navigateur internet pour parler d'un navigateur http(s), ftp(s), sftp qui faisait du gopher il n'y a encore pas si longtemps et qui fait du spdy. Je suis d'accord qu'il faut plutôt dire web, mais ça donne plus l'impression de juste chercher à faire du bruit qu'à faire avancer les choses avec les fournisseurs d'accès au réseau.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Savoir si un site est inaccessible.
Posté par ariasuni . Évalué à 1.
Ok donc je reprend:
Site internet ça fait référence à site web (en général). l'Usage principal d'un navigateur web est de naviguer sur des sites web, et visiter ce que l'on pourrait appeler des sites FTP n'est qu'un usage très secondaire.
On devrait donc utiliser web, et pas internet, et avec uniquement le protocole IP tu fais pas grand chose (c'est comme GNU/Linux: sans GNU tu peux pas faire grand chose).
Alors bien sûr on peut justifier ça par métonymie, mais après faut pas s'étonner que des fournisseurs d'accès internet nous offrent simplement l'«envoi de lettres» en nous promettant la «poste» illimitée…
Je ne fais pas que pinailler, j'essaie de combattre la novlangue à mon niveau…
Écrit en Bépo selon l’orthographe de 1990
# annoncer l'outage
Posté par Krunch (site web personnel) . Évalué à 5.
En tant que pas utilisateur de Google Plus, Twitter ou XMPP, je trouve qu'il aurait été Bien de rediriger linuxfr.org vers une bête page expliquant la situation (pas forcément en détails).
D'après ce que je vois, les entrées DNS de DLFP sont servies par xname et heberge.info. La résolution de nom fonctionnait donc sans doute lors du problème. En admettant qu'il ait été possible mettre en place une page statique quelque part, mettre à jour le record DNS pour pointer vers celle-ci en attendant que la neige fonde ne me semble pas trop compliqué et aurait permis de garder les vieux cons au courant.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: annoncer l'outage
Posté par Sufflope (site web personnel) . Évalué à 6.
Lis le point revoir la gestion des DNS.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.