Table of Contents
+ + +Samba works on a wide range of platforms, but the interface all the +platforms provide is not always compatible. This chapter contains +platform-specific information about compiling and using Samba.
+
+
+Hewlett-Packard's implementation of supplementary groups is nonstandard (for
+historical reasons). There are two group files, /etc/group and
+/etc/logingroup; the system maps UIDs to numbers using the former, but
+initgroups() reads the latter. Most system admins who know the ropes
+symlink /etc/group to /etc/logingroup
+(hard-link does not work for reasons too obtuse to go into here). initgroups() will complain if one of the
+groups you're in, in /etc/logingroup, has what it considers to be an invalid
+ID, which means outside the range [0..UID_MAX], where UID_MAX is
+60000 currently on HP-UX. This precludes -2 and 65534, the usual nobody
+GIDs.
+
+If you encounter this problem, make sure the programs that are failing +to initgroups() are run as users, not in any groups with GIDs outside the +allowed range. +
+This is documented in the HP manual pages under setgroups(2) and passwd(4). +
+ + +On HP-UX you must use gcc or the HP ANSI compiler. The free compiler +that comes with HP-UX is not ANSI compliant and cannot compile Samba. +
+If you run an old version of SCO UNIX, you may need to get important +TCP/IP patches for Samba to work correctly. Without the patch, you may +encounter corrupt data transfers using Samba. +
+The patch you need is UOD385 Connection Drivers SLS. It is available from +SCO ftp.sco.com, directory SLS, +files uod385a.Z and uod385a.ltr.Z). +
+The information provided here refers to an old version of SCO UNIX. If you require +binaries for more recent SCO UNIX products, please contact SCO to obtain packages that are +ready to install. You should also verify with SCO that your platform is up to date for the +binary packages you will install. This is important if you wish to avoid data corruption +problems with your installation. To build Samba for SCO UNIX products may +require significant patching of Samba source code. It is much easier to obtain binary +packages directly from SCO. +
+DNIX has a problem with seteuid() and setegid(). These routines are +needed for Samba to work correctly, but they were left out of the DNIX +C library for some reason. +
+For this reason Samba by default defines the macro NO_EID in the DNIX +section of includes.h. This works around the problem in a limited way, +but it is far from ideal, and some things still will not work right. +
+To fix the problem properly, you need to assemble the following two
+functions and then either add them to your C library or link them into
+Samba. Put the following in the file setegid.s:
+
+ .globl _setegid +_setegid: + moveq #47,d0 + movl #100,a0 + moveq #1,d1 + movl 4(sp),a1 + trap #9 + bccs 1$ + jmp cerror +1$: + clrl d0 + rts +
+Put this in the file seteuid.s:
+
+ .globl _seteuid +_seteuid: + moveq #47,d0 + movl #100,a0 + moveq #0,d1 + movl 4(sp),a1 + trap #9 + bccs 1$ + jmp cerror +1$: + clrl d0 + rts +
+After creating the files, you then assemble them using +
+$as seteuid.s+$as setegid.s+
+which should produce the files seteuid.o and
+setegid.o.
+
+Next you need to add these to the LIBSM line in the DNIX section of +the Samba Makefile. Your LIBSM line will look something like this: +
+LIBSM = setegid.o seteuid.o -ln +
+You should then remove the line: +
+#define NO_EID +
from the DNIX section of includes.h.
+By default during installation, some versions of Red Hat Linux add an
+entry to /etc/hosts as follows:
+
+127.0.0.1 loopback "hostname"."domainname" +
+
+ +This causes Samba to loop back onto the loopback interface. +The result is that Samba fails to communicate correctly with +the world and therefore may fail to correctly negotiate who +is the master browse list holder and who is the master browser. +
+Corrective action: Delete the entry after the word "loopback" +in the line starting 127.0.0.1. +
+Disabling sequential read ahead using vmtune -r 0 improves
+Samba performance significantly.
+
Some people have been experiencing problems with F_SETLKW64/fcntl +when running Samba on Solaris. The built-in file-locking mechanism was +not scalable. Performance would degrade to the point where processes would +get into loops of trying to lock a file. It would try a lock, then fail, +then try again. The lock attempt was failing before the grant was +occurring. The visible manifestation of this was a handful of +processes stealing all of the CPU, and when they were trussed, they would +be stuck in F_SETLKW64 loops. +
+Please check with Sun support for current patches needed to fix this bug. +The patch revision for 2.6 is 105181-34, for 8 is 108528-19, and for 9 is 112233-04. +After the installation of these patches, it is recommended to reconfigure +and rebuild Samba. +
Thanks to Joe Meslovich for reporting this.
+Nsswitch on Solaris 9 refuses to use the Winbind NSS module. This behavior +is fixed by Sun in patch 112960-14. +