# (Developers) how to handle OS variance/detection in modules -- BSDs, other Unixes, etc **URL:** \ **Category:** Ansible Project\ **Created:** [November 3, 2012, 11:02pm UTC](https://forum.ansible.com/t/developers-how-to-handle-os-variance-detection-in-modules-bsds-other-unixes-etc/12067 "2012-11-03T23:02:19Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![Michael\_DeHaan](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@Michael\_DeHaan](https://forum.ansible.com/u/Michael_DeHaan)\ **Post date:** [November 3, 2012, 11:02pm UTC](https://forum.ansible.com/t/developers-how-to-handle-os-variance-detection-in-modules-bsds-other-unixes-etc/12067/1 "2012-11-03T23:02:19Z")
Nigel sent in a nice patch to allow the service module to do some things different on BSD. This is very much based on how we do things in the setup module, but a little more simplified. I've adapted it further. This is the pattern we want to follow when adding better non-Linux support to various modules. Please test out the user module and let me know if there are any problems, as changes have been rather large. I would then perhaps suggest that if folks are intersted in assuring all of the modules are happy on the BSDs, Solarises, etc, we being making other modules start to follow this pattern when we know they will have OS variance. [https://github.com/ansible/ansible/blob/devel/library/user](https://github.com/ansible/ansible/blob/devel/library/user) --Michael ---
**Author:** ![Boyd\_Adamson](https://avatars.discourse-cdn.com/v4/letter/b/e36b37/32.png) [@Boyd\_Adamson](https://forum.ansible.com/u/Boyd_Adamson)\ **Post date:** [November 4, 2012, 9:34am UTC](https://forum.ansible.com/t/developers-how-to-handle-os-variance-detection-in-modules-bsds-other-unixes-etc/12067/2 "2012-11-04T09:34:45Z")
I’m in the position of having written a module for Solaris SMF services and SVR4 packages, both of which I was planning to send a pull request for this week. I had written entirely new modules for these for 2 reasons: 1. I had read somewhere, although I can’t remember where, that the philosophy of Ansible was that when there are different features (e.g. yum vs apt) that there should be different modules, avoiding the need to rely on a lowest common denominator. 2. Both of them have attributes that do not appear in the existing modules (e.g SMF services have properties that can be set on them, different for every service). It sounds from the below that I now need to think of a different approach. Is that true? More directly relevant to the immediate discussion is that in this new model, it’s not clear to me how to handle features that are present only in a single implementation. For example, at user creation time Solaris allows the assignment of RBAC profiles and auths, project membership, process privileges and resource controls among others. How would I implement these options in a generic user module? I may have missed something while reading the source on my phone screen, so feel free to point at an example. ---
**Author:** ![Michael\_DeHaan](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@Michael\_DeHaan](https://forum.ansible.com/u/Michael_DeHaan)\ **Post date:** [November 4, 2012, 2:06pm UTC](https://forum.ansible.com/t/developers-how-to-handle-os-variance-detection-in-modules-bsds-other-unixes-etc/12067/3 "2012-11-04T14:06:06Z")
> I'm in the position of having written a module for Solaris SMF > services and SVR4 packages, both of which I was planning to send a > pull request for this week. > > I had written entirely new modules for these for 2 reasons: > > 1) I had read somewhere, although I can't remember where, that the > philosophy of Ansible was that when there are different features (e.g. > yum vs apt) that there should be different modules, avoiding the need > to rely on a lowest common denominator. Yep, definitely true of packaging. We're trying to keep user and service together now though, and the service module I think is eventually going to be refactored to use the new way 'user' does OS detection, and that will clean it up some. The main reason I like packaging seperate is the package names are almost never the same between distros, and the idea that you can have an easy OS independent playbook for something involving a package is pretty unlikely. This just makes it evident what you are dealing with. I think this also ends up keeping the various packaging code a lot easier to sort through. > 2) Both of them have attributes that do not appear in the existing > modules (e.g SMF services have properties that can be set on them, > different for every service). There might be a way to just add a "properties" option to the service module in this case. Maybe you can share what you have on github so I could understand better? I'm not really a Solaris guy. > It sounds from the below that I now need to think of a different > approach. Is that true? > > More directly relevant to the immediate discussion is that in this new > model, it's not clear to me how to handle features that are present > only in a single implementation. For example, at user creation time > Solaris allows the assignment of RBAC profiles and auths, project > membership, process privileges and resource controls among others. How > would I implement these options in a generic user module? I may have > missed something while reading the source on my phone screen, so feel > free to point at an example. Basically in this case what we would do is make the module option available to \*all\* types of modules, and then it should probably raise an error if used in a class that didn't support it. We might also just name these parameters with a common prefix like "solaris\_" to make it clear they are only used there, if we are pretty sure they are not applicable to other operating systems in a similar way. But it would be really really nice if "user: name=timmy state=present" generally works on all platforms, for cases when people don't need to worry about those extra properties... if that's not the way it works, I'm ok with that. Let me know if you have further questions and so forth. That's just basically what I'm thinking at present. I would \*VERY\* much like to see our modules learn to be smarter about the other Unixes, so I'm quite excited by this. ---
**Author:** ![jpmens1](https://avatars.discourse-cdn.com/v4/letter/j/e9c0ed/32.png) [@jpmens1](https://forum.ansible.com/u/jpmens1)\ **Post date:** [November 4, 2012, 2:18pm UTC](https://forum.ansible.com/t/developers-how-to-handle-os-variance-detection-in-modules-bsds-other-unixes-etc/12067/4 "2012-11-04T14:18:49Z")
> I'm in the position of having written a module for Solaris SMF > services and SVR4 packages, both of which I was planning to send a > pull request for this week. Please do!         -JP ---
**Author:** ![Boyd\_Adamson](https://avatars.discourse-cdn.com/v4/letter/b/e36b37/32.png) [@Boyd\_Adamson](https://forum.ansible.com/u/Boyd_Adamson)\ **Post date:** [November 4, 2012, 11:14pm UTC](https://forum.ansible.com/t/developers-how-to-handle-os-variance-detection-in-modules-bsds-other-unixes-etc/12067/5 "2012-11-04T23:14:47Z")
> > I’m in the position of having written a module for Solaris SMF > > services and SVR4 packages, both of which I was planning to send a > > pull request for this week. > > > > I had written entirely new modules for these for 2 reasons: > > > > 1. I had read somewhere, although I can’t remember where, that the > > philosophy of Ansible was that when there are different features (e.g. > > yum vs apt) that there should be different modules, avoiding the need > > to rely on a lowest common denominator. > > Yep, definitely true of packaging. We’re trying to keep user and > service together now though, and the service > module I think is eventually going to be refactored to use the new way > ‘user’ does OS detection, and that will clean it > up some. > > The main reason I like packaging seperate is the package names are > almost never the same between distros, and the idea > that you can have an easy OS independent playbook for something > involving a package is pretty unlikely. This just > makes it evident what you are dealing with. > > I think this also ends up keeping the various packaging code a lot > easier to sort through. I agree. Just to add more fun, Solaris 11 introduced a new packaging system (IPS), while still supporting the old one. All the native packages have new-style names, while new-style packages exist with old-style names to ease transistion. So, yet another module to come for IPS. For those playing at home, my SVR4 (old-style) package module is at [https://github.com/brontitall/ansible/blob/svr4pkg/library/svr4pkg](https://github.com/brontitall/ansible/blob/svr4pkg/library/svr4pkg) > > 1. Both of them have attributes that do not appear in the existing > > modules (e.g SMF services have properties that can be set on them, > > different for every service). > > There might be a way to just add a “properties” option to the service > module in this case. Maybe you can share > what you have on github so I could understand better? > > I’m not really a Solaris guy. My SMF (service management facility) module is at [https://github.com/brontitall/ansible/blob/smf/library/smf](https://github.com/brontitall/ansible/blob/smf/library/smf) At the moment, I have it accept arbitrary key=value options and treat all those it doesn’t recognize as properties to set. They all have a propgroup/property style name, so perhaps that’s a toe-hold to make something more general. Further, I just realised that I currently have no support for setting options that are not already present, since creating them requires providing a data type (e.g. count:, astring:, etc). This is a rarer, but still needed, procedure. So I need to think of a way to support that operation. > > It sounds from the below that I now need to think of a different > > approach. Is that true? > > > > More directly relevant to the immediate discussion is that in this new > > model, it’s not clear to me how to handle features that are present > > only in a single implementation. For example, at user creation time > > Solaris allows the assignment of RBAC profiles and auths, project > > membership, process privileges and resource controls among others. How > > would I implement these options in a generic user module? I may have > > missed something while reading the source on my phone screen, so feel > > free to point at an example. > > Basically in this case what we would do is make the module option > available to _all_ types of modules, and then > it should probably raise an error if used in a class that didn’t support it. > > We might also just name these parameters with a common prefix like > “solaris\_” to make it clear they are only used > there, if we are pretty sure they are not applicable to other > operating systems in a similar way. > > But it would be really really nice if “user: name=timmy state=present” > generally works on all platforms, for cases > when people don’t need to worry about those extra properties… if > that’s not the way it works, I’m ok with that. As a data point, as far as I have tested, the basics of user creation already work on Solaris, since the most basic useradd command options are the same as on Linux. I haven’t tried every option though. ---
**Author:** ![Romeo\_Theriault](https://avatars.discourse-cdn.com/v4/letter/r/839c29/32.png) [@Romeo\_Theriault](https://forum.ansible.com/u/Romeo_Theriault)\ **Post date:** [November 5, 2012, 6:43am UTC](https://forum.ansible.com/t/developers-how-to-handle-os-variance-detection-in-modules-bsds-other-unixes-etc/12067/6 "2012-11-05T06:43:16Z")
> > \> I'm in the position of having written a module for Solaris SMF > > \> services and SVR4 packages, both of which I was planning to send a > > \> pull request for this week. Cool! I'm glad to see some action in ansible on solaris. > As a data point, as far as I have tested, the basics of user creation > already work on Solaris, since the most basic useradd command options are > the same as on Linux. I haven't tried every option though. I think the "biggest" thing missing is probably the password support. Solaris (as far as I know) has no good way to automate setting a password, short of editing the /etc/shadow file or automating the prompts at the passwd command. I believe there are some third-party tools out there that do it but they're not part of solaris. As far as I know all the other CM tools just edit /etc/shadow. ---
**Author:** ![Boyd\_Adamson](https://avatars.discourse-cdn.com/v4/letter/b/e36b37/32.png) [@Boyd\_Adamson](https://forum.ansible.com/u/Boyd_Adamson)\ **Post date:** [November 5, 2012, 7:22am UTC](https://forum.ansible.com/t/developers-how-to-handle-os-variance-detection-in-modules-bsds-other-unixes-etc/12067/7 "2012-11-05T07:22:38Z")
Ah, yes, you're right of course. This limitation of the OS means that CM tools bypass PAM for password setting, which is … suboptimal.