• Configuration area (config.inc.php file) ends up in /srv/www/htdocs/phpMyAdmin along with the rest of the installation.
• Decided to use “cookie based authentication”; don’t think I need to remember the password.
• The advanced features were turned on in config.sample.inc.php, but the YaST installer doesn’t load the schema required for this into the mySQL database (maybe it’s not possible unless done during mySQL installation). This resulted in endless error messages of “Table ‘phpmyadmin.pma_bookmark’ doesn’t exist”.
• Learned that I needed to run create_tables.sql, which was not included in the openSUSE package. I downloaded it from the phpMyAdmin site, created user “pma”, defined corresponding controluser and controlpass entries in the config file. create_tables finally ran successfully and the bookmarks error messages went away.
• Stopped annoying half-hour auto-logout with: $cfg['LoginCookieValidity'] = 3600 * 8;

• YaST, System, sysconfig editor, cron – edits various configuration parameters stored in the /etc/sysconfig/cron file (this file can also be edited directly).
• YaST, System, System Services – turn the cron service on/off here.
• /etc/crontab, /etc/cron.d/*, /var/spool/cron/tab/<userid> – these files all use the format described in the crontab 5 man page. My as-installed configuration has one line in /etc/crontab that calls run-crons every 15 minutes (*/15). All of the other directories were empty. Also, the one line starts with a dash, a special feature for root that prevents sending a message to the syslog file.
• /usr/lib/cron/run-crons – shell script called by the default /etc/crontab entry. run-crons runs all pending shell scripts in the /etc/cron.* sub-directories. This is an extensive script containing the logic to handle systems that don’t run 24×7.
• /etc/cron.{hourly, daily, weekly, monthly} – these directories contain bash scripts, not crontab-format files.

As installed, /etc/crontab runs dailies within the first 15 minutes after rebooting and every 24 hours thereafter. If one has the misfortune to get that first run during work hours, cron will continue to run the dailies every day at that time! The daily tasks have a lot of system-wide finds (core files, locate, beagle, etc) that consume 100% of the cpu. This annoyed me frequently in my SUSE 10.0 days.

From reading the run-crons code, I found out about the DAILY_TIME parameter in /etc/sysconfig. If this is set, cron runs the daily tasks only during the hour specified. The trade-off is that the computer must be running at DAILY_TIME (but if not, cron will run daily tasks anyway after MAX_NOT_RUN days). The weekly and monthly tasks aren’t controlled by DAILY_TIME, so I guess if I reboot one minute after noon, weekly and monthly tasks will run at 12:15 pm thereafter.

To try all this out, I set DAILY_TIME to 14:00 and changed the /etc/crontab minutes parameter to 22,52, and will expect to see activity each day at 2:22 pm.

A nice extension would be a WORK_DAY parameter; a time span during which cron would avoid running any of the periodic tasks. This would retain cron’s ability to run tasks within the first 15 minutes after a reboot, so long as it didn’t occur during work hours.

My happiness with openSUSE 10.2 disappears when the Zen Updater runs. Every time it starts, does an update, restarts, etc, update-status (a compiled 64-bit executable, not a Perl or Python script) runs for 5-7 minutes with 99% cpu usage.

Others have complained about this problem, so it’s not just my installation. When I first wrote this, I had a couple of angry paragraphs about the ills of ZENworks and zmd. Since then, I located a more well-reasoned critique of ZENworks (complete with screen shots). It reviews openSUSE 10.1, but most everything still applies.

I started YaST, Software, Online Update Configuration. This turns out to be a canned task that accepts no user input and assigns you randomly to a SUSE update repository each time it runs. So I was moved from utah.edu to somewhere else (with a couple 6 minute update-status runs thrown in).

How shall I deal with ZENworks? First I read an article in SUSEWiki.org on Adding YaST Sources. This discussed how to use a local ISO file instead of the installation CD as the main package catalog, and pointed out a second, YaST update configuration screen: YaST, Software, Installation Source. This is the familiar YaST interface that allows one to configure all package and update repository catalogs.

A log of the various steps I tried (long and tedious, scroll down to the Conclusions):

