How to Install & Configure printer, Network Printer. Step by step configuration of primary DNS server in RHEL7/CentOS7. How To Convert pdf to word without software - Duration: 9.

• Dns Server Configuration In Linux 6 Step By Step Pdf Printer Manual
• Dns Server Configuration In Linux 6 Step By Step Pdf Printer Software
• Redhat Print Server

Local malware or poor DNS server configuration, external agents Turning Windows users into Linux users with MakuluLinux Aero In this free PDF download, you'll get step-by-step instructions for setting up VPN access to SQL. This tutorial explains how to configure DNS server in RedHat Linux step by step with practical example. Learn how to configure DNS Server (Master, Slave, Caching-only and Forwarding-only), DNS Zone (Forward and Reverse), DNS lookup, Chroot DNS environment and DNS clients in detail.

This section describes how to configure printing services in SGD and includes the following topics:

SGD supports two types of printing: PDF printing and Printer-Direct printing.

When using the tablet workspace, only PDF printing is supported.

With PDF printing, users print from an application using an SGD PDF printer. The print job must be in PostScript format. The PostScript print job is sent from the application server to an SGD server, where it is converted into a PDF file. The SGD server then sends the PDF file to a PDF viewer on the user's client device, where the file can be viewed, saved, and printed.

With Printer-Direct printing, users print from an application to a printer attached to their client device. SGD does this by cooperating with the lp or lpr printing system on the SGD host and the native printing system on the application server. The print job is sent from the application server to an SGD server. The SGD server then sends the print job to the SGD Client, which sends it to the user's client printer. If the format of the print job used by the application server is different to the format needed by the client printer, SGD converts the print job before sending it to the SGD Client.

PDF printing is usually more reliable and produces better results than Printer-Direct printing.

SGD has two PDF printers: Universal PDF Printer and Universal PDF Viewer.

On Microsoft Windows client devices, the Universal PDF Printer displays the print job as a PDF file in the Adobe Reader, which then prints the PDF file to the user's default printer. The Universal PDF Viewer displays the print job as a PDF file in the Adobe Reader, which the user can then decide whether to print or save.

On UNIX, Linux, and Mac OS X platform client devices and on tablet devices, there is no difference between the Universal PDF Printer and Universal PDF Viewer, as the print job is always displayed as a PDF file in a PDF viewer. The user can then decide whether to print or save the PDF file.

SGD uses distributed printing. Print jobs are sent to the SGD server hosting the user's application session. This means that a user's print jobs are distributed across the array, and there are no bottlenecks or single points of failure.

SGD supports printer-direct printing to PostScript, Printer Command Language (PCL), and text-only printers attached to the user's client device. The SGD tta_print_converter script performs any conversion needed to format print jobs correctly for the client printer. To convert from Postscript to PCL, Ghostscript must be installed on the SGD server.

Setting up printing involves the following configuration steps:

1. Configure application server for printing.

   The required configuration for the application server depends on the application server platform.

   See Section 5.1.3, “Configuring Microsoft Windows Application Servers for Printing”.

   See Section 5.1.4, “Configuring UNIX and Linux Platform Application Servers for Printing”.

2. Configure the SGD servers for printing.

   See Section 5.1.5, “Configuring an SGD Server for Printing”.

3. Configure printing to client devices.

   The required configuration depends on the client device platform.

   See Section 5.1.6, “Configuring Printing to Microsoft Windows Client Devices”.

   See Section 5.1.7, “Configuring Printing to UNIX, Linux, and Mac OS X Platform Client Devices”.

   See Section 5.1.8, “Configuring Printing to Tablet Devices”.

The following topics describe the configuration required to print from applications running on a Microsoft Windows application server.

• This topic is for legacy Microsoft Windows application servers that use a version of the Microsoft Remote Desktop protocol (RDP) protocol earlier than version 5.0.

SGD automatically creates printer queues in the Windows application session.

When a user starts or resumes a Windows application, the SGD Client sends information about the client's printers to SGD. SGD supplies this information to the application server and the application server then creates, or maps, the printers in the Windows Remote Desktop Services session. The user sees the printers that are attached to the client device and also the printers that are attached directly to the application server.

To be able to create a client printer in the Microsoft Windows application session, the following must be true:

• Printer mapping must be enabled on the application server, see Section 4.1.3, “Configuring Microsoft Windows Remote Desktop Services for Use With SGD” for details.

• The SGD Client must determine the name of the printer driver for the client printer and send it to application server.

• The printer driver for the client printer must be installed on the application server.

The printer drivers that must be installed on the application server are as follows:

• PDF printing – The printer drivers selected for use with PDF printing.

  See Configuring the Printers Available in Windows Remote Desktop Services Sessions for information on selecting printer drivers.

• Printer-Direct printing – The printer driver for every client printer.

  For Microsoft Windows client devices, you can use printer driver mapping to map one printer driver name to another. See Printer Driver Mapping.

  For UNIX, Linux, and Mac OS X platform client devices, the printer configuration files specify the printer driver that is used. See Section 5.1.7, “Configuring Printing to UNIX, Linux, and Mac OS X Platform Client Devices”.

SGD Administrators can control the SGD printers that are available in Windows Remote Desktop Services sessions. See Configuring the Printers Available in Windows Remote Desktop Services Sessions.

SGD enables Administrators to control the printers that are available in Windows Remote Desktop Services sessions. You can configure the printers, as follows:

• Globally. In the Administration Console, go to the Global Settings, Printing tab.

• Individually. In the Administration Console, go to the Printing tab for an organization, an organizational unit, a user profile, or a Windows application object.

  If you configure an organization or organizational unit object, this affects all the users in that organization or organizational unit.

  If you configure a Windows application object, this overrides the printing configuration for organization, organizational unit, or user profile objects. The order of precedence for printing configuration is: Windows application, user profile, organizational unit, organization.

You can set the following attributes on the Printing tab.

Table 5.1 Attributes Used to Configure Printing From Remote Desktop Services Sessions

Any configuration changes you make on the Printing tab only take effect for new user sessions.

If you make a PDF printer the default printer for Windows applications and SGD is configured to only allow users to print to their default printer, users see two printers in their Windows application session. The user's default client printer and the PDF printer are shown.

To use PDF printing, you must install the PostScript printer drivers you want to use for PDF printing on the application server. Make sure the printer drivers have sufficient features for your users. By default, SGD is configured to use the HP Color LaserJet 2800 Series PS printer driver. The printer driver name entered in the Postscript Printer Driver field on the Printing tab must match the name of the printer driver installed on the application server exactly. Pay particular attention to the use of capitals and spaces. The /opt/tarantella/etc/data/default.printerinfo.txt file contains all the common printer driver names, ordered by manufacturer. To avoid errors, copy and paste the driver name from this file.

