Re: Domino, scheduler and root id
Steve,
When I ran into this, it only occured after the password expiration time
was exceeded. Is this the case for you as well? If so, set password expiration
to "0", and the password file to the Domino user and group ID, and all should be
fine (works here anyway). Scott
Steven Harris
<[EMAIL PROTECTED]
.INFO> To
Sent by: "ADSM: ADSM-L@VM.MARIST.EDU
Dist Stor Manager" cc
<[EMAIL PROTECTED]
DU>Subject
[ADSM-L] Domino, scheduler and root id
08/10/2005 08:46 PM
Please respond to
"ADSM: Dist Stor
Manager"
<[EMAIL PROTECTED]
DU>
Hi All,
AIX 5.2, TSM Server 5.2.0.0 (working on an upgrade), Client 5.2.0.0, domino
client 5.1.5.0, domino 6.5.4
My predecessor set up this environment using AIX srcmgr facilty to run a dsmc
sched process for each domino instance - there are 8 on this machine, and they
run under the root id. The domino instances themselves have a different unix id
for each instance. Each instance is logically separate with its own file
systems, domino binaries and a tsm directory that contains domdsm.cfg, dsm.opt,
logs and a security directory containing the TSM.PWD file for the instance. We
can literally export a couple of volume groups and import them elsewhere to
move a domino instance to another AIX lpar.
Domino backups are scheduled using a command schedule, and in the script the
backup is run under the unix ID for the instance.
The problem is that when PASSWD GENERATE does its thing, the TSM.PWD file is
deleted and re-created with the new password. This is done by the scheduler
process and so the new TSM.PWD file has root ownership. Thus the backups fail
as they can't access the new encrypted password.
So, I've tried to fix this by running dsmc sched as the domino user, but I get
ANS1817E Schedule function can only be run by a TSM authorized user.
I've set up a TSM admin with node ownership, and I can run dsmc command line as
the domino user, but not the scheduler. dsmcad won't work either.
Is there any solution other than running everything as root or resorting to
cron? I'd like to domino admins to be able to check logs and don't want them
to have root access, but using separate users also has nice safeguards when it
comes to restoring in the right environment.
TIA
Steve
Steve Harris
AIX and TSM Admin
Sydney, Australia
Re: Domino, scheduler and root id
Hi Steve Check the USER option in the client guide. I think it will help. Guillaume Gilbert Storage Architect 514.866.8876 Office 514.866.0901 Fax 514.290.6526 Cellular [EMAIL PROTECTED] StorageTek Canada Inc. INFORMATION made POWERFUL -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Steven Harris Sent: August 10, 2005 21:47 To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] Domino, scheduler and root id Hi All, AIX 5.2, TSM Server 5.2.0.0 (working on an upgrade), Client 5.2.0.0, domino client 5.1.5.0, domino 6.5.4 My predecessor set up this environment using AIX srcmgr facilty to run a dsmc sched process for each domino instance - there are 8 on this machine, and they run under the root id. The domino instances themselves have a different unix id for each instance. Each instance is logically separate with its own file systems, domino binaries and a tsm directory that contains domdsm.cfg, dsm.opt, logs and a security directory containing the TSM.PWD file for the instance. We can literally export a couple of volume groups and import them elsewhere to move a domino instance to another AIX lpar. Domino backups are scheduled using a command schedule, and in the script the backup is run under the unix ID for the instance. The problem is that when PASSWD GENERATE does its thing, the TSM.PWD file is deleted and re-created with the new password. This is done by the scheduler process and so the new TSM.PWD file has root ownership. Thus the backups fail as they can't access the new encrypted password. So, I've tried to fix this by running dsmc sched as the domino user, but I get ANS1817E Schedule function can only be run by a TSM authorized user. I've set up a TSM admin with node ownership, and I can run dsmc command line as the domino user, but not the scheduler. dsmcad won't work either. Is there any solution other than running everything as root or resorting to cron? I'd like to domino admins to be able to check logs and don't want them to have root access, but using separate users also has nice safeguards when it comes to restoring in the right environment. TIA Steve Steve Harris AIX and TSM Admin Sydney, Australia
Domino, scheduler and root id
Hi All, AIX 5.2, TSM Server 5.2.0.0 (working on an upgrade), Client 5.2.0.0, domino client 5.1.5.0, domino 6.5.4 My predecessor set up this environment using AIX srcmgr facilty to run a dsmc sched process for each domino instance - there are 8 on this machine, and they run under the root id. The domino instances themselves have a different unix id for each instance. Each instance is logically separate with its own file systems, domino binaries and a tsm directory that contains domdsm.cfg, dsm.opt, logs and a security directory containing the TSM.PWD file for the instance. We can literally export a couple of volume groups and import them elsewhere to move a domino instance to another AIX lpar. Domino backups are scheduled using a command schedule, and in the script the backup is run under the unix ID for the instance. The problem is that when PASSWD GENERATE does its thing, the TSM.PWD file is deleted and re-created with the new password. This is done by the scheduler process and so the new TSM.PWD file has root ownership. Thus the backups fail as they can't access the new encrypted password. So, I've tried to fix this by running dsmc sched as the domino user, but I get ANS1817E Schedule function can only be run by a TSM authorized user. I've set up a TSM admin with node ownership, and I can run dsmc command line as the domino user, but not the scheduler. dsmcad won't work either. Is there any solution other than running everything as root or resorting to cron? I'd like to domino admins to be able to check logs and don't want them to have root access, but using separate users also has nice safeguards when it comes to restoring in the right environment. TIA Steve Steve Harris AIX and TSM Admin Sydney, Australia
