Ted Miller wrote:
Is samba running there? If so, you are mostly done.
Yes, at the moment I have Samba running, but apparently not properly
configured. I am also in the process of moving this machine from Centos
4 to Centos 5, and am trying to do it better this time. At the moment
office2 is dual boot, still defaulting to C4.
I don't think there should be a big difference samba-wise.
If you aren't already using samba, you need to 'smbpasswd
-a username' for each user and input the password (or go around and
let them type it themselves).
Done at this point.
After this, a windows user mapping a samba-shared directory from your
office2 machine will have the same access as the same user logged in
locally. There are the same issues with directories that users share
with group permissions, but samba offers some extra options to force
owner/group/permissions on newly created files that will help.
That is something I need to fix, because I do have some issues with
group accessed files, where certain operations require me to log in as
root and run a script that cleans up the file ownership, otherwise some
users can no longer access the files. Any pointers on where to find
documentation on this?
Newly created files default to having the group ownership of the primary
group of the user creating it, and the RH scheme is to give every user
his own group. You can do something like this in the samba share
configuration:
valid users = @groupname
force group = groupname
force create mode = 0775
force directory mode = 0775
This will make new files have the right group and r/w (and executable,
which you might not want). If files are also created on the Linux side
you need to 'chmod g+s' on the directory to make new files take the
group of the directory.
You can find samba docs here:
http://us1.samba.org/samba/docs/man/Samba-HOWTO-Collection/
I have been using 'share' mode, but a little reading makes it sound like
I should switch to 'user' mode to make my life easier. I have been
adding various user permission lines to each share. Will they keep
working if I just comment out those lines?
Share vs. user doesn't make a difference in how things work after the
connection is established - it controls when authentication happens.
Share mode just lets you browse the share list before authenticating and
you can connect to different shares with different credentials.
You might look at webmin, since it has an option to maintain unix and
samba passwords at the same time and it can also keep multiple
machines in sync.
Does anyone maintain webmin for Centos? I have most of the common repos
hooked to yum, but webmin draws a blank.
This is one of the reasons I usually install k12ltsp instead of the
stock centos distribution (you don't lose anything, it just adds some
extras and makes the updates yummable). You probably can grab the RPM
directly from the webmin site.
The other complication is that if you also want to share files via
NFS, the permissioning mechanism is entirely different. NFS just
looks at the uid/gid/modes like a local file, so you need to make the
password files consistent across all the Linux boxes.
Does NFS work with windows? I have wasted considerable time on Google
trying to answer that question, and the only answer I find is that there
are commercial products that (for a per-seat fee) will connect windows
to NFS.
On windows you would use 'services for unix'. But I'd stick to samba.
> I read that NFS v.4 was supposed to "play better" with windows,
but I could not find any official comment, or windows drivers, or even
any recommendations of client only drivers.
Don't know about that.
There is also the issue that users who have root access to their own
workstation can pretend to be any user over NFS.
Not an issue in this situation, users do not have root access.
Do they have the same uid/gid, and group lists on their workstations as
on the file server?
For a single-user Linux workstation scenario, it might make more sense
to only provide samba shares and use cifs mounts instead of NFS. NFS
makes more sense between multiuser unix/linux boxes where only the
administrator(s) have root access.
That is what I did under C4, but with considerable frustration, but
maybe a simplified version of what I had (minus per-share permission
listing in smb.conf) would get me most of what I want.
If it is one user per workstation, treating it just like the windows
connections with samba should work.
I don't think you need to code anything since there are already
several options with varying degrees of complexity. Centralizing
authentication will help if you have many users and password changes.
But that can be as simple as turning on domain controller emulation on
samba on your office2 server and configuring everything else (windows
and Linux) to use it.
Any pointers to where I could learn the implications/pluses/minuses of
that? It might be useful with my multiple machines (real and virtual)
per user.
Samba authentication for linux just checks that a login/password match.
You still have to create the users and if you use NFS, make sure the
uid/gid's are all the same. For windows it works like a domain
controller and once you've logged in as a windows user, you
automatically authenticate to the samba shares as the same user and the
server can force login scripts to run on the client.
If these remote users are doing anything but video editing, another
useful option might be to use remote X logins or freenx/NX for a
remote Linux desktop directly from your office2 machine instead of
accessing its files on their workstation. How well it works depends
on what they are doing and the relative CPU and video use compared to
file access.
Video editing is getting done on a windows-native-boot laptop. Video
editing seems to be something that open source doesn't do very well.
I use a mac for the little I do, but I thought that
http://cvs.cinelerra.org/docs.php and http://lives.sourceforge.net were
supposed to be getting better.
--
Les Mikesell
lesmikesell@xxxxxxxxx
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos