>Second, the add user script on the first completely bypasses the normal
e-smith mechanisms and
>works for some users, while the add user script from the second one tries
to use the e-smith way and
>doesn't seem to work for anybody.
The method that you outline in your howto that "bypasses" the e-smith way of
doing things should work for 95%+ of users provided Samba is in fact
running as a PDC and two things happen on the client machine when joining
the domain:
1. The user MUST be logged on the Win NT/2000 machine as the administrator.
2. When prompted to authenticate addition the machine to the domain, the
user MUST input the root username and password. The e-smith admin account,
or any other for that matter, will not work.
If the user neglects to do either of the above, Windows will report a
totally unrelated error message and the machine will not be added to the
domain (This error message reported will likely get better over time as the
Samba team reverse engineers more and more of the Win 2000 RPC specs)
Further, I think the "bypass" approach is the better one as it seems more
inline with my understanding of the development path of Samba. It's my
understanding that the Samba team plans to build functionality into Samba to
remove machine accounts from smbpasswd and passwd when a machine leaves the
domain. I'm not very familiar with the scripts that Mitel has developed to
add machines accounts, but I would hate for these accounts to show up in the
server manager along with user accounts (as often happens with X Window user
account apps). It would really clutter things.
Regards,
Greg J. Zartman, P.E.
Vice-President
Logging Engineering International, Inc.
1243 West 7th Avenue
Eugene, Oregon 97402
541-683-8383 Fax 541-683-8144
Web: www.leiinc.com
-----Original Message-----
From: Gordon Rowell [mailto:[EMAIL PROTECTED]]
Sent: Friday, 21 September 2001 2:55 PM
To: Smith, Jeffery S (Scott)
Cc: Darrell May; Dan Brown; e-smith-devinfo
Subject: Re: [e-smith-devinfo] SME5 breaks RAV for some users
On Fri, Sep 21, 2001 at 05:42:30PM -0400, "Smith, Jeffery S (Scott)"
<[EMAIL PROTECTED]> wrote:
> Question: Does the qmail license allow for differentiation between
> distribution/installation and configuration?
IANAL, yes.
> If I install qmail as per "make install" and sell or distribute a system,
> this is obviously not a license violation.
IANAL, correct.
> Now, what happens if once this system is installed at a user's site, the
> user then elects to modify it so that qmail is not in a "make install"
> state? Has the user violated the license? Is this not allowed, perhaps to
> replace a script or binary with one of their own making, or to relocate a
> utility to another path?
Yes, users are completely at liberty to modify their own systems. The
restriction is on _distributing_ a modified qmail.
> If the above is not disallowed, then is it a license violation for an
> application installed by the user subsequent to qmail to make a similar
> modification?
I don't believe so. I believe that what RAV is doing is fine, as long
as the end-user chooses to install it. Bundling RAV (and thus bundling
a modification to qmail) would be a problem.
> If qmail is installed, and RAV is installed, and then the system
delivered,
> and then the user chooses to run an RPM that makes the two work
together --
> I fail to see how this is a problem. I can see the problem if the two
> packages and installed and integrated prior to distribution, but one in
the
> user's possession it seems odd that it would be any kind of license
> violation.
IANAL, but correct. The issue is _user_ choice. If a user chooses to
install something which modifies qmail, that is their choice.
> And, of course, I could be wrong. I'm mostly just curious as I've
> heard many times how restrictive the qmail license is.
Gordon
--
Gordon Rowell [EMAIL PROTECTED]
VP Engineering
Network Server Solutions Group http://www.e-smith.com
Mitel Networks Corporation http://www.mitel.com
--
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
--
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
