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:[EMAIL PROTECTED] Sent: Friday, June 10, 2005 6:07 AM To: [EMAIL PROTECTED]; 'M Maki'; samba@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. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba