mardi 14 octobre 2008

Ouvrons les yeux!!



Ce qui se passe aujourd'hui dans le monde est, si on y regarde de "prêt", le plus grand vol à l'échelle de la planète!!!
Mais qui sont les voleurs et les volés?? Personne n'en parle au infos!
La police est-elle au courant?

Forcément que non, les voleurs, pour réussir un tel coup, se sont déjà mis dans la poche la plupart de ceux qui pouvaient les dénoncer...

Pour comprendre ce qui se passe, il faut remonter très loin...
Au moment où les banques sont nées et surtout quand elles ont commencé à prêter de l'argent qu'elles n'avaient pas.
Le phénomène touche aujourd'hui le monde entier, l'argent qui circule n'existe plus! C'est en l'empruntant qu'il se créé...

Plutot que de gérer la monnaie eux-même, les Etats sont contraints d'emprunter l'argent dont ils ont besoin, grossissant la dette qui finallement coute plus cher en remboursement d'intérêt qu'en capital utile...
Le comble: L'état français s'apprête à réemprunter le l'argent (aux banques) pour financer les banques!! Incroyable mais vrai!!!

Pour en savoir plus, il faut connaitre l'histoire de l'argent:
http://www.bankster.tv/argent_dette.htm
http://www.dailymotion.com/relevance/search/banksters

Alors vite!! Pour sortir de la crise qui nous ronge: Agissons!!

vendredi 19 septembre 2008

Building a Multisourced Infrastructure Using OpenVPN

Building a Multisourced Infrastructure Using OpenVPN
Building a Multisourced Infrastructure Using OpenVPN
February 1st, 2008 by Dmitriy Samovskiy in

* HOWTOs

Have you ever needed to expand your colocated servers at more than one provider and allow applications to communicate as if they were on the same LAN, possibly over multiple sets of firewalls and layers of NAT? Or, maybe you've wanted to move from one hosting service to another to take advantage of lower pricing or better uptime but would have preferred to do it gradually instead of in a single swoop (and a weekend-long maintenance window)? Or, maybe you've considered the Amazon EC2 cloud to host part, but not all, of your infrastructure? If your answer to any of these questions is yes, what you want is essentially a multisourced infrastructure.

The Amazon EC2

The Amazon EC2 (Elastic Compute Cloud) is a Web service that allows users to provision new machines in an Amazon-hosted virtualized infrastructure in a matter of minutes, using a publicly available API. Users get full root access and can install almost any OS or application in their Amazon Machine Images. Web service APIs allow users to reboot their instances remotely and scale capacity quickly if necessary, by adding tens or even hundreds of machines. Additionally, there is no up-front hardware setup costs—Amazon charges only for the capacity you actually use; there is no minimum fee. As more applications find their way to Amazon's virtual computing environment, system administrators are looking for ways to provide secure connectivity over the public Internet between new machines in the Amazon EC2 and old machines in their regular data centers. This article describes one such technique—how to build a multisourced infrastructure based on OpenVPN.

Let's take a look at a simple distributed application, which consists of multiple services, a LAMP stack. Traditionally, you would start with Apache and MySQL on a single server. As your site grows, you would provision another server from your provider and add a second Apache instance. Later, you might want to provision yet another machine to be a dedicated database server to improve performance. This is a typical single-sourced infrastructure—all services run within a single physical environment, controlled and supported by a single provider.

In contrast, with a multisourced infrastructure, you no longer are limited to one provider or one data center. You are free to mix and match hosting plans from different providers to suit your business and architecture better, and you can use as many providers as you like. Your applications still can communicate with one another, but instead of having a physical LAN, it's now a virtual LAN that sits on top of public Internet links. You can grow your services horizontally and achieve better geographic redundancy and fault tolerance at the same time, all without significant changes in your application. If it works in a single-sourced physical LAN, it most likely will work in multisourced virtual LAN as well.

Additionally, you can leverage the strengths of a particular provider for just a subset of your services. Going back to the LAMP stack as our example, with Amazon EC2, you can provision many Apache instances in response to the current load quickly; although you might prefer to run MySQL on bare metal elsewhere instead of in an EC2 virtual machine.

Finally, this method allows you to expand your corporate infrastructure outside your current data center or allow outside services to use applications in your corporate data center. Consider a remotely hosted data-crunching cluster that you rent by the hour, which uses your corporate data warehouse system for its input. As you can see, a multisourced infrastructure is more flexible and can accommodate various scenarios and needs.

Figure 1. Multisourced Infrastructure: OpenVPN Virtual Links

In this article, I describe a particular implementation of the multisourced infrastructure concept that we at CohesiveFT (www.cohesiveft.com) developed using OpenVPN and that has been running in our production environment since mid-summer 2007. We chose OpenVPN primarily because it uses standard OpenSSL encryption, runs on multiple operating systems and does not require kernel patching or additional modules. The latter benefit is of key importance. Many Virtual Private Server (VPS) hosting solutions currently provide great service with pricing that is often better than other forms of hosting. These providers build guest OS kernels specifically tailored for their environment and method of virtualization. As a result, you probably want to avoid rebuilding the Linux kernel on your VPS as much as possible. Not that it can't be done, but you can save some time and probably get faster technical support if you don't do it.

Among the alternatives to OpenVPN, there is Openswan, a code fork of the original FreeS/WAN Project, but it requires a kernel patch to support NAT traversal, according to its wiki (wiki.openswan.org/index.php/Openswan/Install).

The OpenVPN protocol also is firewall-friendly, as it can pass all traffic over a single UDP tunnel (the default port is 1194). That feature, coupled with SSL encryption, makes this solution very difficult to attack when data packets pass through the public Internet.

OpenVPN turned out to be a great choice and offered us all the functionality we expected, except for one very important feature, fault tolerance. When you use a VPN to provide corporate network access to remote users, the solution is very simple—you deploy several OpenVPN servers and configure each server with its own network segment (for example, server 10.5.0.0 255.255.0.0 and server 10.6.0.0 255.255.0.0). In a typical scenario, the dynamic IP address assigned to a remote user will not matter much, as long as you configure firewalls, applications and services to allow both subnets.

