Installation of SuSE Linux 9.0

The latest version of SuSE Linux is the most visually slick version so far. However, some of the server functions, including email and printing, had been compiled in such a way that they were prevented from working. No doubt this is an effective security measure. SuSE's installation also created a bad lilo.conf file that prevented the new system from booting.

Installation

Booted from CD and selected "Install - Safe Settings"
SuSE Linux 9.0 has the nice feature of automatically contacting a server and downloading security updates. However, after installation was finished, the graphical login screen would not let anyone log in. I was finally able to get a root terminal using a Unix trick and changed the runlevel manually to avoid SuSE's login screen.
The installation allows you to select whether to use 'lilo' or 'grub' as the boot loader. I selected lilo, which turned out to be a mistake. After installation, on the first boot, the kernel hung at LI. I had to reboot from the CD and select "boot installed system" or whatever it's called. It turned out that the installation program had created a lilo.conf file with boot=/dev/hda instead of /boot/sda1, and had assigned all the ide drives to lower BIOS numbers than the SCSI drives. Since our root partition was on /dev/sda1, the system wouldn't boot. To fix this, I changed the lines in the disk section of lilo.conf to:
disk=/dev/sda bios=0x80 disk=/dev/sdb bios=0x81 disk=/dev/sdc bios=0x82 boot = /dev/sda
and ran /sbin/lilo. Changing the relationship between the "bios" numbers and the drive names does not cause any harm, but the disk containing the root partition and boot loader must be specified in the "boot" parameter.
One feature that's needed is the ability to configure the installation and select packages beforehand on some other system, rather than on the system being upgraded. Selecting packages from the CD is very time-consuming, which means that the computer will be unavailable for several hours while you're upgrading. This inconveniences many users when you upgrade your main production server. It also inconveniences you, because your users will come in and stand around watching the installation while they repeatedly ask you when the server will come back up. Booting up from the CD should only be required when actually performing the installation.

Problems with spamassassin

Error message from Spam Assassin:

spamc[6397]: connect() to spamd at 127.0.0.1 failed, retrying (1/3): Connection refused

Solution: started /usr/sbin/spamd -d in /etc/rc.d/local

However, Spam Assassin still didn't work: the "*****SPAM*****" marking was not being added to the Subject line.

Solution: Edit /etc/mail/spamassassin/local.cf and change

# rewrite_subject 0
to

rewrite_subject 1

See linuxsetup49.html for more details on setting up spamassassin.

Fixing printing

Can't print using lprng.
Solution:

Ran checkpc -f -v and edit /etc/printcap to remove all the warnings.

cd /usr/lib
chown lp.lp lpf
chmod 0700 lpf

```
cd /var/spool/lpd/myprinter
chown lp.lp * 
```
After this, lpd was still giving this message:
Printer 'hpbw@localhost' - cannot open connection - No such file or directory
lpr -Pmyprinter@localhost worked but lpr -Pmyprinter didn't.
Solution:
Edit /etc/printcap and add this line to every printer:
:force_localhost@:\

However, Windows users still could not print because nmbd was not being started by /etc/init.d/smb. Only smbd was being started.
Start it manually

/usr/sbin/nmbd -d -s /etc/samba/smb.conf

Problem: Staircase effect is back

Text files were printed with a ``staircase'' effect for some printers but not others. This was a problem frequently seen in the old days of linux, and was caused by the print filter (lpf) being ignored. All attempts to get lpd to see the lpf filter were unsuccessful. Yast2 was able to detect the printers but deleted the printcap file without fixing anything, and trashed my sendmail configuration, Web server configuration and /etc/hosts file when it started the dreaded Suse scripts. These files had to be restored from backups.

The sendmail configuration file /etc/mail/local-host-names was also overwritten by SusE's scripts.

Solution: Download and install new lprng and change the filter line in /etc/printcap from

:if=/usr/lib/lpf:\

to

:filter=/usr/libexec/filters/lpf:\

Neither the /usr/lib/filters/lpf installed by Suse nor the hand-written script that worked previously worked with the new lprng. The /etc/printcap entry became:

