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@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@centos.org http://lists.centos.org/mailman/listinfo/centos
--On Tuesday, June 07, 2011 12:58 AM -0400 Robert Heller heller@deepsoft.com wrote:
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.
In my case they're all magnetics with ext3 logical drives, so they show up with labels.
My practice has been to label them "Backup1", "Backup2", etc. and then "mount /dev/disk/by-label/Backup1 /mnt/Backup1". Or list all the possibilities in /etc/fstab so I can just name the mount point in the mount command.
An additional complication is that some USB drives spin down after some idle time, and don't spin back up when accessed, leading to errors and FS corruption. I've used "hdparam -s 0 --prefer-ata12 /dev/sdb" (for example) but some drives ignore that, so I end up needing to start a script that touches a file and sync's every few seconds.
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.
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).
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.
"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.
Ljubomir)
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.
Lamar Owen wrote:
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.
I needed to reactivate my Atheros radio after hibernate on CentOS 5.x, and NetworkManager on 5.x was not able to do that,so I had to use Network service and in cli to be able to script it.
I used NetworkManager in RHEL 6 Beta1 (recompiled it to work) but never needed it in cli mode.
OP stated that he is *running* headless *server*, so extrapolation gave me: CentOS 5.x (already running) and non movable system for one wireless connection (headless server). 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.
Ljubomir
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 6/7/2011 11:48 AM, Lamar Owen wrote:
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.....
A similar but worse situation most likely. 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.
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@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@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....).
On 6/7/2011 2:27 PM, Lamar Owen wrote:
I like the /media/$disk-label convention; no matter how many disks I may have, removeable media will come up properly.
I do a lot of disk image cloning and swapping disks around among machines. Does it handle getting duplicates in the same machine gracefully - or at least better than it used to when they first came up with partition labels and used them in fstab?
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....).
I almost never sit at the console of a linux box - or at least the one where the programs are running, so I'm much more interested in freenx/NX, or remote X performance. Or the ability of the GUI programs to work sensibly when running in a remote window. And I don't think it is sensible if I start firefox remotely with 'ssh -Y' and it tells a currently running instance on a different display to open a new window there.
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
-
Benjamin Hackl -
John R Pierce -
Kenneth Porter -
Lamar Owen -
Les Mikesell -
Ljubomir Ljubojevic -
Robert Heller