https://rancher.com/ logo
Join Slack
Powered by
This message was deleted.
# lima
a
This message was deleted.
f
I'm slightly uncomfortable with merging experimental code that is known not to really work, if nobody is going to continue to work on it. If you simply want to preserve it for posteriority, just in case, then I would rather keep it in a branch, where it isn't in the way when the main branch needs to be modified for other requirements.
b
that was not the intention, only submitting the patches that actually do work - like paths and such
even if they only make up half of a working program. others will be in "draft" or in branch, like you say
f
I guess this is fine, but if it e.g. drags in a requirement on Cygwin, then I'm not sure if this is something we want; maybe the next person is going with a different approach anyways
b
I think I was a bit unclear, I meant "Cygwin paths" as in 
cygpath.exe
.
Which turned out to not be the same anyway, i.e. /c rather than /cygdrive/c 🙂
f
Ok, let's see; I assume these will not be massive changes anyways. I'm just a bit cautious because I've been stuck maintaining old codebases before, with insufficient test coverage, and large chunks of seemingly dead code, which made it impossible to modify because nobody know if this would break something unrelated, or not.
b
BTW; I managed to fix the paths also for the home directory. It was a rather sad story, actually
f
If these are all just small localized changes, then it should be all good
b
In theory, UNC would be the way to solve it. But in practice, the only thing that works is DOS path
Unfortunately, the "syscall" and "filepath" changes are everywhere. Maybe for-the-better, but still annoying
f
I think those kind of changes are fine
What I'm worried about is (for example) a bunch of logic for qemu configuration that is intermingled with the current code, which is already quite complex
b
Indeed. My home was that named pipes and tcp sockets would at least be portable, as options, but they didn't really work out
f
b
was it about using periods in usernames ? oh well, at least it is not spaces
f
Yes, that one is about periods. Spaces are actually broken even with the remapping of the username because we don't properly quote the mountpoints.
b
Nobody does. I guess most just "don't allow spaces", because of that
f
And yes, that is based on an actual user. Another one that doesn't work is a username like 
Tim O'Reilly
, and we had reports from that type too
b
I thought Mac enforced proper user names, but maybe that was before
f
That was on Windows, but even on macOS, sometimes user names come from a directory service, so are fixed by company policy. Some use email addresses
👍 1
b
Easy enough to get the form fields confused, when creating a new user
They fixed that here by changing everyones email instead. Slight overkill
f
I think local user creation is more strict, but if the name comes from Active Directory or whatever, they just accept whatever it contains.
b
Anyway, I guess "everything goes" when it comes to the host if you want it portable
At least that is what this experiment tought me, when username/uid/gid/homedir fails 😄
f
I guess we can make the regex configurable, but this will just result in more bug reports again because people think their distro supports more relaxed rules, and then one the utilities fails later on
b
I thought it would still work with the uid/gid, even if the user names were slightly mangled
but maybe this was the expectation that the path would be identical on both sides of the connection
f
Well, some commands, like 
useradd
, in some versions of Linux, will fail to create the user if it doesn't conform. In which case cloud-init will fail and the users will complain that ssh never gets ready... 😞
b
right. but I meant if you do change the username but leave the path creation
was the username in the VM important ? that was the piece missing for me
f
Yes, having the path the same on both sides was the assumption for making it look like 
nerdctl
runs on the host, when it actually doesn't
b
like I have /home/anders created in the VM, but the user lives in "anders.linux"
f
The username inside the VM is not important for Lima; that's why we fall back to a default. But the reporting user claims they have "scripts" that include the username
b
so I thought it could create /home/first.last, and then have a different $HOME
but if there are requrements on username, that won't work
f
Having the same paths is also important for volume mounts from the host into a container
b
Yeah, doubling down on the illusion
Calling these "bind mounts" irks me
f
For Rancher Desktop we actually have stub processes for both 
docker
and 
nerdctl
running on Win32 that will translate the filenames to the WSL2 form before talking to the sockets
b
There were some similar shenaningans on CoreOS for Podman Desktop, when 
/Users
was expected on a read-only file system
e.g. translating it under the hood from /Users to /mnt/Users - and then back again
I think they eventually just gave up on the whole idea, and remounted the disk R/W
2 Views
Open in Slack
PreviousNext
Powered by