Originally Published: Wednesday, 18 October 2000 Author: Chris Campbell
Published to: enhance_articles_sysadmin/Sysadmin Page: 1/1 - [Printable]

Linux and Windows NT 4.0: Basic Administration - Part IV

Linux (like Unix before it) was designed with the concept of a server in mind. Originally, when a user connected to a Unix machine, it was a direct physical connection as a terminal. The terminal was basically a CRT and keyboard, with no actual processor. When a user worked on the server, the user was actually working on the server and with the exception of an occasional connection to another server, the server was the network. The simplified Graphical User Interface was added as it was needed onto the firm foundations of a tried and true Server Operating system. The origins may still be seen in such functions as telnet, FTP and thin client connections via X-Sessions.

   Page 1 of 1  

File Sharing

Linux, (like Unix before it) was designed with the concept of a server in mind. Originally when a user connected to a Unix machine, it was a direct physical connection as a terminal. The terminal was basically a CRT and keyboard, with no actual processor. When a user worked on the server, the user was actually working on the server and with the exception of an occasional connection to another server, the server IS the network. The simplified Graphical User interface was added as it was needed, onto the firm foundations of a tried and true Server Operating system. The origins however, may still be seen is such functions as telnet, FTP and thin client connections via X-Sessions.

Microsoft originally developed Windows as a simplified interface for DOS, then with Windows 3.11 (and subsequent releases) it began to use peer-to-peer networking to connect individual PC's. With the initial release of Windows NT, Microsoft threw its hat into the server arena. However, that NT's concept of a server still remains with the concepts established with peer to peer networking such as NetBIOS broadcasts with WINS to resolve BIOS names to IP addresses. (Non-routable broadcast protocols are often indicative of LAN orgins.) In fact, Most smaller networks using NT would be perfectly fine remaining with peer to peer for basic file and print sharing.

Unfortunately, Microsoft's emphasis to date has been on forcing the abilities of a server into a GUI facade instead of focusing on the stability and strength of the server itself.

The true server aspects of Windows NT was initially in the form of maintaining centralized security, and the ability to host Internet services such as Web, e-mail and ftp servers, items that were developed for UNIX and have always existed in Linux inherently. In fact, the much touted directory services of Windows 2000 is simply a paradigm shift to using DNS instead of WINS for local name resolution, and incorporating the existing directory service, LDAP with Microsoft DFS. It is an attempt to become comparable to Novell's NDS, which has already been fully implemented in Linux (Written by Novell).

SAMBA

Samba is, by far, the most crucial tool in a successful NT to Linux migration. This package serves Microsoft's SMB protocol, enabling Windows Clients to see the Linux machine as a file and print server; this closes the gap between the unix server-centrix mentality and the Windows peer-to-peer mentality. Incidentally, some of the more excitable Linux zealots tend to pit Windows NT against Linux, but to date, Andrew Tridgell (creator of the samba project) has been most prolific in making the playing ground level. Microsoft's proprietary SMB can be run on Linux, and often with faster results than its Microsoft cousin.

If you have been following this series using the automated installation of Mandrake as was suggested in the first article, then accessing Samba is simple; It's all ready to go. (It is possible then to skip ahead to the section marked SWAT)

If Samba is not installed on the machine, the source may be downloaded from http://www.samba.org. The latest distribution will always be named Samba-latest.tar.gz.

After downloading the file, decompress it by typing:

tar -zxf {filename}

To continue on with the install go to the directory created by the decompression:

samba-2.0.x/source

Type:

#./configure --with-smbwrapper

This will compile a make file, which will be executed when the compile is complete:

#make

when that is complete, type:

#make install

This should do the actual installation and should end with a message indicating that the SWAT files have been installed.

Next, In order to enable Samba at boot-up, we have to add the smb processes to /etc/services:

netbios-ssn 139/tcp
netbios-ns 137/udp

and to /etc/inetd.conf:

netbios-ssn stream tcp nowait root /usr/local/samba/bin/smbd smbd
netbios-ns stream udp nowait root /usr/local/samba/bin/nmbd nmbd

at the shell then, type:

#killall -HUP inetd

