Re: v7.1.8/8.1.2 SSL Upgrade: Rethinking servers first or clients first

[Loon, Eric van (ITOPT3) - KLM]

Hi Steve,
Both your and Arnauds solution will work, until you stop/start your server. 
Then the schedule time will be missed and it will never be started again until 
you run it once manually...
Kind regards,
Eric van Loon
Air France/KLM Storage Engineering

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of 
Harris, Steven
Sent: woensdag 7 maart 2018 2:57
To: ADSM-L@VM.MARIST.EDU
Subject: Re: v7.1.8/8.1.2 SSL Upgrade: Rethinking servers first or clients first

Eric

Really old-school...

Schedule a one time admin schedule to run a script that as the last step 
schedules itself again some time in the future

e.g

def scr reset_fred
upd scr reset_fred 'upd admin fred  sessionsecurity=transitional'   line=5  
 check the syntax
upd scr reset_fred 'upd sched reset_fred  t=a start=+0:05'  line=10


def sched reset_fred t=a cmd='run reset_fred'  active=yes  


Regards

Steve

Steven Harris
TSM Admin/Consultant
Canberra Australia



-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Loon, 
Eric van (ITOPT3) - KLM
Sent: Wednesday, 7 March 2018 2:00 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] v7.1.8/8.1.2 SSL Upgrade: Rethinking servers first or 
clients first

Hi Krzysztof,
Agreed, it will work but it sure aint pretty. And again, we are trying to find 
a fix for something IBM has broken...
Kind regards,
Eric van Loon
Air France/KLM Storage Engineering


-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of 
Krzysztof Przygoda
Sent: dinsdag 6 maart 2018 15:40
To: ADSM-L@VM.MARIST.EDU
Subject: Re: v7.1.8/8.1.2 SSL Upgrade: Rethinking servers first or clients first

Hi Eric
Solution for admin schedule to run more often without crontabs is to have 
several of them starting at different moment of each hour (startt value).
Eg:
def sched ADMIN_TRANSITIONAL_1 type=admin active=yes  STARTT=15:01 CMD="RUN 
ADMIN_TRANSITIONAL" duru=min peru=hour def sched ADMIN_TRANSITIONAL_2 
type=admin active=yes  STARTT=15:11 CMD="RUN ADMIN_TRANSITIONAL" duru=min 
peru=hour etc.
I know, this make the "fix" even more ridiculous ...but again, it works:-)

Kind regards
Krzysztof

2018-03-06 15:17 GMT+01:00 Loon, Eric van (ITOPT3) - KLM <
eric-van.l...@klm.com>:

> Hi Roger,
> I'm struggling with the exact same issues as you are. I'm running a
> 7.1.8 server and all procedures we are using for years to deploy new 
> clients fail because of the admins STRICT issue. And migrating 
> existing (< 7.1.8) versions from another server to this 7.1.8 server 
> is only possible after a manual update of the admin to TRANSITIONAL, 
> each and every time. You can't bypass this by installing the 
> certificate first because the dsmcert utility does not exist in pre-7.1.8 
> clients!
> I really think IBM has screwed up here big time. They clearly 
> underestimated the impact of this "small" security "enhancements" they 
> implemented. :-( I too thought about the fix of having the admin 
> account updated to TRANSITIONAL every minute or so, but I haven't been 
> able to find a way through the administrative scheduler to schedule a 
> command more often that once per hour (PERunits=H)... So you have to 
> build your own scripts and schedule it through cron, which isn't 
> allowed in our shop.
> I too have a hard time finding a simple solution. I think the best 
> thing IBM could do is admit that they have underestimated this issue 
> and create a
> 7.1.8.100 patch level with the option to set an admin account to 
> TRANSITIONAL permanently.
> Kind regards,
> Eric van Loon
> Air France/KLM Storage Engineering
>
> -Original Message-
> From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf 
> Of Deschner, Roger Douglas
> Sent: vrijdag 2 maart 2018 2:00
> To: ADSM-L@VM.MARIST.EDU
> Subject: v7.1.8/8.1.2 SSL Upgrade: Rethinking servers first or clients 
> first
>
> I've been using our test setup for further testing, and I'm thinking 
> of reversing my strategy. I may want to upgrade clients first, and 
> then servers.
>
> The basic issue is still how to overcome the roadblock of having an 
> Administrator ID automatically switched from TRANSITIONAL to STRICT 
> upon first login from a 7.1.8/8.1.2+ dsmadmc client. IBM seems to 
> think we can upgrade all servers and all clients to 7.1.8/8.1.2+ 
> simultaneously. That is not practical.
>
> In the worst case, this automatic switching could cause the System 
> Administrator's worst nightmare - to lose control over a running system.
>
> I am still considering the (very ugly) bypass of an administrative 
> schedule that sets it back to TRANSITIONAL for all Admin IDs every 5 
> minutes. There will still be some failures.
>
> But I am

Re: v7.1.8/8.1.2 SSL Upgrade: Rethinking servers first or clients first

[PAC Brion Arnaud]

Another alternative  : define a script named "OP_ADMIN_CONTROL"

Having following content :

del schedule OP_ADMIN_LOOP_CTL type=administrative   
[your update admin command]
def schedule OP_ADMIN_LOOP_CTL type=a cmd="run OP_ADMIN_CONTROL" active=yes 
startt=now+0:10 peru=o


Cheers.

Arnaud

**
Backup and Recovery Systems Administrator
Panalpina Management Ltd., Basle, Switzerland,
CIT Department Viadukstrasse 42, P.O. Box 4002 Basel/CH
Phone: +41 (61) 226 11 11, FAX: +41 (61) 226 17 01
Direct: +41 (61) 226 19 78
e-mail: arnaud.br...@panalpina.com
This electronic message transmission contains information from Panalpina and is 
confidential or privileged. This information is intended only for the person 
(s) named above. If you are not the intended recipient, any disclosure, 
copying, distribution or use or any other action based on the contents of this 
information is strictly prohibited. 

If you receive this electronic transmission in error, please notify the sender 
by e-mail, telephone or fax at the numbers listed above. Thank you.
**


-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of 
Harris, Steven
Sent: Wednesday, March 07, 2018 2:57 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: v7.1.8/8.1.2 SSL Upgrade: Rethinking servers first or clients first

Eric

Really old-school...

Schedule a one time admin schedule to run a script that as the last step 
schedules itself again some time in the future

e.g

def scr reset_fred
upd scr reset_fred 'upd admin fred  sessionsecurity=transitional'   line=5  
 check the syntax
upd scr reset_fred 'upd sched reset_fred  t=a start=+0:05'  line=10


def sched reset_fred t=a cmd='run reset_fred'  active=yes  


Regards

Steve

Steven Harris
TSM Admin/Consultant
Canberra Australia



-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Loon, 
Eric van (ITOPT3) - KLM
Sent: Wednesday, 7 March 2018 2:00 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] v7.1.8/8.1.2 SSL Upgrade: Rethinking servers first or 
clients first

Hi Krzysztof,
Agreed, it will work but it sure aint pretty. And again, we are trying to find 
a fix for something IBM has broken...
Kind regards,
Eric van Loon
Air France/KLM Storage Engineering


-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of 
Krzysztof Przygoda
Sent: dinsdag 6 maart 2018 15:40
To: ADSM-L@VM.MARIST.EDU
Subject: Re: v7.1.8/8.1.2 SSL Upgrade: Rethinking servers first or clients first

Hi Eric
Solution for admin schedule to run more often without crontabs is to have 
several of them starting at different moment of each hour (startt value).
Eg:
def sched ADMIN_TRANSITIONAL_1 type=admin active=yes  STARTT=15:01 CMD="RUN 
ADMIN_TRANSITIONAL" duru=min peru=hour def sched ADMIN_TRANSITIONAL_2 
type=admin active=yes  STARTT=15:11 CMD="RUN ADMIN_TRANSITIONAL" duru=min 
peru=hour etc.
I know, this make the "fix" even more ridiculous ...but again, it works:-)

Kind regards
Krzysztof

2018-03-06 15:17 GMT+01:00 Loon, Eric van (ITOPT3) - KLM <
eric-van.l...@klm.com>:

