2 Mar
2022
2 Mar
'22
8:25 p.m.
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.
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
------------------------------------------------------------------------
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