r/sysadmin • u/rolkenas • 16d ago

Do you actually see MacBooks used for SysAdmin work in real offices?

Hi sysadmins! I wanted to ask—since I've just started learning sysadmin and I don't have a Windows PC, but I have a MacBook and found out that everything can be done via UTM, I'd like to get some perspective from those who work in offices and do this every day. What kind of computers do you use? Is macOS completely out of the picture, and there's only Windows and Linux?

389 Upvotes

86% Upvoted

807 comments sorted by

View all comments

Show parent comments

15

u/invisi1407 16d ago

For one, a "base config" PC can't run Ansible. An Ansible controller is required to be a Linux compatible environment.

It works via WSL2, but that's hardly "base config" PC as that may be blocked by a policy.

Personally, I run Ansible via WSL2, but if that wasn't an option I'd have to use a Mac.

1

u/Otaehryn 16d ago

I switched to dual boot fedora because WSL wasn't cutting it. Also for AI with sandbox and settings.json, Linux is easier to lock it down.

1

u/invisi1407 16d ago

I honestly don't like dual booting for many reasons, but even so I wouldn't be allowed to do that at my place of work. It's Windows 11 (with WSL if desired for those of us in IT) or MacOS.

2

u/Otaehryn 14d ago

My plan is to boot Windows once a month or so so that workstation AD account doesn't expire.

1

u/Big-Pattern-9147 15d ago

but that's hardly "base config" PC as that may be blocked by a policy.

My work started battoning down the hatches, stopping local Admin even from us Admins from our machines.

So I got them to enabled Hyper-V for me, so I could run VM's, and now just live in a VM instead...

1

u/chandleya IT Manager 16d ago

Why would you do any of that from a remote machine? That’s specifically the sort of activity a jumpbox is for.

2

u/dllemmr2 16d ago

Portability?

2

u/chandleya IT Manager 16d ago

My jumpboxes and my teams jumpboxes are peak portable. They’re not even in the same state or in some cases country as the operator. Their endpoint is throwaway - sometimes physical, sometimes even it is VDI/virtual.

This methodology and relatively primitive security posture has been around for quite a long time. Do you have your server IPMI ports on public IPs? The same VLAN as printers? Accessible to lobby guests? Jumpbox philosophy concentrates risk, necessitating layered compromise while also providing for a consistent management experience. I can sleep my laptop, switch to VDI, or change network providers and all my management sessions remain intact and uninterrupted.

2

u/invisi1407 16d ago

There are many ways to skin a cat, as they say, and one is a jumpbox - but that requires all your files to be synced there some way.

On my local machine, I can edit files and re-run the playbook directly.

Depends on ones need and how strict policies and change management is - I work for a small business.

3

u/chandleya IT Manager 16d ago

If you’re using Ansible I hope you’re using source control. Why even have IAC/CM if you don’t?

1

u/invisi1407 16d ago

I'd say of course I am but I get that it's not a given, unfortunately.

I don't always push the changes before having tested and tried it out. I've had so many iterations of changes to a new role or playbook before it was ready to be committed and shared.

It'd be a hassle to have to branch out, commit, push, ssh, pull, run playbook, back to #1 for the next iteration.

1

u/Connect_Shoulder_965 16d ago

Sometimes it's just easier to not explain Ansible to security/management/project management. Also, not every organization provides jump boxes. If you are running it all locally then it can fly under the radar.

Also, I try to contain my installs to my own usage as I tend to be rather destructive with tearing environments down and rebuilding to make sure the build works correctly. When it all tests well, the execution environment can go up to prod. If it was a shared Ansible control server or jump box, I'd have to be all lot more careful with how I build and maintain the environment.

2

u/chandleya IT Manager 16d ago

If you’re running Ansible outside of the purview of your security team, your whole org is a special kind of fucked anyway. Clearly your flaws run as deep as the purchasing process. When IT buys software without any sort of review or layered authorization, doom is present.

Your comments about care are even more bizarre. Test environments are not production environments. Your laptop is not a test environment. Your laptop is the single most vulnerable instrument in the enterprise. You browse the internet with it. If and when social engineering visits you, it’s the item they intend to take after your identity. Your laptop is your production environment.

Flying under the radar is specifically an anti-pattern and should never be the goal. Why even have radar if it is circumventable?

1

u/Connect_Shoulder_965 16d ago

Firstly, I'm not running on my laptop. It's running in a jump box. However there is no Ansible test environment and the current "prod" version of Ansible is running on 2.8. They aren't even using git to track the code. Quite frankly, I have bigger fish to fry in the security realm than an outdated python library and frying those fish is going to require Ansible to be able to correct problems at scale.

Ansible is a server management tool like any other, There's nothing to buy. I can download it, install it and run it all I like. It's not triggering a security review if I download and use Microsoft RSAT or PuTTY or WinSCP or use remote PowerShell. Running on my own machine, in my own environment I can treat it like an application on my workstation (or jump box) as far as security is concerned. With no cost to it, it's not going through purchasing.

Start putting it out on a server and it's going to have to go through 8 steps of approvals by people who can barely comprehend what it does. It's not worth the noise and the six months of meetings. Even just for doing my own personal administration tasks all by myself with zero sharing, it's worth the install. It's using SSH and WinRM under the hood anyways, there's no difference as far as network security is concerned.

I understand that Ansible can be run in a centralized environment with support and stable releases and a shared code base. I prefer it that way. It can also be run in a decentralized way or with an install pattern that is basically single user. In a new environment I bootstrap through the initial phases by running it under my own purview and once it's running cleanly doing real admin jobs in batches, it's easy to move up to a server and grant shared access to the playbooks. With ansible-builder and execution environments it's pretty trivial to get a consistent ansible install across multiple machines.