Thursday, September 9, 2010

Multiple NIC In Same Subnet IP Address - ARP Problem

/proc/sys/net/ipv4/conf/(eth0 || eth1)/arp_filter change the value to a 1 instead of 0.

ip route del default

route add default gw 192.168.1.1 dev eth1
route add default gw 192.168.1.1 dev eth0

ip route add 192.168.1.0/24 dev eth0 table 2
ip route add 0/0 via 192.168.1.1 dev eth0 table 2
ip rule add from 192.168.1.123 table 2
ip rule add to 192.168.1.123 table 2

ip route add 192.168.1.0/24 dev eth1 table 3
ip route add 0/0 via 192.168.1.1 dev eth1 table 3
ip rule add from 192.168.1.121 table 3
ip rule add to 192.168.1.121 table 3

echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_filter
echo 1 > /proc/sys/net/ipv4/conf/eth1/arp_filter

Security Parameter for sysctl.conf - Example

sysctl -p
sysctl -w net.ipv4.route.flush=1

Example:
# Kernel sysctl configuration file for Red Hat Linux
#
# For binary values, 0 is disabled, 1 is enabled. See sysctl(8) and
# sysctl.conf(5) for more details.

# Controls IP packet forwarding
net.ipv4.ip_forward = 0

# Controls source route verification
net.ipv4.conf.default.rp_filter = 1

# Controls the System Request debugging functionality of the kernel
kernel.sysrq = 0

# Controls whether core dumps will append the PID to the core filename.
# Useful for debugging multi-threaded applications.
kernel.core_uses_pid = 1

#Prevent SYN attack
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 2048
net.ipv4.tcp_synack_retries = 2

# Disables packet forwarding
net.ipv4.ip_forward=0

# Disables IP source routing
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.lo.accept_source_route = 0
net.ipv4.conf.eth0.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0

# Enable IP spoofing protection, turn on source route verification
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.lo.rp_filter = 1
net.ipv4.conf.eth0.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1

# Disable ICMP Redirect Acceptance
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.lo.accept_redirects = 0
net.ipv4.conf.eth0.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0

# Enable Log Spoofed Packets, Source Routed Packets, Redirect Packets
net.ipv4.conf.all.log_martians = 1
net.ipv4.conf.lo.log_martians = 1
net.ipv4.conf.eth0.log_martians = 1

# Disables IP source routing
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.lo.accept_source_route = 0
net.ipv4.conf.eth0.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0

# Enable IP spoofing protection, turn on source route verification
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.lo.rp_filter = 1
net.ipv4.conf.eth0.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1

# Disable ICMP Redirect Acceptance
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.lo.accept_redirects = 0
net.ipv4.conf.eth0.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0

# Disables the magic-sysrq key
kernel.sysrq = 0

# Modify system limits for Ensim WEBppliance
fs.file-max = 65000

# Decrease the time default value for tcp_fin_timeout connection
net.ipv4.tcp_fin_timeout = 15

# Decrease the time default value for tcp_keepalive_time connection
net.ipv4.tcp_keepalive_time = 1800

# Turn off the tcp_window_scaling
net.ipv4.tcp_window_scaling = 0

# Turn off the tcp_sack
net.ipv4.tcp_sack = 0

# Turn off the tcp_timestamps
net.ipv4.tcp_timestamps = 0

# Enable TCP SYN Cookie Protection
net.ipv4.tcp_syncookies = 1

# Enable ignoring broadcasts request
net.ipv4.icmp_echo_ignore_broadcasts = 1

# Enable bad error message Protection
net.ipv4.icmp_ignore_bogus_error_responses = 1

# Log Spoofed Packets, Source Routed Packets, Redirect Packets
net.ipv4.conf.all.log_martians = 1

# Set maximum amount of memory allocated to shm to 256MB
kernel.shmmax = 268435456

# Improve file system performance
vm.bdflush = 100 1200 128 512 15 5000 500 1884 2

# Improve virtual memory performance
vm.buffermem = 90 10 60

# Increases the size of the socket queue (effectively, q0).
net.ipv4.tcp_max_syn_backlog = 1024

# Increase the maximum total TCP buffer-space allocatable
net.ipv4.tcp_mem = 57344 57344 65536

# Increase the maximum TCP write-buffer-space allocatable
net.ipv4.tcp_wmem = 32768 65536 524288

# Increase the maximum TCP read-buffer space allocatable
net.ipv4.tcp_rmem = 98304 196608 1572864

# Increase the maximum and default receive socket buffer size
net.core.rmem_max = 524280
net.core.rmem_default = 524280

# Increase the maximum and default send socket buffer size
net.core.wmem_max = 524280
net.core.wmem_default = 524280

# Increase the tcp-time-wait buckets pool size
net.ipv4.tcp_max_tw_buckets = 1440000

# Allowed local port range
net.ipv4.ip_local_port_range = 16384 65536

# Increase the maximum memory used to reassemble IP fragments
net.ipv4.ipfrag_high_thresh = 512000
net.ipv4.ipfrag_low_thresh = 446464

# Increase the maximum amount of option memory buffers
net.core.optmem_max = 57344

# Increase the maximum number of skb-heads to be cached
net.core.hot_list_length = 1024

## DO NOT REMOVE THE FOLLOWING LINE!
## nsobuild:20051206

Thursday, April 23, 2009

Solaris Command

System Information


Print system information

# prtconf

Check the memory

# prtconf | grep Memory

Swap administration, check swap size

# man swap
# swap -s


Describe instruction set architectures

# isainfo -kv

To find if the system is 32 bit or 64 bit

# isainfo -v


Packages


Extract from URL http://www.softpanorama.org/Solaris/Packages/index.shtml

All the software distributed as part of Solaris by Sun is released in package format. This includes all the standard shells and command sets. Packages clearly emerge as the preferred way of distributing software on Solaris specifically due to the following features:

Uniform package installation and removal interfaces (pkgadd and pkgrm) Ability to see exactly which (versions of) packages are installed on the system (pkgchk -l) Ability to verify the integrity of the contents of the package (pkgchk -p -l) Ability to specify package dependencies and/or incompatibilities (depend, compver) Ability to specify additional space requirements for the package (space) Ability to create custom, dynamic package installation and removal scripts (request, checkinstall, preinstall, postinstall; preremove, postremove, and Class Action scripts) It is possible to convert RPM to Solaris packages.

The most commonly used package management commands are:

pkgadd Adds a package to the target system. Only root can run "pkgadd" pkgrm Removes an installed package from a target system pkgchk Checks a file to determine from which package it was installed. In case you suspect unauthorized modification of the file you can check which package an installed file was extracted from by using the pkgchk command. pkginfo -- list of installed packages pkgadm Here is a list of typical commands used :

