Ah oui quand même !
edit : ah oui et sur raspbmc, désactiver le firewall ne fonctionne pas, il faut désactiver (ou configurer) iptables en ssh sinon pas d’accès sabnzbd/sickbeard depuis un réseau extérieur.
Sur mon XBian, le fait d’ouvrir les ports a suffit…ça dépend peut-être des distribs…
Et sinon, ouais, je pense que passer d’un (vieux, mais quand même) PC de jeu tout équipé à un machin qui consomme 2 ou 3 watts, quand on laisse le bouzin allumé 24/7, ça se ressent vite 
Oui configurer iptables reviendrait à ouvrir les ports. Seulement dans raspbmc, il y a une option accessible directement depuis l’interface sensée désactiver le firewall, et visiblement ça ne fonctionne pas. Donc je l’ai juste désactivé (le raspi est déjà derrière un firewall).
Petit truc aussi pour le montage du NAS, j’ai du mettre cette ligne dans fstab :
//BENDER/Bender /home/pi/BENDER_share cifs credentials=/home/pi/cifs.credentials,workgroup=WORKGROUP,sec=ntlm,rw,nounix,iocharset=utf8,file_mode=0777,dir_mode=0777 0 0
L’option sec était obligatoire, j’ai pas essayé sans file_mode et dir_mode, mais en tout cas mettre seulement //PARTAGE /dossier user mdp ne fonctionnait pas (problème de droits pour créer des dossiers/fichiers)
Bizarre parce qu’actuellement, sickbeard créé bien les dossiers et fichiers sur mon NAS (et j’ai pas spécialement changé la config…)
J’ai eu un petit soucis avec le script de cherny, il manque principalement l’alimentation de sb_config + IPB qui a du changer la ligne du wget pour coller des balises URL.
Voici ce que ça donne
#!/bin/shBEGIN INIT INFO
Provides: SickBeard
Required-Start: $network $remote_fs $syslog
Required-Stop: $network $remote_fs $syslog
Default-Start: 2 3 4 5
Default-Stop: 0 1 6
Short-Description: Start SickBeard at boot time
Description: Start SickBeard.
END INIT INFO
case “$1” in
start)
echo “Starting SickBeard…”
/usr/bin/sudo -u pi -H /usr/local/sickbeard/SickBeard.py -d --datadir /var/sickbeard --config /var/sickbeard/sickbeard.ini
echo “SickBeard started !”
;;
stop)
sb_config=/var/sickbeard/sickbeard.ini
p=ps aux | grep -v grep | grep SickBeard.py | tr -s \ | cut -d ' ' -f 2
if [ -n “$p” ]; then
echo "Shutting down SickBeard…"
sb_api_key=grep -m 1 api_key ${sb_config} | cut -d ' ' -f 3;
sb_port=grep -m 1 web_port ${sb_config} | cut -d ' ' -f 3;
wget -q --delete-after http://localhost:${sb_port}/api/${sb_api_key}/?cmd=sb.shutdown
while ps -p $p > /dev/null
do
echo “Waiting for SickBeard …”;
sleep 5;
done
echo "SickBeard stopped !"
else
echo "SickBeard is not running"
fi
;;
*)
echo "Usage: $0 {start|stop}"
exit 1
esacexit 0
Un clone de raspberry interessant :
The Hardkernel ODROID-U3 sells for $59. It’s about the size of a credit card, but has room for a Samsung Exynos 4412 quad-core processor, 2GB of RAM, 3 USB ports, a micro USB port, micro HDMI port, and microSD card slot.
http://liliputing.com/2013/12/odroid-u3-59-dev-board-with-the-power-of-a-galaxy-s3.html
@Bussiere : Ca a l’air chouette parce que c’est sur une toute petite carte, mais j’ai peur que la dissipation thermique ne soit pas facile avec une bestiole pareille.
Edit :
http://forum.odroid.com/viewtopic.php?f=10&t=915&p=5259&hilit=temperature#p5259
I’ve found interesting lines in arch/arm/mach-exynos/mach-odroid-x.c
I guess that it means that if CONFIG_EXYNOS_THERMAL is activated (it is disabled in current ubuntu images by a misstake, but you can rebuild a kernel) CPU frequency would drop to 800 Mhz if it is hotter than 85 degrees. And if it heats to more than 105 it would drop frequency to 200 MHz.
#ifdef CONFIG_EXYNOS_THERMAL
/* below temperature base on the celcius degree /
struct tmu_data exynos_tmu_data __initdata = {
.ts = {
.stop_throttle = 82,
.start_throttle = 85,
.stop_warning = 102,
.start_warning = 105,
.start_tripping = 110, / temp to do tripping /
.start_hw_tripping = 113, / temp to do hw_trpping*/
.stop_mem_throttle = 80,
.start_mem_throttle = 85,.stop_tc = 13, .start_tc = 10,},
.cpulimit = {
.throttle_freq = 800000,
.warning_freq = 200000,
},
.temp_compensate = {
.arm_volt = 925000, /* vdd_arm in uV for temperature compensation /
.bus_volt = 900000, / vdd_bus in uV for temperature compensation /
.g3d_volt = 900000, / vdd_g3d in uV for temperature compensation */
},
.efuse_value = 55,
.slope = 0x10008802,
.mode = 0,
};
#endif
[quote=« Histrion, post:187, topic: 54705 »][/quote]
merci 
Une nouvelle utilisation potentielle des RaspPi: audit wifi foutage de merde chez les copains via le projet FruityWifi.
Même principe que le Pineapple: entre moultes autres utilisations potentielles, ca (Karma) crée un point d’acces dont le SSID change en fonction des probes de nos appareils Wifi. En clair: un grand nombre d’appareils crient a tue-tête les SSIDs qu’ils connaissent en espérant que le point d’acces soit dans les parages et réponde “yep c’est moi”. Karma tente simplement de se faire passer pour un de ces points d’acces. Arrangez vous pour servir de bridge Wifi et hop, vous pouvez sniffer tout ce que votre cible fait sur le net.
Pas encore eu le temps de mettre les mains dedans… mais j’aimerai bien tester ca dans une conférence en mai… j’espère avoir le temps d’ici là.
Hmmmm, pas besoin de sniffer, mais en faisant un intermédiaire on peut remplacer toutes les images des sites web par des photos de Nicolas Cage et là au moins c’est marrant.
Nos appareils Wifi n’utilisent pas d’empreinte pour vérifier qu’ils se connectent bien aux bons appareils et pas à n’importe quel réseau Wifi qui a le même nom ? Ou c’est l’empreinte qui est imitée ?
A part le SSID ils regardent pas grand chose, tant que c’est le même et le mot de passe/type de protection c’est bon.
[quote=“JakeGrafton, post:189, topic: 54705”][/quote]
thks
[quote=“Glasofruix, post:192, topic: 54705”][/quote]
Donc je peux créer une réseau WiFi du même nom que celui de mon voisin, faire que mon voisin se connecte à mon faux réseau et envoie par erreur son mot de passe sur mon réseau ? Ça me semble trop simple.
A priori c’est aussi con que ça, mais a quand même un peu de trucs en mémoire pour différencier les connexions, comme le canal et l’adresse MAC de l’émetteur (la puissance du signal aussi), donc ton voisin va se connecter au réseau qu’il connaît quand les deux sont dispos en même temps. Par contre si y en a qu’un seul…
heu, faut quand meme bien saisir à un moment donnée la clef du reseau wifi non ?
A priori c’est (presque) aussi con que ca.
Naturellement Karma ne va pas te permettre de simuler un point d’acces sécurisé, mais il suffit que tu te sois connecté une fois a un point d’acces ouvert (et ne l’ait pas “oublié” - ce qui sur iPhone par exemple n’est pas possible a fortiori, seulement tant que le réseau est visible) pour que tu ais un point d’accès que Karma peut utiliser. Ensuite la plus part des appareils fonctionnent sur le mode “le signal le plus puissant est préféré” donc même chez soi avec son Home-Wifi on “pourrait” être emmerdé si un Pineapple suffisamment puissant était dans le coin.
Pour ce qui est du mot de passe je crois que c’est un peu plus compliqué que ca (mais je ne peux pas vérifier là maintenant). Il y a une sorte de Handshake qui se passe avant l’échange du mot de passe, Handshake que Karma ne peut pas simuler aussi simplement.
[quote=“Bussiere, post:186, topic: 54705”][/quote]
Le souci avec ce genre de carte c’est le support OS dans le temps : chez les chinois c’est souvent aussitôt vendu, aussitôt oublié. Alors que le RPi bénéficie de MaJ régulières depuis plus de deux ans… Les cartes àlakon qui auront une durée de vie utile de 2 mois, j’ai arrêté personnellement …
Le plus compliqué c’est le gestionnaire de paquets (tu parlais peut-être plutôt de ça en disant OS). Là, effectivement, il faut qu’une communauté existe… Même pour le Raspberry ça n’a pas été simple au début.
[quote=“Histrion, post:199, topic: 54705”][/quote]
En fait je parlais de plusieurs choses :
- Kernel car il y a souvent des blobs binaires (non open source) pour les SoC, donc si le vendor abandonne le SoC en cours de route, bonne chance pour avoir des updates de kernel (note au passage, ce problème touche également les téléphones Android, et certains SoC Qualcomm sont bloqués en kernel 2.6)
- Paquetages (car il faut des paquetages optimisés pour le SoC, pas de communauté derrière, pas de MaJ de paquetages)