Open Source Web Hosting

2FA is pretty cool, especially when you don’t have to get a text message or email. Google Authenticator generates codes that expire after 30 seconds, so I figured it’s a good option for 2FA. I tried installing it on my Samsung Android and it said it was installing for over 24 hours. Finally I gave in and connected to wifi at which point it installed in a minute or less.

Next issue was invalid PIN. No matter what I tried my PIN was invalid! Then a colleague suggested it’s because my phone’s time is off by a few minutes. Under Settings – System – Date and time – I found that “Automatic date and time” was unchecked. After checking that, my time updated and my Authenticator codes worked right away!

This happens every time and I need to look for the solution. Posting here to save time going forward.

“startupWarnings”: {
“totalLinesWritten”: 9,
“log”: [
“2015-08-21T18:47:29.634+0000 I CONTROL [initandlisten] “,
“2015-08-21T18:47:29.634+0000 I CONTROL [initandlisten] ** WARNING: /sys/kernel/mm/transparent_hugepage/enabled is ‘always’.”,
“2015-08-21T18:47:29.634+0000 I CONTROL [initandlisten] ** We suggest setting it to ‘never'”,
“2015-08-21T18:47:29.634+0000 I CONTROL [initandlisten] “,
“2015-08-21T18:47:29.634+0000 I CONTROL [initandlisten] ** WARNING: /sys/kernel/mm/transparent_hugepage/defrag is ‘always’.”,
“2015-08-21T18:47:29.634+0000 I CONTROL [initandlisten] ** We suggest setting it to ‘never'”,

http://docs.mongodb.org/master/tutorial/transparent-huge-pages/

Create the following file at /etc/init.d/disable-transparent-hugepages:

#!/bin/sh
### BEGIN INIT INFO
# Provides: disable-transparent-hugepages
# Required-Start: $local_fs
# Required-Stop:
# X-Start-Before: mongod mongodb-mms-automation-agent
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Disable Linux transparent huge pages
# Description: Disable Linux transparent huge pages, to improve
# database performance.
### END INIT INFO

case $1 in
start)
if [ -d /sys/kernel/mm/transparent_hugepage ]; then
thp_path=/sys/kernel/mm/transparent_hugepage
elif [ -d /sys/kernel/mm/redhat_transparent_hugepage ]; then
thp_path=/sys/kernel/mm/redhat_transparent_hugepage
else
return 0
fi

echo 'never' > ${thp_path}/enabled
echo 'never' > ${thp_path}/defrag

unset thp_path
;;
esac

2
Make it executable.
Run the following command to ensure that the init script can be used:
sudo chmod 755 /etc/init.d/disable-transparent-hugepages

3
Configure your operating system to run it on boot.
Use the appropriate command to configure the new init script on your Linux distribution.

Distribution Command
Ubuntu and Debian
sudo update-rc.d disable-transparent-hugepages defaults

I can edit the port in the config file, but automation agent wipes that change out. How the heck does one change the port in cloud manager? I’m going to try removing and reinstalling the agent to see if that does it.

They don’t seem to want to tell you how to remove it!

On Ubuntu, dpkg -r mongodb-mms-automation-agent-manager removes it.

Had to do some searching to figure this out, so I’m noting it here for future reference. Even though smbclient -L works just fine, mounting with smbmount or mount -t was just not working.

apt-get install cifs-utils
mount.cifs -vv //192.168.0.3/backup /mnt/drobo/ -o user=Admin

it prompts for Admin’s password, then voila.

Was having some trouble hosting a wordpress site from a subfolder of the domain, ‘/blog’. The permalinks just would not work until I found this solution:

I only had to adapt it slightly for my situation:

location /blog/ {
try_files $uri $uri/ /blog/index.php?$args;
}

I had tried several other solutions but they had results such as losing the css. This worked for me!

Carelessly following these instructions, I got a WPOD.
Turns out the reason was I was copying two sections where I really only needed the second.
For the not-so-faint-of-heart;
make your child folder, such as ‘twentyten-child’ (2010, old-school, I know!)
Then you need two files to get started; style.css and functions.php as follows:

style.css
/*
Theme Name: TwentyTen Child
Theme URI: http://example.com/twenty-ten-child/
Description: TwentyTen Child Theme
Author: Joe T
Author URI: http://www.omniweb.com/wordpress
Template: twentyten
Version: 1.0.0
License: GNU General Public License v2 or later
License URI: http://www.gnu.org/licenses/gpl-2.0.html
Tags: Blargh, light, dark, two-columns, right-sidebar, responsive-layout, accessibility-ready
Text Domain: twenty-ten-child
*/

and functions.php

Then add any other files you need to customize and you’re safe from the upgrade destruction monster. Just good idea to keep an eye on when the parent theme is updated, what files are updated and make concurrent changes in any customized files (scary! but do it anyway you lazy lug [to myself]) -bye

Running vsftpd on CentOS, a user was unable to upload a file to a folder for which the user had group permissions.

Thanks to this post here, I was able to figure it out.

Needed to edit vsftpd.conf and update to include the following lines:

local_umask=002
file_open_mode=0777
anon_upload_enable=YES
anon_mkdir_write_enable=YES

After restarting vsftpd and making sure the relevant folders are group-writable, it works!

I have a program that uses perl’s File::PID but I was having some issue where the program would occasionally start multiple times.

Finally today I spent some time to figure out what’s going on. It seems that if you use the '$pidfile->write' function after checking whether it’s running already with '$pidfile->running()' then it puts back NOT the PID of the currently running process, but the PID that was there before!

Unless I’m misunderstanding my test result, you (I) need to do this to get the new PID into the old pidfile:


use File::Pid;
my $pidfile = File::Pid->new({
file => '/var/run/upload_cdn.pid',
});

#$pidfile->write; ## This was putting the original non-running PID back into the file


Maybe I was doing something wrong or maybe there’s a better way to handle this? Hopefully my program won’t start running multiple times any more!

While trying to run automated backups with syncbackfree some systems were having the subject error.

According to this forum the problem is with trying to use a mapped drive. I changed it to the LAN ip address
\\192.168.0.100\

and we’ll see if that doesn’t resolve it.

While trying to install XML::RSS from CPAN on a CentOS installation with Perl 5.10, it kept failing on the pre-requisite XML::Parser

For example, one of the failures showed:

t/astress.t ……….. Failed 15/27 subtests

and concluded with

Test Summary Report
——————-
t/astress.t (Wstat: 0 Tests: 27 Failed: 15)
Failed tests: 5-11, 14, 18-24
Files=15, Tests=141, 1 wallclock secs ( 0.07 usr 0.03 sys + 0.88 cusr 0.14 csys = 1.12 CPU)
Result: FAIL
Failed 1/15 test programs. 15/141 subtests failed.
make: *** [test_dynamic] Error 255
TODDR/XML-Parser-2.43.tar.gz
/usr/bin/make test — NOT OK
//hint// to see the cpan-testers results for installing this module, try:
reports TODDR/XML-Parser-2.43.tar.gz
Running make install
make test had returned bad status, won’t install without force

To resolve this, I found the doc said

“You can install this module from OS package too, but CPAN has most fresh version.
CentOS/RHEL/Fedora: perl-XML-Parser

so based on this I used
yum install perl-XML-Parser
to install the Perl XML Parser, and that then allowed
cpan XML::RSS
to finally complete the install correctly.