Tiny Core Base > TCB Tips & Tricks
nobackup bootcode?
clach04:
--- Quote from: gerald_clark on September 29, 2009, 01:24:58 AM ---You can look at /etc/init.d/tc-config.
--- End quote ---
Just the info I needed, thanks! Here is my quick-n-dirty grep that shows TC bootcodes (whether they are documented at http://www.tinycorelinux.com/faq.html#bootcodes or not, e.g. theme):
--- Code: ---tc@box:~$ grep ')' /etc/init.d/tc-config |grep ';;' |grep -v 'case '
waitusb*) WAITUSB=${i#*=} ;;
lang*) LANGUAGE=${i#*=} ;;
kmap*) KEYMAP=${i#*=} ;;
tz*) TZ=${i#*=} ;;
desktop*) DESKTOP=${i#*=} ;;
user*) USER=${i#*=} ;;
home*) MYHOME=${i#*=} ;;
cryptohome*) CRYPTOHOME=${i#*=} ;;
tcvd*) TCVD=${i#*=} ;;
opt*) MYOPT=${i#*=} ;;
local*) LOCAL=${i#*=} ;;
dosswapfile*) DOSSWAP=1; SWAPFILE=${i#*=} ;;
tce*) TCE=${i#*=} ;;
resume*) RESUME=${i#*=} ;;
host*) HOST=1 ;;
settime*) SETTIME=${i#*=} ;;
thm*) THEME=${i#*=} ;;
bkg*) BACKGROUND=${i#*=} ;;
nofstab) NOFSTAB=1 ;;
syslog) SYSLOG=1 ;;
noutc) NOUTC=1 ;;
nodhcp) NODHCP=1 ;;
checkfs) CHECKFS=1 ;;
noicons) NOICONS=1 ;;
text) TEXT=1 ;;
superuser) SUPERUSER=1 ;;
noswap) NOSWAP=1 ;;
secure) SECURE=1 ;;
protect) PROTECT=1 ;;
ssh) SSH=1 ;;
cron) CRON=1 ;;
xsetup) XSETUP=1 ;;
laptop) LAPTOP=1 ;;
base) ONLYBASE=1 ;;
norestore) NORESTORE=1 ;;
noautologin) NOAUTOLOGIN=1 ;;
pause) PAUSE=1 ;;
--- End code ---
(modified with slight re-wording of what this list is)
clach04:
--- Quote from: roberts on September 29, 2009, 08:03:45 PM ---I have, in fact, been considering a change in this area.
First, I see new users confused when they first encounter the exit routine.
No backup can be performed because, no location was ever specified.
......On the other hand, I have provided the env BACKUP to control where a backup should be performed or not. Setting this to 0 stops any request to do a backup.
......I am considering having the norestore option causing the backup box to become unchecked.
Thereby using norestore would also mean no backup, unless you take action to indicate otherwise.
To to help the new users, if no backup was specified and no norestore was indicated and BACKUP is set to 1 and a 'tce' was found, then default to using the 'tce' directory location. This would be consistent with the usbinstall method of defaulting the backup to be in the tce directory.
--- End quote ---
That would be great if this could be added. One thing I've noticed is that the user .profile is always the same as the skeleton version, i.e. "diff /etc/skel/.profile .profile" shows no differences.
How about when creating the user .profile script it isn't a straight copy but instead something like:
--- Code: ---. /etc/skel/.profile
--- End code ---
This way users who want to backup their home directory will be more resilient to upgrades where the skeleton version may get updated.
From the tc-config script (setupHome) it looks like the skel dir is simply a straight copy (not just this file), maybe the "default" skeleton shared profile could be renamed/moved somewhere else?
Also if the norestore option was set the skeleton version could do something like:
--- Code: ---if [ -z "${BACKUP}" ]
then
echo z true
export BACKUP=1
fi
--- End code ---
so if backup is not set, it defaults to on, if it is set the setting is unchanged. The tc-config could then set BACKUP=0 if NORESTORE is set in the user .profile script, e.g.:
--- Code: ---setupHome(){
tar -C /etc/skel -cf - . | tar -C /home/"$USER" -xf -
# gen profile
touch /home/"$USER"/.profile
chmod a+x /home/"$USER"/.profile
if [ "${NORESTORE}" = "1" ]
then
echo 'export BACKUP=0' >> /home/"$USER"/.profile
fi
echo '. /etc/whatever_shared_profile_is_called' >> /home/"$USER"/.profile
chown -Rh "$USER".staff /home/"$USER"
chmod g+s /home/"$USER"
}
--- End code ---
The above is a quick copy/paste of the existing routine with a few (completely untested) tweaks.
Comments? Does this approach veer off the TC approach?
Chris
mikshaw:
The etc/skel directory, as far as I know, has always been used only as a source for default user configs, for when a new user is created. After the user's home is created, those files have nothing to do with that particular user. This is as it should be. A user then has complete control over his personal files, and the system administrator can make whatever desired changes to /etc/skel without affecting the existing users.
Navigation
[0] Message Index
[*] Previous page
Go to full version