connecting from another laptop

[pwright]

trying to connect to a running crc using https://github.com/code-ready/crc/blob/master/docs/source/topics/proc_connecting-to-remote-instance.adoc

However, my 'client' is using Fedora 33 and I wonder if my problems are related to using dnsmasq and the default F33 setting described in

https://fedoramagazine.org/systemd-resolved-introduction-to-split-dns/

Are there ways to verify the proxy and dns config on both sides?

[pwright]

followed the instructions in https://gist.github.com/zoilomora/f7d264cefbb589f3f1b1fc2cea2c844c and everything 'just worked', so maybe docs just need to be updated for F33?

[cfergeau]

Ah yeah, this part of the documentation is not good for f33. However, rather than disabling systemd-resolved altogether, you could use resolvectl dns to append your remote server as a DNS server to your default network interface? (though I am a bit confused by 'using dnsmasq and the default f33 settings' used in the same sentence, for me dnsmasq and systemd-resolved as used by f33 are mutually exclusive)

[pwright]

thanks for the quick reply @cfergeau
TBH, this stuff is all new to me, I was hoping to 'just follow the docs'... but now that I'm here, I suppose there's no harm in learning new things ;)

I see there's an option to use both together at https://unix.stackexchange.com/questions/304050/how-to-avoid-conflicts-between-dnsmasq-and-systemd-resolved
and https://itectec.com/ubuntu/ubuntu-how-to-add-dnsmasq-and-keep-systemd-resolved-18-04/

One thing I can report is that I tried F32 laptop as a client and ran into the same issues, resolved again using the gist from above.

[praveenkumar]

We do need to update the client documents from fedora-33, I am surprised to know that it doesn't work with f-32, @pwright can you provide some details about that f-32 system?

[pwright]

@praveenkumar what do you wanna know? it might be an edge case, given that I had run crc/minikube/docker on it previously and that might have messed up networking in some way. Just mentioning it in case it's a procedure that hasn't been tested for a few releases.

[kowen-rh]

The procedure was tested using a Fedora 32 client with both a Fedora 32 server and a RHEL 8 server. At the time, this procedure worked well for all of these configurations. All of these operating systems, for both the client and the server, were fresh installations, though.

I understand that we need to update the client documentation for Fedora 33, but I'm not certain what, exactly, needs to be changed at this point in order to verify that the steps will work as intended.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[jotak]

I had the same issue. I've been able to make it work quite easily, keeping using systemd-resolved.
Since I already had CRC installed at some point on my client laptop, I already had the file /etc/NetworkManager/dispatcher.d/99-crc.sh created. What I did was just to change the IP of crc to my server IP in that file:

export LC_ALL=C

resolvectl domain crc ~testing
resolvectl dns crc 192.168.1.95
resolvectl default-route crc false

exit 0

(edit: it seems like this config has actually no impact here, since we're not using a "crc" interface)

And in my /etc/hosts:

192.168.1.95 testing api.crc.testing oauth-openshift.apps-crc.testing apps-crc.testing console-openshift-console.apps-crc.testing

where 192.168.1.95 is my server IP.

I don't really know how systemd-resolved works, so not sure if just this config is sufficient, or if there's more that I didn't see because I had crc installed previously.

[cfergeau]

I don't really know how systemd-resolved works, so not sure if just this config is sufficient, or if there's more that I didn't see because I had crc installed previously.

This should be enough.

[guillaumerose]

Is it still an issue ?