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 < [email protected]>: > 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:[email protected]] On Behalf Of > Deschner, Roger Douglas > Sent: vrijdag 2 maart 2018 2:00 > To: [email protected] > 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 > ******************************************************** >
