1. 30

  2. 3


    This is really good.

    If anyone has trouble understanding what they’re seeing, the video is marvellous.

    1. 2

      I notice in the iptables example provided (http://www.howardism.org/Technical/Emacs/linux-iptables.html) the default policy is never changed to DROP.

      The accompanying documentation in the ‘Close All the Ports’ section suggests that that iptables -F will erase all the firewall rules. This command Flushes the chains but it won’t change the default policies to DROP if they are set to ACCEPT, which will result in any traffic not matching rules in the chain (there will be none after a Flush) to fall through to the default policy and be accepted. So if the default policies are ACCEPT at the time of running the Flush, it actually has the opposite effect and opens all ports.

      Default policy configuration for the chain is set using the -P parameter. eg.

      iptables -P INPUT DROP
      iptables -P FORWARD DROP

      Before setting the default policies, make doubly sure you have ACCEPT rules for your remote access or OOBM configured :)


      There also doesn’t appear to be a rule for ESTABLISHED,RELATED return traffic, so connections outbound from the host are going to be an issue.

      1. 2

        Why is this better than configuring the machine exclusively with Ansible (or your tool of choice) in the first place, that is, never logging in and making changes manually that you then have to pull into a configuration script later?

        That’s the practice I’ve adopted for the servers I manage, and it means that it’s literally impossible for me to have not kept track of how to reproduce the state of the system I’m working on. At any time I can wipe the system or destroy the VM or whatever, and know that I’ll get right back to where I left off. I can also commit my experiments to my local git repository and then it’s trivial to back out an attempt that didn’t work.

        Once I got proficient at it, I found that the overhead of doing it this way, while definitely not zero, was small enough that the benefit was easily worth the cost.

        1. 2

          I don’t think it replaces Ansible. The author of this post says (in the video linked by geocar) that he uses his notes to create Chef cookbooks.

          Instead of a bash script or yaml document with comments sprinkled in, it’s a document of prose with code sprinkled in that you can markup with links or images that can easily be shared to anyone. They don’t have to understand anything; it’s just text.

          You could also use org-babel to write an Ansible playbook or role, or just continue using Ansible on its own because it’s your server and you can provision it however you want :)

        Stories with similar links:

        1. Literate DevOps via arcatan 6 years ago | 7 points | no comments