Arthur de Jong <[email protected]> writes: > Thanks for your answer. I have reworked the init script a bit to be a > little simpler. I've also renamed the variables to prefix everything > related to k5start with K5START. Please check the attached files to see > if it is still working as expected.
Not for me, the krb5_ccname may not have the TYPE: part, in this case,
it must[1] be treated as file path.
This should be better:
K5START_CCNAME=$(sed -n 's/^krb5_ccname\( *\|[^:]*:*\)\([^: ]*\) *$/\2/ip'
/etc/nslcd.conf)
which work for both "TYPE:path" and "path".
The use_sasl value is not restricted in nslcd/cfg.c, it's on as soon as
it's define, so the following may be better:
if [ -x "$K5START_BIN" ] && \
$(grep -q '^use_sasl *.\+*$' $NSLCD_CFG) && \
$(grep -q '^sasl_mech *GSSAPI$' $NSLCD_CFG) && \
[ -n "$K5START_CCNAME" ]
then
K5START_START="yes"
fi
> I've also introduced a K5START_START flag that gets enabled when a
> supported configuration is found. I think it is a little cleaner than
> erroring out on unsupported configurations.
I'm fine with tris.
> I'm not yet happy with the restart code yet (I think the log messages
> get mixed up). Perhaps some improvements can be made there?
First:
restart|force-reload)
[ -d "$NSLCD_STATEDIR" ] || ( mkdir -m 755 "$NSLCD_STATEDIR" ; \
chown nslcd:nslcd "$NSLCD_STATEDIR" )
log_daemon_msg "Restarting $NSLCD_DESC" "nslcd"
start-stop-daemon --stop --quiet --retry 10 \
--pidfile $NSLCD_PIDFILE \
--name nslcd
log_end_msg $?
[ -n "$NSLCD_PIDFILE" ] && rm -f $NSLCD_PIDFILE
k5start_stop
k5start_start
start-stop-daemon --start \
--pidfile $NSLCD_PIDFILE \
--startas $NSLCD_BIN
log_end_msg $?
;;
With this the logs looks good to me.
> Also, I'm wondering about the K5START_CCNAME option. Shouldn't that be
> K5START_CCFILE? If I understand correctly a CCNAME is something like
> "FILE:/foo/bar" while the variable currently only holds the filename
> part.
Yes, the CCFILE suffix looks better.
>> I use the following configuration:
>> use_sasl on
>> sasl_mech GSSAPI
>> krb5_ccname /tmp/nslcd.tkt
>
> Is there any reasonable configuration where you have use_sasl set to on
> but sasl_mech not set? In other words do you think I should remove the
> use_sasl option and just use SASL when sasl_mech is configured?
There is no default mechanism for SASL, so we must define it with
sasl_mech and this makes use_sasl superflous.
> Anyway, thanks for your feedback.
You are welcome ;-)
Footnotes:
[1] I'm not sure about "must"
--
Daniel Dehennin
Récupérer ma clef GPG:
gpg --keyserver pgp.mit.edu --recv-keys 0x6A2540D1
pgp0mz4ic7tSS.pgp
Description: PGP signature