When you build a multisourced infrastructure, however, this is not an acceptable solution, unless you want servers to change their IP addresses from time to time. To satisfy redundancy and fault-tolerance requirements, we needed an active-active pair of OpenVPN servers to share a common address space—all hosts must be able to access each other by static IP addresses at all times, no matter which OpenVPN server provides connectivity at either end of the communication. Then, if we lose one OpenVPN server, the other will provide all connectivity. And, if they are both up, both will be accepting connections from clients to share the load. This feature was not available as a part of the OpenVPN source distribution, so we developed a standalone dynamic routing dæmon to facilitate active-active load balancing. You can find its source code, along with useful links, use-case scenarios and mailing lists, at www.cohesiveft.com/multisourced-infra.
Building Your Virtual LAN

You need two machines to run the OpenVPN dæmon in server mode (we refer to them as vpnsrvA and vpnsrvB, and let's assume their physical IP addresses in your network are 192.168.7.1 and 192.168.17.1, respectively) and two new private subnets: data (for example, 10.100.100.0/24) and management (10.200.200.0/24). All of your applications and services will run in the data subnet, and vpnsrvA and vpnsrvB will exchange runtime status and routing information in the management subnet. Think of these two machines as virtual network switches for your virtual LAN. Also, note that these subnets do not have to be class C; you can choose a bigger data network, especially if you are planning to connect a large number of hosts.

Listing 1a. OpenVPN Server Configuration for vpnsrvA

server 10.100.100.0 255.255.255.0

ifconfig 10.100.100.1 10.100.100.2


push "route 10.100.100.0 255.255.255.0"
push "route 10.200.200.0 255.255.255.0"
dev tun
proto udp
user nobody
persist-key
persist-tun
dh keys/dh1024.pem
ca keys/ca.crt
cert keys/vpnsrvA-1.crt
key keys/vpnsrvA-1.key
comp-lzo
verb 3
keepalive 10 60
client-config-dir ccd
management tunnel 5656 /etc/openvpn/pass

Listing 1b. OpenVPN Server Configuration for vpnsrvB

mode server
tls-server
ifconfig 10.100.100.10110.100.100.102
ifconfig-pool 10.100.100.410.100.100.251
route 10.100.100.0255.255.255.0
push "route 10.100.100.0255.255.255.0"
push "route 10.200.200.0255.255.255.0"
dev tun
proto udp
user nobody
persist-key
persist-tun
dh keys/dh1024.pem
ca keys/ca.crt
cert keys/vpnsrvB- 1.crt
key keys/vpnsrvB-1.key
comp-lzo
verb 3
keepalive 10 60
client-config-dir ccd
management tunnel 5656 /etc/openvpn/pass

Configure vpnsrvA and vpnsrvB as OpenVPN servers for the data subnet (Listings 1a and 1b). You may add more configuration options as needed. Note that the “server” line in the configuration file is a shortcut and cannot be used for both vpnsrvA and vpnsrvB. It actually expands to a set of commands that would have assigned 10.100.100.1 to both servers (see the OpenVPN man page for more details). We want an active-active configuration; therefore, we need vpnsrvA and vpnsrvB to be in the same subnet but to have different IP addresses. To accomplish this, we explicitly expand the server definition for vpnsrvB and assign it the 10.100.100.101 IP address.

Another important note is that the client configuration directory (usually called ccd) and keys directory (called keys) need to be identical on both vpnsrvA and vpnsrvB. One of the easiest ways to accomplish this is to use rsync. rsync allows us to keep it simple and avoid extra variables in the mix. Plus, we always can switch the direction of rsync and promote either of the servers to be the master. For now, let's assume that vpnsrvA is the master and that vpnsrvB mirrors the ccd and keys directories from vpnsrvA using rsync. You will create keys (preferably using the easy-rsa package that ships with OpenVPN) and update the ccd entries on the master server.

Listing 2. OpenVPN Client Configuration

# Note: "remote" must point to servers' physical
# (not virtual) IP addresses
client
remote 192.168.7.1
remote 192.168.17.1
dev tun
proto udp
user nobody
persist-key
persist-tun
keepalive 10 60
comp-lzo
ca keys/ca.crt
cert keys/client-1.crt
key keys/client-1.key
ns-cert-type server

At this point, you can configure several hosts on your network as OpenVPN clients (Listing 2). Each host will have its own certificate/key pair, and the ifconfig-push directive in the ccd entry for this host will set its IP address (see Resources for a link to the OpenVPN HOWTO for a detailed explanation of how to set it up). We tie the virtual IP address to a host based on its certificate/key pair, in much the same way as in a DHCP configuration you would tie an IP address to a host based on its Ethernet MAC address. Therefore, each client must have its own unique certificate/key pair.

Note that we use OpenVPN's built-in capability to round-robin between multiple servers and reconnect after connectivity failures, which is controlled by the keepalive option. Once this is done, you should be able to start the OpenVPN clients, and they should at least be able to communicate with their current OpenVPN server and refer to it by IP—10.100.100.1 or 10.100.100.101. If your client connects to vpnsrvA and you bring down the openvpn dæmon on vpnsrvA, the client will detect it and automatically reconnect to vpnsrvB.

A quick note about firewalls—in a virtual LAN, your main data interface will be called tun0. Therefore, all the rules you used to define for interface eth0 in a single-sourced configuration will need to be redefined for tun0. The Ethernet interface, however, will require additional rules to allow UDP on port 1194 (OpenVPN) from the client machines to both vpnsrvA and vpnsrvB.

The setup that we already have accomplished is somewhat fault-tolerant. If vpnsrvA becomes unavailable, all clients will reconnect to vpnsrvB, and connectivity will be restored. In other words, this is active-passive redundancy. But, what will happen if both vpnsrvA and vpnsrvB are up? Let's assume that host1 and host2 run the openvpn dæmon in client mode. host1 connected to vpnsrvA and was assigned 10.100.100.25; host2 connected to vpnsrvB and was assigned 10.100.100.41. The routing table on vpnsrvA is shown in Listing 3. In this scenario, when host1 attempts to ping 10.100.100.101, its outgoing packets will be routed first to vpnsrvA but then will go back to the same tun0 interface, because vpnsrvA does not know about the existence of vpnsrvB. Similarly, when host1 attempts to ping host2, vpnsrvA also will send these packets back, as indicated by the 10.100.100.0/24 route. As a result, both operations will fail.

Listing 3. Parts of the Routing Table on vpnsrvA

10.100.100.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
10.100.100.0 10.100.100.2 255.255.255.0 UG 0 0 0 tun0

To address this issue, we developed a dynamic routing dæmon called cube-routed (download it from www.cohesiveft.com/multisourced-infra). It shares routing information between vpnsrvA and vpnsrvB and adjusts routing tables depending on which client connects to which server in near real time. Its internal structure is not very complex. One thread connects to a local OpenVPN dæmon process via its management interface (see the management option in the OpenVPN configuration file) and regularly runs the status command to update the list of clients connected locally. Another thread publishes this information for the remote instance of cube-routed. The third thread regularly reads a list of connected clients from the remote instance of cube-routed. Finally, the fourth thread adjusts the local routing table based on the following two rules: 1) adds a host route for every host connected to the remote OpenVPN server and 2) deletes the host route for every host connected to the local OpenVPN server.

