Configuration checklist for a newly created KDE login under openSUSE 10.2, installed with a 1600×1200 display.

Personal Settings (formerly KDE Control Center):

• Appearance & Themes, Fonts: fonts all size 10, except Desktop, was 11 now 10. In the past, KDE has changed these on me when I plugged in a new monitor and rebooted.
• A & T, Icons, Advanced: Desktop & file manager was 48, now 32. Toolbar and Main Toolbar is 22; tried 32 & 48 but nothing looked different.
• A & T, Icons: (TBD) root’s KMenu icons are much smaller than other users; yet no parameter causes the KMenu icons to change size. How do I control these?
• A & T, Launch Feedback: was Bouncing Cursor 30 sec, now Passive 15.
• A & T, Screensaver: no password, advanced Top-Left lockscreen.
• A & T, Style: is Plastik.
• A & T, Theme Mgr: current setting not highlighted, I think it is Plastik.
• Desktop, Panels: Menus tab – was SUSE style, now KDE style.
• Desktop, Window Behavior: Focus tab – follow-mouse. Moving tab – display window geometry.
• Regional, Country/Reg & Lang: Time/Dates tab – short date DD-SHORTMONTH-YY, first day Sunday. Other tab – paper format US Letter. Note: causes a system configuration update to run.

Panel & Task Bar:

• From panel context menu, Add Applet, System Monitor.
• KMenu, System, Desktop Applet, K R&R Tray (missing from panel context Applet menu) that presents all screen resolutions.
• KMenu, System, Desktop Applet, openSUSE Updater Applet. This looks like YOU (YaST online updater) from SUSE 10. This is different than the one displayed in the root acount (ZEN? who knows), for which it isn’t obvious how to add to the taskbar. After logging out and back in, the zen-updater symbol appears. Moreover, the updater applet is now missing from root’s panel.
• Add Application System Terminal Konsole.

Miscellaneous

• Konsole Settings: size 80×40, schema white on black, set as default.
• Clock Applet Configure: day of week, font size.
• I wanted a KDE applet that monitors in real-time the ACPI power-saving state of the processor. Gnome gnome-cpufreq-applet allowed me to watch my Athlon CPU frequency change between 2.2 and 1.0GHz, helping me see the effects of the various Active Schemes and Frequency Policies offered by kpowersave. 
  Finally discovered kcpufreq by Sebastian Schaffert who transplanted it from Gnome.

I configure Apache2 on openSUSE with YaST rather than editing the configuration files directly. If this is your first time installing Apache on openSUSE, I highly recommend it. YaST is a big time-saver for two aspects of Apache configuration: the initial installation and adding, enabling, and disabling server modules. A default server configuration supporting Perl and PHP can be up and running in less than an hour using YaST.

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.

After several tries and hours of frustration, I finally have a Java plugin working with Firefox under openSUSE 10.2 on my AMD Athlon (x86_64) workstation. What a pain this was. You get no Java plugin “out of the box” and I found no instructions on the openSUSE web site. I guess AMD Athlon users are still a niche group, which is surprising given how many AMD machines I see advertised.

Here’s how to get a working Firefox + Java plugin combination for openSUSE 10.2 on x86_64 machines using only YaST (the openSUSE system administration GUI) and “official” openSUSE repository sites.

Install openSUSE 10.2 from DVD. Here’s what happens:

• YaST installs Java JRE 1.5.0 x86_64 and no Java browser plug-in (Sun doesn’t support a 64 bit plug-in).
• Surf to a site that needs the plug-in (e.g. nist.time.gov) and the dreaded green jigsaw puzzle piece appears. The Mozilla plug-in finder will fail.

Using YaST/ Software/ Software Management:

The following steps replace the openSUSE-default x86_64 Firefox and Java packages with i586 32-bit versions.

