<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Posts on Manas Gupta</title>
    <link>https://blog.manasg.com/post/</link>
    <description>Recent content in Posts on Manas Gupta</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-us</language>
    <lastBuildDate>Wed, 17 Jun 2020 18:59:42 -0700</lastBuildDate><atom:link href="https://blog.manasg.com/post/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>ISP and DNS Injection</title>
      <link>https://blog.manasg.com/isp-and-dns-injection/</link>
      <pubDate>Wed, 17 Jun 2020 18:59:42 -0700</pubDate>
      
      <guid>https://blog.manasg.com/isp-and-dns-injection/</guid>
      <description>A case of non-existent DNS entries coming to life blah.blah exists? $ ping -c2 blah.blah PING blah.blah (23.202.231.169) 56(84) bytes of data. 64 bytes from a23-202-231-169.deploy.static.akamaitechnologies.com (23.202.231.169): icmp_seq=1 ttl=53 time=71.5 ms I ran the above command on a whim on my new raspberry pi and was surprised by the result. That DNS entry does not exist. And neither does the tld. WTF?
What about fhdskfsdafs.google.com ? Let&amp;rsquo;s try this fhdskfsdafs.google.com</description>
    </item>
    
    <item>
      <title>Fun with IPSet and IPTables</title>
      <link>https://blog.manasg.com/fun-with-ipset-and-iptables/</link>
      <pubDate>Mon, 25 Sep 2017 21:20:05 -0700</pubDate>
      
      <guid>https://blog.manasg.com/fun-with-ipset-and-iptables/</guid>
      <description>TLDR IPSet is an extension of IPTables which can give significant performance gains as well as simplify configuration. perf top showed 10-30% CPU overhead for IPTables in my setup. It was negligible with IPSet.
Background  An additional IP-layer security was needed for a HTTP/s server 4 ports to be restricted A pool of Virtual Machines on the LAN (no NAT) were the clients Clients had random or non-contiguous IPs Chef runs on all the machines  It was almost trivial to have some chef code to get the IPs of all the clients and create IPTable rules.</description>
    </item>
    
    <item>
      <title>Monitorama 2017 : My Impressions</title>
      <link>https://blog.manasg.com/monitorama-2017-my-impressions/</link>
      <pubDate>Fri, 26 May 2017 21:58:42 -0700</pubDate>
      
      <guid>https://blog.manasg.com/monitorama-2017-my-impressions/</guid>
      <description>I attended Monitorama 2017 in PDX a few days ago. It&amp;rsquo;s a fantastic conference, which anybody running or writing a production service should attend.
All talks were live streamed and recordings are available - day1, day2 and day3. I chose to attend since it let&amp;rsquo;s me give my full attention to the speakers. It also served as a great off-site or an ops person&amp;rsquo;s retreat :). There is something special about &amp;ldquo;being&amp;rdquo; at the venue, relevant chatter and meeting other folks.</description>
    </item>
    
    <item>
      <title>Putting It All Together</title>
      <link>https://blog.manasg.com/putting-it-all-together/</link>
      <pubDate>Mon, 08 May 2017 21:29:18 -0700</pubDate>
      
      <guid>https://blog.manasg.com/putting-it-all-together/</guid>
      <description>Documentation tends to focus on &amp;ldquo;how&amp;rdquo; and often misses the &amp;ldquo;why&amp;rdquo;.
Jonathan Palardy puts it very well.
 there’s a README.md in each repo now… but maybe we need a documentary.mp4 instead. Interviews about how the code evolved.
 At work, I update a collection of essays every few months which explain the &amp;ldquo;why&amp;rdquo; for decisions/projects/technology-choices. This provides a more holistic experience compared to reading various tickets, searching emails and the typical institutional/tribal knowledge.</description>
    </item>
    
    <item>
      <title>Multi Node Setup with Test Kitchen</title>
      <link>https://blog.manasg.com/multi-node-setup-with-test-kitchen/</link>
      <pubDate>Sun, 02 Apr 2017 09:41:22 -0700</pubDate>
      
      <guid>https://blog.manasg.com/multi-node-setup-with-test-kitchen/</guid>
      <description>What&amp;rsquo;s test kitchen? From Test Kitchen
 It is designed to execute isolated code run in pristine environments ensuring that no prior state exists.
 It hooks with Chef really well and provides integration testing for infrastructure code and is a great tool for developing runbooks as code. You can use it with Vagrant/EC2/Docker to provide the underlying &amp;lsquo;server environments&amp;rsquo;.
Why use it? I returned to Nagios after many years and wanted to get it up and running locally.</description>
    </item>
    
    <item>
      <title>Runbooks As Code</title>
      <link>https://blog.manasg.com/runbooks-as-code/</link>
      <pubDate>Sat, 25 Mar 2017 01:13:28 -0700</pubDate>
      
      <guid>https://blog.manasg.com/runbooks-as-code/</guid>
      <description>Here&amp;rsquo;s the jar to run in prod and here&amp;rsquo;s the pdf on troubleshooting it.
 This still happens in 2017. It may make sense if you are shipping software to run outside your organization. But in an online/SaaS environment, this falls apart after a couple of months.
Here are some of our team&amp;rsquo;s guidelines, whenever we bring new components online.
Deployed with Chef, no exceptions Even if the chef cookbook is just a collection of execute directives.</description>
    </item>
    
    <item>
      <title>Achieving Common Ground</title>
      <link>https://blog.manasg.com/achieving-common-ground/</link>
      <pubDate>Thu, 05 Jan 2017 21:02:03 -0700</pubDate>
      
      <guid>https://blog.manasg.com/achieving-common-ground/</guid>
      <description>What are some tools to help developers and operations achieve common ground?
There are tools which can help, but it&amp;rsquo;s more effective to work out the flow of information between the teams and use tools to facilitate the transfer.
Dashboards for Metrics Lets take a web service as an example. Begin with two to four metrics which are common and relevant across the teams
 rate of requests rate of error (http_code &amp;gt; 499) latency  They should be in an easy to remember location and available to everyone.</description>
    </item>
    
    <item>
      <title>The DevOps Engineer</title>
      <link>https://blog.manasg.com/the-devops-engineer/</link>
      <pubDate>Thu, 22 Dec 2016 21:56:28 -0700</pubDate>
      
      <guid>https://blog.manasg.com/the-devops-engineer/</guid>
      <description>I was looking for someone on the operations side of things to join us. You know, Ops, running and maintaining Production. I was asked if I was looking for a SysAdmin, Site Reliability Engineer (SRE) or a DevOps Engineer. I did not give it much thought and went through a resume screening exercise.
And then it struck me.
There were so many &amp;ldquo;DevOps Engineers&amp;rdquo; resumes out there:
 who knew Chef/Puppet/Ansible who could code against the AWS Api who knew Docker :)  Surprisingly, &amp;ldquo;hands-on and troubleshooting experience, on a high traffic website, powered by any-flavor-of-unix&amp;rdquo; was absent.</description>
    </item>
    
  </channel>
</rss>
