Dashboard > Maintain > Attic > Maintain - System Administration > Information > Page Comparison
Maintain Log In   View a printable version of the current page.
Maintain - System Administration
Browse Space    
Version 42 by Nathan Butcher
on Jan 23, 2006 21:06.

<< Changes from 41 to 42
compared with
Current by Frederic Wenzel
on Sep 05, 2006 14:11.
(show comment)
 
Key
These lines were removed. This word was removed.
These lines were added. This word was added.

View page history


There are 2 changes. View first change.

  
  
 *ALL INFORMATION HERE IS FOR MAINTAIN 2.4*
  
 This page will be for documenting System Administration issues on [Maintain|http://osuosl.org/projects/maintain]. This covers installation, configuration editing, network design, documentation writing... and anything else a competant Linux sysadmin would need to get Maintain working with as little fuss as possible.
  
 I spent ages trying to build a system which would be as lightweight as possible for maintain with all the necessary packages it needs to work properly. Finally I have it all planned out.
  
 I started off trying to use Red Hat Enterprise 2.1, but that was way too old. Even though the recommended packages were in, the PHP just broke for some unknown reason. I switched to Debian and haven't looked back.
 Safe to say that if you actually want to use Redhat as a distro, then anything later than RedHat 7.2 will probably work, but if you can get away using Debian, then please do. FreeBSD should also be possible. Let us know how it goes if you manage to do it on one of the BSDs.
  
 h3. INSTALLATION
  
 Debian is a recommended distro for Maintain. Apt-get makes the install very painless and also very lightweight on disk space. If you're a linux admin fanatic who wants to use only the bare minimum space needed for a particular server's Linux install... the debian-sarge netinstall iso is it. Maintain on my server isn't even topping a 400MB footprint... and that makes me think I could stick the entire system onto compact flash and forget about hard drives if I really wanted to. (It would all depend on how big my Maintain database would become)
  
 Here is a script for a clean install on Debian, with little to no bloat. I've used the new Debian sarge netinstall CD. The CD itself isn't a huge download (only about 100+MB) as most of the packages are apt-got . After the install, you should be connected to the internet for apt-get packages.
  
 Here's the script. Even if you don't use it, you can see how to build the system by hand if you wish on other Linux/Unixes. It won't set up MySQL automatically yet, but maybe that's something I can work on.
  
 NOTE: You don't actually need to install a DNS or DHCP server on your Maintain box (DJB's TinyDNS, BIND or DHCPD-3). I've just done it this way for ease of installation should you want them on board. I've assumed you want DJB's TinyDNS and DHCPD-3. You may want to edit the script to skip out installing DJB tools and DHCPD-3 depending on your network. (Note: If you are not sure how to set up your network yet, see the section on "Maintain and your network" below)
  
  
 ******************
  ----
 {noformat}
 #!/bin/bash
 ############################################################
 #
 #Installer for maintain. You will need a newly installed base Debian system
 #with a connection to a debian ftp site for apt-get updates
 #The Debian sarge net-installer CD is recommended.
 #Also, you will need source tarballs of the DJB tools
 #(If you intend putting a DNS server on your Maintain server)
 #
 #daemontools-0.76.tar.gz
 #ucspi-tcp-0.88.tar.gz
 #djbdns-1.05.tar.gz
 #...as well as a source tarball of maintain as well (of course!)
 #
 #Check out the settings below and update them as necessary.
 #
 #Config MySQL to run at boot.
 #Make sure you are in the directory you are running this script from
 #or you will find that the install may go haywire.
 #Also don't try and tee or redirect stdoutput - ncurses screens don't like
 #that very much, and you will make them angry and not want to talk to you.
 #
 ####SETTINGS#################################################
 #CHANGE THIS TO THE VERSION OF MAINTAIN YOU ARE UNTARBALLING
 vershon=2.4.2
 #CHANGE THIS TO THE DIRECTORY YOU WANT /maintain TO GO INTO
 instawl=/data
 ###########################################################
  
 #where you are running this script
 parth=`pwd`
  
 #message
 echo "This installer will set up a base Debian install with maintain with"
 echo "all the needed packages."
 echo "Apt-get will be started, so you'd better have it configured properly"
 echo "or this installer will bomb out."
 echo "Maintain will appear in $instawl/maintain."
 echo "Hold on to your hats folks......."
  
 #apt-get needed packages
  
 #gcc and make just to install djb tarballs
 apt-get -y install gcc
 apt-get -y install make
 #other packages maintain needs
 apt-get -y install mysql-server
 apt-get -y install mysql-client
 apt-get -y install apache-ssl
 apt-get -y install php4
 apt-get -y install php4-cgi
 apt-get -y install php4-ldap
 apt-get -y install php4-mysql
 apt-get -y install libapache-mod-php4
 apt-get -y install rsync
 apt-get -y install ssh
 #comment out dhcp3-server if you don't want it
 apt-get -y install dhcp3-server
  
 # start work unpacking the djb tools
 # Comment this section out if you don't want/need it
 #######################################################
  
 #first unpack and install daemontools
 mkdir -p /package
 chmod 1755 /package
 cp daemontools-0.76.tar.gz /package
 cd /package
 tar -xzvf daemontools-0.76.tar.gz
 cd admin/daemontools-0.76
 chmod 1755 package
 package/install
 cd $parth
  
 #second set up uscpi-tcp
 tar -xzvf ucspi-tcp-0.88.tar.gz
 cd ucspi-tcp-0.88
 make
 make setup check
 cd $parth
  
 #lastly we can now install djbdns
 tar -xzvf djbdns-1.05.tar.gz
 cd djbdns-1.05
 make
 make setup check
 cd $parth
  
 #########################################################
  
 #Now to get maintain installed
 #First create dir if it doesn't exist
 if [ ! -d $instawl ]
 then
  mkdir "$instawl"
 fi
  
 cp maintain-"$vershon".tar.gz $instawl
 cd $instawl
 tar -xzvf maintain-"$vershon".tar.gz
 ln -s maintain-"$vershon" maintain
  
 echo "OK, looks like everything is ready. Initializing config files."
  
 cd maintain
 cd config
 cp maintain.cfg.dist maintain.cfg
 cd ../modules
 cp modules.php.dist modules.php
 cd ../build/templates/dhcp
 cp dhcpd.conf.header.dist dhcpd.conf.header
 cp dhcpd.conf.footer.dist dhcpd.conf.footer
 cp dhcpd.conf.primary.dist dhcpd.conf.primary
 cp dhcpd.conf.secondary.dist dhcpd.conf.secondary
  
 cd "$instawl"/maintain/lib/perl/Local/Maintain
 perl Makefile.PL
 make
  
 cd "$instawl"
  
 echo "OK, looks like I'm done. Removing gcc and make for security."
  
 # remove make and gcc
 apt-get -y remove make
 apt-get -y remove gcc
  
 echo "All done."
 {noformat}
  
 ********************
  
 h3. MySQL SETUP
  
 For those novice sysadmin's that have no idea about how to set up MySQL, here's help:-
  
 First, log in root to mySQL
  
 {noformat}
 # mysql -u root mysql
 {noformat}
  
 and create a user for maintain. Replace <password> with your own user password for user "maintain".
  
 {noformat}
 mysql> GRANT ALL PRIVILEGES ON *.* TO 'maintain'@'localhost'
  > IDENTIFIED BY '<password>';
 {noformat}
  
 and then exit MySQL
  
 {noformat}
 mysql> exit
 {noformat}
  
 Log in again, but this time as user "maintain". Enter your password when prompted.
  
 {noformat}
 # mysql -u maintain -p
 Enter Password:
 {noformat}
  
 now you create the database maintain will use. Replace <tablename> with your own table name (I've unoriginally called mine "maintain")
 {noformat}
 mysql> create database <tablename>;
 {noformat}
  
 exit mysql again
  
 {noformat}
 mysql> exit
 {noformat}
  
 And now here's where we get the maintain.sql script and slug it into MySQL for use.
 Replace <tablename> with the tablename you gave.
 Replace $<prefix> with the directory on maintain. By default it is /data/maintain. Once again, you will be asked for your maintain MySQL password.
  
 {noformat}
 # mysql -u maintain -p <tablename> < $<prefix>/install/sql/maintain.sql
 Enter Password:
 {noformat}
  
 My install command looked a little like this:-
  
 {noformat}
 # mysql -u maintain -p maintain < /data/maintain/install/sql/maintain.sql
 {noformat}
  
 And there you have it. MySQL is setup and ready for use by maintain.
  
 A now a little tip which might come in handy. If you ever need to manually tweak the MySQL database for Maintain, you can always apt-get install mysqlcc. It is a multiplatform graphical tool (requiring X-Windows on Debian) to help you edit MySQL databases. It is very simple to start up and use immediately.
  
 h3. PHP TWEAKING
  
 Before you can bring up Maintain over a web browser, there are a few settings that need to be checked in relation to how PHP is used. Please note that this follows on my original Debian install, so if you've used my script on a Debian system fresh install, then this applies directly to you.
  
 First of all, you have to go to /etc/php4/apache, and there you will find a file called php.ini
  
 {noformat}
 # cd /etc/php4/apache
 {noformat}
  
 Then it's just a case of opening php.ini with the vi editor and making a small change.
  
 {noformat}
 # vi php.ini
 {noformat}
  
 Now, go down about half-way though this configuration file until you get to a section labelled "Dynamic extensions". You will see the following a bit below that, which looks like this:-
  
 {noformat}
 ;Example lines:
  
 ;extension=mysql.so
 ;extension=gd.so
 {noformat}
  
 Here, uncomment the semi-colon from "extension=mysql.so"
  
 {noformat}
 ;Example lines:
  
 extension=mysql.so
 ;extension=gd.so
 {noformat}
  
 PHP should now have no troubles accessing MySQL required for maintain.
  
 h3. APACHE-SSL SETUP
  
 While it's recommended to run Maintain using Apache-ssl, you don't have to. It is recommended that you DO use SSL because you really don't want someone messing with your DNS and DHCP tables after your maintain password goes over the net in ASCII text. Fortunately, apache-ssl is a nice apt-gettable package in debian which takes a lot of the work out of it for you.
  
 To get Apache-ssl to work properly, it needs to know which directory the maintain php files are in. If you're using the default maintain directory of /data/maintain, then these files are in /data/maintain/docs.
  
 In order to see maintain in your browser, you'll need to tell Apache where maintain's web files are. That's done by editing the "DocumentRoot" directive in the httpd.conf configuration file. You'll find the DocumentRoot directive in /etc/apache-ssl/httpd.conf
  
 {noformat}
 # cd /etc/apache-ssl
 {noformat}
  
 In this directory is a file called httpd.conf.
 Open the file "httpd.conf" with the vi editor.
  
 {noformat}
 # vi httpd.conf
 {noformat}
  
 ...and you'll see DocumentRoot some way down in the configuration file.
 You edit that accordingly to the docs directory inside your maintain directory... (which would be /data/maintain/docs, if you're using the default maintain directory)
  
 {noformat}
 DocumentRoot /data/maintain/docs
 {noformat}
  
 Not finished quite yet. There's an alias in the default Debian apache-ssl that will prevent the maintain gifs from showing up. Look in httpd.conf and go down until you see a section starting with <IfModule mod_alias.c>. In there you should see :-
  
 {noformat}
 Alias /images/ /usr/share/images
 {noformat}
  
 Just edit this line so that the "/images/" alias is something else (Maintain wants /images to point to /data/maintain/docs/images, NOT way out in /usr/share/images).
 For example, I made this edit:-
  
 {noformat}
 Alias /img/ /usr/share/images
 {noformat}
  
 Problem solved.
  
 Now save the edited httpd.conf file with :wq! as you normally do with vi.
 Restarting apache-ssl is done via the init.d start script:
  
 {noformat}
 # /etc/init.d/apache-ssl restart
 {noformat}
  
 Nearly finished. There's one more thing that needs to be done before maintain will show up in a web browser.
 Go to your maintain directory's "docs" directory (this will have the same full path as what you supplied in DocumentRoot). Show the directory with ls, and you will see a file called "update.php". This file needs to be wiped in order for maintain to be viewable.
  
 {noformat}
 # rm update.php
 {noformat}
  
 Now for some troubleshooting. Make sure of the following before you access Maintain for the first time.
  
 * You have edited the maintain.cfg file (otherwise you'll get an error because it can't be read - or a number of other weird happenings). Especially ensure that the "prefix" and "web_path" directives are set properly, and that the MySQL username and password are set in the config file.
 * You have done MySQL setup and put the MySQL password for maintain in the maintain.cfg file (or you'll get a MySQL error and won't be able to log in)
 * Make sure that /data/maintain/docs is owned by "maintain" or some other non-privileged account. (or you'll get a "Forbidden" error as you try to connect to maintain). Try "chown -R maintain:maintain data" to fix this... you need to make sure that the /data directory is owned by "maintain" including all the subdirs.
 * Make sure that you are accessing maintain with https:// (or you won't be able to connect to Apache-ssl, as it expects TCP port 443, NOT port 80)
  
 h3. MAINTAIN AND YOUR NETWORK
  
 At this point you should be able to log into Maintain easily to make your various DNS/DHCP server configurations (more on that later). However, while all your editing work is saved in the database, Maintain still needs to build DNS and DHCP configuration files and push those to the appropriate DHCP/DNS servers.
  
 *At the time of writing, Maintain is not very good at building BIND configuration files. It generates TinyDNS configuration files very well though, so if you're actually going to deploy Maintain you will need TinyDNS somewhere on your network (or on your Maintain server). If you absolutely need to use BIND on your network somewhere, then you should install DJBDNS on your maintain server and zone transfer the data to your BIND servers.*
  
 Most likely, you will use Maintain to generate configuration files, and then have Maintain push these files over to your respective DNS servers. In most organisations (of any worth), there should be two DNS servers for this exact purpose. A primary and a secondary DNS slave server should be available to publish internal DNS addresses of your organisation.
 (If you find some place with a dedicated tertiary DNS server, shoot the sys-admin there - unless it's YOU!).
  
 How you set Maintain and your DNS DHCP management is entirely up to you, your requirements, and your network configuration (check out the "README.design" file).
  
 First method to consider when setting up Maintain is the "Stealth Primary" method suggested by the README.design file. This is probably the most "hassle free" way of running Maintain. All Maintain does is generate the configs, and then these are copied out and over to your primary DNS server (from where they are zone-transferred and backed up to your secondary DNS server). At the moment, the only way you'll get away with using this configuration is if your DNS name servers are running TinyDNS.
  
 {noformat}
  (Maintain) ---(rsync+ssh:configs)---> (NS1)<----->(NS2)
 {noformat}
  
 In this situation, all Maintain needs to do is generate config files, and then have them transferred automatically and regularly to your DNS servers. If you don't know how to set up file transfer via rsync+ssh, then there are some good sites on the internet for explaining this in detail. Rsync is a valuable tool which any good sysadmin should know all about (if not, get thee to a howto page!). You will then need to have your DNS server updated to reflect the config changes automatically.
  
 It is also possible to generate DNS config files and have them slotted into a DNS server which Maintain will run on it's own hardware. This way, you can zone transfer DNS information across to your name servers. It may be easier to do things this way, otherwise you may end up having to restart your DNS server to re-read new config files, as in the above example, all the time. Until BIND gets better support in Maintain, this configuration is essential if your current name servers are running on BIND, and you are migrating to Maintain (and away from Lucent's QIP, for example).
  
 {noformat}
  (Maintain+TinyDNS) ---(zone transfer)---> (NS1)<----->(NS2)
 {noformat}
  
 Another option is to have Maintain live on your Primary DNS server. This too, is quite a possible solution. You will also have more control over how Maintain interacts with your server (if Maintain gets updated to do this in future). However, the down side of doing things this way is the potential security risk, and the extra load on your Primary DNS.
  
 {noformat}
  (Maintain+NS1) <--------> (NS2)
 {noformat}
  
 It IS possible (if you are so inclined) to have your Maintain server become a one-stop DHCP/DNS management console. That is, to have Maintain, MySQL, Apache-ssl, DHCPD3, and your choice of DJB's TinyDNS or BIND all running from the one server - taking DHCP requests, acting as a DNS server, and allowing access for admins to the Maintain WebGUI.
  
 {noformat}
  (Maintain+DNS+DHCP) --> NETWORK
 {noformat}
  
 ...but what are we thinking, right? That's crazy in an environment where you are managing thousands upon thousands of host computers. You'll most likely turn your server into a toaster with all the requests!
  
 Of course, keep in mind what kind of software runs your primary DNS server (TinyDNS or BIND), because you will need to generate configuration files to match your server. The kind of DNS server configs you use are registered in Maintain's "maintain.cfg" file (either tinydns or named.conf).
 The resulting configs can be found in Maintain's "build" subdirectory. What you do with those configs from there is up to you.
  
 h3. UNDERSTANDING MAINTAIN
  
 To the uninitiated network admin, creating DNS and DHCP records in Maintain is actually fairly complicated. I'll try and break down the use of the GUI into a format which is easily understood.
  
 First of all, to produce a functional DNS/DHCP database you have to understand the various management terms, what they do, and in what order you manage them.
  
 *First of all, at the top of the heirarchy, we have the concept of ZONES:-*
 ZONES are purely administrative groups (in fact, I think they should be called administrative groups, otherwise you'd get confused with ISC BIND zones).
 All ZONES do is to limit access to users in relation to DOMAINS and blocks of IP adresses. If there is only one person who will be using the Maintain GUI in your organisation (such as in mine), then it is quite OK to only create one ZONE and leave it at that. If, however, many users will be adjusting domains and IP adresses in Maintain, it may make sense to create a number of ZONES and user accounts.
 As ZONEs are simply for Maintain's administrative purposes, ZONE info does not have any influence on the DNS/DHCP configuration building process AT ALL.
  
 *After you have your first ZONE, you need to set up your DOMAINS:-*
 A DOMAIN will name your internal addresses to the network. (In BIND, DOMAINS are called "zones", if that helps you understand better.)
 There are two types of DOMAINS. Master Domains will contain Start of Authority (SOA) data. Other domains may not. An example domain name would be *domainname.institution.com*
 You will also have the ability to assign a DOMAIN to a ZONE (for administrative purposes). Just like in BIND, DOMAINS can also be reverse lookup zones.
  
 *After you have defined your DOMAINS, you should register IP BLOCKS for them:-*
 IP BLOCKS simply define an area of IP space which Maintain will use and determine IP space which you will place SUBNETS into. You have quite a bit of freedom when it comes to making IP BLOCKS, but for administrative purposes, it is perhaps a good idea to make several IP BLOCKS for your DOMAINS from which you can manage your SUBNETS. IP BLOCKS really only have administrative meaning, and the names given to IP BLOCKS do not show up on any configuration file that Maintain builds. However, IP BLOCKS do determine what SUBNETS are allowed, and SUBNETS of course carry some weight in the configuration file building process.
  
 *Once IP BLOCKS have been made, you can think about SUBNETS:-*
 SUBNETS follow the standard rules about subnetting IPv4 networks you learnt when you did your CCNA. You need to calculate appropriate network IPs and subnet masks which you intend to use. You may only create subnets inside IP BLOCKS. SUBNETS have a rather large influence on the config files that Maintain builds, especially in DHCP configurations.
  
 *You can then break up SUBNETS into IP RANGES:-*
 IP ranges only really have administrative influence in Maintain. They will allow you to define a range of IPs within a SUBNET and define how they are to be used. You could, for example, split up a SUBNET so that half of the IP addresses are Static, and the rest controlled under DHCP. Another function of an IP RANGE is to define which administrative ZONES and DNS DOMAINS these hosts are linked to.
  
 *Finally, at the lowest point in the chain, we have HOSTS, CNAMES, MX RECORDS, FORWARD/REVERSE POINTERS:-*
 This should be self explanatory. Each host can be defined seperately to your needs as per your network design. If you like, you can add quite a lot of information to the database about each and every one of your hosts. This is where the underlying databse in Maintain will really help your system administration. CNAMES will of course provide alias names for your hosts, and MX records will define where your mail servers are.
  
 For good planning, it may help you to think about your DNS/DHCP database in terms of a tree. The diagram below assumes centralized administration.
  
 {noformat}
 ZONE----+
  |
  DOMAIN-----+
  | IP BLOCK-----+
  | | SUBNET----+
  | | | IP RANGE-----+
  | | | HOSTS
  | | |
  | | SUBNET----+
  | | IP RANGE-----+
  | | | HOSTS
  | | |
  | | IP RANGE-----+
  | | HOSTS
  | |
  | IP BLOCK-----+
  | SUBNET----+
  | IP RANGE-----+
  | HOSTS
  |
  DOMAIN-----+
  IP BLOCK-----+
  SUBNET----+
  | IP RANGE-----+
  | HOSTS
  |
  SUBNET----+
  IP RANGE-----+
  HOSTS
 {noformat}
  
 More on VLANs and WORKGROUPS to come.....
  
Site powered by a free Open Source Project / Non-profit License (more) of Confluence - the Enterprise wiki.
Learn more or evaluate Confluence for your organisation.
Powered by Atlassian Confluence, the Enterprise Wiki. (Version: 2.2.7 Build:#524 Jul 28, 2006) - Bug/feature request - Contact Administrators