time to disable coinhive – hysteria ensues

See my previous post here – https://sigtar.com/2017/10/13/coinhive-alternative

So the trial of coinhive and associated monero browser mining has come to an end. It seems most corporate firewalls and security appliances detect and block access to my domain just being associated with the coinhive java-script.

Even though i was being a polite net citizen and disclosing it on the site – firewalls with strict polices dont give it a chance. Several public DNS servers have also block listed the site – hopefully this will be undone soon.

There is a lot of fear around the word “crypto” due to the more malicious crypto-locker virus and it seems that coinhive has been associated to similar hysteria and panic.

Note : the amount of “wasted CPU” is trivial as i would only expect people visiting my site to be donating some cycles. i.e. in most cases i wouldn’t expect and entire company / business behind a firewall to browse my website and be under threat of  mass “CPU stealing”

 

Opensolaris – ZFS recovery after kernel panic

Recently i hit what i thought was a huge disaster with my ZFS array. Essentially i was unable to import my zpool without causing the kernel to panic and reboot. Still unsure of the exact reason, but it didn’t seem to be due to a hardware fault. (zpool import showed all disks as ONLINE)

When i tried to import with zpool import -f tank the machine would lockup and reboot (panic).

The kernel panic;  (key line)

> genunix: [ID 361072 kern.notice] zfs: freeing free segment (offset=3540185931776 size=22528)

Nothing i could do would fix it… tried both of these options in the system file with no success;

set zfs:zfs_recover=1
set aok=1

After a quick email from a Sun Engineer (kudos to Victor), the zdb command line that fixed it;

zdb -e -bcsvL <poolname>

zdb is a read only diagnostic tool, but seemed to read through the sectors that had the corrupt data and fix things??  (not sure how a read only tool does that) – the run took well over 15hrs.

Updated: 20/10/2009

Apparently if you have set zfs:zfs_recover=1 in your system file the zdb command will operate in a different manner fixing the issues it encounters.

Remember to run a zpool scrub <poolname> if you are lucky enough to get it back online.

This thread has some additional info…

http://opensolaris.org/jive/message.jspa?messageID=479553

Update 31/05/2012

This command has also helped me when i cant mount a pool in RW mode

zpool import -F -f -o readonly=on -R /mnt/temp zpool2