If a PDF viewer is not configured on the client device, the PDF printers are not available in the Windows application session, even if a PDF printer is enabled.

To print from a legacy Microsoft Windows application server that uses a version of the Microsoft RDP protocol earlier than version 5.0, you must configure a Line Printer Remote (LPR)-compatible TCP/IP printer on the application server. Configure the printer to send print jobs to the primary SGD server in the array. Consult your system documentation for details of how to configure printers.

Note the following limitations:

• PDF printing is not supported.

• No multiple printer support. You can only print to the client device's default printer. It is not possible for users to select a printer. If a user needs to print to a different printer, they have to log out of SGD, change their default printer, and then log in again.

• Print jobs might be deleted. When a print job is transferred from the application server to an SGD server, the user's SGD name is needed to identify which client device to send the print job to. With some versions of Microsoft Windows, there is no direct way to associate print jobs with SGD users. If SGD cannot identify which user has printed a particular job, the print job is deleted. This might happen, for example, if two users log in to the application server with the same name.

• Distributed printing is not available. All print jobs are directed through the primary server in an SGD array.

To use PDF printing from a UNIX or Linux platform application server, you must install at least one SGD printer queue on the application server. You do not have to install printer queues for the Universal PDF Printer and Universal PDF Viewer. However, if a UNIX or Linux platform application you are using does not allow you to configure printer arguments, or does not allow you to specify the Universal PDF Printer and Universal PDF Viewer because their names contain spaces, you must install an additional printer queue called tta_pdfprinter and print to that queue.

To use Printer-Direct printing from a UNIX or Linux platform application server, you must install SGD printer queues as follows:

• Single printer queue. Install an SGD printer queue for the primary SGD server in the array. All print jobs are directed to the primary SGD server, and the primary server sends the print jobs to the client device.

• Multiple printer queues. Install an SGD printer queue for each SGD server in the array. Each printer queue redirects print jobs to an SGD server, and the SGD server sends the print jobs to the client device.

  It is best to use multiple printer queues so that print jobs are distributed across the array, and there are no bottlenecks or single points of failure

You configure printer queues with the SGD printer queue installation script. See Section 5.1.4.1, “How to Install an SGD Printer Queue on a UNIX or Linux Platform Application Server”.

The SGD printer queue installation scripts installs replacement lp or lpr scripts. These are used instead of the standard scripts, to ensure that print jobs contain enough information for SGD to be able to identify the user that printed them. See Section 5.1.4.4, “Printing With the SGD lp and lpr Scripts” for details.

If the application server is also an SGD server, a printer queue is installed automatically when you install SGD.

1. Copy the /opt/tarantella/bin/scripts/prtinstall.en.sh script from an SGD server to a temporary directory on the application server.

2. Log in to the application server as superuser (root).

3. Change to the temporary directory.

4. Run the script to install the printer queue.

   See Section 5.1.4.2, “The SGD Printer Queue Installation Script” for details of all the command options for the SGD printer queue installation script.

   • If the array consists of a single SGD server, use the following command:

     When prompted, enter the full Domain Name System (DNS) name of the SGD server.

   • If the array contains more than one SGD server, create a printer queue for each SGD server in the array. Use the following command:

     The DNS-name is the full DNS name of an SGD server. The name of each printer queue, as specified by the --appprinter argument, can be anything you like but it must be unique.

   If you use the Common UNIX Printing System (CUPS), you might have to use the --cups option with prtinstall.en.sh, to indicate that you are using CUPS. You might also have to reconfigure CUPS. See Section 5.1.4.3, “Configuring Printing for CUPS”.

The SGD printer queue installation script, prtinstall.en.sh, installs an SGD printer queue on a UNIX or Linux platform application server. It also installs the SGD replacement lp or lpr scripts.

The prtinstall.en.sh script is located in the /opt/tarantella/bin/scripts directory on the SGD server.

You must be superuser (root) to run this script.

The syntax for the script is as follows:

The following table describes the available options for the script.

The following example installs an SGD printer called tta_london on an application server.

See the Oracle Secure Global Desktop Platform Support and Release Notes for details of supported CUPS versions.

The following configuration changes might be needed to enable printing with CUPS:

• CUPS LPD compatibility mode must be enabled for any LPD clients.

  If you have any Line Printer Daemon (LPD) clients on your application server, you must enable the CUPS LPD compatibility mode so that CUPS can accept remote print jobs from LPD clients. See the CUPS documentation for information on how to enable LPD compatibility mode.

• CUPS raw printing must be enabled.

  On the host where SGD is installed, enable raw printing in CUPS, by editing the /etc/cups/mime.convs and/etc/cups/mime.types files. These files contain comments explaining how to do this. Search for comments containing the word “raw”.

After making changes to your CUPS configuration, you might have to restart the CUPS daemon.

To use CUPS for printing, you must use the /opt/tarantella/bin/lp script.

The SGD printer queue installation script, prtinstall.en.sh, installs the SGD lp or lpr replacement scripts. Users must use these replacement scripts when they print from a UNIX or Linux platform application server. The replacement scripts ensure that print jobs contain enough information for SGD to be able to identify the user that printed them.

The SGD login scripts set the user's PATH to ensure that the replacement scripts take precedence over the system scripts. However, if the application uses a full path name, for example /usr/bin/lp, or modifies PATH itself, you must reconfigure the application to use /opt/tarantella/bin/lp or /opt/tarantella/bin/lpr.

Users print with the replacement scripts as follows:

If the -d or -P argument is omitted, the output goes to the client's default printer. How you specify the printer depends on the client device. See Section 5.1.6, “Configuring Printing to Microsoft Windows Client Devices” and Section 5.1.7, “Configuring Printing to UNIX, Linux, and Mac OS X Platform Client Devices” for details.

Configuring an SGD server for printing involves the following configuration steps:

• Ghostscript might need to be installed on the SGD host. SGD might need to be configured to find the Ghostscript installation.

  See Section 5.1.5.1, “Checking the Ghostscript Installation on the SGD Host”.

• The SGD host might need to be configured to accept remote print requests.

  See Section 5.1.5.2, “Configuring the SGD Host to Accept Remote Print Requests”.

• SGD might need to be configured to convert print jobs between different formats.

  See Section 5.1.5.3, “Configuring SGD Print Job Conversion”.

SGD uses Ghostscript to convert print jobs into PDF files. To use PDF printing, Ghostscript must be installed on the SGD host. For best results, install the latest version of Ghostscript. Your Ghostscript distribution must include the ps2pdf program.

With Printer-Direct printing, the tta_print_converter script uses Ghostscript to convert print jobs from PostScript to PCL format. For best results, download and install the additional fonts.

Ghostscript is not included with the SGD software.

When you install SGD, it automatically detects Ghostscript if it is installed in one of the following locations:

