Yang - Implementing order dependent CLIs - ietf-netmod-yang

I have two CLIs and I have this below requirement.
If #1 is configured first, then #2 config is NOT allowed.
If #2 is configured first, then #1 config is allowed.
I have tried using must, but that makes them mutually exclusive. How do I implement this ordering in Yang?
Thanks

I don't think there is a direct approach available with this in Yang. May be for your product you need to add an extension, which can check while config is being loaded as part of edit-config

Related

Is there any difference between using SYS_syscallname __NR_syscallname in seccomp?

Which is the difference between using SYS_syscallname and __NR_syscallname in a seccomp filter? Which one should I use?
You should use __NR_syscallname (e.g., __NR_chdir). As per the syscalls manpage:
Roughly speaking, the code belonging to the system call with number __NR_xxx defined in /usr/include/asm/unistd.h can be found in the Linux kernel source in the routine sys_xxx().
The difference is that SYS_syscallname definitions are part of the libc, while __NR_syscallname definitions are from the Linux headers. I'm also not sure all __NR_syscallname have a SYS_syscallname alias.

How do I configure the ModSecurity engine to be ON for a single attack type and DetectionOnly for all others?

I need to gradually implement ModSecurity. It must be configured to only block attacks by a single attack type (e.g. SQLi), but log all other attacks from the other attack types.
For ease of upgrading the owasp rules, it is recommended to avoid modifying the original owasp rules. Ideally I'm looking for a solution which will follow this guideline and won't require modifying the original owasp rules.
Currently my test configuration is only accomplishing part of this. With this Debian installation of ModSecurity, I have removed individual rule files from /usr/share/modsecurity-crs/rules/*.conf from the configuration. This allows me to enable ModSecurity with engine=on and only the rule sets for the particular attack type loaded in the configuration, but it is not logging the incidents of other attack types.
You’ve a few options:
1) Use anomaly scoring and the sql_injection_score value that the OWASP CRS sets for SQLi rules.
Set your mode to DetectionOnly.
Set your anomaly scoring values very high in
Add a new rule that blocks if sql_injection_score is above a certain amount.
This can be achieved with an extra rule like this:
SecRule tx.sql_injection_score "#gt 1”
"id:9999,\
phase:5,\
ctl:ruleEngine=on \
block"
Setting the ”#gt 1” to an appropriate threshold.
The OWASP CRS sets similar variables for other categories as well.
2) Load rules individually and rules before and after to turn rule engine on and off.
Within a phase rules are executed in order specified. You can use this to have config like the following:
SecRuleEngine DetectionOnly
Include rules/other_rules_1.conf
Include rules/other_rules_2.conf
SecAction “id:9000, phase:2, ctl: ctl:ruleEngine=on”
Include rules/sqli_rules.conf
SecAction “id:9001, phase:2, ctl: ctl:ruleEngine=off”
Include rules/other_rules_3.conf
Include rules/other_rules_4.conf
However if a category contains several phases then you’ll need to add several SecActions - one for each phase used.
3) Active the rules you want by altering the Actions to include turning on the ruleEngine.
Set your mode to DetectionOnly.
Use SecRuleUpdateActionById to add a ctl:ruleEngine=on to the rules you want on. It would be nice if there was a SecRuleUpdateActionByTag or SecRuleAddActionByTag but there isn’t (though it has been asked for in the past).
This is probably a bit fragile as depends on knowing the specific rule ids and also requires checking the actions per rule or assuming they are all the same. Probably better to just edit the CRS files to be honest.
This is probably the best if you want to only enable a set of rules, rather than a full category.
4) Edit the files, to do the same as above directly.
This is not a bad option if you know this will be a short term option and eventually you hope to enable all rules anyway. Revert the file back when ready.
Alternatively leave the original rules in place and copy the rules, giving them new ids, and with the addition of the ctl:ruleEngine=on action.

AEM 6.4 upgrade - Cross-boundary resource type usage of internal marked path

While upgrading to 6.4, we ran pattern detector report and got below lines for ECU category. Is there any reference to fix this issue?
Cross-boundary resource type usage of internal marked path /libs/cq/gui/components/projects/admin/projectteam referenced at
/apps/cq/core/content/projects/gadgets/xtrftranslationprojectsummary/jcr:content/content/items/form/items/fixedcolumns/items/column2/items/tabs/items/tab1/items/projectmembers
One more:
Cross-boundary resource type usage of internal marked path /libs/cq/gui/components/projects/admin/wizard/properties/thumbnail referenced at
/apps/cq/core/content/projects/wizard/xtrftranslationproject/defaultproject/items/column1/items/cover
As per the official documentation on Extraneous Content Usage, this means that your custom code uses components that are considered internal and are not part of the API. Both errors say you referenced them so we're looking at simple use (rather than an overlay or inheritance based on sling:resourceSuperType). You just have a couple resources with the sling:resourceType values belonging to internal components whose use in this context is not something that's officially supported or tested.
They may break at some point when you upgrade to a newer version of AEM or try to apply a hotfix.
The best way to go forward would be to stop using them and replace them with other components that are considered public and therefore supported. If no suitable replacement is available, you should consider replacing them with custom code that you control.
I'm not familiar with either cq/gui/components/projects/admin/projectteam or cq/gui/components/projects/admin/wizard/properties/thumbnail so I can't recommend any replacements. Any potential replacement should have the mixin type of either granite:PublicArea (can be used, overlaid or inherited), granite:AbstractArea (can be inherited but not overlaid or used directly) or granite:FinalArea (can be used but not inherited).

Puppet Class: define a variable which list all files in a directory

I'm defining my own Puppet class, and I was wondering if it is possible to have an array variable which contains a list of all files in a specific directory. I was wondering to have a similar syntax like below, but didn't found a way to make it work.
$dirs = Dir.entries('C:\\Program Files\\Java\\')
Does anyone how to do it in a Puppet file?
Thanks!
I was wondering if it is possible to have an array variable which contains a list of all files in a specific directory.
Information about the current state of the machine to be configured is conveyed to the catalog compiler via facts. These are available to your classes as top-scope variables, and Puppet (or Facter, actually) provides ways to define your own custom facts. That's a link into the Facter 3 manual, but similar applies to earlier versions. Do not overlook the rest of the Facter documentation, which has more relevant information on this topic.
On the other hand, information about the machine providing catalog-building services -- the master in a master / agent setup -- can be obtained by writing and calling a custom function. This is rarely what you actually want, but it's worth mentioning because you might one day want a custom function for some other purpose.

Variable subsystem implementation in Simulink 2007a

I've seen that it's already implemented in Matlab R2013 in the form of Variant Subsystems, but budget and convenience don't show the upgrade necessary yet:
I am seeking a subsystem in which a concrete implementation can be selected prior to running the simulation, in Matlab R2007a.
A bunch of enabled subsystems along with a switch block connected to a masked variable would do the trick, however the whole family of selectable implementations must coexist inside the "container" subsystem.
Any workaround, other than upgrading to R2013?
Thank you.
I have come up with the following workaround.
1- Include all the possible implementations in a Library
2- Create a Configurable Subsystem block in the Library and edit it to include all the desired implementations
3- Right clicking in a Configurable Subsystem instance will show the "Block Choice" option where the desired implementation can be chosen.
Regardless of differences that may exist with respect to the Variant Subsystem solution when it comes to code generation, RT targets etc..., this solution works for me.