GuiGui's Show

Un excellent article, avec des photos, qui nous parle des câbles sous-marins qui transportent Internet (et toutes nos communications en général), des stations d'atterrissement de ces câbles, des datacenters où sont installés les ordinateurs des opérateurs réseau et des fournisseurs de services ainsi que des quelques réseaux de distribution qui amènent le Ternet dans le logement de tout un chacun. Bref, on aperçoit le côté très matériel d'Internet que l'on oublie souvent. Je recommande vivement la lecture de cet article.

Quelques ressources complémentaires :

• http://shaarli.guiguishow.info/?9kAT1g : compte-rendu d'une émission de radio dans laquelle étaient évoqués le financement des câbles sous-marins, les enjeux géopolitiques de ces câbles, les consortiums qui sont derrière leur installation et leur exploitation, etc ;
  
  
• http://www.bortzmeyer.org/tubes.html : compte-rendu de lecture du livre « Tubes: A journey to the center of the Internet » qui s'attache aussi à présenter l'aspect physique, matériel, concret d'Internet.

[...]

But how does it work? Have you ever thought about how that cat picture actually gets from a server in Oregon to your PC in London? We’re not simply talking about the wonders of TCP/IP or pervasive Wi-Fi hotspots, though those are vitally important as well. No, we’re talking about the big infrastructure: the huge submarine cables, the vast landing sites and data centres with their massively redundant power systems, and the elephantine, labyrinthine last-mile networks that actually hook billions of us to the Internet.

[...]

The secret world of cable landing sites

[...] Providing an Internet service goes beyond the mere capabilities of a single ISP on this sceptred isle or, indeed, the capabilities of any single ISP anywhere in the world.

First we’re going to take a rare look at one of the most unusual and interesting strands of the Internet and how it arrives onshore in Britain. We’re not talking dark fibre between terrestrial data centres 50 miles apart, but the landing station where Tata’s Atlantic submarine cable terminates at a mysterious location on the west coast of England after its 6,500km journey from New Jersey in the USA.

Connecting to the US is critical for any serious international communications company, and Tata’s Global Network (TGN) is the only wholly owned fibre ring encircling the planet. It amounts to a 700,000km subsea and terrestrial network with more than 400 points of presence worldwide. [...] At any one time Tata’s Tier 1 network is handling 24 percent of the world’s Internet traffic, so the chance to get up close and personal with TGN-A (Atlantic), TGN-WER (Western Europe), and their cable consortium friends is not to be missed.

The site itself is a pretty much vanilla data centre from the outside, appearing grey and anonymous—they could be crating cabbages in there for all you’d know. Inside, it’s RFID cards to move around the building and fingerprint readers to access the data centre areas, but first a cuppa and a chat in the boardroom. This isn’t your typical data centre, and some aspects need explaining. In particular, submarine cable systems have extraordinary power requirements, all supported by extensive backup facilities.

[...] He brought with him some subsea cable samples to show how the design changes depending on the depth. The nearer to the surface you get, the more protection—armour—you need to withstand potential disturbances from shipping. Trenches are dug and cables buried in shallow waters coming up onto shore. At greater depths, though, areas such as the West European Basin, which is almost three miles from the surface, there’s no need for armour, as merchant shipping poses no threat at all to cables on the seabed. At these depths, cable diameter is just 17mm, akin to a marker pen encased by a thick polyethylene insulating sheath. A copper conductor surrounds multiple strands of steel wire that protect the optical fibres at the core, which are inside a steel tube less than 3mm in diameter and cushioned in thixotropic jelly. Armoured cables have the same arrangement internally but are clad with one or more layers of galvanised steel wire, which is wrapped around the entire cable.

Without the copper conductor, you wouldn’t have a subsea cable. Fibre-optic technology is fast and seemingly capable of unlimited bandwidth, but it can’t cover long distances without a little help. Repeaters—effectively signal amplifiers—are required to boost the light transmission over the length of the fibre optic cable. This is easily achieved on land with local power, but on the ocean bed the amplifiers receive a DC voltage from the cable’s copper conductor. And where does that power come from? The cable landing sites at either end of the cable.

Although the customers wouldn’t know it, TGN-A is actually two cables that take diverse paths to straddle the Atlantic. If one cable goes down, the other is there to ensure continuity. The alternative TGN-A lands at a different site some 70 miles (and three terrestrial amplifiers) away and receives its power from there, too. One of these transatlantic subsea cables has 148 amplifiers, while the other slightly longer route requires 149.

Oui, il y a des répéteurs tous les 80 kilomètres environ. Source : http://shaarli.guiguishow.info/?9kAT1g

[...]

“To power the cable from this end, we’ve a positive voltage and in New Jersey there’s a negative voltage on the cable. We try and maintain the current—the voltage is free to find the resistance of the cable. It’s about 9,000V, and we share the voltage between the two ends. It’s called a dual-end feed, so we’re on about 4,500V each end. In normal conditions we could power the cable from here to New Jersey without any support from the US.”

[...] Yet looking at the cable sample itself, with a mere eight strands of optical fibre inside, you can’t help but think that, for all the effort involved, there should be more. “The limitations are on the size of the amplifier. For eight fibre pairs you’d need twice the size of amplifier,” says John, and as the amplifier scales up, so does the need for power.

At the landing site, the eight fibres that make up TGN-A exist as four pairs, each pair comprising a distinct send and receive fibre. The individual fibre strands are coloured, such that if it’s broken, and a repair needs to be done at sea, the technicians know how to splice it back together again. Similarly, those on land can identify what goes where when plugging into the Submarine Line Terminal Equipment

[...] “Once the cable has been found and returned to the cable-repair ship, a new piece of undamaged cable is attached. The ROV [remotely operated vehicle] then returns to the seabed, finds the other end of the cable and makes the second join. It then uses a high-pressure water jet to bury the cable up to 1.5 metres under the seabed,” he says.

“Repairs normally take around 10 days from the moment the cable repair ship is launched, with four to five days spent at the location of the break. Fortunately, such incidents are rare: Virgin Media has only had to deal with two in the past seven years.”

[...]

“Forward error correction is used to understand the signal that’s being sent, and modulation techniques have changed as the amount of traffic going down the signal has increased," says Osborne. [...]

DWDM (Dense Wavelength Division Multiplexing) technology is used to combine the various data channels, and by transmitting these signals at different wavelengths—different coloured light within a specific spectrum—down the fibre optic cable, it effectively creates multiple virtual-fibre channels. In doing so the carrying capacity of the fibre is dramatically increased.

One of the main issues affecting this application of photonics communications is the optical dispersion of the fibre. It’s something designers factor in to the cable construction, with some sections of fibre having positive dispersion qualities and others negative. And if you need to do a repair, you’ll have to be sure you have the correct dispersion cable type on board. [...]

Vache. :O

To the left of both boxes are power cables inside metal pipes.

:O

[...]

The yellow fibre trunking snakes overhead to the racks that will perform various tasks, including demultiplexing the incoming signals to separate out different frequency bands. [...] “It depends what the client wants,” adds Osborne. “If they want a single 100G circuit that’s coming out of one of those boxes it can be handed over directly to the customer. If the customer wants a lower speed, then yes, it will have to be handed over to further equipment to split it up into lower speeds. There are clients who will buy a 100G direct link but not that many. A lower-tier ISP, for example, wanting to buy transmission capability from us, will opt for a 10G circuit. “The bulk of the transport on the cable is either used for our own Internet or is being sold as transport circuits to other Internet wholesale operators—the likes of BT, Verizon, and other international operators who don’t have their own subsea cables buy transport from us.”

Tall distribution frames support a patchwork of optical cables that divvy up 10G connectivity for clients. If you fancy a capacity upgrade then it’s pretty much as simple as ordering the cards and stuffing them into the shelves—the term used to describe the arrangements in the large equipment chassis. John points out a customer’s existing 560Gbps system (based on 40G technology), which recently received an additional 1.6Tbps upgrade. The extra capacity was achieved by using two 800Gbps racks, both functioning on 100G technology for a total bandwidth of more than 2.1Tbps. As he talks about the task, one gets the impression that the lengthiest part of the process is waiting for the new cards to show up.

All of Tata’s network infrastructure onsite is duplicated, so there are two of rooms SLT1 and SLT2. One Atlantic system internally referred to as S1 is on the left of SLT1, and the Western Europe Portugal cable referred to as C1 is on the right. And on the other side of the building there’s SLT2, with the Atlantic S2 system together with C2 connecting to Spain.

Terrestrial room

In a separate area nearby is the terrestrial room, which, among other tasks, handles traffic connections to Tata’s data centre in London. One of the transatlantic fibre pairs doesn’t actually drop at the landing site at all. It’s an “express pair” that continues straight to Tata's London premises from New Jersey to minimise latency. Talking of which, John looked up the latency of the two Atlantic cables; the shorter journey clocks up a round trip delay (RTD) of 66.5ms, while the longer route takes 66.9ms. So your data is travelling at around 437,295,816 mph. Fast enough for you?

On this topic he describes the main issues: “Each time we convert from optical to electrical and then back to optical, this adds latency. With higher-quality optics and more powerful amplifiers, the need to regenerate the signal is minimised these days. Other factors involve the limitations on how much power can be sent down the subsea cables. Across the Atlantic, the signal remains optical over the complete path.”

[...]