cube-routed instances will exchange information over the management subnet we selected earlier. Create a second tunnel tun1 between vpnsrvA and vpnsrvB. vpnsrvA can be a server with IP 10.200.200.1, and vpnsrvB is its client with IP 10.200.200.5. You can use the configuration files from Listings 1 and 2 as a basis, but remember to adjust the IP addresses and select a different port—for example, you could add port 11940 to both the server and client. Start both OpenVPN dæmons, and use ping 10.200.200.1 and ping 10.200.200.5 to verify connectivity between them.

Now, create configuration files for cube-routed on both vpnsrvA and vpnsrvB, as shown in Listings 4a and 4b, and start both instances as root with the path to the configuration file as the only parameter (note that OpenVPN must already be running, and the tun0/tun1 interfaces on both vpnsrvA and vpnsrvB must be up).

Listing 4a. vpnsrvA cube-routed Configuration File

vpnsrvA
mgmt_interface = tun1
data_interface = tun0
remote_mgmt_ip = 10.200.200.5
remote_data_ip = 10.100.100.101
openvpn_mgmt_pass_file = /etc/openvpn/pass
openvpn_mgmt_port = 5656
cube_routed_port = 5657

Listing 4b. vpnsrvB cube-routed Configuration File

mgmt_interface = tun1
data_interface = tun0
remote_mgmt_ip = 10.200.200.1
remote_data_ip = 10.100.100.1
openvpn_mgmt_pass_file = /etc/openvpn/pass
openvpn_mgmt_port = 5656
cube_routed_port = 5657

Once you start everything and after several minutes of initial convergence time, host1 from the example above will be able to communicate with host2, even though they connected to different OpenVPN servers. Thus, you've achieved a fully fault-tolerant virtual LAN connectivity, with data traffic encryption as an added bonus.
Conclusion

This implementation is not without its limitations. First, applications that use broadcast or multicast will not work with OpenVPN's tun device. You can use the same network layout as described here, but instead of tun, experiment with OpenVPN's tap device to work around this. Second, latency of network links over the public Internet is significantly higher than that of Ethernet. If this is an inherent requirement for your application, you probably should leave this part of your infrastructure single-sourced. Third, because we use UDP-based tunnels, OpenVPN links will tend to go up and down more often than Ethernet, especially during times of network congestion. You can implement data caches, avoid long-lived TCP connections, focus on network exception-handling logic and experiment with TCP tunnels to reduce negative impact. Finally, there are exactly two OpenVPN servers in this setup. This generally should be sufficient, as it doesn't affect the number of actual hosts that you have connected to your multisourced infrastructure. If for some reason you need more than two, it becomes much more difficult to implement route sharing among cube-routed instances. In that case, you might want to consider a messaging system instead of raw sockets (for example, RabbitMQ). All in all, in our case, we found that the overall benefits of a multisourced infrastructure far outweighed the problems caused by these limitations, particularly if you design your architecture with these limitations in mind.

Multisourced infrastructure is a logical extension of its single-sourced predecessor, similar to the distributed service-oriented architecture, which came after monolithic applications and enabled greater flexibility, a faster development cycle and higher availability. It can help you design a smarter architecture and avoid a lock-in to a single hosting provider, on top of a standard time-tested open-source OpenVPN.

Resources

OpenVPN: openvpn.net

OpenVPN 2.0 HOWTO: openvpn.net/howto.html

“Meet OpenVPN” by Hans-Cees Speel: www.linuxjournal.com/article/7949

“Introduction to OpenVPN” by David Bogen: www.osnews.com/story.php/5803/Introduction-to-OpenVPN

Openswan: www.openswan.org

cube-routed: www.cohesiveft.com/multisourced-infra

Amazon EC2: aws.amazon.com/ec2

RabbitMQ: www.rabbitmq.com

Dmitriy Samovskiy works at CohesiveFT (www.cohesiveft.com), an innovative maker of custom virtualized application stacks, where he focuses on open-source technologies, distributed applications, systems integration, Python and Ruby. You can reach him at dmitriy.samovskiy@cohesiveft.com.

mardi 16 septembre 2008

Zicmama News

La phase de béta s'est terminée d'elle même fin aout par le remplissage des 2 premiers serveurs.
Merci à tout ceux qui sont inscrit pour leur participation au "Find the bug"!
Maintenant, avant de lancer le 3ème serveur (et les suivants), il est temps de retoucher le code de Zicmama pour que soient corrigés ses défauts de jeunesse...

Stay Tuned

lundi 30 juin 2008

Le dilemne du pirate (et comment le résoudre).

Les pirates sont innovants, ils mettent en évidence les problème du marché et montrent la voie à de nouveaux business models. Malgré tout, ils restent souvent taxés de voleurs.

Par Matt Mason.

Matt Mason, journaliste, est l’auteur du livre The Pirate’s Dilemma : How Youth Culture Is Reinventing Capitalism (Le dilemme du pirate : comment les jeunes réinventent le capitalisme), publié en 2008 chez Free Press.

Tout comme la lumière, qui existe tant sous forme d’ondes que de particules, rend perplexes les scientifiques, l’information semble nous rendre de plus en plus perplexes. L’information devient en même temps moins chère et plus coûteuse. Et il semblerait que nombre d’entre nous, et notamment ceux qui possèdent ou contrôlent une grande partie de l’information, ne comprennent plus comment l’observer ni l’utiliser.

