Recipes define subsystems that are distinct parts of larger systems. They are the basic units of setup in frycook. Generally a recipe corresponds to an os-level package that needs to be installed or configured.
The Recipe class is the base class for all recipes to subclass. It defines the framework for recipes and some helper functions. By itself it doesn’t do much.
It has a set of helper functions that are hooks called by frycooker to apply the recipe to a remote server:
handle_pre_apply_message()
handle_post_apply_message()
run_apply()
run_messages()
It has another set of helper functions used within recipes for copying files to remote servers:
get_local_file_perms()
push_file()
push_template()
push_package_file_set()
It has a final set of helper functions used within recipes for managing git repos on remote servers:
push_git_repo()
clone_git_repo()
update_git_repo()
is_git_repo()
ensure_git_repo()
Define the actions to take place when this recipe is applied to a computer. Override this function in your subclass of Recipe if you have any actions to apply. If you don’t have any actions, then why are you creating a recipe?
| Parameters: | computer (string) – name of computer to apply recipe to |
|---|
Clone a git repo on a remote server.
| Parameters: |
|
|---|
Make sure a git repo exists in the target path on the remote computer.
| Parameters: |
|
|---|---|
| Return type: | boolean |
| Returns: | True if repo already existed, False if not |
Get a string of the permissions set on a local file.
| Parameters: | local_name (string) – path to file on local file system |
|---|---|
| Return type: | string |
| Returns: | string containing perms of file, ie. ‘655’ |
Print the post-apply message for the user and wait for him/her to hit return before continuing.
Print the pre-apply message for the user and wait for him/her to hit return before continuing.
Make sure the target path exists on the remote computer and is really a git repo.
| Parameters: |
|
|---|---|
| Return type: | boolean |
| Returns: | True if repo already existed, False if not |
Define checks to run before applying the recipe. The base class checks that the designated computer exists in the environment dictionary. This is a good place to check other things in your environment dictionary that the apply function expects to be there. Override this function in your subclass of Recipe if you have any checks to perform. Raise a RecipeException if you encounter exceptional conditions. Be sure to call the base class function to make sure its checks get done as well.
| Parameters: | computer (string) – name of computer to apply recipe checks to |
|---|---|
| Raises RecipeException: | |
| raised if the computer name is not in the environment being processed | |
Copy a file to a remote server if the file is different or doesn’t exist.
| Parameters: |
|
|---|
Make a local clone of the repo in git_url into the temp directory specified in the settings file, then rsync it to the remote path.
| Parameters: |
|
|---|
Copy a set of files to a remote server, maintaining the same directory structure and processing any templates encountered. This copies the files to the root of the destination, so that things like /etc/hosts or /etc/nginx/nginx.conf get put in the right place.
First create a directory with the same name as package_name in your root packages directory. Then create a directory structure under that that mirrors the target machine and all files will get copied there in the correct place.
For template file processing, a default environment dictionary will be passed in consisting of:
{"computer": host_env["computers"][computer_name]}
Template files have a .tmplt extension.
If aux_env is given, it will be added to the default dictionary using dict.update() after the default dictionary is constructed. This means that if you pass in an aux_env dictionary with a key called “computer”, that that key will over-write the default key of that name.
If a file named fck_metadata.txt is encountered in a directory, then it’s expected to have contents of lines consisting of <path>:<owner>:<group>:<perms> that specifies the owner, group, and permissions for the path specified (directory-relative).
If a file named fck_delete.txt is encountered in a directory, then it’s expected to have contents of lines containing names of files to delete, one per line. This way you can clean out a directory as well as copy files to it.
| Parameters: |
|
|---|
Process a template file and push its contents to a remote server if it’s different than what’s already there.
| Parameters: |
|
|---|
A FileMetaDataTracker object keeps track of owner, group, and permissions for files and directories during a push_package_fileset operation. This hinges on a file named fck_metadata.txt being encountered in the directory being examined. This file should have each line contain the text <filename>:<owner>:<group>:<perms>, where <filename> is either a file name or ‘.’ for the directory itself, <owner> is the owner’s account name, <group> is the group’s name, and <perms> is the permissions string..
Read in the metadata for the given directory from the fck_metadata.txt file in the directory, or remember metadata from previous calls if no fck_metadata.txt file is encountered.
The input parameters are expected to be the values returned from a call to os.walk()
| Parameters: |
|
|---|
Lookup the owner, group, and permissions for the given path and filename from the metadata dictionary in this object. If no filename is specified, the data is retrieved for the directory specified in path.
| Parameters: |
|
|---|---|
| Return type: | tuple of strings |
| Returns: | tuple containing (<owner>, <group>, <perms>, ) |
A FileDeleter object deletes unwanted files from a directory on a remote server. This hinges on a file named fck_delete.txt being encountered in the directory being examined. This file should have each line contain the name of a file to be deleted.
Examine the given directory, check for a fck_delete.txt file in the directory, and if it exists delete all remote files named in it.
| Parameters: |
|
|---|