Feedback: remove 127.0.0.1 from sys.ip_addresses (3.7)?

22 views
Skip to first unread message

Eystein Måløy Stenberg

unread,
Jul 18, 2014, 5:31:02 PM7/18/14
to <help-cfengine@googlegroups.com>
Hi everyone,

I found having 127.0.0.1 as part of sys.ip_addresses more of an
annoyance than useful. Are you using this, or would you like to see it go?

Please leave a comment here or at the pull request [1] if you have an
opinion. This will not be changed in the 3.6 branch in any case.

Thank you.

[1] https://github.com/cfengine/core/pull/1854

--

Eystein

Neil Watson

unread,
Jul 18, 2014, 7:58:15 PM7/18/14
to <help-cfengine@googlegroups.com>
I've never used the loopback address in CFEngine.

--
Neil H Watson
Compliance reporting with CFEngine Community http://evolvethinking.com/products/delta-reporting/
Simplify CFEngine with EFL http://evolvethinking.com/evolve-thinkings-free-cfengine-library/
VIM and Cfengine https://github.com/neilhwatson/vim_cf3
CFEngine support and training from Evolve Thinking, http://evolvethinking.com

Marco Marongiu

unread,
Jul 19, 2014, 8:49:48 AM7/19/14
to help-c...@googlegroups.com
I would rather leave it as it is or make it pedantic and actually have
*all* of addresses that are defined on the host in sys.ip_addresses.

The reasoning behind the statement above is a bit complex, I'll try to
summarize it in short below.

On the surface, it looks like:

* as far as we know, the loopback interface has address 127.0.0.1,
therefore we can assume it's always there (unless proven different) and
remove it from sys.ip_addresses

BUT

then we could go one step forward and argue that, actually, all
addresses in the range 127.0.0.0/8 are loopback addresses and may be
safely ignored, right?

BUT

then you have debian and derived systems that point to the local machine
using 127.0.1.1, which then comes to be something more meaningful than
just loopback.

And there may be other BUTs that I just can't see at the moment. Which,
in the end, makes me think: assume nothing, give me all of the
addresses, I'll sort it out myself. There are enough functions in 3.6 to
help filtering out unwanted addresses.

Another solution would be having a separate list with all the loopback
addresses filtered out. That would be much more useful than just wiping
them off from sys.ip_addresses.

Ciao
-- bronto

Nick Anderson

unread,
Jul 19, 2014, 11:20:22 AM7/19/14
to Marco Marongiu, help-c...@googlegroups.com

I have never been bothered by its existence. I might have used it once or twice but not recently.
I don't know what we gain by removing it. A few bytes of memory, and some extra magic that makes some special address ranges not appear in the interface list.

I think I would prefer to have all IPs and use filter(). There is WORKDIR/inputs/ignore_interfaces.rx that you could also use, kind of hard to find in the docs, just a small mention in the hard class documentation. https://docs.cfengine.com/latest/reference-classes.html#hard-classes

Anyone have a suggestion where it should be documented? I was looking for it in common control.

Anyway, I'd leave it given the choice, I prefer the more complete information.

--
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 help-cfengin...@googlegroups.com.
To post to this group, send email to help-c...@googlegroups.com.
Visit this group at http://groups.google.com/group/help-cfengine.
For more options, visit https://groups.google.com/d/optout.

Stephen Jones

unread,
Jul 20, 2014, 8:47:12 AM7/20/14
to help-c...@googlegroups.com
On the point regarding ignore_interfaces.rx

Is it not odd to have this in inputs? For me this makes it pretty useless as I purge everything in there in update_policy and as all most of my hosts have differing network setups so I can't manage this file? I'd like to exclude some bonds as the cfengine reports often come from private addresses in the subject. Guess I could template it... Somewhere like state would be a more suitable location for me?

Thoughts?

Mark Burgess

unread,
Jul 20, 2014, 9:10:12 AM7/20/14
to help-c...@googlegroups.com

Since the file is an input, and it is not state this makes no sense.

If you purge everything in inputs, I think you have made a decision that is causing you trouble. Perhaps you should reconsider this rather brutal option? Alternatively, CFEngine makes it very easy for you to exclude files from a purge.

M

Stephen Jones

unread,
Jul 20, 2014, 8:41:49 PM7/20/14
to help-c...@googlegroups.com
If purging policy inputs is considered brutal then why is it an option in the default cfengine policy?

body copy_from u_rcp(from,server)
{
      source      => "$(from)";
      compare     => "digest";
      trustkey    => "false";

    !am_policy_hub::

      servers => { "$(server)" };

    cfengine_internal_encrypt_transfers::
      encrypt => "true";

    cfengine_internal_purge_policies::
      purge => "true";

    cfengine_internal_preserve_permissions::
      preserve => "true";
}

I've tried without success to get a copy_from with purge enable from deleting files that do not exist at the source regardless of what is present in a file_select. Can you provide an example?

Bas van der Vlies

unread,
Jul 21, 2014, 3:25:51 AM7/21/14
to Stephen Jones, help-c...@googlegroups.com
Stephen I also use the “purge” option for the inputs directory. To exclude the file from deleting it is a bit weird.
You have to create the file in your directory where you copy from, eg:
* vi ignore_interfaces.rx
* I always put this sentence in it: Only a placeholder else the file will be deleted

