Re: [OpenStack-Infra] JJB's use of inspect plugin info requires administrator permissions

[Thanh Ha]

Taking a look at the code, I realized the test command allowed spoofing of
the plugins_info. I thought I'd try and see what happens if we allowed
spoofing with the update command too and submitted this patch:

https://review.openstack.org/326722

I'm wondering if this could be a possible solution to the Administrator
permissions issue assuming that providing the plugins_info yaml file causes
JJB to not query the live Jenkins system for the info.

Regards,
Thanh

On 7 June 2016 at 15:34, Thanh Ha  wrote:

> Hi Everyone,
>
> I've been meaning to bring this up for awhile. It seems some plugins are
> getting a bit smarter and using the "parser.registry.get_plugin_info"
> command to parse plugin versions to figure out what version of a plugin is
> installed in Jenkins.
>
> Unfortunately it's come to our attention that this feature in Jenkins
> requires the Administrator permission which can be problematic if you have
> an environment where you prefer not to give this permission out. I think
> the ideal solution is to build into Jenkins a separate permission for
> viewing plugin information. I'll try contacting Jenkins devs to see if this
> is something they can do inside Jenkins.
>
> Failing that maybe we can somehow make the plugin info optional in JJB?
> any thoughts around this topic?
>
> One of our use cases with this is that we have a sandbox instance of
> Jenkins deployed for our community to test jobs with however for obvious
> reasons we cannot give folks administrator access to this instance but
> unfortunately if someone is trying to use a plugin (such as the Slack
> plugin) that needs to inspect plugin versions jjb fails to push the job.
>
> Regards,
> Thanh
>
>
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Infra priorities and spec cleanup

[Jeremy Stanley]

On 2016-06-07 00:27:17 +0200 (+0200), Antoine Musso wrote:
> Sorry if I come late in the party, I rely on Nodepool snapshot
> feature to polish up images. I have even hit a wall recently
> attempting to use puppet to provision a service that can not
> always be done in a chroot or be to slow to do at instance boot
> time.
[...]
> Andreas Florath and Greg Haynes pointed out that upstart / init
> scripts in a chroot is usually a no/no
[...]

Worth checking with the DIB maintainers, but I've heard of work on
alternate non-chroot backends for it which would in theory alleviate
these concerns.
-- 
Jeremy Stanley

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra