Salt: git.latest says: I don't handle protocol '/root/https

[the-l-a-cat]

When I ask a state to clone me a git repository it fails with an error I can't make any sense of.

This is the relevant part of the output of state.highstate call:

          ID: zsh
    Function: git.latest
        Name: https://github.com/zsh-users/zsh-syntax-highlighting
      Result: False
     Comment: Cloning into '/usr/share/zsh/plugins/zsh-syntax-highlighting'...
              fatal: I don't handle protocol '/root/https'
     Changes:   

And there's the related fragment of sls.

 zsh:                                                                    
    pkg.installed:                                                      
        - name: zsh                                                     
    git.latest:                                                         
        - name: https://github.com/zsh-users/zsh-syntax-highlighting    
        - target: /usr/share/zsh/plugins/zsh-syntax-highlighting        

I found the error mentioned once in freenode salt channel logs but regretfully no solution was apparent there.

 # salt-call --versions-report
           Salt: 2014.1.10
         Python: 2.7.6 (default, Mar 22 2014, 22:59:56)
         Jinja2: 2.7.2
       M2Crypto: 0.21.1
 msgpack-python: 0.3.0
   msgpack-pure: Not Installed
       pycrypto: 2.6.1
         PyYAML: 3.10
          PyZMQ: 14.0.1
            ZMQ: 4.0.4
 # uname -a
 Linux host 3.13.0-24-generic #46-Ubuntu SMP Thu Apr 10 19:11:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

[the-l-a-cat]

It should be mentioned that minion in subject is located on the same host as is the master. I am not sure as to how the fact may happen to be relevant.

So far I can't reproduce that behaviour on other minions in the same installation: so far, everything behaves correctly.

[basepi]

Strange, I wonder if you have some sort of corruption going on. Does it work if you change it to git:// instead of https://?

[the-l-a-cat]

Yes, with git:// it works perfectly.

[basepi]

Hmmm, well at least we have a workaround. I wonder what's different for https? We'll have to see if we can reproduce this.

[notnarb]

Chiming in since I am finding this bug too.
I have one https github repo working fine:

dotfiles:                                          
  git.latest:                                      
    - name: https://github.com/notnarb/dotfiles.git
    - user: notnarb                                
    - group: notnarb                               
    - target: /home/notnarb/dotfiles               
    - require:                                     
        - user: notnarb                            
        - pkg: git                                 

But more recently I tried to add another repo for the same minion and got the same error as above

cask:
  git.latest:
    - name: https://github.com/cask/cask.git
    - user: notnarb
    - group: notnarb
    - target: /home/notnarb/cask
    - require:
        - user: notnarb
        - pkg: git
        - pkg: emacs24-nox
        - file: /home/notnarb/.emacs.d

----------
          ID: cask
    Function: git.latest
        Name: https://github.com/cask/cask.git
      Result: False
     Comment: Cloning into '/home/notnarb/cask '...
              fatal: I don't handle protocol '/home/notnarb/https'
     Started:
    Duration:
     Changes:
----------

Checked the salt minion logs and found

2015-01-27 00:00:31,211 [salt.state       ][ERROR   ] Cloning into '/home/notnarb/cask '...
fatal: I don't handle protocol '/home/notnarb/https'
2015-01-27 00:01:22,293 [salt.loaded.int.module.cmdmod][ERROR   ] Command 'git clone https://github.com/cask/cask.git /home/notnarb/cask  ' failed with return code: 128

Tried to run the command myself on the minion and sure enough:

notnarb@<minion>:~$ git clone https://github.com/cask/cask.git /home/notnarb/cask
Cloning into '/home/notnarb/cask'...
fatal: I don't handle protocol '/home/notnarb/https'

Looks to be a problem with git

notnarb@<minion>:~$ git --version
git version 2.1.4
notnarb@<minion>:~$ uname -a
Linux debian 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt2-1 (2014-12-08) x86_64 GNU/Linux
notnarb@<minion>:~$ salt-minion --version
salt-minion 2014.1.13 (Hydrogen)

@the-l-a-cat it looks like we're both running debian based distros, do you still have a machine with this bug to see what version of git you're running?

I restored a snapshot before salt was installed and installed git