Exclude the file in copy_from with file_select:
* "exclude_file" slist => { “ignore_interfaces.rx" };
* file_select => ex_list("@(exclude_file)"),

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 help-cfengin...@googlegroups.com.
> To post to this group, send email to help-c...@googlegroups.com.
> Visit this group at http://groups.google.com/group/help-cfengine.
> For more options, visit https://groups.google.com/d/optout.

---
Bas van der Vlies
| Operations, Support & Development | SURFsara | Science Park 140 | 1098 XG Amsterdam
| T +31 (0) 20 800 1300 | bas.van...@surfsara.nl | www.surfsara.nl |





Ted Zlatanov

unread,
Jul 21, 2014, 11:57:29 AM7/21/14
to help-c...@googlegroups.com
On Sun, 20 Jul 2014 17:41:49 -0700 (PDT) Stephen Jones <stephen...@gmail.com> wrote:

SJ> If purging policy inputs is considered brutal then why is it an option in
SJ> the default cfengine policy?

(changing topic)

Because many people wanted an easy way to do it. It's off by default,
reflecting the official usage recommendation.

It's worth noting that bootstrapping a host will essentially "rm -rf"
the inputs. That has surprised me in the past.

Ted

Eystein Måløy Stenberg

unread,
Jul 21, 2014, 12:25:52 PM7/21/14
to help-c...@googlegroups.com
Just a bit of context: this was primarily started due to reporting
clarity. Having all nodes report 127.0.0.1 as their IP detracts more
than it adds, it seems.

A new, separate list w/o loopback makes sense - more generic and
definitively more backward-compatible.

Any opinions on a reasonable name? sys.ip_addresses_noloopback,
sys.ip_addresses_remote? What's the opposite of loopback? :)

Thanks for the feedback, very helpful.

On 19/07/14 08:20, Nick Anderson wrote:
> I have never been bothered by its existence. I might have used it once
> or twice but not recently.
> I don't know what we gain by removing it. A few bytes of memory, and
> some extra magic that makes some special address ranges not appear in
> the interface list.
>
> I think I would prefer to have all IPs and use filter(). There is
> WORKDIR/inputs/ignore_interfaces.rx that you could also use, kind of
> hard to find in the docs, just a small mention in the hard class
> documentation.
> https://docs.cfengine.com/latest/reference-classes.html#hard-classes
>
> Anyone have a suggestion where it should be documented? I was looking
> for it in common control.
>
> Anyway, I'd leave it given the choice, I prefer the more complete
> information.
>
> On Jul 19, 2014 7:49 AM, "Marco Marongiu" <bront...@gmail.com
> <mailto:bront...@gmail.com>> wrote:
>
> I would rather leave it as it is or make it pedantic and actually have
> *all* of addresses that are defined on the host in sys.ip_addresses.
>
> The reasoning behind the statement above is a bit complex, I'll try to
> summarize it in short below.
>
> On the surface, it looks like:
>
> * as far as we know, the loopback interface has address 127.0.0.1,
> therefore we can assume it's always there (unless proven different) and
> remove it from sys.ip_addresses
>
> BUT
>
> then we could go one step forward and argue that, actually, all
> addresses in the range 127.0.0.0/8 <http://127.0.0.0/8> are loopback
> addresses and may be
> safely ignored, right?
>
> BUT
>
> then you have debian and derived systems that point to the local machine
> using 127.0.1.1, which then comes to be something more meaningful than
> just loopback.
>
> And there may be other BUTs that I just can't see at the moment. Which,
> in the end, makes me think: assume nothing, give me all of the
> addresses, I'll sort it out myself. There are enough functions in 3.6 to
> help filtering out unwanted addresses.
>
> Another solution would be having a separate list with all the loopback
> addresses filtered out. That would be much more useful than just wiping
> them off from sys.ip_addresses.
>
> Ciao
> -- bronto
>
> --
> 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 help-cfengin...@googlegroups.com
> <mailto:help-cfengine%2Bunsu...@googlegroups.com>.
> To post to this group, send email to help-c...@googlegroups.com
> <mailto:help-c...@googlegroups.com>.
> Visit this group at http://groups.google.com/group/help-cfengine.
> For more options, visit https://groups.google.com/d/optout.
>
> --
> 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 help-cfengin...@googlegroups.com
> <mailto:help-cfengin...@googlegroups.com>.
> To post to this group, send email to help-c...@googlegroups.com
> <mailto:help-c...@googlegroups.com>.

Ted Zlatanov

unread,
Jul 21, 2014, 2:29:05 PM7/21/14
to help-c...@googlegroups.com
On Mon, 21 Jul 2014 09:25:45 -0700 Eystein Måløy Stenberg <eystein.mal...@cfengine.com> wrote:

EMS> Any opinions on a reasonable name? sys.ip_addresses_noloopback,
EMS> sys.ip_addresses_remote? What's the opposite of loopback? :)

How about:

"if_wanted" slist => getinterfaces("-loopback", "up", "running", "ipv4");
"flags" slist => getinterfaceflags("en0:0");
"addresses_wanted" slist => getaddresses(if_wanted);

IOW, make the interface name the primary key for network discovery and
provide functions to discover facts instead of trying to do everything
on startup (inventory modules can do that, if wanted by the user)[1]

Ted

[1] in trainings, I had a Mac OS X laptop running VirtualBox hang for
several minutes while cf-agent was discovering that some bridged address
was invalid. Every time it ran.

Dimitrios Apostolou

unread,
Jul 21, 2014, 3:49:36 PM7/21/14
to help-c...@googlegroups.com
On Mon, Jul 21, 2014 at 8:28 PM, Ted Zlatanov <t...@lifelogs.com> wrote:
[1] in trainings, I had a Mac OS X laptop running VirtualBox hang for
several minutes while cf-agent was discovering that some bridged address
was invalid.  Every time it ran.

There are a lot of name lookups over all interfaces address. I've been flirting with the idea of removing them, but possible breakage is holding me back.


Dimitris

Reply all
Reply to author
Forward
0 new messages