PDA

View Full Version : ~/etc/



sireasoning
01-09-2003, 07:37 AM
What would be nice is to have /etc in the home directory and have knoppix supercede any configuration from the cd /etc with ~/home/etc/* (esp while using persistant home). This would allow for specific configurations such as the hosts file to be included at boot.

lilliput
01-21-2003, 08:08 AM
I'm searching the same things...
My idea was something like this

persistant mount the /dev/hdax partition

directory; just link* if present in the persistant "home" partition
| to directory in the / Filesystem
hdax---/ \/
----/home/knoppix/
----/etc/.../
----/usr/local

I have test and he works fine but i haven't create a script..
We need 2 scripts one to copy all the requires file (during the install process)
and the second to mount the partition during the boot.

link* I do not know when the persistant home script is launch but to create the link we have to do something like ..
erase the real directory from the ram memory and creat a symbolique link ... (ln -s )
or directly change the directory inode (I don't think it's possible in a script)
If you have any suggestion


__________________________________________________ ____________________________________________
lilliput@free.fr
Smaller we are, bigger our exploration is...

sireasoning
01-21-2003, 01:04 PM
the main problem with that approach is when you change computers (one of benefits of Knoppix). That is why only certain files need to be changeable in ~/.etc (and supercede /etc) and then let knoppix auto create all others. How does one make /home/knoppix/.etc supercede /etc? Is there a path statement for config files?

I have replaced /usr/local with ~/bin although I like that idea. What about ~/local? That would only require a change of the path statement to include /home/knoppix/local/bin. That should be minor enough to be included, esp in conjunction with persistant home.

lilliput
01-21-2003, 02:54 PM
I was thinking about an another things ..
If you burn persistant home in you have burn home persistant in your cd ;; when you boot in a normal PC it's the same as usually (you have even the option "boot : knoppix nohome")...
So we could add in this script the new linking way ;;;

When I was speaking about ~/etc/... it's not a burn on the cd it justt a partition who has been mount dutring the boot wiith home persistant and which the script has re-link the directorie ... (if I'm not clear, tell it me, I'm not english ...)
The approach could be in different way the script burn doesn't need to change I think, I've to look more about it...

__________________________________________________ ___________
lilliput@ifrance.com

sireasoning
01-21-2003, 09:18 PM
To make sure we are on the same page I will rehash our approaches:

my understanding of your approach:
using persistant home to store on the hard drive (or usb pen drive, etc) the home directory, /etc, and /usr/local. At bootup with persistant home the stored directories are then symlinked into the directory tree replacing the ones normally created by Knoppix.

my approach:
Knoppix adds /home/knoppix/local/bin and /home/knoppix/local/sbin to the path statement and creates a /home/knoppix/local directory with the normal subdirectories.
Knoppix also makes a change in how /etc is referenced so that it first checks /home/knoppix/.etc then /etc for the configuration to use. This way any changes made in ~/.etc will supercede /etc allowing for only specific changes to be made (and unmade if necessary).

my evaluation:
I think either version of the local directory would work well. The only reason I might prefer my approach is that it would not depend on persistant home to be used and it only involves a minor script change.

As far as /etc goes. The greatest weakness to your approach is that the stored /etc drive may have portability problems accross machines. For instance, if the only thing you need to change is the /etc/hosts file, one would still have all of the stored settings in say /etc/sysconfig or /etc/fstab from their old machine. With only certain files stored in ~/.etc I think it is more portable and it also does not rely on using persistant home.

Another possible approach:
I haven't fully thought this out yet, but what about having a /home/knoppix/.root directory with a full directory tree. Anything in this directory tree would supercede aything in /. This tree would only be populated with changes and would be checked first (and maybe any changes would be symlinked into the main tree.) Using this approach a script could be written to search ~/.root and if it finds anything there it creates a symlink in the same position (overwriting what was in main). This script would be accessible from the KNOPPIX menu so that after changes are made, they can be implemented through this script. As a failsafe the script can first make the old item in root into a .old file before it replaces it. For instance, we would handle /etc and /usr/local in the following way:

~/.root/usr/local
the path statement in Knoppix would begin with the following lines:
/home/knoppix/.root/bin, /home/knoppix/.root/sbin, home/knoppix/.root/usr/bin, /home/knoppix/.root/usr/sbin, /home/knoppix/.root/usr/local/bin, /home/knoppix/.root/usr/local/sbin, /home/knoppix/.root/opt/bin, /home/knoppix/.root/opt/sbin, (rest of existing path)

This would not need to be symlinked or replaced, just a change to the path statement works here.

~/.root/etc
Lets say this only contains a hosts file (~/.root/etc/hosts). The script would read this, change /etc/hosts to /etc/hosts.old and symlink ~/.root/etc/hosts as /etc/hosts

So now instead of just persistant home, we have a form of persistant root. This approach may be superior than the first two in that it creates a whole new territory of possibilites and configuration playing for advanced users. For instance, an admin could just burn Knoppix CD's for workstations and store on the local hard drive (or connect through NFS to a central hard drive) all office specific configurations and programs. The main OS would be impervious to attacks and upgrades would be as easy as burning the latest Knoppix CD's. If the upgrade fails, put back in the older cd. This may broaden Knoppix's reach considerably!

Schwarze
01-21-2003, 10:40 PM
Hi sireasoning, hi lilliput.

Just out of curiosity: What's wrong with saveconfig? It collects all changed files under /etc and saves them to floppy (or a persistent home).

I think, this comes pretty close to sireasoning's idea. Furthermore you don't depend on KPH (but you can take advantage of it) and it's already on the CD. :wink:

Matthias

audioaficionado
01-21-2003, 11:06 PM
I've only run Knoppix Linux so I'm still a newbie's newbie. Most of what you've said is beyond me at this time. However, what I'd like to see is a hard drive config save option built in to Knoppix out of the box. Knoppix would always look for these config files and then give you the option to use them, maybe choose from several that you'd named as say KDE.knx, IceWM.knx, steve's custom.knx, etc. If you don't want to save a config (say you really hosed your last session) you just say no to the save config option as you log off. Next session, you pick from your saved good configs.

BTW you could burn your HD config files to CD-R/W and when you get on another PC, you copy them to the HD and then boot into Knoppix and pick up where you left off on the last PC. Of course Knoppix always has to auto detect hardware every session as it won't know anything about the PC it's on or the last session until it checks the hardware first and then access the configs. If the last configs are incompatible with the differant PC's hardware, then it will default to the just detected settings.

I know what I'd like but not how to do it.

01-22-2003, 05:58 AM
I'm totatly agree with the third proposition ...
There no problem at all for the ~/.root/local and etc...

~/.root/etc your suggestion to rename hosts to hosts.old is great ()

Oups I forget why not create a particular directory in the /
like /persitant (just an example) could be better in the case we add user
with different access right. And more easily to access to install some applications

(why not ...We could apply a persitant_home for each user of couse without general config file.. and duplicate the
/home/knoppix to
/home/user1 and apply the persistanthome to this user1 home)


This solution is clean and proper

So to resume:
1) Make the /etc modification
(we have to look if all the "new" files have been loaded ie fstab)
2) Link the applications directories
3) Link the other users directory
3) apply the actually persistant home to get the config
4) i don't miss to update the $PATH, generate a script to launch with .bashrc or something like that
5) If more than 1 user (exept root) ask fort the login
6) I think it's finish


Any suggestion and critic of course is welcome
I prefer critic because the work is more construct after.
Sorry about my english errors

lilliput
01-22-2003, 06:01 AM
Oups I didn't send my post rapidly so no login ...sorry ..

sireasoning
01-24-2003, 08:04 AM
Hi sireasoning, hi lilliput.

Just out of curiosity: What's wrong with saveconfig? It collects all changed files under /etc and saves them to floppy (or a persistent home).

I think, this comes pretty close to sireasoning's idea. Furthermore you don't depend on KPH (but you can take advantage of it) and it's already on the CD. :wink:

Matthias

I have been playing with saveconfig and it does some things well but fails in others. For instance, say I wanted to build a module for my winmodem. There is a program available called ltmodem that will do this. It will also create a deb file. I tried to get it to install to the root system but it failed (mostly because of all of the links to the cdrom. However when I removed those links and copied those files into the root tree, it still failed.) However, even if I had succeeded, it would have been gone by the next boot. However with a ~/.root directory tree I could concievable copy over the relative files needed to its proper place in the ~/.root tree, then installed chroot ~/.root or something like that. Maybe the deb file installer can be modified to install to the .root tree, copying over any existing files from the current root tree that need to be modified? This would allow specialty installs that can be portable with a usb pen drive, etc.

Also, when will persistent home be part of the knoppix startup so that a floppy would not be necessary with persistant home?

lilliput
01-24-2003, 10:26 AM
And I have no floppy drive on my ladtop...

Schwarze
01-24-2003, 11:31 AM
...but you know about the option to run KPH directly from the CD without the floppy?

If KPH will be included in future versions of KNOPPIX (and this seems to be BIG point for many people - at least when i look at my email inbox) it will behave exactly like this (except knoppix.sh will be renamed).

Matthias

sireasoning
01-25-2003, 10:45 PM
...but you know about the option to run KPH directly from the CD without the floppy?

If KPH will be included in future versions of KNOPPIX (and this seems to be BIG point for many people - at least when i look at my email inbox) it will behave exactly like this (except knoppix.sh will be renamed).

Matthias

The only option I know of is to rebuild the knoppix cd with persistant home's knoppix.sh. Is there another way?

Also, along the lines of the .root file, what about profiles? I may want things more specific on a certain computer on the local lan, but I may want a different setup for any general computer I may "take over" on the road. As far as seperate .root directories go, there could just be links to the items that want to be kept (such as installed programs and their libraries) while allowing knoppix to build its own (such as /etc/fstab, X, etc).

lilliput
01-29-2003, 04:46 PM
If think I have found the simple way to install some application ..
but i have still a little pb !!

the command I'd used are :

lndir /KNOPPIX/usr /mnt/hda2/install_dir
mount --bind /mnt/hda2/install_dir /usr

but the problem is that I can not access to much of applications after ...
Why ?? /KNOPPIX/usr is different from /usr or is something bad on command ..?

So I return to my try .. and doc yeap MAN PAGE !!!! I love IT LOL ;-)

__________________________________________________ ___________

Un lilliputien en délire ....

sireasoning
01-29-2003, 05:31 PM
If think I have found the simple way to install some application ..
but i have still a little pb !!

the command I'd used are :

lndir /KNOPPIX/usr /mnt/hda2/install_dir
mount --bind /mnt/hda2/install_dir /usr

but the problem is that I can not access to much of applications after ...
Why ?? /KNOPPIX/usr is different from /usr or is something bad on command ..?

So I return to my try .. and doc yeap MAN PAGE !!!! I love IT LOL ;-)

__________________________________________________ ___________

Un lilliputien en délire ....

It doesn't appear that you have really done anything different. Currently /usr is just linked to /Knoppix/usr. What you did was create a link to /Knoppix/usr, mounted it in a different directory and then remounted it as /usr. The only way the above would work (with persistent home) would be if you had enough hard drive space to do something like this:

mkdir /home/knoppix/.root
cp -R /Knoppix/usr /home/knoppix/.root/
mount --bind /home/knoppix/.root/usr /usr

However /usr is huge and it would seem you would need a VERY large usb pen drive to do it this way. Now if you could install a program chroot /home/knoppix/.root then have the system be able to check there first then goto /, I think that would be more efficient. This is easily done via the PATH statement as long as it is checked first for executables, however, where I get lost are things like lib, etc and other crucial directories and links, especially if you have to add a module to the kernel (such as for a winmodem.)

lilliput
01-29-2003, 05:59 PM
no because lndir create just a link so nott very big !!

sireasoning
01-29-2003, 06:18 PM
the link is your problem though! Lets call /Knoppix/usr = K, /usr = u and your new mount in /mnt = m.

Your approach:

K > (link) m > u

Knoppix approach

K > u

outside of the extra step, there is no difference. Both eventually link back to K. The reason you have problems with installing is the inability to overwrite links, especially those further down the directory. For instance, if only the file is linked, that file can be deleted and you can replace it with a file of your own. However, if a whole directory is linked and you have to go down a directory or two to get to your file. You cannot delete that file because once you entered the linked directory (in this case /usr linked to /Knoppix/usr), you are being actually sent to the /Knoppix/usr directory on the read-only cdrom. Even your redirect does not change this.

lilliput
01-29-2003, 07:37 PM
I solve my pb by ..
mkdir /mnt/hda2/usr
lndir /KNOPPIX/usr /mnt/hda2/usr
rm -f /usr
ln -s /mnt/hda2/usr /usr

But you were rigth my /mnt/hda2/usr is enough heavy 106M I think thats because there is too much little file and "format" with good option would be better.
But what do you offer to get it ??

lilliput
01-29-2003, 07:38 PM
I mean for a better solution ..

01-30-2003, 04:50 AM
Ok I found a solution to install *.deb;
___________
dpkg -x name.deb ~./root
___________
and for compile a src ..
./configure --prefix=~./root
make
make install
___________
it was enough simple .. !!
so now we have to look for the /etc ..

lilliput
01-30-2003, 04:54 AM
sorry i was not login and make mistake /* */
_____________________________________
Ok I found a solution to install *.deb;
___________
dpkg -x name.deb ~/.root/usr
___________
and for compile a src ..
./configure --prefix=~/.root/usr
make
make install
___________
it was enough simple .. !!
so now we have to look for the /etc ...

