Djey

Bonjour, à mon avis, un conteneur Docker ne pourra pas accéder à une clé USB branchée sur le serveur. Docker ne gère que des flux réseau ou des volumes disques partagés, il n'accède pas nativement au matériel. Ce n'est pas le même principe / but qu'une machine virtuelle.

Bonjour, la seule solution que j'aie trouvée pour le démarrage est d'utiliser la fonction wake-on-lan du HP (si activée dans le BIOS). Mais cela nécessite qu'un appareil tourne sur le réseau et 'réveille' le microserver à une heure définie. Pour ma part, j'ai créé un outil en ruby qui tourne H24 sur un raspberry pi. Sinon à la demande une simple appli smartphone fait très bien le job du WOL (il en existe pas mal de dispo). Et pour l'arrêt, oui bien sûr on peut scripter l'extinction du serveur avec le shell ESXi. Et selon la configuration des VMs, on peut leur demander de s'arrêter proprement juste avant l'extinction (les vmware tools doivent être installés sur la VM, un paquet syno existe). Idem l'outil sait gèrer l'arrêt à la demande (via une requête http) ou selon une planification basique avec cron. Cela peut s'installer à la mano ou via un docker. + d'infos : viewtopic.php?f=2&t=4475

I think you're very close. Personally, I just had to create/edit this file in ESXI shell (connect with ssh as root): /etc/ssh/keys-root/authorized_keys and append my public key to it. I can't remember of additional ESXi settings necessary. Might help in your case.

Indeed, authentication has to be correctly set-up before starting pi-control container. Here is a starter link : https://blogs.vmware.com/vsphere/2012/0 ... xi-50.html Here comes some explanation on article steps: To generate a private/public key pair onto dsm, you just log onto DSM shell then run: ssh-keygen and follow instructions. It will create keys in directory : /root/.ssh/ ( or if you already have keys, copy them into /root/.ssh/ directory) Then, connect to ESXl from DSM: ssh root@ And confirm to add key to host cache In ESXI, edit /etc/ssh/keys-/authorized_keys file and copy contents of previously generated id_rsa.pub (public key) - that's what ssh-copy-id command does. Exit ESXI shell and try connecting again. If properly configured, next time connection won't require password. To run the container, you just check volume parameter to point your DSM keys directory, check -v parameter : -v /root/.ssh:/root/.ssh Also, after running pi-control container, execute command and post results here : docker logs pi-control Should be better after that. Please let me know Thanks

Sorry for late reply, I just tested smartX x64 image against SynoDocker. Working here. From root shell: docker run -d -p 8080:80 -e PI_CONTROL_ADDRESS=':4600' --restart=always --name smartx djey/smartx-linux-x64:0.1 , assuming that pi-control container running under host port 4600. Thus smartX web-ui will be available through http://:8080/smartx.html

Tested and it works as well as containerized on rPi Sadly, DSM GUI did not let me provide all required arguments to run image into a container; I had to type from root shell: docker run -d -p 4600:4600 -e ESXI_HOST='x.x.x.x' -e ESXI_USER='root' -e ESXI_MAC_ADDR='xx:xx:xx:xx:xx:xx' -e LAN_BROADCAST_ADDR='x.x.x.x' -v /root/.ssh:/root/.ssh --restart=always --name pi-control djey/pi-control-linux-x64:0.1 Running container does appear into DSM GUI afterwards, so that's alright finally. - I'm with DSM 5.2-5967 U1 - Edit: x64 Linux image available for smartX web interface. But need to be tested against SynoDocker, still.

Thanks haydibe, looks like DSM GUI always wanna get 'latest' tag. So latest tag is working for some images, some other won't (might be due to different docker version - ARM images are pushed from my raspberry PI directly, x64 ones from virtualized Xubuntu 14.04 ) I guess that manually (command line) pulled images do appear into DSM as well? Sorry I haven't time to try this till tomorrow.

That's weird, I could pull the image from PC at work, but DSM GUI couldn't for the same reasons as you. All other images can be retrieved without a hitch. Maybe I should recreate the repository and push again ...

Docker image for x64 Linux kernel is ready. It should run fine within xpenology. https://hub.docker.com/r/djey/pi-control-linux-x64/ Please note that some limitations do remain, due to the base image I've been using (Alpine). Will fix it in the future.

Yeah, my fault I'm afraid. I did not provide details about image compatibility. A x64-based image (from alpine linux I guess) should work well on syno docker.

Hi, that happens because the current image is based on Debian for ARM (raspbian:jessie) as it's running on a raspberry PI. To make it run on x64 architecture, I have to create a new image. I will do eventually.

Finally! I was able to create Docker images for both pi-control and smartX projects! Those first images are made for devices running raspbian:jessie. pi-control: https://github.com/djey47/pi-control/wi ... install%3F (instructions) and https://hub.docker.com/r/djey/pi-control-raspbian/ (hub) smartX: https://github.com/djey47/smartX/blob/master/README.md (instructions) and https://hub.docker.com/r/djey/smartx-raspbian/ (hub)

Hi, pi-control services do actually run on raspberryPi (or similar device). It's not so easy to install (or even create a such a spk file) on the NAS - due to lack of software support on DSM. smartX could be however, as it only need nginx. Some of the reasons why I decided to set everything on a rPi: - the need to control the NAS even when ESXi is OFF (e.g. to start it) - the need to check hypervisor status with all Vms plugged in, even when xpenology is not running. and yes, smartctl seems to work finally on xpenology. The fact is, smartX is just a webapp and can't directly get data from the system, it must use a data source (like JSON sent by pi-control) to get values. A solution would be to enhance pi-control to provide info from smartctl as well ... By the way, as a first step I was planning to use ESXI smartd daemon to get latest events. https://github.com/djey47/pi-control/issues/10 I will take note of your idea, can't guarantee to get time to put my hands on it, but who knows ... Thanks for your interest in this project!

Il serait intéressant de voir du côté du paramétrage smb du xpenology. Le protocole a du évoluer.

@elmuziko: it should work with ESXi 5.1, as it does not rely on tools which are 5.5-specific. @McDull: No, SMART support has not always been available with smartctl/smartd, depending on xpenology version and installed bootloader. It did work with Trantor's 4.3. When I migrated to 5.0, gnoBoot did not support it; that's why I had to find a workaround. Now, nanoboot seems to have it fixed. So what will be next ? I can't definely rely on the bootloader... A major advantage is I can monitor my datastore hdd to ESxi the same way:) Anyway you're right, if your hardware support VT-d, adding a 3rd part disk controller and using passthrough mode is the way to go to. That's not an option with N54L.