XigmaNAS 12.1.0.4.7287 released (FreeBSD 12.1-RELEASE-P2)

[zoon01]

We are pleased to announce the release of XigmaNAS version 12.1.0.4.7287- Ingva.

The 12.1 series does replace and upgrade the 12.0.0.4 series who are now unsupported.
We suggest to upgrade your 12.0.0.4 servers to 12.1.0.4.7287 or latest 11.3.0.4.xxxx series.

First BACKUP your current Configuration!
READ readme_12.1.txt please before you do anything!

Download build 12.1.0.4.7287

Changes for release 12.1.0.4.7287
=================================
- Upgrade to FreeBSD 12.1-RELEASE P2.
- WebGUI code & framework improvements.
- Upgrade devcpu-data to 1.28.
- Upgrade bash to 5.0 P16.
- Upgrade lighttpd to 1.4.55.
- Upgrade php to 7.3.15.
- Upgrade sudo to 1.8.31.
- Upgrade e2fsprogs to 1.45.5.
- Upgrade dialog to 1.3-20200228.
- Upgrade nano to 4.8.
- Upgrade phpmyadmin to 4.9.4.
- Upgrade samba to 4.10.13.
- Upgrade syncthing to 1.3.4.

Fixes:
- Display releases of minor/major OS upgrades and minor/major product upgrades, beta versions and nightlies.


Basic Note:
- Make a new backup of your system configuration and store this on safe location, the system config.xml could be upgraded!
- Clear your browser's cache to avoid display issues after upgrade when coming from older releases.

Regards,
Team XigmaNAS

[sleid]

Update successfully, no problem with sshd but problems with the execution via cron of healthcheck.zfs this crashes the web interface and unable to reconnect to the web interface after logging out. reboot sytem or browser restart is required to log in.
Thanks

[raulfg3]

update sucesfully, no problems detected.


Thanks a lot.

[Victek]

Thanks for the long awaited update. Running fine after 10 minutes flash.

[Snufkin]

Nextcloud 18.0.1.3 (NextOwnCloud Extension) failed to start with PHP 7.4.3.
Two missed PHP modules were found:

• GD
• zip

PHP 7.4 is recommended runtime environment according to Nextcloud 18 System requirements.

Not sure, if there are simple ways to update the extension or add modules to embedded XigmaNAS.

[zoon01]

Nextcloud 18.0.1.3 (NextOwnCloud Extension) failed to start with PHP 7.4.3.
Two missed PHP modules were found:

• GD
• zip

PHP 7.4 is recommended runtime environment according to Nextcloud 18 System requirements.

Not sure, if there are simple ways to update the extension or add modules to embedded XigmaNAS.

Wil add missing modules for next release,
extra options/modules might require a custom install to add yourself.

[Snufkin]

Nextcloud 18.0.1.3 (NextOwnCloud Extension) failed to start with PHP 7.4.3.
Two missed PHP modules were found:

• GD
• zip

PHP 7.4 is recommended runtime environment according to Nextcloud 18 System requirements.

Not sure, if there are simple ways to update the extension or add modules to embedded XigmaNAS.

Wil add missing modules for next release,
extra options/modules might require a custom install to add yourself.

Great! Thank you!

There is absolutely no rush to add above modules. They were found in non-production test bench, and I had a chance to test XNAS downgrade/config restore. Not even minor glitch!

Actually Nexcloud 18.0.1 is not ready for production yet due to some bugs in new Photo/Gallery application.

[netware5]

Upgrade of embedded 7091 to 7287 via WebGUI went smooth.

One important info for all colleagues using the wsdd.py script:

The new release is with Python 3.7. You shall change the Python version in the first line of wsdd.py script to 3.7:

Code: Select all

#!/usr/bin/env python3.7

Otherwise the wsdd.py script will not work.

[riveradavid]

Does this build include fixes for the Samba configuration problems many of us have faced?

[raulfg3]

28/04/2020 Updated info: viewtopic.php?f=78&t=15146#p94833

Does this build include fixes for the Samba configuration problems many of us have faced?

yes

[rth]

Update from version 11.3 to 12.1 working well.
Had to revert from previous 12 release because file shares not working correctly.
Thanks for the update.

HP microserver,2GB,3*2tb+1*8tb

[kim.bjoern]

