USB Flash/Jump Drives-Linux??

Greetings: Running Slackware 9.0 and 9.1; kernels 2.4.20 or 2.4.22,
bare.i installation, I've experienced good support for all USB
devices except Flash Drives.

First one bought was a Link-Max UL-641 that, plugged in, was
immediately accessible by the kernel with no configuring by me..

Later attempts with other brands, no such luck.. As I look at the
retail boxes not a single one mentions Linux, so was wondering what
others have discovered.. It's no fun buying then returning just to
see what works or doesn't...

Most of the comments on the Web seem to indicate this is not a
problem but I've found otherwise.. One vendor, Kingston, said flat
out that Linux is not supported by their devices..

Best and TIA.
--

Hal - in Terra Alta, WV - Slackware GNU/Linux 9.0 (2.4.20-1)
..
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: USB Flash/Jump Drives-Linux??

At 09:03 AM 1/29/2005 -0500, Hal MacArgle wrote:


>Greetings: Running Slackware 9.0 and 9.1; kernels 2.4.20 or 2.4.22,
>bare.i installation, I've experienced good support for all USB
>devices except Flash Drives.
>
>First one bought was a Link-Max UL-641 that, plugged in, was
>immediately accessible by the kernel with no configuring by me..
>
>Later attempts with other brands, no such luck.. As I look at the
>retail boxes not a single one mentions Linux, so was wondering what
>others have discovered.. It's no fun buying then returning just to
>see what works or doesn't...
>
>Most of the comments on the Web seem to indicate this is not a
>problem but I've found otherwise.. One vendor, Kingston, said flat
>out that Linux is not supported by their devices..
>
>Best and TIA.


I've only used one of these drives, a Lexar 256 MB JunpDrive Secure. Since
I compile my own kernels, I did have to recompile (2.4.21, I think),
turning on several USB options and SCSI (the standard way to access USB
drives uses SCSI emulation), but then had no difficulty on my own systems
.... and a couple of embedded Linux systems, using their manufacturers'
stock kernels, also accessed the drive with no difficulty.

