Project

General

Profile

tickets #60752

"Download package" link in OBS pointing to Factory package yields error "api.infra.opensuse.org:80 (getaddrinfo: Name or service not known)"

Added by okurz about 3 years ago. Updated almost 3 years ago.

Status:
Closed
Priority:
High
Assignee:
dmacvicar
Category:
Software portal
Target version:
-
Start date:
2019-12-06
Due date:
% Done:

100%

Estimated time:

Description

Observation

Full details:

Error connecting to http://api.infra.opensuse.org//search/published/binary/id?match=project='openSUSE%3AFactory'+and+name='os-autoinst': Failed to open TCP connection to api.infra.opensuse.org:80 (getaddrinfo: Name or service not known)

Steps to reproduce

History

#1 Updated by okurz about 3 years ago

  • Private changed from Yes to No

#2 Updated by okurz about 3 years ago

  • Tracker changed from communication to tickets

#3 Updated by lrupp about 3 years ago

  • Status changed from New to Workable
  • Assignee changed from opensuse-admin-obs to opensuse-admin-app-devs
  • % Done changed from 0 to 10

While it works at the moment (I guess someone re-enabled the api.infra.opensuse.org DNS entry), I like to know why software.opensuse.org is using an internal DNS name for API ?
This should be (if ever) api.opensuse.org (or download.opensuse.org), but definitively not the internal name...

=> thus: looks to me like a bug in software.opensuse.org. Giving to "opensuse-admin-app-devs" for now, I'm unsure who is maintaining software.o-o these days.

#4 Updated by lrupp about 3 years ago

  • Category changed from OBS to Software portal

#5 Updated by agraul about 3 years ago

  • Assignee changed from opensuse-admin-app-devs to dmacvicar

=> thus: looks to me like a bug in software.opensuse.org. Giving to "opensuse-admin-app-devs" for now, I'm unsure who is maintaining software.o-o these days.

Mostly dmacvicar and me.

I like to know why software.opensuse.org is using an internal DNS name for API ?

I don't know why it uses that DNS name, it was already set up this way when I started updating the rails application. Maybe Duncan knows that?

The fact that the DNS name was shown as part of an exception is definitely a bug (https://github.com/openSUSE/software-o-o/issues/555).

#6 Updated by lrupp about 3 years ago

agraul wrote:

=> thus: looks to me like a bug in software.opensuse.org. Giving to "opensuse-admin-app-devs" for now, I'm unsure who is maintaining software.o-o these days.

Mostly dmacvicar and me.

Thanks!

I like to know why software.opensuse.org is using an internal DNS name for API ?

I don't know why it uses that DNS name, it was already set up this way when I started updating the rails application. Maybe Duncan knows that?

The fact that the DNS name was shown as part of an exception is definitely a bug (https://github.com/openSUSE/software-o-o/issues/555).

Please switch to the normal api.opensuse.org domain. The internal api (api.infra.opensuse.org) will go away in the near future. As we are currently working on separating OBS a bit more from anything else (including openQA and softwareo.o) these days...

#7 Updated by dmacvicar about 3 years ago

If you tell us the cookie works in the external server, or which HTTP
credentials to use, and confirms doing HTTP auth will not decrease
performance significantly, switching should be relatively easy.

Well: I can not promise that http auth will not decrease performance. I can just tell that the api machine will leave the current internal network.

So we should start to think about possible solutions...

As I'm no fan of IP whitelists or whatever old school "security settings" are currently in place (need to check, sorry), I think we need to start testing, if the cookie works also via the external api. I can not imagine, why this should not work. Can you please check this?

If this does not work, we might need to come together and find another solution.

#8 Updated by lrupp about 3 years ago

JFYI: the work on OBS separation will start again during the next weeks. I expect it to be done and of Februar. If nothing happens, software.o.o will be down again at this point.

#9 Updated by dmacvicar about 3 years ago

dmacvicar wrote:

If you tell us the cookie works in the external server, or which HTTP
credentials to use, and confirms doing HTTP auth will not decrease
performance significantly, switching should be relatively easy.

Well: I can not promise that http auth will not decrease performance. I can just tell that the api machine will leave the current internal network.

So we should start to think about possible solutions...

As I'm no fan of IP whitelists or whatever old school "security settings" are currently in place (need to check, sorry), I think we need to start testing, if the cookie works also via the external api. I can not imagine, why this should not work. Can you please check this?

If this does not work, we might need to come together and find another solution.

I just tested this and if my test was correct, the opensuse_cookie header we use with api.infra.opensuse.org does not work with api.opensuse.org and you get 401. The only alternative for api.opensuse.org is to use the HTTP auth credentials we always use for development, but I am not sure if that credentials will stay or are desirable.

#11 Updated by lrupp almost 3 years ago

  • Status changed from Workable to Closed
  • % Done changed from 10 to 100

Solved for now by moving software.o.o into OBS network.

Also available in: Atom PDF