I'm running a headless server, so no GUI, just ssh logins. I don't seem to have the mechanism that automounts USB drives to a subdirectory of /media, and from googling around I think that's a feature of a GUI-based system. What implements it? Right now I manually create a mountpoint in /mnt and then manually mount by label from /dev/disk/by-label after plugging the drive in. It would be convenient if the drive automounted when plugged in.
At Mon, 06 Jun 2011 19:31:29 -0700 CentOS mailing list <centos at centos.org> wrote:> > I'm running a headless server, so no GUI, just ssh logins. I don't seem to > have the mechanism that automounts USB drives to a subdirectory of /media, > and from googling around I think that's a feature of a GUI-based system. > What implements it? Right now I manually create a mountpoint in /mnt and > then manually mount by label from /dev/disk/by-label after plugging the > drive in. It would be convenient if the drive automounted when plugged in.The problem is this: you also need some way to unmount the disk. And for FAT file systems, you need to somehow map the ownership. The GUI does the mount in the logged in user and the [GNome] desktop icon includes a right-click menu with an 'eject' / 'unmount' item. Delegate this functing to some daemon running as root or to a hotplug script (which would also be running as root), would be problematical for obvious reasons. Question are these random thumb drives? Or are they magnetic drives? Are then always connected? Regularly connected? FAT file systems? Ext2/3 file systems? There are several options: One option is to include a line in /etc/fstab like this: /dev/thumb /media/thumb auto noauto,user,rw 0 0 (/dev/thumb in this case is created by this udev rule: KERNEL=="sd[a-z]*", BUS=="scsi", SYSFS{device/vendor}=="Kingston", NAME="thumb" disk-by-label is not possible since this disk is formatted FAT) This disk is still manually mounted and dismounted, but a non-priviledged user can do the mount and unmount and only the mount point is used. The other option is to use automount with lines like this in an automount config file: /reposi386 -fstype=ext2 :LABEL=REPOSI386 /reposx86_64 -fstype=ext2 :LABEL=REPOSX86_64 (these are 16gig thumb drives reformatted with labeled ext2 file systems) These drives are mounted on-demand and auto dismount after period of idleness.> _______________________________________________ > CentOS mailing list > CentOS at centos.org > http://lists.centos.org/mailman/listinfo/centos > >-- Robert Heller -- 978-544-6933 / heller at deepsoft.com Deepwoods Software -- http://www.deepsoft.com/ () ascii ribbon campaign -- against html e-mail /\ www.asciiribbon.org -- against proprietary attachments
On 06/06/11 7:31 PM, Kenneth Porter wrote:> think that's a feature of a GUI-based system.indeed, this is a ongoing peeve of mine with linux. getting wireless networking functioning without those GUI helpers is a real pain too. this stuff should all be implemented in underlying daemons, with both text and GUI control surfaces. -- john r pierce N 37, W 123 santa cruz ca mid-left coast
I'd recommend automount. I think it is installed by default.
Have a look at /etc/auto.misc
Just add an entry like
foobar -mountoptions :/dev/disk/by-label/foobar
which would mount your device as /misc/foobar
Also check /etc/auto.master and man {autofs,automount,auto.master}
Don't forget to
chkconfig autofs on
Brgds
--
Freundliche Gruesse/Best Regards
Benjamin Hackl
IT/Administration
Media FOCUS Research Ges.m.b.H.
Maculangasse 8, 1220 Wien
Tel.-Nr.: +43 1 258 97 01-295
benjamin.hackl at focusmr.com
http://www.focusmr.com/
On Tuesday, June 07, 2011 12:38:12 AM John R Pierce wrote:> On 06/06/11 7:31 PM, Kenneth Porter wrote: > > think that's a feature of a GUI-based system. > > indeed, this is a ongoing peeve of mine with linux. getting wireless > networking functioning without those GUI helpers is a real pain too. > > this stuff should all be implemented in underlying daemons, with both > text and GUI control surfaces.NetworkManager has text utilities, at least in EL6. (the nmcli applet, part of the base NetworkManager package). How well it works I don't know, haven't tried. But GUI isn't a dirty word. While it's nice to do things CLI only, and it's definitely conserving of bandwidth, there are uses for the GUI that the CLI cannot do easily. And vice-versa. Since it is an open-source system, John, you know that for it to get implemented someone has to have that itch to scratch..... and the place to scratch that itch is in Fedora.... Upstream EL has other goals, and things do get implemented due to paying customer request. Sometimes even due to request from a non-customer..... Apparently the 'CLI can control everything the GUI can' isn't an itch anyone is currently scratching (unless that's one of the goals behind systemd.... although I think the opposite goal is the case there, making the system much more GUI-drivable at all levels).
On Tuesday, June 07, 2011 09:42:48 AM Ljubomir Ljubojevic wrote:> "system-network-config-cmd -p WirelessHome -a" will select existing > profile WirelessHome and activate it. It's not NetworkManager but > "network" service.> "iwlist ath0 scanning will list all available AP's in range so you can > choose ESSID for system-config-network config screen (it should work in > console mode.While I somewhat understand the reticence of some folks to try to understand NetworkManager, the fact of the matter is that that is upstream's preferred networking daemon these days (EL6 days, that is). The older method will become less and less supported as time goes on. Not that I'm a 'fan' of NetworkManager; I'm just a pragmatist in this regard: it's the preferred, supported, way to do things in that release, so might as well learn it, at least for those cases where it works well. It's not that hard to learn how to use nmcli to do both of those operations as listed above. The second operation, for instance, is: nmcli dev wifi which will list the AP's on all wifi interfaces. To get a list of connections: nmcli con list To bring a connection up: nmcli con $conid up Configuring the connections is a different story; on Fedora at least there is cnetworkmanager, and it appears to not yet be in EPEL. So getting the connections configured first seems to be a little more difficult. But not having tried it....I can't intelligently comment. According to the documentation at least the /etc/sysconfig/network-scripts directory is still there, and still usable with manual editing.
On Tuesday, June 07, 2011 12:32:01 PM Ljubomir Ljubojevic wrote:> So knowing how lame NetworkManager in 5.x > is, I suggested viable solution for his particular problem, unmovable > headless CentOS 5.x> And thanks for NM cli commands, I might need it when my laptop goes C6.Which is why I mentioned them, as that is the direction upstream is going. EL5 probably will never have many of the very nice amenities that EL6 has. But the whole NM thing isn't actually on the line of the OP's question; that was about hotplugged USB drives.....
On Tuesday, June 07, 2011 02:45:32 PM Les Mikesell wrote:> There's a lot of gunk that > assumes that the person logged into the console automatically owns some > of the devices - a concept that doesn't make much sense in the context > of a multiuser system that can handle concurrent users. And I think > some of that is wired into the GUI parts. I'd say you are better off > avoiding that and mounting/unmounting things the way you want.That's one thing ConsoleKit and PolicyKit are for..... of course, if those aren't already being deprecated.... But I do use Linux at the desktop, daily, using KDE 4 for that matter, and it works marvelously. I also have true multiuser GUI systems running; and I've found the tools that are in place to be reasonable, and further to work in a pretty intuitive fashion. No dependence on absolute disk device names, etc. As an extreme example, on my EL6 testbed system, the boot drive is.... well, look for yourself: [root at www ~]# mount /dev/mapper/vg_www-lv_root on / type ext4 (rw) proc on /proc type proc (rw) sysfs on /sys type sysfs (rw) devpts on /dev/pts type devpts (rw,gid=5,mode=620) tmpfs on /dev/shm type tmpfs (rw,rootcontext="system_u:object_r:tmpfs_t:s0") /dev/sdaa1 on /boot type ext4 (rw) /dev/md127 on /home type ext3 (rw) /dev/mapper/vg_bak2-lv_lobak on /opt/lobak type ext4 (rw) none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw) sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw) /dev/sdg1 on /home/lowen type ext4 (rw) [root at www ~]# That's not a typo; /boot is on /dev/sdaa1 (two 'a's). It changes from boot to boot, depending upon exact delays, disk spinup on the devices under /dev/md127, and LUN recognize delays on the Clariion (which depends on which path happens to get chosen by the multipather as well as how much load are on the Clariions right now). Oh, and it depends on how temperamental the 3Ware 9550 is being today, since the boot drive is on a RAID5 of four disks on it. The first plugged-in USB disk will get, right now at this moment, /dev/sdad. I like the /media/$disk-label convention; no matter how many disks I may have, removeable media will come up properly. What I haven't found out how to do is tell the system that two of the SATA ports on the SiI3124 controller (where the RAID1 two-drive /dev/md127 lives) are actually external and thus removeables.... And even though this is a typical server box with a typically anemic ATI Rage XL, GUI performance, even with Firefox, isn't bad at all. (Supermicro dual Xeon board with multiple high-speed 64-bit PCI-X busses and slots; haven't found a good low-profile 133MHz PCI-X VGA board yet....).