kschopmeyer / smipyping Goto Github PK

Right now when we discover a possible server we test it against the known servers but do not try further tests to determine if this could be a logical server (default creds, etc.) We can possibly reduce the number of unknowns in the environment by running more tests on the servers that show up as unknown.

Thus, for eample, an unknown is shown as the same address as each of the fujitsu servers. That is because they only list either the http or https ports but keep the keep the other ports open so that we do not find the second open port in the targets table.

Some tests include:

1. IP address in table
2. Multiple principal/credential combinations.
3. Futher detailed tests just to see if we can get a wbemserver like error response from the device.

We should be able to execute -h and --help options without a database. However, they fail because we validate the config file and get the database parameters before executing any commands. We should be executing this code at the time the first database open is executed.

2019-02-19 16:52:54,299-smipyping.audit-TargetsTable TargetID: 122, update fields: {'ScanEnabled': 'Disabled'}, original fields: {'ScanEnabled': u'Enabled'}
2019-02-19 16:52:54,299-INFO -smipyping.audit-TargetsTable TargetID: 122, update fields: {'ScanEnabled': 'Disabled'}, original fields: {'ScanEnabled': u'Enabled'}

Some of the operations (cimping, explorer, sweep) are multithreaded, creating many threads to accomplish there tasks more rapidly. Normally a Cntrl_C should immediatly terminate the operation.

However, it does not since we are not passing the kill information on to each thread but depending on the thread to terminate. This works fairly well in most cases except for the sweep where a very large sweep does not die for some time after a ctrl_c, depending on the range of the sweep.

Today the local and travis tests only run against the travis (linux) environment and not against windows.

We need to enable ci testing against the windows platform

Displays are normally in the form

Proposed deletions for all targets: startdate: 2012-01-01 00:00:00, end_date: 2016-01-01 00:00:00

Which by itself is hard to read but even more,

inputs of dates are in the form dd/mm/yy

The Makefile is not finding the correct pywbem install scripts.

Today we use the scapy package. This package only supports python 2 today and we have not tested against a fork that apparently supports python3.

Since this is a cmd line tool, generally we make heavy use of ways to select particular entities in the tables. generally this is the ID for the table. This makes it hard for the user since they have to remember integer IDs for particular entries in a table.

Thus: 'smicli targets list'

generates a table of the targets table (id, ip address, creds, port, etc.) However, to modify/get/delete, etc. a particular entry you must remember the id from a previous list. Thus smicli modify 98 --ipaddress 10.2.104.22 modifies the ipaddress of target 98. This is hard to do. We have for some tables the capability to list all of the entries and allow the user to select one. Thus, smicli modify ? --ipaddress 10.2.104.22 would first present a list of the targets with info including (id, product, company, etc.) and the user could then select this entry without having to remember the ID number or abort the whole operation.

Note that we tried doing things like using other fields (company, product, etc.) to derive the id but there are too many duplicates in the tables to allow this to refine to a single id and further, some things like product are actually spelled slightly differently in different targets.

This is all part of making this easier to use and will apply not this and the other command line tools like pywbemcli equally.

If there is only a single column in a report, it mangles the column header, printing only the first character of the header name. Not sure at this point if this is a problem in smipyping or in the table library.

All reports should reflect the name of the object, not just a db ID. Right now at least the users list output reflects the ID, not the name.

We use the character ? to ask for a pick list for options that require an id since most people would not remember an id.
However, we also include the --interactive options which was an old way to do the same thing.

Drop the --interactive option.

These fields should be validated in the database against the actual server. We probably need an option to execute this validation and to update the database.

This means that the audit log grows without end. We need to either extend the config file for this log or force it to a rotating log. It is easy because one of the log types in Python is the rotating log.

In a number of reports, we put the name WBEMException on the status row for status of tests that failed with a particular exception message. However:

1. We call it WBEMException. The DMTF Spec for CIM-XML XML name is CIMError and it is derived when the CIMError header is returned.

2. We put the return code into the information in the table, This is the status_code that is received with the message. However, it requires that the user look up the code. I propose that we change that to the string equivalent to the code as defined in DSP 0200 (ex. CIM_ERR_ACCESS_DENIED is the text definition of the status code when the server denies access)

3. Finally, there is also often a text attached to the error. Since this can be very long, we really do not want to put that into a table output. However, we do generate a log for these returns and the full text can appear in the log.

Extend the general option --versions to show the pywbem vesion also

We agreed that the way to have both readonly and read-write database access was to create multiple users. Most people would know a user that was read-only so that they could not modify the db. That simply means creating multiple users in the db with varying access. The only support for that in smipyping is in the documentation.

However, we want to be sure we have a clean exception when a read-only user tries to write to the db. We need to extend the exceptions to cover this particular issue and return the proper response.

We should probably include time information on all reports since the assumption is that they will be used for more than just a snapshot so some record of when generated could be important.

This subcommand creates a bad name (something line %) because there is an issue with the mysql sql for updating a single property