Remote OS Support: FreeBSD

[amitds1997]

Remote OS Support: FreeBSD

[bgshacklett]

Quick update: I finally got back to this and I found that running under a non-root user with Neovim pre-installed from source is working! So, the scope of this request has been solved, for sure, even if there are some optimizations which could still be made.

Thanks again for working on this so quickly (and sorry it took me so long to get back to you!)

[amitds1997]

I have pushed changes to the feat/support-freebsd branch. And was able to get it up and running (given that Linux Binary compatibility was enabled and any suitable userland is installed). Let me know your thoughts. If it works, I'll do some clean up and send it out.

[bgshacklett]

Thank you for looking at this so quickly! I'm running into a bit of difficulty (perhaps related to Linux Binary compatibility? I'll look into this more):

FAILED JOB OUTPUT (SO FAR)
sh: /home/bshacklett/.remote-nvim/.remote-nvim/.remote-nvim/.remote-nvim/.remote-nvim/nvim-downloads/stable/bin/nvim: not found
ERROR Fri Jan 12 16:53:07 2024 /Users/bgshacklett/.local/Cellar/neovim/HEAD-677e02b/share/nvim/plugged/remote-nvim.nvim/lua/remote-nvim/providers/provider.lua:602: 'Install Neovim if not exists' failed.
stack traceback:
	.../remote-nvim.nvim/lua/remote-nvim/providers/provider.lua:603: in function '_handle_job_completion'
	.../remote-nvim.nvim/lua/remote-nvim/providers/provider.lua:623: in function 'run_command'
	.../remote-nvim.nvim/lua/remote-nvim/providers/provider.lua:374: in function '_setup_remote'
	.../remote-nvim.nvim/lua/remote-nvim/providers/provider.lua:546: in function <.../remote-nvim.nvim/lua/remote-nvim/providers/provider.lua:543>
	[C]: in function 'pcall'
	.../remote-nvim.nvim/lua/remote-nvim/providers/provider.lua:441: in function <.../remote-nvim.nvim/lua/remote-nvim/providers/provider.lua:440> 

FAILED JOB OUTPUT (SO FAR)
Downloading Neovim for Linux (AppImage)...
Extracting Neovim binary...
/home/bshacklett/.remote-nvim/.remote-nvim/.remote-nvim/.remote-nvim/.remote-nvim/scripts/neovim_install.sh: line 61: /tmp/tmp.eyUwxgJ4/nvim.appimage: cannot execute binary file: Exec format error

[amitds1997]

I did some more digging. I think one better way to install is to just build it from source. The build requirements seem to be something that should be available on most FreeBSD systems. This allows us to remove dependency on Linux compatibility layer.

[amitds1997]

Sorry for the confusion as I was traversing methods to support FreeBSD. As of now, there are 3 ways we can get this:

1. Install using appimage
   • Setup required: Linux Binary Compatibility Layer must be enabled
   • Advantages:
     1. Only a single binary needs to be downloaded
     2. We can support different versions
   • Disadvantage: Enabling system Compatibility layer just for a single app is too much to ask for
2. Install from source
   • Setup required: All build-prerequisites should be installed
   • Advantages:
     1. No dependency on Linux Binary Compatibility layer
     2. We can support different versions
   • Disadvantage: All build prerequisites would have to be installed first which is a bit of hassle
3. Use system neovim
   • Setup required: None
   • Advantages:
     1. No action needed. Plugin can manage everything
   • Disadvantage:
     1. No version support

With the feat/support-freebsd, you have support for 1 currently. I have yet to add support for 2 and 3. But 2 and 3 sound better to me than 1 because the actions to take are that much clear. Let me know if you have any thoughts on these or what would be the preferred workflow for FreeBSD users since I have not worked with FreeBSD systems before.

[amitds1997]

Sorry for the confusion as I was traversing methods to support FreeBSD. As of now, there are 3 ways we can get this:

1. Install using appimage
   
   * Setup required: Linux Binary Compatibility Layer must be enabled
   * Advantages:
     
     1. Only a single binary needs to be downloaded
     2. We can support different versions
   * Disadvantage: Enabling system Compatibility layer just for a single app is too much to ask for

