samba - Oct 2008 - Compile help for Solaris 10 x86, samba 3.0.28a deficient?

Hi all,

I've got an ongoing battle with samba shipped with Sun Solaris 10 in  
it's current form (Samba version 3.0.28a) not wanting to talk to my  
OpenLDAP master correctly. Essentially, under certain conditions, this  
behaviour is observed, in the log.smbd:

[2008/10/11 08:54:03, 1, pid=13610] libsmb/cliconnect.c:(1451)
   Error connecting to 192.168.117.150 (Connection refused)
[2008/10/11 08:54:03, 0, pid=13610] auth/auth_server.c:(89)
   password server not available
[2008/10/11 08:54:03, 1, pid=13610] auth/auth_server.c:(247)
   password server is not connected (cli not initilised)

So, I went about logging this at a much more verbose level, which  
hasn't really gotten me anywhere. I can't find an answer to what these  
errors actually mean - and the only google hits on this specific  
problem are my own posts.

I thought, "What if they have changed the way SPNEGO works in Mac OS X  
10.5.5's implementation of their directory/kerberos KDC?"

I then thought that maybe Samba 3.0.28a (only a hunch, no way to prove  
it) just wasn't up to the task, and that I should try compiling 3.2.4  
for my hosts. I gave it a good shot. A really good shot - been at it  
for a week now, with no joy. Thanks to all those here who have tried  
to help out with it too!

I am looking for some very basic instructions with regard to compiling  
samba. I want to compile Samba for Solaris 10 x86, with krb5 support,  
with aio support. I don't really want or need ADS.

Unfortunately, try as I might, just hasn't panned out this way. Every  
step of the way, something has gone wrong.

If someone could help me out from first principles with the basics,  
such as the "influential environmental variables" :

   CC          C compiler command
   CFLAGS      C compiler flags
   LDFLAGS     linker flags, e.g. -L<lib dir> if you have libraries in a
               nonstandard directory <lib dir>
   LIBS        libraries to pass to the linker, e.g. -l<library>
   CPPFLAGS    C/C++/Objective C preprocessor flags, e.g. -I<include  
dir> if
               you have headers in a nonstandard directory <include dir>
   CPP         C preprocessor

...and actually getting Solaris default/vanilla krb5 to configure,  
make, make install correctly when one specifies --with-krb5=/usr/lib/ 
krb5, this would be most appreciated. Not even sure if I should be  
using Sun Studio compiler or GCC.

I sort of hoped that somebody would release pre-built binaries for Sol  
10 x86, unfortunately, all I can find on samba.org is a long way out  
of date SPARC binary of 3.0.23.

Thanks for your time.

JC

On Sunday 12 October 2008 07:55:01 Jake Carroll wrote:
> I sort of hoped that somebody would release pre-built binaries for Sol
> 10 x86, unfortunately, all I can find on samba.org is a long way out
> of date SPARC binary of 3.0.23.
There are Blastwave x86 packages out there. If you have searched the old posts 
on this list, you should have found that maintainer (Dennis Clarke) even 
posted links here on the list.

Here you go:

Samba 3.0.31:
http://www.blastwave.org/testing/samba-3.0.31,REV=2008.08.22-SunOS5.8-i386-CSW.pkg.bz2

Samba 3.2.2:
http://www.blastwave.org/testing/samba-3.2.2,REV=2008.08.22-SunOS5.8-i386-CSW.pkg.gz

I don't know if the links are still functional.



-- 
|    Jakov Sosic    |    ICQ: 28410271    |   PGP: 0x965CAE2D   |
================================================================| start fighting
cancer -> http://www.worldcommunitygrid.org/   |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url :
http://lists.samba.org/archive/samba/attachments/20081012/25c9c40e/attachment.bin

> Hi all,
see http://www.blastwave.org/testing/

you will find 3.0.32 and 3.2.2 there

If you want to work on this together, sounds great, come over to Blastwave
and we can sort this out. I can tell you that building Samba on Solaris is
a miserable experience, a lonely miserable wretched task.

but .. you already know that :-\

I do too.

One has to wonder how code that is written in C can be moving towards such
poor portability that it compiles in the linux world but not the unix
world.
I'd be happy to discuss that .. and whatever else is needed for a nice
stable package .. but not here.

please see http://wiki.blastwave.org and click "join us" such that we
can
suffer through this process together.

Dennis Clarke

ps: I am working on the samba packages here .. hence the misery

> On Sunday 12 October 2008 07:55:01 Jake Carroll wrote:
>
>> I sort of hoped that somebody would release pre-built binaries for Sol
>> 10 x86, unfortunately, all I can find on samba.org is a long way out
>> of date SPARC binary of 3.0.23.
>
> There are Blastwave x86 packages out there. If you have searched the old
> posts
> on this list, you should have found that maintainer (Dennis Clarke) even
> posted links here on the list.
>
> Here you go:
>
> Samba 3.0.31:
>
http://www.blastwave.org/testing/samba-3.0.31,REV=2008.08.22-SunOS5.8-i386-CSW.pkg.bz2
>
> Samba 3.2.2:
>
http://www.blastwave.org/testing/samba-3.2.2,REV=2008.08.22-SunOS5.8-i386-CSW.pkg.gz
>
> I don't know if the links are still functional.
>
They function .. always have .. always will .. until we release them to
all the mirrors.