Setting these services to start at boot can also be done through Linuxconf, drakeconf, or many of the distribution specific administration tools.

The /etc/services file edited above contains TCP/IP port information. This file exists in Windows NT also, in c:\winnt\system32\drivers\etc\services. In Linux the refusal of protocols on a port by port basis is done simply by commenting out the ports in /etc/inetd.conf. This can also be done in Windows NT, but not with the services file; instead it is necessary to go to:

  • -START -> SETTINGS -> CONTROL PANEL -> NETWORK -> PROTCOLS -> TCP/IP -> PROPERTIES -> ADVANCED
  • Click: "Enable Security"
  • then click "Configure"

    Here the option to select specific ports are given. inetd is a service that runs and listens for requests on TCP/IP ports. Once a request has arrived, inetd starts the server daemon relative to that port. This saves in memory and processing power by not having the server daemons running constantly. Incidentally, Inetd cannot be reset with the kill command that was covered in the last article. Instead, it is necessary to use killall -HUP to reset inetd to reread it's configuration file, inetd.conf. - These items will be reviewed again in a future article on TCP/IP services.

    SWAT Samba Web Administration Tool, or SWAT, should be located in /usr/local/samba/swat. Different distributions, however, may put the SWAT files in other locations. In order to enable SWAT, add to /etc/services:

    swat 901/tcp

    and to /etc/inetd.conf:

    swat stream tcp nowait.400 root /usr/local/samba/bin/swat swat at the shell once

    again, type:

    #killall -HUP inetd

    Now that inetd has been updated, at this point we can open a Web browser. Most installations install Netscape locally. In the Web browser, set the address to http://127.0.0.1:901.

    127.0.0.1 is the TCP/IP loopback address. This will open the browser to SWAT, which is running locally on port 901. SWAT will require a login as root, and then will open to a menu. This is a Web based interface for /etc/smb.conf, the samba configuration file.

    • Daemons
      • smbd - the SMB daemon
      • nmbd - the NetBIOS nameserver
    • Administrative Utilities
      • smbstatus - monitoring Samba
      • SWAT - web configuration tool
      • smbpasswd - managing SMB passwords
      • make_smbcodepage - codepage creation
      • testparm - validating your config file
      • testprns - testing printer configuration
    • General Utilities
      • nmblookup - NetBIOS name query tool
      • smbtar - SMB backup tool
      • smbclient - command line SMB client
    • Configuration Files
      • smb.conf - the main Samba configuration file
      • lmhosts - NetBIOS hosts file
      • smbpasswd - SMB password file
    • Miscellaneous
      • Samba introduction
      • Joining an NT Domain
      • Changing UNIX permissions using NT
      • smbrun - internal smbd utility

    These are all links to information about Samba. There is obviously too much to cover here, so it is strongly suggested that before putting a Samba-Linux server into production that these pages be reviewed. It is necessary to decide if the Samba server will be a domain controller, or not, should it run, WINS, login scripts, use local passwd information, etc. -And that's just the "Global Settings"!

    Now, test the system status by typing:

    #smbclient -U% -L 127.0.0.1

    At this point, Samba should be running. The SMB protocol is the cornerstone of Windows Peer-to-Peer (and now Server) networking and is installed with any version of Windows. This is notably more complicated on Linux as Linux Servers aren't typically automatically assumed to supplant Windows NT boxes.

    smbpasswd: Unless authentication has been pointed to an existing Windows NT Server or Domain, it is necessary to add any local users that are intended to use smb to the smbpasswd file. (Samba can also be configured to look at the /etc/passwd file too, but that should only be used if all users should have access to the smb shares.) The syntax for adding a user to smbpasswd is:

    #smbpasswd -a {username}

    Sharing Files:

    To create a file share in Windows NT, there are many ways:

    >From "My Computer", find the folder that is to be shared. Right click and go to "Sharing".

    Click "Share as" and assign a share name. Shares can be removed and Permissions can be set here also, but this is not typically the most secure: We'll get back to that in a minute. Files can also be shared still via Filemanager. To see this, at a command line, type:

    C:\winfile

    Here, just click once on the folder to be shared and go to "Disk" -> "Share as".

    Here a share name and permissions can be assigned. Shares can also be removed.

    Shares can also be created, both locally and remotely via the Server Manager.

  • -START -> PROGRAMS -> ADMINISTRATIVE TOOLS -> SERVER MANAGER
  • Click "Computer" -> "Shared Directories".

    Here also, shares can be created and removed.

    Sharing can also be done from command line in Windows NT:

    Locally-

    To create:

    Net share {Sharename}={drive}:\{path_to_share} /Remark:"{text}"

    To remove:

    Net share {Sharename} /delete

    To list:

    Net share

    Remote-

    To create:

    Rmtshare \\{server}\{Sharename}={drive}:\{path_to_share} /Remark:"{text}"

    To remove:

    Rmtshare \\{server}\{Sharename} /delete

    Note on Windows NT Sharing permissions:

    Windows NT share security is not all that inclusive. A share can be created beneath the share that the administrator creates and the security would be easily subverted. Instead, the system level security of NTFS does an excellent job of keeping unwanted people away. This security can be set from Explorer:

    Right click on the folder that has been (or is to be) shared. Go down to "properties". (Notice that there is a tab for sharing here also.) Click on the "security" tab.

    Click "permissions". Click "Replace permissions on all subdirectories".

    Now, selected the users or groups that need to access this resource. Typically, it is suggested that all day to day users/groups be given "Change" access, and having "Full Access" only being given to Administrators/Domain Administrators.

    Permissions may also be altered in the command line:

    cacls {file/folder name} /T /C /G {user}:{permissions: R Read }
    {user2}:{permissions}
    C Change
    F Full Control

    Multiple users can be added without need of additional /G switches.

    In Linux, to add an SMB share from the shell, add to /etc/smb.conf:


    #Global Parameters
    workgroup = {workgroup}
    [{sharename}]
    comment = {Text}
    path = {Path to shared folder/file}
    read only = no
    guest ok = yes

    >From SWAT, go to Global Settings and update the workgroup, NetBIOS name, and WINS support options with the appropriate values.

    Click "Shares" -> Type {Sharename} next to "Create Share". Click "Create Share".

    Here SWAT will create a new form with spaces for comment, path to shared folder/file, guest account, etc.

    Now Click "Status". Click "Restart SMBD". Click "Restart NMBD".

    File sharing can also be done through linuxconf, and other distribution-specific administration tools, such as drakeconf.

    Printing, although an aspect of SAMBA, will be covered more thoroughly in a later article.

    "TCP/IP Services", as the printer set-up will be via TCP/IP.

    WINS Windows Internet Naming Server, To Start WINS in NT:

  • START-> SETTINGS -> CONTROL PANEL -> NETWORK
  • Click "Services" Tab
  • Click "Add"
  • Select "Microsoft Windows Internet Naming Services"
  • Click OK and proceed with installation and reboot.
  • Once rebooted, go to: START -> PROGRAMS -> ADMINISTRATIVE TOOLS -> WINS MANAGER

    The local IP address should be in the server list. Any additional server may be created or added at ths point.

    For starting Wins in Linux, we have already covered how to activate WINS in SWAT:

    >From SWAT, go to Global Settings, change WINS support to yes - or point to an existing Windows NT server.

    To configure WINS from the shell, edit the /etc/smb.conf file, find (or add):

    To have the Linux server act as the WINS server-

    wins support=yes

    To point to another WINS server-

    wins server=x.x.x.x

    Where x.x.x.x is the IP address of the existing WINS server.

    Samba Login Scripts:

    It may be necessary for each client to perform various tasks at login, such as reconnecting network drives, audits and administrative messages. For a Linux server to truly supplant and Windows NT server, Login scripts must be functional.

    To add a login script, change directories to:

    c:\winnt\system32\repl\export\scripts

    There are two directories in c:\winnt\system32\repl\, export and import. This is for use of domain controller syncronization and replication. In theory, an administrator would create and alter login scripts in export on the primary domain controller and set domain replication to export these scripts to all of the backup domain controllers. The backup domain controllers, on the other hand, would be set to look for their login scripts in the imports directory. - This scenario would be set in server manager, as per the networks individual needs. - This is beyond the scope of this series.

    In c:\winnt\system32\repl\export\scripts, edit a file with a .bat extension.

    Here, add any sort of thing desired to be executed at login, such as:

    @echo off net use h: /del net use h: \\server_01\%username%$

    The login script would be set in the user settings, as covered in the earlier article on User Administration.

    To add Login Scripts in Linux via Samba, in SWAT, go to global settings and click "View Advanced Settings". About 3/4 down the page is a section for "Logon Options". Under here is a form entry for "Login Script". Select a location for the login script. The next step, obviously is to go to that location and create the script.

    This is one instance where adding the setting via shell is less cumbersome.

    Simply edit /etc/smb.conf and add:

    logon script = {scriptname}

    There is one more important final note about Samba. Microsoft did not use encrypted passwords for authentication until Windows NT Service Pack 3 and Windows 98. (Windows 95 Service pack 2 is also rumored to have encrypted passwords, but I have found no success with it.) If the other OS's on the network use encrypted passwords, then add to /etc/smb.conf:

    encrypt passwords=yes

    Also, take care to make sure that any users intended to use the server have been entered into the smbpasswd file, as described above.

    NFS:

    Network File System (NFS) is amazingly easy to set up, provided that both TCP/IP and name resolution have been set up properly. This also requires that they there are other UNIX machines on the network as this is a UNIX specific function. NT is not automatically capable of this, but as it is nearly crucial to unix-to-unix filesharing, it is being covered here briefly.

    On the unix/linux machine with the NFS folder to share, edit /etc/exports and add:

    {Sharepath} {IP/MachineName}(rw,no_root_squash)

    followed by the command:

    #exportfs -a

    This will give read-write access to {sharepath}. Other permissions, such as read-only(ro), can be used, but for testing this should be sufficient.

    On the unix/linux machine that wishes to mount the NFS share, edit /etc/fstab (/etc/vfstab if Solaris) and add:

    #device directory type options
    {remote_server}:{remote_sharepath} {local_mount_point} NFS defaults

    /etc/fstab holds all of the mount information for linux, with local, removable and network drives all accounted for. Here, drives may even be set to connect at boot-up. Now that the remote drives will be set to be mounted we will mount the share by typing:

    #mount -a

    This will re-mount all contents of /etc/fstab and provided that all configuration is correct, that should be all the steps needed. As mentioned about, NT is not automatically capable of NFS. The additional purchase of Microsoft's Unix Services for Windows NT (about $195.00), will allow the server to see, serve, and even Gateway NFS volumes. To use this software on Windows NT, it is necessary to have both service pack 4 and IE 4.0 installed. (At least for the latest release of the product). This product may be used for NT 40 or windows 2000. This can be seen clearly in the Interface which uses the Microsoft Management Console (MMC) which is the mainstay of the Windows 2000 administration.

    Like sharing folders via SMB (CIFS) there are multiple ways to create NFS shares.

    >From "My Computer", find the folder that is to be share. Right click and go to "Sharing".

    Click on the "NFS Sharing" tab. Click the radial for "Share this folder" "Share as" and assign a share name. Click permissions allows the machines intended to mount the share to be specified.

    The folder may also be shared via command line. At the dos prompt, type:

    To create:

    c:\>Nfsshare {Sharename}={drive}:\{path_to_share}

    To remove:

    c:\>Nfsshare {Sharename} /delete Connecting to an NFS share using windows NT 4.0 with Unix Services for Windows NT, can also be done both from the GUI or from command line. In the GUI, use Windows Explorer. In Explorer, goto:

    Tools > Map Network Drive

    Select the letter for the drive from the drive list and then specify in the path:

    \\{computer}\{share}

    To specify a username, use the "Connect As:" field to do so.

    >From command line:

    c:\>mount -o {options} -u:{username} ip:{password} \\{computer}\{share}

    There are multiple options for the -o flag, including the ability to mount as an anonymous user, which may be necessary. That function would be as follows.

    c:\>mount -o anon -u:{username} ip:{password} \\{computer}\{share}

    We will continue working with the Unix Services for Windows NT in the next part, "Simple TCP/IP Services."





  •    Page 1 of 1