Dit-Dah.click – clickety-clack.click

overviewNGINXKeys - User Rights - SSH

DitDah Info

modify rules

 /etc/nginx/nginx.conf

Sites

cd /usr/share/nginx/html/localtransporter.space/

cd /usr/share/nginx/html/spiffydesign.com/

cd /usr/share/nginx/html/dit-dah.click

To hide the .env file using Nginx and prevent it from being served publicly, you can add a specific rule in your Nginx configuration that denies access to this file. Here's how to do it:

Step-by-step instructions:

Open your Nginx configuration file: You can either add this rule to your main Nginx configuration file (e.g., /etc/nginx/nginx.conf) or to the server block configuration for your site (e.g., /etc/nginx/conf.d/localtransporter.space.conf).

Example:
```
sudo nano /etc/nginx/conf.d/localtransporter.space.conf
```

Add the following rule to block access to the .env file: Insert this block inside your server block configuration:

server {
    # Other server settings...

    location ~ /\.env {
        deny all;
        return 404;
    }

    # Other location blocks...
}

Save and exit the file: After adding the rule, save and close the configuration file.
Test your Nginx configuration: Before restarting Nginx, you should test the configuration for syntax errors:
```
sudo nginx -t
```
If the syntax is correct, you will see a message like:
```
nginx: configuration file /etc/nginx/nginx.conf test is successful
```
Restart Nginx to apply the changes:
```
sudo systemctl restart nginx
```

How it works:

The location ~ /\.env block matches any requests for files that start with .env.
The deny all; directive denies access to the .env file.
The return 404; ensures that the server returns a "404 Not Found" response, making it appear as if the file doesn’t exist.

By following these steps, you ensure that your .env file will not be accessible through the browser, even if someone tries to access it directly.

Sending Files to Live (smp staging)

1. Use a Non-Root User with `sudo` Permissions

If you have another user (e.g., notroot or similar) that has sudo permissions, you can transfer files using scp as that user and then use sudo on the server to move the files to the target directory.

Steps:

Copy the Files to the Server: Use a non-root user (notroot or another user with sudo access):

