Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

So trying to use the example and I keep getting time outs. #113

Closed
tdwitham opened this issue Aug 10, 2021 · 47 comments
Closed

So trying to use the example and I keep getting time outs. #113

tdwitham opened this issue Aug 10, 2021 · 47 comments
Labels
cleanup Used for issues that are stale and should be considered for closing

Comments

@tdwitham
Copy link

So I get a timeout response - can go to the browser and it all works fine, any hints?

`import sys
import redfish

login_host = "https://10.250.2.2"
login_account = "root"
login_password = "tester"

sys.stdout.write("Before OBJ host=%s account=%s password=%s\n" % (login_host, login_account, login_password))
REDFISH_OBJ = redfish.redfish_client(base_url=login_host, username=login_account, password=login_password,
timeout=5, max_retry=3, default_prefix='/redfish/v1/Systems')
sys.stdout.write("After OBJ\n")

REDFISH_OBJ.login(auth="session")

response = REDFISH_OBJ.get("/redfish/v1/Systems", None)

sys.stdout.write("%s\n" % response)

REDFISH_OBJ.logout()
`
@mraineri
Copy link
Contributor

mraineri commented Aug 11, 2021 •
edited
Loading

Is there an exception shown from the sample that could be shared? I would like to see where exactly the timeouts are coming from.

Can you also try changing "session" to "basic" in the login method? Browsers would use Basic Auth instead of Redfish Sessions, so that would give us a bit of consistency between the two for testing.

Some other things you can try with curl that might help; can you share the responses for these?

  • curl -k -u root:tester -D - "https://https://10.250.2.2/redfish/v1/"
  • curl -k -u root:tester -D - "https://https://10.250.2.2/redfish/v1/Systems"
  • curl -k -u root:tester -D - "https://https://10.250.2.2/redfish/v1/SessionService"
  • curl -k -u root:tester -D - "https://https://10.250.2.2/redfish/v1/SessionService/Sessions"

@tdwitham
Copy link
Author

tdwitham commented Aug 11, 2021 via email

@mraineri
Copy link
Contributor

Are your proxy settings configured via the following environment variables like this, or is there something else your browser is using?

export HTTP_PROXY="http://192.168.1.10:8888"
export HTTPS_PROXY="http://192.168.1.10:8888"

@tdwitham
Copy link
Author

tdwitham commented Aug 11, 2021 via email

@tdwitham
Copy link
Author

tdwitham commented Aug 11, 2021 via email

@mraineri
Copy link
Contributor

No, installing a certificate isn't needed for the interface to work (but it is encouraged since most services come with a self-signed certificate by default).

At least from the messages in your latest response, that would indicate to me the credentials "root" and "tester" are not valid. Were those same credentials working in the browser when you tried accessing Redfish resources via that path?

@tdwitham
Copy link
Author

tdwitham commented Aug 13, 2021 via email

@mraineri
Copy link
Contributor

The library itself doesn't contain that level of logic; it stops at producing a Python dictionary from the the JSON response, and leaves it up to the caller to extract the dictionary values that are relevant to their usage.

We do have a separate set of scripts that consumes this library and does more of the higher order types of operations (like collecting and displaying log data), and could be used as a sample for how to walk a Redfish service to find the data of interest. That project can be found here: https://github.com/DMTF/Redfish-Tacklebox

@tdwitham
Copy link
Author

tdwitham commented Aug 16, 2021 via email

@mraineri
Copy link
Contributor

mraineri commented Aug 16, 2021 •
edited
Loading

You need to specify the scheme with the address; instead of --rhost 10.250.2.2 it should be --rhost http://10.250.2.2

Probably worth adding some validation in the library to make the exception more clear to the user, since it's ultimately the library that consumes the value passed in the rhost argument.

@tdwitham
Copy link
Author

tdwitham commented Aug 16, 2021 via email

@mraineri
Copy link
Contributor

It's hard to tell without the payload in question, but it appears the service is not rendering the mandatory @odata.id property in one or more of its Drive resources. If this is the case, we might need to consider adding some workaround flags to bypass services that are not implementing mandatory properties to Tacklebox.

@mraineri
Copy link
Contributor

It could be that there was an error in getting the resource in question (and error payloads do not have @odata.id properties). This might be a good time for me to revisit this tool and improve the error handling.

@tdwitham
Copy link
Author

tdwitham commented Aug 16, 2021 via email

@mraineri
Copy link
Contributor

You should be able to get it from a browser and paste it here. From the trace, it's following the links through Systems, Storage, and Drives.

Depending on the number of storage subsystems, it might get difficult to track down the exact culprit. I would start with trying to find the first drive reported in the first storage subsystem.

  • Go to /redfish/v1/Systems
  • Go to the first system instance in the Members array
  • Go to the Storage collection found in the first system (look for the "Storage" property)
  • Go to the first storage instance in the Members array
  • Go to the first drive listed in the "Drives" property

I'm hoping the payload found at that last step will tell us what's going on, but if it's not clear, I can make a debug branch in Tacklebox for tracing what's going on.

@tdwitham
Copy link
Author

