Thanks for the reply. I think we are making progress, see comments/questions interspersed below. Les Mikesell wrote: > 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. 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. >> 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). 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? > 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. 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? >> 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. Does anyone maintain webmin for Centos? I have most of the common repos hooked to yum, but webmin draws a blank. > 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. 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. > 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. > 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. >> 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. 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. > 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. Sounds like a great idea for a CentosPlus .rpm. >> 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. 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. Ted Miller