Re: Network FS w/o user setup

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



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

[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux