@braswelljay said in Centralized Log Management:

I was hoping to see what others might be doing to address these kind of issues.

Most people don't have those issues. Retaining logs of a year is pretty much unheard of. Even Wall St. firms don't do that. Military might of course. But very few places can utilize a server log in real time, let alone a week old one and to start pouring through year old logs.... totally pointless.

While there are times this might make sense, dollars to donuts your "cybersecurity" team has no idea what they are doing and making completely bogus requirements because they sound good to management but have no technical (ergo security) merit. No one responds to an incident a year later. That's ridiculous.

Storing logs is expensive. Really expensive. No one does it. Not like that. It makes no sense. I'd ask for a pretty serious business explanation of how the cost of building, maintaining, and storing all that data is justified from their security response position. I guarantee once you ask them to explain, they'll be forced to admit they have no idea what they are doing.

https://aws.amazon.com/opensearch-service/the-elk-stack/what-is-opensearch/

@coliver said in Quickbooks replacement:

Literally anything else? Sorry that's less then helpful. Have them look at https://www.xero.com/us/.

Anything else is the best answer.

@dashrender said in Centralized Log Management:

He was audited by what we assume is a third party likely strickly pointing out best practices. These pointed out items likely don't take the specific company and their current setup into mind at all.

Not possible. In order to be a best practice is MUST apply to all businesses. If you have to evaluate the efficacy of something, then it's a "rule of thumb" at best.

If they presented this as a best practice, they are a security risk and we know that they are being dishonest. It is a good security practice, from an isolated "security without business concern" perspective. But in business, security like IT, is a business function. All security has to be seen in respect to its business protection value. If the security costs more than it protects, it itself is the failure.

@jaredbusch said in CentOS - What is the current opinion here?:

@adamf said in CentOS - What is the current opinion here?:

Is anyone using CentOS stream in a production scenario?

I don't but I would, but then I already use Fedora in production.

Right, if you think you want CentOS Stream, Fedora is like the production ready improvement on it. It's not that Stream is bad, it's that Fedora is better in like every way, while being essentially the same basic product. Stream is just a ridiculous half-assed byproduct of Fedora. If you love the ecosystem, stick with Fedora. I use about half Fedora and half Ubuntu. Both are great.

@pete-s said in CentOS - What is the current opinion here?:

@jaredbusch said in CentOS - What is the current opinion here?:

But this is the thing, not all applications are designed to run on various operating systems. So you do not always have the luxury.

That's true, you have to run what works. But most of the time you can stick to one OS.

Not that we've found. Finding an environment where you are running Linux, and can avoid all variation is pretty rare, I think. So many apps only work on Ubuntu XOR CentOS. It's a mes out there.

@jaredbusch said in Centralized Log Management:

@scottalanmiller said in Centralized Log Management:

should be evaluated for efficacy in the given environment."

That is how exactly zero "audits" work.

It's how ALL honest audits work. The problem is, like most MSPs who are secretly scam VARs, almost all audits, especially those hired outside of IT by incompetent managers, bring in scammers with no knowledge, qualifications, or honesty who just seek to defraud and are, themselves, a security risk.

We do audits, however, and we'd never present that way. Real auditors are out there. But people don't like to hire them because they can't produce checklists and shopping lists.

@pete-s said in P2V conversion:

@wls-itguy said in P2V conversion:

I have two physical servers that would take a great deal of time to rebuild to virtual so a conversion from P2V would be ideal. What are you guys using to do P2V conversions?

I was looking for VMWare's converter but I don't think it exists anymore.

It's better to just reinstall on a new Windows (I'm guessing) and do whatever upgrades that are needed at the same time.

P2V is not a good generic solution. Consider it for quick and dirty band-aid solutions only.

Totally agree. Use migration time as a good time to run side by side and migrate the app and update / cleanup with a fresh install. If you have good procedures, this will be trivial. If you don't, even better, this is a chance to catch gaps in the knowledge base.

@pete-s said in Centralized Log Management:

@scottalanmiller said in Centralized Log Management:

@braswelljay said in Centralized Log Management:

Does not collect server, application and network logs sufficiently to respond to and investigate a cybersecurity incident

This is not a bad thing. Collecting logs is good, centrally is best. But only if you have a team that can use them. If you had that, likely you'd already be doing this. So the question is... before doing this, do you have a team ready to leverage it? Or is this just a way to potentially spend more money with the "cyber security" guys because there's no better way to make money than getting paid to read logs.

Standards such as ISO 27001 have requirement that logs are protected. If an intruder gains root privileges on a server the only way to protect the logs is to have them stored somewhere else. So having central logging might be a compliance issues in some cases.