• YaST, Software, Installation Source.
• Add, Media Type -> Local Directory.
• I checked the ISO image box, browsed to my new /iso directory where I had placed the 10.2 ISO image.
• YaST scanned the image and a new “Configured Software Catalog” appeared.
• To test, I turned the Status Source Setting to Off for the DVD, left the “Synchronize with ZENworks option turned on, and clicked Finish.
• A “synchronizing with ZENworks” info box appeared, so off to the kitchen for a snack during a few minutes of parse-metadata followed by another 6 minutes of update-status.
• Started YaST, Software, Online Update (called YOU in SUSE 10). It suggested an update to Firefox 1.5.0.9, which I new was wrong because openSUSE 10.2 is on 2.0. Where did the problem come from: using YOU, or the ZEN reconfig that switched repositories?
• Installation Source GUI confirms my ISO catalog and the osuosl.org update catalog are both 10.2. Software Management GUI shows the correct version of Firefox currently installed.
• Noticed in the ZEN Software Updater, Configure, that one of the catalogs I had deleted with YaST still appeared. I removed it here also, and the process took only a few seconds! Something is different with update-status.
• Lots of changes through two separate interfaces, so let’s reboot … update-status ran less than 2 min, but both zen-updater and YOU don’t present the correct pending updates.
• Tar file of /var/lib/rpm, then rpm –initdb; rpm –rebuilddb to see if rebuilding the RPM database would fix things. The dates on the DB files were no different upon completion.
• Hid the files, re-ran rpm, no new rpm databases appeared. Apparently rebuilddb is no longer functional. Replaced the files, now YaST Software Management looks normal again. ZEN’s database seems to be in /var/lib/zypp.
• Perhaps the ZEN Management Daemon (zmd) is responsible. Crossing my fingers, I ran Online Update Configuration again. update-status completed in less than a minute. ZEN failed, saying that it had updated YaST (ftp.ale.org this time) but could not update ZEN. Indeed ZEN still retains the old update repository.
• Started YOU, and the correct updates appear!
• Accepted all updates, and they installed correctly, even the Nokia one that had choked ZEN, starting this problem in the first place. Also, new dates have appeared on all of the /var/lib/rpm database files, so they are apparently okay.
• Read some Novell instructions and decided to add a third party repository packman.unixheads.com/suse/10.2 which now appears as a YUM repository. This triggered “synchronizing with ZENworks”; let’s see if the YUM update repository gets fixed.
• The ZEN updater is now showing the exclamation point. It wants to update a bunch of packages that I don’t have installed, packages from packman apparently. I guess it thinks this is the update repository. I turned off packman in the configure screen.
• update-status ran 3 minutes with packman added. So it appears that nothing was wrong with my system: ZEN is just cpu intensive.
• YaST, Software Management now shows ksensor, which I know is from packman. Installation was successful.
• YaST Online Updater is currently working fine with one update catalog and ZEN now presents only the local ISO catalog. Bad news. Options:
  • Keep re-running YaST Online Update Configuration until ZEN installs a catalog that both it and YaST accept. But I’m worried that I’ve broken ZEN somehow and it won’t accept any catalog.
  • Switch the panel updater applet from ZEN to YaST (an earlier post describes the controlling /etc/sysconfig option). Does this also turn off zmd?
  • Make no changes. See if the ZEN applet shows new updates. If not, periodically run YOU to check. Take further action in the event that YOU shows updates and ZEN does not.
• I don’t know what process updates the rpm database and since rpm –rebuilddb was shown to have no effect, I’d better make sure to make a copy of the database before doing anything risky.

Conclusions:

• ZEN processes (zmd, parse-metadata, update-status) are cpu intensive. With no progress bar or feedback of any kind in zen-updater to show concerned users what’s happening, it’s easy to think “infinite loop” when cpu times skyrocket. But it’s probably just a catalog that takes a long time to process.
• ZEN’s configuration of and interaction with YUM update catalogs is fragile. Running YaST, Online Update Configuration to assign a different update catalog is a good option to solve unexplained updater failures and error messages. Sometimes it must be run more than once. Consider it a ZEN reboot.

Current Status:

• Both YaST and ZEN have accepted the switch from the DVD to the local ISO file that I installed. So I won’t ever need to load the DVD again. Excellent – will add this step to my Linux upgrade checklist.
• I now better understand the repositories and DVDs. The retail package DVD (which is double layer) contains noarch, i586, and x86_64 packages for both oss and non-oss. My downloaded ISO DVD image is missing i586 packages. Online repositories have all architectures, but are split between oss and non-oss. I need a source for oss and non-oss i586 packages. Options:
  • Add two online i586 repositories. But update-status run times might return to 6 minutes.
  • Download the i586 DVD ISO image and install that locally.
