Caleb's questions

I'm trying to setup gitlab (6.5.1) on a fresh clean server. Everything appears to work, but git is unable to push to any project. Following the commands from the newly created project page and pushing to the remote via ssh gives:

$ git push -u origin master
fatal: Could not read from remote repository.

Please make sure you have the correct access
rights and the repository exists.

This seems to be a fairly common problem. Unfortunately it seems to have a number of potential causes and none of them seem to match. From issue 3424 on an old release and various other sources online I've seen and checked the following suggestions:

• Leftover ssh keys

  This is a clean setup with no leftovers. My key got added to the authorized keys file properly and is the only one listed.

• Running ssh with debug logging shows errors related to Ruby environment vars.

  Mine comes up clean. SSH debug shows a successful connection. Everything about the authentication handshaking is normal, then this is the end of the output:

  debug1: Sending command: git-receive-pack 'username/reponame.git'
  debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
  debug1: client_input_channel_req: channel 0 rtype [email protected] reply 0
  debug1: channel 0: free: client-session, nchannels 1
  debug1: fd 0 clearing O_NONBLOCK
  debug1: fd 1 clearing O_NONBLOCK
  

• Problems with the gitlab-shell environment.

  Unlike many others with the same error message above, my gitlab-shell check script returns a clean bill of health:

  % sudo -u gitlab -H ~gitlab/gitlab-shell/bin/check   
  Check GitLab API access: OK
  Check directories and files: 
          /var/lib/gitlab/repositories: OK
          /var/lib/gitlab/.ssh/authorized_keys: OK
  Test redis-cli executable: redis-cli 2.8.5
  Send ping to redis server: PONG
  

• Restart {unicorn,sidekiq,redis}

  The reports that restarting one or more services clears this up don't seem to apply here. This isn't an intermittent problem that releading a daemon fixes.

• The repo isn't getting physically created

  But it is. The first time every time, the bare git repo in ~gitlab/repositories/username/reponame.git gets created every time and seems to have the correct permissions.

• Gitlab-shell can't talk to the API server because A) DNS problems, B) wrong ip/port/interface binding C) not having/having a trailing slash.

  The check script says the API access is fine.

  I'm not running nginx, so the default ip binding issue related to that is n/a.

  I've tried both *:8080 and 127.0.0.1:8080 for the listen value in unicorn.yml.

  Beyond that, I have tried various iterations of localhost, 127.0.0.1 and the fully qualified domain name (which is DNS resolving fine) with and without trailing slashes in shell.yml to no avail. I have also tried wiring this directly to the unicorn server on port 8080 instead of the Apache SSL / proxy host on port 80. Nothing seems to make any difference. My certificate is not self signed and are working fine for browsers, but I tried setting self_signed_cert: true anyway. Nothing.

• The reported git paths are wrong, add fully qualified path from gitlab user home.

  This seems like a legit suggestion if the gitlab-shell isn't doing some monkey business to correct this already, but I tried changing git remote add origin gitlab@server:username/reponame.git to ``git remote add origin gitlab@server:repositories/username/reponame.git` to no avail. Same error.

This seems to be the litany of solutions suggested, but none of them seem right. Note I am able to push over http. The login prompt accepts my ldap username and password and accepts a push. This is only a problem trying to use SSH. Testing just the ssh login part with ssh -T gitlab@server works fine.

What else could be causing this error?

How does one go about debugging such an issue in gitlab? There does not seem to be anything relevant at all in ~gitlab/gitlab-shell/gitlab-shell.log. Where would a more informative error message be found?

I'm trying to configure a new installation of OpenLDAP (2.6.39) on Arch Linux. I've used the default core packages to install and configure it, however I cannot get it to obey any access control declarations in the settings file.

My /etc/openldap/slapd.conf has just these two declarations that I got from the docs:

access to attr=userPassword
    by self =xw
    by anonymous auth
    by * none

access to *
    by self write
    by users read
    by * none

I've started the service normally and most things seem to work. I can login using pam/nslcd and use phpldapadmin. However the above access restrictions do not seem to be working. From phpldapadmin I was able to see and change the password field for users other that the uid I connected with. The same happens using the command line client (output cropped):

$ ldapsearch -D 'uid=user2,ou=People,dc=example,dc=com' -w 1234 '(uid=user1)'
userPassword:: e1NTSEF9VEZ4K2U1M0JtUEU0NkljdlBPaTBycE41RTh2aXJNeTg=

As you can see I am authenticating using user2 but am able to query the entry for user1 and see the password field.

Other declarations in slapd.conf are clearly in effect, so I'm not editing the wrong file or something like that. I've tried setting draconian rules like access to * by * none as the only rule but am still able to see anything in the directory from any user. I'm placing the access lines at the place in the default configuration where the sample ones were.

How do I make OpenLDAP actually heed the acl's in its config file istead of ignoring them?

Over on EC2 I am trying to setup AMI's for PLD-Linux that use the new features that allow running custom kernels from inside the AMI using PV-Grub. I've setup custom AMI's many times before but can't get the kernel thing to go.

Basically I have a ebs disk with a grub menu file and custom xenU kernel on it. Registering this and launching it as an instance starts pv-grub from the xen host and pv-grub finds my menu file and tries to boot the config found there. However no matter how I configure the grub menu items or the disc partitions, grub always throws error "Error 21: Selected disk does not exist".

I have tried many permutation of the following:

• Raw volume as disk with filesystem
• 1 partition on volume with filesystem in that
• hd0 and hd00 AKI's (hd0 finds the menu file for the raw disk version, hd00 for the one partition version)
• using no root command from the grub menu
• using root(hd0)
• using root(hd0,0)
• using various rootnoverify()'s

I am using ext3 in all cases. I have no system/device map files to get in the way. Any incorrect combination of partition layout and hd0/hd00 AKI's does lead to a different error, but if I use the right one and it finds the menu file, it invariably throws the error above.

What am I missing?

(Cross posted from EC2 Forum because no answer there, I will take care of making sure the solution is also cross posted)