Re: classfiltercsv: filtering only works on bundle level

Xander Cage <[email protected]>
Newsgroups gmane.comp.sysutils.cfengine.general
Message-ID <[email protected]>
ah good to know, so there is no hurry in eliminating arrays.

btw...i tried you suggestion  and passed the data container to the child 
function...no fun. variable undefined and a strange error thrown.

/var/cfengine/bin/cf-agent -KI -f ./data_container_test.cf
   error: The value of variable 'default:remove_in_files.user' contains a 
reference to itself, '$(user)'
R: $(user)
R: Time: Mon Oct 18 10:07:14 2021 -  Bundle: check_user - Message: uid 
$(user) completely removed.


bundle agent parent_bundle
{
  
  vars:
      "data_file" string => "/root/cfe_testbed/users.csv";
      "d" data => classfiltercsv($(data_file), "true", 0);

      
  methods:

   "call_check_user"     usebundle => check_user( @(d) ),
                         handle => "remove_it";

    
}

bundle agent check_user (info) {

    vars:

          "keys_unsorted" slist => getindices("info");
          "keys" slist => sort(keys_unsorted, "lex");
          "user" string => "$(info[$(keys)][uid])";

    classes:

               classes:

                 "zombie";


               "EXISTS_PASSWD"
                     comment    => "check if user exists as local user (in 
/etc/passwd)",
                     expression => regline("^$(user):.*", "/etc/passwd");

               "EXISTS_LDAP"
                     comment    => "check if user has an entry in the 
/etc/security/user file",
                     expression => regline("^$(user):", 
"/etc/security/user");

               "EXISTS_HOMEDIR"
                    comment    => "user has a homedir..",
                    expression => fileexists("/home/$(user)/.");

    methods:

        "remove_by_aix"       usebundle  => remove_by_aix($(user)),
                              comment    => "if its an OS-user let AIX do a 
rmuser",
                              ifvarclass => "EXISTS_PASSWD";

        "remove_from_files"   usebundle  => remove_in_files($(user)),
                              comment    => "remove in stanza-files and 
cronjob-dir";

        "remove_home_dir"     usebundle  => remove_home_dir($(user)),
                              comment    => "will assume /home/$USER is the 
homedir",
                              ifvarclass => "EXISTS_HOMEDIR";

    reports:

       "$(user)";

        EXISTS_PASSWD.!EXISTS_LDAP::

            "Time: $(sys.date) -  Bundle: $(this.bundle) - Message: uid 
$(user) exists in /etc/passwd only (OS user).";

        !EXISTS_PASSWD.EXISTS_LDAP::

            "Time: $(sys.date) -  Bundle: $(this.bundle) - Message: uid 
$(user) exists only in security-file (LDAP user).";

        EXISTS_HOMEDIR.!EXISTS_LDAP.!EXISTS_PASSWD::

            "Time: $(sys.date) -  Bundle: $(this.bundle) - Message: uid 
$(user) leftover /home/dir.";

        !EXISTS_HOMEDIR.!EXISTS_LDAP.!EXISTS_PASSWD::

            "Time: $(sys.date) -  Bundle: $(this.bundle) - Message: uid 
$(user) completely removed.";

}

bundle agent remove_by_aix(user) {


    commands:

        "/usr/sbin/rmuser -p  "
            args    => "$(user)",
            comment => "remove with OS means ..";

}

bundle agent remove_in_files(user) {


    vars:

        "stanza_files" slist => { "/etc/security/limits",
                                  "/etc/security/user",
                                  "/etc/security/lastlog",
                                  "/etc/security/passwd",
                                  "/etc/security/environ",
                                  "/etc/security/user.roles",
                                };

    files:

        "/var/spool/cron/crontabs/$(user)"
                comment => "delete leftover cronjob file",
                delete  => tidy;

    methods:

        "call_remove_stanza" usebundle  => delete_stanza($(stanza_files), 
$(user)),
                             comment    => "delete user in each file";
}

bundle agent remove_home_dir(user) {


    methods:

        "remove_home_dir" usebundle => rm_rf("/home/$(user)"),
                          comment   => "delete leftover home-dir";
}


On Friday, October 15, 2021 at 5:02:53 PM UTC+2 Nick Anderson wrote:

