publish-over... and settings credentials
nicolas de loof
Romain Seguy
Your mail is interesting, and it's something that I do for the WAS Builder (deployment to WebSphere -- yeah, I know the name is not a good match). User/password can be defined at the central level but also at the build step level.
Actually, I think the subject you mention could be a little bit wider: In fact, the issue you raise is there mainly because the definitions of the servers is done at the Admin level (thus, in the global config screen), and the real question is: Is it the right place? Shouldn't a notion of Server or Resource be introduced within Jenkins (I remember talking about that maybe 1.5 or 2 years ago on the ML) and shouldn't a dedicated set of permission be set up accordingly?
I've worked on that a little bit and came with a plugin ("Resources Plugin") which I've not released (but I plan to release it as a basis for the WAS Builder plugin). Some screenshots to explain it:
- Pick the type of resources you want to manage: http://goo.gl/GJbxj
- Edit/add resources: http://goo.gl/BNRCV
I quote you: wdyt?
Romain
domi
Bap
> +1
>
> I also think this is something missing in Jenkins - kind of
> configurations between Administrator (Global) and User (Job)
> permissions?
> Therefore it would probably also make sense to define a new
> permission type for this kind of configuration.
> /Domi
>
> On 26.10.2011, at 13:11, Romain Seguy wrote:
>
>> Hi Nicolas,
>>
>> Your mail is interesting, and it's something that I do for the WAS
>> Builder (deployment to WebSphere -- yeah, I know the name is not a
>> good match). User/password can be defined at the central level but
>> also at the build step level.
>>
>> Actually, I think the subject you mention could be a little bit
>> wider: In fact, the issue you raise is there mainly because the
>> definitions of the servers is done at the Admin level (thus, in the
>> global config screen), and the real question is: Is it the right
>> place? Shouldn't a notion of Server or Resource be introduced
>> within Jenkins (I remember talking about that maybe 1.5 or 2 years
>> ago on the ML) and shouldn't a dedicated set of permission be set
>> up accordingly?
>>
>> I've worked on that a little bit and came with a plugin ("Resources
>> Plugin") which I've not released (but I plan to release it as a
>> basis for the WAS Builder plugin). Some screenshots to explain it:
>> - Pick the type of resources you want to manage: http://goo.gl/GJbxj
>> - Edit/add resources: http://goo.gl/BNRCV
>>
>> I quote you: wdyt?
>>
+1
I think the ability of those less privileged than administrators to be
able to define servers is
a definite winner.
I'm not sure, however, if it completely solves Nicolas' original
problem of having a set of
credentials that are private and for use with only one job/a few jobs.
Correct me if I'm not understanding the resources option correctly,
but if I had a server that most
people deployed to, I'd have to define the "server" multiple times,
once for each set of
credentials and then set a permission to restrict it to a particular
group, user or job.
IMHO, in this case having an incompletely defined server and requiring
the credentials to be filled
in in the job or publisher/build step would (potentially) save a lot
of configuration.
>> Romain
>>
>> 2011/10/26 nicolas de loof <nicolas...@gmail.com>
>> Hi folks,
>>
>> The Publish-over.. plugin family assumes network settings and
>> credentials are configured as a system-wide setting.
>> On large Jenkins installation, a common requirement is for each
>> development team to use dedicated credentials for security purpose,
>> and probably also dedicated sub-directories on the target server.
>>
>> An solution could be to allow additional "Abstract" (or "Hybrid"?)
>> configuration to be set at global settings, to allow centralized
>> configuration of network details (server IP, name services,
>> timeout...) but let job define credential + relative path.
>> i.e. have BPHostConfiguration include a boolean hybrid attribute,
>> use it to disable username / secretPassword on global settings and
>> provide a HostConfiguration jelly template for setting them from
>> job configuration, in addition to relative path to remoteRootDir
>>
>> wdyt ?
This seems like a good idea.
I'll try to take a look at this in the next week.
Bap.
>>
>> Nicolas
>>
Romain Seguy
Quoting domi <do...@fortysix.ch>:
+1
I also think this is something missing in Jenkins - kind of configurations between Administrator (Global) and User (Job) permissions?
Therefore it would probably also make sense to define a new permission type for this kind of configuration.
/Domi
On 26.10.2011, at 13:11, Romain Seguy wrote:
Hi Nicolas,
Your mail is interesting, and it's something that I do for the WAS Builder (deployment to WebSphere -- yeah, I know the name is not a good match). User/password can be defined at the central level but also at the build step level.
Actually, I think the subject you mention could be a little bit wider: In fact, the issue you raise is there mainly because the definitions of the servers is done at the Admin level (thus, in the global config screen), and the real question is: Is it the right place? Shouldn't a notion of Server or Resource be introduced within Jenkins (I remember talking about that maybe 1.5 or 2 years ago on the ML) and shouldn't a dedicated set of permission be set up accordingly?
I've worked on that a little bit and came with a plugin ("Resources Plugin") which I've not released (but I plan to release it as a basis for the WAS Builder plugin). Some screenshots to explain it:
- Pick the type of resources you want to manage: http://goo.gl/GJbxj
- Edit/add resources: http://goo.gl/BNRCV
I quote you: wdyt?
+1
I think the ability of those less privileged than administrators to be able to define servers is
a definite winner.
I'm not sure, however, if it completely solves Nicolas' original problem of having a set of
credentials that are private and for use with only one job/a few jobs.
Correct me if I'm not understanding the resources option correctly, but if I had a server that most
people deployed to, I'd have to define the "server" multiple times, once for each set of
credentials and then set a permission to restrict it to a particular group, user or job.
No no, this is not the intend. The current behavior is for a privileged user to create the server definition once. He can choose to set security credentials or not.
At the build step level, it the build step supports it of course (e.g. in the WAS Builder plugin this is supported), users can override security credentials if they've been defined at the server definition level, or set them if it's not the case.
I'll try to upload that in a github repo this week so that you can take a look at this.
Romain
Bap
Roman,
Yes, I understand the original email that Nicolas sent, and I agreed
with him, which is why I wrote "I'll try to take a look at this in the
next week."
What I was struggling to understand is how your resources solution
(although good for other reasons) solves Nicolas' original issue.
You wrote "... In fact, the issue you raise is there mainly because
the definitions of the servers is done at the Admin level (thus, in
the global config screen), and the real question is: Is it the right
place? ..."
From your reply on the 7th, it seems that you also agree that the
resources soloution would not solve the issue that Nicolas raised,
even though your original reply suggested that it would.
Bap.
Romain Seguy
In fact the resources solution partly solves Nicolas' issue in the sense that it separates server definitions from Jenkins' admin screen. That is, a new permission is available which doesn't require admin privileges. As such, he can be granted to a largest set of trusted users who can define new resources for everybody.
Still, what Nicolas mentions regarding the fact that he wants to be able to override credentials in the job is not (and can't be) covered by the plugin. The developer has to do that by himself directly in its plugin (I do thta for the WAS Builder plugin).
Tell me if it clears the confusion, it's true that I've not been very clear :-)
Romain