zachfi / puppet-bsd

A Puppet module for BSD
Apache License 2.0
9 stars 11 forks source link

route does not get set on FreeBSD #121

Open da125 opened 6 years ago

da125 commented 6 years ago

Hello,

I'm trying to set a static IP and default route on a FreeBSD 11.1 machine with:

class { 'bsd::network': v4gateway => '192.168.0.1' } bsd::network::interface { 'em0': description => 'Primary Interface', addresses => [ '192.168.0.37/24' ] }

on a machine the previously received and IP over DHCP.

The interesting thing that happens is that the default route gets removed but not added back again by the puppet agent run. This in turn leaves the server not accessible.

From what I can gather, it's because the routing service on FreeBSD has no "status" command and also does not need to be running. As can be seen from below, the restart is never issued.

Debug: Executing: '/etc/rc.d/routing onestatus' Debug: /Stage[main]/Bsd::Network/Service[routing]: Skipping restart; service is not running

Am I missing some option in my node definition?

zachfi commented 6 years ago

Hi, Does the gateway get set in rc.conf? I don't think we'll remove the DHCP option if you set a gateway, but I have bsd::network::v4gateway set on all my systems and I get an entry in rc.conf to match.

da125 commented 6 years ago

Hi,

I see my error. What I meant to say was that the default route in netstat -rn get's removed but not set to the one I define in bsd::network::v4gateway. /etc/rc.conf has no "defaultrouter" option when setting an interface to DHCP.

Your module does the right job in setting the "defaultrouter" option in /etc/rc.conf but when restarting the routing service, I think it fails because it first does a "status" on the rc.d script and that parameter does not exist for /etc/rc.d/routing (as can be seen from the puppet client debug output).

zachfi commented 6 years ago

I've just pushed a status branch with a change that should disable the status lookup. Are you in a position to test that branch?

da125 commented 6 years ago

Let me fire up my vm's and test; will take some time.

As long as the /etc/rc.d/routing just receives a "onerestart", I think everything should work.

da125 commented 6 years ago

Interesting enough, nothing changes. I see the same messages in the puppet agent debug:

Debug: Executing: '/etc/rc.d/routing onestatus' Debug: /Stage[main]/Bsd::Network/Service[routing]: Skipping restart; service is not running

As a very crude test, I did this:

'FreeBSD': {
  Shellvar {
    target => '/etc/rc.conf',
    notify => Exec['restart_routing']
  }

  exec { 'restart_routing':
    command     => '/etc/rc.d/routing onerestart',
    refreshonly => true
  }

And it works as long as in the manifest I specify a relation, like so:

bsd::network::interface { 'em0': description => 'Primary Interface', addresses => [ '192.168.157.133/24', '192.168.157.134/24' ] }-> class { 'bsd::network': v4gateway => '192.168.157.2' }

Yes i know, my ruby/puppet skills need a lot of work...

zachfi commented 6 years ago

The solution you've outlined makes good sense, though is there a more targeted approach that we could take to avoid any rc.conf change restarting the routing? Only route option changes would need, necessarily, to restart routing. The netif script seems to do the right thing most of the time if you're not adjusting routes.

da125 commented 6 years ago
@@ -73,7 +73,6 @@
    'FreeBSD': {
      Shellvar {
        target => '/etc/rc.conf',
-        notify => Service['routing'],
      }

      # Should we enable IPv4 forwarding?
@@ -104,6 +103,7 @@
      if $v4gateway {
        shellvar { 'defaultrouter':
          value => $v4gateway,
+          notify => Exec['restart_routing']
        }
       } else {
         shellvar { 'defaultrouter':
@@ -116,6 +116,7 @@
      if $v6gateway {
        shellvar { 'ipv6_defaultrouter':
          value => $v6gateway,
+          notify => Exec['restart_routing']
         }
       } else {
         shellvar { 'ipv6_defaultrouter':
 @@ -126,6 +127,11 @@

       service { 'routing':
       }
+
+      exec { 'restart_routing':
+        command     => '/etc/rc.d/routing onerestart',
+        refreshonly => true
+      }
     }
     default: {
       notify { 'Not supported': }

That should be better but it still requires the "->" in the manifest. Ex:

bsd::network::interface { 'em0': description => 'Primary Interface', addresses => [ '192.168.157.133/24', '192.168.157.134/24' ] }-> class { 'bsd::network': v4gateway => '192.168.157.2' }

And I think this breaks the design of the module. Maybe it makes sense to adjust it so that the defaultroute get's called last, after the last IP is set? (I checked the code but don't realize where this is happening).

da125 commented 6 years ago

any updates on this?

zachfi commented 6 years ago

Apologies for the delay. That looks like a reasonable change to me. Were you able to test that it worked as you expected?

da125 commented 6 years ago

It works but only if you run the routing after setting the IP for the interface and I think this breaks the module.

xbeaudouin commented 5 years ago

Have another issue on FreeBSD 12 :

Error: Could not retrieve catalog from remote server: Error 500 on SERVER: Server Error: no parameter named 'value' (file: /usr/local/etc/puppet/environments/production/modules/bsd/manifests/network.pp, line: 32) on Sysctl[net.inet.ip.forwarding] (file: /usr/local/etc/puppet/environments/production/modules/bsd/manifests/network.pp, line: 32) on node rprng1.prod.hotcity.lu
Warning: Not using cache on failed catalog
Error: Could not retrieve catalog; skipping run

The configuration part on my side was really simple:

class { 'bsd::network':
       v4gateway       => '10.194.57.1',
       v4forwarding    => false,
       v6forwarding    => false,
}
bsd::network::interface { 'vmx0':
       addresses => [ '10.194.57.10/24'],
}

Puppet barf itself on the forwarding stuff... I dunno why, but is there a way to ignore it ?

Regards

zachfi commented 5 years ago

All my hardware is on 12 and I'm not seeing this. Which version of the module are you running @xbeaudouin? This seems like a different issue than the OP.