This repository was archived by the owner on Sep 24, 2019. It is now read-only.
Add the ability to manage remote systems via ssh#67
Merged
lutter merged 32 commits intopuppetlabs-toy-chest:masterfrom Nov 8, 2017
Merged
Add the ability to manage remote systems via ssh#67lutter merged 32 commits intopuppetlabs-toy-chest:masterfrom
lutter merged 32 commits intopuppetlabs-toy-chest:masterfrom
Conversation
The target classes abstract how we interact with the system we are managing
It's now possible to just list what commands a provider requires to
indicate its suitability, something like
suitable:
commands:
- ls
- df
Since running a provider with ral_action=describe is slow, it's now possible to store its metadata in a separate YAML file. For a provider mine.prov, if mine.yaml exists, we just read that; if it's not there, we'll still run the describe action of the provider.
The addition of a reader and writer makes it possible to load and save the tree manually so that users of the tree can be unaware of where files come from (e.g., not the local system)
When creating an augeas handle for an ssh target, we manually read and write files through our ssh connection rather than trying to load htem from the local system.
When using search expressions like /files/etc/hosts/*[ipaddr= '127.0.0.1'] to specify a node, we can 'lose' the node if its ipaddr field changes. resolve() makes it possible to turn the path into something that does not involve any searches, e.g. /files/etc/hosts/1, addressing this problem
Otherwise, we fail to set properties on an existing mount because the base path contains a search that will not work after erasing its contents
We didn't check for missing mandatory entries before, and didn't pass all errors back up properly
We were uploading external commands every time we tried to determine if they are suitable - that defeats the purpose of external metadata.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This makes it possible to access a remote system that has nothing (or not very much) in terms of prerequisites on it. A prebuilt tarball is available that makes it possible to use these changes on a system. After downloading, unpack it somewhere and run
./ral/bin/ralsh; it will work on any glibc based Linux machine (e.g., CentOS 6 and 7). Seeralsh --helpfor usage information, especially the new--targetand--sudooptions.Remote access is purely through the ssh and scp command line tools, and makes heavy use of control sockets to reuse an existing session.
Requirements to use this:
which,rm,mv,chown,chmod,mktemp, andddon it (these could mostly be removed by usingsftpinstead ofscp)Providers are properly checked for suitability; notice how running
ralshandralsh -t somehostwill list different providers; several providers (file::posix,user::useradd, andgroup::groupadd) have not been adapted to remote use.External providers (scripts like
systemd.prov) are uploaded to the target system and run there, internal providers likehostandmountsimply retrieve files from the target and process them on the controller (and write them back to the remote) Such providers also run commands 'over the wire'; e.g., themountprovider will runmount/umountvia ssh. Also, thepackage::dnfprovider is broken right now and fails.The interface for dealing with a remote system is defined in target/base.hpp and the implementation of ssh access is in target/ssh.cc
One thing that makes this slow is that currently the provider lifecycle forces providers to eagerly load files they need to process. That part of the API needs to be improved to separate listing and interrogating provider metadata from full provider initialization. Even with that,
ralshis quite usable even with a system 40ms away.Making the remaining providers work:
userandgroupneed to stop using POSIX API's to access/etc/passwdand/etc/groupand instead use Augeas for that; other than that, they follow the same pattens ashostandmountfilerequires that the target API be expanded. Some aspects of file management (e.g., reading permissions) will require additional capabilities in that interface, some operations, like managing SELinux context, will always be hard.dnfprovider requires that we upload more than one file per provider as it is split across two filesssh_authorized_keyprovider is written in mruby; we can instrument mruby similar to what thetargetclasses do to make that work (or, of course, upload an mruby interpreter to the target)