Nous vivons dans un monde où une entreprise peut légalement breveter les cochons, ou tout autre entité vivante à l’exception de l’être humain, mais où copier sur disque dur un CD que vous avez acheté est considéré comme une violation des droits de quelqu’un d’autre. Un monde où un bon père de famille pourrait devoir plus de 12 millions de dollars d’amendes par jour s’il était attaqué à chaque fois qu’il contrevenait accidentellement à la loi sur les droits d’auteurs. Une société où il est normal que chacun de nous soit bombardé par 5000 messages publicitaires par jour, généralement sans permission, mais où créer une œuvre d’art et la montrer soi-même au public sans autorisation peut mener en prison. Ce texte ne traite pas seulement des avantages et des inconvénients du partage de fichiers, mais surtout d’une espèce entière qui perd son sens des réalités, qui n’arrive plus à comprendre le potentiel de l’une des ses plus précieuses (et pourtant l’une des plus abondantes) ressources.

Nous sommes nombreux à nous demander si nos idées comptent comme de l’information ou comme une propriété. Quand nous avons une nouvelle idée, deux forces opposées sont à l’oeuvre. Nous pensons d’un côté à comment faire connaître cette idée, mais de l’autre nous nous demandons aussi comment en profiter. Nous voulons répandre nos idées comme des informations, mais aussi les capitaliser comme de la propriété intellectuelle. C’est ce problème de l’information que je nomme le dilemme du pirate.

La première chose à comprendre est que la décision de partager « notre » information ne « nous » revient pas toujours. Si une entreprise pharmaceutique décide de ne vendre ses médicaments contre la malaria et les anti-rétroviraux contre le Sida qu’à un prix trop élevé pour les citoyens d’un pays en développement, alors ce pays peut décider d’ignorer la protection des brevets et fabriquer ses propres copies pirates des médicaments afin de sauver des vies. Si une industrie dépendant de l’information physique, de la distribution limitée et de la rareté artificielle décide d’ignorer des méthodes plus efficaces de distribuer sa propriété, alors les pirates se faufileront dans la brèche et mettront en évidence le fait qu’il existe de meilleures manières de faire les choses.

Certains des plus grands innovateurs américains ont d’abord été considérés comme des pirates. Quand Thomas Edison a inventé le phonographe, les musiciens l’ont taxé de pirate tentant de voler leur travail et de saccager l’industrie des concerts. Puis fut instauré ce que nous appelons aujourd’hui l’industrie du disque : un système permettant de payer des royalties aux musiciens. Par la suite, Edison inventa le kinétographe et réclama des royalties à tous ceux utilisant sa technologie pour faire des films. Cela força un groupe de réalisateurs pirates, dont l’un se prénommait William, à quitter New-York pour ce qui était alors encore le Far West. Ils y prospérèrent sans payer de royalties jusqu’à l’expiration du brevet d’Edison. Aujourd’hui, ces pirates continuent d’opérer de là-bas, quoique légalement, dans la ville qu’ils ont fondé : Hollywood. Le nom de famille de William ? Fox.

Le piratage est à la pointe de l’innovation, une innovation qui passe par tous les moyens nécessaires. De grands oligopoles contrôlent la plupart de nos industries et de nos gouvernements. Six entreprises contrôlent la majeure partie de ce que nous voyons et entendons. Selon les chiffres de la Banque mondiale en 2007, environ deux tiers des 150 plus grandes économies ne sont pas des nations, mais des multinationales. Nous savons tous que le système ne fonctionne pas vraiment comme prévu, mais nous continuons de penser que ce système inefficace représente « le libre échange ». Les pirates détruisent les systèmes inefficaces. Ils suppriment l’ordre et créent un chaos à court-terme. Mais le résultat à long terme du piratage à grande échelle est souvent un meilleur système, une façon plus efficace de faire les choses. Les pirates ont utilisé le chaos pour créer une grande partie des ordres établis aujourd’hui, et maintenant que ces industries deviennent à leur tour inefficaces avec les nouvelles technologies, le chaos apparaît de nouveau.

Pour une grande partie d’entre nous, du PDG à l’artiste inconnu, dans la santé et l’éducation comme dans les loisirs, se pose le problème de voir sa propriété intellectuelle partagée par d’autres sans permission. Cela implique un changement d’attitude : parfois, le piratage n’est pas le problème, mais la solution. En fait, le piratage est un signal pour le marché, un avertissement précoce, qui reste trop souvent ignoré par les industries existantes. Que nous soyons des pirates ou des professionnels, nous nous faisons concurrence dans le même domaine.

Quand les pirates pénètrent sur notre marché, nous avons deux choix : nous pouvons porter plainte contre eux ou espérer qu’ils partiront d’eux-mêmes. Parfois, c’est la meilleure chose à faire. Mais que faire dans le cas où ces pirates créent d’une certaine manière une valeur ajoutée pour notre société ? Si ces pirates font réellement quelque chose d’utile, les gens vont les soutenir et le bras armé de la loi ne fera plus effet. Qu’importe le nombre de personnes attaquées en justice, les pirates continueront de revenir et de se multiplier. Et il faut voir la vérité en face : si les procès deviennent un élément essentiel de votre business model, alors vous n’avez plus de business model. A moins d’être un avocat.

Car dans ces cas-là, les pirates ne font que souligner une meilleure façon pour nous de faire les choses. Ils trouvent les failles hors du marché et de meilleures manières pour que la société fonctionne. Dans ces situations, la seule façon de combattre le piratage est de légitimer et de légaliser de nouvelles innovations, afin de concurrencer les pirates sur le marché. Une fois le nouveau marché légitimé, de nouvelles opportunités se créent pour tout le monde. C’est de cette façon que la télévision par câble a débuté. C’est pour cette raison que de nombreux médicaments sont vendus à des prix suffisamment bas pour que les gens dans le Tiers-Monde puissent les acheter. Et c’est ainsi que de nombreuses autres nouvelles opportunités se créent aujourd’hui. Les pirates nous proposent un choix. Nous pouvons soit les combattre au tribunal, soit leur rendre coup pour coup sur le marché. Leur faire concurrence ou pas, telle est la question. Tel est le dilemme du pirate.

