Search results

  1. L

    [Feature Request] A custom log format similar to %D

    We make great use of the %D log format string ("The time taken to serve the request, in microseconds"), but what I'd also really love to have is a similar benchmark measuring from when litespeed initiates the external application request and when it gets a complete result. The problem with %D...
  2. L

    Problems this morning with litespeed going unresponsive

    Well fwiw I haven't had any issues since blocking that network both in the firewall and LS <deny/> rules. Looks like a zero day. So far nothing to suggest it did anything beyond DOSing the LS service. I'm rolling out the latest update as recommended
  3. L

    Problems this morning with litespeed going unresponsive

    That's definitely the attack, hd-sam, that's the same URL we're seeing hit
  4. L

    Problems this morning with litespeed going unresponsive

    I'm blocking all of 188.120.224.0/20 LS mentioned 69.30.193.133, but I'm skeptical that one is involved. Keep in mind that if some network serves as a proxy for a request, it's going to show up too in the error log. The big pain here is that the bug will break LS through cloudflare or...
  5. L

    Problems this morning with litespeed going unresponsive

    Definitely the issue has to do with overflowing the HTTP authorization. Seeing it in every occurrence. The only server's that have gone down since blocking the russian IP (I blocked the /24) are ones that get proxied through another IP I haven't blocked: 2017-02-17 11:35:16.011 [DEBUG]...
  6. L

    Problems this morning with litespeed going unresponsive

    So far I have found no examples of a server going down that wasn't from that network. 2017-02-17 09:12:20.208 [NOTICE] [188.120.224.119:56848] Status 400: Http request header is too big, abandon! 2017-02-17 10:04:14.863 [NOTICE] [188.120.224.119:65358] Status 400: Http request header is too...
  7. L

    Problems this morning with litespeed going unresponsive

    So far so good after blocking that russian network... consider doing so yourselves
  8. L

    Problems this morning with litespeed going unresponsive

    Looks like an attack? Seeing this russian network on different servers right before they go down: 188.120.224.119 2017-02-17 11:28:04.987 [DEBUG] [188.120.224.119:61167] Headers: GET /rss/catalog/notifystock/ HTTP/1.1 Host:xxx Connection: keep-alive Accept-Encoding: gzip,deflate...
  9. L

    Problems this morning with litespeed going unresponsive

    Here's a debug log of one down on the latest version of LS:
  10. L

    Problems this morning with litespeed going unresponsive

    For everyone dealing with the issues this morning, here's what I'm seeing The nobody user fork of the litespeed process becomes unresponsive: nobody 722810 65.9 0.0 131856 18156 ? R<l 11:03 5:05 litespeed (lshttpd) ... and will appear to max out the CPU in top. strace reveals...
  11. L

    A feature request that would make me SOOOO happy

    Okay, so this is awesome for sure. I've benefited a lot from this... but it makes me want more :) Is there some sort of way to get a log of that same data, rather than having to poll it all the time? Edit: Just to be clear, the benefit here is having access to HTTP requests that trigger...
  12. L

    A feature request that would make me SOOOO happy

    Brilliant; that'll accomplish what I want to do. Thanks!
  13. L

    A feature request that would make me SOOOO happy

    Exactly. Is there some way to gather that without requesting that entire HTML page? Maybe some sort of option that dumps just that data in XML/JSON output, or some file similar to /tmp/lshttpd/.rtreport that contained the same information used in that GUI? If there isn't I'll just scrape that HTML.
  14. L

    A feature request that would make me SOOOO happy

    As was pointed out to me, it appears you guys basically have that (and more) in the GUI. (Real-Time Statistics: Requests Snapshot, with Ext-app Detail checked). Is there any chance at an API or filesystem interface for that information? Or should I start scraping the admin GUI :-P
  15. L

    A feature request that would make me SOOOO happy

    You've already got /tmp/lshttpd/.rtreport which is nice, we hook some stats into that... however, what I'd really love to see is a way to associate running external applications with their request information. Something like: { external_pid: 1234, start_time: 1471461438.423 user: litespeedrocks...
  16. L

    OCSP stapling with cPanel / vhost configuration

    Aside from running 5.0.19 , is there anything more involved? Above the virtual host: SSLStaplingCache shmcb:/tmp/stapling_cache(128000) In the virtual host: SSLUseStapling on
  17. L

    OCSP stapling with cPanel / vhost configuration

    I know OCSP stapling is supported with this method: https://www.litespeedtech.com/support/wiki/doku.php/litespeed_wiki:config:ocsp-stapling ... however, is there a way that is compatible with the normal httpd.conf cPanel utilizes? It seems like there's a sort of undesirable work-around here...
  18. L

    Recommended method for blocking useragents globally?

    Blocking user-agents at the .htaccess level is easy, but what about in the scenario where we want to block every request to the web server for a specific user-agent (ideally multiple bad user-agents)? What is the recommended method for accomplishing that?
  19. L

    [Closed] Handling cached form keys with LiteMage

    This wound up being an issue with the site's code closing prematurely, not litemage So in an effort to illustrate this, I found something interesting. Edit: Each are 3 separate requests to add the same product to the cart (after reloading the product page) With LiteMage Enabled and Secret Keys...
  20. L

    [Closed] Handling cached form keys with LiteMage

    > formkey is always privately hole punched. It is handled specially and by default. So the product page each user view will contain only his own form key. This form key will be purged by login/logout event. In the scenario I ran into, the issue is that the form key needed to be purged each cart...
Top