Differences

This shows you the differences between two versions of the page.

--- deploy_laravel_application_on_a_linux_vds [2025/05/13 07:05] – [Safer & More Standard Approach] kkaragoz
+++ deploy_laravel_application_on_a_linux_vds [2025/05/13 07:48] (current) – kkaragoz
@@ Line 95: / Line 95: @@
 </code>
 ===== 3- Bind a Domain =====
-Connect a domain to a server can be done by simply changing the DNS records of the domain. Lets assume the VDS server's IP address as 100.45.213.77. Here is an example DNS record table:
+Connect a domain to a server can be done by simply changing the DNS records of the domain. You will typically manage these records through your **domain registrar's website** or a **separate DNS hosting provider's control panel**. Lets assume the VDS server's IP address as 100.45.213.77.
+Here is an example DNS record table you might configure:
 ^ Type ^ Name ^ Content       ^ TTL  ^
@@ Line 103: / Line 105: @@
 | AAAA | @    | Public IPv6   | Auto |
-  - @ stands for the full domain address (FQDN) like ''%%vicky.com%%''.
+  * ''%%@%%'' stands for the base domain address (often called the root domain or FQDN) like ''%%vicky.com%%''.
-  - For IPv6 you should create AAAA record.
+  * For IPv6, you should create an AAAA record pointing to your server's public IPv6 address.
-  - * stands for the whole subdomains like ''%%*.vicky.com%%''.
+  * ''%%*%%'' stands for a wildcard, representing all subdomains that don't have a specific A record defined, like ''%%anything.vicky.com%%''.
-  - sub1: I wrote sub1 but it can be anything. I'll assume ''%%secret%%'' instead of ''%%sub1%%'', this record stands for ''%%secret.vicky.com%%''.
+  * ''%%sub1%%'': I wrote sub1 but it can be anything. I'll assume ''%%secret%%'' instead of ''%%sub1%%'', this record stands for ''%%secret.vicky.com%%''.
-  - You can add more subdomains as I showed on the table by ''%%sub1%%''
+  * You can add more specific subdomains as needed by creating additional A records.
+  * ''%%TTL%%'' (Time To Live) is the duration that DNS resolvers are told to cache your record before requesting a fresh copy. 'Auto' is usually fine, letting the provider decide.
+{{ :screenshot_20250512_121756.png?400 | Example screenshot of a DNS configuration interface (placeholder)}}
+You don't have to add explicit records for every single subdomain if you use the ''%%*%%'' wildcard record. However, note that an explicit record for a specific subdomain will take precedence over the wildcard record.
-{{ :screenshot_20250512_121756.png?400 |}}
+**DNS Propagation:** After saving your DNS changes, it can take some time for these updates to propagate across the internet's DNS servers. This process, called propagation, can range from a few minutes to several hours, sometimes up to 48 hours, though typically faster for A records. You can use online tools or command-line utilities like ''%%dig%%'' or ''%%nslookup%%'' to check the status of your DNS propagation from different locations.
-You don't have to add record of the subdomain like sub1, sub2, sub3, etc. When you add '*' symbol and create a record, it represent all subdomains that you will create.
+Once these DNS records are pointing to your server's IP address, you will configure your web server (Nginx) in the next section to respond to requests for these domain names.
 ===== 4- Nginx Installation & Configuration =====
 [[https://nginx.org|nginx]] ("engine x") is an HTTP web server, reverse proxy, content cache, load balancer, TCP/UDP proxy server, and mail proxy server. Before nginx installation we should be ensure about apache/apache2 is not running and enabled.
@@ Line 238: / Line 245: @@
 ===== 5- SSL Certification: Certbot =====
-It is time to apply SSL certificates of domains. I use "**Full SSL Encryption**" on CloudFlare for my domain addresses.To install SSL certificates firstly check for updates:
+It is essential to secure your application with SSL/TLS encryption to protect data in transit and build user trust. [[https://letsencrypt.org/|Let's Encrypt]] provides free, automated, and open Certificate Authorities, and [[https://certbot.eff.org|Certbot]] is a tool to easily obtain and manage these certificates, especially for web servers like Nginx.
+You mentioned using "**Full SSL Encryption**" on Cloudflare. This means Cloudflare encrypts the connection between the user and Cloudflare, and ''%%also%%'' encrypts the connection between Cloudflare and your origin server. For Cloudflare's "Full SSL" to work correctly, your server ''%%still needs a valid SSL certificate%%''. Certbot will provide this valid certificate.
+To install Certbot and the Nginx plugin, first ensure your package list is up-to-date:
 <code bash>
 sudo apt update && sudo apt upgrade
 </code>
-We are ready to install [[https://certbot.eff.org|Certbot]]:
+Now we are ready to install Certbot:
 <code bash>
 sudo apt install certbot python3-certbot-nginx
 </code>
-After installation is completed, lets move to the ''%%sites-enabled%%'' path again.
+After installation is completed, we will use the Certbot Nginx plugin, which can automatically configure SSL for domains specified in your Nginx configuration files located in ''%%/etc/nginx/sites-enabled/%%''.
 <code bash>
-cd /etc/nginx/sites-enabled/
+sudo certbot --nginx
 </code>
+When you run this command, Certbot will:
+  * Prompt you for an email address for urgent renewal or security notices.
+  * Ask you to agree to the terms of service.
+  * Scan your Nginx configuration files for ''%%server_name%%'' directives to find the domains you want to secure.
+  * Present a list of identified domains and ask you to select which ones you want certificates for.
+  * Communicate with the Let's Encrypt servers to verify domain ownership (usually by serving a temporary file through your web server).
+  * If successful, it will obtain the SSL certificates.
+  * **Automatically modify** your Nginx configuration file(s) in ''%%/etc/nginx/sites-enabled/%%'' to:
+    * Add the ''%%listen 443 ssl;%%'' directive for HTTPS.
+    * Point to the correct ''%%ssl_certificate%%'' and ''%%ssl_certificate_key%%'' files it just obtained.
+    * (Optionally) Ask if you want to redirect HTTP traffic (port 80) to HTTPS (port 443). It is highly recommended to choose the redirect option for better security and SEO.
+  * **Automatically set up a renewal mechanism** (usually a systemd timer or cron job) that will attempt to renew your certificates before they expire (Let's Encrypt certificates are valid for 90 days).
-Then run the following command for automatic SSL certificate process:
+After Certbot completes its process and potentially modifies your Nginx configuration, it will usually handle reloading or restarting Nginx itself. However, it's a good practice to test the Nginx configuration and explicitly reload to be sure:
 <code bash>
-sudo certbot --nginx
+sudo nginx -t # Test Nginx configuration for syntax errors
-</code>
+sudo systemctl reload nginx # Reload Nginx to apply changes
-Enter the related fields like email, confirm terms, select domains, etc. Then Certbot will notify about the certification status. If it's done, you can reload the nginx again.
-<code bash>
-sudo systemctl reload nginx
 </code>
+You can verify that SSL is working by visiting your domain(s) in a web browser and checking for the padlock icon in the address bar and ensuring the URL starts with ''%%https://%%''.
+**Important:** The ''%%certbot --nginx%%'' command only needs to be run the first time to obtain the certificate and configure Nginx. Certbot's automatic renewal process handles keeping your certificates up-to-date in the future.
 ===== 6- PHP Installation =====
 Let's proceed to uninstall the currently installed PHP packages and then install a specific version (like PHP 8.2) cleanly using the Ondřej Surý PPA, which is the recommended way for up-to-date PHP versions on Ubuntu/Debian.
@@ Line 513: / Line 537: @@
 </code>
-Using chmod -R 0777 is indeed a significant security risk because it grants full read, write, and execute permissions to all users on the system for those directories and everything within them. This means if any other user account on your server were compromised, they could potentially modify or inject malicious files into your application's storage or cache directories.
+Using ''%%chmod -R 0777%%'' is indeed a significant security risk because it grants full read, write, and execute permissions to all users on the system for those directories and everything within them. This means if any other user account on your server were compromised, they could potentially modify or inject malicious files into your application's storage or cache directories.
-==== Safer & More Standard Approach ====
+==== Laravel - Safer & More Standard Approach ====
 The goal is to grant write permissions only to the specific user or group that the web server (Nginx/PHP-FPM) runs as, while keeping ownership and primary access with your deployment user.
@@ Line 573: / Line 597: @@
 sudo chmod g+s /var/www/vicky.com/bootstrap/cache
 </code>
+==== Static App - Appropriate Permissions ====
+Generally do not need to set the same 775 group write permissions or change the group ownership to www-data for your static application's folder. The write operations happen during the deployment process when you, as the deployment user (vicky), build the app locally (or on the server) and copy the output files to the server directory ''%%/var/www/static-page.vicky.com%%''.
+The goal for static assets is to allow the web server (www-data user) to read and execute/navigate through the directories to find the files, while ensuring your deployment user (vicky) has full control to update the files, and restricting write access for others.
+A standard and safe permission set for static web content folders is:
+**Ownership**: The files and directories should be owned by your deployment user (vicky) and their primary group (vicky).
+<code bash>
+sudo chown -R vicky:vicky /var/www/static-page.vicky.com
+</code>
+**Permissions**:
+  * Directories: 755 (Owner: Read, Write, Execute; Group: Read, Execute; Others: Read, Execute). This allows the owner (vicky) full control and allows the web server user (www-data - which falls under "Others" unless specifically added to vicky's group) to navigate into directories and read their contents.
+  * Files: 644 (Owner: Read, Write; Group: Read; Others: Read). This allows the owner (vicky) to read and modify the files and allows the web server user (www-data) to read the files.
+You can set these permissions recursively:
+<code bash>
+# Ensure ownership is correct
+sudo chown -R vicky:vicky /var/www/static-page.vicky.com
+# Set directory permissions to 755
+sudo find /var/www/static-page.vicky.com -type d -exec chmod 755 {} +
+# Set file permissions to 644
+sudo find /var/www/static-page.vicky.com -type f -exec chmod 644 {} +
+</code>
+A slightly simpler, though less precise, common alternative for static sites is just:
+<code bash>
+# Ensure ownership is correct
+sudo chown -R vicky:vicky /var/www/static-page.vicky.com
+# Set recursive permissions to 755 (grants execute to files, which is harmless for static assets)
+sudo chmod -R 755 /var/www/static-page.vicky.com
+</code>
 ===== 11- Setup the Application =====
@@ Line 587: / Line 652: @@
 php artisan migrate
 </code>