Open GrepItAll opened 6 years ago
i128
commented
6 years ago I've noticed a bit of load upon job star/enqueue. The build_crack_cmd.rb is a bit clunky and is due for a major rewrite. Ideally, when completed, it'd be more efficient, and might address the above experienced issue.
GrepItAll
commented
6 years ago Fair enough, is there anything that can be done in the mean time to alleviate this? Other than not having so many people accessing the web interface simultaneously!
ccammilleri
commented
6 years ago @GrepItAll webbrick isn't a robust webserver which could be the cause. A couple things I can think of.
gem 'puma' to your Gemfile, then do a bundle install, and edit the web instance in Procfile to look like this: web: puma ./hashview.rb. again untested, but thats how i'd start.GrepItAll
commented
6 years ago Cheers @ccammilleri, I'll try both of these next time we have multiple users available to test it
ccammilleri
commented
6 years ago @GrepItAll just curious, did you get a chance to test the suggestions?
GrepItAll
commented
6 years ago I haven't yet, but coincidentally this is the week where I'm most likely to need it! I will have a room full of people all trying to access the server in a couple of days, so I can try the suggestions out then.
GrepItAll
commented
6 years ago I tried following your instructions for Puma, but I think more changes are needed to get it to play nicely:
15:18:25 web.1 | APPLICATION VERSION: 0.7.2
15:18:25 web.1 | DB:VERSION 0.7.2
15:18:25 web.1 | ! Unable to load application: NameError: uninitialized constant Hashview
15:18:25 web.1 | bundler: failed to load command: puma (/home/classroom/.rvm/gems/ruby-2.2.2/bin/puma)
15:18:25 web.1 | NameError: uninitialized constant Hashview
15:18:25 web.1 | /home/classroom/.rvm/gems/ruby-2.2.2/gems/rack-1.6.5/lib/rack/builder.rb:43:in `const_get'
15:18:25 web.1 | /home/classroom/.rvm/gems/ruby-2.2.2/gems/rack-1.6.5/lib/rack/builder.rb:43:in `parse_file'
15:18:25 web.1 | /home/classroom/.rvm/gems/ruby-2.2.2/gems/puma-3.11.0/lib/puma/configuration.rb:318:in `load_rackup'
15:18:25 web.1 | /home/classroom/.rvm/gems/ruby-2.2.2/gems/puma-3.11.0/lib/puma/configuration.rb:243:in `app'
15:18:25 web.1 | /home/classroom/.rvm/gems/ruby-2.2.2/gems/puma-3.11.0/lib/puma/runner.rb:138:in `load_and_bind'
15:18:25 web.1 | /home/classroom/.rvm/gems/ruby-2.2.2/gems/puma-3.11.0/lib/puma/single.rb:87:in `run'
15:18:25 web.1 | /home/classroom/.rvm/gems/ruby-2.2.2/gems/puma-3.11.0/lib/puma/launcher.rb:183:in `run'
15:18:25 web.1 | /home/classroom/.rvm/gems/ruby-2.2.2/gems/puma-3.11.0/lib/puma/cli.rb:77:in `run'
15:18:25 web.1 | /home/classroom/.rvm/gems/ruby-2.2.2/gems/puma-3.11.0/bin/puma:10:in `<top (required)>'
15:18:25 web.1 | /home/classroom/.rvm/gems/ruby-2.2.2/bin/puma:23:in `load'
15:18:25 web.1 | /home/classroom/.rvm/gems/ruby-2.2.2/bin/puma:23:in `<top (required)>'
15:18:25 web.1 | exited with code 1
I had 8 people trying to access my hashview system the other day simultaneously. Everyone managed to queue a different job at the same time (at my request). However, once someone tried to press play on their job, I found that everyones connection to hashview kept timing out and the hashview log showed it trying to send the same pages out to everyone over and over again. The hashcat job never started because of this; I think that we'd basically caused a DoS on the system which prevented any work getting started.
Asking most of the users to close their tabs allowed hashview to carry on with it's work.
I don't have a particular error to report and I appreciate that having multiple users accessing the same system simultaneously is probably uncommon, but it seems like the web server being run by hashview is not particularly robust. Any ideas about solutions for this?