apport-collect does not work on headless servers

Status changed to 'Confirmed' because the bug affects multiple users.

This has a compelling reason given a fair amount of original reporters are doing so via Server OSes (i.e. no GUI).

This would want to be addressed as resources become available to ease triaging, and server original report confusion.

apport-collect is not for reporting bugs, but for updating bugs that already reported to Launchpad. Perhaps you mean apport-bug or apport-cli? If you mean apport-cli, it now contains the following function:

351 def open_url(self, url):
352 text = '%s\n\n %s\n\n%s' % (
353 _('To continue, you must visit the following URL:'),
354 url,
355 _('You can launch a browser now, or copy this URL into a browser on another computer.'))
356
357 answer = self.ui_question_choice(text, [_('Launch a browser now')], False)
358 if answer == [0]:
359 apport.ui.UserInterface.open_url(self, url)

So a link is presented with will take you to the bug filing form in Launchpad. Does this address your issue?

Brian Murray, thanks for the quick response to this. I've subscribe a1291762 (who referenced this report) so I'll let this person/original reporter be the final authority here.

>"apport-collect is not for reporting bugs, but for updating bugs that already reported to Launchpad."

To advise, as per the OR's Description the issue that is scoped to this report is when apport-collect is invoked on a headless (i.e. no GUI) server environment, further supported by https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1547838/comments/25 , et. al.

>"Perhaps you mean apport-bug or apport-cli?"

This may affect apport-cli and apport-bug also, but I haven't confirmed this.

>"If you mean apport-cli, it now contains the following function:"

The scope of this report would appear still a live one as per LP1547838#25. However, if the changes you are referencing are after 2016-03-07, then perhaps a1291762 could speak to if this changed anything.

As per the original description, apport-collect launched a browser (in my case, apparently this was lynx). This browser could not complete the required OAth login (it got me to a screen where I could choose how long to allow my computer to act on my behalf and when I selected a link it returned 403 Forbidden). Using w3m (which was already installed) as the browser allowed me to login and apport-collect could then send all the information for the bug report. I can't really comment on using various other apport- tools but unless they do the same job as apport-collect, I'm not sure they would have helped.

Remarking to Triaged given sidebar discussion was surrounding apport-cli (not apport-collect). Please advise if this would not be preferred.

I just run on another use case for this:

A kernel upgrade made gnome unable to start, apport-collect needs to have a confirmation from a browser but since I can't start a normal desktop, I can't send the report.
The workaround using w3m may work but than after that I need to set back to firefox, not the easiest way. We could improve here a lot!

Yes we need some kind of API key that would be given to apport-collect to be authenticated to launchpad automatically without any browser launched

This REALLY need when we have a client that cannot start a graphic session.