• /usr/local/bin

• /usr/bin

• /usr/sfw/bin

• /opt/sfw/bin

• /bin

• /usr/sbin

• /sbin

• /usr/lbin

If Ghostscript is installed in a different location, run the SGD printer queue installation script on the SGD host. Use the --gsbindir option of the script to configure the location of Ghostscript. See Section 5.1.4.2, “The SGD Printer Queue Installation Script” for more details.

If more than one version of Ghostscript is installed, run the SGD printer queue installation script with the --gsbindir option, to tell SGD which version to use.

If Ghostscript is not installed on the SGD host, or your Ghostscript distribution does not include the ps2pdf program, install Ghostscript and then run the SGD printer queue installation script.

You can use the gstest script to test the Ghostscript installation on an SGD host. This script is run by default when you install SGD.

The gstest script checks for errors in the Ghostscript installation and uses ps2pdf to generate a test PDF file. Script output is reported on-screen, and is also written to the /opt/tarantella/var/log/print.log file.

You run gstest as follows:

Using gstest in this way performs a basic test of the font installation on the SGD host and generates a fonts test file, /opt/tarantella/var/info/sample.pdf. If Ghostscript fonts are installed correctly, the sample.pdf file contains three lines, each rendered in a different font. The fonts used are listed in the /opt/tarantella/var/log/print.log file.

Alternatively, you can specify an input file and output file to use with gstest. For example:

If you do not specify an output file, gstest creates an output PDF file at /tmp/sgd_sample.pdf.

If you specify your own input file, gstest does not generate the fonts test PDF file, /opt/tarantella/var/info/sample.pdf.

Print jobs are sent from the application server to an SGD server, and then from the SGD server to the client device. To be able to direct print jobs from an application server to a client device, the SGD host must be configured to accept remote print requests. How you do this varies for each platform. Check your System Administration documentation for information about this.

For example, if you are using lpd on Linux systems, you must add an entry in the /etc/hosts.equiv or /etc/hosts.lpd file, if available, for each application server that might send a print request. After making these changes, remember to restart the lpd daemon.

With Printer-Direct printing, print jobs are sent from an application server to an SGD server. The SGD server then sends the print job to the client device, which sends it to the user's printer. When print jobs arrive at the SGD server, they might need to be converted to a format suitable for the client printer.

Print jobs from Windows RDP sessions are never converted, because they are assumed to be in the correct format.

To decide whether a print job needs to be converted, the SGD server checks a printer type configuration file to see whether the format used by the client printer matches the format used by the application server. If the format matches, the print job is forwarded to the client device printer without any conversion. If the formats do not match, the SGD server converts the print job to the right format using the tta_print_converter script.

To ensure that print jobs are formatted correctly, you might have to edit a printer type configuration file and the tta_print_converter script. This is described in the following sections.

Only edit these files if you have to use Printer-Direct printing and need to resolve issues with print job formats. In most cases, PDF printing provides a better solution for issues with print job formats.

SGD uses the following configuration files to determine the printer type:

• Microsoft Windows client devices. The /opt/tarantella/etc/data/printertypes.txt file is used.

  See Section 5.1.6, “Configuring Printing to Microsoft Windows Client Devices”.

• UNIX, Linux, and Mac OS X platform client devices. One of the following files is used:

  • /opt/tarantella/etc/data/default.printerinfo.txt – This is the global configuration file.

  • $HOME/.tarantella/printerinfo.txt – This is a user-specific configuration file.

  See Section 5.1.7, “Configuring Printing to UNIX, Linux, and Mac OS X Platform Client Devices”.

You can edit these files if you want to support particular printers, or to add new types of printer.

If you add a new printer type, you might also have to edit the tta_print_converter script.

If there is insufficient detail or inaccurate mappings in these files, SGD might convert print jobs unnecessarily, or not at all.

The tta_print_converter script converts print jobs from the format used by the application server to the format required by the client device, as determined by the printer type. By default, the script recognizes PostScript and non-PostScript formats. To convert print jobs from PostScript to PCL, Ghostscript must be installed on the SGD host. See Section 5.1.5.1, “Checking the Ghostscript Installation on the SGD Host” for more information about installing and configuring Ghostscript for SGD printing.

You can edit the tta_print_converter script to recognize and convert between different print job formats, or to add support for a new printer type.

You must log on as superuser (root) to edit the script.

The tta_print_converter script is in the /opt/tarantella/bin/scripts directory. The script includes comments, to help you to customize it.

The shell function GetDataType determines the print job format from the first 128 bytes of the print job. The data is URL-encoded, for example, the % character is encoded as %25.

The client printer type is passed to this script in upper case, for example, POSTSCRIPT or MYNEWTYPE.

If you experience problems printing to a PCL printer, the tta_print_converter script contains some code which has been commented out. You can use this code to see if this solves the problem.

The configuration required for printing to Microsoft Windows client devices depends on whether you are using PDF printing or Printer-Direct printing, as described in the following sections.

To be able to use PDF printing, Adobe Reader version 4.0 or later must be installed on the client device.

From a Microsoft Windows application, you print in the normal way, and select either the Universal PDF Printer or the Universal PDF Viewer in the application's Print dialog.

From an application running on a UNIX or Linux platform application server, you print in the normal way, using the SGD replacement lp or lpr scripts. You select a PDF printer as part of the print command, for example:

The filename must be a PostScript file, so the application must be able to output PostScript.

When users print, the PDF file is displayed in the Adobe Reader. If the Universal PDF Printer is selected, the PDF file is printed automatically to the user's default printer. The Adobe Reader runs minimized and does not exit when the print job has finished. If the Universal PDF Viewer is selected, the PDF file is displayed in the Adobe Reader window. The user can then decide whether to print or save the file.

On UNIX, Linux, and Mac OS X platform client devices, the PDF file is displayed either in the default PDF viewer or in the PDF viewer configured in the client profile. The user can then decide whether to print or save the PDF file. There is no difference between the Universal PDF Printer and the Universal PDF Viewer, as the print job is always displayed in a PDF viewer.

This section describe the configuration that might be needed when using Printer-Direct printing to print to Microsoft Windows client devices and includes the following topics:

When printing from a Microsoft Windows application, the large number and variety of client printers available can cause problems. The majority of the problems are caused by not having the correct printer drivers installed on the application server. One solution is to use PDF printing. Another solution, for Windows client devices only, is to use printer driver mapping.

Printer driver mapping enables you to map one printer driver name to another. You do this by editing the [Previous Names] section of the /opt/tarantella/etc/data/default.printerinfo.txt file.

The following is an example of an entry in a default.printerinfo.txt file:

This means that if users have client printers that use either the 'my HP driver' or 'my other HP driver' printer driver, SGD uses the 'HP LaserJet 5' printer driver when creating the printer.

