Add "Connection Type" of "none" to list - ie: This would allow the ability to have an interface configured, but specify that it should NOT have an IP address. While there are probably many reasons for doing this, the most common one would be for when VLANs are configured, and one does not wish to use the base interface (ie: ethX) untagged. ie: I might wish to specify each VLAN on eth0 as tagged (ie: eth0.1, eth0.2, etc) without having eth0 itself to have an IP. This can be done by having "BOOTPROTO=none" and NOT specifying an IPADDRESS=line (and NETMASK, etc) at all.
Good idea -- added to the tracker: tracker.clearfoundation.com/view.php?id=1145
(also useful to set IPV6INIT=no and IPV6_AUTOCONF=no, but I don't do this, don't use IPv6 at all myself).
I'm sure that will be part of the IPv6 initiative in ClearOS 6. That reminds me, I need to go request my address block from my ISP!
Oh, and BTW - if you were to add the ability to stop/start an interface from web config (per my prior suggestions), I would recommend that if the user clicks this on the physical interface (ie: ethX) that also has VLANs configured (ethX.Y), that the app would warn the user that "Stopping or restarting a physical interface will stop or restart all VLANs configured on that interface. It you are accessing this webpage from one of those VLANs, this may disconnect you. Would you like to continue?"
Noted!
We've had it with the performance of the forums and are now actively looking at alternatives. 400 database queries to load the main forum page is just ridiculous! The blog software is also broken and the URL rewrite engine (sh404SEF) is a horror show. Other bits of ClearFoundation infrastructure are okay (though the translation server is sluggish too):
Our mirror system is well designed to get updates out quickly, but it suffers from two weaknesses:
- If an update fails high up on the mirror hierarchy, the mirrors further down the line are marked as "offline". This increases the load on the higher mirrors which in turn might get overloaded and taken offline. Aaaaand death spiral. That's exactly what happened a few days ago.
- For most mirrors, all you need is rsync and cron. ClearFoundation's mirrors are more complex to configure and it has been hard to convince potential mirror hosts to bit the bullet.
It's good to read that RH have done a security verification on the LS code - this suggests that the fork is being taken seriously, and (assuming they are satisfied), that the code is getting close or at 'production ready'. A few more tests and it might be appropriate to look at changing over. David.
I think being able to show the MAC address for each interface would be EXTREMELY helpful, as would (which I didn't mention before) showing the network driver name (ie: "ASIX USB Ehternet Adapter" or "r8169 Gigabit Ethernet driver", etc). This would help one to find out (without dropping to the shell or messing with network cables) which NIC actually got mapped to which device.
I added an enhancement request to the tracker: tracker.clearfoundation.com/view.php?id=1142
BTW - one question - I haven't looked at this much in COS 6.4, but do we still have to do the EXTRALANS= thing that was required in COS 5.2 to have COS route between LANS? (at the time it was in /etc/system/network, though looks like now its /etc/clearos/network.conf). This would also be nice if web admin would ask about and configure for you.
Yes, that command line parameter is still around. And yes, adding "static route manager" is on the todo list too!
The vga= line is already kludged in there. Ideally, we would patch the anaconda installer instead of doing a post-install hack. No matter, it's on the TODO list.
VLAN support was added to the Network - IP Settings page in ClearOS. This should be considered beta at the moment, but you can give it a try with the following commands:
Unlike virtual interfaces, VLANs are considered "first class citizens" by the underlying network API. What does that mean to the end user? VLAN interfaces:
- can be configured in the DHCP server
- appear in the Network Report
- are available in MultiWAN
- etc.
Please feel free send us feedback - bugs, suggestions, etc.
When a kernel is installed, it creates some files in /boot during the post-install routine. If this fails or is interrupted, boot problems will happen! If it is the latest kernel that is failing, try re-installing it:
Code:
rpm -e kernel-xyz # where xyz is the specific version you want to remove
yum install kernel
