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.
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.
I understand your use-case...its just that it's not a common one and the original design of the dynamic DNS service binds a domain to a device's hostkey...In other words, it would be a lot of work for very few people's benefit to break that 1:1 relationship and bind to something like hostkey:ethX.
I heard from Darryl and David that they were able to get you back up and running. Darryl suspects (but it is unconfirmed) that running CloneZilla Live CD may have started the array and made changes.
Your lucky day, I guess....depends on how you look at things.
Thanks for your post...I know it's the nature of forums to be asking for help, which necessitates there being a problem, but not enough people use these forums to post their positive experiences. Nice to see/hear...
The messages are located in the system MySQL database. If you're familiar with MySQL, use the access instructions.
I wrote the archiver, so you can blame me directly for the POS. We don't use it internally, so I've been reliant on feedback (mostly coming from partners and paid support or consulting) to know how it is doing in the real world.
I'm going to be rewriting parts of it when the conversion to a 6.x app is underway. I already have some thoughts on how to make it less dependent, or possibly completely independent of MySQL, which adds complexity and usually requires someone to keep an eye on things.
Almost there...there was an issue with line identification and how data array's were being constructed. If anyone following this thread can install the latest update and give me feedback on if they can reproduce any of the 'wonky' behaviour, I'd appreciate it.
