Funny you should ask Phil…
I did just that yesterday after being enlightened on the capabilities of
the RT CLI. But I observed an interesting behavior - more Unix than RT
related, but it confused the crap out of my users [and me for a moment].
I’m using ‘amanda’ as a backup utility on our RT box. I had a shell
session going as user ‘amanda’ and did ‘su -’ to run the cli script.
You’d think that would at least make stuff run with the ‘root’ user
environment, wouldn’t you?
I ran an RT CLI something like this:
for user in $(< userList)
rt --create --owner=$user <…etc…>
sendmail $email@example.com < userNotification.txt
I ran this with the ‘-x’ flag on the shell invocation - and as all the
script output flitted by, I noticed that ‘sendmail’ was being invoked by
user ‘amanda’ - not ‘root’.
So the From: line in the email all the users received said “Amanda
Backup Utility” [the comment I made in the ‘amanda’ useradd] and of
course the message text had absolutely nothing to do with ‘amanda’. Just
a tad embarrassing - but I quickly sent an update email explaining the
fiasco to the users. When I see my inbox at the office this morning I’ll
have a better idea how well received THAT was…
Drew M. Mooney
Motorola Professional Services
Phil Homewood wrote:
Drew Mooney wrote:
The alternatives? Tracking newuser password changes piecemeal, and
maintaining user-related email threads offline from RT. This scheme
would keep everything RT-related on RT. It’s probably of limited
utility after the up-front flood of user-creations required by deploying
RT, but still a worthwhile endeavor I think.
Why not script something /outside/ RT? Since you’re probably
going to use the CLI to create users and assign their passwords,
why not wrap the RT CLI commands in a script that also sends the
details to the user?