Commentaires (3)

Par matts, 12 janvier 2010 12 h 40 min

Les options qui vont bien pour synchroniser d’ext3 vers vfat :

rsync --modify-window=1 -rtv --delete /data/dir /mnt/

via: http://www.kylev.com/2005/03/29/rsync-and-vfat/

Commentaires (1)

Par matts, 21 octobre 2009 18 h 02 min

As rsyncd, the rsync daemon, only supports encryption for authentication, and not for the file-transfer itself, it might be a good idea to switch to rsync over ssh, especially when rsync-ing over the Internet.

But there’s a drawback : you cannot enable server-side logging directly from the server, as you would do with the rsyncd daemon.

Here’s a workaround for enabling server-side logging from the rsync client :

rsync -av --rsync-path="rsync --log-file=/tmp/rsync.log" -e ssh user@host:/remote_dir local_dir

Edit :
Turns out that there is a way to enable server-side logging from the server, even if it does not seem to be well-documented. You can create an rsyncd.conf file in the home directory of the user used for ssh. Here’s the one I use :

id file = /home/user/var/run/rsyncd.pid
log file = /home/user/log/rsync.log
lock file = /home/user/var/run/rsync.lock
uid             = user
gid             = user
use chroot      = no
max connections = 4
transfer logging = true
 
 
[export_name]
  comment = export_name
  path = /mnt/disk/dir
  read only = yes
  list = no
  hosts allow = ip_address

You can then rsync this way :

rsync -av -e ssh user@host::export_name .

Commentaires (0)

Par matts, 3 septembre 2009 15 h 32 min

Comment savoir à quelle branche distante correspond telle branche locale ?

git remote show origin

donnera :

Remote branch merged with 'git pull' while on branch branche_distante
    branche_locale

Commentaires (0)

Par matts, 27 août 2009 10 h 14 min

Problème : je souhaite mettre à jour mon répertoire git, tout en conservant les modifications locales que j’ai faites, mais sans commiter-pusher celles-ci.

Solution : utiliser git stash !

# On met dans le stash les modifications locales
git stash save un_nom_qui_va_bien
 
# On récupère les modifications distantes
git fetch
 
# On les applique
git rebase origin
 
 # On réapplique les modifications locales contenues dans le stash, mais au sommet des commits !
git stash apply un_nom_qui_va_bien

Commentaires (0)

Par matts, 27 avril 2009 20 h 56 min

Ça faisait un bout de temps que l’idée me trottait dans la tête : avoir deux réseaux Wifi distincts ; un « sécurisé », et un « moins sécurisé ». Ceci afin de protéger le réseau local.

L’idée est que les périphériques qui se connectent en WPA (bien) ont accès au réseau local et à Internet, alors que les périphériques qui se connectent en WEP (pas bien) n’ont accès qu’à Internet et pas au réseau local.

Et bien c’est possible avec DD-WRT. Cerise sur le gâteau, on peut même faire en sorte que les périphériques connectés en WEP ne se voient pas entre eux (AP Isolation).

Il y a beaucoup de tutorials sur le net ; voici le seul qui ait fonctionné pour moi :

http://www.pennock.nl/dd-wrt/Multiple_BSSIDs.html

Commentaires (1)

Par matts, 11 avril 2009 12 h 59 min

Sous ce titre un peu ronflant se cache une astuce qui a vraiment accéléré mon firefox 3 : l’optimisation des base sqlite qu’il utilise. Un petit