Since you don't include any details, I don't know if what was unusual about
your experience was the single success (say with a device that does not
require SCSI emulation somehow) or your several (few? many? you don't say)
failures.

Why not tell us more ... in particular, what devices you tried with and
failed, and how you accessed the Link-Max.




--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.7.4 - Release Date: 1/25/2005


-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: USB Flash/Jump Drives-Linux??

Ray Olszewski wrote:
> At 09:03 AM 1/29/2005 -0500, Hal MacArgle wrote:
>
>
>> Greetings: Running Slackware 9.0 and 9.1; kernels 2.4.20 or 2.4.22,
>> bare.i installation, I've experienced good support for all USB
>> devices except Flash Drives.
>>
>> First one bought was a Link-Max UL-641 that, plugged in, was
>> immediately accessible by the kernel with no configuring by me..
>>
>> Later attempts with other brands, no such luck.. As I look at the
>> retail boxes not a single one mentions Linux, so was wondering what
>> others have discovered.. It's no fun buying then returning just to
>> see what works or doesn't...
>>
>> Most of the comments on the Web seem to indicate this is not a
>> problem but I've found otherwise.. One vendor, Kingston, said flat
>> out that Linux is not supported by their devices..
>>
>> Best and TIA.
>
>
>
> I've only used one of these drives, a Lexar 256 MB JunpDrive Secure.
> Since I compile my own kernels, I did have to recompile (2.4.21, I
> think), turning on several USB options and SCSI (the standard way to
> access USB drives uses SCSI emulation), but then had no difficulty on my
> own systems ... and a couple of embedded Linux systems, using their
> manufacturers' stock kernels, also accessed the drive with no difficulty.
>

I have also had good success with my Lexar 128MB JumpDrive. Just tested my
brother's PNY Attache 128MB with a 2.6.10 kernel - works fine as well.

You may want to try a 2.6 kernel - Fedora core 3 or Slackware 10. A lot of USB
stuff has been merged into 2.6.

Jim
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: USB Flash/Jump Drives-Linux??

On 01-29, Ray Olszewski wrote:
> At 09:03 AM 1/29/2005 -0500, Hal MacArgle wrote:
>
>
> >Greetings: Running Slackware 9.0 and 9.1; kernels 2.4.20 or 2.4.22,
> >bare.i installation, I've experienced good support for all USB
> >devices except Flash Drives.
> >
> >First one bought was a Link-Max UL-641 that, plugged in, was
> >immediately accessible by the kernel with no configuring by me..
> >
> >Later attempts with other brands, no such luck.. As I look at the
> >retail boxes not a single one mentions Linux, so was wondering what
> >others have discovered.. It's no fun buying then returning just to
> >see what works or doesn't...
> >
> >Most of the comments on the Web seem to indicate this is not a
> >problem but I've found otherwise.. One vendor, Kingston, said flat
> >out that Linux is not supported by their devices..
> >
> >Best and TIA.
>
>
> I've only used one of these drives, a Lexar 256 MB JunpDrive Secure. Since
> I compile my own kernels, I did have to recompile (2.4.21, I think),
> turning on several USB options and SCSI (the standard way to access USB
> drives uses SCSI emulation), but then had no difficulty on my own systems
> .. and a couple of embedded Linux systems, using their manufacturers'
> stock kernels, also accessed the drive with no difficulty.
>
> Since you don't include any details, I don't know if what was unusual about
> your experience was the single success (say with a device that does not
> require SCSI emulation somehow) or your several (few? many? you don't say)
> failures.
>
> Why not tell us more ... in particular, what devices you tried with and
> failed, and how you accessed the Link-Max.

Greetings Ray, thanks for the input:

I only run Linux here but attempt to "help" neighbours with
their Windoze boxes so bought the 64mB drive in order to download
Winfiles on my machine and use the flash drive to sneaker net to
their machine.. Used to use floppies but the bloat!

The docos for the UL-641 said Linux 2.4.X and WinME up with
Win98SE needing an extra driver supplied on the drive.. It turned out
I could never get it recognized by two neighbour machines running
Win98SE, but that file worked with another running Win98FE..??.. I've
decided, since, then, that I know nothing about Windoze and,
probably, never will... Thinking it may have been the UL-641...

I bought another one made by Kingston and I discarded my
notes when the vendor said to contact Kingston techhelp who told me
their flash drive would not work with Linux - never/none... The other
one I tried same problem and I can't remember the mfgr.. I decided I
needed more info so hit the Web and most docos mention Linux supports
all USB drives, 2.4.X up, and all say that Win98SE needs an extra
driver.. The UL-641 says USB 1.0; 1.1 and 2.0 OK.. I think my older
machines are all 1.1, so I selected a flash drive that didn't mention
2.0 needed..

Anyway I plugged the UL-641 as received into this Linux box,
2.4 20, Slackware bare.i precompiled, and dmesg reported the drive as
/dev/sdb1.. Mounting sdb1, sure enough, there were the vfat files.. I
saved them to a CD thence reformatted the drive as ext2 - perfect.. I
had to do nothing except plug it in and mount..

Tried on another machine, same thing, with dmesg reporting
the device as sda1, because the former machine has other scsi
devices.. It was all automatic.. Both machines have ide-scsi default
because of using cdrecord and a CD Burner.. BTW Slack 9.0 and 9.1,
2.4.20 and 2.4.22, bare.i, precompile, support USB when booted..
Patrick has compiled that in the two versions I've used..

Now that I know a Lexar Jump Drive Secure, wonder what the
secure means? Has a write protect switch?, I will look one of them
up to try.. I'm presuming that Flash Drive, Jump Drive and many other
names are the same thing; memory card in an enclosure.. Very
confusing.. Before buying though, if possible, I will check
with Lexar - will I get the right answer??

Thanks again; appreciate!!

Hal - in Terra Alta, WV - Slackware GNU/Linux 9.0 (2.4.20-1)
..

-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: USB Flash/Jump Drives-Linux??

I have three thumb drives: MicroAdvantage Quickdrive 64Mb, Lexar
SecureMedia 512Mb and a 256Mb (forgot the make).

Anyway, I'm using 2.6.10. The kernel accesses all three of them just as
if they were normal drives (SCSI drives).

If your config is like mine, then you can just...

mount /dev/sda1 /mnt/ThumbDrive

I have this line in my fstab:

/dev/sda1 /mnt/FatDrive vfat noauto,exec,rw,user,umask=000 0 0

Linux treats it just like a normal SCSI drive. I can't remember what
options I enabled in the kernel.

Hal MacArgle wrote:
> On 01-29, Ray Olszewski wrote:
>
>>At 09:03 AM 1/29/2005 -0500, Hal MacArgle wrote:
>>
>>
>>
>>>Greetings: Running Slackware 9.0 and 9.1; kernels 2.4.20 or 2.4.22,
>>>bare.i installation, I've experienced good support for all USB
>>>devices except Flash Drives.
>>>
>>>First one bought was a Link-Max UL-641 that, plugged in, was
>>>immediately accessible by the kernel with no configuring by me..
>>>
>>>Later attempts with other brands, no such luck.. As I look at the
>>>retail boxes not a single one mentions Linux, so was wondering what
>>>others have discovered.. It's no fun buying then returning just to
>>>see what works or doesn't...
>>>
>>>Most of the comments on the Web seem to indicate this is not a
>>>problem but I've found otherwise.. One vendor, Kingston, said flat
>>>out that Linux is not supported by their devices..
>>>
>>>Best and TIA.
>>
>>
>>I've only used one of these drives, a Lexar 256 MB JunpDrive Secure. Since
>>I compile my own kernels, I did have to recompile (2.4.21, I think),
>>turning on several USB options and SCSI (the standard way to access USB
>>drives uses SCSI emulation), but then had no difficulty on my own systems
>>.. and a couple of embedded Linux systems, using their manufacturers'
>>stock kernels, also accessed the drive with no difficulty.
>>
>>Since you don't include any details, I don't know if what was unusual about
>>your experience was the single success (say with a device that does not
>>require SCSI emulation somehow) or your several (few? many? you don't say)
>>failures.
>>
>>Why not tell us more ... in particular, what devices you tried with and
>>failed, and how you accessed the Link-Max.
>
>
> Greetings Ray, thanks for the input:
>
> I only run Linux here but attempt to "help" neighbours with
> their Windoze boxes so bought the 64mB drive in order to download
> Winfiles on my machine and use the flash drive to sneaker net to
> their machine.. Used to use floppies but the bloat!
>
> The docos for the UL-641 said Linux 2.4.X and WinME up with
> Win98SE needing an extra driver supplied on the drive.. It turned out
> I could never get it recognized by two neighbour machines running
> Win98SE, but that file worked with another running Win98FE..??.. I've
> decided, since, then, that I know nothing about Windoze and,
> probably, never will... Thinking it may have been the UL-641...
>
> I bought another one made by Kingston and I discarded my
> notes when the vendor said to contact Kingston techhelp who told me
> their flash drive would not work with Linux - never/none... The other
> one I tried same problem and I can't remember the mfgr.. I decided I
> needed more info so hit the Web and most docos mention Linux supports
> all USB drives, 2.4.X up, and all say that Win98SE needs an extra
> driver.. The UL-641 says USB 1.0; 1.1 and 2.0 OK.. I think my older
> machines are all 1.1, so I selected a flash drive that didn't mention
> 2.0 needed..
>
> Anyway I plugged the UL-641 as received into this Linux box,
> 2.4 20, Slackware bare.i precompiled, and dmesg reported the drive as
> /dev/sdb1.. Mounting sdb1, sure enough, there were the vfat files.. I
> saved them to a CD thence reformatted the drive as ext2 - perfect.. I
> had to do nothing except plug it in and mount..
>
> Tried on another machine, same thing, with dmesg reporting
> the device as sda1, because the former machine has other scsi
> devices.. It was all automatic.. Both machines have ide-scsi default
> because of using cdrecord and a CD Burner.. BTW Slack 9.0 and 9.1,
> 2.4.20 and 2.4.22, bare.i, precompile, support USB when booted..
> Patrick has compiled that in the two versions I've used..
>
> Now that I know a Lexar Jump Drive Secure, wonder what the
> secure means? Has a write protect switch?, I will look one of them
> up to try.. I'm presuming that Flash Drive, Jump Drive and many other
> names are the same thing; memory card in an enclosure.. Very
> confusing.. Before buying though, if possible, I will check
> with Lexar - will I get the right answer??
>
> Thanks again; appreciate!!
>
> Hal - in Terra Alta, WV - Slackware GNU/Linux 9.0 (2.4.20-1)
> .
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.linux-learn.org/faqs
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: USB Flash/Jump Drives-Linux??

Hal MacArgle wrote:
> Greetings: Running Slackware 9.0 and 9.1; kernels 2.4.20 or 2.4.22,
> bare.i installation, I've experienced good support for all USB
> devices except Flash Drives.
>
> First one bought was a Link-Max UL-641 that, plugged in, was
> immediately accessible by the kernel with no configuring by me..
>
> Later attempts with other brands, no such luck.. As I look at the
> retail boxes not a single one mentions Linux, so was wondering what
> others have discovered.. It's no fun buying then returning just to
> see what works or doesn't...
>
> Most of the comments on the Web seem to indicate this is not a
> problem but I've found otherwise.. One vendor, Kingston, said flat
> out that Linux is not supported by their devices..
>
> Best and TIA.
Hi, Hal:

I have a SanDisk Cruzer micro (128 MB) and just plugged it into
3 systems running kernel-2.4.22 (Slackware 9.1) and
1 laptop running kernel-2.4.26 (Slackware 10.0)
and all reported a new USB device and
SCSI Emulation for Mass Storage Devices assigned it
sda:sda1

I think that 'hotplug' helps to accomplish this automagically.

So, these devices support USB and if your linux kernel
supports 'SCSI emulation' and USB, it should work.

I think.

HTH, Chuck


-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Abstract Control Module/Communications Device Class

Howdy, Everyone:

I am trying to get the DCE connection speed from the USB modem of my
mobile telephone. The cell phone is a LG vx6100 and I am using linux
kernel-2.4.26 and the acm.o module. With 'minicom' I can send AT
commands to the phone, but the Hayes AT command ATW2 returns "ERROR"
With 'pppd' I can establish a 'ppp' connection and browse the web
with the 'ppp0' device that is created.

I would like to find out if the 'AT command set' is part of the
mobile phone firmware or part of the 'acm.o' driver software.

Is there evidence of an 'AT command' to display DCE connect speed?

Regards, Chuck




-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: USB Flash/Jump Drives-Linux??

Greetings Ray, Chuck, Joshua and all who replied.. Apparently my
original problem was getting two flash/jump drives that "happened" to
not work with Linux.. So be it.

Anyway it seems, at least the Lexar brands are no problem and,
probably with kernel 2.6.X, the others might not be either.. At any
rate I visited the only "computer store" we have in this rural area
finding they stocked three Lexar models; one called "sport" the
others "secure." They also had an "Impact" 256mB that turned out to
be a Lexar sans the "secure?" software.. Plugged into this box it
works like a charm.. It was $10 less than the Lexar price but with a
90 day warranty vice sth like 4 years for the "genuine" Lexar...

We learn something every day, eh? APPRECIATE one and all..

Hal - in Terra Alta, WV - Slackware GNU/Linux 9.0 (2.4.20-1)

> Hal MacArgle wrote:
> >Greetings: Running Slackware 9.0 and 9.1; kernels 2.4.20 or 2.4.22,
> >bare.i installation, I've experienced good support for all USB
> >devices except Flash Drives.
> >
> >First one bought was a Link-Max UL-641 that, plugged in, was
> >immediately accessible by the kernel with no configuring by me..
> >
> >Later attempts with other brands, no such luck.. As I look at the
> >retail boxes not a single one mentions Linux, so was wondering what
> >others have discovered.. It's no fun buying then returning just to
> >see what works or doesn't...
> >
> >Most of the comments on the Web seem to indicate this is not a
> >problem but I've found otherwise.. One vendor, Kingston, said flat
> >out that Linux is not supported by their devices..
> >
> >Best and TIA.
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Delete /home/shared Samba directory; need better SSH solution!

We have people remotely SSH into our box from our overseas branch in India,
and I didn't want to create a home directory for every user at that branch.
So, I plopped them into /home/shared so they could view our network shares,
and therefore gain access to the folders for which they had permission
(having set up groups and put each user into a group). Yesterday, I ended up
deleting our Samba shares directory (/home/shared) because I was attempting
to get rid of a user; Linux prompted me if I wanted to get rid of that
user's files, and I hit ok without thinking, thereby wiping out most of our
network.

I'm slowly but surely restoring everything, but I'm wondering how to
approach remote SSH a bit more safely. I was thinking of having 1 SSH user
only for our users to work with.

Let me know if you require more information. OS is RedHat Linux 9, soon to
be upgraded to RH Enterprise WS 3.0.

- Eve


-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: Delete /home/shared Samba directory; need better SSH solution!

At 10:53 AM 2/9/2005 -0500, Eve Atley wrote:

>We have people remotely SSH into our box from our overseas branch in India,
>and I didn't want to create a home directory for every user at that branch.
>So, I plopped them into /home/shared so they could view our network shares,
>and therefore gain access to the folders for which they had permission
>(having set up groups and put each user into a group). Yesterday, I ended up
>deleting our Samba shares directory (/home/shared) because I was attempting
>to get rid of a user; Linux prompted me if I wanted to get rid of that
>user's files, and I hit ok without thinking, thereby wiping out most of our
>network.
>
>I'm slowly but surely restoring everything, but I'm wondering how to
>approach remote SSH a bit more safely. I was thinking of having 1 SSH user
>only for our users to work with.
>
>Let me know if you require more information. OS is RedHat Linux 9, soon to
>be upgraded to RH Enterprise WS 3.0.


All ssh itself provides you with is a way to connect over an insecure
network (the Internet) in a way that protects the content of the
transmissions from being read anyplace other than at the endpoints of the
connection. All the other security issues are no different from any other
login mechanism and are, really, matters of on-host security management.

Addressing those issues really is specific to the site and the contents of
what you are trying to protect, details I wouldn't even suggest you share
in this public a forum. But that said, I am (and others are) left only able
to offer generalities in the way of advice.

Having a single ssh user is, in my opinion, a bad idea. It means that you
have no accountability ... if a problem arises, you don't know who was
actually logged in at the time. And it means a single password is shared
among an unknown number of people, making any procedure for password
protection pretty much nonsense, and making the process of changing the
password cumbersome.

Were I to try to eal with your setup as I understand it, I'd do something
like this:

1. For each remote user, set up an individual shell account, with a good
password. (That is, don't do what your first sentence above says, despite
its having a superficial simplicity.) Then expect (demand) that each user
treat his or her userid/password information as confidential company
information to be protected by whatever standards the company usually uses.
And set up your system so ssh (including things tunneled through ssh, like
scp) is the ONLY way a user can connect to the system.

2. Put all these users into a group - I'll call it "india" for now".

3. For the files and directories you want these folks to have write access
to, make them mode 664 or 774 as appropriate, chgrp them to india, and let
them rely on group- rather than user-level access. Set these users' umasks
so files they upload have appropriate permissions.


-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

RE: Delete /home/shared Samba directory; need better SSH solution!

Thanks. Your advice makes sense, but allow me to give a bit more detail of
the current setup.

1. Those users for whom I do have an account set up (example: gagan) have
their own username/password.
2. FTP and Telnet has been disabled, so SSH is the only way they can access
our US server currently.
3. Those users, ie. gagan, that have a username/password, are currently
placed into the groups for which they have access (ie. marketing) and that
particular directory is owned by root with file group set to itself (ie.
marketing).
4. Each directory is set to 770, with owner/group having r/w/x bit set.

Now, you wrote:

3. For the files and directories you want these folks to have write
access
to, make them mode 664 or 774 as appropriate, chgrp them to india,
and let
them rely on group- rather than user-level access. Set these users'
umasks
so files they upload have appropriate permissions.

1. Based on this setup, would I still chgrp the directories to India?
2. I am not sure how to set umasks, but once I figure that out, I would then
set it directly on the user?

The question seems to have mutated; I appreciate your explanation of SSH as
a method by which to transmit securely over an insecure medium rather than
offering any true security of the machine itself. In rethinking this
strategy, I think assigning each user his/her own secure password needs to
be the norm, and when users ssh into the system they will just have to
navigate to the shared directory on their own. Any other suggestions are
appreciated.

Thanks,
Eve


-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

RE: Delete /home/shared Samba directory; need better SSH solution!

At 03:38 PM 2/10/2005 -0500, Eve Atley wrote:

>Thanks. Your advice makes sense, but allow me to give a bit more detail of
>the current setup.
>
>1. Those users for whom I do have an account set up (example: gagan) have
>their own username/password.
>2. FTP and Telnet has been disabled, so SSH is the only way they can access
>our US server currently.

I figured this (does anybody run telnet any more? at least not on systems
that connect to public networks, I hope ... I still use it occasionally on
isolated, benchtop setups to communicate between a workstation and an
embedded system, but even then only because the embedded system vendor only
offers telnet access), but I tend to err on the side of giving too much
info, not too little ... so I was mentioning that just in case.

>3. Those users, ie. gagan, that have a username/password, are currently
>placed into the groups for which they have access (ie. marketing) and that
>particular directory is owned by root with file group set to itself (ie.
>marketing).
>4. Each directory is set to 770, with owner/group having r/w/x bit set.
>
>Now, you wrote:
>
> 3. For the files and directories you want these folks to have write
>access
> to, make them mode 664 or 774 as appropriate, chgrp them to india,
>and let
> them rely on group- rather than user-level access. Set these users'
>umasks
> so files they upload have appropriate permissions.
>
>1. Based on this setup, would I still chgrp the directories to India?

That was only an example, and it was kind of based on the notion that the
users in question really needed only access to the shared directory you had
mentioned. If that is a misreading of your needs, then my suggestion was
bad (or at least incomplete) advice.

More generally, you use the file /etc/groups to associate users with groups
(a user can be in many groups this way in addition to his or her "home"
group as listed in /etc/passwd) and use that mechanism in whatever way is
appropriate to the details of your setup.

>2. I am not sure how to set umasks, but once I figure that out, I would then
>set it directly on the user?

Yes. Exacylt how to set this depends on how you set other attributes for a
user. For example, if your system use /etc/profile for standard user
characteristics, and /home///profile for user-specific settings,
you could set the umask in one of these places. "man umask" should give you
a page on the C function, but that includes the info on how to interpret
umask values (it's pretty obvious, just the inverse of mode ... e.g., a
umask of 022 sets the default mode to 755) .

>The question seems to have mutated; I appreciate your explanation of SSH as
>a method by which to transmit securely over an insecure medium rather than
>offering any true security of the machine itself. In rethinking this
>strategy, I think assigning each user his/her own secure password needs to
>be the norm, and when users ssh into the system they will just have to
>navigate to the shared directory on their own. Any other suggestions are
>appreciated.

I've never tried this, but maybe .bashrc could include a command to switch
the user to the shared directory immediately on login?


-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Linux Redhat Enterprise 3.0 = no support for firewire HD?

I have been tasked with adding a hot swap drive to our Redhat Linux 9 box as
our backup solution, then upgrading to Linux Enterprise 3.0. I'm researching
how best to format and mount these drives in Redhat 9 before upgrading. Then
I ran across this article:

Using the Granite Digital Firewire Drive Bay with Red Hat Linux
http://www.nber.org/sys-admin/granite-digital-linux.html

...and it states near the bottom,
"(Note added June 13, 2004) I have just "upgraded" our system to Red Hat
Enterprise Linux 3.0, and find that it has no support whatsover for firewire
hard drives. We were able to find some information about adding support at
Dell which seems to work. A recently obtained Fedora does have similar
support to RH9."

Can anyone verify if this is true? (!)

Thanks,
Eve


-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs