On Wed, Apr 27, 2016 at 01:27:08PM -0400, Steve Litt wrote:
> On Wed, 27 Apr 2016 08:25:02 -0400
> fsmithred <fsmith...@gmail.com> wrote:
> 
> > On 04/26/2016 09:32 PM, Steve Litt wrote:
> > > On Tue, 26 Apr 2016 18:19:32 -0400
> > > fsmithred <fsmith...@gmail.com> wrote:
> > > 
> > >   
> > >> I like pmount for mounting usb devices. It's pretty smart. For
> > >> removable devices, you don't need to list them
> > >> in /etc/pmount.allow, and it handles encrypted filesystems
> > >> (cryptsetup/luks).  
> > > 
> > > 
> > > Ahh, now I remember. Pmount isn't an AUTOmounter, you still must
> > > tell it which device to mount. It doesn't mount the second you plug
> > > in your thumb drive.
> > > 
> > > Therefore: pmount, when combined with the inotifywait automounters
> > > we've all made, should be perfect.
> > > 
> > > Those pmount automounter commands should run as the user who plugs
> > > in the thumb, so rather than running straight from the init, they
> > > should probably run when you log in, and if there's already a copy
> > > running when you log in, it does nothing.
> > > 
> > > SteveT
> > >   
> > 
> > That's pretty much what my usb-mounter does. Inotifywait runs when
> > you log into the desktop, and when you plug in a thumb drive, it pops
> > up a window showing you the partitions on that device. You then
> > choose one to mount, and the script runs pmount in your name.
> 
> That sounds *perfect* to me, always assuming the "window" is a CLI
> question and answer i X isn't running. Where's the source code? I'd like
> to start using it.
> 
> Somebody suggested we package an automounter for Devuan. What you
> describe sounds like the right thing.
> 
> 
> > Bypassing the popup window and automounting would be a simple edit,
> 
> My no-user-confirmation version was problematic and vaguely disturbing.
> I'd leave the user in the loop.
> 
> > as would making it work without a gui.
> 
> Yes. This being Devuan, some facility for asking and recieving an
> answer should be provided even if X isn't runnnig.

If X isn't running on the local screen, is what I suspect you mean.
Assuming the cocept is a "local screen" is well-defined.
It might not be ideal to post the mount on the screen of someone who 
has logged in remotely by ssh -X.  But what if one ssh -x's in from a 
user that *is* on the local screen? etc., etc.

Being able to ask what's been plugged in recently with a CLI command 
might also be useful.

> 
> > I don't know what happens if
> > there are multiple users logged in at the same time, but that might
> > be an edge case.

It should certainly take account of who is logged in locally, ane whose 
virtul X terminnal is actually on the screen.  I once had a system that 
would automount plugged-in USBs for the first user it found in the 
/etc/p0assword file (starting at UID 1000, of course), whether s/he/it 
was logged in at the momet or not.  This was *always* the wrong choice.  
I had to become root to unmount; only after that could I become mysseld 
and mount again.

-- hendrik
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Reply via email to