Wishlist

From Cfwiki

Jump to: navigation, search

This page contains a list of requests from the Cfengine community. If you are looking to get involved with the cfengine community, feel free take a look below and see if there is something you can accomplish! Consider editing this page to mark that you are working on it; you can also send an email to the Cfengine Help mailing list.

Contents

Development Ideas for Cfengine

Code Change Ideas

Language ideas (most also require backend changes)

  • Add ${pid} variable.
  • Better array support. It would be nice to have the ability to push values on to an array. Especially with code that is generated from templates. 
control:
    any::
        actionsequnce = ( shellcommands )
        AllowArrayOf = ( ips )
    class1::
        ips = ( 192.168.1.1 )
    class2::
        ips = ( 192.168.1.2 )

shellcommands:
    "/bin/echo $(ips)"

would produce of both class1 and class2 were defined: 


192.168.1.1:192.168.1.2
  • FilterMatches( filter_name [, path_predicate ] ) evaluated expression so you can define classes using filters rather than having to run test or find.
  • cfexecd option to periodically (i.e. weekly) force email output even if output hasn't changed. Nice comprimise to cfexecd' normal behavior in case output is accidentally deleted or ignored the first time.
  • option to have cfenvd watch all configured ports and protocols, like TcpPort81_low_dev1; also allow it to collect CPU and load data
  • clean up cfengine file format:
    • Settle case-sensitivity in cfengine directives: are they case insensitive or not?
    • more tolerant of whitespace: why not accept 
config=(something)
  • Have debugging flags in the code. So we can turn on and off debugging for certain sections of code. It will make it easier to figure out what cfengine is doing, rather than run debug for the whole run.
  • Direct LDAP support. It would be cool to query LDAP attributes for a given machine to define classes. (Note from TimN: Why stop there? Draw data from PAM, nsswitch.conf, and SQL databases. The array support (above) would be a good prerequisite for this)
  • Add better error reporting. If there is an error from stdout in a shellcommand you get the following message:

[root@chief cfengine2]# /var/cfengine/bin/cfagent -qK -D poss_helloworld cfengine::r/bin/echo "Hel: sh: line 1: /usr/bin/echo: No such file or directory [root@chief cfengine2]#

It is difficult to determine from the 16 characters what the unique it tried to run, and where it exists in your Cfengine code.

ACL changes
  • Handle Linux Posix ACLs, as well as Solaris ACLs. (Support for this was planned for the 2.1.11b1 snapshot (--kevc), but Mark recently indicated that 2.1.11 would not cover linux ACL's as the API was too complex to support at this time. (--joshr))
  • AFS support for real. It's listed as a supported filesystem type but there's no code behind it
  • Linux chattr flag support in "files:". Ideally flags that are common across operating systems would have common words. Something like "immutable". (--anonymous)
  • Support for selinux chcon (ls -Z), and the like
File Editing

If you want to add something to this section, and if it's an editfiles-related or templating-type idea, please add them to the respective pages (or links to them on the respective pages).

Class Manipulation
  • Allow rule operators inside class definitions. Example: 
 classes:
     install_foo = (
         some_os.the_lab
         other
         places
         the_bar
     )
  • Enforce class declarations so 'typo-ed' class names can't be used, and to prevent undefined AddInstallables from behaving randomly. (Note from TimN: I'd like this to be optional, and undefined AddInstallables treated as empty)
  • Class comparators. Time >= some_time. OS >= redhat_9. (Ed Note: Added in 2.1.14 !)
  • Allow null class definitions so you can "prepare_for_some_new_feature = ( )" without assigning any hosts to it right away.
RegExp Testing
  • Writing RegExp can be painful. CfEngine should have a new tool to test Posix RegExp on strings, before commiting the config. *Update: This is now available for testing:* http://www.cfengine.org/utilities.phtml (--EricSorenson 20070912)
Allow Variable Iteration in Method Calls
  • One of the more common questions people have is "How do I execute a shell command with an iterator where the iterator shows up more than one place in the shell argument list". Allowing the use of iterators in the argument list to a method call would solve this. For example: 
control:
  iterator=(a:b:c)
methods:
  myForEach($(iterator))
  file=myForEach.cf
  server=localhost
  returnvars=null
  returnclasses=null

myForEach.cf

     control:
    
    
     MethodName       = ( myForEach )
     MethodParameters = ( usedmorethanonce )
    
     actionsequence = ( shellcommands )

     shellcommands:
        "/bin/echo ${usedmorethanonce} is used again here ${usedmorethanonce}"

   alerts:
   
   any::
    
      ReturnVariables(none)
      ReturnClasses(none)