You can also use wild-card characters, such as * and ?, on the right hand side of the = sign. Use * to mean any string of characters, including an empty string and ? to mean any single character. This is useful, for example, to create generic printer mappings where you have a wide variety of client devices.

For example, if the file contains the following entry:

All printer driver names like 'HP LaserJet 5', 'HP LaserJet 5M', and 'HP Color LaserJet 5' are mapped to the printer driver 'HP LaserJet 5'.

The default.printerinfo.txt file contains more detailed instructions on how to create the mappings.

For Microsoft Windows client devices, SGD uses the /opt/tarantella/etc/data/printertypes.txt file to determine whether to convert a print job from one format to another before sending it to the client device. The printertypes.txt file maps printer drivers, for example, pscript.dll, to printer types, for example PostScript.

Print jobs from Windows RDP sessions are never converted, because they are assumed to be in the correct format.

The printertypes.txt file includes comments to help you to customize it. By default, the file includes mappings for PostScript, PCL, and text-only printers. You must log on as superuser (root) to edit this file.

The printertypes.txt file used for Windows clients also contains entries for UNIX platform and Apple Macintosh clients. This is used only as a fallback. For UNIX or Linux platforms, it maps UNIX types to printer types. For Apple Macintosh, it maps printer names to printer types.

To find out the name of the printer driver used by a client device, print a test page and check the Driver Name field.

To add support for a new printer type, add lines following the same pattern. For example:

For example, a Windows client device, cairo, runs Windows and its default printer is PCL. The printer driver used is unidrv.dll. The [Windows*] section in printertypes.txt has the following format:

As there is no specific match for unidrv.dll, the final entry applies: PostScript. This means that when the user prints, print jobs are incorrectly converted to PostScript before being sent to cairo.

To fix this, edit printertypes.txt as root and add a specific match for unidrv.dll as follows:

Following this change, SGD correctly identifies the printer configured on cairo, and print jobs are converted to PCL for that client device.

When printing from a UNIX or Linux platform application server to a Microsoft Windows client device, users can specify the printer they print to by using any of the following:

• The Universal Naming Convention (UNC) name of a network printer accessible to the client, for example:

• A “friendly” name, for example:

• A port on the client, for example:

To use a UNC name, you must enclose the printer name in quotes and escape every backslash with an extra backslash, as shown in the previous example. As different shells process backslashes differently, you might need to experiment with the number of backslashes. You can also use underscores instead of backslashes, for example:

Using underscores only works if the first two characters of the printer name are underscores.

You can avoid problems with UNC names by using a “friendly” name. You configure “friendly” names in the /opt/tarantella/etc/data/printernamemap.txt file. The entries in this file map “friendly” names to UNC names, for example:

You do not have to escape any backslashes.

The configuration required for printing to UNIX, Linux, and Mac OS X platform client devices depends on whether you are using PDF printing or Printer-Direct printing, as described in the following sections.

To be able to use PDF printing, a PDF viewer must be installed on the client device. See the Oracle Secure Global Desktop Platform Support and Release Notes for details of the default PDF viewers for each supported platform.

To be able to use a default PDF viewer, the application must be on the user's PATH.

If an alternative PDF viewer is preferred, the command for the alternative viewer application can be configured in the user's client profile. In the profile you enter either the command or the full path to the command, depending on whether the application is on the user's PATH. See Section 6.2.4, “Client Profile Settings” for details.

From a Microsoft Windows application, you print in the normal way, and select either the Universal PDF Printer or the Universal PDF Viewer in the application's Print dialog.

From an application running on a UNIX or Linux platform application server, you print in the normal way, using the SGD replacement lp or lpr scripts. You select a PDF printer as part of the print command, for example:

The filename must be a PostScript file, so the application must be able to output PostScript.

The PDF file is displayed either in the default PDF viewer or in the PDF viewer configured in the client profile. The user can then decide whether to print or save the PDF file. There is no difference between the Universal PDF Printer and the Universal PDF Viewer, as the print job is always displayed in a PDF viewer.

To use Printer-Direct printing to print to printers attached to UNIX, Linux, or Mac OS X platform client devices, the client printers must be defined in one of the following printer configuration files:

• Global printer configuration file – /opt/tarantella/etc/data/default.printerinfo.txt.

  This file set the defaults for all users printing through that SGD server. As this file is not replicated across the array, you have to manually copy it to the other SGD servers.

• User-specific printer configuration file – $HOME/.tarantella/printerinfo.txt.

  The user-specific printer configuration file is optional and has to be manually created on client devices. Users can create their own file or you can use the global configuration file as a template and distribute it to users. This file contains the settings for an individual user regardless of the SGD server they print through. The settings in this file take precedence over the settings in the global configuration file.

The format of the global and user-specific printer configuration file is the same:

