Clarifying wording in installation readme about evap

[richardebeling]

Ah, that may be the problem I reported with git for windows here: https://www.github.com/git-for-windows/git/issues/4705

For me, vagrant creates its private SSH keys with CRLF line endings, but the SSH executable that comes with git for windows only accepts LF line endings.

When you have Git Bash open inside the cloned EvaP folder, I'd expect

ssh [email protected] -p 2222 -i .vagrant/machines/default/virtualbox/private_key

(i. e. open an SSH connection to the local computer, at port 2222, and use the private key file that vagrant created)
to print

Load key ".vagrant/machines/default/virtualbox/private_key": error in libcrypto
[email protected]: Permission denied (publickey).

You could convert the line endings of the private key using dos2unix, then it should work:

dos2unix .vagrant/machines/default/virtualbox/private_key
vagrant ssh  # now works (hopefully)

In #2079, we're currently planning on adding to the readme that we do not recommend using Git Bash because SSH behaves weirdly in there.

[niklasmohrin]

Hi! I am not sure I understand the motivation for your suggested change. After changing the setting in Git bash, you should be able to (and are supposed to) continue entering the next commands in this Git bash. Can you describe a particular problem that occurred in your setup?

---

The term "command line" is actually somewhat generic here - these commands should work from any of the standard methods to operate your computer by entering text commands (Windows cmd, Windows Powershell, Windows Git bash, Macos Terminal, any terminal on Linux, even in a non-graphical Linux session). Since the readme should actually cover all of these platforms, changing the wording to something like "windows command prompt" is a definite no-go and I don't see why we would emphasize that the windows program in particular is called "command prompt".

If there is anything tricky that we could add as a hint for a specific platform, we could think about that. However, I feel that if the only hurdle is having to understand what it means to "run a command on the command line", then my gut feeling would be that we leave this for the reader to figure out - they will have to understand it anyways once they start to work in the development VM.

[richardebeling]

We tried the setup procedure from the readme using Git Bash on Windows on two machines today. On one of the machines, we encountered an issue where the vagrant ssh command would not correctly give an interactive pseudo-terminal with a command prompt, i.e., (venv) evap@ubuntu-jammy:/evap $ would not appear and it thus looks like the execution hangs:

user@machine MINGW64 ~/Desktop/EvaP (main)
$ vagrant ssh
Welcome to Ubuntu 22.04.3 LTS (GNU/Linux 5.15.0-87-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/advantage

  System information as of Mon Nov 20 23:22:15 UTC 2023

  System load:  0.0810546875       Processes:               124
  Usage of /:   10.6% of 38.70GB   Users logged in:         0
  Memory usage: 20%                IPv4 address for enp0s3: 10.0.2.15
  Swap usage:   0%


Expanded Security Maintenance for Applications is not enabled.

23 updates can be applied immediately.
16 of these updates are standard security updates.
To see these additional updates run: apt list --upgradable

Enable ESM Apps to receive additional future security updates.
See https://ubuntu.com/esm or run: sudo pro status



The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.

(seems to hang here as no more output is produced)

You can enter commands there (such as ./manage.py run), but the initialization from .bashrc didn't run correctly, so they result in errors.

This issue is unrelated to our specific setup and seems to be more of a windows-ssh-executable-in-git-bash issue as discussed here: hashicorp/vagrant#9143 (comment). I'll make a PR adding the mentioned workaround for that to our Vagrantfile.

@CurtisHolick is this also the issue you encountered? Above, you said that you were

unable to get the next steps of starting vagrant and, SSHing, and running the manage.py file

which implies to me that there was an issue before. In this case, we'd need a more detailed error description as we can not reproduce this. As @niklasmohrin said, the commands from our readme are intended to work inside Git Bash on Windows.

[CurtisHolick]

Hello,
The issue I have when I try to use git bash instead of cmd to do this seems to be slightly different on my end. After running vagrant up, when I enter vagrant ssh I get the error [email protected]: Permission denied (publickey). The same commands work fine for me through command, I hope this context helps. I am running a fairly fresh windows 10 install, with an amd processor if that makes a difference as well.

[richardebeling]

Closing for now as #2079 is merged. Feel free to comment/reopen if your issue was something else than the CRLF problem.