Tiny Core Linux
Tiny Core Extensions => TCE Talk => Topic started by: Jason W on August 22, 2009, 09:04:21 PM
-
As the intention has been announced of migrating to one extension type, it is time to replace the user.tar.gz in extensions with scripted routines. I will start migrating my extensions to this new approach now. Please use this thread to point out any extensions that need such attention or for any questions.
-
replace the user.tar.gz in extensions with scripted routines
So if there is a file, say etc/something.conf for example, in my something.tcz extension, it will be created as a softlink to /tmp/tcloop/something/etc/something.conf. Are you saying I should have
cp -f /tmp/tcloop/something/etc/something.conf /etc/
chmod +w /etc/something.conf
or similar instead of placing etc/something.conf in my user.tar.gz? If not, can you provide a small example of what you mean?
Thanks,
Daniel
-
Here is what I have in the tcp_wrappers script.
[ -f /tmp/tcloop/tcp_wrappers/usr/local/etc/hosts.allow ] && cp -Rp /tmp/tcloop/tcp_wrappers/usr/local/etc/hosts.allow /usr/local/etc/
[ -f /tmp/tcloop/tcp_wrappers/usr/local/etc/hosts.deny ] && cp -Rp /tmp/tcloop/tcp_wrappers/usr/local/etc/hosts.deny /usr/local/etc/
[ -e /etc/hosts.allow ] || cp /usr/local/etc/hosts.allow /etc/
[ -e /etc/hosts.deny ] || cp /usr/local/etc/hosts.deny /etc/
I have not yet downloaded the new RC to see the code, doing that now, but the above would give the same result whether being used in copy-to-system mode or mounted. The first two lines of course would only copy in case of mounted use, the second two would run in either case. Depending on the copy flags being used, "busybox cp" may need to be called as some options are unique to coreutils vs busybox. -Rp may not be needed, but it is my usual invocation I use on my own time and would work for directory contents.
-
cp -a could be used (short for -dpR). These options are the same in both afaik.
-
Thanks, that would be better, "cp -a".
Also, it seems coreutils cp will not overwrite the existing symlinks with "cp -a". Busybox cp does, so perhaps the best for now is "busybox cp -a".
-
When I create an extension that has a config file I rename that file to something like extension.conf.orig. Then use a startup script with the following:
[ ! -e /usr/local/etc/extension.conf ] && cp -p /usr/local/etc/extension.conf.orig /usr/local/etc/extension.conf
this gives the user the original file as a backup, an editable file when using a tcz, does not overwrite any previous user files, and works for both extension types.
Using the -a flag with a tcz extension will just copy the link, not the file, so -p is used instead
-
That is a good way to handle configs. But coreutils "cp -p" will complain that the symlink being overwritten and the file that is being copied are the same file and nothing is done, even if -f is used. So I reckon busybox still needs to be declared so it will work when coreutils is installed.
-
The script isn't replacing any files though. I'm copying the .orig file over to the config location only if the config file is not present.
The config file is named extension.conf.orig in the extension itself, it is not being replaced.
-
Ok, but the replacing would occur for non config files like firefox, firefox-bin, python files in /usr/local/bin that would not need copying in the case of a load-to-system use. Though those files could be stored in, say, /usr/local/share/firefox/ as firefox.orig or firefox-bin.orig and then be copied to the system. But that would be copying them in the case of a load-to-system instance where copying would not be needed, only in the tested case of mounting/symlinking. Either way would not be wrong I think, though.
-
Though choice is good, standardization would reduce confusion in this regard. And keeping files that the script would copy over in a certain place to be copied in the case of both extension uses would be less confusing. Say moving /usr/local/bin/app to /usr/local/share/app/app.orig so it would be copied to /usr/local/bin/ by the script in the case of either mount or copy-to-system would make the scripts more symmetrical across uses and less confusing. And would eliminate the need to overwrite symlinks.