Texte publié à l’origine sur le site TorrentFreaks, en Creative Commons Attribution-Share Alike. Traduction Sébastien Delahaye pour Ecrans.fr
Source: http://www.pascalrobin.com/blog/index.php?2008/01/15/77-le-dilemne-du-pirate-et-comment-le-resoudre

lundi 23 juin 2008

Et si l'Electricité virait au Net

L'électricité qui alimente nos maisons provient souvent de la grosse centrale la plus proche...
Et si demain elle venait de chez mon voisin, mieux de chez moi!

Ca m'en a tout l'air possible quand on voit qu'une éolienne à venir promet de produire pour moins cher que l'EDF ricain.

Eolienne Skystream 3.7 Injection réseau
Eolienne AT623

On se prend à rêver de voir s'évanouir la facture EDF.
A la manière dont Internet fonctionne et l'information y circule, on
devrait se demander si notre réseau électrique ne serait pas mieux
décomposé en millions de sources de courant?
Le réseau deviendrait fiable car à sources d'énergie multiples...

Actuellement le problème c'est d'avoir le droit de se brancher au réseau national.
Actuellement, on a le choix entre:
- installer un pack de batteries et siroter son jus tout seul... Bcp de plomb ;(
- revendre son jus à EDF qui demande des installations à plusieurs milliers d'Euros: trop cher et compliqué!

L'alternative, trouver un moyen de connecter facilement ses sources d'énergies (éolien, solaire) à sa prise EDF pour laisser le courant fluctuer en fonction de la consommation de ses appareils. Plus ou moins assité par le réseau général, on consomme ou produit en fonction du vent et de ce qu'on fait.

On prône les problèmes techniques ou la dangerosité de l'aventure, mais raccorder une éolienne ou toute autre source de courant au réseau est possible!
Beaucoup essaye en inversant un onduleur d'ordinateur, en faisant marcher un moteur en générateur...
http://www.abcelectronique.com/forum/archive/index.php/t-5817.html
http://www.econologie.com/forums/faire-tourner-le-compteur-electrique-a-l-envers-par-1-eolien-vt1998.html
http://www.yourgreendream.com/index.php

En tout cas, je rêve qu'on arrive un jour à tous devenir participant au monde plutot que simples consommateurs!
A suivre...

lundi 2 juin 2008

Expérience sur les réseaux wifi mesh

Le principe du réseau maillé (mesh network) est que toute machine connecté à ce type de réseau peut être consommateur ou producteur de ressources. Comme ça on peut partager des fichiers, des connexions internet.

Quoi on peut mutualiser des connexions internet? Oui, le mesh publiera l'IP de tous les noeuds ayant un accès au net pour en faire bénéficier ceux qui n'en ont pas.
Et vive le partage entre voisins pour dépanner celui dont l'adsl ne marche plus, ou qui attend toujours son abonnement...



Pour procéder, nous allons utiliser une fonera avec sa fontenna (Magnifique petit routeur wifi bon marché mis au point par Fon). On va en remplacer le firmware pour y mettre un merveilleux OpenWRT Kamikaze!
Qui lui saura faire tourner OLSR, un protocole de gestion de réseaux mesh...
_______ ________ __
| |.-----.-----.-----.| | | |.----.| |_
| - || _ | -__| || | | || _|| _|
|_______|| __|_____|__|__||________||__| |____|
|__| W I R E L E S S F R E E D O M
KAMIKAZE (7.09) -----------------------------------


1) Débloquer la Fonera:

a- Downgrader le firmware
ATTENTION: Toute cette manipulation doit être faite avec la Fenora non connectée à Internet !

* Lorsque la Fonera est sous tension, appuyer pendant 30 secondes sur le bouton reset.
* Après les 30 secondes mettre la Fonera hors-tension (tout en gardant le bouton enfoncé).
* Ensuite remettre la Fonera sous-tension et ne lacher le bouton reset que lorsque les lumière 'Internet' et/ou 'WLAN' commencent à s'allumer.


