<HTML>

<HEAD>

<META content="text/html; charset=iso-8859-1" http-equiv=Content-Type>

<META content="OPENWEBMAIL" name=GENERATOR>

</HEAD>

<BODY bgColor=#ffffff>

Hi Michael,

<br />

<br />Oh, I realized this dates back to the Raq days.  I've had to work around this problem with the Raqs we had, then BlueQuartz, and now BlueOnyx.  Its just never thrown in a entire 255.255.255.0 in the routing table before - claiming to own that entire /24 network.

<br />

<br />

<br />I could possibly see a situation where a different mask than 255.255.255.255 would be used - maybe if someone were using a IP out of the same subnet as the server's main IP.  So 192.168.100.10/255.255.255.0 for the server, and going up through 11, 12, 13, 14 for the virtual sites.  In that case, the 255.255.255.0 might be appropriate for the virtual site IPs.  But I'm pretty sure that even in that situation - if the virtual site IPs had a mask of 255.255.255.255, they should work.  After all, the server never initiates a out-going connection from the virtual site IP - it always uses the server's main IP when connecting outward.  And the mask doesn't matter on inbound connections.

<br />

<br />So I can't think of any drawback to a default 255.255.255.255 for all virtual sites.  Of course, we could always set the GUI's virtual site input form to have a mask field that defaults to 255.255.255.255 - and someone who desires something different can change that in the GUI.

<br />

<br />

<br />Its just that right now, I have to go through every one of the /etc/sysconfig/network-script/ifcfg-eth0:x files and change the mask and broadcast.  Then, to insure the GUI doesn't change it back - I have to set the immutable bit on those files.  And of course - then I have to change it back before deleting or making changes to any sites.  

<br />

<br />If I don't do that - the GUI takes the serveri's main IP 255.255.255.240 mask, applies it to all the virtual site IPs, and I suddenly have broadcast IPs defined in some /etc/sysconfig/network-script/ifcfg-eth0:x files that prevents me from using that IP on another virtual site.  My only option is modifying all those files and locking them, or just not using those IPs it thinks are broadcast IPs - and loosing use of valuable real-world IPs.

<br />

<br />

<br />Thanks for looking at this issue Michael.  If there is anything I can do to help, or test to help - please let me know.

<br />

<br />

<br />

<br />Chuck

<br />

<br />

<br />

<br /><font size="2"><b>---------- Original Message 

-----------</b>

<br />

From: Michael Stauber <mstauber@blueonyx.it> 

<br />

To: BlueOnyx General Mailing List <blueonyx@mail.blueonyx.it> 

<br />

Sent: Sun, 13 Apr 2014 15:34:29 -0500 

<br />

Subject: [BlueOnyx:15181] Re: Routing problems in BlueOnyx 

<br />

<br />> Hi Chuck, 

<br />> 

<br />> 

> Does anyone know why virtual sites are not automatically created with a 

netmask  

<br />> 

> of 255.255.255.255? 

<br />> 

<br />> 

That's a good point. Probably because it's been that way since the first 

<br />> 

RaQ's and Qube's. 

<br />> 

<br />> 

But it is a good question: Do we need to continue things this way? Or 

<br />> 

does anything speak against setting up extra IP's (beyond the primary 

<br />> 

one for each ethX) with the mask of 255.255.255.255 instead? 

<br />> 

<br />> 

It's trivial to change in the network handlers. But I don't want to 

<br />> 

break functionality in case anyone has good reasons why we should keep 

<br />> 

it as it is now. 

<br />> 

<br />> 

Thoughts and insights on this are more than welcome. 

<br />> 

<br />> 

--  

<br />> 

With best regards 

<br />> 

<br />> 

Michael Stauber 

<br />> 

_______________________________________________ 

<br />> 

Blueonyx mailing list 

<br />> 

Blueonyx@mail.blueonyx.it 

<br />> 

<a target="_blank" href="http://mail.blueonyx.it/mailman/listinfo/blueonyx">http://mail.blueonyx.it/mailman/listinfo/blueonyx</a> 

<br /><b>------- End of Original Message 

-------</b>

<br />

</font>

</BODY>

</HTML>