• Re-ran YaST Online Update Configuration, ZEN installed mirrors.usc.edu successfully such that both zen-updater and opensuseupdater report the same updates.
• Switched the panel updater applet (/etc/sysconfig/sw_management) from the zlm (zen-updater) update manager to opensuse. The SUSE updater now appears (but only in KDE because the updater applet is part of KDE).
• My updating process now looks like it did in SUSE 10.0: the GUI that resembles the package installer with the detailed progress log above and the double progress bars at the bottom. I left the “sync with ZEN” option turned on.

Other information related to package updating:

• Offical openSUSE pages: Using the ZEN Updater, Package Repositories.
• From a LinuxQuestions.org post:
  

  – only common lib is libzypp. For example I deleted all zmd/mono/rug (with exception of single libzypp) and I am using Yast/smart only.
  - rpm db is common to all package managers otherwise eat time you would use different PM different installed/not installed packages would be shown.

• The SMART Package Updater was recommended by a forum post, but a detailed, multi-step installation process and co-existence with ZEN are concerns.
• The Package Management Category at SUSEWiki.org is the source for several of the above links. Other links on Finding RPMs and Package Database Management might be helpful.

YaST isn’t good at all facets of Apache configuration so some editing of conf files may eventually be needed. If manual editing is required, why not use it exclusively? Because once you go manual, you can’t switch back to YaST when major changes are needed. I like the fact that if I install a new web application that needs several additional Apache modules, I can use YaST to enable them in a couple of minutes, often without having to learn anything about them.

I also like the fact that using YaST to configure Apache will give me a configuration closely matched to thousands of other openSUSE Apache servers. This makes it likely that I will get a functional, robust httpd set up at the start. Then I can incrementally add modules and customizations as needed, testing as I go.

Following is a YaST-based recipe to install a straightforward httpd configuration with Perl, PHP, and mod_userdir enabled. Subversion, WebDAV, and virtual host support are also added (using some conf file editing). Finally, the added bookkeeping steps that allow YaST and hand-edited conf files to co-exist are presented.

Part I: Content-Independent Configuration

Part 1 installs a functional (but empty) httpd server with all modules and parameters properly configured. Connections to the site-specific content are discussed in Part 2.

1. OpenSUSE scatters Apache conf files among /etc/apache2 and its conf.d, sysconfig.d and vhosts.d sub-directories. Keep a copy of the original conf files to determine what YaST has done and add source code control repositories to manage manually edited files:
   • cd /etc/apache2
   • mkdir ORIG; cp -p *.conf ORIG
   • mkdir RCS
   • Repeat for the three “.d” subdirectories.
