*.pyc
*.pid
*~
+do-rsync.sh
--- /dev/null
+Count your YAML dashes
+######################
+
+:date: 2014-08-31
+:tags: hints,ruby,yaml
+:category: hints
+:author: Jude N
+
+I spent way too long the other day thrying to figure out why some Hiera variable wasn't available in some puppet manifest.
+
+It turns out there was a typo in the YAML file where the first line of the file only had two dashes instead of three.
+
+In this cases, the Ruby 1.8.7 yaml parser corrupts the first entry in the yaml file, adding the two dashes to the beginning of the key, instead of throwing a parser error.
+
+.. code-block:: irb
+
+ irb(main):001:0> require 'yaml'
+ => true
+ irb(main):002:0> a=YAML.load_file("only-two-dashes.yaml")
+ => {"-- first"=>1, "second"=>2}
+ irb(main):003:0> b=YAML.load_file("correctly-including-three-dashes.yaml")
+ => {"first"=>2, "first"=>1}
+
+I couldn't find an existing bug for this, but I didn't look to harrd since this has been fixed in Ruby 1.9
+
+.. code-block:: irb
+
+ irb(main):001:0> require 'yaml'
+ => true
+ irb(main):002:0> a=YAML.load_file("only-two-dashes.yaml")
+ Psych::SyntaxError: (t1.yaml): couldn't parse YAML at line 1 column 1
+ from /usr/lib/ruby/1.9.1/psych.rb:154:in `parse'
+ from /usr/lib/ruby/1.9.1/psych.rb:154:in `parse_stream'
+ from /usr/lib/ruby/1.9.1/psych.rb:125:in `parse'
+ from /usr/lib/ruby/1.9.1/psych.rb:112:in `load'
+ from /usr/lib/ruby/1.9.1/psych.rb:229:in `load_file'
+ from (irb):2
+ from /usr/bin/irb1.9.1:12:in `<main>'.
+
+So if you're using Ruby 1.8.7, and it looks like the first item in your YAML file is being dropped for some
+reason, check the first line of the file has 3 dashes.
+
+
+
+
--- /dev/null
+Code Generation and Deployment Diagrams
+#######################################
+
+:date: 2014-07-07
+:tags: idea,project
+:category: idea
+:author: Jude N
+:Status: draft
+
+Is code generation for deployment diagrams possible/useful ?
+
+Problem
+- A deployment diagram is put together pretty close to the start of the project.
+- The deployment diagram shows the various machines in the stack and what services should be running on the machines, and what ports should be opened
+- In theory, it should be possible to set up the manifests for the boxes to open iptables rules, adjust SELinux policies to use the expected ports, etc
+- In practice, there are usually errors uncovered late in the development cycle, since the networking changes can't really be tested until there's software available to pass traffic over the ports (at which point we figure out the manifests are opening traffic in the reverse direction,
+- It would be good if there was a better way to 'kickstart' the manifests involved with multi-machine stacks.
+
+Solution
+- Since we do use deployment documents, and it is possible to generate skeleton code from UML class diagrams, it might be possible to set up skeleton puppet manifests from deployments diagrams.
+- So what open source tools where this might be possible ?
+
+ - `Gaphor`_ : I could get one end of a connector to attach to a node, but not the other.
+ - `Dia`_ : Thre's a Python API where I was able to get some basic node/connector code generation working, but Dia didn't let me nest components in nodes. Also many years since a new release.
+ - `ArgoUML`_ : The deployment diagram supports nesting components inside nodes, but adding support for puppet code generation would involve writing a lot of Java. PLus 2 years since a release, and still using SVN.
+ - `PlantUML`_ : UML diagrams are generated from text files, so in theory I could use the text as an input to code generation program that could output puppet.
+ -- I also like that this approach removes a lot of the time wasted fiddling with diagram layout by outsourcing that to graphviz.
+ -- The text-source approach has also worked out well for me using the `Quick sequence Diagram Editor`_
+
+.. _Gaphor: http://freecode.com/projects/gaphor
+.. _Dia: https://wiki.gnome.org/Apps/Dia
+.. _ArgoUML: http://argouml.tigris.org/
+.. _PLantUML: http://plantuml.sourceforge.net/
+.. _Quick sequence Diagram Editor: http://sourceforge.net/projects/sdedit/
--- /dev/null
+Bellhop
+#######
+
+:date: 2014-05-04
+:tags: idea,project
+:category: idea
+:author: Jude N
+:Status: draft
+
+bellhop is a generic packaging server.
+
+Problem
+- Every tool and platform eventually has it's own packaging tool (python eggs, ruby gems, perl modules, javascript packages)
+- You should be able to build a project even when the external intrnet is unavailable (local mirroring)
+- You should be able to save versions of the packages used by a project even when the external sites / mirrors have dropped them (pinning)
+- Serving new type of package shouldn't involve setting up an entirely new ecosystem to basically serve files over http
+
+Solution
+- Provide a single package providing source called ''bellhop' (since he'll carry your packages for you)
+- bellhop will use a plugin architecture to provide interfaces for various packaging interfaces
+- user will be able to use whatever the default packaging client tool is (yum / apt / pip / easy_install / gem / npm / whatever)
+- bellhop will provide a common backend in a consistent format for storing the packages, regardless of how the client expects the files to be served)
+- bellhop will provide a plugin architecture for the backend storage of packages
+
+ - The default will be filesystem bases, with packages being stored under /var/www/bellhop/{package_type}/{package_name}/{available_versions_of_package_name}
+
+- bellhop will be written in a language that'll be easy to get accepted in distros default packaging schemso
+ - Target fedora and debian packages for starts
+ - limit dependencies / use established/proven libraries
+ - default python 2 version for now ?
+
+- Plugins:
+
+ - pypi : python : nothing special ? : /var/www/bellhop/pypi/_packagename_/_package_versions_ : URL format
+ - cpan : perl : Downloads some index files first : /var/www/bellhop/cpan/_packagename_ / _package_version_ : URL format
+
+
+- Just set up the repos with httpd / nginx url rewrites ?
+
+- Notes:
+
+ - see pinto's concepts of stacks and pins: http://perlmaven.com/pinto-tutorial
--- /dev/null
+busboy
+######
+
+:date: 2014-05-08
+:tags: idea,project
+:category: idea
+:author: Jude N
+:Status: draft
+
+ipbusboy is an iptables policy builder similar to audit2allow - it watches for IP traffic that is being dropped, and attempts to build a policy which would allow to be flow.
+(ip)busboys clear (ip)tables. (Yeah it's a stretch...)
+
+Problem
+- you don't want every port on your machine wide open
+- you also want to make your policies as strict as possible
+- getting the iptables syntax correct is a pain.
+
+Solution
+- turn on logging of dropped packets
+- attempt to do your activity currently getting blocked
+- turn off logging of packets.
+- Based on the dropped packets, build up a policy which would allow those packets to pass.
+
+ - Allow incoming traffic from address XXX on port YYY through interface ZZZ
+ - Allow outgoing traffic to address AAA on port BBBB through interface CCC
+ - Add state settings ????
+
+Next Steps
+- Find my iptables book...
+- Collect examples of blocked IP tables traffic
+
FEED_ALL_ATOM = None
CATEGORY_FEED_ATOM = None
TRANSLATION_FEED_ATOM = None
-FEED_RSS = None
-FEED_ALL_RSS = None
-CATEGORY_FEED_RSS = None
+FEED_RSS = 'feeds/rss.xml'
+FEED_ALL_RSS = 'feeds/all.rss.xml'
+CATEGORY_FEED_RSS = 'feeds/cat.%s.rss.xml'
+TAG_FEED_RSS = 'feeds/tag.%s.rss.xml'
FEED_MAX_ITEMS = 20
# Blogroll
projects / pwan.org.git / commitdiff