Opensource Git Server with Gitea

Clone and Push Source Code

To clone and push code to your self-hosted Gitea instance running on Kubernetes, you'll need to use the SSH service exposed by Gitea. Here's how to do it:

1. Setup SSH Access

First, ensure your SSH key is added to Gitea so that you can use it for Git operations (clone, push, etc.).

Steps to Add SSH Key in Gitea:

  1. Access the Gitea web interface at your custom domain.
  2. Log in to your Gitea account.
  3. Go to Settings > SSH Keys > Add Key.
  4. Paste your public SSH key in the provided field and save.

2. Clone a Repository

Once your SSH key is added, you can clone repositories using SSH.

git clone git@<domain>:username/repository.git

Replace username/repository.git with the actual repository path.

3. Push Code to the Repository

After cloning the repository, you can push your local changes to it.

1. Navigate to the cloned repository directory

cd repository

2. Make changes to your code and commit them:

git add .
git commit -m "Your commit message"

3. Push the changes to Gitea:

git push origin master

This will push your changes to the master branch (replace with the appropriate branch name if needed).

4. SSH Configuration (Optional)

If you want to avoid typing the full SSH URL every time, you can set up an SSH config file:

  1. Open or create the SSH config file:
nano ~/.ssh/config
  1. Add the following to it:
Host <domain>
  User git
  HostName <domain>
  Port 22
  IdentityFile ~/.ssh/id_rsa  # Path to your private key

Now you can clone and push using a shorter URL, like:

git clone git:username/repository.git

Accessing SSH via Kubernetes (if needed)

If you're accessing Gitea's SSH service through Kubernetes, ensure you're using the correct NodeIP and port, as exposed by the NodePort service:

Create Public SSH Key

  1. Open Git Bash
  2. Paste the text below, replacing the email used in the example with your GitHub email address.
ssh-keygen -t ed25519 -C "your_email@example.com"

If you are using a legacy system that doesn't support the Ed25519 algorithm, use:

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

This creates a new SSH key, using the provided email as a label.

When you're prompted to "Enter a file in which to save the key", you can press Enter to accept the default file location. Please note that if you created SSH keys previously, ssh-keygen may ask you to rewrite another key, in which case we recommend creating a custom-named SSH key. To do so, type the default file location and replace id_ALGORITHM with your custom key name.

  1. At the prompt, type a secure passphrase.
