Я намагаюся налаштувати gitlab (6.5.1) на свіжий чистий сервер. Здається, все працює, але git не в змозі підштовхнути жоден проект. Слідом за командами зі сторінки новоствореного проекту та натисканням на віддалений через ssh дає:
$ 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.
Це здається досить поширеною проблемою. На жаль, мабуть, існує ряд потенційних причин, і жодна з них, схоже, не відповідає. З випуску 3424 на старій версії та різних інших джерелах в Інтернеті я бачив і перевіряв наступні пропозиції:
Залишилися ключі ssh
Це чисте налаштування без залишків. Мій ключ належним чином додано до файлу авторизованих ключів і є єдиним у списку.
Запуск ssh за допомогою журналу налагодження показує помилки, пов'язані із змінами середовища Ruby.
Моя виходить чистою. Налагодження SSH показує вдале з'єднання. Все, що стосується рукостискання аутентифікації, є нормальним, тоді це кінець результату:
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 eow@openssh.com reply 0 debug1: channel 0: free: client-session, nchannels 1 debug1: fd 0 clearing O_NONBLOCK debug1: fd 1 clearing O_NONBLOCKПроблеми з середовищем gitlab-shell.
На відміну від багатьох інших із тим самим повідомленням про помилку вище, мій скрипт перевірки gitlab-shell повертає чистий рахунок:
% 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Перезапустіть {unicorn, sidekiq, redis}
Звіти, що перезапуск однієї або декількох служб очищає це, схоже, не застосовуються тут. Це не переривчаста проблема, яка виводить виправлення демона.
Фізично не створюється репо
Але це. Перший раз, коли щойно
~gitlab/repositories/username/reponame.gitстворюється голий gpo repo in, здається, має правильні дозволи.Gitlab-shell не може спілкуватися з сервером API, оскільки A) проблеми з DNS, B) неправильне ip / порт / прив'язка інтерфейсу C), що не має / має продільну косу рису.
Сценарій перевірки каже, що доступ до API нормально.
Я не запускаю nginx, тому проблемою зв’язування ip за замовчуванням, пов'язаною з цим, є n / a.
Я спробував і те,
*:8080і127.0.0.1:8080значення слухати вunicorn.yml.Крім того, я спробував різні ітерації localhost, 127.0.0.1 і повністю кваліфікований доменне ім’я (що дозволяє вирішити DNS), без і без зворотнього прорізування
shell.yml. Я також спробував підключити це безпосередньо до сервера єдиноріг на порту 8080 замість хоста Apache SSL / проксі на порт 80. Ніщо не має значення. Мій сертифікат не підписаний самостійно і працює нормально для браузерів, але яself_signed_cert: trueвсе-таки спробував налаштувати . Нічого.Повідомлені шляхи git неправильні. Додайте повністю кваліфікований шлях від дому користувача gitlab.
Це здається легітимною пропозицією, якщо gitlab-shell не робить жодної справи мавп, щоб це виправити, але я спробував змінити
git remote add origin gitlab@server:username/reponame.gitна `` git remote add origin gitlab @ server: repositories / username / reponame.git` безрезультатно. Та сама помилка.
Це здається літанією запропонованих рішень, але жодне з них не здається правильним. Примітка: Я можу перейти на http. Запрошення для входу приймає моє ім’я користувача та пароль ldap та приймає натиск. Це лише проблема при спробі використання SSH. Тестування лише частини ssh для входу в систему ssh -T gitlab@serverдобре працює.
Що ще може спричинити цю помилку?
Як можна налагодити таку проблему в gitlab? Здається, взагалі немає нічого актуального ~gitlab/gitlab-shell/gitlab-shell.log. Де було б знайдено більш інформативне повідомлення про помилку?