| Login | Ramblings | Résumé | IT Portfolio | Home |
The Great Linux Project is my Summer of 2003 project which is to acquire a decent machine to become my 2nd Linux server and then set up Gentoo Linux on the box followed by fully configuring the machine to run as a web, mail, ftp server for the Internet and as a file server for my LAN.
The machine I chose was a Dell 6350 purchased off eBay for a mere $899 (including S&H). I purchased this machine after researching and making sure there was ample Linux support for this machine. As it turns out, it had been certified to run on Red Hat as Dell shipped numerous machines with Red Hat installed by factory option. This turns out to be a great thing as my Mandrake Install CDs would come in quite handy.
The following is the description from eBay:
This unit is a Dell Poweredge 6350 which has dual 550 Xeon 2M L2 cache on both processors and is capable of quad procs.The memory is 1 GIG and has (3)18.2 GIG SCSI drives in Dell trays.The Dell Poweredge Expandable RAID Controller 2 is running the raid and the unit has passed all diagnostic tests.The unit has (3) power supplies and the standard CD-ROM and floppy drive.The side rails are included but there are no sliders for the cabinet part,just what is actually pictured is included,plus the standard keyboard,mouse and power cord.Ask questions before the end of the auction and if Your looking at this type of heavy duty server then I hope You know what it's all about.The Dell diagnostic software is pre-installed and there is no o/s included. Shipping will be 40 dollars in the connected continental US ONLY! Payment can be by Paypal,money order or cashiers check due within 5 days from auction's end.Ask questions and the unit carries our no DOA guarantee through the boot sequence for not having an o/s.Please use the Ebay checkout feature after You have won the auction and visit our other auctions for more networking and printer equipment.Thanks!!!
The machine arrived Wednesday morning and it was off to the races. The first thing I did was boot up the machine and verify all the hardware was as described on the eBay article and everything was good to go. The only thing really missing was the original CDs that came with the machine so I could reinstall the system diagnostics should I ever have to completely rebuild the RAID. Requested this CD from the seller and he says its on the way.
The next thing I did was verify that I had the RAID configuration I really wanted for the machine. With three 18.2gig HDs in it, it came configured as one large 33.6gig disk. After some research, I learned that this configuration requires all three disks, is fully fault tolerant to one disk loss (i.e. I can lose any one disk and it would still function correctly).
I still had my Gentoo 1.0 Install CD lying around so the first thing I did was pop that in and gave it a whirl. I got to the boot prompt and modprobed for the scsi devices and network card. This got me online in short order, but I couldn't find the hard drive. After trying out the new Gentoo 1.4 CD and having no luck, I gave the old Mandrake 8.1 CDs a shot and this OS flawlessly detected everything in my system. I couldn't resist loading up Mandrake 9.1 in similar fashion and it, too installed flawlessly with all the default settings.
I now had a game plan. I would install Mandrake 9.1, carefully configuring the filesystem volumes and then perform a chroot install of Gentoo to switch the whole system over to Gentoo.
For the filesystem, I wanted to be sure I chose the right one for running and maintaining the server over the long run. It was a tough choice between Ext3, XFS, JFS, and ReiserFS. I only knew I didn't want Ext2, which offers no journalling capabilities as the others mentioned did. With a bit of research, I quickly narrowed the choices down to XFS and ReiserFS. In the end, I set up the following partitions:
| Mount | Size | Filesystem |
|---|---|---|
| / | 5 gb | ReiserFS |
| swap | 424 mb | Linux Swap |
| /gentoo | 5 gb | ReiserFS |
| /large | 5 gb | XFS |
| /home | 18 gb | ReiserFS |
In the end, I chose to go with the ReiserFS filesystem for its purported stability, good performance on typical sized files and future potential get even better over time, especially with large file I/O performance. The lone XFS "/large" partition is where I intend to store ultra large files (such as the database files utilized by Zope, PostgreSQL, etc.).
The "/gentoo" mount point will be where Gentoo Linux is installed. Grub was chosen as the bootloader as it seemed easier to configure as I try out various linux kernels (experience gained from early days of trials and tribulations with getting Gentoo installed).
Interview With the People Behind JFS, ReiserFS & XFS
Common threads: Advanced filesystem implementor's guide, Part 9
Once all the filesystems were defined, I quickly moved through the Mandrake install only installing minimal stuff to get a KDE graphical desktop setup. Things installed and booted up as expected. We're ready to begin installing Gentoo!
# hdparm -tT /dev/sda/dev/sda: Timing buffer-cache reads: 128 MB in 0.58 seconds =220.69 MB/sec Timing buffered disk reads: 64 MB in 1.54 seconds = 41.56 MB/sec
For one used to IDE drives, can you say, "Smmmmooookkkinnnnng!"
Faster apps on a better machine
Ok, this was a tricky one to do and since I got all bogged down in just trying to make it work, I stopped documenting as I went, so this page is rather, uhmmm...sketchy, to say the least.
Basically, it boiled down to installing Mandrake, then feeding off all its wonderful hardware recognition wizardry to do the menuconfig on the Gentoo Kernel, which was built inside a chroot under the Mandrake Kernel. I'll try to document the actual process if I ever do it again (not likely).
Even so, all is not lost, here is what I do to maintain my kernel. I chose the gs-sources for server reliability.
To quote: http://www.gentoo.org/doc/en/gentoo-kernel.xml
For users to whom desktop interactive performance comes as a secondary priority to reliability and hardware support, we have the gs-sources. GS stands for Gentoo Stable (creative, aren't we?). This patch set is tuned and tested to provide the best support for the latest hardware and ensures that your mission critical servers will be up when you need them. This kernel doesn't have some of the most aggressive performance tuning patches from the gentoo-sources, but rest assured, the great performance that you know and love from the vanilla kernels are alive and well. Where possible and without compromising stability we add server related performance patches.
This kernel provides support for the latest ACPI subsystem, EVMS, ECC (required for HA Linux systems), Encrypted Loopback devices, NTFS, Win4Lin and XFS. It also contains updates for IDE, ext3 and several network cards amongst other patches.
In other words, these sources are perfect for servers and High-Availability systems.
# cp /usr/src/linux/.config /usr/src/linux-2.4.23_pre8-gss/.config # rm /usr/src/linux # ln -s /usr/src/linux/linux-2.4.23_pre-gss/ /usr/src/linux # cd /usr/src/linux # make dep && make bzImage modules modules_install
# cp arch/i386/boot/bzImage /mandrake/boot/kernel-2.4.23_pre8-gss # cp System.map /mandrake/boot/System.map-2.4.23_pre8-gss # cp .config /boot/config-2.4.23_pre8-gss
Watch out! I built my Gentoo by chroot'ng off a Mandrake 9.1 Install. If you built according to standard Gentoo installations, don't be having "mandrake" in your destination path.
Gotta have the kernel to boot. System.map for oops. Saving config file for easy retrieval on next kernel build.
What is System.map?, you say?
| To bring system up to date. | emerge rsync emerge -u system emerge -u world etc-update |
| To search the portage tree | emerge -s texttosearchfor |
| To pretend... | emerge -p packagename |
| Where's the portage tree? | cd /usr/portage |
emerge apache
I like my apache home directory off the /home subdirectory.
mkdir /home/apache/ mv /var/www/localhost /home/apache
Gotta have SSL. Edit /etc/conf.d/apache2 and uncomment line with option to start SSL.
The basic rule when configuring the kernel is to remove everything, you do not need. This will create a small kernel but also remove the vulnerabilities that may lie inside drivers and other features.
Also consider turning off loadable module support. Even though it is possible to add modules (root kits) without this features, it does make it harder for normal attackers to install root kits via kernel modules.
Many kernel parameters can be altered through the /proc file system or by using sysctl.
To dynamically change kernel parameters and variables on the fly you need CONFIG_SYSCTL defined in your kernel. This is default in a standard 2.4 kernel.
Code listing 10.1: Drop ping packets |
# /bin/echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_all
|
This will cause the kernel to simply ignore all ping messages also known as ICMP type 0 messages. The reason for this is that an IP packet carrying the ICMP message can contain payload with other information than you think. Administrators use ping as a diagnostic tool and often complain if they cannot ping. There is no reason for an outsider to be able to ping. But sometimes it can be handy for insiders to be able to ping. Then this can be solved by disabling ICMP type 0 messages in the firewall.
Code listing 10.2: Ignore broadcast pings |
# /bin/echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
|
This disables response to ICMP broadcasts and will prevent Smurf attacks. The Smurf attack works by sending an ICMP type 0 (ping) message to the broadcast address of a network. Typically the attacker will use a spoofed source address. All the computers on the network will respond to the ping message and thereby flooding the spoofed host.
Code listing 10.3: Disable source routed packets |
# /bin/echo "0" > /proc/sys/net/ipv4/conf/all/accept_source_route
|
Do not accept source routed packets. Attackers can use source routing to generate traffic pretending to originate from inside your network, but it is actually routed back along the path from which it came, so attackers can compromise your network. Source routing is rarely used for legitimate purposes so disable it.
Code listing 10.4: Disable redirect acceptance |
# /bin/echo "0" > /proc/sys/net/ipv4/conf/all/accept_redirects
|
Disable ICMP redirect acceptance. ICMP redirects can be used to alter your routing tables, possibly to a bad end.
Code listing 10.5: Protect against bad error messages |
# /bin/echo "1" > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
|
Enable protection against bogus error message responses.
Code listing 10.6: Enable reverse path filtering |
# for i in /proc/sys/net/ipv4/conf/*; do
/bin/echo "1" > $i/rp_filter
done
|
Note: If you turn on IP forwarding, you will also get this result. |
Turn on reverse path filtering. This helps make sure that packets use legitimate source addresses, by automatically rejecting incoming packets if the routing table entry for their source address does not match the network interface they are arriving on. This has security advantages because it prevents IP spoofing.
Warning: However turning on reverse path filtering can be a problem if you use asymmetric routing (packets from you to a host take a different path than packets from that host to you) or if you operate a non-routing host which has several IP addresses on different interfaces. |
Code listing 10.7: Log all spoofed, source routed and redirect packets |
# /bin/echo "1" > /proc/sys/net/ipv4/conf/all/log_martians
|
Log spoofed packets, source routed packets and redirect packets.
Code listing 10.8: Activate IP forwarding |
# /bin/echo "0" > /proc/sys/net/ipv4/ip_forward
|
Make sure that IP forwarding is turned off. We only want this for a multi-homed host.
All these settings will be reset when the machine is rebooted. So I suggest that you add the following script to the run level rc-update add procparam defaultand make it executable chmod +x /etc/init.d/procparam.
Code listing 10.9: /etc/init.d/procparam |
#!/sbin/runscript |
To generate a host key, run "make host-key". Alternately you can do so manually using the following commands:
ssh-keygen -t rsa1 -f /etc/ssh/ssh_host_key -N ""
ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key -N ""
ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key -N ""
http://www.skunkworx.org/guides/QmailOnGentoo.txt
This document gives instructions on how to install, configure, and run qmail on a system running Gentoo Linux. I wrote this after I could not find any qmail documentation specific to Gentoo, despite Gentoo offering packages (or "ebuilds", to use Gentoo's terminology) for qmail and related software.
You are probably not reading this if you are not familiar with Gentoo Linux, but just in case, Gentoo is a relatively new distribution that aims at striking a compromise between the convenience and compatibility of a linux installation based on ready-made software packages, and the power and configurability of a linux installation built from source. For more details, visit Gentoo's website (http://www.gentoo.org). Gentoo's promise of being able to tailor software exactly to a system's specifications, while at the same time having a package manager easily keep track of it all, was what attracted me to this operating system, to say nothing of the recommendations I received from friends and coworkers.
You are probably also not reading this if you have not heard of qmail, but to be thorough, Daniel J. Bernstein's qmail is an email server software package, providing the same general functionality of packages like Sendmail or ssmtp. qmail is undebatably the most secure email server software available for Unix-compatible, and I would argue that it is the most secure email server software period. qmail also provides plenty of configurability, enough to suit the needs of almost any email-related task. The fact that qmail has not had an official release since 1997, and yet continues to grow in popularity without a single security alert, is testimony of its quality. qmail is not for the faint of heart, however. Even with a versatile package manager like Gentoo's Portage, qmail requires some manual intervention, not to mention firm knowledge of what you are doing, to run optimally.
These instructions were written using Gentoo Linux 1.4, installed following the distributor's instructions, and the qmail ebuild provided by Gentoo through its package manager, Portage. As of this writing, the recommended Gentoo ebuild for qmail is 1.03-r10. There may be instructions here that are specific to these versions. Also, Gentoo and Portage are highly customizable, and experienced Gentoo users who have heavily tweaked their systems may find these instructions completely off base.
qmail as installed by Portage closely follows the process prescribed by "Life with qmail" (LWQ, http://www.lifewithqmail.org), written by Dave Sill. LWQ is required reading; the instructions given here mostly highlight the steps not taken by Portage that you will need to perform manually in order to have an installation that conforms to LWQ.
Gentoo's qmail ebuild includes a few patches to the original source code. These patches fix minor bugs and provide additional features not present in the author's distribution of qmail 1.03, including the ability to encrypt SMTP sessions with TLS, and the ability to authenticate SMTP sessions using the AUTH command. These patches, and the additional features they provide, will be discussed in greater detail in a future revision of this guide.
IMPORTANT: qmail, as well as any software package written in the C programming language, relies on a package called glibc to provide the basic C function libraries. As of this writing, Gentoo's recommended glibc ebuild is version 2.3.2-r1. Because of an old coding method that is no longer supported by the authors of glibc, all qmail ebuilds older than 1.03-r10 (as well as the unpatched source code for qmail 1.03) ARE NOT COMPATIBLE with any ebuilds based on glibc 2.3.2! To ensure smooth installation, make sure you are using the latest unmasked ebuilds of qmail and all software packages qmail depends on (including daemontools, ucspi-tcp, checkpassword, cmd5checkpw, and dot-forward; more information about these packages is below.)
Before you can install qmail, you may need to configure Gentoo to allow you to do so. This requires knowing a few things about Gentoo and Portage.
One of Portage's features is the ability to keep track of "virtual" packages. Virtual packages are not specific software packages, but are definitions that can be matched by any Gentoo ebuild claiming to do so. When you install (or "merge") an ebuild that matches the definition of a virtual package, Portage considers that virtual package present on your system.
Gentoo keeps a list of default ebuilds it will use to satisfy virtual package needs. An ebuild from this list is merged whenever the associated virtual package is requested and a matching ebuild is not already present. Many of these ebuilds are added to the system during Gentoo's initial set-up.
Much of Gentoo's behavior is governed by a set of configuration files collectively known as a "profile." Included in a profile is the default list for satisfying virtual package requirements. Regardless of what profile you use, you can look at the associated files in /etc/make.profile. Editing these files is not a good idea, unless you are planning on building your own profiles for distribution.
Besides the default list supplied by a profile, Gentoo also keeps a list of virtual packages actually present on your system, and the ebuilds that represent those virtual packages. Gentoo keeps this list in the file /var/cache/edb/virtuals. Whenever you merge an ebuild that satisfies the requirements for a virtual package, that virtual package's entry is created or updated in /var/cache/edb/virtuals. However, for some virtual packages, Gentoo allows only one matching ebuild to be present, and any attempt to merge another matching ebuild will be blocked by Portage. When necessary, this feature can be worked around by editing /var/cache/edb/virtuals manually.
Gentoo controls the presence of an email server (or, more accurately, a "mail transfer agent") with the virtual package "virtual/mta". Normally, only one virtual/mta package is allowed to be present. Gentoo's qmail ebuild is a virtual/mta package, however, it is not the only one. If you followed all instructions for installing Gentoo, ssmtp will be present on your system, and will be listed in /var/cache/edb/virtuals, blocking all other virtual/mta packages.
So, to allow qmail to be installed, you must edit /var/cache/edb/virtuals. Look for the line that starts with "virtual/mta". You can do one of two things to this line:
virtual/mta net-mail/ssmtp net-mail/qmail
This will allow qmail and ssmtp to be present on your system.
#1 is the recommended choice, as it is usually not a good idea to have more than one MTA installed on your system.
Now, you are ready to install qmail. Don't unmerge ssmtp just yet, as other components of your system may complain about the sudden lack of a virtual/mta package.
Thanks to Portage and the "emerge" command, all of the software required for running qmail is installed with a single command. However, keep in mind that the authors of Gentoo recommend you always run emerge with the "pretend" flag prior to installing any new packages, so that you know for certain what is about to be installed on your system.
# emerge -p qmail
These are the packages that I would merge...
Depending on what you already have available, you will see a number of ebuilds that Portage would merge along with qmail. Most likely you will see "ucspi-tcp", "daemontools", "dot-forward", "checkpassword", and "cmd5checkpw" in this list. Except for "cmd5checkpw", these are additional tools written by Bernstein, designed to provide a stable, easily configurable environment for qmail. "ucspi-tcp" and "daemontools" in particular are required packages for a qmail installation that conforms to LWQ, and Gentoo's default configuration appropriately defines qmail as dependent on these packages.
(NOTE: Gentoo offers an ebuild called qmail-sumo that will install qmail and all software qmail depends on, and then also install additional qmail related tools. You can run "emerge -p qmail-sumo" to see the list of packages that would be installed. qmail-sumo will be discussed in greater detail in a future revision of this guide, however, qmail-sumo can be safely merged for the purposes of this guide.)
(NOTE: "cmd5checkpw" is used to offer authenticated SMTP, which will be covered in a future revision of this guide.)
Once you are satisfied in knowing what is going to be added to your system, run emerge again without the "pretend" flag.
# emerge qmail
When this command finishes, the system will be almost ready. Portage not only installs qmail and all related software, but also performs a number of necessary system configurations, and installs several scripts documented in LWQ.
Gentoo's qmail ebuild includes an option that allows for some additional automatic configuration. In fact, this extra configuration will be enough for qmail to run securely and effectively on many systems. However, while I recommend taking advantage of this option to prevent any security checkpoints from being accidentally overlooked, this feature should not be considered a substitute for following the rest of this guide, especially if qmail is to be used in a production environment. To perform the additional automatic configuration, run this command:
# ebuild /var/db/pkg/net-mail/qmail-1.03-r10/qmail-1.03-r10.ebuild config
If run, the above command will look up the machine's fully qualified domain name, and set up qmail to process email bound for this name specifically. For example, if the fully qualified domain name is machine.example.com, qmail will process for local delivery any email bound for an address ending in "@machine.example.com" (but not "@example.com"). qmail will also be instructed to reject any other email, unless the connection is from an IP address local to the machine; in that case the email will be directed (or "relayed") to the appropriate destination. This effectively restricts relaying to system users actually logged into the machine. These configurations may not be exactly what you want, so continue reading to learn how to configure qmail to suit your needs.
(NOTE: Running the above ebuild command will also generate a self-signed SSL certificate for use with encrypted SMTP. More informaiton about encrypted SMTP will be in a future revision of this guide. For now, simply follow the instructions given; you can safely ignore the generated certificate if you do not plan on using encrypted SMTP.)
From this point, follow LWQ starting with section 2.7. Refer to the instructions below for Gentoo-specific notes related to each section.
rc-update add svscan default
Note that starting svscan from an rc script does not protect it from unexpected termination. If you would like to take advantage of init's ability to keep processes alive, do not use Gentoo's rc script for svscan. Instead, edit /etc/inittab, adding this line:
SV:12345:respawn:/usr/bin/svscanboot
Note that the ebuild uses a different directory for daemontools' executables than the author's original package.
The comments for Red Hat Linux's chkconfig tool are not needed. PATH does not have to include /usr/local/bin or /usr/local/sbin; these directories are empty on a typical Gentoo system.
(NOTE: tcpserver, the program used to listen for SMTP connections, will always set a limit on the number of concurrent connections allowed. The default is 40. See tcpserver's documentation at http://cr.yp.to/ucspi-tcp/tcpserver.html for more details.)
(NOTE: See LWQ appendix B.6 for more information on rblsmtpd.)
You may wish to change this script to bring it in line with LWQ. If so, keep in mind that Portage will not automatically remove files that were changed after an ebuild was merged, so if you ever remove or update qmail, you will need to handle this file (and any other files you have changed) manually. If you decide to leave the script as is, you can skip the step where /var/qmail/control/concurrencyincoming is created.
All log files under /var/log are already created, as is the /service directory. You will need to create the symbolic links within the /service directory. Note that qmail will not start automatically after these links are created, unless svscan is running (see the notes for LWQ section 2.7).
emerge -C mailbase emerge -C ssmtp
(NOTE: Any configuration you may have performed to run ssmtp on your system, such as having it start automatically during system boot, will need to be undone prior to removal.)
The "sendmail" symbolic links are already created.
Now follow the instructions given in LWQ section 3 to fully configure qmail. If you performed the optional configuration discussed above, a number of files discussed in LWQ section 3 will already exist by this point:
/var/qmail/control/me /var/qmail/control/defaultdomain /var/qmail/control/plusdomain /var/qmail/control/locals /var/qmail/control/rcpthosts
Each of these files will contain a single line, the fully qualified domain name of the machine. LWQ section 3 explains what each of these files is for.
(NOTE: The optional configuration discussed above will also create files "clientcert.pem" and "servercert.pem" in /var/qmail/control. These files are necessary for encrypted SMTP, which will be discussed in greater detail in a future revision of this guide. They can be safely ignored if you do not plan on using encrypted SMTP.)
Gentoo offers a qmail-pop3d ebuild that follows most of steps 4 through 6. Simply run "emerge qmail-pop3d". When this command finishes, you MUST edit the newly installed /var/qmail/supervise/qmail-pop3d/run script, replacing "theleaf.be" with the fully qualified domain name of your machine. Then, run the following command to finish the installation:
ln -s /var/qmail/supervise/qmail-pop3d /service
(NOTE: If you used the qmail-sumo ebuild to install qmail, the qmail-pop3d ebuild will already be in place.)
If you created the /var/qmail/bin/qmailctl script discussed in LWQ section 2.8.2.1, follow steps 7 through 12 to add features related to qmail-pop3d.
If svscan is currently running, POP3 service should now be available.
Your qmail server should now be ready for action. However, you may still have some questions or concerns.
If you are using Gentoo without many customizations, and you have a concern about qmail's installation as performed by Portage, contact the maintainers of Gentoo, as they wish to be notified of any problems with their ebuilds. Their policy is to investigate the problem, and then notify the original software authors themselves if they determine the cause lies there. Visit Gentoo's bug page (http://bugs.gentoo.org) for more information.
If you have successfully installed qmail, but now you have a question about its performance and/or your configuration, the qmail mailing list is the place to ask experienced qmail users for information. However, please keep in mind these are people giving of their free time, and they are very tired of reading the same questions over and over. I cannot emphasize this enough: READ THE DOCUMENTATION and, if appropriate, CHECK YOUR LOGS before asking a question on the list. LWQ, the qmail man pages, the web pages maintained by qmail's author at http://cr.yp.to, and especially the qmail mailing list archives (http://www.ornl.gov/cts/archives/mailing-lists/qmail/) are all excellent sources of information, and many list veterans consider all of these to be required reading. Should you decide a question to the list is necessary, list veteran Charles Cazabon has written "12 Steps to qmail List Bliss" (http://www.qcc.ca/~charlesc/writings/12-steps-to-qmail-list-bliss.html), detailing what every list veteran would like to see happen when somebody has a question about qmail.
If you have a question or comment about this guide in particular, feel free to email me at skunkworx@kingwoodcable.com.
Thanks to Dave Sill for excellent qmail documentation in the form of "Life
with qmail" and The qmail Handbook.
Thanks to Charles Cazabon for invaluable help through the qmail mailing list.
Thanks to Daniel J. Bernstein for qmail itself.
Thanks to the authors and contributors of Gentoo for creating an excellent linux distribution.
# emerge mysql
# /usr/bin/mysql_install_db # /etc/init.d/mysql start # /usr/bin/mysql_admin -u root -h dawg passwordnew_password# /usr/bin/mysql_admin -u root passwordnew_password
Here's how:
Then you can add new users by issuingGRANTstatements:mysql> GRANT ALL PRIVILEGES ON . TO monty@localhost -> IDENTIFIED BYsome_passWITH GRANT OPTION; mysql> GRANT ALL PRIVILEGES ON . TO monty@%-> IDENTIFIED BYsome_passWITH GRANT OPTION; mysql> GRANT RELOAD,PROCESS ON . TO admin@localhost; mysql> GRANT USAGE ON . TO dummy@localhost;These
GRANTstatements set up three new users:
monty- A full superuser who can connect to the server from anywhere, but who must use a password
'some_pass'to do so. Note that we must issueGRANTstatements for bothmonty@localhostand
monty@"%". If we don't add the entry withlocalhost, the anonymous user entry forlocalhostthat is created bymysql_install_dbtakes precedence when we connect from the local host, because it has a more specificHostfield value and thus comes earlier in theusertable sort order.admin- A user who can connect from
localhostwithout a password and who is granted theRELOADandPROCESSadministrative privileges. This allows the user to execute themysqladmin reload,mysqladmin refresh, andmysqladmin flush-*commands, as well as
mysqladmin processlist. No database-level privileges are granted. (They can be granted later by issuing additionalGRANTstatements.)dummy- A user who can connect without a password, but only from the local host. No privileges are granted--the
USAGEprivilege type allows you to create a user with no privileges. It has the effect of setting all the global privileges to'N'. It is assumed that you will grant specific privileges to the account later.You can also add the same user access information directly by issuing
INSERTstatements and then telling the server to reload the grant tables:shell> mysql --user=root mysql mysql> INSERT INTO user VALUES(localhost,monty,PASSWORD(some_pass), ->Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y); mysql> INSERT INTO user VALUES('%',monty,PASSWORD(some_pass), ->Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y); mysql> INSERT INTO user SET Host=localhost,User=admin, -> Reload_priv=Y, Process_priv='Y'; mysql> INSERT INTO user (Host,User,Password) -> VALUES(localhost,dummy,''); mysql> FLUSH PRIVILEGES;
Taken from http://www.mysql.com/doc/en/Adding_users.html
Since this computer acts as gateway and firewall to my LAN and I want DHCP to assign/manage IP addresses on the local machines, I needed to install and configure dhcpd.
Installing dhcpd required setting CONFIG_PACKET (Packet socket) and CONFIG_FILTER (Socket Filtering) to "*" in the menuconfig for the kernel build. After that, I added dhcp to the /etc/init.d default startup.
# rc-update add dhcp default
Also, edited the /etc/dhcp/dhcpd.conf as follows:
ddns-update-style none;
subnet 192.168.0.0 netmask 255.255.255.0 {
# default gateway
option routers 192.168.0.3;
option subnet-mask 255.255.255.0; option domain-name "gibberishcode.net";
option domain-name-servers 192.168.0.3;
range dynamic-bootp 192.168.0.16 192.168.0.253;
default-lease-time 21600;
max-lease-time 43200;
}
eth0 connects to the DSL modem and the DSL modem takes care of connecting to ISP. The DSL modem has been configured for IP Pass-thru so that the external IP address is assigned to the eth0 NIC. Which means that dhcpcd had to be emerged and a small script written to activate eth0 at bootup.
#!/sbin/runscriptdepend() { need net use checkroot }
start() { ebegin "Starting up dhcpcd for eth0 and eth1" dhcpcd eth0 dhcpcd eth1 eend 0 }
stop() { ebegin "unsetting dhcpcd for eth0." echo "Not implemented, yet." eend 0 }
As you can see, I don't rightly know how to kill off this service. Anybody?
To begin setting up PostgreSQL complete with Zope access:
# emerge -u postgres # emerge -u psycopg # emerge -u zpsycopgda
Had trouble importing Zope 2.5.1 into 2.6.4, so just copied the whole shebang for now to /home/zope/zope. The ZpsycopgDA adaptor wouldn't load, complaining about linked library not found. Copied the psycopgmodule.so file from /usr/lib/python2.1/site-packages into the /home/zope/zope/lib/python directory and this solved the problem loading Zope.
Created postgres home directory and directory for data files on the "large" volume.
# mkdir /large/postgresql # chown postgres postgres:postgres /large/postgresql # mkdir /large/postgresql/data
Edited /etc/conf.d/postgresql to set data and logfile paths to /large/postgresql/data then initialized the database and started the services.
# su - postgres # initdb -D /large/postgresql/data # /etc/init.d/postgresql start
Logged on to old server and exported all the databases
# ssh root@mandrake # su - postgres # pg_dumpall > data.dump # exit
Copied to /large/postgresql on new server and imported the database.
# psql -f /large/postgresql/data.dump template1
It doesn't matter which database you specify here since the script file created by pg_dumpall will contain the appropriate commands to create and connect to the saved databases.
Zope 2.5.1 website with PostgreSQL connections should now work at this point.
Creating a database cluster
PostgreSQL
7.4 Documentation (pg_dumpall)
| mwlang@cybrains.net | Guest | Login | Home |