scp -r /Users/spiffy/Documents/nsgandolf/dit-dah/nakedsword_stage-smp-dit-dah/build/* notroot@195.35.32.187:/home/notroot/

SSH into the Server: Log in as the non-root user:
```
ssh notroot@195.35.32.187
```
1. Use rsync for a Safer Move
rsync is a more robust tool for synchronizing directories. It can also ensure that only changed files are transferred and give you better control over file operations.

Here’s how you can use rsync to safely copy the files and overwrite the existing ones:
```
sudo rsync -av --delete /home/notroot/ /usr/share/nginx/html/dit-dah.click/
```
- -a: Archive mode (preserves permissions, timestamps, etc.).
- -v: Verbose (shows progress).
- --delete: Removes files from the destination that are no longer in the source, keeping the directories perfectly in sync.
This method is safer and more efficient when updating files.
1. Check Permissions: Make sure the nginx server has read permissions on the files:
```
sudo chown -R www-data:www-data /usr/share/nginx/html/dit-dah.click
sudo chmod -R 755 /usr/share/nginx/html/dit-dah.click
```

2. Enable `sudo` for Secure File Transfer

If you find yourself needing to frequently copy files as a non-root user and move them to directories that require root permissions, you could streamline this process by granting the user sudo access to move files:

Edit the sudoers file: Allow the non-root user to run commands as sudo without being prompted for a password (optional, for convenience):
```
sudo visudo
```
Add the following line (replace notroot with your actual username):
```
notroot ALL=(ALL) NOPASSWD: /bin/mv, /bin/chown, /bin/chmod
```

This will allow notroot to move and set permissions on files without needing to re-enter a password each time.

Summary:

Use a non-root user for scp: Upload files to a temporary location (e.g., /home/notroot).
Use sudo + rsync : Move the files to the web server directory using sudo.
Ensure Permissions: Set proper ownership and permissions on the destination files.

Other setting for gandolf

The project was built assuming it is hosted at the server root. You can control this with the homepage field in your package.json. For example, add this to build it for GitHub Pages:

"homepage" : "http://myname.github.io/myapp",

The build folder is ready to be deployed. You may serve it with a static server:

npm install -g serve serve -s build

Server Settings

Nginx

sudo nginx -t // test changes 
sudo systemctl restart nginx // apply changes

dit-dah.click.conf gitlab.conf localtransporter.space.conf php-fpm.conf

sudo nano /etc/nginx/conf.d/localtransporter.space.conf

/etc/nginx/conf.d/dit-dah.click.conf

# HTTP - Redirect all traffic to HTTPS
server {
    listen 80;
    server_name dit-dah.click www.dit-dah.click;

    location /.well-known/acme-challenge/ {
        allow all;
    }

    return 301 https://$host$request_uri;  # Redirect to HTTPS
}

# HTTPS - Serve the site over HTTPS
server {
    listen 443 ssl;
    server_name dit-dah.click www.dit-dah.click;

    ssl_certificate /etc/letsencrypt/live/dit-dah.click/fullchain.pem;  # SSL Certificate
    ssl_certificate_key /etc/letsencrypt/live/dit-dah.click/privkey.pem;  # SSL Key
    include /etc/letsencrypt/options-ssl-nginx.conf;  # SSL Options
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;

    root /usr/share/nginx/html/dit-dah.click;  # Define the document root
    index index.html;

    location / {
        try_files $uri /index.html;  # Support for React routing
    }

    # Block access to sensitive files and directories
    location ~ /\.git {
        deny all;
    }

    location ~ /\.env {
        deny all;
    }

    location ~* \.(bak|conf|ini|log)$ {
        deny all;
    }

    location ~ /\.(htaccess|htpasswd|git|svn) {
        deny all;
    }

    location ~* \.(swp|swo|bak|tmp|~)$ {
        deny all;
    }

    access_log /var/log/nginx/ditdah_access.log;
    error_log /var/log/nginx/ditdah_error.log;
}

spiffydesign / pages attempt v1

gitlab.rb

##! Define to enable GitLab Pages pages_external_url "https://pages.spiffydesign.com" gitlab_pages['enable'] = true gitlab_pages['external_http'] = ['127.0.0.1:8090'] gitlab_pages['external_https'] = ['127.0.0.1:8091'] gitlab_pages['root_cert'] = "/etc/letsencrypt/live/pages.spiffydesign.com/fullchain.pem" gitlab_pages['root_key'] = "/etc/letsencrypt/live/pages.spiffydesign.com/privkey.pem"

# GitLab frontend - spiffydesign.com
upstream gitlab-workhorse {
    server 127.0.0.1:8181 fail_timeout=0;
}

# GitLab Pages backend - pages.spiffydesign.com
upstream gitlab-pages {
    server 127.0.0.1:8090 fail_timeout=0;  # GitLab Pages running on port 8090
}

# Main GitLab instance at spiffydesign.com (HTTP to HTTPS redirect)
server {
    listen 80;
    server_name spiffydesign.com www.spiffydesign.com;

    location / {
        return 301 https://$host$request_uri;  # Redirect HTTP to HTTPS
    }
}

# Main GitLab instance at spiffydesign.com (HTTPS)
server {
    listen 443 ssl;
    server_name spiffydesign.com www.spiffydesign.com;

    ssl_certificate /etc/letsencrypt/live/spiffydesign.com/fullchain.pem;  # Correct SSL certificate for spiffydesign.com
    ssl_certificate_key /etc/letsencrypt/live/spiffydesign.com/privkey.pem;  # Correct key for spiffydesign.com
    include /etc/letsencrypt/options-ssl-nginx.conf;  # Let's Encrypt SSL options
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;

    location / {
        proxy_pass http://gitlab-workhorse;
        proxy_set_header Host $http_host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Frame-Options SAMEORIGIN;
        proxy_set_header X-Content-Type-Options nosniff;
    }

    access_log /var/log/nginx/gitlab_access.log;
    error_log /var/log/nginx/gitlab_error.log;

    # Block access to sensitive files and directories
    location ~ /\.git {
        deny all;
    }

    location ~ /\.env {
        deny all;
    }

    location ~* \.(bak|conf|ini|log)$ {
        deny all;
    }

    location ~ /\.(htaccess|htpasswd|git|svn) {
        deny all;
    }

    location ~* \.(swp|swo|bak|tmp|~)$ {
        deny all;
    }
}

# GitLab Pages at pages.spiffydesign.com (HTTP to HTTPS redirect)
server {
    listen 80;
    server_name pages.spiffydesign.com;

 location / {
	return 301 https://$host$request_uri;  # Redirect HTTP to HTTPS
    }

}

# GitLab Pages at pages.spiffydesign.com (HTTPS)
server {
    listen 443 ssl;
    server_name pages.spiffydesign.com;

    ssl_certificate  /etc/letsencrypt/live/pages.spiffydesign.com/fullchain.pem;  # standalone  certificate
    ssl_certificate_key /etc/letsencrypt/live/pages.spiffydesign.com/privkey.pem;  # standalone certificate
    include /etc/letsencrypt/options-ssl-nginx.conf;  # Let's Encrypt SSL options
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;

  location / {
	proxy_pass https://127.0.0.1:8091;  # Forward HTTPS traffic to GitLab Pages running on port 8091
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

    access_log /var/log/nginx/gitlabpages_access.log;
    error_log /var/log/nginx/gitlabpages_error.log;
}

simpler – but was showing content as default on all sites – and pages.spiffydesign.com was nly showing this

  GNU nano 5.6.1                                                                          dit-dah.click.conf
# React Frontend - dit-dah.click
server {
    listen 80;
    server_name dit-dah.click www.dit-dah.click;

    root /usr/share/nginx/html/dit-dah.click;
    index index.html;
    

    location / {
        try_files $uri /index.html; # Make sure this is here to support React routing
    }

    location /.well-known/acme-challenge/ {
        allow all;
    }

    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/dit-dah.click/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/dit-dah.click/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
    
       # Block access to sensitive files and directories
    location ~ /\.git {
        deny all;
    }

    location ~ /\.env {
        deny all;
    }

    location ~* \.(bak|conf|ini|log)$ {
        deny all;
    }

    location ~ /\.(htaccess|htpasswd|git|svn) {
        deny all;
    }

    location ~* \.(swp|swo|bak|tmp|~)$ {
        deny all;
    }

   access_log /var/log/nginx/gitlab_access.log;
    error_log /var/log/nginx/gitlab_error.log;

}

gitlab.conf – with pags – with SSL rerun

# GitLab Pages backend - pages.spiffydesign.com
upstream gitlab-pages {
    server 127.0.0.1:8090 fail_timeout=0;  # GitLab Pages running on port 8090
}

# Main GitLab instance at spiffydesign.com
server {
    if ($host = www.spiffydesign.com) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


    if ($host = spiffydesign.com) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


    listen 80;
    server_name spiffydesign.com www.spiffydesign.com;

    location / {
        return 301 https://$host$request_uri;  # Redirect HTTP to HTTPS
    }




}

server {
    listen 443 ssl;
    server_name spiffydesign.com www.spiffydesign.com;
    ssl_certificate /etc/letsencrypt/live/spiffydesign.com/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/spiffydesign.com/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

    location / {
        proxy_pass http://gitlab-workhorse;
        proxy_set_header Host $http_host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Frame-Options SAMEORIGIN;
        proxy_set_header X-Content-Type-Options nosniff;
    }

    access_log /var/log/nginx/gitlab_access.log;
    error_log /var/log/nginx/gitlab_error.log;

    # Block access to sensitive files and directories
    location ~ /\.git {
        deny all;
    }

    location ~ /\.env {
        deny all;
    }

    location ~* \.(bak|conf|ini|log)$ {
        deny all;
    }

    location ~ /\.(htaccess|htpasswd|git|svn) {
        deny all;
    }

    location ~* \.(swp|swo|bak|tmp|~)$ {
        deny all;
    }


}

# GitLab Pages at pages.spiffydesign.com
server {
    if ($host = pages.spiffydesign.com) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


    listen 80;
    server_name pages.spiffydesign.com;

    location / {
        return 301 https://$host$request_uri;  # Redirect HTTP to HTTPS
    }


}

server {
    listen 443 ssl;
    server_name pages.spiffydesign.com;
    ssl_certificate /etc/letsencrypt/live/spiffydesign.com/fullchain.pem; # managed by Certbot
  # Reuse SSL certificate
    ssl_certificate_key /etc/letsencrypt/live/spiffydesign.com/privkey.pem; # managed by Certbot
  # Reuse SSL certificate
    include /etc/letsencrypt/options-ssl-nginx.conf;  # Let's Encrypt SSL options
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;

    location / {
        proxy_pass http://gitlab-pages;  # Proxy to the GitLab Pages service running on port 8090
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

    access_log /var/log/nginx/pages_access.log;
    error_log /var/log/nginx/pages_error.log;

}

/etc/nginx/conf.d/gitlab.conf (spiffydesign.com – with pages)

# GitLab frontend - spiffydesign.com
upstream gitlab-workhorse {
    server 127.0.0.1:8181 fail_timeout=0;
}

# GitLab Pages backend - pages.spiffydesign.com
upstream gitlab-pages {
    server 127.0.0.1:8090 fail_timeout=0;  # GitLab Pages running on port 8090
}

# Main GitLab instance at spiffydesign.com
server {
    listen 80;
    server_name spiffydesign.com www.spiffydesign.com;

    location / {
        return 301 https://$host$request_uri;  # Redirect HTTP to HTTPS
    }
}

server {
    listen 443 ssl;
    server_name spiffydesign.com www.spiffydesign.com;

    ssl_certificate /etc/letsencrypt/live/spiffydesign.com/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/spiffydesign.com/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

    location / {
        proxy_pass http://gitlab-workhorse;
        proxy_set_header Host $http_host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Frame-Options SAMEORIGIN;
        proxy_set_header X-Content-Type-Options nosniff;
    }

    access_log /var/log/nginx/gitlab_access.log;
    error_log /var/log/nginx/gitlab_error.log;

    # Block access to sensitive files and directories
    location ~ /\.git {
        deny all;
    }

    location ~ /\.env {
        deny all;
    }

    location ~* \.(bak|conf|ini|log)$ {
        deny all;
    }

    location ~ /\.(htaccess|htpasswd|git|svn) {
        deny all;
    }

    location ~* \.(swp|swo|bak|tmp|~)$ {
        deny all;
    }
}

# GitLab Pages at pages.spiffydesign.com
server {
    listen 80;
    server_name pages.spiffydesign.com;

    location / {
        return 301 https://$host$request_uri;  # Redirect HTTP to HTTPS
    }
}

server {
    listen 443 ssl;
    server_name pages.spiffydesign.com;

    ssl_certificate /etc/letsencrypt/live/spiffydesign.com/fullchain.pem;  # Reuse SSL certificate
    ssl_certificate_key /etc/letsencrypt/live/spiffydesign.com/privkey.pem;  # Reuse SSL certificate
    include /etc/letsencrypt/options-ssl-nginx.conf;  # Let's Encrypt SSL options
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;

    location / {
        proxy_pass http://gitlab-pages;  # Proxy to the GitLab Pages service running on port 8090
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

    access_log /var/log/nginx/pages_access.log;
    error_log /var/log/nginx/pages_error.log;
}

/etc/nginx/conf.d/gitlab.conf (spiffydesign.com) – SIMPLE _ PRE PAGES


# GitLab frontend - spiffydesign.com
upstream gitlab-workhorse {
    server 127.0.0.1:8181 fail_timeout=0;
}

server {
    listen 80;
    server_name spiffydesign.com www.spiffydesign.com;

    location / {
        return 301 https://$host$request_uri;  # Redirect HTTP to HTTPS
    }
}

server {
    listen 443 ssl;
    server_name spiffydesign.com www.spiffydesign.com;

    ssl_certificate /etc/letsencrypt/live/spiffydesign.com/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/spiffydesign.com/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

    location / {
        proxy_pass http://gitlab-workhorse;
        proxy_set_header Host $http_host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Frame-Options SAMEORIGIN;
        proxy_set_header X-Content-Type-Options nosniff;
    }

    access_log /var/log/nginx/gitlab_access.log;
    error_log /var/log/nginx/gitlab_error.log;
    
   # Block access to sensitive files and directories
    location ~ /\.git {
        deny all;
    }

    location ~ /\.env {
        deny all;
    }

    location ~* \.(bak|conf|ini|log)$ {
        deny all;
    }

    location ~ /\.(htaccess|htpasswd|git|svn) {
        deny all;
    }

    location ~* \.(swp|swo|bak|tmp|~)$ {
        deny all;
    }

   access_log /var/log/nginx/gitlab_access.log;
    error_log /var/log/nginx/gitlab_error.log;
}

localtransporter.space

server {
    listen 80;
    server_name localtransporter.space www.localtransporter.space;

    root /usr/share/nginx/html/localtransporter.space;  # Adjust this to your build directory
    index index.html;

    location / {
        try_files $uri /index.html;
    }

    # SSL Configuration
    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/localtransporter.space/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/localtransporter.space/privkey.pem;
    include /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;

   # Block access to sensitive files and directories
    location ~ /\.git {
        deny all;
    }

    location ~ /\.env {
        deny all;
        return 404;
    }

    location ~* \.(bak|conf|ini|log)$ {
        deny all;
    }

    location ~ /\.(htaccess|htpasswd|git|svn) {
        deny all;
    }

    location ~* \.(swp|swo|bak|tmp|~)$ {
        deny all;
    }

   access_log /var/log/nginx/gitlab_access.log;
    error_log /var/log/nginx/gitlab_error.log;
}

test nginx (after changes)

sudo nginx -t

RESPONSE:
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

restart nginx (apply changes)

sudo systemctl restart nginx

OR

sudo nginx -s reload  // reload nginx

Gitlab

Config

sudo nano /etc/gitlab/gitlab.rb
// then run to reconfigure
sudo gitlab-ctl reconfigure

Basic Setup

It looks like you're diving into setting up a self-hosted GitLab instance. Based on your earlier context, you're planning to host GitLab on a subdomain (glab.dit-dah.click) and use it for managing your projects, including React and Laravel apps. You're also managing the server manually without a control panel, which gives you flexibility in setup.

Here’s a general guide to get your self-hosted GitLab instance running:

1. Set Up GitLab on AlmaLinux

Since you're using AlmaLinux, GitLab provides official installation instructions for RHEL-based distributions, which work for AlmaLinux.

Install the Dependencies:

sudo yum install -y curl policycoreutils openssh-server perl
sudo systemctl enable sshd
sudo systemctl start sshd
sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload

Install GitLab:

curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.rpm.sh | sudo bash
sudo EXTERNAL_URL="http://glab.dit-dah.click" yum install -y gitlab-ce

You’ll replace glab.dit-dah.click with your domain/subdomain.

Configure GitLab:

After installation, you can edit /etc/gitlab/gitlab.rb to tweak any configurations. For example, if you want to run GitLab over HTTPS:

sudo nano /etc/gitlab/gitlab.rb

Add or update:

external_url "https://glab.dit-dah.click"

Then reconfigure GitLab:

sudo gitlab-ctl reconfigure

2. SSL Setup (Optional)

If you want to use HTTPS, consider using Let's Encrypt for SSL certificates:

Modify the GitLab configuration:

external_url "https://glab.dit-dah.click"
letsencrypt['enable'] = true

Run the reconfiguration:

sudo gitlab-ctl reconfigure

3. Setting Up DNS

Make sure your DNS provider has an A record pointing glab.dit-dah.click to your server’s IP address.

4. User Management

You’ve already created admin users, but for a larger team, you can manage roles directly from the GitLab web interface, creating repositories, assigning permissions, and setting up continuous integration and deployment (CI/CD).

5. Backup & Restore (Optional)

You can also configure regular backups for your GitLab instance to avoid data loss:

sudo gitlab-rake gitlab:backup:create

Backups will be stored in /var/opt/gitlab/backups.

6. CI/CD Pipeline Setup

You can configure GitLab CI/CD pipelines using .gitlab-ci.yml in each of your projects. Here’s a basic example for a Laravel and React setup:

Laravel `.gitlab-ci.yml`:

stages:
  - install
  - test

install:
  stage: install
  script:
    - composer install

test:
  stage: test
  script:
    - ./vendor/bin/phpunit

React `.gitlab-ci.yml`:

stages:
  - build

build:
  stage: build
  script:
    - npm install
    - npm run build

7. Optimizing Performance

To improve performance, you can tweak memory settings or configure Redis and PostgreSQL for better efficiency, especially if your team and repository sizes grow.

Let me know if you need help with any specific configurations or further steps on this setup!

Error Logs

Here are the common CLI commands and paths to access error logs for various services on a typical Linux server:

1. NGINX Error Logs

To access NGINX error logs:

# View NGINX error log
sudo tail -f /var/log/nginx/error.log

# View NGINX access log
sudo tail -f /var/log/nginx/access.log

You can replace tail -f with just cat or less if you want to view the entire log:

sudo cat /var/log/nginx/error.log

If you have custom log paths defined in your NGINX configuration (as in your case for GitLab Pages), use those paths:

# For GitLab
sudo tail -f /var/log/nginx/gitlab_error.log

# For GitLab Pages
sudo tail -f /var/log/nginx/pages_error.log

2. GitLab Logs

GitLab logs are stored in the following directories:

GitLab general logs:

sudo gitlab-ctl tail

You can also specify which logs you want to view:

# GitLab Rails application logs
sudo gitlab-ctl tail gitlab-rails

# GitLab Workhorse logs
sudo gitlab-ctl tail gitlab-workhorse

# GitLab NGINX logs
sudo gitlab-ctl tail nginx

# GitLab Pages logs
sudo gitlab-ctl tail gitlab-pages

# GitLab Sidekiq logs
sudo gitlab-ctl tail sidekiq

3. DNS Logs

DNS logs vary depending on which DNS service you're using. If you're using BIND as your DNS server, check logs with:

# BIND DNS server logs (if applicable)
sudo tail -f /var/log/syslog | grep named

For systemd-resolved (which is common on newer Linux systems):

# DNS resolver logs via systemd
sudo journalctl -u systemd-resolved

For DNSMasq (if you're using it):

# DNSMasq logs
sudo tail -f /var/log/syslog | grep dnsmasq

4. PHP Error Logs

PHP logs can usually be found in the following locations, but it depends on your PHP configuration:

# PHP-FPM error logs (for PHP-FPM installations)
sudo tail -f /var/log/php7.4-fpm.log  # Replace with your PHP version

# PHP error log (for Apache or other setups)
sudo tail -f /var/log/php_errors.log

You can find the exact location of the PHP error log by checking the php.ini configuration file:

# Find the PHP error log location in php.ini
php -i | grep error_log

5. Database Error Logs

MySQL / MariaDB:

# For MariaDB or MySQL error logs
sudo tail -f /var/log/mysql/error.log  # Sometimes stored at /var/log/mysqld.log

PostgreSQL:

# PostgreSQL logs (assuming default location)
sudo tail -f /var/log/postgresql/postgresql-12-main.log  # Adjust the version and path if needed

Summary of Commands:

# NGINX error logs
sudo tail -f /var/log/nginx/error.log

# GitLab logs
sudo gitlab-ctl tail

# DNS logs (BIND)
sudo tail -f /var/log/syslog | grep named

# PHP logs
sudo tail -f /var/log/php_errors.log

# MySQL/MariaDB error logs
sudo tail -f /var/log/mysql/error.log

These commands will help you monitor logs and troubleshoot errors across the different services on your server. Let me know if you need more details for specific configurations!

pages.spiffydesign.com – ssl stuff

Your configuration is combining both spiffydesign.com and pages.spiffydesign.com in a single NGINX config file, which is fine. However, it’s important to make sure each domain is properly routed and that certificates are managed correctly for both.

Let's address your questions:

1. Should you break up the configuration into separate files?

While you can keep both spiffydesign.com and pages.spiffydesign.com in the same config file, it's not necessary to split them unless you want to organize the configurations separately. NGINX can handle multiple server blocks in a single file, but if it makes management easier for you, you can split them up into separate config files, each handling one domain.

For example, you could have:

/etc/nginx/sites-available/spiffydesign.conf
/etc/nginx/sites-available/pages.spiffydesign.conf

If you split them, make sure to symlink them to sites-enabled:

sudo ln -s /etc/nginx/sites-available/spiffydesign.conf /etc/nginx/sites-enabled/
sudo ln -s /etc/nginx/sites-available/pages.spiffydesign.conf /etc/nginx/sites-enabled/

Whether you keep them together or separate, they should function the same.

2. Why is there a `proxy_pass http://gitlab-pages` in the location block?

The proxy_pass http://gitlab-pages line is used to forward requests to the GitLab Pages service running on your server at port 8090.

In this block:

upstream gitlab-pages {
    server 127.0.0.1:8090 fail_timeout=0;  # GitLab Pages running on port 8090
}

server {
    listen 443 ssl;
    server_name pages.spiffydesign.com;

    ssl_certificate /etc/letsencrypt/live/spiffydesign.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/spiffydesign.com/privkey.pem;

    location / {
        proxy_pass http://gitlab-pages;  # Proxy to GitLab Pages running on 8090
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

The proxy_pass line tells NGINX to forward traffic for pages.spiffydesign.com to the GitLab Pages service listening on port 8090.

proxy_pass http://gitlab-pages;: Forwards requests to the internal service on port 8090.
proxy_set_header Host $host;: Ensures the original Host header is forwarded so that GitLab Pages knows the correct domain being requested.
proxy_set_header X-Forwarded-Proto $scheme;: Passes the protocol (HTTP/HTTPS) along to the backend service, which helps GitLab Pages understand whether the request was secure.

Issues you're experiencing:

SSL Error (ERR_CERT_COMMON_NAME_INVALID): This happens because the wrong SSL certificate is being presented (e.g., the certificate for spiffydesign.com is used instead of pages.spiffydesign.com).
- You're already reusing the same certificate for spiffydesign.com and pages.spiffydesign.com, which should be fine as long as both domains are included in the certificate.
- Check the certificate using:
```
sudo certbot certificates
```
  Ensure that both spiffydesign.com and pages.spiffydesign.com are listed in the certificate.
- If they’re not, you can re-issue the certificate with both domains:
```
sudo certbot --nginx -d spiffydesign.com -d pages.spiffydesign.com
```
Pages showing content from dit-dah.click: This could be because NGINX is defaulting to another server block (like dit-dah.click) if it doesn't find a matching server_name. Ensure all domains have their own server blocks and are properly separated.

Fixing the SSL certificate issue:

Verify the SSL certificates:
- Run sudo certbot certificates to see which domains are covered by your SSL certificates.
- If pages.spiffydesign.com is not included in the certificate, re-issue it with both domains:
```
sudo certbot --nginx -d spiffydesign.com -d pages.spiffydesign.com
```
Ensure proper server blocks for all domains:
- Make sure that each domain (spiffydesign.com, pages.spiffydesign.com, dit-dah.click) has its own dedicated server block with its own server_name and proper routing. This prevents NGINX from defaulting to another domain when one is misconfigured.

Test the configuration: After making changes, test the NGINX configuration:

sudo nginx -t  # Check for syntax errors
sudo systemctl reload nginx  # Reload NGINX if everything is correct

By ensuring your SSL certificates are correct and properly routing each domain in its own server block, the issues you're experiencing should be resolved. Let me know how it goes or if you need further assistance!

Firewalld

https://firewalld.org/

zone=public
public (active)
  target: default
  icmp-block-inversion: no
  interfaces: eth0
  sources:
  services: cockpit dhcpv6-client https ssh
  ports: 8181/tcp 80/tcp 443/tcp 443/udp 21/tcp 53/tcp 53/udp 22/tcp 110/tcp 143/tcp 993/tcp 995/tcp 40110/tcp 5050/tcp
  protocols:
  forward: yes
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

Updated

[root@spiffydesign conf.d]# sudo firewall-cmd --list-all --zone=public
public (active)
  target: default
  icmp-block-inversion: no
  interfaces: eth0
  sources:
  services: cockpit dhcpv6-client https ssh
  ports: 8181/tcp 80/tcp 443/tcp 443/udp 53/tcp 53/udp 22/tcp 110/tcp 143/tcp 993/tcp 995/tcp
  protocols:
  forward: no
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

Useful Commands

sudo firewall-cmd --list-all --zone=public
sudo firewall-cmd --remove-port=21/tcp --zone=public --permanent  # Remove FTP port if not needed
sudo firewall-cmd --add-port=21/tcp --zone=public --permanent  # Remove FTP port if not needed
sudo firewall-cmd --reload

firewalld rules are generally set by zone, which applies to the entire server or specific network interfaces rather than by individual URLs (domains).

• By default, your server’s public zone manages traffic for all network interfaces or IP addresses on the server.

• This means that all services (like HTTP, HTTPS, SSH) allowed in the public zone apply to all domains (e.g., dit-dah.click, localtransporter.space, spiffydesign.com) hosted on the same server, unless specific configurations are made for different zones or interfaces.

If you need more granular control, you could:

• Assign different network interfaces to different zones.

• Use firewalld rich rules to allow or block traffic based on IP addresses, ports, or protocols on a more specific level.

packet forwarding

Packet forwarding refers to the ability of a machine (in this case, your server) to forward network traffic from one network interface to another. It’s typically used in scenarios where the server acts as a router or gateway, meaning it receives traffic on one interface and forwards it to another.

For example:

• If your server has multiple network interfaces (e.g., eth0, eth2) and is connected to different networks, packet forwarding allows the server to pass traffic between these networks.

• If you use your server to route traffic between different subnets or networks, or if it’s configured as a gateway for other devices, packet forwarding is essential.

When to Disable Packet Forwarding:

• Single-NIC servers (common setup): If your server only has one network interface (e.g., eth0) and isn’t routing traffic between different networks, packet forwarding is unnecessary.

• Security: Enabling packet forwarding when it’s not needed can expose your server to additional risks, such as being used in a man-in-the-middle attack or facilitating traffic forwarding that you don’t intend.

TURNING IT OFF –

sudo firewall-cmd --zone=public --remove-forward --permanent
sudo firewall-cmd --reload

But by default, firewall rules in the public zone cover all traffic, including your multiple domains on the server.

Here are the basic commands for managing firewalld on your server:

1. Check the Status of firewalld:

sudo firewall-cmd --state

This will show if the firewall is running (running) or not.

2. Start/Stop/Restart firewalld:

Start:
```
sudo systemctl start firewalld
```
Stop:
```
sudo systemctl stop firewalld
```
Restart:
```
sudo systemctl restart firewalld
```

3. Enable/Disable firewalld to Start at Boot:

Enable:
```
sudo systemctl enable firewalld
```
Disable:
```
sudo systemctl disable firewalld
```

4. List All Active Zones and Rules:

sudo firewall-cmd --list-all

This shows the default zone and lists active services, ports, protocols, and rules.

5. Add/Remove/Allow Ports:

Allow a Port (Permanent):

sudo firewall-cmd --zone=public --add-port=8080/tcp --permanent

Remove a Port:

sudo firewall-cmd --zone=public --remove-port=8080/tcp --permanent

6. Add/Remove Services:

Add a Service (Permanent):

sudo firewall-cmd --zone=public --add-service=http --permanent

Remove a Service:

sudo firewall-cmd --zone=public --remove-service=http --permanent

7. Reload firewalld:

After making changes, you need to reload firewalld to apply the changes:

sudo firewall-cmd --reload

8. List Open Ports:

sudo firewall-cmd --list-ports

9. Check Zone Information:

View Default Zone:
```
sudo firewall-cmd --get-default-zone
```
List all Zones:
```
sudo firewall-cmd --get-zones
```

View Zone Settings:

sudo firewall-cmd --zone=public --list-all

10. Allow/Block IP Address:

Allow a specific IP:

sudo firewall-cmd --zone=public --add-rich-rule="rule family='ipv4' source address='192.168.1.100' accept" --permanent

Block a specific IP:

sudo firewall-cmd --zone=public --add-rich-rule="rule family='ipv4' source address='192.168.1.100' drop" --permanent

11. Check Firewall Rules:

sudo firewall-cmd --list-all --zone=public

These commands should cover most of the tasks you'll need to manage firewalld on your server.

Gitlab runner

For GitLab Runners, you can set up three types of runners depending on your needs:

Instance Runners: These runners are available to all projects and groups in your GitLab instance.
Group Runners: These are shared runners across all projects within a specific group.
Project Runners: These are runners specifically assigned to a single project.

Here’s how you can register GitLab runners:

1. Registering an Instance Runner (for all projects)

As an administrator, you can set up an instance runner that will be available to all projects within your self-hosted GitLab instance.

Install the GitLab Runner: On your server (or another server that will act as the runner), install the GitLab Runner:

curl -L --output /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64
sudo chmod +x /usr/local/bin/gitlab-runner
sudo useradd --comment 'GitLab Runner' --create-home gitlab-runner --shell /bin/bash
sudo /usr/local/bin/gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runner
sudo /usr/local/bin/gitlab-runner register
sudo /usr/local/bin/gitlab-runner start

Get the registration token:
- Go to your GitLab Admin Area (spiffydesign.com/admin/runners).
- Copy the Instance Runner registration token.
Register the runner:
```
sudo gitlab-runner register
```
- GitLab URL: https://spiffydesign.com/
- Token: Paste the instance runner token from step 2.
- Description: Add a description for the runner (e.g., "General Instance Runner").
- Tags: Add tags to help identify which jobs this runner should pick up.
- Executor: Choose an executor (e.g., shell, docker, etc.). Docker is commonly used for isolation.

Once registered, this runner will be available for all projects in the instance.

2. Registering a Project Runner (for a specific project)

Go to your project settings:
- Navigate to your project in GitLab, then go to Settings > CI/CD > Runners.
- Under Project Runners, you’ll see a button to get a registration token for that specific project.
Install and register the runner: The process is the same as the instance runner:
```
sudo gitlab-runner register
```
- GitLab URL: https://spiffydesign.com/
- Token: Use the project-specific registration token.
- Executor: Choose the executor as per your requirement.

The runner will only be available for that specific project.

3. Assigning Runners to Groups

If you want to set up Group Runners, you'll need to create a group first and assign the runner to that group. This allows all projects in the group to share the runner.

To create a Group Runner, follow the same process as registering an instance runner, but get the registration token from the Group Settings page instead.

4. Verify Runner Registration

Once the runner is registered, you can verify it in your GitLab interface:

Go to the project or admin area where you registered the runner.
Check if the runner appears in the Runners section and if it's marked as online.

Let me know if you need further details on setting up specific executors like Docker or troubleshooting issues with your runners!

Full complete backup

sudo tar -czvf /home/backup/full_server_backup_$(date +%Y%m%d).tar.gz /etc/nginx /var/www /home /etc/letsencrypt /etc/systemd/system /etc/ssh /etc/gitlab /opt/gitlab

GITLAB

sudo gitlab-backup create

The backup file will be saved in /var/opt/gitlab/backups/ by default. You can copy this file to your backup directory:

sudo cp /var/opt/gitlab/backups/* /home/backup/

NGINX

sudo tar -czvf /home/backup/nginx_conf_backup_$(date +%Y%m%d).tar.gz /etc/nginx

SSL

sudo tar -czvf /home/backup/ssl_certificates_backup_$(date +%Y%m%d).tar.gz /etc/letsencrypt

GRAB IT

scp root@195.35.32.187:/home/backup/full_server_backup_20240922.tar.gz /Users/spiffy/Desktop/somefolder/

To create a full backup of the entire server, including all websites (spiffydesign.com, dit-dah.click, localtransporter.space), GitLab, and all configuration files, you'll need to back up the following:

Files & Directories: For each website's files and application data (e.g., HTML, CSS, JS, config files).
Databases: Any MySQL, MariaDB, or PostgreSQL databases.
GitLab Backup: GitLab repositories, configuration, and data.
Nginx/Apache configuration: Your web server configurations.
SSL Certificates: Any SSL certificates and their private keys.
System Configuration: Any OS-level configurations, such as firewall rules, crontab jobs, and environment variables.

Here’s a step-by-step guide to creating a complete backup of your server:

1. Backup Files & Directories

You’ll need to back up the entire /var/www/ directory (or wherever your web files are located) along with other key directories, such as configuration files.

sudo tar -czvf /backup/full_server_backup_$(date +%Y%m%d).tar.gz /etc/nginx /etc/apache2 /var/www /home /etc/letsencrypt /etc/systemd/system /etc/ssh /etc/gitlab /opt/gitlab

This will create a .tar.gz archive of critical directories and configurations:

/etc/nginx or /etc/apache2: Nginx or Apache configuration files.
/var/www: Web application files.
/home: Any user-specific files or projects.
/etc/letsencrypt: SSL certificates and keys.
/etc/systemd/system: System services configuration.
/etc/ssh: SSH configuration (important for server access).
/etc/gitlab and /opt/gitlab: GitLab configuration and installation files.

Make sure to adjust the paths based on your system's configuration.

2. Backup Databases

For MySQL/MariaDB:

To back up MySQL or MariaDB databases:

mysqldump -u root -p --all-databases > /backup/mysql_backup_$(date +%Y%m%d).sql

For PostgreSQL (if used by GitLab or other applications):

sudo -u postgres pg_dumpall > /backup/postgresql_backup_$(date +%Y%m%d).sql

This will create SQL dump files that you can later restore.

3. GitLab Backup

GitLab provides a built-in command to create a backup of repositories, uploads, and GitLab settings:

sudo gitlab-backup create

The backup file will be saved in /var/opt/gitlab/backups/ by default. You can copy this file to your backup directory:

sudo cp /var/opt/gitlab/backups/* /backup/

Additionally, you should back up the GitLab secrets (important for encryption keys, etc.):

sudo cp /etc/gitlab/gitlab-secrets.json /backup/

4. Backup Web Server Configurations

Back up Nginx or Apache configurations. You may have done this already if you included /etc/nginx or /etc/apache2 in the tarball.

For Nginx:

sudo tar -czvf /backup/nginx_conf_backup_$(date +%Y%m%d).tar.gz /etc/nginx

For Apache:

sudo tar -czvf /backup/apache_conf_backup_$(date +%Y%m%d).tar.gz /etc/apache2

5. Backup SSL Certificates

Your SSL certificates (from Let's Encrypt or other sources) should also be backed up. Usually, they are located in /etc/letsencrypt if using Let's Encrypt:

sudo tar -czvf /backup/ssl_certificates_backup_$(date +%Y%m%d).tar.gz /etc/letsencrypt

6. Backup System Configuration (Optional)

If you’ve customized other parts of your system (such as firewall rules, crontab entries, or environment variables), it’s a good idea to back them up as well.

Backup crontab:

sudo crontab -l > /backup/root_crontab_backup_$(date +%Y%m%d).txt

Backup Firewall rules:

For iptables:

sudo iptables-save > /backup/firewall_backup_$(date +%Y%m%d).conf

7. Automate Backups (Optional)

You can automate this process using a cron job:

sudo crontab -e

Add the following line to schedule a daily backup at 2 AM:

0 2 * * * /path/to/backup_script.sh

Make sure to write your backup script with all the commands mentioned above.

8. Backup Storage

Make sure to store your backup files on an external drive or cloud storage to prevent data loss if your server fails. You can use rsync or scp to copy the backup files to another location.

Example with rsync:

rsync -avz /backup/ user@remote-server:/remote-backup/

9. Restore Backup (In Case of Failure)

To restore the backup, you’ll need to reverse the process:

Extract the tarball to the correct locations.
Restore the databases using mysql or psql.
Restore GitLab using its restore command: gitlab-backup restore.
Reconfigure Nginx or Apache and SSL certificates.

This process will give you a complete backup of your server, including the websites, databases, GitLab instance, and all necessary configuration files.

NGINX settings

DETAILS: Tier: Free, Premium, Ultimate Offering: Self-managed

This page provides configuration information for administrators and DevOps engineers configuring NGINX for GitLab installations. It includes essential instructions for optimizing performance and security specific to bundled NGINX (Linux package), Helm charts, or custom setups.

Service-specific NGINX settings

To configure NGINX settings for different services, edit the gitlab.rb file.

WARNING: Incorrect or incompatible configuration might cause the service to become unavailable.

Use nginx['<setting>'] keys to configure settings for the GitLab Rails application. GitLab provides similar keys for other services like pages_nginx, mattermost_nginx, and registry_nginx. Configurations for nginx are also available for these <service_nginx> settings, and share the same default values as GitLab NGINX.

To operate NGINX for isolated services like Mattermost, use gitlab_rails['enable'] = false instead of nginx['enable'] = false. For more information, see Running GitLab Mattermost on its own server.

When you modify the gitlab.rb file, configure NGINX settings for each service separately. Settings specified using nginx['foo'] are not replicated to service-specific NGINX configurations (such as registry_nginx['foo'] or mattermost_nginx['foo']). For example, to configure HTTP to HTTPS redirection for GitLab, Mattermost and Registry, add the following settings to gitlab.rb:

nginx['redirect_http_to_https'] = true
registry_nginx['redirect_http_to_https'] = true
mattermost_nginx['redirect_http_to_https'] = true

Enable HTTPS

By default, Linux package installations do not use HTTPS. To enable HTTPS for gitlab.example.com:

If you use a proxy, load balancer, or other external device to terminate SSL for the GitLab host name, see External, proxy, and load balancer SSL termination.

Change the default proxy headers

By default, when you specify external_url, a Linux package installation sets NGINX proxy headers that are suitable for most environments.

For example, if you specify the https schema in the external_url, a Linux package installation sets:

"X-Forwarded-Proto" => "https",
"X-Forwarded-Ssl" => "on"

If your GitLab instance is in a more complex setup, such as behind a reverse proxy, you might need to adjust the proxy headers to avoid errors like:

The change you wanted was rejected
Can't verify CSRF token authenticity Completed 422 Unprocessable

To override the default headers:

Edit /etc/gitlab/gitlab.rb:

nginx['proxy_set_headers'] = {
  "X-Forwarded-Proto" => "http",
  "CUSTOM_HEADER" => "VALUE"
}

Save the file and reconfigure GitLab for the changes to take effect.

You can specify any header supported by NGINX.

Configure GitLab trusted proxies and NGINX `real_ip` module

By default, NGINX and GitLab log the IP address of the connected client.

If GitLab is behind a reverse proxy, you might not want the IP address of the proxy to show as the client address.

To configure NGINX to use a different address, add your reverse proxy to the real_ip_trusted_addresses list:

# Each address is added to the NGINX config as 'set_real_ip_from <address>;'
nginx['real_ip_trusted_addresses'] = [ '192.168.1.0/24', '192.168.2.1', '2001:0db8::/32' ]
# Other real_ip config options
nginx['real_ip_header'] = 'X-Forwarded-For'
nginx['real_ip_recursive'] = 'on'

For a description of these options, see the NGINX realip module documentation.

By default, Linux package installations use the IP addresses in real_ip_trusted_addresses as GitLab trusted proxies. The trusted proxy configuration prevents users from being listed as signed in from those IP addresses.

Save the file and reconfigure GitLab for the changes to take effect.

Configure the PROXY protocol

To use a proxy like HAProxy in front of GitLab with the PROXY protocol:

Edit /etc/gitlab/gitlab.rb:

# Enable termination of ProxyProtocol by NGINX
nginx['proxy_protocol'] = true
# Configure trusted upstream proxies. Required if `proxy_protocol` is enabled.
nginx['real_ip_trusted_addresses'] = [ "127.0.0.0/8", "IP_OF_THE_PROXY/32"]

Save the file and reconfigure GitLab for the changes to take effect.

After you enable this setting, NGINX only accepts PROXY protocol traffic on these listeners. Adjust any other environments you might have, such as monitoring checks.

Use a non-bundled web server

By default, the Linux package installs GitLab with bundled NGINX. Linux package installations allow web server access through the gitlab-www user, which resides in the group with the same name. To allow an external web server access to GitLab, add the external web server user to the gitlab-www group.

To use another web server like Apache or an existing NGINX installation:

Disable bundled NGINX:

In /etc/gitlab/gitlab.rb set:
```
nginx['enable'] = false
```
Set the username of the non-bundled web server user:

Linux package installations have no default setting for the external web server user. You must specify it in the configuration. For example:
- Debian/Ubuntu: The default user is www-data for both Apache and NGINX.
- RHEL/CentOS: The NGINX user is nginx.
Install Apache or NGINX before continuing, so the web server user is created. Otherwise, the Linux package installation fails during reconfiguration.

If the web server user is www-data, in /etc/gitlab/gitlab.rb set:
```
web_server['external_users'] = ['www-data']
```
This setting is an array, so you can specify multiple users to add to the gitlab-www group.

Run sudo gitlab-ctl reconfigure for the change to take effect.

If you use SELinux and your web server runs under a restricted SELinux profile, you might need to loosen the restrictions on your web server.

Ensure the web server user has the correct permissions on all directories used by the external web server. Otherwise, you might receive failed (XX: Permission denied) while reading upstream errors.
Add the non-bundled web server to the list of trusted proxies:

Linux package installations usually default the list of trusted proxies to the configuration in the real_ip module for the bundled NGINX.

For non-bundled web servers, configure the list directly. Include the IP address of your web server if it is not on the same machine as GitLab. Otherwise, users appear to be signed in from your web server's IP address.
```
gitlab_rails['trusted_proxies'] = [ '192.168.1.0/24', '192.168.2.1', '2001:0db8::/32' ]
```
Optional. If you use Apache, set GitLab Workhorse settings:

Apache cannot connect to a UNIX socket and must connect to a TCP port. To allow GitLab Workhorse to listen on TCP (by default port 8181), edit /etc/gitlab/gitlab.rb:
```
gitlab_workhorse['listen_network'] = "tcp"
gitlab_workhorse['listen_addr'] = "127.0.0.1:8181"
```
Run sudo gitlab-ctl reconfigure for the change to take effect.
Download the correct web server configuration:

Go to the GitLab repository and download the required configuration. Select the correct configuration file for serving GitLab with or without SSL. You might need to change:
- The value of YOUR_SERVER_FQDN to your FQDN.
- If you use SSL, the location of your SSL keys.
- The location of your log files.

NGINX configuration options

GitLab provides various configuration options to customize NGINX behavior for your specific needs. Use these reference items to fine-tune your NGINX setup and optimize GitLab performance and security.

Set the NGINX listen addresses

By default, NGINX accepts incoming connections on all local IPv4 addresses.

To change the list of addresses:

Edit /etc/gitlab/gitlab.rb:

# Listen on all IPv4 and IPv6 addresses
nginx['listen_addresses'] = ["0.0.0.0", "[::]"]
registry_nginx['listen_addresses'] = ['*', '[::]']
mattermost_nginx['listen_addresses'] = ['*', '[::]']
pages_nginx['listen_addresses'] = ['*', '[::]']

Save the file and reconfigure GitLab for the changes to take effect.

Set the NGINX listen port

By default, NGINX listens on the port specified in external_url or uses the standard port (80 for HTTP, 443 for HTTPS). If you run GitLab behind a reverse proxy, you might want to override the listen port.

To change the listen port:

Edit /etc/gitlab/gitlab.rb. For example, to use port 8081:
```
nginx['listen_port'] = 8081
```
Save the file and reconfigure GitLab for the changes to take effect.

Change the verbosity level of NGINX logs

By default, NGINX logs at the error verbosity level.

To change the log level:

Edit /etc/gitlab/gitlab.rb:
```
nginx['error_log_level'] = "debug"
```
Save the file and reconfigure GitLab for the changes to take effect.

For valid log level values, see the NGINX documentation.

Set the Referrer-Policy header

By default, GitLab sets the Referrer-Policy header to strict-origin-when-cross-origin on all responses. This setting makes the client:

Send the full URL as referrer for same-origin requests.
Send only the origin for cross-origin requests.

To change this header:

Edit /etc/gitlab/gitlab.rb:
```
nginx['referrer_policy'] = 'same-origin'
```
To disable this header and use the client's default setting:
```
nginx['referrer_policy'] = false
```
Save the file and reconfigure GitLab for the changes to take effect.

WARNING: Setting this to origin or no-referrer breaks GitLab features that require the full referrer URL.

For more information, see the Referrer Policy specification.

Disable Gzip compression

By default, GitLab enables Gzip compression for text data over 10240 bytes. To disable Gzip compression:

Edit /etc/gitlab/gitlab.rb:
```
nginx['gzip_enabled'] = false
```
Save the file and reconfigure GitLab for the changes to take effect.

NOTE: The gzip setting applies only to the main GitLab application, not to other services.

Disable proxy request buffering

To disable request buffering for specific locations:

Edit /etc/gitlab/gitlab.rb:

nginx['request_buffering_off_path_regex'] = "/api/v\\d/jobs/\\d+/artifacts$|/import/gitlab_project$|\\.git/git-receive-pack$|\\.git/ssh-receive-pack$|\\.git/ssh-upload-pack$|\\.git/gitlab-lfs/objects|\\.git/info/lfs/objects/batch$"

Save the file and reconfigure GitLab for the changes to take effect.
Reload NGINX configuration gracefully:
```
sudo gitlab-ctl hup nginx
```

For more information about the hup command, see the NGINX documentation.

Configure `robots.txt`

To configure a custom robots.txt file for your instance:

Create your custom robots.txt file and note its path.
Edit /etc/gitlab/gitlab.rb:
```
nginx['custom_gitlab_server_config'] = "\nlocation =/robots.txt { alias /path/to/custom/robots.txt; }\n"
```
Replace /path/to/custom/robots.txt with the actual path to your custom robots.txt file.
Save the file and reconfigure GitLab for the changes to take effect.

This configuration adds a custom NGINX setting to serve your custom robots.txt file.

Insert custom NGINX settings into the GitLab server block

To add custom settings to the NGINX server block for GitLab:

Edit /etc/gitlab/gitlab.rb:

# Example: block raw file downloads from a specific repository
nginx['custom_gitlab_server_config'] = "location ^~ /foo-namespace/bar-project/raw/ {\n deny all;\n}\n"

Save the file and reconfigure GitLab for the changes to take effect.

This inserts the defined string at the end of the server block in /var/opt/gitlab/nginx/conf/gitlab-http.conf.

WARNING: Custom settings might conflict with settings defined elsewhere in your gitlab.rb file.

Notes

If you're adding a new location, you might need to include:
```
proxy_cache off;
proxy_http_version 1.1;
proxy_pass http://gitlab-workhorse;
```
Without these, any sub-location might return a 404 error.
You cannot add the root / location or the /assets location, as they already exist in gitlab-http.conf.

Insert custom settings into the NGINX configuration

To add custom settings to the NGINX configuration:

Edit /etc/gitlab/gitlab.rb:

# Example: include a directory to scan for additional config files
nginx['custom_nginx_config'] = "include /etc/gitlab/nginx/sites-enabled/*.conf;"

Save the file and reconfigure GitLab for the changes to take effect.

This inserts the defined string at the end of the http block in /var/opt/gitlab/nginx/conf/nginx.conf.

For example, to create and enable custom server blocks:

Create custom server blocks in the /etc/gitlab/nginx/sites-available directory.
Create the /etc/gitlab/nginx/sites-enabled directory if it doesn't exist.

To enable a custom server block, create a symlink:

sudo ln -s /etc/gitlab/nginx/sites-available/example.conf /etc/gitlab/nginx/sites-enabled/example.conf

Reload NGINX configuration:
```
sudo gitlab-ctl hup nginx
```
Alternatively, you can restart NGINX:
```
sudo gitlab-ctl restart nginx
```

You can add domains for server blocks as an alternative name to the generated Let's Encrypt SSL certificate.

Custom NGINX settings inside the /etc/gitlab/ directory are backed up to /etc/gitlab/config_backup/ during an upgrade and when sudo gitlab-ctl backup-etc is manually executed.

Configure custom error pages

To modify text on the default GitLab error pages:

Edit /etc/gitlab/gitlab.rb:
```
nginx['custom_error_pages'] = {
 '404' => {
   'title' => 'Example title',
   'header' => 'Example header',
   'message' => 'Example message'
 }
}
```
This example modifies the default 404 error page. You can use this format for any valid HTTP error code, such as 404 or 502.
Save the file and reconfigure GitLab for the changes to take effect.

The result for the 404 error page would look like this:

Use an existing Passenger and NGINX installation

You can host GitLab with an existing Passenger and NGINX installation and still use Linux packages for updates and installation.

If you disable NGINX, you can't access other services included in a Linux package installation, such as Mattermost, unless you manually add them to nginx.conf.

Configuration

To set up GitLab with an existing Passenger and NGINX installation:

Edit /etc/gitlab/gitlab.rb:

# Define the external url
external_url 'http://git.example.com'

# Disable the built-in NGINX
nginx['enable'] = false

# Disable the built-in Puma
puma['enable'] = false

# Set the internal API URL
gitlab_rails['internal_api_url'] = 'http://git.example.com'

# Define the web server process user (ubuntu/nginx)
web_server['external_users'] = ['www-data']

Save the file and reconfigure GitLab for the changes to take effect.

Configure the virtual host (server block)

In your custom Passenger/NGINX installation:

Create a new site configuration file with the following content:

upstream gitlab-workhorse {
 server unix://var/opt/gitlab/gitlab-workhorse/sockets/socket fail_timeout=0;
}

server {
 listen *:80;
 server_name git.example.com;
 server_tokens off;
 root /opt/gitlab/embedded/service/gitlab-rails/public;

 client_max_body_size 250m;

 access_log  /var/log/gitlab/nginx/gitlab_access.log;
 error_log   /var/log/gitlab/nginx/gitlab_error.log;

 # Ensure Passenger uses the bundled Ruby version
 passenger_ruby /opt/gitlab/embedded/bin/ruby;

 # Correct the $PATH variable to included packaged executables
 passenger_env_var PATH "/opt/gitlab/bin:/opt/gitlab/embedded/bin:/usr/local/bin:/usr/bin:/bin";

 # Make sure Passenger runs as the correct user and group to
 # prevent permission issues
 passenger_user git;
 passenger_group git;

 # Enable Passenger & keep at least one instance running at all times
 passenger_enabled on;
 passenger_min_instances 1;

 location ~ ^/[\w\.-]+/[\w\.-]+/(info/refs|git-upload-pack|git-receive-pack)$ {
   # 'Error' 418 is a hack to re-use the @gitlab-workhorse block
   error_page 418 = @gitlab-workhorse;
   return 418;
 }

 location ~ ^/[\w\.-]+/[\w\.-]+/repository/archive {
   # 'Error' 418 is a hack to re-use the @gitlab-workhorse block
   error_page 418 = @gitlab-workhorse;
   return 418;
 }

 location ~ ^/api/v3/projects/.*/repository/archive {
   # 'Error' 418 is a hack to re-use the @gitlab-workhorse block
   error_page 418 = @gitlab-workhorse;
   return 418;
 }

 # Build artifacts should be submitted to this location
 location ~ ^/[\w\.-]+/[\w\.-]+/builds/download {
     client_max_body_size 0;
     # 'Error' 418 is a hack to re-use the @gitlab-workhorse block
     error_page 418 = @gitlab-workhorse;
     return 418;
 }

 # Build artifacts should be submitted to this location
 location ~ /ci/api/v1/builds/[0-9]+/artifacts {
     client_max_body_size 0;
     # 'Error' 418 is a hack to re-use the @gitlab-workhorse block
     error_page 418 = @gitlab-workhorse;
     return 418;
 }

 # Build artifacts should be submitted to this location
 location ~ /api/v4/jobs/[0-9]+/artifacts {
     client_max_body_size 0;
     # 'Error' 418 is a hack to re-use the @gitlab-workhorse block
     error_page 418 = @gitlab-workhorse;
     return 418;
 }


 # For protocol upgrades from HTTP/1.0 to HTTP/1.1 we need to provide Host header if its missing
 if ($http_host = "") {
 # use one of values defined in server_name
   set $http_host_with_default "git.example.com";
 }

 if ($http_host != "") {
   set $http_host_with_default $http_host;
 }

 location @gitlab-workhorse {

   ## https://github.com/gitlabhq/gitlabhq/issues/694
   ## Some requests take more than 30 seconds.
   proxy_read_timeout      3600;
   proxy_connect_timeout   300;
   proxy_redirect          off;

   # Do not buffer Git HTTP responses
   proxy_buffering off;

   proxy_set_header    Host                $http_host_with_default;
   proxy_set_header    X-Real-IP           $remote_addr;
   proxy_set_header    X-Forwarded-For     $proxy_add_x_forwarded_for;
   proxy_set_header    X-Forwarded-Proto   $scheme;

   proxy_http_version 1.1;
   proxy_pass http://gitlab-workhorse;

   ## The following settings only work with NGINX 1.7.11 or newer
   #
   ## Pass chunked request bodies to gitlab-workhorse as-is
   # proxy_request_buffering off;
   # proxy_http_version 1.1;
 }

 ## Enable gzip compression as per rails guide:
 ## http://guides.rubyonrails.org/asset_pipeline.html#gzip-compression
 ## WARNING: If you are using relative urls remove the block below
 ## See config/application.rb under "Relative url support" for the list of
 ## other files that need to be changed for relative url support
 location ~ ^/(assets)/ {
   root /opt/gitlab/embedded/service/gitlab-rails/public;
   gzip_static on; # to serve pre-gzipped version
   expires max;
   add_header Cache-Control public;
 }

 error_page 502 /502.html;
}

