PROJET AUTOBLOG


Geekfault

Site original : Geekfault

⇐ retour index

Mise à jour

Mise à jour de la base de données, veuillez patienter...

Devbox KVM+Libvirt perfect setup.

jeudi 24 mars 2011 à 18:55

Dans le cadre de mon boulot chez Euro-Web j’ai été amené à monter une plate forme un peu particulière pour mon client Zenexity. Leur principale activité est le développement d’applications web basées sur une technologie maison open source ( framework Play! ).

J’ai donc demandé l’autorisation de faire une documentation publique sur cette installation, car je la trouve intéressante, et je n’ai rien trouvé de similaire pour le moment sur la toile.

Le setup part d’un gros besoin en machines virtuelles :

Avertissement : Cet article a pour but de partager des connaissances avec un public avisé.

Préambule

Cahier des charges

Comme expliqué plus haut le système de VM est un système très utilisé chez mon client. J’avais dans le passé monté un serveur XEN pour eux, mais la flexibilité ne convenait plus, notamment pour les grid de test Windows.

Il fallait donc un nouveau serveur de VM. By design, les guest Windows ne seront pas accessible depuis l’internet, et n’auront donc pas d’IP publique. En outre, les développeurs devront pouvoir accéder de façon transparente à leur Windows de test, si possible de manière sécurisée.

Les guests GNU/Linux, quand à eux,  pourront être accessibles via une IP publique, via VPN ou les deux à la fois.

La création / les duplications / la maintenance / le démarrage / l’arrêt des VM devra être très simple. (Le client souhaite  garder la main sur cela, et être maitre de la situation en matière de création de VM).

Choix de la technologie

Nous avons finalement retenu l’idée d’un serveur étant capable de faire cela :

Prérequis Kernel

Nous avons finalement utilisé le noyau 2.6.32.27. En effet les noyaux 2.6.36 présentent un bug dans le support KVM qui fait freezer la machine à la coupure des VM. (Nous sommes à priori victimes d’une régression dans le kernel Linux).
http://comments.gmane.org/gmane.comp.emulators.kvm.devel/65852

Nous avons donc upgradé sur le 2.6.37 mais, nous nous sommes heurtés à un nouveau bug kernel.

Bug kernel avec le 2.6.37