To one side is a bench of test equipment and, as seeing is believing, one of the technicians plumbs a fibre-optic cable into an EXFO FTB-500. This is equipped with an FTB-5240S spectrum analyser module. The EXFO device itself runs on Windows XP Pro Embedded and features a touchscreen interface. After a fashion it boots up to reveal the installed modules. Select one and, from the list on the main menu, you choose a diagnostic routine to perform.

Hahaha, winwin XP. :')

[...]

Never far from the heavy lifting in data communications, a Juniper MX960 universal edge router acts as the IP backbone here. In fact, there are two onsite confirms John: “We have the transatlantic stuff coming in and then we can drop STM-1 [Synchronous Transport Module, level 1], GigE, or 10GigE clients—so this will do some sort of multiplexing and drop the IP network to various customers.”

The equipment used on the terrestrial DWDM platforms takes up far less space than the subsea cable system. Apparently, the ADVA FSP 3000 equipment is pretty much exactly the same thing as the Ciena 6500 kit, but because it’s terrestrial the quality of the electronics doesn’t have to be as robust In effect, the shelves of ADVA gear used are simply cheaper versions, as the distances involved are much shorter. With the subsea cable systems, the longer you go, the more noise is introduced, and so there’s a greater dependence on the Ciena photonics systems deployed at the landing site to compensate for that noise.

One of the racks houses three separate DWDM systems. Two of them connect to London on separate cables (each via three amplifiers), and the other goes to a data centre in Buckinghamshire.

[...]

The power of nightmares

You can’t visit a landing site or a data centre without noticing the need for power, not only for the racks but for the chillers: the cooling systems that ensure that servers and switches don’t overheat. And as the submarine cable landing site has unusual power requirements for its undersea repeaters, it has rather unusual backup systems, too.

Enter one of the two battery rooms and instead of racks of Yuasa UPS support batteries—with a form factor not too far removed from what you’ll find in your car—the sight is more like a medical experiment. Huge lead-acid batteries in transparent tanks, looking like alien brains in jars, line the room. Maintenance-free with a life of 50 years, this array of 2V batteries amounts to 1600Ah, delivering a guaranteed four hours of autonomy.

Battery chargers, which are basically the rectifiers, supply the float voltage so the batteries are maintained. They also supply the DC voltage to the building for the racks.

Inside the room are two PFEs (Power Feed Equipment) all housed together within sizeable blue cabinets. One is powering the Atlantic S1 cable and the other is for Portugal C1. A digital display gives a reading of 4,100V at around 600mA for the Atlantic PFE and another shows just over 1,500V at around 650mA for the C1 PFE.

John describes the configuration: “The PFE has two separate converters. Each converter has three power stages. Each one can supply 3,000V DC. So this one cabinet can actually supply the whole cable, so we have an n+1 redundancy, because there’re two onsite. However, it’s more like n+3, because if both convertors failed in New Jersey and a convertor here failed also, we could still feed the cable.”

:O

Revealing some rather convoluted switching arrangements, John explains the control system: “This is basically how we turn it on and off. If there is a cable fault, we have to work with the ship managing the repair. There are a whole load of procedures we have to go through to ensure it’s safe before the ship’s crew can work on it. Obviously, voltage that high is lethal, so we have to send power safety messages. We’ll send a notification that the cable is grounded and they’ll respond. It’s all interlocked so you can make sure it’s safe.”

The site also has two 2MVA (megavolt-ampere) diesel generators. Of course, as everything’s duplicated, the second one is a backup. There are three huge chillers, too, but apparently they only need one. Once a month the generator backup is tested off load, and twice a year the whole building is run on load. As the site also doubles up as a data centre, it’s a requirement for SLAs and ISO accreditation.

In a normal month, the electricity bill for the site comfortably reaches five figures.

Pas mal. :D

Datacenter

At the Buckinghamshire data centre there are similar redundancy requirements, albeit on a different scale, with two giant collocation and managed hosting halls (S110 and S120), each occupying 10,000 square feet. Dark fibre connects S110 to London, while S120 connects to the west coast landing site. [...]

[...]

So we’ve got 400 locations with multiple devices which connect into one big network, which is one autonomous system. It provides IP, Internet, and point-to-point services to our customers. Because it has a mesh topology [400 interconnected devices]—any one connection will take a different route to the MPLS cloud. We also provide network services—on-net and off-net services. Service providers like Virgin Media and NetApp terminate their services into the building.”

In the spacious Data Hall 110, Tata’s managed hosting and cloud services are on one side, with collocation customers on the other. Data Hall 120 is much the same. Some clients keep their racks in cages and restrict access to just their own personnel. By being here, they get space, power, and environment. All the racks have two supplies from A UPS and B UPS, by default. They each come via a different grid, taking alternative routes through the building.

“So our fibre, which comes from the SLTE [ NDLR : la station d'atterisage / « landing site » du câble sous-marin ;) ] and London, terminates in here,” says Paul. Pointing out a rack of Ciena 6500 kit, he adds, “You might have seen equipment like this at the landing site. This is what takes the main dark fibre coming into the building and then it distributes it to the DWDM equipment. The dark fibre signals are divided into the different spectrums, and then it goes to the ADVA from where it’s distributed to the actual customers. We don’t allow customers to directly connect into our network, so all the network devices are terminated here. And from here we extend our connectivity to our customers.”

A typical day for Paul and his remote-hands colleagues is more about the rack-and-stack process of bringing new customers on board and remote-hands tasks such as swapping out hard drives and SSDs. It doesn’t involve particularly in-depth troubleshooting. For instance, if a customer loses connectivity to any of their devices, his team is there for support and will check that the physical layer is functioning in terms of connectivity, and, if required, will change network adapters and suchlike to make sure a device or platform is reachable.

He has noticed a few changes in recent years, though. Rack-and-stack servers that were 1U or 2U in size are being replaced by 8U or 9U chassis that can support a variety of different cards including blade servers. Consequently, the task of installing individual network servers is becoming a much less common request. In the last four or five years, there have been other changes, too.

“At Tata, a lot of what it provides is HP and Dell—products we’re currently using for managed hosting and cloud setups. Earlier it used to be Sun as well but now we see very little of Sun. For storage and backup, we used to use NetApp as a standard product but now I see that EMC is also being used, and lately we’ve seen a lot of Hitachi storage. Also, a lot of customers are going for a dedicated storage backup solution rather than managed or shared storage.”

[...]

The NOC's NOC

The layout in the NOC (network operations centre) area of the site is much the same as you’d find in any office, although the big TV screen and camera linking the UK office to the NOC staff in Chennai in India is a bit of surprise. It’s a network test of sorts, though: if that screen goes down, they both know there’s a problem. Here, it’s effectively level one support. The network is being monitored in New York, and the managed hosting is monitored in Chennai. So if anything serious does happen, these remote locations would know about it first.

Haha la supervision de la connectivité avec un écran. :D

George describes the setup: “Being an operations centre we have people calling in regarding problems. We support the top 50 customers—all top financial clients—and it’s a really high priority every time they have a problem. The network that we have is a shared infrastructure, so if there’s a major problem then a lot of customers may be impacted. We need to be able to update them in a timely fashion, if there’s an ongoing problem. We have commitment to some customers to update every hour, and for some it’s 30 minutes. In the critical incident scenario, we constantly update them during the lifetime of the incident. This support is 24/7.”

Being an international cable system, the more typical problems are the same for communications providers everywhere: namely damage to terrestrial cables, most commonly at construction sites in less well-regulated territories. That and, of course, wayward anchors on the seabed. And then there are the DDoS (distributed denial-of-service) attacks, where systems are targeted and all available bandwidth is swamped by traffic. The team is, of course, well equipped to manage such threats.

“The tools are set up in a way to monitor the usual traffic patterns of what is expected during that period during a day. It can examine 4pm last Thursday and then the same time today. If the monitoring detects anything unusual, it can proactively deal with an intrusion and reroute the traffic via a different firewall, which can filter out any intrusion. That’s proactive DDoS mitigation. The other is reactive, where the customer can tell us: 'OK I have a threat on this day. I want you to be on doubt.’ Even then, we can proactively do some filtering. There’s also legitimate activity that we will receive notification of, for example Glastonbury [ NDLR : un festival musical international réputé], so when the tickets go on sale, that high level of activity isn’t blocked.”

Latency commitments have to be monitored proactively, too, for customers like Citrix, whose portfolio of virtualisation services and cloud applications will be sensitive to excessive networking delays. Another client that appreciates the need for speed is Formula One. Tata Communications handles the event networking infrastructure for all the teams and the various broadcasters.

“We are responsible for the whole F1 ecosystem, including the race engineers who are on site and are also part of the team. We build a POP [point of presence] on every race site—installing it, extending all the cables and provisioning all the customers. We install different Wi-Fi Internet breakouts for the paddocks and everywhere else. The engineer on site does all the jobs, and he can show all the connectivity is working for the race day. We monitor it from here using PRTG software so we can check the status of the KPIs [key performance indicators]. We support it from here, 24/7.” Such an active client, which has regular fixtures throughout the year, means that the facilities management team must negotiate dates to test the backup systems. If it’s an F1 race week, then from Tuesday to the following Monday, these guys have to keep their hands in their pockets and not start testing circuits at the data centre. Even during the tour, when Paul pointed out the F1 equipment rack, he played safe and chose not to open up the cabinet to allow a closer look.

Vache :O

Oh, and if you’re curious about the backup facilities here, there are 360 batteries per UPS and there are eight UPSes. That’s more than 2,800 batteries, and as they’re all 32kg each, this amounts to around 96 tonnes in the building. The batteries have a 10-year lifespan, and they’re individually monitored for temperature, humidity, resistance, and current around the clock. At full load they’ll keep the data centre ticking over for around eight minutes, allowing plenty of time for the generators to kick in. On the day, the load was such that the batteries could keep everything running for a couple of hours.

There are six generators—three per data centre hall. Each generator is rated to take the full load of the data centre, which is 1.6MVA. They produce 1,280kW each. The total coming into the site is 6MVA, which is probably enough power to run half the town. There is also a seventh generator that handles landlord services. The site stores about 8,000 litres of fuel, enough to last well over 24 hours at full load. At full fuel burn, 220 litres of diesel an hour is consumed, which, if it were a car travelling at 60mph, would notch up a meagre 1.24mpg—figures that make a Humvee seem like a Prius.

[...]

The last mile [ NDLR : entre les datacenters (dans lesquels sont installés les machines des FAI et des fournisseurs de services) et chaque habitation ]

Inside Openreach's [ NDLR : filiale de l'opérateur historique monopolistique UK, BT. Cette filiale détient le réseau physique. ] new VDSL2 cabinets is a DSLAM (digital subscriber line access module, in BT parlance). In the case of older ADSL and ADSL2, DSLAM kit tends to be found farther away at the exchange, but its use in the street is to amplify the fibre-optic cable signal connected to the exchange to enable a broadband speed increase to the end user. Using tie pair cables, the mains-powered DSLAM cabinet is linked to the existing street cabinet, and this combination is described as a primary cross-connection point (PCP). The copper cabling to the end user’s premises remains unchanged, while VDSL2 is used to deliver the broadband connectivity to the premises from the conventional street cabinet.

