I’m part of a team who manage a number of openSUSE users (currently around 10 - but that is slowly increasing) on laptops, they’re all based locally (but that could change in the future) and when ever those users want new software installing we have to go over to their machine and approve the install as they do not have admin rights (dictate by our main client).
I’m looking for recommendations for software/services that we could us to manage the software that our users are allowed to install on their machines, so that new software can be confirmed as okay and the system will install it when it next checks in, or we can prompt the software to connect to the machine and install the software. Ideally a way to manage available repos and priority would be included in that.
By default those devices don’t allow ssh or remote desktop connections, but it’s possible to change that.
In house, for managing servers we use saltstack. In the past I have set up a spacewalk server to manage CentOS server installations.
I’m wondering what recommendations other users/admins would give for managing desktop machines.
I’m aware of SuSe Manager, and from what I have read it uses salt and spacewalk to manage machines, but I would assume that is a paid for service for those using SEL. If I am wrong, or there is a free version please let me know. Anyone with experience of SuSe manager and it’s use/usefulness in managing lap/desktop machines I would love to hear your thoughts!
I know I could probably set up salt states to manage these machines, and while that would probably be fine for the current admins, having something that is quite difficult to understand may make it harder to bring in new staff to help with that workload later.
I’ve only used spacewalk to admin CentOS servers, but I assume I could use it to manage openSUSE laptops in the same kind of way. Has anyone ever used it for this? Was it successful?
Others may answer differently,
To me, a preferred solution depends on the tastes and skill levels of your Admins.
When I look at these different solutions, I see the same basic parts which can even be implemented quickly and easily as “roll your own,” particularly because our zypper command is so much simpler and powerful compared to apt or yum.
You need to configure access to install sources, ie repositories.
Our “zypper ar” command avoids all the text file editing other distros require.
And, once a repo is added, you can fully manage from the command line thereafter.
You need to determine who decides what software to install, and perhaps updating policy.
Do you want Users to make the decision entirely on their own, or Administrators? You can grant Users permission to install using “sudo” or you can allow them access to scripts that have sufficient permissions.
This is a highly individualized decision. Personally, I tightly control Developer environments because it’s critical to ensuring consistent and successful builds. The same with Production deployments. For these scenarios, I typically take the time to create Build scripts that ensure that they are built the same way, every time and can be used any time I add a new Developer or Server, or replace. For ordinary Users, it’s not so necessary to “cookie cutter” so I’d probably opt for modifying sudo or just grant them root permissions (but retain the option to wipe their system and replace with a standard image). Of course, this decision also likely affects whatever your User or Employee Use Policy, your Backup and Recovery Policy and more. You will also likely want to run system inventory software to track what is installed and running on every machine.
Personally, I haven’t yet had to manage a situation that’s more than what I can script out, but if that happened I might consider Puppet or Chef, even Saltstack.
If you are a very large organization where you can’t keep track of what every employee is doing on every machine, you may want to deploy something that is more policy oriented and allow less independent User decisions. You may also want to run network auditing software to stay on top of what happens whether authorized or not.
As I described, the tools to “roll your own” are readily available in openSUSE, but of course if you run across something packaged that satisfies all your requirements I don’t see any reason not to implement.
Additional - Since you’re already at 10 Users/machines, depending on how much those machines are used on-site in your office, you should at least consider AD/LDAP for network security. If AD, there are various solutions that extend AD to support Linux machines beyond just Users (which is typically what you get when you add a Linux box to LDAP or AD. No machine management which is the other half of what AD can provide). Although extending AD to support Linux consistently without mistakes can be done without cost, it’s usually beyond the capability or ordinary mortals so I recommend the various community or commercial solutions instead. This might be especially useful if your Admins have Windows AD experience.
You could set up your own repos and only stock it with approved apps. But by nature an install normally requires root access and root does allow all actions. But root access can be done over the net via any number of remote controls apps. So that would eliminate the need to be physically at the machine. I believe that SuSe manager is proprietary and only comes with the enterprise versions.
Hi
I use SUSE Manager 3.0 (Not free, runs on SLES 12 SP1), it handles the openSUSE distribution [need to tweak the bootstrap script] (13.2, Leap 42.1, Tumbleweed only OBS repos [no repodata for oss/non-oss]). OBS and local http repos fine. I can also integrate with SUSE Studio to spin up vm images and deploy locally. Configuration file deployment etc all good to go.
But if you have used spacewalk, you should be able to integrate openSUSE, there are spacewalk client/server tools on OBS for openSUSE, integrate those into your CentOS system?