2. Install from source
   
   * Setup required: All [build-prerequisites](https://github.com/neovim/neovim/blob/master/BUILD.md#freebsd) should be installed
   * Advantages:
     
     1. No dependency on Linux Binary Compatibility layer
     2. We can support different versions
   * Disadvantage: All build prerequisites would have to be installed first which is a bit of hassle

3. Use system neovim
   
   * Setup required: None
   * Advantages:
     
     1. No action needed. Plugin can manage everything
   * Disadvantage:
     
     1. No version support

With the feat/support-freebsd, you have support for 1 currently. I have yet to add support for 2 and 3. But 2 and 3 sound better to me than 1 because the actions to take are that much clear. Let me know if you have any thoughts on these or what would be the preferred workflow for FreeBSD users since I have not worked with FreeBSD systems before.

@bgshacklett Could you try the branch again. I have integrated 2 and 3. Please clean up the existing configuration using the :RemoteCleanup <host-id> command. Now, it should allow you to choose b/w downloading appimage, using system Neovim and building from source. Let me know if you face any problems.

If you choose to build by source, do note that it would take some time and you would have a single notification saying "Installing Neovim" for a long time without any other information. I'm working on adding a better UI for that.

[amitds1997]

It seems we are almost there 🤘🏼 Regarding server not coming up, the plugin depends upon the `nvim` binary locally to run an `echo` command. Can you please confirm that the binary with that name is present on your local. https://github.com/amitds1997/remote-nvim.nvim/blob/feat%2Fsupport-freebsd/lua%2Fremote-nvim%2Fproviders%2Fprovider.lua#L493 Also, when you see the error, do you see an active session when you run `: RemoteSessionInfo`? If you do, simply re-running `:RemoteStart` and selecting the server from already configured workspaces should connect you with the server. Regarding the one-time freeze up, it usually happens when you copy your configuration and your package manager gets initialized (vim.fn.system git clone call). It is usually a blocking call and the Nvim server is not able to respond to the call since it is single threaded. I'll try looking into the other error that you mentioned. Thanks for testing things out at your end. Really appreciate it!

…

On Mon, Jan 15, 2024, 9:04 PM Brian G. Shacklett ***@***.***> wrote: First try, building Neovim from source failed with some dependency issues. I ended up having to install gmake, cmake, git, and gettext. It finally finished and I was prompted to copy my config and start the local client. At that point, things seemed to freeze up and I got this error: Error executing luv callback: .../remote-nvim.nvim/lua/remote-nvim/providers/provider.lua:526: Server did not come up on loc al in 20000 ms. Try again :( stack traceback: [C]: in function 'error' .../remote-nvim.nvim/lua/remote-nvim/providers/provider.lua:526: in function <.../remo te-nvim.nvim/lua/remote-nvim/providers/provider.lua:518> [C]: in function 'resume' ...ged/remote-nvim.nvim/lua/remote-nvim/providers/utils.lua:31: in function 'on_choice ' ...ar/neovim/HEAD-677e02b/share/nvim/runtime/lua/vim/ui.lua:54: in function 'select' ...ged/remote-nvim.nvim/lua/remote-nvim/providers/utils.lua:27: in function <...ged/re mote-nvim.nvim/lua/remote-nvim/providers/utils.lua:26> Afterwards, Nvim became largely unresponsive, but this only happened once. I also see this error in the logs: ERROR Mon Jan 15 10:11:49 2024 /Users/bgshacklett/.local/Cellar/neovim/HEAD-677e02b/share/nvim/plugged/remote-nvim.nvim/lua/remote-nvim/providers/provider.lua:480: .../remote-nvim.nvim/lua/remote-nvim/providers/provider.lua:505: handle 0x600003e980a0 is already closing I'll try wiping everything out and using a system-installed Nvim next. P.S.: Running gnu-watch -d -n1 ps aux on the remote machine worked relatively well to get a rough idea of the progress, but requires installing an additional package. — Reply to this email directly, view it on GitHub <#70 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AG7ZNGY3YPMFEMXTIH6BBQDYOVEALAVCNFSM6AAAAABBYHMZVGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJSGM4TCNBXGI> . You are receiving this because you commented.Message ID: ***@***.***>

[bgshacklett]

Local machine:

zsh ❯ which nvim
/Users/bgshacklett/.local/bin/nvim

[amitds1997]

Thanks for creating this! I have never worked with FreeBSD, and Neovim does not publish a binary that can be run directly on FreeBSD.

I did some preliminary analysis in a FreeBSD VM (FreeBSD 14.0) and it seems after enabling the Linux compatibility layer, Neovim Linux appimage works great.

More specifically, I ran these commands from the manual (https://docs.freebsd.org/en/books/handbook/linuxemu/):

sysrc linux_enable="YES"
service linux start
pkg install linux_base-c7

Would this be an acceptable solution? Ideally, if there was a direct binary available, that would have been great but that is not the case right now. Let me know your thoughts and I can push change if this is an acceptable compromise (this would require the minimum set of changes). Another option can be to fallback to the system level Neovim installation but that would take some development time to implement.

[amitds1997]

Once you are able to run ./nvim.appimage --appimage-extract, rest of the process should work.

Side note: The nested .remote-nvim folder looks scary. Was that something you manually did or did it happen automatically? If it happened automatically (I had a look at code and it should not), I have one more bug to squash 🐛

[bgshacklett]

So if Neovim is already installed on the remote system, it should just use the existing package?

[bgshacklett]

First try, building Neovim from source failed with some dependency issues. I ended up having to install gmake, cmake, git, and gettext. It finally finished and I was prompted to copy my config and start the local client. At that point, things seemed to freeze up and I got this error:

Error executing luv callback:
.../remote-nvim.nvim/lua/remote-nvim/providers/provider.lua:526: Server did not come up on loc
al in 20000 ms. Try again :(
stack traceback:
        [C]: in function 'error'
        .../remote-nvim.nvim/lua/remote-nvim/providers/provider.lua:526: in function <.../remo
te-nvim.nvim/lua/remote-nvim/providers/provider.lua:518>
        [C]: in function 'resume'
        ...ged/remote-nvim.nvim/lua/remote-nvim/providers/utils.lua:31: in function 'on_choice
'
        ...ar/neovim/HEAD-677e02b/share/nvim/runtime/lua/vim/ui.lua:54: in function 'select'
        ...ged/remote-nvim.nvim/lua/remote-nvim/providers/utils.lua:27: in function <...ged/re
mote-nvim.nvim/lua/remote-nvim/providers/utils.lua:26>

Afterwards, Nvim became largely unresponsive, but this only happened once.

I also see this error in the logs:

ERROR Mon Jan 15 10:11:49 2024 /Users/bgshacklett/.local/Cellar/neovim/HEAD-677e02b/share/nvim/plugged/remote-nvim.nvim/lua/remote-nvim/providers/provider.lua:480: .../remote-nvim.nvim/lua/remote-nvim/providers/provider.lua:505: handle 0x600003e980a0 is already closing

I'll try wiping everything out and using a system-installed Nvim next.

P.S.: Running gnu-watch -d -n1 ps aux on the remote machine worked relatively well to get a rough idea of the progress, but requires installing an additional package.

Edit:
It looks like there is no built-in package for Neovim in OPNSense, so I'll need to do a little digging before I can test the "use system nvim" scenario.

[amitds1997]

Local machine:

zsh ❯ which nvim
/Users/bgshacklett/.local/bin/nvim

Updated the comment above with some additional details. If you try running RemoteStart again, you should be able to connect to remote.

The first error could have been because the server had frozen up git cloning the package manager and it did not respond in 20s.

[bgshacklett]

Running RemoteStart again worked once, but is timing out in most cases. The case where it did work, it took almost the full 20 seconds to connect. It seems like the second error I mentioned is getting thrown in the :RemoteLog output every time it fails.

[bgshacklett]

Note: IPv6 is in the mix here. I don't see why it would matter, given that the connection is being made, but wanted to mention it just in case it's relevant.

[amitds1997]

Hmm, thanks for that piece of info. Could you provide sample SSH config so that I can try to emulate it at my end?

[bgshacklett]

I don't really do much with my SSH config. I force v4 for bitbucket:

Host bitbucket.org
    AddressFamily inet
		HostName bitbucket.org

...and I have colima running, which adds the following:

Host colima
  IdentityFile "/Users/bgshacklett/.lima/_config/user"
  IdentityFile "/Users/bgshacklett/.ssh/id_ed25519"
  IdentityFile "/Users/bgshacklett/.ssh/id_rsa"
  IdentityFile "/Users/bgshacklett/.ssh/tnc-ed25519"
  StrictHostKeyChecking no
  UserKnownHostsFile /dev/null
  NoHostAuthenticationForLocalhost yes
  GSSAPIAuthentication no
  PreferredAuthentications publickey
  Compression no
  BatchMode yes
  IdentitiesOnly yes
  Ciphers "^[email protected],[email protected]"
  User bgshacklett
  ControlMaster auto
  ControlPath "/Users/bgshacklett/.lima/colima/ssh.sock"
  ControlPersist 5m
  Hostname 127.0.0.1
  Port 49293

I'll try to dive into the code a bit when I have a moment to see if I can add some debug statements or otherwise get more information about what I'm seeing. It certainly seems like something to do with my environment, so I may not be the best test case for this particular ticket. If you're feeling comfortable that it's working for a generic BSD endpoint, it might make sense to split off a separate issue for my particular experiences.