SNO Flight Manual

Been searching for answers on various questions, thus far to little avail, i find many of the answers on the forum but sadly even the most basic of details can take near hours or more to find.

isn’t there any public resource for customizing node’s?

i find this when searching for a wiki

but seems unrelated to SNO

Show me the manual…

or this is the topic where we start making the Storage Node Operator’s Flight Manual

Explain how you want to customize your node? Theres not much you can change. You need to be in compliance.

Just making sure you’re aware of this page

If that’s not what you’re looking for, can you be more specific?

well one current, in my mind very basic example is that i want to change my config.yaml
which i’m pretty sure i got figured out, but then i start pondering stuff, like if i’m suppose to shut down the node while editing it, or if i can edit it live and if the changes then are applied or if a reboot is required.

or if i want to setup logrotate on a month or weekly basis, i sure all the information is around… but everyone searching and discovering it on their own just seems like a great waste of time, when it could be slowly compiled into a manual.

from what i have seen in the documentation it’s mostly in relation to basic setup… which don’t get me wrong makes perfect sense, this is an entirely new program/ecosystem.

generally i want to keep my storagenode as close to default as possible, i’ve found over the years of working with computers that, its really nice when stuff is really modular.

however i digress.

i was wanting to change that in my config.yaml to do what brightsilence suggested in the link above, seems straight forward and i suppose it is, i just read about people on forums that changed the wrong config.yaml, breaking their node so i like to go through the details of what i’m doing, so i’m sure i don’t break something.

When i looked into the storj documentation they talked about running docker commands, i think it was to get into the container config.yaml, but that may have been some old issues… and i cannot seem to refind it even tho i was looking at it like yesterday.

but after searching on config.yaml i found:

6.1 Optional - How to manually edit the configuration parameters

which gave me the exact location i needed to change the config.yaml at
tho i could only find that when searching in

then i found, that i do need to shutdown my node before changing the config.yaml from

still have no clue why i should use the -t 300 command when shutting down the node…
did shut it down a few times without that, didn’t seem to matter much…

but i’m sure it will make more sense when i get around checking the docker documentation.

it just seems like all this very basic stuff should be in a very easy to approach manual.
i’m sure that when i get the hang of all this, it will be very second nature… but for now trying to figure out how to do stuff, seem arcane at best.

on the upside i did figure out the other day that i can run a fullscreen putty linux terminal with a storagenode docker live log feed, by using:
docker logs storagenode --tail 20 --follow

took me a google search to figure out, that ctrl+c was the only thing that could stop it and then another google search to find out that i had to ctrl + rclick to get out of the putty fullscreen…

I know that’s just because i’m very green in linux, but still… i think a lot of people would like a better manual for all kinds of stuff, storagenode log screensaver beats cmatrix anyday of the week imo.

maybe i’m just use to most stuff being very simply explained and executed since being an advanced windows user for decades.

maybe open source just doesn’t translate well into simple documentation… i duno…

also nice to know that you can actually replicate your configuration, if everything crashes and burns… xD, instead of trying to remember what you did and why, or having to do a weeks or month long research project / build again.

I’m sure many people will join in an attempt help to create a great manual for SNO’s

Thank you for your input regarding documentation. I suggest you read the FAQ section of the documentation. For example

is answered here

is at least partially addressed here

I see you already found some of the questions answered in the FAQ, as well as discovered that we do have a help desk at where you can search for answers to your questions. We are constantly working to improve our documentation and are always happy to hear any suggestions to improve (you can post your comments on the KB articles directly.)

So in summary, I am not sure why having the most frequently asked questions being part of the documentation and having an extensive knowledge base in the helpdesk you are suggesting is not up to par.

On the other hand, details of how to use third party software such as Putty is beyond the scope of Storj support. Each tool has their own help section on their website or in the software.

Well i didn’t want to disrupt my ability to use docker log commands nor that the various scripts people made to not work by default.
so i plan to set up a cron job running this docker command using a timestamp.

docker logs storagenode >& /zPool/storj_etc/storj_logs/2020-03-24_storagenode.log

was kinda meaning to look at logrotate, but ended up with that, not sure what logrotate can do tho… lol
but should be fine for what i’m trying to do.

also i cannot forfeit the docker log storagenode --follow command… thats one of the best things i’ve discovered since moving to linux, aside from working hardware passthrough on the hypervisor… which was just a mindblowing difference compared to hyperv

As a beginner SNO, but a seasoned Linux user, I do agree that there is very little documentation on how things work on a technical level. For example from my own experience the documentation should explicitly state that the storage node measures disk space by querying /app/config, or why it is not supported to have /app/config be placed on an SMB share.

The documentation could also present popular practices like setting up an uptime notification, the script, etc.

It is perfectly understandable though that this is the current state, as the software is still young. The only way to change the current state is to put some actual work on documentation. So… Is there a preferred way to contribute to the documentation site?

1 Like