SoftDux
to reinstall all those contribs is a pain in the neck
Agreed, but that's how the sme server backup and restore concept works. It's a development design decision.
If you want to change it or create another way of doing it, then take your requests and/or code to the bugtracker please.
See the link to dmay's howto in another post re building a sme6 ISO, and many other posts on the subject from a couple of years ago, I don't know how much of it will still apply to sme7.
Keep in mind that a lot of people got badly stung using a unofficial highly customised release of sme6.01.xx when upgrade time came, as there were many incompatibilities (rpms etc) that broke the standard upgrade process.
At that time some blame was cast at developers for upgrades that went wrong, but that release was not created by the main developers. In actual fact the developers did a lot of extra work in future releases to try and overcome the issues caused by the unofficial "gung ho" ISO release.
I hear what you're saying, but that's only going to be the case if one installs a new version of SME than what was installed before the problem arose.
There were two parts to my answer, one is that restoring "executables/binaries" is fraught with problems, the other related to incompatible rpms versions. They are separate issues and you ignored the first one, which I gather is the bigger problem. Charlie Brady advised/informed of the first issue some time ago in these forums.
what about scripts that expect config files in /etc? What will happen if I backup the whole /etc folder? Could it cause problems upon restoration?
Yes you will have problems, the issues are similar to that mentioned above.
Only some of /etc is backed up, here is the standard inclusions
/etc/e-smith/templates-custom
/etc/e-smith/templates-user-custom
/etc/group
/etc/gshadow
/etc/passwd
/etc/samba/secrets.tdb
/etc/samba/smbpasswd
/etc/shadow
/etc/smbpasswd
/etc/ssh
/etc/sudoers
/home/e-smith
/root
Note that all /etc/config files are a result of system installed code or template code or custom template code.
A new install of the OS installs standard /etc/config files, rpm contribs install additional templates that create additional or add to /etc/config files and custom template changes also add to /etc/config files. Only custom templates are included in back ups, as all the rest are easily recreatable.
..with "custom templates" .... contrib writers should actually be using that custom templates?
No, they should use the templates folder. It all ties in with the concepts we have been talking about throughout this thread ie a reinstall of contrib rpms will add new templates to the templates folder.
How does this work? How do I add upsmon or mrepo for example to a custom script?
It's time for me to point you to the Developers Guide, which you should read extremely slowly and work through the examples given on a test server. Then read it again another two or three times.
If you want to do development work, use the devinfo list (although I think that is not being used so much these days), or open specific bugs to track development of a particular rpm/function/code (which seems to be the preferred approach these days).
http://wiki.contribs.org/SME_Server:Documentation:Developers_ManualWhat I meant with "include & exclude", is say I want to include the whole /etc folder in the backup, but exclude a few files folders from /etc, instead of choosing each & every file in /etc to include...
The DAR2 contrib has sections for Backup selections, Prune directories, and Exclude files, so you tailor it as you wish.
The general approach you are referring to (backup & restore of contribs) will no doubt cause you problems later, so I seriously suggest you do not try to change the underlying concept.
Search these forums a lot more ie particularly on posts by Charlie Brady as he has given us all some real "gems" of information, not to overlook many others who have told us a lot of useful info as well eg Gordon Rowell and Shad Lords etc.
Some advice.
A lot of development work has gone into the sme server over many years and it is an accumulation of much knowledge and experience, and long ago determined design criteria. Of course change is implemented as practically required and as developer time input allows. This is free software to most of us, but many have paid the price somewhere along the way, usually in contributed time or paid for specific sponsored development effort.
You seem to want sme server to be something else or perform differently accordingly to your desires or the way you see it. I suggest you use the software as it is, keeping in mind the considerable degree of effort that has got it to where it is today, far more effort than you could ever do.