I am reporting a number of problems with the ebuild for the Courier mail server. Together, they make it a very ugly and unreliable exercise to move an existing Courier installation from another distro to a Gentoo system, no matter how small or basic the installation. From this point on I will refer to the correct installation instructions at http://www.courier- mta.org/install.html as the 'standard install. 1) There are way too many init.d scripts, and these do not honour the flags set in the /etc/ courier config files. The standard install provides a single init.d script which checks certain flags to determine which modules to start. The package was designed to be configured in a certain way. Please don't break it by trying to be too clever. 2) The standard install will place the entire Courier package into a well organised single directory, rooted at /usr/lib/courier. This tree is self-contained and can be easily copied from machine to machine with very little maintenance. By browsing this tree it is easy to discover the wide range of utilities related to Courier. Conversely, in an effort to adhere to standards, the Portage install will scatter the Courier files in various places on the hard disk, mixing Courier's binaries with those of other packages. Please keep stuff together, and if you really _must_ put things in the 'standard' paths, just install sym links. 3) The standard install docs highlight the need to unpack the tarball as a non-root user. Although there is a configuration flag provided to override this, I have seen a number of people requesting assistance in #gentoo because some things were not functioning. I have been able to help these people by diagnosing that the file permissions on certain items were incorrect - a side-effect of unpacking the tarball as root. Portage really needs the ability to unpack/make packages as a non-root user. By deviating from the recommended installation, the ebuild installation makes it harder for users to obtain support from the package author. He quite rightly gives more attention to those people who have followed his instructions carefully, and will often tell people to go back and install as-per his instructions before he can provide assistance. The strict adherance to whatever standards Gentoo follows, although admirable in theory is a royal PITA when these standards are not widely enforced by other distros. I moved my mail server from RedHat to mabdarke in an hour, It will take at least a week to move it to Gentoo, and even then I would have little confidence in it working as before. As an aside. Apple made the mistake of trying to conform when they changed httpd.conf to apache.conf. The result was many hundreds of complaints from long term Apache users. OS X now follows the de-facto standard and everyone is happy. As nobody else seems to follow the documented standards followed by Gentoo, I would suggest that if you must change things, create a better standard.
1) init.d scripts - If our init.d scripts lack functionality or are confusing to setup please let me know how they are confusing or lacking needed features. AFAIK the scripts allow great flexibility for the enabling/disabling of portions of the server. I use courier-imap at one of my employers and having things split out to courier-{imapd,imapd-ssl,pop3d,pop3d-ssl) is nice for the purpose of selectively enabling and disabling support for protocols without taking the whole enchilada down. 2) All files under /usr/lib/courier - This break FHS/LSB compliance and Gentoo is making every attempt to follow these standards. If we changed our standards for the way every package chose as it's default install we would have a very disorganized distribution. Thanks to the FHS/LSB we can follow a nice regulated set of rules for placement of software binaries, libraries, docs, etc... While this makes some of the instructions by MrSam irrelevant or incorrect for Gentoo, with small modifications they can still be followed. We haven't eliminated key files, we have just expanded upon or moved them from their default non-FHS-compliant location. If you have a specific problem with getting courier setup, please let me know and I will point you in the right direction. If you see where documentation is specifically needed to get over some confusing setup procedures, please tell me where these problem areas are and I will attack them one at a time. :) 3) non-root unpack/configure - Can you please reference a post/chat/convo that shows where a non-root compile is "needed" ??? Being as there is a configure option for doing a root unpack/configure (--disable-root-check) I would assume that it is an acceptable method for setting up courier. If there was no configuration option for disabling that check and a non-root unpack/configure was forced then I would see the reason. There are no other programs currently in gentoo (that I know of) which require a non-root unpack/configure. If it is a serious security risk that the ebuild doesn't address, please let me know what is vulnerable. I look forward to your responses.
Are you still around Tim?
The configuration option: --enable-mimetypes=/etc/apache/conf/mime.types \ implies a dependency on apache -- I don't see one. I also absolutely disagree that courier should depend on apache, thus, I propose *one* of the following alterations: 1. Include a mime.types file, placed in /etc/courier perhaps, and reference that. 2. create a 'mime-types' package, which provides the canonical Gentoo mime.types file, which then Boa, Apache, thttpd, courier, and many other packages could all depend on without providing their (all difference) versions.
I had a few problems installing courier: >>> Merging net-mail/courier-0.39.3 to / /usr/sbin/ebuild.sh: cd: /var/tmp/portage/courier-0.39.3/image//usr/share/courier: No such file or directory changing Maildir in imapd to .maildir sed: can't read imapd: No such file or directory changing Maildir in imapd-ssl to .maildir sed: can't read imapd-ssl: No such file or directory changing Maildir in pop3d to .maildir sed: can't read pop3d: No such file or directory changing Maildir in pop3d-ssl to .maildir sed: can't read pop3d-ssl: No such file or directory /usr/sbin/ebuild.sh: cd: /var/tmp/portage/courier-0.39.3/image//usr/sbin: No such file or directory mv: cannot stat `imapd': No such file or directory mv: cannot stat `imapd-ssl': No such file or directory mv: cannot stat `pop3d': No such file or directory mv: cannot stat `pop3d-ssl': No such file or directory /usr/sbin/ebuild.sh: cd: /var/tmp/portage/courier-0.39.3/image//etc/courier: No such file or directory cp: cannot stat `*.dist': No such file or directory cp: omitting directory `etc' cp: omitting directory `usr' chown: failed to get attributes of `ldapaliasrc': No such file or directory changing imapd-ssl: COURIERTLS to /usr/bin/couriertls sed: can't read imapd-ssl: No such file or directory changing authdaemonrc: authmodulelist to authpam sed: can't read authdaemonrc: No such file or directory changing authdaemonrc: version to authdaemond.plain sed: can't read authdaemonrc: No such file or directory grep: esmtpd: No such file or directory adding parameter ##NAME: BOFHBADMIME:0 to esmtpd sed: can't read esmtpd: No such file or directory grep: esmtpd-ssl: No such file or directory adding parameter ##NAME: BOFHBADMIME:0 to esmtpd-ssl sed: can't read esmtpd-ssl: No such file or directory grep: esmtpd-msa: No such file or directory adding parameter ##NAME: BOFHBADMIME:0 to esmtpd-msa sed: can't read esmtpd-msa: No such file or directory changing Maildir in courierd to .maildir sed: can't read courierd: No such file or directory --- /etc/
Please check out bug #10011 There is a new ebuild in portage. If you would test this new version and comment on that bug I would appreciate it.
courier-0.40.1 is in portage. Please let me know if you still have installation problems.
Tim, are you still around?
Nick, I believe Tim might be referring to one of my own complaints with his #1. When I start /etc/init.d/courier, the depend tells it to start all of the modules listed, including courier-pop3d and courier-pop3d-ssl. Ideally starting courier would only start the modules it would actually use, as the standard install does. Perhaps an entry in conf.d would be the correct way to take care of this? I simply commented out the last two items in the need list, though this is probably not the best way....
Yes. I'm still here, but I have been working night and day to meet some impossible deadlines for a January trade show and just haven't had the chance to even boot my Gentoo box for over a month. My point about the init.d scripts is that Mr.Sam already provided a mechanism for determining which modules should be loaded, and it's a very good method. Please honour it. I sent you a copy of his init.d script and it should be a simple matter to adapt it for Gentoo. If you stick to his method then it becomes easier to copy the courier /etc directory from another installation and have it just work. Many users (including myself) simply won't migrate their mail server to Gentoo if they have to spend weeks validating the installation to ensure that alll the right modules are loaded in the right order. Please stick to the standard way of managing Courier. If you want to provide your 'split' init.d scripts that's fine - put them in another optional ebuild, courier-init-tools for example. With regard to the root unpack/build, I am not sure exactly what the --disable-root-check option does, as it's a long time since I even built courier now. However, conventional wisdom has always been to do NOTHING as root that can be done as a non-privileged user - that is common sense. Installation is the only task that may (will) require root privileges. In that respect this is not a problem unique to the Courier ebuild, but with Portage in general. My experience with Courier however is what alerted me to the problem. I don't know if there is already a feature request active for non-root ebuilds. If not, there soon will be. When I get this workload out of the way I'll get back to Gentoo. -- Tim
Calendar in courier broken? I can't get the calendar to work. pcpd appear to be started, and can be started with pcpd start. (From the right directory) However, logging in through the webmai gives me "501 Operation not permitted" error, when I try to connect to the calendar.
As I remember I had some similar problems with the calendar. I have no idea how I fixed this, but I have it working now. Check permissions is all I can really tell you... Make sure you have the right directories in your home directory for the maildir that holds the calendar info. It ended up being different from my real mail directory for me. I gave up and let it have its way :)
Please check out courier-0.41.0 which has recently been added to portage.
Created attachment 8645 [details] Standard Courier init.d script This script honours the settings in /etc/courier config files.
I apologise for being so quiet for such a long time - I have had to commit my self fully to a contract and have not had a chance to look at this for several months. Anyway, I just emerged Courier again, and guess what? I got ELEVEN init.d scripts! Furthermore, When I try to rc-update, I get this: * Caching service dependencies... * NEED: can't find service courier-filterd needed by courier-mta; This is still broken. I have attached (I hope) the single init.d script distributed with Courier for your perusal.
same courier-filterd problem, can be solved by removing courier-filterd from the init script dependancies, doesnt break anything afaics
Am I to assume that as there has been no response to this topic, and that as the ebuild is six months behind the current version, that this ebuild is low-priority? Oh well. Who needs an imap server on linux anyway? <sigh>
I agree, this ebuild is awfully build, something isn't right at all. If i use the same parameters to configure the vanilla sources myself, it works whereas the ebuild fails ! Steph
if someone can contribute an updated ebuild for courier, I can at least pop it into ~x86. I know nothing of courier, so I am relying on your respective expertises.
courier-0.42.2 is on it's way into portage which will fully take in all available features of the courier package. As far as following the courier install docs verbatim and installing to Mr. Sam's chosen location, I'm sure that won't happen. I have been looking into other linux distributions and FreeBSD and none appear to follow them verbatim. I am confident that we will have a fully-featured and easy-to-configure package in portage with this release. I will post here again once the new version is in portage.
courier-0.42.2 is now in portage.
Oh the frustration! I have installed the latest ebuild on my test server and am *STILL* trying to migrate from my Mandrake box (it went from RH to Mandrake in 10 mins - no hitches). Ther are still way too many init.d scripts. If you go the simple route and type /etc/ init.d/courier start, it starts up all the sub-modules. /etc/init.d/courier stop will leave all the additional modules running. This is broken. PLEASE adapt the single init.d script that honours the settings in the config files in /etc/courier. Many of the settings in the confiig scripts have default values decided at build time. These have not been changed in the config scripts, and are either misleading or wrong. As a result of the re-organisation of Courier's directory structures, manny settings which store paths apparently default to the original values in /usr/lib/courier... As a result of changes for FHS compliance, these are wrong. If you insist on changing defaults, you must change everything (which makes for a horrible migration experience). P.S. The Courier config files still use the default ~/Maildir for mail delivery. /etc/skel provides ~/.maildir. Please fix one or the other
Correct me if i am wrong, but the .maildir is just the Gentoo default, don't ask me why, i personaly use : ./Maildir Steph
bugzilla playing tricks with us