inmanta/exec

Moved to https://code.inmanta.com/solutions/modules/exec

inmanta

Repository for the inmanta package. This package exists for backwards compatibility and depends on the inmanta-core package. For more information, have a look at inmanta-core's GitHub page.

exec's Issues

JQ dependency causes pip errors

JQ requires a working c/autoconf build environment, on most clean systems this is not present.

This causes crashes in the compiler and agent.

reference: https://pypi.org/project/jq/

Exec module runs commands multiple times, ingoring the 'creates' value

Due to semantic changes in the reload mechanism and some the very old base classes used by exec, it now triggers reloads too often and incorrectly

This resource

postgresql_initdb_script = exec::Run(host=self.host,
                                        creates="/var/lib/pgsql/10/data/pg_hba.conf",
                                        command=exec::in_shell("sudo su -c '/usr/pgsql-10/bin/initdb /var/lib/pgsql/10/data' - postgres"),
                                        requires=[install_postgresql_contrib_package, install_postgresql_package])
  

From the prostgresql module

Now fails on first deploy because:

1. it executes
2. then it executes the reload logic because it receives events from it's dependents
3. this second execution ignores the 'creates', causing failure

Work around

1. set reload to /usr/bin/true

postgresql_initdb_script = exec::Run(host=self.host,
                                        creates="/var/lib/pgsql/10/data/pg_hba.conf",
                                        reload="/usr/bin/true", # fix for https://github.com/inmanta/exec/issues/185
                                        command=exec::in_shell("sudo su -c '/usr/pgsql-10/bin/initdb /var/lib/pgsql/10/data' - postgres"),
                                        requires=[install_postgresql_contrib_package, install_postgresql_package])

Passing environment vars with "_" in the name doesn't work

Defining an environment variable with "_" in results in a stack trace.

WORKS

JAVAHOME=

environment_vars = {"JAVAHOME": "/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin"}

exec::Run(host=target, command="ant deploy >> {{ _logfile }} 2>&1", environment=environment_vars, cwd=self.installation_path)

ERROR

JAVA_HOME=

environment_vars = {"JAVA_HOME": "/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin"}

exec::Run(host=target, command="ant deploy >> {{ _logfile }} 2>&1", environment=environment_vars, cwd=self.installation_path

Traceback (most recent call last):
File "/opt/inmanta/lib64/python3.6/site-packages/inmanta/agent/handler.py", line 534, in execute
self.do_changes(ctx, resource, changes)
File "/var/lib/inmanta/60442c77-e62e-4fab-badd-350eed94b6fc/agent/code/modules/inmanta_plugins.exec.py", line 167, in do_changes
return self.do_cmd(ctx, resource, resource.command)
File "/var/lib/inmanta/60442c77-e62e-4fab-badd-350eed94b6fc/agent/code/modules/inmanta_plugins.exec.py", line 140, in do_cmd
raise Exception("Failed to execute command: %s" % ret[1])
Exception: Failed to execute command:

Index on the command attribute of Run entity complicates things

In this module we have the following:

entity Run:
    string command
    ...
end
index Run(host, command)

The fact that the command is part of the index creates some issues (or limitations in the usage of this entity).

1. Commands that needs to be executed multiple time, for example make in different paths, will raise a DoubleSetException.
2. Commands that needs to be executed at least once, but are created in different implementations, will cause Dependency loop exception if the entity is properly linked to the implementation with requires=self.requires and provides=self.provides and their is a dependency between the entities having those commands in their implementations.
3. Passing a full script to the command attribute while making use of the in_shell plugin can raise errors. I didn't investigate the root cause of it, in my case the error was:

   Exception: Failed to commit resource updates (An unexpected error occurred in the server while processing the request: ('Invalid id for resource exec::Run[kc1-host,command=sh -c "INTERFACE_NAME=\\"tap-201-3\\"\nSUB_INTERFACE_VLAN=\\"1001\\"\nSUB_INTERFACE_NAME=\\"${INTERFACE_NAME}.${SUB_INTERFACE_VLAN}\\"\nSUB_INTERFACE_ADDR=\\"10.255.1.6/30\\"\n\n\nif [[ $(ip link show ${SUB_INTERFACE_NAME} 2> /dev/null) ]]; then\n\techo \\"Interface already created\\"\nelse\n\tip link add link ${INTERFACE_NAME} name ${SUB_INTERFACE_NAME} type vlan id ${SUB_INTERFACE_VLAN}\nfi\n\nip link set ${SUB_INTERFACE_NAME} up\n\nif [[ $(ip -o addr show ${SUB_INTERFACE_NAME} | grep ${SUB_INTERFACE_ADDR}) ]]; then\n\techo \\"Ip address already added\\"\nelse\n\tip addr add ${SUB_INTERFACE_ADDR} dev ${SUB_INTERFACE_NAME}\nfi"],v=2305',))
   

A general workaround for all of this issues is to create a file (with std::File), containing whatever we want to execute and naming it whatever we want, deploying it, and then executing it with the exec::Run entity.

I think we should either:

1. Update the entity with a new name attribute and add it to the index, while removing the command from it. (but that will break backward compatibility)
2. Create a new entity, duplicate of the existing one, but with the difference mentioned in 1.
3. Document the workaround, and show it as good practice for this module, if we really want to keep the module untouched.