Code change::Backend ideas

  • Add a splay= feature as an alternative to ifelapsed= so you can splay individual actions across arbitrary time periods longer than the cfagent run schedule. Example: Run package updates on all systems once per day but not all at the same time. Implement by a combination of using the same hashing algorithm that SplayTime uses and ifelapsed= style locking to make the action happen near the host's timeslot.
  • Make matches= work with define= and elsedefine= in processes:. Example: 
"${ntpd}" matches=1 elsedefine=restart_ntp
  • Document the style for the C code in cfengine (you know people will ask why no indentation at first level ;-). Provide Emacs and vi tools for implementing the style. Perhaps use the indent program to standardize...
  • The ability to specify an alternate port for cfengine use.
  • The ability to choose a syslog facility, enabling the administrator to easily separate agent logs from other system logs. This way, the logs could also be centralized on a syslog server, and easier to parse.
  • Run-time definition of 32_bit and 64_bit classes (so '64 bit machines know they are 64 bit when they use 32 bit cfengine binaries').
  • Wider and more complete package management support (perhaps including Debian .deb files, Solaris dkgs, AIX installp packages, HP-UX swinstall depot packages, etc.) (But see also Documentation::Updates)
  • (Fixed in 2.1.13.) Don't evaluate class definitions that are prefixed with rules that evaluate false. For example, don't attempt egrep on a Solaris system given: 
classes:

  !solaris::

    doit = ( ReturnsZero(/bin/egrep -q ...) )
  • Allow file distribution via ssh/scp file distribution as you probably already have sshd installed. Can be done separately, but seems like a useful thing to integrate into the main system. Sometimes people don't trust the recipients of files to connect back into the distributor the way cfengine does. (--anonymous)
  • Consider use of Parrot as the backend, because:
    • It would mean that some of the portability issues would be solved for us
    • It would mean that we could (if we did things properly) embed other Parrot-based languages in cfengine or vice versa, and call on their libraries. Other Parrot-based languages include Perl, Python, Ruby, PHP, m4, and a wide variety of others.
    • Parrot will have a powerful grammar engine. This may increase the ability of ordinary people to change the syntax
    • Warning: Parrot is unfinished at this point (February of 2005)
  • Perhaps branching Cfengine into two separate projects:
    • a cfengine framework (cff) : Consisting of cfservd and the update.conf section of cfagent.
    • a cfengine language (cflang) : Consisting of the rest of cfagent not part of cff.
    • (That is, a distribution (cff = cfengine framework) project and a language (cflang) project, with cff being cfservd, the update.conf section of cfagent, and cfexecd, and cflang being the rest of cfagent.)
    • The idea behind this suggestion is the Unix philosophy of having a tool that does one thing, and does it well. (--Wayland, aka TimN)
  • Better default classes for network addresses to allow matching of non-CIDR networks
    • use network address in IPv4 and IPv6, e.g. 
