Koozali.org: home of the SME Server
Legacy Forums => Experienced User Forum => Topic started by: el Jaimito on January 26, 2003, 10:10:40 PM
-
Hi all,
messing about with e-smith, getting into the templating system, 'cos I need to make some changes. However, this is proving problematic. I'm probably on the wrong track, corrective kicks appreciated :-)
I need to make a trivial change to the fetchmail config in order to:
1. leave the mail on the ISP server
2. comment out the '--fetchall' so the kept mail is not repeatedly collected.
The official docs I've read instruct in the use the template-custom scheme, whereby slick provision has been made for such alterations.
This is easy, and I was about finished with a custom templates-custom/fetchmail/ 50multi-drop when I got another request/further info from my colleagues, that they also needed to use multipop (dugong) to collect from various ISP POP accounts.
Fine, looked at multipop. Aha. It also uses templates-custom/fetchmail/50multi-drop, good. And it neatly overwrites my revised 50multi template. Ah-hah. Oh.
After further thought on this, my working solution is to use a context diff and patch, like so:
a. copy 50multi-drop from templates to templates-custom if it does not already exist there
b. then to patch the 50multi-drop copy in templates-custom (whichever proggie put it there) to make the necessary changes
This would seem to work with the 5.5 original 50multi-drop, the 5.6 original 50multi-drop and the 5.5 dungog revised 50multi-drop to allow the changes I want.
But it does seem pretty uphill compared with the '30 secs with text editor on fetchmailrc' approach.
Am I missing something very fundamental here? Or is this [the 'subsequent custom-template changes overwrite issue'] a genuine shortcoming of the template-overlay schema?
elJ
PS, I'm a Linux-naif really - is the purpose of the here-document-created .fetchmailrc to enhance security, or if not, what?
All hints/brickbats gratefully received...
-
From what I've read here, addons should not use /templates-custom/. /templates-custom/ is made for machine-specific customizations. The author really should use a modified /templates/ fragment. You may need to alter your custom files to produce the desired result after installing a new addon, but their defaults shouldn't overwrite your customizations...
I'm not involved with the production of SME software, but I think they use the template system to provide an easy way for the system to be greatly modified, while at the same time allowing it to be returned to default with almost no effort. It also allows the configuration to be easily rebuilt by the system if something comes up. When using SME, keep in mind that it's really aimed at smaller offices with real IT staff. If they can be talked through entering one line at a command prompt to fix everything, that's much better than having them try to edit files and all the other stuff that usually goes along with fixing computers...
-
Bill Talcott wrote:
>
> that it's really aimed at smaller offices with real IT staff.
Errrr, "NO real IT staff"...
-
Bill said:
>From what I've read here, addons should not use /templates-custom/. /templates-
>custom/ is made for machine-specific customizations.
Thanks for the reply. Hmm, I must be misunderstanding this. I based my actions on the document at
http://www.e-smith.org/custom/
I f I revise the base template, any upgrade would overide my revision. The referred doc specifically recommends using templates/custom for such customisations. But there's a problem if two authors attempt to override the *same* default template, it seems to me.
I searched on the phorum before posting my original request, but found no direct reference to this issue. I *did* find one post jokingly suggesting three levels of templating, and suspect that may be related to this issue.
>When using SME, keep in mind that it's really aimed at smaller offices with (no) real IT staff. If they can be talked through entering one line at a command prompt to fix everything, that's much better than having them try to edit files and all the other stuff that usually goes along with fixing computers...
Well, yes. I suspect you also meant not 'a command prompt' but 'a web form'. With the sorts of users we have, I wouldn't even let them near a web form :-) If they can handle a command prompt they could handle a .fetchmailrc!
I'm starting to see that the real issue here is, what is the canonical reference? I hadn't really though about this before, but in *nix systems, the canonical reference traditionally used to be the .config file (or other plaintext configuration file) that defined the options controlling the system: cf Windows, where it used to be the *.ini file, and later moved (mostly) to the registry.
But in SuSE, and RedHat, Mandrake, and of course e-smith/SME, that is no longer true (but with different details). The GUI is the implicit canonical reference in these systems (as I found when I tried editing config files by hand in Mandrake, only to have my changes overwritten by the GUI). I am now starting to see that this just may be injecting an extra level of unmanageability, in the name of simplicity of management.
Or of course I've got hold of the wrong end of the stick (yet again!)
elJ
-
el Jaimito wrote:
>
> Bill said:
>
> >From what I've read here, addons should not use
> /templates-custom/. /templates-
> >custom/ is made for machine-specific customizations.
>
> Thanks for the reply. Hmm, I must be misunderstanding this. I
> based my actions on the document at
>
> http://www.e-smith.org/custom/
>
> I f I revise the base template, any upgrade would overide my
> revision. The referred doc specifically recommends using
> templates/custom for such customisations. But there's a
> problem if two authors attempt to override the *same* default
> template, it seems to me.
>
> I searched on the phorum before posting my original request,
> but found no direct reference to this issue. I *did* find one
> post jokingly suggesting three levels of templating, and
> suspect that may be related to this issue.
Yes, your customizations that you make should go in /templates-custom/. I've seen posts here that /templates-custom/ is made only for your personal customizations, and any addons should use /templates/ for their files. In other words, multipop's default files should not overwrite your custom files. They should go in /templates/, not /templates-custom/. But like you said, this can cause problems if you have two addons attempting to alter the same file. The three-level template system might help, but you'd still run into this unless you had a dir for each addon, which would probably make things ten times more complicated. Obviously, it's best if you can add a new fragment for your addon, but sometimes the existing stuff simply NEEDS to be changed...
> >When using SME, keep in mind that it's really aimed at
> smaller offices with (no) real IT staff. If they can be
> talked through entering one line at a command prompt to fix
> everything, that's much better than having them try to edit
> files and all the other stuff that usually goes along with
> fixing computers...
>
> Well, yes. I suspect you also meant not 'a command prompt'
> but 'a web form'. With the sorts of users we have, I wouldn't
> even let them near a web form :-) If they can handle a
> command prompt they could handle a .fetchmailrc!
I did mean command line. I meant that it's easier to say tell them to type "/sbin/e-smith/expand-template /etc/program.conf" than it is to have them load the file into pico, find the bad part, edit it out, and save the file.
> I'm starting to see that the real issue here is, what is the
> canonical reference? I hadn't really though about this
> before, but in *nix systems, the canonical reference
> traditionally used to be the .config file (or other
> plaintext configuration file) that defined the options
> controlling the system: cf Windows, where it used to be the
> *.ini file, and later moved (mostly) to the registry.
>
> But in SuSE, and RedHat, Mandrake, and of course e-smith/SME,
> that is no longer true (but with different details). The GUI
> is the implicit canonical reference in these systems (as I
> found when I tried editing config files by hand in Mandrake,
> only to have my changes overwritten by the GUI). I am now
> starting to see that this just may be injecting an extra
> level of unmanageability, in the name of simplicity of
> management.
Well, if you know what you're doing, you can delete the default templates and write your own files. However, I usually find it just as easy to make a custom fragment as to find the right part of the file and edit it. Some fragments contain code to handle all the ibays for example. Changing one little thing in a fragment can apply the change to all the ibays, and provides only one place to screw something up, instead of ten. I think (not 100% sure) you can even just write your own custom .conf file in the /templates-custom/ dir, instead of actually making a templated version of your custom file. Again, this allows a quick fix without screwing everything else up.
-
Bill replied:
>Yes, your customizations that you make should go in /templates-custom/. I've seen posts here that /templates-custom/ is made only for your personal customizations, and any addons should use /templates/ for their files. In other words, multipop's default files should not overwrite your custom files. They should go in / templates/, not /templates-custom/.
Well, sure, but multipop IS a customization of the existing templates to permit multiple pop account mail collection.
>But like you said, this can cause problems if you have two addons attempting to alter the same file.
Well, yes, it does. The doc here says:
"Do not modify existing templates in /etc/e-smith/templates/ as your changes will be overwritten when packages are upgraded."
Which is clear (and obvious) enough. If multipop is written so as to change the base level templates, it will be overwritten on upgrades. If it uses templates-custom tree, as recommended, then there is potential conflict between this template override and any other (such as my proposed alteration).
The diff+patch I propose does currently work round this, but it's crude.
If the original config files were canonical this would not happen (I think!)
Anyway, the system is how it is. But running into this issue has made me revise my ideas on the generality of application of the e-smith/SME solution. I still think it's pretty neat, but every design decision has its' implications, and I'm now understanding what they are in this case.
Any comments on whether my proposed solution/fix/bodge-up (using a diff and patch) is workable/appalling/despicable? :-)
elJ
-
Why not ask Steven Noble at Dungog to mod the Multipop addon to provide the control you want - it might be possible to add the option as a checkbox for each of the accounts from which mail to to be collected.
Sorry for the extra work Steven :-)
-
>Why not ask Steven Noble at Dungog to mod the Multipop addon to provide the control you want - it might be possible to add the option as a checkbox for each of the accounts from which mail to to be collected. Sorry for the extra work Steven :-)
Nice suggestion - I'll ask him :-)
elJ