To add a package
# pkgadd -d
# pkgadd -d . , for example pkgadd -d . SFWsnort

To remove a package
# pkgrm

To get short description (info) on a package
# pkginfo -x
# pkginfo -l

To list all installed packages
# pkginfo

To list the files that constitute the package
# pkgchk -l
# pkgchk -l | grep Pathname # lists files only.
# pkgchk -d -l

To what package the file /usr/bin/ls belongs:
# pkgchk -lp /usr/bin/ls
or
# grep /var/sadm/install/contents

To find out what files are in a package
# grep /var/sadm/install/contents

To find out what runlevel you're in
# who -r

Services

Observing services, lets say sendmail service

#svcs -d network/smtp:sendmail
#svcs -p network/smtp:sendmail




X Applications


Clock

#/usr/openwin/bin/xclock

Move File System from ZFS to UFS

# zpool create rootpool c0t1d0s1
# zfs create rootpool/rootfs
# zfs set mountpoint=legacy rootpool/rootfs
# mkdir /zfsroot
# mount -F zfs rootpool/rootfs /zfsroot

add this entry in /etc/vfstab:

rootpool/rootfs   -                       /backup zfs     1  yes     -


Moving back from ZFS to UFS:

Identify which disk was used from zfs, in our case it was "c0t1d0s1"

#zpool destroy -R rootpool
#newfs /dev/dsk/c0t0d0s1

Check the file system

# fstyp /dev/dsk/c0t0d0s1
ufs

and mount it to use

#mount /dev/dsk/c0t0d0s1 /dirname

plz note that above mount is temporary, to make it permanent make entry in /etc/vfstab.

Comment the /etc/vfstab entry from zfs and uncomment the entry for the above partition and give

#mount -a



Some additional command for adding/deleting & setting mount point for ZFS filesystem.

# zfs list
NAME                       USED  AVAIL  REFER  MOUNTPOINT
newpool 11.0G 123G 94K /newpool
newpool/ROOT 4.43G 123G 18K legacy
newpool/ROOT/solaris10_8 4.43G 123G 4.43G /
newpool/dump 1.50G 123G 1.50G -
newpool/export 142K 123G 20K /export
newpool/export/home 122K 123G 122K /export/home
newpool/opt 18K 123G 18K /opt
newpool/swap 1G 124G 16K -
newpool/u01 4.08G 123G 4.08G /u01
#zfs destroy -rf newpool/export
#zfs create newpool/export_home
#zfs set mountpoint=/export/home newpool/export_home
# zfs list
NAME                       USED  AVAIL  REFER  MOUNTPOINT
newpool 14.8G 119G 94K /newpool
newpool/ROOT 3.99G 119G 18K legacy
newpool/ROOT/solaris10_8 3.99G 119G 3.99G /
newpool/dump 1.50G 119G 1.50G -
newpool/export_home 158M 119G 158M /export/home
newpool/opt 4.08G 119G 4.08G /opt
newpool/swap 1G 120G 16K -
newpool/u01 4.08G 119G 4.08G /u01



Reference

http://www.solarisinternals.com/wiki/index.php/ZFS_Best_Practices_Guide

How to create SWAP in Live Linux Server

How to create SWAP in Live Linux Server

[root@manage squid]# free -m

             total       used       free     shared    buffers     cached
Mem: 1005 712 292 0 23 231
-/+ buffers/cache: 457 547
Swap: 250 21 229

[root@manage squid]# df -h

Filesystem            Size  Used Avail Use% Mounted on
/dev/sda5 695M 373M 287M 57% /
/dev/sda1 23M 9.0M 13M 42% /boot
/dev/sda9 197M 928k 186M 0% /home
/dev/sda6 486M 156M 305M 34% /usr/local
/dev/sda7 32G 14G 16G 48% /var

[root@manage /]# dd if=/dev/zero of=/var/swapfile count=1024 bs=1024000

1024+0 records in
1024+0 records out

[root@manage /]# mkswap /var/swapfile

Setting up swapspace version 1, size = 1048571904 bytes

[root@manage /]# swapon /var/swapfile

[root@manage /]# free -m

             total       used       free     shared    buffers     cached
Mem: 1005 992 12 0 26 750
-/+ buffers/cache: 215 789
Swap: 1250 24 1226

[root@manage /]# vi /etc/fstab

/dev/sda5               /                       newfs   defaults        1 1
/dev/sda1 /boot newfs defaults 1 2
/dev/sda9 /home newfs defaults 1 2
/dev/fd0 /mnt/floppy auto noauto,owner 0 0
/dev/sda6 /usr/local newfs defaults 1 2
/dev/sda7 /var newfs defaults 1 2
none /proc proc defaults 0 0
none /dev/pts devpts gid=5,mode=620 0 0
/dev/sda8 swap swap defaults 0 0
/var/swapfile swap swap defaults 0 0

Saturday, August 30, 2008

User Authentication HOWTO