Thanks for this release. I tested embedded installs on ESXI, and almost everything seems to work just fine.

Except: I can't access Disks Management in the gui, and get an error:

Warning: array_key_exists() expects parameter 2 to be array, null given in /etc/inc/system.inc on line 584 Warning: array_key_exists() expects parameter 2 to be array, null given in /etc/inc/system.inc on line 584 Warning: Cannot modify header information - headers already sent by (output started at /etc/inc/system.inc:584) in /usr/local/www/fbegin.inc on line 34

Any ideas?

/Kim Bjoern

[ms49434]

Thanks for this release. I tested embedded installs on ESXI, and almost everything seems to work just fine.

Except: I can't access Disks Management in the gui, and get an error:

Warning: array_key_exists() expects parameter 2 to be array, null given in /etc/inc/system.inc on line 584 Warning: array_key_exists() expects parameter 2 to be array, null given in /etc/inc/system.inc on line 584 Warning: Cannot modify header information - headers already sent by (output started at /etc/inc/system.inc:584) in /usr/local/www/fbegin.inc on line 34

Any ideas?

/Kim Bjoern

a variable isn't properly initialized, a bug fix has been committed: https://sourceforge.net/p/xigmanas/code/7294/

[Snufkin]

System log display error still needs to be fixed.

[markmarques]

updated to this 12.1.0.4.7287 with no problems...
Thanks for the update ...

[raulfg3]

System log display error still needs to be fixed.

I notice that user and Time&date are correct, but event have the same tim&date And users (need to clean)

1.jpg

[SWS1953]

[/quote]
Wil add missing modules for next release,
extra options/modules might require a custom install to add yourself.
[/quote]

How can i custom install these modules. It woulkd be nice to keep using nextcloud.
Thanks Sven

[Cyberpower678]

Upgrade went smoothly, but there are still some bugs that need resolving regarding the GUI. One minor, one not so.

For the not so minor if a ZFS pool is in the UNAVAIL state the GUI will completely break on the home screen. A very helpful warning message is displayed at the top. Looking at it I have established that the problem is calculating the percentage of the pool being used up. It becomes a non-numeric value which will prompt the warning and prematurely send out headers, which in turn causes nothing but the toolbar to load. A simple fix for this is to add a check with is_numeric to catch that and work around it in /etc/inc/system.inc. You can see what I added below.

Screen Shot 2020-03-07 at 10.21.03.png

The second issue is that the banner on top doesn't completely load. When the first error is triggered however, the banner is loaded and reloaded repeatedly filling the entire page with a banner.

Screen Shot 2020-03-07 at 10.27.38.png

As mentioned though, the banner issue isn't a problem that affects usability unless combined with the first error, but it would be nice to fix.

[ms49434]

System log display error still needs to be fixed.

I notice that user and Time&date are correct, but event have the same tim&date And users (need to clean)
1.jpg

could you please test commit 7301 and feedback?

[raulfg3]

System log display error still needs to be fixed.

I notice that user and Time&date are correct, but event have the same tim&date And users (need to clean)
1.jpg

could you please test commit 7301 and feedback?

I need a XigmaNAS-x64-full-12.1.0.4.7301.tgz file to download to test it.

please post me a P.M.

[Snufkin]

System log display error still needs to be fixed.

I notice that user and Time&date are correct, but event have the same tim&date And users (need to clean)
1.jpg

could you please test commit 7301 and feedback?

It becomes better, but not perfect yet.

syslog-7301.jpg

[ms49434]

System log display error still needs to be fixed.

I notice that user and Time&date are correct, but event have the same tim&date And users (need to clean)
1.jpg

could you please test commit 7301 and feedback?

It becomes better, but not perfect yet.
syslog-7301.jpg

Would it be possible for you to be more specific on "It becomes better, but not perfect yet"?
The log service records 2 different type of messages, RFC 3164 and RFC 5424 compliant, the latter is encapsulated in the msg of the RFC 3164 record.
RFC 3164 logs timestamp, hostname and the message, whereas RFC 5424 logs timestamp, hostname, app-name, procid, msgid, structured data and the message.
If the message is a RFC 3164 message, the 3 fields timestamp, hostname and the message are currently displayed.
If the message is a RFC 5424 message, the timestamp, hostname and the app-name + message of the RFC 5424 part are displayed (commit 7301).

[Snufkin]

