Re: [e-smith-devinfo] Re: Comments in generated config
> Point taken. I agree templates are best left for the experts. But in my > example, if comments are not found in the templated files the user is > more likely to change smb.conf directly following the 'expert' advice of > their database software support tech. > We all know where that will lead. I wonder if pulling some of these parameters into the server-manager wouldn't help. Sort of a SWAT for SME machines. It could have all of the domain features we've been recently discussing along with other common features. Many of the options listed in such an interface could be simple yes/no or pick form a list type items. Very simular to the Domain Master option currently in server manager. When you select YES, SME alters the correct smb.conf parameters to make you SME machine a Domain Master. Regards, Greg Zartman -- Please report bugs to [EMAIL PROTECTED] Please mail [EMAIL PROTECTED] (only) to discuss security issues Support for registered customers and partners to [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Archives by mail and http://www.mail-archive.com/devinfo%40lists.e-smith.org
RE: [e-smith-devinfo] Re: Comments in generated config
On Thu, 11 Oct 2001, Smith, Jeffery S (Scott) wrote: > Perhaps another "feature" needed is a template editor. Rather than having to > create the path in templates-custom, copy over the template, etc, it would > be a relatively simple matter to create a perl script to automate this. I'm guessing you envisage this editor as a 'create a custom template/fragment' web-manager plugin as there are lots of unix editors capable of being programmed with macros in the ways you suggest already I believe - emacs, vi ... My instinct is that anyone capable of understanding clearly what needs to be done in template customisation would find it easier and faster to direct edit. And there is the potential to create a mess if such an editor is accessable by someone who doesn't know what they're doing. But that's not really an excuse not to develop it - the real test is how useful it would be and it seems to me your idea at least has the potential to make life easier for the e-smith developer/integrator, making the templating system a little more transparent to function. -=-=-==-=-=--=-=-=-=-=-=-=-=-=-=-=-= Graeme Robinson - Graenet consulting www.graenet.com - internet solutions -=-=-=-=-=-=-=-=-=-=-==---=-=--=-=-= -- Please report bugs to [EMAIL PROTECTED] Please mail [EMAIL PROTECTED] (only) to discuss security issues Support for registered customers and partners to [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Archives by mail and http://www.mail-archive.com/devinfo%40lists.e-smith.org
RE: [e-smith-devinfo] Re: Comments in generated config
> -Original Message- > From: Darrell May [mailto:[EMAIL PROTECTED]] > Sent: Thursday, October 11, 2001 1:29 PM > Subject: RE: [e-smith-devinfo] Re: Comments in generated config > > /sbin/e-smith/modify-template templatepath > > Just so I understand, templatepath would be the actual file > name right? Yes, as in your example: ./modify-template /etc/smb.conf So the path is the final location of the configuration file, or relative to /etc/e-smith/templates if you prefer to think of it that way. The fragmentname would be just that. For example: ./modify-template -f 10globals /etc/smb.conf Or, and I somewhat prefer this syntax: ./modify-template /etc/smb.conf:10globals Or to make the perlites fall in love: ./modify-template /etc/smb.conf::10globals :-) > I think this is a great idea Scott. thanks > The perl script could even start with a menu. > > Modify Template Options: > > V - View template output > D - Display with comments and fragment names visable > E - Edit fragment > A - Add fragment > S - Search template > L - Load changes I think if you want to make a fully menu driven mode, the first task should be to select a template (configuration file), and then provide the options above which are relative to a specific template. Also, the selection of templates might include the search option as well, in order to present a list of templates containing specified string in any fragment. Since we're dreaming here, another useful option might be tacked onto the "Load changes" option you suggest. I'm assuming load changes would perform an expand-template. Sometimes that is enough, but often what is really needed is a signal-event. If there were a database that listed templates and the events (or actions?) that should be executed whenever the template is updated, then load changes would be truly effective. Otherwise, I think expand-template is not enough. > So who's the perl wizard that will create this? Not my forte yet, unfortunately. I'm groping my way through perl, but am nowhere near being able to do such a thing in any kind of reasonable timeframe. Though it would be a good learning project ;-) I'm sure the good folks at Mitel are quite capable, but I think they have their hands full with other tasks at the moment. Volunteers? Scott -- Please report bugs to [EMAIL PROTECTED] Please mail [EMAIL PROTECTED] (only) to discuss security issues Support for registered customers and partners to [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Archives by mail and http://www.mail-archive.com/devinfo%40lists.e-smith.org
RE: [e-smith-devinfo] Re: Comments in generated config
"Smith, Jeffery S (Scott)" <[EMAIL PROTECTED]> said: > /sbin/e-smith/modify-template templatepath Just so I understand, templatepath would be the actual file name right? /sbin/e-smith/modify-template /etc/smb.conf I think this is a great idea Scott. The perl script could even start with a menu. Modify Template Options: V - View template output D - Display with comments and fragment names visable E - Edit fragment A - Add fragment S - Search template L - Load changes So who's the perl wizard that will create this? -- Darrell May DMC NETSOURCED.COM http://netsourced.com http://myEZserver.com -- Please report bugs to [EMAIL PROTECTED] Please mail [EMAIL PROTECTED] (only) to discuss security issues Support for registered customers and partners to [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Archives by mail and http://www.mail-archive.com/devinfo%40lists.e-smith.org
RE: [e-smith-devinfo] Re: Comments in generated config
Perhaps another "feature" needed is a template editor. Rather than having to create the path in templates-custom, copy over the template, etc, it would be a relatively simple matter to create a perl script to automate this. /sbin/e-smith/modify-template templatepath This script could present a list of the available template fragments, from which the user would select one, and then load the fragment into vi or pico. After editing, if the saved file is different than the original, the fragment would automatically be placed into templates-custom. Exit logic could either return to the prompt, or return to the fragment list. The editor would of course need to check for existing custom templates -- basically the same logic that goes into selecting files for template expansion. Edit the custom template if it exists, else load the default and save to custom. Also display any new fragments from custom. For editing a specific fragment, a special syntax for templatepath: templatepath:fragmentname Or an alternate syntax: /modify-template -f fragmentname templatepath Another option would be to provide a grep filter in the editor: ./modify-template -s "searchstring" templatepath This would present a list of only those fragments containing the specified searchstring. Note that the -f option would not apply here. Lastly, some options to check what type a template (or fragment) is, and to restore a template (or fragment) to the default state. Display all fragments (or the specified fragment) and indicate if it is the default or custom: ./modify-template -t [-f fragmentname] templatepath Delete the specified template or fragment: ./modify-template -d [-f fragmentname] templatepath Some more search options. A -a to search all fragments in a directory, and a -r to search recusively: ./modify-template -a -r -s "searchstring" pathname Note that pathname in this case would be interpreted relative to /etc/e-smith/templates. Oh, and I suppose an option to create a new template: ./modify-template -n fragmentname templatepath And one to "copy" one from an existing fragment: ./modify-template -c sourcepath:fragment targetpath:fragment This modify-template editor interface would eliminate the primary need for comments in the output (ie, finding the fragment that generates the output) and would simplify the process of editing fragments (not really necessary to understand the templates / templates-custom structure.) Comments? Scott -- Please report bugs to [EMAIL PROTECTED] Please mail [EMAIL PROTECTED] (only) to discuss security issues Support for registered customers and partners to [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Archives by mail and http://www.mail-archive.com/devinfo%40lists.e-smith.org
Re: [e-smith-devinfo] Re: Comments in generated config
Dan Brown <[EMAIL PROTECTED]> said: > You might be right on this, Darrell, but I don't think a user who > doesn't grok grep is very likely to go tinkering with templates > either. Point taken. I agree templates are best left for the experts. But in my example, if comments are not found in the templated files the user is more likely to change smb.conf directly following the 'expert' advice of their database software support tech. We all know where that will lead. Cheers, -- Darrell May DMC NETSOURCED.COM http://netsourced.com http://myEZserver.com -- Please report bugs to [EMAIL PROTECTED] Please mail [EMAIL PROTECTED] (only) to discuss security issues Support for registered customers and partners to [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Archives by mail and http://www.mail-archive.com/devinfo%40lists.e-smith.org
Re: [e-smith-devinfo] Re: Comments in generated config
Quoting Darrell May <[EMAIL PROTECTED]>: > The key thing to remember is your customers knowledge. The average > Mitel user will not know the grep command exists. You might be right on this, Darrell, but I don't think a user who doesn't grok grep is very likely to go tinkering with templates either. I don't have a problem with including the names of the template fragments in the fragments themselves, and agree it could save a little bit of time, but I don't think it'd make much of a positive impact. -- Dan Brown, KE6MKS, [EMAIL PROTECTED] "Since all the world is but a story, it were well for thee to choose the more enduring story rather than the story that is less enduring." -- The Judgment of St. Colum Cille -- Please report bugs to [EMAIL PROTECTED] Please mail [EMAIL PROTECTED] (only) to discuss security issues Support for registered customers and partners to [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Archives by mail and http://www.mail-archive.com/devinfo%40lists.e-smith.org
Re: [e-smith-devinfo] Re: Comments in generated config
Charlie Brady <[EMAIL PROTECTED]> said: > No. You didn't have to be nasty. You could have dealt with the issues we > raised. My apologizes Charlie and Gordon. Let's deal with the issues raised... > As Daniel pointed out, there will be some files for which '#' > prefixed lines are not treated as comments. So we could then simply 'identify' which files this is an issue with and not comment these files or comment in the files acceptable syntax. > I don't know whether the "proposed standard" was intended to be > automated, or to be a de facto standard applied by the author of each > template fragment. Again, if we identify what files have an issue it could be either way. Automated would take some work on Mitel's end. Maybe you are moving in this direction. Authored would leave the work to the author of course. An identified and posted list of files and their appropriate comments syntax would solve this issue. File | Comment Syntax smb.conf | # ; httpd.conf | # file_to_be_named | no comments permitted The key thing to remember is your customers knowledge. The average Mitel user will not know the grep command exists. An example issue for your clients is they call a software vendor for support. Their database isn't working right. The software vendors determines they have an incorrect setting in smb.conf. The support tells them to set 'strict locking = no'. The client looks at smb.conf and sees the VERY important comment at the top that this is a templated file. (You are not planning on removing this comment are you?) They read through the file and find strict locking set to yes. They see immediately, from the commented fragment title that this is set in the [11strictLocking] fragment. They now know what to change, where it is set and with a little more digging on e- smith.org will figure out how to change a template fragment correctly. One less support call for us. One happy customer feeling good that he/she has solved their database problem and now has an understanding of template fragments. Regards, -- Darrell May DMC NETSOURCED.COM http://netsourced.com http://myEZserver.com -- Please report bugs to [EMAIL PROTECTED] Please mail [EMAIL PROTECTED] (only) to discuss security issues Support for registered customers and partners to [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Archives by mail and http://www.mail-archive.com/devinfo%40lists.e-smith.org
Re: [e-smith-devinfo] Re: Comments in generated config
On Thu, 11 Oct 2001, Darrell May wrote: > Sorry for being nasty but I just had to ;-> No. You didn't have to be nasty. You could have dealt with the issues we raised. As Daniel pointed out, there will be some files for which '#' prefixed lines are not treated as comments. In fact, there are some templated configuration files for which there is no valid comment syntax. Any automated addition of fragment name would need to be aware of these issues. I don't know whether the "proposed standard" was intended to be automated, or to be a de facto standard applied by the author of each template fragment. If the latter, I'd advise against it. In my experience, incorrect comments are usually worse than no comments at all. And I've seen very few projects where comments are always updated when they should be. Charlie Brady [EMAIL PROTECTED] Lead Product Developer Network Server Solutions Grouphttp://www.e-smith.com/ Mitel Networks Corporationhttp://www.mitel.com/ Phone: +1 (613) 368 4376 or 564 8000 Fax: +1 (613) 564 7739 -- Please report bugs to [EMAIL PROTECTED] Please mail [EMAIL PROTECTED] (only) to discuss security issues Support for registered customers and partners to [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Archives by mail and http://www.mail-archive.com/devinfo%40lists.e-smith.org
RE: [e-smith-devinfo] Re: Comments in generated config
I like the comments and I think it's a good idea to include them in the output files. Just a quick question. What difference will it make to the server whether or not comments are included? With the speed and power of today's computers, are we talking about a huge loss in speed due to extra code? Or does it have nothing to do with processing the output files? If you are worried about people editing the files directly, then including the comments helps them find the templates easier (and understand the SME system better)... instead of "grepping" themselves in circles. Just my 2cents. Trev. > -Original Message- > From: Gordon Rowell [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, October 10, 2001 9:19 PM > To: Darrell May > Cc: e-smith-devinfo > Subject: Re: [e-smith-devinfo] Re: Comments in generated config > > > On Thu, Oct 11, 2001 at 02:11:31AM -, Darrell May > <[EMAIL PROTECTED]> wrote: > > > > phm1a <[EMAIL PROTECTED]> said: > > > > > Hmmm. Smart. Simple. Effective. Sensible. > > > Gotta be something wrong with it somewhere... > > > ;>) > > > > Yup, just found it. The Mitel gang doesn't agree :( > > > > Sorry for being nasty but I just had to ;-> > > I think it was a bit unnecessary :-( > > There are lots of things we could put in, and you were saying it should > be a standard. Charlie and I disagreed for various reasons. That's what > discussion is about...isn't it? > > We strongly support proper documentation of the template fragments > themselves, but want to keep the output files as small and clean as > possible. > > Gordon > -- > Gordon Rowell[EMAIL PROTECTED] > VP Engineering > Network Server Solutions Group http://www.e-smith.com > Mitel Networks Corporation http://www.mitel.com > > > -- > Please report bugs to [EMAIL PROTECTED] > Please mail [EMAIL PROTECTED] (only) to discuss security issues > Support for registered customers and partners to [EMAIL PROTECTED] > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > Archives by mail and > http://www.mail-archive.com/devinfo%40lists.e-smith.org > > -- Please report bugs to [EMAIL PROTECTED] Please mail [EMAIL PROTECTED] (only) to discuss security issues Support for registered customers and partners to [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Archives by mail and http://www.mail-archive.com/devinfo%40lists.e-smith.org
Re: [e-smith-devinfo] Re: Comments in generated config
On Thu, Oct 11, 2001 at 02:11:31AM -, Darrell May <[EMAIL PROTECTED]> wrote: > > phm1a <[EMAIL PROTECTED]> said: > > > Hmmm. Smart. Simple. Effective. Sensible. > > Gotta be something wrong with it somewhere... > > ;>) > > Yup, just found it. The Mitel gang doesn't agree :( > > Sorry for being nasty but I just had to ;-> I think it was a bit unnecessary :-( There are lots of things we could put in, and you were saying it should be a standard. Charlie and I disagreed for various reasons. That's what discussion is about...isn't it? We strongly support proper documentation of the template fragments themselves, but want to keep the output files as small and clean as possible. Gordon -- Gordon Rowell[EMAIL PROTECTED] VP Engineering Network Server Solutions Group http://www.e-smith.com Mitel Networks Corporation http://www.mitel.com -- Please report bugs to [EMAIL PROTECTED] Please mail [EMAIL PROTECTED] (only) to discuss security issues Support for registered customers and partners to [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Archives by mail and http://www.mail-archive.com/devinfo%40lists.e-smith.org
Re: [e-smith-devinfo] Re: Comments in generated config files
On Thu, Oct 11, 2001 at 01:00:54PM +1000, Daniel van Raay <[EMAIL PROTECTED]> wrote: > [...] > It would be handy though to have a setting, similar to the existing > DebugTemplateExpansion, which when enabled would insert a > single '# Generated from /etc/e-smith/templates/etc/foo.bar/50bla' > line for each template fragment expanded. I certainly like this idea (and have thought about doing it in the past). This seems a very clean solution to the issue - no comments in the general case, but comments when you really want to see them. The comments are also auto-generated which I like as it saves on duplication of information. When combined with the newer expand-template which allows you to specify the output file, this should provide lots of debugging information. > I'm sure there must be an instance where such a comment would > break a config file though... There sure will be ones for which # commands are not allowed. Oh how I wish Unix had a standard config file comment character. Gordon -- Gordon Rowell[EMAIL PROTECTED] VP Engineering Network Server Solutions Group http://www.e-smith.com Mitel Networks Corporation http://www.mitel.com -- Please report bugs to [EMAIL PROTECTED] Please mail [EMAIL PROTECTED] (only) to discuss security issues Support for registered customers and partners to [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Archives by mail and http://www.mail-archive.com/devinfo%40lists.e-smith.org
Re: [e-smith-devinfo] Re: Comments in generated config files
On 10 Oct 2001, Charlie Brady wrote: > On Thu, 11 Oct 2001, Gordon Rowell wrote: > > > IMO, the generated files should be as compact as possible, without > > additional comment noise. The reasoning for the fragment is captured in > > the fragment, which then generates as little as is required. The > > comments often obscure the vital information. > > I agree with Gordon on this. The correct place for comments is in the > template fragment. No human need ever read the generated configuration > file, so comments should not be required there. In fact comments in the > generated file might encourage people to directly edit the configuration > file, instead of making changes to a template. It would be handy though to have a setting, similar to the existing DebugTemplateExpansion, which when enabled would insert a single '# Generated from /etc/e-smith/templates/etc/foo.bar/50bla' line for each template fragment expanded. I'm sure there must be an instance where such a comment would break a config file though... Daniel van Raay -- Please report bugs to [EMAIL PROTECTED] Please mail [EMAIL PROTECTED] (only) to discuss security issues Support for registered customers and partners to [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Archives by mail and http://www.mail-archive.com/devinfo%40lists.e-smith.org
Re: [e-smith-devinfo] Re: Comments in generated config
phm1a <[EMAIL PROTECTED]> said: > Hmmm. Smart. Simple. Effective. Sensible. > Gotta be something wrong with it somewhere... > ;>) Yup, just found it. The Mitel gang doesn't agree :( Sorry for being nasty but I just had to ;-> Darrell -- Please report bugs to [EMAIL PROTECTED] Please mail [EMAIL PROTECTED] (only) to discuss security issues Support for registered customers and partners to [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Archives by mail and http://www.mail-archive.com/devinfo%40lists.e-smith.org
