:: Re: [DNG] automount, mount, and USB…
トップ ページ
このメッセージを削除
このメッセージに返信
著者: Steve Litt
日付:  
To: dng
題目: Re: [DNG] automount, mount, and USB sticks
On Tue, 28 Jul 2015 20:09:06 -0700
James Powell <james4591@???> wrote:

> ________________________________
> From: Hendrik Boom<mailto:hendrik@topoi.pooq.com>
> Sent: ‎7/‎28/‎2015 7:45 PM
> To: dng@???<mailto:dng@lists.dyne.org>
> Subject: Re: [DNG] automount, mount, and USB sticks
>
> On Tue, Jul 28, 2015 at 01:08:26PM -0700, Gregory Nowak wrote:
> > On Tue, Jul 28, 2015 at 03:17:11PM -0400, Hendrik Boom wrote:
> > > Of course I have to guess whether the device has
> > > been plugged in as /dev/sdb, or /dev/sde, or whatever. In case of
> > > (frequent) doubt, I switch to a root console with control-alt-F1
> > > and a login, unplug the device, and plug it in again. It will
> > > the tell me after a while, that a new device has been inserted,
> > > and tell me what /dev/sd* name it has dynamically installed. I
> > > end up, as root, mounting the device with root as the owner.
> > > It's usually a USB stick with one of the ubiquitous Microsoft
> > > file systems used on USB sticks, and all the files can be read or
> > > writen by root only.
> >
> > There is a much easier way. Instead of switching consoles and
> > guessing, just plug the device in, and look at the last screen full
> > of the output from dmesg.
>
> Yes, that would have been easier.
>
> > Also, if you're mounting on your own laptop, it
> > will usually have one hd, /dev/sda. When you plug in a usb device,
> > it will probably have /dev/sdb. If you unplug it, and plug in the
> > same device, or plug in another stick, it will probably
> > have /dev/sdb still.
>
> For whatever reason, there was a time when it kept picking new letters
> if I umounted the stick, took it ouot, and put another in. Maybe
> there was a bug somewhere then? But I could not rely on it always
> being /dev/sdb.
>
> > So, you could just put a line in /etc/fstab which will allow a
> > normal user to mount /dev/sdb1 for example to whatever directory you
> > want. All you would have to do as a normal user is to type:
> > mount /dev/sdb1
> > after plugging in the drive, and you should be able to find its'
> > contents under whatever directory you specified in fstab.
>
> Truth is, I no longer trust it to be consistent.
>
> -- hendrik
>
> >
> > Greg




================ JAMES POWELL SAID ====================
> Eventually, and I kinda realized this, work may be needed to write a
> udisks replacement for vdev that can work off vdev without loosing
> functionality to udisks using applications and file managers,
> especially for non-Linux systems.
>
> Nothing fancy, but as long as it works and allows for some level of
> control for admins, I don't have a problem with it.
>
> Thoughts?

================ JAMES POWELL SAID ====================

A glimpse at https://wiki.archlinux.org/index.php/Udisks shows this
udisks thing to be so thoroughly entangled with programs subsumed by
systemd that it's just too much work. dbus, polkit, you have to enmesh
it with how much stuff just to mount something.

Just to inject some humor into it, see this section:

https://wiki.archlinux.org/index.php/Udisks#inotify

Yeah, that's right: Arch is recommending that the actual plug-in
detection be done with inotify, the isolated-from-systemd that I was
going to use for my automounter if I got 20 people and Jude is using to
replace part of udev.

Meanwhile, as far as I can see, their entanglement with polkit does
nothing more than my idea about sudo. Does anyone see any reason why
polkit should be assumed more secure than sudo?

And dbus? The only reason I can think of for dbus is so our good
friends at Freedesktop.Org can have their desktop environment can phone
in the request to unmount. About those phone-in requests via dbus: Is
there any reason we can't have a program called Devuan Control Center
that becomes the *real* place the user goes in order to tell the
computer to unmount, reboot, poweroff, log out, etc. Seriously, why
should mounting and unmounting, manually or automatically, have
*anything* to do with a GUI? They're OS functions.

I think rewriting udisks is a snipe hunt: we need to make a clean
break, in my opinion. Otherwise we'll be forever chasing Lennart's
latest great idea of the week.

SteveT

Steve Litt
July 2015 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21