@NetworkNerd

1. Identify the Cause of High Disk IO and CPU Wait MariaDB Activity: Since mariadb is showing high IO during the problematic window, it's crucial to identify the queries causing this load. You can enable the slow query log in MariaDB to capture queries that are taking an unusually long time to execute. Scheduled Tasks: Check for any scheduled tasks (cron jobs) on the server that run around 5 AM CST. These could be system tasks, WordPress cron jobs, or database maintenance tasks. 2. Systemd-journald Failure The failure of systemd-journal-flush.service suggests that the journaling system is overwhelmed, likely due to the high IO load. Investigate the journal logs (journalctl) for any errors or warnings that occur around this time. 3. Review WordPress Plugins and Activities Plugin Behavior: Even though plugins like Updraft Plus are scheduled for different times, they might be triggering background tasks. Verify plugin behavior and logs. WordPress Cron: WordPress has its own cron system (wp-cron.php) that can sometimes trigger resource-intensive tasks. Review the WordPress cron events. 4. Server and Database Optimization Database Optimization: Run a check and optimization task on your MariaDB database. Over time, databases can become inefficient and slow. Upgrade Resources: An e2-micro instance is quite limited in resources. If this issue is related to resource constraints, consider upgrading the VM instance type. 5. Monitoring and Logs Enable Enhanced Monitoring: Tools like sar, iotop, or atop can provide in-depth system metrics. Make sure they are configured correctly. Access and Error Logs: Review NGINX, PHP-FPM, and MariaDB logs for any anomalies during the problematic time frame. 6. External Factors Traffic Spikes: Although Jetpack stats show low traffic, consider checking the access logs for unexpected traffic spikes, which might be bots or crawlers. Network Analysis: Use tools to monitor network activity. Unexpected external connections might be contributing to the load. 7. Testing and Isolation Isolate Components: Temporarily disable certain components or plugins during the problem window to see if the issue persists. Test in a Staging Environment: If possible, replicate the setup in a staging environment to test without affecting the live site.

@wrcombs said in Certificate Authorization Error:

@jaredbusch said in Certificate Authorization Error:

@wrcombs said in Certificate Authorization Error:

Any ideas?

Also, update windows and Chrome.

Did windows updates this morning and chrome is up to date..

You just want to make sure Windows and Chrome have the latest CA root certs in their stores... that's why he's recommending doing that.

@Skyetel said in Skyetel sign up working better:

Maybe this?
https://mangolassi.it/topic/20290/ad-blockers-advice

I thought I had posted in your thread because I know that you posted that after my issue.

So yup, going with I slacked and didn't post.

@IRJ You are passionate about computers, you love to write code. Well, what's more exciting than being able to create your own plugins.

When you know that WordPress is today one of the most used CMS on the web, it would be really interesting to see how a plugin is made and to be able to create it yourself. [Check it here] (http://bit.ly/2KxPChJ)

@black3dynamite said in Downloading full Website offline:

@scottalanmiller said in Downloading full Website offline:

@black3dynamite said in Downloading full Website offline:

@dbeato @scottalanmiller

https://github.com/mariomaric/website-size

But does it really not download everything? Websites don't report on the size directly AFAIK.

Using --spider, does not download the pages.
Using --no-directories, tells wget to create empty directories.

So it gets it all from "Content Length"? Interesting. Guess that would work.

@scottalanmiller said in [Solved] All computers cannot access 1 specific site:

@manxam Well that worked out then 🙂

I did. We're not ones for forcing tech on clients but there's a limit to client risks that we're willing to live with.
This particular client deals with a LOT of sensitive data and it always bothered me that they had a known vulnerable router in place that we had to admin with a 5 year old version of Firefox.

YOu can also do a free test from Qualys
https://www.qualys.com/free-services/
https://www.qualys.com/community-edition/

Registration is by form submission. Then you'll be emailed with payment details. It's getting updated to explain that, now.

@phlipelder said in Website hosting: Which direction to go:

I'm in the process of figuring out how to set up Wiki.js on Ubuntu running in Azure with a MongoDB backend and Apache fronting for SSL.

MongoDB will be phased out in Wiki.js 2.0.0
https://github.com/Requarks/wiki
0_1532199283945_03dba03f-a33e-4ce2-a8a5-d95a0c45e1b3-image.png

2012...ouch, scrap this one then....

So the existing website is built on DNN, which Bitium has a SAML SSO solution which may work for this.

Still investigating.

@coliver said in Digital Phone Lists - Internal WebSite:

What kind of phone system do you have? Why not use something like FOP2? That way the phone list is always up to date. If you're using FreePBX you can write a script to output a phone list nightly.

FOP2 is a great choice for a viewable panel. but it is not a list for quick reference.

I keep 3 tabs open with FOP2 most of the day. 2 clients and our phone system.

@Kimberley-Paessler said in How do you test your website:

@DustinB3403 If you (or your customer) are using PRTG, you could use the "cloud ping" and "cloud http" sensors to monitor reachability from around the world. Those sensors will try to reach your website from 5 different AWS data centers, and will report on reachability and response time from each of those data centers. If something goes wrong, you can get an alert, so you know you need to react. The free version of PRTG will let you run 5 cloud http and 5 cloud ping sensors.

If that's not enough, check out services such as https://www.site24x7.com/, which provide similar ongoing monitoring on a larger scale.

If a one-time or manual test is enough, check out services like https://tools.pingdom.com/ or https://www.webpagetest.org/, which are free and don't require any setup on your side, but only provide a snapshot of up/down at the time you try them.

Along with pingdom, we usually use https://geopeeker.com which also gives a snapshot from multiple locations

I also recommend developing the site on pantheon and then moving it to your server. It's much easier to develop there.

I like it.

@FiyaFly said:

I have Centurylink at home. I can do a quick check from there when I get home. Maybe unrelated, but I was having some severe issues with DNS a couple weeks back at home.

I'll post more info on my findings tonight.

Thanks.

@scottalanmiller said:

Old ilO too.

...all old and current iDRAC.

@anonymous said:

I can handle this for you for a flat fee. I promise results within 30 days, or your money back.

Lol. We have to do this the legal way. We are a large company and someone is always trying to sue us. Heck we have people try to send us product we never order then sue us when we don't pay their invoices.

@Carnival-Boy said:

But it's about doing your own cost-benefit analysis. It's too simplistic to say you should never run legacy applications.

Of course, there are always times that legacy applications need to be run. But there are limits too. ASP as a platform has been legacy for a decade and a half. That's a long time. It has a pending end date for when it may not be available any longer in any capacity. It presents platform level risk which may prove to not matter, but may prove to be extremely limiting in the future - that's the nature of risk, we don't know what will happen with hardware and software down the road. But it is technical debt building up in a platform that is nearly all of the way through its "trailing off support" timeframe.

It's fine to have legacy apps. But it is also important to identify when a legacy app is becoming too legacy. In the OP's case, ASP created support and hosting risk in addition to normal concerns. Those were probably types of risk that were not considered in the past. Any business running ASP is constrained if they decide that they want to go hosted, for example. They might not ever decide to do that, but there is technical debt potentially making that decision for them, as well.

Any ongoing support of an ASP legacy app means that investment is being put into the old system. Maybe that is trivial, maybe it is major. Technical debt is a hidden cost. Money goes into keeping the old system running instead of being implemented in a new system. The effort to support the old could offset the effort to replace it.