4

I'm currently playing with chef to evaluate whether or not such a configuration tool might help us in our *nix-based environment.

For the last few days I'm struggling with one problem I can't find a solution for. Basically, I have 2 private network ranges 192.168.1.0/24 and 192.168.2.0/24. There is a Server (Ubuntu 14.04.4 LTS) having access to both networks (192.168.1.1/24 on em1 and 192.168.2.1/24 on em2) which is running the chef-server.

As far as I understand, chef will listen on the interface which has the default route configured for (here 192.168.1.1 on em1). However, I want chef to watch over the servers on both networks.

When I bootstrap to Servers on 192.168.2.0/24, the client gets installed but there is no response from the client because the server calls itself 192.168.1.1 which is not visible to 192.168.2.0/24 (after all it's just a common subnet).

Is there a way to let chef listen on both interfaces (e.g. something like 'listen on 0.0.0.0/0')? I've searched the whole net but only found solutions for the underlying services like bookshelf. Do you have any advice on how to realize the configuration management in such an environment?

Greetings Kenneth

0

No answers after 2 weeks so I expect, there is no "simple" way of achieving the goal.

I want to share my ideas of how my "workaround" looks like. Maybe it'll help those facing a similar problem.

  • Subnet A: 192.168.1.0/24
  • Subnet B: 192.168.2.0/24
  • Subnet C: 192.168.3.0/24

I added a new, separate subnet (C) which is kinda like a dmz (Because of the content it is none, but I hope you'll get the idea). Afterwards, I created policies for shorewall, which grant routing from Subnet A and B to the newly created C but not backwards. This way, the chef-clients from both networks, A and B, are able to connect to the chef-server in C but A and B are still not allowed to communicate with each other. Furthermore C is not allowed to contact systems behind A and B, so even if someone hijacks A or B, he does still have problems accessing the other subnets. Though this'll make adding new nodes a bit more complex, it's still quite easy (e.g. writing a general script installing chef-client and connecting it to the server or using a local version of 'knife').

Here's the (simplified) policy file currently in use by shorewall:

#SOURCE         DEST            POLICY             LOG LEVEL        LIMIT:BURST
$FW             A               REJECT             
$FW             B               REJECT             
$FW             C               REJECT             

A               $FW             DROP             
A               B               REJECT             
A               C               ACCEPT             

B               $FW             DROP             
B               A               REJECT             
B               C               ACCEPT             

C               $FW             DROP             
C               A               REJECT             
C               B               REJECT             

# THE FOLLOWING POLICY MUST BE LAST
all             all             DROP             info

After all, this is not the solution I was searching for. Nevertheless, the more I think about it, the more I like this solution because there are no additional bridges besides the firewall itself and we are able to deploy software which may be useful in both subnets too (e.g. RabbitMQ).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.