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.Loon AT klm DOT 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 AT VM.MARIST DOT EDU] On Behalf
> Of
> Deschner, Roger Douglas
> Sent: vrijdag 2 maart 2018 2:00
> To: ADSM-L AT VM.MARIST DOT 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
> ********************************************************
>
|
