![]() Now we’re going to define the ports to block (see Figure 1):Įnter “536, 537†(without the quotes) under the Port field Open Server Admin from /Applications/ServerĪuthenticate to the server you are configuringĬlick on Firewall under the Computers and Servers ListĬlick on the Start Service button in the toolbar of Server Admin If you need to restore this later you can drag the file back over to the Server Admin screen.įirst we’re going to enable Firewall (ipfw): When you see the + icon let go of the icon and it will save the service settings. To do this, drag the small icon in the lower right-hand corner of the firewall service screen to the desktoop. Also, be sure to backup the service settings before making any changes. Also try to make sure that you do this stuff while you have the opportunity for a little down-time as you might need a little time to troubleshoot. The last thing you want to do is block yourself from being able to ARD or SSH into a system you are trying to administer. There are many different ways to do this (including using managed switches) but this way has been working for us.ĭISCLAIMER : Be very careful playing with the firewall on a headless server. Another way to accomplish this might be to block all traffic for metadata for the network range of 192.168.50.x. We are going to focus on blocking outgoing traffic for Xsan on the production IP. If metadata goes over the 192.168.50.x network then it will likely cause issues, so our goal throughout is going to be blocking metadata traffic on 192.168.50.5. The IP address of our metadata controllers metadata IP is 10.0.0.5. Through this entire article we are going to assume that the IP address of our metadata controllers production IP is 192.168.50.5. Once we step through this using Server Admin we will explain the same thing using the configuration files which should help users of old versions of Mac OS X Server or of Mac OS X Workstation. This example assumes that you are using Tiger Server for your metadata controller. Here is an example of how to do this using ipfw. A fix to get around this issue for these systems is to block metadata traffic on the production network interface. This doesn’t always work, and selecting a network controller to use is not an available option with Xsan clients and older versions of the Xsan software. This can be done by:Ĭlick on the Xsan listed under SAN ComponentsĬhoose the network controller you would like to connect using One way to fix this for metadata controllers is to choose the network adapter that you would like to use on the metadata network in Server Admin. We see this in many configurations and it can cause dropped packets, unmountable volumes and other intermittent issues. Namely that Xsan will attempt to use the corporate network for connectivity with clients. For systems that are obtaining directory information or need to be wired into the corporate network of many organizations this can cause issues. Xsan requires a dedicated ethernet network in the supported architecture by Apple.
0 Comments
Leave a Reply. |