After running a provided setup script on our Fedora server, we switched back to Windows, where, from our test workstations MMC, we used an InterStructures snap-in to join the Fedora system to our domain. We hit the first snag in testing while creating a share on our Linux box. It turns out that SELinux (Security-Enhanced Linux), the mandatory access control system thats enabled by default on Fedora 4, was the source of our conflict, and we had to disable SELinux enforcement (a pitfall that the InterStructures product documentation neglected to mention).Windows overtakes Unix in revenues and Linux moves into third place in the server market. Click here to read more.After all this, however, we sailed fairly smoothly through installing, configuring and managing from Windows a handful of other services running on our Fedora system. For instance, we transferred the DHCP-serving duties on our small network from Windows Server to Fedora without a hitchand without leaving the point-and-click niceties of the MMC. The InterStructures DHCP module offered us most of the same configuration options and features as Windows Server 2003s built-in DHCP service, and these options were organized in more or less the same way. Although our configuration was a very simple one (our Fedora DHCP config file was only 10 lines long), we appreciated not having to brush up on our config file syntax to produce it. To test InterStructures Apache management tool, we installed Apache and MediaWiki on our Fedora box. From our Windows XP MMC outpost, we were able to switch our Web servers default directory from the standard "html" to "mediawiki," where the files for the Web application are served. All connections between InterStructures-enabled Linux servers and the Windows machines that manage them are carried out over SSL (Secure Sockets Layer) encrypted connections. This is good, but, in future versions of the product, wed like to see a tighter authentication scheme. For example, certain operations required the usual sorts of authentication credentials, such as a domain admin password for joining a Linux box to the domain. In other cases, though, such as when we set out to manage our Apache Web server, we were prompted for the Linux machines root password. Particularly when Active Directory is around to organize things, wed like to see a more unified setup for authentication. Wed also like to see an InterStructures module for administering system updates on the Linux boxes managed by the product. Network-facing components like the ones that QCDs wares are meant to manage frequently undergo security updates, and it stands to reason that the same Windows administrators whom these modules mean to shelter from direct interaction with Linux should have a similarly MMC-based means of managing updates. Along similar lines, wed like to see QCD provide software repositories that work with the update tools native to supported distributions, such as Fedoras yum, SUSEs YOU (Yast OnlineUpdate) and Red Hats up2date. For the version of Fedora that we tested, the default distribution packages for Samba, Squid, et al. worked just fine with the InterStructures modules. However, for some module/component combinations, the documentation noted that different versions of these components would be required. We could download these packages directly from QCDs site, but distro-native repositories would have made things friendlierparticularly for uninitiated admins. Whats more, while we were able to update managed packagesSamba, specificallyduring our tests without fouling our management setup, QCD could find that future distribution updates might interfere with the operation of its services. In such a case, ensuring that packages from QCDs own repository take precedence could help prevent service outages for users. Next page: Evaluation Shortlist: Related Products.