------------------------------------------------------------------------
On 3/2/22 2:25 PM, Johnny Billquist wrote:
One obvious reason it might not be is the fact that if something
security wise is screwed up, you are in a deep pile of poo poo.
Was it HP Integrity servers that had some root kit on the ILO, or
something like that...?
Back in the day, I liked to have the disks with important software,
like the OS and core applications, write protected during normal
operations. Little chance of that getting corrupted... But it did
require you to physical be by the disks if you wanted to upgrade
things, since you needed to hit that write protect switch. But I was
happy with that.
Johnny
------------------------------------------------------------------------
On 2022-03-02 20:19, Thomas DeBellis wrote:
'almost'?
I found myself curious as to when it wouldn't be. Could you
elaborate? Did you have something in mind, perhaps having SNMP on
all the time?
We expended substantial effort to make our 20's effectively 'lights
out'; nobody in the machine--EVER--except to mount tapes and disks or
to boot and that was during third shift. They could even be
configured for remote management in the boot regard if you had local
(wired) terminals on the first DH11.
You could set the switches of the front end that indicated which
terminal would become the CTY. One of these terminals happened to be
TTY7:, which was several blocks away (in my office). Saved me walking
and the howling cold of the machine room...
As far as I am aware, at Big Bank, we will not install any machines
that don't do complete lights out. That policy is at least two
decades old.
------------------------------------------------------------------------
On 3/2/22 12:58 AM, Dave McGuire wrote:
I'm not a PyDECnet user yet, but I will say this, remote
manageability is almost always a good thing.
-Dave
> ------------------------------------------------------------------------
>
>
> On 3/1/22 20:16, Paul Koning wrote:
>
> Question for PyDECnet users: as I mentioned, there's a new API,
> cleaner than the old one. A major addition is access to the
> Session Control layer, in other words external programs can talk to
> the API to use DECnet communication services, inbound or outbound.
> This is how I implemented a simple subset NCP and NFT.
>
>
> That API runs over a Unix domain socket, in connection mode. It's
> quite similar to TCP but inherently local to the machine where
> PyDECnet is running. That's nice for security, of course. But on
> the other hand, it means that there isn't a way for a PyDECnet
> running on one machine to offer a portal into DECnet for nearby
> machines. If you keep a DECnet router in the basement, your laptop
> can't run NCP since it has no access to that socket.
>
> It would not be all that difficult to add an option for running
> that same API over a TCP port, possibly with some sort of access
> filtering. Is there interest in such a thing?
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se