ipv4_172_16_1_128 for 172.16.1.234/25 (172.16.1.234 netmask 255.255.255.128 -> network 172.16.1.128 (first address)
ipv6_2001_db8_1_2 for 2001:db8:1:2:1234:5678:abcd:1234/64 (network is 2001:db8:1:2::/64), only works for
                  16bit boundaries, beware of address compression (2001:db8::/64 should be 2001_db8_0_0)
    • The ability in the control section to disable classes based on IP addresses all together.

Process Ideas

  • A publicly accessible read-only code repository (CVS or other).
  • A cfengine advisory board who would make recommendations to Mark. They would have no official power, but would have representatives from system administration, academic, commercial, and development sectors. They (or another group) could also help Mark consider patches and feature requests, manage the bug database, and test cfengine on various platforms.
(Note from Ed: According to this post from Mark Burgess, after the 'next major version of cfengine', a 'cvs repository' will be set up, after which time Mark's "involvement in development will be reduced").

Testing ideas

  • A regression test suite run on the snapshots nightly.

Branching ideas

  • Stable and development branches to facilitate testing and development. Perhaps like Perl or the Linux kernel, with odd-numbered release versions (i.e., 2.3.x) being development versions, and even-numbered release versions (i.e., 2.2.x) being stable releases.
  • Perhaps branching or forking a non-academic, production-oriented version of cfengine. (Ed: I'm not politically in favor of this, but it is discussed in some circles).

Advocacy ideas

  • Keep Freshmeat entry for Cfengine up-to-date.

Packaging and Archive Ideas

  • Putting a RPM spec file into the top level of the source tar.gz archive allows autocreation of RPMs directly from the source tarball, and provides a "starting point" for other RPM developers. (Like this: "rpm -ta cfengine.tar.gz")
  • Coordinate with official package maintainers for various distributions...
  • Provide timestamps in the filename of the snapshots (not the official releases!). This could help minimize confusion for testers. (Ed: perhaps like 'cfengine-2.1.11-20041020-0101.tar.gz'). (See Talk:Wishlist page for sidenote on this topic.)

Documentation Ideas

Updates

  • Document which packaging systems are actually supported on the backend. Rumours are heard of support for Debian, Solaris, etc, packages, but the only one documented is RPM.
  • The "QuickStart" Guide has been begun, but needs lots more work.
  • Update the distributed documents to fix spelling and grammar as well as generally improve the organization. Ideas can be sent to David Douthitt,or posted here.

Proposed New Documents

General

  • QuickStart: This has been begun already, but may eventually be moved out of the Wiki (subject to the Creative Commons License used for the wiki -Ed).
  • A clear reference of all possible cfagent.conf sections and their associated declarations (Question from TimN: In what way is the current cfagent Reference different from what you want?)
  • Documentation on cfenvd and cfenvgraph; these should be documented in the //Reference Manual//

cfwiki.org

  • Maybe a place is needed for developers to (semi-) document the organization of the code and, thus, help bring new developers onboard. ( DavidMasterson )
    • Advantage of doing this is that the developers could directly discuss the code sections and suggest major (or minor) reorganizations with examples in the Talk area.
  • A Cfengine Glossary (In progress). Class, Section, Variable, other cfengine-specific nomenclature.
  • a page on cfwiki.org encouraging people to link to cfwiki.org, perhaps with suggested text and graphics.

Diagrams

  • A graphic representing a 'bird's eye view' of all the cfengine binaries and usual configurations (cfrun, cfexecd, cfservd, ... and usual contents of /var/cfengine/input). Also picture showing purpose of each directory in /var/cfengine.
  • A diagram that outlines cfengine's topology when used in a multi-server environment.

Process ideas

General

  • Modernize the documentation with DocBook. In what way is Texinfo unsuitable and "unmodern"?
  • Have man pages for cfagent, cfrun, cfexecd, cfservd installed by default 'make install'.
  • Have a user commented documentation similiar to PHP's (Note from TimN: this might work on the wiki, with the document as an "article", and the comments as "discussion"; see below suggestions on wiki and documentation).

Programmers

  • Someone has already started work on using doxygen with cfengine

cfwiki.org

  • Remove 'community portal' link from left bar, add 'Tips and Tricks' and 'Wishlist' links.
  • Beautified home page. Picture? Headline? Fancy table layout?
  • Reasonable Categories for cfwiki.org.
  • Remove cfwiki/index.php/ from urls (again)
  • A nicer 'cfwiki.org' graphic! (This shows up on the upper left of each page.) The easiest thing to use would be a 135x135 pixel, transparent PNG (or gif).
  • cfwiki.org polls.
  • Wiki-ize current documentation (see also the note under Documentation::Process::General about having a PHP-like documentation)
    • Replace the old (ugly? sry!) cfengine.org site by this Wiki. This implies the import of the whole documentation, but the wiki CSS is easier to read! This Wiki is great! (--anonymous) (Note from TimN: Last time this was suggested, a lot of people felt that they wanted the documentation, at least, to be separate. Ed: Perhaps a different collaborative authoring mechanism would be more appropriate).
    • Wiki-ize the Cfengine Tutorial and Reference. These must still be in the distribution, but moving authoring to a Wiki would allow simple and direct editing by users everywhere. (Some suitable method of exporting the content from the wiki back into cfengine would need to be developed.)

Other Ideas

  • An external script to scan a filesystem for the current file permissions, owner, and group information and to then generate the appropriate cfengine configuration files which maintain the currently active permissions.

Things that have happened!

  • Get Cfengine into Fedora Core 3. (NOTE: cfengine is in Fedora 7)

Articles About Cfengine People Would Like To Read

If any of these articles already exist, please note it here!

  • File Layout and Architecture -- (pearcec, Brendan Strejcek) (Ed: elaboration on what you'd like to see in this article is welcome!)
  • Application-specific cfengine configuration ideas, modules, lessons learned.

cfwiki.org changelog

The changelog records major changes on cfwiki.org and when they occur. As tasks from cfwiki.org and ideas from above are completed, they are moved to the changelog.

Quick Links

Main Page - Overview - Glossary - Links - Articles - Wishlist - Tips, Tricks and Notes - Current Events
Interview - Support - Books - Help - Mascot - Motto - All Pages - Statistics - Cfwiki.org Changes

Retrieved from "http://www.cfwiki.org/cfwiki/index.php/Wishlist"
Personal tools