Fix git group detection for gitolite ssh user.
Created by: VonC
The tasks gitlab:env:info mixes user and group, and presume as a group 'git'. However, gitolite group name can be anything.
That patch add the git group name in the config, and check gitolite.ssh_user group against git.group (which defaults to 'git', as before this patch, if undefined).
M config/gitlab.yml.example: Add 'group' in 'git' section Mention default value for the two extra settings M lib/tasks/gitlab/check.rake: Check that gitolite.ssh_user group is the one defined in git.group. Make sure to default to 'git' as the expected group if said group is undefined in the config. Note: uses a more complete regexp for the group detection (the group can start, end or be in the middle or the list of groups of gitolite.ssh_user)
Merge request reports
Activity
Unable to load the diff Created by: riyad
This should go into https://github.com/gitlabhq/gitlabhq/blob/master/config/initializers/1_settings.rb
By Administrator on 2013-01-14T11:44:38 (imported from GitLab project)
By Administrator on 2013-01-14T11:44:38 (imported from GitLab)
Unable to load the diff Unable to load the diff Created by: VonC
@Riyad So #{git_group} is correct (even if incorrectly named), right? What 'gitlab' is (or comes from), then, if it isn't gitolite_ssh_user?
By Administrator on 2013-01-14T11:44:38 (imported from GitLab project)
By Administrator on 2013-01-14T11:44:38 (imported from GitLab)
Created by: gliptak
+1 You can have gitlab also running the git/gitolite install (so the group is indeed gitlab) (I understand that this is different than the standard install).
By Administrator on 2013-01-10T15:41:06 (imported from GitLab project)
By Administrator on 2013-01-10T15:41:06 (imported from GitLab)
Unable to load the diff Created by: VonC
@Riyad So I do need to add gitolite_ssh_user to git_group, right?
By Administrator on 2013-01-14T11:44:38 (imported from GitLab project)
By Administrator on 2013-01-14T11:44:38 (imported from GitLab)
Created by: riyad
I think you are confused ... or maybe I am ... who knows. ;) There are two things to separate here: the Gitolite/SSH sphere (with the
gituser and group) and GitLab/Grack/HTTP sphere (with thegitlabuser and group). In the standard configuration thegituser and group are assumed to own and/or manage SSH access and the repositories. The problem is, that when you have somebody push over HTTP through GitLab/Grack (which run under thegitlabuser) the files written to the repositories will havegitlabset as owner. This will cause permission issues when other users try to push over SSH (using thegituser). So we add thegitlabuser to thegitgroup and have all files belong togit:gitand have setGID set. It's just that we assume, if you have a certain Gitolite/SSH user (configured with thegitolite.ssh_useroption) it's group is called the same. :)So I'm not quite sure what your setup looks like and what problems you have run into. :/
By Administrator on 2013-01-10T19:03:37 (imported from GitLab project)
By Administrator on 2013-01-10T19:03:37 (imported from GitLab)
Created by: VonC
@Riyad My issue is simple. I don't have user 'gitlab', or user 'git', or group 'git', or... That means all your checks and tests are failing in my setup (even though everything is working).
My goal is to generalize what seems to be hard-coded values, and allow for those checks to pass, even in a "non-standard" configuration.
My question is, if you are adding gitlab user to git group:
"where, in the settings, can I find those two names"?
I will rename git.group into gitolite.group (your explanation is quite clear on that), that will avoid using {gitolite_ssh_user} as a group (assuming git:git, which is certainly not true for any setup)
I don't know where to look for getting that 'gitlab' value though. Do I need to add another setting "gitlab.user"?
Again, assuming anything about the user and group simply isn't not possible in the real world: I have used the server my IT department gave me, with the account and the group they allowed me to reuse.
And, by the way, everything is working just fine (GitLab, gitolite, ssh, https access, even a bit of Apache Phusion Passenger, ...).
But with accounts and groups very different of what is hard-code as being the "default".By Administrator on 2013-01-14T06:33:38 (imported from GitLab project)
By Administrator on 2013-01-14T06:33:38 (imported from GitLab)
Created by: VonC
@Riyad I have renamed git.group in gitolite.group, and introduced gitlab.user.
That way, the intent is clearer: adding the gitlab user (http) to the gitolite group (ssh).
By Administrator on 2013-01-11T11:16:39 (imported from GitLab project)
By Administrator on 2013-01-11T11:16:39 (imported from GitLab)
Created by: VonC
@Riyad corrections done (I add gitlab user (http) to the gitolite group (ssh)), and the patch passes CI, based on very latest commit eff6d3c1 (from today)
By Administrator on 2013-01-14T14:38:25 (imported from GitLab project)
By Administrator on 2013-01-14T14:38:25 (imported from GitLab)
Created by: dzaporozhets
Too much options. Is it a problem for anyone to setup gitlab user or what? Why we should keep everything in config? A lot of configurations really slows development and produce bugs. git user for gitolite and gitlab for gitlab. No configs.
By Administrator on 2013-01-16T13:18:14 (imported from GitLab project)
By Administrator on 2013-01-16T13:18:14 (imported from GitLab)
Created by: VonC
@randx Are you serious?
Do you really expect that out there in the real world, you will have your accounts named like you want?
You have HARD CODED VALUES for data as important as account names!
I will look forward for your own solution, but the status quo makes all your tests useless: my setup works, but I have none of your checks pass because you somehow "expect" my environment to conform to some kind of "naming convention" that, I can assure you, has no chance to be enforced when deployed in actual production servers.
By Administrator on 2013-01-16T13:32:46 (imported from GitLab project)
By Administrator on 2013-01-16T13:32:46 (imported from GitLab)
Created by: VonC
I have a few other values (from the
tasks/gitlab/check.rake) to add to the settings, but the general idea for those values (like the two introduced in this patch) is:- if you don't define them at all, they default to what exists right now: i.e. nothing changes.
- they clarify the intent (who is doing what).
- they allow the user to see what are the various parts needed by GitLab (gitolite, ssh, git, ...).
By Administrator on 2013-01-16T20:46:37 (imported from GitLab project)
By Administrator on 2013-01-16T20:46:37 (imported from GitLab)
Created by: dzaporozhets
Do you really expect that out there in the real world, you will have your accounts named like you want?
Why not? I wonder why you found it strange.
@Riyad np. you can merge if you find it ok
By Administrator on 2013-01-16T21:56:11 (imported from GitLab project)
By Administrator on 2013-01-16T21:56:11 (imported from GitLab)
Created by: VonC
@randx
Why Not?
Maybe because in 20 years:
- I never been root of a production server
- I never had the choice of choosing the accounts left for me to use
- I never had the luxury to install anything in the "standard" paths
- ... and so on
But if actually intent to enforce the "git user for gitolite and gitlab for gitlab" policy, you need to put it front and center in big bold red letters in your "Installation" page, because that has HUGE implications, especially on a server with an existing git user (for entirely) different purpose.
Why do I found "git user for gitolite and gitlab for gitlab" so strange?
Because it is simply impossible to ask for new accounts on all the servers you need to introduce, evaluate, test, and put into production a new framework (like yours: GitLab).
You take the account(s) the admins give you and run with it.Servers in big corps are not dedicated to an app: they are mutualized, meaning a lot of things are running on it.
If you want to know more about my vision of the "real world out there", see my presentation "DVCS in big corporation": http://www.youtube.com/watch?v=D2swiB8QOHk
I will track down other "assumptions" GitLab might contain and propose other variables to add, but again the idea remains:
If you don't define the settings I propose, then those variables will default to the current setting: nothing changes.
By Administrator on 2013-01-16T22:14:58 (imported from GitLab project)
By Administrator on 2013-01-16T22:14:58 (imported from GitLab)
Created by: riyad
Merged :) (see 8f9dec28)
- changed the
gitolite.groupoption name togitolite.owner_group - made the options commented out by default and updated the descriptions
- fixed the setting default values
- updated
check.raketo use the new settings throughout
By Administrator on 2013-01-16T23:36:02 (imported from GitLab project)
By Administrator on 2013-01-16T23:36:02 (imported from GitLab)
- changed the
Created by: dzaporozhets
I never had the choice of choosing the accounts left for me to use I never had the luxury to install anything in the "standard" paths
its sad
Servers in big corps are not dedicated to an app: they are mutualized, meaning a lot of things are running on it.
You know about Virtualization right?
I mean if big company NEEDS GitLab it can create a clean VM any time and setup an instance there or even setup a dedicated server fot it. Its not an 'ordering pizza web page' so I guess admins are more interested in code safety and valid of application.
Anyway one thing you are right - its better be configurable then hardcoded. Thank you for this PR and discussion
By Administrator on 2013-01-17T07:01:39 (imported from GitLab project)
By Administrator on 2013-01-17T07:01:39 (imported from GitLab)
Created by: VonC
@randx I am... at a loss for words.
I am really happy that you didn't had to deal with the same IT administration reality that I had to in several large corporations.
Good for you.But please at least entertain the idea that any assumption or hard coded value you could rely upon might not be valid in a client environment (for any -- good or bad -- reason, known from the client only).
By Administrator on 2013-01-17T07:14:56 (imported from GitLab project)
By Administrator on 2013-01-17T07:14:56 (imported from GitLab)