[...]

It’s a far cry from Virgin Media’s HFC network, which currently has homes connected at 200Mbps and businesses at 300Mbps. Virgin Media uses fibre-optic cables to deliver its services to streetside cabinets, which distribute broadband and TV over a single copper coaxial cable (a twisted pair is still used for voice).

It's also worth mentioning that DOCSIS 3.0 is the leading last-mile network tech over in the US, with about 55 million out of 90 million fixed-line broadband connections using coaxial cable. ADSL is in second place with about 20 million and then FTTP with about 10 million. Hard numbers for VDSL2 deployment in the US are hard to come by, but it appears to be used sporadically in some urban areas.

Ok, FTTP, c'est le terme pour englober toutes les technos fibres qui arrivent en fibre jusqu'à l'abonné (FTTH, FTTB, etc.). Ok, donc Virgin déploie du FTTC (comme le FTTLA mais l'armoire de rue est plus proche des abonné-e-s. :- Je pense que l'équivalent français est de la fibre jusqu'aux sous-répartiteurs) et Openreach fait du VDSL2, de la montée en débit sur suivre, en somme.

There's still plenty of headroom with DOCSIS 3 that will allow cable ISPs to offer downstream connection speeds of 400, 500, or 600Mbps as needed—and then after that there'll be DOCSIS 3.1 waiting in the wings. [...] The DOCSIS 3.1 spec suggests more than 10Gbps is possible downstream and eventually 1Gbps upstream. These capacities are made possible by the use of quadrature amplitude modulation techniques—the same as used on short-distance submarine cables.

[...]

[...) we’d be remiss if we completely ignored the other side of the last-mile (or last-100m) equation: mobile devices and wireless connectivity.

Case in point: the recent emergence of almost blanket Wi-Fi hotspot coverage in urban areas. First it was a few plucky cafes and pubs, and then BT turned its customers’ routers into open Wi-Fi hotspots with its "BT with Fon" service. Now we’re moving into major infrastructure plays, such as Wi-Fi across the London Underground and Virgin’s curious “smart pavement” in Chesham, Buckinghamshire. For this project, Virgin Media basically put a bunch of Wi-Fi access points beneath manhole covers made of specially made radio-transparent resin. Virgin maintains a large network of ducts and cabinets across the UK that are connected to the Internet—so why not add a few Wi-Fi access points to share that connectivity with the public?

[...]

“The biggest issue tends to be challenging conventional thinking. For example, traditional wireless projects involve mounting a radio as high as permission allows and radiating with as much power as regulations permit. What we tried to do was put a radio under the ground and work within the allowed power levels of traditional in home Wi-Fi," he says.

[...]

[...] future of wired Internet

The next thing on the horizon for Openreach’s POTS network is G.fast, which is best described as an FTTdp (fibre to distribution point) configuration. Again, this is a fibre-to-copper arrangement, but the DSLAM will be placed even closer to the premises, up telegraph poles and under pavements, with a conventional copper twisted pair for the last few tens of metres.

The idea is to get the fibre as close to the customer as possible, while at the same time minimising the length of copper, theoretically enabling connection speeds of anywhere from 500Mbps to 800Mbps. G.fast operates over a much broader frequency spectrum than VDSL2, so longer cable lengths have more impact on its efficiency. However, there has been some doubt whether BT Openreach will be optimising speeds in this way as, for reasons of cost, it could well retreat to the green cabinet to deliver these services and take a hit on speed, which would slide down to 300Mbps.

[...]

The last few years have also been exciting for smaller, independent players such as Hyperoptic and Gigaclear, which are rolling out their own fibre infrastructure. Their footprints are still hyper-focused on a few thousand inner-city apartment blocks (Hyperoptic) and rural villages (Gigaclear), but increased competition and investment in infrastructure is never a bad thing.

En 2015, plusieurs personnes ont fait du lobbying ( :D ) pour que je migre mon blog, un WordPress, vers un générateur de sites web statiques. Je m'étais mis ça de côté dans ma TODO. Je viens de prendre le temps de m'intéresser à la question.

Pourquoi migrer ?

• WordPress est un CMS complet, avec des tonnes de fonctionnalités dont je ne me sers pas. C'est relou de mettre à jour un truc dont je ne me sers pas pour avoir des nouvelles fonctionnalités dont je ne me servirai pas. Dans le mois qui suit la sortie d'une nouvelle version, il y a une faille de sécurité qui touche toutes les anciennes versions… Pleaaaase. Notons que depuis 2015, j'ai stocké l'enchaînement de commandes que j'utilise pour mettre à jour dans un fichier texte et je pourrais envisager de créer un script sans trop de problèmes. Quoi qu'il en soit, le temps nécessaire pour mettre à jour mon WordPress a diminué ces derniers temps.
  
  
• En 2015, je trouvais l'idée séduisante car les commentaires de mon blog étaient alors envahis par le spam. Genre mon anti-spam (Spam Karma) laissait quasiment tout passer et je devais nettoyer les commentaires très régulièrement pour ne pas avoir de merde publiée sur mon blog et ne pas voir la taille de ma sauvegarde de la base de données grossir démesurément. En avril 2016, je me rendais compte que cette inefficacité était dû au passage à PHP 5.6.X dans Debian Jessie qui met l'extension MySQL au placard au profit de PDO, ce qui fait que la fonction mysql_real_escape_string(), utilisée par mon antispam, n'est plus disponible. Voir http://shaarli.guiguishow.info/?1_-YHw

Contrainte

La seule contrainte que je me suis fixée est la suivante : toutes les URL existantes doivent fonctionner après la migration. Toutes. Simplement parce que les URL cools / sympas ne changent jamais. Pérennité de l'information et du moyen d'y accéder, tout ça.

Évidemment, je souhaiterai aussi que les liens de mes tables des matières, qui pointent sur les sous-titres de mes billets, continuent aussi à fonctionner. Si ce n'est pas le cas, c'est ennuyeux mais ce n'est pas dramatique : l'utilisateur-rice atterrira quand même sur la bonne page web, juste il-elle ne sera pas propulsé-e au bon endroit dans le contenu de la page, c'est moins grave.

Continuer à publier sur mon blog ?

Cette question est importante. Si je décide que je ne veux plus publier sur mon blog, alors c'est simple : je dégaine wget ou httrack et je crée une copie statique de mon blog et c'est cette copie que je publie. Pas besoin d'un nouveau moteur de blog, même statique. Si je veux pouvoir ajouter des articles sur mon blog, alors oui, une migration vers un autre outil semble plus appropriée.

Je souhaite publier occasionnellement des articles sur mon blog. Le format shaarli + markdown n'est pas forcément le plus adapté. L'audience n'est pas non plus la même.

Quel générateur de site statique utiliser ?

Des générateurs de sites statiques, il en existe plusieurs centaines.

Mes critères de choix (liste ordonnée) : logiciel libre, pas écrit dans un langage de kikoo / inadapté (JavaScript / Node.js, Java, Go, Erlang, C/C++, Haskell, etc.), importation possible depuis WordPress, une bonne documentation et une communauté d'utilisateur-rice-s.

Avec ces critères, les logiciels suivants émergent du lot : Jekyll (Ruby), Octopress (basé sur Jekyll) et Pelican (Python). Je note aussi Lektor qui propose une interface d'admin en Node.js pour créer / modifier / supprimer les pages. Je connaissais aussi ikiwiki, codé en Perl, plus adapté pour les wikis, comme son nom l'indique.

J'ai choisi Pelican. Parce que je sais coder en Python et que je connais (un peu) Jinja2 (moteur de template) depuis que j'utilise ansible. Au cas où j'aurais besoin de mettre les mains dans le cambouis. Et un peu aussi parce que 2 des 3 lobbyistes qui m'ont invité à migrer mon blog utilisent Pelican (oui, effet de prescription, oui, je suis un mouton).

