• Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About Djey

  • Rank
    Advanced Member
  1. 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.
  2. Djey

    Xpe & ESXI

    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 p
  3. 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.
  4. Indeed, authentication has to be correctly set-up before starting pi-control container. Here is a starter link : ... 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-/authorize
  5. 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
  6. 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
  7. 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.
  8. 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 ...
  9. Docker image for x64 Linux kernel is ready. It should run fine within xpenology. Please note that some limitations do remain, due to the base image I've been using (Alpine). Will fix it in the future.
  10. 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.
  11. 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.
  12. 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: ... install%3F (instructions) and (hub) smartX: (instructions) and (hub)
  13. 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 ge
  14. Il serait intéressant de voir du côté du paramétrage smb du xpenology. Le protocole a du évoluer.
  15. @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