peptide|lp:\ :lp=:/dev/null:\ :force_localhost:\ :rm=63.127.146.200:\ :rp=peptide:\ :sh:\ :bk: :filter=/usr/libexec/filters/lpf:\ :sd=/var/spool/lpd/peptide:\ :lf=/var/spool/lpd/peptide/errs:\ :mx#0:

Problem: Samba Windows users still can't print. Windows users got the message "Access denied, unable to connect". Edited /etc/samba/smb.conf and replaced /usr/spool/lpd with /var/spool/lpd.

Fixing sendmail

First, sendmail gave "connection refused" message in system logs; email could be sent but no mail could be received.
Solution: edited /etc/sysconfig/mail and changed
SMTPD_LISTEN_REMOTE="no"
to "yes".
Second, imap didn't work; many users got "login disabled" because imap wouldn't accept unencrypted passwords. It appears that by default, the new version of imapd no longer works. It must be removed and replaced before mail will work for Windows clients.

I downloaded a new wu-imapd. This in turn required openssl (see linuxsetup54.html and linuxsetup42.html).

Edited /etc/ld.so.conf, added /usr/ssl/lib, usr/local/lib, and /usr/lib and ran ldconfig.

I also edited /etc/xinetd.d/imap and changed every instance of disable = yes to disable = no.

Wu-imapd compiled successfully with the command line
make lsu WITH_SSL_AND_PLAINTEXT=yes
(lsu = Linux SuSE) but users still were getting "login disabled". Apparently only the
make lnx SSLTYPE=none
command creates a functional imapd; however, I could not compile it with this command or with the make slx command which the documentation suggests.

After getting a tip from a fellow linuxer, I tried
make lsu SSLTYPE=none
which worked despite giving dire error messages.

Despite all this, mail was still not working correctly. The newaliases command gave the error:

Cannot rebuild aliases: no database format defined
Cannot create database for alias file /etc/mail/aliases

To fix this, I had to install libdb from www.sleepycat.com since I couldn't find libdb on the SuSE CD.

Libdb compiled successfully with the following commands:

cd build_unix 
../dist/configure
make
make install

This put the libraries in /usr/local/BerkeleyDB.4.2/lib I added this path to /etc/ld.so.conf, copied the libs to /usr/lib, copied includes to /usr/include/db2, and reran ldconfig.

Next, I recompiled sendmail. Created a site.config.m4 file as described in linuxsetup50.html

Edited devtools/Site/site.config.m4 and added a line for DSM_CONF_SHM. The entire file looks like this:

