lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d8de9c6a-f1e5-a43e-4b6e-e20c3cd3e7d9@6wind.com>
Date:   Fri, 12 Apr 2019 17:42:15 +0200
From:   Nicolas Dichtel <nicolas.dichtel@...nd.com>
To:     Lucas Bates <lucasb@...atatu.com>
Cc:     Linux Kernel Network Developers <netdev@...r.kernel.org>,
        David Miller <davem@...emloft.net>,
        Jamal Hadi Salim <jhs@...atatu.com>,
        Cong Wang <xiyou.wangcong@...il.com>,
        Jiri Pirko <jiri@...nulli.us>,
        Marcelo Ricardo Leitner <mleitner@...hat.com>,
        Vlad Buslov <vladbu@...lanox.com>,
        Davide Caratti <dcaratti@...hat.com>, kernel@...atatu.com
Subject: Re: [RFC net-next 1/1] tdc.py: Introduce required plugins

Le 12/04/2019 à 17:21, Lucas Bates a écrit :
> On Fri, Apr 12, 2019 at 4:31 AM Nicolas Dichtel
> <nicolas.dichtel@...nd.com> wrote:
>>> in our tri-weekly tc test meeting and the general consensus to address
>>> what you brought up is leaning towards the following:
>>>
>>> - adding a symlink to nsPlugin
>> I don't understand why a symlink is needed. Just load it by default and use it
>> when needed. A property can be added to each test to tell which plugin (in fact,
>> which topology) is needed to run it.
>> Thus, if a new complex test is added, it can define another topology.
> 
> I'm loathe to hard-code it into the script, but we can avoid the
> symlink if we specify some default plugins to load in the
> tdc_config.py file.
Why is it a problem to specify the plugin in the test description? The fw tests
depend on a specific topology, thus it's better explicitly state that.

> 
>>> - Changing default behaviour so that unless an option is explicitly
>>> specified, all the tests will be run under a namespace with automatic
>>> creation of the ports
>> Yes.
>>
>>> - If the user chooses /not/ to use namespaces, it will still create
>>> the veth pair to use.
>> In fact, I would say an option so that the user can choose another topology.
> 
> Quite possibly, but for traffic generation (upcoming using scapy)
> we're just reusing the simple topology right now.
I was thinking you were arguing for this option. If nobody need it, let's just
remove it.

> 
>>>> After your patch, I got the following error:
>>>> $ ./tdc.py
>>>> Traceback (most recent call last):
>>>>   File "./tdc.py", line 740, in <module>
>>>>     main()
>>>>   File "./tdc.py", line 734, in main
>>>>     set_operation_mode(pm, args)
>>>>   File "./tdc.py", line 692, in set_operation_mode
>>>>     check_required_plugins(pm, alltests)
>>>>   File "./tdc.py", line 583, in check_required_plugins
>>>>     os.chown('plugins/{}'.format(fname), uid=int(os.getenv('SUDO_UID')),
>>>> TypeError: int() argument must be a string or a number, not 'NoneType'
>>>
>>> That would be expected if you aren't running tdc with sudo or as root
>>> or as a user with network admin capability.
>> I was root for the test.
> 
> Ah. That environment variable is probably not present on your system.
> Out of curiosity, what shell/distribution are you using?
> 
It was on a debian 8.11 / bash.


Regards,
Nicolas

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