Doug’s Blog

Handily dispensing information to .00000001% of the world’s population

Archive for 2018

Google Chrome changed background colors

Thursday, July 26th, 2018

I updated Chrome to version 68.0.3440.75 (Official Build) (64-bit) just the other day and found that my browser windows had the background color change from white to a washed out looking pink. At first I thought it was a monitor issue, but other browsers and applications looked fine.

I tried a few things to fix it, including changed chrome settings by going to “chrome://flags/#windows10-custom-titlebar” and trying that setting with both disabled/enabled.

Turns out what fixed it was to disable hardware acceleration! Not sure why the new version of Chrome handles that differently, the setting was the same on the older version. But in any case, to turn it off, go to “settings”, scroll to the bottom and click “Advanced”, then towards the end under “System” you can turn off hardware acceleration.

Applying callback to grecaptcha

Tuesday, June 5th, 2018

We were having some troubles with some users rushing to click the submit button on a form immediately after clicking the good ‘ole “I’m not a robot” checkbox, instead of waiting nicely for the captcha to verify. By the way, that is TOTALLY what a robot would do, so it’s probably good that it fails the verification.

But to get the submit button to only enable after the checkbox turns green, you need to provide a “callback” routine for the grecaptcha. And, you can also provide a “expired-callback” routine for if the captcha box sits around too long after a check and then turns red. Note that you need to put the defined callbacks without quotes.

Also to add some complexity, we had two separate captchas in our page, so we had to define two of them. Some people have reported troubles doing so, but our final solution worked.

We had a problem where the callback routines were not being called, but everything else was working — it turns out we have the callback functions defined AFTER the render, and moving them before that section made everything work. So, the final layout:

<script src=”https://www.google.com/recaptcha/api.js?onload=myCaptInit&render=explicit” async defer></script>
<script>
var myCaptInit = function() {
var buton11 = function() {
$(“#mainsubmit”).removeAttr(“disabled”);
};
var butoff11 = function() {
$(“#mainsubmit”).attr(“disabled”, “disabled”);
};
grecaptcha.render(‘recaptcha11′, {
‘sitekey': ‘xxxx’,
‘callback': buton11,
‘expired-callback': butoff11,
‘size': ‘compact’
});
grecaptcha.render(‘recaptcha10′, {
‘sitekey’ : ‘xxxx’,
‘size’ : ‘compact’
});
};
</script>

Recovery LVM Data from RAID

Thursday, March 1st, 2018

We had a client that had an OLD fileserver box, a Thecus N4100PRO. It was completely dust-ridden and the power supply had burned out.

Since these drives were in a RAID configuration, you could not hook any one of them up to a windows box, or a linux box to see the data. You have to hook them all up to a box and reassemble the RAID.

We took out the drives (3 of them) and then used an external SATA to USB box to connect them to a Linux server running CentOS. You can use parted to see what drives are now being seen by your linux system:

parted -l | grep ‘raid\|sd’

Then using that output, we assembled the drives into a software array:

mdadm -A /dev/md0 /dev/sdb2 /dev/sdc2 /dev/sdd2

If we tried to only use two of those drives, it would give an error, since these were all in a linear RAID in the Thecus box.

If the last command went well, you can see the built array like so:

root% cat /proc/mdstat
Personalities : [linear]
md0 : active linear sdd2[0] sdb2[2] sdc2[1]
1459012480 blocks super 1.0 128k rounding

Note the personality shows the RAID type, in our case it was linear, which is probably the worst RAID since if any one drive fails, your data is lost. So good thing these drives outlasted the power supply! Now we find the physical volume:

pvdisplay /dev/md0

Gives us:

— Physical volume —
PV Name /dev/md0
VG Name vg0
PV Size 1.36 TB / not usable 704.00 KB
Allocatable yes
PE Size (KByte) 2048
Total PE 712408
Free PE 236760
Allocated PE 475648
PV UUID iqwRGX-zJ23-LX7q-hIZR-hO2y-oyZE-tD38A3

Then we find the logical volume:

lvdisplay /dev/vg0

Gives us:

— Logical volume —
LV Name /dev/vg0/syslv
VG Name vg0
LV UUID UtrwkM-z0lw-6fb3-TlW4-IpkT-YcdN-NY1orZ
LV Write Access read/write
LV Status NOT available
LV Size 1.00 GB
Current LE 512
Segments 1
Allocation inherit
Read ahead sectors 16384

— Logical volume —
LV Name /dev/vg0/lv0
VG Name vg0
LV UUID 0qsIdY-i2cA-SAHs-O1qt-FFSr-VuWO-xuh41q
LV Write Access read/write
LV Status NOT available
LV Size 928.00 GB
Current LE 475136
Segments 1
Allocation inherit
Read ahead sectors 16384

We want to focus on the lv0 volume. You cannot mount yet, until you are able to lvscan them.

lvscan

Show us things are inactive currently:

inactive ‘/dev/vg0/syslv’ [1.00 GB] inherit
inactive ‘/dev/vg0/lv0′ [928.00 GB] inherit

So we set them active with:

vgchange vg0 -a y

And doing lvscan again shows:

ACTIVE ‘/dev/vg0/syslv’ [1.00 GB] inherit
ACTIVE ‘/dev/vg0/lv0′ [928.00 GB] inherit

Now we can mount with:

mount /dev/vg0/lv0 /mnt

And viola! We have our data up and accessable in /mnt to recover! Of course your setup is most likely going to look different from what I have shown you above, but hopefully this gives some helpful information for you to recover your own data.

SFTP in Perl Connecting to Legacy Server

Tuesday, January 16th, 2018

We had a client that had a need to do automated SFTPs to various sites. It turns out that some of the sites had an older SSHD that would generate an error like “DH Group Exchange reply out of range”, and that required this parameter if you were using SFTP from the command line:

-oKexAlgorithms=diffie-hellman-group1-sha1

Now in Perl we were using Net::SFTP and it took some finagling (yes, that’s really a word) to figure out the proper settings, so here they were in case you were having trouble. And we had to add the warn flag otherwise we would get this warning:

Couldn’t fsetstat: Permission denied

Another oddity was that when we were putting files, the SFTP server allowed multiple files with the same name! Very odd, so we had to make sure to add a $sftp->do_remove command prior to the put command.

Here is what we used for the function call:

%sftp_args =
( “user” => “myuser”,
“password” => “mypass”,
“debug” => 0,
“warn” => 0,
“ssh_args” => [ options => [ “KexAlgorithms diffie-hellman-group1-sha1″ ] ]
);

$sftp = Net::SFTP->new($sftp_host,%sftp_args);