[Qvcs-CVS] qvcs-guide qvcs-9.ks,1.2,1.3 qvcs-guide.tex,1.1,1.2 qvcs-guide.xml,1.1,1.2
Brought to you by:
graf25
Menu
▾
▴
[Qvcs-CVS] qvcs-guide qvcs-9.ks,1.2,1.3 qvcs-guide.tex,1.1,1.2 qvcs-guide.xml,1.1,1.2
|
From: <gr...@us...> - 2003-06-25 22:41:37
|
Update of /cvsroot/qvcs-guide/qvcs-guide
In directory sc8-pr-cvs1:/tmp/cvs-serv2547
Modified Files:
qvcs-9.ks qvcs-guide.tex qvcs-guide.xml
Log Message:
Day's work.
Index: qvcs-9.ks
===================================================================
RCS file: /cvsroot/qvcs-guide/qvcs-guide/qvcs-9.ks,v
retrieving revision 1.2
retrieving revision 1.3
diff -C2 -d -r1.2 -r1.3
*** qvcs-9.ks 25 Jun 2003 14:13:40 -0000 1.2
--- qvcs-9.ks 25 Jun 2003 22:41:33 -0000 1.3
***************
*** 19,23 ****
authconfig --enableshadow --enablemd5
bootloader --location=mbr
- #reboot
%packages
--- 19,22 ----
Index: qvcs-guide.tex
===================================================================
RCS file: /cvsroot/qvcs-guide/qvcs-guide/qvcs-guide.tex,v
retrieving revision 1.1
retrieving revision 1.2
diff -C2 -d -r1.1 -r1.2
*** qvcs-guide.tex 25 Jun 2003 03:57:21 -0000 1.1
--- qvcs-guide.tex 25 Jun 2003 22:41:33 -0000 1.2
***************
*** 1,1192 ****
! \documentclass{article}
! \usepackage{rcs}
! \usepackage{url}
! \RCS $Date$
! \RCS $Revision$
! \RCS $Author$
!
! \usepackage{fancyheadings}
! \pagestyle{fancy}
! \cfoot{\small{Revision \RCSRevision{}, as of \RCSDate{} by \RCSAuthor{}}}
[...6207 lines suppressed...]
! {323}}\Par%
! {\def\fSize%
! {9\p@}\def\LineSpacing%
! {9.9\p@}\def\LineSpacingFactor%
! {0}\def\StartIndent%
! {48\p@}\def\StartIndentFactor%
! {0}\def\fFamName{Courier-New}\def\fWeight%
! {medium}\def\fPosture%
! {upright}\def\FirstLineStartIndent%
! {0\p@}\def\FirstLineStartIndentFactor%
! {0}\def\Lines%
! {asis}\def\InputWhitespaceTreatment%
! {preserve}}
! [auth]
! ~~~~method~=~user
! ~~~~force\char95{}https~=~no
! ~~~~elvis~=~albus@hogwarts.jk
! ~~~~domain~=~hogwarts.jk
! ~~~~~~~~\endPar{}\endNode{}\endPar{}\endSeq{}\endDisplayGroup{}\endNode{}\endSeq{}\endDisplayGroup{}\endNode{}\endSeq{}\endSpS{}\endNode{}\endSeq{}\endNode{}\endNode{}\endSeq{}\endFOT{}
\ No newline at end of file
Index: qvcs-guide.xml
===================================================================
RCS file: /cvsroot/qvcs-guide/qvcs-guide/qvcs-guide.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -C2 -d -r1.1 -r1.2
*** qvcs-guide.xml 25 Jun 2003 03:57:21 -0000 1.1
--- qvcs-guide.xml 25 Jun 2003 22:41:33 -0000 1.2
***************
*** 6,9 ****
--- 6,13 ----
<!ENTITY rhl "<trademark>Red Hat</trademark> <productname>Linux</productname>">
<!ENTITY qvcs "<acronym>QVCS</acronym>">
+ <!ENTITY ver "9">
+ <!ENTITY rhbase "http://redhat.linux.duke.edu/pub/redhat/linux/9/en/os/i386">
+ <!ENTITY qvcsbase "http://mirror.mricon.com/qvcs-guide">
+ <!ENTITY prompt "<prompt>[root@mail root]#</prompt>">
]>
***************
*** 47,51 ****
&qvcs; tie-in as the best small to mid-class server
solution. This document is written for &rhl; systems running
! OS version 9.
</para>
</abstract>
--- 51,55 ----
&qvcs; tie-in as the best small to mid-class server
solution. This document is written for &rhl; systems running
! &ver;.
</para>
</abstract>
***************
*** 86,92 ****
This guide will help you configure and set up a similar system.
</para>
- </chapter>
- <chapter id="software">
- <title>The Software</title>
<sect1>
<title>OSes, Packages, and Disclaimers</title>
--- 90,93 ----
***************
*** 96,100 ****
every distribution. This guide is aimed at &rhl;, and is
based on a set of binary packages provided with it. If you are
! running something other than &rhl; version 9, or like building
stuff from source, please consult the following document:
<ulink url="http://megaz.arbuz.com/?p=qmail_howto">
--- 97,101 ----
every distribution. This guide is aimed at &rhl;, and is
based on a set of binary packages provided with it. If you are
! running something other than &rhl; &ver;, or like building
stuff from source, please consult the following document:
<ulink url="http://megaz.arbuz.com/?p=qmail_howto">
***************
*** 115,350 ****
</important>
</sect1>
<sect1>
! <title>From Zero to 60 in 30 minutes</title>
<para>
! This section will walk you through a generic &rhl;
! installation process. The system we are going to install is
! going to aim <emphasis>exclusively</emphasis> at being a mail
! server running nothing but virtual servers and webmail
! interface (so-called "pop-toaster"). If you are
! planning to use your system for any other services, you can
! still glance through this installation part for hints and
! caveats, but your install will differ from the one outlined
! below.
</para>
<sect2>
! <title>Considering the hardware</title>
<para>
! This setup is aimed at low- to middle-low-end installations,
! hence we will be VERY relaxed about our hardware
! requirements. Nevertheless, there are several important
! things to consider. First of all, we need to make sure that
! our server is capable of handling peak loads, such as happen
! at times when a new outlook virus hits the Internet (you
! HAVE banned outlook from your company's systems, right?
! <emphasis>RIGHT?</emphasis>). Another thing to consider is
! how many clients you are planning to support, together with
! how much maximum space you are going to allow them to have.
</para>
<para>
! Overall, we are looking at three different variables --
! memory amount, processor speed, and hard drive space. Let's
! consider a setup with <emphasis>500</emphasis> clients max
! and look at all three of these variables.
</para>
! <sect3>
! <title>HDD space</title>
! <para>
! A sensible amount of mail quota to allow per client would
! be about 50Mb, so the amount of hard drive space we will
! require just for our 500 clients' e-mails would be around
! 25Gb. That's not all, though, as we will need to consider
! the amount of hard drive space that we will require for
! the mail queue.
! </para>
! <para>
! Let's imagine that we've been hit with a virus that mails
! itself to a hundred people and all 500 our clients got
! infected because we've stupidly allowed Outlook on our
! network (gee, did I come across as biased? :)). If the
! virus is around 100Kb in size, that means that the total
! amount of traffic a single client will generate will be
! around 10Mb. Multiply that by 500, and we arrive at a
! staggering 5Gb of traffic just to handle that virus. Since
! qmail will spend a good deal of time making connections,
! we will want to make sure that there is plenty of space to
! queue all of these requests. What this means is that we
! will have to allow around 5-7Gb of space for queuing,
! which brings us to 30-35Gb of total space for the mail
! subsystem.
! </para>
<para>
! The OS itself will actually require very little space --
! no more than 500Mb for everything we will need, including
! virtual web-servers preferences and other miscellaneous
! data.
</para>
<para>
! After we allow about one more gigabyte for system swap
! space, we arrive at 35-40Gb overall HDD space needed for
! our installation with 500 clients. Re-calculate the
! requirements for your number of clients using the
! following formula:
</para>
! <segmentedlist>
! <title>Space considerations</title>
! <segtitle>User space</segtitle>
! <segtitle>Qmail queue</segtitle>
! <segtitle>System and swap</segtitle>
! <seglistitem>
! <seg>N*50Mb</seg>
! <seg>N*10Mb</seg>
! <seg>1.5GB</seg>
! </seglistitem>
! </segmentedlist>
<para>
! Whether you decide to choose SCSI or IDE is up to you, but
! you should consider that most common HDD activity will be
! accessing and moving small files, something that high-RPM
! SCSI drives do best. Depending on how redundant you want
! to be (which generally depends on how pissed off your
! clients can get, times the amount of downtime), you might
! consider creating a RAID array to mirror all your data.
</para>
<para>
! If you do decide to go with <acronym>RAID</acronym>, then
! my advice would be to get 1 small IDE drive for the
! system, and 3 SCSI drives for a RAID-1 array (1 active, 1
! mirror, and 1 spare). Granted, this setup will be more
! expensive, but believe me, you will sleep MUCH better at
! night.
</para>
! </sect3>
! <sect3>
! <title>RAM requirements</title>
<para>
! The amount of RAM we will require depends on the number of
! simultaneous connections we are going to have to our
! server. This largely depends on the environment you are
! setting this up for.
</para>
<para>
! If you are creating this setup for your company, then it's
! a good possibility that a good chunk of these 500 will be
! accessing your system simultaneously, especially around
! 9am in the morning when people first arrive at work and
! check their e-mail. If, however, you are an ISP and your
! clients are mostly home-users, then the amount of
! simultaneous connections your server is likely to
! experience would be MUCH lower, since people will tend to
! check their e-mail at various times during the day.
</para>
<para>
! Let's approximate -- if you are setting up a server for
! your company, the likely peak usage would be around 90% of
! all your clients. The amount of memory each request will
! consume depends largely on what kind of connection it is
! -- <application>smtp</application> and
! <application>imap</application> require very small amounts
! of memory for each connection, within a few hundred
! kilobytes each. Webmail requests, however, are very
! memory-hungry and will likely gobble up a hefty chunk of
! RAM -- around 5Mb per each request. However, the good
! thing about webmail is that each request lasts only a few
! seconds, so even if 200 people decide to connect to your
! server at around the same time, it's unlikely that there
! will be any more than 50 http processes running
! simultaneously.
</para>
<para>
! But let's be pessimistic and allow for freaky
! coincidences. Let's imagine that all of your 500 clients
! decided to connect to your server at roughly the same
! time, and our apache daemon spawned 150 processes,
! consuming 5Mb each. That brings the memory usage up to
! 750Mb. The system itself consumes about 50Mb of your
! memory, so at peak loads we will be consuming around 800Mb
! of RAM. If you want your server to be snappy at all times,
! you will need to have at least that much memory in your
! box, however, if you decide that such coincidence is not
! very likely and you'd rather save on extra memory, you can
! settle on 512Mb and let the swapping process catch the
! rest.
</para>
<para>
! If, however, you are an ISP with most clients being
! home-users, you are not likely to experience more than
! 10% of your clients trying to connect at the same
! time. The memory requirement would be more relaxed, and it
! is likely that 256Mb of memory will suffice for
! you. Nevertheless, it's always better to have more memory,
! than less, so you are still encouraged to use 512Mb for
! 500 clients.
</para>
<para>
! In general, to calculate how much memory you will need use the
! following formulas:
</para>
! <segmentedlist>
! <title>RAM considerations</title>
! <segtitle>For a company</segtitle>
! <segtitle>For an ISP with home-users</segtitle>
! <seglistitem>
! <seg>N/3*5+50</seg>
! <seg>N/10*5+50</seg>
! </seglistitem>
! </segmentedlist>
<para>
! For 500 users these values will be 880Mb and 300Mb
! respectively. If you are going to rely on swapping, you
! can bring those values down to 512Mb and 256Mb.
</para>
! </sect3>
! <sect3>
! <title>CPU requirements</title>
<para>
! None of the processes are very CPU-intensive, actually,
! and you are not very likely to bottleneck at the processor
! level. The only exception would be when someone tries to
! sort a mailbox with thousands of e-mails in it, but I
! believe that is punishable by law in most countries
! anyway. The best way to avoid this is to set up message
! count quotas. Overall, I would recommend using something
! like a 1.5 GHz and above system for our 500 users, so our
! calculation formula would look something like so:
</para>
! <segmentedlist>
! <title>CPU Considerations</title>
! <segtitle>Lower end</segtitle>
! <segtitle>Higher end</segtitle>
! <seglistitem>
! <seg>N*1.5+800</seg>
! <seg>N*2+1000</seg>
! </seglistitem>
! </segmentedlist>
<para>
! I'm using the +800 method simply because I think that if
! you decide to use something less than a 800Mhz system, you
! are likely to be plagued by various problems related to
! aging hardware.
</para>
! </sect3>
! <sect3>
! <title>Other stuff</title>
<para>
! I am not covering networking environment and bandwidth,
! since you will likely have to stick with what you already
! have anyway. A common 100Base-T network card will suffice
! in terms of a NIC. However, you should consider
! implementing some sort of a backup solution to make sure
! that you don't lose your job or go out of business when
! your server catches on fire and you find it reduced to
! cinders when you come to work one lovely Monday morning. I
! have only good words to say about Amanda <ulink
! url="http://www.amanda.org/">http://www.amanda.org/</ulink>,
! or you may choose some of the many alternatives.
</para>
<para>
! Refer to the section on "What to back up"
! further in the document for the list of directories to
! include in your backup run.
</para>
! </sect3>
! </sect2>
</sect1>
</chapter>
--- 116,753 ----
</important>
</sect1>
+
+ </chapter>
+ <chapter id="install">
+ <title>Installation: From Zero to 60 in 30 minutes</title>
+ <para>
+ This section will walk you through a generic &rhl; installation
+ process. The system we are going to install is going to aim
+ <emphasis>exclusively</emphasis> at being a mail server running
+ nothing but virtual servers and webmail interface (so-called
+ "pop-toaster"). If you are planning to use your system
+ for any other services, you can still glance through this
+ installation part for hints and caveats, but your install will
+ differ from the one outlined below.
+ </para>
<sect1>
! <title>Considering the hardware</title>
<para>
! This setup is aimed at low- to middle-low-end installations,
! hence we will be VERY relaxed about our hardware
! requirements. Nevertheless, there are several important things
! to consider. First of all, we need to make sure that our
! server is capable of handling peak loads, such as happen at
! times when a new outlook virus hits the Internet (you HAVE
! banned outlook from your company's systems, right?
! <emphasis>RIGHT?</emphasis>). Another thing to consider is how
! many clients you are planning to support, together with how
! much maximum space you are going to allow them to have.
! </para>
! <para>
! Overall, we are looking at three different variables -- memory
! amount, processor speed, and hard drive space. Let's consider
! a setup with <emphasis>500</emphasis> clients max and look at
! all three of these variables.
</para>
<sect2>
! <title>HDD space</title>
<para>
! A sensible amount of mail quota to allow per client would be
! about 50Mb, so the amount of hard drive space we will
! require just for our 500 clients' e-mails would be around
! 25Gb. That's not all, though, as we will need to consider
! the amount of hard drive space that we will require for the
! mail queue.
</para>
<para>
! Let's imagine that we've been hit with a virus that mails
! itself to a hundred people and all 500 our clients got
! infected because we've stupidly allowed Outlook on our
! network (gee, did I come across as biased? :)). If the virus
! is around 100Kb in size, that means that the total amount of
! traffic a single client will generate will be around
! 10Mb. Multiply that by 500, and we arrive at a staggering
! 5Gb of traffic just to handle that virus. Since qmail will
! spend a good deal of time making connections, we will want
! to make sure that there is plenty of space to queue all of
! these requests. What this means is that we will have to
! allow around 5-7Gb of space for queuing, which brings us to
! 30-35Gb of total space for the mail subsystem.
</para>
! <para>
! The OS itself will actually require very little space -- no
! more than 1Gb for everything we will need, including virtual
! web-servers, preferences and other miscellaneous data.
! </para>
! <para>
! After we allow about one more gigabyte for system swap
! space, we arrive at 35-40Gb overall HDD space needed for our
! installation with 500 clients. Re-calculate the requirements
! for your number of clients using the following formula:
! </para>
! <segmentedlist>
! <title>HDD considerations</title>
! <segtitle>User space</segtitle>
! <segtitle>Qmail queue</segtitle>
! <segtitle>System and swap</segtitle>
! <seglistitem>
! <seg>N*50Mb</seg>
! <seg>N*10Mb</seg>
! <seg>1.5GB</seg>
! </seglistitem>
! </segmentedlist>
! <para>
! Whether you decide to choose SCSI or IDE is up to you, but
! you should consider that most common HDD activity will be
! accessing and moving small files, something that high-RPM
! SCSI drives do best. Depending on how redundant you want to
! be (which generally depends on how pissed off your clients
! can get, times the amount of downtime), you might consider
! creating a RAID array to mirror all your data.
! </para>
! <para>
! If you do decide to go with <acronym>RAID</acronym>, then my
! advice would be to get 1 small IDE drive for the system, and
! 3 SCSI drives for a RAID-1 array (1 active, 1 mirror, and 1
! spare). Granted, this setup will be more expensive, but
! believe me, you will sleep MUCH better at night.
! </para>
! </sect2>
! <sect2>
! <title>RAM requirements</title>
! <para>
! The amount of RAM we will require depends on the number of
! simultaneous connections we are going to have to our
! server. This largely depends on the environment you are
! setting this up for.
! </para>
! <para>
! If you are creating this setup for your company, then it's a
! good possibility that a good chunk of these 500 will be
! accessing your system simultaneously, especially around 9am
! in the morning when people first arrive at work and check
! their e-mail. If, however, you are an ISP and your clients
! are mostly home-users, then the amount of simultaneous
! connections your server is likely to experience would be
! MUCH lower, since people will tend to check their e-mail at
! various times during the day.
! </para>
! <para>
! Let's approximate -- if you are setting up a server for your
! company, the likely peak usage would be around 90% of all
! your clients. The amount of memory each request will consume
! depends largely on what kind of connection it is --
! <application>smtp</application> and
! <application>imap</application> require very small amounts
! of memory for each connection, within a few hundred
! kilobytes each. Webmail requests, however, are very
! memory-hungry and will likely gobble up a hefty chunk of RAM
! -- around 5Mb per each request. However, the good thing
! about webmail is that each request lasts only a few seconds,
! so even if 200 people decide to connect to your server at
! around the same time, it's unlikely that there will be any
! more than 50 http processes running simultaneously.
! </para>
! <para>
! But let's be pessimistic and allow for freaky
! coincidences. Let's imagine that all of your 500 clients
! decided to connect to your server at roughly the same time,
! and our apache daemon spawned 150 processes, consuming 5Mb
! each. That brings the memory usage up to 750Mb. The system
! itself consumes about 50Mb of your memory, so at peak loads
! we will be consuming around 800Mb of RAM. If you want your
! server to be snappy at all times, you will need to have at
! least that much memory in your box, however, if you decide
! that such coincidence is not very likely and you'd rather
! save on extra memory, you can settle on 512Mb and let the
! swapping process catch the rest.
! </para>
! <para>
! If, however, you are an ISP with most clients being
! home-users, you are not likely to experience more than 10%
! of your clients trying to connect at the same time. The
! memory requirement would be more relaxed, and it is likely
! that 256Mb of memory will suffice for you. Nevertheless,
! it's always better to have more memory, than less, so you
! are still encouraged to use 512Mb for 500 clients.
! </para>
! <para>
! In general, to calculate how much memory you will need use
! the following formulas:
! </para>
! <segmentedlist>
! <title>RAM considerations</title>
! <segtitle>For a company</segtitle>
! <segtitle>For an ISP with home-users</segtitle>
! <seglistitem>
! <seg>N/3*5+50</seg>
! <seg>N/10*5+50</seg>
! </seglistitem>
! </segmentedlist>
! <para>
! For 500 users these values will be 880Mb and 300Mb
! respectively. If you are going to rely on swapping, you can
! bring those values down to 512Mb and 256Mb.
! </para>
! </sect2>
! <sect2>
! <title>CPU requirements</title>
! <para>
! None of the processes are very CPU-intensive, actually, and
! you are not very likely to bottleneck at the processor
! level. The only exception would be when someone tries to
! sort a mailbox with thousands of e-mails in it, but I
! believe that is punishable by law in most countries
! anyway. The best way to avoid this is to set up message
! count quotas. Overall, I would recommend using something
! like a 1.5 GHz and above system for our 500 users, so our
! calculation formula would look something like so:
! </para>
! <segmentedlist>
! <title>CPU Considerations</title>
! <segtitle>Lower end</segtitle>
! <segtitle>Higher end</segtitle>
! <seglistitem>
! <seg>N*1.5+800</seg>
! <seg>N*2+1000</seg>
! </seglistitem>
! </segmentedlist>
! <para>
! I'm using the +800 method simply because I think that if
! you decide to use something less than a 800Mhz system, you
! are likely to be plagued by various problems related to
! aging hardware.
! </para>
! </sect2>
! <sect2>
! <title>Other stuff</title>
! <para>
! I am not covering networking environment and bandwidth,
! since you will likely have to stick with what you already
! have anyway. A common 100Base-T network card will suffice in
! terms of a NIC. However, you should consider implementing
! some sort of a backup solution to make sure that you don't
! lose your job or go out of business when your server catches
! on fire and you find it reduced to cinders when you come to
! work one lovely Monday morning. I have only good words to
! say about Amanda <ulink
! url="http://www.amanda.org/">http://www.amanda.org/</ulink>,
! or you may choose some of the many alternatives.
! </para>
! <para>
! Refer to the section on "What to back up" further
! in the document for the list of directories to include in
! your backup run.
! </para>
! </sect2>
! </sect1>
! <sect1>
! <title>Installing &rhl; &ver;</title>
! <para>
! There are two ways to do it. One is to get installation CDs
! and go through the installation process yourself, and another
! one is to use kickstart for a network install of a
! cookie-cutter QVCS system. In any case you will need the
! following information.
! </para>
! <sect2>
! <title>Partitioning</title>
! <para>
! You need to have at least 4 partitions:
! <simplelist type="inline">
! <member>/</member>
! <member>swap</member>
! <member>/var</member>
! <member>/home</member>
! </simplelist>.
! </para>
! <para>
! Use the calculations we just did in the previous section to
! come up with appropriate partition sizes, and create the
! "/home" partition last letting it use the rest of
! the remaining disk space. If you're making a RAID-1, utilize
! <application>Disk Druid's</application> nice RAID'ing
! features.
! </para>
! <para>
! For our example, the partitions would look like so, for a
! 40Gb HDD:
! </para>
! <programlisting>
! / - 1Gb
! swap - 1024Mb
! /var - 7Gb
! /home - the rest
! </programlisting>
! </sect2>
! <sect2>
! <title>Installing using kickstart</title>
! <para>
! Kickstart installations make the process extremely easy (or
! hard, depending on which part you are comfortable with). You
! will need either a bootable CD to start the process, or two
! floppies for the network install. Easiest is to burn a
! <filename>boot.iso</filename> image, which can be found
! here: <ulink url="&rhbase;/images/"> &rhbase;/images/
! </ulink>. ISO images can be burnt onto a CD from most
! OSes. If you have disk 1 of the &rhl; &ver; set, you can use
! it for this purpose as well.
! </para>
! <para>
! Boot from a CD that you have just created and when you get
! to a line that says "<prompt>boot:</prompt>", type
! in the following:
! </para>
! <para>
! <prompt>boot:</prompt> <userinput>linux
! ks=&qvcsbase;/qvcs-&ver;.ks</userinput>
! </para>
! <para>
! A text-based installation should start, and the only three
! questions you will need to answer would be:
! </para>
! <itemizedlist>
! <listitem>
! <para>
! how to partition the system (see the previous section
! for info)
! </para>
! </listitem>
! <listitem>
! <para>what time zone you are located in</para>
! </listitem>
! <listitem>
! <para>
! what your root password is
! </para>
! </listitem>
! </itemizedlist>
! <para>
! After you have answered all three of the above questions,
! the installation will chug along, unless something is
! horribly wrong with the installation source.
! </para>
! <para>
! Once all the packages have installed, you will be presented
! with a seemingly blank blue screen -- kickstart will be
! executing post-installation routines, such as updating your
! system to the latest &rhl; &ver; errata and installing
! &qvcs; packages. To see what is going on in more detail,
! press
! <keycombo>
! <keycap>Alt</keycap>
! <keycap>F3</keycap>
! </keycombo>
! which will switch you to a different console. You will see a
! whole lot of headers being downloaded, then a few packages
! updated and installed. After a little while
! post-installation will be finished, and you can switch back
! to the main installation console,
! <keycombo>
! <keycap>Alt</keycap>
! <keycap>F1</keycap>
! </keycombo>
! to reboot your machine after the installation.
! </para>
! <warning>
<para>
! If kickstart will not work for you, perhaps because of
! some problems with the network or installation servers,
! please refer to the next section on how to install the
! machine from distribution CDs.
</para>
+ </warning>
+ </sect2>
+ <sect2>
+ <title>Installing from &rhl; &ver; CDs</title>
+ <para>
+ If you are on a slow network, or are not comfortable with
+ using kicstart installations, you may use &rhl; &ver;
+ distribution CDs to install your &qvcs; pop-toaster.
+ </para>
+ <para>
+ The install process is simple enough. Just follow the setup
+ process, paying attention to the partitioning scheme we have
+ discussed above, and when it gets to package installation
+ select "Custom" and then <emphasis>uncheck all
+ groups in the selection screen</emphasis>. For this
+ installation we only want the core of the operating system.
+ </para>
+ <para>
+ Once the installation is complete, reboot, login as root,
+ and perform the following actions:
+ </para>
+ <programlisting>
+ &prompt; <userinput>wget &qvcsbase;/qvcs-init</userinput>
+ &prompt; <userinput>sh qvcs-init</userinput>
+ </programlisting>
+ <para>
+ <application>Qvcs-init</application> will install the public
+ keys, download the automated updater tool called
+ "yum", update your machine to the latest &rhl;
+ errata for &ver;, and install the QVCS group of packages.
+ </para>
+ <para>
+ Once <application>qvcs-init</application> finishes, reboot
+ the machine so unneeded services can be removed and
+ necessary ones started. Once your machine comes back up,
+ both kickstarted and manual installations should be at the
+ same point.
+ </para>
+ </sect2>
+ </sect1>
+ <sect1>
+ <title>Romantic getaway</title>
+ <para>
+ Let me explain in more detail what we just installed. There
+ are overall 14 packages that constitute the qvcs system:
+ </para>
+ <itemizedlist>
+ <listitem>
<para>
! <application>qmail</application>: This is the package with
! all main qmail binaries. Qmail is an
! <acronym>MTA</acronym> and <acronym>MDA</acronym>, which
! stands for "Mail Transport Agent" and "Mail
! Delivery Agent". It was written with security in mind
! and hasn't had a single security exploit in many
! years. Moreover, the author of this package has set up a
! prize of $1000 to anyone who can find a security flaw in
! qmail -- this prize has gone unclaimed in years.
! <footnote>
! <para>
! Just in case you are wondering: yes, I do have a
! permission to distribute this rpm. See <command>rpm
! -qi qmail</command> for more information.
! </para>
! </footnote>
</para>
! </listitem>
! <listitem>
<para>
! <application>qmail-initscripts</application>: This package
! contains initialization and xinetd scripts for qmail,
! written specifically for &rhl;.
</para>
+ </listitem>
+ <listitem>
<para>
! <application>courier-imap</application>: Courier-Imap is a
! very well-done IMAP server which was written specifically
! to work with "Maildir" mail storage system used
! by qmail. It is very fast, very standards compliant, and
! takes very little space in your computer's memory.
</para>
! </listitem>
! <listitem>
<para>
! <application>vmailmgr</application>: This is the Virtual
! Mail Manager for qmail -- it is also an
! <acronym>MDA</acronym> and allows you to have
! "virtual" e-mail users without giving said users
! shell access on your system, which can often lead to
! security compromises.
</para>
+ </listitem>
+ <listitem>
<para>
! <application>vmailmgr-courier-imap</application>: This
! small package adds an authentication module to
! courier-imap which allows it to work with virtual users
! set up by vmailmgr.
</para>
+ </listitem>
+ <listitem>
<para>
! <application>vmailmgr-daemon</application>: A small
! package containing a special binary which lets vmailmgrd
! communicate with other daemons, like perl or php in our
! case.
</para>
+ </listitem>
+ <listitem>
<para>
! <application>ucspi-unix</application>: This is a support
! package for vmailmgr-daemon and allows creating UNIX
! sockets on the system for communication between daemons.
</para>
+ </listitem>
+ <listitem>
<para>
! <application>libmcrypt</application>: This is a set of
! encryption libraries used by vadmin plugin. Vadmin uses
! libmcrypt to encrypt the passwords before storing them on
! the hard drive for enhanced security.
</para>
+ </listitem>
+ <listitem>
<para>
! <application>php-mcrypt</application>: A shared library
! file which ties libmcrypt to php and provides php
! encryption functions.
</para>
! </listitem>
! <listitem>
<para>
! <application>squirrelmail</application>: This is a great
! IMAP-based php webmail system.
</para>
! </listitem>
! <listitem>
<para>
! <application>vadmin</application>: Vadmin is a plugin for
! squirrelmail which makes administering vmailmgr virtual
! domains a part of squirrelmail. It has some very nice
! features like the ability to add/remove users, set quotas
! or account expiration dates, etc.
</para>
! </listitem>
! <listitem>
<para>
! <application>qmail-autoresponder</application>: This
! package allows setting up autoresponders through the
! squirrelmail (vadmin) interface.
</para>
! </listitem>
! <listitem>
<para>
! <application>qvcs-helpers</application>: This package has
! a few helper scripts which come with this guide. They will
! be explained later.
</para>
+ </listitem>
+ <listitem>
<para>
! <application>yum</application>: This is an automated
! updater and installer that makes installing software and
! keeping your server updated very easy.
</para>
! </listitem>
! </itemizedlist>
! <para>
! And no, the title of this section doesn't have anything to do
! with any of it. It simply states what I would rather be doing
! right now instead of writing this guide. :)
! </para>
! </sect1>
! <sect1>
! <title>QVCS-install</title>
! <para>
! After the initial installation is completed, we need to run
! <command>qvcs-install</command> in order to configure the
! system for our purposes.
! </para>
! <programlisting>
! &prompt; <userinput>qvcs-install</userinput>
! </programlisting>
! <para>
! This tool will configure the system software for some default
! settings, suitable for running the base &qvcs; install. The
! best thing about it is the fact that it will save backup
! copies of the files it overwrites into
! <filename>/var/lib/qvcs-install</filename> so you can always
! restore old configurations if you find it necessary.
! </para>
! <para>
! Once this step is done, you are ready to configure your system
! for actual use.
! </para>
! </sect1>
! </chapter>
! <chapter id="config-basic">
! <title>Basic Configuration</title>
! <para>
! Let's go ahead and configure your system so it's suitable for
! your purposes.
! </para>
! <note>
! <title>Examples</title>
! <para>
! For the sake of providing examples, I will be using the
! following virtual domains to make the narrative easier to
! follow:
! <simplelist type="inline">
! <member>hogwarts.jk</member>
! <member>theministry.jk</member>
! <member>quidditch.jk</member>
! </simplelist>
! (what Harry Potter addiction?).
! </para>
! </note>
! <sect1>
! <title>Creating the first virtual domain</title>
! <para>
! The first virtual domain requires some effort, but only
! relatively to the others. Here is how we would proceed.
! </para>
! <note>
! <para>
! If you are getting "<computeroutput>command not
! found</computeroutput>" errors, make sure you are
! logged in as root. If you have used <command>su</command> to
! become root, make sure you use "<command>su
! -</command>" to enable the root environment.
! </para>
! </note>
! <programlisting>
! &prompt; <userinput>addvirt hogwarts.jk</userinput>
! </programlisting>
! <para>
! The <command>addvirt</command> script will ask you for a
! password. Remember it, as you will need it to enable the
! domain in vadmin. Make sure it's a good password, too, as it
! is a system password and though the account is marked as
! <command>/sbin/nologin</command> during creation, having poor
! passwords is one of the main reasons servers get cracked.
! </para>
! <para>
! Now we need to create the first virtual user. To do that,
! let's become the domain "master user" and use the
! <command>vadduser</command> command to create the virtual
! account. If you look at the output of the "addvirt"
! command, you will notice something to the matter of
! "<computeroutput>Creating new domain user
! "theministry_jk"</computeroutput>. In the next
! command you will need to use the username reported by the
! resulting command instead of "hogwarts_jk" (usually
! it just subsitutes all dots for underscores in the domain to
! arrive at the username). Oh, and make it something other than
! "albus."
! </para>
! <programlisting>
! &prompt; <userinput>su -s /bin/bash - hogwarts_jk</userinput>
! <prompt>[hogwarts_jk@mail hogwarts_jk]$ </prompt><userinput>vadduser albus</userinput>
! <prompt>[hogwarts_jk@mail hogwarts_jk]$ </prompt><userinput>exit</userinput>
! &prompt; <userinput>service qmail restart</userinput>
! </programlisting>
! </sect1>
! <sect1>
! <title>Editing <filename>vadmin.conf</filename></title>
! <tip>
! <para>
! The only editor that comes with your machine is
! <command>vi</command>. If it gives you the creeps, you can
! install <command>nano</command> by using yum. Nano is a
! successor to pico and inherits all of its shortcuts.
! <programlisting>
! &prompt; <userinput>yum install nano</userinput>
! </programlisting>
! </para>
! </tip>
! <para>
! Open <filename>/etc/vadmin/vadmin.conf</filename> in your
! editor and locate the [auth] section. Change the
! <varname>elvis</varname> parameter to reflect the virtual user
! that you have just added. For a <varname>domain</varname> add
! the domain name that you have just created using
! "addvirt". E.g. for me that would be:
! </para>
! <programlisting>
! [auth]
! method = user
! force_https = yes
! elvis = albus@hogwarts.jk
! domain = hogwarts.jk
! </programlisting>
</sect1>
</chapter>
|