Generating public/private ed25519 key pair.
Enter file in which to save the key (/c/Users/<user>/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /c/Users/<user>/.ssh/id_ed25519
Your public key has been saved in /c/Users/<user>/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:<code> <email>
The key's randomart image is:
+--[ED25519 256]--+
|    ..+.. oo.    |
|     =E=  .o .   |
|    oo=o... o    |
|     ..Bo=.+ .   |
|      +.S.* +    |
|     . + * = .   |
|        o * +    |
|         +o= .   |
|        ..o++.   |
+----[SHA256]-----+

Error when Push Source Code

The error message

> git push origin main:main
error: RPC failed; HTTP 413 curl 22 The requested URL returned error: 413
send-pack: unexpected disconnect while reading sideband packet
fatal: the remote end hung up unexpectedly
Everything up-to-date

The error you're seeing is related to a Git push issue, where the data being pushed exceeds the allowed size for HTTP requests. Specifically, the HTTP 413 error indicates that the request is too large, and it can happen when pushing large commits or files.

Solution Steps

1. Increase Git HTTP Buffer Size

The most common fix is to increase the buffer size for Git's HTTP operations. You can do this by configuring Git with a larger buffer size on your local machine.

Run this command to increase the Git HTTP buffer size:

git config --global http.postBuffer 524288000  # 500MB

2. Configure Gitea to Allow Larger Pushes (Optional)

If increasing the buffer on your client doesn't work, you may need to adjust the settings in Gitea to allow larger pushes.

1. Edit the Gitea configuration (app.ini):

[server]
; Max size for HTTP upload, in MB
MAX_UPLOAD_SIZE = 1024

2. Restart Gitea to apply the configuration changes:

kubectl rollout restart deployment gitea -n git

3. Increase Kubernetes Resource Limits (Optional)

If your Gitea pod has limited CPU or memory, it might be throttling large requests. You can increase the resource limits for the Gitea pod in your Kubernetes deployment configuration.

For example, add resource limits in the deployment YAML:

resources:
  requests:
    memory: "512Mi"
    cpu: "500m"
  limits:
    memory: "2Gi"
    cpu: "1"

Apply the changes with:

kubectl apply -f gitea-deployment.yaml

4. Push in Smaller Batches

If the file you're pushing is very large, you can try pushing smaller commits or files in batches to avoid hitting the request size limit.

After Applying Changes

Directory Permission

The "Permission denied" error you're encountering indicates that the user running the Gitea service does not have sufficient permissions to create directories or files in the specified location (/data/gitea/log). This issue typically occurs due to incorrect file or directory permissions.

To resolve this issue, follow these steps:

Option 1: Adjust Directory Ownership and Permissions

  1. Check Current Ownership and Permissions: First, verify the current ownership and permissions of the /data/gitea directory and its subdirectories:

    ls -ld /data/gitea
ls -l /data/gitea/log

  2. Change Ownership to Gitea User: If Gitea is running under a specific user (e.g., gitea), change the ownership of the directory and its contents to this user:

    sudo chown -R gitea:gitea /data/gitea

  3. Adjust Permissions: Set appropriate permissions to allow the gitea user (or the user running Gitea) to read, write, and execute in the directories:

    sudo chmod -R 755 /data/gitea

  4. Retry Gitea Operations: Restart or retry the operation that caused the permission denied error in Gitea.

Option 2: Use ACLs (Access Control Lists)

If you need more granular permissions control, you can use ACLs to grant specific permissions to the Gitea user:

  1. Install ACL Package (if not already installed):

    sudo apt update
sudo apt install acl

  2. Set ACLs on the Directory:

    sudo setfacl -R -m u:gitea:rwx /data/gitea
sudo setfacl -d -R -m u:gitea:rwx /data/gitea

    This command grants read, write, and execute permissions recursively (-R) to the gitea user (u:gitea:rwx) on /data/gitea and sets the default ACL (-d) so that any new files or directories inherit these permissions.

  3. Verify ACLs: Check the ACLs to ensure they are correctly applied:

    getfacl /data/gitea

  4. Retry Gitea Operations: Restart or retry the operation that caused the permission denied error in Gitea.

Additional Considerations

By following these steps, you should be able to resolve the "Permission denied" issue for Gitea and allow it to create directories and files as required. Adjust the ownership, permissions, or ACLs according to your specific security and access requirements.

Create Dedicated User for Gitea

Benefits of Creating a Dedicated User and Group (gitea):

  1. Isolation: By creating a separate user and group (gitea), you isolate Gitea's files and processes from other system users and applications. This isolation enhances security by limiting access to Gitea-related resources only to the gitea user and group.

  2. Security: Assigning specific permissions to the gitea user and group allows you to control exactly what Gitea can access and modify on your system. This reduces the risk of unintended modifications or security breaches.

  3. Standardization: Using a dedicated user and group (gitea) for Gitea installations promotes consistency and standardization across different deployments. It simplifies management and troubleshooting, especially in environments with multiple applications and users.

  4. Compatibility: Many applications and services, including Gitea, are designed to run under a specific user and group for optimal compatibility and security configurations.

Steps to Create gitea User and Group:

Here’s how you can create the gitea user and group on your system:

1. Create the gitea Group:

sudo groupadd -r gitea

2. Create the gitea User:

sudo useradd -r -g gitea -d /var/lib/gitea -s /bin/bash gitea

3. Set Permissions:

Ensure that directories and files relevant to Gitea (e.g., /var/lib/gitea, /data/gitea, or specific paths you use) are owned by the gitea user and group (gitea:gitea). Adjust permissions as necessary to allow Gitea to read, write, and execute where required.

Example Usage in NFS Setup:

Conclusion:

Creating a dedicated user and group (gitea) specifically for Gitea installations enhances security, isolation, and compatibility with other services. It’s a recommended practice to follow when setting up applications like Gitea on your system, ensuring clear separation of privileges and streamlined management. Adjust configurations based on your specific deployment needs and security policies to achieve optimal performance and security for Gitea and other applications.

Deploying Gitea on Docker

Deploying Gitea on Docker involves setting up the Gitea application along with a database backend. Here’s a step-by-step guide to deploy Gitea using Docker Compose:

Step 1: Prepare Docker Compose File

Create a docker-compose.yml file to define the services (Gitea and MySQL in this case):

version: '3'

services:
  server:
    image: gitea/gitea:latest
    environment:
      - USER_UID=1000  # Replace with your host user UID if necessary
      - USER_GID=1000  # Replace with your host group GID if necessary
    restart: always
    volumes:
      - ./gitea:/data
    ports:
      - "3000:3000"
      - "2222:22"  # SSH port (optional, adjust as needed)
    depends_on:
      - db
    networks:
      - gitea_network

  db:
    image: mysql:5.7
    environment:
      MYSQL_DATABASE: gitea
      MYSQL_USER: gitea
      MYSQL_PASSWORD: password
      MYSQL_ROOT_PASSWORD: root_password
    volumes:
      - ./mysql:/var/lib/mysql
    restart: always
    networks:
      - gitea_network

networks:
  gitea_network:
    driver: bridge

Step 2: Configure Docker Compose File

Step 3: Deploy Gitea

Run the following command in the directory containing your docker-compose.yml file:

docker-compose up -d

This command starts both Gitea and MySQL containers in detached mode (-d), allowing them to run in the background.

Step 4: Access Gitea

After deployment, access Gitea through your browser at http://localhost:3000. Replace localhost with your server's IP address or domain name if accessing remotely.

Step 5: Initial Setup

Follow the on-screen instructions to complete the initial setup of Gitea, including setting up an admin account and configuring basic settings.

Notes:

This setup provides a basic deployment of Gitea using Docker Compose. Modify as per your environment and security requirements for production use.