Compiling Ravencoin sgminer branch for x16r algorithm on ethOS

So, I was asked by a friend to compile some software for him using: https://github.com/aceneun/sgminer-gm-x16r/releases

I have to say that users branch was exactly that ‘aceneun’.

In the end I thought I’d goto the source so reached out to the raven developer of this branch:
https://github.com/brian112358/sgminer-x16r

It’s a tough time compiling in EthOS because it’s all weird, and it required extra depedancies do an apt-cache search for the extra dev libs, namely:

sudo apt-get install ocl-icd-opencl-dev it has a lot of dependancies and in ethos:

sudo apt-get-ubuntu install ocl-icd-opencl-dev

Upgrading all those packages seems not to break anything in my EthOS anyway. Now on to compiling brians branch of sgminer for the X16r algorithm.

Download repo:

git clone https://github.com/brian112358/sgminer-x16r

Prepare for compilation && checkout the dev branch && run make prepare

cd sgminer-x16r
git checkout dev

git submodule update --init --recursive
./autogen.sh

Then finally, we finish with :

CFLAGS="-Os -Wall -march=native -I/opt/AMDAPPSDK-3.0/include" LDFLAGS="-L/opt/amdgpu-pro/lib/x86_64-linux-gnu" ./configure --disable-git-version --disable-adl --prefix=/opt/sgminer-5.5.5

Finally run make to compile the software

make

You dont have to install it but you can like

make install

Make a proper file for our configs:

vi mylauncher.sh
[bash]
#!/bin/bash

export GPU_FORCE_64BIT_PTR=1
export GPU_MAX_HEAP_SIZE=100
export GPU_USE_SYNC_OBJECTS=1
export GPU_MAX_ALLOC_PERCENT=100
export GPU_SINGLE_ALLOC_PERCENT=100



ADDRESS="RBFthisiswhereyourravencoinaddressgoes"
POOL="stratum+tcp://miningpanda.site:3666"
PASSWORD="x"
INTENSITY="19"

./sgminer -k x16r -o $POOL -u $ADDRESS -p $PASSWORD -I $INTENSITY

chmod +x mylauncher.sh
./mylauncher.sh

A very simple task and as an avid proponent of ravencoin!

Compiling Ravencoin sgminer branch for x16r algorithm on ethOS

So, I was asked by a friend to compile some software for him using: https://github.com/aceneun/sgminer-gm-x16r/releases

I have to say that users branch was exactly that ‘aceneun’.

In the end I thought I’d goto the source so reached out to the raven developer of this branch:
https://github.com/brian112358/sgminer-x16r

It’s a tough time compiling in EthOS because it’s all weird, and it required extra depedancies do an apt-cache search for the extra dev libs, namely:

sudo apt-get install ocl-icd-opencl-dev it has a lot of dependancies and in ethos:

sudo apt-get-ubuntu install ocl-icd-opencl-dev

Upgrading all those packages seems not to break anything in my EthOS anyway. Now on to compiling brians branch of sgminer for the X16r algorithm.

Download repo:

git clone https://github.com/brian112358/sgminer-x16r

Prepare for compilation && checkout the dev branch && run make prepare

cd sgminer-x16r
git checkout dev

git submodule update --init --recursive
./autogen.sh

Then finally, we finish with :

CFLAGS="-Os -Wall -march=native -I/opt/AMDAPPSDK-3.0/include" LDFLAGS="-L/opt/amdgpu-pro/lib/x86_64-linux-gnu" ./configure --disable-git-version --disable-adl --prefix=/opt/sgminer-5.5.5

Finally run make to compile the software

make

You dont have to install it but you can like

make install

Make a proper file for our configs:

vi mylauncher.sh
[bash]
#!/bin/bash

export GPU_FORCE_64BIT_PTR=1
export GPU_MAX_HEAP_SIZE=100
export GPU_USE_SYNC_OBJECTS=1
export GPU_MAX_ALLOC_PERCENT=100
export GPU_SINGLE_ALLOC_PERCENT=100



ADDRESS="RBFthisiswhereyourravencoinaddressgoes"
POOL="stratum+tcp://miningpanda.site:3666"
PASSWORD="x"
INTENSITY="19"

./sgminer -k x16r -o $POOL -u $ADDRESS -p $PASSWORD -I $INTENSITY

chmod +x mylauncher.sh
./mylauncher.sh

A very simple task and as an avid proponent of ravencoin!

Diagnosing a sick website getting 500,000 to 1 million views a day

So today I had a customer that had some woes. I don’t even think they were aware they were getting 504’s but I had to come up with some novel ways to

A) show them where teh failure happened
B) Show them the failed pages that failed to load (i.e. get a 504 gateway timeout)
C) show them the number of requests and how they changed based on the day of the outage, and a ‘regular normal’ day.
D) show them specific type of pages which are failing to give better idea of where the failure was

