@francesco-provino said in KVM or VMWare:

@rjt said in KVM or VMWare:

@francesco-provino Amazon Web Services may have a slight disagreement with you on whether KVM or XEN is suitable for business.

KVM and XEN are suitable for the business case of an hyperscaler of course, but the question of @WLS-ITGuy was literally "We're getting ready for our server refresh and along with that our license is up for renewal for VMWare. I am curious to the benefits of KVM over VMWare." -> so they are a small shop already using VMware.

It totally makes no sense to switch from VMware to KVM or Xen-based solutions in his business case.

I'd say the exact opposite. Now, that he already has VMware gives VMware an edge, where it would never have made sense to put in VMware in the first place, but since it is already there the least effort is continuing with it. But the effort to switch is half in the evaluation, and half in the doing. We move customers off of VMware to KVM regularly and it is fast, easy, and once done, it reduces their risk and cost (mostly by reducing support, but also reducing the need for third party software and, obviously, VMware licensing itself and the biggest cost, consulting hours for VMware licensing.)

In the OP's scenario, VMware is a solid consideration. But does KVM have absolutely crystal clear advantages? Yes 100%. At the OP's scale, VMware is technical debt. The question is only... is the debt too great to bother eliminating? Do they live with a "good enough" solution, or invest in a longer term, easier to support, lower cost, lower risk alternative? The problem is that it's only a little less support, only a little less cost, only a little less risk. So it is a hard comparison.

But the one thing we can guarantee is that no solution is an obvious choice. Not VMware, not KVM. It's a business decision based on a lot of small factors.

The biggest single reason to avoid VMware is the ecosystem around it that is so unhealthy and pushes it and other paid for, licensed, add ons and costly support models very, very strongly without generally any evaluation of the customer's needs. Because VMware is a product sold through the channel, and one with massive profits for the sellers and supporters of it, it creates a system of people and vendors industry wide who push it for their own interests and that's dangerous to customers.

@vigneshn said in magento:

how i fix this
Too many arguments, expected arguments "command".

When are you getting this error, and where?

@gjacobse said in Mesh Central: Display Change on remote:

Does MC all for full interaction when making Display Changes? Specifically - When applying settings, can you click the Keep Changes?

It must because I do that all the time.

@travisdh1 said in Lenovo - if it's on your network, you ARE breached.:

@scottalanmiller said in Lenovo - if it's on your network, you ARE breached.:

@gjacobse said in Lenovo - if it's on your network, you ARE breached.:

Thanks for dumping ice water down my back.... We use Lenovo for every laptop and desktop.

It's basically the only thing Lenovo is known for.

Knowledge of Lenovo's misdeeds is STILL unknown to most people. So I'm going to have to bring it up in the next all-hands meeting here

Not exactly unknown. Mostly ignored. Not quite the same. People hear about it and instantly say (to themselves), "I don't care about this, it doesn't affect me" and chose to move on and not internalize what the risks of Lenovo mean to them in a meaningful way.

@dashrender said in Did you notice the Skyetel outage today?:

yes we definitely noticed.

users were calling me mins before the notices from Skyetel were being sent out.

Yeah, Skyetel had the status message up and a fix SO fast BUT... with as many customers as we have, we were inundated with tickets and calls about the outage (because calls between customers and us were still working) before the route around was able to take effect. Luckily we spend most of the time just telling people to "check again, we think it is already fixed" rather than "we have no idea how long this will take."

@dashrender said in Lenovo - if it's on your network, you ARE breached.:

@travisdh1 said in Lenovo - if it's on your network, you ARE breached.:

@gjacobse said in Lenovo - if it's on your network, you ARE breached.:

I'd like to see recent references; everything I have found hasn't been updated / linked to since 2019 about the 2014-2015 incident.

What has changed? Nothing.

Why should anyone keep reporting no news?

Exactly - There's nothing newer because they haven't been caught doing any dirty shit in the past 2-3 years. But at the same time - the same management is in charge, so why would we expect them to do things right?

I think that they've been caught. It's just so unimportant to American consumers if Chinese companies are spying on them that literally reporting it has no value.

@dashrender said in Active Directory Domain name:

@siringo said in Active Directory Domain name:

@dashrender said in Active Directory Domain name:

