Re: Komba.. (More reasons why it has to reap mounts)

[Paul Cupis <paul@cupis.co.uk>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 23 Apr 2003 17:34, Michael Peddemors 
<michael@linuxmagic.com> wrote:
> On Wednesday 23 April 2003 06:22, Paul Cupis wrote:
> > Deleted users if a much different scenario than users who have
> > logged off and left 'long' running processes running.
>
> Yes, but both have to be handled.  Can you think of a basic premise
> where if a user doesn't have a process running, he needs the mounts
> still?

Cron jobs, delayed execution of programs/scripts.

> > > Well, we should be able to detect if
> > > 1) the user has active processes
> > > 2) the user is logged in (Actually that will be covered by 1)
> > >
> > > If not, the mount can be reaped.
> >
> > How do you propose to reap the mounts? This is not, AFAIK,
> > something which komba is concerned with.
>
> I heard that, but if the program is used to mount the shares, it
> should be able to look after unmounting them..

It can unmount them - doesn't necessarily mean it should reap them. 
Perhaps you feel the same way about the other mount tools, and smbmount 
GUIs?

> > Description: KDE Samba browser
> >  Komba2 is a GUI machine and share browser for the
> >  SMB protocol. Komba2 allows you to scan any number
> >  of subnets for machines with SMB. The workgroups,
> >  machines and share are shown in a tree-view.
> >  For each machine you can then view the list of
> >  shares, and mount, unmount or browse them. You can
>
>                                 ^^^^^^^^
>
> > If you want users to unmount things when they log off, perhaps this
> > could be added as an option to komba ( [X] Always unmount upon
> > logoff ), but it should not be on by default. if you want unused
> > mounts on your system to be unmounted, you need some daemon to do
> > that. I am nt currently aware of any such daemon, though I'm sure
> > one could be coded. But unmounting something accidentally or
> > incorrectly could be disasterous.
>
> It needs to be addressed, in any case, and if at least any mounts
> created by Komba were reaped when unused, then we would be a long
> way.  Any shares mounted manually, (ie not via Komba) it doesn't have
> to deal with..  Then noone has to deal with the whole debian system
> logic as a whole, and deal with it strictly in the package that
> handles 'mounting and unmounting'.
>
> Maybe a seperate 'mtab style' record keeping, and a cron job to clean
> them would be the simplest, or a Komba Reaper Daemon, and this could
> have 'as an option' the ability to clean up system mounts, but this
> should not be the default.
>
> > Perhaps automatic unmounting-upon-closing-komba could be added as a
>
> They already have that..
>
> > user-definable option, but I think that would be a bad idea. One
> > should not have to have komba running the entire time one wants to
> > use a share mounted _via_ komba. Having an unmount-upon-logoff
> > would be better, but
>
> Yes, precisely....
>
> > would require some part of komba to be called upon KDE logoff to do
> > the unmounting.
>
> But that doesn't handle disco's  So a reaper would have to be in
> place anyways, so might as well let the reaper do all the work.  As
> well, it may need to be at the user logoff, and not KDE logoff,
> however that might be more satisfying for those liking 'Microsoft
> Style'

Discos? If you want to take mounting/unmounting out of the users hands, 
maybe try autofs/automount/whatever it is called.

> > I can understand the problem you percieve, but I do not agree with
> > your proposed solutions. Users should unmount shares when they have
> > finished
>
> SHOULD??? We aren't dealing with educated users, and expecting 100
> users to remember to do this every day on an xterminal system is
> impractical.

Educate the users, then? They must have been educated enough to _mount_ 
the shares, why not unmount them?

> > If they do not unmount them, perhaps they had a good reason
>
> No, it shoudl be that if they have a NEED to keep shares opened after
> all their tasks are completed, they should perform some special
> operation to do so, but this SHOULD NOT be the default behavior in a
> robust system.

Some special operation? Like mounting the shares? I assume you mean that 
auto-reaped shares should be the default, persistant shares should be 
an option?

Paul Cupis
- -- 
paul@cupis.co.uk

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+qbezIzuKV+SHX/kRAg6zAJ0WdqQmUSRlXIZCPnig8uWkgbxeLQCdFhKx
CJx/WkOGdNf8PKR961x/qTI=
=VmQc
-----END PGP SIGNATURE-----