In general, it is recommended that you install the service by starting it on a user's account. In this case, the initial GIT is usually configured from the account used.
It may be necessary to install services with the system account, for example, following user permission restrictions. In this case, if you want to configure GIT, you need to configure the system account manually (particularly if the use of SSH keys for connection is required to clone a remote Git repository).
This configuration must be completed before the Git repository is configured.
Prerequisites:
- GIT must be installed on the machine.
- For the system account configuration, Microsoft Sysinternals Suite tools must be installed on the machine (psexec).
- OpenSSL must be installed if you need to generate SSH keys.
Creating a command prompt in the system account
If you want to install services with the system account, you need to first create a command prompt run in the system account. To do this:
- run a command prompt (cmd.exe) as an administrator.
- enter the "psexec -i -s cmd.exe" command.
This operation opens a new command window in the system account. You can check it is running correctly by showing the content of the "USERPROFILE" environment variable. The value must be "C:\Windows\System32\config\systemprofile".
You can configure GIT for command line input in the usual way. All the configuration commands below need to be executed in this window. Once the configuration is complete, you can close the command window.
If the services need to be installed on the current user account, a normal command window is sufficient (no need to execute as an Administrator). ↑ Top of page
Basic GIT configuration
It is recommended that you configure a default value for the user's name and email address. Enter the following commands in the command window:
- git config --global user.name "Martin Dupont"
- git config --global user.email "martin.dupont@exemple.com"
It is also recommended that you globally disable cr/lf substitution by git*:
git config --global core.autocrlf false
This configuration (core.autocrlf false) is required at least for the project if the Git configuration is performed outside the source code repository installation wizard.
You also need to add the ".adelia" system directory to the ".gitignore" file. This is the directory containing the system data of the local service, it is not intended to be shared (several workstations could be connected and have their own configuration).
*The source code import and export tool can export text files using only the "lf" marker and not "crlf" as a line separator. In addition, the source code repository may potentially be installed on a non-Windows platform. Tools are based on the SHA-1 signature of files to identify changes. If Git changes the files according to the platform, to adapt line returns in Windows or Unix format, the calculation of this signature will be altered and the objects considered as modified despite the source being identical. ↑ Top of page
Adding an SSH key
You can use standard Git commands to generate an SSH key for authentication with a central repository. To do this, you can generate an SSH key using the "ssh-keygen" command.
You can also copy files to the "C:\Windows\System32\config\systemprofile\.ssh" directory from your user profile. You will find the generated public key in the "C:\Windows\System32\config\systemprofile\.ssh\id_rsa.pub" file. This key must be configured at central Git repository level to allow remote access.
Once the configuration is complete and the key has been added to the Git server, you can test the connection using the following command: "ssh -T username@git_server.com" (where git_server.com is the host name of your Git server and username is the name of your account on the server).
NB: If you use Windows explorer to copy files from the ".ssh" directory to the system account, you need to change the access permissions to the "C:\Windows\System32\config\systemprofile" directory to add it to your user account. The configuration files in the ".ssh" directory will be accessible in the system account itself, to the machine's administrators and the user who performed the action (who will be the owner of the files). In this case, you may have "Bad owner or permissions on <file_name>" errors.
These errors are due to the fact that SSH has a strict security strategy and checks that the files cannot be accessed by users other than their initial owner. You need to correct the authorisations file by file by changing the owner to "MACHINE\System" and deleting the access to the user account (leave the Administrators group in place though). You will perhaps need to delete inherited file permissions.