Hi all,
the eighth service on the list of services to migrate is Crash report storage.
-- Migration status --
While for previous services here I could bring positive information, now it's time for a service that is very sad.
Because this service resides on old primary server, it requires migration. Unfortunately, we do not currently have any information about this service - nor the source code for server side. Therefore in the current state of service, we can not ensure the issuance of a new ssl certificate. For everything, we must be able to contact Tim.
Other problems are that the web interface is unfinished, making it difficult to use. It is not possible to mark a records as completed. At the same time, retrieving the list is often not complete, so there is an increased effort required to obtain the latest records. Many records are generated without the presence of debug symbols, so their usefulness is reduced.
-- What needs to be done --
We have to decide what to do next with this service.
We will either need to obtain the source code and data of existing records so that we can migrate the service and then work on improving it. Or we could implement the server side of the service from scratch, based on the client side code in tdelibs. Or we can look for a similar service with a GPL license and the ability to install on our server. In any case, it will probably take a lot of effort here to make the service useful.
-- More ideas and suggestions?
Do you have any other ideas and suggestions? Do you know of any open source solutions that could serve our purpose?
Cheers
On Fri, 11 Dec 2020 04:23:50 +0100 Slávek Banko via tde-users users@trinitydesktop.org wrote:
-- What needs to be done --
We have to decide what to do next with this service.
We will either need to obtain the source code and data of existing records so that we can migrate the service and then work on improving it. Or we could implement the server side of the service from scratch, based on the client side code in tdelibs. Or we can look for a similar service with a GPL license and the ability to install on our server. In any case, it will probably take a lot of effort here to make the service useful.
-- More ideas and suggestions?
Do you have any other ideas and suggestions? Do you know of any open source solutions that could serve our purpose?
Only thing I can think of is, does the server-side code from the KDE era still exist in their source control somewhere? If the client side hasn't changed very much, it might provide a place to start in recreating the server.
E. Liddell
On Friday 11 of December 2020 14:33:47 E. Liddell wrote:
On Fri, 11 Dec 2020 04:23:50 +0100
Slávek Banko via tde-users users@trinitydesktop.org wrote:
-- What needs to be done --
We have to decide what to do next with this service.
We will either need to obtain the source code and data of existing records so that we can migrate the service and then work on improving it. Or we could implement the server side of the service from scratch, based on the client side code in tdelibs. Or we can look for a similar service with a GPL license and the ability to install on our server. In any case, it will probably take a lot of effort here to make the service useful.
-- More ideas and suggestions?
Do you have any other ideas and suggestions? Do you know of any open source solutions that could serve our purpose?
Only thing I can think of is, does the server-side code from the KDE era still exist in their source control somewhere? If the client side hasn't changed very much, it might provide a place to start in recreating the server.
E. Liddell ____________________________________________________
If memory serves me right, zploading crash reports and the corresponding server side is a new code from Tim. As far as I know, there was no similar solution at the time of KDE. In any case, thank you for a good idea.
Cheers
On 2020/12/11 10:40 PM, Slávek Banko via tde-users wrote:
If memory serves me right, zploading crash reports and the corresponding server side is a new code from Tim. As far as I know, there was no similar solution at the time of KDE. In any case, thank you for a good idea.
Yes, that was something added by Tim in 2013/2014. If you look in ML archive, you can surely find an email about it. Cheers Michele
On Friday 11 of December 2020 16:02:00 Michele Calgaro via tde-users wrote:
On 2020/12/11 10:40 PM, Slávek Banko via tde-users wrote:
If memory serves me right, zploading crash reports and the corresponding server side is a new code from Tim. As far as I know, there was no similar solution at the time of KDE. In any case, thank you for a good idea.
Yes, that was something added by Tim in 2013/2014. If you look in ML archive, you can surely find an email about it. Cheers Michele
Michele, good point:
https://mail.trinitydesktop.org/mailman3/hyperkitty/list/devels@trinitydeskt... https://mail.trinitydesktop.org/mailman3/hyperkitty/list/users@trinitydeskto...
Cheers
-- What needs to be done --
We have to decide what to do next with this service.
We will either need to obtain the source code and data of existing records so that we can migrate the service and then work on improving it. Or we could implement the server side of the service from scratch, based on the client side code in tdelibs. Or we can look for a similar service with a GPL license and the ability to install on our server. In any case, it will probably take a lot of effort here to make the service useful.
-- More ideas and suggestions?
Do you have any other ideas and suggestions? Do you know of any open source solutions that could serve our purpose?
Hi Slavek, given that lot of crash reports are already quite old and that it is always difficult to reach Tim, it probably makes more sense to create a new service on the new tde-box and start from scratch, preparing something more user friendly than the original service. If there is an open source software that could do the job already, even better.
Cheers Michele
On Thu December 10 2020 19:23:50 Slávek Banko via tde-users wrote:
Because this service resides on old primary server, it requires migration. Unfortunately, we do not currently have any information about this service - nor the source code for server side. Therefore in the current state of service, we can not ensure the issuance of a new ssl certificate. For everything, we must be able to contact Tim.
Are crash dumps just text or is there more to them? If text you could at least in the short term just change the client side to mail them to a private mailbox accessible only to trusted devs.
--Mike
On Friday 11 of December 2020 17:10:22 Mike Bird via tde-users wrote:
On Thu December 10 2020 19:23:50 Slávek Banko via tde-users wrote:
Because this service resides on old primary server, it requires migration. Unfortunately, we do not currently have any information about this service - nor the source code for server side. Therefore in the current state of service, we can not ensure the issuance of a new ssl certificate. For everything, we must be able to contact Tim.
Are crash dumps just text or is there more to them? If text you could at least in the short term just change the client side to mail them to a private mailbox accessible only to trusted devs.
--Mike ____________________________________________________
The data is prepared as a text file and sent as multipart/form-data.
https://mirror.git.trinitydesktop.org/cgit/tdebase/tree/drkonqi/toplevel.cpp...
Here it will probably be useful to divide the solution into two phases:
1. Prepare a reverse proxy configuration for the crash report service in the web server on the tde-box and try to contact Tim to change the address in the DNS record so that the communication for crash report service is directed to the tde-box.
In this first phase, requests would be forwarded to the old primary server as they are now. However, on the web server side of the tde-box we would deal with issuing certificates.
2. Prepare a new backend for this service. And once we have a replacement ready for this service, we will be able to easily switch it by changing the settings of our reverse proxy on tde-box.
Cheers
On 2020/12/12 10:58 AM, Slávek Banko via tde-users wrote:
- Prepare a reverse proxy configuration for the crash report service in
the web server on the tde-box and try to contact Tim to change the address in the DNS record so that the communication for crash report service is directed to the tde-box.
In this first phase, requests would be forwarded to the old primary server as they are now. However, on the web server side of the tde-box we would deal with issuing certificates.
- Prepare a new backend for this service. And once we have a replacement
ready for this service, we will be able to easily switch it by changing the settings of our reverse proxy on tde-box.
Sounds like a good plan to me :-) Cheers Michele
On Friday 11 of December 2020 04:23:50 Slávek Banko via tde-users wrote:
-- More ideas and suggestions?
Do you have any other ideas and suggestions? Do you know of any open source solutions that could serve our purpose?
When I tried to find a suitable existing solution that would suit our needs, I only found Sentry suitable. It looks like a very sophisticated system, but on the other hand it seems too big:
As I thought more about it, I had the idea that we could try to integrate the backend for dr-konqi on the server so that crash-reports could be created as Issues in TGW. What is your opinion on this idea?
Cheers
Slávek Banko via tde-users wrote:
I thought more about it, I had the idea that we could try to integrate the backend for dr-konqi on the server so that crash-reports could be created as Issues in TGW. What is your opinion on this idea?
May be it is worth trying. But some system issues that cause crashes are not exactly caused by issue in TDE. But you can try and see how it works
--------------------------------------------------------------------- To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
On Sunday 13 of December 2020 00:19:01 deloptes via tde-users wrote:
Slávek Banko via tde-users wrote:
I thought more about it, I had the idea that we could try to integrate the backend for dr-konqi on the server so that crash-reports could be created as Issues in TGW. What is your opinion on this idea?
May be it is worth trying. But some system issues that cause crashes are not exactly caused by issue in TDE. But you can try and see how it works
Dr. Konqi only responds if a TDE application crashes. Therefore, only backtraces for TDE applications should be uploaded there.
For cases where the crash is caused by another library, it will be useful to verify whether it is a bug in the relevant library or whether it is a library call issue that should be addressed in a TDE application. For such cases, it will be correct that the backtrace is uploaded for the respective TDE application.
The only somewhat confusing situation can be when it comes to a GTK application that runs with the TQt style => as a TDE application. However, even such cases will be good if we have the backtrace recorded.
That's why I expect it to be good for all cases.
Cheers
On 2020/12/13 04:20 AM, Slávek Banko via tde-users wrote:
As I thought more about it, I had the idea that we could try to integrate the backend for dr-konqi on the server so that crash-reports could be created as Issues in TGW. What is your opinion on this idea?
Yes, excellent suggestion. It makes perfect sense and fits nicely with our development environment. We should go this way!
Cheers Michele
On Sunday 13 of December 2020 03:41:02 Michele Calgaro via tde-users wrote:
On 2020/12/13 04:20 AM, Slávek Banko via tde-users wrote:
As I thought more about it, I had the idea that we could try to integrate the backend for dr-konqi on the server so that crash-reports could be created as Issues in TGW. What is your opinion on this idea?
Yes, excellent suggestion. It makes perfect sense and fits nicely with our development environment. We should go this way!
Cheers Michele
Exactly. I assume it will save us work: we won't have to invent the integration of a "crash report system" with TGW, we won't have to design and create a UI for a crash report system, we'll get it all automatically. And at the same time we will get other advantages: there it will be possible to assign a crash report to a branch, set a milestone, it will be possible to refer from / to other issues and pull requests, there it will be possible to add comments - ask for more information, discuss solutions,... we'll get it all automatically.
Cheers
Exactly. I assume it will save us work: we won't have to invent the integration of a "crash report system" with TGW, we won't have to design and create a UI for a crash report system, we'll get it all automatically. And at the same time we will get other advantages: there it will be possible to assign a crash report to a branch, set a milestone, it will be possible to refer from / to other issues and pull requests, there it will be possible to add comments - ask for more information, discuss solutions,... we'll get it all automatically.
And we can switch it even without reaching out to Tim! :-) Cheers Michele
On Sunday 13 December 2020 07:21:32 am Michele Calgaro via tde-users wrote:
Exactly. I assume it will save us work: we won't have to invent the integration of a "crash report system" with TGW, we won't have to design and create a UI for a crash report system, we'll get it all automatically. And at the same time we will get other advantages: there it will be possible to assign a crash report to a branch, set a milestone, it will be possible to refer from / to other issues and pull requests, there it will be possible to add comments - ask for more information, discuss solutions,... we'll get it all automatically.
And we can switch it even without reaching out to Tim! :-) Cheers Michele
I'll make the suggestion that the crash report doesn't even initiate on the user's PC unless they have whatever (tool/library?) is needed to send a crash report.
Why? It's always bugged me that something TDE crashes, a popup on my system gets initiated, but since I don't have XYZ installed the crash popup then tells me, "Never mind, I can't send anything anyway."
I'll make the second suggestion that if whatever XYZ is, is small disk space wise, then XYZ should be either default installed or added to install docs as, "Install this to generate crash reports."
On the second suggestion, it'd probably be best to link to whatever doc explains exactly what gets included in crash reports, what security issues they might have, what information might be leaked, etc... *
* I've never turned them on as I've never seen anything assuring me my clients' data won't be breached in some way. As it is now, I sign so many NDAs I can't take the risks.
Best, Michael
-
deloptes -
E. Liddell -
Michael -
Michele Calgaro -
Mike Bird -
Slávek Banko