Ошибка при загрузке артефактов координатору

Я немного повеселился, настраивая GitLab, и, потратив немало времени на его взлом, я относительно привык к его настройке, теперь, сделав это на двух машинах, второй раз с гораздо большей легкостью, чем первоначально …

Однако я столкнулся с довольно большой проблемой на обеих машинах: мой конвейер CI сломан. Каким-то образом где-то моя установка предоставляет 403 артефактам после завершения сборки, а это означает, что каждая работа, которая когда-либо технически успешна, будет только обречена на провал ...

Я рылся в сети в поисках ответов, но не нашел много полезного.

Я обновил GitLab CE до 10.1.4 минуты назад, а также GitLab-runner до 10.1.0, последние пакеты, доступные мне через apt на более важной из двух машин, на которых установлена ​​более новая версия Ubuntu, чем другая - 17.04. пикантность на «зверюге» по сравнению с 16.10 яккеты на «q2». Обе регистрации gitlab-runner используют оболочку для выполнения.

Соответствующий вывод задания CI выглядит следующим образом:

Cloning repository...
Cloning into '/[clonepath]'...
Checking out 8319d586 as master...
Skipping Git submodules setup
mesg: ttyname failed: Inappropriate ioctl for device
mesg: ttyname failed: Inappropriate ioctl for device
mesg: ttyname failed: Inappropriate ioctl for device
$ mvn -B install
[INFO] Scanning for projects...

