Return to Revisions

This is a follow-up to the answer from wutzebaer.

The Cardano team has since patched the repository to address the issue. They did not however, revert the problem file to it's previous working state. Instead they re-introduced the file using a different method and with different contents. Namely, the new nsswitch.conf file only contains hosts: dns file

Apparently, this seems to have solved the problem for many but there are still some cases where it is failing.

The workaround that wutzebaer posted still works, but I have a few improvements:

i. The nsswitch.conf file only needs to contain.

hosts: file dns 

note the order is file dns, not dns file

The reordering of these properties is the new fix that needs to be made officially.

ii. The nsswitch.conf file should be stored in the project where it can be committed to the repository, not in the user's home directory. In this way, the project remains self-contained and not dependent on any user-specific environment.

The new instructions:

1. create <project folder>/.devcontainer/nsswitch.conf with the contents:

hosts: file dns

2. Update the devcontainer.json to mount the nsswitch.conf in the container.

{
    "name": "Plutus Starter Project",
    "image": "docker.io/inputoutput/plutus-starter-devcontainer:v1.0.10",

    "remoteUser": "plutus",

    "mounts": [
        // This shares cabal's remote repository state with the host. We don't mount the whole of '.cabal', because
        // 1. '.cabal/config' contains absolute paths that will only make sense on the host, and
        // 2. '.cabal/store' is not necessarily portable to different version of cabal etc.
        "source=${localEnv:HOME}${localEnv:USERPROFILE}/.cabal/packages,target=/home/plutus/.cabal/packages,type=bind,consistency=cached",
        "source=${localWorkspaceFolder}/.devcontainer/nsswitch.conf,target=/etc/nsswitch.conf,type=bind,consistency=cached",
    ],

    "settings": {
        // Note: don't change from bash so it runs .bashrc
        "terminal.integrated.shell.linux": "/bin/bash"
    },
    
    // IDs of extensions inside container
    "extensions": [
        "haskell.haskell"
    ],
}

For bonus points, note that I have also modified the other mount configuration "source=${localEnv:HOME}${localEnv:USERPROFILE}/.cabal/packages,target=/home/plutus/.cabal/packages,type=bind,consistency=cached"

changing source=${localEnv:HOME}/.cabal/packages

to source=${localEnv:HOME}${localEnv:USERPROFILE}/.cabal/packages

This is because the HOME environment variable is not a standard variable in windows although many people may have it defined due to various (often 'nix-like) software installs. Microsoft's recommendation is to pair ${localEnv:HOME}${localEnv:USERPROFILE} since HOME is only valid for linux and USERPROFILE is only valid for windows.

In my case, the HOME variable is not defined, so spinning up the container would give me mount errors because it was looking for /.cabal/packages instead of C:\Users\FuzzyLogic/.cabal/packages