Merge branch 'master' into preos

Signed-off-by: Nico Schottelius <nico@bento.schottelius.org>

Conflicts:
	docs/changelog

docs/changelog

@@ -4,12 +4,19 @@ Changelog
 	* Changes are always commented with their author in (braces)
 	* Exception: No braces means author == Nico Schottelius
 
-2.3.7:
+
+3.0.0:
+	* Core: Messaging support added
+	* Type: __iptables_rule: Use default parameter
+	* Type __file: Do not generate code if mode is 0xxx
+
+2.3.7: 2013-12-02
 	* Type __file: Secure the file transfer by using mktemp (Steven Armstrong)
 	* Type __file: Only remove file when state is absent (Steven Armstrong)
 	* Type __link: Only remove link when state is absent (Steven Armstrong)
 	* Type __directory: Only remove directory when state is absent (Steven Armstrong)
 	* Type __directory: Fix newly introduced quoting issue
+	* Type __package_zypper: Fix explorer and parameter issue (Daniel Heule)
 	* Core: Fix backtrace when cache cannot be deleted
 
 2.3.6: 2013-11-25

docs/dev/logs/2013-01-20.notifications

@@ -0,0 +1,20 @@
+Allow cross-type communication
+
+Sending notifications is possible from
+
+    - manifest
+    - gencode-local
+    - gencode-remote
+
+Sending a notification from an object means writing to the file "notifications" into
+its object:
+
+    echo mytest >> "$__object/notifications" # a type reports something
+
+Reading / Reacting on notifications works by accessing the file
+referred to be "$__notifications". All notifications are prefixed with
+the object name ($__object_name) and are appended into this file.
+
+To find out, whether a file was copied, run:
+
+    grep __file/etc/passwd:copy "$__notifications"

docs/dev/logs/2013-01-20.triggers

@@ -0,0 +1,49 @@
+An alternative / complementary approach to notifications: triggers (or actions?)
+
+A type may support various actions by creating files in its subdirectory
+"actions". Other types can trigger an action of a different type or object
+by calling them (indirectly?):
+
+
+if grep "__file/etc/nginx/conf.d/.*:copy" "$__notifications"; then
+
+    # Call action from a type
+    cdist trigger __nginx/reload
+fi
+
+
+Not sure whether this approach (calling "actions" of other types) is sane,
+as nginx should probably better know if it should be restarted "itself".
+
+
+--------------------------------------------------------------------------------
+
+Alternate approach:
+
+__nginx_vhost www.some-domain.ch --custom << eof
+some custom code for __nginx_vhost inclusion
+eof
+
+__nginx_vhost:
+
+    manifest:
+        # __nginx_vhost requires __nginx: creates directories
+
+        require"$__object_name" __nginx --require-only
+        
+        # Do WE or __file ... depend on nginx?
+        cdist require __nginx
+
+        # Create file that contains the giving code
+        __file /etc/nginx/conf.d/www.some-domain.ch
+
+        require="__nginx" __file /etc/nginx/conf.d/www.some-domain.ch
+
+__nginx:
+    manifest:
+        __package nginx --state present
+
+        __file some-custom-files
+
+    gencode-remote:
+        if first_install or file changed:

docs/dev/logs/2013-11-25.notifications