for f in ~/.mozilla/firefox/*/*.sqlite; do sqlite3 $f 'VACUUM;'; done

quand le navigateur n’est pas lancé, et la recherche d’url ou de mots-clés dans la barre d’adresse va bien plus vite.

Commentaires (0)

Par matts, 8 avril 2009 19 h 11 min

Je possède un routeur Netgear wgt624 depuis plusieurs années. Il a toujours bien fonctionné. Cependant, depuis quelque temps, il est devenu capricieux…

Une connexion wifi prolongée faisait planter le routeur, liaison ethernet comprise. Au début, ça n’arrivait que de temps en temps, et puis au fûr et à mesure, c’est devenu régulier, puis fréquent, puis insupportable.

Après avoir pesté contre Netgear parce qu’il s’agit d’un v2 et qu’il n’y a pas (et qu’il n’y aura vraisemblablement plus) de mises-à-jour du firmware…

Après avoir essayé 10 000 configurations différentes, à base de MTU et de Threshold…

Rien n’y a fait.

Jusqu’à ce que je teste, en désespoir de cause, un conseil lu au détour d’un forum…

Une fois le WGT624v2 posé à la verticle, dans son socle, et plus à l’horizontale, sur la table… Il ne bronche plus. Plus rien, plus une déconnexion, plus un plantage…

Une meilleure circulation de l’air, sans doute…

Mais alors, pourquoi est-ce venu au fur et à mesure ? Après plusieurs années d’utilisation ?

Edit 11 avril :
Bon, en fait, avec le Netgear en position verticale, ça plantait quand même de temps en temps… Du coup, j’ai recyclé un de mes vieux ventilateurs pour disque durs Akasa pour le refroidir… Mais ça plantait encore… Donc avant d’investir dans du water-cooling pour mon routeur, j’ai opté pour une solution pas satisfaisante pour l’esprit (et les perfs) mais qui a l’air de fonctionner : passer la bête en mode « b » seulement… =\

Edit 13 avril :
Après avoir regardé du côté des firmware alternatifs (sans grand succès), j’ai tenté un reset hard du routeur (restauration des paramètres d’usine), ce que je n’avais pas fait je crois lors de la dernière mise-à-jour du firmware, alors que c’est conseillé. Le routeur tourne depuis 24h en mode b et g sans broncher… Il semblerait que ça ait résolu le problème…

Commentaires (0)

Par matts, 30 mars 2009 17 h 27 min

Vi :

highlight accolade 	: %
recherche 		: /
recherche arrière	: ?
recherche suivant	: n 	(next)
recherche précédent	: N
recherche mot courant	: *
mot suivant		: w 	(word)
mot précédent		: b 	(back)
recharger le fichier    : :e %
ouvrir le fichier	: gf 	(go file)
changer le mot		: cw 	(change word)
changer tout le mot	: ciw 	(change inner word)
complétion		: Control-P
fenêtre suivante        : Control-w w
revenir à l'endroit précédent du curseur : Control-o (old place)
exécuter une commande sur tous les buffers : :bufdo(!) :macommande

Emacs :

début de ligne		: Control-A (Control-A, A quand on est dans un screen)
fin de ligne		: Control-E
couper jusqu'à la fin de la ligne : Control-K
mot suivant 		: Meta f 	(forward)
mot précédent 		: Meta b 	(backward)

Shell :

arguments de la dernière commande 	: !*
réexecuter la dernière commande		: !!

Commentaires (0)

Par matts, 26 mars 2009 13 h 54 min

Tiens, je ne savais pas qu’on pouvait récupérer le login d’un utilisateur authentifé en HTTP ; celui-ci est stocké dans la variable REMOTE_USER. Voila, voila.

Commentaires (0)

Par matts, 26 février 2009 19 h 30 min

Au départ, j’utilisais un client IRC graphique (konversation, pour ne pas le nommer)…

Le problème, c’est que lorsqu’on passe de l’ethernet au wifi, ou inversement, on se fait déconnecter, le serveur ne le remarque pas, on revient sous « pseudo1″ ou « pseudo_ » avant de timeouter sur son pseudo original. Bref, c’est nul.

Après, j’ai utilisé un client en console dans un screen en distant sur une machine toujours reliée au net. Super, plus de déconnexion, mais du coup, on perd les avantages des clients graphiques : plus de notifications sonores ou visuelles. On répond aux messages trois heures après. Bref, c’est nul.

Du coup, je me suis dit : il me faudrait un client IRC « client/serveur », comme pour Soulseek : museekd tourne sur le serveur, et on s’y connecte avec museeq comme interface graphique.

Et bien ça existe ! Ça s’appelle un bouncer IRC, je ne connaissais pas du tout, et c’est exactement ce que je voulais. On se connecte au bouncer qui tourne sur le serveur, qui est lui-même connecté au « vrai » serveur IRC. Du coup, on peut déconnecter son client graphique, quand on revient, le bouncer renvoie tout ce qu’on a manqué ! En plus, on peut utiliser le client graphique qu’on aime le plus…

J’utilise znc, disponible en paquet debian, mais il existe d’autres, comme sbnc, muh, ezbounce, psybnc…