À l’heure où les USA sont empêtrés dans une sombre histoire d’espionnage généralisé à grande échelle, il nous a paru intéressant de déterrer et traduire un article de Richard Stallman rédigé en 2001 juste après le 11 septembre.

Force est de reconnaître qu’une fois de plus il avait pressenti les conséquences néfastes que nous subissons aujourd’hui.

Des milliers de morts, des millions privés de libertés civiles ?

Thousands dead, millions deprived of civil liberties?

Richard Stallman - 2001 - Site personnel
(Traduction : Lamessen, Slystone, Sky, Amine Brikci-N, Asta)

Dans de nombreux cas, les dommages les plus sévères que cause une lésion nerveuse sont secondaires ; ils se produisent dans les heures qui suivent le traumatisme initial, car la réaction du corps à ces dommages tue davantage de cellules nerveuses. Les chercheurs commencent à découvrir des façons de prévenir ces lésions secondaires et réduire les dommages ultimes.

Si nous ne faisons pas attention, les attaques meurtrières sur New York et Washington vont conduire à des effets secondaires bien pire encore, si le congrès étasunien adopte des « mesures préventives » qui écartent la liberté que l’Amérique représente.

Je ne parle pas de fouilles dans les aéroports ici. Les fouilles de personnes ou de bagages, tant qu’ils ne cherchent pas autre chose que des armes et ne gardent pas de traces de ces fouilles, est juste un désagrément : elles ne mettent pas en danger vos libertés civiles. C’est la surveillance massive de tous les aspects de nos vies qui m’inquiète : de nos appels téléphoniques, nos courriels et nos déplacements physiques.

Ces mesures sont susceptibles d’être recommandées indépendamment du fait qu’elles seraient efficaces pour leur objectif déclaré. Un dirigeant d’une entreprise développant un logiciel de reconnaissance faciale est dit avoir annoncé à des journalistes que le déploiement massif de caméras embarquant un système de reconnaissance faciale aurait empêché les attaques. Le New York Times du 15 septembre cite un congressiste prônant cette « solution ». Étant donné que la reconnaissance humaine du visage effectuée par les agents d’accueil n’a pas permis de stopper les pirates, il n’y a pas de raison de penser que les caméras à reconnaissance faciale informatisée aurait été d’une quelconque aide. Mais cela n’arrête pas les agences qui ont toujours voulu mettre en place plus de surveillance de pousser ce plan aujourd’hui, ainsi que beaucoup d’autres plans similaires. Il faudra l’opposition du public pour les stopper.

Encore plus inquiétant, une proposition visant à exiger des portes dérobées gouvernementales dans les logiciels de chiffrement a déjà fait son apparition.

Pendant ce temps, le Congrès s’est empressé de voter une résolution donnant à Bush les pleins pouvoirs d’utilisation de la force militaire en représailles des attaques. Les représailles peuvent être justifiées, si les auteurs des attaques peuvent être identifiés et ciblés avec soin, mais le Congrès a le devoir d’examiner les mesures spécifiques lorsqu’elles sont proposées. Donner carte blanche au président dans un moment de colère est exactement l’erreur qui a conduit les États-Unis dans la guerre du Vietnam.

S’il vous plait, laissez vos représentants élus et votre président non élu savoir que vous ne voulez pas que vos libertés civiles deviennent les prochaines victimes du terrorisme. N’attendez pas, Les lois sont déjà en cours d’écriture.

Crédit photo : Sigg3net (Creative Commons By)

Original post of Framablog.Votez pour ce billet sur Planet Libre.

Vous n'avez sûrement pas pu y échapper, le gouvernement des USA et la NSA ont affirmé espionner les communications électroniques sur leur territoire. Cela inclut Gmail, Facebook, Skype, etc... et donc aussi les communications des étrangers qui utilisent ces services.

On pourrait penser que les personnes qui s'auto-hébergent sont à l'abri mais de fait il suffit qu'il seul des correspondants d'une communication utilise un service aux USA et c'est l'ensemble de la communication qui peut être espionnée. Malheureusement, bon nombre de mes contacts ont une adresse mail @gmail.com ou @hotmail.com :-/ Autant dire que lorsque l'on leur envoie un mail, le fait d'être auto-hébergé ne change rien.

Se prémunir de cet espionnage requiert donc une solution plus globale. Une sécurisation de bout en bout où les intermédiaires de communication n'aient pas connaissance du contenu et où le déchiffrement du message se fait par un logiciel libre sur une plateforme en laquelle l'utilisateur a confiance (êtes vous sûr qu'il n'y a pas de backdoor dans votre OS de smartphone?)