System log display error still needs to be fixed.

I notice that user and Time&date are correct, but event have the same tim&date And users (need to clean)
1.jpg

could you please test commit 7301 and feedback?

It becomes better, but not perfect yet.
syslog-7301.jpg

Would it be possible for you to be more specific on "It becomes better, but not perfect yet"?
The log service records 2 different type of messages, RFC 3164 and RFC 5424 compliant, the latter is encapsulated in the msg of the RFC 3164 record.

I am sorry, ms49434, I couldn't make my point clear. Let me try to explain what I meant.

On the System Log page, the Date & Time column has different formatting for different rows.

• First formatting option

  Code: Select all

  Mar 8 20:44:30

• Second formatting option (taken from RFC 5424 message?)

  Code: Select all

  2020-03-08T20:44:34.562280+03:00

This is what I called "not perfect" in terms of user experience.

[ms49434]

System log display error still needs to be fixed.

I notice that user and Time&date are correct, but event have the same tim&date And users (need to clean)
1.jpg

could you please test commit 7301 and feedback?

It becomes better, but not perfect yet.
syslog-7301.jpg

Would it be possible for you to be more specific on "It becomes better, but not perfect yet"?
The log service records 2 different type of messages, RFC 3164 and RFC 5424 compliant, the latter is encapsulated in the msg of the RFC 3164 record.

I am sorry, ms49434, I couldn't make my point clear. Let me try to explain what I meant.

On the System Log page, the Date & Time column has different formatting for different rows.

• First formatting option

  Code: Select all

  Mar 8 20:44:30

• Second formatting option (taken from RFC 5424 message?)

  Code: Select all

  2020-03-08T20:44:34.562280+03:00

This is what I called "not perfect" in terms of user experience.

diag_log.inc from commit 7301 and diag_log.php from commit 7302 are now showing the old style timestamp and host.

[Snufkin]

diag_log.inc from commit 7301 and diag_log.php from commit 7302 are now showing the old style timestamp and host.

Great! We have almost reached the perfect solution.

Do you think it's worth getting rid of duplicate dates in messages like this one?

Code: Select all

Mar 8 20:44:35	xnas-beta	smbd: [2020/03/08 20:44:35.890480, 0] ../../lib/util/become_daemon.c:136(daemon_ready)

[ms49434]

diag_log.inc from commit 7301 and diag_log.php from commit 7302 are now showing the old style timestamp and host.

Great! We have almost reached the perfect solution.

Do you think it's worth getting rid of duplicate dates in messages like this one?

Code: Select all

Mar 8 20:44:35	xnas-beta	smbd: [2020/03/08 20:44:35.890480, 0] ../../lib/util/become_daemon.c:136(daemon_ready)

please try adding "debug timestamp = no" to the global section of smb4.conf

[Snufkin]

...
Do you think it's worth getting rid of duplicate dates in messages like this one?

Code: Select all

Mar 8 20:44:35	xnas-beta	smbd: [2020/03/08 20:44:35.890480, 0] ../../lib/util/become_daemon.c:136(daemon_ready)

please try adding "debug timestamp = no" to the global section of smb4.conf

Above option has absolutely incredible power.
It doesn't remove timestamp from the message, but completely suppresses its logging.

[ms49434]

...
Do you think it's worth getting rid of duplicate dates in messages like this one?

Code: Select all

Mar 8 20:44:35	xnas-beta	smbd: [2020/03/08 20:44:35.890480, 0] ../../lib/util/become_daemon.c:136(daemon_ready)

please try adding "debug timestamp = no" to the global section of smb4.conf

Above option has absolutely incredible power.
It doesn't remove timestamp from the message, but completely suppresses its logging.

This option is working on my machines since a long time. From the smb.conf man pages, 'debug timestamp' is a synonym for 'timestamp logs':

Code: Select all

debug timestamp
This parameter is a synonym for timestamp logs.

timestamp logs (G)
Samba debug log messages are timestamped by default. If you are running at a high debug level these timestamps can be distracting. This boolean parameter allows timestamping to be turned off.

Default: timestamp logs = yes

[zoon01]

Thanks for all feedback,
new release is out!

[riveradavid]

Does this build include fixes for the Samba configuration problems many of us have faced?

yes

Unfortunately, it looks like it still has problems. It gets farther, but still died in the initialization script on a new installation.