a couple of design/implementation questions (resent)

Samir Girdhar samir at cs.toronto.edu
Mon Oct 4 23:19:39 GMT 1999


[hmm, my first attempt to post didn't make it to this list...]

Hi,

#include <first_post.h>
#include <kudos_for_great_sw.h>

Apologies if this isn't the best list to post these questions/comments
to but they seemed too general for ntdom and too low-level for the main
samba list.

I've pretty much finished implementing PDC support via samba (2.0.5a)
and fully integrating it into our unix environment, complete with
password synchronization going in both directions, etc., etc..

Looking back at the implementation, however, there's a couple of niggly
things that I don't like so I thought I'd ask about 'em here....

1) Samba client utils (unix)

   Why is it that these utils (esp. smbpasswd) need to be able to read
   smb.conf?

   My motivation is that I have a RAID system and a Samba server and I
   want the Samba server to not rely on anything that is NFS-mounted for
   day-to-day operation.  Clients are all either NT or un*x.

   In my original implementation, samba was built with
   "--prefix=/nfs/exported/directory/on/raid" and I'd hacked the Makefile
   so that CONFIGFILE = $(PRIVATEDIR)/smb.conf.  However, the unix client
   utils broke because they couldn't read the config file.

   (As an aside, given that smbpasswd is reading smb.conf, why does it
    still default to 127.0.0.1 when looking for smbd instead of what's
    actually in the smb.conf under "netbios name"?)

   What I've ended up doing is maintaining smb.conf in $(prefix)/lib/
   (nfs exported), manually dropping the current version into
   $(PRIVATEDIR), and starting the daemons with the "-s" flag.

   My issue now is that when my (home-grown) unix passwd program calls
   smbpasswd to change the samba password for the user, there is a
   dependency on this nfs-mounted directory, just to read smb.conf
   (and apparently ignore the contents).

   The motivation for this question is eliminating that dependency (I
   could obviously roll up a new smbpasswd with a different config but
   that feels too kludgey and I was looking for a more elegant solution).

   I concede that there may be very good reasons for smbpasswd to read
   smb.conf and that my configuration is just not esoteric enough to
   require them.

2) smbpasswd -d

   Our rmuser scripts will run "smbpasswd -d" to disable users' Samba
   accounts and I want to write something that will remove the entries
   that have been marked as disabled (probably with sed or somesuch).

   I was wondering if there is some lockfile I should create so that
   smbd or smbpasswd don't come along and update a user's password or
   something while I'm rewriting smbpasswd without the disabled users.
   (I couldn't find any evidence of locking mechansims, file-based or
    otherwise while perusing the code but that could just be because I
    wasn't looking in the right place(s)).

   Even better, IMO, would be an option to smbpasswd that would actually
   do the deletion for me....


Cheers!
Samir



More information about the samba-technical mailing list