mercredi 30 mars 2011

Equipements et services télécom : et si la compatibilité IPv6 était obligatoire ?

La raréfaction des adresses IPv4 se poursuit inexorablement : le 24 novembre la barre des 100 jours de stock encore disponible était franchie, et aujourd'hui, deux semaines plus tard, il ne reste qu'à peine plus de 100 millions d'adresses IPv4 attribuables, qui seront épuisées dans environ 83 jours, c'est à dire moins d'un trimestre :

On se rappelle que, lorsque l'État a décidé de basculer la télévision hertzienne de l'analogique au numérique, avec le déploiement de la TNT, il a mis en place des mesures contraignantes : les fournisseurs d'équipements, en l'occurrence les fabricants de télévision, ont eu l’obligation d’intégrer un tuner TNT à l’ensemble de leurs produits.

Ainsi, dans l’article 19 de la loi sur la « modernisation de la diffusion audiovisuelle et la télévision du futur », promulguée en mars 2007 et en vigueur un an plus tard, il était stipulé que « Dans un délai de douze mois à compter de la promulgation de la présente loi, les téléviseurs vendus aux consommateurs sur le territoire national intègrent un adaptateur permettant la réception des services de la télévision numérique terrestre ».

Evidemment, il existe aujourd'hui des solutions comme le NAT pour continuer à utiliser des adresses IPv4 en dépit de la pénurie qui arrive. Pour autant, certains se disent que l’on pourrait passer à la vitesse supérieure : ainsi pourrait-on envisager qu’une loi contraignante impose aux équipementiers télécom et aux fournisseurs de services IP de ne plus avoir le droit, passé une certaine date, de fournir des équipements qui ne seraient pas nativement compatibles avec IPv6

lire encore

mardi 29 mars 2011

Héberger vos applications dans le nuage Google "App Engine"

Getting Started: Java

This tutorial describes how to develop and deploy a simple Java project with Google App Engine. The example project, a guest book, demonstrates how to use the Java runtime environment, and how to use several App Engine services, including the datastore and Google Accounts.
This tutorial has the following sections:

lundi 28 mars 2011

Open Source Ecologie, numérique, paysans et culture libre

Open Source Ecologie, numérique, paysans et culture libre

L'open source ou le libre, pas seulement pour l'informatique!

mardi 22 mars 2011

Adding Multiple Databases to replication... This is How...

=============================
MASTER: add lines to my.cnf
=============================
binlog-do-db=database_name_1
binlog-do-db=database_name_2
binlog-do-db=database_name_3
=============================
MASTER: SQL SYNTAX
=============================
GRANT REPLICATION SLAVE ON *.* TO 'user'@'%' IDENTIFIED BY 'password';
FLUSH PRIVILEGES;
FLUSH TABLES WITH READ LOCK;
UNLOCK TABLES;
SHOW MASTER STATUS;
output> file | Position | Binlog_Do_DB
mysql-bin.000963 1570 database_name_1,database_name_2,database_name_3
=============================

lire l'article complet

Google Web Toolkit Overview - Google Web Toolkit - Google Code

Google Web Toolkit Overview - Google Web Toolkit - Google Code: "– Envoyé à l'aide de la barre d'outils Google"

lundi 21 mars 2011

Replication Mysql Master / Master

Dans cet article nous allons essayer de mettre en place une solution qui assure la redondance d'une base de donnéesMySQL et qui permet de partager la charge entre deux nœuds.
Pour assurer la redondance des données nous allons avoir recours à la réplication native de MySQL.
En ce qui concerne le partage de charge, nous allons utiliser MySQL Proxy bien qu'il soit encore à sa version 0.8 Alpha.

Redondance des données:

Dans cette section, nous allons configurer une réplication entre deux Maîtres MySQL, identifiés par DB-1 et DB-2, sachant que dans cette configuration, chaque Maitre sera en même temps l'esclave de l'autre.
Ce schéma est plus expressif:


Le grand avantage de cette architecture est d'avoir deux bases de données sur lesquelles on peut écrire en parallèle sans se soucier de la synchronisation, la réplication se charge de synchroniser vers DB-2 ce qu'on écrit sur DB-1, et vice versa.
C'est d'ailleurs pourquoi on va utiliser MySQL Proxy qui se placera comme partageur de charge entre ces deux bases de données.


lire l'article complet (clicker ici)

Replication Master/Slave temps réel MySQL


