Greetings -

Sorry in advance if this is a stupid idea, but -

I'd really like to be able to set a distinct "clock" for a specific chroot environment, 
such that the super-user could call :
   const char *my_chroot_directory = "/some_chroot";
   struct stat st;
   if(stat( my_chroot_directory, &st) ==0)
         sys_clock_settime ((clockid_t) st.st_inode,  (struct timespec *)tp)
   ( from glibc )
and there would be a real-time clock offset association in the kernel between the 
inode number of the directory to which a "chroot" has succeeded,  and a real-time
clock offset , so that ALL processes that run with their "root" directory of such
chroot directories can get the same values for time() or gettimeofday() which would be
offset from the real-time clock by the current offset of the last "clock_settime(inode, timespec)" 
second parameter for that directory inode (first parameter). 
Eventually,  the coreutils "date(1)" command could be extended to support setting the system 
date and time for different chroot() root directories.

Does anyone know of a module that does this ?

If not, and if no-one convinces me this is a stupid idea, I'm going to write one.

Thanks in advance for any replies,
All the best,
Jason Vas Dias (a software engineer) <jason.vas.dias@gmail.com>



--

[ message continues ]

It certainly doesn't sound like a particularly good idea to me. This
would add great complexity to the kernel while having very few
users. Perhaps there's something I haven't considered but I can't think
of any good applications for this sort of functionality. Do you have
something in particular in mind?

It seems like what you want here is simple virtualization. Have you
considered KVM? The closest thing to your request currently upstream is
containers, although I'm unsure of whether a container can be created
with an independent clock. Might be something to look into.

Cheers,

- Ben
--

[ message continues ]

I'm not sure that it need be that complex -
  o kernel knows chroot() has succeeded so adds the inode of that directory to a "inode <-> clock_offset" mapping
     initialized to 0.
  o this mapping could perhaps also be used to provide other future per-chroot specific features - as for instance 
     a per-chroot  list of extra acceptable binary executable formats ?
  o clock_gettime() and gettimeofday() and time() and clock_settime() are modified to see if the root device inode 
     number has a non-zero real-time clock offset, and, if so, apply it to the real-time clock returned or in the case
     of clock_settime(), set the associated offset to a non-zero value.

RE: why ?
This would allow one to very easily support websites for totally different timezones , where offsets need not be
restricted to legal timezone offsets but could encompass years - also nice if you want to run applications whose
license key has expired .  Also very easy to support multiple instances of cron(1) running in different timezones.
In any case, the module would ensure that the time the kernel sees internally for all processes is the actual real-time
clock value; only processes which have their root directory in one of the special chroot directories would get

To me, using virtualization to solve this problem is like using a sledgehammer to crack a nut,
particularly if the optimal performance of the processes running in such chroot environments

Thanks for your comments,  but I think it is still a good idea and I'm investigating now - 
it doesn't seem to need to be too complex to me.

All the best,
Jason.
--

[ message continues ]

You might want to take a look at Linux-Vserver; it has containers (that 
is, chroot on stereoids) with support for "virtualized time"/clock offset.

Virtualized time is not without downsides, it adds overhead. It will be 
tiny compared to using a sledgehammer of course. The vserver guys puts 
it this way;
"This enables per guest time offsets to allow for adjusting the system 
clock individually per guest. this adds some overhead to the time 
functions and therefore should not be enabled without good reason."

http://linux-vserver.org/

It could be useful to implement such a thing in a "time" namespace, 
making it available to lxc containers and cgroups also.
--

[ message continues ]

KVM needs hardware support (but chroot runs wherever Linux runs)
--

[ message continues ]

See subterfugue.net... it can do this.

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--

[ message continues ]

Sorry for the delay in responding - 
but I've been very busy, amongst other things working on the "per-chroot" module, which
now works in a very basic but sufficient mode.
If anyone else would find it useful,  I'll fill it out some more and post it to this list. 

I'd like to see this "subterfuge.net" - but I'm unable to connect with HTTP:
  
$ curl http://subterfuge.net --trace-ascii /dev/fd/2
== Info: About to connect() to subterfuge.net port 80 (#0)
== Info:   Trying 184.82.15.90... == Info: No route to host
== Info: couldn't connect to host
== Info: Closing connection #0
curl: (7) couldn't connect to host

while google just finds "subterfuge.com" which appears to be a Spanish record company ...
Is this server now down / being blocked ? 
Did I get the URL incorrect ? What is / was the software at subterfuge.net ?

All the best & happy new year to all ,
Jason
--

[ message continues ]

Sorry, it is on 

http://subterfugue.sourceforge.net/

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--

[ message continues ]