Forward compatibility fix for CentOS 7.x platform and nmap-ncat issues.

[hookbot]

Yes, everything used to work fine on CentOS 6.x until RedHat 7.x came along and decided that the "nmap-ncat" package was a great replacement for "nc". Unfortuantely, this doesn't support that DANGEROUS "-z" option anymore. Rude, eh?

So this patch just allows it to work with any version of netcat again, just like the good old days.

[hookbot]

I just tested dashman with this patch on CentOS 7.x and everything is finally up and running perfectly fine now. Sorry for the past 16 months where this hasn't been working.

[hookbot]

The www.dashninja.pl website no longer detects freshly configured masternodes at the moment. So this patch will pull the funding txn and payee from "masternode status" instead of trying to extract it from WEB_NINJA_JSON.

[hookbot]

And this finally fixes this crashing spewage on CentOS 6.x platform:

--> testing installation... Traceback (most recent call last):
File "venv/bin/py.test", line 5, in
from pkg_resources import load_entry_point
File "/home/master/.dashcore/sentinel/venv/lib/python2.6/site-packages/pkg_resources.py", line 3007, in
working_set.require(requires)
File "/home/master/.dashcore/sentinel/venv/lib/python2.6/site-packages/pkg_resources.py", line 728, in require
needed = self.resolve(parse_requirements(requirements))
File "/home/master/.dashcore/sentinel/venv/lib/python2.6/site-packages/pkg_resources.py", line 626, in resolve
raise DistributionNotFound(req)
pkg_resources.DistributionNotFound: argparse
--> sentinel tests failed
when running:
venv/bin/py.test ./test/
Exiting.

[moocowmoo]

Thanks for these patches! I'll be free to give dashman some attention soon and will review your submissions then.

In the meantime, why doesn't 2>&1 fold STDERR into STDOUT like I'm expecting it to?
If you want to chat about it, here's a discord link: http://dashchat.org/

[hookbot]

I finally successfully got your dashman running CentOS 7.x using these compatibility patches. For proof, see these 2 nodes:

XrcxRCXQ9V8TJ4mAefCSS5gYXpRHBDxWpi

XrcxRCXo9GJjby9PzSFKrR4aH5hLacKM9a

Both running on my fork code.

[hookbot]

And that's a very good question about the "2>&1"! It actually DOES fold STDERR into STDOUT. Actually, everything going to STDERR ends up spraying out to your face on STDOUT and everything that would have normally gone to STDOUT gets appended to the file.

Unfortunately, all shell programs under linux execute the redirection specifications in REVERSE order, i.e., right-to-left (instead of the more intuitive left-to-right that most humans seem to prefer). Thus, the ">>" is redirected first, then the "2>" is redirected later since it's to the LEFT. I'm not sure why this is, but that's how it works. Here is an example demonstrating this confusing behavior:

$ perl -e 'print "To STDOUT\n"; print STDERR "to STDERR\n";'
To STDOUT
to STDERR
$ perl -e 'print "To STDOUT\n"; print STDERR "to STDERR\n";' 2>&1 >/dev/null
to STDERR
$ perl -e 'print "To STDOUT\n"; print STDERR "to STDERR\n";' >/dev/null 2>&1
$
$ perl -e 'print "To STDOUT\n"; print STDERR "to STDERR\n";' 2>&1 | cat
to STDERR
To STDOUT
$ perl -e 'print "To STDOUT\n"; print STDERR "to STDERR\n";' 2>&1 | cat >/dev/null
$

So probably a better solution would be to just slide that "2>&1" over to the right a bit. (See my latest pull request.)

Or just use the "|cat" method to make it super clear to everyone and avoid relying on the strange back-asswards shell behavior.

But I don't think it's appropriate to spray all the STDERR into the crontab pipe and fill up my mailbox with all that spewage every few seconds.

[moocowmoo]

WOW! I learned something new today. Thank you!

I've occasionally gotten this wrong without realizing why, reading it to myself as:
"take the output of moo, fold STDERR into STDOUT, then redirect STDOUT into cow"
when it's actually:
"take the output of moo, redirect STDOUT into cow, with STDERR folded into STDOUT"

I had no idea I didn't know this important syntax! THANK YOU!

Oh, and nice trick with the vanity addressed masternodes!

[hookbot]

BTW, the dashninja.pl website is finally functioning again, so my patch to quickly extract the ADDY and VIN and the VIDX from the LOCAL_MN_STATUS is not required anymore.

I mean, it's nice to show your wallet and transaction regardless if dashninja is have problems, but it also might still be nice to validate the status with an external website anyways. I can see pros and cons to either way. Just my two cents.

[hookbot]

Also, I finally fixed the bootstrap code within the fork so it works on CentOS 6.x instead of this spewage:

--> Bootstrapping blockchain. Please wait...
--> Downloading bootstrap... 3.1G...
pv: invalid option -- 'a'
Try `pv --help' for more information.
pv: invalid option -- 'a' bootstrap download failed. skipping.
--> Launching dashd... DONE!

[moocowmoo]

I'm guessing the wrapper is because the cron run doesn't have LD_LIBRARY_PATH set?
Instead, is there a way to set it in the initial virtualenv install at line 1219 virtualenv venv 2>/dev/null >/dev/null;?

[hookbot]

Well, it MIGHT be possible to move that line up closer to line 1252 way up closer to line 1219, but I was scared of possible infinite grinding the "pip install" and "py.test" stuff when they attempt to run the "bin/python2" which never requires any LD_LIBRARY_PATH dancing around.

This wrapper is ONLY for CentOS 6.x where that new-fangled Python 2.7 requirement is nearly impossible to find. The only way I was able to get sentinel to work on CentOS 6.x was using the "scl" wrapper:

$ time scl enable python27 "~/dashman/dashman install sentinel"

And yes, no matter how hard I tried to fix the crontab entry to run the correct "scl" wrapper properly on CentOS 6.x platform, every time I accidentally update dashman, she keeps bricking over my goodness with that nasty stock "sentinel" crontab entry, then my node would fall into WATCHDOG_EXPIRED and I'd lose all my beans. I couldn't stand it anymore, so I added that patch to buttwag around all the frustrations. Now everything works great again on CentOS 6.x.

Basically, this just ensures that if there is any "$LD_LIBRARY_PATH" existing during the commandline installation, that same environment will exist when the cron runs too.

Fortunately, in the other 99% of the cases, this "$LD_LIBRARY_PATH" is already naked, so this line just doesn't do anything at all.

OH! What would be REALLY cool would be if dashman could automagically detect the version of python running and do all the "scl" wrapper stuff if that's the only way to reach python2.7 on the current system.

Yes, I realize this is ugly, but I'm open to any suggestions.

[hookbot]

NOTE: I've also found that CentOS 6.x runs more efficiently than CentOS 7.x (and other Platforms) on VMs with less memory resources, which is what really makes this patch so much more valuable to people who care about how much money it costs each month to keep a masternode up and running.