> Hi Roger,
> I'm struggling with the exact same issues as you are. I'm running a
> 7.1.8 server and all procedures we are using for years to deploy new 
> clients fail because of the admins STRICT issue. And migrating 
> existing (< 7.1.8) versions from another server to this 7.1.8 server 
> is only possible after a manual update of the admin to TRANSITIONAL, 
> each and every time. You can't bypass this by installing the 
> certificate first because the dsmcert utility does not exist in pre-7.1.8 
> clients!
> I really think IBM has screwed up here big time. They clearly 
> underestimated the impact of this "small" security "enhancements" they 
> implemented. :-( I too thought about the fix of having the admin 
> account updated to TRANSITIONAL every minute or so, but I haven't been 
> able to find a way through the administrative scheduler to schedule a 
> command more often that once per hour (PERunits=H)... So you have to 
> build your own scripts and schedule it through cron, which isn't 
> allowed in our shop.
> I too have a hard time finding a simple solution. I think the best 
> thing IBM could do is admit that they have underestimated this issue 
> and create a
> 7.1.8.100 patch level with the option to set an admin account to 
> TRANSITIONAL permanently.
> Kind regards,
> Eric van Loon
> Air France/KLM Storage Engineering
>
> -Original Message-
> From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU]

Re: v7.1.8/8.1.2 SSL Upgrade: Rethinking servers first or clients first

[Harris, Steven]

Eric

Really old-school...

Schedule a one time admin schedule to run a script that as the last step 
schedules itself again some time in the future

e.g

def scr reset_fred
upd scr reset_fred 'upd admin fred  sessionsecurity=transitional'   line=5  
 check the syntax
upd scr reset_fred 'upd sched reset_fred  t=a start=+0:05'  line=10


def sched reset_fred t=a cmd='run reset_fred'  active=yes  


Regards

Steve

Steven Harris
TSM Admin/Consultant
Canberra Australia



-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Loon, 
Eric van (ITOPT3) - KLM
Sent: Wednesday, 7 March 2018 2:00 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] v7.1.8/8.1.2 SSL Upgrade: Rethinking servers first or 
clients first

Hi Krzysztof,
Agreed, it will work but it sure aint pretty. And again, we are trying to find 
a fix for something IBM has broken...
Kind regards,
Eric van Loon
Air France/KLM Storage Engineering


-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of 
Krzysztof Przygoda
Sent: dinsdag 6 maart 2018 15:40
To: ADSM-L@VM.MARIST.EDU
Subject: Re: v7.1.8/8.1.2 SSL Upgrade: Rethinking servers first or clients first

Hi Eric
Solution for admin schedule to run more often without crontabs is to have 
several of them starting at different moment of each hour (startt value).
Eg:
def sched ADMIN_TRANSITIONAL_1 type=admin active=yes  STARTT=15:01 CMD="RUN 
ADMIN_TRANSITIONAL" duru=min peru=hour def sched ADMIN_TRANSITIONAL_2 
type=admin active=yes  STARTT=15:11 CMD="RUN ADMIN_TRANSITIONAL" duru=min 
peru=hour etc.
I know, this make the "fix" even more ridiculous ...but again, it works:-)

Kind regards
Krzysztof

2018-03-06 15:17 GMT+01:00 Loon, Eric van (ITOPT3) - KLM <
eric-van.l...@klm.com>:

