@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.

@dashrender said in VDI Options - Modernization:

@jimmy9008 said in VDI Options - Modernization:

@scottalanmiller

I get what ya'll are saying but thats just not how it is here. My options are replace what is there with new, or keep what is there and let it grow older.

I'll keep looking at options on my own, but thanks folks.

I'm lost - why are you bailing on this thread because one person said VDI is not how you should be moving forward? Other options were presented.

No one said it wasn't how they should move forward. We pointed out the fact that it's a legacy holdover and that by modernizing you don't need it (and haven't ever, VDI didn't come about until it was already a legacy need). That it's legacy doesn't mean it isn't the right way forward. People need to stop thinking that everything legacy is always bad, that's an inappropriate reaction to IT basics.

Old isn't always bad. It's well worth evaluating if there is a reason not to modernize, sure. But just because something is legacy does not automatically make it bad.

@jimmy9008 said in VDI Options - Modernization:

@dashrender said in VDI Options - Modernization:

@jimmy9008 said in VDI Options - Modernization:

@scottalanmiller

I get what ya'll are saying but thats just not how it is here. My options are replace what is there with new, or keep what is there and let it grow older.

I'll keep looking at options on my own, but thanks folks.

I'm lost - why are you bailing on this thread because one person said VDI is not how you should be moving forward? Other options were presented.

I don't see value in discussing why we have a VDI. The fact is we do and that will not be changing. Being told 'grumble grumble' that is not how to do it 'grumble grumble' is of no help to me. Regardless of what it does, VDI is staying. My options are keep the old stuff and hope it works for another 5 years until the next cycle, or use the budget I have to replace it for a new VDI stack. The project is not to asses the needs of requiring VDI, but to replace the VDI with a new VDI.

Most of the comments on the thread do not help with that so I gave up with it. Sure, if the project was 'get rid of VD' - but its not.

Somebody suggested Azure VDI, will take a look at that and keep looking at other options.

The value is that if we don't know WHY you have something, then no one can tell you which solution is even an option for you, let alone which one makes sense. This is IT, you can't do any meaningful aspect of your job in any other way.

No one, absolutely no one "needs" VDI, that's not a possibility. It's possible that VDI is a good option for you, but it's impossible that it's a necessity. No one is grumbling. Do not call "doing ethical IT diligence" grumbling.

If you have no control over the environment and have strict constraints, that's fine. But this is an IT question, so we need to know those constraints. No one is judging or saying you are doing something wrong. But we have no idea of the requirements so the first step of any investigation is "what is needed", then "how best to do what is needed." THat's where we are. We don't know why it is needed or when modernization will take place. We have to know if the company is on the path to modernizing and so VDI might be a very short term stop gap, or the plan is that modernization isn't even on the radar and VDI might be needed for decades to come (a common thing.) And we need to know all those needs and more to know what types of VDI, products, approaches, etc. will best apply.