Ansible Agent Option?
-
@scottalanmiller said in Ansible Agent Option?:
@Obsolesce said in Ansible Agent Option?:
@scottalanmiller said in Ansible Agent Option?:
A simple test would be this.... if MDM is the right tool for your laptops, then it would also be the right tool for your servers.
Servers are not mobile devices.
Nor are desktops. They are all the same. Everything is somewhat mobile, nothing is totally stationary or totally mobile. They are just "computing devices". Needing to define their rate of mobility as a part of their ability to be managed would be a failure of any solution.
That's not the whole point. It's Device management versus configuration / state management.
-
@Obsolesce said in Ansible Agent Option?:
@scottalanmiller said in Ansible Agent Option?:
We want (and have with Salt), a single, uniform, enterprise, state based means of management.
Salt works, but it's not MDM.
@scottalanmiller said in Ansible Agent Option?:
@Obsolesce said in Ansible Agent Option?:
@scottalanmiller said in Ansible Agent Option?:
@Obsolesce said in Ansible Agent Option?:
@coliver said in Ansible Agent Option?:
@Obsolesce said in Ansible Agent Option?:
Why not have an Ansible server on the same network as the devices and reachable by the Ansible server?
From an MSP perspective that can get pretty inefficient and heavy.
Why is an MSP wanting to manage client user Windows mobile devices with Ansible? That doesn't make much sense and not really what it's for.
What is Ansible for if not managing your computers? It's what Salt is for.
MDM != configuration management
I want what Salt does... complete system management via State. There is a reason that state management is considered the future of system management.
Why do I want MDM if it doesn't do what we are looking for?
Maybe I don't know what you are looking for.
I think you want to manage devices, that can be mobile, with a configuration management tool, instead of a device management tool.
A single, uniform, state based, total system management platform. I want exactly the same things on servers, desktops, laptops, etc. Not one thing different between them as I need the same functionality universally, and using multiple tools to do the same task would be poor, at best.
-
@Obsolesce Just take MDM and SM out of the equation.
He wants FM
Fleet Management for everything a client has.
-
@Obsolesce said in Ansible Agent Option?:
@scottalanmiller said in Ansible Agent Option?:
@Obsolesce said in Ansible Agent Option?:
@scottalanmiller said in Ansible Agent Option?:
A simple test would be this.... if MDM is the right tool for your laptops, then it would also be the right tool for your servers.
Servers are not mobile devices.
Nor are desktops. They are all the same. Everything is somewhat mobile, nothing is totally stationary or totally mobile. They are just "computing devices". Needing to define their rate of mobility as a part of their ability to be managed would be a failure of any solution.
That's not the whole point. It's Device management versus configuration / state management.
Nope, the management is absolutely identical in every way. Not one iota different. Configuration / state management for all. No idea what this "device management" is except for a half-assed attempt at config / state management without really doing it.
-
@scottalanmiller said in Ansible Agent Option?:
@Obsolesce said in Ansible Agent Option?:
@scottalanmiller said in Ansible Agent Option?:
We want (and have with Salt), a single, uniform, enterprise, state based means of management.
Salt works, but it's not MDM.
@scottalanmiller said in Ansible Agent Option?:
@Obsolesce said in Ansible Agent Option?:
@scottalanmiller said in Ansible Agent Option?:
@Obsolesce said in Ansible Agent Option?:
@coliver said in Ansible Agent Option?:
@Obsolesce said in Ansible Agent Option?:
Why not have an Ansible server on the same network as the devices and reachable by the Ansible server?
From an MSP perspective that can get pretty inefficient and heavy.
Why is an MSP wanting to manage client user Windows mobile devices with Ansible? That doesn't make much sense and not really what it's for.
What is Ansible for if not managing your computers? It's what Salt is for.
MDM != configuration management
I want what Salt does... complete system management via State. There is a reason that state management is considered the future of system management.
Why do I want MDM if it doesn't do what we are looking for?
Maybe I don't know what you are looking for.
I think you want to manage devices, that can be mobile, with a configuration management tool, instead of a device management tool.
A single, uniform, state based, total system management platform. I want exactly the same things on servers, desktops, laptops, etc. Not one thing different between them as I need the same functionality universally, and using multiple tools to do the same task would be poor, at best.
Then what you do is put software on each device you want to manage, or find a tool that can magically find devices behind any random unknown NAT.
-
@Obsolesce said in Ansible Agent Option?:
@coliver said in Ansible Agent Option?:
@Obsolesce said in Ansible Agent Option?:
@scottalanmiller said in Ansible Agent Option?:
A simple test would be this.... if MDM is the right tool for your laptops, then it would also be the right tool for your servers.
Servers are not mobile devices.
Nor are Desktops but it would be nice to manage them with the same tool. Intune comes to mind it will do some state management and is getting better with time...
Intune only works because it's built to work that way. The operating systems and software that runs on them is built to work with intune so that the devices can be managed. Intune is (M)DM. Jamf is (M)DM. SaltStack, Ansible, etc is not device management. SaltStack has a big plus that it works well to manage devices due to the nature of agent based.
SaltStack and Ansible are basically the same. But Ansible lacks an agent so access is less secure and way more complicated. You can layer SDN onto Ansible to achieve it, ZeroTier for example, but that carries complexity and problems. The agent nature is so superior, by such a staggering degree. In theory you can build an Ansible agent, that shouldn't be that hard. The problem is that no one seems to have made and maintained one, it's just a theory that you could do, but beyond that, if someone made an agent it seems like it would be perfect.
-
@Obsolesce said in Ansible Agent Option?:
@scottalanmiller said in Ansible Agent Option?:
@Obsolesce said in Ansible Agent Option?:
@scottalanmiller said in Ansible Agent Option?:
We want (and have with Salt), a single, uniform, enterprise, state based means of management.
Salt works, but it's not MDM.
@scottalanmiller said in Ansible Agent Option?:
@Obsolesce said in Ansible Agent Option?:
@scottalanmiller said in Ansible Agent Option?:
@Obsolesce said in Ansible Agent Option?:
@coliver said in Ansible Agent Option?:
@Obsolesce said in Ansible Agent Option?:
Why not have an Ansible server on the same network as the devices and reachable by the Ansible server?
From an MSP perspective that can get pretty inefficient and heavy.
Why is an MSP wanting to manage client user Windows mobile devices with Ansible? That doesn't make much sense and not really what it's for.
What is Ansible for if not managing your computers? It's what Salt is for.
MDM != configuration management
I want what Salt does... complete system management via State. There is a reason that state management is considered the future of system management.
Why do I want MDM if it doesn't do what we are looking for?
Maybe I don't know what you are looking for.
I think you want to manage devices, that can be mobile, with a configuration management tool, instead of a device management tool.
A single, uniform, state based, total system management platform. I want exactly the same things on servers, desktops, laptops, etc. Not one thing different between them as I need the same functionality universally, and using multiple tools to do the same task would be poor, at best.
Then what you do is put software on each device you want to manage, or find a tool that can magically find devices behind any random unknown NAT.
Right, that's what I asked if anyone had one for Ansible. That's why I asked for exactly that.
-
@scottalanmiller said in Ansible Agent Option?:
Nope, the management is absolutely identical in every way. Not one iota different.
IF that was the case, then Ansible would just work like a real MDM or DM solution would. LIke Intune, Jamf, SCCM, mobileiron, even ESET, etc... anything with an agent basically. Ansible is not for managing mobile devices. A device i can consider mobile if it's not on the same LAN as the management server.
-
@Obsolesce said in Ansible Agent Option?:
@scottalanmiller said in Ansible Agent Option?:
Nope, the management is absolutely identical in every way. Not one iota different.
IF that was the case, then Ansible would just work like a real MDM or DM solution would. LIke Intune, Jamf, SCCM, mobileiron, even ESET, etc... anything with an agent basically. Ansible is not for managing mobile devices. A device i can consider mobile if it's not on the same LAN as the management server.
You are defining big concepts, like MDM and state management machines, by their use of an agent or not. That's not the same thing. The state machine world has both agent based, and agentless, and both options within it.
Using the limitations of a LAN as a way to define kinds of software is a very odd approach to taxonomy.
-
@DustinB3403 said in Ansible Agent Option?:
@Obsolesce Just take MDM and SM out of the equation.
He wants FM
Fleet Management for everything a client has.
Then one of the tools i mentioned here. Even LogMeIN would work. SaltStack is not a good way to do that either from an MSP perspective... there's no client management interface like you'd want for simple management, monitoring, etc...
-
Imagine if we redefined backups as different animals based on being pre-installed agent (StorageCraft) or injected agent (Veeam.) Same purpose, used in the same places, usually interchangeable, just how the agent gets there differs. It wouldn't make sense.
That's what we are dealing with here. One injects the agent at run time (Ansible), one leaves it there (Salt.) One is "call in", one is call out. But the actual fundamental tooling is essentially identical.
-
@Obsolesce said in Ansible Agent Option?:
@DustinB3403 said in Ansible Agent Option?:
@Obsolesce Just take MDM and SM out of the equation.
He wants FM
Fleet Management for everything a client has.
Then one of the tools i mentioned here. Even LogMeIN would work. SaltStack is not a good way to do that either from an MSP perspective... there's no client management interface like you'd want for simple management, monitoring, etc...
Why is Salt not ideal for an MSP? It's pretty ideal IMHO. Ansible would be better, likely, if it had an agent. But LogMeIn sure doesn't compete with Salt, not in the slightest. I literally know of nothing that competes with Salt.
-
@scottalanmiller said in Ansible Agent Option?:
@Obsolesce said in Ansible Agent Option?:
@scottalanmiller said in Ansible Agent Option?:
Nope, the management is absolutely identical in every way. Not one iota different.
IF that was the case, then Ansible would just work like a real MDM or DM solution would. LIke Intune, Jamf, SCCM, mobileiron, even ESET, etc... anything with an agent basically. Ansible is not for managing mobile devices. A device i can consider mobile if it's not on the same LAN as the management server.
You are defining big concepts, like MDM and state management machines, by their use of an agent or not. That's not the same thing. The state machine world has both agent based, and agentless, and both options within it.
Using the limitations of a LAN as a way to define kinds of software is a very odd approach to taxonomy.
You want a device management tool, not SaltStack/Ansible/Chef/Puppet/DSC.
-
@Obsolesce said in Ansible Agent Option?:
@scottalanmiller said in Ansible Agent Option?:
@Obsolesce said in Ansible Agent Option?:
@scottalanmiller said in Ansible Agent Option?:
Nope, the management is absolutely identical in every way. Not one iota different.
IF that was the case, then Ansible would just work like a real MDM or DM solution would. LIke Intune, Jamf, SCCM, mobileiron, even ESET, etc... anything with an agent basically. Ansible is not for managing mobile devices. A device i can consider mobile if it's not on the same LAN as the management server.
You are defining big concepts, like MDM and state management machines, by their use of an agent or not. That's not the same thing. The state machine world has both agent based, and agentless, and both options within it.
Using the limitations of a LAN as a way to define kinds of software is a very odd approach to taxonomy.
You want a device management tool, not SaltStack/Ansible/Chef/Puppet/DSC.
How is Salt not the definitive device management tool? In what way does LMI or something else compete for managing devices?
-
Salt will allow for essentially unlimited system management, with state which is absolutely critical, with monitoring and reporting, with LAN or without LAN, and doesn't need anything installed that can't be found in Chocolatey (not as good as needing nothing at all, but close.)
-
@scottalanmiller said in Ansible Agent Option?:
@Obsolesce said in Ansible Agent Option?:
@DustinB3403 said in Ansible Agent Option?:
@Obsolesce Just take MDM and SM out of the equation.
He wants FM
Fleet Management for everything a client has.
Then one of the tools i mentioned here. Even LogMeIN would work. SaltStack is not a good way to do that either from an MSP perspective... there's no client management interface like you'd want for simple management, monitoring, etc...
Why is Salt not ideal for an MSP? It's pretty ideal IMHO. Ansible would be better, likely, if it had an agent. But LogMeIn sure doesn't compete with Salt, not in the slightest. I literally know of nothing that competes with Salt.
I get that you want to use it to ensure for example 7-zip is on every device you want to manage. I understand you would do that with SS/Ansible/etc.... normally. But your situation is not the design intentions, even though a specific task you want to do is. I can't explain it much more than that. You're an MSP wanting to manage user and server devices of multiple clients (or tenants) or whatever I assume, and want to make sure there's a standard configuratino on all the devices? If that's the case the idea of using a config management tool like SaltStack or Ansible doesn't make sense because of former, but would with just the latter, but thats not the... I don't know how to say it. Some parts of that make sense, but not the top level view of what it actually is.
Just use SaltStack then, if you can't use Intune, Jamf, SCCM, etc. Note that all device management tools use an Agent, and the other stuff I'm talking about either does not, or it can, but that doesn't mean that's the purpose of what you want to do in a grand view.
SInce what you want to do is simple, and SS works, why not use it? That's what doesn't make sense.
-
When Ansible and SaltStack were initially designed, was everyone running out there with it for managing their companies Windows user devices... desktops and laptops? Making sure it has printers, and chocolatey, etc.? No.
-
@coliver said in Ansible Agent Option?:
@Obsolesce said in Ansible Agent Option?:
@scottalanmiller said in Ansible Agent Option?:
A simple test would be this.... if MDM is the right tool for your laptops, then it would also be the right tool for your servers.
Servers are not mobile devices.
Nor are Desktops but it would be nice to manage them with the same tool. Intune comes to mind it will do some state management and is getting better with time...
Nobody is managing servers with Intune. They are using SaltStack/Ansible/Chef/Puppet/DSC/SCCM for servers. NOT Intune. Also, Intune doesn't even support Server OSs.
-
@DustinB3403 said in Ansible Agent Option?:
@Obsolesce said in Ansible Agent Option?:
@DustinB3403 said in Ansible Agent Option?:
@Obsolesce said in Ansible Agent Option?:
@coliver said in Ansible Agent Option?:
@Obsolesce said in Ansible Agent Option?:
Why not have an Ansible server on the same network as the devices and reachable by the Ansible server?
From an MSP perspective that can get pretty inefficient and heavy.
Why is an MSP wanting to manage client user Windows devices with Ansible? That doesn't make much sense and not really what it's for.
Because they're being paid to manage them.
Then they should manage them with MDM software.
And which MDM would recommend?
How the hell do I recommend MDM software based solely on the fact he wants some unknown to me configuration on some unknown to me devices in unknown environments?
@scottalanmiller said in Ansible Agent Option?:
Salt will allow for essentially unlimited system management, with state which is absolutely critical, with monitoring and reporting, with LAN or without LAN, and doesn't need anything installed that can't be found in Chocolatey (not as good as needing nothing at all, but close.)
SO why are you not using SaltStack then? SaltStack and do ANYTHING to a Windows device. How? It can run PowerShell, and it can run scheduled tasks with any configuration. I can think of no case SaltStack wouldn't work for some configuration on a Windows device. SaltStack is like the only exception to the rule, so why not use it?
-
@scottalanmiller said in Ansible Agent Option?:
@Obsolesce said in Ansible Agent Option?:
@coliver said in Ansible Agent Option?:
@Obsolesce said in Ansible Agent Option?:
Why not have an Ansible server on the same network as the devices and reachable by the Ansible server?
From an MSP perspective that can get pretty inefficient and heavy.
Why is an MSP wanting to manage client user Windows mobile devices with Ansible? That doesn't make much sense and not really what it's for.
Even not an MSP, why would anyone want to use anything but state machines for managing their machines?
This kinda sounds like you wanna run DeepFreeze on all machines, except for a small area of the disk the users are allowed to write to. that does actually sound awesome - as long as you can prevent execution of programs from that space.
