Re: [autofs] Returning issues.
On 06/08/2011 06:55 AM, Ian Kent wrote: There's a lot of information her, which probably isn't specific to the issue being discussed so snip ... Ah very nice to know the project I'm working on for a long time now is being appreciated I do not appreciate it when one is just snipping the text I've written about my project, to inform others about what the project is about. Don't know, can't see anything relevant in the kernel source. Maybe you should look harder: http://www.h-online.com/open/features/Kernel-Log-Coming-in-2-6-39-Part-2-Storage-and-file-systems-1232317.html?page=2 and http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=1abf0c718f15a56a0a435588d1b104c7a37dc9bd Stef ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] Returning issues.
On 06/07/2011 07:23 AM, Ian Kent wrote: On Sun, 2011-06-05 at 19:01 +0200, Stef Bon wrote: hi, I see that issues that automounter doing unnecessary mounting like: http://linux.kernel.org/pipermail/autofs/2011-May/006568.html I think you misunderstood the report here. Neither of the points below were related to it. and here http://linux.kernel.org/pipermail/autofs/2011-April/006542.html some more documentation here would prevent users asking the same questions. This behaviour is mostly caused by: A. ls is a alias (in de shell) to ls --color=auto which will follow targets, and this makes the automounter mount. This mostly isn't a problem these days as most user space utilities behave better with automount these days. We will need to wait and see how the user space utilities behave with the new vfs automount kernel infrastructure and work out what needs to be done as we go. I hope you're right. How do apps know a directory is a autofs managed mountpoint? B. extended attributes called by the environment, or an app. I see here a sollution is proposed to fix this in coreutils and the acl package. Hmm, is this right? Yes, this was related to inconsistent use of system calls within the user space utility, an lgetxattr(2) call was being made instead of a getxattr(2) call (inconsistent with respect to previous calls in the same utility code path), which was causing a mount to occur on the follow, as required by the lgetxattr(2) call. So, in this case, it needed to be fixed in the utility. You're mixing things here I think. A lgetxattr will normally not follow a symlink, as the call getxattr does. Isn't it the other way around? (compare stat and lstat: lstat looks at the symlink self, stat follows the symlink and takes the target) Anyhow, when a userspace utility does something like that, it's a serious error. Utilities should do exactly what is requested, and never anything else. | autofs directories don't have extended attributes. You mean only the autofs managed mount points? The contents of the share can have Xattr right? Can't an autofs managed directory have Xattr?? That does not sound right. No, the autofs fs doesn't support extended attributes. Do you really think we need extended attributes? If you do then a patch, which includes some reasoning of why we need them, would be welcomed. No, it suprise me only, since the contents of an autofs managed mountpoint can have Xatttr (see above) and I consider the autofs managed mountpoint belonging to the mounted share. Maybe simular like the stat call, where the trailing slash makes the difference, a trailing slash to the end of the path when doing getxattr/setxattr is doing a call to the . dir on the remote share, and without it it's going to the autofs managed dir on the localhost, resulting in a EOPNOTSUPP as expected. In my construction I'm blocking the xattr calls to autofs managed dirs, unless it's already mounted, and I consider this as an ugly hack. | How? This is possible in the (special) construction I'm working on, fuse-workspace and mount.md5key. In short, it's like GoboLinux, providing a special environment to the user. GoboLinux needed a special kernel patch to achieve this, I'm using a FUSE fs to do the same. The environment looks like: /Computer /Home /Internet Services /Mounts /Network /Shared /System This the the root of the filesystem. Quite different he?!? Now you may think like what the hell you're doing to the Linux system, but the normal directories like /bin, /etc, /lib, etcetera are present but hidden, the readdir - part of the FUSE fs - call has the ability to hide entries when configured. You can do a stat on /bin, and enter it normally . Well that's required to make the system run. First step is to mount the FUSE fs at a certain directory: /var/lib/workspace/$USER/bind Then create the root system directory: mkdir /var/lib/workspace/$USER/bind/bin then make it hidden: setfattr --name=system.workspace_entry_hide --no-dereference --value=1 -- /var/lib/workspace/bind/$USER/bind/bin This command changes the value of the Xattr (system.workspace_entry_hide) of the entry managed by the FUSE fs, as the FUSE fs has a administration of entries and inodes of it's own, and has it's own set of Xattr as you can see. Now the entry will not show when doing a readdir call anymore. But it does exist, and can be used to mount: mount --bind /bin /var/lib/workspace/$USER/bind/bin Every syscall to something in this directory will not go through the FUSE fs, but directly will lead to /bin, which is a very good thing, the extra layer will slow things down. The VFS takes care of that. Now do this for every root system map, and you have a complete directory you can chroot to, where you can do things with the FUSE fs, and not have any loss of performance. Now chroot to this environment using pam_chroot when the session begins, and you'r done. It's possible
Re: [autofs] bug doing simple stat call to mountpoint
On 06/05/2011 11:37 PM, Stef Bon wrote: On 06/05/2011 06:44 PM, Stef Bon wrote: Hi, I'm using autofs 5.0.5, kernel 2.6.38.6. In the construction I'm working on I got the following error: stat /mnt/mount.md5key/sbon/0/0a8805e89f4cc6653185a4ec4335cca1 stat: cannot stat `/mnt/mount.md5key/sbon/0/0a8805e89f4cc6653185a4ec4335cca1': No such file or directory sbon [ /tmp/mount.md5key/users/sbon/cache/0a8805e89f4cc6653185a4ec4335cca1 ]$ ls /mnt/mount.md5key/sbon/0/0a8805e89f4cc6653185a4ec4335cca1 gives contents as expected I've tried linux 2.6.39.1, and same behaviour. I'll try an older kernel (2.6.37) Oef I have found the cause of this. I had to add a trailing slash, like: stat /mnt/mount.md5key/sbon/0/0a8805e89f4cc6653185a4ec4335cca/ this makes the automount mount. Stef Stef ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
[autofs] Returning issues.
hi, I see that issues that automounter doing unnecessary mounting like: http://linux.kernel.org/pipermail/autofs/2011-May/006568.html and here http://linux.kernel.org/pipermail/autofs/2011-April/006542.html some more documentation here would prevent users asking the same questions. This behaviour is mostly caused by: A. ls is a alias (in de shell) to ls --color=auto which will follow targets, and this makes the automounter mount. B. extended attributes called by the environment, or an app. I see here a sollution is proposed to fix this in coreutils and the acl package. Hmm, is this right? If an app wants to get the xattr of an autofs managed directory, what is the sollution proposed here then? Can't an autofs managed directory have Xattr?? That does not sound right. In my construction I'm blocking the xattr calls to autofs managed dirs, unless it's already mounted, and I consider this as an ugly hack. Stef ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] bug doing simple stat call to mountpoint
On 06/05/2011 06:44 PM, Stef Bon wrote: Hi, I'm using autofs 5.0.5, kernel 2.6.38.6. In the construction I'm working on I got the following error: stat /mnt/mount.md5key/sbon/0/0a8805e89f4cc6653185a4ec4335cca1 stat: cannot stat `/mnt/mount.md5key/sbon/0/0a8805e89f4cc6653185a4ec4335cca1': No such file or directory sbon [ /tmp/mount.md5key/users/sbon/cache/0a8805e89f4cc6653185a4ec4335cca1 ]$ ls /mnt/mount.md5key/sbon/0/0a8805e89f4cc6653185a4ec4335cca1 gives contents as expected The automounter does not call the mount command in the first case, and like it should in the second. mount | grep 55ed //SCLFS20091030/sbon on /mnt/mount.md5key/sbon/0/55ed21dee4bb9604117a013e57dc5690 type cifs (rw) I'm sorry I'm mixing two mountpoints here: mount | grep 0a88 //SCLFS20091030/ftp on /mnt/mount.md5key/sbon/0/0a8805e89f4cc6653185a4ec4335cca1 type cifs (rw) and stat /mnt/mount.md5key/sbon/0/0a8805e89f4cc6653185a4ec4335cca1 File: `/mnt/mount.md5key/sbon/0/0a8805e89f4cc6653185a4ec4335cca1' Size: 0 Blocks: 0 IO Block: 16384 directory Device: 18h/24d Inode: 2 Links: 692 Access: (0755/drwxr-xr-x) Uid: ( 4024/gast) Gid: ( 3000/netgroup) Access: 2011-06-05 18:36:16.283327100 +0200 Modify: 2011-05-08 23:30:59.245301800 +0200 Change: 2011-05-08 23:30:59.245301800 +0200 Stef ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] bug doing simple stat call to mountpoint
On 06/05/2011 06:44 PM, Stef Bon wrote: Hi, I'm using autofs 5.0.5, kernel 2.6.38.6. In the construction I'm working on I got the following error: stat /mnt/mount.md5key/sbon/0/0a8805e89f4cc6653185a4ec4335cca1 stat: cannot stat `/mnt/mount.md5key/sbon/0/0a8805e89f4cc6653185a4ec4335cca1': No such file or directory sbon [ /tmp/mount.md5key/users/sbon/cache/0a8805e89f4cc6653185a4ec4335cca1 ]$ ls /mnt/mount.md5key/sbon/0/0a8805e89f4cc6653185a4ec4335cca1 gives contents as expected I've tried linux 2.6.39.1, and same behaviour. I'll try an older kernel (2.6.37) Stef ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] [PATCH 00/17] Introduce automounter dentry ops
On 09/30/2010 08:14 PM, David Howells wrote: The attached patches introduce a couple of new dentry operations for use by automounters and make AFS, NFS, CIFS and autofs4 use them. This means that these filesystems no longer have to abuse lookup(), follow_link() and d_revalidate() to achieve the desired effect. Improvments are always welcome as I look at it, but for my understanding, how do these new dentry operations cooperate with cifs? Cifs is the target filesystem, and handled by the automounter, thus the automounter is the initiator, not cifs. As you describe it (well it looks like it, I may not understand...) cifs is the initiator, and the patches to the automounter make autofs handle cifs requests handle better? What is now the case here?? I cannot understand. Any explanation is appreciated. Stef Bon the Netherlands There are two dentry operations provided: (1) struct vfsmount *(*d_automount)(struct path *path); This is used by follow_automount() in fs/namei.c to ask the filesystem that owns the dentry at the current path point to mount something on @path. It is called if either the inode belonging to the given dentry is flagged S_AUTOMOUNT or the dentry is flagged DMANAGED_AUTOMOUNT, and if the dentry has nothing mounted on it in the current namespace when someone attempts to use that dentry. No locks will be held when this is called. d_op-d_automount() may return one of: (a) The vfsmount mounted upon that dentry, in which case pathwalk will move to the root dentry of that vfsmount. (b) NULL if something was already mounted there, in which case pathwalk will loop around and recheck the mountings. (c) -EISDIR, in which case pathwalk will stop at this point and attempt to use that dentry as the object of interest. If the current dentry is not terminal within the path, -EREMOTE will be returned. (d) An error value, to be returned immediately. Automount transits are counted as symlinks to prevent circular references from being a problem. If one is detected, -ELOOP will be returned. If stat() is given AT_NO_AUTOMOUNT then d_op-d_automount() will not be invoked on a terminal dentry; instead that dentry will be returned by pathwalk. follow_automount() also does not invoke d_op-d_automount() if the caller gave AT_SYMLINK_NOFOLLOW to stat(), but rather returns the base dentry. (2) int (*d_manage)(struct path *path, bool mounting_here); This is called by managed_dentry() or follow_down() in fs/namei.c to indicate to a filesystem that pathwalk is about to step off of the current path point and walk to another point in the path. This is called if DMANAGED_TRANSIT is set on a dentry. This can then be used by autofs to stop non-daemon processes from walking until it has finished constructing or expiring the tree behind the dentry. It could also be used to prevent undesirables from mounting on this dentry. @mounting_here is true if called from follow_down() from mount, in which case namespace_sem is held exclusively by the caller of follow_down(). Otherwise, no locks are held. d_op-d_manage() may return one of: (a) 0 to continue the pathwalk as normal. (b) -EISDIR to prevent managed_dentry() from crossing to a mounted filesystem or calling d_op-d_automount(), in which case the dentry will be treated as an ordinary directory. (c) An error to abort the pathwalk completely. To make this work for autofs, d_mounted in struct dentry has become d_managed. This used to be a count of the number of mounts on this dentry. The bottom 28 bits are still that (DMANAGED_MOUNTPOINT). The upper four bits contain a couple of flags, DMANAGED_TRANSIT and DMANAGED_AUTOMOUNT. This allows managed_dentry() to test all three conditions with minimumal overhead if none of them are true. For other filesystems, setting S_AUTOMOUNT is sufficient. This is noted by __d_instantiate() which will set DMANAGED_AUTOMOUNT automatically if it is seen. Checking S_AUTOMOUNT doesn't work for autofs, however, since the dentry might not have an inode, hence why a dentry flag also. S_AUTOMOUNT and d_automount() are introduced in patch 1; d_manage(), d_managed and DMANAGED_* are introduced in patch 7. David --- David Howells (8): Make follow_down() handle d_manage() Make dentry::d_mounted into a more general field for special function dirs Add an AT_NO_AUTOMOUNT flag to suppress terminal automount Remove the automount through follow_link() kludge code from pathwalk CIFS: Use d_automount() rather than abusing follow_link() NFS: Use d_automount() rather than abusing follow_link() AFS: Use d_automount() rather than abusing follow_link() Add a dentry op to handle automounting rather than
Re: [autofs] Browse mode in autofs 5
On 05/13/2010 02:15 AM, Murata, Dennis wrote: Is there any way to turn off browse mode on specific nfs mounts using autofs 5? We are running a modified RHEL5U5, autofs-5.0.1-rc2.143.el5, kernel-2.6.18-194.el5. The users want the data mounts to be browseable so they can see the possible directories, but we don't want /home to be browseable. The KDE and Gnome file managers will cause all home directories to mount if the user looks at /home. That would cause over 2000 mount requests. In RHEL4 autofs4, we could specify which directories to browse, I don't see this option in autofs5. Thanks Wayne ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs No, I only know a generic method (setting BROWSE_MODE=no in the conffile, or exporting it before automount starts), but that's not what you're looking for? Stef Bon the Netherlands. Sent from my LinuxFromScratch machine, Thunderbird 3.1beta1 ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
[autofs] Testing a key is mounted.
Hi,
some time ago I asked here it is possible to test a valid key is mounted, in a
autofs managed directory.
I've written a function which does that for me, from within a FUSE module. SO
now it's not necessary anymore to do this via autofs. THis does not mean for
me that communicating with a automount process via /dev/autofs is not a good
thing.
My function:
static signed int Md5KeyIsMounted(const char *testmd5key)
{
int nreturn=-1;
DIR *dp;
struct dirent *de;
// only check when this directory is an option
syslog(MY_LOG, Md5KeyIsMounted, key: %s, testmd5key);
if ( strlen(testmd5key) != MD5_DIR_LEN ) goto out;
if ( options.autofs_mount_path != NULL ) {
dp = opendir(options.autofs_mount_path);
if (dp == NULL) goto out;
while ((de = readdir(dp)) != NULL) {
syslog(MY_LOG, md5key found: %s, de-d_name);
if ( strcmp(de-d_name,testmd5key) == 0 ) {
nreturn=1;
goto out;
}
}
closedir(dp);
}
out:
return nreturn;
}
It just looks at the directory where autofs creates the autofs managed (key)
directories. If mounted it exists.
Now when in my fs there is a lookup of a .directory file, which is in a autofs
managed directory, it's able to determine it's mounted or not, and depending
on the result of that test, present a different .directory.
Note that my fuse fs intercept calls to this .directory file and present
.directory file from a predefined place. If t does not do that, it will just
try to look at the .directory file in the autofs managed mount point, causing
it to be mounted.
Stef
___
autofs mailing list
autofs@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] How to determine a path is a mountpoint.
On Monday 22 February 2010 04:54:03 Ian Kent wrote: So, am I missing here something? Or has something changed? When I look to the various init rc scripts, the file /etc/sysconfig/autofs file is sourced. In the init script the sourcing of the configuration is redundant but environment variables that are exported will be seen by child processes (as per normal shell environment variable export rules) and can be used to over-ride the settings in the autofs configuration. Note that the internal autofs default is BROWSE_MODE=yes and that is set to no by the default installed configuration for backward compatibility. Now when I export them all, they are detected and used. I see logging and browse mode is set to no. OK now I'm beginning to understand, the automounter reads the configuration values directly, from the default configuration file. I thought the automounter reads them from the environement, cause the conf file is sourced at the beginning of the init file. I've found the code. This is, and it happens to me more often, not well documented. Please start a wiki or something. I know you are very busy, I recieved some copies of emails about an important issue this weekend. I'm working also a lot with FUSE, and the wiki there provides a lot of information, although it's not complete. I would like to help if I can. Stef Bon The USE_MISC_DEVICE is the only exception. It is used only by the init script for checking if /dev/autofs is present and if we want to use /dev/autofs for kernel communication. Ian ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] How to determine a path is a mountpoint.
On Friday 19 February 2010 15:11:49 Stef Bon wrote: On Friday 19 February 2010 04:57:15 Ian Kent wrote: On 02/19/2010 07:18 AM, Stef Bon wrote: On Wednesday 17 February 2010 15:25:08 Ian Kent wrote: My fusemodule is an overlay fs, which mirrors another directory under the directory under which it's mounted, and does some changes. aka unionfs type behaviour? You are in for a bundle of trouble if your trying to implement an overlay file system. If there are enough restrictions on functionality you might be able to get this working reliably but the locking alone will likely drive you nuts! You understand that once you play in kernel space you can have multiple concurrent code paths accessing and possibly changing the same data structures at the same time. Well it's difficult, well not for me, but for the deveopers of FUSE. It's not in kernel space, but in userspace. Never heard of? My directory looks like: root [ /usr/src/cblfs-200910/autofs-5.0.5 ]# /bin/ls -l /mnt/mount.md5key/sbon/mount/ total 0 dr-xr-xr-x 2 root root 0 2010-02-19 13:42 60ef51078836b9a9c78a3398f053d562 dr-xr-xr-x 2 root root 0 2010-02-19 13:42 7bfb90bb66496650c21925bd56a71bdc dr-xr-xr-x 2 root root 0 2010-02-19 13:42 e23e33a53d5d08ad8f0425de4edd9309 while nothing is mounted: root [ /usr/src/cblfs-200910/autofs-5.0.5 ]# mount | grep /mnt/mount.md5key/ root [ /usr/src/cblfs-200910/autofs-5.0.5 ]# Is this behaviour normal? Is there a configuration switch?? Obvioulsy the automounter allows autofs directories to exists, while the are not connected. Well I've found the sollution to path's not disappearing. Somehow when in my script the environment variables are set like follows: USE_MISC_DEVICE=no BROWSE_MODE=no APPEND_OPTIONS=yes LOGGING=debug /usr/sbin/automount --pidfile /var/run/autofs.var-run-autofs-auto.master.pid /var/run/autofs/auto.master the automounter is not taking these values, what suprised me a lot! This is the way the automounter reads various settings, via the environment. Values in /etc/sysconfig/autofs (or /etc/sysconfig/autofs.conf depends on your distro...) are read and set this way! Now when I do something like: USE_MISC_DEVICE=no export BROWSE_MODE=no APPEND_OPTIONS=yes export LOGGING=debug /usr/sbin/automount --pidfile /var/run/autofs.var-run-autofs-auto.master.pid /var/run/autofs/auto.master I can see that I get the desired behaviour: unmounted entries (keys) are deleted! I've checked the file environ in the /proc/3689 directory, and only found the values LOGGING and BROWSE_MODE, not USE_MISC_DEVICE and APPEND_OPTIONS. But there is logging and browse_mode is not used! So, am I missing here something? Or has something changed? When I look to the various init rc scripts, the file /etc/sysconfig/autofs file is sourced. Stef Bon ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] How to determine a path is a mountpoint.
On Friday 19 February 2010 04:57:15 Ian Kent wrote:
On 02/19/2010 07:18 AM, Stef Bon wrote:
On Wednesday 17 February 2010 15:25:08 Ian Kent wrote:
My fusemodule is an overlay fs, which mirrors another directory under
the directory under which it's mounted, and does some changes.
aka unionfs type behaviour?
You are in for a bundle of trouble if your trying to implement an
overlay file system. If there are enough restrictions on functionality
you might be able to get this working reliably but the locking alone
will likely drive you nuts! You understand that once you play in kernel
space you can have multiple concurrent code paths accessing and possibly
changing the same data structures at the same time.
Well it's difficult, well not for me, but for the deveopers of FUSE. It's not
in kernel space, but in userspace. Never heard of?
With Fuse one is able to write your own fs, by just writing what all the basic
function do, like getattr, readdir, open, write and close. These are just a
selection, look at the website for more info.
http://fuse.sourceforge.net/
Im not running into trouble, it's just an filesystem which happens to be an
overlay fs.
My overlay is just like the mount --bind (or mount --rbind) command. It just
mirrors the contents of one directory into another.But it does more. It
reckognizes symbolic links which point to an autofs managed resource. Let me
explain:
A tree to SMB resources look like
$HOME/Network/Windows Network/BONONLINE/ADMIN/admin -
/mnt/mount.md5key/sbon/mount/50b89942f697f095ac66359eae1b3a8f
/documentation -
/mnt/mount.md5key/sbon/mount/68141c6ce3077c8e438f7b31c3002053
/public -
/mnt/mount.md5key/sbon/mount/795e5d59a7901e91296cf6aae0987c94
/sbon -
/mnt/mount.md5key/sbon/mount/8236f6c5eae783204a24f447c4ea8ec3
where the keys (50b8999... and the others) are names of records in
/var/cache/mount.md5key. Here the directories with these names exist, and
contain
information about the resource. This record is looked up by mount.md5key, and
the real mountcommand is started, with the right parameters.
Now this is not ideal, cause were dealing with symbolic links, pointing to the
targets. Most applications forget where they are coming from, which result in
the user browsing in /mnt/mount.md5key/ which should not happen. Futher,
when accessing the directory of the server, and listing the contents,
everey share is mounted, cause almost all applications want to know what the
target is what the links ar pointing at. And last but not least, a lot of
applications in KDE (I do not know abou Gnome) search for a .directory file in
the directory, making every target mounted.
To prevent this behaviour, I've started fuse-workspace-union, which mirrors the
connectionstree (with allkinds of links to different resources) to the
directory
under which it's mounted, and does some things. First it will translate
symbolic links, pointing to a directory in /mnt/mount.md5key/sbon/, into a
directory.
This will make it look like the shares are directl mounted in the
connectionsmap, while in fact it's just a trick.
mkdir -p /var/lib/workspace/sbon/{bind,conf}
mv $HOME/Network /var/lib/workspace/sbon/bind
mkdir $HOME/Workspace
start fuse-workspace-union with the right parameters:
/usr/bin/fuse-workspace-union $HOME/Workspace \
--bind-directory=/var/lib/workspace/sbon/bind \
--conf-directory=/var/lib/workspace/sbon/conf \
--autofs-mount-directory=/mnt/mount.md5key/sbon/mount \
--autofs-cache-directory=/var/cache/mount.md5key \
-o allow_root,default_permissions,use_ino
Now when I do:
cd $HOME/Workspace/Network/Windows Network/BONONLINE/ADMIN
ls -l
drwxr-xr-x 2 sbon netgroup 61 2009-12-31 21:17 admin
drwxr-xr-x 2 sbon netgroup 61 2009-12-31 21:17 documentation
drwxr-xr-x 2 sbon netgroup 61 2009-12-31 21:17 public
drwxr-xr-x 2 sbon netgroup 61 2009-12-31 21:17 sbon
Futher it will intercept call's for a .directory file, which will make the
resource to be mounted by the automounter, and present a standard .directory
file
instead.
FUSE does a lot of administration for me. It will generate inodes, handle
locks, is multitheaded. Extended attributes are supported, locking does work.
Only inotify is not implemented yet in my fs.
I hope things get more clear now, after this long story.
In a previous mail I've said that the key directories in the autofs managed
directory disappear when the resource is unmounted. I am wrong!
I've checked it again, and now the directories stay there, while the resource
is not mounted. Huh?? How come??
My directory looks like:
root [ /usr/src/cblfs-200910/autofs-5.0.5 ]# /bin/ls -l
/mnt
Re: [autofs] How to determine a path is a mountpoint.
On Tuesday 16 February 2010 18:29:00 Ian Kent wrote: On 02/16/2010 09:20 PM, Stef Bon wrote: On Tuesday 16 February 2010 04:04:17 Ian Kent wrote: On 02/16/2010 05:53 AM, Stef Bon wrote: Hello, Yes, checking /proc/mounts is slow but is the only way when using older versions of the kernel module. In a recent source tree, have a look at lib/mounts.c:is_mounted() and lib/dev-ioctl-lib.c, and in particular dev_ioctl_ismountpoint(). Ian Thanks for you fast answer. I've checked the code and found the functions you're pointed, they are indeed what I'm looking for. The function is_mounted looks like an internal function. It makes use of a struct ioctl_ops, which is initialised with get_ioctl_ops. I do not understand this, cause this function does not use any parameter (like path!) so how does this function determine it's a mountpoint? Read lib/dev-ioctl-lib.c, that's why I mentioned it, it's not that long. It implements a set of functions for autofs control operations. Many of them can't be called by just any process but the dev_ioctl_ismountpoint() function can. It may not look that simple but if you take some time to understand what it is doing you can take the bits you need and that will end up being fairly simple. The one problem you do have is that if the kernel doesn't have the new device ioctl interface you will need to scan /proc/mounts, the same as is done by the is_mounted() function if it sees the new functionality isn't available. Ok, but some helpe here is welcome. I've learned C just some months ago, and programming devices is new to me. Look at dev_ioctl_ismountpoint. The parameters it's using are logopt, ioctlfd, path and mountpoint. logopt has something to do with logging, and is important, but not the topic. ioctlfd is the filedescriptor for the fifo(?) in /var/run: /var/run/autofs.fifo-mnt-mount.md5key-sbon-mount in /proc/1705/fd : 9 - /var/run/autofs.fifo-mnt-mount.md5key-sbon-mount and 15 - /var/run/autofs.fifo-mnt-mount.md5key-root-mount futher path is of course the path to be examined. Is it absolute or relative and mountpoint is the value which is combination of DEV_IOCTL_IS_MOUNTED, DEV_IOCTL_IS_AUTOFS and DEV_IOCTL_IS_OTHER. Is my analysis good??? To be sure, the value's I'm looking for are autofs managed mountpoints (DEV_IOCTL_IS_AUTOFS is 1) and the path is a mountpoint, which means a resource is actually mounted here. (DEV_IOCTL_IS_OTHER). I'm using a setup where the autofs managed directories are one level deep, nothing more. But does this function really return a path is a mountpoint. In my module, it's already clear that it is an autofs managed dir. In my module autofs managed dirs are of the form /mnt/mount.md5key/%USERID%/mount/%md5key% where %md5key% is the md5sum of the resource record. My fuse module checks the dirname of the path is equal to /mnt/mount.md5key/%USERID%, and the basename is 32 long, and exists. Resource records, containing all the information about a resource (local like USB and remote like SMB and FTP) necessary to mount it. Now I want to add a test in my fusemodule fuse-workspace-union about this autofsmanaged directory is a an active mountpoint, or not active (expired/not activated...). It's not that important, but I want extra cosmetics. When mounted, I want the module to show another icon than when not mounted. Stef Ian ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
[autofs] How to determine a path is a mountpoint.
Hello, I'm working on a construction of the automounter in combination with a fuse module. The automounter is the mounthelper. I'm looking for a way to determine in C a directory is a mountpoint, specially a autofs managed directory, so a virtual directory created by the automounter. I can parse the /etc/mtab file or /proc/mounts, like in bash: cat /proc/mounts | grep --word-regexp $mountpoint but this is slow.. I have looked to the code of the program mountpoint, but this is not possible in an autofs maneged directory. This program does a cd to the directory and checks the filesystem changes. With autofs this makes the mountpoint always mounted, which is of course not what I'm looking for. Stef ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] sshfs and autofs
Marc Weber wrote:
Excerpts from Stef Bon's message of Wed Dec 23 23:31:15 +0100 2009:
Marc Weber wrote:
Excerpts from Stef Bon's message of Wed Dec 23 22:59:48 +0100 2009:
Stef Bon wrote:
This is the whole problem, because this is not easy. The automounter
(read man 5 autofs) can offer variables like USER, UID, etc,HOST
of the user requesting the mount (according to the manpage). Then to
present this user a suitable dialog... maybe via dbus???
I'm silly here, the user is not the problem, this is already available,
in the options, or - in my construction - in the config file, in the
parameter AUTOFS_USER
and in the mountpath, but the environment this user is using! A pid of
the process would be very usefull, for example.
But this is not easy. When I'm logged in twice with the same account,
which session should get the question for the passphrase?
About which session are you talking now? A ssh-agent session determined
by SSH_AGENT_PID and SSH_AUTH_SOCKET ?
Add this to your .bashrc or .zshrc:
reuseSSHAgent () {
local f=~/.current-ssh-agent
. $f || true
ps -p $SSH_AGENT_PID /dev/null || {
ssh-agent | grep -v echo $f
. $f
ssh-add
}
}
reuseSSHAgent
If there is a ssh agent running it will be used if not it will be
started. Then ssh-add will be run (I use only one key so this is
comfortable to me ..)
Maybe I should check that the socket file exists then I would'nt have to
run ps.
Gentoo has a nice script called keychain which provides this and more
for ssh-agent and the gnu-gpg agent. However I felt it was too bloated
and replaced it by this function.
You really don't want to type your password twice, do you ? :)
No, but sometimes inevitable.
I'm talking about the usersession. When logged in twice, and I'm
activating the mount at the second session (or login)
how does the automounter and the mount script know which usersession to
present a dialog.
This is no issue when you first enter the passphrase manually in the
first session, make use of it and reuse it on the second.
Stef
How does wall work ?
Maybe it should be asked on all terminals.
This would work.
But that's the reason why I didn't even try to find a solution.
If automount knew about the process id there might be a chance figuring
out about the tty being used..
But it's not a problem for me so I won't fix it unless you have an idea
which can be implemented fast.
Marc Weber
Well maybe PAM can help you here.
If you login with a password through pam, there are pammodules which can
do something with
the authentication. Long time ago I've setup a pam constrcution which
stores the username and the
password in a file. The module I used was pam_script.so, which is
developed not by the PAM team,
but since some time there is pam_exec.so, which does the same.
My login file in /etc/pam.d looks like:
#%PAM-1.0
authrequiredpam_shells.so
#auth requiredpam_env.so readenv=0
authrequiredpam_script.so
onauth=/etc/security/onauth.ldap expose=authtok (A)
authsufficient pam_ldap.so use_first_pass
authrequiredpam_script.so expose=authtok (B)
authrequiredpam_unix.so audit md5 shadow try_first_pass
account requiredpam_nologin.so
account sufficient pam_unix.so
account optionalpam_ldap.so
passwordsufficient pam_unix.so try_first_pass use_authtok
md5 shadow
passwordrequiredpam_ldap.so
session requiredpam_script.so runas=root (C)
session optionalpam_limits.so
session requiredpam_ck_connector.so
session optionalpam_mail.so dir=/var/mail standard
session requiredpam_unix.so shadow md5
session requiredpam_ldap.so
Let me explain what happens here:
at (A) the modules pam_script asks for a password, and exposes to the
script onauth.ldap. This script is in the /etc/security directory. Of
this option
is not supplied the default script onauth is run.
The onauth.ldap script is a symlink to onauth. It stores the password,
in the environment var PAM_AUTHTOK in a file on a temporary drive,
created at boottime, on my system at /var/run/safe:
tmpfs on /var/run/safe type tmpfs (rw,size=500k)
It's of course protected that only root can access these passwords, and
the user self.
Earlier I've also used encryption here, but a temporary drive which does
not exist when the system is down is sufficient.
Now the onauth.ldap script stores the password the
/var/run/safe/sbon/ldap dir, in the password.tmp file, and it creates a
symlink to it like:
/var/run/safe/sbon/latest - /var/run/safe/sbon/ldap
assuming sbon (me) is trying to login.
I wanted to make it obvious which
Re: [autofs] sshfs and autofs
SMB_auth_method=guest The md5key is the md5sum of this config file. A config file for a SSH address may look like (I'm not using it at this moment so I may forget something): NET_service=ssh LOCAL_user=root SSH_server=192.168.0.2 SSH_auth_method=agent Now the md5sum of this file is 2b2468c31ab6a00a3f47d5df01d7a116, create this directory: install -d /var/cache/mount.md5key/2b2468c31ab6a00a3f47d5df01d7a116 and move this record in it: mv from somehere/config /var/cache/mount.md5key/2b2468c31ab6a00a3f47d5df01d7a116 Now to access this resource, direct access is not very userfriendly, the md5keys only make sense to the computer, not the user. I've created a script which scans the cache (in /var/cache/mount.md5key/) for available resources for a user, and creates a tree in the homedirectory, which makes sense to the user, with symboliclinks to the right md5key entries: For me still as root this looks like: ~/Network/Windows Network/BONONLINE/LFS20060812/public - /mnt/mount.md5key/root/mount/1bf8a01af6d3eb08ffa08b9b6578f514 and ~/Network/SSH access/192.168.0.2 - /mnt/mount.md5key/root/mount/2b2468c31ab6a00a3f47d5df01d7a116 When entering these directories, (read following the link) the mount.md5key command looks for the key in /var/cache/mount.md5key/ directory, finds it, looks for the config file and launches the right mount command with the right parameters. You see the whole intelligent thing is done by the mount.md5key command, getting al the right information out off the config file. Now there are more I can tell you about this. The information about remote and local resources is not static. With Samba shares there are some utilities which cann help you to find out the resources a user logged in has access to, like nbtscan, nmblookup and smbclient. For other resources there might be other utilities. Futher I do not like these symbolic links. When following them, you as user might end up with your favorite app in /mnt/mount.md5key/%USER%/mount directory, looking to strange looking directories on a strange place in the filesystem. Thats the reason I'm working on an fuse modules (fuse-workspace I've called it) which mirrors this connections tree, where it's possible to make some symbolic links look like directories. It's too complicated, but look at http://linux.bononline.nl/linux/fuse-workspace/index.php and http://linux.bononline.nl/linux/mount.md5key/index.php http://linux.bononline.nl/linux/runsessionscripts/index.php Now to get back to your problem, as I understand it, I've read some manpages, and yes I'm using private/public keys without passphrase. I did not know about agents until now. I understand that this communication through this agent makes it easier to make a ssh connection. If I'm wrong please correct. Next add the .ssh/id_dsa and .ssh/id_rsa and .ssh/identity files with ssh-add. If this is done, other applications do not have to enter the passphrase anymore, if they make use of this agent, which they can find though the environment variables. But the ssh-add command asks for the passphrase, and if done in an environment with the automounter you have a problem here, I understand. In my setup the mount.md5key command has to find out who is activating the mount, and what the evironment is (simple terminal or X) and present a passphrase dialog. Apart problem: how to store the information about the agent for other apps. This is the whole problem, because this is not easy. The automounter (read man 5 autofs) can offer variables like USER, UID, etc,HOST of the user requesting the mount (according to the manpage). Then to present this user a suitable dialog... maybe via dbus??? I do not have a sollution for you here, sorry, I can ony analyze it's difficult. I think that your script tries to offer a dialog somehere, but that it does not reach you as user... Earlier I've thought about this when entering a Windows/Samba share, but I left it for exact these reasons. Somebody else?? Stef Bon For this reason you find many howtos when googling telling you how to setup keys with empty passwords because this just works. I have two goals: a) figuring out whether there are even nicer solutions b) telling people that they can use password protected private keys and automount using my script. Here again I'm trying to help here. Thanks for doing so. I hope that this mail showing you how to use ssh-agents does help you a little bit understanding my configuration. Marc Weber ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] sshfs and autofs
Stef Bon wrote: This is the whole problem, because this is not easy. The automounter (read man 5 autofs) can offer variables like USER, UID, etc,HOST of the user requesting the mount (according to the manpage). Then to present this user a suitable dialog... maybe via dbus??? I'm silly here, the user is not the problem, this is already available, in the options, or - in my construction - in the config file, in the parameter AUTOFS_USER and in the mountpath, but the environment this user is using! A pid of the process would be very usefull, for example. But this is not easy. When I'm logged in twice with the same account, which session should get the question for the passphrase? Stef ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] sshfs and autofs
Marc Weber wrote:
Excerpts from Stef Bon's message of Wed Dec 23 22:59:48 +0100 2009:
Stef Bon wrote:
This is the whole problem, because this is not easy. The automounter
(read man 5 autofs) can offer variables like USER, UID, etc,HOST
of the user requesting the mount (according to the manpage). Then to
present this user a suitable dialog... maybe via dbus???
I'm silly here, the user is not the problem, this is already available,
in the options, or - in my construction - in the config file, in the
parameter AUTOFS_USER
and in the mountpath, but the environment this user is using! A pid of
the process would be very usefull, for example.
But this is not easy. When I'm logged in twice with the same account,
which session should get the question for the passphrase?
About which session are you talking now? A ssh-agent session determined
by SSH_AGENT_PID and SSH_AUTH_SOCKET ?
Add this to your .bashrc or .zshrc:
reuseSSHAgent () {
local f=~/.current-ssh-agent
. $f || true
ps -p $SSH_AGENT_PID /dev/null || {
ssh-agent | grep -v echo $f
. $f
ssh-add
}
}
reuseSSHAgent
If there is a ssh agent running it will be used if not it will be
started. Then ssh-add will be run (I use only one key so this is
comfortable to me ..)
Maybe I should check that the socket file exists then I would'nt have to
run ps.
Gentoo has a nice script called keychain which provides this and more
for ssh-agent and the gnu-gpg agent. However I felt it was too bloated
and replaced it by this function.
You really don't want to type your password twice, do you ? :)
No, but sometimes inevitable.
I'm talking about the usersession. When logged in twice, and I'm
activating the mount at the second session (or login)
how does the automounter and the mount script know which usersession to
present a dialog.
This is no issue when you first enter the passphrase manually in the
first session, make use of it and reuse it on the second.
Stef
___
autofs mailing list
autofs@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] sshfs and autofs
Marc Weber wrote: # ls -l /auto ls: cannot access /auto/mlin: Permission denied total 0 d? ? ? ? ?? mlin Well the question marks mean that glibc cannot figure out the permissions. This means probably that the mount has not been succesfull. It was. The user can access it. But root can't. Does this work. I do not know anything about ssh agents. Than you should start to learn at least some basics. An ssh-agent is a process which keeps your passwords in memory to unlock the .ssh/id_* keys. Of course it works. I'm using it. Wow, I'm just making clear that I do not know anything these agents. I'm just asking you about it, but not doubting your abilities. I n my construction I'm using the following command: PasswordAuthentication='no' -o IdentityFile=$homedir/.ssh/id_dsa -o This id_dsa, is it protected by password? If you use google to find out how to use automount and sshfs you'll find many instructions about how to generate a key with empty password and how to configure automount. However using an empty password is not an option for me. Here again I'm trying to help here. I'm just trying to figure out (see above) how your setup works, and I try to be of some help here. But it looks if you already know everything, and it looks as you don't want to be helped. Be a little bit more specific and understand that somebody else does not understand your setup immediatly, Stef Bon the directory /mnt/mount.md5key/%USER% is owned by the user and has permissions 700, so no other user except How do you assign these permissions 700 ? I didn't suceed Marc Weber ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
[autofs] shell environment when mounting
Hello, I'm using a construction where the automounter is started when a sessions starts, using ConsoleKit. Look at: http://linux.bononline.nl/linux/fuse-workspace/index.php I'm using the feature of ConsoleKit to run a script/program when a session is added, and when it's removed, in /etc/ConsoleKit/run.d. Now here some environmentvariables are set by ConsoleKit, indicating the user, the seat and the session, and more. Part of my construction is a wrapper shell script around mount.cifs, which calls mount.cifs with the right parameters. It's a sh script. Now I've found out that the environmentvariables set by ConsoleKit are still set when this script is run. It looks like the mount.md5key (this is the name of the wrapper) shell script is using the same environment as when the automounter is started. Is this right?? Stef Bon ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] ldap and reloading
Ian Kent wrote: Stef Bon wrote: Hello, when using static file maps, or even executable maps, when the map changes, you'll have to reload the daemon to make these changes effective. How does this work when all the data is in ldap? Does the automounter still creates a sort of snapshot of the map in memory, and to reread the data provided by ldap, a reload is neccesary? ldap is well know for that this is not needed. For example with postfix, it can use static maps, and when something changes, it has te be restarted. But when the lookup data (for local users for example) is in ldap, this is not neccesary. That's not quite right. If you use the browse option then the entire map must be read in at start. If not then autofs remembers entries that it has seen and attempts to check their currency at lookup. Each lookup should check if the entry is still up to date and attempts to work out if the map has changed (although it's not quite as simple as that). If we think the map has changed a re-load should be triggered internally. Following the (or any) re-load there is a cleanup which is probably why it looks like map changes aren't seen. Any changes in multi-mount entries cannot be seen until after they have expired away, because of the need to maintain the context of the entry over the duration of the mount. Direct maps don't quite do this properly, partly because of the way they work and partly because of an issue I haven't addressed yet. Clearly, with program maps, we need to rely on the re-load to a large extent but a best effort is made to work out if the entry is stale, however, we just don't have anything really to use to establish this, so a re-load is needed to clean them up. Ok Ian, maybe you're right. You probably are, I cannot discuss this with you, you're the expert. You say that it may look like map changes aren't seen. How, as developer of a construction making use of autofs, can I see/check it's reloaded. Are there any indications, or triggers which always lead to this internal reloading? BTW I also use reloading when a map/mountpoint is added or removed, so not only when a map changes. I know multimount entries are difficult, and are handled as one. But how about ldap? I assume you're talking about how maps are handled here in general, but is this different/the same with ldap?? Stef Bon ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] ldap and reloading
Ian Kent wrote: Ondrej Valousek wrote: Talking about ldap maps reloading - maybe it is worth mentioning that if you configure automounter using the recently added DNS SRV support, automounter reloads itself as per zone TTL in DNS (that includes the master map, too) - right Ian? Ondrej Not quite. On re-load, if the last time we got the list of servers is greater than the ttl it will lookup there server list again before attempting to read from them. Map entry lookups them selves don't check this ttl so a re-load is only done if we think the map has changed. Well, this is all getting very complicated. Too complicated for me. The only thing I'm using autofs for is creating a autofs managed directory in the homedirectory, for mounting local (USB) and remote (SMB shares) resources. To make this work, the autofs daemon has to reread the configuration of maps multiple times. It would be so much easier if there is a sort of autofsctl utility for adding/removing mountpoints, and changing maps. for example: a. add a mounpoint and map. b. delete a mountpoint c. change a map. Now when something changes, the global remounter gets a reload signal, which is still buggy. I'm still having problems here, but since I've upgraded the kernel to linux-2.6.29.4 I've got less problems. Stef ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
[autofs] ldap and reloading
Hello, when using static file maps, or even executable maps, when the map changes, you'll have to reload the daemon to make these changes effective. How does this work when all the data is in ldap? Does the automounter still creates a sort of snapshot of the map in memory, and to reread the data provided by ldap, a reload is neccesary? ldap is well know for that this is not needed. For example with postfix, it can use static maps, and when something changes, it has te be restarted. But when the lookup data (for local users for example) is in ldap, this is not neccesary. If this is the case, I go directly over to ldap. Stef ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
[autofs] again: automounters stops after reload signal
Hello, again I'm having trouble with reloading the automounter. After removing an usb device, the map for local devices is corrected: the line for this device is removed. Then, a reload signal to the automounter should make this effective. in detail: my auto.master looks like: /mnt/sd /etc/autofs/auto.sd --timeout=50 +/var/run/autofs/auto.master before removing the usb device: /var/run/autofs/auto.master: /home/sbon/Connections/Devices /var/run/autofs/session/auto.local.map.sbon --ghost --timeout=0 /home/sbon/Connections/Network /var/run/autofs/session/auto.network.map.sbon --ghost /root/Connections/Network /var/run/autofs/session/auto.network.map.root --ghost /var/run/autofs/session/auto.local.map.sbon: USB Flash Memory -fstype=auto :/dev/sdb1 Now after removing, the scripts first unmount /dev/sdb1, then remove this line from the mapfile, then correct the auto.master and the do a reload: after removing the usb device: /var/run/autofs/auto.master: /home/sbon/Connections/Network /var/run/autofs/session/auto.network.map.sbon --ghost /root/Connections/Network /var/run/autofs/session/auto.network.map.root --ghost the /var/run/autofs/session/auto.local.map.sbon file is empty. The reload signal makes the automounter stop. I've applied al the latest patches. Stef Bon logfile: 2009-06-02T13:46:37.670526+02:00 lfs20080510 : Reloading the automounter. 2009-06-02T13:46:37.681826+02:00 lfs20080510 automount[14339]: re-reading master map /etc/autofs/auto.master 2009-06-02T13:46:37.681877+02:00 lfs20080510 automount[14339]: lookup_nss_read_master: reading master file /etc/autofs/auto.master 2009-06-02T13:46:37.681929+02:00 lfs20080510 automount[14339]: parse_init: parse(sun): init gathered global options: (null) 2009-06-02T13:46:37.682002+02:00 lfs20080510 automount[14339]: lookup_read_master: lookup(file): read entry /mnt/sd 2009-06-02T13:46:37.682069+02:00 lfs20080510 automount[14339]: lookup_read_master: lookup(file): read entry +/var/run/autofs/auto.master 2009-06-02T13:46:37.682100+02:00 lfs20080510 automount[14339]: lookup_nss_read_master: reading master file /var/run/autofs/auto.master 2009-06-02T13:46:37.682138+02:00 lfs20080510 automount[14339]: parse_init: parse(sun): init gathered global options: (null) 2009-06-02T13:46:37.682180+02:00 lfs20080510 automount[14339]: lookup_read_master: lookup(file): read entry /home/sbon/Connections/Network 2009-06-02T13:46:37.682234+02:00 lfs20080510 automount[14339]: lookup_read_master: lookup(file): read entry /root/Connections/Network 2009-06-02T13:46:37.682314+02:00 lfs20080510 automount[14339]: st_readmap: state 1 path /home/sbon/Connections/Network 2009-06-02T13:46:37.682360+02:00 lfs20080510 automount[14339]: re-reading map for /home/sbon/Connections/Network 2009-06-02T13:46:37.682364+02:00 lfs20080510 automount[14339]: st_readmap: state 1 path /mnt/sd 2009-06-02T13:46:37.682368+02:00 lfs20080510 automount[14339]: re-reading map for /mnt/sd 2009-06-02T13:46:37.682372+02:00 lfs20080510 automount[14339]: st_prepare_shutdown: state 1 path /home/sbon/Connections/Devices 2009-06-02T13:46:37.682429+02:00 lfs20080510 automount[14339]: lookup_nss_read_map: reading map file /var/run/autofs/session/auto.network.map.sbon 2009-06-02T13:46:37.682455+02:00 lfs20080510 automount[14339]: expire_proc: exp_proc = 3058047888 path /home/sbon/Connections/Devices 2009-06-02T13:46:37.682508+02:00 lfs20080510 automount[14339]: st_readmap: state 1 path /root/Connections/Network 2009-06-02T13:46:37.682716+02:00 lfs20080510 automount[14339]: parse_init: parse(sun): init gathered global options: (null) 2009-06-02T13:46:37.682876+02:00 lfs20080510 automount[14339]: lookup_nss_read_map: reading map file /etc/autofs/auto.sd 2009-06-02T13:46:37.682922+02:00 lfs20080510 automount[14339]: re-reading map for /root/Connections/Network 2009-06-02T13:46:37.682974+02:00 lfs20080510 automount[14339]: parse_init: parse(sun): init gathered global options: (null) 2009-06-02T13:46:37.682979+02:00 lfs20080510 automount[14339]: lookup_nss_read_map: reading map file /var/run/autofs/session/auto.network.map.root 2009-06-02T13:46:37.682998+02:00 lfs20080510 automount[14339]: parse_init: parse(sun): init gathered global options: (null) 2009-06-02T13:46:37.683065+02:00 lfs20080510 automount[14339]: st_ready: st_ready(): state = 4 path /mnt/sd 2009-06-02T13:46:37.683070+02:00 lfs20080510 automount[14339]: expire_cleanup: got thid 3058047888 path /home/sbon/Connections/Devices stat 0 2009-06-02T13:46:37.683074+02:00 lfs20080510 automount[14339
Re: [autofs] writing to fstab or mtab
Jeff Moyer wrote: Stef Bon s...@bononline.nl writes: Hello, Now to prevent HAL to try to mount the device at /media, the scripts in my contruction write a line to /etc/fstab, like: /dev/sdb1 /home/sbon/Connections/Devices/USB\040stick auto noauto,user 0 0 This works very good, but this setting in fstab confuses the automounter. I'm not trying to solve my problem here with hal, but how come the setting in fstab to confuse autofs? Stef, you're going to have to be a bit more specific! What do you mean it confuses the automounter? What behaviour is expected/observed? Do you have a debug log? Cheers, Jeff Thanks for your reply, I've solved the problem already by adding the --timeout=0 option to the map for usb devices. Then by activating the mount directly, the mount is written to mtab. KDE finds this mount then, and bypasses HAL, what is the goal. Stef ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
[autofs] writing to fstab or mtab
Hello, I've created a construction which mounts via autofs local (USB devices) and remote resources (SMB, FTP and SSH) resources in a subdirectory of the homedirectory of the user logged in. This works with ConsoleKit, udev and autofs. Look at: http://linux.bononline.nl/linux/autofsmanaged/index.php It looks like: http://www.gentoo-wiki.info/Autofs#UDEV_with_autofs But there is some trouble with hal, hal tries to mount the local devices at /media, which is exported to the desktopenvironment KDE. This leads to the confusing situation that in the places toolbar there is a icon for the device, and in my homedirectory a directory managed by autofs. When I click on the icon, the device is mounted at /media, when I enter the directory $HOME/Connections/Devices/USB stick (for example), it's mounted here. The nice thing here is that the icon in my places toolbar changes also then. It's notified (via mtab/HAL I think) that the device is mounted. Now when I click on it, Dolphin leads me to the right place. Now to prevent HAL to try to mount the device at /media, the scripts in my contruction write a line to /etc/fstab, like: /dev/sdb1 /home/sbon/Connections/Devices/USB\040stick auto noauto,user 0 0 This works very good, but this setting in fstab confuses the automounter. I'm not trying to solve my problem here with hal, but how come the setting in fstab to confuse autofs? Stef Bon PS problems with hal are there because it's to rigid about where devices are mounted, and it's not aware of user sessions. Linux is a multiuser system, but HAL not. ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] Automounter stops after reload signal.
Ian Kent wrote: On Fri, Apr 24, 2009 at 10:19:19AM +0200, Stef Bon wrote: Ian Kent wrote: Oops, that's not quite right. Try this instead, of course the CHANGELOG hunk might not apply. And there was another mistake in this patch. This one hopefully will be the final form of the fix. autofs-5.0.4 - library reload fix update fix Ok, I have not been able to apply and test this patch. The last one is doing very well. I'll recompile autofs with this new patch and report this. Stef Bon ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
[autofs] Map a single file??
Hello, I would like to know is it possible for the automounter to map a single file? In KDE, the filemanagers Dolphin and Konqueror look for the file .directory in every directory. In some cases I want to present a special .directory file. The automounter is presenting a tree which consist of networks, workgroups, servers and shares. For the network for example, the windows network folder icon would be something like an windows icon. This can be set in the .directory file. Futher I want these directories presented as icons, not in list. So, can the automounter map single files, besides directories mapped to networkmountpoints? Stef Bon ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] Automounter stops after reload signal.
Ian Kent wrote:
Oops, that's not quite right.
Try this instead, of course the CHANGELOG hunk might not apply.
autofs-5.0.4 - library reload fix update fix
From: Ian Kent ra...@themaw.net
The library reload fixes introduced a bug which causes autofs to
incorrectly shutdown. Previously the signal handling thread only
recieved signals either when they were explicity sent or it was
time to shutdown so continuing on to call the signal handling
routine was the correct thing to do. Now we need to join with
the mount handling thread at exit but, in this case, we don't
want to continue on to the signal handling routine as that will
incorrectly cause the signal to be passed on to other mount
handling threads.
---
CHANGELOG |1 +
daemon/automount.c | 13 +++--
lib/master.c |2 --
3 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/CHANGELOG b/CHANGELOG
index 7ca45fd..5e01812 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -44,6 +44,7 @@
- use intr option as hosts mount default.
- fix kernel includes.
- dont umount existing direct mount on master re-read.
+- fix incorrect shutdown introduced by library relaod fixes.
4/11/2008 autofs-5.0.4
---
diff --git a/daemon/automount.c b/daemon/automount.c
index 80691fa..d7e3e12 100644
--- a/daemon/automount.c
+++ b/daemon/automount.c
@@ -1332,8 +1332,17 @@ static void *statemachine(void *arg)
case SIGTERM:
case SIGINT:
case SIGUSR2:
- if (master_done(master_list))
- return NULL;
+ master_mutex_lock();
+ if (!list_empty(master_list-completed)) {
+ if (master_done(master_list)) {
+ master_mutex_unlock();
+ return NULL;
+ }
+ master_mutex_unlock();
+ break;
+ }
+ master_mutex_unlock();
+
case SIGUSR1:
do_signals(master_list, sig);
break;
diff --git a/lib/master.c b/lib/master.c
index 762094f..e43f835 100644
--- a/lib/master.c
+++ b/lib/master.c
@@ -1182,7 +1182,6 @@ int master_done(struct master *master)
struct master_mapent *entry;
int res = 0;
- master_mutex_lock();
head = master-completed;
p = head-next;
while (p != head) {
@@ -1195,7 +1194,6 @@ int master_done(struct master *master)
}
if (list_empty(master-mounts))
res = 1;
- master_mutex_unlock();
return res;
}
Ok, thanks a lot! I will try this.
Stef Bon
___
autofs mailing list
autofs@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/autofs
[autofs] hal and autofs
Hello, I've created a construction which mounts local devices like USB sticks and remote (network) services in a connectionsmap in the users homedirectory. Integration with my desktop (KDE 4.2) is not that good. When in Dolphin, it tries to mount the devices at /media, not in this autofs managed directory (in my case /home/sbon/Connections/Devices). Responsible for this behaviour in KDE is HAL. Integration of autofs and hal is imho a good idea. It should be an configurationoption to let the automounter handle the mounting, or do it the way things are done at this moment (by HAL). Required is that autofs has dbus support. I do not have a lot of experience with dbus, but other systems should be able to add a mountpoint (with all options and the path to the local device), and autofs should export information about all mountpoints it manages, and which devices are mounted or not. What's your opinion, is this possible? Stef Bon ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] Automounter stops after reload signal.
Ian Kent wrote: Stef Bon wrote: Ian Kent wrote: On Wed, 2009-04-08 at 18:14 +0200, Stef Bon wrote: Hello, I've been working on a construction which adds an autofs managed mountpoint to the homedirectory, when: a. an usb device or more than one is detected when logging in b. an usb device is plugged in during a session What version of autofs did you say you are using? Well, 5.0.4. OK, then the daemon should remain running as long as there is at least one entry in the master map. If the daemon receives a HUP signal then any mount handling threads that terminate will send SIGTERM to the signal catching thread. If the master map becomes empty during this SIGTERM check autofs will exit. That is what the daemon exit condition is and we do need such a condition to be able to exit at all. If something else is happening in your case then we need to work out what's going on. Yes, the auto.master file is not empty. In all of my cases, and in the example below, the auto.master file has one line which is there always: /mnt/sd /etc/autofs/auto.sd --timeout=50 I remember that I have added this line to prevent this unwanted behaviour. In my construction it can happen that when no users are logged in (after logout), there are no mountpoints, and then the automounter did stop also. So then I added this line, and the behaviour disappeared. Now it's back again. Removing a mountpoint, and reloading gives this behaviour, even if there are other mountpoints and maps in the auto.master file. Ok, so this should be a bug, if you say that, when the auto.master file is empty, the automounter should stop after a HUP signal. Apart from this bug, I do not understand this. You say it's necessary to exit at all, but is this a technical reason? The master daemon should not stop after a reload signal, even if the master file is empty. Stef Bon However, there are a couple of patches against 5.0.4 in this area of the code, but I'm not sure they make the above behaviour different. We could give then a try. I can imagine that my story is complicated, so I've found a simple way to get the same behaviour. Add the following line to the auto.master file in /etc/autofs: /mnt/smb /etc/autofs/auto.smb Start the daemon, or, if already running, do a reload. Play with the new mountpoint, so do something like : ls /mnt/smb/valid name of smb host look at the result, a tree should be the result. Now remove the line again, (thus: /mnt/smb /etc/a), and give the daemon a reload again, and the daemon stops. As it should if there are no master map entries remaining. I've been here before and I think trying to change the exit condition will be quite hard. I've got a 2.6.27.9 kernel, patched with autofs4-2.6.27-dev-ioctl-20081029.patch and autofs4-2.6.27-v5-update-20081027.patch Stef Bon ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] Automounter stops after reload signal.
Ian Kent wrote: On Wed, 2009-04-08 at 18:14 +0200, Stef Bon wrote: Hello, I've been working on a construction which adds an autofs managed mountpoint to the homedirectory, when: a. an usb device or more than one is detected when logging in b. an usb device is plugged in during a session What version of autofs did you say you are using? Well, 5.0.4. I can imagine that my story is complicated, so I've found a simple way to get the same behaviour. Add the following line to the auto.master file in /etc/autofs: /mnt/smb /etc/autofs/auto.smb Start the daemon, or, if already running, do a reload. Play with the new mountpoint, so do something like : ls /mnt/smb/valid name of smb host look at the result, a tree should be the result. Now remove the line again, (thus: /mnt/smb /etc/a), and give the daemon a reload again, and the daemon stops. I've got a 2.6.27.9 kernel, patched with autofs4-2.6.27-dev-ioctl-20081029.patch and autofs4-2.6.27-v5-update-20081027.patch Stef Bon ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
[autofs] Automounter stops after reload signal.
Hello, I've been working on a construction which adds an autofs managed mountpoint to the homedirectory, when: a. an usb device or more than one is detected when logging in b. an usb device is plugged in during a session This looks like: /home/sbon/Connections is the base directory for all kinds of connections (network, all kind of hardware) Earlier I've been working on a construction to create a browseable network map here, also with autofs. Network resources like SMB shares, FTP servers and SSH access is possible. (SMB via cifs, FTP via curlftpfs/FUSE, SSH via sshfs/FUSE). Access to Novell networks should also be possible. Now about devices. When I add a device during my session, the (virtual) directory Devices is added, and therein my USB stick: /home/sbon/Connections/Devices/USB_DISK_Pro Other devices should also appear in this directory. I do not have published this yet anywhere, but it is simular to the one you can find here: http://www.gentoo-wiki.info/Autofs#UDEV_with_autofs The big difference with my construction is that the mountpoint is *in* the users homedirectory, not in /media: direct accessible for users from their homedirectory, where going to a foreign place like /media is not that userfriendly. Now I've got the following situation: my mastermap looks like: /mnt/sd /etc/autofs/auto.sd --timeout=50 +/var/run/autofs/auto.master and /var/run/autofs/auto.master: /home/sbon/Connections/Network /var/run/autofs/session/auto.network.map.sbon --ghost /home/sbon/Connections/Devices /var/run/autofs/session/auto.usb.map.sbon --ghost the automaps are dynamically created maps: /var/run/autofs/session/auto.usb.map.sbon: USB_DISK_Pro -fstype=auto :/dev/disk/by-uuid/6891-3786 and /var/run/autofs/session/auto.network.map.sbon: FTP -fstype=ftpfs \ /192.168.0.1 ://192.168.0.1 \ /ftp-stud.fht-esslingen.de ://ftp-stud.fht-esslingen.de Windows Network -fstype=cifs,credentials=/var/run/safe/sbon/latest/mount.smb.cred \ /BONONLINE/ROUTER/sbon -rw,ip=192.168.0.1 ://ROUTER/sbon \ /BONONLINE/ROUTER/bononline -rw,ip=192.168.0.1 ://ROUTER/bononline \ /BONONLINE/ROUTER/mvanklink -rw,ip=192.168.0.1 ://ROUTER/mvanklink \ /BONONLINE/ROUTER/ftp -rw,ip=192.168.0.1 ://ROUTER/ftp \ /BONONLINE/ROUTER/public -rw,ip=192.168.0.1 ://ROUTER/public \ /BONONLINE/ROUTER/cwdocumenten -rw,ip=192.168.0.1 ://ROUTER/cwdocumenten \ /BONONLINE/LFS20060812/sbon -rw,ip=192.168.0.2 ://LFS20060812/sbon \ /BONONLINE/LFS20060812/bononline -rw,ip=192.168.0.2 ://LFS20060812/bononline \ /BONONLINE/LFS20060812/video -rw,ip=192.168.0.2 ://LFS20060812/video \ /BONONLINE/LFS20060812/test -rw,ip=192.168.0.2 ://LFS20060812/test \ /BONONLINE/LFS20060812/public -rw,ip=192.168.0.2 ://LFS20060812/public SSH access -fstype=sshfs \ /192.168.0.1 ://s...@192.168.0.1:/ \ /192.168.0.2 ://s...@192.168.0.2:/ These maps are created dynamically, by udev (when plugging in a device) and at login (coldpluggin and the networkmap) There is a script which is run by udev when a device is removed. After removal of the usbstick, my maps look like: /var/run/autofs/auto.master /home/sbon/Connections/Network /var/run/autofs/session/auto.network.map.sbon --ghost The networkmap is unchanged. After a reload the automounter has stopped. Attached is the relevant output of the logfile. This behaviour I get also in siumlar situations. For example, logging in as sbon, adding a device, then logging in as root in a terminal(konsole and then su), everything is still ok (the maps above are changed: mountpoints and maps are added. But when logging out as root, and the maps are changed again, the automounter stops also. It looks like the automounter cannot handle the removal of mountpoints correctly. It will stop. Stef Bon 2009-04-08T13:08:40.686693+02:00 lfs20080510 kernel:6usb 6-1.3: USB disconnect, address 4 2009-04-08T13:08:40.714507+02:00 lfs20080510 : The configuration file /etc/autofs.usersession.conf found. 2009-04-08T13:08:40.716559+02:00 lfs20080510 : Parameter DEVICES_NAME not set. Using default. 2009-04-08T13:08:40.770432+02:00 lfs20080510 automount[5948]: re-reading master map /etc/autofs/auto.master 2009-04-08T13:08:40.770586+02:00 lfs20080510 automount[5948]: lookup_nss_read_master: reading master file /etc/autofs/auto.master 2009-04-08T13:08:40.770645+02:00 lfs20080510 automount[5948]: parse_init: parse(sun): init gathered global options: (null) 2009-04-08T13:08:40.770723+02:00 lfs20080510 automount[5948]: lookup_read_master: lookup(file): read entry /mnt/sd 2009-04-08T13:08:40.770791+02:00 lfs20080510 automount[5948]: lookup_read_master: lookup(file): read entry +/var/run/autofs/auto.master 2009-04-08T13:08:40.770826+02:00 lfs20080510 automount[5948]: lookup_nss_read_master: reading master file /var/run/autofs/auto.master 2009-04-08T13:08:40.770868+02:00 lfs20080510 automount[5948]: parse_init: parse(sun
[autofs] Automounter stops after reload signal.
(I've sent this earlier to the autofs maillist but it doesnot appear there, I do not get a copy also myself) Hello, I've been working on a construction which adds an autofs managed mountpoint to the homedirectory, when: a. an usb device or more than one is detected when logging in b. an usb device is plugged in during a session This looks like: /home/sbon/Connections is the base directory for all kinds of connections (network, all kind of hardware) Earlier I've been working on a construction to create a browseable network map here, also with autofs. Network resources like SMB shares, FTP servers and SSH access is possible. (SMB via cifs, FTP via curlftpfs/FUSE, SSH via sshfs/FUSE). Access to Novell networks should also be possible. Now about devices. When I add a device during my session, the (virtual) directory Devices is added, and therein my USB stick: /home/sbon/Connections/Devices/USB_DISK_Pro Other devices should also appear in this directory. I do not have published this yet anywhere, but it is simular to the one you can find here: http://www.gentoo-wiki.info/Autofs#UDEV_with_autofs The big difference with my construction is that the mountpoint is *in* the users homedirectory, not in /media: direct accessible for users from their homedirectory, where going to a foreign place like /media is not that userfriendly. Now I've got the following situation: my mastermap looks like: /mnt/sd /etc/autofs/auto.sd --timeout=50 +/var/run/autofs/auto.master and /var/run/autofs/auto.master: /home/sbon/Connections/Network /var/run/autofs/session/auto.network.map.sbon --ghost /home/sbon/Connections/Devices /var/run/autofs/session/auto.usb.map.sbon --ghost the automaps are dynamically created maps: /var/run/autofs/session/auto.usb.map.sbon: USB_DISK_Pro -fstype=auto :/dev/disk/by-uuid/6891-3786 and /var/run/autofs/session/auto.network.map.sbon: FTP -fstype=ftpfs \ /192.168.0.1 ://192.168.0.1 \ /ftp-stud.fht-esslingen.de ://ftp-stud.fht-esslingen.de Windows Network -fstype=cifs,credentials=/var/run/safe/sbon/latest/mount.smb.cred \ /BONONLINE/ROUTER/sbon -rw,ip=192.168.0.1 ://ROUTER/sbon \ /BONONLINE/ROUTER/bononline -rw,ip=192.168.0.1 ://ROUTER/bononline \ /BONONLINE/ROUTER/mvanklink -rw,ip=192.168.0.1 ://ROUTER/mvanklink \ /BONONLINE/ROUTER/ftp -rw,ip=192.168.0.1 ://ROUTER/ftp \ /BONONLINE/ROUTER/public -rw,ip=192.168.0.1 ://ROUTER/public \ /BONONLINE/ROUTER/cwdocumenten -rw,ip=192.168.0.1 ://ROUTER/cwdocumenten \ /BONONLINE/LFS20060812/sbon -rw,ip=192.168.0.2 ://LFS20060812/sbon \ /BONONLINE/LFS20060812/bononline -rw,ip=192.168.0.2 ://LFS20060812/bononline \ /BONONLINE/LFS20060812/video -rw,ip=192.168.0.2 ://LFS20060812/video \ /BONONLINE/LFS20060812/test -rw,ip=192.168.0.2 ://LFS20060812/test \ /BONONLINE/LFS20060812/public -rw,ip=192.168.0.2 ://LFS20060812/public SSH access -fstype=sshfs \ /192.168.0.1 ://s...@192.168.0.1:/ \ /192.168.0.2 ://s...@192.168.0.2:/ These maps are created dynamically, by udev (when plugging in a device) and at login (coldpluggin and the networkmap) There is a script which is run by udev when a device is removed. After removal of the usbstick, my maps look like: /var/run/autofs/auto.master /home/sbon/Connections/Network /var/run/autofs/session/auto.network.map.sbon --ghost The networkmap is unchanged. After a reload the automounter has stopped. Attached is the relevant output of the logfile. This behaviour I get also in siumlar situations. For example, logging in as sbon, adding a device, then logging in as root in a terminal(konsole and then su), everything is still ok (the maps above are changed: mountpoints and maps are added. But when logging out as root, and the maps are changed again, the automounter stops also. It looks like the automounter cannot handle the removal of mountpoints correctly. It will stop. Stef Bon 2009-04-08T13:08:40.686693+02:00 lfs20080510 kernel:6usb 6-1.3: USB disconnect, address 4 2009-04-08T13:08:40.714507+02:00 lfs20080510 : The configuration file /etc/autofs.usersession.conf found. 2009-04-08T13:08:40.716559+02:00 lfs20080510 : Parameter DEVICES_NAME not set. Using default. 2009-04-08T13:08:40.770432+02:00 lfs20080510 automount[5948]: re-reading master map /etc/autofs/auto.master 2009-04-08T13:08:40.770586+02:00 lfs20080510 automount[5948]: lookup_nss_read_master: reading master file /etc/autofs/auto.master 2009-04-08T13:08:40.770645+02:00 lfs20080510 automount[5948]: parse_init: parse(sun): init gathered global options: (null) 2009-04-08T13:08:40.770723+02:00 lfs20080510 automount[5948]: lookup_read_master: lookup(file): read entry /mnt/sd 2009-04-08T13:08:40.770791+02:00 lfs20080510 automount[5948]: lookup_read_master: lookup(file): read entry +/var/run/autofs/auto.master 2009-04-08T13:08:40.770826+02:00 lfs20080510 automount[5948]: lookup_nss_read_master: reading master file /var/run/autofs/auto.master 2009-04-08T13
Re: [autofs] make an executable map rerun.
Ian Kent wrote: No, after activating the executable map once, the data provided by the executable map is kept. I've tested this by letting the executable map write to an logfile, and it's running seldom. I can look at the contents of /proc/mounts and here I see the autofs tree, which is kept. So I do not understand your remark saying it is consulted every single lookup. Does the option -browse mather here? I'm using that and because this forces the automounter to remember the data right? It just means that autofs won't delete mount point directories after they expire. Actually, this case looks like another problem, in that we'll get directories that being retained that are no longer valid. Oh well, that's something for another day. I'm checking I understand your reaction. You point at the browse option which forces autofs to not delete mount point directories. Anyway, if the entry isn't a multi-mount (in which case it must not be forgotten until it expires away) then it will be deleted from the cache and the program map consulted again if the cache entry is older than the negative timeout. Maybe making the negative timeout smaller would do what you need, hopefully without causing other issues. The default negative timeout is 60 seconds. I will try this, but I'm using executable maps which produce a multi-mount map. OK, I was wrong. Sorry about that (I was confused with the fact that program maps don't support the -browse option, since they can't support map enumeration). I admit I am not up to speed on v5. However, it looks to me like a HUP signal will not cause the service thread for your mount point to restart unless the actual program map changed. This means the cache will still be in tact, as you observed. I suspect we should probably clear the cache for any maptype that does not support enumeration upon receiving a HUP signal. Ian, what do you think? Not really, due to possible active multi-mounts. The multi-mounts entries are the reason we have to wait until the mount isn't busy. Ok, checking again here. You mean the case that one of the mountentries, part of the multi-mount map is used (is: mounted) makes that the whole map is not refreshed. Thanks for your reaction, Stef Bon ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
[autofs] make an executable map rerun.
Hello, I've been working on a solution to make networkresources available via autofs on a dynamic way. After login with help from ConsoleKit a mountpoint is added to the master file of the automounter. This mountpoint is in the homedirectory of the user logging in. This way I've a browseable network map in my home directory for Windows Networks (via cifs), FTP (via curlftpfs/FUSE) and SSH (with sshfs/FUSE). Others, like Novell should be possible. It works with executable maps. Now for some reasons I would like some control over rerrunning the executable map, to make the automounter refresh the autofs data. Now I do not see how to do that. I reload signal does not do that. Is there a way to do this? Stef Bon ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] make an executable map rerun.
Jeff Moyer wrote: Stef Bon s...@bononline.nl writes: Hello, I've been working on a solution to make networkresources available via autofs on a dynamic way. After login with help from ConsoleKit a mountpoint is added to the master file of the automounter. This mountpoint is in the homedirectory of the user logging in. This way I've a browseable network map in my home directory for Windows Networks (via cifs), FTP (via curlftpfs/FUSE) and SSH (with sshfs/FUSE). Others, like Novell should be possible. This sounds like interesting work. Do you have it posted somewhere? Yes, look at: http://linux.bononline.nl/linux/automountsmbshares/index.php It works with executable maps. Now for some reasons I would like some control over rerrunning the executable map, to make the automounter refresh the autofs data. Now I do not see how to do that. I reload signal does not do that. Is there a way to do this? No caching is done for program maps. They are consulted for every single lookup, so you shouldn't have to do anything special. Is this not the behaviour you are observing? No, after activating the executable map once, the data provided by the executable map is kept. I've tested this by letting the executable map write to an logfile, and it's running seldom. I can look at the contents of /proc/mounts and here I see the autofs tree, which is kept. So I do not understand your remark saying it is consulted every single lookup. Does the option -browse mather here? I'm using that and because this forces the automounter to remember the data right? Stef Cheers, Jeff ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] make an executable map rerun.
Jeff Moyer wrote: I can look at the contents of /proc/mounts and here I see the autofs tree, which is kept. So I do not understand your remark saying it is consulted every single lookup. Does the option -browse mather here? I'm using that and because this forces the automounter to remember the data right? OK, I was wrong. Sorry about that (I was confused with the fact that program maps don't support the -browse option, since they can't support map enumeration). I admit I am not up to speed on v5. However, it looks to me like a HUP signal will not cause the service thread for your mount point to restart unless the actual program map changed. This means the cache will still be in tact, as you observed. I suspect we should probably clear the cache for any maptype that does not support enumeration upon receiving a HUP signal. Ian, what do you think? Cheers, Jeff Ok, question: how does the automounter determine that the acual program map has changed? Futher, it may be a good thing to develop an utility which manages mountpoints and related maps. (like autofsctl) One of the things is to make executable maps run again and let the automounter read the data. Reloading the configuration is another task. Stef ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] Modified auto.smb script
On Monday 27 October 2008 15:00:20 Ian Kent wrote: On Fri, 2008-10-24 at 16:46 +0200, Stef Bon wrote: Hi, I've sent this email before. Can you confirm it's arrived? Yeah, I've received your mail. What do you want me to do with the script? Well, the script does (in my network) work with cifs shares, where the original auto.smb doesn't. In my case I have to add the ipaddress or it does not work. The manpage of mount.cifs says that this option has to be used rarely. But it's my experience sometimes when mounting a Win2K or WinXP machine, it does not work. (CIFS expects the tcp name and not the netbiosname, smbfs did that) So I cannot say it's a really must, but at least it cannot hurt. You're on the safe side when using the ipaddress. Well I should add this script to the package autofs, replacing the auto.smb, if you want my opinion. Smbfs is not supported anymore in the latest kernels. Stef ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] Proposed update to auto.smb
On Monday 03 November 2008 15:16:33 Jeff Moyer wrote:
Ian Kent [EMAIL PROTECTED] writes:
On Mon, 2008-11-03 at 11:32 +0900, Ian Kent wrote:
Hi all,
Stef Bon has reported some difficulty with the current auto.smb.
-opts=-fstype=cifs
+
+FILESYSTEM=cifs
+
So, umm, when is $FILESYSTEM not going to be cifs?
That's a good one. I thought it's a good thing to still support
smbfs, which is not cifs obviously.
+if [ $FILESYSTEM != cifs ]; then
+ opts=-fstype=$FILESYSTEM,guest
+else
+ for P in /bin /sbin /usr/bin /usr/sbin
+ do
+ if [ -x $P/nmblookup ]; then
+ NMBLOOKUP=$P/nmblookup
+ break
+ fi
+ done
+
+ if [ ! -x $NMBLOOKUP ]; then
+ exit 1
+ fi
Is it possible to not have the nmblookup program? It seems to me it
would be safer to at least try the mount w/o the ip address if you can't
obtain one.
Yes, that's also good choice. Now the script fails when nmblookup is not
found, which is not always necessary.
+
+ ipaddress=$($NMBLOOKUP $key --debug-level=0 2/dev/null | grep '00'
| awk '{ print $1 }') + if [ -z $ipaddress ]; then
+ exit 1
+ fi
+
+ opts=-fstype=cifs,guest,ip=$ipaddress
+fi
for P in /bin /sbin /usr/bin /usr/sbin
do
Can we compress these two loops that do the same thing (determine the
path to the samba/cifs binaries)?
Yes possibly. But the loop to find nmblookup is only done when using cifs (see
above..). Also, when combined, the loop should not stop when only one is
found, but both. But yes it's possible to create one loop with some if and
thens.
Stef
___
autofs mailing list
autofs@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/autofs
[autofs] Modified auto.smb script
Hi, I've sent this email before. Can you confirm it's arrived? Stef Hello, I've modified the auto.smb script to make use of cifs in stead of smbfs. In my network mounting a SMB share with cifs fails, unless the ipaddress is an option:ip=$ipaddress. It uses the tool nmblookup for that. Futher I'm working on an howto which describes the various ways to mount SMB shares. Stef Bon the Netherlands auto.smb Description: application/shellscript ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
[autofs] Script to mount the whole SMB network.
Hello, I've posted earlier here, about the autofs managed network maps. I'm using the new autofs version. With this version it's possible to use multi mount maps. The script here uses the name of the network as key, here only the Windows Network is supported. copy the auto.network script to /etc/autofs make it executable if not already mkdir -p /mnt/network Add this to the auto.master file: /mnt/network /etc/autofs/auto.network -browse So when I want to enter the Windows Network, I type: ls -A /mnt/network/Windows Network You'll get the complete windows environment and you can access the shares. It acts as guest, but when a credential file is provided, it will use that one for authentification. It takes some time to complete, it uses lookups by nmblookup. If your network is bigger, it takes more time. It uses CIFS, and will check it is supported. You can make it use SMBFS, change the parameter FILESYSTEM Futher this script only creates a map for the Windows Network. On my system the script can also handle FTP and SSH (with the help of Fuse) See for more info: http://linux.bononline.nl/linux/automountsmbshares/automountsmbshares-page01a.php The it's possible to do: ls /mnt/network/FTP hosts and ls /mnt/network/SSH Greetings, Stef Bon the Netherlands auto.network Description: application/shellscript ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
[autofs] Cannot access the webpages of the archives.
Hello, I'm checking the pages of the linux autofs maillist, but I get a message I do not have permissions: Forbidden You don't have permission to access /pipermail/autofs/2008-June/004801.html on this server. Apache/2.2.8 (Fedora) Server at linux.kernel.org Port 80 Others having the same problem? Stef Bon the Netherlands, the country below sealevel. ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] Script to mount the whole SMB network.
On Wednesday 30 July 2008 10:59:51 Stef Bon wrote: Hello, copy the auto.network script to /etc/autofs make it executable if not already Oops, it had a small bug. Attached is the corrected version. Stef Bon auto.network Description: application/shellscript ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] Suggestion for better manpage.
On Tuesday 17 June 2008 16:44:09 Jeff Moyer wrote: Ian Kent [EMAIL PROTECTED] writes: On Tue, 2008-06-17 at 12:57 +0200, Stef Bon wrote: Hello, reading the manpage of automount, I would like to change the section in the manpage about how the daemon reacts on signals. Send a patch. Try this on for size. Cheers, OK, you've already done this. Very clever. Stef ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
[autofs] Suggestion for better manpage.
Hello, reading the manpage of automount, I would like to change the section in the manpage about how the daemon reacts on signals. It is now: If the automount daemon catches a USR1 signal, it will umount all currently unused autofs managed mounted file systems and continue running (forced expire). If it catches the TERM signal it will umount all unused autofs managed mounted file systems and exit if there are no remaining busy file systems. If autofs has been compiled with the option to ignore busy mounts on exit it will exit leaving any busy mounts in place other- wise busy file systems will not be umounted and autofs will not exit. Alternatively, if autofs has been compiled with the option to enable forced shutdown then a USR2 signal to the daemon will cause all mounts to be umounted and any busy mounts to be forcibly umounted, including autofs mount point directories (summary execution). Note that the forced umount is an unlink operation and the actual umount will not happen in the kernel un- til active file handles are released. The daemon also responds to a HUP signal which triggers an update of the maps for each mount point. If any autofs mount point directories are busy when the daemon is sent an exit signal the daemon will not exit. The exception to this is if autofs has been built with configure options to either ignore busy mounts at exit or force umount at exit. If the ignore busy mounts at exit option is used the filesystems will be left in a catatonic (non-functional) state and can be manually umounted when they become unused. If the force umount at exit option is used the filesystems will be umounted but the mount will not be released by the kernel until they are no longer in use by the processes that held them busy. If automount managed filesystems are found mounted when autofs is started they will be recoverd unless they are no longer present in the map in which case they need to umounted manually. I would like to suggest: The automount daemon can react on a few signals. Some of them are standard, others are less standard and/or need compiletime options. TERM If it catches the TERM signal it will umount all unused autofs managed mounted filesystems, and exit if there are no remaining mounts left. It will keep on running (till??) If compiled with the ignore busy mounts option, it will exit here, and leave any mountpoint in place. USR2 This only applies when the automounter is compiled with the enable forced shudown. When it catches the USR2, it will umount all mounts, busy or not. Note: umounting a busy mountpoint is actually an unlink operation. The actual umount will be done later, when all active file handleds are released. (this id done by??) USR1 With the USR1 signal it will umount all currently unused mounts, and continue running (forced expire). HUP This signal triggers an update of the maps for each mountpoint. I've left out some parts, but mostly rearranged the information. I've left out the text summary execution Is it important? But what do you think. Is it better this way? Stef Bon ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
[autofs] Very good the patches.
Hello, thanks for the patches. I experienced some problems with my construction on autofs managed network maps: - still problems on not wanting to run when auto.master file is empty, and the included /var/run/autofs.auto.master is not found - unmounting everything when sutting down with the signal USR2 (and compiled with the enable-forcesd-shutdown) does not what it's supposed to do - when I've got two networks, I've got two toplevel directories on my mountpoint. When both are expired and there are no mounts, one will disappear. This is not what I want. The best for my construction is that the toplevel directories (for example Windows Network and SSH hosts) will remain. Well anyway, I'll try the patches. Can I actually apply them? I've been looking in the source, and the latest patch is from may... Stef Bon ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] Some reload problems.
Ian Kent wrote: May 6 11:32:15 localhost automount[5773]: autofs stopped So this is what happens. So, autofs just exits. The problem is that autofs needs to know when to exit and that amounts to checking if any active mounts are left. But that check breaks down because we need to avoid it unless we've actually been asked to shutdown and, at the moment, this isn't known to the function that does the check. The condition is checked every time a mount point shuts down. I think I can fix this fairly easily but, for it to be a simple fix, we will need a patch I'm working on to be merged first. So you're stuck, for a while anyway. Well I'm not really stuck. The way I've solved it is to add another mountpoint to /etc/autofs/auto.master which remains there. Then there is no problem. And I can wait. Thank you for looking to this problem. With all these steps I hope I can create a contruction which allows a more powerfull access to network resources than there exist today. Stef Bon ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] Some reload problems.
Ian Kent wrote: On Mon, 2008-05-05 at 16:13 +0200, Stef Bon wrote: It's also ok when a line is added. But there are some problems when stopping. When stopping a session (by logging out), the line in /var/run/autofs/auto.master is removed and the daemon gets a reload. Now, when there are no other lines here, and there also no other mountpoints in the main mastermap, the daemon stops. You'll need to provide a debug log as well as the explanation, ensure you are capturing all the output to syslog. OK, I've added the debug option. Now I show you what happens. First at boottime the automount daemon is started, with an empty masterfile: May 6 10:54:46 localhost automount[5773]: Starting automounter version 5.0.3, master map /etc/autofs/auto.master May 6 10:54:46 localhost automount[5773]: using kernel protocol version 5.00 May 6 10:54:46 localhost automount[5773]: lookup_nss_read_master: reading master file /etc/autofs/auto.master May 6 10:54:46 localhost automount[5773]: parse_init: parse(sun): init gathered global options: (null) May 6 10:54:46 localhost automount[5773]: lookup_read_master: lookup(file): read entry +/var/run/autofs/auto.master May 6 10:54:46 localhost automount[5773]: lookup_nss_read_master: reading master file /var/run/autofs/auto.master May 6 10:54:46 localhost automount[5773]: parse_init: parse(sun): init gathered global options: (null) May 6 10:54:46 localhost automount[5773]: no mounts in table May 6 10:54:46 localhost bootlog: Starting automount... [ OK ] Ok it detects the master file is empty, but it keeps on running. I can test it with: [root ~]# /etc/rc.d/init.d/autofs status automount is running with pid 5773 and map /etc/autofs/auto.master Then, when a session starts, an entry is added to the /var/run/autofs/auto.master file: KDM runs a script after login of sbon: /etc/session.d/scripts/start/add_network_mountpoint.sh sbon This command adds a line to the /var/run/autofs/auto.master file and gives the running daemon a reload signal: [root ~]# cat /var/run/autofs/auto.master /home/sbon/Global\ Network /etc/autofs/session/auto.network.sbon -browse And the logfile gives: May 6 11:02:40 localhost bootlog: Reloading automount with map /etc/autofs/auto.master.[ OK ] May 6 11:02:40 localhost automount[5773]: re-reading master map /etc/autofs/auto.master May 6 11:02:40 localhost automount[5773]: lookup_nss_read_master: reading master file /etc/autofs/auto.master May 6 11:02:40 localhost automount[5773]: parse_init: parse(sun): init gathered global options: (null) May 6 11:02:40 localhost automount[5773]: lookup_read_master: lookup(file): read entry +/var/run/autofs/auto.master May 6 11:02:40 localhost automount[5773]: lookup_nss_read_master: reading master file /var/run/autofs/auto.master May 6 11:02:40 localhost automount[5773]: parse_init: parse(sun): init gathered global options: (null) May 6 11:02:40 localhost automount[5773]: lookup_read_master: lookup(file): read entry /home/sbon/Global\ Network May 6 11:02:40 localhost automount[5773]: master_do_mount: mounting /home/sbon/Global Network May 6 11:02:40 localhost automount[5773]: automount_path_to_fifo: fifo name /var/run/autofs.fifo-home-sbon-Global Network May 6 11:02:40 localhost automount[5773]: lookup_nss_read_map: reading map file /etc/autofs/session/auto.network.sbon May 6 11:02:40 localhost automount[5773]: parse_init: parse(sun): init gathered global options: (null) May 6 11:02:40 localhost automount[5773]: mounted indirect mount on /home/sbon/Global Network with timeout 300, freq 75 seconds May 6 11:02:40 localhost automount[5773]: ghosting enabled Now checking the contents of /proc/mounts: [root ~]# cat /proc/mounts .. .. .. /etc/autofs/session/auto.network.sbon /home/sbon/Global\040Network autofs rw,fd=5,pgrp=5773,timeout=300,minproto=5,maxproto=5,indirect 0 0 This is the only autofs related line here. The networkservices are not yet visible to sbon: [root ~]# ls -A /home/sbon/Global\ Network (no output here) so there is another script which activates the networks (it needs to be run with permissions of the user logging in: [sbon ~]$ /opt/kde-4.0/env/50activate_networks.sh : Activating network Windows Network : Activating network SSH hosts Now the log file: May 6 11:13:42 localhost automount[5773]: expire_cleanup: got thid 3083566000 path /home/sbon/Global Network stat 0 May 6 11:13:42 localhost automount[5773]: expire_cleanup: sigchld: exp 3083566000 finished, switching from 2 to 1 May 6 11:13:42 localhost automount[5773]: st_ready: st_ready(): state = 2 path /home/sbon/Global Network May 6 11:14:46 localhost : Activating network Windows Network. May 6 11:14:46 localhost automount[5773]: handle_packet: type = 3 May 6 11:14:46 localhost automount[5773]: handle_packet_missing_indirect: token 16, name Windows Network, request pid 6924 May 6 11:14:46 localhost automount[5773]: attempting to mount entry /home
[autofs] Some reload problems.
Hello, I'm working on a construction which makes it able for ordinary users to browse (and mount) the network over different services like SSH and SMB. It creates a networkmap in the homedirectory: /home/sbon/Global Network for example. Now this contruction creates and uses a temporarly master map in /var/run/autofs: /var/run/autofs.master which in my single user case looks like: /home/sbon/Global\ Network /etc/autofs/session/auto.network.sbon -browse The map is in /var/run, because it only contains runtime data. The line is added by a script run by KDM, when my session starts. (and removed by another script run by KDM, when a sessions ends) Now I'v added this networkrelated/usersession auto.master to the main auto.master: # # other mountpoints and maps here # +/var/run/autofs/auto.master Now, there is an (I think reasonable) assumption: - when the automount daemon is not started at boottime, the creation of the networkfolders should not be done (this construction does not start it, it should already be running) - the daemon will start and continu running with an empty master map - a reload hasn't much consequences for existing trees. But what is necessary, is that after any change in the /var/run/autofs/auto.master file, the daemon should get a reload. Now my experience is that the first issue is ok. There is even a patch for it. (I'm using version 5.0.3) The daemon starts, even with an empty auto.master file (and an empty /var/run/autofs/auto.master). It's also ok when a line is added. But there are some problems when stopping. When stopping a session (by logging out), the line in /var/run/autofs/auto.master is removed and the daemon gets a reload. Now, when there are no other lines here, and there also no other mountpoints in the main mastermap, the daemon stops. To avoid this problem, I've added valid mountpoint to the main mastermap, and this problem did not occur anymore. But, what remained is that the top level directory of a unused browseable network tree was removed after a reload. I have to avtivate it again. Let me explain: my construction supports two services at this moment: SSH and SMB. When I login, both are activated by a litlle script which does: ls -A /home/sbon/Global Network/Windows Network and ls -A /home/sbon/Global Network/SSH hosts Now I can browse the network. (I've discussed this earlier..) The /var/run/autofs/auto.master file has two lines, one for me and one for root. There are smb shares for me (sbon) mounted, so there are active mounts. No ssh host is mounted for sbon. When root is logging out, the line with for root is removed, and the daemon gets a reload. The result is that the Windows Network does still exist in /home/sbon/Global Network, but SSH hosts not anymore, which should not be the case. I hope you're able to understand the situation. Stef Bon ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] Some reload problems.
Stef Bon wrote: Now, there is an (I think reasonable) assumption: - when the automount daemon is not started at boottime, the creation of the networkfolders should not be done (this construction does not start it, it should already be running) - the daemon will start and continu running with an empty master map - a reload hasn't much consequences for existing trees. But what is necessary, is that after any change in the /var/run/autofs/auto.master file, the daemon should get a reload. Now my experience is that the first issue is ok. There is even a patch for it. (I'm using version 5.0.3) Sorry, I meant the second issue. The first is an assumption. SB ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] Question about timeout option.
Ian Kent wrote: On Sun, 2008-04-27 at 16:14 +0200, Stef Bon wrote: Hello, 22 april I posted a message with the question about the timeout option. Has anybody read it, and possibly have a clue? I read it. Try using -browse or browse (not --browse). Yes, thanks that did it! Somehow the option browse did not get through to the daemon. In my autofs configuration it was set to no, and the option in the master file was ignored. Now I've set it to yes in the configuration file, and everything is ok. I'm still looking why this happened. It might prevent the top directories from being removed after expire (and when you access these it will re-create the sub-directories each time so that will be OK) but it wont be able to create the directories initially because it's a program map and autofs doesn't have a way to ask it for a list of it's keys. I haven't really had any suggestions that I think are workable for doing this. No, I understand. It's not possible to let the automount discover these keys, without knowledge of the map. Stef Bon ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
[autofs] include a master file: where does the automounter look
Hello, when I read the manpage for auto.master (and other docs) I see that I can include another master file by doing: +auto.master The comment says that by doing so, the you can specify a master map which is found using nsswitch sources. What happens then? Where does it look then? When I add a line with an auto.master file with full path: +/var/run/autofs/auto.master it works also. Stef ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] include a master file: where does the automounter look
Ian Kent wrote: On Mon, 2008-04-28 at 16:53 +0800, Ian Kent wrote: On Mon, 2008-04-28 at 10:32 +0200, Stef Bon wrote: Hello, when I read the manpage for auto.master (and other docs) I see that I can include another master file by doing: +auto.master The comment says that by doing so, the you can specify a master map which is found using nsswitch sources. What happens then? Where does it look then? If you have a line in /etc/nsswitch.conf like: automount: files nis it will look in /etc for auto.master (files) and try to connect to a nis server and ask for auto.master. There's actually a bit more to it than that because of the possibility of different actions, such as continuing or returning when a source is found or not. Thanks a lot for the info. Stef Bon BTW I'm working on documentating the construction I'm using right now. It's not ready, but when I'm happy, I will also redo the already existing documentation on howtoforge. Look at: http://linux.bononline.nl/linux/automountsmbshares/automountsmbshares-page01a.php ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
[autofs] Add mountpoints to mastermap dynamically.
Hello, again a question. The construction I'm working on does add a mountpoint dynamically to an existing map. After added (first some checking the mountpoint is not already included) a reload is done with the running automount (HUP signal). The same after removing a mountpoint. It works very good, but I'm wondering, is this the way to do this?? Isn't there a autofsctl program??? Stef Bon ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] include a master file: where does the automounter look
Ian Kent wrote: On Mon, 2008-04-28 at 10:32 +0200, Stef Bon wrote: Hello, when I read the manpage for auto.master (and other docs) I see that I can include another master file by doing: +auto.master The comment says that by doing so, the you can specify a master map which is found using nsswitch sources. What happens then? Where does it look then? If you have a line in /etc/nsswitch.conf like: automount: files nis it will look in /etc for auto.master (files) and try to connect to a nis server and ask for auto.master. Ok, it will search for the files first and after that the nis thing. But here: this line which instructed the automounter to look in the nsswitch.conf file is in a auto.master file, and then you instruct it to look for the same file again. This does not make sense to me... Stef Bon ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] Add mountpoints to mastermap dynamically.
Jeff Moyer wrote: Stef Bon [EMAIL PROTECTED] writes: Hello, again a question. The construction I'm working on does add a mountpoint dynamically to an existing map. The subject says you're adding a new entry to the master map. This sentence sounds like you're adding an entry to an existing map. The second should be caught automatically by the daemon, so no need to reload. Ok, I mean the first: adding a new entry to the master map. After added (first some checking the mountpoint is not already included) a reload is done with the running automount (HUP signal). The same after removing a mountpoint. It works very good, but I'm wondering, is this the way to do this?? Isn't there a autofsctl program??? You could do, 'service autofs reload' instead. Or maybe you should investigate direct maps. I'm not sure, since I know very little of your setup. Yes, but my system does not know a service command. (LFS/BLFS). I think this command service is typical Red Hat isn't it? I have to give the init script the command reload directly: /etc/rc.d/init.d/autofs reload It has the same effect. Stef Bon ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
[autofs] Question about timeout option.
Hello, 22 april I posted a message with the question about the timeout option. Has anybody read it, and possibly have a clue? Basically explained: I'm using a multiple mounts map to mount the smb shares and the ssh hosts. The key here is the name of the network. In the case of smb it's Windows Network, with ssh it's SSH hosts. The autoscript mapped to the mountpoint produces with this key a map like: /etc/autofs/session/auto.network.sbon Windows Network -fstype=cifs,credentials=/home/sbon/.autofssession/smb/mount.cred \ /BONONLINE/LFS20060812/bononline -rw,ip=192.168.0.2 ://LFS20060812/bononline \ /BONONLINE/LFS20060812/ftp -rw,ip=192.168.0.2 ://LFS20060812/ftp \ /BONONLINE/LFS20060812/sbon -rw,ip=192.168.0.2 ://LFS20060812/sbon \ /BONONLINE/LFS20060812/video -rw,ip=192.168.0.2 ://LFS20060812/video \ /CWWERKGROEP/ROUTER/ftp -rw,ip=192.168.0.1 ://ROUTER/ftp \ /CWWERKGROEP/ROUTER/public -rw,ip=192.168.0.1 ://ROUTER/public \ /CWWERKGROEP/ROUTER/sbon -rw,ip=192.168.0.1 ://ROUTER/sbon If the key is SSH hosts it't output is: /etc/autofs/session/auto.network.sbon SSH hosts -fstype=sshfs \ /192.168.0.3 -rw,nodev,nonempty,noatime ://[EMAIL PROTECTED]:/ \ /192.168.0.1 -rw,nodev,nonempty,noatime ://[EMAIL PROTECTED]:/ \ /192.168.0.15 -rw,nodev,nonempty,noatime ://[EMAIL PROTECTED]:/ \ /195.243.111.226 -rw,nodev,nonempty,noatime ://[EMAIL PROTECTED]:/ \ /192.168.0.10 -rw,nodev,nonempty,noatime ://[EMAIL PROTECTED]:/ \ /192.168.0.2 -rw,nodev,nonempty,noatime ://[EMAIL PROTECTED]:/ When starting the automounter I have to activate these maps by doing a initial ls %MOUNTPOINT%/Windows Network and ls %MOUNTPOINT%/SSH hosts Now I can browse the tree which is created. But when I leave it for a while, this tree will disappear. I have to do the ls commands like above again. Now a can avoid this behaviour by diabling the timeout by adding the --timeout 0 option in the master file. But this has some disadvantages: - mounted shares/hosts are not unmounted anymore when not used for a period set by the timeout option - the current map stays in memory. This means that changes in the underlying network (a host is added for example) will not get their way into this map. So, to stay with the first problem, has someone an idea how to solve this timeout of the map. How can I make the automounter not forget the map, but unmount shares that not used anymore? Thanks in advance, Stef Bon ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
[autofs] Indirect mounts: name of network as key.
Hello, since some time I'm working on a sollution to provide access to the network with autofs. My construction adds an entry to the auto.master file: /home/sbon/Global\ Network/etc/autofs/session/auto.network.sbon --browse The auto.network.sbon file is a symlink to auto.network. The directory Global Network is owned by root. The script auto.network.sbon creates a map depending the key. The key is the name of the network. When the key is for example Windows Network, it's output is: -fstype=cifs,credentials=/home/sbon/.autofssession/smb/mount.cred \ /BONONLINE/LFS20060812/bononline -rw,ip=192.168.0.2 ://LFS20060812/bononline \ /BONONLINE/LFS20060812/ftp -rw,ip=192.168.0.2 ://LFS20060812/ftp \ /BONONLINE/LFS20060812/sbon -rw,ip=192.168.0.2 ://LFS20060812/sbon \ /BONONLINE/LFS20060812/video -rw,ip=192.168.0.2 ://LFS20060812/video \ /CWWERKGROEP/ROUTER/public -rw,ip=192.168.0.1 ://ROUTER/public \ /CWWERKGROEP/ROUTER/sbon -rw,ip=192.168.0.1 ://ROUTER/sbon When the key is SSH hosts, it's output is: -fstype=sshfs \ /192.168.0.1 -rw,nodev,nonempty,noatime ://[EMAIL PROTECTED]:/ \ /192.168.0.2 -rw,nodev,nonempty,noatime ://[EMAIL PROTECTED]:/ \ (the mount.sshfs is a script which calls the sshfs fuse program with the right parameters) ( the script auto.network determines these maps dynamically..) Now when a session for a user starts, the line for this (/home/sbon/Global\ Network /etc/autofs/se...) is added to the auto.master file. If the automount daemon is not running, it is started here, else the running automounter gets a reload. This construction gives a very good way to access the network. It comes very near to what I'm looking for. It provides easy access to various network services. At the same time, because of the use of cifs for smb networks, advanced features are supported. The only problem to activate the map, and to keep is up. Normally when I do something like: : cd /home/sbon/Global Network : ls (gives no output, I have to do:) : ls Windows Network BONONLINE CWWERKGROEP (now I've got a browseable map, where the shares are only mounted when accessed, what is good! Simular:) : ls SSH hosts 192.168.0.1 192.168.0.2 I solve this by doing a ls %Network Name% for all the networks available to an user. Well a script does that. There is only one thing where this construction goes wrong, and that is that the automounter sometimes forgets the whole tree, for example the Windows Network tree. Than I see only the tree SSH hosts. This has something to do with the timeout option. This option applys to the active mounts (cifs and sshfs here), but as far I can see also to the whole browseable tree. Now it's obvious, when setting this value here to zero, and thus disabling this behaviour, solves the problem. It leaves the whole browseable tree intact. But now the cifs and sshfs shares are not unmounted anymore, when they are unused for some time... This is not so good, because this is one of the pros of the automounter. Is there a way to make the timeout option only apply to the actual external mounts, and leave the browseable tree? Thanks in advance, Stef Bon ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] Indirect mounts: name of network as key.
Stef Bon wrote: Hello, When the key is SSH hosts, it's output is: -fstype=sshfs \ /192.168.0.1 -rw,nodev,nonempty,noatime ://[EMAIL PROTECTED]:/ \ /192.168.0.2 -rw,nodev,nonempty,noatime ://[EMAIL PROTECTED]:/ \ Some program is replacing the literal \@ by an at on the website, not the mail. I hope this comes through all right: -fstype=sshfs \ /192.168.0.1 -rw,nodev,nonempty,noatime ://[EMAIL PROTECTED]:/ \ /192.168.0.2 -rw,nodev,nonempty,noatime ://[EMAIL PROTECTED]:/ \ Stef Bon ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
[autofs] Testing the UID var.
Hello,
the latest weeks I've been testing with the paramters UID, USER etc.
provided by the automounter,
indicating the user activating the mount. I've changed the default
auto.smb script to make use of this var:
(earlier I had another constructing which was not so comprehensive)
-
#!/bin/bash
key=$1
opts='-fstype=smbtest,auid=$UID'
SMBCLIENT=/usr/bin/smbclient
[ -x $SMBCLIENT ] || exit 1
# echo $key
$SMBCLIENT -gNL $key 2/dev/null| awk -v key=$key -v opts=$opts
-F'|' -- '
BEGIN { ORS=; first=1 }
/Disk/ { if (first) { print opts; first=0 }; sub(/ /, \\ ,
$2); print \\\n\t / $2, :// key / $2 }
END { if (!first) print \n; else exit 1 }
'
Note:
a. I've made this script I little bit simpler by letting it not search
the smbclient script.
b. the fstype is not smb but smbtest. I've created a wrapper
mount.smbtest which will filter the parameter
auid out. This value can be used for permissions and authentification
c. the extra opion auid (activating user) which will be assigned when
the automounter does the mount, not when running this script. That's why
there are single quotes around it.
Futher I use this wrapper mount.smbtest, which is a little bit too big
to show here. In pseudo code:
-
#!/bin/sh
# log the parameters, important to see how this script is called
# and what the value of auid is
set | grep ^BASH_ARGV /var/log/mount.smbtest.log
seperate the value auid from the rest of the paramaters
if this auid is not empty, and does exist (an existing user on the system)
check there are credentials for this user
if so then perform a mount.smb with the credentials, with all the right
options (mountpoint, unc_address and other options)
else do a guest mount ( with the right options)
--
When looking to the logfile, sometimes the auid is correct, but in about
50% of the cases it's empty.
If you would like to test with this I can provide this mount.smbtest script.
Stef Bon
___
autofs mailing list
autofs@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] More directories?
Ian Kent wrote: Return everything else but the key as usual. Format like: [-fstype=type,options] [[/] [localtion] \ /dir location \ /dir location The leading / is required and the root mount / is optional. It's been a while since I played with this but I think the offsets of the multi-mount need to be in depth order. Ian Ok, this format you give returns a list. This list is interpreted by the automount daemon, and it determines which entry applies. Now it should be possible to let this script (it has to be a script) only show the entry which applies: -fstype=cifs,credentials=/home/sbon/.smb/mount.cred / \ /sbon/lfs20060812/public ://lfs20060812/public if I give the command: ls autofsmountpoint/sbon/lfs20060812/public This way the script is more smart. Stef Bon ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] More directories?
Ian Kent wrote: Its totally dependent on what is returned from the script. The example script, auto.smb, just returns an entry with a multi-mount offset for each share. If a more complex multi-mount is returned that should work fine. The old auto.hosts would often return a more complex multi-mount entry as NFS exports are often deeper than a single level. Ian Ok, That's clear. I know that's it's the script which should return it. What I want to know is, is it possible to use mountpoint's like: ../USER/server/share/mounted smb share A multimount with the first key the USER. Stef Bon ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] bind mounting into a generated multi-level directory structure
Chris Stromsoe wrote: My eventual solution was to use multi-mount to bind mount a shared directory with libraries and other common data to a simple generated path as a container, and then bind mount the hashed directory inside of that volume. I'm using the container volume as a chroot environment to run untrusted code (php) on a web server, and wanted to minimize exposure to the rest of the machine as much as possible. Ok, it's more clear to me now. I'm wondering, isn't it possible to create a custom chroot command, which will of course do the chroot, but also do the necessary binds. I've been working on a login shell (chroot_union) which is the standard shell of a user. When this user logs in (starts a session) a copy of the system is created with unionfs. Then a chroot is done, and a perfect environment where the user can do anything is there. Isn't that possible? Stef Bon ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] bind mounting into a generated multi-level directory structure
chris barry wrote: On Sun, 2008-02-10 at 15:18 +0100, Stef Bon wrote: Chris Stromsoe wrote: I have a set of directories that are created and removed programmatically, and are hashed three levels deep (/top/hash/hash/name). The depth is constant, the hashes and names are not. There are around 35k at any time. I would like to bind mount a common directory into each top-level (/top/hash/hash/name/data) on demand. Can I use autofs to do that without having to explicitly list all of the directory paths in auto.master? Why not use symlinks to this shared common directory, and mount that one? Stef Bon His goal is to create a chroot'd environment, and the symlink cannot function there. Good to mention. I did not understand it's about a chrooted environment. The earlier emails do not say anything at all about that. Stef ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] User token activating the mount.
Stef Bon wrote: So good news! With this extra field indicating the user which is activating the mount, it is possible to do an extra security check. An mount on behalf of an user can only be activated by himself. And everybody can do a guest mount. Hi Stef, this is very good! The automounter is a very powerfull tool, and this power can be abused. It does not check who's activating the mount, and I can imagine that this anybody can mount situation is very insecure. The automounter - running under the account root - can do anything. Check credentials for example which are normally hidden to the user activating the mount, and perform a mount with these credentials. So a check on the userid and only performing the action this user is allowed to is a good idea! I will check this out. Stef ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
[autofs] User token activating the mount.
Hello, some time I've been experimenting with the automounter to mount smb shares for ordinary users. I've got autofs-5.0.3 installed with patches for my linux-2.6.23.11 kernel. My auto.master looks like: /mnt/autofs/network/etc/auto.network and /etc/auto.network is: * -fstype=network :/%$USER I've read that in construction of the key some variables are possible. So this auto.network adds the username to the key, seperated with a %. Now with this construction the mount wrapper mount.network is called. Basically it analyses the key and constructs the real unc_address out of it. My construction uses mountpoints like: /home/sbon/Global Network/Windows Network/WORKGROUP/SERVER/firstshare - /mnt/autofs/network/smb:[EMAIL PROTECTED]@WORKGROUP%firstshare Note this is a single directory, containing several fields: - smb is the protocol - u_sbon is the indicator that the mount should be done as the normal user sbon - SERVER and WORKGROUP speak for themselves - firstshare is the share on SERVER Now, the mount.network wrapper contruct out of this: mount.cifs //SERVER/firstshare /mnt/autofs/network/smb:[EMAIL PROTECTED]@WORKGROUP%firstshare -o credentials=/home/sbon/.autofssession/smb/mount.cred I can add an extra command to log the environment with: set /var/log/mount.network.log I do not do this because I hope the environment variable USER will be the user which activated the automounter, but I can look at the arguments the script mount.network gets. And look: cat /var/log/mount.network.log | grep ^BASH_ARGV and look at the last added line1, and then to the argument corresponding with the key ( or extern address): a %root is added to this key when I do a ls (as root): ls -al /mnt/autofs/network/smb:[EMAIL PROTECTED]@WORKGROUP%public the automounter has added the user (which is now root) to the key: [3]=/smb:[EMAIL PROTECTED]@WORKGROUP%public%root Now this happens also, when I do this as myself (sbon). The only thing is that it does not always does this. Sometimes this field is empty. I'm still testing. So good news! With this extra field indicating the user which is activating the mount, it is possible to do an extra security check. An mount on behalf of an user can only be activated by himself. And everybody can do a guest mount. Stef Bon ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] bind mounting into a generated multi-level directory structure
Chris Stromsoe wrote: I have a set of directories that are created and removed programmatically, and are hashed three levels deep (/top/hash/hash/name). The depth is constant, the hashes and names are not. There are around 35k at any time. I would like to bind mount a common directory into each top-level (/top/hash/hash/name/data) on demand. Can I use autofs to do that without having to explicitly list all of the directory paths in auto.master? Why not use symlinks to this shared common directory, and mount that one? Stef Bon ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] Looking for a per user submount...
Ian Kent wrote: On Mon, 2008-01-28 at 11:11 +0100, Francesco P. Lovergine wrote: I was looking for some sort of automounting for per-user subtrees. Essentially I need to bind-mount on demand some per user (users are sql-based) subdir like /path/user/mount_point, where /path/user is a true dir. I'm missing something or it cannot be performed using autofs without adding each entry explicitly for every users ? Try something like. In the master map: /topdir /etc/auto.users In auto.users: * :/path/ Clearly, the automount entries for future mounts aren't known until they are triggered, so they can't be seen no matter what options you use. Ian I've been working on a construction to achieve mounts on a per-user basis. It's based on a few things: - a tree in the homedirectory of the logged in user, representing the Windows network. The shares are symlinks pointing to the automount path: /mnt/autofs/network/: /home/sbon/Global Network/Windows Network/BONONLINE/LFS20060812/public - /mnt/autofs/network/smb:[EMAIL PROTECTED]@BONONLINE%public Now this autofs directory/key (/smb::[EMAIL PROTECTED]@BONONLINE%public) does have all the information in it necessary to do a cifs mount. I can do this because the automounter does not understand the smb protocol. It just passes the parameters to the mount program. Earlier I've been working with a construction where the automounter had to be started for every user. This new construction does not need this. Futher this Windows Network representation is build by scripts which discover the network periodically. - my auto file looks like: * -fstype=network :/ Very short and simple! Earlier I've been working with submounts ( Ian do you remember this?) Look at the filesystem network. It does not exist, but I've created a mount.network wrapper: - a mount.network wrapper. It's just possible to use this wrapper in stead of a normal filesystem!! This wrapper does find all the information necessay out of the key (/smb::[EMAIL PROTECTED]@WORKGROUP%share) to call the real mounter mount.cifs! The automounter is started at boottime with a rc script. There is only one point which is difficult: for which users the network representation has to be build. Any advice appreciated. I'm using a special module in PAM for that purpose right now, but maybe there are other ways to do this. My most recent howto is on: http://linux.bononline.nl/linux/automountsmbshares/automountsmbshares-page01a.php An older version is available at: http://www.howtoforge.com/automatic_discovery_mounting_smb_networkshares This latest version I will update as soon as I'm ready with the documentation on my own website. This construction is working very good. Try it. If you need any help you can contact me. Stef Bon ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
Re: [autofs] user token
On Tuesday 27 November 2007 09:19:35 muzzol wrote:
2007/11/27, Ian Kent [EMAIL PROTECTED]:
What is it that you need that the standard environment I mentioned
doesn't provide?
for example sending a message to user with zenity. for identifying
wich user is performing the request i must do some tricky things now,
and only works on stations with just one user logged in.
exposing some user variables _inside_ executable mappings would help a
lot with mounts that need some interaction from user.
look out this pseudo-code:
if user request for samba mount
if not exists credentials file
ask for credentials
as i said, i got a working script, but is very dirty and specific.
Well i've done something like this. Look at:
http://www.howtoforge.com/automatic_discovery_mounting_smb_networkshares
I've been struggling with this question some time, and found a good way to deal
with this USER
variable.
In short:
. there are some scripts which are run by fcron which maintain a cache. These
scripts make use of nbtscan (systemwide) and
smbclient (per user) to find all hosts and shares. The latest make use of a
credentialsfile (if found, if no then guest).
. one of the mainthings these script create is a windows network tree in the
homemap of all users logged in:
~/Global Network/Windows Network/Host A/first share A
second share A
Host B/first
share B
second share B
The shares are symbolic links. For example the first share A of host A points
to:
/mnt/autofs/user/%USER%/smb/Host A/first share A
Now on this directory my automount program is active (which for this user is
started
when he logs in, but still is running as root), with only:
auto.hosts and auto.share which look like:
auto.hosts in the /var/run/autofs/user/%USER%/smb directory
#!/bin/bash
echo -fstype=autofs,-Dhost=${host}
file:/var/run/autofs/user/%USER%/smb/auto.share
and auto.share also in the /var/run/autofs/user/%USER%/smb directory
* ${host}:/
* -fstype=smb ://${host}/
Now this smb filesystem does not exist (only cifs and smbfs right?) I've
created a script
mount.smb which calls mount.cifs (or mount.smbfs).
To this program no variable is know which can identify the user. Simular to
your problem.
Now when you look at the mountpoint, the mountpoint is always something like:
/mnt/autofs/user/%USER%/smb/somehost/someshare
so with a program like cut you can extract the exact userid:
userid=$(echo $mountpoint | cut --delimiter / --fields 5 )
If this is found,
you can check in the userhomedirectory for a credentialsfile.
If found, the script will call the right mountprogram (mount.cifs or
mount.smbfs)
with the credentialsfile. If not there, it will do a guest mount.
Note that this construction in my mail here is newer than in the howto on
howtoforge.
I'm running this at home, and it's very good.
Hope this helps,
Stef Bon
Voorburg
the Netherlands
___
autofs mailing list
autofs@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/autofs
[autofs] Please some comment on this construction.
Hello,
since some time now I'm using a construction which makes use of a construction
of auto files
(auto.master, auto.hosts and auto.share) to mount smb shares on demand.
I'm wrriting a howto about it now, which will appear soon on HowtoForge.
Now I've found information about the configuartion of the three files on:
http://www.novell.com/coolsolutions/tip/19076.html
A short summary:
there are three files, the auto.master file:
/mydomain /etc/auto.mydomain
the auto.mydomain file:
* -fstype=autofs,-Dhost= file=:/etc/auto.mydomain.sub
and the /etc/auto.mydomain.sub
* ${host}:/
*
-fstype=smbfs,workgroup=mydomain,uid=myuser,credentials=/home/myuser/.smb/mydomain
://${host}/
Now my question is about the latest file. First thing: what is happening here?
The first line, what does it?
I anybody can help me here,
thanks,
Stef Bon
the Netherlands
___
autofs mailing list
autofs@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/autofs
[autofs] Question about documentation/examples.
Hello, I'm working on a construction which: - automatic discovers the Windows (Samba) network (domains/hosts/shares) and builds a network tree in the home directory of all the connected users - automatic mount the share on a per user basis when user or application wants to enter a share. Her I use autofs for. It works very good. The following links helped me a lot: http://www.howtoforge.com/accessing_windows_or_samba_shares_using_autofs http://www.novell.com/coolsolutions/tip/19076.html At this moment the setup I'm using works very good! I do not have to configure anything manually. Now, I would like to experiment more with the configuration of the various auto.* files. I've been looking for detailed documentation about it, but only found the manpages and an old guide on The Linux Documentation Project.. This howto is aged, and the manpages give - to me - only a global impression. Sorry for the one who has written those, but I'm just trying te get familiar with autofs.. So my question is, is there documentation which can help me futher?? Thanks in advance, Stef ___ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