Si les gens qui utilisent Gmail & consort aujourd'hui ne sont pas auto-hébergés, je ne pense pas qu'ils vont le devenir par miracle. Ces gros services apportent beaucoup de facilité (stockage en ligne gratuit, accès depuis n'importe quel terminal sans configuration, aucune maintenance) que l'auto-hébergement d'aujourd'hui peine à concurrencer.

Des initiatives comment BitMessage ou Retroshare émergent mais le futur est encore à créer.

Original post of Tuxicoman.Votez pour ce billet sur Planet Libre.

J’ai présenté une conférence la semaine dernière, dimanche 2 juin, à la Ubuntu Party de Paris, autour du réseau social décentralisé Movim qui se base sur XMPP. L’ambiance était fun, même si l’évènement était un peu plus modeste que d’habitude, ça n’empêche pas de faire de bonnes rencontres.

Je vous conseille de regarder la vidéo avec les slides à côté, ils sont juste en dessous.

• Télécharger la vidéo en webm
• Télécharger la vidéo en ogv
• Télécharger la vidéo en mp4
• Télécharger la présentation en odp
• Télécharger la présentation en pdf

Il se trouve qu’on a aussi été invité au PSES2013 (Pas Sage en Seine 2013, à Paris) et que je me retrouve donc présenter Movim à nouveau dans deux semaines.

Vous pourrez me rencontrer samedi 22 juin de 18h30 à 19h30 (plus d’info).

Original post of Influence PC.Votez pour ce billet sur Planet Libre.

Vous avez acquis un petit serveur sur online.net, une Dedibox SC. Vous souhaitez optimiser votre service mySQL.

Le problème est que vous ne savez pas par où commencer. Cet article est à votre disposition pour vous aider dans cette tâche complexe d’optimisation de votre serveur de base de données mySQL.

Une optimisation personnelle de la configuration mySQL avec 2 Go de RAM donne :

[client]
port		= 3306
socket		= /var/run/mysqld/mysqld.sock

[mysqld_safe]
socket		= /var/run/mysqld/mysqld.sock
nice		= 0

[mysqld]

## PARAMETRES GENERAUX :
user                   = mysql
pid-file	       = /var/run/mysqld/mysqld.pid
socket		       = /var/run/mysqld/mysqld.sock
port	    	       = 3306
basedir		       = /usr

## PARAMETRES du moteur innodb :
innodb_flush_method            = O_DIRECT
innodb_log_files_in_group      = 2
###VOIR PLUS BAS COMMENT CALCULER: innodb_log_file_size           = 0
innodb_flush_log_at_trx_commit = 2
innodb_file_per_table          = 1
innodb_buffer_pool_size        = 624M

## PARAMETRES du moteur myISAM :
key_buffer_size                = 4M
myisam_recover                 = FORCE,BACKUP

## PARAMETRES de connexions :
max_allowed_packet     = 16M
max_connect_errors     = 9999999
skip_name_resolve
skip-external-locking

# PARAMETRES de stockage :
datadir                = /var/lib/mysql/
tmpdir		       = /tmp
lc-messages-dir	       = /usr/share/mysql

## PARAMETRES de caches et de limites :
tmp_table_size                 = 64M
max_heap_table_size            = 64M
query_cache_type               = 1
query_cache_size               = 64M
query_cache_limit              = 8M
#max_connections                = 1500
max_connections                = 60
thread_cache_size              = 20
open_files_limit               = 65535
table_definition_cache         = 1024
table_open_cache               = 1024

## PARAMETRES de log :
log_bin                = /var/log/mysql/mysql-bin.log
expire_logs_days       = 14
sync_binlog            = 1

## PARAMETRES des logs d'erreurs :
slow_query_log                 = 1
log_queries_not_using_indexes  = 1
long_query_time                = 10
log_error                      = /var/lib/mysql/mysql-error.log
slow_query_log_file            = /var/lib/mysql/mysql-slow.log

[mysqldump]
quick
quote-names
#max_allowed_packet	= 16M
max_allowed_packet	= 16M

[mysql]

[isamchk]
key_buffer_size         = 32M

!includedir /etc/mysql/conf.d/

Ce fichier de configuration ne vous conviendra certainement pas. Il ne s’agit que de valeurs pour mon cas personnel. Cependant, vous pourrez comparer avec vos propres paramètres.

Comment calculer key_buffer ?

Les deux variables les plus importantes au moment du réglage d’un serveur MySQL sont key_buffer et table_cache. Vous devriez vous assurer que celles-ci sont sont bien paramétrées avant de modifier les autres variables. Nous allons voir comment régler de manière optimale la variable key_buffer.

Après une période de trafic sur votre serveur MySQL, loguez-vous en root sur le serveur mysql :
mysql -uroot -pyourpasswordrootmysql
effectuez un :
show status like 'key%' ;

Vous obtenez la réponse du système :
:+--------------------+-----------+
| Variable_name | Value |
+--------------------+-----------+
| Key_blocks_used | 311642 |
| Key_read_requests | 147513163 |
| Key_reads | 470581 |
| Key_write_requests | 4122525 |
| Key_writes | 716390 |
+--------------------+-----------+
5 rows in set (0.00 sec)

Divisez la valeur Key_reads par Key_read_request soit ici dans l’exemple :
470581 / 147513163 = 0,003190095

si le résultat est supérieur à 0,01 augmenter la valeur de key_buffer dans le fichier de configuration MySQL se situant à /etc/mysql/my.cnf

Si votre tableau n’est pas encore rempli par manque de trafic, optez pour une première fois une valeur de key_buffer comprise entre 25% et 30% de la taille de mémoire physique du serveur.

Comment calculer le innodb_log_file_size ?

Loguez-vous en root sur le serveur mysql :
mysql -uroot -pyourpasswordrootmysql

Lorsque votre serveur mySQL tourne depuis plus de 48 heures, connectez-vous en console à votre serveur mySQL. Puis executez la commande suivante lorsque celui-ci est en pleine charge :

pager grep sequence

ensuite saisissez :
mysql> show engine innodb status\\G select sleep(60); show engine innodb status\\G

Remarquez le numéro de séquence du journal. C’est le nombre total d’octets écrits dans le journal des transactions.

Effectuez avec une calculatrice le calcul suivant :
(SecondNombre – PremierNombre) / 1024 / 1024
Vous obtiendrez par exemple 1.25434 Mo de données écrites par minute.
Soit en 1 heure d’utilisation : 1.25434×60=75 Mo de données.
Il y a 2 fichiers journaux, ce qui donne 75/2=37 Mo soit arrondi à une puissance de 2 : 32 Mo
La valeur de votre innodb_log_file_size sera donc de 32M.

En ce qui concerne les logs concernant les requêtes longues de plus de 10 secondes, on les désactive sur la production, et on les active sur la machine de développement :


### En production mis à 0
###slow_query_log = 0
###log_queries_not_using_indexes = 0
slow_query_log = 1
log_queries_not_using_indexes = 1
long_query_time = 10
slow_query_log_file = /var/lib/mysql/mysql-slow.log


Comment calculer le query_cache_size ?

Après une période de trafic sur votre serveur MySQL, loguez-vous en root sur le serveur mysql :
mysql -uroot -pyourpasswordrootmysql
effectuez un :
show status like 'qc%'; ;

Vous obtenez la réponse du système :
:+-------------------------+---------+
| Variable_name | Value |
+-------------------------+---------+
| Qcache_free_blocks | 594 |
| Qcache_free_memory | 1807168 |
| Qcache_hits | 56029 |
| Qcache_inserts | 12429 |
| Qcache_lowmem_prunes | 6527 |
| Qcache_not_cached | 6513 |
| Qcache_queries_in_cache | 1027 |
| Qcache_total_blocks | 3271 |
+-------------------------+---------+

Qcache_free_memory : La mémoire libre pour de nouvelles requêtes.
Qcache_hits : Le nombre de requêtes qui ont été mise en cache. Plus ce nombre est élevé, mieux c’est.
Qcache_inserts : Combien de requêtes mis en cache depuis le dernier redémarrage de mysql.
Qcache_lowmem_prunes : Nombre de requêtes retirées du cache par manque de place afin d’en insérer de nouvelle. Si cette valeur augmente rapidement (idéalement doit être à zéro), augmentez la valeur de query_cache_size.

Tester les paramétrages

Pour tester les paramétrages de mySQL, vous pouvez utiliser le script shell de Matthew Montgomery.
Téléchargement : tuning-primer.sh

Conclusion

En espérant que cet article vous donne les éléments pour commencer vos optimisations mySQL sur votre Dedibox SC. Vous devrez passer du temps sur la documentation de mySQL server en fonction des optimisations souhaitées.

http://dev.mysql.com/doc/refman/5.0/fr/mysql-optimization.html

Je vous invite également à consulter le blog d’Olivier DASINI. Vous y trouverez quelques précieux conseils d’un administrateur de base de données.

Original post of bazzanella.Votez pour ce billet sur Planet Libre.

Lors de l’Ubuntu Party des 1 & 2 Juin j’ai proposé une « définition d’une monnaire libre ». La vidéo sera peut-être disponible plus tard, mais en attendant, j’ai souhaité résumer cette présentation à partir des graphiques que j’ai utilisés, dans la vidéo suivante :

La présentation LibreOffice est disponible dans cette archive libre :

Enfin pour finir un lien magnet vers le torrent du fichier vidéo source.

Original post of Stéphane Laborde.Votez pour ce billet sur Planet Libre.