Stack blog post

0x0B-ssh/0-use_a_private_key

@@ -1,3 +1,3 @@
 #!/usr/bin/env bash
 # Connecting to a server through a private key
-ssh -i ~/.ssh/holberton ubuntu@35.231.33.237
+ssh -i ~/.ssh/school ubuntu@35.231.33.237

0x0B-ssh/1-create_ssh_key_pair

@@ -1,3 +1,3 @@
 #!/usr/bin/env bash
 # Creates an RSA key pair
-ssh-keygen -t rsa -f holberton -b 4096 -N betty
+ssh-keygen -t rsa -f school -b 4096 -N betty

0x0B-ssh/2-ssh_config

@@ -52,5 +52,5 @@ Host *
     HashKnownHosts yes
     GSSAPIAuthentication yes
     GSSAPIDelegateCredentials no
-    IdentityFile ~/.ssh/holberton
+    IdentityFile ~/.ssh/alx
     PasswordAuthentication no

0x0B-ssh/4-puppet_ssh_config.pp

@@ -1,6 +1,6 @@
 # Changes SSH config file
 exec { 'echo':
   path    => 'usr/bin:/bin',
-  command => 'echo "    IdentityFile ~/.ssh/holberton\n    PasswordAuthentication no" >> /etc/ssh/ssh_config',
+  command => 'echo "    IdentityFile ~/.ssh/school\n    PasswordAuthentication no" >> /etc/ssh/ssh_config',
   returns => [0,1],
-}
+}

0x11-what_happens_when_your_type_google_com_in_your_browser_and_press_enter/0-blog_post

@@ -0,0 +1,54 @@
+
+**Demystifying the Journey of a Web Request: What Happens When You Type "https://www.google.com" in Your Browser**
+
+*Introduction:*
+
+The seamless experience of browsing the web often conceals the intricate processes happening behind the scenes. When you type "https://www.google.com" into your browser's address bar and hit Enter, it triggers a fascinating journey involving various components of the web stack. In this article, we will unravel this journey, step by step, shedding light on the magic that brings your favorite websites to your screen.
+
+**Step 1: DNS Request:**
+
+Before your browser can connect to Google's servers, it needs to find out where they are located. This is where the Domain Name System (DNS) comes into play. When you hit Enter, your computer sends a DNS request to a DNS server, asking for the IP address associated with "www.google.com." This server may cache the IP or query other DNS servers to find the answer.
+
+**Step 2: TCP/IP Connection:**
+
+Once your computer knows where to find Google's servers, it initiates a TCP/IP connection to the provided IP address. This connection involves a three-way handshake, where both your computer and Google's servers exchange information to establish a reliable connection.
+
+**Step 3: Firewall Security:**
+
+As the connection is established, it passes through your computer's firewall. Firewalls are like security guards, monitoring and filtering incoming and outgoing traffic. They ensure that only safe and authorized data can flow in and out of your computer.
+
+**Step 4: HTTPS/SSL Encryption:**
+
+Security is paramount on the web, especially when transmitting sensitive data. Google uses HTTPS (Hypertext Transfer Protocol Secure) to encrypt the data exchanged between your browser and its servers. During the SSL (Secure Sockets Layer) handshake, a secure connection is established, safeguarding your information from prying eyes.
+
+**Step 5: Load-Balancer:**
+
+Google serves millions of users worldwide, and to manage this load efficiently, they employ load balancers. These smart devices distribute incoming traffic across multiple servers, ensuring optimal performance, redundancy, and high availability.
+
+**Step 6: Web Server:**
+
+The web server is where the real action happens. It receives your request and responds by sending back the web page you requested. Google uses powerful web servers like Apache or Nginx to handle these requests with lightning speed.
+
+**Step 7: Application Server:**
+
+Not all content on the web is static. Dynamic websites, like Google, rely on application servers to generate content on the fly. These servers process your request, execute scripts, and fetch data from databases or other sources to create the web page you see.
+
+**Step 8: Database Interaction:**
+
+Behind the scenes, Google relies on extensive databases to provide search results, personalized recommendations, and more. The application server communicates with these databases to fetch relevant information, ensuring that you receive the most up-to-date content.
+
+**Conclusion:**
+
+The journey of a web request, from DNS resolution to database interaction, involves a symphony of components working in harmony. Each plays a vital role in delivering a seamless browsing experience. Understanding these processes can deepen our appreciation for the technology that powers the web.
+
+**Share Your Insights:**
+
+Do you have any questions or insights about the inner workings of the web stack? Feel free to share them in the comments below!
+
+**Share the URL:**
+
+Read the full article on Medium: [Link to Your Blog Post]
+
+---
+
+This sample blog post provides a simplified explanation of what happens when you type "https://www.google.com" in your browser. You can expand on each step with more technical details and examples to create a more in-depth article.

0x19-postmortem/README.md

@@ -1 +1,43 @@
-# Postmortem
+# Postmortem
+Sample Postmortem: Outage Resolution
+
+## Issue Summary:
+
+Duration:
+Start Time: September 15, 2023, 14:00 UTC
+End Time: September 15, 2023, 17:30 UTC
+Impact:
+Service Affected: E-commerce Website
+Users Affected: 80% of users experienced slow page loading and checkout failures.
+##Root Cause:
+
+The root cause of the outage was an unexpected surge in traffic due to a flash sale event. Our load balancer's auto-scaling mechanism failed to respond adequately, causing server congestion.
+
+## Timeline:
+
+Detection Time: September 15, 2023, 14:15 UTC
+Detected by automated monitoring alert for high server load.
+Actions Taken:
+Investigated server logs and identified increased traffic.
+Assumed it was a DDoS attack initially.
+Misleading Paths:
+Focused on network security logs.
+Engaged the security team unnecessarily.
+Escalation:
+Incident escalated to the DevOps team.
+SREs involved due to the severity of the issue.
+Resolution:
+Scaled server capacity manually to accommodate traffic.
+Implemented rate limiting to mitigate impact.
+Regular updates were posted on the website to keep users informed.
+Root Cause and Resolution:
+
+The issue was caused by a surge in genuine user traffic, not a DDoS attack. Our auto-scaling algorithm was not optimized to handle such rapid traffic spikes. To resolve it, we manually scaled up server capacity and adjusted the auto-scaling algorithm parameters to respond more effectively to sudden traffic surges.
+
+## Corrective and Preventative Measures:
+
+Optimize auto-scaling parameters for more dynamic scaling.
+Implement more robust traffic monitoring and alerting systems.
+Enhance communication protocols for cross-functional incident response.
+Establish a post-incident review process to capture lessons learned.
+This outage highlighted the importance of continuously improving our infrastructure's scalability and incident response capabilities. We are committed to implementing these measures to ensure uninterrupted service for our users.