Peter Hernberg
Floris Lambrechts − Language changes, various small fixes (v0.8).
2000−05−02
Revision History
Revision 0.8 2003−02−20 Revised by: fl
language changes, various small fixes
Revision 0.5 2000−05−15 Revised by: ph
added section on securing pam, added resources section
Revision 0.1 2000−05−02 Revised by: ph
initial version
Explains how user and group information is stored and how users are authenticated on a Linux system (PAM),
and how to secure you system's user authentication.
Table of Contents
1. Introduction....................................................................................................................................................1
1.1. How this document came to be.........................................................................................................1
1.2. New versions....................................................................................................................................1
1.3. Feedback..........................................................................................................................................1
1.4. Copyrights and Trademarks..............................................................................................................1
1.5. Acknowledgements and Thanks.......................................................................................................1
1.6. Assumptions about the reader...........................................................................................................2
2. How User Information is Stored on Your System.......................................................................................3
2.1. /etc/passwd.......................................................................................................................................3
2.2. Shadow passwords...........................................................................................................................3
2.3. /etc/group and /etc/gshadow.............................................................................................................3
2.4. MD5 encrypted passwords................................................................................................................4
2.5. Sifting through the mess...................................................................................................................4
3. PAM (Pluggable Authentication Modules)...................................................................................................5
3.1. Why..................................................................................................................................................5
3.2. What.................................................................................................................................................5
3.2.1. Distributions that support pam................................................................................................5
3.2.2. Installing PAM........................................................................................................................6
3.3. How..................................................................................................................................................6
3.3.1. PAM configuration files..........................................................................................................6
3.3.2. A little something....................................................................................................................6
3.3.3. Configuration syntax...............................................................................................................7
3.3.4. pam.conf configuration...........................................................................................................8
3.4. Getting more information.................................................................................................................8
4. Securing User Authentication.......................................................................................................................9
4.1. A strong /etc/pam.d/other..................................................................................................................9
4.1.1. A paranoid configuration.........................................................................................................9
4.1.2. A kinder configuration............................................................................................................9
4.1.3. Choosing a /etc/pam.d/other..................................................................................................10
4.2. Disabling logins for user with null passwords................................................................................10
4.3. Disable unused services..................................................................................................................10
4.4. Password−cracking tools................................................................................................................10
4.5. Shadow and MD5 passwords..........................................................................................................11
5. Tying it all together......................................................................................................................................12
5.1. Apache + mod_auth_pam...............................................................................................................12
5.2. Our example...................................................................................................................................12
5.3. Installing mod_auth_pam...............................................................................................................12
5.4. Configuring PAM...........................................................................................................................12
5.4.1. Deciding how to configure PAM..........................................................................................12
5.5. Configuring Apache........................................................................................................................13
5.6. Testing our setup............................................................................................................................13
User Authentication HOWTO
i
Table of Contents
6. Resources......................................................................................................................................................14
6.1. PAM...............................................................................................................................................14
6.2. General Security.............................................................................................................................14
6.3. Offline Documentation..................................................................................................................14
7. Conclusion....................................................................................................................................................15
User Authentication HOWTO
ii
1. Introduction
1.1. How this document came to be
When trying to add a number of (mostly unnecessary :) network services to my existing home network, I kept
running into the problem of authentication, so I decided to figure out how authentication works on linux
systems, write a HOWTO, and call it my senior project. I hope this document helps you understand this
often−forgotten, but very important, aspect of system administration.
1.2. New versions
Unitl I get my domain up and running properly, the newest version of this document will be available from
http://www.linuxdoc.org/.
1.3. Feedback
Comments, corrections, suggestions, flames, and flying saucer sightings can be sent to petehern@yahoo.com.
1.4. Copyrights and Trademarks
(c) 2000 Peter Hernberg
This manual may be reproduced in whole or in part, without fee, subject to the following restrictions:
The copyright notice above and this permission notice must be preserved complete on all complete or
partial copies
·
· Any translation or derived work must be approved by the author in writing before distribution.
If you distribute this work in part, instructions for obtaining the complete version of this manual must
be included, and a means for obtaining a complete version provided.
·
Small portions may be reproduced as illustrations for reviews or quotes in other works without this
permission notice if proper citation is given. Exceptions to these rules may be granted for academic
purposes: Write to the author and ask. These restrictions are here to protect us as authors, not to
restrict you as learners and educators. Any source code (aside from the SGML this document was
written in) in this document is placed under the GNU General Public License, available via
anonymous FTP from the GNU archive.
·
1.5. Acknowledgements and Thanks
Thanks to my family for putting up with me for 18 years. Thanks to the Debian folks for making such a sweet
distro for me to play with. Thanks to CGR for paying me to be a geek. Thanks to Sandy Harris for his helpful
suggestions. Finally, I'd like thank the makers of ramen noodles, because I don't know how I'd live without
them.
1. Introduction 1
1.6. Assumptions about the reader
For the purpose of this document, it is assumed that the reader is comfortably with executing commands at the
command line and editing text configuration files.
User Authentication HOWTO
1. Introduction 2
2. How User Information is Stored on Your System
2.1. /etc/passwd
On almost all linux distributions (and commercial *nixes as well), user information is stored in
/etc/passwd, a text file which contains the user's login, their encrypted password, a unique numerical user
id (called the uid), a numerical group id (called the gid), an optional comment field (usually containing such
items as their real name, phone number, etc.), their home directory, and their preferred shell. A typical entry in
/etc/passwd looks something like this:
pete:K3xcO1Qnx8LFN:1000:1000:Peter Hernberg,,,1−800−FOOBAR:/home/pete:/bin/bash
As you can see, it's pretty straight−forward. Each entry contains the six fields I described above, with each
field separated by a colon. If this were as complex as user authentication got, there would be no need for this
HOWTO.
2.2. Shadow passwords
Looking at your /etc/passwd, it's likely that you actually saw something like this:
pete:x:1000:1000:Peter Hernberg,,,1−800−FOOBAR:/home/pete:/bin/bash
Where did the encrypted password go? Before I tell you where it went, a bit explanation is required.
The /etc/passwd file, which contains information about all users, including their encrypted password, is
readable by all users, making it possible for any user to get the encrypted password of everyone on the system.
Though the passwords are encrypted, password−cracking programs are widely available. To combat this
growing security threat, shadow passwords were developed.
When a system has shadow passwords enabled, the password field in /etc/passwd is replaced by an "x"
and the user's real encrypted password is stored in /etc/shadow. Because /etc/shadow is only readable
by the root user, malicious users cannot crack their fellow users' passwords. Each entry in /etc/shadow
contains the user's login, their encrypted password, and a number of fields relating to password expiration. A
typical entry looks like this:
pete:/3GJllg1o4152:11009:0:99999:7:::
2.3. /etc/group and /etc/gshadow
Group information is stored in /etc/group. The format is similar to that of /etc/passwd, with the
entries containing fields for the group name, password, numerical id (gid), and a comma−separated list of
group members. An entry in /etc/group looks like this:
pasta:x:103:spagetti,fettucini,linguine,vermicelli
2. How User Information is Stored on Your System 3
As you can see from the "x" in the password field, group passwords can be shadowed as well. Although
groups almost never have their own passwords, it is worth noting that shadowed group password information
is stored in /etc/gshadow.
2.4. MD5 encrypted passwords
Traditionally, unix passwords were encrypted with the standard crypt() function. (For more information on the
crypt() function, see the crypt(3) manpage.) As computers grew faster, passwords encrypted with this function
became easier to crack. As the internet emerged, tools for distributing the task of password−cracking across
multiple hosts became available. Many 'newer' distributions ship with the option of encrypting passwords with
the stronger MD5 hash algorithm. (For more information on the MD5 hash algorithm, consult RFC 1321.)
While MD5 passwords will not eliminate the threat of password cracking, they will make cracking your
passwords much more difficult.
2.5. Sifting through the mess
As you can see, there are a number of different ways user authentication information can be stored on your
system (shadow passwords without MD5 encryption, /etc/passwd passwords with MD5 encryption, etc.).
How do programs like login and su know how to verify your password? Worse yet, what if you wanted to
change the way passwords are stored on your system? How will programs that need your password know that
passwords are stored differently? PAM is the answer.
User Authentication HOWTO
2. How User Information is Stored on Your System 4
3. PAM (Pluggable Authentication Modules)
Pluggable authentication modules are at the core of user authentication in any modern linux distribution.
3.1. Why
Back in the good old days of linux, if a program, such as su, passwd, login, or xlock, needed to authenticate a
user, it would simply read the necessary information from /etc/passwd. If it needed to change the users'
password, it would simply edit /etc/passwd. This simple but clumsy method presented numerous
problems for system administrators and application developers. As MD5 and shadow passwords became
increasingly popular, each program requiring user authentication had to know how to get the proper
information when dealing with a number of different schemes. If you wanted to change your user
authentication scheme, all these programs had to be recompiled. PAM eliminates this mess by enabling
programs to transparently authenticate users, regardless of how user information is stored.
3.2. What
Quoting from the Linux−PAM System Administrator's Guide: "It is the purpose of the Linux−PAM project to
separate the development of privilege granting software from the development of secure and appropriate
authentication schemes. This is accomplished by providing a library of functions that an application may use
to request that a user be authenticated." With PAM, it doesn't matter whether your password is stored in
/etc/passwd or on a server in Hong Kong. When a program needs to authenticate a user, PAM provides a
library containing the functions for the proper authentication scheme. Because this library is loaded
dynamically, changing authentication schemes can be done by simply editing a configuration file.
Flexibility is one of PAM's greatest strengths. PAM can be configured to deny certain programs the right to
authenticate users, to only allow certain users to be authenticated, to warn when certain programs attempt to
authenticate, or even to deprive all users of login privileges. PAM's modular design gives you complete
control over how users are authenticated.
3.2.1. Distributions that support pam.
Nearly all popular distributions have supported PAM for some time. Here's an incomplete list of distributions
that support PAM:
· Redhat since version 5.0
· Mandrake since 5.2
· Debian since version 2.1 (partial support in 2.1 −− complete support in 2.2)
· Caldera since version 1.3
· Turbolinux since version 3.6
· SuSE since version 6.2
This list is certainly incomplete and possibly inaccurate. I'd appreciate it if you sent any corrections or
additions to this list to .
3. PAM (Pluggable Authentication Modules) 5
3.2.2. Installing PAM
Installing PAM from scratch is long process, beyond the scope of this HOWTO. If PAM isn't installed on
your system, you're probably running such an old version of your distribution that there are many other
reasons to upgrade. If you really want to do it yourself, then you're certainly not the sort of person who needs
any help from me. For all these reasons, I'm going to assume that you already have PAM installed.
3.3. How
Enough talk, let's dig in.
3.3.1. PAM configuration files
PAM configuration files are stored in the /etc/pam.d/ directory. (If you don't have /etc/pam.d/
directory, don't worry, I'll cover that in the next section) Let's go over there and take a look.
~$ cd /etc/pam.d
/etc/pam.d/$ ls
chfn chsh login other passwd su xlock
/etc/pam.d/$
Your system may have a few more or a few less files in this directory, depending on what's installed on your
system. Whatever the details, you probably saw a file for each of the programs on your system that
authenticate users. As you probably already guessed, each file contains the PAM authentication configuration
for the program it's named after (except for the other file, which we'll talk about in a little bit). Let's take a
look the PAM configuration file for login (I've condensed the file for the sake of simplicity):
/etc/pam.d/$ cat login
# PAM configuration for login
auth requisite pam_securetty.so
auth required pam_nologin.so
auth required pam_env.so
auth required pam_unix.so nullok
account required pam_unix.so
session required pam_unix.so
session optional pam_lastlog.so
password required pam_unix.so nullok obscure min=4 max=8
Before I dig into this file, I must mention a little something.
3.3.2. A little something
A small percentage of the readers are probably thinking, "Oh no! I don't have a /etc/pam.d directory! Your list
of distributions says that my distribution includes PAM, but I can't find that directory. Without PAM, my life
is empty and meaningless! What can I do?" Don't worry, all is not lost. If you know that your distribution
includes PAM, but you have no /etc/pam.d/ directory, then your PAM configuration is stored in
/etc/pam.conf. Rather than being spread across several files, all your PAM configuration is stored in a
single file. This adds a little twist to PAM configuration, but the proper adjustments are pointed out in section
3.3.4.
User Authentication HOWTO
3. PAM (Pluggable Authentication Modules) 6
3.3.3. Configuration syntax
PAM configuration files have the following syntax:
type control module−path module−arguments
Using the login configuration file (see above) as an example let's take a look a the syntax for PAM
configuration files:
PAM configuration tokens
type
The type token tells PAM what type of authentication is to be used for this module. Modules of the
same type can be "stacked", requiring a user to meet multiple requirements to be authenticated. PAM
recognizes four types:
account
Determines whether the user is allowed to access the service, whether their passwords has
expired, etc.
auth
Determines whether the user is who they claim to be, usually by a password, but perhaps by a
more sophistcated means, such as biometrics.
password
Provides a mechanism for the user to change their authentication. Again, this usually their
password.
session
Things that should be done before and/or after the user is authenticed. This might included
things such as mounting/unmounting the user home directory, logging their login/logout, and
restricting/unrestricting the services available to the user.
In the login config file, we see at least one entry for each type. Since this the program that allows user
to login (hence the name :), it's understandable that it needs to access all of the different types of
authentication.
control
The control token tells PAM what should be done in if authentication by this module fails. PAM
recognizes four control types:
requisite
Failure to authenticate via this module results in immediate denial of authentication.
required
Failure also results in denial of authentication, although PAM will still call all the other
modules listed for this service before denying authentication.
sufficient
If authentication by this module is successful, PAM will grant authentication, even if a
previous required module failed.
optional
Whether this module succeeds or fails is only significant if it is the only module of its type for
this service.
In the configuration file for login, we see nearly all of the different control types. Most of the required
User Authentication HOWTO
3. PAM (Pluggable Authentication Modules) 7
modules are pam_unix.so (the main authentication module), the single requisite module is
pam_securetty.so (which makes sure the user is logging in on a secure console), and the only
optional module is pam_lastlog.so (the module that retrieves information on the user's most
recent login).
module−path
The module−path tells PAM which module to use and (optionally) where to find it. Most
configurations only contain the module's name, as is the case in our login configuration file. When
this is the case, PAM looks for the modules in the default PAM module directory, normally
/usr/lib/security. However, if your linux distribution conforms to the Filesystem Hierarchy
Standard (FHS), PAM modules can be found in /lib/security.
module−arguments
The module−arguments are arguments to be passed to the module. Each module has its own
arguments. For example, in our login configuration, the "nulok" ("null ok", argument being passed to
pam_unix.so module, indicating the a blank ("null") password is acceptable ("ok").
3.3.4. pam.conf configuration
If your PAM configuration is stored in /etc/pam.conf rather than /etc/pam.d/, PAM configuration
lines are a bit different. Rather than each service having its own configuration file, all configurations are
stored in /etc/pam.conf with the service name as the first token in a configuration line. For example, the
following line in /etc/pam.d/login:
auth required pam_unix.so nulok
would become the following line in /etc/pam.conf:
login auth required pam_unix.so nulok
Except for this minor difference, all the rest of the configuration PAM syntax applies.
3.4. Getting more information
For more information on configuring PAM and complete PAM module reference, consult the Linux−PAM
System Administrator's Guide. This guide serves as a thorough and up−to−date reference on PAM
configuration.
User Authentication HOWTO
3. PAM (Pluggable Authentication Modules) 8
4. Securing User Authentication
Many linux distributions ship with user authentication that is not adequately secure. This section discusses
some of the ways you make user authentication secure on your system. While doing these things will make
your system more secure, do not be so naive as to think they make you invulnerable.
4.1. A strong /etc/pam.d/other
All of the files in /etc/pam.d/ contain the configuration for a particular service. The notable exception to
this rule is the /etc/pam.d/other file. This file contains the configuration for any services which do not
have their own configuration file. For example, if the (imaginary) xyz service attempted authentication, PAM
would look for a /etc/pam.d/xyz file. Not finding one, authentication for xyz would be determined by
the /etc/pam.d/other file. Since /etc/pam.d/other is the configuration to which PAM services
fallback, it is important that it is secure. We will discuss two secure configurations of /etc/pam.d/other,
one which is quite nearly paranoid and one which is gentler.
4.1.1. A paranoid configuration
A paranoid configuration of /etc/pam.d/other is as follows:
auth required pam_deny.so
auth required pam_warn.so
account required pam_deny.so
account required pam_warn.so
password required pam_deny.so
password required pam_warn.so
session required pam_deny.so
session required pam_warn.so
With this configuration, whenever an unknown service attempts to access any of the four configuration types,
PAM denies authentication (via the pam_deny.so module) and then logs a syslog warning (via the
pam_warn.so module). Short of a bug in PAM, this configuration is brutally secure. The only problem with
that brutality is it may cause problems if your accidentally delete the configuration of another service. If your
/etc/pam.d/login was mistakenly deleted, no one would be able to login!
4.1.2. A kinder configuration
Here's configuration that isn't quite so mean:
auth required pam_unix.so
auth required pam_warn.so
account required pam_unix.so
account required pam_warn.so
password required pam_deny.so
password required pam_warn.so
session required pam_unix.so
session required pam_warn.so
This configuration will allow an unknown service to authenticate (via the pam_unix.so module), although it
4. Securing User Authentication 9
will not allow it to change the user's password. Although it allows authentication by unknown services, it logs
a syslog warning whenever such a service attempts authentication.
4.1.3. Choosing a /etc/pam.d/other
I would strongly reccomend that you implement the first /etc/pam.d/other configuration unless you
have a very good reason not to. It always a good idea to be 'secure by default'. If you ever do need to grant a
new service authentication privileges, you can simply create a PAM configuration file for that service.
4.2. Disabling logins for user with null passwords
On most linux systems, there a number of "dummy" user accounts, used to assign privileges to certain system
services like ftp, webservers, and mail gateways. Having these accounts allows your system to be more
secure, because if these services are compromised, an attacker will only gain the limited privileges available
to the dummy account, rather than the full privileges of a service running as root. However, allowing these
dummy account login privileges is a security risk, as they usually have blank (null) passwords. The
configuration option that enables null passwords is the "nullok" module−argument. You'll want to remove this
argument from any modules of 'auth' type for services that allow login. This is usually the login service, but it
may also include services like rlogin and ssh. Hence, the following line in /etc/pam.d/login:
auth required pam_unix.so nullok
should be changed to:
auth required pam_unix.so
4.3. Disable unused services
Looking at the files in /etc/pam.d/, you'll probably see configuration files for a number of programs you
don't use and maybe even a few you've never heard of. Although allowing authentication to these services
probably won't open any huge security holes, you're better off denying them authentication. The best way to
disable PAM authentication for these programs is to rename these files. Not finding the file named after the
service requesting authentication, PAM will fallback to the (hopefully) very secure /etc/pam.d/other. If
you later find that you need one of these programs, you can simply rename the file to its original name and
everything will work as it was intended.
4.4. Password−cracking tools
While password−cracking tools can be used by attackers to compromise a system, they can also be used by
system administrators as proactive tool to ensure the strength of passwords on their system. The two most
commonly used password−cracking tools are "crack" and "John the Ripper". Crack is probably included in
your favorite distribution. John the Ripper can be obtained from
http://www.false.com/security/john/index.html. Run the tools against your password database and you'll
probably be surprised with what they come up with.
Additionally, there is a PAM module which utilizes the crack library to check the strength of a users password
User Authentication HOWTO
4. Securing User Authentication 10
whenever it changed. When this module is installed, the user can only change their password to one which
meets the minimum password strength.
4.5. Shadow and MD5 passwords
As was discussed in the first section of this document, Shadow and MD5 passwords can make your system
more secure. During the installation procedure, most modern distributions will ask whether you want to install
MD5 and/or Shadow passwords. Unless you have a good reason not to, you should enable these. The process
of converting from non−shadowed/non−MD5 passwords is a complicated process, and is beyond the scope of
this document. The Shadow Password HOWTO is outdated, but it might be of some help.
User Authentication HOWTO
4. Securing User Authentication 11
5. Tying it all together
In this section, I'll give a simple example which ought to help tie together what's in the previous section.
5.1. Apache + mod_auth_pam
As our example, we'll install and configure mod_auth_pam, an Apache module that allows you to authenticate
users of your webserver using PAM. For the purpose of this example, I'll assume you have apache installed. If
it's not installed already you should be able find installation packages from your distributor.
5.2. Our example
Our goal will be to configure a restricted area of our webserver, a family/ directory, to authenticate users
via PAM. This directory contains private family information, and should only be accessible to members of the
user group family.
5.3. Installing mod_auth_pam
First, you'll want to download mod_auth_pam from http://blank.pages.de/pam/mod_auth_pam/. The following
commands will compile mod_auth_pam (you must be logged in as root):
~# tar xzf mod_auth_pam.tar.gz
~# cd mod_auth_pam−1.0a
~/mod_auth_pam−1.0a# make
~/mod_auth_pam−1.0a# make install
If you have any trouble installing the mod_auth_pam module, make sure you've installed your distribution's
apache−dev package. After you've installed mod_auth_pam, you'll need to restart apache. Apache can usually
by restarted by typing the following command (again, you must be root):
~# /etc/init.d/apache restart
5.4. Configuring PAM
The PAM configuration for Apache is stored in /etc/pam.d/httpd. The default configuration (which
was installed when you installed mod_auth_pam) is secure, but it uses a module (pam_pwdb.so) which may
not be available on many systems. (Besides, configuring it from scratch will be fun!) So delete the
/etc/pam.d/httpd file, and start with a fresh one.
5.4.1. Deciding how to configure PAM
If we're going to configure how PAM deals with Apache's authentication requests, we need to figure out
exactly what we need PAM to check for. First, we want PAM to make sure the user's password matches their
password in the standard unix password database. This sounds like the 'auth' type and the pam_unix.so
module. We'll want the module's control type to be set to 'required', so authentication will fail without a
correct password. Here's what the first line of our /etc/pam.d/httpd looks like:
5. Tying it all together 12
auth required pam_unix.so
Secondly, we must make sure that the users account is valid (i.e. their password has not expired or any such
nastiness). This is the 'account' type and is also provided by the pam_unix.so module. Again, we'll set this
module's control type to 'required'. After adding this line, our /etc/pam.d/httpd configuration looks like
this:
auth required pam_unix.so
account required pam_unix.so
It's not terribly sophisticated, but it does the job. It ought to be a good start for learning how to configure PAM
services.
5.5. Configuring Apache
Now that PAM is configured to authenticate apache's requests, we'll configure apache to properly utilize PAM
authentication to restrict access to the family/ directory. To do so, add the following lines to your
httpd.conf (usually stored in /etc/apache/ or /etc/httpd):

AuthPAM_Enabled on
AllowOverride None
AuthName "Family Secrets"
AuthType "basic"
require group family

You may need to replace /var/www/ with the default location of web documents, which is often
/home/httpd/. Wherever that is, you'll need to create the family directory.
Before we test our setup, I'll take a moment to explain the Apache configuration you just entered. The
directive is used to encapsulate configuration data for this directory. Inside this directive, we've
enabled PAM authentication ("AuthPAM_enabled on"), turned off any overriding of this configuration
("AllowOverride none"), named this authentication zone "Family Secrets" ("AuthName "Family Secrets""),
set the http authentication (not the PAM authentication) type to the default ("AuthType "basic""), and required
the user group family ("require group family").
5.6. Testing our setup
Now that we've got everything setup up properly, it's time to revel in our success. Fire up your favorite web
browser and head over to http://your−domain/family/ (replacing your−domain with, well, your domain). You
are now an uber−authenticator!
User Authentication HOWTO
5. Tying it all together 13
6. Resources
There are a number of resources, both online and offline, where you can more information about user
authentication. If you know of any resources that ought to be added to this list, drop me a line at

6.1. PAM
· Linux−PAM System Administrator's Guide
· Linux−PAM Module Writer's Manual
· Linux−PAM Application Developer's Manual
6.2. General Security
· linuxsecurity.com
· securitywatch.com
· Security HOWTO
· Packetstorm
6.3. Offline Documentation
A lot of information can be gathered from your system's manual pages. The following are some manpages
relating to user authentication. The number in parentheses refers to the manpage section. To view the
passwd(5) manpage, you would enter man 5 passwd.
· passwd(5)
· crypt(3)
· pam.d(5)
· group(5)
· shadow(5)
6. Resources 14
7. Conclusion
I hope you found this HOWTO helpful. If you have any questions, comments, or suggestions, I'd love to hear
from you. You can email me at .
7. Conclusion 15

Linux Apache SSL PHP/FI frontpage mini−HOWTO

Table of Contents
Linux Apache SSL PHP/FI frontpage mini−HOWTO....................................................................................1
Marcus Faure, marcus@faure.de............................................................................................................1
1. Introduction.........................................................................................................................................1
2. Component installation.......................................................................................................................1
3. Putting it all together...........................................................................................................................1
1. Introduction.........................................................................................................................................1
1.1 Description of the components..........................................................................................................1
1.2 Working configurations....................................................................................................................2
1.3 History..............................................................................................................................................2
2. Component installation.......................................................................................................................3
2.1 Preparations.......................................................................................................................................3
2.2 Adding PHP......................................................................................................................................3
2.3 Adding SSL.......................................................................................................................................4
2.4 Adding frontpage..............................................................................................................................4
3. Putting it all together...........................................................................................................................4
3.1 Apache modules to try.......................................................................................................................4
3.2 Giving CGI's more security...............................................................................................................5
3.3 Compiling and installing the server daemon.....................................................................................5
3.4 Adding frontpage support to a web....................................................................................................6
3.5 Starting the daemon..........................................................................................................................7
3.6 Some considerations left....................................................................................................................7
3.7 Known bugs......................................................................................................................................7
3.8 The final word...................................................................................................................................7
Linux Apache SSL PHP/FI frontpage mini−HOWTO
i
Linux Apache SSL PHP/FI frontpage mini−HOWTO
Marcus Faure, marcus@faure.de
v1.1, July 1998
This document is about building a multipurpose webserver that will support dynamic web content via the
PHP/FI scripting language, secure transmission of data based on Netscape's SSL, secure execution of
CGI's and M$ Frontpage Server Extensions
1. Introduction
· 1.1 Description of the components
· 1.2 Working configurations
· 1.3 History
2. Component installation
· 2.1 Preparations
· 2.2 Adding PHP
· 2.3 Adding SSL
· 2.4 Adding frontpage
3. Putting it all together
· 3.1 Apache modules to try
· 3.2 Giving CGI's more security
· 3.3 Compiling and installing the server daemon
· 3.4 Adding frontpage support to a web
· 3.5 Starting the daemon
· 3.6 Some considerations left
· 3.7 Known bugs
· 3.8 The final word
1. Introduction
Before you start reading: I am not a native speaker, so there are probably spelling/grammatical errors in this
document. Feel encouraged to inform me of mistakes.
1.1 Description of the components
The webserver you hopefully will get after having read this howto is composed of several parts, the original
apache sources with some (well, many) patches and some external executables. I recommend using the
Linux Apache SSL PHP/FI frontpage mini−HOWTO 1
software versions I tried, they will probably compile without greater problems and result in a fairly stable
daemon. If you are courageous, you can try to compile all the latest−stuff−with−tons−of−new−features, but
don't blame me if something fails ;−). However, you may report other working configurations to be included
in future versions of this document. All of the steps were tested on a linux 2.0.35 box, so the howto is
somewhat linux−specific, but you should be able to use it for other unixes as well.
You do not necesserily have to compile in all components. I tried to structure this howto so that you can skip
the parts you are not interested in.
The document is neither a user manual to Apache, SSL, PHP/FI nor frontpage. Its prime intention is to save
webservice providers some headaches when installing their server and to do my little contribution to the linux
community.
PHP is a scripting language that supports dynamic HTML pages. It is a bit like Apache's SSI, but by far more
complex and has database modules for many popular dbs. The GD libraries are needed by PHP.
SSL is an implementation of Netscape's Secure Socket Layer that allow secure connections over insecure
networks, e.g. to transmit credit card numbers to web based forms.
frontpage is a wysiwyg web authoring tool that makes use of some server−specific extensions called
webbots. Some people think frontpage is cool because you can create feedback forms and discussion webs
without having to know a bit about html or cgi. It even protects the designer from uploading his/her site via
ftp by using a builtin publisher. If you wish to support frontpage but do not like to setup a windows server,
the apache server extensions are your choice.
1.2 Working configurations
Though this document has been downloaded some 100 times since I published it, I received only little
feedback. In particular, noone told me of other working combinations. Combinations that work for me are:
· Linux 2.0.31, Apache 1.2.4, PHP 2.0.0, SSL 0.8.0, fp 98 3.0.3 (*)
· Linux 2.0.33, Apache 1.2.5, PHP 2.0.1, SSL 0.8.0, fp 98 3.0.3 (*)
· Linux 2.0.35, Apache 1.2.6, PHP 3, SSL 0.8.0, fp 98 3.0.4
(*) version 3.0.3 is not recommended
1.3 History
v0.0/Apr 98: Preview version
v1.0/Jun 98: Now using Apache 1.2.6, updated fp section, minor corrections
v1.1/Jul 98: Sgmlized and restructered version
You can find the latest version of this document at http://www.faure.de
Linux Apache SSL PHP/FI frontpage mini−HOWTO
1.2 Working configurations 2
2. Component installation
2.1 Preparations
You will need:
· Apache 1.2.6 http://www.apache.org/dist/apache_1_2_6.tar.gz
· PHP/FI Extensions http://php.iquest.net/files/download.phtml?/files/php−2.01.tar.gz
· GD Library http://siva.cshl.org/gd/gd.html
· SSL 0.8.0 ftp://ftp.ox.ac.uk/pub/crypto/SSL/SSLeay−0.8.0.tar.gz
· SSL patch for Apache 1.2.6 ftp://ftp.ox.ac.uk/pub/crypto/SSL/apache_1.2.6+ssl_1.17.tar.gz
· frontpage 98 server extensions and install script http://www.rtr.com/fpsupport/download.htm
Get the sources you want. Untar apche, php, gd and ssl to /usr/src. Untar the SSL patch to
/usr/src/apache_1.2.6.
2.2 Adding PHP
cd to /usr/src/gd1.2 and type make. This will build the GD library libgd.a, that should be copied to
/usr/lib. Now cd to php−2.0.1 and run ./install.
The relevant questions are:
Would you like to compile PHP/FI as an Apache module? [yN] y
Are you compiling for an Apache 1.1 or later server? [Yn] y
Are you using Apache−Stronghold? [yN] y
Does your Apache server support ELF dynamic loading? [yN] y
Apache include directory (which has httpd.h)? [/usr/local/include/apache] /usr/src/apache_1.2.6/src
Would you like to build an ELF shared library? [yN] y
Additional directories to search for .h files []: /usr/src/gd1.2
Would you like the bundled regex library? [yN] n
Like the frontpage extensions, phtml includes a security problem because it is run under the uid of the
webserver. Be sure to turn on safe mode in src/php.h and restrict the search path to a save value. There are
some other options in php.h you may want to edit. If you are very concerned about security, compile php as a
cgi. However, this will be a performance loss and not as smart as the module version.
Type make to build all files. When the compilation is done, copy mod_php.* and libphp.a to
/usr/src/apache_1.2.6/src Add a line
Module php_module mod_php.o
to the end of /usr/src/apache_1.2.6/src/Configuration, add
−lphp −lm −lgdbm −lgd
to the EXTRA_LIBS in the same file,
application/x−httpd−php phtml
to Apache's mime.types and
Linux Apache SSL PHP/FI frontpage mini−HOWTO
2. Component installation 3
AddType application/x−httpd−php .phtml
to Apache's srm.conf.
You may also want to add index.phtml to DirectoryIndex in that file so that a file index.phtml is
automatically loaded when its directory is requested.
2.3 Adding SSL
cd /usr/src/SSL−0.8.0; ./Configure linux−elf; make; make rehash This will
create libraries needed by apache. You may issue make test to verify the compilation. You have to apply
a patch to apache. It is important that you apply it before the frontpage patch, otherwise frontpage will not
work. cd to /usr/src/apache_1.2.6/src and issue patch < /usr/src/apache_1.2.6/SSLpatch. Set SSL_BASE=/usr/src/SSLeay−0.8.0 in Configuration. Make sure that Module proxy_module is disabled otherwise Apache won't compile. If you are in need of a proxy, go for Squid http://squid.nlanr.net/ Now make certificate to generate SSLconf/conf/httpsd.pem. 2.4 Adding frontpage Rename the fp30.linux.tar.Z file to fp30.linux.tar.gz, otherwise the install script will not find it. Run ./fp_install to copy the extension files to /usr/local/frontpage. zcat can usually be invoked as /usr/bin/zcat. You now have to apply the FP patch. cd to /usr/src/apache_1.2.6/src and type patch < /usr/src/frontpage/version3.0/apache−fp/fp−patch−apache_1.2.5 This will create the mod_frontpage.* files and do some modifications to Configuration etc. The 1.2.5 patch will work with both apache 1.2.5 and 1.2.6. Skip the part about installing webs, you can do that later 3. Putting it all together 3.1 Apache modules to try The modules I use besides SSL, PHP and frontpage are: Module env_module mod_env.o Module config_log_module mod_log_config.o Module mime_module mod_mime.o Module negotiation_module mod_negotiation.o Module dir_module mod_dir.o Module cgi_module mod_cgi.o Module asis_module mod_asis.o Module imap_module mod_imap.o Module action_module mod_actions.o Module alias_module mod_alias.o Module rewrite_module mod_rewrite.o Module access_module mod_access.o Module auth_module mod_auth.o Module anon_auth_module mod_auth_anon.o Linux Apache SSL PHP/FI frontpage mini−HOWTO 2.3 Adding SSL 4 Module digest_module mod_digest.o Module expires_module mod_expires.o Module headers_module mod_headers.o Module browser_module mod_browser.o 3.2 Giving CGI's more security If you are an ISP (you probably are when you read this) you will want to improve security. The suexec utility allows you to do so; it will execute cgi's under the UID of the webowner instead of executing it under the webservers UID. Go to /usr/src/apache_1.2.6/support and make suexec. chmod 4711 suxec and copy it to the location specified in ../src/httpd.h which is /usr/local/etc/httpd/sbin/suexec by default. If the path seems a little cryptic to you − it did to me − edit httpd.h and set the path to a more comfortable value. 3.3 Compiling and installing the server daemon Enter /usr/src/apache_1.2.6/src and edit Configuration to set all the Modules you want to include in your Apache daemon. When done, run ./Configure and make. This is the last (and most complicated) compilation step, so cross your fingers. If it succeeds, cp httpsd to /usr/sbin. The daemon is somewhat big, consider this when assembling your webserver. Create the directory /var/httpd with subdirectories cgi−bin, conf, htdocs, icons, virt1, virt2 and logs. In /usr/src/apache_1.2.6/conf edit access.conf−dist, mime.types and srm.conf−dist to suit your needs and copy them to var/httpd/conf/access.conf, srm.conf and mime.types. Copy the httpsd.pem you created with make certificate to /var/httpd/conf. Use the following httpd.conf: ServerType standalone Port 80 Listen 80 Listen 443 User wwwrun Group wwwrun ServerAdmin webmaster@yourhost.com ServerRoot /var/httpd ErrorLog logs/error_log TransferLog logs/access_log PidFile logs/httpd.pid ServerName www.yourhost.com MinSpareServers 3 MaxSpareServers 20 StartServers 3 SSLCACertificatePath /var/httpd/conf SSLCACertificateFile /var/httpd/conf/httpsd.pem SSLCertificateFile /var/httpd/conf/httpsd.pem SSLLogFile /var/httpd/logs/ssl.log
SSLDisable
ServerAdmin webmaster@virt1.com
DocumentRoot /var/httpd/virt1
ScriptAlias /cgi−bin/ /var/httpd/virt1/cgi−bin/
ServerName www.virt1.com
ErrorLog logs/virt1−error.log
TransferLog logs/virt1−access.log
User virt1admin
Linux Apache SSL PHP/FI frontpage mini−HOWTO
3.2 Giving CGI's more security 5
Group users


ServerAdmin webmaster@virt1.com
DocumentRoot /var/httpd/virt1
ScriptAlias /cgi−bin/ /var/httpd/virt1/cgi−bin/
ServerName www.virt1.com
ErrorLog logs/virt1−ssl−error.log
TransferLog logs/virt1−ssl−access.log
User virt1admin
Group users
SSLCACertificatePath /var/httpd/conf
SSLCACertificateFile /var/httpd/conf/httpsd.pem
SSLCertificateFile /var/httpd/conf/httpsd.pem
SSLLogFile /var/httpd/logs/virt1−ssl.log
SSLVerifyClient 0
SSLFakeBasicAuth


SSLDisable
ServerAdmin webmaster@virt2.com
DocumentRoot /var/httpd/virt2
ScriptAlias /cgi−bin/ /var/httpd/virt2/cgi−bin/
ServerName www.virt2.com
ErrorLog logs/virt2−error.log
TransferLog logs/virt2−access.log

Depending on the modules compiled in, not all directives may be available. You can retrieve a list of
available directives with httpsd −h.
3.4 Adding frontpage support to a web
Enter /usr/local/frontpage/version3.0/bin and load ./fpsrvadm. Choose install and
apache−fp. The next questions should be answered the following way:
Enter server config filename: /var/httpd/conf/httpd.conf
Enter host name for multi−hosting []: www.virt2.com
Starting install, port: www.virt2.com:80, web: ""
Enter user's name []: virt2admin
Enter user's password:
Confirm password:
Creating root web
Recalculate links for root web
Install completed.
The user name must be the unix login of the webowner. The password does not necessarily have to match the
system password. You have to manually add sendmailcommand:/usr/sbin/sendmail %r to
/usr/local/frontpage/www.virt2.com:80.conf, otherwise your users will not be able to send
web−generated eMails. kill −HUP your httpsd to make fp reread its config. You can now access
www.virt2.com with your frontpage client.
Under some circumstances fpsrvadm complaints that a root web has to be installed first. This is pretty
useless, but you should do so to silence fpsrvadm.
Linux Apache SSL PHP/FI frontpage mini−HOWTO
3.4 Adding frontpage support to a web 6
3.5 Starting the daemon
Start Apache with httpsd −f /var/httpd/conf/httpd.conf. You can now access
www.virt1.com both through http and https which is pretty cool. Of course you have to pay for a real
certificate if you want to offer webwide SSL or users might laugh at you.
Copy one of the demo files from the php examples directory to virt1 to test phtml.
3.6 Some considerations left
Do not use frontpage 97 extensions. They do not work, at least under Linux. When installing specific
versions of the c++ libraries, they appear to work but your logs will soon fill with premature end of
script headers and your mailbox will fill with complaints. Do not use frontpage 98 extensions before
version 3.0.2.1330. Do not be confused, version numbers are somewhat inheterogenous. When telnetting to
port 80, typing "get / http/1.0" and hitting return twice, you get a version number 3.0.4 for frontpage.
You can find out the more specific version number by executing
/usr/local/frontpage/currentversion/exes/_vti_bin/shtml.exe −version. Older
versions have a nasty bug that requires httpd.conf to be writable by the gid of the webserver. This should
make you scream if you are at all concerned about security. Versions since 3.0.2.1330 are more usable.
3.7 Known bugs
When touching Recalculate Links in the frontpage client, the server starts a process that consumes
99% cpu cycles and some 10 mb of memory. But even for medium−sized webs and fast machines, the client
sometimes recieves a timeout message, though the calculation will be finished correctly. Inform frontpage
users to be patient and not to hit Recalculate Links several times. Inform yourself to equip the server
with at least 64MB.
Please note that at the time of writing both SSL and frontpage work, but not at the same time, that means you
can neither publish your web using ssl nor make use of the webbots through https. You can publish your web
on port 80 and access it encrypted on port 443, but your counters etc. will be broken. I consider this a bug.
This problem shall be fixed in SSL 0.9.0.
3.8 The final word
For those who think the title of this howto is nearly as long as the document: Did you ever listened to Meat
Loaf?
O.K. readers, you're done for today. Feel free to send me your feedback, eternal gratitude, flowers, ecash,
cars, oil sources etc.
Linux Apache SSL PHP/FI frontpage mini−HOWTO
3.5 Starting the daemon 7