In this case a lot of the failures were .html pages, so it could be a cache was being triggered too much, it could be that their application was really inefficient, or in many cases, were catalog search requests which no doubt would scratch the db pretty nastily if the database or the query wasn’t refactored or designed with scalability in mind.

With all that in mind I explained to the customer, even the most worrysome (or woesome) of applications and frameworks, and even the most grizzly of expensive MySQL queries can be combatted, simply by a more adaptable or advanced cache mechanism. Anyway, all of that out of the way, I said to them it’s important to understand the nature of the problem with the application, since in their case were getting a load average of over 600.

I don’t have their solution,. I have the solution to showing them the problem. Enter the sysad, blazing armour, etc etc. Well, thats the way it’s _supposed_ to happen !

cat /var/log/httpd/access_log | grep '26/Mar' | grep 'HTTP/1.1" 50' | wc -l
26081

cat /var/log/httpd/access_log | grep '27/Mar' | grep 'HTTP/1.1" 50' | wc -l
2

So we can see 504’s the day before wasn’t an issue, but how many requests did the site get for each day comparatively?

[root@anon-WEB1 httpd]# cat access_log | grep '26/Mar' | wc -l
437598
[root@anon-WEB1 httpd]# cat access_log | grep '25/Mar' | wc -l
339445

The box received 25% more traffic, but even based from the figures in the SAR, cpuload had gone up 1500% beyond what the 32 cores on their server could do. Crazy. It must be because requests are getting queued or rather ‘building up’, and there are so many requests reaching apache, hitting the request for mysql, that either mysql formed a bottleneck and might need more memory, or, at this scale, a larger or smaller (probably larger) sized packet for the request, this can speed up significantly how fast the memory bucket fills and empties, and request queue gets killed. Allowing it to build up is going to be a disaster, because it will mean not just slow queries get a 504 gateway timeout, but also normal requests to regular html pages too (or even cached pages), since at that stage the cpu is completely overwhelmed.

I wrote a script,

to find a majority of the 504’s for the 26 Mar you can use this piece:

cat access_log | grep '26/Mar' | grep 'HTTP/1.1" 50' | awk {'print $7'}

to generate a unique list for your developer/team of pages which failed you can run:

cat access_log | grep '26/Mar' | grep 'HTTP/1.1" 50' | awk {'print $7'} | sort | uniq

To be honest. In the simplicity of this post somewhere, is a stroke of inspiration (if not ingenuity). Also it’s kind of hacky and crap, but, it does work and it is effective for doing the job.

AND that is What counts.

Fixing phpmyadmin, Connection for controluser as defined in your configuration failed.

This happens when the phpmyadmin package is installed, but for some reason or another the automation the package manager and phpmyadmin have for setting up the phpmyadmin user, and phpmyadmin database doesn’t properly use the table schema from /usr/share. Here is the process of fixing this error for those that get it.

Create a database called phpmyadmin

create database phpmyadmin;

You can actually call the database anything as long as you remember what you changed it to later.

Create a database user

MariaDB [(none)]> GRANT ALL PRIVILEGES ON phpmyadmin.* to phpmyadmin@localhost identified by 'AVERYSECUREpasswordgoeshere98123123sdabcsd123' ;
Query OK, 0 rows affected (0.00 sec)

Locate the create_tables.sql file copied by the package manager (or zip if installing from source)


[root@linuxbox phpMyAdmin]# find /usr/share | grep create_table
/usr/share/phpMyAdmin/sql/create_tables.sql
/usr/share/phpMyAdmin/sql/create_tables_drizzle.sql
/usr/share/phpMyAdmin/libraries/display_create_table.lib.php
/usr/share/phpMyAdmin/test/libraries/PMA_display_create_table_test.php

Import the database schema

# Check the file is correct
[root@wlinuxbox---wp phpMyAdmin]# vi /usr/share/phpMyAdmin/sql/create_tables.sql

# Import it
[root@wlinuxbox wp phpMyAdmin]# mysql -u root -p < /usr/share/phpMyAdmin/sql/create_tables.sql
Enter password:

Afterwards you will need to make phpmyadmin aware of the creds in /etc/phpMyAdmin/config.inc.php

vi /etc/phpMyAdmin/confing.inc.php

Confirm your changes

[root@wd-linux-8---wp phpMyAdmin]# cat /etc/phpMyAdmin/config.inc.php | grep -A3 phpmyadmin
 * wiki <http://wiki.phpmyadmin.net>.
 */

