This TID is a work in progress, does not pretend to be complete and it is written in the assumption that the Filr environment, especially the SQL environment is unaltered compared to a default Filr installation.
This TID is focusing on a Cluster setup, as this is the setup where a small failure can have the largest impact, but several items can be of value for a large or small setup too.
- To make sure this is a readable TID only the most critical values to allow a successful upgrade are listed, but do not refrain from verifying all other settings too.
- Variables, that may differ from the default and that are specific to the Filr setup are listed as [value]
For a Cluster node, with NFS for /vashare, High-Availibility Search with 2 search appliances and a MySQL database and no port redirection configured:
SERVICE_CONFIGURED="yes"(!!) In case this value reads "type:uninitialized drive:sdc size:* format:ext3" then the value should be set to CONFIG_VAINIT_DEVICE_STORAGE="type:existing drive:auto name:auto format:auto"
CONFIG_VAINIT_SEARCH_DOMAINS="[search.dns.suffxes as required]"
CONFIG_VAINIT_DNS_SERVER="[IP address(es) of the DNS server(s)]"
CONFIG_VAINIT_DEVICE_STORAGE="type:existing drive:sdb name:sdb1 format:MSDOS fs:[chosen.filesystem (in general ext3)]" (!!)
CONFIG_VAINIT_SHARED_NFS_SERVER_HOST="[dns name or IP address of the NFS server]"
type=large (also valid for a cluster)
<Host ajpPort="8009" ajpPortEnabled="true" apr="true" forceSecure="true" keystoreFile="" listenPort="8080" listenPortDisabled="8080" listenPortEnabled="true" name="[name of the appliance or the load balancer]" port="80" portDisabled="8080" portRedirect="false" proxyhostname="" proxyport="80" secureListenPort="8443" securePort="443" shutdownPort="8005"/>
<JavaVirtualMachine ms="[value of the JVM min setting]" mx="[value of the JVM max setting" ss=""/>
<Config id="Installed" type="MySql">
<Resource driverClassName="com.mysql.jdbc.Driver" for="icecore" password="[encrypted password]" url="jdbc:mysql://[name or ip of the mysql host]:3306/[Filr's MySQL Database]?useUnicode=true&amp;characterEncoding=UTF-8" username="[MySQL user used by Flr]"/>
<Lucene luceneLocation="high availability">
<Resource lucene.index.hostname="[dns name or ip of the first lucene]" lucene.max.booleans="10000" lucene.max.ha.search.nodes="100" lucene.merge.factor="10" lucene.rmi.port="1199" lucene.rmi.service="" lucene.server.login="lucene service" lucene.server.password="[Encrypted Password]" lucene.server.port="1188">
<HASearchNode ha.service.name="[how the first lucene is listed]" ha.service.title="[Description of first lucene]" ha.service.hostname="[dns name or IP of the first lucene]" ha.service.rmi.port="1199"/>
<HASearchNode ha.service.name="[how the second lucene is listed]" ha.service.title="[Description of second lucene]" ha.service.hostname="[dns name or IP of the second lucene]" ha.service.rmi.port="1199"/>
<Clustered cacheGroupAddress="22.214.171.124" cacheGroupPort="4446" cacheService="" cachingProvider="memcached" enable="true" jvmRoute="worker1" memCachedAddress="" memcachedAddresses="[dns name or IP of first lucene]:11211 [dns name or IP of second lucene]:11211"/>
referenceUrl=jdbc:mysql://[name or IP of the MySQL server]:3306/[Filr's database]?useUnicode=true&characterEncoding=UTF-8
url=jdbc:mysql://[name or IP of the MySQL serfver]:3306/filr?useUnicode=true&characterEncoding=UTF-8
referenceUsername=[Filr's MySQL User]
username=[Filr's MySQL User]
<bean id="luceneSessionFactory" class="com.novell.teaming.search.ha.HALuceneSessionFactory" depends-on="sPropsUtil">
<value>[How the first Lucene is listed]</value>
<value>[dns name or IP of the first Lucene]</value>
<value>[How the second Lucene is listed]</value>
<value>[dns name or IP of the second Lucene]</value>
Although this file will not be part of the vaconfig.zip, in a cluster none of the Filr nodes should have this file on /vastorage as all nodes should be using the same encryption / decryption key stored on the /vashare.
Make sure that the correlating Filr version license key file is installed and no longer the Filr license file of the previous release or even Novell Filr1.0.
After all these files were verified, and are sure to contain the required cluster related information, it is required to regenerate a /vastorage/conf/vaconfig.zip (after creating a backup copy) using the following command:
This could cause that during the upgrade the /vashare is not mounted and because of that the encryption key to be regenerated causing the incorrect decryption of the stored passwords in the configuration and several other fatal phenomena.
An other observed phenomena is that when the Filr node (even when only temporarily) was reconfigured to use Basic for the WebDAV authentication method, the password encryption algorithm changed in the file that sets it during the upgrade.
This caused the inability of users to log in after the upgrade.
In each case this resulted in very unwanted, erroneous configurations that can stay unnoticed until or after the systems were upgraded.
It depends on what patch level the systems were when these administrative changes that trigger these unwanted effects were performed if the Filr systems are affected or not.
This however makes it near to impossible to determine which systems are affected, therefor we suggest to check and verify the files mentioned and updating the vaconfig.zip before attempting the upgrade to increase the chance of a successful update to Filr 2.0.
If, during the upgrade of the first node errors occur during the database update, that looks similar to:
Cannot find net folder config that this non-top net folder [number] belongs toPlease contact Technical Services so they can assist you in this matter.
In order to allow a usable and manageable virtual disk in a
VMware environment, make sure that the second hard disk of the
appliance that requires to be upgraded is configured to be "independent"
and "Persistent" before starting the copy of the virtual disk file(s).
Additional information regarding a couple files:
[How the * Lucene is listed] refers to how that Lucene / Search Appliance is listed In the Search Appliance configuration Page of the Filr, reachable via port 9443 > Novell Filr Appliance Configuration > Search appliance.
- The NTP server entries are fairly critical to be correct, as Filr relies heavily on a correct timesync between all appliances that build up the Filr cluster environment as well with the back-end servers.
- In case of a CIFS shared storage setup for /vashare, there should not be any NFS related entries populated and the CIFS related entries should look like:
CONFIG_VAINIT_SHARED_CIFS_SERVER_FOLDER="\\[dns name or IP of the CIFS server]\[share]"
In addition, there should be a /etc/opt/novell/base/.smbcredentials which should contain a username= and password= entry
- The entries related to the network can not cause an upgrade failure, but can cause an annoyance after the upgrade. If port redirection is enabled, the network entry would look like:
<Host ajpPort="8009" ajpPortEnabled="false" apr="false" forceSecure="true" keystoreFile="" listenPort="8080" listenPortDisabled="8080" listenPortEnabled="true" name="[name of the appliance or the load balancer]" port="80" portDisabled="0" portRedirect="true" proxyhostname="" proxyport="80" secureListenPort="8443" securePort="443" shutdownPort="8005"/>
- The entries related to the JVM might cause some failures during the upgrade, but mostly just an annoyance after the upgrade. However, make sure to configure the newly deployed Virtual Machine with at least the same amount of RAM compared to the previous appliance. Keep in mind not to decrease the RAM.
- In case you doubt the SQL password, it can be re-entered in clear text.
- If the Lucene luceneLocation is not stored as high availability, the upgrade will succeed, but with only a single Search Appliance connected. It is recommended to have all Search appliances to be connected during the upgrade so they can be updated and re-indexed in the same manner.
- In the Clustered cacheGroupAddress section the memcachedAddress value might point to the Filr appliance(s) ip addresse(s); In the course of Filr's lifespan a design change was made to transfer the memcached functionality to the less strained Search appliances. This changes was not made automatically for clusters that were configured before this design change and can be made -if desired- before or after the upgrade. When changing this to reflect the new design approach, make sure that the Search appliance is configured to start the mecached service, and that it's Firewall allows access to port 11211 alongside 1199.
- In this file, there is also a configuration line that controls whether the local postfix mail server is used, or not (true or false) this has no influence on the end result for the upgrade itself, but when Filr was configured to use a remote, corporate mail server, this could be an annoyance when incorrect after the upgrade. If this value is set to true make sure there is an entry in the /filrinstall/installer.xml that looks like:
<Outbound allowSendToAllUsers="true" defaultTZ="[Configured TimeZone]" forceHTTPSLinks="[true or false]" fromEmailAddressOverride="" fromEmailAddressOverrideAll="false">
<Resource mail.smtp.auth="true" mail.smtp.connectiontimeout="15000" mail.smtp.host="[smtp server ip or dns name]" mail.smtp.password="[some encrypted password]" mail.smtp.port="25" mail.smtp.sendpartial="true" mail.smtp.starttls.enable="false" mail.smtp.user="[configured mail user]" mail.smtps.auth="true" mail.smtps.connectiontimeout="15000" mail.smtps.host="[smtp server ip or dns name]" mail.smtps.password="[some encrypted password]" mail.smtps.port="25" mail.smtps.sendpartial="true" mail.smtps.starttls.enable="false" mail.smtps.user="[configured mail user]" mail.transport.protocol="smtp"/>
- If you doubt the correctness of the passwords, you can enter the passwords in clear text, this will however required to replace the double equals sign ( == ) with a single ( = ) and removing the trailing one.
When upgrading the Filr appliance to a newer version, the procedure to do so for -up to and including- Filr 2.0 the procedure is to replace the first disk, with the operating system, only preserving the second disk that contains the /vastorage. When you had reconfigured the Filr so it was able to connect to NAS devices that only allowed NTLMv1, SMBv1 and /or required the workgroup= to be populated with the AD domain name, please be aware that these manually altered configuration files are not preserved and will be in a default state after the upgrade.
In addition, Filr 2.0 uses a seperate smb.conf /etc/opt/novell/filr/.smb/smb.conf