Internet protocol security IPsec — IPsec is actually a collection of multiple related protocols. It can be used as a complete VPN protocol solution, or it can be used simply as the encryption
scheme within L2TP or PPTP. IPsec exists at the network layer layer three in the ISO OSI model. IPsec extends standard IP for the purpose of supporting more secure Internet−based services
including, but not limited to, VPNs. IPsec specifically protects against man in the middle attacks by hiding IP addresses that would otherwise appear on the wire.
SOCKS network security protocol — The SOCKS system provides a unique alternative to other protocols for VPNs. SOCKS functions at the session layer layer five in the ISO OSI model,
compared to all of the other VPN protocols that work at layer two or three. This implementation offers advantages and disadvantages over the other protocol choices. Functioning at this higher
level, SOCKS allows administrators to limit VPN traffic to certain applications. To use SOCKS, however, administrators must configure SOCKS proxy servers within the client environments as well
as SOCKS software on the clients themselves see the section about proxies.
A number of vendors offer VPN−related products. These products sometimes do not work with each other because of the choice of incompatible protocols as described above or simply because of
lack of standardized testing. Some VPN products are hardware devices. Most VPN devices are effectively routers that integrate encryption functionality. Other types of VPN products are software
packages. VPN software installs on top of a host operating system and can require significant customization for the local environment. Many vendor solutions comprise both server−side
hardware and client−side software designed for use with the hardware.
VPN technology can also be used within the intranet itself to control access to individual subnets on the private network. In this mode, VPN clients connect to a VPN server that acts as a gateway to
computers behind it on the subnet. Note that this type of VPN implementation does not involve Internet resources because everything happens within the intranet. However, it does take
advantage of the security features and convenience of VPN technology.
An amazing amount of development effort has been invested in VPN technologies. Yet the task of choosing and deploying a VPN solution remains far from simple. It may prove helpful to train
workers in at least the basics of VPN clients to help them migrate to new VPN deployments. They have to be aware of the traffic congestion and router failures on the Internet that can adversely
impact the performance of the implemented VPN. It is also important when building a VPN to choose a high−quality ISP.
25.3.4 UNIX and Not−UNIX Platform Integration
An intranet is heterogeneous in many aspects, on different implementation levels, including the OS level. Same network services could be accomplished on multiple OS platforms, and the
implemented OS platform is completely hidden from the users. All differences are mostly invisible. However, this is not the case regarding the needed administration for provided intranet services.
Simply, sometime things are not going so smoothly, and we cannot ignore underlying differences. They can have a substantial impact to the overall intranet behavior and performances.
653
Intranet users simply use the network resources hardware and software and complain if something does not work, or works slowly. A typical working scenario is that a user logs in via a desktop,
checks e−mail, and continues to work in the intranet environment. NT clients access UNIX servers, request certain services on behalf of users, and return requested data to users. On the surface, this
working intranet environment looks uniform and contiguous. In reality there are certain discontinuities in its implementation.
Generally, the intranet benefit of using multiple OS platforms is that each platform is implemented on those places in the intranet where its advantages lead to better overall performance. But there
are also some disadvantages of mixed OS implementations. A certain level of the intranet customization can help to diminish these disadvantages. This customization is primarily related to a
unified intranet administration and management. To accomplish this task, a larger integration of implemented OS platforms is needed to avoid existing differences in their administrations. The
following text is an attempt to point to the main issues related to the integration of the UNIX and NT platforms to make the intranet a technically better place to work.
A uniform administration of individual user accounts — Users have to have the same login name, user ID, primary group, home directory, as well as authentication data password.
This is not trivial in the heterogeneous environment. UNIX supports NIS for centralized system administration see Chapter 17. But NIS is unknown to NT. Centralized NT
administration is provided via one or more primary domain controllers PDC. The two approaches are mutually incompatible, and the need for their integration is obvious. More
specifically it means that the UNIX Master NIS Server and NT Primary Domain Controller have to share the same administrative data and push them all over the intranet. In that way
UNIX NIS clients and desktops will see the same user administrative data.
There is third−party software that delivers the same. But we advocate a homemade solution. First we have to proclaim the master NIS server for the central administrative resource for
the whole intranet. Simultaneously UNIX part of the Intranet will be fully covered. Then we have to force that each action on the NIS master is automatically transferred and remotely
invoked on the NT PDC. That will cover the NT part of the network. Afterward every user will be identified identically anywhere on the intranet.
A homemade program even a script can handle the needed synchronization between NIS master and PDC. This presents a cost−effective and efficient solution.
1.
A uniform administration of groups — unique groups over the whole intranet are very important for a secure intranet operation. The groups have to be the same and users should
belong to the same groups. Access to the data is usually based on the files mode, and they are shared only among members of the same group. Unfortunately, the required uniqueness
is not possible for certain system groups that are too specific in UNIX and NT. These system groups remain, as they are, each in its own platform without any impact on the wider intranet
behavior.
The same approach from the previous paragraph can be implemented: NIS master vs. PDC 2.
654
3.
An integrated intranet file service — Users have to have unrestricted access to the same data. Especially users home directories should be unique. A kind of unified intranet file
service UIFS has to be provided. UNIX network filesystems — NFS see Chapter 18 are incompatible with NT Common Internet Filesystem CIFS. Neither side can provide UIFS for
both UNIX and NT parts of an intranet.
The most appropriate solution could be a UNIX NFS file server with the CIFS emulation software on it. UNIX file servers are stable and robust in their implementations. UNIX nfs
clients approach the file server normally, while at the same time the CIFS emulation software accommodates NT clients. There are several commercial CIFS emulation products,
as well as the freeware Samba package.
User home directories could and should be located on the UIFS file serverservers. UIFS and unique home directories relax other network applications also. Especially, it is easier to
enforce the required backup policy. Simply, important data to be backed up are grouped together on one or several UIFS servers. There is no need to worry about desktop data.
4.
A unified print service is much easier to accomplish. Network printers are compatible with both UNIX and NT clients. If a printing center organized around a print server with multiple
local printers is needed, NT print server is probably a better choice. 5.
A unified e−mail service is also easy to accomplish; a UNIX e−mail server seems to be appropriate. Sendmail see Chapter 20 is a mature and reliable e−mail product proven
through all years of its wide use. The compatibility of the intranet e−mail server with UNIX and NT clients is based, however, on the implementation of POP and IMAP protocols, which
are independent of sendmail and transparent over both platforms. 6.
Most other intranet services can run on any OS platform independently, like firewall, viruswall, or proxy. The only criterion for the implemented OS platform is overall service
performance. 7.
655
Section IV: Case Studies
Chapter List
Chapter 26: UNIX Installation Chapter 27: Upgrade Disk Space
Chapter 28: UNIX Emergency Situations
656
Chapter 26: UNIX Installation
26.1 Introductory Notes
The first step in dealing with an UNIX system is to install the operating system itself. On a UNIX platform, delivered systems with the OS preinstalled is more an exception than the rule. In any
case, among the administrative duties are the UNIX installation when we say UNIX installation we are thinking UNIX OS installation and the initial configuration of the installed UNIX system that will
allow access for further upgrades.
UNIX installation per se should not be a problem. There are two main reasons why: The installation procedure is usually well documented; the provided documentation usually
covers all possible installation scenarios, as well as potential troubleshooting. 1.
The system is not in an operational stage, and we are relaxed during the installation. It is easy to repeat an installation procedure if something is going wrong, we have started
everything from scratch, so we can do the same again. 2.
Nevertheless, any real installation example is always welcome and helpful. Different installation scenarios and options, and a general installation approach in the provided documentation can
sometimes be confusing. Existing dilemmas can be quickly resolved if we have an appropriate installation case in front of us. This is the purpose of this chapter. A few installation examples for the
currently most common UNIX flavors — Solaris, HP−UX, and Linux — could be very helpful in a number of real installation cases, and also very educational for the readers.
OS installation is the first step in making a UNIX system workable. However, this is not the only step in accomplishing this task, as well as keeping a UNIX system compliant with unavoidable upgrades,
updates, and patches. The second part of this chapter addresses these issues. For both parts it is assumed that we have workable hardware in front of us, that we have access to the system
console, and that the CD drive is available.
26.2 UNIX Installation Procedures
In this part, the installation procedure examples for a few common UNIX flavors are documented. Despite the fact that they are sufficiently general and applicable for listed UNIX flavors, they are
also site−specific. Please keep in mind that some differences in the installation procedures caused by different system hardware configurations andor operating system versions and releases are
always possible. This is the reason why, in each of the examples that follow, the relevant initial information is always provided.
26.2.1 HP−UX Installation
The following text describes in detail steps performed in installing HP−UX 10.20 operating system on the Series 800 HP system — model E35; the host is named blue in this example. The
described installation procedure also includes a mirroring of the root filesystem, which is realized as a single filesystem that also includes usr and var.
Power−on the system. 1.
Insert the HP−UX 10.20 Install and Core OS CD into the CD drive. 2.
Follow messages on the console. Pay attention to the message: 3.
657
