Ted Miller wrote:
Johnny Hughes wrote:
Well ... you would need to Join the "Samba Server" to your "Windows
Domain". If that domain is ADS (Active Directory Services) then it is
a different procedure than if it is a WinNT type Windows Domain.
This is getting well outside the range of complexity that I am looking
for. If I add more detail, maybe something more suitable to my
situation will suggest itself to members of the list.
1. This is a very small network, only one primary file server (office2).
A second file server (RAIDer1) has only one shared directory, so is not
really an issue.
2. Users log in primarily from Linux boxes, but have to run virtual
Windows machines for some software, and also log in from Windows laptops.
Virtual windows machines should be no different in terms of network
connections, so you can ignore that distinction.
3. office2 is set up with logins and home directories for all users, and
directories are permissioned such that users can run programs on office2
(if needed) and directory permissions work right.
Is samba running there? If so, you are mostly done.
4. Some users don't have physical machines, but only have virtual
machine(s) running on office2, which also need "network" access to
office2 files.
Again, nothing different.
Because all the users and permissions already exist on office2, I would
like those existing permissions to be reflected when the file system is
shared, just the same as when it is accessed locally. To restate: my
desire is that users, logins, and permissions be identical whether a
user is logged into office2 or whether that user is using a network file
share from another virtual or physical machine, running Linux or
Windows. I would think there would be a "market" for a network file
system where sharing a directory tree involved no more than assigning a
network share name to it. If (and only if) you had access to the file
locally, you now have access to it on the network. Very simple to
administer, very simple to understand--one set of permissions (kept
locally) works everywhere.
This mostly "just works" if you deal with a few complications that on a
small scale can be worked around without too much trouble. The first
complication is that you need to maintain passwords separately for Linux
and Windows because they are stored with different encryption. 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). 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. Windows/samba connections are treated as single users with
all access through that connection treated with the permissions of the
matching linux login. With samba in 'user' mode, the authentication is
done before you can even see the shares and even if you have multiple
shares mapped from the server they must all be as the same user. There
is also a 'share' mode where you authenticate separately per connection.
From everything I have heard, a windows domain controller would be more
work than it is worth for this size of project, as I am looking for
something machine-scale, not enterprise scale.
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. 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. There is also the
issue that users who have root access to their own workstation can
pretend to be any user over NFS. 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.
I hope this more clearly expresses my desires, even if only so that
everyone can tell me to keep dreaming, because what I want doesn't
exist--or in the open source tradition, quit dreaming and start coding.
(Unfortunately I am still working on my first C++ lesson book.)
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. Or it can be as complicated as running a separate
Active Domain controller. I've always been surprised that Linux
distributions didn't come with a pre-configured LDAP server that
automatically worked for local users and samba and could server other
Linux boxes as you add them without starting over, but so far I don't
think any provide that.
Sorry I neglected this (and all other) threads for a week or more, as I
had to learn how to do video editing to rescue an otherwise disastrously
unusable video project for my employer.
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.
--
Les Mikesell
lesmikesell@xxxxxxxxx
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
