Using pijul on a private server

Question
1

Hi there.

I am currently trying to setup a private repo on my server. It almost works, I can select the patches I want to push for instance. The issue is, once I do it, pijul exits gracefully but nothing had happened server-side and if I push again, I am asked to push the exact same patches.

Any idea on how to solve this issue? Have pijul been tested with openssh?

The only thing I see that differs from a push to the nest, with RUST_LOG=info, is:

INFO:thrussh::client::encrypted: Unhandled global request: Ok("hostkeys-00@openssh.com")
1 Like
2

This is a standard message sent by openssh, nothing to worry about. Unfortunately, we don’t have tests for that, but we should, even if they fail if you don’t have an SSH server running locally.

Pushing fails on my machine with a “file not found” error, I wonder what causes this.

3

I tried to read the code of thrussh and my understanding is that it closes the session when it receives a global request it does not know about.

Being able to use pijul with openssh as the server would be great, IMO, but I have no idea how hard it could be.

4

Okay, so now I am in a situation where I can pull but not push. Any idea?

5

I can’t reproduce, but I had to tweak my configuration a little before getting it to work. The main thing was a problem with my path when calling commands over SSH, which was pointing to an old version of Pijul installed by Nix, instead of the one installed by Cargo.

6

I may have a lead. Here is what I can see in my logs

DEBUG:pijul::commands::remote: pushable: {Sha512(zlCWdpMkWb7AlnPqe-7lRQAsMdJmWUd_NKYpNfFuIrD2vf8Q_2zKp9QOZMs6ew2Hc55ZOK-Bb-i5SshcZa4Xcg)}
...
TRACE:libpijul::backend::hash: write_value Sha512(0x7ffb4b465497) 0x7ffb4b4252d0

The hash looks strange, but it’s probably completely legit?

7

That’s not really helpful. The trace is totally normal, and the other command just means it has a patch to push.

What does ssh lthms@remote "which pijul" give you? Are you sure your remote pijul has the latest patches?

Another useful info would be to know whether the remote repository received the patch, i.e. if the remote .pijul/patches contains your patch.

1 Like
8

Thanks a lot. I finally managed to make the thing works. The issue was almost the same you described. When I was logged in my server, which pijul was returning the correct path (/usr/local/bin/pijul). However, with the command you gave me, it was actually returning /usr/bin/pijul… This version was certainly very old (probably 0.5, actually).

When I deleted this old version, it still didn’t worked. Indeed, when doing the ssh "which pijul", it was reporting that pijul was not found… expect pijul itself was complaining on the client side.

Now it works, because I put an up-to-date version of pijul in the correct location.

There is probably a room for improvement here on error reporting.

9

Okay, so it looks like it does not work anymore. I suspect it can be related to the recent changes in pijul/src/commands/remote.rs, even though I cannot be sure.

Basically, the pull command works, but the push doesn’t.

1 Like