Revert removal of default password as it breaks unsupervised GitLab install/configurations.
The default password was removed in 8.6.0:
- Issue: https://gitlab.com/gitlab-org/gitlab-ce/issues/1980
- Changelog: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG#L205
This breaks server installation scripts where I’m setting up specific GitLab configurations automatically using the GitLab API immediately following an installation.
Without a default password, I don’t see how we can implement non-interactive setups of specific Gitlab configurations.
Currently, I am using something similar to the following and the latest release breaks it, with the first call returning a 401 unauthorised error:
echo -e "\t* Setting the GitLab root password…"
privateToken=$(curl "${curlSecurity}" -X POST https://${domain}/api/v3/session/ --data-urlencode 'login=root' --data-urlencode 'password=5iveL!fe' | jq --raw-output .private_token)
# Create the Generated account and store its ID.
echo -e "\t* Creating the ${gitlabAccountName} account on GitLab…"
curl "${curlSecurity}" --header "PRIVATE-TOKEN: ${privateToken}" -X PUT https://${domain}/api/v3/users/1 --data-urlencode "password=${gitlabAccountPassword}"
# Add the SSH key to the account.
echo -e "\t* Adding SSH key to the account…"
curl "${curlSecurity}" --header "PRIVATE-TOKEN: ${privateToken}" -X POST https://${domain}/api/v3/users/${accountID}/keys --data-urlencode "id=${accountID}" --data-urlencode "title=SSH Key" --data-urlencode "key=${publicKey}"
# Create the repository for sites.
echo -e "\t* Creating sites repository…"
curl "${curlSecurity}" --header "PRIVATE-TOKEN: ${privateToken}" -X POST https://${domain}/api/v3/projects/user/${accountID} --data-urlencode "user_id=${accountID}" --data-urlencode "name=sites" --data-urlencode "description=Site drafts generated by Better Inspector." --data-urlencode "public=true"
(Where curlSecurity is simply '--insecure' if the script is running with Let’s Encrypt’s staging server.)
Unless there is a different way of supporting this use case, without manual intervention from a human being who must first change the root password, I would like to ask that we consider reverting this change and reinstating a default root password.
This is a core use case for us as we are using GitLab installations as components of our application. It is also a feature that makes it possible to install and configure GitLab unsupervised as part of larger systems.