mirror of
				https://github.com/TheLocehiliosan/yadm
				synced 2025-06-13 13:03:58 +00:00 
			
		
		
		
	Regenerate yadm.md
This commit is contained in:
		
							parent
							
								
									8d1151a609
								
							
						
					
					
						commit
						8ff804c1a9
					
				
							
								
								
									
										86
									
								
								yadm.md
									
									
									
									
									
								
							
							
						
						
									
										86
									
								
								yadm.md
									
									
									
									
									
								
							| @ -257,12 +257,22 @@ | ||||
|        local.user | ||||
|               Override the USER for the purpose of symlinking alternate files. | ||||
| 
 | ||||
| ## HOOKS | ||||
|        yadm  has  the capability to execute scripts before or after any opera- | ||||
|        tion that yadm can perform. To utilize  this  functionality,  create  a | ||||
|        directory to store the hook scripts at $HOME/.yadm/hooks.  Then, create | ||||
|        scripts inside this directory for whatever operation you want  to  hook | ||||
|        into. For instance, if you'd like a script to run after yadm pull, your | ||||
|        hook    script    should    be    executable     and     located     at | ||||
|        $HOME/.yadm/hooks/post_pull.sh.   Any  of the yadm subcommands can uti- | ||||
|        lize this functionality. | ||||
| 
 | ||||
| ## ALTERNATES | ||||
|        When managing a set of files across different systems, it can be useful | ||||
|        to have an automated way of choosing an alternate version of a file for | ||||
|        a different operating system, host, or user.  yadm implements a feature | ||||
|        which will automatically create a symbolic link to the appropriate ver- | ||||
|        sion  of  a  file,  as long as you follow a specific naming convention. | ||||
|        sion of a file, as long as you follow  a  specific  naming  convention. | ||||
|        yadm can detect files with names ending in any of the following: | ||||
| 
 | ||||
|          ## | ||||
| @ -274,10 +284,10 @@ | ||||
|          ##OS.HOSTNAME | ||||
|          ##OS.HOSTNAME.USER | ||||
| 
 | ||||
|        If there are any files managed  by  yadm's  repository,  or  listed  in | ||||
|        If  there  are  any  files  managed  by yadm's repository, or listed in | ||||
|        $HOME/.yadm/encrypt, which match this naming convention, symbolic links | ||||
|        will be created for the most appropriate version.   This  may  best  be | ||||
|        demonstrated  by  example.  Assume  the  following files are managed by | ||||
|        will  be  created  for  the most appropriate version.  This may best be | ||||
|        demonstrated by example. Assume the  following  files  are  managed  by | ||||
|        yadm's repository: | ||||
| 
 | ||||
|          - $HOME/path/example.txt## | ||||
| @ -299,7 +309,7 @@ | ||||
| 
 | ||||
|        $HOME/path/example.txt -> $HOME/path/example.txt##Darwin | ||||
| 
 | ||||
|        Since the hostname doesn't match any of the  managed  files,  the  more | ||||
|        Since  the  hostname  doesn't  match any of the managed files, the more | ||||
|        generic version is chosen. | ||||
| 
 | ||||
|        If running on a Linux server named "host4", the link will be: | ||||
| @ -317,42 +327,42 @@ | ||||
|        If no "##" version exists and no files match the current CLASS/OS/HOST- | ||||
|        NAME/USER, then no link will be created. | ||||
| 
 | ||||
|        Links are also created for directories named this way, as long as  they | ||||
|        Links  are also created for directories named this way, as long as they | ||||
|        have at least one yadm managed file within them. | ||||
| 
 | ||||
|        CLASS  must  be manually set using yadm config local.class <class>.  OS | ||||
|        is determined by running uname -s, HOSTNAME by  running  hostname,  and | ||||
|        USER  by  running id -u -n.  yadm will automatically create these links | ||||
|        CLASS must be manually set using  yadm config local.class <class>.   OS | ||||
|        is  determined  by  running uname -s, HOSTNAME by running hostname, and | ||||
|        USER by running id -u -n.  yadm will automatically create  these  links | ||||
|        by default. This can be disabled using the yadm.auto-alt configuration. | ||||
|        Even if disabled, links can be manually created by running yadm alt. | ||||
| 
 | ||||
|        It  is possible to use "%" as a "wildcard" in place of CLASS, OS, HOST- | ||||
|        NAME, or USER. For example, The following file could be linked for  any | ||||
|        It is possible to use "%" as a "wildcard" in place of CLASS, OS,  HOST- | ||||
|        NAME,  or USER. For example, The following file could be linked for any | ||||
|        host when the user is "harvey". | ||||
| 
 | ||||
|        $HOME/path/example.txt##%.%.harvey | ||||
| 
 | ||||
|        CLASS  is  a special value which is stored locally on each host (inside | ||||
|        the local repository). To use alternate symlinks using CLASS, you  must | ||||
|        set  the  value  of class using the configuration local.class.  This is | ||||
|        CLASS is a special value which is stored locally on each  host  (inside | ||||
|        the  local repository). To use alternate symlinks using CLASS, you must | ||||
|        set the value of class using the configuration  local.class.   This  is | ||||
|        set like any other yadm configuration with the yadm config command. The | ||||
|        following sets the CLASS to be "Work". | ||||
| 
 | ||||
|          yadm config local.class Work | ||||
| 
 | ||||
|        Similarly,  the  values of OS, HOSTNAME, and USER can be manually over- | ||||
|        ridden using the configuration options  local.os,  local.hostname,  and | ||||
|        Similarly, the values of OS, HOSTNAME, and USER can be  manually  over- | ||||
|        ridden  using  the  configuration options local.os, local.hostname, and | ||||
|        local.user. | ||||
| 
 | ||||
