Setting Up a GitLab Server on Synology and Tips for Deleting Files from a Remote Git Repository

Setting Up a GitLab Server on Synology and Tips for Deleting Files from a Remote Git Repository

Installing a GitLab Server on Synology and Configuring the Mail Server

With a Synology NAS, it is easy and fast to implement many functions that would normally require complex installation and configuration, such as quickly setting up a blog, website, audio, video, or photo services. For software development, another powerful use case is quickly building a Git server. Given Git’s importance in modern version control systems, being able to rapidly set up a full-featured Git server with both public and private repository support further highlights the value of Synology.

Synology’s official packages include two Git server options: Git Server and GitLab. Git Server is Synology’s native package, but after installation it can only be accessed and operated through the command line over SSH. This is inconvenient for users who are not familiar with Git commands or who prefer GitLab’s visual interface. In addition, due to Synology’s default administrative permission restrictions, only users with admin privileges in the Administration group can access the server via SSH. Granting too many team members Administration privileges introduces potential security risks, so Git Server seems better suited to individual developers at home who are comfortable with the Git command line and have full server control.

By contrast, GitLab provides a complete visual interface. If you are familiar with GitHub, GitLab will feel naturally familiar. Like GitHub, GitLab supports both SSH and HTTP access to software repositories, allowing users to manage their own repositories without requiring special server administration privileges. This makes the permission model both safer and more convenient.

GitLab on Synology is installed based on Docker. For Synology, the introduction of the Docker package makes the NAS feel almost all-powerful, thanks to Docker’s huge software ecosystem. As long as performance allows, Synology can run different Docker images, such as Ubuntu and other Linux distributions, or standalone services like PostgreSQL. Docker-based deployment prevents software from interfering with one another. In this sense, many Synology packages such as virtual machine management and database packages become less essential. As you become more familiar with Docker, you may find yourself increasingly preferring it for installing the functions you need.

Synology provides one-click installation for the GitLab package. Simply select GitLab in Package Center and install it, and the package will be downloaded and installed automatically. During installation, you need to set the database username and password, as well as external port mappings. By default, GitLab’s HTTP port 80 and SSH port 22 are mapped to Synology ports 30000 and 30001. If the server firewall is enabled, remember to open the corresponding ports for GitLab access. (Since SSH did not actually work in my case, I changed port 30001 to map to GitLab port 443 for HTTPS access.)

These settings can all be modified after installation. To enable GitLab to send email, you also need to configure your mail server information in advance. However, the default mail settings provided by the Synology package are incomplete, and additional environment variables must be added. So during GitLab installation, it is best not to start the service immediately after installation. (If it has already started, you need to stop the GitLab package first, modify the environment variables, and then start it again in order to enable email sending.)

Open Docker from Synology’s main menu, go to Container, select GitLab, and click Edit. (If GitLab is currently running, the edit function will be unavailable.) In the edit screen, you can see the environment variables and add the SMTP mail server variables needed for sending email. Port mappings can also be changed here. Below is an example using NetEase 126 Mail.

I was unable to get QQ Mail working, and only succeeded with 126 Mail, so that is the only example I can provide. Also note that both NetEase and QQ Mail have recently switched to an authorization-code login system. When using third-party clients, your normal mailbox password will not work. You must verify via phone and generate an authorization code, and the password you enter in GitLab’s environment variables should be that authorization code.

For variables not included in the default configuration, just add them manually:

• SMTP_ENABLED: true (Enable sending email via SMTP)
• SMTP_DOMAIN: smtp.126.com (SMTP domain)
• SMTP_HOST: smtp.126.com (SMTP server host)
• SMTP_PORT: 465 (SMTP server port; default is 587)
• SMTP_USER: your email address (SMTP username)
• SMTP_PASS: your email authorization code (SMTP password)
• SMTP_STARTTLS: true (Enable STARTTLS)
• SMTP_TLS: true (Enable SSL/TLS)
• SMTP_OPENSSL_VERIFY_MODE: none (SMTP OpenSSL verification mode; acceptable values are none, peer, client_once, and fail_if_no_peer_cert)
• SMTP_AUTHENTICATION: login (Specify the SMTP authentication method)

After installation is complete, start the GitLab service. Depending on your server’s performance, startup may take some time. While GitLab is starting, accessing its URL may return a 502 error, but in most cases this will resolve itself if you wait a bit.

On first login, you will see a screen to set the password for the default root user (administrator). After that, you can log in with this account to manage system settings, users, and more. If you want to change the email address in your personal profile, GitLab will require email confirmation, which is why the mail server configuration described above is necessary.

With these settings, GitLab should now work normally. If you are already familiar with GitHub, almost everything can be used in much the same way. Enjoy.

A Tip for Deleting Only Remote Repository Files in Git

When creating a new project in IDEs such as Visual Studio, PyCharm, or Eclipse, many project-related files are often generated automatically. The usual practice when initializing a Git repository is to first create a .gitignore file and list the files and file types that should not be included in version control, and then push the project to the remote repository.

However, if you overlook this at the beginning and accidentally push some unnecessary files to the remote repository, you may want to remove them from the server only. Since those files are still needed locally, you should not delete them locally and sync the deletion.

Use the following command in the Git command line to remove the files from the repository, then commit and push the change. This will delete the unnecessary files from the remote repository while keeping your local copies intact:

git rm -r --cached xxx.xxx

Be sure to pay attention to the --cached parameter. It removes files from the repository index only. Without this parameter, your local files would also be deleted, just like with a normal rm command. The -r option means recursive.

Then run:

git commit -m "your comments"
git push