Re: Hiding nodes with unionmount

[Sergiu Ivanov]

Hello,

On Thu, Jul 30, 2009 at 09:26:11PM +0200, Arne Babenhauserheide wrote:
> Am Donnerstag, 30. Juli 2009 14:37:39 schrieb Sergiu Ivanov:
> > > $ settrans -a / mine /mnt/usb/arne.tbz
> >
> > You mean union-mounting ``mine'' here, right?  Note that you still
> > require root privileges to set a translator on / .  (At least I'm not
> > allowed to do that in my instance of the Hurd).
> 
> I assume to make it really clean it would have to be something like 
> 
> $ ln / chroot/real_root
> $ chroot chroot /bin/bash
> $ settrans -a / mine real_root
> 
> Or at least something like it (I'm not firm on the exact way to do it). 

I suppose this may work if you have the rights to write chroot/ , but,
unfourtunately, I can't check it.  For some reason, when I try chroot
<dir> /bin/bash , it tells me that it cannot find /bin/bash , although
this executable definitely exists :-(
 
> And what does a subhurd do exactly? 
> 
> (I'd also be glad to just get a pointer :) ). 

My understanding is that a sub-Hurd is something like another instance
of Hurd running on top of the same instance of gnumach.  It seems that
a sub-Hurd may reuse some servers from the main Hurd.  I'm not really
expert in this area, so you will probably like to read this:
http://www.gnu.org/software/hurd/hurd/subhurd.html .
 
> The goal is to have / with some modifications. The "mine" translator is a 
> theoretical translator which turns the system into my private system - though 
> only for me :) 

Clear :-)
 
> It should be able to modify the system and save all changes I do to the 
> system 
> in a personal file - and only there. 
> 
> That would even allow me to do a "rm -rf /" which would naturally make the 
> system unusable for me (my / would be empty), but wouldn't affect anyone 
> else. 
> My personal environment would then simply contain a notice for the filterfs 
> that it should filter out all files :) 

So, you store diffs between the real / and your version, right?
 
> > > It could even use a version tracking backend, which tells it which files
> > > need to be filtered and added. That way a change in the base system could
> > > be reflected in the filterfs. This would then use a lot more space, but
> > > if the main repository would be used as a base by all users, that space
> > > would only be required once.
> >
> > I'm sorry, but I cannot see why you need a version tracking back-end
> > in this case.  Actually, what I cannot fully understand is the
> > ``version tracking'' part :-) 
> 
> That would just enable us to effectively mount a set of patches ;) 
> 
> We could then check which file we removed, and if the underlying filesystem 
> changed, we'd be able to see the diffs and "merge" the changes with our 
> changes. 

So, you are talking about something like branches?  The master branch
being the original / and each user having their own branch, right?
This sounds very interesting :-) I had the idea of employing git (for
instance) in managing my ~/ , but it makes little sense.  Multi-user
management is much more interesting :-)
 
> But it can simply be replaced with a package manager which knows which 
> packages are installed in root and which files they own. 

Hm...  I'm not sure a package manager could replace a VCS: what it you
*modify* some files in /etc/ ? AFAIK, package managers are not
interested in what the installed files contain, so I'd say that a VCS
is required anyway.
 
> The filter needs to know what to hide, and I though a version tracking system 
> could provide that information. But the package manager can do it, too, and 
> with far less overhead. Portage already has all information for that. 

I still cannot see how a package manager can do that.  I'm setting up
Gentoo now, and I'm reading the Portage chapter of the handbook, but
it doesn't really help in understanding how it could track files.
Could you please explain how it should work?
 
> > So, your personal setup also includes the modified files from some
> > system directories, right?  (like /var/db, /etc/)
> 
> Jupp. 
> 
> Ideally it would also be able to modify /dev /proc and anything else, so 
> programs see exactly what I want them to see. 

I think the possibility of this is implied by design: every
modification of a system-wide configuration file is stored as a diff
and is not applied to the *real* file.  So you can do whatever you
want in your environment :-)
 
> A firewall could for example be a translator on the network device, so it 
> would automatically be completely transparent, and an audio equalizer could 
> be 
> a translator on /dev/dsp

You are suggesting very interesting translator use-cases :-) I think
they are pretty orthogonal with multi-user management via the mine
translator, so one could implement these already now (well, except for
/dev/dsp).
 
Regards,
scolobb