[gd/samba-autobuild/.git] / docs / docbook / faq / features.xml

<chapter id="FAQ-features">

<title>Features</title>

<sect1>
<title>How can I prevent my samba server from being used to distribute the Nimda worm?</title>

<para>Author: HASEGAWA Yosuke (translated by <ulink url="monyo@samba.gr.jp">TAKAHASHI Motonobu</ulink>)</para>

<para>
Nimba Worm is infected through shared disks on a network, as well as through
Microsoft IIS, Internet Explorer and mailer of Outlook series.
</para>

<para>
At this time, the worm copies itself by the name *.nws and *.eml on
the shared disk, moreover, by the name of Riched20.dll in the folder
where *.doc file is included.
</para>

<para>
To prevent infection through the shared disk offered by Samba, set
up as follows:
</para>

<para>
<programlisting>
[global]
  ...
  # This can break Administration installations of Office2k.
  # in that case, don't veto the riched20.dll
  veto files = /*.eml/*.nws/riched20.dll/
</programlisting>
</para>

<para>
By setting the "veto files" parameter, matched files on the Samba
server are completely hidden from the clients and making it impossible
to access them at all.
</para>

<para>
In addition to it, the following setting is also pointed out by the
samba-jp:09448 thread: when the
"readme.txt.{3050F4D8-98B5-11CF-BB82-00AA00BDCE0B}" file exists on
a Samba server, it is visible only as "readme.txt" and dangerous
code may be executed if this file is double-clicked.
</para>

<para>
Setting the following,
<programlisting>
  veto files = /*.{*}/
</programlisting>
any files having CLSID in its file extension will be inaccessible from any
clients.
</para>

<para>
This technical article is created based on the discussion of
samba-jp:09448 and samba-jp:10900 threads.
</para>
</sect1>

<sect1>
<title>How can I use samba as a fax server?</title>

<para>Contributor: <ulink url="mailto:zuber@berlin.snafu.de">Gerhard Zuber</ulink></para>

<para>Requirements:
<simplelist>
<member>UNIX box (Linux preferred) with SAMBA and a faxmodem</member>
<member>ghostscript package</member>
<member>mgetty+sendfax package</member>
<member>pbm package (portable bitmap tools)</member>
</simplelist>
</para>

<para>First, install and configure the required packages. Be sure to read the mgetty+sendfax 
manual carefully.</para>

<sect2>
<title>Tools for printing faxes</title>

<para>Your incomed faxes are in:
<filename>/var/spool/fax/incoming</filename>. Print it with:</para>

<para><programlisting>
for i in *
do
g3cat $i | g3tolj | lpr -P hp
done
</programlisting>
</para>

<para>
g3cat is in the tools-section, g3tolj is in the contrib-section
for printing to HP lasers.
</para>

<para>
If you want to produce files for displaying and printing with Windows, use
some tools from the pbm-package like the following command: <command>g3cat $i | g3topbm - |  ppmtopcx - >$i.pcx</command>
and view it with your favourite Windows tool (maybe paintbrush)
</para>

</sect2>

<sect2>
<title>Making the fax-server</title>

<para>fetch the file <filename>mgetty+sendfax/frontends/winword/faxfilter</filename> and place it in <filename>/usr/local/etc/mgetty+sendfax/</filename>(replace /usr/local/ with whatever place you installed mgetty+sendfax)</para>

<para>prepare your faxspool file as mentioned in this file
edit fax/faxspool.in and reinstall or change the final
/usr/local/bin/faxspool too.
</para>

<para><programlisting>
if [ "$user" = "root" -o "$user" = "fax" -o \
     "$user" = "lp" -o "$user" = "daemon" -o "$user" = "bin" ]
</programlisting></para>

<para>find the first line and change it to the second.</para>

<para>
make sure you have pbmtext (from the pbm-package). This is
needed for creating the small header line on each page.
</para>

<para>Prepare your faxheader <filename>/usr/local/etc/mgetty+sendfax/faxheader</filename></para>

<para>
Edit your /etc/printcap file:
<programlisting>
# FAX 
lp3|fax:\
        :lp=/dev/null:\
        :sd=/usr/spool/lp3:\
        :if=/usr/local/etc/mgetty+sendfax/faxfilter:sh:sf:mx#0:\
        :lf=/usr/spool/lp3/fax-log:
</programlisting></para>

<para>Now, edit your <filename>smb.conf</filename> so you have a smb based printer named "fax"</para>

</sect2>

<sect2>
<title>Installing the client drivers</title>

<para>
Now you have a printer called "fax" which can be used via
TCP/IP-printing (lpd-system) or via SAMBA (windows printing).
</para>

<para>
On every system you are able to produce postscript-files you
are ready to fax.
</para>

<para>
On Windows 3.1 95 and NT:
</para>

<para>
Install a printer wich produces postscript output,
   e.g.  apple laserwriter
</para>

<para>Connect the "fax" to your printer.</para>

<para>
Now write your first fax. Use your favourite wordprocessor,
write, winword, notepad or whatever you want, and start
with the headerpage.
</para>

<para>
Usually each fax has a header page. It carries your name,
your address, your phone/fax-number.
</para>

<para>
It carries also the recipient, his address and his *** fax
number ***. Now here is the trick:
</para>

<para>
Use the text:
<programlisting>
Fax-Nr: 123456789
</programlisting>
as the recipients fax-number. Make sure this text does not
occur in regular text ! Make sure this text is not broken
by formatting information, e.g. format it as a single entity.
(Windows Write and Win95 Wordpad are functional, maybe newer
 versions of Winword are breaking formatting information).
</para>

<para>
The trick is that postscript output is human readable and
the faxfilter program scans the text for this pattern and
uses the found number as the fax-destination-number.
</para>

<para>
Now print your fax through the fax-printer and it will be
queued for later transmission. Use faxrunq for sending the
queue out.
</para>

</sect2>

<sect2>
<title>Example smb.conf</title>

<para><programlisting>
[global]
 printcap name = /etc/printcap
 print command = /usr/bin/lpr -r -P %p %s
 lpq command = /usr/bin/lpq -P %p
 lprm command = /usr/bin/lprm -P %p %j

[fax]
    comment = FAX (mgetty+sendfax)
    path = /tmp
    printable = yes
    public = yes
    writable = no
    create mode = 0700
    browseable = yes
    guest ok = no
</programlisting></para>

</sect2>
</sect1>

<sect1>
<title>Samba doesn't work well together with DHCP!</title>

<para>
We wish to help those folks who wish to use the ISC DHCP Server and provide
sample configuration settings. Most operating systems today come ship with
the ISC DHCP Server. ISC DHCP is available from:
<ulink url="ftp://ftp.isc.org/isc/dhcp">ftp://ftp.isc.org/isc/dhcp</ulink>
</para>

<para>
Incorrect configuration of MS Windows clients (Windows9X, Windows ME, Windows
NT/2000) will lead to problems with browsing and with general network
operation. Windows 9X/ME users often report problems where the TCP/IP and related
network settings will inadvertantly become reset at machine start-up resulting
in loss of configuration settings. This results in increased maintenance
overheads as well as serious user frustration.
</para>

<para>
In recent times users on one mailing list incorrectly attributed the cause of
network operating problems to incorrect configuration of Samba.
</para>

<para>
One user insisted that the only way to provent Windows95 from periodically
performing a full system reset and hardware detection process on start-up was
to install the NetBEUI protocol in addition to TCP/IP. This assertion is not
correct.
</para>

<para>
In the first place, there is NO need for NetBEUI. All Microsoft Windows clients
natively run NetBIOS over TCP/IP, and that is the only protocol that is
recognised by Samba. Installation of NetBEUI and/or NetBIOS over IPX will
cause problems with browse list operation on most networks. Even Windows NT
networks experience these problems when incorrectly configured Windows95
systems share the same name space. It is important that only those protocols
that are strictly needed for site specific reasons should EVER be installed.
</para>

<para>
Secondly, and totally against common opinion, DHCP is NOT an evil design but is
an extension of the BOOTP protocol that has been in use in Unix environments
for many years without any of the melt-down problems that some sensationalists
would have us believe can be experienced with DHCP. In fact, DHCP in covered by
rfc1541 and is a very safe method of keeping an MS Windows desktop environment
under control and for ensuring stable network operation.
</para>

<para>
Please note that MS Windows systems as of MS Windows NT 3.1 and MS Windows 95
store all network configuration settings a registry. There are a few reports
from MS Windows network administrators that warrant mention here. It would appear
that when one sets certain MS TCP/IP protocol settings (either directly or via
DHCP) that these do get written to the registry. Even though a subsequent
change of setting may occur the old value may persist in the registry. This
has been known to create serious networking problems.
</para>

<para>
An example of this occurs when a manual TCP/IP environment is configured to
include a NetBIOS Scope. In this event, when the administrator then changes the
configuration of the MS TCP/IP protocol stack, without first deleting the
current settings, by simply checking the box to configure the MS TCP/IP stack
via DHCP then the NetBIOS Scope that is still persistent in the registry WILL be
applied to the resulting DHCP offered settings UNLESS the DHCP server also sets
a NetBIOS Scope. It may therefore be prudent to forcibly apply a NULL NetBIOS
Scope from your DHCP server. The can be done in the dhcpd.conf file with the
parameter:
<command>option netbios-scope "";</command>
</para>

<para>
While it is true that the Microsoft DHCP server that comes with Windows NT
Server provides only a sub-set of rfc1533 functionality this is hardly an issue
in those sites that already have a large investment and commitment to Unix
systems and technologies. The current state of the art of the DHCP Server
specification in covered in rfc2132.
</para>

</sect1>

<sect1>
<title>How can I assign NetBIOS names to clients with DHCP?</title>

<para>
SMB network clients need to be configured so that all standard TCP/IP name to
address resolution works correctly. Once this has been achieved the SMB
environment provides additional tools and services that act as helper agents in
the translation of SMB (NetBIOS) names to their appropriate IP Addresses. One
such helper agent is the NetBIOS Name Server (NBNS) or as Microsoft called it
in their Windows NT Server implementation WINS (Windows Internet Name Server).
</para>

<para>
A client needs to be configured so that it has a unique Machine (Computer)
Name.
</para>

<para>
This can be done, but needs a few NT registry hacks and you need to be able to
speak UNICODE, which is of course no problem for a True Wizzard(tm) :)
Instructions on how to do this (including a small util for less capable
Wizzards) can be found at
</para>

<para><ulink url="http://www.unixtools.org/~nneul/sw/nt/dhcp-netbios-hostname.html">http://www.unixtools.org/~nneul/sw/nt/dhcp-netbios-hostname.html</ulink></para>

</sect1>

<sect1>
<title>How do I convert between unix and dos text formats?</title>

<para>
Jim barry has written an <ulink url="ftp://samba.org/pub/samba/contributed/fixcrlf.zip">
excellent drag-and-drop cr/lf converter for
windows</ulink>. Just drag your file onto the icon and it converts the file.
</para>

<para>
The utilities unix2dos and dos2unix(in the mtools package) should do 
the job under unix.
</para>

</sect1>

<sect1>
<title>Does samba have wins replication support?</title>

<para>
At the time of writing there is currently being worked on a wins replication implementation(wrepld).
</para>

</sect1>

</chapter>