Microblog : A very long article Wikipedia article on the orientation of toilet paper [7 jun à 22:52] [R]

Dimanche, 19 février 2017

Cookies aux pépites de chocolat

Catégories : [ Cuisine ]

Une recette adaptée de Cookwise avec des ingrédients disponibles en Finlande.

Ingrédients

Pour environ 32 cookies.

  • 140g + 30g beurre doux
  • 125g noix de pécan
  • 200g fariinisokeri
  • 1 c. à soupe extrait de vanille liquide
  • 1 oeuf
  • 200g kakkuvehnäjauho
  • 1,5 c. à café levure chimique
  • 1 pincée de sel
  • 80g chocolat noir 72% Pirkka luomu
  • 100g chocolat au lait Panda

Préparation

  • Préchauffer le four à 180 °C, étaler les noix de pécan sur une plaque à biscuits.
  • Mélanger (30s au mixeur) la farine, la levure chimique et le sel.
  • Battre (au batteur éléctrique équipé d'un fouet) 140g de beurre avec le sucre et l'extrait de vanille pour obtenir un mélange homogène. Ajouter l'oeuf et continuer à battre.
  • Faire griller les noix de pécan au four pendant 8 min.
  • Incorporer peu à peu le mélange de farine à l'appareil.
  • Lorsque les noix sont grillées, les mélanger à 30g de beurre et laisser refroidir un peu.
  • Hacher le chocolat au couteau en morceaux d'au plus 5mm et mélanger brièvement à l'appareil.
  • Hacher les noix au couteau en morceaux d'au plus 5mm et mélanger brièvement à l'appareil.
  • Laisser reposer 2h au réfrigérateur.
  • Préchauffer le four à 180 °C.
  • Placer 8 ou 9 boules de pâte grossièrement formées d'environ 35 – 40mm de diamètre sur une plaque en aluminium recouverte d'une feuille de cuisson réutilisable. Replacer le reste de pâte au réfrigérateur.
  • Cuire pendant 9 min au milieu du four.
  • Laisser refroidir 5 min puis déplacer les cookies à l'aide d'une spatule sur une grille.
  • Répéter les trois étapes précédentes avec le reste de la pâte.
  • Conserver dans une boite à biscuits en métal.

[ Posté le 19 février 2017 à 11:45 | pas de commentaire | ]

Dimanche, 5 février 2017

SSH access to a Buffalo LS210 NAS

Traduction: [ Google | Babelfish ]

Catégories : [ Informatique ]

My old NAS that I use for backups is now over 10 years old, and while it still works and faithfully backs-up my files every night, it has an always increasing probability to fail.

I decided to replace it with a Buffalo Linkstation 210, that offers 2 TB of space for 140 EUR, making it cheaper than building my own device, at the risk of not being able to use it the way I want it, being a commercial device that wasn't designed with my needs in mind.

The way I want to use the NAS is that it boots automatically at a given time, after which the backup script on the desktop starts, transfers the needed files, and puts the NAS to sleep mode again. That last feature was available on my previous device, but not anymore on the LS210. Hence the need to make it do my bidding.

Moreover, the Web UI for administrating the LS210 is horribly slow on my desktop due to bad Javascript code, so the less I have to use it, the better.

The device

The way to gain SSH access seems to vary depending on the exact version of the device and the firmware. Mine is precisely a LS210D0201-EU device with firmware version 1.63-0.04, bought in January 2017.

Initial setup

I found instructions on the nas-central.com forum. It relies on a Java tool called ACP_COMMANDER that apparently uses a backdoor of the device that is used for firmware updates and whatnots, but can apparently be used for running any kind of shell command on the device, as root, using the device's admin user's password.

Let's assume $IP is the IP address of the device and "password" is the password of the admin user on the device (it's the default password).

You can test that ACP_COMMANDER works with the following command that runs uname -a on the device:
java -jar acp_commander.jar -t $IP -ip $IP -pw password -c "uname -a"
It will output some amount of information (including a weird message about changing the IP and a wrong password ), but if you find the following in the middle of it, it means that it worked:
>uname -a
Linux LS210D 3.3.4 #1 Thu Sep 17 22:55:58 JST 2015 armv7l GNU/Linux

Starting the SSH server is then a matter of

  • enabling the SSH feature (which, on this cheap model, is disabled by default),
  • starting the SSH server,
  • changing root's password to "root" so that we can login (the password can be changed to something more secure later).
This is achieved through the following commands:
java -jar acp_commander.jar -t $IP -ip $IP -pw password -c "sed -i 's/SUPPORT_SFTP=0/SUPPORT_SFTP=1/g' /etc/nas_feature"
 
java -jar acp_commander.jar -t $IP -ip $IP -pw password -c "/etc/init.d/sshd.sh start"
 
java -jar acp_commander.jar -t $IP -ip $IP -pw password -c "(echo root;echo root)|passwd"

On some older version of the firmware, root login was disabled in SSH, and needed to be allowed with

java -jar acp_commander.jar -t $IP -ip $IP -pw password -c "sed -i 's/#PermitRootLogin/PermitRootLogin/g' /etc/sshd_config"
but that is not the case on my device.

Once this is done, I can run
ssh root@$IP

and login with password "root" (which was set earlier).

One nasty feature of the device is that the /etc/nas_feature file gets rewritten on each boot through the initrd. One last step is then to edit /etc/init.d/sshd.sh and to comment out near the beginning of the file the few lines that check for the SSH/SFTP support and exit in case SSH is not supported:
 #if [ "${SUPPORT_SFTP}" = "0" ] ; then
 #        echo "Not support sftp on this model." > /dev/console
 #        exit 0                                               
 #fi

According to a comment on the nas-central forum,

“The /etc/nas_feature is restored on each reboot, so sshd does not run on boot. Even if you change the init script.”

but I found this not to be true.

I checked that this setup really resists reboots, by logging in as root and typing reboot. SSH access was still possible after the device had restarted.

Going further

It was then possible to setup SSH access using keys; RSA and ECDSA are supported but not ED25519.

One missing feature is the sudo command, but I can live without it I guess.

I have then setup the device to wake up at a given time (through the “Sleep timer” feature in the administration Web UI). It is then possible to put the device to sleep by running as root
PowerSave.sh standby
The command is located in /usr/local/sbin, and this path is not available for non-interactive logins, so I wrote the following wrapper script to shutdown the device:
#!/bin/sh
 
ssh root@$IP 'bash -l -c "PowerSave.sh standby"'

After having been put into standby, the device will then start automatically on the set time, or when the “function” button on the back is pressed.

[ Posté le 5 février 2017 à 12:52 | pas de commentaire | ]