However do note that if you have a machine that is running and performing a task ok then generally there is no need to keep updating nodes.
I agree.
But there is that niggling thing where security is waving its hand/s.
These machines are not that exposed, but for the time/s they are on the net I think it would be silly to have one with a big security hole just sitting there.
(I don't know how the security updates are rolled out.)
Got a new problem. New thread.
(Sheesh!)
That is a good point, though I can't see how bigtimer, for example, could be a security issue. Perhaps someone who knows more about these things could comment on the security question.
Yeah, well I just picked that as an example.
I am probably being a bit too paranoid.
I should change my name to Marvin.
We are now well off-topic. But a short response to this. Any code you have loaded into an active app may have potential security issues. In the case of Node-RED, if you have exposed the admin UI to the Internet without suitable protection, you have a tremendous number of moving parts from many different sources all working together and, to the best of my knowledge, none of those parts have been security tested.
Now, do that mean it is too dangerous to connect Node-RED to the Internet? Nope. Because the definition of "dangerous" is a relative one. It depends what you are doing and why. Just remember that the majority of attacks start with someone discovering a vulnerability and then automating the search for systems. Mostly, there is nobody home, just millions of automated systems searching for vulnerable hosts.
If all you are ever doing with Node-RED is learning the ropes and your host server is a Pi isolated from everything else on your network, then clearly the risk - and impact - is really low. On the other hand, if you are using Node-RED as part of an industrial IoT system that can control the heating, lighting and security of a global organisation ... well, lets just say, in that case, if your security, risk and audit teams haven't locked you in a dark room until an independent IT Health Check has been done, they all deserve to be sacked and you will probably find yourself on the front pages of the tabloid newspapers.
Thanks.
So I really should change my name to "Marvin" *
- Marvin - Hitch Hiker's Guide To The Galaxy.
Only if you have a terrible pain in the diodes down your left hand side.
I'm not sure about this. On Ubuntu 16.04 and 18.04 I've had a lot of issues upgrading and installing node-red.
What seems to have solved them has been in my Home directory doing:
sudo -R chown username.group
Somehow some things in the .npm and other directories ended up owned by root and broke most everything.
I can't explain how it happened, by my issues went away after doing this.
Still an issue with upgrading the Email node from Manage Pallet, but "if it ain't broke, don't fix it!" I won't worry about it until the current Email node stops working. Got messages form it this afternoon from my AI system when the mailman came.
The usual cause of this is using sudo npm to install a local node. The rule is use sudo npm if -g is used, otherwise don't use sudo.
By the way, you can use the pi install/upgrade script with Ubuntu, it is the easiest way to make sure you have the latest node red with a consistent set of tools (npm and nodes) and the systemd script that allows it to be auto run on startup.
The email node was installed with a global flag. In the next version of node-red the manage pallete install will be able to update this. If you want to use the newer version before then, go to your .node-red directory and use the command listed in the nodes readme on flows.nodered.org this will install it locally and node-red uses this in preference to the nodes with the global flag.
But you do need v8 of nodejs to use the newer version as stated in the readme
As Colin has said, this will be because you've done something in there using SUDO - most likely, as he says, installing a node with sudo.
I think the confusion is that in post #23 you said it wouldn't have done any harm, but I think you were specifically talking about clearing the cache in that post.
I think my point is that something in recent Ubuntu updates is installing something nodejs as root.
I've done five virgin installs of Ubuntu-Mate (3 of 16.04, 2 of 18.04) All have had issues after node-red was installed using the "debian/Raspbian" script. The first ran into an "this is an NPM issue" for which I joined the "NPM community" and posted a report and error log as mentioned in the error message. Their solution had me run a command as root, it didn't really fix the issue. Eventually I figured out a lot of hidden directories in my home folder were owned by root. No more issues since doing the chown -R command so I "owned everything"
The other four installs all had issues, this time I went straight to the chown -R and no more issues other than the Email node, which has been explained above and in another thread prior to this.
I installed node-red using the script on my main desktop a month or two ago, and I'd not been diligent about updates for it as I have too much going on the tolerate all the reboots required. On the fresh installs this is not an issue so they all were "up to date" before running the debian/raspbian node-red install script and they were all broken installing the dasboard and other nodes with manage pallet until I did the chown -R command.
If you can tell us the folders that are causing issues, we might be able to help.
It would be interesting to know what you have installed since Linux should rarely need rebooting. On my Pi's and on my VPS's I'd be amazed if I have to reboot even once a year. I tend to reboot my older Pi2 most often and that is mainly because so much is squeezed onto it that it helps to do an occasional reboot.
Interesting - if you can provide any pointers to any of these files that may give us a clue and would be worth digging into. Thanks
I'm just setting up a sixth fresh install of Ubuntu 16.04. I get this error when I run the install script:
"npm update check failed" and the error "box" suggests the chown -R command.
~/.config/configstore is owned by root.
I've done apt-get update ; apt-get upgrade ; apt-get install build-essentials git
Then I've installed the Modivius NCS v1 SDK, and after it completes I run the node-red install script.
Again after doing the chown -R command manage pallet works.
So either its something in the recent Ubuntu updates the installation of the NCS SDK that is doing this, if there is not an issue with the script.
hmm - that would seem to be a node.js/npm update issue.
If you get a chance can you try running the chown fix in the .config directory rather than all over (though of course in theory you should indeed own all your own files).
I can fix it in the script if necessary but I don't really want to "fix" more than is required.
OK - this seems to be a known issue - https://askubuntu.com/questions/925545/npm-update-check-failed
I have added that specific fix to the upgrade script so hopefully that should now work as intended without having to apply manually.
Thanks for following up on this. I expect to be setting up another system next week, I'll followup if the problem still persists. Although since I now have a solution its not much of a problem.
Will be good to confirm. Indeed you may know the answer - but loads of users won't - so if we can fix it for all it's "a good thing". Thanks again.