SGI Techpubs Library

The new home for SGI documentation is the SGI Customer Portal, This site will be redirected to the new location later this month.

Linux  »  Books  »  Administrative  »  
SGI Internet Server for Messaging Installation and Quick Start
(document number: 007-4294-003 / published: 2001-01-04)    table of contents  |  additional info  |  download
find in page

Chapter 5. Enabling HTTP Access for Linuxconf Administration

This chapter tells you how to enable Linuxconf HTTP access on port 98 to a browser running locally or on a remote workstation. This step is optional but recommended.

You will use the Linuxconf utility to make system administration changes; documentation required for those changes is available online in the SGI Internet Server Web administration graphical user interface (GUI) and in the SGI Internet Server Administrator's Guide.

This chapter discusses the following:

Caution: The Linuxconf HTTP interface does not feature SSL encryption, which means that your root password could potentially be snooped by a hacker if you allow it to travel over any untrusted network.

If your system cannot be accessed through a private network, you should not use the Linuxconf HTTP interface. You can still use the Web administration GUI to access tutorial documentation and apply it to a separate Linuxconf session, conducted using your KVM access or over your serial console.

Managing Linuxconf HTTP Access Control

By default, only superusers on a system have Linuxconf execution privilege. The application has the following user interfaces:

  • curses-based interface for use in a local shell or serial console

  • Gnome GUI for use in an X Windows environment

  • HTTP interface for use in a local or remote browser

Of these, only the first two are available by default. Before you activate the HTTP interface, do the following: in your ipchains (8) configuration, ensure that packets directed to port 98 on any of the public interfaces are quietly dropped. If you have followed the SGI recommendations for Bastille Linux, this will already have been done for you.

Local Console

If you have chosen to use a local console for the preproduction environment (as done in “Local Console Access” in Chapter 2), do the following:

  1. Open a shell by clicking the Gnome footprint logo in the control panel at the bottom of your screen

  2. Become superuser and execute the following command to launch the Gnome GUI interface in background mode:

    # /bin/linuxconf &

Remote Console

If you have chosen to use a remote console for the preproduction environment (as done in “Serial Console Access” in Chapter 2), do the following:

  1. Open a shell over a private network or your serial console

  2. Become superuser

  3. Enter the following to launch Linuxconf:

    # /bin/linuxconf

Configuring Linuxconf for HTTP Access

Note: This section describes using the curses-based interface; if using the GUI, you will point and click instead.

  1. Use your up and down arrow keys to reach the Networking tab. If it has a "+" next to it, press Enter to open it up.

  2. Open up the Misc subtab in the same way. Navigate to the Linuxconf network access feature line and press Enter.

  3. Enable option: press Space to allow all users with Linuxconf execution privileges access to the HTTP interface.

  4. Log access option: press Space to ensure that all Linuxconf HTTP login attempts are logged.

  5. Host or network option:

    Note: You must explicitly allow some specific access by filling in this field. If you leave it blank, the HTTP interface remains effectively disabled.

    Linuxconf gives you the following options:

    • To limit access to all hosts on your private network, specify the name of the associated network port (eth1).

    • If your network architecture has three tiers, you may instead specify the IP address of your most private subnet. For a typical C-class subnet, this address would take the form x.x.x.0. In this case, the netmask (see below) is required.

    • If you prefer, you may specify the hostname or IP address of a specific workstation in your network operations center. Make sure your server can resolve the hostname without having to consult a DNS server on a public network.

    Press Enter to move on to the next line.

  6. Netmask (optional): if you have restricted access to the private network port, leave this blank. If you specified a C-class subnet, use the value If you specified a host on a C-class subnet, the default value of is fine.

  7. Additional entries: if you specify more than one host/network+netmask combination, access will be allowed if any of them are met (that is, a logical OR). Mixing restriction types complicates the access control logic. Use this option to ensure that you have access from from multiple network operations center workstations.

  8. Press Tab to proceed to the Accept button.

    Note: If you have specified a restriction that cannot be verified when you press Enter at this point, it is possible that Linuxconf will hang. If this happens, press Ctrl-C to abort the session.

    If you actually must apply such a restriction, reenter Linuxconf, provide values that are syntactically equivalent, and then correct them by hand in the /etc/conf.linuxconf file.

  9. If you want to allow HTTP access for more than two network operations center workstations, press Tab again to reach the Add button, then press Enter.

The following example demonstrates all three mechanisms for allowing HTTP access to Linuxconf:

  • Interface name

  • Subnet

  • Host

However, to keep things simple, SGI does not recommend actually mixing them. (User input is shown in bold.)

+------------ Linuxconf html access control ------------------+
| You can specify which networks or hosts are allowed         |
| to access linuxconf to configure your computer              |
| (They need a password still)                                |
| Linuxconf listen on port 98. Point your browser to          |
| http://your_machine:98/                                     |
|                                                             |
|                      +------------------------------+       |
|                      |[X] Enable network access     |       |
|Log access            |[X] in /var/log/htmlaccess.log|       |
|Network or host:      |eth1                          |       |
|Netmask(optional):    |                              |       |
|Network or host:      |                     |       |
|Netmask(optional):    |                     |       |
|Network or host:      |bobs_workstation              |       |
|Netmask(optional):    |                              |       |
|Network or host:      |                              |       |
|Netmask(optional):    |                              |       |
|                      +------------------------------+       |
|     +------+       +------+       +---+       +----+        |
|     |Accept|       |Cancel|       |Add|       |Help|        |
|     +------+       +------+       +---+       +----+        |

Activating Linuxconf HTTP Invocation Privileges

For security purposes, you should not run linuxconf --http from the command line (or from a script); you should launch it from inetd as described later in this section.

