Bug 154943 - saslauthd doesn't start early enough
Summary: saslauthd doesn't start early enough
Keywords:
Status: CLOSED DUPLICATE of bug 246900
Alias: None
Product: Fedora
Classification: Fedora
Component: cyrus-sasl
Version: 10
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Tomas Mraz
QA Contact: Brian Brock
URL:
Whiteboard:
: 154947 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-04-14 22:14 UTC by Nathan G. Grennan
Modified: 2009-01-23 16:36 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2009-01-23 16:36:04 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Nathan G. Grennan 2005-04-14 22:14:03 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050322 Galeon/1.3.20

Description of problem:
saslauthd is used by postfix and other mail software like cyrus-imapd for authencation. By default saslauthd starts at 95, while postfix starts at 80, and cyrus-imapd starts at 65. This creates a time window where postfix and cyrus-imapd have started, but saslauthd hasn't. So a user tries to authenicate, but fails because saslauthd isn't avaliable. In my case I also use mysql to store mail user authencation information. mysql starts at 64, and needs be to be running before saslauthd. So I have changed /etc/rc.d/init.d/saslauthd so that it starts at 64 instead of 95. Ideally we would want enough time delay bewteen mysql and saslauthd so that mysql has time to initialize. The same is true for saslauthd and cyrus-imapd.

Ideally if mysqld, postgresql, openldap, and anything else that might use be used by saslauthd could be kept before saslauthd, along with moving saslauthd before anything that might use it like postfix and cyrus-imapd.

Version-Release number of selected component (if applicable):
cyrus-sasl-2.1.20-4

How reproducible:
Always

Steps to Reproduce:
1. Install saslauthd, mysqld, and postfix
2. chkconfig saslauthd on ; chkconfig mysqld on ; chkconfig postfix on
3. ls -al /etc/rc.d/rc3.d

Actual Results:  S64mysqld -> ../init.d/mysqld
S80postfix -> ../init.d/postfix
S95saslauthd -> ../init.d/saslauthd

Expected Results:  S64mysqld -> ../init.d/mysqld
S64saslauthd -> ../init.d/saslauthd
S80postfix -> ../init.d/postfix

Additional info:

Comment 1 Marius Andreiana 2005-05-13 09:05:02 UTC
*** Bug 154947 has been marked as a duplicate of this bug. ***

Comment 2 Marius Andreiana 2005-05-13 09:09:02 UTC
Yes, this would be useful and more setups will work out of the box.

Comment 3 Nalin Dahyabhai 2005-09-13 19:51:06 UTC
Er, that creates a circle: slapd can be configured to use saslauthd, and slapd
starts with priority of 27.  And saslauthd may be configured to consult slapd, ugh.

Comment 4 Bill Nottingham 2005-09-13 20:17:55 UTC
Yeah, not sure how you solve that loop.

Comment 5 Bill Nottingham 2005-09-13 20:18:36 UTC
Ideally, you'd move to a dynamic system, where dependencies on startup would be
automatically generated based on whether or not postfix was using saslauthd, etc.

Comment 6 Nalin Dahyabhai 2005-09-13 21:36:30 UTC
I know!  We can use tsort!

Seriously though, LSB defines Required-Start and Should-Start magic comments
which attempt to provide a way out of this mess, but without being able to pick
up cues from the current configuration, it doesn't indicate a solution, either.

Comment 9 Bug Zapper 2008-05-14 01:59:23 UTC
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 10 Bug Zapper 2008-11-26 01:47:45 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 11 Tomas Mraz 2009-01-23 16:36:04 UTC
We now have LSB headers in the init script so the saslauthd will start probably earlier. As written in earlier comments the correct order depends on concrete configuration of the services so there will probably be necessary a manual administrator intervention anyway.

*** This bug has been marked as a duplicate of bug 246900 ***


Note You need to log in before you can comment on or make changes to this bug.