• Select 64bit (x86_64) Firefox for removal, click Accept.
• Install the 32bit (i586) version, click Accept.
• Start Software Management a third time and search for Java or select Development, Languages, Java.
• Find the Java 1.5.0 plug-in, which is only available as an i586 binary (no x86_64). Upon selecting it for install, YaST will propose installing Java JRE 1.4.2 (which is also an i586 version) and removing Java JRE 1.5.0.
• Uncheck the Java 1.4.2 JRE package.
• Highlight the Java 1.5.0 package, then choose the Versions tab in the window below. The x86_64 architecture will be checked. Select the i586 variant. Go back up to the check-box for Java 1.5.0 and toggle it until the update/reinstall symbol appears (two rotating arrows).
• After confirming that the Java 1.5.0 reinstall symbol appears, the Java 1.5.0 plug-in package is checked, and the Java 1.4.2 package is not checked, click on the Check Dependencies button.
• If dependencies are okay, click Accept.
• You should now have a working Firefox + Java + Java plug-in configuration, all being i586 (32 bit) versions. I rebooted, but I don’t think that is required.

Problems:

• When I clicked Accept, the Java plug-in was installed, but the x86_64 version of Java 1.5.0 was left unchanged! Naturally the 32-bit plugin did not work with the 64-bit JRE.
• I think things would have worked fine with the retail package DVD, which is a double-layer DVD containing both i586 and x86_64 ISO images. But my downloaded installation disk has only the 64-bit ISO image.
• I fooled around with the on-line update catalogs (YaST/ Software/ Installation Source) and was finally successful in retrieving the i586 version from one of the openSUSE repositories.

I expect that a lot of Linux Athlon users want a working Java plugin and only a few need the extra performance of 64-bit Java. Thus I think that until Sun offers an x86_64 plug-in, Linux distros should make the 32-bit Java JRE the default package for the x86_64 installation.

Complaining about the difficulty of viewing and controlling the Installation & Update Source catalog settings and online updates could take another entire blog post. Visibility into what YUM is up to is reduced compared to YaST Online Update from SuSE 10.0. The main goal of these GUIs is to avoid resorting to rpm for straightforward installations, yet I seem to need rpm more with each new release, not less.

Update — openSUSE 10.3:

Early in 2008 I found a How To use Java with Firefox on 64-bit openSUSE 10.3 page on the openSUSE.org web site. Apparently openSUSE still installs 64-bit Java-less Firefox as the default (contrary to my above recommendation :-). The article first describes a torturous process of creating a parallel 32-bit installation that cannot be maintained via automatic updates. Not appealing.

But toward the end of the article an Alternate Approach section presents the six-step equivalent of my approach for 10.3. I recommend this Sun’s Java method as the best solution for 10.3. It is an interesting variant to my method in that it keeps Java 1.6 x86_64 for other applications by installing both 1.6 and 1.5, providing Firefox with a back-revision (1.5.0) of the plug-in.

It took a long time to figure out how to turn off the blinking cursor in Gvim. Here are two ways, and all of my other changes to GVim on WinXP.

" MY changes:
:color torte
set nohlsearch
set noincsearch
set shiftwidth=4
set nobackup
set noshowmatch
" Turn off blinking for the n, v, & c states:
let &guicursor = substitute(&guicursor, "n-v-c:", "n-v-c:blinkon0-", "")
" NOTE: To stop all blinking:
" let &guicursor = &guicursor . ",a:blinkon0"
The above is added to the end of the _vimrc file, avoiding any edits to mswin.vim, etc.

Here is my current Apache2 config file’s subsection for serving Subversion and WebDAV folders: default-server.conf (webdav fragment).

Comments:

• I’m using AuthType Basic for svn, viewcvs, and filesystem DAV access. It provides some security, and is also necessary for WindowsXP, which apparently will not connect to a Web Folder with no authentication.
• The viewCVS location needs its own authentication, since this tool accesses the SVN repository directly using the file: protocol. In doing so, it bypasses the http server /svn location and its associated authentication.
• The SVNParentPath is convenient because new SVN repositories can be added without editing the conf file. The downside is that different users can’t be restricted to particular repositories or given different access privileges.
• ViewCVS has an additional configuration file /srv/viewcvs/viewcvs.conf that must contain the roots of all repositories, plus a few other items.