Filr not available after upgrade to 24.1

Hi Community,

just upgrade our large Filr env to 24.1, didn't receive any error message but now :

- we are unable to login to web interface (nor local admin)

- branding does not appear on the web page (opentext Filr, is displayed)

seems every service are running fine : search appliance, postgresql, filr ... etc

disk space is not critical and inode count seems correct, too

any idea ?

Thanks,

Regards

Everyone is a genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is stupid. [A. Einstein]

Parents
  • Suggested Answer

    0

    It seems the real culprit was disk space on root partition.
    / had 3.3 G free out of 50G, but seems not enough for the system to run quietly.
    Support redirects me to this conversation :
    community.microfocus.com/.../new-issue-small-deployment-shuts-down-after-15-minutes

    While checking usage (with du), I didn't find that much of "big" directories...
    But noticed root is BTRFS now (who did take such decision?) and while looking snapper, I noticed 67 snapshots,
    from September 2022 till today. Deleting some of them provides me with more than 10G (total 13G),
    after that I restart everything and both Filr and famtd services are stable now (for a day).

    Note : tell developers to add/document a procedure to clean that garbage out

    Everyone is a genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is stupid. [A. Einstein]

  • 0 in reply to 

    Ah, ok. So the assumption about the failure group you were in was a bit hasty. But good to know, thanks for the update.

    As for the btrfs thing: I also wondered about that for some time, especially with the other related issues we see, like the quota pains and such.
    I think I have gathered enough bits and pieces from some webinars on different products in our space to hazard a guess.(Btw, no matter if Filr, GW, ZEN,... - and hopefully maybe a vibe one when the someone at the company finally "gets it" - they are all to be recommended if only to keep informed about what's going on.)
    It has been said that keeping an appliance model up to date, fresh and current for multiple products is a lot of work, especially on the testing side. When Filr was still SLE12-based, it had a history of coming from JEOS (Just Enough-OS) and was very slim and lean, but needed a load of work to keep it that way. Also, having to test every SUSE-patch thoroughly before taking it in is a workload that can't be skimped on, really, having seen that SUSE CIFS-changes broke CIFS on OES a few times already and OES is a staple backend for Filr. It seems to me that with resources in terms of people-hours being sparse everywhere, and with the change to SLE15 being a boatload of work in an as of itself (if you include the SP level changes, few bricks are in the same place they were before), it looks to me that the Filr appliances are now based on a standard, default SLE installation that is not especially slimmed down. This can be seen if you look at the list of OS patches for the recent update, they have loads of WiFi firmware updates in them, and if someone can explain to me why a Filr Virtual Appliance needs WiFi firmware packages they will get a candy bar from me when (or if) we meet.
    The "standard SLE15" of course includes the default choice of btrfs for the root file system as well as the default snapper integration of zypper (pre- and post-snapshots) as well as the defautl quota settings. I could go on a rant about btrfs being the wrong FS of choice for a use case where a set of zypper pre/post snapshots changes the Database through posttrans-scripts, but the changed database is not part of the snapshot, or where user and subvolume quota management would make sense to keep logs in check, but not if logs are saved in an ext3/4 volume somewhere else. Btfrs does have its place, but that place is where it is properly configured, managed, and above all fully understood by the admin working the system. In my opinion a virtual appliance that is to be run black box-style is not that place.

    I see two ways to get the garbage out for good: a)configure snapper properly and b) on the next appliance drop, change the root file system type. A third way would be full of weeds and thorns: change all file systems in Filr to btrfs, including vastorage and var disks, and make snapshots have a value. Of course, this way is moot on a virtualisation platform that already provides snapshots :).

    Have a nice week!

Reply
  • 0 in reply to 

    Ah, ok. So the assumption about the failure group you were in was a bit hasty. But good to know, thanks for the update.

    As for the btrfs thing: I also wondered about that for some time, especially with the other related issues we see, like the quota pains and such.
    I think I have gathered enough bits and pieces from some webinars on different products in our space to hazard a guess.(Btw, no matter if Filr, GW, ZEN,... - and hopefully maybe a vibe one when the someone at the company finally "gets it" - they are all to be recommended if only to keep informed about what's going on.)
    It has been said that keeping an appliance model up to date, fresh and current for multiple products is a lot of work, especially on the testing side. When Filr was still SLE12-based, it had a history of coming from JEOS (Just Enough-OS) and was very slim and lean, but needed a load of work to keep it that way. Also, having to test every SUSE-patch thoroughly before taking it in is a workload that can't be skimped on, really, having seen that SUSE CIFS-changes broke CIFS on OES a few times already and OES is a staple backend for Filr. It seems to me that with resources in terms of people-hours being sparse everywhere, and with the change to SLE15 being a boatload of work in an as of itself (if you include the SP level changes, few bricks are in the same place they were before), it looks to me that the Filr appliances are now based on a standard, default SLE installation that is not especially slimmed down. This can be seen if you look at the list of OS patches for the recent update, they have loads of WiFi firmware updates in them, and if someone can explain to me why a Filr Virtual Appliance needs WiFi firmware packages they will get a candy bar from me when (or if) we meet.
    The "standard SLE15" of course includes the default choice of btrfs for the root file system as well as the default snapper integration of zypper (pre- and post-snapshots) as well as the defautl quota settings. I could go on a rant about btrfs being the wrong FS of choice for a use case where a set of zypper pre/post snapshots changes the Database through posttrans-scripts, but the changed database is not part of the snapshot, or where user and subvolume quota management would make sense to keep logs in check, but not if logs are saved in an ext3/4 volume somewhere else. Btfrs does have its place, but that place is where it is properly configured, managed, and above all fully understood by the admin working the system. In my opinion a virtual appliance that is to be run black box-style is not that place.

    I see two ways to get the garbage out for good: a)configure snapper properly and b) on the next appliance drop, change the root file system type. A third way would be full of weeds and thorns: change all file systems in Filr to btrfs, including vastorage and var disks, and make snapshots have a value. Of course, this way is moot on a virtualisation platform that already provides snapshots :).

    Have a nice week!

Children
  • 0 in reply to 

    With that been said, why not :

    - either document the BTRFS aspect in the documentation

    - add a BTRFS management menu (snapper command) in the VA administration main page

    In other OpenText product, we are encountering same kind off issue with Docker used for "everything" without managing it correctly, but that's off topics Innocent.

    Everyone is a genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is stupid. [A. Einstein]