tc-config runs tc-restore.sh too late

[philip]

Summary: Please consider modifying the bootup script /etc/init.d/tc-config so that tc-restore.sh gets invoked earlier.

Rationale: My TC-2.0rc3 install starts very slowly because I need the openssh extension. That package comes with a script called /usr/local/tce.installed/openssh whose job is to make sure the system has usable encryption keys in the right places. If the keys are missing, the command ssh-keygen is used to make new ones. My hardware is old, so this takes several minutes. Now here's the kicker: the keys are missing every time -- in spite of being mentioned in /opt/.filetool.lst -- because the bootup process runs the script just mentioned before restoring the files in my backup. So I wait a long time for ssh-keygen to make new keys, and then they get obliterated immediately as the saved ones are overwritten on top of them. So I suggest re-sequencing /etc/init.d/tc-config a little, to restore files from the backup before running the extension-setup scripts. I tried this on my own system with good success.

Brainstorming: Restoring files from the backup early gives users more influence on how the boot process goes forward (probably good), but increases the risk that the boot process will overwrite files that the user has customized (probably bad). If my suggested re-sequencing is immune to the latter risk, please do it. If it's not, more thinking will be needed. We could read the files from the backup twice: once before the extension scripts get executed and once more afterward, just in case any user-generated files got damaged. Or we could make one of those two steps optional, to be triggered with yet another boot parameter. I'm sure our crack development team can come up with additional possibilities and implement the best of the bunch.

Thanks.

[curaga]

In previous versions the backup was restored before extensions, but it was modified to be later for the exact reason you saw too - user-customized files would not overwrite fresh ones from extensions.

Extracting the backup twice would take system resources, in case the backup was big. But as the goal is to only have dynamic content there, and static content in an extension, it might be viable.

On the other hand, since your keys are very unlikely to change, why not make an extension out of them? It would guarantee being loaded before the installation scripts, and save backup time too.

[philip]

... since your keys are very unlikely to change, why not make an extension out of them?

This is an interesting suggestion and I will look into it.

The short answer to your question is a combination of, "I didn't think of it" with "I don't know how." So I'll go learn and report back ... no problem. But, considering TC as a whole, I'm nervous about the level of technical expertise this kind of response demands of a general user. So I'm asking for a little more discussion of the design decision at work here.

More brainstorming: what if the system were built to look for an optional second list of files that gets treated almost exactly like /opt/.filetool.lst, only restored earlier in the boot sequence? We could call it /opt/.filetool-early.lst and mention how to use it in the notes that support the openssh extension. Figuring out how to succeed with a setup like that is well inside my "naive user" comfort zone; building extensions isn't.

[Guy]

In regards to:

why not make an extension out of them?

I don't know how.

Here is how to make an extension of background images.

/background.html][removed due to policy violation]/background.html

You could do the same type of thing with the files you want in an extension.

[roberts]

I have always promoted factoring out static content from one's backup into personal tces.

Don't think of it as I need to learn how to make an extension. After all the backup (mydata.tgz) is really the same format as a tce. While true, most extensions have menu items and icons, but they are not required.

Since you already have identified your ssh files in .filetool.sh, the hardest part is already done.

Copy .filetool.lst to say for example myssh.lst. Next edit out all the lines except those for your ssh configuration from myssh.lst.  Then issue a tar command like this:

tar -C / -T myssh.lst -zcvf myssh.tce

Copy your myssh.tce to your tce directory. Done.

[philip]

... the backup (mydata.tgz) is really the same format as a tce.

Until today, I didn't have to know the details of how the backup process worked or how to make my own tce. Of course I'm happy to learn, and happy that RobertS solved my problem with two shell commands, so Thank You! However, I still feel that this kind of intervention is at the outer limits of "Novice-friendly up and coming alternative distro". (Am I correct in thinking we'd like TC to fit some such description?)

An important part of "novice-friendly" is documentation. In some other projects I follow, people who learn something in the forums are encouraged to summarize it in the wiki. This is a good understanding to promote, and I'll give some thought to taking my turn thanks to this thread. Not tonight, though: writing something presentable for a wiki is surprisingly time-consuming! (YMMV)

[roberts]

Documentation is always needed. But to consider anything distribution offering only core, i.e., not turnkey, I would not presume to be novice friendly.

[philip]

Documentation is always needed. But to consider anything distribution offering only core, i.e., not turnkey, I would not presume to be novice friendly.

For me TC has been very intuitive and easy to use right from the start. "Novice-friendly" is not out of TC's reach, although I can understand that in these early days it's not the priority. For now, I'll settle for novice-friendlier, , and contribute to the docs as and when I can to help with that.

[SvOlli]

I'm having a similar problem starting dropbear via boot parameter: first dropbear is started and later on the keys are extracted from mydata.tgz. Shouldn't dropbear be started after unpacking mydata.tgz? See attached patch for my suggestion how it should be.

[roberts]

You can start dropbear from /opt/bootlocal.sh which is after restore process.

[SvOlli]

You can start dropbear from /opt/bootlocal.sh which is after restore process.

Yes, that is a workaround, but I think for 2.1 ssh should be started after unpacking mydata.tgz, since a later start of ssh is no loss at all.

[philip]

... a later start of ssh is no loss at all.

Better than "no loss at all", a later start of ssh is probably a wise security practice. Having the system in a settled and secure state before outsiders can connect sounds like a great idea.

[roberts]

You can call it a "workaround", I call it consistentcy. Boot time are before restore, /opt/bootlocal.sh is after restore. So what is being proposed is not a bug fix but an exception to the rule.
Perhaps in the case of ssh it is appropriate.

[roberts]

sshd starting moved to after restore. Will be in 2.1rc2.

[SvOlli]

Thanks! :-)