Project

General

Profile

Actions

User story #10714

open

Use sharefile as basis for persistent files

Added by Janos Mattyasovszky over 7 years ago. Updated almost 7 years ago.

Status:
New
Priority:
N/A
Assignee:
-
Category:
Techniques
UX impact:
Suggestion strength:
Wish - This is just an idea | nice to have
User visibility:
Operational - other Techniques | Technique editor | Rudder settings
Effort required:
Name check:
Fix check:
Regression:

Description

Currently if I want to have "persistent" files (like ssh hostkeys), I mis-use the sharefile NCF method by sharing a file with ${g.uuid}, so basically myself.

I follow this logic to create "persistent SSH hostkeys":

[Start]
 ||
 \/                       Yes
 Does file exist locally? ================================\\ 
 ||                                                       ||
 \/ No                    Yes                             ||
 Is file shared with me?  ====> Retrieve remote file =====||
 ||                                                       ||
 \/ No                                                    \/
 Generate new file =====> Share file with myself  =====> [END]

This allows me to create "persistent" files, that are restored if a node gets reinstalled (with the same UUID of course).

It would come handy to have an NCF Method that behaves like this:

File persist

*file_path*: Full path to the file
*force_side*: local/remote
-> If it exists
    -> Is it the same as remote?
      -> If it is => kept
      -> If it is not
           -> if force_side=local -> Make sure it is shared with myself (overwrite what is remote) => kept
           -> if force_side=remote -> Retrieve file from remote (overwrite local) => repaired
-> If it does not exist:
    -> If it exists remote -> retrieve from policy_server => repaired
    -> If it does not exist remote => error

So you could write an NCF logic like this:

NCF Methods:
- file_persist: 
  path: /etc/ssh/ssh_host_ed25519_key
  force_side: remote

- command_execution: 
  command: ssh-keygen -f /etc/ssh/ssh_host_ed25519_key -q -C '' -N '' -t ed25519
  conditions: file_persist_error

(well, the ssh hostkey might not be the very best example, because it will be generated on first start of system, but take any kind of file as example)

Actions #1

Updated by Benoît PECCATTE over 7 years ago

Nice, I like the idea !

However, if after a fresh install the file exists, the persistent version will not be used.
Shouldn't you start with downloading the file first, of course you would need something to detect which one is the most recent, the remote or the local one.

Actions #2

Updated by Janos Mattyasovszky over 7 years ago

Hi,

Not if you think about this workflow:

-> If it exists
    -> Is it the same as remote?
      -> If it is => kept
      -> If it is not
           -> if force_side=local -> Make sure it is shared with myself (overwrite what is remote) => kept
           -> if force_side=remote -> Retrieve file from remote (overwrite local) => repaired

If it exists after installation, if would check if it's the same as the remote, and if not, force_side would define which one to update.

Actions #3

Updated by Janos Mattyasovszky over 7 years ago

And which one is "newer" is not always that what you want to be effectively there.

Like the ssh hostkeys. They are generated at the first time sshd starts, so there is a very good chance that it will be generated on a fresh system before rudder has the ability to download the proper one, and the new file will definetly be "fresher" than the one on the policy server, but not what I want. I want the file on the policy server (which is older) to overwrite the local file (which is newer) because the ssh pubkey is already stored on many other systems, so I want to restore it to the old known version.

Actions #4

Updated by Benoît PECCATTE almost 7 years ago

  • Target version set to Ideas (not version specific)
Actions

Also available in: Atom PDF