Trying to run non-docker SN on QNAP

[Beddhist]

It was going so well yesterday. Port forwarded in router. ARMv7 binary installed. Linux user created. Config file created and edited. Setup created all the necessary files and folders. SN started and waiting…

First problem: no traffic in or out.
2nd problem: can’t connect to console port.

It got late, so I shut down the SN and logged off the NAS.

Today I want to continue, but now the SN refuses to start: can’t find identity. It found it in the config yesterday, but today it looks in the default location. WTF?

Added config dir to command line, like this:

[/share/CACHEDEV1_DATA/sn] # ./storagenode dashboard --config-dir . --identity-dir .

Now it fails to connect to itself:

2021-01-03T13:25:12.260+0700 FATAL Unrecoverable error {"error": "rpc: dial tcp 127.0.0.1:7778: connect: connection refused", "errorVerbose": "rpc: dial tcp 127.0.0.1:7778: connect: connection refused\n\tstorj.io/common/rpc.TCPConnector.DialContextUnencrypted:107\n\tstorj.io/common/rpc.Dialer.dialTransportUnencrypted:178\n\tstorj.io/common/rpc.Dialer.dialUnencrypted.func1:161\n\tstorj.io/common/rpc/rpcpool.(*Conn).newConn:129\n\tstorj.io/common/rpc/rpcpool.(*Conn).getConn:158\n\tstorj.io/common/rpc/rpcpool.(*Conn).Invoke:194\n\tstorj.io/common/rpc/rpctracing.(*TracingWrapper).Invoke:31\n\tstorj.io/common/pb.(*drpcPieceStoreInspectorClient).Dashboard:1087\n\tmain.(*dashboardClient).dashboard:42\n\tmain.cmdDashboard:70\n\tstorj.io/private/process.cleanup.func1.4:362\n\tstorj.io/private/process.cleanup.func1:380\n\tgithub.com/spf13/cobra.(*Command).execute:842\n\tgithub.com/spf13/cobra.(*Command).ExecuteC:950\n\tgithub.com/spf13/cobra.(*Command).Execute:887\n\tstorj.io/private/process.ExecWithCustomConfig:88\n\tstorj.io/private/process.ExecCustomDebug:70\n\tmain.main:336\n\truntime.main:204"}

Now I would like to know how it can be that a program works one day and not the next? And how do I fix it?

I found that the private server line in config was commented out. I tried uncommenting it and then removing the 127.0.0.1 part, but nothing changes.

Thanks,
Peter.

[Pac]

Hello.
Could you provide us with the docker command you use to start the node ? (Please remove personal details like storj afdress, email, host…)

Also, did you use the special command for initializing the node, first? (With --setup)

[Beddhist]

Hi Pac,

No docker here, as it says in the title. The start command is:

./storagenode run --config-dir . --identity-dir .

Oh rhubarb: I just realised that I tried to run the dashboard, rather than starting the node. Duuuh!

Ok, status change, we are now were we were yesterday: the node starts, but there is zero traffic.
Port is open when SN is running, closed when not, as expected.

Trying to access dashboard from my PC does not work, “Firefox can’t establish a connection to the server at qm.local:14002.”

Yes, I ran setup to create all the files and dirs, incl. config.yaml.

[Pac]

@Beddhist

No docker here, as it says in the title

Ah right, my bad
Sorry.

[Alexey]

You need to specify an absolute paths to your config and the identity locations.
Please, also use a remote access configuration to connect to your dashboard from anywhere: How to remote access the web dashboard - Storj Docs
The other way is to configure console.address: to listen on LAN IP, not the localhost as default. This is not recommended if your local network is not trusted (for example - if it is a shared WiFi network).

Perhaps it’s worth to create and register the storagenode service like there:

How to set up a non-Docker node using systemd services with the official native storagenode binary

Hello, I have a method for this but I wanted to get through an update cycle to make sure it worked before I posted it. I’m running two separate nodes with two separate binaries storagenode1 and storagenode2, and then the individual systemd service files for each node. Both nodes use a common storagenode-updater binary. If you already have a node installed as per the OP instructions, set up the second node as follows. Prerequisites Set up identities, port forwards, etc, for your second node. M…

You also can configure the updater:

[Tech Preview] Linux Storage Node & Updater

We now have a Linux storage node and updater available. The Linux installer and the new docker container are not yet available. That means for now we have to create the required services manually. If you don’t know how that works please skip this test round and come back later when we have the installer or the docker container ready. Please don’t migrate any existing storage node. Better start a fresh storage node and expect it to get disqualified. If you are still willing to help us testing t…

