Thank you for response. I simply forgot to CC the list. Now it should work.
This is a simplified situation of using automatic squashfs container generation with autofs. --------------------------------------------------------------------------------------------------- User: john. autofs path to make squashfs: /makesqfs access mask: /makesqfs/<username>/<file name> autofs path to access sqfs: /usercontainers access mask: /usercontainers/<username>/<file name> John wants to put one of his folders (/home/john/foldertoprocess) in a secure storage as a squashfs container which can be accessed automatically anytime. he could make it by isssuing regular command mksquashfs <source> <destination file name> -<options> and copy resulted file to secure storage. be he wants to use something simpler and robust. Instead, John issues the following command: cp /home/john/foldertoprocess /makesqfs/john/marketanalyzis after some time he (and may be other users in the system) can access his securely stored and read only files by following this symbolic link /containers/john/marketanalyzis what happens on backend? ====================== when he copies files to /makesqfs/john/marketanalyzis autofs executes a script that prepares temporary folder somewhere (/tmp/john/marketanalyzis) and mounts it as /makesqfs/john/marketanalyzis when copying finishes and timeout of 5 minutes of inactivity fires in autofs, it executes a designated script and passes /makesqfs/john/marketanalyzis as a parameter. script makes a squashfs container marketanalyzis.sfs and puts it somewhere in secure location, and then makes a symbolic link at /containers/john/marketanalyzis which points to /usercontainers/john/marketanalyzis after script is done, autofs successfully unmounts /makesqfs/john/marketanalyzis Notes: i think script can also remount /makesqfs/john/marketanalyzis as read only before making actual mksquashfs command. with such approach squashfs container creation may be done on separate computer, while mounting part can also be done from different locations. 2008/9/16 Jeff Moyer <[EMAIL PROTECTED]>: > Alexander <[EMAIL PROTECTED]> writes: > >> truly speaking i don't know what is semantics with offset mounts, but >> can describe following situation. >> >> client access the folder /tmpstorage/filestocompress >> it mounts as /tmp/filestocompress (where /tmp is a tmpfs/shmfs or >> unionfs with different underlying mount points) >> client then copies his files there and after time of inactivity >> autofs executes script /bin/compress and after it's completion >> unmounts all corresponding mount points. > > I'm not quite sure I follow. If you could list the steps, taking > automount out of the picture, that would be helpful. So, what is the > ordered list of steps to perform, using *exact* path names. Above, > what's confusing me is that an access to /tmpstorage/filestocompress > would mount anything on /tmp. Autofs simply doesn't work that way. > >> the /bin/compress script does following: >> 0. it gets parameter of what path is going to be unmounted, in our >> example it is /tmp/filestocompress >> 1. makes compressed tar, bzip, or squashfs container from >> /tmp/filestocompress in /users/username/filestocompress.tar >> 2. optionaly deletes all files in /tmp/filestocompress and exits >> >> something like that > > Again, a specific example would be more helpful (with real commands and > paths). > > I'm curious to know why you didn't CC the list on your response. Is it > okay if we continue discussions there? > > Thanks! > > Jeff > -- Sincerely, Alexandr N. _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
