On Wed, 27 Aug 2003, William O'Shea wrote: > You only have to get the config file right once and > it would stay that way through any upgrade.
Actually, that isn't true; or rather, that has historically not been the case with imapd. There is an unsupported config file capability. There is a way through that unsupported config file that you can set a subdirectory of the UNIX home directory as the user's IMAP home directory. However, doing so is at your own risk. It is possible that you could install an update and it will break. Such episodes have happened in the past. There are implications to setting the directory that imapd uses to other than the UNIX home directory. Some people do so anyway, in spite of my advice against doing so. As a courtesy the documentation suggests a possible patch to accomplish it. But it's still at your own risk. Whenever you deviate from what is supported by the developer, you take this risk. The developer may know about what people are doing, and make strenuous efforts to avoid breaking their unsupported local changes when he releases an upgrade. But sometimes unexpected consequences happen. > If I have > to change the source file each and every time an upgrade > or patch comes out, then I can get it wrong each and > every time. This sounds like open source may not be the best choice for you, and that you should consider other options. I'm not being sarcastic. Open source is not the right solution for everyone. The main motivation behind open source is that the end user can review what is in an upgrade, and thus make intelligent decisions about the upgrade vis a vis local modifications (and their potential impact). It also permits the developer to disclaim support for local modifications. Closed source, such as what Microsoft distributes, is a different matter. Here, you are entirely at the mercy of the vendor; but in return you get support for all possible configurations that the vendor chooses to make available to you. You also generally pay for the privilege. I don't know what support arrangements you may have with RH. As far as I know UW doesn't get any funding from RH. If you'd like to make a donation to UW for more advanced imapd support, I could put you in touch with the right people. > Also, it completly ignores the problem of timelyness. > If I do not require a recompile, I can have RH uptodate > auto download any security patches. If I must recompile > everytime, then that required me to be available to do it. > If I'm on vacation for two, my server will be vulnerable > for those two weeks. On the other hand, if someone compromises the mechanism by which patches are auto-downloaded, then while you are on vacation your system might automatically install an intentionally vulnerable version. It's a two-edged sword. Personally, I would not think of leaving a machine running while I am on vacation unless either the machine is thoroughly firewalled or has a babysitter empowered to fix things or at least pull its plug if needed. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
