Clark, thanks for reply.
On Mon, Apr 10, 2017 at 6:49 PM, Clark Boylan <cboy...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
