>but have yet included not those under
> discussion from Greg (no sleight intended, just a status update).
None taken...
Wow, alot happens when you leave the office for a day. You guys have been
busy!! :o)
I am very excited about working with your new RPM Gordon and will start
playing with it as soon as a I get a few fires put out. There are a few
existing issues that I would really like to re-emphasize.
1) The domain admins group parameter. Please don't take this the wrong way
Darrel, but I strongly believe that this parameter is defined incorrectly in
the current fragment. This parameter should point to a single group that
specifies those user who are admins of the DOMAIN, not local machine
administration account. On a Win NT/2000/XP "native" domain, the domain
admin is completely separate from the local machine administrator, as it
should be(you either log into the machine or the domain, not both). The
current fragment lists three machine admin accounts: administrator, admin,
and root. None of these accounts have any meaning as far as Domain
administration is concerned. They are local machine admin accounts. Take a
typical windows machine for example, as this is where 90% of my experience
is. You can not log on as the machine admin and the domain admin at the
same time. Well that's not 100% true. I can play around with accounts on a
specific machine so that the machine admin is also a domain admin, but this
isn't the standard.
If I log onto a windows client as root, what does it buy me? From windows
standpoint, root is just another user. I can't do any Unix side admin while
logged in on the windows client as root.
I believe this fragment should simply read:
domain admin group = domain_admins (or something like that)
This mirrors the current Microsoft Networks service.
2) add user script. This little guy has nearly gotten me banished from my
office. Yes, the current script works, but not all of the time. My
development guys are going nuts as they are developing a network admin app.
and are pulling machines on and off the domain frequently. After throwing
my hands up over this, I posted on one of the Samba mailing lists and
determined that the problem lies in this portion of the
machine-account-create script:
system("/usr/bin/passwd", "-l", "$machineName")
and warn("Could not lock password for $machineName\n");
system("/usr/bin/smbpasswd", "-a", "-m", "$machineName")
and warn("Could not create smb password entry for $machineName\n");;
Samba does both of these functions on it's own after a machine account is
successfully added to the passwd database. I updated my
machine-account-create script by pulling out these lines and adding the
necessary lines of code to add machines accounts to the e-smith account
database. After doing this, things are working better (at least the
software guys aren't complaining), but now I'm not "standard" with the rest
of the e-smith folks....
3) I haven't had a chance to study all of yours and Darrel's discussion
today, but I do what to say that in my opinion the smb.conf file should be
as simply as possible. I would like to see all of the comments, unused
parameters, and parameters that are set at samba defaults gone. It is SUCH
a pain to troubleshoot the current smb.conf file (This is not at all unique
to e-smith. SWAT causes the same problem) Once the fragments are expanded,
I believe that one should be able to go look at the config file that Samba
will see without having to wade through a duplication of all of the
information listed in the smb.conf fragments. Here is how I think the
smb.conf file should look:
[11workgroup]
workgroup = workgroup
[12adduser]
add user script =
and so on....
With this, I could easily step down through my smb.conf file. If I spot an
error with a given parameter, the fragment name is right there for me to go
in and fix.
Incidentally, I feel that I could quite easily write a perl script that
could verify if a given fragment duplicates a default value in samba. I
think it would be quite easily to structure this as a function that could be
called when the fragments are being expanded.
Looking forward to digging into this new rpm...
Regards,
Greg J. Zartman
LEI
--
Please report bugs to [EMAIL PROTECTED]
Please mail [EMAIL PROTECTED] (only) to discuss security issues
Support for registered customers and partners to [EMAIL PROTECTED]
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Archives by mail and http://www.mail-archive.com/devinfo%40lists.e-smith.org