Not many companies need to follow that. And that's one of the reasons that those certifications are so often considered bad.... they make core business decisions a requirement when they rarely make sense.

@pete-s said in CentOS - What is the current opinion here?:

My opinion is that a company should pick one linux OS as their standard and stick to that for everything possible.

I wrote about this in my book. It feels good, but I think it is generally impossible. And once you have variation, attempting homogeneity falls apart in value. You can generally get by with a few different OSes with minor variation. For us that means Ubuntu, Ubuntu LTS, Fedora, Debian, and CentOS Stream are required in some combination. We can't standardize on any one because we have a workload here or there that requires something "niche". When we have the choice, we are using Ubuntu first. Then Ubuntu LTS, then Fedora. But it's always workload based and going with just one wouldn't be practical unless we were only running software that we wrote ourselves exclusively.

@pete-s said in CentOS - What is the current opinion here?:

I'm curious about what workloads you are thinking about.
I try but I can't think of any major application that doesn't run on both debian and redhat based distros.

Zimbra is one that always gets me. RHEL / CentOS/ Ubuntu LTS only. And they've tried to block CentOS in the past, but gave up on that.

@phlipelder said in CentOS - What is the current opinion here?:

@travisdh1 said in CentOS - What is the current opinion here?:

@dashrender said in CentOS - What is the current opinion here?:

@scottalanmiller said in CentOS - What is the current opinion here?:

@pete-s said in CentOS - What is the current opinion here?:

@jaredbusch said in CentOS - What is the current opinion here?:

But this is the thing, not all applications are designed to run on various operating systems. So you do not always have the luxury.

That's true, you have to run what works. But most of the time you can stick to one OS.

Not that we've found. Finding an environment where you are running Linux, and can avoid all variation is pretty rare, I think. So many apps only work on Ubuntu XOR CentOS. It's a mes out there.

You can say that again.

Ok, I will, just look at my home lab! Fedora, Ubuntu and Debian because things either only run or run much better on different ones.

Say what one wills about Microsoft Windows, this conversation makes it clear that things are relatively homogeneous on that side of things. All things being equal and the company is not stuck on some encapsulated AS400 app or something.