Après cela normalement, le firmware doit être dans les 0.7.1 rA (ou A est compris entre 1 et 5. Généralement il descend jusqu'à la révision 2).

b- Utiliser l'exploit de Kolofonium
source: http://stefans.datenbruch.de/lafonera/#kolofonium

Démarrer la fontera sans la raccorder à internet. Se connecter en wifi à "MyPlace" (la clef est notée sous le boitier). Puis, changer les paramètres comme indiqué:

Dans l'interface de gestion de la Fonera (interface Web) passer en ip statique (Advanced -> Network settings) et changer :

* l'addresse ip et la passerelle de tel sorte que la Fenora puisse avoir accès à Internet [192.168.202.100 / 255.255.255.0 | 192.168.202.1]
* le serveur DNS à 88.198.165.155 (serveur mis en place par Kolofonium: un faux serveur DNS qui reconfigure le Fonera et lance dropbear au lancement de Chilispot)
* Valider et faire un hard-reboot de la Fenora (mise hors-tension puis mise sous-tension) en la branchant à votre réseau.


Lorsque la Fenora a redémarré il est possible de se connecter en SSH (via la liaison WIFI, donc attaché au SSID MyPlace avec le numéro de série comme Clé) sur l'adresse 192.168.202.100 (login: root, pw: admin)

fred@kirikou:~$ ssh root@192.168.202.100
BusyBox v1.1.3 (2006.09.11-19:54+0000) Built-in shell (ash)
Enter 'help' for a list of built-in commands.
Fonera Firmware (Version 0.7.0 rev 4) -------------
* Based on OpenWrt - http://openwrt.org
* Powered by FON - http://www.fon.com
---------------------------------------------------
root@OpenWrt:~# echo "alias ll='ls -al'" >> /etc/profile
root@OpenWrt:~# mv /etc/init.d/dropbear /etc/init.d/S51dropbear


Ensuite ajouter à /etc/firewall.user
iptables -t nat -A prerouting_rule -i $WAN -p tcp --dport 22 -j ACCEPT
iptables -A input_rule -i $WAN -p tcp --dport 22 -j ACCEPT
iptables -t nat -A prerouting_rule -i $LAN -p tcp --dport 22 -j ACCEPT
iptables -A input_rule -i $LAN -p tcp --dport 22 -j ACCEPT

Et voila! On va pouvoir jouer avec...
SSH est ouvert!

Mais Redboot (http://wiki.openwrt.org/OpenWrtDocs/Hardware/Fon/Fonera) ne l'est pas forcément également et nous allons rentrer par là...

Lancer un dmesg et repérer la ligne "RedBoot config":
<5>Creating 6 MTD partitions on "spiflash":
<5>0x00000000-0x00030000 : "RedBoot"
<5>0x00030000-0x00720000 : "rootfs"
<5>0x00730000-0x007e0000 : "vmlinux.bin.l7"
<5>0x007e0000-0x007ef000 : "FIS directory"
<5>0x007ef000-0x007f0000 : "RedBoot config"
<5>0x007f0000-0x00800000 : "board_config"


En comptant de 0, noter son numéro (ici 4),
puis faites en adaptant:
root@OpenWrt:/# cat /dev/mtd/4ro > /tmp/redboot_config
root@OpenWrt:/# strings /tmp/redboot_config
root@OpenWrt:/# cd /tmp
root@OpenWrt:/# wget http://ipkg.k1k2.de/hack/openwrt-ar531x-2.4-vmlinux-CAMICIA.lzma
root@OpenWrt:/# mtd -e vmlinux.bin.l7 write openwrt-ar531x-2.4-vmlinux-CAMICIA.lzma vmlinux.bin.l7
root@OpenWrt:/# reboot
root@OpenWrt:/# cd /tmp
root@OpenWrt:/# wget http://ipkg.k1k2.de/hack/out.hex
root@OpenWrt:/# mtd -e "RedBoot config" write out.hex "RedBoot config"
root@OpenWrt:/# reboot


Enfin redboot devrait être joignable par le port 9000 au démarrage...

2) Installer OpenWRT:

Eteindre la Fonera. La rebrancher sur son ordinateur
Télécharger http://download.berlin.freifunk.net/fonera/ap51-flash-1.0-42 (Parcourir le site pour une version (windows))
Télécharger la dernière version d'openwrt pour cette plateforme:
http://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/openwrt-atheros-2.6-root.squashfs
http://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/openwrt-atheros-2.6-vmlinux.lzma

Ensuite lancer
$ chmod 755 ap51-flash-1.0-42
$ sudo ./ap51-flash-1.0-42 eth0 ./openwrt-atheros-2.6-root.squashfs ./openwrt-atheros-2.6-vmlinux.lzma

Terminé!!! Voila OpenWRT Kamikaze 7.09 installé sur la Fonera ;)
Son adresse IP sera par défault 192.168.1.1

3) Configurer le noeud (ex: ETOILE3)

a- Changer le mot de passe:

root@OpenWrt:/# telnet 192.168.1.1
root@OpenWrt:/# passwd


b- Changer le hostname:


root@OpenWrt:/# uci show system
root@OpenWrt:/# uci set system.cfg1.hostname=ETOILE3
root@OpenWrt:/# uci commit


c- Modifier network et wireless config:

root@OpenWrt:/# vi /etc/config/network
# Copyright (C) 2006 OpenWrt.org

config interface loopback
option ifname lo
option proto static
option ipaddr 127.0.0.1
option netmask 255.0.0.0

config interface lan
option ifname eth0
option proto dhcp
option ipaddr 192.168.203.1
option netmask 255.255.255.0
option gateway 192.168.10.254

config interface wlan0
option ifname ath0
option proto static
option ipaddr 192.168.103.1
option netmask 255.255.255.0

config interface wlan1
option ifname ath1
option proto static
option ipaddr 10.97.2.3
option netmask 255.255.255.0

root@ETOILE3:~# vi /etc/config/wireless
config wifi-device wifi0
option type atheros
option channel 11
option diversity 0
option txantenna 1
option rxantenna 1
option agmode 11bg
option mode '11bg'
option disabled '0'

config wifi-iface
option device wifi0
option network wlan0
option mode ap
option ssid ETOILE3
option encryption 'psk'
option wpa_crypto 'tkip'
option password 'xxxxxxxxxx'
option hidden '0'
option isolate '0'
option txpower '18'
option bgscan '0'
option wds '0'
option key 'xxxxxxxxxx'

config wifi-iface
option device wifi0
option network wlan1
option mode adhoc
option ssid olsr.zicmama.com
option hidden '1'
option encryption none
option bssid ca:fe:ca:fe:ca:fe
option isolate '0'
option bgscan '0'
option wds '0'

d- Ajouter les packages olsr et x-wrt, les configurer:

echo "src X-Wrt http://downloads.x-wrt.org/xwrt/kamikaze/7.09/atheros-2.6/packages" >> /etc/ipkg.conf
ipkg update
ipkg install olsrd olsrd-mod-bmf olsrd-mod-dot-draw olsrd-mod-dyn-gw olsrd-mod-httpinfo olsrd-mod-nameservice webif
hostapd-mini
# autostart olsrd
ln -s /etc/init.d/olsrd /etc/rc.d/S70olsrd

root@ETOILE2:~# vi /etc/firewall.user
#!/bin/sh

# Copyright (C) 2006 OpenWrt.org

iptables -F input_rule
iptables -F output_rule
iptables -F forwarding_rule
iptables -t nat -F prerouting_rule
iptables -t nat -F postrouting_rule

# The following chains are for traffic directed at the IP of the
# WAN interface

iptables -F input_wan
iptables -F forwarding_wan
iptables -t nat -F prerouting_wan

# Does anyone have a command to get the name of the WIFI interface on Kamikaze so
# that it doesn't have to be hard-coded here? This is a bit sloppy it seems.
WIFI=ath1

## -- This allows port 22 to be answered by (dropbear on) the router
iptables -A input_wan -p tcp --dport 22 -j ACCEPT

# Allow connections to olsr info port.
iptables -A input_wan -p tcp --dport 1979 -j ACCEPT

# OLSR needs port 698 to transmit state messages.
iptables -A input_rule -p udp --dport 698 -j ACCEPT

###################################################################
### START Rules that allow forwarding from one network to another.
### Rules based on openwrt wiki page:
### http://wiki.openwrt.org/OlsrMeshHowto
###################################################################
# Debugging... do we have WIFI, LAN and WAN appropriately defined?
# These values are passed to us from /etc/init.d/firewall, which
# calls this script.
WAN=ath0
echo WIFI == $WIFI
echo LAN == $LAN
echo WAN == $WAN