La réplication MySQL consiste à avoir en temps réel deux bases de données MySQL identiques afin de pouvoir basculer sur un deuxième serveur en cas de défaillance du premier.
La réplication MySQL est basée sur le fait que le serveur va garder la trace de toutes les évolutions de vos bases (modifications, effacements, etc.) dans un fichier de log binaire et les esclaves vont lire les requêtes du maître dans ce fichier de log, pour pouvoir exécuter les mêmes requêtes sur leurs copies. Il est très important de comprendre que le fichier de log binaire est simplement un enregistrement des modifications depuis un point fixe dans le temps (le moment où vous activez le log binaire). Tous les esclaves que vous activez auront besoin de la copie des données qui existaient au moment du démarrage du log. Si vous démarrez vos esclaves sur sans qu’ils ne disposent des données identiques à celles du maître au moment du démarrage du log binaire, votre réplication va échouer.

mercredi 16 mars 2011

Configuration relayhost use a Google Apps (gmail) smtp with postfix

All the commands are done under the root user (or you could use sudo)
as root apt-get install postfix libsasl2 ca-certificate libsasl2-modules
Configure Postfix
This tutorial will not outline how to configure your postfix server, but we’ll jump directly to the relayhost section.  You’ll want to add the following lines to your /etc/postfix/main.cf


relayhost = [smtp.gmail.com]:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_tls_CAfile = /etc/postfix/cacert.pem
smtp_use_tls = yes
The above lines are telling Postfix that you want to relay mail through gmail on a specific port, telling it to authenticate, and where to find the username and password.  The last three lines specify the authentication types supported, where the certificate authority file is and that it should use tls.At this point you can restart Postfix and it should work, however it will complain about not being able to authenticate the certificate.  To take care of this issue we’ll use the ca-certificate package we installed and tell it where it can validate the certificate.

Define Username and Password
Next we’ll need to populate the sasl_passwd file.  Create the file /etc/postfix/sasl_passwd with the following contents:

[smtp.gmail.com]:587 user.name@domainGoogleApps:password
This file should have restrictive permissions and then needs to be translated into a .db that Postfix will read.

sudo chmod 400 /etc/postfix/sasl_passwd
sudo postmap /etc/postfix/sasl_passwd
Then reload postfix (/etc/init.d/postfix reload) and you should be set.

Using & validating CA certificate
touch /etc/postfix/cacert.pem
cat /etc/ssl/certs/Thawte_Premium_Server_CA.pem >> /etc/postfix/cacert.pem
 
cat /etc/ssl/certs/Equifax_Secure_CA.pem >> /etc/postfix/cacert.pem 

samedi 12 mars 2011

Sell hosting plan and get at least 10% commisions

The Second Tier referral program is available to all resellers. You will receive a 10% commission of the web hosting plan's wholesale price every time a reseller referred by you makes a sale. There is no commission for sold domain names through the Second Tier referral program

learn more and start your own hosting business in 10 minutes  (click here)

vendredi 11 mars 2011

How To scp, ssh and rsync without prompting for password

Whenever you need to use rsync to copy files, it asks for passwords. Usually scp and rsync commands are used to transfer or backup files between known hosts or by the same user on both the hosts. It can get really annoying the password is asked every time , specially if we need to automate backup with some batch scripts.
Lets say you want to copy between two hosts host_src and host_dest. host_src is the host where you would run the scp, ssh or rsyn command, irrespective of the direction of the file copy!
  1. On host_src, run this command as the user that runs scp/ssh/rsync
    $ ssh-keygen -t rsa
    This will prompt for a passphrase. Just press the enter key. It'll then generate an identification (private key) and a public key. Do not ever share the private key with anyone! ssh-keygen shows where it saved the public key. This is by default ~/.ssh/id_rsa.pub:
    Your public key has been saved in /.ssh/id_rsa.pub
  1. Transfer the id_rsa.pub file to host_dest by either ftp, scp, rsync or any other method.
  1. On host_dest, login as the remote user which you plan to use when you run scp, ssh or rsync on host_src.
  2. Copy the contents of id_rsa.pub to ~/.ssh/authorized_keys
    $ cat id_rsa.pub >>~/.ssh/authorized_keys $ chmod 700 ~/.ssh/authorized_keys
    If this file does not exists, then the above command will create it. Make sure you remove permission for others to read this file. If its a public key, why prevent others from reading this file? Probably, the owner of the key has distributed it to a few trusted users and has not placed any additional security measures to check if its really a trusted user.
  1. Note that ssh by default does not allow root to log in. This has to be explicitly enabled on host_dest. This can be done by editing /etc/ssh/sshd_config and changing the option of PermitRootLogin from no to yes. Don't forget to restart sshd so that it reads the modified config file. Do this only if you want to use the root login.
Well, thats it. Now you can run scp, ssh and rsync on host_src connecting to host_dest and it won't prompt for the password. Note that this will still prompt for the password if you are running the commands on host_dest connecting to host_src. You can reverse the steps above (generate the public key on host_dest and copy it to host_src) and you have a two way setup ready!