diradm fails to create a user. Reproducible: Always Steps to Reproduce: # diradm useradd -p calisse twitt Actual Results: /usr/libexec/diradm.user.sh: line 64: [: : integer expression expected Expected Results: User created successfully No need to go over this again: 14:38 <kyron> set -x output of /usr/libexec/diradm.user.sh useradd() http://pastebin.ca/1049346 14:38 <robbat2> hmm 14:38 <robbat2> here's a fixup 14:38 <robbat2> flip lines 62, 63 14:38 <robbat2> and in front of the UIDNUMBERMIN assignment 14:38 <robbat2> do 14:38 <robbat2> [ -z "${UIDNUMBER}" ] && UIDNUMBER="${UIDNUMBERMIN}" 14:38 <robbat2> so the new block reads: 14:39 <robbat2> else 14:39 <robbat2> UIDNUMBER="$(usernextfreeuid)" 14:39 <robbat2> [ -z "${UIDNUMBER}" ] && UIDNUMBER="${UIDNUMBERMIN}" 14:39 <robbat2> if [ "${UIDNUMBER}" -gt "${UIDNUMBERMAX}" ]; then 14:40 <kyron> that's rather weird since I _was_ able to create another user earlyer on... hmmm... 14:41 <robbat2> it's a bug anyway in my code 14:41 <kyron> k 14:41 <robbat2> i should definetly check that it's not null from usernextfreeuid
Created attachment 158975 [details] This is the patch to correct the problem.
While at it, I vote for a change of defaults in diradm.conf so that they reflect the same ones as usually seen on a Gentoo machine. In /etc/diradm.conf, change the two following configs to default to: HOMEBASE="/home" DEFAULT_LOGINSHELL="/bin/bash"
2.9.5 in the tree now, with a much better fix, that actually generates better UIDS in all cases, even when the LDAP already has ~300 users in it. It's the only change between 2.9.3 and 2.9.5.