APPENDDEF(`confMAPDEF', `-DNEWDB')dnl
APPENDDEF(`confINCDIRS', `-I/usr/include/db2')
APPENDDEF(`confLIBDIRS', `-L/usr/lib')
APPENDDEF(`confLIBS', `-ldb') 
APPENDDEF(`confENVDEF', `-DSM_CONF_SHM=0')

Then

sh Build c
sh Build install

finally produced a working sendmail with imapd access and support for email aliases and procmail.

See linuxsetup50.html for more details on setting up sendmail.

As mentioned elsewhere, the sendmail configuration file /etc/mail/local-host-names was also overwritten by one of SusE's scripts. This file should be checked everytime Yast2 is run.

Fixing netatalk (AppleTalk)

Netatalk also didn't work. Mac OS users were unable to see shared disks or their home directories.

Reinstall BerkeleyDB from www.sleepycat.com. Since libdb was needed to compile netatalk, I considered reinstalling a new netatalk. Luckily, I tried it first on another server. I could not get the new netatalk (version 1.6.4 from netatalk.sourceforge.net) to start at all on the other server. So I stayed with the SuSE version.

I verified that the disks were being exported (by simply adding the directory names on a separate line in /etc/atalk/AppleVolumes.default). However, whenever a Mac user would try to access the disk, I obtained the following error message:

afpd: cnid_open: CATASTROPHIC ERROR opening database environment /temporary/.AppleDB. Run db_recovery -c immediately
In fact, there is no such program as "db_recovery". I ran db_recover -cv several times but the error continued to occur. After considerable head-scratching, I tried deleting the .AppleDB and .AppleDouble directories in the directories accessed by Mac users. This made the files once again visible and stopped the error messages.

Apparently, the database format used by netatalk has changed since the earlier version. I also started "timelord" which is a time server for Macintosh clients.

Fixing inn news server

The news server (inn) also didn't work. Several changes have been made to the config files and database format. Read the file /usr/share/doc/packages/inn/README.linux for more information.

I edited the following config files:

/etc/news/inn.conf
/usr/lib/news/bin/makehistory -O -b says:
makehistory: /etc/news/inn.conf:13: parse error: saw string, expecting semicolon or newline
Solution:
The file format has been changed for some reason. Any parameter containing a name or spaces must now be surrounded in double quotes, e.g.:
mta: "/usr/sbin/sendmail -oi %s"
Also empty parameters must be commented out and 'L' at end of integers is prohibited.

A new entry
ovmethod: "buffindexed"
is now needed.

/etc/news/readers.conf (replaces nnrp.access)
By default this file doesn't allow anyone except localhost to connect. Uncomment one of the predefined "auth" entries and one of the predefined "access" entries and substitute your domain name for "example.com", for example

        auth "local" {
        hosts: "*.brneurosci.org, brneurosci.org"
        default: "<local>@brneurosci.org"
        } 
    
        access "local" {
        users: "<local>@brneurosci.org"
        newsgroups: "*"
        }

(The line containing "<local>" should be entered verbatim.)

/etc/news/storage.conf
This file can be left unchanged from the default

        method tradspool {
            newsgroups: *
            class: 1
        }

/etc/news/newsfeeds
Add an entry for controlchan

controlchan!:!*,control,control.*,!control.cancel\
        :Tc,Wnsm:/usr/lib/news/bin/controlchan

and remove the entry for overview.

/etc/news/incoming.conf, /etc/news/expire.ctl, and /etc/news/control.ctl can be left unchanged if you have a previous working version.

Once everything is configured (see linuxsetup32.html for more details), start inn with

/etc/init.d/inn start
It will say:

innd: buffindexed: file '/var/spool/news/overview/OV1' does not exist, ignoring '0' innd: SERVER cant open overview method
To fix this error, I did the following:

Make sure the paths in /etc/news/buffindexed.conf correspond to the actual news directory.

Create the overview/OV1 and OV2 files. If /etc/news/buffindexed.conf says

0:/var/spool/news/overview/OV1:1536000
         1:/var/spool/news/overview/OV2:1536000

use

dd if=/dev/zero of=/var/spool/news/overview/OV1 bs=1024 count=1536000
dd if=/dev/zero of=/var/spool/news/overview/OV2 bs=1024 count=1536000

to create files of the correct size.
It should say:

1536000+0 records in
1536000+0 records out

Change the ownerships and permissions:

chown news.news /var/spool/news/overview/OV1
chown news.news /var/spool/news/overview/OV2
chmod 664 /var/spool/news/overview/OV1
chmod 664 /var/spool/news/overview/OV2

Other changes needed to get inn running:

If it says

innd: hismethod is not defined: 
No such file or directory

add

hismethod:              hisv6

after the ovmethod entry in /etc/news/inn.conf.

If it says

SERVER cant bind /var/lib/news/run/control 
No such file or directory

Create the appropriate directories.

cd /var/lib/news
mkdir run
chown news.news run
mkdir /var/spool/news/out.going
chown news.news  /var/spool/news/out.going
mkdir /var/spool/news/in.coming
chown news.news  /var/spool/news/in.coming 
mkdir /var/spool/news/over.view
chown news.news  /var/spool/news/over.view 
mkdir /var/spool/news/in.coming/tmp
chown news.news  /var/spool/news/in.coming/tmp

Start inn in /etc/rc.d. It should write log messages similar to this:

innd: SERVER descriptors 1024
innd: SERVER outgoing 1011
innd: SERVER ccsetup control:15
innd: SERVER lcsetup localconn:17
innd: SERVER rcsetup remconn:3
innd: controlchan! spawned controlchan!:20:proc:17715
innd: abcde.inbound.news.uu.net opened abcde.inbound.news.uu.net:19:file
controlchan[17715]: starting 
innd: SERVER perl filtering enabled
innd: SERVER starting

Finally, rebuild the history database. The previous history file format is also no longer supported by innd. The manual says to use /usr/lib/news/bin/convertspool to convert the file.
Once inn is running, su to news and run /usr/lib/news/bin/convertspool. Inn will immediately crash, wiping out the `out.going' directory. Re-create it with the following commands
mkdir /var/spool/news/out.going chown news.news /var/spool/news/out.going
and restart inn.

One difference from the previous version is that nnrpd will now flood your syslog file with a list of all active groups each time a user logs on. Edit /etc/syslogd.conf to get rid of them (add "news.crit"). Over the next few hours news articles should start pouring in from your ISP.
Even though innd appeared to be running, I still received two cryptic error messages in the daily report:
innd: SERVER cant open overview method innd: hismethod is not defined: No such file or directory
Inspection of the source code showed that the file innd was looking for was a concatenation of pathnews + "db" + /history, where pathnews is defined in /etc/news, which made it /etc/news/db/history. The hismethod was fixed by changing pathnews to /var/lib/news in /etc/news/inn.conf.

Fixing Apache

The Apache web server is now in a new place. We now have several copies of httpd.conf, all different:

  /etc/apache2/httpd.conf
  /etc/httpd/httpd.conf
  /usr/local/apache2/conf/httpd.conf
  /usr/local/apache/conf/httpd.conf
  /usr/local/httpd/conf/httpd.conf

This is only fair, because we also have several incompatible versions of httpd:

  /usr/local/apache/bin/httpd
  /usr/local/apache2/bin/httpd
  /usr/local/httpd/bin/httpd
  /usr/sbin/httpd
  /usr/sbin/httpd2

To find out which httpd goes with which httpd.conf:

Check the startup script to find out which binary is being started.
Run `strings' against the binary to find the location of its conf file.
Get rid of all the other conf files and replace them with links.

  cat apache2 | grep bin | grep httpd
      apache_link=/usr/sbin/httpd2
  ls -l /usr/sbin/httpd2
      lrwxrwxrwx 1 root  root \
      /usr/sbin/httpd2 -> /usr/sbin/httpd2-prefork
  ls -l /usr/sbin/httpd2-prefork
      -rwxr-xr-x 1 root  root /usr/sbin/httpd2-prefork
  strings usr/sbin/httpd2-prefork | grep httpd.conf
      /etc/apache2/httpd.conf
  vi /etc/apache2/httpd.conf

But wait! That's not all! The new version is now not only full of include files, but also contains the line

Note: instead of adding your own configuration here, consider adding it in your own file (/etc/apache2/httpd.conf.local) putting its name into APACHE_CONF_INCLUDE_FILES in /etc/sysconfig/apache2 -- this will make system updates easier :)

So, instead of checking one single conf file, you now also have to check all the following files to make sure they're correct.

  /etc/apache2/httpd.conf.local
  /etc/sysconfig/apache2
  /etc/apache2/default-server.conf
  /etc/apache2/vhosts.d/*.conf
  uid.conf. 
  server-tuning.conf
  sysconfig.d/loadmodule.conf 
  listen.conf. 
  mod_log_config.conf
  sysconfig.d/global.conf 
  mod_status.conf 
  mod_info.conf
  mod_autoindex-defaults.conf  
  mod_mime-defaults.conf
  errors.conf
  ssl-global.conf 
  default-server.conf 
  mod_userdir.conf
  conf.d/apache2-manual?conf  
  sysconfig.d/include.conf 
  vhosts.d

We decided to avoid this by compiling and installing our own version of apache (see linuxsetup42.html). This had the additional benefit of creating yet another entirely new set of incompatible binaries and conf files.

Problems with freetype

Programs requiring freetype would not compile. See linuxsetup70.html for instructions on installing freetype, libXft, and libXrender.

Problems running autoconf

Autoconf wouldn't run. Numerous errors caused by an old autoconf package in /usr/local/bin. After these files were removed, still got error:

   Can't locate object method "path" via package \
    "Autom4te::Request" at \
    /usr/bin/autom4te line 81, <GEN1>line 115.

Edited /usr/bin/autom4te and removed line 81. This seemed to work with no problems so far.

Problems Installing Software from SuSE's CD-ROM

Later I decided to add another package from the CD onto a different computer. However, Yast and Yast2 couldn't read the DVD or CD, and gave the message "Notify: No installation data found on medium. Details: Could not mount the source medium." This occurred with the installation CDs and DVD, and in both CD drives. I copied the CDs to a single directory as the manual recommended and tried "Install from hard disk" and "Change source of installation" and got the same error. The error was accompanied by a slew of syslog messages like this:

 ide-scsi: unsup command: dev hdd: flags = \
REQ_RW REQ_NOMERGE REQ_STARTED REQ_BLOCK_PC

SuSE's support database on their website recognized this as a known bug and suggested typing "hwscan --cdrom". This command creates a profile of the CD in /var/lib/hardware. However, the only effect it had was to change the error message to "Could not mount the source medium. mount: error while guessing filesystem type. mount: /dev/hdd superblock". When I clicked "OK" the original message reappeared. Changing /etc/fstab for /dev/cdrom, /dev/hdc, and /dev/hdd to force the filesystem to iso9660 had no effect. The CD could be easily mounted by hand, but could not be mounted by Yast or Yast2. Yast2 also couldn't mount the SuSE 8.0 CDs. Yet it was possible to boot into the installation program from both the 8.0 and 9.0 CDs.

Solution: SuSE uses the term "medium" to refer to what normal humans would call the "version" of the SuSE distribution. When it says "No installation data found on medium", it actually means "You inserted a CD from a more recent version of SuSE". This computer was actually running SuSE 8.0 and the CDs were from version 9.0. It is apparently impossible for Yast to recognize this fact.

However, once you get this error, inserting the correct CD is not sufficient. Even rebooting is not sufficient to get Yast to read CDs again. I was only able to get the CD recognized by inserting an old SuSE 7.0 CD and clicking "Cancel" when it identified it as an incorrect version. When I inserted the 8.0 CD, it was then correctly recognized. Yast can recognize earlier versions of SuSE, but later versions cause it to get screwed up.

To find the version of Suse that is currently installed, type cat /etc/issue .

Minor problems

fvwm95 was not present. Download, compile, and install it.
rxvt had no error bars and ignored its .Xinitrc settings. Downloaded, compiled, and installed a new version.
'ps -aux' gives annoying error message about "bad syntax" along with an advertisement for somebody's Web site. (This is not yet fixed).
"uname -a" now prints "GNU/Linux" instead of "Linux" or "unknown". Edited the uname binary with vche-nc and customized the string to something else.
'grep' now sometimes bombs out with "memory exhausted" error. (This is not yet fixed). Solution: copy a grep binary from an older machine.
'tripwire' segfaults instead of creating a new database. Tripwire did not compile with gcc 3.3.1. Here is the procedure for compiling tripwire on an older system (gcc 2.95.3).
1. Download new version of tripwire from sourceforge.
2. Make sure STL and g++ are installed.
3. tar -xzvf
4. cd src
5. make release
6. cd install
7. edit install.cfg, set CLOBBER to "true"; otherwise it won't install.
8. cd ..
9. su
10. cp install/install.* .
11. ./install.sh
12. edit /etc/tripwire/twpol.txt
13. cd /usr/sbin
14. ln -s /etc/tripwire/tw.cfg tw.cfg
15. ./tripwire -m i (to initialize)
16. Database file was put in /var/lib/tripwire/biochem.twd. For security, move this file to a floppy and then copy it back to /var/lib/tripwire before checking files.
17. ./tripwire -m c (to check)
Contrary to its documentation, tripwire looked not in the current directory or /etc/tripwire for its config file, but in /usr/sbin.

On the SuSE 9 system, "make release" bombed out for an unknown reason.
In file included from ../stlport/complex:40, from complex.cpp:21: ../stlport/wrap_std/complex:16:39: ../g++-include/complex: No such file or directory
Other C++ programs compile without errors. This is not yet fixed.

Back