However, you can use the inetd(8) super-daemon to terminate the Linuxconf HTTP process after a configurable interval without activity.

Do the following:

  1. Open up a shell as superuser.

  2. Verify that the super-daemon is currently running:

    # /bin/ps -fC inetd

    By default, it is launched at boot time by way of the symbolic link S50inet in /etc/rc.d/rc3.d or /etc/rc.d/rc5.d (depending on your init state).

  3. Verify that the /etc/services file contains the appropriate Linuxconf information:

    # /bin/grep linuxconf /etc/services

    The output should read:

    linuxconf 98/tcp

    If it does not, edit /etc/services and append that line.

  4. Verify that the /etc/inetd.conf file contains the appropriate Linuxconf information:

    # /bin/grep linuxconf /etc/inetd.conf

    By default, the output should read:

    #linuxconf stream tcp wait root /bin/linuxconf linuxconf --http

    Edit the file and remove the # character to uncomment the line so that inetd will spawn the Linuxconf HTTP interface in response to an incoming TCP request on port 98.

    If the line is missing, edit the /etc/inetd.conf file and append the line minus the # character.

  5. If you had to make changes to either the /etc/services or /etc/inetd.conf files, execute the following command to ensure that the inetd process rereads its configuration files:

    # /usr/bin/killall -HUP inetd

If you want to test this, start a browser on any of the systems for which you earlier allowed Linuxconf HTTP access. Point it at the following URL:


Replace hostname with the actual name you have associated with the private interface of your SGI Internet Server in your private DNS server.

Note: The trailing “/” in the URL is required in this case.

If you have a private network interface, and have previously restricted access to port 98 on that interface, the following applies: if you attempt to access the Linuxconf HTTP interface using a name or IP address associated with any of the public interfaces, your request will be quietly dropped by ipchains(8). Instead, use the name or IP address associated with your private interface. That interface name or one of its aliases should match the contents of the value of HOSTNAME in /etc/sysconfig/network, up to but not including the first dot. This is required to use the links from the Web administration GUI to the Linuxconf HTTP interface. See also Chapter 3, “Configuring the Network”.

Managing Linuxconf User Privileges

If you created a second superuser account during the Bastille Linux procedure, that account will be identical to user root in every respect except for the account name and password. No further action is required to ensure this account has Linuxconf access.

Do not give any nonprivileged user execution for all Linuxconf features. However, you can choose to delegate selected tasks, such as post office protocol (POP) account management, to a user account.

Caution: By delegating selected tasks, you are providing not just execution permissions for certain sections but also read-only access to the rest of Linuxconf. Therefore, you should only exercise this option on behalf of individuals you trust. In a commercial environment, this should apply to every member of your operations staff.

For example, if you want to delegate POP account management, do the following:

  1. Reenter Linuxconf as superuser.

  2. In succession, open the tabs for the following:

    Users accounts -> Normal -> User accounts

  3. Select the account to which you want to delegate POP account management.

  4. Scroll down to the section marked Privileges . Grant the user access to Linuxconf, plus POP account management and/or Virtual POP account management.

  5. Press Accept and Quit .

Note: Only superusers are allowed to invoke the curses-based interface from a shell due to execution permissions on the /bin/linuxconf binary. You should ask them to use the HTTP interface instead, provided you have enabled access to that.

Delegating Selected Linuxconf Privileges to Hosted Customers

In theory, the mechanism described above could be used to delegate tasks such as POP account management to hosted customers. This would alleviate the system administration overhead associated with your SGI Internet Server for Messaging. However, SGI recommends against delegating any Linuxconf privileges to any hosted customers using either shared or dedicated hosting:

  • With shared hosting, Linuxconf privileges are not granular enough for delegation to work as desired.

    Any customer to whom you delegate Linuxconf POP account management privileges would also be able manipulate the POP accounts of all other customers hosted on the same system. Some of them might be competitors. From a business perspective, this ought to represent an unacceptable risk to you.

  • With dedicated hosting, you would either have to allow these customers access to a private network (such as through dial-in modems), or else open up Linuxconf HTTP access on a public interface.

You should use another mechanism to implement this type of delegation.

Because the current Linuxconf HTTP interface does not have transport encryption, allowing use by customers introduces the significant risk of having system passwords snooped by a hacker. In addition, you have no control over how carefully a hosted customer would protect any password that you provide.

Separately, if one of your own privileged system administrators were ever to succeed in accessing the Linuxconf HTTP interface by means of the public interface, the system root password could be exposed.

If you open up Linuxconf HTTP access on a public interface, and a hacker is able to obtain a password for a privileged account, your system is instantly compromised. Regardless of whether the transport is encrypted, the hacker could simply access port 98 and perform malicious actions. This is an unacceptable risk.

SGI Internet Server for Messaging Installation and Quick Start
(document number: 007-4294-003 / published: 2001-01-04)    table of contents  |  additional info  |  download

    Front Matter
    About This Guide
    Chapter 1. Configuring the SGI Internet Server for Messaging
    Chapter 2. Setting Up Console Access
    Chapter 3. Configuring the Network
    Chapter 4. Server Lockdown Using Bastille Linux
    Chapter 5. Enabling HTTP Access for Linuxconf Administration
    Chapter 6. SGI Internet Server for Messaging Web Administration GUI
    Appendix A. Password Worksheet
    Appendix B. Network Connectivity Worksheet
    Appendix C. Reinstalling from CD-ROM

Home    •     What's New    •     Help    •     Terms of Use    •     Privacy Policy    •

© 2009 - 2015 Silicon Graphics International Corp. All Rights Reserved.