iptables -A forwarding_rule -i $WAN -o $WIFI -j ACCEPT
iptables -A forwarding_rule -i $WIFI -o $WAN -j ACCEPT

# For forwarding LAN & WIFI in nodes
iptables -A forwarding_rule -i $LAN -o $WIFI -j ACCEPT

# For WIFI clients to connect to nodes.
iptables -A forwarding_rule -i $WIFI -o $WIFI -j ACCEPT

# For connecting a wired lan client of node 1 to wired lan client of node 2
iptables -A forwarding_rule -i $LAN -o $LAN -j ACCEPT

# WIFI needs to go to LAN ports, too!
iptables -A forwarding_rule -i $WIFI -o $LAN -j ACCEPT

# Masquerade all traffic to olsr net
iptables -t nat -A POSTROUTING -o $WIFI -j MASQUERADE
iptables -t nat -A POSTROUTING -o $LAN -j MASQUERADE

root@ETOILE2:~# vi /etc/dnsmasq.conf
AJouter:
dhcp-option=6,192.168.102.1
Et ajuster les DNS dans resolv.conf

root@ETOILE2:~# vi /etc/olsrd.conf
DebugLevel 0
IpVersion 4
AllowNoInt yes
Pollrate 0.1
TcRedundancy 2
MprCoverage 7
LinkQualityFishEye 1
LinkQualityWinSize 100
LinkQualityDijkstraLimit 0 6.0
LinkQualityLevel 2
UseHysteresis no

Hna4
{
192.168.103.0 255.255.255.0
192.168.203.0 255.255.255.0
}

Interface "ath1"
{
HelloInterval 4.0
HelloValidityTime 72.0
TcInterval 3.0
TcValidityTime 216.0
MidInterval 12.0
MidValidityTime 216.0
HnaInterval 12.0
HnaValidityTime 72.0
}

LoadPlugin "olsrd_httpinfo.so.0.1"
{
PlParam "port" "8080"
PlParam "Net" "192.168.0.0 255.255.0.0"
PlParam "Net" "10.97.2.0 255.255.255.0"
}

LoadPlugin "olsrd_dyn_gw.so.0.4"
{
PlParam "Interval" "40"
PlParam "Ping" "193.43.210.154"
}

LoadPlugin "olsrd_nameservice.so.0.3"
{
PlParam "name" "etoile3"
PlParam "suffix" ".lan"
PlParam "hosts-file" "/etc/hosts"
}

Une fois ces fichiers à jour rebooter. Si un boitier ayant reçu la même configuration est proche, il fera parti du même groupe WIFI mesh

Se le noeud est instable (ce arrive à cause de la gestion wifi simultanée du mesh et de l'AP)
Ajouter un reboot régulier à /etc/init.d/custom-user-startup

# reboot every 2 hours
(sleep 7200; reboot)&


Références:
http://www.e-bulles.be/bubble/Kamikaze
http://wiki.openwrt.org/OlsrMeshHowto
http://wiki.x-wrt.org/index.php/Kamikaze_Installation
http://www.toulouse-sans-fil.net/wiki/Kamikaze

http://www.fon.com/fr/

mercredi 21 mai 2008

Lettre d'une prof en colère

Je suis un professeur d'histoire-géographie de 30 ans, enseignant dans un lycée d'Indre-et-Loire, non syndiqué et qui a fait grève pour la première fois de sa carrière cette année. Nous ne travaillons - comme vous le savez si bien maintenant chers lecteurs - « que » 18 heures par semaine devant les élèves, et ce, depuis 1950. Or ce temps fut conçu en prévoyant qu'un enseignant travaille 1,5 heure chez lui pour une heure devant les élèves afin de préparer ses cours, évaluer les élèves et actualiser ses connaissances dans sa discipline.
Cela fait 18 fois 2,5 soit 45 heures hebdomadaires. Je suppose, qu'intérieurement, vous vous dites:
« vous avez les vacances pour compenser ».
Ces chères vacances qui font de nous des privilégiés ! Certes, il est vrai que nous avons 10 jours en février, 10 jours en avril, 10 jours à Noël, 5 jours aux vacances de la Toussaint (en réalité 8 jours mais nous travaillons 3 jours de plus en juillet pour compenser), cela fait 35 jours de congés payés. Aujourd'hui avec les 4 semaines de congés payés et les RTT, beaucoup de salariés ont autant de congés si ce n'est plus ! Or, nous, enseignants, pendant ces 35 jours de congés payés, souvent, nous corrigeons nos copies ou préparons nos cours. Vous répondrez: « oui mais vous avez 2 mois en été ».
Ces fameux deux mois d'été, il faut le savoir, ne nous sont pas payés : notre grille de salaire fut fixée en 1850 au même niveau que les autres cadres de la fonction publique recrutés avec un concours au niveau BAC+3, mais à cette grille, il nous a été retiré 2 mois de salaire, puis le résultat fut divisé par 12 (afin de recevoir un salaire chaque mois).
Pensiez-vous vraiment que l'on nous payait à rien faire durant deux mois ?
Non ! En résumé nous travaillons 45 heures par semaine, payés environ 1660 euros par mois, avec 35 jours de congés payés. Les événements de ces derniers jours, voire de ces derniers mois m'ulcèrent. Certains politiques détournent le débat sur le service minimum à l'école, pour s'attirer la sympathie des parents d'élèves qui, eux, travaillent toute la journée.
Pensez-vous vraiment, chers lecteurs, que le service minimum soit au centre de nos revendications ? Bien sûr que non ! Le seul aléa, c'est que nos «vraies » revendications sont tues, étouffées avant qu'elles ne vous parviennent. D'où cette lettre, qui, je l'espère, arrivera jusqu'à tous les parents d'élèves.

52 heures par semaine et classes de 40 élèves
Premièrement, notre principale revendication c'est la lutte contre la suppression des postes, certes, la « quantité ne fait pas la qualité », mais dans mon établissement, nous avons perdu 2 postes de professeur d'histoire-géographie en 2 ans, alors que la perte d'effectifs ne s'élève qu'à 40 élèves. Pourquoi ces suppressions de postes générales à tous les
disciplines et à tous les établissements ? Il s'agit de répartir les heures entre les professeurs restants afin qu'ils fassent 21 heures ou 22 heures de présence devant les élèves, soit plus de 52 heures de travail hebdomadaire !
Qui pourrait tolérer cela ?
Une autre solution serait d'augmenter les effectifs de chaque classe, les classes à 40 élèves deviendront monnaie courante. J'ai donc une proposition à faire à tous les enseignants qui liront ce courrier. Etant donné que nous ne sommes pas rémunérés pour les mois de juillet et août, ne faisons rien, pas de préparation de cours ni de renouvellement de nos connaissances durant l'été. Ensuite, pendant nos « petites vacances » qui sont nos congés payés communs à tous les salariés, reposons-nous: pas de copies ni de cours à préparer. Et surtout, à partir du mois de septembre, travaillons réellement 35 heures par semaines.
Personnellement, je suis prête à fournir au ministre de l'éducation mon emploi du temps semaine par semaine indiquant mes 35 heures de travail réalisées, préparation des cours et corrections de copies inclus. Mais je tiens à vous prévenir que si les enseignants travaillaient réellement « que » 35 heures par semaine, les cours ne seraient pas toujours prêts à temps, les copies seraient rendues très longtemps après les devoirs (un paquet de lycée c'est 4 heures de correction, actuellement je corrige 20 h toutes les 2 à 3 semaines), les brevets blancs et bacs blancs seraient moins nombreux, etc.