Pourquoi ne pas migrer ?

Avant de migrer, j'ai voulu me faire une liste de tout ce qui pourrait foirer. J'imagine que ça pourra servir à d'autres donc voici une petite liste non-exhaustive des problèmes potentiels que j'ai identifiés (liste ordonnée, du moins relou / problématique au plus problématique) :

• Est-ce qu'une migration vers Pelican me permet de virer des softs ? Non, j'ai toujours besoin de PHP pour shaarli et j'ai toujours besoin de MySQL pour Tiny Tiny RSS. J'ai testé beaucoup d'agrégateurs RSS (voir http://www.guiguishow.info/2011/08/07/agregateur-rss/ et http://www.guiguishow.info/2013/03/18/passer-de-newsfox-a-kriss-feed/ ) avant d'en trouver un qui fait le job que j'attends de lui donc il est exclu que j'en change. Shaarli me convient très bien donc il ne dégagera pas. Bon, virer WordPress permet déjà d'avoir moins de code sur le serveur donc ça restreint fortement la surface d'attaque.
  
  
• Est-ce que ça me débarrasse de WordPress ? Hé bah non, car j'administre d'autres WordPress. Genre association, tout ça. Bon, OK, ça ne sera bientôt plus le cas mais still…
  
  
• Pelican prend en charge trois formats pour rédiger le contenu : asciiDoc, reStructuredText et markdown. Je suis habitué à utiliser markdown pour créer mes slides Beamer et pour mettre en forme mes shaarlis. Donc ça va, il n'y a pas une barrière supplémentaire à l'entrée.
  
  

• Ma plus grande crainte était d'avoir des URL différentes. Mais en fait, non. Genre, pour avoir le même format « /année/mois/jour/titre/ » que mon WordPress, ça se dit comme cela dans pelicanconf.py ( voir http://docs.getpelican.com/en/3.6.3/settings.html ) :

  ARTICLE_URL = '{date:%Y}/{date:%m}/{date:%d}/{slug}/'
  ARTICLE_SAVE_AS = '{date:%Y}/{date:%m}/{date:%d}/{slug}/index.html'

Même chose pour les pages, les archives, les catégories, etc.

• L'absence de PHP signifie l'absence de commentaires. Pourtant, des personnes ont écrit d'excellents commentaires sur mon blog. Je trouve que supprimer (ne pas importer) les commentaires, c'est un manque d'éthique ou de politesse ou de je ne sais quoi : ces personnes ont fait l'effort d'écrire et m'ont appris des trucs. Bien sûr, dans les articles correspondant, j'ai mentionné les commentaires intéressants mais je n'ai pas forcément intégré lesdits commentaires au billet. Des infos intéressantes seraient donc perdues dans la migration. Je trouve ça dommage. Évidement, il est hors de question que j'utilise un service externe genre Disqus. Visiblement, il existe des solutions. Soit en utilisant une base sqlite (lol, site statique, tout çà) comme isso et d'autres. Soit avec du mail dedans ( https://github.com/getpelican/pelican-plugins/tree/master/pelican_comment_system ). Ce deuxième système a la classe. \o/ Pour importer les commentaires WordPress dedans : https://gist.github.com/tiramiseb/048db9c21c3fac8a44fd76cddaa17834 .
  
  
• Il faut que je retrouve un thème sombre, extensible et qui utilise un maximum la place qu'on a sur nos écrans (pas centré sur 400 pixels comme mon blog actuel, car c'est ridicule). Et rien que ça, ça va être une plaie. Et comme l'existant ne me conviendra pas, il faudra forcément que je le modifie. J'ai autre chose à faire, sérieux. :-
  
  
• Mon blog et mon shaarli sont entremêlés : des contenus pointés par mon shaarli sont stockés dans mon /wp-content/uploads. Oui, on évite de lier deux machines ou deux logiciels entre eux, règle de base. De la même manière, du contenu hébergé dans /wp-content/uploads n'a pas vraiment de lien, ni avec mon blog, ni sur ce shaarli. Exemple : les vidéos des journées FédéRez 2013. Là encore, cette organisation est stupide : j'aurai dû créer un autre virtualhost avec un autre domaine (genre datalove.guiguishow). Rien d'irréparable, juste il faut faire le ménage et écrire les redirections qui vont bien sachant que, puisqu'on est entre virtualhosts, il faut gérer http/https et ne pas rediriger bêtement tout en http ou tout en https.
  
  
• L'absence de PHP signifie l'absence d'un champ de recherche. Or, c'est clairement la fonctionnalité que j'utilise le plus pour retrouver ce que j'ai écrit, pour retrouver des commandes, etc. Hors de question d'être dépendant d'un service externe et encore moins de Google. Visiblement, il existe un plugin avec du JSON et du jQuery dedans pour faie le job : http://moparx.com/2014/04/adding-search-capabilities-within-your-pelican-powered-site-using-tipue-search/ . Remplacer PHP par une bouse bien lourde en JavaScript, j'aime le concept… Ou pas. Utiliser YaCy ?
  
  

