#2865 closed defect (fixed)
OMEdit crash reports needs better handling
Reported by: | adrpo | Owned by: | adeas31 |
---|---|---|---|
Priority: | high | Milestone: | 1.9.4 |
Component: | OMEdit | Version: | trunk |
Keywords: | Cc: | sjoelund.se, adeas31 |
Description
We get emails like these which are useless
Please attach the following files alongwith your bug description in your crash report, 1. /tmpomeditcommands.log 2. /tmpopenmodelica.omc.output.OMEdit 3. /tmpopenmodelica.stacktrace.OMEdit
People never attach anything.
I suggest we do something like this:
- create an SVN or GIT repository on openmodelica.org or github
- add a user that can write to it
- svn commit or git commit to it a zipped crash report from OMEdit with an unique filename (UUID.zip).
What do you think about this? Any comments?
Side note: The paths in the email are wrong, should be tmp/ and I'm not sure about "alongwith" :)
Attachments (2)
Change History (29)
comment:1 Changed 10 years ago by adrpo
- Summary changed from OMEdit crashes reports needs better handling to OMEdit crash reports needs better handling
comment:2 Changed 10 years ago by sjoelund.se
comment:3 Changed 10 years ago by adeas31
I fixed the paths in r22621.
comment:4 in reply to: ↑ description Changed 10 years ago by adeas31
Replying to adrpo:
We get emails like these which are useless
Please attach the following files alongwith your bug description in your crash report, 1. /tmpomeditcommands.log 2. /tmpopenmodelica.omc.output.OMEdit 3. /tmpopenmodelica.stacktrace.OMEditPeople never attach anything.
I suggest we do something like this:
- create an SVN or GIT repository on openmodelica.org or github
- add a user that can write to it
- svn commit or git commit to it a zipped crash report from OMEdit with an unique filename (UUID.zip).
It means the user have to install SVN/Git in order to send the crash report, right?
comment:5 follow-up: ↓ 6 Changed 10 years ago by sjoelund.se
No SVN/GIT installation is needed as long as you send the correct http commands ;)
Simply uploading via https is simpler though. We do not need or want version control for this. We want to be able to delete logs once we have gone through them, or to let the user himself delete the files if he no longer wants them available.
comment:6 in reply to: ↑ 5 ; follow-up: ↓ 9 Changed 10 years ago by adeas31
Replying to sjoelund.se:
No SVN/GIT installation is needed as long as you send the correct http commands ;)
Simply uploading via https is simpler though. We do not need or want version control for this. We want to be able to delete logs once we have gone through them, or to let the user himself delete the files if he no longer wants them available.
We can use http upload. Qt has a class for it QHttp http://qt-project.org/doc/qt-4.8/qhttp.html.
Create a form in php, put it somewhere in openmodelica.org server, prepare the data in OMEdit and post it to the php form.
By doing this we might become vulnerable to spam emails. How can we handle spams in this way?
comment:7 follow-up: ↓ 8 Changed 10 years ago by adeas31
A little bit time consuming but comprehensive solution is to write a SMTP class in Qt.
comment:8 in reply to: ↑ 7 Changed 10 years ago by sjoelund.se
Replying to adeas31:
A little bit time consuming but comprehensive solution is to write a SMTP class in Qt.
No. You cannot do this. Most people are firewalled away from being able to run mail servers.
comment:9 in reply to: ↑ 6 Changed 10 years ago by sjoelund.se
Replying to adeas31:
By doing this we might become vulnerable to spam emails. How can we handle spams in this way?
Reject any email that does not contain a "secret" key and the exact files OMEdit uploads.
comment:10 follow-up: ↓ 11 Changed 10 years ago by adrpo
Nah. I would *NEVER EVER* use openmodelica.org for this or one of our test or build servers. Is too much of a security risk, people can upload anything and do DOS.
That's why I would use github, we only need to put git.exe in the installation and we are done.
If people find the user that OMEdit uses to upload stuff then they will upload crap or do DOS on github not our servers.
We could also probably use something like Google drive and upload there.
Alternatively, we could resurrect the old omeweb server and use that with https upload.
comment:11 in reply to: ↑ 10 Changed 10 years ago by sjoelund.se
Replying to adrpo:
That's why I would use github, we only need to put git.exe in the installation and we are done.
No. "You must be a human. Accounts registered by "bots" or other automated methods are not permitted."
If people find the user that OMEdit uses to upload stuff then they will upload crap or do DOS on github not our servers.
So what? You make it upload to somewhere that is only accessible to administrators and is cleaned out automatically.
we could resurrect the old omeweb server and use that with https upload.
What is the difference from using dev.openmodelica.org or similar? It's not like a lot of tools will search the web for c++ code to find some url with a magic key that uploads 3 specific named text-files over https, right?
comment:12 Changed 10 years ago by adrpo
Yeah, I forgot about dev.openmodelica.org. Using dev would be fine.
Changed 10 years ago by sjoelund.se
Changed 10 years ago by sjoelund.se
comment:13 Changed 10 years ago by sjoelund.se
I played for a little bit and ended up with the following python-scripts. Adding more checks would not be hard. The output directory could be in www-pub password-protected or accessible sftp-only. API keys or spam detection can be added as an option.
comment:14 Changed 10 years ago by adrpo
Cool, we can try this. Note that the file names have changed since yesterday:
omeditcommands.mos omeditcommunication.log openmodelica.omc.output.OMEdit
comment:15 follow-ups: ↓ 17 ↓ 21 Changed 10 years ago by adrpo
Adeel, I guess Qt has a http(s) request post class that we could use. Also, we could add more information like OMC version and OMEdit version as that is not available in any of these files.
Also, you need to ask for user's permission to send the files as they might contain private information.
comment:16 follow-up: ↓ 18 Changed 10 years ago by adrpo
We also need to generate unique file names if we upload in the same directory. We could probably use UUID or something like that.
comment:17 in reply to: ↑ 15 Changed 10 years ago by adeas31
Replying to adrpo:
Adeel, I guess Qt has a http(s) request post class that we could use. Also, we could add more information like OMC version and OMEdit version as that is not available in any of these files.
Also, you need to ask for user's permission to send the files as they might contain private information.
Yes, Qt has QHttp class (as I mentioned earlier). I will try it. What will be post url?
comment:18 in reply to: ↑ 16 Changed 10 years ago by adeas31
Replying to adrpo:
We also need to generate unique file names if we upload in the same directory. We could probably use UUID or something like that.
I don't think we need it? Martin is generating unique file names in server.py. Check line 18,
prefix = time.strftime("%Y-%m-%d_%H:%M:%S")
comment:19 Changed 10 years ago by adrpo
See test.py for the post url. I guess just for testing now.
comment:20 Changed 10 years ago by sjoelund.se
You could also install the script in /var/www if you like, so you can tweak it yourself (add your own email, etc).
comment:21 in reply to: ↑ 15 Changed 10 years ago by sjoelund.se
Replying to adrpo:
Adeel, I guess Qt has a http(s) request post class that we could use. Also, we could add more information like OMC version and OMEdit version as that is not available in any of these files.
Also, you need to ask for user's permission to send the files as they might contain private information.
Maybe reply-to email as well?
comment:22 Changed 10 years ago by perost
- Cc perost removed
comment:23 Changed 10 years ago by adeas31
From r22785 OMEdit uses the http upload approach for crash reports. The files are uploaded to the server and the crash report email contains the links of them.
comment:24 Changed 10 years ago by sjoelund.se
You should get a permanent URL for it before the release ;)
comment:25 Changed 10 years ago by adeas31
- Resolution set to fixed
- Status changed from new to closed
Done in r22797.
comment:26 Changed 9 years ago by dietmarw
- Milestone changed from Future to pre1.9.4
It doesn't make sense to keep closed ticket in the "Future" milestone that were simply forgotten to assign to the correct milestone in the past.
comment:27 Changed 7 years ago by sjoelund.se
- Milestone changed from pre1.9.4 to 1.9.4
Removing the pre1.9.4 milestone in favor of 1.9.4.
I have suggested something similar in the past. My choice was http upload though.