It seems that way, but I feel like Linux apps tend to be almost always for current versions of the OS. At least production ones. But on Windows the amount of "we only support really old versions" is really high (of course, you can argue, anything that does that can't be production, right?)

But really, the issue is that Windows is an OS and Ubuntu is an OS. So there is no fracturing. The thing that gets weird is when you look at a large family of similar operating systems and compare them to the single OS of Windows. Sure, it seems fractured. That's because we are comparing an orchard to a tree. OS to OS, there is no fracturing.

There's no direct comparison. In the Windows world, though, you get "only licensed for Server" or "only runs on desktop" version issues that create similar fractures even on a single OS. We are constantly talking to clients about having gotten the wrong OS version for their needs. That never happens with Linux because there aren't those licensing limits or version in that way. It's a totally different style of problem, but it exists there, too.

@phlipelder said in CentOS - What is the current opinion here?:

Say what one wills about Microsoft Windows, this conversation makes it clear that things are relatively homogeneous on that side of things.

I think that the bigger thing in the Linux world is that sure, we have this "problem" where we often need Ubuntu, Fedora and maybe something else to deploy all of our apps. But the big question is... why does it matter? They are all free. They are all the same licensing. They are all effectively the same - if you know one you know them all. The same tools and management works across them. You don't need special cross training or anything. It's trivially annoying to have these tiny differences, but they are truly tiny. At the end of the day, I run at least five or six different distros of Linux for our fleet and the amount of time that I have to think about it is... zero. It's a zero problem issue.

Sure, in theory, it adds some problems. But in practice it doesn't. And if you start using any amount of automation, it truly vanishes completely to the point that you'll never even know that there are different distros in the fleet. Now, if you get Windows to the same point, it'll just merge into the fleet too, in theory. But some things, like licensing, always remain unique. As do drivers and stuch.

So while I might need to have a few deployment images for Linux to cover my bases, it's essentially background noise. I have to have different Windows images too for my Windows needs (OEM, generic, server, desktop, and each licensed version), and even being primarily a Linux shop, we have way greater Windows variety in practice (customers running every version from 2003 and forward because of licensing problems) with Linux being almost entirely current (or current LTS) and only about four distros in practice.

@phlipelder said in CentOS - What is the current opinion here?:

With support our preference is to be as homogeneous as possible. Having so many distros to manage and update instead of just one Windows OS with perhaps a few versions online looks to be a lot more complex.

In theory, and if that is a need, you can force yourself to a single distro / image. But in practice, they are so similar as to be the same. The cross platform knowledge delta is nominal and even having to patch four or five distros literally means 1% maximum the effort and risk of patching a single version of Windows. From a Windows world perspective, where the single "trunk" is fragile and constantly breaking, adding more trunks is scary because we assume each is as fragile. In the Linux world where most of the enterprise trunks are super stable, you get a different reaction. It's safer and easier to manage a large variety of Linux than one Windows.

@pete-s said in CentOS - What is the current opinion here?:

My guess is that Zimbra is getting by on mostly legacy installations though. Self-hosted email is hard to justify nowadays.

I think moreso they are killed off by their crap licensing, BS installation practices, lack of updates, and MailCow coming along and taking their candy away.

IF you feel the crazy need to host your own email, MailCow does it better than Zimbra, and is truly OS (and deploys natively to Docker.)

@hobbit666 said in Centralized Log Management:

@scottalanmiller said in Centralized Log Management:

OpenSearch from Amazon. They took the ELK stack, made it 100% open source, and back it by Amazon. It is so good both in technical product and in licensing, that essentially it is the only game in town now.

Interesting take from ELK side
https://www.elastic.co/what-is/opensearch

Our products remain free and open, but Amazon can no longer freely use Elasticsearch and Kibana products without collaborating with us. Rather than collaborate with us and contribute back, Amazon created its own forked projects, which are less mature, not ready for production use, and provide inferior capabilities compared to Elasticsearch and Kibana.

That's BS. It's that you can't just use their products. It affects everyone, Amazon only did it because their customers needed it. Not because Amazon needed it. ELK is full of crap.

@pete-s said in Centralized Log Management:

@dashrender said in Centralized Log Management:

@hobbit666 said in Centralized Log Management:

@scottalanmiller said in Centralized Log Management:

OpenSearch from Amazon. They took the ELK stack, made it 100% open source, and back it by Amazon. It is so good both in technical product and in licensing, that essentially it is the only game in town now.

Interesting take from ELK side
https://www.elastic.co/what-is/opensearch

Our products remain free and open, but Amazon can no longer freely use Elasticsearch and Kibana products without collaborating with us. Rather than collaborate with us and contribute back, Amazon created its own forked projects, which are less mature, not ready for production use, and provide inferior capabilities compared to Elasticsearch and Kibana.

LOL - someone sounds like they are just complaining that their toy was taken.

True, but they are probably right. Amazon and other providers bastardize open source projects because the licences doesn't require them to share their changes with the open source community.

That's not what the issue was. It was that they were allowed to USE the software without paying for it. It had nothing to do with being open source, and everything to do with having been free (to use.)

@dustinb3403 said in Need Regex Help:

I need some help with some regex,

Every tool has its own regex. Which regex do you need?

@siringo said in Free Hosted Help Desk?:

Wondering if anyone is aware of a reasonable, free, hosted helpdesk system?

We use FreshDesk. I don't like it, but it is free and hosted.

@jimmy9008 said in VDI Options - Modernization:

@pete-s said in VDI Options - Modernization:

@jimmy9008

What I've seen large corporations do is to retire their VDI solutions and find other ways to fulfill whatever they were trying to accomplish with VDI.

So it makes sense asking what your trying to accomplish with VDI and looking at other ways to accomplish it.

Any centralized solution will have limited scalability by it's very nature of being centralized. That goes for your VDI solution too.

Interesting. Do you have any specific examples?

The VDI solution actually does what we need and has for a long time, we are just at the point where we need to replace the stack as its in our replacement window. 5-7 years old is not something we wish to keep. Plus, if doing a replacement we should look at other technologies (including no VDI if you have any specifics?)

Yes, if you are on legacy apps that aren't up to twenty years ago standards, VDI often meets that need very well. But VDI is slow, cumbersome, expensive, and unnecessarily risky. It's a bit weird that your organization is concerned about a five year old VDI solution, but not worried about workloads that are assumed to be ancient and unmaintained (or poorly maintained.)

The examples of moving away from VDI are everywhere... basically every business that moves to modern software has zero value to VDI, those that don't often want it.

In veterinary we can use this example a lot. Ancient software is the mainstay in the industry - almost every clinic using the market leaders (all of which are unmaintained for 25+ years, many over 30) use VDI to make the software work better, more securely and be available remotely. But it adds a lot of cost to already costly and risky solutions.

Any clinic running anything remotely modern thinks this is crazy, Because all the modern clinical apps are web based, have zero need for Windows at all, let alone VDI, and can naturally be accessed from anywhere and are vastly more secure.