tdwitham commented Aug 16, 2021 via email

@mraineri
Copy link
Contributor

So, it is the latter case; the Storage resource is presenting links to Drives that result in a 404. I can certainly add better error handling to not crash in these cases, but it would be good to understand why the service you're working with isn't accepting the Drive URIs its presenting. It could be a case where the drive itself is absent, but we have modeling guidance in Redfish to render the resource with the "State" property inside of "Status" as "Absent" rather than returning a 404.

@jcleung5549
Copy link

What do you get when you issue a GET /redfish/v1/Systems/............/Storage/1/Drives/0 via Postman? Anything you do via the library, you can debug by walking the resource tree manually.

@tdwitham
Copy link
Author

tdwitham commented Aug 16, 2021 via email

@mraineri
Copy link
Contributor

@tdwitham I just released some changes that might help; rf_sys_inventory has a "workaround" flag added to bypass that issue you hit.

@tdwitham
Copy link
Author

tdwitham commented Aug 30, 2021 via email

@tdwitham
Copy link
Author

tdwitham commented Sep 1, 2021 via email

@mraineri
Copy link
Contributor

mraineri commented Sep 1, 2021

In this case it looks like you can't even log into the system; it's trying to access /redfish/v1/ but getting a 400. Can you access the resource in the browser?

@tdwitham
Copy link
Author

tdwitham commented Sep 1, 2021 via email

@tdwitham
Copy link
Author

tdwitham commented Sep 1, 2021 via email

@mraineri
Copy link
Contributor

mraineri commented Sep 2, 2021

I just noticed the URI given is not correct. You're missing a / in the rhost argument: http:/10.250.2.2.

@tdwitham
Copy link
Author

tdwitham commented Sep 2, 2021 via email

@mraineri
Copy link
Contributor

mraineri commented Sep 2, 2021 •
edited
Loading

For --rhost, you would leave off the resource URI (it's just the scheme + IP address). So, it should be --rhost https://10.250.2.2.

@tdwitham
Copy link
Author

tdwitham commented Sep 2, 2021 via email

@mraineri
Copy link
Contributor

mraineri commented Sep 3, 2021

Would it be possible to try https instead of http? Services tend to reject Redfish Session Login when using http since it's not a secure communication channel.

rf_sys_inventory.py --user test --password tester --rhost https://10.250.2.2

@tdwitham
Copy link
Author

tdwitham commented Sep 3, 2021 via email

@mraineri
Copy link
Contributor

mraineri commented Sep 3, 2021

Okay, can you add the new --workaround argument to attempt to bypass service-side issues?

@mraineri
Copy link
Contributor

mraineri commented Sep 3, 2021

It also doesn't seem like you've pulled down the latest updates to Tacklebox; the line reported in the exception trace doesn't match the updates we've pushed last week and it correlates with the older version prior to the introduction of the --workaround flag for the script.

@tdwitham
Copy link
Author

tdwitham commented Sep 3, 2021 via email

@mraineri
Copy link
Contributor

mraineri commented Sep 7, 2021 •
edited
Loading

How long did you wait? Depending on the size of the service and its responsiveness to requests, it may take a minute for the inventory to be collected.

@tdwitham
Copy link
Author

tdwitham commented Sep 7, 2021 via email

@mraineri
Copy link
Contributor

mraineri commented Sep 7, 2021

Sure, that would be good to see for me to compare with what I'm currently expecting. It might need to be provided back to the service vendor.

@tdwitham
Copy link
Author

tdwitham commented Sep 7, 2021 via email

@mraineri
Copy link
Contributor

mraineri commented Sep 7, 2021

What happens when you try to access URIs like "/redfish/v1/Chassis/PCIeRiser3" in your browser?

@tdwitham
Copy link
Author

tdwitham commented Sep 7, 2021 via email

@mraineri
Copy link
Contributor

mraineri commented Sep 7, 2021

What do you get back as a response in your browser?

I may need to add more info info to the warning messages to show what exactly went wrong.

@tdwitham
Copy link
Author

tdwitham commented Sep 7, 2021 via email

@mraineri
Copy link
Contributor

mraineri commented Sep 9, 2021

I don't think email attachments come through on the GitHub issue; only the text gets posted as far as I know.

@tdwitham
Copy link
Author

tdwitham commented Sep 9, 2021 via email

@tdwitham
Copy link
Author

tdwitham commented Oct 22, 2021 via email

@mraineri
Copy link
Contributor

The latter; "/redfish/v1/Chassis/RackMount/PwrSupply1FRU" is an illegal URI

@mraineri mraineri added the cleanup Used for issues that are stale and should be considered for closing label Jan 20, 2023
@mraineri
Copy link
Contributor

Closing; the issues here are related to non-conformant URIs from the service. Tacklebox has an enhancement opened to allow for a user to control whether the tools dynamically adjust to non-conformant URIs or make 1.6.0 assumptions about URIs (DMTF/Redfish-Tacklebox#75), which is the remainder of the problem in this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
cleanup Used for issues that are stale and should be considered for closing
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@tdwitham @mraineri @jcleung5549