lilliput
01-30-2003, 07:10 PM
question to sireasoning;

Why do you want to put all the application and config file in ~
(/ramdisk/home/knoppix).
why knoppix and not directtly in /ramdisk/home/.usr
in case more than we add user ..?
Have you some idea to ./etc

I think all our modifications must be load & run in the "preknoppix.sh" script ..

sireasoning
01-30-2003, 11:21 PM
question to sireasoning;

Why do you want to put all the application and config file in ~
(/ramdisk/home/knoppix).
why knoppix and not directtly in /ramdisk/home/.usr
in case more than we add user ..?
Have you some idea to ./etc

I think all our modifications must be load & run in the "preknoppix.sh" script ..

Actually, that is a pretty good idea as long as persistant home covers the /home directory and not just /home/knoppix.

This may actually offer a way to have different setups for different computers:

for instance:
/home/bootscript (or some other more flattering name... maybe bs for short) could be the root change directory.
Then you would create subdirectories for each instance.... like /home/bootscript/laptop and /home/bootscript/generic
from there you could have the root tree with all /etc and /var files being copied over to the main root tree, all /bin; /sbin; /usr/sbin/; /usr/sbin; /usr/local/bin; /usr/local/sbin being added to the beginning of the PATH and whatever we could do to have the libraries, etc added to the PATH so that the new tree files have precedence. With the persistent home option, one could therefore choose which root tree one wants at bootup.