@@ -0,0 +1,50 @@
+Follow up from 2013-01-20:
+
+    - (re-)create message file per object?
+        - yes, but do not necessarily save in object space
+        - save $anywhere
+
+    - object_run
+        - current notifications are imported into a file available at $__messages_in
+        - after object run, everything that has been written to $__messages_out is merged into the $__messages file
+
+        - functions:
+            self.explorer.run_global_explorers(self.local.global_explorer_out_path)
+            self.manifest.run_initial_manifest(self.local.initial_manifest)
+                self.local.run_script(initial_manifest, env=self.env_initial_manifest(initial_manifest))
+            self.explorer.run_type_explorers(cdist_object)
+            self.manifest.run_type_manifest(cdist_object)
+                self.local.run_script(type_manifest, env=self.env_type_manifest(cdist_object))
+            self.code.run_gencode_local(cdist_object)
+                self.local.run_script(script, env=env, return_output=True)
+            self.code.run_gencode_remote(cdist_object)
+                self.local.run_script(script, env=env, return_output=True)
+
+
+    - message support in ...
+        - initialmanifest - yes
+        - explorer - no
+        - only locally - yes
+        
+    - how to use notification / messaging in cdist
+        - can be used in all local scripts:
+            - initial manifest
+            - type manifest
+            - type gencode-*
+        - order of object exeution is random or as you requested using require=""
+
+    - example use:
+
+__file/gencode-local:
+         if [ "$local_cksum" != "$remote_cksum" ]; then
+            echo "$__remote_copy" "$source" "${__target_host}:${destination}"
+            echo "copy" >> "$__messages_out"
+         fi
+ 
+__nginx/manifest:
+    __file /etc/nginx/sites-enabled/myfile --source "$__type/files/nginx-config"
+
+__nginx/gencode-remote:
+    if grep -q "__file/etc/nginx/sites-enabled/myfile:copy" "$__messages_in"; then
+        echo /etc/init.d/nginx restart
+    fi

docs/man/cdist-reference.text.sh

@@ -1,6 +1,6 @@
 #!/bin/sh
 #
-# 2010-2012 Nico Schottelius (nico-cdist at schottelius.org)
+# 2010-2013 Nico Schottelius (nico-cdist at schottelius.org)
 #
 # This file is part of cdist.
 #
@@ -191,6 +191,12 @@ __manifest::
 __global::
     Directory that contains generic output like explorer.
     Available for: initial manifest, type manifest, type gencode, shell
+__messages_in::
+    File to read messages from
+    Available for: initial manifest, type manifest, type gencode
+__messages_out::
+    File to write messages
+    Available for: initial manifest, type manifest, type gencode
 __object::
     Directory that contains the current object.
     Available for: type manifest, type explorer, type gencode

docs/man/man7/cdist-messaging.text

@@ -0,0 +1,72 @@
+cdist-messaging(7)
+==================
+Nico Schottelius <nico-cdist--@--schottelius.org>
+
+NAME
+----
+cdist-messaging - How the initial manifest and types can communication
+
+
+DESCRIPTION
+-----------
+cdist has a simple but powerful way of allowing communication between
+the initial manifest and types as well as types and types.
+
+Whenever execution is passed from cdist to one of the
+scripts described below, cdist generate 2 new temporary files
+and exports the environment variables __messages_in and
+__messages_out to point to them. 
+
+Before handing over the control, the content of the global message 
+file is copied into the file referenced by $__messages_in.
+
+After cdist gained control back, the content of the file referenced
+by $__messages_out is appended to the global message file.
+
+This way overwriting any of the two files by accident does not 
+interfere with other types.
+
+The order of execution is not defined unless you create dependencies 
+between the different objects (see cdist-manifest(7)) and thus you
+can only react reliably on messages by objects that you depend on.
+
+
+AVAILABILITY
+------------
+Messaging is possible between all **local** scripts:
+
+- initial manifest
+- type/manifest
+- type/gencode-local
+- type/gencode-remote
+
+
+EXAMPLES
+--------
+When you want to emit a message use:
+
+--------------------------------------------------------------------------------
+echo "something" >> "$__messages_out"
+--------------------------------------------------------------------------------
+
+When you want to react on a message use:
+
+--------------------------------------------------------------------------------
+if grep -q "^__your_type/object/id:something" "$__messages_in"; then
+    echo "I do something else"
+fi
+--------------------------------------------------------------------------------
+
+
+SEE ALSO
+--------
+- cdist(1)
+- cdist-manifest(7)
+- cdist-reference(7)
+- cdist-type(7)
+
+
+COPYING
+-------
+Copyright \(C) 2013 Nico Schottelius. Free use of this software is
+granted under the terms of the GNU General Public License version 3 (GPLv3).