Dit-Dah

/ all-scribbly, coding / By

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:

  1. 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

  2. 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...}

  3. Save and exit the file:After adding the rule, save and close the configuration file.

  4. 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

  5. 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)

cp -r /Users/spiffy/Documents/nsgandolf/dit-dah/gandolf-smp-dit-dah/build/* root@195.35.32.187:/usr/share/nginx/html/localtransporter.space/cp -r /Users/spiffy/Documents/nsgandolf/dit-dah/sitenameh/build/* root@195.35.32.187:/usr/share/nginx/html/localtransporter.space/ or spiffydesign.com/ or dit-dah.click
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 HTTPSserver {    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 HTTPSserver {    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 Pagespages_external_url “https://pages.spiffydesign.com“gitlab_pages[‘enable’] = truegitlab_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.comupstream gitlab-workhorse {    server 127.0.0.1:8181 fail_timeout=0;}# GitLab Pages backend - pages.spiffydesign.comupstream 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.clickserver {    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.comupstream gitlab-pages {    server 127.0.0.1:8090 fail_timeout=0;  # GitLab Pages running on port 8090}# Main GitLab instance at spiffydesign.comserver {    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.comserver {    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.comupstream gitlab-workhorse {    server 127.0.0.1:8181 fail_timeout=0;}# GitLab Pages backend - pages.spiffydesign.comupstream gitlab-pages {    server 127.0.0.1:8090 fail_timeout=0;  # GitLab Pages running on port 8090}# Main GitLab instance at spiffydesign.comserver {    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.comserver {    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.comupstream 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 -tRESPONSE:nginx: the configuration file /etc/nginx/nginx.conf syntax is oknginx: configuration file /etc/nginx/nginx.conf test is successful

restart nginx (apply changes)

sudo systemctl restart nginxORsudo nginx -s reload  // reload nginx

Gitlab

Config
sudo nano /etc/gitlab/gitlab.rb// then run to reconfiguresudo 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 perlsudo systemctl enable sshdsudo systemctl start sshdsudo firewall-cmd --permanent --add-service=httpsudo firewall-cmd --permanent --add-service=httpssudo firewall-cmd --reload
Install GitLab:
curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.rpm.sh | sudo bashsudo 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:

  1. Modify the GitLab configuration:
external_url "https://glab.dit-dah.click"letsencrypt['enable'] = true
  1. 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  - testinstall:  stage: install  script:    - composer installtest:  stage: test  script:    - ./vendor/bin/phpunit
React .gitlab-ci.yml:
stages:  - buildbuild:  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 logsudo tail -f /var/log/nginx/error.log# View NGINX access logsudo 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 GitLabsudo tail -f /var/log/nginx/gitlab_error.log# For GitLab Pagessudo 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 logssudo gitlab-ctl tail gitlab-rails# GitLab Workhorse logssudo gitlab-ctl tail gitlab-workhorse# GitLab NGINX logssudo gitlab-ctl tail nginx# GitLab Pages logssudo gitlab-ctl tail gitlab-pages# GitLab Sidekiq logssudo 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 systemdsudo journalctl -u systemd-resolved

For DNSMasq (if you’re using it):

# DNSMasq logssudo 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.iniphp -i | grep error_log

5. Database Error Logs

MySQL / MariaDB:
# For MariaDB or MySQL error logssudo 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 logssudo tail -f /var/log/nginx/error.log# GitLab logssudo gitlab-ctl tail# DNS logs (BIND)sudo tail -f /var/log/syslog | grep named# PHP logssudo tail -f /var/log/php_errors.log# MySQL/MariaDB error logssudo 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:

  1. 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

  2. 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.

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

    sudo nginx -t  # Check for syntax errorssudo 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=publicpublic (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=publicpublic (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=publicsudo firewall-cmd --remove-port=21/tcp --zone=public --permanent  # Remove FTP port if not neededsudo firewall-cmd --add-port=21/tcp --zone=public --permanent  # Remove FTP port if not neededsudo 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 --permanentsudo 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:

  1. Instance Runners: These runners are available to all projects and groups in your GitLab instance.
  2. Group Runners: These are shared runners across all projects within a specific group.
  3. 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.

  1. 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-amd64sudo chmod +x /usr/local/bin/gitlab-runnersudo useradd --comment 'GitLab Runner' --create-home gitlab-runner --shell /bin/bashsudo /usr/local/bin/gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runnersudo /usr/local/bin/gitlab-runner registersudo /usr/local/bin/gitlab-runner start

  2. Get the registration token:

    • Go to your GitLab Admin Area (spiffydesign.com/admin/runners).
    • Copy the Instance Runner registration token.

  3. 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)

  1. 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.

  2. 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:

  1. Files & Directories: For each website’s files and application data (e.g., HTML, CSS, JS, config files).
  2. Databases: Any MySQL, MariaDB, or PostgreSQL databases.
  3. GitLab Backup: GitLab repositories, configuration, and data.
  4. Nginx/Apache configuration: Your web server configurations.
  5. SSL Certificates: Any SSL certificates and their private keys.
  6. 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:

  1. Extract the tarball to the correct locations.
  2. Restore the databases using mysql or psql.
  3. Restore GitLab using its restore command: gitlab-backup restore.
  4. 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.

Related Posts