Replace git.example.com with your server URL.

If you receive a 403 Forbidden error, ensure Passenger is enabled in /etc/nginx/nginx.conf:

Uncomment this line:
```
# include /etc/nginx/passenger.conf;
```
Reload the NGINX configuration:
```
sudo service nginx reload
```

Configure NGINX status monitoring

By default, GitLab configures an NGINX health-check endpoint at 127.0.0.1:8060/nginx_status to monitor your NGINX server status.

The endpoint displays the following information:

Active connections: 1
server accepts handled requests
18 18 36
Reading: 0 Writing: 1 Waiting: 0

Active connections: Open connections in total.
Three figures showing:
- All accepted connections.
- All handled connections.
- Total number of handled requests.
Reading: NGINX reads request headers.
Writing: NGINX reads request bodies, processes requests, or writes responses to a client.
Waiting: Keep-alive connections. This number depends on the keepalive_timeout directive.

Configure NGINX status options

To configure NGINX status options:

Edit /etc/gitlab/gitlab.rb:

nginx['status'] = {
 "listen_addresses" => ["127.0.0.1"],
 "fqdn" => "dev.example.com",
 "port" => 9999,
 "options" => {
   "access_log" => "on", # Disable logs for stats
   "allow" => "127.0.0.1", # Only allow access from localhost
   "deny" => "all" # Deny access to anyone else
 }
}

