Providing Services Under Linux

Discussion in 'Advanced Tutorials' started by LinuxDotOrg, Jul 9, 2013.

  1. LinuxDotOrg

    LinuxDotOrg Administrator

    Messages:
    34
    Likes Received:
    70
    Trophy Points:
    8
    Running A Name Server

    The most popular software for translating hard to remember IP addresses (unless you're into mnemonics) into easy (or at least easier) to remember domain names is BIND. BIND is short for Berkeley Internet Name Domain and is software to provide DNS (Domain Name System) services. Here, we'll set up a very simple system that's adequate for a small business or home network.

    Installing BIND

    At the time of this writing, the most recent version of BIND is version 9. Major distributions have packaged BIND for easy installation.

    Files Associated with BIND

    BIND's configuration files can be found in /etc/bind

    named.conf is the file that references the zone files for domains and reverse lookups for IPs.

    named.conf

    The forwarders are the DNS servers that BIND consults just in case it can't resolve names on its own. If you're using this in a small business or home setting, these numbers should be the DNS servers of your provider.
    Code:
    forwarders { X.X.X.X; Y.Y.Y.Y; Z.Z.Z.Z; };



    After this line, we'll add the domains that we'll be hosting in our own server. That will make them resolve internally.

    Code:
    // add entries for other zones below here
     
    zone "linux.ork" in {
    type master;
    file "/etc/bind/linux.zone";
    };
     
    zone "0.168.192.in-addr.arpa" {
    type master;
    file "/etc/bind/linux.res";
    };
    

    The first entry is the domain plus its TLD (top level domain) as in our example linux.ork

    The second entry is the IP minus the last number - all of which is written backwards. In our example, the local network is 192.168.0.X.

    In the example, the first entry references the zone file. The second is the reverse lookup of the domain name.

    In the case where we have various domains hosted on our local network, we'll just have one file for reverse lookup.

    *.zone File
    Code:
    @ IN SOA linux.ork. root.linux.ork. (
    2004091501 ; --- SERIAL NUM.
    604800 ; --- REFRESH
    86400 ; --- RETRY
    2419200 ; --- EXPIRES
    604800) ; --- MINIMUM
    IN NS machine.linux.ork.
    IN NS www.linux.ork.
    IN MX 10 machine.linux.ork.
     
    machine IN A 192.168.0.20
    www IN A 192.168.0.20
    Let's look at what these numbers mean. SERIAL NUMBER needs to be a unique number and for this reason it's best to use a system based on the date plus two more digits. If you make changes to this file, you need to add one to the end numbers (eg. 02, 03 etc)

    REFRESH is the time in seconds that the your nameserver should contact the primary name server. RETRY is there in case a primary nameserver goes off line. This is the time before your server waits to contact it again. If the primary name server becomes unreachable, then the last number, EXPIRE, kicks in and tells it that beyond this point, it should stop trying. Finally, MINIMUM is the length of time that the name server will keep domain cached. Here, like the REFRESH value, will keep it for a week.

    IN NS are the distinct names for which machines are known.

    IN MX 10 - is the name of the machine for purposes of sending email.

    Finally, we indicate the name of the machine as an A record and its corresponding IP address. Here we can list all of the machines in the local network and their IP addresses.

    m
    Code:
    achine IN A 192.168.0.20
     
    *.res File
    @ IN SOA linux.ork. root.linux.ork. (
    2003091501 ; --- SERIAL NUMBER
    604800 ; --- REFRESH
    86400 ; --- RETRY
    2419200 ; --- EXPIRES
    604800) ; --- MINIMUM
    IN NS machine.linux.ork.
    20 IN PTR www.linux.ork.
    20 IN PTR machine.linux.ork.
    

    These values are the same as the zone file, except at the end where you'll see we've changed '[name] + IN' for '20 IN PTR' + the machine's name.

    Restart BIND

    After any changes, you'll need to restart BIND. This is known as the 'named' daemon.

    Printing with CUPS

    CUPS stands for 'Common Unix Printing System'. The first version of CUPS was released in October, 1999. It has since become very popular on Linux systems. The reason for this is that unlike earlier printing system, network system is a lot easier with CUPS. The reason for this is the method of "printer browsing" built into it. This lets client computers on a LAN, for example, to automatically find and use printers on any other "server" on the network. The other main advantage to using CUPS is its system for supporting printers. It uses PPD files to get that job done. PPD stands for Postscript Printer Description and it is essentially a configuration file for a particular printer. To configure a printer, you simply place a PPD file corresponding to the printer in question in the /usr/share/cups/model directory of the CUPS system. Printer configuration, which has always been a somewhat daunting task, is much easier with CUPS.

    Linuxprinting.org, which is an invaluable resource for getting printers working under Linux, has a large collection of freely available PPD files at http://www.linuxprinting.org/download/PPD/

    CUPS comes with a web-based configuration tool that you can access by pointing your browser athttp://localhost:631. The main administration panel looks like this:


    There are also various static GUI applications for configuring cups. However, up to the time of this writing, my experience with the tools I have used to configure CUPS has not been good. In my opinion, the best thing is to go to /etc/cups/, fire up your text editor (vi, emacs, etc) an manually edit the configuration files. This is what any experienced Unix/Linux system administrator would do.

    Network Printing

    CUPS is designed to check for the existence of other CUPS servers. So, if you have a machine without a printer that's running CUPS, it will look for a machine with a printer: the print server. This server needs to be configured to accept connections to it. That means the file cupsd.conf must have information in it as to what machines can use its printer. Also, you'll need to make sure that any firewall you have in place accepts TCP connections on port 631.
    To let other computers use the printer, you'll need to look for the following section in your cupsd.conf file:
    Code:
    <Location /printers/hp3325>
    Order Deny,Allow
    Deny From All
    Allow From 127.0.0.1
    AuthType None
    Allow from 192.168.0.*
    <Location />

    As you can see, I've let machines on my network (192.168.0.*) access the printer. You should also find the following line an remove the comment sign (#) to allow local access to the printer:

    Code:
    BrowseAllow @LOCAL
    

    Client Machines

    Now, you'll need to create or modify the /etc/cups/printers.conf on the client machines, which must also be running cups. For the server setup above, my clients look like this:
    Code:
    <DefaultPrinter hp3325>[/COLOR]
    [COLOR=#000000]Info hp3325[/COLOR]
    [COLOR=#000000]DeviceURI lpd://192.168.0.9:631[/COLOR]
    [COLOR=#000000]State Idle[/COLOR]
    [COLOR=#000000]Accepting Yes[/COLOR]
    [COLOR=#000000]JobSheets none none[/COLOR]
    [COLOR=#000000]QuotaPeriod 0[/COLOR]
    [COLOR=#000000]PageLimit 0[/COLOR]
    [COLOR=#000000]KLimit 0[/COLOR]
    [COLOR=#000000]</Printer>
    Amit_*nix likes this.

Share This Page