While there are so much chattering about automounting, security considerations of the new fstab "console" tag etc., i have as a systems administrator withnessed one thing - with something as old as floppyes.
People mount up the floppy (acctually, they have no clue that they are mounting it, they just click the nice little "floppy" icon), get their files, pull out the floppy (without umounting), and logs out.
Then, 2 minutes later, another user logs in, pulls up his/her floppy, and... the floppy is mounted. Cant get it umounted, and can't mount his/her floppy. Grr...
Reason that there is a problem with floppyes and not other removable storage, is of cource that floppyes is the only removable storage that the user can pull out without the system gets the message - if you pull an usb mass storage plug, it gets umounted (and it is mounted "sync" so you probably won't loose data either). If you try to eject a cd, it wont come out - untill you umount it (this is really frustrating to new users as well - the "eject" button should umount the cd and eject it, and if it is buisy, tell dbus to tell gnome to display that popup we all loved in fc1)
But what if all volumes that the user mounted when he/she was logged on, automatically got umounted when the user who mounted it logs out? That would solve it.
About the "console" flag: would a user sitting on an XDMCP terminal be considered a console user or not? How is it determined if he/she is a console user or not? Because someone sitting on an xdmcp terminal shouldn't be considered "console"...
Kyrre
Kyrre Ness Sjobak wrote:
People mount up the floppy (acctually, they have no clue that they are mounting it, they just click the nice little "floppy" icon), get their files, pull out the floppy (without umounting), and logs out.
Then, 2 minutes later, another user logs in, pulls up his/her floppy, and... the floppy is mounted. Cant get it umounted, and can't mount his/her floppy. Grr...
I've oftentimes setup machines to use the automounter with a rediculously low timeout value (say 6-30 seconds) for cases/users like this.
-- Rex
On Mon, 2004-10-04 at 15:35 +0200, Kyrre Ness Sjobak wrote:
Then, 2 minutes later, another user logs in, pulls up his/her floppy, and... the floppy is mounted. Cant get it umounted, and can't mount his/her floppy. Grr...
Yeah, it's a perennial problem. I guess people are trying to solve it with user-space proxy filesystems and the like. Not sure how mature they are.
But what if all volumes that the user mounted when he/she was logged on, automatically got umounted when the user who mounted it logs out? That would solve it.
Hmmm. The argument against that I guess is that the user could want it to stay mounted for one of their cron jobs or something. Maybe that's sufficiently obscure that we could ignore it. But it still doesn't solve the case of a user just ejecting the disk before logout.
About the "console" flag: would a user sitting on an XDMCP terminal be considered a console user or not?
No.
How is it determined if he/she is a console user or not?
Local Linux console login or local GDM.
man, 04.10.2004 kl. 15.49 skrev Colin Walters:
On Mon, 2004-10-04 at 15:35 +0200, Kyrre Ness Sjobak wrote:
Then, 2 minutes later, another user logs in, pulls up his/her floppy, and... the floppy is mounted. Cant get it umounted, and can't mount his/her floppy. Grr...
Yeah, it's a perennial problem. I guess people are trying to solve it with user-space proxy filesystems and the like. Not sure how mature they are.
Sure. Think KDE does that.
But what if all volumes that the user mounted when he/she was logged on, automatically got umounted when the user who mounted it logs out? That would solve it.
Hmmm. The argument against that I guess is that the user could want it to stay mounted for one of their cron jobs or something. Maybe that's sufficiently obscure that we could ignore it. But it still doesn't solve the case of a user just ejecting the disk before logout.
That is just to obscure. You dont run cron jobs on a client off removable media. You just dont do that. But shure, make it possible to turn back on if neccesary.
About the "console" flag: would a user sitting on an XDMCP terminal be considered a console user or not?
No.
Good. Then we can finaly make removable media mountable on our thin-client-server. (today only root can do that)
How is it determined if he/she is a console user or not?
Local Linux console login or local GDM.
Sound good
But what happens if you log out with "control-alt-backspace"? Iv'e seen prosesses survive that...
(and i have a certain thin-client-server, which has people which logged on in august, even if they certainly isn't logged on today...)
On Mon, 2004-10-04 at 16:00 +0200, Kyrre Ness Sjobak wrote:
man, 04.10.2004 kl. 15.49 skrev Colin Walters:
On Mon, 2004-10-04 at 15:35 +0200, Kyrre Ness Sjobak wrote:
Then, 2 minutes later, another user logs in, pulls up his/her floppy, and... the floppy is mounted. Cant get it umounted, and can't mount his/her floppy. Grr...
Yeah, it's a perennial problem. I guess people are trying to solve it with user-space proxy filesystems and the like. Not sure how mature they are.
Sure. Think KDE does that.
Like at the kio layer or something? So all I/O in KDE goes through a daemon? Or just when it's a floppy drive?
That is just to obscure. You dont run cron jobs on a client off removable media. You just dont do that.
Actually I do for my backups :)
But what happens if you log out with "control-alt-backspace"? Iv'e seen prosesses survive that...
Good question - If gdm doesn't handle that it's really a bug.
man, 04.10.2004 kl. 16.34 skrev Colin Walters:
On Mon, 2004-10-04 at 16:00 +0200, Kyrre Ness Sjobak wrote:
man, 04.10.2004 kl. 15.49 skrev Colin Walters:
On Mon, 2004-10-04 at 15:35 +0200, Kyrre Ness Sjobak wrote:
Then, 2 minutes later, another user logs in, pulls up his/her floppy, and... the floppy is mounted. Cant get it umounted, and can't mount his/her floppy. Grr...
Yeah, it's a perennial problem. I guess people are trying to solve it with user-space proxy filesystems and the like. Not sure how mature they are.
Sure. Think KDE does that.
Like at the kio layer or something? So all I/O in KDE goes through a daemon? Or just when it's a floppy drive?
That is just to obscure. You dont run cron jobs on a client off removable media. You just dont do that.
Actually I do for my backups :)
Hmm... Okay. I get it. But still - lets make this configurable, right? And what kind of enviroment are you backing up from, to what media? From which user?
But what happens if you log out with "control-alt-backspace"? Iv'e seen prosesses survive that...
Good question - If gdm doesn't handle that it's really a bug.
-- fedora-devel-list mailing list fedora-devel-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-devel-list
That is just to obscure. You dont run cron jobs on a client off removable media. You just dont do that.
Actually I do for my backups :)
AOL. With todays sizes and prizes of removable storage, it really makes much more sense to backup to a 300GB fast, easy to install and cheap FireWire-disk, than to a slow and expensive tapedrive. =;-)
Most of the time this is probably done as root, but I guess there still might be situations where one wants to run such a job as another user.
Rgds. Ola Thoresen
man, 04.10.2004 kl. 16.34 skrev Colin Walters:
On Mon, 2004-10-04 at 16:00 +0200, Kyrre Ness Sjobak wrote:
man, 04.10.2004 kl. 15.49 skrev Colin Walters:
On Mon, 2004-10-04 at 15:35 +0200, Kyrre Ness Sjobak wrote:
Then, 2 minutes later, another user logs in, pulls up his/her floppy, and... the floppy is mounted. Cant get it umounted, and can't mount his/her floppy. Grr...
Yeah, it's a perennial problem. I guess people are trying to solve it with user-space proxy filesystems and the like. Not sure how mature they are.
Sure. Think KDE does that.
Like at the kio layer or something? So all I/O in KDE goes through a daemon? Or just when it's a floppy drive?
Through the KIO layer. There is (at least i think there is) a client called "floppy:/". Just open the KDE "open file" dialog, and you will find it.
BTW i'm a gnome fan so i really shouldn't know this. But somehow i do... The reason for me to have konquerror installed (hey, gotta have qt anyway, so many progs need it, btw KDE is a good backup) is fish://... I love that. Why isn't there such a thing for GNOME? :(
That is just to obscure. You dont run cron jobs on a client off removable media. You just dont do that.
Actually I do for my backups :)
But what happens if you log out with "control-alt-backspace"? Iv'e seen prosesses survive that...
Good question - If gdm doesn't handle that it's really a bug.
-- fedora-devel-list mailing list fedora-devel-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-devel-list
hi,
i am trying to set up bonding to have NIC redundancy, i have set it up to work the only problem is that the NIC are flooding the cisco switch with it MAC address?? figthing for the port, does anyone know a fix for this?
Kashif
please create a new thread instead of ansvering to an old one. People who are using threaded mail clients (such as evolution, newsgroups, and the archive) will see your mail as a reply to RFE: more on mounting.
Kyrre
man, 04.10.2004 kl. 17.04 skrev Kashif Ali:
hi,
i am trying to set up bonding to have NIC redundancy, i have set it up to work the only problem is that the NIC are flooding the cisco switch with it MAC address?? figthing for the port, does anyone know a fix for this?
Kashif
Kashif Ali wrote:
hi,
i am trying to set up bonding to have NIC redundancy, i have set it up to work the only problem is that the NIC are flooding the cisco switch with it MAC address?? figthing for the port, does anyone know a fix for this?
Kashif
On Mon, 2004-10-04 at 16:58 +0200, Kyrre Ness Sjobak wrote:
BTW i'm a gnome fan so i really shouldn't know this. But somehow i do... The reason for me to have konquerror installed (hey, gotta have qt anyway, so many progs need it, btw KDE is a good backup) is fish://... I love that. Why isn't there such a thing for GNOME? :(
ssh://
On Mon, 2004-10-04 at 11:14, Colin Walters wrote:
On Mon, 2004-10-04 at 16:58 +0200, Kyrre Ness Sjobak wrote:
BTW i'm a gnome fan so i really shouldn't know this. But somehow i do... The reason for me to have konquerror installed (hey, gotta have qt anyway, so many progs need it, btw KDE is a good backup) is fish://... I love that. Why isn't there such a thing for GNOME? :(
ssh://
Have the key adding and password-acceptance dialogs been added. And does it handle symlinked-dirs properly now? The last time I used it it was a complete mess.
-sv
Kyrre Ness Sjobak wrote:
While there are so much chattering about automounting, security considerations of the new fstab "console" tag etc., i have as a systems administrator withnessed one thing - with something as old as floppyes.
People mount up the floppy (acctually, they have no clue that they are mounting it, they just click the nice little "floppy" icon), get their files, pull out the floppy (without umounting), and logs out.
Then, 2 minutes later, another user logs in, pulls up his/her floppy, and... the floppy is mounted. Cant get it umounted, and can't mount his/her floppy. Grr...
Reason that there is a problem with floppyes and not other removable storage, is of cource that floppyes is the only removable storage that the user can pull out without the system gets the message - if you pull an usb mass storage plug, it gets umounted (and it is mounted "sync" so you probably won't loose data either). If you try to eject a cd, it wont come out - untill you umount it (this is really frustrating to new users as well - the "eject" button should umount the cd and eject it, and if it is buisy, tell dbus to tell gnome to display that popup we all loved in fc1)
But what if all volumes that the user mounted when he/she was logged on, automatically got umounted when the user who mounted it logs out? That would solve it.
About the "console" flag: would a user sitting on an XDMCP terminal be considered a console user or not? How is it determined if he/she is a console user or not? Because someone sitting on an xdmcp terminal shouldn't be considered "console"...
Kyrre
Maybe the easiest would be to patch the Gnome/KDE Desktop file-io with floppy devices to mount/umount after each action (like the mtools).
It sometimes takes a helluva lot of time to mount a vfat floppy... Besides, it would still be better to do a "forced" umount on logout (so it would work even if the disc isn't there/still active progs in the path - just kill'em)
man, 04.10.2004 kl. 15.51 skrev Harald Hoyer:
Kyrre Ness Sjobak wrote:
While there are so much chattering about automounting, security considerations of the new fstab "console" tag etc., i have as a systems administrator withnessed one thing - with something as old as floppyes.
People mount up the floppy (acctually, they have no clue that they are mounting it, they just click the nice little "floppy" icon), get their files, pull out the floppy (without umounting), and logs out.
Then, 2 minutes later, another user logs in, pulls up his/her floppy, and... the floppy is mounted. Cant get it umounted, and can't mount his/her floppy. Grr...
Reason that there is a problem with floppyes and not other removable storage, is of cource that floppyes is the only removable storage that the user can pull out without the system gets the message - if you pull an usb mass storage plug, it gets umounted (and it is mounted "sync" so you probably won't loose data either). If you try to eject a cd, it wont come out - untill you umount it (this is really frustrating to new users as well - the "eject" button should umount the cd and eject it, and if it is buisy, tell dbus to tell gnome to display that popup we all loved in fc1)
But what if all volumes that the user mounted when he/she was logged on, automatically got umounted when the user who mounted it logs out? That would solve it.
About the "console" flag: would a user sitting on an XDMCP terminal be considered a console user or not? How is it determined if he/she is a console user or not? Because someone sitting on an xdmcp terminal shouldn't be considered "console"...
Kyrre
Maybe the easiest would be to patch the Gnome/KDE Desktop file-io with floppy devices to mount/umount after each action (like the mtools).
Harald Hoyer wrote:
Kyrre Ness Sjobak wrote:
While there are so much chattering about automounting, security considerations of the new fstab "console" tag etc., i have as a systems administrator withnessed one thing - with something as old as floppyes.
People mount up the floppy (acctually, they have no clue that they are mounting it, they just click the nice little "floppy" icon), get their files, pull out the floppy (without umounting), and logs out.
Then, 2 minutes later, another user logs in, pulls up his/her floppy, and... the floppy is mounted. Cant get it umounted, and can't mount his/her floppy. Grr...
Reason that there is a problem with floppyes and not other removable storage, is of cource that floppyes is the only removable storage that the user can pull out without the system gets the message - if you pull an usb mass storage plug, it gets umounted (and it is mounted "sync" so you probably won't loose data either). If you try to eject a cd, it wont come out - untill you umount it (this is really frustrating to new users as well - the "eject" button should umount the cd and eject it, and if it is buisy, tell dbus to tell gnome to display that popup we all loved in fc1)
But what if all volumes that the user mounted when he/she was logged on, automatically got umounted when the user who mounted it logs out? That would solve it.
About the "console" flag: would a user sitting on an XDMCP terminal be considered a console user or not? How is it determined if he/she is a console user or not? Because someone sitting on an xdmcp terminal shouldn't be considered "console"...
Kyrre
Maybe the easiest would be to patch the Gnome/KDE Desktop file-io with floppy devices to mount/umount after each action (like the mtools).
I think there was a brief discussion in the nautilus mailing list about writing an mtools backend for gnome-vfs.
Regards, Ricardo Veguilla
On Mon, 04 Oct 2004 15:35:41 +0200, Kyrre Ness Sjobak kyrre@solution-forge.net wrote:
About the "console" flag: would a user sitting on an XDMCP terminal be considered a console user or not? How is it determined if he/she is a console user or not? Because someone sitting on an xdmcp terminal shouldn't be considered "console"...
I strongly suggest you read over the system documentation on how pam_console works and the associated configuration files in an effort to understand how things are configured by default. My limited understanding of the default situations is that remote xdmcp connections are not considered 'console'. But don't take my word for it, i haven't gotten around to testing xdmcp during fc3 testing yet. If you are concerned I encourage you to test the remote xdmcp connection case and make sure the defaults are not configured to set the xdmcp user as console owner. Here's a hint the files in /var/run/console/ are particularly useful to watch, to figure out who is the current 'console' user.
-jef
I shall do that anyway - to ensure that my fc2 "thin" clients will work without reinstalling... (they once was fc1 thin clients) (the point of running a "normal" distro on them is to make it possible to plug'em in anywhere on the net without modifying the main DHCP server. Which is something i am not allowed to do (first thing i would do is to get a proper DHCPD and DNS - windows server 2000 dns sucks beyond anything. It cant even resolve all domain names...
man, 04.10.2004 kl. 15.56 skrev Jeff Spaleta:
On Mon, 04 Oct 2004 15:35:41 +0200, Kyrre Ness Sjobak kyrre@solution-forge.net wrote:
About the "console" flag: would a user sitting on an XDMCP terminal be considered a console user or not? How is it determined if he/she is a console user or not? Because someone sitting on an xdmcp terminal shouldn't be considered "console"...
I strongly suggest you read over the system documentation on how pam_console works and the associated configuration files in an effort to understand how things are configured by default. My limited understanding of the default situations is that remote xdmcp connections are not considered 'console'. But don't take my word for it, i haven't gotten around to testing xdmcp during fc3 testing yet. If you are concerned I encourage you to test the remote xdmcp connection case and make sure the defaults are not configured to set the xdmcp user as console owner. Here's a hint the files in /var/run/console/ are particularly useful to watch, to figure out who is the current 'console' user.
-jef
On Mon, Oct 04, 2004 at 03:35:41PM +0200, Kyrre Ness Sjobak wrote:
But what if all volumes that the user mounted when he/she was logged on, automatically got umounted when the user who mounted it logs out? That would solve it.
That sounds very sensible - please bugzilla it as an RFE
About the "console" flag: would a user sitting on an XDMCP terminal be considered a console user or not? How is it determined if he/she is a console user or not? Because someone sitting on an xdmcp terminal shouldn't be considered "console"...
An xdmcp session is not considered "console". VNC access to the console session (shared access) might be.
Handling devices on thin clients (often nbd exports of the client cdrom drive) is another matter again
man, 04.10.2004 kl. 16.36 skrev Alan Cox:
On Mon, Oct 04, 2004 at 03:35:41PM +0200, Kyrre Ness Sjobak wrote:
But what if all volumes that the user mounted when he/she was logged on, automatically got umounted when the user who mounted it logs out? That would solve it.
That sounds very sensible - please bugzilla it as an RFE
Shall do - but where?
About the "console" flag: would a user sitting on an XDMCP terminal be considered a console user or not? How is it determined if he/she is a console user or not? Because someone sitting on an xdmcp terminal shouldn't be considered "console"...
An xdmcp session is not considered "console". VNC access to the console session (shared access) might be.
Handling devices on thin clients (often nbd exports of the client cdrom drive) is another matter again
That would be cool - if a thin client could export its floppy (device, not mountpoint?) to the thin-client server. Same goes to sound - but does the loginscripts properly setup ESD?
Kyrre
On Mon, Oct 04, 2004 at 04:49:32PM +0200, Kyrre Ness Sjobak wrote:
That would be cool - if a thin client could export its floppy (device, not mountpoint?) to the thin-client server. Same goes to sound - but does the loginscripts properly setup ESD?
Our default ESD setup doesn't but then ESD stands for ESD Should Die 8). ESD does support this but getting it working with ssh tunnels is pretty horrid
man, 04.10.2004 kl. 16.58 skrev Alan Cox:
On Mon, Oct 04, 2004 at 04:49:32PM +0200, Kyrre Ness Sjobak wrote:
That would be cool - if a thin client could export its floppy (device, not mountpoint?) to the thin-client server. Same goes to sound - but does the loginscripts properly setup ESD?
Our default ESD setup doesn't but then ESD stands for ESD Should Die 8). ESD does support this but getting it working with ssh tunnels is pretty horrid
I like ESD... At least i did under OSS. Nowadays ALSA does the mixing, so... But (having resently heard from another admin, an i agree) multimedia (and removable storage) is really the only reason to avoid thin clients - exept that, it rocks! (if i just could have quake 3 and removable storage on a (purpose-built) thin client, my main box would happen to be in the basement in less that 10 minutes - no noise, bootup time=time for an LCD to start (less than one secound), little desktop real estate used... ahh. Mac's new shiny litle toy: mwah hah hah luser!)
Btw. in most enviroments, XDMCP runs *without* ssh, right?
And i *still* wonder where to file that RFE. Which component?
Kyrre
I know. just a unfortunate wording on my side.
I think running X through SSH would be a great idea (for security), but then they should maybe call it X11R7 instead? Oh wait. Extentions...
And i know you can tunnel it both through a ssh session (the -X flag) and also in some, mystical manner (yeah, if i need it, ill RTFM) forward ports through it. And that would break Esd Should Die... (why i have no clue - you're the hacker here, not me...)
Kyrre
man, 04.10.2004 kl. 19.22 skrev Alan Cox:
On Mon, Oct 04, 2004 at 05:05:49PM +0200, Kyrre Ness Sjobak wrote:
Btw. in most enviroments, XDMCP runs *without* ssh, right?
XDMCP is not based on ssh. Thats a limit in the X level protocols and should be filed upstream in the Xorg bugzilla.
[snip]
I like ESD... At least i did under OSS. Nowadays ALSA does the mixing, so... But (having resently heard from another admin, an i agree) multimedia (and removable storage) is really the only reason to avoid thin clients - exept that, it rocks! (if i just could have quake 3 and removable storage on a (purpose-built) thin client, my main box would happen to be in the basement in less that 10 minutes - no noise, bootup time=time for an LCD to start (less than one secound), little desktop real estate used... ahh. Mac's new shiny litle toy: mwah hah hah luser!)
Ok, as I manage some thin clients that have both local drive and local audio I think I am qualified to respond to this one. You can get audio on a thin client. GNOME appears to pick up on the fact that you're on a remote system and redirect audio automagicly. LTSP supports local drives as well. it's a little more complicated to setup. but not horribly so. and it's getting better GLX is supported, but you're not going to be getting the proprietary NVIDIA or ATi drivers installed without some trouble, but if you want quiet, you're gonna be going for older stuff anyway. here's a link to my website on all things ltsp. give it a look before you go writing stuff off as impossible.
http://www.bravegnuworld.com/~rjune/ltsp/
Thanks! Ill look into it :)
man, 04.10.2004 kl. 20.59 skrev Richard June:
[snip]
I like ESD... At least i did under OSS. Nowadays ALSA does the mixing, so... But (having resently heard from another admin, an i agree) multimedia (and removable storage) is really the only reason to avoid thin clients - exept that, it rocks! (if i just could have quake 3 and removable storage on a (purpose-built) thin client, my main box would happen to be in the basement in less that 10 minutes - no noise, bootup time=time for an LCD to start (less than one secound), little desktop real estate used... ahh. Mac's new shiny litle toy: mwah hah hah luser!)
Ok, as I manage some thin clients that have both local drive and local audio I think I am qualified to respond to this one. You can get audio on a thin client. GNOME appears to pick up on the fact that you're on a remote system and redirect audio automagicly. LTSP supports local drives as well. it's a little more complicated to setup. but not horribly so. and it's getting better GLX is supported, but you're not going to be getting the proprietary NVIDIA or ATi drivers installed without some trouble, but if you want quiet, you're gonna be going for older stuff anyway. here's a link to my website on all things ltsp. give it a look before you go writing stuff off as impossible.
RFE somehow landed at "basesystem". Guess i guessed that mount lives there.
https://bugzilla.redhat.com/bugzilla/post_bug.cgi
man, 04.10.2004 kl. 16.36 skrev Alan Cox:
On Mon, Oct 04, 2004 at 03:35:41PM +0200, Kyrre Ness Sjobak wrote:
But what if all volumes that the user mounted when he/she was logged on, automatically got umounted when the user who mounted it logs out? That would solve it.
That sounds very sensible - please bugzilla it as an RFE
About the "console" flag: would a user sitting on an XDMCP terminal be considered a console user or not? How is it determined if he/she is a console user or not? Because someone sitting on an xdmcp terminal shouldn't be considered "console"...
An xdmcp session is not considered "console". VNC access to the console session (shared access) might be.
Handling devices on thin clients (often nbd exports of the client cdrom drive) is another matter again
devel@lists.stg.fedoraproject.org
-
Alan Cox -
Colin Walters -
Harald Hoyer -
Jef Spaleta -
Kashif Ali -
Kyrre Ness Sjobak -
Ola Thoresen -
Rex Dieter -
Ricardo Veguilla -
Richard June -
seth vidal -
Warren Togami