To disable the NGINX status endpoint:

nginx['status'] = {
 'enable' => false
}

Save the file and reconfigure GitLab for the changes to take effect.

Configure user permissions for uploads

To ensure user uploads are accessible, add your NGINX user (usually www-data) to the gitlab-www group:

sudo usermod -aG gitlab-www www-data

Templates

The configuration files are similar to the bundled GitLab NGINX configuration, with these differences:

Passenger configuration is used instead of Puma.
HTTPS is not enabled by default, but you can enable it.

After making changes to the NGINX configuration:

For Debian-based systems, restart NGINX:
```
sudo service nginx restart
```
For other systems, refer to your operating system's documentation for the correct command to restart NGINX.

unbundled nginx – using external nginx

To clarify the process and ensure your external NGINX serves GitLab, along with the dit-dah.click and localtransporter.space domains, follow these steps:

Step-by-Step Plan for Multiple Domains with External NGINX

Disable Bundled GitLab NGINX (GitLab Configuration)
Set Up Virtual Hosts for External NGINX (for dit-dah.click and localtransporter.space)
Serve GitLab from External NGINX (for spiffydesign.com or glab.dit-dah.click)
Set Up SSL for All Domains
Reconfigure GitLab and Restart NGINX

Step 1: Disable GitLab’s Bundled NGINX