• L'import depuis WordPress ne sera pas parfait, il suffit de lire des témoignages pour le vérifier : http://jonathan.michalon.eu/passage-a-pelican.html ou http://blog.jasonantman.com/2014/02/converting-wordpress-posts-to-pelican-markdown/ . J'ai testé et j'ai constaté les problèmes suivants :

  • Le nom d'auteur importé est le login dans WordPress, pas le nom de plume (oui, WordPress peut séparer les deux). Un coup de sed peut être nécessaire ;
    
    
  • Certains caractères comme « < », « > » sont échappés dans le markdown, lors de l'import. Il n'y a rien dans l'export XML WordPress, c'est vraiment Pandoc qui ajoute l'échappement durant l'import. Il faut les identifier et les sed ;
    
    
  • Sur mon WordPress, la table des matières de chaque article est créee dynamiquement par une extension (Table of Contents Generator codée par Scott Yang). Donc forcément, les tables des matières ne sont pas exportées par WordPress. Il faut donc les refaire à la mimine ou prévoir de se coder un script. ÉDIT DU 25/09/2016 À 21H05 : ou utiliser https://github.com/getpelican/pelican-plugins/tree/master/extract_toc FIN DE L'ÉDIT ;
    
    
  • Il faut importer soi-même les images car l'importateur se contente de faire un lien vers l'existant. De même, les légendes sont importées avec leur style CSS qui, du coup, fait partie de la nouvelle légence (genre « [caption id="attachment_36' class="aligncenter" width="300" caption="ma légende"] ». Pour corriger les légendes, il faudra forcément utiliser des regex look-behind. Pour l'import des images, c'est tout à la mimine. Dans mon cas, on parle d'environ 300 images, hein ;
    
    
  • Tous les liens sur des images (afin de les voir en grand) sont en http uniquement et sont des liens absolus… C'est comme cela que WordPress les stocke. Sur mon blog, j'ai un plugin pour réécrire les liens en https quand l'utilisateur se ramène en https : Content over SSL. Avec Pelican, j'imagine qu'il doit y avoir une syntaxe Apache pour arriver au même résultat ;
    
    
  • De la même manière, il faut corriger les liens internes genre ceux qui pointent vers wp-content/uploads puisque ce dossier a vocation à disparaître après la migration ;
    
    
  • Pelican ne supporte pas le multi-catégories : chaque article a une seule catégorie et des tags. Voir https://github.com/getpelican/pelican/issues/350 . Du coup, l'importateur fusionne toutes les catégories d'un même article en une seule genre un article dans les catégories nommées « divers » et « humeur » se retrouve dans une catégorie nommée « divers-humeur ». Forcément, cela fait exploser le nombre de catégories et ruine l'effet même des catégories puisque chaque article se retrouve dans une catégorie au lieu d'une union de catégories.
    
    
  • Sur mon WordPress, pour mettre en valeur les bouts de code et les commandes et pour faire de la coloration syntaxique, j'utilise l'extension wp-syntax. Sauf que cette extension prend un temps colossal à parser dynamiquement les articles. Du coup, pour chaque nouveau billet, je copie le code html qu'elle génère (« <div class="wp_syntax"><pre lang="langage">mon merveilleux code ici</pre></div> ») directement dans le billet puis je désactive l'extension. Forcément, ça ne marche plus suite à l'importation : le code est isolé dans le markdown. Il faut jouer avec des regex (et des regex capturantes) pour corriger tout ça et positionner les délimiteurs attendus ( voir http://docs.getpelican.com/en/3.6.3/content.html#syntax-highlighting ). Bref, y'a de quoi bien se prendre la tête. :S
    
    
  • Sans compter d'autres mauvaises surprises. Relire 138 articles dont la plupart sont des pavés, ça prendra forcément beaucoup de temps.

Vu tous ces points, on se rend compte que la migration depuis WordPress va nécessiter beaucoup de travail, notamment l'import depuis WP, la personnalisation du thème et l'installation d'un moteur de recherche. Une mise à jour de WordPress me prend 5 minutes montre en main (+ 5 minutes supplémentaires le temps de basher WordPress sur IRC :P ). Une faille de sécurité WordPress est tombée en moyenne tous les 2 mois sur la dernière année. Il me faut donc 5 minutes tous les 2 mois soit 30 minutes par an. La question devient donc : combien de mises à jour de WordPress faudrait-il avant que le passage à Pelican soit rentabilisé ? On sent bien qu'on est sur plusieurs années d'équivalence.

Notes diverses sur Pelican

• ÉDIT DU 25/09/2016 À 21H10 : y'a un article sympa sur Pelican dans GNU/Linux magazine France numéro 184. FIN DE L'ÉDIT.
  
  
• Avec jessie-backports, l'installation se résume à : apt-get installl python-ps4 python-lxml pandoc pelican
  
  
• Importer depuis Wordpress au format markdown :
  • Dans l'interface d'admin WordPress : « Outils » -> « Exporter », laisser cocher « Tout le contenu » -> « Télécharger le fichier d'export ». Source : http://marieguillaumet.com/exporter-et-importer-wordpress-quelques-astuces/
    
    
  • pelican-quickstart puis cd dans le dossier de votre nouveau blog puis pelican-import --wpfile ../export.xml -m markdown -o content [--dir-page --dir-cat] . Attention : si votre blog contient de bon gros pavés, il faudra pas mal de RAM pour effectuer la conversion. Genre 512M de RAM ne suffisent pas pour convertir mon blog, pandoc se fait tuer par l'OOM-killer de Linux.
    
    
  • make html pour générer localement votre blog. make serve pour lancer un serveur web minimaliste local et accéder à votre blog via localhost:8000 . Il est tout à fait possible de make html pendant qu'un make serve est en cours de fonctionnement.
    
    
  • pelicanconf.py : définir les paramètres à utiliser pour générer la copie locale, votre site web de dev'. publishconf.py : la même mais pour le site web de prod'.

En résumé, j'ai creusé (un peu) le monde des générateurs de sites web statiques et j'ai approfondi Pelican. Mais, je ne migrerai pas mon blog existant car cela représente trop de travail pour assurer la qualité de l'import.

Héhé :)

Jeter un disque défaillant ? Nan jeter toute la machine. Nan, jeter toute la baie. Nan, remplacer toute la salle. Nan, tout le datacenter.

Suite à mon essai de GNU IceCat, j'ai encore découvert des paramètres pas cool dans Firefox.

• extensions.blocklist.enabled => false

  Enable the blocklist. Retrieve the list from the server specified in extensions.blocklist.url at the interval specified in extensions.blocklist.interval. If blocklisted extensions or plugins are already installed, disable them, and prevent blocklisted extensions from being installed in the future.
  ( http://kb.mozillazine.org/Extensions.blocklist.enabled )

• layout.spellcheckDefault => 2

  Enable spellchecker for multi-line controls and single-line controls. (Default in Camino)
  ( http://kb.mozillazine.org/Layout.spellcheckDefault )

• dom.battery.enabled => false
• device.sensors.enabled => false
• camera.control.face_detection.enabled => false
  => bon, ça parle tout seul.

• media.gmp-manager.url => http://127.0.0.1/
• media.gmp-manager.url.override => "data:text/plain,"
• media.gmp-provider.enabled => false

  GMP is a special purpose extension point for authorised 3rd party codecs and EME (Encrypted Media Extensions) CDMs (Content Decryption Modules).
  ( https://wiki.mozilla.org/GeckoMediaPlugins )

• browser.selfsupport.url => ""
  => Permet d'évaluer Firefox. La notification apparaît que pour une poignée d'utilisateurs mais Firefox (pour avoir simplement un échantillon) se connecte bien régulièrement chez Mozilla (pour savoir s'il fait partie du lot qui doit afficher la notification, j'imagine). Voir https://support.mozilla.org/fr/kb/rate-your-firefox-experience-heartbeat

• browser.newtabpage.directory.source => "");
• browser.newtabpage.directory.ping => ""
• browser.newtabpage.introShown => true
  => Ça, c'est pour le très controversé ajout de pub lors de l'ouverture d'un nouvel onglet. Bon, a priorio, ça ne me concerne pas vu que j'ai configuré browser.newtab.url -> about:blank , mais bon.

• social.directories" => ""
• social.remote-install.enabled => false
• social.share.activationPanelEnabled => false
• social.shareDirectory => ""
• social.toast-notifications.enabled => false
• social.whitelist => ""
  => Ça, c'est pour virer ce qu'il reste de l'API Social de Firefox…

On peut aussi empêcher la mise à jour automatique des moteurs de recherche mais je ne l'ai pas fait :

• browser.search.update => false

J'ai mis à jour mon shaarli sur ma configuration Firefox.

Il est déjà assez pénible de voir le terme systématiquement renvoyé à la cybercriminalité pour ne pas devoir, en prime, faire la chasse aux fantasmes agités à tout propos.

«Fausse alerte terroriste à Paris : un hacker de 16 ans interpellé», «Une Tesla piratée à distance par des hackers chinois», «Internet en Corée du Nord : des hackers dressent l’inventaire». On n’en a choisi que trois, mais des titres d’articles du même tonneau, ces derniers jours, il y en a eu des dizaines sur le Web. [...]

Or, de quoi parle-t-on ici ? Dans le premier cas, d’un irresponsable canular téléphonique qui, pour spectaculaires qu’aient été ses résultats, ne nécessite pas de compétences poussées – que l’adolescent arrêté se présente comme un hacker ne fait pas du délit dont il est accusé une prouesse technique. Dans le second cas, d’une faille découverte par les chercheurs d’un laboratoire chinois en cybersécurité. Enfin, dans le troisième, d’un changement de configuration (possiblement par erreur) sur le serveur de noms de domaine de la Corée du Nord, changement qui a rendu accessible la liste de ces derniers et a été repéré, notamment, par un chercheur en sécurité informatique. Avec pour résultat d’offrir un accès inédit à la partie du Web la plus fermée au monde (et manifestement pas la plus florissante).

On pourrait rappeler que pour les communautés hackers elles-mêmes, le terme renvoie d’abord à une façon d’appréhender la technologie : la comprendre, la bidouiller, la détourner, résumait Wikipédia il y a quelques années. Que le hacking – une culture, des pratiques – ne saurait donc se réduire au piratage informatique, même si ce dernier en est la dimension la plus médiatisée. [...] On pourrait même convoquer le Comité invisible qui, dans A nos amis, écrit : «Là où l’ingénieur vient capturer tout ce qui fonctionne pour que tout fonctionne mieux, pour le mettre au service du système, le hacker se demande "comment ça marche ?" pour en trouver les failles, mais aussi pour inventer d’autres usages, pour expérimenter.»

A défaut de réussir à appréhender dans sa complexité le terme «hacker», du moins devrait-il être possible de ne pas le mettre à toutes les sauces. Il est certes plus vendeur de titrer sur le piratage d'une Tesla par de mystérieux «hackers chinois», avec toute l'imagerie que l'expression peut véhiculer, plutôt que sur la découverte d'une faille par des chercheurs en cybersécurité. [...]

Via https://twitter.com/bearstech/status/778876525554860032 via https://twitter.com/bluetouff

L'ARCEP a soumis à consultation publique l'analyse qu'elle fait du marché [ NDLR : des accès à Internet ] fixe. [...] Cette analyse du marché fixe est importante, car elle permet au régulateur des télécoms de constater les manquements du marché, les orientations à suivre et les décisions à acter.

Dans les grandes lignes, la Fédération a évoqué les sujets suivants :

• Montrer les biais de l'analyse faite par l'ARCEP : considérer le marché comme unique remède à tous les maux, ignorer les petits opérateurs en général, et tout modèle autre qu'industriel en particulier, centrer son analyse sur les opérateurs et pas sur l'utilisateur final ;
• Souligner le manque de concurrence sur la boucle locale fibre : l'abonné moyen a, au mieux, le choix entre deux opérateurs, quand tout va bien, aucune possibilité de nouvel entrant de petite taille : exclusions des opérateurs locaux, des associatifs ;
• Souligner que la boucle locale dite "mutualisée" est en fait un monopole local, sur une zone géographique, par une joint-venture de gros opérateurs qui s'entendent ; Proposer une obligation, pour ce monopole, de fournir une offre activée pour remédier l'absence de concurrence, permettre l'existence des petits opérateurs, et ouvrir le marché des entreprises vers la fibre optique ;
• Exposer les possibilités, en matière de déploiement de boucle locale, qu'offre le modèle mis en œuvre par la Fédération FDN sur la boucle locale radio et la boucle locale fibre.

Nous espérons que ce travail sera pris en compte par le régulateur afin de ne plus retarder l'ouverture du marché de la fibre optique en France.

J'avais déjà évoqué cette consultation et donné mon avis dans un autre shaarli : http://shaarli.guiguishow.info/?9VVNag . Je ne reviens donc pas sur la terminologie.

Ci-dessous, le contenu de la réponse de la FFDN avec plus de détails que le TL;DR ci-dessus.

Biais de méthodologie

• Le marché et la régulation sont des moyens, non une fin en soi. L'ARCEP devrait analyser et réguler en faisant un focus sur l'intérêt général. Or, ce dernier est totalement absent de l'analyse.
  
  
• Les petits opérateurs, ceux avec des chiffres d'affaires insignifiants, ne sont pas considérés par l'ARCEP alors qu'ils ont des avantages : proximité des abonnés, éthique, adaptation aux territoires et aux gens, savoir-faire de terrain, etc.
  
  
• L'analyse de la concurrence par l'ARCEP se focalise sur les opérateurs sans jamais s'intéresser aux abonné-e-s alors que cet angle fait apparaître des manquements de la régulation. Exemple, sur la fibre optique, l'ARCEP compare les parts de marché sans se demander : le jour du raccordement de son immeuble (construction du PM), est-ce que l'abonné-e a le choix de son opérateur ? Dans la théorie du cadre réglementaire, oui. Dans la pratique, non, il n'aura accès qu'à l'opérateur commercial dont l'opérateur d'immeuble intégré aura construit le réseau. L'opérateur co-financeur du réseau arrivera plusieurs mois après. Et l'abonné-e ne verra probablement jamais un troisième opérateur venir raccorder sa piaule.
  
  
• L'ARCEP a du mal à identifier quand il n'existe pas d'offre parce qu'il n'y a pas de demande ou parce qu'il n'y a pas d'offres. C'est typiquement sur les offres d'accès de gros allumées sur fibre optique : le régulateur constate qu'il n'y a pas d'offres dans les ZTD et ZMD-AMII tout en restant bloqué sur "peut-être qu'il n'y a pas de demandes ?" ! L'absence de ce marché est problématique en soi, je vais y revenir. Cela est donc un paravent que l'ARCEP installe devant elle pour éviter d'avoir à se bouger.
  
  
• En 2015, l'ARCEP a pris une décision en défaveur d'Orange qui facturer son offre LFO en fonction de l'usage qui en était fait par l'opérateur locataire. Genre Free Mobile qui veut collecter du trafic de la boucle locale cuivre ou fibre, c'est tel tarif. Par contre, si c'est pour collecter du trafic provenant d'une antenne de téléphonie, alors c'est plus cher. On voit bien ici que le but est de retarder Free Mobile ! Un opérateur doit être neutre. C'est le sens du règlement européen sur la neutralité des réseaux en ce qui concerne les accès Internet vendus au détail. Reste plus qu'à extrapoler ça sur les offres de gros. LFO, c'est fait. Reste génie civil et compagnie.
  
  
• Le débit montant est le plus important. C'est lui qui est le marqueur de nouveaux usages : TVIP 4k fluide, envoi de fichiers plus rapides, vidéoconférence qui saccade moins, etc. C'est pour cela que la FTTH n'a rien à voir avec du câble à 5 mbps d'upload.
  
  
• L'ARCEP se trompe quand elle analyse le marché pro sous l'angle des offres avec GTR : la GTR est une garantie. Les offres pros sont plus des offres avec des besoins et des services particuliers qu'une offre sur laquelle on appose une garantie et des pénalités en cas de son non-respect.

Offres d'accès de gros activées

• Elles permettent l'émergence et l'existence d'une grande variété de petits opérateurs ;
  
  
• Elles fluidifient le marché en cela qu'elles rendent possible et simplifient le changement d'opérateur par un-e abonné-e ;
  
  
• Elles évitent les monopoles / duopoles / oligopoles sur les boucles locales ;
  
  
• Elles sont source de revenus pour les opérateurs qui les proposent d'où un meilleur taux de remplissage des infrastructures de l'opérateur constructeur de la boucle locale ;
  
  
• Elles permettent d'éparpiller le savoir-faire, la connaissance des réseaux, l'ingénierie des réseaux partout en France au lieu que tout cela reste à Paris. La connaissance des réseaux est un indice de développement des territoires. Ce point entre dans la mission « aménagament des territoires » confiée à l'ARCEP par l'article 42-1 du CPCE.
  
  
• Expliquer que garantir l'ouverture du marché en offres de gros passives permettra l'apparition d'une offre de gros active est une mauvaise lecture de l'histoire. L'expérience de l'ADSL montre le contraire : des offres de gros activées sont apparues très tôt sur le marché. Tarder à forcer l'apparition d'une offre de gros allumée sur la fibre fera que les petits acteurs s'essouffleront et disparaîtront. Il faut une offre de gros activée sur chaque boucle locale optique dès aujourd'hui.
  
  
• Envisager l'émergence d'un troisième opérateur co-investisseur sur le passif qui proposerait une offre de gros activée est pas top : un seul acteur = monopole. Il vaut mieux apporter le terreau pour que plusieurs opérateurs soient en mesure de proposer des offres de gros activées. De plus, il est peu probable qu'un acteur émerge s'il sait d'avance qu'il sera régulé dès qu'il montrera le bout de son nez.
  
  
• L'idée de faire émerger une offre de gros activée sur la fibre spécialement pour le marché des entreprises est pas top : une offre de gros activée généraliste sur laquelle on peut greffer de la QoS, des services et des garanties sera plus adaptée car elle apportera de la souplesse (une même offre sur plusieurs marchés).

Boucle locale et mutualisation

• Les boucles locales (cuivre, fibre, câble, radio, etc.) sont des infrastructures essentielles et des monopoles de fait. Elle devrait donc être une propriété publique. Pour la culture, la Constitution de 1946 dit précisément cela, plus celle de 1958. On aurait donc une séparation claire entre les opérateurs de boucles locales et les opérateurs commerciaux. Cela va à l'encontre du credo de l'UE de concurrence par les infras mais cela éviterait les monopoles privés. La mutualisation est peut-être plus efficace mais elle entraîne ce problème.
  
  
• Le non-engagement de la puissance publique dans les ZTD et ZMD-AMII dès lors qu'un opérateur déclare y allait aurait dû être "échangé" contre une obligation, pour ces mêmes gros opérateurs, de venir sur les RIP.

Transparence

• Ça serait top d'avoir un système d'information (SI) sur le génie civil d'Orange mais aussi sur celui d'autres structures (collectivités, ErDF, etc.) permettant à un nouvel opérateur de savoir quelles sont les infrastructures mobilisables pour monter des boucles locales. Même chose pour les boucles locales optiques : avoir plus d'informations, de manière unifiée, ça serait top. Hé oui, y'a toujours cette idée d'un SI commun sur la fibre qui permet d'obtenir les opérateurs et les infras à partir d'une adresse.
  
  
• En prolongement, ça serait cool qu'utiliser le génie civil existant ne nécessite pas de commander des études préalables pour des choses que l'opérateur sait faire car si s'agit d'une barrière tarifaire à l'entrée. Les infos dont on parle dans le point précédent devraient être disponibles dans des formats ouverts sinon il s'agit d'une barrière technique et financière à l'entrée. Enfin, afin d'éviter une barrière réglementaire, ça serait top que l'ARCEP n'organise pas trouze-mille groupes de travail (et consultations, aussi :- ) auxquels seuls les services des gros opérateurs peuvent participer.

L'ARCEP ne doit pas se désengager du cuivre

• Le cuivre va perdurer plusieurs décennies dans des zones qui subissent déjà la fracture numérique de plein fouet. Dans le Calvados, par exemple, il est prévu de fibrer les derniers bleds en 2037 ! Sans compter que tous les gros chantiers ont toujours du retard. Il est très fort probable que l'ARCEP aura encore des différends à régler, de la régulation asymétrique à appliquer, etc.
  
  
• Se désengager trop tôt du cuivre amplifiera la fracture numérique : les zones déjà défavorisées subiront les défauts d'un marché non régulé en plus de l'absence de fibre. Cumul des inégalités et de la discrimination entre les territoires.
  
  
• C'est toujours dans les périodes de transition que les atteintes (commerciales ou aux droits) sont les plus fortes :
  • Réduction du nombre d'opérateurs auxquels un particulier ou une entreprise peut souscrire. On a donc une réduction de la liberté de choix des gens ;
    
    
  • Quand FDN ne parvenait pas à signer un contrat de collecte ADSL au début des années 2000, son nombre d'adhérents a fortement diminué. Sur la même période de nombreux opérateurs qui opéraient sur le bas débit sont morts ou ont fusionnés

Solutions de repli pour les territoires qui n'auront pas la fibre dans les 10 prochaines années

• 4G / satellite : débit partagé, ça ne permet ni les usages de demain ni même de produire et diffuser des contenus et services depuis chez soi. La latence du satellite exclut tous les usages interactifs.
  
  
• Effectuer de la montée en débit cuivre puis un fibrage revient plus cher que de juste déployer de la fibre. Sans compter que les collectivités territoriales qui auront financé de la fibre ne pourront pas financer de la fibre juste après.
  
  
• La fibre est la seule technologie qui supprime les disparités, les inégalités entre lignes : les caractéristiques (débit, latence), ne changent pas vraiment en fonction du nombre d'utilisateurs connectés simultanément ni en fonction de l'état de la ligne et de son ancienneté ni en fonction de la distance depuis le central téléphonique.
  
  
• Il faut envisager d'autres solutions palliatives mais ça nécessite de s'adapter aux territoires, d'arrêter de concevoir le réseau depuis un point donné du territoire en espérant que ça s'applique partout pareil. Il faut encourager les initiatives (associatives ou non) de construction de boucles locales radio / fibre. Le Wi-Fi point-à-point (unidirectionnel) permet des débits de 30 à 50 mbps symétriques, ce n'est pas à négliger. Il faut que les élu-e-s arrêtent de penser qu'il n'y a qu'Orange qui a le droit de déployer des réseaux de communications électroniques en France !
  
  
• Le fait de déployer des boucles locales n'empêche pas ces structures d'avoir recours à des offres de gros allumées qui peuvent servir à collecter le trafic et à le faire remonter jusqu'à un datacenter ainsi qu'à agir sur d'autres supports si ceux-ci sont plus adaptés à une zone géographique.

De très bons rappels sur le chiffrement de Vernam suivis de mises en garde sur un projet de crypto-bullshit post-Snowden de plus… À lire, au moins les rappels sur Vernam.

Le chiffrement de Vernam (ou masque jetable, ou OTP (One Time Pad)) est un système de chiffrement inventé en 1917 par Gilbert Vernam. Il a pour particularité d’être prouvé mathématiquement comme incassable, c’est-à-dire qu’il n’existe et n’existera jamais de méthode plus efficace que la force brute pour tenter de déchiffrer un message codé sans connaître la clef de chiffrement.

[...]

Ce système est effectivement incassable puisque toute clef K déchiffrera quelque chose. Mieux, il est toujours possible de trouver une clef K′ tel que le déchiffré de C donnera n’importe quel texte donné. Vous aurez donc beau tester les 2X clefs possibles, vous n’obtiendrez rien d’autre que l’ensemble des 2X messages possibles, certains n’ayant littéralement aucun sens, d’autres formant des textes parfaitement sensés et un seul étant le message réel.

Ce protocole incassable n’est réellement incassable qu’à 3 conditions.

• La clef doit être au moins aussi longue que le message à chiffrer. En effet, la cryptographie a horreur des répétitions, et utiliser la même clef pour chiffrer plusieurs bouts du message conduit aux mêmes attaques que pour le chiffrement ECB.
• La clef doit être vraiment aléatoire. Pas question d’utiliser un générateur pseudo aléatoire, puisqu’un attaquant s’attaquera alors à bruteforcer ce CSPRNG pour trouver la clef en moins de 2X essais.
• La clef ne doit jamais être réutilisée. Sinon on tombe à nouveau dans les problèmes de réutilisation de clef.

La clef doit être générée par un processus réellement aléatoire. Cela nécessite du matériel dédié, utilisant des processus physiques aléatoires pour générer de la donnée, par exemple la désintégration atomique, le bruit thermique ou des phénomènes quantiques.

Ce matériel doit être sous votre entier contrôle, il est inenvisageable que quelqu’un d’autre ait accès à ce matériel et aucun intermédiaire ne saurait être suffisamment de confiance pour vous fournir de telles données.[...] Dans le cas contraire, il serait en effet très facile pour un attaquant de compromettre cette machine par un procédé quelconque ou de soudoyer un intermédiaire pour vous délivrer du faux aléatoire. Un tel déploiement de matériel et de sécurité donne à un tel système un coût très largement prohibitif, surtout comparé à la sécurité supplémentaire réellement apportée par rapport à des systèmes à coût négligeable comme AES (ou CHACHA20 si vous avez peur de la NSA).

Le problème du chiffre de Vernam est que tous les correspondants doivent posséder une copie de la clef et surtout que cette clef ne peut pas être transmise sur un canal non fiable.

Si on suppose un canal informatique fiable, alors Vernam est sans intérêt puisqu’on aurait tout intérêt à utiliser ce canal pour échanger directement les données plutôt que la clef. Une rencontre physique juste avant l’établissement d’un canal protégé par Vernam est aussi un non-sens, puisqu’on aurait alors mieux fait de s’y échanger les données au passage… Il n’y a donc pas d’autre moyen d’échange de la clef qu’une rencontre physique très antérieure à la communication chiffrée.

Le coût en devient tout aussi prohibitif et dans tous les cas peu utilisable en pratique par le commun des mortels.
Comme pour la génération, l’absence de tiers de confiance (rencontre physique des correspondants) est plus abordable mais généralement difficile à organiser, l’utilisation de moyen informatique étant souvent là pour compenser de l’éloignement physique (communication trans-nationale) ou de l’impossibilité de déplacement (correspondant en situation délicate dans son pays).

On voit aussi que Vernam nécessite autant de partages de clef que de tuples de correspondants et que la clef d’un correspondant A ne peut pas être utilisée pour échanger avec B.

Chaque envoi de message nécessite l’utilisation d’une nouvelle clef, sous peine de compromettre la sécurité du système. Étant donné la difficulté de génération et de transmission de la clef, le chiffre de Vernam réclame donc la mise-en-œuvre d’une sorte de dictionnaire de clefs. On va générer une très grosse quantité de données aléatoires (par exemple un fichier de 2Go), qu’on va transmettre en une seule fois lors d’une rencontre physique.

Lors de l’envoi d’un message, on va alors piocher dans ce paquet de données pour générer notre clef, chiffrer notre message puis détruire les données de la clef (évite la réutilisation et une compromission ultérieure). Une manière de procéder est par exemple de lire le fichier de données séquentiellement et de le remplir de 0 au fur et à mesure de l’utilisation. Se posent du coup deux problèmes.

D’abord, comment garantir que le(s) récepteur(s) auront bien encore toutes les données nécessaires à la génération de la clef. Le support des données aléatoires (disque dur, clef USB, feuille de papier…) peut en effet s’être dégradé avec le temps (on parle ici de plusieurs années de rétention potentielle), avec des secteurs endommagés, des trous, des bits inversés à cause du rayonnement cosmique (non, ce n’est pas une blague, une barrette de RAM de 4Go connaît un bit-flip tous les 5j à cause de ça)…

Plus grave, une situation de compétition existe sur la consommation des données. Par exemple, si plus ou moins au même moment A envoie un message à B et consomme sa plage [X, X+M] alors que B envoie à A en consommant sa plage [X, X+N], quand A et B vont recevoir leur message, leur plage [X, X+min(M,N)] va déjà être consommée et aucun des deux n’aura accès à la clef permettant le déchiffrement ! (–edit– Un anonyme m’a fait remarquer dans les commentaires qu’en plus d’empécher le déchiffrement par les personnes légitimes, on a en fait chiffré deux messages avec un même bout de clef, et donc un attaquant potentiel peut lui calculer la somme des deux messages chiffrés pour obtenir les textes en clair…)

On peut régler partiellement ces problèmes. On peut par exemple demander à avoir une clef différente pour chaque émetteur. Dans l’exemple précédent, si A utilise un cahier pour chiffrer avec B et un autre pour déchiffrer B, alors chaque va consommer sa propre première page pour le chiffrement, laissant intacte celle de déchiffrement. [...] On peut aussi imaginer ne détruire la clef qu’à l’émission et indiquer dans le message le numéro de page à utiliser pour le déchiffrement, mais alors on affaiblit la sécurité (disparition de la confidentialité persistante : si un cahier tombe, tous les messages précédemment émis sont compromis).

Blind Eagle

Blind Eagle vient de lancer un Kickstarter, et rejoint donc le cimetière des projets charlatans vous promettant le retour de l’être aimé votre vie privée. Ce projet se présente comme une solution totalement sûre puisque basée sur le chiffrement de Vernam qui est lui totalement sûr (en théorie seulement, comme montré précédemment).

Déjà pour rappel, un projet qui se présente comme un 100% sûr, absolument indécryptable (sic), infaillible, vous pouvez être sûr que c’est juste du 100% absolument bullshit. Voir à ce sujet une très bonne FAQ (malheureusement en anglais) sur comment détecter un projet bullshito-crypto.

Le projet annonce générer les clefs avec du matériel quantique (100% sécurité, audité, approuvé, certifié, fiable, whatever, sinon ce n’est pas drôle…). La qualité de l’aléatoire obtenu ne pourra de toute façon pas être contrôlée par l’utilisateur, puisque un tel système se doit d’être en écriture seule, en tout cas pour la partie de stockage des clefs (leur

Même s’ils utilisent réellement un générateur quantique, le stockage des clefs et leur transmission va être un véritable challenge pour ne pas affaiblir la sécurité de Vernam. Ils annoncent une livraison en main propre sous emballage scellé, mais je les imagine mal assurer une livraison par leur soins et donc plutôt recourir à un transporteur tiers, réduisant à néant la sécurité du système.
L’emballage scellé n’apporte rien en termes de sécurité puisqu’un scellé n’a de sens que s’il est identifiable par le récepteur (par exemple dans le cas de la cérémonie DNSSec, on s’assure que les scellés sont les mêmes que ceux de la dernière cérémonie). Une interception du paquet et un remplacement du scellé par un autre ne sera pas détectable.

Dans tous les cas, Blind Eagle pourra conserver une copie des clefs générées, réduisant à nouveau la confiance en ce système à quelque chose proche de la constante de Planck. Pire, Blind Eagle ne se cache pas de les conserver pour faire fonctionner leur système en mode « solo » (voir juste après).

[...]

Un des modes de fonctionnement (« solo ») de Blind Eagle permet de s’affranchir (ie. de casser tout le système de Vernam…) de l’échange de clef en introduisant un point de centralisation. Vernam impose en effet que l’émetteur et le destinataire procèdent à un échange de clef avant la communication, ce qui est difficile à réaliser en pratique. Blind Eagle va alors plutôt faire du chiffrement entre vous et eux, puis entre eux et votre destinataire. Oh wait ! Ça ne serait pas exactement la notion de man-in-the-middle en cryptographie ?

[...] On me signale en plus qu’ils ont l’ambition d’avoir plusieurs centres de données, donc votre clef privée va au pire se retrouver un petit peu partout sur la surface du globe, au mieux être centralisée à un seul endroit avec tout plein de machines y ayant accès… [...]

Comme d’habitude en cryptographie, la sécurité n’est réellement possible qu’avec du logiciel libre, avec le code-source accessible et analysable par la communauté.

Or ici, rien n’est publié, alors que ça devrait être l’action n°1 à réaliser, avant même toute communication officielle et mise à disposition du public, afin que la communauté crypto puisse faire les remarques nécessaires et évaluer réellement la sécurité de la solution proposée.

[...]

Mais où est donc votre cryptologue ? Un « expert » (même si je déteste ce mot) en sécurité ? Un papier de recherche appuyant votre méthodologie ou vos assertions sur votre système 100% fiable ?

Non, rien de tout ça. Juste une équipe de personnes qui n’ont a priori pas touché à la sécurité au mieux depuis leur sortie d’école pour les techniques, au pire jamais de leur vie pour les autres.

Au contraire, quand certaines personnes proches du domaine de la sécurité (Geoffroy Couprie par exemple, qui leur a gentiment proposé un audit, ou moi-même) leur ont posé des questions ou soulevé des problèmes, le projet a très vite fait n’importe quoi, allant jusqu’à publier des correspondances privées, ou même à supprimer leur tweets. Pour un projet prônant la confiance, la transparence et le respect de la vie privée, on repassera.

[...]

Ne dites donc plus jamais à vos utilisateurs que vous implémentez un Vernam ou que votre technologie est prouvée comme étant théoriquement sûre, ce n’est pas vrai et donc au mieux un mensonge, au pire une pratique commerciale déloyale. GPG, TLS, HTTPS ou OTR seront en tous points plus sécurisés que votre solution, même dans leur version la plus faible, jusqu’à preuve mathématique du contraire que vous devrez apporter.

Très intéressant feedback sur les SSII : actualisé, sans aigreur, avec des arguments fondés qui vont au-delà de la simple technique. J'en recommande la lecture.

Ce texte a plutôt pour vocation à éclairer les futurs candidats sur les conditions qu’on peut rencontrer dans une SSII. Comme beaucoup maintenant, je considère qu’une SSII est un bon tremplin pour un jeune diplômé, mais qu’il faut aussi savoir tourner la page quand on sent que ça peut déraper.

La diversité des domaines permet de monter en compétence rapidement et de toucher à plein de sujets et de technos différentes, chose qu’il est beaucoup plus difficile de réaliser sur un poste fixe dans une société standard où votre poste n’évoluera que très peu. Mais les conditions de travail n’y sont pas toujours très roses, et il faut en avoir conscience, surtout si comme moi on a des difficultés à ne pas pouvoir faire son travail correctement (au sens de l’état de l’art).

[...]

2012 . L’année charnière. La crise est passée par là (même si elle a à mon avis bon dos), les relations clients deviennent plus difficiles. Les budgets ne sont plus là, les délais non plus. Les projets continuent à rentrer mais la concurrence entre SSII fait que les prix sont tirés vers le bas, chacun voulant rentrer des projets et les volent aux autres en massacrant les prix. Les clients n’ont plus les yeux en face des trous et en tout cas des moyens totalement décalés par rapport à leurs besoins.

Les clients ont commencé à inventer de nouveaux modes de gestion de projet, avec des notions de « POC (preuve de concept) » (comprendre du code kleenex que si ça marche on garde, si ça ne marche pas on jette, et que dans les 2 cas, on cherche à ne pas payer le fournisseur quand même), de « challenge » (comprendre qu’on sait que c’est infaisable ce qu’on demande mais que tu pourrais quand même faire un effort quoi).

Les méthodes agiles ont aussi eu le malheur de devenir le buzz-word du moment, et du coup sont apparues dans les plaquettes et propositions commerciales. Sauf qu’elles sont devenues la justification pour faire n’importe quoi, comme ne plus du tout faire de spécification, supprimer les tests unitaires ou la revue de code, ou encore livrer n’importe quoi très vite.

Les développeurs se retrouvent du coup avec des projets sous-vendus (50 à 100 jours max) et une qualité technique massacrée. L’intégration continue a disparu des écrans radars, tout comme la revue de code. Les équipes ne sont plus formées, le niveau technique global chute drastiquement, les « têtes » qui tenaient les projets à bouts de bras partent. Les chefs de projet senior sont remplacés par des juniors qui n’ont de chef ni la formation ni la volonté ni le charisme nécessaire pour tenir tête aux commerciaux et à la direction. Il n’y a même plus vraiment d’équipe projet, ou alors se résumant à un développeur débutant encadré par un développeur à peine plus senior propulsé chef de projet, tout étant dorénavant géré par les commerciaux en pratique.

2015 . Le coup de grâce. Les buzz-words sont de retour. « Big-data », « cloud », « IoT », « cyber-sécurité ». Plus aucun appel d’offre ne sort sans en contenir plusieurs sinon tous. On fait n’importe quoi, et cette fois non seulement d’un point de vue commercial et technique, mais aussi, et c’est encore plus grave, d’un point de vue éthique. Les projets qui dépassent les 10 jours-hommes se comptent sur les doigts d’une main et ceux avec plus de 2 personnes affectées dessus aussi.

[...]

Vous l’aurez compris, je ne me sens dorénavant plus à ma place. Je n’ai plus le temps ni les ressources pour faire correctement ce que j’estime être mon travail.

Techniquement, je n’ai plus le temps de faire de revue de code, de former les nouveaux arrivants ou de mettre en place les outils pour faire du code de qualité, parce que les commerciaux gardent la main sur l’ensemble des manettes et ont transformé les ingénieurs en techniciens voire en ouvriers. Pas étonnant que les Chinois ou les Indiens grignotent de plus en plus le marché, ils coûtent 10× moins chers pour une médiocrité équivalente.

Éthiquement, les projets réalisés sont de plus en plus en contradiction avec mes idéaux, avec des objets connectés où la sécurité est bien le dernier des soucis et où la vie privée n’existe plus, même en option. Parce que le discours commercial ambiant est en contradiction totale avec les nécessités techniques, surtout dans une ère post-Snowden.

Humainement parlant, les délais sont intenables, le stress élevé, la pression aussi. Les moyens ne sont plus suffisants pour travailler, j’en arrive même à devoir héberger des projets sur mes propres machines parce que ceux qui devaient faire cette partie ne veulent/peuvent/savent pas le faire, faute de moyens et de temps. Parce que la rentabilité ne peut être maintenue qu’en sur-exploitant le personnel.

J’ai déjà plusieurs fois alerté ma hiérarchie sur les problèmes rencontrés, ça a conduit au mieux à tenter de me retourner les neurones à coups de justification bullshitto-marketo-commercialo-financier, en général à aucune action sérieuse qui suit et au pire à des prises de bec de plus en plus violente.

[...]

Le travail en SSII est aussi un coup de roulette russe permanent, une épée de Damoclès. Si vous avez la chance de réussir à rester plus ou moins sédentaire au sein du bureau d’études pour réaliser les projets forfaitisés, vous pouvez contrôler a minima l’impact de votre vie professionnelle sur votre vie personnelle.

Mais si vous avez le malheur d’être envoyé en mission, parfois à l’autre bout de l’Île-de-France, vous pouvez être baladé tous les X temps (X variant de 3 mois à 10 ans) d’un client à l’autre, d’un lieu à l’autre, dans des conditions qui en plus sont théoriquement illégales au vu du Code du Travail (délit de marchandage et prêt de main d’œuvre illicite).

Si vous êtes parmi les chanceux du premier groupe, vous n’avez en plus pas intérêt à devenir le petit caillou dans la chaussure du service, sinon le second groupe vous tend rapidement les bras. Comme on dit, en SSII, le licenciement n’existe pas, on appelle ça « partir en mission »… :)

Dans mon cas, mon dernier départ en mission a aussi été synonyme du sacrifice de ma vie associative et collaborative. Il est en effet bien difficile de trouver du temps libre et de la motivation pour travailler sur des projets personnels quand vous faites 8h-20h « effectif » tous les jours, dont 3h de transport dans les bouchons (non comptés dans les temps de travail, merci la SYNTEC !). C’est à mon avis ce sacrifice qui a accéléré ma décision de partir.

MON CONSEIL POUR LES GENS QUI SOUHAITENT SORTIR DU LOT : Prendre l'A20 direction Toulouse

:DDDD

(Lot = département).

Ça date, je n'ai pas tout lu, je garde juste une information que je trouve méga intéressante :

Nous gardons en mémoire les anciennes erreurs tant du législateur national que du régulateur. Par exemple sur la redevance due par les opérateurs. Les textes européens indiquent bien, depuis le début de l’ouverture du marché des télécoms, que les États membres peuvent demander une redevance aux opérateurs pour financer l’autorité de régulation, et que cette redevance devait être équitable. Le législateur français avait traduit ça en « 20 k€ pour tout le monde, 80 k€ pour l’opérateur historique ». Tous les micro-opérateurs qui existaient avant l’ART, dont FDN, ont donc eu ce réflexe de survie : ne pas se déclarer, pour ne pas mourir. Et l’ART de poursuivre les opérateurs qui tombaient dans son radar, comme ce fut le cas de NetPratique par exemple.

Pour moi, cela montre qu'il ne suffit pas de faire, de "make", de monter une initiative et de la faire vivre. Il faut aussi exister au niveau politique et agir auprès des autorités qui régissent le secteur dans lequel l'initiative évolue. Sans ça, l'initiative se fera bouffer, se fera marcher dessus sans complaisance. En rapport avec http://shaarli.guiguishow.info/?xo1oaQ .