mirror of
https://github.com/linkedin/school-of-sre
synced 2026-01-20 15:38:03 +00:00
Deployed 9d7218b with MkDocs version: 1.1.2
This commit is contained in:
Kalyanasundaram Somasundaram
@@ -1164,11 +1164,11 @@
|
||||
<ul>
|
||||
<li>
|
||||
<p><strong>Read Your Own Writes Consistency</strong></p>
|
||||
<p>A client will see his updates immediately after they are written. The reads can hit nodes other than the one where it was written. However he might not see updates by other clients immediately. </p>
|
||||
<p>Clients will see their updates immediately after they are written. The reads can hit nodes other than the one where it was written. However they might not see updates by other clients immediately.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p><strong>Session Consistency</strong></p>
|
||||
<p>A client will see the updates to his data within a session scope. This generally indicates that reads & writes occur on the same server. Other clients using the same nodes will receive the same updates. </p>
|
||||
<p>Clients will see the updates to their data within a session scope. This generally indicates that reads & writes occur on the same server. Other clients using the same nodes will receive the same updates.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p><strong>Casual Consistency</strong></p>
|
||||
|
||||
@@ -1642,10 +1642,10 @@ commands on your own.</p>
|
||||
<h2 id="usergroup-management">User/Group Management</h2>
|
||||
<ul>
|
||||
<li>
|
||||
<p>Each user in Linux has an associated user ID called UID attached to him</p>
|
||||
<p>Users in Linux has an associated user ID called UID attached to them.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Each user also has a home directory and a login shell associated with him/her</p>
|
||||
<p>Users also has a home directory and a login shell associated with them.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>A group is a collection of one or more users. A group makes it easier to share permissions among a group of users.</p>
|
||||
|
||||
File diff suppressed because one or more lines are too long
@@ -1523,7 +1523,7 @@ Correspondence between layers of the TCP/IP architecture and the OSI model. Also
|
||||
<h3 id="pgp-smime-email-security">PGP & S/MIME : Email Security</h3>
|
||||
<ul>
|
||||
<li>There are several security protocols at the application layer. The most used of these protocols are email security protocols namely PGP and S/MIME.</li>
|
||||
<li>SMTP (“Simple Mail Transfer Protocol”) is used for sending and delivering from a client to a server via port 25: it’s the outgoing server. On the contrary, POP (“Post Office Protocol”) allows the user to pick up the message and download it into his inbox: it’s the incoming server. The latest version of the Post Office Protocol is named POP3, and it’s been used since 1996; it uses port 110</li>
|
||||
<li>SMTP (“Simple Mail Transfer Protocol”) is used for sending and delivering from a client to a server via port 25: it’s the outgoing server. On the contrary, POP (“Post Office Protocol”) allows the users to pick up the message and download it into their inbox: it’s the incoming server. The latest version of the Post Office Protocol is named POP3, and it’s been used since 1996; it uses port 110</li>
|
||||
</ul>
|
||||
<p>PGP</p>
|
||||
<ul>
|
||||
@@ -1540,9 +1540,9 @@ Correspondence between layers of the TCP/IP architecture and the OSI model. Also
|
||||
</ul>
|
||||
<p>S/MIME</p>
|
||||
<ul>
|
||||
<li>SMTP can only handle 7-bit ASCII text (You can use UTF-8 extensions to alleviate these limitations, ) messages. While POP can handle other content types besides 7-bit ASCII, POP may, under a common default setting, download all the messages stored in the mail server to the user's local computer. After that, if POP removes these messages from the mail server. This makes it difficult for the user to read his messages from multiple computers.</li>
|
||||
<li>SMTP can only handle 7-bit ASCII text (You can use UTF-8 extensions to alleviate these limitations, ) messages. While POP can handle other content types besides 7-bit ASCII, POP may, under a common default setting, download all the messages stored in the mail server to the user's local computer. After that, if POP removes these messages from the mail server. This makes it difficult for the users to read their messages from multiple computers.</li>
|
||||
<li>The Multipurpose Internet Mail Extension protocol (MIME) was designed to support sending and receiving email messages in various formats, including nontext files generated by word processors, graphics files, sound files, and video clips. Moreover, MIME allows a single message to include mixed types of data in any combination of these formats.</li>
|
||||
<li>The Internet Mail Access Protocol (IMAP), operated on TCP port 143(only for non-encrypted), stores (Configurable on both server & client just like PoP) incoming email messages in the mail server until the user deletes them deliberately. This allows the user to access his mailbox from multiple machines and download messages to a local machine without deleting it from the mailbox in the mail server.</li>
|
||||
<li>The Internet Mail Access Protocol (IMAP), operated on TCP port 143(only for non-encrypted), stores (Configurable on both server & client just like PoP) incoming email messages in the mail server until the user deletes them deliberately. This allows the users to access their mailbox from multiple machines and download messages to a local machine without deleting it from the mailbox in the mail server.</li>
|
||||
</ul>
|
||||
<p>SSL/TLS</p>
|
||||
<ul>
|
||||
|
||||
@@ -1604,12 +1604,12 @@ the typical time to live (TTL) for cached entries is a couple of hours, thereby
|
||||
<li>Injecting bogus route advertising information into the BGP-distributed routing database by malicious sources, accidentally or routers can disrupt Internet backbone operations. </li>
|
||||
<li>Blackholing traffic:</li>
|
||||
<li>Blackhole route is a network route, i.e., routing table entry, that goes nowhere and packets matching the route prefix are dropped or ignored. Blackhole routes can only be detected by monitoring the lost traffic.</li>
|
||||
<li>Blackhole routes are the best defence against many common viral attacks where the traffic is dropped from infected machines to/from command & control masters.</li>
|
||||
<li>Blackhole routes are the best defence against many common viral attacks where the traffic is dropped from infected machines to/from command & control hosts.</li>
|
||||
<li>
|
||||
<p>Infamous BGP Injection attack on Youtube</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>EX: In 2008, Pakistan decided to block YouTube by creating a BGP route that led into a black hole. Instead, this routing information got transmitted to a hong kong ISP and from there accidentally got propagated to the rest of the world meaning millions were routed through to this black hole and therefore unable to access YouTube.</p>
|
||||
<p>Ex: In 2008, Pakistan decided to block YouTube by creating a BGP route that led into a black hole. Instead, this routing information got transmitted to a hong kong ISP and from there accidentally got propagated to the rest of the world meaning millions were routed through to this black hole and therefore unable to access YouTube.</p>
|
||||
</li>
|
||||
<li>Potentially, the greatest risk to BGP occurs in a denial of service attack in which a router is flooded with more packets than it can handle. Network overload and router resource exhaustion happen when the network begins carrying an excessive number of BGP messages, overloading the router control processors, memory, routing table and reducing the bandwidth available for data traffic.</li>
|
||||
<li>Refer: <a href="https://medium.com/bugbountywriteup/bgp-the-weak-link-in-the-internet-what-is-bgp-and-how-do-hackers-exploit-it-d899a68ba5bb">https://medium.com/bugbountywriteup/bgp-the-weak-link-in-the-internet-what-is-bgp-and-how-do-hackers-exploit-it-d899a68ba5bb</a></li>
|
||||
|
||||
92
sitemap.xml
92
sitemap.xml
@@ -1,187 +1,187 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2020-11-30</lastmod>
|
||||
<lastmod>2020-12-03</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2020-11-30</lastmod>
|
||||
<lastmod>2020-12-03</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2020-11-30</lastmod>
|
||||
<lastmod>2020-12-03</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2020-11-30</lastmod>
|
||||
<lastmod>2020-12-03</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2020-11-30</lastmod>
|
||||
<lastmod>2020-12-03</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2020-11-30</lastmod>
|
||||
<lastmod>2020-12-03</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2020-11-30</lastmod>
|
||||
<lastmod>2020-12-03</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2020-11-30</lastmod>
|
||||
<lastmod>2020-12-03</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2020-11-30</lastmod>
|
||||
<lastmod>2020-12-03</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2020-11-30</lastmod>
|
||||
<lastmod>2020-12-03</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2020-11-30</lastmod>
|
||||
<lastmod>2020-12-03</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2020-11-30</lastmod>
|
||||
<lastmod>2020-12-03</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2020-11-30</lastmod>
|
||||
<lastmod>2020-12-03</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2020-11-30</lastmod>
|
||||
<lastmod>2020-12-03</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2020-11-30</lastmod>
|
||||
<lastmod>2020-12-03</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2020-11-30</lastmod>
|
||||
<lastmod>2020-12-03</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2020-11-30</lastmod>
|
||||
<lastmod>2020-12-03</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2020-11-30</lastmod>
|
||||
<lastmod>2020-12-03</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2020-11-30</lastmod>
|
||||
<lastmod>2020-12-03</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2020-11-30</lastmod>
|
||||
<lastmod>2020-12-03</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2020-11-30</lastmod>
|
||||
<lastmod>2020-12-03</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2020-11-30</lastmod>
|
||||
<lastmod>2020-12-03</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2020-11-30</lastmod>
|
||||
<lastmod>2020-12-03</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2020-11-30</lastmod>
|
||||
<lastmod>2020-12-03</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2020-11-30</lastmod>
|
||||
<lastmod>2020-12-03</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2020-11-30</lastmod>
|
||||
<lastmod>2020-12-03</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2020-11-30</lastmod>
|
||||
<lastmod>2020-12-03</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2020-11-30</lastmod>
|
||||
<lastmod>2020-12-03</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2020-11-30</lastmod>
|
||||
<lastmod>2020-12-03</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2020-11-30</lastmod>
|
||||
<lastmod>2020-12-03</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2020-11-30</lastmod>
|
||||
<lastmod>2020-12-03</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2020-11-30</lastmod>
|
||||
<lastmod>2020-12-03</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2020-11-30</lastmod>
|
||||
<lastmod>2020-12-03</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2020-11-30</lastmod>
|
||||
<lastmod>2020-12-03</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2020-11-30</lastmod>
|
||||
<lastmod>2020-12-03</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2020-11-30</lastmod>
|
||||
<lastmod>2020-12-03</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2020-11-30</lastmod>
|
||||
<lastmod>2020-12-03</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2020-11-30</lastmod>
|
||||
<lastmod>2020-12-03</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2020-11-30</lastmod>
|
||||
<lastmod>2020-12-03</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2020-11-30</lastmod>
|
||||
<lastmod>2020-12-03</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2020-11-30</lastmod>
|
||||
<lastmod>2020-12-03</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2020-11-30</lastmod>
|
||||
<lastmod>2020-12-03</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2020-11-30</lastmod>
|
||||
<lastmod>2020-12-03</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2020-11-30</lastmod>
|
||||
<lastmod>2020-12-03</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2020-11-30</lastmod>
|
||||
<lastmod>2020-12-03</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url><url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2020-11-30</lastmod>
|
||||
<lastmod>2020-12-03</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
</urlset>
|
||||
BIN
sitemap.xml.gz
BIN
sitemap.xml.gz
Binary file not shown.
Binary file not shown.
|
Before Width: | Height: | Size: 47 KiB After Width: | Height: | Size: 121 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 33 KiB After Width: | Height: | Size: 75 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 28 KiB After Width: | Height: | Size: 52 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 40 KiB After Width: | Height: | Size: 105 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 46 KiB After Width: | Height: | Size: 93 KiB |
@@ -1422,13 +1422,13 @@
|
||||
<p>Horizontal scaling stands for cloning of an application or service such that work can easily be distributed across instances with absolutely no bias.</p>
|
||||
<p>Let's see how our monolithic application improves with this principle</p>
|
||||
<p><img alt="Horizontal Scaling" src="../images/horizontal-scaling.jpg" /></p>
|
||||
<p>Here DB is scaled separately from the application. This is to let you know each component’s scaling capabilities can be different. Usually, web applications can be scaled by adding resources unless there is no state stored inside the application. But DBs can be scaled only for Reads by adding more followers but Writes have to go to only one master to make sure data is consistent. There are some DBs that support multi-master writes but we are keeping them out of scope at this point. </p>
|
||||
<p>Here DB is scaled separately from the application. This is to let you know each component’s scaling capabilities can be different. Usually, web applications can be scaled by adding resources unless there is no state stored inside the application. But DBs can be scaled only for Reads by adding more followers but Writes have to go to only one leader to make sure data is consistent. There are some DBs that support multi-leader writes but we are keeping them out of scope at this point.</p>
|
||||
<p>Apps should be able to differentiate between Reads and Writes to choose appropriate DB servers. Load balancers can split traffic between identical servers transparently.</p>
|
||||
<p><strong>WHAT:</strong> Duplication of services or databases to spread transaction load.</p>
|
||||
<p><strong>WHEN TO USE:</strong> Databases with a very high read-to-write ratio (5:1 or greater—the higher the better). Because only read replicas of DBs can be scaled, not the Master. </p>
|
||||
<p><strong>WHEN TO USE:</strong> Databases with a very high read-to-write ratio (5:1 or greater—the higher the better). Because only read replicas of DBs can be scaled, not the Leader.</p>
|
||||
<p><strong>HOW TO USE:</strong> Simply clone services and implement a load balancer. For databases, ensure that the accessing code understands the difference between a read and a write.</p>
|
||||
<p><strong>WHY:</strong> Allows for the fast scale of transactions at the cost of duplicated data and functionality.</p>
|
||||
<p><strong>KEY TAKEAWAYS:</strong> This is fast to implement, is a low cost from a developer effort perspective, and can scale transaction volumes nicely. However, they tend to be high cost from the perspective of the operational cost of data. The cost here means if we have 3 followers and 1 Master DB, the same database will be stored as 4 copies in the 4 servers. Hence added storage cost</p>
|
||||
<p><strong>KEY TAKEAWAYS:</strong> This is fast to implement, is a low cost from a developer effort perspective, and can scale transaction volumes nicely. However, they tend to be high cost from the perspective of the operational cost of data. The cost here means if we have 3 followers and 1 Leader DB, the same database will be stored as 4 copies in the 4 servers. Hence added storage cost</p>
|
||||
<h3 id="refer_1">Refer</h3>
|
||||
<ul>
|
||||
<li><a href="https://learning.oreilly.com/library/view/the-art-of/9780134031408/ch23.html">https://learning.oreilly.com/library/view/the-art-of/9780134031408/ch23.html</a> </li>
|
||||
|
||||
Reference in New Issue
Block a user