Open /etc/gitlab/gitlab.rb and add this line to disable the bundled NGINX:

nginx['enable'] = false

Also, configure the external web server user (likely nginx):

web_server['external_users'] = ['nginx']

Then, run:

sudo gitlab-ctl reconfigure

Step 2: Set Up Virtual Hosts for `dit-dah.click` and `localtransporter.space`

Edit the /etc/nginx/conf.d/dit-dah.click.conf for dit-dah.click and /etc/nginx/conf.d/localtransporter.space.conf for localtransporter.space.

old multi site

#react server { listen 195.35.32.187; root /usr/share/nginx/html/dit-dah.click; server_name dit-dah.click;

    #ssl_certificate /etc/letsencrypt/live/dit-dah.click/fullchain.pem;
    #ssl_certificate_key /etc/letsencrypt/live/dit-dah.click/privkey.pem;

    location / {
    try_files $uri $uri/ =404;
   }
}

#admin server { listen 195.35.32.187; root usr/share/nginx/html/localtransporter.space; server_name localtransporter.space;

    #ssl_certificate /etc/letsencrypt/live/dit-dah.click/fullchain.pem;
    #ssl_certificate_key /etc/letsencrypt/live/dit-dah.click/privkey.pem;

    location / {
    try_files $uri $uri/ =404;
   }
}

Example Configuration for `dit-dah.click`:

server {
    listen 80;
    server_name dit-dah.click www.dit-dah.click;
    return 301 https://$host$request_uri;  # Redirect HTTP to HTTPS
}

server {
    listen 443 ssl;
    server_name dit-dah.click www.dit-dah.click;

    ssl_certificate /etc/letsencrypt/live/dit-dah.click/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/dit-dah.click/privkey.pem;

    root /var/www/dit-dah.click;  # Adjust to your React build directory
    index index.html index.htm;

    location / {
        try_files $uri /index.html;
    }
}

Example Configuration for `localtransporter.space`:

server {
    listen 80;
    server_name localtransporter.space www.localtransporter.space;
    return 301 https://$host$request_uri;  # Redirect HTTP to HTTPS
}

server {
    listen 443 ssl;
    server_name localtransporter.space www.localtransporter.space;

    ssl_certificate /etc/letsencrypt/live/localtransporter.space/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/localtransporter.space/privkey.pem;

    root /var/www/localtransporter.space/public;  # Adjust to your Laravel app root
    index index.php index.html index.htm;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;
    }
}

Step 3: Serve GitLab Through External NGINX (for `spiffydesign.com`)

ORIGINAL

#   * Official English Documentation: http://nginx.org/en/docs/
#   * Official Russian Documentation: http://nginx.org/ru/docs/

user nginx;
worker_processes auto;
error_log /var/log/nginx/error.log;
pid /run/nginx.pid;