The main obstacles to this approach would be during installation and shutdown.
For instance, installation would need a choice as to which of the new root directories (or how many of them) would get the new installations, whenever the system is shut down, which changed files from /var and/etc go where. Having these options does add a layer of complication. However for the short run, if we can get past the libraries, and other mentioned issues (which I am sure someone out there knows how to do) then we can have a single profile that should be workable, with a framework for multiple profiles in place.

It can be simple at boot to do a profile=laptop or profile=generic at boot. This could also allow for a modification to the knoppix bootscript for running certain services or disabling others, adding in needed modules (or updates), etc. Maybe even storing the kernel source (or downloading when needed without having to store it). This really expands the functionality of knoppix!

lilliput
01-31-2003, 06:58 AM
could we have soon a talk on the irc #knoppix channel ?
Could be more constructive and fast than here ..
Today I'm busy but saturday or sunday i would be free ..tell me when and i'll try to be at time;;

other people could come too of course !!

So hope to chat with you soon ..

sireasoning
01-31-2003, 07:33 AM
Where do you live? Setting a time can be challenging from different time zones :-}

I live -6 from GMT (Central Time Zone USA)

Schwarze
01-31-2003, 11:02 PM
Great idea to meet on irc! Maybe we can tweak KPH a little to meet the needs...