[Beddhist]

Thank you Alexey.

I already have absolute paths in my config. To make sure I have also used them to start the SN. It makes no difference. It starts and syncs the clock with a satellite, so it must be communicating, but absolutely nothing happens in the log for hours:

2021-01-03T16:37:00.063+0700 INFO Configuration loaded {"Location": "/share/CACHEDEV1_DATA/sn/config.yaml"} 2021-01-03T16:37:00.095+0700 INFO Operator email {"Address": "xxx@gmail.com"} 2021-01-03T16:37:00.096+0700 INFO Operator wallet {"Address": "0xb1c9621fxxxxx34c4A8d05D47d"} 2021-01-03T16:37:02.324+0700 INFO Telemetry enabled 2021-01-03T16:37:02.532+0700 INFO db.migration Database Version {"version": 46} 2021-01-03T16:37:03.665+0700 INFO preflight:localtime start checking local system clock with trusted satellites' system clock. 2021-01-03T16:37:04.778+0700 INFO preflight:localtime **local system clock is in sync with trusted satellites'** system clock. 2021-01-03T16:37:04.779+0700 INFO bandwidth Performing bandwidth usage rollups 2021-01-03T16:37:04.779+0700 WARN piecestore:monitor Disk space is less than requested. Allocated space is {"bytes": 724781355008} 2021-01-03T16:37:04.780+0700 INFO Node 14cU4e4unH4cesN9Wu9oZfDRug5XiYNYn6mPZ4i3qhXrC7WU23 started 2021-01-03T16:37:04.781+0700 INFO Public server started on [::]:28968 2021-01-03T16:37:04.781+0700 INFO Private server started on 127.0.0.1:7778 2021-01-03T16:37:04.782+0700 INFO trust Scheduling next refresh {"after": "6h43m28.219546462s"} 2021-01-03T17:37:04.779+0700 INFO bandwidth Performing bandwidth usage rollups 2021-01-03T18:37:04.779+0700 INFO bandwidth Performing bandwidth usage rollups

The dashboard on my Windows SN is accessible from other PCs on the LAN. Why does this not work in Linux? As a former IT professional I thought I knew my networking stuff, but from where to where is the port being forwarded to? On which machine do I have to type the forwarding command? Do I have to do this every time I want to connect? I am totally confused.

I started working my way through the setup instructions you have linked. However, almost none of this applies to QTS, QNAP’s cut down Linux.

QTS does not have

• a root account, it’s called admin
• commands like su, sudo, service and many others
• runlevels
• systemd or another usable init system (it does use init, but it’s reloaded from NVRAM at boot, overwriting anything you may have done.)

QTS has

• a root file system that is mostly not persistent across boots
• sshd that permits logins only from admin

With these constraints I suspect that the auto updater will not work and I will have to roll my own. There are ways around some of the limitations and I will document my setup, in case others want to repeat it.

Regards,
Peter.

[Alexey]

@Beddhist

I already have absolute paths in my config.

Not only in configs, you also need to use absolute paths in the storagenode run command.

@Beddhist

The dashboard on my Windows SN is accessible from other PCs on the LAN. Why does this not work in Linux?

The storagenode’s dashboard is listening on 127.0.0.1:14002 by default. In this case the dashboard will be available only on the QNAP itself. To change that you need to modify the console.address: in the config.yaml, like

console.address: :14002

You also need to check your firewall if exist and allow the connection to the 14002 port (and also node’s port) as well.

@Beddhist

QTS does not have

• a root account, it’s called admin
• commands like su, sudo, service and many others
• runlevels
• systemd or another usable init system (it does use init, but it’s reloaded from NVRAM at boot, overwriting anything you may have done.)

@Beddhist

With these constraints I suspect that the auto updater will not work and I will have to roll my own.

Maybe then it’s simpler to use a docker version in my opinion.

[Beddhist]

Yes, it would be simpler, but I’ve got 2 of the most low-end NAS they make and so docker and many other apps will not run. < 512MB RAM for a start.

But what I would really like to know: why is there no activity? No vetting, no repair uploads, nothing at all.

[Pac]

@Beddhist

No vetting, no repair uploads, nothing at all.

As if the node wasn’t reachable from outside

[Beddhist]

Exactly. But yougetsignal says the port is open and if I stop the SN it says it’s closed.

[Beddhist]

@Alexey

console.address: :14002

Thank you again, that worked. Dashboard says it’s online, however, it’s 2 versions back, so I’ll grab the latest and try again.

10 mins later: Aha! v1.19.4 is working.