| 
 | ||||
| ## JINJA | ||||
|        If  the  envtpl command is available, Jinja templates will also be pro- | ||||
|        If the envtpl command is available, Jinja templates will also  be  pro- | ||||
|        cessed to create or overwrite real files.  yadm will treat files ending | ||||
|        in | ||||
| 
 | ||||
|          ##yadm.j2 | ||||
| 
 | ||||
|        as  Jinja templates. During processing, the following variables are set | ||||
|        as Jinja templates. During processing, the following variables are  set | ||||
|        according to the rules explained in the ALTERNATES section: | ||||
| 
 | ||||
|          YADM_CLASS | ||||
| @ -368,7 +378,7 @@ | ||||
|          config=dev-whatever | ||||
|          {% endif -%} | ||||
| 
 | ||||
|        would output a file named whatever with the following  content  if  the | ||||
|        would  output  a  file named whatever with the following content if the | ||||
|        user is "harvey": | ||||
| 
 | ||||
|          config=work-Linux | ||||
| @ -381,44 +391,44 @@ | ||||
| 
 | ||||
| 
 | ||||
| ## ENCRYPTION | ||||
|        It  can  be  useful to manage confidential files, like SSH or GPG keys, | ||||
|        across multiple systems. However, doing so would put  plain  text  data | ||||
|        into  a  Git  repository, which often resides on a public system.  yadm | ||||
|        implements a feature which can make it easy to encrypt  and  decrypt  a | ||||
|        set  of  files  so  the  encrypted version can be maintained in the Git | ||||
|        repository.  This feature will only  work  if  the  gpg(1)  command  is | ||||
|        It can be useful to manage confidential files, like SSH  or  GPG  keys, | ||||
|        across  multiple  systems.  However, doing so would put plain text data | ||||
|        into a Git repository, which often resides on a  public  system.   yadm | ||||
|        implements  a  feature  which can make it easy to encrypt and decrypt a | ||||
|        set of files so the encrypted version can  be  maintained  in  the  Git | ||||
|        repository.   This  feature  will  only  work  if the gpg(1) command is | ||||
|        available. | ||||
| 
 | ||||
|        To  use  this  feature, a list of patterns must be created and saved as | ||||
|        $HOME/.yadm/encrypt.  This list of patterns should be relative  to  the | ||||
|        To use this feature, a list of patterns must be created  and  saved  as | ||||
|        $HOME/.yadm/encrypt.   This  list of patterns should be relative to the | ||||
|        configured work-tree (usually $HOME).  For example: | ||||
| 
 | ||||
|                   .ssh/*.key | ||||
|                   .gnupg/*.gpg | ||||
| 
 | ||||
|        The yadm encrypt command will find all files matching the patterns, and | ||||
|        prompt for a password. Once a  password  has  confirmed,  the  matching | ||||
|        files  will  be encrypted and saved as $HOME/.yadm/files.gpg.  The pat- | ||||
|        terns and files.gpg should be added to the yadm repository so they  are | ||||
|        prompt  for  a  password.  Once  a password has confirmed, the matching | ||||
|        files will be encrypted and saved as $HOME/.yadm/files.gpg.   The  pat- | ||||
|        terns  and files.gpg should be added to the yadm repository so they are | ||||
|        available across multiple systems. | ||||
| 
 | ||||
|        To decrypt these files later, or on another system run yadm decrypt and | ||||
|        provide the correct password.  After files are  decrypted,  permissions | ||||
|        provide  the  correct password.  After files are decrypted, permissions | ||||
|        are automatically updated as described in the PERMISSIONS section. | ||||
| 
 | ||||
|        Symmetric  encryption is used by default, but asymmetric encryption may | ||||
|        Symmetric encryption is used by default, but asymmetric encryption  may | ||||
|        be enabled using the yadm.gpg-recipient configuration. | ||||
| 
 | ||||
|        NOTE: It is recommended that you use a private repository when  keeping | ||||
|        NOTE:  It is recommended that you use a private repository when keeping | ||||
|        confidential files, even though they are encrypted. | ||||
| 
 | ||||
| ## PERMISSIONS | ||||
|        When  files  are checked out of a Git repository, their initial permis- | ||||
|        When files are checked out of a Git repository, their  initial  permis- | ||||
|        sions are dependent upon the user's umask. This can result in confiden- | ||||
|        tial files with lax permissions. | ||||
| 
 | ||||
|        To prevent this, yadm will automatically update the permissions of con- | ||||
|        fidential files.  The "group" and "others" permissions will be  removed | ||||
|        fidential  files.  The "group" and "others" permissions will be removed | ||||
|        from the following files: | ||||
| 
 | ||||
|        - $HOME/.yadm/files.gpg | ||||
| @ -430,13 +440,13 @@ | ||||
|        - The GPG directory and files, .gnupg/* | ||||
| 
 | ||||
|        yadm will automatically update permissions by default. This can be dis- | ||||
|        abled using the yadm.auto-perms configuration.  Even if disabled,  per- | ||||
|        abled  using the yadm.auto-perms configuration.  Even if disabled, per- | ||||
|        missions can be manually updated by running yadm perms.  The SSH direc- | ||||
|        tory processing can be disabled using the yadm.ssh-perms configuration. | ||||
| 
 | ||||
| ## FILES | ||||
|        The  following are the default paths yadm uses for its own data.  These | ||||
|        paths can be altered using universal options.  See the OPTIONS  section | ||||
|        The following are the default paths yadm uses for its own data.   These | ||||
|        paths  can be altered using universal options.  See the OPTIONS section | ||||
|        for details. | ||||
| 
 | ||||
|        $HOME/.yadm | ||||
|  | ||||
		Loading…
	
		Reference in New Issue
	
	Block a user