[9.201][BUG] The whitelist/blacklist object already exists (Web Filter)

When i add a whitelist/blacklist website to the Filter Action, saving the object but NOT the Filter Action itself, the next time i want to use the same Name, i get the following error:

The whitelist/blacklist object with the name 'MyName' already exists.

But you can't see it with the webadmin (Screenshots).


How can i delete this invisible object? SSH?

Greetz [:P]
  • This looks like missing UI functionality, there is no "folder" to select existing definitions or other management mechanism that I could find quickly.

    The same problem exists in 9.109 in the "Add regular expression objects" in Web Protection->Web Filtering->URL Filtering.  Also, clicking on the red X removes it from the group but does not appear to remove the REF in 9.109 (it did appear to remove the REF in 9.200-11).

    Proceed at your own risk, or at the very least none to me. Make backups, work within your change management processes and maintenance windows after testing in an appropriate environment.

    Dump domain regular expression objects:
    cc get_objects_filtered '$_->{type} eq "domain_regex"'


    If that doesn't work (get_objects_filtered removed from 9.3+?) try:
    cc get_objects http domain_regex


    or try the gof.pl script.

    Verify the only affected nodes/objects is itself.
    cc get_affected_nodes REF_HttDomWhatever
    cc get_affected_objects REF_HttDomWhatever


    Delete orphaned object:
    cc del_object REF_HttDomWhatever


    Please let me know how these work for you.
  • Hello teched,

    thanks for answering.
    The affected UTM is for testing only.

    Your solution works great [:O]
    Had some problems at the beginning, because i have to write the commands in RAW mode, with ' and () but now it works like a charm [:P].

    Where can i get some deeper basic knowledge about commandline?


    Here are the instruction for cc newbies like me:
    Remember:
    Direct configuration of Astaro from the shell is unsupported, unless directed to by Astaro Support staff or official documentation.
    For paid licenses, modifications done from the shell without direction or sanction may nullify your support agreement.


    1. SSH to UTM and login with loginuser
    2. su - root
    3. cc
    4. RAW
    5. get_objects_filtered ('$_->{type} eq "domain_regex"')
    Now you should get anything like:


    Calling Confd function get_objects_filtered('$_->{type} eq "domain_regex"')
    result: [
              {
                'autoname' => 0,
                'class' => 'http',
                'data' => {
                            'comment' => 'orphancomment',
                            'domain' => [
                                          'orphandomain.com'
                                        ],
                            'include_subdomains' => 0,
                            'mode' => 'Domain',
                            'name' => 'ORPHANname',
                            'regexps' => [],
                            'restrict_regex' => 1
                          },
                'hidden' => 0,
                'lock' => '',
                'nodel' => '',
                'ref' => 'REF_HttDomOrphanname',
                'type' => 'domain_regex'
              }
            ]
    To delete the orphaned object type:


    1. del_object ('REF_HttDomMyname')
    THANK YOU TECHED!! :-)
  • I did things a bit differently - I didn't use RAW.

    [LIST=1]
    • Login as loginuser via SSH.
    • su -
    • cc commands, as in my Code sections at the bash # prompt.
    [/LIST]

    Limited example:

    utm:/root/ # cc get_affected_objects REF_HttDom19216801
    [
              'REF_HttDom19216801'
            ]
    utm:/root/ # cc get_affected_nodes REF_HttDom19216801
    []
    utm:/root/ # cc del_object REF_HttDom19216801
    1
  • *push

    Not shure if this one got lost in the shuffle [SIZE="3"]:[/SIZE]>
  • I would like to chime in, very annoying issue that caused me headaches. Please fix it!
  • Thanks for reporting. We are now tracking this as Mantis ID #31479
  • The Mantis ID #31479 is now under investigation. We are planning to release a fix for this issue in Version 9.202.
  • We are planning to release a fix for this issue in Version 9.203.
  • We are planning to release a fix for this issue in Version 9.204.
  • We are planning to release a fix for this issue in Version 9.205.