@siringo said in Active Directory Domain name:

so are you guys saying that the new thinking is now to give your inhouse, private AD domain name a subdomain name of your public domain name?

I wouldn't call it new - it's been since at least 2016, and likely longer than that.

is that primarily to avoid that macOS stuff Scott mentioned?

I believe dumping .local was to avoid the mac issues, the subdomain use is because of DNS.

I never did any 2000/AD training (3.51 for me) but I can clearly remember reading MS technotes that mentioned using .local. That's why I've used that since.

I believe .local came into vogue around Server 2003 (maybe 2003R2) and was stopped around Server 2008 or 2012.

Oh, OK. Thanks for that. I'd never heard of any of that before. Good to know.

FYI - Local was also dumped because it's not a valid TLD (Top Level Domain) - i.e. can't be used on the internet. Certificate makers are now refusing to include domain.local in new certificates.

Not also, it was kept until there was competition over the private (can't be used) TLD. Apple and MS both chose it because it couldn't be used that way. No certificate maker should ever have included it (and I've never heard of that as it would always indicate a scam CA as you cannot own that domain by definition).

Any CA that issued that can't be trusted and is a huge security risk.

@stuartjordan said in Neglect in the highest? Shocking!:

How can this still be happening in nearly 2022.

Because these aren't IT pros or IT firms. These are VARs scamming customers.

@stacksofplates said in Active Directory Domain name:

@dbeato said in Active Directory Domain name:

@scottalanmiller said in Active Directory Domain name:

used that way. No certificate maker should ever have included it (and I've never heard of that as it would always indicate a scam CA as you cannot own that domain by definition).

The Majority if not all did add the .local, .lan and others, unless you think all CA are scams then I wouldn't say they are a scam.

Yeah from a quick search looks like at least GoDaddy and Digicert offered them.

Nov 2015 is when CA/Browser Forum set the standard to not allow internal domains. So looks like most if not all would have supported it before that.

https://cabforum.org/internal-names/

Damn, that's a major security hole! So I could go get a cert issued for a domain someone else used and there had to be zero verification since.... there was nothing to verify!

@dashrender said in Active Directory Domain name:

I guess that makes most CA's scams.

That's not what did it, but yes, yes they are.

Because if it wasn't blue, calling it the blue screen of death would have been way too confusing.

@scottalanmiller said in Responding to "This BS called URE" from Synology Forums:

You don't even need a raid to be able to do that test.. But funny, that doesn't happen.

Actually, you can't test with RAID, because the RAID system protects against UREs essentially completely. RAID only fails from a URE when you have a URE happen on one of the drives in your array at the exact same moment that another URE happens, at the exact same moment, on the exact same bit (parity or mirror) of every drive in the array. On RAID 5 that would mean on two drives, on RAID 6 on three, on RAID 7 on four and on RAID 1 on as many drives as you have in your array (which is often two, but can be any number that you like.) So while a single URE happening is basically a guarantee, and often. Two matching and simultaneous UREs happening even on RAID 5 is so unlikely that it would not be expected to happen in the entire history of humanity. but in theory, it could.

Then he says "funny, that doesn't happen" as if he's never used a computer. People with hard drives without RAID see this constantly! UREs are the most common cause of corrupted files which can do terrible things to your computer or just cause that little spec in an image file that you don't always notice. Audio, video, and other creative professionals are used to looking for these. Office workers are familiar with files corrupting. IT is called in all of the time to repair computers that have had system files get corrupted. Saying "funny, that doesn't happen" is a weird way to phrase "as anyone who uses a computer knows, this happens so often that we all experience it and see it as a normal part of computing."

@scottalanmiller said in Responding to "This BS called URE" from Synology Forums:

But your disk has billions upon billions of sectors, and each and every one of them has it's own URE. so that is why your disk does not fail and seems to keep on working day after day.

Right, disk failures are by each sector, and that's all. Hence why people just live with them and don't bother protecting against them in most cases. A single sector failure is pretty low risk to a normal computer user. This is all exactly as all URE discussions have said. He's not revealing something new, just pointing out the obvious. The drive doesn't fail, one sector gets a URE out of billions that get read.

The idea that a disk would fail from a URE is a weird injection that he has added here to make people think that the unknown other party is insane. But no URE discussion anywhere assumes that a disk will fail. That's why disk failure and URE are two different failure conditions entirely.

@scottalanmiller said in Responding to "This BS called URE" from Synology Forums:

The premise is that when doing a RAID rebuild, that the process will stop on the occurrence of one of these read errors that WILL happen at some point in time of the first 11.3TB of data read off any of the disks. But why would this happen? Does the disk itself know that the data it just read was faulty and give an error to the Synology? Isn't that really a MTBF ?? Or is it just that when doing the CRC calculation to try and rebuild the missing block, that the calculation will result in a value that just is not possible so it will fail? But that doesn't make any sense either as all you are doing is for example, reading a bit that should say 10110000 and getting 10010000. A single bit error that will give you the wrong result but why would it actually stop anything.

So all you are really assured is that doing a rebuild, you are likely to get a bit error that will have a chance of changing some file at some point on the RAID disk. But the chances are about the same as you reading a file off the disk and getting a bit error and not knowing it, and then saving that now wrong file back to the disk.

I am perplexed then at what the issue really is ?

So there is "premise" and "what the issue really is."

First, it is not a premise, it is how MD RAID, and all enterprise class RAID, works. In parity RAID we don't know what the impact is because the RAID system has no knowledge of the data on top of it and the array acts like it is a file (it is actually a volume, but the difference is the same.) When an exposed URE is encountered, whatever scale the layer is that is affected, is lost. In the case of mirrored RAID or no RAID, it is a sector. One bit is bad, the sector is scrapped. In the case of parity RAID, the minimum size above it is the volume which is mapped to the array. So the entire array is lost because it is a single unit that cannot be safely calculated. This is just parity basics, it's not a premise.

So what the issue really is.... is what has been stated ad nauseum and he is ignoring... that an exposed URE on a parity array being rebuilt causes the array to be in an unsafe state and dropped. It isn't that the array makers want to lose all of that data, it is just the granularity at which it can no longer be trusted.

@scottalanmiller said in Nextcloud 23:

@stuartjordan said in Nextcloud 23:

You just go to configuration > Nextcloud Office > and select use this server.

Where do you find any of those settings?

Have to scroll down, haha

@dashrender said in ProxMox eating SSDs?:

Anyone run into this issue on enterprise hardware?

There is no "issue". Even those that claim that they are running into it, it's consumer drives with HA logging going to those drives. Its' nothing to do with ProxMox, it's just standard, everyday CoroSync logging. The people saying "this is system administration basics" are correct.

@jasgot said in Nextcloud 23:

You'd think they would use the same name for everything and outline the steps somewhere to get is all installed properly. Sheesh!

I noticed the same mess. They have had this all screwed up for some time. It makes no sense and there is no automatic dependency handling or clear guidance.

@voip_n00b said in ProxMox eating SSDs?:

I eat 14 enterprise SSD’s every morning for breakfast. Very tasty and full of protein. The consumer ones are terrible tho and taste like cardboard. Always get the enterprise ones.

SSF

Solid State Flakes

@dashrender said in New customer - greenfield setup:

They want web filtering to keep porn/guns/violence, etc at bay.

I'd start by moving this from a hobby/emotional discussion to a business one. What "business value" are they looking for. The point here isn't to make them act like a business if they aren't one, but to use this process to define their real goal because the answer to your question is determined by that.

Right now, maybe they did a bunch of research and business thoughts and know that they need some filtering. unlikely, but plausible. But they aren't relaying enough of that information to you (suggesting that there is none) so you don't know how to solve the problem because you are lacking the information necessary to do so that had to be used to make a business decision to do so in the first place.

Also, if this WAS a business decision, how did they reach it without talking to their IT and getting the IT costs and options as part of the process? They can't, ergo we know it's an emotional response. But that's separate.

@dashrender said in New customer - greenfield setup:

Of course it's really only worthwhile where we can do SSL inspection (can this be down without installing certs on the clients to allow MiTM inspection?)

Nope, that's physically impossible. These types of devices I see as reckless because they are often poorly maintained, often made by questionable vendors (Sophos is fine, but many others are less respectable) and provide a single point of total egress of your data with nearly all assumed protections removed.