> *Deprecated* is probably too strong of a word there. They aren't going 
> anywhere, at least not in CFEngine 3. But there is more focus on data type 
> variables and generally I would tend to use functions that return data vs 
> returning a classic array.
>
> So, I probably would not spend time hunting down classic arrays unless I 
> had nothing better to do.
>
> On Friday, October 15, 2021 at 3:03:09 AM UTC-5 Xander Cage wrote:
>
>> ah...yes, just a matter of reorganization, thank you. helped a lot. 
>>
>> while we are at it...i am just doing all this because of this phrase in 
>> -> 
>> https://docs.cfengine.com/docs/3.18/reference-language-concepts-variables.html#associative-arrays
>>
>> Note that associative arrays are being deprecated in favor of the data 
>> <https://docs.cfengine.com/docs/3.18/reference-promise-types-vars.html#data> 
>> variable type. 
>>
>> this sent me on the hunt for arrays in my policy jungle. or is this 
>> statement just informational?
>> On Thursday, October 14, 2021 at 9:53:49 PM UTC+2 Nick Anderson wrote:
>>
>>> Hi, 
>>>
>>> Hopefully this attaches itself to the correct thread, no email in my 
>>> inbox to respond to for this one. ¯\_(ツ)_/¯ 
>>>
>>> Can you provide a completely stand-alone policy so that we can easily 
>>> run and re-produce the problem you have? 
>>>
>>> Proceeding only with my internal parser :)…. 
>>>
>>> Regarding "only works if the data and filter classes are in the same 
>>> bundle", I suspect that you are just seeing class scope at work. In the 
>>> documentation, Classes and Decisions in Language Concepts of the 
>>> Reference manual 
>>> <https://docs.cfengine.com/docs/3.18/reference-language-concepts-classes.html> 
>>> has a section on Class scope 
>>> <https://docs.cfengine.com/docs/3.18/reference-language-concepts-classes.html#class-scope> 
>>> which talks about this a bit. It looks like you are using classes that are 
>>> defined with a *bundle* scope (only visible within that bundle) and 
>>> when you call your child_bundle you did not have it inherit the classes, so 
>>> inside of child_bundle, any *bundle* scoped classes that were defined 
>>> in parent_bundle won't be visible. 
>>>
>>> bundle agent __main__{
>>>   methods:
>>>       "parent";
>>> }bundle agent parent{
>>>   classes:
>>>       "my_bundle_scoped_class_defined_in_parent";
>>>
>>>   methods:
>>>       "Write our child into our will"
>>>         usebundle => child,
>>>         inherit => "true";
>>>
>>>       "Step children get the shaft by default"
>>>         usebundle => step_child;
>>> }bundle agent child{
>>>   reports:
>>>       "$(this.bundle): I can see my_bundle_scoped_class_defined_in_parent since my parent wrote me into the will."
>>>         if => "my_bundle_scoped_class_defined_in_parent";
>>>       "$(this.bundle): I wasn't written into the will, at least I am not red-headed."
>>>         unless => "my_bundle_scoped_class_defined_in_parent";}bundle agent step_child{
>>>   reports:
>>>       "$(this.bundle): I can see my_bundle_scoped_class_defined_in_parent since my parent wrote me into the will."
>>>         if => "my_bundle_scoped_class_defined_in_parent";
>>>       "$(this.bundle): I wasn't written into the will, at least I am not red-headed."
>>>         unless => "my_bundle_scoped_class_defined_in_parent";}
>>>
>>>
>>> R: child: I can see my_bundle_scoped_class_defined_in_parent since my parent wrote me into the will.
>>> R: step_child: I wasn't written into the will, at least I am not red-headed.
>>>
>>> Regarding "i want to use the data container as a somewhat "global" 
>>> variable without repeating it" , I don't think that you have to repeat 
>>> the data container, you can pass it whole like you do, or pass it's name. 
>>> Either way, you don't get a variable registered in the state (see 
>>> --show-evaluated-vars). 
>>> Listing 1: Example Policy
>>>
>>> bundle agent __main__{
>>>    vars:
>>>       "my_data" data => '{ "data": "here" }';
>>>
>>>   methods:
>>>       "Pass data container"
>>>         usebundle => example_1( @(my_data) );
>>>
>>>       "Pass NAME of data container"
>>>         usebundle => example_2( "$(this.namespace):$(this.bundle).my_data" );}
>>> bundle agent example_1(my_data){
>>>       vars: "my_data_$(this.bundle)" data => '{ "bundle": "$(this.bundle)" }';
>>>       reports: "$(this.bundle):$(with)" with => storejson( @(my_data) );}bundle agent example_2(my_data){
>>>       vars: "my_data_$(this.bundle)" data => '{ "bundle": "$(this.bundle)" }';
>>>       reports: "$(this.bundle):$(with)" with => storejson( $(my_data) );}
>>>
>>>
>>> # cf-agent --no-lock --log-level info --show-evaluated-vars=my_data --file /tmp/example.cf
>>> R: example_1:{
>>>   "data": "here"
>>> }
>>> R: example_2:{
>>>   "data": "here"
>>> }
>>> Variable name                            Variable value                                               Meta tags                                Comment                                 
>>> default:example_1.my_data_example_1      {"bundle":"example_1"}                                       source=promise                                                                   
>>> default:example_2.my_data_example_2      {"bundle":"example_2"}                                       source=promise                                                                   
>>> default:main.my_data                     {"data":"here"}                                              source=promise                                                                   
>>>
>>> Hope this helps … 
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups "help-cfengine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To view this discussion on the web visit https://groups.google.com/d/msgid/help-cfengine/f7a45ae6-3f24-4013-a1a2-3a53c59e8a0fn%40googlegroups.com.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.