Wow that's not terrifying advice at all. /sarcasm

If you expect someone to run their own git & ci server, is it so hard to give them a couple of dot-point instructions:

- create a .list file with these two lines: <blah>

- add the GPG key for Apt

- run aptitude/apt-get update

Sure enough, you're already listed on curl|sh (http://curlpipesh.tumblr.com), which also includes a link to the https://packages.gitlab.com/gitlab/gitlab-ce/install page which has a "manual" tab.

Even with "manual" selected, you still insist that people should make a http request to your server, to generate a .list file, even though the only variables are local variables, which you send as part of the request anyway: distro ID (e.g. Debian, Ubuntu, etc) and release codename (Wheezy, Jessie, etc).

The most ominous thing to me is that you send the result of `hostname -f` to your server. Even bigger WHY!?

Hi:

I built packagecloud, which is what GitLab uses for hosting packages.

Getting a package repository installed securely is quite a bit more difficult than it seems, but I agree that our Manual install instructions should be simplified and improved. I'll see what I can do about making them better.

As far as the hostname goes: we used it simply because its a unique identifier for the machine, but really anything could be used (like a MAC address or whatever). This is used because private repositories have tokens issued against a unique identifier, so a machine reinstalling a repo won't generate a new read token. I'll add a comment to the bash script explaining this, and consider adding an override in the future so that users can specify another identifier of their choice instead.

This is why a request to the server is required: it generates a read token server side which is then implanted into the APT repository configuration for the local machine so that the local machine can access the repo.

We want to make it as easy and fast as possible to start with GitLab, hence the curl from https. But feel free to send a merge request to improve the download page with the instructions you would like to see and we can discuss.

Sending the hostname is default Packagecloud.io behaviour.

> Sending the hostname is default Packagecloud.io behaviour

Your own download page states:

We recommend you set the name to the fqdn of the target node (the value of hostname -f on linux), but you can set it to whatever you want

If your company is recommending something, shouldn't you have a good reason why?

Can you link to the page where you found this? I can't find it on https://about.gitlab.com/downloads/#debian8

This seems like setup instructions for GitLab and I think it is unrelated.

The page I linked above: https://packages.gitlab.com/gitlab/gitlab-ce/install

Click the "Manual" tab, last paragraph of the 'deb' section.

This is the default download page of PackageCloud. The reason for this is probably that most of the time PackageCloud requires credentials to download packages. But I'll ask the author.

Joe of PackageCloud was kind enough to change the code so that an id will be send back, not the hostname.

The changes: 1.) Renamed hostname to unique_id everywhere, and added more prose around replacing unique_id with any unique identifier. 2.) Removed the unique_id code from install scripts for public repos (still exists in private repos) 3.) Modified the manual install instructions to be easier to follow, and not require a curl to the server for public repos. 4.) Added mirroring instructions for both YUM and APT.

Shipping in 1.0.23

I had to curl that file down and then pipe it in in a separate step, but it looks to be working. Thanks for your help!

You're welcome.