Password rules may be relevant to some scenarios. In such a case, this
can provide guidance if the BMC does not have such a facility or
alternatively provide friendlier warnings than the BMC provides
around shortcomings of the password.
It was frequent that a token expiration would impact attempt to convert
an account. Suppress the token based authentication to more reliably
have a fresh login.
Additionally, mitigate chance of exhausting user login limit.
Finally, switch to a generated password for the temporary account. Should something go awry
between deleting the third-party account and recreating it, this
means the system will have to be reset through OS or F1 menu. However this is better
than the risk of a well known backdoor account being inadvertently
created.
XML errors turn out to be unserializable. Catch this general
class of problems and provide a less devastating behavior.
Doing an xml.fromstring('') is an example of how to trigger it.
Some redfish implementations did
not handle a relatively open ended barrage
of concurrent requests. Try limitting to 4 concurrent
requests to evaluate how the implementations handle it.
For an SD530 XCC, we would incur 4 attempts at default:
-To pre-config enable SMM, we try once
-Due to pyghmi auto-degrade, try again as oper
-Then during the actual config phase, try again
-Again, try again as oper
Now with pyghmi opt-out, we will force to try only as admin, eliminating the second try.
The SD530 code will now mark that the default creds failed so that
the config phase will know to skip that.
To improve the ease of use, if an administrator has a collective but
does not designate a collective.manager for a node being discovered,
default to the collective member that executes the discovery.
To improve the ease of use, if an administrator has a collective but
does not designate a collective.manager for a node being discovered,
default to the collective member that executes the discovery.
Provide foundation for node renaming, including
updating groups and inheritance and notifying collection
watchers of the change, and updating the existing watchers
with the new notification fingerprint.
A confluent nodegroup may either be a normal static one, which
can be used for attribute inheritence, or a dynamic one, which
cannot be used with static list or static attributes.
Warn the user when they try to set that up to make it more obvious
that the dynamic groups can't do what they are trying to do.
In the event of an unanticipated firmware exception,
capture to log. Expected error conditions should have specific handlers
to avoid the tracellog treatment.
Since everywhere else accepts noderange, it is a reasonable
expectation for the nodes attribute on nodegroups to also
take a noderange. Correct this inconsistency.
If filesystem is full, this could be a side effect that would impact
a later start in a collective context. This mechanism induces repair
from a collective peer.
Particularly in trying to support license keys, serial number
handling is at least required. Easiest and most powerful and most
consistent path is to use the same attribute expansion as everywhere
else.
Commit to repository, even though not yet used. It is likely to
be renamed. The purpose is to help generate an appropriate self signed
cert for https including all the ip addresses as subject alternative
names so that names or addresses may be used with installers that
have had the cert injected.
For contexts where early execution execution almost always means
some sort of error, but the terminal automatically closes,
provide a minimum time to execute option so confetty will
forcibly slow things down in such a likely scenario.
Without incurring execution penalty, endeavor to sort available
data in an opportunistic way. This certainly does not guarantee order,
but it makes it highly likely for quick queries to appear orderly.
While we do not have a path forward for auto-resize in SOL consoles,
we can provide the capability for ssh consoles. The CLI being enabled
is of course nice, but running ssh directly is still suggested in such
a context and ultimately the Web GUI will be the most prominent
consumer of the information.
There are circumstances where the advertised IP is
useful information, even if that IP cannot be validated.
It is also the case that most of the time the advertised IP
is useless if not validated, so it is an optional field.
Have the cache operate against the sha256 of the passphrase rather
than the passhprase directly (mitigate presence of password in memory).
Pull PAM into the cache behavior to accelerate PAM based usage.
Rearrange things so that both built in confluent and PAM passwords
can be used.
This causes the manual assignment to sleep less and for the rescan
command to meaningfully slow down shell requests to provide better sense
of when scan completes.
In a confluent2lxca scenario, it is highly probably that confluent's
attribute is not viable for LXCA usage (link local address).
Give the current configuration the opportunity to replace the
confluent reference with the current IPv4 of the host.
The order argument only had any meaning when used in custom fields.
Add a loop in the custom field agnostic section of the code to correct
the behavior.
This opens the path to more customized output and have the appropriate
formatting. Also revise the Tabulator code to more closely match
the original nodediscover list output.
Various behaviors break if the administrator declares a chain goes
to nowhere, throw up an error and hopefully see it caught to detect
this misconfiguration.
nodehealth adds granularity and health to the return code.
Rather than only reflecting failure running command, also
have nodehealth assign exit code according to the expectations
of nagios.
This concept is potentially problematic, as a volume named 'all' is
valid. Additionally, if really wanting all, the caller probably wants
the full storage configuration, better provide that up a level to
avoid requiring many calls to do that.
When confetty exits without doing anything, it causes
sockapi to reference an empty request. Check for that before
checking if it is a collective request.
The BMC is at much higher risk for rejecting the password
(e.g. the password does not pass complexity requirements). If the
username changes, but the password is still default, it is very
confusing. Give the password change the chance to break the
configuration process first.
One, make the tracking bools enforce a lock to reduce confusion
Treat an initializing peer as failed, to avoid getting too fixated
on an uncertain target.
Make sure that no more than one follower is tried at a time by
killing before starting a new one, and syncing up the configmanager
state
Decline to act on an assimilation request if we are trying to connect
and also if the current leader asks us to connect and we already are.
Avoid calling get_leader while connecting, as that can cause a member
to decide to become a leader while trying to connect, by swapping
the reactions to the connect request.
Avoid trying to assimilate existing followers.
Fix some logging.
The initialization lock is meant to avoid collective and generic
initialization stepping on each other. This is somewhat reduced in
efficacy if one has a sync running while the other is changing relevant
data.
When the client is a proxy term, disable ability to produce
proxy terminals. This was wreaking havoc with client
count with ghosts and triggering output multiplication.
When doing snmp, messages would always go to log only, even if the
user was at the confetty cli. Give user access to knowing the error
impacting the query.
Move collective manager and configmanager to share a configinitlock,
so that bad timings during internal initialization and collective
activity cannot interfere and produce corrupt database.
This became an issue with the fix for 'everything' disappearing.
If a confluent instance has forgotten the collective, more cleanly
handle the situation, and abort the assimilation rather than assuming
the peer should be leader, unless txcount specifically is called out
as the reason.
If a confluent instance has forgotten the collective, more cleanly
handle the situation, and abort the assimilation rather than assuming
the peer should be leader, unless txcount specifically is called out
as the reason.
This provides an ability to designate the desired rules that
are applied in the wake of automatic discovery. The most popular
would be 'expiry=no,loginfailures=0'
For certain attributes, notably passwords, it is sometimes desirable
to prompt interactively to help facilitate keeping such data out of
bash_history, screen sharing, and ps output. -e enables this if the
user is aware of how to use 'read', -p is a quicker way to enable this.
For the 'by-mac', only remove the structure when it is ready for API
view without changing internal view.
For the 'by-switch', do the update per switch and after it's done.
Provide ability to check scan status through reading
/networking/macs/rescan
It shouldn't be possible for this to be the case, but out of an
abundance of caution, check for this. So far only produced this by
forcing broken = True in a debug session. Intended to catch an alleged
scenario where console was managing to use a broken session (fixed in
pyghmi) and have confluent also recognize the situation for non-console
usage).
Through an unknown set of circumstances, an solconnection could be
stuck 'connecting'. In every case analyzed, the ipmi_session was
broken. Use that to detect a class of failure and react appropriately.
Exceptions on collective calls were not correctly handled, fix
the handling so that collective continues and also the calling function
is correctly given the exception.
Fallback would do nothing to fix a persistent problem with an IPMI
session. For lack of knowing how to avoid the situation, at least
make changes so it won't go wrong in the future.
If a sync is in progress, wait for that to complete.
Then issue the requested *new* sync.
Probably only needed if fullsync, as the one in progress may be a
'dirty' only sync and fullsync would be satisfied by the partial sync
without it, which is bad.
First the data was not actually being staged in the rollback area.
Secondly, there wasn't an assurance that the disk wouldn't have rollback
committed...
If client has higher transaction count, do not close the connection
before extracting peer address.
If our connect session is rudely terminated, abort rather than trying
to continue.
On assimilate failure, ignore a failed assimilate with no data.
Fix problem where a follower getting double deleted was causing an error.
Cryptodome is a modern, but compatible replacement for pycrypto.
We may move to cryptography eventually, but start with this for now
for some nice speedups in some cases.
For one, configmanager was left with stale callback references, clean
those up.
For another, the callback pattern was creating a circular reference that
python memory management couldn't overcome. Break the reference
explicity when an item is disposed of.
For one, configmanager was left with stale callback references, clean
those up.
For another, the callback pattern was creating a circular reference that
python memory management couldn't overcome. Break the reference
explicity when an item is disposed of.
In the wake of leader loss, the assimilate attempt was causing one
of a couple of bad behaviors, a trace if broken and if it should
work, the format of the data payload was incorrect.
Startup was foiled when one entry was bad. Also add comments
on invite/join needing to be done from current leader, and the need
for better error messages.
Inputdata needed to be serialized for the network. Further, had
to have a JSON-safe payload for indicating name for certificate look
up, to avoid doing pickle load on client input prior to client
validation.
This will keep consoles connected across a manager change. Note
that as it stands, a console session enduring multiple changes will
become increasingly convoluted as the redirect chain will increase
every time, rather than shorting back to the entry point.
Backups should carefully protect keys.json, but that's only feasible
interactively. However keys don't change, so have a way to combine
protected keys.json with password with relatively safe non-interactive
incremental backups.
The db dump function did not trigger the init() function.
Rearrange the collective section to occur after a section that does
ensure the configmanager is initted.
Manual discovery may 'catch' some incidental data from auto-discovery.
Since the operation is manual, trust the user rather than assume the
user is confused.
Manual discovery may 'catch' some incidental data from auto-discovery.
Since the operation is manual, trust the user rather than assume the
user is confused.
For requests that must be routed to a definitive owner (e.g. IPMI),
have an attribute to track the currently responsible server for
singleton operations.
Some switches send raw octets back, some printable. Try to normalize
when unprintable chassis id are detected. This is not 100%, if the hex
would be all between 20 and 80 throughout the string, then this will
fail to do the right thing.
Hopefully, the amount of times when lldp partners disagree on how to
implement LLDP-MIB will be limited. Currently it is known than Lenovo
and Juniper switches disagree, and both of those have what would
be unprintable values in the mfg portion of the chassis id.
Some switches send raw octets back, some printable. Try to normalize
when unprintable chassis id are detected. This is not 100%, if the hex
would be all between 20 and 80 throughout the string, then this will
fail to do the right thing.
Hopefully, the amount of times when lldp partners disagree on how to
implement LLDP-MIB will be limited. Currently it is known than Lenovo
and Juniper switches disagree, and both of those have what would
be unprintable values in the mfg portion of the chassis id.
Useful for some generic applications where nodediscover
does not have full support, but must be used with care
as it doesn't guarantee the mac address is what we expect
it to be.
Useful for some generic applications where nodediscover
does not have full support, but must be used with care
as it doesn't guarantee the mac address is what we expect
it to be.
Putting thoughts down on how xmit will work, will add recv and relay,
do some testing, and then decide how much can be done to apply it neatly
to the various points.
This marks the start of attempting to connect the invitation
to sockets and using the invitation to measure the certificates as
well as proving client knowledge of an invitation token.
This facilitates the generation of invitations and logistics of proving
knowledge of the invitation and the integrity of the certificates.
peercert is to be gotten through getpeercert(binary_form=True) and
local cert through the util function to load from file, since we don't
have another way of getting local certificate.
Putting thoughts down on how xmit will work, will add recv and relay,
do some testing, and then decide how much can be done to apply it neatly
to the various points.
This marks the start of attempting to connect the invitation
to sockets and using the invitation to measure the certificates as
well as proving client knowledge of an invitation token.
This prevents the useless networking socket from being opened
when it cannot be used. This means most implementations will not
have an extra port to explain unless the user goes through the work
and knows what it would be.
discovery autosense at scale may produce undesirable performance.
Provide an interface to turn off the autosense.
If autosense is off, manual scan can still be performed.
This facilitates the generation of invitations and logistics of proving
knowledge of the invitation and the integrity of the certificates.
peercert is to be gotten through getpeercert(binary_form=True) and
local cert through the util function to load from file, since we don't
have another way of getting local certificate.
If someone does a reopen, try to preserve the buffer, unless connect
proves there to be a deeper issue. The risk of staleness is low, but
the experience of the whole screen clearing is tricky. This was not
such an issue at the time, but using pyte causes clearbuffer to also
clear connected client terminals.
If someone tries to use this with pasu syntax, try to do the right
thing. Similarly, if trying to paste the same syntax nodeconfig
uses on output, tolerate that as well.
First, refactor the attrname translation to be in a single method.
Recognize if 'None' comes back rather than a dictionary with na 'value'
Add a proper ValueError if an invalid attribute name is used.
Properly catch and transform ValueErrors in the API
It has been observed that a Lenovo XCC can fail to produce the
appropriate attributes in the SLP data. In such a case, and only if we
are in the preconfig path (which means it is a candidate for discovery),
reset the XCC to try to correct the behavior.
When certificate validation is not occuring in a secure fashion, make
it obvious to user through '(insecure)' flag. Lay the groundwork for
future update to actually provide a secure attach strategy, once the
firmware is willing.
If something happens to have the right ip, but no stored certificate
because it's not discovered, it was used as a data source if the
addpolicy was lax. Harden the flow by skipping unverifiable parts
of the chain.
Also apply fixes and lay groundwork for eventual 'secure' discovery
policy. As such a policy is too limited to be practical at this point
(SMM only) the full deal is postponed until it would be feasible.
This does not actually allow config deployment, but it can help in
ascertaining access for manual access to a switch.
A proper 'handler' will come later to add configuration, probably with
an emphasis on CNOS rather than ENOS.
eval_node can establish that this is a direct discovery attempt.
In that specific context, the check can be performed. Otherwise,
we can't check in this way, but the enclosure manager should raise the
error on behalf of the rest of the situation.
The _group function was not using fixup_attribute, add that.
Additionally, on the clear_ functions, use the aliases to make clearing
work with the shorthand as well.
First, globbing can only be the cause of a mess up if the given
noderange is a file that matches.
With this we still have:
for node in $(nodelist compute); do nodepower $node; done
As a potential false positive if any node is a range.
For this, offer suggestion of changing directories.
Also, if it had been:
for NODE in $(nodelist compute); do export NODE; nodepower $NODE; done
Another clause can detect that, which has been added.
In various scenarios, too many macs on a port can be a sign of trouble.
For example, a chained SMM configuration with head on switch port, or
incorrectly pointing a nodes net attributes at a switch uplink port, or
defining SMMs without any nodes, causing XCCs to think they are
rackmount. This sets some sanity value for avoiding problems. This is
of course a mitigation, invalid scenarios could still run afoul of the
limits, but it should catch a large chunk of offending scenarios.
The suppression was unable to be accomplished for bash without
somehow otherwise breaking the shell. zsh and csh could be better at
one-off glob disabling though.
If output comes close enough together, make some effort to group it
so that it will have a higher tendency of looking orderly. This of
course only does so when it does not interfere with quickly presenting
the data.
If a session is closed, also kill off any associated
relays in progress. One exception, video port relay
in ESTABLISHED is left alone due to limitation, but
at least no new open.
When serving multiple browser, limit a forwarder to only the specific
client that authorized that forwarder. Previously, one client was
allowed to access another client's forwarding port if it happened to
know the location.
While we are limited to one 'listen' target at a time, we can
qualiify by the source address to at least provide distinct
behavior depending on the client.
This prevents sockets from opening up to the world that could be used
to connect to management interfaces directly, apart from the specific
requestors.
This should be a more bulletproof place to be. Note that it used
to be here and was moved because pyghmi used to call oem_init, but
pyghmi has been changed for a long time to no longer have that
requirement.
To keep the concurrent update level to a fairly widely attainable limit,
impose 256 at a time limit. This is a gigantic improvement over most
previous circumstances still, and can comfortably accommodate three of
the most dense racks at a time.
Web forward from popup context requires it be exempt from CSRF
protection. This is harmless (as all GET should be, but erring on side
of caution), so add it to the whitelist of CSRF skipping on a CSRF
enabled client session.
Switches need some data sanitized. Also used IndexError instead of
KeyError, and add handling for interfaces with slashes in the name.
The name 'verified' also fits better than 'authenticated'
Instead of *just* being able to search by uuid for pxe,
add the ability to search by uuid for https things, if no fingerprint
match.
This allows remote xcc setup to follow in the wake of a pxe attempt.
Situation of filehandle exhaustion was seen. In the scenario observed,
multiple connections to the same target were seen. So:
1) Backout the recheck block and replace with more comprehensively
placed semaphore.
2) Place a discovery pool limit of 500 to generally constrain things.
3) Further limit things to one detected thread per mac address
If there is an existing DB, there were race conditions in loading the
restore. Fix by clearing the existing DB once the viability of the
restore dataset has been established
While we cannot get serial number and model number in a PXE request,
if there is a matching uuid, fill in the data from the match. Also
provide info on the related macs so that info can be correlated in more
complex ways (e.g. which mac is pxe, which mac is BMC, which IP goes
where, etc.)
Various commands may (accidentally or intentionally) encounter
non-ascii data. While python stdout without pipe is fine, when piping
it assumes ascii. Fix this to always assume utf-8 explicitly.
Some things on update are active immediately, others are pending reboot.
Documentation needs to use this to let users know what they need to do
or not need to do after the firmware update.
Lay groundwork for pulling this sort of data in on discovery. The plan is that *if* serial numbers will
be used as a cue for discovery, it would be in the context of a nodediscover command.
Often times, a pyghmi update carries the substance of
a patch. Instead of a person having to remember to
manually restart, try to trigger an update to restart
confluent automatically.
In the case of execing to ssh, preserve literal argumants since
ssh is going to parse them. Pre-parsing will cause ssh to strip out spaces, for example.
If a node is deleted, act similar to if it were defined with no console.method, to avoid
superfluous trace output. In the future, it may make sense to filter out nodes with no
console.method earlier, since a fair amount of startup work is done that is ultimately ignored
for situations where console is not enabled.
The data length of a log entry must not exceed 65k. If an attempt is
made to log that much, break it up and duplicate the records. It may make
sense to indicate a continuation explicitly, but for now just extend.
str will tend to present a more normal looking error string. Use
that so that a user does not have the impression there is a code
issue on expected errors.
Some processes (e.g. nodefirmware update) warrant a different sort of
strategy to try to abbreviate, where collation falls short. For this,
provide a columnar output that changes to line by line if stdout is not
a terminal.
The bay number can be opportunisticly grabbed, provide
that info in the discovery api. In future, should add 'by-bay'
once we have enclosure data as well.
The data length of a log entry must not exceed 65k. If an attempt is
made to log that much, break it up and duplicate the records. It may make
sense to indicate a continuation explicitly, but for now just extend.
If an administrator clears the cert fingerprint, they will
likely set it to ''. In such a case, go down the 'no fingerprint'
path rather than reject it.
enclosure.bay is integer rather than string now. Fix the filter
to use format, which is more robust in numeric versus string anyway.
Also, consistently make the underlying data integer rather than
sometimes string.
If even one of a noderange failed to complete the
set boot device step, none would progress. Change
the behavior so that exit code still happens and
processing does stop on timed out nodes, but go
ahead and reboot those that were fine.
Sometimes in a likely mismatched IP situation, some SLP things will manage to reply and slow
down. For now in the case of mismatched IPv4 being likely, provide a mode fixated on link local.
noderanges use [], and bash can do undesirable things.
Since these commands by and large do not reference files,
or at least files likely to be globbed, disable globbing.
Provide a different scheme that does not involve a wait(), if by chance
the flow dies without getting back to our thread. wait() has no timeout
so this is a strategy to cope by making sure we hang for no longer than
3 minutes, which is well beyond any time a login should possibly take.
While it may not have been possible in eventlet for this to happen,
strictly speaking if it were a thread, it could exit during check for
liveness and leave data on the queue.
To be careful, also drain the queue after all children dead.
Provide a more concrete measurement of
children, rather than relying upon a
sentinel value on the queue. It seems
that even using 'finally' didn't assure
that we always get that sentinel value
before a worker dies. Sentinel value
still used to avoid a long wait in the
usual case.
If something went completely off the rails, it could easily fill up lots of memory with log entries in the 2 seconds it
would buffer. For now disable the buffering on key debug logs, as the main purpose was reducing IOPs in the per-node
console logs anyway. A future behavior may be to also limit the size and/or number of outstanding log entries before
committing to disk.
Most of the time, we don't need this pool. Create when needed,
and clean up after 30 seconds of inactivity. This avoids a slow
shutdown that was due to core python hanging in help_finish_stuff,
and as a bonus means most of the time, one only sees one confluent
process, which has been a source of questions already.
A redacted dump will not have a keys.json file, which
is natural. Replace 'file not found' with a message
indicating the possibility of a redacted dump.
If a caller (reasonably) broke out of a loop, a subsequent call would get old data.
Protect against this by discarding data not consumed if previously called.
A redacted dump will not have a keys.json file, which
is natural. Replace 'file not found' with a message
indicating the possibility of a redacted dump.
Wait until the object is logged in before trying to set
the key handler. It carries some prerequisite on talking
to the BMC, so it is better handled in the logged handler.
If a socket error occurred that wasn't -2, the client would get an error
about KeyError, which wouldn't be helpful. raise the unhandled exception
to provide more informative data in case of an issue.
This has no functional difference, just a cosmetic
difference that does not give the erroneous impression
a logout actually occurred. This does mean that if a browser
disables cookies and uses the api explorer, there would
be an opportunity for a CSRF.
At some expense of convenience, make it difficult
for CSRF to succeed even against the API explorer
for most people. User/Password will now only be
accepted on hitting enter in the address bar rather
than following any link.
Regardless of whether the client uses it as a session id
or not, the fact remains a sessionid is assigned.
Pass the session id in the auth data even if the client
did not send it.
If a user requests an interval that is not a whole
number, begin honoring it and adjust the timestamp
precision to indicate milliseconds. Do not bother
with milliseconds on whole number intervals.
Clients may now format a string as if it were to be an expression for an attribute,
and have the server evaluate it using the same engine without passing through the
attribute engine. This makes it easier, for example, to do nodeexec n1-n4 ipmitool -H {hardwaremanagement.manager}
For reasons not entirely understood, we can
have an ipmi command object without registering
a key handler. Unconditionally register the key handler
on each use of the command object. This still saves the
network load of logging in, so it's not a terrible workaround.
When a message is used that would raise an exception in a singleton
case, make available the appropriate apicode in contexts that would be
relevant (namely multi-node operations and all asynchttp).
This makes the exceptions more self describing and simplifies httpapi and sockapi.
An important step to improve asynchttp conveyance of error data that would normally
be an http error in synchronous operation.
Enable a WebUI to request an auth token. This will allow it to indicate it is running in a browser and have the server implement protections such that
other software in the browser cannot send arbitrary requests into the server API.
This is implemented in a backward compatible fashion, allowing, for example, purely non-browser clients to ignore the CSRF protection as
it doesn't apply to that use case.
Consoles starting up would potentially delay API availaility. Change
by having the API having ample time to startup, then commence the
busy work of starting cnosole sessions.
Do a better job of cleanly handling scenarios
where disconnect would come from a session currently
disconnected. Inside the ipmi plugin, suppress a
disconnect event if one has been sent. Inside
consoleserver, surpress logging a disconnect when
already disconnected.
Originally was going to skip the reconnect, but that would
mitigate recovery. Hopefully supressing the duplicate
disconnect in ipmi plugin, and some fixes in pyghmi will
avoid a 'double connect' scenario.
If python system module had a name that conflicted in some way
with a plugin, the plugin load would fail. Fix this by prioritizing
the plugin path over system locations. Also, to avoid the breakage
going the other way, remove the plugindir from the system path when
that particular directory is done.
HTTP console API did not have a means to send break
or request session reopen. Rectify this discrepency
by adding an 'action' key to request certain console
specific actions. In retrospect, closing the session
should have just been an 'action', but leaving things
as-is.
In the common case, we were falling through the bottom
without an explicit return. Restructure things to both
explicitly return and look a bit more sane.
The Attributes management class was making shared shallow
copies. This caused a problem when attributes class assumed
it could modify the result. Correct by providing a deep copy
of that node's data when it is requested.
This brings things right to the level of xCAT in
terms of underlying capability. mac addresses have both
an all inclusive list of ports it is found on, and any nodes
that it matches. It goes another step further by logging errors
when ambiguity is detected (either verbatim config conflict or
ambiguous result based on 'namesmatch' and the switch config).
One, include a number of 'fellow' mac addresses on the same port.
Another, allow a mac to appear on multiple ports and have that
reflected in the data structure. Also capture errors to trace
log rather than hanging up on unexpected cases.
Wire up the singleton switch search function to a function that
extracts list of switches and relevant auth data from the config
engine. Add attributes to allow indication by hardware management
port connection. The OS nics will be added later for in-band discovery,
but that's of limited value until PXE support anyway.
This time, the update function is a generator that yields as a sign to caller
that the mac map has had at least a partial update to be considered.
As we implement internal processes with automation,
provide a hook for code to convey information about
situations encountered during background activity.
Ultimately, it is intended to hook event forwarders
for things like syslog/email/etc
Refactor the snmputil to be object oriented to simplify upstream code. Implement
a method to generate a mac address to ifName/ifDescr for a given switch.
On the path to instrumenting network switches, first
we'll add some framework for SNMP. Given that we are
using eventlet and thus we need a patchable SNMP,
we employ PySNMP, despite it being a bit peculiar.
This commit tucks away the oddness and makes it
pretty easy to use for our purposes.
This brings things right to the level of xCAT in
terms of underlying capability. mac addresses have both
an all inclusive list of ports it is found on, and any nodes
that it matches. It goes another step further by logging errors
when ambiguity is detected (either verbatim config conflict or
ambiguous result based on 'namesmatch' and the switch config).
One, include a number of 'fellow' mac addresses on the same port.
Another, allow a mac to appear on multiple ports and have that
reflected in the data structure. Also capture errors to trace
log rather than hanging up on unexpected cases.
Wire up the singleton switch search function to a function that
extracts list of switches and relevant auth data from the config
engine. Add attributes to allow indication by hardware management
port connection. The OS nics will be added later for in-band discovery,
but that's of limited value until PXE support anyway.
This time, the update function is a generator that yields as a sign to caller
that the mac map has had at least a partial update to be considered.
As we implement internal processes with automation,
provide a hook for code to convey information about
situations encountered during background activity.
Ultimately, it is intended to hook event forwarders
for things like syslog/email/etc
Refactor the snmputil to be object oriented to simplify upstream code. Implement
a method to generate a mac address to ifName/ifDescr for a given switch.
On the path to instrumenting network switches, first
we'll add some framework for SNMP. Given that we are
using eventlet and thus we need a patchable SNMP,
we employ PySNMP, despite it being a bit peculiar.
This commit tucks away the oddness and makes it
pretty easy to use for our purposes.
This is a resource consumption problem. Defer such measures until later.
Investigation uncovered that there may have been another culprit anyway,
will see if only the other change (to kick a zoned out connection attempt)
suffices.
Occasionally it was observed that systems would be just stuck in 'connect',
provide a backup system to detect and forcibly kick the console in such a case.
In theory, pyghmi should be doing a self-health check. It has been discovered at scale that
this self-health check may encounter issues. For now, try to workaround by having another
health check at the confluent level, deferred by console activity. It's also spaced far apart
so it should not significantly add to idle load (one check every ~5 minutes, spread out).
Many sensors in nodesensors are not useful except when
evaluated as part of nodehealth. Provide an option to allow people
to skip such sensors. Particularly useful in generating time series CSV
data.
Previously, offline nodes would be rechecked automatically on average every 45 seconds. Extend this
to on average 180 seconds, to reduce ARP traffic significantly when there are a large volume of
undefined nodes. The 'try to connect on open' behavior is retained, so this would mean a longer loss
of connectivity only in a background monitored session.
Knowing ahead of time that confluent is the sort of app that, despite
best efforts, is filehandle heavy, auto-attempt to raise soft to
be equal to hard limit. A sufficiently large cluster (i.e. more than 2000
nodes) would still need to have limit adjusted at system level for now.
Sometimes a collection will be slow. Don't inflict the 'cd' with the slowness, defer until actually
asked to do something that would enumerate said collection. Accomplish this by checking for
the 'cd' target in it's parent collection, rather than asking to list its contents.
gdbm backend does not support the 'iterkeys' interface directly,
requiring instead to manually traverse. Unfortunately, dbhash
does not implement the gdbm interface for this, so we have
to have two codepaths.
Now that the problematic use of an os pipe is no more,
go ahead and patch pyghmi in a straightforward way. This
was needed for the sake of pyghmi plugins that use a webclient.
If a plugin iterates a datetime object, decode to ISO-8601 string
on the way out. This allows plugins to work directly with datetime
objects and allow the messaging layer to normalize it to ISO-8601
Messages that were not a node (e.g. confluent users) erroneously
had data put into 'databynode'. Correct the mistake by omitting
the insertion of databynode when the message is clearly not a node
related thing.
IPMI plugin was issuing redundant calls to remove the same
watcher. Track that a session has already unhooked to
avoid double unhook (which runs at least a slight risk
of unhooking the wrong handler (*if* it were allowed).
IPMI health requests are relatively expensive. It's
also pretty popular and therefore prone to be the target of
inadvertantly aggressive concurrent requests. Mitigate the harm
by detecting concurrent usage and having callers share an answer.
When receiving a USR1 signal, it did usefully provide
'the' current stack, useful for diagnosing really hard
hangs. However, it's frequently informative to see all
the thread stack traces, so add that data to the diagnostic
feature.
When a terminal closes and notifies server, it was
pulling the rug out from asyncsession consoles.
Make asyncsession aware that the console may be gone
and discard tracking it rather than give a 500.
When an error (to be fixed) happened while updating expiry,
an asyncsession failed to have a reaper scheduled for cleanup.
Correct this by putting the reaper schedule right after the
cancellation.
Further, an async being destroyed did not reap related console
sessions. Add code to reap related console sessions when
the async session gets destroyed.
When the read_recent_text ran off a cliff looking for buffer data,
it left the current textfile handle in a bad state. This caused
the buffer rebuild to fail completely in a scenario where all the
current logs put together don't have enough data to satisfy the
buffer. Fix this by making the handle more obviously broken, and
repairing while seeking out data.
Users have noted and complained that log data was lost, and didn't have old data. This changes
the default behavior to be indefinite retention. Users noting a lot of logs using space have a nice
intuitive indication of old files to delete, and the option remains for those to request a log expiration.
Before the connection would fail and log to trace without anything
particularly informative for the client (they just saw 'unexpected error'.
Provide a more informative behavior for the client.
If exiting from a shell session, the databuffer will contain needed info for the client
to work properly. Preserve databuffer existence. Responsibility for deleting the
object should be in the hands of the caller.
The rollback support and replaydid not follow more than one log back. Do the work to recurse
into older and older files, until big enough buffer or run out of files.
If a user can connect, but gets removed mid session, traces were
being generated. Correct by recognizing the circumstance and returning
the appropriate error to the client.
When initializing security key, a background thread may occur. Sometimes,
the system would go to daemonize while that thread was still running, and
the whole system could exit. Leading to incomplete write to globals as well
as leaving the daemon looking at the data copied over from pre-fork and
seeing the last state of that thread forever frozen. Make sure the background
threads are fully done prior to exiting.
It seems it is possible in some circumstance for the thread id to become stale,
perhaps due to a different threadid executing the code for some reason.
Just in case, ensure the same exact value that was added is later discarded.
This provides a method for client to request session be closed down. This provides more
immediate responsiveness to the client count when closing such a terminal. With this
both closing a single window and doing a 'logout' immediately impacts clientcount.
If something triggers a logout of session, immediately cut into long polling
console sessions that are relevant. This results in web client being able to
immediately detect a logout externally originated.
Provide a means for an http request to erase
it's own session's validity. Always return 200
to allow a client to send bogus credentials and
think they got success to forget the auth data in
the browser.
A javascript client running in browser may want
the standard authorization header suppressed.
This allows a client to block the default browser
authentication prompt.
Like self-signed TLS certificates, SSH host keys
warrant a similar security policy. This implementations
follows the lead of the TLS management and uses the same
policy name and interpretation, just storing the value
in 'pubkeys.ssh' for the node rather than an extensible
set of entry points (for now).
Previously, was using counters to track the relation, also had distinct tracking of users versus
callbacks. Unify the callback and user into a single 'session' attach and then use the size
of the set of sessions and their declared users rather than trying to maintain a counter on the side.
This change simplifies the relationship, changes away the logging and clientcount counter for
a more robust strategy, and paves the way for the dependent ShellHandler to terminate connected
sessions when the shell session dies.
Unlike consoles, where the underlying concept is a real
persistent thing that needs some care to reattach to watch,
a shell session should die when it is lost, as a new one would
have to be created anyway. Modify the disconnect behavior
for a shell session to set closed and notify the receivers.
It should also reap dependent watching objects in a future
change.
This causes some additional features into core. Namely
the ability to use a fixed module rather than a string
defined plugin. This allows shellserver to implement the
'plugin' interface without living in 'plugins'. 'plugins'
implies modularity and potential eventual choice, but
this functionality is core. It would make sense for the
'attributes' plugin to be changed to match this strategy.
When a shell session is initiated, it registers
a recipient at the same time it would be trying
to establish session for not being a 'wait for
recipient'. Aggressively mark the state as connecting
to avoid the recipient erroneously thinking things have
not be set into motion yet. Additionally, have the ssh
plugin avoid a traceback when disconnecting before completing
connection.
Have httpapi recognize the difference and start a shellserver
session when appropriate. Next step will be to wire up enumeration of
current shellserver sessions, debug ssh.py traceback, delete on remote
close, and auto-delete when no client connected after some interval (e.g.
30 minutes).
UUIDs when a simple number will do are harder to use.
Change to a simple increment id. This could cause an issue
with multiple management nodes, but I think the sessions
should be contained to the instance used.
console logging assumptions are not valid for shell sessions.
Correct by modifying the buffer init code to be conditional
and adding a stub 'log' to the ShellHandler class.
Provide a common 'shellserver' capability cloned off of 'consoleserver'.
This will enable the concept of per-user shells with option for multiple
shells per. Each user will have their own set of shell sessions rather
than shared across users. Can revisit in future if sharing between
users is desired.
Create a module that does ssh and treats it like
a console. The plan is to have a cliserver.py to
behave in a manner resembling consoleserver.py, but
with option to have multiple distinct sessions per
target.
Previously, was using counters to track the relation, also had distinct tracking of users versus
callbacks. Unify the callback and user into a single 'session' attach and then use the size
of the set of sessions and their declared users rather than trying to maintain a counter on the side.
This change simplifies the relationship, changes away the logging and clientcount counter for
a more robust strategy, and paves the way for the dependent ShellHandler to terminate connected
sessions when the shell session dies.
Unlike consoles, where the underlying concept is a real
persistent thing that needs some care to reattach to watch,
a shell session should die when it is lost, as a new one would
have to be created anyway. Modify the disconnect behavior
for a shell session to set closed and notify the receivers.
It should also reap dependent watching objects in a future
change.
This causes some additional features into core. Namely
the ability to use a fixed module rather than a string
defined plugin. This allows shellserver to implement the
'plugin' interface without living in 'plugins'. 'plugins'
implies modularity and potential eventual choice, but
this functionality is core. It would make sense for the
'attributes' plugin to be changed to match this strategy.
When a shell session is initiated, it registers
a recipient at the same time it would be trying
to establish session for not being a 'wait for
recipient'. Aggressively mark the state as connecting
to avoid the recipient erroneously thinking things have
not be set into motion yet. Additionally, have the ssh
plugin avoid a traceback when disconnecting before completing
connection.
Have httpapi recognize the difference and start a shellserver
session when appropriate. Next step will be to wire up enumeration of
current shellserver sessions, debug ssh.py traceback, delete on remote
close, and auto-delete when no client connected after some interval (e.g.
30 minutes).
UUIDs when a simple number will do are harder to use.
Change to a simple increment id. This could cause an issue
with multiple management nodes, but I think the sessions
should be contained to the instance used.
console logging assumptions are not valid for shell sessions.
Correct by modifying the buffer init code to be conditional
and adding a stub 'log' to the ShellHandler class.
Provide a common 'shellserver' capability cloned off of 'consoleserver'.
This will enable the concept of per-user shells with option for multiple
shells per. Each user will have their own set of shell sessions rather
than shared across users. Can revisit in future if sharing between
users is desired.
Create a module that does ssh and treats it like
a console. The plan is to have a cliserver.py to
behave in a manner resembling consoleserver.py, but
with option to have multiple distinct sessions per
target.
Create a module that does ssh and treats it like
a console. The plan is to have a cliserver.py to
behave in a manner resembling consoleserver.py, but
with option to have multiple distinct sessions per
target.
Create a module that does ssh and treats it like
a console. The plan is to have a cliserver.py to
behave in a manner resembling consoleserver.py, but
with option to have multiple distinct sessions per
target.
2015-10-21 13:42:31 -04:00
163 changed files with 21222 additions and 7999 deletions
**nodeattrib** manages the attributes of confluent nodes. In
the simplest form, it simply takes the given noderange(5) and lists the
matching nodes, one line at a time.
If a list of node attribute names are given, the value of those are also
displayed. If `-b` is specified, it will also display information on
how inherited and expression based attributes are defined. Attributes can be
straightforward values, or an expression as documented in nodeattribexpressions(5).
For a full list of attributes, run `nodeattrib <node> all` against a node.
If `-c` is specified, this will set the nodeattribute to a null value.
This is different from setting the value to an empty string.
Attributes may be specified by wildcard, for example `net.*switch` will report
all attributes that begin with `net.` and end with `switch`.
If the word all is specified, then all available attributes are given.
Omitting any attribute name or the word 'all' will display only attributes
that are currently set.
For the `groups` attribute, it is possible to add a group by doing
`groups,=<newgroup>` and to remove by doing `groups^=<oldgroup>`
Note that `nodeattrib <group>` will likely not provide the expected behavior.
See nodegroupattrib(8) command on how to manage attributes on a group level.
## OPTIONS
* `-b`, `--blame`:
Annotate inherited and expression based attributes to show their base value.
* `-c`, `--clear`:
Clear specified nodeattributes
* `-e`, `--environment`:
Set specified attributes based on exported environment variable of matching name. Environment variable names may be lower case or all upper case. Replace . with _ as needed (e.g. info.note may be specified as either $info_note or $INFO_NOTE
* `-p`, `--prompt`:
Request interactive prompting to provide values rather than the command line or environment variables.
## EXAMPLES
* Listing matching nodes of a simple noderange:
`# nodeattrib n1-n2`
`n1: console.method: ipmi`
`n1: hardwaremanagement.manager: 172.30.3.1`
`n2: console.method: ipmi`
`n2: hardwaremanagement.manager: 172.30.3.2`
* Getting an attribute of nodes matching a noderange:
`# nodeattrib n1,n2 hardwaremanagement.manager`
`n1: hardwaremanagement.manager: 172.30.3.1`
`n2: hardwaremanagement.manager: 172.30.3.2`
* Getting a group of attributes while determining what group defines them:
`# nodeattrib n1,n2 hardwaremanagement --blame`
`n1: hardwaremanagement.manager: 172.30.3.1`
`n1: hardwaremanagement.method: ipmi (inherited from group everything)`
`n1: hardwaremanagement.switch: r8e1`
`n1: hardwaremanagement.switchport: 14`
`n2: hardwaremanagement.manager: 172.30.3.2`
`n2: hardwaremanagement.method: ipmi (inherited from group everything)`
`n2: hardwaremanagement.switch: r8e1`
`n2: hardwaremanagement.switchport: 2`
* Listing matching nodes of a simple noderange that are set:
`# nodeattrib n1-n2 current`
`n1: console.method: ipmi`
`n1: hardwaremanagement.manager: 172.30.3.1`
`n2: console.method: ipmi`
`n2: hardwaremanagement.manager: 172.30.3.2`
* Change attribute on nodes of a simple noderange:
`# nodeattrib n1-n2 console.method=serial`
`n1: console.method: serial`
`n1: hardwaremanagement.manager: 172.30.3.1`
`n2: console.method: serial`
`n2: hardwaremanagement.manager: 172.30.3.2`
* Clear attribute on nodes of a simple noderange, if you want to retain the variable set the attribute to "":
`# nodeattrib n1-n2 -c console.method`
`# nodeattrib n1-n2 console.method`
`n1: console.method: `
`n2: console.method: `
* List all switches that a node is described as connected to:
`nodefirmware` reports and updates various firmware on nodes. By default it
will retrieve all firmware, but can be directed to fetch specific firmware by
calling out the name of the firmware (e.g. uefi or xcc) or request reading only
core firmware firmware by using the word 'core', which is generally a quicker
operation.
In the update form, it accepts a single file and attempts to update it using
the out of band facilities. Firmware updates can end in one of three states:
* `error`: The attempted update encountered an error that prevented successful install. Nodes experiencing this state will be reported at the end and more detail on the error will be given
* `pending`: The firmware update process has completed, but the firmware will not be active until the relevant component next resets. Generally speaking, for UEFI update the system will need a reboot, and for BMC updates, the `nodebmcreset` command will begin the process to activate the firmware.
* `complete`: The firmware update process has completed and activation has proceeded. Note that while the activation process has commenced, the component may still be in the process of rebooting when nodefirmware exits.
<noderange> is a syntax that can be used in most Confluent commands to conveniently specify a list of nodes. The result is that the command will be applied to a range of nodes, often in parallel.
## EXAMPLES:
The simplest noderange is a single node name:
`n1`
Nodes and groups may be used interchangeably. The following may be used in any context where n1 would be accepted as a noderange:
`rack1`
Commonly, there is a desire to target a range of elements. There are a few identically behaving syntaxes for the purpose.
`n1:n20`
`n1-n20`
`n[1-20]`
Note that numbers may be zero padded or not, it will automatically detect the padding amount and adjust members of the range accordingly. Ranges also can understand multiple numeric values changing:
`r[1-3]u[01-10]`
`r1u01-r3u10`
Ranges can also be applied to group names, and all above syntaxes are compatible:
`rack1-rack10`
`rack[1-10]`
Also, regular expressions may be used to indicate nodes with names matching certain patterns:
`~r1u..`
The other major noderange primitive is indicating nodes by some attribute value:
`location.rack=7`
The attribute name may use a wildcard:
`net.*switch=switch1`
Commas can be used to indicate multiple nodes, and can mix and match any of the above primitives. The following can be a valid single noderange, combining any and all members of each comma separated component
Exclusions can be done by prepending a ‘-‘ before a portion of a noderange:
`rack1,-n2`
`compute,-rack1`
`compute,-location.row=12`
To indicate nodes that match multiple selections at once (set intersection), the @ symbol may be used:
`compute@rack1`
`location.rack=10@compute`
For complex expressions, () may be used to indicate order of expanding the noderange to be explicit
`rack1,-(console.logging=full@compute)`
Noderange syntax can also indicate ‘pagination’, or separating the nodes into well defined chunks. > is used to indicate how many nodes to display at a time, and < is used to indicate how many nodes to skip into a noderange:
`rack1>3<6`
The above would show the seventh through ninth nodes of the rack1 group. Like all other noderange operations, this may be combined with any of the above, but must appear as the very last operation. Ordering is done with a natural sort.
'description':'Policy to use for auto-configuration of discovered '
'and identified nodes. Valid values are "manual", '
'"permissive", or "open". "manual" means nodes are '
'detected, but not autoconfigured until a user '
'approves. "permissive" indicates to allow discovery, '
'so long as the node has no existing public key. '
'"open" allows discovery even if a known public key '
'is already stored',
'validlist':('manual','permissive','pxe','open'),
},
'info.note':{
'description':'A field used for administrators to make arbitrary '
'notations about nodes. This is meant entirely for '
'human use and not programmatic use, so it can be '
'freeform text data without concern for issues in how '
'the server will process it.',
},
'location.height':{
'description':'Height in RU of the system (defaults to query the systems)',
},
'location.room':{
'description':'Room description for the node',
},
'location.row':{
'description':'Row description for the rack the node is in',
},
'location.rack':{
'description':'Rack number of the rack the node is in',
},
'location.u':{
'description':'Position in the rack of the node',
},
# 'location.timezone': {
# 'description': 'POSIX timezone to apply to this node',
# },
@@ -147,11 +265,13 @@ node = {
'console.logging':{
'description':('Indicate logging level to apply to console. Valid '
'values are currently "full", "interactive", and '
'"none". Defaults to "full".')
'"none". Defaults to "full".'),
'validvalues':('full','interactive','none'),
},
'console.method':{
'description':('Indicate the method used to access the console of '
'the managed node.')
'the managed node.'),
'validvalues':('ssh','ipmi'),
},
# 'virtualization.host': {
# 'description': ('Hypervisor where this node does/should reside'),
@@ -175,54 +295,109 @@ node = {
# 'appliesto': ['vm'],
# },
'hardwaremanagement.manager':{
'description':'The management address dedicated to this node',
'description':'The management address dedicated to this node. This '
'is the address of, for example, the Lenovo IMM.',
},
'hardwaremanagement.method':{
'description':'The method used to perform operations such as power '
'control, get sensor data, get inventory, and so on. '
},
# 'enclosure.manager': {
# 'description': "The management device for this node's chassis",
'enclosure.bay':{
'description':'The bay in the enclosure, if any',
# 'appliesto': ['system'],
# },
# 'enclosure.bay': {
# 'description': 'The bay in the enclosure, if any',
},
'enclosure.extends':{
'description':'When using an extendable enclosure, this is the node '
'representing the manager that is one closer to the '
'uplink.',
},
'enclosure.manager':{
'description':"The management device for this node's chassis",
# 'appliesto': ['system'],
# },
},
# 'enclosure.type': {
# 'description': '''The type of enclosure in use (e.g. IBM BladeCenter,
#IBM Flex)''',
# 'appliesto': ['system'],
# },
# 'inventory.serialnumber': {
#'description': 'The manufacturer serial number of node',
# },
# 'inventory.uuid': {
# 'description': 'The UUID of the node as presented in DMI',
# },
# 'inventory.modelnumber': {
'id.model':{
'description':'The model number of a node. In scenarios where there '
'is both a name and a model number, it is generally '
'expected that this would be the generally more '
'specific model number.'
},
'id.serial':{
'description':'The manufacturer serial number of node',
},
'id.uuid':{
'description':'The UUID of the node as presented in DMI.',
},
# For single interface mac collection, net.bootable suffices
# For multiple interface mac collection, we perhaps add an address field and use subnet affinity as a clue
# to disambiguate multiple addresses for external provisioning
# For internal provisioning, the UUID matters rather than the MAC, though subnet affinity may
# still be a factor to select the appropriate static config to send down. In such a case bonding
# is hopefully more likely as that's a bit easier.
# Start with the first case and only document that, the other thoughts can be future items if they turn up
'net.bootable':{
'type':bool,
'description':'Whether or not the indicated network interface is to be used for booting. This is used by '
'the discovery process to decide where to place the mac address of a detected PXE nic.',
},
'net.ipv4_gateway':{
'description':'The IPv4 gateway to use if applicable. As is the '
'case for other net attributes, net.eth0.ipv4_gateway '
'and similar is accepted.'
},
'net.hwaddr':{
'description':'The hardware address, aka MAC address of the interface indicated, generally populated by the '
'PXE discovery mechanism'
},
# 'net.pxe': { 'description': 'Whether pxe will be used on this interface'
# TODO(jjohnson2): Above being 'true' will control whether mac addresses
# are stored in this nics attribute on pxe-client discovery, since
# pxe discovery is ambiguous for BMC and system on same subnet,
# or even both on the same port and same subnet
'net.switch':{
'description':'An ethernet switch the node is connected to. Note '
'that net.* attributes may be indexed by interface. '
'For example instead of using net.switch, it is '
'possible to use net.eth0.switch and net.eth1.switch '
'or net.0.switch and net.1.switch to define multiple '
'sets of net connectivity associated with each other.'
},
'net.switchport':{
'description':'The port on the switch that corresponds to this node. '
'See information on net.switch for more on the '
'flexibility of net.* attributes.'
},
# 'id.modelnumber': {
# 'description': 'The manufacturer dictated model number for the node',
# },
# 'inventory.snmpengineid': {
# 'id.modelname': {
# 'description': 'The manufacturer model label for the node',
# },
# 'id.snmpengineid': {
# 'description': 'The SNMP Engine id used by this node',
# },
# 'secret.snmpuser': {
# 'description': 'The user to use for SNMPv3 access to this node',
# },
# 'secret.snmppassphrase': {
# 'description': 'The passphrase to use for SNMPv3 access to this node',
# 'secret.snmppassword': {
# 'description': 'The password to use for SNMPv3 access to this node',
# },
'secret.snmpcommunity':{
'description':('SNMPv1 community string, it is highly recommended to'
'step up to SNMPv3'),
},
# 'secret.snmplocalizedkey': {
# 'description': ("SNMPv3 key localized to this node's SNMP Engine id"
# 'This can be used in lieu of snmppassphrase to avoid'
# 'retaining the passphrase TODO: document procedure'
# 'to commit passphrase to localized key'),
# },
# 'secret.snmpcommunity': {
# 'description': ('SNMPv1 community string, it is highly recommended to'
# 'step up to SNMPv3'),
# },
# 'secret.localadminpassphrase': {
# 'secret.adminpassword': {
# 'description': ('The passphrase to apply to local root/administrator '
# 'account. '
# 'If the environment is 100% Linux, the value may be '
@@ -233,34 +408,35 @@ node = {
# 'AD')
# },
'secret.ipmikg':{
'description':'Optional Integrity key for IPMI communication'
'description':'Optional Integrity key for IPMI communication. This '
'should generally be ignored, as mutual authentication '
'is normally done with the password alone (which is a '
'shared secret in IPMI)'
},
# 'secret.ipmiuser': {
# 'description': ('The username to use to log into IPMI device related '
# 'to the node. For setting username, default '
# 'behavior is to randomize username, for using '
# 'username if not set, USERID is assumed'),
# },
# 'secret.ipmipassphrase': {
# 'description': ('The key to use to authenticate to IPMI device '
# 'related to the node. For setting passphrase, '
# 'default behavior is to randomize passphrase and '
# 'store it here. If going to connect over the '
# 'network and value is not set, PASSW0RD is attempted')
# },
'secret.hardwaremanagementuser':{
'description':('Username to be set and used by protocols like SSH'
'and HTTP where client provides passphrase over the '
'network. Given the distinct security models betwen '
'this class of protocols and SNMP and IPMI, snmp and '
'ipmi utilize dedicated values.'),
'description':('The username to use when connecting to the hardware'
'manager'),
},
'secret.hardwaremanagementpassword':{
'description':('Passphrase to be set and used by protocols like SSH'
'and HTTP, where client sends passphrase over the '
'network. Given distinct security models between '
'this class of protocols, SNMP, and IPMI, SNMP and '
'IPMI are given their own settings with distinct'
'behaviors'),
'description':('Password to use when connecting to the hardware'
'manager'),
},
'pubkeys.addpolicy':{
'description':('Policy to use when encountering unknown public'
'keys. Choices are "automatic" to accept and '
'store new key if no key known and "manual"'
'to always reject a new key, even if no key known'
'Note that if the trusted CA verifies the certificate,'
' that is accepted ignoring this policy. Default '
'policy is "automatic"'),
'valid_values':('automatic','manual'),
},
'pubkeys.tls_hardwaremanager':{
'description':('Fingerprint of the TLS certificate recognized as'
'belonging to the hardware manager of the server'),
},
'pubkeys.ssh':{
'description':('Fingerprint of the SSH key of the OS running on the '
'system.'),
},
}
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.