When it comes to configuration files in the underlying operating system, ClearOS tries not to get in the way. If you make a change to a configuration file, the change will either be reflected in the ClearOS interface (when it's exposed) or left alone.

Some similar products use a different approach. A common approach is to save the configuration in a custom data store (a database for example) and then rewrite configuration files using the the data store. There are certainly advantages to this type of approach, but we just feel that it gets in the way! Though it's more complicated to parse configuration files like we do in ClearOS, it's really not rocket science.

As with all rules, there are exceptions when it comes to staying out of the way. Here's an example to help you understand why we sometimes make exceptions.

The Intrusion Detection system needs to know the IP and network information for all WANs and LANs in order to tweak the way the underlying detection rules work. When an administrator adds a WAN (open source multi-WAN, baby!) or changes their LAN IP range, the Intrusion Detection needs to be reconfigured. As you can imagine, there are many apps that need to behave the same way. We don't want an administrator trudging through all the ClearOS apps looking for IP settings that need to be changed. In many cases, these underlying settings are not exposed in the web interface anyway (Intrusion Detection system included).

To help with this type a scenario, the clearsync event system was created in version 6. Sticking with our Intrusion Detection, it registers a “please let me know when the network configuration changes” event with clearsync. When this event occurs, the Intrusion Detection system will reconfigure its network settings and restart (if necessary). For the really technical folks reading along, go ahead and take a look at various events configured on your system by browsing the /etc/clearsync.d directory.

The Internet domain name is a tricky little parameter. It is used in a lot of places, but not always in a consistent manner. This is especially true on a multi-homed system where the “public/WAN” domain is example.com, but the internal “private/LAN” domain is example.lan. For example, the DHCP server will dish out a domain name for all the DHCP clients. Some administrators are fine with dishing out “example.com”, while others prefer “example.lan”.

Various parts of the mail system (Postfix, Amavis, Zarafa) all have to have the same domain information configured. In addition, the e-mail address for each user is stored on a per user basis in LDAP. Manually changing the “mydomain” configuration in the Postfix configuration is going to cause a world of hurt if the other configuration files and LDAP aren't changed with it.

For these reasons, the Internet Domain parameter is often automatically configured by ClearOS.

search?q=clearos%2C%20clearos%20content%2C%20dev%2C%20architecture%2C%20maintainer_dloper&btnI=lucky