Retrieving NAS4Free Build

For my NAS’ e-mail report I wanted to display NAS4Free version. While uname does give quite a few options, none of them returned all the details I could see on the Status page. And this is where open source shines - source code to the rescue!

Quick investigation has shown that all necessary details are in [util.inc](https://github.com/nas4free/nas4free/blob/master/etc/inc/util.inc). There in get_product_name function I’ve found the first hint - set of prd.* files in /etc directory. Those files get built with the OS and have all the details needed.

To keep a long story short, this is what I’ve decided upon:

VERSION_TEXT="`cat /etc/prd.name` `$cat /etc/prd.version` `cat /etc/prd.version.name` (revision `cat /etc/prd.revision`)"
echo "$VERSION_TEXT"

When ran on my current system, I get “NAS4Free 10.2.0.2 - Prester (revision 2118)”. Exactly what I needed. :)

Using AN20 on PIC16LF1559

For one pet project, I decided to use Microchip’s PIC16LF1559. as it was close to perfect as far as my needs went in that particular scenario. So I got all parts, soldered it onto the board and it almost worked perfectly.

Single thing that gave me trouble was light detection. It seemed as if ADC converter was giving me nonsense. I check and rechecked my code multiple times as this was the first time I’ve dealt with this chip. It took me a while before I remembered to check errata sheet. And, lo and behold, there was an known issue: “AN20 is not internally connected to the ADC bus when AD2CON0’s CHS bit select the pin.” And guess which pin I decided to use for light sensor?

Initialization of ADC is something that will slightly vary with application but what follows is a reasonable starting point:

ADCOMCONbits.ADFM = 1;      //right-justified
ADCOMCONbits.ADCS = 0b111;  //Frc (clock derived from A/D RC oscillator)
ADCOMCONbits.ADPREF = 0b00; //Vref is Vdd
AD2CON0bits.CHS = 20;       //select AN20
AAD2CHbits.CH20 = 1;        //AN20 is connected to ADC2

This will nicely work around the issue by using AN20 on the secondary channel. Not an ideal situation but it was ok in my case as I had no other plans for secondary channel anyhow.

Reading a value is a bit different than when dealing with a usual, single-channel, setup:

uint16_t getAdcValue(void) {
    AD2CON0bits.ADON = 1; //Turn on ADC

    AD2CON0bits.GO  = 1;
    while (AD2CON0bits.GO_nDONE) { nop(); } //Wait for A/D convert complete

    AD2CON0bits.ADON = 0; //Turn off ADC

    if (AADSTATbits.AD2CONV) {
        return AD2RES1;
    } else {
        return AD2RES0;
    }
}

For my purpose it made sense to turn on/off ADC as needed - for some other scenarios it might be better just to leave it always on. But interesting bit comes when reading a value - ADC saves it interleaved between two registers: AD2RES0 and AD2RES1. Code simply had to make sure to read correct one.

And this, slightly roundabout process, finally got the project working.

VHD Attach 4.10

This is pretty much just a maintenance release of VHD Attach. No new features are present but some old bugs have been squashed. One that plenty people might have found annoying is erroneous removal of the ReFS integrity stream on NTFS drives. This makes sense when you try to create virtual disk on ReFS but has no place when dealing with NTFS.

Also registration to handle both .vhd and .vhdx is added. As this is option not turned on by default on Windows 10, not many people actually noticed it missing, but a few did. And finally there is a fix for the dreaded NullReferenceException when OpenWithProgids is not present. Neither of these really affect many systems, but it did affect some.

This is most probably the last release without the auto-upgrade functionality. I have always been proponent of software not phoning home and not making the internet connection whenever it pleases; it just seemed rude to me. However, it seems that normal people generally don’t mind, assuming it is done discretely, and it does solve my e-mail nightmare. Probably 95% percent e-mail error reports I get are due to the use of the old versions and users simply not being aware of the fix.

I am still thinking how exactly to do it and how to impact users as little as possible, considering both startup time and privacy as concerns, but do it I will. :)

As always, download is available on the program page.

Accessing NAS4Free Web Interface With SSH

I was fortunate enough to collocate my backup machine at friend’s place. Unfortunately I wasn’t smart enough to actually setup everything. :) Only thing I had working was SSH.

Yes, my first though was to use SSH forwarding. Configuring local SSH tunnel with any free source port and using destination IP address with 443 (https) or 80 (http) as a port would allow for accessing remote web interface. Just access 127.0.0.1:localport and web interface would appear as if it was accessed through local network.

For my example I configured local port 62443 toward destination 192.168.0.1:443 and accessing 127.0.0.1:62443 should have been enough to show NAS4Free web interface. However, that didn’t work as smartass me didn’t enable Port Forwarding on the remote box. Duh!

To get out of this hole, first step is to allow for editing of config.xml where all settings are saved and that is mounted read-only by default:

umount /cf
mount -o rw /cf

After that use vi to edit /cf/conf/config.xml and add tcpforwarding configuration parameter:

<sshd>
    <port>22</port>
    <pubkeyauthentication/>
    <permitrootlogin/>
    <enable/>
    <private-key/>
    <subsystem/>
    ^^<tcpforwarding/>^^
</sshd>

Unsurprisingly that doesn’t really help as configuration isn’t applied automatically. Easiest way to apply it is restart:

init 6

As machine booted, I could access web interface via the magic of SSH port forwarding.

[2018-07-22: NAS4Free has been renamed to XigmaNAS as of July 2018]

Removing \"Custom Script Entries\" From NAS4Free Status E-mail

One annoyance I have with NAS4Free is how every custom report has a prefix - even when you fully customize it:

Custom script entries:
----------------------
All local pools are healthy
• Nenya: not reachable
• Narya: not reachable
...``

I find that “Custom script entries:” followed by dashes completely unnecessary and, if you read message on a small screen (e.g. Pebble watch), it just takes space from the more important information.

Culprit to this can be found in /etc/inc/report.inc where the following line creates that header:

$statusreport->AddArticle(new StatusReportArticleCmd("^^Custom script entries^^","{$config['statusreport']['report_scriptname']}"));

Good old sed can help us with removing this:

sed -i -e 's^Custom script entries^^g' /etc/inc/report.inc

If you have embedded installation, this will work only until restart. To make it “permanent”, just add it to System→Advanced→Command scripts.

[2018-07-22: NAS4Free has been renamed to XigmaNAS as of July 2018]