Setting up git (1:2.1.4-2) ...
Setting up rsync (3.1.1-2+b1) ...
notnarb@<minion-snapshot>:~$ git clone https://github.com/cask/cask.git /home/notnarb/cask
Cloning into '/home/notnarb/cask'...
remote: Counting objects: 3225, done.
remote: Total 3225 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (3225/3225), 990.17 KiB | 367.00 KiB/s, done.
Resolving deltas: 100% (1808/1808), done.
Checking connectivity... done.
notnarb@<minion-snapshot>:~$ git --version
git version 2.1.4

and it works fine....

Restarted my current (salted) state. Same issue as before...

Heres the two different VM's side by side with the exact same command pasted from the same clipboard reporting different output.....
The one on the left is the base snapshot I took before installing salt -- now forked to have git installed through apt get.
The one on the right is the one managed by salt with git installed via:

git:            
  pkg.installed 

edit: whoops, accidentally posted early

One more thing: Checked the sha1sums of /usr/lib/git-core (secretly hoping I was a security mastermind and stumbled upon salt maliciously messing with binaries) and (regrettedly) found them to be the same

notnarb@<minion>:/usr/lib/git-core$ find -type f | xargs sha1sum | sha1sum
825917ea499117034cb99921874efd3932559ada  -

(don't quote me on that one liner actually working -- I do know the sums of the git binaries match)

The two VM states are less than a day apart so I really have no idea why they are behaving differently.

[notnarb]

It looks to me that there are situations in which salt will create a "https:" / "github.com" / "" folder structure (with https: being located where you tried to clone the repository to), and then git chokes upon finding the "https:" folder and gets confused. I don't have access to the system right now, but I'll see if I can make it reproducable when I do.

[basepi]

Awesome, thanks.

[thehunmonkgroup]

Ran into this issue as well, running 2014.7.2.
Since I only needed to initially install the repo as part of server setup, I tried this instead:

git-foo-repo:
  cmd.run:
    - name: /usr/bin/git clone ssh://{{ git_repository_website_host }}/var/local/git/foo.git --bare
    - unless: test -d /var/local/git/foo.git

That gave me the same error: fatal: I don't handle protocol '/root/ssh'
So I tried this slight variation, which ended up working:

git-foo-repo:
  cmd.run:
    - name: cd /var/local/git && /usr/bin/git clone ssh://{{ git_repository_website_host }}/var/local/git/foo.git --bare
    - unless: test -d /var/local/git/foo.git

Hope this helps the debugging effort.

[terminalmage]

After a little google-fu, this "I don't handle protocol..." message seems to happen when the remote URL is malformed. To those experiencing this, are you using the origin param, and if so, can you post the contents of git remote -v?

[terminalmage]

Actually, I misspoke, I did not mean the origin param, I meant the remote_name param.

[bfritz]

This is a git bug and I'm seeing it on Debian Jessie with git 2.1.4-2.1. A clone to target under /tmp fails if run from /root and succeeds if run from /tmp.

$ sudo -s
# cd /root
# git clone https://github.com/pyr/cyanite.git /tmp/cyanite
Cloning into '/tmp/cyanite'...
fatal: I don't handle protocol '/root/https'


# cd /tmp
# git clone https://github.com/pyr/cyanite.git /tmp/cyanite
Cloning into '/tmp/cyanite'...
[..]
Receiving objects: 100% (1442/1442), 955.64 KiB | 1.08 MiB/s, done.

The clone fails because git incorrectly writes the repository URL to .git/config before the clone. A snippet from strace:

open("/tmp/cyanite/.git/config.lock", O_RDWR|O_CREAT|O_EXCL, 0666) = 3
[..]
write(3, "[core]\n\trepositoryformatversion "..., 92) = 92
write(3, "[remote \"origin\"]\n", 18)   = 18
write(3, "\turl = /root/https://github.com/"..., 48) = 48   <-- INCORRECT "/root/" PREFIX
[..]
rename("/tmp/cyanite/.git/config.lock", "/tmp/cyanite/.git/config") = 0

Still looking for a reasonable workaround.

[terminalmage]

@bfritz I was able to work around it in Salt by executing the git clone from /tmp instead of not specifying the cwd and letting it fall back to the home directory (/root for the root user, of course). This fix (along with over a dozen others) will be part of a rewrite of the git state and execution module in 2015.8.0.

See here for the fix: https://github.com/saltstack/salt/pull/26521

Thanks very much for the investigative work on this, you're awesome!