In any event, one of the primary goals is to have as ingrained support for
IPMI as conserver has for telnet, with the same session multiplexing that
'rpower' and such can do.  ssh would still be a callout for now I think.

On the logging front, I was considering a lazier approach that would
defer/aggregate/compress data writes to filesystem.


From:   Egan Ford <[email protected]>
To:     xCAT Users Mailing list <[email protected]>
Date:   07/01/2013 03:07 PM
Subject:        Re: [xcat-user] conserver replacement



We have had a few scaling issues with large setups (4000+) with conserver
logging fulltime (often required for some large customers).  It was never a
problem with terminal servers, but when we started to use expect and
perl/ipmitool to automate BC and IPMI, then it started to get a bit
bloated.  But then again we were using the system call with many instances
of perl/ipmitool running.

Anyway I have no technical preference if you can make it scale.  If Perl
can do the job, with say, select, then great!

On Mon, Jul 1, 2013 at 12:51 PM, Jarrod B Johnson <[email protected]>
wrote:
  Debating between python, perl, and C.

  Inactive hide details for Egan Ford ---07/01/2013 02:44:50 PM---What are
  you going to write it in? On Sun, Jun 30, 2013 at 11:3Egan Ford
  ---07/01/2013 02:44:50 PM---What are you going to write it in? On Sun,
  Jun 30, 2013 at 11:38 AM, Jarrod Johnson

  From: Egan Ford <[email protected]>
  To: xCAT Users Mailing list <[email protected]>
  Date: 07/01/2013 02:44 PM
  Subject: Re: [xcat-user] conserver replacement




  What are you going to write it in?

  On Sun, Jun 30, 2013 at 11:38 AM, Jarrod Johnson
  <[email protected]> wrote:
  > I'm contemplating a conserver replacement.  There is sufficient
  > functionality I want to add and conserver is a tad inconvenient.
  >
  > conman wasn't appreciably closer than conserer toward the goals I had
  in
  > mind.
  >
  > So I'm considering making a new one.  The differences would be:
  > -IPv6 support
  > -Precise SSL client certficate authentication for SSL socket client
  > operation
  > -HTTP access (i.e. being an external FastCGI handler, interoperable
  directly
  > with shellinabox's javascript code).
  > -Baked in ipmi support in the same manner than conserver could do
  telnet
  > (i.e. fewer processes)
  >  -contemplating going a bit further by having non-console  IPMI
  commands
  > over the sessions and helping do some IPMI secret management and
  rotation to
  > implement IPMI more securely than is typical).
  > -SSL target support (e.g. smoother/possible consoles for KVM/ESXi
  guests,
  > where the target acts like a client rather than a server)
  > -Smoother configuration reload
  > -Exception-only logging (i.e. a logging option to request the console
  be
  > monitored for events like firmware errors or kernel oops and only log
  those
  > sorts of events)
  > -Improved logging performance and function.  Reduce IO cost per console
  > whilst adding more precise timing information (eschews plain text logs,
  but
  > would provide tooling to extract plain text logs optionally stripping
  > control codes alongside potentially a more accurate replaycons)
  >
  > I fully anticipate full logging whilst etiher a FastCGI or SSL socket
  client
  > is connected.  It would be site preference as to whether full logging,
  > exception-only logging, or no logging is performed while no clients are
  > connected to a given console, but hopefully the reduced IO cost and
  more
  > efficient IPMI console support renders it a less costly feature to
  enact..
  >
  > For authentication, aside from SSL client certs, would support
  user/password
  > auth with admin having the option to addiotnally require TOTP  (TOTP
  support
  > would have the secret encrypted using  user password as key).  The TOTP
  > algorithm would be interoperable with the Google Authenticator mobile
  app.
  >
  >
  ------------------------------------------------------------------------------

  > This SF.net email is sponsored by Windows:
  >
  > Build for Windows Store.
  >
  > http://p.sf.net/sfu/windows-dev2dev
  > _______________________________________________
  > xCAT-user mailing list
  > [email protected]
  > https://lists.sourceforge.net/lists/listinfo/xcat-user
  >

  ------------------------------------------------------------------------------

  This SF.net email is sponsored by Windows:

  Build for Windows Store.

  http://p.sf.net/sfu/windows-dev2dev
  _______________________________________________
  xCAT-user mailing list
  [email protected]
  https://lists.sourceforge.net/lists/listinfo/xcat-user



  ------------------------------------------------------------------------------

  This SF.net email is sponsored by Windows:

  Build for Windows Store.

  http://p.sf.net/sfu/windows-dev2dev
  _______________________________________________
  xCAT-user mailing list
  [email protected]
  https://lists.sourceforge.net/lists/listinfo/xcat-user

------------------------------------------------------------------------------

This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
xCAT-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/xcat-user

<<inline: graycol.gif>>

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
xCAT-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/xcat-user

Reply via email to