1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
|
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [
<!ENTITY % global_entities SYSTEM '../entities/global.entities'>
%global_entities;
]>
<chapter id="Portability">
<chapterinfo>
&author.jelmer;
&author.jht;
<!-- Some other people as well, but there were no author names in the text files this file is based on-->
</chapterinfo>
<title>Portability</title>
<para>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.</para>
<sect1>
<title>HPUX</title>
<para>
HP's implementation of supplementary groups is non-standard (for
historical reasons). There are two group files, <filename>/etc/group</filename> and
<filename>/etc/logingroup</filename>; the system maps UIDs to numbers using the former, but
initgroups() reads the latter. Most system Admins who know the ropes
symlink <filename>/etc/group</filename> to <filename>/etc/logingroup</filename>
(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 <filename>/etc/logingroup</filename> has what it considers to be an invalid
ID, which means outside the range <constant>[0..UID_MAX]</constant>, where <constant>UID_MAX</constant> is (I think)
60000 currently on HP-UX. This precludes -2 and 65534, the usual <constant>nobody</constant>
GIDs.
</para>
<para>
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.
</para>
<para>This is documented in the HP manual pages under setgroups(2) and passwd(4).
</para>
<para>
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.
</para>
</sect1>
<sect1>
<title>SCO UNIX</title>
<para>
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.
</para>
<para>
The patch you need is UOD385 Connection Drivers SLS. It is available from
SCO (<ulink noescape="1" url="ftp://ftp.sco.com/">ftp.sco.com</ulink>, directory SLS,
files uod385a.Z and uod385a.ltr.Z).
</para>
<para>
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.
</para>
</sect1>
<sect1>
<title>DNIX</title>
<para>
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.
</para>
<para>
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.
</para>
<para>
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 <filename>setegid.s</filename>:
</para>
<para><programlisting>
.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
</programlisting></para>
<para>
Put this in the file <filename>seteuid.s</filename>:
</para>
<para><programlisting>
.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
</programlisting></para>
<para>
After creating the above files, you then assemble them using
</para>
<screen>
&prompt;<userinput>as seteuid.s</userinput>
&prompt;<userinput>as setegid.s</userinput>
</screen>
<para>
that should produce the files <filename>seteuid.o</filename> and
<filename>setegid.o</filename>
</para>
<para>
Then you need to add these to the LIBSM line in the DNIX section of
the Samba Makefile. Your LIBSM line will then look something like this:
</para>
<para><programlisting>
LIBSM = setegid.o seteuid.o -ln
</programlisting></para>
<para>
You should then remove the line:
</para>
<para><programlisting>
#define NO_EID
</programlisting></para>
<para>from the DNIX section of <filename>includes.h</filename>.</para>
</sect1>
<sect1>
<title>Red Hat Linux</title>
<para>
By default during installation, some versions of Red Hat Linux add an
entry to <filename>/etc/hosts</filename> as follows:
<programlisting>
127.0.0.1 loopback "hostname"."domainname"
</programlisting>
</para>
<para>
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.
</para>
<para>
Corrective Action: Delete the entry after the word "loopback"
in the line starting 127.0.0.1.
</para>
</sect1>
<sect1>
<title>AIX</title>
<sect2>
<title>Sequential Read Ahead</title>
<!-- From an email by William Jojo <jojowil@hvcc.edu> -->
<para>
Disabling Sequential Read Ahead using <userinput>vmtune -r 0</userinput> improves
Samba performance significantly.
</para>
</sect2>
</sect1>
<sect1>
<title>Solaris</title>
<sect2>
<title>Locking Improvements</title>
<para>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. So the visible manifestation of this would be a handful of
processes stealing all of the CPU, and when they were truss-ed they would
be stuck if F_SETLKW64 loops.
</para>
<para>
Sun released patches for Solaris 2.6, 8, and 9. The patch for Solaris 7
has not been released yet.
</para>
<para>
The patch revision for 2.6 is 105181-34, for 8 is 108528-19 and for 9 is 112233-04.
</para>
<para>
After the install of these patches, it is recommended to reconfigure
and rebuild Samba.
</para>
<para>Thanks to Joe Meslovich for reporting this.</para>
</sect2>
<sect2 id="winbind-solaris9">
<title>Winbind on Solaris 9</title>
<para>
Nsswitch on Solaris 9 refuses to use the Winbind NSS module. This behavior
is fixed by Sun in patch <ulink url="http://sunsolve.sun.com/pub-cgi/findPatch.pl?patchId=112960;rev=14">112960-14</ulink>.
</para>
</sect2>
</sect1>
</chapter>
|
