[Info-vax] Integrity iLO Configuration?

[Jan-Erik Söderholm]

Den 2021-06-25 kl. 00:38, skrev Dave Froble:
> On 6/24/2021 3:10 PM, Bill Gunshannon wrote:
>> On 6/24/21 2:44 PM, Dave Froble wrote:
>>> On 6/24/2021 1:19 PM, Stephen Hoffman wrote:
>>>> On 2021-06-24 00:50:32 +0000, Dave Froble said:
>>>>
>>>>> Apparently I'm getting an itanic on Friday.  Do I have to use iLO and
>>>>> such, or, can I ignore tham?
>>>>
>>>> That's your call.
>>>>
>>>> Around here, I'd want to configure and connect the iLO to the network,
>>>> yes. With any Integrity server. Regardless of the intended usage of the
>>>> Integrity server.
>>>>
>>>> If this Integrity server includes graphics hardware and a graphics
>>>> display (that via separate controller, or via the iLO), that'll likely
>>>> be the primary usage, and not the iLO network-connected serial console.
>>>>
>>>> If using this Integrity server as a remote server with interactive
>>>> sessions—traditional timesharing, not graphics—then the iLO can be one
>>>> of the various network connections, or can be ignored.
>>>>
>>>> For a development-only system, the iLO is akin to a backup. Handy to
>>>> have when something goes wrong, also handy for upgrades and for
>>>> restarting the host and for restarting the network stack, but probably
>>>> not used heavily otherwise.
>>>>
>>>>
>>>
>>> I need to do some TCP/IP research and development.  The Alpha doesn't
>>> get the latest stuff, and, I really need to be using the latest stuff.
>>>
>>> Didn't want the damn thing, but, I need to do the research.
>>>
>>
>> Can't you get involved in the "Early Implementer" stuff with VSI
>> and do your research on an X86-64 version?
>>
>> bill
>>
> 
> Not in the mood to do any testing of pre-release stuff.
> 
> I need to develop a better method of handling lots of socket connect 
> requests.  I also need to see if my ideas will work Ok.

How many are "lots of"?

> 
> Current thoughts are a single listener that validates requests, accepts the 
> connection, and passes it off to a worker process, then drops it's own 
> connection to the socket.  Involves some inter-process communications.  
> Listener might get rather busy, but will spend little time on each request.
> 

How are the clients deigned? Calls from Javascript running in browsers?
Are the clients your own applications too?

For the usual HTTP (and everything related to that) based communication
WASD will provide most of what you need out of the box. Have you yet
looked at WASD? What you describe as your "current thoughts" above
is just a description of how WASD works.

The WASD server is very stable. Mostly starts at boot and runs until
you reboot or shutdown. From our production box:

$ sh sys/proc=ht*
OpenVMS V8.4-2L2    25-JUN-2021 10:34:28.60   Uptime  802 17:00:25
   Pid    Process Name  State  pri      I/O   CPU           Page flts  Pages
00000452 HTTPd:80      HIB    4   36199885   0 00:44:26.89 10693      661
$


$ sh proc/id=00000452/acc

25-JUN-2021 10:34:46.99   User: HTTP$SERVER  Process ID:   00000452
                           Node: HV06         Process name: "HTTPd:80"

Accounting information:
  Buffered I/O count:  32823260  Peak working set size:      12464
  Direct I/O count:     3376625  Peak virtual size:         216496
  Page faults:            10693  Mounted volumes:                0
  Images activated:          29
  Elapsed CPU time:          0 00:44:26.89
  Connect time:            802 18:40:12.00

As you can see, it is the same "connect time" for the WASD server
as the "Uptime" for thr system.

$ write sys$output f$getsyi("boottime")
14-APR-2019 15:50:45.00
$


If I access one of our web addresses, I get a "worker process":


$ sh sys/proc=ht*
OpenVMS V8.4-2L2    6   25-JUN-2021 10:36:04.35   Uptime  802 17:02:00
   Pid    Process Name  State Pri      I/O      CPU       Page flts Pages
00000452 HTTPd:80      HIB     4 36200066  0 00:44:26.91     10693   661
000BF940 HTTPd:80-590  HIB     2     5761  0 00:00:03.35      6313  3426 M
$

The worker process stays alive for a configured time so the next
access is faster without any process startup. IF the worker process
has an active session when the next request arrives, a secons process
is started. All automatically handled by WASD.

In this case, the worker process is running a Python script, but it could
be any application writen in any language, of course. Probably with a
C-wrapper for the WASD CGI APIs.

I do not understand why anyone would prefer to write all this from scratch.

Regards, Jan-Erik.