An Educator`s Guide to School Networks

Chapter 2


What is a Protocol?
A protocol is a set of rules that governs the communications between computers on a network. In order for two computers to talk to each other, they must be speaking the same language. Many different types of network protocols and standards are required to ensure that your computer (no matter which operating system, network card, or application you are using) can communicate with another computer located on the next desk or half-way around the world. The OSI (Open Systems Interconnection) Reference Model defines seven layers of networking protocols. The complexity of these layers is beyond the scope of this tutorial; however, they can be simplified into four layers to help identify some of the protocols with which you should be familiar (see fig 1).


Figure 1 illustrates how some of the major protocols would correlate to the OSI model in order to communicate via the Internet. In this model, there are four layers, including:

  • Ethernet (Physical/Data Link Layers)
  • IP/IPX (Network Layer)
  • TCP/SPX (Transport Layer)
  • HTTP, FTP, Telnet, SMTP, and DNS (Session/Presentation/Application Layers)

    Assuming you want to send an e-mail message to someone in Italy, we will examine the layers "from the bottom up" -- beginning with Ethernet (physical/data link kayers).

    Ethernet (Physical/Data Link Layers)
    The physical layer of the network focuses on hardware issues, such as cables, repeaters, and network interface cards. By far the most common protocol used at the physical layer is Ethernet. For example, an Ethernet network (such as 10BaseT or 100BaseTX) specifies the type of cables that can be used, the optimal topology (star vs. bus, etc.), the maximum length of cables, etc. (See the Cabling section for more information on Ethernet standards related to the physical layer).

    The data link layer of the network addresses the way that data packets are sent from one node to another. Ethernet uses an access method called CSMA/CD (Carrier Sense Multiple Access/Collision Detection). This is a system where each computer listens to the cable before sending anything through the network. If the network is clear, the computer will transmit. If some other node is already transmitting on the cable, the computer will wait and try again when the line is clear. Sometimes, two computers attempt to transmit at the same instant. When this happens a collision occurs. Each computer then backs off and waits a random amount of time before attempting to retransmit. With this access method, it is normal to have collisions. However, the delay caused by collisions and retransmitting is very small and does not normally effect the speed of transmission on the network.

    Ethernet

    The original Ethernet standard was developed in 1983 and had a maximum speed of 10 Mbps (phenomonal at the time). The Ethernet protocol allows for bus, star, or tree topologies, depending on the type of cables used and other factors .

    The current standard at the 10 Mbps level is 10BaseT. The "10" stands for the speed of transmission (10 megabits per second); the "Base" stands for "baseband" meaning it has full control of the wire on a single frequency; and the "T" stands for "twisted pair" cable. Older standards, such as 10Base2 and 10Base5, used coaxial cable, but these standards are seldom used in new installations. Fiber cable can also be used at this level in 10BaseFL.

    Fast Ethernet

    The Fast Ethernet protocol supports transmission up to 100 Mbps. Fast Ethernet requires the use of different, more expensive network concentrators/hubs and network interface cards. In addition, category 5 twisted pair or fiber optic cable is necessary. Fast Ethernet standards include:

  • 100BaseT - 100 Mbps over 2-pair category 5 or better UTP cable.
  • 100BaseFX - 100 Mbps over fiber cable.
  • 100BaseSX -100 Mbps over multimode fiber cable.
  • 100BaseBX - 100 Mbps over single mode fiber cable.

    Gigabit Ethernet

    Gigabit Ethernet standard is a protocol that has a transmission speed of 1 Gbps (1000 Mbps). It can be used with both fiber optic cabling and copper. The 1000BaseT, the copper cable used for Gigabit Ethernet (see the Cabling section for more information).

  • 1000BaseT - 1000 Mbps over 2-pair category 5 or better UTP cable.
  • 1000BaseTX - 1000 Mbps over 2-pair category 6 or better UTP cable.
  • 1000BaseFX - 1000 Mbps over fiber cable.
  • 1000BaseSX -1000 Mbps over multimode fiber cable.
  • 1000BaseBX - 1000 Mbps over single mode fiber cable.

    The Ethernet standards continue to evolve. with 10 Gigabit Ethernet (10,000 Mbps) and 100 Gigabit Ethernet (100,000 Mbps),



    LocalTalk

    LocalTalk is a network protocol that was developed by Apple Computer, Inc. for Macintosh computers many years ago. LocalTalk adapters and special twisted pair cable can be used to connect a series of older computers through the serial port (current Macintosh computers have Ethernet cards and/or wireless adapters installed). A primary disadvantage of LocalTalk is speed. Its speed of transmission is only 230 Kbps.

    Token Ring

    The Token Ring protocol was developed by IBM in the mid-1980s. The access method used involves token-passing. In Token Ring, the computers are connected so that the signal travels around the network from one computer to another in a logical ring. A single electronic token moves around the ring from one computer to the next. If a computer does not have information to transmit, it simply passes the token on to the next workstation. If a computer wishes to transmit and receives an empty token, it attaches data to the token. The token then proceeds around the ring until it comes to the computer for which the data is meant. The Token Ring protocol requires a star-wired ring using twisted pair or fiber optic cable. It can operate at transmission speeds of 4 Mbps or 16 Mbps. Due to the increasing popularity of Ethernet, the use of Token Ring in school environments has decreased dramatically.

    IP and IPX (Network Layer)

    The network layer is in charge of routing network messages (data) from one computer to another. The common protocols at this layer are IP (which is paired with TCP at the transport layer for Internet network) and IPX (which is paired with SPX at the transport layer for some older Macintosh, Linus, UNIX, Novell and Windows networks). Because of the growth in Internet-based networks, IP/TCP are becoming the leading protocols for most networks.

    Every network device (such as network interface cards and printers) have a physical address called a MAC (Media Access Control) address. When you purchase a network card, the MAC address is fixed and cannot be changed. Networks using the IP and IPX protocols assign logical addresses (which are made up of the MAC address and the network address) to the devices on the network, This can all become quite complex -- suffice it to say that the network layer takes care of assigning the correct addresses (via IP or IPX) and then uses routers to send the data packets to other networks.

    TCP and SPX (Transport Layer)

    The transport layer is concerned with efficient and reliable trsansportation of the data packets from one network to another. In most cases, a document, e-mail message or other piece of information is not sent as one unit. Instead, it is broken into small data packets, each with header information that identifies its correct sequence and document.

    When the data packets are sent over a network, they may or may not take the same route -- it doesn't matter. At the receiving end, the data packets are re-assembled into the proper order. After all packets are received, a message goes back to the originating network. If a packet does not arrive, a message to "re-send" is sent back to the originating network.

    TCP, paired with IP, is by far the most popular protocol at the transport level. If the IPX protocol is used at the network layer (on networks such as Novell or Microsoft), then it is paired with SPX at the transport layer.

    HTTP, FTP, SMTP and DNS (Session/Presentation/Application Layers)

    Several protocols overlap the session, presentation, and application layers of networks. There protocols listed below are a few of the more well-known:

  • DNS - Domain Name System - translates network address (such as IP addresses) into terms understood by humans (such as URLs)
  • DHCP - Dynamic Host Configuration Protocol - can automatically assign Internet addresses to computers and users
  • FTP - File Transfer Protocol - a protocol that is used to transfer and manipulate files on the Internet
  • HTTP - HyperText Transfer Protocol - An Internet-based protocol for sending and receiving webpages
  • IMAP - Internet Message Access Protocol - A protocol for e-mail messages on the Internet
  • IRC - Internet Relay Chat - a protocol used for Internet chat and other communications
  • POP3 - Post Office protocol Version 3 - a protocol used by e-mail clients to retrieve messages from remote servers
  • SMTP - Simple Mail Transfer Protocol - A protocol for e-mail messages on the Internet

    More...

    Thursday, November 12, 2009

  • An Educator`s Guide to School Networks

    Chapter 1


    What Is Network ?
    A network consists of two or more computers that are linked in order to share resources (such as printers and CDs), exchange files, or allow electronic communications. The computers on a network may be linked through cables, telephone lines, radio waves, satellites, or infrared light beams.

    The two basic types of networks include:

    - Local Area Network (LAN)
    - Wide Area Network (WAN)

    You may also see references to a Metropolitan Area Networks (MAN), a Wireless LAN (WLAN), or a Wireless WAN (WWAN).

    Local Area Network
    A Local Area Network (LAN) is a network that is confined to a relatively small area. It is generally limited to a geographic area such as a writing lab, school, or building. Rarely are LAN computers more than a mile apart.

    In a typical LAN configuration, one computer is designated as the file server. It stores all of the software that controls the network, as well as the software that can be shared by the computers attached to the network. Computers connected to the file server are called workstations. The workstations can be less powerful than the file server, and they may have additional software on their hard drives. On many LANs, cables are used to connect the network interface cards in each computer; other LANs may be wireless. See the Topology, Cabling, and Hardware sections of this tutorial for more information on the configuration of a LAN.

    Wide Area Network
    Wide Area Networks (WANs) connect larger geographic areas, such as Florida, the United States, or the world. Dedicated transoceanic cabling or satellite uplinks may be used to connect this type of network.

    Using a WAN, schools in Florida can communicate with places like Tokyo in a matter of minutes, without paying enormous phone bills. A WAN is complicated. It uses multiplexers to connect local and metropolitan networks to global communications networks like the Internet. To users, however, a WAN will not appear to be much different than a LAN.

    Advantages of Installing a School Network
  • Speed. Networks provide a very rapid method for sharing and transferring files. Without a network, files are shared by copying them to memory cards or discs, then carrying or sending the discs from one computer to another. This method of transferring files (referred to as sneaker-net) can be very time-consuming.
  • Cost. Networkable versions of many popular software programs are available at considerable savings when compared to buying individually licensed copies.
  • Security. Files and programs on a network can be designated as "copy inhibit," so that you do not have to worry about illegal copying of programs. Also, passwords can be established for specific directories to restrict access to authorized users.
  • Centralized Software Management. One of the greatest benefits of installing a network at a school is the fact that all of the software can be loaded on one computer (the file server). This eliminates that need to spend time and energy installing updates and tracking files on independent computers throughout the building.
  • Resource Sharing. Sharing resources is another advantage of school networks. Most schools cannot afford enough laser printers, fax machines, modems, scanners, and CD players for each computer. However, if these or similar peripherals are added to a network, they can be shared by many users.
  • Electronic Mail. The presence of a network provides the hardware necessary to install an E-Mail system. E-mail aids in personal and professional communication for all school personnel, and it facilitates the dissemination of general information to the entire school staff. Electronic mail on a LAN can enable students to communicate with teachers and peers at their own school. If the LAN is connected to the Internet, students can communicate with others throughout the world.
  • Flexible Access. School networks allow students to access their files from computers throughout the school. Students can begin an assignment in their classroom, save part of it on a public access area of the network, then go to the media center after school to finish their work. Students can also work cooperatively through the network.
  • Workgroup Computing. Collaborative software allows many users to work on a document or project concurrently. For example, educators located at various schools within a county could simultaneously contribute their ideas about new curriculum standards to the same document, spreadsheets, or website.

    Disadvantages of Installing a School Network
  • Expensive to Install. Although a network will generally save money over time, the initial costs of installation can be prohibitive. Cables, network cards, routers, and software are expensive, and the installation may require the services of a technician.
  • Requires Administrative Time. Proper maintenance of a network requires considerable time and expertise. Many schools have installed a network, only to find that they did not budget for the necessary administrative support.
  • File Server May Fail. Although a file server is no more susceptible to failure than any other computer, when the files server "goes down," the entire network may come to a halt. When this happens, the entire school may lose access to necessary programs and files.
  • Cables May Break. The Topology chapter presents information about the various configurations of cables. Some of the configurations are designed to minimize the inconvenience of a broken cable; with other configurations, one broken cable can stop the entire network.
  • Must Monitor Security Issues. Wireless networks are becoming increasingly common; however, security can be an issue with wireless networks.



    More...

  • Linux Home Server HOWTO
    Chapter 8 - Domain Name System (BIND)
    Version: - bind 9.3.2


    The Domain Name System (or Service) provides a naming resolution service that makes it easy for us humans to use the Internet, among other tasks. Every computer located on the Internet that is publicly accessible uses an unique Internet address, but these Internet addresses are numerical in nature and difficult to remember. To download the latest Linux kernel I point my browser to http://www.kernel.org/, but the server is located at the Internet address of 204.152.191.5, I know which address I would prefer to remember.

    The global DNS provides listings for publicly accessible addresses. If you need to access any computer resources inside your own network and your network is using RFC1918

    This chapter will provide the steps necessary to configure your own DNS server to assist in internal name resolution and to provide a caching service for external domains. The Berkeley Internet Name Domain (BIND) software is installed on most Linux distributions, and is also available from the Internet Systems Consortium site.





    If you are using a dynamic IP address and you would like to host your own website and email servers, then you will also need to review the Dynamic DNS details in Chapter 5.


    Initial Configuration
    For a Linux host to use DNS, the system resolver must be told which name servers to use. This information is stored in the /etc/resolv.conf file. As with any configuration, we should always backup the original configuration file before editing it.


    [bash]# cp /etc/resolv.conf /etc/resolv.conf.original
    [bash]# vi /etc/resolv.conf


    The resolver on the new DNS server needs to be adjusted so it points to itself for name resolution. Be sure to substitute "example.com" for the domain(s) you are configuring.


    search example.com
    nameserver 127.0.0.1


    The search parameter defines a list of domains that will be searched when doing hostname queries. The nameserver parameter lists the DNS servers that the host should use for name resolution, in this case itself.

    For more information on the system resolver, type "man resolv.conf" at the command prompt.

    Setting Daemon Options
    The name of the DNS daemon in the BIND package is funnily enough called named, and the main configuration file is located in /etc/named.conf. The configuration can be quite daunting to the new, so lets back it up before making any changes.


    [bash]# cp /etc/named.conf /etc/named.conf.original
    [bash]# vi /etc/named.conf


    The main configuration file is split into many sections. To configure named to only allow queries from the local server and internal network hosts, add the "listen-on" and "allow-query" options. This will restrict unwanted queries on your server.


    options {
    directory "/var/named";
    dump-file "/var/named/data/cache_dump.db";
    statistics-file "/var/named/data/named_stats.txt";
    /*
    * If there is a firewall between you and nameservers you want
    * to talk to, you might need to uncomment the query-source
    * directive below. Previous versions of BIND always asked
    * questions using port 53, but BIND 8.1 uses an unprivileged
    * port by default.
    */
    //query-source address * port 53;
    listen-on { 127.0.0.1; 192.168.1.1; };
    allow-query { 127.0.0.1; 192.168.1.0/24; };
    };


    If your DNS server is located behind a firewall and is having difficulty with resolving names, you may need to uncomment this directive.


    query-source address * port 53;


    The "." zone below tells named to check this file for a list of the root name servers, so it knows where to send external queries. This enables the caching nameserver feature of BIND, by forwarding any unknown requests to the root nameservers listed in the file. This zone should already be listed in the configuration.


    zone "." IN {
    type hint;
    file "named.ca";
    };


    You may find that sending every new DNS query to the root name servers will be a little slow. This can be improved by sending all of your queries to a quicker "upstream" DNS server which will process your request for you. An upstream DNS server (like the ones at your ISP) may already have the query you're after in its cache, or it will normally have a faster backbone link to the root name servers.

    To use forwarders you need to have at least one upstream DNS server IP address. Forwarders are a configuration option which needs to be placed inside the "options" section (place under the "allow-query" option above).


    #Place INSIDE 'options'

    forward first;
    forwarders { xxx.xxx.xxx.xxx; xxx.xxx.xxx.xxx; }; <-- Add your ISP's DNS servers in here (IP addresses ONLY)






    Pay particular attention to the format of the configuration file, missing semicolons will cause the daemon to function irrationally, if at all.


    Adding Your Domain
    To provide resolution for the network and computer resources inside your own private network, you need to configure your DNS with your own master DNS zone. The examples below will now guide the configuration of a master zone. These examples are more designed to provide DNS for an internal private network (the home or small office user), and should be used only as a basis for a full authoritative zone. It is also suggested that you configure your domain externally for people to find you on the Internet, see DDNS Service Providers in Chapter 5 if you don't have external name resolution.

    Firstly we need to set the zone information in the same named configuration file we used earlier, place the following configuration settings at the bottom of the "/etc/named.conf" file.


    [bash]# vi /etc/named.conf






    The "example.com" domain name must be substituted for your domain in the following examples.



    zone "example.com" IN {
    type master;
    file "data/master-example.com";
    allow-update { none; };
    };

    zone "1.168.192.in-addr.arpa" IN {
    type master;
    file "data/reverse-192.168.1";
    allow-update { none; };
    };


    The "example.com" zone will be configured as a master using the file "master-example.com" to store all the details about the zone entities (inside the "/var/named/chroot/var/named/data" directory).

    You should notice the configuration file is located inside a chroot() jail directory, this is a secure configuration typical of BIND installations. We will not cover chroot here, but be aware of the importance of the directory structure (some Linux versions may differ slightly though).


    [bash]# vi /var/named/chroot/var/named/data/master-example.com


    The following is an example FORWARD zone file for the "example.com" domain name, it is using private addressing for internal only name resolution.


    ;
    ; Zone File for "example.com" - Internal Use ONLY
    ;
    $TTL 1D
    @ IN SOA galaxy.example.com. sysadmin.example.com. (
    10 ; Serial
    8H ; Refresh
    2H ; Retry
    4W ; Expire
    1D ) ; Minimum
    ;
    IN NS galaxy ; Name Server for the domain
    IN MX 10 galaxy ; Mail Exchange
    ;
    example.com. IN A 192.168.1.1 ; IP address for the domain 'example.com'
    galaxy IN A 192.168.1.1 ; IP address for 'galaxy'
    www IN CNAME galaxy ; 'galaxy' is also known as www
    ftp IN CNAME galaxy ; 'galaxy' is also known as ftp
    ;
    wkstn1 IN A 192.168.1.201 ; MANUAL IP address entry for 'wkstn1'
    wkstn2 IN A 192.168.1.202 ; MANUAL IP address entry for 'wkstn2'


    The forward zone file allows name resolution from NAME to IP address. To allow name resolution from IP address to NAME, we need to configure a REVERSE zone file.


    [bash]# vi /var/named/chroot/var/named/data/reverse-192.168.1


    The reverse zone file looks similar to the forward zone file, however you will note the IP addresses are listed first, with the names listed after the pointer directive (PTR).


    ;
    ; Reverse File for network "192.168.1.0/24" - Internal ONLY
    ;
    $TTL 1D
    @ IN SOA galaxy.example.com. sysadmin.example.com. (
    10 ; Serial
    8H ; Refresh
    2H ; Retry
    4W ; Expire
    1D ) ; Minimum
    ;
    IN NS galaxy.example.com.
    1 IN PTR galaxy.example.com.
    ;
    201 IN PTR wkstn1.example.com. ; MANUAL entry for 'wkstn1' reverse delegation
    202 IN PTR wkstn2.example.com. ; MANUAL entry for 'wkstn2' reverse delegation






    When configuring the forward and reverse zone files, ensure the IP addresses and the host names are identical in both files. Also, DO NOT add DHCP names and addresses into the files, they will change over time - this can be resolved by using Dynamic DNS below.


    The following are some of the common parameters (and definitions) required to configure our zone files.


    Parameter


    Definition


    $TTL


    Time To Live for the zone file


    IN


    The Internet system


    SOA


    Start Of Authority to administer zone


    NS


    Name Server for the zone


    MX


    Mail Exchange for the zone (needs a priority value)


    A


    Address records for hosts / network equipment


    CNAME


    Canonical name for an alias (points to "A" record)


    This line specifies that the host galaxy.example.com is the SOA for the zone, and that sysadmin.example.com is the email address of the zone's technical contact (sysadmin@example.com). It is important to note that a period "." at the end of the domain names indicates they are fully qualified.


    @ IN SOA galaxy.example.com. sysadmin.example.com.






    The periods "." located at the end of fully qualified domain names are required. Failure to use periods for FQDNs will cause irregular name resolution.


    The following entry specifies that galaxy.example.com is the mail exchange for the zone, which has been set to priority 10. Leave this as standard unless you know what you are doing, or remove it if you are not running your own email servers.


    MX 10 galaxy ; Mail Exchange


    That completes the configuration of named and the new forward/reverse zone files for our "example.com" domain name. The zone files now need to be chown'd to the named user account and a symbolic link created to the new chroot() jailed file.


    [bash]# chown named.named /var/named/chroot/var/named/data/master-example.com
    [bash]# ln -s /var/named/chroot/var/named/data/master-example.com /var/named/data/master-example.com

    [bash]# chown named.named /var/named/chroot/var/named/data/reverse-192.168.1
    [bash]# ln -s /var/named/chroot/var/named/data/reverse-192.168.1 /var/named/data/reverse-192.168.1






    The file naming convention is typical of Fedora Core and may differ slightly between Linux distributions.


    Checking Your Work
    There are several small programs that are in the BIND package that allow integrity checking of the named configuration and zone files. These are great tools to maintain your sanity for testing purposes, as named can be quite particular about problems in the configuration and zone files.


    [bash]# named-checkconf /etc/named.conf






    The most common errors for misconfiguration in the named file are missing semicolons ";" after parameter settings.


    The zone file should be checked for format consistency, and should resemble the above example.com zone file (substitutions should be made for the domain and hosts being configured).


    [bash]# named-checkzone -d example.com /var/named/data/master-example.com


    loading "example.com" from "/var/named/master-example.com" class "IN"
    zone example.com/IN: loaded serial 10
    OK


    The reverse zone file should also be checked for any errors.


    [bash]# named-checkzone -d 1.168.192.in-addr.arpa /var/named/data/reverse-192.168.1


    loading "1.168.192.in-addr.arpa" from "/var/named/data/reverse-192.168.1" class "IN"
    zone 1.168.192.in-addr.arpa/IN: loaded serial 10
    OK






    The most common errors for misconfiguration in zone files are missing periods "." at the end of fully qualified domain names - especially for the SOA line.


    Starting BIND
    After BIND has been configured and there are no errors being returned from the check applications, it is time to set the runlevels and start the service.


    [bash]# chkconfig --level 2345 named on
    [bash]# /etc/init.d/named restart


    A manual check after setting the runlevels confirms that named should start properly after a system reboot.


    [bash]# chkconfig --list named


    Once the service has been started, check the system log to see if there are any runtime errors, and that your newly configured zone is being served successfully. The entries "zone example.com/IN: loaded serial 10" and "zone 1.168.192.in-addr.arpa/IN: loaded serial 10" confirms the zone load was successful and can now be queried.


    [bash]# grep named /var/log/messages



    galaxy named[19111]: starting BIND 9.3.2 -u named -t /var/named/chroot
    galaxy named[19111]: found 2 CPUs, using 2 worker threads
    galaxy named[19111]: loading configuration from '/etc/named.conf'
    galaxy named[19111]: listening on IPv4 interface lo, 127.0.0.1#53
    galaxy named[19111]: listening on IPv4 interface eth1, 192.168.1.1#53
    galaxy named[19111]: command channel listening on 127.0.0.1#953
    galaxy named[19111]: zone 0.in-addr.arpa/IN: loaded serial 42
    galaxy named[19111]: zone 0.0.127.in-addr.arpa/IN: loaded serial 1997022700
    galaxy named[19111]: zone 1.168.192.in-addr.arpa/IN: loaded serial 10 <-- Successful load
    galaxy named[19111]: zone 255.in-addr.arpa/IN: loaded serial 42
    galaxy named[19111]: zone example.com/IN: loaded serial 10 <-- Successful load
    galaxy named[19111]: zone localdomain/IN: loaded serial 42
    galaxy named[19111]: zone localhost/IN: loaded serial 42
    galaxy named[19111]: running


    Testing The Server
    Now that you have configured your Linux server to query itself for DNS and you have configured the caching server and added your own zone files, its time to test that everything we did was successful. Using the dig application we can check a name resolution for www.example.com, remembering that www in our configuration was an alias that really pointed to galaxy.example.com.


    [bash]# dig www.example.com


    ; <<>> DiG 9.3.2 <<>> www.example.com
    ;; global options: printcmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48535 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.example.com. IN A ;; ANSWER SECTION: www.example.com. 86400 IN CNAME galaxy.example.com. galaxy.example.com. 86400 IN A 192.168.1.1 <-- Correct IP address returned

    ;; AUTHORITY SECTION:
    example.com. 86400 IN NS galaxy.example.com.

    ;; Query time: 3 msec
    ;; SERVER: 127.0.0.1#53(127.0.0.1) <-- Query from local server
    ;; WHEN: Wed May 17 21:16:38 2006
    ;; MSG SIZE rcvd: 84


    The above results return the true CNAME for www, and also the A record for galaxy.example.com being 192.168.1.1. In the footer area the query server is set as 127.0.0.1#53, this is the nameserver we originally set in the /etc/resolv.conf file, itself.

    We can now check a complete listing of the whole zone file with the following command.


    [bash]# dig example.com AXFR @localhost


    ; <<>> DiG 9.3.2 <<>> example.com AXFR @localhost
    ; (1 server found)
    ;; global options: printcmd
    example.com. 86400 IN SOA galaxy.example.com. sysadmin.example.com. 10 28800 7200 2419200 86400
    example.com. 86400 IN NS galaxy.example.com.
    example.com. 86400 IN MX 10 galaxy.example.com.
    example.com. 86400 IN A 192.168.1.1
    ftp.example.com. 86400 IN CNAME galaxy.example.com.
    galaxy.example.com. 86400 IN A 192.168.1.1
    wkstn1.example.com. 86400 IN A 192.168.1.201
    wkstn2.example.com. 86400 IN A 192.168.1.202
    www.example.com. 86400 IN CNAME galaxy.example.com.
    example.com. 86400 IN SOA galaxy.example.com. sysadmin.example.com. 10 28800 7200 2419200 86400
    ;; Query time: 2 msec
    ;; SERVER: 127.0.0.1#53(127.0.0.1) <-- Query from local server
    ;; WHEN: Wed May 17 21:17:21 2006
    ;; XFR size: 9 records (messages 1)


    The most important test is that we are able to successfully resolve domain names that are listed externally to our private network, and cached from the many Internet DNS servers.


    [bash]# dig fedora.redhat.org


    ; <<>> DiG 9.3.2 <<>> fedora.redhat.org
    ;; global options: printcmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2193 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;fedora.redhat.org. IN A ;; ANSWER SECTION: fedora.redhat.org. 120 IN A 65.38.107.197 ;; AUTHORITY SECTION: redhat.org. 86400 IN NS ns1.ireithost.com. redhat.org. 86400 IN NS ns2.ireithost.com. ;; ADDITIONAL SECTION: ns1.ireithost.com. 156739 IN A 65.38.107.198 ns2.ireithost.com. 156739 IN A 65.38.109.156 ;; Query time: 395 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) <-- Query from local server
    ;; WHEN: Wed May 17 21:18:36 2006
    ;; MSG SIZE rcvd: 132


    Our last test is to confirm that reverse name lookup is available by querying the reverse delegation zone.


    [bash]# host 192.168.1.201


    201.1.168.192.in-addr.arpa domain name pointer wkstn1.example.com.


    Now that the DNS set up is complete, the rest of the workstations inside the private network must be configured to use DNS 192.168.1.1 as the primary name server. For Linux clients this should be listed in /etc/resolv.conf, for Windows clients this should be configured in network settings.

    If your internal network is using DHCP to provide IP addresses to your workstations, then "option domain-name-servers 192.168.1.1;" should be set in your "/etc/dhcpd.conf" configuration file.

    Configuring Dynamic DNS
    As you would have noticed, configuring the forward and reverse zones for a single domain name can take some time to set up correctly and the information these zone files contain are pretty much static, ie they shouldn't change much. However when an IP address or name does change the information in the zone files also need to be changed otherwise the incorrect details will be returned from our DNS server when queried.

    To automate this, we use Dynamic DNS. The Internet Systems Consortium corporation (ISC) write both of the BIND and DHCP server suites that are utilised within Fedora Core, when both of these server applications are utilised together, they are able to update themselves whenever details change between DHCP and DNS. This allows an easy method for the forward and reverse DNS zone files to be updated when a dynamic host is allocated an IP address from the DHCP server.





    The following configuration adjustments assume you have already configured your ISC DHCP daemon in accordance with Chapter 10; please do this first.


    To configure Dynamic DNS, we can generate a basic set of configuration files by running the rndc-confgen application. The first half of the output goes into the "/etc/rndc.conf" file, while the remaining half of the output goes into the "/etc/named.conf" file.


    [bash]# rndc-confgen


    key "rndckey" { <-- Insert first section into /etc/rndc.conf file
    algorithm hmac-md5;
    secret "rZvmZb1cOtvkUfacVZ6oKA==";
    };

    options {
    default-key "rndckey";
    default-server 127.0.0.1;
    default-port 953;
    }; <-- End of first section

    key "rndckey" { <-- Insert second section into /etc/named.conf file
    algorithm hmac-md5;
    secret "rZvmZb1cOtvkUfacVZ6oKA==";
    };

    controls {
    inet 127.0.0.1 port 953
    allow { 127.0.0.1; } keys { "rndckey"; };
    }; <-- End of second section






    Ensure the "include /etc/rndc.key" directive is removed (or commented out) from both the /etc/rndc.conf and /etc/named.conf files, as you have now created a new configuration. Only ensure there is only ONE "controls" directive in /etc/named.conf.

    To ensure that all zone updates are secure, the update requests and transfers are covered using a secure key (MD5 message hash algorithm) which can be generated easily with the dnssec-keygen application. This key then needs to be replicated and shared with the DNS and DHCP server configuration files.


    [bash]# dnssec-keygen -a HMAC-MD5 -b 128 -n USER DYNAMIC_DNS_KEY
    [bash]# cat Kdynamic_dns_key*.private


    Private-key-format: v1.2
    Algorithm: 157 (HMAC_MD5)
    Key: LBxD9REd0XAEwPYOTZMS0w== <-- Shared MD5 Algorithm






    The "Kdynamic_dns_key*" file generated in the above step is safe to delete after the DNS and DHCP configuration files have been updated.


    The DNS server configuration file needs to be updated with the secure key declaration, and the zone file settings will also need to be allowed to update if they are done so with the secure key.


    [bash]# vi /etc/named.conf


    key DYNAMIC_DNS_KEY {
    algorithm hmac-md5;
    secret LBxD9REd0XAEwPYOTZMS0w==; <-- Shared MD5 Algorithm };


    zone "example.com" IN {
    type master;
    file "data/master-example.com";
    allow-update { key DYNAMIC_DNS_KEY; }; <-- Allow "key" update
    };

    zone "1.168.192.in-addr.arpa" IN {
    type master;
    file "data/reverse-192.168.1";
    allow-update { key DYNAMIC_DNS_KEY; }; <-- Allow "key" update
    };


    Now the DHCP server configuration file needs to updated with the same secure key declarations. The server is also told where the primary zone files are stored (on 127.0.0.1) so they can update the DNS server.


    [bash]# vi /etc/dhcpd.conf


    key DYNAMIC_DNS_KEY {
    algorithm hmac-md5;
    secret LBxD9REd0XAEwPYOTZMS0w==; <-- Shared MD5 Algorithm
    }

    zone example.org. {
    primary 127.0.0.1;
    key DYNAMIC_DNS_KEY; <-- Allow "key" update
    }

    zone 1.168.192.in-addr.arpa. {
    primary 127.0.0.1;
    key DYNAMIC_DNS_KEY; <-- Allow "key" update
    }






    The secure key must match in both the "/etc/named.conf" and "/etc/dhcpd.conf" files otherwise Dynamic DNS will not work effectively.


    The DHCP server must now be configured to allow client updates, make the following two changes to your "/etc/dhcpd.conf" file.


    [bash]# vi /etc/dhcpd.conf


    #
    # DHCP Server Config File
    #
    ddns-update-style interim; <--- Change these in /etc/dhcpd.conf
    allow client-updates; <--- Change these in /etc/dhcpd.conf


    The DHCP daemon now needs to be configured for Dynamic DNS updates.


    [bash]# vi /etc/sysconfig/named


    OPTIONS=-4
    ENABLE_ZONE_WRITE=yes
    ROOTDIR=/var/named/chroot






    For detailed information about named daemon, type "man named" at the command prompt.


    Now that the Dynamic DNS configurations are complete, the services need to be restarted.


    [bash]# /etc/init.d/dhcpd restart
    [bash]# /etc/init.d/named restart


    Allow your Dynamic DNS configuration a little time to run (enough for some DHCP clients to renew IP Addresses) and then check the syslog to see if your server is successfully updating the forward and reverse zone files with the new client information.


    [bash]# grep dhcpd /var/log/messages


    dhcpd: if wkstn3.example.com IN TXT "3168f50e8140ac8a1c8b84d809c6adbefe" rrset exists and wkstn3.example.com IN A 192.168.1.200 rrset exists delete wkstn3.example.com IN A 192.168.1.200: success.
    dhcpd: if wkstn3.example.com IN A rrset doesn't exist delete wkstn3.example.com IN TXT "3168f50e8140ac8a1c8b84d809c6adbefe": success.
    dhcpd: removed reverse map on 200.1.168.192.in-addr.arpa.
    dhcpd: DHCPRELEASE of 192.168.1.200 from 00:13:d4:2e:3b:d6 (wkstn3) via eth1 (found)
    dhcpd: DHCPDISCOVER from 00:13:d4:2e:3b:d6 via eth1
    dhcpd: DHCPOFFER on 192.168.1.200 to 00:13:d4:2e:3b:d6 (wkstn3) via eth1
    dhcpd: Added new forward map from wkstn3.example.com to 192.168.1.200
    dhcpd: added reverse map from 200.1.168.192.in-addr.arpa. to wkstn3.example.com


    The named daemon will also add entries to the syslog to identify correct/successful operation.


    [bash]# grep named /var/log/messages


    named: client 127.0.0.1#32769: updating zone 'example.com/IN': adding an RR at 'wkstn3.example.com' A
    named: client 127.0.0.1#32769: updating zone 'example.com/IN': adding an RR at 'wkstn3.example.com' TXT
    named: client 127.0.0.1#32769: updating zone '1.168.192.in-addr.arpa/IN': deleting rrset at '200.1.168.192.in-addr.arpa' PTR
    named: client 127.0.0.1#32769: updating zone '1.168.192.in-addr.arpa/IN': adding an RR at '200.1.168.192.in-addr.arpa' PTR


    A forward lookup can be checked against a known DHCP client to ensure a successful lookup.


    [bash]# host wkstn3.example.com


    wkstn3.example.com has address 192.168.1.200


    A reverse lookup can also be done to ensure reverse delegation can also be confirmed.


    [bash]# host 192.168.1.200


    200.1.168.192.in-addr.arpa domain name pointer wkstn3.example.com


    If you have got this far, you have done well - enjoy a fully automated Dynamic DNS solution.

    More...

    Monday, November 9, 2009

    Linux Home Server HOWTO
    Chapter 5 - Broadband Connectivity


    Its now time to plug in our modem and dial up the information super highway, look out Internet here we come. While we are inside this chapter, we will also explore the concepts of Dynamic DNS and how it can be automated for users that have Dynamic IP accounts.






    Detailed technical aspects of individual modems will not be covered here, please consult your user manual for information on key modem settings. If the modem came preconfigured from your ISP, please contact them for any technical assistance.


    Ethernet Modems
    The most typical Internet connection type for home users is by means of a modem, whether it be dialup, ethernet, cable, or wireless, the concepts are all virtually the same. Today's modems are quite advanced and come with many neat security features to help protect the average user from the everyday threats out on the Internet.

    Broadband modems generally operate in two different modes, that of 'bridged' or 'routed'.

  • In routed mode the modem is configured to connect to the ISP, and the IP address which is allocated to the broadband account is provided to the modem. The modem is also connected to the computer on a separate internal network which it shields from the Internet. The modem acts as a router.
  • In bridged mode the modem opens a virtual tunnel to the ISP and the host computer dials a PPP connection over that virtual link. The modem operates as a dumb device while the host computer handles the connection and the related security for the Internal hosts across the link. The modem provides a link and the connection is established between the computer and ISP. The IP address is allocated to the computer, normally via the ppp0 device.

    There are pros and cons about both connection types, particularly if it is a modem router which is capable of stateful packet inspection and maintaining a secure state for the hosts on the private network. This HOWTO will concentrate on the bridging type connection, and provide the means for your server to establish, maintain and secure its own connection.

    To connect to an ethernet modem the server must be fitted with a second ethernet device; common practice is to identify your "external" public network interface as eth0 (this is also consistent with this HOWTO's documentation). The ethernet device will be configured and controlled the same way as described in the previous chapter, with one minor difference being the protocol type assigned to the device. The ethernet device (and modem) are only maintaining a virtual tunnel over which the PPP link will travel, so it needs to be configured with BOOTPROTO=none parameter.


    [bash]# vi /etc/sysconfig/network-scripts/ifcfg-eth0



    # External Ethernet Device (BRIDGED MODE - NO PROTOCOL)
    DEVICE=eth0
    TYPE=Ethernet
    ONBOOT=yes
    USERCTL=no
    BOOTPROTO=none <-- No protocol defined here.
    PEERDNS=no
    HWADDR=00:00:21:E0:B8:B9
    IPV6INIT=no


    After the ethernet device has been configured to operate in bridged mode, use some ethernet cable to connect the modem to the eth0 device. The modem should be able to connect to the exchange (or cable service), however the link still needs to be configured with the PPPoE settings.






    When the ethernet "eth0" device is brought to the active state it will not be allocated (or broadcast for) an IP address and therefore not appear in the routing table as it is in "bridged" mode.


    PPPoE Configuration
    When you connect to the Internet using an old style dialup modem, your computer communicates over the telephone system and back to your ISP using PPP (Point-to-Point Protocol). The broadband system is virtually the same but now your computer uses PPPoE (Point-to-Point Protocol over Ethernet) which is a modified version designed for the newer broadband specifications.

    Roaring Penguin provides a free Linux PPPoE client that is already installed as a base package in many distributions. The PPPoE client is ideally suited to USB and ethernet (bridged mode) modems where a virtual link has already been established by the modem, and the PPPoE client handles the remaining dialup and authentication functions over that link. When an ethernet modem connects using the routed mode, it does so by using a similar PPPoE client preconfigured at the modem.

    The PPPoE configuration file is stored in the same location with the other networking device files, however it is slightly more detailed than the other files, as shown below.


    [bash]# vi /etc/sysconfig/network-scripts/ifcfg-ppp0



    TYPE=xDSL
    DEVICE=ppp0
    PROVIDER=ppp0
    USER='username@myisp.com'
    ONBOOT=yes
    DEMAND=no
    USERCTL=no
    PERSIST=yes
    PEERDNS=no
    DEFROUTE=yes
    ETH=eth0
    BOOTPROTO=dialup
    FIREWALL=NONE
    PING=.
    PPPOE_TIMEOUT=80
    LCP_INTERVAL=20
    LCP_FAILURE=3
    CONNECT_TIMEOUT=60
    CONNECT_POLL=6
    CLAMPMSS=1412
    SYNCHRONOUS=no
    PIDFILE=/var/run/pppoe-adsl.pid
    IPV6INIT=no



    Parameter


    Details


    DEVICE


    The logical name for the PPP device


    PROVIDER


    A friendly name for the ISP


    USER


    The ISP account username (password is specified in separate file)


    ONBOOT


    Specifies whether the devices should start when the system starts (depending on network service)


    USERCTL


    Directs that only root, or all system users can control the device


    PERSIST


    Will attempt to redial the connection if the link is disconnected


    PEERDNS


    Import the DNS nameserver settings into /etc/resolv.conf (careful if running own DNS)


    ETH


    Tells PPPoE client which network device to use


    BOOTPROTO


    The protocol type used to initialise the device (static | dhcp | none)


    Now that the PPPoE connection is configured, the authentication details for the account need to be stored so the client can automate the login process.

    You should notice in the credentials file below, that the USER and PROVIDER details specified in the above configuration file are provided as the first two fields in the file. This binds the details together so the PPPoE client knows which details belong to which ISP connection (it is possible to have multiple PPP connections listed here).


    [bash]# vi /etc/ppp/pap-secrets



    "username@myisp.com" "ppp0" "YOUR_ISP_PASSWORD"


    As with any authentication credentials, they should be kept secure from unauthorised access. This is more so if the server is accessible by other system users.


    [bash]# chmod 600 /etc/ppp/pap-secrets


    The PPPoE client implementation also uses a small server application that listens for discovery frames from the remote connection. The following settings are required for the pppoe-server.


    [bash]# vi /etc/ppp/pppoe-server-options



    require-pap
    login
    lcp-echo-interval 10
    lcp-echo-failure 2


    The PPPoE configuration is now completed and the connection is ready to be tested. It is assumed that your modem is properly connected and if an ethernet modem is being used, that the extra network device (eth0) is also configured and ready.

    The easiest way to test the interface is to restart the networking service, which will test all of the devices by stopping and then starting them using the initscripts.


    [bash]# /etc/init.d/network restart


    By checking the syslog you should be able to see if the connection was successful. If the connection was not successful, you should be provided with some error messages. Below is a successful connection.


    [bash]# tail /var/log/messages



    galaxy network: Bringing up interface eth1: succeeded
    galaxy pppd[10190]: pppd 2.4.2 started by root, uid 0
    galaxy pppd[10190]: Using interface ppp0
    galaxy pppd[10190]: Connect: ppp0 <--> /dev/pts/4
    galaxy pppoe[10191]: PPP session is 5036
    galaxy pppd[10190]: CHAP authentication succeeded
    galaxy pppd[10190]: local IP address xxx.xxx.xxx.xxx <-- Your DHCP Address
    galaxy pppd[10190]: remote IP address 202.154.95.169
    galaxy network: Bringing up interface ppp0: succeeded


    Specific connection details of the ppp0 device can also be provided with the ifconfig command. This should identify the local (your) IP address, the remote IP address and other details like connection statistics.


    [bash]# ifconfig ppp0



    ppp0


    Link encap:Point-to-Point Protocol
    inet addr:xxx.xxx.xxx.xxx P-t-P:202.154.95.169 Mask:255.255.255.255
    UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1492 Metric:1
    RX packets:2753 errors:0 dropped:0 overruns:0 frame:0
    TX packets:2636 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:3
    RX bytes:1470035 (1.4 Mb) TX bytes:472461 (461.3 Kb)


    The device can be manually controlled with the following commands, these should start to look familiar now as you use them often to control your connections.


    [bash]# ifup ppp0
    bash]# ifdown ppp0


    Now that we are finally connected to the Internet we need to make sure we can send data using the link. Remember the configuration parameter we earlier used called DEFROUTE=yes, well that attribute should have placed a default gateway into the routing table when the ppp0 device connected, this now allows any packets that are not destined for the private network to be routed out to the Internet when the device is connected.


    [bash]# route -n



    Kernel IP routing table
    Destination Gateway Genmask Flags Metric Ref Use Iface
    202.154.95.169 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0 <-- Remote Interface
    192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
    0.0.0.0 202.154.95.169 0.0.0.0 UG 0 0 0 ppp0 <-- Default Gateway






    The eth0 device does not get listed in the routing table, it is only providing a virtual connection for the ppp0 link to cross.


    Dynamic DNS Services
    Dynamic DNS is a service offered by many organisations that allow general Internet users to bind a Fully Qualified Domain Name to a dynamic IP address, something that is normally only achieved with a static IP address.

    The concept is simple, you have a fully qualified domain name that you want to point to your home computer, the only problem is that your ISP account uses dynamic IP addresses and it changes every time your server reconnects to the Internet. DDNS allows dynamic IP account users a service where their DNS records are updated if their connection (IP Address) details change, and then allows the updated information to be propagated throughout the rest of the DNS world. With an always on server and a reliable Internet account, it is technically rare for an IP address to change, so many home users are embracing the capability.

    Many new broadband modems are capable of supporting DDNS and automatic updates using preconfigured software internal to the modem. We will provide our own automation script a little further on.





    DDNS is only used with globally routed IP addresses which are external of your private network. This is not the internal private network addresses. Basic DNS principles for private networks are covered in Chapter 8.


    To use DDNS you need the following:
  • a registered domain name,
  • a dynamic IP address,
  • an account with a DDNS service provider, and
  • a means to update the service (next section).

    An Internet domain name was considered as one of our planning principles in Chapter 2. To fully implement our networking services for the external network, a domain name is required. InterNIC maintains this list (http://www.internic.net/origin.html) of Domain Registrars listed by country if you need to register a domain.

    Some Dynamic DNS service providers also offer sub domain names that can be registered and used for free, the names are similar to "yourname.no-ip.org" or "yourname.homelinux.org". If you are happy using a simple sub domain instead of registering (and paying for) your own domain name, then you should have a look at some of the services offered by the Dynamic DNS service providers.

    Some of the DDNS service providers are listed in the following table. Most offer free accounts that will allow the registration of a few domain names, providing the basic requirements for home users. Some providers offer extra services like backup mail server for times that your Internet connection may be offline, however these extra services may not be free. If in doubt about the services provided, please contact the relevant organisation.


    Organisation


    Website


    ZoneEdit


    http://www.zoneedit.com/


    No-IP.com


    http://www.no-ip.com/


    DynDNS.org


    http://www.dyndns.org/


    DHS International


    http://www.dhs.org/


    DyNS


    http://www.dyns.cx/


    Cn99


    http://www.3322.org/


    DynDNS.DK


    http://dyndns.dk/


    eNom, Inc


    http://www.enom.com/


    TZODNS


    http://www.tzo.com/


    At this point you will need to configure your registered domain name using one of the DDNS service provider accounts. Please consult their online documentation for assistance in this task.





    You will need to register your host (ie. galaxy.example.com) against your present dynamic IP address. You should also now add an "alias" (or CNAME) of "www" which points to galaxy.example.com - substitute for your specific domain. Be sure to set an MX (mail exchange) record for your domain if you plan on setting up a mail server for your network.


    Dynamic DNS Automation
    The key to effective Dynamic DNS is ensuring that whenever your dynamic IP address changes on your broadband account, that the changes are sent to your DDNS service promptly so they can be replicated across the entire DNS.

    This can be achieved by editing your ppp connection script, and placing a wget HTTP request towards the bottom of the script to execute after the dialup connection has been called. The following update is for a zoneedit.com DDNS account.


    [bash]# vi /etc/ppp/ip-up.local



    wget -O - --http-user=username --http-passwd=password --no-check-certificate \
    "https://dynamic.zoneedit.com/auth/dynamic.html?host=galaxy.example.com"






    Always check the wget command in a terminal window first, this allows you to debug it slightly and view (or install) any SSL certificates that are associated with the website.


    You should be aware that while the above communication is using the HTTPS protocol which provides some level of confidentiality for your account details, the executing command line can be viewed by any local user simply with the ps command. This is an important consideration if normal users are going to have access on the server.

    The output of the above command looks similar to this.


    [bash]# wget -O - --http-user=username --http-passwd=password --no-check-certificate \
    "https://dynamic.zoneedit.com/auth/dynamic.html?host=galaxy.example.com"



    --21:28:12-- https://dynamic.zoneedit.com/auth/dynamic.html?host=galaxy.example.com
    => `-'
    Resolving dynamic.zoneedit.com... 69.72.142.98
    Connecting to dynamic.zoneedit.com[69.72.142.98]:443... connected.
    WARNING: Certificate verification error for dynamic.zoneedit.com: self signed certificate
    WARNING: certificate common name `localhost.localdomain' doesn't match requested host name `dynamic.zoneedit.com'.
    HTTP request sent, awaiting response... 200 OK
    Length: 109 [text/html]

    0% [ ] 0 --.--K/s
    <success CODE="200" TEXT="Update succeeded." ZONE="example.com" HOST="galaxy.example.com" IP="xxx.xxx.xxx.xxx">
    100%[====================================================================>] 109 --.--K/s

    21:28:17 (1.93 MB/s) - `-' saved [109/109]


    The above solution ensures that any time the ppp0 interface is brought up using the correct initialisation scripts, that an update is sent to the DDNS service.

    It is possible for many reasons that the ppp0 interface can be started and the DDNS update may be unsuccessful. This scenario can be addressed by using a script which is called every few hours as a precautionary measure.

    Create the following script to update the account details for your ZoneEdit.com account.


    [bash]# vi /bin/ddns-update



    #!/bin/sh
    #
    # DDNS Automation Script - ZoneEdit.com
    # File: /bin/ddns-update

    # Set ZoneEdit.com Account Details
    USER=username
    PASS=password
    HOST=galaxy.example.com
    EMAIL=admin@example.com

    # Constants - change files if needed
    TMP1=/tmp/ddns_tmp1
    TMP2=/tmp/ddns_tmp2

    # Send update request and save results
    wget -O $TMP1 --http-user=$USER --http-passwd=$PASS --no-check-certificate \
    "https://dynamic.zoneedit.com/auth/dynamic.html?host=$HOST"

    echo ZoneEdit.com - DDNS Update > $TMP2
    echo Time: `date '+%T - %e %B'` >> $TMP2
    cat $TMP1 >> $TMP2

    cat $TMP2 | mail -s "ZoneEdit.com - DDNS Update for $HOST" $EMAIL
    rm -f $TMP1 $TMP2


    Next you need to make the script executable (Consider if only root or all users can read the script, and apply the appropriate permissions).


    [bash]# chmod +x /bin/ddns-update


    To test the script you should execute it manually at the command prompt to see if it is functional. If the script is suitable it can be scheduled with cron to execute on a regular basis.


    [bash]# crontab -e



    00 */8 * * * /bin/ddns-update


    The above crontab entry will execute the ddns-update script every 8 hours.

    The script is designed to email the update query results to a particular user account. If you receive the following '707' error code, then the DDNS update script is being scheduled too often and should be relaxed.


    ERROR CODE="707" TEXT="Duplicate updates for the same host/ip, adjust client settings" ZONE="example.com" HOST="galaxy.example.com">


    Remember the initial ip-up solution should provide adequate stability for your DDNS requirements, and the ddns-update script is only a precautionary measure; try not to over use it.

    More...

  • Linux Home Server HOWTO
    Chapter 2 - Planning Considerations


    Every network system needs some level of planning. If you have decided that you are going to install and configure Linux as your main network server, then you have planned that, simple as it may be its still a plan. The following information is designed to provide some basic everyday considerations to expand your new network plan.

    Your ISP's Acceptable Use Policy
    Before we install our server and connect our new network onto the Internet, we must make sure that we are actually allowed to do so. Believe it or not, but the Internet Service Provider's plan you used to join the Internet may prevent you from connecting your new system and operating with a server and extra workstations - the whole intention of this HOWTO.

    How is this so? When you joined your ISP, you would have agreed to use their systems the way that they planned their networks and user accounts to be utilised. All ISPs draft some type of Acceptable Use Policies (AUP) which are legal binding contracts between the user and ISP, it lays out what you can and can't do with your account.

    Some ISPs do not allow more than one workstation at a time to connect with a particular plan. Some may block specific TCP and UDP ports in an attempt to protect their own networking infrastructure and customers, more so against hackers and spammers. Some may also do regular scans of their user's traffic to determine who is in breach of their AUP.

    Always check with your ISPs AUP to be certain that implementing some type of server based system and extra workstations is allowable, otherwise you may find you no longer have an account if you do the wrong thing. Always check with the ISP if you're ever in doubt, ignorance is not an excuse.

    If implementing this HOWTO is going to breach your ISPs AUP, please do not proceed with installing the services herein. Alternatively, your ISP may have another plan which will be more suited to your needs.

    Server Requirements
    Now that we are sure we can install servers using our Internet account, we need to plan how we are going to connect and configure our server.

    A server would typically be described as a networked computer providing dedicated services and resources to multiple users and clients. That being said, the key concept to remember is dedicated services. Because the server is going to provide various full time networked functions, it really needs to be a dedicated computer running a single Operating System. This allows its services to be available to authorised users any time they are required.

    Each distribution of Linux has an accompanying set of release notes which states the computing requirements recommended for an installed system to successfully operate its software. Installation sizes can range from 800 MB through to around 4 GB just for the operating system alone, which does not consider any file storage needs for your users or the size of which applications can grow through normal use like a networked database application. If you are planning a large network for many users, you should consider the storage requirements so your users and applications have sufficient hard drive space.

    Before you install your server and insert it into your network as the centre of all your systems, consider what applications and services it will be running at that time, the amount of users connecting, and the expected workload it would be subjected to. If you have a large scale network then your systems may be better distributed over several servers to reduce processor demand on a single computer. It is far more sensible (and easier) to use a system that will meet your requirements for the future than to do a system swap in a few months time.

    This section is not an enticement that you need to purchase the latest and biggest components on which to base your server, its just to get you thinking about sustaining your system's capabilities for the future.

    Most small home users can easily get away with the minimum specifications or even less, and a second hand computer will most definitely suit their needs.

    Internet Domain Name
    To be uniquely distinguished on the Internet we need one important aspect, an Internet Address. Our Internet (or IP) Address is likened to an electronic mailing address that computers and network devices use to find other networked devices on the electronic super highway, this allows the delivery of our data.

    That's all well and good for electrical devices, however it is too difficult for people to remember many Internet sites purely by a numerical address, so to be uniquely identified and easily located, we need a Domain Name which best suits the services we offer. A Domain Name can be linked to our unique Internet address using the Domain Name System which we will be configuring later in Chapater 8.

    The DNS system is historically best suited to static IP addresses. However, with the introduction of Dynamic DNS, its now even easier for home users to use a Domain Name with a dynamically changing IP address. This HOWTO provides a section on DDNS services and the ability to automate any DDNS changes on a dynamic IP account.

    This HOWTO is written with the assumption that you have a registered Domain Name that will be used to configure your new server. If you need to register a new domain, then InterNIC maintains this list ( http://www.internic.net/origin.html )of Domain Registrars listed by country. It is recommended that you have a domain name registered before installation, as it is easier to configure during the installation rather than post fixing.

    Some Dynamic DNS service providers also offer sub domain names that can be registered and used for free, the names are similar to "yourname.no-ip.org" or "yourname.homelinux.org". If you are happy using a simple sub domain instead of registering (and paying for) your own domain name, then have a look at some of the services offered by the Dynamic DNS service providers listed in Chapter 5.

    We will be using the domain "example.com" which is free to be used for documentation and training purposes. You will need to substitute that domain for your registered domain where ever you see it throughout this document.





    Always have a look at several domain registrars before registering your domain, some offer extra services that you may not need for a simple network, and you can save a little money by finding the right one.





    Normally you do not own a Domain Name. You will be required to register it for a period of time at which point it must be re-registered so you can continue using that name. Failure to re-register a Domain Name when it expires may allow another organisation or individual to legally register and use your domain.

    Network Topology
    Networks are interconnected in many different ways depending on the connection types, devices in use, the speed of a link, or even the leasing costs of the line. Many organisations have large scale networks which require much planning and consideration before they are installed, however the majority of home users will connect to the Internet using a simple broadband type modem. The Ethernet and USB modems would be most typical for home users because of their relatively low cost and ease of use; therefore we will concentrate on their configuration.

    The two figures below show what the logical topology of how our network will look like, with the server separating and providing security to our internal private network, while maintaining an external connection to our ISP. This is by no means the best design for a network as it relies on a single system to provide our total security; the server. Many modems these days come complete with their own pre-installed firewall and NAT solutions, these are invaluable devices and provide that extra level of security for your home network. Configuring security enabled routers is outside the scope of this HOWTO as these instructions are detailed in the modems user manual.



    The topology in figure 1 uses a single ethernet device (eth0) for connecting all the internal systems to the server, and a single USB modem (ppp0) to dial the server and pass all its data. Before choosing this setup method you should ensure your USB modem is supported by Linux or that your modem has drivers available for you to use.



    Similar to figure 1, the topology illustrated in figure 2 shows the same internal network design with a single ethernet device (eth1). However there is a second ethernet device (eth0) which allows the Point-to-Point Protocol connection out through the ethernet modem and onto your ISP. This is the preferred method for connection as the connection is less problematic using an ethernet modem, however it does require two network cards.

    The configurations and application settings used throughout this HOWTO follow the Ethernet Modem network topology as seen in Figure 2.

    More...

    Linux Home Server HOWTO
    Chapter 1 - Introduction


    About This HOWTO
    Building your own fully operational networked server can be greatly satisfying. More important, it can provide you with much freedom to do as you please without depending on someone else's systems. Manage your own email, run your own web server, host multiple websites, even operate your own database applications. Next time your ISPs email server crashes, you won't be affected.

    This HOWTO will explore some of the standard types of applications and services available to configure a dedicated Linux network server. This type of server configuration is perfectly suited to the home user, or can also provide the basis for a small to medium office system.

    The HOWTO is considered a high level document, which should provide a reason level of detail to guide your installations to a stable and secure state. Further documentation should be sought by the reader in key areas to provide detailed technical explanations.

    This document is developed around the Fedora Core versions of Linux, so some configuration aspects will favour Fedora Core more than other Linux distributions. However, the configuration files, scripts and concepts are kept as generic as possible for the wider audience.

    Reader Assumptions
    I have tried to keep this HOWTO as simple as possible for all users to better understand the concepts and explanations herein. To fully utilise all configuration aspects like email and web server, I've made the following assumptions:

  • The reader has a basic understanding of the hierarchical structure of a Linux filesystem,
  • The reader understands the relationship of a server/client model and the services it provides,
  • The installer will not breach their Internet Service Provider's Acceptable Use Policy implementing this HOWTO,
  • A registered Internet Domain Name is available for use during the installation,
  • The reader can use a text editor (vim examples are used throughout HOWTO),
  • At least one dedicated computer will be used as the server (possibly more for a small to medium office environment), and
  • There is a full time broadband Internet connection available for use.

    If users find the "vim" editor too difficult in manipulating the configuration files, then other text editors can be used instead like "gedit". Alternativley the "vim" GUI can be started by typing "gvim".

    Providing Feedback
    This document covers a wide range of topics, while I have attempted to provide the best possible coverage on all these areas, some errors may occur or application settings change over time with updated releases. There are also numerous hyperlinks to external resources and sites which may break over time as these sites update or move.

    If you find any errors or omissions throughout the documentation, or perhaps have a better solution to possible problems, then please contact me so these changes may be incorporated into the document.

    Send all feedback and comments to: youremail (at) host . com

    Document Conventions
    This document uses the following textual conventions throughout the document as assistance to readers.


    Description


    Appearance


    Warning: Things that may affect stability


    This is a warning.


    Caution: Things that are important


    This is a caution.


    Hint: Things that may assist


    This is a hint.


    Note: Things that may need remembering


    This is a note.


    File Name


    /etc/resolv.conf


    Directory Name


    /var/log


    Typed Command


    rpm -ivh package.rpm


    Application Name


    ntpd


    Command Prompt - generic user


    [bash]$


    Command Prompt - root user


    [bash]#


    Command Prompt - generic user with tcsh shell


    [tcsh]$


    Environment Variable


    VARIABLE


    Emphasized Word


    emphasized


    Quoted Text


    "quote"


    Configuration Example


    workgroup = WORKGROUP
    server string = Samba Server


    The following server and networking details are used throughout the configuration and script examples.


    Description


    Value


    Hostname:


    galaxy


    Domain Name:


    example.com


    Fully Qualified Hostname:


    galaxy.example.com


    External Network Device:


    eth0 (as applicable)


    Internal Network Device:


    eth1


    Internal IP Address:


    192.168.1.1


    Subnet Mask


    255.255.255.0


    Private Network Address (Internal):


    192.168.1.0/24



    The above settings should be adjusted to suit the requirements of the individual and their networks. Where adjustments are changed, they should then be continued throughout the entire document for consistency.


    Acknowledgments and Thanks
    I first and foremost need to thank my wife Susan and our two children Caitlin and Lachlan for their support and understanding while I took time off to prepare this document. The majority of this HOWTO (the initial version for FC3) was written in a relatively short time, there was much to test and document to ensure that I presented you, the members of the Linux community, with what I hope is a quality resource. To my wife and family, I love you.

    I would also like to acknowledge the following people who helped me in certain areas of the document:
    1. Anyone ?
    Copyright Notice © 2004, 2005 and 2006 - Miles Brennan This documentation is licensed under the Creative Commons deed version 2.5 Attribution-NonCommercial-ShareAlike 2.5 You are free:
  • to copy, distribute, display, and perform the work
  • to make derivative works

    Under the following conditions:
  • By : Attribution. You must attribute the work in the manner specified by the author or licensor.
  • nc : Noncommercial. You may not use this work for commercial purposes.
  • sa : Share Alike. If you alter, transform, or build upon this work, you may distribute the resulting work only under a license identical to this one.

  • For any reuse or distribution, you must make clear to others the license terms of this work.
  • Any of these conditions can be waived if you get permission from the copyright holder.

    Your fair use and other rights are in no way affected by the above.
    This is a human-readable summary of the Legal Code (the full license).

    Registered Trademarks
    Linux is a registered trademark of Linus Torvalds.
    The Fedora trademark is a trademark of Red Hat, Inc.
    Motif and UNIX are registered trademarks of The Open Group.
    Windows is a registered trademark of Microsoft Corporation.
    SSH and Secure Shell are trademarks of SSH Communications Security, Inc.
    All other trademarks and copyrights referred to are the property of their respective owners.

    More...

    Sunday, November 8, 2009

  •  
    Tutorial - Wordpress Themes is proudly powered by WordPress and themed by Mukkamu Templates Novo Blogger