I'd really like to join, but i'm +1 GMT ;(
So, just to have a time base for further discussions: How about Sunday at 20:00 GMT?
I hope 2 pm is ok for you, sireasoning?!

Matthias

sireasoning
02-01-2003, 12:37 AM
I am more of a night person. You are most likely to catch me after midnight my time... and I often stay up til 5-6am. That would probably be morning for you....

lilliput
02-01-2003, 06:36 AM
time in GMT ..? ..

sireasoning
02-01-2003, 09:48 AM
midnight here is probably 6am GMT (I am -6 hours). It is currently close to 3am my time and I am getting ready to pop in for a few and see if anyone is there....

Dave_Bechtel
02-02-2003, 06:04 AM
--I haven't read the whole thread yet, so this may be a hasty reply; but here goes...

1. It would seem the best way to implement this, is to (eventually, after some testing) get it into the Knoppix "Main tree" - i.e. Klaus's ISO images. That way everyone benefits w/o extra work + DL's.

2. My easy solution for etc: Knoppix creates the initial /etc by copying from the CD, then user customizations are copied in -- to do this, /etc will probably have to be moved to /ramdisk or somewhere, and our memory requirements may go up (again. Used to be 16MB of RAM was sufficient... ;-) After /etc is stabilized, we resume startup, so apps from here on in will grab the custom stuff.

3. Modify the boot-en.img with a cheatcode to ask for a 2nd disk that contains the user's custom stuff, or to have the user type in a path to where it lives (/dev/sda, /dev/hdb1, /dev/hda1 @ /knoppix-phome.tar.gz or whatever. Jorge Garcia will probably love me for suggesting this. :lol: ) This will probably involve freeing up space on the 1.44 floppy image, which may be problematical. However, once the basic functionality is there, the end-user can then write their own code to the .img if need be, to permanently tell Knoppix where to look. (gunzip miniroot.gz to somewhere, mount it as loop, edit, re-gzip -9, cp back to .img).

--I'm going thru the rest of the thread, but just wanted to put these thoughts down 1st.

Update:

4. We should standardize on a particular filesystem, if a 2nd disk will be asked for. Floppies don't pose much of a problem, but...

5. USB pen-drives (AFAIK) only support FAT(32?), but Minix filesystem would also be worth considering for user-custom stuff, esp. as you can exec files + scripts from it; and it's more efficient. A Minix file/system (my recommendation is 20-30MB max size for easy Download, but should be less) could be on the Fat32 partition and mounted as loop, and then we could have additional *code* on the pendrive or whatever. BTW, this is also where you could store your "root directory override" stuff.

5a. (User-space issue: we'd need instructions for them on how to put the code on the drive, or just put a file up for DL and tell them how to copy the file to the 2nd-stage disk.)

5b. We'd have to umount the loop tho once done, no need to waste resources. (Unless the USB drive is where the root-override is.)

5c. The USB pendrive solution would prolly have to have a whole other cheatcode and code-section devoted to it, but also has the potential to be used with Zip drives and the like (they're mounted as SCSI. I dunno about LS120.) Modules (ppa, imm) would need to be added to boot-en.img if they don't exist there yet. (See "freeing up space on the floppy image".)

6. I just realized that Knoppix "/" is only like 2Meg. We could move the entire root directory to the Pendrive! Of course, we'd be in a world of hurt if it got disconnected, but at least the Zipdrive ppl would be Ok. ;-)


the main problem with that approach is when you change computers (one of benefits of Knoppix). That is why only certain files need to be changeable in ~/.etc (and supercede /etc) and then let knoppix auto create all others. How does one make /home/knoppix/.etc supercede /etc? Is there a path statement for config files?

I have replaced /usr/local with ~/bin although I like that idea. What about ~/local? That would only require a change of the path statement to include /home/knoppix/local/bin. That should be minor enough to be included, esp in conjunction with persistant home.

Dave_Bechtel
02-02-2003, 07:06 AM
>> Now if you could install a program chroot /home/knoppix/.root then have the system be able to check there first then goto /, I think that would be more efficient. This is easily done via the PATH statement as long as it is checked first for executables, however, where I get lost are things like lib, etc and other crucial directories and links, especially if you have to add a module to the kernel (such as for a winmodem.)

--This is kind of what /usr/local/bin is for. But for libs and stuff, you may have to re-run ' ldconfig ' - see man page for it.

--In the case of new modules, I'd push Klaus to include it. If that's not possible due to licensing or whatever, you can just mount a file over loopback that has been formatted as a filesystem (' du -s -h /lib/modules ' and make sure you DD your file to be big enough, plus a bit extra), copy /lib/modules to it, umount it, mount it as /lib/modules, and copy your kernel module to it. Then depmod -a and modprobe. Post if you need details, but check my Linuxtips page ( http://wolfrdr.tripod.com/linuxtips.html ) also.

--The only thing is that you'd have to mount the file as /lib/modules at every boot, but that's part if what KPH is going to include as functionality.



If think I have found the simple way to install some application ..
but i have still a little pb !!

the command I'd used are :

lndir /KNOPPIX/usr /mnt/hda2/install_dir
mount --bind /mnt/hda2/install_dir /usr

but the problem is that I can not access to much of applications after ...
Why ?? /KNOPPIX/usr is different from /usr or is something bad on command ..?

So I return to my try .. and doc yeap MAN PAGE !!!! I love IT LOL ;-)

__________________________________________________ ___________

Un lilliputien en délire ....

It doesn't appear that you have really done anything different. Currently /usr is just linked to /Knoppix/usr. What you did was create a link to /Knoppix/usr, mounted it in a different directory and then remounted it as /usr. The only way the above would work (with persistent home) would be if you had enough hard drive space to do something like this:

mkdir /home/knoppix/.root
cp -R /Knoppix/usr /home/knoppix/.root/
mount --bind /home/knoppix/.root/usr /usr

However /usr is huge and it would seem you would need a VERY large usb pen drive to do it this way. Now if you could install a program chroot /home/knoppix/.root then have the system be able to check there first then goto /, I think that would be more efficient. This is easily done via the PATH statement as long as it is checked first for executables, however, where I get lost are things like lib, etc and other crucial directories and links, especially if you have to add a module to the kernel (such as for a winmodem.)

sireasoning
02-02-2003, 08:35 AM
I was on IRC last night with eadz and he came up with a much simpler approach that I will expand upon now.

He said that he could write a script which would automatically do recursive linking from the /Knoppix cd root tree.
Currently there is a single link to such large directories as /usr to /KNOPPIX/usr. Although this in many ways simplifies things, it also creates problems for those who wish to make changes. If I understand him correctly, his script would automatically create recursive links all the way down the /usr tree for example so that every item is linked instead of an entire directory. This is a crucial first step.

I think that next we would create a directory such as /home/profiles. This is where one could keep diferent root tree profiles for different situations. For instance: /home/profiles/laptop/.root would be the root tree for a laptop (with some of the programs installed plus extras such as a module to run the internel winmodem, modules to activate the special buttons, etc that would be specific to that laptop. You may want another profile such as /home/profiles/generic/.root that would house only the extra programs you would want, etc. These .root trees would only include the extra stuff installed by the user so they do not necessarily need to take up much space. In addition, they could easily be created with the current persistant home program. When the system is loaded (or after a program is installed there) a script is run which will auto load items from the chosen profiles' .root directory on top of the main root tree.

When installing to each profile one could chroot /home/profiles/XXX/.root. So in essence, this may still be small enough to fit on a floppy in some instances, but could easily be run with persistant home from a usb pen drive, etc. The possibilities and portability of this approach would allow for maximum flexibility.

to load the profiles.... maybe have an option at boottime such as:
knoppix profiles
this would then begin the loadup process and after the drive has been discovered and it is ready to write from a profile onto the main root tree, a menu could pop up asking you to choose the profile you wish and list them (in the above scenario you could choose laptop or generic).

eadz
02-02-2003, 08:54 AM
just to clarify
* I didn't say I could write it ;)
* it goes down the .root ( we'll call the place for changes .root ) tree, not the /KNOPPIX/ tree

and example

1 - standard knoppix
/lib is a symlink


/lib -> /KNOPPIX/lib


2
/lib is a directory in / (ramdisk ) however it only contains symlinks and directories
- in .root/ there is lib/modules/2.4.20-custom - a kernel modules



/lib/ is created in ramdisk
/lib/iptables -> /KNOPPIX/iptables
/lib/modules/2.4.20 -> /KNOPPIX/lib/modules/2.4.20
/lib/modules/2.4.20-custom -> .root/lib/modules/2.4.20-custom
/lib/libacl.so.1.0.3 -> /KNOPPIX/lib/libacl.so.1.0.3
...
/lib/libz.so.1 -> /KNOPPIX/lib/libz.so.1
/lib/security -> /KNOPPIX/lib/security


now, yes thats a lot of symlinks
the general rule, is that if you make a directory, or add a file in a directory, there will me as many symlinks as files in that directory.

How the script would work :

It travels down the .root tree, IF there is a directory say in /lib/modules/ then instead of linking /lib to /KNOPPIX/lib it makes /lib in ramdisk, and starts linking files, either to /KNOPPIX/ or to .root.

That means that if say you don't add anything to /etc, it will still link to /KNOPPIX normally, so you _dont_ have to recreate the _whole_ tree as symlinks

sorry if i'm not clear on this, im not a technical writer

sireasoning
02-02-2003, 11:50 AM
how smart will this script have to be?

For instance:
lets say that you wanted to add a plugin to mozilla.
mozilla is at /usr/lib/mozilla on Knoppix X1 version of CD
the user installs the plugin chroot /home/.root and it is now located at /home/.root/usr/lib/mozilla/plugins

My understanding of how your script would perform is that the script would create /usr symlink to every directory and file under /KNOPPIX/usr to /usr with the exception of /usr/lib.
the script now creates the /usr/lib directory
the script now would have to create symlinks to every directory and file in /KNOPPIX/usr/lib with the exception of mozilla...
and so on.

Now, lets assume that Knoppix X2 is released
in this version he has removed program A and decided to include program B. Both were orignially installed into /usr/lib. Would your script have to know of this change in advance to function or could the script remain the same over the change of CD versions? Or would it require prior knowledge of the full directories (and files) in the root tree?

lilliput
02-02-2003, 05:14 PM
Suggestion
we could make 2 scripts
The first one is scanning (/home/.root/usr/....) and writing all the existing files and directory in
/home/.root/.files2symlink
the second one at the boot time just read .files2symlink and make the link..

So you have just to run the first script when you make any modification...
The second script could run the first script if he detects any errors...

Dave_Bechtel
02-03-2003, 09:21 PM
--Any script(s) which traverses /usr and makes symlinks, are going to run for quite some time. Don't forget the decompression overhead. The mount / bind and lndir suggestions seem to be worth looking into, if they add similar functionality with less overhead.

--Remember, K.I.S.S. Nobody wants an extra *1* minute added to their boot time, much less 3 or 5... ' knx-hdinstall ' is included for a reason. We need to keep this functionality limited to a certain extent, and as *fast* as possible.


Suggestion
we could make 2 scripts
The first one is scanning (/home/.root/usr/....) and writing all the existing files and directory in
/home/.root/.files2symlink
the second one at the boot time just read .files2symlink and make the link..

So you have just to run the first script when you make any modification...
The second script could run the first script if he detects any errors...

lilliput
02-04-2003, 01:33 AM
other Idea;
why not do not use a real separate one /home/.root/usr
with application install with the command
config --prefix=/home/.root/usr (here an alias like "config=./config --prefix=/home/.root/usr" is enough )
make
make install
make clean

or for a debian paquet use the command
dpkg -x name.deb /home/.root/usr
(same sort of alias for dpkg !!)
We have just to renews some variable like $PATH; or some links paths to the lib; to compile a news program fo exemple ;
I think we could even re-configure kpackage to install the paquet in right way;

To finish a question how do you envisage to creat a symlink to a read only media.. I've made a lot of research and look likes impossible directly. So what's the method ??

eadz
02-04-2003, 02:14 AM
other Idea;
To finish a question how do you envisage to creat a symlink to a read only media.. I've made a lot of research and look likes impossible directly. So what's the method ??

/ (root) is in ramdisk, so it's read-write.

Alextreme
02-04-2003, 07:03 PM
mount --bind-ing sure is an efficient way to do this, i mean, morphix uses it :D [/plug]

then again, it uses between 10-20 of em, but overkill never hurts :P

probono
02-09-2003, 08:19 PM
I think what we really need here is an overlay or translucency file system like the one at
http://mailman.linuxtag.org/pipermail/debian-knoppix/2002-August/000828.html
This mounts a second filesystem over the first. Does anyone know why it was not implemented in Knoppix? Perhaps anyone out there can do it...

sireasoning
02-09-2003, 08:37 PM
wow! This could be the missing link to the whole puzzle? Anyone have any practical experience with it? Maybe the security issues could be resolved by allowing configuration as to how many overlays allowed? Maybe even hardcoded at one? I have a minimal understanding of this patch but it seems very interesting.

probono
02-11-2003, 11:23 PM
Bernhard Wiedemann, the author of the translucency filesystem, wrote:
"and for anyone happening to read this - want to have a look at the compactest way of making your own customized bootcd?http://lsmod.de/bootcd/Makefile (beta quality only yet)"

He posted to the Knoppix developer mailing list: http://mailman.linuxtag.org/pipermail/debian-knoppix/2003-February/001879.html
"When all is set up correctly (see make init)
its about just calling "make iso" or "make rw" to master or
burn a complete remastered CD-RW... you may have a
preconfigured, adapted, autohardwareconfiguring standard Debian system
within the "linuxroot" dir (it should also work with any other
distribution). The idea with translucency is that on bootup the ram-disk(tmpfs on /tmp) is initially empty (consuming no memory) but that you can change any file as usual on the system"

So, as it seems to me, the "make"-script burns a knoppixlike CD which has the function we want! :-) Too bad I have no Linux machine with a burner :-(