/*
--
$cfg['Servers'][$i]['controluser']   = 'phpmyadmin';          // MySQL control user settings
                                                    // (this user must have read-only
$cfg['Servers'][$i]['controlpass']   = 'AVERYSECUREpasswordgoeshere98123123sdabcsd123';          // access to the "mysql/user"

$cfg['Servers'][$i]['pmadb']         = 'phpmyadmin'

Your work is done, and that pesky error is gone now phpmyadmin has it’s DB. This tutorial has been a long time coming as I see this all the time.

Adding a User with Sudo Access using visudo

Use the command visudo to access the /etc/sudoers file.

visudo

Uncomment this line:

## Allows people in group wheel to run all commands
# %wheel        ALL=(ALL)       ALL

So it looks like:

## Allows people in group wheel to run all commands
 %wheel        ALL=(ALL)       ALL

Save the file then

Run this command for your user

usermod -aG wheel usernameforsudoaccesshere

Your done.

But test it

su usernamewithsudoaccess
sudo yum history

Any root only command is a good enough test for this. The command should run succesfully after re-providing your users password for sudo access.

Disable/Enable TLS v1.0 v1.1 and v1.2 for plesk

This actually applies to any website, but is specifically aimed at plesk. Today a customer had complained that we’d disabled both tls 1 and 1.1, they wanted 1.1 for compatibility in the meantime, so it requires doing 1 of 2 things.

plesk bin server_pref -u -ssl-protocols 'TLSv1.1 TLSv1.2'

Or alternatively it can be done directly from within the conf.d ssl.conf for plesk in /etc/httpd/conf.d/ssl.conf, this also applies to httpd users not using plesk.

[root@888426-WEB3 ~]# cat /etc/httpd/conf.d/ssl.conf | grep TLS
#SSLProtocol +TLSv1 +TLSv1.1 +TLSv1.2
##     This exports the standard SSL/TLS related `SSL_*' environment variables.
##   The safe and default but still SSL/TLS standard compliant shutdown
##     the SSL/TLS standard but is needed for some brain-dead browsers. Use
##     alert of the client. This is 100% SSL/TLS standard compliant, but in
SSLProtocol +TLSv1.1 +TLSv1.2

A pretty simple operation here.

Redirect HTTP to HTTPS

It’s pretty simple after adding a HTTPS site in apache, to forward your existing HTTP website traffic to HTTPS. There might be reasons why you don’t forward everything, but in this case today I was asked to forward everything. Here is how I achieved it:

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L] 

It could be configured for a specific directory tho

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^/?somedir/(.*) https://%{SERVER_NAME}/secure/$1 [R,L] 

Pretty simple stuff.

Retrieving SMART status from a SDA disk attached to a MegaRAID card

Today I realised that manually checking the smart status of a disk required a bit more.

[root@box ~]# smartctl -a -d megaraid,0 /dev/sda
smartctl 5.43 2016-09-28 r4347 [x86_64-linux-2.6.32-696.16.1.el6.x86_64] (local build)
Copyright (C) 2002-12 by Bruce Allen, http://smartmontools.sourceforge.net

Vendor:               SEAGATE
Product:              ST3146356SS
Revision:             HS10
User Capacity:        146,815,733,760 bytes [146 GB]
Logical block size:   512 bytes
Logical Unit id:      -----
Serial number:        ----
Device type:          disk
Transport protocol:   SAS
Local Time is:        Thu Mar 15 05:18:57 2018 CDT
Device supports SMART and is Enabled
Temperature Warning Disabled or Not Supported
SMART Health Status: OK

Current Drive Temperature:     32 C
Drive Trip Temperature:        68 C
Elements in grown defect list: 15
Vendor (Seagate) cache information
  Blocks sent to initiator = 3694557980
  Blocks received from initiator = 4259977977
  Blocks read from cache and sent to initiator = 2859908284
  Number of read and write commands whose size <= segment size = 1099899109
  Number of read and write commands whose size > segment size = 0
Vendor (Seagate/Hitachi) factory information
  number of hours powered up = 65098.07
  number of minutes until next internal SMART test = 23

Error counter log:
           Errors Corrected by           Total   Correction     Gigabytes    Total
               ECC          rereads/    errors   algorithm      processed    uncorrected
           fast | delayed   rewrites  corrected  invocations   [10^9 bytes]  errors
read:   105645673        6         0  105645679   105645679      65781.538           0
write:         0        0        38        38         45      48511.618           7
verify: 48452245        7         0  48452252   48452259      43540.092           7

Non-medium error count:       48

SMART Self-test log
Num  Test              Status                 segment  LifeTime  LBA_first_err [SK ASC ASQ]
     Description                              number   (hours)
# 1  Background long   Completed                  16       1                 - [-   -    -]
# 2  Background short  Completed                  16       0                 - [-   -    -]

In order to retrieve this detail you need to use -d megaraid,n where n is the disk id number. Try 0, 1, 2, 3, etc. Or use the megaraidCLI to get a list of all the disks. I dunno I thought it was worth mentioning at least. It always pays to check this if customer is having weird I/O troubles. Quite a lot of detail is provided about errors the disk encounters. So looking here, even if SMART OK. Gives you an idea if any test failing for disk.