Vers le système anglo-saxon
Vous allez répondre que l'on contribuera dès lors à détériorer notre système éducatif déjà si mal en point ! Notre système n'est pas si mal en point que l'on veut vous faire croire. Les professeurs de vos enfants sont parmi les mieux formés du monde, les concours du CAPES et de l'agrégation sont parmi les plus difficiles à réussir. Mais le ministre de l'éducation veut remplacer ces professeurs compétents qu'il faut rémunérer à leur juste valeur (minimum BAC + 3) par des intérimaires, des vacataires sans diplômes et moins bien payés. Il veut copier le système anglo-saxon, où un professeur enseigne plusieurs disciplines avec pour seules compétences son niveau BAC !

Après tout, à quoi cela sert-il qu'un prof de langue étudie 3 à 4 ans à l'université une langue étrangère, se rende dans ce pays pour se familiariser avec le mode de vie et dispense ensuite son savoir aux élèves alors qu'en Angleterre avoir appris l'espagnol au lycée suffit à avoir les compétences pour l'enseigner. On vous parle sans cesse « d'échec scolaire »,
mais ce « pseudo échec scolaire » n'est pas le fait des enseignants, au contraire ces derniers limitent « la casse ». Je m'explique: le gouvernement souhaite absolument que 80% d'une classe d'âge obtiennent le BAC. Tans pis si un élève de 3ème rêve d'être plombier. Les recommandations données et « imposées » aux professeurs principaux de 3ème sont claires, il faut faire passer en 2nde générale et technologique. Les places en BEP ou CAP sont d'ailleurs peu nombreuses et seuls les meilleurs élèves sont acceptés. Les autres vont en 2nde, quitte à échouer après. Les enseignants rencontrent les parents, expliquent les différentes voies empruntables par les élèves qui ne souhaitent pas aller au lycée, mais le discours est tellement bien formaté et martelé que chacun imagine la voie professionnelle comme un échec.
D'autre part, les établissements ont des « quotas » de redoublants à ne pas dépasser. Tans pis si un élève aurait pu consolider des acquis fragiles en redoublant (car redoubler c'est une 2nde chance, ce n'est pas une sanction).

« Nous passons pour des bouffons »
A cela s'ajoute le manque de sanction. Combien de parents n'ont-ils pas entendu leurs enfants raconter qu'ils n'ont pas pu avancer dans tel ou tel cours car certains élèves faisaient « le bordel » ? Or, un enseignant peut difficilement exclure un élève de cours sous peine d'être déconsidéré par sa hiérarchie, des exercices supplémentaires peuvent être donnés mais s'ils ne sont pas réalisés, que faire ? Coller ? Oui, c'est une solution mais dans de nombreux établissements il n'y a pas assez de personnels ou d'heures rémunérées pour surveiller les colles du mercredi.
Exclure ? Pourquoi pas ? Mais les chefs d'établissements y sont souvent réfractaires car l'exclusion définitive les met en situation d'échec vis-à-vis du rectorat. Nous faisons grève pour nous faire entendre mais nous apparaissons comme des « bouffons » dont on se joue. Nous ne bloquons aucune production, nous ne prenons pas de voyageurs en otage, nous ne bloquons pas les routes et, de ce fait, le gouvernement a raison de rigoler et d'attendre que l'on ait fini nos « petites manifs ». Maintenant il y a toujours la solution de « bloquer » la production, notre production étant pour nous l'éducation et le savoir. Rien n'est plus facile que de faire grève durant les épreuves du BAC et brevet, ou pire encore, travailler 35 heures par semaine, car à partir de ce moment il n'est pas dit que vos enfants aient acquis toutes les compétences nécessaires à la réussite de leurs examens, étant donner que pour faire que 35 h nous devront donner des QCM à la place des compositions, que nous ne pourrons plus préparer d'examens blancs, car trop longs à corriger. Si tel était le cas nous serions très loin d'atteindre 80 % de réussite au BAC ! Peut être que le gouvernement attend de constater qu'avec ses réformes imposées et contre-productives, la cuvée 2009 du BAC ne représentera que 50 % des candidats.
Chers lecteurs, j'espère que ce courrier vous permettra de vous forger votre propre opinion, tout en vous détachant du bourrage de crâne gouvernemental et médiatique qui ne tend qu'à masquer la réalité des problèmes et revendications. Rien ne vous empêche d'aller interroger directement les professeurs de vos enfants, ils sauront vous renseigner sur la réalité du système éducatif français. Je terminerai en précisant que jamais en classe nous ne critiquons tel ou tel corps de métier, alors je ne comprends pas pourquoi certains élèves arrivent en classe avec un discours méprisant envers les enseignants, discours véhiculé par les parents alors que ces derniers ne savent rien de la réalité de nos conditions de travail.

Elisabeth, Tours