# Load dynamic modules. See /usr/share/doc/nginx/README.dynamic.
include /usr/share/nginx/modules/*.conf;

events {
    worker_connections 1024;
}

http {
    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;

    sendfile            on;
    tcp_nopush          on;
    tcp_nodelay         on;
    keepalive_timeout   65;
    types_hash_max_size 4096;

    include             /etc/nginx/mime.types;
    default_type        application/octet-stream;

    # Load modular configuration files from the /etc/nginx/conf.d directory.
    # See http://nginx.org/en/docs/ngx_core_module.html#include
    # for more information.
    include /etc/nginx/conf.d/*.conf;

    server {
	listen       80;
        listen       [::]:80;
        server_name  _;
        root         /usr/share/nginx/html;

       	# Load configuration files for the default server block.
        include /etc/nginx/default.d/*.conf;

        error_page 404 /404.html;
        location = /404.html {
        }

	error_page 500 502 503 504 /50x.html;
        location = /50x.html {
        }
    }
#react
#    server {
 #       listen 195.35.32.187;
  #      root /usr/share/nginx/html/dit-dah.click;
   #     server_name dit-dah.click;

       	#ssl_certificate /etc/letsencrypt/live/dit-dah.click/fullchain.pem;
       	#ssl_certificate_key /etc/letsencrypt/live/dit-dah.click/privkey.pem;

    #    location / {
     #   try_files $uri $uri/ =404;
      # }
  #  }
#admin
   # server {
    #    listen  195.35.32.187;
     #   root usr/share/nginx/html/localtransporter.space;
      #  server_name localtransporter.space;

       	#ssl_certificate /etc/letsencrypt/live/dit-dah.click/fullchain.pem;
       	#ssl_certificate_key /etc/letsencrypt/live/dit-dah.click/privkey.pem;

       # location / {
       # try_files $uri $uri/ =404;
      # }
   # }
   
# Settings for a TLS enabled server.
#
#    server {
#        listen       443 ssl http2;
#        listen       [::]:443 ssl http2;
#        server_name  _;
#        root         /usr/share/nginx/html;
#
#        ssl_certificate "/etc/pki/nginx/server.crt";
#        ssl_certificate_key "/etc/pki/nginx/private/server.key";
#        ssl_session_cache shared:SSL:1m;
#        ssl_session_timeout  10m;
#        ssl_ciphers PROFILE=SYSTEM;
#        ssl_prefer_server_ciphers on;
#
#        # Load configuration files for the default server block.
#        include /etc/nginx/default.d/*.conf;
#
#        error_page 404 /404.html;
#            location = /40x.html {
#        }
#
#        error_page 500 502 503 504 /50x.html;
#            location = /50x.html {
#        }
#    }

}

Create a new configuration file for GitLab (for example, /etc/nginx/conf.d/gitlab.conf):

upstream gitlab-workhorse {
    server unix:/var/opt/gitlab/gitlab-workhorse/socket fail_timeout=0;
}

server {
    listen 80;
    server_name spiffydesign.com;
    return 301 https://$host$request_uri;  # Redirect HTTP to HTTPS
}

server {
    listen 443 ssl;
    server_name spiffydesign.com;

    ssl_certificate /etc/letsencrypt/live/spiffydesign.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/spiffydesign.com/privkey.pem;

    location / {
        proxy_pass http://gitlab-workhorse;
        proxy_set_header Host $http_host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Frame-Options SAMEORIGIN;
        proxy_set_header X-Content-Type-Options nosniff;
    }

    access_log /var/log/nginx/gitlab_access.log;
    error_log /var/log/nginx/gitlab_error.log;
}

Step 4: Set Up SSL for All Domains

Use Certbot to configure SSL for each domain.

For dit-dah.click:

sudo certbot --nginx -d dit-dah.click -d www.dit-dah.click

For localtransporter.space:

sudo certbot --nginx -d localtransporter.space -d www.localtransporter.space

For spiffydesign.com (GitLab domain):

sudo certbot --nginx -d spiffydesign.com

This will generate SSL certificates and update the NGINX configuration automatically.

Step 5: Reconfigure GitLab and Restart NGINX

Run the following command to apply the GitLab configuration:

sudo gitlab-ctl reconfigure

Then restart NGINX to apply all changes:

sudo systemctl restart nginx

Now, you should have the following setup:

dit-dah.click serves your React front end.
localtransporter.space serves your Laravel back end.
spiffydesign.com serves the GitLab interface.

Let me know if any specific parts of the setup need more clarification!

Yes, spiffydesign.com will continue working as long as:

GitLab's Bundled NGINX is Disabled: You’ve already disabled the bundled NGINX within GitLab (nginx['enable'] = false), and it should now rely on your external NGINX.
NGINX Configuration for GitLab is Set: If you’ve properly set up the NGINX virtual host configuration for spiffydesign.com (or glab.dit-dah.click), GitLab will continue to work as expected. The configuration will serve GitLab through the external NGINX, handling both HTTP and HTTPS traffic.
SSL Certificates: If you’ve obtained SSL certificates for spiffydesign.com via Certbot (or manually if needed), the HTTPS version of the site will keep running securely.

If everything is configured correctly, you don’t need to worry about spiffydesign.com—it should function seamlessly alongside your other domains (dit-dah.click and localtransporter.space). As long as the NGINX server is running and properly configured, all of your domains will continue working without conflicts.

To confirm it's working, you can test:

sudo systemctl restart nginx
curl -I https://spiffydesign.com

NGINX settings

DETAILS: Tier: Free, Premium, Ultimate Offering: Self-managed

Service-specific NGINX settings

To configure NGINX settings for different services, edit the gitlab.rb file.

WARNING: Incorrect or incompatible configuration might cause the service to become unavailable.

nginx['redirect_http_to_https'] = true
registry_nginx['redirect_http_to_https'] = true
mattermost_nginx['redirect_http_to_https'] = true

Enable HTTPS

By default, Linux package installations do not use HTTPS. To enable HTTPS for gitlab.example.com:

If you use a proxy, load balancer, or other external device to terminate SSL for the GitLab host name, see External, proxy, and load balancer SSL termination.

Change the default proxy headers

By default, when you specify external_url, a Linux package installation sets NGINX proxy headers that are suitable for most environments.

For example, if you specify the https schema in the external_url, a Linux package installation sets:

"X-Forwarded-Proto" => "https",
"X-Forwarded-Ssl" => "on"

If your GitLab instance is in a more complex setup, such as behind a reverse proxy, you might need to adjust the proxy headers to avoid errors like:

The change you wanted was rejected
Can't verify CSRF token authenticity Completed 422 Unprocessable

To override the default headers:

Edit /etc/gitlab/gitlab.rb:

nginx['proxy_set_headers'] = {
  "X-Forwarded-Proto" => "http",
  "CUSTOM_HEADER" => "VALUE"
}

Save the file and reconfigure GitLab for the changes to take effect.

You can specify any header supported by NGINX.

Configure GitLab trusted proxies and NGINX `real_ip` module

By default, NGINX and GitLab log the IP address of the connected client.

If GitLab is behind a reverse proxy, you might not want the IP address of the proxy to show as the client address.

To configure NGINX to use a different address, add your reverse proxy to the real_ip_trusted_addresses list:

# Each address is added to the NGINX config as 'set_real_ip_from <address>;'
nginx['real_ip_trusted_addresses'] = [ '192.168.1.0/24', '192.168.2.1', '2001:0db8::/32' ]
# Other real_ip config options
nginx['real_ip_header'] = 'X-Forwarded-For'
nginx['real_ip_recursive'] = 'on'

For a description of these options, see the NGINX realip module documentation.

Save the file and reconfigure GitLab for the changes to take effect.

Configure the PROXY protocol

To use a proxy like HAProxy in front of GitLab with the PROXY protocol:

Edit /etc/gitlab/gitlab.rb:

# Enable termination of ProxyProtocol by NGINX
nginx['proxy_protocol'] = true
# Configure trusted upstream proxies. Required if `proxy_protocol` is enabled.
nginx['real_ip_trusted_addresses'] = [ "127.0.0.0/8", "IP_OF_THE_PROXY/32"]

Save the file and reconfigure GitLab for the changes to take effect.

After you enable this setting, NGINX only accepts PROXY protocol traffic on these listeners. Adjust any other environments you might have, such as monitoring checks.

Use a non-bundled web server

To use another web server like Apache or an existing NGINX installation:

Disable bundled NGINX:

In /etc/gitlab/gitlab.rb set:
```
nginx['enable'] = false
```
Set the username of the non-bundled web server user:

Linux package installations have no default setting for the external web server user. You must specify it in the configuration. For example:
- Debian/Ubuntu: The default user is www-data for both Apache and NGINX.
- RHEL/CentOS: The NGINX user is nginx.
Install Apache or NGINX before continuing, so the web server user is created. Otherwise, the Linux package installation fails during reconfiguration.

If the web server user is www-data, in /etc/gitlab/gitlab.rb set:
```
web_server['external_users'] = ['www-data']
```
This setting is an array, so you can specify multiple users to add to the gitlab-www group.

Run sudo gitlab-ctl reconfigure for the change to take effect.

If you use SELinux and your web server runs under a restricted SELinux profile, you might need to loosen the restrictions on your web server.

Ensure the web server user has the correct permissions on all directories used by the external web server. Otherwise, you might receive failed (XX: Permission denied) while reading upstream errors.
Add the non-bundled web server to the list of trusted proxies:

Linux package installations usually default the list of trusted proxies to the configuration in the real_ip module for the bundled NGINX.

For non-bundled web servers, configure the list directly. Include the IP address of your web server if it is not on the same machine as GitLab. Otherwise, users appear to be signed in from your web server's IP address.
```
gitlab_rails['trusted_proxies'] = [ '192.168.1.0/24', '192.168.2.1', '2001:0db8::/32' ]
```
Optional. If you use Apache, set GitLab Workhorse settings:

Apache cannot connect to a UNIX socket and must connect to a TCP port. To allow GitLab Workhorse to listen on TCP (by default port 8181), edit /etc/gitlab/gitlab.rb:
```
gitlab_workhorse['listen_network'] = "tcp"
gitlab_workhorse['listen_addr'] = "127.0.0.1:8181"
```
Run sudo gitlab-ctl reconfigure for the change to take effect.
Download the correct web server configuration:

Go to the GitLab repository and download the required configuration. Select the correct configuration file for serving GitLab with or without SSL. You might need to change:
- The value of YOUR_SERVER_FQDN to your FQDN.
- If you use SSL, the location of your SSL keys.
- The location of your log files.

NGINX configuration options

Set the NGINX listen addresses

By default, NGINX accepts incoming connections on all local IPv4 addresses.

To change the list of addresses:

Edit /etc/gitlab/gitlab.rb:

# Listen on all IPv4 and IPv6 addresses
nginx['listen_addresses'] = ["0.0.0.0", "[::]"]
registry_nginx['listen_addresses'] = ['*', '[::]']
mattermost_nginx['listen_addresses'] = ['*', '[::]']
pages_nginx['listen_addresses'] = ['*', '[::]']

Save the file and reconfigure GitLab for the changes to take effect.

Set the NGINX listen port

To change the listen port:

Edit /etc/gitlab/gitlab.rb. For example, to use port 8081:
```
nginx['listen_port'] = 8081
```
Save the file and reconfigure GitLab for the changes to take effect.

Change the verbosity level of NGINX logs

By default, NGINX logs at the error verbosity level.

To change the log level:

Edit /etc/gitlab/gitlab.rb:
```
nginx['error_log_level'] = "debug"
```
Save the file and reconfigure GitLab for the changes to take effect.

For valid log level values, see the NGINX documentation.

Set the Referrer-Policy header

By default, GitLab sets the Referrer-Policy header to strict-origin-when-cross-origin on all responses. This setting makes the client:

Send the full URL as referrer for same-origin requests.
Send only the origin for cross-origin requests.

To change this header:

Edit /etc/gitlab/gitlab.rb:
```
nginx['referrer_policy'] = 'same-origin'
```
To disable this header and use the client's default setting:
```
nginx['referrer_policy'] = false
```
Save the file and reconfigure GitLab for the changes to take effect.

WARNING: Setting this to origin or no-referrer breaks GitLab features that require the full referrer URL.

For more information, see the Referrer Policy specification.

Disable Gzip compression

By default, GitLab enables Gzip compression for text data over 10240 bytes. To disable Gzip compression:

Edit /etc/gitlab/gitlab.rb:
```
nginx['gzip_enabled'] = false
```
Save the file and reconfigure GitLab for the changes to take effect.

NOTE: The gzip setting applies only to the main GitLab application, not to other services.

Disable proxy request buffering

To disable request buffering for specific locations:

Edit /etc/gitlab/gitlab.rb:

nginx['request_buffering_off_path_regex'] = "/api/v\\d/jobs/\\d+/artifacts$|/import/gitlab_project$|\\.git/git-receive-pack$|\\.git/ssh-receive-pack$|\\.git/ssh-upload-pack$|\\.git/gitlab-lfs/objects|\\.git/info/lfs/objects/batch$"

Save the file and reconfigure GitLab for the changes to take effect.
Reload NGINX configuration gracefully:
```
sudo gitlab-ctl hup nginx
```

For more information about the hup command, see the NGINX documentation.

Configure `robots.txt`

To configure a custom robots.txt file for your instance:

Create your custom robots.txt file and note its path.
Edit /etc/gitlab/gitlab.rb:
```
nginx['custom_gitlab_server_config'] = "\nlocation =/robots.txt { alias /path/to/custom/robots.txt; }\n"
```
Replace /path/to/custom/robots.txt with the actual path to your custom robots.txt file.
Save the file and reconfigure GitLab for the changes to take effect.

This configuration adds a custom NGINX setting to serve your custom robots.txt file.

Insert custom NGINX settings into the GitLab server block

To add custom settings to the NGINX server block for GitLab:

Edit /etc/gitlab/gitlab.rb:

# Example: block raw file downloads from a specific repository
nginx['custom_gitlab_server_config'] = "location ^~ /foo-namespace/bar-project/raw/ {\n deny all;\n}\n"

Save the file and reconfigure GitLab for the changes to take effect.

This inserts the defined string at the end of the server block in /var/opt/gitlab/nginx/conf/gitlab-http.conf.

WARNING: Custom settings might conflict with settings defined elsewhere in your gitlab.rb file.

Notes

If you're adding a new location, you might need to include:
```
proxy_cache off;
proxy_http_version 1.1;
proxy_pass http://gitlab-workhorse;
```
Without these, any sub-location might return a 404 error.
You cannot add the root / location or the /assets location, as they already exist in gitlab-http.conf.

Insert custom settings into the NGINX configuration

To add custom settings to the NGINX configuration:

Edit /etc/gitlab/gitlab.rb:

# Example: include a directory to scan for additional config files
nginx['custom_nginx_config'] = "include /etc/gitlab/nginx/sites-enabled/*.conf;"

Save the file and reconfigure GitLab for the changes to take effect.

This inserts the defined string at the end of the http block in /var/opt/gitlab/nginx/conf/nginx.conf.

For example, to create and enable custom server blocks:

Create custom server blocks in the /etc/gitlab/nginx/sites-available directory.
Create the /etc/gitlab/nginx/sites-enabled directory if it doesn't exist.

To enable a custom server block, create a symlink:

sudo ln -s /etc/gitlab/nginx/sites-available/example.conf /etc/gitlab/nginx/sites-enabled/example.conf

Reload NGINX configuration:
```
sudo gitlab-ctl hup nginx
```
Alternatively, you can restart NGINX:
```
sudo gitlab-ctl restart nginx
```

You can add domains for server blocks as an alternative name to the generated Let's Encrypt SSL certificate.

Custom NGINX settings inside the /etc/gitlab/ directory are backed up to /etc/gitlab/config_backup/ during an upgrade and when sudo gitlab-ctl backup-etc is manually executed.

Configure custom error pages

To modify text on the default GitLab error pages:

Edit /etc/gitlab/gitlab.rb:
```
nginx['custom_error_pages'] = {
 '404' => {
   'title' => 'Example title',
   'header' => 'Example header',
   'message' => 'Example message'
 }
}
```
This example modifies the default 404 error page. You can use this format for any valid HTTP error code, such as 404 or 502.
Save the file and reconfigure GitLab for the changes to take effect.

The result for the 404 error page would look like this:

Use an existing Passenger and NGINX installation

You can host GitLab with an existing Passenger and NGINX installation and still use Linux packages for updates and installation.

If you disable NGINX, you can't access other services included in a Linux package installation, such as Mattermost, unless you manually add them to nginx.conf.

Configuration

To set up GitLab with an existing Passenger and NGINX installation:

Edit /etc/gitlab/gitlab.rb:

# Define the external url
external_url 'http://git.example.com'

# Disable the built-in NGINX
nginx['enable'] = false

# Disable the built-in Puma
puma['enable'] = false

# Set the internal API URL
gitlab_rails['internal_api_url'] = 'http://git.example.com'

# Define the web server process user (ubuntu/nginx)
web_server['external_users'] = ['www-data']

Save the file and reconfigure GitLab for the changes to take effect.

Configure the virtual host (server block)

In your custom Passenger/NGINX installation:

Create a new site configuration file with the following content:

upstream gitlab-workhorse {
 server unix://var/opt/gitlab/gitlab-workhorse/sockets/socket fail_timeout=0;
}

server {
 listen *:80;
 server_name git.example.com;
 server_tokens off;
 root /opt/gitlab/embedded/service/gitlab-rails/public;

 client_max_body_size 250m;

 access_log  /var/log/gitlab/nginx/gitlab_access.log;
 error_log   /var/log/gitlab/nginx/gitlab_error.log;

 # Ensure Passenger uses the bundled Ruby version
 passenger_ruby /opt/gitlab/embedded/bin/ruby;

 # Correct the $PATH variable to included packaged executables
 passenger_env_var PATH "/opt/gitlab/bin:/opt/gitlab/embedded/bin:/usr/local/bin:/usr/bin:/bin";

 # Make sure Passenger runs as the correct user and group to
 # prevent permission issues
 passenger_user git;
 passenger_group git;

 # Enable Passenger & keep at least one instance running at all times
 passenger_enabled on;
 passenger_min_instances 1;

 location ~ ^/[\w\.-]+/[\w\.-]+/(info/refs|git-upload-pack|git-receive-pack)$ {
   # 'Error' 418 is a hack to re-use the @gitlab-workhorse block
   error_page 418 = @gitlab-workhorse;
   return 418;
 }

 location ~ ^/[\w\.-]+/[\w\.-]+/repository/archive {
   # 'Error' 418 is a hack to re-use the @gitlab-workhorse block
   error_page 418 = @gitlab-workhorse;
   return 418;
 }

 location ~ ^/api/v3/projects/.*/repository/archive {
   # 'Error' 418 is a hack to re-use the @gitlab-workhorse block
   error_page 418 = @gitlab-workhorse;
   return 418;
 }

 # Build artifacts should be submitted to this location
 location ~ ^/[\w\.-]+/[\w\.-]+/builds/download {
     client_max_body_size 0;
     # 'Error' 418 is a hack to re-use the @gitlab-workhorse block
     error_page 418 = @gitlab-workhorse;
     return 418;
 }

 # Build artifacts should be submitted to this location
 location ~ /ci/api/v1/builds/[0-9]+/artifacts {
     client_max_body_size 0;
     # 'Error' 418 is a hack to re-use the @gitlab-workhorse block
     error_page 418 = @gitlab-workhorse;
     return 418;
 }

 # Build artifacts should be submitted to this location
 location ~ /api/v4/jobs/[0-9]+/artifacts {
     client_max_body_size 0;
     # 'Error' 418 is a hack to re-use the @gitlab-workhorse block
     error_page 418 = @gitlab-workhorse;
     return 418;
 }


 # For protocol upgrades from HTTP/1.0 to HTTP/1.1 we need to provide Host header if its missing
 if ($http_host = "") {
 # use one of values defined in server_name
   set $http_host_with_default "git.example.com";
 }

 if ($http_host != "") {
   set $http_host_with_default $http_host;
 }

 location @gitlab-workhorse {

   ## https://github.com/gitlabhq/gitlabhq/issues/694
   ## Some requests take more than 30 seconds.
   proxy_read_timeout      3600;
   proxy_connect_timeout   300;
   proxy_redirect          off;

   # Do not buffer Git HTTP responses
   proxy_buffering off;

   proxy_set_header    Host                $http_host_with_default;
   proxy_set_header    X-Real-IP           $remote_addr;
   proxy_set_header    X-Forwarded-For     $proxy_add_x_forwarded_for;
   proxy_set_header    X-Forwarded-Proto   $scheme;

   proxy_http_version 1.1;
   proxy_pass http://gitlab-workhorse;

   ## The following settings only work with NGINX 1.7.11 or newer
   #
   ## Pass chunked request bodies to gitlab-workhorse as-is
   # proxy_request_buffering off;
   # proxy_http_version 1.1;
 }

 ## Enable gzip compression as per rails guide:
 ## http://guides.rubyonrails.org/asset_pipeline.html#gzip-compression
 ## WARNING: If you are using relative urls remove the block below
 ## See config/application.rb under "Relative url support" for the list of
 ## other files that need to be changed for relative url support
 location ~ ^/(assets)/ {
   root /opt/gitlab/embedded/service/gitlab-rails/public;
   gzip_static on; # to serve pre-gzipped version
   expires max;
   add_header Cache-Control public;
 }

 error_page 502 /502.html;
}

