Hello, sonofrage,
First of all, welcome, and great to see you managed to get that far with
CFEngine.
As per the directory structure, I find your idea a little bit weird. I
see that you have separated the .cf files in src/ from scripts in
resources/, however you left promises.cf and stdlib in the top
directory. I understand that you need to have the main promises.cf and
failsafe.cf files in the top-dir of $(inputs_dir) but stdlib does not
need to sit there.
Anyway, what I found to be more common is the use of masterfiles for
just the .cf files. People tend to use something like master_modules and
master_scripts and replicate that from the cfengine master server. Thus
a client machine copies files to its $(inputs_dir), declared from
$(sys.workdir)/inputs, traditionally located in /var/cfengine/inputs.
The same goes for modules/script/support files.
So if you want to stay close to what most people are using, use this scheme.
I am using a different scheme, however. I have a service-oriented
directory structure:
$(masterfiles_dir)/
|-- promises.cf
|-- failsafe.cf
|-- cfengine/
|-- |-- cfengine_stdlib.cf
|-- |-- update.cf
|-- auth/
|-- |-- auth.cf
|-- |-- authentication_helper.cfmodule
|-- |-- krb5.conf.template
|-- packages/
|-- |-- packages.cf
|-- |-- sources.list.tmplt
I have modified the default update mechanism, to recursively copy all
.cf files into a flat structure in $(inputs_dir), .cfmodule files to
$(modules_dir) and .template files $(templates_dir). I am stripping the
extension from modules and templates when that happens. I am using cfgen
(http://dozzie.jarowit.net/trac/wiki/cfgen) for generating the templates.
I find this scheme easier to find files corresponding to a particular
service, easier to drop or add a new service and it is generally cleaner.
> I'm using relative paths to call the scripts from check_jdk.cf, like:
>
> "scripts_folder" string => "resources/scripts";
This is not the best idea. It is difficult to say, what the working
directory is, will it be the same on all clients, will it not change
etc. CFEngine is not intended to be used from other scripts, so you
should not do anything like cd /cf-test/project/ && cf-agent. If you
really want to move CFEngine from /var/cfengine, then recompile it with
a different prefix like /cf-test and use the built-in variable
$(sys.workdir), which points to /var/cfengine in default packages. Then
you can use:
"scripts_folder" string => "$(sys.workdir)resources/scripts";
for the actual job. If you do not want to recompile CFEngine or do not
want its binaries to sit in /cf-test, you can actually define your own
variable $(current_project) and set it to /cf-test/project. There would
be just a one-line change to move it to a different dir.
> Proposed executable file "resources/scripts/check_java_version.sh" doesn't
> exist
> ...
> Proposed executable file "resources/scripts/unzip_package.sh" doesn't
> exist
For starters, it's easy to just use scripts to do a particular job from
CFEngine. You should however try to minimize the tasks you do with them.
CFEngine is faster, more reliable and will cope with a lot of things
that a quickly wrapped-up script would not handle. Have a look at the
Promise Theory on the CFEngine website.
For the particular java case, I prefer to use Debian or RedHat packages
to distribute it. If you just want to unpack it from a zipfile, perhaps
it is better to just use a copy promise and copy this from a master
server where it is kept unpacked.
I hope this helps you and I wish you a pleasant experience with CFEngine!
Cheers,
Ballock
_______________________________________________
Help-cfengine mailing list
[email protected]
https://cfengine.org/mailman/listinfo/help-cfengine
