Re: [Audit-test-developer] [PATCH 19/20] restructuralize networking documentation, example profile.bash

[Linda K. <lin...@hp...>]

On 05/02/13 10:42, Miroslav Vadkerti wrote:
> Hi Jirka and Linda
> 
> ----- Original Message -----
>> Please ignore [PATCH 19/20] and [PATCH 20/20], consider them excluded
>> from the series.
>>
>> I'm not really comfortable with so many changes in one commit,
>> I'll split them into several commits and submit separately.
>>
>> As for the profile.bash - we always use a script with all variables
>> exported, similar to utils/netfilter/profile.sample or a similar part
>> in README.netfilter. It makes reboots quite easy.
>>
>> This is the reason why the previous patch series broke NS install
>> - I assumed that netfilter-related variables will be available
>> to network tests as well.
>>
>> However I understand your concerns about keeping inter-testbucket
>> dependencies as few as possible.
>>
>> On 04/22/2013 11:09 PM, Linda Knippers wrote:
>>> Hmmm...I don't really see this as an improvement.  Now I have to
>>> look at README.netfilter for the diagram, the profile.bash to understand
>>> what the variables are, and the new separate ifcfg-rhel.txt to see
>>> the examples?  I can see having the ifcfg information separate if
>>> you have one for rhel6, one for rhel7, one for SLES11, etc., but I
>>> don't see the point of having it separate if there's just one.
>>
>> Is there a reason for keeping them in one place?
>>
>> The new profile.bash is meant to be suite-wide config, not
>> netfilter-only configuration. Original README.netfilter contained
>> non-netfilter variables as well.
>>
>> The reason for ifcfg-rhel.txt was to separate distro-specific
>> example configuration from the generic distro-independent information.
>>
>>> I realize that eth0 and eth1 are more realistic interface names for the
>>> TOE but I thought having them be different from the interface names on
>>> the NS was helpful for the examples.
>>
>> The more likely explanation is that eth3 and eth4 were taken from a real
>> setup, likely along with example MAC addresses.
>>
>>>> @@ -122,7 +122,12 @@ If running on an LSPP/MLS system, install the test
>>>> policy and change to the
>>>>  "lspp_test_r" role.
>>>>  
>>>>  # make policy
>>>> -# newrole -r lspp_test_r
>>>> +
>>>> +Now log out of the system, log back in as the eal user, switch role
>>>> +to lspp_test_r and become root.
>>>
>>> Why don't the previous instructions work?
>>
>> Newrole spawns a new shell, which creates a "chain" like
>>   ssh -> sysadm_r -> su -> lspp_test_r -> bash
>>
>> This is most likely fine, but it doesn't match the "chain" that would
>> exist after reboot and login:
>>   ssh -> lspp_test_r -> su -> bash
>>
>> This *could* have unforseen consequences, so it makes sense to avoid
>> taking any chances.
> 
> Well, I remembered this one from my early days while working on the testsuite.

The instructions were wrong (well, they worked with RHEL5 but not
RHEL6) in the early days (the order of the su and newrole were
reversed) but we fixed that based on your feedback.  Perhaps that's
what you're thinking of?

We might have had other errors too but I thought we cleaned everything
up.  That's why I was wondering if something no longer worked.

-- ljk

> Unfortunately I didn't note enough info back then and I cannot reproduce the 
> wrong influence on the steps anymore on any MLS related testcase. I consider
> this issue as resolved and the patch regarding this is not needed anymore.
> 
> Jirka pls remove this hunk prom the patch set.
> 
> Thanks and regards,
> /M
> 
> 
>>
>>> But what if I don't want to run the netfilter tests?  Do these
>>> instructions still work?  Since the netfilter tests have extra
>>> requirements (2 NICs, for example), its nice (ok, required) to be able
>>> to run all the rests of the tests, including the network tests, without
>>> running the netfilter tests.
>>
>> To my best knowledge, none of the changes submitted in this or the
>> previous patch series created new dependencies on the secondary network
>> for non-{netfilter,netfilebt} tests. The "network" tests should work
>> without "secnet" just fine.
>>
>> The changes have just made the "network" tests use the infrastructure
>> provided by the addition of netfilter tests - variables related to
>> the primary "lblnet" network, to be exact.
>>
>> The actual networking-related dependencies should remain untouched
>>  - local tests shouldn't need any networking at all, "network" tests
>> should be fine with LOCAL_* and LBLNET_*, netfilter/netfilebt needing
>> LOCAL_SEC_* and SECNET_* above that.
>>
>>>> +Please note that in the examples above, all interfaces are configured via
>>>> static
>>>> +network address assignment. You may use also DHCP for configuring your
>>>> devices
>>>> +but static addresses are best of the DHCP addresses aren't persistent or
>>>> +don't provide the subnet separation required by the tests.
>>>> +
>>>> +If DHCP addresses are used and are not persistent, the LBLNET and SECNET
>>>> +variables must be updated each time an address on the NS changes, and
>>>> +the LOCAL variables must be updated if an address on the TOE changes.
>>>> +A change to either server will require re-running 'make netconfig'
>>>> +on the TOE and re-running the NS setup procedure described in
>>>> README.netwk_svr.
>>>
>>> This (the ifcfg examples) is an odd place to find an important note
>>> the LBLNET and SECNET variables if running with DHCP.  This wording
>>> made more sense here when it was all in one file.
>>
>> <snip>
>>
>>>> +After configuring the interfaces you need to restart the networking for
>>>> the
>>>> +changes to take effect.
>>>> +
>>>> +# service network restart
>>>> +
>>>> +After restarting the network on the TOE and NS, verify the
>>>> +configuration by examining the results of 'ifconfig' on each
>>>> +system.  On the TOE, verify the bridge configuration with the
>>>> +'brctl show' command.
>>>
>>> Same for the above.  I wouldn't expect to find part of the setup
>>> instructions here.
>>
>> I plan to move it back to README.netfilter, good catch, thanks.
>>
>>>> +# bitness, 32 or 64
>>>> +export MODE="64"
>>>
>>> In other places, we figure out what the right MODE is based
>>> on the default for the machine/OS and we don't override the
>>> MODE if it was already set.
>>>> +
>>>> +# protection profile
>>>> +# "capp" if the TOE is configured in 'base' mode or
>>>> +# "lspp" if the TOE is configured in 'mls' mode
>>>> +export PPROFILE="lspp"
>>>
>>> In other places, we figure out the right PPROFILE (capp
>>> if there's no SELinux) and we also default to capp if PPROFILE
>>> isn't set.  We don't override PPROFILE if it was already set.
>>>
>>> See rules.mk at the top level directory of the test suite.
>>
>> Thanks for pointing it out. This leaves [PATCH 20/20] without much sense
>> as this autodetection logic applies to it as well, meaning a better
>> solution (if any) is needed.
>>
>>
>> As pointed out in the first sentence of this email, I plan to rewrite
>> this patch entirely into several patches, addressing the issues that
>> were pointed out, creating a small series that should be easier
>> to review.
>> The new profile.bash should be re-designed to take the autodetection
>> into account, for example.
>>
>> Jiri
>>
>>
>> ------------------------------------------------------------------------------
>> Try New Relic Now & We'll Send You this Cool Shirt
>> New Relic is the only SaaS-based application performance monitoring service
>> that delivers powerful full stack analytics. Optimize and monitor your
>> browser, app, & servers with just a few lines of code. Try New Relic
>> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
>> _______________________________________________
>> Audit-test-developer mailing list
>> Aud...@li...
>> https://lists.sourceforge.net/lists/listinfo/audit-test-developer
>>
>