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.

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

500 Service Error - when try to save a testrun #191

Closed
jehoff opened this Issue Jan 19, 2018 · 11 comments

Comments

Projects
None yet
5 participants
@jehoff
Copy link

jehoff commented Jan 19, 2018

WARNING: do not publically report security issues in the bug tracker!
Ping us via email to coordinate the fix and disclosure of the problem!

Description of problem

generated a testcase. Want to create a testrun. If i push "save" button to store my testrun "500 Service Error" pops up.

Component (web, API, etc)

Kiwi Docker Image @ Debian 8.0 System

Version or commit hash (if applicable)

3.49

How often reproducible

always

Steps to Reproduce

  1. Generate Testcase
  2. Confirm Testcase
    3.Write Testrun
  3. Save Testrun

Actual results

Error pops ub

Expected results

no error

Additional info

i can create testcases, create users.... but i cant save test run

@xbln

This comment has been minimized.

Copy link

xbln commented Jan 19, 2018

Did you change default system test_case_status or test_case_run_status by admin interface (because you wanted to have status entries in your language)?

@atodorov

This comment has been minimized.

Copy link
Member

atodorov commented Jan 19, 2018

@jehoff please retry with latest master and also give me a traceback of the failure (enable DEBUG=True in settings). Also let us know if you have edited any of the default objects in the DB, especially changing the names in another language like @xbln says.

@jehoff

This comment has been minimized.

Copy link
Author

jehoff commented Jan 22, 2018

first off all, sorry for my late replay. i wasn´t in office this morning.

@xbln : i didnt changed test_case_status nor test_case_run_status

@atodorov : what do you mean by "latest master"? where do i find the traceback/log.file? DEBUG is activited. I didnt change/modify anything with language.

i tried to update the container with:

docker pull kiwitcms/kiwi

but i got this error:

Error response from daemon: pull access denied for kiwitcms/kiwi, repository does not exist or may require 'docker login'

Should i try to reinstall kiwi docker-image?

thx for your fast support!

@atodorov

This comment has been minimized.

Copy link
Member

atodorov commented Jan 22, 2018

@atodorov : what do you mean by "latest master"? where do i find the traceback/log.file? DEBUG is activited. I didnt change/modify anything with language.

With DEBUG=True traceback should be printed in the browser instead getting a 500 error page.

docker pull kiwitcms/kiwi

Try rebuilding the docker image from the latest checkout from git.

@jehoff

This comment has been minimized.

Copy link
Author

jehoff commented Jan 22, 2018

@atodorov : There is no difference in browser window (debug on/off). only "shown 500 Error Service".
I will try to rebuild the latest git version

@xbln

This comment has been minimized.

Copy link

xbln commented Jan 22, 2018

I would always suggest to use the latest https://github.com/MrSenko/kiwi-docker docker image. For that repository you need a login. You can ask Alex for the credencials.

To use the latest "official" image, preferably on a standard environment like the digitalocean docker droplet, will help to find out bugs by isolating them from errors made by rebuilding the image on a home grown environment.

For error tracking it was very useful for me adding a phpmyadmin container to the installation.

@atodorov

This comment has been minimized.

Copy link
Member

atodorov commented Jan 25, 2018

@jehoff when you have DEBUG=True in your settings Django will not display a 500 page but a traceback and an autogenerated page in the browser. The fact that you are not seeing this means your settings have not been changed. Inside the running container Python traceback should be printed in /var/log/httpd/ssl_error_log.

You can try running Kiwi TCMS locally and see if you can reproduce:
http://kiwitcms.readthedocs.io/en/latest/set_dev_env.html

@okainov

This comment has been minimized.

Copy link
Contributor

okainov commented Jan 29, 2018

Inside the running container Python traceback should be printed in /var/log/httpd/ssl_error_log.

Is there more user-friendly way to check the log? I'm not an expert in web-docker stuff, but for me it looks like overhead to go into docker container for the logs, I would expect them to be in real filesystem\in some mounted docker volume, which is accessible from outside of the container
And could you also specify this somewhere in the documentation, like in FAQ: "where to find log files?" Thanks

@xbln

This comment has been minimized.

Copy link

xbln commented Jan 29, 2018

It is not too hard to step "inside" the running container. Just type docker exec -it <container name> bash. To find out names of your containers, type docker container ls.

You can also copy content from inside a running container to your host filesystem by typing docker cp <container_name>:<path> <dest_path> or the other way round docker cp <source_path> <container_name>:<path>.

@atodorov

This comment has been minimized.

Copy link
Member

atodorov commented Jan 29, 2018

Is there more user-friendly way to check the log?

We're working on making this easier to detect programatically and be reported to us automatically via Sentry. When done you can switch to your own Sentry credentials and debug yourself.

The easiest way is to set DEBUG=True and have the traceback in the browser. This is the standard Django practice.

I'm not an expert in web-docker stuff, but for me it looks like overhead to go into docker container for the logs, I would expect them to be in real filesystem\in some mounted docker volume, which is accessible from outside of the container

You are using a Docker container to run software so it is understandable that logs and other files will be inside the docker container. Exposing these directories via volumes and mounting them on the host will probably work (you have to update your docker-compose.yml to configure that) but be aware this can have all sorts of issues with file ownership and permissions between the host and the container not to mention SELinux. Also this kind of mapping isn't universally applicable to everyone because we have no idea in what environment do you run your docker compose or even if you use compose at all.

And could you also specify this somewhere in the documentation, like in FAQ: "where to find log files?"

Will do, this is definitely a good suggestion.

atodorov added a commit that referenced this issue Feb 24, 2018

Expose httpd logs to the host running docker. Fixes #191
this commit makes it easier to access the httpd logs, mostly useful
in case of error, and adds a small section about troubleshooting in
production.

There could still be issues with SELinux and file ownership depending
on how the host setup.

The helper instroduced in this commit only gets applied if you
use docker-compose to start Kiwi TCMS. If you don't logs will still
be inside the container!

@atodorov atodorov closed this in 52c63e9 Feb 25, 2018

@LZ-001

This comment has been minimized.

Copy link

LZ-001 commented Aug 1, 2018

I also met this issue when saving a testplan, following is the error info got from ssl_error_log:
"RSA certificate configured for : does NOT include an ID which matches the server name"
what should I do?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.