https://rancher.com/ logo
Join Slack
Powered by
This message was deleted.
# rancher-desktop
a
This message was deleted.
f
It is possible to override the MAC address of the bridged interface using an 
override.yaml
file, but I doubt it will do you any good. The IP address is assigned by the DHCP server on your local network, so if you have some mechanism to set the IP address based on MAC address, you could try using the current MAC address of the bridged network. The algorithm should keep the MAC address stable across restarts / reinstalls, as long as the directory names don't change.
I'm confused by what you mean by "internal" network. Is this the shared network inside your machine, or the network the bridged interface connects to?
i
I do have the ability to control IP via MAC with DHCP, so that shouldn't be a problem. Can you provide more details on the comment regarding directory names? I want to make sure I understand it before I dive down any rabbit holes.
Simply put, my LAN uses the 10.x.x.x IP Range. My Corporate VPN is forwarding 10.x across it.
It may be better if I can simply disabled the bridged network in lima and use local, but wasn't sure that was possible either.
f
"local" would mean "shared"? That is a NATed network inside the host, so not accessible externally
Networking looks like this (but only one VM):
I have to leave now; will be back in about 30min or so, sorry!
i
Take your time. I'm just grateful for the help.
And yes, I believe shared is what I'm looking to configure. It appears by default it's already using bridged.
f
I'm sorry, this took a lot longer than expected, and now I'm in a meeting for another hour...
i
lol no need to apologize, I am certainly familiar with that scenario. I've enough work-arounds that I'm able to run for right now.
f
Ok, I think I'm done for now with meetings and errands...
The MAC address of your bridged interface (
rd0
inside the VM) should not change, it is calculated from a checksum of the machine id and the path to the Lima instance directory.
So unless you e.g. change your username, the checksum should be fixed. It is designed that MAC addresses are unique (include the machine id), but are "predictable" by using the location for the 
lima.yaml
config file (and an index for the interface, so 
rd0
and 
rd1
have different addresses)
I've looked into disabling the bridged interface, but it would be very hacky: you could create an 
override.yaml
file and specify that 
rd0
is also using the 
rancher-desktop-shared
network.
If you don't need a routable IP address for the VM, then you could simply disable administrative access. It gets rid of the prompt for the 
sudo
password, and will not configure 
rd0
and 
rd1
, you only get port forwarding to the host via 
localhost
. So maybe that is another solution for you.
Or you could configure your DHCP with the MAC address of the bridged interface to hand out the IP address you want, if you need the network to be routable.
i
I'm not too worried about the network being routable, so I may try using non admin mode. My only concern with it is I am seeing an issue where kubectl commands on the localhost seemingly fail. If I wait a bit, it'll return and everything will be fine. I'm not quite sure what's going on there, but I suspect it may still be related to the VPN.
f
The other thing to watch out for is if you are using the moby engine: RD will not be able to create 
/var/run/docker.sock
without admin rights, so you have to make sure to 
docker context use rancher-desktop
. I think RD will set this up automatically, but might not if the default context also seems to be working.
On the plus side, you are not being prompted for the sudo password after each reboot (because macOS clears 
/var/run
on boot).
Anyways, let me know if this works for you, or if you have further questions
i
oO Now that's an interesting comment...would not using the 
rancher-desktop
context cause issues, even while using sudo? I've been trying to use 
docker buildx
lately, so it makes me wonder if it's related...
Well that may not matter. I'm not sure if the context buildx uses is different from the normal docker context.
(And yes, I am using Moby)
f
idk, but I think it should use the configured context
i
Okay, Thank You. I've several different options here so I will have to figure out which one I want to ultimately go with.
171 Views
Open in Slack
PreviousNext
Powered by