Different directory and also root password does not work
azngeek opened this issue · comments
Hi,
i wanted to setup dlite in a way that i can use a different directory which i can use as a volume mount then. I checked the past issues and it seems like that the default directory is /Users. By inspecting the latest stable release version 1.1.5 i saw that you can specify an alternative mount. So this is what i did.
- Checked the version
> dlite version
1.1.5
- Stopped dlite and ensured that it is not running
ps aux |grep dlite
dlite stop
- Install the latest version and specify path
sudo dlite install -v 2.3.0 --share=/Volumes/myexternaldir
- Try to check if the mount work
docker run -d --name=test -p 192.168.64.5:80:80 -v /Volumes/myexternaldir:/test test_image
- Log into my container and check if mount is available
docker exec -it <id> bash
ls -lisah /test #empty
- Check on docker image, if mount is present
ssh root@docker.local
# and also with screen and password 'dhyve'
#sudo screen /dev/ttys000
Password:
Sorry, try again.
Password:
Sorry, try again.
Password:
So the question is: Did i miss something? The volume should be available with the --share command. And also the docker parameters used are very basic. That's the point where i need to validate the correct mount point but this is not possible as i can not log into the docker instance. Also the local.docker ip seems to be increased after various start and stop attempts.
Additional information:
cat ~/.dlite/config.json
{"uuid":"<id>","cpu_count":1,"memory":2,"hostname":"local.docker","share":"/Volumes/myexternaldir"}|
Update on the directory stuff. It seems like that the shares defined in the config.json do not get updated. So you need to manually edit the etc/exports file.
> cat /etc/exports
# BEGIN: dlite
/Volumes/myexternaldir -network 192.168.64.0 -mask 255.255.255.0 -alldirs -maproot=root:wheel
# END: dlite
if your ip is changing it's because you've run the install command again, which generates a new uuid and therefore a new ip.
the root login doesn't work over ssh though i do plan to enable it in the future. it not working in screen is very wrong, however. there's no reason that should ever not work, that password is hard coded in the os image.
try to use the docker user over ssh and it will hopefully have your key in place so it won't even prompt for a password.
as for the volume share, i can take a look as to why it might not be creating the correct export for you. sounds like a bug for sure.
I had a similar issue using 1.1.5 with the export not being created correctly, it was still /Users rather than the share defined at at install which resides in ~/.dlite/config.json.
Am I right in reading that https://github.com/johanneswuerbach/nfsexports/blob/master/nfsexports.go#L31-L33 is checking for the identifier dlite and not the contents? Could mitigate by removing existing exports with the dlite identifier before adding new ones.
I'm currently debugging permissions inside which may be related, I'm unable to write files inside the containers since I moved my share around.
While debugging this I noted that you can login via ssh docker@local.docker and sudo as required.
diff --git a/utils/hosts.go b/utils/hosts.go
index 9772c82..afc8790 100644
--- a/utils/hosts.go
+++ b/utils/hosts.go
@@ -151,6 +151,8 @@ func AddExport(uuid, share string) error {
share = "/Users"
}
+ nfsexports.Remove("", "dlite")
+
export := fmt.Sprintf("%s -network 192.168.64.0 -mask 255.255.255.0 -alldirs -maproot=root:wheel", share)
_, err := nfsexports.Add("", "dlite", export)
if err != nil {This resolves the export creation when changing shares for me on legacy.
I figured that was the case. Feel free to submit a pull request and I'll get it merged and a patch release out
I figured that was the case. Feel free to submit a pull request and I'll get it merged and a patch release out
Sweet, I'll send a PR I'm just not clear on the reloading.. I was running sudo dlite daemon to go fast, its then the export was updated. Is that functionally equivalent to dlite stop && dlite start?
right, dlite stop halts the daemon process and dlite start brings it back up, so your fix should work perfectly
Btw. do you have any idea how i can reset the IP? I would like to keep it static if possible?
there's no way to forcibly make it static, but if the UUID for your virtual machine doesn't change it should always get the same IP. you can look in /var/db/dhcp_leases and see what each UUID you've had running maps to and set your config to match the one you want if it's already taken, but that's about the best you can do