@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

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.