Solutions to the NCM components exercises

Exercise 2.

Note that you're running on a SMP machine, so preferably choose an SMP kernel!
Steps:

in profile_lxb06xxx.tpl define

"/system/kernel/version"="2.4.21-20.EL.cernsmp";

Commit the changes in CDB. If you look into /var/log/ncm-cdispd.log you will see something like:
 
[INFO] NCM-NCD version 1.1.18 started by root at: Thu Jan 13 20:17:40 2005
[INFO] adding missing pre/post requisite component: spma
[INFO] executing configure on components....
 
 
[INFO] running component: spma
---------------------------------------------------------
[OK]   updated SPMA target configuration file in /var/lib/spma-target.cf
[INFO] configure on component spma executed, 0 errors, 0 warnings
 
[INFO] running component: grub
---------------------------------------------------------
[OK]   updated boot kernel version to /boot/vmlinuz-2.4.21-20.EL.cernsmp
[INFO] configure on component grub executed, 0 errors, 0 warnings
 
=========================================================
 
[OK]   0 errors, 0 warnings executing configure
 

If you try to configure a non-existing kernel, you may get an error message like:

[ERROR] kernel /boot/vmlinuz-2.8.42-1.smp not found
[INFO] configure on component grub executed, 1 errors, 0 warnings

Running ncm-ncd --unconfigure grub does provide an error, as there is no 'unconfigure' method defined for this component!

[ERROR] Unconfigure() method not implemented by component
[INFO] configure on component grub executed, 1 errors, 0 warnings

You can have a look at the component file as installed under /usr/lib/perl/NCM/Component/grub.pm

Now, undo the configuration change, and configure back the correct kernel.
How to revert to the old kernel?

Use the power of inheritance: just remove the line you added to profile_lxb06xxx.tpl and the previously default value will  appear again. The cdispd daemon will then re-run grub and the previously configured kernel will be selected.

Note: Why does ncm-cdispd run the component? If you check ncm-query --component grub (which is an alias to ncm-query --dump /software/components/grub) you will see a 'register_change' entry. Here we list the paths for that component which should be watched by ncm-cdispd for changes. /software/components/<component_name> is always watched.

Note: This component does not generate the contents of /etc/grub.conf, unlike the edg-lcfg 'grub' component. It relies on a system program ('grubby') to do that job, which has the advantage that the syntax of the configuration file, nor any other contents inside the configuration file, has to be declared in the CDB.

Exercise 3.

Cron configuration:

Remember to use a PAN "list" for the entries.

  "/software/components/cron/entries/0/name"="example";
  "/software/components/cron/entries/0/user"="root";
  "/software/components/cron/entries/0/frequency"="* * * * *";
  "/software/components/cron/entries/0/command"="ls /proc";

More entries can be added eg.
"/software/components/cron/entries/1/name"="another"
etc.
The resulting cron.d file should look like:
[root@lxb0615 root]# cat /etc/cron.d/example.ncm-cron.cron
#
# File generated by ncm-cron on Thu Jan 13 20:13:55 2005.
#
* * * * * root (date --iso-8601=seconds --utc; ls /proc) >> /var/log/example.ncm-cron.log 2>&1
Accounts configuration:
"/software/components/accounts/users/napoleon/comment"="4Legs Good";
"/software/components/accounts/users/napoleon/uid"=8888;
"/software/components/accounts/users/napoleon/createHome"=true;

Exercise 4:

  1. The 'reason' field can be declared as follows (in pro_declaration_component_state.tpl.cin)
     

    Note the quotes around "reason". Alternatively, it is also possible to define 'reason' below /system instead of below /software/components/state. This is left as an exercise to the students.
     

  2. Run 'make', and add the pro_declaration_component_state.tpl to the CDB. You should also 'include' this template at an appropriate place. For testing, the 'profile_lxbxxx.tpl' is good.
     
  3. Now, edit profile_lxbxxx.tpl:
     
  4. Regenerate the profile via cdbop. ncm-query --component state should now dump
     
  5. See here for the resulting component. The changed parts are marked in blue. Note that the code could be of course compacted - but we want to focus on clarity in this example.
     
  6. Run: make release, and provide a ChangeLog entry. Run make rpm. Of course, you can modify the code as many times as you want and run 'make rpm' without having to increase the release number. Do not forget to update the documentation .pod file!
     
  7. rpm -Uvh /usr/src/redhat/RPMS/noarch/ncm-state-x.y.z-1.noarch.rpm. For the curious: run 'rpm -ql ncm-state' to see what files have been installed where.
     
  8. run ncm-ncd --configure state. If you set 'dispatch' to true in CDB, it would be run automatically by cdispd. You should get...

    [INFO] running component: state
    ---------------------------------------------------------
    updated /etc/state.desired
    updated /etc/state.desired
    [INFO] configure on component state executed, 0 errors, 0 warnings

    cat /etc/state.desired should give you

    #
    # desired node state
    # created by quattor NCM 'state' component
    #
    STATE_DESIRED = production
    REASON = four legs good, two legs bad
     
  9. Of course, NCM will refuse to run 'state' unless it has been set to 'active' in the profile !

Note that this component is very simple. If you want to see more advanced examples of using eg. the configuration access API (NVA API), have a look at eg. the SPMA component under /usr/lib/perl/NCM/Component.spma.pm.

1/2005 German.Cancio@cern.ch