2. Start YaST/ Network Services/ HTTP Server:
   • Turn on php, perl, python and/or ruby in a special configuration page that only appears once (one can still turn these on/off later, but it’s easier to do here).
   • Accept defaults in the Server Wizard (5 pages), except choose Start When Booting on page 5.
   • Click Advanced Configuration.
   • In the Server Modules tab, enable dav, dav_fs, info, rewrite and status.
   • Needed to Add Module for dav_svn but the YaST screen would not accept input, so I hit Finish (will add in Step 3).
     
   • The server starts. http://localhost just says “It works!” instead of the normal Apache welcome page. Didn’t like this so I copied index.html from an old SUSE 10.0 installation.
   • Read the comments in all of the /etc/apache2/conf.d/*.conf files, some of which are controlled by IfDefine blocks. For my installation, I learned I needed to add the SVN_DOC and SVN_VIEWCVS flags (next step).
3. Start YaST/ System/ sysconfig Editor:
   • Select Network, WWW, Apache2.
   • Highlight APACHE_MODULES. Add dav_svn into the Modules line. Note: Don’t hand-edit dav_svn into /etc/apache2/sysconfig.d/loadmodule.conf, as YaST will just remove it next time it runs.
   • Highlight APACHE_SERVER_FLAGS. Type “SVN_DOC SVN_VIEWCVS” into the text field.
   • Finish.
4. A diff of ORIG/default-server.conf with the one YaST created shows that YaST removed the mod_userdir section, changed indents, and added ServerName and ServerAdmin. Thus I chose the original distribution .conf as my starting point:
   • mv default-server.conf{,.YAST}
   • cp ORIG/default-server.conf .

   • ci -l default-server.conf
   • Edit with a text editor and copy the ServerName and ServerAdmin directives from the YaST version into default-server.conf.
   • ci -l default-server.conf
5. Restart YaST/ Network Services/ HTTP Server:
   • Select the Server Modules tab and verify that the dav_svn module appears.
   • Exit or Abort.
   • Note: from this point forward, if YaST/HTTP Server is re-run and Finish is clicked, default-server.conf and /etc/sysconfig/apache2 will be overwritten. Capture a snapshot before running or retrieve original from RCS archive afterward.
6. Check the syntax of all configuration files and reload httpd:
   rcapache2 restart-hup
7. Browse http://localhost/server-info and server-status. Verify all desired modules are present and running.
8. Browse //localhost/manual and localhost/svn-manual to see documentation.

The content-independent phase of installation is complete.

Part II: Serving Local Site Content

To prepare for Part 2, load all content files that are outside of the server document root (e.g. Subversion repositories, WebDAV directories, and user public_html areas). I keep my Subversion repositories under /home/wwwrun/svn, giving them the same owner and group as the httpd process.

1. Verify that browsing a http://localhost/~<username> directory works.
2. Subversion repository configuration goes in the /etc/apache2/conf.d/subversion.conf file. I piggybacked the WebDAV configuration into this file rather than creating a separate file: subversion.conf. Also, I add Basic Auth to ViewVC in subversion.viewvc.conf (see earlier blog entry for an explanation).
3. Use htpasswd2 to create the basic authentication password file.
4. Create a /var/lock/apache2 directory (user wwwrun, group www).
5. rcapache2 configtest
6. rcapache2 restart-hup
7. Browse http://localhost/svn/<reponame>. Username and password are requested and the repository appears. Run RapidSVN from a Windows machine to verify connectivity.
8. Edit /srv/viewvc/viewvc.conf to add root or root_parents, default root, and mailto.
9. Browse http://localhost/viewvc , username and password are requested, then the ViewVC page appears. Click on the “ViewVC Help” hyperlink and the documentation appears.
10. Using Konqueror, browse webdav://localhost/fs and a folder view of the WebDAV folder appears.
11. See this blog entry for details of connecting to WebDAV via WindowsXP.

All of my local Subversion, WebDAV, and web page content is now available via Apache.

Part III: Virtual Hosts

Finally I’ll add virtual hosts for my various development, prototype, and staging areas. The YaST HTTP Server GUI offers a screen to do this, but I chose to start with the as-delivered file just as with default-server.conf.

1. Create a new conf file in /etc/apache2/vhosts.d (e.g. LLvhost.conf in my case). I copied the vhost.template as the starting point.
2. I defined four virtual servers:
   • localhost – contains only a ServerName statement to serve as the default server.
   • llxxx – three name-based servers that have document roots in various code development sub-directories. Each of these gets a separate set of error and access log files.
3. Uncomment the NameVirtualHost *:80 line in /etc/apache2/listen.conf.
4. Add the three name-based server names to /etc/hosts as synonyms for localhost.
5. rcapache2 configtest
6. rcapache2 restart-hup
7. Browse http://llxxx and the virtual host content appears. Verify that log information appears in the correct file pair in /var/log/apache2.

Part IV: Configuration Control and Maintenance

The Apache server installation is now complete. But adding source code control is necessary to safely re-run YaST/ Network Services/ HTTP Server Configuration in the future. Whenever HTTP Server Configuration is ended with Save or Finish, any of the conf files may be overwritten, obliterating prior manual edits. Source code control allows us to manage and resolve this conflict.

Using the unaltered conf files in the ORIG directories as references, perform a diff of all of the conf files to learn which have been customized. Any altered conf files that were hand-edited should be placed under configuration control (e.g. CVS, Subversion, RCS). Consider controlling the YaST-altered files as well.

I maintain five files in RCS: default-server.conf, mod_userdir.conf, subversion.conf, subversion.viewvc.conf, LLvhost.conf. After saving any new HTTP Server Configuration session, I use rcsdiff to learn what changes have been made to these files. Review the changes and either restore the last version from RCS or check in a new revision as appropriate.