[Info-vax] Do you (or someone you work with) sysman on Windows?

[johnwallace4 at yahoo.co.uk]

On Monday, 25 May 2015 15:36:28 UTC+1, Stephen Hoffman  wrote:
> On 2015-05-25 14:00:44 +0000, Jan-Erik Soderholm said:
> 
> > ...
> > DEC AXPVMS VMS V6.1      Oper System Install    04-MAY-1994
> > 
> > Not the same physical disk, of course. But same system image that have 
> > moved from some RX2x disk to the current IBM DS8000 FRC SAN.
> > 
> > I don't know it one should expect any problems with this, it works 
> > anyway... :-)
> 
> With ~twenty years of customizations and tweaks and old workaround and 
> left-over settings and the rest, this is probably an irreproducible 
> environment.
> 
> A development environment like this almost certainly does not match any 
> production production, short of cloning development over into 
> production.   Cloning a development environment into production should 
> be a last-resort operation, given the who-knows-what that is usually 
> lurking in a development environment, too.
> 
> Do these configurations usually work?  Sure.  Have I used ancient 
> environments?  Ayup.  Is reproducibility important for production 
> environments?  Definitely.  After having chased "it works fine in 
> development" problems a few too many times in production, details like 
> keeping a pristine development environment and source control and 
> automated deployment gets a whole lot more interesting.
> 
> OpenVMS unfortunately makes automated deployments far more painful than 
> this process should be for one server, and particularly painful 
> deployments when you're rolling out rather more than one server.  I've 
> yet to find a clean way to establish network names and network 
> addresses for bulk rollouts for instance, short of some rather ugly DCL 
> procedure hackery and related customizations.  This given that DHCP 
> doesn't work all that well with OpenVMS, and OpenVMS has no way to 
> advertise itself as a new and now-manageable host short of local 
> customizations -- an HP iLO can help here, but there are configuration 
> issues in the OpenVMS host environment.
> 
> Which gets back to my earlier comments around profiles and related 
> mechanisms.  This involves moving away from the traditional "bespoke" 
> configurations such as what Jan-Erik appears to be managing, and 
> heading toward automated bulk deployments, and toward nuke-and-pave 
> processing when the local application requirements shift.  Even in 
> smaller environments, this makes for a much faster redeployment of a 
> core production server, for instance.
> 
> Jan-Erik and a number of existing environments will probably never move 
> to clean-install processing, but other folks I'm dealing with are 
> interested, and particularly when dealing with more than one.  Once you 
> get around to deploying 300 OpenVMS servers, the Old Ways Of Doing 
> Things get... annoyingly tedious.  (That deployment number is NOT made 
> up nor picked from the air, either.)
> 
> As x86-64 gets rolling, there'll be increasing interest in easier 
> deployments for OpenVMS, as folks are already used to shuffling their 
> VM guests and their servers around.
> 
> But back to that earlier comment of mine: nuking and paving gets you a 
> reproducible and more easily supportable and more easily recoverable 
> environment.   OpenVMS just isn't good at that.  Other operating 
> systems are vastly better at it.
> 
> 
> 
> 
> -- 
> Pure Personal Opinion | HoffmanLabs LLC

Lots of words, no TLDR. Sorry.

When you say "nuking and paving gets you a reproducible and more
easily supportable and more easily recoverable environment. Other
operating  systems are vastly better [than VMS is] at it.", can
you give us some examples of what others *really* do better?

At first I thought you must mean Apple, about which I admit to
knowing nothing. Then I remembered that I know that Apple don't
do server software or hardware those days so I'm probably wrong.

I'm struggling to see how you're referring to the other two
widespread choices in the business world (Windows, Linux); 
my 20+ years of experience of developing, sysadminning, and
supporting them (and a bit more on VMS) seems to have
resulted in a different picture than the one you have.

As soon as you let an outside-connected Linux or Windows
system update itself for a few weeks, you've lost all
knowledge of (let alone control over) what's on that system.
Fortunately, many modern IT departments don't see that as a
problem. Handy, that.
 
You want that kind of thing (some would call it anarchy) to
happen with VMS as well?

Or are we supposed to ignore those details and trust in the
likes of Puppet and so on? [Will anybody even remember DevOps
in ten years time? (I won't care by then).

Maybe I'm missing something (but I don't get out much these
days).

Another example: VMS BACKUP may not have a shiny GUI for free
but for me it's always been more predictable and reliable at
doing a backup+restore than any of the stuff built in with
Windows and Linux. I'm one of many many people that can't even
make Windows 7's builtin tool reliably take a backup, let alone
restore one. See how many people are struggling with "shadow
copy could not be created" and similar Windows messages. See if
you can find anything other than the vaguest of non-support.
Maybe a failure of the built-in backup tool doesn't matter in a
corporate environment where there's a 3rd party backup tool
everywhere in the picture. After all, they'd surely be handling
shadow copy failures properly wouldn't they, before starting a
backup? 


Re software installation cloning etc: if VSI or a partner
wanted to build a product to do that, do you think there'd
be any inspiration to be found in the remains of Polycenter
Software Distribution (formerly VAX RSM) which did many of
these 'modern' things like distributed cloned customised
installations? This was way back in the 1990s, before the
Polycenter stuff was Palmerised out.

SPD 29.59.xx, or e.g. this Digital Technical Journal article
for those unfamiliar (which will be lots of people, sadly):
http://www.hpl.hp.com/hpjournal/dtj/vol6num4/vol6num4art6.pdf
Obviously lots of things will have changed in the meantime.


One of the nice things about VMS is its visible behaviours are
generally documented. Windows, less so; vast quantities of "do
it this way because this way it works". Sometimes, the "do it
this way"s contradict each other (example follows). Linux,
mostly the code is the documentation, till its visible
behaviour changes.

An example: Windows' SystemIDs were once upon a time considered
to be things that had to be adjusted after a system was cloned.
There was a nice tool from Sysinternals (reverse engineered, not
built from documentation) to help with this.

Then MS bought Sysinternals and suddenly unique SystemIDs
aren't important any more. Not to Microsoft anyway. But third
party software may have relied on the original vision, that
a SystemID is distinct between boxes. Ignore them at your peril
[1].

Lots of organisations are comfortable building their IT
strategies and departments around this kind of vagueness,
because it's never caused any real problems (that anyone's
admitted). Should they be comfortable?

Puzzled.

[1] Random example of the consequences of building on
vagueness - Windows SystemIDs, unique or not?:
http://www.brianmadden.com/blogs/guestbloggers/archive/2011/04/13/do-sids-matter-anymore.aspx