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." > ******************************************************** > 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 > ******************************************************** > ******************************************************** 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 ********************************************************