Replace git.example.com with your server URL.

If you receive a 403 Forbidden error, ensure Passenger is enabled in /etc/nginx/nginx.conf:

Uncomment this line:
```
# include /etc/nginx/passenger.conf;
```
Reload the NGINX configuration:
```
sudo service nginx reload
```

Configure NGINX status monitoring

By default, GitLab configures an NGINX health-check endpoint at 127.0.0.1:8060/nginx_status to monitor your NGINX server status.

The endpoint displays the following information:

Active connections: 1
server accepts handled requests
18 18 36
Reading: 0 Writing: 1 Waiting: 0

Active connections: Open connections in total.
Three figures showing:
- All accepted connections.
- All handled connections.
- Total number of handled requests.
Reading: NGINX reads request headers.
Writing: NGINX reads request bodies, processes requests, or writes responses to a client.
Waiting: Keep-alive connections. This number depends on the keepalive_timeout directive.

Configure NGINX status options

To configure NGINX status options:

Edit /etc/gitlab/gitlab.rb:

nginx['status'] = {
 "listen_addresses" => ["127.0.0.1"],
 "fqdn" => "dev.example.com",
 "port" => 9999,
 "options" => {
   "access_log" => "on", # Disable logs for stats
   "allow" => "127.0.0.1", # Only allow access from localhost
   "deny" => "all" # Deny access to anyone else
 }
}

To disable the NGINX status endpoint:

nginx['status'] = {
 'enable' => false
}

Save the file and reconfigure GitLab for the changes to take effect.

Configure user permissions for uploads

To ensure user uploads are accessible, add your NGINX user (usually www-data) to the gitlab-www group:

sudo usermod -aG gitlab-www www-data

Templates

The configuration files are similar to the bundled GitLab NGINX configuration, with these differences:

Passenger configuration is used instead of Puma.
HTTPS is not enabled by default, but you can enable it.

After making changes to the NGINX configuration:

For Debian-based systems, restart NGINX:
```
sudo service nginx restart
```
For other systems, refer to your operating system's documentation for the correct command to restart NGINX.

unbundled nginx – using external nginx

To clarify the process and ensure your external NGINX serves GitLab, along with the dit-dah.click and localtransporter.space domains, follow these steps:

Step-by-Step Plan for Multiple Domains with External NGINX

Disable Bundled GitLab NGINX (GitLab Configuration)
Set Up Virtual Hosts for External NGINX (for dit-dah.click and localtransporter.space)
Serve GitLab from External NGINX (for spiffydesign.com or glab.dit-dah.click)
Set Up SSL for All Domains
Reconfigure GitLab and Restart NGINX

Step 1: Disable GitLab’s Bundled NGINX

Open /etc/gitlab/gitlab.rb and add this line to disable the bundled NGINX:

nginx['enable'] = false

Also, configure the external web server user (likely nginx):

web_server['external_users'] = ['nginx']

Then, run:

sudo gitlab-ctl reconfigure

Step 2: Set Up Virtual Hosts for `dit-dah.click` and `localtransporter.space`

Edit the /etc/nginx/conf.d/dit-dah.click.conf for dit-dah.click and /etc/nginx/conf.d/localtransporter.space.conf for localtransporter.space.

old multi site

#react server { listen 195.35.32.187; root /usr/share/nginx/html/dit-dah.click; server_name dit-dah.click;

    #ssl_certificate /etc/letsencrypt/live/dit-dah.click/fullchain.pem;
    #ssl_certificate_key /etc/letsencrypt/live/dit-dah.click/privkey.pem;

    location / {
    try_files $uri $uri/ =404;
   }
}

#admin server { listen 195.35.32.187; root usr/share/nginx/html/localtransporter.space; server_name localtransporter.space;

    #ssl_certificate /etc/letsencrypt/live/dit-dah.click/fullchain.pem;
    #ssl_certificate_key /etc/letsencrypt/live/dit-dah.click/privkey.pem;

    location / {
    try_files $uri $uri/ =404;
   }
}

Example Configuration for `dit-dah.click`:

server {
    listen 80;
    server_name dit-dah.click www.dit-dah.click;
    return 301 https://$host$request_uri;  # Redirect HTTP to HTTPS
}

server {
    listen 443 ssl;
    server_name dit-dah.click www.dit-dah.click;

    ssl_certificate /etc/letsencrypt/live/dit-dah.click/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/dit-dah.click/privkey.pem;

    root /var/www/dit-dah.click;  # Adjust to your React build directory
    index index.html index.htm;

    location / {
        try_files $uri /index.html;
    }
}

Example Configuration for `localtransporter.space`:

server {
    listen 80;
    server_name localtransporter.space www.localtransporter.space;
    return 301 https://$host$request_uri;  # Redirect HTTP to HTTPS
}

server {
    listen 443 ssl;
    server_name localtransporter.space www.localtransporter.space;

    ssl_certificate /etc/letsencrypt/live/localtransporter.space/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/localtransporter.space/privkey.pem;

    root /var/www/localtransporter.space/public;  # Adjust to your Laravel app root
    index index.php index.html index.htm;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;
    }
}

Step 3: Serve GitLab Through External NGINX (for `spiffydesign.com`)

ORIGINAL

#   * Official English Documentation: http://nginx.org/en/docs/
#   * Official Russian Documentation: http://nginx.org/ru/docs/

user nginx;
worker_processes auto;
error_log /var/log/nginx/error.log;
pid /run/nginx.pid;