printer-name is the name of the printer as it is known to the lp or lpr system on the client. The printer name must be enclosed in straight quotation marks (') and be followed by an Equal (=) sign. This is the name that users can specify when printing from a UNIX or Linux platform application server. It is also the name that displays in the Print dialog when users print from a Microsoft Windows application server.

windows-driver is the name of the printer driver to use when printing from a Microsoft Windows application server. The printer driver name must be enclosed in double quotes. The name of the printer driver must match the name of the printer driver installed on the Windows application server exactly. Pay particular attention to the use of capitals and spaces. The default.printerinfo.txt file contains all the common printer driver names ordered by manufacturer. To avoid errors, copy and paste the driver name from this file.

printer-type is the format to be used for the print job. The values can be PostScript, PCL or Text. This information is optional, but if it is missing, PostScript is used by default. This information is used to determine whether SGD converts the print job from the format used by the application server to the format needed by the client printer. See also Section 5.1.5.3, “Configuring SGD Print Job Conversion”.

The first printer listed in the [UNIX] section is the client's default printer.

When SGD is first installed, the default.printerinfo.txt file contains the following entry:

With this configuration, when users print from a Windows application server, they see a printer called _Default. This printer prints to the default printer on the client using a basic PostScript printer driver, “HP Color LaserJet 2800 Series PS”.

This means that a printer is available in the Windows application, even if there is no printer connected to the client device.

For example, if an SGD user's $HOME/.tarantella/printerinfo.txt file contains the following entries:

When the user prints from a Microsoft Windows application server to a UNIX platform client device, the following printers are available:

• drafts

• salespersons

The user's default printer is drafts, which in this example has been defined as a PCL printer.

Only PDF printing is supported on tablet devices.

To be able to use PDF printing, a PDF viewer plug-in must be installed on the browser on the tablet device.

From a Microsoft Windows application, you print in the normal way, and select either the Universal PDF Printer or the Universal PDF Viewer in the application's Print dialog.

From an application running on a UNIX or Linux platform application server, you print in the normal way, using the SGD replacement lp or lpr scripts. You select a PDF printer as part of the print command, as shown in Section 5.1.7.1, “PDF Printing”.

The PDF file is displayed in the default PDF viewer on the tablet device. The user can then decide whether to print or save the PDF file. There is no difference between the Universal PDF Printer and the Universal PDF Viewer, as the print job is always displayed in a PDF viewer.

This section describes the print job management features of SGD and includes the following topics:

SGD Administrators control printing services with the tarantella print command. This command enables you to do the following:

• List spooled print jobs and identify the SGD users they belong to. You can use this to check that print jobs from the application server printing system have reached the SGD print queue.

• Remove print jobs from the SGD print queue.

• Pause and restart SGD printing services.

• Move print jobs from one SGD server to another.

The syntax for the tarantella print command is as follows:

tarantella print start stop status pause resume list cancel move

The following table shows the available subcommands for tarantella print.

SGD Administrators can set a time limit on how long a print job can remain on an SGD server before it is deleted. This is useful if you have to manage a high volume of printing.

To specify the number of hours that print jobs remain on the server, use the following command:

To return SGD to its default behavior, so that print jobs remain on the server indefinitely, use the following command:

Users can manage their own print jobs from the Printing area on the workspace, as shown in Figure 5.1, “Printing Area on the SGD Workspace”.

Figure 5.1 Printing Area on the SGD Workspace

The Printing area shows the number of jobs currently in the print queue and the controls for managing print jobs.

When documents are printing, the workspace tells a user how many print jobs they have in the queue. Users can click Cancel All to delete all pending print jobs.

Users can also click Pause to temporarily stop printing. When printing is paused, any print jobs that are pending are held in a queue until the user either cancels them or resumes printing.

The printer icon changes to show you when printing is paused. Click Resume to start printing again.

For the tablet workspace, the Pause and Resume options are not available in the Printing area.

To manage print jobs individually, click List All Jobs. The workspace displays a list of all the print jobs the user has in the queue, along with information about the job, for example the number of copies and the selected printer.

If you pause printing, click the Resume button to print just that one print job.

With the tablet workspace, users can only resume PDF print jobs.

To cancel a print job, click the Cancel button.

When printing from a Microsoft Windows application server, or a UNIX or Linux platform application server, users can choose which printer they print to. If the user does not select a printer, the output goes to their default printer. For all other application servers, the output always goes to the client device's default printer.

Users can see which printer is their default printer by pointing with the mouse at the printer icon on their workspace. A popup displays the name of the default printer.

If a user wants to change their default printer, they must log out of SGD, change the default printer and then log in to again.

Use the following checklists to diagnose and fix the problem:

If this does not resolve the problem, follow the steps in Section 5.1.10.4, “Tracing a Print Job”.

Use the following client device troubleshooting steps to diagnose printing problems in SGD.

Questions

• 5.1.10.1.1: Does SGD Support Printing for the Client Device or Printer Type?

• 5.1.10.1.2: Is Printing Paused on the Client Device?

• 5.1.10.1.3: Is the Printer Configured Correctly?

• 5.1.10.1.4: For PDF Printing, is the PDF Viewer Installed on the Client?

• 5.1.10.1.5: For PDF Printing From a UNIX or Linux Platform Application Server, is the Print Job in the Right Format?

• 5.1.10.1.6: Does the User Have the Necessary Registry Permissions?

Questions and Answers

5.1.10.1.1: Does SGD Support Printing for the Client Device or Printer Type?

Check the Printing area on the workspace. Does the printer icon contain a red cross and is the message “No Client Printer Available” displayed? If so, this means that SGD does not support printing for this client device or printer type, or that there was an error creating client printers.

5.1.10.1.2: Is Printing Paused on the Client Device?

Make sure that the user has not paused printing. Check the Printer Paused icon is not displayed.

Use the tarantella webtopsession list command to see whether the user has paused printing.

5.1.10.1.3: Is the Printer Configured Correctly?

Make sure that the printer is correctly configured, for example by printing a web page to the printer from a web browser on the client device. Depending on the application server, some print jobs can only go to the client device's default printer.

If printing to a UNIX, Linux, or Mac OS X platform client device, check that you have configured printing for these client types. See Section 5.1.7, “Configuring Printing to UNIX, Linux, and Mac OS X Platform Client Devices”.

5.1.10.1.4: For PDF Printing, is the PDF Viewer Installed on the Client?

To be able to use PDF printing in SGD, a PDF viewer must be installed on the client device.

Check that the supported viewer, or the user's preferred viewer, is installed on the client and that the application is executable.

On UNIX, Linux, or Mac OS X system client devices, check that the user has read and write access to the /tmp directory.

If the PDF viewer is Adobe Reader (acroread), check that the viewer supports the -openInNewWindow command option. If the PDF viewer is Preview app (/Applications/preview.app), check that the viewer supports the open -a command option.

If a PDF viewer is not installed or accessible, the SGD PDF printers are available to the user.

5.1.10.1.5: For PDF Printing From a UNIX or Linux Platform Application Server, is the Print Job in the Right Format?

If the user's PDF viewer starts, but they receive a file format error, check that the format of the file being printed on a UNIX or Linux platform application server is PostScript.

5.1.10.1.6: Does the User Have the Necessary Registry Permissions?

On Microsoft Windows client devices, users must have write access to the HKEY_LOCAL_MACHINESOFTWAREMicrosoftCryptographyRNGSeed registry key and read access to the rest of the registry.

This access is required by several of the Windows application programming interfaces (APIs) for printing.

Use the following application server troubleshooting steps to diagnose printing problems in SGD.

Questions

• 5.1.10.2.1: Is Printing Enabled on the Application Server?

Questions and Answers

5.1.10.2.1: Is Printing Enabled on the Application Server?

Before users can print, you might need to enable printing services on your application server.

On Microsoft Windows application servers, printer mapping must be enabled. Printer mapping is configurable globally, or as a group policy. By default, printer mapping is enabled.

On UNIX and Linux platform application servers, printing services must be enabled.

Questions

• 5.1.10.2.1: Is a Printer Configured on the Application Server?

• 5.1.10.2.2: Is the Printer Created in the Windows Application Session?

• 5.1.10.2.3: Is the Application Printing to the Correct Printer?

• 5.1.10.2.4: Are Accounts Shared on the Application Server?

• 5.1.10.2.5: Is the Windows Name of the Server the Same as the DNS Name?

• 5.1.10.2.6: If You Are Using PDF Printing, is the Same PostScript Printer Driver Installed on Every Microsoft Windows Application Server?

Questions and Answers

5.1.10.2.1: Is a Printer Configured on the Application Server?

Before users can print, you might need to configure a SGD printer on your application server. See the following:

• Section 5.1.3, “Configuring Microsoft Windows Application Servers for Printing”.

• Section 5.1.4, “Configuring UNIX and Linux Platform Application Servers for Printing”.

5.1.10.2.2: Is the Printer Created in the Windows Application Session?

If the user is trying to print from a Microsoft Windows application server, accessed using Windows Remote Desktop Services, then the user's printers are configured automatically. See Section 5.1.3.1, “Configuring Printing for Microsoft Windows Application Servers”. If not, check the System Event log on the application server for the following errors:

• Event ID: 1111 Description: Driver drivername required for printer printertype is unknown. Contact the administrator to install the driver before you log in again.

• Event ID: 1105 Description: Printer security information for the printername / clientcomputername /Session number could not be set

• Event ID: 1106 Description: The printer could not be installed.

These errors indicate that the printer driver for the client printer might not be supported by the application server. Either install the printer driver on the application server, or see Printer Driver Mapping for details of how to support other printer drivers, including using wildcards to support a wide range of printer driver names.

It is also worth checking that the name of the printer driver in /opt/tarantella/etc/data/default.printerinfo.txt, or the user's $HOME/.tarantella/printerinfo.txt, matches the name of the driver on the application server.

If this does not resolve the problem, see Microsoft Knowledge Base article 239088 for more details.

Dns Server Configuration In Linux 6 Step By Step Pdf Printer Manual

5.1.10.2.3: Is the Application Printing to the Correct Printer?

The application must print to the printer queue you have configured. On UNIX or Linux platform application servers, the prtinstall.en.sh script creates a printer queue named tta_printer by default.

On UNIX or Linux platform application servers, the application must print using the replacement lp or lpr scripts installed by prtinstall.en.sh. The SGD login scripts set PATH to ensure that the replacement scripts take precedence over the system scripts. If the application uses a full path name, for example /usr/bin/lp, or modifies PATH itself, reconfigure the application to use /opt/tarantella/bin/lp or /opt/tarantella/bin/lpr.

5.1.10.2.4: Are Accounts Shared on the Application Server?

If more than one user is simultaneously logged in to the same application server with the same user name, SGD might be unable to distinguish which user owns the print jobs. SGD discards the print jobs, logging that it has done so. This occurs with UNIX or Linux system application servers that do not have an SGD printer queue.

To fix this problem, run the prtinstall.en.sh script to configure a printer. See Section 5.1.4.2, “The SGD Printer Queue Installation Script”.

Use the tarantella print command to check that print jobs from the application server printing system are reaching the SGD print queue.

5.1.10.2.5: Is the Windows Name of the Server the Same as the DNS Name?

If you have a Microsoft Windows server with a DNS name of naples.example.com and a NetBIOS name of VESUVIUS, print jobs from this server fail, because they contain the host identifier VESUVIUS instead of naples.

You can avoid this problem by editing the file hostnamemap.txt in the /opt/tarantella/etc/data directory. This file enables you to map host names to DNS names. The file contains instructions on how to create the mappings.

5.1.10.2.6: If You Are Using PDF Printing, is the Same PostScript Printer Driver Installed on Every Microsoft Windows Application Server?

To be able to use PDF printing, you must install the same PostScript printer driver on every Microsoft Windows application server.

In the Administration Console, check that the name of the driver matches the name configured in the Postscript Printer Driver field on the Global Settings, Printing tab, or the Printing tab for the user profile or parent object. The System Event log on the application server shows an error if the names do not match.

Use the following SGD server troubleshooting steps to diagnose printing problems in SGD.

Questions

• 5.1.10.3.1: Is Printing Paused or Disabled Across the Array?

• 5.1.10.3.2: For Printing on Microsoft Windows Client Devices, Are Client Printers Disabled?

• 5.1.10.3.3: Has the Array Configuration Changed?

• 5.1.10.3.4: For PDF Printing, is Ghostscript Available on the SGD Host?

Questions and Answers

5.1.10.3.1: Is Printing Paused or Disabled Across the Array?

Use the tarantella print status command to check whether printing is paused or disabled for the array.

If necessary, enable printing, using tarantella print start or tarantella print resume.

5.1.10.3.2: For Printing on Microsoft Windows Client Devices, Are Client Printers Disabled?

In the Administration Console, check the Global Settings, Printing tab, or the Printing tab for the user profile or parent object. See whether users can access all their client printers, just their default client printer, or no client printers.

For PDF printing, check whether the SGD PDF printers are enabled.

5.1.10.3.3: Has the Array Configuration Changed?

Printing is not reconfigured if you do any of the following:

• Create an array

• Add a new secondary server to the array

• Change the primary server in the array

If the array has changed you might have to reconfigure printing, so that print jobs are sent to the correct printer.

5.1.10.3.4: For PDF Printing, is Ghostscript Available on the SGD Host?

PDF printing in SGD uses Ghostscript to convert print jobs into PDF files. SGD also uses Ghostscript to convert print jobs from PostScript to PCL.

Try upgrading to the latest version of Ghostscript. After upgrading, ensure that the symbolic link /opt/tarantella/var/info/gsbindir points to the directory where the new Ghostscript binaries are installed.

If the /opt/tarantella/var/log/print.log file contains a message such as 'Can't find ps2pdf' or 'Consider obtaining Ghostscript from http://www.ghostscript.com', then either Ghostscript is not installed or it is installed in a non-standard location.

See Section 5.1.5.1, “Checking the Ghostscript Installation on the SGD Host” for details of how fix Ghostscript installation problems.

If the checklists above do not solve your SGD printing problem, try the following troubleshooting steps. These steps enable you to track the progress of a print job from the application server to the SGD server to the client device.

Questions

• 5.1.10.4.1: Step 1: Can You Print From the SGD Server?

• 5.1.10.4.2: Step 2: Is the SGD Printer Queue Installed on the SGD Server?

• 5.1.10.4.3: Step 3: Is the Print Job Leaving the UNIX or Linux Platform Application Server?

• 5.1.10.4.4: Step 4: Is the Print Job Present in the UNIX or Linux System Spool Directory?

• 5.1.10.4.5: Step 5: Is the Print Job Leaving the Windows Application Server?

• 5.1.10.4.6: Step 6: Is the Print Job Reaching the SGD Server?

• 5.1.10.4.7: Step 7: Have You Examined the Print Log Files?

Questions and Answers

5.1.10.4.1: Step 1: Can You Print From the SGD Server?

Configure an X or character application to run on the SGD server. Display a terminal window, for example xterm, and start the application from your SGD workspace.

Try printing a test page, by running the /opt/tarantella/bin/scripts/printtestpage.en.sh script.

If the page does not print, run /opt/tarantella/bin/scripts/printtestpage.en.sh --direct. This bypasses the UNIX or Linux system spooler.

Check the following:

• Did the first test page print?

  The problem is related to the movement of print jobs from the application server to the SGD server.

  • For UNIX or Linux platform application servers, go to Step 3.

  • For Windows Remote Desktop Services, go to Step 5.

• Did the second test page print?

  The problem is related to the UNIX or Linux system printing system on the SGD host.

  Investigate and fix any problems, using your UNIX or Linux system documentation for help. Then try printing again.

• Did neither of the test pages print?

  The problem is related to the SGD server.

  Go to Step 2.

5.1.10.4.2: Step 2: Is the SGD Printer Queue Installed on the SGD Server?

In the list of printers on the SGD host, check for an entry for tta_printer.

Consult your UNIX or Linux system documentation to find out how to display the list of printers. On some systems, you can use lpstat -t. If your system has a file /etc/printcap, this contains a list of printers in plain text format.

Check the following:

• Is the tta_printer printer present on the SGD host?

  The problem is related to the movement of print jobs from the SGD server to the client device. Go to Step 7.

• Is the tta_printer printer missing from the SGD host?

  Run the prtinstall.en.sh script on the SGD server. Then try printing again.

  See also Section 5.1.4.2, “The SGD Printer Queue Installation Script”.

5.1.10.4.3: Step 3: Is the Print Job Leaving the UNIX or Linux Platform Application Server?

Using an application object configured to display a terminal window on the UNIX or Linux system application server, try printing a small text file to the SGD printer. For example, enter the command: lp -d tta_printer /etc/hosts.

Check the following:

• Does the command return an error message?

  Check that the UNIX or Linux platform application server is configured to print through SGD. You might need to run the prtinstall.en.sh script. See Section 5.1.4.2, “The SGD Printer Queue Installation Script” for more details.

• Does the command return a print job ID?

  This suggests that SGD printing is correctly configured, but the problem might lie in the UNIX or Linux print system. Go to Step 4.

5.1.10.4.4: Step 4: Is the Print Job Present in the UNIX or Linux System Spool Directory?

The print spool directory varies between different UNIX or Linux systems. Consult your UNIX or Linux system documentation for assistance.

Check the following:

• Is the print job present in the spool directory?

  There might be a network problem between the application server and SGD server. Go to Step 6.

• Is the print job missing from the spool directory?

  Check your UNIX or Linux system LPD printing configuration. For example, ensure that there are suitable entries in /etc/hosts.equiv or /etc/hosts.lpd, and that there are no .deny files, such as /etc/hosts.equiv.deny.

  Check that the lpd daemon is running and listening. For example, use the following commands:

  Try printing again.

5.1.10.4.5: Step 5: Is the Print Job Leaving the Windows Application Server?

Check the print queue on the application server. Consult your system documentation if you need help on how to do this.

Check the following:

• Is the print job leaving the application server?

  There might be a network problem between the application server and SGD server. Go to Step 6.

• Is the print job leaving the application server?

  Check the configuration of the SGD printer, as follows:

  • Check that you can ping and telnet to the SGD server from the application server.

  • Look for errors in the Event Log.

  • From a command prompt, use the lpr -s server -p tta_printer filename command to print. If this works, the printer driver on the application server might not be installed or configured correctly.

5.1.10.4.6: Step 6: Is the Print Job Reaching the SGD Server?

Check the SGD print spool directories on the SGD server: /opt/tarantella/var/spool and /opt/tarantella/var/print/queue.

Check the following:

• Is the print job present on the SGD server?

  Check that you are using fully qualified domain names in the application object, and that name resolution is working correctly.

  Examine the printing log files for more information. Go to Step 7.

• Is the print job missing from the SGD server?

  Check the configuration of the SGD server, as follows:

  • Check your UNIX or Linux system LPD printing configuration.

    For example, ensure that there are suitable entries in /etc/hosts.equiv or /etc/hosts.lpd, and that there are no .deny files, such as /etc/hosts.equiv.deny.

    Check that the lpd daemon is running and listening. For example, use the following commands:

  • Check that you can ping and telnet to the SGD server from the application server.

  • If you are using Windows Remote Desktop Services, display a command prompt and use the lpr -s server -p tta_printer filename command to print. If this works, this suggests the printer driver on the application server is not installed or configured correctly.

5.1.10.4.7: Step 7: Have You Examined the Print Log Files?

You can use the tarantella query command to examine the logs across the array. Log files are stored in /opt/tarantella/var/log on each SGD server in the array.

If the print log files are empty, edit the Log Filter, to log printing messages. In the Administration Console, go to the Global Settings, Monitoring tab, and add the following log filters:

If the log contains messages indicating problems with user name mappings, this suggests you are using shared accounts on the application server. See Section 5.1.10.2, “Application Server Checklist”.

This section describes some typical problems when printing through SGD and includes the following topics.

Dns Server Configuration In Linux 6 Step By Step Pdf Printer Software

When printing from a Windows application, users can set preferences for the printers they use. The following are common problems with printer preferences.

The first time a client printer is defined for a user, the printer preferences, such as the paper size and orientation, are the application server's defaults for the printer driver and not the client printer's current preferences.

Users can change the printer preferences on the application server, and these modified preferences are used when they next connect using a client device with the same printer.

When a user changes their printer preferences, for example by changing the default paper size, sometimes the change is not remembered when they next run a Windows application.

There is a delay between changing the preferences and the new preferences being sent to the client. When changing printer preferences, it is advisable to wait a few minutes before logging out of the Windows application.

If large numbers of client printers are present, printer preferences can sometimes become corrupted. Bob anderson stretching pdf italiano.

Use the Printer Preference Caching (--noprintprefs) attribute to disable the storing of printer preferences for a Windows application, as follows:

where appname is the name of the Windows application.

Printer preferences are linked directly to the driver name. So, if a user changes the printer they use and the new printer uses a different driver name, they have to set the printer preferences again.

The printer settings of a local printer are not set on the printer in the remote Windows application session when you use SGD. However, they are set when you use the Microsoft Remote Desktop Connection client.

SGD does not support this capability.

If you are using PDF printing on a Microsoft Windows client device, some printer settings might be ignored by the Adobe Reader.

This might be because the printer driver used for PDF printing has settings that are not available on the client printer.

Some settings, such as page orientation, have to be set in the Adobe Reader print dialog, as well as on the printer in the Windows application session. Once you have set up the Reader, the settings are remembered.

After disabling the SGD print system, by running tarantella print stop, it is still possible to spool print jobs on application servers. These jobs remained queued until SGD printing is restarted.

To prevent print jobs from being submitted, disable the SGD print queue manually on the application servers.

When using PDF printing, users might find that the fonts on the printed output are not what they expected.

As PDF printing relies on a combination of Windows printer drivers, when printing from Windows applications, Ghostscript and a PDF viewer to deliver its output, you might have to experiment with the font settings for each of these components to see if this produces a better result.

When printing from a Windows application and the document contains TrueType fonts, users might find that the printer is using its own fonts, called device fonts, instead of the TrueType fonts. This can result in some characters being printed as “empty boxes” ([]).

The solution to this problem is to force the printer to download the TrueType fonts for printing.

Display the Print dialog in the Windows application and select Properties, Advanced. In the Graphic section, change the TrueType Font option to Download as Softfont.

The names of printers created in a Windows Remote Desktop Services session depend on the client device platform.

For Unix, Linux, and Mac OS X platform client devices, the name comes from the printer configuration file used for the client device. See Section 5.1.7, “Configuring Printing to UNIX, Linux, and Mac OS X Platform Client Devices” for more details.

For Windows client devices, the name comes from the printer driver.

If you are using PDF printing, you can amend the names of the PDF printers. See Section 5.1.11.5, “Changing the Names of the SGD PDF Printers”.

The names of SGD PDF printers are configurable. You can amend these names as follows.

To change the PDF printer names for all users, use the following command:

To change the PDF printer names for an organization, organizational unit, or user profile object, the object must also be configured to override the parent object's printing settings. Use the following command:

Users who access Windows applications from UNIX, Linux, or Mac OS X platform client devices, might see a printer called _Default in their Windows application session. This can be confusing to users if their client printer has a different name or they have no client printer.

Redhat Print Server

This is caused by the default setting in the printerinfo.txt file, which is used to associate the printer driver name with a print job when printing from a Windows application.

To correct the printer name, edit the printerinfo.txt file.

To remove the _Default printer name, delete the _Default entry from the printerinfo.txt file.

See Section 5.1.7, “Configuring Printing to UNIX, Linux, and Mac OS X Platform Client Devices”, for more details about the printerinfo.txt file.

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. Legal Notices

Domain Name Service (DNS) is an internet service that maps IP addresses to fully qualified domain names (FQDN) and vice versa.

BIND stands for Berkley Internet Naming Daemon.

BIND is the most common program used for maintaining a name server on Linux.

In this tutorial, we will explain how to install and configure a DNS server.
If you are new to DNS, you should first understand the fundamentals of DNS and how it works.

1. Network Information

In this tutorial, we are going to setup a local DNS server for the network shown in the below diagram.

We’ll use “thegeekstuff.net” domain as an example for this DNS installation. “mail”, “web”, “ns” are the hosts that resides within this domain.

It is possible to configure a single system to act as a caching name server, primary/master and secondary/slave. We will configure this DNS as a Primay/Master as well as Caching DNS server.

We’ll be installing DNS server on “10.42.0.83”.

2. Install Bind

Install the bind9 package using the appropriate package management utilities for your Linux distributions.

On Debian/Ubuntu flavors, do the following:

On Redhat/CentOS/Fedora flavors, do the following:

All the DNS configurations are stored under /etc/bind directory. The primary configuration is /etc/bind/named.conf which will include other needed files. The file named /etc/bind/db.root describes the root nameservers in the world.

3. Configure Cache NameServer

The job of a DNS caching server is to query other DNS servers and cache the response. Next time when the same query is given, it will provide the response from the cache. The cache will be updated periodically.

Please note that even though you can configure bind to work as a Primary and as a Caching server, it is not advised to do so for security reasons. Having a separate caching server is advisable.

All we have to do to configure a Cache NameServer is to add your ISP (Internet Service Provider)’s DNS server or any OpenDNS server to the file /etc/bind/named.conf.options. For Example, we will use google’s public DNS servers, 8.8.8.8 and 8.8.4.4.

Uncomment and edit the following line as shown below in /etc/bind/named.conf.options file.

After the above change, restart the DNS server.

4. Test the Cache NameServer

You can use the dig command to test DNS services. DIG command examples explains more about how to perform DNS lookups.

Now when the second time you execute the dig, there should be an improvement in the Query time. As you see below, it took only 3 msec the second time, as it is getting the info from our caching DNS server.

5. Configure Primary/Master Nameserver

Next, we will configure bind9 to be the Primary/Master for the domain/zone “thegeekstuff.net”.

As a first step in configuring our Primary/Master Nameserver, we should add Forward and Reverse resolution to bind9.

To add a DNS Forward and Reverse resolution to bind9, edit /etc/bind9/named.conf.local.

Now the file /etc/bind/db.thegeekstuff.net will have the details for resolving hostname to IP address for this domain/zone, and the file /etc/bind/db.10 will have the details for resolving IP address to hostname.

6. Build the Forward Resolution for Primary/Master NameServer

Now we will add the details which is necessary for forward resolution into /etc/bind/db.thegeekstuff.net.

First, copy /etc/bind/db.local to /etc/bind/db.thegeekstuff.net

Next, edit the /etc/bind/db.thegeekstuff.net and replace the following.

1. In the line which has SOA: localhost. – This is the FQDN of the server in charge for this domain. I’ve installed bind9 in 10.42.0.83, whose hostname is “ns”. So replace the “localhost.” with “ns.thegeekstuff.net.”. Make sure it end’s with a dot(.).
2. In the line which has SOA: root.localhost. – This is the E-Mail address of the person who is responsible for this server. Use dot(.) instead of @. I’ve replaced with lak.localhost.
3. In the line which has NS: localhost. – This is defining the Name server for the domain (NS). We have to change this to the fully qualified domain name of the name server. Change it to “ns.thegeekstuff.net.”. Make sure you have a “.” at the end.

Next, define the A record and MX record for the domain. A record is the one which maps hostname to IP address, and MX record will tell the mailserver to use for this domain.

Once the changes are done, the /etc/bind/db.thegeekstuff.net file will look like the following:

6. Build the Reverse Resolution for Primary/Master NameServer

We will add the details which are necessary for reverse resolution to the file /etc/bind/db.10. Copy the file /etc/bind/db.127 to /etc/bind/db.10

Next, edit the /etc/bind/db.10 file, and basically changing the same options as /etc/bind/db.thegeekstuff.net

Next, for each A record in /etc/bind/db.thegeekstuff.net, add a PTR record.

Whenever you are modifying the file db.thegeekstuff.net and db.10, you need to increment the “Serial” number as well. Typically admin uses DDMMYYSS for serial numbers and when they modify, the change the serial number appropriately.

Finally, restart the bind9 service:

7. Test the DNS server

Now we have configured the DNS server for our domain. We will test our DNS server by pinging mail.thegeekstuff.net from web.thegeekstuff.net.

If the ping is success, then we have configured the DNS successfully.

You can also use nslookup and dig to test DNS servers.

On web.thegeekstuff.net server, add the following to /etc/resolv.conf

Now ping, mail.thegeekstuff.net, which should resolve the address appropriately from the DNS server that we just configured.

If you enjoyed this article, you might also like.