> Hi Roger,
> I'm struggling with the exact same issues as you are. I'm running a
> 7.1.8 server and all procedures we are using for years to deploy new 
> clients fail because of the admins STRICT issue. And migrating 
> existing (< 7.1.8) versions from another server to this 7.1.8 server 
> is only possible after a manual update of the admin to TRANSITIONAL, 
> each and every time. You can't bypass this by installing the 
> certificate first because the dsmcert utility does not exist in pre-7.1.8 
> clients!
> I really think IBM has screwed up here big time. They clearly 
> underestimated the impact of this "small" security "enhancements" they 
> implemented. :-( I too thought about the fix of having the admin 
> account updated to TRANSITIONAL every minute or so, but I haven't been 
> able to find a way through the administrative scheduler to schedule a 
> command more often that once per hour (PERunits=H)... So you have to 
> build your own scripts and schedule it through cron, which isn't 
> allowed in our shop.
> I too have a hard time finding a simple solution. I think the best 
> thing IBM could do is admit that they have underestimated this issue 
> and create a
> 7.1.8.100 patch level with the option to set an admin account to 
> TRANSITIONAL permanently.
> Kind regards,
> Eric van Loon
> Air France/KLM Storage Engineering
>
> -Original Message-
> From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf 
> Of Deschner, Roger Douglas
> Sent: vrijdag 2 maart 2018 2:00
> To: ADSM-L@VM.MARIST.EDU
> Subject: v7.1.8/8.1.2 SSL Upgrade: Rethinking servers first or clients 
> first
>
> I've been using our test setup for further testing, and I'm thinking 
> of reversing my strategy. I may want to upgrade clients first, and 
> then servers.
>
> The basic issue is still how to overcome the roadblock of having an 
> Administrator ID automatically switched from TRANSITIONAL to STRICT 
> upon first login from a 7.1.8/8.1.2+ dsmadmc client. IBM seems to 
> think we can upgrade all servers and all clients to 7.1.8/8.1.2+ 
> simultaneously. That is not practical.
>
> In the worst case, this automatic switching could cause the System 
> Administrator's worst nightmare - to lose control over a running system.
>
> I am still considering the (very ugly) bypass of an administrative 
> schedule that sets it back to TRANSITIONAL for all Admin IDs every 5 
> minutes. There will still be some failures.
>
> But I am also considering reversing the strategy I had considered 
> earlier, to a different strategy of upgrading all of the clients 
> involved (about 7 of them, I think, but I'm not sure) to 7.1.8 or
> 8.1.4 first, while the servers are all still running older versions. 
> So far, everything would be working.
>
> Then doublecheck that there are not any left behind by scanning 
> activity logs, the summary file, etc.
>
> Then once the operation of these clients was stabilized, upgrade our 4 

Re: v7.1.8/8.1.2 SSL Upgrade: Rethinking servers first or clients first

[Loon, Eric van (ITOPT3) - KLM]

Hi Krzysztof,
Agreed, it will work but it sure aint pretty. And again, we are trying to find 
a fix for something IBM has broken...
Kind regards,
Eric van Loon
Air France/KLM Storage Engineering


-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of 
Krzysztof Przygoda
Sent: dinsdag 6 maart 2018 15:40
To: ADSM-L@VM.MARIST.EDU
Subject: Re: v7.1.8/8.1.2 SSL Upgrade: Rethinking servers first or clients first

Hi Eric
Solution for admin schedule to run more often without crontabs is to have 
several of them starting at different moment of each hour (startt value).
Eg:
def sched ADMIN_TRANSITIONAL_1 type=admin active=yes  STARTT=15:01 CMD="RUN 
ADMIN_TRANSITIONAL" duru=min peru=hour def sched ADMIN_TRANSITIONAL_2 
type=admin active=yes  STARTT=15:11 CMD="RUN ADMIN_TRANSITIONAL" duru=min 
peru=hour etc.
I know, this make the "fix" even more ridiculous ...but again, it works:-)

Kind regards
Krzysztof

2018-03-06 15:17 GMT+01:00 Loon, Eric van (ITOPT3) - KLM <
eric-van.l...@klm.com>:

> Hi Roger,
> I'm struggling with the exact same issues as you are. I'm running a 
> 7.1.8 server and all procedures we are using for years to deploy new 
> clients fail because of the admins STRICT issue. And migrating 
> existing (< 7.1.8) versions from another server to this 7.1.8 server 
> is only possible after a manual update of the admin to TRANSITIONAL, 
> each and every time. You can't bypass this by installing the 
> certificate first because the dsmcert utility does not exist in pre-7.1.8 
> clients!
> I really think IBM has screwed up here big time. They clearly 
> underestimated the impact of this "small" security "enhancements" they 
> implemented. :-( I too thought about the fix of having the admin 
> account updated to TRANSITIONAL every minute or so, but I haven't been 
> able to find a way through the administrative scheduler to schedule a 
> command more often that once per hour (PERunits=H)... So you have to 
> build your own scripts and schedule it through cron, which isn't 
> allowed in our shop.
> I too have a hard time finding a simple solution. I think the best 
> thing IBM could do is admit that they have underestimated this issue 
> and create a
> 7.1.8.100 patch level with the option to set an admin account to 
> TRANSITIONAL permanently.
> Kind regards,
> Eric van Loon
> Air France/KLM Storage Engineering
>
> -Original Message-
> From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf 
> Of Deschner, Roger Douglas
> Sent: vrijdag 2 maart 2018 2:00
> To: ADSM-L@VM.MARIST.EDU
> Subject: v7.1.8/8.1.2 SSL Upgrade: Rethinking servers first or clients 
> first
>
> I've been using our test setup for further testing, and I'm thinking 
> of reversing my strategy. I may want to upgrade clients first, and 
> then servers.
>
> The basic issue is still how to overcome the roadblock of having an 
> Administrator ID automatically switched from TRANSITIONAL to STRICT 
> upon first login from a 7.1.8/8.1.2+ dsmadmc client. IBM seems to 
> think we can upgrade all servers and all clients to 7.1.8/8.1.2+ 
> simultaneously. That is not practical.
>
> In the worst case, this automatic switching could cause the System 
> Administrator's worst nightmare - to lose control over a running system.
>
> I am still considering the (very ugly) bypass of an administrative 
> schedule that sets it back to TRANSITIONAL for all Admin IDs every 5 
> minutes. There will still be some failures.
>
> But I am also considering reversing the strategy I had considered 
> earlier, to a different strategy of upgrading all of the clients 
> involved (about 7 of them, I think, but I'm not sure) to 7.1.8 or 
> 8.1.4 first, while the servers are all still running older versions. 
> So far, everything would be working.
>
> Then doublecheck that there are not any left behind by scanning 
> activity logs, the summary file, etc.
>
> Then once the operation of these clients was stabilized, upgrade our 4 
> servers one at a time. As each server is upgraded, the already-updated 
> client would cause certificates to be exchanged and that Admin ID to 
> be switched to STRICT, which would be OK since all of the client nodes 
> where that Admin ID might log in from would already be at 
> V7.1.8/8.1.2+. (At least we hope. This may expose those we forgot.)
>
> Unless I'm overlooking something big here, I think this would allow us 
> to upgrade each client and each server independently, and iron out any 
> issues one at a time. Any comments on this client-first strategy?
>
> Roger Deschner
> University of Illinois at Chicago
> "I have not lost my mind; it is backed up on tape somewhere."
> *

Re: v7.1.8/8.1.2 SSL Upgrade: Rethinking servers first or clients first

[Krzysztof Przygoda]

Hi Eric
Solution for admin schedule to run more often without crontabs is to have
several of them starting at different moment of each hour (startt value).
Eg:
def sched ADMIN_TRANSITIONAL_1 type=admin active=yes  STARTT=15:01
CMD="RUN ADMIN_TRANSITIONAL" duru=min peru=hour
def sched ADMIN_TRANSITIONAL_2 type=admin active=yes  STARTT=15:11
CMD="RUN ADMIN_TRANSITIONAL" duru=min peru=hour
etc.
I know, this make the "fix" even more ridiculous ...but again, it works:-)

Kind regards
Krzysztof

2018-03-06 15:17 GMT+01:00 Loon, Eric van (ITOPT3) - KLM <
eric-van.l...@klm.com>:

> Hi Roger,
> I'm struggling with the exact same issues as you are. I'm running a 7.1.8
> server and all procedures we are using for years to deploy new clients fail
> because of the admins STRICT issue. And migrating existing (< 7.1.8)
> versions from another server to this 7.1.8 server is only possible after a
> manual update of the admin to TRANSITIONAL, each and every time. You can't
> bypass this by installing the certificate first because the dsmcert utility
> does not exist in pre-7.1.8 clients!
> I really think IBM has screwed up here big time. They clearly
> underestimated the impact of this "small" security "enhancements" they
> implemented. :-(
> I too thought about the fix of having the admin account updated to
> TRANSITIONAL every minute or so, but I haven't been able to find a way
> through the administrative scheduler to schedule a command more often that
> once per hour (PERunits=H)... So you have to build your own scripts and
> schedule it through cron, which isn't allowed in our shop.
> I too have a hard time finding a simple solution. I think the best thing
> IBM could do is admit that they have underestimated this issue and create a
> 7.1.8.100 patch level with the option to set an admin account to
> TRANSITIONAL permanently.
> Kind regards,
> Eric van Loon
> Air France/KLM Storage Engineering
>
> -Original Message-
> From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of
> Deschner, Roger Douglas
> Sent: vrijdag 2 maart 2018 2:00
> To: ADSM-L@VM.MARIST.EDU
> Subject: v7.1.8/8.1.2 SSL Upgrade: Rethinking servers first or clients
> first
>
> I've been using our test setup for further testing, and I'm thinking of
> reversing my strategy. I may want to upgrade clients first, and then
> servers.
>
> The basic issue is still how to overcome the roadblock of having an
> Administrator ID automatically switched from TRANSITIONAL to STRICT upon
> first login from a 7.1.8/8.1.2+ dsmadmc client. IBM seems to think we can
> upgrade all servers and all clients to 7.1.8/8.1.2+ simultaneously. That is
> not practical.
>
> In the worst case, this automatic switching could cause the System
> Administrator's worst nightmare - to lose control over a running system.
>
> I am still considering the (very ugly) bypass of an administrative
> schedule that sets it back to TRANSITIONAL for all Admin IDs every 5
> minutes. There will still be some failures.
>
> But I am also considering reversing the strategy I had considered earlier,
> to a different strategy of upgrading all of the clients involved (about 7
> of them, I think, but I'm not sure) to 7.1.8 or 8.1.4 first, while the
> servers are all still running older versions. So far, everything would be
> working.
>
> Then doublecheck that there are not any left behind by scanning activity
> logs, the summary file, etc.
>
> Then once the operation of these clients was stabilized, upgrade our 4
> servers one at a time. As each server is upgraded, the already-updated
> client would cause certificates to be exchanged and that Admin ID to be
> switched to STRICT, which would be OK since all of the client nodes where
> that Admin ID might log in from would already be at V7.1.8/8.1.2+. (At
> least we hope. This may expose those we forgot.)
>
> Unless I'm overlooking something big here, I think this would allow us to
> upgrade each client and each server independently, and iron out any issues
> one at a time. Any comments on this client-first strategy?
>
> Roger Deschner
> University of Illinois at Chicago
> "I have not lost my mind; it is backed up on tape somewhere."
> 
> For information, services and offers, please visit our web site:
> http://www.klm.com. This e-mail and any attachment may contain
> confidential and privileged material intended for the addressee only. If
> you are not the addressee, you are notified that no part of the e-mail or
> any attachment may be disclosed, copied or distributed, and that any other
> action related to this e-mail or attachment is strictly prohibited, and may
> be unla

Re: v7.1.8/8.1.2 SSL Upgrade: Rethinking servers first or clients first

[Loon, Eric van (ITOPT3) - KLM]

Hi Roger,
I'm struggling with the exact same issues as you are. I'm running a 7.1.8 
server and all procedures we are using for years to deploy new clients fail 
because of the admins STRICT issue. And migrating existing (< 7.1.8) versions 
from another server to this 7.1.8 server is only possible after a manual update 
of the admin to TRANSITIONAL, each and every time. You can't bypass this by 
installing the certificate first because the dsmcert utility does not exist in 
pre-7.1.8 clients!
I really think IBM has screwed up here big time. They clearly underestimated 
the impact of this "small" security "enhancements" they implemented. :-(
I too thought about the fix of having the admin account updated to TRANSITIONAL 
every minute or so, but I haven't been able to find a way through the 
administrative scheduler to schedule a command more often that once per hour 
(PERunits=H)... So you have to build your own scripts and schedule it through 
cron, which isn't allowed in our shop.
I too have a hard time finding a simple solution. I think the best thing IBM 
could do is admit that they have underestimated this issue and create a 
7.1.8.100 patch level with the option to set an admin account to TRANSITIONAL 
permanently.
Kind regards,
Eric van Loon
Air France/KLM Storage Engineering

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of 
Deschner, Roger Douglas
Sent: vrijdag 2 maart 2018 2:00
To: ADSM-L@VM.MARIST.EDU
Subject: v7.1.8/8.1.2 SSL Upgrade: Rethinking servers first or clients first

I've been using our test setup for further testing, and I'm thinking of 
reversing my strategy. I may want to upgrade clients first, and then servers.

The basic issue is still how to overcome the roadblock of having an 
Administrator ID automatically switched from TRANSITIONAL to STRICT upon first 
login from a 7.1.8/8.1.2+ dsmadmc client. IBM seems to think we can upgrade all 
servers and all clients to 7.1.8/8.1.2+ simultaneously. That is not practical.

In the worst case, this automatic switching could cause the System 
Administrator's worst nightmare - to lose control over a running system. 

I am still considering the (very ugly) bypass of an administrative schedule 
that sets it back to TRANSITIONAL for all Admin IDs every 5 minutes. There will 
still be some failures.

But I am also considering reversing the strategy I had considered earlier, to a 
different strategy of upgrading all of the clients involved (about 7 of them, I 
think, but I'm not sure) to 7.1.8 or 8.1.4 first, while the servers are all 
still running older versions. So far, everything would be working.

Then doublecheck that there are not any left behind by scanning activity logs, 
the summary file, etc. 

Then once the operation of these clients was stabilized, upgrade our 4 servers 
one at a time. As each server is upgraded, the already-updated client would 
cause certificates to be exchanged and that Admin ID to be switched to STRICT, 
which would be OK since all of the client nodes where that Admin ID might log 
in from would already be at V7.1.8/8.1.2+. (At least we hope. This may expose 
those we forgot.)

Unless I'm overlooking something big here, I think this would allow us to 
upgrade each client and each server independently, and iron out any issues one 
at a time. Any comments on this client-first strategy?

Roger Deschner
University of Illinois at Chicago
"I have not lost my mind; it is backed up on tape somewhere."

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286

Re: v7.1.8/8.1.2 SSL Upgrade: Rethinking servers first or clients first

[Fernando Florentino]

In some cases, I have to copy cert256.arm from Spectrum instance directory
and copy to server client to register manually.

On Thu, Mar 1, 2018 at 9:59 PM, Deschner, Roger Douglas 
wrote:

> I've been using our test setup for further testing, and I'm thinking of
> reversing my strategy. I may want to upgrade clients first, and then
> servers.
>
> The basic issue is still how to overcome the roadblock of having an
> Administrator ID automatically switched from TRANSITIONAL to STRICT upon
> first login from a 7.1.8/8.1.2+ dsmadmc client. IBM seems to think we can
> upgrade all servers and all clients to 7.1.8/8.1.2+ simultaneously. That is
> not practical.
>
> In the worst case, this automatic switching could cause the System
> Administrator's worst nightmare - to lose control over a running system.
>
> I am still considering the (very ugly) bypass of an administrative
> schedule that sets it back to TRANSITIONAL for all Admin IDs every 5
> minutes. There will still be some failures.
>
> But I am also considering reversing the strategy I had considered earlier,
> to a different strategy of upgrading all of the clients involved (about 7
> of them, I think, but I'm not sure) to 7.1.8 or 8.1.4 first, while the
> servers are all still running older versions. So far, everything would be
> working.
>
> Then doublecheck that there are not any left behind by scanning activity
> logs, the summary file, etc.
>
> Then once the operation of these clients was stabilized, upgrade our 4
> servers one at a time. As each server is upgraded, the already-updated
> client would cause certificates to be exchanged and that Admin ID to be
> switched to STRICT, which would be OK since all of the client nodes where
> that Admin ID might log in from would already be at V7.1.8/8.1.2+. (At
> least we hope. This may expose those we forgot.)
>
> Unless I'm overlooking something big here, I think this would allow us to
> upgrade each client and each server independently, and iron out any issues
> one at a time. Any comments on this client-first strategy?
>
> Roger Deschner
> University of Illinois at Chicago
> "I have not lost my mind; it is backed up on tape somewhere."

Re: [EXTERNAL] v7.1.8/8.1.2 SSL Upgrade: Rethinking servers first or clients first

[Rhodes, Richard L.]

>Then once the operation of these clients was stabilized, upgrade 
>our 4 servers one at a time. As each server is upgraded, 
>the already-updated client would cause certificates to be 
>exchanged and that Admin ID to be switched to STRICT, which 
>would be OK since all of the client nodes where that Admin 
>ID might log in from would already be at V7.1.8/8.1.2+. 

Do your servers talk to each other?  

Our servers are all setup with server-to-server communications for a 
library sharing environment and moving node data between servers.  
Are there issues upgrading servers one at a time when the 
servers talk to each other?


Rick




-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of 
Deschner, Roger Douglas
Sent: Thursday, March 1, 2018 8:00 PM
To: ADSM-L@VM.MARIST.EDU
Subject: [EXTERNAL] v7.1.8/8.1.2 SSL Upgrade: Rethinking servers first or 
clients first

I've been using our test setup for further testing, and I'm thinking of 
reversing my strategy. I may want to upgrade clients first, and then servers.

The basic issue is still how to overcome the roadblock of having an 
Administrator ID automatically switched from TRANSITIONAL to STRICT upon first 
login from a 7.1.8/8.1.2+ dsmadmc client. IBM seems to think we can upgrade all 
servers and all clients to 7.1.8/8.1.2+ simultaneously. That is not practical.

In the worst case, this automatic switching could cause the System 
Administrator's worst nightmare - to lose control over a running system. 

I am still considering the (very ugly) bypass of an administrative schedule 
that sets it back to TRANSITIONAL for all Admin IDs every 5 minutes. There will 
still be some failures.

But I am also considering reversing the strategy I had considered earlier, to a 
different strategy of upgrading all of the clients involved (about 7 of them, I 
think, but I'm not sure) to 7.1.8 or 8.1.4 first, while the servers are all 
still running older versions. So far, everything would be working.

Then doublecheck that there are not any left behind by scanning activity logs, 
the summary file, etc. 

Then once the operation of these clients was stabilized, upgrade our 4 servers 
one at a time. As each server is upgraded, the already-updated client would 
cause certificates to be exchanged and that Admin ID to be switched to STRICT, 
which would be OK since all of the client nodes where that Admin ID might log 
in from would already be at V7.1.8/8.1.2+. (At least we hope. This may expose 
those we forgot.)

Unless I'm overlooking something big here, I think this would allow us to 
upgrade each client and each server independently, and iron out any issues one 
at a time. Any comments on this client-first strategy?

Roger Deschner
University of Illinois at Chicago
"I have not lost my mind; it is backed up on tape somewhere."
--

The information contained in this message is intended only for the personal and 
confidential use of the recipient(s) named above. If the reader of this message 
is not the intended recipient or an agent responsible for delivering it to the 
intended recipient, you are hereby notified that you have received this 
document in error and that any review, dissemination, distribution, or copying 
of this message is strictly prohibited. If you have received this communication 
in error, please notify us immediately, and delete the original message.

v7.1.8/8.1.2 SSL Upgrade: Rethinking servers first or clients first

[Deschner, Roger Douglas]

I've been using our test setup for further testing, and I'm thinking of 
reversing my strategy. I may want to upgrade clients first, and then servers.

The basic issue is still how to overcome the roadblock of having an 
Administrator ID automatically switched from TRANSITIONAL to STRICT upon first 
login from a 7.1.8/8.1.2+ dsmadmc client. IBM seems to think we can upgrade all 
servers and all clients to 7.1.8/8.1.2+ simultaneously. That is not practical.

In the worst case, this automatic switching could cause the System 
Administrator's worst nightmare - to lose control over a running system. 

I am still considering the (very ugly) bypass of an administrative schedule 
that sets it back to TRANSITIONAL for all Admin IDs every 5 minutes. There will 
still be some failures.

But I am also considering reversing the strategy I had considered earlier, to a 
different strategy of upgrading all of the clients involved (about 7 of them, I 
think, but I'm not sure) to 7.1.8 or 8.1.4 first, while the servers are all 
still running older versions. So far, everything would be working.

Then doublecheck that there are not any left behind by scanning activity logs, 
the summary file, etc. 

Then once the operation of these clients was stabilized, upgrade our 4 servers 
one at a time. As each server is upgraded, the already-updated client would 
cause certificates to be exchanged and that Admin ID to be switched to STRICT, 
which would be OK since all of the client nodes where that Admin ID might log 
in from would already be at V7.1.8/8.1.2+. (At least we hope. This may expose 
those we forgot.)

Unless I'm overlooking something big here, I think this would allow us to 
upgrade each client and each server independently, and iron out any issues one 
at a time. Any comments on this client-first strategy?

Roger Deschner
University of Illinois at Chicago
"I have not lost my mind; it is backed up on tape somewhere."