# Load dynamic modules. See /usr/share/doc/nginx/README.dynamic.
include /usr/share/nginx/modules/*.conf;

events {
    worker_connections 1024;
}

http {
    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;

    sendfile            on;
    tcp_nopush          on;
    tcp_nodelay         on;
    keepalive_timeout   65;
    types_hash_max_size 4096;

    include             /etc/nginx/mime.types;
    default_type        application/octet-stream;

    # Load modular configuration files from the /etc/nginx/conf.d directory.
    # See http://nginx.org/en/docs/ngx_core_module.html#include
    # for more information.
    include /etc/nginx/conf.d/*.conf;

    server {
	listen       80;
        listen       [::]:80;
        server_name  _;
        root         /usr/share/nginx/html;

       	# Load configuration files for the default server block.
        include /etc/nginx/default.d/*.conf;

        error_page 404 /404.html;
        location = /404.html {
        }

	error_page 500 502 503 504 /50x.html;
        location = /50x.html {
        }
    }
#react
#    server {
 #       listen 195.35.32.187;
  #      root /usr/share/nginx/html/dit-dah.click;
   #     server_name dit-dah.click;

       	#ssl_certificate /etc/letsencrypt/live/dit-dah.click/fullchain.pem;
       	#ssl_certificate_key /etc/letsencrypt/live/dit-dah.click/privkey.pem;

    #    location / {
     #   try_files $uri $uri/ =404;
      # }
  #  }
#admin
   # server {
    #    listen  195.35.32.187;
     #   root usr/share/nginx/html/localtransporter.space;
      #  server_name localtransporter.space;

       	#ssl_certificate /etc/letsencrypt/live/dit-dah.click/fullchain.pem;
       	#ssl_certificate_key /etc/letsencrypt/live/dit-dah.click/privkey.pem;

       # location / {
       # try_files $uri $uri/ =404;
      # }
   # }
   
# Settings for a TLS enabled server.
#
#    server {
#        listen       443 ssl http2;
#        listen       [::]:443 ssl http2;
#        server_name  _;
#        root         /usr/share/nginx/html;
#
#        ssl_certificate "/etc/pki/nginx/server.crt";
#        ssl_certificate_key "/etc/pki/nginx/private/server.key";
#        ssl_session_cache shared:SSL:1m;
#        ssl_session_timeout  10m;
#        ssl_ciphers PROFILE=SYSTEM;
#        ssl_prefer_server_ciphers on;
#
#        # Load configuration files for the default server block.
#        include /etc/nginx/default.d/*.conf;
#
#        error_page 404 /404.html;
#            location = /40x.html {
#        }
#
#        error_page 500 502 503 504 /50x.html;
#            location = /50x.html {
#        }
#    }

}

Create a new configuration file for GitLab (for example, /etc/nginx/conf.d/gitlab.conf):

upstream gitlab-workhorse {
    server unix:/var/opt/gitlab/gitlab-workhorse/socket fail_timeout=0;
}

server {
    listen 80;
    server_name spiffydesign.com;
    return 301 https://$host$request_uri;  # Redirect HTTP to HTTPS
}

server {
    listen 443 ssl;
    server_name spiffydesign.com;

    ssl_certificate /etc/letsencrypt/live/spiffydesign.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/spiffydesign.com/privkey.pem;

    location / {
        proxy_pass http://gitlab-workhorse;
        proxy_set_header Host $http_host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Frame-Options SAMEORIGIN;
        proxy_set_header X-Content-Type-Options nosniff;
    }

    access_log /var/log/nginx/gitlab_access.log;
    error_log /var/log/nginx/gitlab_error.log;
}

Step 4: Set Up SSL for All Domains

Use Certbot to configure SSL for each domain.

For dit-dah.click:

sudo certbot --nginx -d dit-dah.click -d www.dit-dah.click

For localtransporter.space:

sudo certbot --nginx -d localtransporter.space -d www.localtransporter.space

For spiffydesign.com (GitLab domain):

sudo certbot --nginx -d spiffydesign.com

This will generate SSL certificates and update the NGINX configuration automatically.

Step 5: Reconfigure GitLab and Restart NGINX

Run the following command to apply the GitLab configuration:

sudo gitlab-ctl reconfigure

Then restart NGINX to apply all changes:

sudo systemctl restart nginx

Now, you should have the following setup:

dit-dah.click serves your React front end.
localtransporter.space serves your Laravel back end.
spiffydesign.com serves the GitLab interface.

Let me know if any specific parts of the setup need more clarification!

Yes, spiffydesign.com will continue working as long as:

GitLab's Bundled NGINX is Disabled: You’ve already disabled the bundled NGINX within GitLab (nginx['enable'] = false), and it should now rely on your external NGINX.
NGINX Configuration for GitLab is Set: If you’ve properly set up the NGINX virtual host configuration for spiffydesign.com (or glab.dit-dah.click), GitLab will continue to work as expected. The configuration will serve GitLab through the external NGINX, handling both HTTP and HTTPS traffic.
SSL Certificates: If you’ve obtained SSL certificates for spiffydesign.com via Certbot (or manually if needed), the HTTPS version of the site will keep running securely.

To confirm it's working, you can test:

sudo systemctl restart nginx
curl -I https://spiffydesign.com

The privileges and setup for secure SSH access.

1. Granting `newuser` SSH Access

By default, any new user can log in via SSH as long as:

They have a home directory (which was created when you added the user).
They have proper file permissions on their home directory and .ssh folder (if you're using key-based authentication).
Root login is disabled (which is good for security), so you will use the regular user for SSH access.

You don't need to grant special privileges to the newuser user just for SSH access. However, here are the key points to ensure it works securely:

Using Password Authentication (default)

If you're allowing SSH logins via password:

newuser just needs to use their password to log in via SSH:
```
ssh newuser@your-server-ip
```

Using Key-Based Authentication (recommended)

Key-based authentication is more secure than password-based authentication.

First, generate an SSH key pair on your local machine (if you don't have one yet):
```
ssh-keygen
```
Copy the public key to the server for the newuser user:
```
ssh-copy-id newuser@your-server-ip
```
This will automatically place the key into /home/newuser/.ssh/authorized_keys and set the correct permissions.

After that, you should be able to SSH into the server without a password:
```
ssh newuser@your-server-ip
```

To use a specific SSH key (like newuser_hostinger_id_rsa) for the newuser user, you can manually copy the public key to the server. Here’s the step-by-step process to achieve this:

1. Ensure the Public Key Exists

First, verify that you have both the private (newuser_hostinger_id_rsa) and public key (newuser_hostinger_id_rsa.pub). If you don’t have the public key, you can generate it from the private key:

ssh-keygen -y -f ~/.ssh/newuser_hostinger_id_rsa > ~/.ssh/newuser_hostinger_id_rsa.pub

This will create the corresponding public key file (newuser_hostinger_id_rsa.pub).

2. Copy the Public Key to the Server Manually

You'll manually add the public key to the newuser user’s ~/.ssh/authorized_keys file on the server.

Option 1: Using `ssh-copy-id` with a Specific Key

If you're using ssh-copy-id, you can specify which key to use by providing the key file using the -i option:

ssh-copy-id -i ~/.ssh/spiffy_hostinger_id_rsa.pub spiffy@your-server-ip

This command will copy your specific public key to the newuser user's ~/.ssh/authorized_keys file.

Option 2: Manually Add the Key to `authorized_keys`

If ssh-copy-id is not available or you prefer to do it manually, follow these steps:

Log in to the server as a user with access:
```
ssh spiffy@your-server-ip
```
Create the .ssh directory (if it doesn't exist):

Run these commands to ensure the .ssh directory is properly set up:
```
mkdir -p ~/.ssh
chmod 700 ~/.ssh
```
Copy the public key manually to the authorized_keys file:

On your local machine, copy the contents of your public key (newuser_hostinger_id_rsa.pub) to the server. You can do this by outputting the public key and adding it to the authorized_keys file on the server. For example:
```
cat ~/.ssh/spiffy_hostinger_id_rsa.pub | ssh spiffy@your-server-ip 'cat >> ~/.ssh/authorized_keys'
```
Set the proper permissions:

Ensure that the authorized_keys file has the correct permissions:
```
chmod 600 ~/.ssh/authorized_keys
```

3. Configure Your SSH Client to Use the Specific Key

Once the public key is installed on the server, you’ll want to configure your local machine’s SSH client to use the newuser_hostinger_id_rsa private key when connecting as the newuser user.

You can specify the key to use directly when connecting:

ssh -i ~/.ssh/newuser_hostinger_id_rsa newuser@your-server-ip

Alternatively, you can add an entry to your ~/.ssh/config file for easier access. Edit the file and add something like this:
```
Host your-server-ip
    User newuser
    IdentityFile ~/.ssh/newuser_hostinger_id_rsa
```
Now, you can just type:
```
ssh your-server-ip
```
And it will automatically use the correct key for the newuser user.

4. Test the Connection

Finally, test that your setup is working by attempting to log in:

ssh spiffy@your-server-ip

If everything is configured correctly, you should be able to log in without a password using your specific SSH key.

Let me know if you need further assistance!

Since you've disabled root login via SSH, this is the recommended workflow:

Log in as newuser:
- SSH into the server as the newuser user (either using a password or SSH key):
```
ssh newuser@your-server-ip
```
Switch to newuser-root for Administrative Tasks: Once logged in as newuser, you can switch to newuser-root using the su command (if newuser-root is an account with administrative privileges) or use sudo:
- Switch to newuser-root:
```
su - newuser-root
```
  Enter the password for newuser-root when prompted.
- Alternatively, if newuser-root has sudo privileges, you can perform admin tasks directly as newuser using sudo:
```
sudo command_to_run_as_root
```

3. Grant `newuser` User `sudo` Privileges (Optional)

If you want newuser to have administrative privileges, you can add the newuser user to the wheel or sudo group. This allows newuser to use sudo to execute commands with root privileges:

sudo usermod -aG wheel newuser  # or use 'sudo' group depending on your system

This will allow newuser to run sudo commands directly after logging in via SSH. Example:

ssh newuser@your-server-ip
sudo whoami   # should return 'root'

4. Disable Password Authentication (Optional, for Key-based Security)

If you're using SSH key-based authentication, it’s a good idea to disable password authentication entirely to improve security:

Edit the SSH configuration file /etc/ssh/sshd_config:
```
sudo nano /etc/ssh/sshd_config
```
Set the following options (if not already set):
```
PasswordAuthentication no
PermitRootLogin no
```
Restart SSH to apply the changes:
```
sudo systemctl restart sshd
```

This will ensure that only users with a valid SSH key can log in, and root login will still be disabled.

Recap:

You log in as the newuser user via SSH (with password or key).
If you need root privileges, you can either switch to newuser-root using su - newuser-root or configure newuser to use sudo directly.
For better security, prefer key-based SSH login and disable password authentication.

DitDah Info

modify rules

Sites

Step-by-step instructions:

How it works:

Sending Files to Live (smp staging)

1. Use a Non-Root User with sudo Permissions

Steps:

2. Enable sudo for Secure File Transfer

Summary:

Other setting for gandolf

Server Settings

Nginx

dit-dah.click.conf gitlab.conf localtransporter.space.conf php-fpm.conf

/etc/nginx/conf.d/dit-dah.click.conf

spiffydesign / pages attempt v1

localtransporter.space

test nginx (after changes)

restart nginx (apply changes)

Gitlab

Config

Basic Setup

1. Set Up GitLab on AlmaLinux

Install the Dependencies:

Install GitLab:

Configure GitLab:

2. SSL Setup (Optional)

3. Setting Up DNS

4. User Management

5. Backup & Restore (Optional)

6. CI/CD Pipeline Setup

Laravel .gitlab-ci.yml:

React .gitlab-ci.yml:

7. Optimizing Performance

Error Logs

1. NGINX Error Logs

2. GitLab Logs

3. DNS Logs

4. PHP Error Logs

5. Database Error Logs

MySQL / MariaDB:

PostgreSQL:

Summary of Commands:

pages.spiffydesign.com – ssl stuff

Let's address your questions:

1. Should you break up the configuration into separate files?

2. Why is there a proxy_pass http://gitlab-pages in the location block?

Issues you're experiencing:

Fixing the SSL certificate issue:

Firewalld

Updated

Useful Commands

packet forwarding

1. Check the Status of firewalld:

2. Start/Stop/Restart firewalld:

3. Enable/Disable firewalld to Start at Boot:

4. List All Active Zones and Rules:

5. Add/Remove/Allow Ports:

6. Add/Remove Services:

7. Reload firewalld:

8. List Open Ports:

9. Check Zone Information:

10. Allow/Block IP Address:

11. Check Firewall Rules:

Gitlab runner

1. Registering an Instance Runner (for all projects)

2. Registering a Project Runner (for a specific project)

3. Assigning Runners to Groups

4. Verify Runner Registration

Full complete backup

1. Backup Files & Directories

2. Backup Databases

For MySQL/MariaDB:

For PostgreSQL (if used by GitLab or other applications):

3. GitLab Backup

4. Backup Web Server Configurations

5. Backup SSL Certificates

6. Backup System Configuration (Optional)

Backup crontab:

Backup Firewall rules:

1. Use a Non-Root User with `sudo` Permissions

2. Enable `sudo` for Secure File Transfer

Laravel `.gitlab-ci.yml`:

React `.gitlab-ci.yml`:

2. Why is there a `proxy_pass http://gitlab-pages` in the location block?

Configure GitLab trusted proxies and NGINX `real_ip` module

Configure `robots.txt`

Step 2: Set Up Virtual Hosts for `dit-dah.click` and `localtransporter.space`

Example Configuration for `dit-dah.click`:

Example Configuration for `localtransporter.space`:

Step 3: Serve GitLab Through External NGINX (for `spiffydesign.com`)

Configure GitLab trusted proxies and NGINX `real_ip` module

Configure `robots.txt`