Back to Techies Corner

Home Host Two - Setting Up Samba

Background

I have got too used to using ConTEXT as my HTML editor, and, at least for the minute, life's too short to learn another highlighting text editor. So my next step in setting up what has now become known as 'The Home Host Project' (to me at least) is to give ConTEXT direct access to the DevSite's HTML files.

Problem

ConTEXT is a Windows programme. So the DevSite virtual machine needs Samba installing / configuring via a PuTTY terminal session. A good side effect will be that other M$ proggies like PaintShop Pro can access the graphics folder too.

Solution - Installing Samba

First stage is to ensure that Samba is installed.

  1. Used the command 'yum search samba' to check if its even installed. If it is skip to the Instaling SWAT section
  2. If its not, then run 'yum install samba' responding to the prompt to go ahead and install. (I bet there's a switch to default this, but its a comfort factor to me.)
  3. Next use '/sbin/chkconfig --level 345 smb on' to set smb to start at boot time in runtime levels 3, 4 and 5. You can check that it has set as predicted with the command '/sbin/chkconfig --list'.
  4. Finally you need to start the service, using '/sbin/service smb start'.

My original intention here was to configure Samba by editing the smb.conf file directly. A quick read of the man page quickly dissuaded me. (Yes, its something I should get to understand, but not at the time-expense of 'The Home Host Project'.) So I have now opted to have a look at something that should make it easier - SWAT (known to YUM as SAMBA-SWAT.)

Solution - Installing SWAT

  1. Used the command 'yum search samba-swat' to check if its even installed. If it is skip to the next section 'Configuring SWAT
  2. If not then you need to install it. Run the command 'yum install samba-swat' responding yes to the prompt when it appears.

And that's it - all you need to do now is configure xinetd to run it as a service to be able to access it via a web browser.

Solution - Configuring SWAT

Now here I am going to really save you some time and effort. I read the SWAT man page and Googled it, and the info I found talks about configuring inetd to run SWAT as a service, but this is Fedora, it uses the more secure xinetd. So I Googled somemore and found an article on configuring xinetd.conf to run SWAT as a service, and followed it exactly. I did think that the file was a little (to say the least) bare. Eventually the penny dropped at the work ' include' and I checked out the /etc/xinetd.d directory and there already was the swat service file ready to be included in the xinet.conf file on service startup (usually at boot time).

[root@gamp-vm garrath]# ls -l /etc/xinetd*
-rw-r--r-- 1 root root 677 Apr 9 12:42 /etc/xinetd.conf

/etc/xinetd.d:
total 52
-rw-r--r-- 1 root root 563 Oct 12 08:41 chargen
-rw-r--r-- 1 root root 580 Oct 12 08:41 chargen-udp
-rwxr-xr-x 1 root root 239 Oct 2 2003 cups-lpd
-rw-r--r-- 1 root root 419 Oct 12 08:41 daytime
-rw-r--r-- 1 root root 438 Oct 12 08:41 daytime-udp
-rw-r--r-- 1 root root 341 Oct 12 08:41 echo
-rw-r--r-- 1 root root 360 Oct 12 08:41 echo-udp
-rw-r--r-- 1 root root 317 Dec 4 04:45 rsync
-rw-r--r-- 1 root root 314 Oct 12 08:41 services
-rw-r--r-- 1 root root 392 Aug 12 2003 sgi_fam
-rw-r--r-- 1 root root 363 Feb 12 19:43 swat
-rw-r--r-- 1 root root 497 Oct 12 08:41 time
-rw-r--r-- 1 root root 518 Oct 12 08:41 time-udp

It looks like this:

[root@gamp-vm garrath]# more /etc/xinetd.d/swat
# default: off
# description: SWAT is the Samba Web Admin Tool. Use swat \
# to configure your Samba server. To use SWAT, \
# connect to port 901 with your favorite web browser.
service swat
{
port = 901
socket_type = stream
wait = no
only_from = 127.0.0.1
user = root
server = /usr/sbin/swat
log_on_failure += USERID
disable = yes
}
[root@gamp-vm garrath]#

Now this is all well and good, but it defaults to a useage of running a browser locally to configure Samba. (Yep! That's right, that's what this is all about in case you'd forgotten.) Which does imply that there is X and a browser installed, but that's not so on my servers. So I need to be able to access these with a browser on the desktop.

A quick read of the xinetd.confg man page tell me that I can alter the 'only_from' parameter to accepting any host on a named (DNS) domain.

  1. Use your favourite text editor to open the file '/etc/xinetd.d/swat'
  2. Add a # to the front of the line 'only_from = 127.0.0.1' to comment it out. Then add another line below 'only_from = .c-n-u.local'. *
  3. Now change the value of 'disable =' from 'yes' to 'no'. Save the file and close the editor.
  4. Now restart the xinetd daemon using the '/sbin/service xinetd restart' command.
  5. Lastly it is wise to check that the SWAT service is known to the server. This means it is part of the /etc/services file. Run the command 'more /etc/services | grep swat' and you should get back the one line:
    swat 901/tcp #Samba Web Administration Tool
    which tells you that all is ok. If you get nothing back, then add the above line to the file.
  6. Run the command 'smbpasswd -a root' which prompted me to add a password for the user root.

    7. * This tells SWAT to reverse look up the hostname within the domain and check it exists. Then it gives access. You can use network addresses and eliminate the reverse lookup time, e.g. '10.0.0.0', which would accept any address from that network space, but that's less secure. But currently it doesn't work and I have used # to comment out the line and insert a '10.0.0.0' line to gain access.

Solution - Configuring Samba in SWAT

There are two buttons on the SWAT home page that you need to use; 'Globals' and 'Shares'. Read the help to understand them.

  1. Open the local browser and enter the URL to the server, e.g.
    'http:///DevSite'
  2. Under Globals set the Workgroup to your network NetBIOS name, click on the commit button and that's about it in there to get things working.
  3. Under Shares create a share name, e.g. DevSite and set the path to it. Click on the commit button on this page and you should be set.

All that was left to do was to re-map the W: drive to the new Samba share on the VM server and I was away!

NB This has rather made the first step redundant, as I don't need to FTP to the DevSite server any longer, but that's only because I don't want to learn vi properly, or emacs or any of the others I could use in a terminal session.