You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a enhancement proposal. I don't have code to back it up as I implemented a solution with Make already. However, it would be fantastic to have in rcm the support to deploy locally managed host-specific dotfiles to remote hosts. Or at least allow to "stage" or build host specific dotfiles to configurable HOME directories (which then could be copied to remote hosts).
In my case, I need different dotfiles on different remote hosts. I can't do a git checkout for each host (or cluster of hosts), there are too many and there are security concerns. I assumed I could bend rcm to achieve this. First I tried to set a fake hostname, say "cluster_a" and change the $HOME variable to a custom "output" directory, say: build/cluster_a. I also set the dotfiles source directory. Then I ran the rcm commands in that environment with always copy everything. I thought I have my doftiles built now an can just scp them to the remotes. Unfortunately that doesn't work, rcm always seems to want to work in the actual /home/username.
One thing I could think of this could look like is having a switch which triggers copying dotfiles to from-to-hosts (probably defaulting to localhost as source and rcrc-host host as target). And make the copy tool customizable (say: RCM_REMOTE_COPY_COMMAND="scp %{src_host}${src_file} %{dest_host}%{dest_file}"). Something like that, I'm not partial on how exactly it is realized.
Does this sound like something worthwhile to add?
The text was updated successfully, but these errors were encountered:
Sorry, struggling to follow this. Allow me to re-state what you said, and you tell me whether I got it?
The problem to solve is: many hosts, each with custom rc files, some with firewalls or connectivity that prevent git or other convenient rc file-sharing mechanisms.
A proposed solution is: populate the home directories for each host ahead of time on a local computer, and scp those homedirs into place.
Another proposed solution is: run rcm locally but have as its target a set of scp commands instead of mkdir/ln/cp.
Does that match what you're describing?
The solution where rcm knows about scp does not appeal to me.
The solution where you can specify an output directory that is not $HOME seems useful. I'd accept that patch.
Mike, you got it right. Sorry for the foggy initial post. I'll work on the customizable $HOME when I have the time and issue a pull request. It'll take a while though.
This is a enhancement proposal. I don't have code to back it up as I implemented a solution with Make already. However, it would be fantastic to have in rcm the support to deploy locally managed host-specific dotfiles to remote hosts. Or at least allow to "stage" or build host specific dotfiles to configurable HOME directories (which then could be copied to remote hosts).
In my case, I need different dotfiles on different remote hosts. I can't do a git checkout for each host (or cluster of hosts), there are too many and there are security concerns. I assumed I could bend rcm to achieve this. First I tried to set a fake hostname, say "cluster_a" and change the $HOME variable to a custom "output" directory, say: build/cluster_a. I also set the dotfiles source directory. Then I ran the rcm commands in that environment with always copy everything. I thought I have my doftiles built now an can just scp them to the remotes. Unfortunately that doesn't work, rcm always seems to want to work in the actual /home/username.
One thing I could think of this could look like is having a switch which triggers copying dotfiles to from-to-hosts (probably defaulting to localhost as source and rcrc-host host as target). And make the copy tool customizable (say: RCM_REMOTE_COPY_COMMAND="scp %{src_host}${src_file} %{dest_host}%{dest_file}"). Something like that, I'm not partial on how exactly it is realized.
Does this sound like something worthwhile to add?
The text was updated successfully, but these errors were encountered: