Proposal: linux_admin sysvinit / systemd support

It occurs to me that the MiqLinux::InitProcs module and new Systemd module being written would best reside under the generic linux_admin gem which could be expanded to provide generic sysvinit & systemd detection (and possibly manipulation) for ruby code. Since Miq already pulls in linux_admin no new dependencies would need to be added and the web app could be simplified to call out to the linux_admin interface.


linux_admin is a GEM that performs Linux administration functions on live Linux machines and VMs (running on the OS of the machine). Fleecing runs outside the execution context of the VM in question, so this won’t work.

Hrm, the fleecing logic still runs as a ruby process correct? Why would it not be able to pull in a gem?

It’s not a question of being able to pull in the gem. The fleecing ruby process runs on the appliance, so linux_admin would perform its operations on the appliance, not the VM being fleeced.

Right but in essence the fleecing & underlying logic are “mounting” the vm. Not through the kernel mounting mechanisms, but via our own mechanism so that we can traverse the filesystem and such. With a little care and abstraction I’d think it’d be possible to extract the info from any mounted fs whether via kernel mount or via our memory mounted system with the added benefit that we can access this info from any ruby process (and more logic would be pulled out of the lib dir).


This is something I’ve been thinking about for some time, and I covered it to some extent in the presentation I made at the MIQ developer symposium. To address this properly in a general way is a fairly large effort. As such, I don’t think it should be addressed at this time, in the context of the systemd fix.

Another point is, this only works for solutions that are solely filesystem based. For many operations, linux_admin assumes it can execute native commands to perform operations. So, it may not be obvious which linux_admin operations can be performed in a VM’s context, and which cannot.

linux_admin’s purpose is to essentially be a wrapper around shelling out, so that CLIs can be accessed in a simpler, object oriented way. Additionally, linux_admin is used for parsing stdout from those CLIs to keep the parsing logic can live in one place.

To the purposes of your proposal, I can see linux_admin also being used to look at filesystem layout, and then extrapolating information from that. For example, I’ve thought about moving some of our lib/util/miq-system and lib/util/miq-process code into linux_admin, which wraps ps and also looks at /dev/proc , but as Rich said this requires executing in the running VM context.

If Rich’s virtual file system proposal were implemented, then we could execute against a non-running VM context, but only filesystem based pieces would work. However I think that proposal is some time away.

The only way I can see this working in the short term is if you made a method in linux_admin that accepted the filesystem content from an external source. linux_admin itself could leverage this method for the running VM context, and fleecing could use it after it retrieves the data.

I should clarify that I think my last paragraph is not the right way to do it. It is the only way I see it working, and as I think it’s not good, I think the whole proposal sort of breaks down.

Yes I was also thinking of some sort of abstraction where the underlying fs access mechanism wouldn’t matter to the service and other system related parsing logic. It’s fine that there’s other stuff tbd but still think this would be useful at some point, just a matter of time.

In any case what about a separate library besides linux_admin then? Again so that the reusable sysv and systemd logic could be extracted out of the lib dir, simplifying it and such.

I would just fix the bug for now, adhering to the current scheme. We’ll worry about refactoring and code reuse once we can address it more holistically.