[76529.274129] rmap_remove: ffff88017deb37f8 1->BUG
[76529.274162] ------------[ cut here ]------------
[76529.274189] kernel BUG at arch/x86/kvm/mmu.c:700!
[76529.274217] invalid opcode: 0000 [#1] SMP
[76529.274247] last sysfs file: /sys/devices/virtual/net/lo/operstate
[76529.274276] CPU 2
[76529.274302] Pid: 27193, comm: kvm Not tainted 2.6.37 #1 01V648/PowerEdge R410
[76529.274333] RIP: 0010:[] [] drop_spte+0xb8/0x179
[76529.274389] RSP: 0018:ffff88080d987b28 EFLAGS: 00010296
[76529.274417] RAX: 000000000000003b RBX: ffff88017deb37f8 RCX: ffff8800000bc380
[76529.274449] RDX: 000000000000c3c3 RSI: 0000000000000046 RDI: ffffffff81918a88
[76529.274480] RBP: ffff88080d987b38 R08: 0000000000000000 R09: 000000000000000a
[76529.274512] R10: ffff88102f819400 R11: ffff88102f819400 R12: ffff880fe7cb0000
[76529.274544] R13: ffff88080d987b98 R14: 0000000000000000 R15: ffff88017deb37f8
[76529.274576] FS: 0000000000000000(0000) GS:ffff88102fc20000(0000) knlGS:0000000000000000
[76529.274623] CS: 0010 DS: 002b ES: 002b CR0: 000000008005003b
[76529.274652] CR2: 00007fb91807f000 CR3: 000000100aa0d000 CR4: 00000000000026e0
[76529.274684] DR0: 0000000000000090 DR1: 00000000000000a4 DR2: 00000000000000ff
[76529.274715] DR3: 000000000000000f DR6: 00000000ffff0ff0 DR7: 0000000000000400
[76529.274747] Process kvm (pid: 27193, threadinfo ffff88080d986000, task ffff8805a1d82630)
[76529.274794] Stack:
[76529.274815] ffff88080da10090 ffff880fe7cb0000 ffff88080d987b88 ffffffff8100ef8f
[76529.274870] ffff8805a1d82630 000000ff8109702a ffff88080d987c08 ffff880fe7cb0000
[76529.274925] ffff88080da10950 ffff88080d987b98 ffff880fe7cb2320 0000000000020d93
[76529.274981] Call Trace:
[76529.275006] [] kvm_mmu_prepare_zap_page+0x74/0x23c
[76529.275038] [] kvm_mmu_zap_all+0x41/0x6b
[76529.275069] [] kvm_arch_flush_shadow+0x11/0x1e
[76529.275101] [] kvm_mmu_notifier_release+0x2c/0x3f
[76529.275134] [] __mmu_notifier_release+0x49/0x74
[76529.275166] [] exit_mmap+0x27/0x147
[76529.275198] [] mmput+0x28/0xb4
[76529.275226] [] exit_mm+0x124/0x131
[76529.275254] [] do_exit+0x20f/0x6a7
[76529.275283] [] do_group_exit+0x71/0x99
[76529.275313] [] get_signal_to_deliver+0x2fa/0x315
[76529.275346] [] do_signal+0x6d/0x673
[76529.275375] [] ? kill_pid_info+0x3a/0x47
[76529.275404] [] ? sys_kill+0x82/0x161
[76529.275433] [] do_notify_resume+0x27/0x51
[76529.275464] [] int_signal+0x12/0x17
[76529.275491] Code: 48 d9 71 81 31 c0 e8 2b 7f 5c 00 0f 0b eb fe 40 f6 c6 01 75 26 48 39 f3 74 15 48 89 de 48 c7 c7 63 d9 71 81 31 c0 e8 0b 7f 5c 00 <0f> 0b eb fe 48 c7 00 00 00 00 00 e9 ac 00 00 00 48 83 e6 fe 31
[76529.275720] RIP [] drop_spte+0xb8/0x179
[76529.275752] RSP
[76529.276109] ---[ end trace 2d814c5436296e34 ]---
[76529.276177] Fixing recursive fault but reboot is needed!

Je vous renvoie à la mailing list de kernel.org à ce sujet. Ça ressemble beaucoup, le gars a le même problème sur un 2.6.36. Le mainteneur des kernel 2.4.x a posté un patch pour 2.6.36 sur le thread.

Voici ce qu’il faut activer dans le noyau pour que notre setup fonctionne :

- Networking support
-- Networking options
--- 802.1d Ethernet Bridging
--- Network Packet Filtering framework (netfilter)
---- Core Netfilter configuration (les options dont vous aurez besoin pour vos propres régles de firewalling)
---- IP: Netfilter Configuration
----- IP tables support
----- IPv4 Connection tracking support (required for NAT)
----- Full NAT
----- MASQUERADE target support

(à compléter, j’ai certainement du oublier un truc).

Installation des composants indispensables

Voici la liste des composants indispensables à installer avec votre package manager (apt-get sous Debian; emerge sous Gentoo) :

Use flags sous Gentoo

/etc/portage/package.use

app-emulation/libvirt libvirtd qemu lvm network nfs virt-network

Configuration du bridge (debian ways)

/etc/network/interfaces

auto lo
iface lo inet loopback
# The primary network interface

auto eth0
iface eth0 inet static
address 91.x.x.x
netmask 255.255.255.0
network 91.x.x.0
broadcast 91.x.x.255
gateway 91.x.x.1

auto br0
iface br0 inet static
address 91.x.x.x
netmask 255.255.255.0
network 91.x.x.0
broadcast 91.x.x.255
gateway 91.x.x.1
bridge_ports eth0
bridge_stp off
bridge_maxwait 5

auto br1
iface br1 inet static
address 172.16.20.1
netmask 255.255.255.0
network 172.16.20.0
broadcast 172.16.20.255
bridge_ports tap0
bridge_stp off
bridge_maxwait 5

pre-up iptables-restore -c /etc/network/iptables

auto eth1
iface eth1 inet static
address 10.191.78.4
netmask 255.255.0.0
network 10.191.0.0
broadcast 10.191.0.255

libvirt setup

/etc/default/libvirt-bin
start_libvirtd="yes"
libvirtd_opts="-d"

Creation du fichier de l’image :
# qemu-img create /var/VM/gentoo-x86_64.img 10G

/etc/sysctl.conf
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 1
net.bridge.bridge-nf-call-arptables = 0
net.ipv4.conf.all.bootp_relay = 1

Attention à l’isolation reseau des VM : https://bugzilla.redhat.com/show_bug.cgi?id=512206

Le DHCP ne doit pas envoyer de requêtes sur le reseau :
# iptables -t filter -A FORWARD -p udp --sport 68 --dport 67 -j DROP

Sécuriser le VNC de qemu/kvm en le forçant sur l’interface sécurisée

/etc/libvirt/qemu.conf
vnc_listen '172.16.20.1'

Problème de keymap bug libvirt

http://www.arnebrodowski.de/blog/keymap-problems-with-virt-manager.html

Iptables avec le bridge et la libvirt

http://ddevnet.net/wiki/index.php/How_KVM_or_libVirt_IPtables_work

Mise en place du dhcpd

/etc/dhcp/dhcpd.conf
ddns-update-style none;
option domain-name "zenexity.fr";
option domain-name-servers 81.93.xxx.xxx, 81.93.xx.xx;
default-lease-time 3600;
max-lease-time 7200;

log-facility local7;

subnet 91.xxx.xx.0 netmask 255.255.255.0 {
range 91.xxx.xx.20 91.xxx.xx.50;
option routers 91.xxx.xx.1;
}

subnet 172.16.20.0 netmask 255.255.255.0 {
range 172.16.20.128 172.16.20.254;
option routers 172.16.20.1
}

Exemple de création de VM

libvirt stocke ses fichiers de description de VM dans /etc/libvirt/qemu. Voici un exemple de fichier xml généré par libvirt :
/etc/libvirt/qemu/debian-50.xml


debian-50
ce5fe35a-703b-8291-9508-8a83f74eb110
524288
524288
1

hvm






destroy
restart
restart

/usr/bin/kvm





















Attention, si vous changez à la main un fichier domain.xml vous devez lancer la commande ;
# virsh define domain.xml

Internet pour les VM n’ayant été bind que sur le bridge du VPN

# iptables -t filter -A FORWARD -i br1 -j MARK --set-mark 1
# iptables -t nat -A POSTROUTING -m mark ! --mark 1 -o br0 -j MASQUERADE

Ou, moins fin :
# iptables -t nat -A POSTROUTING -o br0 -j MASQUERADE

Commandes libvirt qui vous serviront avec KVM

  • virsh start domain : Start le domaine spécifié
  • virsh shutdown domain : Shutdown le domaine spécifié
  • virsh reboot domain : just reboot a domain
  • virsh destroy domain : Terminate a domain
  • virsh autostart domain : Autostart a domain
  • virsh list : List domains

Ordre de boot des services

Cette partie est la pierre angulaire de ce setup :

  1. Il faut que dhcpd soit demarré après openvpn ! en effet sinon vous ne serai pas capable de diffuser des adresses ip sur votre interface br1 (bridgé avec l’interface tap0 du vpn) si le dhcpd ne demarre pas après openvpn.
  2. Il faut que la libvirt soit demarré après dhcpd, sinon vous ne serez pas capable de donner des ip à vos VM si celles-ci sont en auto start./etc/init.d/.depend.start
    TARGETS = rsyslog qemu-kvm killprocs openvpn apache2 isc-dhcp-server cron acpid ssh rsync dbus exim4 libvirt-bin bootlogs munin-node single rc.local stop-bootlogd rmnologin
    INTERACTIVE = openvpn apache2
    openvpn: rsyslog
    apache2: rsyslog
    isc-dhcp-server: rsyslog
    cron: rsyslog
    acpid: rsyslog
    ssh: rsyslog
    rsync: rsyslog
    dbus: rsyslog
    exim4: rsyslog
    libvirt-bin: rsyslog openvpn
    munin-node: rsyslog isc-dhcp-server qemu-kvm openvpn libvirt-bin apache2 bootlogs cron acpid ssh rsync dbus exim4
    single: killprocs bootlogs
    rc.local: rsyslog isc-dhcp-server qemu-kvm openvpn libvirt-bin apache2 bootlogs cron acpid ssh rsync dbus exim4
    stop-bootlogd: rsyslog isc-dhcp-server qemu-kvm openvpn libvirt-bin apache2 bootlogs cron acpid ssh rsync dbus exim4
    rmnologin: rsyslog isc-dhcp-server qemu-kvm openvpn libvirt-bin apache2 bootlogs cron acpid ssh rsync dbus exim4
  3. /etc/network/interfaces sur Debian aura toujours tendance à se lancer AVANT la création de tap0 par le service openvpn, or votre interface br1 doit être bridge sur tap0, il est donc nécéssaire de lancer ce petit script (J’ai rajouté ce script au script d’init de openvpn, ainsi celui est lancé juste après que le vpn soit lancé, ainsi le bridge entre br1 et tap0 est fonctionnel lorsque la libvirt se lancera) :
    /etc/zenexity/fixebr1
    sleep 10
    ifdown br1 && echo 'bridge down' >> /var/tmp/bridge
    sleep 1
    ifup br1 && echo 'bridge up' >> /var/tmp/bridge
    sleep 1
    /etc/init.d/isc-dhcp-server restart
  4. Plugin munin pour libvirt + KVM

    virt-cpu
    virt-memory

    Je vous renvoie au site du plugin LibVirt pour Munin.

Schema de l’infrastructure

Reverse SSH : accéder à un serveur derrière un NAT/Firewall

samedi 19 février 2011 à 15:30

Le SSH tout le monde le sait, c’est magique. Mais malheureusement ça ne marche pas OOTB. On a tous en tête plusieurs situations où on s’est dit “Damn, si seulement j’avais un accès SSH sur cette machine”, la machine étant inaccessible parce que derrière un firewall ou routeur NAT que vous ne contrôlez pas.

Imaginez avoir accès en SSH à la machine de ce noob qui ne sait pas configurer son NAT. Ou bien vous assurer que votre laptop soit toujours joignable en SSH peu importe la connexion sur laquelle il est…

Cette conférence du DEF-Con m’a interloqué : comment le mec a repris la main sur une machine qui était probablement derrière un NAT? Peut-être grâce au reverse SSH !

Principe de fonctionnement

Le principe est assez simple : c’est l’ordinateur derrière le NAT (nous l’appellerons distant) qui doit établir la première connexion. Il établit en fait un tunnel SSH vers vous (nous l’appellerons local) et ainsi en remontant le tunnel dans l’autre sens on accède très facilement à la destination.

On suppose donc que la connexion SSH vers l’ordinateur local est aisée (serveur dédié ou NAT bien configuré).

Avantages

Vérifiez la configuration du serveur SSH local

Il faut que le serveur sur local autorise les tunnels (/etc/ssh/sshd_config) :
AllowTcpForwarding yes

Let’s go!

Sur distant (la machine inaccessible), créez le tunnel :
distant$ ssh -NR 22222:localhost:22 user@local
Bien entendu local est l’IP de votre machine et user est un utilisateur qui y a accès.

Une fois le tunnel établi, il ne vous reste plus qu’à remonter le tunnel pour établir la connexion SSH depuis local :
local$ ssh -p 22222 user@127.0.0.1

Service au démarrage

Avec autossh (disponible dans le package manager de votre distro préférée) et une connexion SSH sans mot de passe, vous pouvez très facilement créer un script de démarrage sur distant pour que le tunnel soit toujours récréé sans intervention humaine :
# autossh -i /path/to/privateKey.rsa -NR 22222:localhost:22 user@local

Il vous suffit d’ajouter cette commande dans vos scripts de boot (/etc/rc.local par exemple).

Aller plus loin

Ici nous utilisons du SSH pour ouvrir l’accès à un serveur SSH, mais on pourrait envisager d’ouvrir l’accès à n’importe quel serveur qui tournerait sur distant, par exemple un serveur web pour du monitoring Munin :
distant$ ssh -NR 22280:localhost:80 user@local
local$ firefox "http://127.0.0.1:22280"

Vous l’aurez compris, vous pouvez aussi centraliser sur votre serveur (“local”) des tunnels venant de tous les n00bs que vous aidez régulièrement, l’astuce est de remplacer 22222 dans les diverses commandes citées sur cette page par un autre code de port compris entre 1024 et 65535. Et de maintenir une liste exhaustive de ceux-ci !

La nouvelle mode Geek : avoir son domaine .42

dimanche 19 décembre 2010 à 19:16

Ça claque à mort non d’avoir un nom de domaine en .42 ?
Vous l’avez rêvé ! Ils l’ont fait !
En clin d’œil à H2G2, pour épater un peu Marvin, et parce que la réponse universelle doit bien être ré-solvable quelque part sur le net 😉

Pour le moment pure expérimentation de la 42registry de ce .42, juste avant de peut être conquérir le monde ! (L’univers et le reste !)

Pourquoi on vous parle de ça ?

Bah parce que la 42registry.org ils sont cool, on les aimes bien, et on a envie de les aider.
C’est des fous, et nous chez GeekFault on aime bien les fous.

Vous pouvez d’ailleurs remarquer que si vous savez résoudre les domaines en .42 http://geekfault.42 est disponible.

Vous pouvez d’ailleurs remarquer que vous pouvez venir nous parler de geekfault ou de 42registry sur Geeknode : 4.irc.42 / salon #geekfault / et salon : #42

Votre humble serviteur est également lisible sur son .42 : http://bragon.42

Erf, je sais pas résoudre les domaines en .42, comment je fais ?

3 méthodes pour le moment :
– Je possède mon propre serveur DNS bind9
– Je possède mon propre serveur DNScache DJBDNS.
– Je veux utiliser des serveurs DNS open qui savent résoudre .42

Je possède Bind

Et bah je rajoute à mon named.conf (ou named.conf.local selon les distribs):


zone “42″ IN {
type forward;
forwarders {81.93.248.69; 81.93.248.68; 91.194.60.196; 193.17.192.53; };
};

Je reload bind, et roulz.

/etc/init.d/bind9 reload

ou

/etc/init.d/named reload

J’ai DJB … Oui Je sais ….


cd /services/dnscache
echo 91.191.147.246 > root/servers/42
echo 91.191.147.243 >> root/servers/42
svc -t /services/dnscache

Je suis un pauvre pommé, j’ai pas de serveur de nom

Et bien j’utilise les openDNS de GeekNode.org :

On édite /etc/resolv.conf

nameserver 81.93.248.69
nameserver 81.93.248.68

Hey mec ? Comment je réserve mon .42 ?

Gros poulet ! t’es pas déjà sur : http://42registry.org, tout est expliqué en long en large et en travers !
Alors va vite réserver ton .42 et faire passer le message.

Merci à la team 42registry pour tout l’poisson !

(Et surtout à Colin qui se reconnaîtra ;D)

Liste des domaines enregistrés

Ils sont disponible ici : http://bragon.42/42.txt

Devenez miroir de Wikileaks sans risque (corrigé)

dimanche 5 décembre 2010 à 00:14

Bon, d’habitude on se refuse de parler politique sur Geekfault… Mais on ne peut pas se taire plus longtemps sur ce qui se passe du côté de Wikileaks. En tant que geeks nous devons nous lever et protester contre ces atteintes à la liberté d’expression sur Internet.

Wikileaks a aujourd’hui publié sa solution à la censure : le mirroring. Si Wikileaks est consultable sur des centaines de noms de domaine et des centaines d’IPs, il sera d’autant plus difficile de tous les faire taire.

A noter que cet article, bien qu’entièrement orienté autour de ce sujet, s’applique aussi si vous souhaitez offrir à quelqu’un un accès SSH chrooté et aux commandes limitées.

Mise à jour : Mes mesures de sécurité étaient trop optimistes : Rsync n’utilise pas du SFTP mais doit pouvoir lancer un serveur Rsync sur sa destination en SSH. Voici donc une nouvelle version de cet article, testé et approuvé.

Le problème

Pour décentraliser la chose, les administrateurs de Wikileaks demande à tous les volontaires de leur offrir un accès en SSH à leur serveur pour pouvoir y pousser un miroir de Wikileaks et le garder à jour grâce à Rsync.

Ca qui m’a dérangé c’est le fait de donner un accès SSH à des inconnus sur mon serveur. Mais la solution existe : CHROOTER ce compte à un endroit où il ne peut faire aucun mal au système. Voici comment faire.

Attention : cet article ne porte bien évidemment pas sur la sécurisation de votre serveur. Il présente juste une manière d’éviter que les administrateurs de Wikileaks (que vous ne connaissez pas) aient trop de libertés sur votre serveur (et, oui, je suis paranoïaque sur le coup).

NB : Si vous souhaitez devenir très simplement un miroir Wikileaks et que vous leur faites entièrement confiance, les étapes “Créer l’utilisateur“, “Configurer un nom de domaine et un VirtualHost” et “Soumettre votre miroir à Wikileaks” sont suffisantes.

Sécuriser OpenSSH

On va donner à Wikileaks (ou toute personne ayant leur clé RSA privée) un accès SSH sur notre serveur. Mais on ne veut prendre aucun risque : cet accès n’aura aucune autre possibilité que de déposer des fichiers là où on l’y autorise, c’est-à-dire dans sa home.

Pour cela, modifiez votre fichier /etc/ssh/sshd_config. Vérifiez d’abord que vous avez ces trois lignes qui autorisent la connexion avec une clé publique RSA.
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile %h/.ssh/authorized_keys

Dernièrement, à la fin du fichier créez une nouvelle règle d’override telle que celle-ci :
Match user wikileaks
ChrootDirectory /home/wikileaks
X11Forwarding no
AllowTcpForwarding no

Cette règle est assez explicite et fait simplement en sorte que l’utilisateur wikileaks soit Chrooté dans sa home. Redémarrez SSHd.

Créer l’utilisateur

Rien de bien sorcier :
# mkdir /home/wikileaks
# useradd -d /home/wikileaks -s /bin/bash wikileaks
# chown wikileaks:wikileaks /home/wikileaks

Ensuite autorisons la connexion des administrateurs de Wikileaks :
# su - wikileaks
$ mkdir ~/.ssh
$ wget http://wikileaks.ch/id_rsa.pub -O ~/.ssh/authorized_keys
$ chmod 600 ~/.ssh/authorized_keys

Pour finir, n’oublions pas de créer le répertoire où sera hébergé le miroir :
$ mkdir ~/www

Créer l’environnement chroot

Pour qu’un chroot fonctionne correctement, il faut que sa racine appartienne à root. Nous créons aussi les deux répertoires indipensables à l’exécution d’un rsync : /bin et /lib.
# chown root:root /home/wikileaks
# mkdir /home/wikileaks/bin
# mkdir /home/wikileaks/lib

Ensuite copions les binaires nécessaires pour faire un Rsync :
# cp `which bash` /home/wikileaks/bin/bash
# cp `which rsync` /home/wikileaks/bin/rsync

Pour que ces binaires fonctionnent, il faut aussi copier les librairies nécessaires. Pour lister ces librairies vous pouvez exécuter un ldd puis copiez une à une ces libraires
# ldd `which bash` `which rsync`
# cp /lib/libncurses.so.5 /home/wikileaks/lib/
...

Attention : si votre serveur est un système 64bits il faudra créer le dossier /home/wikileaks/lib64/ et le peupler avec les librairies venant de /lib64.

Au final vous devriez arriver à une structure proche de celle-ci :
bin
|- bash
|- rsync
lib
|- ld-linux.so.2
|- libacl.so.1
|- libattr.so.1
|- libc.so.6
|- libdl.so.2
|- libncurses.so.5
|- libpopt.so.0

Dès maintenant, si on se chroote dans /home/wikileaks on n’aura que très très peu de possibilités : les commandes internes à bash et rsync.

Un dummyshell

Oui, je suis d’accord, les commandes internes de bash c’est encore trop! Nous permettons un accès SSH qui pourrait potentiellement lancer une fork bomb par exemple. Nous allons donc créer un shell stupide qui ne permet que de lancer un serveur Rsync. Créez le fichier /home/wikileaks/bin/dummyshell :
#!/bin/bash
if (( $# == 0 )); then
printf "%s\n" "shell access is disabled. sorry."
exit 1
elif (( $# == 2 )) && [[ $1 == "-c" && $2 == "rsync --server"* ]]; then
exec $2
fi

Il faut ensuite le rendre exécutable et utilisé comme shell par défaut de l’utilisateur :
# chmod +x /home/wikileaks/bin/dummyshell
# ln -s /home/wikileaks/bin/dummyshell /bin/dummyshell
# usermod -s /bin/dummyshell wikileaks

C’est maintenant officiel, l’utilisateur wikileaks ne peut rien faire de plus que lancer un serveur Rsync ! Et il y a aussi la sécurité du Chroot.

Test

Je vous recommande de tester le tout, pour être sûr que Wikileaks pourra uploader son site sur votre serveur. Pour cela ajoutez votre propre clé RSA dans une nouvelle ligne de /home/wikileaks/.ssh/authorized_keys et tentez d’envoyer un fichier :
$ rsync -ave ssh test.html wikileaks@votreServeur:/www

Vous pouvez également éprouver la sécurité en tentant de vous connecter en SSH ou d’exécuter une commande en SSH -t.

Configurer un nom de domaine et un VirtualHost

Je suppose que vous vous en sortirez sur ce point-là : créez un nom de domaine (ou un sous-domaine) pour votre miroir et configurez votre serveur web en conséquence.

Le DocumentRoot à spécifier est bien /home/wikileaks/www

Profitez-en pour empêcher l’exécution de scripts sur le répertoire :

AllowOverride None
Options -ExecCGI

Soumettre votre miroir à Wikileaks

Rendez-vous sur http://46.59.1.2/mass-mirror.html et soumettez votre miroir !

Sous “absolute path where we should upload the html data” mettez simplement “/www/”.

Normalement Wikileaks pushera l’entièreté du site sur votre serveur. Félicitations, vous défendez la liberté d’expression sans risque majeur pour votre serveur !

Sikuli : programmez avec des screenshots

dimanche 31 octobre 2010 à 17:53

Il nous arrive souvent de devoir refaire la même chose encore et encore sur nos ordinateurs. Et pourtant, ce sont eux les machines! Évidemment les plus érudits ont déjà tout un tas de scripts bash (ou un autre langage obscur) pour leur simplifier la vie.

Mais il reste toujours certaines interactions qu’on n’arrive pas à automatiser : celles qui touchent aux interfaces graphiques (lorsqu’aucune API n’est présente/utile). Je vous présente donc Sikuli, le moyen d’automatiser simplement ce qu’on voit à l’écran à partir de screenshots.

Installation

Sikuli est un programme open-source en Jython (un interpréteur Python en Java, silence dans le fond de la salle~) et dispose de versions compatibles avec Windows, MacOS et évidemment Linux (32 ou 64bits). Je vous renvoie donc sur la page de téléchargements du projet pour télécharger la dernière version.

Assurez-vous d’avoir toutes les dépendances:
sudo apt-get install sun-java6-jre libcv4 libcvaux4 libhighgui4

Rien à compiler, décompressez le tout et lancez sikuli-ide.sh

Scripts simples

Je ne pense pas que tout vous expliquer soit réellement utile ici, l’application est très intuitive. Les instructions principales sont évidemment click(…), rightClick(…) ou type(“…”). Tout est renseigné dans la colonne de gauche.

Pour insérer un screenshot je vous recommande le raccourci clavier Ctrl+Maj+2 ou, s’il ne fonctionne pas à l’endroit où vous souhaitez le faire, utilisez le bouton de screenshot de Sikuli qui a un délai configurable dans les préférences.

Voici par exemple un script qui change la résolution de mon écran (oui, je sais, je pourrais le faire avec xrandr mais ici c’est vraiment à la portée de n’importe qui) :

Remarquez que sur certains des screenshots il y a un point rouge. Il correspond à l'endroit précis qui sera cliqué, appelé Target Offset dans Sikuli et programmable en cliquant sur le bouton représentant le screenshot.

Scripts un peu plus intelligents

Bien sûr Sikuli est proche d’un vrai langage de programmation et permet donc des scripts plus puissants, plus intelligents. On peut faire des boucles, des conditions, des wait, etc.

Voici quelques exemples simples qui parlent d’eux-même.

value = input("Entre la bonne valeur : ")
type(value + "\n")

Beaucoup d’autres exemples sont consultables dans la documentation de Sikuli.

C’est bien beau pour les n00bs, mais pour les geeks comme moi?

Bon j’ai du me détruire le cerveau à trouver une utilité à Sikuli pour les geeks durs de dur qui savent tout faire en bash… Et j’ai trouvé!

Si vous développez des interfaces graphiques, Sikuli peut faire des unitTests sur celles-ci ! On peut aussi utiliser les possibilités de Sikuli dans ses propres logiciels Java.

On peut aussi interagir avec des grosses méchantes applications web en AJAX… Si vous trouvez d’autres utilités, laissez-les en commentaire 🙂

Lancer un script

On peut évidemment lancer un script depuis l’interface graphique de Sikuli mais le plus intéressant est de le faire depuis un terminal ou un raccourci. Rien de plus simple, il suffit d’appeler Sikuli avec le paramètre –run :
/chemin/vers/sikuli/sikuli-ide.sh --run /chemin/vers/script.sikuli

J’en ai même un assigné à un raccourcis clavier (Google est votre ami, les raccourcis clavier dépendent de votre environnement graphique)

En savoir plus

Can't retrieve feed: file_get_contents(): SSL operation failed with code 1. OpenSSL Error messages: error:141A318A:SSL routines:tls_process_ske_dhe:dh key too small