[openstack-dev] [infra] is it ok to create extra users with sudo permissions during devstack run
Pavlo Shchelokovskyy
pshchelokovskyy at mirantis.com
Mon Apr 10 16:24:42 UTC 2017
Clark,
thanks for reply.
On Mon, Apr 10, 2017 at 6:49 PM, Clark Boylan <cboylan at sapwetik.org> wrote:
> On Mon, Apr 10, 2017, at 08:31 AM, Pavlo Shchelokovskyy wrote:
> > Hi infra team,
> >
> > on order to test a piece of functionality I am developing, during the
> > devstack plugin run I need to create an extra user with password-less
> > sudo
> > permissions. As I am not sure of intricacies of our infra setup, I'd like
> > to clarify if it is acceptable.
> >
> > TL;DR
> > There is 'openstack/networking-generic-switch' project that mainly aims
> > to
> > provide a Neutron ML2 plugin suitable to manage cheap HW switches that
> > only
> > allow configuration over SSH. The problem with those is that these
> > switches
> > usually have limitations on the number of concurrent SSH sessions open on
> > the switch.
> >
> > In order to overcome this, I am attempting to introduce DLM to
> > networking-generic-switch to globally limit the number of active SSH
> > connections to a given switch across all threads of neutron-service on
> > all
> > hosts [0].
> >
> > To test this locally in my Xenial DevStack VM, I am creating and
> > configuring "ovsmanager" user with password-less sudo permissions (so it
> > is
> > able to manage OVS), limit the number of allowed sessions for that user
> > in
> > /etc/security/limits.d/ and configure networking-generic-switch to access
> > localhost via that user to simulate a switch with limited number
> > of allowed SSH sessions.
> >
> > My questions is is it ok if I replicate this logic in the devstack plugin
> > of networking-generic-switch to set up gate testing for this feature?
> > In the end it seems it boils down to whether infra re-uses VMs it creates
> > to run gate jobs for anything else and if such changes can affect those
> > re-using these VMs, but I might be missing something else.
> >
> > [0] https://review.openstack.org/#/c/452959/
>
> The test instances that run devstack are single use VMs that are not
> reused. Every job running on these instances starts with sudo access,
> but by default we remove sudo access for the stack user which is what
> the OpenStack services run as. We do this to force those services to use
> rootwrap (or its equivalent) and test that the rootwrap rules are
> functional.
>
> As long as you create your new user during the initial devstack run you
> shouldn't have any issues with this.
>
> It wasn't mentioned above, but I would run a separate sshd for this
> rather than modify the existing one as ssh is the control mechanism for
> the test jobs. Better to run a separate independent service that won't
> conflict with job control.
>
> Hope this helps,
> Clark
>
>
I'm not going to control the number of sessions via SSH itself and change
the /etc/ssh/sshd_config, instead I'm going to create a file
/etc/security/limits.d/ovsmanager.conf (this is the place on Ubuntu Xenial)
with
#<domain> <type> <item> <value>
ovsmanager - maxlogins 2
AFAIU this should not interfere with any other users and the number of
sessions/connections they are allowed (I would even prepend "ngs_" to the
created user name so it is clear what created it).
Cheers,
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170410/90a76291/attachment.html>
More information about the OpenStack-dev
mailing list