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