On Fri, Mar 05, 2010 at 03:07:36PM -0500, Justin Lloyd wrote: >I think I understand Jesse's rationale but I agree with Neil. >Analogously to the Unix command philosophy, IMHO, bodies (and often >bundles) should do one thing and do it well. Use multiple promises in >conjunction like you would use command-line pipes. > >Jesse, have you maybe tried something with a methods promise as wrapper >around calls to multiple bundles, using usebundle, to encapsulate >everything into a single "call"? I don't know if that would help with >what you're trying to do, but it came to mind as I was writing the first >paragraph. :)
Yep, I've been trying to do exactly that. In the process of trying, I've hit various limitations of what cfengine can or will do, ranging from string replacement foibles, to strings list iteration things, to odd timing defining variables based on classes. Some of these problems stem from incomplete understanding of the tools (list iteration), to technical limitations (string replacement), to just plain wierd (variable definition). Several times on this list the comments like "wrap stuff in bundles" and "make generic parameratized" bundles have been made. I completely agree with this idea, as it encourages code reuse, abstraction, single locations for fixing bugs, and all the wonderful things that come writing modular code. However, what I think should be a fairly straightforward--if not "simple" problem--has worked out to be anything but. This isn't the first time that this has happened either, as I've spent no small amount of time trying to get cfengine to do something natively that could be replaced by a very small shell script. >-----Original Message----- >From: Jesse Becker [mailto:becker...@mail.nih.gov] >Sent: Friday, March 05, 2010 12:57 PM >To: nwat...@symcor.com >Cc: Becker, Jesse (NIH/NHGRI) [C]; help-cfengine@cfengine.org; >help-cfengine-boun...@cfengine.org; Justin Lloyd >Subject: Re: Thoughts about copy_from > >On Fri, Mar 05, 2010 at 02:45:19PM -0500, nwat...@symcor.com wrote: >>help-cfengine-boun...@cfengine.org wrote on 2010-03-05 14:37:57: >>> I'd like to add one more suggestion as well: >>> >>> * Include the ability to call expand_scalars in the same promise as >>> copying a file from a remote host. Currently, this has to be >done >>via >>> two separate promises: one to copy the file to the local host, >and >>a >>> second to call edit_files and expand the variables. >> >>Technically they are separate. One involves a comparision, a copy and > >Yes, and I actually understand why, and how to implement it using a >copy/expand two-step process. I've been trying to make this into a >generic bundle (but have been stymied in various ways, prompting various >recent mailng list posts). > >I also think that they could could be combined into one step in order to >simplfy the promises. Just be sure to make the comparison based on >mtimes, and not checksums so you aren't constantly rebuilding the >file (unless that is what you want...). > > > >>possibly a verify of a source file. The second edits a copy of that >file >>that was copied. > >> >>cfserverd:/var/masterfiles/source-template >>| >>copy >>| >>cfagent:/tmp/souce-template-copy >>| >>edit and save to new location >>| >>/etc/final-target-file >> >> >>Sincerely, >>-- >>Neil Watson >>416-673-3465 >> >>> >>> >* The reference manual doesn't specify the default value for >>copy_from's >>> >copy_backup attribute. (That goes for a number of things in the >>> >documentation, actually.) >>> > >>> >* cfengine_stdlib.cf has several copy_from bodies. secure_cp is >useful >>> >but I prefer a secure_cp with a backup, so I created my own >>> >(secure_copy_with_backup) in my own library file. A third >>> >"backup=true|false" parameter to the standard copy_from bodies may >be >>> >valuable, but that would break existing policy files, so it's just a >>> >thought. >>> > >>> >* It might be nice to have the file extension appended when >copy_backup >>> >is used to be configurable beyond just the default ".cfsaved" text >and >>> >"timestamp" options, mainly to allow for multiple backups, similar >to >>> >what various log rotation commands provide. I can see how it may be >>> >argued that this goes against Cfengine's convergent nature, but >since >>it >>> >already provides the timestamp option, I thought I'd throw this out >>> >there anyway. A files promise could be used to limit the number of >>> >backups, or that could be another attribute. >>> > >>> >That is all. :) >>> > >>> >-- >>> >Justin C. Lloyd >>> >Unix Infrastructure Engineer >>> >DigitalGlobe, An Imaging and Information Company >>> > >>> > >>> >This electronic communication and any attachments may contain >>> confidential and proprietary >>> >information of DigitalGlobe, Inc. If you are not the intended >>> recipient, or an agent or employee >>> >responsible for delivering this communication to the intended >>> recipient, or if you have received >>> >this communication in error, please do not print, copy, retransmit, >>> disseminate or >>> >otherwise use the information. Please indicate to the sender that >>> you have received this >>> >communication in error, and delete the copy you received. >>> DigitalGlobe reserves the >>> >right to monitor any electronic communication sent or received by >>> its employees, agents >>> >or representatives. >>> > >>> >_______________________________________________ >>> >Help-cfengine mailing list >>> >Help-cfengine@cfengine.org >>> >https://cfengine.org/mailman/listinfo/help-cfengine >>> >>> -- >>> Jesse Becker >>> NHGRI Linux support (Digicon Contractor) >>> _______________________________________________ >>> Help-cfengine mailing list >>> Help-cfengine@cfengine.org >>> https://cfengine.org/mailman/listinfo/help-cfengine >> > >Content-Description: ATT00001..txt >> >> >>CONFIDENTIALITY WARNING >>This communication, including any attachments, is for the exclusive use >of addressee and may contain proprietary and/or confidential >information. If you are not the intended recipient, any use, copying, >disclosure, dissemination or distribution is strictly prohibited. If you >are not the intended recipient, please notify the sender immediately by >return e-mail, delete this communication and destroy all copies. >> >>AVERTISSEMENT RELATIF ?? LA CONFIDENTIALIT?? >>Ce message, ainsi que les pi??ces qui y sont jointes, est destin?? ?? >l???usage exclusif de la personne ?? laquelle il s???adresse et peut >contenir de l???information personnelle ou confidentielle. Si le lecteur >de ce message n???en est pas le destinataire, nous l???avisons par la >pr??sente que toute diffusion, distribution, reproduction ou utilisation >de son contenu est strictement interdite. Veuillez avertir sur-le-champ >l???exp??diteur par retour de courrier ??lectronique et supprimez ce >message ainsi que toutes les pi??ces jointes. > > >-- >Jesse Becker >NHGRI Linux support (Digicon Contractor) > >This electronic communication and any attachments may contain confidential and >proprietary >information of DigitalGlobe, Inc. If you are not the intended recipient, or an >agent or employee >responsible for delivering this communication to the intended recipient, or if >you have received >this communication in error, please do not print, copy, retransmit, >disseminate or >otherwise use the information. Please indicate to the sender that you have >received this >communication in error, and delete the copy you received. DigitalGlobe >reserves the >right to monitor any electronic communication sent or received by its >employees, agents >or representatives. > -- Jesse Becker NHGRI Linux support (Digicon Contractor) _______________________________________________ Help-cfengine mailing list Help-cfengine@cfengine.org https://cfengine.org/mailman/listinfo/help-cfengine
