Hi, I currently manage an environment where my Unix and Windows usernames are defined, but different. So, I must use a username map. But I have several Samba servers (one for each NFS package) and I must maintain all these username map files. As we want everybody to map the same way on every Samba servers in a NIS domain, we added the 'Windows user' information to the NIS 'passwd' map (by adding a string like '<win=xxx>' to the gecos field). Now, as the only way for Samba to get this mapping information is through a flat file, I have to push this file onto every samba server every time I build the NIS passwd map. And, in order to do that, I must maintain a list of these servers on the NIS master server (assuming a standard path for storing this file on each samba server). Instead of such a 'push' solution, I would much prefer a 'pull' one. The only way I found, with the current Samba implementation, would be to write an NSS module which would only implement the getpwnam function. I started looking at this solution but we quickly decided not to go further because of the problems of maintainability of such a piece of code. Another solution, much easier to implement, would be to modify the code in map_username(), so that, if the 'username map' file has the executable bit set, it would be executed instead of being parsed, and it would give an answer on stdout (with an empty value if no mapping found). This way, there is no change in Samba configuration. The only potential incompatibility would be if a current username map file has the executable bit set, although it is a plain file, once the user updates Samba to the new version, it would start executing the file. In order to remove this incompatibility, we could add a 'execute username map' option... What do you think about this change ? I can send a patch for it, but it is very easy to implement with a call to smbrun(). Regards, Fran?ois
On Thu, Jul 21, 2005 at 04:29:36PM +0000, Fran?ois LAUPRETRE wrote:> > What do you think about this change ? I can send a patch for it, but it is very > easy to implement with a call to smbrun().Hmmmm. How much demand is there for this from others ? I agree it would need another parameter to enable it (so it doesn't happen by accident). If it's really easy can you send in a patch and let's look at it. Thanks, Jeremy.
> From: Gerald (Jerry) Carter [mailto:jerry@samba.org] > > I *really* don't like this. It's fine for a local hack > and probably a good solution in this case, but this will > bit rot in the tree so fast due to its very specific and > non-intuitive nature. > > A better general solution that would apply to more > networks would to allow the username map to be stored > in a directory services such as NIS or LDAP. > > If you want a pull based method, just have a cron job > on each server that rebuilds the file every 10 minutes. > No code changes necessary.Yes, in my case, I can easily generate a new NIS map, if Samba becomes able to read the mappings from it. And this solution would be perfect in my case. But, I thought that allowing an external program to provide the mappings with its own logic would be a better solution, as it solves a much greater range of cases. Example : - if the information lies outside of NIS or LDAP, I have to add a push mechanism to update NIS or LDAP anytime I change my reference data. Or a cron job, as you suggest :( - if I cannot easily generate a map, for any reason. A rather simple case (just as an example) : if I want to give a Unix mapping to a Windows username only if his corresponding Unix home directory is viewable (through the automounter) from the Samba host. I also could use an external mechanism (maybe another NIS map) to restrict access to the Samba servers in my domain. And there are still many cases where the logic of pushing a plain list cannot be used (without cron jobs, again). In short, I think that the solution of getting the map from NIS or LDAP is a good one, but, if Samba could execute an external script to resolve the mappings, it would be much more general, not so complicated for the users, and easier to implement in the Samba code (and to document). It would also necessitate only one new configuration parameter. Regards Fran?ois -------------- next part -------------- Ce message et ses pi?ces jointes (le "message") est destin? ? l'usage exclusif de son destinataire. Si vous recevez ce message par erreur, merci d'en aviser imm?diatement l'exp?diteur et de le d?truire ensuite. Le pr?sent message pouvant ?tre alt?r? ? notre insu, CALYON Corporate and Investment Bank ne peut pas ?tre engag? par son contenu. Tous droits r?serv?s. This message and/or any attachments (the "message") is intended for the sole use of its addressee. If you are not the addressee, please immediately notify the sender and then destroy the message. As this message and/or any attachments may have been altered without our knowledge, its content is not legally binding on CALYON Corporate and Investment Bank. All rights reserved.
> ----- Message from Fran?ois LAUPRETRE <francois.laupretre@calyon. > com> on Thu, 21 Jul 2005 16:29:36 +0000 (UTC) ----- > > To: > > samba@lists.samba.org > > Subject: > > [Samba] Executable 'username map' > > Hi, > > I currently manage an environment where my Unix and Windows usernames are> defined, but different. So, I must use a username map. But I have > several Samba > servers (one for each NFS package) and I must maintain all these usernamemap> files. As we want everybody to map the same way on every Samba > servers in a NIS > domain, we added the 'Windows user' information to the NIS 'passwd' map(by> adding a string like '<win=xxx>' to the gecos field). > > Now, as the only way for Samba to get this mapping information is througha> flat file, I have to push this file onto every samba server every > time I build > the NIS passwd map. And, in order to do that, I must maintain a listofthese> servers on the NIS master server (assuming a standard path for storingthis> file on each samba server). >Seems like a lot of trouble to maintain all those separate username map files. Why not just use a single copy of the file and nfs mount it via automounting so that all your Samba servers read the same file, then you only have to update a single file and all your Samba servers see the changes immediately. No push necessary. Regards, Arnold Andrews Sr. Systems Administrator Seagate Technology
I am sorry but I don't have a patch and, as I am on holiday out of home from tomorrow, I won't work on it before mid-august. And I don't know very well the Samba coding practice concerning portability. But, if it is not done when I'm back, I send you a patch. Basically, I would run the command via smbrun(), connected to a pipe(), with anything from stderr going to the smbd log. The first line of stdout would contain the result. An empty stdout would mean that the username cannot be mapped (like for autofs executable maps). We also have two choices for the 'username map' parameter when 'username map script' is set : either it is ignored, or it is parsed after the script, but only if the script didn't return anything. Up to you. Regards Fran?ois> -----Original Message----- > From: Gerald (Jerry) Carter [mailto:jerry@samba.org] > Sent: Friday, July 22, 2005 3:26 PM > To: Laupretre, Fran?ois (CALYON); Jeremy Allison > Subject: Re: RE : [Samba] Executable 'username map' > > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Fran?ois Laupretre wrote: > > > In short, I think that the solution of getting the map from > > NIS or LDAP is a good one, but, if Samba could execute > > an external script to resolve the mappings, it would be > > much more general, not so complicated for the > > users, and easier to implement in the Samba code (and > > to document). It would also necessitate only one new > > configuration parameter. > > Fran?ois, > > I actually retracted my initial statement last night. > Adding a 'username map script' is a flexible solution > to solving the directory integration problem. If you > have a patch, go ahead and send it to me or I can code > this up later today. > > > > cheers, jerry > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.0 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org > > iD8DBQFC4PQFIR7qMdg1EfYRAjQOAKCMu77nMoRCjka9bBmyLDOKq7PfdACfYqNf > PaMzoqwRqfKnRJZcpH1tYOI> =SdaT > -----END PGP SIGNATURE----- >-------------- next part -------------- Ce message et ses pi?ces jointes (le "message") est destin? ? l'usage exclusif de son destinataire. Si vous recevez ce message par erreur, merci d'en aviser imm?diatement l'exp?diteur et de le d?truire ensuite. Le pr?sent message pouvant ?tre alt?r? ? notre insu, CALYON Corporate and Investment Bank ne peut pas ?tre engag? par son contenu. Tous droits r?serv?s. This message and/or any attachments (the "message") is intended for the sole use of its addressee. If you are not the addressee, please immediately notify the sender and then destroy the message. As this message and/or any attachments may have been altered without our knowledge, its content is not legally binding on CALYON Corporate and Investment Bank. All rights reserved.
Seemingly Similar Threads
- computing differences between consecutive vector elements
- Many "Error: Corrupted index cache file /XXX/dovecot.index.cache: invalid record size"
- using Rterm under cygwin, no possiblity to delete characters
- sshd accepted fingerprint logging
- Inverse Prediction with splines