[Samba] Re: Problems with Samba and Windows 2003 ActiveDomainServer

[Mark A. Holm]

Not getting enough cycles to actually work on this, so I have to apologize for the slow turn. On the larger client I had every
intention of setting up an internal YUM or Apt server for doing the updates from approved and tested packages. I have also found in
most cases that the packaged binaries usually had almost everything compiled in, with the exception of Amanda. As you said though,
they are always a bit behind the curve. 

I tried your suggestion of getting the latest RPM from samba.org for Fedora and it doesn't change the behavior any. There has got to
be something else in this setup that is still wrong. I just can't find it. It's got to be something simple, as everything works
except the last step, and it partially works for the groups. Is there something that needs to be changed on the windows server side
regarding permissions or domain settings? Is there an LDAP component that needs to be configured? I keep seeing references to the
LDAP components of Samba, but no steps for configuration needed on the client/member server.

	markh

-----Original Message-----
From: Paul Gienger [mailto:pgienger at ae-solutions.com] 
Sent: Friday, June 10, 2005 6:07 AM
To: markh at infoarch.com; 'M Maki'; samba at lists.samba.org
Subject: RE: [Samba] Re: Problems with Samba and Windows 2003 ActiveDomainServer

>Has anybody been able to make this work using the distributed packages from
>the Fedora distribution or SuSE?

Most of the time the distro packages are compiled with the kitchen sink
included so you can get just about anything working.  Maybe you could shoot
a note back to your distro's builders asking why SuperCoolOption isn't built
in?  The stock Fedora rpm worked fine for our needs (ldap) but we've moved
away from them since they didn't update fast enough.  Still sticking with an
rpm build from the samba.org specfile, which btw, does seem to have ADS
built in.


> going to be. I have another client that is looking at
> deploying approximately 200 workstations. If I have to hand compile each
> new machine, these will take a lot longer to deploy, even
> with scripting and a centralized distribution server.

If you have any decent sized linux (or any OS deployment really), it helps
if you have some sort of internal deployment server.  It also helps if you
use the package manager that came with your system rather than compiling
everything as a source file with "./configure ; make ; make install."  RPM
may have its problems, or people just like to whine about it, but for gods
sake it's built in, and 99% of the time it works.  

With our fedora servers we have an internal yum server.  To deploy a package
to any number of systems it's not too difficult:

1. Build rpm package
2. Place it in the repository and run the yum repo update command.
3. Either of 2 things to get it installed
  a. If this is an update or special version of a package, wait till the
nightly update comes and gets it.
  b. if this is a new package, go to the system and run "yum install
mysupercoolpackage

I am taking for granted that you've got your machines already configured for
your internal repository, since of course, that's the whole point: to show
how easy it is to install things if you've got the infrastructure set to use
it.  Actually creating an internal server is fairly easy if you follow the
documentation.

I'm also just talking Fedora, I'd be surprised if SuSE didn't have something
similar, I'm ignoring the rest of the world since you only mentioned SuSE
and Fedora.