Jump to content

kiwiphnx

Members
  • Posts

    23
  • Joined

  • Last visited

Everything posted by kiwiphnx

  1. Would it help to run Johnny (or, more appropriately, "Kenny") off a volume or filesystem that supports snapshotting, e.g. OverlayFS or LVM; the idea being to snapshot the OS daily and hosting accounts hourly, allowing most files to be kelp read-only and rolling back the snapshot upon server crash?
  2. We scanned the site for malware and got it up again on the new host. Long story short, WordPress or one of its plugins may have broken itself on the last update. Although I haven't yet connected the database on the new host; loading the site from cache revealed that the WordFence firewall is generating a request of around 250 bytes with every mouse movement. Perhaps this is a contributing factor to the problem?
  3. Thanks again. The medium-term goal for us is to migrate the site to a better-suited CMS such as Concrete5 or Drupal; WordPress was never really intended to be a permanent solution. At this point, however, we have committed ourselves to migrating the website to paid hosting on a shared New Zealand-hosted VPS; so whatever we do now will only be a very short term solution (two weeks tops). I have already updated CloudFlare DNS to point the www and static subdomains to the new server, so that will only leave small stuff like the URL shortener and some mail forwarding rules. I apologise again for the load on your servers, whatever the root cause turns out to be; and Phoenix Adviser Group Ltd. thanks you for providing the service that you do. During Phoenix's time on Tommy, I have tried everything I can think of to tune performance (believe me, 10s+ page loading times are no fun for us either); including deploying CloudFlare CDN, agressively caching the HTML output from WordPress, and writing a very complex .htaccess ruleset to try to bypass WordPress for as many requests as possible. I have even suggested ways in which HeloiHost can increase the reliability and uptime of all your servers by, e.g. deploying a high-performance reverse proxy (e.g. Varnish) in front of them; potentially allowing Apache restarts to be overlapped (on different ports) on the backend. I think what HelioHost does is very noble, and I want you to be as successful as possible.
  4. I notice the account has become suspended again; so I can only guess something has happened quite recently to cause the unacceptably-high load (WordPress exploit or misbehaving plugin, perhaps?). Fortunately, I did have sufficient time to create and pull the backup, so the matter is now much less urgent. With your help, I would suggest we reset both the document root and .htaccess; and rebuild a static copy of the site using the contents of /www/static/uploads and /www/static/cache/cache-enabler/; as it will take me at least a few days to rebuild the site on the new host and we cannot afford to lose our web presence during that time. If you do find any insights into what has caused the unusual load, it would be greatly appreciated if you share them with me; as my strategy at present is to assume the site has been compromised and to rebuild it from scratch.
  5. I've retrieved and deleted the backup. Now if we can only figure out what is causing the account to generate such a high load. Were we the target of an attack; Is the WordPress caching not working properly; or is there perhaps an error in the .htaccess rules? I want to work with you to serve at least a static version of the website while I work to get the site live on our new host; the biggest problem I have right now (and, perhaps, this is the problem) is that the mod_rewrite ruleset in .htaccess has grown so complex (primarily as a result of having to host more than one web on the account) that I am not entirely sure I have a complete understanding of them anymore.
  6. Quick question: One of the reasons we started looking for alternative hosting is because we have exhausted our storage quota. Do site backups created via cPanel count toward this limit; and, if so, is it possible to temporarily increase the quota so we can take a backup? If not, I will explore alternative ways to efficiently transfer the content offsite.
  7. Thanks for the quick reply, wolstech. I am rather surprised to find that it is causing high load; if you can help us discover the reason why this is the case, it will perhaps help both of us. I will immediately begin the process of archiving the site for transfer to another provider. Cheers, Administrator Phoenix Adviser Group Ltd.
  8. Username: kiwiphnx Server: tommy Domain: phoenixadvisergroup.nz As this is a business website, it is critical that we know the reason why our account has been suspended so we can reestablish our website as soon as possible. If this is due to resource usage; please be advised that we are in the process of transferring to paid hosting with another provider, but we will need (at minimum) FTP access to our account so we can pull the latest version of the website. If this is a suspected terms of service violation; what terms do you feel have been violated? Regards, Phoenix Adviser Group Ltd.
  9. Besides IIS and MSSQL, do you have any plans to run other Microsoft server software; e.g. Microsoft Exchange Server? This could be useful for end-users who want groupware functionality but prefer to use Microsoft Outlook or Windows Mail; which can't use CalDAV and CardDAV out-of-the-box.
  10. Thanks for the reply, wolstech. If that happens, will the plan be to deploy Plesk across all services, as a replacement for cPanel?
  11. Just out of curiosity, is or will there be a way for hosting accounts on Lily to be integrated with Microsoft Office 365 Business and Azure Active Directory?
  12. It's been down for more than an hour, now. I imagine the admins are doing the best they can to resolve the problem.
  13. Hi Piotr, Thanks for developing your monitoring system; it's really quite handy! One feature that I have thought would be really useful is to display a vertical cross-hair underneath the pointer, allowing to correlate events and read the time of occurrence off the axis.
  14. Thanks. If the blocks are permanent, could you please also unblock any other IPs in the network 118.148.0.0 - 118.149.255.255 (TWOdegrees-nz), as I hit another blocked IP (118.149.143.25) which I suspect may have been from a previous session, as I haven't created any new SFTP connections today. Cheers.
  15. The IP address 118.149.136.184 has been blocked for trying to log in to SFTP with the wrong password too many times. Reason: I was attempting to set up SFTP access in Konqueror so that I could transfer our media library to SharePoint. Mistyping the password probably didn't help.
  16. Thanks for the suggestion. You'll be happy to know we already use Cloudflare to cache and distribute our static content (which helps immensely). Unfortunately, I am yet to find a reasonable solution to the problem of caching WordPress' output. I have actually gone to the point of installing various caching plugins (specifically Autoptimize and Cache Enabler, although I have tried many others along the way) and configuring Apache to immediately serve pages from the cache (bypassing WordPress completely) whenever possible. Unfortunately, WordPress relies on cookies to determine whether a user is logged in, which necessitates the sending of a "Vary: Cookie" header, which effectively kills any shared caches along the way. If you go with a reverse proxy, it may also be a reasonable compromise (security-wise) to offload SSL from the origins to the proxy, freeing up more valuable CPU resources. If required, local traffic between the origins and the proxy could still be encrypted and sent over an aggregated, reusable connection, which would at the very least avoid the expense of repeatedly setting up and tearing down SSL connections at the origin.
  17. That's actually a very good explanation of the highly variable response times of Tommy; and I apologise if I came across as self-centered (that wasn't the intention). I believe I want the same thing you do; for HelioHost to be the best possible service it can be; and I am willing to work with you to help achieve that goal. That said, I think the service you offer already is pretty terrific and your passion towards the community is admirable. I represent and can find clients that would be prepared to back you with real money if we can find a way to make your services more dependable. Please help me to find a way to help you achieve this goal. One suggestion I could make (apologies if you've already considered this) is to put a reverse-proxy (e.g. Squid or Apache with sub-requests) in front of your webservers (physical or processes), configured such that it can immediately serve a cached response (appropriately marked with a 502 or 503 response code if the cache is stale) while the origin webserver is restarting. Doing so might even help reduce the load on your origin servers for static content such as images, giving Apache more time to generate dynamic content.
  18. Thanks for the response and the feedback. No, I don't consider 100Mbps slow; in fact, I'd be very happy to obtain a transfer rate that was anywhere near the 1Mbps that our DSL connection would allow (for uploads). Perhaps it is our round-trip-time to the server that is the problem; I'll try your suggestion of tarballing and see if it helps our specific situation. Another, possibly related phenomenon is that we often experience lag times of up to 3 seconds when accessing our website over HTTPS. I assumed this was due to server load, as we don't seem to have such problems with other NZ-to-US traffic.
  19. Thank you. The new post is here: https://www.helionet.org/index/topic/30608-suggestion-reduce-server-ftp-load-by-supporting-and-encouraging-use-of-rsync-protocol/
  20. Hello Helionet, My observations of using Nautilus' DAVS support to transfer files to/from Tommy (I can't seem to get SFTP/FTPS to work reliably for some reason) have been that file transfers seem to take a lot longer than they should. It also occurred to me that the majority of FTP-like traffic would be clients either modifying and re-uploading their sites, or taking backups. Therefore, it seems there is the potential for a performance gain by supporting, and encouraging the usage of, a differential file transfer protocol such as RSync; possibly transported over SSH or SSL to provide encryption. My suggestion is to have a look into this (there is a Node.js RSync implementation that could be used to provide cross-platform support via a web browser) and see what potential performance gains, if any, can be had over vanilla SFTP/FTPS/DAVS; although I suspect the SSL encryption cost would far outweigh rsync's file checksumming cost, especially if the results of the latter can be cached.
  21. Your IP has been blocked! The IP address 118.149.153.163 has been blocked for trying to log in to SFTP with the wrong password too many times. To prevent this from happening again in the future please make sure your username and password are saved correctly in your SFTP client. You won't be able to continue to cPanel until an admin unblocks you. I don't quite understand why the block triggered, as the file transfer looked as though it was working, albeit a little slowly. Too many connections, perhaps? Explanation: Although I have tried using FTPS/SFTP previously, it seems the only protocol I can get to work reliably is DAVS, but that seems to be excruciatingly slow for some reason. Is there any chance you would consider supporting rsync?
×
×
  • Create New...