The poor man should work with me .. sounds like we have both worked in
lonely miserable long nights and days and wondered why we were being
punished, what sins had we committed that we deserved this.

yes .. it is that bad.

Dennis

> On Sun, Oct 12, 2008 at 07:50:33AM -0400, Dennis Clarke wrote:
>> see http://www.blastwave.org/testing/
>>
>> you will find 3.0.32 and 3.2.2 there
>>
>> If you want to work on this together, sounds great, come over to
>> Blastwave
>> and we can sort this out. I can tell you that building Samba on Solaris
>> is
>> a miserable experience, a lonely miserable wretched task.
>
> Wait a second -- at least we try to keep our build farm
> hosts happy. At this very moment, the build is broken, but
> I've already checked in a fix.
>
> If you have necessary patches, please send them to
> samba-technical. The packaging/Solaris subdirectory is
> pretty much orphaned, it could really benefit from some
> care.
I'd be happy to fill it with a samba package or a set. Keep in mind that
any such package will require dependencies and I may come up with
something standalone that "just works" with only one package being
installed.

I have some thoughts on that ... but anyways .. I'd be happy to help with
that poor forgotten orphan.

Dennis

> On Sun, Oct 12, 2008 at 12:26:36PM -0400, Dennis Clarke wrote:
>> I'd be happy to fill it with a samba package or a set. Keep in mind
that
>> any such package will require dependencies and I may come up with
>> something standalone that "just works" with only one package
being
>> installed.
>>
>> I have some thoughts on that ... but anyways .. I'd be happy to
help
>> with
>> that poor forgotten orphan.
>
> You're very welcome. You might want to look at
>
> http://wiki.samba.org/index.php/Using_Git_for_Samba_Development
>
> If you send in patches in git format, you get the credits in
> "git log" and "git blame" :-)
Looks like a good idea .. guess what my first job is? You guessed it ! I
have to port git to Solaris !  What fun :-)

-- 
Dennis Clarke

> On Sun, Oct 12, 2008 at 03:58:00PM -0400, Dennis Clarke wrote:
>> > If you send in patches in git format, you get the credits in
>> > "git log" and "git blame" :-)
>>
>> Looks like a good idea .. guess what my first job is? You guessed it !
I
>> have to port git to Solaris !  What fun :-)
>
> Well, you can always send patches raw. But then you don't
> get the blamecredits :-)
nah .. where is the fun in that ?

Solaris people will want a functional git anyways .. so I may as well get
that into the catalog here.

My real issue with samba is the nasty errors I get during linkage. With
GCC 4.3.2 I see this :

.
.
.
mkdir bin
mkdir lib/talloc
Compiling lib/talloc/talloc.c
Linking non-shared library bin/libtalloc.a
mkdir lib/replace
Compiling lib/replace/replace.c
Compiling lib/replace/snprintf.c
Compiling lib/replace/getpass.c
Compiling lib/replace/strptime.c
Compiling lib/replace/timegm.c
Compiling lib/replace/inet_aton.c
Compiling lib/replace/getifaddrs.c
creating
/export/nfs/build/samba-3.2.3-build/../samba-3.2.3/source/exports/libtalloc.syms
Linking shared library bin/libtalloc.so.1
ld: warning: option -o appears more than once, first setting taken
Text relocation remains                         referenced
    against symbol                  offset      in file
_init                               0x34       
/export/home/dclarke/local/lib/gcc/sparc-sun-solaris2.8/4.2.4/crt1.o
main                                0x5c       
/export/home/dclarke/local/lib/gcc/sparc-sun-solaris2.8/4.2.4/crt1.o
_fini                               0x24       
/export/home/dclarke/local/lib/gcc/sparc-sun-solaris2.8/4.2.4/crt1.o
_fini                               0x28       
/export/home/dclarke/local/lib/gcc/sparc-sun-solaris2.8/4.2.4/crt1.o
exit                                0x64       
/export/home/dclarke/local/lib/gcc/sparc-sun-solaris2.8/4.2.4/crt1.o
_environ                            0x50       
/export/home/dclarke/local/lib/gcc/sparc-sun-solaris2.8/4.2.4/crt1.o
_environ                            0x54       
/export/home/dclarke/local/lib/gcc/sparc-sun-solaris2.8/4.2.4/crt1.o
atexit                              0x1c       
/export/home/dclarke/local/lib/gcc/sparc-sun-solaris2.8/4.2.4/crt1.o
atexit                              0x2c       
/export/home/dclarke/local/lib/gcc/sparc-sun-solaris2.8/4.2.4/crt1.o
_exit                               0x6c       
/export/home/dclarke/local/lib/gcc/sparc-sun-solaris2.8/4.2.4/crt1.o
ld: fatal: relocations remain against allocatable but non-writable sections
collect2: ld returned 1 exit status
make: *** [bin/libtalloc.so.1] Error 1

sometimes the process feels very voodoo spooky because I am quite careful
with compiler options. With Sun Studio 11 I get the same sort of error
message but with less detail.

quite annoying.

Dennis