OpenFiler 2.99 Update Troubleshooting

The easy normal way of installing updates on OpenFiler is via conary update <package>! Sometimes, it just won't work like this.

Troubleshooting Errors

You can have several different error scenarios which each need their own solution:

Error "changeset cannot be applied: applying update would cause errors"

[root@atsan001 ~]# conary update openldap
Applying update job:
    Update  openldap(:config :lib :runtime) (2.4.19-0.0.3-1 -> 2.4.19-0.0.4-1)
    Install openldap:devel=2.4.19-0.0.4-1
    Install openldap:devellib=2.4.19-0.0.4-1
    Install openldap:doc=2.4.19-0.0.4-1
    Install openldap:supdoc=2.4.19-0.0.4-1
Creating database transaction (8 of 8)...changeset cannot be applied:
applying update would cause errors:
/usr/lib64/liblber.a conflicts with a file owned by openldap:devellib=/conary.rpath.com@rpl:devel//2/2.4.11-2.1-1[is: x86_64]

/usr/lib64/libslapi.so conflicts with a file owned by openldap:devellib=/conary.rpath.com@rpl:devel//2/2.4.11-2.1-1[is: x86_64]

[...]

/usr/share/man/man3/ldap_abandon.3.gz conflicts with a file owned by openldap:devel=/conary.rpath.com@rpl:devel//2/2.4.11-2.1-1[is: x86_64]

This could happen due to not installing packages in the correct order, when the dependencies of the package cannot be resolved or when there are file conflicts. The solution should be a conary update <package> --resolve --replace-files. This will resolve dependencies if possible and overwrite file conflicts by replacing these files.

Error "<package> was not found"

[root@atsan001 ~]# conary update scsi-target-utils
scsi-target-utils was not found on path openfileresa.rpath.org@esa:openfileresa-3.0, foresight.rpath.org@fl:2-qa, conary.rpath.com@rpl:2

This could happen due to a typing error of the package name or that it simply does not exist on the default path. Therefore you will have to visit the following site: http://www.rpath.org/search?type=Packages

• Here you can search for the package you're looking for:

• Look for "OpenFiler ESA" in the column "Product":

Under the package name you can see the correct download path! So type conary update <package>=<path>. This should solve the problem.

Error "The following dependencies would not be met after this update"

[root@atsan001 ~]# conary update group-core
The following dependencies would not be met after this update:

  newt:python=0.52.6-1-0.1 (Already installed) requires:
    soname: ELF64/libslang-utf8.so.1(SysV x86_64)
  which is provided by:
    slang:lib=1.4.9-6-0.1 (Would be erased)

This will happen when there are errors with package dependencies. The solution is similar to the changeset cannot be applied error, except that you additionally have to ignore dependencies: conary update <package> --no-deps --resolve --replace-files.

Before replacing files you should try with the keep-required option: conary update <package> --keep-required. This will force the update to be applied but still keep required files. Unfortunately this solution does not always work.

Rollback

If you have installed one or more packages and suddenly after a reboot OpenFiler is crashed, you could try to do a rollback to a specific point where you know that the system was working! Afterwards you can install each single package to find the one that forces the problem. First of all you should check your rblist with conary rblist | less. As this list contains a lot of information, you should run it trough the less pipe, as you will not be able to scroll to the top otherwise.

Check rblist

The output may look something like this:

r.168:
           erased: dbus(:config :data :devel :devellib :lib) 1.2.4-1-1
           erased: libtool(:lib) conary.rpath.com@rpl:2-qa/1.5.24-3-0.1
           erased: libxml2(:python) conary.rpath.com@rpl:2-qa/2.6.30-3-0.1
           erased: libxslt(:python) conary.rpath.com@rpl:2-qa/1.1.24-2-0.1
           erased: portmap(:runtime) conary.rpath.com@rpl:2-qa/4.0-11-0.1
           erased: python-hashlib(:python) 20081119-1-1
           erased: python-multiprocessing(:python) 2.6.2.1-1-1
          updated: group-openfileresa-appliance 2.99.1-35-2 -> 2.99.2-5-1

r.167:
          updated: php-openfiler(:config :lib) 0.1-2-1 -> 0.1-3-1

r.166:
          updated: dbus(:runtime) foresight.rpath.org@fl:2-qa/1.4.0-0.3-1 -> 1.4.6-0.3-1
        installed: dbus:config foresight.rpath.org@fl:2-qa/1.4.6-0.3-1
        installed: dbus:data foresight.rpath.org@fl:2-qa/1.4.6-0.3-1
        installed: dbus:devel foresight.rpath.org@fl:2-qa/1.4.6-0.3-1
        installed: dbus:devellib foresight.rpath.org@fl:2-qa/1.4.6-0.3-1
        installed: dbus:doc foresight.rpath.org@fl:2-qa/1.4.6-0.3-1
        installed: dbus:lib foresight.rpath.org@fl:2-qa/1.4.6-0.3-1
        installed: dbus:supdoc foresight.rpath.org@fl:2-qa/1.4.6-0.3-1
[...]

The number behind the r. tells you the rollback point!

Two different Types of Rollback

• You can now do a rollback step by step with: conary rollback 1.

The rPath documentation says:

"Conary's rollback system works like a push-pop stack in which rollbacks are 'pushed' onto the stack when changesets are applied and 'popped' off the stack when a rollback command is issued. If you wish to restore to a system configuration from a previous time, identify the rollback representing that desired point in time (using conary rblist), and 'pop' the stack to that level by repeatedly applying the most recent rollback (using conary rollback)."

• Or you can roll back to the preferred system state by typing: conary rollback r.<number>.

Web Interface not available any more after running Updates

This is what typically happens if you don't install updates the correct way! You just won't be able to access the GUI as your web browser will either tell you that the page cannot be found, that there is a HTTP 500 Internal Server Error or just show you a blank screen. It may also happen that you can access the web interface (probably only via the IP address), but after a login it will give you one of the problems described above. Of course your server will boot as normal and you can also reach it via the console or SSH.

Verify the Issue

The packages I have found most likely to produce these issues are different PHP updates (especially PHP PAM Auth) in combination with the group appliance and php-openfiler packages. To verify these issues you can run the following command: service openfiler status. If it is stopped, do a service openfiler start. For me the output was this:

[root@atsan001 ~]# service openfiler status
openfiler is stopped
[root@atsan001 ~]# service openfiler start
Starting openfiler: openfiler: Syntax error on line 47 of /opt/openfiler/etc/httpd/conf/httpd.conf: Cannot load /opt/openfiler/etc/httpd/modules/libphp5.so into server: libidn.so.11: cannot open shared object file: No such file or directory
                                                           [FAILED]

Do not try to start services like httpd or NetworkManager as they are handled by the openfiler service! It won't work but give you additional error messages which might confuse you. It's also very wise to check log files. You can find them in /var/log and the relevant one in /var/log/openfiler/httpd.

Relevant Services

This shows that OpenFiler uses its own httpd service while the daemon you can start with service httpd start is the default one from Apache. This is why it will result in even more damage than helping you find the originating problem.

Something similar belongs to the NetworkManager. I found out that if you start this service it will crash your network configuration, especially your /etc/hosts file. Occasionally this contains the DNS servers for name resolution, but obviously OpenFiler handles this differently. So if you start this daemon, you won't have any network connection at all.