...

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 11.204 s
[INFO] Finished at: 2017-11-18T05:45:08+01:00
[INFO] Final Memory: 27M/640M
[INFO] ------------------------------------------------------------------------
mesg: ttyname failed: Inappropriate ioctl for device
mesg: ttyname failed: Inappropriate ioctl for device
mesg: ttyname failed: Inappropriate ioctl for device
Uploading artifacts...
target/*.jar: found 1 matching files               
ERROR: Uploading artifacts to coordinator... forbidden  id=35 responseStatus=403 
Forbidden status=403 Forbidden token=sP9oHykF
FATAL: permission denied                           
ERROR: Job failed: exit status 1

Я запускаю GitLab под поддоменом Apache2 Vhost, в основном для эстетики и исключения порта, следующего за хостом, то есть 8080 для единорога, поскольку на Apache работают другие сайты.

Это настроенные параметры в моем gitlab.rb:

gitlab_rails['trusted_proxies'] = [ '127.0.0.1' ]
gitlab_workhorse['listen_network'] = "tcp"
gitlab_workhorse['listen_addr'] = "127.0.0.1:8181"
nginx['enable'] = false

Установка значений в любой из следующих опций / значений как таковых

web_server['username'] = 'www-data'
web_server['group'] = 'www-data'

выдает ошибку при перенастройке:

Starting Chef Client, version 12.12.15
resolving cookbooks for run list: ["gitlab"]
Synchronizing Cookbooks:
  - package (0.1.0)
  - registry (0.1.0)
  - consul (0.0.0)
  - gitlab (0.0.1)
  - runit (0.14.2)
Installing Cookbook Gems:
Compiling Cookbooks...
Recipe: gitlab::default
  * directory[/etc/gitlab] action create (up to date)
  Converging 408 resources
  * directory[/etc/gitlab] action create (up to date)
  * directory[Create /var/opt/gitlab] action create (up to date)
  * directory[/opt/gitlab/embedded/etc] action create (up to date)
  * template[/opt/gitlab/embedded/etc/gitconfig] action create (up to date)
Recipe: gitlab::web-server
  * group[Webserver user and group] action create (up to date)
  * user[Webserver user and group] action create

 ================================================================================
    Error executing action `create` on resource 'user[Webserver user and group]'
 ================================================================================

    Mixlib::ShellOut::ShellCommandFailed
    ------------------------------------
    Expected process to exit with [0], but received '8'
    ---- Begin output of ["usermod", "-s", "/bin/false", "-d", "/var/opt/gitlab/nginx", "www-data"] ----
    STDOUT:
    STDERR: usermod: user www-data is currently used by process 2656
    ---- End output of ["usermod", "-s", "/bin/false", "-d", "/var/opt/gitlab/nginx", "www-data"] ----
    Ran ["usermod", "-s", "/bin/false", "-d", "/var/opt/gitlab/nginx", "www-data"] returned 8

    Resource Declaration:
    ---------------------
    # In /opt/gitlab/embedded/cookbooks/cache/cookbooks/package/definitions/account.rb

     38:     user params[:name] do
     39:       username username
     40:       shell params[:shell]
     41:       home params[:home]
     42:       uid params[:uid]
     43:       gid params[:ugid]
     44:       system params[:system]
     45:       supports params[:user_supports]
     46:       action params[:action]
     47:     end
     48:   end

    Compiled Resource:
    ------------------
    # Declared in /opt/gitlab/embedded/cookbooks/cache/cookbooks/package/definitions/account.rb:38    :in `block in from_file'

    user("Webserver user and group") do
      params {:action=>nil, :username=>"www-data", :uid=>nil, :ugid=>"www-data", :groupname=>"www-data", :gid=>nil, :shell=>"/bin/false", :home=>"/var/opt/gitlab/nginx", :system=>true, :append_to_group=>true, :group_members=>["www-data"], :user_supports=>{:manage_home=>false}, :manage=>true, :name=>"Webserver user and group"}
      action [:create]
      supports {:manage_home=>false}
      retries 0
      retry_delay 2
      default_guard_interpreter :default
      username "www-data"
      gid 33
      home "/var/opt/gitlab/nginx"
      shell "/bin/false"
      system true
      iterations 27855
      declared_type :user
      cookbook_name "gitlab"
      recipe_name "web-server"
    end

    Platform:
    ---------
    x86_64-linux


    Running handlers:
    Running handlers complete
    Chef Client failed. 0 resources updated in 04 seconds

А что касается Apache, вот Vhost с поддержкой SSL:

<IfModule mod_ssl.c>
  <VirtualHost *:443>
    ServerName [host]
    ServerAdmin [email]
    DocumentRoot /opt/gitlab/embedded/service/gitlab-rails/public
    ServerSignature Off
    ProxyPreserveHost On
    AllowEncodedSlashes NoDecode
    <Location />
      Order deny,allow
      Allow from all
      Require all granted
      ProxyPassReverse http://127.0.0.1:8181/
      ProxyPassReverse http://[host]/
      RequestHeader set X-Forwarded-Ssl 'on'
    </Location>
    RewriteEngine on
    RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f [OR]
    RewriteCond %{REQUEST_URI} ^/uploads/.*
    RewriteRule .* http://127.0.0.1:8181%{REQUEST_URI} [P,QSA,NE]

    SSLCertificateFile /etc/letsencrypt/live/[host]/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/[host]/privkey.pem
    Include /etc/letsencrypt/options-ssl-apache.conf
  </VirtualHost>
</IfModule>

Есть идеи, что происходит? Я еще не откопал информацию журнала Apache, так как это, вероятно, не будет Apache, поскольку запрос идет прямо к gitlab-worker (8181). Какие журналы мне следует проверить при необходимости?

Спасибо за уделенное время.


person oasis9 - Bob Sharp    schedule 18.11.2017    source источник


Ответы (1)


Это не особенно полезный ответ, так как решение не имеет большого объяснения своей работы.

Конфигурации, которые у меня были, остались такими же, как указано выше, но для бегуна, который я установил, я удалил конфигурацию rm /etc/gitlab-runner/config.toml, а затем приступил к удалению пакета с машины, apt purge gitlab-runner. (gitlab-ci-multi-runner - еще один пакет, который доступен, но, похоже, не обновлен до GitLab 10 - возвращает 404, а не подключается к узлу).

Я переустановил бегун apt install gitlab-runner, а затем зарегистрировал его - gitlab-runner register. Здесь важно отметить, что во время регистрации я использовал свое полное доменное имя, например, https://git.example.com вместо любого локального адреса, такого как http://localhost:8080 или http://localhost:8181 (unicorn, gitlab-workhorse соответственно). И да, я запускаю свои бегуны на своем локальном компьютере. Опасно, но я слишком доверяю своей команде. Это может быть нашей неудачей, невежественное системное администрирование является ключом к успеху.

person oasis9 - Bob Sharp    schedule 18.11.2017